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

Merge branch 'lammps:develop' into fix_reaxff/species-fixes

Browse Source
This commit is contained in:
Jacob Gissinger
2024-02-13 18:46:04 -05:00
committed by GitHub
parent 63332eb1b2 c6a8f1fe58
commit 382a449f58
932 changed files with 16455 additions and 10415 deletions
Download Patch File Download Diff File Expand all files Collapse all files

78
doc/src/Build_development.rst
View File

@ -122,32 +122,39 @@ Code Coverage and Unit Testing (CMake only)
-------------------------------------------
The LAMMPS code is subject to multiple levels of automated testing
during development: integration testing (i.e. whether the code compiles
on various platforms and with a variety of settings), unit testing
(i.e. whether certain individual parts of the code produce the expected
results for given inputs), run testing (whether selected complete input
decks run without crashing for multiple configurations), and regression
testing (i.e. whether selected input examples reproduce the same
results over a given number of steps and operations within a given
error margin). The status of this automated testing can be viewed on
`https://ci.lammps.org <https://ci.lammps.org>`_.
during development:
- Integration testing (i.e. whether the code compiles
on various platforms and with a variety of compilers and settings),
- Unit testing (i.e. whether certain functions or classes of the code
produce the expected results for given inputs),
- Run testing (i.e. whether selected input decks can run to completion
without crashing for multiple configurations),
- Regression testing (i.e. whether selected input examples reproduce the
same results over a given number of steps and operations within a
given error margin).
The status of this automated testing can be viewed on `https://ci.lammps.org
<https://ci.lammps.org>`_.
The scripts and inputs for integration, run, and regression testing
are maintained in a
`separate repository <https://github.com/lammps/lammps-testing>`_
of the LAMMPS project on GitHub.
of the LAMMPS project on GitHub. A few tests are also run as GitHub
Actions and their configuration files are in the ``.github/workflows/``
folder of the LAMMPS git tree.
The unit testing facility is integrated into the CMake build process
of the LAMMPS source code distribution itself. It can be enabled by
The unit testing facility is integrated into the CMake build process of
the LAMMPS source code distribution itself. It can be enabled by
setting ``-D ENABLE_TESTING=on`` during the CMake configuration step.
It requires the `YAML <https://pyyaml.org/>`_ library and development
headers (if those are not found locally a recent version will be
downloaded and compiled along with LAMMPS and the test program) to
compile and will download and compile a specific recent version of the
`Googletest <https://github.com/google/googletest/>`_ C++ test framework
for implementing the tests.
It requires the `YAML <https://pyyaml.org/>`_ library and matching
development headers to compile (if those are not found locally a recent
version of that library will be downloaded and compiled along with
LAMMPS and the test programs) and will download and compile a specific
version of the `GoogleTest <https://github.com/google/googletest/>`_ C++
test framework that is used to implement the tests.
.. admonition:: Software version requirements for testing
.. admonition:: Software version and LAMMPS configuration requirements
:class: note
The compiler and library version requirements for the testing
@ -155,7 +162,7 @@ for implementing the tests.
example the default GNU C++ and Fortran compilers of RHEL/CentOS 7.x
(version 4.8.x) are not sufficient. The CMake configuration will try
to detect incompatible versions and either skip incompatible tests or
stop with an error. Also the number of tests will depend on
stop with an error. Also the number of available tests will depend on
installed LAMMPS packages, development environment, operating system,
and configuration settings.
@ -234,12 +241,31 @@ will be skipped if prerequisite features are not available in LAMMPS.
time. Preference is given to parts of the code base that are easy to
test or commonly used.
Tests for styles of the same kind of style (e.g. pair styles or bond
styles) are performed with the same test executable using different
input files in YAML format. So to add a test for another style of the
same kind it may be sufficient to add a suitable YAML file.
:doc:`Detailed instructions for adding tests <Developer_unittest>` are
provided in the Programmer Guide part of the manual.
Tests as shown by the ``ctest`` program are command lines defined in the
``CMakeLists.txt`` files in the ``unittest`` directory tree. A few
tests simply execute LAMMPS with specific command line flags and check
the output to the screen for expected content. A large number of unit
tests are special tests programs using the `GoogleTest framework
<https://github.com/google/googletest/>`_ and linked to the LAMMPS
library that test individual functions or create a LAMMPS class
instance, execute one or more commands and check data inside the LAMMPS
class hierarchy. There are also tests for the C-library, Fortran, and
Python module interfaces to LAMMPS. The Python tests use the Python
"unittest" module in a similar fashion than the others use `GoogleTest`.
These special test programs are structured to perform multiple
individual tests internally and each of those contains several checks
(aka assertions) for internal data being changed as expected.
Tests for force computing or modifying styles (e.g. styles for non-bonded
and bonded interactions and selected fixes) are run by using a more generic
test program that reads its input from files in YAML format. The YAML file
provides the information on how to customized the test program to test
a specific style and - if needed - with specific settings.
To add a test for another, similar style (e.g. a new pair style) it is
usually sufficient to add a suitable YAML file. :doc:`Detailed
instructions for adding tests <Developer_unittest>` are provided in the
Programmer Guide part of the manual. A description of what happens
during the tests is given below.
Unit tests for force styles
^^^^^^^^^^^^^^^^^^^^^^^^^^^

29
doc/src/Build_settings.rst
View File

@ -44,7 +44,7 @@ require use of an FFT library to compute 1d FFTs. The KISS FFT
library is included with LAMMPS, but other libraries can be faster.
LAMMPS can use them if they are available on your system.
.. versionadded:: TBD
.. versionadded:: 7Feb2024
Alternatively, LAMMPS can use the `heFFTe
<https://icl-utk-edu.github.io/heffte/>`_ library for the MPI
@ -59,15 +59,19 @@ libraries and better pipelining for packing and communication.
.. code-block:: bash
-D FFT=value # FFTW3 or MKL or KISS, default is FFTW3 if found, else KISS
-D FFT_KOKKOS=value # FFTW3 or MKL or KISS or CUFFT or HIPFFT, default is KISS
-D FFT_SINGLE=value # yes or no (default), no = double precision
-D FFT_PACK=value # array (default) or pointer or memcpy
-D FFT_USE_HEFFTE=value # yes or no (default), yes links to heFFTe
.. note::
The values for the FFT variable must be in upper-case. This is
an exception to the rule that all CMake variables can be specified
with lower-case values.
When the Kokkos variant of a package is compiled and selected at run time,
the FFT library selected by the FFT_KOKKOS variable applies. Otherwise,
the FFT library selected by the FFT variable applies.
The same FFT settings apply to both. FFT_KOKKOS must be compatible with the
Kokkos back end - for example, when using the CUDA back end of Kokkos,
you must use either CUFFT or KISS.
Usually these settings are all that is needed. If FFTW3 is
selected, then CMake will try to detect, if threaded FFTW
@ -106,6 +110,8 @@ libraries and better pipelining for packing and communication.
FFT_INC = -DFFT_FFTW3 # -DFFT_FFTW3, -DFFT_FFTW (same as -DFFT_FFTW3), -DFFT_MKL, or -DFFT_KISS
# default is KISS if not specified
FFT_INC = -DFFT_KOKKOS_CUFFT # -DFFT_KOKKOS_{FFTW,FFTW3,MKL,CUFFT,HIPFFT,KISS}
# default is KISS if not specified
FFT_INC = -DFFT_SINGLE # do not specify for double precision
FFT_INC = -DFFT_FFTW_THREADS # enable using threaded FFTW3 libraries
FFT_INC = -DFFT_MKL_THREADS # enable using threaded FFTs with MKL libraries
@ -116,6 +122,8 @@ libraries and better pipelining for packing and communication.
FFT_INC = -I/usr/local/include
FFT_PATH = -L/usr/local/lib
FFT_LIB = -lhipfft # hipFFT either precision
FFT_LIB = -lcufft # cuFFT either precision
FFT_LIB = -lfftw3 # FFTW3 double precision
FFT_LIB = -lfftw3 -lfftw3_omp # FFTW3 double precision with threads (needs -DFFT_FFTW_THREADS)
FFT_LIB = -lfftw3 -lfftw3f # FFTW3 single precision
@ -178,6 +186,11 @@ The Intel MKL math library is part of the Intel compiler suite. It
can be used with the Intel or GNU compiler (see the ``FFT_LIB`` setting
above).
The cuFFT and hipFFT FFT libraries are packaged with NVIDIA's CUDA and
AMD's HIP installations, respectively. These FFT libraries require the
Kokkos acceleration package to be enabled and the Kokkos back end to be
GPU-resident (i.e., HIP or CUDA).
Performing 3d FFTs in parallel can be time-consuming due to data access
and required communication. This cost can be reduced by performing
single-precision FFTs instead of double precision. Single precision
@ -189,11 +202,11 @@ generally less than the difference in precision. Using the
``-DFFT_SINGLE`` setting trades off a little accuracy for reduced memory
use and parallel communication costs for transposing 3d FFT data.
When using ``-DFFT_SINGLE`` with FFTW3, you may need to build the FFTW
library a second time with support for single-precision.
When using ``-DFFT_SINGLE`` with FFTW3, you may need to ensure that
the FFTW3 installation includes support for single-precision.
For FFTW3, do the following, which should produce the additional
library ``libfftw3f.a`` or ``libfftw3f.so``\ .
When compiler FFTW3 from source, you can do the following, which should
produce the additional libraries ``libfftw3f.a`` and/or ``libfftw3f.so``\ .
.. code-block:: bash

