lb/rigid/pc/sphere = style name of this fix command
+
bodystyle = single or molecule or group
+
+
+single args = none
+molecule args = none
+group args = N groupID1 groupID2 ...
+ N = # of groups
+
+
+
zero or more keyword/value pairs may be appended
+
keyword = force or torque or innerNodes
force values = M xflag yflag zflag
M = which rigid body from 1-Nbody (see asterisk form below)
xflag,yflag,zflag = off/on if component of center-of-mass force is active
torque values = M xflag yflag zflag
M = which rigid body from 1-Nbody (see asterisk form below)
xflag,yflag,zflag = off/on if component of center-of-mass torque is active
innerNodes values = innergroup-ID
innergroup-ID = ID of the atom group which does not experience a hydrodynamic force from the lattice-Boltzmann fluid
This fix is based on the fix rigid command, and was
created to be used in place of that fix, to integrate the equations of
motion of spherical rigid bodies when a lattice-Boltzmann fluid is
present with a user-specified value of the force-coupling constant.
-The fix uses the integration algorithm described in Mackay et al. to update the positions, velocities, and orientations of
+The fix uses the integration algorithm described in Mackay et al. to update the positions, velocities, and orientations of
a set of spherical rigid bodies experiencing velocity dependent
hydrodynamic forces. The spherical bodies are assumed to rotate as
solid, uniform density spheres, with moments of inertia calculated
using the combined sum of the masses of all the constituent particles
(which are assumed to be point particles).
By default, all of the atoms that this fix acts on experience a
hydrodynamic force due to the presence of the lattice-Boltzmann fluid.
However, the innerNodes keyword allows the user to specify atoms
belonging to a rigid object which do not interact with the
lattice-Boltzmann fluid (i.e. these atoms do not feel a hydrodynamic
force from the lattice-Boltzmann fluid). This can be used to
distinguish between atoms on the surface of a non-porous object, and
those on the inside.
This feature can be used, for example, when implementing a hard sphere
interaction between two spherical objects. Instead of interactions
occurring between the particles on the surfaces of the two spheres, it
is desirable simply to place an atom at the center of each sphere,
which does not contribute to the hydrodynamic force, and have these
central atoms interact with one another.
Apart from the features described above, this fix is very similar to
the rigid fix (although it includes fewer optional arguments, and
assumes the constituent atoms are point particles); see
fix rigid for a complete documentation.
Restart, fix_modify, output, run start/stop, minimize info:
No information about the rigid and rigid/nve fixes are written to
binary restart files.
Similar to the fix rigid command: The rigid
fix computes a global scalar which can be accessed by various output commands. The scalar value calculated by
these fixes is “intensive”. The scalar is the current temperature of
the collection of rigid bodies. This is averaged over all rigid
bodies and their translational and rotational degrees of freedom. The
translational energy of a rigid body is 1/2 m v^2, where m = total
mass of the body and v = the velocity of its center of mass. The
rotational energy of a rigid body is 1/2 I w^2, where I = the moment
of inertia tensor of the body and w = its angular velocity. Degrees
of freedom constrained by the force and torque keywords are
removed from this calculation.
All of these fixes compute a global array of values which can be
accessed by various output commands.
The number of rows in the array is equal to the number of rigid
bodies. The number of columns is 15. Thus for each rigid body, 15
values are stored: the xyz coords of the center of mass (COM), the xyz
components of the COM velocity, the xyz components of the force acting
on the COM, the xyz components of the torque acting on the COM, and
the xyz image flags of the COM, which have the same meaning as image
flags for atom positions (see the “dump” command). The force and
torque values in the array are not affected by the force and
torque keywords in the fix rigid command; they reflect values before
any changes are made by those keywords.
The ordering of the rigid bodies (by row in the array) is as follows.
For the single keyword there is just one rigid body. For the
molecule keyword, the bodies are ordered by ascending molecule ID.
For the group keyword, the list of group IDs determines the ordering
of bodies.
The array values calculated by these fixes are “intensive”, meaning
they are independent of the number of atoms in the simulation.
No parameter of these fixes can be used with the start/stop keywords
of the run command. These fixes are not invoked during
energy minimization.
Restrictions
This fix is part of the USER-LB package. It is only enabled if LAMMPS
was built with that package. See the Making LAMMPS section for more info.
Can only be used if a lattice-Boltzmann fluid has been created via the
fix lb/fluid command, and must come after this
command. Should only be used if the force coupling constant used in
fix lb/fluid has been set by the user; this
integration fix cannot be used if the force coupling constant is set
by default.
The defaults are force * on on on, and torque * on on on.
(Mackay et al.) Mackay, F. E., Ollila, S.T.T., and Denniston, C., Hydrodynamic Forces Implemented into LAMMPS through a lattice-Boltzmann fluid, Computer Physics Communications 184 (2013) 2021-2031.
\ No newline at end of file
diff --git a/doc/html/fix_neb.html b/doc/html/fix_neb.html
index 77ce3e40a..51832325e 100644
--- a/doc/html/fix_neb.html
+++ b/doc/html/fix_neb.html
@@ -1,280 +1,280 @@
fix neb command — LAMMPS documentation
Kspring = inter-replica spring constant (force/distance units)
Examples
fix1activeneb10.0
Description
Add inter-replica forces to atoms in the group for a multi-replica
simulation run via the neb command to perform a nudged
elastic band (NEB) calculation for transition state finding. Hi-level
explanations of NEB are given with the neb command and in
Section 6.5 of the manual. The fix
neb command must be used with the “neb” command to define how
inter-replica forces are computed.
Only the N atoms in the fix group experience inter-replica forces.
Atoms in the two end-point replicas do not experience these forces,
but those in intermediate replicas do. During the initial stage of
NEB, the 3N-length vector of interatomic forces Fi = -Grad(V) acting
on the atoms of each intermediate replica I is altered, as described
in the (Henkelman1) paper, to become:
Ri are the atomic coordinates of replica I; Ri-1 and Ri+1 are the
coordinates of its neighbor replicas. That (t with a hat over it) is
the unit “tangent” vector for replica I which is a function of Ri,
Ri-1, Ri+1, and the potential energy of the 3 replicas; it points
roughly in the direction of (Ri+i - Ri-1); see the
(Henkelman1) paper for details.
The first two terms in the above equation are the component of the
interatomic forces perpendicular to the tangent vector. The last term
is a spring force between replica I and its neighbors, parallel to the
tangent vector direction with the specified spring constant Kspring.
The effect of the first two terms is to push the atoms of each replica
toward the minimum energy path (MEP) of conformational states that
transition over the energy barrier. The MEP for an energy barrier is
defined as a sequence of 3N-dimensional states which cross the barrier
at its saddle point, each of which has a potential energy gradient
parallel to the MEP itself.
The effect of the last term is to push each replica away from its two
neighbors in a direction along the MEP, so that the final set of
states are equidistant from each other.
During the second stage of NEB, the forces on the N atoms in the
replica nearest the top of the energy barrier are altered so that it
climbs to the top of the barrier and finds the saddle point. The
forces on atoms in this replica are described in the
(Henkelman2) paper, and become:
Fi=-Grad(V)+2(Grad(V)dotThat)That
The inter-replica forces for the other replicas are unchanged from the
first equation.
Restart, fix_modify, output, run start/stop, minimize info:
No information about this fix is written to binary restart files. None of the fix_modify options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various output commands. No parameter of this fix can
be used with the start/stop keywords of the run command.
The forces due to this fix are imposed during an energy minimization,
as invoked by the minimize command via the
neb command.
Restrictions
This command can only be used if LAMMPS was built with the REPLICA
package. See the Making LAMMPS section
for more info on packages.
This fix tests each kspace style (Ewald, PPPM, and MSM), and
automatically selects the fastest style to use for the remainder
of the run. If the fastest style is Ewald or PPPM, the fix also
adjusts the coulomb cutoff towards optimal speed. Future versions
of this fix will automatically select other kspace parameters
to use for maximum simulation speed. The kspace parameters may
include the style, cutoff, grid points in each direction, order,
Ewald parameter, MSM parallelization cut-point, MPI tasks to use, etc.
The rationale for this fix is to provide the user with
as-fast-as-possible simulations that include long-range electrostatics
(kspace) while meeting the user-prescribed accuracy requirement. A
simple heuristic could never capture the optimal combination of
parameters for every possible run-time scenario. But by performing
short tests of various kspace parameter sets, this fix allows
parameters to be tailored specifically to the user’s machine, MPI
ranks, use of threading or accelerators, the simulated system, and the
simulation details. In addition, it is possible that parameters could
be evolved with the simulation on-the-fly, which is useful for systems
that are dynamically evolving (e.g. changes in box size/shape or
number of particles).
When this fix is invoked, LAMMPS will perform short timed tests of
various parameter sets to determine the optimal parameters. Tests are
performed on-the-fly, with a new test initialized every N steps. N should
be chosen large enough so that adequate CPU time lapses between tests,
thereby providing statistically significant timings. But N should not be
chosen to be so large that an unfortunate parameter set test takes an
inordinate amount of wall time to complete. An N of 100 for most problems
seems reasonable. Once an optimal parameter set is found, that set is
used for the remainder of the run.
This fix uses heristics to guide it’s selection of parameter sets to test,
but the actual timed results will be used to decide which set to use in the
simulation.
It is not necessary to discard trajectories produced using sub-optimal
parameter sets, or a mix of various parameter sets, since the user-prescribed
accuracy will have been maintained throughout. However, some users may prefer
to use this fix only to discover the optimal parameter set for a given setup
that can then be used on subsequent production runs.
This fix starts with kspace parameters that are set by the user with the
kspace_style and kspace_modify
commands. The prescribed accuracy will be maintained by this fix throughout
the simulation.
None of the fix_modify options are relevant to this
fix.
No parameter of this fix can be used with the start/stop keywords of
the run command. This fix is not invoked during energy minimization.
Restrictions
This fix is part of the KSPACE package. It is only enabled if LAMMPS was
built with that package. See the Making LAMMPS section for more info.
Do not set “neigh_modify once yes” or else this fix will never be
called. Reneighboring is required.
keyword = checkqeq or lgvdw or safezone or mincapcheckqeq value = yes or no = whether or not to require qeq/reax fix
lgvdw value = yes or no = whether or not to use a low gradient vdW correction
safezone = factor used for array allocation
mincap = minimum size for array allocation
Examples
pair_style reax/c NULL
pair_style reax/c controlfile checkqeq no
pair_style reax/c NULL lgvdw yes
pair_style reax/c NULL safezone 1.6 mincap 100
pair_coeff * * ffield.reax C H O N
Description
Style reax/c computes the ReaxFF potential of van Duin, Goddard and
co-workers. ReaxFF uses distance-dependent bond-order functions to
represent the contributions of chemical bonding to the potential
energy. There is more than one version of ReaxFF. The version
implemented in LAMMPS uses the functional forms documented in the
supplemental information of the following paper: (Chenoweth et al., 2008). The version integrated into LAMMPS matches
the most up-to-date version of ReaxFF as of summer 2010. For more
technical details about the pair reax/c implementation of ReaxFF, see
the (Aktulga) paper.
The reax/c/kk style is a Kokkos version of the ReaxFF potential that is
derived from the reax/c style. The Kokkos version can run on GPUs and
can also use OpenMP multithreading. For more information about the Kokkos package,
see Section 4 and Section 5.3.3.
One important consideration when using the reax/c/kk style is the choice of either
half or full neighbor lists. This setting can be changed using the Kokkos package
command.
The reax/c style differs from the pair_style reax
command in the lo-level implementation details. The reax style is a
Fortran library, linked to LAMMPS. The reax/c style was initially
implemented as stand-alone C code and is now integrated into LAMMPS as
a package.
LAMMPS provides several different versions of ffield.reax in its
potentials dir, each called potentials/ffield.reax.label. These are
documented in potentials/README.reax. The default ffield.reax
contains parameterizations for the following elements: C, H, O, N.
The format of these files is identical to that used originally by van
Duin. We have tested the accuracy of pair_style reax/c potential
against the original ReaxFF code for the systems mentioned above. You
can use other ffield files for specific chemical systems that may be
available elsewhere (but note that their accuracy may not have been
tested).
Note
We do not distribute a wide variety of ReaxFF force field files
with LAMMPS. Adri van Duin’s group at PSU is the central repository
for this kind of data as they are continuously deriving and updating
parameterizations for different classes of materials. You can submit
a contact request at the Materials Computation Center (MCC) website
https://www.mri.psu.edu/materials-computation-center/connect-mcc,
describing the material(s) you are interested in modeling with ReaxFF.
They can tell
you what is currently available or what it would take to create a
suitable ReaxFF parameterization.
The cfile setting can be specified as NULL, in which case default
settings are used. A control file can be specified which defines
values of control variables. Some control variables are
global parameters for the ReaxFF potential. Others define certain
performance and output settings.
Each line in the control file specifies the value for
a control variable. The format of the control file is described
below.
Note
The LAMMPS default values for the ReaxFF global parameters
correspond to those used by Adri van Duin’s stand-alone serial
code. If these are changed by setting control variables in the control
file, the results from LAMMPS and the serial code will not agree.
Two examples using pair_style reax/c are provided in the examples/reax
sub-directory, along with corresponding examples for
pair_style reax.
Use of this pair style requires that a charge be defined for every
atom. See the atom_style and
read_data commands for details on how to specify
charges.
The ReaxFF parameter files provided were created using a charge
equilibration (QEq) model for handling the electrostatic interactions.
Therefore, by default, LAMMPS requires that the fix qeq/reax command be used with pair_style reax/c
when simulating a ReaxFF model, to equilibrate charge each timestep.
Using the keyword checkqeq with the value no
turns off the check for fix qeq/reax,
allowing a simulation to be run without charge equilibration.
In this case, the static charges you
assign to each atom will be used for computing the electrostatic
interactions in the system.
See the fix qeq/reax command for details.
Using the optional keyword lgvdw with the value yes turns on
the low-gradient correction of the ReaxFF/C for long-range
London Dispersion, as described in the (Liu) paper. Force field
file ffield.reax.lg is designed for this correction, and is trained
for several energetic materials (see “Liu”). When using lg-correction,
recommended value for parameter thb is 0.01, which can be set in the
control file. Note: Force field files are different for the original
or lg corrected pair styles, using wrong ffield file generates an error message.
Optional keywords safezone and mincap are used for allocating
reax/c arrays. Increasing these values can avoid memory problems, such
as segmentation faults and bondchk failed errors, that could occur under
certain conditions. These keywords aren’t used by the Kokkos version, which
instead uses a more robust memory allocation scheme that checks if the sizes of
the arrays have been exceeded and automatically allocates more memory.
The thermo variable evdwl stores the sum of all the ReaxFF potential
energy contributions, with the exception of the Coulombic and charge
equilibration contributions which are stored in the thermo variable
ecoul. The output of these quantities is controlled by the
thermo command.
This pair style tallies a breakdown of the total ReaxFF potential
energy into sub-categories, which can be accessed via the compute pair command as a vector of values of length 14.
The 14 values correspond to the following sub-categories (the variable
names in italics match those used in the original FORTRAN ReaxFF code):
eb = bond energy
ea = atom energy
elp = lone-pair energy
emol = molecule energy (always 0.0)
ev = valence angle energy
epen = double-bond valence angle penalty
ecoa = valence angle conjugation energy
ehb = hydrogen bond energy
et = torsion energy
eco = conjugation energy
ew = van der Waals energy
ep = Coulomb energy
efi = electric field energy (always 0.0)
eqeq = charge equilibration energy
To print these quantities to the log file (with descriptive column
headings) the following commands could be included in an input script:
Only a single pair_coeff command is used with the reax/c style which
specifies a ReaxFF potential file with parameters for all needed
elements. These are mapped to LAMMPS atom types by specifying N
additional arguments after the filename in the pair_coeff command,
where N is the number of LAMMPS atom types:
filename
N indices = ReaxFF elements
The filename is the ReaxFF potential file. Unlike for the reax
pair style, any filename can be used.
In the ReaxFF potential file, near the top, after the general
parameters, is the atomic parameters section that contains element
names, each with a couple dozen numeric parameters. If there are M
elements specified in the ffield file, think of these as numbered 1
to M. Each of the N indices you specify for the N atom types of LAMMPS
atoms must be an integer from 1 to M. Atoms with LAMMPS type 1 will
be mapped to whatever element you specify as the first index value,
etc. If a mapping value is specified as NULL, the mapping is not
performed. This can be used when the reax/c style is used as part
of the hybrid pair style. The NULL values are placeholders for atom
types that will be used with other potentials.
As an example, say your LAMMPS simulation has 4 atom types and the
elements are ordered as C, H, O, N in the ffield file. If you want
the LAMMPS atom type 1 and 2 to be C, type 3 to be N, and type 4 to be
H, you would use the following pair_coeff command:
pair_coeff * * ffield.reax C C N H
The format of a line in the control file is as follows:
variable_name value
and it may be followed by an ”!” character and a trailing comment.
If the value of a control variable is not specified, then default
values are used. What follows is the list of variables along with a
brief description of their use and default values.
simulation_name: Output files produced by pair_style reax/c carry
this name + extensions specific to their contents. Partial energies
are reported with a ”.pot” extension, while the trajectory file has
”.trj” extension.
tabulate_long_range: To improve performance, long range interactions
can optionally be tabulated (0 means no tabulation). Value of this
variable denotes the size of the long range interaction table. The
range from 0 to long range cutoff (defined in the ffield file) is
divided into tabulate_long_range points. Then at the start of
simulation, we fill in the entries of the long range interaction table
by computing the energies and forces resulting from van der Waals and
Coulomb interactions between every possible atom type pairs present in
the input system. During the simulation we consult to the long range
interaction table to estimate the energy and forces between a pair of
atoms. Linear interpolation is used for estimation. (default value =
0)
energy_update_freq: Denotes the frequency (in number of steps) of
writes into the partial energies file. (default value = 0)
nbrhood_cutoff: Denotes the near neighbors cutoff (in Angstroms)
regarding the bonded interactions. (default value = 5.0)
hbond_cutoff: Denotes the cutoff distance (in Angstroms) for hydrogen
-bond interactions.(default value = 7.5. Value of 0.0 turns off hydrogen
-
-
bonds)
+bond interactions.(default value = 7.5. Value of 0.0 turns off
+hydrogen bonds)
bond_graph_cutoff: is the threshold used in determining what is a
physical bond, what is not. Bonds and angles reported in the
trajectory file rely on this cutoff. (default value = 0.3)
thb_cutoff: cutoff value for the strength of bonds to be considered in
three body interactions. (default value = 0.001)
thb_cutoff_sq: cutoff value for the strength of bond order products
to be considered in three body interactions. (default value = 0.00001)
write_freq: Frequency of writes into the trajectory file. (default
value = 0)
traj_title: Title of the trajectory - not the name of the trajectory
file.
atom_info: 1 means print only atomic positions + charge (default = 0)
atom_forces: 1 adds net forces to atom lines in the trajectory file
(default = 0)
atom_velocities: 1 adds atomic velocities to atoms line (default = 0)
bond_info: 1 prints bonds in the trajectory file (default = 0)
angle_info: 1 prints angles in the trajectory file (default = 0)
This pair style does not support the pair_modify
mix, shift, table, and tail options.
This pair style does not write its information to binary restart files, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.
This pair style can only be used via the pair keyword of the
run_style respa command. It does not support the
inner, middle, outer keywords.
Styles with a gpu, intel, kk, 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 5
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 GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the Making LAMMPS 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 when you invoke LAMMPS, or you can
use the suffix command in your input script.
See Section 5 of the manual for
more instructions on how to use the accelerated styles effectively.
Restrictions
This pair style is part of the USER-REAXC package. It is only enabled
if LAMMPS was built with that package. See the Making LAMMPS section for more info.
The ReaxFF potential files provided with LAMMPS in the potentials
directory are parameterized for real units. You can use
the ReaxFF potential with any LAMMPS units, but you would need to
create your own potential file with coefficients listed in the
appropriate units if your simulation doesn’t use “real” units.
(Liu) L. Liu, Y. Liu, S. V. Zybin, H. Sun and W. A. Goddard, Journal
of Physical Chemistry A, 115, 11016-11022 (2011).
\ No newline at end of file
diff --git a/doc/src/fix_lb_rigid_pc_sphere.txt b/doc/src/fix_lb_rigid_pc_sphere.txt
index 89474d805..bd42978c2 100755
--- a/doc/src/fix_lb_rigid_pc_sphere.txt
+++ b/doc/src/fix_lb_rigid_pc_sphere.txt
@@ -1,146 +1,146 @@
"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
fix lb/rigid/pc/sphere command :h3
[Syntax:]
fix ID group-ID lb/rigid/pc/sphere bodystyle args keyword values ... :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
lb/rigid/pc/sphere = style name of this fix command :l
bodystyle = {single} or {molecule} or {group} :l
{single} args = none
{molecule} args = none
{group} args = N groupID1 groupID2 ...
- N = # of groups
+ N = # of groups :pre
zero or more keyword/value pairs may be appended :l
keyword = {force} or {torque} or {innerNodes} :l
{force} values = M xflag yflag zflag
M = which rigid body from 1-Nbody (see asterisk form below)
xflag,yflag,zflag = off/on if component of center-of-mass force is active
{torque} values = M xflag yflag zflag
M = which rigid body from 1-Nbody (see asterisk form below)
xflag,yflag,zflag = off/on if component of center-of-mass torque is active
{innerNodes} values = innergroup-ID
innergroup-ID = ID of the atom group which does not experience a hydrodynamic force from the lattice-Boltzmann fluid :pre
:ule
[Examples:]
fix 1 spheres lb/rigid/pc/sphere
fix 1 all lb/rigid/pc/sphere force 1 0 0 innerNodes ForceAtoms :pre
[Description:]
This fix is based on the "fix rigid"_fix_rigid.html command, and was
created to be used in place of that fix, to integrate the equations of
motion of spherical rigid bodies when a lattice-Boltzmann fluid is
present with a user-specified value of the force-coupling constant.
The fix uses the integration algorithm described in "Mackay et
al."_#Mackay to update the positions, velocities, and orientations of
a set of spherical rigid bodies experiencing velocity dependent
hydrodynamic forces. The spherical bodies are assumed to rotate as
solid, uniform density spheres, with moments of inertia calculated
using the combined sum of the masses of all the constituent particles
(which are assumed to be point particles).
:line
By default, all of the atoms that this fix acts on experience a
hydrodynamic force due to the presence of the lattice-Boltzmann fluid.
However, the {innerNodes} keyword allows the user to specify atoms
belonging to a rigid object which do not interact with the
lattice-Boltzmann fluid (i.e. these atoms do not feel a hydrodynamic
force from the lattice-Boltzmann fluid). This can be used to
distinguish between atoms on the surface of a non-porous object, and
those on the inside.
This feature can be used, for example, when implementing a hard sphere
interaction between two spherical objects. Instead of interactions
occurring between the particles on the surfaces of the two spheres, it
is desirable simply to place an atom at the center of each sphere,
which does not contribute to the hydrodynamic force, and have these
central atoms interact with one another.
:line
Apart from the features described above, this fix is very similar to
the rigid fix (although it includes fewer optional arguments, and
assumes the constituent atoms are point particles); see
"fix rigid"_fix_rigid.html for a complete documentation.
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about the {rigid} and {rigid/nve} fixes are written to
"binary restart files"_restart.html.
Similar to the "fix rigid"_fix_rigid.html command: The rigid
fix computes a global scalar which can be accessed by various "output
commands"_Section_howto.html#howto_15. The scalar value calculated by
these fixes is "intensive". The scalar is the current temperature of
the collection of rigid bodies. This is averaged over all rigid
bodies and their translational and rotational degrees of freedom. The
translational energy of a rigid body is 1/2 m v^2, where m = total
mass of the body and v = the velocity of its center of mass. The
rotational energy of a rigid body is 1/2 I w^2, where I = the moment
of inertia tensor of the body and w = its angular velocity. Degrees
of freedom constrained by the {force} and {torque} keywords are
removed from this calculation.
All of these fixes compute a global array of values which can be
accessed by various "output commands"_Section_howto.html#howto_15.
The number of rows in the array is equal to the number of rigid
bodies. The number of columns is 15. Thus for each rigid body, 15
values are stored: the xyz coords of the center of mass (COM), the xyz
components of the COM velocity, the xyz components of the force acting
on the COM, the xyz components of the torque acting on the COM, and
the xyz image flags of the COM, which have the same meaning as image
flags for atom positions (see the "dump" command). The force and
torque values in the array are not affected by the {force} and
{torque} keywords in the fix rigid command; they reflect values before
any changes are made by those keywords.
The ordering of the rigid bodies (by row in the array) is as follows.
For the {single} keyword there is just one rigid body. For the
{molecule} keyword, the bodies are ordered by ascending molecule ID.
For the {group} keyword, the list of group IDs determines the ordering
of bodies.
The array values calculated by these fixes are "intensive", meaning
they are independent of the number of atoms in the simulation.
No parameter of these fixes can be used with the {start/stop} keywords
of the "run"_run.html command. These fixes are not invoked during
"energy minimization"_minimize.html.
[Restrictions:]
This fix is part of the USER-LB package. It is only enabled if LAMMPS
was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
Can only be used if a lattice-Boltzmann fluid has been created via the
"fix lb/fluid"_fix_lb_fluid.html command, and must come after this
command. Should only be used if the force coupling constant used in
"fix lb/fluid"_fix_lb_fluid.html has been set by the user; this
integration fix cannot be used if the force coupling constant is set
by default.
[Related commands:]
"fix lb/fluid"_fix_lb_fluid.html, "fix lb/pc"_fix_lb_pc.html
[Default:]
The defaults are force * on on on, and torque * on on on.
:line
:link(Mackay)
[(Mackay et al.)] Mackay, F. E., Ollila, S.T.T., and Denniston, C., Hydrodynamic Forces Implemented into LAMMPS through a lattice-Boltzmann fluid, Computer Physics Communications 184 (2013) 2021-2031.
diff --git a/doc/src/fix_neb.txt b/doc/src/fix_neb.txt
index b80cbae0e..65c9eebb5 100644
--- a/doc/src/fix_neb.txt
+++ b/doc/src/fix_neb.txt
@@ -1,106 +1,106 @@
"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
fix neb command :h3
[Syntax:]
fix ID group-ID neb Kspring :pre
ID, group-ID are documented in "fix"_fix.html command
neb = style name of this fix command
Kspring = inter-replica spring constant (force/distance units) :ul
[Examples:]
fix 1 active neb 10.0 :pre
[Description:]
Add inter-replica forces to atoms in the group for a multi-replica
simulation run via the "neb"_neb.html command to perform a nudged
elastic band (NEB) calculation for transition state finding. Hi-level
explanations of NEB are given with the "neb"_neb.html command and in
"Section 6.5"_Section_howto.html#howto_5 of the manual. The fix
neb command must be used with the "neb" command to define how
inter-replica forces are computed.
Only the N atoms in the fix group experience inter-replica forces.
Atoms in the two end-point replicas do not experience these forces,
but those in intermediate replicas do. During the initial stage of
NEB, the 3N-length vector of interatomic forces Fi = -Grad(V) acting
on the atoms of each intermediate replica I is altered, as described
in the "(Henkelman1)"_#Henkelman1 paper, to become:
-Fi = -Grad(V) + (Grad(V) dot That) That + Kspring (|Ri+i - Ri| - |Ri - Ri-1|) That :pre
+Fi = -Grad(V) + (Grad(V) dot That) That + Kspring (| Ri+i - Ri | - | Ri - Ri-1 |) That :pre
Ri are the atomic coordinates of replica I; Ri-1 and Ri+1 are the
coordinates of its neighbor replicas. That (t with a hat over it) is
the unit "tangent" vector for replica I which is a function of Ri,
Ri-1, Ri+1, and the potential energy of the 3 replicas; it points
roughly in the direction of (Ri+i - Ri-1); see the
"(Henkelman1)"_#Henkelman1 paper for details.
The first two terms in the above equation are the component of the
interatomic forces perpendicular to the tangent vector. The last term
is a spring force between replica I and its neighbors, parallel to the
tangent vector direction with the specified spring constant {Kspring}.
The effect of the first two terms is to push the atoms of each replica
toward the minimum energy path (MEP) of conformational states that
transition over the energy barrier. The MEP for an energy barrier is
defined as a sequence of 3N-dimensional states which cross the barrier
at its saddle point, each of which has a potential energy gradient
parallel to the MEP itself.
The effect of the last term is to push each replica away from its two
neighbors in a direction along the MEP, so that the final set of
states are equidistant from each other.
During the second stage of NEB, the forces on the N atoms in the
replica nearest the top of the energy barrier are altered so that it
climbs to the top of the barrier and finds the saddle point. The
forces on atoms in this replica are described in the
"(Henkelman2)"_#Henkelman2 paper, and become:
Fi = -Grad(V) + 2 (Grad(V) dot That) That :pre
The inter-replica forces for the other replicas are unchanged from the
first equation.
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various "output
commands"_Section_howto.html#howto_15. No parameter of this fix can
be used with the {start/stop} keywords of the "run"_run.html command.
The forces due to this fix are imposed during an energy minimization,
as invoked by the "minimize"_minimize.html command via the
"neb"_neb.html command.
[Restrictions:]
This command can only be used if LAMMPS was built with the REPLICA
package. See the "Making LAMMPS"_Section_start.html#start_3 section
for more info on packages.
[Related commands:]
"neb"_neb.html
[Default:] none
:link(Henkelman)
[(Henkelman1)] Henkelman and Jonsson, J Chem Phys, 113, 9978-9985 (2000).
:link(Henkelman)
[(Henkelman2)] Henkelman, Uberuaga, Jonsson, J Chem Phys, 113,
9901-9904 (2000).
diff --git a/doc/src/fix_tune_kspace.txt b/doc/src/fix_tune_kspace.txt
index 8159e1f5b..d7fe49255 100644
--- a/doc/src/fix_tune_kspace.txt
+++ b/doc/src/fix_tune_kspace.txt
@@ -1,102 +1,100 @@
"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
fix tune/kspace command :h3
[Syntax:]
fix ID group-ID tune/kspace N :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
tune/kspace = style name of this fix command :l
N = invoke this fix every N steps :l
:ule
[Examples:]
fix 2 all tune/kspace 100 :pre
[Description:]
This fix tests each kspace style (Ewald, PPPM, and MSM), and
automatically selects the fastest style to use for the remainder
of the run. If the fastest style is Ewald or PPPM, the fix also
adjusts the coulomb cutoff towards optimal speed. Future versions
of this fix will automatically select other kspace parameters
to use for maximum simulation speed. The kspace parameters may
include the style, cutoff, grid points in each direction, order,
Ewald parameter, MSM parallelization cut-point, MPI tasks to use, etc.
The rationale for this fix is to provide the user with
as-fast-as-possible simulations that include long-range electrostatics
(kspace) while meeting the user-prescribed accuracy requirement. A
simple heuristic could never capture the optimal combination of
parameters for every possible run-time scenario. But by performing
short tests of various kspace parameter sets, this fix allows
parameters to be tailored specifically to the user's machine, MPI
ranks, use of threading or accelerators, the simulated system, and the
simulation details. In addition, it is possible that parameters could
be evolved with the simulation on-the-fly, which is useful for systems
that are dynamically evolving (e.g. changes in box size/shape or
number of particles).
When this fix is invoked, LAMMPS will perform short timed tests of
various parameter sets to determine the optimal parameters. Tests are
performed on-the-fly, with a new test initialized every N steps. N should
be chosen large enough so that adequate CPU time lapses between tests,
thereby providing statistically significant timings. But N should not be
chosen to be so large that an unfortunate parameter set test takes an
inordinate amount of wall time to complete. An N of 100 for most problems
seems reasonable. Once an optimal parameter set is found, that set is
used for the remainder of the run.
This fix uses heristics to guide it's selection of parameter sets to test,
but the actual timed results will be used to decide which set to use in the
simulation.
It is not necessary to discard trajectories produced using sub-optimal
parameter sets, or a mix of various parameter sets, since the user-prescribed
accuracy will have been maintained throughout. However, some users may prefer
to use this fix only to discover the optimal parameter set for a given setup
that can then be used on subsequent production runs.
This fix starts with kspace parameters that are set by the user with the
"kspace_style"_kspace_style.html and "kspace_modify"_kspace_modify.html
commands. The prescribed accuracy will be maintained by this fix throughout
the simulation.
None of the "fix_modify"_fix_modify.html options are relevant to this
fix.
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command. This fix is not invoked during "energy
minimization"_minimize.html.
[Restrictions:]
This fix is part of the KSPACE package. It is only enabled if LAMMPS was
built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
Do not set "neigh_modify once yes" or else this fix will never be
called. Reneighboring is required.
[Related commands:]
"kspace_style"_kspace_style.html, "boundary"_boundary.html
"kspace_modify"_kspace_modify.html, "pair_style
lj/cut/coul/long"_pair_lj.html, "pair_style
lj/charmm/coul/long"_pair_charmm.html, "pair_style
lj/long"_pair_lj_long.html, "pair_style
lj/long/coul/long"_pair_lj_long.html,
"pair_style buck/coul/long"_pair_buck.html
[Default:]
-:line
-
diff --git a/doc/src/molecule.txt b/doc/src/molecule.txt
index 7b8c14fda..f1311a380 100644
--- a/doc/src/molecule.txt
+++ b/doc/src/molecule.txt
@@ -1,468 +1,467 @@
"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
molecule command :h3
[Syntax:]
molecule ID file1 keyword values ... file2 keyword values ... fileN ... :pre
ID = user-assigned name for the molecule template :ulb,l
file1,file2,... = names of files containing molecule descriptions :l
zero or more keyword/value pairs may be appended after each file :l
keyword = {offset} or {toff} or {boff} or {aoff} or {doff} or {ioff} or {scale} :l
{offset} values = Toff Boff Aoff Doff Ioff
Toff = offset to add to atom types
Boff = offset to add to bond types
Aoff = offset to add to angle types
Doff = offset to add to dihedral types
Ioff = offset to add to improper types
{toff} value = Toff
Toff = offset to add to atom types
{boff} value = Boff
Boff = offset to add to bond types
{aoff} value = Aoff
Aoff = offset to add to angle types
{doff} value = Doff
Doff = offset to add to dihedral types
{ioff} value = Ioff
Ioff = offset to add to improper types
{scale} value = sfactor
sfactor = scale factor to apply to the size and mass of the molecule :pre
:ule
[Examples:]
molecule 1 mymol.txt
molecule 1 co2.txt h2o.txt
molecule CO2 co2.txt boff 3 aoff 2
molecule 1 mymol.txt offset 6 9 18 23 14
molecule objects file.1 scale 1.5 file.1 scale 2.0 file.2 scale 1.3 :pre
-:pre
[Description:]
Define a molecule template that can be used as part of other LAMMPS
commands, typically to define a collection of particles as a bonded
molecule or a rigid body. Commands that currently use molecule
templates include:
"fix deposit"_fix_deposit.html
"fix pour"_fix_pour.html
"fix rigid/small"_fix_rigid.html
"fix shake"_fix_shake.html
"fix gcmc"_fix_gcmc.html
"create_atoms"_create_atoms.html
"atom_style template"_atom_style.html :ul
The ID of a molecule template can only contain alphanumeric characters
and underscores.
A single template can contain multiple molecules, listed one per file.
Some of the commands listed above currently use only the first
molecule in the template, and will issue a warning if the template
contains multiple molecules. The "atom_style
template"_atom_style.html command allows multiple-molecule templates
to define a system with more than one templated molecule.
Each filename can be followed by optional keywords which are applied
only to the molecule in the file as used in this template. This is to
make it easy to use the same molecule file in different molecule
templates or in different simulations. You can specify the same file
multiple times with different optional keywords.
The {offset}, {toff}, {aoff}, {doff}, {ioff} keywords add the
specified offset values to the atom types, bond types, angle types,
dihedral types, and/or improper types as they are read from the
molecule file. E.g. if {toff} = 2, and the file uses atom types
1,2,3, then each created molecule will have atom types 3,4,5. For the
{offset} keyword, all five offset values must be specified, but
individual values will be ignored if the molecule template does not
use that attribute (e.g. no bonds).
The {scale} keyword scales the size of the molecule. This can be
useful for modeling polydisperse granular rigid bodies. The scale
factor is applied to each of these properties in the molecule file, if
they are defined: the individual particle coordinates (Coords
section), the individual mass of each particle (Masses section), the
individual diameters of each particle (Diameters section), the total
mass of the molecule (header keyword = mass), the center-of-mass of
the molecule (header keyword = com), and the moments of inertia of the
molecule (header keyword = inertia).
NOTE: The molecule command can be used to define molecules with bonds,
angles, dihedrals, imporopers, or special bond lists of neighbors
within a molecular topology, so that you can later add the molecules
to your simulation, via one or more of the commands listed above. If
such molecules do not already exist when LAMMPS creates the simulation
box, via the "create_box"_create_box.html or
"read_data"_read_data.html command, when you later add them you may
overflow the pre-allocated data structures which store molecular
topology information with each atom, and an error will be generated.
Both the "create_box"_create_box.html command and the data files read
by the "read_data"_read_data.html command have "extra" options which
insure space is allocated for storing topology info for molecules that
are added later.
The format of an individual molecule file is similar to the data file
read by the "read_data"_read_data.html commands, and is as follows.
A molecule file has a header and a body. The header appears first.
The first line of the header is always skipped; it typically contains
a description of the file. Then lines are read one at a time. Lines
can have a trailing comment starting with '#' that is ignored. If the
line is blank (only whitespace after comment is deleted), it is
skipped. If the line contains a header keyword, the corresponding
value(s) is read from the line. If it doesn't contain a header
keyword, the line begins the body of the file.
The body of the file contains zero or more sections. The first line
of a section has only a keyword. The next line is skipped. The
remaining lines of the section contain values. The number of lines
depends on the section keyword as described below. Zero or more blank
lines can be used between sections. Sections can appear in any order,
with a few exceptions as noted below.
These are the recognized header keywords. Header lines can come in
any order. The numeric value(s) are read from the beginning of the
line. The keyword should appear at the end of the line. All these
settings have default values, as explained below. A line need only
appear if the value(s) are different than the default.
N {atoms} = # of atoms N in molecule, default = 0
Nb {bonds} = # of bonds Nb in molecule, default = 0
Na {angles} = # of angles Na in molecule, default = 0
Nd {dihedrals} = # of dihedrals Nd in molecule, default = 0
Ni {impropers} = # of impropers Ni in molecule, default = 0
Mtotal {mass} = total mass of molecule
Xc Yc Zc {com} = coordinates of center-of-mass of molecule
Ixx Iyy Izz Ixy Ixz Iyz {inertia} = 6 components of inertia tensor of molecule :ul
For {mass}, {com}, and {inertia}, the default is for LAMMPS to
calculate this quantity itself if needed, assuming the molecules
consists of a set of point particles or finite-size particles (with a
non-zero diameter) that do not overlap. If finite-size particles in
the molecule do overlap, LAMMPS will not account for the overlap
effects when calculating any of these 3 quantities, so you should
pre-compute them yourself and list the values in the file.
The mass and center-of-mass coordinates (Xc,Yc,Zc) are
self-explanatory. The 6 moments of inertia (ixx,iyy,izz,ixy,ixz,iyz)
should be the values consistent with the current orientation of the
rigid body around its center of mass. The values are with respect to
the simulation box XYZ axes, not with respect to the prinicpal axes of
the rigid body itself. LAMMPS performs the latter calculation
internally.
These are the allowed section keywords for the body of the file.
{Coords, Types, Charges, Diameters, Masses} = atom-property sections
{Bonds, Angles, Dihedrals, Impropers} = molecular topology sections
{Special Bond Counts, Special Bonds} = special neighbor info
{Shake Flags, Shake Atoms, Shake Bond Types} = SHAKE info :ul
If a Bonds section is specified then the Special Bond Counts and
Special Bonds sections can also be used, if desired, to explicitly
list the 1-2, 1-3, 1-4 neighbors within the molecule topology (see
details below). This is optional since if these sections are not
included, LAMMPS will auto-generate this information. Note that
LAMMPS uses this info to properly exclude or weight bonded pairwise
interactions between bonded atoms. See the
"special_bonds"_special_bonds.html command for more details. One
reason to list the special bond info explicitly is for the
"thermalized Drude oscillator model"_tutorial_drude.html which treats
the bonds between nuclear cores and Drude electrons in a different
manner.
NOTE: Whether a section is required depends on how the molecule
template is used by other LAMMPS commands. For example, to add a
molecule via the "fix deposit"_fix_deposit.html command, the Coords
and Types sections are required. To add a rigid body via the "fix
pour"_fix_pour.html command, the Bonds (Angles, etc) sections are not
required, since the molecule will be treated as a rigid body. Some
sections are optional. For example, the "fix pour"_fix_pour.html
command can be used to add "molecules" which are clusters of
finite-size granular particles. If the Diameters section is not
specified, each particle in the molecule will have a default diameter
of 1.0. See the doc pages for LAMMPS commands that use molecule
templates for more details.
Each section is listed below in alphabetic order. The format of each
section is described including the number of lines it must contain and
rules (if any) for whether it can appear in the data file. In each
case the ID is ignored; it is simply included for readability, and
should be a number from 1 to Nlines for the section, indicating which
atom (or bond, etc) the entry applies to. The lines are assumed to be
listed in order from 1 to Nlines, but LAMMPS does not check for this.
:line
{Coords} section:
one line per atom
line syntax: ID x y z
x,y,z = coordinate of atom :ul
:line
{Types} section:
one line per atom
line syntax: ID type
type = atom type of atom :ul
:line
{Charges} section:
one line per atom
line syntax: ID q
q = charge on atom :ul
This section is only allowed for "atom styles"_atom_style.html that
support charge. If this section is not included, the default charge
on each atom in the molecule is 0.0.
:line
{Diameters} section:
one line per atom
line syntax: ID diam
diam = diameter of atom :ul
This section is only allowed for "atom styles"_atom_style.html that
support finite-size spherical particles, e.g. atom_style sphere. If
not listed, the default diameter of each atom in the molecule is 1.0.
:line
{Masses} section:
one line per atom
line syntax: ID mass
mass = mass of atom :ul
This section is only allowed for "atom styles"_atom_style.html that
support per-atom mass, as opposed to per-type mass. See the
"mass"_mass.html command for details. If this section is not
included, the default mass for each atom is derived from its volume
(see Diameters section) and a default density of 1.0, in
"units"_units.html of mass/volume.
:line
{Bonds} section:
one line per bond
line syntax: ID type atom1 atom2
type = bond type (1-Nbondtype)
atom1,atom2 = IDs of atoms in bond :ul
The IDs for the two atoms in each bond should be values
from 1 to Natoms, where Natoms = # of atoms in the molecule.
:line
{Angles} section:
one line per angle
line syntax: ID type atom1 atom2 atom3
type = angle type (1-Nangletype)
atom1,atom2,atom3 = IDs of atoms in angle :ul
The IDs for the three atoms in each angle should be values from 1 to
Natoms, where Natoms = # of atoms in the molecule. The 3 atoms are
ordered linearly within the angle. Thus the central atom (around
which the angle is computed) is the atom2 in the list.
:line
{Dihedrals} section:
one line per dihedral
line syntax: ID type atom1 atom2 atom3 atom4
type = dihedral type (1-Ndihedraltype)
atom1,atom2,atom3,atom4 = IDs of atoms in dihedral :ul
The IDs for the four atoms in each dihedral should be values from 1 to
Natoms, where Natoms = # of atoms in the molecule. The 4 atoms are
ordered linearly within the dihedral.
:line
{Impropers} section:
one line per improper
line syntax: ID type atom1 atom2 atom3 atom4
type = improper type (1-Nimpropertype)
atom1,atom2,atom3,atom4 = IDs of atoms in improper :ul
The IDs for the four atoms in each improper should be values from 1 to
Natoms, where Natoms = # of atoms in the molecule. The ordering of
the 4 atoms determines the definition of the improper angle used in
the formula for the defined "improper style"_improper_style.html. See
the doc pages for individual styles for details.
:line
{Special Bond Counts} section:
one line per atom
line syntax: ID N1 N2 N3
N1 = # of 1-2 bonds
N2 = # of 1-3 bonds
N3 = # of 1-4 bonds :ul
N1, N2, N3 are the number of 1-2, 1-3, 1-4 neighbors respectively of
this atom within the topology of the molecule. See the
"special_bonds"_special_bonds.html doc page for more discussion of
1-2, 1-3, 1-4 neighbors. If this section appears, the Special Bonds
section must also appear.
As explained above, LAMMPS will auto-generate this information if this
section is not specified. If specified, this section will
override what would be auto-generated.
:line
{Special Bonds} section:
one line per atom
line syntax: ID a b c d ...
a,b,c,d,... = IDs of atoms in N1+N2+N3 special bonds :ul
A, b, c, d, etc are the IDs of the n1+n2+n3 atoms that are 1-2, 1-3,
1-4 neighbors of this atom. The IDs should be values from 1 to
Natoms, where Natoms = # of atoms in the molecule. The first N1
values should be the 1-2 neighbors, the next N2 should be the 1-3
neighbors, the last N3 should be the 1-4 neighbors. No atom ID should
appear more than once. See the "special_bonds"_special_bonds.html doc
page for more discussion of 1-2, 1-3, 1-4 neighbors. If this section
appears, the Special Bond Counts section must also appear.
As explained above, LAMMPS will auto-generate this information if this
section is not specified. If specified, this section will override
what would be auto-generated.
:line
{Shake Flags} section:
one line per atom
line syntax: ID flag
flag = 0,1,2,3,4 :ul
This section is only needed when molecules created using the template
will be constrained by SHAKE via the "fix shake" command. The other
two Shake sections must also appear in the file, following this one.
The meaning of the flag for each atom is as follows. See the "fix
shake"_fix_shake.html doc page for a further description of SHAKE
clusters.
0 = not part of a SHAKE cluster
1 = part of a SHAKE angle cluster (two bonds and the angle they form)
2 = part of a 2-atom SHAKE cluster with a single bond
3 = part of a 3-atom SHAKE cluster with two bonds
4 = part of a 4-atom SHAKE cluster with three bonds :ul
:line
{Shake Atoms} section:
one line per atom
line syntax: ID a b c d
a,b,c,d = IDs of atoms in cluster :ul
This section is only needed when molecules created using the template
will be constrained by SHAKE via the "fix shake" command. The other
two Shake sections must also appear in the file.
The a,b,c,d values are atom IDs (from 1 to Natoms) for all the atoms
in the SHAKE cluster that this atom belongs to. The number of values
that must appear is determined by the shake flag for the atom (see the
Shake Flags section above). All atoms in a particular cluster should
list their a,b,c,d values identically.
If flag = 0, no a,b,c,d values are listed on the line, just the
(ignored) ID.
If flag = 1, a,b,c are listed, where a = ID of central atom in the
angle, and b,c the other two atoms in the angle.
If flag = 2, a,b are listed, where a = ID of atom in bond with the the
lowest ID, and b = ID of atom in bond with the highest ID.
If flag = 3, a,b,c are listed, where a = ID of central atom,
and b,c = IDs of other two atoms bonded to the central atom.
If flag = 4, a,b,c,d are listed, where a = ID of central atom,
and b,c,d = IDs of other three atoms bonded to the central atom.
See the "fix shake"_fix_shake.html doc page for a further description
of SHAKE clusters.
:line
{Shake Bond Types} section:
one line per atom
line syntax: ID a b c
a,b,c = bond types (or angle type) of bonds (or angle) in cluster :ul
This section is only needed when molecules created using the template
will be constrained by SHAKE via the "fix shake" command. The other
two Shake sections must also appear in the file.
The a,b,c values are bond types (from 1 to Nbondtypes) for all bonds
in the SHAKE cluster that this atom belongs to. The number of values
that must appear is determined by the shake flag for the atom (see the
Shake Flags section above). All atoms in a particular cluster should
list their a,b,c values identically.
If flag = 0, no a,b,c values are listed on the line, just the
(ignored) ID.
If flag = 1, a,b,c are listed, where a = bondtype of the bond between
the central atom and the first non-central atom (value b in the Shake
Atoms section), b = bondtype of the bond between the central atom and
the 2nd non-central atom (value c in the Shake Atoms section), and c =
the angle type (1 to Nangletypes) of the angle between the 3 atoms.
If flag = 2, only a is listed, where a = bondtype of the bond between
the 2 atoms in the cluster.
If flag = 3, a,b are listed, where a = bondtype of the bond between
the central atom and the first non-central atom (value b in the Shake
Atoms section), and b = bondtype of the bond between the central atom
and the 2nd non-central atom (value c in the Shake Atoms section).
If flag = 4, a,b,c are listed, where a = bondtype of the bond between
the central atom and the first non-central atom (value b in the Shake
Atoms section), b = bondtype of the bond between the central atom and
the 2nd non-central atom (value c in the Shake Atoms section), and c =
bondtype of the bond between the central atom and the 3rd non-central
atom (value d in the Shake Atoms section).
See the "fix shake"_fix_shake.html doc page for a further description
of SHAKE clusters.
:line
[Restrictions:] none
[Related commands:]
"fix deposit"_fix_deposit.html, "fix pour"_fix_pour.html,
"fix gcmc"_fix_gcmc.html
[Default:]
The default keywords values are offset 0 0 0 0 0 and scale = 1.0.
diff --git a/doc/src/pair_reax_c.txt b/doc/src/pair_reax_c.txt
index 6963f7b02..c7f62aedf 100644
--- a/doc/src/pair_reax_c.txt
+++ b/doc/src/pair_reax_c.txt
@@ -1,347 +1,347 @@
"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 reax/c command :h3
pair_style reax/c/kk command :h3
[Syntax:]
pair_style reax/c cfile keyword value :pre
cfile = NULL or name of a control file :ulb,l
zero or more keyword/value pairs may be appended :l
keyword = {checkqeq} or {lgvdw} or {safezone} or {mincap}
{checkqeq} value = {yes} or {no} = whether or not to require qeq/reax fix
{lgvdw} value = {yes} or {no} = whether or not to use a low gradient vdW correction
{safezone} = factor used for array allocation
{mincap} = minimum size for array allocation :pre
:ule
[Examples:]
pair_style reax/c NULL
pair_style reax/c controlfile checkqeq no
pair_style reax/c NULL lgvdw yes
pair_style reax/c NULL safezone 1.6 mincap 100
pair_coeff * * ffield.reax C H O N :pre
[Description:]
Style {reax/c} computes the ReaxFF potential of van Duin, Goddard and
co-workers. ReaxFF uses distance-dependent bond-order functions to
represent the contributions of chemical bonding to the potential
energy. There is more than one version of ReaxFF. The version
implemented in LAMMPS uses the functional forms documented in the
supplemental information of the following paper: "(Chenoweth et al.,
2008)"_#Chenoweth_2008. The version integrated into LAMMPS matches
the most up-to-date version of ReaxFF as of summer 2010. For more
technical details about the pair reax/c implementation of ReaxFF, see
the "(Aktulga)"_#Aktulga paper.
The {reax/c/kk} style is a Kokkos version of the ReaxFF potential that is
derived from the {reax/c} style. The Kokkos version can run on GPUs and
can also use OpenMP multithreading. For more information about the Kokkos package,
see "Section 4"_Section_packages.html#kokkos and "Section 5.3.3"_accelerate_kokkos.html.
One important consideration when using the {reax/c/kk} style is the choice of either
half or full neighbor lists. This setting can be changed using the Kokkos "package"_package.html
command.
The {reax/c} style differs from the "pair_style reax"_pair_reax.html
command in the lo-level implementation details. The {reax} style is a
Fortran library, linked to LAMMPS. The {reax/c} style was initially
implemented as stand-alone C code and is now integrated into LAMMPS as
a package.
LAMMPS provides several different versions of ffield.reax in its
potentials dir, each called potentials/ffield.reax.label. These are
documented in potentials/README.reax. The default ffield.reax
contains parameterizations for the following elements: C, H, O, N.
The format of these files is identical to that used originally by van
Duin. We have tested the accuracy of {pair_style reax/c} potential
against the original ReaxFF code for the systems mentioned above. You
can use other ffield files for specific chemical systems that may be
available elsewhere (but note that their accuracy may not have been
tested).
NOTE: We do not distribute a wide variety of ReaxFF force field files
with LAMMPS. Adri van Duin's group at PSU is the central repository
for this kind of data as they are continuously deriving and updating
parameterizations for different classes of materials. You can submit
a contact request at the Materials Computation Center (MCC) website
"https://www.mri.psu.edu/materials-computation-center/connect-mcc"_https://www.mri.psu.edu/materials-computation-center/connect-mcc,
describing the material(s) you are interested in modeling with ReaxFF.
They can tell
you what is currently available or what it would take to create a
suitable ReaxFF parameterization.
The {cfile} setting can be specified as NULL, in which case default
settings are used. A control file can be specified which defines
values of control variables. Some control variables are
global parameters for the ReaxFF potential. Others define certain
performance and output settings.
Each line in the control file specifies the value for
a control variable. The format of the control file is described
below.
NOTE: The LAMMPS default values for the ReaxFF global parameters
correspond to those used by Adri van Duin's stand-alone serial
code. If these are changed by setting control variables in the control
file, the results from LAMMPS and the serial code will not agree.
Two examples using {pair_style reax/c} are provided in the examples/reax
sub-directory, along with corresponding examples for
"pair_style reax"_pair_reax.html.
Use of this pair style requires that a charge be defined for every
atom. See the "atom_style"_atom_style.html and
"read_data"_read_data.html commands for details on how to specify
charges.
The ReaxFF parameter files provided were created using a charge
equilibration (QEq) model for handling the electrostatic interactions.
Therefore, by default, LAMMPS requires that the "fix
qeq/reax"_fix_qeq_reax.html command be used with {pair_style reax/c}
when simulating a ReaxFF model, to equilibrate charge each timestep.
Using the keyword {checkqeq} with the value {no}
turns off the check for {fix qeq/reax},
allowing a simulation to be run without charge equilibration.
In this case, the static charges you
assign to each atom will be used for computing the electrostatic
interactions in the system.
See the "fix qeq/reax"_fix_qeq_reax.html command for details.
Using the optional keyword {lgvdw} with the value {yes} turns on
the low-gradient correction of the ReaxFF/C for long-range
London Dispersion, as described in the "(Liu)"_#Liu_2011 paper. Force field
file {ffield.reax.lg} is designed for this correction, and is trained
for several energetic materials (see "Liu"). When using lg-correction,
recommended value for parameter {thb} is 0.01, which can be set in the
control file. Note: Force field files are different for the original
or lg corrected pair styles, using wrong ffield file generates an error message.
Optional keywords {safezone} and {mincap} are used for allocating
reax/c arrays. Increasing these values can avoid memory problems, such
as segmentation faults and bondchk failed errors, that could occur under
certain conditions. These keywords aren't used by the Kokkos version, which
instead uses a more robust memory allocation scheme that checks if the sizes of
the arrays have been exceeded and automatically allocates more memory.
The thermo variable {evdwl} stores the sum of all the ReaxFF potential
energy contributions, with the exception of the Coulombic and charge
equilibration contributions which are stored in the thermo variable
{ecoul}. The output of these quantities is controlled by the
"thermo"_thermo.html command.
This pair style tallies a breakdown of the total ReaxFF potential
energy into sub-categories, which can be accessed via the "compute
pair"_compute_pair.html command as a vector of values of length 14.
The 14 values correspond to the following sub-categories (the variable
names in italics match those used in the original FORTRAN ReaxFF code):
{eb} = bond energy
{ea} = atom energy
{elp} = lone-pair energy
{emol} = molecule energy (always 0.0)
{ev} = valence angle energy
{epen} = double-bond valence angle penalty
{ecoa} = valence angle conjugation energy
{ehb} = hydrogen bond energy
{et} = torsion energy
{eco} = conjugation energy
{ew} = van der Waals energy
{ep} = Coulomb energy
{efi} = electric field energy (always 0.0)
{eqeq} = charge equilibration energy :ol
To print these quantities to the log file (with descriptive column
headings) the following commands could be included in an input script:
compute reax all pair reax/c
variable eb equal c_reax\[1\]
variable ea equal c_reax\[2\]
\[...\]
variable eqeq equal c_reax\[14\]
thermo_style custom step temp epair v_eb v_ea ... v_eqeq :pre
Only a single pair_coeff command is used with the {reax/c} style which
specifies a ReaxFF potential file with parameters for all needed
elements. These are mapped to LAMMPS atom types by specifying N
additional arguments after the filename in the pair_coeff command,
where N is the number of LAMMPS atom types:
filename
N indices = ReaxFF elements :ul
The filename is the ReaxFF potential file. Unlike for the {reax}
pair style, any filename can be used.
In the ReaxFF potential file, near the top, after the general
parameters, is the atomic parameters section that contains element
names, each with a couple dozen numeric parameters. If there are M
elements specified in the {ffield} file, think of these as numbered 1
to M. Each of the N indices you specify for the N atom types of LAMMPS
atoms must be an integer from 1 to M. Atoms with LAMMPS type 1 will
be mapped to whatever element you specify as the first index value,
etc. If a mapping value is specified as NULL, the mapping is not
performed. This can be used when the {reax/c} style is used as part
of the {hybrid} pair style. The NULL values are placeholders for atom
types that will be used with other potentials.
As an example, say your LAMMPS simulation has 4 atom types and the
elements are ordered as C, H, O, N in the {ffield} file. If you want
the LAMMPS atom type 1 and 2 to be C, type 3 to be N, and type 4 to be
H, you would use the following pair_coeff command:
pair_coeff * * ffield.reax C C N H :pre
:line
The format of a line in the control file is as follows:
variable_name value :pre
and it may be followed by an "!" character and a trailing comment.
If the value of a control variable is not specified, then default
values are used. What follows is the list of variables along with a
brief description of their use and default values.
simulation_name: Output files produced by {pair_style reax/c} carry
this name + extensions specific to their contents. Partial energies
are reported with a ".pot" extension, while the trajectory file has
".trj" extension.
tabulate_long_range: To improve performance, long range interactions
can optionally be tabulated (0 means no tabulation). Value of this
variable denotes the size of the long range interaction table. The
range from 0 to long range cutoff (defined in the {ffield} file) is
divided into {tabulate_long_range} points. Then at the start of
simulation, we fill in the entries of the long range interaction table
by computing the energies and forces resulting from van der Waals and
Coulomb interactions between every possible atom type pairs present in
the input system. During the simulation we consult to the long range
interaction table to estimate the energy and forces between a pair of
atoms. Linear interpolation is used for estimation. (default value =
0)
energy_update_freq: Denotes the frequency (in number of steps) of
writes into the partial energies file. (default value = 0)
nbrhood_cutoff: Denotes the near neighbors cutoff (in Angstroms)
regarding the bonded interactions. (default value = 5.0)
hbond_cutoff: Denotes the cutoff distance (in Angstroms) for hydrogen
-bond interactions.(default value = 7.5. Value of 0.0 turns off hydrogen
- bonds)
+bond interactions.(default value = 7.5. Value of 0.0 turns off
+hydrogen bonds)
bond_graph_cutoff: is the threshold used in determining what is a
physical bond, what is not. Bonds and angles reported in the
trajectory file rely on this cutoff. (default value = 0.3)
thb_cutoff: cutoff value for the strength of bonds to be considered in
three body interactions. (default value = 0.001)
thb_cutoff_sq: cutoff value for the strength of bond order products
to be considered in three body interactions. (default value = 0.00001)
write_freq: Frequency of writes into the trajectory file. (default
value = 0)
traj_title: Title of the trajectory - not the name of the trajectory
file.
atom_info: 1 means print only atomic positions + charge (default = 0)
atom_forces: 1 adds net forces to atom lines in the trajectory file
(default = 0)
atom_velocities: 1 adds atomic velocities to atoms line (default = 0)
bond_info: 1 prints bonds in the trajectory file (default = 0)
angle_info: 1 prints angles in the trajectory file (default = 0)
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
This pair style does not support the "pair_modify"_pair_modify.html
mix, shift, table, and tail options.
This pair style does not write its information to "binary restart
files"_restart.html, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.
This pair style can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. It does not support the
{inner}, {middle}, {outer} keywords.
:line
Styles with a {gpu}, {intel}, {kk}, {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 5"_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 GPU, USER-INTEL, KOKKOS,
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 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This pair style is part of the USER-REAXC package. It is only enabled
if LAMMPS was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
The ReaxFF potential files provided with LAMMPS in the potentials
directory are parameterized for real "units"_units.html. You can use
the ReaxFF potential with any LAMMPS units, but you would need to
create your own potential file with coefficients listed in the
appropriate units if your simulation doesn't use "real" units.
[Related commands:]
"pair_coeff"_pair_coeff.html, "fix qeq/reax"_fix_qeq_reax.html, "fix
reax/c/bonds"_fix_reax_bonds.html, "fix
reax/c/species"_fix_reaxc_species.html, "pair_style
reax"_pair_reax.html
[Default:]
The keyword defaults are checkqeq = yes, lgvdw = no, safezone = 1.2,
mincap = 50.
:line
:link(Chenoweth_2008)
[(Chenoweth_2008)] Chenoweth, van Duin and Goddard,
Journal of Physical Chemistry A, 112, 1040-1053 (2008).
:link(Aktulga)
(Aktulga) Aktulga, Fogarty, Pandit, Grama, Parallel Computing, 38,
245-259 (2012).
:link(Liu_2011)
[(Liu)] L. Liu, Y. Liu, S. V. Zybin, H. Sun and W. A. Goddard, Journal
of Physical Chemistry A, 115, 11016-11022 (2011).
diff --git a/doc/src/read_restart.txt b/doc/src/read_restart.txt
index 6acc0ad4a..0e50b4028 100644
--- a/doc/src/read_restart.txt
+++ b/doc/src/read_restart.txt
@@ -1,256 +1,254 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
read_restart command :h3
[Syntax:]
read_restart file flag :pre
file = name of binary restart file to read in
flag = remap (optional) :ul
[Examples:]
read_restart save.10000
read_restart save.10000 remap
read_restart restart.*
read_restart restart.*.mpiio
read_restart poly.*.% remap :pre
-:pre
-
[Description:]
Read in a previously saved system configuration from a restart file.
This allows continuation of a previous run. Details about what
information is stored (and not stored) in a restart file is given
below. Basically this operation will re-create the simulation box
with all its atoms and their attributes as well as some related global
settings, at the point in time it was written to the restart file by a
previous simluation. The simulation box will be partitioned into a
regular 3d grid of rectangular bricks, one per processor, based on the
number of processors in the current simulation and the settings of the
"processors"_processors.html command. The partitioning can later be
changed by the "balance"_balance.html or "fix
balance"_fix_balance.html commands.
NOTE: Normally, restart files are written by the
"restart"_restart.html or "write_restart"_write_restart.html commands
so that all atoms in the restart file are inside the simulation box.
If this is not the case, the read_restart command will print an error
that atoms were "lost" when the file is read. This error should be
reported to the LAMMPS developers so the invalid writing of the
restart file can be fixed. If you still wish to use the restart file,
the optional {remap} flag can be appended to the read_restart command.
This should avoid the error, by explicitly remapping each atom back
into the simulation box, updating image flags for the atom
appropriately.
Restart files are saved in binary format to enable exact restarts,
meaning that the trajectories of a restarted run will precisely match
those produced by the original run had it continued on.
Several things can prevent exact restarts due to round-off effects, in
which case the trajectories in the 2 runs will slowly diverge. These
include running on a different number of processors or changing
certain settings such as those set by the "newton"_newton.html or
"processors"_processors.html commands. LAMMPS will issue a warning in
these cases.
Certain fixes will not restart exactly, though they should provide
statistically similar results. These include "fix
shake"_fix_shake.html and "fix langevin"_fix_langevin.html.
Certain pair styles will not restart exactly, though they should
provide statistically similar results. This is because the forces
they compute depend on atom velocities, which are used at half-step
values every timestep when forces are computed. When a run restarts,
forces are initially evaluated with a full-step velocity, which is
different than if the run had continued. These pair styles include
"granular pair styles"_pair_gran.html, "pair dpd"_pair_dpd.html, and
"pair lubricate"_pair_lubricate.html.
If a restarted run is immediately different than the run which
produced the restart file, it could be a LAMMPS bug, so consider
"reporting it"_Section_errors.html#err_2 if you think the behavior is
wrong.
Because restart files are binary, they may not be portable to other
machines. In this case, you can use the "-restart command-line
switch"_Section_start.html#start_7 to convert a restart file to a data
file.
Similar to how restart files are written (see the
"write_restart"_write_restart.html and "restart"_restart.html
commands), the restart filename can contain two wild-card characters.
If a "*" appears in the filename, the directory is searched for all
filenames that match the pattern where "*" is replaced with a timestep
value. The file with the largest timestep value is read in. Thus,
this effectively means, read the latest restart file. It's useful if
you want your script to continue a run from where it left off. See
the "run"_run.html command and its "upto" option for how to specify
the run command so it doesn't need to be changed either.
If a "%" character appears in the restart filename, LAMMPS expects a
set of multiple files to exist. The "restart"_restart.html and
"write_restart"_write_restart.html commands explain how such sets are
created. Read_restart will first read a filename where "%" is
replaced by "base". This file tells LAMMPS how many processors
created the set and how many files are in it. Read_restart then reads
the additional files. For example, if the restart file was specified
as save.% when it was written, then read_restart reads the files
save.base, save.0, save.1, ... save.P-1, where P is the number of
processors that created the restart file.
Note that P could be the total number of processors in the previous
simulation, or some subset of those processors, if the {fileper} or
{nfile} options were used when the restart file was written; see the
"restart"_restart.html and "write_restart"_write_restart.html commands
for details. The processors in the current LAMMPS simulation share
the work of reading these files; each reads a roughly equal subset of
the files. The number of processors which created the set can be
different the number of processors in the current LAMMPS simulation.
This can be a fast mode of input on parallel machines that support
parallel I/O.
A restart file can also be read in parallel as one large binary file
via the MPI-IO library, assuming it was also written with MPI-IO.
MPI-IO is part of the MPI standard for versions 2.0 and above. Using
MPI-IO requires two steps. First, build LAMMPS with its MPIIO package
installed, e.g.
make yes-mpiio # installs the MPIIO package
make g++ # build LAMMPS for your platform :pre
Second, use a restart filename which contains ".mpiio". Note that it
does not have to end in ".mpiio", just contain those characters.
Unlike MPI-IO dump files, a particular restart file must be both
written and read using MPI-IO.
:line
Here is the list of information included in a restart file, which
means these quantities do not need to be re-specified in the input
script that reads the restart file, though you can redefine many of
these settings after the restart file is read.
"units"_units.html
"newton bond"_newton.html (see discussion of newton command below)
"atom style"_atom_style.html and "atom_modify"_atom_modify.html settings id, map, sort
"comm style"_comm_style.html and "comm_modify"_comm_modify settings mode, cutoff, vel
"timestep"_timestep.html
simulation box size and shape and "boundary"_boundary.html settings
atom "group"_group.html definitions
per-type atom settings such as "mass"_mass.thml
per-atom attributes including their group assignments and molecular topology attributes (bonds, angles, etc)
force field styles ("pair"_pair_style.html, "bond"_bond_style.html, "angle"_angle_style.html, etc)
force field coefficients ("pair"_pair_coeff.html, "bond"_bond_coeff.html, "angle"_angle_coeff.html, etc) in some cases (see below)
"pair_modify"_pair_modify.html settings, except the compute option
"special_bonds"_special_bonds.html settings :ul
Here is a list of information not stored in a restart file, which
means you must re-issue these commands in your input script, after
reading the restart file.
"newton pair"_newton.html (see discussion of newton command below)
"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 "newton"_newton.html command has two settings, one for pairwise
interactions, the other for bonded. Both settings are stored in the
restart file. For the bond setting, the value in the file will
overwrite the current value (at the time the read_restart command is
issued) and warn if the two values are not the same and the current
value is not the default. For the pair setting, the value in the file
will not overwrite the current value (so that you can override the
previous run's value), but a warning is issued if the two values are
not the same and the current value is not the default.
Note that some force field styles (pair, bond, angle, etc) do not
store their coefficient info in restart files. Typically these are
many-body or tabulated potentials which read their parameters from
separate files. In these cases you will need to re-specify the "pair
"pair_coeff"_pair_coeff.html, "bond_coeff"_bond_coeff.html, etc
commands in your restart input script. The doc pages for individual
force field styles mention if this is the case. This is also true of
"pair_style hybrid"_pair_hybrid.html (bond hybrid, angle hybrid, etc)
commands; they do not store coefficient info.
As indicated in the above list, the "fixes"_fix.html used for a
simulation are not stored in the restart file. This means the new
input script should specify all fixes it will use. However, note that
some fixes store an internal "state" which is written to the restart
file. This allows the fix to continue on with its calculations in a
restarted simulation. To re-enable such a fix, the fix command in the
new input script must use the same fix-ID and group-ID as was used in
the input script that wrote the restart file. If a match is found,
LAMMPS prints a message indicating that the fix is being re-enabled.
If no match is found before the first run or minimization is performed
by the new script, the "state" information for the saved fix is
discarded. See the doc pages for individual fixes for info on which
ones can be restarted in this manner.
Likewise, the "computes"_fix.html used for a simulation are not stored
in the restart file. This means the new input script should specify
all computes it will use. However, some computes create a fix
internally to store "state" information that persists from timestep to
timestep. An example is the "compute msd"_compute_msd.html command
which uses a fix to store a reference coordinate for each atom, so
that a displacement can be calculated at any later time. If the
compute command in the new input script uses the same compute-ID and
group-ID as was used in the input script that wrote the restart file,
then it will create the same fix in the restarted run. This means the
re-created fix will be re-enabled with the stored state information as
described in the previous paragraph, so that the compute can continue
its calculations in a consistent manner.
Some pair styles, like the "granular pair styles"_pair_gran.html, also
use a fix to store "state" information that persists from timestep to
timestep. In the case of granular potentials, it is contact
information between pairs of touching particles. This info will also
be re-enabled in the restart script, assuming you re-use the same
granular pair style.
LAMMPS allows bond interactions (angle, etc) to be turned off or
deleted in various ways, which can affect how their info is stored in
a restart file.
If bonds (angles, etc) have been turned off by the "fix
shake"_fix_shake.html or "delete_bonds"_delete_bonds.html command,
their info will be written to a restart file as if they are turned on.
This means they will need to be turned off again in a new run after
the restart file is read.
Bonds that are broken (e.g. by a bond-breaking potential) are written
to the restart file as broken bonds with a type of 0. Thus these
bonds will still be broken when the restart file is read.
Bonds that have been broken by the "fix
bond/break"_fix_bond_break.html command have disappeared from the
system. No information about these bonds is written to the restart
file.
:line
[Restrictions:]
To write and read restart files in parallel with MPI-IO, the MPIIO
package must be installed.
[Related commands:]
"read_data"_read_data.html, "read_dump"_read_dump.html,
"write_restart"_write_restart.html, "restart"_restart.html
[Default:] none