quasi-static laser solver

[tsung1029]

Hi:

I am trying to add a quasi-static section for laser evolution for codes like QuickPIC and WAKE. I am currently thinking about adding it as a new type of solver but I can imagine you can put it in the laser description as well. If anyone has a preference please let me know. Thanks!

[jlvay]

Quasistatic primarily refers to a type of field solver. A possibility would be:

class PICMI_QuasistaticSolver(_ClassWithInit):
    """
    Quasistatic field solver
      - grid: grid object to be used by the solver (grid object)
      - method: One of 'Electromagnetic', 'Electrostatic' (string)
      - l_nodal = None: Quantities are at nodes if True, staggered otherwise (boolean)
      - source_smoother = None: Smoother object to apply to the sources (smoother object)
      - field_smoother = None: Smoother object to apply to the fields (smoother object)
    """

In addition, there will need to be a way to indicate which set of particles will be part of the plasma (or background electron cloud) and which are the beam(s). This could also be automated by looking at the prescribed initial longitudinal velocity of the particles: close to the speed of light = beam species; much smaller than the speed of light = plasma / e- cloud.

[dpgrote]

This looks like a good start. Could you add two more input parameters, plasma_species and beam_species, which are the lists of the appropriate species?

Instead of treating this as a field solver, could this be an alternate Simulation class, since for example the time stepping is different than with Simulation? Then instead of method, there would be an input parameter "solver". The codes could then distinguish between ES and EM using that. Then also grid would not be needed, and the smoother inputs would be in the solver.

[jlvay]

Dave, I would rather have it as a solver. Why do you say that grid would not be needed?
Looking at the current version of PICMI, unless I missed it, the time step is not set for an electrostatic simulation. What could be done is that the time step is an explicit parameter of the simulation object, that can be set to 'auto'.

[dpgrote]

If the solver is passed in, grid would already be an attribute of the solver.

Correct, with ES field solver, the time step is not specified. However, it is already an input of the Simulation object. Presumably, for an ES simulation, if the user hasn't specified it, an error would be raised.