2
doc/src/Commands_bond.rst
View File

@ -124,7 +124,7 @@ OPT.
*
*
* :doc:`charmm (iko) <dihedral_charmm>`
* :doc:`charmmfsw <dihedral_charmm>`
* :doc:`charmmfsw (k) <dihedral_charmm>`
* :doc:`class2 (ko) <dihedral_class2>`
* :doc:`cosine/shift/exp (o) <dihedral_cosine_shift_exp>`
* :doc:`fourier (io) <dihedral_fourier>`

2
doc/src/Commands_pair.rst
View File

@ -146,7 +146,7 @@ OPT.
* :doc:`lj/charmm/coul/long/soft (o) <pair_fep_soft>`
* :doc:`lj/charmm/coul/msm (o) <pair_charmm>`
* :doc:`lj/charmmfsw/coul/charmmfsh <pair_charmm>`
* :doc:`lj/charmmfsw/coul/long <pair_charmm>`
* :doc:`lj/charmmfsw/coul/long (k) <pair_charmm>`
* :doc:`lj/class2 (gko) <pair_class2>`
* :doc:`lj/class2/coul/cut (ko) <pair_class2>`
* :doc:`lj/class2/coul/cut/soft <pair_fep_soft>`

2
doc/src/Commands_removed.rst
View File

@ -129,7 +129,7 @@ USER-REAXC.
USER-REAXC package
------------------
.. deprecated:: TBD
.. deprecated:: 7Feb2024
The USER-REAXC package has been renamed to :ref:`REAXFF <PKG-REAXFF>`.
In the process also the pair style and related fixes were renamed to use

66
doc/src/Developer_updating.rst
View File

@ -20,6 +20,7 @@ Available topics in mostly chronological order are:
- `Use ev_init() to initialize variables derived from eflag and vflag`_
- `Use utils::numeric() functions instead of force->numeric()`_
- `Use utils::open_potential() function to open potential files`_
- `Use symbolic Atom and AtomVec constants instead of numerical values`_
- `Simplify customized error messages`_
- `Use of "override" instead of "virtual"`_
- `Simplified and more compact neighbor list requests`_
@ -196,6 +197,71 @@ New:
fp = utils::open_potential(filename, lmp);
Use symbolic Atom and AtomVec constants instead of numerical values
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. versionchanged:: 18Sep2020
Properties in LAMMPS that were represented by integer values (0, 1,
2, 3) to indicate settings in the ``Atom`` and ``AtomVec`` classes (or
classes derived from it) (and its derived classes) have been converted
to use scoped enumerators instead.
.. list-table::
:header-rows: 1
:widths: auto
* - Symbolic Constant
- Value
- Symbolic Constant
- Value
* - Atom::GROW
- 0
- Atom::MAP_NONE
- 0
* - Atom::RESTART
- 1
- Atom::MAP_ARRAY
- 1
* - Atom::BORDER
- 2
- Atom::MAP_HASH
- 2
* - Atom::ATOMIC
- 0
- Atom::MAP_YES
- 3
* - Atom::MOLECULAR
- 1
- AtomVec::PER_ATOM
- 0
* - Atom::TEMPLATE
- 2
- AtomVec::PER_TYPE
- 1
Old:
.. code-block:: c++
molecular = 0;
mass_type = 1;
if (atom->molecular == 2)
if (atom->map_style == 2)
atom->add_callback(0);
atom->delete_callback(id,1);
New:
.. code-block:: c++
molecular = Atom::ATOMIC;
mass_type = AtomVec::PER_TYPE;
if (atom->molecular == Atom::TEMPLATE)
if (atom->map_style == Atom::MAP_HASH)
atom->add_callback(Atom::GROW);
atom->delete_callback(id,Atom::RESTART);
Simplify customized error messages
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

45
doc/src/Fortran.rst
View File

@ -315,6 +315,10 @@ of the contents of the :f:mod:`LIBLAMMPS` Fortran interface to LAMMPS.
:ftype extract_variable: function
:f set_variable: :f:subr:`set_variable`
:ftype set_variable: subroutine
:f set_string_variable: :f:subr:`set_set_string_variable`
:ftype set_string_variable: subroutine
:f set_internal_variable: :f:subr:`set_internal_variable`
:ftype set_internal_variable: subroutine
:f gather_atoms: :f:subr:`gather_atoms`
:ftype gather_atoms: subroutine
:f gather_atoms_concat: :f:subr:`gather_atoms_concat`
@ -1398,7 +1402,28 @@ Procedures Bound to the :f:type:`lammps` Derived Type
Set the value of a string-style variable.
.. versionadded:: 3Nov2022
.. deprecated:: 7Feb2024
This function assigns a new value from the string *str* to the string-style
variable *name*\ . If *name* does not exist or is not a string-style
variable, an error is generated.
.. warning::
This subroutine is deprecated and :f:subr:`set_string_variable`
should be used instead.
:p character(len=*) name: name of the variable
:p character(len=*) str: new value to assign to the variable
:to: :cpp:func:`lammps_set_variable`
--------
.. f:subroutine:: set_string_variable(name, str)
Set the value of a string-style variable.
.. versionadded:: 7Feb2024
This function assigns a new value from the string *str* to the string-style
variable *name*\ . If *name* does not exist or is not a string-style
@ -1406,7 +1431,23 @@ Procedures Bound to the :f:type:`lammps` Derived Type
:p character(len=*) name: name of the variable
:p character(len=*) str: new value to assign to the variable
:to: :cpp:func:`lammps_set_variable`
:to: :cpp:func:`lammps_set_string_variable`
--------
.. f:subroutine:: set_internal_variable(name, val)
Set the value of a internal-style variable.
.. versionadded:: 7Feb2024
This function assigns a new value from the floating-point number *val* to
the internal-style variable *name*\ . If *name* does not exist or is not
an internal-style variable, an error is generated.
:p character(len=*) name: name of the variable
:p read(c_double) val: new value to assign to the variable
:to: :cpp:func:`lammps_set_internal_variable`
--------

2
doc/src/Howto_cmake.rst
View File

@ -349,6 +349,8 @@ Some common LAMMPS specific variables
- when set to ``name`` the LAMMPS executable and library will be called ``lmp_name`` and ``liblammps_name.a``
* - ``FFT``
- select which FFT library to use: ``FFTW3``, ``MKL``, ``KISS`` (default, unless FFTW3 is found)
* - ``FFT_KOKKOS``
- select which FFT library to use in Kokkos-enabled styles: ``FFTW3``, ``MKL``, ``HIPFFT``, ``CUFFT``, ``KISS`` (default)
* - ``FFT_SINGLE``
- select whether to use single precision FFTs (default: ``off``)
* - ``WITH_JPEG``

7
doc/src/Howto_structured_data.rst
View File

@ -52,8 +52,8 @@ JSON
"ke": 2.4962152903997174569
}
YAML format thermo_style output
===============================
YAML format thermo_style or dump_style output
=============================================
Extracting data from log file
-----------------------------
@ -112,6 +112,9 @@ of that run:
Number of runs: 2
TotEng = -4.62140097780047
Extracting data from dump file
------------------------------
.. versionadded:: 4May2022
YAML format output has been added to multiple commands in LAMMPS,

12
doc/src/Library_objects.rst
View File

@ -9,6 +9,8 @@ fixes, or variables in LAMMPS using the following functions:
- :cpp:func:`lammps_extract_variable_datatype`
- :cpp:func:`lammps_extract_variable`
- :cpp:func:`lammps_set_variable`
- :cpp:func:`lammps_set_string_variable`
- :cpp:func:`lammps_set_internal_variable`
- :cpp:func:`lammps_variable_info`
-----------------------
@ -38,6 +40,16 @@ fixes, or variables in LAMMPS using the following functions:
-----------------------
.. doxygenfunction:: lammps_set_string_variable
:project: progguide
-----------------------
.. doxygenfunction:: lammps_set_internal_variable
:project: progguide
-----------------------
.. doxygenfunction:: lammps_variable_info
:project: progguide

33
doc/src/Modify_style.rst
View File

@ -96,6 +96,39 @@ list all non-conforming lines. By adding the `-f` flag to the command
line, they will modify the flagged files to try to remove the detected
issues.
Constants (strongly preferred)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Global or per-file constants should be declared as `static constexpr`
variables rather than via the pre-processor with `#define`. The name of
constants should be all uppercase. This has multiple advantages:
- constants are easily identified as such by their all upper case name
- rather than a pure text substitution during pre-processing, `constexpr
variables` have a type associated with them and are processed later in
the parsing process where the syntax checks and type specific
processing (e.g. via overloads) can be applied to them.
- compilers can emit a warning if the constant is not used and thus can
be removed (we regularly check for and remove dead code like this)
- there are no unexpected substitutions and thus confusing syntax errors
when compiling leading to, for instance, conflicts so that LAMMPS
cannot be compiled with certain combinations of packages (this *has*
happened multiple times in the past).
Pre-processor defines should be limited to macros (but consider C++
templates) and conditional compilation. If a per-processor define must
be used, it should be defined at the top of the .cpp file after the
include statements and at all cost it should be avoided to put them into
header files.
Some sets of commonly used constants are provided in the ``MathConst``
and ``EwaldConst`` namespaces and implemented in the files
``math_const.h`` and ``ewald_const.h``, respectively.
There are always exceptions, special cases, and legacy code in LAMMPS,
so please contact the LAMMPS developers if you are not sure.
Placement of braces (strongly preferred)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

