ICODE-ADC/lammps
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'lammps:develop' into cg-dna

Browse Source
This commit is contained in:
Oliver Henrich
2024-04-19 22:07:32 +01:00
committed by GitHub
parent 5b47038b14 6836bca5f8
commit 52ab29798a
646 changed files with 69565 additions and 36911 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
doc/src/Build_extras.rst
View File

@ -533,9 +533,6 @@ They must be specified in uppercase.
* - A64FX
- HOST
- ARMv8.2 with SVE Support
* - WSM
- HOST
- Intel Westmere CPU (SSE 4.2)
* - SNB
- HOST
- Intel Sandy/Ivy Bridge CPU (AVX 1)
@ -566,18 +563,15 @@ They must be specified in uppercase.
* - KNL
- HOST
- Intel Knights Landing Xeon Phi
* - BGQ
- HOST
- IBM Blue Gene/Q CPU
* - POWER7
- HOST
- IBM POWER7 CPU
* - POWER8
- HOST
- IBM POWER8 CPU
* - POWER9
- HOST
- IBM POWER9 CPU
* - RISCV_SG2042
- HOST
- SG2042 (RISC-V) CPU
* - KEPLER30
- GPU
- NVIDIA Kepler generation CC 3.0 GPU
@ -666,7 +660,7 @@ They must be specified in uppercase.
- GPU
- Intel GPU Ponte Vecchio
This list was last updated for version 4.2 of the Kokkos library.
This list was last updated for version 4.3.0 of the Kokkos library.
.. tabs::

2
doc/src/Commands_bond.rst
View File

@ -89,6 +89,7 @@ OPT.
* :doc:`cosine/shift (o) <angle_cosine_shift>`
* :doc:`cosine/shift/exp (o) <angle_cosine_shift_exp>`
* :doc:`cosine/squared (o) <angle_cosine_squared>`
* :doc:`cosine/squared/restricted (o) <angle_cosine_squared_restricted>`
* :doc:`cross <angle_cross>`
* :doc:`dipole (o) <angle_dipole>`
* :doc:`fourier (o) <angle_fourier>`
@ -127,6 +128,7 @@ OPT.
* :doc:`charmmfsw (k) <dihedral_charmm>`
* :doc:`class2 (ko) <dihedral_class2>`
* :doc:`cosine/shift/exp (o) <dihedral_cosine_shift_exp>`
* :doc:`cosine/squared/restricted <dihedral_cosine_squared_restricted>`
* :doc:`fourier (io) <dihedral_fourier>`
* :doc:`harmonic (iko) <dihedral_harmonic>`
* :doc:`helix (o) <dihedral_helix>`

1
doc/src/Commands_pair.rst
View File

@ -245,6 +245,7 @@ OPT.
* :doc:`oxrna2/coaxstk <pair_oxrna2>`
* :doc:`pace (k) <pair_pace>`
* :doc:`pace/extrapolation (k) <pair_pace>`
* :doc:`pedone (o) <pair_pedone>`
* :doc:`pod <pair_pod>`
* :doc:`peri/eps <pair_peri>`
* :doc:`peri/lps (o) <pair_peri>`

6
doc/src/Errors_messages.rst
View File

@ -7883,12 +7883,6 @@ keyword to allow for additional bonds to be formed
Fix poems cannot (yet) work with coupled bodies whose joints connect
the bodies in a tree structure.
*Triclinic box skew is too large*
The displacement in a skewed direction must be less than half the box
length in that dimension. E.g. the xy tilt must be between -half and
+half of the x box length. This constraint can be relaxed by using
the box tilt command.
*Tried to convert a double to int, but input_double > INT_MAX*
Self-explanatory.

7
doc/src/Errors_warnings.rst
View File

@ -752,13 +752,6 @@ This will most likely cause errors in kinetic fluctuations.
More than the maximum # of neighbors was found multiple times. This
was unexpected.
*Triclinic box skew is large*
The displacement in a skewed direction is normally required to be less
than half the box length in that dimension. E.g. the xy tilt must be
between -half and +half of the x box length. You have relaxed the
constraint using the box tilt command, but the warning means that a
LAMMPS simulation may be inefficient as a result.
*Use special bonds = 0,1,1 with bond style fene*
Most FENE models need this setting for the special_bonds command.

124
doc/src/Howto_2d.rst
View File

@ -1,42 +1,112 @@
2d simulations
==============
================
2d simulations
================
Use the :doc:`dimension <dimension>` command to specify a 2d simulation.
You must use the :doc:`dimension <dimension>` command to specify a 2d
simulation. The default is 3d.
Make the simulation box periodic in z via the :doc:`boundary <boundary>`
command. This is the default.
A 2d simulation box must be periodic in z as set by the :doc:`boundary
<boundary>` command. This is the default.
If using the :doc:`create_box <create_box>` command to define a
simulation box, set the z dimensions narrow, but finite, so that the
:doc:`create_atoms <create_atoms>` command will fill the 3d simulation
box with a single z plane of atoms - e.g.
Simulation boxes in LAMMPS can be either orthogonal or triclinic in
shape. Orthogonal boxes in 2d are a rectangle with 4 edges that are
each perpendicular to either the x or y coordinate axes. Triclinic
boxes in 2d are a parallelogram with opposite pairs of faces parallel
to each other. LAMMPS supports two forms of triclinic boxes,
restricted and general, which for 2d differ in how the box is oriented
with respect to the xy coordinate axes. See the :doc:`Howto triclinic
<Howto_triclinic>` for a detailed description of all 3 kinds of
simulation boxes.
Here are examples of using the :doc:`create_box <create_box>` command
to define the simulation box for a 2d system.
.. code-block:: LAMMPS
create_box 1 -10 10 -10 10 -0.25 0.25
# 2d orthogonal box using a block-style region
region mybox block -10 10 0 10 -0.5 0.5
create_box 1 mybox
If using the :doc:`read_data <read_data>` command to read in a file of
atom coordinates, set the "zlo zhi" values to be finite but narrow,
similar to the create_box command settings just described. For each
atom in the file, assign a z coordinate so it falls inside the
z-boundaries of the box - e.g. 0.0.
# 2d restricted triclinic box using a prism-style region with only xy tilt
region mybox prism 0 10 0 10 -0.5 0.5 2.0 0.0 0.0
create_box 1 mybox
Use the :doc:`fix enforce2d <fix_enforce2d>` command as the last
defined fix to ensure that the z-components of velocities and forces
are zeroed out every timestep. The reason to make it the last fix is
so that any forces induced by other fixes will be zeroed out.
# 2d general triclinic box using a primitive cell for a 2d hex lattice
lattice custom 1.0 a1 1.0 0.0 0.0 a2 0.5 0.86602540378 0.0 &
a3 0.0 0.0 1.0 basis 0.0 0.0 0.0 triclinic/general
create_box 1 NULL 0 5 0 5 -0.5 0.5
Many of the example input scripts included in the LAMMPS distribution
Note that for 2d orthogonal or restricted triclinic boxes, the box has
a 3rd dimension which must straddle z = 0.0 in the z dimension.
Typically the width of box in the z dimension should be narrow,
e.g. -0.5 to 0.5, but that is not required. For a 2d general
triclinic box, the *a3* vector defined by the :doc:`lattice <lattice>`
command must be (0.0,0.0,1.0), which is its default value. Also the
*clo* and *chi* arguments of the :doc:`create_box <create_box>`
command must be -0.5 and 0.5.
Here are examples of using the :doc:`read_data <read_data>` command
to define the simulation box for a 2d system via keywords in the
header section of the data file. These are the same boxes as the examples
for the :doc:`create_box <create_box>` command
.. code-block:: LAMMPS
# 2d orthogonal box
-10 10 xlo xhi
0 10 ylo yhi
-0.5 0.5 zlo zhi # this is the default, so no need to specify
# 2d restricted triclinic box with only xy tilt
-10 10 xlo xhi
0 10 ylo yhi
-0.5 0.5 zlo zhi # this is the default, so no need to specify
2.0 0.0 0.0 xy xz yz
# 3d general triclinic box using a primitive cell for a 2d hex lattice
5 0 0 avec
2.5 4.3301270189 0 bvec
0 0 1 cvec # this is the default, so no need to specify
0 0 -0.5 abc origin # this is the default for 2d, so no need to specify
Note that for 2d orthogonal or restricted triclinic boxes, the box has
a 3rd dimension specified by the *zlo zhi* values, which must straddle
z = 0.0. Typically the width of box in the z dimension should be
narrow, e.g. -0.5 to 0.5, but that is not required. For a 2d general
triclinic box, the z component of *avec* and *bvec* must be zero, and
*cvec* must be (0,0,1), which is the default. The z component of *abc
origin* must also be -0.5, which is the default.
If using the :doc:`create_atoms <create_atoms>` command to create
atoms in the 2d simulation box, all the z coordinates of created atoms
will be zero.
If using the :doc:`read_data <read_data>` command to read in a data
file of atom coordinates for a 2d system, the z coordinates of all
atoms should be zero. A value within epsilon of zero is also allowed
in case the data file was generated by another program with finite
numeric precision, in which case the z coord for the atom will be set
to zero.
Use the :doc:`fix enforce2d <fix_enforce2d>` command as the last fix
defined in the input script. It ensures that the z-components of
velocities and forces are zeroed out every timestep. The reason to
make it the last fix is so that any forces added by other fixes will
also be zeroed out.
Many of the example input scripts included in the examples directory
are for 2d models.
.. note::
Some models in LAMMPS treat particles as finite-size spheres, as
opposed to point particles. See the :doc:`atom_style sphere <atom_style>` and :doc:`fix nve/sphere <fix_nve_sphere>`
commands for details. By default, for 2d simulations, such particles
will still be modeled as 3d spheres, not 2d discs (circles), meaning
opposed to point particles. See the :doc:`atom_style sphere
<atom_style>` and :doc:`fix nve/sphere <fix_nve_sphere>` commands
for details. By default, for 2d simulations, such particles will
still be modeled as 3d spheres, not 2d discs (circles), meaning
their moment of inertia will be that of a sphere. If you wish to
model them as 2d discs, see the :doc:`set density/disc <set>` command
and the *disc* option for the :doc:`fix nve/sphere <fix_nve_sphere>`,
:doc:`fix nvt/sphere <fix_nvt_sphere>`, :doc:`fix nph/sphere <fix_nph_sphere>`, :doc:`fix npt/sphere <fix_npt_sphere>`
commands.
model them as 2d discs, see the :doc:`set density/disc <set>`
command and the *disc* option for the :doc:`fix nve/sphere
<fix_nve_sphere>`, :doc:`fix nvt/sphere <fix_nvt_sphere>`,
:doc:`fix nph/sphere <fix_nph_sphere>`, :doc:`fix npt/sphere
<fix_npt_sphere>` commands.

33
doc/src/Howto_body.rst
View File

