Using AtomECS for optical transport simulations

[ElliotB256]

An email from @tevzLotric ,

Dear Dr. Bentine,

I am working on optimizing the optical transport of ultracold erbium atoms for the dipolar quantum gases group here in Oxford. This of course involves running some simulations. Péter Juhász brought to my attention that you have written a library, AtomECS, for simulating ultracold gases, and I think I could make good use of it.

The reason I am writing to you is that I have tried running it, but cannot find a way to vary the location (intersection parameter) of a Gaussian Beam between different timesteps. Doing so would be crucial for what I am trying to do. Is there a way to do so in ­­the library? The best I could think of is deleting the old beam and adding a new one, but I cannot even figure a way to do that. Do you have better ideas about how I could implement a moving beam?

Thank you for any help, Tevž Lotrič

To define time-varying quantities you should use the ramp API in atomecs - see e.g. the documentation here. It allows you to define the values of components at different points in time, and then linearly ramp between them. You could use the to move the beam focus, change the beam waist, etc. There are minimal examples in the unit tests for that module which show how to use it.

You may also wish to use s-wave collisions in your simulations, I'd like @d-garrick to comment on what the state of the s-wave collision features are at the moment.

It's worth mentioning Cambridge have been working on optical transport simulations using atomecs (@MauriceZeuner and @tiffanyharte did the atomecs dipole trap implementation). @MauriceZeuner I saw there were some commits regarding testing the dipole trap example, is the current implementation working?

[ElliotB256]

Also tagging @BrianBostwick and @cahty1006 from the Cambridge AION team!

[d-garrick]

On the subject of s-wave collisions, I'm currently working on finishing this up. AtomECS currently can already implement s-wave collisions, but it uses a static spatial partition so may be of limited usefulness. The upgrades I'm writing will adapt the spatial partitioning between timesteps to fit the width and density of the cloud. The collision rates agree with theoretical predictions of the collision rates, and I'm trying to obtain some good experimental data to compare to for confirmation. These upgrades will also include one/two/three body losses. The collisions currently use the previous version of AtomECS syntax so it hasn't been merged with the master, but this can be done soon. I'm hoping to be finished and have pushed these upgrades in the next couple of weeks.

[tiffanyharte]

Dipole trap implementation: we're still seeing some results that don't look quite right (looking at trap frequencies) - @cahty1006 and @BrianBostwick are looking into this currently so hopefully soon we'll either confirm everything is fine or identify the problem. We'll also add some more tests at this stage to make sure everything is consistent moving forwards! But just for now I'd be cautious of results using the dipole trap implementation.

If others are using the dipole trap then it would be good to know whether your results match your expectations!

[tevzLotric]

Hi, thanks for the response.

There is however still a slight problem I cannot get over - the intersection of a Gaussian Beam is not defined as a component, and so I cannot find a way to let the ramp change it. If I for example try the magnetic quadrupole trap instead, where the position is defined externally, the same ramp implementation works fine. I cannot find a simple way to work around this, and I think it may go back to issue #68. Is there any workaround?

[ElliotB256]

GaussianBeam implements the lerp trait, so you can just define a Ramp for the GaussianBeam component directly to change the intersection of focus, etc