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 <em>remap</em> 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>
</div>
<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 class="reference internal" href="newton.html"><span class="doc">newton</span></a> or
<a class="reference internal" href="processors.html"><span class="doc">processors</span></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 class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> and <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></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
<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 class="reference internal" href="Section_errors.html#err-2"><span class="std std-ref">reporting it</span></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 class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">-restart command-line switch</span></a> to convert a restart file to a data
file.</p>
<p>Similar to how restart files are written (see the
<p>As indicated in the above list, the <a class="reference internal" href="fix.html"><span class="doc">fixes</span></a> used for a
simulation are not stored in the restart file. This means the new
input script should specify all fixes it will use. However, 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>Likewise, the <a class="reference internal" href="fix.html"><span class="doc">computes</span></a> used for a simulation are not stored
in the restart file. This means the new input script should specify
all computes it will use. However, some computes create a fix
internally to store “state” information that persists from timestep to
timestep. An example is the <a class="reference internal" href="compute_msd.html"><span class="doc">compute msd</span></a> command
which uses a fix to store a reference coordinate for each atom, so
that a displacement can be calculated at any later time. If the
compute command in the new input script uses the same compute-ID and
group-ID as was used in the input script that wrote the restart file,
then it will create the same fix in the restarted run. This means the
re-created fix will be re-enabled with the stored state information as
described in the previous paragraph, so that the compute can continue
its calculations in a consistent manner.</p>
<p>Some pair styles, like the <a class="reference internal" href="pair_gran.html"><span class="doc">granular pair styles</span></a>, also
use a fix to store “state” information that persists from timestep to
timestep. In the case of granular potentials, it is contact
information between pairs of touching particles. This info will also
be re-enabled in the restart script, assuming you re-use the same
granular pair style.</p>
<p>LAMMPS allows bond interactions (angle, etc) to be turned off or
deleted in various ways, which can affect how their info is stored in
a restart file.</p>
<p>If bonds (angles, etc) have been turned off by the <a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> or <a class="reference internal" href="delete_bonds.html"><span class="doc">delete_bonds</span></a> command,
their info 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 class="reference internal" href="fix_bond_break.html"><span class="doc">fix bond/break</span></a> command have disappeared from the
system. No information about these bonds is written to the restart
file.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>To write and read restart files in parallel with MPI-IO, the MPIIO
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.