4
doc/src/angle_charmm.rst
View File

@ -70,7 +70,9 @@ for more info.
Related commands
""""""""""""""""
:doc:`angle_coeff <angle_coeff>`
:doc:`angle_coeff <angle_coeff>`, :doc:`pair_style lj/charmm variants <pair_charmm>`,
:doc:`dihedral_style charmm <dihedral_charmm>`,
:doc:`dihedral_style charmmfsw <dihedral_charmm>`, :doc:`fix cmap <fix_cmap>`
Default
"""""""

19
doc/src/angle_lepton.rst
View File

@ -11,7 +11,16 @@ Syntax
.. code-block:: LAMMPS
angle_style lepton
angle_style style args
* style = *lepton*
* args = optional arguments
.. parsed-literal::
args = *auto_offset* or *no_offset*
*auto_offset* = offset the potential energy so that the value at theta0 is 0.0 (default)
*no_offset* = do not offset the potential energy
Examples
""""""""
@ -19,6 +28,7 @@ Examples
.. code-block:: LAMMPS
angle_style lepton
angle_style lepton no_offset
angle_coeff 1 120.0 "k*theta^2; k=250.0"
angle_coeff 2 90.0 "k2*theta^2 + k3*theta^3 + k4*theta^4; k2=300.0; k3=-100.0; k4=50.0"
@ -41,6 +51,13 @@ angle coefficient. For example `"200.0*theta^2"` represents a
U_{angle,i} = K (\theta_i - \theta_0)^2 = K \theta^2 \qquad \theta = \theta_i - \theta_0
.. versionchanged:: 7Feb2024
By default the potential energy U is shifted so that the value U is 0.0
for $theta = theta_0$. This is equivalent to using the optional keyword
*auto_offset*. When using the keyword *no_offset* instead, the
potential energy is not shifted.
The `Lepton library <https://simtk.org/projects/lepton>`_, that the
*lepton* angle style interfaces with, evaluates this expression string
at run time to compute the pairwise energy. It also creates an

614
doc/src/atom_style.rst
View File

@ -49,248 +49,221 @@ Examples
Description
"""""""""""
Define what style of atoms to use in a simulation. This determines
what attributes are associated with the atoms. This command must be
used before a simulation is setup via a :doc:`read_data <read_data>`,
:doc:`read_restart <read_restart>`, or :doc:`create_box <create_box>`
command.
The *atom_style* command selects which per-atom attributes are
associated with atoms in a LAMMPS simulation and thus stored and
communicated with those atoms as well as read from and stored in data
and restart files. Different models (e.g. :doc:`pair styles
<pair_style>`) require access to specific per-atom attributes and thus
require a specific atom style. For example, to compute Coulomb
interactions, the atom must have a "charge" (aka "q") attribute.
A number of distinct atom styles exist that combine attributes. Some
atom styles are a superset of other atom styles. Further attributes
may be added to atoms either via using a hybrid style which provides a
union of the attributes of the sub-styles, or via the :doc:`fix
property/atom <fix_property_atom>` command. The *atom_style* command
must be used before a simulation is setup via a :doc:`read_data
<read_data>`, :doc:`read_restart <read_restart>`, or :doc:`create_box
<create_box>` command.
.. note::
Many of the atom styles discussed here are only enabled if
LAMMPS was built with a specific package, as listed below in the
Restrictions section.
Many of the atom styles discussed here are only enabled if LAMMPS was
built with a specific package, as listed below in the Restrictions
section.
Once a style is assigned, it cannot be changed, so use a style general
enough to encompass all attributes. E.g. with style *bond*, angular
terms cannot be used or added later to the model. It is OK to use a
style more general than needed, though it may be slightly inefficient.
Once a style is selected and the simulation box defined, it cannot be
changed but only augmented with the :doc:`fix property/atom
<fix_property_atom>` command. So one should select an atom style
general enough to encompass all attributes required. E.g. with atom
style *bond*, it is not possible to define angles and use angle styles.
The choice of style affects what quantities are stored by each atom,
what quantities are communicated between processors to enable forces
to be computed, and what quantities are listed in the data file read
by the :doc:`read_data <read_data>` command.
It is OK to use a style more general than needed, though it may be
slightly inefficient because it will allocate and communicate
additional unused data.
These are the additional attributes of each style and the typical
kinds of physical systems they are used to model. All styles store
coordinates, velocities, atom IDs and types. See the
Atom style attributes
"""""""""""""""""""""
The atom style *atomic* has the minimum subset of per-atom attributes
and is also the default setting. It encompasses the following per-atom
attributes (name of the vector or array in the :doc:`Atom class
<Classes_atom>` is given in parenthesis): atom-ID (tag), type (type),
position (x), velocities (v), forces (f), image flags (image), group
membership (mask). Since all atom styles are a superset of atom style
*atomic*\ , they all include these attributes.
This table lists all the available atom styles, which attributes they
provide, which :doc:`package <Packages>` is required to use them, and
what the typical applications are that use them. See the
:doc:`read_data <read_data>`, :doc:`create_atoms <create_atoms>`, and
:doc:`set <set>` commands for info on how to set these various
quantities.
:doc:`set <set>` commands for details on how to set these various
quantities. More information about many of the styles is provided in
the Additional Information section below.
+--------------+-----------------------------------------------------+--------------------------------------+
| *amoeba* | molecular + charge + 1/5 neighbors | AMOEBA/HIPPO polarized force fields |
+--------------+-----------------------------------------------------+--------------------------------------+
| *angle* | bonds and angles | bead-spring polymers with stiffness |
+--------------+-----------------------------------------------------+--------------------------------------+
| *atomic* | only the default values | coarse-grain liquids, solids, metals |
+--------------+-----------------------------------------------------+--------------------------------------+
| *body* | mass, inertia moments, quaternion, angular momentum | arbitrary bodies |
+--------------+-----------------------------------------------------+--------------------------------------+
| *bond* | bonds | bead-spring polymers |
+--------------+-----------------------------------------------------+--------------------------------------+
| *charge* | charge | atomic system with charges |
+--------------+-----------------------------------------------------+--------------------------------------+
| *dielectric* | normx normy normz area/patch ed em epsilon curv | system with surface polarization |
+--------------+-----------------------------------------------------+--------------------------------------+
| *dipole* | charge and dipole moment | system with dipolar particles |
+--------------+-----------------------------------------------------+--------------------------------------+
| *dpd* | internal temperature and internal energies | DPD particles |
+--------------+-----------------------------------------------------+--------------------------------------+
| *edpd* | temperature and heat capacity | eDPD particles |
+--------------+-----------------------------------------------------+--------------------------------------+
| *electron* | charge and spin and eradius | electronic force field |
+--------------+-----------------------------------------------------+--------------------------------------+
| *ellipsoid* | shape, quaternion, angular momentum | aspherical particles |
+--------------+-----------------------------------------------------+--------------------------------------+
| *full* | molecular + charge | bio-molecules |
+--------------+-----------------------------------------------------+--------------------------------------+
| *line* | end points, angular velocity | rigid bodies |
+--------------+-----------------------------------------------------+--------------------------------------+
| *mdpd* | density | mDPD particles |
+--------------+-----------------------------------------------------+--------------------------------------+
| *molecular* | bonds, angles, dihedrals, impropers | uncharged molecules |
+--------------+-----------------------------------------------------+--------------------------------------+
| *oxdna* | nucleotide polarity | coarse-grained DNA and RNA models |
+--------------+-----------------------------------------------------+--------------------------------------+
| *peri* | mass, volume | mesoscopic Peridynamic models |
+--------------+-----------------------------------------------------+--------------------------------------+
| *smd* | volume, kernel diameter, contact radius, mass | solid and fluid SPH particles |
+--------------+-----------------------------------------------------+--------------------------------------+
| *sph* | rho, esph, cv | SPH particles |
+--------------+-----------------------------------------------------+--------------------------------------+
| *sphere* | diameter, mass, angular velocity | granular models |
+--------------+-----------------------------------------------------+--------------------------------------+
| *bpm/sphere* | diameter, mass, angular velocity, quaternion | granular bonded particle models (BPM)|
+--------------+-----------------------------------------------------+--------------------------------------+
| *spin* | magnetic moment | system with magnetic particles |
+--------------+-----------------------------------------------------+--------------------------------------+
| *tdpd* | chemical concentration | tDPD particles |
+--------------+-----------------------------------------------------+--------------------------------------+
| *template* | template index, template atom | small molecules with fixed topology |
+--------------+-----------------------------------------------------+--------------------------------------+
| *tri* | corner points, angular momentum | rigid bodies |
+--------------+-----------------------------------------------------+--------------------------------------+
| *wavepacket* | charge, spin, eradius, etag, cs_re, cs_im | AWPMD |
+--------------+-----------------------------------------------------+--------------------------------------+
.. list-table::
:header-rows: 1
:widths: auto
* - Atom style
- Attributes
- Required package
- Applications
* - *amoeba*
- *full* + "1-5 special neighbor data"
- :ref:`AMOEBA <PKG-AMOEBA>`
- AMOEBA/HIPPO force fields
* - *angle*
- *bond* + "angle data"
- :ref:`MOLECULE <PKG-MOLECULE>`
- bead-spring polymers with stiffness
* - *atomic*
- tag, type, x, v, f, image, mask
-
- atomic liquids, solids, metals
* - *body*
- *atomic* + radius, rmass, angmom, torque, body
- :ref:`BODY <PKG-BODY>`
- arbitrary bodies, see :doc:`body howto <Howto_body>`
* - *bond*
- *atomic* + molecule, nspecial, special + "bond data"
- :ref:`MOLECULE <PKG-MOLECULE>`
- bead-spring polymers
* - *bpm/sphere*
- *bond* + radius, rmass, omega, torque, quat
- :ref:`BPM <PKG-BPM>`
- granular bonded particle models, see :doc:`BPM howto <Howto_bpm>`
* - *charge*
- *atomic* + q
-
- atomic systems with charges
* - *dielectric*
- *full* + mu, area, ed, em, epsilon, curvature, q_scaled
- :ref:`DIELECTRIC <PKG-DIELECTRIC>`
- systems with surface polarization
* - *dipole*
- *charge* + mu
- :ref:`DIPOLE <PKG-DIPOLE>`
- atomic systems with charges and point dipoles
* - *dpd*
- *atomic* + rho + "reactive DPD data"
- :ref:`DPD-REACT <PKG-DPD-REACT>`
- reactive DPD
* - *edpd*
- *atomic* + "eDPD data"
- :ref:`DPD-MESO <PKG-DPD-MESO>`
- Energy conservative DPD (eDPD)
* - *electron*
- *charge* + espin, eradius, ervel, erforce
- :ref:`EFF <PKG-EFF>`
- Electron force field systems
* - *ellipsoid*
- *atomic* + rmass, angmom, torque, ellipsoid
-
- aspherical particles
* - *full*
- *molecular* + q
- :ref:`MOLECULE <PKG-MOLECULE>`
- molecular force fields
* - *line*
- *atomic* + molecule, radius, rmass, omega, torque, line
-
- 2-d rigid body particles
* - *mdpd*
- *atomic* + rho, drho, vest
- :ref:`DPD-MESO <PKG-DPD-MESO>`
- Many-body DPD (mDPD)
* - *molecular*
- *angle* + "dihedral and improper data"
- :ref:`MOLECULE <PKG-MOLECULE>`
- apolar and uncharged molecules
* - *oxdna*
- *atomic* + id5p
- :ref:`CG-DNA <PKG-CG-DNA>`
- coarse-grained DNA and RNA models
* - *peri*
- *atomic* + rmass, vfrac, s0, x0
- :ref:`PERI <PKG-PERI>`
- mesoscopic Peridynamics models
* - *smd*
- *atomic* + molecule, radius, rmass + "smd data"
- :ref:`MACHDYN <PKG-MACHDYN>`
- Smooth Mach Dynamics models
* - *sph*
- *atomic* + "sph data"
- :ref:`SPH <PKG-SPH>`
- Smoothed particle hydrodynamics models
* - *sphere*
- *atomic* + radius, rmass, omega, torque
-
- finite size spherical particles, e.g. granular models
* - *spin*
- *atomic* + "magnetic moment data"
- :ref:`SPIN <PKG-SPIN>`
- magnetic particles
* - *tdpd*
- *atomic* + cc, cc_flux, vest
- :ref:`DPD-MESO <PKG-DPD-MESO>`
- Transport DPD (tDPD)
* - *template*
- *atomic* + molecule, molindex, molatom
- :ref:`MOLECULE <PKG-MOLECULE>`
- molecular systems where attributes are taken from :doc:`molecule files <molecule>`
* - *tri*
- *sphere* + molecule, angmom, tri
-
- 3-d triangulated rigid body LJ particles
* - *wavepacket*
- *charge* + "wavepacket data"
- :ref:`AWPMD <PKG-AWPMD>`
- Antisymmetrized wave packet MD
.. note::
It is possible to add some attributes, such as a molecule ID, to
atom styles that do not have them via the :doc:`fix property/atom
<fix_property_atom>` command. This command also allows new custom
attributes consisting of extra integer or floating-point values to
be added to atoms. See the :doc:`fix property/atom
<fix_property_atom>` page for examples of cases where this is
useful and details on how to initialize, access, and output the
custom values.
It is possible to add some attributes, such as a molecule ID and
charge, to atom styles that do not have them built in using the
:doc:`fix property/atom <fix_property_atom>` command. This command
also allows new custom-named attributes consisting of extra integer
or floating-point values or vectors to be added to atoms. See the
:doc:`fix property/atom <fix_property_atom>` page for examples of
cases where this is useful and details on how to initialize,
access, and output these custom values.
All of the above styles define point particles, except the *sphere*,
*bpm/sphere*, *ellipsoid*, *electron*, *peri*, *wavepacket*, *line*,
*tri*, and *body* styles, which define finite-size particles. See the
:doc:`Howto spherical <Howto_spherical>` page for an overview of using
finite-size particle models with LAMMPS.
----------
All of the point-particle styles assign mass to particles on a
per-type basis, using the :doc:`mass <mass>` command, The finite-size
particle styles assign mass to individual particles on a per-particle
basis.
Particle size and mass
""""""""""""""""""""""
For the *sphere* and *bpm/sphere* styles, the particles are spheres
and each stores a per-particle diameter and mass. If the diameter >
0.0, the particle is a finite-size sphere. If the diameter = 0.0, it
is a point particle. Note that by use of the *disc* keyword with the
:doc:`fix nve/sphere <fix_nve_sphere>`, :doc:`fix nvt/sphere
<fix_nvt_sphere>`, :doc:`fix nph/sphere <fix_nph_sphere>`,
:doc:`fix npt/sphere <fix_npt_sphere>` commands for the *sphere* style,
spheres can be effectively treated as 2d discs for a 2d simulation if
desired. See also the :doc:`set density/disc <set>` command. These
styles take an optional 0 or 1 argument. A value of 0 means the
radius of each sphere is constant for the duration of the simulation.
A value of 1 means the radii may vary dynamically during the simulation,
e.g. due to use of the :doc:`fix adapt <fix_adapt>` command.
All of the atom styles define point particles unless they (1) define
finite-size spherical particles via the *radius* attribute, or (2)
define finite-size aspherical particles (e.g. the *body*, *ellipsoid*,
*line*, and *tri* styles). Most of these styles can also be used with
mixtures of point and finite-size particles.
For the *ellipsoid* style, the particles are ellipsoids and each
stores a flag which indicates whether it is a finite-size ellipsoid or
a point particle. If it is an ellipsoid, it also stores a shape
vector with the 3 diameters of the ellipsoid and a quaternion 4-vector
with its orientation.
Note that the *radius* property may need to be provided as a
*diameter* (e.g. in :doc:`molecule files <molecule>` or :doc:`data
files <read_data>`). See the :doc:`Howto spherical <Howto_spherical>`
page for an overview of using finite-size spherical and aspherical
particle models with LAMMPS.
For the *dielectric* style, each particle can be either a physical
particle (e.g. an ion), or an interface particle representing a boundary
element between two regions of different dielectric constant. For
interface particles, in addition to the properties associated with
atom_style full, each particle also should be assigned a normal unit
vector (defined by normx, normy, normz), an area (area/patch), the
difference and mean of the dielectric constants of two sides of the
interface along the direction of the normal vector (ed and em), the
local dielectric constant at the boundary element (epsilon), and a mean
local curvature (curv). Physical particles must be assigned these
values, as well, but only their local dielectric constants will be used;
see documentation for associated :doc:`pair styles <pair_dielectric>`
and :doc:`fixes <fix_polarize>`. The distinction between the physical
and interface particles is only meaningful when :doc:`fix polarize
<fix_polarize>` commands are applied to the interface particles. This
style is part of the DIELECTRIC package.
Unless an atom style defines the per-atom *rmass* attribute, particle
masses are defined on a per-type basis, using the :doc:`mass <mass>`
command. This means each particle's mass is indexed by its atom
*type*.
For the *dipole* style, a point dipole is defined for each point
particle. Note that if you wish the particles to be finite-size
spheres as in a Stockmayer potential for a dipolar fluid, so that the
particles can rotate due to dipole-dipole interactions, then you need
to use atom_style hybrid sphere dipole, which will assign both a
diameter and dipole moment to each particle.
A few styles define the per-atom *rmass* attribute which can also be
added using the :doc:`fix property/atom <fix_property_atom>` command.
In this case each particle stores its own mass. Atom styles that have
a per-atom rmass may define it indirectly through setting particle
diameter and density on a per-particle basis. If both per-type mass
and per-atom *rmass* are defined (e.g. in a hybrid style), the
per-atom mass will take precedence in any operation which which works
with both flavors of mass.
For the *electron* style, the particles representing electrons are 3d
Gaussians with a specified position and bandwidth or uncertainty in
position, which is represented by the eradius = electron size.
----------
For the *peri* style, the particles are spherical and each stores a
per-particle mass and volume.
The *bpm/sphere* style is part of the BPM package.
The *oxdna* style is for coarse-grained nucleotides and stores the
3'-to-5' polarity of the nucleotide strand, which is set through
the bond topology in the data file. The first (second) atom in a
bond definition is understood to point towards the 3'-end (5'-end)
of the strand. Note that this style is part of the CG-DNA package.
The *dpd* style is for dissipative particle dynamics (DPD) particles.
Note that it is part of the DPD-REACT package, and is not for use with
the :doc:`pair_style dpd or dpd/stat <pair_dpd>` commands, which can
simply use atom_style atomic. Atom_style dpd extends DPD particle
properties with internal temperature (dpdTheta), internal conductive
energy (uCond), internal mechanical energy (uMech), and internal
chemical energy (uChem).
The *edpd* style is for energy-conserving dissipative particle
dynamics (eDPD) particles which store a temperature (edpd_temp), and
heat capacity(edpd_cv).
The *mdpd* style is for many-body dissipative particle dynamics (mDPD)
particles which store a density (rho) for considering
density-dependent many-body interactions.
The *tdpd* style is for transport dissipative particle dynamics (tDPD)
particles which store a set of chemical concentration. An integer
"cc_species" is required to specify the number of chemical species
involved in a tDPD system.
The *sph* style is for smoothed particle hydrodynamics (SPH)
particles which store a density (rho), energy (esph), and heat capacity
(cv).
The *smd* style is for a general formulation of Smooth Particle
Hydrodynamics. Both fluids and solids can be modeled. Particles
store the mass and volume of an integration point, a kernel diameter
used for calculating the field variables (e.g. stress and deformation)
and a contact radius for calculating repulsive forces which prevent
individual physical bodies from penetrating each other.
For the *spin* style, a magnetic spin is associated to each atom.
Those spins have a norm (their magnetic moment) and a direction.
The *wavepacket* style is similar to *electron*, but the electrons may
consist of several Gaussian wave packets, summed up with coefficients
cs= (cs_re,cs_im). Each of the wave packets is treated as a separate
particle in LAMMPS, wave packets belonging to the same electron must
have identical *etag* values.
For the *line* style, the particles are idealized line segments and
each stores a per-particle mass and length and orientation (i.e. the
end points of the line segment).
For the *tri* style, the particles are planar triangles and each
stores a per-particle mass and size and orientation (i.e. the corner
points of the triangle).
The *template* style allows molecular topology (bonds,angles,etc) to be
defined via a molecule template using the :doc:`molecule <molecule>`
command. The template stores one or more molecules with a single copy
of the topology info (bonds,angles,etc) of each. Individual atoms
only store a template index and template atom to identify which
molecule and which atom-within-the-molecule they represent. Using the
*template* style instead of the *bond*, *angle*, *molecular* styles
can save memory for systems comprised of a large number of small
molecules, all of a single type (or small number of types). See the
paper by Grime and Voth, in :ref:`(Grime) <Grime>`, for examples of how this
can be advantageous for large-scale coarse-grained systems.
The ``examples/template`` directory has a few demo inputs and examples
showing the use of the *template* atom style versus *molecular*.
.. note::
When using the *template* style with a :doc:`molecule template
<molecule>` that contains multiple molecules, you should ensure the
atom types, bond types, angle_types, etc in all the molecules are
consistent. E.g. if one molecule represents H2O and another CO2,
then you probably do not want each molecule file to define 2 atom
types and a single bond type, because they will conflict with each
other when a mixture system of H2O and CO2 molecules is defined,
e.g. by the :doc:`read_data <read_data>` command. Rather the H2O
molecule should define atom types 1 and 2, and bond type 1. And
the CO2 molecule should define atom types 3 and 4 (or atom types 3
and 2 if a single oxygen type is desired), and bond type 2.
Additional information about specific atom styles
"""""""""""""""""""""""""""""""""""""""""""""""""
For the *body* style, the particles are arbitrary bodies with internal
attributes defined by the "style" of the bodies, which is specified by
@ -309,6 +282,148 @@ Note that there may be additional arguments required along with the
*bstyle* specification, in the atom_style body command. These
arguments are described on the :doc:`Howto body <Howto_body>` doc page.
For the *dielectric* style, each particle can be either a physical
particle (e.g. an ion), or an interface particle representing a boundary
element between two regions of different dielectric constant. For
interface particles, in addition to the properties associated with
atom_style full, each particle also should be assigned a normal unit
vector (defined by normx, normy, normz), an area (area/patch), the
difference and mean of the dielectric constants of two sides of the
interface along the direction of the normal vector (ed and em), the
local dielectric constant at the boundary element (epsilon), and a mean
local curvature (curv). Physical particles must be assigned these
values, as well, but only their local dielectric constants will be used;
see documentation for associated :doc:`pair styles <pair_dielectric>`
and :doc:`fixes <fix_polarize>`. The distinction between the physical
and interface particles is only meaningful when :doc:`fix polarize
<fix_polarize>` commands are applied to the interface particles. This
style is part of the DIELECTRIC package.
For the *dipole* style, a point dipole vector mu is defined for each
point particle. Note that if you wish the particles to be finite-size
spheres as in a Stockmayer potential for a dipolar fluid, so that the
particles can rotate due to dipole-dipole interactions, then you need
to use the command `atom_style hybrid sphere dipole`, which will
assign both a diameter and dipole moment to each particle. This also
requires using an integrator with a "/sphere" suffix like :doc:`fix
nve/sphere <fix_nve_sphere>` or :doc:`fix nvt/sphere <fix_nvt_sphere>`
and the "update dipole" or "update dlm" parameters to the fix
commands.
The *dpd* style is for reactive dissipative particle dynamics (DPD)
particles. Note that it is part of the DPD-REACT package, and is not
required for use with the :doc:`pair_style dpd or dpd/stat <pair_dpd>`
commands, which only require the attributes from atom_style *atomic*.
Atom_style *dpd* extends DPD particle properties with internal
temperature (dpdTheta), internal conductive energy (uCond), internal
mechanical energy (uMech), and internal chemical energy (uChem).
The *edpd* style is for energy-conserving dissipative particle
dynamics (eDPD) particles which store a temperature (edpd_temp), and
heat capacity (edpd_cv).
For the *electron* style, the particles representing electrons are 3d
Gaussians with a specified position and bandwidth or uncertainty in
position, which is represented by the eradius = electron size.
For the *ellipsoid* style, particles can be ellipsoids which each
stores a shape vector with the 3 diameters of the ellipsoid and a
quaternion 4-vector with its orientation. Each particle stores a flag
in the ellipsoid vector which indicates whether it is an ellipsoid (1)
or a point particle (0).
For the *line* style, particles can be are idealized line segments
which store a per-particle mass and length and orientation (i.e. the
end points of the line segment). Each particle stores a flag in the
line vector which indicates whether it is a line segment (1) or a
point particle (0).
The *mdpd* style is for many-body dissipative particle dynamics (mDPD)
particles which store a density (rho) for considering density-dependent
many-body interactions.
The *oxdna* style is for coarse-grained nucleotides and stores the
3'-to-5' polarity of the nucleotide strand, which is set through
the bond topology in the data file. The first (second) atom in a
bond definition is understood to point towards the 3'-end (5'-end)
of the strand.
For the *peri* style, the particles are spherical and each stores a
per-particle mass and volume.
The *smd* style is for Smooth Particle Mach dynamics. Both fluids and
solids can be modeled. Particles store the mass and volume of an
integration point, a kernel diameter used for calculating the field
variables (e.g. stress and deformation) and a contact radius for
calculating repulsive forces which prevent individual physical bodies
from penetrating each other.
The *sph* style is for smoothed particle hydrodynamics (SPH) particles
which store a density (rho), energy (esph), and heat capacity (cv).
For the *spin* style, a magnetic spin is associated with each atom.
Those spins have a norm (their magnetic moment) and a direction.
The *tdpd* style is for transport dissipative particle dynamics (tDPD)
particles which store a set of chemical concentration. An integer
"cc_species" is required to specify the number of chemical species
involved in a tDPD system.
The *wavepacket* style is similar to the *electron* style, but the
electrons may consist of several Gaussian wave packets, summed up with
coefficients cs= (cs_re,cs_im). Each of the wave packets is treated
as a separate particle in LAMMPS, wave packets belonging to the same
electron must have identical *etag* values.
The *sphere* and *bpm/sphere* styles allow particles to be either point
particles or finite-size particles. If the *radius* attribute is >
0.0, the particle is a finite-size sphere. If the diameter = 0.0, it
is a point particle. Note that by using the *disc* keyword with the
:doc:`fix nve/sphere <fix_nve_sphere>`, :doc:`fix nvt/sphere
<fix_nvt_sphere>`, :doc:`fix nph/sphere <fix_nph_sphere>`, :doc:`fix
npt/sphere <fix_npt_sphere>` commands for the *sphere* style, spheres
can be effectively treated as 2d discs for a 2d simulation if desired.
See also the :doc:`set density/disc <set>` command. These styles also
take an optional 0 or 1 argument. A value of 0 means the radius of
each sphere is constant for the duration of the simulation (this is
the default). A value of 1 means the radii may vary dynamically
during the simulation, e.g. due to use of the :doc:`fix adapt
<fix_adapt>` command.
The *template* style allows molecular topology (bonds,angles,etc) to be
defined via a molecule template using the :doc:`molecule <molecule>`
command. The template stores one or more molecules with a single copy
of the topology info (bonds,angles,etc) of each. Individual atoms only
store a template index and template atom to identify which molecule and
which atom-within-the-molecule they represent. Using the *template*
style instead of the *bond*, *angle*, *molecular* styles can save memory
for systems comprised of a large number of small molecules, all of a
single type (or small number of types). See the paper by Grime and
Voth, in :ref:`(Grime) <Grime>`, for examples of how this can be
advantageous for large-scale coarse-grained systems. The
``examples/template`` directory has a few demo inputs and examples
showing the use of the *template* atom style versus *molecular*.
.. note::
When using the *template* style with a :doc:`molecule template
<molecule>` that contains multiple molecules, you should ensure the
atom types, bond types, angle_types, etc in all the molecules are
consistent. E.g. if one molecule represents H2O and another CO2,
then you probably do not want each molecule file to define 2 atom
types and a single bond type, because they will conflict with each
other when a mixture system of H2O and CO2 molecules is defined,
e.g. by the :doc:`read_data <read_data>` command. Rather the H2O
molecule should define atom types 1 and 2, and bond type 1. And
the CO2 molecule should define atom types 3 and 4 (or atom types 3
and 2 if a single oxygen type is desired), and bond type 2.
For the *tri* style, particles can be planar triangles which each
stores a per-particle mass and size and orientation (i.e. the corner
points of the triangle). Each particle stores a flag in the tri
vector which indicates whether it is a triangle (1) or a point
particle (0).
----------
Typically, simulations require only a single (non-hybrid) atom style.
@ -326,11 +441,12 @@ dipole". When a hybrid style is used, atoms store and communicate the
union of all quantities implied by the individual styles.
When using the *hybrid* style, you cannot combine the *template* style
with another molecular style that stores bond,angle,etc info on a
with another molecular style that stores bond, angle, etc info on a
per-atom basis.
LAMMPS can be extended with new atom styles as well as new body
styles; see the :doc:`Modify <Modify>` doc page.
LAMMPS can be extended with new atom styles as well as new body styles;
see the corresponding manual page on :doc:`modifying & extending LAMMPS
<Modify_atom>`.
----------
@ -346,54 +462,20 @@ This command cannot be used after the simulation box is defined by a
Many of the styles listed above are only enabled if LAMMPS was built
with a specific package, as listed below. See the :doc:`Build package
<Build_package>` page for more info.
The *amoeba* style is part of the AMOEBA package.
The *angle*, *bond*, *full*, *molecular*, and *template* styles are
part of the MOLECULE package.
The *line* and *tri* styles are part of the ASPHERE package.
The *body* style is part of the BODY package.
The *dipole* style is part of the DIPOLE package.
The *peri* style is part of the PERI package for Peridynamics.
The *oxdna* style is part of the CG-DNA package for coarse-grained
simulation of DNA and RNA.
The *electron* style is part of the EFF package for :doc:`electronic
force fields <pair_eff>`.
The *dpd* style is part of the DPD-REACT package for dissipative
particle dynamics (DPD).
The *edpd*, *mdpd*, and *tdpd* styles are part of the DPD-MESO package
for energy-conserving dissipative particle dynamics (eDPD), many-body
dissipative particle dynamics (mDPD), and transport dissipative particle
dynamics (tDPD), respectively.
The *sph* style is part of the SPH package for smoothed particle
hydrodynamics (SPH). See `this PDF guide
<PDF/SPH_LAMMPS_userguide.pdf>`_ to using SPH in LAMMPS.
The *spin* style is part of the SPIN package.
The *wavepacket* style is part of the AWPMD package for the
:doc:`antisymmetrized wave packet MD method <pair_awpmd>`.
<Build_package>` page for more info. The table above lists which package
is required for individual atom styles.
Related commands
""""""""""""""""
:doc:`read_data <read_data>`, :doc:`pair_style <pair_style>`
:doc:`read_data <read_data>`, :doc:`pair_style <pair_style>`,
:doc:`fix property/atom <fix_property_atom>`, :doc:`set <set>`
Default
"""""""
The default atom style is atomic. If atom_style sphere is used its
default argument is 0.
The default atom style is *atomic*. If atom_style *sphere* or
*bpm/sphere* is used, its default argument is 0.
----------

4
doc/src/bond_bpm_rotational.rst
View File

@ -147,8 +147,8 @@ By default, pair forces are not calculated between bonded particles.
Pair forces can alternatively be overlaid on top of bond forces by setting
the *overlay/pair* keyword to *yes*. These settings require specific
:doc:`special_bonds <special_bonds>` settings described in the
restrictions. Further details can be found in the :doc:`how to
<Howto_bpm>` page on BPMs.
restrictions. Further details can be found in the :doc:`how to <Howto_bpm>`
page on BPMs.
.. versionadded:: 28Mar2023

4
doc/src/bond_bpm_spring.rst
View File

@ -113,8 +113,8 @@ By default, pair forces are not calculated between bonded particles.
Pair forces can alternatively be overlaid on top of bond forces by setting
the *overlay/pair* keyword to *yes*. These settings require specific
:doc:`special_bonds <special_bonds>` settings described in the
restrictions. Further details can be found in the :doc:`how to
<Howto_bpm>` page on BPMs.
restrictions. Further details can be found in the :doc:`how to <Howto_bpm>`
page on BPMs.
.. versionadded:: 28Mar2023

19
doc/src/bond_lepton.rst
View File

@ -11,7 +11,16 @@ Syntax
.. code-block:: LAMMPS
bond_style lepton
bond_style style args
* style = *lepton*
* args = optional arguments
.. parsed-literal::
args = *auto_offset* or *no_offset*
*auto_offset* = offset the potential energy so that the value at r0 is 0.0 (default)
*no_offset* = do not offset the potential energy
Examples
""""""""
@ -19,6 +28,7 @@ Examples
.. code-block:: LAMMPS
bond_style lepton
bond_style lepton no_offset
bond_coeff 1 1.5 "k*r^2; k=250.0"
bond_coeff 2 1.1 "k2*r^2 + k3*r^3 + k4*r^4; k2=300.0; k3=-100.0; k4=50.0"
@ -40,6 +50,13 @@ constant *K* of 200.0 energy units:
U_{bond,i} = K (r_i - r_0)^2 = K r^2 \qquad r = r_i - r_0
.. versionchanged:: 7Feb2024
By default the potential energy U is shifted so that he value U is 0.0
for $r = r_0$. This is equivalent to using the optional keyword
*auto_offset*. When using the keyword *no_offset* instead, the
potential energy is not shifted.
The `Lepton library <https://simtk.org/projects/lepton>`_, that the
*lepton* bond style interfaces with, evaluates this expression string at
run time to compute the pairwise energy. It also creates an analytical