@ -102,8 +102,19 @@ particles of different styles
| :doc:`dump image <dump_image>` | output body particle attributes as an image |
+------------------------------------------------+-----------------------------------------------------+
The pair styles defined for use with specific body styles are listed
in the sections below.
The pair styles currently defined for use with specific body styles
are listed in the sections below.
Note that for all the body styles, if the data file defines a general
triclinic box, then the orientation of the body particle and its
corresponding 6 moments of inertia and other orientation-dependent
values should reflect the fact the body is defined withing a general
triclinic box with edge vectors **A**,**B**,**C**. LAMMPS will rotate
the box to convert it to a restricted triclinic box. This operation
will also rotate the orientation of the body particles. See the
:doc:`Howto triclinic <Howto_triclinic>` doc page for more details.
The sections below highlight the orientation-dependent values specific
to each body style.
----------
@ -154,12 +165,18 @@ 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 principal axes of the
rigid body itself. LAMMPS performs the latter calculation internally.
The coordinates of each sub-particle are specified as its x,y,z
displacement from the center-of-mass of the body particle. The
center-of-mass position of the particle is specified by the x,y,z
values in the *Atoms* section of the data file, as is the total mass
of the body particle.
Note that if the data file defines a general triclinic simulation box,
these sub-particle displacements are orientation-dependent and, as
mentioned above, should reflect the body particle's orientation within
the general triclinic box.
The :doc:`pair_style body/nparticle <pair_body_nparticle>` command can be used
with this body style to compute body/body and body/non-body interactions.
@ -226,6 +243,7 @@ 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 principal axes of the
rigid body itself. LAMMPS performs the latter calculation internally.
The coordinates of each vertex are specified as its x,y,z displacement
from the center-of-mass of the body particle. The center-of-mass
position of the particle is specified by the x,y,z values in the
@ -270,6 +288,11 @@ A disk, whose diameter is 3.0, mass 1.0, is specified as follows:
0 0 0
3.0
Note that if the data file defines a general triclinic simulation box,
these polygon vertex displacements are orientation-dependent and, as
mentioned above, should reflect the body particle's orientation within
the general triclinic box.
The :doc:`pair_style body/rounded/polygon <pair_body_rounded_polygon>`
command can be used with this body style to compute body/body
interactions. The :doc:`fix wall/body/polygon <fix_wall_body_polygon>`
@ -366,6 +389,7 @@ 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 principal axes of the
rigid body itself. LAMMPS performs the latter calculation internally.
The coordinates of each vertex are specified as its x,y,z displacement
from the center-of-mass of the body particle. The center-of-mass
position of the particle is specified by the x,y,z values in the
@ -435,6 +459,11 @@ A sphere whose diameter is 3.0 and mass 1.0, is specified as follows:
The number of edges and faces for a rod or sphere must be listed,
but is ignored.
Note that if the data file defines a general triclinic simulation box,
these polyhedron vertex displacements are orientation-dependent and,
as mentioned above, should reflect the body particle's orientation
within the general triclinic box.
The :doc:`pair_style body/rounded/polhedron
<pair_body_rounded_polyhedron>` command can be used with this body
style to compute body/body interactions. The :doc:`fix

431
doc/src/Howto_triclinic.rst
View File

@ -2,43 +2,195 @@ Triclinic (non-orthogonal) simulation boxes
===========================================
By default, LAMMPS uses an orthogonal simulation box to encompass the
particles. The :doc:`boundary <boundary>` command sets the boundary
conditions of the box (periodic, non-periodic, etc). The orthogonal
box has its "origin" at (xlo,ylo,zlo) and is defined by 3 edge vectors
starting from the origin given by **a** = (xhi-xlo,0,0); **b** =
(0,yhi-ylo,0); **c** = (0,0,zhi-zlo). The 6 parameters
particles. The orthogonal box has its "origin" at (xlo,ylo,zlo) and
extends to (xhi,yhi,zhi). Conceptually it is defined by 3 edge
vectors starting from the origin given by **A** = (xhi-xlo,0,0); **B**
= (0,yhi-ylo,0); **C** = (0,0,zhi-zlo). The :doc:`boundary
<boundary>` command sets the boundary conditions for the 6 faces of
the box (periodic, non-periodic, etc). The 6 parameters
(xlo,xhi,ylo,yhi,zlo,zhi) are defined at the time the simulation box
is created, e.g. by the :doc:`create_box <create_box>` or
:doc:`read_data <read_data>` or :doc:`read_restart <read_restart>`
commands. Additionally, LAMMPS defines box size parameters lx,ly,lz
where lx = xhi-xlo, and similarly in the y and z dimensions. The 6
parameters, as well as lx,ly,lz, can be output via the
:doc:`thermo_style custom <thermo_style>` command.
is created by one of these commands:
LAMMPS also allows simulations to be performed in triclinic
(non-orthogonal) simulation boxes shaped as a parallelepiped with
triclinic symmetry. The parallelepiped has its "origin" at
(xlo,ylo,zlo) and is defined by 3 edge vectors starting from the
origin given by **a** = (xhi-xlo,0,0); **b** = (xy,yhi-ylo,0); **c** =
(xz,yz,zhi-zlo). *xy,xz,yz* can be 0.0 or positive or negative values
and are called "tilt factors" because they are the amount of
displacement applied to faces of an originally orthogonal box to
transform it into the parallelepiped. In LAMMPS the triclinic
simulation box edge vectors **a**, **b**, and **c** cannot be arbitrary
vectors. As indicated, **a** must lie on the positive x axis. **b** must
lie in the xy plane, with strictly positive y component. **c** may have
any orientation with strictly positive z component. The requirement
that **a**, **b**, and **c** have strictly positive x, y, and z components,
respectively, ensures that **a**, **b**, and **c** form a complete
right-handed basis. These restrictions impose no loss of generality,
since it is possible to rotate/invert any set of 3 crystal basis
vectors so that they conform to the restrictions.
* :doc:`create_box <create_box>`
* :doc:`read_data <read_data>`
* :doc:`read_restart <read_restart>`
* :doc:`read_dump <read_dump>`
For example, assume that the 3 vectors **A**,\ **B**,\ **C** are the edge
vectors of a general parallelepiped, where there is no restriction on
**A**,\ **B**,\ **C** other than they form a complete right-handed basis i.e.
**A** x **B** . **C** > 0. The equivalent LAMMPS **a**,\ **b**,\ **c** are a linear
rotation of **A**, **B**, and **C** and can be computed as follows:
Internally, LAMMPS defines box size parameters lx,ly,lz where lx =
xhi-xlo, and similarly in the y and z dimensions. The 6 parameters, as
well as lx,ly,lz, can be output via the :doc:`thermo_style custom
<thermo_style>` command. See the :doc:`Howto 2d <Howto_2d>` doc page
for info on how zlo and zhi are defined for 2d simulations.
----------
Triclinic simulation boxes
""""""""""""""""""""""""""
LAMMPS also allows simulations to be performed using triclinic
(non-orthogonal) simulation boxes shaped as a 3d parallelepiped with
triclinic symmetry. For 2d simulations a triclinic simulation box is
effectively a parallelogram; see the :doc:`Howto 2d <Howto_2d>` doc
page for details.
One use of triclinic simulation boxes is to model solid-state crystals
with triclinic symmetry. The :doc:`lattice <lattice>` command can be
used with non-orthogonal basis vectors to define a lattice that will
tile a triclinic simulation box via the :doc:`create_atoms
<create_atoms>` command.
A second use is to run Parrinello-Rahman dynamics via the :doc:`fix
npt <fix_nh>` command, which will adjust the xy, xz, yz tilt factors
to compensate for off-diagonal components of the pressure tensor. The
analog for an :doc:`energy minimization <minimize>` is the :doc:`fix
box/relax <fix_box_relax>` command.
A third use is to shear a bulk solid to study the response of the
material. The :doc:`fix deform <fix_deform>` command can be used for
this purpose. It allows dynamic control of the xy, xz, yz tilt
factors as a simulation runs. This is discussed in the :doc:`Howto
NEMD <Howto_nemd>` doc page on non-equilibrium MD (NEMD) simulations.
Conceptually, a triclinic parallelepiped is defined with an "origin"
at (xlo,ylo,zhi) and 3 edge vectors **A** = (ax,ay,az), **B** =
(bx,by,bz), **C** = (cx,cy,cz) which can be arbitrary vectors, so long
as they are non-zero, distinct, and not co-planar. In addition, they
must define a right-handed system, such that (**A** cross **B**)
points in the direction of **C**. Note that a left-handed system can
be converted to a right-handed system by simply swapping the order of
any pair of the **A**, **B**, **C** vectors.
The 4 commands listed above for defining orthogonal simulation boxes
have triclinic options which allow for specification of the origin and
edge vectors **A**, **B**, **C**. For each command, this can be done
in one of two ways, for what LAMMPS calls a *general* triclinic box or
a *restricted* triclinic box.
A *general* triclinic box is specified by an origin (xlo, ylo, zlo)
and arbitrary edge vectors **A** = (ax,ay,az), **B** = (bx,by,bz), and
**C** = (cx,cy,cz). So there are 12 parameters in total.
A *restricted* triclinic box also has an origin (xlo,ylo,zlo), but its
edge vectors are of the following restricted form: **A** =
(xhi-xlo,0,0), **B** = (xy,yhi-ylo,0), **C** = (xz,yz,zhi-zlo). So
there are 9 parameters in total. Note that the restricted form
requires **A** to be along the x-axis, **B** to be in the xy plane
with a y-component in the +y direction, and **C** to have its
z-component in the +z direction. Note that a restricted triclinic box
is *right-handed* by construction since (**A** cross **B**) points in
the direction of **C**.
The *xy,xz,yz* values can be zero or positive or negative. They are
called "tilt factors" because they are the amount of displacement
applied to edges of faces of an orthogonal box to change it into a
restricted triclinic parallelepiped.
.. note::
Any right-handed general triclinic box (i.e. solid-state crystal
basis vectors) can be rotated in 3d around its origin in order to
conform to the LAMMPS definition of a restricted triclinic box.
See the discussion in the next sub-section about general triclinic
simulation boxes in LAMMPS.
Note that the :doc:`thermo_style custom <thermo_style>` command has
keywords for outputting the various parameters that define the size
and shape of orthogonal, restricted triclinic, and general triclinic
simulation boxes.
For orthogonal boxes there 6 thermo keywords (xlo,ylo,zlo) and
(xhi,yhi,zhi).
For restricted triclinic boxes there are 9 thermo keywords for
(xlo,ylo,zlo), (xhi,yhi,zhi), and the (xy,xz,yz) tilt factors.
For general triclinic boxes there are 12 thermo keywords for
(xlo,ylo,zhi) and the components of the **A**, **B**, **C** edge
vectors, namely (avecx,avecy,avecz), (bvecx,bvecy,bvecz), and
(cvecx,cvecy,cvecz),
The remainder of this doc page explains (a) how LAMMPS operates with
general triclinic simulation boxes, (b) mathematical transformations
between general and restricted triclinic boxes which may be useful
when creating LAMMPS inputs or interpreting outputs for triclinic
simulations, and (c) how LAMMPS uses tilt factors for restricted
triclinic simulation boxes.
----------
General triclinic simulation boxes in LAMMPS
""""""""""""""""""""""""""""""""""""""""""""
LAMMPS allows specification of general triclinic simulation boxes with
their atoms as a convenience for users who may be converting data from
solid-state crystallographic representations or from DFT codes for
input to LAMMPS. Likewise it allows output of dump files, data files,
and thermodynamic data (e.g. pressure tensor) in a general triclinic
format.
However internally, LAMMPS only uses restricted triclinic simulation
boxes. This is for parallel efficiency and to formulate partitioning
of the simulation box across processors, neighbor list building, and
inter-processor communication of per-atom data with methods similar to
those used for orthogonal boxes.
This means 4 things which are important to understand:
* Input of a general triclinic system is immediately converted to a
restricted triclinic system.
* If output of per-atom data for a general triclinic system is
requested (e.g. for atom coordinates in a dump file),
conversion from a restricted to general triclinic system is done at
the time of output.
* The conversion of the simulation box and per-atom data from general
triclinic to restricted triclinic (and vice versa) is a 3d rotation
operation around an origin, which is the lower left corner of the
simulation box. This means an input data file for a general
triclinic system should specify all per-atom quantities consistent
with the general triclinic box and its orientation relative to the
standard x,y,z coordinate axes. For example, atom coordinates
should be inside the general triclinic simulation box defined by the
edge vectors **A**, **B**, **C** and its origin. Likewise per-atom
velocities should be in directions consistent with the general
triclinic box orientation. E.g. a velocity vector which will be in
the +x direction once LAMMPS converts from a general to restricted
triclinic box, should be specified in the data file in the direction
of the **A** edge vector. See the :doc:`read_data <read_data>` doc
page for info on all the per-atom vector quantities to which this
rule applies when a data file for a general triclinic box is input.
* If commands such as :doc:`write_data <write_data>` or :doc:`dump
custom <dump>` are used to output general triclinic information, it
is effectively the inverse of the operation described in the
preceding bullet.
* Other LAMMPS commands such as :doc:`region <region>` or
:doc:`velocity <velocity>` or :doc:`set <set>`, operate on a
restricted triclinic system even if a general triclinic system was
defined initially.
This is the list of commands which have general triclinic options:
* :doc:`create_box <create_box>` - define a general triclinic box
* :doc:`create_atoms <create_atoms>` - add atoms to a general triclinic box
* :doc:`lattice <lattice>` - define a custom lattice consistent with the **A**, **B**, **C** edge vectors of a general triclinic box
* :doc:`read_data <read_data>` - read a data file for a general triclinic system
* :doc:`write_data <write_data>` - write a data file for a general triclinic system
* :doc:`dump atom, dump custom <dump>` - output dump snapshots in general triclinic format
* :doc:`dump_modify triclinic/general <dump_modify>` - select general triclinic format for dump output
* :doc:`thermo_style <thermo_style>` - output the pressure tensor in
general triclinic format
* :doc:`thermo_modify triclinic/general <thermo_modify>` - select general triclinic format for thermo output
* :doc:`read_restart <read_restart>` - read a restart file for a general triclinic system
* :doc:`write_restart <read_restart>` - write a restart file for a general triclinic system
----------
Transformation from general to restricted triclinic boxes
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Let **A**,\ **B**,\ **C** be the right-handed edge vectors of a
general triclinic simulation box. The equivalent LAMMPS **a**,\
**b**,\ **c** for a restricted triclinic box are a 3d rotation of
**A**, **B**, and **C** and can be computed as follows:
.. math::
@ -55,23 +207,17 @@ rotation of **A**, **B**, and **C** and can be computed as follows:
c_y = & \mathbf{C} \cdot \widehat{(\mathbf{A} \times \mathbf{B})} \times \mathbf{\hat{A}} \quad = \quad \frac{\mathbf{B} \cdot \mathbf{C} - b_x c_x}{b_y} \\
c_z = & |\mathbf{C} \cdot \widehat{(\mathbf{A} \times \mathbf{B})}|\quad = \quad \sqrt{C^2 - {c_x}^2 - {c_y}^2}
where A = \| **A** \| indicates the scalar length of **A**\ . The hat symbol (\^)
indicates the corresponding unit vector. :math:`\beta` and :math:`\gamma` are angles
between the vectors described below. Note that by construction,
**a**, **b**, and **c** have strictly positive x, y, and z components, respectively.
If it should happen that
**A**, **B**, and **C** form a left-handed basis, then the above equations
are not valid for **c**\ . In this case, it is necessary
to first apply an inversion. This can be achieved
by interchanging two basis vectors or by changing the sign of one of them.
where A = \| **A** \| indicates the scalar length of **A**\ . The hat
symbol (\^) indicates the corresponding unit vector. :math:`\beta` and
:math:`\gamma` are angles between the **A**, **B**, **C** vectors
as described below.
For consistency, the same rotation/inversion applied to the basis vectors
must also be applied to atom positions, velocities,
and any other vector quantities.
This can be conveniently achieved by first converting to
fractional coordinates in the
old basis and then converting to distance coordinates in the new basis.
The transformation is given by the following equation:
For consistency, the same rotation applied to the triclinic box edge
vectors can also be applied to atom positions, velocities, and other
vector quantities. This can be conveniently achieved by first
converting to fractional coordinates in the general triclinic
coordinates and then converting to coordinates in the restricted
triclinic basis. The transformation is given by the following equation:
.. math::
@ -82,87 +228,24 @@ The transformation is given by the following equation:
\mathbf{A \times B}
\end{pmatrix} \cdot \mathbf{X}
where *V* is the volume of the box, **X** is the original vector quantity and
**x** is the vector in the LAMMPS basis.
where *V* is the volume of the box (same in either basis), **X** is
the fractional vector in the general triclinic basis and **x** is the
resulting vector in the restricted triclinic basis.
There is no requirement that a triclinic box be periodic in any
dimension, though it typically should be in at least the second dimension
of the tilt (y in xy) if you want to enforce a shift in periodic
boundary conditions across that boundary. Some commands that work
with triclinic boxes, e.g. the :doc:`fix deform <fix_deform>` and :doc:`fix npt <fix_nh>` commands, require periodicity or non-shrink-wrap
boundary conditions in specific dimensions. See the command doc pages
for details.
----------
The 9 parameters (xlo,xhi,ylo,yhi,zlo,zhi,xy,xz,yz) are defined at the
time the simulation box is created. This happens in one of 3 ways.
If the :doc:`create_box <create_box>` command is used with a region of
style *prism*, then a triclinic box is setup. See the
:doc:`region <region>` command for details. If the
:doc:`read_data <read_data>` command is used to define the simulation
box, and the header of the data file contains a line with the "xy xz
yz" keyword, then a triclinic box is setup. See the
:doc:`read_data <read_data>` command for details. Finally, if the
:doc:`read_restart <read_restart>` command reads a restart file which
was written from a simulation using a triclinic box, then a triclinic
box will be setup for the restarted simulation.
Crystallographic general triclinic representation of a simulation box
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Note that you can define a triclinic box with all 3 tilt factors =
0.0, so that it is initially orthogonal. This is necessary if the box
will become non-orthogonal, e.g. due to the :doc:`fix npt <fix_nh>` or
:doc:`fix deform <fix_deform>` commands. Alternatively, you can use the
:doc:`change_box <change_box>` command to convert a simulation box from
orthogonal to triclinic and vice versa.
As with orthogonal boxes, LAMMPS defines triclinic box size parameters
lx,ly,lz where lx = xhi-xlo, and similarly in the y and z dimensions.
The 9 parameters, as well as lx,ly,lz, can be output via the
:doc:`thermo_style custom <thermo_style>` command.
To avoid extremely tilted boxes (which would be computationally
inefficient), LAMMPS normally requires that no tilt factor can skew
the box more than half the distance of the parallel box length, which
is the first dimension in the tilt factor (x for xz). This is required
both when the simulation box is created, e.g. via the
:doc:`create_box <create_box>` or :doc:`read_data <read_data>` commands,
as well as when the box shape changes dynamically during a simulation,
e.g. via the :doc:`fix deform <fix_deform>` or :doc:`fix npt <fix_nh>`
commands.
For example, if xlo = 2 and xhi = 12, then the x box length is 10 and
the xy tilt factor must be between -5 and 5. Similarly, both xz and
yz must be between -(xhi-xlo)/2 and +(yhi-ylo)/2. Note that this is
not a limitation, since if the maximum tilt factor is 5 (as in this
example), then configurations with tilt = ..., -15, -5, 5, 15, 25,
... are geometrically all equivalent. If the box tilt exceeds this
limit during a dynamics run (e.g. via the :doc:`fix deform <fix_deform>`
command), then the box is "flipped" to an equivalent shape with a tilt
factor within the bounds, so the run can continue. See the :doc:`fix deform <fix_deform>` page for further details.
One exception to this rule is if the first dimension in the tilt
factor (x for xy) is non-periodic. In that case, the limits on the
tilt factor are not enforced, since flipping the box in that dimension
does not change the atom positions due to non-periodicity. In this
mode, if you tilt the system to extreme angles, the simulation will
simply become inefficient, due to the highly skewed simulation box.
Box flips that may occur using the :doc:`fix deform <fix_deform>` or
:doc:`fix npt <fix_nh>` commands can be turned off using the *flip no*
option with either of the commands.
Note that if a simulation box has a large tilt factor, LAMMPS will run
less efficiently, due to the large volume of communication needed to
acquire ghost atoms around a processor's irregular-shaped subdomain.
For extreme values of tilt, LAMMPS may also lose atoms and generate an
error.
Triclinic crystal structures are often defined using three lattice
constants *a*, *b*, and *c*, and three angles :math:`\alpha`,
:math:`\beta`, and :math:`\gamma`. Note that in this nomenclature,
the a, b, and c lattice constants are the scalar lengths of the edge
General triclinic crystal structures are often defined using three
lattice constants *a*, *b*, and *c*, and three angles :math:`\alpha`,
:math:`\beta`, and :math:`\gamma`. Note that in this nomenclature, the
a, b, and c lattice constants are the scalar lengths of the edge
vectors **a**, **b**, and **c** defined above. The relationship
between these 6 quantities (a, b, c, :math:`\alpha`, :math:`\beta`,
:math:`\gamma`) and the LAMMPS box sizes (lx,ly,lz) =
(xhi-xlo,yhi-ylo,zhi-zlo) and tilt factors (xy,xz,yz) is as follows:
:math:`\gamma`) and the LAMMPS restricted triclinic box sizes
(lx,ly,lz) = (xhi-xlo,yhi-ylo,zhi-zlo) and tilt factors (xy,xz,yz) is
as follows:
.. math::
@ -186,15 +269,19 @@ The inverse relationship can be written as follows:
The values of *a*, *b*, *c*, :math:`\alpha` , :math:`\beta`, and
:math:`\gamma` can be printed out or accessed by computes using the
:doc:`thermo_style custom <thermo_style>` keywords
*cella*, *cellb*, *cellc*, *cellalpha*, *cellbeta*, *cellgamma*,
respectively.
:doc:`thermo_style custom <thermo_style>` keywords *cella*, *cellb*,
*cellc*, *cellalpha*, *cellbeta*, *cellgamma*, respectively.
----------
Output of restricted and general triclinic boxes in a dump file
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
As discussed on the :doc:`dump <dump>` command doc page, when the BOX
BOUNDS for a snapshot is written to a dump file for a triclinic box,
an orthogonal bounding box which encloses the triclinic simulation box
is output, along with the 3 tilt factors (xy, xz, yz) of the triclinic
box, formatted as follows:
BOUNDS for a snapshot is written to a dump file for a restricted
triclinic box, an orthogonal bounding box which encloses the triclinic
simulation box is output, along with the 3 tilt factors (xy, xz, yz) of
the restricted triclinic box, formatted as follows:
.. parsed-literal::
@ -204,7 +291,7 @@ box, formatted as follows:
zlo_bound zhi_bound yz
This bounding box is convenient for many visualization programs and is
calculated from the 9 triclinic box parameters
calculated from the 9 restricted triclinic box parameters
(xlo,xhi,ylo,yhi,zlo,zhi,xy,xz,yz) as follows:
.. parsed-literal::
@ -217,22 +304,66 @@ calculated from the 9 triclinic box parameters
zhi_bound = zhi
These formulas can be inverted if you need to convert the bounding box
back into the triclinic box parameters, e.g. xlo = xlo_bound -
MIN(0.0,xy,xz,xy+xz).
back into the restricted triclinic box parameters, e.g. xlo =
xlo_bound - MIN(0.0,xy,xz,xy+xz).
One use of triclinic simulation boxes is to model solid-state crystals
with triclinic symmetry. The :doc:`lattice <lattice>` command can be
used with non-orthogonal basis vectors to define a lattice that will
tile a triclinic simulation box via the
:doc:`create_atoms <create_atoms>` command.
----------
A second use is to run Parrinello-Rahman dynamics via the :doc:`fix npt <fix_nh>` command, which will adjust the xy, xz, yz tilt
factors to compensate for off-diagonal components of the pressure
tensor. The analog for an :doc:`energy minimization <minimize>` is
the :doc:`fix box/relax <fix_box_relax>` command.
Periodicity and tilt factors for triclinic simulation boxes
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
A third use is to shear a bulk solid to study the response of the
material. The :doc:`fix deform <fix_deform>` command can be used for
this purpose. It allows dynamic control of the xy, xz, yz tilt
factors as a simulation runs. This is discussed in the next section
on non-equilibrium MD (NEMD) simulations.
There is no requirement that a triclinic box be periodic in any
dimension, though it typically should be in y or z if you wish to
enforce a shift in coordinates due to periodic boundary conditions
across the y or z boundaries. See the doc page for the :doc:`boundary
<boundary>` command for an explanation of shifted coordinates for
restricted triclinic boxes which are periodic.
Some commands that work with triclinic boxes, e.g. the :doc:`fix
deform <fix_deform>` and :doc:`fix npt <fix_nh>` commands, require
periodicity or non-shrink-wrap boundary conditions in specific
dimensions. See the command doc pages for details.
A restricted triclinic box can be defined with all 3 tilt factors =
0.0, so that it is initially orthogonal. This is necessary if the box
will become non-orthogonal, e.g. due to use of the :doc:`fix npt
<fix_nh>` or :doc:`fix deform <fix_deform>` commands. Alternatively,
you can use the :doc:`change_box <change_box>` command to convert a
simulation box from orthogonal to restricted triclinic and vice versa.
.. note::
Highly tilted restricted triclinic simulation boxes can be
computationally inefficient. This is due to the large volume of
communication needed to acquire ghost atoms around a processor's
irregular-shaped subdomain. For extreme values of tilt, LAMMPS may
also lose atoms and generate an error.
LAMMPS will issue a warning if you define a restricted triclinic box
with a tilt factor which skews the box more than half the distance of
the parallel box length, which is the first dimension in the tilt
factor (e.g. x for xz).
For example, if xlo = 2 and xhi = 12, then the x box length is 10 and
the xy tilt factor should be between -5 and 5 to avoid the warning.
Similarly, both xz and yz should be between -(xhi-xlo)/2 and
+(yhi-ylo)/2. Note that these are not limitations, since if the
maximum tilt factor is 5 (as in this example), then simulations boxes
and atom configurations with tilt = ..., -15, -5, 5, 15, 25, ... are
all geometrically equivalent.
If the box tilt exceeds this limit during a dynamics run (e.g. due to
the :doc:`fix deform <fix_deform>` command), then by default the box
is "flipped" to an equivalent shape with a tilt factor within the
warning bounds, and the run continues. See the :doc:`fix deform
<fix_deform>` page for further details. Box flips that would normally
occur using the :doc:`fix deform <fix_deform>` or :doc:`fix npt
<fix_nh>` commands can be suppressed using the *flip no* option with
either of the commands.
One exception to box flipping is if the first dimension in the tilt
factor (e.g. x for xy) is non-periodic. In that case, the limits on
the tilt factor are not enforced, since flipping the box in that
dimension would not change the atom positions due to non-periodicity.
In this mode, if the system tilts to large angles, the simulation will
simply become inefficient, due to the highly skewed simulation box.

25
doc/src/Howto_type_labels.rst
View File

@ -14,16 +14,17 @@ wherever they appear in LAMMPS input or output files. The total number
Ntypes for each interaction is "locked in" when the simulation box
is created.
A recent addition to LAMMPS is the option to use strings - referred
to as type labels - as an alternative. Using type labels instead of
A recent addition to LAMMPS is the option to use strings - referred to
as type labels - as an alternative. Using type labels instead of
numeric types can be advantageous in various scenarios. For example,
type labels can make inputs more readable and generic (i.e. usable through
the :doc:`include command <include>` for different systems with different
numerical values assigned to types. This generality also applies to
other inputs like data files read by :doc:`read_data <read_data>` or
molecule template files read by the :doc:`molecule <molecule>`
command. See below for a list of other commands that can use
type labels in different ways.
type labels can make inputs more readable and generic (i.e. usable
through the :doc:`include command <include>` for different systems with
different numerical values assigned to types. This generality also
applies to other inputs like data files read by :doc:`read_data
<read_data>` or molecule template files read by the :doc:`molecule
<molecule>` command. A discussion of the current type label support can
be found in :ref:`(Gissinger) <Typelabel24>`. See below for a list of
other commands that can use type labels in different ways.
LAMMPS will *internally* continue to use numeric types, which means
that many previous restrictions still apply. For example, the total
@ -124,3 +125,9 @@ between the files. The creation of simulation-ready reaction templates
for :doc:`fix bond/react <fix_bond_react>` is much simpler when using
type labels, and results in templates that can be used without
modification in multiple simulations or different systems.
-----------
.. _Typelabel24:
**(Gissinger)** J. R. Gissinger, I. Nikiforov, Y. Afshar, B. Waters, M. Choi, D. S. Karls, A. Stukowski, W. Im, H. Heinz, A. Kohlmeyer, and E. B. Tadmor, J Phys Chem B, 128, 3282-3297 (2024).

4
doc/src/Intro_features.rst
View File

@ -29,7 +29,7 @@ General features
* spatial decomposition of simulation domain for MPI parallelism
* particle decomposition inside spatial decomposition for OpenMP and GPU parallelism
* GPLv2 licensed open-source distribution
* highly portable C++-11
* highly portable C++-11 (optional packages may require C++17)
* modular code with most functionality in optional packages
* only depends on MPI library for basic parallel functionality, MPI stub for serial compilation
* other libraries are optional and only required for specific packages
@ -81,7 +81,7 @@ commands)
* pairwise potentials: Lennard-Jones, Buckingham, Morse, Born-Mayer-Huggins, Yukawa, soft, Class II (COMPASS), hydrogen bond, harmonic, gaussian, tabulated, scripted
* charged pairwise potentials: Coulombic, point-dipole
* many-body potentials: EAM, Finnis/Sinclair, MEAM, MEAM+SW, EIM, EDIP, ADP, Stillinger-Weber, Tersoff, REBO, AIREBO, ReaxFF, COMB, Streitz-Mintmire, 3-body polymorphic, BOP, Vashishta
* machine learning potentials: ACE, AGNI, GAP, Behler-Parrinello (N2P2), POD, RANN
* machine learning potentials: ACE, AGNI, GAP, Behler-Parrinello (N2P2), POD, RANN, SNAP
* interfaces to ML potentials distributed by external groups: ANI, ChIMES, DeepPot, HIPNN, MTP
* long-range interactions for charge, point-dipoles, and LJ dispersion: Ewald, Wolf, PPPM (similar to particle-mesh Ewald), MSM, ScaFaCoS
* polarization models: :doc:`QEq <fix_qeq>`, :doc:`core/shell model <Howto_coreshell>`, :doc:`Drude dipole model <Howto_drude>`

17
doc/src/Python_scatter.rst
View File

@ -54,8 +54,21 @@ like this:
x[3] = x coord of atom with ID 2
...
x[n3-1] = z coord of atom with ID natoms
lmp.scatter_atoms("x",1,3,x)
lmp.scatter_atoms("x", 1, 3, x)
The coordinates can also be provided as arguments to the initializer of x:
.. code-block:: python
from ctypes import c_double
natoms = 2
n3 = 3*natoms
# init in constructor
x = (n3*c_double)(0.0, 0.0, 0.0, 1.0, 1.0, 1.0)
lmp.scatter_atoms("x", 1, 3, x)
# or using a list
coords = [1.0, 2.0, 3.0, -3.0, -2.0, -1.0]
x = (c_double*len(coords))(*coords)
Alternatively, you can just change values in the vector returned by
the gather methods, since they are also ctypes vectors.

80
doc/src/angle_cosine_squared_restricted.rst Normal file
View File

@ -0,0 +1,80 @@
.. index:: angle_style cosine/squared/restricted
.. index:: angle_style cosine/squared/restricted/omp
angle_style cosine/squared/restricted command
=============================================
Accelerator Variants: *cosine/squared/restricted/omp*
Syntax
""""""
.. code-block:: LAMMPS
angle_style cosine/squared/restricted
Examples
""""""""
.. code-block:: LAMMPS
angle_style cosine/squared/restricted
angle_coeff 2*4 75.0 100.0
Description
"""""""""""
.. versionadded:: 17Apr2024
The *cosine/squared/restricted* angle style uses the potential
.. math::
E = K [\cos(\theta) - \cos(\theta_0)]^2 / \sin^2(\theta)
, which is commonly used in the MARTINI force field,
where :math:`\theta_0` is the equilibrium value of the angle, and :math:`K`
is a prefactor. Note that the usual 1/2 factor is included in :math:`K`.
See :ref:`(Bulacu) <restricted-Bulacu>` for a description of the restricted angle for the MARTINI force field.
The following coefficients must be defined for each angle type via the
:doc:`angle_coeff <angle_coeff>` command as in the example above, or in
the data file or restart files read by the :doc:`read_data <read_data>`
or :doc:`read_restart <read_restart>` commands:
* :math:`K` (energy)
* :math:`\theta_0` (degrees)
:math:`\theta_0` is specified in degrees, but LAMMPS converts it to radians
internally.
----------
.. include:: accel_styles.rst
----------
Restrictions
""""""""""""
This angle style can only be used if LAMMPS was built with the
EXTRA-MOLECULE package. See the :doc:`Build package <Build_package>` doc page
for more info.
Related commands
""""""""""""""""
:doc:`angle_coeff <angle_coeff>`
Default
"""""""
none
----------
.. _restricted-Bulacu:
**(Bulacu)** Bulacu, Goga, Zhao, Rossi, Monticelli, Periole, Tieleman, Marrink, J Chem Theory Comput, 9, 3282-3292
(2013).

3
doc/src/angle_style.rst
View File

@ -10,7 +10,7 @@ Syntax
angle_style style
* style = *none* or *zero* or *hybrid* or *amoeba* or *charmm* or *class2* or *class2/p6* or *cosine* or *cosine/buck6d* or *cosine/delta* or *cosine/periodic* or *cosine/shift* or *cosine/shift/exp* or *cosine/squared* or *cross* or *dipole* or *fourier* or *fourier/simple* or *gaussian* or *harmonic* or *lepton* or *mm3* or *quartic* or *spica* or *table*
* style = *none* or *zero* or *hybrid* or *amoeba* or *charmm* or *class2* or *class2/p6* or *cosine* or *cosine/buck6d* or *cosine/delta* or *cosine/periodic* or *cosine/shift* or *cosine/shift/exp* or *cosine/squared* or *cosine/squared/restricted* or *cross* or *dipole* or *fourier* or *fourier/simple* or *gaussian* or *harmonic* or *lepton* or *mm3* or *quartic* or *spica* or *table*
Examples
""""""""
@ -84,6 +84,7 @@ of (g,i,k,o,t) to indicate which accelerated styles exist.
* :doc:`cosine/shift <angle_cosine_shift>` - angle cosine with a shift
* :doc:`cosine/shift/exp <angle_cosine_shift_exp>` - cosine with shift and exponential term in spring constant
* :doc:`cosine/squared <angle_cosine_squared>` - angle with cosine squared term
* :doc:`cosine/squared/restricted <angle_cosine_squared_restricted>` - angle with restricted cosine squared term
* :doc:`cross <angle_cross>` - cross term coupling angle and bond lengths
* :doc:`dipole <angle_dipole>` - angle that controls orientation of a point dipole
* :doc:`fourier <angle_fourier>` - angle with multiple cosine terms

27
doc/src/atom_style.rst
View File

@ -283,21 +283,22 @@ Note that there may be additional arguments required along with the
arguments are described on the :doc:`Howto body <Howto_body>` doc page.
For the *dielectric* style, each particle can be either a physical
particle (e.g. an ion), or an interface particle representing a boundary
element between two regions of different dielectric constant. For
interface particles, in addition to the properties associated with
atom_style full, each particle also should be assigned a normal unit
vector (defined by normx, normy, normz), an area (area/patch), the
particle (e.g. an ion), or an interface particle representing a
boundary element between two regions of different dielectric
constant. For interface particles, in addition to the properties
associated with atom_style full, each particle also should be assigned
a unit dipole vector (mu) representing the direction of the induced
dipole moment at each interface particle, an area (area/patch), the
difference and mean of the dielectric constants of two sides of the
interface along the direction of the normal vector (ed and em), the
local dielectric constant at the boundary element (epsilon), and a mean
local curvature (curv). Physical particles must be assigned these
values, as well, but only their local dielectric constants will be used;
see documentation for associated :doc:`pair styles <pair_dielectric>`
and :doc:`fixes <fix_polarize>`. The distinction between the physical
and interface particles is only meaningful when :doc:`fix polarize
<fix_polarize>` commands are applied to the interface particles. This
style is part of the DIELECTRIC package.
local dielectric constant at the boundary element (epsilon), and a
mean local curvature (curv). Physical particles must be assigned
these values, as well, but only their local dielectric constants will
be used; see documentation for associated :doc:`pair styles
<pair_dielectric>` and :doc:`fixes <fix_polarize>`. The distinction
between the physical and interface particles is only meaningful when
:doc:`fix polarize <fix_polarize>` commands are applied to the
interface particles. This style is part of the DIELECTRIC package.
For the *dipole* style, a point dipole vector mu is defined for each
point particle. Note that if you wish the particles to be finite-size

54
doc/src/boundary.rst
View File

@ -42,8 +42,10 @@ commands.
The style *p* means the box is periodic, so that particles interact
across the boundary, and they can exit one end of the box and re-enter
the other end. A periodic dimension can change in size due to
constant pressure boundary conditions or box deformation (see the :doc:`fix npt <fix_nh>` and :doc:`fix deform <fix_deform>` commands). The *p*
style must be applied to both faces of a dimension.
constant pressure boundary conditions or box deformation (see the
:doc:`fix npt <fix_nh>` and :doc:`fix deform <fix_deform>` commands).
The *p* style must be applied to both faces of a dimension. For 2d
simulations the z dimension must be periodic (which is the default).
The styles *f*, *s*, and *m* mean the box is non-periodic, so that
particles do not interact across the boundary and do not move from one
@ -76,28 +78,44 @@ atoms becomes less than 50.0. This can be useful if you start a
simulation with an empty box or if you wish to leave room on one side
of the box, e.g. for atoms to evaporate from a surface.
For triclinic (non-orthogonal) simulation boxes, if the second dimension
of a tilt factor (e.g. y for xy) is periodic, then the periodicity is
enforced with the tilt factor offset. If the first dimension is
shrink-wrapped, then the shrink wrapping is applied to the tilted box
face, to encompass the atoms. E.g. for a positive xy tilt, the xlo
and xhi faces of the box are planes tilting in the +y direction as y
increases. These tilted planes are shrink-wrapped around the atoms to
determine the x extent of the box.
LAMMPS also allows use of triclinic (non-orthogonal) simulation boxes.
See the :doc:`Howto triclinic <Howto_triclinic>` page for a
geometric description of triclinic boxes, as defined by LAMMPS, and
how to transform these parameters to and from other commonly used
triclinic representations.
description of both general and restricted triclinic boxes and how to
define them. General triclinic boxes (arbitrary edge vectors **A**,
**B**, and **C**) are converted internally to restricted triclinic
boxes with tilt factors (xy,xz,yz) which skew an otherwise orthogonal
box.
The boundary <boundary> command settings explained above for the 6
faces of an orthogonal box also apply in similar manner to the 6 faces
of a restricted triclinic box (and thus to the corresponding 6 faces
of a general triclinic box), with the following context.
if the second dimension of a tilt factor (e.g. y for xy) is periodic,
then the periodicity is enforced with the tilt factor offset. This
means that for y periodicity a particle which exits the lower y
boundary is displaced in the x-direction by xy before it re-enters the
upper y boundary. And vice versa if a particle exits the upper y
boundary. Likewise the ghost atoms surrounding a particle near the
lower y boundary include images of particles near the upper y-boundary
which are displaced in the x-direction by xy. Similar rules apply for
z-periodicity and the xz and/or yz tilt factors.
If the first dimension of a tilt factor is shrink-wrapped, then the
shrink wrapping is applied to the tilted box face, to encompass the
atoms. E.g. for a positive xy tilt, the xlo and xhi faces of the box
are planes tilting in the +y direction as y increases. The position
of these tilted planes are adjusted dynamically to shrink-wrap around
the atoms to determine the xlo and xhi extents of the box.
Restrictions
""""""""""""
This command cannot be used after the simulation box is defined by a
:doc:`read_data <read_data>` or :doc:`create_box <create_box>` command or
:doc:`read_restart <read_restart>` command. See the
:doc:`change_box <change_box>` command for how to change the simulation
box boundaries after it has been defined.
:doc:`read_data <read_data>` or :doc:`create_box <create_box>` command
or :doc:`read_restart <read_restart>` command. See the
:doc:`change_box <change_box>` command for how to change the
simulation box boundaries after it has been defined.
For 2d simulations, the z dimension must be periodic.

54
doc/src/compute_mliap.rst
View File

@ -20,7 +20,7 @@ Syntax
*model* values = style
style = *linear* or *quadratic* or *mliappy*
*descriptor* values = style filename
style = *sna*
style = *sna* or *ace*
filename = name of file containing descriptor definitions
*gradgradflag* value = 0/1
toggle gradgrad method for force gradient
@ -31,6 +31,7 @@ Examples
.. code-block:: LAMMPS
compute mliap model linear descriptor sna Ta06A.mliap.descriptor
compute mliap model linear descriptor ace H_N_O_ccs.yace gradgradflag 1
Description
"""""""""""
@ -40,18 +41,15 @@ of machine-learning interatomic potentials with respect to model parameters.
It is used primarily for calculating the gradient of energy, force, and
stress components with respect to model parameters, which is useful when
training :doc:`mliap pair_style <pair_mliap>` models to match target data.
It provides separate
definitions of the interatomic potential functional form (*model*)
and the geometric quantities that characterize the atomic positions
(*descriptor*). By defining *model* and *descriptor* separately,
It provides separate definitions of the interatomic potential functional
form (*model*) and the geometric quantities that characterize the atomic
positions (*descriptor*). By defining *model* and *descriptor* separately,
it is possible to use many different models with a given descriptor,
or many different descriptors with a given model. Currently, the
compute supports just two models, *linear* and *quadratic*,
and one descriptor, *sna*, the SNAP descriptor used by
:doc:`pair_style snap <pair_snap>`, including the linear, quadratic,
and chem variants. Work is currently underway to extend
the interface to handle neural network energy models,
and it is also straightforward to add new descriptor styles.
or many different descriptors with a given model. Currently, the compute
supports *linear* and *quadratic* SNAP descriptor computes used in
:doc:`pair_style snap <pair_snap>`, *linear* SO3 descriptor computes, and
*linear* ACE descriptor computes used in :doc:`pair_style pace <pair_pace>`,
and it is straightforward to add new descriptor styles.
The compute *mliap* command must be followed by two keywords
*model* and *descriptor* in either order.
@ -60,19 +58,31 @@ The *model* keyword is followed by the model style (*linear*,
*quadratic* or *mliappy*). The *mliappy* model is only available if
LAMMPS is built with the *mliappy* Python module. There are
:ref:`specific installation instructions <mliap>` for that module.
For the *mliap* compute, specifying a *linear* model will compute the
specified descriptors and gradients with respect to linear model parameters
whereas *quadratic* will do the same, but for the quadratic products of
descriptors.
The *descriptor* keyword is followed by a descriptor style, and
additional arguments. The compute currently supports two descriptor
styles *sna* and *so3*, but it is is straightforward to add additional
descriptor styles. The SNAP descriptor style *sna* is the same as that
used by :doc:`pair_style snap <pair_snap>`, including the linear,
quadratic, and chem variants. A single additional argument specifies
the descriptor filename containing the parameters and setting used by
the SNAP descriptor. The descriptor filename usually ends in the
additional arguments. The compute currently supports three descriptor
styles: *sna*, *so3*, and *ace*, but it is is straightforward to add
additional descriptor styles. The SNAP descriptor style *sna* is the
same as that used by :doc:`pair_style snap <pair_snap>`, including the
linear, quadratic, and chem variants. A single additional argument
specifies the descriptor filename containing the parameters and setting used
by the SNAP descriptor. The descriptor filename usually ends in the
*.mliap.descriptor* extension. The format of this file is identical to
the descriptor file in the :doc:`pair_style mliap <pair_mliap>`, and is
described in detail there.
The ACE descriptor style *ace* is the same as :doc:`pair_style pace <pair_pace>`.
A single additional argument specifies the *ace* descriptor filename
that contains parameters and settings for the ACE descriptors. This file
format differs from the SNAP or SO3 descriptor files, and has a *.yace* or
*.ace* extension. However, as with other mliap descriptor styles, this file
is identical to the ace descriptor file in :doc:`pair_style mliap <pair_mliap>`,
where it is described in further detail.
.. note::
The number of LAMMPS atom types (and the value of *nelems* in the model)
@ -172,8 +182,10 @@ This compute is part of the ML-IAP package. It is only enabled if
LAMMPS was built with that package. In addition, building LAMMPS with
the ML-IAP package requires building LAMMPS with the ML-SNAP package.
The *mliappy* model also requires building LAMMPS with the PYTHON
package. See the :doc:`Build package <Build_package>` page for more
info.
package. The *ace* descriptor also requires building LAMMPS with the
ML-PACE package. See the :doc:`Build package <Build_package>` page for
more info. Note that `kk` (KOKKOS) accelerated variants of SNAP and
ACE descriptors are not compatible with `mliap descriptor`.
Related commands
""""""""""""""""

242
doc/src/create_atoms.rst
View File

@ -86,25 +86,46 @@ Description
"""""""""""
This command creates atoms (or molecules) within the simulation box,
either on a lattice, or a single atom (or molecule), or on a surface
defined by a triangulated mesh, or a random collection of atoms (or
molecules). It is an alternative to reading in atom coordinates
either on a lattice, or at random points, or on a surface defined by a
triangulated mesh. Or it creates a single atom (or molecule) at a
specified point. It is an alternative to reading in atom coordinates
explicitly via a :doc:`read_data <read_data>` or :doc:`read_restart
<read_restart>` command. A simulation box must already exist, which is
<read_restart>` command.
To use this command a simulation box must already exist, which is
typically created via the :doc:`create_box <create_box>` command.
Before using this command, a lattice must also be defined using the
:doc:`lattice <lattice>` command, unless you specify the *single* style
with units = box or the *random* style. For the remainder of this doc
page, a created atom or molecule is referred to as a "particle".
Before using this command, a lattice must typically also be defined
using the :doc:`lattice <lattice>` command, unless you specify the
*single* or *mesh* style with units = box or the *random* style. To
create atoms on a lattice for general triclinic boxes, see the
discussion below.
For the remainder of this doc page, a created atom or molecule is
referred to as a "particle".
If created particles are individual atoms, they are assigned the
specified atom *type*, though this can be altered via the *basis*
keyword as discussed below. If molecules are being created, the type
of each atom in the created molecule is specified in the file read by
the :doc:`molecule <molecule>` command, and those values are added to
the specified atom *type* (e.g., if *type* = 2 and the file specifies
atom types 1, 2, and 3, then each created molecule will have atom types
3, 4, and 5).
of each atom in the created molecule is specified in a specified file
read by the :doc:`molecule <molecule>` command, and those values are
added to the specified atom *type* (e.g., if *type* = 2 and the file
specifies atom types 1, 2, and 3, then each created molecule will have
atom types 3, 4, and 5).
.. note::
You cannot use this command to create atoms that are outside the
simulation box; they will just be ignored by LAMMPS. This is true
even if you are using shrink-wrapped box boundaries, as specified
by the :doc:`boundary <boundary>` command. However, you can first
use the :doc:`change_box <change_box>` command to temporarily
expand the box, then add atoms via create_atoms, then finally use
change_box command again if needed to re-shrink-wrap the new atoms.
See the :doc:`change_box <change_box>` doc page for an example of
how to do this, using the create_atoms *single* style to insert a
new atom outside the current simulation box.
----------
For the *box* style, the create_atoms command fills the entire
simulation box with particles on the lattice. If your simulation box
@ -126,10 +147,117 @@ periodic boundaries. If this is desired, you should either use the
*box* style, or tweak the region size to get precisely the particles
you want.
----------
If the simulation box is formulated as a general triclinic box defined
by arbitrary edge vectors **A**, **B**, **C**, then the *box* and
*region* styles will create atoms on a lattice commensurate with those
edge vectors. See the :doc:`Howto_triclinic <Howto_triclinic>` doc
page for a detailed explanation of orthogonal, restricted triclinic,
and general triclinic simulation boxes. As with the :doc:`create_box
<create_box>` command, the :doc:`lattice <lattice>` command used by
this command must be of style *custom* and use its *triclinic/general*
option. The *a1, *a2*, *a3* settings of the :doc:`lattice <lattice>`
command define the edge vectors of a unit cell of the general
triclinic lattice. The :doc:`create_box <create_box>` command creates
a simulation box which replicates that unit cell along each of the
**A**, **B**, **C** edge vectors.
.. note::
LAMMPS allows specification of general triclinic simulation boxes
as a convenience for users who may be converting data from
solid-state crystallographic representations or from DFT codes for
input to LAMMPS. However, as explained on the
:doc:`Howto_triclinic <Howto_triclinic>` doc page, internally,
LAMMPS only uses restricted triclinic simulation boxes. This means
the box created by the :doc:`create_box <create_box>` command as
well as the atoms created by this command with their per-atom
information (e.g. coordinates, velocities) are converted (rotated)
from general to restricted triclinic form when the two commands are
invoked. The <Howto_triclinic>` doc page also discusses other
LAMMPS commands which can input/output general triclinic
representations of the simulation box and per-atom data.
The *box* style will fill the entire general triclinic box with
particles on the lattice, as explained above.
.. note::
The *region* style also operates as explained above, but the check
for particles inside the region is performed *after* the particle
coordinates have been converted to the restricted triclinic box.
This means the region must also be defined with respect to the
restricted triclinic box, not the general triclinic box.
If the simulation box is general triclinic, the *single*, *random*,
and *mesh* styles described next operate on the box *after* it has
been converted to restricted triclinic. So all the settings for those
styles should be made in that context.
----------
For the *single* style, a single particle is added to the system at
the specified coordinates. This can be useful for debugging purposes
or to create a tiny system with a handful of particles at specified
positions.
positions. For a 2d simulation the specified z coordinate must be
0.0.
.. versionchanged:: 2Jun2022
The *porosity* style has been renamed to *random* with added functionality.
For the *random* style, *N* particles are added to the system at
randomly generated coordinates, which can be useful for generating an
amorphous system. For 2d simulations, the z coordinates of all added
atoms will be 0.0.
The particles are created one by one using the specified random number
*seed*, resulting in the same set of particle coordinates, independent
of how many processors are being used in the simulation. Unless the
*overlap* keyword is specified, particles created by the *random*
style will typically be highly overlapped. Various additional
criteria can be used to accept or reject a random particle insertion;
see the keyword discussion below. Multiple attempts per particle are
made (see the *maxtry* keyword) until the insertion is either
successful or fails. If this command fails to add all requested *N*
particles, a warning will be output.
If the *region-ID* argument is specified as NULL, then the randomly
created particles will be anywhere in the simulation box. If a
*region-ID* is specified, a geometric volume is filled that is both
inside the simulation box and is also consistent with the region
volume. See the :doc:`region <region>` command for details. Note
that a region can be specified so that its "volume" is either inside
or outside its geometric boundary.
Note that the create_atoms command adds particles to those that
already exist. This means it can be used to add particles to a system
previously read in from a data or restart file. Or the create_atoms
command can be used multiple times, to add multiple sets of particles
to the simulation. For example, grain boundaries can be created, by
interleaving the create_atoms command with :doc:`lattice <lattice>`
commands specifying different orientations.
When this command is used, care should be taken to ensure the
resulting system does not contain particles that are highly
overlapped. Such overlaps will cause many interatomic potentials to
compute huge energies and forces, leading to bad dynamics. There are
several strategies to avoid this problem:
* Use the :doc:`delete_atoms overlap <delete_atoms>` command after
create_atoms. For example, this strategy can be used to overlay and
surround a large protein molecule with a volume of water molecules,
then delete water molecules that overlap with the protein atoms.
* For the *random* style, use the optional *overlap* keyword to avoid
overlaps when each new particle is created.
* Before running dynamics on an overlapped system, perform an
:doc:`energy minimization <minimize>`. Or run initial dynamics with
:doc:`pair_style soft <pair_soft>` or with :doc:`fix nve/limit
<fix_nve_limit>` to un-overlap the particles, before running normal
dynamics.
.. figure:: img/marble_race.jpg
:figwidth: 33%
@ -189,73 +317,6 @@ to the area of that triangle.
beneficial to exclude computing interactions between the created
particles using :doc:`neigh_modify exclude <neigh_modify>`.
.. versionchanged:: 2Jun2022
The *porosity* style has been renamed to *random* with added functionality.
For the *random* style, *N* particles are added to the system at
randomly generated coordinates, which can be useful for generating an
amorphous system. The particles are created one by one using the
specified random number *seed*, resulting in the same set of particle
coordinates, independent of how many processors are being used in the
simulation. Unless the *overlap* keyword is specified, particles
created by the *random* style will typically be highly overlapped.
Various additional criteria can be used to accept or reject a random
particle insertion; see the keyword discussion below. Multiple
attempts per particle are made (see the *maxtry* keyword) until the
insertion is either successful or fails. If this command fails to add
all requested *N* particles, a warning will be output.
If the *region-ID* argument is specified as NULL, then the randomly
created particles will be anywhere in the simulation box. If a
*region-ID* is specified, a geometric volume is filled that is both
inside the simulation box and is also consistent with the region
volume. See the :doc:`region <region>` command for details. Note
that a region can be specified so that its "volume" is either inside
or outside its geometric boundary.
Note that the create_atoms command adds particles to those that
already exist. This means it can be used to add particles to a system
previously read in from a data or restart file. Or the create_atoms
command can be used multiple times, to add multiple sets of particles
to the simulation. For example, grain boundaries can be created, by
interleaving the create_atoms command with :doc:`lattice <lattice>`
commands specifying different orientations.
When this command is used, care should be taken to ensure the
resulting system does not contain particles that are highly
overlapped. Such overlaps will cause many interatomic potentials to
compute huge energies and forces, leading to bad dynamics. There are
several strategies to avoid this problem:
* Use the :doc:`delete_atoms overlap <delete_atoms>` command after
create_atoms. For example, this strategy can be used to overlay and
surround a large protein molecule with a volume of water molecules,
then delete water molecules that overlap with the protein atoms.
* For the *random* style, use the optional *overlap* keyword to avoid
overlaps when each new particle is created.
* Before running dynamics on an overlapped system, perform an
:doc:`energy minimization <minimize>`. Or run initial dynamics with
:doc:`pair_style soft <pair_soft>` or with :doc:`fix nve/limit
<fix_nve_limit>` to un-overlap the particles, before running normal
dynamics.
.. note::
You cannot use any of the styles explained above to create atoms
that are outside the simulation box; they will just be ignored by
LAMMPS. This is true even if you are using shrink-wrapped box
boundaries, as specified by the :doc:`boundary <boundary>` command.
However, you can first use the :doc:`change_box <change_box>`
command to temporarily expand the box, then add atoms via
create_atoms, then finally use change_box command again if needed
to re-shrink-wrap the new atoms. See the :doc:`change_box
<change_box>` doc page for an example of how to do this, using the
create_atoms *single* style to insert a new atom outside the
current simulation box.
----------
Individual atoms are inserted by this command, unless the *mol*
@ -469,12 +530,19 @@ on a single CPU core.
-----
The *units* keyword determines the meaning of the distance units used
to specify the coordinates of the one particle created by the *single*
style, or the overlap distance *Doverlap* by the *overlap* keyword. A
*box* value selects standard distance units as defined by the
:doc:`units <units>` command (e.g., :math:`\AA` for
units = *real* or *metal*\ . A *lattice* value means the distance units are in
lattice spacings.
by parameters for various styles. A *box* value selects standard
distance units as defined by the :doc:`units <units>` command (e.g.,
:math:`\AA` for units = *real* or *metal*\ . A *lattice* value means
the distance units are in lattice spacings. These are affected settings:
* for *single* style: coordinates of the particle created
* for *random* style: overlap distance *Doverlap* by the *overlap* keyword
* for *mesh* style: *bisect* threshold value for *meshmode* = *bisect*
* for *mesh* style: *radthresh* value for *meshmode* = *bisect*
* for *mesh* style: *density* value for *meshmode* = *qrand*
Since *density* represents an area (distance ^2), the lattice spacing
factor is also squared.
----------

241
doc/src/create_box.rst
View File

@ -9,9 +9,11 @@ Syntax
.. code-block:: LAMMPS
create_box N region-ID keyword value ...
create_box N NULL alo ahi blo bhi clo chi keyword value ...
* N = # of atom types to use in this simulation
* region-ID = ID of region to use as simulation domain
* region-ID = ID of region to use as simulation domain or NULL for general triclinic box
* alo,ahi,blo,bhi,clo,chi = multipliers on a1,a2,a3 vectors defined by :doc"`lattice <lattice>` command (only when region-ID = NULL)
* zero or more keyword/value pairs may be appended
* keyword = *bond/types* or *angle/types* or *dihedral/types* or *improper/types* or *extra/bond/per/atom* or *extra/angle/per/atom* or *extra/dihedral/per/atom* or *extra/improper/per/atom* or *extra/special/per/atom*
@ -32,121 +34,204 @@ Examples
.. code-block:: LAMMPS
# orthogonal or restricted triclinic box using regionID = mybox
create_box 2 mybox
create_box 2 mybox bond/types 2 extra/bond/per/atom 1
.. code-block:: LAMMPS
# 2d general triclinic box using primitive cell for 2d hex lattice
lattice custom 1.0 a1 1.0 0.0 0.0 a2 0.5 0.86602540378 0.0 &
a3 0.0 0.0 1.0 basis 0.0 0.0 0.0 triclinic/general
create_box 1 NULL 0 5 0 5 -0.5 0.5
.. code-block:: LAMMPS
# 3d general triclinic box using primitive cell for 3d fcc lattice
lattice custom 1.0 a2 0.0 0.5 0.5 a1 0.5 0.0 0.5 a3 0.5 0.5 0.0 basis 0.0 0.0 0.0 triclinic/general
create box 1 NULL -5 5 -10 10 0 20
Description
"""""""""""
This command creates a simulation box based on the specified region.
Thus a :doc:`region <region>` command must first be used to define a
geometric domain. It also partitions the simulation box into a
regular 3d grid of rectangular bricks, one per processor, based on the
number of processors being used and the settings of the
:doc:`processors <processors>` command. The partitioning can later be
changed by the :doc:`balance <balance>` or :doc:`fix balance <fix_balance>` commands.
This command creates a simulation box. It also partitions the box into
a regular 3d grid of smaller sub-boxes, one per processor (MPI task).
The geometry of the partitioning is based on the size and shape of the
simulation box, the number of processors being used and the settings
of the :doc:`processors <processors>` command. The partitioning can
later be changed by the :doc:`balance <balance>` or :doc:`fix balance
<fix_balance>` commands.
The argument N is the number of atom types that will be used in the
Simulation boxes in LAMMPS can be either orthogonal or triclinic in
shape. Orthogonal boxes are a brick in 3d (rectangle in 2d) with 6
faces that are each perpendicular to one of the standard xyz
coordinate axes. Triclinic boxes are a parallelepiped in 3d
(parallelogram in 2d) with opposite pairs of faces parallel to each
other. LAMMPS supports two forms of triclinic boxes, restricted and
general, which differ in how the box is oriented with respect to the
xyz coordinate axes. See the :doc:`Howto triclinic <Howto_triclinic>`
for a detailed description of all 3 kinds of simulation boxes.
The argument *N* is the number of atom types that will be used in the
simulation.
Orthogonal and restricted triclinic boxes are created by specifying a
region ID previously defined by the :doc:`region <region>` command.
General triclinic boxes are discussed below.
If the region is not of style *prism*, then LAMMPS encloses the region
(block, sphere, etc.) with an axis-aligned orthogonal bounding box
which becomes the simulation domain.
which becomes the simulation domain. For a 2d simulation, the zlo and
zhi values of the simulation box must straddle zero.
If the region is of style *prism*, LAMMPS creates a non-orthogonal
simulation domain shaped as a parallelepiped with triclinic symmetry.
As defined by the :doc:`region prism <region>` command, the
parallelepiped has its "origin" at (xlo,ylo,zlo) and is defined by three
edge vectors starting from the origin given by
:math:`\vec a = (x_\text{hi}-x_\text{lo},0,0)`;
:math:`\vec b = (xy,y_\text{hi}-y_\text{lo},0)`; and
:math:`\vec c = (xz,yz,z_\text{hi}-z_\text{lo})`.
The parameters *xy*\ , *xz*\ , and *yz* can be 0.0 or
positive or negative values and are called "tilt factors" because they
are the amount of displacement applied to faces of an originally
orthogonal box to transform it into the parallelepiped.
parallelepiped has an "origin" at (xlo,ylo,zlo) and three edge vectors
starting from the origin given by :math:`\vec a =
(x_\text{hi}-x_\text{lo},0,0)`; :math:`\vec b =
(xy,y_\text{hi}-y_\text{lo},0)`; and :math:`\vec c =
(xz,yz,z_\text{hi}-z_\text{lo})`. In LAMMPS lingo, this is a
restricted triclinic box because the three edge vectors cannot be
defined in arbitrary (general) directions. The parameters *xy*\ ,
*xz*\ , and *yz* can be 0.0 or positive or negative values and are
called "tilt factors" because they are the amount of displacement
applied to faces of an originally orthogonal box to transform it into
the parallelepiped. For a 2d simulation, the zlo and zhi values of
the simulation box must straddle zero.
By default, a *prism* region used with the create_box command must have
tilt factors :math:`(xy,xz,yz)` that do not skew the box more than half
the distance of the parallel box length. For example, if
:math:`x_\text{lo} = 2` and :math:`x_\text{hi} = 12`, then the :math:`x`
box length is 10 and the :math:`xy` tilt factor must be between
:math:`-5` and :math:`5`. Similarly, both :math:`xz` and :math:`yz`
must be between :math:`-(x_\text{hi}-x_\text{lo})/2` and
Typically a *prism* region used with the create_box command should
have tilt factors :math:`(xy,xz,yz)` that do not skew the box more
than half the distance of the parallel box length. For example, if
:math:`x_\text{lo} = 2` and :math:`x_\text{hi} = 12`, then the
:math:`x` box length is 10 and the :math:`xy` tilt factor must be
between :math:`-5` and :math:`5`. Similarly, both :math:`xz` and
:math:`yz` must be between :math:`-(x_\text{hi}-x_\text{lo})/2` and
:math:`+(y_\text{hi}-y_\text{lo})/2`. Note that this is not a
limitation, since if the maximum tilt factor is 5 (as in this example),
then configurations with tilt :math:`= \dots, -15`, :math:`-5`,
:math:`5`, :math:`15`, :math:`25, \dots` are all geometrically
equivalent. Simulations with large tilt factors will run inefficiently,
since they require more ghost atoms and thus more communication. With
very large tilt factors, LAMMPS will eventually produce incorrect
trajectories and stop with errors due to lost atoms or similar.
limitation, since if the maximum tilt factor is 5 (as in this
example), then configurations with tilt :math:`= \dots, -15`,
:math:`-5`, :math:`5`, :math:`15`, :math:`25, \dots` are all
geometrically equivalent.
See the :doc:`Howto triclinic <Howto_triclinic>` page for a
geometric description of triclinic boxes, as defined by LAMMPS, and
how to transform these parameters to and from other commonly used
triclinic representations.
LAMMPS will issue a warning if the tilt factors of the created box do
not meet this criterion. This is because simulations with large tilt
factors may run inefficiently, since they require more ghost atoms and
thus more communication. With very large tilt factors, LAMMPS may
eventually produce incorrect trajectories and stop with errors due to
lost atoms or similar issues.
When a prism region is used, the simulation domain should normally be periodic
in the dimension that the tilt is applied to, which is given by the second
dimension of the tilt factor (e.g., :math:`y` for :math:`xy` tilt). This is so
that pairs of atoms interacting across that boundary will have one of them
shifted by the tilt factor. Periodicity is set by the
:doc:`boundary <boundary>` command. For example, if the :math:`xy` tilt factor
is non-zero, then the :math:`y` dimension should be periodic. Similarly, the
:math:`z` dimension should be periodic if :math:`xz` or :math:`yz` is non-zero.
LAMMPS does not require this periodicity, but you may lose atoms if this is not
the case.
See the :doc:`Howto triclinic <Howto_triclinic>` page for geometric
descriptions of triclinic boxes and tilt factors, as well as how to
transform the restricted triclinic parameters to and from other
commonly used triclinic representations.
When a prism region is used, the simulation domain should normally be
periodic in the dimension that the tilt is applied to, which is given
by the second dimension of the tilt factor (e.g., :math:`y` for
:math:`xy` tilt). This is so that pairs of atoms interacting across
that boundary will have one of them shifted by the tilt factor.
Periodicity is set by the :doc:`boundary <boundary>` command. For
example, if the :math:`xy` tilt factor is non-zero, then the :math:`y`
dimension should be periodic. Similarly, the :math:`z` dimension
should be periodic if :math:`xz` or :math:`yz` is non-zero. LAMMPS
does not require this periodicity, but you may lose atoms if this is
not the case.
Note that if your simulation will tilt the box (e.g., via the
:doc:`fix deform <fix_deform>` command), the simulation box must be set up to
be triclinic, even if the tilt factors are initially 0.0. You can
also change an orthogonal box to a triclinic box or vice versa by
:doc:`fix deform <fix_deform>` command), the simulation box must be
created as triclinic, even if the tilt factors are initially 0.0. You
can also change an orthogonal box to a triclinic box or vice versa by
using the :doc:`change box <change_box>` command with its *ortho* and
*triclinic* options.
.. note::
If the system is non-periodic (in a dimension), then you should
not make the lo/hi box dimensions (as defined in your
:doc:`region <region>` command) radically smaller/larger than the extent
of the atoms you eventually plan to create (e.g., via the
:doc:`create_atoms <create_atoms>` command). For example, if your atoms
extend from 0 to 50, you should not specify the box bounds as :math:`-10000`
and :math:`10000`. This is because as described above, LAMMPS uses the
specified box size to lay out the 3d grid of processors. A huge
(mostly empty) box will be sub-optimal for performance when using
"fixed" boundary conditions (see the :doc:`boundary <boundary>`
command). When using "shrink-wrap" boundary conditions (see the
:doc:`boundary <boundary>` command), a huge (mostly empty) box may cause
a parallel simulation to lose atoms the first time that LAMMPS
shrink-wraps the box around the atoms.
If the system is non-periodic (in a dimension), then you should not
make the lo/hi box dimensions (as defined in your :doc:`region
<region>` command) radically smaller/larger than the extent of the
atoms you eventually plan to create (e.g., via the
:doc:`create_atoms <create_atoms>` command). For example, if your
atoms extend from 0 to 50, you should not specify the box bounds as
:math:`-10000` and :math:`10000`. This is because as described
above, LAMMPS uses the specified box size to lay out the 3d grid of
processors. A huge (mostly empty) box will be sub-optimal for
performance when using "fixed" boundary conditions (see the
:doc:`boundary <boundary>` command). When using "shrink-wrap"
boundary conditions (see the :doc:`boundary <boundary>` command), a
huge (mostly empty) box may cause a parallel simulation to lose
atoms the first time that LAMMPS shrink-wraps the box around the
atoms.
----------
As noted above, general triclinic boxes in LAMMPS allow the box to
have arbitrary edge vectors **A**, **B**, **C**. The only
restrictions are that the three vectors be distinct, non-zero, and not
co-planar. They must also define a right-handed system such that
(**A** x **B**) points in the direction of **C**. Note that a
left-handed system can be converted to a right-handed system by simply
swapping the order of any pair of the **A**, **B**, **C** vectors.
To create a general triclinic boxes, the region is specified as NULL
and the next 6 parameters (alo,ahi,blo,bhi,clo,chi) define the three
edge vectors **A**, **B**, **C** using additional information
previously defined by the :doc:`lattice <lattice>` command.
The lattice must be of style *custom* and use its *triclinic/general*
option. This insures the lattice satisfies the restrictions listed
above. The *a1, *a2*, *a3* settings of the :doc:`lattice <lattice>`
command define the edge vectors of a unit cell of the general
triclinic lattice. This command uses them to define the three edge
vectors and origin of the general triclinic box as:
* **A** = (ahi-alo) * *a1*
* **B** = (bhi-blo) * *a2*
* **C** = (chi-clo) * *a3*
* origin = (alo*a1 + blo*a2 + clo*a3)
For 2d general triclinic boxes, clo = -0.5 and chi = 0.5 is required.
.. note::
LAMMPS allows specification of general triclinic simulation boxes
as a convenience for users who may be converting data from
solid-state crystallographic representations or from DFT codes for
input to LAMMPS. However, as explained on the
:doc:`Howto_triclinic <Howto_triclinic>` doc page, internally,
LAMMPS only uses restricted triclinic simulation boxes. This means
the box defined by this command and per-atom information
(e.g. coordinates, velocities) defined by the :doc:`create_atoms
<create_atoms>` command are converted (rotated) from general to
restricted triclinic form when the two commands are invoked. The
<Howto_triclinic>` doc page also discusses other LAMMPS commands
which can input/output general triclinic representations of the
simulation box and per-atom data.
----------
The optional keywords can be used to create a system that allows for
bond (angle, dihedral, improper) interactions, or for molecules with
special 1--2, 1--3, or 1--4 neighbors to be added later. These optional
keywords serve the same purpose as the analogous keywords that can be
used in a data file which are recognized by the
special 1--2, 1--3, or 1--4 neighbors to be added later. These
optional keywords serve the same purpose as the analogous keywords
that can be used in a data file which are recognized by the
:doc:`read_data <read_data>` command when it sets up a system.
Note that if these keywords are not used, then the create_box command
creates an atomic (non-molecular) simulation that does not allow bonds
between pairs of atoms to be defined, or a
:doc:`bond potential <bond_style>` to be specified, or for molecules with
special neighbors to be added to the system by commands such as
:doc:`create_atoms mol <create_atoms>`, :doc:`fix deposit <fix_deposit>`
or :doc:`fix pour <fix_pour>`.
between pairs of atoms to be defined, or a :doc:`bond potential
<bond_style>` to be specified, or for molecules with special neighbors
to be added to the system by commands such as :doc:`create_atoms mol
<create_atoms>`, :doc:`fix deposit <fix_deposit>` or :doc:`fix pour
<fix_pour>`.
As an example, see the examples/deposit/in.deposit.molecule script,
which deposits molecules onto a substrate. Initially there are no
molecules in the system, but they are added later by the
:doc:`fix deposit <fix_deposit>` command. The create_box command in the
script uses the bond/types and extra/bond/per/atom keywords to allow
this. If the added molecule contained more than one special bond
(allowed by default), an extra/special/per/atom keyword would also
need to be specified.
molecules in the system, but they are added later by the :doc:`fix
deposit <fix_deposit>` command. The create_box command in the script
uses the bond/types and extra/bond/per/atom keywords to allow this.
If the added molecule contained more than one special bond (allowed by
default), an extra/special/per/atom keyword would also need to be
specified.
----------

