### openPMD Record Path Examples

Source: https://github.com/openpmd/openpmd-standard/blob/latest/STANDARD.md

Illustrates the structure and naming conventions for accessing scalar and vector records within the openPMD file hierarchy.

```APIDOC
Scalar Record Path:
  Format: `basePath` + `meshesPath` or `basePath` + `particlesPath` + `particleName`
  Example: `/data/meshes/temperature`
  Example: `/data/particles/electrons/charge`

Vector Record Paths (Cartesian):
  Format: `recordName/x`, `recordName/y`, `recordName/z` (where `recordName` is a sub-group)
  Example Group: `/data/meshes/F/`
    Components: `x`, `y`, `z`
  Example Group: `/data/particles/electrons/position/`
    Components: `x`, `y`, `z`

Vector Record Paths (Cylindrical):
  Format: `recordName/r`, `recordName/t`, `recordName/z` (where `recordName` is a sub-group)
  Example Group: `/data/meshes/F/`
    Components: `r`, `t`, `z`
```

--------------------------------

### Python h5py Example for Reading Particle Position

Source: https://github.com/openpmd/openpmd-standard/blob/latest/STANDARD.md

Demonstrates how to read particle position data, handling both constant and variable components, and applying unit conversions using h5py.

```Python
import h5py

def is_const_component(record_component):
    return ("value" in record_component.attrs.keys())

def get_component(group, component_name):
    record_component = group[component_name]
    unitSI = record_component.attrs["unitSI"]

    if is_const_component(record_component):
        return record_component.attrs["value"], unitSI
    else:
        return record_component.value, unitSI

f = h5py.File('example.h5')
species = f["<path_to_species_group>"]

position_x_relative, unitXRel = get_component(species, "position/x")
position_x_offset, unitXOff = get_component(species, "positionOffset/x")

x = position_x_relative * unitXRel + \
    position_x_offset * unitXOff

f.close()
```

--------------------------------

### Python h5py Example for Macroparticle Charge Calculation

Source: https://github.com/openpmd/openpmd-standard/blob/latest/EXT_ED-PIC.md

Demonstrates how to read particle charge attributes from an openPMD file using h5py, accounting for macroparticle weighting. It shows how to calculate the macroparticle charge based on the 'macroWeighted' and 'weightingPower' attributes, with an option to avoid reading the 'weighting' record for performance.

```python
import h5py

# Assume 'example.h5' is an openPMD file
f = h5py.File('example.h5')

# Navigate to the species group (replace with actual path)
species = f["<path_to_species_group>"]

# Read the charge attribute
q = species["charge"][:]

# Get unit and weighting power from attributes
u_si = q.attrs["unitSI"]
p = q.attrs["weightingPower"]

# Calculate macroparticle charge based on weighting
if q.attrs["macroWeighted"] == 0 and p != 0:
    # Read weighting if necessary
    w = species["weighting"][:]
    q_macro = u_si * q * w**p
else :
    # No need to read the weighting from disk
    q_macro = u_si * q

# q_macro now holds the charge of the macroparticles
print(f"Macroparticle charges: {q_macro}")

f.close()
```

--------------------------------

### OpenPMD chargeCorrectionParameters Attribute

Source: https://github.com/openpmd/openpmd-standard/blob/latest/EXT_ED-PIC.md

Defines the 'chargeCorrectionParameters' attribute, which provides additional details for charge correction methods. It is required when 'chargeCorrection' is not set to 'none' and includes an example parameter.

```APIDOC
chargeCorrectionParameters:
  type: (string)
  scope: required if chargeCorrection is not none
  description: additional parameters to describe the charge correction parameter
  example: period=100
```

--------------------------------

### Git Workflow for Contributing to openPMD Standard

Source: https://github.com/openpmd/openpmd-standard/blob/latest/CONTRIBUTING.md

This section outlines the essential Git commands required to contribute to the openPMD standard. It covers forking the repository, cloning the fork locally, setting up the official repository as a remote, fetching updates, creating a new branch for changes, and pushing those changes back to your fork.

```git
git clone git@github.com:<YourUserName>/openPMD-standard.git
cd openPMD-standard
git remote add mainline git@github.com:openPMD/openPMD-standard.git
git fetch mainline
git checkout mainline/upcoming-<versionNumber> -b <newBranch>
```

```git
git push -u origin
```

--------------------------------

### openPMD: Particle Record Naming Conventions

Source: https://github.com/openpmd/openpmd-standard/blob/latest/EXT_ED-PIC.md

Defines the standard naming conventions for particle properties in openPMD outputs. These conventions specify the record name, expected data types, unit dimensions, and implementation advice to ensure correct interpretation of particle data.

