diff --git a/doc/pair_lj_soft.html b/doc/pair_lj_soft.html
index 419807db5..4bc56286a 100644
--- a/doc/pair_lj_soft.html
+++ b/doc/pair_lj_soft.html
@@ -1,256 +1,280 @@
<HTML>
<CENTER><A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> - <A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A>
</CENTER>
<HR>
<H3>pair_style lj/cut/soft command
</H3>
<H3>pair_style lj/cut/soft/omp command
</H3>
<H3>pair_style lj/cut/coul/cut/soft command
</H3>
<H3>pair_style lj/cut/coul/cut/soft/omp command
</H3>
<H3>pair_style lj/cut/coul/long/soft command
</H3>
<H3>pair_style lj/cut/coul/long/soft/omp command
</H3>
<H3>pair_style lj/cut/tip4p/long/soft command
</H3>
<H3>pair_style lj/cut/tip4p/long/soft/omp command
</H3>
+<H3>pair_style lj/charmm/coul/long/soft command
+</H3>
+<H3>pair_style lj/charmm/coul/long/soft/omp command
+</H3>
<H3>pair_style coul/cut/soft command
</H3>
<H3>pair_style coul/cut/soft/omp command
</H3>
<H3>pair_style coul/long/soft command
</H3>
<H3>pair_style coul/long/soft/omp command
</H3>
<H3>pair_style tip4p/long/soft command
</H3>
<H3>pair_style tip4p/long/soft/omp command
</H3>
<P><B>Syntax:</B>
</P>
<PRE>pair_style style args
</PRE>
-<UL><LI>style = <I>lj/cut/soft</I> or <I>lj/cut/coul/cut/soft</I> or <I>lj/cut/coul/long/soft</I> or <I>lj/cut/tip4p/long/soft</I> or <I>coul/cut/soft</I> or <I>coul/long/soft</I> or <I>tip4p/long/soft</I>
+<UL><LI>style = <I>lj/cut/soft</I> or <I>lj/cut/coul/cut/soft</I> or <I>lj/cut/coul/long/soft</I> or <I>lj/cut/tip4p/long/soft</I> or <I>lj/charmm/coul/long/soft</I> or <I>coul/cut/soft</I> or <I>coul/long/soft</I> or <I>tip4p/long/soft</I>
<LI>args = list of arguments for a particular style
</UL>
<PRE> <I>lj/cut/soft</I> args = n alpha_lj cutoff
n, alpha_LJ = parameters of soft-core potential
cutoff = global cutoff for Lennard-Jones interactions (distance units)
<I>lj/cut/coul/cut/soft</I> args = n alpha_LJ alpha_C cutoff (cutoff2)
n, alpha_LJ, alpha_C = parameters of soft-core potential
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
<I>lj/cut/coul/long/soft</I> args = n alpha_LJ alpha_C cutoff
- n, alpha_LJ, alpha_C = parameters of the soft-core potential
+ n, alpha_LJ, alpha_C = parameters of the soft-core potential
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
<I>lj/cut/tip4p/long/soft</I> args = otype htype btype atype qdist n alpha_LJ alpha_C cutoff (cutoff2)
otype,htype = atom types for TIP4P O and H
btype,atype = bond and angle types for TIP4P waters
qdist = distance from O atom to massless charge (distance units)
- n, alpha_LJ, alpha_C = parameters of the soft-core potential
+ n, alpha_LJ, alpha_C = parameters of the soft-core potential
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
+ <I>lj/charmm/coul/long/soft</I> args = n alpha_LJ alpha_C inner outer (cutoff)
+ n, alpha_LJ, alpha_C = parameters of the soft-core potential
+ inner, outer = global switching cutoffs for LJ (and Coulombic if only 5 args)
+ cutoff = global cutoff for Coulombic (optional, outer is Coulombic cutoff if only 5 args)
<I>coul/cut/soft</I> args = n alpha_C cutoff
- n, alpha_C = parameters of the soft-core potential
+ n, alpha_C = parameters of the soft-core potential
cutoff = global cutoff for Coulomb interactions (distance units)
<I>coul/long/soft</I> args = n alpha_C cutoff
- n, alpha_C = parameters of the soft-core potential
+ n, alpha_C = parameters of the soft-core potential
cutoff = global cutoff for Coulomb interactions (distance units)
<I>tip4p/long/soft</I> args = otype htype btype atype qdist n alpha_C cutoff
otype,htype = atom types for TIP4P O and H
btype,atype = bond and angle types for TIP4P waters
qdist = distance from O atom to massless charge (distance units)
- n, alpha_C = parameters of the soft-core potential
+ n, alpha_C = parameters of the soft-core potential
cutoff = global cutoff for Coulomb interactions (distance units)
</PRE>
<P><B>Examples:</B>
</P>
<PRE>pair_style lj/cut/soft 2.0 0.5 9.5
pair_coeff * * 0.28 3.1 1.0
pair_coeff 1 1 0.28 3.1 1.0 9.5
</PRE>
<PRE>pair_style lj/cut/coul/cut/soft 2.0 0.5 10.0 9.5
pair_style lj/cut/coul/cut/soft 2.0 0.5 10.0 9.5 9.5
pair_coeff * * 0.28 3.1 1.0
pair_coeff 1 1 0.28 3.1 0.5 10.0
pair_coeff 1 1 0.28 3.1 0.5 10.0 9.5
</PRE>
<PRE>pair_style lj/cut/coul/long/soft 2.0 0.5 10.0 9.5
pair_style lj/cut/coul/long/soft 2.0 0.5 10.0 9.5 9.5
pair_coeff * * 0.28 3.1 1.0
pair_coeff 1 1 0.28 3.1 0.0 10.0
pair_coeff 1 1 0.28 3.1 0.0 10.0 9.5
</PRE>
<PRE>pair_style lj/cut/tip4p/long/soft 1 2 7 8 0.15 2.0 0.5 10.0 9.8
pair_style lj/cut/tip4p/long/soft 1 2 7 8 0.15 2.0 0.5 10.0 9.8 9.5
pair_coeff * * 0.155 3.1536 1.0
pair_coeff 1 1 0.155 3.1536 1.0 9.5
</PRE>
+<PRE>pair_style lj/charmm/coul/long 2.0 0.5 10.0 8.0 10.0
+pair_style lj/charmm/coul/long 2.0 0.5 10.0 8.0 10.0 9.0
+pair_coeff * * 0.28 3.1 1.0
+pair_coeff 1 1 0.28 3.1 1.0 0.14 3.1
+</PRE>
<PRE>pair_style coul/long/soft 1.0 10.0 9.5
pair_coeff * * 1.0
pair_coeff 1 1 1.0 9.5
</PRE>
<PRE>pair_style tip4p/long/soft 1 2 7 8 0.15 2.0 0.5 10.0 9.8
pair_coeff * * 1.0
pair_coeff 1 1 1.0 9.5
</PRE>
<P><B>Description:</B>
</P>
<P>The <I>lj/cut/soft</I> style and substyles compute the 12/6 Lennard-Jones
and Coulomb potential modified by a soft core, in order to avoid
singularities during free energy calculations when sites are created
or anihilated <A HREF = "#Beutler">(Beutler)</A>.
</P>
<CENTER><IMG SRC = "Eqs/pair_lj_soft.jpg">
</CENTER>
<P>Coulomb interactions are also damped with a soft core at short
distance as
</P>
<CENTER><IMG SRC = "Eqs/pair_coul_soft.jpg">
</CENTER>
<P>In the Coulomb part C is an energy-conversion constant, q_i and q_j
are the charges on the 2 atoms, and epsilon is the dielectric constant
which can be set by the <A HREF = "dielectric.html">dielectric</A> command.
</P>
<P>The coefficient lambda is an activation parameter. When lambda = 1 the
pair potentiel is identical to a Lennard-Jones term plus a Coulomb
term. When lambda = 0 the pair interactions are deactivated. The
transition between these two extrema is smoothed by a repulsive soft
core in order to avoid singularities in potential energy and forces
when sites are created or anihilated and can overlap
<A HREF = "#Beutler">(Beutler)</A>.
</P>
<P>The paratemers n, alpha_LJ and alpha_C are set in the
<A HREF = "pair_style.html">pair_style</A> command, before the cutoffs. Usual
choices for the exponent are n = 2 or n = 1. For the remaining
coefficients alpha_LJ = 0.5 and alpha_C = 10 Angstrom^2 are
appropriate choices. Plots of the LJ and Coulomb terms are shown
below, for lambda ranging from 1 ro 0 every 0.1.
</P>
<CENTER><IMG SRC = "JPG/lj_soft.jpg"><IMG SRC = "JPG/coul_soft.jpg">
</CENTER>
<P>The <I>lj/cut/tip4p/long/soft</I> implements a soft-core version of the
TIP4P water model. The usage of this pair style is documented in the
<A HREF = "pair_lj.html">pair_lj</A> styles. The soft-core version introduces the
lambda parameter to the list of arguments, after epsilon and sigma in
the <A HREF = "pair_coeff.html">pair_coeff</A> command. The paratemers n, alpha_LJ
and alpha_C are set in the <A HREF = "pair_style.html">pair_style</A> command,
before the cutoffs.
</P>
+<P>Style <I>lj/charmm/coul/long/soft</I> implements a soft-core version of the
+CHARMM version of LJ interactions with an additional switching
+function S(r) that ramps the energy and force smoothly to zero between
+an inner and outer cutoff. The usage of this pair style is documented
+in the <A HREF = "pair_charmm.html">pair_charmm</A> styles. The soft-core version
+introduces the lambda parameter to the list of arguments, after
+epsilon and sigma in the <A HREF = "pair_coeff.html">pair_coeff</A> command (and
+before the optional eps14 and sigma14). The paratemers n,
+alpha_LJ and alpha_C are set in the <A HREF = "pair_style.html">pair_style</A>
+command, before the cutoffs.
+</P>
<P>The <I>coul/cut/soft</I>, <I>coul/long/soft</I> and <I>tip4p/long/soft</I> substyles
are designed to be combined with other pair potentials via the
<A HREF = "pair_hybrid.html">pair_style hybrid/overlay</A> command. This is because
they have no repulsive core. Hence, if used by themselves, there will
be no repulsion to keep two oppositely charged particles from
overlapping each other. In this case, if lambda = 1, a singularity may
occur. These substyles are suitable to represent charges embedded in
the Lennard-Jones radius of another site (for example hydrogen atoms
in several water models).
</P>
<P>For the <I>lj/cut/coul/cut/soft</I> or <I>lj/cut/coul/long/soft</I> pair styles,
the following coefficients must be defined for each pair of atoms
types via the <A HREF = "pair_coeff.html">pair_coeff</A> command as in the examples
above, or in the data file or restart files read by the
<A HREF = "read_data.html">read_data</A> or <A HREF = "read_restart.html">read_restart</A>
commands, or by mixing as described below:
</P>
<UL><LI>epsilon (energy units)
<LI>sigma (distance units)
<LI>lambda (activation parameter between 0 and 1)
<LI>cutoff1 (distance units)
<LI>cutoff2 (distance units)
</UL>
<P>The latter two coefficients are optional. If not specified, the global
LJ and Coulombic cutoffs specified in the pair_style command are used.
If only one cutoff is specified, it is used as the cutoff for both LJ
and Coulombic interactions for this type pair. If both coefficients
are specified, they are used as the LJ and Coulombic cutoffs for this
type pair. You cannot specify 2 cutoffs for style <I>lj/cut/soft</I>,
since it has no Coulombic terms. For the <I>coul/cut/soft</I> and
<I>coul/long/soft</I> only lambda and the optional cutoff2 are to be
specified.
</P>
<HR>
<P>Styles with a <I>cuda</I>, <I>gpu</I>, <I>omp</I>, or <I>opt</I> suffix are functionally
the same as the corresponding style without the suffix. They have
been optimized to run faster, depending on your available hardware, as
discussed in <A HREF = "Section_accelerate.html">Section_accelerate</A> of the
manual. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
</P>
<P>These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
packages, respectively. They are only enabled if LAMMPS was built with
those packages. See the <A HREF = "Section_start.html#start_3">Making LAMMPS</A>
section for more info.
</P>
<P>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <A HREF = "Section_start.html#start_7">-suffix command-line
switch</A> when you invoke LAMMPS, or you can
use the <A HREF = "suffix.html">suffix</A> command in your input script.
</P>
<P>See <A HREF = "Section_accelerate.html">Section_accelerate</A> of the manual for
more instructions on how to use the accelerated styles effectively.
</P>
<HR>
<P><B>Mixing, shift, tail correction, restart info</B>:
</P>
<P>For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance for this pair style can be mixed.
The default mix value is <I>geometric</I>. See the "pair_modify" command
for details.
</P>
<P>These pair styles support the <A HREF = "pair_modify.html">pair_modify</A> shift
option for the energy of the Lennard-Jones portion of the pair
interaction.
</P>
<P>These pair styles support the <A HREF = "pair_modify.html">pair_modify</A> tail
option for adding a long-range tail correction to the energy and
pressure for the Lennard-Jones portion of the pair interaction.
</P>
<P>These pair styles write information to <A HREF = "restart.html">binary restart
files</A>, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.
</P>
<HR>
<P><B>Restrictions:</B>
</P>
<P>To avoid division by zero do not set sigma = 0. When sites do not
interact though the Lennard-Jones term use epsilon = 0 and sigma = 1
for example, or else use the <I>coul/long/soft</I> or similar substyle.
</P>
<P>All of the plain <I>soft</I> pair styles are part of the USER-FEP package.
The <I>long</I> styles also requires the KSPACE package to be installed.
They are only enabled if LAMMPS was built with those packages. See
the <A HREF = "Section_start.html#start_3">Making LAMMPS</A> section for more info.
</P>
<P><B>Related commands:</B>
</P>
<P><A HREF = "pair_coeff.html">pair_coeff</A>, <A HREF = "fix_adapt.html">fix_adapt</A>,
<A HREF = "fix_adapt_fep.html">fix_adapt/fep</A>, <A HREF = "compute_fep.html">compute_fep</A>
</P>
<P><B>Default:</B> none
</P>
<HR>
<A NAME = "Beutler"></A>
<P><B>(Beutler)</B> Beutler, Mark, van Schaik, Gerber, van Gunsteren, Chem
Phys Lett, 222, 529 (1994).
</P>
</HTML>
diff --git a/doc/pair_lj_soft.txt b/doc/pair_lj_soft.txt
index c6df26809..7e1226bd5 100644
--- a/doc/pair_lj_soft.txt
+++ b/doc/pair_lj_soft.txt
@@ -1,236 +1,258 @@
"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
pair_style lj/cut/soft command :h3
pair_style lj/cut/soft/omp command :h3
pair_style lj/cut/coul/cut/soft command :h3
pair_style lj/cut/coul/cut/soft/omp command :h3
pair_style lj/cut/coul/long/soft command :h3
pair_style lj/cut/coul/long/soft/omp command :h3
pair_style lj/cut/tip4p/long/soft command :h3
pair_style lj/cut/tip4p/long/soft/omp command :h3
+pair_style lj/charmm/coul/long/soft command :h3
+pair_style lj/charmm/coul/long/soft/omp command :h3
pair_style coul/cut/soft command :h3
pair_style coul/cut/soft/omp command :h3
pair_style coul/long/soft command :h3
pair_style coul/long/soft/omp command :h3
pair_style tip4p/long/soft command :h3
pair_style tip4p/long/soft/omp command :h3
[Syntax:]
pair_style style args :pre
-style = {lj/cut/soft} or {lj/cut/coul/cut/soft} or {lj/cut/coul/long/soft} or {lj/cut/tip4p/long/soft} or {coul/cut/soft} or {coul/long/soft} or {tip4p/long/soft}
+style = {lj/cut/soft} or {lj/cut/coul/cut/soft} or {lj/cut/coul/long/soft} or {lj/cut/tip4p/long/soft} or {lj/charmm/coul/long/soft} or {coul/cut/soft} or {coul/long/soft} or {tip4p/long/soft}
args = list of arguments for a particular style :ul
{lj/cut/soft} args = n alpha_lj cutoff
n, alpha_LJ = parameters of soft-core potential
cutoff = global cutoff for Lennard-Jones interactions (distance units)
{lj/cut/coul/cut/soft} args = n alpha_LJ alpha_C cutoff (cutoff2)
n, alpha_LJ, alpha_C = parameters of soft-core potential
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
{lj/cut/coul/long/soft} args = n alpha_LJ alpha_C cutoff
- n, alpha_LJ, alpha_C = parameters of the soft-core potential
+ n, alpha_LJ, alpha_C = parameters of the soft-core potential
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
{lj/cut/tip4p/long/soft} args = otype htype btype atype qdist n alpha_LJ alpha_C cutoff (cutoff2)
otype,htype = atom types for TIP4P O and H
btype,atype = bond and angle types for TIP4P waters
qdist = distance from O atom to massless charge (distance units)
- n, alpha_LJ, alpha_C = parameters of the soft-core potential
+ n, alpha_LJ, alpha_C = parameters of the soft-core potential
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
+ {lj/charmm/coul/long/soft} args = n alpha_LJ alpha_C inner outer (cutoff)
+ n, alpha_LJ, alpha_C = parameters of the soft-core potential
+ inner, outer = global switching cutoffs for LJ (and Coulombic if only 5 args)
+ cutoff = global cutoff for Coulombic (optional, outer is Coulombic cutoff if only 5 args)
{coul/cut/soft} args = n alpha_C cutoff
- n, alpha_C = parameters of the soft-core potential
+ n, alpha_C = parameters of the soft-core potential
cutoff = global cutoff for Coulomb interactions (distance units)
{coul/long/soft} args = n alpha_C cutoff
- n, alpha_C = parameters of the soft-core potential
+ n, alpha_C = parameters of the soft-core potential
cutoff = global cutoff for Coulomb interactions (distance units)
{tip4p/long/soft} args = otype htype btype atype qdist n alpha_C cutoff
otype,htype = atom types for TIP4P O and H
btype,atype = bond and angle types for TIP4P waters
qdist = distance from O atom to massless charge (distance units)
- n, alpha_C = parameters of the soft-core potential
+ n, alpha_C = parameters of the soft-core potential
cutoff = global cutoff for Coulomb interactions (distance units)
:pre
[Examples:]
pair_style lj/cut/soft 2.0 0.5 9.5
pair_coeff * * 0.28 3.1 1.0
pair_coeff 1 1 0.28 3.1 1.0 9.5 :pre
pair_style lj/cut/coul/cut/soft 2.0 0.5 10.0 9.5
pair_style lj/cut/coul/cut/soft 2.0 0.5 10.0 9.5 9.5
pair_coeff * * 0.28 3.1 1.0
pair_coeff 1 1 0.28 3.1 0.5 10.0
pair_coeff 1 1 0.28 3.1 0.5 10.0 9.5 :pre
pair_style lj/cut/coul/long/soft 2.0 0.5 10.0 9.5
pair_style lj/cut/coul/long/soft 2.0 0.5 10.0 9.5 9.5
pair_coeff * * 0.28 3.1 1.0
pair_coeff 1 1 0.28 3.1 0.0 10.0
pair_coeff 1 1 0.28 3.1 0.0 10.0 9.5 :pre
pair_style lj/cut/tip4p/long/soft 1 2 7 8 0.15 2.0 0.5 10.0 9.8
pair_style lj/cut/tip4p/long/soft 1 2 7 8 0.15 2.0 0.5 10.0 9.8 9.5
pair_coeff * * 0.155 3.1536 1.0
pair_coeff 1 1 0.155 3.1536 1.0 9.5 :pre
-
+
+pair_style lj/charmm/coul/long 2.0 0.5 10.0 8.0 10.0
+pair_style lj/charmm/coul/long 2.0 0.5 10.0 8.0 10.0 9.0
+pair_coeff * * 0.28 3.1 1.0
+pair_coeff 1 1 0.28 3.1 1.0 0.14 3.1 :pre
+
pair_style coul/long/soft 1.0 10.0 9.5
pair_coeff * * 1.0
pair_coeff 1 1 1.0 9.5 :pre
pair_style tip4p/long/soft 1 2 7 8 0.15 2.0 0.5 10.0 9.8
pair_coeff * * 1.0
pair_coeff 1 1 1.0 9.5 :pre
[Description:]
The {lj/cut/soft} style and substyles compute the 12/6 Lennard-Jones
and Coulomb potential modified by a soft core, in order to avoid
singularities during free energy calculations when sites are created
or anihilated "(Beutler)"_#Beutler.
:c,image(Eqs/pair_lj_soft.jpg)
Coulomb interactions are also damped with a soft core at short
distance as
:c,image(Eqs/pair_coul_soft.jpg)
In the Coulomb part C is an energy-conversion constant, q_i and q_j
are the charges on the 2 atoms, and epsilon is the dielectric constant
which can be set by the "dielectric"_dielectric.html command.
The coefficient lambda is an activation parameter. When lambda = 1 the
pair potentiel is identical to a Lennard-Jones term plus a Coulomb
term. When lambda = 0 the pair interactions are deactivated. The
transition between these two extrema is smoothed by a repulsive soft
core in order to avoid singularities in potential energy and forces
when sites are created or anihilated and can overlap
"(Beutler)"_#Beutler.
The paratemers n, alpha_LJ and alpha_C are set in the
"pair_style"_pair_style.html command, before the cutoffs. Usual
choices for the exponent are n = 2 or n = 1. For the remaining
coefficients alpha_LJ = 0.5 and alpha_C = 10 Angstrom^2 are
appropriate choices. Plots of the LJ and Coulomb terms are shown
below, for lambda ranging from 1 ro 0 every 0.1.
:c,image(JPG/lj_soft.jpg),image(JPG/coul_soft.jpg)
The {lj/cut/tip4p/long/soft} implements a soft-core version of the
TIP4P water model. The usage of this pair style is documented in the
"pair_lj"_pair_lj.html styles. The soft-core version introduces the
lambda parameter to the list of arguments, after epsilon and sigma in
the "pair_coeff"_pair_coeff.html command. The paratemers n, alpha_LJ
and alpha_C are set in the "pair_style"_pair_style.html command,
before the cutoffs.
+Style {lj/charmm/coul/long/soft} implements a soft-core version of the
+CHARMM version of LJ interactions with an additional switching
+function S(r) that ramps the energy and force smoothly to zero between
+an inner and outer cutoff. The usage of this pair style is documented
+in the "pair_charmm"_pair_charmm.html styles. The soft-core version
+introduces the lambda parameter to the list of arguments, after
+epsilon and sigma in the "pair_coeff"_pair_coeff.html command (and
+before the optional eps14 and sigma14). The paratemers n,
+alpha_LJ and alpha_C are set in the "pair_style"_pair_style.html
+command, before the cutoffs.
+
The {coul/cut/soft}, {coul/long/soft} and {tip4p/long/soft} substyles
are designed to be combined with other pair potentials via the
"pair_style hybrid/overlay"_pair_hybrid.html command. This is because
they have no repulsive core. Hence, if used by themselves, there will
be no repulsion to keep two oppositely charged particles from
overlapping each other. In this case, if lambda = 1, a singularity may
occur. These substyles are suitable to represent charges embedded in
the Lennard-Jones radius of another site (for example hydrogen atoms
in several water models).
For the {lj/cut/coul/cut/soft} or {lj/cut/coul/long/soft} pair styles,
the following coefficients must be defined for each pair of atoms
types via the "pair_coeff"_pair_coeff.html command as in the examples
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands, or by mixing as described below:
epsilon (energy units)
sigma (distance units)
lambda (activation parameter between 0 and 1)
cutoff1 (distance units)
cutoff2 (distance units) :ul
The latter two coefficients are optional. If not specified, the global
LJ and Coulombic cutoffs specified in the pair_style command are used.
If only one cutoff is specified, it is used as the cutoff for both LJ
and Coulombic interactions for this type pair. If both coefficients
are specified, they are used as the LJ and Coulombic cutoffs for this
type pair. You cannot specify 2 cutoffs for style {lj/cut/soft},
since it has no Coulombic terms. For the {coul/cut/soft} and
{coul/long/soft} only lambda and the optional cutoff2 are to be
specified.
:line
Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally
the same as the corresponding style without the suffix. They have
been optimized to run faster, depending on your available hardware, as
discussed in "Section_accelerate"_Section_accelerate.html of the
manual. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
packages, respectively. They are only enabled if LAMMPS was built with
those packages. See the "Making LAMMPS"_Section_start.html#start_3
section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section_accelerate"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, tail correction, restart info]:
For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance for this pair style can be mixed.
The default mix value is {geometric}. See the "pair_modify" command
for details.
These pair styles support the "pair_modify"_pair_modify.html shift
option for the energy of the Lennard-Jones portion of the pair
interaction.
These pair styles support the "pair_modify"_pair_modify.html tail
option for adding a long-range tail correction to the energy and
pressure for the Lennard-Jones portion of the pair interaction.
These pair styles write information to "binary restart
files"_restart.html, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.
:line
[Restrictions:]
To avoid division by zero do not set sigma = 0. When sites do not
interact though the Lennard-Jones term use epsilon = 0 and sigma = 1
for example, or else use the {coul/long/soft} or similar substyle.
All of the plain {soft} pair styles are part of the USER-FEP package.
The {long} styles also requires the KSPACE package to be installed.
They are only enabled if LAMMPS was built with those packages. See
the "Making LAMMPS"_Section_start.html#start_3 section for more info.
[Related commands:]
"pair_coeff"_pair_coeff.html, "fix_adapt"_fix_adapt.html,
"fix_adapt/fep"_fix_adapt_fep.html, "compute_fep"_compute_fep.html
[Default:] none
:line
:link(Beutler)
[(Beutler)] Beutler, Mark, van Schaik, Gerber, van Gunsteren, Chem
Phys Lett, 222, 529 (1994).
diff --git a/doc/restart.html b/doc/restart.html
index c56afdcb3..cec36ed7c 100644
--- a/doc/restart.html
+++ b/doc/restart.html
@@ -1,175 +1,186 @@
<HTML>
<CENTER><A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> - <A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A>
</CENTER>
<HR>
<H3>restart command
</H3>
<P><B>Syntax:</B>
</P>
<PRE>restart 0
restart N root keyword value ...
restart N file1 file2 keyword value ...
</PRE>
<UL><LI>N = write a restart file every this many timesteps
<LI>N can be a variable (see below)
<LI>root = filename to which timestep # is appended
<LI>file1,file2 = two full filenames, toggle between them when writing file
<LI>zero or more keyword/value pairs may be appended
<LI>keyword = <I>fileper</I> or <I>nfile</I>
<PRE> <I>fileper</I> arg = Np
Np = write one file for every this many processors
<I>nfile</I> arg = Nf
Nf = write this many files, one from each of Nf processors
</PRE>
</UL>
<P><B>Examples:</B>
</P>
<PRE>restart 0
restart 1000 poly.restart
restart 1000 poly.restart.mpiio
restart 1000 restart.*.equil
restart 10000 poly.%.1 poly.%.2 nfile 10
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>
<P>Note that you can specify the restart command twice, once with a
single filename and once with two filenames. This would allow you,
for example, to write out archival restart files every 100000 steps
using a single filenname, and more frequent temporary restart files
every 1000 steps, using two filenames. Using restart 0 will turn off
both modes of output.
</P>
<P>Similar to <A HREF = "dump.html">dump</A> files, the restart filename(s) can contain
two wild-card characters.
</P>
<P>If a "*" appears in the single filename, it is replaced with the
current timestep value. This is only recognized when a single
filename is used (not when toggling back and forth). Thus, the 3rd
example above creates restart files as follows: restart.1000.equil,
restart.2000.equil, etc. If a single filename is used with no "*",
then the timestep value is appended. E.g. the 2nd example above
creates restart files as follows: poly.restart.1000,
poly.restart.2000, etc.
</P>
<P>If a "%" character appears in the restart filename(s), then one file
is written for each processor and the "%" character is replaced with
the processor ID from 0 to P-1. An additional file with the "%"
replaced by "base" is also written, which contains global information.
For example, the files written on step 1000 for filename restart.%
would be restart.base.1000, restart.0.1000, restart.1.1000, ...,
restart.P-1.1000. This creates smaller files and can be a fast mode
of output and subsequent input on parallel machines that support
parallel I/O. The optional <I>fileper</I> and <I>nfile</I> keywords discussed
below can alter the number of files written.
</P>
<P>The restart file can also be written in parallel as one large binary
file via the MPI-IO library, which 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>
<PRE>make yes-mpiio # installs the MPIIO package
make g++ # build LAMMPS for your platform
</PRE>
<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>
<P>Restart files are written on timesteps that are a multiple of N but
not on the first timestep of a run or minimization. You can use the
<A HREF = "write_restart.html">write_restart</A> command to write a restart file
before a run begins. A restart file is not written on the last
timestep of a run unless it is a multiple of N. A restart file is
written on the last timestep of a minimization if N > 0 and the
minimization converges.
</P>
<P>Instead of a numeric value, N can be specifed as an <A HREF = "variable.html">equal-style
variable</A>, which should be specified as v_name, where
name is the variable name. In this case, the variable is evaluated at
the beginning of a run to determine the next timestep at which a
restart file will be written out. On that timestep, the variable will
be evaluated again to determine the next timestep, etc. Thus the
variable should return timestep values. See the stagger() and
logfreq() and stride() math functions for <A HREF = "variable.html">equal-style
variables</A>, as examples of useful functions to use in
this context. Other similar math functions could easily be added as
options for <A HREF = "variable.html">equal-style variables</A>.
</P>
<P>For example, the following commands will write restart files
every step from 1100 to 1200, and could be useful for debugging
a simulation where something goes wrong at step 1163:
</P>
<PRE>variable s equal stride(1100,1200,1)
restart v_s tmp.restart
</PRE>
<HR>
<P>See the <A HREF = "read_restart.html">read_restart</A> command for information about
what is stored in a restart file.
</P>
<P>Restart files can be read by a <A HREF = "read_restart.html">read_restart</A>
command to restart a simulation from a particular state. Because the
file is binary (to enable exact restarts), it may not be readable on
another machine. In this case, you can use the <A HREF = "Section_start.html#start_7">-r command-line
switch</A> to convert a restart file to a data
file.
</P>
+<P>IMPORTANT NOTE: Although the purpose of restart files is to enable
+restarting a simulation from where it left off, not all information
+about a simulation is stored in the file. For example, the list of
+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.
+</P>
<HR>
<P>The optional <I>nfile</I> or <I>fileper</I> keywords can be used in conjunction
with the "%" wildcard character in the specified restart file name(s).
As explained above, the "%" character causes the restart file to be
written in pieces, one piece for each of P processors. By default P =
the number of processors the simulation is running on. The <I>nfile</I> or
<I>fileper</I> keyword can be used to set P to a smaller value, which can
be more efficient when running on a large number of processors.
</P>
<P>The <I>nfile</I> keyword sets P to the specified Nf value. For example, if
Nf = 4, and the simulation is running on 100 processors, 4 files will
be written, by processors 0,25,50,75. Each will collect information
from itself and the next 24 processors and write it to a restart file.
</P>
<P>For the <I>fileper</I> keyword, the specified value of Np means write one
file for every Np processors. For example, if Np = 4, every 4th
processor (0,4,8,12,etc) will collect information from itself and the
next 3 processors and write it to a restart file.
</P>
<HR>
<P><B>Restrictions:</B>
</P>
<P>To write and read restart files in parallel with MPI-IO, the MPIIO
package must be installed.
</P>
<P><B>Related commands:</B>
</P>
<P><A HREF = "write_restart.html">write_restart</A>, <A HREF = "read_restart.html">read_restart</A>
</P>
<P><B>Default:</B>
</P>
<PRE>restart 0
</PRE>
</HTML>
diff --git a/doc/restart.txt b/doc/restart.txt
index 834e7d0d7..ae0282029 100644
--- a/doc/restart.txt
+++ b/doc/restart.txt
@@ -1,163 +1,174 @@
"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
restart command :h3
[Syntax:]
restart 0
restart N root keyword value ...
restart N file1 file2 keyword value ... :pre
N = write a restart file every this many timesteps :ulb,l
N can be a variable (see below) :l
root = filename to which timestep # is appended :l
file1,file2 = two full filenames, toggle between them when writing file :l
zero or more keyword/value pairs may be appended :l
keyword = {fileper} or {nfile} :l
{fileper} arg = Np
Np = write one file for every this many processors
{nfile} arg = Nf
Nf = write this many files, one from each of Nf processors :pre
:ule
[Examples:]
restart 0
restart 1000 poly.restart
restart 1000 poly.restart.mpiio
restart 1000 restart.*.equil
restart 10000 poly.%.1 poly.%.2 nfile 10
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.
Note that you can specify the restart command twice, once with a
single filename and once with two filenames. This would allow you,
for example, to write out archival restart files every 100000 steps
using a single filenname, and more frequent temporary restart files
every 1000 steps, using two filenames. Using restart 0 will turn off
both modes of output.
Similar to "dump"_dump.html files, the restart filename(s) can contain
two wild-card characters.
If a "*" appears in the single filename, it is replaced with the
current timestep value. This is only recognized when a single
filename is used (not when toggling back and forth). Thus, the 3rd
example above creates restart files as follows: restart.1000.equil,
restart.2000.equil, etc. If a single filename is used with no "*",
then the timestep value is appended. E.g. the 2nd example above
creates restart files as follows: poly.restart.1000,
poly.restart.2000, etc.
If a "%" character appears in the restart filename(s), then one file
is written for each processor and the "%" character is replaced with
the processor ID from 0 to P-1. An additional file with the "%"
replaced by "base" is also written, which contains global information.
For example, the files written on step 1000 for filename restart.%
would be restart.base.1000, restart.0.1000, restart.1.1000, ...,
restart.P-1.1000. This creates smaller files and can be a fast mode
of output and subsequent input on parallel machines that support
parallel I/O. The optional {fileper} and {nfile} keywords discussed
below can alter the number of files written.
The restart file can also be written in parallel as one large binary
file via the MPI-IO library, which 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.
Restart files are written on timesteps that are a multiple of N but
not on the first timestep of a run or minimization. You can use the
"write_restart"_write_restart.html command to write a restart file
before a run begins. A restart file is not written on the last
timestep of a run unless it is a multiple of N. A restart file is
written on the last timestep of a minimization if N > 0 and the
minimization converges.
Instead of a numeric value, N can be specifed as an "equal-style
variable"_variable.html, which should be specified as v_name, where
name is the variable name. In this case, the variable is evaluated at
the beginning of a run to determine the next timestep at which a
restart file will be written out. On that timestep, the variable will
be evaluated again to determine the next timestep, etc. Thus the
variable should return timestep values. See the stagger() and
logfreq() and stride() math functions for "equal-style
variables"_variable.html, as examples of useful functions to use in
this context. Other similar math functions could easily be added as
options for "equal-style variables"_variable.html.
For example, the following commands will write restart files
every step from 1100 to 1200, and could be useful for debugging
a simulation where something goes wrong at step 1163:
variable s equal stride(1100,1200,1)
restart v_s tmp.restart :pre
:line
See the "read_restart"_read_restart.html command for information about
what is stored in a restart file.
Restart files can be read by a "read_restart"_read_restart.html
command to restart a simulation from a particular state. Because the
file is binary (to enable exact restarts), it may not be readable on
another machine. In this case, you can use the "-r command-line
switch"_Section_start.html#start_7 to convert a restart file to a data
file.
+IMPORTANT NOTE: Although the purpose of restart files is to enable
+restarting a simulation from where it left off, not all information
+about a simulation is stored in the file. For example, the list of
+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.
+
:line
The optional {nfile} or {fileper} keywords can be used in conjunction
with the "%" wildcard character in the specified restart file name(s).
As explained above, the "%" character causes the restart file to be
written in pieces, one piece for each of P processors. By default P =
the number of processors the simulation is running on. The {nfile} or
{fileper} keyword can be used to set P to a smaller value, which can
be more efficient when running on a large number of processors.
The {nfile} keyword sets P to the specified Nf value. For example, if
Nf = 4, and the simulation is running on 100 processors, 4 files will
be written, by processors 0,25,50,75. Each will collect information
from itself and the next 24 processors and write it to a restart file.
For the {fileper} keyword, the specified value of Np means write one
file for every Np processors. For example, if Np = 4, every 4th
processor (0,4,8,12,etc) will collect information from itself and the
next 3 processors and write it to a restart file.
:line
[Restrictions:]
To write and read restart files in parallel with MPI-IO, the MPIIO
package must be installed.
[Related commands:]
"write_restart"_write_restart.html, "read_restart"_read_restart.html
[Default:]
restart 0 :pre
diff --git a/doc/run.html b/doc/run.html
index 49ecf3129..49fb6e34a 100644
--- a/doc/run.html
+++ b/doc/run.html
@@ -1,206 +1,206 @@
<HTML>
<CENTER><A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> - <A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A>
</CENTER>
<HR>
<H3>run command
</H3>
<P><B>Syntax:</B>
</P>
<PRE>run N keyword values ...
</PRE>
<UL><LI>N = # of timesteps
<LI>zero or more keyword/value pairs may be appended
<LI>keyword = <I>upto</I> or <I>start</I> or <I>stop</I> or <I>pre</I> or <I>post</I> or <I>every</I>
<PRE> <I>upto</I> value = none
<I>start</I> value = N1
N1 = timestep at which 1st run started
<I>stop</I> value = N2
N2 = timestep at which last run will end
<I>pre</I> value = <I>no</I> or <I>yes</I>
<I>post</I> value = <I>no</I> or <I>yes</I>
<I>every</I> values = M c1 c2 ...
M = break the run into M-timestep segments and invoke one or more commands between each segment
c1,c2,...,cN = one or more LAMMPS commands, each enclosed in quotes
c1 = NULL means no command will be invoked
</PRE>
</UL>
<P><B>Examples:</B>
</P>
<PRE>run 10000
run 1000000 upto
run 100 start 0 stop 1000
run 1000 pre no post yes
run 100000 start 0 stop 1000000 every 1000 "print 'Protein Rg = $r'"
run 100000 every 1000 NULL
</PRE>
<P><B>Description:</B>
</P>
<P>Run or continue dynamics for a specified number of timesteps.
</P>
<P>When the <A HREF = "run_style.html">run style</A> is <I>respa</I>, N refers to outer
loop (largest) timesteps.
</P>
<P>A value of N = 0 is acceptable; only the thermodynamics of the system
are computed and printed without taking a timestep.
</P>
<P>The <I>upto</I> keyword means to perform a run starting at the current
timestep up to the specified timestep. E.g. if the current timestep
is 10,000 and "run 100000 upto" is used, then an additional 90,000
timesteps will be run. This can be useful for very long runs on a
machine that allocates chunks of time and terminate your job when time
is exceeded. If you need to restart your script multiple times
(reading in the last restart file), you can keep restarting your
script with the same run command until the simulation finally
completes.
</P>
<P>The <I>start</I> or <I>stop</I> keywords can be used if multiple runs are being
performed and you want a <A HREF = "fix.html">fix</A> command that changes some
value over time (e.g. temperature) to make the change across the
entire set of runs and not just a single run. See the doc page for
individual fixes to see which ones can be used with the <I>start/stop</I>
keywords.
</P>
<P>For example, consider this fix followed by 10 run commands:
</P>
<PRE>fix 1 all nvt 200.0 300.0 1.0
run 1000 start 0 stop 10000
run 1000 start 0 stop 10000
...
run 1000 start 0 stop 10000
</PRE>
<P>The NVT fix ramps the target temperature from 200.0 to 300.0 during a
run. If the run commands did not have the start/stop keywords (just
"run 1000"), then the temperature would ramp from 200.0 to 300.0
during the 1000 steps of each run. With the start/stop keywords, the
ramping takes place over the 10000 steps of all runs together.
</P>
<P>The <I>pre</I> and <I>post</I> keywords can be used to streamline the setup,
clean-up, and associated output to the screen that happens before and
after a run. This can be useful if you wish to do many short runs in
succession (e.g. LAMMPS is being called as a library which is doing
other computations between successive short LAMMPS runs).
</P>
<P>By default (pre and post = yes), LAMMPS creates neighbor lists,
computes forces, and imposes fix constraints before every run. And
after every run it gathers and prints timings statistics. If a run is
just a continuation of a previous run (i.e. no settings are changed),
the initial computation is not necessary; the old neighbor list is
still valid as are the forces. So if <I>pre</I> is specified as "no" then
the initial setup is skipped, except for printing thermodynamic info.
Note that if <I>pre</I> is set to "no" for the very 1st run LAMMPS
performs, then it is overridden, since the initial setup computations
must be done.
</P>
<P>IMPORTANT NOTE: If your input script changes settings between 2 runs
(e.g. adds a <A HREF = "fix.html">fix</A> or <A HREF = "dump.html">dump</A> or
<A HREF = "compute.html">compute</A> or changes a <A HREF = "neigh_modify.html">neighbor</A> list
parameter), then the initial setup must be performed. LAMMPS does not
check for this, but it would be an error to use the <I>pre no</I> option in
this case.
</P>
<P>If <I>post</I> is specified as "no", the full timing summary is skipped;
only a one-line summary timing is printed.
</P>
<P>The <I>every</I> keyword provides a means of breaking a LAMMPS run into a
series of shorter runs. Optionally, one or more LAMMPS commands (c1,
c2, ..., cN) will be executed in between the short runs. If used, the
<I>every</I> keyword must be the last keyword, since it has a variable
number of arguments. Each of the trailing arguments is a single
LAMMPS command, and each command should be enclosed in quotes, so that
the entire command will be treated as a single argument. This will
also prevent any variables in the command from being evaluated until
it is executed multiple times during the run. Note that if a command
itself needs one of its arguments quoted (e.g. the <A HREF = "print.html">print</A>
command), then you can use a combination of single and double quotes,
as in the example above or below.
</P>
<P>The <I>every</I> keyword is a means to avoid listing a long series of runs
and interleaving commands in your input script. For example, a
<A HREF = "print.html">print</A> command could be invoked or a <A HREF = "fix.html">fix</A> could
be redefined, e.g. to reset a thermostat temperature. Or this could
be useful for invoking a command you have added to LAMMPS that wraps
some other code (e.g. as a library) to perform a computation
periodically during a long LAMMPS run. See <A HREF = "Section_modify.html">this
section</A> of the documentation for info about how
to add new commands to LAMMPS. See <A HREF = "Section_howto.html#howto_10">this
section</A> of the documentation for ideas
about how to couple LAMMPS to other codes.
</P>
<P>With the <I>every</I> option, N total steps are simulated, in shorter runs
of M steps each. After each M-length run, the specified commands are
invoked. If only a single command is specified as NULL, then no
command is invoked. Thus these lines:
</P>
<PRE>variable q equal x[100]
-run 6000 every 2000 "print Coord = $q"
+run 6000 every 2000 "print 'Coord = $q'"
</PRE>
<P>are the equivalent of:
</P>
<PRE>variable q equal x[100]
run 2000
-print Coord = $q
+print "Coord = $q"
run 2000
-print Coord = $q
+print "Coord = $q"
run 2000
-print Coord = $q
+print "Coord = $q"
</PRE>
<P>which does 3 runs of 2000 steps and prints the x-coordinate of a
particular atom between runs. Note that the variable "$q" will
be evaluated afresh each time the print command is executed.
</P>
<P>Note that by using the line continuation character "&", the run every
command can be spread across many lines, though it is still a single
command:
</P>
<PRE>run 100000 every 1000 &
"print 'Minimum value = $a'" &
"print 'Maximum value = $b'" &
"print 'Temp = $c'" &
"print 'Press = $d'"
</PRE>
<P>If the <I>pre</I> and <I>post</I> options are set to "no" when used with the
<I>every</I> keyword, then the 1st run will do the full setup and the last
run will print the full timing summary, but these operations will be
skipped for intermediate runs.
</P>
<P>IMPORTANT NOTE: You might hope to specify a command that exits the run
by jumping out of the loop, e.g.
</P>
<PRE>variable t equal temp
run 10000 every 100 "if '$t < 300.0' then 'jump SELF afterrun'"
</PRE>
<P>Unfortunately this will not currently work. The run command simply
executes each command one at a time each time it pauses, then
continues the run. You can replace the jump command with a simple
<A HREF = "quit.html">quit</A> command and cause LAMMPS to exit during the
middle of a run when the condition is met.
</P>
<P><B>Restrictions:</B>
</P>
<P>The number of specified timesteps N must fit in a signed 32-bit
integer, so you are limited to slightly more than 2 billion steps
(2^31) in a single run. However, you can perform successive runs to
run a simulation for any number of steps (ok, up to 2^63 steps).
</P>
<P><B>Related commands:</B>
</P>
<P><A HREF = "minimize.html">minimize</A>, <A HREF = "run_style.html">run_style</A>,
<A HREF = "temper.html">temper</A>
</P>
<P><B>Default:</B>
</P>
<P>The option defaults are start = the current timestep, stop = current
timestep + N, pre = yes, and post = yes.
</P>
</HTML>
diff --git a/doc/run.txt b/doc/run.txt
index f9049f28c..79dabffa3 100644
--- a/doc/run.txt
+++ b/doc/run.txt
@@ -1,197 +1,197 @@
"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
run command :h3
[Syntax:]
run N keyword values ... :pre
N = # of timesteps :ulb,l
zero or more keyword/value pairs may be appended :l
keyword = {upto} or {start} or {stop} or {pre} or {post} or {every} :l
{upto} value = none
{start} value = N1
N1 = timestep at which 1st run started
{stop} value = N2
N2 = timestep at which last run will end
{pre} value = {no} or {yes}
{post} value = {no} or {yes}
{every} values = M c1 c2 ...
M = break the run into M-timestep segments and invoke one or more commands between each segment
c1,c2,...,cN = one or more LAMMPS commands, each enclosed in quotes
c1 = NULL means no command will be invoked :pre
:ule
[Examples:]
run 10000
run 1000000 upto
run 100 start 0 stop 1000
run 1000 pre no post yes
run 100000 start 0 stop 1000000 every 1000 "print 'Protein Rg = $r'"
run 100000 every 1000 NULL :pre
[Description:]
Run or continue dynamics for a specified number of timesteps.
When the "run style"_run_style.html is {respa}, N refers to outer
loop (largest) timesteps.
A value of N = 0 is acceptable; only the thermodynamics of the system
are computed and printed without taking a timestep.
The {upto} keyword means to perform a run starting at the current
timestep up to the specified timestep. E.g. if the current timestep
is 10,000 and "run 100000 upto" is used, then an additional 90,000
timesteps will be run. This can be useful for very long runs on a
machine that allocates chunks of time and terminate your job when time
is exceeded. If you need to restart your script multiple times
(reading in the last restart file), you can keep restarting your
script with the same run command until the simulation finally
completes.
The {start} or {stop} keywords can be used if multiple runs are being
performed and you want a "fix"_fix.html command that changes some
value over time (e.g. temperature) to make the change across the
entire set of runs and not just a single run. See the doc page for
individual fixes to see which ones can be used with the {start/stop}
keywords.
For example, consider this fix followed by 10 run commands:
fix 1 all nvt 200.0 300.0 1.0
run 1000 start 0 stop 10000
run 1000 start 0 stop 10000
...
run 1000 start 0 stop 10000 :pre
The NVT fix ramps the target temperature from 200.0 to 300.0 during a
run. If the run commands did not have the start/stop keywords (just
"run 1000"), then the temperature would ramp from 200.0 to 300.0
during the 1000 steps of each run. With the start/stop keywords, the
ramping takes place over the 10000 steps of all runs together.
The {pre} and {post} keywords can be used to streamline the setup,
clean-up, and associated output to the screen that happens before and
after a run. This can be useful if you wish to do many short runs in
succession (e.g. LAMMPS is being called as a library which is doing
other computations between successive short LAMMPS runs).
By default (pre and post = yes), LAMMPS creates neighbor lists,
computes forces, and imposes fix constraints before every run. And
after every run it gathers and prints timings statistics. If a run is
just a continuation of a previous run (i.e. no settings are changed),
the initial computation is not necessary; the old neighbor list is
still valid as are the forces. So if {pre} is specified as "no" then
the initial setup is skipped, except for printing thermodynamic info.
Note that if {pre} is set to "no" for the very 1st run LAMMPS
performs, then it is overridden, since the initial setup computations
must be done.
IMPORTANT NOTE: If your input script changes settings between 2 runs
(e.g. adds a "fix"_fix.html or "dump"_dump.html or
"compute"_compute.html or changes a "neighbor"_neigh_modify.html list
parameter), then the initial setup must be performed. LAMMPS does not
check for this, but it would be an error to use the {pre no} option in
this case.
If {post} is specified as "no", the full timing summary is skipped;
only a one-line summary timing is printed.
The {every} keyword provides a means of breaking a LAMMPS run into a
series of shorter runs. Optionally, one or more LAMMPS commands (c1,
c2, ..., cN) will be executed in between the short runs. If used, the
{every} keyword must be the last keyword, since it has a variable
number of arguments. Each of the trailing arguments is a single
LAMMPS command, and each command should be enclosed in quotes, so that
the entire command will be treated as a single argument. This will
also prevent any variables in the command from being evaluated until
it is executed multiple times during the run. Note that if a command
itself needs one of its arguments quoted (e.g. the "print"_print.html
command), then you can use a combination of single and double quotes,
as in the example above or below.
The {every} keyword is a means to avoid listing a long series of runs
and interleaving commands in your input script. For example, a
"print"_print.html command could be invoked or a "fix"_fix.html could
be redefined, e.g. to reset a thermostat temperature. Or this could
be useful for invoking a command you have added to LAMMPS that wraps
some other code (e.g. as a library) to perform a computation
periodically during a long LAMMPS run. See "this
section"_Section_modify.html of the documentation for info about how
to add new commands to LAMMPS. See "this
section"_Section_howto.html#howto_10 of the documentation for ideas
about how to couple LAMMPS to other codes.
With the {every} option, N total steps are simulated, in shorter runs
of M steps each. After each M-length run, the specified commands are
invoked. If only a single command is specified as NULL, then no
command is invoked. Thus these lines:
variable q equal x\[100\]
-run 6000 every 2000 "print Coord = $q" :pre
+run 6000 every 2000 "print 'Coord = $q'" :pre
are the equivalent of:
variable q equal x\[100\]
run 2000
-print Coord = $q
+print "Coord = $q"
run 2000
-print Coord = $q
+print "Coord = $q"
run 2000
-print Coord = $q :pre
+print "Coord = $q" :pre
which does 3 runs of 2000 steps and prints the x-coordinate of a
particular atom between runs. Note that the variable "$q" will
be evaluated afresh each time the print command is executed.
Note that by using the line continuation character "&", the run every
command can be spread across many lines, though it is still a single
command:
run 100000 every 1000 &
"print 'Minimum value = $a'" &
"print 'Maximum value = $b'" &
"print 'Temp = $c'" &
"print 'Press = $d'" :pre
If the {pre} and {post} options are set to "no" when used with the
{every} keyword, then the 1st run will do the full setup and the last
run will print the full timing summary, but these operations will be
skipped for intermediate runs.
IMPORTANT NOTE: You might hope to specify a command that exits the run
by jumping out of the loop, e.g.
variable t equal temp
run 10000 every 100 "if '$t < 300.0' then 'jump SELF afterrun'" :pre
Unfortunately this will not currently work. The run command simply
executes each command one at a time each time it pauses, then
continues the run. You can replace the jump command with a simple
"quit"_quit.html command and cause LAMMPS to exit during the
middle of a run when the condition is met.
[Restrictions:]
The number of specified timesteps N must fit in a signed 32-bit
integer, so you are limited to slightly more than 2 billion steps
(2^31) in a single run. However, you can perform successive runs to
run a simulation for any number of steps (ok, up to 2^63 steps).
[Related commands:]
"minimize"_minimize.html, "run_style"_run_style.html,
"temper"_temper.html
[Default:]
The option defaults are start = the current timestep, stop = current
timestep + N, pre = yes, and post = yes.