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

Merge branch 'lammps:develop' into create_atoms-overlap_w_mol

Browse Source
This commit is contained in:
Jacob Gissinger
2024-01-10 19:55:18 -05:00
committed by GitHub
parent 3e2d5098c0 7ca2dcac62
commit 60f1233b07
3430 changed files with 199703 additions and 150526 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
doc/src/Bibliography.rst
View File

@ -203,7 +203,7 @@ Bibliography
A Caro, DA Crowson, M Caro; Phys Rev Lett, 95, 075702 (2005)
**(CasP)**
CasP webpage: https://www.helmholtz-berlin.de/people/gregor-schiwietz/casp_en.html
CasP webpage: http://www.casp-program.org/
**(Cawkwell2012)**
A.\ M. N. Niklasson, M. J. Cawkwell, Phys. Rev. B, 86 (17), 174308 (2012).
@ -562,6 +562,9 @@ Bibliography
**(Kumar)**
Kumar and Skinner, J. Phys. Chem. B, 112, 8311 (2008)
**(Lafourcade)**
Lafourcade, Maillet, Denoual, Duval, Allera, Goryaeva, and Marinica, `Comp. Mat. Science, 230, 112534 (2023) <https://doi.org/10.1016/j.commatsci.2023.112534>`_
**(Lamoureux and Roux)**
G.\ Lamoureux, B. Roux, J. Chem. Phys 119, 3025 (2003)

23
doc/src/Build_basics.rst
View File

@ -90,7 +90,7 @@ standard. A more detailed discussion of that is below.
directory, or ``make`` from the ``src/STUBS`` dir. If the build
fails, you may need to edit the ``STUBS/Makefile`` for your
platform. The stubs library does not provide MPI/IO functions
required by some LAMMPS packages, e.g. ``MPIIO`` or ``LATBOLTZ``,
required by some LAMMPS packages, e.g. ``LATBOLTZ``,
and thus is not compatible with those packages.
.. note::
@ -128,14 +128,13 @@ and adds vectorization support when compiled with compatible compilers,
in particular the Intel compilers on top of OpenMP. Also, the ``KOKKOS``
package can be compiled to include OpenMP threading.
In addition, there are a few commands in LAMMPS that have native
OpenMP support included as well. These are commands in the ``MPIIO``,
``ML-SNAP``, ``DIFFRACTION``, and ``DPD-REACT`` packages.
Furthermore, some packages support OpenMP threading indirectly through
the libraries they interface to: e.g. ``KSPACE``, and ``COLVARS``.
See the :doc:`Packages details <Packages_details>` page for more info
on these packages, and the pages for their respective commands for
OpenMP threading info.
In addition, there are a few commands in LAMMPS that have native OpenMP
support included as well. These are commands in the ``ML-SNAP``,
``DIFFRACTION``, and ``DPD-REACT`` packages. Furthermore, some packages
support OpenMP threading indirectly through the libraries they interface
to: e.g. ``KSPACE``, and ``COLVARS``. See the :doc:`Packages details
<Packages_details>` page for more info on these packages, and the pages
for their respective commands for OpenMP threading info.
For CMake, if you use ``BUILD_OMP=yes``, you can use these packages
and turn on their native OpenMP support and turn on their native OpenMP
@ -489,8 +488,9 @@ using CMake or Make.
.. code-block:: bash
-D BUILD_TOOLS=value # yes or no (default)
-D BUILD_LAMMPS_SHELL=value # yes or no (default)
-D BUILD_TOOLS=value # yes or no (default). Build binary2txt, chain.x, micelle2d.x, msi2lmp, phana, stl_bin2txt
-D BUILD_LAMMPS_SHELL=value # yes or no (default). Build lammps-shell
-D BUILD_LAMMPS_GUI=value # yes or no (default). Build lammps-gui
The generated binaries will also become part of the LAMMPS installation
(see below).
@ -504,7 +504,6 @@ using CMake or Make.
make binary2txt # build only binary2txt tool
make chain # build only chain tool
make micelle2d # build only micelle2d tool
make thermo_extract # build only thermo_extract tool
cd lammps/tools/lammps-shell
make # build LAMMPS shell

30
doc/src/Build_cmake.rst
View File

@ -16,8 +16,7 @@ environments is on a :doc:`separate page <Howto_cmake>`.
.. note::
LAMMPS currently requires that CMake version 3.10 or later is available;
version 3.12 or later is preferred.
LAMMPS currently requires that CMake version 3.16 or later is available.
.. warning::
@ -34,19 +33,18 @@ Advantages of using CMake
^^^^^^^^^^^^^^^^^^^^^^^^^
CMake is an alternative to compiling LAMMPS in the traditional way
through :doc:`(manually customized) makefiles <Build_make>` and a recent
addition to LAMMPS thanks to the efforts of Christoph Junghans (LANL)
and Richard Berger (Temple U). Using CMake has multiple advantages that
are specifically helpful for people with limited experience in compiling
software or for people that want to modify or extend LAMMPS.
through :doc:`(manually customized) makefiles <Build_make>`. Using
CMake has multiple advantages that are specifically helpful for
people with limited experience in compiling software or for people
that want to modify or extend LAMMPS.
- CMake can detect available hardware, tools, features, and libraries
and adapt the LAMMPS default build configuration accordingly.
- CMake can generate files for different build tools and integrated
development environments (IDE).
- CMake supports customization of settings with a command line, text
mode, or graphical user interface. No knowledge of file formats or
complex command line syntax is required.
mode, or graphical user interface. No manual editing of files,
knowledge of file formats or complex command line syntax is required.
- All enabled components are compiled in a single build operation.
- Automated dependency tracking for all files and configuration options.
- Support for true out-of-source compilation. Multiple configurations
@ -179,13 +177,13 @@ configuration is selected with the *-C* flag:
ctest -C Debug
The CMake scripts in LAMMPS have basic support for being compiled using a
multi-config build system, but not all of it has been ported. This is in
particular applicable to compiling packages that require additional libraries
that would be downloaded and compiled by CMake. The "windows" preset file
tries to keep track of which packages can be compiled natively with the
MSVC compilers out-of-the box. Not all of those external libraries are
portable to Windows, either.
The CMake scripts in LAMMPS have basic support for being compiled using
a multi-config build system, but not all of it has been ported. This is
in particular applicable to compiling packages that require additional
libraries that would be downloaded and compiled by CMake. The
``windows.cmake`` preset file tries to keep track of which packages can
be compiled natively with the MSVC compilers out-of-the box. Not all of
the external libraries are portable to Windows, either.
Installing CMake

43
doc/src/Build_development.rst
View File

@ -255,16 +255,18 @@ A test run is then a a collection multiple individual test runs each
with many comparisons to reference results based on template input
files, individual command settings, relative error margins, and
reference data stored in a YAML format file with ``.yaml``
suffix. Currently the programs ``test_pair_style``, ``test_bond_style``, and
``test_angle_style`` are implemented. They will compare forces, energies and
(global) stress for all atoms after a ``run 0`` calculation and after a
few steps of MD with :doc:`fix nve <fix_nve>`, each in multiple variants
with different settings and also for multiple accelerated styles. If a
prerequisite style or package is missing, the individual tests are
skipped. All tests will be executed on a single MPI process, so using
the CMake option ``-D BUILD_MPI=off`` can significantly speed up testing,
since this will skip the MPI initialization for each test run.
Below is an example command and output:
suffix. Currently the programs ``test_pair_style``, ``test_bond_style``,
``test_angle_style``, ``test_dihedral_style``, and
``test_improper_style`` are implemented. They will compare forces,
energies and (global) stress for all atoms after a ``run 0`` calculation
and after a few steps of MD with :doc:`fix nve <fix_nve>`, each in
multiple variants with different settings and also for multiple
accelerated styles. If a prerequisite style or package is missing, the
individual tests are skipped. All force style tests will be executed on
a single MPI process, so using the CMake option ``-D BUILD_MPI=off`` can
significantly speed up testing, since this will skip the MPI
initialization for each test run. Below is an example command and
output:
.. code-block:: console
@ -416,15 +418,16 @@ When compiling LAMMPS with enabled tests, most test executables will
need to be linked against the LAMMPS library. Since this can be a very
large library with many C++ objects when many packages are enabled, link
times can become very long on machines that use the GNU BFD linker (e.g.
Linux systems). Alternatives like the ``lld`` linker of the LLVM project
or the ``gold`` linker available with GNU binutils can speed up this step
substantially. CMake will by default test if any of the two can be
enabled and use it when ``ENABLE_TESTING`` is active. It can also be
selected manually through the ``CMAKE_CUSTOM_LINKER`` CMake variable.
Allowed values are ``lld``, ``gold``, ``bfd``, or ``default``. The
``default`` option will use the system default linker otherwise, the
linker is chosen explicitly. This option is only available for the
GNU or Clang C++ compiler.
Linux systems). Alternatives like the ``mold`` linker, the ``lld``
linker of the LLVM project, or the ``gold`` linker available with GNU
binutils can speed up this step substantially (in this order). CMake
will by default test if any of the three can be enabled and use it when
``ENABLE_TESTING`` is active. It can also be selected manually through
the ``CMAKE_CUSTOM_LINKER`` CMake variable. Allowed values are
``mold``, ``lld``, ``gold``, ``bfd``, or ``default``. The ``default``
option will use the system default linker otherwise, the linker is
chosen explicitly. This option is only available for the GNU or Clang
C++ compilers.
Tests for other components and utility functions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -518,6 +521,8 @@ The following options are available.
make fix-errordocs # remove error docs in header files
make check-permissions # search for files with permissions issues
make fix-permissions # correct permissions issues in files
make check-docs # search for several issues in the manual
make check-version # list files with pending release version tags
make check # run all check targets from above
These should help to make source and documentation files conforming

343
doc/src/Build_extras.rst
View File

@ -52,7 +52,6 @@ This is the list of packages that may require additional steps.
* :ref:`ML-POD <ml-pod>`
* :ref:`ML-QUIP <ml-quip>`
* :ref:`MOLFILE <molfile>`
* :ref:`MSCG <mscg>`
* :ref:`NETCDF <netcdf>`
* :ref:`OPENMP <openmp>`
* :ref:`OPT <opt>`
@ -140,6 +139,8 @@ CMake build
# value = yes or no (default)
-D CUDA_MPS_SUPPORT=value # enables some tweaks required to run with active nvidia-cuda-mps daemon
# value = yes or no (default)
-D CUDA_BUILD_MULTIARCH=value # enables building CUDA kernels for all supported GPU architectures
# value = yes (default) or no
-D USE_STATIC_OPENCL_LOADER=value # downloads/includes OpenCL ICD loader library, no local OpenCL headers/libs needed
# value = yes (default) or no
@ -158,41 +159,49 @@ CMake build
A more detailed list can be found, for example,
at `Wikipedia's CUDA article <https://en.wikipedia.org/wiki/CUDA#GPUs_supported>`_
CMake can detect which version of the CUDA toolkit is used and thus will try
to include support for **all** major GPU architectures supported by this toolkit.
Thus the GPU_ARCH setting is merely an optimization, to have code for
the preferred GPU architecture directly included rather than having to wait
for the JIT compiler of the CUDA driver to translate it.
CMake can detect which version of the CUDA toolkit is used and thus will
try to include support for **all** major GPU architectures supported by
this toolkit. Thus the GPU_ARCH setting is merely an optimization, to
have code for the preferred GPU architecture directly included rather
than having to wait for the JIT compiler of the CUDA driver to translate
it. This behavior can be turned off (e.g. to speed up compilation) by
setting :code:`CUDA_ENABLE_MULTIARCH` to :code:`no`.
When compiling for CUDA or HIP with CUDA, version 8.0 or later of the CUDA toolkit
is required and a GPU architecture of Kepler or later, which must *also* be
supported by the CUDA toolkit in use **and** the CUDA driver in use.
When compiling for OpenCL, OpenCL version 1.2 or later is required and the
GPU must be supported by the GPU driver and OpenCL runtime bundled with the driver.
When compiling for CUDA or HIP with CUDA, version 8.0 or later of the
CUDA toolkit is required and a GPU architecture of Kepler or later,
which must *also* be supported by the CUDA toolkit in use **and** the
CUDA driver in use. When compiling for OpenCL, OpenCL version 1.2 or
later is required and the GPU must be supported by the GPU driver and
OpenCL runtime bundled with the driver.
When building with CMake, you **must NOT** build the GPU library in ``lib/gpu``
using the traditional build procedure. CMake will detect files generated by that
process and will terminate with an error and a suggestion for how to remove them.
When building with CMake, you **must NOT** build the GPU library in
``lib/gpu`` using the traditional build procedure. CMake will detect
files generated by that process and will terminate with an error and a
suggestion for how to remove them.
If you are compiling for OpenCL, the default setting is to download, build, and
link with a static OpenCL ICD loader library and standard OpenCL headers. This
way no local OpenCL development headers or library needs to be present and only
OpenCL compatible drivers need to be installed to use OpenCL. If this is not
desired, you can set :code:`USE_STATIC_OPENCL_LOADER` to :code:`no`.
If you are compiling for OpenCL, the default setting is to download,
build, and link with a static OpenCL ICD loader library and standard
OpenCL headers. This way no local OpenCL development headers or library
needs to be present and only OpenCL compatible drivers need to be
installed to use OpenCL. If this is not desired, you can set
:code:`USE_STATIC_OPENCL_LOADER` to :code:`no`.
The GPU library has some multi-thread support using OpenMP. If LAMMPS is built
with ``-D BUILD_OMP=on`` this will also be enabled.
The GPU library has some multi-thread support using OpenMP. If LAMMPS
is built with ``-D BUILD_OMP=on`` this will also be enabled.
If you are compiling with HIP, note that before running CMake you will have to
set appropriate environment variables. Some variables such as
:code:`HCC_AMDGPU_TARGET` (for ROCm <= 4.0) or :code:`CUDA_PATH` are necessary for :code:`hipcc`
and the linker to work correctly.
If you are compiling with HIP, note that before running CMake you will
have to set appropriate environment variables. Some variables such as
:code:`HCC_AMDGPU_TARGET` (for ROCm <= 4.0) or :code:`CUDA_PATH` are
necessary for :code:`hipcc` and the linker to work correctly.
Using CHIP-SPV implementation of HIP is now supported. It allows one to run HIP
code on Intel GPUs via the OpenCL or Level Zero backends. To use CHIP-SPV, you must
set :code:`-DHIP_USE_DEVICE_SORT=OFF` in your CMake command line as CHIP-SPV does not
yet support hipCUB. The use of HIP for Intel GPUs is still experimental so you
should only use this option in preparations to run on Aurora system at ANL.
.. versionadded:: 3Aug2022
Using the CHIP-SPV implementation of HIP is supported. It allows one to
run HIP code on Intel GPUs via the OpenCL or Level Zero backends. To use
CHIP-SPV, you must set :code:`-DHIP_USE_DEVICE_SORT=OFF` in your CMake
command line as CHIP-SPV does not yet support hipCUB. As of Summer 2022,
the use of HIP for Intel GPUs is experimental. You should only use this
option in preparations to run on Aurora system at Argonne.
.. code:: bash
@ -617,18 +626,24 @@ They must be specified in uppercase.
* - HOPPER90
- GPU
- NVIDIA Hopper generation CC 9.0 GPU
* - VEGA900
* - AMD_GFX906
- GPU
- AMD GPU MI25 GFX900
* - VEGA906
- AMD GPU MI50/MI60
* - AMD_GFX908
- GPU
- AMD GPU MI50/MI60 GFX906
* - VEGA908
- AMD GPU MI100
* - AMD_GFX90A
- GPU
- AMD GPU MI100 GFX908
* - VEGA90A
- AMD GPU MI200
* - AMD_GFX942
- GPU
- AMD GPU MI200 GFX90A
- AMD GPU MI300
* - AMD_GFX1030
- GPU
- AMD GPU V620/W6800
* - AMD_GFX1100
- GPU
- AMD GPU RX7900XTX
* - INTEL_GEN
- GPU
- SPIR64-based devices, e.g. Intel GPUs, using JIT
@ -651,7 +666,7 @@ They must be specified in uppercase.
- GPU
- Intel GPU Ponte Vecchio
This list was last updated for version 3.7.1 of the Kokkos library.
This list was last updated for version 4.2 of the Kokkos library.
.. tabs::
@ -707,9 +722,10 @@ This list was last updated for version 3.7.1 of the Kokkos library.
``cmake/presets`` folder, ``kokkos-serial.cmake``,
``kokkos-openmp.cmake``, ``kokkos-cuda.cmake``,
``kokkos-hip.cmake``, and ``kokkos-sycl.cmake``. They will enable
the KOKKOS package and enable some hardware choice. So to compile
with CUDA device parallelization (for GPUs with CC 5.0 and up)
with some common packages enabled, you can do the following:
the KOKKOS package and enable some hardware choices. For GPU
support those preset files must be customized to match the
hardware used. So to compile with CUDA device parallelization with
some common packages enabled, you can do the following:
.. code-block:: bash
@ -871,6 +887,50 @@ included in the LAMMPS source distribution in the ``lib/lepton`` folder.
----------
.. _machdyn:
MACHDYN 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.
.. tabs::
.. tab:: 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 inside the CMake build directory. If the Eigen3
library is already on your system (in a location where CMake
cannot find it), set ``EIGEN3_INCLUDE_DIR`` to the directory the
``Eigen3`` include file is in.
.. tab:: Traditional make
You can download the Eigen3 library manually if you prefer; follow
the instructions in ``lib/machdyn/README``. You can also do it in one
step from the ``lammps/src`` dir, using a command like these,
which simply invokes the ``lib/machdyn/Install.py`` script with the
specified args:
.. code-block:: bash
make lib-machdyn # print help message
make lib-machdyn args="-b" # download to lib/machdyn/eigen3
make lib-machdyn 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/machdyn`` to point to the Eigen dir. When LAMMPS builds it
will use this link. You should not need to edit the
``lib/machdyn/Makefile.lammps`` file.
----------
.. _mliap:
ML-IAP package
@ -921,59 +981,6 @@ Python version 3.6 or later.
----------
.. _mscg:
MSCG package
-----------------------
To build with this package, you must download and build the MS-CG
library. Building the MS-CG library requires that the GSL
(GNU Scientific Library) headers and libraries are installed on your
machine. See the ``lib/mscg/README`` and ``MSCG/Install`` files for
more details.
.. tabs::
.. tab:: CMake build
.. code-block:: bash
-D DOWNLOAD_MSCG=value # download MSCG for build, value = no (default) or yes
-D MSCG_LIBRARY=path # MSCG library file (only needed if a custom location)
-D MSCG_INCLUDE_DIR=path # MSCG include directory (only needed if a custom location)
If ``DOWNLOAD_MSCG`` is set, the MSCG library will be downloaded
and built inside the CMake build directory. If the MSCG library
is already on your system (in a location CMake cannot find it),
``MSCG_LIBRARY`` is the 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.
.. tab:: 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 step from the ``lammps/src`` dir, using a
command like these, which simply invokes the
``lib/mscg/Install.py`` script with the specified args:
.. code-block:: bash
make lib-mscg # print help message
make lib-mscg args="-b -m serial" # download and build in lib/mscg/MSCG-release-master
# with the settings compatible with "make serial"
make lib-mscg args="-b -m mpi" # download and build in lib/mscg/MSCG-release-master
# with the settings compatible with "make mpi"
make lib-mscg args="-p /usr/local/mscg-release" # use the existing MS-CG installation in /usr/local/mscg-release
Note that 2 symbolic (soft) links, ``includelink`` and ``liblink``,
will be created in ``lib/mscg`` to point to the MS-CG
``src/installation`` dir. When LAMMPS is built in src it will use
these links. You should not need to edit the
``lib/mscg/Makefile.lammps`` file.
----------
.. _opt:
OPT package
@ -1049,12 +1056,12 @@ additional details.
.. code-block:: bash
-D PYTHON_EXECUTABLE=path # path to Python executable to use
-D Python_EXECUTABLE=path # path to Python executable to use
Without this setting, CMake will guess the default Python version
on your system. To use a different Python version, you can either
create a virtualenv, activate it and then run cmake. Or you can
set the PYTHON_EXECUTABLE variable to specify which Python
set the 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.
@ -1469,6 +1476,55 @@ ML-POD package
----------
.. _ml-quip:
ML-QUIP package
---------------------------------
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. The automatic download will from
within CMake will download the non-commercial use version.
.. tabs::
.. tab:: CMake build
.. code-block:: bash
-D DOWNLOAD_QUIP=value # download QUIP library for build, value = no (default) or yes
-D QUIP_LIBRARY=path # path to libquip.a (only needed if a custom location)
-D USE_INTERNAL_LINALG=value # Use the internal linear algebra library instead of LAPACK
# value = no (default) or yes
CMake will try to download and build the QUIP library from GitHub,
if it is not found on the local machine. This requires to have git
installed. It will use the same compilers and flags as used for
compiling LAMMPS. Currently this is only supported for the GNU
and the Intel compilers. Set the ``QUIP_LIBRARY`` variable if you
want to use a previously compiled and installed QUIP library and
CMake cannot find it.
The QUIP library requires LAPACK (and BLAS) and CMake can identify
their locations and pass that info to the QUIP build script. But
on some systems this triggers a (current) limitation of CMake and
the configuration will fail. Try enabling ``USE_INTERNAL_LINALG`` in
those cases to use the bundled linear algebra library and work around
the limitation.
.. tab:: Traditional make
The download/build procedure for the QUIP library, described in
``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 successfully build on your system.
----------
.. _plumed:
PLUMED package
@ -1990,55 +2046,6 @@ verified to work in February 2020 with Quantum Espresso versions 6.3 to
----------
.. _ml-quip:
ML-QUIP package
---------------------------------
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. The automatic download will from
within CMake will download the non-commercial use version.
.. tabs::
.. tab:: CMake build
.. code-block:: bash
-D DOWNLOAD_QUIP=value # download QUIP library for build, value = no (default) or yes
-D QUIP_LIBRARY=path # path to libquip.a (only needed if a custom location)
-D USE_INTERNAL_LINALG=value # Use the internal linear algebra library instead of LAPACK
# value = no (default) or yes
CMake will try to download and build the QUIP library from GitHub,
if it is not found on the local machine. This requires to have git
installed. It will use the same compilers and flags as used for
compiling LAMMPS. Currently this is only supported for the GNU
and the Intel compilers. Set the ``QUIP_LIBRARY`` variable if you
want to use a previously compiled and installed QUIP library and
CMake cannot find it.
The QUIP library requires LAPACK (and BLAS) and CMake can identify
their locations and pass that info to the QUIP build script. But
on some systems this triggers a (current) limitation of CMake and
the configuration will fail. Try enabling ``USE_INTERNAL_LINALG`` in
those cases to use the bundled linear algebra library and work around
the limitation.
.. tab:: Traditional make
The download/build procedure for the QUIP library, described in
``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 successfully build on your system.
----------
.. _scafacos:
SCAFACOS package
@ -2086,50 +2093,6 @@ To build with this package, you must download and build the
----------
.. _machdyn:
MACHDYN 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.
.. tabs::
.. tab:: 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 inside the CMake build directory. If the Eigen3
library is already on your system (in a location where CMake
cannot find it), set ``EIGEN3_INCLUDE_DIR`` to the directory the
``Eigen3`` include file is in.
.. tab:: 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 invokes the ``lib/smd/Install.py`` script with the
specified args:
.. code-block:: bash
make lib-smd # print help message
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`` file.
----------
.. _vtk:
VTK package