```APIDOC
Records per Particle Species:

- `charge`
  - type: *(floatX)* or *(intX)* or *(uintX)*
  - description: electric charge of the macroparticle or of the underlying individual particle (depending on the `macroWeighted` flag)
  - advice to implementors: must have `weightingPower = 1` and `unitDimension = (0., 0., 1., 1., 0., 0., 0.)` (charge = current * time)

- `mass`
  - type: *(floatX)* or *(intX)* or *(uintX)*
  - description: mass of the macroparticle or of the underlying individual particle (depending on the `macroWeighted` flag)
  - advice to implementors: must have `weightingPower = 1` and `unitDimension = (0., 1., 0., 0., 0., 0., 0.)` (mass)

- `weighting`
  - type: *(floatX)* or *(intX)* or *(uintX)*
  - description: the number of underlying individual particles that the macroparticles represent
  - advice to implementors: must have `weightingPower = 1`, `macroWeighted = 1`, `unitSI = 1` and `unitDimension == (0., ..., 0.)`

- `momentum/` + components (e.g., `x`, `y`, `z`)
  - type: each component in *(floatX)* or *(intX)* or *(uintX)*
  - description: component-wise momentum of the macroparticle or of the underlying individual particle (depending on the `macroWeighted` flag)
  - advice to implementors: must have `weightingPower = 1` and `unitDimension = (1., 1., -1., 0., 0., 0., 0.)` (momentum = mass * length / time)

- `position/` + components (e.g., `x`, `y`, `z`)
  - type: each component in *(floatX)* or *(intX)* or *(uintX)*
  - description: component-wise position of a particle, relative to `positionOffset`.
    - If `positionOffset` components are constant, position is relative to a global offset.
    - If `positionOffset` components are non-constant, `position` must represent the in-cell-position and `positionOffset` the cell's beginning.
  - rationale: Dividing particle position into cell beginning and in-cell position improves precision.
  - advice to implementors: must have `weightingPower = 0` and `unitDimension = (1., 0., 0., 0., 0., 0., 0.)` (length).
  - advice to implementors: *(floatX)* type is most frequent.
  - example: use only `x` and `y` in 2D.

- `positionOffset/` + components (e.g., `x`, `y`, `z`)
  - type: each component in *(floatX)* or *(intX)* or *(uintX)*
  - description: If non-constant, this must represent the position of the beginning of the cell.
    - Position of cell beginning is defined via `gridGlobalOffset + i * gridSpacing`.
    - `unitSI` of each component must be set to the corresponding lengths of the cell's edges in SI units.
  - advice to implementors: Interpretation of `position` and `positionOffset` does not alter the pure calculation of global particle position.
  - advice to implementors: must have `weightingPower = 0` and `unitDimension = (1., 0., 0., 0., 0., 0., 0.)` (length).
  - advice to implementors: *(intX)* or *(uintX)* type is most frequent.
```

--------------------------------

### openPMD Naming Conventions

Source: https://github.com/openpmd/openpmd-standard/blob/latest/STANDARD.md

Defines the allowed characters for record and component names to ensure compatibility and efficient parsing.

```APIDOC
Record/Component Names:
  Type: *(string)*
  Description: Allowed characters are `a-Z`, `0-9`, and underscore `_`.
  Regex: `\w`
```

--------------------------------

### openPMD: particlePatches Sub-group Specification

Source: https://github.com/openpmd/openpmd-standard/blob/latest/EXT_ED-PIC.md

Details the `particlePatches` sub-group, explaining its use with non-constant `positionOffset` components and how `offset` and `extent` refer to cell positions. Provides implementation advice for selecting particles by cell.

```APIDOC
particlePatches:
  description: if this sub-group is used in combination with non-constant
               components in the `positionOffset` components, the
               position for `offset` and `extent` refers to the
               position of the beginning of the cell (see `positionOffset`)
  advice to implementors: the calculation and description of
                        `position` and `positionOffset` is as in
                        the base standard still the same;
                        for non-constant components in `positionOffset`
                        (beginning-of-cell representation) one can simply
                        check `offset` and `extent` against the
                        `positionOffset` record to select particles
                        in patches "by cell"
```

--------------------------------

### openPMD Attributes and Types

Source: https://github.com/openpmd/openpmd-standard/blob/latest/STANDARD.md

Specifies key attributes for records, their data types, and descriptions, crucial for understanding temporal offsets and time step information in scientific simulations.

```APIDOC
Attribute: timeOffset
  Type: *(floatX)*
  Description: Offset with respect to the reference `time`.

Attribute: time
  Type: *(floatX)*
  Description: The reference time for the current iteration.

Attribute: dt
  Type: *(floatX)*
  Description: The latest time step used to reach this iteration.

Attribute: timeUnitSI
  Type: *(float64 / REAL8)*
  Description: Conversion factor to convert `time` and `dt` to seconds.
  Example: `1.0e-16`
```

--------------------------------

### openPMD: boundElectrons Field Specification

Source: https://github.com/openpmd/openpmd-standard/blob/latest/EXT_ED-PIC.md

