AtomECS
AtomECS copied to clipboard
Tophat beam profile
The code seems to assume a Gaussian beam profile, I would like to simulate a MOT geometry using laser beams with a tophat profile or more generally be able to modify the beam profile to be an abritrary function. Adding a tophat module in lasers is not sufficient as the code continues to assume a gaussian beam in other instances.
Based on the original email, here is a rough outline of an implementation following the ECS pattern:
Top hat implementation
- First, add a new component called
TopHat, which defines everything required to describe a top-hat beam profile (eg, radius). A laser beam with a top hat profile should now be created as an entity with aTopHatcomponent, instead of aGaussiancomponent. - Add a system to calculate the intensity of the laser field for all atoms in a top hat beam. This can follow the existing 'SampleLaserIntensitySystem' here, but should only perform the calculation for Cooling beams that have the
TopHatcomponent.
Now laser beams can have e.g. TopHat+Cooling, or Gaussian+Cooling, and we have the flexibility to add more in the future!
Changes required for intensity calculation code
In the original email, @Saskia461 asked if the current code assumes that all beams are gaussians - and it does! Based on this, we should rename SampleLaserIntensitySystem to SampleGaussianIntensitySystem, and add an additional SampleTopHatIntensitySystem (following e.g. how the magnetic samplers work for the different field sources).
@MauriceZeuner does this work well with your Gaussian beam changes that include focussing/waists? Anything else needed?
(This is a good test case to make sure the components are split properly - e.g. is there anything in Gaussian that is required for a general beam, or anything in other beam components that really belong in Gaussian?)
Interesting use-case! My initial thoughts:
- all beams have a power, direction and intersection, currently, that's an attribute of
GaussianBeam. We could split it up intoGaussianProfileandBeamand let theBeamhave these attributes that all such components would otherwise have in common. - the ellipticity could arguably also be part of a general
Beamrather thanGaussianBeambut not sure if other use-cases need it.
But actually, instead of defining new Systems all the time, why not work with traits? For example, you have a Beam component, that has, a trait that one could call Profile which we then implement for all gaussian and tophat beams and whatnot. That way, you'd get a: Beam<Gaussian> or Beam<Tophat> component that can still (at least I think so) be processed by an SampleLaserIntensitySystem. Or would the different types be problematic here? One could solve that with Options, though... just an idea, what do you think?
@MauriceZeuner your first bullet point is the intended pattern we should follow here. For the second, I would argue ellipticity should be part of GaussianProfile, not Beam; for instance if I defined a RectangularProfile beam then the property ellipticity would not make sense.
Re traits: I think that goes against the ECS pattern here, where the intention is behaviour by composition. There is no issue with having a large number of systems, eg one per type of profile. In the ECS approach a laser should be 'a profile component', 'a beam/direction component', 'a cooling component'/'a dipole trap component', etc.
Okay, that makes sense. I'm happy to implement this if you like, as soon as the dipole feature branch is merged - otherwise, I have to update all the branches that wait to be merged separately, which would not be time-efficient, I guess.
I would prefer to leave this for @Saskia461 to try, it seems like a good first feature
(If they would like to try it!)
I'm happy to try it, it will probably take a while longer though since I am very new to Rust and have a few other things on my to do list with deadlines.
well great, that's even better, then! @Saskia461 feel free to contact me if you get stuck somewhere or want a general overview on how the ECS works under the roof ^^