2
doc/src/Build_manual.rst
View File

@ -52,7 +52,7 @@ can be translated to different output format using the `Sphinx
incorporates programmer documentation extracted from the LAMMPS C++
sources through the `Doxygen <https://doxygen.nl/>`_ program. Currently
the translation to HTML, PDF (via LaTeX), ePUB (for many e-book readers)
and MOBI (for Amazon Kindle(tm) readers) are supported. For that to work a
and MOBI (for Amazon Kindle readers) are supported. For that to work a
Python interpreter version 3.8 or later, the ``doxygen`` tools and
internet access to download additional files and tools are required.
This download is usually only required once or after the documentation

2
doc/src/Build_package.rst
View File

@ -55,7 +55,6 @@ packages:
* :ref:`ML-POD <ml-pod>`
* :ref:`ML-QUIP <ml-quip>`
* :ref:`MOLFILE <molfile>`
* :ref:`MSCG <mscg>`
* :ref:`NETCDF <netcdf>`
* :ref:`OPENMP <openmp>`
* :ref:`OPT <opt>`
@ -183,6 +182,7 @@ make a copy of one of them and modify it to suit your needs.
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
cmake -C ../cmake/presets/macos-multiarch.cmake [OPTIONS] ../cmake # compile serial multi-arch binaries on macOS
Presets that have names starting with "windows" are specifically for
compiling LAMMPS :doc:`natively on Windows <Build_windows>` and

73
doc/src/Build_settings.rst
View File

@ -44,6 +44,14 @@ require use of an FFT library to compute 1d FFTs. The KISS FFT
library is included with LAMMPS, but other libraries can be faster.
LAMMPS can use them if they are available on your system.
.. versionadded:: TBD
Alternatively, LAMMPS can use the `heFFTe
<https://icl-utk-edu.github.io/heffte/>`_ library for the MPI
communication algorithms, which comes with many optimizations for
special cases, e.g. leveraging available 2D and 3D FFTs in the back end
libraries and better pipelining for packing and communication.
.. tabs::
.. tab:: CMake build
@ -53,6 +61,7 @@ LAMMPS can use them if they are available on your system.
-D FFT=value # FFTW3 or MKL or KISS, default is FFTW3 if found, else KISS
-D FFT_SINGLE=value # yes or no (default), no = double precision
-D FFT_PACK=value # array (default) or pointer or memcpy
-D FFT_USE_HEFFTE=value # yes or no (default), yes links to heFFTe
.. note::
@ -76,6 +85,16 @@ LAMMPS can use them if they are available on your system.
-D MKL_INCLUDE_DIR=path # ditto for Intel MKL library
-D FFT_MKL_THREADS=on # enable using threaded FFTs with MKL libraries
-D MKL_LIBRARY=path # path to MKL libraries
-D FFT_HEFFTE_BACKEND=value # FFTW or MKL or empty/undefined for the stock heFFTe back end
-D Heffte_ROOT=path # path to an existing heFFTe installation
.. note::
heFFTe comes with a builtin (= stock) back end for FFTs, i.e. a
default internal FFT implementation; however, this stock back
end is intended for testing purposes only and is not optimized
for production runs.
.. tab:: Traditional make
@ -111,6 +130,24 @@ LAMMPS can use them if they are available on your system.
files in its default search path. You must specify ``FFT_LIB``
with the appropriate FFT libraries to include in the link.
Traditional make can also link to heFFTe using an existing installation
.. code-block:: make
include <path-to-heffte-installation>/share/heffte/HeffteMakefile.in
FFT_INC = -DFFT_HEFFTE -DFFT_HEFFTE_FFTW $(heffte_include)
FFT_PATH =
FFT_LIB = $(heffte_link) $(heffte_libs)
The heFFTe install path will contain `HeffteMakefile.in`.
which will define the `heffte_` include variables needed to link to heFFTe from
an external project using traditional make.
The `-DFFT_HEFFTE` is required to switch to using heFFTe, while the optional `-DFFT_HEFFTE_FFTW`
selects the desired heFFTe back end, e.g., `-DFFT_HEFFTE_FFTW` or `-DFFT_HEFFTE_MKL`,
omitting the variable will default to the `stock` back end.
The heFFTe `stock` back end is intended to be used for testing and debugging,
but is not performance optimized for large scale production runs.
The `KISS FFT library <https://github.com/mborgerding/kissfft>`_ is
included in the LAMMPS distribution. It is portable across all
platforms. Depending on the size of the FFTs and the number of
@ -170,6 +207,16 @@ Depending on the machine, the size of the FFT grid, the number of
processors used, one option may be slightly faster. The default is
ARRAY mode.
When using ``-DFFT_HEFFTE`` CMake will first look for an existing
install with hints provided by ``-DHeffte_ROOT``, as recommended by the
CMake standard and note that the name is case sensitive. If CMake cannot
find a heFFTe installation with the correct back end (e.g., FFTW or
MKL), it will attempt to download and build the library automatically.
In this case, LAMMPS CMake will also accept all heFFTe specific
variables listed in the `heFFTe documentation
<https://mkstoyanov.bitbucket.io/heffte/md_doxygen_installation.html>`_
and those variables will be passed into the heFFTe build.
----------
.. _size:
@ -459,27 +506,13 @@ those systems:
.. _exceptions:
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 thrown from within LAMMPS.
.. tabs::
.. tab:: CMake build
.. code-block:: bash
-D LAMMPS_EXCEPTIONS=value # yes or no (default)
.. tab:: Traditional make
.. code-block:: make
LMP_INC = -DLAMMPS_EXCEPTIONS <other LMP_INC settings>
LAMMPS errors do not kill the calling code, but throw an exception. In
the C-library interface, the call stack is unwound and control returns
to the caller, e.g. to Python or a code that is coupled to LAMMPS. The
error status can then be queried. When using C++ directly, the calling
code has to be set up to *catch* exceptions thrown from within LAMMPS.
.. note::

11
doc/src/Commands_compute.rst
View File

@ -91,6 +91,7 @@ KOKKOS, o = OPENMP, t = OPT.
* :doc:`ke/atom/eff <compute_ke_atom_eff>`
* :doc:`ke/eff <compute_ke_eff>`
* :doc:`ke/rigid <compute_ke_rigid>`
* :doc:`composition/atom (k) <compute_composition_atom>`
* :doc:`mliap <compute_mliap>`
* :doc:`momentum <compute_momentum>`
* :doc:`msd <compute_msd>`
@ -99,6 +100,7 @@ KOKKOS, o = OPENMP, t = OPT.
* :doc:`nbond/atom <compute_nbond_atom>`
* :doc:`omega/chunk <compute_omega_chunk>`
* :doc:`orientorder/atom (k) <compute_orientorder_atom>`
* :doc:`pace <compute_pace>`
* :doc:`pair <compute_pair>`
* :doc:`pair/local <compute_pair_local>`
* :doc:`pe <compute_pe>`
@ -114,12 +116,15 @@ KOKKOS, o = OPENMP, t = OPT.
* :doc:`property/grid <compute_property_grid>`
* :doc:`property/local <compute_property_local>`
* :doc:`ptm/atom <compute_ptm_atom>`
* :doc:`rattlers/atom <compute_rattlers_atom>`
* :doc:`rdf <compute_rdf>`
* :doc:`reaxff/atom (k) <compute_reaxff_atom>`
* :doc:`reduce <compute_reduce>`
* :doc:`reduce/chunk <compute_reduce_chunk>`
* :doc:`reduce/region <compute_reduce>`
* :doc:`rigid/local <compute_rigid_local>`
* :doc:`saed <compute_saed>`
* :doc:`slcsa/atom <compute_slcsa_atom>`
* :doc:`slice <compute_slice>`
* :doc:`smd/contact/radius <compute_smd_contact_radius>`
* :doc:`smd/damage <compute_smd_damage>`
@ -153,11 +158,11 @@ KOKKOS, o = OPENMP, t = OPT.
* :doc:`sph/t/atom <compute_sph_t_atom>`
* :doc:`spin <compute_spin>`
* :doc:`stress/atom <compute_stress_atom>`
* :doc:`stress/cartesian <compute_stress_profile>`
* :doc:`stress/cylinder <compute_stress_profile>`
* :doc:`stress/cartesian <compute_stress_cartesian>`
* :doc:`stress/cylinder <compute_stress_curvilinear>`
* :doc:`stress/mop <compute_stress_mop>`
* :doc:`stress/mop/profile <compute_stress_mop>`
* :doc:`stress/spherical <compute_stress_profile>`
* :doc:`stress/spherical <compute_stress_curvilinear>`
* :doc:`stress/tally <compute_tally>`
* :doc:`tdpd/cc/atom <compute_tdpd_cc_atom>`
* :doc:`temp (k) <compute_temp>`

4
doc/src/Commands_dump.rst
View File

@ -23,17 +23,14 @@ An alphabetic list of all LAMMPS :doc:`dump <dump>` commands.
* :doc:`atom <dump>`
* :doc:`atom/adios <dump_adios>`
* :doc:`atom/gz <dump>`
* :doc:`atom/mpiio <dump>`
* :doc:`atom/zstd <dump>`
* :doc:`cfg <dump>`
* :doc:`cfg/gz <dump>`
* :doc:`cfg/mpiio <dump>`
* :doc:`cfg/uef <dump_cfg_uef>`
* :doc:`cfg/zstd <dump>`
* :doc:`custom <dump>`
* :doc:`custom/adios <dump_adios>`
* :doc:`custom/gz <dump>`
* :doc:`custom/mpiio <dump>`
* :doc:`custom/zstd <dump>`
* :doc:`dcd <dump>`
* :doc:`grid <dump>`
@ -51,7 +48,6 @@ An alphabetic list of all LAMMPS :doc:`dump <dump>` commands.
* :doc:`xtc <dump>`
* :doc:`xyz <dump>`
* :doc:`xyz/gz <dump>`
* :doc:`xyz/mpiio <dump>`
* :doc:`xyz/zstd <dump>`
* :doc:`yaml <dump>`

11
doc/src/Commands_fix.rst
View File

@ -69,7 +69,7 @@ OPT.
* :doc:`drude/transform/inverse <fix_drude_transform>`
* :doc:`dt/reset (k) <fix_dt_reset>`
* :doc:`edpd/source <fix_dpd_source>`
* :doc:`efield <fix_efield>`
* :doc:`efield (k) <fix_efield>`
* :doc:`efield/tip4p <fix_efield>`
* :doc:`ehex <fix_ehex>`
* :doc:`electrode/conp (i) <fix_electrode>`
@ -116,13 +116,13 @@ OPT.
* :doc:`momentum (k) <fix_momentum>`
* :doc:`momentum/chunk <fix_momentum>`
* :doc:`move <fix_move>`
* :doc:`mscg <fix_mscg>`
* :doc:`msst <fix_msst>`
* :doc:`mvv/dpd <fix_mvv_dpd>`
* :doc:`mvv/edpd <fix_mvv_dpd>`
* :doc:`mvv/tdpd <fix_mvv_dpd>`
* :doc:`neb <fix_neb>`
* :doc:`neb/spin <fix_neb_spin>`
* :doc:`nonaffine/displacement <fix_nonaffine_displacement>`
* :doc:`nph (ko) <fix_nh>`
* :doc:`nph/asphere (o) <fix_nph_asphere>`
* :doc:`nph/body <fix_nph_body>`
@ -182,6 +182,7 @@ OPT.
* :doc:`pour <fix_pour>`
* :doc:`precession/spin <fix_precession_spin>`
* :doc:`press/berendsen <fix_press_berendsen>`
* :doc:`press/langevin <fix_press_langevin>`
* :doc:`print <fix_print>`
* :doc:`propel/self <fix_propel_self>`
* :doc:`property/atom (k) <fix_property_atom>`
@ -233,15 +234,15 @@ OPT.
* :doc:`spring <fix_spring>`
* :doc:`spring/chunk <fix_spring_chunk>`
* :doc:`spring/rg <fix_spring_rg>`
* :doc:`spring/self <fix_spring_self>`
* :doc:`spring/self (k) <fix_spring_self>`
* :doc:`srd <fix_srd>`
* :doc:`store/force <fix_store_force>`
* :doc:`store/state <fix_store_state>`
* :doc:`tdpd/source <fix_dpd_source>`
* :doc:`temp/berendsen <fix_temp_berendsen>`
* :doc:`temp/berendsen (k) <fix_temp_berendsen>`
* :doc:`temp/csld <fix_temp_csvr>`
* :doc:`temp/csvr <fix_temp_csvr>`
* :doc:`temp/rescale <fix_temp_rescale>`
* :doc:`temp/rescale (k) <fix_temp_rescale>`
* :doc:`temp/rescale/eff <fix_temp_rescale_eff>`
* :doc:`tfmc <fix_tfmc>`
* :doc:`tgnpt/drude <fix_tgnh_drude>`

23
doc/src/Commands_pair.rst
View File

@ -87,7 +87,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 (g) <pair_coul_slater>`
* :doc:`coul/shield <pair_coul_shield>`
* :doc:`coul/streitz <pair_coul>`
* :doc:`coul/tt <pair_coul_tt>`
@ -110,7 +110,7 @@ OPT.
* :doc:`eam/he <pair_eam>`
* :doc:`edip (o) <pair_edip>`
* :doc:`edip/multi <pair_edip>`
* :doc:`edpd <pair_mesodpd>`
* :doc:`edpd (g) <pair_mesodpd>`
* :doc:`eff/cut <pair_eff>`
* :doc:`eim (o) <pair_eim>`
* :doc:`exp6/rx (k) <pair_exp6_rx>`
@ -158,14 +158,14 @@ OPT.
* :doc:`lj/cut (gikot) <pair_lj>`
* :doc:`lj/cut/coul/cut (gko) <pair_lj_cut_coul>`
* :doc:`lj/cut/coul/cut/dielectric (o) <pair_dielectric>`
* :doc:`lj/cut/coul/cut/soft (o) <pair_fep_soft>`
* :doc:`lj/cut/coul/cut/soft (go) <pair_fep_soft>`
* :doc:`lj/cut/coul/debye (gko) <pair_lj_cut_coul>`
* :doc:`lj/cut/coul/debye/dielectric (o) <pair_dielectric>`
* :doc:`lj/cut/coul/dsf (gko) <pair_lj_cut_coul>`
* :doc:`lj/cut/coul/long (gikot) <pair_lj_cut_coul>`
* :doc:`lj/cut/coul/long/cs <pair_cs>`
* :doc:`lj/cut/coul/long/dielectric (o) <pair_dielectric>`
* :doc:`lj/cut/coul/long/soft (o) <pair_fep_soft>`
* :doc:`lj/cut/coul/long/soft (go) <pair_fep_soft>`
* :doc:`lj/cut/coul/msm (go) <pair_lj_cut_coul>`
* :doc:`lj/cut/coul/msm/dielectric <pair_dielectric>`
* :doc:`lj/cut/coul/wolf (o) <pair_lj_cut_coul>`
@ -202,7 +202,7 @@ OPT.
* :doc:`lubricate/poly (o) <pair_lubricate>`
* :doc:`lubricateU <pair_lubricateU>`
* :doc:`lubricateU/poly <pair_lubricateU>`
* :doc:`mdpd <pair_mesodpd>`
* :doc:`mdpd (g) <pair_mesodpd>`
* :doc:`mdpd/rhosum <pair_mesodpd>`
* :doc:`meam (k) <pair_meam>`
* :doc:`meam/ms (k) <pair_meam>`
@ -220,7 +220,8 @@ OPT.
* :doc:`morse/soft <pair_fep_soft>`
* :doc:`multi/lucy <pair_multi_lucy>`
* :doc:`multi/lucy/rx (k) <pair_multi_lucy_rx>`
* :doc:`nb3b/harmonic <pair_nb3b_harmonic>`
* :doc:`nb3b/harmonic <pair_nb3b>`
* :doc:`nb3b/screened <pair_nb3b>`
* :doc:`nm/cut (o) <pair_nm>`
* :doc:`nm/cut/coul/cut (o) <pair_nm>`
* :doc:`nm/cut/coul/long (o) <pair_nm>`
@ -265,13 +266,13 @@ OPT.
* :doc:`smd/tri_surface <pair_smd_triangulated_surface>`
* :doc:`smd/ulsph <pair_smd_ulsph>`
* :doc:`smtbq <pair_smtbq>`
* :doc:`snap (k) <pair_snap>`
* :doc:`snap (ik) <pair_snap>`
* :doc:`soft (go) <pair_soft>`
* :doc:`sph/heatconduction <pair_sph_heatconduction>`
* :doc:`sph/heatconduction (g) <pair_sph_heatconduction>`
* :doc:`sph/idealgas <pair_sph_idealgas>`
* :doc:`sph/lj <pair_sph_lj>`
* :doc:`sph/lj (g) <pair_sph_lj>`
* :doc:`sph/rhosum <pair_sph_rhosum>`
* :doc:`sph/taitwater <pair_sph_taitwater>`
* :doc:`sph/taitwater (g) <pair_sph_taitwater>`
* :doc:`sph/taitwater/morris <pair_sph_taitwater_morris>`
* :doc:`spin/dipole/cut <pair_spin_dipole>`
* :doc:`spin/dipole/long <pair_spin_dipole>`
@ -305,5 +306,5 @@ OPT.
* :doc:`wf/cut <pair_wf_cut>`
* :doc:`ylz <pair_ylz>`
* :doc:`yukawa (gko) <pair_yukawa>`
* :doc:`yukawa/colloid (go) <pair_yukawa_colloid>`
* :doc:`yukawa/colloid (gko) <pair_yukawa_colloid>`
* :doc:`zbl (gko) <pair_zbl>`

42
doc/src/Commands_removed.rst
View File

@ -41,7 +41,7 @@ warning.
LATTE package
-------------
.. deprecated:: TBD
.. deprecated:: 15Jun2023
The LATTE package with the fix latte command was removed from LAMMPS.
This functionality has been superseded by :doc:`fix mdi/qm <fix_mdi_qm>`
@ -85,6 +85,35 @@ The same functionality is available through
:doc:`bond style mesocnt <bond_mesocnt>` and
:doc:`angle style mesocnt <angle_mesocnt>`.
MPIIO package
-------------
.. deprecated:: 21Nov2023
The MPIIO package has been removed from LAMMPS since it was unmaintained
for many years and thus not updated to incorporate required changes that
had been applied to the corresponding non-MPIIO commands. As a
consequence the MPIIO commands had become unreliable and sometimes
crashing LAMMPS or corrupting data. Similar functionality is available
through the :ref:`ADIOS package <PKG-ADIOS>` and the :ref:`NETCDF
package <PKG-NETCDF>`. Also, the :doc:`dump_modify nfile or dump_modify
fileper <dump_modify>` keywords may be used for an efficient way of
writing out dump files when running on large numbers of processors.
Similarly, the "nfile" and "fileper" keywords exist for restarts:
see :doc:`restart <restart>`, :doc:`read_restart <read_restart>`,
:doc:`write_restart <write_restart>`.
MSCG package
------------
.. deprecated:: 21Nov2023
The MSCG package has been removed from LAMMPS since it was unmaintained
for many years and instead superseded by the `OpenMSCG software
<https://software.rcc.uchicago.edu/mscg/>`_ of the Voth group at the
University of Chicago, which can be used independent from LAMMPS.
REAX package
------------
@ -97,6 +126,17 @@ syntax compatible with the removed reax pair style, so input files will
have to be adapted. The REAXFF package was originally called
USER-REAXC.
USER-REAXC package
------------------
.. deprecated:: TBD
The USER-REAXC package has been renamed to :ref:`REAXFF <PKG-REAXFF>`.
In the process also the pair style and related fixes were renamed to use
the "reaxff" string instead of "reax/c". For a while LAMMPS was maintaining
backward compatibility by providing aliases for the styles. These have
been removed, so using "reaxff" is now *required*.
USER-CUDA package
-----------------

4
doc/src/Developer_grid.rst
View File

@ -92,8 +92,8 @@ Arguments for these methods can be values returned by the
*setup_grid()* method (described below), which define the extent of
the grid cells (owned+ghost) the processor owns. These 4 methods
allocate memory for 2d (first two) and 3d (second two) grid data. The
two methods that end in "_one" allocate an array which stores a single
value per grid cell. The two that end in "_multi" allocate an array
two methods that end in "_offset" allocate an array which stores a single
value per grid cell. The two that end in "_last" allocate an array
which stores *Nvalues* per grid cell.
.. code-block:: c++

3
doc/src/Developer_platform.rst
View File

@ -70,6 +70,9 @@ File and path functions and global constants
.. doxygenfunction:: is_console
:project: progguide
.. doxygenfunction:: disk_free
:project: progguide
.. doxygenfunction:: path_is_directory
:project: progguide

155
doc/src/Developer_unittest.rst
View File

@ -121,7 +121,7 @@ will be suppressed and only a summary printed, but adding
the '-V' option will then produce output from the tests
above like the following:
.. code-block::
.. code-block:: console
[...]
1: [ RUN ] Tokenizer.empty_string
@ -180,19 +180,11 @@ discarded but by setting the verbose flag (via setting the ``TEST_ARGS``
environment variable, ``TEST_ARGS=-v``) it can be printed and used to
understand why tests fail unexpectedly.
Another complexity of these tests stems from the need to capture
situations where LAMMPS will stop with an error, i.e. handle so-called
"death tests". Here the LAMMPS code will operate differently depending
on whether it was configured to throw C++ exceptions on errors or call
either ``exit()`` or ``MPI_Abort()``. In the latter case, the test code
also needs to detect whether LAMMPS was compiled with the OpenMPI
library, as OpenMPI is **only** compatible the death test options of the
GoogleTest library when C++ exceptions are enabled; otherwise those
"death tests" must be skipped to avoid reporting bogus failures. The
specifics of this step are implemented in the ``TEST_FAILURE()``
macro. These tests operate by capturing the screen output when executing
the failing command and then comparing that with a provided regular
expression string pattern. Example:
The specifics of so-called "death tests", i.e. conditions where LAMMPS
should fail and throw an exception, are implemented in the
``TEST_FAILURE()`` macro. These tests operate by capturing the screen
output when executing the failing command and then comparing that with a
provided regular expression string pattern. Example:
.. code-block:: c++
@ -282,9 +274,7 @@ Tests for using the Fortran module are in the ``unittest/fortran``
folder. Since they are also using the GoogleTest library, they require
to also implement test wrappers in C++ that will call fortran functions
which provide a C function interface through ISO_C_BINDINGS that will in
turn call the functions in the LAMMPS Fortran module. This part of the
unit tests is incomplete since the Fortran module it is based on is
incomplete as well.
turn call the functions in the LAMMPS Fortran module.
Tests for the C++-style library interface
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -405,10 +395,10 @@ compare with the reference and also start from the data file. A final
check will use multi-cutoff r-RESPA (if supported by the pair style) at
a 1:1 split and compare to the Verlet results. These sets of tests are
run with multiple test fixtures for accelerated styles (OPT, OPENMP,
INTEL) and for the latter two with 4 OpenMP threads enabled. For
these tests the relative error (epsilon) is lowered by a common factor
due to the additional numerical noise, but the tests are still comparing
to the same reference data.
INTEL, KOKKOS (OpenMP only)) and for the latter three with 4 OpenMP
threads enabled. For these tests the relative error (epsilon) is lowered
by a common factor due to the additional numerical noise, but the tests
are still comparing to the same reference data.
Additional tests will check whether all listed extract keywords are
supported and have the correct dimensionality and the final set of tests
@ -442,17 +432,19 @@ The ``test_pair_style`` tester is used with 4 categories of test inputs:
pair style is defined, but the computation of the pair style contributions
is disabled.
The ``test_bond_style`` and ``test_angle_style`` are set up in a similar
fashion and share support functions with the pair style tester. The final
group of tests in this section is for fix styles that add/manipulate forces
and velocities, e.g. for time integration, thermostats and more.
The ``test_bond_style``, ``test_angle_style``, ``test_dihedral_style``, and
``test_improper_style`` tester programs are set up in a similar fashion and
share support functions with the pair style tester. The final group of
tests in this section is for fix styles that add/manipulate forces and
velocities, e.g. for time integration, thermostats and more.
Adding a new test is easiest done by copying and modifying an existing test
for a style that is similar to one to be tested. The file name should follow
the naming conventions described above and after copying the file, the first
step is to replace the style names where needed. The coefficient values
do not have to be meaningful, just in a reasonable range for the given system.
It does not matter if some forces are large, for as long as they do not diverge.
Adding a new test is easiest done by copying and modifying an existing YAML
file for a style that is similar to one to be tested. The file name should
follow the naming conventions described above and after copying the file,
the first step is to replace the style names where needed. The coefficient
values do not have to be meaningful, just in a reasonable range for the
given system. It does not matter if some forces are large, for as long as
they do not diverge.
The template input files define a large number of index variables at the top
that can be modified inside the YAML file to control the behavior. For example,
@ -480,7 +472,7 @@ Note that this disables computing the kspace contribution, but still will run
the setup. The "gewald" parameter should be set explicitly to speed up the run.
For styles with long-range electrostatics, typically two tests are added one using
the (slower) analytic approximation of the erfc() function and the other using
the tabulated coulomb, to test both code paths. The reference results in the YAML
the tabulated coulomb, to test both code paths. The reference results in the YAML
files then should be compared manually, if they agree well enough within the limits
of those two approximations.
@ -534,3 +526,102 @@ The ``unittest/tools`` folder contains tests for programs in the
shell, which are implemented as a python scripts using the ``unittest``
Python module and launching the tool commands through the ``subprocess``
Python module.
Troubleshooting failed unit tests
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The are by default no unit tests for newly added features (e.g. pair, fix,
or compute styles) unless your pull request also includes tests for the
added features. If you are modifying some features, you may see failures
for existing tests, if your modifications have some unexpected side effects
or your changes render the existing text invalid. If you are adding an
accelerated version of an existing style, then only tests for INTEL,
KOKKOS (with OpenMP only), OPENMP, and OPT will be run automatically.
Tests for the GPU package are time consuming and thus are only run
*after* a merge, or when a special label, ``gpu_unit_tests`` is added
to the pull request. After the test has started, it is often best to
remove the label since every PR activity will re-trigger the test (that
is a limitation of triggering a test with a label). Support for unit
tests with using KOKKOS with GPU acceleration is currently not supported.
When you see a failed build on GitHub, click on ``Details`` to be taken
to the corresponding LAMMPS Jenkins CI web page. Click on the "Exit"
symbol near the ``Logout`` button on the top right of that page to go to
the "classic view". In the classic view, there is a list of the
individual runs that make up this test run (they are shown but cannot be
inspected in the default view). You can click on any of those.
Clicking on ``Test Result`` will display the list of failed tests. Click
on the "Status" column to sort the tests based on their Failed or Passed
status. Then click on the failed test to expand its output.
For example, the following output snippet shows the failed unit test
.. code-block:: console
[ RUN ] PairStyle.gpu
/home/builder/workspace/dev/pull_requests/ubuntu_gpu/unit_tests/cmake_gpu_opencl_mixed_smallbig_clang_static/unittest/force-styles/test_main.cpp:63: Failure
Expected: (err) <= (epsilon)
Actual: 0.00018957912910606503 vs 0.0001
Google Test trace:
/home/builder/workspace/dev/pull_requests/ubuntu_gpu/unit_tests/cmake_gpu_opencl_mixed_smallbig_clang_static/unittest/force-styles/test_main.cpp:56: EXPECT_FORCES: init_forces (newton off)
/home/builder/workspace/dev/pull_requests/ubuntu_gpu/unit_tests/cmake_gpu_opencl_mixed_smallbig_clang_static/unittest/force-styles/test_main.cpp:64: Failure
Expected: (err) <= (epsilon)
Actual: 0.00022892713393549854 vs 0.0001
The failed assertions provide line numbers in the test source
(e.g. ``test_main.cpp:56``), from which one can understand what
specific assertion failed.
Note that the force style engine runs one of a small number of systems
in a rather off-equilibrium configuration with a few atoms for a few
steps, writes data and restart files, uses :doc:`the clear command
<clear>` to reset LAMMPS, and then runs from those files with different
settings (e.g. newton on/off) and integrators (e.g. verlet vs. respa).
Beyond potential issues/bugs in the source code, the mismatch between
the expected and actual values could be that force arrays are not
properly cleared between multiple run commands or that class members are
not correctly initialized or written to or read from a data or restart
file.
While the epsilon (relative precision) for a single, `IEEE 754 compliant
<https://en.wikipedia.org/wiki/IEEE_754>`_, double precision floating
point operation is at about 2.2e-16, the achievable precision for the
tests is lower due to most numbers being sums over intermediate results
and the non-associativity of floating point math leading to larger
errors. In some cases specific properties of the tested style. As a
rule of thumb, the test epsilon can often be in the range 5.0e-14 to
1.0e-13. But for "noisy" force kernels, e.g. those a larger amount of
arithmetic operations involving `exp()`, `log()` or `sin()` functions,
and also due to the effect of compiler optimization or differences
between compilers or platforms, epsilon may need to be further relaxed,
sometimes epsilon can be relaxed to 1.0e-12. If interpolation or lookup
tables are used, epsilon may need to be set to 1.0e-10 or even higher.
For tests of accelerated styles, the per-test epsilon is multiplied
by empirical factors that take into account the differences in the order
of floating point operations or that some or most intermediate operations
may be done using approximations or with single precision floating point
math.
To rerun the failed unit test individually, change to the ``build`` directory
and run the test with verbose output. For example,
.. code-block:: bash
env TEST_ARGS=-v ctest -R ^MolPairStyle:lj_cut_coul_long -V
``ctest`` with the ``-V`` flag also shows the exact command line
of the test. One can then use ``gdb --args`` to further debug and
catch exceptions with the test command, for example,
.. code-block:: bash
gdb --args /path/to/lammps/build/test_pair_style /path/to/lammps/unittest/force-styles/tests/mol-pair-lj_cut_coul_long.yaml
It is recommended to configure the build with ``-D
BUILD_SHARED_LIBS=on`` and use a custom linker to shorten the build time
during recompilation. Installing `ccache` in your development
environment helps speed up recompilation by caching previous
compilations and detecting when the same compilation is being done
again. Please see :doc:`Build_development` for further details.

6
doc/src/Errors_messages.rst
View File

@ -7148,9 +7148,6 @@ keyword to allow for additional bonds to be formed
*Read_dump xyz fields do not have consistent scaling/wrapping*
Self-explanatory.
*Reading from MPI-IO filename when MPIIO package is not installed*
Self-explanatory.
*Reax_defs.h setting for NATDEF is too small*
Edit the setting in the ReaxFF library and re-compile the
library and re-build LAMMPS.
@ -8489,9 +8486,6 @@ keyword to allow for additional bonds to be formed
The write_restart command cannot be used before a read_data,
read_restart, or create_box command.
*Writing to MPI-IO filename when MPIIO package is not installed*
Self-explanatory.
*Zero length rotation vector with displace_atoms*
Self-explanatory.

2
doc/src/Examples.rst
View File

@ -104,8 +104,6 @@ Lowercase directories
+-------------+------------------------------------------------------------------+
| min | energy minimization of 2d LJ melt |
+-------------+------------------------------------------------------------------+
| mscg | parameterize a multi-scale coarse-graining (MSCG) model |
+-------------+------------------------------------------------------------------+
| msst | MSST shock dynamics |
+-------------+------------------------------------------------------------------+
| multi | multi neighboring for systems with large interaction disparities |

237
doc/src/Fortran.rst
View File

@ -56,17 +56,6 @@ C++ in the ``examples/COUPLE/simple`` folder of the LAMMPS distribution.
and Ubuntu 18.04 LTS and not compatible. Either newer compilers
need to be installed or the Linux updated.
.. versionchanged:: 8Feb2023
.. note::
A contributed Fortran interface is available in the
``examples/COUPLE/fortran2`` folder. However, since the completion
of the :f:mod:`LIBLAMMPS` module, this interface is now deprecated,
no longer actively maintained and will likely be removed in the
future. Please see the ``README`` file in that folder for more
information about it and how to contact its author and maintainer.
----------
Creating or deleting a LAMMPS object
@ -203,40 +192,62 @@ Below is an example demonstrating some of the possible uses.
.. code-block:: fortran
PROGRAM testprop
USE LIBLAMMPS
USE, INTRINSIC :: ISO_C_BINDING, ONLY : c_double, c_int64_t
USE, INTRINSIC :: ISO_FORTRAN_ENV, ONLY : OUTPUT_UNIT
TYPE(lammps) :: lmp
INTEGER(KIND=c_int64_t), POINTER :: natoms
REAL(KIND=c_double), POINTER :: dt
INTEGER(KIND=c_int64_t), POINTER :: ntimestep
REAL(KIND=c_double) :: pe, ke
PROGRAM testprop
USE LIBLAMMPS
USE, INTRINSIC :: ISO_C_BINDING, ONLY : c_double, c_int64_t, c_int
USE, INTRINSIC :: ISO_FORTRAN_ENV, ONLY : OUTPUT_UNIT
TYPE(lammps) :: lmp
INTEGER(KIND=c_int64_t), POINTER :: natoms, ntimestep, bval
REAL(KIND=c_double), POINTER :: dt, dval
INTEGER(KIND=c_int), POINTER :: nfield, typ, ival
INTEGER(KIND=c_int) :: i
CHARACTER(LEN=11) :: key
REAL(KIND=c_double) :: pe, ke
lmp = lammps()
CALL lmp%file('in.sysinit')
natoms = lmp%extract_global('natoms')
WRITE(OUTPUT_UNIT,'(A,I0,A)') 'Running a simulation with ', natoms, ' atoms'
WRITE(OUTPUT_UNIT,'(I0,A,I0,A,I0,A)') lmp%extract_setting('nlocal'), &
' local and ', lmp%extract_setting('nghost'), ' ghost atoms. ', &
lmp%extract_setting('ntypes'), ' atom types'
lmp = lammps()
CALL lmp%file('in.sysinit')
natoms = lmp%extract_global('natoms')
WRITE(OUTPUT_UNIT,'(A,I0,A)') 'Running a simulation with ', natoms, ' atoms'
WRITE(OUTPUT_UNIT,'(I0,A,I0,A,I0,A)') lmp%extract_setting('nlocal'), &
' local and ', lmp%extract_setting('nghost'), ' ghost atoms. ', &
lmp%extract_setting('ntypes'), ' atom types'
CALL lmp%command('run 2 post no')
dt = lmp%extract_global('dt')
ntimestep = lmp%extract_global('ntimestep')
WRITE(OUTPUT_UNIT,'(A,I0,A,F4.1,A)') 'At step: ', ntimestep, &
' Changing timestep from', dt, ' to 0.5'
dt = 0.5_c_double
CALL lmp%command('run 2 post no')
CALL lmp%command('run 2 post no')
WRITE(OUTPUT_UNIT,'(A,I0)') 'At step: ', ntimestep
pe = lmp%get_thermo('pe')
ke = lmp%get_thermo('ke')
PRINT*, 'PE = ', pe
PRINT*, 'KE = ', ke
ntimestep = lmp%last_thermo('step', 0)
nfield = lmp%last_thermo('num', 0)
WRITE(OUTPUT_UNIT,'(A,I0,A,I0)') 'Last thermo output on step: ', ntimestep, &
', number of fields: ', nfield
DO i=1, nfield
key = lmp%last_thermo('keyword',i)
typ = lmp%last_thermo('type',i)
IF (typ == lmp%dtype%i32) THEN
ival = lmp%last_thermo('data',i)
WRITE(OUTPUT_UNIT,*) key, ':', ival
ELSE IF (typ == lmp%dtype%i64) THEN
bval = lmp%last_thermo('data',i)
WRITE(OUTPUT_UNIT,*) key, ':', bval
ELSE IF (typ == lmp%dtype%r64) THEN
dval = lmp%last_thermo('data',i)
WRITE(OUTPUT_UNIT,*) key, ':', dval
END IF
END DO
CALL lmp%close(.TRUE.)
END PROGRAM testprop
dt = lmp%extract_global('dt')
ntimestep = lmp%extract_global('ntimestep')
WRITE(OUTPUT_UNIT,'(A,I0,A,F4.1,A)') 'At step: ', ntimestep, &
' Changing timestep from', dt, ' to 0.5'
dt = 0.5_c_double
CALL lmp%command('run 2 post no')
WRITE(OUTPUT_UNIT,'(A,I0)') 'At step: ', ntimestep
pe = lmp%get_thermo('pe')
ke = lmp%get_thermo('ke')
WRITE(OUTPUT_UNIT,*) 'PE = ', pe
WRITE(OUTPUT_UNIT,*) 'KE = ', ke
CALL lmp%close(.TRUE.)
END PROGRAM testprop
---------------
@ -262,6 +273,8 @@ of the contents of the :f:mod:`LIBLAMMPS` Fortran interface to LAMMPS.
:ftype style: type(lammps_style)
:f type: derived type to access lammps type constants
:ftype type: type(lammps_type)
:f dtype: derived type to access lammps data type constants
:ftype dtype: type(lammps_dtype)
:f close: :f:subr:`close`
:ftype close: subroutine
:f subroutine error: :f:subr:`error`
@ -278,6 +291,8 @@ of the contents of the :f:mod:`LIBLAMMPS` Fortran interface to LAMMPS.
:ftype get_natoms: function
:f get_thermo: :f:func:`get_thermo`
:ftype get_thermo: function
:f last_thermo: :f:func:`last_thermo`
:ftype last_thermo: function
:f extract_box: :f:subr:`extract_box`
:ftype extract_box: subroutine
:f reset_box: :f:subr:`reset_box`
@ -587,6 +602,96 @@ Procedures Bound to the :f:type:`lammps` Derived Type
--------
.. f:function:: last_thermo(what, index)
This function will call :cpp:func:`lammps_last_thermo` and returns
either a string or a pointer to a cached copy of LAMMPS last thermodynamic
output, depending on the data requested through *what*. Note that *index*
uses 1-based indexing to access thermo output columns.
.. versionadded:: 15Jun2023
Note that this function actually does not return a value, but rather
associates the pointer on the left side of the assignment to point to
internal LAMMPS data (with the exception of string data, which are
copied and returned as ordinary Fortran strings). Pointers must be
of the correct data type to point to said data (typically
``INTEGER(c_int)``, ``INTEGER(c_int64_t)``, or ``REAL(c_double)``).
The pointer being associated with LAMMPS data is type-checked at
run-time via an overloaded assignment operator. The pointers
returned by this function point to temporary, read-only data that may
be overwritten at any time, so their target values need to be copied
to local storage if they are supposed to persist.
For example,
.. code-block:: fortran
PROGRAM thermo
USE LIBLAMMPS
USE, INTRINSIC :: ISO_C_BINDING, ONLY : c_double, c_int64_t, c_int
TYPE(lammps) :: lmp
INTEGER(KIND=c_int64_t), POINTER :: ntimestep, bval
REAL(KIND=c_double), POINTER :: dval
INTEGER(KIND=c_int), POINTER :: nfield, typ, ival
INTEGER(KIND=c_int) :: i
CHARACTER(LEN=11) :: key
lmp = lammps()
CALL lmp%file('in.sysinit')
ntimestep = lmp%last_thermo('step', 0)
nfield = lmp%last_thermo('num', 0)
PRINT*, 'Last thermo output on step: ', ntimestep, ' Number of fields: ', nfield
DO i=1, nfield
key = lmp%last_thermo('keyword',i)
typ = lmp%last_thermo('type',i)
IF (typ == lmp%dtype%i32) THEN
ival = lmp%last_thermo('data',i)
PRINT*, key, ':', ival
ELSE IF (typ == lmp%dtype%i64) THEN
bval = lmp%last_thermo('data',i)
PRINT*, key, ':', bval
ELSE IF (typ == lmp%dtype%r64) THEN
dval = lmp%last_thermo('data',i)
PRINT*, key, ':', dval
END IF
END DO
CALL lmp%close(.TRUE.)
END PROGRAM thermo
would extract the last timestep where thermo output was done and the number
of columns it printed. Then it loops over the columns to print out column
header keywords and the corresponding data.
.. note::
If :f:func:`last_thermo` returns a string, the string must have a length
greater than or equal to the length of the string (not including the
terminal ``NULL`` character) that LAMMPS returns. If the variable's
length is too short, the string will be truncated. As usual in Fortran,
strings are padded with spaces at the end. If you use an allocatable
string, the string **must be allocated** prior to calling this function.
:p character(len=\*) what: string with the name of the thermo keyword
:p integer(c_int) index: 1-based column index
:to: :cpp:func:`lammps_last_thermo`
:r pointer [polymorphic]: pointer to LAMMPS data. The left-hand side of the
assignment should be either a string (if expecting string data) or a
C-compatible pointer (e.g., ``INTEGER(c_int), POINTER :: nlocal``) to the
extracted property.
.. warning::
Modifying the data in the location pointed to by the returned pointer
may lead to inconsistent internal data and thus may cause failures,
crashes, or bogus simulations. In general, it is much better
to use a LAMMPS input command that sets or changes these parameters.
Using an input command will take care of all side effects and necessary
updates of settings derived from such settings.
--------
.. f:subroutine:: extract_box([boxlo][, boxhi][, xy][, yz][, xz][, pflags][, boxflag])
This subroutine will call :cpp:func:`lammps_extract_box`. All
@ -764,13 +869,14 @@ Procedures Bound to the :f:type:`lammps` Derived Type
.. note::
If :f:func:`extract_global` returns a string, the string must have length
greater than or equal to the length of the string (not including the
terminal ``NULL`` character) that LAMMPS returns. If the variable's
length is too short, the string will be truncated. As usual in Fortran,
strings are padded with spaces at the end. If you use an allocatable
string, the string **must be allocated** prior to calling this function,
but you can automatically reallocate it to the correct length after the
If :f:func:`extract_global` returns a string, the string must have
a length greater than or equal to the length of the string (not
including the terminal ``NULL`` character) that LAMMPS returns. If
the variable's length is too short, the string will be
truncated. As usual in Fortran, strings are padded with spaces at
the end. If you use an allocatable string, the string **must be
allocated** prior to calling this function, but you can
automatically reallocate it to the correct length after the
function returns, viz.,
.. code-block :: fortran
@ -2172,19 +2278,13 @@ Procedures Bound to the :f:type:`lammps` Derived Type
.. versionadded:: 3Nov2022
In case of an error, LAMMPS will either abort or throw a C++ exception.
The latter has to be :ref:`enabled at compile time <exceptions>`.
This function checks if exceptions were enabled.
When using the library interface with C++ exceptions enabled, the library
interface functions will "catch" them, and the error status can then be
checked by calling :f:func:`has_error`. The most recent error message can be
retrieved via :f:func:`get_last_error_message`.
This can allow one to restart a calculation or delete and recreate
the LAMMPS instance when a C++ exception occurs. One application
of using exceptions this way is the :ref:`lammps_shell`. If C++
exceptions are disabled and an error happens during a call to
LAMMPS or the Fortran API, the application will terminate.
When using the library interface, the library interface functions
will "catch" exceptions, and then the error status can be checked by
calling :f:func:`has_error`. The most recent error message can be
retrieved via :f:func:`get_last_error_message`. This allows to
restart a calculation or delete and recreate the LAMMPS instance when
a C++ exception occurs. One application of using exceptions this way
is the :ref:`lammps_shell`.
:to: :cpp:func:`lammps_config_has_exceptions`
:r has_exceptions:
@ -2938,14 +3038,6 @@ Procedures Bound to the :f:type:`lammps` Derived Type
This function can be used to query if an error inside of LAMMPS
has thrown a :ref:`C++ exception <exceptions>`.
.. note::
This function will always report "no error" when the LAMMPS library
has been compiled without ``-DLAMMPS_EXCEPTIONS``, which turns fatal
errors aborting LAMMPS into C++ exceptions. You can use the library
function :cpp:func:`lammps_config_has_exceptions` to check if this is
the case.
:to: :cpp:func:`lammps_has_error`
:r has_error: ``.TRUE.`` if there is an error.
:rtype has_error: logical
@ -2968,13 +3060,6 @@ Procedures Bound to the :f:type:`lammps` Derived Type
would happen only in a single MPI rank and thus may not be recoverable, as
other MPI ranks may be waiting on the failing MPI rank(s) to send messages.
.. note::
This function will do nothing when the LAMMPS library has been
compiled without ``-DLAMMPS_EXCEPTIONS``, which turns errors aborting
LAMMPS into C++ exceptions. You can use the function
:f:func:`config_has_exceptions` to check whether this is the case.
:p character(len=\*) buffer: string buffer to copy the error message into
:o integer(c_int) status [optional]: 1 when all ranks had the error,
2 on a single-rank error.