Defines the `boundElectrons` field, specifying its data type (floatX, intX, uintX) and purpose for atomic physics algorithms. Includes implementation advice regarding weightingPower and unitDimension.

```APIDOC
boundElectrons:
  type: *(floatX)* or *(intX)* or *(uintX)*
  description: number of bound electrons of an ion/atom;
               to provide information to atomic physics algorithms
  advice to implementors: must have `weightingPower = 1` and
                        `unitDimension = (0., ..., 0.)` (dimensionless)
```

--------------------------------

### APIDOC: openPMD meshesPath Attributes

Source: https://github.com/openpmd/openpmd-standard/blob/latest/EXT_ED-PIC.md

This section details the additional attributes for the `meshesPath` group within the openPMD standard. It covers specifications for field solvers, boundary conditions for both fields and particles, and current smoothing techniques, including their types, scopes, and allowed values.

```APIDOC
meshesPath Attributes:

  fieldSolver:
    type: (string)
    scope: required
    description: Maxwell/field solver
    allowed values:
      - "Yee"
      - "CK" (*Cole-Karkkainen* type solvers)
      - "Lehe"
      - "DS" (*Directional Splitting*)
      - "PSTD" (*Pseudo-Spectral Time Domain*)
      - "PSATD" (*Pseudo-Spectral Analytical Time Domain*)
      - "GPSTD"
      - "other"
      - "none"

  fieldSolverParameters:
    type: (string)
    scope: required if `fieldSolver` is `other` or `GPSTD`, optional otherwise
    description: additional scheme and parameters specification for fields solvers

  fieldBoundary:
    type: array of (string) of length 2 `N`
    scope: required
    description: boundary conditions in each direction (N is dimensionality of field mesh). Strings stored in order: lower end of first axis, upper end of first axis, lower end of second axis, etc.
    allowed values:
      - "periodic"
      - "open" (optionally add scheme spec like PML, Silver-Muller in `fieldBoundaryParameters`)
      - "reflecting" (optionally add scheme spec like Neumann-type or Dirichlet-type in `fieldBoundaryParameters`)
      - "other"

  fieldBoundaryParameters:
    type: array of (string) of length 2 `N`
    scope: required if `fieldBoundary` is `other`, optional otherwise
    description: additional scheme and parameters specification for the boundary conditions

  particleBoundary:
    type: array of (string) of length 2 `N`
    scope: required
    description: boundary conditions in each direction (N is dimensionality of field mesh). Strings stored in order: lower end of first axis, upper end of first axis, lower end of second axis, etc.
    allowed values:
      - "periodic"
      - "absorbing"
      - "reflecting"
      - "reinjecting" (optionally add scheme spec like "thermal, T=1keV" in `particleBoundaryParameters`)
      - "other"
    note: currently all particles must have the same boundary condition

  particleBoundaryParameters:
    type: array of (string) of length 2 `N`
    scope: required if `particleBoundary` is `other`, optional otherwise
    description: additional scheme and parameters specification for the boundary conditions

  currentSmoothing:
    type: (string)
    scope: required
    description: applied filters to the current field after particle current deposition
    note: may become a particle record attribute in the future
    allowed values:
      - "Binomial"
      - "other"
      - "none"

  currentSmoothingParameters:
    type: (string)
    scope: required if `currentSmoothing` is not `none`
    description: additional parameters to describe the applied filter further
    note: may become a particle record attribute in the future
    example: "period=10;numPasses=4;compensator=true"

```

--------------------------------

### OpenPMD Naming Conventions: Auxiliary Fields

Source: https://github.com/openpmd/openpmd-standard/blob/latest/EXT_ED-PIC.md

Details naming conventions for auxiliary fields derived from particle species, discretized on the mesh. It specifies prefixes for quantities like current densities (J), densities, and energy, and how to denote summed quantities.

```APIDOC
auxiliary fields:
  fields derived from particle species, discretized on the mesh (cells):
    prefix them with <particleSpecies>_*:
    defined names and examples:
      J: such as electron_J for current densities created by the particles in particle species electron
      density: such as electron_density (elements per volume/area/line)
      chargeDensity: such as electron_chargeDensity (charge per volume/area/line)
      particleEnergy: kinetic energy of all particles, with their weighted contribution to a cell
      energyDensity: same as particleEnergy but divided by density
      particleCounter: ignores the shape of a particle and just checks if the position of it "corresponds" to a cell

  to store the same quantities as above, but summed for each cell over all particles in all particle species, skip the prefix and use the defined names directly
```

--------------------------------

### OpenPMD Naming Conventions: Fundamental Fields

Source: https://github.com/openpmd/openpmd-standard/blob/latest/EXT_ED-PIC.md

Outlines the naming conventions for fundamental fields in openPMD mesh records, specifically 'E' (electric field) and 'B' (magnetic field), including their types, descriptions, and required unit dimensions.

