UpdateStep and InitialUpdateStep

UpdateStep and InitialUpdateStep:: Blocks to define how fields are updated in a MultiField block.
InitialUpdateStep:: Used to define an update step to be performed at time = 0; Vorpal will also run InitialUpdateStep after a restore if the alsoAfterRestore flag is set to true.
UpdateStep:: For every subsequent update after InitialUpdateStep, use an UpdateStep block.

Steps to be performed at every time step are indicated between the tags:

<UpdateStep *nameOfThisStep*>

</UpdateStep>

Note

By default, steps are ordered as they appear in the input file. However, you may overrule the order by setting the parameter updateStepOrder = [step1 step2 … ].

InitalUpdateSteps does not use toDtFrac; these are updated with time 0 at initialization; and after restore (if alsoAfterRestore = true), they are updated with the current MultiField time.

Regarding toDtFrac, when MultiField is at \(t_{n-1}\) and is told to update itself to time \(t_{n}\) by calling \(\mathsf{update} \left( t_{n} \right)\), MultiField will call \(\mathsf{update} \left( t' \right)\) for all updaters in the update step, where

\[t'= t_{n – 1} (1 – \mathsf{toDtFrac}) + t_n \cdot \mathsf{toDtFrac}.\]

In other words, toDtFrac = 1 tells MultiField to update the updaters (in the update step) to its same time; whereas, toDtFrac = 0.5 updates the updaters to the half-way time.

Note

The parameter toDtFrac does not refer to a time step, but to an absolute time.

For example, suppose that an updater is in only one update step, with toDtFrac = 0.5. During the first update, that updater will be updated by only a half-time step; however, all subsequent updates will be updated by a whole time step.

Note

Field updaters may appear in more than one update step. It is common in EM simulations with particles to perform the B-update with toDtFrac = 0.5 then the E-update with toDtFrac = 1, and then the B-update with toDtFrac = 1.

Field-particle-overlap

Update steps are divided into two groups:

First group:
Contains all the update steps before the first update step with an updater that requires the field rhoJ (here the name must be rhoJ exactly).

Second group:
Remaining updaters after the first update step.

Note

The update order for updaters within the same update step is sometimes difficult to predict, because of skin/body separation. The skin updates will all be done in the order in which the updaters are listed, and the same is true for the body updates. However, some of the regions covered by the skin and body updates may differ for different updaters. For example, some updaters cannot be separated: consider a skinnable updater u1 and a non-skinnable updater u2. If updaters = [u1 u2] then u1 will be done before u2 on the skin cells of u1, while u2 will be done before u1 on the body cells of u1 (because the entire u2 update is treated as a skin update). Two updaters can both be skinnable but have different skin and body regions.

When two updaters are of the same kind, and read and write the same fields then updates should be performed in the listed order.

UpdateStep and InitialUpdateStep Parameters

kind (string, optional): What type of update step (and therefore updater and fields) are being used. If regular fields and updaters, then this attribute can be ommitted. If CrossDev fields and updaters are being used then this should be fldSlbUpdateStepCrossDev`

updaters (string vector, required): Names of updaters to be executed during this step.

messageFields (string vector): Name of the field to be messaged. Parallel processing often requires that domain boundary fields be messaged between processors. Only one field can be specified. Typically it is one of the updater’s writeFields. The dummyUpdater can be used if more than one writeField should be messaged. Periodic boundary conditions will also be applied to only this field.

toDtFrac (float, required): Updates the updaters to either the same time, or to the half-way time.

alsoAfterRestore (optional, default = false)

Specifies whether to perform this update step when restoring from a dump. This is handy, for example, for nodal fields, which can be easily computed from the Yee fields. One of:

true

false

Example Update Step Block Using the nodalE field in the MessageFields Parameter

<UpdateStep  step08>
  kind = fldSlbUpdateStepCrossDev
  toDtFrac = 1.0
  messageFields = [nodalE]
  updaters = [plasmaDielectric]
</UpdateStep>