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

Merge branch 'develop' into BPM

Browse Source
This commit is contained in:
jtclemm
2022-01-12 10:52:11 -07:00
committed by GitHub
parent 744e615dbb 878557dd48
commit 19abc5d329
884 changed files with 39864 additions and 18216 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
doc/src/Bibliography.rst
View File

@ -1123,9 +1123,12 @@ Bibliography
**(Sun)**
Sun, J. Phys. Chem. B, 102, 7338-7364 (1998).
**(Surblys)**
**(Surblys2019)**
Surblys, Matsubara, Kikugawa, Ohara, Phys Rev E, 99, 051301(R) (2019).
**(Surblys2021)**
Surblys, Matsubara, Kikugawa, Ohara, J Appl Phys 130, 215104 (2021).
**(Sutmann)**
Sutmann, Arnold, Fahrenberger, et. al., Physical review / E 88(6), 063308 (2013)

36
doc/src/Build_cmake.rst
View File

@ -150,6 +150,42 @@ for IDEs like Eclipse, CodeBlocks, or Kate can be selected using the *-G*
command line flag. A list of available generator settings for your
specific CMake version is given when running ``cmake --help``.
.. _cmake_multiconfig:
Multi-configuration build systems
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Throughout this manual it is mostly assumed that LAMMPS is being built
on a Unix-like operating system with "make" as the underlying "builder",
since this is the most common case. In this case the build "configuration"
is chose using ``-D CMAKE_BUILD_TYPE=<configuration>`` with ``<configuration>``
being one of "Release", "Debug", "RelWithDebInfo", or "MinSizeRel".
Some build tools, however, can also use or even require to have a so-called
multi-configuration build system setup. For those the built type (or
configuration) is chosen at compile time using the same build files. E.g.
with:
.. code-block:: bash
cmake --build build-multi --config Release
In that case the resulting binaries are not in the build folder directly
but in sub-directories corresponding to the build type (i.e. Release in
the example from above). Similarly, for running unit tests the
configuration is selected with the *-C* flag:
.. code-block:: bash
ctest -C Debug
The CMake scripts in LAMMPS have basic support for being compiled using a
multi-config build system, but not all of it has been ported. This is in
particular applicable to compiling packages that require additional libraries
that would be downloaded and compiled by CMake. The "windows" preset file
tries to keep track of which packages can be compiled natively with the
MSVC compilers out-of-the box. Not all of those external libraries are
portable to Windows either.
Installing CMake
^^^^^^^^^^^^^^^^

10
doc/src/Build_development.rst
View File

@ -185,6 +185,10 @@ The ``ctest`` command has many options, the most important ones are:
- run subset of tests matching the regular expression <regex>
* - -E <regex>
- exclude subset of tests matching the regular expression <regex>
* - -L <regex>
- run subset of tests with a label matching the regular expression <regex>
* - -LE <regex>
- exclude subset of tests with a label matching the regular expression <regex>
* - -N
- dry-run: display list of tests without running them
* - -T memcheck
@ -299,6 +303,12 @@ will destroy the original file, if the generation run does not complete,
so using *-g* is recommended unless the YAML file is fully tested
and working.
Some of the force style tests are rather slow to run and some are very
sensitive to small differences like CPU architecture, compiler
toolchain, compiler optimization. Those tests are flagged with a "slow"
and/or "unstable" label, and thus those tests can be selectively
excluded with the ``-LE`` flag or selected with the ``-L`` flag.
.. admonition:: Recommendations and notes for YAML files
:class: note

33
doc/src/Build_extras.rst
View File

@ -341,6 +341,18 @@ minutes to hours) to build. Of course you only need to do that once.)
$ make lib-kim args="-p /usr/local" # use an existing KIM API installation at the provided location
$ make lib-kim args="-p /usr/local -a EAM_Dynamo_Ackland_W__MO_141627196590_002" # ditto but add one model or driver
When using the "-b " option, the KIM library is built using its native
cmake build system. The ``lib/kim/Install.py`` script supports a
``CMAKE`` environment variable if the cmake executable is named other
than ``cmake`` on your system. Additional environment variables may be
provided on the command line for use by cmake. For example, to use the
``cmake3`` executable and tell it to use the gnu version 11 compilers
to build KIM, one could use the following command line.
.. code-block:: bash
$ CMAKE=cmake3 CXX=g++-11 CC=gcc-11 FC=gfortran-11 make lib-kim args="-b " # (re-)install KIM API lib using cmake3 and gnu v11 compilers with only example models
Settings for debugging OpenKIM web queries discussed below need to
be applied by adding them to the ``LMP_INC`` variable through
editing the ``Makefile.machine`` you are using. For example:
@ -560,11 +572,26 @@ They must be specified in uppercase.
* - VEGA908
- GPU
- AMD GPU MI100 GFX908
* - INTEL_GEN
* - VEGA90A
- GPU
- Intel GPUs Gen9+
- AMD GPU
* - INTEL_DG1
- GPU
- Intel Iris XeMAX GPU
* - INTEL_GEN9
- GPU
- Intel GPU Gen9
* - INTEL_GEN11
- GPU
- Intel GPU Gen11
* - INTEL_GEN12LP
- GPU
- Intel GPU Gen12LP
* - INTEL_XEHP
- GPU
- Intel GPUs Xe-HP
This list was last updated for version 3.4.1 of the Kokkos library.
This list was last updated for version 3.5.0 of the Kokkos library.
.. tabs::

5
doc/src/Build_windows.rst
View File

@ -89,6 +89,11 @@ miss the correct master ``CMakeLists.txt``. Try to open the
starting point. It is also possible to configure and compile LAMMPS
from the command line with a CMake binary from `cmake.org <https://cmake.org>`_.
Please note, that for either approach CMake will create a so-called
:ref:`"multi-configuration" build environment <cmake_multiconfig>`, and
the command lines for building and testing LAMMPS must be adjusted
accordingly.
To support running in parallel you can compile with OpenMP enabled using
the OPENMP package or install Microsoft MPI (including the SDK) and compile
LAMMPS with MPI enabled.

1
doc/src/Commands_bond.rst
View File

@ -37,6 +37,7 @@ OPT.
* :doc:`class2 (ko) <bond_class2>`
* :doc:`fene (iko) <bond_fene>`
* :doc:`fene/expand (o) <bond_fene_expand>`
* :doc:`fene/nm <bond_fene>`
* :doc:`gaussian <bond_gaussian>`
* :doc:`gromos (o) <bond_gromos>`
* :doc:`harmonic (iko) <bond_harmonic>`

1
doc/src/Commands_compute.rst
View File

@ -28,6 +28,7 @@ KOKKOS, o = OPENMP, t = OPT.
* :doc:`angle <compute_angle>`
* :doc:`angle/local <compute_angle_local>`
* :doc:`angmom/chunk <compute_angmom_chunk>`
* :doc:`ave/sphere/atom (k) <compute_ave_sphere_atom>`
* :doc:`basal/atom <compute_basal_atom>`
* :doc:`body/local <compute_body_local>`
* :doc:`bond <compute_bond>`

2
doc/src/Commands_pair.rst
View File

@ -210,6 +210,7 @@ OPT.
* :doc:`nm/cut (o) <pair_nm>`
* :doc:`nm/cut/coul/cut (o) <pair_nm>`
* :doc:`nm/cut/coul/long (o) <pair_nm>`
* :doc:`nm/cut/split <pair_nm>`
* :doc:`oxdna/coaxstk <pair_oxdna>`
* :doc:`oxdna/excv <pair_oxdna>`
* :doc:`oxdna/hbond <pair_oxdna>`
@ -262,6 +263,7 @@ OPT.
* :doc:`spin/neel <pair_spin_neel>`
* :doc:`srp <pair_srp>`
* :doc:`sw (giko) <pair_sw>`
* :doc:`sw/mod (o) <pair_sw>`
* :doc:`table (gko) <pair_table>`
* :doc:`table/rx (k) <pair_table_rx>`
* :doc:`tdpd <pair_mesodpd>`

3
doc/src/Developer_platform.rst
View File

@ -118,6 +118,9 @@ Environment variable functions
.. doxygenfunction:: putenv
:project: progguide
.. doxygenfunction:: unsetenv
:project: progguide
.. doxygenfunction:: list_pathenv
:project: progguide

31
doc/src/Developer_utils.rst
View File

@ -56,11 +56,11 @@ String to number conversions with validity check
These functions should be used to convert strings to numbers. They are
are strongly preferred over C library calls like ``atoi()`` or
``atof()`` since they check if the **entire** provided string is a valid
``atof()`` since they check if the **entire** string is a valid
(floating-point or integer) number, and will error out instead of
silently returning the result of a partial conversion or zero in cases
where the string is not a valid number. This behavior allows to more
easily detect typos or issues when processing input files.
where the string is not a valid number. This behavior improves
detecting typos or issues when processing input files.
Similarly the :cpp:func:`logical() <LAMMPS_NS::utils::logical>` function
will convert a string into a boolean and will only accept certain words.
@ -76,19 +76,34 @@ strings for compliance without conversion.
----------
.. doxygenfunction:: numeric
.. doxygenfunction:: numeric(const char *file, int line, const std::string &str, bool do_abort, LAMMPS *lmp)
:project: progguide
.. doxygenfunction:: inumeric
.. doxygenfunction:: numeric(const char *file, int line, const char *str, bool do_abort, LAMMPS *lmp)
:project: progguide
.. doxygenfunction:: bnumeric
.. doxygenfunction:: inumeric(const char *file, int line, const std::string &str, bool do_abort, LAMMPS *lmp)
:project: progguide
.. doxygenfunction:: tnumeric
.. doxygenfunction:: inumeric(const char *file, int line, const char *str, bool do_abort, LAMMPS *lmp)
:project: progguide
.. doxygenfunction:: logical
.. doxygenfunction:: bnumeric(const char *file, int line, const std::string &str, bool do_abort, LAMMPS *lmp)
:project: progguide
.. doxygenfunction:: bnumeric(const char *file, int line, const char *str, bool do_abort, LAMMPS *lmp)
:project: progguide
.. doxygenfunction:: tnumeric(const char *file, int line, const std::string &str, bool do_abort, LAMMPS *lmp)
:project: progguide
.. doxygenfunction:: tnumeric(const char *file, int line, const char *str, bool do_abort, LAMMPS *lmp)
:project: progguide
.. doxygenfunction:: logical(const char *file, int line, const std::string &str, bool do_abort, LAMMPS *lmp)
:project: progguide
.. doxygenfunction:: logical(const char *file, int line, const char *str, bool do_abort, LAMMPS *lmp)
:project: progguide

2
doc/src/Developer_write.rst
View File

@ -55,7 +55,7 @@ of each timestep. First of all, implement a constructor:
if (narg < 4)
error->all(FLERR,"Illegal fix print/vel command");
nevery = force->inumeric(FLERR,arg[3]);
nevery = utils::inumeric(FLERR,arg[3],false,lmp);
if (nevery <= 0)
error->all(FLERR,"Illegal fix print/vel command");
}

3
doc/src/Errors_messages.rst
View File

@ -7772,9 +7772,6 @@ keyword to allow for additional bonds to be formed
The system size must fit in a 32-bit integer to use this dump
style.
*Too many atoms to dump sort*
Cannot sort when running with more than 2\^31 atoms.
*Too many elements extracted from MEAM library.*
Increase 'maxelt' in meam.h and recompile.

5
doc/src/Howto_drude2.rst
View File

@ -491,11 +491,6 @@ NPT ensemble using Nose-Hoover thermostat:
**(Schroeder)** Schroeder and Steinhauser, J Chem Phys, 133,
154511 (2010).
.. _Jiang2:
**(Jiang)** Jiang, Hardy, Phillips, MacKerell, Schulten, and Roux,
J Phys Chem Lett, 2, 87-92 (2011).
.. _Thole2:
**(Thole)** Chem Phys, 59, 341 (1981).

3
doc/src/Howto_github.rst
View File

@ -141,7 +141,8 @@ unrelated feature, you should switch branches!
Committing changes to the *develop*, *release*, or *stable* branches
is strongly discouraged. While it may be convenient initially, it
will create more work in the long run. Various texts and tutorials
on using git effectively discuss the motivation for this.
on using git effectively discuss the motivation for using feature
branches instead.
**After changes are made**

35
doc/src/Install_git.rst
View File

