git-svn-id: svn://svn.icms.temple.edu/lammps-ro/trunk@13630 f3b2605a-c512-4ea7-a41b-209d697bcdaa

doc/read_restart.html

@@ -30,14 +30,16 @@ read_restart poly.*.% remap
 </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
+<P>Read in a previously saved system configuration from a restart file.
+This allows continuation of a previous run. However, not the entire
+state of a simulation can be saved and read back.  Details about what
+information 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 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 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.
@@ -137,22 +139,25 @@ written and read using MPI-IO.
 <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
+units, atom style and atom style related settings (<I>id</I>, <I>map</I>,
+<I>sort</I>), communication settings (<I>mode</I>, <I>cutoff</I>, <I>vel</I>), timestep,
+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 - in most cases - force field 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>One exception is that some force styles do not store their coefficient
+info in restart files.  Typically these are many-body or tabulated
+potentials which read their parameters from separate files;
+you may 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 mention 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

doc/read_restart.txt

@@ -27,14 +27,16 @@ read_restart poly.*.% remap :pre
 
 [Description:]
 
-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
+Read in a previously saved system configuration from a restart file.
+This allows continuation of a previous run. However, not the entire
+state of a simulation can be saved and read back.  Details about what
+information 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 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.
@@ -134,22 +136,25 @@ written and read using MPI-IO.
 :line
 
 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
+units, atom style and atom style related settings ({id}, {map},
+{sort}), communication settings ({mode}, {cutoff}, {vel}), timestep,
+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 - in most cases - force field coefficients, and
 "special_bonds"_special_bonds.html 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.
 
-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 "pair
-style"_pair_style.html and "pair coeff"_pair_coeff.html 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).
+One exception is that some force styles do not store their coefficient
+info in restart files.  Typically these are many-body or tabulated
+potentials which read their parameters from separate files;
+you may need to re-specify the "pair style"_pair_style.html and
+"pair coeff"_pair_coeff.html commands in your restart input script.
+The doc pages for individual pair styles mention if this is the case.
+This is also true of bond_style hybrid (and angle_style, dihedral_style,
+improper_style hybrid).
 
 All settings made by the "pair_modify"_pair_modify.html command, such
 as the shift and tail settings, are stored in the restart file with

doc/restart.html

@@ -47,13 +47,14 @@ restart v_mystep poly.restart
 </PRE>
 <P><B>Description:</B>
 </P>
-<P>Write out a binary restart file every so many timesteps, in either or
-both of two modes, as a run proceeds.  A value of 0 means do not write
-out any restart files.  The two modes are as follows.  If one filename
-is specified, a series of filenames will be created which include the
-timestep in the filename.  If two filenames are specified, only 2
-restart files will be created, with those names.  LAMMPS will toggle
-between the 2 names as it writes successive restart files.
+<P>Write out a binary restart file with the current state of the
+simulation every so many timesteps, in either or both of two modes, as
+a run proceeds.  A value of 0 means do not write out any restart
+files.  The two modes are as follows.  If one filename is specified, a
+series of filenames will be created which include the timestep in the
+filename.  If two filenames are specified, only 2 restart files will
+be created, with those names.  LAMMPS will toggle between the 2 names
+as it writes successive restart files.
 </P>
 <P>Note that you can specify the restart command twice, once with a
 single filename and once with two filenames.  This would allow you,

doc/restart.txt

@@ -37,13 +37,14 @@ restart v_mystep poly.restart :pre
 
 [Description:]
 
-Write out a binary restart file every so many timesteps, in either or
-both of two modes, as a run proceeds.  A value of 0 means do not write
-out any restart files.  The two modes are as follows.  If one filename
-is specified, a series of filenames will be created which include the
-timestep in the filename.  If two filenames are specified, only 2
-restart files will be created, with those names.  LAMMPS will toggle
-between the 2 names as it writes successive restart files.
+Write out a binary restart file with the current state of the
+simulation every so many timesteps, in either or both of two modes, as
+a run proceeds.  A value of 0 means do not write out any restart
+files.  The two modes are as follows.  If one filename is specified, a
+series of filenames will be created which include the timestep in the
+filename.  If two filenames are specified, only 2 restart files will
+be created, with those names.  LAMMPS will toggle between the 2 names
+as it writes successive restart files.
 
 Note that you can specify the restart command twice, once with a
 single filename and once with two filenames.  This would allow you,

doc/write_restart.html

@@ -83,9 +83,10 @@ 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
-<A HREF = "read_restart.html">read_restart</A> command for information about what is
-stored in a restart file.
+in order to re-use that information. Details are usually given in
+the documentation of the respective command. Also, see the
+<A HREF = "read_restart.html">read_restart</A> command for general information
+about what is stored in a restart file.
 </P>
 <HR>
 

doc/write_restart.txt

@@ -76,9 +76,10 @@ 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"_read_restart.html command for information about what is
-stored in a restart file.
+in order to re-use that information. Details are usually given in
+the documentation of the respective command. Also, see the
+"read_restart"_read_restart.html command for general information
+about what is stored in a restart file.
 
 :line