71
doc/src/dihedral_cosine_squared_restricted.rst Normal file
View File

@ -0,0 +1,71 @@
.. index:: dihedral_style cosine/squared/restricted
dihedral_style cosine/squared/restricted command
================================================
Syntax
""""""
.. code-block:: LAMMPS
dihedral_style cosine/squared/restricted
Examples
""""""""
.. code-block:: LAMMPS
dihedral_style cosine/squared/restricted
dihedral_coeff 1 10.0 120
Description
"""""""""""
.. versionadded:: 17Apr2024
The *cosine/squared/restricted* dihedral style uses the potential
.. math::
E = K [\cos(\phi) - \cos(\phi_0)]^2 / \sin^2(\phi)
, which is commonly used in the MARTINI force field.
See :ref:`(Bulacu) <restricted-Bul>` for a description of the restricted dihedral for the MARTINI force field.
The following coefficients must be defined for each dihedral type via the
:doc:`dihedral_coeff <dihedral_coeff>` command as in the example above, or in
the data file or restart files read by the :doc:`read_data <read_data>`
or :doc:`read_restart <read_restart>` commands:
* :math:`K` (energy)
* :math:`\phi_0` (degrees)
:math:`\phi_0` is specified in degrees, but LAMMPS converts it to radians internally.
----------
Restrictions
""""""""""""
This dihedral style can only be used if LAMMPS was built with the
EXTRA-MOLECULE package. See the :doc:`Build package <Build_package>` doc page
for more info.
Related commands
""""""""""""""""
:doc:`dihedral_coeff <dihedral_coeff>`
Default
"""""""
none
----------
.. _restricted-Bul:
**(Bulacu)** Bulacu, Goga, Zhao, Rossi, Monticelli, Periole, Tieleman, Marrink, J Chem Theory Comput, 9, 3282-3292
(2013).

