Merge pull request #2829 from akohlmey/package-reorganization2
Package reorganization (step 2)
This commit is contained in:
Axel Kohlmeyer
@ -161,9 +161,15 @@ set(STANDARD_PACKAGES
|
||||
DPD-SMOOTH
|
||||
DRUDE
|
||||
EFF
|
||||
EXTRA-COMPUTE
|
||||
EXTRA-DUMP
|
||||
EXTRA-FIX
|
||||
EXTRA-MOLECULE
|
||||
EXTRA-PAIR
|
||||
FEP
|
||||
GRANULAR
|
||||
H5MD
|
||||
INTERLAYER
|
||||
KIM
|
||||
KSPACE
|
||||
LATBOLTZ
|
||||
@ -190,6 +196,7 @@ set(STANDARD_PACKAGES
|
||||
MPIIO
|
||||
MSCG
|
||||
NETCDF
|
||||
ORIENT
|
||||
PERI
|
||||
PHONON
|
||||
PLUGIN
|
||||
@ -212,7 +219,6 @@ set(STANDARD_PACKAGES
|
||||
SRD
|
||||
TALLY
|
||||
UEF
|
||||
USER-MISC
|
||||
VORONOI
|
||||
VTK
|
||||
YAFF)
|
||||
|
||||
@ -25,11 +25,17 @@ set(ALL_PACKAGES
|
||||
DPD-SMOOTH
|
||||
DRUDE
|
||||
EFF
|
||||
EXTRA-COMPUTE
|
||||
EXTRA-DUMP
|
||||
EXTRA-FIX
|
||||
EXTRA-MOLECULE
|
||||
EXTRA-PAIR
|
||||
FEP
|
||||
GPU
|
||||
GRANULAR
|
||||
H5MD
|
||||
INTEL
|
||||
INTERLAYER
|
||||
KIM
|
||||
KOKKOS
|
||||
KSPACE
|
||||
@ -59,6 +65,7 @@ set(ALL_PACKAGES
|
||||
NETCDF
|
||||
OPENMP
|
||||
OPT
|
||||
ORIENT
|
||||
PERI
|
||||
PHONON
|
||||
PLUGIN
|
||||
@ -81,7 +88,6 @@ set(ALL_PACKAGES
|
||||
SRD
|
||||
TALLY
|
||||
UEF
|
||||
USER-MISC
|
||||
VORONOI
|
||||
VTK
|
||||
YAFF)
|
||||
|
||||
@ -27,11 +27,17 @@ set(ALL_PACKAGES
|
||||
DPD-SMOOTH
|
||||
DRUDE
|
||||
EFF
|
||||
EXTRA-COMPUTE
|
||||
EXTRA-DUMP
|
||||
EXTRA-FIX
|
||||
EXTRA-MOLECULE
|
||||
EXTRA-PAIR
|
||||
FEP
|
||||
GPU
|
||||
GRANULAR
|
||||
H5MD
|
||||
INTEL
|
||||
INTERLAYER
|
||||
KIM
|
||||
KOKKOS
|
||||
KSPACE
|
||||
@ -61,6 +67,7 @@ set(ALL_PACKAGES
|
||||
NETCDF
|
||||
OPENMP
|
||||
OPT
|
||||
ORIENT
|
||||
PERI
|
||||
PHONON
|
||||
PLUGIN
|
||||
@ -83,7 +90,6 @@ set(ALL_PACKAGES
|
||||
SRD
|
||||
TALLY
|
||||
UEF
|
||||
USER-MISC
|
||||
VORONOI
|
||||
VTK
|
||||
YAFF)
|
||||
|
||||
@ -21,10 +21,16 @@ set(WIN_PACKAGES
|
||||
DPD-SMOOTH
|
||||
DRUDE
|
||||
EFF
|
||||
EXTRA-COMPUTE
|
||||
EXTRA-DUMP
|
||||
EXTRA-FIX
|
||||
EXTRA-MOLECULE
|
||||
EXTRA-PAIR
|
||||
FEP
|
||||
GPU
|
||||
GRANULAR
|
||||
INTEL
|
||||
INTERLAYER
|
||||
KSPACE
|
||||
LATTE
|
||||
MACHDYN
|
||||
@ -39,11 +45,13 @@ set(WIN_PACKAGES
|
||||
ML-HDNNP
|
||||
ML-IAP
|
||||
ML-SNAP
|
||||
ML-RANN
|
||||
MOFFF
|
||||
MOLECULE
|
||||
MOLFILE
|
||||
OPENMP
|
||||
OPT
|
||||
ORIENT
|
||||
PERI
|
||||
PHONON
|
||||
POEMS
|
||||
@ -61,7 +69,6 @@ set(WIN_PACKAGES
|
||||
SRD
|
||||
TALLY
|
||||
UEF
|
||||
USER-MISC
|
||||
VORONOI
|
||||
YAFF)
|
||||
|
||||
|
||||
@ -23,8 +23,13 @@ set(ALL_PACKAGES
|
||||
DPD-SMOOTH
|
||||
DRUDE
|
||||
EFF
|
||||
EXTRA-COMPUTE
|
||||
EXTRA-FIX
|
||||
EXTRA-MOLECULE
|
||||
EXTRA-PAIR
|
||||
FEP
|
||||
GRANULAR
|
||||
INTERLAYER
|
||||
KSPACE
|
||||
MACHDYN
|
||||
MANYBODY
|
||||
@ -37,6 +42,7 @@ set(ALL_PACKAGES
|
||||
MOLECULE
|
||||
OPENMP
|
||||
OPT
|
||||
ORIENT
|
||||
PERI
|
||||
PHONON
|
||||
PLUGIN
|
||||
@ -51,8 +57,8 @@ set(ALL_PACKAGES
|
||||
SPH
|
||||
SPIN
|
||||
SRD
|
||||
TALLY
|
||||
UEF
|
||||
USER-MISC
|
||||
VORONOI
|
||||
YAFF)
|
||||
|
||||
|
||||
@ -191,7 +191,7 @@ Bibliography
|
||||
A.\ Calhoun, M. Pavese, G. Voth, Chem Phys Letters, 262, 415 (1996).
|
||||
|
||||
**(Campana)**
|
||||
C.\ Campana and M. H. Muser, *Practical Green's function approach to the simulation of elastic semi-infinite solids*\ , `Phys. Rev. B [74], 075420 (2006) <https://doi.org/10.1103/PhysRevB.74.075420>`_
|
||||
C.\ Campana and M. H. Muser, *Practical Green's function approach to the simulation of elastic semi-infinite solids*, `Phys. Rev. B [74], 075420 (2006) <https://doi.org/10.1103/PhysRevB.74.075420>`_
|
||||
|
||||
**(Cao1)**
|
||||
J.\ Cao and B. Berne, J Chem Phys, 99, 2902 (1993).
|
||||
@ -767,7 +767,7 @@ Bibliography
|
||||
Morris, Fox, Zhu, J Comp Physics, 136, 214-226 (1997).
|
||||
|
||||
**(Moustafa)**
|
||||
Sabry G. Moustafa, Andrew J. Schultz, and David A. Kofke, *Very fast averaging of thermal properties of crystals by molecular simulation*\ , `Phys. Rev. E [92], 043303 (2015) <https://link.aps.org/doi/10.1103/PhysRevE.92.043303>`_
|
||||
Sabry G. Moustafa, Andrew J. Schultz, and David A. Kofke, *Very fast averaging of thermal properties of crystals by molecular simulation*, `Phys. Rev. E [92], 043303 (2015) <https://link.aps.org/doi/10.1103/PhysRevE.92.043303>`_
|
||||
|
||||
**(Muller-Plathe1)**
|
||||
Muller-Plathe, J Chem Phys, 106, 6082 (1997).
|
||||
|
||||
@ -204,9 +204,9 @@ be multiple tests run automatically:
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
Found 74 packages
|
||||
Standard package NEWPACKAGE missing in Packages_standard.rst
|
||||
Standard package NEWPACKAGE missing in Packages_details.rst
|
||||
Found 88 packages
|
||||
Package NEWPACKAGE missing in Packages_list.rst
|
||||
Package NEWPACKAGE missing in Packages_details.rst
|
||||
|
||||
- A test that only standard, printable ASCII text characters are used.
|
||||
This runs the command ``env LC_ALL=C grep -n '[^ -~]' src/*.rst`` and
|
||||
|
||||
@ -2,7 +2,7 @@ Commands by category
|
||||
====================
|
||||
|
||||
This page lists most of the LAMMPS commands, grouped by category. The
|
||||
:doc:`General commands <Commands_all>` doc page lists all general commands
|
||||
:doc:`General commands <Commands_all>` page lists all general commands
|
||||
alphabetically. Style options for entries like fix, compute, pair etc.
|
||||
have their own pages where they are listed alphabetically.
|
||||
|
||||
|
||||
@ -50,6 +50,6 @@ values are not desired, the :doc:`processors <processors>` and
|
||||
tell LAMMPS how to map processors to the simulation box.
|
||||
|
||||
Many input script errors are detected by LAMMPS and an ERROR or
|
||||
WARNING message is printed. The :doc:`Errors <Errors>` doc page gives
|
||||
WARNING message is printed. The :doc:`Errors <Errors>` page gives
|
||||
more information on what errors mean. The documentation for each
|
||||
command lists restrictions on how the command can be used.
|
||||
|
||||
@ -47,7 +47,7 @@ LAMMPS:
|
||||
named "x" followed by an "x" character.
|
||||
|
||||
How the variable is converted to a text string depends on what style
|
||||
of variable it is; see the :doc:`variable <variable>` doc page for
|
||||
of variable it is; see the :doc:`variable <variable>` page for
|
||||
details. It can be a variable that stores multiple text strings, and
|
||||
return one of them. The returned text string can be multiple "words"
|
||||
(space separated) which will then be interpreted as multiple
|
||||
|
||||
@ -17,7 +17,7 @@ currently supports building with :doc:`conventional makefiles
|
||||
differ in how packages are enabled or disabled for inclusion into a
|
||||
LAMMPS binary so they cannot be mixed. The source files for each
|
||||
package are in all-uppercase sub-directories of the ``src`` folder, for
|
||||
example ``src/MOLECULE`` or ``src/USER-MISC``. The ``src/STUBS``
|
||||
example ``src/MOLECULE`` or ``src/EXTRA-MOLECULE``. The ``src/STUBS``
|
||||
sub-directory is not a package but contains a dummy MPI library, that is
|
||||
used when building a serial version of the code. The ``src/MAKE``
|
||||
directory and its sub-directories contain makefiles with settings and
|
||||
|
||||
@ -17,8 +17,9 @@ the steps outlined below:
|
||||
if your issue has already been reported and if it is still open.
|
||||
* Check the `GitHub Pull Requests page <https://github.com/lammps/lammps/pulls>`_
|
||||
to see if there is already a fix for your bug pending.
|
||||
* Check the `mailing list archives <https://www.lammps.org/mail.html>`_
|
||||
to see if the issue has been discussed before.
|
||||
* Check the `mailing list archives <https://www.lammps.org/mail.html>`_ or
|
||||
the `LAMMPS forum <https://www.lammps.org/forum.html>`_ to see if the
|
||||
issue has been discussed before.
|
||||
|
||||
If none of these steps yields any useful information, please file a new
|
||||
bug report on the `GitHub Issue page <https://github.com/lammps/lammps/issues>`_.
|
||||
|
||||
@ -570,10 +570,10 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
|
||||
See the region prism command for details.
|
||||
|
||||
*Can only use -plog with multiple partitions*
|
||||
Self-explanatory. See doc page discussion of command-line switches.
|
||||
Self-explanatory. See page discussion of command-line switches.
|
||||
|
||||
*Can only use -pscreen with multiple partitions*
|
||||
Self-explanatory. See doc page discussion of command-line switches.
|
||||
Self-explanatory. See page discussion of command-line switches.
|
||||
|
||||
*Can only use Kokkos supported regions with Kokkos package*
|
||||
Self-explanatory.
|
||||
@ -1154,7 +1154,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
|
||||
Self-explanatory.
|
||||
|
||||
*Cannot use -reorder after -partition*
|
||||
Self-explanatory. See doc page discussion of command-line switches.
|
||||
Self-explanatory. See page discussion of command-line switches.
|
||||
|
||||
*Cannot use Ewald with 2d simulation*
|
||||
The kspace style ewald cannot be used in 2d simulations. You can use
|
||||
@ -2347,14 +2347,14 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
|
||||
*Compute used in variable between runs is not current*
|
||||
Computes cannot be invoked by a variable in between runs. Thus they
|
||||
must have been evaluated on the last timestep of the previous run in
|
||||
order for their value(s) to be accessed. See the doc page for the
|
||||
order for their value(s) to be accessed. See the page for the
|
||||
variable command for more info.
|
||||
|
||||
*Compute used in variable thermo keyword between runs is not current*
|
||||
Some thermo keywords rely on a compute to calculate their value(s).
|
||||
Computes cannot be invoked by a variable in between runs. Thus they
|
||||
must have been evaluated on the last timestep of the previous run in
|
||||
order for their value(s) to be accessed. See the doc page for the
|
||||
order for their value(s) to be accessed. See the page for the
|
||||
variable command for more info.
|
||||
|
||||
*Compute vcm/chunk does not use chunk/atom compute*
|
||||
@ -3126,7 +3126,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
|
||||
*Energy was not tallied on needed timestep*
|
||||
You are using a thermo keyword that requires potentials to
|
||||
have tallied energy, but they did not on this timestep. See the
|
||||
variable doc page for ideas on how to make this work.
|
||||
variable page for ideas on how to make this work.
|
||||
|
||||
*Epsilon or sigma reference not set by pair style in PPPMDisp*
|
||||
Self-explanatory.
|
||||
@ -4535,10 +4535,10 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
|
||||
particles.
|
||||
|
||||
*Incorrect # of floating-point values in Bodies section of data file*
|
||||
See doc page for body style.
|
||||
See page for body style.
|
||||
|
||||
*Incorrect # of integer values in Bodies section of data file*
|
||||
See doc page for body style.
|
||||
See page for body style.
|
||||
|
||||
*Incorrect %s format in data file*
|
||||
A section of the data file being read by fix property/atom does
|
||||
@ -4573,7 +4573,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
|
||||
The number of fields per line is not what expected.
|
||||
|
||||
*Incorrect bonus data format in data file*
|
||||
See the read_data doc page for a description of how various kinds of
|
||||
See the read_data page for a description of how various kinds of
|
||||
bonus data must be formatted for certain atom styles.
|
||||
|
||||
*Incorrect boundaries with slab Ewald*
|
||||
@ -4641,7 +4641,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
|
||||
Incorrect number of words per line in the potential file.
|
||||
|
||||
*Incorrect integer value in Bodies section of data file*
|
||||
See doc page for body style.
|
||||
See page for body style.
|
||||
|
||||
*Incorrect multiplicity arg for dihedral coefficients*
|
||||
Self-explanatory. Check the input script or data file.
|
||||
@ -5996,7 +5996,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
|
||||
Self-explanatory.
|
||||
|
||||
*Needed bonus data not in data file*
|
||||
Some atom styles require bonus data. See the read_data doc page for
|
||||
Some atom styles require bonus data. See the read_data page for
|
||||
details.
|
||||
|
||||
*Needed molecular topology not in data file*
|
||||
@ -6198,7 +6198,7 @@ keyword to allow for additional bonds to be formed
|
||||
|
||||
*One or more atom IDs is too big*
|
||||
The limit on atom IDs is set by the SMALLBIG, BIGBIG, SMALLSMALL
|
||||
setting in your LAMMPS build. See the :doc:`Build settings <Build_settings>` doc page for more info.
|
||||
setting in your LAMMPS build. See the :doc:`Build settings <Build_settings>` page for more info.
|
||||
|
||||
*One or more atom IDs is zero*
|
||||
Either all atoms IDs must be zero or none of them.
|
||||
@ -6593,7 +6593,7 @@ keyword to allow for additional bonds to be formed
|
||||
|
||||
*Pair style bop requires comm ghost cutoff at least 3x larger than %g*
|
||||
Use the communicate ghost command to set this. See the pair bop
|
||||
doc page for more details.
|
||||
page for more details.
|
||||
|
||||
*Pair style born/coul/long requires atom attribute q*
|
||||
An atom style that defines this attribute must be used.
|
||||
@ -6913,7 +6913,7 @@ keyword to allow for additional bonds to be formed
|
||||
*Per-atom energy was not tallied on needed timestep*
|
||||
You are using a thermo keyword that requires potentials to
|
||||
have tallied energy, but they did not on this timestep. See the
|
||||
variable doc page for ideas on how to make this work.
|
||||
variable page for ideas on how to make this work.
|
||||
|
||||
*Per-atom fix in equal-style variable formula*
|
||||
Equal-style variables cannot use per-atom quantities.
|
||||
@ -6921,7 +6921,7 @@ keyword to allow for additional bonds to be formed
|
||||
*Per-atom virial was not tallied on needed timestep*
|
||||
You are using a thermo keyword that requires potentials to have
|
||||
tallied the virial, but they did not on this timestep. See the
|
||||
variable doc page for ideas on how to make this work.
|
||||
variable page for ideas on how to make this work.
|
||||
|
||||
*Per-processor system is too big*
|
||||
The number of owned atoms plus ghost atoms on a single
|
||||
@ -8408,7 +8408,7 @@ keyword to allow for additional bonds to be formed
|
||||
*Virial was not tallied on needed timestep*
|
||||
You are using a thermo keyword that requires potentials to
|
||||
have tallied the virial, but they did not on this timestep. See the
|
||||
variable doc page for ideas on how to make this work.
|
||||
variable page for ideas on how to make this work.
|
||||
|
||||
*Voro++ error: narea and neigh have a different size*
|
||||
This error is returned by the Voro++ library.
|
||||
|
||||
@ -213,7 +213,7 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
|
||||
in unexpected behavior.
|
||||
|
||||
*Fix bond/swap will ignore defined angles*
|
||||
See the doc page for fix bond/swap for more info on this
|
||||
See the page for fix bond/swap for more info on this
|
||||
restriction.
|
||||
|
||||
*Fix deposit near setting < possible overlap separation %g*
|
||||
|
||||
@ -174,10 +174,10 @@ web site.
|
||||
If you uncomment the :doc:`dump image <dump_image>` line(s) in the input
|
||||
script a series of JPG images will be produced by the run (assuming
|
||||
you built LAMMPS with JPG support; see the
|
||||
:doc:`Build_settings <Build_settings>` doc page for details). These can
|
||||
:doc:`Build_settings <Build_settings>` page for details). These can
|
||||
be viewed individually or turned into a movie or animated by tools
|
||||
like ImageMagick or QuickTime or various Windows-based tools. See the
|
||||
:doc:`dump image <dump_image>` doc page for more details. E.g. this
|
||||
:doc:`dump image <dump_image>` page for more details. E.g. this
|
||||
Imagemagick command would create a GIF file suitable for viewing in a
|
||||
browser.
|
||||
|
||||
@ -207,14 +207,12 @@ Uppercase directories
|
||||
+------------+--------------------------------------------------------------------------------------------------+
|
||||
| MC | using LAMMPS in a Monte Carlo mode to relax the energy of a system |
|
||||
+------------+--------------------------------------------------------------------------------------------------+
|
||||
| PACKAGES | examples for specific packages and contributed commands in USER-MISC |
|
||||
| PACKAGES | examples for specific packages and contributed commands |
|
||||
+------------+--------------------------------------------------------------------------------------------------+
|
||||
| SPIN | examples for features of the SPIN package |
|
||||
+------------+--------------------------------------------------------------------------------------------------+
|
||||
| UNITS | examples that run the same simulation in lj, real, metal units |
|
||||
+------------+--------------------------------------------------------------------------------------------------+
|
||||
| USER-MISC | examples for commands in the USER-MISC packages |
|
||||
+------------+--------------------------------------------------------------------------------------------------+
|
||||
| VISCOSITY | compute viscosity via several methods |
|
||||
+------------+--------------------------------------------------------------------------------------------------+
|
||||
|
||||
@ -228,7 +226,4 @@ of the sub-directories have their own README files which give further
|
||||
instructions. See the :doc:`Packages_details <Packages_details>` doc
|
||||
page for more info on specific packages.
|
||||
|
||||
Similarly the USER-MISC directory has sub-directories for examples
|
||||
corresponding to individual commands or styles in the USER-MISC package.
|
||||
|
||||
.. _openkim: https://openkim.org
|
||||
|
||||
@ -50,7 +50,7 @@ a temperature or pressure compute to a barostatting fix.
|
||||
|
||||
Thermodynamic output, which can be setup via the
|
||||
:doc:`thermo_style <thermo_style>` command, often includes pressure
|
||||
values. As explained on the doc page for the
|
||||
values. As explained on the page for the
|
||||
:doc:`thermo_style <thermo_style>` command, the default pressure is
|
||||
setup by the thermo command itself. It is NOT the pressure associated
|
||||
with any barostatting fix you have defined or with any compute you
|
||||
|
||||
@ -49,7 +49,7 @@ command's documentation for the formula it computes.
|
||||
COMPASS is a general force field for atomistic simulation of common
|
||||
organic molecules, inorganic small molecules, and polymers which was
|
||||
developed using ab initio and empirical parameterization techniques.
|
||||
See the :doc:`Tools <Tools>` doc page for the msi2lmp tool for creating
|
||||
See the :doc:`Tools <Tools>` page for the msi2lmp tool for creating
|
||||
LAMMPS template input and data files from BIOVIA's Materials Studio
|
||||
files. Please note that the msi2lmp tool is very old and largely
|
||||
unmaintained, so it does not support all features of Materials Studio
|
||||
|
||||
@ -10,7 +10,7 @@ deformable objects, etc. Note that other kinds of finite-size
|
||||
spherical and aspherical particles are also supported by LAMMPS, such
|
||||
as spheres, ellipsoids, line segments, and triangles, but they are
|
||||
simpler entities than body particles. See the :doc:`Howto spherical
|
||||
<Howto_spherical>` doc page for a general overview of all these
|
||||
<Howto_spherical>` page for a general overview of all these
|
||||
particle types.
|
||||
|
||||
Body particles are used via the :doc:`atom_style body <atom_style>`
|
||||
@ -170,14 +170,14 @@ with this body style to compute body/body and body/non-body interactions.
|
||||
The *rounded/polygon* body style represents body particles as a 2d
|
||||
polygon with a variable number of N vertices. This style can only be
|
||||
used for 2d models; see the :doc:`boundary <boundary>` command. See the
|
||||
"pair_style body/rounded/polygon" doc page for a diagram of two
|
||||
"pair_style body/rounded/polygon" page for a diagram of two
|
||||
squares with rounded circles at the vertices. Special cases for N = 1
|
||||
(circle) and N = 2 (rod with rounded ends) can also be specified.
|
||||
|
||||
One use of this body style is for 2d discrete element models, as
|
||||
described in :ref:`Fraige <body-Fraige>`.
|
||||
|
||||
Similar to body style *nparticle*\ , the atom_style body command for
|
||||
Similar to body style *nparticle*, the atom_style body command for
|
||||
this body style takes two additional arguments:
|
||||
|
||||
.. parsed-literal::
|
||||
@ -284,7 +284,7 @@ The *rounded/polyhedron* body style represents body particles as a 3d
|
||||
polyhedron with a variable number of N vertices, E edges and F faces.
|
||||
This style can only be used for 3d models; see the
|
||||
:doc:`boundary <boundary>` command. See the "pair_style
|
||||
body/rounded/polygon" doc page for a diagram of a two 2d squares with
|
||||
body/rounded/polygon" page for a diagram of a two 2d squares with
|
||||
rounded circles at the vertices. A 3d cube with rounded spheres at
|
||||
the 8 vertices and 12 rounded edges would be similar. Special cases
|
||||
for N = 1 (sphere) and N = 2 (rod with rounded ends) can also be
|
||||
@ -293,7 +293,7 @@ specified.
|
||||
This body style is for 3d discrete element models, as described in
|
||||
:ref:`Wang <body-Wang>`.
|
||||
|
||||
Similar to body style *rounded/polygon*\ , the atom_style body command
|
||||
Similar to body style *rounded/polygon*, the atom_style body command
|
||||
for this body style takes two additional arguments:
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
@ -51,7 +51,7 @@ scales the floating point value to spread it across multiple integers.
|
||||
Spatial bins can be of various kinds, e.g. 1d bins = slabs, 2d bins =
|
||||
pencils, 3d bins = boxes, spherical bins, cylindrical bins.
|
||||
|
||||
This compute also calculates the number of chunks *Nchunk*\ , which is
|
||||
This compute also calculates the number of chunks *Nchunk*, which is
|
||||
used by other commands to tally per-chunk data. *Nchunk* can be a
|
||||
static value or change over time (e.g. the number of clusters). The
|
||||
chunk ID for an individual atom can also be static (e.g. a molecule
|
||||
|
||||
@ -119,7 +119,7 @@ server code. Another code could be substituted for either.
|
||||
|
||||
The examples below show launching both codes from the same window (or
|
||||
batch script), using the "&" character to launch the first code in the
|
||||
background. For all modes except *mpi/one*\ , you could also launch the
|
||||
background. For all modes except *mpi/one*, you could also launch the
|
||||
codes in separate windows on your desktop machine. It does not
|
||||
matter whether you launch the client or server first.
|
||||
|
||||
@ -132,7 +132,7 @@ mpirun, even if one or both of them runs on a single processor. This
|
||||
is so that MPI can figure out how to connect both MPI processes
|
||||
together to exchange MPI messages between them.
|
||||
|
||||
For message exchange in *file*\ , *zmq*\ , or *mpi/two* modes:
|
||||
For message exchange in *file*, *zmq*, or *mpi/two* modes:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
|
||||
@ -362,7 +362,7 @@ have to be enabled to be included into a LAMMPS executable. Packages
|
||||
are enabled through setting variables of the kind ``PKG_<NAME>`` to
|
||||
``on`` and disabled by setting them to ``off`` (or using ``yes``,
|
||||
``no``, ``1``, ``0`` correspondingly). ``<NAME>`` has to be replaced by
|
||||
the name of the package, e.g. ``MOLECULE`` or ``USER-MISC``.
|
||||
the name of the package, e.g. ``MOLECULE`` or ``EXTRA-PAIR``.
|
||||
|
||||
|
||||
Using presets
|
||||
|
||||
@ -5,7 +5,7 @@ The adiabatic core-shell model by :ref:`Mitchell and Fincham <MitchellFincham>`
|
||||
to a system. In order to mimic the electron shell of an ion, a
|
||||
satellite particle is attached to it. This way the ions are split into
|
||||
a core and a shell where the latter is meant to react to the
|
||||
electrostatic environment inducing polarizability. See the :doc:`Howto polarizable <Howto_polarizable>` doc page for a discussion of all
|
||||
electrostatic environment inducing polarizability. See the :doc:`Howto polarizable <Howto_polarizable>` page for a discussion of all
|
||||
the polarizable models available in LAMMPS.
|
||||
|
||||
Technically, shells are attached to the cores by a spring force f =
|
||||
@ -78,7 +78,7 @@ satellite particle if desired.
|
||||
Since the core/shell model permits distances of r = 0.0 between the
|
||||
core and shell, a pair style with a "cs" suffix needs to be used to
|
||||
implement a valid long-range Coulombic correction. Several such pair
|
||||
styles are provided in the CORESHELL package. See :doc:`this doc page <pair_cs>` for details. All of the core/shell enabled pair
|
||||
styles are provided in the CORESHELL package. See :doc:`this page <pair_cs>` for details. All of the core/shell enabled pair
|
||||
styles require the use of a long-range Coulombic solver, as specified
|
||||
by the :doc:`kspace_style <kspace_style>` command. Either the PPPM or
|
||||
Ewald solvers can be used.
|
||||
|
||||
@ -42,7 +42,7 @@ context of your application.
|
||||
stand-alone code could communicate with LAMMPS through files that the
|
||||
command writes and reads.
|
||||
|
||||
See the :doc:`Modify command <Modify_command>` doc page for info on how
|
||||
See the :doc:`Modify command <Modify_command>` page for info on how
|
||||
to add a new command to LAMMPS.
|
||||
|
||||
.. spacer
|
||||
|
||||
@ -91,7 +91,7 @@ DRUDE package) to convert a non-polarizable data file (here
|
||||
|
||||
This will automatically insert the new atoms and bonds.
|
||||
The masses and charges of DCs and DPs are computed
|
||||
from *phenol.dff*\ , as well as the DC-DP bond constants. The file
|
||||
from *phenol.dff*, as well as the DC-DP bond constants. The file
|
||||
*phenol.dff* contains the polarizabilities of the atom types
|
||||
and the mass of the Drude particles, for instance:
|
||||
|
||||
@ -106,7 +106,7 @@ and the mass of the Drude particles, for instance:
|
||||
|
||||
The hydrogen atoms are absent from this file, so they will be treated
|
||||
as non-polarizable atoms. In the non-polarizable data file
|
||||
*data.102494.lmp*\ , atom names corresponding to the atom type numbers
|
||||
*data.102494.lmp*, atom names corresponding to the atom type numbers
|
||||
have to be specified as comments at the end of lines of the *Masses*
|
||||
section. You probably need to edit it to add these names. It should
|
||||
look like
|
||||
@ -125,7 +125,7 @@ look like
|
||||
|
||||
**Basic input file**
|
||||
|
||||
The atom style should be set to (or derive from) *full*\ , so that you
|
||||
The atom style should be set to (or derive from) *full*, so that you
|
||||
can define atomic charges and molecular bonds, angles, dihedrals...
|
||||
|
||||
The *polarizer* tool also outputs certain lines related to the input
|
||||
@ -143,7 +143,7 @@ and N for non-polarizable atoms. Here the atom types 1 to 3 (C and O
|
||||
atoms) are DC, atom types 4 and 5 (H atoms) are non-polarizable and
|
||||
the atom types 6 to 8 are the newly created DPs.
|
||||
|
||||
By recognizing the fix *drude*\ , LAMMPS will find and store matching
|
||||
By recognizing the fix *drude*, LAMMPS will find and store matching
|
||||
DC-DP pairs and will treat DP as equivalent to their DC in the
|
||||
*special bonds* relations. It may be necessary to extend the space
|
||||
for storing such special relations. In this case extra space should
|
||||
@ -340,11 +340,11 @@ For the *thole* pair style the coefficients are
|
||||
The special neighbors have charge-charge and charge-dipole
|
||||
interactions screened by the *coul* factors of the *special_bonds*
|
||||
command (0.0, 0.0, and 0.5 in the example above). Without using the
|
||||
pair_style *thole*\ , dipole-dipole interactions are screened by the
|
||||
same factor. By using the pair_style *thole*\ , dipole-dipole
|
||||
pair_style *thole*, dipole-dipole interactions are screened by the
|
||||
same factor. By using the pair_style *thole*, dipole-dipole
|
||||
interactions are screened by Thole's function, whatever their special
|
||||
relationship (except within each DC-DP pair of course). Consider for
|
||||
example 1-2 neighbors: using the pair_style *thole*\ , their dipoles
|
||||
example 1-2 neighbors: using the pair_style *thole*, their dipoles
|
||||
will see each other (despite the *coul* factor being 0.) and the
|
||||
interactions between these dipoles will be damped by Thole's function.
|
||||
|
||||
@ -384,7 +384,7 @@ For our phenol example, the groups would be defined as
|
||||
group CORES type 1 2 3 # DCs
|
||||
group DRUDES type 6 7 8 # DPs
|
||||
|
||||
Note that with the fixes *drude/transform*\ , it is not required to
|
||||
Note that with the fixes *drude/transform*, it is not required to
|
||||
specify *comm_modify vel yes* because the fixes do it anyway (several
|
||||
times and for the forces also).
|
||||
|
||||
|
||||
@ -140,8 +140,8 @@ After everything is done, add the files to the branch and commit them:
|
||||
flag) will automatically include **all** modified **and** new files
|
||||
and that is rarely the behavior you want. It can easily lead to
|
||||
accidentally adding unrelated and unwanted changes into the
|
||||
repository. Instead it is preferable to explicitly use *git add*\ ,
|
||||
*git rm*\ , *git mv* for adding, removing, renaming individual files,
|
||||
repository. Instead it is preferable to explicitly use *git add*,
|
||||
*git rm*, *git mv* for adding, removing, renaming individual files,
|
||||
respectively, and then *git commit* to finalize the commit.
|
||||
Carefully check all pending changes with *git status* before
|
||||
committing them. If you find doing this on the command line too
|
||||
|
||||
@ -4,7 +4,7 @@ Calculate thermal conductivity
|
||||
The thermal conductivity kappa of a material can be measured in at
|
||||
least 4 ways using various options in LAMMPS. See the examples/KAPPA
|
||||
directory for scripts that implement the 4 methods discussed here for
|
||||
a simple Lennard-Jones fluid model. Also, see the :doc:`Howto viscosity <Howto_viscosity>` doc page for an analogous discussion
|
||||
a simple Lennard-Jones fluid model. Also, see the :doc:`Howto viscosity <Howto_viscosity>` page for an analogous discussion
|
||||
for viscosity.
|
||||
|
||||
The thermal conductivity tensor kappa is a measure of the propensity
|
||||
@ -58,7 +58,7 @@ between hot and cold regions of the simulation box.
|
||||
The :doc:`compute heat/flux <compute_heat_flux>` command can calculate
|
||||
the needed heat flux and describes how to implement the Green_Kubo
|
||||
formalism using additional LAMMPS commands, such as the :doc:`fix ave/correlate <fix_ave_correlate>` command to calculate the needed
|
||||
auto-correlation. See the doc page for the :doc:`compute heat/flux <compute_heat_flux>` command for an example input script
|
||||
auto-correlation. See the page for the :doc:`compute heat/flux <compute_heat_flux>` command for an example input script
|
||||
that calculates the thermal conductivity of solid Ar via the GK
|
||||
formalism.
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@ Manifolds (surfaces)
|
||||
|
||||
**Overview:**
|
||||
|
||||
This doc page is not about a LAMMPS input script command, but about
|
||||
This page is not about a LAMMPS input script command, but about
|
||||
manifolds, which are generalized surfaces, as defined and used by the
|
||||
MANIFOLD package, to track particle motion on the manifolds. See
|
||||
the src/MANIFOLD/README file for more details about the package
|
||||
|
||||
@ -3,7 +3,7 @@ Using LAMMPS with the MDI library for code coupling
|
||||
|
||||
.. note::
|
||||
|
||||
This Howto doc page will eventually replace the
|
||||
This Howto page will eventually replace the
|
||||
:doc:`Howto client/server <Howto_client_server>` doc page.
|
||||
|
||||
Client/server coupling of two codes is where one code is the "client"
|
||||
@ -120,7 +120,7 @@ input script will continue. After finishing execution of the input
|
||||
script, the instance of LAMMPS will be destroyed.
|
||||
|
||||
LAMMPS supports the full set of MD-appropriate engine commands defined
|
||||
by the MDI library. See the :doc:`mdi/engine <mdi_engine>` doc page for
|
||||
by the MDI library. See the :doc:`mdi/engine <mdi_engine>` page for
|
||||
a list of these.
|
||||
|
||||
If those commands are not sufficient for a user-developed driver to use
|
||||
|
||||
@ -268,7 +268,7 @@ Computes that generate values to output
|
||||
Every :doc:`compute <compute>` in LAMMPS produces either global or
|
||||
per-atom or local values. The values can be scalars or vectors or
|
||||
arrays of data. These values can be output using the other commands
|
||||
described in this section. The doc page for each compute command
|
||||
described in this section. The page for each compute command
|
||||
describes what it produces. Computes that produce per-atom or local
|
||||
values have the word "atom" or "local" in their style name. Computes
|
||||
without the word "atom" or "local" produce global values.
|
||||
@ -281,7 +281,7 @@ Fixes that generate values to output
|
||||
Some :doc:`fixes <fix>` in LAMMPS produces either global or per-atom or
|
||||
local values which can be accessed by other commands. The values can
|
||||
be scalars or vectors or arrays of data. These values can be output
|
||||
using the other commands described in this section. The doc page for
|
||||
using the other commands described in this section. The page for
|
||||
each fix command tells whether it produces any output quantities and
|
||||
describes them.
|
||||
|
||||
|
||||
@ -8,34 +8,33 @@ periodically.
|
||||
|
||||
These are the relevant commands:
|
||||
|
||||
* :doc:`neb <neb>` for nudged elastic band calculations
|
||||
* :doc:`hyper <hyper>` for bond boost hyperdynamics (HD)
|
||||
* :doc:`neb <neb>` for nudged elastic band calculations (NEB)
|
||||
* :doc:`neb_spin <neb_spin>` for magnetic nudged elastic band calculations
|
||||
* :doc:`prd <prd>` for parallel replica dynamics
|
||||
* :doc:`tad <tad>` for temperature accelerated dynamics
|
||||
* :doc:`temper <temper>` for parallel tempering
|
||||
* :doc:`prd <prd>` for parallel replica dynamics (PRD)
|
||||
* :doc:`tad <tad>` for temperature accelerated dynamics (TAD)
|
||||
* :doc:`temper <temper>` for parallel tempering with fixed volume
|
||||
* :doc:`temper/npt <temper_npt>` for parallel tempering extended for NPT
|
||||
* :doc:`temper/grem <temper_grem>` for parallel tempering with generalized replica exchange (gREM)
|
||||
* :doc:`fix pimd <fix_pimd>` for path-integral molecular dynamics (PIMD)
|
||||
|
||||
NEB is a method for finding transition states and barrier energies.
|
||||
PRD and TAD are methods for performing accelerated dynamics to find
|
||||
and perform infrequent events. Parallel tempering or replica exchange
|
||||
runs different replicas at a series of temperature to facilitate
|
||||
rare-event sampling.
|
||||
NEB is a method for finding transition states and barrier potential energies.
|
||||
HD, PRD, and TAD are methods for performing accelerated dynamics to find and
|
||||
perform infrequent events. Parallel tempering or replica exchange runs
|
||||
different replicas at a series of temperature to facilitate rare-event
|
||||
sampling. PIMD runs different replicas whose individual particles in different
|
||||
replicas are coupled together by springs to model a system of ring-polymers which
|
||||
can represent the quantum nature of atom cores.
|
||||
|
||||
These commands can only be used if LAMMPS was built with the REPLICA
|
||||
package. See the :doc:`Build package <Build_package>` doc page for more
|
||||
info.
|
||||
|
||||
PIMD runs different replicas whose individual particles are coupled
|
||||
together by springs to model a system or ring-polymers.
|
||||
|
||||
This commands can only be used if LAMMPS was built with the USER-MISC
|
||||
package. See the :doc:`Build package <Build_package>` doc page for more
|
||||
package. See the :doc:`Build package <Build_package>` page for more
|
||||
info.
|
||||
|
||||
In all these cases, you must run with one or more processors per
|
||||
replica. The processors assigned to each replica are determined at
|
||||
run-time by using the :doc:`-partition command-line switch <Run_options>` to launch LAMMPS on multiple partitions,
|
||||
which in this context are the same as replicas. E.g. these commands:
|
||||
run-time by using the :doc:`-partition command-line switch
|
||||
<Run_options>` to launch LAMMPS on multiple partitions, which in this
|
||||
context are the same as replicas. E.g. these commands:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -46,9 +45,11 @@ would each run 8 replicas, on either 16 or 8 processors. Note the use
|
||||
of the :doc:`-in command-line switch <Run_options>` to specify the input
|
||||
script which is required when running in multi-replica mode.
|
||||
|
||||
Also note that with MPI installed on a machine (e.g. your desktop),
|
||||
you can run on more (virtual) processors than you have physical
|
||||
processors. Thus the above commands could be run on a
|
||||
single-processor (or few-processor) desktop so that you can run
|
||||
a multi-replica simulation on more replicas than you have
|
||||
physical processors.
|
||||
Also note that with MPI installed on a machine (e.g. your desktop), you
|
||||
can run on more (virtual) processors than you have physical processors.
|
||||
Thus the above commands could be run on a single-processor (or
|
||||
few-processor) desktop so that you can run a multi-replica simulation on
|
||||
more replicas than you have physical processors. This is useful for
|
||||
testing and debugging, since with most modern processors and MPI
|
||||
libraries the efficiency of a calculation can severely diminish when
|
||||
oversubscribing processors.
|
||||
|
||||
@ -28,7 +28,7 @@ can be invoked via the *dpd/tstat* pair style:
|
||||
:doc:`Fix nvt <fix_nh>` only thermostats the translational velocity of
|
||||
particles. :doc:`Fix nvt/sllod <fix_nvt_sllod>` also does this, except
|
||||
that it subtracts out a velocity bias due to a deforming box and
|
||||
integrates the SLLOD equations of motion. See the :doc:`Howto nemd <Howto_nemd>` doc page for further details. :doc:`Fix nvt/sphere <fix_nvt_sphere>` and :doc:`fix nvt/asphere <fix_nvt_asphere>` thermostat not only translation
|
||||
integrates the SLLOD equations of motion. See the :doc:`Howto nemd <Howto_nemd>` page for further details. :doc:`Fix nvt/sphere <fix_nvt_sphere>` and :doc:`fix nvt/asphere <fix_nvt_asphere>` thermostat not only translation
|
||||
velocities but also rotational velocities for spherical and aspherical
|
||||
particles.
|
||||
|
||||
@ -88,7 +88,7 @@ Below is a list of some custom temperature computes that can be used like that:
|
||||
|
||||
Thermodynamic output, which can be setup via the
|
||||
:doc:`thermo_style <thermo_style>` command, often includes temperature
|
||||
values. As explained on the doc page for the
|
||||
values. As explained on the page for the
|
||||
:doc:`thermo_style <thermo_style>` command, the default temperature is
|
||||
setup by the thermo command itself. It is NOT the temperature
|
||||
associated with any thermostatting fix you have defined or with any
|
||||
|
||||
@ -23,21 +23,21 @@ origin given by **a** = (xhi-xlo,0,0); **b** = (xy,yhi-ylo,0); **c** =
|
||||
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
|
||||
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
|
||||
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.
|
||||
|
||||
For example, assume that the 3 vectors **A**\ ,\ **B**\ ,\ **C** are the edge
|
||||
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:
|
||||
**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:
|
||||
|
||||
.. math::
|
||||
|
||||
@ -57,9 +57,9 @@ rotation of **A**\ , **B**\ , and **C** and can be computed as follows:
|
||||
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.
|
||||
**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
|
||||
**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.
|
||||
@ -95,7 +95,7 @@ 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
|
||||
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
|
||||
@ -135,7 +135,7 @@ 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>` doc page for further details.
|
||||
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
|
||||
@ -160,10 +160,10 @@ 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`,
|
||||
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
|
||||
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:
|
||||
@ -188,10 +188,10 @@ The inverse relationship can be written as follows:
|
||||
{\rm yz} = & \frac{b*c \cos{\alpha} - {\rm xy}*{\rm xz}}{\rm ly} \\
|
||||
{\rm lz}^2 = & c^2 - {\rm xz}^2 - {\rm yz}^2 \\
|
||||
|
||||
The values of *a*\ , *b*\ , *c* , :math:`\alpha` , :math:`\beta`, and
|
||||
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*\ ,
|
||||
*cella*, *cellb*, *cellc*, *cellalpha*, *cellbeta*, *cellgamma*,
|
||||
respectively.
|
||||
|
||||
As discussed on the :doc:`dump <dump>` command doc page, when the BOX
|
||||
|
||||
@ -42,7 +42,7 @@ command, which determines grad(Vstream) in the equation above.
|
||||
E.g. the derivative in the y-direction of the Vx component of fluid
|
||||
motion or grad(Vstream) = dVx/dy. The Pxy off-diagonal component of
|
||||
the pressure or stress tensor, as calculated by the :doc:`compute pressure <compute_pressure>` command, can also be monitored, which
|
||||
is the J term in the equation above. See the :doc:`Howto nemd <Howto_nemd>` doc page for details on NEMD simulations.
|
||||
is the J term in the equation above. See the :doc:`Howto nemd <Howto_nemd>` page for details on NEMD simulations.
|
||||
|
||||
The third method is to perform a reverse non-equilibrium MD simulation
|
||||
using the :doc:`fix viscosity <fix_viscosity>` command which implements
|
||||
|
||||
@ -13,7 +13,7 @@ by several popular visualization tools. The :doc:`dump image <dump_image>` and :
|
||||
output internally rendered images and convert a sequence of them to a
|
||||
movie during the MD run. Several programs included with LAMMPS as
|
||||
auxiliary tools can convert between LAMMPS format files and other
|
||||
formats. See the :doc:`Tools <Tools>` doc page for details.
|
||||
formats. See the :doc:`Tools <Tools>` page for details.
|
||||
|
||||
A Python-based toolkit distributed by our group can read native LAMMPS
|
||||
dump files, including custom dump files with additional columns of
|
||||
|
||||
@ -53,7 +53,7 @@ granular particles; all the other commands create smooth walls.
|
||||
* :doc:`fix wall/region <fix_wall_region>` - use region surface as wall
|
||||
* :doc:`fix wall/gran <fix_wall_gran>` - flat or curved walls with :doc:`pair_style granular <pair_gran>` potential
|
||||
|
||||
The *lj93*\ , *lj126*\ , *colloid*\ , *harmonic*\ , and *morse* styles all
|
||||
The *lj93*, *lj126*, *colloid*, *harmonic*, and *morse* styles all
|
||||
allow the flat walls to move with a constant velocity, or oscillate in
|
||||
time. The :doc:`fix wall/region <fix_wall_region>` command offers the
|
||||
most generality, since the region surface is treated as a wall, and
|
||||
|
||||
@ -32,7 +32,7 @@ Here are suggestions on how to perform these tasks:
|
||||
are simple programs that will build simple molecular systems, such as
|
||||
linear bead-spring polymer chains. The moltemplate program is a true
|
||||
molecular builder that will generate complex molecular models. See
|
||||
the :doc:`Tools <Tools>` doc page for details on tools packaged with
|
||||
the :doc:`Tools <Tools>` page for details on tools packaged with
|
||||
LAMMPS. The `Pre/post processing page <http:/www.lammps.org/prepost.html>`_ of the LAMMPS website
|
||||
describes a variety of third party tools for this task. Furthermore,
|
||||
some LAMMPS internal commands allow to reconstruct, or selectively add
|
||||
@ -49,7 +49,7 @@ Here are suggestions on how to perform these tasks:
|
||||
* **Simulation analysis:** If you want to perform analysis on-the-fly as
|
||||
your simulation runs, see the :doc:`compute <compute>` and
|
||||
:doc:`fix <fix>` doc pages, which list commands that can be used in a
|
||||
LAMMPS input script. Also see the :doc:`Modify <Modify>` doc page for
|
||||
LAMMPS input script. Also see the :doc:`Modify <Modify>` page for
|
||||
info on how to add your own analysis code or algorithms to LAMMPS.
|
||||
For post-processing, LAMMPS output such as :doc:`dump file snapshots <dump>` can be converted into formats used by other MD or
|
||||
post-processing codes. To some degree, that conversion can be done
|
||||
@ -61,7 +61,7 @@ Here are suggestions on how to perform these tasks:
|
||||
LAMMPS will do these conversions. Scripts provided in the
|
||||
tools/python directory can extract and massage data in dump files to
|
||||
make it easier to import into other programs. See the
|
||||
:doc:`Tools <Tools>` doc page for details on these various options.
|
||||
:doc:`Tools <Tools>` page for details on these various options.
|
||||
* **Visualization:** LAMMPS can produce NETPBM, JPG or PNG snapshot images
|
||||
on-the-fly via its :doc:`dump image <dump_image>` command and pass
|
||||
them to an external program, `FFmpeg <https://www.ffmpeg.org>`_ to generate
|
||||
@ -71,7 +71,7 @@ Here are suggestions on how to perform these tasks:
|
||||
LAMMPS website for
|
||||
visualization packages that can process LAMMPS output data.
|
||||
* **Plotting:** See the next bullet about Pizza.py as well as the
|
||||
:doc:`Python <Python_head>` doc page for examples of plotting LAMMPS
|
||||
:doc:`Python <Python_head>` page for examples of plotting LAMMPS
|
||||
output. Scripts provided with the *python* tool in the tools
|
||||
directory will extract and massage data in log and dump files to make
|
||||
it easier to analyze and plot. See the :doc:`Tools <Tools>` doc page
|
||||
|
||||
@ -25,7 +25,7 @@ the website for details. All versions can be downloaded from the
|
||||
|
||||
LAMMPS is designed to be easy to modify or extend with new
|
||||
capabilities, such as new force fields, atom types, boundary
|
||||
conditions, or diagnostics. See the :doc:`Modify <Modify>` doc page for
|
||||
conditions, or diagnostics. See the :doc:`Modify <Modify>` page for
|
||||
more details.
|
||||
|
||||
In the most general sense, LAMMPS integrates Newton's equations of
|
||||
|
||||
@ -20,7 +20,8 @@ available online are listed below.
|
||||
* `Glossary of terms relevant to LAMMPS <https://www.lammps.org/glossary.html>`_
|
||||
* `LAMMPS highlights with images <https://www.lammps.org/pictures.html>`_
|
||||
* `LAMMPS highlights with movies <https://www.lammps.org/movies.html>`_
|
||||
* `Mail list <https://www.lammps.org/mail.html>`_
|
||||
* `Mailing list <https://www.lammps.org/mail.html>`_
|
||||
* `LAMMPS forum <https://www.lammps.org/forum.html>`_
|
||||
* `Workshops <https://www.lammps.org/workshops.html>`_
|
||||
* `Tutorials <https://www.lammps.org/tutorials.html>`_
|
||||
|
||||
|
||||
@ -6,7 +6,7 @@ Body particles can represent complex entities, such as surface meshes
|
||||
of discrete points, collections of sub-particles, deformable objects,
|
||||
etc.
|
||||
|
||||
See the :doc:`Howto body <Howto_body>` doc page for an overview of using
|
||||
See the :doc:`Howto body <Howto_body>` page for an overview of using
|
||||
body particles and the various body styles LAMMPS supports. New
|
||||
styles can be created to add new kinds of body particles to LAMMPS.
|
||||
|
||||
|
||||
@ -25,13 +25,16 @@ the work of others (and possibly get scooped by them) or have your work
|
||||
duplicated by others.
|
||||
|
||||
For informal communication with (some of) the LAMMPS developers you may
|
||||
ask to join the `LAMMPS developers on Slack <https://lammps.slack.com>`_.
|
||||
This slack work space is by invitation only. Thus for access, please
|
||||
send an e-mail to ``slack@lammps.org`` explaining what part of LAMMPS
|
||||
you are working on. Only discussions related to LAMMPS development are
|
||||
tolerated, so this is **NOT** for people that look for help with compiling,
|
||||
installing, or using LAMMPS. Please contact the `lammps-users mailing
|
||||
list <https://www.lammps.org/mail.html>`_ for those purposes instead.
|
||||
ask to join the `LAMMPS developers on Slack
|
||||
<https://lammps.slack.com>`_. This slack work space is by invitation
|
||||
only. Thus for access, please send an e-mail to ``slack@lammps.org``
|
||||
explaining what part of LAMMPS you are working on. Only discussions
|
||||
related to LAMMPS development are tolerated, so this is **NOT** for
|
||||
people that look for help with compiling, installing, or using
|
||||
LAMMPS. Please contact the
|
||||
`lammps-users mailing list <https://www.lammps.org/mail.html>`_ or the
|
||||
`LAMMPS forum <https://www.lammps.org/forum.html>`_ for those purposes
|
||||
instead.
|
||||
|
||||
How quickly your contribution will be integrated depends largely on how
|
||||
much effort it will cause to integrate and test it, how many and what
|
||||
@ -49,11 +52,9 @@ with gzip. Please only use gzip compression, as this works well and is
|
||||
available on all platforms.
|
||||
|
||||
If the new features/files are broadly useful we may add them as core
|
||||
files to LAMMPS or as part of a :doc:`package <Packages_list>`. The
|
||||
USER-MISC package is simply a collection of (mostly) unrelated single
|
||||
files, which is the simplest way to have your contribution quickly added
|
||||
to the LAMMPS distribution. All packages are listed and described
|
||||
on the :doc:`Packages details <Packages_details>` doc page.
|
||||
files to LAMMPS or as part of a :doc:`package <Packages_list>`. All
|
||||
packages are listed and described on the :doc:`Packages details
|
||||
<Packages_details>` doc page.
|
||||
|
||||
Note that by providing us files to release, you are agreeing to make
|
||||
them open-source, i.e. we can release them under the terms of the GPL
|
||||
@ -61,7 +62,7 @@ them open-source, i.e. we can release them under the terms of the GPL
|
||||
a LGPL (version 2.1) distribution that we make available to developers
|
||||
on request only and with files that are authorized for that kind of
|
||||
distribution removed (e.g. interface to FFTW). See the
|
||||
:doc:`LAMMPS license <Intro_opensource>` doc page for details.
|
||||
:doc:`LAMMPS license <Intro_opensource>` page for details.
|
||||
|
||||
.. note::
|
||||
|
||||
@ -79,7 +80,7 @@ distribution removed (e.g. interface to FFTW). See the
|
||||
|
||||
.. _lws: https://www.lammps.org
|
||||
|
||||
The previous sections of this doc page describe how to add new "style"
|
||||
The previous sections of this page describe how to add new "style"
|
||||
files of various kinds to LAMMPS. Packages are simply collections of
|
||||
one or more new class files which are invoked as a new style within a
|
||||
LAMMPS input script. If designed correctly, these additions typically
|
||||
@ -92,7 +93,7 @@ trivial change is making a parent-class method "virtual" when you derive
|
||||
a new child class from it.
|
||||
|
||||
Here is a checklist of steps you need to follow to submit a single file
|
||||
or user package for our consideration. Following these steps will save
|
||||
or package for our consideration. Following these steps will save
|
||||
both you and us time. Please have a look at the existing files in
|
||||
packages in the src directory for examples. If you are uncertain, please ask.
|
||||
|
||||
@ -106,7 +107,7 @@ packages in the src directory for examples. If you are uncertain, please ask.
|
||||
your contribution(s) to be added to main LAMMPS code or one of its
|
||||
standard packages, it needs to be written in a style compatible with
|
||||
other LAMMPS source files. This means: 2-character indentation per
|
||||
level, **no tabs**\ , no lines over 100 characters. I/O is done via
|
||||
level, **no tabs**, no lines over 100 characters. I/O is done via
|
||||
the C-style stdio library (mixing of stdio and iostreams is generally
|
||||
discouraged), class header files should not import any system headers
|
||||
outside of <cstdio>, STL containers should be avoided in headers,
|
||||
@ -150,37 +151,40 @@ packages in the src directory for examples. If you are uncertain, please ask.
|
||||
You may also use ``// clang-format on/off`` throughout your file
|
||||
to protect sections of the file from being reformatted.
|
||||
|
||||
* If you want your contribution to be added as a user-contributed
|
||||
feature, and it's a single file (actually a \*.cpp and \*.h file) it can
|
||||
rapidly be added to the USER-MISC directory. Send us the one-line
|
||||
entry to add to the USER-MISC/README file in that dir, along with the
|
||||
2 source files. You can do this multiple times if you wish to
|
||||
contribute several individual features.
|
||||
* Please review the list of :doc:`available Packages <Packages_details>`
|
||||
to see if your contribution could be added to be added to one of them.
|
||||
It should fit into the general purposed of that package. If it does not
|
||||
fit well, it can be added to one of the EXTRA- packages or the MISC package.
|
||||
|
||||
* If you want your contribution to be added and it has several related
|
||||
features or is dependent on an external or bundled library, it is best
|
||||
to make it a package directory with a name like FOO. In addition to
|
||||
your new files, the directory should contain a README text file. The
|
||||
README should contain your name and contact information and a brief
|
||||
description of what your new package does. If your files depend on
|
||||
other LAMMPS style files also being installed (e.g. because your file
|
||||
is a derived class from the other LAMMPS class), then an Install.sh
|
||||
file is also needed to check for those dependencies. See other README
|
||||
and Install.sh files in other directories as examples. Submit a pull
|
||||
request on GitHub or send us a tarball of this FOO directory. Pull
|
||||
requests are strongly encouraged since the greatly reduce the effort
|
||||
to integrate a contribution and simplify the process of adjusting the
|
||||
contributed code to cleanly integrate into the LAMMPS distribution.
|
||||
* If your contribution has several related features that are not covered
|
||||
by one of the existing packages or is dependent on a library (bundled
|
||||
or external), it is best to make it a package directory with a name
|
||||
like FOO. In addition to your new files, the directory should contain
|
||||
a README text file. The README should contain your name and contact
|
||||
information and a brief description of what your new package does. If
|
||||
your files depend on other LAMMPS style files also being installed
|
||||
(e.g. because your file is a derived class from the other LAMMPS
|
||||
class), then an Install.sh file is also needed to check for those
|
||||
dependencies and modifications to src/Depend.sh to trigger the checks.
|
||||
See other README and Install.sh files in other directories as examples.
|
||||
Similarly for CMake support changes need to be made to cmake/CMakeLists.txt,
|
||||
the files in cmake/presets, and possibly a file to cmake/Modules/Packages/
|
||||
added. Please check out how this is handled for existing packages and
|
||||
ask the LAMMPS developers if you need assistance. Please submit a pull
|
||||
request on GitHub or send us a tarball of this FOO directory and all
|
||||
modified files. Pull requests are strongly encouraged since they greatly
|
||||
reduce the effort required to integrate a contribution and simplify the
|
||||
process of adjusting the contributed code to cleanly fit into the
|
||||
LAMMPS distribution.
|
||||
|
||||
* Your new source files need to have the LAMMPS copyright, GPL notice,
|
||||
and your name and email address at the top, like other
|
||||
user-contributed LAMMPS source files. They need to create a class
|
||||
that is inside the LAMMPS namespace. If the file is for one of the
|
||||
USER packages, including USER-MISC, then we are not as picky about the
|
||||
coding style (see above). I.e. the files do not need to be in the
|
||||
same stylistic format and syntax as other LAMMPS files, though that
|
||||
would be nice for developers as well as users who try to read your
|
||||
code.
|
||||
that is inside the LAMMPS namespace. To simplify maintenance, we
|
||||
may ask to adjust the programming style and formatting style to closer
|
||||
match the rest of LAMMPS. We bundle a clang-format configuration file
|
||||
that can help with adjusting the formatting, although this is not a
|
||||
strict requirement.
|
||||
|
||||
* You **must** also create a **documentation** file for each new command
|
||||
or style you are adding to LAMMPS. For simplicity and convenience,
|
||||
@ -199,13 +203,13 @@ packages in the src directory for examples. If you are uncertain, please ask.
|
||||
pdf" in the doc folder. As appropriate, the text files can include
|
||||
inline mathematical expression or figures (see doc/JPG for examples).
|
||||
Additional PDF files with further details (see doc/PDF for examples)
|
||||
may also be included. The doc page should also include literature
|
||||
may also be included. The page should also include literature
|
||||
citations as appropriate; see the bottom of doc/fix_nh.rst for
|
||||
examples and the earlier part of the same file for how to format the
|
||||
cite itself. Citation labels must be unique across all .rst files.
|
||||
The "Restrictions" section of the doc page should indicate if your
|
||||
The "Restrictions" section of the page should indicate if your
|
||||
command is only available if LAMMPS is built with the appropriate
|
||||
USER-MISC or FOO package. See other package doc files for examples of
|
||||
FOO package. See other package doc files for examples of
|
||||
how to do this. Please run at least "make html" and "make spelling"
|
||||
and carefully inspect and proofread the resulting HTML format doc page
|
||||
before submitting your code. Upon submission of a pull request,
|
||||
|
||||
@ -129,7 +129,7 @@ derived class. See fix.h for details.
|
||||
Typically, only a small fraction of these methods are defined for a
|
||||
particular fix. Setmask is mandatory, as it determines when the fix
|
||||
will be invoked during the timestep. Fixes that perform time
|
||||
integration (\ *nve*\ , *nvt*\ , *npt*\ ) implement initial_integrate() and
|
||||
integration (\ *nve*, *nvt*, *npt*\ ) implement initial_integrate() and
|
||||
final_integrate() to perform velocity Verlet updates. Fixes that
|
||||
constrain forces implement post_force().
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@ specific set of features. For example, force fields for molecular
|
||||
systems or rigid-body constraints are in packages. You can see the
|
||||
list of all packages and "make" commands to manage them by typing
|
||||
"make package" from within the src directory of the LAMMPS
|
||||
distribution. The :doc:`Build package <Build_package>` doc page gives
|
||||
distribution. The :doc:`Build package <Build_package>` page gives
|
||||
general info on how to install and un-install packages as part of the
|
||||
LAMMPS build process.
|
||||
|
||||
|
||||
@ -49,11 +49,17 @@ page gives those details.
|
||||
* :ref:`DPD-SMOOTH <PKG-DPD-SMOOTH>`
|
||||
* :ref:`DRUDE <PKG-DRUDE>`
|
||||
* :ref:`EFF <PKG-EFF>`
|
||||
* :ref:`EXTRA-COMPUTE <PKG-EXTRA-COMPUTE>`
|
||||
* :ref:`EXTRA-DUMP <PKG-EXTRA-DUMP>`
|
||||
* :ref:`EXTRA-FIX <PKG-EXTRA-FIX>`
|
||||
* :ref:`EXTRA-MOLECULE <PKG-EXTRA-MOLECULE>`
|
||||
* :ref:`EXTRA-PAIR <PKG-EXTRA-PAIR>`
|
||||
* :ref:`FEP <PKG-FEP>`
|
||||
* :ref:`GPU <PKG-GPU>`
|
||||
* :ref:`GRANULAR <PKG-GRANULAR>`
|
||||
* :ref:`H5MD <PKG-H5MD>`
|
||||
* :ref:`INTEL <PKG-INTEL>`
|
||||
* :ref:`INTERLAYER <PKG-INTERLAYER>`
|
||||
* :ref:`KIM <PKG-KIM>`
|
||||
* :ref:`KOKKOS <PKG-KOKKOS>`
|
||||
* :ref:`KSPACE <PKG-KSPACE>`
|
||||
@ -83,6 +89,7 @@ page gives those details.
|
||||
* :ref:`NETCDF <PKG-NETCDF>`
|
||||
* :ref:`OPENMP <PKG-OPENMP>`
|
||||
* :ref:`OPT <PKG-OPT>`
|
||||
* :ref:`ORIENT <PKG-ORIENT>`
|
||||
* :ref:`PERI <PKG-PERI>`
|
||||
* :ref:`PHONON <PKG-PHONON>`
|
||||
* :ref:`PLUGIN <PKG-PLUGIN>`
|
||||
@ -108,7 +115,6 @@ page gives those details.
|
||||
* :ref:`VORONOI <PKG-VORONOI>`
|
||||
* :ref:`VTK <PKG-VTK>`
|
||||
* :ref:`YAFF <PKG-YAFF>`
|
||||
* :ref:`USER-MISC <PKG-USER-MISC>`
|
||||
|
||||
----------
|
||||
|
||||
@ -562,6 +568,7 @@ short-range or long-range interactions.
|
||||
* :doc:`pair_style lj/cut/dipole/cut <pair_dipole>`
|
||||
* :doc:`pair_style lj/cut/dipole/long <pair_dipole>`
|
||||
* :doc:`pair_style lj/long/dipole/long <pair_dipole>`
|
||||
* :doc: `angle_style dipole <angle_dipole>`
|
||||
* examples/dipole
|
||||
|
||||
----------
|
||||
@ -755,6 +762,86 @@ tools/eff; see its README file.
|
||||
* tools/eff
|
||||
* https://www.lammps.org/movies.html#eff
|
||||
|
||||
-------------------
|
||||
|
||||
.. _PKG-EXTRA-COMPUTE:
|
||||
|
||||
EXTRA-COMPUTE package
|
||||
---------------------
|
||||
|
||||
**Contents:**
|
||||
|
||||
Additional compute styles that are less commonly used.
|
||||
|
||||
**Supporting info:**
|
||||
|
||||
* src/EXTRA-COMPUTE: filenames -> commands
|
||||
* :doc:`compute <compute>`
|
||||
|
||||
----------
|
||||
|
||||
.. _PKG-EXTRA-DUMP:
|
||||
|
||||
EXTRA-DUMP package
|
||||
------------------
|
||||
|
||||
**Contents:**
|
||||
|
||||
Additional dump styles that are less commonly used.
|
||||
|
||||
**Supporting info:**
|
||||
|
||||
* src/EXTRA-DUMP: filenames -> commands
|
||||
* :doc:`dump <dump>`
|
||||
|
||||
----------
|
||||
|
||||
.. _PKG-EXTRA-FIX:
|
||||
|
||||
EXTRA-FIX package
|
||||
-----------------
|
||||
|
||||
**Contents:**
|
||||
|
||||
Additional fix styles that are less commonly used.
|
||||
|
||||
**Supporting info:**
|
||||
|
||||
* src/EXTRA-FIX: filenames -> commands
|
||||
* :doc:`fix <fix>`
|
||||
|
||||
----------
|
||||
|
||||
.. _PKG-EXTRA-MOLECULE:
|
||||
|
||||
EXTRA-MOLECULE package
|
||||
----------------------
|
||||
|
||||
**Contents:**
|
||||
|
||||
Additional bond, angle, dihedral, and improper styles that are less commonly used.
|
||||
|
||||
**Supporting info:**
|
||||
|
||||
* src/EXTRA-MOLECULE: filenames -> commands
|
||||
* :doc:`molecular styles <Commands_bond>`
|
||||
|
||||
----------
|
||||
|
||||
.. _PKG-EXTRA-PAIR:
|
||||
|
||||
EXTRA-PAIR package
|
||||
------------------
|
||||
|
||||
**Contents:**
|
||||
|
||||
Additional pair styles that are less commonly used.
|
||||
|
||||
**Supporting info:**
|
||||
|
||||
* src/EXTRA-PAIR: filenames -> commands
|
||||
* :doc:`pair_style <pair_style>`
|
||||
|
||||
----------
|
||||
|
||||
.. _PKG-FEP:
|
||||
@ -938,6 +1025,24 @@ This package has :ref:`specific installation instructions <intel>` on the :doc:`
|
||||
|
||||
----------
|
||||
|
||||
.. _PKG-INTERLAYER:
|
||||
|
||||
INTERLAYER package
|
||||
------------------
|
||||
|
||||
**Contents:**
|
||||
|
||||
A collection of pair styles specifically to be used for modeling layered
|
||||
materials, most commonly graphene sheets (or equivalents).
|
||||
|
||||
**Supporting info:**
|
||||
|
||||
* src/INTERLAYER: filenames -> commands
|
||||
* :doc:`Pair style <Commands_pair>` page
|
||||
* examples/PACKAGES/interlayer
|
||||
|
||||
----------
|
||||
|
||||
.. _PKG-KIM:
|
||||
|
||||
KIM package
|
||||
@ -1428,7 +1533,7 @@ MISC package
|
||||
|
||||
**Contents:**
|
||||
|
||||
A variety of compute, fix, pair, dump styles with specialized
|
||||
A variety of compute, fix, pair, bond styles with specialized
|
||||
capabilities that don't align with other packages. Do a directory
|
||||
listing, "ls src/MISC", to see the list of commands.
|
||||
|
||||
@ -1440,18 +1545,16 @@ listing, "ls src/MISC", to see the list of commands.
|
||||
**Supporting info:**
|
||||
|
||||
* src/MISC: filenames -> commands
|
||||
* :doc:`compute ti <compute_ti>`
|
||||
* :doc:`fix evaporate <fix_evaporate>`
|
||||
* :doc:`bond_style special <bond_special>`
|
||||
* :doc:`compute viscosity/cos <compute_viscosity_cos>`
|
||||
* :doc:`fix accelerate/cos <fix_accelerate_cos>`
|
||||
* :doc:`fix imd <fix_imd>`
|
||||
* :doc:`fix oneway <fix_oneway>`
|
||||
* :doc:`fix orient/fcc <fix_orient>`
|
||||
* :doc:`fix ttm <fix_ttm>`
|
||||
* :doc:`fix thermal/conductivity <fix_thermal_conductivity>`
|
||||
* :doc:`fix viscosity <fix_viscosity>`
|
||||
* examples/KAPPA
|
||||
* examples/VISCOSITY
|
||||
* https://www.lammps.org/pictures.html#ttm
|
||||
* https://www.lammps.org/movies.html#evaporation
|
||||
* :doc:`fix ipi <fix_ipi>`
|
||||
* :doc:`pair_style agni <pair_agni>`
|
||||
* :doc:`pair_style list <pair_list>`
|
||||
* :doc:`pair_style srp <pair_srp>`
|
||||
* :doc:`pair_style tracker <pair_tracker>`
|
||||
* :doc:`fix pair/tracker <fix_pair_tracker>`
|
||||
|
||||
----------
|
||||
|
||||
@ -1936,6 +2039,23 @@ This package has :ref:`specific installation instructions <opt>` on the :doc:`Bu
|
||||
* Search the :doc:`pair style <Commands_pair>` page for styles followed by (t)
|
||||
* `Benchmarks page <https://www.lammps.org/bench.html>`_ of web site
|
||||
|
||||
.. _PKG-ORIENT:
|
||||
|
||||
ORIENT package
|
||||
--------------
|
||||
|
||||
**Contents:**
|
||||
|
||||
A few fixes that apply orientation dependent forces for studying
|
||||
grain boundary migration.
|
||||
|
||||
**Supporting info:**
|
||||
|
||||
* src/ORIENT: filenames -> commands
|
||||
* :doc:`fix orient/bcc <fix_orient>`
|
||||
* :doc:`fix orient/fcc <fix_orient>`
|
||||
* :doc:`fix orient/eco <fix_orient_eco>`
|
||||
|
||||
----------
|
||||
|
||||
.. _PKG-PERI:
|
||||
@ -2305,10 +2425,13 @@ another set.
|
||||
* :doc:`prd <prd>`
|
||||
* :doc:`tad <tad>`
|
||||
* :doc:`temper <temper>`,
|
||||
* :doc:`temper/npt <temper_npt>`,
|
||||
* :doc:`temper/grem <temper_grem>`,
|
||||
* :doc:`run_style verlet/split <run_style>`
|
||||
* examples/neb
|
||||
* examples/prd
|
||||
* examples/tad
|
||||
* examples/PACKAGES/grem
|
||||
|
||||
----------
|
||||
|
||||
@ -2658,26 +2781,3 @@ which discuss the `QuickFF <quickff_>`_ methodology.
|
||||
* :doc:`pair_style mm3/switch3/coulgauss/long <pair_lj_switch3_coulgauss_long>`
|
||||
* :doc:`pair_style lj/switch3/coulgauss/long <pair_lj_switch3_coulgauss_long>`
|
||||
* examples/PACKAGES/yaff
|
||||
|
||||
----------
|
||||
|
||||
.. _PKG-USER-MISC:
|
||||
|
||||
USER-MISC package
|
||||
-----------------
|
||||
|
||||
**Contents:**
|
||||
|
||||
A potpourri of (mostly) unrelated features contributed to LAMMPS by
|
||||
users. Each feature is a single fix, compute, pair, bond, angle,
|
||||
dihedral, improper, or command style.
|
||||
|
||||
**Authors:** The author for each style in the package is listed in the
|
||||
src/USER-MISC/README file.
|
||||
|
||||
**Supporting info:**
|
||||
|
||||
* src/USER-MISC: filenames -> commands
|
||||
* src/USER-MISC/README
|
||||
* one page per individual command listed in src/USER-MISC/README
|
||||
* examples/USER-MISC
|
||||
|
||||
@ -143,6 +143,31 @@ whether an extra library is needed to build and use the package:
|
||||
- :doc:`pair_style eff/cut <pair_eff>`
|
||||
- PACKAGES/eff
|
||||
- no
|
||||
* - :ref:`EXTRA-COMPUTE <PKG-EXTRA-COMPUTE>`
|
||||
- additional compute styles
|
||||
- :doc:`compute <compute>`
|
||||
- n/a
|
||||
- no
|
||||
* - :ref:`EXTRA-DUMP <PKG-EXTRA-DUMP>`
|
||||
- additional dump styles
|
||||
- :doc:`dump <dump>`
|
||||
- n/a
|
||||
- no
|
||||
* - :ref:`EXTRA-FIX <PKG-EXTRA-FIX>`
|
||||
- additional fix styles
|
||||
- :doc:`fix <fix>`
|
||||
- n/a
|
||||
- no
|
||||
* - :ref:`EXTRA-MOLECULE <PKG-EXTRA-MOLECULE>`
|
||||
- additional molecular styles
|
||||
- :doc:`molecular styles <Commands_bond>`
|
||||
- n/a
|
||||
- no
|
||||
* - :ref:`EXTRA-PAIR <PKG-EXTRA-PAIR>`
|
||||
- additional pair styles
|
||||
- :doc:`pair_style <pair_style>`
|
||||
- n/a
|
||||
- no
|
||||
* - :ref:`FEP <PKG-FEP>`
|
||||
- free energy perturbation
|
||||
- :doc:`compute fep <compute_fep>`
|
||||
@ -168,6 +193,11 @@ whether an extra library is needed to build and use the package:
|
||||
- :doc:`Speed intel <Speed_intel>`
|
||||
- `Benchmarks <https://www.lammps.org/bench.html>`_
|
||||
- no
|
||||
* - :ref:`INTERLAYER <PKG-INTERLAYER>`
|
||||
- Inter-layer pair potentials
|
||||
- :doc:`several pair styles <Commands_pair>`
|
||||
- PACKAGES/interlayer
|
||||
- no
|
||||
* - :ref:`KIM <PKG-KIM>`
|
||||
- OpenKIM wrapper
|
||||
- :doc:`pair_style kim <pair_kim>`
|
||||
@ -313,6 +343,11 @@ whether an extra library is needed to build and use the package:
|
||||
- :doc:`Speed opt <Speed_opt>`
|
||||
- `Benchmarks <https://www.lammps.org/bench.html>`_
|
||||
- no
|
||||
* - :ref:`ORIENT <PKG-ORIENT>`
|
||||
- fixes for orientation depended forces
|
||||
- :doc:`fix orient/* <fix_orient>`
|
||||
- PACKAGES/orient_eco
|
||||
- no
|
||||
* - :ref:`PERI <PKG-PERI>`
|
||||
- Peridynamics models
|
||||
- :doc:`pair_style peri <pair_peri>`
|
||||
@ -423,11 +458,6 @@ whether an extra library is needed to build and use the package:
|
||||
- :doc:`fix nvt/uef <fix_nh_uef>`
|
||||
- PACKAGES/uef
|
||||
- no
|
||||
* - :ref:`USER-MISC <PKG-USER-MISC>`
|
||||
- single-file contributions
|
||||
- USER-MISC/README
|
||||
- USER-MISC
|
||||
- no
|
||||
* - :ref:`VORONOI <PKG-VORONOI>`
|
||||
- Voronoi tesselation
|
||||
- :doc:`compute voronoi/atom <compute_voronoi_atom>`
|
||||
|
||||
@ -43,7 +43,7 @@ complex loop with branching logic, than can be created using the
|
||||
simple looping and branching logic enabled by the :doc:`next <next>` and
|
||||
:doc:`if <if>` commands.
|
||||
|
||||
See the :doc:`python <python>` doc page and the :doc:`variable <variable>`
|
||||
See the :doc:`python <python>` page and the :doc:`variable <variable>`
|
||||
doc page for its python-style variables for more info, including
|
||||
examples of Python code you can write for both pure Python operations
|
||||
and callbacks to LAMMPS.
|
||||
|
||||
@ -20,7 +20,7 @@ computes, fixes, or variables in LAMMPS using the :py:mod:`lammps` module.
|
||||
global vector or array, a single double value from the vector or array
|
||||
is returned, indexed by I (vector) or I and J (array). I,J are
|
||||
zero-based indices.
|
||||
See the :doc:`Howto output <Howto_output>` doc page for a discussion of
|
||||
See the :doc:`Howto output <Howto_output>` page for a discussion of
|
||||
global, per-atom, and local data, and of scalar, vector, and array
|
||||
data types. See the doc pages for individual :doc:`computes <compute>`
|
||||
and :doc:`fixes <fix>` for a description of what they calculate and
|
||||
|
||||
@ -41,4 +41,4 @@ first importing from the ``lammps`` module:
|
||||
>>> CDLL("liblammps.so")
|
||||
|
||||
If an error occurs, carefully go through the steps in :ref:`python_install_guides` and on the
|
||||
:doc:`Build_basics <Build_basics>` doc page about building a shared library.
|
||||
:doc:`Build_basics <Build_basics>` page about building a shared library.
|
||||
|
||||
@ -42,7 +42,7 @@ single processor. In theory you should get identical answers on any
|
||||
number of processors and on any machine. In practice, numerical
|
||||
round-off due to using floating-point math can cause slight differences
|
||||
and an eventual divergence of molecular dynamics trajectories. See the
|
||||
:doc:`Errors common <Errors_common>` doc page for discussion of this.
|
||||
:doc:`Errors common <Errors_common>` page for discussion of this.
|
||||
|
||||
LAMMPS can run as large a problem as will fit in the physical memory of
|
||||
one or more processors. If you run out of memory, you must run on more
|
||||
|
||||
@ -365,7 +365,7 @@ to insure that a specific Kspace processor (in the second partition) is
|
||||
matched up with a specific set of processors in the first partition.
|
||||
See the :doc:`General tips <Speed_tips>` page for more details.
|
||||
|
||||
If the keyword *nth* is used with a setting *N*\ , then it means every
|
||||
If the keyword *nth* is used with a setting *N*, then it means every
|
||||
Nth processor will be moved to the end of the ranking. This is useful
|
||||
when using the :doc:`run_style verlet/split <run_style>` command with 2
|
||||
partitions via the -partition command-line switch. The first set of
|
||||
@ -397,7 +397,7 @@ so that the processors in each partition will be
|
||||
See the "processors" command for how to insure processors from each
|
||||
partition could then be grouped optimally for quad-core nodes.
|
||||
|
||||
If the keyword is *custom*\ , then a file that specifies a permutation
|
||||
If the keyword is *custom*, then a file that specifies a permutation
|
||||
of the processor ranks is also specified. The format of the reorder
|
||||
file is as follows. Any number of initial blank or comment lines
|
||||
(starting with a "#" character) can be present. These should be
|
||||
@ -464,7 +464,7 @@ The syntax following restartfile (or remap), namely
|
||||
datafile keyword value ...
|
||||
|
||||
is identical to the arguments of the :doc:`write_data <write_data>`
|
||||
command. See its doc page for details. This includes its
|
||||
command. See its page for details. This includes its
|
||||
optional keyword/value settings.
|
||||
|
||||
----------
|
||||
@ -505,11 +505,11 @@ The syntax following restartfile (or remap), namely
|
||||
group-ID dumpstyle dumpfile arg1 arg2 ...
|
||||
|
||||
is identical to the arguments of the :doc:`write_dump <write_dump>`
|
||||
command. See its doc page for details. This includes what per-atom
|
||||
command. See its page for details. This includes what per-atom
|
||||
fields are written to the dump file and optional dump_modify settings,
|
||||
including ones that affect how parallel dump files are written, e.g.
|
||||
the *nfile* and *fileper* keywords. See the
|
||||
:doc:`dump_modify <dump_modify>` doc page for details.
|
||||
:doc:`dump_modify <dump_modify>` page for details.
|
||||
|
||||
----------
|
||||
|
||||
@ -537,7 +537,7 @@ partition screen files file.N.
|
||||
**-suffix style args**
|
||||
|
||||
Use variants of various styles if they exist. The specified style can
|
||||
be *gpu*\ , *intel*\ , *kk*\ , *omp*\ , *opt*\ , or *hybrid*\ . These
|
||||
be *gpu*, *intel*, *kk*, *omp*, *opt*, or *hybrid*\ . These
|
||||
refer to optional packages that LAMMPS can be built with, as described
|
||||
in :doc:`Accelerate performance <Speed>`. The "gpu" style corresponds to the
|
||||
GPU package, the "intel" style to the INTEL package, the "kk"
|
||||
|
||||
@ -152,7 +152,7 @@ information is provided about the line search and statistics on how
|
||||
many iterations and force-evaluations the minimizer required.
|
||||
Multiple force evaluations are typically done at each iteration to
|
||||
perform a 1d line minimization in the search direction. See the
|
||||
:doc:`minimize <minimize>` doc page for more details.
|
||||
:doc:`minimize <minimize>` page for more details.
|
||||
|
||||
----------
|
||||
|
||||
|
||||
@ -71,7 +71,7 @@ by AMD.
|
||||
|
||||
**Building LAMMPS with the GPU package:**
|
||||
|
||||
See the :ref:`Build extras <gpu>` doc page for
|
||||
See the :ref:`Build extras <gpu>` page for
|
||||
instructions.
|
||||
|
||||
**Run with the GPU package from the command line:**
|
||||
@ -118,7 +118,7 @@ automatic selection of the number of GPUs to use.
|
||||
Using the "-pk" switch explicitly allows for setting of the number of
|
||||
GPUs/node to use and additional options. Its syntax is the same as
|
||||
the "package gpu" command. See the :doc:`package <package>`
|
||||
command doc page for details, including the default values used for
|
||||
command page for details, including the default values used for
|
||||
all its options if it is not specified.
|
||||
|
||||
Note that the default for the :doc:`package gpu <package>` command is to
|
||||
@ -182,7 +182,7 @@ deterministic results.
|
||||
calculations can be dynamically balanced across the CPU cores and
|
||||
GPUs. GPU-specific settings can be made which can be optimized
|
||||
for different hardware. See the :doc:`package <package>` command
|
||||
doc page for details.
|
||||
page for details.
|
||||
* As described by the :doc:`package gpu <package>` command, GPU
|
||||
accelerated pair styles can perform computations asynchronously with
|
||||
CPU computations. The "Pair" time reported by LAMMPS will be the
|
||||
|
||||
@ -103,7 +103,7 @@ Quick Start for Experienced Users
|
||||
"""""""""""""""""""""""""""""""""
|
||||
|
||||
LAMMPS should be built with the INTEL package installed.
|
||||
Simulations should be run with 1 MPI task per physical *core*\ ,
|
||||
Simulations should be run with 1 MPI task per physical *core*,
|
||||
not *hardware thread*\ .
|
||||
|
||||
* Edit src/MAKE/OPTIONS/Makefile.intel_cpu_intelmpi as necessary.
|
||||
@ -205,7 +205,7 @@ this information can normally be obtained with:
|
||||
Building LAMMPS with the INTEL package
|
||||
"""""""""""""""""""""""""""""""""""""""""""
|
||||
|
||||
See the :ref:`Build extras <intel>` doc page for
|
||||
See the :ref:`Build extras <intel>` page for
|
||||
instructions. Some additional details are covered here.
|
||||
|
||||
For building with make, several example Makefiles for building with
|
||||
|
||||
@ -67,7 +67,7 @@ produce an executable compatible with a specific hardware.
|
||||
Building LAMMPS with the KOKKOS package
|
||||
"""""""""""""""""""""""""""""""""""""""
|
||||
|
||||
See the :ref:`Build extras <kokkos>` doc page for instructions.
|
||||
See the :ref:`Build extras <kokkos>` page for instructions.
|
||||
|
||||
Running LAMMPS with the KOKKOS package
|
||||
""""""""""""""""""""""""""""""""""""""
|
||||
@ -217,7 +217,7 @@ threads/task as Nt. The product of these two values should be N, i.e.
|
||||
be best for many-body potentials. For simpler pair-wise potentials, it
|
||||
may be faster to use a "full" neighbor list with Newton flag to "off".
|
||||
Use the "-pk kokkos" :doc:`command-line switch <Run_options>` to change
|
||||
the default :doc:`package kokkos <package>` options. See its doc page for
|
||||
the default :doc:`package kokkos <package>` options. See its page for
|
||||
details and default settings. Experimenting with its options can provide
|
||||
a speed-up for specific calculations. For example:
|
||||
|
||||
@ -279,7 +279,7 @@ one or more nodes, each with two GPUs:
|
||||
setting the neighbor binsize equal to twice the CPU default value will
|
||||
give speedup, which is the default when running on GPUs. Use the "-pk
|
||||
kokkos" :doc:`command-line switch <Run_options>` to change the default
|
||||
:doc:`package kokkos <package>` options. See its doc page for details and
|
||||
:doc:`package kokkos <package>` options. See its page for details and
|
||||
default settings. Experimenting with its options can provide a speed-up
|
||||
for specific calculations. For example:
|
||||
|
||||
|
||||
@ -18,7 +18,7 @@ launched by each MPI task on the local node (using shared memory).
|
||||
Building LAMMPS with the OPENMP package
|
||||
"""""""""""""""""""""""""""""""""""""""""
|
||||
|
||||
See the :ref:`Build extras <openmp>` doc page for
|
||||
See the :ref:`Build extras <openmp>` page for
|
||||
instructions.
|
||||
|
||||
Run with the OPENMP package from the command line
|
||||
@ -50,7 +50,7 @@ threads per MPI task via the OMP_NUM_THREADS environment variable.
|
||||
|
||||
You can also use the "-pk omp Nt" :doc:`command-line switch <Run_options>`, to explicitly set Nt = # of OpenMP threads
|
||||
per MPI task to use, as well as additional options. Its syntax is the
|
||||
same as the :doc:`package omp <package>` command whose doc page gives
|
||||
same as the :doc:`package omp <package>` command whose page gives
|
||||
details, including the default values used if it is not specified. It
|
||||
also gives more details on how to set the number of threads via the
|
||||
OMP_NUM_THREADS environment variable.
|
||||
@ -70,7 +70,7 @@ Use the :doc:`suffix omp <suffix>` command, or you can explicitly add an
|
||||
|
||||
You must also use the :doc:`package omp <package>` command to enable the
|
||||
OPENMP package. When you do this you also specify how many threads
|
||||
per MPI task to use. The command doc page explains other options and
|
||||
per MPI task to use. The command page explains other options and
|
||||
how to set the number of threads via the OMP_NUM_THREADS environment
|
||||
variable.
|
||||
|
||||
|
||||
@ -15,7 +15,7 @@ Any hardware. Any compiler.
|
||||
Building LAMMPS with the OPT package
|
||||
""""""""""""""""""""""""""""""""""""
|
||||
|
||||
See the :ref:`Build extras <opt>` doc page for instructions.
|
||||
See the :ref:`Build extras <opt>` page for instructions.
|
||||
|
||||
Run with the OPT package from the command line
|
||||
""""""""""""""""""""""""""""""""""""""""""""""
|
||||
|
||||
@ -363,7 +363,7 @@ michele.ceriotti at gmail.com, to interface to a variety of molecular
|
||||
dynamics codes.
|
||||
|
||||
See the tools/i-pi/manual.pdf file for an overview of i-PI, and the
|
||||
:doc:`fix ipi <fix_ipi>` doc page for further details on running PIMD
|
||||
:doc:`fix ipi <fix_ipi>` page for further details on running PIMD
|
||||
calculations with LAMMPS.
|
||||
|
||||
----------
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
Styles with a *gpu*\ , *intel*\ , *kk*\ , *omp*\ , or *opt* suffix are
|
||||
Styles with a *gpu*, *intel*, *kk*, *omp*, or *opt* suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed on the :doc:`Speed packages <Speed_packages>` doc
|
||||
@ -7,11 +7,11 @@ produce the same results, except for round-off and precision issues.
|
||||
|
||||
These accelerated styles are part of the GPU, INTEL, KOKKOS,
|
||||
OPENMP and OPT packages, respectively. They are only enabled if
|
||||
LAMMPS was built with those packages. See the :doc:`Build package <Build_package>` doc page for more info.
|
||||
LAMMPS was built with those packages. See the :doc:`Build package <Build_package>` page for more info.
|
||||
|
||||
You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the :doc:`-suffix command-line switch <Run_options>` when you invoke LAMMPS, or you can use the
|
||||
:doc:`suffix <suffix>` command in your input script.
|
||||
|
||||
See the :doc:`Speed packages <Speed_packages>` doc page for more
|
||||
See the :doc:`Speed packages <Speed_packages>` page for more
|
||||
instructions on how to use the accelerated styles effectively.
|
||||
|
||||
@ -56,7 +56,7 @@ radian\^2.
|
||||
|
||||
----------
|
||||
|
||||
Styles with a *gpu*\ , *intel*\ , *kk*\ , *omp*\ , or *opt* suffix are
|
||||
Styles with a *gpu*, *intel*, *kk*, *omp*, or *opt* suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed on the :doc:`Speed packages <Speed_packages>` doc
|
||||
@ -65,13 +65,13 @@ produce the same results, except for round-off and precision issues.
|
||||
|
||||
These accelerated styles are part of the GPU, INTEL, KOKKOS,
|
||||
OPENMP and OPT packages, respectively. They are only enabled if
|
||||
LAMMPS was built with those packages. See the :doc:`Build package <Build_package>` doc page for more info.
|
||||
LAMMPS was built with those packages. See the :doc:`Build package <Build_package>` page for more info.
|
||||
|
||||
You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the :doc:`-suffix command-line switch <Run_options>` when you invoke LAMMPS, or you can use the
|
||||
:doc:`suffix <suffix>` command in your input script.
|
||||
|
||||
See :doc:`Speed packages <Speed_packages>` doc page for more
|
||||
See :doc:`Speed packages <Speed_packages>` page for more
|
||||
instructions on how to use the accelerated styles effectively.
|
||||
|
||||
----------
|
||||
|
||||
@ -54,7 +54,7 @@ Restrictions
|
||||
""""""""""""
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULE package. See the :doc:`Build package <Build_package>` doc page
|
||||
EXTRA-MOLECULE package. See the :doc:`Build package <Build_package>` doc page
|
||||
for more info.
|
||||
|
||||
Related commands
|
||||
|
||||
@ -58,7 +58,7 @@ Restrictions
|
||||
""""""""""""
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULE package. See the :doc:`Build package <Build_package>` doc page
|
||||
EXTRA-MOLECULE package. See the :doc:`Build package <Build_package>` doc page
|
||||
for more info.
|
||||
|
||||
Related commands
|
||||
|
||||
@ -53,7 +53,7 @@ Restrictions
|
||||
""""""""""""
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
USER-MISC package.
|
||||
MOLECULE package.
|
||||
|
||||
Related commands
|
||||
""""""""""""""""
|
||||
|
||||
@ -64,7 +64,7 @@ Restrictions
|
||||
""""""""""""
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
USER-MISC package. See the :doc:`Build package <Build_package>` doc
|
||||
MOLECULE package. See the :doc:`Build package <Build_package>` doc
|
||||
page for more info.
|
||||
|
||||
Related commands
|
||||
|
||||
@ -88,7 +88,7 @@ Restrictions
|
||||
""""""""""""
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
USER-MISC package. See the :doc:`Build package <Build_package>` doc
|
||||
DIPOLE package. See the :doc:`Build package <Build_package>` doc
|
||||
page for more info.
|
||||
|
||||
.. note::
|
||||
@ -106,7 +106,9 @@ page for more info.
|
||||
The :doc:`newton <newton>` command for intramolecular interactions must be "on"
|
||||
(which is the default except when using some accelerator packages).
|
||||
|
||||
This angle style should not be used with SHAKE.
|
||||
.. note::
|
||||
|
||||
This angle style should **NOT** be used with fix shake.
|
||||
|
||||
Related commands
|
||||
""""""""""""""""
|
||||
|
||||
@ -50,7 +50,7 @@ Restrictions
|
||||
""""""""""""
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
USER-MISC package. See the :doc:`Build package <Build_package>` doc
|
||||
MOLECULE package. See the :doc:`Build package <Build_package>` doc
|
||||
page for more info.
|
||||
|
||||
Related commands
|
||||
|
||||
@ -49,7 +49,7 @@ Restrictions
|
||||
""""""""""""
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
USER-MISC package. See the :doc:`Build package <Build_package>` doc
|
||||
MOLECULE package. See the :doc:`Build package <Build_package>` doc
|
||||
page for more info.
|
||||
|
||||
Related commands
|
||||
|
||||
@ -49,7 +49,7 @@ Restrictions
|
||||
""""""""""""
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
USER-MISC package. See the :doc:`Build package <Build_package>` doc
|
||||
MOLECULE package. See the :doc:`Build package <Build_package>` doc
|
||||
page for more info.
|
||||
|
||||
Related commands
|
||||
|
||||
@ -58,7 +58,7 @@ specifying additional BondBond (and BondAngle) coefficients either via
|
||||
the input script or in the data file. I.e. *class2* must be added to
|
||||
each line after the angle type. For lines in the BondBond (or
|
||||
BondAngle) section of the data file for angle types that are not
|
||||
*class2*\ , you must use an angle style of *skip* as a placeholder, e.g.
|
||||
*class2*, you must use an angle style of *skip* as a placeholder, e.g.
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
|
||||
@ -57,7 +57,7 @@ Restrictions
|
||||
""""""""""""
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
USER-MISC package. See the :doc:`Build package <Build_package>` doc
|
||||
MOLECULE package. See the :doc:`Build package <Build_package>` doc
|
||||
page for more info.
|
||||
|
||||
Related commands
|
||||
|
||||
@ -37,7 +37,7 @@ where :math:`\theta_0` is the equilibrium value of the angle and
|
||||
*lj/sdk* pair style between the atoms 1 and 3. This angle potential is
|
||||
intended for coarse grained MD simulations with the CMM parameterization
|
||||
using the :doc:`pair_style lj/sdk <pair_sdk>`. Relative to the
|
||||
pair_style *lj/sdk*\ , however, the energy is shifted by
|
||||
pair_style *lj/sdk*, however, the energy is shifted by
|
||||
:math:`\epsilon`, to avoid sudden jumps. Note that the usual 1/2 factor
|
||||
is included in :math:`K`.
|
||||
|
||||
|
||||
@ -66,7 +66,7 @@ specified by the associated :doc:`angle_coeff <angle_coeff>` command.
|
||||
|
||||
There are also additional accelerated pair styles included in the
|
||||
LAMMPS distribution for faster performance on CPUs, GPUs, and KNLs.
|
||||
The individual style names on the :ref:`Commands angle <angle>` doc page are followed by one or more
|
||||
The individual style names on the :ref:`Commands angle <angle>` page are followed by one or more
|
||||
of (g,i,k,o,t) to indicate which accelerated styles exist.
|
||||
|
||||
* :doc:`none <angle_none>` - turn off angle interactions
|
||||
@ -103,7 +103,7 @@ Angle styles can only be set for atom_styles that allow angles to be
|
||||
defined.
|
||||
|
||||
Most angle styles are part of the MOLECULE package. They are only
|
||||
enabled if LAMMPS was built with that package. See the :doc:`Build package <Build_package>` doc page for more info. The doc pages for
|
||||
enabled if LAMMPS was built with that package. See the :doc:`Build package <Build_package>` page for more info. The doc pages for
|
||||
individual bond potentials tell if it is part of a package.
|
||||
|
||||
Related commands
|
||||
|
||||
@ -66,7 +66,7 @@ Restrictions
|
||||
Only for be used with the specific controllers *thermal* or *momentum*.
|
||||
They are ignored if a lumped solution is requested.
|
||||
|
||||
*control thermal* is only for be used with specific transfers: thermal (*rescale*\ , *hoover*\ , *flux*\ ), *two_temperature* (*flux*\ ).
|
||||
*control thermal* is only for be used with specific transfers: thermal (*rescale*, *hoover*, *flux*\ ), *two_temperature* (*flux*\ ).
|
||||
*rescale* not valid with time filtering activated
|
||||
|
||||
*correction_max_iterations* is only for use with *thermal* physics using
|
||||
|
||||
@ -40,7 +40,7 @@ command. The *id* and *map* keywords must be specified before a
|
||||
simulation box is defined; other keywords can be specified any time.
|
||||
|
||||
The *id* keyword determines whether non-zero atom IDs can be assigned
|
||||
to each atom. If the value is *yes*\ , which is the default, IDs are
|
||||
to each atom. If the value is *yes*, which is the default, IDs are
|
||||
assigned, whether you use the :doc:`create atoms <create_atoms>` or
|
||||
:doc:`read_data <read_data>` or :doc:`read_restart <read_restart>`
|
||||
commands to initialize atoms. If the value is *no* the IDs for all
|
||||
|
||||
@ -61,7 +61,7 @@ command.
|
||||
Restrictions section.
|
||||
|
||||
Once a style is assigned, it cannot be changed, so use a style general
|
||||
enough to encompass all attributes. E.g. with style *bond*\ , angular
|
||||
enough to encompass all attributes. E.g. with style *bond*, angular
|
||||
terms cannot be used or added later to the model. It is OK to use a
|
||||
style more general than needed, though it may be slightly inefficient.
|
||||
|
||||
@ -136,13 +136,13 @@ quantities.
|
||||
It is possible to add some attributes, such as a molecule ID, to
|
||||
atom styles that do not have them via the :doc:`fix property/atom <fix_property_atom>` command. This command also
|
||||
allows new custom attributes consisting of extra integer or
|
||||
floating-point values to be added to atoms. See the :doc:`fix property/atom <fix_property_atom>` doc page for examples of cases
|
||||
floating-point values to be added to atoms. See the :doc:`fix property/atom <fix_property_atom>` page for examples of cases
|
||||
where this is useful and details on how to initialize, access, and
|
||||
output the custom values.
|
||||
|
||||
All of the above styles define point particles, except the *sphere*\ ,
|
||||
*ellipsoid*\ , *electron*\ , *peri*\ , *wavepacket*\ , *line*\ , *tri*\ , and
|
||||
*body* styles, which define finite-size particles. See the :doc:`Howto spherical <Howto_spherical>` doc page for an overview of using
|
||||
All of the above styles define point particles, except the *sphere*,
|
||||
*ellipsoid*, *electron*, *peri*, *wavepacket*, *line*, *tri*, and
|
||||
*body* styles, which define finite-size particles. See the :doc:`Howto spherical <Howto_spherical>` page for an overview of using
|
||||
finite-size particle models with LAMMPS.
|
||||
|
||||
All of the point-particle styles assign mass to particles on a
|
||||
@ -236,7 +236,7 @@ individual physical bodies from penetrating each other.
|
||||
For the *spin* style, a magnetic spin is associated to each atom.
|
||||
Those spins have a norm (their magnetic moment) and a direction.
|
||||
|
||||
The *wavepacket* style is similar to *electron*\ , but the electrons may
|
||||
The *wavepacket* style is similar to *electron*, but the electrons may
|
||||
consist of several Gaussian wave packets, summed up with coefficients
|
||||
cs= (cs_re,cs_im). Each of the wave packets is treated as a separate
|
||||
particle in LAMMPS, wave packets belonging to the same electron must
|
||||
@ -256,7 +256,7 @@ command. The template stores one or more molecules with a single copy
|
||||
of the topology info (bonds,angles,etc) of each. Individual atoms
|
||||
only store a template index and template atom to identify which
|
||||
molecule and which atom-within-the-molecule they represent. Using the
|
||||
*template* style instead of the *bond*\ , *angle*\ , *molecular* styles
|
||||
*template* style instead of the *bond*, *angle*, *molecular* styles
|
||||
can save memory for systems comprised of a large number of small
|
||||
molecules, all of a single type (or small number of types). See the
|
||||
paper by Grime and Voth, in :ref:`(Grime) <Grime>`, for examples of how this
|
||||
@ -283,7 +283,7 @@ the *bstyle* argument. Body particles can represent complex entities,
|
||||
such as surface meshes of discrete points, collections of
|
||||
sub-particles, deformable objects, etc.
|
||||
|
||||
The :doc:`Howto body <Howto_body>` doc page describes the body styles
|
||||
The :doc:`Howto body <Howto_body>` page describes the body styles
|
||||
LAMMPS currently supports, and provides more details as to the kind of
|
||||
body particles they represent. For all styles, each body particle
|
||||
stores moments of inertia and a quaternion 4-vector, so that its
|
||||
@ -332,14 +332,14 @@ styles.
|
||||
|
||||
The accelerated styles are part of the KOKKOS package. They are only
|
||||
enabled if LAMMPS was built with those packages. See the :doc:`Build
|
||||
package <Build_package>` doc page for more info.
|
||||
package <Build_package>` page for more info.
|
||||
|
||||
You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the :doc:`-suffix command-line
|
||||
switch <Run_options>` when you invoke LAMMPS, or you can use the
|
||||
:doc:`suffix <suffix>` command in your input script.
|
||||
|
||||
See the :doc:`Speed packages <Speed_packages>` doc page for more
|
||||
See the :doc:`Speed packages <Speed_packages>` page for more
|
||||
instructions on how to use the accelerated styles effectively.
|
||||
|
||||
Restrictions
|
||||
@ -350,9 +350,9 @@ This command cannot be used after the simulation box is defined by a
|
||||
|
||||
Many of the styles listed above are only enabled if LAMMPS was built
|
||||
with a specific package, as listed below. See the :doc:`Build package
|
||||
<Build_package>` doc page for more info.
|
||||
<Build_package>` page for more info.
|
||||
|
||||
The *angle*\ , *bond*\ , *full*\ , *molecular*\ , and *template* styles are
|
||||
The *angle*, *bond*, *full*, *molecular*, and *template* styles are
|
||||
part of the MOLECULE package.
|
||||
|
||||
The *line* and *tri* styles are part of the ASPHERE package.
|
||||
@ -370,7 +370,7 @@ The *electron* style is part of the EFF package for :doc:`electronic force field
|
||||
The *dpd* style is part of the DPD-REACT package for dissipative
|
||||
particle dynamics (DPD).
|
||||
|
||||
The *edpd*\ , *mdpd*\ , and *tdpd* styles are part of the DPD-MESO package
|
||||
The *edpd*, *mdpd*, and *tdpd* styles are part of the DPD-MESO package
|
||||
for energy-conserving dissipative particle dynamics (eDPD), many-body
|
||||
dissipative particle dynamics (mDPD), and transport dissipative particle
|
||||
dynamics (tDPD), respectively.
|
||||
|
||||
@ -11,7 +11,7 @@ Syntax
|
||||
balance thresh style args ... keyword args ...
|
||||
|
||||
* thresh = imbalance threshold that must be exceeded to perform a re-balance
|
||||
* one style/arg pair can be used (or multiple for *x*\ ,\ *y*\ ,\ *z*\ )
|
||||
* one style/arg pair can be used (or multiple for *x*,\ *y*,\ *z*\ )
|
||||
* style = *x* or *y* or *z* or *shift* or *rcb*
|
||||
|
||||
.. parsed-literal::
|
||||
@ -170,10 +170,10 @@ fractions of the box length) are also printed.
|
||||
----------
|
||||
|
||||
The method used to perform a load balance is specified by one of the
|
||||
listed styles (or more in the case of *x*\ ,\ *y*\ ,\ *z*\ ), which are
|
||||
listed styles (or more in the case of *x*,\ *y*,\ *z*\ ), which are
|
||||
described in detail below. There are 2 kinds of styles.
|
||||
|
||||
The *x*\ , *y*\ , *z*\ , and *shift* styles are "grid" methods which
|
||||
The *x*, *y*, *z*, and *shift* styles are "grid" methods which
|
||||
produce a logical 3d grid of processors. They operate by changing the
|
||||
cutting planes (or lines) between processors in 3d (or 2d), to adjust
|
||||
the volume (area in 2d) assigned to each processor, as in the
|
||||
@ -222,7 +222,7 @@ from scratch.
|
||||
|
||||
----------
|
||||
|
||||
The *x*\ , *y*\ , and *z* styles invoke a "grid" method for balancing, as
|
||||
The *x*, *y*, and *z* styles invoke a "grid" method for balancing, as
|
||||
described above. Note that any or all of these 3 styles can be
|
||||
specified together, one after the other, but they cannot be used with
|
||||
any other style. This style adjusts the position of cutting planes
|
||||
@ -263,7 +263,7 @@ once. You should normally only list dimensions where you expect there
|
||||
to be a density variation in the particles.
|
||||
|
||||
Balancing proceeds by adjusting the cutting planes in each of the
|
||||
dimensions listed in *dimstr*\ , one dimension at a time. For a single
|
||||
dimensions listed in *dimstr*, one dimension at a time. For a single
|
||||
dimension, the balancing operation (described below) is iterated on up
|
||||
to *Niter* times. After each dimension finishes, the imbalance factor
|
||||
is re-computed, and the balancing operation halts if the *stopthresh*
|
||||
@ -428,8 +428,8 @@ weights. It assigns the same weight to each particle owned by a
|
||||
processor based on the total computational time spent by that
|
||||
processor. See details below on what time window is used. It uses
|
||||
the same timing information as is used for the :doc:`MPI task timing
|
||||
breakdown <Run_output>`, namely, for sections *Pair*\ , *Bond*\ ,
|
||||
*Kspace*\ , and *Neigh*\ . The time spent in those portions of the
|
||||
breakdown <Run_output>`, namely, for sections *Pair*, *Bond*,
|
||||
*Kspace*, and *Neigh*\ . The time spent in those portions of the
|
||||
timestep are measured for each MPI rank, summed, then divided by the
|
||||
number of particles owned by that processor. I.e. the weight is an
|
||||
effective CPU time/particle averaged over the particles on that
|
||||
@ -455,7 +455,7 @@ are for the entire previous run. For the *fix balance* command the
|
||||
timing data is for only the timesteps since the last balancing
|
||||
operation was performed. If timing information for the required
|
||||
sections is not available, e.g. at the beginning of a run, or when the
|
||||
:doc:`timer <timer>` command is set to either *loop* or *off*\ , a warning
|
||||
:doc:`timer <timer>` command is set to either *loop* or *off*, a warning
|
||||
is issued. In this case no weights are computed.
|
||||
|
||||
.. note::
|
||||
|
||||
@ -55,7 +55,7 @@ Restrictions
|
||||
""""""""""""
|
||||
|
||||
This bond style can only be used if LAMMPS was built with the CLASS2
|
||||
package. See the :doc:`Build package <Build_package>` doc page for more
|
||||
package. See the :doc:`Build package <Build_package>` page for more
|
||||
info.
|
||||
|
||||
Related commands
|
||||
|
||||
@ -58,7 +58,7 @@ Restrictions
|
||||
""""""""""""
|
||||
|
||||
This bond style can only be used if LAMMPS was built with the MOLECULE
|
||||
package. See the :doc:`Build package <Build_package>` doc page for more
|
||||
package. See the :doc:`Build package <Build_package>` page for more
|
||||
info.
|
||||
|
||||
You typically should specify :doc:`special_bonds fene <special_bonds>`
|
||||
|
||||
@ -60,7 +60,7 @@ Restrictions
|
||||
""""""""""""
|
||||
|
||||
This bond style can only be used if LAMMPS was built with the MOLECULE
|
||||
package. See the :doc:`Build package <Build_package>` doc page for more
|
||||
package. See the :doc:`Build package <Build_package>` page for more
|
||||
info.
|
||||
|
||||
You typically should specify :doc:`special_bonds fene <special_bonds>`
|
||||
|
||||
@ -50,7 +50,7 @@ Restrictions
|
||||
""""""""""""
|
||||
|
||||
This bond style can only be used if LAMMPS was built with the
|
||||
USER-MISC package. See the :doc:`Build package <Build_package>` doc
|
||||
MOLECULE package. See the :doc:`Build package <Build_package>` doc
|
||||
page for more info.
|
||||
|
||||
Related commands
|
||||
|
||||
@ -51,7 +51,7 @@ Restrictions
|
||||
""""""""""""
|
||||
|
||||
This bond style can only be used if LAMMPS was built with the MOLECULE
|
||||
package. See the :doc:`Build package <Build_package>` doc page for more
|
||||
package. See the :doc:`Build package <Build_package>` page for more
|
||||
info.
|
||||
|
||||
Related commands
|
||||
|
||||
@ -53,7 +53,7 @@ Restrictions
|
||||
""""""""""""
|
||||
|
||||
This bond style can only be used if LAMMPS was built with the MOLECULE
|
||||
package. See the :doc:`Build package <Build_package>` doc page for more
|
||||
package. See the :doc:`Build package <Build_package>` page for more
|
||||
info.
|
||||
|
||||
Related commands
|
||||
|
||||
@ -56,7 +56,7 @@ Restrictions
|
||||
""""""""""""
|
||||
|
||||
This bond style can only be used if LAMMPS was built with the
|
||||
USER-MISC package. See the :doc:`Build package <Build_package>` doc
|
||||
MOLECULE package. See the :doc:`Build package <Build_package>` doc
|
||||
page for more info.
|
||||
|
||||
Related commands
|
||||
|
||||
@ -54,7 +54,7 @@ Restrictions
|
||||
""""""""""""
|
||||
|
||||
This bond style can only be used if LAMMPS was built with the
|
||||
USER-MISC package. See the :doc:`Build package <Build_package>` doc
|
||||
MOLECULE package. See the :doc:`Build package <Build_package>` doc
|
||||
page for more info.
|
||||
|
||||
Related commands
|
||||
|
||||
@ -64,7 +64,7 @@ Restrictions
|
||||
""""""""""""
|
||||
|
||||
This bond style can only be used if LAMMPS was built with the MOLECULE
|
||||
package. See the :doc:`Build package <Build_package>` doc page for more
|
||||
package. See the :doc:`Build package <Build_package>` page for more
|
||||
info.
|
||||
|
||||
Unlike other bond styles, the hybrid bond style does not store bond
|
||||
|
||||
@ -52,7 +52,7 @@ Restrictions
|
||||
""""""""""""
|
||||
|
||||
This bond style can only be used if LAMMPS was built with the MOLECULE
|
||||
package. See the :doc:`Build package <Build_package>` doc page for more
|
||||
package. See the :doc:`Build package <Build_package>` page for more
|
||||
info.
|
||||
|
||||
Related commands
|
||||
|
||||
@ -51,8 +51,8 @@ or :doc:`read_restart <read_restart>` commands:
|
||||
Restrictions
|
||||
""""""""""""
|
||||
|
||||
This bond style can only be used if LAMMPS was built with the MOLECULE
|
||||
package. See the :doc:`Build package <Build_package>` doc page for more
|
||||
This bond style can only be used if LAMMPS was built with the EXTRA-MOLECULE
|
||||
package. See the :doc:`Build package <Build_package>` page for more
|
||||
info.
|
||||
|
||||
Related commands
|
||||
|
||||
@ -39,7 +39,7 @@ Examples
|
||||
Description
|
||||
"""""""""""
|
||||
|
||||
The *oxdna/fene* , *oxdna2/fene* and *oxrna2/fene* bond styles use the potential
|
||||
The *oxdna/fene*, *oxdna2/fene*, and *oxrna2/fene* bond styles use the potential
|
||||
|
||||
.. math::
|
||||
|
||||
@ -118,7 +118,7 @@ Restrictions
|
||||
|
||||
This bond style can only be used if LAMMPS was built with the
|
||||
CG-DNA package and the MOLECULE and ASPHERE package. See the
|
||||
:doc:`Build package <Build_package>` doc page for more info.
|
||||
:doc:`Build package <Build_package>` page for more info.
|
||||
|
||||
Related commands
|
||||
""""""""""""""""
|
||||
|
||||
@ -96,7 +96,7 @@ Restrictions
|
||||
""""""""""""
|
||||
|
||||
This bond style can only be used if LAMMPS was built with the MOLECULE
|
||||
package. See the :doc:`Build package <Build_package>` doc page for more
|
||||
package. See the :doc:`Build package <Build_package>` page for more
|
||||
info.
|
||||
|
||||
The *quartic* style requires that :doc:`special_bonds <special_bonds>`
|
||||
|
||||
@ -86,7 +86,7 @@ Restrictions
|
||||
""""""""""""
|
||||
|
||||
This bond style can only be used if LAMMPS was built with the
|
||||
USER-MISC package. See the :doc:`Build package <Build_package>` doc
|
||||
MISC package. See the :doc:`Build package <Build_package>` doc
|
||||
page for more info.
|
||||
|
||||
This bond style requires the use of a :doc:`pair_style <pair_style>` which
|
||||
|
||||
@ -111,7 +111,7 @@ Bond styles can only be set for atom styles that allow bonds to be
|
||||
defined.
|
||||
|
||||
Most bond styles are part of the MOLECULE package. They are only
|
||||
enabled if LAMMPS was built with that package. See the :doc:`Build package <Build_package>` doc page for more info. The doc pages for
|
||||
enabled if LAMMPS was built with that package. See the :doc:`Build package <Build_package>` page for more info. The doc pages for
|
||||
individual bond potentials tell if it is part of a package.
|
||||
|
||||
Related commands
|
||||
|
||||
@ -143,7 +143,7 @@ Restrictions
|
||||
""""""""""""
|
||||
|
||||
This bond style can only be used if LAMMPS was built with the MOLECULE
|
||||
package. See the :doc:`Build package <Build_package>` doc page for more
|
||||
package. See the :doc:`Build package <Build_package>` page for more
|
||||
info.
|
||||
|
||||
Related commands
|
||||
|
||||
@ -10,7 +10,7 @@ Syntax
|
||||
|
||||
boundary x y z
|
||||
|
||||
* x,y,z = *p* or *s* or *f* or *m*\ , one or two letters
|
||||
* x,y,z = *p* or *s* or *f* or *m*, one or two letters
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
@ -45,17 +45,17 @@ 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.
|
||||
|
||||
The styles *f*\ , *s*\ , and *m* mean the box is non-periodic, so that
|
||||
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
|
||||
side of the box to the other.
|
||||
|
||||
For style *f*\ , the position of the face is fixed. If an atom moves
|
||||
For style *f*, the position of the face is fixed. If an atom moves
|
||||
outside the face it will be deleted on the next timestep that
|
||||
reneighboring occurs. This will typically generate an error unless
|
||||
you have set the :doc:`thermo_modify lost <thermo_modify>` option to
|
||||
allow for lost atoms.
|
||||
|
||||
For style *s*\ , the position of the face is set so as to encompass the
|
||||
For style *s*, the position of the face is set so as to encompass the
|
||||
atoms in that dimension (shrink-wrapping), no matter how far they
|
||||
move. Note that when the difference between the current box dimensions
|
||||
and the shrink-wrap box dimensions is large, this can lead to lost
|
||||
@ -67,7 +67,7 @@ This is best addressed by setting initial box dimensions to match the
|
||||
shrink-wrapped dimensions more closely, by using *m* style boundaries
|
||||
(see below).
|
||||
|
||||
For style *m*\ , shrink-wrapping occurs, but is bounded by the value
|
||||
For style *m*, shrink-wrapping occurs, but is bounded by the value
|
||||
specified in the data or restart file or set by the
|
||||
:doc:`create_box <create_box>` command. For example, if the upper z
|
||||
face has a value of 50.0 in the data file, the face will always be
|
||||
@ -85,7 +85,7 @@ 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.
|
||||
|
||||
See the :doc:`Howto triclinic <Howto_triclinic>` doc page for a
|
||||
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.
|
||||
|
||||
@ -34,15 +34,15 @@ For triclinic (non-orthogonal) simulation boxes, the *tilt* keyword
|
||||
allows simulation domains to be created with arbitrary tilt factors,
|
||||
e.g. via the :doc:`create_box <create_box>` or
|
||||
:doc:`read_data <read_data>` commands. Tilt factors determine how
|
||||
skewed the triclinic box is; see the :doc:`Howto triclinic <Howto_triclinic>` doc page for a discussion of triclinic
|
||||
skewed the triclinic box is; see the :doc:`Howto triclinic <Howto_triclinic>` page for a discussion of triclinic
|
||||
boxes in LAMMPS.
|
||||
|
||||
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). If *tilt* is set to
|
||||
*small*\ , which is the default, then an error will be
|
||||
*small*, which is the default, then an error will be
|
||||
generated if a box is created which exceeds this limit. If *tilt*
|
||||
is set to *large*\ , then no limit is enforced. You can create
|
||||
is set to *large*, then no limit is enforced. You can create
|
||||
a box with any tilt factors you wish.
|
||||
|
||||
Note that if a simulation box has a large tilt factor, LAMMPS will run
|
||||
|
||||
@ -16,7 +16,7 @@ Syntax
|
||||
.. parsed-literal::
|
||||
|
||||
parameter = *x* or *y* or *z* or *xy* or *xz* or *yz* or *boundary* or *ortho* or *triclinic* or *set* or *remap*
|
||||
*x*\ , *y*\ , *z* args = style value(s)
|
||||
*x*, *y*, *z* args = style value(s)
|
||||
style = *final* or *delta* or *scale* or *volume*
|
||||
*final* values = lo hi
|
||||
lo hi = box boundaries after displacement (distance units)
|
||||
@ -25,14 +25,14 @@ Syntax
|
||||
*scale* values = factor
|
||||
factor = multiplicative factor for change in box length after displacement
|
||||
*volume* value = none = adjust this dim to preserve volume of system
|
||||
*xy*\ , *xz*\ , *yz* args = style value
|
||||
*xy*, *xz*, *yz* args = style value
|
||||
style = *final* or *delta*
|
||||
*final* value = tilt
|
||||
tilt = tilt factor after displacement (distance units)
|
||||
*delta* value = dtilt
|
||||
dtilt = change in tilt factor after displacement (distance units)
|
||||
*boundary* args = x y z
|
||||
x,y,z = *p* or *s* or *f* or *m*\ , one or two letters
|
||||
x,y,z = *p* or *s* or *f* or *m*, one or two letters
|
||||
*p* is periodic
|
||||
*f* is non-periodic and fixed
|
||||
*s* is non-periodic and shrink-wrapped
|
||||
@ -82,7 +82,7 @@ The :doc:`create_box <create_box>`, :doc:`read data <read_data>`, and
|
||||
simulation box is orthogonal or triclinic and their doc pages explain
|
||||
the meaning of the xy,xz,yz tilt factors.
|
||||
|
||||
See the :doc:`Howto triclinic <Howto_triclinic>` doc page for a
|
||||
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.
|
||||
@ -179,18 +179,18 @@ new owning processors.
|
||||
|
||||
----------
|
||||
|
||||
For the *x*\ , *y*\ , and *z* parameters, this is the meaning of their
|
||||
For the *x*, *y*, and *z* parameters, this is the meaning of their
|
||||
styles and values.
|
||||
|
||||
For style *final*\ , the final lo and hi box boundaries of a dimension
|
||||
For style *final*, the final lo and hi box boundaries of a dimension
|
||||
are specified. The values can be in lattice or box distance units.
|
||||
See the discussion of the units keyword below.
|
||||
|
||||
For style *delta*\ , plus or minus changes in the lo/hi box boundaries
|
||||
For style *delta*, plus or minus changes in the lo/hi box boundaries
|
||||
of a dimension are specified. The values can be in lattice or box
|
||||
distance units. See the discussion of the units keyword below.
|
||||
|
||||
For style *scale*\ , a multiplicative factor to apply to the box length
|
||||
For style *scale*, a multiplicative factor to apply to the box length
|
||||
of a dimension is specified. For example, if the initial box length
|
||||
is 10, and the factor is 1.1, then the final box length will be 11. A
|
||||
factor less than 1.0 means compression.
|
||||
@ -199,7 +199,7 @@ The *volume* style changes the specified dimension in such a way that
|
||||
the overall box volume remains constant with respect to the operation
|
||||
performed by the preceding keyword. The *volume* style can only be
|
||||
used following a keyword that changed the volume, which is any of the
|
||||
*x*\ , *y*\ , *z* keywords. If the preceding keyword "key" had a *volume*
|
||||
*x*, *y*, *z* keywords. If the preceding keyword "key" had a *volume*
|
||||
style, then both it and the current keyword apply to the keyword
|
||||
preceding "key". I.e. this sequence of keywords is allowed:
|
||||
|
||||
@ -249,15 +249,15 @@ compressed around its mid point.
|
||||
|
||||
----------
|
||||
|
||||
For the *xy*\ , *xz*\ , and *yz* parameters, this is the meaning of their
|
||||
For the *xy*, *xz*, and *yz* parameters, this is the meaning of their
|
||||
styles and values. Note that changing the tilt factors of a triclinic
|
||||
box does not change its volume.
|
||||
|
||||
For style *final*\ , the final tilt factor is specified. The value
|
||||
For style *final*, the final tilt factor is specified. The value
|
||||
can be in lattice or box distance units. See the discussion of the
|
||||
units keyword below.
|
||||
|
||||
For style *delta*\ , a plus or minus change in the tilt factor is
|
||||
For style *delta*, a plus or minus change in the tilt factor is
|
||||
specified. The value can be in lattice or box distance units. See
|
||||
the discussion of the units keyword below.
|
||||
|
||||
@ -281,10 +281,10 @@ and upper face of the box. Two letters assigns the first style to the
|
||||
lower face and the second style to the upper face.
|
||||
|
||||
The style *p* means the box is periodic; the other styles mean
|
||||
non-periodic. For style *f*\ , the position of the face is fixed. For
|
||||
style *s*\ , the position of the face is set so as to encompass the
|
||||
non-periodic. For style *f*, the position of the face is fixed. For
|
||||
style *s*, the position of the face is set so as to encompass the
|
||||
atoms in that dimension (shrink-wrapping), no matter how far they
|
||||
move. For style *m*\ , shrink-wrapping occurs, but is bounded by the
|
||||
move. For style *m*, shrink-wrapping occurs, but is bounded by the
|
||||
current box edge in that dimension, so that the box will become no
|
||||
smaller. See the :doc:`boundary <boundary>` command for more
|
||||
explanation of these style options.
|
||||
|
||||
@ -80,7 +80,7 @@ with the *multi* neighbor style. The *multi/old* communication mode is comparabl
|
||||
with both the *multi* and *multi/old* neighbor styles.
|
||||
|
||||
The *cutoff* keyword allows you to extend the ghost cutoff distance
|
||||
for communication mode *single*\ , which is the distance from the borders
|
||||
for communication mode *single*, which is the distance from the borders
|
||||
of a processor's sub-domain at which ghost atoms are acquired from other
|
||||
processors. By default the ghost cutoff = neighbor cutoff = pairwise
|
||||
force cutoff + neighbor skin. See the :doc:`neighbor <neighbor>` command
|
||||
@ -96,7 +96,7 @@ style present and no *comm_modify cutoff* command used. Otherwise a
|
||||
warning is printed, if this bond based estimate is larger than the
|
||||
communication cutoff used.
|
||||
|
||||
The *cutoff/multi* option is equivalent to *cutoff*\ , but applies to
|
||||
The *cutoff/multi* option is equivalent to *cutoff*, but applies to
|
||||
communication mode *multi* instead. Since the communication cutoffs are
|
||||
determined per atom collections, a collection specifier is needed and
|
||||
cutoff for one or multiple collections can be extended. Also ranges of
|
||||
@ -132,9 +132,9 @@ different processors, or when the interaction straddles a periodic
|
||||
boundary.
|
||||
|
||||
The appropriate ghost cutoff depends on the :doc:`newton bond <newton>`
|
||||
setting. For newton bond *off*\ , the distance needs to be the furthest
|
||||
setting. For newton bond *off*, the distance needs to be the furthest
|
||||
distance between any two atoms in the bond, angle, etc. E.g. the
|
||||
distance between 1-4 atoms in a dihedral. For newton bond *on*\ , the
|
||||
distance between 1-4 atoms in a dihedral. For newton bond *on*, the
|
||||
distance between the central atom in the bond, angle, etc and any
|
||||
other atom is sufficient. E.g. the distance between 2-4 atoms in a
|
||||
dihedral.
|
||||
@ -173,7 +173,7 @@ The *vel* keyword enables velocity information to be communicated with
|
||||
ghost particles. Depending on the :doc:`atom_style <atom_style>`,
|
||||
velocity info includes the translational velocity, angular velocity,
|
||||
and angular momentum of a particle. If the *vel* option is set to
|
||||
*yes*\ , then ghost atoms store these quantities; if *no* then they do
|
||||
*yes*, then ghost atoms store these quantities; if *no* then they do
|
||||
not. The *yes* setting is needed by some pair styles which require
|
||||
the velocity state of both the I and J particles to compute a pairwise
|
||||
I,J interaction, as well as by some compute and fix commands.
|
||||
|
||||
@ -35,7 +35,7 @@ information about a previous state of the system. Defining a compute
|
||||
does not perform a computation. Instead computes are invoked by other
|
||||
LAMMPS commands as needed, e.g. to calculate a temperature needed for
|
||||
a thermostat fix or to generate thermodynamic or dump file output.
|
||||
See the :doc:`Howto output <Howto_output>` doc page for a summary of
|
||||
See the :doc:`Howto output <Howto_output>` page for a summary of
|
||||
various LAMMPS output options, many of which involve computes.
|
||||
|
||||
The ID of a compute can only contain alphanumeric characters and
|
||||
@ -59,7 +59,7 @@ style produce global quantities.
|
||||
Note that a single compute can produce either global or per-atom or
|
||||
local quantities, but not both global and per-atom. It can produce
|
||||
local quantities in tandem with global or per-atom quantities. The
|
||||
compute doc page will explain.
|
||||
compute page will explain.
|
||||
|
||||
Global, per-atom, and local quantities each come in three kinds: a
|
||||
single scalar value, a vector of values, or a 2d array of values. The
|
||||
@ -119,7 +119,7 @@ values by the number of atoms in the system, depending on the
|
||||
"thermo_modify norm" setting. It will not normalize intensive values.
|
||||
If a compute value is accessed in another way, e.g. by a
|
||||
:doc:`variable <variable>`, you may want to know whether it is an
|
||||
intensive or extensive value. See the doc page for individual
|
||||
intensive or extensive value. See the page for individual
|
||||
computes for further info.
|
||||
|
||||
----------
|
||||
@ -153,19 +153,19 @@ via the :doc:`compute_modify <compute_modify>` command.
|
||||
Computes can be deleted with the :doc:`uncompute <uncompute>` command.
|
||||
|
||||
Code for new computes can be added to LAMMPS; see the
|
||||
:doc:`Modify <Modify>` doc page for details. The results of their
|
||||
:doc:`Modify <Modify>` page for details. The results of their
|
||||
calculations accessed in the various ways described above.
|
||||
|
||||
----------
|
||||
|
||||
Each compute style has its own doc page which describes its arguments
|
||||
Each compute style has its own page which describes its arguments
|
||||
and what it does. Here is an alphabetic list of compute styles
|
||||
available in LAMMPS. They are also listed in more compact form on the
|
||||
:doc:`Commands compute <Commands_compute>` doc page.
|
||||
|
||||
There are also additional accelerated compute styles included in the
|
||||
LAMMPS distribution for faster performance on CPUs, GPUs, and KNLs.
|
||||
The individual style names on the :doc:`Commands compute <Commands_compute>` doc page are followed by one or more of
|
||||
The individual style names on the :doc:`Commands compute <Commands_compute>` page are followed by one or more of
|
||||
(g,i,k,o,t) to indicate which accelerated styles exist.
|
||||
|
||||
* :doc:`ackland/atom <compute_ackland_atom>` - determines the local lattice structure based on the Ackland formulation
|
||||
|
||||
@ -63,14 +63,14 @@ Output info
|
||||
|
||||
This compute calculates a per-atom vector, which can be accessed by
|
||||
any command that uses per-atom values from a compute as input. See
|
||||
the :doc:`Howto output <Howto_output>` doc page for an overview of
|
||||
the :doc:`Howto output <Howto_output>` page for an overview of
|
||||
LAMMPS output options.
|
||||
|
||||
Restrictions
|
||||
""""""""""""
|
||||
|
||||
This compute is part of the USER-MISC package. It is only enabled if
|
||||
LAMMPS was built with that package. See the :doc:`Build package <Build_package>` doc page for more info.
|
||||
This compute is part of the EXTRA-COMPUTE package. It is only enabled if
|
||||
LAMMPS was built with that package. See the :doc:`Build package <Build_package>` page for more info.
|
||||
|
||||
The per-atom vector values will be unitless since they are the
|
||||
integers defined above.
|
||||
|
||||
@ -62,7 +62,7 @@ neighbor atom in each requested ADF.
|
||||
command, and means those pairwise interactions do not appear in the
|
||||
neighbor list. Because this fix uses a neighbor list, it also means
|
||||
those pairs will not be included in the ADF. This does not apply when
|
||||
using long-range coulomb interactions (\ *coul/long*\ , *coul/msm*\ ,
|
||||
using long-range coulomb interactions (\ *coul/long*, *coul/msm*,
|
||||
*coul/wolf* or similar. One way to get around this would be to set
|
||||
special_bond scaling factors to very tiny numbers that are not exactly
|
||||
zero (e.g. 1.0e-50). Another workaround is to write a dump file, and
|
||||
@ -81,7 +81,7 @@ neighbor atom in each requested ADF.
|
||||
cannot be performed, and LAMMPS will give an error message. The *skin* value
|
||||
is what is specified with the :doc:`neighbor <neighbor>` command.
|
||||
|
||||
The *itypeN*\ ,\ *jtypeN*\ ,\ *ktypeN* settings can be specified in one of two
|
||||
The *itypeN*,\ *jtypeN*,\ *ktypeN* settings can be specified in one of two
|
||||
ways. An explicit numeric value can be used, as in the first example
|
||||
above. Or a wild-card asterisk can be used to specify a range of atom
|
||||
types as in the second example above.
|
||||
@ -92,10 +92,10 @@ all types from 1 to N. A leading asterisk means all types from 1 to n
|
||||
(inclusive). A middle asterisk means all types from m to n
|
||||
(inclusive).
|
||||
|
||||
If *itypeN*\ , *jtypeN*\ , and *ktypeN* are single values, as in the first example
|
||||
If *itypeN*, *jtypeN*, and *ktypeN* are single values, as in the first example
|
||||
above, this means that the ADF is computed where atoms of type *itypeN*
|
||||
are the central atom, and neighbor atoms of type *jtypeN* and *ktypeN*
|
||||
are forming the angle. If any of *itypeN*\ , *jtypeN*\ , or *ktypeN*
|
||||
are forming the angle. If any of *itypeN*, *jtypeN*, or *ktypeN*
|
||||
represent a range of values via
|
||||
the wild-card asterisk, as in the second example above, this means that the
|
||||
ADF is computed where atoms of any of the range of types represented
|
||||
@ -103,7 +103,7 @@ by *itypeN* are the central atom, and the angle is formed by two neighbors,
|
||||
one neighbor in the range of types represented by *jtypeN* and another neighbor
|
||||
in the range of types represented by *ktypeN*\ .
|
||||
|
||||
If no *itypeN*\ , *jtypeN*\ , *ktypeN* settings are specified, then
|
||||
If no *itypeN*, *jtypeN*, *ktypeN* settings are specified, then
|
||||
LAMMPS will generate a single ADF for all atoms in the group.
|
||||
The inner cutoff is set to zero and the outer cutoff is set
|
||||
to the force cutoff. If no pair_style is specified, there is no
|
||||
@ -135,7 +135,7 @@ Each unique angle satisfying the above criteria is counted only once, regardless
|
||||
of whether either or both of the neighbor atoms making up the
|
||||
angle appear in both the J and K lists.
|
||||
It is OK if a particular angle is included in more than
|
||||
one individual histogram, due to the way the *itypeN*\ , *jtypeN*\ , *ktypeN*
|
||||
one individual histogram, due to the way the *itypeN*, *jtypeN*, *ktypeN*
|
||||
arguments are specified.
|
||||
|
||||
The first ADF value for a bin is calculated from the histogram count by
|
||||
@ -177,13 +177,13 @@ Output info
|
||||
"""""""""""
|
||||
|
||||
This compute calculates a global array with the number of rows =
|
||||
*Nbins*\ , and the number of columns = 1 + 2\*Ntriples, where Ntriples is the
|
||||
*Nbins*, and the number of columns = 1 + 2\*Ntriples, where Ntriples is the
|
||||
number of I,J,K triples specified. The first column has the bin
|
||||
coordinate (angle-related ordinate at midpoint of bin). Each subsequent column has
|
||||
the two ADF values for a specific set of (\ *itypeN*\ ,\ *jtypeN*\ ,\ *ktypeN*\ )
|
||||
the two ADF values for a specific set of (\ *itypeN*,\ *jtypeN*,\ *ktypeN*\ )
|
||||
interactions, as described above. These values can be used
|
||||
by any command that uses a global values from a compute as input. See
|
||||
the :doc:`Howto output <Howto_output>` doc page for an overview of
|
||||
the :doc:`Howto output <Howto_output>` page for an overview of
|
||||
LAMMPS output options.
|
||||
|
||||
The array values calculated by this compute are all "intensive".
|
||||
@ -191,7 +191,7 @@ The array values calculated by this compute are all "intensive".
|
||||
The first column of array values is the angle-related ordinate, either
|
||||
the angle in degrees or radians, or the cosine of the angle. Each
|
||||
subsequent pair of columns gives the first and second kinds of ADF
|
||||
for a specific set of (\ *itypeN*\ ,\ *jtypeN*\ ,\ *ktypeN*\ ). The values
|
||||
for a specific set of (\ *itypeN*,\ *jtypeN*,\ *ktypeN*\ ). The values
|
||||
in the first ADF column are normalized numbers >= 0.0,
|
||||
whose integral w.r.t. the ordinate is 1,
|
||||
i.e. the first ADF is a normalized probability distribution.
|
||||
@ -204,6 +204,9 @@ angles per atom satisfying the ADF criteria.
|
||||
Restrictions
|
||||
""""""""""""
|
||||
|
||||
This compute is part of the EXTRA-COMPUTE package. It is only enabled if
|
||||
LAMMPS was built with that package. See the :doc:`Build package <Build_package>` page for more info.
|
||||
|
||||
The ADF is not computed for neighbors outside the force cutoff,
|
||||
since processors (in parallel) don't know about atom coordinates for
|
||||
atoms further away than that distance. If you want an ADF for larger
|
||||
|
||||
@ -38,7 +38,7 @@ Output info
|
||||
This compute calculates a global vector of length N where N is the
|
||||
number of sub_styles defined by the :doc:`angle_style hybrid <angle_style>` command, which can be accessed by indices
|
||||
1-N. These values can be used by any command that uses global scalar
|
||||
or vector values from a compute as input. See the :doc:`Howto output <Howto_output>` doc page for an overview of LAMMPS output
|
||||
or vector values from a compute as input. See the :doc:`Howto output <Howto_output>` page for an overview of LAMMPS output
|
||||
options.
|
||||
|
||||
The vector values are "extensive" and will be in energy
|
||||
|
||||
@ -128,7 +128,7 @@ array is the number of angles. If a single value is specified, a
|
||||
local vector is produced. If two or more values are specified, a
|
||||
local array is produced where the number of columns = the number of
|
||||
values. The vector or array can be accessed by any command that uses
|
||||
local values from a compute as input. See the :doc:`Howto output <Howto_output>` doc page for an overview of LAMMPS output
|
||||
local values from a compute as input. See the :doc:`Howto output <Howto_output>` page for an overview of LAMMPS output
|
||||
options.
|
||||
|
||||
The output for *theta* will be in degrees. The output for *eng* will
|
||||
|
||||
@ -75,7 +75,7 @@ This compute calculates a global array where the number of rows = the
|
||||
number of chunks *Nchunk* as calculated by the specified :doc:`compute chunk/atom <compute_chunk_atom>` command. The number of columns =
|
||||
3 for the 3 xyz components of the angular momentum for each chunk.
|
||||
These values can be accessed by any command that uses global array
|
||||
values from a compute as input. See the :doc:`Howto output <Howto_output>` doc page for an overview of LAMMPS output
|
||||
values from a compute as input. See the :doc:`Howto output <Howto_output>` page for an overview of LAMMPS output
|
||||
options.
|
||||
|
||||
The array values are "intensive". The array values will be in
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user