diff --git a/doc/read_restart.html b/doc/read_restart.html
index dd2222866..dd904f21d 100644
--- a/doc/read_restart.html
+++ b/doc/read_restart.html
@@ -1,406 +1,406 @@
<!DOCTYPE html>
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>read_restart command — LAMMPS 15 May 2015 version documentation</title>
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
<link rel="top" title="LAMMPS 15 May 2015 version documentation" href="index.html"/>
<script src="_static/js/modernizr.min.js"></script>
</head>
<body class="wy-body-for-nav" role="document">
<div class="wy-grid-for-nav">
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
<div class="wy-side-nav-search">
<a href="Manual.html" class="icon icon-home"> LAMMPS
</a>
<div role="search">
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
<input type="text" name="q" placeholder="Search docs" />
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
</div>
</div>
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
<ul>
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
</ul>
</div>
</nav>
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
<a href="Manual.html">LAMMPS</a>
</nav>
<div class="wy-nav-content">
<div class="rst-content">
<div role="navigation" aria-label="breadcrumbs navigation">
<ul class="wy-breadcrumbs">
<li><a href="Manual.html">Docs</a> »</li>
<li>read_restart command</li>
<li class="wy-breadcrumbs-aside">
<a href="http://lammps.sandia.gov">Website</a>
<a href="Section_commands.html#comm">Commands</a>
</li>
</ul>
<hr/>
</div>
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
<div itemprop="articleBody">
<div class="section" id="read-restart-command">
<span id="index-0"></span><h1>read_restart command<a class="headerlink" href="#read-restart-command" title="Permalink to this headline">¶</a></h1>
<div class="section" id="syntax">
<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
<div class="highlight-python"><div class="highlight"><pre>read_restart file flag
</pre></div>
</div>
<ul class="simple">
<li>file = name of binary restart file to read in</li>
<li>flag = remap (optional)</li>
</ul>
</div>
<div class="section" id="examples">
<h2>Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
<div class="highlight-python"><div class="highlight"><pre>read_restart save.10000
read_restart save.10000 remap
read_restart restart.*
read_restart restart.*.mpiio
read_restart poly.*.% remap
</pre></div>
</div>
</div>
<div class="section" id="description">
<h2>Description<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
<p>Read in a previously saved system configuration from a restart file.
This allows continuation of a previous run. Details about what
information is stored (and not stored) in a restart file is given
below. Basically this operation will re-create the simulation box
with all its atoms and their attributes as well as some related global
settings, 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 class="reference internal" href="processors.html"><em>processors</em></a> command. The partitioning can later be
changed by the <a class="reference internal" href="balance.html"><em>balance</em></a> or <a class="reference internal" href="fix_balance.html"><em>fix balance</em></a> commands.</p>
<div class="admonition warning">
<p class="first admonition-title">Warning</p>
<p class="last">Normally, restart files are written by the
<a class="reference internal" href="restart.html"><em>restart</em></a> or <a class="reference internal" href="write_restart.html"><em>write_restart</em></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 <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"><em>newton</em></a> or
<a class="reference internal" href="processors.html"><em>processors</em></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"><em>fix shake</em></a> and <a class="reference internal" href="fix_langevin.html"><em>fix langevin</em></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 class="reference internal" href="pair_gran.html"><em>granular pair styles</em></a>, <a class="reference internal" href="pair_dpd.html"><em>pair dpd</em></a>, and
<a class="reference internal" href="pair_lubricate.html"><em>pair lubricate</em></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 class="reference internal" href="Section_errors.html#err-2"><span>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>-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
<a class="reference internal" href="write_restart.html"><em>write_restart</em></a> and <a class="reference internal" href="restart.html"><em>restart</em></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 class="reference internal" href="run.html"><em>run</em></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 class="reference internal" href="restart.html"><em>restart</em></a> and
<a class="reference internal" href="write_restart.html"><em>write_restart</em></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 <em>fileper</em> or
<em>nfile</em> options were used when the restart file was written; see the
<a class="reference internal" href="restart.html"><em>restart</em></a> and <a class="reference internal" href="write_restart.html"><em>write_restart</em></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>
<div class="highlight-python"><div class="highlight"><pre>make yes-mpiio # installs the MPIIO package
make g++ # build LAMMPS for your platform
</pre></div>
</div>
<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 class="docutils" />
<p>Here is the list of information included in a restart file, which
means these quantities do not need to be re-specified in the input
script that reads the restart file, though you can redefine many of
these settings after the restart file is read.</p>
<ul class="simple">
<li><a class="reference internal" href="units.html"><em>units</em></a></li>
<li><a class="reference internal" href="atom_style.html"><em>atom style</em></a> and <a class="reference internal" href="atom_modify.html"><em>atom_modify</em></a> settings id, map, sort</li>
<li><a class="reference internal" href="comm_style.html"><em>comm style</em></a> and <a class="reference external" href="comm_modify">comm_modify</a> settings mode, cutoff, vel</li>
<li><a class="reference internal" href="timestep.html"><em>timestep</em></a></li>
<li>simulation box size and shape and <a class="reference internal" href="boundary.html"><em>boundary</em></a> settings</li>
<li>atom <a class="reference internal" href="group.html"><em>group</em></a> definitions</li>
<li>per-type atom settings such as <a class="reference external" href="mass.thml">mass</a></li>
<li>per-atom attributes including their group assignments and molecular topology attributes (bonds, angles, etc)</li>
<li>force field styles (<a class="reference internal" href="pair_style.html"><em>pair</em></a>, <a class="reference internal" href="bond_style.html"><em>bond</em></a>, <a class="reference internal" href="angle_style.html"><em>angle</em></a>, etc)</li>
<li>force field coefficients (<a class="reference internal" href="pair_coeff.html"><em>pair</em></a>, <a class="reference internal" href="bond_coeff.html"><em>bond</em></a>, <a class="reference internal" href="angle_coeff.html"><em>angle</em></a>, etc) in some cases (see below)</li>
<li><a class="reference internal" href="pair_modify.html"><em>pair_modify</em></a> settings, except the compute option</li>
<li><a class="reference internal" href="special_bonds.html"><em>special_bonds</em></a> settings</li>
</ul>
<p>Here is a list of information not stored in a restart file, which
means you must re-issue these commands in your input script, after
reading the restart file.</p>
<ul class="simple">
<li><a class="reference internal" href="fix.html"><em>fix</em></a> commands (see below)</li>
<li><a class="reference internal" href="compute.html"><em>compute</em></a> commands (see below)</li>
<li><a class="reference internal" href="variable.html"><em>variable</em></a> commands</li>
<li><a class="reference internal" href="region.html"><em>region</em></a> commands</li>
<li><a class="reference internal" href="neighbor.html"><em>neighbor list</em></a> criteria including <a class="reference internal" href="neigh_modify.html"><em>neigh_modify</em></a> settings</li>
<li><a class="reference internal" href="kspace_style.html"><em>kspace_style</em></a> and <a class="reference internal" href="kspace_modify.html"><em>kspace_modify</em></a> settings</li>
<li>info for <a class="reference internal" href="thermo_style.html"><em>thermodynamic</em></a>, <a class="reference internal" href="dump.html"><em>dump</em></a>, or <a class="reference internal" href="restart.html"><em>restart</em></a> output</li>
</ul>
<p>Note that some force field styles (pair, bond, angle, etc) do not
store their coefficient info in restart files. Typically these are
many-body or tabulated potentials which read their parameters from
separate files. In these cases you will need to re-specify the “pair
<a class="reference internal" href="pair_coeff.html"><em>pair_coeff</em></a>, <a class="reference internal" href="bond_coeff.html"><em>bond_coeff</em></a>, etc
commands in your restart input script. The doc pages for individual
force field styles mention if this is the case. This is also true of
<a class="reference internal" href="pair_hybrid.html"><em>pair_style hybrid</em></a> (bond hybrid, angle hybrid, etc)
commands; they do not store coefficient info.</p>
<p>As indicated in the above list, the <a class="reference internal" href="fix.html"><em>fixes</em></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"><em>computes</em></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"><em>compute msd</em></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"><em>granular pair styles</em></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 allow 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>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"><em>fix shake</em></a> or <a class="reference internal" href="delete_bonds.html"><em>delete_bonds</em></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"><em>fix bond/break</em></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<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
<p>To write and read restart files in parallel with MPI-IO, the MPIIO
package must be installed.</p>
</div>
<div class="section" id="related-commands">
<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
<p><a class="reference internal" href="read_data.html"><em>read_data</em></a>, <a class="reference internal" href="read_dump.html"><em>read_dump</em></a>,
<a class="reference internal" href="write_restart.html"><em>write_restart</em></a>, <a class="reference internal" href="restart.html"><em>restart</em></a></p>
<p><strong>Default:</strong> none</p>
</div>
</div>
</div>
</div>
<footer>
<hr/>
<div role="contentinfo">
<p>
© Copyright .
</p>
</div>
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>.
</footer>
</div>
</div>
</section>
</div>
<script type="text/javascript">
var DOCUMENTATION_OPTIONS = {
URL_ROOT:'./',
VERSION:'15 May 2015 version',
COLLAPSE_INDEX:false,
FILE_SUFFIX:'.html',
HAS_SOURCE: true
};
</script>
<script type="text/javascript" src="_static/jquery.js"></script>
<script type="text/javascript" src="_static/underscore.js"></script>
<script type="text/javascript" src="_static/doctools.js"></script>
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
<script type="text/javascript" src="_static/js/theme.js"></script>
<script type="text/javascript">
jQuery(function () {
SphinxRtdTheme.StickyNav.enable();
});
</script>
</body>
</html>
\ No newline at end of file
diff --git a/doc/read_restart.txt b/doc/read_restart.txt
index bc1349419..84ebe0d1c 100644
--- a/doc/read_restart.txt
+++ b/doc/read_restart.txt
@@ -1,243 +1,243 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
read_restart command :h3
[Syntax:]
read_restart file flag :pre
file = name of binary restart file to read in
flag = remap (optional) :ul
[Examples:]
read_restart save.10000
read_restart save.10000 remap
read_restart restart.*
read_restart restart.*.mpiio
read_restart poly.*.% remap :pre
:pre
[Description:]
Read in a previously saved system configuration from a restart file.
This allows continuation of a previous run. Details about what
information is stored (and not stored) in a restart file is given
below. Basically this operation will re-create the simulation box
with all its atoms and their attributes as well as some related global
settings, 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
"processors"_processors.html command. The partitioning can later be
changed by the "balance"_balance.html or "fix
balance"_fix_balance.html commands.
IMPORTANT NOTE: Normally, restart files are written by the
"restart"_restart.html or "write_restart"_write_restart.html 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 {remap} 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.
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 "newton"_newton.html or
"processors"_processors.html commands. LAMMPS will issue a warning in
these cases.
Certain fixes will not restart exactly, though they should provide
statistically similar results. These include "fix
shake"_fix_shake.html and "fix langevin"_fix_langevin.html.
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
"granular pair styles"_pair_gran.html, "pair dpd"_pair_dpd.html, and
"pair lubricate"_pair_lubricate.html.
If a restarted run is immediately different than the run which
produced the restart file, it could be a LAMMPS bug, so consider
"reporting it"_Section_errors.html#err_2 if you think the behavior is
wrong.
Because restart files are binary, they may not be portable to other
machines. In this case, you can use the "-restart command-line
switch"_Section_start.html#start_7 to convert a restart file to a data
file.
Similar to how restart files are written (see the
"write_restart"_write_restart.html and "restart"_restart.html
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 "run"_run.html command and its "upto" option for how to specify
the run command so it doesn't need to be changed either.
If a "%" character appears in the restart filename, LAMMPS expects a
set of multiple files to exist. The "restart"_restart.html and
"write_restart"_write_restart.html 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.
Note that P could be the total number of processors in the previous
simulation, or some subset of those processors, if the {fileper} or
{nfile} options were used when the restart file was written; see the
"restart"_restart.html and "write_restart"_write_restart.html 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.
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.
make yes-mpiio # installs the MPIIO package
make g++ # build LAMMPS for your platform :pre
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.
:line
Here is the list of information included in a restart file, which
means these quantities do not need to be re-specified in the input
script that reads the restart file, though you can redefine many of
these settings after the restart file is read.
"units"_units.html
"atom style"_atom_style.html and "atom_modify"_atom_modify.html settings id, map, sort
"comm style"_comm_style.html and "comm_modify"_comm_modify settings mode, cutoff, vel
"timestep"_timestep.html
simulation box size and shape and "boundary"_boundary.html settings
atom "group"_group.html definitions
per-type atom settings such as "mass"_mass.thml
per-atom attributes including their group assignments and molecular topology attributes (bonds, angles, etc)
force field styles ("pair"_pair_style.html, "bond"_bond_style.html, "angle"_angle_style.html, etc)
force field coefficients ("pair"_pair_coeff.html, "bond"_bond_coeff.html, "angle"_angle_coeff.html, etc) in some cases (see below)
"pair_modify"_pair_modify.html settings, except the compute option
"special_bonds"_special_bonds.html settings :ul
Here is a list of information not stored in a restart file, which
means you must re-issue these commands in your input script, after
reading the restart file.
"fix"_fix.html commands (see below)
"compute"_compute.html commands (see below)
"variable"_variable.html commands
"region"_region.html commands
"neighbor list"_neighbor.html criteria including "neigh_modify"_neigh_modify.html settings
"kspace_style"_kspace_style.html and "kspace_modify"_kspace_modify.html settings
info for "thermodynamic"_thermo_style.html, "dump"_dump.html, or "restart"_restart.html output :ul
Note that some force field styles (pair, bond, angle, etc) do not
store their coefficient info in restart files. Typically these are
many-body or tabulated potentials which read their parameters from
separate files. In these cases you will need to re-specify the "pair
"pair_coeff"_pair_coeff.html, "bond_coeff"_bond_coeff.html, etc
commands in your restart input script. The doc pages for individual
force field styles mention if this is the case. This is also true of
"pair_style hybrid"_pair_hybrid.html (bond hybrid, angle hybrid, etc)
commands; they do not store coefficient info.
As indicated in the above list, the "fixes"_fix.html 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.
Likewise, the "computes"_fix.html 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 "compute msd"_compute_msd.html 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.
Some pair styles, like the "granular pair styles"_pair_gran.html, 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.
-LAMMPS allow 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.
+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.
If bonds (angles, etc) have been turned off by the "fix
shake"_fix_shake.html or "delete_bonds"_delete_bonds.html 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.
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.
Bonds that have been broken by the "fix
bond/break"_fix_bond_break.html command have disappeared from the
system. No information about these bonds is written to the restart
file.
:line
[Restrictions:]
To write and read restart files in parallel with MPI-IO, the MPIIO
package must be installed.
[Related commands:]
"read_data"_read_data.html, "read_dump"_read_dump.html,
"write_restart"_write_restart.html, "restart"_restart.html
[Default:] none