And then you can create a new branch and set the omp-rbm branch as the upstream like so:

git checkout -b <your-branch-name>
# make changes to the files, and add and commit them to your local branch
git push --set-upstream omp-rbm-origin omp-rbm

You will have to let me know if you want access so I can add you as a collaborator on github. Just send me the email associated with your github profile and I can add you.

I asked Kyle to talk about this application of the RBM for coupled channel scattering but I ended up not having enough time to sit down and chat. I would love to be involved in this project if there’s space for one more person.

I have thought a bit about how it could be implemented from my involvement with the ROSE project. Let me know if that’d work

Of course, we’d love to have you involved! All we’ve done so far is to start formulating the problem. We can set up a zoom this coming week to discuss the project.

Let’s do it! I will be at Caltech for most of this upcoming week. Monday is pretty free, the other days we can try to figure out a time in the morning.

I filled my availability. I’m at Caltech this week for work so my times are not very flexible. Hopefully there’s some overlap. If not I will try my best to be present for the scheduled time

Happy 4th of July to everyone, and very happy to have you aboard Edgard!

Thanks Kyle for rewriting and uploading the notes!
I attempted to create a pull request with a couple of small fixes,

When we stopped discussing last time we were considering two points:

What parameters to vary. For a simple start, changing only the depths V, W, \beta, \gamma will simplify the evaluation of the couplings.

What basis to use. We thought that it would be most convenient to use a separate basis for the ground state and each excited state, presumably just a set of solutions for those (for each set “a” of parameters, the \psi_0, \psi_1, \psi_2 in the notes). The alternative could have been to treat the tuple of solutions for each state as a single, longer vector, and make a basis for that.

Agreed. If we stick with the affine dependencies (just depths) training and testing the emulator will be really easy.

I’m a bit more of a fan of using a single, longer vector. Because the equations we are modelling are inherently coupled and linear, so there will be more redundancy we can exploit. But I agree that a basis for everything is simpler, so maybe start there first.

I was reading the description on the github and got a bit confused. I had understood that the coupled-channel problem is just mixing states with different “l” numbers. If it is mixing different energies, what do we choose for “l” in each equation?

My understanding is that, if the potentials do not couple different angular momenta (as we want here, I guess), then you can solve for each single l separately, and they do not couple. In principle you have to solve for all l to get the full solution, but in practice one truncates somewhere reasonable for the energy of interest.

So coupled channels in general can be open to interpretation - it just means factorizing your Hilbert space into an elastic channels, as well as one or more discrete inelastic channels. Typically the elastic channel is the ground state of the target + the projectile, and the included inelastic channels are the excited states of the target + projectile.

The choice of model that describes those excited states is determined by what sort of phenomena need to be described. For example, for heavy nuclei, one might choose a collective model like the soft-rotor model, that describes rotational and vibrational excitations of the target. It is this choice of model that determines the coupling between angular momentum states. For example, for the soft-rotor model, each channel describes a given total angular momentum, and so the three contributing the angular momentum of 1) the target 2) the projectile and 3) the orbital angular momentum need to be coupled in such a way (e.g. through Racah coefficients) that adds up to the total angular momentum of the channel (and, for unpolarized beams/detectors, averages over total projection quantum numbers).

In our toy model, we’ve made up a simple thing that ignores angular momentum coupling entirely - e.g. our model Hilbert space is factorizable into a tensor product of energy and AM states. This is a very unrealistic simplifying assumption. In this case, it is as Simone describes; each orbital AM state is uncoupled to eachother, but the energy levels are coupled within each orbital AM state,

A better choice might be to assign the ground state and each excited state a fixed total angular momentum. Then (by Wigner-Eckhart theorem) the coupling between partial waves (orbital AM states) becomes purely geometric, and each excited state has contributions by a weighted sum of oributal AM states, with weights given by Racah coefficients (or, equivalently, Wigner-6j symbols). This increases the dimension of the Hilbert space dramatically, as each l state is now coupled, but is much closer to real problems so perhaps this is a better place to start.

Thanks for the more in-depth reply!
While it is indeed quite unrealistic, for our toy model, personally, I would go ahead imagining that we are coupling, say, three 0+ states, at least to start. Adding angular momentum coupling generates several technical annoyances but little physics insight.

I agree that this is probably the best place to start.

If we have time, we can extend to channels with non-zero total AM as I described. This would probably present the biggest technical challenge of how to construct the basis (e.g. one basis for each partial wave? each channel? tensor product somehow?) which would provide valuable insight into how best to do it with a realistic model (e.g. with a production code like Fresco as the high-fidelity solver). I think this can be really good “future work” for this project.

Hey @aainabthapa , I’m finally getting around to reading this paper and I was wondering if there is a good source for numerical/computational details on the implementation of RPA/QRPA?