Order of sequent add_coupling calls changes Hamiltonian

[evgmik]

Hi, thanks for Rydiqule package.

For the bug context, I am trying to calculate laser polarization light dependent parameters in a Rb atom. I notice that when I apply the couplings between intermediate and Rydberg levels the resulting Hamiltonian are not the same. With some shuffling happening for the off diagonal links between Rydberg and intermediate manifolds.

My understanding that Hamiltonian level numbering is happening at the time of Cell creation, so it should not happen.

Below a minimal example to reproduce the bug, order of lines after comment starting with ATTENTION changes the outcome.

import matplotlib.pyplot as plt
import numpy as np

import rydiqule as rq
from rydiqule import A_QState
import networkx as nx


g = rq.A_QState(5, 0, 0.5, f=3, m_f='all')
i = rq.A_QState(5, 1, 1.5, f=4, m_f='all')
r = rq.A_QState(44, 2, 2.5, m_j='all')

c = rq.Cell('Rb85', [g,i,r])

dwp = 0 # probe detunings
dwb = 0 # blue detunings
c.add_coupling((g,i), rabi_frequency = 10.5, detuning=dwp, q=0, label='probe_pi')
c.add_coupling((g,i), rabi_frequency = 5.5, detuning=dwp, q=-1, label='probe_l')
c.add_coupling((g,i), rabi_frequency = 2.3, detuning=dwp, q=1, label='probe_r')

# upper link beam
c.add_coupling((i,r), rabi_frequency = 10, detuning=dwb, q=0, label='blue_pi')
# ATTENTION: changing order of the next 2 lines changes Hamiltonian
c.add_coupling((i,r), rabi_frequency = 30, detuning=dwb, q=-1, label='blue_l')
c.add_coupling((i,r), rabi_frequency = 40, detuning=dwb, q=1, label='blue_r')

plt.figure(1)
plt.clf()
plt.imshow(np.abs(c.get_hamiltonian()))
plt.title("|Hamiltonian|")
plt.savefig('hamiltonian.png')
plt.close()

Also a more involved calculation which for example tracks total population of the intermediate level also would produce different results
based on the coupling order.

[dihm]

While I won't go so far as to say it is intentional, it is a natural consequence of rydiqule's design bumping up against subtleties in mixing bases.

Rrydiqule's design does not allow multiple coupling definitions between two states. If one already exists, it will remove the old one completely then over-write. The rub is that when moving between states defined in different bases (ie hyperfine to fine), polarization selection rules mix and multiple polarizations will couple between the same sublevels (ie $sigma^\pm$ light couples the some of the same $m_F \rightarrow m'_{J}$ sublevels). Therefore, when you add a second polarization to the same coupling group, some of the sublevel transitions are being over-written. To be clear, neither order of operation is going to give the correct result for this sample problem. Assuming you are on >=v2, you should be able to call print(c) before and after adding the trouble couplings to see what is going on.