2
doc/src/compute_pace.rst
View File

@ -36,7 +36,7 @@ Examples
Description
"""""""""""
.. versionadded:: TBD
.. versionadded:: 7Feb2024
This compute calculates a set of quantities related to the atomic
cluster expansion (ACE) descriptors of the atoms in a group. ACE

2
doc/src/compute_rattlers_atom.rst
View File

@ -32,7 +32,7 @@ Examples
Description
"""""""""""
.. versionadded:: TBD
.. versionadded:: 7Feb2024
Define a compute that identifies rattlers in a system. Rattlers are often
identified in granular or glassy packings as under-coordinated atoms that

2
doc/src/compute_reaxff_atom.rst
View File

@ -40,7 +40,7 @@ Examples
Description
"""""""""""
.. versionadded:: TBD
.. versionadded:: 7Feb2024
Define a computation that extracts bond information computed by the ReaxFF
potential specified by :doc:`pair_style reaxff <pair_reaxff>`.

2
doc/src/compute_slcsa_atom.rst
View File

@ -32,7 +32,7 @@ Examples
Description
"""""""""""
.. versionadded:: TBD
.. versionadded:: 7Feb2024
Define a computation that performs the Supervised Learning Crystal
Structure Analysis (SL-CSA) from :ref:`(Lafourcade) <Lafourcade2023_1>`