3
doc/src/dihedral_style.rst
View File

@ -10,7 +10,7 @@ Syntax
dihedral_style style
* style = *none* or *zero* or *hybrid* or *charmm* or *charmmfsw* or *class2* or *cosine/shift/exp* or *fourier* or *harmonic* or *helix* or *lepton* or *multi/harmonic* or *nharmonic* or *opls* or *spherical* or *table* or *table/cut*
* style = *none* or *zero* or *hybrid* or *charmm* or *charmmfsw* or *class2* or *cosine/shift/exp* or *cosine/squared/restricted* or *fourier* or *harmonic* or *helix* or *lepton* or *multi/harmonic* or *nharmonic* or *opls* or *spherical* or *table* or *table/cut*
Examples
""""""""
@ -105,6 +105,7 @@ exist.
* :doc:`charmmfsw <dihedral_charmm>` - CHARMM dihedral with force switching
* :doc:`class2 <dihedral_class2>` - COMPASS (class 2) dihedral
* :doc:`cosine/shift/exp <dihedral_cosine_shift_exp>` - dihedral with exponential in spring constant
* :doc:`cosine/squared/restricted <dihedral_cosine_squared_restricted>` - squared cosine dihedral with restricted term
* :doc:`fourier <dihedral_fourier>` - dihedral with multiple cosine terms
* :doc:`harmonic <dihedral_harmonic>` - harmonic dihedral
* :doc:`helix <dihedral_helix>` - helix dihedral

108
doc/src/dump.rst
View File

@ -275,16 +275,20 @@ format <dump_modify>` command and its options.
Format of native LAMMPS format dump files:
The *atom*, *custom*, *grid*, and *local* styles create files in a
simple LAMMPS-specific text format that is self-explanatory when
viewing a dump file. Many post-processing tools either included with
LAMMPS or third-party tools can read this format, as does the
simple LAMMPS-specific text format that is mostly self-explanatory
when viewing a dump file. Many post-processing tools either included
with LAMMPS or third-party tools can read this format, as does the
:doc:`rerun <rerun>` command. See tools described on the :doc:`Tools
<Tools>` doc page for examples, including `Pizza.py
<https://lammps.github.io/pizza>`_.
For all these styles, the dimensions of the simulation box are
included in each snapshot. For an orthogonal simulation box this
information is formatted as:
included in each snapshot. The simulation box in LAMMPS can be
defined in one of 3 ways: orthogonal, restricted triclinic, and
general triclinic. See the :doc:`Howto triclinic <Howto_triclinic>`
doc page for a detailed description of all 3 options.
For an orthogonal simulation box the box information is formatted as:
.. parsed-literal::
@ -301,10 +305,10 @@ the six characters is one of *p* (periodic), *f* (fixed), *s* (shrink wrap),
or *m* (shrink wrapped with a minimum value). See the
:doc:`boundary <boundary>` command for details.
For triclinic simulation boxes (non-orthogonal), an orthogonal
bounding box which encloses the triclinic simulation box is output,
along with the three tilt factors (*xy*, *xz*, *yz*) of the triclinic box,
formatted as follows:
For a restricted triclinic simulation box, an orthogonal bounding box
which encloses the restricted triclinic simulation box is output,
along with the three tilt factors (*xy*, *xz*, *yz*) of the triclinic
box, formatted as follows:
.. parsed-literal::
@ -326,6 +330,10 @@ bounding box extents (xlo_bound, xhi_bound, etc.) are calculated from the
triclinic parameters, and how to transform those parameters to and
from other commonly used triclinic representations.
For a general triclinic simulation box, see the "General triclinic"
section below for a description of the ITEM: BOX BOUNDS format as well
as how per-atom coordinates and per-atom vector quantities are output.
The *atom* and *custom* styles output a "ITEM: NUMBER OF ATOMS" line
with the count of atoms in the snapshot. Likewise they output an
"ITEM: ATOMS" line which includes column descriptors for the per-atom
@ -397,7 +405,6 @@ command.
Dump files in other popular formats:
.. note::
This section only discusses file formats relevant to this doc page.
@ -653,6 +660,87 @@ how to control the compression level in both variants.
----------
General triclinic simulation box output for the *atom* and *custom* styles:
As mentioned above, the simulation box can be defined as a general
triclinic box, which means that 3 arbitrary box edge vectors **A**,
**B**, **C** can be specified. See the :doc:`Howto triclinic
<Howto_triclinic>` doc page for a detailed description of general
triclinic boxes.
This option is provided as a convenience for users who may be
converting data from solid-state crystallographic representations or
from DFT codes for input to LAMMPS. However, as explained on the
:doc:`Howto_triclinic <Howto_triclinic>` doc page, internally, LAMMPS
only uses restricted triclinic simulation boxes. This means the box
and per-atom information (e.g. coordinates, velocities) LAMMPS stores
are converted (rotated) from general to restricted triclinic form when
the system is created.
For dump output, if the :doc:`dump_modify triclinic/general
<dump_modify>` command is used, the box description and per-atom
coordinates and other per-atom vectors will be converted (rotated)
from restricted to general form when each dump file snapshots is
output. This option can only be used if the simulation box was
initially created as general triclinic. If the option is not used,
and the simulation box is general triclinic, then the dump file
snapshots will reflect the internal restricted triclinic geometry.
The dump_modify triclinic/general option affects 3 aspects of the dump
file output.
First, the format for the BOX BOUNDS is as follows
.. parsed-literal::
ITEM: BOX BOUNDS abc origin
ax ay az originx
bx by bz originy
cx cy cz originz
where the **A** edge vector of the box is (ax,ay,az) and similarly
for **B** and **C**. The origin of all 3 edge vectors is (originx,
originy, originz).
Second, the coordinates of each atom are converted (rotated) so that
the atom is inside (or near) the general triclinic box defined by the
**A**, **B**, **C** edge vectors. For style *atom*, this only alters
output for unscaled atom coords, via the :doc:`dump_modify scaled no
<dump_modify>` setting. For style *custom*, this alters output for
either unscaled or unwrapped output of atom coords, via the *x,y,z* or
*xu,yu,zu* attributes. For output of scaled atom coords by both
styles, there is no difference between restricted and general
triclinic values.
Third, the output for any attribute of the *custom* style which
represents a per-atom vector quantity will be converted (rotated) to
be oriented consistent with the general triclinic box and its
orientation relative to the standard xyz coordinate axes.
This applies to the following *custom* style attributes:
* vx,vy,vz = atom velocities
* fx,fy,fz = forces on atoms
* mux,muy,muz = orientation of dipole moment of atom
* omegax,omegay,omegaz = angular velocity of spherical particle
* angmomx,angmomy,angmomz = angular momentum of aspherical particle
* tqx,tqy,tqz = torque on finite-size particles
For example, if the velocity of an atom in a restricted triclinic box
is along the x-axis, then it will be output for a general triclinic
box as a vector along the **A** edge vector of the box.
.. note::
For style *custom*, the :doc:`dump_modify thresh <dump_modify>`
command may access per-atom attributes either directly or
indirectly through a compute or variable. If the attribute is an
atom coordinate or one of the vectors mentioned above, its value
will *NOT* be a general triclinic (rotated) value. Rather it will
be a restricted triclinic value.
----------
Arguments for different styles:
The sections below describe per-atom, local, and per grid cell

47
doc/src/dump_modify.rst
View File

@ -17,7 +17,7 @@ Syntax
* one or more keyword/value pairs may be appended
* these keywords apply to various dump styles
* keyword = *append* or *at* or *balance* or *buffer* or *colname* or *delay* or *element* or *every* or *every/time* or *fileper* or *first* or *flush* or *format* or *header* or *image* or *label* or *maxfiles* or *nfile* or *pad* or *pbc* or *precision* or *region* or *refresh* or *scale* or *sfactor* or *skip* or *sort* or *tfactor* or *thermo* or *thresh* or *time* or *units* or *unwrap*
* keyword = *append* or *at* or *balance* or *buffer* or *colname* or *delay* or *element* or *every* or *every/time* or *fileper* or *first* or *flush* or *format* or *header* or *image* or *label* or *maxfiles* or *nfile* or *pad* or *pbc* or *precision* or *region* or *refresh* or *scale* or *sfactor* or *skip* or *sort* or *tfactor* or *thermo* or *thresh* or *time* or *triclinic/general* or *units* or *unwrap*
.. parsed-literal::
@ -74,12 +74,13 @@ Syntax
-N = sort per-atom lines in descending order by the Nth column
*tfactor* arg = time scaling factor (> 0.0)
*thermo* arg = *yes* or *no*
*time* arg = *yes* or *no*
*thresh* args = attribute operator value
attribute = same attributes (x,fy,etotal,sxx,etc) used by dump custom style
operator = "<" or "<=" or ">" or ">=" or "==" or "!=" or "\|\^"
value = numeric value to compare to, or LAST
these 3 args can be replaced by the word "none" to turn off thresholding
*time* arg = *yes* or *no*
*triclinic/general* arg = *yes* or *no*
*units* arg = *yes* or *no*
*unwrap* arg = *yes* or *no*
@ -802,8 +803,9 @@ region since the last dump.
dump_modify ... thresh v_charge |^ LAST
This will dump atoms whose charge has changed from an absolute value
less than :math:`\frac12` to greater than :math:`\frac12` (or vice versa) since the last dump (e.g., due to reactions and subsequent charge equilibration in a
reactive force field).
less than :math:`\frac12` to greater than :math:`\frac12` (or vice
versa) since the last dump (e.g., due to reactions and subsequent
charge equilibration in a reactive force field).
The choice of operators listed above are the usual comparison
operators. The XOR operation (exclusive or) is also included as "\|\^".
@ -811,6 +813,18 @@ In this context, XOR means that if either the attribute or value is
0.0 and the other is non-zero, then the result is "true" and the
threshold criterion is met. Otherwise it is not met.
.. note::
For style *custom*, the *triclinic/general* keyword can alter dump
output for general triclinic simulation boxes and their atoms. See
the :doc:`dump <dump>` command for details of how this changes the
format of dump file snapshots. The thresh keyword may access
per-atom attributes either directly or indirectly through a compute
or variable. If the attribute is an atom coordinate or a per-atom
vector (such as velocity, force, or dipole moment), its value will
*NOT* be a general triclinic (rotated) value. Rather it will be a
restricted triclinic value.
----------
The *time* keyword only applies to the dump *atom*, *custom*, *local*,
@ -835,6 +849,29 @@ The default setting is *no*\ .
----------
The *triclinic/general* keyword only applies to the dump *atom* and
*custom* styles. It can only be used with a value of *yes* if the
simulation box was created as a general triclinic box. See the
:doc:`Howto_triclinic <Howto_triclinic>` doc page for a detailed
explanation of orthogonal, restricted triclinic, and general triclinic
simulation boxes.
If this keyword is used with a value of *yes*, the box information at
the beginning of each snapshot will include information about the 3
arbitrary edge vectors **A**, **B**, **C** that define the general
triclinic box as well as their origin. The format is described on the
:doc:`dump <dump>` doc page.
The coordinates of each atom will likewise be output as values in (or
near) the general triclinic box. Likewise, per-atom vector quantities
such as velocity, omega, dipole moment, etc will have orientations
consistent with the general triclinic box, meaning they will be
rotated relative to the standard xyz coordinate axes. See the
:doc:`dump <dump>` doc page for a full list of which dump attributes
this affects.
----------
The *units* keyword only applies to the dump *atom*, *custom*, and
*local* styles (and their COMPRESS package versions *atom/gz*,
*custom/gz* and *local/gz*\ ). If set to *yes*, each individual dump
@ -922,6 +959,8 @@ The option defaults are
* sort = off for dump styles *atom*, *custom*, *cfg*, and *local*
* sort = id for dump styles *dcd*, *xtc*, and *xyz*
* thresh = none
* time = no
* triclinic/general no
* units = no
* unwrap = no

2
doc/src/fix_ave_chunk.rst
View File

@ -435,7 +435,7 @@ molecule.
----------
.. versionadded:: TBD
.. versionadded:: 17Apr2024
new keyword *append*
The *file* or *append* keywords allow a filename to be specified. If

2
doc/src/fix_ave_histo.rst
View File

@ -319,7 +319,7 @@ on. The default is step 0. Often input values can be 0.0 at time 0,
so setting *start* to a larger value can avoid including a 0.0 in
a running or windowed histogram.
.. versionadded:: TBD
.. versionadded:: 17Apr2024
new keyword *append*
The *file* or *append* keywords allow a filename to be specified. If

2
doc/src/fix_ave_time.rst
View File

@ -272,7 +272,7 @@ are effectively constant or are simply current values (e.g., they are
being written to a file with other time-averaged values for purposes
of creating well-formatted output).
.. versionadded:: TBD
.. versionadded:: 17Apr2024
new keyword *append*
The *file* or *append* keywords allow a filename to be specified. If

2
doc/src/fix_balance.rst
View File

@ -70,7 +70,7 @@ re-balancing is performed periodically during the simulation. To
perform "static" balancing, before or between runs, see the
:doc:`balance <balance>` command.
.. versionadded:: TBD
.. versionadded:: 17Apr2024
The *report* balance style only computes the load imbalance but
does not attempt any re-balancing. This way the load imbalance

2
doc/src/fix_deform_pressure.rst
View File

