Rabi frequencies #73

AVB25 · 2024-12-23T18:37:34Z

Essentially, this is a completion of the TODO in Atom.calc_Epole about the connection between the stored scattering amplitudes and the experimentally measurable Rabi frequencies. Instead of documentation, it adds functions for directly calculating Rabi frequencies and other related quantities like light shift (AC Stark shift) frequencies. There are a couple of other things added, such as a broader Beam object to store a laser beam's parameters. This could replace the Laser object if desired.

AVB25 · 2024-12-23T18:41:36Z

I think this mostly agrees with experiment, except the quadrupole Rabi frequencies it predicts have been around 2.3 times faster than those found in ABaQuS. I'm not sure whether the discrepancy is due to maths or experimental parameters not being fully known.

One thing I maybe suspect is the conversion from Cartesian to Spherical coordinates. The conversion I've done is mostly from https://doi.org/10.1007/s003400050373 with some fudging of signs to make the Rank 1 tensor components agree with what is usually used, but the maths in Section 4.5 of Angular Momentum by Brink and Satchler gives slightly different results. However, it would make the discrepancy bigger.

…ntal parameters

AVB25 · 2024-12-23T18:57:45Z

(Formatting)

hartytp

Great to have some work towards handling scattering amplitudes properly etc.

However, a PR along these lines is unlikely to get merged because it doesn't respect and work with some of the basic design decisions behind this package. I'll go into some detail below and in the comments to illustrate what I mean.

In terms of going from here to something mergeable, I'd suggest you try to break this down into a series of smaller PRs which do just one thing (e.g. a small util function for calculating Rayleigh ranges if you feel that's useful) rather than a single large PR which really does a few unconnected things.

Examples of ways this PR doesn't work with the design behind this package:

we deliberately chose not to have a State object because we want to work at arbitrary magnetic fields where F is not well-defined (although there is a helper until already provided to aid with this)
we chose to work in saturation intensity units, now power / waist (again, there is a helper util for converting)
we chose to deal with polarization based on the change in angular momentum for the transition it drives, not polarization angles
we chose to specify laser frequencies in terms of a detuning from a transition, rather than an absolute wavelength

There is obviously no single convention which is best in every situation, but one has to adopt a representation and work with it, rather than having multiple things which do the same thing in different ways. If you want a different convention, the best approach would be to add a few util functions to help with the conversions - or, if you feel strongly that we should change the fundamental design, to open a discussion issue for one specific point.

Beyond that, the Beam object really feels like it groups a few things together which don't belong together - just helper functions.

Also, there are no tests! Before merging something like this I'd want to see some tests which exercise the new functionality - e.g. comparing calculations to known good values from literature / trusted theses.

hartytp · 2024-12-23T20:34:15Z

atomic_physics/common.py

