Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tophat beam profile #52

Open
Saskia461 opened this issue Jun 1, 2021 · 9 comments
Open

Tophat beam profile #52

Saskia461 opened this issue Jun 1, 2021 · 9 comments
Assignees
Labels
enhancement New feature or request

Comments

@Saskia461
Copy link

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 ElliotB256 added the enhancement New feature or request label Jun 1, 2021
@ElliotB256
Copy link
Collaborator

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 a TopHat component, instead of a Gaussian component.
  • 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 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!

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
Copy link
Collaborator

@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
Copy link
Collaborator

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 into GaussianProfile and Beam and let the Beam have these attributes that all such components would otherwise have in common.
  • the ellipticity could arguably also be part of a general 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?

@ElliotB256
Copy link
Collaborator

@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
Copy link
Collaborator

MauriceZeuner commented Jun 2, 2021

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
Copy link
Collaborator

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

@ElliotB256
Copy link
Collaborator

(If they would like to try it!)

@Saskia461
Copy link
Author

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
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants