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

merged conflicts in thermo.cpp

Browse Source
This commit is contained in:
Karl Hammond
2022-10-30 14:34:43 -05:00
parent 643865221c e68b0b442e
commit 745f90cb71
3699 changed files with 14186 additions and 6724 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
doc/src/Build_development.rst
View File

@ -147,6 +147,16 @@ 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.
.. admonition:: Software version requirements for testing
:class: note
The compiler and library version requirements for the testing
framework are more strict than for the main part of LAMMPS. For
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 compatible versions and either skip incompatible tests or
stop with an error.
After compilation is complete, the unit testing is started in the build
folder using the ``ctest`` command, which is part of the CMake software.
The output of this command will be looking something like this::

59
doc/src/Build_extras.rst
View File

@ -234,7 +234,7 @@ LAMMPS code. This also applies to the ``-DLAMMPS_BIGBIG``\ ,
Makefile you use.
You can also build the library in one step from the ``lammps/src`` dir,
using a command like these, which simply invoke the ``lib/gpu/Install.py``
using a command like these, which simply invokes the ``lib/gpu/Install.py``
script with the specified args:
.. code-block:: bash
@ -350,7 +350,7 @@ minutes to hours) to build. Of course you only need to do that once.)
You can download and build the KIM library manually if you prefer;
follow the instructions in ``lib/kim/README``. You can also do
this in one step from the lammps/src directory, using a command like
these, which simply invoke the ``lib/kim/Install.py`` script with
these, which simply invokes the ``lib/kim/Install.py`` script with
the specified args.
.. code-block:: bash
@ -954,7 +954,7 @@ more details.
You can download and build the MS-CG library manually if you
prefer; follow the instructions in ``lib/mscg/README``\ . You can
also do it in one step from the ``lammps/src`` dir, using a
command like these, which simply invoke the
command like these, which simply invokes the
``lib/mscg/Install.py`` script with the specified args:
.. code-block:: bash
@ -1011,7 +1011,7 @@ POEMS package
``lib/poems``\ . You can do this manually if you prefer; follow
the instructions in ``lib/poems/README``\ . You can also do it in
one step from the ``lammps/src`` dir, using a command like these,
which simply invoke the ``lib/poems/Install.py`` script with the
which simply invokes the ``lib/poems/Install.py`` script with the
specified args:
.. code-block:: bash
@ -1100,7 +1100,7 @@ binary package provided by your operating system.
You can download and build the Voro++ library manually if you
prefer; follow the instructions in ``lib/voronoi/README``. You
can also do it in one step from the ``lammps/src`` dir, using a
command like these, which simply invoke the
command like these, which simply invokes the
``lib/voronoi/Install.py`` script with the specified args:
.. code-block:: bash
@ -1179,7 +1179,7 @@ The ATC package requires the MANYBODY package also be installed.
``lib/atc``. You can do this manually if you prefer; follow the
instructions in ``lib/atc/README``. You can also do it in one
step from the ``lammps/src`` dir, using a command like these,
which simply invoke the ``lib/atc/Install.py`` script with the
which simply invokes the ``lib/atc/Install.py`` script with the
specified args:
.. code-block:: bash
@ -1230,7 +1230,7 @@ AWPMD package
``lib/awpmd``. You can do this manually if you prefer; follow the
instructions in ``lib/awpmd/README``. You can also do it in one
step from the ``lammps/src`` dir, using a command like these,
which simply invoke the ``lib/awpmd/Install.py`` script with the
which simply invokes the ``lib/awpmd/Install.py`` script with the
specified args:
.. code-block:: bash
@ -1293,7 +1293,7 @@ be built for the most part with all major versions of the C++ language.
In general, it is safer to use build setting consistent with the
rest of LAMMPS. This is best carried out from the LAMMPS src
directory using a command like these, which simply invoke the
directory using a command like these, which simply invokes the
``lib/colvars/Install.py`` script with the specified args:
.. code-block:: bash
@ -1334,20 +1334,30 @@ This package depends on the KSPACE package.
.. tab:: CMake build
No additional settings are needed besides ``-D PKG_KSPACE=yes`` and ``-D
PKG_ELECTRODE=yes``.
No additional settings are needed besides ``-D PKG_KSPACE=yes`` and
``-D PKG_ELECTRODE=yes``.
.. tab:: Traditional make
The package is activated with ``make yes-KSPACE`` and ``make
yes-ELECTRODE``
Before building LAMMPS, you must configure the ELECTRODE support
libraries and settings in ``lib/electrode``. You can do this
manually, if you prefer, or do it in one step from the
``lammps/src`` dir, using a command like these, which simply
invokes the ``lib/electrode/Install.py`` script with the specified
args:
.. code-block:: bash
$ make lib-electrode # print help message
$ make lib-electrode args="-m serial" # build with GNU g++ compiler and MPI STUBS (settings as with "make serial")
$ make lib-electrode args="-m mpi" # build with default MPI compiler (settings as with "make mpi")
Note that the ``Makefile.lammps`` file has settings for the BLAS and
LAPACK linear algebra libraries. As explained in ``lib/awpmd/README``
these can either exist on your system, or you can use the files provided
in ``lib/linalg``. In the latter case you also need to build the library
in ``lib/linalg`` with a command like these:
Note that the ``Makefile.lammps`` file has settings for the BLAS
and LAPACK linear algebra libraries. These can either exist on
your system, or you can use the files provided in ``lib/linalg``.
In the latter case you also need to build the library in
``lib/linalg`` with a command like these:
.. code-block:: bash
@ -1356,6 +1366,9 @@ This package depends on the KSPACE package.
$ make lib-linalg args="-m mpi" # build with default MPI Fortran compiler (settings as with "make mpi")
$ make lib-linalg args="-m gfortran" # build with GNU Fortran compiler
The package itself is activated with ``make yes-KSPACE`` and
``make yes-ELECTRODE``
----------
.. _ml-pace:
@ -1555,7 +1568,7 @@ the HDF5 library.
``lib/h5md``. You can do this manually if you prefer; follow the
instructions in ``lib/h5md/README``. You can also do it in one
step from the ``lammps/src`` dir, using a command like these,
which simply invoke the ``lib/h5md/Install.py`` script with the
which simply invokes the ``lib/h5md/Install.py`` script with the
specified args:
.. code-block:: bash
@ -1611,7 +1624,7 @@ details please see ``lib/hdnnp/README`` and the `n2p2 build documentation
You can download and build the *n2p2* library manually if you prefer;
follow the instructions in ``lib/hdnnp/README``\ . You can also do it in
one step from the ``lammps/src`` dir, using a command like these, which
simply invoke the ``lib/hdnnp/Install.py`` script with the specified args:
simply invokes the ``lib/hdnnp/Install.py`` script with the specified args:
.. code-block:: bash
@ -1748,7 +1761,7 @@ they will be downloaded the first time this package is installed.
Before building LAMMPS, you must build the *mesont* library in
``lib/mesont``\ . You can also do it in one step from the
``lammps/src`` dir, using a command like these, which simply
invoke the ``lib/mesont/Install.py`` script with the specified
invokes the ``lib/mesont/Install.py`` script with the specified
args:
.. code-block:: bash
@ -1917,7 +1930,7 @@ verified to work in February 2020 with Quantum Espresso versions 6.3 to
``lib/qmmm``. You can do this manually if you prefer; follow the
first two steps explained in ``lib/qmmm/README``. You can also do
it in one step from the ``lammps/src`` dir, using a command like
these, which simply invoke the ``lib/qmmm/Install.py`` script with
these, which simply invokes the ``lib/qmmm/Install.py`` script with
the specified args:
.. code-block:: bash
@ -2025,7 +2038,7 @@ To build with this package, you must download and build the
You can download and build the ScaFaCoS library manually if you
prefer; follow the instructions in ``lib/scafacos/README``. You
can also do it in one step from the ``lammps/src`` dir, using a
command like these, which simply invoke the
command like these, which simply invokes the
``lib/scafacos/Install.py`` script with the specified args:
.. code-block:: bash
@ -2069,7 +2082,7 @@ Eigen3 is a template library, so you do not need to build it.
You can download the Eigen3 library manually if you prefer; follow
the instructions in ``lib/smd/README``. You can also do it in one
step from the ``lammps/src`` dir, using a command like these,
which simply invoke the ``lib/smd/Install.py`` script with the
which simply invokes the ``lib/smd/Install.py`` script with the
specified args:
.. code-block:: bash

1
doc/src/Commands_pair.rst
View File

@ -295,6 +295,7 @@ OPT.
* :doc:`vashishta (gko) <pair_vashishta>`
* :doc:`vashishta/table (o) <pair_vashishta>`
* :doc:`wf/cut <pair_wf_cut>`
* :doc:`ylz <pair_ylz>`
* :doc:`yukawa (gko) <pair_yukawa>`
* :doc:`yukawa/colloid (go) <pair_yukawa_colloid>`
* :doc:`zbl (gko) <pair_zbl>`

2
doc/src/Developer_updating.rst
View File

@ -7,7 +7,7 @@ source files provided as a supplement to a publication) that are written
for an older version of LAMMPS and thus need to be updated to be
compatible with the current version of LAMMPS. Due to the active
development of LAMMPS it is likely to always be incomplete. Please
contact developer@lammps.org in case you run across an issue that is not
contact developers@lammps.org in case you run across an issue that is not
(yet) listed here. Please also review the latest information about the
LAMMPS :doc:`programming style conventions <Modify_style>`, especially
if you are considering to submit the updated version for inclusion into

42
doc/src/Fortran.rst
View File

@ -1,11 +1,11 @@
The ``LIBLAMMPS`` Fortran Module
********************************
The ``LIBLAMMPS`` module provides an interface to call LAMMPS from Fortran.
It is based on the LAMMPS C library interface and
requires a Fortran 2003-compatible compiler to be compiled. It is
designed to be self-contained and not require any support functions
written in C, C++, or Fortran other than those in the C library interface.
The ``LIBLAMMPS`` module provides an interface to call LAMMPS from
Fortran. It is based on the LAMMPS C library interface and requires a
fully Fortran 2003-compatible compiler to be compiled. It is designed
to be self-contained and not require any support functions written in C,
C++, or Fortran other than those in the C library interface.
While C libraries have a defined binary interface (ABI) and can thus be
used from multiple compiler versions from different vendors as long
@ -21,11 +21,11 @@ for a simple program using the Fortran interface would be:
mpifort -o testlib.x lammps.f90 testlib.f90 -L. -llammps
Please note that the MPI compiler wrapper is only required when the
calling the library from an MPI-parallelized program. Otherwise, using the
fortran compiler (gfortran, ifort, flang, etc.) will suffice. It may be
necessary to link to additional libraries, depending on how LAMMPS was
configured and whether the LAMMPS library :doc:`was compiled as a static
or dynamic library <Build_link>`.
calling the library from an MPI-parallelized program. Otherwise, using
the plain Fortran compiler (gfortran, ifort, flang, etc.) will suffice.
It may be necessary to link to additional libraries, depending on how
LAMMPS was configured and whether the LAMMPS library :doc:`was compiled
as a static or dynamic library <Build_link>`.
If the LAMMPS library itself has been compiled with MPI support, the
resulting executable will still be able to run LAMMPS in parallel with
@ -299,7 +299,7 @@ of the contents of the ``LIBLAMMPS`` Fortran interface to LAMMPS.
``MPI_comm`` derived type to access the integer value of the
communicator, such as in
.. code-block:: Fortran
.. code-block:: fortran
PROGRAM testmpi
USE LIBLAMMPS
@ -446,7 +446,7 @@ Procedures Bound to the lammps Derived Type
represents a properly-initialized LAMMPS instance, the following code will
extract the periodic box settings into the variable "periodic":
.. code-block:: Fortran
.. code-block:: fortran
! code to start up
logical :: periodic(3)
@ -593,7 +593,7 @@ Procedures Bound to the lammps Derived Type
but you can automatically reallocate it to the correct length after the
function returns, viz.,
.. code-block :: Fortran
.. code-block :: fortran
PROGRAM test
USE LIBLAMMPS
@ -670,7 +670,7 @@ Procedures Bound to the lammps Derived Type
will print the *y*-coordinate of the sixth atom on this processor.
Conversely,
.. code-block:: Fortran
.. code-block:: fortran
TYPE(lammps) :: lmp
REAL(c_double), DIMENSION(:,:), POINTER :: x => NULL()
@ -720,7 +720,7 @@ Procedures Bound to the lammps Derived Type
typical notation in C and C++, but not Fortran), you can create another
pointer and associate it thus:
.. code-block:: Fortran
.. code-block:: fortran
REAL(c_double), DIMENSION(:,:), POINTER :: x, x0
x = lmp%extract_atom("x")
@ -752,7 +752,7 @@ Procedures Bound to the lammps Derived Type
For example,
.. code-block:: Fortran
.. code-block:: fortran
TYPE(lammps) :: lmp
REAL(c_double), DIMENSION(:), POINTER :: COM
@ -938,7 +938,7 @@ Procedures Bound to the lammps Derived Type
For example,
.. code-block:: Fortran
.. code-block:: fortran
TYPE(lammps) :: lmp
REAL(c_double) :: dr, dx, dy, dz
@ -960,7 +960,7 @@ Procedures Bound to the lammps Derived Type
appropriate size to match the internal data, and will be
type/kind/rank-checked at the time of the assignment. For example,
.. code-block:: Fortran
.. code-block:: fortran
TYPE(lammps) :: lmp
REAL(c_double), DIMENSION(:), POINTER :: r
@ -973,7 +973,7 @@ Procedures Bound to the lammps Derived Type
array computed by :doc:`fix store/state <fix_store_state>` when three
inputs are specified. Similarly,
.. code-block:: Fortran
.. code-block:: fortran
TYPE(lammps) :: lmp
REAL(c_double), DIMENSION(:), POINTER :: x
@ -1059,7 +1059,7 @@ Procedures Bound to the lammps Derived Type
For example,
.. code-block:: Fortran
.. code-block:: fortran
TYPE(lammps) :: lmp
REAL(c_double) :: area
@ -1129,7 +1129,7 @@ Procedures Bound to the lammps Derived Type
If you want data from this function to be accessible as a two-dimensional
array, you can declare a rank-2 pointer and reassign it, like so:
.. code-block:: Fortran
.. code-block:: fortran
USE, INTRINSIC :: ISO_C_BINDING
USE LIBLAMMPS

37
doc/src/Howto_tip4p.rst
View File

@ -8,18 +8,28 @@ This site M is located at a fixed distance away from the oxygen along
the bisector of the HOH bond angle. A bond style of *harmonic* and an
angle style of *harmonic* or *charmm* should also be used.
A TIP4P model is run with LAMMPS using either this command
A TIP4P model is run with LAMMPS using either these commands
for a cutoff model:
* :doc:`pair_style tip4p/cut <pair_lj_cut_tip4p>`
* :doc:`pair_style lj/cut/tip4p/cut <pair_lj_cut_tip4p>`
or these two commands for a long-range model:
or these commands for a long-range model:
* :doc:`pair_style tip4p/long <pair_coul>`
* :doc:`pair_style lj/cut/tip4p/long <pair_lj_cut_tip4p>`
* :doc:`pair_style lj/long/tip4p/long <pair_lj_long>`
* :doc:`pair_style tip4p/long/soft <pair_fep_soft>`
* :doc:`pair_style lj/cut/tip4p/long/soft <pair_fep_soft>`
* :doc:`kspace_style pppm/tip4p <kspace_style>`
* :doc:`kspace_style pppm/disp/tip4p <kspace_style>`
For both models, the bond lengths and bond angles should be held fixed
using the :doc:`fix shake <fix_shake>` command.
The bond lengths and bond angles should be held fixed using the
:doc:`fix shake <fix_shake>` or :doc:`fix rattle <fix_shake>` command,
unless a parameterization for a flexible TIP4P model is used. The
parameter sets listed below are all for rigid TIP4P model variants and
thus the bond and angle force constants are not used and can be set to
any legal value; only equilibrium length and angle are used.
These are the additional parameters (in real units) to set for O and H
atoms and the water molecule to run a rigid TIP4P model with a cutoff
@ -87,15 +97,16 @@ solver (e.g. Ewald or PPPM in LAMMPS):
| LJ :math:`\epsilon`, :math:`\sigma` of OH, HH = 0.0
|
Note that the when using the TIP4P pair style, the neighbor list
cutoff for Coulomb interactions is effectively extended by a distance
2 \* (OM distance), to account for the offset distance of the
fictitious charges on O atoms in water molecules. Thus it is
typically best in an efficiency sense to use a LJ cutoff >= Coulomb
cutoff + 2\*(OM distance), to shrink the size of the neighbor list.
This leads to slightly larger cost for the long-range calculation, so
you can test the trade-off for your model. The OM distance and the LJ
and Coulombic cutoffs are set in the :doc:`pair_style lj/cut/tip4p/long <pair_lj_cut_tip4p>` command.
Note that the when using the TIP4P pair style, the neighbor list cutoff
for Coulomb interactions is effectively extended by a distance 2 \* (OM
distance), to account for the offset distance of the fictitious charges
on O atoms in water molecules. Thus it is typically best in an
efficiency sense to use a LJ cutoff >= Coulomb cutoff + 2\*(OM
distance), to shrink the size of the neighbor list. This leads to
slightly larger cost for the long-range calculation, so you can test the
trade-off for your model. The OM distance and the LJ and Coulombic
cutoffs are set in the :doc:`pair_style lj/cut/tip4p/long
<pair_lj_cut_tip4p>` command.
Wikipedia also has a nice article on `water models <https://en.wikipedia.org/wiki/Water_model>`_.