5
doc/src/create_atoms.rst
View File

@ -536,6 +536,11 @@ command.
A rotation vector specified for a single molecule must be in
the z-direction for a 2d model.
For :doc:`molecule templates <molecule>` that are created from multiple
files, i.e. contain multiple molecule *sets*, only the first set is
used. To create multiple molecules the files currently need to be
merged and different molecule IDs assigned with a Molecules section.
Related commands
""""""""""""""""

7
doc/src/dihedral_charmm.rst
View File

@ -3,6 +3,7 @@
.. index:: dihedral_style charmm/kk
.. index:: dihedral_style charmm/omp
.. index:: dihedral_style charmmfsw
.. index:: dihedral_style charmmfsw/kk
dihedral_style charmm command
=============================
@ -12,6 +13,8 @@ Accelerator Variants: *charmm/intel*, *charmm/kk*, *charmm/omp*
dihedral_style charmmfsw command
================================
Accelerator Variants: *charmmfsw/kk*
Syntax
""""""
@ -144,7 +147,9 @@ for more info.
Related commands
""""""""""""""""
:doc:`dihedral_coeff <dihedral_coeff>`
:doc:`dihedral_coeff <dihedral_coeff>`,
:doc:`pair_style lj/charmm variants <pair_charmm>`,
:doc:`angle_style charmm <angle_charmm>`, :doc:`fix cmap <fix_cmap>`
Default
"""""""