```APIDOC
fundamental fields:
  E:
    type: (floatX) or (intX) or (uintX)
    description: the electric field
    advice to implementors: a (floatX) type is likely the most frequent case for this record
    advice to implementors: must have unitDimension = (1., 1., -3., -1., 0., 0., 0.) (V/m = kg * m / (A * s^3))
  B:
    type: (floatX) or (intX) or (uintX)
    description: the magnetic field
    advice to implementors: must have unitDimension = (0., 1., -2., -1., 0., 0., 0.) (T = kg / (A * s^2))
    advice to implementors: a (floatX) type is likely the most frequent case for this record
```

--------------------------------

### openPMD Particle Patch Structure

Source: https://github.com/openpmd/openpmd-standard/blob/latest/STANDARD.md

Defines the structure for organizing particle data into patches within each particle species group. This structure facilitates parallel post-processing and data locality by logically ordering 1D arrays of attributes into local patches.

```APIDOC
ParticleSpecies.particlePatches:
  Description: Recommended sub-group for parallel post-processing of particle data.
  Purpose: Logically order 1D arrays of attributes into local patches of particles for parallel read/processing.
  Requirements: If `particlePatches` sub-group exists, the following records are required, stored in per-particle patch order.

  Records:
    - `numParticles`:
        Type: uint64 / UNSIGNED8
        Description: Number of particles in this patch. For serial, it's the global count; for parallel (e.g., MPI), it's the count per MPI rank. The sum of all entries is the global particle count.
        Examples:
          - Serial, one patch: Global number of all particles.
          - Parallel, e.g. MPI: Number of particles of a specific MPI rank.

    - `numParticlesOffset`:
        Type: uint64 / UNSIGNED8
        Description: Offset within the one-dimensional records of the particle species where the first particle in this patch is stored. For serial, it's 0; for parallel, it's the sum of particles from preceding patches.
        Examples:
          - Serial, one patch: 0
          - Parallel, e.g. MPI: Number of particles of all preceding MPI ranks' patches.

    - `offset/` + components (e.g., `x`, `y`, `z`):
        Type: floatX, intX, or uintX for each component.
        Description: Absolute position (position + positionOffset) where the particle patch begins. Defines the inclusive lower bound for positions associated with the patch. Requirements are the same as for regular record components.

    - `extent/` + components (e.g., `x`, `y`, `z`):
        Type: floatX, intX, or uintX for each component.
        Description: Extent of the particle patch. The `offset` + `extent` defines the exclusive upper bound. The union of all patches must cover the complete particle records.

```

--------------------------------

### Representing Constant Record Components

Source: https://github.com/openpmd/openpmd-standard/blob/latest/STANDARD.md

Details on how to replace record components with constant values by using sub-groups and specific attributes. This structure is used for mesh or particle records where a component's value is uniform across all entries or dimensions.

```APIDOC
Structure for Constant Component:

When a record component (e.g., `B.x`, `T`, `charge`) is constant for all values on the mesh or for all particles, replace the data set `<componentName>` with an empty sub-group `<componentName>/`.

This sub-group must host the following attributes:

- `value`: The constant value for the component.
- `shape`: A 1-dimensional array of `uint64` elements, where N is the number of dimensions of the record. It contains the number of elements of each dimension that are replaced with a constant value. For mesh-based records, the order must match `axisLabels`.

Other required attributes previously on the data set (e.g., `unitSI`, `unitDimension`) must be added to this new sub-group.

Examples:

1.  Mesh record `B` constant for `B.x` and `B.y`:
    `<basePath><meshesPath>B/`: record group (e.g., `unitDimension`)
      - `x/`: sub-group with attributes `value=<C0>`, `shape=array(..., ...)` (e.g., `unitSI`)
      - `y/`: sub-group with attributes `value=<C1>`, `shape=array(..., ...)` (e.g., `unitSI`)
      - `z`: data set (standard attributes, e.g., `unitSI`)

2.  Mesh record `T` constant:
    `<basePath><meshesPath>T/`: record group with attributes `value=<C0>`, `shape=array(...)` (e.g., `unitDimension`, `unitSI`)

3.  Particle record `charge` for species `electrons` constant:
    `<basePath><particlesPath>electrons/charge/`: record group with attribute `value=-1.0`, `shape=array(...)` (e.g., `unitSI=1.60217657e-19`, `unitDimension=array(...)`)
```

--------------------------------

### OpenPMD fieldSmoothingParameters Attribute

Source: https://github.com/openpmd/openpmd-standard/blob/latest/EXT_ED-PIC.md

Describes the 'fieldSmoothingParameters' attribute, which is required when 'fieldSmoothing' is not 'none'. It allows for additional parameters to describe the applied filter.

```APIDOC
fieldSmoothingParameters:
  type: (string)
  scope: required if fieldSmoothing is not none
  description: additional parameters to describe the applied filter further (similar to currentSmoothingParameters)
```

--------------------------------

