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:
doc_solution(...)
.set_initial_condition()
The namespace ExactSolnForUnsteadyHeat
that stores the problem parameters is identical to that in the previous example.
The only change to the main function is that we record the command line arguments and store them in the namespace CommandLineArgs
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.
The 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 Problem::read(...)
.
Briefly, the dump file contains:
Problem::time_pt()->time()
;dt
, stored in the Problem's
Time
object, and their values.Data
objects in the Problem
, as well as the present and previous coordinates of all Nodes
.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.
The Problem::dump(...)
and 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
for
loop over the fixed number of timesteps in the main
function to a while
loop that checks if the continuous time, accessible via Problem::time_pt()->time()
, has reached or exceeded . This works because the Problem::dump(...)
and Problem::read(...)
functions dump and restore the value of the continuous time.dump_it(...)
and restart(...)
so that they write/read the current label for the output files to/from the restart file. Problem::dump(...)
and 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 DocInfo
object in the main
function, accessible to all member functions in the Problem
is to make the DocInfo
object a private data member of the Problem
class.A pdf version of this document is available.