96
doc/src/fix_neb.rst
View File

@ -109,7 +109,7 @@ Note that in this case the specified *Kspring* is in
force/distance units.
With a value of *ideal*, the spring force is computed as suggested in
ref`(WeinanE) <WeinanE>`
:ref:`(WeinanE) <WeinanE>`
.. math::
@ -120,18 +120,18 @@ and :math:`RD_{ideal}` is the ideal *RD* for which all the images are
equally spaced. I.e. :math:`RD_{ideal} = (i-1) \cdot meanDist` when the
climbing replica is off, where *i* is the replica number). The
*meanDist* is the average distance between replicas. Note that in this
case the specified *Kspring* is in force units. When the climbing replica
is on, :math:`RD_{ideal}` and :math:`meanDist` are calculated separately
each side of the climbing image. Note that the *ideal* form of nudging
can often be more effective at keeping the replicas equally spaced before
climbing, then equally spaced either side of the climbing image whilst
climbing.
case the specified *Kspring* is in force units. When the climbing
replica is on, :math:`RD_{ideal}` and :math:`meanDist` are calculated
separately each side of the climbing image. Note that the *ideal* form
of nudging can often be more effective at keeping the replicas equally
spaced before climbing, then equally spaced either side of the climbing
image whilst climbing.
With a value of *equal* the spring force is computed as for *ideal*
when the climbing replica is off, promoting equidistance. When the climbing
With a value of *equal* the spring force is computed as for *ideal* when
the climbing replica is off, promoting equidistance. When the climbing
replica is on, the spring force is computed to promote equidistant
absolute differences in energy, rather than distance, each side of
the climbing image:
absolute differences in energy, rather than distance, each side of the
climbing image:
.. math::
@ -143,23 +143,22 @@ where *ED* is the cumulative sum of absolute energy differences:
ED = \sum_{i<N} \left|E(R_{i+1}) - E(R_i)\right|,
*meanEdist* is the average absolute energy difference between
replicas up to the climbing image or from the climbing image
to the final image, for images before or after the climbing
image respectively. :math:`ED_{ideal}` is the corresponding
cumulative sum of average absolute energy differences in
each case, in close analogy to *ideal*. This form of nudging
is to aid schemes which integrate forces along, or near to,
NEB pathways such as :doc:`fix_pafi <fix_pafi>`.
*meanEdist* is the average absolute energy difference between replicas
up to the climbing image or from the climbing image to the final image,
for images before or after the climbing image
respectively. :math:`ED_{ideal}` is the corresponding cumulative sum of
average absolute energy differences in each case, in close analogy to
*ideal*. This form of nudging is to aid schemes which integrate forces
along, or near to, NEB pathways such as :doc:`fix_pafi <fix_pafi>`.
----------
The keyword *perp* specifies if and how a perpendicular nudging force
is computed. It adds a spring force perpendicular to the path in
order to prevent the path from becoming too strongly kinked. It can
The keyword *perp* specifies if and how a perpendicular nudging force is
computed. It adds a spring force perpendicular to the path in order to
prevent the path from becoming too strongly kinked. It can
significantly improve the convergence of the NEB calculation when the
resolution is poor. I.e. when few replicas are used; see
:ref:`(Maras) <Maras1>` for details.
resolution is poor. I.e. when few replicas are used; see :ref:`(Maras)
<Maras1>` for details.
The perpendicular spring force is given by
@ -181,10 +180,10 @@ force is added.
By default, no additional forces act on the first and last replicas
during the NEB relaxation, so these replicas simply relax toward their
respective local minima. By using the key word *end*, additional
forces can be applied to the first and/or last replicas, to enable
them to relax toward a MEP while constraining their energy E to the
target energy ETarget.
respective local minima. By using the key word *end*, additional forces
can be applied to the first and/or last replicas, to enable them to
relax toward a MEP while constraining their energy E to the target
energy ETarget.
If :math:`E_{Target} > E`, the interatomic force :math:`F_i` for the
specified replica becomes:
@ -197,33 +196,33 @@ specified replica becomes:
The "spring" constant on the difference in energies is the specified
*Kspring3* value.
When *estyle* is specified as *first*, the force is applied to the
first replica. When *estyle* is specified as *last*, the force is
applied to the last replica. Note that the *end* keyword can be used
twice to add forces to both the first and last replicas.
When *estyle* is specified as *first*, the force is applied to the first
replica. When *estyle* is specified as *last*, the force is applied to
the last replica. Note that the *end* keyword can be used twice to add
forces to both the first and last replicas.
For both these *estyle* settings, the target energy *ETarget* is set
to the initial energy of the replica (at the start of the NEB
calculation).
If the *estyle* is specified as *last/efirst* or *last/efirst/middle*,
force is applied to the last replica, but the target energy *ETarget*
is continuously set to the energy of the first replica, as it evolves
force is applied to the last replica, but the target energy *ETarget* is
continuously set to the energy of the first replica, as it evolves
during the NEB relaxation.
The difference between these two *estyle* options is as follows. When
*estyle* is specified as *last/efirst*, no change is made to the
inter-replica force applied to the intermediate replicas (neither
first or last). If the initial path is too far from the MEP, an
intermediate replica may relax "faster" and reach a lower energy than
the last replica. In this case the intermediate replica will be
relaxing toward its own local minima. This behavior can be prevented
by specifying *estyle* as *last/efirst/middle* which will alter the
inter-replica force applied to intermediate replicas by removing the
contribution of the gradient to the inter-replica force. This will
only be done if a particular intermediate replica has a lower energy
than the first replica. This should effectively prevent the
intermediate replicas from over-relaxing.
inter-replica force applied to the intermediate replicas (neither first
or last). If the initial path is too far from the MEP, an intermediate
replica may relax "faster" and reach a lower energy than the last
replica. In this case the intermediate replica will be relaxing toward
its own local minima. This behavior can be prevented by specifying
*estyle* as *last/efirst/middle* which will alter the inter-replica
force applied to intermediate replicas by removing the contribution of
the gradient to the inter-replica force. This will only be done if a
particular intermediate replica has a lower energy than the first
replica. This should effectively prevent the intermediate replicas from
over-relaxing.
After converging a NEB calculation using an *estyle* of
*last/efirst/middle*, you should check that all intermediate replicas
@ -237,9 +236,10 @@ target energy.
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 global or per-atom quantities are stored
by this fix for access by various :doc:`output commands <Howto_output>`.
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 global or per-atom quantities are stored by
this fix for access by various :doc:`output commands <Howto_output>`.
No parameter of this fix can be used with the *start/stop* keywords of
the :doc:`run <run>` command.