### openPMD Root Group Attributes

Source: https://github.com/openpmd/openpmd-standard/blob/latest/STANDARD.md

Defines optional attributes for the root group ('/') of an openPMD file, indicating the presence and location of mesh and particle records, along with essential metadata about the data's origin.

```APIDOC
Root Group Attributes:

Optional Attributes:

  meshesPath
    - type: (string)
    - description: path *relative* from the `basePath` to the mesh records
    - example: `meshes/`
    - note: if this attribute is missing, the file is interpreted as if it contains *no mesh records*! If the attribute is set, the group behind it *must* exist!

  particlesPath
    - type: (string)
    - description: path *relative* from the `basePath` to the groups for each particle species and the records they include
    - example: `particles/`
    - note: if this attribute is missing, the file is interpreted as if it contains *no particle records*! If the attribute is set, the group behind it *must* exist!

Recommended Attributes:

  author
    - type: (string)
    - description: Author and contact for the information in the file
    - example: `Axel Huebl <a.huebl@hzdr.de>`

  software
    - type: (string)
    - description: the software/code/simulation that created the file
    - example: `PIConGPU`, `Warp`

  softwareVersion
    - type: (string)
    - description: the version of the software/code/simulation that created the file
    - example: `1.2.1`, `80c7551`, `rev42`

  date
    - type: (string)
    - description: date of creation in format "YYYY-MM-DD HH:mm:ss tz"
    - example: `2015-12-02 17:48:42 +0100`

Optional Attributes:

  softwareDependencies
    - type: (string)
    - description: dependencies of `software` that were used when `software` created the file, semicolon-separated list
    - examples:
      - `gcc@5.4.0;boost@1.66.0;nvcc@9.1;python@3.6;adios@1.13;hdf5@1.8.17`
      - `registry.example.com/user/repo:version`

  machine
    - type: (string)
    - description: the machine or relevant hardware that created the file; as semicolon-separated list if needed
    - example: `summit-ornl`, `pco.pixelfly-usb`

General Attribute:

  comment
    - type: (string)
    - description: an arbitrary comment for human-readable documentation
    - example: `After each time step we randomly removed 5 particles.`
```

--------------------------------

### openPMD Standard Root Group Attributes

Source: https://github.com/openpmd/openpmd-standard/blob/latest/STANDARD.md

Defines the essential attributes required for the root group of an openPMD data file, including version information, extension identifiers, and the base path for data storage.

```APIDOC
Attribute: openPMD
  Type: string
  Description: (targeted) version of the format in "MAJOR.MINOR.REVISION", see section "The versions of this standard", minor and revision must not be neglected
  Example: "1.1.0"

Attribute: openPMDextension
  Type: uint32
  Description: the bit-mask of unique IDs of applied extensions of the openPMD standard (see: *Domain-Specific Extensions*); to test for a specific extension `ID` perform a bit-wise `AND` operation on `openPMDextension`: `extension_1_used = (( openPMDextension AND ID ) == ID)`
  Note: if only one extension is used at a time, the value for `openPMDextension` is simply the `ID` of the extension
  Examples:
    - `0`: only the base standard is used
    - `1`: the base standard and the extension with ID `1` apply for the file
    - general case (discouraged in this version of the standard): `openPMDextension=0 OR <ID1> OR <ID2> OR <...>` (bit-wise `OR`)

Attribute: basePath
  Type: string
  Description: a common prefix for all data sets and sub-groups of a specific iteration; this string only indicates *how* the data is stored, to create a real path from it replace all occurrences of `%T` with the integer value of the iteration, e.g., `/data/%T` becomes `/data/100`
  Allowed Value: fixed to `/data/%T/` for this version of the standard
  Note: all the data that is formatted according to the present standard (i.e. both the meshes and the particles) is to be stored within a path of the form given by `basePath` (e.g. in the above example, the data will be stored within the path `/data/100/`). If, for various reasons, a user wants to store *additional data* that is not (or cannot be) formatted according to the present standard (e.g. fields on an unstructured mesh), this can be done be storing this data within a path that *is not* formatted according to the present standard.
```

--------------------------------

### openPMD Group Particle Species Attributes Specification

Source: https://github.com/openpmd/openpmd-standard/blob/latest/EXT_ED-PIC.md

This section details the extended attributes for the `Group` object, specifically for particle species within the openPMD standard. It covers parameters like `particleShape`, `currentDeposition`, `particlePush`, `particleInterpolation`, and `particleSmoothing`, outlining their types, scopes, descriptions, and allowed values or formats.

