forked from lijiext/lammps
220 lines
10 KiB
HTML
220 lines
10 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 flag
|
|
</PRE>
|
|
<UL><LI>file = name of binary restart file to read in
|
|
<LI>flag = remap (optional)
|
|
</UL>
|
|
<P><B>Examples:</B>
|
|
</P>
|
|
<PRE>read_restart save.10000
|
|
read_restart save.10000 remap
|
|
read_restart restart.*
|
|
read_restart restart.*.mpiio
|
|
read_restart poly.*.% remap
|
|
</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. Basically this operation
|
|
will re-create the simulation box with all its atoms and their
|
|
attributes, at the point in time it was written to the restart file by
|
|
a previous simluation. The simulation box will be partitioned into a
|
|
regular 3d grid of rectangular bricks, one per processor, based on the
|
|
number of processors in the current simulation and the settings of the
|
|
<A HREF = "processors.html">processors</A> command. The partitioning can later be
|
|
changed by the <A HREF = "balance.html">balance</A> or <A HREF = "fix_balance.html">fix
|
|
balance</A> commands.
|
|
</P>
|
|
<P>IMPORTANT NOTE: Normally, restart files are written by the
|
|
<A HREF = "restart.html">restart</A> or <A HREF = "write_restart.html">write_restart</A> commands
|
|
so that all atoms in the restart file are inside the simulation box.
|
|
If this is not the case, the read_restart command will print an error
|
|
that atoms were "lost" when the file is read. This error should be
|
|
reported to the LAMMPS developers so the invalid writing of the
|
|
restart file can be fixed. If you still wish to use the restart file,
|
|
the optional <I>remap</I> flag can be appended to the read_restart command.
|
|
This should avoid the error, by explicitly remapping each atom back into
|
|
the simulation box, updating image flags for the atom appropriately.
|
|
</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.
|
|
</P>
|
|
<P>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.
|
|
</P>
|
|
<P>Certain fixes will 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>.
|
|
</P>
|
|
<P>Certain pair styles will not restart exactly, though they should
|
|
provide statistically similar results. This is because the forces
|
|
they compute depend on atom velocities, which are used at half-step
|
|
values every timestep when forces are computed. When a run restarts,
|
|
forces are initially evaluated with a full-step velocity, which is
|
|
different than if the run had continued. These pair styles include
|
|
<A HREF = "pair_gran.html">granular pair styles</A>, <A HREF = "pair_dpd.html">pair dpd</A>, and
|
|
<A HREF = "pair_lubricate.html">pair lubricate</A>.
|
|
</P>
|
|
<P>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. In this case, you can use the <A HREF = "Section_start.html#start_7">-restart command-line
|
|
switch</A> to convert a restart file to a data
|
|
file.
|
|
</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 and how many files are in it. 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.
|
|
</P>
|
|
<P>Note that P could be the total number of processors in the previous
|
|
simulation, or some subset of those processors, if the <I>fileper</I> or
|
|
<I>nfile</I> options were used when the restart file was written; see the
|
|
<A HREF = "restart.html">restart</A> and <A HREF = "write_restart.html">write_restart</A> commands
|
|
for details. 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>
|
|
<P>A restart file can also be read in parallel as one large binary file
|
|
via the MPI-IO library, assuming it was also written with MPI-IO.
|
|
MPI-IO is part of the MPI standard for versions 2.0 and above. Using
|
|
MPI-IO requires two steps. First, build LAMMPS with its MPIIO package
|
|
installed, e.g.
|
|
</P>
|
|
<PRE>make yes-mpiio # installs the MPIIO package
|
|
make g++ # build LAMMPS for your platform
|
|
</PRE>
|
|
<P>Second, use a restart filename which contains ".mpiio". Note that it
|
|
does not have to end in ".mpiio", just contain those characters.
|
|
Unlike MPI-IO dump files, a particular restart file must be both
|
|
written and read using MPI-IO.
|
|
</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. Typically these are many-body potentials which read
|
|
their parameters from separate files; you need to re-specify the <A HREF = "pair_style.html">pair
|
|
style</A> and <A HREF = "pair_coeff.html">pair coeff</A> commands in
|
|
your restart input script. 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>All settings made by the <A HREF = "pair_modify.html">pair_modify</A> command, such
|
|
as the shift and tail settings, are stored in the restart file with
|
|
the pair style. The one exception is the <A HREF = "pair_modify.html">pair_modify
|
|
compute</A> setting is not stored, since it is typically
|
|
only used for debugging purposes.
|
|
</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>Bonds that have been broken by the <A HREF = "fix_bond_break.html">fix
|
|
bond/break</A> command have disappeared from the
|
|
system. No information about these bonds is written to the restart
|
|
file.
|
|
</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 = "neighbor.html">neighbor list</A>
|
|
criteria including settings made via the
|
|
<A HREF = "neigh_modify.html">neigh_modify</A> comand, <A HREF = "dump.html">dump</A> file
|
|
output, <A HREF = "region.html">geometric regions</A>, etc.
|
|
</P>
|
|
<HR>
|
|
|
|
<P><B>Restrictions:</B>
|
|
</P>
|
|
<P>To write and read restart files in parallel with MPI-IO, the MPIIO
|
|
package must be installed.
|
|
</P>
|
|
<P><B>Related commands:</B>
|
|
</P>
|
|
<P><A HREF = "read_data.html">read_data</A>, <A HREF = "read_dump.html">read_dump</A>,
|
|
<A HREF = "write_restart.html">write_restart</A>, <A HREF = "restart.html">restart</A>
|
|
</P>
|
|
<P><B>Default:</B> none
|
|
</P>
|
|
</HTML>
|