TeamAtomECS / AtomECS

Cold atom simulation code
GNU General Public License v3.0
45 stars 11 forks source link

Tophat beam profile #52

Open Saskia461 opened 3 years ago

Saskia461 commented 3 years ago

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.

ElliotB256 commented 3 years ago

Based on the original email, here is a rough outline of an implementation following the ECS pattern:

Top hat implementation

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).

ElliotB256 commented 3 years ago

@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?)

MauriceZeuner commented 3 years ago

Interesting use-case! My initial thoughts:

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?

ElliotB256 commented 3 years ago

@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.

MauriceZeuner commented 3 years ago

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.

ElliotB256 commented 3 years ago

I would prefer to leave this for @Saskia461 to try, it seems like a good first feature

ElliotB256 commented 3 years ago

(If they would like to try it!)

Saskia461 commented 3 years ago

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.

MauriceZeuner commented 3 years ago

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 ^^