@ -69,7 +69,7 @@ Examples
Description
"""""""""""
.. versionadded:: TBD
.. versionadded:: 17Apr2024
This fix is an extension of the :doc:`fix deform <fix_deform>`
command, which allows all of its options to be used as well as new

4
doc/src/fix_electrode.rst
View File

@ -253,7 +253,7 @@ be enabled if any electrode particle has the same type as any
electrolyte particle (which would be unusual in a typical simulation)
and the fix will issue an error in that case.
.. versionadded:: TBD
.. versionadded:: 17Apr2024
The keyword *qtotal* causes *fix electrode/conp* and *fix
electrode/thermo* to add an overall potential to all electrodes so that
@ -267,7 +267,7 @@ and since *symm on* constrains the total charge of all electrodes to be
zero, either option is incompatible with the *qtotal* keyword (even if
*qtotal* is set to zero).
.. versionadded:: TBD
.. versionadded:: 17Apr2024
The keyword *eta* takes the name of a custom double vector defined via
fix property/atom. The values will be used instead of the standard eta

281
doc/src/fix_rigid.rst
View File

@ -171,14 +171,15 @@ Examples of large rigid bodies are a colloidal particle, or portions
of a biomolecule such as a protein.
Example of small rigid bodies are patchy nanoparticles, such as those
modeled in :ref:`this paper <Zhang1>` by Sharon Glotzer's group, clumps of
granular particles, lipid molecules consisting of one or more point
dipoles connected to other spheroids or ellipsoids, irregular
particles built from line segments (2d) or triangles (3d), and
coarse-grain models of nano or colloidal particles consisting of a
small number of constituent particles. Note that the :doc:`fix shake <fix_shake>` command can also be used to rigidify small
molecules of 2, 3, or 4 atoms, e.g. water molecules. That fix treats
the constituent atoms as point masses.
modeled in :ref:`this paper <Zhang1>` by Sharon Glotzer's group,
clumps of granular particles, lipid molecules consisting of one or
more point dipoles connected to other spheroids or ellipsoids,
irregular particles built from line segments (2d) or triangles (3d),
and coarse-grain models of nano or colloidal particles consisting of a
small number of constituent particles. Note that the :doc:`fix shake
<fix_shake>` command can also be used to rigidify small molecules of
2, 3, or 4 atoms, e.g. water molecules. That fix treats the
constituent atoms as point masses.
These fixes also update the positions and velocities of the atoms in
each rigid body via time integration, in the NVE, NVT, NPT, or NPH
@ -212,13 +213,14 @@ processors when ghost atom info is accumulated.
.. note::
To use the *rigid/small* styles the ghost atom cutoff must be
large enough to span the distance between the atom that owns the body
and every other atom in the body. This distance value is printed out
when the rigid bodies are defined. If the
:doc:`pair_style <pair_style>` cutoff plus neighbor skin does not span
this distance, then you should use the :doc:`comm_modify cutoff <comm_modify>` command with a setting epsilon larger than
the distance.
To use the *rigid/small* styles the ghost atom cutoff must be large
enough to span the distance between the atom that owns the body and
every other atom in the body. This distance value is printed out
when the rigid bodies are defined. If the :doc:`pair_style
<pair_style>` cutoff plus neighbor skin does not span this
distance, then you should use the :doc:`comm_modify cutoff
<comm_modify>` command with a setting epsilon larger than the
distance.
Which of the two variants is faster for a particular problem is hard
to predict. The best way to decide is to perform a short test run.
@ -229,49 +231,54 @@ differences may accumulate to produce divergent trajectories.
.. note::
You should not update the atoms in rigid bodies via other
time-integration fixes (e.g. :doc:`fix nve <fix_nve>`, :doc:`fix nvt <fix_nh>`, :doc:`fix npt <fix_nh>`, :doc:`fix move <fix_move>`),
or you will have conflicting updates to positions and velocities
resulting in unphysical behavior in most cases. When performing a hybrid
simulation with some atoms in rigid bodies, and some not, a separate
time integration fix like :doc:`fix nve <fix_nve>` or :doc:`fix nvt <fix_nh>` should be used for the non-rigid particles.
time-integration fixes (e.g. :doc:`fix nve <fix_nve>`, :doc:`fix
nvt <fix_nh>`, :doc:`fix npt <fix_nh>`, :doc:`fix move
<fix_move>`), or you will have conflicting updates to positions and
velocities resulting in unphysical behavior in most cases. When
performing a hybrid simulation with some atoms in rigid bodies, and
some not, a separate time integration fix like :doc:`fix nve
<fix_nve>` or :doc:`fix nvt <fix_nh>` should be used for the
non-rigid particles.
.. note::
These fixes are overkill if you simply want to hold a collection
of atoms stationary or have them move with a constant velocity. A
simpler way to hold atoms stationary is to not include those atoms in
your time integration fix. E.g. use "fix 1 mobile nve" instead of
"fix 1 all nve", where "mobile" is the group of atoms that you want to
move. You can move atoms with a constant velocity by assigning them
an initial velocity (via the :doc:`velocity <velocity>` command),
setting the force on them to 0.0 (via the :doc:`fix setforce <fix_setforce>` command), and integrating them as usual
(e.g. via the :doc:`fix nve <fix_nve>` command).
These fixes are overkill if you simply want to hold a collection of
atoms stationary or have them move with a constant velocity. A
simpler way to hold atoms stationary is to not include those atoms
in your time integration fix. E.g. use "fix 1 mobile nve" instead
of "fix 1 all nve", where "mobile" is the group of atoms that you
want to move. You can move atoms with a constant velocity by
assigning them an initial velocity (via the :doc:`velocity
<velocity>` command), setting the force on them to 0.0 (via the
:doc:`fix setforce <fix_setforce>` command), and integrating them
as usual (e.g. via the :doc:`fix nve <fix_nve>` command).
.. warning::
The aggregate properties of each rigid body are
calculated at the start of a simulation run and are maintained in
internal data structures. The properties include the position and
velocity of the center-of-mass of the body, its moments of inertia, and
its angular momentum. This is done using the properties of the
constituent atoms of the body at that point in time (or see the *infile*
keyword option). Thereafter, changing these properties of individual
atoms in the body will have no effect on a rigid body's dynamics, unless
they effect any computation of per-atom forces or torques. If the
keyword *reinit* is set to *yes* (the default), the rigid body data
structures will be recreated at the beginning of each *run* command;
if the keyword *reinit* is set to *no*, the rigid body data structures
will be built only at the very first *run* command and maintained for
as long as the rigid fix is defined. For example, you might think you
could displace the atoms in a body or add a large velocity to each atom
in a body to make it move in a desired direction before a second run is
performed, using the :doc:`set <set>` or
:doc:`displace_atoms <displace_atoms>` or :doc:`velocity <velocity>`
commands. But these commands will not affect the internal attributes
of the body unless *reinit* is set to *yes*\ . With *reinit* set to *no*
(or using the *infile* option, which implies *reinit* *no*\ ) the position
and velocity of individual atoms in the body will be reset when time
integration starts again.
The aggregate properties of each rigid body are calculated at the
start of a simulation run and are maintained in internal data
structures. The properties include the position and velocity of the
center-of-mass of the body, its moments of inertia, and its angular
momentum. This is done using the properties of the constituent
atoms of the body at that point in time (or see the *infile*
keyword option). Thereafter, changing these properties of
individual atoms in the body will have no effect on a rigid body's
dynamics, unless they effect any computation of per-atom forces or
torques. If the keyword *reinit* is set to *yes* (the default), the
rigid body data structures will be recreated at the beginning of
each *run* command; if the keyword *reinit* is set to *no*, the
rigid body data structures will be built only at the very first
*run* command and maintained for as long as the rigid fix is
defined. For example, you might think you could displace the atoms
in a body or add a large velocity to each atom in a body to make it
move in a desired direction before a second run is performed, using
the :doc:`set <set>` or :doc:`displace_atoms <displace_atoms>` or
:doc:`velocity <velocity>` commands. But these commands will not
affect the internal attributes of the body unless *reinit* is set
to *yes*\ . With *reinit* set to *no* (or using the *infile*
option, which implies *reinit* *no*\ ) the position and velocity of
individual atoms in the body will be reset when time integration
starts again.
----------
@ -316,17 +323,17 @@ to be part of rigid bodies.
.. note::
To compute the initial center-of-mass position and other
properties of each rigid body, the image flags for each atom in the
body are used to "unwrap" the atom coordinates. Thus you must ensure
that these image flags are consistent so that the unwrapping creates a
To compute the initial center-of-mass position and other properties
of each rigid body, the image flags for each atom in the body are
used to "unwrap" the atom coordinates. Thus you must ensure that
these image flags are consistent so that the unwrapping creates a
valid rigid body (one where the atoms are close together),
particularly if the atoms in a single rigid body straddle a periodic
boundary. This means the input data file or restart file must define
the image flags for each atom consistently or that you have used the
:doc:`set <set>` command to specify them correctly. If a dimension is
non-periodic then the image flag of each atom must be 0 in that
dimension, else an error is generated.
particularly if the atoms in a single rigid body straddle a
periodic boundary. This means the input data file or restart file
must define the image flags for each atom consistently or that you
have used the :doc:`set <set>` command to specify them correctly.
If a dimension is non-periodic then the image flag of each atom
must be 0 in that dimension, else an error is generated.
The *force* and *torque* keywords discussed next are only allowed for
the *rigid* styles.
@ -362,12 +369,13 @@ settings from the final keyword are used.
.. note::
For computational efficiency, you may wish to turn off pairwise
and bond interactions within each rigid body, as they no longer
contribute to the motion. The :doc:`neigh_modify exclude <neigh_modify>` and :doc:`delete_bonds <delete_bonds>`
commands are used to do this. If the rigid bodies have strongly
overlapping atoms, you may need to turn off these interactions to
avoid numerical problems due to large equal/opposite intra-body forces
For computational efficiency, you may wish to turn off pairwise and
bond interactions within each rigid body, as they no longer
contribute to the motion. The :doc:`neigh_modify exclude
<neigh_modify>` and :doc:`delete_bonds <delete_bonds>` commands are
used to do this. If the rigid bodies have strongly overlapping
atoms, you may need to turn off these interactions to avoid
numerical problems due to large equal/opposite intra-body forces
swamping the contribution of small inter-body forces.
For computational efficiency, you should typically define one fix
@ -379,7 +387,8 @@ is more expensive.
The constituent particles within a rigid body can be point particles
(the default in LAMMPS) or finite-size particles, such as spheres or
ellipsoids or line segments or triangles. See the :doc:`atom_style sphere and ellipsoid and line and tri <atom_style>` commands for more
ellipsoids or line segments or triangles. See the :doc:`atom_style
sphere and ellipsoid and line and tri <atom_style>` commands for more
details on these kinds of particles. Finite-size particles contribute
differently to the moment of inertia of a rigid body than do point
particles. Finite-size particles can also experience torque (e.g. due
@ -389,7 +398,8 @@ orientation. These contributions are accounted for by these fixes.
Forces between particles within a body do not contribute to the
external force or torque on the body. Thus for computational
efficiency, you may wish to turn off pairwise and bond interactions
between particles within each rigid body. The :doc:`neigh_modify exclude <neigh_modify>` and :doc:`delete_bonds <delete_bonds>`
between particles within each rigid body. The :doc:`neigh_modify
exclude <neigh_modify>` and :doc:`delete_bonds <delete_bonds>`
commands are used to do this. For finite-size particles this also
means the particles can be highly overlapped when creating the rigid
body.
@ -401,16 +411,17 @@ perform constant NVE time integration. They are referred to below as
the 4 NVE rigid styles. The only difference is that the *rigid* and
*rigid/small* styles use an integration technique based on Richardson
iterations. The *rigid/nve* and *rigid/small/nve* styles uses the
methods described in the paper by :ref:`Miller <Miller3>`, which are thought
to provide better energy conservation than an iterative approach.
methods described in the paper by :ref:`Miller <Miller3>`, which are
thought to provide better energy conservation than an iterative
approach.
The *rigid/nvt* and *rigid/nvt/small* styles performs constant NVT
integration using a Nose/Hoover thermostat with chains as described
originally in :ref:`(Hoover) <Hoover>` and :ref:`(Martyna) <Martyna2>`, which
thermostats both the translational and rotational degrees of freedom
of the rigid bodies. They are referred to below as the 2 NVT rigid
styles. The rigid-body algorithm used by *rigid/nvt* is described in
the paper by :ref:`Kamberaj <Kamberaj>`.
originally in :ref:`(Hoover) <Hoover>` and :ref:`(Martyna)
<Martyna2>`, which thermostats both the translational and rotational
degrees of freedom of the rigid bodies. They are referred to below as
the 2 NVT rigid styles. The rigid-body algorithm used by *rigid/nvt*
is described in the paper by :ref:`Kamberaj <Kamberaj>`.
The *rigid/npt*, *rigid/nph*, *rigid/npt/small*, and *rigid/nph/small*
styles perform constant NPT or NPH integration using a Nose/Hoover
@ -436,12 +447,12 @@ The target pressures for each of the 6 components of the stress tensor
can be specified independently via the *x*, *y*, *z* keywords, which
correspond to the 3 simulation box dimensions. For each component,
the external pressure or tensor component at each timestep is a ramped
value during the run from *Pstart* to *Pstop*\ . If a target pressure is
specified for a component, then the corresponding box dimension will
change during a simulation. For example, if the *y* keyword is used,
the y-box length will change. A box dimension will not change if that
component is not specified, although you have the option to change
that dimension via the :doc:`fix deform <fix_deform>` command.
value during the run from *Pstart* to *Pstop*\ . If a target pressure
is specified for a component, then the corresponding box dimension
will change during a simulation. For example, if the *y* keyword is
used, the y-box length will change. A box dimension will not change
if that component is not specified, although you have the option to
change that dimension via the :doc:`fix deform <fix_deform>` command.
For all barostat keywords, the *Pdamp* parameter operates like the
*Tdamp* parameter, determining the time scale on which pressure is
@ -525,11 +536,11 @@ discussed below.
The *langevin* keyword applies a Langevin thermostat to the constant
NVE time integration performed by any of the 4 NVE rigid styles:
*rigid*, *rigid/nve*, *rigid/small*, *rigid/small/nve*\ . It cannot be
used with the 2 NVT rigid styles: *rigid/nvt*, *rigid/small/nvt*\ . The
desired temperature at each timestep is a ramped value during the run
from *Tstart* to *Tstop*\ . The *Tdamp* parameter is specified in time
units and determines how rapidly the temperature is relaxed. For
*rigid*, *rigid/nve*, *rigid/small*, *rigid/small/nve*\ . It cannot
be used with the 2 NVT rigid styles: *rigid/nvt*, *rigid/small/nvt*\ .
The desired temperature at each timestep is a ramped value during the
run from *Tstart* to *Tstop*\ . The *Tdamp* parameter is specified in
time units and determines how rapidly the temperature is relaxed. For
example, a value of 100.0 means to relax the temperature in a timespan
of (roughly) 100 time units (:math:`\tau` or fs or ps - see the
:doc:`units <units>` command). The random # *seed* must be a positive
@ -564,29 +575,30 @@ used. *Tchain* is the number of thermostats in the Nose Hoover chain.
This value, along with *Tdamp* can be varied to dampen undesirable
oscillations in temperature that can occur in a simulation. As a rule
of thumb, increasing the chain length should lead to smaller
oscillations. The keyword *pchain* specifies the number of
thermostats in the chain thermostatting the barostat degrees of
freedom.
oscillations. The keyword *pchain* specifies the number of thermostats
in the chain thermostatting the barostat degrees of freedom.
.. note::
There are alternate ways to thermostat a system of rigid bodies.
You can use :doc:`fix langevin <fix_langevin>` to treat the individual
particles in the rigid bodies as effectively immersed in an implicit
solvent, e.g. a Brownian dynamics model. For hybrid systems with both
rigid bodies and solvent particles, you can thermostat only the
solvent particles that surround one or more rigid bodies by
appropriate choice of groups in the compute and fix commands for
temperature and thermostatting. The solvent interactions with the
rigid bodies should then effectively thermostat the rigid body
temperature as well without use of the Langevin or Nose/Hoover options
associated with the fix rigid commands.
You can use :doc:`fix langevin <fix_langevin>` to treat the
individual particles in the rigid bodies as effectively immersed in
an implicit solvent, e.g. a Brownian dynamics model. For hybrid
systems with both rigid bodies and solvent particles, you can
thermostat only the solvent particles that surround one or more
rigid bodies by appropriate choice of groups in the compute and fix
commands for temperature and thermostatting. The solvent
interactions with the rigid bodies should then effectively
thermostat the rigid body temperature as well without use of the
Langevin or Nose/Hoover options associated with the fix rigid
commands.
----------
The *mol* keyword can only be used with the *rigid/small* styles. It
must be used when other commands, such as :doc:`fix deposit <fix_deposit>` or :doc:`fix pour <fix_pour>`, add rigid
bodies on-the-fly during a simulation. You specify a *template-ID*
must be used when other commands, such as :doc:`fix deposit
<fix_deposit>` or :doc:`fix pour <fix_pour>`, add rigid bodies
on-the-fly during a simulation. You specify a *template-ID*
previously defined using the :doc:`molecule <molecule>` command, which
reads a file that defines the molecule. You must use the same
*template-ID* that the other fix which is adding rigid bodies uses.
@ -670,16 +682,16 @@ cross periodic boundaries during the simulation.
.. note::
If you use the *infile* or *mol* keywords and write restart
files during a simulation, then each time a restart file is written,
the fix also write an auxiliary restart file with the name
rfile.rigid, where "rfile" is the name of the restart file,
If you use the *infile* or *mol* keywords and write restart files
during a simulation, then each time a restart file is written, the
fix also write an auxiliary restart file with the name rfile.rigid,
where "rfile" is the name of the restart file,
e.g. tmp.restart.10000 and tmp.restart.10000.rigid. This auxiliary
file is in the same format described above. Thus it can be used in a
new input script that restarts the run and re-specifies a rigid fix
using an *infile* keyword and the appropriate filename. Note that the
auxiliary file will contain one line for every rigid body, even if the
original file only listed a subset of the rigid bodies.
file is in the same format described above. Thus it can be used in
a new input script that restarts the run and re-specifies a rigid
fix using an *infile* keyword and the appropriate filename. Note
that the auxiliary file will contain one line for every rigid body,
even if the original file only listed a subset of the rigid bodies.
If the system has rigid bodies with finite-size overlapping particles
and the model uses the :doc:`fix gravity <fix_gravity>` command to
@ -728,10 +740,11 @@ also accounted for by this fix.
----------
If your simulation is a hybrid model with a mixture of rigid bodies and
non-rigid particles (e.g. solvent) there are several ways these rigid
fixes can be used in tandem with :doc:`fix nve <fix_nve>`, :doc:`fix nvt
<fix_nh>`, :doc:`fix npt <fix_nh>`, and :doc:`fix nph <fix_nh>`.
If your simulation is a hybrid model with a mixture of rigid bodies
and non-rigid particles (e.g. solvent) there are several ways these
rigid fixes can be used in tandem with :doc:`fix nve <fix_nve>`,
:doc:`fix nvt <fix_nh>`, :doc:`fix npt <fix_nh>`, and :doc:`fix nph
<fix_nh>`.
If you wish to perform NVE dynamics (no thermostatting or
barostatting), use one of 4 NVE rigid styles to integrate the rigid
@ -741,14 +754,14 @@ particles.
If you wish to perform NVT dynamics (thermostatting, but no
barostatting), you can use one of the 2 NVT rigid styles for the rigid
bodies, and any thermostatting fix for the non-rigid particles
(:doc:`fix nvt <fix_nh>`, :doc:`fix langevin <fix_langevin>`, :doc:`fix
temp/berendsen <fix_temp_berendsen>`). You can also use one of the 4
NVE rigid styles for the rigid bodies and thermostat them using
:doc:`fix langevin <fix_langevin>` on the group that contains all the
particles in the rigid bodies. The net force added by :doc:`fix
langevin <fix_langevin>` to each rigid body effectively thermostats its
translational center-of-mass motion. Not sure how well it does at
thermostatting its rotational motion.
(:doc:`fix nvt <fix_nh>`, :doc:`fix langevin <fix_langevin>`,
:doc:`fix temp/berendsen <fix_temp_berendsen>`). You can also use one
of the 4 NVE rigid styles for the rigid bodies and thermostat them
using :doc:`fix langevin <fix_langevin>` on the group that contains
all the particles in the rigid bodies. The net force added by
:doc:`fix langevin <fix_langevin>` to each rigid body effectively
thermostats its translational center-of-mass motion. Not sure how
well it does at thermostatting its rotational motion.
If you wish to perform NPT or NPH dynamics (barostatting), you cannot
use both :doc:`fix npt <fix_nh>` and the NPT or NPH rigid styles. This
@ -774,12 +787,12 @@ to the global pressure and the box is scaled the same by any of the
barostatting fixes.
You could even use the second and third options for a non-hybrid
simulation consisting of only rigid bodies, assuming you give :doc:`fix
npt <fix_nh>` an empty group, though it's an odd thing to do. The
barostatting fixes (:doc:`fix npt <fix_nh>` and :doc:`fix press/berensen
<fix_press_berendsen>`) will monitor the pressure and change the box
dimensions, but not time integrate any particles. The integration of
the rigid bodies will be performed by fix rigid/nvt.
simulation consisting of only rigid bodies, assuming you give
:doc:`fix npt <fix_nh>` an empty group, though it's an odd thing to
do. The barostatting fixes (:doc:`fix npt <fix_nh>` and :doc:`fix
press/berensen <fix_press_berendsen>`) will monitor the pressure and
change the box dimensions, but not time integrate any particles. The
integration of the rigid bodies will be performed by fix rigid/nvt.
----------
@ -824,10 +837,10 @@ various :doc:`output commands <Howto_output>`. 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.
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, but only for the *rigid* and
*rigid/nve* fixes.

2
doc/src/fix_wall_flow.rst
View File

@ -40,7 +40,7 @@ Examples
Description
"""""""""""
.. versionadded:: TBD
.. versionadded:: 17Apr2024
This fix implements flow boundary conditions (FBC) introduced in
:ref:`(Pavlov1) <fbc-Pavlov1>` and :ref:`(Pavlov2) <fbc-Pavlov2>`.

9
doc/src/labelmap.rst
View File

@ -43,7 +43,8 @@ The label map can also be defined by the :doc:`read_data <read_data>`
command when it reads these sections in a data file: Atom Type Labels,
Bond Type Labels, etc. See the :doc:`Howto type labels
<Howto_type_labels>` doc page for a general discussion of how type
labels can be used.
labels can be used. See :ref:`(Gissinger) <Typelabel>` for a discussion
of the type label implementation in LAMMPS and its uses.
Valid type labels can contain any alphanumeric character, but must not
start with a number, a '#', or a '*' character. They can contain other
@ -98,3 +99,9 @@ Default
"""""""
none
-----------
.. _Typelabel:
**(Gissinger)** J. R. Gissinger, I. Nikiforov, Y. Afshar, B. Waters, M. Choi, D. S. Karls, A. Stukowski, W. Im, H. Heinz, A. Kohlmeyer, and E. B. Tadmor, J Phys Chem B, 128, 3282-3297 (2024).

96
doc/src/lattice.rst
View File

