qtc-umd / rydiqule Goto Github PK

Hi there,

So I am trying to couple state |a> to |b> with two lasers, the ultimate goal is to do some kind of wave mixing scheme in a ladder system. However, I am having trouble achieving this in rydiqule.

The first thing I attempted was to add two couplings independently, so we have Add_Coupling((a,b), laser_1 parameters) Add_Coupling((a,b)laser_2 parameters). The problem with this is that if you check the Hamiltonian before and after the second coupling, what the second coupling will do is simply overwrite the first coupling, so laser1's parameter will be replaced by the laser2 parameter.

The other thing I've tried was instead of solving in steady state, I solve it in the time domain, such that I only need 1 coupling statement. The way this works (or at least what I believe to be) is that since laser1 and laser2 couple the same state, then in a suitable rotating frame, we can have the off-diagonal element be written as O1+O2e^(-iDt )|a><b| where O1,O2 is the rabi frequency corresponding to laser1 and laser2 and D is the detuning of laser2. Now, I'm not sure if the time-dependent scaler function just effectively multiplies it by the rabi frequencies so that you'll see a change in the off-diagonal element but what I have done was I defined f to be f(t)=1+(O2/O1)e^(iDt ) and using this then solving it at large time scale, I did get a sensible answer but have no way of verifying the validity. Also, this method is extremely slow for my purpose and I would avoid it if possible and do a steady solution instead.

Hello, first, I am very happy to be using Rydiqule! I was trying to do something a little extra, and ran into perhaps a limitation of the system worth discussing, or perhaps someone can show me the work-around, or what I'm doing wrong. I wanted to look at all the Zeeman sub-levels in EIT, and effectively drive many coupling transitions over the same detuning scan, but with varying Rabi frequencies and decay branches on each edge depending on the states it drives. So I'm looking at something like 30 or 42 zipped detuning scans, and I can zip the parameters just fine, but in the raw Hamiltonian representation, is still a [dd.....*d, n * n] matrix.
Using test detuning scans of size 3, I run into issues just looking at sub-sets:
{ Unable to allocate 127. GiB for an array with shape (3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 22) and data type complex128 }

and if I make the whole thing, I see errors in get_hamiltonian()'s mesh_grid and other counting / einsum arrangement functions such as :
{ c:_______\Anaconda3\lib\site-packages\numpy\lib\function_base.py in (.0)
4976 s0 = (1,) * ndim
-> 4977 output = [np.asanyarray(x).reshape(s0[:i] + (-1,) + s0[i + 1:])
4978 for i, x in enumerate(xi)]
ValueError: maximum supported dimension for an ndarray is 32, found 42
}

I don't see this being an easy fix,, and I don't think I'm even asking for anyone to work on it, I'm just curious how one would go about it, give how the rest of the graph-to-hamiltonian pipeline works. A big fix may be to internally write or generate the Hamiltonians where they're already zipped and many parameters scan in the same axis, losing dimensions in the big matrix representation. Perhaps if it were possible to perform a 'hard zip' that re-writes the Hamiltonian dimension, before generating the hamiltonian of that size, that's what I might be hoping for? It seems the issue is when generating and passing this big dimension matrix.
I can also imagine doing a loop over this detuning value as an external work around. It's funny, the issue is that Rydiqule is too generous at incorporating arbitrary parameters, I quickly blew up the dimensionality with p->30!

Any advice on this would be appreciated. Thanks!

needed to pip install leveldiagram.

In Section 3 of examples/Introduction_To_Rydiqule.ipynb, the figure in cell 32 has changed. I can't judge which one is more correct, but they are qualitatively very different.

In earlier commits, the figure is the one represented in the notebook when loaded:

...but when it is actually run, the figure is now:

I'm running into issues with using hyperfine states with Cell. I'm specifying the states using the notation [n, l, j, F, mF] as the documentation suggests, but I'm getting TypeErrors.

It looks like the list for each state is getting passed to the ARC function getRabiFrequency(), but the number of arguments being passed is incompatible. It also seems like the getRabiFrequency function expects arguments in the fine basis [n, l, j, mj]. It's not clear to me how or if Rydiqule handles conversion from the coupled hyperfine basis [n, l, j, F, mF] to the fine basis [n, l, j, mj], especially since the coupled hyperfine basis states are generally superpositions of the uncoupled basis states [n, l, j, mj, i, mi].

An error is not raised if I manually compute the hyperfine transition Rabi frequencies to input in the Cell couplings.

Example code:

import rydiqule as rq
import numpy as np

states = [[6, 0, 0.5, 4, 0], [6, 1, 1.5, 5, 0]]

probe = {'states': (0,1), 'beam_power': 1e-3, 'beam_waist': 1e-3, 'detuning': 0}

cell = rq.Cell('Cs', states[0], states[1], beam_area = np.pi*probe['beam_waist']**2)
cell.add_couplings(probe)

