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. The
frequency at which restart data is written to file is governed by the
run control file variable restart_freq, which is used as follows:
restart_freq: 1000
This variable is an optional variable in that there is no default value.
If this variable is not included in the run control file, there will be
no restart data written. Restart data is output when the expression (n
mod restart f req)? = 0 evaluates to true, where n represents the time
step number. As with output data, it is important to note that data is
written at the beginning of the time step, so that the information that
is written to the restart files represents the state of the simulation
before the variables are updated at the new time step. No user input is
required in terms of selecting which restart data is required to be
written. This is automatically determined by the code based on the type
of simulation that is 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 to be written out according to the
value of restart_freq described above, 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.