```APIDOC
Group Particle Species Attributes:

  particleShape:
    type: *(floatX)*
    scope: *required*
    description: The order of the particle assignment function shape.
    example values:
      - `0.` pointlike (NGP)
      - `1.` linear (CIC)
      - `2.` quadratic (TSC)
      - `3.` quadrilinear (PQS)
      - or any other positive `floating point` number

  currentDeposition:
    type: *(string)*
    scope: *required*
    description: Current deposition scheme.
    allowed values:
      - `VillaBune` ([doi:10.1016/0010-4655(92)90169-Y](http://dx.doi.org/10.1016/0010-4655(92)90169-Y))
      - `Esirkepov` ([doi:10.1016/S0010-4655(00)00228-9](http://dx.doi.org/10.1016/S0010-4655(00)00228-9))
      - `ZigZag`
      - `directBoris` (Birdsall & Langdon, *Plasma Physics via Computer Simulation*, 15-5)
      - `directMorseNielson` (Birdsall & Langdon, *Plasma Physics via Computer Simulation*, 15-5)
      - `other`
      - `none`

  currentDepositionParameters:
    type: *(string)*
    scope: *optional*
    description: Further parameters for current deposition schemes; reserved for future use.

  particlePush:
    type: *(string)*
    scope: *required*
    description: Particle-Pushing Algorithm.
    allowed values:
      - `Boris` (J.P. Boris. *Relativistic plasma simulation-optimization of a hybrid code.* USA, 1970)
      - `Vay` ([doi:10.1063/1.2837054](https://dx.doi.org/10.1063/1.2837054))
      - `free-streaming` (constantly moving with initial momentum)
      - `LLRK4` (reduced Laundau-Lifshitz pusher via RK4 and classical radiation reaction, [doi:10.1016/j.cpc.2016.04.002](https://dx.doi.org/10.1016/j.cpc.2016.04.002))
      - `none` (static particles such as probes)
      - `other`

  particleInterpolation:
    type: *(string)*
    scope: *required*
    description: Method used to interpolate fields to particle positions, as described in [doi:10.1016/j.crme.2014.07.006](http://dx.doi.org/10.1016/j.crme.2014.07.006) section 2.4.
    allowed values:
      - `uniform`: Fields interpolated directly from the staggered grid to particle positions (same interpolation order in all directions).
      - `energyConserving`: Also known as *Galerkin method*. Fields interpolated directly from the staggered grid to particle positions (reduced interpolation order in parallel direction). Energy conserving in the limit of infinitely small time steps.
      - `momentumConserving`: Fields first interpolated from staggered grid points to cell corners, then from cell corners to particle position (same order of interpolation in all directions). Momentum conserving in the limit of infinitely small time steps.
      - `other`

  particleSmoothing:
    type: *(string)*
    scope: *required*
    description: Applied transformations or smoothing filters on copied versions of the fields while interpolating those to the particle.
    allowed values:
      - `Binomial`
      - `other`
      - `none`

  particleSmoothingParameters:
    type: *(string)*
    scope: *required if `particleSmoothing` is not `none`*
    description: Additional parameters to describe the applied filter further.
    example: `period=1;numPasses=2;compensator=false`
    reserved for future use: `direction=array()`, `stride=array()`
```

--------------------------------

### openPMD Iteration Encoding Attributes

Source: https://github.com/openpmd/openpmd-standard/blob/latest/STANDARD.md

Specifies attributes required for managing time series data within openPMD files, defining how iterations are encoded either across multiple files or within groups of a single file.

```APIDOC
Iteration Encoding Attributes:

Required Attributes for the root group ('/'):

  iterationEncoding
    - type: (string)
    - description: tells if other iterations of this series are encoded in the same file or if an other `open/close` call is necessary to access other iterations.
    - allowed values:
      - `fileBased` (multiple files)
      - `groupBased` (one file)

  iterationFormat
    - type: (string)
    - description: a well defined string with the iteration `%T` placeholder defining either the series of files (`fileBased`) or the series of groups within a single file (`groupBased`) that allows to extract the iteration from it. For `fileBased` formats, the iteration must be included in the file name. The format depends on the selected `iterationEncoding` method.
    - examples:
      - for `fileBased`:
        - `filename_%T.h5` (without file system directories)
      - for `groupBased`:
        - `/data/%T/` (must be equal to and encoded in the `basePath`)

Required Attributes for the `basePath` (related to time):

  time
    - type: (floatX)
    - description: the time corresponding to this iteration. Because at one given iteration, different quantities may be defined at different times (e.g. in a staggered code), this time is defined as a global reference time for this iteration.
```

--------------------------------

### openPMD Particle Record Attributes for Macroparticles

Source: https://github.com/openpmd/openpmd-standard/blob/latest/EXT_ED-PIC.md

Defines essential attributes for particle records in openPMD when using macroparticles. These attributes clarify the nature of recorded quantities (individual particle vs. macroparticle) and how they relate to weighting factors.