@ -19,7 +19,7 @@ Syntax
scale = lattice constant in distance units (for all other units)
* zero or more keyword/value pairs may be appended
* keyword = *origin* or *orient* or *spacing* or *a1* or *a2* or *a3* or *basis*
* keyword = *origin* or *orient* or *spacing* or *a1* or *a2* or *a3* or *basis* or *triclinic/general*
.. parsed-literal::
@ -34,6 +34,7 @@ Syntax
x,y,z = primitive vector components that define unit cell
*basis* values = x y z
x,y,z = fractional coords of a basis atom (0 <= x,y,z < 1)
*triclinic/general* values = no values
Examples
""""""""
@ -44,7 +45,7 @@ Examples
lattice hex 0.85
lattice sq 0.8 origin 0.0 0.5 0.0 orient x 1 1 0 orient y -1 1 0
lattice custom 3.52 a1 1.0 0.0 0.0 a2 0.5 1.0 0.0 a3 0.0 0.0 0.5 &
basis 0.0 0.0 0.0 basis 0.5 0.5 0.5
basis 0.0 0.0 0.0 basis 0.5 0.5 0.5 triclinic/general
lattice none 2.0
Description
@ -129,10 +130,13 @@ and a3 are 3 orthogonal unit vectors (edges of a unit cube). But you
can specify them to be of any length and non-orthogonal to each other,
so that they describe a tilted parallelepiped. Via the *basis*
keyword you add atoms, one at a time, to the unit cell. Its arguments
are fractional coordinates (0.0 <= x,y,z < 1.0). The position vector
x of a basis atom within the unit cell is thus a linear combination of
the unit cell's 3 edge vectors, i.e. x = bx a1 + by a2 + bz a3,
where bx,by,bz are the 3 values specified for the *basis* keyword.
are fractional coordinates (0.0 <= x,y,z < 1.0). For 2d simulations,
the fractional z coordinate for any basis atom must be 0.0.
The position vector x of a basis atom within the unit cell is a linear
combination of the unit cell's 3 edge vectors, i.e. x = bx a1 + by
a2 + bz a3, where bx,by,bz are the 3 values specified for the *basis*
keyword.
----------
@ -168,18 +172,21 @@ The *origin* option specifies how the unit cell will be shifted or
translated when mapping it into the simulation box. The x,y,z values
are fractional values (0.0 <= x,y,z < 1.0) meaning shift the lattice
by a fraction of the lattice spacing in each dimension. The meaning
of "lattice spacing" is discussed below.
of "lattice spacing" is discussed below. For 2d simulations, the
*origin* z value must be 0.0.
The *orient* option specifies how the unit cell will be rotated when
mapping it into the simulation box. The *dim* argument is one of the
3 coordinate axes in the simulation box. The other 3 arguments are
the crystallographic direction in the lattice that you want to orient
along that axis, specified as integers. E.g. "orient x 2 1 0" means
the x-axis in the simulation box will be the [210] lattice
direction, and similarly for y and z. The 3 lattice directions you
specify do not have to be unit vectors, but they must be mutually
orthogonal and obey the right-hand rule, i.e. (X cross Y) points in
the Z direction.
the x-axis in the simulation box will be the [210] lattice direction,
and similarly for y and z. The 3 lattice directions you specify do
not have to be unit vectors, but they must be mutually orthogonal and
obey the right-hand rule, i.e. (X cross Y) points in the Z direction.
For 2d simulations, the *orient* x and y vectors must define 0 for
their 3rd component. Similarly the *orient* z vector must define 0
for its 1st and 2nd components.
.. note::
@ -193,6 +200,59 @@ the Z direction.
----------
The *triclinic/general* option specifies that the defined lattice is
for use with a general triclinic simulation box, as opposed to an
orthogonal or restricted triclinic box. The :doc:`Howto triclinic
<Howto_triclinic>` doc page explains all 3 kinds of simulation boxes
LAMMPS supports.
If this option is specified, a *custom* lattice style must be used.
The *a1*, *a2*, *a3* vectors should define the edge vectors of a
single unit cell of the lattice with one or more basis atoms. They
edge vectors can be arbitrary so long as they are non-zero, distinct,
and not co-planar. In addition, they must define a right-handed
system, such that (*a1* cross *a2*) points in the direction of *a3*.
Note that a left-handed system can be converted to a right-handed
system by simply swapping the order of any pair of the *a1*, *a2*,
*a3* vectors. For 2d simulations, the *a3* vector must be specified
as (0.0,0.0,1.0), which is its default value.
If this option is used, the *origin* and *orient* settings must have
their default values. Namely (0.0,0.0,0.0) for the *origin* and
(100), (010), (001) for the *orient* vectors.
The :doc:`create_box <create_box>` command can be used to create a
general triclinic box that replicates the *a1*, *a2*, *a3* unit cell
vectors in each direction to create the 3 arbitrary edge vectors of
the overall simulation box. It requires a lattice with the
*triclinic/general* option.
Likewise, the :doc:`create_atoms <create_atoms>` command can be used
to add atoms (or molecules) to a general triclinic box which lie on
the lattice points defined by *a1*, *a2*, *a3* and the unit cell basis
atoms. To do this, it also requires a lattice with the
*triclinic/general* option.
.. note::
LAMMPS allows specification of general triclinic lattices and
simulation boxes as a convenience for users who may be converting
data from solid-state crystallographic representations or from DFT
codes for input to LAMMPS. However, as explained on the
:doc:`Howto_triclinic <Howto_triclinic>` doc page, internally,
LAMMPS only uses restricted triclinic simulation boxes. This means
the box and per-atom information (e.g. coordinates, velocities)
defined by the :doc:`create_box <create_box>` and
:doc:`create_atoms <create_atoms>` commands are converted from
general to restricted triclinic form when the two commands are
invoked. It also means that any other commands which use lattice
spacings from this command (e.g. the region command), will be
operating on a restricted triclinic simulation box, even if the
*triclinic/general* option was used to define the lattice. See the
next section for details.
----------
Several LAMMPS commands have the option to use distance units that are
inferred from "lattice spacings" in the x,y,z box directions.
E.g. the :doc:`region <region>` command can create a block of size
@ -216,6 +276,18 @@ coordinates of the 8 corner points of the modified unit cell (4 in
2d). Similarly, the Y and Z lattice spacings are defined as the
difference in the min/max of the y and z coordinates.
.. note::
If the *triclinic/general* option is specified, the unit cell
defined by *a1*, *a2*, *a3* edge vectors is first converted to a
restricted triclinic orientation, which is a rotation operation.
The min/max extent of the 8 corner points is then determined, as
described in the preceding paragraph, to set the lattice
spacings. As explained for the *triclinic/general* option above,
this is because any use of the lattice spacings by other commands
will be for a restricted triclinic simulation box, not a general
triclinic box.
Note that if the unit cell is orthogonal with axis-aligned edges (no
rotation via the *orient* keyword), then the lattice spacings in each
dimension are simply the scale factor (described above) multiplied by

2
doc/src/package.rst
View File

@ -576,7 +576,7 @@ changed to *no* since the *sort* keyword does not support *host* mode. Not
all fix styles with extra atom data support *device* mode and in that case
a warning will be given and atom sorting will run in *no* mode instead.
.. versionadded:: TBD
.. versionadded:: 17Apr2024
The *atom/map* keyword determines whether the host or device builds the
atom_map, see the :doc:`atom_modify map <atom_modify>` command. The

15
doc/src/pair_eam.rst
View File

@ -140,6 +140,21 @@ The OpenKIM Project at
provides EAM potentials that can be used directly in LAMMPS with the
:doc:`kim command <kim_commands>` interface.
.. warning::
The EAM potential files tabulate the embedding energy as a function
of the local electron density :math:`\rho`. When atoms get too
close, this electron density may exceed the range for which the
embedding energy was tabulated for. To avoid crashes, LAMMPS will
assume a linearly increasing embedding energy for electron densities
beyond the maximum tabulated value. LAMMPS will print a warning when
this happens. It may be acceptable at the beginning of an
equilibration (e.g. when using randomized coordinates) but would be a
big concern for accuracy if it happens during production runs. The
EAM potential file triggering the warning during production is thus
not a good choice, and the EAM model in general not likely a good
model for the kind of system under investigation.
----------
For style *eam*, potential values are read from a file that is in the

64
doc/src/pair_mliap.rst
View File

