Discontinuity for behaviour in `red-mot` at weak scattering

[ElliotB256]

It looks like the scattering force abruptly cuts off at weaker scattering. Running plot_molasses.m with more points illustrates this well: You can see that for velocities above ~22 the force abruptly cuts to zero.

I expect this is related to the Poisson implementation when the mean is low, but will investigate more.

[ElliotB256]

Additionally, it looks like there are discrete bands - (16,22)m/s and (14,16)m/s where the gradient changes sharply - eg one photon scattered?

[ElliotB256]

For reference, here is the same plot on master branch

[ElliotB256]

More information - it looks like the TwoLevel populations are at least not zero, see plotted here:

This is using the following implementation for output:

impl fmt::Display for TwoLevelPopulation {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        write!(f, "({:?},{:?},0.0)", self.ground, self.excited)
    }
}

Looks like the read_output I wrote expects a vector3, it would be nice to change that and add Display impls for all atom components. It's quite useful for debugging...

[ElliotB256]

Rates are also non zero,

[ElliotB256]

Total scattered are non zero, looks like the cutoff in behaviour occurs when the total scattered photons are less than 1.547 (suspiciously close to pi/2 - coincidence?)

[ElliotB256]

Ok, easy enough, I think it's because the sim has fluctuations off - testing now. This is good a reason to make ActualPhotonsScattered use a float, so it can correctly capture dynamics when fluctuations are disabled - right now, it tries to use the mean value, but results in no force (because no photons scattered) when expected number is too small.

[ElliotB256]

[ElliotB256]

Scattering fluctuations enabled:

[ElliotB256]

I think the 'fix' should be allowing the previous behaviour to be reproduced when disabling scattering fluctuations. This would involve storing a float value on ActualPhotonsScattered, and either filling it with the integer value from the fluctuations, or the float value from the ExpectedPhotonsScattered.

Also interesting note - the behaviour is different for fast atoms when fluctuations are considered, I wonder why. Might not neccessarily be an implementation error.

[ElliotB256]

Fixed in 729d682. Here's a side-by-side comparison of the behaviours on the two branches with fluctuations disabled:

[ElliotB256]

(Note also that the timestep labels were incorrect on the right graph)

[ElliotB256]

A few comments ago I plotted the total photons scattered within a timestep. It peaks at around 15, and the timestep is 1us, so a rate of 15 MHz. The linewidth is 6 MHz, and 15 ~ 6 MHz / 2 * 2pi. For sanity we should double check whether the value of Gamma/2 includes the 2 pi or not (ie, check units in rad/s or Hz).

[ElliotB256]

I thought some of these examples were quite interesting so I added a graph to show scattered photon rates to the molasses example. Do you think it's worth keeping this in the script?

[ElliotB256]

I noticed this in the red traces - they bend down before coming up. I believe this is due to saturation as the atoms go into resonance with the counter-propagating beams (blue rates), so atoms spend less time in the ground state to interact with the co-propagating beams via the cooling cycle

[tiffanyharte]

If it doesn't overcrowd the figure it could be nice to add a justification/visualisation of this explanation?

[MauriceZeuner]

Thank you Elliot, these diagrams give great insights! I take from it a few things:

• ActualPhotonsScattered needs to become f64, mostly for the case when the Fluctuations are disabled
• Thoroughly check when Gamma is used in Hz or angular 1/s
• implement the #display trait for all relevant components
• the master simulation takes longer for the atoms to be stopped - we, therefore, think that the red-mot branch is wrong by a certain factor?

Question to the first couple diagrams - can that problem really be solved by making ActualPhotonsScattered a float? Because - as you read from the diagrams, scattering is not close to 0, so maybe there is an additional problem?

[ElliotB256]

See comments above - already made the change to ActualPhotonsScattered. Also not sure whether master or red-mot was correct so we may need a comparison to eg numerical solution of 1D eqn in Mathematica (Xuhui had checked that previously for master, but its not a unit test so it could have broken).

[ElliotB256]

Not sure where else to put this so I'll put it here - here's simulation with fluctuations on, clearly showing it respects the Doppler limit: