Open Saskia461 opened 3 years ago
Based on the original email, here is a rough outline of an implementation following the ECS pattern:
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 a TopHat
component, instead of a Gaussian
component.TopHat
component.Now laser beams can have e.g. TopHat
+Cooling
, or Gaussian
+Cooling
, and we have the flexibility to add more in the future!
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:
GaussianBeam
. We could split it up into GaussianProfile
and Beam
and let the Beam
have these attributes that all such components would otherwise have in common.Beam
rather than GaussianBeam
but 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 ^^
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.