This is a somewhat sticky problem, partly complicated by the fact that I'm not confident in what the Hamiltonian should even be. In the near term, you can over-ride this behavior (basically controlled by specifying q) by ensuring you provide rabi_frequency and instead giving the correct coupling_coefficients for the combined polarizations. If you create a reliable scripting that leverages ARC (or even better RQ_AlkaliAtom), I'd love to see it. Such scripting is basically what we would need to do under the hood to support this, so having a worked example would make implementation much easier. Ultimately, I suspect a generalized parameterization that covers the many possible edge cases is going to be tough (and is largely why we didn't attempt it).

In the meantime, we will probably need to consider some helpful warning that detects this situation in Cell so others aren't quite as surprised.

[evgmik]

Thanks for the clarification. I think I saw a mentioning that it is impossible to couple the same transition with different fields in one of the issues but it was not clear what were the exact conditions for it to kick in.

To the problem at hand. My understanding that multiple coupling are hard because it hard to build the proper RWA Hamiltonian. From other hand if the "offending" couplings are of the same frequency/detuning, they should not change the RWA and could be added together. I think this is what you are suggesting to do in your work around.

An alternative is to just add couplings instead of overwriting them. This would preserve Hamiltonian invariant against coupling additions order of operations. It is not the most general case, but realistically in an experiment there are 2 or 3 lasers involved so it might be a reasonable way. This would else help with "zip" operation in Rydicule which is quite counterintuitive since one have to zip different polarizations of the same laser while they are coupled in real experiment.

Can you point me to the part of the code which decide that coupling should be overwritten? I will try to see if it cold be reworked.

P.S. in the experiments we are often care about transmission of the light beams which have different polarization decomposition. I.e. we need to track the total susceptibility per polarization. This seems to be unsolvable problem in Rydicule as well. I am not sure how to attack this problem without keeping a separate structure for the light field with its coupling per polarization. But it seems to be needed if we ever able to use Rydicule for realistic systems. I would appreciate any hints how to link it to internals of Rydicule.

[benjamin-n-miller]

My understanding that multiple coupling are hard because it hard to build the proper RWA Hamiltonian.

While this is part of it, there are also logistical issues.

For some context on the internals, we specifically implement the atomic graph of a Sensor as networkx directed graph, which can only have a single coupling between nodes. networkx has a graph object (MultiGraph) that supports multiple edges between nodes, but not using it was a deliberate choice we made early in development because it introduced to many ambiguities in inferring data from the graph. Any possible solution to this issue would need to be careful to respect the method by which rydiqule build its rotating frames.

Can you point me to the part of the code which decide that coupling should be overwritten? I will try to see if it cold be reworked.

The actual removal of the data happens in Sensor._remove_edge_data() (line 3247 in the latest version), which is called on line 1164 in Sensor._add_coherent_data(). It is also worth noting networkx's behavior if you add an edge that already exists. On a digraph object, it will quietly override the old data with the new anyway (also how just inheriting how pure-python dictionaries work). If you have an idea, you are certainly welcome to try and implement it on a fork and share, but we do need to be careful about breaking rydiqule's internal assumptions on this repo.

[dihm]

@evgmik While thinking on this a bit more, I realized there is a simpler work around. The primary issue at hand is that the basis in which we are expressing the optical field isn't really compatible with the mixed atomic basis. If you change the Rydberg state to the hyperfine basis, this issue will de-couple and handle as expected. Assuming that doesn't cause other issues for you, I would recommend that path before mucking around in Rydiqule's internals.

Honestly, there is an argument to be made that even a homogenous basis doesn't play nice with the typical q=-1,0,1 polarization basis since your optical field has a single (complicated) polarization. Decomposing the optical polarization basis in this way is for convenience in defining the atomic states. At least for now, Rydiqule doesn't have the capability to automatically break down an arbitrarily-polarized field into the appropriate q=-1,0,1 basis, which is fundamentally what you are asking for. Right now, we rely on the user to do that decomposition themselves.

While our ultimate goal is for Cell (or more likely some inheritor) to be more black box in these regards, the reality is that Cell is a convenience wrapper for integrating ARC parameter calculations with Sensor. As a result, understanding of how Sensor works is still a requirement for successful use. Or put another way, one still needs to know how to write down the Hamiltonian since Cell and Sensor idiosyncrasies stem from the Hamiltonian itself. Ultimately, the Hamiltonian (atom) does not care how the experimentalist produced the field, merely what it is at the atom. It doesn't matter if I use a single linearly-polarized field, or combine equal left and right circularly polarized fields with a NPBS, the Hamiltonian is unchanged. This is fundamentally why we do not allow multiple couplings on a transition: as far as the Hamiltonian is concerned, there is no second coupling, just the sum total coupling. At least for now, Rydiqule insists the user provides the total coupling for a transition all at once.

As for your ultimate goal, I believe Rydiqule provides the tools already. They just aren't especially user-friendly (or apparently documented, oops) and would require manual work on your part. In broad strokes, I would suggest creating coupling coefficient dictionaries for $\sigma^+$ and $\sigma^-$ (these coefficients track the polarization decomposition as well as relative atomic coupling strengths). Then create a combined coupling coefficient dictionary that sums them in a physical way. Use the combined dictionary to add a single coupling for your complicated field. Then use the separated coefficients to create the associated dipole operator for each desired polarization to feed into the Solution.get_observable() method. Some of this structure is shown in the NMOR example notebook which uses manually defined coupling coefficient matrices to get the susceptibility associated with the polarization perpendicular to the input probing field (necessary to calculate polarization rotation).

If you go down this route, I'll again emphasize that we would be excited to see it. We'd even be open to collaborating on developing a generalized solution. At the end of the day, we are a small team and Rydiqule isn't our primary responsibility. It is a tool we use in house for our research; one that we think has utility for others so we share it publicly. Getting assistance from the community, especially in developing new features and extending capabilities, is going to be critical to ensure utility and ease of use for others' problems.