@ -28,8 +28,9 @@ provides `limited support for subversion clients <svn_>`_.
You can follow the LAMMPS development on 3 different git branches:
* **stable** : this branch is updated with every stable release;
updates are always "fast forward" merges from *develop*
* **stable** : this branch is updated from the *release* branch with
every stable release version and also has selected bug fixes and updates
back-ported from the *develop* branch
* **release** : this branch is updated with every patch release;
updates are always "fast forward" merges from *develop*
* **develop** : this branch follows the ongoing development and
@ -47,20 +48,22 @@ your machine and "release" is one of the 3 branches listed above.
(Note that you actually download all 3 branches; you can switch
between them at any time using "git checkout <branch name>".)
.. note::
.. admonition:: Saving time and disk space when using ``git clone``
The complete git history of the LAMMPS project is quite large because
it contains the entire commit history of the project since fall 2006,
which includes the time when LAMMPS was managed with subversion. This
also includes commits that have added and removed some large files
(mostly by accident). If you do not need access to the entire commit
history, you can speed up the "cloning" process and reduce local disk
space requirements by using the *--depth* git command line flag thus
create a "shallow clone" of the repository that contains only a
subset of the git history. Using a depth of 1000 is usually sufficient
to include the head commits of the *develop* and the *release* branches.
To include the head commit of the *stable* branch you may need a depth
of up to 10000.
which includes the time when LAMMPS was managed with subversion.
This includes a few commits that have added and removed some large
files (mostly by accident). If you do not need access to the entire
commit history (most people don't), you can speed up the "cloning"
process and reduce local disk space requirements by using the
*--depth* git command line flag. That will create a "shallow clone"
of the repository containing only a subset of the git history. Using
a depth of 1000 is usually sufficient to include the head commits of
the *develop* and the *release* branches. To include the head commit
of the *stable* branch you may need a depth of up to 10000. If you
later need more of the git history, you can always convert the
shallow clone into a "full clone".
Once the command completes, your directory will contain the same files
as if you unpacked a current LAMMPS tarball, with the exception, that
@ -156,9 +159,9 @@ changed. How to do this depends on the build system you are using.
.. admonition:: Git protocols
:class: note
The servers at github.com support the "git://" and "https://" access
protocols for anonymous, read-only access. If you have a suitably
configured GitHub account, you may also use SSH protocol with the
The servers at github.com support the "https://" access protocol for
anonymous, read-only access. If you have a suitably configured GitHub
account, you may also use SSH protocol with the
URL "git@github.com:lammps/lammps.git".
The LAMMPS GitHub project is currently managed by Axel Kohlmeyer

2
doc/src/Intro_citing.rst
View File

@ -16,7 +16,7 @@ source code design, the program structure, the spatial decomposition
approach, the neighbor finding, basic communications algorithms, and how
users and developers have contributed to LAMMPS is:
`LAMMPS - A flexible simulation tool for particle-based materials modeling at the atomic, meso, and continuum scales, Comp. Phys. Comm. (accepted 09/2021), DOI:10.1016/j.cpc.2021.108171 <https://doi.org/10.1016/j.cpc.2021.108171>`_
`LAMMPS - A flexible simulation tool for particle-based materials modeling at the atomic, meso, and continuum scales, Comp. Phys. Comm. 271, 108171 (2022) <https://doi.org/10.1016/j.cpc.2021.108171>`_
So a project using LAMMPS or a derivative application that uses LAMMPS
as a simulation engine should cite this paper. The paper is expected to

24
doc/src/Manual_version.rst
View File

@ -10,23 +10,31 @@ Whenever we fix a bug or update or add a feature, it will be merged into
the *develop* branch of the git repository. When a sufficient number of
changes have accumulated *and* the software passes a set of automated
tests, we release it in the next *patch* release, which are made every
few weeks. Info on patch releases are on `this website page
few weeks. The *release* branch of the git repository is updated with
every such release. Info on patch releases are on `this website page
<https://www.lammps.org/bug.html>`_.
Once or twice a year, only bug fixes and small, non-intrusive changes are
included for a period of time, and the code is subjected to more detailed
Once or twice a year, we apply only bug fixes and small, non-intrusive
changes to the *develop* branch and the code is subjected to more detailed
and thorough testing than the default automated testing. The latest
patch release after such a period is then labeled as a *stable* version.
patch release after such a period is then also labeled as a *stable* version
and the *stable* branch is updated with it. Between stable releases
we occasionally release some updates to the stable release containing
only bug fixes and updates back-ported from *develop* but no new features
and update the *stable* branch accordingly.
Each version of LAMMPS contains all the features and bug-fixes up to
and including its version date.
Each version of LAMMPS contains all the documented features up to and
including its version date.
The version date is printed to the screen and logfile every time you
run LAMMPS. It is also in the file src/version.h and in the LAMMPS
directory name created when you unpack a tarball. And it is on the
first page of the :doc:`manual <Manual>`.
* If you browse the HTML pages on the LAMMPS WWW site, they always
describe the most current patch release of LAMMPS.
* If you browse the HTML pages on the LAMMPS WWW site, they will by
default describe the most current patch release version of LAMMPS.
In the navigation bar on the bottom left, there is the option to
view instead the documentation for the most recent *stable* version
or the latest version from the current development branch.
* If you browse the HTML pages included in your tarball, they
describe the version you have, which may be older.

38
doc/src/Modify_pair.rst
View File

@ -12,24 +12,24 @@ includes some optional methods to enable its use with rRESPA.
Here is a brief description of the class methods in pair.h:
+---------------------------------+-------------------------------------------------------------------+
| compute | workhorse routine that computes pairwise interactions |
+---------------------------------+-------------------------------------------------------------------+
| settings | reads the input script line with arguments you define |
+---------------------------------+-------------------------------------------------------------------+
| coeff | set coefficients for one i,j type pair |
+---------------------------------+-------------------------------------------------------------------+
| init_one | perform initialization for one i,j type pair |
+---------------------------------+-------------------------------------------------------------------+
| init_style | initialization specific to this pair style |
+---------------------------------+-------------------------------------------------------------------+
| write & read_restart | write/read i,j pair coeffs to restart files |
+---------------------------------+-------------------------------------------------------------------+
| write & read_restart_settings | write/read global settings to restart files |
+---------------------------------+-------------------------------------------------------------------+
| single | force and energy of a single pairwise interaction between 2 atoms |
+---------------------------------+-------------------------------------------------------------------+
| compute_inner/middle/outer | versions of compute used by rRESPA |
+---------------------------------+-------------------------------------------------------------------+
+---------------------------------+---------------------------------------------------------------------+
| compute | workhorse routine that computes pairwise interactions |
+---------------------------------+---------------------------------------------------------------------+
| settings | reads the input script line with arguments you define |
+---------------------------------+---------------------------------------------------------------------+
| coeff | set coefficients for one i,j type pair |
+---------------------------------+---------------------------------------------------------------------+
| init_one | perform initialization for one i,j type pair |
+---------------------------------+---------------------------------------------------------------------+
| init_style | initialization specific to this pair style |
+---------------------------------+---------------------------------------------------------------------+
| write & read_restart | write/read i,j pair coeffs to restart files |
+---------------------------------+---------------------------------------------------------------------+
| write & read_restart_settings | write/read global settings to restart files |
+---------------------------------+---------------------------------------------------------------------+
| single | force/r and energy of a single pairwise interaction between 2 atoms |
+---------------------------------+---------------------------------------------------------------------+
| compute_inner/middle/outer | versions of compute used by rRESPA |
+---------------------------------+---------------------------------------------------------------------+
The inner/middle/outer routines are optional.

6
doc/src/Packages_details.rst
View File

@ -1907,6 +1907,12 @@ MPIIO library. It adds :doc:`dump styles <dump>` with a "mpiio" in
their style name. Restart files with an ".mpiio" suffix are also
written and read in parallel.
.. warning::
The MPIIO package is currently unmaintained and has become
unreliable. Use with caution.
**Install:**
The MPIIO package requires that LAMMPS is build in :ref:`MPI parallel mode <serial>`.

38
doc/src/angle_class2.rst
View File

@ -64,34 +64,44 @@ These are the 4 coefficients for the :math:`E_a` formula:
radians internally; hence the various :math:`K` are effectively energy
per radian\^2 or radian\^3 or radian\^4.
For the :math:`E_{bb}` formula, each line in a :doc:`angle_coeff <angle_coeff>`
command in the input script lists 4 coefficients, the first of which
is "bb" to indicate they are BondBond coefficients. In a data file,
these coefficients should be listed under a "BondBond Coeffs" heading
and you must leave out the "bb", i.e. only list 3 coefficients after
the angle type.
For the :math:`E_{bb}` formula, each line in a :doc:`angle_coeff
<angle_coeff>` command in the input script lists 4 coefficients, the
first of which is "bb" to indicate they are BondBond coefficients. In
a data file, these coefficients should be listed under a "BondBond
Coeffs" heading and you must leave out the "bb", i.e. only list 3
coefficients after the angle type.
* bb
* :math:`M` (energy/distance\^2)
* :math:`r_1` (distance)
* :math:`r_2` (distance)
For the :math:`E_{ba}` formula, each line in a :doc:`angle_coeff <angle_coeff>`
command in the input script lists 5 coefficients, the first of which
is "ba" to indicate they are BondAngle coefficients. In a data file,
these coefficients should be listed under a "BondAngle Coeffs" heading
and you must leave out the "ba", i.e. only list 4 coefficients after
the angle type.
For the :math:`E_{ba}` formula, each line in a :doc:`angle_coeff
<angle_coeff>` command in the input script lists 5 coefficients, the
first of which is "ba" to indicate they are BondAngle coefficients.
In a data file, these coefficients should be listed under a "BondAngle
Coeffs" heading and you must leave out the "ba", i.e. only list 4
coefficients after the angle type.
* ba
* :math:`N_1` (energy/distance\^2)
* :math:`N_2` (energy/distance\^2)
* :math:`N_1` (energy/distance)
* :math:`N_2` (energy/distance)
* :math:`r_1` (distance)
* :math:`r_2` (distance)
The :math:`\theta_0` value in the :math:`E_{ba}` formula is not specified,
since it is the same value from the :math:`E_a` formula.
.. note::
It is important that the order of the I,J,K atoms in each angle
listed in the Angles section of the data file read by the
:doc:`read_data <read_data>` command be consistent with the order
of the :math:`r_1` and :math:`r_2` BondBond and BondAngle
coefficients. This is because the terms in the formulas for
:math:`E_{bb}` and :math:`E_{ba}` will use the I,J atoms to compute
:math:`r_{ij}` and the J,K atoms to compute :math:`r_{jk}`.
----------
.. include:: accel_styles.rst

46
doc/src/bond_fene.rst
View File

@ -1,4 +1,5 @@
.. index:: bond_style fene
.. index:: bond_style fene/nm
.. index:: bond_style fene/intel
.. index:: bond_style fene/kk
.. index:: bond_style fene/omp
@ -8,12 +9,16 @@ bond_style fene command
Accelerator Variants: *fene/intel*, *fene/kk*, *fene/omp*
bond_style fene/nm command
==========================
Syntax
""""""
.. code-block:: LAMMPS
bond_style fene
bond_style fene/nm
Examples
""""""""
@ -23,6 +28,9 @@ Examples
bond_style fene
bond_coeff 1 30.0 1.5 1.0 1.0
bond_style fene/nm
bond_coeff 1 2.25344 1.5 1.0 1.12246 2 6
Description
"""""""""""
@ -38,16 +46,36 @@ term is attractive, the second Lennard-Jones term is repulsive. The
first term extends to :math:`R_0`, the maximum extent of the bond. The second
term is cutoff at :math:`2^\frac{1}{6} \sigma`, the minimum of the LJ potential.
The following coefficients must be defined for each bond type via the
:doc:`bond_coeff <bond_coeff>` command as in the example above, or in
the data file or restart files read by the :doc:`read_data <read_data>`
or :doc:`read_restart <read_restart>` commands:
The *fene/nm* bond style substitutes the standard LJ potential with the generalized LJ potential
in the same form as in pair style :doc:`nm/cut <pair_nm>`. The bond energy is then given by
.. math::
E = -0.5 K r_0^2 \ln \left[ 1 - \left(\frac{r}{R_0}\right)^2\right] + \frac{E_0}{(n-m)} \left[ m \left(\frac{r_0}{r}\right)^n - n \left(\frac{r_0}{r}\right)^m \right]
Similar to the *fene* style, the generalized Lennard-Jones is cut off at
the potential minimum, :math:`r_0`, to be repulsive only. The following
coefficients must be defined for each bond type via the :doc:`bond_coeff
<bond_coeff>` command as in the example above, or in the data file or
restart files read by the :doc:`read_data <read_data>` or
:doc:`read_restart <read_restart>` commands:
* :math:`K` (energy/distance\^2)
* :math:`R_0` (distance)
* :math:`\epsilon` (energy)
* :math:`\sigma` (distance)
For the *fene/nm* style, the following coefficients are used. Please
note, that the standard LJ potential and thus the regular FENE potential
is recovered for (n=12 m=6) and :math:`r_0 = 2^\frac{1}{6} \sigma`.
* :math:`K` (energy/distance\^2)
* :math:`R_0` (distance)
* :math:`E_0` (energy)
* :math:`r_0` (distance)
* :math:`n` (unitless)
* :math:`m` (unitless)
----------
.. include:: accel_styles.rst
@ -57,9 +85,10 @@ 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>` page for more
info.
The *fene* bond style can only be used if LAMMPS was built with the MOLECULE
package; the *fene/nm* 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.
You typically should specify :doc:`special_bonds fene <special_bonds>`
or :doc:`special_bonds lj/coul 0 1 1 <special_bonds>` to use this bond
@ -68,7 +97,8 @@ style. LAMMPS will issue a warning it that's not the case.
Related commands
""""""""""""""""
:doc:`bond_coeff <bond_coeff>`, :doc:`delete_bonds <delete_bonds>`
:doc:`bond_coeff <bond_coeff>`, :doc:`delete_bonds <delete_bonds>`,
:doc:`pair style lj/cut <pair_lj>`, :doc:`pair style nm/cut <pair_nm>`.
Default
"""""""

1
doc/src/bond_style.rst
View File

@ -87,6 +87,7 @@ accelerated styles exist.
* :doc:`class2 <bond_class2>` - COMPASS (class 2) bond
* :doc:`fene <bond_fene>` - FENE (finite-extensible non-linear elastic) bond
* :doc:`fene/expand <bond_fene_expand>` - FENE bonds with variable size particles
* :doc:`fene/nm <bond_fene>` - FENE bonds with a generalized Lennard-Jones potential
* :doc:`gaussian <bond_gaussian>` - multicentered Gaussian-based bond potential
* :doc:`gromos <bond_gromos>` - GROMOS force field bond
* :doc:`harmonic <bond_harmonic>` - harmonic bond

1
doc/src/compute.rst
View File

@ -174,6 +174,7 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
* :doc:`angle <compute_angle>` - energy of each angle sub-style
* :doc:`angle/local <compute_angle_local>` - theta and energy of each angle
* :doc:`angmom/chunk <compute_angmom_chunk>` - angular momentum for each chunk
* :doc:`ave/sphere/atom <compute_ave_sphere_atom>` - compute local density and temperature around each atom
* :doc:`basal/atom <compute_basal_atom>` - calculates the hexagonal close-packed "c" lattice vector of each atom
* :doc:`body/local <compute_body_local>` - attributes of body sub-particles
* :doc:`bond <compute_bond>` - energy of each bond sub-style

101
doc/src/compute_ave_sphere_atom.rst Normal file
View File

@ -0,0 +1,101 @@
.. index:: compute ave/sphere/atom
.. index:: compute ave/sphere/atom/kk
compute ave/sphere/atom command
================================
Accelerator Variants: *ave/sphere/atom/kk*
Syntax
""""""
.. parsed-literal::
compute ID group-ID ave/sphere/atom keyword values ...
* ID, group-ID are documented in :doc:`compute <compute>` command
* ave/sphere/atom = style name of this compute command
* one or more keyword/value pairs may be appended
.. parsed-literal::
keyword = *cutoff*
*cutoff* value = distance cutoff
Examples
""""""""
.. code-block:: LAMMPS
compute 1 all ave/sphere/atom
compute 1 all ave/sphere/atom cutoff 5.0
comm_modify cutoff 5.0
Description
"""""""""""
Define a computation that calculates the local density and temperature
for each atom and neighbors inside a spherical cutoff.
The optional keyword *cutoff* defines the distance cutoff
used when searching for neighbors. The default value is the cutoff
specified by the pair style. If no pair style is defined, then a cutoff
must be defined using this keyword. If the specified cutoff is larger than
that of the pair_style plus neighbor skin (or no pair style is defined),
the *comm_modify cutoff* option must also be set to match that of the
*cutoff* keyword.
The neighbor list needed to compute this quantity is constructed each
time the calculation is performed (i.e. each time a snapshot of atoms
is dumped). Thus it can be inefficient to compute/dump this quantity
too frequently.
.. note::
If you have a bonded system, then the settings of
:doc:`special_bonds <special_bonds>` command can remove pairwise
interactions between atoms in the same bond, angle, or dihedral. This
is the default setting for the :doc:`special_bonds <special_bonds>`
command, and means those pairwise interactions do not appear in the
neighbor list. Because this fix uses the neighbor list, it also means
those pairs will not be included in the order parameter. This
difficulty can be circumvented by writing a dump file, and using the
:doc:`rerun <rerun>` command to compute the order parameter for
snapshots in the dump file. The rerun script can use a
:doc:`special_bonds <special_bonds>` command that includes all pairs in
the neighbor list.
----------
.. include:: accel_styles.rst
----------
Output info
"""""""""""
This compute calculates a per-atom array with two columns: density and temperature.
These values 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 LAMMPS output options.
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.
Related commands
""""""""""""""""
:doc:`comm_modify <comm_modify>`
Default
"""""""
The option defaults are *cutoff* = pair style cutoff

6
doc/src/compute_bond_local.rst
View File

@ -13,7 +13,7 @@ Syntax
* ID, group-ID are documented in :doc:`compute <compute>` command
* bond/local = style name of this compute command
* one or more values may be appended
* value = *dist* or *engpot* or *force* or *fx* or *fy* or *fz* or *engvib* or *engrot* or *engtrans* or *omega* or *velvib* or *v_name*
* value = *dist* or *dx* or *dy* or *dz* or *engpot* or *force* or *fx* or *fy* or *fz* or *engvib* or *engrot* or *engtrans* or *omega* or *velvib* or *v_name*
.. parsed-literal::
@ -21,6 +21,7 @@ Syntax
*engpot* = bond potential energy
*force* = bond force
*dx*,\ *dy*,\ *dz* = components of pairwise distance
*fx*,\ *fy*,\ *fz* = components of bond force
*engvib* = bond kinetic energy of vibration
*engrot* = bond kinetic energy of rotation
@ -63,6 +64,9 @@ whether the 2 atoms represent a simple diatomic molecule, or are part
of some larger molecule.
The value *dist* is the current length of the bond.
The values *dx*, *dy*, and *dz* are the xyz components of the
*distance* between the pair of atoms. This value is always the
distance from the atom of lower to the one with the higher id.
The value *engpot* is the potential energy for the bond,
based on the current separation of the pair of atoms in the bond.

21
doc/src/compute_heat_flux.rst
View File

@ -89,13 +89,20 @@ included in the calculation.
.. warning::
The compute *heat/flux* has been reported to produce unphysical
values for angle, dihedral and improper contributions
values for angle, dihedral, improper and constraint force contributions
when used with :doc:`compute stress/atom <compute_stress_atom>`,
as discussed in :ref:`(Surblys) <Surblys2>` and :ref:`(Boone) <Boone>`.
You are strongly advised to
as discussed in :ref:`(Surblys2019) <Surblys3>`, :ref:`(Boone) <Boone>`
and :ref:`(Surblys2021) <Surblys4>`. You are strongly advised to
use :doc:`compute centroid/stress/atom <compute_stress_atom>`,
which has been implemented specifically for such cases.
.. warning::
Due to an implementation detail, the :math:`y` and :math:`z`
components of heat flux from :doc:`fix rigid <fix_rigid>`
contribution when computed via :doc:`compute stress/atom <compute_stress_atom>`
are highly unphysical and should not be used.
The Green-Kubo formulas relate the ensemble average of the
auto-correlation of the heat flux :math:`\mathbf{J}`
to the thermal conductivity :math:`\kappa`:
@ -232,10 +239,14 @@ none
----------
.. _Surblys2:
.. _Surblys3:
**(Surblys)** Surblys, Matsubara, Kikugawa, Ohara, Phys Rev E, 99, 051301(R) (2019).
**(Surblys2019)** Surblys, Matsubara, Kikugawa, Ohara, Phys Rev E, 99, 051301(R) (2019).
.. _Boone:
**(Boone)** Boone, Babaei, Wilmer, J Chem Theory Comput, 15, 5579--5587 (2019).
.. _Surblys4:
**(Surblys2021)** Surblys, Matsubara, Kikugawa, Ohara, J Appl Phys 130, 215104 (2021).

14
doc/src/compute_pair_local.rst
View File

@ -13,11 +13,12 @@ Syntax
* ID, group-ID are documented in :doc:`compute <compute>` command
* pair/local = style name of this compute command
* one or more values may be appended
* value = *dist* or *eng* or *force* or *fx* or *fy* or *fz* or *pN*
* value = *dist* or *dx* or *dy* or *dz* or *eng* or *force* or *fx* or *fy* or *fz* or *pN*
.. parsed-literal::
*dist* = pairwise distance
*dx*,\ *dy*,\ *dz* = components of pairwise distance
*eng* = pairwise energy
*force* = pairwise force
*fx*,\ *fy*,\ *fz* = components of pairwise force
@ -56,6 +57,9 @@ force cutoff distance for that interaction, as defined by the
commands.
The value *dist* is the distance between the pair of atoms.
The values *dx*, *dy*, and *dz* are the xyz components of the
*distance* between the pair of atoms. This value is always the
distance from the atom of lower to the one with the higher id.
The value *eng* is the interaction energy for the pair of atoms.
@ -89,10 +93,10 @@ from the second of the two sub-styles. If the referenced *pN*
is not computed for the specific pairwise interaction (based on
atom types), then the output will be 0.0.
The value *dist* will be in distance :doc:`units <units>`. The value
*eng* will be in energy :doc:`units <units>`. The values *force*, *fx*,
*fy*, and *fz* will be in force :doc:`units <units>`. The values *pN*
will be in whatever units the pair style defines.
The value *dist*, *dx*, *dy* and *dz* will be in distance :doc:`units <units>`.
The value *eng* will be in energy :doc:`units <units>`.
The values *force*, *fx*, *fy*, and *fz* will be in force :doc:`units <units>`.
The values *pN* will be in whatever units the pair style defines.
The optional *cutoff* keyword determines how the force cutoff distance
for an interaction is determined. For the default setting of *type*,

45
doc/src/compute_stress_atom.rst
View File

@ -87,6 +87,10 @@ Tersoff 3-body interaction) is assigned in equal portions to each atom
in the set. E.g. 1/4 of the dihedral virial to each of the 4 atoms,
or 1/3 of the fix virial due to SHAKE constraints applied to atoms in
a water molecule via the :doc:`fix shake <fix_shake>` command.
As an exception, the virial contribution from
constraint forces in :doc:`fix rigid <fix_rigid>` on each atom
is computed from the constraint force acting on the corresponding atom
and its position, i.e. the total virial is not equally distributed.
In case of compute *centroid/stress/atom*, the virial contribution is:
@ -103,13 +107,25 @@ atom :math:`I` due to the interaction and the relative position
:math:`\mathbf{r}_{I0}` of the atom :math:`I` to the geometric center
of the interacting atoms, i.e. centroid, is used. As the geometric
center is different for each interaction, the :math:`\mathbf{r}_{I0}`
also differs. The sixth and seventh terms, Kspace and :doc:`fix
<fix>` contribution respectively, are computed identical to compute
*stress/atom*. Although the total system virial is the same as
also differs. The sixth term, Kspace contribution,
is computed identically to compute *stress/atom*.
The seventh term is handed differently depending on
if the constraint forces are due to :doc:`fix shake <fix_shake>`
or :doc:`fix rigid <fix_rigid>`.
In case of SHAKE constraints, each distance constraint is
handed as a pairwise interaction.
E.g. in case of a water molecule, two OH and one HH distance
constraints are treated as three pairwise interactions.
In case of :doc:`fix rigid <fix_rigid>`,
all constraint forces in the molecule are treated
as a single many-body interaction with a single centroid position.
In case of water molecule, the formula expression would become
identical to that of the three-body angle interaction.
Although the total system virial is the same as
compute *stress/atom*, compute *centroid/stress/atom* is know to
result in more consistent heat flux values for angle, dihedrals and
improper contributions when computed via :doc:`compute heat/flux
<compute_heat_flux>`.
result in more consistent heat flux values for angle, dihedrals,
improper and constraint force contributions
when computed via :doc:`compute heat/flux <compute_heat_flux>`.
If no extra keywords are listed, the kinetic contribution all of the
virial contribution terms are included in the per-atom stress tensor.
@ -134,7 +150,8 @@ contribution for the cluster interaction is divided evenly among those
atoms.
Details of how compute *centroid/stress/atom* obtains the virial for
individual atoms is given in :ref:`(Surblys) <Surblys1>`, where the
individual atoms are given in :ref:`(Surblys2019) <Surblys1>` and
:ref:`(Surblys2021) <Surblys2>`, where the
idea is that the virial of the atom :math:`I` is the result of only
the force :math:`\mathbf{F}_I` on the atom due to the interaction and
its positional vector :math:`\mathbf{r}_{I0}`, relative to the
@ -235,10 +252,10 @@ between the pair of particles. All bond styles are supported. All
angle, dihedral, improper styles are supported with the exception of
INTEL and KOKKOS variants of specific styles. It also does not
support models with long-range Coulombic or dispersion forces,
i.e. the kspace_style command in LAMMPS. It also does not support the
following fixes which add rigid-body constraints: :doc:`fix shake
<fix_shake>`, :doc:`fix rattle <fix_shake>`, :doc:`fix rigid
<fix_rigid>`, :doc:`fix rigid/small <fix_rigid>`.
i.e. the kspace_style command in LAMMPS. It also does not implement the
following fixes which add rigid-body constraints:
:doc:`fix rigid/* <fix_rigid>` and the OpenMP accelerated version of :doc:`fix rigid/small <fix_rigid>`,
while all other :doc:`fix rigid/*/small <fix_rigid>` are implemented.
LAMMPS will generate an error if one of these options is included in
your model. Extension of centroid stress calculations to these force
@ -270,4 +287,8 @@ none
.. _Surblys1:
**(Surblys)** Surblys, Matsubara, Kikugawa, Ohara, Phys Rev E, 99, 051301(R) (2019).
**(Surblys2019)** Surblys, Matsubara, Kikugawa, Ohara, Phys Rev E, 99, 051301(R) (2019).
.. _Surblys2:
**(Surblys2021)** Surblys, Matsubara, Kikugawa, Ohara, J Appl Phys 130, 215104 (2021).

46
doc/src/delete_atoms.rst
View File

@ -20,8 +20,10 @@ Syntax
cutoff = delete one atom from pairs of atoms within the cutoff (distance units)
group1-ID = one atom in pair must be in this group
group2-ID = other atom in pair must be in this group
*porosity* args = region-ID fraction seed
*porosity* args = group-ID region-ID fraction seed
group-ID = group within which to perform deletions
region-ID = region within which to perform deletions
or NULL to only impose the group criterion
fraction = delete this fraction of atoms
seed = random number seed (positive integer)
@ -43,7 +45,8 @@ Examples
delete_atoms region sphere compress no
delete_atoms overlap 0.3 all all
delete_atoms overlap 0.5 solvent colloid
delete_atoms porosity cube 0.1 482793 bond yes
delete_atoms porosity all cube 0.1 482793 bond yes
delete_atoms porosity polymer cube 0.1 482793 bond yes
Description
"""""""""""
@ -76,12 +79,17 @@ have occurred that no atom pairs within the cutoff will remain
minimum number of atoms will be deleted, or that the same atoms will
be deleted when running on different numbers of processors.
For style *porosity* a specified *fraction* of atoms are deleted
within the specified region. For example, if fraction is 0.1, then
10% of the atoms will be deleted. The atoms to delete are chosen
randomly. There is no guarantee that the exact fraction of atoms will
be deleted, or that the same atoms will be deleted when running on
different numbers of processors.
For style *porosity* a specified *fraction* of atoms are deleted which
are both in the specified group and within the specified region. The
region-ID can be specified as NULL to only impose the group criterion.
Likewise, specifying the group-ID as *all* will only impose the region
criterion.
For example, if fraction is 0.1, then 10% of the eligible atoms will
be deleted. The atoms to delete are chosen randomly. There is no
guarantee that the exact fraction of atoms will be deleted, or that
the same atoms will be deleted when running on different numbers of
processors.
If the *compress* keyword is set to *yes*, then after atoms are
deleted, then atom IDs are re-assigned so that they run from 1 to the
@ -89,8 +97,8 @@ number of atoms in the system. Note that this is not done for
molecular systems (see the :doc:`atom_style <atom_style>` command),
regardless of the *compress* setting, since it would foul up the bond
connectivity that has already been assigned. However, the
:doc:`reset_atom_ids <reset_atom_ids>` command can be used after this command to
accomplish the same thing.
:doc:`reset_atom_ids <reset_atom_ids>` command can be used after this
command to accomplish the same thing.
Note that the re-assignment of IDs is not really a compression, where
gaps in atom IDs are removed by decrementing atom IDs that are larger.
@ -100,15 +108,15 @@ the :doc:`create_atoms <create_atoms>` command explains.
A molecular system with fixed bonds, angles, dihedrals, or improper
interactions, is one where the topology of the interactions is
typically defined in the data file read by the
:doc:`read_data <read_data>` command, and where the interactions
themselves are defined with the :doc:`bond_style <bond_style>`,
:doc:`angle_style <angle_style>`, etc commands. If you delete atoms
from such a system, you must be careful not to end up with bonded
interactions that are stored by remaining atoms but which include
deleted atoms. This will cause LAMMPS to generate a "missing atoms"
error when the bonded interaction is computed. The *bond* and *mol*
keywords offer two ways to do that.
typically defined in the data file read by the :doc:`read_data
<read_data>` command, and where the interactions themselves are
defined with the :doc:`bond_style <bond_style>`, :doc:`angle_style
<angle_style>`, etc commands. If you delete atoms from such a system,
you must be careful not to end up with bonded interactions that are
stored by remaining atoms but which include deleted atoms. This will
cause LAMMPS to generate a "missing atoms" error when the bonded
interaction is computed. The *bond* and *mol* keywords offer two ways
to do that.
It the *bond* keyword is set to *yes* then any bond or angle or
dihedral or improper interaction that includes a deleted atom is also

95
doc/src/dump.rst
View File

@ -137,7 +137,7 @@ Examples
dump myDump all atom/gz 100 dump.atom.gz
dump myDump all atom/zstd 100 dump.atom.zst
dump 2 subgroup atom 50 dump.run.bin
dump 2 subgroup atom 50 dump.run.mpiio.bin
dump 2 subgroup atom/mpiio 50 dump.run.mpiio.bin
dump 4a all custom 100 dump.myforce.* id type x y vx fx
dump 4b flow custom 100 dump.%.myforce id type c_myF[3] v_ke
dump 4b flow custom 100 dump.%.myforce id type c_myF[*] v_ke
@ -169,11 +169,12 @@ or multiple smaller files).
.. note::
Because periodic boundary conditions are enforced only on
timesteps when neighbor lists are rebuilt, the coordinates of an atom
written to a dump file may be slightly outside the simulation box.
Re-neighbor timesteps will not typically coincide with the timesteps
dump snapshots are written. See the :doc:`dump_modify pbc <dump_modify>` command if you with to force coordinates to be
Because periodic boundary conditions are enforced only on timesteps
when neighbor lists are rebuilt, the coordinates of an atom written
to a dump file may be slightly outside the simulation box.
Re-neighbor timesteps will not typically coincide with the
timesteps dump snapshots are written. See the :doc:`dump_modify
pbc <dump_modify>` command if you with to force coordinates to be
strictly inside the simulation box.
.. note::
@ -189,20 +190,21 @@ or multiple smaller files).
multiple processors, each of which owns a subset of the atoms.
For the *atom*, *custom*, *cfg*, and *local* styles, sorting is off by
default. For the *dcd*, *xtc*, *xyz*, and *molfile* styles, sorting by
atom ID is on by default. See the :doc:`dump_modify <dump_modify>` doc
page for details.
default. For the *dcd*, *xtc*, *xyz*, and *molfile* styles, sorting
by atom ID is on by default. See the :doc:`dump_modify <dump_modify>`
doc page for details.
The *atom/gz*, *cfg/gz*, *custom/gz*, *local/gz*, and *xyz/gz* styles are identical
in command syntax to the corresponding styles without "gz", however,
they generate compressed files using the zlib library. Thus the filename
suffix ".gz" is mandatory. This is an alternative approach to writing
compressed files via a pipe, as done by the regular dump styles, which
may be required on clusters where the interface to the high-speed network
disallows using the fork() library call (which is needed for a pipe).
For the remainder of this doc page, you should thus consider the *atom*
and *atom/gz* styles (etc) to be inter-changeable, with the exception
of the required filename suffix.
The *atom/gz*, *cfg/gz*, *custom/gz*, *local/gz*, and *xyz/gz* styles
are identical in command syntax to the corresponding styles without
"gz", however, they generate compressed files using the zlib
library. Thus the filename suffix ".gz" is mandatory. This is an
alternative approach to writing compressed files via a pipe, as done
by the regular dump styles, which may be required on clusters where
the interface to the high-speed network disallows using the fork()
library call (which is needed for a pipe). For the remainder of this
doc page, you should thus consider the *atom* and *atom/gz* styles
(etc) to be inter-changeable, with the exception of the required
filename suffix.
Similarly, the *atom/zstd*, *cfg/zstd*, *custom/zstd*, *local/zstd*,
and *xyz/zstd* styles are identical to the gz styles, but use the Zstd
@ -219,6 +221,11 @@ you should thus consider the *atom* and *atom/mpiio* styles (etc) to
be inter-changeable. The one exception is how the filename is
specified for the MPI-IO styles, as explained below.
.. warning::
The MPIIO package is currently unmaintained and has become
unreliable. Use with caution.
The precision of values output to text-based dump files can be
controlled by the :doc:`dump_modify format <dump_modify>` command and
its options.
@ -275,10 +282,11 @@ This bounding box is convenient for many visualization programs. The
meaning of the 6 character flags for "xx yy zz" is the same as above.
Note that the first two numbers on each line are now xlo_bound instead
of xlo, etc, since they represent a bounding box. See the :doc:`Howto triclinic <Howto_triclinic>` page for a geometric description
of triclinic boxes, as defined by LAMMPS, simple formulas for how the
6 bounding box extents (xlo_bound,xhi_bound,etc) are calculated from
the triclinic parameters, and how to transform those parameters to and
of xlo, etc, since they represent a bounding box. See the :doc:`Howto
triclinic <Howto_triclinic>` page for a geometric description of
triclinic boxes, as defined by LAMMPS, simple formulas for how the 6
bounding box extents (xlo_bound,xhi_bound,etc) are calculated from the
triclinic parameters, and how to transform those parameters to and
from other commonly used triclinic representations.
The "ITEM: ATOMS" line in each snapshot lists column descriptors for
@ -310,23 +318,24 @@ written to the dump file. This local data is typically calculated by
each processor based on the atoms it owns, but there may be zero or
more entities per atom, e.g. a list of bond distances. An explanation
of the possible dump local attributes is given below. Note that by
using input from the :doc:`compute property/local <compute_property_local>` command with dump local,
it is possible to generate information on bonds, angles, etc that can
be cut and pasted directly into a data file read by the
:doc:`read_data <read_data>` command.
using input from the :doc:`compute property/local
<compute_property_local>` command with dump local, it is possible to
generate information on bonds, angles, etc that can be cut and pasted
directly into a data file read by the :doc:`read_data <read_data>`
command.
Style *cfg* has the same command syntax as style *custom* and writes
extended CFG format files, as used by the
`AtomEye <http://li.mit.edu/Archive/Graphics/A/>`_ visualization
package. Since the extended CFG format uses a single snapshot of the
system per file, a wildcard "\*" must be included in the filename, as
discussed below. The list of atom attributes for style *cfg* must
begin with either "mass type xs ys zs" or "mass type xsu ysu zsu"
since these quantities are needed to write the CFG files in the
appropriate format (though the "mass" and "type" fields do not appear
explicitly in the file). Any remaining attributes will be stored as
"auxiliary properties" in the CFG files. Note that you will typically
want to use the :doc:`dump_modify element <dump_modify>` command with
extended CFG format files, as used by the `AtomEye
<http://li.mit.edu/Archive/Graphics/A/>`_ visualization package.
Since the extended CFG format uses a single snapshot of the system per
file, a wildcard "\*" must be included in the filename, as discussed
below. The list of atom attributes for style *cfg* must begin with
either "mass type xs ys zs" or "mass type xsu ysu zsu" since these
quantities are needed to write the CFG files in the appropriate format
(though the "mass" and "type" fields do not appear explicitly in the
file). Any remaining attributes will be stored as "auxiliary
properties" in the CFG files. Note that you will typically want to
use the :doc:`dump_modify element <dump_modify>` command with
CFG-formatted files, to associate element names with atom types, so
that AtomEye can render atoms appropriately. When unwrapped
coordinates *xsu*, *ysu*, and *zsu* are requested, the nominal AtomEye
@ -452,6 +461,11 @@ use the :doc:`read_dump <read_dump>` command or perform other
post-processing, just as if the dump file was not written using
MPI-IO.
.. warning::
The MPIIO package is currently unmaintained and has become
unreliable. Use with caution.
Note that MPI-IO dump files are one large file which all processors
write to. You thus cannot use the "%" wildcard character described
above in the filename since that specifies generation of multiple
@ -708,8 +722,9 @@ are part of the MPIIO 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 *xtc* style is part of the MISC package. It is only enabled if
LAMMPS was built with that package. See the :doc:`Build package <Build_package>` page for more info.
The *xtc* and *dcd* styles are part of the EXTRA-DUMP package. They
are only enabled if LAMMPS was built with that package. See the
:doc:`Build package <Build_package>` page for more info.
Related commands
""""""""""""""""

499
doc/src/dump_image.rst
View File

@ -6,6 +6,8 @@ dump image command
dump movie command
==================
(see below for :ref:`dump_modify options <dump_modify_image>` specific to dump image/movie)
Syntax
""""""
@ -15,7 +17,7 @@ Syntax
* ID = user-assigned name for the dump
* group-ID = ID of the group of atoms to be imaged
* style = *image* or *movie* = style of dump command (other styles *atom* or *cfg* or *dcd* or *xtc* or *xyz* or *local* or *custom* are discussed on the :doc:`dump <dump>` doc page)
* style = *image* or *movie* = style of dump command (other styles such as *atom* or *cfg* or *dcd* or *xtc* or *xyz* or *local* or *custom* are discussed on the :doc:`dump <dump>` doc page)
* N = dump every this many timesteps
* file = name of file to write image to
* color = atom attribute that determines color of each atom
@ -79,6 +81,69 @@ Syntax
seed = random # seed (positive integer)
dfactor = strength of shading from 0.0 to 1.0
.. _dump_modify_image:
dump_modify options for dump image/movie
========================================
Syntax
""""""
.. parsed-literal::
dump_modify dump-ID keyword values ...
* these keywords apply only to the *image* and *movie* styles and are documented on this page
* keyword = *acolor* or *adiam* or *amap* or *backcolor* or *bcolor* or *bdiam* or *boxcolor* or *color* or *bitrate* or *framerate*
* see the :doc:`dump modify <dump_modify>` doc page for more general keywords
.. parsed-literal::
*acolor* args = type color
type = atom type or range of types (see below)
color = name of color or color1/color2/...
*adiam* args = type diam
type = atom type or range of types (see below)
diam = diameter of atoms of that type (distance units)
*amap* args = lo hi style delta N entry1 entry2 ... entryN
lo = number or *min* = lower bound of range of color map
hi = number or *max* = upper bound of range of color map
style = 2 letters = "c" or "d" or "s" plus "a" or "f"
"c" for continuous
"d" for discrete
"s" for sequential
"a" for absolute
"f" for fractional
delta = binsize (only used for style "s", otherwise ignored)
binsize = range is divided into bins of this width
N = # of subsequent entries
entry = value color (for continuous style)
value = number or *min* or *max* = single value within range
color = name of color used for that value
entry = lo hi color (for discrete style)
lo/hi = number or *min* or *max* = lower/upper bound of subset of range
color = name of color used for that subset of values
entry = color (for sequential style)
color = name of color used for a bin of values
*backcolor* arg = color
color = name of color for background
*bcolor* args = type color
type = bond type or range of types (see below)
color = name of color or color1/color2/...
*bdiam* args = type diam
type = bond type or range of types (see below)
diam = diameter of bonds of that type (distance units)
*boxcolor* arg = color
color = name of color for simulation box lines and processor sub-domain lines
*color* args = name R G B
name = name of color
R,G,B = red/green/blue numeric values from 0.0 to 1.0
*bitrate* arg = rate
rate = target bitrate for movie in kbps
*framerate* arg = fps
fps = frames per second for movie
Examples
""""""""
@ -91,6 +156,8 @@ Examples
dump m1 all movie 1000 movie.avi type type size 640 480
dump m2 all movie 100 movie.m4v type type zoom 1.8 adiam v_value size 1280 720
dump_modify 1 amap min max cf 0.0 3 min green 0.5 yellow max blue boxcolor red
Description
"""""""""""
@ -145,10 +212,10 @@ is used.
Similarly, the format of the resulting movie is chosen with the
*movie* dump style. This is handled by the underlying FFmpeg converter
and thus details have to be looked up in the `FFmpeg documentation
<http://ffmpeg.org/ffmpeg.html>`_.
Typical examples are: .avi, .mpg, .m4v, .mp4, .mkv, .flv, .mov, .gif
Additional settings of the movie compression like bitrate and
framerate can be set using the :doc:`dump_modify <dump_modify>` command.
<http://ffmpeg.org/ffmpeg.html>`_. Typical examples are: .avi, .mpg,
.m4v, .mp4, .mkv, .flv, .mov, .gif Additional settings of the movie
compression like bitrate and framerate can be set using the
dump_modify command as described below.
To write out JPEG and PNG format files, you must build LAMMPS with
support for the corresponding JPEG or PNG library. To convert images
@ -210,19 +277,20 @@ to colors is as follows:
* type 6 = cyan
and repeats itself for types > 6. This mapping can be changed by the
:doc:`dump_modify acolor <dump_modify>` command.
"dump_modify acolor" command, as described below.
If *type* is specified for the *diameter* setting then the diameter of
each atom is determined by its atom type. By default all types have
diameter 1.0. This mapping can be changed by the :doc:`dump_modify adiam <dump_modify>` command.
diameter 1.0. This mapping can be changed by the "dump_modify adiam"
command, as described below.
If *element* is specified for the *color* and/or *diameter* setting,
then the color and/or diameter of each atom is determined by which
element it is, which in turn is specified by the element-to-type
mapping specified by the "dump_modify element" command. By default
every atom type is C (carbon). Every element has a color and diameter
associated with it, which is the same as the colors and sizes used by
the `AtomEye <atomeye_>`_ visualization package.
mapping specified by the "dump_modify element" command, as described
below. By default every atom type is C (carbon). Every element has a
color and diameter associated with it, which is the same as the colors
and sizes used by the `AtomEye <atomeye_>`_ visualization package.
.. _atomeye: http://li.mit.edu/Archive/Graphics/A/
@ -232,13 +300,13 @@ settings, they are interpreted in the following way.
If "vx", for example, is used as the *color* setting, then the color
of the atom will depend on the x-component of its velocity. The
association of a per-atom value with a specific color is determined by
a "color map", which can be specified via the
:doc:`dump_modify <dump_modify>` command. The basic idea is that the
atom-attribute will be within a range of values, and every value
within the range is mapped to a specific color. Depending on how the
color map is defined, that mapping can take place via interpolation so
that a value of -3.2 is halfway between "red" and "blue", or
discretely so that the value of -3.2 is "orange".
a "color map", which can be specified via the dump_modify command, as
described below. The basic idea is that the atom-attribute will be
within a range of values, and every value within the range is mapped
to a specific color. Depending on how the color map is defined, that
mapping can take place via interpolation so that a value of -3.2 is
halfway between "red" and "blue", or discretely so that the value of
-3.2 is "orange".
If "vx", for example, is used as the *diameter* setting, then the atom
will be rendered using the x-component of its velocity as the
@ -251,9 +319,10 @@ diameter, which can be used as the *diameter* setting.
The various keywords listed above control how the image is rendered.
As listed below, all of the keywords have defaults, most of which you
will likely not need to change. The :doc:`dump modify <dump_modify>`
also has options specific to the dump image style, particularly for
assigning colors to atoms, bonds, and other image features.
will likely not need to change. As described below, the dump modify
command also has options specific to the dump image style,
particularly for assigning colors to atoms, bonds, and other image
features.
----------
@ -295,7 +364,7 @@ types to colors is as follows:
* type 6 = cyan
and repeats itself for bond types > 6. This mapping can be changed by
the :doc:`dump_modify bcolor <dump_modify>` command.
the "dump_modify bcolor" command, as described below.
The bond *width* value can be a numeric value or *atom* or *type* (or
*none* as indicated above).
@ -310,7 +379,8 @@ of the 2 atoms in the bond.
If *type* is specified for the *width* value then the diameter of each
bond is determined by its bond type. By default all types have
diameter 0.5. This mapping can be changed by the :doc:`dump_modify bdiam <dump_modify>` command.
diameter 0.5. This mapping can be changed by the "dump_modify bdiam" command,
as described below.
----------
@ -330,7 +400,7 @@ mapping of types to colors is as follows:
* type 6 = cyan
and repeats itself for types > 6. There is not yet an option to
change this via the :doc:`dump_modify <dump_modify>` command.
change this via the dump_modify command.
The line *width* can only be a numeric value, which specifies that all
lines will be drawn as cylinders with that diameter, e.g. 1.0, which
@ -357,7 +427,7 @@ default the mapping of types to colors is as follows:
* type 6 = cyan
and repeats itself for types > 6. There is not yet an option to
change this via the :doc:`dump_modify <dump_modify>` command.
change this via the dump_modify command.
----------
@ -390,7 +460,7 @@ particle. By default the mapping of types to colors is as follows:
* type 6 = cyan
and repeats itself for types > 6. There is not yet an option to
change this via the :doc:`dump_modify <dump_modify>` command.
change this via the dump_modify command.
----------
@ -414,7 +484,7 @@ the mapping of types to colors is as follows:
* type 6 = cyan
and repeats itself for types > 6. There is not yet an option to
change this via the :doc:`dump_modify <dump_modify>` command.
change this via the dump_modify command.
----------
@ -488,7 +558,8 @@ are rendered as thin cylinders in the image. If *no* is set, then the
box boundaries are not drawn and the *diam* setting is ignored. If
*yes* is set, the 12 edges of the box are drawn, with a diameter that
is a fraction of the shortest box length in x,y,z (for 3d) or x,y (for
2d). The color of the box boundaries can be set with the :doc:`dump_modify boxcolor <dump_modify>` command.
2d). The color of the box boundaries can be set with the "dump_modify
boxcolor" command.
The *axes* keyword determines if and how the coordinate axes are
rendered as thin cylinders in the image. If *no* is set, then the
@ -507,7 +578,8 @@ set (default), then the sub-domain boundaries are not drawn and the
*diam* setting is ignored. If *yes* is set, the 12 edges of each
processor sub-domain are drawn, with a diameter that is a fraction of
the shortest box length in x,y,z (for 3d) or x,y (for 2d). The color
of the sub-domain boundaries can be set with the :doc:`dump_modify boxcolor <dump_modify>` command.
of the sub-domain boundaries can be set with the "dump_modify
boxcolor" command.
----------
@ -607,9 +679,272 @@ Play the movie:
----------
See the :doc:`Modify <Modify>` page for information on how to add
new compute and fix styles to LAMMPS to calculate per-atom quantities
which could then be output into dump files.
Dump_modify keywords for dump image and dump movie
""""""""""""""""""""""""""""""""""""""""""""""""""
The following dump_modify keywords apply only to the dump image and
dump movie styles. Any keyword that works with dump image also works
with dump movie, since the movie is simply a collection of images.
Some of the keywords only affect the dump movie style. The
descriptions give details.
----------
The *acolor* keyword can be used with the dump image command, when its
atom color setting is *type*, to set the color that atoms of each type
will be drawn in the image.
The specified *type* should be an integer from 1 to Ntypes = the
number of atom types. A wildcard asterisk can be used in place of or
in conjunction with the *type* argument to specify a range of atom
types. This takes the form "\*" or "\*n" or "n\*" or "m\*n". If N =
the number of atom types, then an asterisk with no numeric values
means all types from 1 to N. A leading asterisk means all types from
1 to n (inclusive). A trailing asterisk means all types from n to N
(inclusive). A middle asterisk means all types from m to n
(inclusive).
The specified *color* can be a single color which is any of the 140
pre-defined colors (see below) or a color name defined by the
"dump_modify color" command, as described below. Or it can be two or
more colors separated by a "/" character, e.g. red/green/blue. In the
former case, that color is assigned to all the specified atom types.
In the latter case, the list of colors are assigned in a round-robin
fashion to each of the specified atom types.
----------
The *adiam* keyword can be used with the dump image command, when its
atom diameter setting is *type*, to set the size that atoms of each
type will be drawn in the image. The specified *type* should be an
integer from 1 to Ntypes. As with the *acolor* keyword, a wildcard
asterisk can be used as part of the *type* argument to specify a range
of atom types. The specified *diam* is the size in whatever distance
:doc:`units <units>` the input script is using, e.g. Angstroms.
----------
The *amap* keyword can be used with the dump image command, with its
*atom* keyword, when its atom setting is an atom-attribute, to setup a
color map. The color map is used to assign a specific RGB
(red/green/blue) color value to an individual atom when it is drawn,
based on the atom's attribute, which is a numeric value, e.g. its
x-component of velocity if the atom-attribute "vx" was specified.
The basic idea of a color map is that the atom-attribute will be
within a range of values, and that range is associated with a series
of colors (e.g. red, blue, green). An atom's specific value (vx =
-3.2) can then mapped to the series of colors (e.g. halfway between
red and blue), and a specific color is determined via an interpolation
procedure.
There are many possible options for the color map, enabled by the
*amap* keyword. Here are the details.
The *lo* and *hi* settings determine the range of values allowed for
the atom attribute. If numeric values are used for *lo* and/or *hi*,
then values that are lower/higher than that value are set to the
value. I.e. the range is static. If *lo* is specified as *min* or
*hi* as *max* then the range is dynamic, and the lower and/or
upper bound will be calculated each time an image is drawn, based
on the set of atoms being visualized.
The *style* setting is two letters, such as "ca". The first letter is
either "c" for continuous, "d" for discrete, or "s" for sequential.
The second letter is either "a" for absolute, or "f" for fractional.
A continuous color map is one in which the color changes continuously
from value to value within the range. A discrete color map is one in
which discrete colors are assigned to sub-ranges of values within the
range. A sequential color map is one in which discrete colors are
assigned to a sequence of sub-ranges of values covering the entire
range.
An absolute color map is one in which the values to which colors are
assigned are specified explicitly as values within the range. A
fractional color map is one in which the values to which colors are
assigned are specified as a fractional portion of the range. For
example if the range is from -10.0 to 10.0, and the color red is to be
assigned to atoms with a value of 5.0, then for an absolute color map
the number 5.0 would be used. But for a fractional map, the number
0.75 would be used since 5.0 is 3/4 of the way from -10.0 to 10.0.
The *delta* setting must be specified for all styles, but is only used
for the sequential style; otherwise the value is ignored. It
specifies the bin size to use within the range for assigning
consecutive colors to. For example, if the range is from -10.0 to
10.0 and a *delta* of 1.0 is used, then 20 colors will be assigned to
the range. The first will be from -10.0 <= color1 < -9.0, then second
from -9.0 <= color2 < -8.0, etc.
The *N* setting is how many entries follow. The format of the entries
depends on whether the color map style is continuous, discrete or
sequential. In all cases the *color* setting can be any of the 140
pre-defined colors (see below) or a color name defined by the
dump_modify color option.
For continuous color maps, each entry has a *value* and a *color*\ .
The *value* is either a number within the range of values or *min* or
*max*\ . The *value* of the first entry must be *min* and the *value*
of the last entry must be *max*\ . Any entries in between must have
increasing values. Note that numeric values can be specified either
as absolute numbers or as fractions (0.0 to 1.0) of the range,
depending on the "a" or "f" in the style setting for the color map.
Here is how the entries are used to determine the color of an
individual atom, given the value X of its atom attribute. X will fall
between 2 of the entry values. The color of the atom is linearly
interpolated (in each of the RGB values) between the 2 colors
associated with those entries. For example, if X = -5.0 and the 2
surrounding entries are "red" at -10.0 and "blue" at 0.0, then the
atom's color will be halfway between "red" and "blue", which happens
to be "purple".
For discrete color maps, each entry has a *lo* and *hi* value and a
*color*\ . The *lo* and *hi* settings are either numbers within the
range of values or *lo* can be *min* or *hi* can be *max*\ . The *lo*
and *hi* settings of the last entry must be *min* and *max*\ . Other
entries can have any *lo* and *hi* values and the sub-ranges of
different values can overlap. Note that numeric *lo* and *hi* values
can be specified either as absolute numbers or as fractions (0.0 to
1.0) of the range, depending on the "a" or "f" in the style setting
for the color map.
Here is how the entries are used to determine the color of an
individual atom, given the value X of its atom attribute. The entries
are scanned from first to last. The first time that *lo* <= X <=
*hi*, X is assigned the color associated with that entry. You can
think of the last entry as assigning a default color (since it will
always be matched by X), and the earlier entries as colors that
override the default. Also note that no interpolation of a color RGB
is done. All atoms will be drawn with one of the colors in the list
of entries.
For sequential color maps, each entry has only a *color*\ . Here is how
the entries are used to determine the color of an individual atom,
given the value X of its atom attribute. The range is partitioned
into N bins of width *binsize*\ . Thus X will fall in a specific bin
from 1 to N, say the Mth bin. If it falls on a boundary between 2
bins, it is considered to be in the higher of the 2 bins. Each bin is
assigned a color from the E entries. If E < N, then the colors are
repeated. For example if 2 entries with colors red and green are
specified, then the odd numbered bins will be red and the even bins
green. The color of the atom is the color of its bin. Note that the
sequential color map is really a shorthand way of defining a discrete
color map without having to specify where all the bin boundaries are.
Here is an example of using a sequential color map to color all the
atoms in individual molecules with a different color. See the
examples/pour/in.pour.2d.molecule input script for an example of how
this is used.
.. code-block:: LAMMPS
variable colors string &
"red green blue yellow white &
purple pink orange lime gray"
variable mol atom mol%10
dump 1 all image 250 image.*.jpg v_mol type &
zoom 1.6 adiam 1.5
dump_modify 1 pad 5 amap 0 10 sa 1 10 ${colors}
In this case, 10 colors are defined, and molecule IDs are
mapped to one of the colors, even if there are 1000s of molecules.
----------
The *backcolor* sets the background color of the images. The color
name can be any of the 140 pre-defined colors (see below) or a color
name defined by the dump_modify color option.
----------
The *bcolor* keyword can be used with the dump image command, with its
*bond* keyword, when its color setting is *type*, to set the color
that bonds of each type will be drawn in the image.
The specified *type* should be an integer from 1 to Nbondtypes = the
number of bond types. A wildcard asterisk can be used in place of or
in conjunction with the *type* argument to specify a range of bond
types. This takes the form "\*" or "\*n" or "n\*" or "m\*n". If N =
the number of bond types, then an asterisk with no numeric values
means all types from 1 to N. A leading asterisk means all types from
1 to n (inclusive). A trailing asterisk means all types from n to N
(inclusive). A middle asterisk means all types from m to n
(inclusive).
The specified *color* can be a single color which is any of the 140
pre-defined colors (see below) or a color name defined by the
dump_modify color option. Or it can be two or more colors separated
by a "/" character, e.g. red/green/blue. In the former case, that
color is assigned to all the specified bond types. In the latter
case, the list of colors are assigned in a round-robin fashion to each
of the specified bond types.
----------
The *bdiam* keyword can be used with the dump image command, with its
*bond* keyword, when its diam setting is *type*, to set the diameter
that bonds of each type will be drawn in the image. The specified
*type* should be an integer from 1 to Nbondtypes. As with the
*bcolor* keyword, a wildcard asterisk can be used as part of the
*type* argument to specify a range of bond types. The specified
*diam* is the size in whatever distance :doc:`units <units>` you are
using, e.g. Angstroms.
----------
The *bitrate* keyword can be used with the :doc:`dump movie
<dump_image>` command to define the size of the resulting movie file
and its quality via setting how many kbits per second are to be used
for the movie file. Higher bitrates require less compression and will
result in higher quality movies. The quality is also determined by
the compression format and encoder. The default setting is 2000
kbit/s, which will result in average quality with older compression
formats.
.. note::
Not all movie file formats supported by dump movie allow the
bitrate to be set. If not, the setting is silently ignored.
----------
The *boxcolor* keyword sets the color of the simulation box drawn
around the atoms in each image as well as the color of processor
sub-domain boundaries. See the "dump image box" command for how to
specify that a box be drawn via the *box* keyword, and the sub-domain
boundaries via the *subbox* keyword. The color name can be any of the
140 pre-defined colors (see below) or a color name defined by the
dump_modify color option.
----------
The *color* keyword allows definition of a new color name, in addition
to the 140-predefined colors (see below), and associates 3
red/green/blue RGB values with that color name. The color name can
then be used with any other dump_modify keyword that takes a color
name as a value. The RGB values should each be floating point values
between 0.0 and 1.0 inclusive.
When a color name is converted to RGB values, the user-defined color
names are searched first, then the 140 pre-defined color names. This
means you can also use the *color* keyword to overwrite one of the
pre-defined color names with new RBG values.
----------
The *framerate* keyword can be used with the :doc:`dump movie
<dump_image>` command to define the duration of the resulting movie
file. Movie files written by the dump *movie* command have a default
frame rate of 24 frames per second and the images generated will be
converted at that rate. Thus a sequence of 1000 dump images will
result in a movie of about 42 seconds. To make a movie run longer you
can either generate images more frequently or lower the frame rate.
To speed a movie up, you can do the inverse. Using a frame rate
higher than 24 is not recommended, as it will result in simply
dropping the rendered images. It is more efficient to dump images less
frequently.
----------
@ -664,7 +999,7 @@ Related commands
Default
"""""""
The defaults for the keywords are as follows:
The defaults for the dump image and dump movie keywords are as follows:
* adiam = not specified (use diameter setting)
* atom = yes
@ -682,3 +1017,101 @@ The defaults for the keywords are as follows:
* subbox no 0.0
* shiny = 1.0
* ssao = no
----------
The defaults for the dump_modify keywords specific to dump image and dump movie are as follows:
* acolor = \* red/green/blue/yellow/aqua/cyan
* adiam = \* 1.0
* amap = min max cf 0.0 2 min blue max red
* backcolor = black
* bcolor = \* red/green/blue/yellow/aqua/cyan
* bdiam = \* 0.5
* bitrate = 2000
* boxcolor = yellow
* color = 140 color names are pre-defined as listed below
* framerate = 24
----------
These are the standard 109 element names that LAMMPS pre-defines for
use with the dump image and dump_modify commands.
* 1-10 = "H", "He", "Li", "Be", "B", "C", "N", "O", "F", "Ne"
* 11-20 = "Na", "Mg", "Al", "Si", "P", "S", "Cl", "Ar", "K", "Ca"
* 21-30 = "Sc", "Ti", "V", "Cr", "Mn", "Fe", "Co", "Ni", "Cu", "Zn"
* 31-40 = "Ga", "Ge", "As", "Se", "Br", "Kr", "Rb", "Sr", "Y", "Zr"
* 41-50 = "Nb", "Mo", "Tc", "Ru", "Rh", "Pd", "Ag", "Cd", "In", "Sn"
* 51-60 = "Sb", "Te", "I", "Xe", "Cs", "Ba", "La", "Ce", "Pr", "Nd"
* 61-70 = "Pm", "Sm", "Eu", "Gd", "Tb", "Dy", "Ho", "Er", "Tm", "Yb"
* 71-80 = "Lu", "Hf", "Ta", "W", "Re", "Os", "Ir", "Pt", "Au", "Hg"
* 81-90 = "Tl", "Pb", "Bi", "Po", "At", "Rn", "Fr", "Ra", "Ac", "Th"
* 91-100 = "Pa", "U", "Np", "Pu", "Am", "Cm", "Bk", "Cf", "Es", "Fm"
* 101-109 = "Md", "No", "Lr", "Rf", "Db", "Sg", "Bh", "Hs", "Mt"
----------
These are the 140 colors that LAMMPS pre-defines for use with the dump
image and dump_modify commands. Additional colors can be defined with
the dump_modify color command. The 3 numbers listed for each name are
the RGB (red/green/blue) values. Divide each value by 255 to get the
equivalent 0.0 to 1.0 value.
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| aliceblue = 240, 248, 255 | antiquewhite = 250, 235, 215 | aqua = 0, 255, 255 | aquamarine = 127, 255, 212 | azure = 240, 255, 255 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| beige = 245, 245, 220 | bisque = 255, 228, 196 | black = 0, 0, 0 | blanchedalmond = 255, 255, 205 | blue = 0, 0, 255 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| blueviolet = 138, 43, 226 | brown = 165, 42, 42 | burlywood = 222, 184, 135 | cadetblue = 95, 158, 160 | chartreuse = 127, 255, 0 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| chocolate = 210, 105, 30 | coral = 255, 127, 80 | cornflowerblue = 100, 149, 237 | cornsilk = 255, 248, 220 | crimson = 220, 20, 60 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| cyan = 0, 255, 255 | darkblue = 0, 0, 139 | darkcyan = 0, 139, 139 | darkgoldenrod = 184, 134, 11 | darkgray = 169, 169, 169 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| darkgreen = 0, 100, 0 | darkkhaki = 189, 183, 107 | darkmagenta = 139, 0, 139 | darkolivegreen = 85, 107, 47 | darkorange = 255, 140, 0 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| darkorchid = 153, 50, 204 | darkred = 139, 0, 0 | darksalmon = 233, 150, 122 | darkseagreen = 143, 188, 143 | darkslateblue = 72, 61, 139 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| darkslategray = 47, 79, 79 | darkturquoise = 0, 206, 209 | darkviolet = 148, 0, 211 | deeppink = 255, 20, 147 | deepskyblue = 0, 191, 255 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| dimgray = 105, 105, 105 | dodgerblue = 30, 144, 255 | firebrick = 178, 34, 34 | floralwhite = 255, 250, 240 | forestgreen = 34, 139, 34 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| fuchsia = 255, 0, 255 | gainsboro = 220, 220, 220 | ghostwhite = 248, 248, 255 | gold = 255, 215, 0 | goldenrod = 218, 165, 32 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| gray = 128, 128, 128 | green = 0, 128, 0 | greenyellow = 173, 255, 47 | honeydew = 240, 255, 240 | hotpink = 255, 105, 180 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| indianred = 205, 92, 92 | indigo = 75, 0, 130 | ivory = 255, 240, 240 | khaki = 240, 230, 140 | lavender = 230, 230, 250 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| lavenderblush = 255, 240, 245 | lawngreen = 124, 252, 0 | lemonchiffon = 255, 250, 205 | lightblue = 173, 216, 230 | lightcoral = 240, 128, 128 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| lightcyan = 224, 255, 255 | lightgoldenrodyellow = 250, 250, 210 | lightgreen = 144, 238, 144 | lightgrey = 211, 211, 211 | lightpink = 255, 182, 193 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| lightsalmon = 255, 160, 122 | lightseagreen = 32, 178, 170 | lightskyblue = 135, 206, 250 | lightslategray = 119, 136, 153 | lightsteelblue = 176, 196, 222 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| lightyellow = 255, 255, 224 | lime = 0, 255, 0 | limegreen = 50, 205, 50 | linen = 250, 240, 230 | magenta = 255, 0, 255 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| maroon = 128, 0, 0 | mediumaquamarine = 102, 205, 170 | mediumblue = 0, 0, 205 | mediumorchid = 186, 85, 211 | mediumpurple = 147, 112, 219 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| mediumseagreen = 60, 179, 113 | mediumslateblue = 123, 104, 238 | mediumspringgreen = 0, 250, 154 | mediumturquoise = 72, 209, 204 | mediumvioletred = 199, 21, 133 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| midnightblue = 25, 25, 112 | mintcream = 245, 255, 250 | mistyrose = 255, 228, 225 | moccasin = 255, 228, 181 | navajowhite = 255, 222, 173 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| navy = 0, 0, 128 | oldlace = 253, 245, 230 | olive = 128, 128, 0 | olivedrab = 107, 142, 35 | orange = 255, 165, 0 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| orangered = 255, 69, 0 | orchid = 218, 112, 214 | palegoldenrod = 238, 232, 170 | palegreen = 152, 251, 152 | paleturquoise = 175, 238, 238 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| palevioletred = 219, 112, 147 | papayawhip = 255, 239, 213 | peachpuff = 255, 239, 213 | peru = 205, 133, 63 | pink = 255, 192, 203 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| plum = 221, 160, 221 | powderblue = 176, 224, 230 | purple = 128, 0, 128 | red = 255, 0, 0 | rosybrown = 188, 143, 143 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| royalblue = 65, 105, 225 | saddlebrown = 139, 69, 19 | salmon = 250, 128, 114 | sandybrown = 244, 164, 96 | seagreen = 46, 139, 87 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| seashell = 255, 245, 238 | sienna = 160, 82, 45 | silver = 192, 192, 192 | skyblue = 135, 206, 235 | slateblue = 106, 90, 205 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| slategray = 112, 128, 144 | snow = 255, 250, 250 | springgreen = 0, 255, 127 | steelblue = 70, 130, 180 | tan = 210, 180, 140 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| teal = 0, 128, 128 | thistle = 216, 191, 216 | tomato = 253, 99, 71 | turquoise = 64, 224, 208 | violet = 238, 130, 238 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| wheat = 245, 222, 179 | white = 255, 255, 255 | whitesmoke = 245, 245, 245 | yellow = 255, 255, 0 | yellowgreen = 154, 205, 50 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+

613
doc/src/dump_modify.rst
View File

@ -3,6 +3,9 @@
dump_modify command
===================
:doc:`dump_modify <dump_image>` command for image/movie options
===============================================================
Syntax
""""""
@ -12,8 +15,9 @@ Syntax
* dump-ID = ID of dump to modify
* one or more keyword/value pairs may be appended
* these keywords apply to various dump styles
* keyword = *append* or *at* or *buffer* or *delay* or *element* or *every* or *fileper* or *first* or *flush* or *format* or *image* or *label* or *maxfiles* or *nfile* or *pad* or *pbc* or *precision* or *region* or *refresh* or *scale* or *sfactor* or *sort* or *tfactor* or *thermo* or *thresh* or *time* or *units* or *unwrap*
* keyword = *append* or *at* or *buffer* or *delay* or *element* or *every* or *every/time* or *fileper* or *first* or *flush* or *format* or *header* or *image* or *label* or *maxfiles* or *nfile* or *pad* or *pbc* or *precision* or *region* or *refresh* or *scale* or *sfactor* or *sort* or *tfactor* or *thermo* or *thresh* or *time* or *units* or *unwrap*
.. parsed-literal::
@ -28,6 +32,9 @@ Syntax
*every* arg = N
N = dump every this many timesteps
N can be a variable (see below)
*every/time* arg = Delta
Delta = dump every this interval in simulation time (time units)
Delta can be a variable (see below)
*fileper* arg = Np
Np = write one file for every this many processors
*first* arg = *yes* or *no*
@ -35,6 +42,9 @@ Syntax
*format* args = *line* string, *int* string, *float* string, M string, or *none*
string = C-style format string
M = integer from 1 to N, where N = # of per-atom quantities being output
*header* arg = *yes* or *no*
*yes* to write the header
*no* to not write the header
*image* arg = *yes* or *no*
*label* arg = string
string = character string (e.g. BONDS) to use in header of dump local file
@ -66,56 +76,11 @@ Syntax
*unwrap* arg = *yes* or *no*
* these keywords apply only to the *image* and *movie* :doc:`styles <dump_image>`
* keyword = *acolor* or *adiam* or *amap* or *backcolor* or *bcolor* or *bdiam* or *boxcolor* or *color* or *bitrate* or *framerate* or *header*
* keyword = *acolor* or *adiam* or *amap* or *backcolor* or *bcolor* or *bdiam* or *boxcolor* or *color* or *bitrate* or *framerate*
.. parsed-literal::
*acolor* args = type color
type = atom type or range of types (see below)
color = name of color or color1/color2/...
*adiam* args = type diam
type = atom type or range of types (see below)
diam = diameter of atoms of that type (distance units)
*amap* args = lo hi style delta N entry1 entry2 ... entryN
lo = number or *min* = lower bound of range of color map
hi = number or *max* = upper bound of range of color map
style = 2 letters = "c" or "d" or "s" plus "a" or "f"
"c" for continuous
"d" for discrete
"s" for sequential
"a" for absolute
"f" for fractional
delta = binsize (only used for style "s", otherwise ignored)
binsize = range is divided into bins of this width
N = # of subsequent entries
entry = value color (for continuous style)
value = number or *min* or *max* = single value within range
color = name of color used for that value
entry = lo hi color (for discrete style)
lo/hi = number or *min* or *max* = lower/upper bound of subset of range
color = name of color used for that subset of values
entry = color (for sequential style)
color = name of color used for a bin of values
*backcolor* arg = color
color = name of color for background
*bcolor* args = type color
type = bond type or range of types (see below)
color = name of color or color1/color2/...
*bdiam* args = type diam
type = bond type or range of types (see below)
diam = diameter of bonds of that type (distance units)
*boxcolor* arg = color
color = name of color for simulation box lines and processor sub-domain lines
*color* args = name R G B
name = name of color
R,G,B = red/green/blue numeric values from 0.0 to 1.0
*bitrate* arg = rate
rate = target bitrate for movie in kbps
*framerate* arg = fps
fps = frames per second for movie
*header* arg = *yes* or *no*
*yes* to write the header
*no* to not write the header
see the :doc:`dump image <dump_image>` doc page for details
* these keywords apply only to the */gz* and */zstd* dump styles
* keyword = *compression_level*
@ -126,7 +91,7 @@ Syntax
level = integer specifying the compression level that should be used (see below for supported levels)
* these keywords apply only to the */zstd* dump styles
* keyword = *compression_level*
* keyword = *checksum*
.. parsed-literal::
@ -144,7 +109,6 @@ Examples
dump_modify xtcdump precision 10000 sfactor 0.1
dump_modify 1 every 1000 nfile 20
dump_modify 1 every v_myVar
dump_modify 1 amap min max cf 0.0 3 min green 0.5 yellow max blue boxcolor red
Description
"""""""""""
@ -163,8 +127,9 @@ which allow for use of MPI-IO.
----------
These keywords apply to various dump styles, including the :doc:`dump image <dump_image>` and :doc:`dump movie <dump_image>` styles. The
description gives details.
Unless otherwise noted, the following keywords apply to all the
various dump styles, including the :doc:`dump image <dump_image>` and
:doc:`dump movie <dump_image>` styles.
----------
@ -235,11 +200,19 @@ will be accepted.
----------
The *every* keyword changes the dump frequency originally specified by
the :doc:`dump <dump>` command to a new value. The every keyword can be
specified in one of two ways. It can be a numeric value in which case
it must be > 0. Or it can be an :doc:`equal-style variable <variable>`,
which should be specified as v_name, where name is the variable name.
The *every* keyword can be used with any dump style except the *dcd*
and *xtc* styles. It does two things. It specifies that the interval
between dump snapshots will be set in timesteps, which is the default
if the *every* or *every/time* keywords are not used. See the
*every/time* keyword for how to specify the interval in simulation
time, i.e. in time units of the :doc:`units <units>` command. The
*every* keyword also sets the interval value, which overrides the dump
frequency originally specified by the :doc:`dump <dump>` command.
The *every* keyword can be specified in one of two ways. It can be a
numeric value in which case it must be > 0. Or it can be an
:doc:`equal-style variable <variable>`, which should be specified as
v_name, where name is the variable name.
In this case, the variable is evaluated at the beginning of a run to
determine the next timestep at which a dump snapshot will be written
@ -248,11 +221,12 @@ determine the next timestep, etc. Thus the variable should return
timestep values. See the stagger() and logfreq() and stride() math
functions for :doc:`equal-style variables <variable>`, as examples of
useful functions to use in this context. Other similar math functions
could easily be added as options for :doc:`equal-style variables <variable>`. Also see the next() function, which allows
use of a file-style variable which reads successive values from a
file, each time the variable is evaluated. Used with the *every*
keyword, if the file contains a list of ascending timesteps, you can
output snapshots whenever you wish.
could easily be added as options for :doc:`equal-style variables
<variable>`. Also see the next() function, which allows use of a
file-style variable which reads successive values from a file, each
time the variable is evaluated. Used with the *every* keyword, if the
file contains a list of ascending timesteps, you can output snapshots
whenever you wish.
Note that when using the variable option with the *every* keyword, you
need to use the *first* option if you want an initial snapshot written
@ -293,14 +267,103 @@ in file tmp.times:
----------
The *every/time* keyword can be used with any dump style except the
*dcd* and *xtc* styles. It does two things. It specifies that the
interval between dump snapshots will be set in simulation time,
i.e. in time units of the :doc:`units <units>` command. This can be
useful when the timestep size varies during a simulation run, e.g. by
use of the :doc:`fix dt/reset <fix_dt_reset>` command. The default is
to specify the interval in timesteps; see the *every* keyword. The
*every/time* command also sets the interval value.
.. note::
If you wish dump styles *atom*, *custom*, *local*, or *xyz* to
include the simulation time as a field in the header portion of
each snapshot, you also need to use the dump_modify *time* keyword
with a setting of *yes*. See its documentation below.
Note that since snapshots are output on simulation steps, each
snapshot will be written on the first timestep whose associated
simulation time is >= the exact snapshot time value.
As with the *every* option, the *Delta* value can be specified in one
of two ways. It can be a numeric value in which case it must be >
0.0. Or it can be an :doc:`equal-style variable <variable>`, which
should be specified as v_name, where name is the variable name.
In this case, the variable is evaluated at the beginning of a run to
determine the next simulation time at which a dump snapshot will be
written out. On that timestep the variable will be evaluated again to
determine the next simulation time, etc. Thus the variable should
return values in time units. Note the current timestep or simulation
time can be used in an :doc:`equal-style variables <variable>` since
they are both thermodynamic keywords. Also see the next() function,
which allows use of a file-style variable which reads successive
values from a file, each time the variable is evaluated. Used with
the *every/time* keyword, if the file contains a list of ascending
simulation times, you can output snapshots whenever you wish.
Note that when using the variable option with the *every/time*
keyword, you need to use the *first* option if you want an initial
snapshot written to the dump file. The *every/time* keyword cannot be
used with the dump *dcd* style.
For example, the following commands will write snapshots at successive
simulation times which grow by a factor of 1.5 with each interval.
The dt value used in the variable is to avoid a zero result when the
initial simulation time is 0.0.
.. code-block:: LAMMPS
variable increase equal 1.5*(time+dt)
dump 1 all atom 100 tmp.dump
dump_modify 1 every/time v_increase first yes
The following commands would write snapshots at the times listed in
file tmp.times:
.. code-block:: LAMMPS
variable f file tmp.times
variable s equal next(f)
dump 1 all atom 100 tmp.dump
dump_modify 1 every/time v_s
.. note::
When using a file-style variable with the *every/time* keyword, the
file of timesteps must list a first time that is beyond the time
associated with the current timestep (e.g. it cannot be 0.0). And
it must list one or more times beyond the length of the run you
perform. This is because the dump command will generate an error
if the next time it reads from the file is not a value greater than
the current time. Thus if you wanted output at times 0,15,100 of a
run of length 100 in simulation time, the file should contain the
values 15,100,101 and you should also use the dump_modify first
command. Any final value > 100 could be used in place of 101.
----------
The *first* keyword determines whether a dump snapshot is written on
the very first timestep after the dump command is invoked. This will
always occur if the current timestep is a multiple of N, the frequency
specified in the :doc:`dump <dump>` command, including timestep 0. But
if this is not the case, a dump snapshot will only be written if the
setting of this keyword is *yes*\ . If it is *no*, which is the
always occur if the current timestep is a multiple of $N$, the
frequency specified in the :doc:`dump <dump>` command or
:doc:`dump_modify every <dump_modify>` command, including timestep 0.
It will also always occur if the current simulation time is a multiple
of *Delta*, the time interval specified in the doc:`dump_modify
every/time <dump_modify>` command.
But if this is not the case, a dump snapshot will only be written if
the setting of this keyword is *yes*\ . If it is *no*, which is the
default, then it will not be written.
Note that if the argument to the :doc:`dump_modify every
<dump_modify>` doc:`dump_modify every/time <dump_modify>` commands is
a variable and not a numeric value, then specifying *first yes* is the
only way to write a dump snapshot on the first timestep after the dump
command is invoked.
----------
The *flush* keyword determines whether a flush operation is invoked
@ -380,6 +443,13 @@ The *fileper* keyword is documented below with the *nfile* keyword.
----------
The *header* keyword toggles whether the dump file will include a
header. Excluding a header will reduce the size of the dump file for
fixes such as :doc:`fix pair/tracker <fix_pair_tracker>` which do not
require the information typically written to the header.
----------
The *image* keyword applies only to the dump *atom* style. If the
image value is *yes*, 3 flags are appended to each atom's coords which
are the absolute box image of the atom in each dimension. For
@ -592,7 +662,9 @@ The dump *local* style cannot be sorted by atom ID, since there are
typically multiple lines of output per atom. Some dump styles, such
as *dcd* and *xtc*, require sorting by atom ID to format the output
file correctly. If multiple processors are writing the dump file, via
the "%" wildcard in the dump filename, then sorting cannot be
the "%" wildcard in the dump filename and the *nfile* or *fileper*
keywords are set to non-default values (i.e. the number of dump file
pieces is not equal to the number of procs), then sorting cannot be
performed.
.. note::
@ -670,16 +742,20 @@ threshold criterion is met. Otherwise it is not met.
----------
The *time* keyword only applies to the dump *atom*, *custom*, and
*local* styles (and their COMPRESS package versions *atom/gz*,
*custom/gz* and *local/gz*\ ). If set to *yes*, each frame will will
contain two extra lines before the "ITEM: TIMESTEP" entry:
The *time* keyword only applies to the dump *atom*, *custom*, *local*,
and *xyz* styles (and their COMPRESS package versions *atom/gz*,
*custom/gz* and *local/gz*\ ). For the first 3 styles, if set to
*yes*, each frame will will contain two extra lines before the "ITEM:
TIMESTEP" entry:
.. parsed-literal::
ITEM: TIME
\<elapsed time\>
For the *xyz* style, the simulation time is included on the same line
as the timestep value.
This will output the current elapsed simulation time in current
time units equivalent to the :doc:`thermo keyword <thermo_style>` *time*\ .
This is to simplify post-processing of trajectories using a variable time
@ -715,303 +791,35 @@ box size stored with the snapshot.
----------
These keywords apply only to the :doc:`dump image <dump_image>` and
:doc:`dump movie <dump_image>` styles. Any keyword that affects an
image, also affects a movie, since the movie is simply a collection of
images. Some of the keywords only affect the :doc:`dump movie <dump_image>` style. The descriptions give details.
The COMPRESS package offers both GZ and Zstd compression variants of
styles atom, custom, local, cfg, and xyz. When using these styles the
compression level can be controlled by the :code:`compression_level`
keyword. File names with these styles have to end in either
:code:`.gz` or :code:`.zst`.
----------
The *acolor* keyword can be used with the :doc:`dump image <dump_image>`
command, when its atom color setting is *type*, to set the color that
atoms of each type will be drawn in the image.
The specified *type* should be an integer from 1 to Ntypes = the
number of atom types. A wildcard asterisk can be used in place of or
in conjunction with the *type* argument to specify a range of atom
types. This takes the form "\*" or "\*n" or "n\*" or "m\*n". If N = the
number of atom types, then an asterisk with no numeric values means
all types from 1 to N. A leading asterisk means all types from 1 to n
(inclusive). A trailing asterisk means all types from n to N
(inclusive). A middle asterisk means all types from m to n
(inclusive).
The specified *color* can be a single color which is any of the 140
pre-defined colors (see below) or a color name defined by the
dump_modify color option. Or it can be two or more colors separated
by a "/" character, e.g. red/green/blue. In the former case, that
color is assigned to all the specified atom types. In the latter
case, the list of colors are assigned in a round-robin fashion to each
of the specified atom types.
----------
The *adiam* keyword can be used with the :doc:`dump image <dump_image>`
command, when its atom diameter setting is *type*, to set the size
that atoms of each type will be drawn in the image. The specified
*type* should be an integer from 1 to Ntypes. As with the *acolor*
keyword, a wildcard asterisk can be used as part of the *type*
argument to specify a range of atom types. The specified *diam* is
the size in whatever distance :doc:`units <units>` the input script is
using, e.g. Angstroms.
----------
The *amap* keyword can be used with the :doc:`dump image <dump_image>`
command, with its *atom* keyword, when its atom setting is an
atom-attribute, to setup a color map. The color map is used to assign
a specific RGB (red/green/blue) color value to an individual atom when
it is drawn, based on the atom's attribute, which is a numeric value,
e.g. its x-component of velocity if the atom-attribute "vx" was
specified.
The basic idea of a color map is that the atom-attribute will be
within a range of values, and that range is associated with a series
of colors (e.g. red, blue, green). An atom's specific value (vx =
-3.2) can then mapped to the series of colors (e.g. halfway between
red and blue), and a specific color is determined via an interpolation
procedure.
There are many possible options for the color map, enabled by the
*amap* keyword. Here are the details.
The *lo* and *hi* settings determine the range of values allowed for
the atom attribute. If numeric values are used for *lo* and/or *hi*,
then values that are lower/higher than that value are set to the
value. I.e. the range is static. If *lo* is specified as *min* or
*hi* as *max* then the range is dynamic, and the lower and/or
upper bound will be calculated each time an image is drawn, based
on the set of atoms being visualized.
The *style* setting is two letters, such as "ca". The first letter is
either "c" for continuous, "d" for discrete, or "s" for sequential.
The second letter is either "a" for absolute, or "f" for fractional.
A continuous color map is one in which the color changes continuously
from value to value within the range. A discrete color map is one in
which discrete colors are assigned to sub-ranges of values within the
range. A sequential color map is one in which discrete colors are
assigned to a sequence of sub-ranges of values covering the entire
range.
An absolute color map is one in which the values to which colors are
assigned are specified explicitly as values within the range. A
fractional color map is one in which the values to which colors are
assigned are specified as a fractional portion of the range. For
example if the range is from -10.0 to 10.0, and the color red is to be
assigned to atoms with a value of 5.0, then for an absolute color map
the number 5.0 would be used. But for a fractional map, the number
0.75 would be used since 5.0 is 3/4 of the way from -10.0 to 10.0.
The *delta* setting must be specified for all styles, but is only used
for the sequential style; otherwise the value is ignored. It
specifies the bin size to use within the range for assigning
consecutive colors to. For example, if the range is from -10.0 to
10.0 and a *delta* of 1.0 is used, then 20 colors will be assigned to
the range. The first will be from -10.0 <= color1 < -9.0, then second
from -9.0 <= color2 < -8.0, etc.
The *N* setting is how many entries follow. The format of the entries
depends on whether the color map style is continuous, discrete or
sequential. In all cases the *color* setting can be any of the 140
pre-defined colors (see below) or a color name defined by the
dump_modify color option.
For continuous color maps, each entry has a *value* and a *color*\ .
The *value* is either a number within the range of values or *min* or
*max*\ . The *value* of the first entry must be *min* and the *value*
of the last entry must be *max*\ . Any entries in between must have
increasing values. Note that numeric values can be specified either
as absolute numbers or as fractions (0.0 to 1.0) of the range,
depending on the "a" or "f" in the style setting for the color map.
Here is how the entries are used to determine the color of an
individual atom, given the value X of its atom attribute. X will fall
between 2 of the entry values. The color of the atom is linearly
interpolated (in each of the RGB values) between the 2 colors
associated with those entries. For example, if X = -5.0 and the 2
surrounding entries are "red" at -10.0 and "blue" at 0.0, then the
atom's color will be halfway between "red" and "blue", which happens
to be "purple".
For discrete color maps, each entry has a *lo* and *hi* value and a
*color*\ . The *lo* and *hi* settings are either numbers within the
range of values or *lo* can be *min* or *hi* can be *max*\ . The *lo*
and *hi* settings of the last entry must be *min* and *max*\ . Other
entries can have any *lo* and *hi* values and the sub-ranges of
different values can overlap. Note that numeric *lo* and *hi* values
can be specified either as absolute numbers or as fractions (0.0 to
1.0) of the range, depending on the "a" or "f" in the style setting
for the color map.
Here is how the entries are used to determine the color of an
individual atom, given the value X of its atom attribute. The entries
are scanned from first to last. The first time that *lo* <= X <=
*hi*, X is assigned the color associated with that entry. You can
think of the last entry as assigning a default color (since it will
always be matched by X), and the earlier entries as colors that
override the default. Also note that no interpolation of a color RGB
is done. All atoms will be drawn with one of the colors in the list
of entries.
For sequential color maps, each entry has only a *color*\ . Here is how
the entries are used to determine the color of an individual atom,
given the value X of its atom attribute. The range is partitioned
into N bins of width *binsize*\ . Thus X will fall in a specific bin
from 1 to N, say the Mth bin. If it falls on a boundary between 2
bins, it is considered to be in the higher of the 2 bins. Each bin is
assigned a color from the E entries. If E < N, then the colors are
repeated. For example if 2 entries with colors red and green are
specified, then the odd numbered bins will be red and the even bins
green. The color of the atom is the color of its bin. Note that the
sequential color map is really a shorthand way of defining a discrete
color map without having to specify where all the bin boundaries are.
Here is an example of using a sequential color map to color all the
atoms in individual molecules with a different color. See the
examples/pour/in.pour.2d.molecule input script for an example of how
this is used.
.. code-block:: LAMMPS
variable colors string &
"red green blue yellow white &
purple pink orange lime gray"
variable mol atom mol%10
dump 1 all image 250 image.*.jpg v_mol type &
zoom 1.6 adiam 1.5
dump_modify 1 pad 5 amap 0 10 sa 1 10 ${colors}
In this case, 10 colors are defined, and molecule IDs are
mapped to one of the colors, even if there are 1000s of molecules.
----------
The *backcolor* sets the background color of the images. The color
name can be any of the 140 pre-defined colors (see below) or a color
name defined by the dump_modify color option.
----------
The *bcolor* keyword can be used with the :doc:`dump image <dump_image>`
command, with its *bond* keyword, when its color setting is *type*, to
set the color that bonds of each type will be drawn in the image.
The specified *type* should be an integer from 1 to Nbondtypes = the
number of bond types. A wildcard asterisk can be used in place of or
in conjunction with the *type* argument to specify a range of bond
types. This takes the form "\*" or "\*n" or "n\*" or "m\*n". If N = the
number of bond types, then an asterisk with no numeric values means
all types from 1 to N. A leading asterisk means all types from 1 to n
(inclusive). A trailing asterisk means all types from n to N
(inclusive). A middle asterisk means all types from m to n
(inclusive).
The specified *color* can be a single color which is any of the 140
pre-defined colors (see below) or a color name defined by the
dump_modify color option. Or it can be two or more colors separated
by a "/" character, e.g. red/green/blue. In the former case, that
color is assigned to all the specified bond types. In the latter
case, the list of colors are assigned in a round-robin fashion to each
of the specified bond types.
----------
The *bdiam* keyword can be used with the :doc:`dump image <dump_image>`
command, with its *bond* keyword, when its diam setting is *type*, to
set the diameter that bonds of each type will be drawn in the image.
The specified *type* should be an integer from 1 to Nbondtypes. As
with the *bcolor* keyword, a wildcard asterisk can be used as part of
the *type* argument to specify a range of bond types. The specified
*diam* is the size in whatever distance :doc:`units <units>` you are
using, e.g. Angstroms.
----------
The *bitrate* keyword can be used with the :doc:`dump movie <dump_image>` command to define the size of the resulting
movie file and its quality via setting how many kbits per second are
to be used for the movie file. Higher bitrates require less
compression and will result in higher quality movies. The quality is
also determined by the compression format and encoder. The default
setting is 2000 kbit/s, which will result in average quality with
older compression formats.
.. note::
Not all movie file formats supported by dump movie allow the
bitrate to be set. If not, the setting is silently ignored.
----------
The *boxcolor* keyword sets the color of the simulation box drawn
around the atoms in each image as well as the color of processor
sub-domain boundaries. See the "dump image box" command for how to
specify that a box be drawn via the *box* keyword, and the sub-domain
boundaries via the *subbox* keyword. The color name can be any of the
140 pre-defined colors (see below) or a color name defined by the
dump_modify color option.
----------
The *color* keyword allows definition of a new color name, in addition
to the 140-predefined colors (see below), and associates 3
red/green/blue RGB values with that color name. The color name can
then be used with any other dump_modify keyword that takes a color
name as a value. The RGB values should each be floating point values
between 0.0 and 1.0 inclusive.
When a color name is converted to RGB values, the user-defined color
names are searched first, then the 140 pre-defined color names. This
means you can also use the *color* keyword to overwrite one of the
pre-defined color names with new RBG values.
----------
The *framerate* keyword can be used with the :doc:`dump movie <dump_image>` command to define the duration of the resulting
movie file. Movie files written by the dump *movie* command have a
default frame rate of 24 frames per second and the images generated
will be converted at that rate. Thus a sequence of 1000 dump images
will result in a movie of about 42 seconds. To make a movie run
longer you can either generate images more frequently or lower the
frame rate. To speed a movie up, you can do the inverse. Using a
frame rate higher than 24 is not recommended, as it will result in
simply dropping the rendered images. It is more efficient to dump
images less frequently.
----------
The *header* keyword toggles whether the dump file will include a header.
Excluding a header will reduce the size of the dump file for fixes such as
:doc:`fix pair/tracker <fix_pair_tracker>` which do not require the information
typically written to the header.
----------
The COMPRESS package offers both GZ and Zstd compression variants of styles
atom, custom, local, cfg, and xyz. When using these styles the compression
level can be controlled by the :code:`compression_level` parameter. File names
with these styles have to end in either :code:`.gz` or :code:`.zst`.
GZ supports compression levels from -1 (default), 0 (no compression), and 1 to
9. 9 being the best compression. The COMPRESS :code:`/gz` styles use 9 as
default compression level.
GZ supports compression levels from -1 (default), 0 (no compression),
and 1 to
9. 9 being the best compression. The COMPRESS :code:`/gz` styles use 9
as default compression level.
Zstd offers a wider range of compression levels, including negative
levels that sacrifice compression for performance. 0 is the
default, positive levels are 1 to 22, with 22 being the most expensive
levels that sacrifice compression for performance. 0 is the default,
positive levels are 1 to 22, with 22 being the most expensive
compression. Zstd promises higher compression/decompression speeds for
similar compression ratios. For more details see
`http://facebook.github.io/zstd/`.
In addition, Zstd compressed files can have a checksum of the entire
contents. The Zstd enabled dump styles enable this feature by default and it
can be disabled with the :code:`checksum` parameter.
In addition, Zstd compressed files can include a checksum of the
entire contents. The Zstd enabled dump styles enable this feature by
default and it can be disabled with the :code:`checksum` keyword.
----------
Restrictions
""""""""""""
none
Not all *dump_modify* options can be applied to all dump styles.
Details are in the discussions of the individual options.
Related commands
""""""""""""""""
@ -1046,100 +854,7 @@ The option defaults are
* units = no
* unwrap = no
* acolor = \* red/green/blue/yellow/aqua/cyan
* adiam = \* 1.0
* amap = min max cf 0.0 2 min blue max red
* backcolor = black
* bcolor = \* red/green/blue/yellow/aqua/cyan
* bdiam = \* 0.5
* bitrate = 2000
* boxcolor = yellow
* color = 140 color names are pre-defined as listed below
* framerate = 24
* compression_level = 9 (gz variants)
* compression_level = 0 (zstd variants)
* checksum = yes (zstd variants)
----------
These are the standard 109 element names that LAMMPS pre-defines for
use with the :doc:`dump image <dump_image>` and dump_modify commands.
* 1-10 = "H", "He", "Li", "Be", "B", "C", "N", "O", "F", "Ne"
* 11-20 = "Na", "Mg", "Al", "Si", "P", "S", "Cl", "Ar", "K", "Ca"
* 21-30 = "Sc", "Ti", "V", "Cr", "Mn", "Fe", "Co", "Ni", "Cu", "Zn"
* 31-40 = "Ga", "Ge", "As", "Se", "Br", "Kr", "Rb", "Sr", "Y", "Zr"
* 41-50 = "Nb", "Mo", "Tc", "Ru", "Rh", "Pd", "Ag", "Cd", "In", "Sn"
* 51-60 = "Sb", "Te", "I", "Xe", "Cs", "Ba", "La", "Ce", "Pr", "Nd"
* 61-70 = "Pm", "Sm", "Eu", "Gd", "Tb", "Dy", "Ho", "Er", "Tm", "Yb"
* 71-80 = "Lu", "Hf", "Ta", "W", "Re", "Os", "Ir", "Pt", "Au", "Hg"
* 81-90 = "Tl", "Pb", "Bi", "Po", "At", "Rn", "Fr", "Ra", "Ac", "Th"
* 91-100 = "Pa", "U", "Np", "Pu", "Am", "Cm", "Bk", "Cf", "Es", "Fm"
* 101-109 = "Md", "No", "Lr", "Rf", "Db", "Sg", "Bh", "Hs", "Mt"
----------
These are the 140 colors that LAMMPS pre-defines for use with the
:doc:`dump image <dump_image>` and dump_modify commands. Additional
colors can be defined with the dump_modify color command. The 3
numbers listed for each name are the RGB (red/green/blue) values.
Divide each value by 255 to get the equivalent 0.0 to 1.0 value.
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| aliceblue = 240, 248, 255 | antiquewhite = 250, 235, 215 | aqua = 0, 255, 255 | aquamarine = 127, 255, 212 | azure = 240, 255, 255 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| beige = 245, 245, 220 | bisque = 255, 228, 196 | black = 0, 0, 0 | blanchedalmond = 255, 255, 205 | blue = 0, 0, 255 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| blueviolet = 138, 43, 226 | brown = 165, 42, 42 | burlywood = 222, 184, 135 | cadetblue = 95, 158, 160 | chartreuse = 127, 255, 0 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| chocolate = 210, 105, 30 | coral = 255, 127, 80 | cornflowerblue = 100, 149, 237 | cornsilk = 255, 248, 220 | crimson = 220, 20, 60 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| cyan = 0, 255, 255 | darkblue = 0, 0, 139 | darkcyan = 0, 139, 139 | darkgoldenrod = 184, 134, 11 | darkgray = 169, 169, 169 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| darkgreen = 0, 100, 0 | darkkhaki = 189, 183, 107 | darkmagenta = 139, 0, 139 | darkolivegreen = 85, 107, 47 | darkorange = 255, 140, 0 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| darkorchid = 153, 50, 204 | darkred = 139, 0, 0 | darksalmon = 233, 150, 122 | darkseagreen = 143, 188, 143 | darkslateblue = 72, 61, 139 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| darkslategray = 47, 79, 79 | darkturquoise = 0, 206, 209 | darkviolet = 148, 0, 211 | deeppink = 255, 20, 147 | deepskyblue = 0, 191, 255 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| dimgray = 105, 105, 105 | dodgerblue = 30, 144, 255 | firebrick = 178, 34, 34 | floralwhite = 255, 250, 240 | forestgreen = 34, 139, 34 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| fuchsia = 255, 0, 255 | gainsboro = 220, 220, 220 | ghostwhite = 248, 248, 255 | gold = 255, 215, 0 | goldenrod = 218, 165, 32 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| gray = 128, 128, 128 | green = 0, 128, 0 | greenyellow = 173, 255, 47 | honeydew = 240, 255, 240 | hotpink = 255, 105, 180 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| indianred = 205, 92, 92 | indigo = 75, 0, 130 | ivory = 255, 240, 240 | khaki = 240, 230, 140 | lavender = 230, 230, 250 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| lavenderblush = 255, 240, 245 | lawngreen = 124, 252, 0 | lemonchiffon = 255, 250, 205 | lightblue = 173, 216, 230 | lightcoral = 240, 128, 128 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| lightcyan = 224, 255, 255 | lightgoldenrodyellow = 250, 250, 210 | lightgreen = 144, 238, 144 | lightgrey = 211, 211, 211 | lightpink = 255, 182, 193 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| lightsalmon = 255, 160, 122 | lightseagreen = 32, 178, 170 | lightskyblue = 135, 206, 250 | lightslategray = 119, 136, 153 | lightsteelblue = 176, 196, 222 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| lightyellow = 255, 255, 224 | lime = 0, 255, 0 | limegreen = 50, 205, 50 | linen = 250, 240, 230 | magenta = 255, 0, 255 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| maroon = 128, 0, 0 | mediumaquamarine = 102, 205, 170 | mediumblue = 0, 0, 205 | mediumorchid = 186, 85, 211 | mediumpurple = 147, 112, 219 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| mediumseagreen = 60, 179, 113 | mediumslateblue = 123, 104, 238 | mediumspringgreen = 0, 250, 154 | mediumturquoise = 72, 209, 204 | mediumvioletred = 199, 21, 133 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| midnightblue = 25, 25, 112 | mintcream = 245, 255, 250 | mistyrose = 255, 228, 225 | moccasin = 255, 228, 181 | navajowhite = 255, 222, 173 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| navy = 0, 0, 128 | oldlace = 253, 245, 230 | olive = 128, 128, 0 | olivedrab = 107, 142, 35 | orange = 255, 165, 0 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| orangered = 255, 69, 0 | orchid = 218, 112, 214 | palegoldenrod = 238, 232, 170 | palegreen = 152, 251, 152 | paleturquoise = 175, 238, 238 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| palevioletred = 219, 112, 147 | papayawhip = 255, 239, 213 | peachpuff = 255, 239, 213 | peru = 205, 133, 63 | pink = 255, 192, 203 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| plum = 221, 160, 221 | powderblue = 176, 224, 230 | purple = 128, 0, 128 | red = 255, 0, 0 | rosybrown = 188, 143, 143 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| royalblue = 65, 105, 225 | saddlebrown = 139, 69, 19 | salmon = 250, 128, 114 | sandybrown = 244, 164, 96 | seagreen = 46, 139, 87 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| seashell = 255, 245, 238 | sienna = 160, 82, 45 | silver = 192, 192, 192 | skyblue = 135, 206, 235 | slateblue = 106, 90, 205 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| slategray = 112, 128, 144 | snow = 255, 250, 250 | springgreen = 0, 255, 127 | steelblue = 70, 130, 180 | tan = 210, 180, 140 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| teal = 0, 128, 128 | thistle = 216, 191, 216 | tomato = 253, 99, 71 | turquoise = 64, 224, 208 | violet = 238, 130, 238 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
| wheat = 245, 222, 179 | white = 255, 255, 255 | whitesmoke = 245, 245, 245 | yellow = 255, 255, 0 | yellowgreen = 154, 205, 50 |
+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+