```APIDOC
macroWeighted:
  type: uint32
  scope: required
  description: Indicates whether a quantity is written for the underlying individual particle (`macroWeighted = 0`) or for the full macroparticle (`macroWeighted = 1`).
  example: For a macroparticle representing 100 electrons, if the 'charge' attribute stores the charge of a single electron (-1.6e-19), `macroWeighted` must be 0. If it stores the total charge of 100 electrons (-1.6e-17), `macroWeighted` must be 1.

weightingPower:
  type: float64 / REAL8
  scope: required
  description: Specifies the power to which the `weighting` factor should be raised to convert a quantity from its individual-particle representation to its full-macroparticle representation. For example, if a macroparticle represents `w` individual particles, and a quantity `q` is for an individual particle, the macroparticle quantity `Q` is `q * w^power`, where `power` is `weightingPower`.
  example: If a macroparticle represents 100 electrons (w=100) and the individual electron charge is q=-1.6e-19, the total macroparticle charge Q is q * w^1. Thus, `weightingPower` must be 1.
```

--------------------------------

### openPMD Record Time Offset Specification

Source: https://github.com/openpmd/openpmd-standard/blob/latest/STANDARD.md

Specifies the time offset of a record relative to the basePath's time attribute, using the same unit system as the basePath's time. This is crucial for staggered grids in simulations.

```APIDOC
Record.timeOffset:
  type: floatX
  description: The offset between the time at which this record is defined and the `time` attribute of the `basePath` level. This should be written in the same unit system as `time` (i.e., it should be multiplied by `timeUnitSI` to get the actual time in seconds).
  example: In a staggered PIC code, if `time` corresponds to the electric field's time, `timeOffset` would be 0.5e-5 for magnetic field if `dt` is 1.e-5, and 0. for the electric field.
```

--------------------------------

### openPMD Unit Conversion and Dimensionality

Source: https://github.com/openpmd/openpmd-standard/blob/latest/STANDARD.md

Specifies the requirement for unit conversion factors to enable scaling data without reformatting during the write process. A common attribute, `unitSI`, is provided to transform data to the International System of Units (SI).

```APIDOC
UnitSystemsAndDimensionality:
  Description: Standard does not impose a unit system but requires a common interface for unit conversion.
  Purpose: Allow scaling data without reformatting during the write process.

  Required Attributes for each `Record` and `Record Component` (including scalar records where record is the component):
    - `unitSI`:
        Type: float64 / REAL8
        Description: A conversion factor to multiply data with to be represented in SI units.
        Rationale:
          - Can be used to scale a dimension-less `component`.
          - If the `component` is dimension-less and already in the correct scaling or SI (e.g., an index counter), set this to 1.0.
        Example: 2.99792e8 (for speed of light in m/s)

```

--------------------------------

### openPMD: protonNumber Field Specification

Source: https://github.com/openpmd/openpmd-standard/blob/latest/EXT_ED-PIC.md

Defines the `protonNumber` field, specifying its data type (floatX, intX, uintX) and purpose for atomic physics algorithms. Includes implementation advice regarding weightingPower and unitDimension.

```APIDOC
protonNumber:
  type: *(floatX)* or *(intX)* or *(uintX)*
  description: the atomic number Z of an ion/atom;
               to provide information to atomic physics algorithms
  advice to implementors: must have `weightingPower = 1` and
                        `unitDimension = (0., ..., 0.)` (dimensionless)
```

--------------------------------

### openPMD: neutronNumber Field Specification

Source: https://github.com/openpmd/openpmd-standard/blob/latest/EXT_ED-PIC.md

Defines the `neutronNumber` field, specifying its data type (floatX, intX, uintX) and purpose for atomic physics algorithms. Includes implementation advice regarding weightingPower and unitDimension.

```APIDOC
neutronNumber:
  type: *(floatX)* or *(intX)* or *(uintX)*
  description: the neutron number N = the mass number - A and
               the atomic number Z of an ion/atom;
               to provide information to atomic physics algorithms
  advice to implementors: must have `weightingPower = 1` and
                        `unitDimension = (0., ..., 0.)` (dimensionless)
```

--------------------------------

### openPMD Record Unit Dimension Specification

Source: https://github.com/openpmd/openpmd-standard/blob/latest/STANDARD.md

Defines the powers of the 7 SI base units for a record's unit, enabling automated compatibility checks. It does not represent the record's array dimensionality.

```APIDOC
Record.unitDimension:
  type: array of 7 (float64 / REAL8)
  description: Powers of the 7 base measures characterizing the record's unit in SI (length L, mass M, time T, electric current I, thermodynamic temperature theta, amount of substance N, luminous intensity J).
  rationale: Allows automated record detection, identification and compatibility checks, independent of specific names or string representations; does *not* represent if the record is a 1, 2 or 3D array.
  advice: Implement a lookup table for common quantities/units, respecting the power of base units.
  examples:
    - "m / s" is of dimension L=1, T=-1. Store array: (1., 0., -1., 0., 0., 0., 0.)
    - "N = kg * m / s^2". Store array: (1., 1., -2., 0., 0., 0., 0.)
    - Magnetic field: "T = kg / (A * s^2)". Store array: (0., 1., -2., -1., 0., 0., 0.)
    - Electric field: "V/m = kg * m / (A * s^3)". Store array: (1., 1., -3., -1., 0., 0., 0.)
    - Dimensionless (e.g., index): (0., 0., 0., 0., 0., 0., 0.)
```