2
doc/src/fix_nonaffine_displacement.rst
View File

@ -44,7 +44,7 @@ Examples
Description
"""""""""""
.. versionadded:: TBD
.. versionadded:: 7Feb2024
This fix computes different metrics of the nonaffine displacement of
particles. The first metric, *d2min* calculates the :math:`D^2_\mathrm{min}`

2
doc/src/fix_qeq.rst
View File

@ -232,8 +232,6 @@ These fixes are part of the QEQ package. They are only enabled if
LAMMPS was built with that package. See the :doc:`Build package
<Build_package>` page for more info.
These qeq fixes are not compatible with the GPU and USER-INTEL packages.
These qeq fixes will ignore electric field contributions from
:doc:`fix efield <fix_efield>`.

9
doc/src/info.rst
View File

@ -10,7 +10,7 @@ Syntax
info args
* args = one or more of the following keywords: *out*, *all*, *system*, *memory*, *communication*, *computes*, *dumps*, *fixes*, *groups*, *regions*, *variables*, *coeffs*, *styles*, *time*, *accelerator*, or *configuration*
* args = one or more of the following keywords: *out*, *all*, *system*, *memory*, *communication*, *computes*, *dumps*, *fixes*, *groups*, *regions*, *variables*, *coeffs*, *styles*, *time*, *accelerator*, *fft* or *configuration*
* *out* values = *screen*, *log*, *append* filename, *overwrite* filename
* *styles* values = *all*, *angle*, *atom*, *bond*, *compute*, *command*, *dump*, *dihedral*, *fix*, *improper*, *integrate*, *kspace*, *minimize*, *pair*, *region*
@ -92,6 +92,13 @@ The *accelerator* category prints out information about compile time
settings of included accelerator support for the GPU, KOKKOS, INTEL,
and OPENMP packages.
.. versionadded:: 7Feb2024
The *fft* category prints out information about the included 3d-FFT
support. This lists the 3d-FFT engine, FFT precision, FFT library
used by the FFT engine. If the KOKKOS package is included, the settings
used for the KOKKOS package are displayed as well.
The *styles* category prints the list of styles available in the
current LAMMPS binary. It supports one of the following options
to control which category of styles is printed out:

5
doc/src/kspace_style.rst
View File

@ -450,7 +450,10 @@ relative RMS error.
For the KOKKOS package, the *pppm/kk* style performs charge
assignment and force interpolation calculations, along with the FFTs
themselves, on the GPU or (optionally) threaded on the CPU when
using OpenMP and FFTW3.
using OpenMP and FFTW3. The specific FFT library is selected using
the FFT_KOKKOS CMake parameter. See the
:doc:`Build settings <Build_settings>` doc page for how to select a
3rd-party FFT library.
----------

138
doc/src/molecule.rst
View File

@ -126,14 +126,50 @@ molecule (header keyword = inertia).
Format of a molecule file
"""""""""""""""""""""""""
The format of an individual molecule file is similar but
(not identical) to the data file read by the :doc:`read_data <read_data>`
commands, and is as follows.
The format of an individual molecule file looks similar but is
different than that of a data file read by the :doc:`read_data <read_data>`
commands. Here is a simple example for a TIP3P water molecule:
.. code-block::
# Water molecule. TIP3P geometry
# header section:
3 atoms
2 bonds
1 angles
# body section:
Coords
1 0.00000 -0.06556 0.00000
2 0.75695 0.52032 0.00000
3 -0.75695 0.52032 0.00000
Types
1 1 # O
2 2 # H
3 2 # H
Charges
1 -0.834
2 0.417
3 0.417
Bonds
1 1 1 2
2 1 1 3
Angles
1 1 2 1 3
A molecule file has a header and a body. The header appears first. The
first line of the header and thus of the molecule file is *always* skipped;
it typically contains a description of the file or a comment from the software
that created the file.
first line of the header and thus of the molecule file is *always*
skipped; it typically contains a description of the file or a comment
from the software that created the file.
Then lines are read one line at a time. Lines can have a trailing
comment starting with '#' that is ignored. There *must* be at least one
@ -158,25 +194,62 @@ appear if the value(s) are different than the default, except when
defining a *body* particle, which requires setting the number of
*atoms* to 1, and setting the *inertia* in a specific section (see below).
* N *atoms* = # of atoms N in molecule, default = 0
* Nb *bonds* = # of bonds Nb in molecule, default = 0
* Na *angles* = # of angles Na in molecule, default = 0
* Nd *dihedrals* = # of dihedrals Nd in molecule, default = 0
* Ni *impropers* = # of impropers Ni in molecule, default = 0
* Nf *fragments* = # of fragments Nf in molecule, default = 0
* Ninteger Ndouble *body* = # of integer and floating-point values
in body particle, default = 0
* Mtotal *mass* = total mass of molecule
* Xc Yc Zc *com* = coordinates of center-of-mass of molecule
* Ixx Iyy Izz Ixy Ixz Iyz *inertia* = 6 components of inertia tensor of molecule
.. list-table::
:header-rows: 1
:widths: auto
For *mass*, *com*, and *inertia*, the default is for LAMMPS to
calculate this quantity itself if needed, assuming the molecules
consist of a set of point particles or finite-size particles (with a
non-zero diameter) that do not overlap. If finite-size particles in
the molecule do overlap, LAMMPS will not account for the overlap
effects when calculating any of these 3 quantities, so you should
pre-compute them yourself and list the values in the file.
* - Number(s)
- Keyword
- Meaning
- Default Value
* - N
- atoms
- # of atoms N in molecule
- 0
* - Nb
- bonds
- # of bonds Nb in molecule
- 0
* - Na
- angles
- # of angles Na in molecule
- 0
* - Nd
- dihedrals
- # of dihedrals Nd in molecule
- 0
* - Ni
- impropers
- # of impropers Ni in molecule
- 0
* - Nf
- fragments
- # of fragments Nf in molecule
- 0
* - Ninteger Ndouble
- body
- # of integer and floating-point values in body particle
- 0
* - Mtotal
- mass
- total mass of molecule
- computed
* - Xc Yc Zc
- com
- coordinates of center-of-mass of molecule
- computed
* - Ixx Iyy Izz Ixy Ixz Iyz
- inertia
- 6 components of inertia tensor of molecule
- computed
For *mass*, *com*, and *inertia*, the default is for LAMMPS to calculate
this quantity itself if needed, assuming the molecules consist of a set
of point particles or finite-size particles (with a non-zero diameter)
that do **not** overlap. If finite-size particles in the molecule
**do** overlap, LAMMPS will not account for the overlap effects when
calculating any of these 3 quantities, so you should pre-compute them
yourself and list the values in the file.
The mass and center-of-mass coordinates (Xc,Yc,Zc) are
self-explanatory. The 6 moments of inertia (ixx,iyy,izz,ixy,ixz,iyz)
@ -188,7 +261,7 @@ internally.
These are the allowed section keywords for the body of the file.
* *Coords, Types, Molecules, Fragments, Charges, Diameters, Masses* = atom-property sections
* *Coords, Types, Molecules, Fragments, Charges, Diameters, Dipoles, Masses* = atom-property sections
* *Bonds, Angles, Dihedrals, Impropers* = molecular topology sections
* *Special Bond Counts, Special Bonds* = special neighbor info
* *Shake Flags, Shake Atoms, Shake Bond Types* = SHAKE info
@ -303,6 +376,21 @@ not listed, the default diameter of each atom in the molecule is 1.0.
----------
.. versionadded:: 7Feb2024
*Dipoles* section:
* one line per atom
* line syntax: ID mux muy muz
* mux,muy,muz = x-, y-, and z-component of point dipole vector of atom
This section is only allowed for :doc:`atom styles <atom_style>` that
support particles with point dipoles, e.g. atom_style dipole. If not
listed, the default dipole component of each atom in the molecule is set
to 0.0.
----------
*Masses* section:
* one line per atom

13
doc/src/neb.rst
View File

@ -10,7 +10,7 @@ Syntax
neb etol ftol N1 N2 Nevery file-style arg keyword values
* etol = stopping tolerance for energy (energy units)
* etol = stopping tolerance for energy (dimensionless)
* ftol = stopping tolerance for force (force units)
* N1 = max # of iterations (timesteps) to run initial NEB
* N2 = max # of iterations (timesteps) to run barrier-climbing NEB
@ -89,10 +89,11 @@ potentials, and the starting configuration when the neb command is
issued should be the same for every replica.
In a NEB calculation each replica is connected to other replicas by
inter-replica nudging forces. These forces are imposed by the :doc:`fix neb <fix_neb>` command, which must be used in conjunction with the
neb command. The group used to define the fix neb command defines the
NEB atoms which are the only ones that inter-replica springs are
applied to. If the group does not include all atoms, then non-NEB
inter-replica nudging forces. These forces are imposed by the
:doc:`fix neb <fix_neb>` command, which must be used in conjunction
with the neb command. The group used to define the fix neb command
defines the NEB atoms which are the only ones that inter-replica springs
are applied to. If the group does not include all atoms, then non-NEB
atoms have no inter-replica springs and the forces they feel and their
motion is computed in the usual way due only to other atoms within
their replica. Conceptually, the non-NEB atoms provide a background
@ -445,7 +446,7 @@ Related commands
""""""""""""""""
:doc:`prd <prd>`, :doc:`temper <temper>`, :doc:`fix langevin <fix_langevin>`,
:doc:`fix viscous <fix_viscous>`
:doc:`fix viscous <fix_viscous>`, :doc:`fix neb <fix_neb>`
Default
"""""""