2
doc/src/fix_addtorque.rst
View File

@ -99,7 +99,7 @@ invoked by the :doc:`minimize <minimize>` command.
Restrictions
""""""""""""
This fix is part of the MISC package. It is only enabled if
This fix is part of the EXTRA-FIX package. It is only enabled if
LAMMPS was built with that package. See the :doc:`Build package
<Build_package>` page for more info.

18
doc/src/fix_dt_reset.rst
View File

@ -78,13 +78,20 @@ outer loop (largest) timestep, which is the same timestep that the
Note that the cumulative simulation time (in time units), which
accounts for changes in the timestep size as a simulation proceeds,
can be accessed by the :doc:`thermo_style time <thermo_style>` keyword.
can be accessed by the :doc:`thermo_style time <thermo_style>`
keyword.
Also note that the :doc:`dump_modify every/time <dump_modify>` option
allows dump files to be written at intervals specified by simulation
time, rather than by timesteps. Simulation time is in time units;
see the :doc:`units <units>` doc page for details.
Restart, fix_modify, output, run start/stop, minimize info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
No information about this fix is written to :doc:`binary restart files <restart>`. None of the :doc:`fix_modify <fix_modify>` options
are relevant to this fix.
No information about this fix is written to :doc:`binary restart files
<restart>`. None of the :doc:`fix_modify <fix_modify>` options are
relevant to this fix.
This fix computes a global scalar which can be accessed by various
:doc:`output commands <Howto_output>`. The scalar stores the last
@ -93,7 +100,8 @@ timestep on which the timestep was reset to a new value.
The scalar value calculated by this fix is "intensive".
No parameter of this fix can be used with the *start/stop* keywords of
the :doc:`run <run>` command. This fix is not invoked during :doc:`energy minimization <minimize>`.
the :doc:`run <run>` command. This fix is not invoked during
:doc:`energy minimization <minimize>`.
Restrictions
""""""""""""
@ -102,7 +110,7 @@ Restrictions
Related commands
""""""""""""""""
:doc:`timestep <timestep>`
:doc:`timestep <timestep>`, :doc:`dump_modify every/time <dump_modify>`
Default
"""""""

4
doc/src/fix_langevin_drude.rst
View File

@ -40,7 +40,7 @@ Example input scripts available: examples/PACKAGES/drude
Description
"""""""""""
Apply two Langevin thermostats as described in :ref:`(Jiang) <Jiang1>` for
Apply two Langevin thermostats as described in :ref:`(Jiang1) <Jiang1>` for
thermalizing the reduced degrees of freedom of Drude oscillators.
This link describes how to use the :doc:`thermalized Drude oscillator model <Howto_drude>` in LAMMPS and polarizable models in LAMMPS
are discussed on the :doc:`Howto polarizable <Howto_polarizable>` doc
@ -300,5 +300,5 @@ The option defaults are zero = no.
.. _Jiang1:
**(Jiang)** Jiang, Hardy, Phillips, MacKerell, Schulten, and Roux, J
**(Jiang1)** Jiang, Hardy, Phillips, MacKerell, Schulten, and Roux, J
Phys Chem Lett, 2, 87-92 (2011).