--------------------------------

### OpenPMD chargeCorrection Attribute

Source: https://github.com/openpmd/openpmd-standard/blob/latest/EXT_ED-PIC.md

Specifies the 'chargeCorrection' attribute for mesh records, detailing its type, scope, and a comprehensive list of allowed correction methods with associated DOIs and references.

```APIDOC
chargeCorrection:
  type: (string)
  scope: required
  description: applied corrections to fields to ensure charge conservation
  allowed values:
    - Marder ([doi:10.1016/0021-9991(87)90043-X])
    - Langdon ([doi:10.1016/0010-4655(92)90105-8])
    - Boris (Birdsall & Langdon, *Plasma Physics via Computer Simulation*, 15-6)
    - hyperbolic (section III-B in [doi:10.1063/1.872648], [doi:http://dx.doi.org/10.1006/jcph.2000.6507], section 2.3 in [doi:10.1016/S0920-3796(96)00502-9])
    - spectral (various)
    - other
    - none
```

--------------------------------

### OpenPMD fieldSmoothing Attribute

Source: https://github.com/openpmd/openpmd-standard/blob/latest/EXT_ED-PIC.md

Details the 'fieldSmoothing' attribute for mesh records, specifying its type, scope, and that it uses the same allowed values as 'currentSmoothing' for applied field filters.

```APIDOC
fieldSmoothing:
  type: (string)
  scope: required
  description: applied field filters for E and B
  allowed values: same as for currentSmoothing
```

--------------------------------

### openPMD Mesh Record Attributes Specification

Source: https://github.com/openpmd/openpmd-standard/blob/latest/STANDARD.md

Defines the mandatory attributes for storing mesh data in the openPMD standard. This includes detailed specifications for geometry types (cartesian, thetaMode), associated parameters, data ordering (C vs. Fortran), axis labels, grid spacing, and global offsets, ensuring interoperability and correct data interpretation.

```APIDOC
MeshRecordAttributes:
  description: Required attributes for each mesh record.

  Attributes:
    geometry:
      type: string
      description: Defines the geometry of the mesh. Right-handed coordinate systems are imposed.
      allowed_values:
        - "cartesian": Standard Cartesian mesh.
        - "thetaMode": Regularly-spaced mesh in the r-z plane with Fourier decomposition in the azimuthal direction. Mesh arrays are stored as a 3D record (azimuthal mode, r, z). The first axis has length 2m+1, storing real part of mode 0, real part of mode 1, imaginary part of mode 1, etc.
        - "cylindrical": Reserved.
        - "spherical": Reserved.
        - "other": Other geometry types.

    geometryParameters:
      type: string
      description: Additional parameters for the geometry, separated by ';'. Required for 'thetaMode' geometry.
      examples:
        - "m=3;imag=+" (for thetaMode with 3 modes and '+' sign for imaginary part definition)

    dataOrder:
      type: string
      description: Specifies the ordering of elements in 1D arrays for N-dimensional data, matching the writing code's index-operator definition.
      rationale: Addresses differences in memory layout between C (row-major) and Fortran (column-major).
      allowed_values:
        - "C": Data written by C, C++, Python, Java.
        - "F": Data written by Fortran.
      notes: Can be omitted for 1D records.

    axisLabels:
      type: 1D array of strings
      description: Ordering of labels for the mesh geometry dimensions. The order must match the writing code's index-operator definition.
      advice_to_implementors: Query 'dataOrder' to invert access if necessary.
      examples:
        - ["z", "y", "x"] for 3D Cartesian C-style write (dataOrder='C')
        - ["y", "x"] for 2D Cartesian C-style write (dataOrder='C')
        - ["x", "y"] for 2D Cartesian Fortran-style write (dataOrder='F')
        - ["r", "z"] for thetaMode Fortran-style write (dataOrder='F')

    gridSpacing:
      type: 1D array of floatX
      description: Spacing of grid points along each dimension in simulation units. Refers to the spacing of the written record, which may be down-sampled.
      advice_to_implementors: Order must be identical to 'axisLabels'.

    gridGlobalOffset:
      type: 1D array of float64 / REAL8
      description: Start position of the current domain of the simulation.
      advice_to_implementors: Order must be identical to 'axisLabels'.

```

--------------------------------

### OpenPMD Reserved Attributes

Source: https://github.com/openpmd/openpmd-standard/blob/latest/EXT_ED-PIC.md

Defines reserved attributes for future use within the openPMD standard, specifically for array-like properties such as direction and stride.

```APIDOC
reserved for future use:
  direction=array()
  stride=array()
```

=== COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.