@@ -131,6 +137,11 @@ def __init__(

        self.levels = levels
        self.transitions = transitions
+        # Store the transitions indexed by the upper and lower levels it connects,
+        # useful fro reverse searching
+        self.reverse_transitions = {


This shouldn't be stored as class attribute - bad practice to store the same information multiple times in different formats.

hartytp · 2024-12-23T20:35:38Z

atomic_physics/beam.py

+
+        return [q_m2, q_m1, q_0, q_p1, q_p2]
+
+    def print_rank1(self, title=None):


Please remove these print functions. If anything, this is the kind of thing we'd have in an example script, but it doesn't belong in the library code.

hartytp · 2024-12-23T20:37:51Z

atomic_physics/common.py

@@ -32,6 +32,12 @@
     atom.delta)
 """

+State = namedtuple("State", ["level", "F", "M"])
+State.__doc__ = """Convenient holder for storing atomic state data.


Not having a first-class representation of a state was a deliberate decision because this package is intended to work at arbitrary magnetic field, so one cannot generally assume that F is a good quantum number. Instead, we rely on indexing states within a level by energy order and provide a helper function for getting a best-guess at which state corresponds to a given |F, M_F>.

Having a first-class object for this would be a much more major change.

hartytp · 2024-12-23T20:39:12Z

atomic_physics/rabi.py

+from .beam import Beam
+import scipy.constants as consts
+
+__doc__ = """


This isn't how we specify module-level docstrings in this package.

hartytp · 2024-12-23T20:41:00Z

atomic_physics/beam.py

+import numpy as np
+import scipy.constants as consts
+
+"""Vectors to convert a Cartesian vector to the spherical basis, with q=-1, 0, 1


Why docstring formatting when this is basically a comment?

hartytp · 2024-12-23T20:53:27Z

atomic_physics/beam.py

+
+    def __post_init__(self):
+        self.I_peak = 2 * self.power / (np.pi * self.waist_radius**2)
+        self.E_field = np.sqrt(2 * self.I_peak / (consts.c * consts.epsilon_0))


This should not be a class attribute - trivially calculable from other properties. At most it should be a helper function.

hartytp · 2024-12-23T20:58:44Z

atomic_physics/rabi.py

+
+def scattering_amplitude_to_dipole_matrix_element_prefactor(wavelength: float):
+    """
+    Get the prefactor to convert a scattering amplitude (the scale that


This description doesn't tell me a lot. I'd like a proper definition which links this to physical observables / gives clear definitions of what we mean (there are a few different conventions around). Linking to papers has a place, but I shouldn't have to read a paper to figure out what this does.

hartytp · 2024-12-23T20:59:44Z

atomic_physics/rabi.py

+    )
+
+
+def scattering_amplitude_to_quadrupole_matrix_element_prefactor(wavelength: float):


Generally in this package we don't have separate functions for dipole and quadrupole matrix elements - we pass in a transition and figure that out internally.

hartytp · 2024-12-23T21:01:22Z

atomic_physics/rabi.py

+    more complex phase-dependent interactions such as light shifts and Raman
+    transitions.
+
+    TODO: The quadrupole Rabi frequency disagreed with the experimentally measured


This kind of TODO does not belong here!

hartytp · 2024-12-23T21:08:49Z

atomic_physics/common.py

@@ -422,9 +433,7 @@ def calc_Epole(self):
        since they are somewhat more convenient to work with. The two are
        related by constants and power of the transition frequencies.

-        To do: define what we mean by a matrix element, and how the amplitudes


Having a helper util for converting to Rabi frequencies is great, but it doesn't remove the need to add some documentation to define what we actually mean by a matrix element and to remind people how this is converted to physically measurable Rabi frequencies (and what we mean by a Rabi frequency since there is more than one convention).

hartytp · 2024-12-23T21:14:47Z

I think this mostly agrees with experiment, except the quadrupole Rabi frequencies it predicts have been around 2.3 times faster than those found in ABaQuS. I'm not sure whether the discrepancy is due to maths or experimental parameters not being fully known.

One thing I maybe suspect is the conversion from Cartesian to Spherical coordinates. The conversion I've done is mostly from https://doi.org/10.1007/s003400050373 with some fudging of signs to make the Rank 1 tensor components agree with what is usually used, but the maths in Section 4.5 of Angular Momentum by Brink and Satchler gives slightly different results. However, it would make the discrepancy bigger.

Better to either (a) resolve this kind of discrepancy before opening this PR or (b) explicitly mark the PR as a draft. It's not really clear what the intent behind this PR is - are you looking for a review and merge, or just opening as a placeholder while you do some more thinking?

FWIW the sign conventions here are a bit messy. The big thing I was looking for in my todo was to get really clear (and document! e.g. adding a markdown document if needed) on what conventions we're using and avoid fudges.

hartytp · 2024-12-23T21:21:41Z

NB there is some related discussion in:

Those issues outline the approach I would expect us to take here.

AVB25 · 2024-12-26T14:39:29Z

Thank you for the detailed comments, I appreciate you adding all that info and links.

Having read them, I agree with you that the approach I took was not the correct one - and that I probably rushed to raise a PR on something that wasn't ready for that yet. The main intention behind the PR was that I had written this code for some recent simulation work and spent a fair bit of time looking up how to go from the scattering rates in ePole to a physical Rabi frequency. Other PhDs in the group then mentioned that they also had to go through a similar process, so I thought it would be useful to make this code available as part of the package, since calculations of Rabi frequencies and other similar quantities feel like a natural extension of its current utility. However, in doing so, I more or less directly copied the functions I had used without thinking about how they'd fit in with the rest of the package, which I now realise was not the best thing to do - apologies.

Regarding the TODO on the quadrupole transitions, I agree that this is not in a state that is mergeable - I will find comparisons with literature and include them in tests.

I also agree that splitting this up into smaller PRs/issues would make this more manageable. Shall I close this PR, unless you have anything else to add?

hartytp · 2025-01-07T21:21:12Z

@AVB25 thanks for the contribution.

I spent some time over the holiday refreshing the API for atomic physics as well as improving documentation and testing - largely inspired by this PR. I think it's now in a better place to tackle this.

If you're still interested in taking this forward, I suggest a good small issue to tackle first would be #86 Do you want to give that a go?

hartytp · 2025-01-07T21:22:56Z

Another self-contained PR would be to add a helper function to create an arbitrary elliptical polarization based on angles (see the polarization module and tests). If we do this, the main things I'm keen on are having good docs (either docstring or adding to the definitions / conventions page in the manual, being clear about things like definitions of angles and sign conventions / handedness. Maybe even include an ASCII art / SVG image illustrating how we define angles) and tests.

AVB25 · 2025-01-08T09:49:24Z

Thank you for this! And yes! I'd be more than happy to take both forward.

Useful Beam object for storing beam intensity and polarisation

6bdf9a3

AVB25 force-pushed the rabi_frequencies branch from 56a747f to 896deea Compare December 23, 2024 18:53

Functions for directly calculating the Rabi frequencies from experime…

8078811

…ntal parameters

AVB25 force-pushed the rabi_frequencies branch from 896deea to 8078811 Compare December 23, 2024 18:56

hartytp marked this pull request as draft December 23, 2024 20:32

hartytp requested changes Dec 23, 2024

View reviewed changes

hartytp closed this Jan 7, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Rabi frequencies #73

Rabi frequencies #73

AVB25 commented Dec 23, 2024

AVB25 commented Dec 23, 2024

AVB25 commented Dec 23, 2024

hartytp left a comment •

edited

Loading

hartytp Dec 23, 2024

hartytp Dec 23, 2024

hartytp Dec 23, 2024

hartytp Dec 23, 2024

hartytp Dec 23, 2024

hartytp Dec 23, 2024

hartytp Dec 23, 2024

hartytp Dec 23, 2024

hartytp Dec 23, 2024

hartytp Dec 23, 2024

hartytp commented Dec 23, 2024

hartytp commented Dec 23, 2024

AVB25 commented Dec 26, 2024 •

edited

Loading

hartytp commented Jan 7, 2025

hartytp commented Jan 7, 2025 •

edited

Loading

AVB25 commented Jan 8, 2025


		return [q_m2, q_m1, q_0, q_p1, q_p2]

		def print_rank1(self, title=None):

		)


		def scattering_amplitude_to_quadrupole_matrix_element_prefactor(wavelength: float):

Rabi frequencies #73

Rabi frequencies #73

Conversation

AVB25 commented Dec 23, 2024

AVB25 commented Dec 23, 2024

AVB25 commented Dec 23, 2024

hartytp left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hartytp commented Dec 23, 2024

hartytp commented Dec 23, 2024

AVB25 commented Dec 26, 2024 • edited Loading

hartytp commented Jan 7, 2025

hartytp commented Jan 7, 2025 • edited Loading

AVB25 commented Jan 8, 2025

hartytp left a comment •

edited

Loading

AVB25 commented Dec 26, 2024 •

edited

Loading

hartytp commented Jan 7, 2025 •

edited

Loading