2
doc/src/fix_oneway.rst
View File

@ -51,7 +51,7 @@ the :doc:`run <run>` command. This fix is not invoked during :doc:`energy minim
Restrictions
""""""""""""
This fix is part of the MISC package. It is only enabled if LAMMPS
This fix is part of the EXTRA-FIX package. It is only enabled if LAMMPS
was built with that package. See the :doc:`Build package <Build_package>` page for more info.
Related commands

2
doc/src/fix_smd.rst
View File

@ -144,7 +144,7 @@ the :doc:`run <run>` command. This fix is not invoked during
Restrictions
""""""""""""
This fix is part of the MISC package. It is only enabled if
This fix is part of the EXTRA-FIX package. It is only enabled if
LAMMPS was built with that package. See the :doc:`Build package <Build_package>` page for more info.
Related commands

2
doc/src/kspace_style.rst
View File

@ -310,7 +310,7 @@ Forschungszentrum Juelich.
The library is available for download at "http://scafacos.de" or can
be cloned from the git-repository
"git://github.com/scafacos/scafacos.git".
"https://github.com/scafacos/scafacos.git".
In order to use this KSpace style, you must download and build the
ScaFaCoS library, then build LAMMPS with the SCAFACOS package

2
doc/src/pair_granular.rst
View File

@ -205,7 +205,7 @@ For *damping mass_velocity*, the normal damping is given by:
\eta_n = \eta_{n0} m_{eff}
Here, :math:`\eta_{n0}` is the damping coefficient specified for the normal
contact model, in units of *mass*\ /\ *time* and
contact model, in units of 1/\ *time* and
:math:`m_{eff} = m_i m_j/(m_i + m_j)` is the effective mass.
Use *damping mass_velocity* to reproduce the damping behavior of
*pair gran/hooke/\**.

44
doc/src/pair_hybrid.rst
View File

@ -74,14 +74,17 @@ atoms interact with each other via an *eam* potential, the surface atoms
interact with each other via a *lj/cut* potential, and the metal/surface
interaction is also computed via a *lj/cut* potential. The
*hybrid/overlay* style could be used as in the second example above,
where multiple potentials are superposed in an additive fashion to
where multiple potentials are superimposed in an additive fashion to
compute the interaction between atoms. In this example, using *lj/cut*
and *coul/long* together gives the same result as if the
*lj/cut/coul/long* potential were used by itself. In this case, it
would be more efficient to use the single combined potential, but in
general any combination of pair potentials can be used together in to
produce an interaction that is not encoded in any single pair_style
file, e.g. adding Coulombic forces between granular particles.
file, e.g. adding Coulombic forces between granular particles. Another
limitation of using the *hybrid/overlay* variant, that it does not generate
*lj/cut* parameters for mixed atom types from a mixing rule due to
restrictions discussed below.
If the *hybrid/scaled* style is used instead of *hybrid/overlay*,
contributions from sub-styles are weighted by their scale factors, which
@ -150,10 +153,14 @@ with Tersoff, and the cross-interactions with Lennard-Jones:
pair_coeff * * tersoff 2 C.tersoff NULL C
pair_coeff 1 2 lj/cut 1.0 1.5
If pair coefficients are specified in the data file read via the
:doc:`read_data <read_data>` command, then the same rule applies.
E.g. "eam/alloy" or "lj/cut" must be added after the atom type, for
each line in the "Pair Coeffs" section, e.g.
It is not recommended to read pair coefficients for a hybrid style from a "Pair Coeffs"
or "PairIJ Coeffs" section of a data file via the :doc:`read_data <read_data>` command,
since those sections expect a fixed number of lines, either one line per atom type or
one line pair pair of atom types, respectively. When reading from a data file, the
lines of the "Pair Coeffs" and "PairIJ Coeffs" are changed in the same way as the *pair_coeff*
command, i.e. the name of the pair style to which the parameters apply must follow the
atom type (or atom types), e.g.
.. parsed-literal::
@ -162,6 +169,11 @@ each line in the "Pair Coeffs" section, e.g.
1 lj/cut/coul/cut 1.0 1.0
...
PairIJ Coeffs
1 1 lj/cut/coul/cut 1.0 1.0
...
Note that the pair_coeff command for some potentials such as
:doc:`pair_style eam/alloy <pair_eam>` includes a mapping specification
of elements to all atom types, which in the hybrid case, can include
@ -208,12 +220,22 @@ examples above, or in the data file read by the :doc:`read_data
<read_data>`, or by mixing as described below. Also all sub-styles
must be used at least once in a :doc:`pair_coeff <pair_coeff>` command.
.. note::
.. warning::
LAMMPS never performs mixing of parameters from different sub-styles,
**even** if they use the same type of coefficients, e.g. contain
a Lennard-Jones potential variant. Those parameters must be provided
explicitly.
With hybrid pair styles the use of mixing to generate pair
coefficients is significantly limited compared to the individual pair
styles. LAMMPS **never** performs mixing of parameters from
different sub-styles, **even** if they use the same type of
coefficients, e.g. contain a Lennard-Jones potential variant. Those
parameters must be provided explicitly. Also for *hybrid/overlay*
and *hybrid/scaled* mixing is **only** performed for pairs of atom
types for which only a single pair style is assigned.
Thus it is strongly recommended to provide all mixed terms
explicitly. For non-hybrid styles those could be generated and
written out using the :doc:`write_coeff command <write_coeff>` and
then edited as needed to comply with the requirements for hybrid
styles as explained above.
If you want there to be no interactions between a particular pair of
atom types, you have 3 choices. You can assign the pair of atom types

51
doc/src/pair_lebedeva_z.rst
View File

@ -26,15 +26,29 @@ Examples
Description
"""""""""""
The *lebedeva/z* style computes the Lebedeva interaction
potential as described in :ref:`(Lebedeva et al.) <Leb01>`. An important simplification is made,
which is to take all normals along the z-axis.
The *lebedeva/z* pair style computes the Lebedeva interaction potential
as described in :ref:`(Lebedeva1) <Leb01>` and :ref:`(Lebedeva2)
<Leb02>`. An important simplification is made, which is to take all
normals along the z-axis.
The Lebedeva potential is intended for the description of the interlayer
interaction between graphene layers. To perform a realistic simulation,
this potential must be used in combination with an intralayer potential
such as :doc:`AIREBO <pair_airebo>` or :doc:`Tersoff <pair_tersoff>`
facilitated by using pair style :doc:`hybrid/overlay <pair_hybrid>`. To
keep the intralayer properties unaffected, the interlayer interaction
within the same layers should be avoided. This can be achieved by
assigning different atom types to atoms of different layers (e.g. 1 and
2 in the examples above).
Other interactions can be set to zero using pair_style *none*\ .
.. math::
E = & \frac{1}{2} \sum_i \sum_{i \neq j} V_{ij}\\
E = & \frac{1}{2} \sum_i \sum_{j \neq i} V_{ij}\\
V_{ij} = & B e^{-\alpha(r_{ij} - z_0)} \\
& + C(1 + D_1\rho^2_{ij} + D_2\rho^4_{ij} e^{-\lambda_1\rho^2_{ij}} e^{-\lambda_2 (z^2_{ij} - z^2_0)} \\
& + C(1 + D_1\rho^2_{ij} + D_2\rho^4_{ij}) e^{-\lambda_1\rho^2_{ij}} e^{-\lambda_2 (z^2_{ij} - z^2_0)} \\
& - A \left(\frac{z_0}{r_ij}\right)^6 + A \left( \frac{z_0}{r_c} \right)^6 \\
\rho^2_{ij} = & x^2_{ij} + y^2_{ij} \qquad (\mathbf{n_i} \equiv \mathbf{\hat{z}})
@ -43,12 +57,15 @@ Energies are shifted so that they go continuously to zero at the cutoff assuming
that the exponential part of :math:`V_{ij}` (first term) decays sufficiently fast.
This shift is achieved by the last term in the equation for :math:`V_{ij}` above.
The parameter file (e.g. CC.Lebedeva), is intended for use with metal
:doc:`units <units>`, with energies in meV. An additional parameter, *S*,
is available to facilitate scaling of energies.
The provided parameter file (CC.Lebedeva) contains two sets of parameters.
This potential must be used in combination with hybrid/overlay.
Other interactions can be set to zero using pair_style *none*\ .
- The first set (element name "C") is suitable for normal conditions and
is taken from :ref:`(Popov1) <Popov>`
- The second set (element name "C1") is suitable for high-pressure
conditions and is taken from :ref:`(Koziol1) <Koziol>`
Both sets contain an additional parameter, *S*, that can be used to
facilitate scaling of energies and is set to 1.0 by default.
Restrictions
""""""""""""
@ -77,4 +94,16 @@ none
.. _Leb01:
**(Lebedeva et al.)** I. V. Lebedeva, A. A. Knizhnik, A. M. Popov, Y. E. Lozovik, B. V. Potapkin, Phys. Rev. B, 84, 245437 (2011)
**(Lebedeva1)** I. V. Lebedeva, A. A. Knizhnik, A. M. Popov, Y. E. Lozovik, B. V. Potapkin, Phys. Rev. B, 84, 245437 (2011)
.. _Leb02:
**(Lebedeva2)** I. V. Lebedeva, A. A. Knizhnik, A. M. Popov, Y. E. Lozovik, B. V. Potapkin, Physica E: 44, 949-954 (2012)
.. _Popov:
**(Popov1)** A.M. Popov, I. V. Lebedeva, A. A. Knizhnik, Y. E. Lozovik and B. V. Potapkin, Chem. Phys. Lett. 536, 82-86 (2012).
.. _Koziol:
**(Koziol1)** Z. Koziol, G. Gawlik and J. Jagielski, Chinese Phys. B 28, 096101 (2019).

36
doc/src/pair_local_density.rst
View File

@ -26,23 +26,25 @@ Examples
Description
"""""""""""
The local density (LD) potential is a mean-field manybody potential, and, in some
sense,a generalization of embedded atom models (EAM). The name "local density
potential" arises from the fact that it assigns an energy to an atom depending
on the number of neighboring atoms of given type around it within a predefined
spherical volume (i.e., within a cutoff). The bottom-up coarse-graining (CG)
literature suggests that such potentials can be widely useful in capturing
effective multibody forces in a computationally efficient manner so as to
improve the quality of CG models of implicit solvation:ref:`(Sanyal1) <Sanyal1>` and
phase-segregation in liquid mixtures:ref:`(Sanyal2) <Sanyal2>`, and provide guidelines
to determine the extent of manybody correlations present in a CG
model.:ref:`(Rosenberger) <Rosenberger>` The LD potential in LAMMPS is primarily
intended to be used as a corrective potential over traditional pair potentials
in bottom-up CG models, i.e., as a hybrid pair style with
other explicit pair interaction terms (e.g., table spline, Lennard Jones, etc.).
Because the LD potential is not a pair potential per se, it is implemented
simply as a single auxiliary file with all specifications that will be read
upon initialization.
The local density (LD) potential is a mean-field manybody potential,
and, in some way, a generalization of embedded atom models (EAM). The
name "local density potential" arises from the fact that it assigns an
energy to an atom depending on the number of neighboring atoms of a
given type around it within a predefined spherical volume (i.e., within
the cutoff). The bottom-up coarse-graining (CG) literature suggests
that such potentials can be widely useful in capturing effective
multibody forces in a computationally efficient manner and thus improve
the quality of CG models of implicit solvation :ref:`(Sanyal1)
<Sanyal1>` and phase-segregation in liquid mixtures :ref:`(Sanyal2)
<Sanyal2>`, and provide guidelines to determine the extent of manybody
correlations present in a CG model :ref:`(Rosenberger) <Rosenberger>`.
The LD potential in LAMMPS is primarily intended to be used as a
corrective potential over traditional pair potentials in bottom-up CG
models via :doc:`hybrid/overlay pair style <pair_hybrid>` with other
explicit pair interaction terms (e.g., tabulated, Lennard-Jones, Morse
etc.). Because the LD potential is not a pair potential per se, it is
implemented simply as a single auxiliary file with all specifications
that will be read upon initialization.
.. note::

16
doc/src/pair_meam.rst
View File

@ -28,16 +28,16 @@ Description
as of November 2010; see description below of the mixture_ref_t
parameter
Style *meam* computes pairwise interactions for a variety of materials
using modified embedded-atom method (MEAM) potentials
Pair style *meam* computes non-bonded interactions for a variety of materials
using the modified embedded-atom method (MEAM)
:ref:`(Baskes) <Baskes>`. Conceptually, it is an extension to the original
:doc:`EAM potentials <pair_eam>` which adds angular forces. It is
:doc:`EAM method <pair_eam>` which adds angular forces. It is
thus suitable for modeling metals and alloys with fcc, bcc, hcp and
diamond cubic structures, as well as covalently bonded materials like
silicon and carbon. Style *meam* is a translation of the (now obsolete)
*meam* code from Fortran to C++. It is functionally equivalent to *meam*
but more efficient, and thus *meam* has been removed from LAMMPS after
the 12 December 2018 release.
diamond cubic structures, as well as materials with covalent interactions
like silicon and carbon. This *meam* pair style is a translation of the
original Fortran version to C++. It is functionally equivalent but more
efficient and has additional features. The Fortran version of the *meam*
pair style has been removed from LAMMPS after the 12 December 2018 release.
In the MEAM formulation, the total energy E of a system of atoms is
given by:

20
doc/src/pair_modify.rst
View File

@ -71,21 +71,23 @@ The *mix* keyword affects pair coefficients for interactions between
atoms of type I and J, when I != J and the coefficients are not
explicitly set in the input script. Note that coefficients for I = J
must be set explicitly, either in the input script via the
:doc:`pair_coeff <pair_coeff>` command or in the "Pair Coeffs" section of the
:doc:`data file <read_data>`. For some pair styles it is not
:doc:`pair_coeff <pair_coeff>` command or in the "Pair Coeffs" or "PairIJ Coeffs"
sections of the :doc:`data file <read_data>`. For some pair styles it is not
necessary to specify coefficients when I != J, since a "mixing" rule
will create them from the I,I and J,J settings. The pair_modify
*mix* value determines what formulas are used to compute the mixed
coefficients. In each case, the cutoff distance is mixed the same way
as sigma.
Note that not all pair styles support mixing and some mix options
are not available for certain pair styles. Also, there are additional
restrictions when using :doc:`pair style hybrid or hybrid/overlay <pair_hybrid>`.
See the page for individual pair styles for those restrictions. Note also that the
:doc:`pair_coeff <pair_coeff>` command also can be used to directly set
coefficients for a specific I != J pairing, in which case no mixing is
performed.
Note that not all pair styles support mixing and some mix options are
not available for certain pair styles. Also, there are additional
restrictions when using :doc:`pair style hybrid or hybrid/overlay
<pair_hybrid>`. See the page for individual pair styles for those
restrictions. Note also that the :doc:`pair_coeff <pair_coeff>` command
also can be used to directly set coefficients for a specific I != J
pairing, in which case no mixing is performed. If possible, LAMMPS will
print an informational message about how many of the mixed pair
coefficients were generated and which mixing rule was applied.
- mix *geometric*

29
doc/src/pair_nm.rst
View File

@ -1,4 +1,5 @@
.. index:: pair_style nm/cut
.. index:: pair_style nm/cut/split
.. index:: pair_style nm/cut/coul/cut
.. index:: pair_style nm/cut/coul/long
.. index:: pair_style nm/cut/omp
@ -10,6 +11,9 @@ pair_style nm/cut command
Accelerator Variants: *nm/cut/omp*
pair_style nm/cut/split command
===============================
pair_style nm/cut/coul/cut command
==================================
@ -27,13 +31,15 @@ Syntax
pair_style style args
* style = *nm/cut* or *nm/cut/coul/cut* or *nm/cut/coul/long*
* style = *nm/cut* or *nm/cut/split* or *nm/cut/coul/cut* or *nm/cut/coul/long*
* args = list of arguments for a particular style
.. parsed-literal::
*nm/cut* args = cutoff
cutoff = global cutoff for Pair interactions (distance units)
*nm/cut/split* args = cutoff
cutoff = global cutoff for Pair interactions (distance units)
*nm/cut/coul/cut* args = cutoff (cutoff2)
cutoff = global cutoff for Pair (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
@ -50,6 +56,10 @@ Examples
pair_coeff * * 0.01 5.4 8.0 7.0
pair_coeff 1 1 0.01 4.4 7.0 6.0
pair_style nm/cut/split 1.12246
pair_coeff 1 1 1.0 1.1246 12 6
pair_coeff * * 1.0 1.1246 11 6
pair_style nm/cut/coul/cut 12.0 15.0
pair_coeff * * 0.01 5.4 8.0 7.0
pair_coeff 1 1 0.01 4.4 7.0 6.0
@ -71,7 +81,15 @@ interaction has the following form:
E = \frac{E_0}{(n-m)} \left[ m \left(\frac{r_0}{r}\right)^n - n
\left(\frac{r_0}{r}\right)^m \right] \qquad r < r_c
where :math:`r_c` is the cutoff.
where :math:`r_c` is the cutoff and :math:`r_0` is the minimum of the
potential. Please note that this differs from the convention used for
other Lennard-Jones potentials in LAMMPS where :math:`\sigma` represents
the location where the energy is zero.
Style *nm/cut/split* applies the standard LJ (12-6) potential above
:math:`r_0 = 2^\frac{1}{6}\sigma`. Style *nm/cut/split* is employed in
polymer equilibration protocols that combine core-softening approaches
with topology-changing moves :ref:`Dietz <Dietz>`.
Style *nm/cut/coul/cut* adds a Coulombic pairwise interaction given by
@ -155,7 +173,6 @@ the :doc:`run_style respa <run_style>` command. They do not support the
Restrictions
""""""""""""
These pair styles are part of the EXTRA-PAIR package. They are only enabled if
LAMMPS was built with that package. See the
:doc:`Build package <Build_package>` page for more info.
@ -163,7 +180,7 @@ LAMMPS was built with that package. See the
Related commands
""""""""""""""""
:doc:`pair_coeff <pair_coeff>`
:doc:`pair_coeff <pair_coeff>`, :doc:`pair style lj/cut <pair_lj>`, :doc:`bond style fene/nm <bond_fene>`
Default
"""""""
@ -175,3 +192,7 @@ none
.. _Clarke:
**(Clarke)** Clarke and Smith, J Chem Phys, 84, 2290 (1986).
.. _Dietz:
**(Dietz)** Dietz and Hoy, J. Chem Phys, 156, 014103 (2022).

18
doc/src/pair_python.rst
View File

@ -126,11 +126,11 @@ and *compute_energy*, which both take 3 numerical arguments:
* itype = the (numerical) type of the first atom
* jtype = the (numerical) type of the second atom
This functions need to compute the force and the energy, respectively,
and use the result as return value. The functions need to use the
*pmap* dictionary to convert the LAMMPS atom type number to the symbolic
value of the internal potential parameter data structure. Following
the *LJCutMelt* example, here are the two functions:
This functions need to compute the (scaled) force and the energy,
respectively, and use the result as return value. The functions need
to use the *pmap* dictionary to convert the LAMMPS atom type number
to the symbolic value of the internal potential parameter data structure.
Following the *LJCutMelt* example, here are the two functions:
.. code-block:: python
@ -154,10 +154,10 @@ the *LJCutMelt* example, here are the two functions:
for consistency with the C++ pair styles in LAMMPS, the
*compute_force* function follows the conventions of the Pair::single()
methods and does not return the full force, but the force scaled by
the distance between the two atoms, so this value only needs to be
multiplied by delta x, delta y, and delta z to conveniently obtain the
three components of the force vector between these two atoms.
methods and does not return the pairwise force directly, but the force
divided by the distance between the two atoms, so this value only needs
to be multiplied by delta x, delta y, and delta z to conveniently obtain
the three components of the force vector between these two atoms.
----------

2
doc/src/pair_style.rst
View File

@ -274,6 +274,7 @@ accelerated styles exist.
* :doc:`nm/cut <pair_nm>` - N-M potential
* :doc:`nm/cut/coul/cut <pair_nm>` - N-M potential with cutoff Coulomb
* :doc:`nm/cut/coul/long <pair_nm>` - N-M potential with long-range Coulomb
* :doc:`nm/cut/split <pair_nm>` - Split 12-6 Lennard-Jones and N-M potential
* :doc:`oxdna/coaxstk <pair_oxdna>` -
* :doc:`oxdna/excv <pair_oxdna>` -
* :doc:`oxdna/hbond <pair_oxdna>` -
@ -327,6 +328,7 @@ accelerated styles exist.
* :doc:`spin/neel <pair_spin_neel>` -
* :doc:`srp <pair_srp>` -
* :doc:`sw <pair_sw>` - Stillinger-Weber 3-body potential
* :doc:`sw/mod <pair_sw>` - modified Stillinger-Weber 3-body potential
* :doc:`table <pair_table>` - tabulated pair potential
* :doc:`table/rx <pair_table_rx>` -
* :doc:`tdpd <pair_mesodpd>` - tDPD particle interactions

80
doc/src/pair_sw.rst
View File

@ -3,18 +3,34 @@
.. index:: pair_style sw/intel
.. index:: pair_style sw/kk
.. index:: pair_style sw/omp
.. index:: pair_style sw/mod
.. index:: pair_style sw/mod/omp
pair_style sw command
=====================
Accelerator Variants: *sw/gpu*, *sw/intel*, *sw/kk*, *sw/omp*
pair_style sw/mod command
=========================
Accelerator Variants: *sw/mod/omp*
Syntax
""""""
.. code-block:: LAMMPS
pair_style sw
pair_style style keyword values
* style = *sw* or *sw/mod*
* keyword = *maxdelcs*
.. parsed-literal::
*maxdelcs* value = delta1 delta2 (optional)
delta1 = The minimum thershold for cosine of three-body angle
delta2 = The maximum threshold for cosine of three-body angle
Examples
""""""""
@ -25,6 +41,9 @@ Examples
pair_coeff * * si.sw Si
pair_coeff * * GaN.sw Ga N Ga
pair_style sw/mod maxdelcs 0.25 0.35
pair_coeff * * tmd.sw.mod Mo S S
Description
"""""""""""
@ -48,8 +67,52 @@ where :math:`\phi_2` is a two-body term and :math:`\phi_3` is a
three-body term. The summations in the formula are over all neighbors J
and K of atom I within a cutoff distance :math:`a `\sigma`.
Only a single pair_coeff command is used with the *sw* style which
specifies a Stillinger-Weber potential file with parameters for all
The *sw/mod* style is designed for simulations of materials when
distinguishing three-body angles are necessary, such as borophene
and transition metal dichalcogenide, which cannot be described
by the original code for the Stillinger-Weber potential.
For instance, there are several types of angles around each Mo atom in `MoS_2`,
and some unnecessary angle types should be excluded in the three-body interaction.
Such exclusion may be realized by selecting proper angle types directly.
The exclusion of unnecessary angles is achieved here by the cut-off function (`f_C(\delta)`),
which induces only minimum modifications for LAMMPS.
Validation, benchmark tests, and applications of the *sw/mod* style
can be found in :ref:`(Jiang2) <Jiang2>` and :ref:`(Jiang3) <Jiang3>`.
The *sw/mod* style computes the energy E of a system of atoms, whose potential
function is mostly the same as the Stillinger-Weber potential. The only modification
is in the three-body term, where the value of :math:`\delta = \cos \theta_{ijk} - \cos \theta_{0ijk}`
used in the original energy and force expression is scaled by a switching factor :math:`f_C(\delta)`:
.. math::
f_C(\delta) & = \left\{ \begin{array} {r@{\quad:\quad}l}
1 & \left| \delta \right| < \delta_1 \\
\frac{1}{2} + \frac{1}{2} \cos \left( \pi \frac{\left| \delta \right| - \delta_1}{\delta_2 - \delta_1} \right) &
\delta_1 < \left| \delta \right| < \delta_2 \\
0 & \left| \delta \right| > \delta_2
\end{array} \right. \\
This cut-off function decreases smoothly from 1 to 0 over the range :math:`[\delta_1, \delta_2]`.
This smoothly turns off the energy and force contributions for :math:`\left| \delta \right| > \delta_2`.
It is suggested that :math:`\delta 1` and :math:`\delta_2` to be the value around
:math:`0.5 \left| \cos \theta_1 - \cos \theta_2 \right|`, with
:math:`\theta_1` and :math:`\theta_2` as the different types of angles around an atom.
For borophene and transition metal dichalcogenide, :math:`\delta_1 = 0.25` and :math:`\delta_2 = 0.35`.
This value enables the cut-off function to exclude unnecessary angles in the three-body SW terms.
.. note::
The cut-off function is just to be used as a technique to exclude some unnecessary angles,
and it has no physical meaning. It should be noted that the force and potential are inconsistent
with each other in the decaying range of the cut-off function, as the angle dependence for the
cut-off function is not implemented in the force (first derivation of potential).
However, the angle variation is much smaller than the given threshold value for actual simulations,
so the inconsistency between potential and force can be neglected in actual simulations.
Only a single pair_coeff command is used with the *sw* and *sw/mod* styles
which specifies a Stillinger-Weber potential file with parameters for all
needed elements. These are mapped to LAMMPS atom types by specifying
N additional arguments after the filename in the pair_coeff command,
where N is the number of LAMMPS atom types:
@ -213,10 +276,19 @@ Related commands
Default
"""""""
none
The default values for the *maxdelcs* setting of the *sw/mod* pair
style are *delta1* = 0.25 and *delta2* = 0.35`.
----------
.. _Stillinger2:
**(Stillinger)** Stillinger and Weber, Phys Rev B, 31, 5262 (1985).
.. _Jiang2:
**(Jiang2)** J.-W. Jiang, Nanotechnology 26, 315706 (2015).
.. _Jiang3:
**(Jiang3)** J.-W. Jiang, Acta Mech. Solida. Sin 32, 17 (2019).

2
doc/src/pair_tersoff.rst
View File

@ -23,7 +23,7 @@ Syntax
pair_style style keywords values
* style = *tersoff* or *tersoff/table* or *tersoff/gpu* or *tersoff/omp* or *tersoff/table/omp*
* style = *tersoff* or *tersoff/table*
* keyword = *shift*
.. parsed-literal::

4
doc/src/pair_thole.rst
View File

@ -17,7 +17,7 @@ Syntax
pair_style style args
* style = *thole* or *lj/cut/thole/long* or *lj/cut/thole/long/omp*
* style = *thole* or *lj/cut/thole/long*
* args = list of arguments for a particular style
.. parsed-literal::
@ -25,7 +25,7 @@ Syntax
*thole* args = damp cutoff
damp = global damping parameter
cutoff = global cutoff (distance units)
*lj/cut/thole/long* or *lj/cut/thole/long/omp* args = damp cutoff (cutoff2)
*lj/cut/thole/long* args = damp cutoff (cutoff2)
damp = global damping parameter
cutoff = global cutoff for LJ (and Thole if only 1 arg) (distance units)
cutoff2 = global cutoff for Thole (optional) (distance units)

6
doc/src/pair_vashishta.rst
View File

@ -22,13 +22,13 @@ Syntax
pair_style style args
* style = *vashishta* or *vashishta/table* or *vashishta/omp* or *vashishta/table/omp*
* style = *vashishta* or *vashishta/table*
* args = list of arguments for a particular style
.. parsed-literal::
*vashishta* or *vashishta/omp* args = none
*vashishta/table* or *vashishta/table/omp* args = Ntable cutinner
*vashishta* args = none
*vashishta/table* args = Ntable cutinner
Ntable = # of tabulation points
cutinner = tablulate from cutinner to cutoff

9
doc/src/read_dump.rst
View File

@ -98,8 +98,7 @@ command, after the dump snapshot is read.
----------
If the dump filename specified as *file* ends with ".gz", the dump
file is read in gzipped format. You cannot (yet) read a dump file
that was written in binary format with a ".bin" suffix.
file is read in gzipped format.
You can read dump files that were written (in parallel) to multiple
files via the "%" wild-card character in the dump file name. If any
@ -115,8 +114,8 @@ to tell LAMMPS how many parallel files exist, via its specified
The format of the dump file is selected through the *format* keyword.
If specified, it must be the last keyword used, since all remaining
arguments are passed on to the dump reader. The *native* format is
for native LAMMPS dump files, written with a :doc:`dump atom <dump>` or
:doc:`dump custom <dump>` command. The *xyz* format is for generic XYZ
for native LAMMPS dump files, written with a :doc:`dump atom <dump>`
or :doc:`dump custom <dump>` command. The *xyz* format is for generic XYZ
formatted dump files. These formats take no additional values.
The *molfile* format supports reading data through using the `VMD <vmd_>`_
@ -370,8 +369,6 @@ needed to generate absolute, unscaled coordinates.
Restrictions
""""""""""""
The *native* dump file reader does not support binary .bin dump files.
To read gzipped dump files, you must compile LAMMPS with the
-DLAMMPS_GZIP option. See the :doc:`Build settings <Build_settings>`
doc page for details.