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
+<P>Read in a previously saved system configuration from a restart file.
-allows continuation of a previous run.  Information about what is
+This allows continuation of a previous run. However, not the entire
-stored in a restart file is given below.  Basically this operation
+state of a simulation can be saved and read back.  Details about what
-will re-create the simulation box with all its atoms and their
+information is stored in a restart file is given below.  Basically
-attributes, at the point in time it was written to the restart file by
+this operation will re-create the simulation box with all its atoms
-a previous simluation.  The simulation box will be partitioned into a
+and their attributes as well as some related global settings, at the
-regular 3d grid of rectangular bricks, one per processor, based on the
+point in time it was written to the restart file by a previous
-number of processors in the current simulation and the settings of the
+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
+units, atom style and atom style related settings (<I>id</I>, <I>map</I>,
-settings, group definitions, per-type atom settings such as mass,
+<I>sort</I>), communication settings (<I>mode</I>, <I>cutoff</I>, <I>vel</I>), timestep,
-per-atom attributes including their group assignments and molecular
+simulation box size and shape and boundary settings, group
-topology attributes, force field styles and coefficients, and
+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
+<P>One exception is that some force styles do not store their coefficient
-restart files.  Typically these are many-body potentials which read
+info in restart files.  Typically these are many-body or tabulated
-their parameters from separate files; you need to re-specify the <A HREF = "pair_style.html">pair
+potentials which read their parameters from separate files;
-style</A> and <A HREF = "pair_coeff.html">pair coeff</A> commands in
+you may need to re-specify the <A HREF = "pair_style.html">pair style</A> and
-your restart input script.  The doc pages for individual pair styles
+<A HREF = "pair_coeff.html">pair coeff</A> commands in your restart input script.
-note if this is the case.  This is also true of bond_style hybrid (and
+The doc pages for individual pair styles mention if this is the case.
-angle_style, dihedral_style, improper_style hybrid).
+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
+Read in a previously saved system configuration from a restart file.
-allows continuation of a previous run.  Information about what is
+This allows continuation of a previous run. However, not the entire
-stored in a restart file is given below.  Basically this operation
+state of a simulation can be saved and read back.  Details about what
-will re-create the simulation box with all its atoms and their
+information is stored in a restart file is given below.  Basically
-attributes, at the point in time it was written to the restart file by
+this operation will re-create the simulation box with all its atoms
-a previous simluation.  The simulation box will be partitioned into a
+and their attributes as well as some related global settings, at the
-regular 3d grid of rectangular bricks, one per processor, based on the
+point in time it was written to the restart file by a previous
-number of processors in the current simulation and the settings of the
+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
+units, atom style and atom style related settings ({id}, {map},
-settings, group definitions, per-type atom settings such as mass,
+{sort}), communication settings ({mode}, {cutoff}, {vel}), timestep,
-per-atom attributes including their group assignments and molecular
+simulation box size and shape and boundary settings, group
-topology attributes, force field styles and coefficients, and
+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
+One exception is that some force styles do not store their coefficient
-restart files.  Typically these are many-body potentials which read
+info in restart files.  Typically these are many-body or tabulated
-their parameters from separate files; you need to re-specify the "pair
+potentials which read their parameters from separate files;
-style"_pair_style.html and "pair coeff"_pair_coeff.html commands in
+you may need to re-specify the "pair style"_pair_style.html and
-your restart input script.  The doc pages for individual pair styles
+"pair coeff"_pair_coeff.html commands in your restart input script.
-note if this is the case.  This is also true of bond_style hybrid (and
+The doc pages for individual pair styles mention if this is the case.
-angle_style, dihedral_style, improper_style hybrid).
+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
+<P>Write out a binary restart file with the current state of the
-both of two modes, as a run proceeds.  A value of 0 means do not write
+simulation every so many timesteps, in either or both of two modes, as
-out any restart files.  The two modes are as follows.  If one filename
+a run proceeds.  A value of 0 means do not write out any restart
-is specified, a series of filenames will be created which include the
+files.  The two modes are as follows.  If one filename is specified, a
-timestep in the filename.  If two filenames are specified, only 2
+series of filenames will be created which include the timestep in the
-restart files will be created, with those names.  LAMMPS will toggle
+filename.  If two filenames are specified, only 2 restart files will
-between the 2 names as it writes successive restart files.
+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
+Write out a binary restart file with the current state of the
-both of two modes, as a run proceeds.  A value of 0 means do not write
+simulation every so many timesteps, in either or both of two modes, as
-out any restart files.  The two modes are as follows.  If one filename
+a run proceeds.  A value of 0 means do not write out any restart
-is specified, a series of filenames will be created which include the
+files.  The two modes are as follows.  If one filename is specified, a
-timestep in the filename.  If two filenames are specified, only 2
+series of filenames will be created which include the timestep in the
-restart files will be created, with those names.  LAMMPS will toggle
+filename.  If two filenames are specified, only 2 restart files will
-between the 2 names as it writes successive restart files.
+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
+in order to re-use that information. Details are usually given in
-<A HREF = "read_restart.html">read_restart</A> command for information about what is
+the documentation of the respective command. Also, see the
-stored in a restart file.
+<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
+in order to re-use that information. Details are usually given in
-"read_restart"_read_restart.html command for information about what is
+the documentation of the respective command. Also, see the
-stored in a restart file.
+"read_restart"_read_restart.html command for general information
+about what is stored in a restart file.
 
 :line