write_restart command
Purpose
Writes a restart file containing the current status of the simulation
Note
This command is supported by Aspherix GPU.Syntax
write_restart file keyword value
Keywords |
Description |
|---|---|
file |
obligatory; no keyword; name of file to write restart information to |
number of restart files to be written in parallel simulations if % is used; can be
used to reduce the number of restart files for massively parallel simulations
range: [1,number of processors]; default: number of processors
|
Examples
write_restart restart.equil
write_restart poly.%.* nfile 10
Description
Write a binary restart file of the current state of the simulation.
During a long simulation, the restart command is typically used to output restart files periodically. The write_restart command is useful after a minimization or whenever you wish to write out a single current restart file.
Similar to dump files, the restart filename can contain
two wild-card characters. If a * appears in the filename, it is
replaced with the current timestep value. If % character appears
in the filename, then one file is written by each processor and the
% character is replaced with the processor ID from 0 to P-1. An
additional file with the % replaced by base is also written, which
contains global information. For example, the files written for
filename restart.% would be restart.base, restart.0, restart.1, …
restart.P-1. This creates smaller files and can be a fast mode of
output and subsequent input on parallel machines that support parallel
I/O. The optional nfile keyword discussed below can
alter the number of files written.
Restart files can be read by a read_restart
command to restart a simulation from a particular state. Because the
file is binary (to enable exact restarts), it may not be readable on
another machine. In this case, you can use the -r command-line option to
convert a restart file to a data file.
Warning
Although the purpose of restart files is to enable restarting a simulation from where it left off, not all information about a simulation is stored in the file. For example, the list of fixes that were specified during the initial run is not stored, which means the new input script must specify any fixes you want to use. Even when restart information is stored in the file, as it is for some fixes, commands may need to be re-specified in the new input script, in order to re-use that information. See the read_restart command for information about what is stored in a restart file.
The optional nfile keyword can be used in conjunction
with the % wildcard character in the specified restart file name.
As explained above, the % character causes the restart file to be
written in pieces, one piece for each of P processors. By default P =
the number of processors the simulation is running on. The nfile
keyword can be used to set P to a smaller value, which can
be more efficient when running on a large number of processors.
The nfile keyword sets P to the specified Nf value. For example, if
Nf = 4, and the simulation is running on 100 processors, 4 files will
be written, by processors 0,25,50,75. Each will collect information
from itself and the next 24 processors and write it to a restart file.
Restrictions
This command requires inter-processor communication to migrate atoms before the restart file is written. This means that your system must be ready to perform a simulation before using this command (force fields setup, atom masses initialized, etc).