forked from lijiext/lammps
145 lines
6.7 KiB
HTML
145 lines
6.7 KiB
HTML
<HTML>
|
|
<CENTER><A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> - <A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A>
|
|
</CENTER>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<HR>
|
|
|
|
<H3>read_restart command
|
|
</H3>
|
|
<P><B>Syntax:</B>
|
|
</P>
|
|
<PRE>read_restart file
|
|
</PRE>
|
|
<UL><LI>file = name of binary restart file to read in
|
|
</UL>
|
|
<P><B>Examples:</B>
|
|
</P>
|
|
<PRE>read_restart save.10000
|
|
read_restart restart.*
|
|
read_restart poly.*.%
|
|
</PRE>
|
|
<PRE>
|
|
</PRE>
|
|
<P><B>Description:</B>
|
|
</P>
|
|
<P>Read in a previously saved simulation from a restart file. This
|
|
allows continuation of a previous run. Information about what is
|
|
stored in a restart file is given below.
|
|
</P>
|
|
<P>Restart files are saved in binary format to enable exact restarts,
|
|
meaning that the trajectories of a restarted run will precisely match
|
|
those produced by the original run had it continued on. Several
|
|
things can prevent exact restarts due to round-off effects, in which
|
|
case the trajectories in the 2 runs will slowly diverge. These
|
|
include running on a different number of processors or changing
|
|
certain settings such as those set by the <A HREF = "newton.html">newton</A> or
|
|
<A HREF = "processors.html">processors</A> commands. LAMMPS will issue a warning in
|
|
these cases. Certain fixes will also not restart exactly, though they
|
|
should provide statistically similar results. These include <A HREF = "fix_shake.html">fix
|
|
shake</A> and <A HREF = "fix_langevin.html">fix langevin</A>. If a
|
|
restarted run is immediately different than the run which produced the
|
|
restart file, it could be a LAMMPS bug, so consider <A HREF = "Section_errors.html#err_2">reporting
|
|
it</A> if you think the behavior is wrong.
|
|
</P>
|
|
<P>Because restart files are binary, they may not be portable to other
|
|
machines. They can be converted to ASCII data files using the
|
|
<A HREF = "Section_tools.html#restart">restart2data tool</A> in the tools
|
|
sub-directory of the LAMMPS distribution.
|
|
</P>
|
|
<P>Similar to how restart files are written (see the
|
|
<A HREF = "write_restart.html">write_restart</A> and <A HREF = "restart.html">restart</A>
|
|
commands), the restart filename can contain two wild-card characters.
|
|
If a "*" appears in the filename, the directory is searched for all
|
|
filenames that match the pattern where "*" is replaced with a timestep
|
|
value. The file with the largest timestep value is read in. Thus,
|
|
this effectively means, read the latest restart file. It's useful if
|
|
you want your script to continue a run from where it left off. See
|
|
the <A HREF = "run.html">run</A> command and its "upto" option for how to specify
|
|
the run command so it doesn't need to be changed either.
|
|
</P>
|
|
<P>If a "%" character appears in the restart filename, LAMMPS expects a
|
|
set of multiple files to exist. The <A HREF = "restart.html">restart</A> and
|
|
<A HREF = "write_restart.html">write_restart</A> commands explain how such sets are
|
|
created. Read_restart will first read a filename where "%" is
|
|
replaced by "base". This file tells LAMMPS how many processors
|
|
created the set. Read_restart then reads the additional files. For
|
|
example, if the restart file was specified as save.% when it was
|
|
written, then read_restart reads the files save.base, save.0, save.1,
|
|
... save.P-1, where P is the number of processors that created the
|
|
restart file. The processors in the current LAMMPS simulation share
|
|
the work of reading these files; each reads a roughly equal subset of
|
|
the files. The number of processors which created the set can be
|
|
different the number of processors in the current LAMMPS simulation.
|
|
This can be a fast mode of input on parallel machines that support
|
|
parallel I/O.
|
|
</P>
|
|
<HR>
|
|
|
|
<P>A restart file stores the following information about a simulation:
|
|
units and atom style, simulation box size and shape and boundary
|
|
settings, group definitions, per-type atom settings such as mass,
|
|
per-atom attributes including their group assignments and molecular
|
|
topology attributes, force field styles and coefficients, and
|
|
<A HREF = "special_bonds.html">special_bonds</A> settings. This means that commands
|
|
for these quantities do not need to be re-specified in the input
|
|
script that reads the restart file, though you can redefine settings
|
|
after the restart file is read.
|
|
</P>
|
|
<P>One exception is that some pair styles do not store their info in
|
|
restart files. The doc pages for individual pair styles note if this
|
|
is the case. This is also true of bond_style hybrid (and angle_style,
|
|
dihedral_style, improper_style hybrid).
|
|
</P>
|
|
<P>Information about <A HREF = "kspace_style.html">kspace_style</A> settings are not
|
|
stored in the restart file. Hence if you wish to use an Ewald or PPPM
|
|
solver, these commands must be re-issued after the restart file is
|
|
read.
|
|
</P>
|
|
<P>The list of <A HREF = "fix.html">fixes</A> used for a simulation is not stored in
|
|
the restart file. This means the new input script should specify all
|
|
fixes it will use. Note that some fixes store an internal "state"
|
|
which is written to the restart file. This allows the fix to continue
|
|
on with its calculations in a restarted simulation. To re-enable such
|
|
a fix, the fix command in the new input script must use the same
|
|
fix-ID and group-ID as was used in the input script that wrote the
|
|
restart file. If a match is found, LAMMPS prints a message indicating
|
|
that the fix is being re-enabled. If no match is found before the
|
|
first run or minimization is performed by the new script, the "state"
|
|
information for the saved fix is discarded. See the doc pages for
|
|
individual fixes for info on which ones can be restarted in this
|
|
manner.
|
|
</P>
|
|
<P>Bond interactions (angle, etc) that have been turned off by the <A HREF = "fix_shake.html">fix
|
|
shake</A> or <A HREF = "delete_bonds.html">delete_bonds</A> command will
|
|
be written to a restart file as if they are turned on. This means
|
|
they will need to be turned off again in a new run after the restart
|
|
file is read.
|
|
</P>
|
|
<P>Bonds that are broken (e.g. by a bond-breaking potential) are written
|
|
to the restart file as broken bonds with a type of 0. Thus these
|
|
bonds will still be broken when the restart file is read.
|
|
</P>
|
|
<P>IMPORTANT NOTE: No other information is stored in the restart file.
|
|
This means that an input script that reads a restart file should
|
|
specify settings for quantities like <A HREF = "timestep.html">timestep size</A>,
|
|
<A HREF = "thermo_style.html">thermodynamic</A>, <A HREF = "doc/neighbor.html">neighbor list</A>
|
|
criteria including settings made via the
|
|
<A HREF = "doc/neigh_modify.html">neigh_modify</A> comand, <A HREF = "dump.html">dump</A> file
|
|
output, <A HREF = "region.html">geometric regions</A>, etc.
|
|
</P>
|
|
<P><B>Restrictions:</B> none
|
|
</P>
|
|
<P><B>Related commands:</B>
|
|
</P>
|
|
<P><A HREF = "read_data.html">read_data</A>, <A HREF = "write_restart.html">write_restart</A>,
|
|
<A HREF = "restart.html">restart</A>
|
|
</P>
|
|
<P><B>Default:</B> none
|
|
</P>
|
|
</HTML>
|