2
doc/src/Howto.rst
View File

@ -100,6 +100,8 @@ Tutorials howto
Howto_cmake
Howto_github
Howto_lammps_gui
Howto_moltemplate
Howto_pylammps
Howto_wsl

4
doc/src/Howto_2d.rst
View File

@ -13,9 +13,9 @@ box with a single z plane of atoms - e.g.
.. code-block:: LAMMPS
create box 1 -10 10 -10 10 -0.25 0.25
create_box 1 -10 10 -10 10 -0.25 0.25
If using the :doc:`read data <read_data>` command to read in a file of
If using the :doc:`read_data <read_data>` command to read in a file of
atom coordinates, set the "zlo zhi" values to be finite but narrow,
similar to the create_box command settings just described. For each
atom in the file, assign a z coordinate so it falls inside the

8
doc/src/Howto_body.rst
View File

@ -170,9 +170,9 @@ with this body style to compute body/body and body/non-body interactions.
The *rounded/polygon* body style represents body particles as a 2d
polygon with a variable number of N vertices. This style can only be
used for 2d models; see the :doc:`boundary <boundary>` command. See the
"pair_style body/rounded/polygon" page for a diagram of two
squares with rounded circles at the vertices. Special cases for N = 1
(circle) and N = 2 (rod with rounded ends) can also be specified.
:doc:`pair_style body/rounded/polygon <pair_body_rounded_polygon>` page for
a diagram of two squares with rounded circles at the vertices. Special cases
for N = 1 (circle) and N = 2 (rod with rounded ends) can also be specified.
One use of this body style is for 2d discrete element models, as
described in :ref:`Fraige <body-Fraige>`.
@ -335,7 +335,7 @@ faces are listed, so that M = 6 + 3\*N + 1.
The integer line has three values: number of vertices (N), number of
edges (E) and number of faces (F). The floating point line(s) list 6
moments of inertia followed by the coordinates of the N vertices (x1
to zN) as 3N values, followed by 2N vertex indices corresponding to
to zN) as 3N values, followed by 2E vertex indices corresponding to
the end points of the E edges, then 4\*F vertex indices defining F
faces. The last value is the diameter value = the rounded diameter of
the sphere that surrounds each vertex. The diameter value can be

18
doc/src/Howto_bpm.rst
View File

@ -79,9 +79,9 @@ As bonds can be broken between neighbor list builds, the
bond styles. There are two possible settings which determine how pair
interactions work between bonded particles. First, one can overlay
pair forces with bond forces such that all bonded particles also
feel pair interactions. This can be accomplished by using the *overlay/pair*
keyword present in all bpm bond styles and by using the following special
bond settings
feel pair interactions. This can be accomplished by setting the *overlay/pair*
keyword present in all bpm bond styles to *yes* and requires using the
following special bond settings
.. code-block:: LAMMPS
@ -107,7 +107,17 @@ bond lists is expensive. By setting the lj weight for 1-2 bonds to
zero, this turns off pairwise interactions. Even though there are no
charges in BPM models, setting a nonzero coul weight for 1-2 bonds
ensures all bonded neighbors are still included in the neighbor list
in case bonds break between neighbor list builds.
in case bonds break between neighbor list builds. If bond breakage is
disabled during a simulation run by setting the *break* keyword to *no*,
a zero coul weight for 1-2 bonds can be used to exclude bonded atoms
from the neighbor list builds
.. code-block:: LAMMPS
special_bonds lj 0 1 1 coul 0 1 1
This can be useful for post-processing, or to determine pair interaction
properties between distinct bonded particles.
To monitor the fracture of bonds in the system, all BPM bond styles
have the ability to record instances of bond breakage to output using

41
doc/src/Howto_cmake.rst
View File

@ -1,11 +1,11 @@
Using CMake with LAMMPS tutorial
================================
Using CMake with LAMMPS
=======================
The support for building LAMMPS with CMake is a recent addition to
LAMMPS thanks to the efforts of Christoph Junghans (LANL) and Richard
Berger (Temple U). One of the key strengths of CMake is that it is not
tied to a specific platform or build system and thus generate the files
necessary to build and develop for different build systems and on
Berger (LANL). One of the key strengths of CMake is that it is not
tied to a specific platform or build system. Instead it generates the
files necessary to build and develop for different build systems and on
different platforms. Note, that this applies to the build system itself
not the LAMMPS code. In other words, without additional porting effort,
it is not possible - for example - to compile LAMMPS with Visual C++ on
@ -14,7 +14,7 @@ necessary to program LAMMPS as a project in integrated development
environments (IDE) like Eclipse, Visual Studio, QtCreator, Xcode,
CodeBlocks, Kate and others.
A second important feature of CMake is, that it can detect and validate
A second important feature of CMake is that it can detect and validate
available libraries, optimal settings, available support tools and so
on, so that by default LAMMPS will take advantage of available tools
without requiring to provide the details about how to enable/integrate
@ -32,8 +32,8 @@ program ``cmake`` (or ``cmake3``), a text mode interactive user
interface (TUI) program ``ccmake`` (or ``ccmake3``), or a graphical user
interface (GUI) program ``cmake-gui``. All of them are portable
software available on all supported platforms and can be used
interchangeably. The minimum supported CMake version is 3.10 (3.12 or
later is recommended).
interchangeably. As of LAMMPS version 2 August 2023, the minimum
required CMake version is 3.16.
All details about features and settings for CMake are in the `CMake
online documentation <https://cmake.org/documentation/>`_. We focus
@ -43,11 +43,20 @@ Prerequisites
-------------
This tutorial assumes that you are operating in a command-line environment
using a shell like Bash.
using a shell like Bash or Zsh.
- Linux: any Terminal window will work
- macOS: launch the Terminal application.
- Windows 10: install and run the :doc:`Windows Subsystem for Linux <Howto_wsl>`
- Linux: any Terminal window will work or text console
- macOS: launch the Terminal application
- Windows 10 or 11: install and run the :doc:`Windows Subsystem for Linux <Howto_wsl>`
- other Unix-like operating systems like FreeBSD
.. note::
It is also possible to use CMake on Windows 10 or 11 through either the Microsoft
Visual Studio IDE with the bundled CMake or from the Windows command prompt using
a separately installed CMake package, both using the native Microsoft Visual C++
compilers and (optionally) the Microsoft MPI SDK. This tutorial, however, only
covers unix-like command line interfaces.
We also assume that you have downloaded and unpacked a recent LAMMPS source code package
or used Git to create a clone of the LAMMPS sources on your compilation machine.
@ -338,8 +347,6 @@ Some common LAMMPS specific variables
- common compiler flags, for optimization or instrumentation (default:)
* - ``LAMMPS_MACHINE``
- when set to ``name`` the LAMMPS executable and library will be called ``lmp_name`` and ``liblammps_name.a``
* - ``LAMMPS_EXCEPTIONS``
- when set to ``on`` errors will throw a C++ exception instead of aborting (default: ``off``)
* - ``FFT``
- select which FFT library to use: ``FFTW3``, ``MKL``, ``KISS`` (default, unless FFTW3 is found)
* - ``FFT_SINGLE``
@ -412,9 +419,9 @@ interface (``ccmake`` or ``cmake-gui``).
Using a preset to select a compiler package (``clang.cmake``,
``gcc.cmake``, ``intel.cmake``, ``oneapi.cmake``, or ``pgi.cmake``)
are an exception to the mechanism of updating the configuration incrementally,
as they will trigger a reset of cached internal CMake settings and thus
reset settings to their default values.
are an exception to the mechanism of updating the configuration
incrementally, as they will trigger a reset of cached internal CMake
settings and thus reset settings to their default values.
Compilation and build targets
-----------------------------

10
doc/src/Howto_github.rst
View File

@ -480,11 +480,11 @@ Some recent changes to the workflow are not captured in this tutorial.
For example, in addition to the *develop* branch, to which all new
features should be submitted, there is also a *release*, a *stable*, and
a *maintenance* branch; the *release* branch is updated from the
*develop* as part of a feature release, and *stable* (together with
*release*) are updated from *develop* when a stable release is made. In
between stable releases, selected bug fixes and infrastructure updates
are back-ported from the *develop* branch to the *maintenance* branch
and occasionally merged to *stable* as an update release.
*develop* branch as part of a "feature release", and *stable* (together
with *release*) are updated from *develop* when a "stable release" is
made. In between stable releases, selected bug fixes and infrastructure
updates are back-ported from the *develop* branch to the *maintenance*
branch and occasionally merged to *stable* as an update release.
Furthermore, the naming of the release tags now follow the pattern
"patch_<Day><Month><Year>" to simplify comparisons between releases.

700
doc/src/Howto_lammps_gui.rst Normal file
View File

