jianmu
/
lammps
forked from lijiext/lammps
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

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

This commit is contained in:
sjplimp 2015-12-09 17:29:59 +00:00
parent d43c4a1bf5
commit fe6f196439
11 changed files with 223 additions and 148 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
doc/Eqs/angle_dipole_couple.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.9 KiB

10
doc/Eqs/angle_dipole_couple.tex Normal file
View File

@ -0,0 +1,10 @@
\documentclass[12pt]{article}
\begin{document}
\begin{eqnarray*}
-\vec{T_j} & = & \vec{r_{ij}} \times \vec{F_i}\\
\vec{F_j} & = & -\vec{F_i} \\
\end{eqnarray*}
\end{document}

10
doc/angle_dipole.html
View File

@ -159,15 +159,17 @@ and the reference (bond) vector r_ij:</p>
angle.</p>
<p>The torque on the dipole can be obtained by differentiating the
potential using the &#8216;chain rule&#8217; as in appendix C.3 of
<a class="reference internal" href="pair_gayberne.html#allen"><span>(Allen)</span></a>:</p>
<a class="reference internal" href="#allen"><span>(Allen)</span></a>:</p>
<img alt="_images/angle_dipole_torque.jpg" class="align-center" src="_images/angle_dipole_torque.jpg" />
<p>Example: if gamma0 is set to 0 degrees, the torque generated by
the potential will tend to align the dipole along the reference
direction defined by the (bond) vector r_ij (in other words, mu_j is
restrained to point towards atom &#8216;i&#8217;).</p>
<p>Note that the angle dipole potential does not give rise to any force,
because it does not depend on the distance between i and j (it only
depends on the angle between mu_j and r_ij).</p>
<p>The dipolar torque T_j must be counterbalanced in order to conserve
the local angular momentum. This is achieved via an additional force
couple generating a torque equivalent to the opposite of T_j:</p>
<img alt="_images/angle_dipole_couple.jpg" class="align-center" src="_images/angle_dipole_couple.jpg" />
<p>where F_i and F_j are applied on atoms i and j, respectively.</p>
<p>The following coefficients must be defined for each angle type via the
<a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a> command as in the example above, or in
the data file or restart files read by the <a class="reference internal" href="read_data.html"><em>read_data</em></a>

10
doc/angle_dipole.txt
View File

@ -50,9 +50,13 @@ the potential will tend to align the dipole along the reference
direction defined by the (bond) vector r_ij (in other words, mu_j is
restrained to point towards atom 'i').
Note that the angle dipole potential does not give rise to any force,
because it does not depend on the distance between i and j (it only
depends on the angle between mu_j and r_ij).
The dipolar torque T_j must be counterbalanced in order to conserve
the local angular momentum. This is achieved via an additional force
couple generating a torque equivalent to the opposite of T_j:
:c,image(Eqs/angle_dipole_couple.jpg)
where F_i and F_j are applied on atoms i and j, respectively.
The following coefficients must be defined for each angle type via the
"angle_coeff"_angle_coeff.html command as in the example above, or in

10
doc/fix_ave_chunk.html
View File

@ -159,7 +159,7 @@ v_name = per-atom vector calculated by an atom-style variable with name
<em>norm</em> arg = <em>all</em> or <em>sample</em> or <em>none</em> = how output on <em>Nfreq</em> steps is normalized
all = output is sum of atoms across all <em>Nrepeat</em> samples, divided by atom count
sample = output is sum of <em>Nrepeat</em> sample averages, divided by <em>Nrepeat</em>
none = output is sum of <em>Nrepeat</em> sums, divided by <em>Nrepeat</em>
none = output is sum of <em>Nrepeat</em> sample sums, divided by <em>Nrepeat</em>
<em>ave</em> args = <em>one</em> or <em>running</em> or <em>window M</em>
one = output new average value every Nfreq steps
running = output cumulative average of all previous Nfreq steps
@ -260,8 +260,8 @@ that are a multiples of <em>Nfreq</em>. The average is over <em>Nrepeat</em>
quantities, computed in the preceding portion of the simulation every
<em>Nevery</em> timesteps. <em>Nfreq</em> must be a multiple of <em>Nevery</em> and
<em>Nevery</em> must be non-zero even if <em>Nrepeat</em> is 1. Also, the timesteps
contributing to the average value cannot overlap,
i.e. Nrepeat*Nevery can not exceed Nfreq.</p>
contributing to the average value cannot overlap, i.e. Nrepeat*Nevery
can not exceed Nfreq.</p>
<p>For example, if Nevery=2, Nrepeat=6, and Nfreq=100, then values on
timesteps 90,92,94,96,98,100 will be used to compute the final average
on timestep 100. Similarly for timesteps 190,192,194,196,198,200 on
@ -363,7 +363,7 @@ atoms in the chunk. The averaged output value for the chunk on the
average over atoms across the entire <em>Nfreq</em> timescale.</p>
<p>If the <em>norm</em> setting is <em>sample</em>, the chunk value is summed over atoms
for each sample, as is the count, and an &#8220;average sample value&#8221; is
computed for each sample, i.e. Sample-sum / Sample-count. The outuput
computed for each sample, i.e. Sample-sum / Sample-count. The output
value for the chunk on the <em>Nfreq</em> timesteps is the average of the
<em>Nrepeat</em> &#8220;average sample values&#8221;, i.e. the sum of <em>Nrepeat</em> &#8220;average
sample values&#8221; divided by <em>Nrepeat</em>. In other words it is an average
@ -372,7 +372,7 @@ of an average.</p>
<em>sample</em> seting is done, except the individual &#8220;average sample values&#8221;
are &#8220;summed sample values&#8221;. A summed sample value is simply the chunk
value summed over atoms in the sample, without dividing by the number
of atoms in the sample. The outuput value for the chunk on the
of atoms in the sample. The output value for the chunk on the
<em>Nfreq</em> timesteps is the average of the <em>Nrepeat</em> &#8220;summed sample
values&#8221;, i.e. the sum of <em>Nrepeat</em> &#8220;summed sample values&#8221; divided by
<em>Nrepeat</em>.</p>

10
doc/fix_ave_chunk.txt
View File

@ -34,7 +34,7 @@ keyword = {norm} or {ave} or {bias} or {adof} or {cdof} or {file} or {overwrite}
{norm} arg = {all} or {sample} or {none} = how output on {Nfreq} steps is normalized
all = output is sum of atoms across all {Nrepeat} samples, divided by atom count
sample = output is sum of {Nrepeat} sample averages, divided by {Nrepeat}
none = output is sum of {Nrepeat} sums, divided by {Nrepeat}
none = output is sum of {Nrepeat} sample sums, divided by {Nrepeat}
{ave} args = {one} or {running} or {window M}
one = output new average value every Nfreq steps
running = output cumulative average of all previous Nfreq steps
@ -147,8 +147,8 @@ that are a multiples of {Nfreq}. The average is over {Nrepeat}
quantities, computed in the preceding portion of the simulation every
{Nevery} timesteps. {Nfreq} must be a multiple of {Nevery} and
{Nevery} must be non-zero even if {Nrepeat} is 1. Also, the timesteps
contributing to the average value cannot overlap,
i.e. Nrepeat*Nevery can not exceed Nfreq.
contributing to the average value cannot overlap, i.e. Nrepeat*Nevery
can not exceed Nfreq.
For example, if Nevery=2, Nrepeat=6, and Nfreq=100, then values on
timesteps 90,92,94,96,98,100 will be used to compute the final average
@ -270,7 +270,7 @@ average over atoms across the entire {Nfreq} timescale.
If the {norm} setting is {sample}, the chunk value is summed over atoms
for each sample, as is the count, and an "average sample value" is
computed for each sample, i.e. Sample-sum / Sample-count. The outuput
computed for each sample, i.e. Sample-sum / Sample-count. The output
value for the chunk on the {Nfreq} timesteps is the average of the
{Nrepeat} "average sample values", i.e. the sum of {Nrepeat} "average
sample values" divided by {Nrepeat}. In other words it is an average
@ -280,7 +280,7 @@ If the {norm} setting is {none}, a similar computation as for the
{sample} seting is done, except the individual "average sample values"
are "summed sample values". A summed sample value is simply the chunk
value summed over atoms in the sample, without dividing by the number
of atoms in the sample. The outuput value for the chunk on the
of atoms in the sample. The output value for the chunk on the
{Nfreq} timesteps is the average of the {Nrepeat} "summed sample
values", i.e. the sum of {Nrepeat} "summed sample values" divided by
{Nrepeat}.

30
doc/pair_srp.html
View File

@ -137,6 +137,7 @@
<li>keyword = <em>exclude</em></li>
</ul>
<pre class="literal-block">
<em>bptype</em> value = atom type for bond particles
<em>exclude</em> value = <em>yes</em> or <em>no</em>
</pre>
</div>
@ -196,18 +197,23 @@ or <a class="reference internal" href="read_restart.html"><em>read_restart</em><
is used.</p>
<div class="admonition warning">
<p class="first admonition-title">Warning</p>
<p class="last">Pair style srp considers each bond of type <em>btype</em> to
be a fictitious &#8220;particle&#8221; of type <em>bptype</em>, where <em>bptype</em> is the
largest atom type in the system. There cannot be any actual particles
assigned to this atom type. This means you must specify the number of
types in your system to be one larger would normally be the case,
e.g. via the <a class="reference internal" href="create_box.html"><em>create_box</em></a> or
<a class="reference internal" href="read_data.html"><em>read_data</em></a> commands. These ficitious &#8220;bond particles&#8221;
are inserted at the beginning of the run, and serve as placeholders
that define the position of the bonds. This allows neighbor lists to
be constructed and pairwise interactions to be computed in almost the
same way as is done for actual particles. Because bonds interact only
with other bonds, <a class="reference internal" href="pair_hybrid.html"><em>pair_style hybrid</em></a> should be used
<p>Pair style srp considers each bond of type <em>btype</em> to
be a fictitious &#8220;particle&#8221; of type <em>bptype</em>, where <em>bptype</em> is either
the largest atom type in the system, or the type set by the <em>bptype</em>
flag. Any actual existing particles with this atom type will be deleted
at the beginning of a run. This means you must specify the number of
types in your system accordingly; usually to be one larger than what
would normally be the case, e.g. via the <a class="reference internal" href="create_box.html"><em>create_box</em></a>
or by changing the header in your <a class="reference internal" href="read_data.html"><em>data file</em></a>.
The ficitious &#8220;bond particles&#8221; are inserted at the beginning of the
run, and serve as placeholders that define the position of the bonds.</p>
<blockquote>
<div>This allows neighbor lists to be constructed and pairwise interactions</div></blockquote>
<dl class="docutils">
<dt>to be computed in almost the same way as is done for actual particles.</dt>
<dd>Because bonds interact only with other bonds,</dd>
</dl>
<p class="last"><a class="reference internal" href="pair_hybrid.html"><em>pair_style hybrid</em></a> should be used
to turn off interactions between atom type <em>bptype</em> and all other
types of atoms. An error will be flagged if <a class="reference internal" href="pair_hybrid.html"><em>pair_style hybrid</em></a> is not used.</p>
</div>

25
doc/pair_srp.txt
View File

@ -17,6 +17,7 @@ btype = bond type to apply SRP interactions to (can be wildcard, see below) :l
distance = {min} or {mid} :l
zero or more keyword/value pairs may be appended :l
keyword = {exclude} :l
{bptype} value = atom type for bond particles
{exclude} value = {yes} or {no} :pre
:ule
@ -78,17 +79,19 @@ The last coefficient is optional. If not specified, the global cutoff
is used.
IMPORTANT NOTE: Pair style srp considers each bond of type {btype} to
be a fictitious "particle" of type {bptype}, where {bptype} is the
largest atom type in the system. There cannot be any actual particles
assigned to this atom type. This means you must specify the number of
types in your system to be one larger would normally be the case,
e.g. via the "create_box"_create_box.html or
"read_data"_read_data.html commands. These ficitious "bond particles"
are inserted at the beginning of the run, and serve as placeholders
that define the position of the bonds. This allows neighbor lists to
be constructed and pairwise interactions to be computed in almost the
same way as is done for actual particles. Because bonds interact only
with other bonds, "pair_style hybrid"_pair_hybrid.html should be used
be a fictitious "particle" of type {bptype}, where {bptype} is either
the largest atom type in the system, or the type set by the {bptype}
flag. Any actual existing particles with this atom type will be deleted
at the beginning of a run. This means you must specify the number of
types in your system accordingly; usually to be one larger than what
would normally be the case, e.g. via the "create_box"_create_box.html
or by changing the header in your "data file"_read_data.html.
The ficitious "bond particles" are inserted at the beginning of the
run, and serve as placeholders that define the position of the bonds.
This allows neighbor lists to be constructed and pairwise interactions
to be computed in almost the same way as is done for actual particles.
Because bonds interact only with other bonds,
"pair_style hybrid"_pair_hybrid.html should be used
to turn off interactions between atom type {bptype} and all other
types of atoms. An error will be flagged if "pair_style
hybrid"_pair_hybrid.html is not used.

131
doc/read_restart.html
View File

@ -242,65 +242,90 @@ does not have to end in &#8221;.mpiio&#8221;, 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>A restart file stores the following information about a simulation:
units, atom style and atom style related settings (<em>id</em>, <em>map</em>,
<em>sort</em>), communication settings (<em>mode</em>, <em>cutoff</em>, <em>vel</em>), 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 class="reference internal" href="special_bonds.html"><em>special_bonds</em></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 force 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; you may need to re-specify the <a class="reference internal" href="pair_style.html"><em>pair style</em></a> and <a class="reference internal" href="pair_coeff.html"><em>pair coeff</em></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 class="reference internal" href="pair_modify.html"><em>pair_modify</em></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 class="reference internal" href="pair_modify.html"><em>pair_modify compute</em></a> setting is not stored, since it is typically
only used for debugging purposes.</p>
<p>Information about <a class="reference internal" href="kspace_style.html"><em>kspace_style</em></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 class="reference internal" href="fix.html"><em>fixes</em></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 &#8220;state&#8221;
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 &#8220;state&#8221;
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 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 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>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 &#8220;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 &#8220;state&#8221; 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 &#8220;state&#8221; 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 &#8220;state&#8221; 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 &#8220;state&#8221; 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>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 class="admonition warning">
<p class="first admonition-title">Warning</p>
<p class="last">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 class="reference internal" href="timestep.html"><em>timestep size</em></a>,
<a class="reference internal" href="thermo_style.html"><em>thermodynamic</em></a>, <a class="reference internal" href="neighbor.html"><em>neighbor list</em></a>
criteria including settings made via the
<a class="reference internal" href="neigh_modify.html"><em>neigh_modify</em></a> comand, <a class="reference internal" href="dump.html"><em>dump</em></a> file
output, <a class="reference internal" href="region.html"><em>geometric regions</em></a>, etc.</p>
</div>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">

133
doc/read_restart.txt
View File

@ -134,57 +134,90 @@ written and read using MPI-IO.
:line
A restart file stores the following information about a simulation:
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.
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.
One exception is that some force 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; 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).
"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
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
the pair style. The one exception is the "pair_modify
compute"_pair_modify.html setting is not stored, since it is typically
only used for debugging purposes.
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.
Information about "kspace_style"_kspace_style.html 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.
"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
The list of "fixes"_fix.html 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.
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.
Bond interactions (angle, etc) that have been turned off by the "fix
shake"_fix_shake.html or "delete_bonds"_delete_bonds.html 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.
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.
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
@ -195,14 +228,6 @@ bond/break"_fix_bond_break.html command have disappeared from the
system. No information about these bonds is written to the restart
file.
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 "timestep size"_timestep.html,
"thermodynamic"_thermo_style.html, "neighbor list"_neighbor.html
criteria including settings made via the
"neigh_modify"_neigh_modify.html comand, "dump"_dump.html file
output, "geometric regions"_region.html, etc.
:line
[Restrictions:]

2
doc/searchindex.js
View File

File diff suppressed because one or more lines are too long