Simulations of time-dependent problem can be very time consuming and it is important to be able to restart simulations, e.g. to continue a run after a system crash, etc. We shall illustrate
oomph-lib's dump/restart capabilities by re-visiting the 2D unsteady heat equation discussed in a previous example.
in the square domain , subject to the Dirichlet boundary conditions
and initial conditions
where the functions and are given.
As before, we consider the unforced case, , and choose boundary and initial conditions that are consistent with the exact solution
where and are constants, controlling the decay rate of the solution and its spatial orientation, respectively.
The figure below shows a plot of computed and exact solution at a control node as a function of time. The solid lines represent quantities computed during the original simulation; the dashed line shows the corresponding data from a second simulation that was restarted with the restart file generated at timestep 23 of the original simulation.
Most of the driver code for this example is identical to that discussed in the previous example, therefore we only discuss the modifications required to enable the dump and restart operations:
The only change to the main function is that we record the command line arguments and store them in the namespace
The rest of the main function is identical to that in the previous example.
The problem class contains the two additional member functions
The problem constructor is identical to that in the previous example.
The problem destructor is identical to that in the previous example.
This function is identical to that in the previous example.
We start by checking the validity of the command line arguments, accessible via the namespace
CommandLineArgs, as only a single command line argument is allowed. If a command line argument is provided, it is interpreted as the name of the restart file. We try to open the file and, if successful, pass the input stream to the
restart(...) function, discussed below. If no command line arguments are specified, we generate the initial conditions, essentially as in the
previous example. The only difference is that in the current version of the code, we moved the specification and initialisation of the timestep from the
main function into
set_initial_condition(). This is because in a restarted simulation, the value of
dt must be consistent with that used in the original simulation. If the simulation is restarted, the generic
Problem::read(...) function, called by
restart(...), automatically initialises the previous timestep; otherwise we have to perform the initialisation ourselves.
The Problem member function
doc_solution(...) is identical to that in the previous example, apart from the addition of a call to the new
dump_it(...) function, discussed below.
Problem::dump(...) function writes the generic
Problem data in ASCII format to the specified output file. The content of the file can therefore be inspected and, if necessary, manipulated before a restart. However, the specific content of the file is generally of little interest – it is written in a format that can be read by the corresponding function
Briefly, the dump file contains:
dt, stored in the
Timeobject, and their values.
Dataobjects in the
Problem, as well as the present and previous coordinates of all
The "raw data" is augmented by brief comments that facilitate the identification of individual entries.
In the present problem, the generic
Problem::dump(...) function is sufficient to record the current state of the simulation, therefore no additional information needs to be added to the dump file. The section Comments and Exercises below contains an exercise that illustrates how to customise the dump function to record additional parameters; the demo code with spatial adaptivity provides another example of a customised dump/restart function.
Since the restart file was written by the generic
Problem::dump(...) function, it can be read back with the generic
Problem::read(...) function. If any additional data had been recorded in the restart file, additional read statements could be added here; see Comments and Exercises.
Problem::read(...) functions write/read the generic data that is common to all
oomph-lib problems. Occasionally, it is necessary to record additional data to re-create the system's state when the simulations is restarted. We will explore this in more detail in another example. Here we provide a brief exercise that illustrates the general idea and addresses a shortcoming of the driver code: Currently the program computes the same number of timesteps, regardless of whether or not the simulation was restarted. If a simulation is restarted, the computation therefore continues past
forloop over the fixed number of timesteps in the
mainfunction to a
whileloop that checks if the continuous time, accessible via
Problem::time_pt()->time(), has reached or exceeded . This works because the
Problem::read(...)functions dump and restore the value of the continuous time.
restart(...)so that they write/read the current label for the output files to/from the restart file.
Problem::read(...); just make sure you do it in the same order in both functions. (ii) The easiest way to make the label, currently stored in the
DocInfoobject in the
mainfunction, accessible to all member functions in the
Problemis to make the
DocInfoobject a private data member of the
A pdf version of this document is available.