7
doc/src/pair_charmm.rst
View File

@ -16,6 +16,7 @@
.. index:: pair_style lj/charmm/coul/msm/omp
.. index:: pair_style lj/charmmfsw/coul/charmmfsh
.. index:: pair_style lj/charmmfsw/coul/long
.. index:: pair_style lj/charmmfsw/coul/long/kk
pair_style lj/charmm/coul/charmm command
========================================
@ -43,6 +44,8 @@ pair_style lj/charmmfsw/coul/charmmfsh command
pair_style lj/charmmfsw/coul/long command
=========================================
Accelerator Variants: *lj/charmmfsw/coul/long/kk*
Syntax
""""""
@ -281,7 +284,9 @@ page for more info.
Related commands
""""""""""""""""
:doc:`pair_coeff <pair_coeff>`
:doc:`pair_coeff <pair_coeff>`, :doc:`angle_style charmm <angle_charmm>`,
:doc:`dihedral_style charmm <dihedral_charmm>`,
:doc:`dihedral_style charmmfsw <dihedral_charmm>`, :doc:`fix cmap <fix_cmap>`
Default
"""""""

6
doc/src/pair_lepton.rst
View File

@ -72,7 +72,7 @@ interactions between particles which depend on the distance and have a
cutoff. The potential function must be provided as an expression string
using "r" as the distance variable. With pair style *lepton/coul* one
may additionally reference the charges of the two atoms of the pair with
"qi" and "qj", respectively. With pair style *lepton/coul* one may
"qi" and "qj", respectively. With pair style *lepton/sphere* one may
instead reference the radii of the two atoms of the pair with "radi" and
"radj", respectively; this is half of the diameter that can be set in
:doc:`data files <read_data>` or the :doc:`set command <set>`.
@ -166,8 +166,8 @@ mixing. Thus, expressions for *all* I,J pairs must be specified
explicitly.
Only pair style *lepton* supports the :doc:`pair_modify shift <pair_modify>`
option for shifting the energy of the pair interaction so that it is
0 at the cutoff, pair styles *lepton/coul* and *lepton/sphere* do *not*.
option for shifting the potential energy of the pair interaction so that
it is 0 at the cutoff, pair styles *lepton/coul* and *lepton/sphere* do *not*.
The :doc:`pair_modify table <pair_modify>` options are not relevant for
the these pair styles.

4
doc/src/variable.rst
View File

@ -706,7 +706,7 @@ library. Ceil() is the smallest integer not less than its argument.
Floor() if the largest integer not greater than its argument. Round()
is the nearest integer to its argument.
.. versionadded:: TBD
.. versionadded:: 7Feb2024
The ternary(x,y,z) function is the equivalent of the ternary operator
(? and :) in C or C++. It takes 3 arguments. The first argument is a
@ -1155,7 +1155,7 @@ variable by using the :doc:`compute property/atom
Custom atom properties
----------------------
.. versionadded:: TBD
.. versionadded:: 7Feb2024
Custom atom properties refer to per-atom integer and floating point
vectors or arrays that have been added via the :doc:`fix property/atom