@ -0,0 +1,700 @@
Using the LAMMPS GUI
====================
This document describes **LAMMPS GUI version 1.5**.
-----
LAMMPS GUI is a graphical text editor customized for editing LAMMPS
input files that is linked to the :ref:`LAMMPS library <lammps_c_api>`
and thus can run LAMMPS directly using the contents of the editor's text
buffer as input. It can retrieve and display information from LAMMPS
while it is running, display visualizations created with the :doc:`dump
image command <dump_image>`, and is adapted specifically for editing
LAMMPS input files through text completion and reformatting, and linking
to the online LAMMPS documentation for known LAMMPS commands and styles.
.. note::
Pre-compiled, ready-to-use LAMMPS GUI executables for Linux (Ubuntu
20.04LTS or later and compatible), macOS (version 11 aka Big Sur or
later), and Windows (version 10 or later) :ref:`are available
<lammps_gui_install>` for download. They may be linked to a
development version of LAMMPS in case they need features not yet
available in a released version. Serial LAMMPS executables of the
same LAMMPS version are included as well. The source code for the
LAMMPS GUI is included in the LAMMPS source code and can be found in
the ``tools/lammps-gui`` folder. It can be compiled alongside LAMMPS
when :doc:`compiling with CMake <Build_cmake>`.
LAMMPS GUI tries to provide an experience similar to what people
traditionally would do to run LAMMPS using a command line window:
- editing inputs with a text editor
- run LAMMPS on the input with selected command line flags
- and then use or extract data from the created files and visualize it
That procedure is quite effective for people proficient in using the
command line, as that allows them to use tools for the individual steps
which they are most comfortable with. It is often required when running
LAMMPS on high-performance computing facilities.
The main benefit of using the LAMMPS GUI application instead is that
many basic tasks can be done directly from the GUI without switching to
a text console window or using external programs, let alone writing
scripts to extract data from the generated output. It also integrates
well with graphical desktop environments.
LAMMPS GUI thus makes it easier for beginners to get started running
simple LAMMPS simulations. It is very suitable for tutorials on LAMMPS
since you only need to learn how to use a single program for most tasks
and thus time can be saved and people can focus on learning LAMMPS. It
is also designed to keep the barrier low when you decide to switch to a
full featured, standalone programming editor and more sophisticated
visualization and analysis tools and run LAMMPS from a command line.
The following text provides a detailed tour of the features and
functionality of the LAMMPS GUI.
Suggestions for new features and reports of bugs are always welcome.
You can use the :doc:`the same channels as for LAMMPS itself
<Errors_bugs>` for that purpose.
-----
Main window
-----------
When LAMMPS GUI starts, it will show a main window with either an
empty buffer or the contents of a loaded file. In the latter case it
may look like the following:
.. image:: JPG/lammps-gui-main.png
:align: center
:scale: 50%
There is the typical menu bar at the top, then the main editor buffer,
and a status bar at the bottom. The input file contents are shown
with line numbers on the left and the input is colored according to
the LAMMPS input file syntax. The status bar shows the status of
LAMMPS execution on the left (e.g. "Ready." when idle) and the current
working directory on the right. The name of the current file in the
buffer is shown in the window title; the word `*modified*` is added if
the buffer edits have not yet saved to a file. The size of the main
window will be stored when exiting and restored when starting again.
Opening Files
^^^^^^^^^^^^^
The LAMMPS GUI application will try to open the first command line
argument as a LAMMPS input script, further arguments are ignored.
When no argument is given, LAMMPS GUI will start with an empty buffer.
Files can also be opened via the ``File`` menu or by drag-and-drop of
a file from a graphical file manager into the editor window. Only one
file can be open at a time, so opening a new file with a filled buffer
will close the buffer. If the buffer has unsaved modifications, you
will be asked to either cancel the operation, discard the changes, or
save them.
Running LAMMPS
^^^^^^^^^^^^^^
From within the LAMMPS GUI main window LAMMPS can be started either from
the ``Run`` menu using the ``Run LAMMPS from Editor Buffer`` entry, by
the keyboard shortcut `Ctrl-Enter` (`Command-Enter` on macOS), or by
clicking on the green "Run" button in the status bar. All of these
operations will cause LAMMPS to process the entire input script, which
may contain multiple :doc:`run <run>` or :doc:`minimize <minimize>`
commands.
LAMMPS runs in a separate thread, so the GUI stays responsive and is
able to interact with the running calculation and access data it
produces. It is important to note that running LAMMPS this way is
using the contents of the input buffer for the run (via the
:cpp:func:`lammps_commands_string()` function of the LAMMPS C-library
interface), and **not** the original file it was read from. Thus, if
there are unsaved changes in the buffer, they *will* be used. As an
alternative, it is also possible to run LAMMPS by reading the contents
of a file from the ``Run LAMMPS from File`` menu entry or with
`Ctrl-Shift-Enter`. This option may be required in some rare cases
where the input uses some functionality that is not compatible with
running LAMMPS from a string buffer. For consistency, any unsaved
changes in the buffer must be either saved to the file or undone
before LAMMPS can be run from a file.
.. image:: JPG/lammps-gui-running.png
:align: center
:scale: 75%
While LAMMPS is running, the contents of the status bar change. On
the left side there is a text indicating that LAMMPS is running, which
will also show the number of active threads, if thread-parallel
acceleration was selected in the ``Preferences`` dialog. On the right
side, a progress bar is shown that displays the estimated progress for
the current :doc:`run command <run>`.
Also, the line number of the currently executed command will be
highlighted in green.
.. image:: JPG/lammps-gui-run-highlight.png
:align: center
:scale: 75%
If an error occurs (in the example below the command :doc:`label
<label>` was incorrectly capitalized as "Label"), an error message
dialog will be shown and the line of the input which triggered the
error will be highlighted. The state of LAMMPS in the status bar will
be set to "Failed." instead of "Ready."
.. image:: JPG/lammps-gui-run-error.png
:align: center
:scale: 75%
Up to three additional windows will open during a run:
- a log window with the captured screen output
- a chart window with a line graph created from the thermodynamic output of the run
- a slide show window with images created by a :doc:`dump image command <dump_image>`
More information on those windows and how to adjust their behavior and
contents is given below.
An active LAMMPS run can be stopped cleanly by using either the ``Stop
LAMMPS`` entry in the ``Run`` menu, the keyboard shortcut `Ctrl-/`
(`Command-/` on macOS), or by clicking on the red button in the status
bar. This will cause the running LAMMPS process to complete the current
timestep (or iteration for energy minimization) and then complete the
processing of the buffer while skipping all run or minimize commands.
This is equivalent to the input script command :doc:`timer timeout 0
<timer>` and is implemented by calling the
:cpp:func:`lammps_force_timeout()` function of the LAMMPS C-library
interface. Please see the corresponding documentation pages to
understand the implications of this operation.
Log Window
----------
By default, when starting a run, a "Log Window" will open that displays
the current screen output of the LAMMPS calculation, that would normally
be seen in the command line window, as shown below.
.. image:: JPG/lammps-gui-log.png
:align: center
:scale: 50%
LAMMPS GUI captures the screen output as it is generated and updates
the log window regularly during a run.
By default, the log window will be replaced each time a run is started.
The runs are counted and the run number for the current run is displayed
in the window title. It is possible to change the behavior of LAMMPS
GUI in the preferences dialog to create a *new* log window for every run
or to not show the current log window. It is also possible to show or
hide the *current* log window from the ``View`` menu.
The text in the log window is read-only and cannot be modified, but
keyboard shortcuts to select and copy all or parts of the text can be
used to transfer text to another program. Also, the keyboard shortcut
`Ctrl-S` (`Command-S` on macOS) is available to save the log buffer to a
file. The "Select All" and "Copy" functions, as well as a "Save Log to
File" option are also available from a context menu by clicking with the
right mouse button into the log window text area.
Chart Window
------------
By default, when starting a run, a "Chart Window" will open that
displays a plot of thermodynamic output of the LAMMPS calculation as
shown below.
.. image:: JPG/lammps-gui-chart.png
:align: center
:scale: 50%
The drop down menu on the top right allows selection of different
properties that are computed and written to thermo output. Only one
property can be shown at a time. The plots will be updated with new
data as the run progresses, so they can be used to visually monitor the
evolution of available properties. The window title will show the
current run number that this chart window corresponds to. Same as
explained for the log window above, by default, the chart window will
be replaced on each new run, but the behavior can be changed in the
preferences dialog.
From the ``File`` menu on the top left, it is possible to save an image
of the currently displayed plot or export the data in either plain text
columns (for use by plotting tools like `gnuplot
<http://www.gnuplot.info/>`_ or `grace
<https://plasma-gate.weizmann.ac.il/Grace/>`_), or as CSV data which can
be imported for further processing with Microsoft Excel or `pandas
<https://pandas.pydata.org/>`_
Thermo output data from successive run commands in the input script will
be combined into a single data set unless the format, number, or names
of output columns are changed with a :doc:`thermo_style <thermo_style>`
or a :doc:`thermo_modify <thermo_modify>` command, or the current time
step is reset with :doc:`reset_timestep <reset_timestep>`, or if a
:doc:`clear <clear>` command is issued.
Image Slide Show
----------------
By default, if the LAMMPS input contains a :doc:`dump image
<dump_image>` command, a "Slide Show" window will open which loads and
displays the images created by LAMMPS as they are written.
.. image:: JPG/lammps-gui-slideshow.png
:align: center
:scale: 50%
The various buttons at the bottom right of the window allow single
stepping through the sequence of images or playing an animation (as a
continuous loop or once from first to last). It is also possible to
zoom in or zoom out of the displayed images, and to export the slide
show animation to a movie file, if `ffmpeg <https://ffmpeg.org/>`_ is
installed.
Variable Info
-------------
During a run, it may be of interest to monitor the value of input script
variables, for example to monitor the progress of loops. This can be
done by enabling the "Variables Window" in the ``View`` menu or by using
the `Ctrl-Shift-W` keyboard shortcut. This will show info similar to
the :doc:`info variables <info>` command in a separate window as shown
below.
.. image:: JPG/lammps-gui-variable-info.png
:align: center
:scale: 75%
Like the log and chart windows, its content is continuously updated
during a run. It will show "(none)" if there are no variables
defined. Note that it is also possible to *set* :doc:`index style
variables <variable>`, that would normally be set via command line
flags, via the "Set Variables..." dialog from the ``Run`` menu.
LAMMPS GUI will automatically set the variable "gui_run" to the
current value of the run counter. That way it would be possible
to automatically record a log for each run attempt by using the
command
.. code-block:: LAMMPS
log logfile-${gui_run}.txt
at the beginning of an input file. That would record logs to files
``logfile-1.txt``, ``logfile-2.txt``, and so on for successive runs.
Viewing Snapshot Images
-----------------------
By selecting the ``Create Image`` entry in the ``Run`` menu, or by
hitting the `Ctrl-I` (`Command-I` on macOS) keyboard shortcut, or by
clicking on the "palette" button in the status bar, LAMMPS GUI will send
a custom :doc:`write_dump image <dump_image>` command to LAMMPS and read
the resulting snapshot image with the current state of the system into
an image viewer window. This functionality is not available *during* an
ongoing run. When LAMMPS is not yet initialized, LAMMPS GUI will try to
identify the line with the first run or minimize command and execute all
command up to that line from the input buffer and then add a "run 0"
command. This will initialize the system so an image of the initial
state of the system can be rendered. If there was an error, the
snapshot image viewer will not appear.
When possible, LAMMPS GUI will try to detect which elements the atoms
correspond to (via their mass) and then colorize them in the image
accordingly. Otherwise the default predefined sequence of colors is
assigned to the different atom types.
.. image:: JPG/lammps-gui-image.png
:align: center
:scale: 50%
The default image size, some default image quality settings, the view
style and some colors can be changed in the ``Preferences`` dialog
window. From the image viewer window further adjustments can be made:
actual image size, high-quality (SSAO) rendering, anti-aliasing, view
style, display of box or axes, zoom factor. The view of the system
can be rotated horizontally and vertically. It is also possible to
only display the atoms within a group defined in the input script
(default is "all"). After each change, the image is rendered again
and the display updated. The small palette icon on the top left will
be colored while LAMMPS is running to render the new image; it will be
grayed out when it is finished. When there are many atoms to render
and high quality images with anti-aliasing are requested, re-rendering
may take several seconds. From the ``File`` menu of the image window,
the current image can be saved to a file or copied into the
cut-n-paste buffer for pasting into another application.
Editor Functions
----------------
The editor has most of the usual functionality that similar programs
have: text selection via mouse or with cursor moves while holding the
Shift key, Cut (`Ctrl-X`), Copy (`Ctrl-C`), Paste (`Ctrl-V`), Undo
(`Ctrl-Z`), Redo (`Ctrl-Shift-Z`), Select All (`Ctrl-A`). When trying
to exit the editor with a modified buffer, a dialog will pop up asking
whether to cancel the exit operation, or to save or not save the buffer
contents to a file.
Context Specific Word Completion
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
By default, LAMMPS GUI will display a small pop-up frame with possible
choices for LAMMPS input script commands or styles after 2 characters of
a word have been typed.
.. image:: JPG/lammps-gui-complete.png
:align: center
:scale: 75%
The word can then be completed through selecting an entry by scrolling
up and down with the cursor keys and selecting with the 'Enter' key or
by clicking on the entry with the mouse. The automatic completion
pop-up can be disabled in the ``Preferences`` dialog, but the completion
can still be requested manually by either hitting the 'Shift-TAB' key or
by right-clicking with the mouse and selecting the option from the
context menu. Most of the completion information is taken from the
LAMMPS instance and thus it will be adjusted to only show available
options that have been enabled while compiling LAMMPS. That, however,
excludes accelerated styles and commands; for improved clarity, only the
non-suffix version of styles are shown.
Line Reformatting
^^^^^^^^^^^^^^^^^
The editor supports reformatting lines according to the syntax in order
to have consistently aligned lines. This primarily means adding
whitespace padding to commands, type specifiers, IDs and names. This
reformatting is performed by default when hitting the 'Enter' key to
start a new line. This feature can be turned on or off in the
``Preferences`` dialog, but it can still be manually performed by
hitting the 'TAB' key. The amount of padding can also be changed in the
``Preferences`` dialog.
Internally this functionality is achieved by splitting the line into
"words" and then putting it back together with padding added where the
context can be detected; otherwise a single space is used between words.
Context Specific Help
^^^^^^^^^^^^^^^^^^^^^
.. image:: JPG/lammps-gui-popup-help.png
:align: center
:scale: 50%
A unique feature of the LAMMPS GUI is the option to look up the
documentation for the command in the current line. This can be done by
either clicking the right mouse button or by using the `Ctrl-?` keyboard
shortcut. When clicking the mouse there are additional entries in the
context menu that will open the corresponding documentation page in the
online LAMMPS documentation. When using the keyboard, the first of
those entries will be chosen directly.
Menu
----
The menu bar has entries ``File``, ``Edit``, ``Run``, ``View``, and
``About``. Instead of using the mouse to click on them, the individual
menus can also be activated by hitting the `Alt` key together with the
corresponding underlined letter, that is `Alt-F` will activate the
``File`` menu. For the corresponding activated sub-menus, the key
corresponding the underlined letters can again be used to select entries
instead of using the mouse.
File
^^^^
The ``File`` menu offers the usual options:
- ``New`` will clear the current buffer and reset the file name to ``*unknown*``
- ``Open`` will open a dialog to select a new file
- ``Save`` will save the current file; if the file name is ``*unknown*``
a dialog will open to select a new file name
- ``Save As`` will open a dialog to select and new file name and save
the buffer to it
- ``Quit`` will exit LAMMPS GUI. If there are unsaved changes, a dialog
will appear to either cancel the operation, or to save or not save the
edited file.
In addition, up to 5 recent file names will be listed after the
``Open`` entry that allows re-opening recent files. This list is
stored when quitting and recovered when starting again.
Edit
^^^^
The ``Edit`` menu offers the usual editor functions like ``Undo``,
``Redo``, ``Cut``, ``Copy``, ``Paste``. It can also open a
``Preferences`` dialog (keyboard shortcut `Ctrl-P`) and allows deletion
of all stored preferences so they will be reset to default values.
Run
^^^
The ``Run`` menu has options to start and stop a LAMMPS process.
Rather than calling the LAMMPS executable as a separate executable,
the LAMMPS GUI is linked to the LAMMPS library and thus can run LAMMPS
internally through the :ref:`LAMMPS C-library interface
<lammps_c_api>`.
Specifically, a LAMMPS instance will be created by calling
:cpp:func:`lammps_open_no_mpi`. The buffer contents then executed by
calling :cpp:func:`lammps_commands_string`. Certain commands and
features are only available after a LAMMPS instance is created. Its
presence is indicated by a small LAMMPS ``L`` logo in the status bar
at the bottom left of the main window. As an alternative, it is also
possible to run LAMMPS using the contents of the edited file by
reading the file. This is mainly provided as a fallback option in
case the input uses some feature that is not available when running
from a string buffer.
The LAMMPS calculation will be run in a concurrent thread so that the
GUI can stay responsive and be updated during the run. This can be
used to tell the running LAMMPS instance to stop at the next timestep.
The ``Stop LAMMPS`` entry will do this by calling
:cpp:func:`lammps_force_timeout`, which is equivalent to a :doc:`timer
timeout 0 <timer>` command.
The ``Set Variables...`` entry will open a dialog box where
:doc:`index style variables <variable>` can be set. Those variables
will be passed to the LAMMPS instance when it is created and are thus
set *before* a run is started.
.. image:: JPG/lammps-gui-variables.png
:align: center
:scale: 75%
The ``Set Variables`` dialog will be pre-populated with entries that
are set as index variables in the input and any variables that are
used but not defined, if the built-in parser can detect them. New
rows for additional variables can be added through the ``Add Row``
button and existing rows can be deleted by clicking on the ``X`` icons
on the right.
The ``Create Image`` entry will send a :doc:`dump image <dump_image>`
command to the LAMMPS instance, read the resulting file, and show it
in an ``Image Viewer`` window.
The ``View in OVITO`` entry will launch `OVITO <https://ovito.org>`_
with a :doc:`data file <write_data>` containing the current state of
the system. This option is only available if the LAMMPS GUI can find
the OVITO executable in the system path.
The ``View in VMD`` entry will launch VMD with a :doc:`data file
<write_data>` containing the current state of the system. This option
is only available if the LAMMPS GUI can find the VMD executable in the
system path.
View
^^^^
The ``View`` menu offers to show or hide additional windows with log
output, charts, slide show, variables, or snapshot images. The
default settings for their visibility can be changed in the
``Preferences dialog``.
About
^^^^^
The ``About`` menu finally offers a couple of dialog windows and an
option to launch the LAMMPS online documentation in a web browser.
The ``About LAMMPS`` entry displays a dialog with a summary of the
configuration settings of the LAMMPS library in use and the version
number of LAMMPS GUI itself. The ``Quick Help`` displays a dialog
with a minimal description of LAMMPS GUI. The ``LAMMPS GUI Howto``
entry will open this documentation page from the online documentation
in a web browser window. The ``LAMMPS Manual`` entry will open the
main page of the LAMMPS documentation in the web browser.
-----
Preferences
-----------
The ``Preferences`` dialog allows customization of the behavior and
look of the LAMMPS GUI application. The settings are grouped and each
group is displayed within a tab.
.. |guiprefs1| image:: JPG/lammps-gui-prefs-general.png
:width: 24%
.. |guiprefs2| image:: JPG/lammps-gui-prefs-accel.png
:width: 24%
.. |guiprefs3| image:: JPG/lammps-gui-prefs-image.png
:width: 24%
.. |guiprefs4| image:: JPG/lammps-gui-prefs-editor.png
:width: 24%
|guiprefs1| |guiprefs2| |guiprefs3| |guiprefs4|
General Settings:
^^^^^^^^^^^^^^^^^
- *Echo input to log:* when checked, all input commands, including
variable expansions, will be echoed to the log window. This is
equivalent to using `-echo screen` at the command line. There is no
log *file* produced by default, since LAMMPS GUI uses `-log none`.
- *Include citation details:* when checked full citation info will be
included to the log window. This is equivalent to using `-cite
screen` on the command line.
- *Show log window by default:* when checked, the screen output of a
LAMMPS run will be collected in a log window during the run
- *Show chart window by default:* when checked, the thermodynamic
output of a LAMMPS run will be collected and displayed in a chart
window as line graphs.
- *Show slide show window by default:* when checked, a slide show
window will be shown with images from a dump image command, if
present, in the LAMMPS input.
- *Replace log window on new run:* when checked, an existing log
window will be replaced on a new LAMMPS run, otherwise each run will
create a new log window.
- *Replace chart window on new run:* when checked, an existing chart
window will be replaced on a new LAMMPS run, otherwise each run will
create a new chart window.
- *Replace image window on new render:* when checked, an existing
chart window will be replaced when a new snapshot image is requested,
otherwise each command will create a new image window.
- *Path to LAMMPS Shared Library File:* this option is only visible
when LAMMPS GUI was compiled to load the LAMMPS library at run time
instead of being linked to it directly. With the ``Browse..`` button
or by changing the text, a different shared library file with a
different compilation of LAMMPS with different settings or from a
different version can be loaded. After this setting was changed,
LAMMPS GUI needs to be re-launched.
- *Select Default Font:* Opens a font selection dialog where the type
and size for the default font (used for everything but the editor and
log) of the application can be set.
- *Select Text Font:* Opens a font selection dialog where the type and
size for the text editor and log font of the application can be set.
- *GUI update interval:* Allows to set the time interval between GUI
and data updates during a LAMMPS run in milliseconds. The default is
to update the GUI every 100 milliseconds. This is good for most cases.
For LAMMPS runs that run very fast, however, data may be missed and
through lowering this interval, this can be corrected. However, this
will make the GUI use more resources, which may be a problem on some
computers with slower CPUs. The default value is 100 milliseconds.
Accelerators:
^^^^^^^^^^^^^
This tab enables selection of an accelerator package for LAMMPS to use
and is equivalent to using the `-suffix` and `-package` flags on the
command line. Only settings supported by the LAMMPS library and local
hardware are available. The `Number of threads` field allows setting
the maximum number of threads for the accelerator packages that use
threads.
Snapshot Image:
^^^^^^^^^^^^^^^
This tab allows setting defaults for the snapshot images displayed in
the ``Image Viewer`` window, such as its dimensions and the zoom
factor applied. The *Antialias* switch will render images with twice
the number of pixels for width and height and then smoothly scale the
image back to the requested size. This produces higher quality images
with smoother edges at the expense of requiring more CPU time to
render the image. The *HQ Image mode* option turns on screen space
ambient occlusion (SSAO) mode when rendering images. This is also
more time consuming, but produces a more 'spatial' representation of
the system shading of atoms by their depth. The *VDW Style* checkbox
selects whether atoms are represented by space filling spheres when
checked or by smaller spheres and sticks. Finally there are a couple
of drop down lists to select the background and box colors.
Editor Settings:
^^^^^^^^^^^^^^^^
This tab allows tweaking settings of the editor window. Specifically
the amount of padding to be added to LAMMPS commands, types or type
ranges, IDs (e.g. for fixes), and names (e.g. for groups). The value
set is the minimum width for the text element and it can be chosen in
the range between 1 and 32.
The two settings which follow enable or disable the automatic
reformatting when hitting the 'Enter' key and the automatic display of
the completion pop-up window.
-----------
Keyboard Shortcuts
------------------
Almost all functionality is accessible from the menu of the editor
window or through keyboard shortcuts. The following shortcuts are
available (On macOS use the Command key instead of Ctrl/Control).
.. list-table::
:header-rows: 1
:widths: auto
* - Shortcut
- Function
- Shortcut
- Function
- Shortcut
- Function
* - Ctrl+N
- New File
- Ctrl+Z
- Undo edit
- Ctrl+Enter
- Run Input
* - Ctrl+O
- Open File
- Ctrl+Shift+Z
- Redo edit
- Ctrl+/
- Stop Active Run
* - Ctrl+S
- Save File
- Ctrl+C
- Copy text
- Ctrl+Shift+V
- Set Variables
* - Ctrl+Shift+S
- Save File As
- Ctrl+X
- Cut text
- Ctrl+I
- Snapshot Image
* - Ctrl+Q
- Quit Application
- Ctrl+V
- Paste text
- Ctrl+L
- Slide Show
* - Ctrl+W
- Close Window
- Ctrl+A
- Select All
- Ctrl+P
- Preferences
* - Ctrl+Shift+A
- About LAMMPS
- Ctrl+Shift+H
- Quick Help
- Ctrl+Shift+G
- LAMMPS GUI Howto
* - Ctrl+Shift+M
- LAMMPS Manual
- Ctrl+?
- Context Help
- Ctrl+Shift+W
- Show Variables
* - Ctrl+Shift+Enter
- Run File
- TAB
- Reformat line
- Shift+TAB
- Show Completions
Further editing keybindings `are documented with the Qt documentation
<https://doc.qt.io/qt-5/qplaintextedit.html#editing-key-bindings>`_. In
case of conflicts the list above takes precedence.
All other windows only support a subset of keyboard shortcuts listed
above. Typically, the shortcuts `Ctrl-/` (Stop Run), `Ctrl-W` (Close
Window), and `Ctrl-Q` (Quit Application) are supported.

371
doc/src/Howto_moltemplate.rst Normal file
View File

@ -0,0 +1,371 @@
Moltemplate Tutorial
====================
In this tutorial, we are going to use the tool :ref:`Moltemplate
<moltemplate>` to set up a classical molecular dynamic simulation using
the :ref:`OPLS-AA force field <OPLSAA96>`. The first
task is to describe an organic compound and create a complete input deck
for LAMMPS. The second task is to map the OPLS-AA force field to a
molecular sample created with an external tool, e.g. PACKMOL, and
exported as a PDB file. The files used in this tutorial can be found
in the ``tools/moltemplate/tutorial-files`` folder of the LAMMPS
source code distribution.
Simulating an organic solvent
"""""""""""""""""""""""""""""
This example aims to create a cubic box of the organic solvent
formamide.
The first step is to create a molecular topology in the
LAMMPS-template (LT) file format representing a single molecule, which
will be stored in a Moltemplate object called ``_FAM inherits OPLSAA {}``.
This command states that the object ``_FAM`` is based on an existing
object called ``OPLSAA``, which contains OPLS-AA parameters, atom type
definitions, partial charges, masses and bond-angle rules for many organic
and biological compounds.
The atomic structure is the starting point to populate the command
``write('Data Atoms') {}``, which will write the ``Atoms`` section in the
LAMMPS data file. The OPLS-AA force field uses the ``atom_style full``,
therefore, this column format is used:
``# atomID molID atomType charge coordX coordY coordZ``.
The ``atomID``\ s are replaced with Moltemplate ``$``-type variables, which
are then substituted with unique numerical IDs. The same logic is applied
to the ``molID``, except that the same variable is used for the whole
molecule. The atom types are assigned using ``@``-type variables. The
assignment of atom types (e.g. ``@atom:177``, ``@atom:178``) is done using
the OPLS-AA atom types defined in the "In Charges" section of the file
``oplsaa.lt``, looking for a reasonable match with the description of the atom.
The resulting file (``formamide.lt``) follows:
.. code-block:: bash
_FAM inherits OPLSAA {
# atomID molID atomType charge coordX coordY coordZ
write('Data Atoms') {
$atom:C00 $mol @atom:177 0.00 0.100 0.490 0.0
$atom:O01 $mol @atom:178 0.00 1.091 -0.250 0.0
$atom:N02 $mol @atom:179 0.00 -1.121 -0.181 0.0
$atom:H03 $mol @atom:182 0.00 -2.013 0.272 0.0
$atom:H04 $mol @atom:182 0.00 -1.056 -1.190 0.0
$atom:H05 $mol @atom:221 0.00 0.144 1.570 0.0
}
# A list of the bonds in the molecule:
# BondID AtomID1 AtomID2
write('Data Bond List') {
$bond:C1 $atom:C00 $atom:O01
$bond:C2 $atom:C00 $atom:H05
$bond:C3 $atom:C00 $atom:N02
$bond:C4 $atom:N02 $atom:H03
$bond:C5 $atom:N02 $atom:H04
}
}
You don't have to specify the charge in this example because they will
be assigned according to the atom type. Analogously, only a
"Data Bond List" section is needed as the atom type will determine the
bond type. The other bonded interactions (e.g. angles,
dihedrals, and impropers) will be automatically generated by
Moltemplate.
If the simulation is non-neutral, or Moltemplate complains that you have
missing bond, angle, or dihedral types, this means at least one of your
atom types is incorrect.
The second step is to create a master file with instructions to build a
starting structure and the LAMMPS commands to run an NPT simulation. The
master file (``solv_01.lt``) follows:
.. code-block:: bash
# Import the force field.
import /usr/local/moltemplate/moltemplate/force_fields/oplsaa.lt
import formamide.lt # after oplsaa.lt, as it depends on it.
# Create the input sample.
solv = new _FAM [5].move( 4.6, 0, 0)
[5].move( 0, 4.6, 0)
[5].move( 0, 0, 4.6)
solv[*][*][*].move(-11.5, -11.5, -11.5)
# Set the simulation box.
write_once("Data Boundary") {
-11.5 11.5 xlo xhi
-11.5 11.5 ylo yhi
-11.5 11.5 zlo zhi
}
# Create an input deck for LAMMPS.
write_once("In Init"){
# Input variables.
variable run string solv_01 # output name
variable ts equal 1 # timestep
variable temp equal 300 # equilibrium temperature
variable p equal 1. # equilibrium pressure
variable d equal 1000 # output frequency
variable equi equal 5000 # Equilibration steps
variable prod equal 30000 # Production steps
# PBC (set them before the creation of the box).
boundary p p p
}
# Run an NPT simulation.
write_once("In Run"){
# Derived variables.
variable tcouple equal \$\{ts\}*100
variable pcouple equal \$\{ts\}*1000
# Output.
thermo \$d
thermo_style custom step etotal evdwl ecoul elong ebond eangle &
edihed eimp ke pe temp press vol density cpu
thermo_modify flush yes
# Trajectory.
dump TRJ all dcd \$d \$\{run\}.dcd
dump_modify TRJ unwrap yes
# Thermalisation and relaxation, NPT ensemble.
timestep \$\{ts\}
fix NPT all npt temp \$\{temp\} \$\{temp\} \$\{tcouple\} iso \$p \$p \$\{pcouple\}
velocity all create \$\{temp\} 858096 dist gaussian
# Short runs to update the PPPM settings as the box shinks.
run \$\{equi\} post no
run \$\{equi\} post no
run \$\{equi\} post no
run \$\{equi\}
# From now on, the density shouldn't change too much.
run \$\{prod\}
unfix NPT
}
The first two commands insert the content of files ``oplsaa.lt`` and
``formamide.lt`` into the master file. At this point, we can use the
command ``solv = new _FAM [N]`` to create N copies of a molecule of type
``_FAM``. In this case, we create an array of 5*5*5 molecules on a cubic
grid using the coordinate transformation command ``.move( 4.6, 0, 0)``.
See the Moltemplate documentation to learn more about the syntax. As
the sample was created from scratch, we also specify the simulation box
size in the "Data Boundary" section.
The LAMMPS setting for the force field are specified in the file
``oplsaa.lt`` and are written automatically in the input deck. We also
specify the boundary conditions and a set of variables in
the "In Init" section. The remaining commands to run an NPT simulation
are written in the "In Run" section. Note that in this script, LAMMPS
variables are protected with the escape character ``\`` to distinguish
them from Moltemplate variables, e.g. ``\$\{run\}`` is a LAMMPS
variable that is written in the input deck as ``${run}``.
Compile the master file with:
.. code-block:: bash
moltemplate.sh -overlay-all solv_01.lt
And execute the simulation with the following:
.. code-block:: bash
mpirun -np 4 lmp -in solv_01.in -l solv_01.log
.. figure:: JPG/solv_01.png
:figwidth: 80%
:figclass: align-center
Snapshot of the sample at the beginning and end of the simulation.
Rendered with Ovito.
Mapping an existing structure
"""""""""""""""""""""""""""""
Another helpful way to use Moltemplate is mapping an existing molecular
sample to a force field. This is useful when a complex sample is
assembled from different simulations or created with specialized
software (e.g. PACKMOL). As in the previous example, all molecular
species in the sample must be defined using single-molecule Moltemplate
objects. For this example, we use a short polymer in a box containing
water molecules and ions in the PDB file ``model.pdb``.
It is essential to understand that the order of atoms in the PDB file
and in the Moltemplate master script must match, as we are using the
coordinates from the PDB file in the order they appear. The order of
atoms and molecules in the PDB file provided is as follows:
- 500 water molecules, with atoms ordered in this sequence:
.. parsed-literal::
ATOM 1 O MOL D 1 5.901 7.384 1.103 0.00 0.00 DUM
ATOM 2 H MOL D 1 6.047 8.238 0.581 0.00 0.00 DUM
ATOM 3 H MOL D 1 6.188 7.533 2.057 0.00 0.00 DUM
- 1 polymer molecule.
- 1 Ca\ :sup:`2+` ion.
- 2 Cl\ :sup:`-` ions.
In the master LT file, this sequence of molecules is matched with the
following commands:
.. code-block:: bash
# Create the sample.
wat=new SPC[500]
pol=new PolyNIPAM[1]
cat=new Ca[1]
ani=new Cl[2]
Note that the first command would create 500 water molecules in the
same position in space, and the other commands will use the coordinates
specified in the corresponding molecular topology block. However, the
coordinates will be overwritten by rendering an external atomic
structure file. Note that if the same molecule species are scattered in
the input structure, it is recommended to reorder and group together
for molecule types to facilitate the creation of the input sample.
The molecular topology for the polymer is created as in the previous
example, with the atom types assigned as in the following schema:
.. figure:: JPG/PolyNIPAM.jpg
:scale: 30%
:align: center
Atom types assigned to the polymer's repeating unit.
The molecular topology of the water and ions is stated directly into
the master file for the sake of space, but they could also be written
in a separate file(s) and imported before the sample is created.
The resulting master LT file defining short annealing at a fixed volume
(NVT) follows:
.. code-block:: bash
# Use the OPLS-AA force field for all species.
import /usr/local/moltemplate/moltemplate/force_fields/oplsaa.lt
import PolyNIPAM.lt
# Define the SPC water and ions as in the OPLS-AA
Ca inherits OPLSAA {
write("Data Atoms"){
$atom:a1 $mol:. @atom:354 0.0 0.00000 0.00000 0.000000
}
}
Cl inherits OPLSAA {
write("Data Atoms"){
$atom:a1 $mol:. @atom:344 0.0 0.00000 0.00000 0.000000
}
}
SPC inherits OPLSAA {
write("Data Atoms"){
$atom:O $mol:. @atom:76 0. 0.0000000 0.00000 0.000000
$atom:H1 $mol:. @atom:77 0. 0.8164904 0.00000 0.5773590
$atom:H2 $mol:. @atom:77 0. -0.8164904 0.00000 0.5773590
}
write("Data Bond List") {
$bond:OH1 $atom:O $atom:H1
$bond:OH2 $atom:O $atom:H2
}
}
# Create the sample.
wat=new SPC[500]
pol=new PolyNIPAM[1]
cat=new Ca[1]
ani=new Cl[2]
# Periodic boundary conditions:
write_once("Data Boundary"){
0 26 xlo xhi
0 26 ylo yhi
0 26 zlo zhi
}
# Define the input variables.
write_once("In Init"){
# Input variables.
variable run string sample01 # output name
variable ts equal 2 # timestep
variable temp equal 298.15 # equilibrium temperature
variable p equal 1. # equilibrium pressure
variable equi equal 30000 # equilibration steps
# PBC (set them before the creation of the box).
boundary p p p
neighbor 3 bin
}
# Run an NVT simulation.
write_once("In Run"){
# Set the output.
thermo 1000
thermo_style custom step etotal evdwl ecoul elong ebond eangle &
edihed eimp pe ke temp press atoms vol density cpu
thermo_modify flush yes
compute pe1 all pe/atom pair
dump TRJ all custom 100 \$\{run\}.dump id xu yu zu c_pe1
# Minimise the input structure, just in case.
minimize .01 .001 1000 100000
write_data \$\{run\}.min
# Set the constrains.
group watergroup type @atom:76 @atom:77
fix 0 watergroup shake 0.0001 10 0 b @bond:042_043 a @angle:043_042_043
# Short annealing.
timestep \$\{ts\}
fix 1 all nvt temp \$\{temp\} \$\{temp\} \$(100*dt)
velocity all create \$\{temp\} 315443
run \$\{equi\}
unfix 1
}
In this example, the water model is SPC and it is defined in the
``oplsaa.lt`` file with atom types ``@atom:76`` and ``@atom:77``. For
water we also use the ``group`` and ``fix shake`` commands with
Moltemplate ``@``-type variables, to ensure consistency with the
numerical values assigned during compilation. To identify the bond and
angle types, look for the extended ``@atom`` IDs, which in this case
are:
.. code-block:: bash
replace{ @atom:76 @atom:76_b042_a042_d042_i042 }
replace{ @atom:77 @atom:77_b043_a043_d043_i043 }
From which we can identify the following "Data Bonds By Type":
``@bond:042_043 @atom:*_b042*_a*_d*_i* @atom:*_b043*_a*_d*_i*`` and
"Data Angles By Type": ``@angle:043_042_043 @atom:*_b*_a043*_d*_i*
@atom:*_b*_a042*_d*_i* @atom:*_b*_a043*_d*_i*``
Compile the master file with:
.. code-block:: bash
moltemplate.sh -overlay-all -pdb model.pdb sample01.lt
And execute the simulation with the following:
.. code-block:: bash
mpirun -np 4 lmp -in sample01.in -l sample01.log
.. figure:: JPG/sample01.png
:figwidth: 50%
:figclass: align-center
Sample visualized with Ovito loading the trajectory into the DATA
file written after minimization.
------------
.. _OPLSAA96:
**(OPLS-AA)** Jorgensen, Maxwell, Tirado-Rives, J Am Chem Soc,
118(45), 11225-11236 (1996).

140
doc/src/Howto_output.rst
View File

@ -1,7 +1,7 @@
Output from LAMMPS (thermo, dumps, computes, fixes, variables)
==============================================================
There are four basic kinds of LAMMPS output:
There are four basic forms of LAMMPS output:
* :doc:`Thermodynamic output <thermo_style>`, which is a list of
quantities printed every few timesteps to the screen and logfile.
@ -20,18 +20,17 @@ output files, depending on what :doc:`dump <dump>` and :doc:`fix <fix>`
commands you specify.
As discussed below, LAMMPS gives you a variety of ways to determine
what quantities are computed and printed when the thermodynamics,
what quantities are calculated and printed when the thermodynamics,
dump, or fix commands listed above perform output. Throughout this
discussion, note that users can also :doc:`add their own computes and
fixes to LAMMPS <Modify>` which can then generate values that can then
be output with these commands.
fixes to LAMMPS <Modify>` which can generate values that can then be
output with these commands.
The following subsections discuss different LAMMPS commands related
to output and the kind of data they operate on and produce:
* :ref:`Global/per-atom/local/per-grid data <global>`
* :ref:`Scalar/vector/array data <scalar>`
* :ref:`Per-grid data <grid>`
* :ref:`Disambiguation <disambiguation>`
* :ref:`Thermodynamic output <thermo>`
* :ref:`Dump file output <dump>`
@ -48,34 +47,65 @@ to output and the kind of data they operate on and produce:
Global/per-atom/local/per-grid data
-----------------------------------
Various output-related commands work with four different styles of
Various output-related commands work with four different "styles" of
data: global, per-atom, local, and per-grid. A global datum is one or
more system-wide values, e.g. the temperature of the system. A
per-atom datum is one or more values per atom, e.g. the kinetic energy
of each atom. Local datums are calculated by each processor based on
the atoms it owns, but there may be zero or more per atom, e.g. a list
the atoms it owns, and there may be zero or more per atom, e.g. a list
of bond distances.
A per-grid datum is one or more values per grid cell, for a grid which
overlays the simulation domain. The grid cells and the data they
store are distributed across processors; each processor owns the grid
cells whose center point falls within its subdomain.
overlays the simulation domain. Similar to atoms and per-atom data,
the grid cells and the data they store are distributed across
processors; each processor owns the grid cells whose center points
fall within its subdomain.
.. _scalar:
Scalar/vector/array data
------------------------
Global, per-atom, and local datums can come in three kinds: a single
scalar value, a vector of values, or a 2d array of values. The doc
page for a "compute" or "fix" or "variable" that generates data will
specify both the style and kind of data it produces, e.g. a per-atom
vector.
Global, per-atom, local, and per-grid datums can come in three
"kinds": a single scalar value, a vector of values, or a 2d array of
values. More specifically these are the valid kinds for each style:
When a quantity is accessed, as in many of the output commands
discussed below, it can be referenced via the following bracket
notation, where ID in this case is the ID of a compute. The leading
"c\_" would be replaced by "f\_" for a fix, or "v\_" for a variable:
* global scalar
* global vector
* global array
* per-atom vector
* per-atom array
* local vector
* local array
* per-grid vector
* per-grid array
A per-atom vector means a single value per atom; the "vector" is the
length of the number of atoms. A per-atom array means multiple values
per atom. Similarly a local vector or array means one or multiple
values per entity (e.g. per bond in the system). And a per-grid
vector or array means one or multiple values per grid cell.
The doc page for a compute or fix or variable that generates data will
specify both the styles and kinds of data it produces, e.g. a per-atom
vector. Note that a compute or fix may generate multiple styles and
kinds of output. However, for per-atom data only a vector or array is
output, never both. Likewise for per-local and per-grid data. An
example of a fix which generates multiple styles and kinds of data is
the :doc:`fix mdi/qm <fix_mdi_qm>` command. It outputs a global
scalar, global vector, and per-atom array for the quantum mechanical
energy and virial of the system and forces on each atom.
By contrast, different variable styles generate only a single kind of
data: a global scalar for an equal-style variable, global vector for a
vector-style variable, and a per-atom vector for an atom-style
variable.
When data is accessed by another command, as in many of the output
commands discussed below, it can be referenced via the following
bracket notation, where ID in this case is the ID of a compute. The
leading "c\_" would be replaced by "f\_" for a fix, or "v\_" for a
variable (and ID would be the name of the variable):
+-------------+--------------------------------------------+
| c_ID | entire scalar, vector, or array |
@ -85,40 +115,56 @@ notation, where ID in this case is the ID of a compute. The leading
| c_ID[I][J] | one element of array |
+-------------+--------------------------------------------+
In other words, using one bracket reduces the dimension of the data
once (vector -> scalar, array -> vector). Using two brackets reduces
the dimension twice (array -> scalar). Thus a command that uses
scalar values as input can typically also process elements of a vector
or array.
Note that using one bracket reduces the dimension of the data once
(vector -> scalar, array -> vector). Using two brackets reduces the
dimension twice (array -> scalar). Thus a command that uses scalar
values as input can also conceptually operate on an element of a
vector or array.
.. _grid:
Per-grid data
------------------------
Per-grid data can come in two kinds: a vector of values (one per grid
cekk), or a 2d array of values (multiple values per grid ckk). The
doc page for a "compute" or "fix" that generates data will specify
names for both the grid(s) and datum(s) it produces, e.g. per-grid
vectors or arrays, which can be referenced by other commands. See the
:doc:`Howto grid <Howto_grid>` doc page for more details.
Per-grid vectors or arrays are accessed similarly, except that the ID
for the compute or fix includes a grid name and a data name. This is
because a fix or compute can create multiple grids (of different
sizes) and multiple sets of data (for each grid). The fix or compute
defines names for each grid and for each data set, so that all of them
can be accessed by other commands. See the :doc:`Howto grid
<Howto_grid>` doc page for more details.
.. _disambiguation:
Disambiguation
--------------
Some computes and fixes produce data in multiple styles, e.g. a global
scalar and a per-atom vector. Usually the context in which the input
script references the data determines which style is meant. Example:
if a compute provides both a global scalar and a per-atom vector, the
former will be accessed by using ``c_ID`` in an equal-style variable,
while the latter will be accessed by using ``c_ID`` in an atom-style
variable. Note that atom-style variable formulas can also access
global scalars, but in this case it is not possible to do this
directly because of the ambiguity. Instead, an equal-style variable
can be defined which accesses the global scalar, and that variable can
be used in the atom-style variable formula in place of ``c_ID``.
When a compute or fix produces data in multiple styles, e.g. global
and per-atom, a reference to the data can sometimes be ambiguous.
Usually the context in which the input script references the data
determines which style is meant.
For example, if a compute outputs a global vector and a per-atom
array, an element of the global vector will be accessed by using
``c_ID[I]`` in :doc:`thermodynamic output <thermo_style>`, while a
column of the per-atom array will be accessed by using ``c_ID[I]`` in
a :doc:`dump custom <dump>` command.
However, if a :doc:`atom-style variable <variable>` references
``c_ID[I]``, then it could be intended to refer to a single element of
the global vector or a column of the per-atom array. The doc page for
any command that has a potential ambiguity (variables are the most
common) will explain how to resolve the ambiguity.
In this case, an atom-style variables references per-atom data if it
exists. If access to an element of a global vector is needed (as in
this example), an equal-style variable which references the value can
be defined and used in the atom-style variable formula instead.
Similarly, :doc:`thermodynamic output <thermo_style>` can only
reference global data from a compute or fix. But you can indirectly
access per-atom data as follows. The reference ``c_ID[245][2]`` for
the ID of a :doc:`compute displace/atom <compute_displace_atom>`
command, refers to the y-component of displacement for the atom with
ID 245. While you cannot use that reference directly in the
:doc:`thermo_style <thermo_style>` command, you can use it an
equal-style variable formula, and then reference the variable in
thermodynamic output.
.. _thermo:
@ -389,7 +435,7 @@ output and input data types must match, e.g. global/per-atom/local
data and scalar/vector/array data.
Also note that, as described above, when a command takes a scalar as
input, that could be an element of a vector or array. Likewise a
input, that could also be an element of a vector or array. Likewise a
vector input could be a column of an array.
+--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+

28
doc/src/Howto_pylammps.rst
View File

@ -53,10 +53,10 @@ System-wide Installation
Step 1: Building LAMMPS as a shared library
"""""""""""""""""""""""""""""""""""""""""""
To use LAMMPS inside of Python it has to be compiled as shared library. This
library is then loaded by the Python interface. In this example we enable the
MOLECULE package and compile LAMMPS with C++ exceptions, PNG, JPEG and FFMPEG
output support enabled.
To use LAMMPS inside of Python it has to be compiled as shared
library. This library is then loaded by the Python interface. In this
example we enable the MOLECULE package and compile LAMMPS with PNG, JPEG
and FFMPEG output support enabled.
Step 1a: For the CMake based build system, the steps are:
@ -66,7 +66,7 @@ Step 1a: For the CMake based build system, the steps are:
cd $LAMMPS_DIR/build-shared
# MPI, PNG, Jpeg, FFMPEG are auto-detected
cmake ../cmake -DPKG_MOLECULE=yes -DLAMMPS_EXCEPTIONS=yes -DBUILD_LIB=yes -DBUILD_SHARED_LIBS=yes
cmake ../cmake -DPKG_MOLECULE=yes -DBUILD_LIB=yes -DBUILD_SHARED_LIBS=yes
make
Step 1b: For the legacy, make based build system, the steps are:
@ -79,7 +79,7 @@ Step 1b: For the legacy, make based build system, the steps are:
make yes-MOLECULE
# compile shared library using Makefile
make mpi mode=shlib LMP_INC="-DLAMMPS_PNG -DLAMMPS_JPEG -DLAMMPS_FFMPEG -DLAMMPS_EXCEPTIONS" JPG_LIB="-lpng -ljpeg"
make mpi mode=shlib LMP_INC="-DLAMMPS_PNG -DLAMMPS_JPEG -DLAMMPS_FFMPEG" JPG_LIB="-lpng -ljpeg"
Step 2: Installing the LAMMPS Python package
""""""""""""""""""""""""""""""""""""""""""""
@ -133,7 +133,7 @@ to the location in the virtual environment with:
.. code-block:: bash
cmake . -DPYTHON_EXECUTABLE=$(which python)
cmake . -DPython_EXECUTABLE=$(which python)
# install LAMMPS package in virtualenv
(testing) make install-python
@ -356,18 +356,16 @@ Together with matplotlib plotting data out of LAMMPS becomes simple:
Error handling with PyLammps
----------------------------
Compiling the shared library with C++ exception support provides a better error
handling experience. Without exceptions the LAMMPS code will terminate the
current Python process with an error message. C++ exceptions allow capturing
them on the C++ side and rethrowing them on the Python side. This way you
can handle LAMMPS errors through the Python exception handling mechanism.
Using C++ exceptions in LAMMPS for errors allows capturing them on the
C++ side and rethrowing them on the Python side. This way you can handle
LAMMPS errors through the Python exception handling mechanism.
.. warning::
Capturing a LAMMPS exception in Python can still mean that the
current LAMMPS process is in an illegal state and must be terminated. It is
advised to save your data and terminate the Python instance as quickly as
possible.
current LAMMPS process is in an illegal state and must be
terminated. It is advised to save your data and terminate the Python
instance as quickly as possible.
Using PyLammps in IPython notebooks and Jupyter
-----------------------------------------------

6
doc/src/Howto_spc.rst
View File

@ -69,15 +69,13 @@ SPC/E with rigid bonds.
timestep 1.0
fix rigid all shake 0.0001 10 10000 b 1 a 1
minimize 0.0 0.0 1000 10000
run 0 post no
reset_timestep 0
velocity all create 300.0 5463576
fix integrate all nvt temp 300.0 300.0 1.0
fix integrate all nvt temp 300.0 300.0 100.0
thermo_style custom step temp press etotal density pe ke
thermo 1000
run 20000 upto
write_data tip4p.data nocoeff
write_data spce.data nocoeff
.. _spce_molecule:
.. code-block::

39
doc/src/Howto_structured_data.rst
View File

@ -119,6 +119,45 @@ for example :doc:`dump yaml <dump>` or :doc:`fix ave/time <fix_ave_time>`
Depending on the kind of data being written, organization of the data
or the specific syntax used may change, but the principles are very
similar and all files should be readable with a suitable YAML parser.
A simple example for this is given below:
.. code-block:: python
import yaml
try:
from yaml import CSafeLoader as YamlLoader
except ImportError:
from yaml import SafeLoader as YamlLoader
timesteps = []
with open("dump.yaml", "r") as f:
data = yaml.load_all(f, Loader=YamlLoader)
for d in data:
print('Processing timestep %d' % d['timestep'])
timesteps.append(d)
print('Read %d timesteps from yaml dump' % len(timesteps))
print('Second timestep: ', timesteps[1]['timestep'])
print('Box info: x: ' , timesteps[1]['box'][0], ' y:', timesteps[1]['box'][1], ' z:',timesteps[1]['box'][2])
print('First 5 per-atom columns: ', timesteps[1]['keywords'][0:5])
print('Corresponding 10th atom data: ', timesteps[1]['data'][9][0:5])
The corresponding output for a YAML dump command added to the "melt" example is:
.. parsed-literal::
Processing timestep 0
Processing timestep 50
Processing timestep 100
Processing timestep 150
Processing timestep 200
Processing timestep 250
Read 6 timesteps from yaml dump
Second timestep: 50
Box info: x: [0, 16.795961913825074] y: [0, 16.795961913825074] z: [0, 16.795961913825074]
First 5 per-atom columns: ['id', 'type', 'x', 'y', 'z']
Corresponding 10th atom data: [10, 1, 4.43828, 0.968481, 0.108555]
Processing scalar data with Python
----------------------------------

4
doc/src/Howto_tip3p.rst
View File

@ -128,11 +128,11 @@ TIP3P with rigid bonds.
fix rigid all shake 0.001 10 10000 b 1 a 1
minimize 0.0 0.0 1000 10000
run 0 post no
reset_timestep 0
timestep 1.0
velocity all create 300.0 5463576
fix integrate all nvt temp 300 300 1.0
fix integrate all nvt temp 300 300 100.0
thermo_style custom step temp press etotal pe

32
doc/src/Howto_tip4p.rst
View File

@ -180,29 +180,33 @@ file changed):
fix rigid all shake 0.001 10 10000 b 1 a 1
minimize 0.0 0.0 1000 10000
run 0 post no
reset_timestep 0
timestep 1.0
velocity all create 300.0 5463576
fix integrate all nvt temp 300 300 1.0
fix integrate all nvt temp 300 300 100.0
thermo_style custom step temp press etotal pe
thermo 1000
run 20000
write_data tip3p.data nocoeff
write_data tip4p-implicit.data nocoeff
Below is the code for a LAMMPS input file using the explicit method and
a TIP4P molecule file. Because of using :doc:`fix rigid/nvt/small
a TIP4P molecule file. Because of using :doc:`fix rigid/small
<fix_rigid>` no bonds need to be defined and thus no extra storage needs
to be reserved for them, but we need to switch to atom style full or use
:doc:`fix property/atom mol <fix_property_atom>` so that fix
rigid/nvt/small can identify rigid bodies by their molecule ID:
to be reserved for them, but we need to either switch to atom style full
or use :doc:`fix property/atom mol <fix_property_atom>` so that fix
rigid/small can identify rigid bodies by their molecule ID. Also a
:doc:`neigh_modify exclude <neigh_modify>` command is added to exclude
computing intramolecular non-bonded interactions, since those are
removed by the rigid fix anyway:
.. code-block:: LAMMPS
units real
atom_style charge
atom_modify map array
region box block -5 5 -5 5 -5 5
create_box 3 box
@ -215,18 +219,18 @@ rigid/nvt/small can identify rigid bodies by their molecule ID:
pair_coeff 2 2 0.0 1.0
pair_coeff 3 3 0.0 1.0
fix mol all property/atom mol
fix mol all property/atom mol ghost yes
molecule water tip4p.mol
create_atoms 0 random 33 34564 NULL mol water 25367 overlap 1.33
neigh_modify exclude molecule/intra all
timestep 0.1
fix integrate all rigid/nvt/small molecule temp 300.0 300.0 1.0
velocity all create 300.0 5463576
timestep 0.5
fix integrate all rigid/small molecule langevin 300.0 300.0 100.0 2345634
thermo_style custom step temp press etotal density pe ke
thermo 1000
run 20000
write_data tip4p.data nocoeff
thermo 2000
run 40000
write_data tip4p-explicit.data nocoeff
.. _tip4p_molecule:
.. code-block::

17
doc/src/Howto_tip5p.rst
View File

