Merge pull request #2156 from akohlmey/collected-small-changes
Collected changes for the next patch release
This commit is contained in:
@ -225,7 +225,7 @@ A few example command lines are:
|
||||
|
||||
For compiling with the Clang/LLVM compilers a CMake preset is provided that
|
||||
can be loaded with `-C ../cmake/presets/clang.cmake`. Similarly,
|
||||
`-C ../cmake/presets/intel.cmake` should switch the
|
||||
`-C ../cmake/presets/intel.cmake` should switch the
|
||||
|
||||
In addition you can set ``CMAKE_TUNE_FLAGS`` to specifically add
|
||||
compiler flags to tune for optimal performance on given hosts. By
|
||||
@ -372,7 +372,8 @@ it. The build step will also create generic soft links, named
|
||||
``liblammps.a`` and ``liblammps.so``\ , which point to the specific
|
||||
``liblammps_machine.a/so`` files.
|
||||
|
||||
**CMake and make info**\ :
|
||||
CMake and make info
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Note that for creating a shared library, all the libraries it depends on
|
||||
must be compiled to be compatible with shared libraries. This should be
|
||||
@ -462,7 +463,8 @@ tool. The actual translation is then done via make commands.
|
||||
.. _rst: https://docutils.readthedocs.io/en/sphinx-docs/user/rst/quickstart.html
|
||||
.. _sphinx: https://sphinx-doc.org
|
||||
|
||||
**Documentation make option**\ :
|
||||
Documentation make option
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The following make commands can be issued in the doc folder of the
|
||||
LAMMPS source distribution.
|
||||
@ -489,7 +491,8 @@ your system.
|
||||
current LAMMPS version (HTML and PDF files), from the website
|
||||
`download page <https://lammps.sandia.gov/download.html>`_.
|
||||
|
||||
**CMake build option**\ :
|
||||
CMake build option
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
|
||||
It is also possible to create the HTML version of the manual within
|
||||
the :doc:`CMake build directory <Build_cmake>`. The reason for this
|
||||
@ -512,7 +515,8 @@ Build LAMMPS tools
|
||||
Some tools described in :doc:`Auxiliary tools <Tools>` can be built directly
|
||||
using CMake or Make.
|
||||
|
||||
**CMake build3**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -521,7 +525,8 @@ using CMake or Make.
|
||||
The generated binaries will also become part of the LAMMPS installation
|
||||
(see below).
|
||||
|
||||
**Traditional make**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -545,7 +550,8 @@ a globally visible place on your system, for others to access. Note
|
||||
that you may need super-user privileges (e.g. sudo) if the directory
|
||||
you want to copy files to is protected.
|
||||
|
||||
**CMake build**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -553,7 +559,8 @@ you want to copy files to is protected.
|
||||
make # perform make after CMake command
|
||||
make install # perform the installation into prefix
|
||||
|
||||
**Traditional make**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
There is no "install" option in the ``src/Makefile`` for LAMMPS. If
|
||||
you wish to do this you will need to first build LAMMPS, then manually
|
||||
|
||||
@ -126,7 +126,7 @@ in the next section.
|
||||
|
||||
.. note::
|
||||
|
||||
This unit test framework is new and still under development.
|
||||
The unit test framework is new and still under development.
|
||||
The coverage is only minimal and will be expanded over time.
|
||||
Tests styles of the same kind of style (e.g. pair styles or
|
||||
bond styles) are performed with the same executable using
|
||||
@ -237,12 +237,12 @@ and working.
|
||||
performed with automatically rescaled epsilon to account for
|
||||
additional loss of precision from code optimizations and different
|
||||
summation orders.
|
||||
- When compiling with aggressive compiler optimization, some tests
|
||||
- When compiling with (aggressive) compiler optimization, some tests
|
||||
are likely to fail. It is recommended to inspect the individual
|
||||
tests in detail to decide whether the specific error for a specific
|
||||
tests in detail to decide, whether the specific error for a specific
|
||||
property is acceptable (it often is), or this may be an indication
|
||||
of mis-compiled code (or undesired large of precision due to
|
||||
reordering of operations).
|
||||
of mis-compiled code (or an undesired large loss of precision due
|
||||
to significant reordering of operations and thus less error cancellation).
|
||||
|
||||
Collect and visualize code coverage metrics
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
@ -60,12 +60,13 @@ This is the list of packages that may require additional steps.
|
||||
.. _compress:
|
||||
|
||||
COMPRESS package
|
||||
-------------------------------
|
||||
----------------
|
||||
|
||||
To build with this package you must have the zlib compression library
|
||||
available on your system.
|
||||
|
||||
**CMake build**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
If CMake cannot find the library, you can set these variables:
|
||||
|
||||
@ -74,10 +75,11 @@ If CMake cannot find the library, you can set these variables:
|
||||
-D ZLIB_INCLUDE_DIR=path # path to zlib.h header file
|
||||
-D ZLIB_LIBRARIES=path # path to libz.a (.so) file
|
||||
|
||||
**Traditional make**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
If make cannot find the library, you can edit the file
|
||||
lib/compress/Makefile.lammps to specify the paths and library
|
||||
``lib/compress/Makefile.lammps`` to specify the paths and library
|
||||
name.
|
||||
|
||||
----------
|
||||
@ -91,7 +93,8 @@ To build with this package, you must choose options for precision and
|
||||
which GPU hardware to build for. The GPU package currently supports
|
||||
three different types of backends: OpenCL, CUDA and HIP.
|
||||
|
||||
**CMake build**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -159,7 +162,8 @@ and the linker to work correctly.
|
||||
cmake -D PKG_GPU=on -D GPU_API=HIP -D HIP_ARCH=sm_70 ..
|
||||
make -j 4
|
||||
|
||||
**Traditional make**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
Before building LAMMPS, you must build the GPU library in ``lib/gpu``\ .
|
||||
You can do this manually if you prefer; follow the instructions in
|
||||
@ -208,10 +212,10 @@ your machine are not correct, the LAMMPS build will fail, and
|
||||
|
||||
.. note::
|
||||
|
||||
If you re-build the GPU library in lib/gpu, you should always
|
||||
un-install the GPU package in lammps/src, then re-install it and
|
||||
If you re-build the GPU library in ``lib/gpu``, you should always
|
||||
un-install the GPU package in ``lammps/src``, then re-install it and
|
||||
re-build LAMMPS. This is because the compilation of files in the GPU
|
||||
package uses the library settings from the lib/gpu/Makefile.machine
|
||||
package uses the library settings from the ``lib/gpu/Makefile.machine``
|
||||
used to build the GPU library.
|
||||
|
||||
----------
|
||||
@ -250,7 +254,8 @@ See the list of all KIM models here: https://openkim.org/browse/models
|
||||
the KIM API library with all its models, may take a long time (tens of
|
||||
minutes to hours) to build. Of course you only need to do that once.)
|
||||
|
||||
**CMake build**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -282,7 +287,8 @@ As an alternative, you can specify your own CA cert path by setting the
|
||||
environment variable ``CURL_CA_BUNDLE`` to the path of your choice. A call
|
||||
to the KIM web query would get this value from the environmental variable.
|
||||
|
||||
**Traditional make**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
You can download and build the KIM library manually if you prefer;
|
||||
follow the instructions in ``lib/kim/README``\ . You can also do it in one
|
||||
@ -300,7 +306,7 @@ invoke the ``lib/kim/Install.py`` script with the specified args.
|
||||
$ make lib-kim args="-p /usr/local -a EAM_Dynamo_Ackland_W__MO_141627196590_002" # ditto but add one model or driver
|
||||
|
||||
Settings for OpenKIM web queries discussed above need to be applied by adding
|
||||
them to the ``LMP_INC`` variable through editing the Makefile.machine you are
|
||||
them to the ``LMP_INC`` variable through editing the ``Makefile.machine`` you are
|
||||
using. For example:
|
||||
|
||||
.. code-block:: make
|
||||
@ -605,7 +611,8 @@ LATTE package
|
||||
To build with this package, you must download and build the LATTE
|
||||
library.
|
||||
|
||||
**CMake build**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -618,7 +625,8 @@ already on your system (in a location CMake cannot find it),
|
||||
``LATTE_LIBRARY`` is the filename (plus path) of the LATTE library file,
|
||||
not the directory the library file is in.
|
||||
|
||||
**Traditional make**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
You can download and build the LATTE library manually if you prefer;
|
||||
follow the instructions in ``lib/latte/README``\ . You can also do it in
|
||||
@ -634,11 +642,12 @@ args:
|
||||
$ make lib-latte args="-b -m gfortran" # download and build in lib/latte and
|
||||
# copy Makefile.lammps.gfortran to Makefile.lammps
|
||||
|
||||
Note that 3 symbolic (soft) links, "includelink" and "liblink" and
|
||||
"filelink.o", are created in lib/latte to point into the LATTE home
|
||||
dir. When LAMMPS itself is built it will use these links. You should
|
||||
also check that the Makefile.lammps file you create is appropriate for
|
||||
the compiler you use on your system to build LATTE.
|
||||
Note that 3 symbolic (soft) links, ``includelink`` and ``liblink`` and
|
||||
``filelink.o``, are created in ``lib/latte`` to point to required
|
||||
folders and files in the LATTE home directory. When LAMMPS itself is
|
||||
built it will use these links. You should also check that the
|
||||
``Makefile.lammps`` file you create is appropriate for the compiler you
|
||||
use on your system to build LATTE.
|
||||
|
||||
----------
|
||||
|
||||
@ -651,7 +660,8 @@ This package can optionally include support for messaging via sockets,
|
||||
using the open-source `ZeroMQ library <http://zeromq.org>`_, which must
|
||||
be installed on your system.
|
||||
|
||||
**CMake build**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -659,7 +669,8 @@ be installed on your system.
|
||||
-D ZMQ_LIBRARY=path # ZMQ library file (only needed if a custom location)
|
||||
-D ZMQ_INCLUDE_DIR=path # ZMQ include directory (only needed if a custom location)
|
||||
|
||||
**Traditional make**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
Before building LAMMPS, you must build the CSlib library in
|
||||
``lib/message``\ . You can build the CSlib library manually if you prefer;
|
||||
@ -674,8 +685,8 @@ simply invoke the ``lib/message/Install.py`` script with the specified args:
|
||||
$ make lib-message args="-s" # build as serial lib with no ZMQ support
|
||||
|
||||
The build should produce two files: ``lib/message/cslib/src/libmessage.a``
|
||||
and ``lib/message/Makefile.lammps``\ . The latter is copied from an
|
||||
existing ``Makefile.lammps.\*`` and has settings to link with the ZeroMQ
|
||||
and ``lib/message/Makefile.lammps``. The latter is copied from an
|
||||
existing ``Makefile.lammps.*`` and has settings to link with the ZeroMQ
|
||||
library if requested in the build.
|
||||
|
||||
----------
|
||||
@ -691,7 +702,8 @@ library. Building the MS-CG library requires that the GSL
|
||||
machine. See the ``lib/mscg/README`` and ``MSCG/Install`` files for
|
||||
more details.
|
||||
|
||||
**CMake build**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -706,7 +718,8 @@ filename (plus path) of the MSCG library file, not the directory the
|
||||
library file is in. ``MSCG_INCLUDE_DIR`` is the directory the MSCG
|
||||
include file is in.
|
||||
|
||||
**Traditional make**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
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
|
||||
@ -734,16 +747,18 @@ not need to edit the ``lib/mscg/Makefile.lammps`` file.
|
||||
OPT package
|
||||
---------------------
|
||||
|
||||
**CMake build**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
No additional settings are needed besides ``-D PKG_OPT=yes``
|
||||
|
||||
**Traditional make**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
The compile flag "-restrict" must be used to build LAMMPS with the OPT
|
||||
The compile flag ``-restrict`` must be used to build LAMMPS with the OPT
|
||||
package when using Intel compilers. It should be added to the CCFLAGS
|
||||
line of your Makefile.machine. See src/MAKE/OPTIONS/Makefile.opt for
|
||||
an example.
|
||||
line of your ``Makefile.machine``. See
|
||||
``src/MAKE/OPTIONS/Makefile.opt`` for an example.
|
||||
|
||||
----------
|
||||
|
||||
@ -752,11 +767,13 @@ an example.
|
||||
POEMS package
|
||||
-------------------------
|
||||
|
||||
**CMake build**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
No additional settings are needed besides ``-D PKG_OPT=yes``
|
||||
|
||||
**Traditional make**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
Before building LAMMPS, you must build the POEMS library in ``lib/poems``\ .
|
||||
You can do this manually if you prefer; follow the instructions in
|
||||
@ -772,8 +789,8 @@ dir, using a command like these, which simply invoke the
|
||||
$ make lib-poems args="-m icc" # build with Intel icc compiler
|
||||
|
||||
The build should produce two files: ``lib/poems/libpoems.a`` and
|
||||
``lib/poems/Makefile.lammps``\ . The latter is copied from an existing
|
||||
``Makefile.lammps.\*`` and has settings needed to build LAMMPS with the
|
||||
``lib/poems/Makefile.lammps``. The latter is copied from an existing
|
||||
``Makefile.lammps.*`` and has settings needed to build LAMMPS with the
|
||||
POEMS library (though typically the settings are just blank). If
|
||||
necessary, you can edit/create a new ``lib/poems/Makefile.machine`` file
|
||||
for your system, which should define an ``EXTRAMAKE`` variable to specify
|
||||
@ -791,7 +808,8 @@ library available on your system, which needs to be a Python 2.7
|
||||
version or a Python 3.x version. See ``lib/python/README`` for more
|
||||
details.
|
||||
|
||||
**CMake build**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -804,11 +822,12 @@ PYTHON_EXECUTABLE variable to specify which Python interpreter should
|
||||
be used. Note note that you will also need to have the development
|
||||
headers installed for this version, e.g. python2-devel.
|
||||
|
||||
**Traditional make**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
The build uses the ``lib/python/Makefile.lammps`` file in the compile/link
|
||||
process to find Python. You should only need to create a new
|
||||
``Makefile.lammps.\*`` file (and copy it to ``Makefile.lammps``\ ) if
|
||||
``Makefile.lammps.*`` file (and copy it to ``Makefile.lammps``) if
|
||||
the LAMMPS build fails.
|
||||
|
||||
----------
|
||||
@ -822,7 +841,8 @@ To build with this package, you must download and build the `Voro++ library <vor
|
||||
|
||||
.. _voro-home: http://math.lbl.gov/voro++
|
||||
|
||||
**CMake build**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -830,19 +850,20 @@ To build with this package, you must download and build the `Voro++ library <vor
|
||||
-D VORO_LIBRARY=path # Voro++ library file (only needed if at custom location)
|
||||
-D VORO_INCLUDE_DIR=path # Voro++ include directory (only needed if at custom location)
|
||||
|
||||
If DOWNLOAD_VORO is set, the Voro++ library will be downloaded and
|
||||
If ``DOWNLOAD_VORO`` is set, the Voro++ library will be downloaded and
|
||||
built inside the CMake build directory. If the Voro++ library is
|
||||
already on your system (in a location CMake cannot find it),
|
||||
VORO_LIBRARY is the filename (plus path) of the Voro++ library file,
|
||||
not the directory the library file is in. VORO_INCLUDE_DIR is the
|
||||
``VORO_LIBRARY`` is the filename (plus path) of the Voro++ library file,
|
||||
not the directory the library file is in. ``VORO_INCLUDE_DIR`` is the
|
||||
directory the Voro++ include file is in.
|
||||
|
||||
**Traditional make**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
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 lib/voronoi/Install.py script with the specified
|
||||
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 ``lib/voronoi/Install.py`` script with the specified
|
||||
args:
|
||||
|
||||
.. code-block:: bash
|
||||
@ -852,10 +873,10 @@ args:
|
||||
$ make lib-voronoi args="-p $HOME/voro++" # use existing Voro++ installation in $HOME/voro++
|
||||
$ make lib-voronoi args="-b -v voro++0.4.6" # download and build the 0.4.6 version in lib/voronoi/voro++-0.4.6
|
||||
|
||||
Note that 2 symbolic (soft) links, "includelink" and "liblink", are
|
||||
created in lib/voronoi to point to the Voro++ src dir. When LAMMPS
|
||||
builds in src it will use these links. You should not need to edit
|
||||
the lib/voronoi/Makefile.lammps file.
|
||||
Note that 2 symbolic (soft) links, ``includelink`` and ``liblink``, are
|
||||
created in lib/voronoi to point to the Voro++ source dir. When LAMMPS
|
||||
builds in ``src`` it will use these links. You should not need to edit
|
||||
the ``lib/voronoi/Makefile.lammps`` file.
|
||||
|
||||
----------
|
||||
|
||||
@ -864,23 +885,28 @@ the lib/voronoi/Makefile.lammps file.
|
||||
USER-ADIOS package
|
||||
-----------------------------------
|
||||
|
||||
The USER-ADIOS package requires the `ADIOS I/O library <https://github.com/ornladios/ADIOS2>`_,
|
||||
version 2.3.1 or newer. Make sure that you have ADIOS built either with or
|
||||
without MPI to match if you build LAMMPS with or without MPI.
|
||||
ADIOS compilation settings for LAMMPS are automatically detected, if the PATH
|
||||
and LD_LIBRARY_PATH environment variables have been updated for the local ADIOS
|
||||
installation and the instructions below are followed for the respective build systems.
|
||||
The USER-ADIOS package requires the `ADIOS I/O library
|
||||
<https://github.com/ornladios/ADIOS2>`_, version 2.3.1 or newer. Make
|
||||
sure that you have ADIOS built either with or without MPI to match if
|
||||
you build LAMMPS with or without MPI. ADIOS compilation settings for
|
||||
LAMMPS are automatically detected, if the PATH and LD_LIBRARY_PATH
|
||||
environment variables have been updated for the local ADIOS installation
|
||||
and the instructions below are followed for the respective build
|
||||
systems.
|
||||
|
||||
**CMake build**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
-D ADIOS2_DIR=path # path is where ADIOS 2.x is installed
|
||||
-D PKG_USER-ADIOS=yes
|
||||
|
||||
**Traditional make**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
Turn on the USER-ADIOS package before building LAMMPS. If the ADIOS 2.x software is installed in PATH, there is nothing else to do:
|
||||
Turn on the USER-ADIOS package before building LAMMPS. If the ADIOS 2.x
|
||||
software is installed in PATH, there is nothing else to do:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -901,18 +927,20 @@ USER-ATC package
|
||||
|
||||
The USER-ATC package requires the MANYBODY package also be installed.
|
||||
|
||||
**CMake build**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
No additional settings are needed besides "-D PKG_USER-ATC=yes"
|
||||
and "-D PKG_MANYBODY=yes".
|
||||
|
||||
**Traditional make**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
Before building LAMMPS, you must build the ATC library in lib/atc.
|
||||
Before building LAMMPS, you must build the ATC library in ``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 specified args:
|
||||
``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 specified args:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -921,19 +949,19 @@ lib/atc/Install.py script with the specified args:
|
||||
$ make lib-atc args="-m mpi" # build with default MPI compiler (settings as with "make mpi")
|
||||
$ make lib-atc args="-m icc" # build with Intel icc compiler
|
||||
|
||||
The build should produce two files: lib/atc/libatc.a and
|
||||
lib/atc/Makefile.lammps. The latter is copied from an existing
|
||||
Makefile.lammps.\* and has settings needed to build LAMMPS with the ATC
|
||||
library. If necessary, you can edit/create a new
|
||||
lib/atc/Makefile.machine file for your system, which should define an
|
||||
EXTRAMAKE variable to specify a corresponding Makefile.lammps.machine
|
||||
file.
|
||||
The build should produce two files: ``lib/atc/libatc.a`` and
|
||||
``lib/atc/Makefile.lammps``. The latter is copied from an existing
|
||||
``Makefile.lammps.*`` and has settings needed to build LAMMPS with the
|
||||
ATC library. If necessary, you can edit/create a new
|
||||
``lib/atc/Makefile.machine`` file for your system, which should define
|
||||
an ``EXTRAMAKE`` variable to specify a corresponding
|
||||
``Makefile.lammps.<machine>`` file.
|
||||
|
||||
Note that the Makefile.lammps file has settings for the BLAS and
|
||||
LAPACK linear algebra libraries. As explained in lib/atc/README these
|
||||
LAPACK linear algebra libraries. As explained in ``lib/atc/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:
|
||||
``lib/linalg``. In the latter case you also need to build the library in
|
||||
``lib/linalg`` with a command like these:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -947,19 +975,21 @@ lib/linalg with a command like these:
|
||||
.. _user-awpmd:
|
||||
|
||||
USER-AWPMD package
|
||||
-----------------------------------
|
||||
------------------
|
||||
|
||||
**CMake build**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
No additional settings are needed besides "-D PKG_USER-AQPMD=yes".
|
||||
No additional settings are needed besides ``-D PKG_USER-AQPMD=yes``.
|
||||
|
||||
**Traditional make**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
Before building LAMMPS, you must build the AWPMD library in lib/awpmd.
|
||||
Before building LAMMPS, you must build the AWPMD library in ``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
|
||||
``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 specified args:
|
||||
``lib/awpmd/Install.py`` script with the specified args:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -968,19 +998,19 @@ lib/awpmd/Install.py script with the specified args:
|
||||
$ make lib-awpmd args="-m mpi" # build with default MPI compiler (settings as with "make mpi")
|
||||
$ make lib-awpmd args="-m icc" # build with Intel icc compiler
|
||||
|
||||
The build should produce two files: lib/awpmd/libawpmd.a and
|
||||
lib/awpmd/Makefile.lammps. The latter is copied from an existing
|
||||
Makefile.lammps.\* and has settings needed to build LAMMPS with the
|
||||
The build should produce two files: ``lib/awpmd/libawpmd.a`` and
|
||||
``lib/awpmd/Makefile.lammps``. The latter is copied from an existing
|
||||
``Makefile.lammps.*`` and has settings needed to build LAMMPS with the
|
||||
AWPMD library. If necessary, you can edit/create a new
|
||||
lib/awpmd/Makefile.machine file for your system, which should define
|
||||
an EXTRAMAKE variable to specify a corresponding
|
||||
Makefile.lammps.machine file.
|
||||
``lib/awpmd/Makefile.machine`` file for your system, which should define
|
||||
an ``EXTRAMAKE`` variable to specify a corresponding
|
||||
``Makefile.lammps.<machine>`` file.
|
||||
|
||||
Note that the Makefile.lammps file has settings for the BLAS and
|
||||
LAPACK linear algebra libraries. As explained in lib/awpmd/README
|
||||
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:
|
||||
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
|
||||
|
||||
@ -999,36 +1029,26 @@ USER-COLVARS package
|
||||
This package includes into the LAMMPS distribution the Colvars library, which
|
||||
can be built for the most part with all major versions of the C++ language.
|
||||
|
||||
A few of the most recent features require C++11 support. In particular, the
|
||||
library is optionally built together with the
|
||||
`Lepton <https://simtk.org/projects/lepton>`_ library, a copy of which is also
|
||||
included in the LAMMPS distribution. Lepton implements the
|
||||
`customFunction <http://colvars.github.io/colvars-refman-lammps/colvars-refman-lammps.html#colvar|customFunction>`_
|
||||
feature, and requires C++11 support.
|
||||
|
||||
See `here <https://colvars.github.io/README-c++11.html>`_ for a detailed list of
|
||||
C++11-only features.
|
||||
|
||||
**CMake build**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
This is the recommended build recipe: no additional settings are normally
|
||||
needed besides "-D PKG_USER-COLVARS=yes".
|
||||
needed besides ``-D PKG_USER-COLVARS=yes``.
|
||||
|
||||
Building and linking of Lepton (or other C++11-only features) is enabled
|
||||
automatically when compilation is carried out with C++11 support, and disabled
|
||||
otherwise. Optionally, Lepton build may be manually controlled with the flag
|
||||
"-D COLVARS_LEPTON=yes\|no".
|
||||
|
||||
**Traditional make**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
Before building LAMMPS, one must build the Colvars library in lib/colvars.
|
||||
|
||||
This can be done manually in the same folder by using or adapting one of the
|
||||
provided Makefiles: for example, Makefile.g++ for the GNU compiler.
|
||||
This can be done manually in the same folder by using or adapting one of
|
||||
the provided Makefiles: for example, ``Makefile.g++`` for the GNU C++
|
||||
compiler. C++11 compatibility may need to be enabled for some older
|
||||
compilers (as is done in the example makefile).
|
||||
|
||||
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 lib/colvars/Install.py script with
|
||||
command like these, which simply invoke the ``lib/colvars/Install.py`` script with
|
||||
the specified args:
|
||||
|
||||
.. code-block:: bash
|
||||
@ -1039,7 +1059,7 @@ the specified args:
|
||||
$ make lib-colvars args="-m g++-debug" # build with GNU g++ compiler and colvars debugging enabled
|
||||
|
||||
The "machine" argument of the "-m" flag is used to find a Makefile.machine to
|
||||
use as build recipe. If it does not already exist in lib/colvars, it will be
|
||||
use as build recipe. If it does not already exist in ``lib/colvars``, it will be
|
||||
auto-generated by using compiler flags consistent with those parsed from the
|
||||
core LAMMPS makefiles.
|
||||
|
||||
@ -1050,9 +1070,9 @@ Optional flags may be specified as environment variables:
|
||||
$ COLVARS_DEBUG=yes make lib-colvars args="-m machine" # Build with debug code (much slower)
|
||||
$ COLVARS_LEPTON=no make lib-colvars args="-m machine" # Build without Lepton (included otherwise)
|
||||
|
||||
The build should produce two files: the library lib/colvars/libcolvars.a
|
||||
The build should produce two files: the library ``lib/colvars/libcolvars.a``
|
||||
(which also includes Lepton objects if enabled) and the specification file
|
||||
lib/colvars/Makefile.lammps. The latter is auto-generated, and normally does
|
||||
``lib/colvars/Makefile.lammps``. The latter is auto-generated, and normally does
|
||||
not need to be edited.
|
||||
|
||||
----------
|
||||
@ -1099,12 +1119,14 @@ try a different one, switch to a different build system, consider a
|
||||
global PLUMED installation or consider downloading PLUMED during the
|
||||
LAMMPS build.
|
||||
|
||||
**CMake build**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
When the "-D PKG_USER-PLUMED" flag is included in the cmake command you
|
||||
must ensure that GSL is installed in locations that are specified in
|
||||
your environment. There are then two additional commands that control
|
||||
the manner in which PLUMED is obtained and linked into LAMMPS.
|
||||
When the ``-D PKG_USER-PLUMED=yes`` flag is included in the cmake
|
||||
command you must ensure that GSL is installed in locations that are
|
||||
specified in your environment. There are then two additional variables
|
||||
that control the manner in which PLUMED is obtained and linked into
|
||||
LAMMPS.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -1114,21 +1136,22 @@ the manner in which PLUMED is obtained and linked into LAMMPS.
|
||||
If DOWNLOAD_PLUMED is set to "yes", the PLUMED library will be
|
||||
downloaded (the version of PLUMED that will be downloaded is hard-coded
|
||||
to a vetted version of PLUMED, usually a recent stable release version)
|
||||
and built inside the CMake build directory. If DOWNLOAD_PLUMED is set
|
||||
to "no" (the default), CMake will try to detect and link to an installed
|
||||
version of PLUMED. For this to work, the PLUMED library has to be
|
||||
installed into a location where the pkg-config tool can find it or the
|
||||
PKG_CONFIG_PATH environment variable has to be set up accordingly.
|
||||
PLUMED should be installed in such a location if you compile it using
|
||||
the default make; make install commands.
|
||||
and built inside the CMake build directory. If ``DOWNLOAD_PLUMED`` is
|
||||
set to "no" (the default), CMake will try to detect and link to an
|
||||
installed version of PLUMED. For this to work, the PLUMED library has
|
||||
to be installed into a location where the ``pkg-config`` tool can find
|
||||
it or the PKG_CONFIG_PATH environment variable has to be set up
|
||||
accordingly. PLUMED should be installed in such a location if you
|
||||
compile it using the default make; make install commands.
|
||||
|
||||
The PLUMED_MODE setting determines the linkage mode for the PLUMED
|
||||
The ``PLUMED_MODE`` setting determines the linkage mode for the PLUMED
|
||||
library. The allowed values for this flag are "static" (default),
|
||||
"shared", or "runtime". For a discussion of PLUMED linkage modes,
|
||||
please see above. When DOWNLOAD_PLUMED is enabled the static linkage
|
||||
mode is recommended.
|
||||
please see above. When ``DOWNLOAD_PLUMED`` is enabled the static
|
||||
linkage mode is recommended.
|
||||
|
||||
**Traditional make**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
PLUMED needs to be installed before the USER-PLUMED package is installed
|
||||
so that LAMMPS can find the right settings when compiling and linking
|
||||
@ -1149,9 +1172,9 @@ from the src folder through the following make args:
|
||||
$ make lib-plumed args="-p /usr/local -m shared" # use existing PLUMED installation in
|
||||
# /usr/local and use shared linkage mode
|
||||
|
||||
Note that 2 symbolic (soft) links, "includelink" and "liblink" are
|
||||
Note that 2 symbolic (soft) links, ``includelink`` and ``liblink`` are
|
||||
created in lib/plumed that point to the location of the PLUMED build to
|
||||
use. A new file lib/plumed/Makefile.lammps is also created with settings
|
||||
use. A new file ``lib/plumed/Makefile.lammps`` is also created with settings
|
||||
suitable for LAMMPS to compile and link PLUMED using the desired linkage
|
||||
mode. After this step is completed, you can install the USER-PLUMED
|
||||
package and compile LAMMPS in the usual manner:
|
||||
@ -1186,9 +1209,10 @@ To build with this package you must have the HDF5 software package
|
||||
installed on your system, which should include the h5cc compiler and
|
||||
the HDF5 library.
|
||||
|
||||
**CMake build**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
No additional settings are needed besides "-D PKG_USER-H5MD=yes".
|
||||
No additional settings are needed besides ``-D PKG_USER-H5MD=yes``.
|
||||
|
||||
This should auto-detect the H5MD library on your system. Several
|
||||
advanced CMake H5MD options exist if you need to specify where it is
|
||||
@ -1196,26 +1220,27 @@ installed. Use the ccmake (terminal window) or cmake-gui (graphical)
|
||||
tools to see these options and set them interactively from their user
|
||||
interfaces.
|
||||
|
||||
**Traditional make**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
Before building LAMMPS, you must build the CH5MD library in 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 specified args:
|
||||
Before building LAMMPS, you must build the CH5MD library in
|
||||
``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 specified args:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ make lib-h5md # print help message
|
||||
$ make lib-h5md args="-m h5cc" # build with h5cc compiler
|
||||
|
||||
The build should produce two files: lib/h5md/libch5md.a and
|
||||
lib/h5md/Makefile.lammps. The latter is copied from an existing
|
||||
Makefile.lammps.\* and has settings needed to build LAMMPS with the
|
||||
The build should produce two files: ``lib/h5md/libch5md.a`` and
|
||||
``lib/h5md/Makefile.lammps``. The latter is copied from an existing
|
||||
``Makefile.lammps.*`` and has settings needed to build LAMMPS with the
|
||||
system HDF5 library. If necessary, you can edit/create a new
|
||||
lib/h5md/Makefile.machine file for your system, which should define an
|
||||
EXTRAMAKE variable to specify a corresponding Makefile.lammps.machine
|
||||
file.
|
||||
``lib/h5md/Makefile.machine`` file for your system, which should define
|
||||
an EXTRAMAKE variable to specify a corresponding
|
||||
``Makefile.lammps.<machine>`` file.
|
||||
|
||||
----------
|
||||
|
||||
@ -1230,7 +1255,8 @@ also typically :ref:`install the USER-OMP package <user-omp>`, as it can be
|
||||
used in tandem with the USER-INTEL package to good effect, as explained
|
||||
on the :doc:`Speed intel <Speed_intel>` doc page.
|
||||
|
||||
**CMake build**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -1249,11 +1275,12 @@ Best performance is achieved with Intel hardware, Intel compilers, as well as
|
||||
the Intel TBB and MKL libraries. However, the code also compiles, links, and
|
||||
runs with other compilers and without TBB and MKL.
|
||||
|
||||
**Traditional make**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
Choose which hardware to compile for in Makefile.machine via the
|
||||
following settings. See src/MAKE/OPTIONS/Makefile.intel_cpu\* and
|
||||
Makefile.knl files for examples. and src/USER-INTEL/README for
|
||||
following settings. See ``src/MAKE/OPTIONS/Makefile.intel_cpu*`` and
|
||||
``Makefile.knl`` files for examples. and ``src/USER-INTEL/README`` for
|
||||
additional information.
|
||||
|
||||
For CPUs:
|
||||
@ -1320,7 +1347,8 @@ define an ``EXTRAMAKE`` variable to specify a corresponding
|
||||
USER-MOLFILE package
|
||||
---------------------------------------
|
||||
|
||||
**CMake build**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -1335,13 +1363,14 @@ folder of the local VMD installation in use. LAMMPS ships with a
|
||||
couple of default header files that correspond to a popular VMD
|
||||
version, usually the latest release.
|
||||
|
||||
**Traditional make**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
The lib/molfile/Makefile.lammps file has a setting for a dynamic
|
||||
The ``lib/molfile/Makefile.lammps`` file has a setting for a dynamic
|
||||
loading library libdl.a that is typically present on all systems. It
|
||||
is required for LAMMPS to link with this package. If the setting is
|
||||
not valid for your system, you will need to edit the Makefile.lammps
|
||||
file. See lib/molfile/README and lib/molfile/Makefile.lammps for
|
||||
file. See ``lib/molfile/README`` and ``lib/molfile/Makefile.lammps`` for
|
||||
details. It is also possible to configure a different folder with
|
||||
the VMD molfile plugin header files. LAMMPS ships with a couple of
|
||||
default headers, but these are not compatible with all VMD versions,
|
||||
@ -1358,22 +1387,24 @@ USER-NETCDF package
|
||||
To build with this package you must have the NetCDF library installed
|
||||
on your system.
|
||||
|
||||
**CMake build**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
No additional settings are needed besides "-D PKG_USER-NETCDF=yes".
|
||||
No additional settings are needed besides ``-D PKG_USER-NETCDF=yes``.
|
||||
|
||||
This should auto-detect the NETCDF library if it is installed on your
|
||||
system at standard locations. Several advanced CMake NETCDF options
|
||||
exist if you need to specify where it was installed. Use the ccmake
|
||||
(terminal window) or cmake-gui (graphical) tools to see these options
|
||||
and set them interactively from their user interfaces.
|
||||
exist if you need to specify where it was installed. Use the ``ccmake``
|
||||
(terminal window) or ``cmake-gui`` (graphical) tools to see these
|
||||
options and set them interactively from their user interfaces.
|
||||
|
||||
**Traditional make**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
The lib/netcdf/Makefile.lammps file has settings for NetCDF include
|
||||
The ``lib/netcdf/Makefile.lammps`` file has settings for NetCDF include
|
||||
and library files which LAMMPS needs to build with this package. If
|
||||
the settings are not valid for your system, you will need to edit the
|
||||
Makefile.lammps file. See lib/netcdf/README for details.
|
||||
``Makefile.lammps`` file. See ``lib/netcdf/README`` for details.
|
||||
|
||||
----------
|
||||
|
||||
@ -1382,18 +1413,20 @@ Makefile.lammps file. See lib/netcdf/README for details.
|
||||
USER-OMP package
|
||||
-------------------------------
|
||||
|
||||
**CMake build**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
No additional settings are required besides "-D PKG_USER-OMP=yes". If
|
||||
No additional settings are required besides ``-D PKG_USER-OMP=yes``. If
|
||||
CMake detects OpenMP support, the USER-OMP code will be compiled with
|
||||
multi-threading support enabled, otherwise as optimized serial code.
|
||||
|
||||
**Traditional make**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
To enable multi-threading support in the USER-OMP package (and other
|
||||
styles supporting OpenMP) the following compile and link flags must
|
||||
be added to your Makefile.machine file.
|
||||
See src/MAKE/OPTIONS/Makefile.omp for an example.
|
||||
styles supporting OpenMP) the following compile and link flags must be
|
||||
added to your Makefile.machine file. See
|
||||
``src/MAKE/OPTIONS/Makefile.omp`` for an example.
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
@ -1403,8 +1436,7 @@ See src/MAKE/OPTIONS/Makefile.omp for an example.
|
||||
LINKFLAGS: -qopenmp # for Intel compilers on Linux
|
||||
|
||||
For other platforms and compilers, please consult the documentation
|
||||
about OpenMP support for your compiler. Please see the note about
|
||||
how to address compatibility :ref:`issues with the 'default(none)' directive <default-none-issues>` of some compilers.
|
||||
about OpenMP support for your compiler.
|
||||
|
||||
----------
|
||||
|
||||
@ -1414,19 +1446,20 @@ USER-QMMM package
|
||||
---------------------------------
|
||||
|
||||
For using LAMMPS to do QM/MM simulations via the USER-QMMM package you
|
||||
need to build LAMMPS as a library. A LAMMPS executable with fix qmmm
|
||||
included can be built, but will not be able to do a QM/MM simulation
|
||||
on as such. You must also build a QM code - currently only Quantum
|
||||
ESPRESSO (QE) is supported - and create a new executable which links
|
||||
LAMMPS and the QM code together. Details are given in the
|
||||
lib/qmmm/README file. It is also recommended to read the instructions
|
||||
for :doc:`linking with LAMMPS as a library <Build_link>` for
|
||||
background information. This requires compatible Quantum Espresso
|
||||
and LAMMPS versions. The current interface and makefiles have last
|
||||
been verified to work in February 2020 with Quantum Espresso versions
|
||||
6.3 to 6.5.
|
||||
need to build LAMMPS as a library. A LAMMPS executable with :doc:`fix
|
||||
qmmm <fix_qmmm>` included can be built, but will not be able to do a
|
||||
QM/MM simulation on as such. You must also build a QM code - currently
|
||||
only Quantum ESPRESSO (QE) is supported - and create a new executable
|
||||
which links LAMMPS and the QM code together. Details are given in the
|
||||
``lib/qmmm/README`` file. It is also recommended to read the
|
||||
instructions for :doc:`linking with LAMMPS as a library <Build_link>`
|
||||
for background information. This requires compatible Quantum Espresso
|
||||
and LAMMPS versions. The current interface and makefiles have last been
|
||||
verified to work in February 2020 with Quantum Espresso versions 6.3 to
|
||||
6.5.
|
||||
|
||||
**CMake build**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
When using CMake, building a LAMMPS library is required and it is
|
||||
recommended to build a shared library, since any libraries built from
|
||||
@ -1443,17 +1476,18 @@ would be:
|
||||
|
||||
After completing the LAMMPS build and also configuring and compiling
|
||||
Quantum ESPRESSO with external library support (via "make couple"),
|
||||
go back to the lib/qmmm folder and follow the instructions on the
|
||||
go back to the ``lib/qmmm` folder and follow the instructions on the
|
||||
README file to build the combined LAMMPS/QE QM/MM executable
|
||||
(pwqmmm.x) in the lib/qmmm folder. You need to make certain, that
|
||||
(pwqmmm.x) in the ``lib/qmmm`` folder. You need to make certain, that
|
||||
|
||||
**Traditional make**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
Before building LAMMPS, you must build the QMMM library in lib/qmmm.
|
||||
Before building LAMMPS, you must build the QMMM library in ``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 the specified args:
|
||||
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 the specified args:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -1462,18 +1496,18 @@ lib/qmmm/Install.py script with the specified args:
|
||||
$ make lib-qmmm args="-m mpi" # build with default MPI compiler (settings as in "make mpi")
|
||||
$ make lib-qmmm args="-m gfortran" # build with GNU Fortran compiler
|
||||
|
||||
The build should produce two files: lib/qmmm/libqmmm.a and
|
||||
lib/qmmm/Makefile.lammps. The latter is copied from an existing
|
||||
Makefile.lammps.\* and has settings needed to build LAMMPS with the
|
||||
The build should produce two files: ``lib/qmmm/libqmmm.a`` and
|
||||
``lib/qmmm/Makefile.lammps``. The latter is copied from an existing
|
||||
``Makefile.lammps.*`` and has settings needed to build LAMMPS with the
|
||||
QMMM library (though typically the settings are just blank). If
|
||||
necessary, you can edit/create a new lib/qmmm/Makefile.machine file
|
||||
for your system, which should define an EXTRAMAKE variable to specify
|
||||
a corresponding Makefile.lammps.machine file.
|
||||
necessary, you can edit/create a new ``lib/qmmm/Makefile.<machine>`` file
|
||||
for your system, which should define an ``EXTRAMAKE`` variable to
|
||||
specify a corresponding ``Makefile.lammps.<machine>`` file.
|
||||
|
||||
You can then install QMMM package and build LAMMPS in the usual
|
||||
manner. After completing the LAMMPS build and compiling Quantum
|
||||
ESPRESSO with external library support (via "make couple"), go back to
|
||||
the lib/qmmm folder and follow the instructions in the README file to
|
||||
the ``lib/qmmm`` folder and follow the instructions in the README file to
|
||||
build the combined LAMMPS/QE QM/MM executable (pwqmmm.x) in the
|
||||
lib/qmmm folder.
|
||||
|
||||
@ -1488,26 +1522,28 @@ To build with this package, you must download and build the QUIP
|
||||
library. It can be obtained from GitHub. For support of GAP
|
||||
potentials, additional files with specific licensing conditions need
|
||||
to be downloaded and configured. See step 1 and step 1.1 in the
|
||||
lib/quip/README file for details on how to do this.
|
||||
``lib/quip/README`` file for details on how to do this.
|
||||
|
||||
**CMake build**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
-D QUIP_LIBRARY=path # path to libquip.a (only needed if a custom location)
|
||||
|
||||
CMake will not download and build the QUIP library. But once you have
|
||||
done that, a CMake build of LAMMPS with "-D PKG_USER-QUIP=yes" should
|
||||
done that, a CMake build of LAMMPS with ``-D PKG_USER-QUIP=yes`` should
|
||||
work. Set QUIP_LIBRARY if CMake cannot find the QUIP library.
|
||||
|
||||
**Traditional make**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
The download/build procedure for the QUIP library, described in
|
||||
lib/quip/README file requires setting two environment variables,
|
||||
``lib/quip/README`` file requires setting two environment variables,
|
||||
QUIP_ROOT and QUIP_ARCH. These are accessed by the
|
||||
lib/quip/Makefile.lammps file which is used when you compile and link
|
||||
LAMMPS with this package. You should only need to edit
|
||||
Makefile.lammps if the LAMMPS build can not use its settings to
|
||||
``Makefile.lammps`` if the LAMMPS build can not use its settings to
|
||||
successfully build on your system.
|
||||
|
||||
----------
|
||||
@ -1517,11 +1553,13 @@ successfully build on your system.
|
||||
USER-SCAFACOS package
|
||||
-----------------------------------------
|
||||
|
||||
To build with this package, you must download and build the `ScaFaCoS Coulomb solver library <scafacos-home_>`_
|
||||
To build with this package, you must download and build the `ScaFaCoS
|
||||
Coulomb solver library <scafacos-home_>`_
|
||||
|
||||
.. _scafacos-home: http://www.scafacos.de
|
||||
|
||||
**CMake build**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -1536,22 +1574,23 @@ SCAFACOS_LIBRARY is the filename (plus path) of the ScaFaCoS library
|
||||
file, not the directory the library file is in. SCAFACOS_INCLUDE_DIR
|
||||
is the directory the ScaFaCoS include file is in.
|
||||
|
||||
**Traditional make**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
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 lib/scafacos/Install.py script with the
|
||||
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 ``lib/scafacos/Install.py`` script with the
|
||||
specified args:
|
||||
|
||||
make lib-scafacos # print help message
|
||||
make lib-scafacos args="-b" # download and build in lib/scafacos/scafacos-<version>
|
||||
make lib-scafacos args="-p $HOME/scafacos # use existing ScaFaCoS installation in $HOME/scafacos
|
||||
|
||||
Note that 2 symbolic (soft) links, "includelink" and "liblink", are
|
||||
created in lib/scafacos to point to the ScaFaCoS src dir. When LAMMPS
|
||||
Note that 2 symbolic (soft) links, ``includelink`` and ``liblink``, are
|
||||
created in ``lib/scafacos`` to point to the ScaFaCoS src dir. When LAMMPS
|
||||
builds in src it will use these links. You should not need to edit
|
||||
the lib/scafacos/Makefile.lammps file.
|
||||
the ``lib/scafacos/Makefile.lammps`` file.
|
||||
|
||||
----------
|
||||
|
||||
@ -1563,24 +1602,26 @@ USER-SMD package
|
||||
To build with this package, you must download the Eigen3 library.
|
||||
Eigen3 is a template library, so you do not need to build it.
|
||||
|
||||
**CMake build**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
-D DOWNLOAD_EIGEN3 # download Eigen3, value = no (default) or yes
|
||||
-D EIGEN3_INCLUDE_DIR=path # path to Eigen library (only needed if a custom location)
|
||||
|
||||
If DOWNLOAD_EIGEN3 is set, the Eigen3 library will be downloaded and
|
||||
If ``DOWNLOAD_EIGEN3`` is set, the Eigen3 library will be downloaded and
|
||||
inside the CMake build directory. If the Eigen3 library is already on
|
||||
your system (in a location CMake cannot find it), EIGEN3_INCLUDE_DIR
|
||||
your system (in a location CMake cannot find it), ``EIGEN3_INCLUDE_DIR``
|
||||
is the directory the Eigen3++ include file is in.
|
||||
|
||||
**Traditional make**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
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 specified args:
|
||||
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 specified args:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -1588,9 +1629,9 @@ the lib/smd/Install.py script with the specified args:
|
||||
$ make lib-smd args="-b" # download to lib/smd/eigen3
|
||||
$ make lib-smd args="-p /usr/include/eigen3" # use existing Eigen installation in /usr/include/eigen3
|
||||
|
||||
Note that a symbolic (soft) link named "includelink" is created in
|
||||
lib/smd to point to the Eigen dir. When LAMMPS builds it will use
|
||||
this link. You should not need to edit the lib/smd/Makefile.lammps
|
||||
Note that a symbolic (soft) link named ``includelink`` is created in
|
||||
``lib/smd`` to point to the Eigen dir. When LAMMPS builds it will use
|
||||
this link. You should not need to edit the ``lib/smd/Makefile.lammps``
|
||||
file.
|
||||
|
||||
----------
|
||||
@ -1603,21 +1644,23 @@ USER-VTK package
|
||||
To build with this package you must have the VTK library installed on
|
||||
your system.
|
||||
|
||||
**CMake build**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
No additional settings are needed besides "-D PKG_USER-VTK=yes".
|
||||
No additional settings are needed besides ``-D PKG_USER-VTK=yes``.
|
||||
|
||||
This should auto-detect the VTK library if it is installed on your
|
||||
system at standard locations. Several advanced VTK options exist if
|
||||
you need to specify where it was installed. Use the ccmake (terminal
|
||||
window) or cmake-gui (graphical) tools to see these options and set
|
||||
you need to specify where it was installed. Use the ``ccmake`` (terminal
|
||||
window) or ``cmake-gui`` (graphical) tools to see these options and set
|
||||
them interactively from their user interfaces.
|
||||
|
||||
**Traditional make**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
The lib/vtk/Makefile.lammps file has settings for accessing VTK files
|
||||
The ``lib/vtk/Makefile.lammps`` file has settings for accessing VTK files
|
||||
and its library, which LAMMPS needs to build with this package. If
|
||||
the settings are not valid for your system, check if one of the other
|
||||
lib/vtk/Makefile.lammps.\* files is compatible and copy it to
|
||||
``lib/vtk/Makefile.lammps.*`` files is compatible and copy it to
|
||||
Makefile.lammps. If none of the provided files work, you will need to
|
||||
edit the Makefile.lammps file. See lib/vtk/README for details.
|
||||
edit the ``Makefile.lammps`` file. See ``lib/vtk/README`` for details.
|
||||
|
||||
@ -1,12 +1,12 @@
|
||||
Link LAMMPS as a library to another code
|
||||
========================================
|
||||
|
||||
LAMMPS is designed as a library of C++ objects and can thus be
|
||||
LAMMPS is designed as a library of C++ objects that can be
|
||||
integrated into other applications including Python scripts.
|
||||
The files ``src/library.cpp`` and ``src/library.h`` define a
|
||||
C-style API for using LAMMPS as a library. See the :doc:`Howto
|
||||
library <Howto_library>` doc page for a description of the interface
|
||||
and how to extend it for your needs.
|
||||
library <Howto_library>` page for a description of the interface
|
||||
and how to use it for your needs.
|
||||
|
||||
The :doc:`Build basics <Build_basics>` doc page explains how to build
|
||||
LAMMPS as either a shared or static library. This results in a file
|
||||
@ -31,18 +31,18 @@ the suffix ``.so.0`` (or some other number).
|
||||
communicator with a subset of MPI ranks to the function creating the
|
||||
LAMMPS instance.
|
||||
|
||||
----------
|
||||
|
||||
**Link with LAMMPS as a static library**\ :
|
||||
Link with LAMMPS as a static library
|
||||
------------------------------------
|
||||
|
||||
The calling application can link to LAMMPS as a static library with
|
||||
compilation and link commands as in the examples shown below. These
|
||||
are examples for a code written in C in the file *caller.c*.
|
||||
are examples for a code written in C in the file ``caller.c``.
|
||||
The benefit of linking to a static library is, that the resulting
|
||||
executable is independent of that library since all required
|
||||
executable code from the library is copied into the calling executable.
|
||||
|
||||
*CMake build*\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
This assumes that LAMMPS has been configured without setting a
|
||||
``LAMMPS_MACHINE`` name, installed with "make install", and the
|
||||
@ -55,7 +55,8 @@ The commands to compile and link a coupled executable are then:
|
||||
mpicc -c -O $(pkgconf liblammps --cflags) caller.c
|
||||
mpicxx -o caller caller.o -$(pkgconf liblammps --libs)
|
||||
|
||||
*Traditional make*\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
This assumes that LAMMPS has been compiled in the folder
|
||||
``${HOME}/lammps/src`` with "make mpi". The commands to compile and link
|
||||
@ -83,20 +84,20 @@ LAMMPS library without any optional packages that depend on libraries
|
||||
need to include all flags, libraries, and paths for the coupled
|
||||
executable, that are also required to link the LAMMPS executable.
|
||||
|
||||
*CMake build*\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
When using CMake, additional libraries with sources in the lib folder
|
||||
are built, but not included in ``liblammps.a`` and (currently) not
|
||||
installed with "make install" and not included in the *pkgconfig*
|
||||
installed with ``make install`` and not included in the ``pkgconfig``
|
||||
configuration file. They can be found in the top level build folder,
|
||||
but you have to determine the necessary link flags manually. It is
|
||||
therefore recommended to either use the traditional make procedure to
|
||||
build and link with a static library or build and link with a shared
|
||||
library instead.
|
||||
|
||||
.. TODO: this needs to be updated to reflect that latest CMake changes after they are complete.
|
||||
|
||||
*Traditional make*\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
After you have compiled a static LAMMPS library using the conventional
|
||||
build system for example with "make mode=static serial". And you also
|
||||
@ -110,10 +111,10 @@ change to:
|
||||
g++ -o caller caller.o -L${HOME}/lammps/lib/poems \
|
||||
-L${HOME}/lammps/src/STUBS -L${HOME}/lammps/src -llammps_serial -lpoems -lmpi_stubs
|
||||
|
||||
Note, that you need to link with "g++" instead of "gcc", since the
|
||||
LAMMPS library is C++ code. You can display the currently applied
|
||||
settings for building LAMMPS for the "serial" machine target by using
|
||||
the command:
|
||||
Note, that you need to link with ``g++`` instead of ``gcc`` even if you have
|
||||
written your code in C, since LAMMPS itself is C++ code. You can display the
|
||||
currently applied settings for building LAMMPS for the "serial" machine target
|
||||
by using the command:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -123,25 +124,24 @@ Which should output something like:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# Compiler:
|
||||
# Compiler:
|
||||
CXX=g++
|
||||
# Linker:
|
||||
# Linker:
|
||||
LD=g++
|
||||
# Compilation:
|
||||
# Compilation:
|
||||
CXXFLAGS=-g -O3 -DLAMMPS_GZIP -DLAMMPS_MEMALIGN=64 -I${HOME}/compile/lammps/lib/poems -I${HOME}/compile/lammps/src/STUBS
|
||||
# Linking:
|
||||
# Linking:
|
||||
LDFLAGS=-g -O
|
||||
# Libraries:
|
||||
# Libraries:
|
||||
LDLIBS=-L${HOME}/compile/lammps/src -llammps_serial -L${HOME}/compile/lammps/lib/poems -L${HOME}/compile/lammps/src/STUBS -lpoems -lmpi_stubs
|
||||
|
||||
From this you can gather the necessary paths and flags. With
|
||||
makefiles for other *machine* configurations you need to do the
|
||||
equivalent and replace "serial" with the corresponding *machine* name
|
||||
equivalent and replace "serial" with the corresponding "machine" name
|
||||
of the makefile.
|
||||
|
||||
----------
|
||||
|
||||
**Link with LAMMPS as a shared library**\ :
|
||||
Link with LAMMPS as a shared library
|
||||
------------------------------------
|
||||
|
||||
When linking to LAMMPS built as a shared library, the situation becomes
|
||||
much simpler, as all dependent libraries and objects are either included
|
||||
@ -151,7 +151,8 @@ linking the calling executable. Only the *-I* flags are needed. So the
|
||||
example case from above of the serial version static LAMMPS library with
|
||||
the POEMS package installed becomes:
|
||||
|
||||
*CMake build*\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
The commands with a shared LAMMPS library compiled with the CMake
|
||||
build process are the same as for the static library.
|
||||
@ -161,10 +162,11 @@ build process are the same as for the static library.
|
||||
mpicc -c -O $(pkgconf liblammps --cflags) caller.c
|
||||
mpicxx -o caller caller.o -$(pkgconf --libs)
|
||||
|
||||
*Traditional make*\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
The commands with a shared LAMMPS library compiled with the
|
||||
traditional make build using "make mode=shared serial" becomes:
|
||||
traditional make build using ``make mode=shared serial`` becomes:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -231,29 +233,3 @@ If a required library is missing, you would get a 'not found' entry:
|
||||
libc.so.6 => /usr/lib64/libc.so.6 (0x00007fb7c7b5d000)
|
||||
/lib64/ld-linux-x86-64.so.2 (0x00007fb7c80a2000)
|
||||
|
||||
----------
|
||||
|
||||
**Calling the LAMMPS library**\ :
|
||||
|
||||
Either flavor of library (static or shared) allows one or more LAMMPS
|
||||
objects to be instantiated from the calling program. When used from a
|
||||
C++ program, most of the symbols and functions in LAMMPS are wrapped
|
||||
in a ``LAMMPS_NS`` namespace; you can safely use any of its classes and
|
||||
methods from within the calling code, as needed, and you will not incur
|
||||
conflicts with functions and variables in your code that share the name.
|
||||
This, however, does not extend to all additional libraries bundled with
|
||||
LAMMPS in the lib folder and some of the low-level code of some packages.
|
||||
|
||||
To be compatible with C, Fortran, Python programs, the library has a simple
|
||||
C-style interface, provided in ``src/library.cpp`` and ``src/library.h``.
|
||||
|
||||
See the :doc:`Python library <Python_library>` doc page for a
|
||||
description of the Python interface to LAMMPS, which wraps the C-style
|
||||
interface from a shared library through the `ctypes python module <ctypes_>`_.
|
||||
|
||||
See the sample codes in ``examples/COUPLE/simple`` for examples of C++ and
|
||||
C and Fortran codes that invoke LAMMPS through its library interface.
|
||||
Other examples in the COUPLE directory use coupling ideas discussed on
|
||||
the :doc:`Howto couple <Howto_couple>` doc page.
|
||||
|
||||
.. _ctypes: https://docs.python.org/3/library/ctypes.html
|
||||
|
||||
@ -45,7 +45,8 @@ packages:
|
||||
The mechanism for including packages is simple but different for CMake
|
||||
versus make.
|
||||
|
||||
**CMake build**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
.. code-block:: csh
|
||||
|
||||
@ -72,7 +73,8 @@ once with CMake.
|
||||
invoke cmake. CMake will give an error if that is not the case,
|
||||
indicating how you can un-install all packages in the src dir.
|
||||
|
||||
**Traditional make**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -108,7 +110,8 @@ once with make.
|
||||
within the same command. You can include or exclude multiple packages
|
||||
in a single make command, e.g. make yes-colloid no-manybody.
|
||||
|
||||
**CMake and make info**\ :
|
||||
CMake and make info
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Any package can be included or excluded in a LAMMPS build, independent
|
||||
of all other packages. However, some packages include files derived
|
||||
@ -132,7 +135,7 @@ src directory.
|
||||
|
||||
.. _cmake_presets:
|
||||
|
||||
**CMake shortcuts for installing many packages**\ :
|
||||
CMake presets for installing many packages
|
||||
|
||||
Instead of specifying all the CMake options via the command-line,
|
||||
CMake allows initializing its settings cache using script files.
|
||||
@ -148,13 +151,14 @@ one of them as a starting point and customize it to your needs.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
cmake -C ../cmake/presets/minimal.cmake [OPTIONS] ../cmake # enable just a few core packages
|
||||
cmake -C ../cmake/presets/most.cmake [OPTIONS] ../cmake # enable most packages
|
||||
cmake -C ../cmake/presets/nolib.cmake [OPTIONS] ../cmake # disable packages that do require extra libraries or tools
|
||||
cmake -C ../cmake/presets/clang.cmake [OPTIONS] ../cmake # change settings to use the Clang compilers by default
|
||||
cmake -C ../cmake/presets/intel.cmake [OPTIONS] ../cmake # change settings to use the Intel compilers by default
|
||||
cmake -C ../cmake/presets/all_on.cmake [OPTIONS] ../cmake # enable all packages
|
||||
cmake -C ../cmake/presets/all_off.cmake [OPTIONS] ../cmake # disable all packages
|
||||
cmake -C ../cmake/presets/minimal.cmake [OPTIONS] ../cmake # enable just a few core packages
|
||||
cmake -C ../cmake/presets/most.cmake [OPTIONS] ../cmake # enable most packages
|
||||
cmake -C ../cmake/presets/download.cmake [OPTIONS] ../cmake # enable packages which download sources or potential files
|
||||
cmake -C ../cmake/presets/nolib.cmake [OPTIONS] ../cmake # disable packages that do require extra libraries or tools
|
||||
cmake -C ../cmake/presets/clang.cmake [OPTIONS] ../cmake # change settings to use the Clang compilers by default
|
||||
cmake -C ../cmake/presets/intel.cmake [OPTIONS] ../cmake # change settings to use the Intel compilers by default
|
||||
cmake -C ../cmake/presets/all_on.cmake [OPTIONS] ../cmake # enable all packages
|
||||
cmake -C ../cmake/presets/all_off.cmake [OPTIONS] ../cmake # disable all packages
|
||||
mingw64-cmake -C ../cmake/presets/mingw-cross.cmake [OPTIONS] ../cmake # compile with MinGW cross compilers
|
||||
|
||||
.. note::
|
||||
@ -184,7 +188,8 @@ one of them as a starting point and customize it to your needs.
|
||||
|
||||
----------
|
||||
|
||||
**Make shortcuts for installing many packages**\ :
|
||||
Make shortcuts for installing many packages
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The following commands are useful for managing package source files
|
||||
and their installation when building LAMMPS via traditional make.
|
||||
|
||||
@ -44,7 +44,8 @@ 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.
|
||||
|
||||
**CMake variables**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -74,7 +75,12 @@ to assist:
|
||||
-D FFT_MKL_THREADS=on # enable using threaded FFTs with MKL libraries
|
||||
-D MKL_LIBRARIES=path
|
||||
|
||||
**Makefile.machine settings**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
To change the FFT library to be used and its options, you have to edit
|
||||
your machine Makefile. Below are examples how the makefile variables
|
||||
could be changed.
|
||||
|
||||
.. code-block:: make
|
||||
|
||||
@ -104,7 +110,8 @@ As with CMake, you do not need to set paths in ``FFT_INC`` or ``FFT_PATH``, if
|
||||
the compiler can find the FFT header and library files in its default search path.
|
||||
You must specify ``FFT_LIB`` with the appropriate FFT libraries to include in the link.
|
||||
|
||||
**CMake and make info**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
The `KISS FFT library <http://kissfft.sf.net>`_ is included in the LAMMPS
|
||||
distribution. It is portable across all platforms. Depending on the size
|
||||
@ -127,7 +134,7 @@ download it from `www.fftw.org <http://www.fftw.org>`_. LAMMPS requires
|
||||
version 3.X; the legacy version 2.1.X is no longer supported.
|
||||
|
||||
Building FFTW for your box should be as simple as ``./configure; make;
|
||||
make install``\ . The install command typically requires root privileges
|
||||
make install``. The install command typically requires root privileges
|
||||
(e.g. invoke it via sudo), unless you specify a local directory with
|
||||
the "--prefix" option of configure. Type ``./configure --help`` to see
|
||||
various options.
|
||||
@ -169,20 +176,25 @@ ARRAY mode.
|
||||
|
||||
.. _size:
|
||||
|
||||
Size of LAMMPS data types
|
||||
Size of LAMMPS integer types
|
||||
------------------------------------
|
||||
|
||||
LAMMPS has a few integer data types which can be defined as 4-byte or
|
||||
8-byte integers. The default setting of "smallbig" is almost always
|
||||
adequate.
|
||||
LAMMPS has a few integer data types which can be defined as either
|
||||
4-byte (= 32-bit) or 8-byte (= 64-bit) integers at compile time.
|
||||
The default setting of "smallbig" is almost always adequate.
|
||||
|
||||
**CMake variable**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
-D LAMMPS_SIZES=value # smallbig (default) or bigbig or smallsmall
|
||||
|
||||
**Makefile.machine setting**\ :
|
||||
Traditional build
|
||||
^^^^^^^^^^^^^^^^^
|
||||
|
||||
If you want a setting different from the default, you need to edit your
|
||||
machine Makefile.
|
||||
|
||||
.. code-block:: make
|
||||
|
||||
@ -190,7 +202,8 @@ adequate.
|
||||
|
||||
The default setting is ``-DLAMMPS_SMALLBIG`` if nothing is specified
|
||||
|
||||
**CMake and make info**\ :
|
||||
CMake and make info
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The default "smallbig" setting allows for simulations with:
|
||||
|
||||
@ -251,7 +264,8 @@ PNG image files. Likewise the :doc:`dump movie <dump_image>` command
|
||||
outputs movie files in MPEG format. Using these options requires the
|
||||
following settings:
|
||||
|
||||
**CMake variables**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -276,7 +290,8 @@ variables:
|
||||
-D ZLIB_LIBRARIES=path # path to libz.a (.so) file
|
||||
-D FFMPEG_EXECUTABLE=path # path to ffmpeg executable
|
||||
|
||||
**Makefile.machine settings**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
.. code-block:: make
|
||||
|
||||
@ -295,7 +310,8 @@ with a list of graphics libraries to include in the link. You must
|
||||
insure ffmpeg is in a directory where LAMMPS can find it at runtime,
|
||||
that is a directory in your PATH environment variable.
|
||||
|
||||
**CMake and make info**\ :
|
||||
CMake and make info
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Using ``ffmpeg`` to output movie files requires that your machine
|
||||
supports the "popen" function in the standard runtime library.
|
||||
@ -318,7 +334,8 @@ If this option is enabled, large files can be read or written with
|
||||
gzip compression by several LAMMPS commands, including
|
||||
:doc:`read_data <read_data>`, :doc:`rerun <rerun>`, and :doc:`dump <dump>`.
|
||||
|
||||
**CMake variables**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -326,13 +343,15 @@ gzip compression by several LAMMPS commands, including
|
||||
# default is yes if CMake can find gzip, else no
|
||||
-D GZIP_EXECUTABLE=path # path to gzip executable if CMake cannot find it
|
||||
|
||||
**Makefile.machine setting**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
.. code-block:: make
|
||||
|
||||
LMP_INC = -DLAMMPS_GZIP
|
||||
|
||||
**CMake and make info**\ :
|
||||
CMake and make info
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This option requires that your machine supports the "popen()" function
|
||||
in the standard runtime library and that a gzip executable can be
|
||||
@ -363,7 +382,8 @@ pointers that are aligned to 16-byte boundaries. Using SSE vector
|
||||
instructions efficiently, however, requires memory blocks being
|
||||
aligned on 64-byte boundaries.
|
||||
|
||||
**CMake variable**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -374,7 +394,8 @@ and revert to using the malloc() C-library function instead. When
|
||||
compiling LAMMPS for Windows systems, malloc() will always be used
|
||||
and this setting ignored.
|
||||
|
||||
**Makefile.machine setting**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
.. code-block:: make
|
||||
|
||||
@ -398,13 +419,15 @@ types, the following setting will be needed. It converts "long long"
|
||||
to a "long" data type, which should be the desired 8-byte integer on
|
||||
those systems:
|
||||
|
||||
**CMake variable**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
-D LAMMPS_LONGLONG_TO_LONG=value # yes or no (default)
|
||||
|
||||
**Makefile.machine setting**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
.. code-block:: make
|
||||
|
||||
@ -420,17 +443,26 @@ Exception handling when using LAMMPS as a library
|
||||
This setting is useful when external codes drive LAMMPS as a library.
|
||||
With this option enabled, LAMMPS errors do not kill the calling code.
|
||||
Instead, the call stack is unwound and control returns to the caller,
|
||||
e.g. to Python. Of course the calling code has to be set up to
|
||||
*catch* exceptions from within LAMMPS.
|
||||
e.g. to Python. Of course, the calling code has to be set up to
|
||||
*catch* exceptions thrown from within LAMMPS.
|
||||
|
||||
**CMake variable**\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
-D LAMMPS_EXCEPTIONS=value # yes or no (default)
|
||||
|
||||
**Makefile.machine setting**\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
.. code-block:: make
|
||||
|
||||
LMP_INC = -DLAMMPS_EXCEPTIONS
|
||||
|
||||
.. note::
|
||||
|
||||
When LAMMPS is running in parallel, it is not always possible to
|
||||
cleanly recover from an exception since not all parallel ranks may
|
||||
throw an exception and thus other MPI ranks may get stuck waiting for
|
||||
messages from the ones with errors.
|
||||
|
||||
@ -31,9 +31,9 @@ does something different than this sequence:
|
||||
run 100
|
||||
|
||||
In the first case, the specified timestep (0.5 fs) is used for two
|
||||
simulations of 100 timesteps each. In the 2nd case, the default
|
||||
timestep (1.0 fs) is used for the 1st 100 step simulation and a 0.5 fs
|
||||
timestep is used for the 2nd one.
|
||||
simulations of 100 timesteps each. In the second case, the default
|
||||
timestep (1.0 fs) is used for the first 100 step simulation and a 0.5 fs
|
||||
timestep is used for the second one.
|
||||
|
||||
(2) Some commands are only valid when they follow other commands. For
|
||||
example you cannot set the temperature of a group of atoms until atoms
|
||||
|
||||
@ -78,7 +78,7 @@ OPT.
|
||||
* :doc:`coul/long/soft (o) <pair_fep_soft>`
|
||||
* :doc:`coul/msm (o) <pair_coul>`
|
||||
* :doc:`coul/slater/cut <pair_coul_slater>`
|
||||
* :doc:`coul/slater/long <pair_coul_slater>`
|
||||
* :doc:`coul/slater/long <pair_coul_slater>`
|
||||
* :doc:`coul/shield <pair_coul_shield>`
|
||||
* :doc:`coul/streitz <pair_coul>`
|
||||
* :doc:`coul/wolf (ko) <pair_coul>`
|
||||
|
||||
@ -142,7 +142,7 @@ follows:
|
||||
minimize.
|
||||
|
||||
\item The Special class walks the bond topology of a molecular system
|
||||
to find 1st, 2nd, 3rd neighbors of each atom. It is invoked by
|
||||
to find first, second, third neighbors of each atom. It is invoked by
|
||||
several commands, like read\_data, read\_restart, and replicate.
|
||||
|
||||
\item The Atom class stores all per-atom arrays. More precisely, they
|
||||
|
||||
@ -23,7 +23,7 @@ We use it to show how to identify the origin of a segmentation fault.
|
||||
double *special_lj = force->special_lj;
|
||||
int newton_pair = force->newton_pair;
|
||||
+ double comx = 0.0;
|
||||
|
||||
|
||||
inum = list->inum;
|
||||
ilist = list->ilist;
|
||||
@@ -134,8 +135,10 @@ void PairLJCut::compute(int eflag, int vflag)
|
||||
@ -31,7 +31,7 @@ We use it to show how to identify the origin of a segmentation fault.
|
||||
}
|
||||
}
|
||||
- }
|
||||
|
||||
|
||||
+ comx += atom->rmass[i]*x[i][0]; /* BUG */
|
||||
+ }
|
||||
+ printf("comx = %g\n",comx);
|
||||
@ -42,7 +42,7 @@ After recompiling LAMMPS and running the input you should get something like thi
|
||||
|
||||
.. code-block:
|
||||
|
||||
$ ./lmp -in in.melt
|
||||
$ ./lmp -in in.melt
|
||||
LAMMPS (19 Mar 2020)
|
||||
OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (src/comm.cpp:94)
|
||||
using 1 OpenMP thread(s) per MPI task
|
||||
@ -98,11 +98,11 @@ drop back to the GDB prompt.
|
||||
Unit style : lj
|
||||
Current step : 0
|
||||
Time step : 0.005
|
||||
|
||||
|
||||
Program received signal SIGSEGV, Segmentation fault.
|
||||
0x00000000006653ab in LAMMPS_NS::PairLJCut::compute (this=0x829740, eflag=1, vflag=<optimized out>) at /home/akohlmey/compile/lammps/src/pair_lj_cut.cpp:139
|
||||
139 comx += atom->rmass[i]*x[i][0]; /* BUG */
|
||||
(gdb)
|
||||
(gdb)
|
||||
|
||||
Now typing the command "where" will show the stack of functions starting from
|
||||
the current function back to "main()".
|
||||
@ -119,7 +119,7 @@ the current function back to "main()".
|
||||
#4 0x0000000000410ad3 in LAMMPS_NS::Input::execute_command (this=0x7d1410) at /home/akohlmey/compile/lammps/src/input.cpp:864
|
||||
#5 0x00000000004111fb in LAMMPS_NS::Input::file (this=0x7d1410) at /home/akohlmey/compile/lammps/src/input.cpp:229
|
||||
#6 0x000000000040933a in main (argc=<optimized out>, argv=<optimized out>) at /home/akohlmey/compile/lammps/src/main.cpp:65
|
||||
(gdb)
|
||||
(gdb)
|
||||
|
||||
You can also print the value of variables and see if there is anything
|
||||
unexpected. Segmentation faults, for example, commonly happen when a
|
||||
@ -189,12 +189,12 @@ the console are not mixed.
|
||||
|
||||
.. code-block::
|
||||
|
||||
$ valgrind ./lmp -in in.melt
|
||||
$ valgrind ./lmp -in in.melt
|
||||
==1933642== Memcheck, a memory error detector
|
||||
==1933642== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
|
||||
==1933642== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
|
||||
==1933642== Command: ./lmp -in in.melt
|
||||
==1933642==
|
||||
==1933642==
|
||||
LAMMPS (19 Mar 2020)
|
||||
OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (src/comm.cpp:94)
|
||||
using 1 OpenMP thread(s) per MPI task
|
||||
@ -228,7 +228,7 @@ the console are not mixed.
|
||||
==1933642== by 0x4111FA: LAMMPS_NS::Input::file() (input.cpp:229)
|
||||
==1933642== by 0x409339: main (main.cpp:65)
|
||||
==1933642== Address 0x0 is not stack'd, malloc'd or (recently) free'd
|
||||
==1933642==
|
||||
==1933642==
|
||||
|
||||
As you can see, the stack trace information is similar to that obtained
|
||||
from GDB. In addition you get a more specific hint about what cause the
|
||||
|
||||
@ -381,7 +381,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
|
||||
are defined.
|
||||
|
||||
*Bond atom missing in box size check*
|
||||
The 2nd atoms needed to compute a particular bond is missing on this
|
||||
The second atom needed to compute a particular bond is missing on this
|
||||
processor. Typically this is because the pairwise cutoff is set too
|
||||
short or the bond has blown apart and an atom is too far away.
|
||||
|
||||
@ -391,7 +391,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
|
||||
the atoms are too far apart to make a valid bond.
|
||||
|
||||
*Bond atom missing in image check*
|
||||
The 2nd atom in a particular bond is missing on this processor.
|
||||
The second atom in a particular bond is missing on this processor.
|
||||
Typically this is because the pairwise cutoff is set too short or the
|
||||
bond has blown apart and an atom is too far away.
|
||||
|
||||
@ -401,12 +401,12 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
|
||||
are too far apart to make a valid bond.
|
||||
|
||||
*Bond atoms %d %d missing on proc %d at step %ld*
|
||||
The 2nd atom needed to compute a particular bond is missing on this
|
||||
The second atom needed to compute a particular bond is missing on this
|
||||
processor. Typically this is because the pairwise cutoff is set too
|
||||
short or the bond has blown apart and an atom is too far away.
|
||||
|
||||
*Bond atoms missing on proc %d at step %ld*
|
||||
The 2nd atom needed to compute a particular bond is missing on this
|
||||
The second atom needed to compute a particular bond is missing on this
|
||||
processor. Typically this is because the pairwise cutoff is set too
|
||||
short or the bond has blown apart and an atom is too far away.
|
||||
|
||||
@ -1374,7 +1374,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
|
||||
template does not qualify.
|
||||
|
||||
*Cannot use fix box/relax on a 2nd non-periodic dimension*
|
||||
When specifying an off-diagonal pressure component, the 2nd of the two
|
||||
When specifying an off-diagonal pressure component, the second of the two
|
||||
dimensions must be periodic. E.g. if the xy component is specified,
|
||||
then the y dimension must be periodic.
|
||||
|
||||
@ -1388,7 +1388,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
|
||||
also keyword tri or xy, this is wrong.
|
||||
|
||||
*Cannot use fix box/relax with tilt factor scaling on a 2nd non-periodic dimension*
|
||||
When specifying scaling on a tilt factor component, the 2nd of the two
|
||||
When specifying scaling on a tilt factor component, the second of the two
|
||||
dimensions must be periodic. E.g. if the xy component is specified,
|
||||
then the y dimension must be periodic.
|
||||
|
||||
@ -1429,7 +1429,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
|
||||
This would be changing the same box dimension twice.
|
||||
|
||||
*Cannot use fix nvt/npt/nph on a 2nd non-periodic dimension*
|
||||
When specifying an off-diagonal pressure component, the 2nd of the two
|
||||
When specifying an off-diagonal pressure component, the second of the two
|
||||
dimensions must be periodic. E.g. if the xy component is specified,
|
||||
then the y dimension must be periodic.
|
||||
|
||||
@ -1447,13 +1447,13 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
|
||||
Self-explanatory.
|
||||
|
||||
*Cannot use fix nvt/npt/nph with xy scaling when y is non-periodic dimension*
|
||||
The 2nd dimension in the barostatted tilt factor must be periodic.
|
||||
The second dimension in the barostatted tilt factor must be periodic.
|
||||
|
||||
*Cannot use fix nvt/npt/nph with xz scaling when z is non-periodic dimension*
|
||||
The 2nd dimension in the barostatted tilt factor must be periodic.
|
||||
The second dimension in the barostatted tilt factor must be periodic.
|
||||
|
||||
*Cannot use fix nvt/npt/nph with yz scaling when z is non-periodic dimension*
|
||||
The 2nd dimension in the barostatted tilt factor must be periodic.
|
||||
The second dimension in the barostatted tilt factor must be periodic.
|
||||
|
||||
*Cannot use fix pour rigid and not molecule*
|
||||
Self-explanatory.
|
||||
@ -7192,7 +7192,7 @@ keyword to allow for additional bonds to be formed
|
||||
does not exist.
|
||||
|
||||
*Replacing a fix, but new style != old style*
|
||||
A fix ID can be used a 2nd time, but only if the style matches the
|
||||
A fix ID can be used a second time, but only if the style matches the
|
||||
previous fix. In this case it is assumed you with to reset a fix's
|
||||
parameters. This error may mean you are mistakenly re-using a fix ID
|
||||
when you do not intend to.
|
||||
|
||||
@ -43,17 +43,17 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
|
||||
Self-explanatory.
|
||||
|
||||
*Bond atom missing in box size check*
|
||||
The 2nd atoms needed to compute a particular bond is missing on this
|
||||
The second atom needed to compute a particular bond is missing on this
|
||||
processor. Typically this is because the pairwise cutoff is set too
|
||||
short or the bond has blown apart and an atom is too far away.
|
||||
|
||||
*Bond atom missing in image check*
|
||||
The 2nd atom in a particular bond is missing on this processor.
|
||||
The second atom in a particular bond is missing on this processor.
|
||||
Typically this is because the pairwise cutoff is set too short or the
|
||||
bond has blown apart and an atom is too far away.
|
||||
|
||||
*Bond atoms missing at step %ld*
|
||||
The 2nd atom needed to compute a particular bond is missing on this
|
||||
The second atom needed to compute a particular bond is missing on this
|
||||
processor. Typically this is because the pairwise cutoff is set too
|
||||
short or the bond has blown apart and an atom is too far away.
|
||||
|
||||
@ -486,7 +486,7 @@ This will most likely cause errors in kinetic fluctuations.
|
||||
a new style.
|
||||
|
||||
*No Kspace calculation with verlet/split*
|
||||
The 2nd partition performs a kspace calculation so the kspace_style
|
||||
The second partition performs a kspace calculation so the kspace_style
|
||||
command must be used.
|
||||
|
||||
*No automatic unit conversion to XTC file format conventions possible for units lj*
|
||||
|
||||
@ -163,7 +163,7 @@ Here is how you can run and visualize one of the sample problems:
|
||||
|
||||
Running the simulation produces the files *dump.indent* and
|
||||
*log.lammps*\ . You can visualize the dump file of snapshots with a
|
||||
variety of 3rd-party tools highlighted on the
|
||||
variety of third-party tools highlighted on the
|
||||
`Visualization <https://lammps.sandia.gov/viz.html>`_ page of the LAMMPS
|
||||
web site.
|
||||
|
||||
|
||||
@ -197,7 +197,7 @@ compress individual polymer chains (molecules) in a mixture, is
|
||||
explained on the :doc:`compute chunk/spread/atom <compute_chunk_spread_atom>` command doc page.
|
||||
|
||||
(7) An example for using one set of per-chunk values for molecule
|
||||
chunks, to create a 2nd set of micelle-scale chunks (clustered
|
||||
chunks, to create a second set of micelle-scale chunks (clustered
|
||||
molecules, due to hydrophobicity), is explained on the :doc:`compute chunk/reduce <compute_reduce_chunk>` command doc page.
|
||||
|
||||
(8) An example for using one set of per-chunk values (dipole moment
|
||||
|
||||
@ -114,19 +114,19 @@ summary screen will look like this:
|
||||
-- Detecting CXX compiler ABI info - done
|
||||
-- Detecting CXX compile features
|
||||
-- Detecting CXX compile features - done
|
||||
-- Found Git: /usr/bin/git (found version "2.25.2")
|
||||
-- Found Git: /usr/bin/git (found version "2.25.2")
|
||||
-- Running check for auto-generated files from make-based build system
|
||||
-- Found MPI_CXX: /usr/lib64/mpich/lib/libmpicxx.so (found version "3.1")
|
||||
-- Found MPI: TRUE (found version "3.1")
|
||||
-- Found MPI_CXX: /usr/lib64/mpich/lib/libmpicxx.so (found version "3.1")
|
||||
-- Found MPI: TRUE (found version "3.1")
|
||||
-- Looking for C++ include omp.h
|
||||
-- Looking for C++ include omp.h - found
|
||||
-- Found OpenMP_CXX: -fopenmp (found version "4.5")
|
||||
-- Found OpenMP: TRUE (found version "4.5")
|
||||
-- Found JPEG: /usr/lib64/libjpeg.so (found version "62")
|
||||
-- Found PNG: /usr/lib64/libpng.so (found version "1.6.37")
|
||||
-- Found ZLIB: /usr/lib64/libz.so (found version "1.2.11")
|
||||
-- Found GZIP: /usr/bin/gzip
|
||||
-- Found FFMPEG: /usr/bin/ffmpeg
|
||||
-- Found OpenMP_CXX: -fopenmp (found version "4.5")
|
||||
-- Found OpenMP: TRUE (found version "4.5")
|
||||
-- Found JPEG: /usr/lib64/libjpeg.so (found version "62")
|
||||
-- Found PNG: /usr/lib64/libpng.so (found version "1.6.37")
|
||||
-- Found ZLIB: /usr/lib64/libz.so (found version "1.2.11")
|
||||
-- Found GZIP: /usr/bin/gzip
|
||||
-- Found FFMPEG: /usr/bin/ffmpeg
|
||||
-- Performing Test COMPILER_SUPPORTS-ffast-math
|
||||
-- Performing Test COMPILER_SUPPORTS-ffast-math - Success
|
||||
-- Performing Test COMPILER_SUPPORTS-march=native
|
||||
@ -143,7 +143,7 @@ summary screen will look like this:
|
||||
* JPEG
|
||||
* PNG
|
||||
* ZLIB
|
||||
|
||||
|
||||
-- <<< Build configuration >>>
|
||||
Build type: RelWithDebInfo
|
||||
Install path: /home/akohlmey/.local
|
||||
@ -157,7 +157,7 @@ summary screen will look like this:
|
||||
Options: -ffast-math;-march=native
|
||||
-- <<< Linker flags: >>>
|
||||
-- Executable name: lmp
|
||||
-- Static library flags:
|
||||
-- Static library flags:
|
||||
-- <<< MPI flags >>>
|
||||
-- MPI includes: /usr/include/mpich-x86_64
|
||||
-- MPI libraries: /usr/lib64/mpich/lib/libmpicxx.so;/usr/lib64/mpich/lib/libmpi.so;
|
||||
@ -291,7 +291,7 @@ Some common CMake variables
|
||||
|
||||
.. list-table::
|
||||
:header-rows: 1
|
||||
|
||||
|
||||
* - Variable
|
||||
- Description
|
||||
* - ``CMAKE_INSTALL_PREFIX``
|
||||
@ -313,13 +313,13 @@ Some common CMake variables
|
||||
- Fortran compiler to be used for compilation (default: system specific, ``gfortran`` on Linux)
|
||||
* - ``CXX_COMPILER_LAUNCHER``
|
||||
- tool to launch the C++ compiler, e.g. ``ccache`` or ``distcc`` for faster compilation (default: empty)
|
||||
|
||||
|
||||
Some common LAMMPS specific variables
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. list-table::
|
||||
:header-rows: 1
|
||||
|
||||
|
||||
* - Variable
|
||||
- Description
|
||||
* - ``BUILD_MPI``
|
||||
@ -438,7 +438,7 @@ the target name to the command. Example: ``cmake --build . --target all`` or
|
||||
* - ``clean``
|
||||
- remove all generated files
|
||||
|
||||
|
||||
|
||||
Choosing generators
|
||||
-------------------
|
||||
|
||||
|
||||
@ -119,7 +119,7 @@ non-polarized ions (ions without an attached satellite particle). The
|
||||
groups, one for the core atoms, another for the shell atoms.
|
||||
Non-polarized ions which might also be included in the treated system
|
||||
should not be included into either of these groups, they are taken
|
||||
into account by the *group-ID* (2nd argument) of the compute. The
|
||||
into account by the *group-ID* (second argument) of the compute. The
|
||||
groups can be defined using the :doc:`group *type*\ <group>` command.
|
||||
Note that to perform thermostatting using this definition of
|
||||
temperature, the :doc:`fix modify temp <fix_modify>` command should be
|
||||
|
||||
@ -91,4 +91,4 @@ With these modifications, the 8 simulations of each script would run
|
||||
on the 3 partitions one after the other until all were finished.
|
||||
Initially, 3 simulations would be started simultaneously, one on each
|
||||
partition. When one finished, that partition would then start
|
||||
the 4th simulation, and so forth, until all 8 were completed.
|
||||
the fourth simulation, and so forth, until all 8 were completed.
|
||||
|
||||
@ -28,7 +28,7 @@ scripts are based on. If that script had the line
|
||||
added to it, it would produce 2 binary restart files (tmp.restart.50
|
||||
and tmp.restart.100) as it ran.
|
||||
|
||||
This script could be used to read the 1st restart file and re-run the
|
||||
This script could be used to read the first restart file and re-run the
|
||||
last 50 timesteps:
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
@ -85,7 +85,7 @@ where *V* is the volume of the box, **X** is the original vector quantity and
|
||||
**x** is the vector in the LAMMPS basis.
|
||||
|
||||
There is no requirement that a triclinic box be periodic in any
|
||||
dimension, though it typically should be in at least the 2nd dimension
|
||||
dimension, though it typically should be in at least the second dimension
|
||||
of the tilt (y in xy) if you want to enforce a shift in periodic
|
||||
boundary conditions across that boundary. Some commands that work
|
||||
with triclinic boxes, e.g. the :doc:`fix deform <fix_deform>` and :doc:`fix npt <fix_nh>` commands, require periodicity or non-shrink-wrap
|
||||
@ -120,7 +120,7 @@ The 9 parameters, as well as lx,ly,lz, can be output via the
|
||||
To avoid extremely tilted boxes (which would be computationally
|
||||
inefficient), LAMMPS normally requires that no tilt factor can skew
|
||||
the box more than half the distance of the parallel box length, which
|
||||
is the 1st dimension in the tilt factor (x for xz). This is required
|
||||
is the first dimension in the tilt factor (x for xz). This is required
|
||||
both when the simulation box is created, e.g. via the
|
||||
:doc:`create_box <create_box>` or :doc:`read_data <read_data>` commands,
|
||||
as well as when the box shape changes dynamically during a simulation,
|
||||
@ -137,7 +137,7 @@ limit during a dynamics run (e.g. via the :doc:`fix deform <fix_deform>`
|
||||
command), then the box is "flipped" to an equivalent shape with a tilt
|
||||
factor within the bounds, so the run can continue. See the :doc:`fix deform <fix_deform>` doc page for further details.
|
||||
|
||||
One exception to this rule is if the 1st dimension in the tilt
|
||||
One exception to this rule is if the first dimension in the tilt
|
||||
factor (x for xy) is non-periodic. In that case, the limits on the
|
||||
tilt factor are not enforced, since flipping the box in that dimension
|
||||
does not change the atom positions due to non-periodicity. In this
|
||||
|
||||
@ -34,7 +34,7 @@ Here are suggestions on how to perform these tasks:
|
||||
molecular builder that will generate complex molecular models. See
|
||||
the :doc:`Tools <Tools>` doc page for details on tools packaged with
|
||||
LAMMPS. The `Pre/post processing page <http:/lammps.sandia.gov/prepost.html>`_ of the LAMMPS website
|
||||
describes a variety of 3rd party tools for this task. Furthermore,
|
||||
describes a variety of third party tools for this task. Furthermore,
|
||||
some LAMMPS internal commands allow to reconstruct, or selectively add
|
||||
topology information, as well as provide the option to insert molecule
|
||||
templates instead of atoms for building bulk molecular systems.
|
||||
|
||||
@ -32,11 +32,12 @@ a brief description of the basic code structure of LAMMPS.
|
||||
|
||||
----------
|
||||
|
||||
Once you are familiar with LAMMPS, you may want to bookmark :doc:`this page <Commands>` since it gives quick access to a doc page for
|
||||
Once you are familiar with LAMMPS, you may want to bookmark :doc:`this page <Commands_all>` since it gives quick access to a doc page for
|
||||
every LAMMPS command.
|
||||
|
||||
.. _lws: https://lammps.sandia.gov
|
||||
|
||||
.. _user_documentation:
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:numbered: 3
|
||||
|
||||
@ -1,60 +1,62 @@
|
||||
Building the LAMMPS manual
|
||||
**************************
|
||||
|
||||
Depending on how you obtained LAMMPS, the doc directory has up
|
||||
to 6 sub-directories, 2 Nroff files, and optionally 2 PDF files
|
||||
plus 2 e-book format files:
|
||||
Depending on how you obtained LAMMPS and whether you have built the
|
||||
manual yourself, this directory has a number of sub-directories and
|
||||
files. Here is a list with descriptions:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
src # content files for LAMMPS documentation
|
||||
html # HTML version of the LAMMPS manual (see html/Manual.html)
|
||||
utils # tools and settings for building the documentation
|
||||
docenv # virtualenv for processing the manual sources
|
||||
doctrees # temporary data from processing the manual
|
||||
mathjax # code and fonts for rendering math in html
|
||||
Manual.pdf # large PDF version of entire manual
|
||||
Developer.pdf # small PDF with info about how LAMMPS is structured
|
||||
LAMMPS.epub # Manual in ePUB e-book format
|
||||
LAMMPS.mobi # Manual in MOBI e-book format
|
||||
lammps.1 # man page for the lammps command
|
||||
msi2lmp.1 # man page for the msi2lmp command
|
||||
README # brief info about the documentation
|
||||
src # content files for LAMMPS documentation
|
||||
html # HTML version of the LAMMPS manual (see html/Manual.html)
|
||||
utils # tools and settings for building the documentation
|
||||
lammps.1 # man page for the lammps command
|
||||
msi2lmp.1 # man page for the msi2lmp command
|
||||
Manual.pdf # large PDF version of entire manual
|
||||
Developer.pdf # small PDF with info about how LAMMPS is structured
|
||||
LAMMPS.epub # Manual in ePUB e-book format
|
||||
LAMMPS.mobi # Manual in MOBI e-book format
|
||||
docenv # virtualenv folder for processing the manual sources
|
||||
doctrees # temporary data from processing the manual
|
||||
mathjax # code and fonts for rendering math in html
|
||||
doxygen # doxygen configuration and output
|
||||
.gitignore # list of files and folders to be ignored by git
|
||||
doxygen-warn.log # logfile with warnings from running doxygen
|
||||
github-development-workflow.md # notes on the LAMMPS development workflow
|
||||
include-file-conventions.md # notes on LAMMPS' include file conventions
|
||||
|
||||
If you downloaded LAMMPS as a tarball from the web site, the html folder
|
||||
and the PDF files should be included.
|
||||
If you downloaded LAMMPS as a tarball from `the LAMMPS website <lws_>`_,
|
||||
the html folder and the PDF files should be included.
|
||||
|
||||
If you downloaded LAMMPS from the public git repository, then the HTML
|
||||
and PDF files are not included. Instead you need to create them, in one
|
||||
of two ways:
|
||||
|
||||
a. You can "fetch" the current HTML and PDF files from the LAMMPS web
|
||||
site. Just type "make fetch". This should download a html_www
|
||||
site. Just type ``make fetch``. This should download a html_www
|
||||
directory and Manual_www.pdf/Developer_www.pdf files. Note that if
|
||||
new LAMMPS features have been added more recently than the date of
|
||||
your LAMMPS version, the fetched documentation will include those
|
||||
changes (but your source code will not, unless you update your local
|
||||
repository).
|
||||
|
||||
b. You can build the HTML or PDF files yourself, by typing "make html"
|
||||
or "make pdf". This requires various tools including Sphinx, git,
|
||||
and the MathJax javascript library, which the build process will attempt
|
||||
to download automatically into a virtual environment in the folder
|
||||
doc/docenv and the folder mathjax, respectively, if not already available.
|
||||
This download is required only once, unless you type "make clean-all".
|
||||
After that, viewing and processing of the documentation can be done
|
||||
without internet access. To generate the PDF version of the manual,
|
||||
the PDFLaTeX software and several LaTeX packages are required as well.
|
||||
However, those cannot be installed automatically at the moment.
|
||||
b. You can build the HTML or PDF files yourself, by typing ``make html``
|
||||
or ``make pdf``. This requires various tools and files. Some of them
|
||||
have to be installed (more on that below). For the rest the build
|
||||
process will attempt to download and install them into a python
|
||||
virtual environment and local folders. This download is required
|
||||
only once, unless you type ``make clean-all``. After that, viewing and
|
||||
processing of the documentation can be done without internet access.
|
||||
|
||||
----------
|
||||
|
||||
The generation of all documentation is managed by the Makefile in
|
||||
the doc directory.
|
||||
The generation of all documentation is managed by the Makefile in the
|
||||
doc directory. The following documentation related make commands are
|
||||
available:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
Documentation Build Options:
|
||||
|
||||
make html # generate HTML in html dir using Sphinx
|
||||
make pdf # generate 2 PDF files (Manual.pdf,Developer.pdf)
|
||||
# in doc dir via htmldoc and pdflatex
|
||||
@ -62,8 +64,10 @@ the doc directory.
|
||||
# as a tarball and unpack into html dir and 2 PDFs
|
||||
make epub # generate LAMMPS.epub in ePUB format using Sphinx
|
||||
make mobi # generate LAMMPS.mobi in MOBI format using ebook-convert
|
||||
|
||||
make clean # remove intermediate RST files created by HTML build
|
||||
make clean-all # remove entire build folder and any cached data
|
||||
|
||||
make anchor_check # check for duplicate anchor labels
|
||||
make style_check # check for complete and consistent style lists
|
||||
make package_check # check for complete and consistent package lists
|
||||
@ -74,29 +78,30 @@ the doc directory.
|
||||
Installing prerequisites for HTML build
|
||||
=======================================
|
||||
|
||||
To run the HTML documentation build toolchain, Python 3 and virtualenv
|
||||
have to be installed. Here are instructions for common setups:
|
||||
To run the HTML documentation build toolchain, python 3, git, doxygen,
|
||||
and virtualenv have to be installed locally. Here are instructions for
|
||||
common setups:
|
||||
|
||||
Ubuntu
|
||||
------
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo apt-get install python-virtualenv
|
||||
sudo apt-get install python-virtualenv git doxygen
|
||||
|
||||
Fedora (up to version 21) and Red Hat Enterprise Linux or CentOS (up to version 7.x)
|
||||
------------------------------------------------------------------------------------
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo yum install python3-virtualenv
|
||||
sudo yum install python3-virtualenv git doxygen
|
||||
|
||||
Fedora (since version 22)
|
||||
-------------------------
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo dnf install python3-virtualenv
|
||||
sudo dnf install python3-virtualenv git doxygen
|
||||
|
||||
MacOS X
|
||||
-------
|
||||
@ -120,22 +125,92 @@ Once Python 3 is installed, open a Terminal and type
|
||||
|
||||
This will install virtualenv from the Python Package Index.
|
||||
|
||||
----------
|
||||
Installing prerequisites for PDF build
|
||||
======================================
|
||||
|
||||
Installing prerequisites for epub build
|
||||
=======================================
|
||||
In addition to the tools needed for building the HTML format manual,
|
||||
a working LaTeX installation with support for PDFLaTeX and a selection
|
||||
of LaTeX styles/packages are required.
|
||||
|
||||
ePUB
|
||||
----
|
||||
Installing prerequisites for e-book reader builds
|
||||
=================================================
|
||||
|
||||
Same as for HTML. This uses mostly the same tools and configuration
|
||||
files as the HTML tree. In addition it uses LaTeX to convert embedded
|
||||
In addition to the tools needed for building the HTML format manual,
|
||||
a working LaTeX installation with a few add-on LaTeX packages
|
||||
as well as the ``dvipng`` tool are required to convert embedded
|
||||
math expressions transparently into embedded images.
|
||||
|
||||
For converting the generated ePUB file to a MOBI format file
|
||||
(for e-book readers, like Kindle, that cannot read ePUB), you
|
||||
also need to have the 'ebook-convert' tool from the "calibre"
|
||||
software installed. `http://calibre-ebook.com/ <http://calibre-ebook.com/>`_
|
||||
You first create the ePUB file and then convert it with 'make mobi'
|
||||
On the Kindle readers in particular, you also have support for
|
||||
PDF files, so you could download and view the PDF version as an alternative.
|
||||
For converting the generated ePUB file to a MOBI format file (for e-book
|
||||
readers, like Kindle, that cannot read ePUB), you also need to have the
|
||||
``ebook-convert`` tool from the "calibre" software
|
||||
installed. `http://calibre-ebook.com/ <http://calibre-ebook.com/>`_
|
||||
Typing ``make mobi`` will first create the ePUB file and then convert
|
||||
it. On the Kindle readers in particular, you also have support for PDF
|
||||
files, so you could download and view the PDF version as an alternative.
|
||||
|
||||
|
||||
Instructions for Developers
|
||||
===========================
|
||||
|
||||
When adding new styles or options to the LAMMPS code, corresponding
|
||||
documentation is required and either existing files in the ``src``
|
||||
folder need to be updated or new files added. These files are written
|
||||
in `reStructuredText <rst_>`_ markup for translation with the Sphinx tool.
|
||||
|
||||
Before contributing any documentation, please check that both the HTML
|
||||
and the PDF format documentation can translate without errors. Please also
|
||||
check the output to the console for any warnings or problems. There will
|
||||
be multiple tests run automatically:
|
||||
|
||||
- A test for correctness of all anchor labels and their references
|
||||
|
||||
- A test that all LAMMPS packages (= folders with sources in
|
||||
``lammps/src``) are documented and listed. A typical warning shows
|
||||
the name of the folder with the suspected new package code and the
|
||||
documentation files where they need to be listed:
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
Found 33 standard and 41 user packages
|
||||
Standard package NEWPACKAGE missing in Packages_standard.rst
|
||||
Standard package NEWPACKAGE missing in Packages_details.rst
|
||||
|
||||
- A test that only standard, printable ASCII text characters are used.
|
||||
This runs the command ``env LC_ALL=C grep -n '[^ -~]' src/*.rst`` and
|
||||
thus prints all offending lines with filename and line number
|
||||
prepended to the screen. Special characters like the Angstrom
|
||||
:math:`\mathrm{\mathring{A}}` should be typeset with embedded math
|
||||
(like this ``:math:`\mathrm{\mathring{A}}```\ ).
|
||||
|
||||
- A test whether all styles are documented and listed in their
|
||||
respective overview pages. A typical output with warnings looks like this:
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
Parsed style names w/o suffixes from C++ tree in ../src:
|
||||
Angle styles: 21 Atom styles: 24
|
||||
Body styles: 3 Bond styles: 17
|
||||
Command styles: 41 Compute styles: 143
|
||||
Dihedral styles: 16 Dump styles: 26
|
||||
Fix styles: 223 Improper styles: 13
|
||||
Integrate styles: 4 Kspace styles: 15
|
||||
Minimize styles: 9 Pair styles: 234
|
||||
Reader styles: 4 Region styles: 8
|
||||
Compute style entry newcomp is missing or incomplete in Commands_compute.rst
|
||||
Compute style entry newcomp is missing or incomplete in compute.rst
|
||||
Fix style entry newfix is missing or incomplete in Commands_fix.rst
|
||||
Fix style entry newfix is missing or incomplete in fix.rst
|
||||
Pair style entry new is missing or incomplete in Commands_pair.rst
|
||||
Pair style entry new is missing or incomplete in pair_style.rst
|
||||
Found 6 issue(s) with style lists
|
||||
|
||||
|
||||
In addition, there is the option to run a spellcheck on the entire
|
||||
manual with ``make spelling``. This requires `a library called enchant
|
||||
<https://github.com/AbiWord/enchant>`_. To avoid printing out *false
|
||||
positives* (e.g. keywords, names, abbreviations) those can be added to
|
||||
the file ``lammps/doc/utils/sphinx-config/false_positives.txt``.
|
||||
|
||||
.. _rst: https://docutils.readthedocs.io/en/sphinx-docs/user/rst/quickstart.html
|
||||
|
||||
.. _lws: https://lammps.sandia.gov
|
||||
|
||||
@ -27,7 +27,7 @@ derived class. See fix.h for details.
|
||||
+---------------------------+--------------------------------------------------------------------------------------------+
|
||||
| setup_pre_force | called before force computation in setup (optional) |
|
||||
+---------------------------+--------------------------------------------------------------------------------------------+
|
||||
| setup | called immediately before the 1st timestep and after forces are computed (optional) |
|
||||
| setup | called immediately before the first timestep and after forces are computed (optional) |
|
||||
+---------------------------+--------------------------------------------------------------------------------------------+
|
||||
| min_setup_pre_force | like setup_pre_force, but for minimizations instead of MD runs (optional) |
|
||||
+---------------------------+--------------------------------------------------------------------------------------------+
|
||||
|
||||
@ -10,12 +10,12 @@ Ewald.cpp is an example of computing K-space interactions.
|
||||
Here is a brief description of methods you define in your new derived
|
||||
class. See kspace.h for details.
|
||||
|
||||
+---------------+----------------------------------------------+
|
||||
| init | initialize the calculation before a run |
|
||||
+---------------+----------------------------------------------+
|
||||
| setup | computation before the 1st timestep of a run |
|
||||
+---------------+----------------------------------------------+
|
||||
| compute | every-timestep computation |
|
||||
+---------------+----------------------------------------------+
|
||||
| memory_usage | tally of memory usage |
|
||||
+---------------+----------------------------------------------+
|
||||
+---------------+------------------------------------------------+
|
||||
| init | initialize the calculation before a run |
|
||||
+---------------+------------------------------------------------+
|
||||
| setup | computation before the first timestep of a run |
|
||||
+---------------+------------------------------------------------+
|
||||
| compute | every-timestep computation |
|
||||
+---------------+------------------------------------------------+
|
||||
| memory_usage | tally of memory usage |
|
||||
+---------------+------------------------------------------------+
|
||||
|
||||
@ -490,7 +490,7 @@ interactions. These include Ewald, particle-particle particle-mesh
|
||||
|
||||
Building with this package requires a 1d FFT library be present on
|
||||
your system for use by the PPPM solvers. This can be the KISS FFT
|
||||
library provided with LAMMPS, 3rd party libraries like FFTW, or a
|
||||
library provided with LAMMPS, third party libraries like FFTW, or a
|
||||
vendor-supplied FFT library. See the :doc:`Build settings <Build_settings>` doc page for details on how to select
|
||||
different FFT options for your LAMPMS build.
|
||||
|
||||
|
||||
@ -254,12 +254,3 @@ following steps:
|
||||
* You should now be able to invoke the new interface function from a
|
||||
Python script.
|
||||
|
||||
----------
|
||||
|
||||
.. autoclass:: lammps.lammps
|
||||
:members:
|
||||
:no-undoc-members:
|
||||
|
||||
.. autoclass:: lammps.NeighList
|
||||
:members:
|
||||
:no-undoc-members:
|
||||
|
||||
@ -10,7 +10,7 @@ and type:
|
||||
>>> lmp = lammps()
|
||||
|
||||
If you get no errors, you're ready to use LAMMPS from Python. If the
|
||||
2nd command fails, the most common error to see is
|
||||
second command fails, the most common error to see is
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
|
||||
@ -324,17 +324,17 @@ physical processors is done by MPI before LAMMPS begins. It may be
|
||||
useful in some cases to alter the rank order. E.g. to insure that
|
||||
cores within each node are ranked in a desired order. Or when using
|
||||
the :doc:`run_style verlet/split <run_style>` command with 2 partitions
|
||||
to insure that a specific Kspace processor (in the 2nd partition) is
|
||||
matched up with a specific set of processors in the 1st partition.
|
||||
to insure that a specific Kspace processor (in the second partition) is
|
||||
matched up with a specific set of processors in the first partition.
|
||||
See the :doc:`Speed tips <Speed_tips>` doc page for more details.
|
||||
|
||||
If the keyword *nth* is used with a setting *N*\ , then it means every
|
||||
Nth processor will be moved to the end of the ranking. This is useful
|
||||
when using the :doc:`run_style verlet/split <run_style>` command with 2
|
||||
partitions via the -partition command-line switch. The first set of
|
||||
processors will be in the first partition, the 2nd set in the 2nd
|
||||
processors will be in the first partition, the second set in the second
|
||||
partition. The -reorder command-line switch can alter this so that
|
||||
the 1st N procs in the 1st partition and one proc in the 2nd partition
|
||||
the first N procs in the first partition and one proc in the second partition
|
||||
will be ordered consecutively, e.g. as the cores on one physical node.
|
||||
This can boost performance. For example, if you use "-reorder nth 4"
|
||||
and "-partition 9 3" and you are running on 12 processors, the
|
||||
|
||||
@ -37,7 +37,7 @@ The *charmm* angle style uses the potential
|
||||
E = K (\theta - \theta_0)^2 + K_{ub} (r - r_{ub})^2
|
||||
|
||||
with an additional Urey_Bradley term based on the distance :math:`r` between
|
||||
the 1st and 3rd atoms in the angle. :math:`K`, :math:`\theta_0`,
|
||||
the first and third atoms in the angle. :math:`K`, :math:`\theta_0`,
|
||||
:math:`K_{ub}`, and :math:`R_{ub}` are coefficients defined for each angle
|
||||
type.
|
||||
|
||||
|
||||
@ -31,7 +31,7 @@ Angle coefficients can also be set in the data file read by the
|
||||
:doc:`read_data <read_data>` command or in a restart file.
|
||||
|
||||
N can be specified in one of two ways. An explicit numeric value can
|
||||
be used, as in the 1st example above. Or a wild-card asterisk can be
|
||||
be used, as in the first example above. Or a wild-card asterisk can be
|
||||
used to set the coefficients for multiple angle types. This takes the
|
||||
form "\*" or "\*n" or "n\*" or "m\*n". If N = the number of angle types,
|
||||
then an asterisk with no numeric values means all types from 1 to N. A
|
||||
@ -53,7 +53,7 @@ same format as the arguments of the :doc:`angle_coeff <angle_coeff>` command in
|
||||
script, except that wild-card asterisks should not be used since
|
||||
coefficients for all N types must be listed in the file. For example,
|
||||
under the "Angle Coeffs" section of a data file, the line that
|
||||
corresponds to the 1st example above would be listed as
|
||||
corresponds to the first example above would be listed as
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
|
||||
@ -75,7 +75,7 @@ parenthesized comments):
|
||||
...
|
||||
181 180.0 0.0 0.0
|
||||
|
||||
A section begins with a non-blank line whose 1st character is not a
|
||||
A section begins with a non-blank line whose first character is not a
|
||||
"#"; blank lines or lines starting with "#" can be used as comments
|
||||
between sections. The first line begins with a keyword which
|
||||
identifies the section. The line can contain additional text, but the
|
||||
@ -99,7 +99,7 @@ is in the tabulated file (with effectively no preliminary
|
||||
interpolation), you should set Ntable = Nfile.
|
||||
|
||||
The "FP" parameter is optional. If used, it is followed by two values
|
||||
fplo and fphi, which are the 2nd derivatives at the innermost and
|
||||
fplo and fphi, which are the second derivatives at the innermost and
|
||||
outermost angle settings. These values are needed by the spline
|
||||
construction routines. If not specified by the "FP" parameter, they
|
||||
are estimated (less accurately) by the first two and last two
|
||||
@ -110,9 +110,9 @@ equilibrium angle value, which is used, for example, by the :doc:`fix shake <fix
|
||||
set to 180.0.
|
||||
|
||||
Following a blank line, the next N lines list the tabulated values.
|
||||
On each line, the 1st value is the index from 1 to N, the 2nd value is
|
||||
the angle value (in degrees), the 3rd value is the energy (in energy
|
||||
units), and the 4th is -dE/d(theta) (also in energy units). The 3rd
|
||||
On each line, the first value is the index from 1 to N, the second value is
|
||||
the angle value (in degrees), the third value is the energy (in energy
|
||||
units), and the fourth is -dE/d(theta) (also in energy units). The third
|
||||
term is the energy of the 3-atom configuration for the specified
|
||||
angle. The last term is the derivative of the energy with respect to
|
||||
the angle (in degrees, not radians). Thus the units of the last term
|
||||
|
||||
@ -15,7 +15,7 @@ Syntax
|
||||
fix_modify AtC control momentum glc_velocity
|
||||
fix_modify AtC control momentum hoover
|
||||
fix_modify AtC control momentum flux [faceset face_set_id, interpolate]
|
||||
|
||||
|
||||
* AtC fixID = ID of :doc:`fix atc <fix_atc>` instance
|
||||
* control = name of the AtC sub-command
|
||||
* physics_type = *thermal* or *momentum*
|
||||
@ -52,7 +52,7 @@ the finite element temperature. *flux* is a similar mode, but rather
|
||||
adds energy to the atoms based on conservation of energy.
|
||||
|
||||
*correction_max_iterations* sets the maximum number of iterations to
|
||||
compute the 2nd order in time correction term for lambda with the
|
||||
compute the second order in time correction term for lambda with the
|
||||
fractional step method. The method uses the same tolerance as the
|
||||
controller's matrix solver.
|
||||
|
||||
|
||||
@ -56,7 +56,7 @@ adds energy to the atoms based on conservation of energy. *hoover* and
|
||||
atoms.
|
||||
|
||||
*correction_max_iterations* sets the maximum number of iterations to
|
||||
compute the 2nd order in time correction term for lambda with the
|
||||
compute the second order in time correction term for lambda with the
|
||||
fractional step method. The method uses the same tolerance as the
|
||||
controller's matrix solver.
|
||||
|
||||
|
||||
@ -25,8 +25,8 @@ Syntax
|
||||
- temperature : temperature derived from the relative atomic kinetic energy
|
||||
- kinetic_temperature : temperature derived from the full kinetic energy
|
||||
- number_density : simple kernel estimation of number of atoms per unit volume
|
||||
- stress : Cauchy stress tensor for eulerian analysis (atom_element_map), or 1st Piola-Kirchhoff stress tensor for lagrangian analysis
|
||||
- transformed_stress : 1st Piola-Kirchhoff stress tensor for eulerian analysis (atom_element_map), or Cauchy stress tensor for lagrangian analysis
|
||||
- stress : Cauchy stress tensor for eulerian analysis (atom_element_map), or first Piola-Kirchhoff stress tensor for lagrangian analysis
|
||||
- transformed_stress : first Piola-Kirchhoff stress tensor for eulerian analysis (atom_element_map), or Cauchy stress tensor for lagrangian analysis
|
||||
- heat_flux : spatial heat flux vector for eulerian, or referential heat flux vector for lagrangian
|
||||
- potential_energy : potential energy per unit volume
|
||||
- kinetic_energy : kinetic energy per unit volume
|
||||
@ -37,7 +37,7 @@ Syntax
|
||||
- eshelby_stress : configurational stress (energy-momentum) tensor defined by [Eshelby]_
|
||||
- vacancy_concentration : volume fraction of vacancy content
|
||||
- type_concentration : volume fraction of a specific atom type
|
||||
|
||||
|
||||
Examples
|
||||
""""""""
|
||||
|
||||
|
||||
@ -23,8 +23,8 @@ Syntax
|
||||
- temperature : temperature derived from the relative atomic kinetic energy
|
||||
- kinetic_temperature : temperature derived from the full kinetic energy
|
||||
- number_density : simple kernel estimation of number of atoms per unit volume
|
||||
- stress : Cauchy stress tensor for eulerian analysis (atom_element_map), or 1st Piola-Kirchhoff stress tensor for lagrangian analysis
|
||||
- transformed_stress : 1st Piola-Kirchhoff stress tensor for eulerian analysis (atom_element_map), or Cauchy stress tensor for lagrangian analysis
|
||||
- stress : Cauchy stress tensor for eulerian analysis (atom_element_map), or first Piola-Kirchhoff stress tensor for lagrangian analysis
|
||||
- transformed_stress : first Piola-Kirchhoff stress tensor for eulerian analysis (atom_element_map), or Cauchy stress tensor for lagrangian analysis
|
||||
- heat_flux : spatial heat flux vector for eulerian, or referential heat flux vector for lagrangian
|
||||
- potential_energy : potential energy per unit volume
|
||||
- kinetic_energy : kinetic energy per unit volume
|
||||
|
||||
@ -25,7 +25,7 @@ Syntax
|
||||
- *quartic_bar* : <half_width>
|
||||
- *quartic_cylinder* : <radius>
|
||||
- *quartic_sphere* : <radius>
|
||||
|
||||
|
||||
|
||||
|
||||
Examples
|
||||
|
||||
@ -23,8 +23,8 @@ Syntax
|
||||
- temperature : temperature derived from the relative atomic kinetic energy
|
||||
- kinetic_temperature : temperature derived from the full kinetic energy
|
||||
- number_density : simple kernel estimation of number of atoms per unit volume
|
||||
- stress : Cauchy stress tensor for eulerian analysis (atom_element_map), or 1st Piola-Kirchhoff stress tensor for lagrangian analysis
|
||||
- transformed_stress : 1st Piola-Kirchhoff stress tensor for eulerian analysis (atom_element_map), or Cauchy stress tensor for lagrangian analysis
|
||||
- stress : Cauchy stress tensor for eulerian analysis (atom_element_map), or first Piola-Kirchhoff stress tensor for lagrangian analysis
|
||||
- transformed_stress : first Piola-Kirchhoff stress tensor for eulerian analysis (atom_element_map), or Cauchy stress tensor for lagrangian analysis
|
||||
- heat_flux : spatial heat flux vector for eulerian, or referential heat flux vector for lagrangian
|
||||
- potential_energy : potential energy per unit volume
|
||||
- kinetic_energy : kinetic energy per unit volume
|
||||
|
||||
@ -38,7 +38,7 @@ Related AtC commands
|
||||
- :doc:`fix_modify AtC add_species <atc_add_species>`
|
||||
- :doc:`fix_modify AtC add_molecule <atc_add_molecule>`
|
||||
- :doc:`fix_modify AtC remove_molecule <atc_remove_molecule>`
|
||||
|
||||
|
||||
Default
|
||||
"""""""
|
||||
|
||||
|
||||
@ -22,7 +22,7 @@ Examples
|
||||
|
||||
fix_modify AtC set reference_potential_energy
|
||||
fix_modify AtC set reference_potential_energy -0.05
|
||||
fix_modify AtC set reference_potential_energy myPEvalues
|
||||
fix_modify AtC set reference_potential_energy myPEvalues
|
||||
|
||||
Description
|
||||
"""""""""""
|
||||
|
||||
@ -33,11 +33,11 @@ Command to select the thermal or momentum time integration.
|
||||
Options for thermal time integration:
|
||||
|
||||
*gear*
|
||||
atomic velocity update with 2nd order Verlet, nodal temperature update
|
||||
with 3rd or 4th order Gear, thermostats based on controlling power
|
||||
atomic velocity update with second order Verlet, nodal temperature update
|
||||
with third or fourth order Gear, thermostats based on controlling power
|
||||
|
||||
*fractional_step*
|
||||
atomic velocity update with 2nd order Verlet, mixed nodal temperature
|
||||
atomic velocity update with second order Verlet, mixed nodal temperature
|
||||
update, 3/4 Gear for continuum and 2 Verlet for atomic contributions,
|
||||
thermostats based on controlling discrete energy changes
|
||||
|
||||
@ -46,18 +46,18 @@ Options for thermal time integration:
|
||||
Options for momentum time integration:
|
||||
|
||||
*verlet*
|
||||
atomic velocity update with 2nd order Verlet, nodal temperature update
|
||||
with 2nd order Verlet, kinetostats based on controlling force
|
||||
atomic velocity update with second order Verlet, nodal temperature update
|
||||
with second order Verlet, kinetostats based on controlling force
|
||||
|
||||
*fractional_step*
|
||||
atomic velocity update with 2nd order Verlet, mixed nodal momentum
|
||||
update, 2nd order Verlet for continuum and exact 2nd order Verlet for
|
||||
atomic velocity update with second order Verlet, mixed nodal momentum
|
||||
update, second order Verlet for continuum and exact second order Verlet for
|
||||
atomic contributions, kinetostats based on controlling discrete
|
||||
momentum changes
|
||||
|
||||
*gear*
|
||||
atomic velocity update with 2nd order Verlet, nodal temperature update
|
||||
with 3rd or 4th order Gear, kinetostats based on controlling power.
|
||||
atomic velocity update with second order Verlet, nodal temperature update
|
||||
with third or fourth order Gear, kinetostats based on controlling power.
|
||||
|
||||
---------
|
||||
|
||||
|
||||
@ -32,7 +32,7 @@ Bond coefficients can also be set in the data file read by the
|
||||
:doc:`read_data <read_data>` command or in a restart file.
|
||||
|
||||
N can be specified in one of two ways. An explicit numeric value can
|
||||
be used, as in the 1st example above. Or a wild-card asterisk can be
|
||||
be used, as in the first example above. Or a wild-card asterisk can be
|
||||
used to set the coefficients for multiple bond types. This takes the
|
||||
form "\*" or "\*n" or "n\*" or "m\*n". If N = the number of bond types,
|
||||
then an asterisk with no numeric values means all types from 1 to N. A
|
||||
@ -54,7 +54,7 @@ same format as the arguments of the bond_coeff command in an input
|
||||
script, except that wild-card asterisks should not be used since
|
||||
coefficients for all N types must be listed in the file. For example,
|
||||
under the "Bond Coeffs" section of a data file, the line that
|
||||
corresponds to the 1st example above would be listed as
|
||||
corresponds to the first example above would be listed as
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
|
||||
@ -38,8 +38,8 @@ The *fene* bond style uses the potential
|
||||
|
||||
to define a finite extensible nonlinear elastic (FENE) potential
|
||||
:ref:`(Kremer) <fene-Kremer>`, used for bead-spring polymer models. The first
|
||||
term is attractive, the 2nd Lennard-Jones term is repulsive. The
|
||||
first term extends to :math:`R_0`, the maximum extent of the bond. The 2nd
|
||||
term is attractive, the second Lennard-Jones term is repulsive. The
|
||||
first term extends to :math:`R_0`, the maximum extent of the bond. The second
|
||||
term is cutoff at :math:`2^\frac{1}{6} \sigma`, the minimum of the LJ potential.
|
||||
|
||||
The following coefficients must be defined for each bond type via the
|
||||
|
||||
@ -32,12 +32,12 @@ The *fene/expand* bond style uses the potential
|
||||
|
||||
to define a finite extensible nonlinear elastic (FENE) potential
|
||||
:ref:`(Kremer) <feneexpand-Kremer>`, used for bead-spring polymer models. The first
|
||||
term is attractive, the 2nd Lennard-Jones term is repulsive.
|
||||
term is attractive, the second Lennard-Jones term is repulsive.
|
||||
|
||||
The *fene/expand* bond style is similar to *fene* except that an extra
|
||||
shift factor of :math:`\Delta` (positive or negative) is added to :math:`r` to
|
||||
effectively change the bead size of the bonded atoms. The first term
|
||||
now extends to :math:`R_0 + \Delta` and the 2nd term is cutoff at :math:`2^\frac{1}{6} \sigma + \Delta`.
|
||||
now extends to :math:`R_0 + \Delta` and the second term is cutoff at :math:`2^\frac{1}{6} \sigma + \Delta`.
|
||||
|
||||
The following coefficients must be defined for each bond type via the
|
||||
:doc:`bond_coeff <bond_coeff>` command as in the example above, or in
|
||||
|
||||
@ -74,7 +74,7 @@ parenthesized comments):
|
||||
...
|
||||
101 1.00 338.0000 -1352.0000
|
||||
|
||||
A section begins with a non-blank line whose 1st character is not a
|
||||
A section begins with a non-blank line whose first character is not a
|
||||
"#"; blank lines or lines starting with "#" can be used as comments
|
||||
between sections. The first line begins with a keyword which
|
||||
identifies the section. The line can contain additional text, but the
|
||||
@ -109,9 +109,9 @@ equilibrium bond length, which is used, for example, by the :doc:`fix shake <fix
|
||||
length is to the distance in the table with the lowest potential energy.
|
||||
|
||||
Following a blank line, the next N lines list the tabulated values.
|
||||
On each line, the 1st value is the index from 1 to N, the 2nd value is
|
||||
the bond length r (in distance units), the 3rd value is the energy (in
|
||||
energy units), and the 4th is the force (in force units). The bond
|
||||
On each line, the first value is the index from 1 to N, the second value is
|
||||
the bond length r (in distance units), the third value is the energy (in
|
||||
energy units), and the fourth is the force (in force units). The bond
|
||||
lengths must range from a LO value to a HI value, and increase from
|
||||
one line to the next. If the actual bond length is ever smaller than
|
||||
the LO value or larger than the HI value, then the calculation is
|
||||
|
||||
@ -76,9 +76,9 @@ atoms becomes less than 50.0. This can be useful if you start a
|
||||
simulation with an empty box or if you wish to leave room on one side
|
||||
of the box, e.g. for atoms to evaporate from a surface.
|
||||
|
||||
For triclinic (non-orthogonal) simulation boxes, if the 2nd dimension
|
||||
For triclinic (non-orthogonal) simulation boxes, if the second dimension
|
||||
of a tilt factor (e.g. y for xy) is periodic, then the periodicity is
|
||||
enforced with the tilt factor offset. If the 1st dimension is
|
||||
enforced with the tilt factor offset. If the first dimension is
|
||||
shrink-wrapped, then the shrink wrapping is applied to the tilted box
|
||||
face, to encompass the atoms. E.g. for a positive xy tilt, the xlo
|
||||
and xhi faces of the box are planes tilting in the +y direction as y
|
||||
|
||||
@ -38,7 +38,7 @@ skewed the triclinic box is; see the :doc:`Howto triclinic <Howto_triclinic>` do
|
||||
boxes in LAMMPS.
|
||||
|
||||
LAMMPS normally requires that no tilt factor can skew the box more
|
||||
than half the distance of the parallel box length, which is the 1st
|
||||
than half the distance of the parallel box length, which is the first
|
||||
dimension in the tilt factor (x for xz). If *tilt* is set to
|
||||
*small*\ , which is the default, then an error will be
|
||||
generated if a box is created which exceeds this limit. If *tilt*
|
||||
|
||||
@ -82,9 +82,9 @@ neighbor atom in each requested ADF.
|
||||
is what is specified with the :doc:`neighbor <neighbor>` command.
|
||||
|
||||
The *itypeN*\ ,\ *jtypeN*\ ,\ *ktypeN* settings can be specified in one of two
|
||||
ways. An explicit numeric value can be used, as in the 1st example
|
||||
ways. An explicit numeric value can be used, as in the first example
|
||||
above. Or a wild-card asterisk can be used to specify a range of atom
|
||||
types as in the 2nd example above.
|
||||
types as in the second example above.
|
||||
This takes the form "\*" or "\*n" or "n\*" or "m\*n". If N = the
|
||||
number of atom types, then an asterisk with no numeric values means
|
||||
all types from 1 to N. A leading asterisk means all types from 1 to n
|
||||
@ -92,12 +92,12 @@ all types from 1 to N. A leading asterisk means all types from 1 to n
|
||||
(inclusive). A middle asterisk means all types from m to n
|
||||
(inclusive).
|
||||
|
||||
If *itypeN*\ , *jtypeN*\ , and *ktypeN* are single values, as in the 1st example
|
||||
If *itypeN*\ , *jtypeN*\ , and *ktypeN* are single values, as in the first example
|
||||
above, this means that the ADF is computed where atoms of type *itypeN*
|
||||
are the central atom, and neighbor atoms of type *jtypeN* and *ktypeN*
|
||||
are forming the angle. If any of *itypeN*\ , *jtypeN*\ , or *ktypeN*
|
||||
represent a range of values via
|
||||
the wild-card asterisk, as in the 2nd example above, this means that the
|
||||
the wild-card asterisk, as in the second example above, this means that the
|
||||
ADF is computed where atoms of any of the range of types represented
|
||||
by *itypeN* are the central atom, and the angle is formed by two neighbors,
|
||||
one neighbor in the range of types represented by *jtypeN* and another neighbor
|
||||
|
||||
@ -218,8 +218,8 @@ into ellipses.
|
||||
The created bins (and hence the chunk IDs) are numbered consecutively
|
||||
from 1 to the number of bins = *Nchunk*\ . For *bin2d* and *bin3d*\ , the
|
||||
numbering varies most rapidly in the first dimension (which could be
|
||||
x, y, or z), next rapidly in the 2nd dimension, and most slowly in the
|
||||
3rd dimension. For *bin/sphere*\ , the bin with smallest radii is chunk
|
||||
x, y, or z), next rapidly in the second dimension, and most slowly in the
|
||||
third dimension. For *bin/sphere*\ , the bin with smallest radii is chunk
|
||||
1 and the bni with largest radii is chunk Nchunk = *ncbin*\ . For
|
||||
*bin/cylinder*\ , the numbering varies most rapidly in the dimension
|
||||
along the cylinder axis and most slowly in the radial direction.
|
||||
@ -614,7 +614,7 @@ Note that for the *bin/sphere* style, the radii *srmin* and *srmax* are
|
||||
scaled by the lattice spacing or reduced value of the *x* dimension.
|
||||
|
||||
Note that for the *bin/cylinder* style, the radii *crmin* and *crmax*
|
||||
are scaled by the lattice spacing or reduced value of the 1st
|
||||
are scaled by the lattice spacing or reduced value of the first
|
||||
dimension perpendicular to the cylinder axis. E.g. y for an x-axis
|
||||
cylinder, x for a y-axis cylinder, and x for a z-axis cylinder.
|
||||
|
||||
|
||||
@ -63,7 +63,7 @@ keywords are listed, a single coordination number is calculated, which
|
||||
includes atoms of all types (same as the "\*" format, see below).
|
||||
|
||||
The *typeN* keywords can be specified in one of two ways. An explicit
|
||||
numeric value can be used, as in the 2nd example above. Or a
|
||||
numeric value can be used, as in the second example above. Or a
|
||||
wild-card asterisk can be used to specify a range of atom types. This
|
||||
takes the form "\*" or "\*n" or "n\*" or "m\*n". If N = the number of
|
||||
atom types, then an asterisk with no numeric values means all types
|
||||
|
||||
@ -36,7 +36,7 @@ all effects due to atoms passing through periodic boundaries.
|
||||
|
||||
A vector of four quantities per atom is calculated by this compute.
|
||||
The first 3 elements of the vector are the dx,dy,dz displacements.
|
||||
The 4th component is the total displacement, i.e. sqrt(dx\*dx + dy\*dy +
|
||||
The fourth component is the total displacement, i.e. sqrt(dx\*dx + dy\*dy +
|
||||
dz\*dz).
|
||||
|
||||
The displacement of an atom is from its original position at the time
|
||||
|
||||
@ -224,7 +224,7 @@ the pair\_\*.cpp file associated with the potential.
|
||||
|
||||
Similar to the :doc:`pair_coeff <pair_coeff>` command, I and J can be
|
||||
specified in one of two ways. Explicit numeric values can be used for
|
||||
each, as in the 1st example above. I <= J is required. LAMMPS sets
|
||||
each, as in the first example above. I <= J is required. LAMMPS sets
|
||||
the coefficients for the symmetric J,I interaction to the same
|
||||
values. A wild-card asterisk can be used in place of or in conjunction
|
||||
with the I,J arguments to set the coefficients for multiple pairs of
|
||||
|
||||
@ -64,7 +64,7 @@ If the *kspace* keyword is set to *yes*\ , which is not the default, and
|
||||
if a :doc:`kspace_style <kspace_style>` is defined, then the interaction
|
||||
energy will include a Kspace component which is the long-range
|
||||
Coulombic energy between all the atoms in the first group and all the
|
||||
atoms in the 2nd group. Likewise, the interaction force calculated by
|
||||
atoms in the second group. Likewise, the interaction force calculated by
|
||||
this compute will include the force on the compute group atoms due to
|
||||
long-range Coulombic interactions with atoms in the specified group2.
|
||||
|
||||
|
||||
@ -38,7 +38,7 @@ parameter of mean-squared displacement, see the :doc:`compute msd/nongauss <comp
|
||||
|
||||
A vector of four quantities is calculated by this compute. The first 3
|
||||
elements of the vector are the squared dx,dy,dz displacements, summed
|
||||
and averaged over atoms in the group. The 4th element is the total
|
||||
and averaged over atoms in the group. The fourth element is the total
|
||||
squared displacement, i.e. (dx\*dx + dy\*dy + dz\*dz), summed and
|
||||
averaged over atoms in the group.
|
||||
|
||||
|
||||
@ -36,7 +36,7 @@ they can be used to measure properties of a system.
|
||||
|
||||
Four quantities are calculated by this compute for each chunk. The
|
||||
first 3 quantities are the squared dx,dy,dz displacements of the
|
||||
center-of-mass. The 4th component is the total squared displacement,
|
||||
center-of-mass. The fourth component is the total squared displacement,
|
||||
i.e. (dx\*dx + dy\*dy + dz\*dz) of the center-of-mass. These
|
||||
calculations include all effects due to atoms passing through periodic
|
||||
boundaries.
|
||||
|
||||
@ -39,7 +39,7 @@ element of the vector is the total squared dx,dy,dz displacements
|
||||
drsquared = (dx\*dx + dy\*dy + dz\*dz) of atoms, and the second is the
|
||||
fourth power of these displacements drfourth = (dx\*dx + dy\*dy +
|
||||
dz\*dz)\*(dx\*dx + dy\*dy + dz\*dz), summed and averaged over atoms in the
|
||||
group. The 3rd component is the nonGaussian diffusion parameter NGP =
|
||||
group. The third component is the nonGaussian diffusion parameter NGP =
|
||||
3\*drfourth/(5\*drsquared\*drsquared), i.e.
|
||||
|
||||
.. math::
|
||||
@ -68,7 +68,7 @@ page for an overview of LAMMPS output options.
|
||||
|
||||
The vector values are "intensive". The first vector value will be in
|
||||
distance\^2 :doc:`units <units>`, the second is in distance\^4 units, and
|
||||
the 3rd is dimensionless.
|
||||
the third is dimensionless.
|
||||
|
||||
Restrictions
|
||||
""""""""""""
|
||||
|
||||
@ -63,7 +63,7 @@ chunkID. This means that the original chunk IDs (e.g. molecule IDs)
|
||||
will have been compressed to remove chunk IDs with no atoms assigned
|
||||
to them. Thus a compressed chunk ID of 3 may correspond to an original
|
||||
chunk ID (molecule ID in this case) of 415. The *id* attribute will
|
||||
then be 415 for the 3rd chunk.
|
||||
then be 415 for the third chunk.
|
||||
|
||||
The *coordN* attributes can only be used if a *binning* style was used
|
||||
in the :doc:`compute chunk/atom <compute_chunk_atom>` command referenced
|
||||
|
||||
@ -97,7 +97,7 @@ listed, then a separate histogram is generated for each
|
||||
*itype*\ ,\ *jtype* pair.
|
||||
|
||||
The *itypeN* and *jtypeN* settings can be specified in one of two
|
||||
ways. An explicit numeric value can be used, as in the 4th example
|
||||
ways. An explicit numeric value can be used, as in the fourth example
|
||||
above. Or a wild-card asterisk can be used to specify a range of atom
|
||||
types. This takes the form "\*" or "\*n" or "n\*" or "m\*n". If N = the
|
||||
number of atom types, then an asterisk with no numeric values means
|
||||
@ -106,11 +106,11 @@ all types from 1 to N. A leading asterisk means all types from 1 to n
|
||||
(inclusive). A middle asterisk means all types from m to n
|
||||
(inclusive).
|
||||
|
||||
If both *itypeN* and *jtypeN* are single values, as in the 4th example
|
||||
If both *itypeN* and *jtypeN* are single values, as in the fourth example
|
||||
above, this means that a g(r) is computed where atoms of type *itypeN*
|
||||
are the central atom, and atoms of type *jtypeN* are the distribution
|
||||
atom. If either *itypeN* and *jtypeN* represent a range of values via
|
||||
the wild-card asterisk, as in the 5th example above, this means that a
|
||||
the wild-card asterisk, as in the fifth example above, this means that a
|
||||
g(r) is computed where atoms of any of the range of types represented
|
||||
by *itypeN* are the central atom, and atoms of any of the range of
|
||||
types represented by *jtypeN* are the distribution atom.
|
||||
|
||||
@ -49,7 +49,7 @@ respective group IDs, which can be defined using the
|
||||
must be the same and there should be one bond defined between a pair
|
||||
of atoms in the two groups. Non-polarized ions which might also be
|
||||
included in the treated system should not be included into either of
|
||||
these groups, they are taken into account by the *group-ID* (2nd
|
||||
these groups, they are taken into account by the *group-ID* (second
|
||||
argument) of the compute.
|
||||
|
||||
The temperature is calculated by the formula KE = dim/2 N k T, where
|
||||
|
||||
@ -76,7 +76,7 @@ with respect to *lambda*\ .
|
||||
|
||||
To perform this calculation, you provide one or more atom types as
|
||||
*atype*\ . *Atype* can be specified in one of two ways. An explicit
|
||||
numeric values can be used, as in the 1st example above. Or a
|
||||
numeric values can be used, as in the first example above. Or a
|
||||
wildcard asterisk can be used in place of or in conjunction with the
|
||||
*atype* argument to select multiple atom types. This takes the form
|
||||
"\*" or "\*n" or "n\*" or "m\*n". If N = the number of atom types, then
|
||||
|
||||
@ -33,7 +33,7 @@ A vector of four quantities is calculated by this compute. The first 3
|
||||
elements of the vector are vx \* vx0 (and similarly for the y and z
|
||||
components), summed and averaged over atoms in the group. Vx is the
|
||||
current x-component of velocity for the atom, vx0 is the initial
|
||||
x-component of velocity for the atom. The 4th element of the vector
|
||||
x-component of velocity for the atom. The fourth element of the vector
|
||||
is the total VACF, i.e. (vx\*vx0 + vy\*vy0 + vz\*vz0), summed and
|
||||
averaged over atoms in the group.
|
||||
|
||||
|
||||
@ -73,7 +73,7 @@ or :doc:`read_restart <read_restart>` commands:
|
||||
The weighting factor is required to correct for double counting
|
||||
pairwise non-bonded Lennard-Jones interactions in cyclic systems or
|
||||
when using the CHARMM dihedral style with non-CHARMM force fields.
|
||||
With the CHARMM dihedral style, interactions between the 1st and 4th
|
||||
With the CHARMM dihedral style, interactions between the first and fourth
|
||||
atoms in a dihedral are skipped during the normal non-bonded force
|
||||
computation and instead evaluated as part of the dihedral using
|
||||
special epsilon and sigma values specified with the
|
||||
@ -93,7 +93,7 @@ which applies to all 1-4 interactions in the system. For CHARMM force
|
||||
fields, the special_bonds 1-4 interaction scaling factor should be set
|
||||
to 0.0. Since the corresponding 1-4 non-bonded interactions are
|
||||
computed with the dihedral. This means that if any of the weighting
|
||||
factors defined as dihedral coefficients (4th coeff above) are
|
||||
factors defined as dihedral coefficients (fourth coeff above) are
|
||||
non-zero, then you must use a pair style with "lj/charmm" and set the
|
||||
special_bonds 1-4 scaling factor to 0.0 (which is the
|
||||
default). Otherwise 1-4 non-bonded interactions in dihedrals will be
|
||||
@ -115,7 +115,7 @@ details.
|
||||
|
||||
Note that for AMBER force fields, which use pair styles with "lj/cut",
|
||||
the special_bonds 1-4 scaling factor should be set to the AMBER
|
||||
defaults (1/2 and 5/6) and all the dihedral weighting factors (4th
|
||||
defaults (1/2 and 5/6) and all the dihedral weighting factors (fourth
|
||||
coeff above) must be set to 0.0. In this case, you can use any pair
|
||||
style you wish, since the dihedral does not need any Lennard-Jones
|
||||
parameter information and will not compute any 1-4 non-bonded
|
||||
|
||||
@ -31,7 +31,7 @@ Dihedral coefficients can also be set in the data file read by the
|
||||
:doc:`read_data <read_data>` command or in a restart file.
|
||||
|
||||
N can be specified in one of two ways. An explicit numeric value can
|
||||
be used, as in the 1st example above. Or a wild-card asterisk can be
|
||||
be used, as in the first example above. Or a wild-card asterisk can be
|
||||
used to set the coefficients for multiple dihedral types. This takes the
|
||||
form "\*" or "\*n" or "n\*" or "m\*n". If N = the number of dihedral types,
|
||||
then an asterisk with no numeric values means all types from 1 to N. A
|
||||
@ -53,7 +53,7 @@ same format as the arguments of the dihedral_coeff command in an input
|
||||
script, except that wild-card asterisks should not be used since
|
||||
coefficients for all N types must be listed in the file. For example,
|
||||
under the "Dihedral Coeffs" section of a data file, the line that
|
||||
corresponds to the 1st example above would be listed as
|
||||
corresponds to the first example above would be listed as
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
|
||||
@ -92,7 +92,7 @@ or blank lines.
|
||||
...
|
||||
30 180.0 -0.707106781187
|
||||
|
||||
A section begins with a non-blank line whose 1st character is not a
|
||||
A section begins with a non-blank line whose first character is not a
|
||||
"#"; blank lines or lines starting with "#" can be used as comments
|
||||
between sections. The first line begins with a keyword which
|
||||
identifies the section. The line can contain additional text, but the
|
||||
@ -102,10 +102,10 @@ any order) one or more parameters for the table. Each parameter is a
|
||||
keyword followed by one or more numeric values.
|
||||
|
||||
Following a blank line, the next N lines list the tabulated values. On
|
||||
each line, the 1st value is the index from 1 to N, the 2nd value is
|
||||
the angle value, the 3rd value is the energy (in energy units), and
|
||||
the 4th is -dE/d(phi) also in energy units). The 3rd term is the
|
||||
energy of the 4-atom configuration for the specified angle. The 4th
|
||||
each line, the first value is the index from 1 to N, the second value is
|
||||
the angle value, the third value is the energy (in energy units), and
|
||||
the fourth is -dE/d(phi) also in energy units). The third term is the
|
||||
energy of the 4-atom configuration for the specified angle. The fourth
|
||||
term (when present) is the negative derivative of the energy with
|
||||
respect to the angle (in degrees, or radians depending on whether the
|
||||
user selected DEGREES or RADIANS). Thus the units of the last term
|
||||
@ -147,9 +147,9 @@ choice of angle units).
|
||||
|
||||
The optional "NOF" keyword allows the user to omit the forces
|
||||
(negative energy derivatives) from the table file (normally located in
|
||||
the 4th column). In their place, forces will be calculated
|
||||
the fourth column). In their place, forces will be calculated
|
||||
automatically by differentiating the potential energy function
|
||||
indicated by the 3rd column of the table (using either linear or
|
||||
indicated by the third column of the table (using either linear or
|
||||
spline interpolation).
|
||||
|
||||
The optional "DEGREES" keyword allows the user to specify angles in
|
||||
@ -157,7 +157,7 @@ degrees instead of radians (default).
|
||||
|
||||
The optional "RADIANS" keyword allows the user to specify angles in
|
||||
radians instead of degrees. (Note: This changes the way the forces
|
||||
are scaled in the 4th column of the data file.)
|
||||
are scaled in the fourth column of the data file.)
|
||||
|
||||
The optional "CHECKU" keyword is followed by a filename. This allows
|
||||
the user to save all of the *Ntable* different entries in the
|
||||
|
||||
@ -113,7 +113,7 @@ or blank lines.
|
||||
...
|
||||
30 180.0 -0.707106781187
|
||||
|
||||
A section begins with a non-blank line whose 1st character is not a
|
||||
A section begins with a non-blank line whose first character is not a
|
||||
"#"; blank lines or lines starting with "#" can be used as comments
|
||||
between sections. The first line begins with a keyword which
|
||||
identifies the section. The line can contain additional text, but the
|
||||
@ -123,10 +123,10 @@ any order) one or more parameters for the table. Each parameter is a
|
||||
keyword followed by one or more numeric values.
|
||||
|
||||
Following a blank line, the next N lines list the tabulated values. On
|
||||
each line, the 1st value is the index from 1 to N, the 2nd value is
|
||||
the angle value, the 3rd value is the energy (in energy units), and
|
||||
the 4th is -dE/d(phi) also in energy units). The 3rd term is the
|
||||
energy of the 4-atom configuration for the specified angle. The 4th
|
||||
each line, the first value is the index from 1 to N, the second value is
|
||||
the angle value, the third value is the energy (in energy units), and
|
||||
the fourth is -dE/d(phi) also in energy units). The third term is the
|
||||
energy of the 4-atom configuration for the specified angle. The fourth
|
||||
term (when present) is the negative derivative of the energy with
|
||||
respect to the angle (in degrees, or radians depending on whether the
|
||||
user selected DEGREES or RADIANS). Thus the units of the last term
|
||||
@ -168,9 +168,9 @@ choice of angle units).
|
||||
|
||||
The optional "NOF" keyword allows the user to omit the forces
|
||||
(negative energy derivatives) from the table file (normally located in
|
||||
the 4th column). In their place, forces will be calculated
|
||||
the fourth column). In their place, forces will be calculated
|
||||
automatically by differentiating the potential energy function
|
||||
indicated by the 3rd column of the table (using either linear or
|
||||
indicated by the third column of the table (using either linear or
|
||||
spline interpolation).
|
||||
|
||||
The optional "DEGREES" keyword allows the user to specify angles in
|
||||
@ -178,7 +178,7 @@ degrees instead of radians (default).
|
||||
|
||||
The optional "RADIANS" keyword allows the user to specify angles in
|
||||
radians instead of degrees. (Note: This changes the way the forces
|
||||
are scaled in the 4th column of the data file.)
|
||||
are scaled in the fourth column of the data file.)
|
||||
|
||||
The optional "CHECKU" keyword is followed by a filename. This allows
|
||||
the user to save all of the *Ntable* different entries in the
|
||||
|
||||
@ -134,17 +134,23 @@ Only atoms in the specified group are rendered in the image. The
|
||||
alter what atoms are included in the image.
|
||||
The filename suffix determines whether a JPEG, PNG, or PPM file is
|
||||
created with the *image* dump style. If the suffix is ".jpg" or
|
||||
".jpeg", then a JPEG format file is created, if the suffix is ".png",
|
||||
then a PNG format is created, else a PPM (aka NETPBM) format file is
|
||||
created. The JPEG and PNG files are binary; PPM has a text mode
|
||||
header followed by binary data. JPEG images have lossy compression;
|
||||
PNG has lossless compression; and PPM files are uncompressed but can
|
||||
be compressed with gzip, if LAMMPS has been compiled with
|
||||
-DLAMMPS_GZIP and a ".gz" suffix is used.
|
||||
".jpeg", then a `JPEG format <jpeg_format_>`_ file is created, if the
|
||||
suffix is ".png", then a `PNG format <png_format_>`_ is created, else
|
||||
a `PPM (aka NETPBM) format <ppm_format_>`_ file is created.
|
||||
The JPEG and PNG files are binary; PPM has a text mode header followed
|
||||
by binary data. JPEG images have lossy compression, PNG has lossless
|
||||
compression, and PPM files are uncompressed but can be compressed with
|
||||
gzip, if LAMMPS has been compiled with -DLAMMPS_GZIP and a ".gz" suffix
|
||||
is used.
|
||||
|
||||
.. _jpeg_format: https://jpeg.org/jpeg/
|
||||
.. _png_format: https://en.wikipedia.org/wiki/Portable_Network_Graphics
|
||||
.. _ppm_format: https://en.wikipedia.org/wiki/Netpbm
|
||||
|
||||
Similarly, the format of the resulting movie is chosen with the
|
||||
*movie* dump style. This is handled by the underlying FFmpeg converter
|
||||
and thus details have to be looked up in the FFmpeg documentation.
|
||||
and thus details have to be looked up in the `FFmpeg documentation
|
||||
<http://ffmpeg.org/ffmpeg.html>`_.
|
||||
Typical examples are: .avi, .mpg, .m4v, .mp4, .mkv, .flv, .mov, .gif
|
||||
Additional settings of the movie compression like bitrate and
|
||||
framerate can be set using the :doc:`dump_modify <dump_modify>` command.
|
||||
|
||||
@ -306,7 +306,7 @@ must enclose in quotes if it is more than one field. The *int* and
|
||||
*float* keywords take a single format argument and are applied to all
|
||||
integer or floating-point quantities output. The setting for *M
|
||||
string* also takes a single format argument which is used for the Mth
|
||||
value output in each line, e.g. the 5th column is output in high
|
||||
value output in each line, e.g. the fifth column is output in high
|
||||
precision for "format 5 %20.15g".
|
||||
|
||||
.. note::
|
||||
@ -419,7 +419,7 @@ be written, by processors 0,25,50,75. Each will collect information
|
||||
from itself and the next 24 processors and write it to a dump file.
|
||||
|
||||
For the *fileper* keyword, the specified value of Np means write one
|
||||
file for every Np processors. For example, if Np = 4, every 4th
|
||||
file for every Np processors. For example, if Np = 4, every fourth
|
||||
processor (0,4,8,12,etc) will collect information from itself and the
|
||||
next 3 processors and write it to a dump file.
|
||||
|
||||
@ -790,7 +790,7 @@ for the sequential style; otherwise the value is ignored. It
|
||||
specifies the bin size to use within the range for assigning
|
||||
consecutive colors to. For example, if the range is from -10.0 to
|
||||
10.0 and a *delta* of 1.0 is used, then 20 colors will be assigned to
|
||||
the range. The first will be from -10.0 <= color1 < -9.0, then 2nd
|
||||
the range. The first will be from -10.0 <= color1 < -9.0, then second
|
||||
from -9.0 <= color2 < -8.0, etc.
|
||||
|
||||
The *N* setting is how many entries follow. The format of the entries
|
||||
|
||||
@ -70,7 +70,7 @@ See the :doc:`Build package <Build_package>` doc page for more info.
|
||||
Related commands
|
||||
""""""""""""""""
|
||||
|
||||
:doc:`fix phonon <fix_phonon>`, :doc:`fix numdiff <fix_numdiff>`,
|
||||
:doc:`fix phonon <fix_phonon>`, :doc:`fix numdiff <fix_numdiff>`,
|
||||
|
||||
:doc:`compute hma <compute_hma>` uses an analytic formulation of the
|
||||
Hessian provided by a pair_style's Pair::single_hessian() function,
|
||||
|
||||
@ -229,7 +229,7 @@ specified, but are ignored.
|
||||
|
||||
Similar to the :doc:`pair_coeff command <pair_coeff>`, I and J can be
|
||||
specified in one of two ways. Explicit numeric values can be used for
|
||||
each, as in the 1st example above. I <= J is required. LAMMPS sets
|
||||
each, as in the first example above. I <= J is required. LAMMPS sets
|
||||
the coefficients for the symmetric J,I interaction to the same values.
|
||||
|
||||
A wild-card asterisk can be used in place of or in conjunction with
|
||||
|
||||
@ -199,7 +199,7 @@ specified, but are ignored.
|
||||
|
||||
Similar to the :doc:`pair_coeff command <pair_coeff>`, I and J can be
|
||||
specified in one of two ways. Explicit numeric values can be used for
|
||||
each, as in the 1st example above. I <= J is required. LAMMPS sets
|
||||
each, as in the first example above. I <= J is required. LAMMPS sets
|
||||
the coefficients for the symmetric J,I interaction to the same values.
|
||||
|
||||
A wild-card asterisk can be used in place of or in conjunction with
|
||||
|
||||
@ -435,7 +435,7 @@ column is only used if the *compress* keyword was set to *yes* for the
|
||||
the original chunk IDs (e.g. molecule IDs) will have been compressed
|
||||
to remove chunk IDs with no atoms assigned to them. Thus a compressed
|
||||
chunk ID of 3 may correspond to an original chunk ID or molecule ID of
|
||||
415. The OrigID column will list 415 for the 3rd chunk.
|
||||
415. The OrigID column will list 415 for the third chunk.
|
||||
|
||||
The CoordN columns only appear if a *binning* style was used in the
|
||||
:doc:`compute chunk/atom <compute_chunk_atom>` command. For *bin/1d*\ ,
|
||||
|
||||
@ -321,7 +321,7 @@ accessed on timesteps that are multiples of *Nfreq* since that is when
|
||||
averaging is performed. The global array has # of rows = *Nrepeat*
|
||||
and # of columns = Npair+2. The first column has the time delta (in
|
||||
timesteps) between the pairs of input values used to calculate the
|
||||
correlation, as described above. The 2nd column has the number of
|
||||
correlation, as described above. The second column has the number of
|
||||
samples contributing to the correlation average, as described above.
|
||||
The remaining Npair columns are for I,J pairs of the N input values,
|
||||
as determined by the *type* keyword, as described above.
|
||||
|
||||
@ -346,10 +346,10 @@ values:
|
||||
* 4 = max value of all input values, including ones not histogrammed
|
||||
|
||||
The global array has # of rows = Nbins and # of columns = 3. The
|
||||
first column has the bin coordinate, the 2nd column has the count of
|
||||
values in that histogram bin, and the 3rd column has the bin count
|
||||
first column has the bin coordinate, the second column has the count of
|
||||
values in that histogram bin, and the third column has the bin count
|
||||
divided by the total count (not including missing counts), so that the
|
||||
values in the 3rd column sum to 1.0.
|
||||
values in the third column sum to 1.0.
|
||||
|
||||
The vector and array values calculated by this fix are all treated as
|
||||
intensive. If this is not the case, e.g. due to histogramming
|
||||
|
||||
@ -154,13 +154,13 @@ of type *angletype*\ , with parameters assigned by the corresponding
|
||||
.. note::
|
||||
|
||||
LAMMPS stores and maintains a data structure with a list of the
|
||||
1st, 2nd, and 3rd neighbors of each atom (within the bond topology of
|
||||
first, second, and third neighbors of each atom (within the bond topology of
|
||||
the system) for use in weighting pairwise interactions for bonded
|
||||
atoms. Note that adding a single bond always adds a new 1st neighbor
|
||||
but may also induce \*many\* new 2nd and 3rd neighbors, depending on the
|
||||
atoms. Note that adding a single bond always adds a new first neighbor
|
||||
but may also induce \*many\* new second and third neighbors, depending on the
|
||||
molecular topology of your system. The "extra special per atom"
|
||||
parameter must typically be set to allow for the new maximum total
|
||||
size (1st + 2nd + 3rd neighbors) of this per-atom list. There are 2
|
||||
size (first + second + third neighbors) of this per-atom list. There are 2
|
||||
ways to do this. See the :doc:`read_data <read_data>` or
|
||||
:doc:`create_box <create_box>` commands for details.
|
||||
|
||||
@ -172,12 +172,12 @@ of type *angletype*\ , with parameters assigned by the corresponding
|
||||
considered for pairwise interactions, using the weighting rules set by
|
||||
the :doc:`special_bonds <special_bonds>` command. Consider a new bond
|
||||
created between atoms I,J. If J has a bonded neighbor K, then K
|
||||
becomes a 2nd neighbor of I. Even if the *atype* keyword is not used
|
||||
becomes a second neighbor of I. Even if the *atype* keyword is not used
|
||||
to create angle I-J-K, the pairwise interaction between I and K will
|
||||
be potentially turned off or weighted by the 1-3 weighting specified
|
||||
by the :doc:`special_bonds <special_bonds>` command. This is the case
|
||||
even if the "angle yes" option was used with that command. The same
|
||||
is true for 3rd neighbors (1-4 interactions), the *dtype* keyword, and
|
||||
is true for third neighbors (1-4 interactions), the *dtype* keyword, and
|
||||
the "dihedral yes" option used with the
|
||||
:doc:`special_bonds <special_bonds>` command.
|
||||
|
||||
|
||||
@ -371,7 +371,7 @@ the meaning of the xy,xz,yz tilt factors.
|
||||
|
||||
The *scaleyz yes* and *scalexz yes* keyword/value pairs can not be used
|
||||
for 2D simulations. *scaleyz yes*\ , *scalexz yes*\ , and *scalexy yes* options
|
||||
can only be used if the 2nd dimension in the keyword is periodic,
|
||||
can only be used if the second dimension in the keyword is periodic,
|
||||
and if the tilt factor is not coupled to the barostat via keywords
|
||||
*tri*\ , *yz*\ , *xz*\ , and *xy*\ .
|
||||
|
||||
|
||||
@ -66,7 +66,7 @@ in the body of the data file like this with N lines:
|
||||
N 3 314 315 317 318 330
|
||||
|
||||
The first column is an index from 1 to N to enumerate the CMAP terms;
|
||||
it is ignored by LAMMPS. The 2nd column is the "type" of the
|
||||
it is ignored by LAMMPS. The second column is the "type" of the
|
||||
interaction; it is an index into the CMAP force field file. The
|
||||
remaining 5 columns are the atom IDs of the atoms in the two 4-atom
|
||||
dihedrals that overlap to create the CMAP 5-body interaction. Note
|
||||
|
||||
@ -104,7 +104,7 @@ can be modeled using the :ref:`USER-UEF package <PKG-USER-UEF>` and its :doc:`fi
|
||||
|
||||
For the *x*\ , *y*\ , *z* parameters, the associated dimension cannot be
|
||||
shrink-wrapped. For the *xy*\ , *yz*\ , *xz* parameters, the associated
|
||||
2nd dimension cannot be shrink-wrapped. Dimensions not varied by this
|
||||
second dimension cannot be shrink-wrapped. Dimensions not varied by this
|
||||
command can be periodic or non-periodic. Dimensions corresponding to
|
||||
unspecified parameters can also be controlled by a :doc:`fix npt <fix_nh>` or :doc:`fix nph <fix_nh>` command.
|
||||
|
||||
@ -463,7 +463,7 @@ and the final tilt factor at the end of the simulation would be 0.0.
|
||||
During each flip event, atoms are remapped into the new box in the
|
||||
appropriate manner.
|
||||
|
||||
The one exception to this rule is if the 1st dimension in the tilt
|
||||
The one exception to this rule is if the first dimension in the tilt
|
||||
factor (x for xy) is non-periodic. In that case, the limits on the
|
||||
tilt factor are not enforced, since flipping the box in that dimension
|
||||
does not change the atom positions due to non-periodicity. In this
|
||||
@ -601,7 +601,7 @@ Restrictions
|
||||
You cannot apply x, y, or z deformations to a dimension that is
|
||||
shrink-wrapped via the :doc:`boundary <boundary>` command.
|
||||
|
||||
You cannot apply xy, yz, or xz deformations to a 2nd dimension (y in
|
||||
You cannot apply xy, yz, or xz deformations to a second dimension (y in
|
||||
xy) that is shrink-wrapped via the :doc:`boundary <boundary>` command.
|
||||
|
||||
Related commands
|
||||
|
||||
@ -66,7 +66,7 @@ parenthesized comments):
|
||||
...
|
||||
500 10.0 0.500
|
||||
|
||||
A section begins with a non-blank line whose 1st character is not a
|
||||
A section begins with a non-blank line whose first character is not a
|
||||
"#"; blank lines or lines starting with "#" can be used as comments
|
||||
between sections. The first line begins with a keyword which
|
||||
identifies the section. The line can contain additional text, but the
|
||||
@ -86,8 +86,8 @@ to match exactly what is in the tabulated file (with effectively no
|
||||
preliminary interpolation), you should set Ntable = Nfile.
|
||||
|
||||
Following a blank line, the next N lines list the tabulated values.
|
||||
On each line, the 1st value is the index from 1 to N, the 2nd value is
|
||||
the internal temperature (in temperature units), the 3rd value is the
|
||||
On each line, the first value is the index from 1 to N, the second value is
|
||||
the internal temperature (in temperature units), the third value is the
|
||||
internal energy (in energy units).
|
||||
|
||||
Note that the internal temperature and internal energy values must
|
||||
|
||||
@ -106,7 +106,7 @@ parenthesized comments):
|
||||
...
|
||||
500 10.0 0.500 ... 1.0000
|
||||
|
||||
A section begins with a non-blank line whose 1st character is not a
|
||||
A section begins with a non-blank line whose first character is not a
|
||||
"#"; blank lines or lines starting with "#" can be used as comments
|
||||
between sections. The first line begins with a keyword which
|
||||
identifies the section. The line can contain additional text, but the
|
||||
@ -121,8 +121,8 @@ What LAMMPS does is a preliminary interpolation by creating splines
|
||||
using the Nfile tabulated values as nodal points.
|
||||
|
||||
Following a blank line, the next N lines list the tabulated values.
|
||||
On each line, the 1st value is the index from 1 to N, the 2nd value is
|
||||
the internal temperature (in temperature units), the 3rd value until
|
||||
On each line, the first value is the index from 1 to N, the second value is
|
||||
the internal temperature (in temperature units), the third value until
|
||||
the *m+3* value are the internal energies of the m species (in energy units).
|
||||
|
||||
Note that all internal temperature and internal energy values must
|
||||
|
||||
@ -109,20 +109,42 @@ etc.
|
||||
To use this fix during energy minimization, the energy corresponding
|
||||
to the added forces must also be set so as to be consistent with the
|
||||
added forces. Otherwise the minimization will not converge correctly.
|
||||
Correspondingly, the global virial needs to be updated to be use this
|
||||
fix with variable cell calculations (e.g. :doc:`fix box/relax <fix_box_relax>`
|
||||
or :doc:`fix npt <fix_nh>`).
|
||||
|
||||
This can be done from the external driver by calling this public
|
||||
method of the FixExternal class:
|
||||
This can be done from the external driver by calling these public
|
||||
methods of the FixExternal class:
|
||||
|
||||
.. code-block:: c++
|
||||
|
||||
void set_energy(double eng);
|
||||
void set_energy_global(double eng);
|
||||
void set_virial_global(double *virial);
|
||||
|
||||
where eng is the potential energy. Eng is an extensive quantity,
|
||||
where *eng* is the potential energy, and *virial* an array of the 6
|
||||
stress tensor components. Eng is an extensive quantity,
|
||||
meaning it should be the sum over per-atom energies of all affected
|
||||
atoms. It should also be provided in :doc:`energy units <units>`
|
||||
consistent with the simulation. See the details below for how to
|
||||
insure this energy setting is used appropriately in a minimization.
|
||||
|
||||
Additional public methods that the caller can use to update system
|
||||
properties are:
|
||||
|
||||
.. code-block:: c++
|
||||
|
||||
void set_energy_peratom(double *eng);
|
||||
void set_virial_peratom(double **virial);
|
||||
void set_vector_length(int n);
|
||||
void set_vector(int idx, double val);
|
||||
|
||||
These allow to set per-atom energy contributions, per-atom stress
|
||||
contributions, the length and individual values of a global vector
|
||||
of properties that the caller code may want to communicate to LAMMPS
|
||||
(e.g. for use in :doc:`fix ave/time <fix_ave_time>` or in
|
||||
:doc:`equal-style variables <variable>` or for
|
||||
:doc:`custom thermo output <thermo_style>`.
|
||||
|
||||
----------
|
||||
|
||||
**Restart, fix_modify, output, run start/stop, minimize info:**
|
||||
|
||||
@ -432,7 +432,7 @@ equilibrium liquids can not support a shear stress and that
|
||||
equilibrium solids can not support shear stresses that exceed the
|
||||
yield stress.
|
||||
|
||||
One exception to this rule is if the 1st dimension in the tilt factor
|
||||
One exception to this rule is if the first dimension in the tilt factor
|
||||
(x for xy) is non-periodic. In that case, the limits on the tilt
|
||||
factor are not enforced, since flipping the box in that dimension does
|
||||
not change the atom positions due to non-periodicity. In this mode,
|
||||
@ -673,7 +673,7 @@ Restrictions
|
||||
|
||||
*X*\ , *y*\ , *z* cannot be barostatted if the associated dimension is not
|
||||
periodic. *Xy*\ , *xz*\ , and *yz* can only be barostatted if the
|
||||
simulation domain is triclinic and the 2nd dimension in the keyword
|
||||
simulation domain is triclinic and the second dimension in the keyword
|
||||
(\ *y* dimension in *xy*\ ) is periodic. *Z*\ , *xz*\ , and *yz*\ , cannot be
|
||||
barostatted for 2D simulations. The :doc:`create_box <create_box>`,
|
||||
:doc:`read data <read_data>`, and :doc:`read_restart <read_restart>`
|
||||
@ -687,7 +687,7 @@ is not allowed in the Nose/Hoover formulation.
|
||||
|
||||
The *scaleyz yes* and *scalexz yes* keyword/value pairs can not be used
|
||||
for 2D simulations. *scaleyz yes*\ , *scalexz yes*\ , and *scalexy yes* options
|
||||
can only be used if the 2nd dimension in the keyword is periodic,
|
||||
can only be used if the second dimension in the keyword is periodic,
|
||||
and if the tilt factor is not coupled to the barostat via keywords
|
||||
*tri*\ , *yz*\ , *xz*\ , and *xy*\ .
|
||||
|
||||
@ -710,7 +710,7 @@ Default
|
||||
|
||||
The keyword defaults are tchain = 3, pchain = 3, mtk = yes, tloop = 1,
|
||||
ploop = 1, nreset = 0, drag = 0.0, dilate = all, couple = none,
|
||||
flip = yes, scaleyz = scalexz = scalexy = yes if periodic in 2nd
|
||||
flip = yes, scaleyz = scalexz = scalexy = yes if periodic in second
|
||||
dimension and not coupled to barostat, otherwise no.
|
||||
|
||||
----------
|
||||
|
||||
@ -354,7 +354,7 @@ equilibrium liquids can not support a shear stress and that
|
||||
equilibrium solids can not support shear stresses that exceed the
|
||||
yield stress.
|
||||
|
||||
One exception to this rule is if the 1st dimension in the tilt factor
|
||||
One exception to this rule is if the first dimension in the tilt factor
|
||||
(x for xy) is non-periodic. In that case, the limits on the tilt
|
||||
factor are not enforced, since flipping the box in that dimension does
|
||||
not change the atom positions due to non-periodicity. In this mode,
|
||||
@ -555,7 +555,7 @@ LAMMPS was built with that package. See the :doc:`Build package <Build_package>
|
||||
|
||||
*X*\ , *y*\ , *z* cannot be barostatted if the associated dimension is not
|
||||
periodic. *Xy*\ , *xz*\ , and *yz* can only be barostatted if the
|
||||
simulation domain is triclinic and the 2nd dimension in the keyword
|
||||
simulation domain is triclinic and the second dimension in the keyword
|
||||
(\ *y* dimension in *xy*\ ) is periodic. *Z*\ , *xz*\ , and *yz*\ , cannot be
|
||||
barostatted for 2D simulations. The :doc:`create_box <create_box>`,
|
||||
:doc:`read data <read_data>`, and :doc:`read_restart <read_restart>`
|
||||
@ -569,7 +569,7 @@ is not allowed in the Nose/Hoover formulation.
|
||||
|
||||
The *scaleyz yes* and *scalexz yes* keyword/value pairs can not be used
|
||||
for 2D simulations. *scaleyz yes*\ , *scalexz yes*\ , and *scalexy yes* options
|
||||
can only be used if the 2nd dimension in the keyword is periodic,
|
||||
can only be used if the second dimension in the keyword is periodic,
|
||||
and if the tilt factor is not coupled to the barostat via keywords
|
||||
*tri*\ , *yz*\ , *xz*\ , and *xy*\ .
|
||||
|
||||
@ -626,7 +626,7 @@ Default
|
||||
The keyword defaults are tchain = 3, pchain = 3, mtk = yes, tloop =
|
||||
ploop = 1, nreset = 0, drag = 0.0, dilate = all, couple = none,
|
||||
cauchystat = no,
|
||||
scaleyz = scalexz = scalexy = yes if periodic in 2nd dimension and
|
||||
scaleyz = scalexz = scalexy = yes if periodic in second dimension and
|
||||
not coupled to barostat, otherwise no.
|
||||
|
||||
----------
|
||||
|
||||
@ -39,7 +39,7 @@ useful for treating a large biomolecule as a collection of connected,
|
||||
coarse-grained particles.
|
||||
|
||||
The coupling, associated motion constraints, and time integration is
|
||||
performed by the software package `Parallelizable Open source Efficient Multibody Software (POEMS) <poems_>`_ which computes the
|
||||
performed by the software package `Parallelizable Open source Efficient Multibody Software (POEMS)` which computes the
|
||||
constrained rigid-body motion of articulated (jointed) multibody
|
||||
systems :ref:`(Anderson) <Anderson>`. POEMS was written and is distributed
|
||||
by Prof Kurt Anderson, his graduate student Rudranarayan Mukherjee,
|
||||
@ -48,8 +48,6 @@ and other members of his group at Rensselaer Polytechnic Institute
|
||||
copyright information on POEMS and other details, please refer to the
|
||||
documents in the poems directory distributed with LAMMPS.
|
||||
|
||||
.. _poems: http://www.rpi.edu/~anderk5/lab
|
||||
|
||||
This fix updates the positions and velocities of the rigid atoms with
|
||||
a constant-energy time integration, so you should not update the same
|
||||
atoms via other fixes (e.g. nve, nvt, npt, temp/rescale, langevin).
|
||||
@ -123,7 +121,7 @@ command. This fix is not invoked during :doc:`energy minimization <minimize>`.
|
||||
Restrictions
|
||||
""""""""""""
|
||||
|
||||
This fix is part of the POEMS package. It is only enabled if LAMMPS
|
||||
This fix is part of the :ref:`POEMS <PKG-POEMS>` package. It is only enabled if LAMMPS
|
||||
was built with that package, which also requires the POEMS library be
|
||||
built and linked with LAMMPS. See the :doc:`Build package <Build_package>` doc page for more info.
|
||||
|
||||
|
||||
@ -158,7 +158,7 @@ atom_style "spin" was declared. See the :doc:`Build package <Build_package>` do
|
||||
The *precession/spin* style can only be declared once. If more
|
||||
than one precession type (for example combining an anisotropy and a Zeeman interactions)
|
||||
has to be declared, they have to be chained in the same command
|
||||
line (as shown in the examples above).
|
||||
line (as shown in the examples above).
|
||||
|
||||
Related commands
|
||||
""""""""""""""""
|
||||
|
||||
@ -116,7 +116,7 @@ Restrictions
|
||||
""""""""""""
|
||||
|
||||
This fix should not be used with an x,y,z setting that causes a large
|
||||
shift in the system on the 1st timestep, due to the requested COM
|
||||
shift in the system on the first timestep, due to the requested COM
|
||||
being very different from the initial COM. This could cause atoms to
|
||||
be lost, especially in parallel. Instead, use the
|
||||
:doc:`displace_atoms <displace_atoms>` command, which can be used to
|
||||
|
||||
@ -162,7 +162,7 @@ the restraint is
|
||||
.. math::
|
||||
|
||||
E = 0 \qquad\quad\quad ,if\;r \ge r_0
|
||||
|
||||
|
||||
with the following coefficients:
|
||||
|
||||
* :math:`K` (energy/distance\^2)
|
||||
|
||||
@ -248,7 +248,7 @@ differences may accumulate to produce divergent trajectories.
|
||||
will be built only at the very first *run* command and maintained for
|
||||
as long as the rigid fix is defined. For example, you might think you
|
||||
could displace the atoms in a body or add a large velocity to each atom
|
||||
in a body to make it move in a desired direction before a 2nd run is
|
||||
in a body to make it move in a desired direction before a second run is
|
||||
performed, using the :doc:`set <set>` or
|
||||
:doc:`displace_atoms <displace_atoms>` or :doc:`velocity <velocity>`
|
||||
commands. But these commands will not affect the internal attributes
|
||||
@ -727,7 +727,7 @@ In all case, the rigid bodies and non-rigid particles both contribute
|
||||
to the global pressure and the box is scaled the same by any of the
|
||||
barostatting fixes.
|
||||
|
||||
You could even use the 2nd and 3rd options for a non-hybrid simulation
|
||||
You could even use the second and third options for a non-hybrid simulation
|
||||
consisting of only rigid bodies, assuming you give :doc:`fix npt <fix_nh>` an empty group, though it's an odd thing to do. The
|
||||
barostatting fixes (:doc:`fix npt <fix_nh>` and :doc:`fix press/berensen <fix_press_berendsen>`) will monitor the pressure
|
||||
and change the box dimensions, but not time integrate any particles.
|
||||
|
||||
@ -108,7 +108,7 @@ internal energy and extrapolated velocity are also updated.
|
||||
will be built only at the very first *run* command and maintained for
|
||||
as long as the rigid fix is defined. For example, you might think you
|
||||
could displace the particles in a body or add a large velocity to each particle
|
||||
in a body to make it move in a desired direction before a 2nd run is
|
||||
in a body to make it move in a desired direction before a second run is
|
||||
performed, using the :doc:`set <set>` or
|
||||
:doc:`displace_atoms <displace_atoms>` or :doc:`velocity <velocity>`
|
||||
commands. But these commands will not affect the internal attributes
|
||||
|
||||
@ -18,7 +18,7 @@ Syntax
|
||||
* file = filename containing the reaction kinetic equations and Arrhenius parameters
|
||||
* localTemp = *none,lucy* = no local temperature averaging or local temperature defined through Lucy weighting function
|
||||
* matrix = *sparse, dense* format for the stoichiometric matrix
|
||||
* solver = *lammps_rk4,rkf45* = rk4 is an explicit 4th order Runge-Kutta method; rkf45 is an adaptive 4th-order Runge-Kutta-Fehlberg method
|
||||
* solver = *lammps_rk4,rkf45* = rk4 is an explicit fourth order Runge-Kutta method; rkf45 is an adaptive fourth-order Runge-Kutta-Fehlberg method
|
||||
* minSteps = # of steps for rk4 solver or minimum # of steps for rkf45 (rk4 or rkf45)
|
||||
* maxSteps = maximum number of steps for the rkf45 solver (rkf45 only)
|
||||
* relTol = relative tolerance for the rkf45 solver (rkf45 only)
|
||||
@ -61,9 +61,9 @@ of *m* ordinary differential equations (ODEs) that describe the change
|
||||
in concentration of a given species as a function of time are then
|
||||
constructed based on the *n* reaction rate equations.
|
||||
|
||||
The ODE systems are solved over the full DPD timestep *dt* using either a 4th
|
||||
The ODE systems are solved over the full DPD timestep *dt* using either a fourth
|
||||
order Runge-Kutta *rk4* method with a fixed step-size *h*\ , specified
|
||||
by the *lammps_rk4* keyword, or a 4th order Runge-Kutta-Fehlberg (rkf45) method
|
||||
by the *lammps_rk4* keyword, or a fourth order Runge-Kutta-Fehlberg (rkf45) method
|
||||
with an adaptive step-size for *h*\ . The number of ODE steps per DPD timestep
|
||||
for the rk4 method is optionally specified immediately after the rk4
|
||||
keyword. The ODE step-size is set as *dt/num_steps*. Smaller
|
||||
@ -76,7 +76,7 @@ can be specified by the user or estimated internally. It is recommended that the
|
||||
specify *h0* since this will generally reduced the number of ODE integration steps
|
||||
required. *h0* is defined as *dt / min_steps* if min_steps >= 1. If min_steps == 0,
|
||||
*h0* is estimated such that an explicit Euler method would likely produce
|
||||
an acceptable solution. This is generally overly conservative for the 4th-order
|
||||
an acceptable solution. This is generally overly conservative for the fourth-order
|
||||
method and users are advised to specify *h0* as some fraction of the DPD timestep.
|
||||
For small DPD timesteps, only one step may be necessary depending upon the tolerances.
|
||||
Note that more than min_steps ODE steps may be taken depending upon the ODE stiffness
|
||||
@ -172,7 +172,7 @@ parenthesized comments):
|
||||
...
|
||||
1.0 no + 1.0 co = 0.5 n2 + 1.0 co2 1.66E+06 0.0 0.69
|
||||
|
||||
A section begins with a non-blank line whose 1st character is not a
|
||||
A section begins with a non-blank line whose first character is not a
|
||||
"#"; blank lines or lines starting with "#" can be used as comments
|
||||
between sections.
|
||||
|
||||
|
||||
@ -45,7 +45,7 @@ Description
|
||||
"""""""""""
|
||||
|
||||
Time average computed intensities from :doc:`compute saed <compute_saed>` and
|
||||
write output to a file in the 3rd generation vtk image data format for
|
||||
write output to a file in the third generation vtk image data format for
|
||||
visualization directly in parallelized visualization software packages
|
||||
like ParaView and VisIt. Note that if no time averaging is done, this
|
||||
command can be used as a convenient way to simply output diffraction
|
||||
@ -92,7 +92,7 @@ averaging is done; values are simply generated on timesteps
|
||||
|
||||
----------
|
||||
|
||||
The output for fix ave/time/saed is a file written with the 3rd generation
|
||||
The output for fix ave/time/saed is a file written with the third generation
|
||||
vtk image data formatting. The filename assigned by the *file* keyword is
|
||||
appended with _N.vtk where N is an index (0,1,2...) to account for multiple
|
||||
diffraction intensity outputs.
|
||||
@ -156,7 +156,7 @@ running or windowed average.
|
||||
|
||||
The *file* keyword allows a filename to be specified. Every *Nfreq*
|
||||
steps, the vector of saed intensity data is written to a new file using
|
||||
the 3rd generation vtk format. The base of each file is assigned by
|
||||
the third generation vtk format. The base of each file is assigned by
|
||||
the *file* keyword and this string is appended with _N.vtk where N is
|
||||
an index (0,1,2...) to account for situations with multiple diffraction
|
||||
intensity outputs.
|
||||
|
||||
@ -126,7 +126,7 @@ displacement).
|
||||
|
||||
The force is the total force on the group of atoms by the spring. In
|
||||
the case of the *couple* style, it is the force on the fix group
|
||||
(group-ID) or the negative of the force on the 2nd group (group-ID2).
|
||||
(group-ID) or the negative of the force on the second group (group-ID2).
|
||||
The vector values calculated by this fix are "extensive".
|
||||
|
||||
No parameter of this fix can be used with the *start/stop* keywords of
|
||||
|
||||
@ -118,7 +118,7 @@ various :doc:`output commands <Howto_output>`. The first 3 quantities
|
||||
in the vector are xyz components of the total force added to the group
|
||||
of atoms by the spring. In the case of the *couple* style, it is the
|
||||
force on the fix group (group-ID) or the negative of the force on the
|
||||
2nd group (group-ID2). The 4th quantity in the vector is the
|
||||
second group (group-ID2). The fourth quantity in the vector is the
|
||||
magnitude of the force added by the spring, as a positive value if
|
||||
(r-R0) > 0 and a negative value if (r-R0) < 0. This sign convention
|
||||
can be useful when using the spring force to compute a potential of
|
||||
|
||||
@ -55,8 +55,8 @@ a .gz suffix). The format of the target file1 is as follows:
|
||||
|
||||
The first 3 lines may or may not be needed, depending on the format of
|
||||
the atoms to follow. If image flags are included with the atoms, the
|
||||
1st 3 lo/hi lines must appear in the file. If image flags are not
|
||||
included, the 1st 3 lines should not appear. The 3 lines contain the
|
||||
first 3 lo/hi lines must appear in the file. If image flags are not
|
||||
included, the first 3 lines should not appear. The 3 lines contain the
|
||||
simulation box dimensions for the atom coordinates, in the same format
|
||||
as in a LAMMPS data file (see the :doc:`read_data <read_data>` command).
|
||||
|
||||
|
||||
@ -118,7 +118,7 @@ specified atom types, atom IDs, or molecule IDs into the group. These
|
||||
3 styles can use arguments specified in one of two formats.
|
||||
|
||||
The first format is a list of values (types or IDs). For example, the
|
||||
2nd command in the examples above puts all atoms of type 3 or 4 into
|
||||
second command in the examples above puts all atoms of type 3 or 4 into
|
||||
the group named *water*\ . Each entry in the list can be a
|
||||
colon-separated sequence A:B or A:B:C, as in two of the examples
|
||||
above. A "sequence" generates a sequence of values (types or IDs),
|
||||
@ -131,9 +131,9 @@ uses an increment of 10 and would thus would add atoms IDs
|
||||
|
||||
The second format is a *logical* followed by one or two values (type
|
||||
or ID). The 7 valid logicals are listed above. All the logicals
|
||||
except <> take a single argument. The 3rd example above adds all
|
||||
except <> take a single argument. The third example above adds all
|
||||
atoms with IDs from 1 to 150 to the group named *sub*\ . The logical <>
|
||||
means "between" and takes 2 arguments. The 4th example above adds all
|
||||
means "between" and takes 2 arguments. The fourth example above adds all
|
||||
atoms belonging to molecules with IDs from 50 to 250 (inclusive) to
|
||||
the group named polyA.
|
||||
|
||||
@ -192,7 +192,7 @@ this operation is useful is if the *region* style has been used
|
||||
previously to add atoms to a group that are within a geometric region.
|
||||
If molecules straddle the region boundary, then atoms outside the
|
||||
region that are part of molecules with atoms inside the region will
|
||||
not be in the group. Using the group command a 2nd time with *include
|
||||
not be in the group. Using the group command a second time with *include
|
||||
molecule* will add those atoms that are outside the region to the
|
||||
group.
|
||||
|
||||
@ -207,7 +207,7 @@ group.
|
||||
atoms, and P is the number of processors.
|
||||
|
||||
The *subtract* style takes a list of two or more existing group names
|
||||
as arguments. All atoms that belong to the 1st group, but not to any
|
||||
as arguments. All atoms that belong to the first group, but not to any
|
||||
of the other groups are added to the specified group.
|
||||
|
||||
The *union* style takes a list of one or more existing group names as
|
||||
|
||||
@ -48,7 +48,7 @@ the :doc:`read_data <read_data>` command) are ordered I,J,K,L.
|
||||
the plane of J,K,L, and the bond JK lies in both planes. Similarly for
|
||||
:math:`\chi_{kjli}` and :math:`\chi_{ljik}`.
|
||||
Note that atom J appears in the common bonds (JI, JK, JL) of all 3 X
|
||||
terms. Thus J (the 2nd atom in the quadruplet) is the atom of
|
||||
terms. Thus J (the second atom in the quadruplet) is the atom of
|
||||
symmetry in the 3 :math:`\chi` angles.
|
||||
|
||||
The subscripts on the various :math:`\theta`\ s refer to different
|
||||
@ -56,7 +56,7 @@ combinations of 3 atoms (I,J,K,L) used to form a particular angle.
|
||||
E.g. :math:`\theta_{ijl}` is the angle formed by atoms I,J,L with J
|
||||
in the middle. :math:`\theta_1`, :math:`\theta_2`, :math:`\theta_3`
|
||||
are the equilibrium positions of those angles. Again,
|
||||
atom J (the 2nd atom in the quadruplet) is the atom of symmetry in the
|
||||
atom J (the second atom in the quadruplet) is the atom of symmetry in the
|
||||
theta angles, since it is always the center atom.
|
||||
|
||||
Since atom J is the atom of symmetry, normally the bonds J-I, J-K, J-L
|
||||
|
||||
@ -32,7 +32,7 @@ file read by the :doc:`read_data <read_data>` command or in a restart
|
||||
file.
|
||||
|
||||
N can be specified in one of two ways. An explicit numeric value can
|
||||
be used, as in the 1st example above. Or a wild-card asterisk can be
|
||||
be used, as in the first example above. Or a wild-card asterisk can be
|
||||
used to set the coefficients for multiple improper types. This takes
|
||||
the form "\*" or "\*n" or "n\*" or "m\*n". If N = the number of improper
|
||||
types, then an asterisk with no numeric values means all types from 1
|
||||
@ -55,7 +55,7 @@ exact same format as the arguments of the improper_coeff command in an
|
||||
input script, except that wild-card asterisks should not be used since
|
||||
coefficients for all N types must be listed in the file. For example,
|
||||
under the "Improper Coeffs" section of a data file, the line that
|
||||
corresponds to the 1st example above would be listed as
|
||||
corresponds to the first example above would be listed as
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
|
||||
@ -48,7 +48,7 @@ to other hybrid styles, use the style name (e.g. "harmonic")
|
||||
appropriate to that style. The AngleAngle coeffs for that improper
|
||||
type will then be ignored.
|
||||
|
||||
An improper style of *none* can be specified as the 2nd argument to
|
||||
An improper style of *none* can be specified as the second argument to
|
||||
the improper_coeff command, if you desire to turn off certain improper
|
||||
types.
|
||||
|
||||
|
||||
@ -60,7 +60,7 @@ of SELF, e.g.
|
||||
|
||||
lmp_g++ -var fname in.script < in.script
|
||||
|
||||
The 2nd argument to the jump command is optional. If specified, it is
|
||||
The second argument to the jump command is optional. If specified, it is
|
||||
treated as a label and the new file is scanned (without executing
|
||||
commands) until the label is found, and commands are executed from
|
||||
that point forward. This can be used to loop over a portion of the
|
||||
|
||||
@ -163,7 +163,7 @@ The *pppm/dipole/spin* style invokes a particle-particle particle-mesh solver
|
||||
for magnetic dipole-dipole interactions between magnetic spins.
|
||||
|
||||
The *pppm/tip4p* style is identical to the *pppm* style except that it
|
||||
adds a charge at the massless 4th site in each TIP4P water molecule.
|
||||
adds a charge at the massless fourth site in each TIP4P water molecule.
|
||||
It should be used with :doc:`pair styles <pair_style>` with a
|
||||
*tip4p/long* in their style name.
|
||||
|
||||
|
||||
@ -31,7 +31,7 @@ using the "Masses" keyword. See the :doc:`units <units>` command for
|
||||
what mass units to use.
|
||||
|
||||
The I index can be specified in one of two ways. An explicit numeric
|
||||
value can be used, as in the 1st example above. Or a wild-card
|
||||
value can be used, as in the first example above. Or a wild-card
|
||||
asterisk can be used to set the mass for multiple atom types. This
|
||||
takes the form "\*" or "\*n" or "n\*" or "m\*n". If N = the number of
|
||||
atom types, then an asterisk with no numeric values means all types
|
||||
@ -44,7 +44,7 @@ A line in a :doc:`data file <read_data>` that follows the "Masses"
|
||||
keyword specifies mass using the same format as the arguments of the
|
||||
mass command in an input script, except that no wild-card asterisk can
|
||||
be used. For example, under the "Masses" section of a data file, the
|
||||
line that corresponds to the 1st example above would be listed as
|
||||
line that corresponds to the first example above would be listed as
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
|
||||
@ -178,7 +178,7 @@ processing the rest of its input script after client/server
|
||||
communication terminates.
|
||||
|
||||
If both codes cooperate in this manner, a new round of client/server
|
||||
messaging can be initiated after termination by re-using a 2nd message
|
||||
messaging can be initiated after termination by re-using a second message
|
||||
command in your LAMMPS input script, followed by a new fix client or
|
||||
server command, followed by another message quit command (if LAMMPS is
|
||||
the client). As an example, this can be performed in a loop to use a
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user