nikolasibalic / arc-alkali-rydberg-calculator Goto Github PK

In the section "Creating Highly Excited States" the function atom.getRabiFrequency is used twice. The first time it uses the gaussian beam waist (radius). The second time it uses the gaussian beam diameter (2*waist). According to the docs, it should be the waist and the second call should be adjusted accordingly.

atom = Rubidium87()
level = LevelPlot(atom)
level.makeLevels(4,6,0,3)
level.drawSpectra()
level.showPlot()

maybe change to 'return 0 if is not trangular' in Wiger6J

Hey,
I used Conda instead of pip to download the package.
There's an error running the notebook code:

atom=Caesium()

`
C:\ProgramData\Anaconda3\lib\site-packages\arc\alkali_atom_functions.py in init(self, preferQuantumDefects, cpp_numerov)
200
201 if self.cpp_numerov:
--> 202 from .arc_c_extensions import NumerovWavefunction
203 self.NumerovWavefunction = NumerovWavefunction
204

ImportError: numpy.core.multiarray failed to import`

As I have read other issues, the problem is with the C compiler, but the answers have only addressed pip users.

(I'm using python 3.8)

The paper Gallagher 2003 used for quantum defects for Rb 87 did fittings of D states up to n ~ 37. And they were able to fit measurements using just two quantum defect values (\delta_0 and \delta_2).

I am wondering now if fits were done for larger range of principal quantum numbers, if they would be significantly different? Would these fits have to involve also more terms in fitting function, as it is sometimes used for other alkali metals? By going to n = 84 and n = 97 experiments now are going quite far from the original explored range (see #20).

I have no precise feeling could this account for residual 200 MHz difference between current calculations for n D states in Rb 87 (n~80-100) - if someone has some comments on this, please write!

Originally posted by @nikolasibalic in #20 (comment)

LevelPlot interactivity only works for 2 clicks. See below for details

import arc

levels = arc.LevelPlot(arc.Cesium())
levels.makeLevels(99,101,1,3)
levels.drawLevels(units='ghz')
levels.showPlot()

click on 2 levels: title shows states and delta E
3rd click: no response
4th click: error message shows up

In [5]: Traceback (most recent call last):
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/matplotlib/cbook/__init__.py", line 270, in process
    func(*args, **kwargs)
  File "/Users/xxxx/Library/Python/3.7/lib/python/site-packages/arc/calculations_atom_single.py", line 1777, in onpick2
    self.state1[2], s=self.state1[3]),
IndexError: list index out of range
Traceback (most recent call last):
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/matplotlib/cbook/__init__.py", line 270, in process
    func(*args, **kwargs)
  File "/Users/xxxx/Library/Python/3.7/lib/python/site-packages/arc/calculations_atom_single.py", line 1777, in onpick2
    self.state1[2], s=self.state1[3]),
IndexError: list index out of range

(running 3.0.14)

My python-fu is not adequate to resolve this issue.

The defineBasis method within DynamicPolarizability class double counts energy levels depending on nMin and nMax passed in as a result of the extraLevels check.

It appears that extraLevels for an atom finds any levels that have principle quantum number smaller than the ground state, but, which nonetheless have energy higher than the ground state and are dipole coupled to the ground state. These extraLevels are always added into the basis for DynamicPolarizability calculation. This check is useful and has helped us avoid missing coupling to some states in the past. For the case of Rubidium87 the ground state has n=5 but there are some n=4 levels included in extraLevels. If one passes in nMin=4 to defineBasis then these states are double counted. This has led to incorrect values for calculations.

from arc import Rubidium87, DynamicPolarizability
atom = Rubidium87()
n = 5
l = 1
j = 3/2
calc = DynamicPolarizability(atom, 5, 1, 3/2)
print('with nMin = 5:')
calc.defineBasis(5, 6)
print(calc.basis)

print('with nMin = 4:')
calc.defineBasis(4, 6)
print(calc.basis)

gives

with nMin = 5:
[[5, 0, 0.5, 0.5], [5, 2, 1.5, 0.5], [5, 2, 2.5, 0.5], [6, 0, 0.5, 0.5], [6, 2, 1.5, 0.5], [6, 2, 2.5, 0.5], [4, 2, 2.5], [4, 2, 1.5]]
with nMin = 4:
[[4, 0, 0.5, 0.5], [4, 2, 1.5, 0.5], [4, 2, 2.5, 0.5], [5, 0, 0.5, 0.5], [5, 2, 1.5, 0.5], [5, 2, 2.5, 0.5], [6, 0, 0.5, 0.5], [6, 2, 1.5, 0.5], [6, 2, 2.5, 0.5], [4, 2, 2.5], [4, 2, 1.5]]

