You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To have a more flexible way of initializing laser beams in a simulation we could introduce laser classes which are passed to the antenna or the direct initialization.
I would propose something like this:
In profiles.py define classes like
classGenericLaser(object)
def__init__(a0, w0, lambda, boost, ...):
# The class contains all information about the laser.self.a0=a0self.w0=w0self.lambda=lambdadefprofile(z,r,t):
# A function that only depends on time and space coordinatesreturnE
These objects would then be passed to LaserAntenna() or add_laser() as a parameter laser where then laser.profile(z,r,t) would be called.
For a user it would look like this
The benefit of this would be that I think it declutters the code a little since all laser parameters only live in profiles.py and that the user can define a custom laser in his input script. Plus, as all the laser information is stored in an object it could be used for e.g. a simulation preview plot etc.
The text was updated successfully, but these errors were encountered:
We want to have a function sim.add_laser(LaserObject, method="antenna", boost=BoostConverter),
where "boost" is optional. In the ideal case, the boost object would be attached to sim (e.g. sim.boost = BoostConverter) and sim.add_laser would then use this boost converter by default to boost any laser that is added to the simulation.
To have a more flexible way of initializing laser beams in a simulation we could introduce laser classes which are passed to the antenna or the direct initialization.
I would propose something like this:
In profiles.py define classes like
These objects would then be passed to
LaserAntenna()
oradd_laser()
as a parameterlaser
where then laser.profile(z,r,t) would be called.For a user it would look like this
The benefit of this would be that I think it declutters the code a little since all laser parameters only live in profiles.py and that the user can define a custom laser in his input script. Plus, as all the laser information is stored in an object it could be used for e.g. a simulation preview plot etc.
The text was updated successfully, but these errors were encountered: