Workaround for multiple transitions

[LutherGrusovin]

I've seen your reply from 2021 on a workaround for implementing multiple transitions, by spatially swapping the AtomicTransition component. Could you give me an idea on how I would write code to do this? I'm in my final semester of my undergrad, working on simulating laser cooling of a Dysprosium gas. The atoms will move from a 2D MOT with a 421nm transition into a 3D MOT with a 626nm transition, so I would like to change the transition component once it enters a specific spatial region.

This is indeed a limitation of the current code, that we can only have one transition per atom!

Short term workaround

For now we are modelling setups with blue/red by basically swapping the AtomicTransition either spatially, eg on entities that go into the red region, or in time, eg doing it at a certain point in time. That is a workaround at best.

Longer term feature implementation

Currently the rate equation implementation assumes a two-level system. For various components used in the rate force calcs, eg TotalScatteredPhotons, these enforce being a single transition (really this is the total scattered photons on a particular atomic transition).

One easy implementation could be to introduce generic components for the transitions, for example TotalScatteredPhotons<Sr461>. Variants of the systems could be readily introduced for each transition, so that all the transitions occur in parallel for each allowed transition, eg CalculateTotalScatteredPhotons<Sr461>.

Originally posted by @ElliotB256 in #46

[ElliotB256]

Hey there! You'll need to first create the transition information for your particular atomic species (see for example https://github.com/TeamAtomECS/AtomECS/blob/c4000179bc8f28a2ac57c6257c8af9127d6d2660/src/species.rs). The macros there create a struct that implements the required functionality for an AtomicTransition, e.g. Strontium88_461 *. In your plugin, register laser cooling modules for both transitions, e.g. LaserCoolingPlugin::<Transition1, {number_of_beams}>::default()

• Define your laser beam entities for the two stages of the trap.
  -When you create your atom entities, first attach the Transition1 component. This will allow the transition1 systems to interact with them and create the required forces.
• Add a system that queries entities with Position and Transition1 components. The system checks if they have crossed the threshold into a second region, and if they have use a command buffer to remove the transition1 component and add a transition2 component.
• Alternatively, I'm reasonably confident you can leave both AtomicTransitions on the atom entities the whole time. The physics is approximate because it will calculate forces as if these transitions are separately interacting (rather than e.g. population effects across a multilevel system), but if your regions are separated this is a reasonable approximation anyway. Removing the transition1 component is slightly faster as you won't pay the cost of evaluating the cooling forces twice, but its only a factor of two in the scheme of things.

As a starting point, you can probably stick the above text into codex or claude and it will be able to get a first version running.

Other info which may be interesting but not required to know:

• The transition! macro is defined here; you can think of it as a function that generates a bit of code at compile time, so it lets us automate some aspects of creating the required structs and functions. https://github.com/TeamAtomECS/AtomECS/blob/master/src/laser_cooling/transition.rs#L46
• You might wonder why we don't just have an AtomicTransition struct with variables that encode each of these parameters. By making each atomic transition have a separate struct implementation with fixed constants it allows us to compile the code to be slightly faster, because the values are known and hard coded at compile time.