This issue could be resolved by checking if the existing state is already included in the basis whenever adding new states to the basis.

I have not checked if this issue occurs anywhere else in the code but it may be likely.

Maybe it can calculate angular dependance with tunable external magnetic field, the expected result is like(From Saffman, RMP, 2010):

But I didn't find any available example in the document...

The value returned by getPolarizability is 2/3 the size of alpha_0 here:
http://arc-alkali-rydberg-calculator.readthedocs.io/en/latest/_static/Rydberg_atoms_a_primer.html#Rydberg-Atom-Stark-Shifts

For example see the python file that is inside the attached zip folder (I can't directly attach a python file).
polarisability_check.zip

Hi
In the DynamicPolarizability module, the DynamicPolarizability.lifetime is initilized with a null list and does not have attribute length. So in the codedef getPolarizability

if (accountForStateLifetime and self.lifetimes.length == 0):
for state in self.basis:
self.lifetimes.append(self.atom.getStateLifetime(state[0],
state[1],
state[2],
s=self.s))

there is an error the first line

Dear all,
I am a phd student working on de excitation of Cs Rydberg atoms using Black Body radiation.
I am using the atom calculator (downloaded essentially).
I noticed something, and I may be wrong but, it seems that on the web interface you mix the parenthesis notation for reduced matrix element and the notation with bra ket.
In quantum optics note by Steck, Chapter 7 (Atomic Angular Momentum Structure), page 330, equation (7.239), the link between the two notations is written, and is the reverse of what is appearing on the web interface.


Hoping I am clear enough.

Let me know about this issue.
Thanks.

The wheel for the arc_c_extensions appears to have been compiled with numpy 1.16.x which involved a significant number of numpy API reorganizations over 1.15.x. When trying to run ARC with a lower version of numpy, code in the c_extension tries to load modules that have been renamed.

The explicit error I get running arc 2.0.6, python 3.6.8, and numpy 1.15.4 is

import arc
atom = arc.Rubidium85()
  File "C:\Users\David\Miniconda3\envs\ARC\lib\site-packages\arc\alkali_atom_functions.py", line 175, in __init__
    from .arc_c_extensions import NumerovWavefunction
ImportError: numpy.core.multiarray failed to import

The explicit module it fails on is numpy.core._multiarray_umath. I was put on the right track by a comment deep down the thread of this numpy issue.

Downgrading ARC to 2.0.5 works as expected. Presumably running numpy up to 1.16 would also work, but it isn't mainline in conda yet so I've held off.

Hi
Since I do not have immediate places for this in code, I'll just post a few optional Ca40 references here:

---------------- References with Ca atomic data ------------------------
Efficient repumping of a Ca magneto-optical trap
https://doi.org/10.1103/PhysRevA.96.033402
--New CI_MBPT calculations of energy levels and transition rates of 11 transitions relevant to repumping Ca for laser cooling.

Wavelength-dependent ac Stark shift of the 1S0‐3P1 transition at 657nm in Ca
https://doi.org/10.1103/PhysRevA.70.023414
--magic wavelengths for the ^3P_0 and ^3P_1 transitions in Ca

Investigation of highly excited states of calcium by three-photon ionization
Eur. Phys. J. D 30, 15–22 (2004)
DOI: 10.1140/epjd/e2004-00071-9
--decay times of Ca autoionizing states

--------------- use cases of intermediate Ca states ------------------
The optical calcium frequency standards of PTB and NIST
Comptes Rendus Physique 5.8 (2004): 845-855.
https://doi.org/10.1016/j.crhy.2004.08.005
--atomic structure and systematics relevant to a freely expanding Ca40 ^1S_0 -> ^1P_3 frequency standard

Alternative route to Bose-Einstein condensation of two-electron atoms
https://doi.org/10.1103/PhysRevA.70.023414
--demonstration of a ^3P_2 -> ^3D_3 MOT at 1.978 um, also uses the strong dipole allowed transition from [4s4p] -> [4p^2] near 430 nm

Hello,
I believe there is a bug in the getC6perturbatively method: the result has the opposite sign of what it should be.
I am comparing this with the pairinteraction package and my own code for perturbative C6 interactions and both give the opposite sign compared to ARC.

Thank you for working to extend this useful tool to divalent atoms. When attempting to plot the levels of Ca40 using calc.makeLevels(4,50,0,1,sList=[0]), I do not see the ground state that I would expect at -6.11 eV (https://physics.nist.gov/PhysRefData/Handbook/Tables/calciumtable5.htm) accordingly the $4s^2$ $^0S_1 \rightarrow$ $4s4p$ ^1P_1$ transition at 422.7 nm shows up as 6412.3 nm in the attached plot. In case I incorrectly specified the lowest principal quantum number, I have tried calc.makeLevels(1,50,0,1,sList=[0]) and got the same plot.

Side note: a potentially relevant reference for Ca atomic data: Oscillator strengths of the 4s4p 1,3P1 → 4snd 1,3D2 transitions
of neutral calcium DOI: 10.1140/epjd/e2008-00193-0

arc.calculations_atom_single.StarkMap.plotLevelDiagram

Input variable named "highlighState" should be "highlightState"?

In the code nvwcpp.c and on the primer on the website, the spin-orbit interaction

V_{so}(r)= \frac{\alpha \vec{L} \cdot \vec{S}}{2r^3}

It should be

V_{so}(r)= \frac{\alpha^2 \vec{L} \cdot \vec{S}}{2r^3} \frac{dV}{dr}

In a Hydrogenic potential

\frac{dV}{dr} =  \frac{e^2}{4\pi \epsilon_0 r^2} =  \frac{1}{\alpha}

Which matches the formula in the code (I think the minus signs are all fine).

Anyway why not use the screened potential when calculating the spin-orbit interaction?
Then one would change nvwcpp.c to

inline double Potenital(double r, double step){
	// l<4
	double V1 = CorePotential(r);
	double V2 = CorePotential(r+step);
	double dVdr = (V2-V1)/step;
	double Vso = pow(alpha,2)*commonTerm1*dVdr/(2*r);
	return V1 + Vso;
}

or if one wants to have a spin-orbit interaction which is well-behaved as r->0 an extra term can be included as is done in eq 3.31 of Aymar et al Rev. Mod. Phys. 68, 1015 (1996)

inline double Potenital(double r, double step){
	// l<4
	double V1 = CorePotential(r);
	double V2 = CorePotential(r+step);
	double dVdr = (V2-V1)/step;
	double Vso = pow(alpha,2)*commonTerm1*dVdr/(2.0*r*pow((1.0-pow(alpha,2)*V1/2.0),2));
	return V1 + Vso;
}

Running ARC with numpy>=1.16.3 fails to perform calculations with the following error:

IndexError                                Traceback (most recent call last)
<ipython-input-7-136115d426ee> in <module>
      2 rvdwCs = calcCs.getLeRoyRadius()
      3 print('Le Roy Radius is %.2f um'%rvdwCs)
----> 4 C6Cs = calcCs.getC6perturbatively(theta,phi,nRange,singleEnergyRange)
      5 blockadeCs = np.abs(C6Cs/linewidth)**(1/6)
      6 print(f'Blockade radius for {linewidth*1e3} MHz linewidth laser is {blockadeCs:.2} um')

C:\Miniconda3\envs\arc\lib\site-packages\arc\calculations_atom_pairstate.py in getC6perturbatively(self, theta, phi, nRange, energyDelta)
    873                                                                                l1,j1,
    874                                                                                l2,j2,
--> 875                                                                                self.atom)
    876 
    877                                                 angularFactor = conjugate(stateCom2.T).dot(d.dot(stateCom))

C:\Miniconda3\envs\arc\lib\site-packages\arc\calculations_atom_pairstate.py in __getAngularMatrix_M(self, l, j, ll, jj, l1, j1, l2, j2, atom)
    287         index = self.c.fetchone()
    288         if (index):
--> 289             return self.savedAngularMatrix_matrix[index[0]]
    290 
    291         # determine coupling

IndexError: list index out of range

It also produces the following more helpful message in stdout:
(<class 'ValueError'>, ValueError('Object arrays cannot be loaded when allow_pickle=False'), <traceback object at 0x000000000A2D1E48>).

A quick search reveals a parameter change in np.load that now disables pickle loading be default.

The function arc.alkali_atom_functions.getEnergy does not use quantum defect calculations if n < arc.alkali_atom_functions.minQuantumDefectN . While this is supposedly desired behavior, it is in contrast to the documentation of getEnergy: "For preferQuantumDefects =True, program will always calculate energies from quantum defects (useful for comparing quantum defect calculations with measured energy level values)"

In a level plot not showing S, the labels on the x-axis come out incorrectly. I should see P, D, F, but the labels are cycled left (D in P's place, F in D's place, no label under F).

import arc

levels = arc.LevelPlot(arc.Cesium())
levels.makeLevels(99,101,1,3)
levels.drawLevels(units='ghz')
levels.showPlot()

(running 3.0.12)

on my own copy (installed via pip), I tweaked LevelPlot's and StarkMap's plotting routines to plot in 'GHz', '1/cm' or 'eV'. I wanted to be able to see those figures in the same units.

If desired, I can contribute it to you code via a branch or fork. The mods to your code were pretty minor.

arc/temp folder missing in original distribution. This folder is necessary in order to run C++ integration of Numerov, since the wavefunctions are temporarily saved there. Many thanks to Julius de Hond for spotting this.

Rubidium().getEnergy(n=5, l=0, j=-1/2) (as an example) returns an energy when it shouldn't (I guess?), since total angular momentum quantum number j is negative and probably it cannot be negative. From the function definition it seems when j == -1/2, ARC does not grab recorded experimental energy data, but rather just calculate energy using Rydberg equation. Seems there can be a positivity check for j in the case of S state?

In the magic wavelength example, there may be a potential issue for the polarizabilities of excited states. Namely, the possibility for an excited state to transition to lower energy states is not properly accounted for. For instance, if you calculate the polarizability of 6P_3/2 state of Cesium, the resonance between 6S_1/2-6P_3/2 is not shown in the dynamical polarizability plot. This does not affect greatly for the red-detuned magic wavelengths, but gives a slight shift in the blue wavelengths. This may be troublesome for higher n states as well.

Running 2.2.9, I get the following traceback running Rubidium85().getStateLifetime(n,l,r)

Suspect it is a regression from adding the new optional s keywords.

TypeError                                 Traceback (most recent call last)
<ipython-input-36-75e9188bf66f> in <module>
      4 jR = 2.5
      5 T = 300 #in K
----> 6 Rb85_BBR_Lifetime = Rb85.getStateLifetime(nR,lR,jR)
      7 print(f'BBR included lifetime of Rb85 {nR}{L[lR]}{jR}: {Rb85_BBR_Lifetime*1e6:.3e} us')

C:\Miniconda3\envs\arc\lib\site-packages\arc\alkali_atom_functions.py in getStateLifetime(self, n, l, j, temperature, includeLevelsUpTo, s)
   1558                                                              nto, lto, jto,
   1559                                                              temperature,
-> 1560                                                              s=s)
   1561 
   1562         for nto in xrange(max(self.groundStateN, l + 2),

C:\Miniconda3\envs\arc\lib\site-packages\arc\alkali_atom_functions.py in getTransitionRate(self, n1, l1, j1, n2, l2, j2, temperature, s)
   1457         dipoleRadialPart = 0.0
   1458         if (self.getTransitionFrequency(n1, l1, j1, n2, l2, j2,
-> 1459                                         s1=s, s2=s) > 0):
   1460             dipoleRadialPart = self.getReducedMatrixElementJ_asymmetric(
   1461                 n1, l1, j1,

TypeError: getTransitionFrequency() got an unexpected keyword argument 's1'

Hi Nikola
I think there is an extra factor in the pondermotive polarizability. Since in AC field, the polarizability is defined as U = 1/4*\alpha_{AC} * E^2 compared to that of DC: U = 1/2*\alpha_{DC} * E^2. It is just a minor factor of 2 but I think it still worth to point it out.

hey! @nikolasibalic

I just download the ARC-Alkali-Rydberg-Calculator-3.0.2 .Running the code:

'atom= Strontium88()
calc = LevelPlot(atom)
calc.makeLevels(5,6,0,5,sList=[0,1])
calc.drawLevels()
calc.showPlot()'

in jupyter notebook (python 3.8). Return the error:

'ModuleNotFoundError Traceback (most recent call last)
in
----> 1 atom= Strontium88()
2
3 calc = LevelPlot(atom)
4 calc.makeLevels(5,6,0,5,sList=[0,1])
5 calc.drawLevels()

d:\Jupter\ARC\ARC-Alkali-Rydberg-Calculator-3.0.2\ARC-Alkali-Rydberg-Calculator-3.0.2\arc\divalent_atom_functions.py in init(self, preferQuantumDefects, cpp_numerov)
104
105 if self.cpp_numerov:
--> 106 from .arc_c_extensions import NumerovWavefunction
107 self.NumerovWavefunction = NumerovWavefunction
108

ModuleNotFoundError: No module named 'arc.arc_c_extensions''

Any ideas?
thanks!
lin

The calculation of 6-J symbols in the wigner module includes a look-up table that appears to make assumptions that certain inputs are integers, though they need not be. Thus many symbols, such as wigner.Wigner6j(1/2,1/2,1,2,1,3/2), will throw errors as those inputs are not integers. Specifically, line 215,

return wignerPrecal6j[j1,
                      2 + j1 - J3,
                      int(roundPy2(2 + 2*(j3-j1))),
                      int(roundPy2(2 + 2*(J1-J3))),
                      J2 - 1,
                      int(roundPy2(2 * j2))],

throws the error.

I was trying to calculate the Rabi frequency ratio of Cs atom excitation (6S_{1/2} -->nP_{1/2}) to (6S_{1/2} -->nP_{3/2})
By running the following code:

rabiFreq = cs.getRabiFrequency(n1=6, l1=0, j1=0.5, mj1=0.5, n2=84, l2=1, j2=1.5, q= +1, 
                                      laserPower=1000.e-3, laserWaist= 50.e-6)
rabiFreq_2 = cs.getRabiFrequency(n1=6, l1=0, j1=0.5, mj1=0.5, n2=84, l2=1, j2=0.5, q= 0, 
                                      laserPower=1000.e-3, laserWaist= 50.e-6)
print(rabiFreq/rabiFreq_2)

I got the ratio = 3.4056.
However, the following papers say that the oscillator strength for excitation to P_{1/2} states is orders of magnitude weaker than for excitation to P_{3/2} states:
• https://journals.aps.org/pra/abstract/10.1103/PhysRevA.89.033416
• https://arxiv.org/pdf/1706.06237.pdf
The oscillator strengths are proportional to the square of the Rabi frequency:
3.4^2 = 11.56
but this still can't get us 4 orders of magnitude as the paper say ....
I wonder if there is something wrong with getDipoleMatrixElement?
By the way, I also made this plot:

Hi Nikola
In the Wavefunction class, the plot2D funciton plot the wavefunction in the spherical coordinate on the 2d cartesian plane. Then it make sense to me to only plot the Psi^2 rather than including the volume factor r^2 since this is in cartesian coordinate.

Hi,

Not sure if this is a feature request or a basic question in the usage of matplotlib so sorry if this is not the place.

Is there an easy way to get the handle for the starkmap plots? using plt.gca() does not seem to work.

thanks,

Gal

Hi,

Rydberg transition frequencies of Rb 87 measured in our lab disagree with the values I obtain by doing

atom = Rubidium87()
atom.getTransitionFrequency(5, 0, 0.5, 97, 2, 2.5)  # 5 S_1/2 to 97 D_5/2

Disagreement is quite large : ~ 4.5 GHz.

If I rather use atom=Rubidum85(), they agree within a few MHz. But I'm sure my experiment is done with Rb 87. Wondering if 'scaledRydbergconstant' in ARC package is somehow swapped?

Let me know if you have any idea. #

for atom = Rubidium87()
the defineBasis method of StarkMap gives inf coupling between [51, 50, 49.5, 49.5] and [52, 51, 51.5, 49.5], also between [52, 50, 49.5, 49.5], [52, 51, 50.5, 49.5]
(n0, l0, j0, mj0) is (50, 49, 49.5, 49.5) and nmax=53, nmin=50, lmax=54.
The self.mat2 gives inf at [2,8] and [5,7] which correpsonds to state above.

Cannot find the definition of self.eFieldCouplingSaved.getAngular() function which is called in
self._eFieldCouplingDivE()

Hi I'm walking through the primer and found something worth mentioning.

Everytime makeLevels function is called, it appends the lists of labels. If one calls the function again, it will append another entries, possibly allowing duplicated ones. I found this feature to be useful yet requires some caution.

Say we have a code

nmin=5  #Minimum n
nmax=5 #Maximum n
lmin=0  #Minimum l
lmax=1  #Maxmium l

atom=Rubidium()
levels = LevelPlot(atom)
levels.makeLevels(nmin,nmax,lmin,lmax)
print levels.levelLabel

This yields [[5, 0, 0.5], [5, 1, 0.5], [5, 1, 1.5]].

If it goes through another run, levelLabel will have [[5, 0, 0.5], [5, 1, 0.5], [5, 1, 1.5], [5, 0, 0.5], [5, 1, 0.5], [5, 1, 1.5]]

I believe this behavior is intended and nothing wrong. Actually it can be utilized to include multiple levels which cannot be handled my a single execution of makeLevels. Say one wants to see energy levels above the ground state Rb 5s_{1/2}, including 4d. Although 4d is more energetic, it will be not covered by makeLevels if one specifies nmin=5. Putting nmin=4 will force the code to draw 4s_{1/2}, leading to non-physical result. Therefore workaround I use is

nmin=5  #Minimum n
nmax=5 #Maximum n
lmin=0  #Minimum l
lmax=2  #Maxmium l

levels.makeLevels(4,4,2,2)
levels.makeLevels(nmin,nmax,lmin,lmax)

This will give levels [[4, 2, 1.5], [4, 2, 2.5], [5, 0, 0.5], [5, 1, 0.5], [5, 1, 1.5], [5, 2, 1.5], [5, 2, 2.5]] and it is what I intended to get.

In the future it might be more failsafe to add an initializing function, which empties existing labels. I had to restart kernel in order to draw new level plots.

Hi Nikola,

I'm bringing this issue on behalf of my friend and co-worker Ran Finkelstein.

See below:

Dear Nikola,

Thank you so much for the wonderful ARC package.

I wanted to carry out a calculation for transitions in Rydberg states with Sr atoms, which are Alkaline-earth atoms.

Do you think it would be possible to get literature values of these in ARC? Or other, more elaborate, calculations?

Thank you,

Ran Finkelstein

Hi when I am trying to create an atom using: "atom=Caesium()", my python shell gives an error as following:

Traceback (most recent call last):
File "<pyshell#20>", line 1, in
atom=Caesium()
File "/Users/lukema/Library/Mobile Documents/comappleCloudDocs/Research/ARC-Alkali-Rydberg-Calculator-master/arc/alkali_atom_functions.py", line 172, in init
from .arc_c_extensions import NumerovWavefunction
ModuleNotFoundError: No module named 'arc.arc_c_extensions'

Am doing anything wrong before diving too deep into the code ?
Best

Wavelengths and energies in LevelPlots (and perhaps elsewhere) are reported in fixed units (nm, GHz, eV, cm-1). I wrote a short function to format these numbers with their SI prefixes.

Shall I push the branch ("si_prefix", locally) for review?

two known issues:

1. \mu is not formatting properly
2. this is not turned off for cm-1, which is contrary to tradition.

When calculating the dynamic polarizability of Caesium and Rubidium using getPolarizability I am getting results that don't seem correct.

For the ground state of Rubidium 5s1/2 ,I get the usual asymptotes at 780 and 795 nm but another occurs at around 1100 nm which does not correspond to any real transition in Rubidium.

Likewise with Caesium I am using it to calculate the polarizability of Rydberg states following the idea of J. Phys. B: At. Mol. Opt. Phys. 53 (2020) 155302, however the results I obtain have an additional asymptote occurring at around 1350 nm, where as the authors in the previous article do not get anything showing up at this point.

Is this something you could please explain to me?

I am aware that recent updates introduced some bug to calculation of Stark maps and possibly more. Stable version is 1.3. I am working to resolve this ASAP.

Hey @nikolasibalic,

In order to test some new functions I forked the repository and am working off the 2.0.5 commit. Running the code:

import sys
rootDir = r'C:\Users\Jacob\Documents\ARC-Alkali-Rydberg-Calculator'
sys.path.insert(0,rootDir)

import arc
atom = arc.Caesium()

in Python 3.7.1 returns the (abbreviated) error:

File "arc\alkali_atom_functions.py", line 175, in __init__
    from arc.arc_c_extensions import NumerovWavefunction
ImportError: No module named arc_c_extensions

This is the same error that was reported in a few issues. Issue #19 doesn't seem relevant because I'm not using pip. I've tried running some simple code through the command line and have encountered the same error, so I'm not sure its an issue with my config as was reported in #16. Issue #12 seems the most relevant but release 2.0.4 should have added support for Python 3.7, so I'm not sure why I would need to compile the c-extension myself.

Any thoughts?

Thanks,
Jacob

Hi folks

I'm having an installation issue with pip. I've installed the Visual C++ 14.0 redist from microsoft, but the pip installer is still claiming that it's not installed. I'm using 64-bit python 3.7 (vanilla - not Anaconda/Enthought). Is there any workaround for this, or is this a known problem? I've copied the error output below:

Cheers

James

p.s. Not sure if it's in your control or not, but the link to the visual cpp tools site in the error message below gives me a 404 error.

    ....
    copying arc\arc_c_extensions.c -> build\lib.win-amd64-3.7\arc
    running build_ext
    No module named 'numpy.distutils._msvccompiler' in numpy.distutils; trying from distutils
    building 'arc.arc_c_extensions' extension
    error: Microsoft Visual C++ 14.0 is required. Get it with "Microsoft Visual C++ Build Tools": http://landinghub.visualstudio.com/visual-cpp-build-tools

    ----------------------------------------
Command "c:\users\jkeaveney\appdata\local\programs\python\python37\python.exe -u -c "import setuptools, tokenize;__file__='C:\\Users\\JKEAVE~1\\AppData\\Local\\Temp\\pip-install-h9d5u8oq\\ARC-Alkali-Rydberg-Calculator\\setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record C:\Users\JKEAVE~1\AppData\Local\Temp\pip-record-l2lrredq\install-record.txt --single-version-externally-managed --compile" failed with error code 1 in C:\Users\JKEAVE~1\AppData\Local\Temp\pip-install-h9d5u8oq\ARC-Alkali-Rydberg-Calculator\

Hi,
I would like to calculate some pairstate interactions, but unfortunately the code fails... is there a simple solution to this?
using ARC in python 3.6, and just did the pip install ARC-Alkali-Rydberg-Calculator --upgrade, and also deleted the .arc-data directory...

calc = PairStateInteractions(Caesium(), 28,0,0.5,28,0,0.5, 0.5, 0.5, interactionsUpTo = 2)
calc.defineBasis(0, 0, 5, 5, 25e9,progressOutput=True)
calc.diagonalise(np.linspace(0.2,3,300),250,progressOutput=True)

output.log

Hi,
I am trying to run atom.getStateLifetime(28,3,3.5), with atom=Rubidium87(). This causes jupyter lab to get stuck and collapse every time. If I try the same by with a D state (28,2,2.5) it works fine.
Is it because this is an F state? Are there any literature values for F states?
Any tips in general on how not to collapse Python? this seems to happen every time I run a heavy or an unorthodox calculation

Thank all the developers for improving this calculator. Glad to see this is growing and being more powerful.

Just installed the version 3.0 and I was wondering if it supports dynamic polarizability calculations for divalent atoms.

Say I want to calculate the polarizability of (5s5p) 3P1 state of Strontium88. Can this be done in the current version? In the example notebook, Cesium case was displayed, and DynamicPolarizability function didn't seem to accept individual electron's n and l. Perhaps there's a way to give input for divalent atoms and I'm missing something.

When installing with pip on a Mac, the dependencies matplotlib and sympy were not automatically installed, leading to errors when running

from arc import *;

It seems pip install under Windows doesn't install binary for Numerov integration. I am looking at the problem that seems to happen during wheel creation/upload process. Error received on Windows is:

File "arc\alkali_atom_functions.py", line 175, in __init__
    from arc.arc_c_extensions import NumerovWavefunction
ImportError: No module named arc_c_extensions

getDipoleMatrixElement seems to fail when I try to calculate the dipole moment of transitions to very high (typically n>~100) Rydberg states or between neighboring high-lying Rydberg states. Nothing in the definition of radialWavefunction seems to impose an upper limit on n, so I'm wondering if there are any insights here?

For a concrete example: nS1/2 to nP3/2 in 85Rb.

The following successfully returns -7180.2914962...

atom=Rubidium85()
n1=108
l1=0
j1=0.5
mj1=0.5
n2=108
l2=1
j2=1.5
mj2=1.5
q=mj2-mj1
print(str(atom.getDipoleMatrixElement(n1,l1,j1,mj1,n2,l2,j2,mj2,q)))

But the same code with n1=109 and n2=109 fails.

Hi!

We've updated to the latest ARC and we now cannot import the library.

We get the following error message:

FileNotFoundError Traceback (most recent call last)
in
----> 1 from arc import *
2 #from arc.beta import * # This is necessary for running this notebook before official release of ARC 3.0.0

~\Anaconda3\envs\physics\lib\site-packages\arc_init_.py in
4 from future import division, print_function, absolute_import
5
----> 6 from .alkali_atom_data import *
7 from .calculations_atom_single import *
8 from .calculations_atom_pairstate import *

~\Anaconda3\envs\physics\lib\site-packages\arc\alkali_atom_data.py in
87 from future import division, print_function, absolute_import
88
---> 89 from .alkali_atom_functions import *
90
91 from scipy.constants import Rydberg as C_Rydberg

~\Anaconda3\envs\physics\lib\site-packages\arc\alkali_atom_functions.py in
2487
2488
-> 2489 setup_data_folder()

~\Anaconda3\envs\physics\lib\site-packages\arc\alkali_atom_functions.py in setup_data_folder()
93 os.makedirs(refractiveIndexData)
94
---> 95 for fn in os.listdir(dataFolder):
96 if os.path.isfile(os.path.join(dataFolder, fn)):
97 shutil.copy(os.path.join(dataFolder, fn), refractiveIndexData)

FileNotFoundError: [WinError 3] The system cannot find the path specified: 'C:\Users\fewin\Anaconda3\envs\physics\lib\site-packages\arc\data\refractive_index_data'

Hi
I am trying to compute the continuum radial wavefuntion of Rb87 with the parameteric model potential https://journals.aps.org/pra/pdf/10.1103/PhysRevA.49.982. I looked up the cpp code in arc_c_extensions.c and have couple of questions:

1. Does the radialWavefunction function support continuum energy? I try with positive stateEnergy and it spit out some resonable thing but see 3.
2. In the code, you re-parametrize the radius with x = sqrt(r). Is that for a better percision? since it is not the regular way we write the radial wavefunction.
3. I try a Numerov method with the radial wf u =r * R, like this with the corresponding paramatric potential taken from you code. Below is my code. What I found is that the solution of the two methods sometimes agree but mostly do not. For example,
   En = 1.5, Rl = np.linspace(1e-7,100,10000)
   does not, but
   En = 0.5, Rl = np.linspace(1e-7,100,10000)
   agree. I am wondering what could cause that, would it be the way of re-parametrization?

        from scipy import *
        import numpy as np
        from scipy import integrate
        from scipy import optimize
        import matplotlib.pyplot as plt
        from scipy import constants as cc
        from arc import *
        atom = Rubidium87()
        def effRadialPotential(l, s, j, r, E):
            # used as f in Numerov(f, x0, dx, dh)
            mu = (atom.mass - cc.m_e) / atom.mass #reduce mass of electron
            return 2 * ( mu * (atom.potential(l,s,j,r) - E) + l * (l + 1)/(2 * r**2) )

        def Numerov(f, x0, dx, dh):
            """Given precomputed function f(x), solves for x(t), which satisfies:
                  x''(t) = f(t) x(t)
            """
            x = np.zeros(len(f))
            x[0] = x0
            x[1] = x0+dh*dx

            h2 = dh**2
            h12 = h2/12.

            w0=x0*(1-h12*f[0])
            w1=x[1]*(1-h12*f[1])
            xi = x[1]
            fi = f[1]
            for i in range(2,len(f)):
                w2 = 2*w1-w0+h2*fi*xi  # here fi=f1
                fi = f[i]  # fi=f2
                xi = w2/(1-h12*fi)
                x[i]=xi
                w0 = w1
                w1 = w2
            return x

        Rl = np.linspace(1e-7,10,10000)
        l=0
        En=0.5
        feff = np.array([effRadialPotential(l,0.5,l+.5, i, En) for i in Rl])
        ur = Numerov(feff,0.0,1e-1,Rl[1]-Rl[0])
        norm = integrate.simps(ur**2,x=Rl)
        ur *= 1/np.sqrt(abs(norm))
        arcr, arcRad = atom.radialWavefunction(l,0.5,l+0.5,En,Rl[0],Rl[-1],Rl[1])

        plt.plot(Rl,ur,'b')
        plt.plot(arcr,arcRad,'r')
        # plt.ylim(-1,1)
        norm

I've been calculating pair-state energies for different thetas, and ran into unexpected behavior. ARC is doing fine for theta = 0, but for other angles say theta = 0.5 * pi, the matrix dimension gets huge. e.g. 1553 vs 34660.
State I'm looking into is Rb |97d5/2 mj=5/2, ,97d5/2, mj=5/2>,.

nRyd = 97
lRyd = 2
jRyd = 2.5
mjRyd = 2.5
calc1 = PairStateInteractions(Rubidium(),
                              nRyd, lRyd, jRyd,
                              nRyd, lRyd, jRyd,
                              mjRyd, mjRyd, interactionsUpTo=1)
theta = 0
calc1.defineBasis(theta, 0., 4, 5, 7e9)

This prints out

Calculating Hamiltonian matrix...
	matrix (dimension  1553 )

For same parameters except theta being 0.5*pi,

calc1 = PairStateInteractions(Rubidium(),
                              nRyd, lRyd, jRyd,
                              nRyd, lRyd, jRyd,
                              mjRyd, mjRyd, interactionsUpTo=1)
theta = 0.5 * pi
calc1.defineBasis(theta, 0., 4, 5, 7e9)

which outputs

Calculating Hamiltonian matrix...
	matrix (dimension  34660 )

This seems to impose additional computation cost on diagonalization, and the result also doesn't look physical e.g. no r dependency.

Any tips or comments are greatly appreciated!

In the calculation of Zeeman energy shift, the result is inf for atom.getZeemanEnergyShift( 50, 49.5, 49.5,0). Mainly because the CG(50,50,1/2,-1/2,49.5,49.5) spit out nan which is the result of Wigner3J.

Maybe try to lower the bound in line 60 in Winger3J
if (j1 > 50 or j2 > 50 or j3 > 50 or m1 > 50 or m2 > 50 or m3 > 50):