@ -22,7 +22,7 @@ Syntax
style = *linear* or *quadratic* or *nn* or *mliappy*
filename = name of file containing model definitions
*descriptor* values = style filename
style = *sna* or *so3*
style = *sna* or *so3* or *ace*
filename = name of file containing descriptor definitions
*unified* values = filename ghostneigh_flag
filename = name of file containing serialized unified Python object
@ -36,6 +36,7 @@ Examples
pair_style mliap model linear InP.mliap.model descriptor sna InP.mliap.descriptor
pair_style mliap model quadratic W.mliap.model descriptor sna W.mliap.descriptor
pair_style mliap model nn Si.nn.mliap.model descriptor so3 Si.nn.mliap.descriptor
pair_style mliap model mliappy ACE_NN_Pytorch.pt descriptor ace ccs_single_element.yace
pair_style mliap unified mliap_unified_lj_Ar.pkl 0
pair_coeff * * In P
@ -49,8 +50,8 @@ quantities that characterize the atomic positions (*descriptor*).
By defining *model* and *descriptor* separately, it is possible to use
many different models with a given descriptor, or many different
descriptors with a given model. The pair style currently supports only
*sna* and *so3* descriptor styles, but it is straightforward to add new
descriptors with a given model. The pair style currently supports *sna*,
*so3* and *ace* descriptor styles, but it is straightforward to add new
descriptor styles. By using the *unified* keyword, it is possible to
define a Python model that combines functionalities of both *model* and
*descriptor*.
@ -72,6 +73,26 @@ the smooth SO(3) power spectrum with the explicit inclusion of a radial
basis :ref:`(Bartok) <Bartok2013>` and :ref:`(Zagaceta) <Zagaceta2020>`.
The available models are *linear* and *nn*.
.. versionadded:: 17Apr2024
The descriptor style *ace* is a class of highly general atomic
descriptors, atomic cluster expansion descriptors (ACE) from
:ref:`(Drautz) <Drautz19>`, that include a radial basis, an angular
basis, and bases for other variables (such as chemical species) if
relevant. In descriptor style *ace*, the *ace* descriptors may be
defined up to an arbitrary body order. This descriptor style is the same
as that used in :doc:`pair_style pace <pair_pace>` and :doc:`compute
pace <compute_pace>`. The available models with *ace* in ML-IAP are
*linear* and *mliappy*. The *ace* descriptors and models require
building LAMMPS with the ML-PACE package (see below). The *mliappy*
model style may be used with *ace* descriptors, but it requires that
LAMMPS is also built with the PYTHON package. As with other model
styles, the *mliappy* model style can be used to couple arbitrary python
models that use the *ace* descriptors such as Pytorch NNs. Note that
*ALL* mliap model styles with *ace* descriptors require that descriptors
and hyperparameters are supplied in a `.yace` or `.ace` file, similar to
:doc:`compute pace <compute_pace>`.
The pair_style *mliap* command must be followed by two keywords *model*
and *descriptor* in either order, or the one keyword *unified*. A
single *pair_coeff* command is also required. The first 2 arguments
@ -136,7 +157,7 @@ The detail of *nn* module implementation can be found at :ref:`(Yanxon) <Yanxon2
the mliap-specific python module that is built into LAMMPS.
The *descriptor* keyword is followed by a descriptor style, and additional arguments.
Currently two descriptor styles are available: *sna* and *so3*.
Currently three descriptor styles are available: *sna*, *so3*, and *ace*.
- *sna* indicates the bispectrum component descriptors used by the Spectral
Neighbor Analysis Potential (SNAP) potentials of :doc:`pair_style snap
@ -148,6 +169,16 @@ Currently two descriptor styles are available: *sna* and *so3*.
- *so3* indicated the power spectrum component descriptors. A single additional
argument specifies the descriptor filename containing the parameters and setting.
- *ace* indicates the atomic cluster expansion (ACE) descriptors. A single
additional argument specifies the filename containing parameters, settings, and
definitions of the ace descriptors (through tabulated basis function indices and
corresponding generalized Clebsch-Gordan coefficients) in the ctilde file format,
e.g. in the potential file format with `*.ace` or `*.yace` extensions from
:doc:`pair_style pace <pair_pace>`. Note that unlike the potential file, the
Clebsch-Gordan coefficients in the descriptor file supplied should *NOT* be
multiplied by linear or square root embedding terms.
The SNAP descriptor file closely follows the format of the
:doc:`pair_style snap <pair_snap>` parameter file. The file can contain
blank and comment lines (start with #) anywhere. Each non-blank
@ -169,6 +200,24 @@ contains a few more arguments (e.g., *nmax* and *alpha*). The preparation
of SO3 descriptor and model files can be done with the
`Pyxtal_FF <https://github.com/qzhu2017/PyXtal_FF>`_ package.
The ACE descriptor file differs from the SNAP and SO3 files. It more
closely resembles the potential file format for linear or square-root
embedding ACE potentials used in the :doc:`pair_style pace <pair_pace>`.
As noted above, the key difference is that the Clebsch-Gordan
coefficients in the descriptor file with *mliap descriptor ace* are
*NOT* multiplied by linear or square root embedding terms. In other
words,the model is separated from the descriptor definitions and
hyperparameters. In :doc:`pair_style pace <pair_pace>`, they are
combined. The ACE descriptor files required by *mliap* are generated
automatically in `FitSNAP <https://github.com/FitSNAP/FitSNAP>`_ during
linear, pytorch, etc. ACE model fitting. Additional tools are provided
there to prepare *ace* descriptor files and hyperparameters before model
fitting. The *ace* descriptor files can also be extracted from ACE
model fits in `python-ace. <https://github.com/ICAMS/python-ace>`_. It
is important to note that order of the types listed in :doc:`pair_coeff
<pair_coeff>` must match the order of the elements/types listed in the
ACE descriptor file for all *mliap* styles when using *ace* descriptors.
See the :doc:`pair_coeff <pair_coeff>` page for alternate ways
to specify the path for these *model* and *descriptor* files.
@ -245,7 +294,10 @@ This pair style is part of the ML-IAP package. It is only enabled if
LAMMPS was built with that package. In addition, building LAMMPS with
the ML-IAP package requires building LAMMPS with the ML-SNAP package.
The *mliappy* model requires building LAMMPS with the PYTHON package.
See the :doc:`Build package <Build_package>` page for more info.
The *ace* descriptor requires building LAMMPS with the ML-PACE package.
See the :doc:`Build package <Build_package>` page for more info. Note
that `pair_mliap/kk` acceleration will *not* invoke the `kk`
accelerated variants of SNAP or ACE descriptors.
Related commands
@ -271,5 +323,3 @@ none
.. _Yanxon2020:
**(Yanxon2020)** Yanxon, Zagaceta, Tang, Matteson, Zhu, Mach. Learn.: Sci. Technol. 2, 027001 (2020).

137
doc/src/pair_pedone.rst Normal file
View File

@ -0,0 +1,137 @@
.. index:: pair_style pedone
.. index:: pair_style pedone/omp
pair_style pedone command
=========================
Accelerator Variants: *pedone/omp*
Syntax
""""""
.. code-block:: LAMMPS
pair_style style args
* style = pedone*
* args = list of arguments for a particular style
.. parsed-literal::
*pedone* args = cutoff
cutoff = global cutoff for Pedone interactions (distance units)
Examples
""""""""
.. code-block:: LAMMPS
pair_style hybrid/overlay pedone 15.0 coul/long 15.0
kspace_style pppm 1.0e-5
pair_coeff * * coul/long
pair_coeff 1 2 pedone 0.030211 2.241334 2.923245 5.0
pair_coeff 2 2 pedone 0.042395 1.379316 3.618701 22.0
Used in input scripts:
.. parsed-literal::
examples/PACKAGES/pedone/in.pedone.relax
examples/PACKAGES/pedone/in.pedone.melt
Description
"""""""""""
.. versionadded:: 17Apr2024
Pair style *pedone* computes the **non-Coulomb** interactions of the Pedone
(or PMMCS) potential :ref:`(Pedone) <Pedone>` which combines Coulomb
interactions, Morse potential, and repulsive :math:`r^{-12}`
Lennard-Jones terms (see below). The *pedone* pair style is meant
to be used in addition to a :doc:`Coulomb pair style <pair_coul>` via
pair style :doc:`hybrid/overlay <pair_hybrid>` (see example above).
Using *coul/long* or *could/dsf* (for solids) is recommended.
The full Pedone potential function from :ref:`(Pedone) <Pedone>` for each
pair of atoms is:
.. math::
E = \frac{C q_i q_j}{\epsilon r}
+ D_0 \left[ e^{- 2 \alpha (r - r_0)} - 2 e^{- \alpha (r - r_0)} \right]
+ \frac{B_0}{r^{12}} \qquad r < r_c
:math:`r_c` is the cutoff and :math:`C` is a conversion factor that is
specific to the choice of :doc:`units <units>` so that the entire
Coulomb term is in energy units with :math:`q_i` and :math:`q_j` as the
assigned charges in multiples of the elementary charge.
The following coefficients must be defined for the selected pairs of
atom types via the :doc:`pair_coeff <pair_coeff>` command as in the
example above:
* :math:`D_0` (energy units)
* :math:`\alpha` (1/distance units)
* :math:`r_0` (distance units)
* :math:`C_0` (energy units)
* cutoff (distance units)
The last coefficient is optional. If not specified, the global *pedone*
cutoff is used.
----------
.. include:: accel_styles.rst
----------
Mixing, shift, table, tail correction, restart, rRESPA info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
This pair style does not support mixing.
This pair style support the :doc:`pair_modify <pair_modify>` shift
option for the energy of the pair interaction.
This pair style does not support the :doc:`pair_modify <pair_modify>`
tail option for adding long-range tail corrections to energy and
pressure.
This pair style writes its information to :doc:`binary restart files <restart>`,
so pair_style and pair_coeff commands does not need to be specified in an input
script that reads a restart file.
This pair style can only be used via the *pair* keyword of the
:doc:`run_style respa <run_style>` command. It does not support the
*inner*, *middle*, or *outer* keywords.
----------
Restrictions
""""""""""""
The *pedone* pair style is only enabled if LAMMPS was built with the
EXTRA-PAIR package. See the :doc:`Build package <Build_package>` page
for more info.
Related commands
""""""""""""""""
:doc:`pair_coeff <pair_coeff>`, :doc:`pair_style <pair_style>`,
:doc:`pair style coul/long and coul/dsf <pair_coul>`,
:doc:`pair style morse <pair_morse>`
Default
"""""""
none
-------------
.. _Pedone:
**(Pedone)** A. Pedone, G. Malavasi, M. C. Menziani, A. N. Cormack, and U. Segre, J. Phys. Chem. B, 110, 11780 (2006)

2
doc/src/pair_rebomos.rst
View File

@ -28,7 +28,7 @@ Example input scripts available: examples/threebody/
Description
"""""""""""
.. versionadded:: TBD
.. versionadded:: 17Apr2024
The *rebomos* pair style computes the interactions between molybdenum
and sulfur atoms :ref:`(Stewart) <Stewart>` utilizing an adaptive

49
doc/src/pair_style.rst
View File

@ -275,30 +275,30 @@ accelerated styles exist.
* :doc:`lj/smooth/linear <pair_lj_smooth_linear>` - linear smoothed LJ potential
* :doc:`lj/switch3/coulgauss/long <pair_lj_switch3_coulgauss_long>` - smoothed LJ vdW potential with Gaussian electrostatics
* :doc:`lj96/cut <pair_lj96>` - Lennard-Jones 9/6 potential
* :doc:`local/density <pair_local_density>` - generalized basic local density potential
* :doc:`lubricate <pair_lubricate>` - hydrodynamic lubrication forces
* :doc:`lubricate/poly <pair_lubricate>` - hydrodynamic lubrication forces with polydispersity
* :doc:`lubricateU <pair_lubricateU>` - hydrodynamic lubrication forces for Fast Lubrication Dynamics
* :doc:`lubricateU/poly <pair_lubricateU>` - hydrodynamic lubrication forces for Fast Lubrication with polydispersity
* :doc:`local/density <pair_local_density>` - Generalized basic local density potential
* :doc:`lubricate <pair_lubricate>` - Hydrodynamic lubrication forces
* :doc:`lubricate/poly <pair_lubricate>` - Hydrodynamic lubrication forces with polydispersity
* :doc:`lubricateU <pair_lubricateU>` - Hydrodynamic lubrication forces for Fast Lubrication Dynamics
* :doc:`lubricateU/poly <pair_lubricateU>` - Hydrodynamic lubrication forces for Fast Lubrication with polydispersity
* :doc:`mdpd <pair_mesodpd>` - mDPD particle interactions
* :doc:`mdpd/rhosum <pair_mesodpd>` - mDPD particle interactions for mass density
* :doc:`meam <pair_meam>` - modified embedded atom method (MEAM)
* :doc:`meam/ms <pair_meam>` - multi-state modified embedded atom method (MS-MEAM)
* :doc:`meam/spline <pair_meam_spline>` - splined version of MEAM
* :doc:`meam/sw/spline <pair_meam_sw_spline>` - splined version of MEAM with a Stillinger-Weber term
* :doc:`mesocnt <pair_mesocnt>` - mesoscopic vdW potential for (carbon) nanotubes
* :doc:`mesocnt/viscous <pair_mesocnt>` - mesoscopic vdW potential for (carbon) nanotubes with friction
* :doc:`mgpt <pair_mgpt>` - simplified model generalized pseudopotential theory (MGPT) potential
* :doc:`meam <pair_meam>` - Modified embedded atom method (MEAM)
* :doc:`meam/ms <pair_meam>` - Multi-state modified embedded atom method (MS-MEAM)
* :doc:`meam/spline <pair_meam_spline>` - Splined version of MEAM
* :doc:`meam/sw/spline <pair_meam_sw_spline>` - Splined version of MEAM with a Stillinger-Weber term
* :doc:`mesocnt <pair_mesocnt>` - Mesoscopic vdW potential for (carbon) nanotubes
* :doc:`mesocnt/viscous <pair_mesocnt>` - Mesoscopic vdW potential for (carbon) nanotubes with friction
* :doc:`mgpt <pair_mgpt>` - Simplified model generalized pseudopotential theory (MGPT) potential
* :doc:`mie/cut <pair_mie>` - Mie potential
* :doc:`mm3/switch3/coulgauss/long <pair_lj_switch3_coulgauss_long>` - smoothed MM3 vdW potential with Gaussian electrostatics
* :doc:`mm3/switch3/coulgauss/long <pair_lj_switch3_coulgauss_long>` - Smoothed MM3 vdW potential with Gaussian electrostatics
* :doc:`momb <pair_momb>` - Many-Body Metal-Organic (MOMB) force field
* :doc:`morse <pair_morse>` - Morse potential
* :doc:`morse/smooth/linear <pair_morse>` - linear smoothed Morse potential
* :doc:`morse/smooth/linear <pair_morse>` - Linear smoothed Morse potential
* :doc:`morse/soft <pair_morse>` - Morse potential with a soft core
* :doc:`multi/lucy <pair_multi_lucy>` - DPD potential with density-dependent force
* :doc:`multi/lucy/rx <pair_multi_lucy_rx>` - reactive DPD potential with density-dependent force
* :doc:`nb3b/harmonic <pair_nb3b>` - non-bonded 3-body harmonic potential
* :doc:`nb3b/screened <pair_nb3b>` - non-bonded 3-body screened harmonic potential
* :doc:`nb3b/harmonic <pair_nb3b>` - Non-bonded 3-body harmonic potential
* :doc:`nb3b/screened <pair_nb3b>` - Non-bonded 3-body screened harmonic potential
* :doc:`nm/cut <pair_nm>` - N-M potential
* :doc:`nm/cut/coul/cut <pair_nm>` - N-M potential with cutoff Coulomb
* :doc:`nm/cut/coul/long <pair_nm>` - N-M potential with long-range Coulomb
@ -322,21 +322,22 @@ accelerated styles exist.
* :doc:`oxrna2/xstk <pair_oxrna2>` -
* :doc:`pace <pair_pace>` - Atomic Cluster Expansion (ACE) machine-learning potential
* :doc:`pace/extrapolation <pair_pace>` - Atomic Cluster Expansion (ACE) machine-learning potential with extrapolation grades
* :doc:`pedone <pair_pedone>` - Pedone (PMMCS) potential (non-Coulomb part)
* :doc:`pod <pair_pod>` - Proper orthogonal decomposition (POD) machine-learning potential
* :doc:`peri/eps <pair_peri>` - peridynamic EPS potential
* :doc:`peri/lps <pair_peri>` - peridynamic LPS potential
* :doc:`peri/pmb <pair_peri>` - peridynamic PMB potential
* :doc:`peri/ves <pair_peri>` - peridynamic VES potential
* :doc:`polymorphic <pair_polymorphic>` - polymorphic 3-body potential
* :doc:`peri/eps <pair_peri>` - Peridynamic EPS potential
* :doc:`peri/lps <pair_peri>` - Peridynamic LPS potential
* :doc:`peri/pmb <pair_peri>` - Peridynamic PMB potential
* :doc:`peri/ves <pair_peri>` - Peridynamic VES potential
* :doc:`polymorphic <pair_polymorphic>` - Polymorphic 3-body potential
* :doc:`python <pair_python>` -
* :doc:`quip <pair_quip>` -
* :doc:`rann <pair_rann>` -
* :doc:`reaxff <pair_reaxff>` - ReaxFF potential
* :doc:`rebo <pair_airebo>` - second generation REBO potential of Brenner
* :doc:`rebo <pair_airebo>` - Second generation REBO potential of Brenner
* :doc:`rebomos <pair_rebomos>` - REBOMoS potential for MoS2
* :doc:`resquared <pair_resquared>` - Everaers RE-Squared ellipsoidal potential
* :doc:`saip/metal <pair_saip_metal>` - interlayer potential for hetero-junctions formed with hexagonal 2D materials and metal surfaces
* :doc:`sdpd/taitwater/isothermal <pair_sdpd_taitwater_isothermal>` - smoothed dissipative particle dynamics for water at isothermal conditions
* :doc:`saip/metal <pair_saip_metal>` - Interlayer potential for hetero-junctions formed with hexagonal 2D materials and metal surfaces
* :doc:`sdpd/taitwater/isothermal <pair_sdpd_taitwater_isothermal>` - Smoothed dissipative particle dynamics for water at isothermal conditions
* :doc:`smatb <pair_smatb>` - Second Moment Approximation to the Tight Binding
* :doc:`smatb/single <pair_smatb>` - Second Moment Approximation to the Tight Binding for single-element systems
* :doc:`smd/hertz <pair_smd_hertz>` -

562
doc/src/read_data.rst
View File

@ -63,11 +63,16 @@ Description
Read in a data file containing information LAMMPS needs to run a
simulation. The file can be ASCII text or a gzipped text file
(detected by a .gz suffix). This is one of 3 ways to specify initial
atom coordinates; see the :doc:`read_restart <read_restart>` and
:doc:`create_atoms <create_atoms>` commands for alternative methods.
Also see the explanation of the :doc:`-restart command-line switch
<Run_options>` which can convert a restart file to a data file.
(detected by a .gz suffix).
This is one of 3 ways to specify the simulation box: see the
:doc:`create_box <create_box>` and :doc:`read_restart <read_restart>`
and commands for alternative methods. It is also one of 3 ways to
specify initial atom coordinates: see the :doc:`create_atoms
<create_atoms>` and :doc:`read_restart <read_restart>` and commands
for alternative methods. Also see the explanation of the
:doc:`-restart command-line switch <Run_options>` which can convert a
restart file to a data file.
This command can be used multiple times to add new atoms and their
properties to an existing system by using the *add*, *offset*, and
@ -122,37 +127,55 @@ keyword must be used.
.. note::
The simulation box size (xlo to xhi, ylo to yhi, zlo to zhi) in
the new data file will be merged with the existing simulation box to
create a large enough box in each dimension to contain both the
existing and new atoms. Each box dimension never shrinks due to this
merge operation, it only stays the same or grows. Care must be used if
you are growing the existing simulation box in a periodic dimension.
If there are existing atoms with bonds that straddle that periodic
boundary, then the atoms may become far apart if the box size grows.
This will separate the atoms in the bond, which can lead to "lost"
bond atoms or bad dynamics.
If the first read_data command defined an orthogonal or restricted
triclinic or general triclinic simulation box (see the sub-section
below on header keywords), then subsequent data files must define
the same kind of simulation box. For orthogonal boxes, the new box
can be a different size; see the next Note. For a restricted
triclinic box, the 3 new tilt factors ("xy xz yz" keyword) must
have the same values as in the original data file. For a general
triclinic box, the new avec, bvec, cvec, and "abc origin" keywords
must have the same values in the original data file. files. Also
the *shift* keyword cannot be used in subsequent read_data commands
for a general triclinic box.
.. note::
For orthogonal boxes, the simulation box size in the new data file
will be merged with the existing simulation box to create a large
enough box in each dimension to contain both the existing and new
atoms. Each box dimension never shrinks due to this merge
operation, it only stays the same or grows. Care must be used if
you are growing the existing simulation box in a periodic
dimension. If there are existing atoms with bonds that straddle
that periodic boundary, then the atoms may become far apart if the
box size grows. This will separate the atoms in the bond, which
can lead to "lost" bond atoms or bad dynamics.
The three choices for the *add* argument affect how the atom IDs and
molecule IDs of atoms in the data file are treated. If *append* is
specified, atoms in the data file are added to the current system,
with their atom IDs reset so that an atom-ID = M in the data file
becomes atom-ID = N+M, where N is the largest atom ID in the current
system. This rule is applied to all occurrences of atom IDs in the
data file, e.g. in the Velocity or Bonds section. This is also done
for molecule IDs, if the atom style does support molecule IDs or
they are enabled via fix property/atom. If *IDoffset* is specified,
then *IDoffset* is a numeric value is given, e.g. 1000, so that an
atom-ID = M in the data file becomes atom-ID = 1000+M. For systems
with enabled molecule IDs, another numerical argument *MOLoffset*
is required representing the equivalent offset for molecule IDs.
If *merge* is specified, the data file atoms
are added to the current system without changing their IDs. They are
assumed to merge (without duplication) with the currently defined
atoms. It is up to you to ensure there are no multiply defined atom
IDs, as LAMMPS only performs an incomplete check that this is the case
by ensuring the resulting max atom-ID >= the number of atoms. For
molecule IDs, there is no check done at all.
molecule IDs of atoms in the data file are treated.
If *append* is specified, atoms in the data file are added to the
current system, with their atom IDs reset so that an atom-ID = M in
the data file becomes atom-ID = N+M, where N is the largest atom ID in
the current system. This rule is applied to all occurrences of atom
IDs in the data file, e.g. in the Velocity or Bonds section. This is
also done for molecule IDs, if the atom style does support molecule
IDs or they are enabled via fix property/atom.
If *IDoffset* is specified, then *IDoffset* is a numeric value is
given, e.g. 1000, so that an atom-ID = M in the data file becomes
atom-ID = 1000+M. For systems with enabled molecule IDs, another
numerical argument *MOLoffset* is required representing the equivalent
offset for molecule IDs.
If *merge* is specified, the data file atoms are added to the current
system without changing their IDs. They are assumed to merge (without
duplication) with the currently defined atoms. It is up to you to
ensure there are no multiply defined atom IDs, as LAMMPS only performs
an incomplete check that this is the case by ensuring the resulting
max atom-ID >= the number of atoms. For molecule IDs, there is no
check done at all.
The *offset* and *shift* keywords can only be used if the *add*
keyword is also specified.
@ -288,13 +311,16 @@ Format of the header of a data file
"""""""""""""""""""""""""""""""""""
These are the recognized header keywords. Header lines can come in
any order. The value(s) are read from the beginning of the line.
any order. Each keyword takes a single value unless noted in this
list. The value(s) are read from the beginning of the line.
Thus the keyword *atoms* should be in a line like "1000 atoms"; the
keyword *ylo yhi* should be in a line like "-10.0 10.0 ylo yhi"; the
keyword *xy xz yz* should be in a line like "0.0 5.0 6.0 xy xz yz".
All these settings have a default value of 0, except the lo/hi box
size defaults are -0.5 and 0.5. A line need only appear if the value
is different than the default.
All these settings have a default value of 0, except for the
simulation box size settings; their defaults are explained below. A
keyword line need only appear if its value is different than the
default.
* *atoms* = # of atoms in system
* *bonds* = # of bonds in system
@ -315,81 +341,178 @@ is different than the default.
* *lines* = # of line segments in system
* *triangles* = # of triangles in system
* *bodies* = # of bodies in system
* *xlo xhi* = simulation box boundaries in x dimension
* *ylo yhi* = simulation box boundaries in y dimension
* *zlo zhi* = simulation box boundaries in z dimension
* *xy xz yz* = simulation box tilt factors for triclinic system
* *xlo xhi* = simulation box boundaries in x dimension (2 values)
* *ylo yhi* = simulation box boundaries in y dimension (2 values)
* *zlo zhi* = simulation box boundaries in z dimension (2 values)
* *xy xz yz* = simulation box tilt factors for triclinic system (3 values)
* *avec* = first edge vector of a general triclinic simulation box (3 values)
* *bvec* = second edge vector of a general triclinic simulation box (3 values)
* *cvec* = third edge vector of a general triclinic simulation box (3 values)
* *abc origin* = origin of a general triclinic simulation box (3 values)
The initial simulation box size is determined by the lo/hi settings.
In any dimension, the system may be periodic or non-periodic; see the
:doc:`boundary <boundary>` command. When the simulation box is created
it is also partitioned into a regular 3d grid of rectangular bricks,
one per processor, based on the number of processors being used and
the settings of the :doc:`processors <processors>` command. The
partitioning can later be changed by the :doc:`balance <balance>` or
:doc:`fix balance <fix_balance>` commands.
----------
If the *xy xz yz* line does not appear, LAMMPS will set up an
axis-aligned (orthogonal) simulation box. If the line does appear,
LAMMPS creates a non-orthogonal simulation domain shaped as a
parallelepiped with triclinic symmetry. The parallelepiped has its
"origin" at (xlo,ylo,zlo) and is defined by 3 edge vectors starting
from the origin given by A = (xhi-xlo,0,0); B = (xy,yhi-ylo,0); C =
(xz,yz,zhi-zlo). *Xy,xz,yz* can be 0.0 or positive or negative values
and are called "tilt factors" because they are the amount of
displacement applied to faces of an originally orthogonal box to
transform it into the parallelepiped.
Header specification of the simulation box size and shape
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""
The tilt factors (xy,xz,yz) should not skew the box more than half the
distance of the corresponding parallel box length. For example, if
:math:`x_\text{lo} = 2` and :math:`x_\text{hi} = 12`, then the :math:`x`
box length is 10 and the :math:`xy` tilt factor must be between
:math:`-5` and :math:`5`. Similarly, both :math:`xz` and :math:`yz`
must be between :math:`-(x_\text{hi}-x_\text{lo})/2` and
:math:`+(y_\text{hi}-y_\text{lo})/2`. Note that this is not a
limitation, since if the maximum tilt factor is 5 (as in this example),
then configurations with tilt :math:`= \dots, -15`, :math:`-5`,
:math:`5`, :math:`15`, :math:`25, \dots` are all geometrically
equivalent. Simulations with large tilt factors will run inefficiently,
since they require more ghost atoms and thus more communication. With
very large tilt factors, LAMMPS will eventually produce incorrect
trajectories and stop with errors due to lost atoms or similar.
The last 8 keywords in the list of header keywords are for simulation
boxes of 3 kinds which LAMMPS supports:
See the :doc:`Howto triclinic <Howto_triclinic>` page for a
geometric description of triclinic boxes, as defined by LAMMPS, and
how to transform these parameters to and from other commonly used
triclinic representations.
* orthogonal box = faces are perpendicular to the xyz coordinate axes
* restricted triclinic box = a parallelepiped defined by 3 edge vectors oriented in a constrained manner
* general triclinic box = a parallelepiped defined by 3 arbitrary edge vectors
When a triclinic system is used, the simulation domain should normally
be periodic in the dimension that the tilt is applied to, which is
given by the second dimension of the tilt factor (e.g. y for xy tilt).
This is so that pairs of atoms interacting across that boundary will
have one of them shifted by the tilt factor. Periodicity is set by
the :doc:`boundary <boundary>` command. For example, if the xy tilt
factor is non-zero, then the y dimension should be periodic.
Similarly, the z dimension should be periodic if xz or yz is non-zero.
LAMMPS does not require this periodicity, but you may lose atoms if
this is not the case.
For restricted and general triclinic boxes, see the
:doc:`Howto_triclinic <Howto_triclinic>` doc page for a fuller
description than is given here.
Also note that if your simulation will tilt the box, e.g. via the
:doc:`fix deform <fix_deform>` command, the simulation box must be setup
to be triclinic, even if the tilt factors are initially 0.0. You can
also change an orthogonal box to a triclinic box or vice versa by using
the :doc:`change box <change_box>` command with its *ortho* and
*triclinic* options.
The units of the values for all 8 keywords in in distance units; see
the :doc:`units <units>` command for details.
For 2d simulations, the *zlo zhi* values should be set to bound the z
coords for atoms that appear in the file; the default of -0.5 0.5 is
valid if all z coords are 0.0. For 2d triclinic simulations, the xz
and yz tilt factors must be 0.0.
For all 3 kinds of simulation boxes, the system may be periodic or
non-periodic in any dimension; see the :doc:`boundary <boundary>`
command for details.
When the simulation box is created by the read_data command, it is
also partitioned into a regular 3d grid of subdomains, one per
processor, based on the number of processors being used and the
settings of the :doc:`processors <processors>` command. For each kind
of simulation box the subdomains have the same shape as the simulation
box, i.e. smaller orthogonal bricks for orthogonal boxes, smaller
parallelepipeds for triclinic boxes. The partitioning can later be
changed by the :doc:`balance <balance>` or :doc:`fix balance
<fix_balance>` commands.
For an orthogonal box, only the *xlo xhi*, *ylo yhi*, *zlo zhi*
keywords are used. They define the extent of the simulation box in
each dimension so that the resulting edge vectors of an orthogonal box
are:
* **A** = (xhi-xlo,0,0)
* **B** = (0,yhi-ylo,0)
* **C** = (0,0,zhi-zlo)
The origin (lower left corner) of the orthogonal box is at
(xlo,ylo,zlo). The default values for these 3 keywords are -0.5 and
0.5 for each lo/hi pair. For a 2d simulation, the zlo and zhi values
must straddle zero. The default zlo/zhi values do this, so that
keyword is not needed in 2d.
For a restricted triclinic box, the *xy xz yz* keyword is used in
addition to the *xlo xhi*, *ylo yhi*, *zlo zhi* keywords. The three
*xy,xz,yz* values can be 0.0 or positive or negative, and are called
"tilt factors" because they are the amount of displacement applied to
edges of faces of an orthogonal box to transform it into a restricted
triclinic parallelepiped.
The :doc:`Howto_triclinic <Howto_triclinic>` doc page discusses the
tilt factors in detail and explains that the resulting edge vectors of
a restricted triclinic box are:
* **A** = (xhi-xlo,0,0)
* **B** = (xy,yhi-ylo,0)
* **C** = (xz,yz,zhi-zlo)
This restricted form of edge vectors requires that **A** be in the
direction of the x-axis, **B** be in the xy plane with its y-component
in the +y direction, and **C** have its z-component in the +z
direction. The origin (lower left corner) of the restricted triclinic
box is at (xlo,ylo,zlo).
For a 2d simulation, the zlo and zhi values must straddle zero. The
default zlo/zhi values do this, so that keyword is not needed in 2d.
The xz and yz values must also be zero in 2d. The shape of the 2d
restricted triclinic simulation box is effectively a parallelogram.
.. note::
When a restricted triclinic box is used, the simulation domain
should normally be periodic in any dimensions that tilt is applied
to, which is given by the second dimension of the tilt factor
(e.g. y for xy tilt). This is so that pairs of atoms interacting
across that boundary will have one of them shifted by the tilt
factor. Periodicity is set by the :doc:`boundary <boundary>`
command which also describes the shifting by the tilt factor. For
example, if the xy tilt factor is non-zero, then the y dimension
should be periodic. Similarly, the z dimension should be periodic
if xz or yz is non-zero. LAMMPS does not require this periodicity,
but you may lose atoms if this is not the case.
.. note::
Normally, the specified tilt factors (xy,xz,yz) should not skew the
simulation box by more than half the distance of the corresponding
parallel box length for computational efficiency. For example, if
:math:`x_\text{lo} = 2` and :math:`x_\text{hi} = 12`, then the
:math:`x` box length is 10 and the :math:`xy` tilt factor should be
between :math:`-5` and :math:`5`. LAMMPS will issue a warning if
this is not the case. See the last sub-section of the
:doc:`Howto_triclinic <Howto_triclinic>` doc page for more details.
.. note::
If a simulation box is initially orthogonal, but will tilt during a
simulation, e.g. via the :doc:`fix deform <fix_deform>` command,
then the box should be defined as restricted triclinic with all 3
tilt factors = 0.0. Alternatively, the :doc:`change box
<change_box>` command can be used to convert an orthogonal box to a
restricted triclinic box.
For a general triclinic box, the *avec*, *bvec*, *cvec*, and *abc
origin* keywords are used. The *xlo xhi*, *ylo yhi*, *zlo zhi*, and
*xy xz yz* keywords are NOT used. The first 3 keywords define the 3
edge vectors **A**, **B**, **C** of the general triclinic box. They
can be arbitrary vectors so long as they are distinct, non-zero, and
not co-planar. They must also define a right-handed system such that
(**A** x **B**) points in the direction of **C**. Note that a
left-handed system can be converted to a right-handed system by simply
swapping the order of any pair of the **A**, **B**, **C** vectors.
The origin of the box (origin of the 3 edge vectors) is set by the
*abc origin* keyword.
The default values for these 4 keywords are as follows:
* avec = (1,0,0)
* bvec = (0,1,0)
* cvec = (0,0,1)
* abc origin = (0,0,0) for 3d, (0,0,-0.5) for 2d
For 2d simulations, *cvec* = (0,0,1) is required, and the 3rd value of
*abc origin* must be -0.5. These are the default values, so the
*cvec* keyword is not needed in 2d.
.. note::
LAMMPS allows specification of general triclinic simulation boxes
as a convenience for users who may be converting data from
solid-state crystallographic representations or from DFT codes for
input to LAMMPS. However, as explained on the
:doc:`Howto_triclinic <Howto_triclinic>` doc page, internally,
LAMMPS only uses restricted triclinic simulation boxes. This means
the box and per-atom information (e.g. coordinates, velocities) in
the data file are converted (rotated) from general to restricted
triclinic form when the file is read. Other sections of the data
file must also list their per-atom data appropriately if vector
quantities are specified. This requirement is explained below for
the relevant sections. The :doc:`Howto_triclinic
<Howto_triclinic>` doc page also discusses other LAMMPS commands
which can input/output general triclinic representations of the
simulation box and per-atom data.
The following explanations apply to all 3 kinds of simulation boxes:
orthogonal, restricted triclinic, and general triclinic.
If the system is periodic (in a dimension), then atom coordinates can
be outside the bounds (in that dimension); they will be remapped (in a
periodic sense) back inside the box. Note that if the *add* option is
being used to add atoms to a simulation box that already exists, this
periodic remapping will be performed using simulation box bounds that
are the union of the existing box and the box boundaries in the new
data file.
periodic sense) back inside the box. For triclinic boxes, periodicity
in x,y,z refers to the faces of the parallelepiped defined by the
**A**,**B**,**C** edge vectors of the simulation box. See the
:doc:`boundary <boundary>` command doc page for a fuller discussion.
Note that if the *add* option is being used to add atoms to a
simulation box that already exists, this periodic remapping will be
performed using simulation box bounds that are the union of the
existing box and the box boundaries in the new data file.
If the system is non-periodic (in a dimension), then an image flag for
that direction has no meaning, since there cannot be periodic images
@ -406,7 +529,6 @@ individually back into the principal unit cell in that direction. This
operation is equivalent to the behavior of the :doc:`change_box command
<change_box>` when used to change periodicity.
If those atoms with non-zero image flags are involved in bonded
interactions, this reset can lead to undesired changes, when the image
flag values differ between the atoms, i.e. the bonded interaction
@ -421,73 +543,81 @@ needed, so that the image flag would be zero.
.. note::
If the system is non-periodic (in a dimension), then all atoms in the
data file must have coordinates (in that dimension) that are "greater
than or equal to" the lo value and "less than or equal to" the hi
value. If the non-periodic dimension is of style "fixed" (see the
:doc:`boundary <boundary>` command), then the atom coords must be
strictly "less than" the hi value, due to the way LAMMPS assign atoms
to processors. Note that you should not make the lo/hi values
radically smaller/larger than the extent of the atoms. For example,
if your atoms extend from 0 to 50, you should not specify the box
bounds as -10000 and 10000 unless you also use the :doc:`processors
command <processors>`. This is because LAMMPS uses the specified box
size to layout the 3d grid of processors. A huge (mostly empty) box
will be sub-optimal for performance when using "fixed" boundary
conditions (see the :doc:`boundary <boundary>` command). When using
"shrink-wrap" boundary conditions (see the :doc:`boundary <boundary>`
command), a huge (mostly empty) box may cause a parallel simulation
to lose atoms when LAMMPS shrink-wraps the box around the atoms. The
read_data command will generate an error in this case.
If the system is non-periodic (in a dimension), then all atoms in
the data file must have coordinates (in that dimension) that are
"greater than or equal to" the lo value and "less than or equal to"
the hi value. If the non-periodic dimension is of style "fixed"
(see the :doc:`boundary <boundary>` command), then the atom coords
must be strictly "less than" the hi value, due to the way LAMMPS
assign atoms to processors. Note that you should not make the
lo/hi values radically smaller/larger than the extent of the atoms.
For example, if atoms extend from 0 to 50, you should not specify
the box bounds as -10000 and 10000 unless you also use the
:doc:`processors command <processors>`. This is because LAMMPS
uses the specified box size to layout the 3d grid of processors. A
huge (mostly empty) box will be sub-optimal for performance when
using "fixed" boundary conditions (see the :doc:`boundary
<boundary>` command). When using "shrink-wrap" boundary conditions
(see the :doc:`boundary <boundary>` command), a huge (mostly empty)
box may cause a parallel simulation to lose atoms when LAMMPS
shrink-wraps the box around the atoms. The read_data command will
generate an error in this case.
----------
Meaning of other header keywords
""""""""""""""""""""""""""""""""
The "extra bond per atom" setting (angle, dihedral, improper) is only
needed if new bonds (angles, dihedrals, impropers) will be added to
the system when a simulation runs, e.g. by using the :doc:`fix bond/create <fix_bond_create>` command. Using this header flag
is deprecated; please use the *extra/bond/per/atom* keyword (and
the system when a simulation runs, e.g. by using the :doc:`fix
bond/create <fix_bond_create>` command. Using this header flag is
deprecated; please use the *extra/bond/per/atom* keyword (and
correspondingly for angles, dihedrals and impropers) in the read_data
command instead. Either will pre-allocate space in LAMMPS data
structures for storing the new bonds (angles, dihedrals, impropers).
The "extra special per atom" setting is typically only needed if new
bonds/angles/etc will be added to the system, e.g. by using the :doc:`fix bond/create <fix_bond_create>` command. Or if entire new molecules
will be added to the system, e.g. by using the
:doc:`fix deposit <fix_deposit>` or :doc:`fix pour <fix_pour>` commands,
which will have more special 1-2,1-3,1-4 neighbors than any other
molecules defined in the data file. Using this header flag is
deprecated; please use the *extra/special/per/atom* keyword instead.
Using this setting will pre-allocate space in the LAMMPS data
structures for storing these neighbors. See the
:doc:`special_bonds <special_bonds>` and :doc:`molecule <molecule>` doc
pages for more discussion of 1-2,1-3,1-4 neighbors.
bonds/angles/etc will be added to the system, e.g. by using the
:doc:`fix bond/create <fix_bond_create>` command. Or if entire new
molecules will be added to the system, e.g. by using the :doc:`fix
deposit <fix_deposit>` or :doc:`fix pour <fix_pour>` commands, which
will have more special 1-2,1-3,1-4 neighbors than any other molecules
defined in the data file. Using this header flag is deprecated;
please use the *extra/special/per/atom* keyword instead. Using this
setting will pre-allocate space in the LAMMPS data structures for
storing these neighbors. See the :doc:`special_bonds <special_bonds>`
and :doc:`molecule <molecule>` doc pages for more discussion of
1-2,1-3,1-4 neighbors.
.. note::
All of the "extra" settings are only applied in the first data
file read and when no simulation box has yet been created; as soon as
All of the "extra" settings are only applied in the first data file
read and when no simulation box has yet been created; as soon as
the simulation box is created (and read_data implies that), these
settings are *locked* and cannot be changed anymore. Please see the
description of the *add* keyword above for reading multiple data files.
If they appear in later data files, they are ignored.
description of the *add* keyword above for reading multiple data
files. If they appear in later data files, they are ignored.
The "ellipsoids" and "lines" and "triangles" and "bodies" settings are
only used with :doc:`atom_style ellipsoid or line or tri or body <atom_style>` and specify how many of the atoms are
finite-size ellipsoids or lines or triangles or bodies; the remainder
are point particles. See the discussion of ellipsoidflag and the
*Ellipsoids* section below. See the discussion of lineflag and the
*Lines* section below. See the discussion of triangleflag and the
*Triangles* section below. See the discussion of bodyflag and the
*Bodies* section below.
only used with :doc:`atom_style ellipsoid or line or tri or body
<atom_style>` and specify how many of the atoms are finite-size
ellipsoids or lines or triangles or bodies; the remainder are point
particles. See the discussion of ellipsoidflag and the *Ellipsoids*
section below. See the discussion of lineflag and the *Lines* section
below. See the discussion of triangleflag and the *Triangles* section
below. See the discussion of bodyflag and the *Bodies* section below.
.. note::
For :doc:`atom_style template <atom_style>`, the molecular
topology (bonds,angles,etc) is contained in the molecule templates
read-in by the :doc:`molecule <molecule>` command. This means you
cannot set the *bonds*, *angles*, etc header keywords in the data
file, nor can you define *Bonds*, *Angles*, etc sections as discussed
For :doc:`atom_style template <atom_style>`, the molecular topology
(bonds,angles,etc) is contained in the molecule templates read-in
by the :doc:`molecule <molecule>` command. This means you cannot
set the *bonds*, *angles*, etc header keywords in the data file,
nor can you define *Bonds*, *Angles*, etc sections as discussed
below. You can set the *bond types*, *angle types*, etc header
keywords, though it is not necessary. If specified, they must match
the maximum values defined in any of the template molecules.
keywords, though it is not necessary. If specified, they must
match the maximum values defined in any of the template molecules.
----------
@ -680,6 +810,19 @@ appended to it, which indicate which image of a periodic simulation
box the atom is in. These may be important to include for some kinds
of analysis.
.. note::
For orthogonal and restricted and general triclinic simulation
boxes, the atom coordinates (x,y,z) listed in this section should
be inside the corresponding simulation box. For restricted
triclinic boxes that means the parallelepiped defined by the *xlo
xhi*, *ylo yhi*, *zlo zhi*, and *xy xz yz*, keywords. For general
triclinic boxes that means the parallelepiped defined by the 3 edge
vectors and origin specified by the *avec*, *bvec*, *cvec*, and
*abc origin* header keywords. See the discussion in the header
section above about how atom coordinates outside the simulation box
are (or are not) remapped to be inside the box.
.. list-table::
* - angle
@ -690,10 +833,12 @@ of analysis.
- atom-ID atom-type bodyflag mass x y z
* - bond
- atom-ID molecule-ID atom-type x y z
* - bpm/sphere
- atom-ID molecule-ID atom-type diameter density x y z
* - charge
- atom-ID atom-type q x y z
* - dielectric
- atom-ID atom-type q x y z normx normy normz area ed em epsilon curvature
- atom-ID atom-type q x y z mux muy muz area ed em epsilon curvature
* - dipole
- atom-ID atom-type q x y z mux muy muz
* - dpd
@ -720,8 +865,6 @@ of analysis.
- atom-ID atom-type rho esph cv x y z
* - sphere
- atom-ID atom-type diameter density x y z
* - bpm/sphere
- atom-ID molecule-ID atom-type diameter density x y z
* - spin
- atom-ID atom-type x y z spx spy spz sp
* - tdpd
@ -757,24 +900,42 @@ The per-atom values have these meanings and units, listed alphabetically:
* lineflag = 1 for line segment particles, 0 for point or spherical particles
* mass = mass of particle (mass units)
* molecule-ID = integer ID of molecule the atom belongs to
* mux,muy,muz = components of dipole moment of atom (dipole units)
* mux,muy,muz = components of dipole moment of atom (dipole units) (see general triclinic note below)
* q = charge on atom (charge units)
* rho = density (need units) for SPH particles
* sp = magnitude of magnetic spin of atom (Bohr magnetons)
* spx,spy,spz = components of magnetic spin of atom (unit vector)
* spx,spy,spz = components of magnetic spin of atom (unit vector) (see general triclinic note below)
* template-atom = which atom within a template molecule the atom is
* template-index = which molecule within the molecule template the atom is part of
* theta = internal temperature of a DPD particle
* triangleflag = 1 for triangular particles, 0 for point or spherical particles
* volume = volume of Peridynamic particle (distance\^3 units)
* x,y,z = coordinates of atom (distance units)
* x0,y0,z0 = original (strain-free) coordinates of atom (distance units)
* x0,y0,z0 = original (strain-free) coordinates of atom (distance
units) (see general triclinic note below)
The units for these quantities depend on the unit style; see the
:doc:`units <units>` command for details.
For 2d simulations specify z as 0.0, or a value within the *zlo zhi*
setting in the data file header.
For 2d simulations, the atom coordinate z must be specified as 0.0.
If the data file is created by another program, then z values for a 2d
simulation can be within epsilon of 0.0, and LAMMPS will force them to
zero.
.. note::
If the data file defines a general triclinic box, then the
following per-atom values in the list above are per-atom vectors
which imply an orientation: (mux,muy,muz) and (spx,spy,spz). This
means they should be specified consistent with the general
triclinic box and its orientation relative to the standard x,y,z
coordinate axes. For example a dipole moment vector which will be
in the +x direction once LAMMPS converts from a general to
restricted triclinic box, should be specified in the data file in
the direction of the **A** edge vector. Likewise the (x0,y0,z0)
per-atom strain-free coordinates should be inside the general
triclinic simulation box as explained in the note above. See the
:doc:`Howto triclinic <Howto_triclinic>` doc page for more details.
The atom-ID is used to identify the atom throughout the simulation and
in dump files. Normally, it is a unique value from 1 to Natoms for
@ -922,9 +1083,8 @@ that use unwrapped coordinates internally are as follows:
Atom velocities and other atom quantities not defined above are set to
0.0 when the *Atoms* section is read. Velocities can be set later by
a *Velocities* section in the data file or by a
:doc:`velocity <velocity>` or :doc:`set <set>` command in the input
script.
a *Velocities* section in the data file or by a :doc:`velocity
<velocity>` or :doc:`set <set>` command in the input script.
----------
@ -963,8 +1123,9 @@ the "bodies" keyword.
Each body can have a variable number of integer and/or floating-point
values. The number and meaning of the values is defined by the body
style, as described in the :doc:`Howto body <Howto_body>` doc page. The
body style is given as an argument to the :doc:`atom_style body <atom_style>` command.
style, as described in the :doc:`Howto body <Howto_body>` doc page.
The body style is given as an argument to the :doc:`atom_style body
<atom_style>` command.
The Ninteger and Ndouble values determine how many integer and
floating-point values are specified for this particle. Ninteger and
@ -1179,10 +1340,10 @@ and a general discussion of how type labels can be used.
12 1 2 1 1 0 0 0
The *Ellipsoids* section must appear if :doc:`atom_style ellipsoid <atom_style>` is used and any atoms are listed in the
*Atoms* section with an ellipsoidflag = 1. The number of ellipsoids
should be specified in the header section via the "ellipsoids"
keyword.
The *Ellipsoids* section must appear if :doc:`atom_style ellipsoid
<atom_style>` is used and any atoms are listed in the *Atoms* section
with an ellipsoidflag = 1. The number of ellipsoids should be
specified in the header section via the "ellipsoids" keyword.
The 3 shape values specify the 3 diameters or aspect ratios of a
finite-size ellipsoidal particle, when it is oriented along the 3
@ -1200,6 +1361,12 @@ the quaternion that represents its new orientation is given by
LAMMPS normalizes each atom's quaternion in case (a,b,c) is not
specified as a unit vector.
If the data file defines a general triclinic box, then the quaternion
for each ellipsoid should be specified for its orientation relative to
the standard x,y,z coordinate axes. When the system is converted to a
restricted triclinic box, the ellipsoid quaternions will be altered to
reflect the new orientation of the ellipsoid.
The *Ellipsoids* section must appear after the *Atoms* section.
----------
@ -1316,13 +1483,24 @@ is used and any atoms are listed in the *Atoms* section with a
lineflag = 1. The number of lines should be specified in the header
section via the "lines" keyword.
The 2 end points are the end points of the line segment. The ordering
of the 2 points should be such that using a right-hand rule to cross
the line segment with a unit vector in the +z direction, gives an
"outward" normal vector perpendicular to the line segment.
The 2 end points are the end points of the line segment. They should
be values close to the center point of the line segment specified in
the Atoms section of the data file, even if individual end points are
outside the simulation box.
The ordering of the 2 points should be such that using a right-hand
rule to cross the line segment with a unit vector in the +z direction,
gives an "outward" normal vector perpendicular to the line segment.
I.e. normal = (c2-c1) x (0,0,1). This orientation may be important
for defining some interactions.
If the data file defines a general triclinic box, then the x1,y1 and
x2,y2 values for each line segment should be specified for its
orientation relative to the standard x,y,z coordinate axes. When the
system is converted to a restricted triclinic box, the x1,y1,x2,y2
values will be altered to reflect the new orientation of the line
segment.
The *Lines* section must appear after the *Atoms* section.
----------
@ -1444,15 +1622,27 @@ via the :doc:`pair_coeff <pair_coeff>` command in the input script.
12 0.0 0.0 0.0 2.0 0.0 1.0 0.0 2.0 1.0
The *Triangles* section must appear if :doc:`atom_style tri <atom_style>` is used and any atoms are listed in the *Atoms*
section with a triangleflag = 1. The number of lines should be
specified in the header section via the "triangles" keyword.
The *Triangles* section must appear if :doc:`atom_style tri
<atom_style>` is used and any atoms are listed in the *Atoms* section
with a triangleflag = 1. The number of lines should be specified in
the header section via the "triangles" keyword.
The 3 corner points are the corner points of the triangle. The
ordering of the 3 points should be such that using a right-hand rule
to go from point1 to point2 to point3 gives an "outward" normal vector
to the face of the triangle. I.e. normal = (c2-c1) x (c3-c1). This
orientation may be important for defining some interactions.
The 3 corner points are the corner points of the triangle. They
should be values close to the center point of the triangle specified
in the Atoms section of the data file, even if individual corner
points are outside the simulation box.
The ordering of the 3 points should be such that using a right-hand
rule to go from point1 to point2 to point3 gives an "outward" normal
vector to the face of the triangle. I.e. normal = (c2-c1) x (c3-c1).
This orientation may be important for defining some interactions.
If the data file defines a general triclinic box, then the x1,y1,z1
and x2,y2,z2 and x3,y3,z3 values for each triangle should be specified
for its orientation relative to the standard x,y,z coordinate axes.
When the system is converted to a restricted triclinic box, the
x1,y1,z1,x2,y2,z2,x3,y3,z3 values will be altered to reflect the new
orientation of the triangle.
The *Triangles* section must appear after the *Atoms* section.
@ -1493,6 +1683,12 @@ Vx, vy, vz, and ervel are in :doc:`units <units>` of velocity. Lx, ly,
lz are in units of angular momentum (distance-velocity-mass). Wx, Wy,
Wz are in units of angular velocity (radians/time).
If the data file defines a general triclinic box, then each of the 3
vectors (translational velocity, angular momentum, angular velocity)
should be specified for the rotated coordinate axes of the general
triclinic box. See the :doc:`Howto triclinic <Howto_triclinic>` doc
page for more details.
For atom_style hybrid, following the 4 initial values (ID,vx,vy,vz),
specific values for each sub-style must be listed. The order of the
sub-styles is the same as they were listed in the
@ -1513,8 +1709,8 @@ fields:
atom-ID vx vy vz ervel wx wy wz
Translational velocities can also be set by the
:doc:`velocity <velocity>` command in the input script.
Translational velocities can also be (re)set by the :doc:`velocity
<velocity>` command in the input script.
----------

22
doc/src/thermo_modify.rst
View File

@ -11,7 +11,7 @@ Syntax
thermo_modify keyword value ...
* one or more keyword/value pairs may be listed
* keyword = *lost* or *lost/bond* or *warn* or *norm* or *flush* or *line* or *colname* or *format* or *temp* or *press*
* keyword = *lost* or *lost/bond* or *warn* or *norm* or *flush* or *line* or *colname* or *format* or *temp* or *press* or *triclinic/general*
.. parsed-literal::
@ -32,6 +32,8 @@ Syntax
*or* a thermo keyword or reference to compute, fix, property or variable.
*temp* value = compute ID that calculates a temperature
*press* value = compute ID that calculates a pressure
*triclinic/general* arg = *yes* or *no*
Examples
""""""""
@ -240,6 +242,19 @@ command, thermo output uses a default compute for pressure with ID =
keyword, then the new pressure compute specified by the *press*
keyword will be unaffected by the *temp* setting.
The *triclinic/general* keyword can only be used with a value of *yes*
if the simulation box was created as a general triclinic box. See the
:doc:`Howto_triclinic <Howto_triclinic>` doc page for a detailed
explanation of orthogonal, restricted triclinic, and general triclinic
simulation boxes.
If this keyword is *yes*, the output of the simulation box edge
vectors and the pressure tensor components for the system are
affected. These are specified by the *avec,bvec,cvec* and
*pxx,pyy,pzz,pxy,pxz,pyz* keywords of the :doc:`thermo_style
<thermo_style>` command. See the :doc:`thermo_style <thermo_style>`
doc page for details.
Restrictions
""""""""""""
none
@ -253,8 +268,9 @@ Default
"""""""
The option defaults are lost = error, warn = 100, norm = yes for unit
style of *lj*, norm = no for unit style of *real* and *metal*,
flush = no, and temp/press = compute IDs defined by thermo_style.
style of *lj*, norm = no for unit style of *real* and *metal*, flush =
no, temp/press = compute IDs defined by thermo_style, and
triclinic/general = no.
The defaults for the line and format options depend on the thermo style.
For styles "one" and "custom", the line and format defaults are "one",

103
doc/src/thermo_style.rst
View File

@ -25,12 +25,18 @@ Syntax
evdwl, ecoul, epair, ebond, eangle, edihed, eimp,
emol, elong, etail,
enthalpy, ecouple, econserve,
vol, density, lx, ly, lz, xlo, xhi, ylo, yhi, zlo, zhi,
xy, xz, yz, xlat, ylat, zlat,
bonds, angles, dihedrals, impropers,
pxx, pyy, pzz, pxy, pxz, pyz,
fmax, fnorm, nbuild, ndanger,
vol, density,
xlo, xhi, ylo, yhi, zlo, zhi,
xy, xz, yz,
avecx, avecy, avecz,
bvecx, bvecy, bvecz,
cvecx, cvecy, cvecz,
lx, ly, lz,
xlat, ylat, zlat,
cella, cellb, cellc, cellalpha, cellbeta, cellgamma,
pxx, pyy, pzz, pxy, pxz, pyz,
bonds, angles, dihedrals, impropers,
fmax, fnorm, nbuild, ndanger,
c_ID, c_ID[I], c_ID[I][J],
f_ID, f_ID[I], f_ID[I][J],
v_name, v_name[I]
@ -66,18 +72,21 @@ Syntax
econserve = pe + ke + ecouple = etotal + ecouple
vol = volume
density = mass density of system
lx,ly,lz = box lengths in x,y,z
xlo,xhi,ylo,yhi,zlo,zhi = box boundaries
xy,xz,yz = box tilt for triclinic (non-orthogonal) simulation boxes
xy,xz,yz = box tilt for restricted triclinic (non-orthogonal) simulation boxes
avecx,avecy,avecz = components of edge vector A of the simulation box
bvecx,bvecy,bvecz = components of edge vector B of the simulation box
cvecx,cvecy,cvecz = components of edge vector C of the simulation box
lx,ly,lz = box lengths in x,y,z
xlat,ylat,zlat = lattice spacings as calculated by :doc:`lattice <lattice>` command
bonds,angles,dihedrals,impropers = # of these interactions defined
cella,cellb,cellc = periodic cell lattice constants a,b,c
cellalpha, cellbeta, cellgamma = periodic cell angles alpha,beta,gamma
pxx,pyy,pzz,pxy,pxz,pyz = 6 components of pressure tensor
bonds,angles,dihedrals,impropers = # of these interactions defined
fmax = max component of force on any atom in any dimension
fnorm = length of force vector for all atoms
nbuild = # of neighbor list builds
ndanger = # of dangerous neighbor list builds
cella,cellb,cellc = periodic cell lattice constants a,b,c
cellalpha, cellbeta, cellgamma = periodic cell angles alpha,beta,gamma
c_ID = global scalar value calculated by a compute with ID
c_ID[I] = Ith component of global vector calculated by a compute with ID, I can include wildcard (see below)
c_ID[I][J] = I,J component of global array calculated by a compute with ID
@ -102,8 +111,11 @@ Examples
Description
"""""""""""
Set the style and content for printing thermodynamic data to the screen
and log files.
Set the style and content for printing thermodynamic data to the
screen and log files. The units for each column of output
corresponding to the list of keywords is determined by the :doc:`units
<units>` command for the simulation. E.g. energies will be in energy
units, temperature in temperature units, pressure in pressure units.
Style *one* prints a single line of thermodynamic info that is the
equivalent of "thermo_style custom step temp epair emol etotal press".
@ -245,7 +257,7 @@ and *pxx*, *pyy*, etc.
----------
Here is more information on other keywords whose meaning may not be
clear:
clear.
The *step*, *elapsed*, and *elaplong* keywords refer to timestep
count. *Step* is the current timestep, or iteration count when a
@ -319,6 +331,63 @@ thermostatting or barostatting to their coupling reservoirs -- that is,
the NVT, NPH, or NPT ensembles, the *econserve* quantity should remain
constant over time even though *etotal* may change.
In LAMMPS, the simulation box can be defined as orthogonal or
triclinic (non-orthogonal). See the :doc:`Howto_triclinic
<Howto_triclinic>` doc page for a detailed explanation of orthogonal,
restricted triclinic, and general triclinic simulation boxes and how
LAMMPS rotates a general triclinic box to be restricted triclinic
internally.
The *lx*, *ly*, *lz* keywords are the extent of the simulation box in
each dimension. The *xlo*, *xhi*, *ylo*, *yhi*, *zlo*, *zhi* keywords
are the lower and upper bounds of the simulation box in each dimension.
I.e. *lx* = *xhi* - *xlo*). These 9 values are the same for all 3 kinds
of boxes. I.e. for a restricted triclinic box, they are the values as
if the box were not tilted. For a general triclinic box, they are the
values after it is internally rotated to be a restricted triclinic box.
The *xy*, *xz*, *yz* are the current tilt factors for a triclinic box.
They are the same for restricted and general triclinic boxes.
The *avecx*, *avecy*, *avecz*, *bvecx*, *bvecy*, *bvecz*, *cvecx*,
*cvecy*, *cvecz* are the components of the 3 edge vectors of the
current general simulation box. If it is an orthogonal box the
vectors are along the x, y, z coordinate axes. If it is a restricted
triclinic box, the **A** vector is along the x axis, the **B** vector
is in the xy plane with a +y coordinate, and the **C** vector has a +z
coordinate, as explained on the :doc:`Howto_triclinic
<Howto_triclinic>` doc page. If the :doc:`thermo_modify
triclinic/general <thermo_modify>` option is set then they are the
**A**, **B**, **C** vector which define the general triclinic box.
The *cella*, *cellb*, *cellc*, *cellalpha*, *cellbeta*, *cellgamma*
keywords correspond to the usual crystallographic quantities that
define the periodic simulation box of a crystalline system. See the
:doc:`Howto triclinic <Howto_triclinic>` page for a precise definition
of these quantities in terms of the LAMMPS representation of a
restricted triclinic simulation box via *lx*, *ly*, *lz*, *yz*, *xz*,
*xy*\ .
The *pxx,pyy,pzz,pxy,pxz,pyz* keywords are the 6 components of the
symmetric pressure tensor for the system. See the :doc:`compute
pressure <compute_pressure>` command doc page for details of how it is
calculated.
If the :doc:`thermo_modify triclinic/general <thermo_modify>` option
is set then the 6 components will be output as values consistent with
the orientation of the general triclinic box relative to the standard
xyz coordinate axes. If this keyword is not used, the values will be
consistent with the orientation of the restricted triclinic box (which
aligns with the xyz coordinate axes). As explained on the
:doc:`Howto_triclinic <Howto_triclinic>` doc page, even if the
simulation box is created as a general triclinic box, internally
LAMMPS uses a restricted triclinic box.
Note that because the pressure tensor components are computed using
force vectors and atom coordinates, both of which are rotated in the
general versus restricted triclinic representation, the values will
typically be different for the two cases.
The *fmax* and *fnorm* keywords are useful for monitoring the progress
of an :doc:`energy minimization <minimize>`. The *fmax* keyword
calculates the maximum force in any dimension on any atom in the
@ -338,14 +407,6 @@ to reduce the delay factor to ensure no force interactions are missed
by atoms moving beyond the neighbor skin distance before a rebuild
takes place.
The keywords *cella*, *cellb*, *cellc*, *cellalpha*,
*cellbeta*, *cellgamma*, correspond to the usual crystallographic
quantities that define the periodic unit cell of a crystal. See the
:doc:`Howto triclinic <Howto_triclinic>` page for a geometric
description of triclinic periodic cells, including a precise
definition of these quantities in terms of the internal LAMMPS cell
dimensions *lx*, *ly*, *lz*, *yz*, *xz*, *xy*\ .
----------
For output values from a compute or fix or variable, the bracketed

48
doc/src/variable.rst
View File

@ -279,9 +279,9 @@ This means the variable can then be evaluated as many times as desired
and will return those values. There are two ways to cause the next
set of per-atom values from the file to be read: use the
:doc:`next <next>` command or the next() function in an atom-style
variable, as discussed below. Unlike most variable styles
atomfile-style variables are **deleted** during a :doc:`clear <clear>`
command.
variable, as discussed below. Unlike most variable styles, which
remain defined, atomfile-style variables are **deleted** during a
:doc:`clear <clear>` command.
The rules for formatting the file are as follows. Each time a set of
per-atom values is read, a non-blank line is searched for in the file.
@ -289,23 +289,37 @@ The file is read line by line but only up to 254 characters are used.
The rest are ignored. A comment character "#" can be used anywhere
on a line and all text following and the "#" character are ignored;
text starting with the comment character is stripped. Blank lines
are skipped. The first "word" of a non-blank line, delimited by
white-space, is read as the count N of per-atom lines to immediately
follow. N can be the total number of atoms in the system, or only a
subset. The next N lines have the following format
.. parsed-literal::
ID value
where ID is an atom ID and value is the per-atom numeric value that
will be assigned to that atom. IDs can be listed in any order.
are skipped. The first non-blank line is expected to contain a single
integer number as the count *N* of per-atom lines to follow. *N* can
be the total number of atoms in the system or less, indicating that data
for a subset is read. The next N lines must consist of two numbers,
the atom-ID of the atom for which a value is set followed by a floating
point number with the value. The atom-IDs may be listed in any order.
.. note::
Every time a set of per-atom lines is read, the value for all
atoms is first set to 0.0. Thus values for atoms whose ID does not
appear in the set, will remain 0.0.
Every time a set of per-atom lines is read, the value of the atomfile
variable for **all** atoms is first initialized to 0.0. Thus values
for atoms whose ID do not appear in the set in the file will remain
at 0.0.
Below is a small example for the atomfile variable file format:
.. parsed-literal::
# first set
4
# atom-ID value
3 1
4 -4
1 0.5
2 -0.5
# second set
2
2 1.0
4 -1.0
----------

28
doc/src/write_data.rst
View File

@ -19,6 +19,7 @@ Syntax
*nocoeff* = do not write out force field info
*nofix* = do not write out extra sections read by fixes
*nolabelmap* = do not write out type labels
*triclinic/general = write data file in general triclinic format
*types* value = *numeric* or *labels*
*pair* value = *ii* or *ij*
*ii* = write one line of pair coefficient info per atom type
@ -31,6 +32,7 @@ Examples
write_data data.polymer
write_data data.*
write_data data.solid triclinic/general
Description
"""""""""""
@ -85,10 +87,11 @@ using the :doc:`-r command-line switch <Run_options>`.
:doc:`fixes <fix>` are stored. :doc:`Binary restart files <read_restart>`
store more information.
Bond interactions (angle, etc) that have been turned off by the :doc:`fix shake <fix_shake>` or :doc:`delete_bonds <delete_bonds>` command will
be written to a data file as if they are turned on. This means they
will need to be turned off again in a new run after the data file is
read.
Bond interactions (angle, etc) that have been turned off by the
:doc:`fix shake <fix_shake>` or :doc:`delete_bonds <delete_bonds>`
command will be written to a data file as if they are turned on. This
means they will need to be turned off again in a new run after the
data file is read.
Bonds that are broken (e.g. by a bond-breaking potential) are not
written to the data file. Thus these bonds will not exist when the
@ -122,6 +125,23 @@ not written to the data file. By default, they are written if they
exist. A type label must be defined for every numeric type (within a
given type-kind) to be written to the data file.
Use of the *triclinic/general* keyword will output a data file which
specifies a general triclinic simulation box as well as per-atom
quantities consistent with the general triclinic box. The latter means
that per-atom vectors, such as velocities and dipole moments will be
oriented consistent with the 3d rotation implied by the general
triclinic box (relative to the associated restricted triclinic box).
This option can only be requested if the simulation box was initially
defined to be general triclinic. If if was and the
*triclinic/general* keyword is not used, then the data file will
specify a restricted triclinic box, since that is the internal format
LAMMPS uses for both general and restricted triclinic simulations.
See the :doc:`Howto triclinic <Howto_triclinic>` doc page for more
explanation of how general triclinic simulation boxes are supported by
LAMMPS. And see the :doc:`read_data <read_data>` doc page for details
of how the format is altered for general triclinic data files.
The *types* keyword determines how atom types, bond types, angle
types, etc are written into these data file sections: Atoms, Bonds,
Angles, etc. The default is the *numeric* setting, even if type label

21
doc/src/write_restart.rst
View File

@ -55,21 +55,22 @@ alter the number of files written.
Restart files can be read by a :doc:`read_restart <read_restart>`
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 :doc:`-r command-line switch <Run_options>` to convert a restart file to a data file.
another machine. In this case, you can use the :doc:`-r command-line
switch <Run_options>` to convert a restart file to a data file.
.. 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. Details are usually given in the
documentation of the respective command. Also, see the
:doc:`read_restart <read_restart>` command for general information about
what is stored in a restart file.
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. Details are usually
given in the documentation of the respective command. Also, see the
:doc:`read_restart <read_restart>` command for general information
about what is stored in a restart file.
----------