@ -81,16 +81,19 @@ long-range Coulombic solver (e.g. Ewald or PPPM in LAMMPS).
Below is the code for a LAMMPS input file for setting up a simulation of
TIP5P water with a molecule file. Because of using :doc:`fix
rigid/nvt/small <fix_rigid>` no bonds need to be defined and thus no
extra storage needs to be reserved for them, but we need to switch to
rigid/small <fix_rigid>` no bonds need to be defined and thus no extra
storage needs to be reserved for them, but we need to either switch to
atom style full or use :doc:`fix property/atom mol <fix_property_atom>`
so that fix rigid/nvt/small can identify rigid bodies by their molecule
ID:
so that fix rigid/small can identify rigid bodies by their molecule ID.
Also a :doc:`neigh_modify exclude <neigh_modify>` command is added to
exclude computing intramolecular non-bonded interactions, since those
are removed by the rigid fix anyway:
.. code-block:: LAMMPS
units real
atom_style charge
atom_modify map array
region box block -5 5 -5 5 -5 5
create_box 3 box
@ -106,11 +109,11 @@ ID:
fix mol all property/atom mol
molecule water tip5p.mol
create_atoms 0 random 33 34564 NULL mol water 25367 overlap 1.33
neigh_modify exclude molecule/intra all
timestep 0.20
fix integrate all rigid/nvt/small molecule temp 300.0 300.0 1.0
timestep 0.5
fix integrate all rigid/small molecule langevin 300.0 300.0 50.0 235664
reset_timestep 0
velocity all create 300.0 5463576
thermo_style custom step temp press etotal density pe ke
thermo 1000

3
doc/src/Howto_triclinic.rst
View File

@ -12,7 +12,8 @@ is created, e.g. by the :doc:`create_box <create_box>` or
:doc:`read_data <read_data>` or :doc:`read_restart <read_restart>`
commands. Additionally, LAMMPS defines box size parameters lx,ly,lz
where lx = xhi-xlo, and similarly in the y and z dimensions. The 6
parameters, as well as lx,ly,lz, can be output via the :doc:`thermo_style custom <thermo_style>` command.
parameters, as well as lx,ly,lz, can be output via the
:doc:`thermo_style custom <thermo_style>` command.
LAMMPS also allows simulations to be performed in triclinic
(non-orthogonal) simulation boxes shaped as a parallelepiped with

20
doc/src/Install_git.rst
View File

@ -28,16 +28,16 @@ provides `limited support for subversion clients <svn_>`_.
You can follow the LAMMPS development on 4 different git branches:
* **release** : this branch is updated with every patch or feature release;
updates are always "fast-forward" merges from *develop*
* **develop** : this branch follows the ongoing development and
is updated with every merge commit of a pull request
* **stable** : this branch is updated from the *release* branch with
every stable release version and also has selected bug fixes with every
update release when the *maintenance* branch is merged into it
* **maintenance** : this branch collects back-ported bug fixes from the
*develop* branch to the *stable* branch. It is used to update *stable*
for update releases and it synchronized with *stable* at each stable release.
* **develop** : this branch follows the ongoing development and is
updated with every merge commit of a pull request
* **release** : this branch is updated with every "feature release";
updates are always "fast-forward" merges from *develop*
* **maintenance** : this branch collects back-ported bug fixes from the
*develop* branch to the *stable* branch. It is used to update the
*stable* branch for "stable update releases".
* **stable** : this branch is updated from the *release* branch with
every "stable release" version and also has selected bug fixes with
every "update release" when the *maintenance* branch is merged into it
To access the git repositories on your box, use the clone command to
create a local copy of the LAMMPS repository with a command like:

2
doc/src/Install_mac.rst
View File

@ -5,7 +5,7 @@ LAMMPS can be downloaded, built, and configured for macOS with `Homebrew
<homebrew_>`_. (Alternatively, see the installation instructions for
:doc:`downloading an executable via Conda <Install_conda>`.) The
following LAMMPS packages are unavailable at this time because of
additional requirements not yet met: GPU, KOKKOS, MSCG, MPIIO, POEMS,
additional requirements not yet met: GPU, KOKKOS, MSCG, POEMS,
VORONOI.
After installing Homebrew, you can install LAMMPS on your system with

9
doc/src/Install_windows.rst
View File

@ -18,11 +18,10 @@ needed to run in parallel with MPI.
The LAMMPS binaries contain *all* :doc:`optional packages <Packages>`
included in the source distribution except: ADIOS, H5MD, KIM, ML-PACE,
ML-QUIP, MSCG, NETCDF, PLUMED, QMMM, SCAFACOS, and VTK. The serial
version also does not include the MPIIO and LATBOLTZ packages. The
PYTHON package is only available in the Python installers that bundle a
Python runtime. The GPU package is compiled for OpenCL with mixed
precision kernels.
ML-QUIP, MSCG, NETCDF, QMMM, SCAFACOS, and VTK. The serial version also
does not include the LATBOLTZ package. The PYTHON package is only
available in the Python installers that bundle a Python runtime. The
GPU package is compiled for OpenCL with mixed precision kernels.
The LAMMPS library is compiled as a shared library and the
:doc:`LAMMPS Python module <Python_module>` is installed, so that

14
doc/src/Intro_nonfeatures.rst
View File

@ -5,7 +5,7 @@ LAMMPS is designed to be a fast, parallel engine for molecular
dynamics (MD) simulations. It provides only a modest amount of
functionality for setting up simulations and analyzing their output.
Specifically, LAMMPS was not conceived and designed for:
Originally, LAMMPS was not conceived and designed for:
* being run through a GUI
* building molecular systems, or building molecular topologies
@ -14,9 +14,10 @@ Specifically, LAMMPS was not conceived and designed for:
* visualize your MD simulation interactively
* plot your output data
Over the years some of these limitations have been reduced or
removed, through features added to LAMMPS or external tools
that either closely interface with LAMMPS or extend LAMMPS.
Over the years many of these limitations have been reduced or
removed. In part through features added to LAMMPS and in part
through external tools that either closely interface with LAMMPS
or extend LAMMPS.
Here are suggestions on how to perform these tasks:
@ -24,8 +25,9 @@ Here are suggestions on how to perform these tasks:
wraps the library interface is provided. Thus, GUI interfaces can be
written in Python or C/C++ that run LAMMPS and visualize or plot its
output. Examples of this are provided in the python directory and
described on the :doc:`Python <Python_head>` doc page. Also, there
are several external wrappers or GUI front ends.
described on the :doc:`Python <Python_head>` doc page. As of version
2 August 2023 :ref:`a GUI tool <lammps_gui>` is included in LAMMPS.
Also, there are several external wrappers or GUI front ends.
* **Builder:** Several pre-processing tools are packaged with LAMMPS.
Some of them convert input files in formats produced by other MD codes
such as CHARMM, AMBER, or Insight into LAMMPS input formats. Some of

10
doc/src/Intro_portability.rst
View File

@ -12,7 +12,7 @@ Programming language standards
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Most of the C++ code currently requires a compiler compatible with the
C++11 standard, the KOKKOS package currently requires C++14. Most of
C++11 standard, the KOKKOS package currently requires C++17. Most of
the Python code is written to be compatible with Python 3.5 or later or
Python 2.7. Some Python scripts *require* Python 3 and a few others
still need to be ported from Python 2 to Python 3.
@ -25,7 +25,7 @@ LAMMPS can be compiled from source code using a (traditional) build
system based on shell scripts, a few shell utilities (grep, sed, cat,
tr) and the GNU make program. This requires running within a Bourne
shell (``/bin/sh``). Alternatively, a build system with different back ends
can be created using CMake. CMake must be at least version 3.10.
can be created using CMake. CMake must be at least version 3.16.
Operating systems
^^^^^^^^^^^^^^^^^
@ -62,9 +62,9 @@ regularly tested.
Portability compliance
^^^^^^^^^^^^^^^^^^^^^^
Only a subset of the LAMMPS source code is fully compliant to all of the
above mentioned standards. This is rather typical for projects like
LAMMPS that largely depend on contributions from the user community.
Only a subset of the LAMMPS source code is *fully* compliant to *all*
of the above mentioned standards. This is rather typical for projects
like LAMMPS that largely depend on contributions from the user community.
Not all contributors are trained as programmers and not all of them have
access to multiple platforms for testing. As part of the continuous
integration process, however, all contributions are automatically tested

BIN
doc/src/JPG/PolyNIPAM.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 40 KiB

BIN
doc/src/JPG/image.both.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 23 KiB

BIN
doc/src/JPG/image.default.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 22 KiB

BIN
doc/src/JPG/image.fsaa.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 23 KiB

BIN
doc/src/JPG/image.ssao.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 22 KiB

BIN
doc/src/JPG/lammps-classes.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 286 KiB

After

Width:  |  Height:  |  Size: 304 KiB

BIN
doc/src/JPG/lammps-gui-chart.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 105 KiB

BIN
doc/src/JPG/lammps-gui-complete.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 36 KiB

BIN
doc/src/JPG/lammps-gui-image.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 123 KiB

BIN
doc/src/JPG/lammps-gui-log.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 95 KiB

BIN
doc/src/JPG/lammps-gui-main.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 90 KiB

BIN
doc/src/JPG/lammps-gui-popup-help.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 130 KiB

BIN
doc/src/JPG/lammps-gui-prefs-accel.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 37 KiB

BIN
doc/src/JPG/lammps-gui-prefs-editor.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 44 KiB

BIN
doc/src/JPG/lammps-gui-prefs-general.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 81 KiB

BIN
doc/src/JPG/lammps-gui-prefs-image.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 50 KiB

BIN
doc/src/JPG/lammps-gui-run-error.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 41 KiB

BIN
doc/src/JPG/lammps-gui-run-highlight.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 26 KiB

BIN
doc/src/JPG/lammps-gui-running.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 21 KiB

BIN
doc/src/JPG/lammps-gui-slideshow.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 67 KiB

BIN
doc/src/JPG/lammps-gui-variable-info.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 19 KiB

BIN
doc/src/JPG/lammps-gui-variables.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 16 KiB

BIN
doc/src/JPG/lammps-invoke-python.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 36 KiB

After

Width:  |  Height:  |  Size: 38 KiB

BIN
doc/src/JPG/lammps-releases.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 68 KiB

BIN
doc/src/JPG/pylammps-invoke-lammps.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 36 KiB

After

Width:  |  Height:  |  Size: 36 KiB

BIN
doc/src/JPG/python-invoke-lammps.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 28 KiB

After

Width:  |  Height:  |  Size: 28 KiB

BIN
doc/src/JPG/sample01.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 808 KiB

BIN
doc/src/JPG/solv_01.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 86 KiB

16
doc/src/Library.rst
View File

@ -80,13 +80,15 @@ run LAMMPS in serial mode.
:class: note
If the LAMMPS executable encounters an error condition, it will abort
after printing an error message. For a library interface this is
usually not desirable. Thus LAMMPS can be compiled to to :ref:`throw
a C++ exception <exceptions>` instead. If enabled, the library
functions will catch those exceptions and return. The error status
:cpp:func:`can be queried <lammps_has_error>` and an :cpp:func:`error
message retrieved <lammps_get_last_error_message>`. We thus
recommend enabling C++ exceptions when using the library interface,
after printing an error message. It does so by catching the
exceptions that LAMMPS could throw. For a C library interface this
is usually not desirable since the calling code might lack the
ability to catch such exceptions. Thus, the library functions will
catch those exceptions and return from the affected functions. The
error status :cpp:func:`can be queried <lammps_has_error>` and an
:cpp:func:`error message retrieved <lammps_get_last_error_message>`.
This is, for example used by the :doc:`LAMMPS python module
<Python_module>` and then a suitable Python exception is thrown.
.. admonition:: Using the C library interface as a plugin
:class: note

6
doc/src/Library_objects.rst
View File

@ -9,6 +9,7 @@ fixes, or variables in LAMMPS using the following functions:
- :cpp:func:`lammps_extract_variable_datatype`
- :cpp:func:`lammps_extract_variable`
- :cpp:func:`lammps_set_variable`
- :cpp:func:`lammps_variable_info`
-----------------------
@ -37,6 +38,11 @@ fixes, or variables in LAMMPS using the following functions:
-----------------------
.. doxygenfunction:: lammps_variable_info
:project: progguide
-----------------------
.. doxygenenum:: _LMP_DATATYPE_CONST
.. doxygenenum:: _LMP_STYLE_CONST

6
doc/src/Library_properties.rst
View File

@ -5,6 +5,7 @@ This section documents the following functions:
- :cpp:func:`lammps_get_natoms`
- :cpp:func:`lammps_get_thermo`
- :cpp:func:`lammps_last_thermo`
- :cpp:func:`lammps_extract_box`
- :cpp:func:`lammps_reset_box`
- :cpp:func:`lammps_memory_usage`
@ -81,6 +82,11 @@ subdomains and processors.
-----------------------
.. doxygenfunction:: lammps_last_thermo
:project: progguide
-----------------------
.. doxygenfunction:: lammps_extract_box
:project: progguide

21
doc/src/Manual.rst
View File

@ -23,10 +23,23 @@ coordinated.
----------
The content for this manual is part of the LAMMPS distribution. The
online version always corresponds to the latest feature release version.
If needed, you can build a local copy of the manual as HTML pages or a
PDF file by following the steps on the :doc:`Build_manual` page. If you
The content for this manual is part of the LAMMPS distribution in its
doc directory.
* The version of the manual on the LAMMPS website corresponds to the
latest LAMMPS feature release. It is available at:
`https://docs.lammps.org/ <https://docs.lammps.org/>`_.
* A version of the manual corresponding to the latest LAMMPS stable
release (state of the *stable* branch on GitHub) is available online
at: `https://docs.lammps.org/stable/
<https://docs.lammps.org/stable/>`_
* A version of the manual with the features most recently added to
LAMMPS (state of the *develop* branch on GitHub) is available at:
`https://docs.lammps.org/latest/ <https://docs.lammps.org/latest/>`_
If needed, you can build a copy on your local machine of the manual
(HTML pages or PDF file) for the version of LAMMPS you have
downloaded. Follow the steps on the :doc:`Build_manual` page. If you
have difficulties viewing the pages, please :ref:`see this note
<webbrowser>`.

99
doc/src/Manual_version.rst
View File

@ -3,45 +3,25 @@ What does a LAMMPS version mean
The LAMMPS "version" is the date when it was released, such as 1 May
2014. LAMMPS is updated continuously, and we aim to keep it working
correctly and reliably at all times. You can follow its development
in a public `git repository on GitHub <https://github.com/lammps/lammps>`_.
Modifications of the LAMMPS source code (like bug fixes, code refactors,
updates to existing features, or addition of new features) are organized
into pull requests. Pull requests will be merged into the *develop*
branch of the git repository after they pass automated testing and code
review by the LAMMPS developers. When a sufficient number of changes
have accumulated *and* the *develop* branch version passes an extended
set of automated tests, we release it as a *feature release*, which are
currently made every 4 to 8 weeks. The *release* branch of the git
repository is updated with every such release. A summary of the most
important changes of the patch releases are on `this website page
<https://www.lammps.org/bug.html>`_. More detailed release notes are
`available on GitHub <https://github.com/lammps/lammps/releases/>`_.
Once or twice a year, we have a "stabilization period" where we apply
only bug fixes and small, non-intrusive changes to the *develop*
branch. At the same time, the code is subjected to more detailed and
thorough manual testing than the default automated testing. Also,
several variants of static code analysis are run to improve the overall
code quality, consistency, and compliance with programming standards,
best practices and style conventions.
The release after such a stabilization period is called a *stable*
version and both, the *release* and the *stable* branches are updated
with it. Between stable releases, we collect back-ported bug fixes and
updates from the *develop* branch in the *maintenance* branch. From the
*maintenance* branch we make occasional update releases and update the
*stable* branch accordingly.
correctly and reliably at all times. Also, several variants of static
code analysis are run regularly to maintain or improve the overall code
quality, consistency, and compliance with programming standards, best
practices and style conventions. You can follow its development in a
public `git repository on GitHub <https://github.com/lammps/lammps>`_.
Each version of LAMMPS contains all the documented *features* up to and
including its version date. For recently added features, we add markers
to the documentation at which specific LAMMPS version a feature or
keyword was added or significantly changed.
The version date is printed to the screen and log file every time you run
LAMMPS. It is also in the file src/version.h and in the LAMMPS
directory name created when you unpack a tarball. And it is on the
Identifying the Version
^^^^^^^^^^^^^^^^^^^^^^^
The version date is printed to the screen and log file every time you
run LAMMPS. There also is an indication, if a LAMMPS binary was
compiled from version with modifications **after** a release.
It is also visible in the file src/version.h and in the LAMMPS directory
name created when you unpack a downloaded tarball. And it is on the
first page of the :doc:`manual <Manual>`.
* If you browse the HTML pages of the online version of the LAMMPS
@ -53,3 +33,56 @@ first page of the :doc:`manual <Manual>`.
* If you browse the HTML pages included in your downloaded tarball, they
describe the version you have, which may be older than the online
version.
LAMMPS releases, branches, and tags
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. figure:: JPG/lammps-releases.png
:figclass: align-center
Relations between releases, main branches, and tags in the LAMMPS git repository
Development
"""""""""""
Modifications of the LAMMPS source code (like bug fixes, code
refactoring, updates to existing features, or addition of new features)
are organized into pull requests. Pull requests will be merged into the
*develop* branch of the git repository after they pass automated testing
and code review by the LAMMPS developers.
Feature Releases
""""""""""""""""
When a sufficient number of new features and updates have accumulated
*and* the LAMMPS version on the *develop* branch passes an extended set
of automated tests, we release it as a *feature release*, which are
currently made every 4 to 8 weeks. The *release* branch of the git
repository is updated with every such *feature release* and a tag in the
format ``patch_1May2014`` is added. A summary of the most important
changes of these releases for the current year are posted on `this
website page <https://www.lammps.org/bug.html>`_. More detailed release
notes are `available on GitHub
<https://github.com/lammps/lammps/releases/>`_.
Stable Releases
"""""""""""""""
About once a year, we release a *stable release* version of LAMMPS.
This is done after a "stabilization period" where we apply only bug
fixes and small, non-intrusive changes to the *develop* branch but no
new features. At the same time, the code is subjected to more detailed
and thorough manual testing than the default automated testing.
After such a *stable release*, both the *release* and the *stable*
branches are updated and two tags are applied, a ``patch_1May2014`` format
and a ``stable_1May2014`` format tag.
Stable Release Updates
""""""""""""""""""""""
Between *stable releases*, we collect bug fixes and updates back-ported
from the *develop* branch in a branch called *maintenance*. From the
*maintenance* branch we make occasional *stable update releases* and
update the *stable* branch accordingly. The first update to the
``stable_1May2014`` release would be tagged as
``stable_1May2014_update1``. These updates contain no new features.

42
doc/src/Modify_style.rst
View File