3
doc/src/Packages_details.rst
View File

@ -200,6 +200,7 @@ particle models including ellipsoids, 2d lines, and 3d triangles.
* :doc:`Howto spherical <Howto_spherical>`
* :doc:`pair_style gayberne <pair_gayberne>`
* :doc:`pair_style resquared <pair_resquared>`
* :doc:`pair_style ylz <pair_ylz>`
* `doc/PDF/pair_gayberne_extra.pdf <PDF/pair_gayberne_extra.pdf>`_
* `doc/PDF/pair_resquared_extra.pdf <PDF/pair_resquared_extra.pdf>`_
* examples/ASPHERE
@ -1736,8 +1737,6 @@ must be installed.
.. versionadded:: 30Jun2020
.. versionadded:: 30Jun2020
**Supporting info:**
* src/ML-IAP: filenames -> commands

59
doc/src/Run_output.rst
View File

@ -16,46 +16,47 @@ simulation. An example set of statistics is shown here:
.. parsed-literal::
Loop time of 2.81192 on 4 procs for 300 steps with 2004 atoms
Loop time of 0.942801 on 4 procs for 300 steps with 2004 atoms
Performance: 18.436 ns/day 1.302 hours/ns 106.689 timesteps/s
97.0% CPU use with 4 MPI tasks x no OpenMP threads
Performance: 54.985 ns/day, 0.436 hours/ns, 318.201 timesteps/s, 637.674 katom-step/s
195.2% CPU use with 2 MPI tasks x 2 OpenMP threads
MPI task timings breakdown:
MPI task timing breakdown:
Section \| min time \| avg time \| max time \|%varavg\| %total
---------------------------------------------------------------
Pair \| 1.9808 \| 2.0134 \| 2.0318 \| 1.4 \| 71.60
Bond \| 0.0021894 \| 0.0060319 \| 0.010058 \| 4.7 \| 0.21
Kspace \| 0.3207 \| 0.3366 \| 0.36616 \| 3.1 \| 11.97
Neigh \| 0.28411 \| 0.28464 \| 0.28516 \| 0.1 \| 10.12
Comm \| 0.075732 \| 0.077018 \| 0.07883 \| 0.4 \| 2.74
Output \| 0.00030518 \| 0.00042665 \| 0.00078821 \| 1.0 \| 0.02
Modify \| 0.086606 \| 0.086631 \| 0.086668 \| 0.0 \| 3.08
Other \| \| 0.007178 \| \| \| 0.26
Pair \| 0.61419 \| 0.62872 \| 0.64325 \| 1.8 \| 66.69
Bond \| 0.0028608 \| 0.0028899 \| 0.002919 \| 0.1 \| 0.31
Kspace \| 0.12652 \| 0.14048 \| 0.15444 \| 3.7 \| 14.90
Neigh \| 0.10242 \| 0.10242 \| 0.10242 \| 0.0 \| 10.86
Comm \| 0.026753 \| 0.027593 \| 0.028434 \| 0.5 \| 2.93
Output \| 0.00018341 \| 0.00030942 \| 0.00043542 \| 0.0 \| 0.03
Modify \| 0.039117 \| 0.039348 \| 0.039579 \| 0.1 \| 4.17
Other \| \| 0.001041 \| \| \| 0.11
Nlocal: 501 ave 508 max 490 min
Histogram: 1 0 0 0 0 0 1 1 0 1
Nghost: 6586.25 ave 6628 max 6548 min
Histogram: 1 0 1 0 0 0 1 0 0 1
Neighs: 177007 ave 180562 max 170212 min
Histogram: 1 0 0 0 0 0 0 1 1 1
Nlocal: 1002 ave 1006 max 998 min
Histogram: 1 0 0 0 0 0 0 0 0 1
Nghost: 8670.5 ave 8691 max 8650 min
Histogram: 1 0 0 0 0 0 0 0 0 1
Neighs: 354010 ave 357257 max 350763 min
Histogram: 1 0 0 0 0 0 0 0 0 1
Total # of neighbors = 708028
Ave neighs/atom = 353.307
Ave special neighs/atom = 2.34032
Total # of neighbors = 708020
Ave neighs/atom = 353.30339
Ave special neighs/atom = 2.3403194
Neighbor list builds = 26
Dangerous builds = 0
----------
The first section provides a global loop timing summary. The *loop
time* is the total wall-clock time for the simulation to run. The
*Performance* line is provided for convenience to help predict how
long it will take to run a desired physical simulation. The *CPU use*
line provides the CPU utilization per MPI task; it should be close to
100% times the number of OpenMP threads (or 1 of not using OpenMP).
Lower numbers correspond to delays due to file I/O or insufficient
thread utilization.
The first section provides a global loop timing summary. The *loop time*
is the total wall-clock time for the simulation to run. The
*Performance* line is provided for convenience to help predict how long
it will take to run a desired physical simulation and to have numbers
useful for performance comparison between different simulation settings
or system sizes. The *CPU use* line provides the CPU utilization per
MPI task; it should be close to 100% times the number of OpenMP threads
(or 1 of not using OpenMP). Lower numbers correspond to delays due to
file I/O or insufficient thread utilization.
----------

15
doc/src/clear.rst
View File

@ -23,15 +23,16 @@ Description
"""""""""""
This command deletes all atoms, restores all settings to their default
values, and frees all memory allocated by LAMMPS. Once a clear
command has been executed, it is almost as if LAMMPS were starting
over, with only the exceptions noted below. This command enables
multiple jobs to be run sequentially from one input script.
values, and frees all memory allocated by LAMMPS. Once a clear command
has been executed, it is almost as if LAMMPS were starting over, with
only the exceptions noted below. This command enables multiple jobs to
be run sequentially from one input script.
These settings are not affected by a clear command: the working
directory (:doc:`shell <shell>` command), log file status
(:doc:`log <log>` command), echo status (:doc:`echo <echo>` command), and
input script variables (:doc:`variable <variable>` command).
directory (:doc:`shell <shell>` command), log file status (:doc:`log
<log>` command), echo status (:doc:`echo <echo>` command), and input
script variables except for *atomfile* style variables (:doc:`variable
<variable>` command).
Restrictions
""""""""""""

2
doc/src/dump.rst
View File

@ -202,7 +202,7 @@ or multiple smaller files).
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
pbc <dump_modify>` command if you wish to force coordinates to be
strictly inside the simulation box.
.. note::

6
doc/src/fix_bond_react.rst
View File

@ -404,6 +404,12 @@ atoms are present. The velocity of each created atom is initialized in
a random direction with a magnitude calculated from the instantaneous
temperature of the reaction site.
.. note::
The 'Coords' section must be included in the post-reaction template
when creating atoms because these coordinates are used to determine
where new atoms are inserted.
The handedness of atoms that are chiral centers can be enforced by
listing their IDs in the ChiralIDs section. A chiral atom must be
bonded to four atoms with mutually different atom types. This feature

77
doc/src/neigh_modify.rst
View File

@ -16,12 +16,12 @@ Syntax
keyword = *delay* or *every* or *check* or *once* or *cluster* or *include* or *exclude* or *page* or *one* or *binsize* or *collection/type* or *collection/interval*
*delay* value = N
N = delay building until this many steps since last build
N = delay building neighbor lists until this many steps since last build
*every* value = M
M = build neighbor list every this many steps
M = consider building neighbor lists every this many steps
*check* value = *yes* or *no*
*yes* = only build if some atom has moved half the skin distance or more
*no* = always build on 1st step that *every* and *delay* are satisfied
*yes* = only build if at least one atom has moved half the skin distance or more
*no* = always build on 1st step where *every* and *delay* are conditions are satisfied
*once* value = *yes* or *no*
*yes* = only build neighbor list once at start of run and never rebuild
*no* = rebuild neighbor list according to other settings
@ -71,30 +71,53 @@ Description
"""""""""""
This command sets parameters that affect the building and use of
pairwise neighbor lists. Depending on what pair interactions and
other commands are defined, a simulation may require one or more
neighbor lists.
pairwise neighbor lists. Depending on what pair interactions and other
commands are defined, a simulation may require one or more neighbor
lists.
The *every*, *delay*, *check*, and *once* options affect how often
lists are built as a simulation runs. The *delay* setting means never
build new lists until at least N steps after the previous build. The
*every* setting means build lists every M steps (after the delay has
The *every*, *delay*, *check*, and *once* options affect how often lists
are built as a simulation runs. The *delay* setting means never build
new lists until at least N steps after the previous build. The *every*
setting means attempt to build lists every M steps (after the delay has
passed). If the *check* setting is *no*, the lists are built on the
first step that satisfies the *delay* and *every* settings. If the
*check* setting is *yes*, then the *every* and *delay* settings
determine when a build may possibly be performed, but an actual build
only occurs if some atom has moved more than half the skin distance
(specified in the :doc:`neighbor <neighbor>` command) since the last
build.
only occurs if at least one atom has moved more than half the neighbor
skin distance (specified in the :doc:`neighbor <neighbor>` command)
since the last neighbor list build.
If the *once* setting is yes, then the neighbor list is only built
once at the beginning of each run, and never rebuilt, except on steps
when a restart file is written, or steps when a fix forces a rebuild
to occur (e.g. fixes that create or delete atoms, such as :doc:`fix deposit <fix_deposit>` or :doc:`fix evaporate <fix_evaporate>`).
This setting should only be made if you are certain atoms will not
move far enough that the neighbor list should be rebuilt, e.g. running
a simulation of a cold crystal. Note that it is not that expensive to
check if neighbor lists should be rebuilt.
.. admonition:: Impact of neighbor list settings
:class: note
The choice of neighbor list settings can have a significant impact on
the (parallel) performance of LAMMPS and the correctness of the
simulation results. Since building the neighbor lists is time
consuming, doing it less frequently can speed up a calculation. If
the lists are rebuilt too infrequently, however, interacting pairs
may be missing and thus the resulting pairwise interactions
incorrect. The optimal settings depend on many factors like the
properties of the simulated system (density, geometry, topology,
temperature, pressure), the force field parameters and settings, the
size of the timestep, neighbor list skin distance and more. The
default settings are chosen to be very conservative to guarantee
correctness of the simulation. They depend on the *check* flag
heuristics to reduce the number of neighbor list rebuilds at a minor
expense for executing the check. Determining the correctness of a
specific choice of neighbor list settings is complicated by the fact
that a neighbor list rebuild changes the order in which pairwise
interactions are computed and thus
- due to the limitations of floating-point math - the trajectory.
If the *once* setting is yes, then the neighbor list is only built once
at the beginning of each run, and never rebuilt, except on steps when a
restart file is written, or steps when a fix forces a rebuild to occur
(e.g. fixes that create or delete atoms, such as :doc:`fix deposit
<fix_deposit>` or :doc:`fix evaporate <fix_evaporate>`). This setting
should only be made if you are certain atoms will not move far enough
that the neighbor list should be rebuilt, e.g. running a simulation of a
cold crystal. Note that it is not that expensive to check if neighbor
lists should be rebuilt.
When the rRESPA integrator is used (see the :doc:`run_style <run_style>`
command), the *every* and *delay* parameters refer to the longest
@ -234,11 +257,11 @@ depend on their atom type.
Restrictions
""""""""""""
If the "delay" setting is non-zero, then it must be a multiple of the
"every" setting.
If the *delay* setting is non-zero, then it must be a multiple of the
*every* setting.
The molecule/intra and molecule/inter exclude options can only be used
with atom styles that define molecule IDs.
The *molecule/intra* and *molecule/inter* exclusion options can only
be used with atom styles that define molecule IDs.
The value of the *page* setting must be at least 10x larger than the
*one* setting. This insures neighbor pages are not mostly empty
@ -252,6 +275,6 @@ Related commands
Default
"""""""
The option defaults are delay = 10, every = 1, check = yes, once = no,
The option defaults are delay = 0, every = 1, check = yes, once = no,
cluster = no, include = all (same as no include option defined),
exclude = none, page = 100000, one = 2000, and binsize = 0.0.

45
doc/src/pair_dipole.rst
View File

@ -58,22 +58,26 @@ Examples
.. code-block:: LAMMPS
pair_style lj/cut/dipole/cut 10.0
pair_style lj/cut/dipole/cut 2.5 5.0
pair_coeff * * 1.0 1.0
pair_coeff 2 3 1.0 1.0 2.5 4.0
pair_coeff 2 3 0.8 1.0 2.5 4.0
pair_style lj/sf/dipole/sf 9.0
pair_coeff * * 1.0 1.0
pair_coeff 2 3 1.0 1.0 2.5 4.0 scale 0.5
pair_coeff 2 3 1.0 1.0 2.5 4.0
pair_coeff 2 3 0.8 1.0 2.5 4.0
pair_style lj/cut/dipole/long 10.0
pair_style lj/cut/dipole/long 2.5 3.5
pair_coeff * * 1.0 1.0
pair_coeff 2 3 1.0 1.0 2.5 4.0
pair_coeff 2 3 0.8 1.0 3.0
pair_style lj/long/dipole/long long long 3.5 10.0
pair_style lj/long/dipole/long long long 3.5
pair_coeff * * 1.0 1.0
pair_coeff 2 3 1.0 1.0 2.5 4.0
pair_coeff 2 3 0.8 1.0
pair_style lj/long/dipole/long cut long 2.5 3.5
pair_coeff * * 1.0 1.0
pair_coeff 2 3 0.8 1.0 3.0
Description
"""""""""""
@ -254,23 +258,28 @@ long-range LJ interactions, the :doc:`kspace_style ewald/disp
----------
The following coefficients must be defined for each pair of atoms
types via the :doc:`pair_coeff <pair_coeff>` command as in the examples
above, or in the data file or restart files read by the
:doc:`read_data <read_data>` or :doc:`read_restart <read_restart>`
commands, or by mixing as described below:
The following coefficients must be defined for each pair of atoms types
via the :doc:`pair_coeff <pair_coeff>` command as in the examples above,
or in the data file or restart files read by the :doc:`read_data
<read_data>` or :doc:`read_restart <read_restart>` commands, or by
mixing as described below:
* :math:`\epsilon` (energy units)
* :math:`\sigma` (distance units)
* cutoff1 (distance units)
* cutoff2 (distance units)
The latter 2 coefficients are optional. If not specified, the global
LJ and Coulombic cutoffs specified in the pair_style command are used.
If only one cutoff is specified, it is used as the cutoff for both LJ
and Coulombic interactions for this type pair. If both coefficients
are specified, they are used as the LJ and Coulombic cutoffs for this
type pair.
The latter 2 coefficients are optional. If not specified, the global LJ
and Coulombic cutoffs specified in the pair_style command are used. If
only one cutoff is specified, it is used as the cutoff for both LJ and
Coulombic interactions for this type pair. If both coefficients are
specified, they are used as the LJ and Coulombic cutoffs for this type
pair. When using a long-rang Coulomb solver, only a global Coulomb
cutoff may be used and only the LJ cutoff may be changed with the
:doc:`pair_coeff <pair_coeff>` command. When using the
*lj/long/dipole/long* pair style with *long* *long* setting, only a
single global cutoff may be provided and no cutoff for the
:doc:`pair_coeff <pair_coeff>` command.
----------

12
doc/src/pair_list.rst
View File

@ -57,7 +57,7 @@ The format of the list file is as follows:
ID2 = atom ID of second atom
style = style of interaction
coeffs = list of coeffs
cutoff = cutoff for interaction (optional, except for style *quartic*)
cutoff = cutoff for interaction (optional)
The cutoff parameter is optional for all but the *quartic* interactions.
If it is not specified, the global cutoff is used.
@ -71,7 +71,7 @@ Here is an example file:
15 259 lj126 1.0 1.0 50.0
15 603 morse 10.0 1.2 2.0 10.0 # and another comment
18 470 harmonic 50.0 1.2 5.0
19 332 quartic 5.0 -1.2 1.2 5.0
19 332 quartic 10.0 5.0 -1.2 1.2
The style *lj126* computes pairwise interactions with the formula
@ -100,7 +100,7 @@ The style *harmonic* computes pairwise interactions with the formula
.. math::
E = K (r - r_0)^2
E = K (r - r_0)^2 \qquad r < r_c
and the coefficients:
@ -113,16 +113,14 @@ The style *quartic* computes pairwise interactions with the formula
.. math::
E = K (r - r_c)^2 (r - r_c -b_1) (r - r_c - b_2) \qquad r < r_c
E = K (r - r_0)^2 (r - r_0 -b_1) (r - r_0 - b_2) \qquad r < r_c
and the coefficients:
* :math:`K` (energy units)
* :math:`r_0` (distance units)
* :math:`b_1` (distance units)
* :math:`b_2` (distance units)
* :math:`r_c` (distance units)
Note that the per list entry cutoff :math:`r_c` is **required** for *quartic* interactions.
----------

1
doc/src/pair_pace.rst
View File

@ -112,7 +112,6 @@ requests to compute `gamma`, as shown in example below:
compute max_pace_gamma all reduce max f_pace_gamma
variable dump_skip equal "c_max_pace_gamma < 5"
dump pace_dump all custom 20 extrapolative_structures.dump id x y z f_pace_gamma
dump_modify pace_dump skip v_dump_skip

1
doc/src/pair_style.rst
View File

@ -374,6 +374,7 @@ accelerated styles exist.
* :doc:`vashishta <pair_vashishta>` - Vashishta 2-body and 3-body potential
* :doc:`vashishta/table <pair_vashishta>` -
* :doc:`wf/cut <pair_wf_cut>` - Wang-Frenkel Potential for short-ranged interactions
* :doc:`ylz <pair_ylz>` - Yuan-Li-Zhang Potential for anisotropic interactions
* :doc:`yukawa <pair_yukawa>` - Yukawa potential
* :doc:`yukawa/colloid <pair_yukawa_colloid>` - screened Yukawa potential for finite-size particles
* :doc:`zbl <pair_zbl>` - Ziegler-Biersack-Littmark potential

177
doc/src/pair_ylz.rst Normal file
View File

@ -0,0 +1,177 @@
.. index:: pair_style ylz
pair_style ylz command
===========================
Syntax
""""""
.. code-block:: LAMMPS
pair_style ylz cutoff
* cutoff = global cutoff for interactions (distance units)
Examples
""""""""
.. code-block:: LAMMPS
pair_style ylz 2.6
pair_coeff * * 1.0 1.0 4 3 0.0 2.6
Description
"""""""""""
.. versionadded:: TBD
The *ylz* (Yuan-Li-Zhang) style computes an anisotropic interaction
between pairs of coarse-grained particles considering the relative
particle orientations. This potential was originally developed as a
particle-based solvent-free model for biological membranes
:ref:`(Yuan2010a) <Yuan>`. Unlike :doc:`pair_style gayberne
<pair_gayberne>`, whose orientation dependence is strictly derived from
the closest distance between two ellipsoidal rigid bodies, the
orientation-dependence of this pair style is mathematically defined such
that the particles can self-assemble into one-particle-thick fluid
membranes. The potential of this pair style is described by:
.. math::
U ( \mathbf{r}_{ij}, \mathbf{n}_i, \mathbf{n}_j ) =\left\{\begin{matrix} {u}_R(r)+\left [ 1-\phi (\mathbf{\hat{r}}_{ij}, \mathbf{n}_i, \mathbf{n}_j ) \right ]\epsilon, ~~ r<{r}_{min} \\ {u}_A(r)\phi (\mathbf{\hat{r}}_{ij}, \mathbf{n}_i, \mathbf{n}_j ),~~ {r}_{min}<r<{r}_{c} \\ \end{matrix}\right.\\\\ \phi (\mathbf{\hat{r}}_{ij}, \mathbf{n}_i, \mathbf{n}_j )=1+\left [ \mu (a(\mathbf{\hat{r}}_{ij}, \mathbf{n}_i, \mathbf{n}_j )-1) \right ] \\\\a(\mathbf{\hat{r}}_{ij}, \mathbf{n}_i, \mathbf{n}_j )=(\mathbf{n}_i\times\mathbf{\hat{r}}_{ij} )\cdot (\mathbf{n}_j\times\mathbf{\hat{r}}_{ij} )+{\beta}(\mathbf{n}_i-\mathbf{n}_j)\cdot \mathbf{\hat{r}}_{ij}-\beta^{2}\\\\ {u}_R(r)=\epsilon \left [ \left ( \frac{{r}_{min}}{r} \right )^{4}-2\left ( \frac{{r}_{min}}{r}\right )^{2} \right ] \\\\ {u}_A(r)=-\epsilon\;cos^{2\zeta }\left [ \frac{\pi}{2}\frac{\left ( {r}-{r}_{min} \right )}{\left ( {r}_{c}-{r}_{min} \right )} \right ]\\
where :math:`\mathbf{r}_{i}` and :math:`\mathbf{r}_{j}` are the center
position vectors of particles i and j, respectively,
:math:`\mathbf{r}_{ij}=\mathbf{r}_{i}-\mathbf{r}_{j}` is the
inter-particle distance vector, :math:`r=\left|\mathbf{r}_{ij} \right|`
and :math:`{\hat{\mathbf{r}}}_{ij}=\mathbf{r}_{ij}/r`. The unit vectors
:math:`\mathbf{n}_{i}` and :math:`\mathbf{n}_{j}` represent the axes of
symmetry of particles i and j, respectively, :math:`u_R` and :math:`u_A`
are the repulsive and attractive potentials, :math:`\phi` is an angular
function which depends on the relative orientation between pair
particles, :math:`\mu` is the parameter related to the bending rigidity
of the membrane, :math:`\beta` is the parameter related to the
spontaneous curvature, and :math:`\epsilon` is the energy unit,
respectively. The :math:`\zeta` controls the slope of the attractive
branch and hence the diffusivity of the particles in the in-plane
direction of the membrane. :math:`{r}_{c}` is the cutoff radius,
:math:`r_{min}` is the distance which minimizes the potential energy
:math:`u_{A}(r)` and :math:`r_{min}=2^{1/6}\sigma`, where :math:`\sigma`
is the length unit.
This pair style is suited for solvent-free coarse-grained simulations of
biological systems involving lipid bilayer membranes, such as vesicle
shape transformations :ref:`(Yuan2010b) <Yuan>`, nanoparticle
endocytosis :ref:`(Huang) <Huang>`, modeling of red blood cell membranes
:ref:`(Fu) <Fu>`, :ref:`(Appshaw) <Appshaw>`, and modeling of cell
elasticity :ref:`(Becton) <Becton>`.
Use of this pair style requires the NVE, NVT, or NPT fixes with the
*asphere* extension (e.g. :doc:`fix nve/asphere <fix_nve_asphere>`) in
order to integrate particle rotation. Additionally, :doc:`atom_style
ellipsoid <atom_style>` should be used since it defines the rotational
state of each particle.
The following coefficients must be defined for each pair of atoms types
via the :doc:`pair_coeff <pair_coeff>` command as in the examples above,
or in the data file or restart files read by the :doc:`read_data
<read_data>` or :doc:`read_restart <read_restart>` commands, or by
mixing as described below:
* :math:`\epsilon` = well depth (energy units)
* :math:`\sigma` = minimum effective particle radii (distance units)
* :math:`\zeta` = tune parameter for the slope of the attractive branch
* :math:`\mu` = parameter related to bending rigidity
* :math:`\beta` = parameter related to the spontaneous curvature
* cutoff (distance units)
The last coefficient is optional. If not specified, the global
cutoff specified in the pair_style command is used.
----------
Mixing, shift, table, tail correction, restart, rRESPA info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance for this pair style can be mixed. The default mix
value is *geometric*\ . See the "pair_modify" command for details.
The :doc:`pair_modify <pair_modify>` table option is not relevant for
this pair style.
This pair style does not support the :doc:`pair_modify <pair_modify>`
tail option for adding long-range tail corrections to energy and
pressure.
This pair style writes its information to :doc:`binary restart files
<restart>`, so pair_style and pair_coeff commands do not need to be
specified in an input script that reads a restart file.
This pair style can only be used via the *pair* keyword of the
:doc:`run_style respa <run_style>` command. It does not support the
*inner*, *middle*, *outer* keywords.
----------
Restrictions
""""""""""""
The *ylz* style is part of the ASPHERE package. It is only enabled if
LAMMPS was built with that package. See the :doc:`Build package
<Build_package>` page for more info.
This pair style requires that atoms store torque and a quaternion to
represent their orientation, as defined by the :doc:`atom_style
<atom_style>`. It also requires they store a per-atom :doc:`shape
<set>`. The particles cannot store a per-particle diameter. To avoid
being mistakenly considered as point particles, the shape parameters ought
to be non-spherical, like [1 0.99 0.99]. Unlike the :doc:`resquared
<pair_resquared>` pair style for which the shape directly determines the
mathematical expressions of the potential, the shape parameters for this
pair style is only involved in the computation of the moment of inertia
and thus only influences the rotational dynamics of individual
particles.
This pair style requires that **all** atoms are ellipsoids as defined by
the :doc:`atom_style ellipsoid <atom_style>` command.
Related commands
""""""""""""""""
:doc:`pair_coeff <pair_coeff>`, :doc:`fix nve/asphere
:doc:<fix_nve_asphere>`, `compute temp/asphere <compute_temp_asphere>`,
:doc::doc:`pair_style resquared <pair_resquared>`, :doc:`pair_style
:doc:gayberne <pair_gayberne>`
Default
"""""""
none
----------
.. _Yuan:
**(Yuan2010a)** Yuan, Huang, Li, Lykotrafitis, Zhang, Phys. Rev. E, 82, 011905(2010).
**(Yuan2010b)** Yuan, Huang, Zhang, Soft. Matter, 6, 4571(2010).
.. _Huang:
**(Huang)** Huang, Zhang, Yuan, Gao, Zhang, Nano Lett. 13, 4546(2013).
.. _Fu:
**(Fu)** Fu, Peng, Yuan, Kfoury, Young, Comput. Phys. Commun, 210, 193-203(2017).
.. _Appshaw:
**(Appshaw)** Appshaw, Seddon, Hanna, Soft. Matter,18, 1747(2022).
.. _Becton:
**(Becton)** Becton, Averett, Wang, Biomech. Model. Mechanobiology, 18, 425-433(2019).

10
doc/src/read_data.rst
View File

@ -71,8 +71,14 @@ Also see the explanation of the :doc:`-restart command-line switch
This command can be used multiple times to add new atoms and their
properties to an existing system by using the *add*, *offset*, and
*shift* keywords. See more details below, which includes the use case
for the *extra* keywords.
*shift* keywords. However, it is important to understand that several
system parameters, like the number of types of different kinds and per
atom settings are **locked in** after the first *read_data* command,
which means that no type ID (including its offset) may have a larger
value when processing additional data files than what is set by the
first data file and the corresponding *read_data* command options. See
more details on this situation below, which includes the use case for
the *extra* keywords.
The *group* keyword adds all the atoms in the data file to the
specified group-ID. The group will be created if it does not already

2
doc/src/run_style.rst
View File

@ -101,7 +101,7 @@ Py2 by Pz2, then Px1 must be an integer multiple of Px2, and similarly
for Py1 a multiple of Py2, and Pz1 a multiple of Pz2.
Typically the best way to do this is to let the first partition choose
its onn optimal layout, then require the second partition's layout to
its own optimal layout, then require the second partition's layout to
match the integer multiple constraint. See the
:doc:`processors <processors>` command with its *part* keyword for a way
to control this, e.g.

17
doc/src/variable.rst
View File

@ -213,6 +213,9 @@ from the list of active variables, and is thus available to be
re-defined in a subsequent variable command. The *delete* style does
the same thing.
Variables are **not** deleted by the :doc:`clear <clear>` command with
the exception of atomfile-style variables.
----------
The :doc:`Commands parse <Commands_parse>` page explains how
@ -265,7 +268,7 @@ the first string is assigned to the variable. Each time a
string is assigned. All processors assign the same string to the
variable.
*Index* style variables with a single string value can also be set by
Index-style variables with a single string value can also be set by
using the :doc:`command-line switch -var <Run_options>`.
The *loop* style is identical to the *index* style except that the
@ -285,7 +288,7 @@ be one string for each processor partition or "world". LAMMPS can be
run with multiple partitions via the :doc:`-partition command-line
switch <Run_options>`. This variable command assigns one string to
each world. All processors in the world are assigned the same string.
The next command cannot be used with *equal* style variables, since
The next command cannot be used with equal-style variables, since
there is only one value per world. This style of variable is useful
when you wish to run different simulations on different partitions, or
when performing a parallel tempering simulation (see the :doc:`temper
@ -303,7 +306,7 @@ string. This continues until all the variable strings are consumed.
Thus, this command can be used to run 50 simulations on 8 processor
partitions. The simulations will be run one after the other on
whatever partition becomes available, until they are all finished.
*Universe* style variables are incremented using the files
Universe-style variables are incremented using the files
"tmp.lammps.variable" and "tmp.lammps.variable.lock" which you will
see in your directory during such a LAMMPS run.
@ -341,7 +344,9 @@ variable can be used to adapt the behavior of LAMMPS input scripts via
environment variable settings, or to retrieve information that has
been previously stored with the :doc:`shell putenv <shell>` command.
Note that because environment variable settings are stored by the
operating systems, they persist beyond a :doc:`clear <clear>` command.
operating systems, they persist even if the corresponding *getenv*
style variable is deleted, and also are set for sub-shells executed
by the :doc:`shell <shell>` command.
For the *file* style, a filename is provided which contains a list of
strings to assign to the variable, one per line. The strings can be
@ -373,7 +378,9 @@ This means the variable can then be evaluated as many times as desired
and will return those values. There are two ways to cause the next
set of per-atom values from the file to be read: use the
:doc:`next <next>` command or the next() function in an atom-style
variable, as discussed below.
variable, as discussed below. Unlike most variable styles
atomfile-style variables are **deleted** during a :doc:`clear <clear>`
command.
The rules for formatting the file are as follows. Each time a set of
per-atom values is read, a non-blank line is searched for in the file.