MultiField

MultiField

Advanced method for simulations that enables precise user control over fields and algorithms.

A MultiField object contains a trio of sub-objects:

• Field

• FieldUpdater

• UpdateStep

The MultiField object facilitates development and application of new algorithms by providing separate specification of the data (Field), the update operations on those fields (FieldUpdater), and the algorithmic sequencing of those update operations (UpdateStep). A crucial feature of UpdateStep use is that instances of UpdateStep also govern communication during parallel processing. Additional special cases of these sub-objects also exist, including InitialUpdateStep (an update operation done once at the begining), FieldMultiUpdater (a special treatment of fields with more than one component), and PmlRegion (a special absorber boundary object for electromagnetic simulation).

This additional level of control proves useful in two general circumstances. First, it allows the user to make significant alterations in the sequencing of the traditional electrostatic and electromagnetic algorithms. These changes might include custom sources and boundary conditions, custom fields for particle forces, diagnostics, or post processing purposes, and/or custom combinations of different solvers in the same simulation. One example is to swap out the traditional electromagnetic solvers in favor of GPU accelerated solvers. A second useful circumstance is that it provides a means to create arbitrary partial differential equaion (PDE) solvers, beyond the commonly used electrostatic and electromagnetic simulations. One example provided with the software shows how to construct a solver for the heat conduction problem.

Electromagnetics Using MultiField

The traditional electromagnetic algorithm contains an electric Field and a magnetic Field, two instances of FieldUpdater: Ampere (which updates electric field) and Faraday (which updates magnetic field), and two instances of UpdateStep, one for each of the FieldUpdater. An UpdateStep can designate one-and-only-one field for parallel-process messaging. Therefore UpdateStep must be used twice, once to update-and-message the electric field, and again to update-and-message the magnetic field.

From this backbone electromagnetic algorithm, several commonly used enhancements arise and are found in the following examples:

Metallic Boundaries and the FieldUpdater deyMittraUpdater

When there are metallic boundaries, an additonal FieldUpdater (deyMittraUpdater) applies a cut-cell boundary condition to the magnetic field. This additional FieldUpdater is usually grouped in the same UpdateStep as the Faraday FieldUpdater, so there remain only two UpdateSteps.

Particles and the Magnetic Field UpdateStep

When there are particles, the magnetic field UpdateStep is usually split, so that half is done at the end of the cycle, in order to have electric and magnetic fields at the same time during the cycle for particle forces. The remaining half of the update is then done at the beginning of the next cycle, resulting in three of UpdateStep instead of two.

Particles and Assisted Particle Force Computation with Field Definitions

When there are particles, a second set of electric and magnetic Field definitions centered at the nodes may be introduced to assist in computing particle forces. The edgeToNodeVec FieldUpdater and faceToNodeVec FieldUpdater provide this functionality, and two new uses of UpdateStep, one for each new Field, are placed at the end of the cycle.

Outgoing Wave Boundary Conditions with an Open FieldUpdater

Outgoing wave boundary conditions can be applied to the electric field with an open FieldUpdater. This additional FieldUpdater is usually grouped in the same UpdateStep as the Ampere FieldUpdater.

Dielectric Loss, Matched magnetic loss, and Traditional Bulk Electrical Conductivity

Dielectric loss (complex dielectric), matched magnetic loss, and traditional bulk electrical conductivity, are added as additional uses of FieldUpdater, usually instances of STFuncUpdater, just before and just after Ampere and Faraday, and usually grouped together with the applicable field UpdateStep.

Electric Voltage and Current Sources Addition

Electric voltage and current sources are added as additional uses of FieldUpdater, usually instances of STFuncUpdater, grouped with and applied just before or just after the Ampere UpdateStep.

Blocks Contained Inside MultiField Blocks

A MultiField is described between <MultiField nameOfThisMultiField> and </MultiField> tags. In addition to MultiField parameters, the MultiField block must contain the following blocks:

Field FieldUpdater FieldUpdateStep

and may in some circumstances contain the following additional blocks:

• InitialUpdateStep

• FieldMultiUpdater

• PmlRegion

Instances of Field are not required to appear in occurances of FieldUpdater, however, any FieldUpdater must appear at least once in an UpdateStep or an InitialUpdateStep.

MultiField Parameters

kind

Type of MultiField algorithm; one of:

• Null:

  Works with VSimBase, VSimEM, VSimPD, VSimPA, and VSimVE licenses.

  no kind parameter; this is the default. The default behavior of not specifying a kind parameter for a MultiField is usually the correct choice for simulations.

• lightFrameEnvelopeMultiField:

  Works with VSimPA license.

  Implements the Laser Envelope Model. Fields can be discretized on Laser Envelope Model grids and interpolated to particle positions. When using the Envelope Model with particles, the species should be set to kind = envBoris. This lightFrameEnvelopeMultiField kind of MultiField creates special grids that have the same size and spacing as the main grid, but that move in the +x direction at the speed of light:

  • active grid:

    The position of this grid is initialized to be offset from the main grid by \(c\Delta t/2\) in the \(x\) direction. It is shifted by \(c\Delta t\) in the \(+x\) direction every timestep.

  • alternate grid:

    This grid is initially offset by \(-c\Delta t/2\), and is shifted by \(c\Delta t\) in the \(+x\) direction every timestep.

  • activeLightFrameFields

    Specifies the fields which exist on the active light frame grid.

  • alternateLightFrameFields:

    Specifies the fields which exist on the alternate light frame grid.

updateStepOrder (optional, string vector)

This specifies the order in which to execute the UpdateSteps. By default, if this attribute is not given, the UpdateSteps are executed in the order in which they are specified in the input file.

shiftUpdaters (optional, integer; default = false)

If true, the updaters in the MultiField will be shifted along with the fields. This is only relevant for updaters that rely on GridBoundary information that might shift.

restoreTimeFromField (optional, string)

Name of the field from which MultiField will get the current time when restoring from a dump. restoreTimeFromField is required for cases in which MultiField cannot automatically determine the proper field from which to restore. MultiField can make this determination if there is a field updated by an updater which is specified in an UpdateStep with toDtFrac = 1.