@ -28,20 +28,34 @@ Include files (varied)
packages and hard-to-find bugs have regularly manifested in the
past.
- Header files, especially those defining a "style", should only use
the absolute minimum number of include files and **must not**
contain any ``using`` statements. Typically, that would only be the
header for the base class. Instead, any include statements should
be put in the corresponding implementation files and forward
declarations be used. For implementation files, the "include what
you use" principle should be employed. However, there is the
notable exception that when the ``pointers.h`` header is included
(or one of the base classes derived from it) certain headers will
always be included and thus do not need to be explicitly specified.
These are: `mpi.h`, `cstddef`, `cstdio`, `cstdlib`, `string`,
`utils.h`, `vector`, `fmt/format.h`, `climits`, `cinttypes`. This
also means any such file can assume that `FILE`, `NULL`, and
`INT_MAX` are defined.
- Header files, especially those defining a "style", should only use the
absolute minimum number of include files and **must not** contain any
``using`` statements. Typically, that would only be the header for the
base class. Instead, any include statements should be put in the
corresponding implementation files and forward declarations be used.
For implementation files, the "include what you use" principle should
be employed. However, there is the notable exception that when the
``pointers.h`` header is included (or the header of one of the classes
derived from it), certain headers will *always* be included and thus
do not need to be explicitly specified. These are: `mpi.h`,
`cstddef`, `cstdio`, `cstdlib`, `string`, `utils.h`, `vector`,
`fmt/format.h`, `climits`, `cinttypes`. This also means any such file
can assume that `FILE`, `NULL`, and `INT_MAX` are defined.
- Class members variables should not be initialized in the header file,
but instead should be initialized either in the initializer list of
the constructor or explicitly assigned in the body of the constructor.
If the member variable is relevant to the functionality of a class
(for example when it stores a value from a command line argument), the
member variable declaration is followed by a brief comment explaining
its purpose and what its values can be. Class members that are
pointers should always be initialized to ``nullptr`` in the
initializer list of the constructor. This reduces clutter in the
header and avoids accessing uninitialized pointers, which leads to
hard to debug issues, class members are often implicitly initialized
to ``NULL`` on the first use (but *not* after a :doc:`clear command
<clear>`). Please see the files ``reset_atoms_mol.h`` and
``reset_atoms_mol.cpp`` as an example.
- System headers or headers from installed libraries are included with
angular brackets (example: ``#include <vector>``), while local

70
doc/src/Packages_details.rst
View File

@ -87,8 +87,6 @@ page gives those details.
* :ref:`MOFFF <PKG-MOFFF>`
* :ref:`MOLECULE <PKG-MOLECULE>`
* :ref:`MOLFILE <PKG-MOLFILE>`
* :ref:`MPIIO <PKG-MPIIO>`
* :ref:`MSCG <PKG-MSCG>`
* :ref:`NETCDF <PKG-NETCDF>`
* :ref:`OPENMP <PKG-OPENMP>`
* :ref:`OPT <PKG-OPT>`
@ -1257,7 +1255,7 @@ Also see the :ref:`GPU <PKG-GPU>`, :ref:`OPT <PKG-OPT>`, :ref:`INTEL
<PKG-INTEL>`, and :ref:`OPENMP <PKG-OPENMP>` packages, which have styles
optimized for CPUs, KNLs, and GPUs.
You must have a C++14 compatible compiler to use this package.
You must have a C++17 compatible compiler to use this package.
KOKKOS makes extensive use of advanced C++ features, which can
expose compiler bugs, especially when compiling for maximum
performance at high optimization levels. Please see the file
@ -2034,70 +2032,6 @@ This package has :ref:`specific installation instructions <molfile>` on the :doc
----------
.. _PKG-MPIIO:
MPIIO package
-------------
**Contents:**
Support for parallel output/input of dump and restart files via the
MPIIO library. It adds :doc:`dump styles <dump>` with a "mpiio" in
their style name. Restart files with an ".mpiio" suffix are also
written and read in parallel.
.. warning::
The MPIIO package is currently unmaintained and has become
unreliable. Use with caution.
**Install:**
The MPIIO package requires that LAMMPS is build in :ref:`MPI parallel mode <serial>`.
**Supporting info:**
* src/MPIIO: filenames -> commands
* :doc:`dump <dump>`
* :doc:`restart <restart>`
* :doc:`write_restart <write_restart>`
* :doc:`read_restart <read_restart>`
----------
.. _PKG-MSCG:
MSCG package
------------
**Contents:**
A :doc:`fix mscg <fix_mscg>` command which can parameterize a
Multi-Scale Coarse-Graining (MSCG) model using the open-source `MS-CG library <mscg-home_>`_.
.. _mscg-home: https://github.com/uchicago-voth/MSCG-release
To use this package you must have the MS-CG library available on your
system.
**Authors:** The fix was written by Lauren Abbott (Sandia). The MS-CG
library was developed by Jacob Wagner in Greg Voth's group at the
University of Chicago.
**Install:**
This package has :ref:`specific installation instructions <mscg>` on the :doc:`Build extras <Build_extras>` page.
**Supporting info:**
* src/MSCG: filenames -> commands
* src/MSCG/README
* lib/mscg/README
* examples/mscg
----------
.. _PKG-NETCDF:
NETCDF package
@ -2292,7 +2226,7 @@ and third order tensor from finite differences.
**Install:**
The PHONON package requires that also the :ref:`KSPACE <PKG-KSPACE>`
The fix phonon command also requires that the :ref:`KSPACE <PKG-KSPACE>`
package is installed.

10
doc/src/Packages_list.rst
View File

@ -333,16 +333,6 @@ whether an extra library is needed to build and use the package:
- :doc:`dump molfile <dump_molfile>`
- n/a
- ext
* - :ref:`MPIIO <PKG-MPIIO>`
- MPI parallel I/O dump and restart
- :doc:`dump <dump>`
- n/a
- no
* - :ref:`MSCG <PKG-MSCG>`
- multi-scale coarse-graining wrapper
- :doc:`fix mscg <fix_mscg>`
- mscg
- ext
* - :ref:`NETCDF <PKG-NETCDF>`
- dump output via NetCDF
- :doc:`dump netcdf <dump_netcdf>`

22
doc/src/Python_error.rst
View File

@ -1,11 +1,11 @@
Handling LAMMPS errors
*******************************
**********************
Compiling the shared library with :ref:`C++ exception support <exceptions>` provides a better error
handling experience. Without exceptions the LAMMPS code will terminate the
current Python process with an error message. C++ exceptions allow capturing
them on the C++ side and rethrowing them on the Python side. This way
LAMMPS errors can be handled through the Python exception handling mechanism.
LAMMPS and the LAMMPS library are compiled with :ref:`C++ exception support
<exceptions>` to provide a better error handling experience. LAMMPS errors
trigger throwing a C++ exception. These exceptions allow capturing errors on
the C++ side and rethrowing them on the Python side. This way LAMMPS errors
can be handled through the Python exception handling mechanism.
.. code-block:: python
@ -15,9 +15,7 @@ LAMMPS errors can be handled through the Python exception handling mechanism.
try:
# LAMMPS will normally terminate itself and the running process if an error
# occurs. This would kill the Python interpreter. To avoid this, make sure to
# compile with LAMMPS_EXCEPTIONS enabled. This ensures the library API calls
# will not terminate the parent process. Instead, the library wrapper will
# occurs. This would kill the Python interpreter. The library wrapper will
# detect that an error has occured and throw a Python exception
lmp.command('unknown')
@ -31,6 +29,6 @@ LAMMPS errors can be handled through the Python exception handling mechanism.
.. warning::
Capturing a LAMMPS exception in Python can still mean that the
current LAMMPS process is in an illegal state and must be terminated. It is
advised to save your data and terminate the Python instance as quickly as
possible.
current LAMMPS process is in an illegal state and must be
terminated. It is advised to save your data and terminate the Python
instance as quickly as possible when running in parallel with MPI.

3
doc/src/Python_install.rst
View File

@ -5,8 +5,7 @@ The LAMMPS Python module enables calling the :ref:`LAMMPS C library API
<lammps_c_api>` from Python by dynamically loading functions in the
LAMMPS shared library through the Python `ctypes <ctypes_>`_
module. Because of the dynamic loading, it is required that LAMMPS is
compiled in :ref:`"shared" mode <exe>`. It is also recommended to
compile LAMMPS with :ref:`C++ exceptions <exceptions>` enabled.
compiled in :ref:`"shared" mode <exe>`.
Two components are necessary for Python to be able to invoke LAMMPS code:

5
doc/src/Python_properties.rst
View File

@ -53,6 +53,7 @@ against invalid accesses.
* :py:meth:`version() <lammps.lammps.version()>`: return the numerical version id, e.g. LAMMPS 2 Sep 2015 -> 20150902
* :py:meth:`get_thermo() <lammps.lammps.get_thermo()>`: return current value of a thermo keyword
* :py:meth:`last_thermo() <lammps.lammps.last_thermo()>`: return a dictionary of the last thermodynamic output
* :py:meth:`get_natoms() <lammps.lammps.get_natoms()>`: total # of atoms as int
* :py:meth:`reset_box() <lammps.lammps.reset_box()>`: reset the simulation box size
* :py:meth:`extract_setting() <lammps.lammps.extract_setting()>`: return a global setting
@ -60,6 +61,10 @@ against invalid accesses.
* :py:meth:`extract_box() <lammps.lammps.extract_box()>`: extract box info
* :py:meth:`create_atoms() <lammps.lammps.create_atoms()>`: create N atoms with IDs, types, x, v, and image flags
**Properties**:
* :py:attr:`last_thermo_step <lammps.lammps.last_thermo_step>`: the last timestep thermodynamic output was computed
.. tab:: PyLammps/IPyLammps API
In addition to the functions provided by :py:class:`lammps <lammps.lammps>`, :py:class:`PyLammps <lammps.PyLammps>` objects

19
doc/src/Run_output.rst
View File

@ -49,14 +49,17 @@ simulation. An example set of statistics is shown here:
----------
The first section provides a global loop timing summary. The *loop time*
is the total wall-clock time for the simulation to run. The
*Performance* line is provided for convenience to help predict how long
it will take to run a desired physical simulation and to have numbers
useful for performance comparison between different simulation settings
or system sizes. The *CPU use* line provides the CPU utilization per
MPI task; it should be close to 100% times the number of OpenMP threads
(or 1 of not using OpenMP). Lower numbers correspond to delays due to
file I/O or insufficient thread utilization.
is the total wall-clock time for the MD steps of the simulation run,
excluding the time for initialization and setup (i.e. the parts that may
be skipped with :doc:`run N pre no <run>`). The *Performance* line is
provided for convenience to help predict how long it will take to run a
desired physical simulation and to have numbers useful for performance
comparison between different simulation settings or system sizes. The
*CPU use* line provides the CPU utilization per MPI task; it should be
close to 100% times the number of OpenMP threads (or 1 if not using
OpenMP). Lower numbers correspond to delays due to file I/O or
insufficient thread utilization from parts of the code that have not
been multi-threaded.
----------

23
doc/src/Speed_kokkos.rst
View File

@ -18,7 +18,7 @@ package was developed primarily by Christian Trott (Sandia) and Stan
Moore (Sandia) with contributions of various styles by others,
including Sikandar Mashayak (UIUC), Ray Shan (Sandia), and Dan Ibanez
(Sandia). For more information on developing using Kokkos abstractions
see the Kokkos `Wiki <https://github.com/kokkos/kokkos/wiki>`_.
see the `Kokkos Wiki <https://github.com/kokkos/kokkos/wiki>`_.
Kokkos currently provides support for 4 modes of execution (per MPI
task). These are Serial (MPI-only for CPUs and Intel Phi), OpenMP
@ -26,23 +26,30 @@ task). These are Serial (MPI-only for CPUs and Intel Phi), OpenMP
GPUs) and HIP (for AMD GPUs). You choose the mode at build time to
produce an executable compatible with a specific hardware.
.. admonition:: C++14 support
.. admonition:: C++17 support
:class: note
Kokkos requires using a compiler that supports the c++14 standard. For
some compilers, it may be necessary to add a flag to enable c++14 support.
For example, the GNU compiler uses the -std=c++14 flag. For a list of
compilers that have been tested with the Kokkos library, see the Kokkos
`README <https://github.com/kokkos/kokkos/blob/master/README.md>`_.
Kokkos requires using a compiler that supports the c++17 standard. For
some compilers, it may be necessary to add a flag to enable c++17 support.
For example, the GNU compiler uses the -std=c++17 flag. For a list of
compilers that have been tested with the Kokkos library, see the
`requirements document of the Kokkos Wiki
<https://kokkos.github.io/kokkos-core-wiki/requirements.html>`_.
.. admonition:: NVIDIA CUDA support
:class: note
To build with Kokkos support for NVIDIA GPUs, the NVIDIA CUDA toolkit
software version 9.0 or later must be installed on your system. See
software version 11.0 or later must be installed on your system. See
the discussion for the :doc:`GPU package <Speed_gpu>` for details of
how to check and do this.
.. admonition:: AMD ROCm (HIP) support
:class: note
To build with Kokkos support for AMD GPUs, the AMD ROCm toolkit
software version 5.2.0 or later must be installed on your system.
.. admonition:: CUDA and MPI library compatibility
:class: note

207
doc/src/Tools.rst
View File

@ -93,6 +93,7 @@ Miscellaneous tools
* :ref:`i-pi <ipi>`
* :ref:`kate <kate>`
* :ref:`LAMMPS shell <lammps_shell>`
* :ref:`LAMMPS GUI <lammps_gui>`
* :ref:`LAMMPS magic patterns for file(1) <magic>`
* :ref:`Offline build tool <offline>`
* :ref:`singularity/apptainer <singularity_tool>`
@ -634,6 +635,212 @@ you first need to use the :doc:`clear` command.
----------
.. _lammps_gui:
LAMMPS GUI
----------
.. versionadded:: 2Aug2023
Overview
^^^^^^^^
LAMMPS GUI is a graphical text editor customized for editing LAMMPS
input files that is linked to the :ref:`LAMMPS C-library <lammps_c_api>`
and thus can run LAMMPS directly using the contents of the editor's text
buffer as input. It can retrieve and display information from LAMMPS
while it is running, display visualizations created with the :doc:`dump
image command <dump_image>`, and is adapted specifically for editing
LAMMPS input files through text completion and reformatting, and linking
to the online LAMMPS documentation for known LAMMPS commands and styles.
This is similar to what people traditionally would do to run LAMMPS:
using a regular text editor to edit the input and run the necessary
commands, possibly including the text editor, too, from a command line
terminal window. This similarity is a design goal. While making it easy
for beginners to start with LAMMPS, it is also the intention to simplify
the transition to workflows like most experienced LAMMPS users do.
All features have been extensively exposed to keyboard shortcuts, so
that there is also appeal for experienced LAMMPS users for prototyping
and testing simulations setups.
Features
^^^^^^^^
A detailed discussion and explanation of all features and functionality
are in the :doc:`Howto_lammps_gui` tutorial Howto page.
Here are a few highlights of LAMMPS GUI
- Text editor with syntax highlighting customized for LAMMPS
- Text editor will switch working directory to folder of file in buffer
- Text editor will remember up to 5 recent files
- Context specific LAMMPS command help via online documentation
- LAMMPS is running in a concurrent thread, so the GUI remains responsive
- Support for most accelerator packages
- Progress bar indicates how far a run command is completed
- LAMMPS can be started and stopped with a hotkey
- Screen output is captured in a Log Window
- Thermodynamic output is captured and displayed as line graph in a Chart Window
- Indicator for currently executed command
- Indicator for line that caused an error
- Visualization of current state in Image Viewer (via :doc:`dump image <dump_image>`)
- Many adjustable settings and preferences that are persistent
- Dialog to set variables from the LAMMPS command line
Parallelization
^^^^^^^^^^^^^^^
Due to its nature as a graphical application, it is not possible to use
the LAMMPS GUI in parallel with MPI, but OpenMP multi-threading and GPU
acceleration is available and enabled by default.
Prerequisites and portability
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
LAMMPS GUI is programmed in C++ based on the C++11 standard and using
the `Qt GUI framework <https://www.qt.io/product/framework>`_.
Currently, Qt version 5.12 or later is required; Qt 5.15LTS is
recommended; support for Qt version 6.x is under active development and
thus far only tested with Qt 6.5LTS on Linux. Building LAMMPS with
CMake is required.
The LAMMPS GUI has been successfully compiled and tested on:
- Ubuntu Linux 20.04LTS x86_64 using GCC 9, Qt version 5.12
- Fedora Linux 38 x86\_64 using GCC 13 and Clang 16, Qt version 5.15LTS
- Fedora Linux 38 x86\_64 using GCC 13, Qt version 6.5LTS
- Apple macOS 12 (Monterey) and macOS 13 (Ventura) with Xcode on arm64 and x86\_64, Qt version 5.15LTS
- Windows 10 and 11 x86_64 with Visual Studio 2022 and Visual C++ 14.36, Qt version 5.15LTS
- Windows 10 and 11 x86_64 with MinGW / GCC 10.0 cross-compiler on Fedora 38, Qt version 5.15LTS
.. _lammps_gui_install:
Pre-compiled executables
^^^^^^^^^^^^^^^^^^^^^^^^
Pre-compiled LAMMPS executable packages that include the GUI are currently
available from https://download.lammps.org/static or
https://github.com/lammps/lammps/releases. You can unpack the archives
(or mount the macOS disk image) and run the GUI directly in place. The
folder may also be moved around and added to the ``PATH`` environment
variable so the executables will be found automatically. The LAMMPS GUI
executable is called ``lammps-gui`` and either takes no arguments or
attempts to load the first argument as LAMMPS input file.
Compilation
^^^^^^^^^^^
The source for the LAMMPS GUI is included with the LAMMPS source code
distribution in the folder ``tools/lammps-gui`` and thus it can be can
be built as part of a regular LAMMPS compilation. :doc:`Using CMake
<Howto_cmake>` is required. To enable its compilation, the CMake
variable ``-D BUILD_LAMMPS_GUI=on`` must be set when creating the CMake
configuration. All other settings (compiler, flags, compile type) for
LAMMPS GUI are then inherited from the regular LAMMPS build. If the Qt
library is packaged for Linux distributions, then its location is
typically auto-detected since the required CMake configuration files are
stored in a location where CMake can find them without additional help.
Otherwise, the location of the Qt library installation must be indicated
by setting ``-D Qt5_DIR=/path/to/qt5/lib/cmake/Qt5``, which is a path to
a folder inside the Qt installation that contains the file
``Qt5Config.cmake``. Similarly, for Qt6 the location of the Qt library
installation can be indicated by setting ``-D Qt6_DIR=/path/to/qt6/lib/cmake/Qt6``,
if necessary. When both, Qt5 and Qt6 are available, Qt6 will be preferred
unless ``-D LAMMPS_GUI_USE_QT5=yes`` is set.
It should be possible to build the LAMMPS GUI as a standalone
compilation (e.g. when LAMMPS has been compiled with traditional make),
then the CMake configuration needs to be told where to find the LAMMPS
headers and the LAMMPS library, via ``-D
LAMMPS_SOURCE_DIR=/path/to/lammps/src``. CMake will try to guess a
build folder with the LAMMPS library from that path, but it can also be
set with ``-D LAMMPS_LIB_DIR=/path/to/lammps/lib``.
Rather than linking to the LAMMPS library during compilation, it is also
possible to compile the GUI with a plugin loader library that will load
the LAMMPS library dynamically at runtime during the start of the GUI
from a shared library; e.g. ``liblammps.so`` or ``liblammps.dylib`` or
``liblammps.dll`` (depending on the operating system). This has the
advantage that the LAMMPS library can be updated LAMMPS without having
to recompile the GUI. The ABI of the LAMMPS C-library interface is very
stable and generally backward compatible. This feature is enabled by
setting ``-D LAMMPS_GUI_USE_PLUGIN=on`` and then ``-D
LAMMPS_PLUGINLIB_DIR=/path/to/lammps/plugin/loader``. Typically, this
would be the ``examples/COUPLE/plugin`` folder of the LAMMPS
distribution.
Platform notes
^^^^^^^^^^^^^^
macOS
"""""
When building on macOS, the build procedure will try to manufacture a
drag-n-drop installer, LAMMPS-macOS-multiarch.dmg, when using the 'dmg'
target (i.e. ``cmake --build <build dir> --target dmg`` or ``make dmg``.
To build multi-arch executables that will run on both, arm64 and x86_64
architectures natively, it is necessary to set the CMake variable ``-D
CMAKE_OSX_ARCHITECTURES=arm64;x86_64``. To achieve wide compatibility
with different macOS versions, you can also set ``-D
CMAKE_OSX_DEPLOYMENT_TARGET=11.0`` which will set compatibility to macOS
11 (Big Sur) and later, even if you are compiling on a more recent macOS
version.
Windows
"""""""
On Windows either native compilation from within Visual Studio 2022 with
Visual C++ is supported and tested, or compilation with the MinGW / GCC
cross-compiler environment on Fedora Linux.
**Visual Studio**
Using CMake and Ninja as build system are required. Qt needs to be
installed, tested was a binary package downloaded from
https://www.qt.io, which installs into the ``C:\\Qt`` folder by default.
There is a custom `x64-GUI-MSVC` build configuration provided in the
``CMakeSettings.json`` file that Visual Studio uses to store different
compilation settings for project. Choosing this configuration will
activate building the `lammps-gui.exe` executable in addition to LAMMPS
through importing package selection from the ``windows.cmake`` preset
file and enabling building the LAMMPS GUI and disabling building with MPI.
When requesting an installation from the `Build` menu in Visual Studio,
it will create a compressed ``LAMMPS-Win10-amd64.zip`` zip file with the
executables and required dependent .dll files. This zip file can be
uncompressed and ``lammps-gui.exe`` run directly from there. The
uncompressed folder can be added to the ``PATH`` environment and LAMMPS
and LAMMPS GUI can be launched from anywhere from the command line.
**MinGW64 Cross-compiler**
The standard CMake build procedure can be applied and the
``mingw-cross.cmake`` preset used. By using ``mingw64-cmake`` the CMake
command will automatically include a suitable CMake toolset file (the
regular cmake command can be used after that). After building the
libraries and executables, you can build the target 'zip'
(i.e. ``cmake --build <build dir> --target zip`` or ``make zip``
to stage all installed files into a LAMMPS_GUI folder and then
run a script to copy all required dependencies, some other files,
and create a zip file from it.
Linux
"""""
Version 5.12 or later of the Qt library is required. Those are provided
by, e.g., Ubuntu 20.04LTS. Thus older Linux distributions are not
likely to be supported, while more recent ones will work, even for
pre-compiled executables (see above). After compiling with
``cmake --build <build folder>``, use ``cmake --build <build
folder> --target tgz`` or ``make tgz`` to build a
``LAMMPS-Linux-amd64.tar.gz`` file with the executables and their
support libraries.
----------
.. _arc:
lmp2arc tool

2
doc/src/atc_add_molecule.rst
View File

@ -6,7 +6,7 @@ fix_modify AtC add_molecule command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
fix_modify <AtC fixID> add_molecule <small|large> <tag> <group-ID>

2
doc/src/atc_add_species.rst
View File

@ -6,7 +6,7 @@ fix_modify AtC add_species command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
fix_modify <AtC fixID> add_species <tag> <group|type> <ID>

2
doc/src/atc_atom_element_map.rst
View File

@ -6,7 +6,7 @@ fix_modify AtC atom_element_map command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
fix_modify <AtC fixID> atom_element_map <eulerian|lagrangian> [<frequency>]

2
doc/src/atc_atom_weight.rst
View File

@ -6,7 +6,7 @@ fix_modify AtC atom_weight command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
fix_modify <AtC fixID> atom_weight <method> <args>

2
doc/src/atc_atomic_charge.rst
View File

@ -6,7 +6,7 @@ fix_modify AtC atomic_charge command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
fix_modify <AtC fixID> <include|omit> atomic_charge

2
doc/src/atc_boundary_dynamics.rst
View File

@ -6,7 +6,7 @@ fix_modify AtC boundary_dynamics command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
fix_modify <AtC fixID> boundary_dynamics <on|damped_harmonic|prescribed|coupled|none>

2
doc/src/atc_boundary_faceset.rst
View File

@ -6,7 +6,7 @@ fix_modify AtC boundary_faceset command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
fix_modify <AtC fixID> boundary_faceset <is|add> <faceset_name>

2
doc/src/atc_boundary_type.rst
View File

@ -6,7 +6,7 @@ fix_modify AtC boundary type command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
fix_modify <AtC fixID> boundary type <atom-type-id>

2
doc/src/atc_consistent_fe_initialization.rst
View File

@ -6,7 +6,7 @@ fix_modify AtC consistent_fe_initialization command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
fix_modify <AtC fixID> consistent_fe_initialization <on|off>

2
doc/src/atc_control_localized_lambda.rst
View File

@ -6,7 +6,7 @@ fix_modify AtC control localized_lambda command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
fix_modify <AtC fixID> control localized_lambda <on|off>

2
doc/src/atc_control_momentum.rst
View File

@ -6,7 +6,7 @@ fix_modify AtC control momentum command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
fix_modify <AtC fixID> control <physics_type> <solution_parameter> <value>
fix_modify AtC control momentum none

2
doc/src/atc_control_thermal.rst
View File

@ -6,7 +6,7 @@ fix_modify AtC control thermal command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
fix_modify <AtC fixID> control <physics_type> <solution_parameter> <value>
fix_modify <AtC fixID> control thermal <control_type> <optional_args>

2
doc/src/atc_decomposition.rst
View File

@ -6,7 +6,7 @@ fix_modify AtC decomposition command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
fix_modify <AtC fixID> decomposition <type>

2
doc/src/atc_electron_integration.rst
View File

@ -6,7 +6,7 @@ fix_modify AtC extrinsic electron_integration command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
fix_modify <AtC fixID> extrinsic electron_integration <integration_type> [<num_subcycle_steps>]

2
doc/src/atc_equilibrium_start.rst
View File

@ -6,7 +6,7 @@ fix_modify AtC equilibrium_start command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
fix_modify <AtC fixID> equilibrium_start <on|off>

2
doc/src/atc_extrinsic_exchange.rst
View File

@ -6,7 +6,7 @@ fix_modify AtC extrinsic exchange command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
fix_modify <AtC fixID> extrinsic exchange <on|off>

2
doc/src/atc_fe_md_boundary.rst
View File

@ -6,7 +6,7 @@ fix_modify AtC fe_md_boundary command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
fix_modify <AtC fixID> fe_md_boundary <faceset|interpolate|no_boundary>

2
doc/src/atc_filter_scale.rst
View File

@ -6,7 +6,7 @@ fix_modify AtC filter scale command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
fix_modify <AtC fixID> filter scale <scale>

Some files were not shown because too many files have changed in this diff Show More