Code-specific extensions

Implementing codes can provide classes that have no counterpart in the standard, e.g., additional field solvers or diagnostics. They derive these classes from the base class of the respective kind, which the classes of the standard derive from as well, so that the objects are accepted by the PICMI classes where objects of that kind are expected. Each of these base classes is part of the type alias of its kind (see Type Aliases), e.g., PICMI_Solver in PICMI_AnySolver. Classes that are only used by other code-specific classes derive from PICMI_Extension directly.

pydantic model picmistandard.PICMI_Extension[source]

Base class of code-specific classes that have no counterpart in the PICMI standard.

Implementing codes derive their own classes, e.g., additional field solvers or diagnostics, from the base class of the kind that they belong to (see below), so that these objects are accepted by the fields of the PICMI classes of that kind, e.g., a PICMI_Solver as Simulation.solver. Classes that are only used by fields of the implementing code itself derive from this class directly.

Like all PICMI classes, they validate their parameters (unknown keyword arguments are rejected, assignments are validated) and are restored as their own class when loaded from a serialized simulation.

Example:

class HybridSolver(picmistandard.PICMI_Solver):
    """A code-specific field solver"""

    grid: picmistandard.PICMI_AnyGrid
    electron_temperature: float = Field(description="Electron temperature [eV]")

simulation = Simulation(solver=HybridSolver(grid=grid, electron_temperature=10.0))
pydantic model picmistandard.PICMI_Grid[source]

Base class of the grids of the standard and of the implementing codes, accepted as Simulation.solver’s grid and other fields that take a grid.

pydantic model picmistandard.PICMI_Solver[source]

Base class of the field solvers of the standard and of the implementing codes, accepted as Simulation.solver.

pydantic model picmistandard.PICMI_Distribution[source]

Base class of the particle distributions of the standard and of the implementing codes, accepted as Species.initial_distribution.

pydantic model picmistandard.PICMI_Layout[source]

Base class of the particle layouts of the standard and of the implementing codes, accepted as the layout in Simulation.add_species.

pydantic model picmistandard.PICMI_Laser[source]

Base class of the laser profiles of the standard and of the implementing codes, accepted as the laser in Simulation.add_laser.

pydantic model picmistandard.PICMI_LaserInjection[source]

Base class of the laser injection methods of the standard and of the implementing codes, accepted as the injection method in Simulation.add_laser.

pydantic model picmistandard.PICMI_AppliedField[source]

Base class of the applied fields of the standard and of the implementing codes, accepted as Simulation.add_applied_field.

pydantic model picmistandard.PICMI_Diagnostic[source]

Base class of the diagnostics of the standard and of the implementing codes, accepted as Simulation.add_diagnostic.

pydantic model picmistandard.PICMI_Interaction[source]

Base class of the interactions of the standard and of the implementing codes, accepted as Simulation.add_interaction and Species.interactions.

Classes with analytic expressions, whose parameters are given as additional keyword arguments, derive from PICMI_ExpressionParameters, too.

pydantic model picmistandard.PICMI_ExpressionParameters[source]

Base class of classes with analytic expressions, whose parameters are given as keyword arguments.

Parameters used in the expressions can be given as additional keyword arguments. Those referenced in an expression are collected into the user_defined_kw field, which each derived class declares. Other unknown keyword arguments are still rejected. It is up to the implementing code to make sure that all parameters used in the expressions are defined.

Derived classes list the names of their fields that hold expressions (strings, possibly nested in lists or dictionaries) in _expression_fields. Keyword arguments named like a field are not collected, unless a derived class excludes that field in _parameter_names.