Error message:

  File ~\python scripts\testing\untitled2.py:16
    cell.add_couplings(probe)

  File ~\AppData\Local\miniconda3\envs\rydRelease11\lib\site-packages\rydiqule\sensor.py:366 in add_couplings
    self.add_coupling(states=states, **c_copy, **extra_kwargs)

  File ~\AppData\Local\miniconda3\envs\rydRelease11\lib\site-packages\rydiqule\cell.py:732 in add_coupling
    passed_rabi = np.array([[1e-6*self.atom.getRabiFrequency(*state1, *state2[:-1],

  File ~\AppData\Local\miniconda3\envs\rydRelease11\lib\site-packages\rydiqule\cell.py:732 in <listcomp>
    passed_rabi = np.array([[1e-6*self.atom.getRabiFrequency(*state1, *state2[:-1],

  File ~\AppData\Local\miniconda3\envs\rydRelease11\lib\site-packages\rydiqule\cell.py:732 in <listcomp>
    passed_rabi = np.array([[1e-6*self.atom.getRabiFrequency(*state1, *state2[:-1],

TypeError: getRabiFrequency() takes from 11 to 12 positional arguments but 13 were given

Since this is a RWA Hamiltonian, the diagonal elements should have the opposite sign of the detuning.

2-level system example

basis_size = 2
gamma = zeros((basis_size,basis_size))
gamma[1,0] = 2

Sensor = rq.Sensor(basis_size)
Sensor.set_gamma_matrix(gamma)

Sensor.add_couplings({'states':(0,1), 'rabi_frequency': 8, 'detuning': 5})

print("H = \n", Sensor.get_hamiltonian().real)
print("EOM_d = \n", rq.sensor_utils._decoherence_term(Sensor.decoherence_matrix()))
print("EOM_H = \n", rq.sensor_utils._hamiltonian_term(Sensor.get_hamiltonian()).imag)

Note that

• $\Gamma=2$
• $\delta=5$
• $\Omega/2=4$
• EOM_x order of columns (L-R) and rows (T-B) is (00),(01),(10),(11)

H = 
[[0. 4.]
 [4. 5.]]
EOM_d = 
[[ 0.  0.  0.  2.]
 [ 0. -1.  0.  0.]
 [ 0.  0. -1.  0.]
 [ 0.  0.  0. -2.]]
EOM_H = 
[[-0.  4. -4. -0.]
 [ 4.  5. -0. -4.]
 [-4. -0. -5.  4.]
 [-0. -4.  4. -0.]]

$H_{11}$ should be -5, not 5.

Compare this to Cohen-Tannoudfi, Dupont-Roc, Grynberg "Atom-Photon Interactions" (1998), Chapter V, Equations A.13.a-d (p 359) or Steck "Quantum and Atomic Optics" 0.14_2023, Eqn 5.26 (p 155):

Running on OSX, CyRK needed an additional package and other minor tweaking for rydiqule to load.

I installed rydiqule from my local clone with

pip install -e .

I use macports for packages and bash as my shell, so the necessary commands were:

sudo port install libomp
export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH/opt/local/lib/libomp:

This issue is NOT reporting any error in calculation! I am only documenting some confusion that I encountered using Rydiqule.

There are many parameters that get used to describe thermal velocity of an ideal gas:

1. 1-D standard deviation in the velocity: $\sqrt{kT/m}$ (aka, $\sigma$, the world over).
2. most-probable speed: $\sqrt{2kT/m}$ (favored by Rydiqule)
3. 3-D RMS speed: $\sqrt{3kT/m}$
4. average speed: $\sqrt{\frac{8kT}{\pi m}}$, (favored by ARC)

Documentation

At the top level, in cell and sensor, the documentation on how to specify kvec using the most-probable speed is consistent with the underlying code:

However, in doppler_utils.doppler_classes, most-probable speed is called "sigma", but it is really $\sqrt{2}\sigma$. The default value of 2.0 is reasonable, corresponding to ~2.8$\sigma$, but it takes a bit of diving into the code to confirm that it is a sensible default. I would have preferred a default range of $\pm 3\sigma$.
https://github.com/QTC-UMD/rydiqule/blob/e6f90608088502d7e733f0eb768b60aa4595dfe8/src/rydiqule/doppler_utils.py#L193-L195

Code

In doppler_utils.gaussian3d, the prefactor and return value are calculated for a Gaussian with $\sigma = 1/\sqrt{2}$, not 1 as claimed.

should be

    prefactor = np.power(1/(2*np.pi),spatial_dim*0.5)

    return prefactor*np.exp(-0.5*np.square(Vs).sum(axis=0))

but this would require changes to all of the methods of doppler_classes and likely other bits of code-surgery.

My opinions

1. Anything called Gaussian should return a proper Gaussian.
2. Any well-documented velocity is fine, but it would be best if Rydiqule and ARC would agree.