Appendix: Restarting Cases
When running a simulation, it is often useful to permanently save solution data at selected time steps so that, if necessary, the simulation may be re-initiated from one of these time steps. This data is referred to as restart data and consists of the discrete numerical solution for the primitive variables at all cell centers in the domain as well as the mass flux at all faces in the domain. Because all boundary condition data for the primitive variables is derived from cell-centered data, boundary data located at the center of faces on the boundaries for the primitive variables is not included in the restart data.
Restart Data
The directory where restart data is written is called /restart and can
be found in the directory where the simulation was initiated. Restart data
can be scheduled according to either the time step number or the physical
solution time, as described in Choosing Output Cadence.
A time-step cadence is requested as follows:
restart_freq: 1000
Alternatively, a physical-time cadence is requested as follows:
restart_freq_dt: 0.1
Both frequency options are optional and have no default value. If neither
option is included in the run control file, periodic restart output is
disabled. Only one of restart_freq and restart_freq_dt should be
specified. Restart data is output when (n mod restart_freq) = 0 for the
time-step form. For the physical-time form, restart data is output at the
first accepted state that reaches or passes an exact multiple of
restart_freq_dt. Restart output is not written for the initial state.
The physical-time comparison uses restart_freq_dt_tol to account for
roundoff. Its default value is:
restart_freq_dt_tol: 1.0e-8
As with field output, restart data represents the state at the beginning of the next time step, before the variables are updated again. No user input is required in terms of selecting which restart variables are written. This is automatically determined by the code based on the type of simulation being performed.
The run control file variable restart_modulo can be used to limit the
amount of data that will accumulate in the restart directory. This
variable is used as follows (default value shown):
restart_modulo: 0
Valid values include any integral numeric value greater than or equal to zero. When restart data is scheduled according to the selected restart cadence, the following formats are used for the file names:
variable_hdf5.extension
If restart_modulo=0, the extension is given the same value as the time
step number. In this case, unique file names for each variable will be
written to the /restart directory for each time step for which data is
requested. Thus, for example, if one wanted to save restart data for
every 1000th time step for the entire simulation, one would set
restart_modulo=0 and restart_freq=1000. When the value of restart_modulo
is greater than zero, the extension is computed by the expression
(extension = n mod restart_modulo). Thus, if one wanted to save data
every 1000th time step for the most recent 10000 time steps, one would
set restart_modulo=10000 and restart_freq=1000. In this case, the
extension number would cycle between the values 1000, 2000, 3000, 4000,
5000, 6000, 7000, 8000, 9000, 0 for the duration of the simulation. To
perform a restart from saved data, place the restart time step number
after the case name in a manner like the following:
mpirun -np 1 stream -q solution caseName 1000 >& caseName.log &
In this example, the code will use the restart data from the files
/restart/\* hdf5.1000 for the simulation initial condition rather than
the initial condition information present in the run control file.
Restart Compressible Simulation from an Incompressible Simulation
There are certain situations in which it is sometimes helpful to run an
incompressible simulation to establish a good flow field from a poor
initial condition before proceeding on to the final compressible
simulation. While this procedure is in general not necessary in
practice, it can sometimes be used as a measure of last resort for
getting a simulation started. Because the data in the /restart directory
for an incompressible simulation does not include a file for
temperature, one must use either the run control file variable
initialCondition or initialConditionRegions to provide this information
upon restart in compressible mode. It is important that one include all
required entries in the selected initial condition variable to avoid
code error handling (the code will complain that insufficient
information has been provided for a compressible initial condition and
terminate), however, only the temperature values will be obtained from
the initial condition. All other values will be obtained from the
incompressible simulation restart files. Upon restart, one should see
the following message in the log file:
WARNING: No temperature restart file. Using temperature initial
condition value from .vars file.
It is important when using this restart technique that one uses a temperature initial condition that in conjunction with the pressure values in the pressure restart file results in a density value that is close to that of the incompressible simulation, to avoid restart shock. It should also be noted that this technique can only be used to restart from an incompressible simulation to a pure-fluid compressible simulation. Restart to compressible mixture material simulations is not currently supported.
Restarting a Turbulent Simulation from a Laminar Simulation
In some instances, if one suspects that the turbulence equations are
having difficulty at start-up due to a poor initial condition, it may be
helpful to establish a good flow field by running a laminar flow
simulation before proceeding on to the final turbulent flow simulation.
This can be accomplished by restarting in the normal manner, but because
the restart files for the turbulence quantities are not available from
the laminar simulation, one must provide this information from either
the run control file variables initialCondition or
initialConditionRegions. It is important to include all required entries
in the selected initial condition variables to avoid code error handling
features, however, only the turbulence quantities will be obtained from
the initial condition. All other values will be obtained from the
laminar simulation restart files. Upon restart, one should see the
following messages:
WARNING: No k restart file. Using k initial condition value from
.vars file.
WARNING: No omega restart file. Using omega initial condition value
from .vars file.
Restarting a BDF2 Simulation from a BDF Simulation
In certain instances, one may be required to restart a second-order BDF2
simulation from a first-order BDF simulation. Such may be the case, for
example, if one has a complex geometry where it is difficult to assign a
good initial condition. Due to the poor initial condition, it may be
impossible for the solution to stabilize when using second-order time
integration. In this case, one would first run a certain number of time
steps using first-order time integration, writing out restart data at an
appropriate point, and then restart using second-order time integration.
No active input by the user is required to execute this process, beyond
the normal restart procedure, however, it is important to understand how
the code handles this situation.
In a normal BDF2 run, when restart data is written to file, data is
written for both the current time step and well as the previous time
step, because this second-order time integration scheme employs two
temporal solution levels. When a BDF2 restart is being made from a BDF
simulation, data at the previous time level is no longer available. To
circumvent this problem, the code assumes a zero temporal gradient
condition upon restart and thus assigns the previous time level data
from the current time level data which is available. Temporal accuracy
is thus lost at the initiation of the restart.