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

Merge branch 'develop' of https://github.com/lammps/lammps into kk_atomvec

Browse Source
This commit is contained in:
Stan Moore
2023-01-24 14:15:44 -07:00
parent c42926feb0 554257ca63
commit 7f2e34ff57
705 changed files with 11016 additions and 97288 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
.github/CODEOWNERS vendored
View File

@ -63,6 +63,7 @@ src/MANYBODY/pair_vashishta_table.* @andeplane
src/MANYBODY/pair_atm.* @sergeylishchuk
src/REPLICA/*_grem.* @dstelter92
src/EXTRA-COMPUTE/compute_stress_mop*.* @RomainVermorel
src/EXTRA-COMPUTE/compute_born_matrix.* @Bibobu @athomps
src/MISC/*_tracker.* @jtclemm
src/MC/fix_gcmc.* @athomps
src/MC/fix_sgcmc.* @athomps

4
.github/workflows/codeql-analysis.yml vendored
View File

@ -49,7 +49,9 @@ jobs:
shell: bash
working-directory: build
run: |
cmake -C ../cmake/presets/most.cmake ../cmake
cmake -C ../cmake/presets/most.cmake \
-D DOWNLOAD_POTENTIALS=off \
../cmake
cmake --build . --parallel 2
- name: Perform CodeQL Analysis

1
.github/workflows/compile-msvc.yml vendored
View File

@ -36,6 +36,7 @@ jobs:
nuget install MSMPIsdk
nuget install MSMPIDIST
cmake -C cmake/presets/windows.cmake \
-D DOWNLOAD_POTENTIALS=off \
-D PKG_PYTHON=on \
-D WITH_PNG=off \
-D WITH_JPEG=off \

1
.github/workflows/unittest-macos.yml vendored
View File

@ -47,6 +47,7 @@ jobs:
python3 -m pip install pyyaml
cmake -C ../cmake/presets/clang.cmake \
-C ../cmake/presets/most.cmake \
-D DOWNLOAD_POTENTIALS=off \
-D CMAKE_CXX_COMPILER_LAUNCHER=ccache \
-D CMAKE_C_COMPILER_LAUNCHER=ccache \
-D ENABLE_TESTING=on \

2
.gitignore vendored
View File

@ -55,3 +55,5 @@ out/RelWithDebInfo
out/Release
out/x86
out/x64
src/Makefile.package-e
src/Makefile.package.settings-e

21
SECURITY.md
View File

@ -30,18 +30,19 @@ for unicode characters and only all-ASCII source code is accepted.
# Version Updates
LAMMPS follows continuous release development model. We aim to keep to
keep the development version (develop branch) always fully functional
and employ a variety of automatic testing procedures to detect failures
LAMMPS follows a continuous release development model. We aim to keep
the development version (`develop` branch) always fully functional and
employ a variety of automatic testing procedures to detect failures
of existing functionality from adding or modifying features. Most of
those tests are run on pull requests *before* merging to the development
branch. The develop branch is protected, so all changes *must* be
those tests are run on pull requests *before* merging to the `develop`
branch. The `develop` branch is protected, so all changes *must* be
submitted as a pull request and thus cannot avoid the automated tests.
Additional tests are run *after* merging. Before releases are made
*all* tests must have cleared. Then a release tag is applied and the
release branch fast-forwarded to that tag. Bug fixes and updates are
applied to the current development branch and thus will be available in
the next (patch) release. For stable releases, selected bug fixes are
back-ported and occasionally published as update releases. There are
only updates to the latest stable release.
`release` branch is fast-forwarded to that tag. This is often referred
to as a patch release. Bug fixes and updates are
applied first to the `develop` branch. Later, they appear in the `release`
branch when the next patch release occurs.
For stable releases, selected bug fixes, updates, and new functionality
are pushed to the `stable` branch and a new stable tag is applied.

39
cmake/CMakeLists.txt
View File

@ -168,8 +168,8 @@ endif()
########################################################################
# User input options #
########################################################################
# set path to python interpreter and thus enforcing python version if
# when in a virtual environment and PYTHON_EXECUTABLE is not set on command line
# set path to python interpreter and thus enforcing python version when
# in a virtual environment and PYTHON_EXECUTABLE is not set on command line
if(DEFINED ENV{VIRTUAL_ENV} AND NOT PYTHON_EXECUTABLE)
if(CMAKE_HOST_SYSTEM_NAME STREQUAL "Windows")
set(PYTHON_EXECUTABLE "$ENV{VIRTUAL_ENV}/Scripts/python.exe")
@ -265,6 +265,7 @@ set(STANDARD_PACKAGES
MC
MDI
MEAM
MESONT
MGPT
MISC
ML-HDNNP
@ -308,9 +309,8 @@ set(STANDARD_PACKAGES
YAFF)
set(SUFFIX_PACKAGES CORESHELL GPU KOKKOS OPT INTEL OPENMP)
set(EXTRA_PACKAGES MESONT)
foreach(PKG ${STANDARD_PACKAGES} ${EXTRA_PACKAGES} ${SUFFIX_PACKAGES})
foreach(PKG ${STANDARD_PACKAGES} ${SUFFIX_PACKAGES})
option(PKG_${PKG} "Build ${PKG} Package" OFF)
endforeach()
@ -520,7 +520,7 @@ else()
set(CUDA_REQUEST_PIC)
endif()
foreach(PKG_WITH_INCL KSPACE PYTHON ML-IAP VORONOI COLVARS ML-HDNNP MDI MOLFILE MESONT NETCDF
foreach(PKG_WITH_INCL KSPACE PYTHON ML-IAP VORONOI COLVARS ML-HDNNP MDI MOLFILE NETCDF
PLUMED QMMM ML-QUIP SCAFACOS MACHDYN VTK KIM LATTE MSCG COMPRESS ML-PACE LEPTON)
if(PKG_${PKG_WITH_INCL})
include(Packages/${PKG_WITH_INCL})
@ -568,7 +568,7 @@ RegisterStyles(${LAMMPS_SOURCE_DIR})
########################################################
option(DOWNLOAD_POTENTIALS "Automatically download large potential files" ON)
mark_as_advanced(DOWNLOAD_POTENTIALS)
foreach(PKG ${STANDARD_PACKAGES} ${EXTRA_PACKAGES} ${SUFFIX_PACKAGES})
foreach(PKG ${STANDARD_PACKAGES} ${SUFFIX_PACKAGES})
if(PKG_${PKG})
FetchPotentials(${LAMMPS_SOURCE_DIR}/${PKG} ${LAMMPS_POTENTIALS_DIR})
endif()
@ -708,7 +708,7 @@ target_include_directories(lammps PRIVATE ${LAMMPS_STYLE_HEADERS_DIR})
######################################
set(temp "#ifndef LMP_INSTALLED_PKGS_H\n#define LMP_INSTALLED_PKGS_H\n")
set(temp "${temp}const char * LAMMPS_NS::LAMMPS::installed_packages[] = {\n")
set(temp_PKG_LIST ${STANDARD_PACKAGES} ${EXTRA_PACKAGES} ${SUFFIX_PACKAGES})
set(temp_PKG_LIST ${STANDARD_PACKAGES} ${SUFFIX_PACKAGES})
list(SORT temp_PKG_LIST)
foreach(PKG ${temp_PKG_LIST})
if(PKG_${PKG})
@ -893,6 +893,23 @@ if(ClangFormat_FOUND)
WORKING_DIRECTORY ${LAMMPS_SOURCE_DIR})
endif()
# extract Kokkos compilation settings
get_cmake_property(_allvars VARIABLES)
foreach(_var ${_allvars})
if(${_var})
string(REGEX MATCH "Kokkos_ENABLE_(SERIAL|THREADS|OPENMP|CUDA|HIP|SYCL|OPENMPTARGET|HPX)" _match ${_var})
if(_match)
string(REGEX REPLACE "Kokkos_ENABLE_(OPENMP|SERIAL|CUDA|HIP|SYCL)" "\\1" _match ${_var})
list(APPEND KOKKOS_DEVICE ${_match})
endif()
string(REGEX MATCH "Kokkos_ARCH" _match ${_var})
if(_match)
string(REGEX REPLACE "Kokkos_ARCH_(.*)" "\\1" _match ${_var})
list(APPEND KOKKOS_ARCH ${_match})
endif()
endif()
endforeach()
get_target_property(DEFINES lammps COMPILE_DEFINITIONS)
if(BUILD_IS_MULTI_CONFIG)
set(LAMMPS_BUILD_TYPE "Multi-Config")
@ -912,7 +929,7 @@ message(STATUS "<<< Build configuration >>>
# Print package summary
###############################################################################
set(ENABLED_PACKAGES)
foreach(PKG ${STANDARD_PACKAGES} ${EXTRA_PACKAGES} ${SUFFIX_PACKAGES})
foreach(PKG ${STANDARD_PACKAGES} ${SUFFIX_PACKAGES})
if(PKG_${PKG})
list(APPEND ENABLED_PACKAGES ${PKG})
endif()
@ -990,6 +1007,12 @@ if(PKG_GPU)
endif()
message(STATUS "GPU precision: ${GPU_PREC}")
endif()
if(PKG_KOKKOS)
message(STATUS "Kokkos Devices: ${KOKKOS_DEVICE}")
if(KOKKOS_ARCH)
message(STATUS "Kokkos Architecture: ${KOKKOS_ARCH}")
endif()
endif()
if(PKG_KSPACE)
message(STATUS "<<< FFT settings >>>
-- Primary FFT lib: ${FFT}")

6
cmake/Modules/Packages/KOKKOS.cmake
View File

@ -49,8 +49,8 @@ if(DOWNLOAD_KOKKOS)
list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_CXX_EXTENSIONS=${CMAKE_CXX_EXTENSIONS}")
list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}")
include(ExternalProject)
set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/3.7.00.tar.gz" CACHE STRING "URL for KOKKOS tarball")
set(KOKKOS_MD5 "84991eca9f066383abe119a5bc7a11c4" CACHE STRING "MD5 checksum of KOKKOS tarball")
set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/3.7.01.tar.gz" CACHE STRING "URL for KOKKOS tarball")
set(KOKKOS_MD5 "f140e02b826223b1045207d9bc10d404" CACHE STRING "MD5 checksum of KOKKOS tarball")
mark_as_advanced(KOKKOS_URL)
mark_as_advanced(KOKKOS_MD5)
ExternalProject_Add(kokkos_build
@ -74,7 +74,7 @@ if(DOWNLOAD_KOKKOS)
add_dependencies(LAMMPS::KOKKOSCORE kokkos_build)
add_dependencies(LAMMPS::KOKKOSCONTAINERS kokkos_build)
elseif(EXTERNAL_KOKKOS)
find_package(Kokkos 3.7.00 REQUIRED CONFIG)
find_package(Kokkos 3.7.01 REQUIRED CONFIG)
target_link_libraries(lammps PRIVATE Kokkos::kokkos)
target_link_libraries(lmp PRIVATE Kokkos::kokkos)
else()

4
cmake/Modules/Packages/LEPTON.cmake
View File

@ -4,7 +4,7 @@ if(LEPTON_SOURCE_DIR)
endif()
set(LEPTON_SOURCE_DIR ${LAMMPS_LIB_SOURCE_DIR}/lepton)
file(GLOB LEPTON_SOURCES ${LEPTON_SOURCE_DIR}/src/[^.]*.cpp)
file(GLOB LEPTON_SOURCES ${CONFIGURE_DEPENDS} ${LEPTON_SOURCE_DIR}/src/[^.]*.cpp)
if((CMAKE_HOST_SYSTEM_PROCESSOR STREQUAL "amd64") OR
(CMAKE_HOST_SYSTEM_PROCESSOR STREQUAL "AMD64") OR
@ -15,7 +15,7 @@ else()
endif()
if(LEPTON_ENABLE_JIT)
file(GLOB ASMJIT_SOURCES ${LEPTON_SOURCE_DIR}/asmjit/*/[^.]*.cpp)
file(GLOB ASMJIT_SOURCES ${CONFIGURE_DEPENDS} ${LEPTON_SOURCE_DIR}/asmjit/*/[^.]*.cpp)
endif()
add_library(lepton STATIC ${LEPTON_SOURCES} ${ASMJIT_SOURCES})

73
cmake/Modules/Packages/MESONT.cmake
View File

@ -1,73 +0,0 @@
set(MESONT_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/MESONT)
include(StyleHeaderUtils)
include(CheckLanguage)
# always include C++-only sources
file(GLOB MESONT_SOURCES ${CONFIGURE_DEPENDS} ${MESONT_SOURCES_DIR}/[^.]*mesocnt*.cpp)
file(GLOB MESONT_HEADERS ${CONFIGURE_DEPENDS} ${MESONT_SOURCES_DIR}/[^.]*mesocnt*.h)
# remove derived class when base class is not available
if(NOT PKG_MOLECULE)
list(REMOVE_ITEM MESONT_SOURCES ${MESONT_SOURCES_DIR}/bond_mesocnt.cpp)
list(REMOVE_ITEM MESONT_HEADERS ${MESONT_SOURCES_DIR}/bond_mesocnt.h)
endif()
# include styles dependent on Fortran library only when Fortran is available.
check_language(Fortran)
if(CMAKE_Fortran_COMPILER)
enable_language(Fortran)
file(GLOB MESONT_LIB_SOURCES ${CONFIGURE_DEPENDS} ${LAMMPS_LIB_SOURCE_DIR}/mesont/[^.]*.f90)
add_library(mesont STATIC ${MESONT_LIB_SOURCES})
set_target_properties(mesont PROPERTIES OUTPUT_NAME lammps_mesont${LAMMPS_MACHINE})
target_link_libraries(lammps PRIVATE mesont)
list(APPEND MESONT_SOURCES ${MESONT_SOURCES_DIR}/pair_mesont_tpm.cpp)
list(APPEND MESONT_SOURCES ${MESONT_SOURCES_DIR}/atom_vec_mesont.cpp)
list(APPEND MESONT_SOURCES ${MESONT_SOURCES_DIR}/compute_mesont.cpp)
list(APPEND MESONT_HEADERS ${MESONT_SOURCES_DIR}/pair_mesont_tpm.h)
list(APPEND MESONT_HEADERS ${MESONT_SOURCES_DIR}/atom_vec_mesont.h)
list(APPEND MESONT_HEADERS ${MESONT_SOURCES_DIR}/compute_mesont.h)
endif()
# check for package files in src directory due to old make system
DetectBuildSystemConflict(${LAMMPS_SOURCE_DIR} ${MESONT_SOURCES} ${MESONT_HEADERS})
# manually register style headers
get_property(alist GLOBAL PROPERTY ANGLE)
get_property(blist GLOBAL PROPERTY BOND)
get_property(clist GLOBAL PROPERTY COMPUTE)
get_property(plist GLOBAL PROPERTY PAIR)
get_property(vlist GLOBAL PROPERTY ATOM_VEC)
foreach(fname ${MESONT_HEADERS})
file(STRINGS ${fname} is_style LIMIT_COUNT 1 REGEX ANGLE_CLASS)
if(is_style)
list(APPEND alist ${fname})
endif()
file(STRINGS ${fname} is_style LIMIT_COUNT 1 REGEX BOND_CLASS)
if(is_style)
list(APPEND blist ${fname})
endif()
file(STRINGS ${fname} is_style LIMIT_COUNT 1 REGEX COMPUTE_CLASS)
if(is_style)
list(APPEND clist ${fname})
endif()
file(STRINGS ${fname} is_style LIMIT_COUNT 1 REGEX PAIR_CLASS)
if(is_style)
list(APPEND plist ${fname})
endif()
file(STRINGS ${fname} is_style LIMIT_COUNT 1 REGEX ATOM_CLASS)
if(is_style)
list(APPEND vlist ${fname})
endif()
endforeach()
set_property(GLOBAL PROPERTY ANGLE "${alist}")
set_property(GLOBAL PROPERTY BOND "${blist}")
set_property(GLOBAL PROPERTY COMPUTE "${clist}")
set_property(GLOBAL PROPERTY PAIR "${plist}")
set_property(GLOBAL PROPERTY ATOM_VEC "${vlist}")
target_sources(lammps PRIVATE ${MESONT_SOURCES})
target_include_directories(lammps PRIVATE ${MESONT_SOURCES_DIR})
RegisterPackages(${MESONT_SOURCES_DIR})

1
cmake/presets/most.cmake
View File

@ -40,6 +40,7 @@ set(ALL_PACKAGES
MANYBODY
MC
MEAM
MESONT
MISC
ML-IAP
ML-POD

1
cmake/presets/nolib.cmake
View File

@ -16,7 +16,6 @@ set(PACKAGES_WITH_LIB
LEPTON
MACHDYN
MDI
MESONT
ML-HDNNP
ML-PACE
ML-QUIP

1
cmake/presets/windows.cmake
View File

@ -36,6 +36,7 @@ set(WIN_PACKAGES
MANYBODY
MC
MEAM
MESONT
MISC
ML-IAP
ML-POD

32
doc/Makefile
View File

@ -86,13 +86,13 @@ html: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJAX)
@if [ "$(HAS_BASH)" == "NO" ] ; then echo "bash was not found at $(OSHELL)! Please use: $(MAKE) SHELL=/path/to/bash" 1>&2; exit 1; fi
@$(MAKE) $(MFLAGS) -C graphviz all
@(\
. $(VENV)/bin/activate ; env PYTHONWARNINGS= \
. $(VENV)/bin/activate ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
sphinx-build -E $(SPHINXEXTRA) -b html -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) html ;\
touch $(RSTDIR)/Fortran.rst ;\
touch $(RSTDIR)/Fortran.rst ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
sphinx-build $(SPHINXEXTRA) -b html -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) html ;\
ln -sf Manual.html html/index.html;\
rm -f $(BUILDDIR)/doxygen/xml/run.stamp;\
echo "############################################" ;\
echo "############################################" ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
rst_anchor_check src/*.rst ;\
python $(BUILDDIR)/utils/check-packages.py -s ../src -d src ;\
env LC_ALL=C grep -n '[^ -~]' $(RSTDIR)/*.rst ;\
@ -114,9 +114,9 @@ fasthtml: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJAX)
@$(MAKE) $(MFLAGS) -C graphviz all
@mkdir -p fasthtml
@(\
. $(VENV)/bin/activate ; env PYTHONWARNINGS= \
. $(VENV)/bin/activate ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
sphinx-build $(SPHINXEXTRA) -b html -c $(SPHINXCONFIG) -d $(BUILDDIR)/fasthtml/doctrees $(RSTDIR) fasthtml ;\
touch $(RSTDIR)/Fortran.rst ;\
touch $(RSTDIR)/Fortran.rst ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
sphinx-build $(SPHINXEXTRA) -b html -c $(SPHINXCONFIG) -d $(BUILDDIR)/fasthtml/doctrees $(RSTDIR) fasthtml ;\
deactivate ;\
)
@ -131,8 +131,8 @@ fasthtml: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJAX)
spelling: xmlgen $(SPHINXCONFIG)/conf.py $(VENV) $(SPHINXCONFIG)/false_positives.txt
@if [ "$(HAS_BASH)" == "NO" ] ; then echo "bash was not found at $(OSHELL)! Please use: $(MAKE) SHELL=/path/to/bash" 1>&2; exit 1; fi
@(\
. $(VENV)/bin/activate ; env PYTHONWARNINGS= \
cp $(SPHINXCONFIG)/false_positives.txt $(RSTDIR)/ ; env PYTHONWARNINGS= \
. $(VENV)/bin/activate ; \
cp $(SPHINXCONFIG)/false_positives.txt $(RSTDIR)/; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
sphinx-build -b spelling -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) spelling ;\
rm -f $(BUILDDIR)/doxygen/xml/run.stamp;\
deactivate ;\
@ -146,9 +146,9 @@ epub: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK)
@rm -f LAMMPS.epub
@cp src/JPG/*.* epub/JPG
@(\
. $(VENV)/bin/activate ;\
. $(VENV)/bin/activate ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
sphinx-build -E $(SPHINXEXTRA) -b epub -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) epub ;\
touch $(RSTDIR)/Fortran.rst ;\
touch $(RSTDIR)/Fortran.rst ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
sphinx-build $(SPHINXEXTRA) -b epub -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) epub ;\
rm -f $(BUILDDIR)/doxygen/xml/run.stamp;\
deactivate ;\
@ -167,12 +167,12 @@ pdf: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK)
@$(MAKE) $(MFLAGS) -C graphviz all
@if [ "$(HAS_PDFLATEX)" == "NO" ] ; then echo "PDFLaTeX or latexmk were not found! Please check README for further instructions" 1>&2; exit 1; fi
@(\
. $(VENV)/bin/activate ; env PYTHONWARNINGS= \
. $(VENV)/bin/activate ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
sphinx-build -E $(SPHINXEXTRA) -b latex -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) latex ;\
touch $(RSTDIR)/Fortran.rst ;\
touch $(RSTDIR)/Fortran.rst ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
sphinx-build $(SPHINXEXTRA) -b latex -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) latex ;\
rm -f $(BUILDDIR)/doxygen/xml/run.stamp;\
echo "############################################" ;\
echo "############################################" ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
rst_anchor_check src/*.rst ;\
python utils/check-packages.py -s ../src -d src ;\
env LC_ALL=C grep -n '[^ -~]' $(RSTDIR)/*.rst ;\
@ -200,21 +200,21 @@ pdf: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK)
anchor_check : $(ANCHORCHECK)
@(\
. $(VENV)/bin/activate ;\
. $(VENV)/bin/activate ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
rst_anchor_check src/*.rst ;\
deactivate ;\
)
style_check : $(VENV)
@(\
. $(VENV)/bin/activate ;\
. $(VENV)/bin/activate ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
python utils/check-styles.py -s ../src -d src ;\
deactivate ;\
)
package_check : $(VENV)
@(\
. $(VENV)/bin/activate ;\
. $(VENV)/bin/activate ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \\
python utils/check-packages.py -s ../src -d src ;\
deactivate ;\
)
@ -252,7 +252,7 @@ $(MATHJAX):
$(ANCHORCHECK): $(VENV)
@( \
. $(VENV)/bin/activate; \
. $(VENV)/bin/activate; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
pip $(PIP_OPTIONS) install -e utils/converters;\
deactivate;\
)

2
doc/src/2001/basics.html
View File

@ -63,7 +63,7 @@ In the src directory, there is one top-level Makefile and several
low-level machine-specific files named Makefile.xxx where xxx = the
machine name. If a low-level Makefile exists for your platform, you do
not need to edit the top-level Makefile. However you should check the
system-specific section of the low-level Makefile to insure the
system-specific section of the low-level Makefile to ensure the
various paths are correct for your environment. If a low-level
Makefile does not exist for your platform, you will need to add a
suitable target to the top-level Makefile. You will also need to

2
doc/src/2001/input_commands.html
View File

@ -1206,7 +1206,7 @@ this command is not typically needed if the &quot;nonbond style&quot; and &quot;
an exception to this is if a short cutoff is used initially,
but a longer cutoff will be used for a subsequent run (in the same
input script), in this case the &quot;maximum cutoff&quot; command should be
used to insure enough memory is allocated for the later run
used to ensure enough memory is allocated for the later run
note that a restart file contains nonbond cutoffs (so it is not necessary
to use a &quot;nonbond style&quot; command before &quot;read restart&quot;), but LAMMPS
still needs to know what the maximum cutoff will be before the

6
doc/src/Build.rst
View File

@ -6,9 +6,9 @@ either traditional makefiles for use with GNU make (which may require
manual editing), or using a build environment generated by CMake (Unix
Makefiles, Ninja, Xcode, Visual Studio, KDevelop, CodeBlocks and more).
As an alternative you can download a package with pre-built executables
or automated build trees as described on the :doc:`Install <Install>`
page.
As an alternative, you can download a package with pre-built executables
or automated build trees, as described in the :doc:`Install <Install>`
section of the manual.
.. toctree::
:maxdepth: 1

80
doc/src/Build_basics.rst
View File

@ -44,7 +44,7 @@ standard. A more detailed discussion of that is below.
The executable created by CMake (after running make) is named
``lmp`` unless the ``LAMMPS_MACHINE`` option is set. When setting
``LAMMPS_MACHINE=name`` the executable will be called
``LAMMPS_MACHINE=name``, the executable will be called
``lmp_name``. Using ``BUILD_MPI=no`` will enforce building a
serial executable using the MPI STUBS library.
@ -60,7 +60,7 @@ standard. A more detailed discussion of that is below.
Any ``make machine`` command will look up the make settings from a
file ``Makefile.machine`` in the folder ``src/MAKE`` or one of its
sub-directories ``MINE``, ``MACHINES``, or ``OPTIONS``, create a
subdirectories ``MINE``, ``MACHINES``, or ``OPTIONS``, create a
folder ``Obj_machine`` with all objects and generated files and an
executable called ``lmp_machine``\ . The standard parallel build
with ``make mpi`` assumes a standard MPI installation with MPI
@ -107,9 +107,9 @@ MPI and OpenMP support in LAMMPS
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If you are installing MPI yourself to build a parallel LAMMPS
executable, we recommend either MPICH or OpenMPI which are regularly
executable, we recommend either MPICH or OpenMPI, which are regularly
used and tested with LAMMPS by the LAMMPS developers. MPICH can be
downloaded from the `MPICH home page <https://www.mpich.org>`_ and
downloaded from the `MPICH home page <https://www.mpich.org>`_, and
OpenMPI can be downloaded correspondingly from the `OpenMPI home page
<https://www.open-mpi.org>`_. Other MPI packages should also work. No
specific vendor provided and standard compliant MPI library is currently
@ -130,12 +130,12 @@ 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. In addition
``ML-SNAP``, ``DIFFRACTION``, and ``DPD-REACT`` packages. Furthermore,
some packages support OpenMP threading indirectly through the libraries
they interface to: e.g. ``LATTE``, ``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.
they interface to: e.g. ``LATTE``, ``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
@ -144,9 +144,9 @@ variable before you launch LAMMPS.
For building via conventional make, the ``CCFLAGS`` and ``LINKFLAGS``
variables in Makefile.machine need to include the compiler flag that
enables OpenMP. For GNU compilers it is ``-fopenmp``\ . For (recent) Intel
compilers it is ``-qopenmp``\ . If you are using a different compiler,
please refer to its documentation.
enables OpenMP. For the GNU compilers or Clang, it is ``-fopenmp``\ .
For (recent) Intel compilers, it is ``-qopenmp``\ . If you are using a
different compiler, please refer to its documentation.
.. _default-none-issues:
@ -174,15 +174,16 @@ Choice of compiler and compile/link options
The choice of compiler and compiler flags can be important for maximum
performance. Vendor provided compilers for a specific hardware can
produce faster code than open-source compilers like the GNU compilers.
On the most common x86 hardware most popular C++ compilers are quite
similar in performance of C/C++ code at high optimization levels. When
using the ``INTEL`` package, there is a distinct advantage in using
the `Intel C++ compiler <intel_>`_ due to much improved vectorization
through SSE and AVX instructions on compatible hardware as the source
code includes changes and Intel compiler specific directives to enable
high degrees of vectorization. This may change over time as equivalent
vectorization directives are included into OpenMP standard revisions and
other compilers adopt them.
On the most common x86 hardware, the most popular C++ compilers are
quite similar in their ability to optimize regular C/C++ source code at
high optimization levels. When using the ``INTEL`` package, there is a
distinct advantage in using the `Intel C++ compiler <intel_>`_ due to
much improved vectorization through SSE and AVX instructions on
compatible hardware. The source code in that package conditionally
includes compiler specific directives to enable these high degrees of
vectorization. This may change over time as equivalent vectorization
directives are included into the OpenMP standard and other compilers
adopt them.
.. _intel: https://software.intel.com/en-us/intel-compilers
@ -196,7 +197,7 @@ LAMMPS.
.. tab:: CMake build
By default CMake will use the compiler it finds according to
internal preferences and it will add optimization flags
internal preferences, and it will add optimization flags
appropriate to that compiler and any :doc:`accelerator packages
<Speed_packages>` you have included in the build. CMake will
check if the detected or selected compiler is compatible with the
@ -250,9 +251,9 @@ LAMMPS.
and `-C ../cmake/presets/pgi.cmake`
will switch the compiler to the PGI compilers.
In addition you can set ``CMAKE_TUNE_FLAGS`` to specifically add
compiler flags to tune for optimal performance on given hosts. By
default this variable is empty.
Furthermore, you can set ``CMAKE_TUNE_FLAGS`` to specifically add
compiler flags to tune for optimal performance on given hosts.
This variable is empty by default.
.. note::
@ -368,10 +369,10 @@ running LAMMPS from Python via its library interface.
# no default value
The compilation will always produce a LAMMPS library and an
executable linked to it. By default this will be a static library
named ``liblammps.a`` and an executable named ``lmp`` Setting
``BUILD_SHARED_LIBS=yes`` will instead produce a shared library
called ``liblammps.so`` (or ``liblammps.dylib`` or
executable linked to it. By default, this will be a static
library named ``liblammps.a`` and an executable named ``lmp``
Setting ``BUILD_SHARED_LIBS=yes`` will instead produce a shared
library called ``liblammps.so`` (or ``liblammps.dylib`` or
``liblammps.dll`` depending on the platform) If
``LAMMPS_MACHINE=name`` is set in addition, the name of the
generated libraries will be changed to either ``liblammps_name.a``
@ -429,7 +430,7 @@ You may need to use ``sudo make install`` in place of the last line if
you do not have write privileges for ``/usr/local/lib`` or use the
``--prefix`` configuration option to select an installation folder,
where you do have write access. The end result should be the file
``/usr/local/lib/libmpich.so``. On many Linux installations the folder
``/usr/local/lib/libmpich.so``. On many Linux installations, the folder
``${HOME}/.local`` is an alternative to using ``/usr/local`` and does
not require superuser or sudo access. In that case the configuration
step becomes:
@ -438,9 +439,10 @@ step becomes:
./configure --enable-shared --prefix=${HOME}/.local
Avoiding to use "sudo" for custom software installation (i.e. from source
and not through a package manager tool provided by the OS) is generally
recommended to ensure the integrity of the system software installation.
Avoiding the use of "sudo" for custom software installation (i.e. from
source and not through a package manager tool provided by the OS) is
generally recommended to ensure the integrity of the system software
installation.
----------
@ -514,11 +516,11 @@ using CMake or Make.
Install LAMMPS after a build
------------------------------------------
After building LAMMPS, you may wish to copy the LAMMPS executable of
library, along with other LAMMPS files (library header, doc files) to
a globally visible place on your system, for others to access. Note
that you may need super-user privileges (e.g. sudo) if the directory
you want to copy files to is protected.
After building LAMMPS, you may wish to copy the LAMMPS executable or
library, along with other LAMMPS files (library header, doc files), to a
globally visible place on your system, for others to access. Note that
you may need super-user privileges (e.g. sudo) if the directory you want
to copy files to is protected.
.. tabs::
@ -536,7 +538,7 @@ you want to copy files to is protected.
environment variable, if you are installing LAMMPS into a non-system
location and/or are linking to libraries in a non-system location that
depend on such runtime path settings.
As an alternative you may set the CMake variable ``LAMMPS_INSTALL_RPATH``
As an alternative, you may set the CMake variable ``LAMMPS_INSTALL_RPATH``
to ``on`` and then the runtime paths for any linked shared libraries
and the library installation folder for the LAMMPS library will be
embedded and thus the requirement to set environment variables is avoided.

81
doc/src/Build_cmake.rst
View File

@ -9,10 +9,10 @@ page.
The following text assumes some familiarity with CMake and focuses on
using the command line tool ``cmake`` and what settings are supported
for building LAMMPS. A more detailed tutorial on how to use ``cmake``
itself, the text mode or graphical user interface, change the generated
output files for different build tools and development environments is
on a :doc:`separate page <Howto_cmake>`.
for building LAMMPS. A more detailed tutorial on how to use CMake
itself, the text mode or graphical user interface, to change the
generated output files for different build tools and development
environments is on a :doc:`separate page <Howto_cmake>`.
.. note::
@ -22,12 +22,12 @@ on a :doc:`separate page <Howto_cmake>`.
.. warning::
You must not mix the :doc:`traditional make based <Build_make>`
LAMMPS build procedure with using CMake. Thus no packages may be
LAMMPS build procedure with using CMake. No packages may be
installed or a build been previously attempted in the LAMMPS source
directory by using ``make <machine>``. CMake will detect if this is
the case and generate an error. To remove conflicting files from the
``src`` you can use the command ``make no-all purge`` which will
un-install all packages and delete all auto-generated files.
uninstall all packages and delete all auto-generated files.
Advantages of using CMake
@ -44,9 +44,9 @@ software or for people that want to modify or extend LAMMPS.
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 text mode or graphical
user interface. No knowledge of file formats or and complex command
line syntax required.
- 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.
- 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
@ -55,23 +55,23 @@ software or for people that want to modify or extend LAMMPS.
source tree.
- Simplified packaging of LAMMPS for Linux distributions, environment
modules, or automated build tools like `Homebrew <https://brew.sh/>`_.
- Integration of automated regression testing (the LAMMPS side for that
is still under development).
- Integration of automated unit and regression testing (the LAMMPS side
of this is still under active development).
.. _cmake_build:
Getting started
^^^^^^^^^^^^^^^
Building LAMMPS with CMake is a two-step process. First you use CMake
to generate a build environment in a new directory. For that purpose
you can use either the command-line utility ``cmake`` (or ``cmake3``),
the text-mode UI utility ``ccmake`` (or ``ccmake3``) or the graphical
utility ``cmake-gui``, or use them interchangeably. The second step is
then the compilation and linking of all objects, libraries, and
executables. Here is a minimal example using the command line version of
CMake to build LAMMPS with no add-on packages enabled and no
customization:
Building LAMMPS with CMake is a two-step process. In the first step,
you use CMake to generate a build environment in a new directory. For
that purpose you can use either the command-line utility ``cmake`` (or
``cmake3``), the text-mode UI utility ``ccmake`` (or ``ccmake3``) or the
graphical utility ``cmake-gui``, or use them interchangeably. The
second step is then the compilation and linking of all objects,
libraries, and executables using the selected build tool. Here is a
minimal example using the command line version of CMake to build LAMMPS
with no add-on packages enabled and no customization:
.. code-block:: bash
@ -96,17 +96,17 @@ Compilation can take a long time, since LAMMPS is a large project with
many features. If your machine has multiple CPU cores (most do these
days), you can speed this up by compiling sources in parallel with
``make -j N`` (with N being the maximum number of concurrently executed
tasks). Also installation of the `ccache <https://ccache.dev/>`_ (=
Compiler Cache) software may speed up repeated compilation even more,
e.g. during code development.
tasks). Installation of the `ccache <https://ccache.dev/>`_ (= Compiler
Cache) software may speed up repeated compilation even more, e.g. during
code development, especially when repeatedly switching between branches.
After the initial build, whenever you edit LAMMPS source files, enable
or disable packages, change compiler flags or build options, you must
re-compile and relink the LAMMPS executable with ``cmake --build .`` (or
``make``). If the compilation fails for some reason, try running
``cmake .`` and then compile again. The included dependency tracking
should make certain that only the necessary subset of files are
re-compiled. You can also delete compiled objects, libraries and
should make certain that only the necessary subset of files is
re-compiled. You can also delete compiled objects, libraries, and
executables with ``cmake --build . --target clean`` (or ``make clean``).
After compilation, you may optionally install the LAMMPS executable into
@ -132,12 +132,12 @@ file called ``CMakeLists.txt`` (for LAMMPS it is located in the
``CMakeCache.txt``, which is generated at the end of the CMake
configuration step. The cache file contains all current CMake settings.
To modify settings, enable or disable features, you need to set *variables*
with either the *-D* command line flag (``-D VARIABLE1_NAME=value``) or
change them in the text mode of graphical user interface. The *-D* flag
can be used several times in one command.
To modify settings, enable or disable features, you need to set
*variables* with either the *-D* command line flag (``-D
VARIABLE1_NAME=value``) or change them in the text mode of the graphical
user interface. The *-D* flag can be used several times in one command.
For your convenience we provide :ref:`CMake presets <cmake_presets>`
For your convenience, we provide :ref:`CMake presets <cmake_presets>`
that combine multiple settings to enable optional LAMMPS packages or use
a different compiler tool chain. Those are loaded with the *-C* flag
(``-C ../cmake/presets/basic.cmake``). This step would only be needed
@ -155,22 +155,23 @@ specific CMake version is given when running ``cmake --help``.
Multi-configuration build systems
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Throughout this manual it is mostly assumed that LAMMPS is being built
Throughout this manual, it is mostly assumed that LAMMPS is being built
on a Unix-like operating system with "make" as the underlying "builder",
since this is the most common case. In this case the build "configuration"
is chose using ``-D CMAKE_BUILD_TYPE=<configuration>`` with ``<configuration>``
being one of "Release", "Debug", "RelWithDebInfo", or "MinSizeRel".
Some build tools, however, can also use or even require to have a so-called
multi-configuration build system setup. For those the built type (or
configuration) is chosen at compile time using the same build files. E.g.
with:
since this is the most common case. In this case the build
"configuration" is chose using ``-D CMAKE_BUILD_TYPE=<configuration>``
with ``<configuration>`` being one of "Release", "Debug",
"RelWithDebInfo", or "MinSizeRel". Some build tools, however, can also
use or even require having a so-called multi-configuration build system
setup. For a multi-configuration build, the built type (or
configuration) is selected at compile time using the same build
files. E.g. with:
.. code-block:: bash
cmake --build build-multi --config Release
In that case the resulting binaries are not in the build folder directly
but in sub-directories corresponding to the build type (i.e. Release in
but in subdirectories corresponding to the build type (i.e. Release in
the example from above). Similarly, for running unit tests the
configuration is selected with the *-C* flag:
@ -184,7 +185,7 @@ 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.
portable to Windows, either.
Installing CMake

2
doc/src/Build_development.rst
View File

@ -46,7 +46,7 @@ It can be enabled for all C++ code with the following CMake flag
With this flag enabled all source files will be processed twice, first to
be compiled and then to be analyzed. Please note that the analysis can be
significantly more time consuming than the compilation itself.
significantly more time-consuming than the compilation itself.
----------

68
doc/src/Build_extras.rst
View File

@ -47,7 +47,6 @@ This is the list of packages that may require additional steps.
* :ref:`LEPTON <lepton>`
* :ref:`MACHDYN <machdyn>`
* :ref:`MDI <mdi>`
* :ref:`MESONT <mesont>`
* :ref:`ML-HDNNP <ml-hdnnp>`
* :ref:`ML-IAP <mliap>`
* :ref:`ML-PACE <ml-pace>`
@ -288,7 +287,7 @@ your machine are not correct, the LAMMPS build will fail, and
.. note::
If you re-build the GPU library in ``lib/gpu``, you should always
un-install the GPU package in ``lammps/src``, then re-install it and
uninstall the GPU package in ``lammps/src``, then re-install it and
re-build LAMMPS. This is because the compilation of files in the GPU
package uses the library settings from the ``lib/gpu/Makefile.machine``
used to build the GPU library.
@ -915,9 +914,9 @@ included in the LAMMPS source distribution in the ``lib/lepton`` folder.
.. code-block:: bash
$ make lib-lepton # print help message
$ make lib-lepton args="-m serial" # build with GNU g++ compiler (settings as with "make serial")
$ make lib-lepton args="-m mpi" # build with default MPI compiler (settings as with "make mpi")
make lib-lepton # print help message
make lib-lepton args="-m serial" # build with GNU g++ compiler (settings as with "make serial")
make lib-lepton args="-m mpi" # build with default MPI compiler (settings as with "make mpi")
The "machine" argument of the "-m" flag is used to find a
Makefile.machine to use as build recipe.
@ -1391,8 +1390,21 @@ This package depends on the KSPACE package.
.. tab:: CMake build
No additional settings are needed besides ``-D PKG_KSPACE=yes`` and
``-D PKG_ELECTRODE=yes``.
.. code-block:: bash
-D PKG_ELECTRODE=yes # enable the package itself
-D PKG_KSPACE=yes # the ELECTRODE package requires KSPACE
-D USE_INTERNAL_LINALG=value #
Features in the ELECTRODE package are dependent on code in the
KSPACE package so the latter one *must* be enabled.
The ELECTRODE package also requires LAPACK (and BLAS) and CMake
can identify their locations and pass that info to the LATTE build
script. But on some systems this may cause problems when linking
or the dependency is not desired. Try enabling
``USE_INTERNAL_LINALG`` in those cases to use the bundled linear
algebra library and work around the limitation.
.. tab:: Traditional make
@ -1839,48 +1851,6 @@ MDI package
----------
.. _mesont:
MESONT package
-------------------------
This package includes a library written in Fortran 90 in the
``lib/mesont`` folder, so a working Fortran 90 compiler is required to
compile it. Also, the files with the force field data for running the
bundled examples are not included in the source distribution. Instead
they will be downloaded the first time this package is installed.
.. tabs::
.. tab:: CMake build
No additional settings are needed besides ``-D PKG_MESONT=yes``
.. tab:: Traditional make
Before building LAMMPS, you must build the *mesont* library in
``lib/mesont``\ . You can also do it in one step from the
``lammps/src`` dir, using a command like these, which simply
invokes the ``lib/mesont/Install.py`` script with the specified
args:
.. code-block:: bash
make lib-mesont # print help message
make lib-mesont args="-m gfortran" # build with GNU g++ compiler (settings as with "make serial")
make lib-mesont args="-m ifort" # build with Intel icc compiler
The build should produce two files: ``lib/mesont/libmesont.a`` and
``lib/mesont/Makefile.lammps``\ . The latter is copied from an
existing ``Makefile.lammps.\*`` and has settings needed to build
LAMMPS with the *mesont* library (though typically the settings
contain only the Fortran runtime library). If necessary, you can
edit/create a new ``lib/mesont/Makefile.machine`` file for your
system, which should define an ``EXTRAMAKE`` variable to specify a
corresponding ``Makefile.lammps.machine`` file.
----------
.. _molfile:
MOLFILE package

41
doc/src/Build_link.rst
View File

@ -1,33 +1,32 @@
Link LAMMPS as a library to another code
========================================
LAMMPS is designed as a library of C++ objects that can be
integrated into other applications including Python scripts.
The files ``src/library.cpp`` and ``src/library.h`` define a
C-style API for using LAMMPS as a library. See the
:doc:`Howto_library` page
for a description of the interface and how to use it for your needs.
LAMMPS is designed as a library of C++ objects that can be integrated
into other applications, including Python scripts. The files
``src/library.cpp`` and ``src/library.h`` define a C-style API for using
LAMMPS as a library. See the :doc:`Howto_library` page for a
description of the interface and how to use it for your needs.
The :doc:`Build_basics` page explains how to build
LAMMPS as either a shared or static library. This results in a file
in the compilation folder called ``liblammps.a`` or ``liblammps_<name>.a``
in case of building a static library. In case of a shared library
the name is the same only that the suffix is going to be either ``.so``
or ``.dylib`` or ``.dll`` instead of ``.a`` depending on the OS.
In some cases the ``.so`` file may be a symbolic link to a file with
the suffix ``.so.0`` (or some other number).
The :doc:`Build_basics` page explains how to build LAMMPS as either a
shared or static library. This results in a file in the compilation
folder called ``liblammps.a`` or ``liblammps_<name>.a`` in case of
building a static library. In case of a shared library, the name is the
same only that the suffix is going to be either ``.so`` or ``.dylib`` or
``.dll`` instead of ``.a`` depending on the OS. In some cases, the
``.so`` file may be a symbolic link to a file with the suffix ``.so.0``
(or some other number).
.. note::
Care should be taken to use the same MPI library for the calling code
and the LAMMPS library unless LAMMPS is to be compiled without (real)
MPI support using the include STUBS MPI library.
and the LAMMPS library, unless LAMMPS is to be compiled without (real)
MPI support using the included STUBS MPI library.
Link with LAMMPS as a static library
------------------------------------
The calling application can link to LAMMPS as a static library with
compilation and link commands as in the examples shown below. These
compilation and link commands, as in the examples shown below. These
are examples for a code written in C in the file ``caller.c``.
The benefit of linking to a static library is, that the resulting
executable is independent of that library since all required
@ -142,10 +141,10 @@ Link with LAMMPS as a shared library
When linking to LAMMPS built as a shared library, the situation becomes
much simpler, as all dependent libraries and objects are either included
in the shared library or registered as a dependent library in the shared
library file. Thus those libraries need not to be specified when
linking the calling executable. Only the *-I* flags are needed. So the
example case from above of the serial version static LAMMPS library with
the POEMS package installed becomes:
library file. Thus, those libraries need not be specified when linking
the calling executable. Only the *-I* flags are needed. So the example
case from above of the serial version static LAMMPS library with the
POEMS package installed becomes:
.. tabs::

58
doc/src/Build_make.rst
View File

@ -20,21 +20,22 @@ with :doc:`CMake <Build_cmake>`. The makefiles of the traditional
make based build process and the scripts they are calling expect a few
additional tools to be available and functioning.
* a working C/C++ compiler toolchain supporting the C++11 standard; on
Linux these are often the GNU compilers. Some older compilers
* A working C/C++ compiler toolchain supporting the C++11 standard; on
Linux, these are often the GNU compilers. Some older compiler versions
require adding flags like ``-std=c++11`` to enable the C++11 mode.
* a Bourne shell compatible "Unix" shell program (often this is ``bash``)
* a few shell utilities: ``ls``, ``mv``, ``ln``, ``rm``, ``grep``, ``sed``, ``tr``, ``cat``, ``touch``, ``diff``, ``dirname``
* python (optional, required for ``make lib-<pkg>`` in the src folder).
python scripts are currently tested with python 2.7 and 3.6. The procedure
for :doc:`building the documentation <Build_manual>` requires python 3.5 or later.
* A Bourne shell compatible "Unix" shell program (frequently this is ``bash``)
* A few shell utilities: ``ls``, ``mv``, ``ln``, ``rm``, ``grep``, ``sed``, ``tr``, ``cat``, ``touch``, ``diff``, ``dirname``
* Python (optional, required for ``make lib-<pkg>`` in the src
folder). Python scripts are currently tested with python 2.7 and
3.6 to 3.11. The procedure for :doc:`building the documentation
<Build_manual>` *requires* Python 3.5 or later.
Getting started
^^^^^^^^^^^^^^^
To include LAMMPS packages (i.e. optional commands and styles) you must
enable (or "install") them first, as discussed on the :doc:`Build
package <Build_package>` page. If a packages requires (provided or
package <Build_package>` page. If a package requires (provided or
external) libraries, you must configure and build those libraries
**before** building LAMMPS itself and especially **before** enabling
such a package with ``make yes-<package>``. :doc:`Building LAMMPS with
@ -56,36 +57,36 @@ Compilation can take a long time, since LAMMPS is a large project with
many features. If your machine has multiple CPU cores (most do these
days), you can speed this up by compiling sources in parallel with
``make -j N`` (with N being the maximum number of concurrently executed
tasks). Also installation of the `ccache <https://ccache.dev/>`_ (=
Compiler Cache) software may speed up repeated compilation even more,
e.g. during code development.
tasks). Installation of the `ccache <https://ccache.dev/>`_ (= Compiler
Cache) software may speed up repeated compilation even more, e.g. during
code development, especially when repeatedly switching between branches.
After the initial build, whenever you edit LAMMPS source files, or add
or remove new files to the source directory (e.g. by installing or
uninstalling packages), you must re-compile and relink the LAMMPS
executable with the same ``make <machine>`` command. The makefile's
dependency tracking should insure that only the necessary subset of
files are re-compiled. If you change settings in the makefile, you have
to recompile *everything*. To delete all objects you can use ``make
dependency tracking should ensure that only the necessary subset of
files is re-compiled. If you change settings in the makefile, you have
to recompile *everything*. To delete all objects, you can use ``make
clean-<machine>``.
.. note::
Before the actual compilation starts, LAMMPS will perform several
steps to collect information from the configuration and setup that
is then embedded into the executable. When you build LAMMPS for
the first time, it will also compile a tool to quickly assemble
a list of dependencies, that are required for the make program to
correctly detect which parts need to be recompiled after changes
were made to the sources.
steps to collect information from the configuration and setup that is
then embedded into the executable. When you build LAMMPS for the
first time, it will also compile a tool to quickly determine a list
of dependencies. Those are required for the make program to
correctly detect, which files need to be recompiled or relinked
after changes were made to the sources.
Customized builds and alternate makefiles
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The ``src/MAKE`` directory tree contains the ``Makefile.<machine>``
files included in the LAMMPS distribution. Typing ``make example`` uses
``Makefile.example`` from one of those folders, if available. Thus the
``make serial`` and ``make mpi`` lines above use
``Makefile.example`` from one of those folders, if available. The
``make serial`` and ``make mpi`` lines above, for example, use
``src/MAKE/Makefile.serial`` and ``src/MAKE/Makefile.mpi``,
respectively. Other makefiles are in these directories:
@ -106,12 +107,13 @@ a new name, please edit the first line with the description and machine
name, so you will not confuse yourself, when looking at the machine
summary.
Makefiles you may wish to try include these (some require a package
first be installed). Many of these include specific compiler flags
for optimized performance. Please note, however, that some of these
customized machine Makefile are contributed by users. Since both
compilers, OS configurations, and LAMMPS itself keep changing, their
settings may become outdated:
Makefiles you may wish to try out, include those listed below (some
require a package first be installed). Many of these include specific
compiler flags for optimized performance. Please note, however, that
some of these customized machine Makefile are contributed by users, and
thus may have modifications specific to the systems of those users.
Since compilers, OS configurations, and LAMMPS itself keep changing,
their settings may become outdated, too:
.. code-block:: bash

2
doc/src/Build_manual.rst
View File

@ -2,7 +2,7 @@ Build the LAMMPS documentation
==============================
Depending on how you obtained LAMMPS and whether you have built the
manual yourself, this directory has a number of sub-directories and
manual yourself, this directory has a number of subdirectories and
files. Here is a list with descriptions:
.. code-block:: bash

46
doc/src/Build_package.rst
View File

@ -4,13 +4,14 @@ Include packages in build
In LAMMPS, a package is a group of files that enable a specific set of
features. For example, force fields for molecular systems or
rigid-body constraints are in packages. In the src directory, each
package is a sub-directory with the package name in capital letters.
package is a subdirectory with the package name in capital letters.
An overview of packages is given on the :doc:`Packages <Packages>` doc
page. Brief overviews of each package are on the :doc:`Packages details <Packages_details>` page.
page. Brief overviews of each package are on the :doc:`Packages details
<Packages_details>` page.
When building LAMMPS, you can choose to include or exclude each
package. In general there is no need to include a package if you
package. Generally, there is no need to include a package if you
never plan to use its features.
If you get a run-time error that a LAMMPS command or style is
@ -49,7 +50,6 @@ packages:
* :ref:`LEPTON <lepton>`
* :ref:`MACHDYN <machdyn>`
* :ref:`MDI <mdi>`
* :ref:`MESONT <mesont>`
* :ref:`ML-HDNNP <ml-hdnnp>`
* :ref:`ML-IAP <mliap>`
* :ref:`ML-PACE <ml-pace>`
@ -94,7 +94,7 @@ versus make.
If you switch between building with CMake and make builds, no
packages in the src directory can be installed when you invoke
``cmake``. CMake will give an error if that is not the case,
indicating how you can un-install all packages in the src dir.
indicating how you can uninstall all packages in the src dir.
.. tab:: Traditional make
@ -103,7 +103,7 @@ versus make.
cd lammps/src
make ps # check which packages are currently installed
make yes-name # install a package with name
make no-name # un-install a package with name
make no-name # uninstall a package with name
make mpi # build LAMMPS with whatever packages are now installed
Examples:
@ -119,13 +119,13 @@ versus make.
.. note::
You must always re-build LAMMPS (via make) after installing or
un-installing a package, for the action to take effect. The
uninstalling a package, for the action to take effect. The
included dependency tracking will make certain only files that
are required to be rebuilt are recompiled.
.. note::
You cannot install or un-install packages and build LAMMPS in a
You cannot install or uninstall packages and build LAMMPS in a
single make command with multiple targets, e.g. ``make
yes-colloid mpi``. This is because the make procedure creates
a list of source files that will be out-of-date for the build
@ -150,7 +150,7 @@ other files dependent on that package are also excluded.
if you downloaded a tarball, 3 packages (KSPACE, MANYBODY, MOLECULE)
were pre-installed via the traditional make procedure in the ``src``
directory. That is no longer the case, so that CMake will build
as-is without needing to un-install those packages.
as-is without needing to uninstall those packages.
----------
@ -167,9 +167,9 @@ control flow constructs for more complex operations.
LAMMPS includes several of these files to define configuration
"presets", similar to the options that exist for the Make based
system. Using these files you can enable/disable portions of the
available packages in LAMMPS. If you need a custom preset you can take
one of them as a starting point and customize it to your needs.
system. Using these files, you can enable/disable portions of the
available packages in LAMMPS. If you need a custom preset, you can
make a copy of one of them and modify it to suit your needs.
.. code-block:: bash
@ -183,7 +183,7 @@ one of them as a starting point and customize it to your needs.
cmake -C ../cmake/presets/pgi.cmake [OPTIONS] ../cmake # change settings to use the PGI compilers by default
cmake -C ../cmake/presets/all_on.cmake [OPTIONS] ../cmake # enable all packages
cmake -C ../cmake/presets/all_off.cmake [OPTIONS] ../cmake # disable all packages
mingw64-cmake -C ../cmake/presets/mingw-cross.cmake [OPTIONS] ../cmake # compile with MinGW cross compilers
mingw64-cmake -C ../cmake/presets/mingw-cross.cmake [OPTIONS] ../cmake # compile with MinGW cross-compilers
Presets that have names starting with "windows" are specifically for
compiling LAMMPS :doc:`natively on Windows <Build_windows>` and
@ -227,7 +227,7 @@ The following commands are useful for managing package source files
and their installation when building LAMMPS via traditional make.
Just type ``make`` in lammps/src to see a one-line summary.
These commands install/un-install sets of packages:
These commands install/uninstall sets of packages:
.. code-block:: bash
@ -243,40 +243,40 @@ These commands install/un-install sets of packages:
make yes-ext # install packages that require external libraries
make no-ext # uninstall packages that require external libraries
which install/un-install various sets of packages. Typing ``make
which install/uninstall various sets of packages. Typing ``make
package`` will list all the these commands.
.. note::
Installing or un-installing a package for the make based build process
Installing or uninstalling a package for the make based build process
works by simply copying files back and forth between the main source
directory src and the sub-directories with the package name (e.g.
directory src and the subdirectories with the package name (e.g.
src/KSPACE, src/ATC), so that the files are included or excluded
when LAMMPS is built. Only source files in the src folder will be
compiled.
The following make commands help manage files that exist in both the
src directory and in package sub-directories. You do not normally
src directory and in package subdirectories. You do not normally
need to use these commands unless you are editing LAMMPS files or are
updating LAMMPS via git.
Type ``make package-status`` or ``make ps`` to show which packages are
currently installed. For those that are installed, it will list any
files that are different in the src directory and package
sub-directory.
subdirectory.
Type ``make package-installed`` or ``make pi`` to show which packages are
currently installed, without listing the status of packages that are
not installed.
Type ``make package-update`` or ``make pu`` to overwrite src files with
files from the package sub-directories if the package is installed. It
files from the package subdirectories if the package is installed. It
should be used after the checkout has been :doc:`updated or changed
withy git <Install_git>`, this will only update the files in the package
sub-directories, but not the copies in the src folder.
with git <Install_git>`, this will only update the files in the package
subdirectories, but not the copies in the src folder.
Type ``make package-overwrite`` to overwrite files in the package
sub-directories with src files.
subdirectories with src files.
Type ``make package-diff`` to list all differences between pairs of
files in both the source directory and the package directory.

56
doc/src/Build_settings.rst
View File

@ -1,8 +1,8 @@
Optional build settings
=======================
LAMMPS can be built with several optional settings. Each sub-section
explain how to do this for building both with CMake and make.
LAMMPS can be built with several optional settings. Each subsection
explains how to do this for building both with CMake and make.
* `C++11 standard compliance`_ when building all of LAMMPS
* `FFT library`_ for use with the :doc:`kspace_style pppm <kspace_style>` command
@ -41,7 +41,7 @@ FFT library
When the KSPACE package is included in a LAMMPS build, the
:doc:`kspace_style pppm <kspace_style>` command performs 3d FFTs which
require use of an FFT library to compute 1d FFTs. The KISS FFT
library is included with LAMMPS but other libraries can be faster.
library is included with LAMMPS, but other libraries can be faster.
LAMMPS can use them if they are available on your system.
.. tabs::
@ -63,9 +63,9 @@ LAMMPS can use them if they are available on your system.
Usually these settings are all that is needed. If FFTW3 is
selected, then CMake will try to detect, if threaded FFTW
libraries are available and enable them by default. This setting
is independent of whether OpenMP threads are enabled and a
packages like KOKKOS or OPENMP is used. If CMake cannot detect
the FFT library, you can set these variables to assist:
is independent of whether OpenMP threads are enabled and a package
like KOKKOS or OPENMP is used. If CMake cannot detect the FFT
library, you can set these variables to assist:
.. code-block:: bash
@ -141,18 +141,18 @@ The Intel MKL math library is part of the Intel compiler suite. It
can be used with the Intel or GNU compiler (see the ``FFT_LIB`` setting
above).
Performing 3d FFTs in parallel can be time consuming due to data
access and required communication. This cost can be reduced by
performing single-precision FFTs instead of double precision. Single
precision means the real and imaginary parts of a complex datum are
4-byte floats. Double precision means they are 8-byte doubles. Note
that Fourier transform and related PPPM operations are somewhat less
sensitive to floating point truncation errors and thus the resulting
error is less than the difference in precision. Using the ``-DFFT_SINGLE``
setting trades off a little accuracy for reduced memory use and
parallel communication costs for transposing 3d FFT data.
Performing 3d FFTs in parallel can be time-consuming due to data access
and required communication. This cost can be reduced by performing
single-precision FFTs instead of double precision. Single precision
means the real and imaginary parts of a complex datum are 4-byte floats.
Double precision means they are 8-byte doubles. Note that Fourier
transform and related PPPM operations are somewhat less sensitive to
floating point truncation errors, and thus the resulting error is
generally less than the difference in precision. Using the
``-DFFT_SINGLE`` setting trades off a little accuracy for reduced memory
use and parallel communication costs for transposing 3d FFT data.
When using ``-DFFT_SINGLE`` with FFTW3 you may need to build the FFTW
When using ``-DFFT_SINGLE`` with FFTW3, you may need to build the FFTW
library a second time with support for single-precision.
For FFTW3, do the following, which should produce the additional
@ -177,11 +177,11 @@ ARRAY mode.
Size of LAMMPS integer types and size limits
--------------------------------------------
LAMMPS has a few integer data types which can be defined as either
4-byte (= 32-bit) or 8-byte (= 64-bit) integers at compile time.
This has an impact on the size of a system that can be simulated
or how large counters can become before "rolling over".
The default setting of "smallbig" is almost always adequate.
LAMMPS uses a few custom integer data types, which can be defined as
either 4-byte (= 32-bit) or 8-byte (= 64-bit) integers at compile time.
This has an impact on the size of a system that can be simulated, or how
large counters can become before "rolling over". The default setting of
"smallbig" is almost always adequate.
.. tabs::
@ -254,7 +254,7 @@ topology information, though IDs are enabled by default. The
:doc:`atom_modify id no <atom_modify>` command will turn them off. Atom
IDs are required for molecular systems with bond topology (bonds,
angles, dihedrals, etc). Similarly, some force or compute or fix styles
require atom IDs. Thus if you model a molecular system or use one of
require atom IDs. Thus, if you model a molecular system or use one of
those styles with more than 2 billion atoms, you need the "bigbig"
setting.
@ -264,7 +264,7 @@ systems and 500 million for systems with bonds (the additional
restriction is due to using the 2 upper bits of the local atom index
in neighbor lists for storing special bonds info).
Image flags store 3 values per atom in a single integer which count the
Image flags store 3 values per atom in a single integer, which count the
number of times an atom has moved through the periodic box in each
dimension. See the :doc:`dump <dump>` manual page for a discussion. If
an atom moves through the periodic box more than this limit, the value
@ -285,7 +285,7 @@ Output of JPG, PNG, and movie files
--------------------------------------------------
The :doc:`dump image <dump_image>` command has options to output JPEG or
PNG image files. Likewise the :doc:`dump movie <dump_image>` command
PNG image files. Likewise, the :doc:`dump movie <dump_image>` command
outputs movie files in a variety of movie formats. Using these options
requires the following settings:
@ -354,7 +354,7 @@ Read or write compressed files
If this option is enabled, large files can be read or written with
compression by ``gzip`` or similar tools by several LAMMPS commands,
including :doc:`read_data <read_data>`, :doc:`rerun <rerun>`, and
:doc:`dump <dump>`. Currently supported compression tools are:
:doc:`dump <dump>`. Supported compression tools are currently
``gzip``, ``bzip2``, ``zstd``, and ``lzma``.
.. tabs::
@ -394,7 +394,7 @@ Memory allocation alignment
---------------------------------------
This setting enables the use of the "posix_memalign()" call instead of
"malloc()" when LAMMPS allocates large chunks or memory. Vector
"malloc()" when LAMMPS allocates large chunks of memory. Vector
instructions on CPUs may become more efficient, if dynamically allocated
memory is aligned on larger-than-default byte boundaries. On most
current operating systems, the "malloc()" implementation returns
@ -496,7 +496,7 @@ Trigger selected floating-point exceptions
------------------------------------------
Many kinds of CPUs have the capability to detect when a calculation
results in an invalid math operation like a division by zero or calling
results in an invalid math operation, like a division by zero or calling
the square root with a negative argument. The default behavior on
most operating systems is to continue and have values for ``NaN`` (= not
a number) or ``Inf`` (= infinity). This allows software to detect and

1
doc/src/Commands_compute.rst
View File

@ -88,7 +88,6 @@ 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:`mesont <compute_mesont>`
* :doc:`mliap <compute_mliap>`
* :doc:`momentum <compute_momentum>`
* :doc:`msd <compute_msd>`

6
doc/src/Commands_fix.rst
View File

@ -44,9 +44,6 @@ OPT.
* :doc:`ave/time <fix_ave_time>`
* :doc:`aveforce <fix_aveforce>`
* :doc:`balance <fix_balance>`
* :doc:`brownian <fix_brownian>`
* :doc:`brownian/asphere <fix_brownian>`
* :doc:`brownian/sphere <fix_brownian>`
* :doc:`bocs <fix_bocs>`
* :doc:`bond/break <fix_bond_break>`
* :doc:`bond/create <fix_bond_create>`
@ -54,6 +51,9 @@ OPT.
* :doc:`bond/react <fix_bond_react>`
* :doc:`bond/swap <fix_bond_swap>`
* :doc:`box/relax <fix_box_relax>`
* :doc:`brownian <fix_brownian>`
* :doc:`brownian/asphere <fix_brownian>`
* :doc:`brownian/sphere <fix_brownian>`
* :doc:`charge/regulation <fix_charge_regulation>`
* :doc:`cmap <fix_cmap>`
* :doc:`colvars <fix_colvars>`

1
doc/src/Commands_pair.rst
View File

@ -204,7 +204,6 @@ OPT.
* :doc:`meam/sw/spline <pair_meam_sw_spline>`
* :doc:`mesocnt <pair_mesocnt>`
* :doc:`mesocnt/viscous <pair_mesocnt>`
* :doc:`mesont/tpm <pair_mesont_tpm>`
* :doc:`mgpt <pair_mgpt>`
* :doc:`mie/cut (g) <pair_mie>`
* :doc:`mliap (k) <pair_mliap>`

21
doc/src/Commands_removed.rst
View File

@ -50,6 +50,27 @@ for some optimizations leading to better performance. The pair style
period the C++ version of MEAM was called USER-MEAMC so it could
coexist with the Fortran version.
Minimize style fire/old
-----------------------
.. deprecated:: TBD
Minimize style *fire/old* has been removed. Its functionality can be
reproduced with *fire* with specific options. Please see the
:doc:`min_modify command <min_modify>` documentation for details.
Pair style mesont/tpm, compute style mesont, atom style mesont
--------------------------------------------------------------
.. deprecated:: TBD
Pair style *mesont/tpm*, compute style *mesont*, and atom style
*mesont* have been removed from the :ref:`MESONT package <PKG-MESONT>`.
The same functionality is available through
:doc:`pair style mesocnt <pair_mesocnt>`,
:doc:`bond style mesocnt <bond_mesocnt>` and
:doc:`angle style mesocnt <angle_mesocnt>`.
REAX package
------------

4
doc/src/Developer_comm_ops.rst
View File

@ -14,8 +14,8 @@ Owned and ghost atoms
As described on the :doc:`parallel partitioning algorithms
<Developer_par_part>` page, LAMMPS spatially decomposes the simulation
domain, either in a *brick* or *tiled* manner. Each processor (MPI
task) owns atoms within its sub-domain and additionally stores ghost
atoms within a cutoff distance of its sub-domain.
task) owns atoms within its subdomain and additionally stores ghost
atoms within a cutoff distance of its subdomain.
Forward and reverse communication
=================================

6
doc/src/Developer_flow.rst
View File

@ -139,7 +139,7 @@ Periodic boundary conditions are then applied by the Domain class via
its ``pbc()`` method to remap particles that have moved outside the
simulation box back into the box. Note that this is not done every
timestep, but only when neighbor lists are rebuilt. This is so that
each processor's sub-domain will have consistent (nearby) atom
each processor's subdomain will have consistent (nearby) atom
coordinates for its owned and ghost atoms. It is also why dumped atom
coordinates may be slightly outside the simulation box if not dumped
on a step where the neighbor lists are rebuilt.
@ -153,10 +153,10 @@ method of the Comm class and ``setup_bins()`` method of the Neighbor
class perform the update.
The code is now ready to migrate atoms that have left a processor's
geometric sub-domain to new processors. The ``exchange()`` method of
geometric subdomain to new processors. The ``exchange()`` method of
the Comm class performs this operation. The ``borders()`` method of the
Comm class then identifies ghost atoms surrounding each processor's
sub-domain and communicates ghost atom information to neighboring
subdomain and communicates ghost atom information to neighboring
processors. It does this by looping over all the atoms owned by a
processor to make lists of those to send to each neighbor processor. On
subsequent timesteps, the lists are used by the ``Comm::forward_comm()``

31
doc/src/Developer_grid.rst
View File

@ -28,9 +28,9 @@ grid.
More specifically, a grid point is defined for each cell (by default
the center point), and a processor owns a grid cell if its point is
within the processor's spatial sub-domain. The union of processor
sub-domains is the global simulation box. If a grid point is on the
boundary of two sub-domains, the lower processor owns the grid cell. A
within the processor's spatial subdomain. The union of processor
subdomains is the global simulation box. If a grid point is on the
boundary of two subdomains, the lower processor owns the grid cell. A
processor may also store copies of ghost cells which surround its
owned cells.
@ -62,7 +62,7 @@ y-dimension. It is even possible to define a 1x1x1 3d grid, though it
may be inefficient to use it in a computational sense.
Note that the choice of grid size is independent of the number of
processors or their layout in a grid of processor sub-domains which
processors or their layout in a grid of processor subdomains which
overlays the simulations domain. Depending on the distributed grid
size, a single processor may own many 1000s or no grid cells.
@ -160,7 +160,7 @@ cells (the entire allocated grid).
Grid class constructors
^^^^^^^^^^^^^^^^^^^^^^^
The following sub-sections describe the public methods of the Grid3d
The following subsections describe the public methods of the Grid3d
class which a style command can invoke. The Grid2d methods are
similar; simply remove arguments which refer to the z-dimension.
@ -235,7 +235,7 @@ invoked, because they influence its operation.
void set_zfactor(double factor);
Processors own a grid cell if a point within the grid cell is inside
the processor's sub-domain. By default this is the center point of the
the processor's subdomain. By default this is the center point of the
grid cell. The *set_shift_grid()* method can change this. The *shift*
argument is a value from 0.0 to 1.0 (inclusive) which is the offset of
the point within the grid cell in each dimension. The default is 0.5
@ -245,9 +245,9 @@ typically no need to change the default as it is optimal for
minimizing the number of ghost cells needed.
If a processor maps its particles to grid cells, it needs to allow for
its particles being outside its sub-domain between reneighboring. The
its particles being outside its subdomain between reneighboring. The
*distance* argument of the *set_distance()* method sets the furthest
distance outside a processor's sub-domain which a particle can move.
distance outside a processor's subdomain which a particle can move.
Typically this is half the neighbor skin distance, assuming
reneighboring is done appropriately. This distance is used in
determining how many ghost cells a processor needs to store to enable
@ -295,7 +295,7 @@ to the Grid class via the *set_zfactor()* method (*set_yfactor()* for
2d grids). The Grid class will then assign ownership of the 1/3 of
grid cells that overlay the simulation box to the processors which
also overlay the simulation box. The remaining 2/3 of the grid cells
are assigned to processors whose sub-domains are adjacent to the upper
are assigned to processors whose subdomains are adjacent to the upper
z boundary of the simulation box.
----------
@ -533,7 +533,7 @@ processor's ghost cells extend further than nearest neighbor
processors.
This can be checked by callers who have the option to change the
global grid size to insure more efficient nearest-neighbor-only
global grid size to ensure more efficient nearest-neighbor-only
communication if they wish. In this case, they instantiate a grid of
a given size (resolution), then invoke *setup_comm()* followed by
*ghost_adjacent()*. If the ghost cells are not adjacent, they destroy
@ -549,13 +549,13 @@ Grid class remap methods for load balancing
The following methods are used when a load-balancing operation,
triggered by the :doc:`balance <balance>` or :doc:`fix balance
<fix_balance>` commands, changes the partitioning of the simulation
domain into processor sub-domains.
domain into processor subdomains.
In order to work with load-balancing, any style command (compute, fix,
pair, or kspace style) which allocates a grid and stores per-grid data
should define a *reset_grid()* method; it takes no arguments. It will
be called by the two balance commands after they have reset processor
sub-domains and migrated atoms (particles) to new owning processors.
subdomains and migrated atoms (particles) to new owning processors.
The *reset_grid()* method will typically perform some or all of the
following operations. See the src/fix_ave_grid.cpp and
src/EXTRA_FIX/fix_ttm_grid.cpp files for examples of *reset_grid()*
@ -564,7 +564,7 @@ functions.
First, the *reset_grid()* method can instantiate new grid(s) of the
same global size, then call *setup_grid()* to partition them via the
new processor sub-domains. At this point, it can invoke the
new processor subdomains. At this point, it can invoke the
*identical()* method which compares the owned and ghost grid cell
index bounds between two grids, the old grid passed as a pointer
argument, and the new grid whose *identical()* method is being called.
@ -753,7 +753,7 @@ their input script syntax, as described on the :doc:`Howto_grid
* f_ID:gname:dname
* f_ID:gname:dname[I]
Each grid a command instantiates has a unique *gname*, defined by the
Each grid command instantiates has a unique *gname*, defined by the
command. Likewise each grid cell data structure (scalar or vector)
associated with a grid has a unique *dname*, also defined by the
command.
@ -784,8 +784,7 @@ The *get_grid_by_index()* method is called after the
*get_grid_by_name()* method, using the grid index it returned as its
argument. This method will return a pointer to the Grid2d or Grid3d
class. The caller can use this to query grid attributes, such as the
global size of the grid. The :doc:`dump grid <dump>` to insure each
its grid reference arguments are for grids of the same size.
global size of the grid, to ensure it is of the expected size.
The *get_griddata_by_name()* method takes a grid index *igrid* and a
data name as input. It returns two values. The *ncol* argument is

4
doc/src/Developer_notes.rst
View File

@ -102,7 +102,7 @@ build is then :doc:`processed in parallel <Developer_par_neigh>`.
The most commonly required neighbor list is a so-called "half" neighbor
list, where each pair of atoms is listed only once (except when the
:doc:`newton command setting <newton>` for pair is off; in that case
pairs straddling sub-domains or periodic boundaries will be listed twice).
pairs straddling subdomains or periodic boundaries will be listed twice).
Thus these are the default settings when a neighbor list request is created in:
.. code-block:: c++
@ -361,7 +361,7 @@ allocated as a 1d vector or 3d array. Either way, the ordering of
values within contiguous memory x fastest, then y, z slowest.
For the ``3d decomposition`` of the grid, the global grid is
partitioned into bricks that correspond to the sub-domains of the
partitioned into bricks that correspond to the subdomains of the
simulation box that each processor owns. Often, this is a regular 3d
array (Px by Py by Pz) of bricks, where P = number of processors =
Px * Py * Pz. More generally it can be a tiled decomposition, where

10
doc/src/Developer_org.rst
View File

@ -7,7 +7,7 @@ but there are small a number of files in several other languages like C,
Fortran, Shell script, or Python.
The core of the code is located in the ``src`` folder and its
sub-directories. A sizable number of these files are in the ``src``
subdirectories. A sizable number of these files are in the ``src``
directory itself, but there are plenty of :doc:`packages <Packages>`,
which can be included or excluded when LAMMPS is built. See the
:doc:`Include packages in build <Build_package>` section of the manual
@ -16,11 +16,11 @@ currently supports building with :doc:`conventional makefiles
<Build_make>` and through :doc:`CMake <Build_cmake>`. Those procedures
differ in how packages are enabled or disabled for inclusion into a
LAMMPS binary so they cannot be mixed. The source files for each
package are in all-uppercase sub-directories of the ``src`` folder, for
package are in all-uppercase subdirectories of the ``src`` folder, for
example ``src/MOLECULE`` or ``src/EXTRA-MOLECULE``. The ``src/STUBS``
sub-directory is not a package but contains a dummy MPI library, that is
subdirectory is not a package but contains a dummy MPI library, that is
used when building a serial version of the code. The ``src/MAKE``
directory and its sub-directories contain makefiles with settings and
directory and its subdirectories contain makefiles with settings and
flags for a variety of configuration and machines for the build process
with traditional makefiles.
@ -28,7 +28,7 @@ The ``lib`` directory contains the source code for several supporting
libraries or files with configuration settings to use globally installed
libraries, that are required by some of the optional packages. They may
include python scripts that can transparently download additional source
code on request. Each sub-directory, like ``lib/poems`` or ``lib/gpu``,
code on request. Each subdirectory, like ``lib/poems`` or ``lib/gpu``,
contains the source files, some of which are in different languages such
as Fortran or CUDA. These libraries included in the LAMMPS build,
if the corresponding package is installed.

20
doc/src/Developer_par_comm.rst
View File

@ -7,16 +7,16 @@ large systems provided it uses a correspondingly large number of MPI
processes. Since The per-atom data (atom IDs, positions, velocities,
types, etc.) To be able to compute the short-range interactions MPI
processes need not only access to data of atoms they "own" but also
information about atoms from neighboring sub-domains, in LAMMPS referred
information about atoms from neighboring subdomains, in LAMMPS referred
to as "ghost" atoms. These are copies of atoms storing required
per-atom data for up to the communication cutoff distance. The green
dashed-line boxes in the :ref:`domain-decomposition` figure illustrate
the extended ghost-atom sub-domain for one processor.
the extended ghost-atom subdomain for one processor.
This approach is also used to implement periodic boundary
conditions: atoms that lie within the cutoff distance across a periodic
boundary are also stored as ghost atoms and taken from the periodic
replication of the sub-domain, which may be the same sub-domain, e.g. if
replication of the subdomain, which may be the same subdomain, e.g. if
running in serial. As a consequence of this, force computation in
LAMMPS is not subject to minimum image conventions and thus cutoffs may
be larger than half the simulation domain.
@ -28,10 +28,10 @@ be larger than half the simulation domain.
ghost atom communication
This figure shows the ghost atom communication patterns between
sub-domains for "brick" (left) and "tiled" communication styles for
subdomains for "brick" (left) and "tiled" communication styles for
2d simulations. The numbers indicate MPI process ranks. Here the
sub-domains are drawn spatially separated for clarity. The
dashed-line box is the extended sub-domain of processor 0 which
subdomains are drawn spatially separated for clarity. The
dashed-line box is the extended subdomain of processor 0 which
includes its ghost atoms. The red- and blue-shaded boxes are the
regions of communicated ghost atoms.
@ -42,7 +42,7 @@ atom communication is performed in two stages for a 2d simulation (three
in 3d) for both a regular and irregular partitioning of the simulation
box. For the regular case (left) atoms are exchanged first in the
*x*-direction, then in *y*, with four neighbors in the grid of processor
sub-domains.
subdomains.
In the *x* stage, processor ranks 1 and 2 send owned atoms in their
red-shaded regions to rank 0 (and vice versa). Then in the *y* stage,
@ -55,7 +55,7 @@ For the irregular case (right) the two stages are similar, but a
processor can have more than one neighbor in each direction. In the
*x* stage, MPI ranks 1,2,3 send owned atoms in their red-shaded regions to
rank 0 (and vice versa). These include only atoms between the lower
and upper *y*-boundary of rank 0's sub-domain. In the *y* stage, ranks
and upper *y*-boundary of rank 0's subdomain. In the *y* stage, ranks
4,5,6 send atoms in their blue-shaded regions to rank 0. This may
include ghost atoms they received in the *x* stage, but only if they
are needed by rank 0 to fill its extended ghost atom regions in the
@ -110,11 +110,11 @@ performed in LAMMPS:
over 3x the length of a stretched bond for dihedral interactions. It
can also exceed the periodic box size. For the regular communication
pattern (left), if the cutoff distance extends beyond a neighbor
processor's sub-domain, then multiple exchanges are performed in the
processor's subdomain, then multiple exchanges are performed in the
same direction. Each exchange is with the same neighbor processor,
but buffers are packed/unpacked using a different list of atoms. For
forward communication, in the first exchange a processor sends only
owned atoms. In subsequent exchanges, it sends ghost atoms received
in previous exchanges. For the irregular pattern (right) overlaps of
a processor's extended ghost-atom sub-domain with all other processors
a processor's extended ghost-atom subdomain with all other processors
in each dimension are detected.

10
doc/src/Developer_par_long.rst
View File

@ -20,7 +20,7 @@ e) electric field values from grid points near each atom are interpolated to com
For any of the spatial-decomposition partitioning schemes each processor
owns the brick-shaped portion of FFT grid points contained within its
sub-domain. The two interpolation operations use a stencil of grid
subdomain. The two interpolation operations use a stencil of grid
points surrounding each atom. To accommodate the stencil size, each
processor also stores a few layers of ghost grid points surrounding its
brick. Forward and reverse communication of grid point values is
@ -64,7 +64,7 @@ direction of the 1d FFTs it has to perform. LAMMPS uses the
pencil-decomposition algorithm as shown in the :ref:`fft-parallel` figure.
Initially (far left), each processor owns a brick of same-color grid
cells (actually grid points) contained within in its sub-domain. A
cells (actually grid points) contained within in its subdomain. A
brick-to-pencil communication operation converts this layout to 1d
pencils in the *x*-dimension (center left). Again, cells of the same
color are owned by the same processor. Each processor can then compute
@ -161,8 +161,8 @@ grid/particle operations that LAMMPS supports:
<partition>` calculation and then use the :doc:`verlet/split
integrator <run_style>` to perform the PPPM computation on a
dedicated, separate partition of MPI processes. This uses an integer
"1:*p*" mapping of *p* sub-domains of the atom decomposition to one
sub-domain of the FFT grid decomposition and where pairwise non-bonded
"1:*p*" mapping of *p* subdomains of the atom decomposition to one
subdomain of the FFT grid decomposition and where pairwise non-bonded
and bonded forces and energies are computed on the larger partition
and the PPPM kspace computation concurrently on the smaller partition.
@ -172,7 +172,7 @@ grid/particle operations that LAMMPS supports:
- LAMMPS implements a ``GridComm`` class which overlays the simulation
domain with a regular grid, partitions it across processors in a
manner consistent with processor sub-domains, and provides methods for
manner consistent with processor subdomains, and provides methods for
forward and reverse communication of owned and ghost grid point
values. It is used for PPPM as an FFT grid (as outlined above) and
also for the MSM algorithm which uses a cascade of grid sizes from

14
doc/src/Developer_par_neigh.rst
View File

@ -22,7 +22,7 @@ last reneighboring; this and other options of the neighbor list rebuild
can be adjusted with the :doc:`neigh_modify <neigh_modify>` command.
On steps when reneighboring is performed, atoms which have moved outside
their owning processor's sub-domain are first migrated to new processors
their owning processor's subdomain are first migrated to new processors
via communication. Periodic boundary conditions are also (only)
enforced on these steps to ensure each atom is re-assigned to the
correct processor. After migration, the atoms owned by each processor
@ -39,12 +39,12 @@ its settings modified with the :doc:`atom_modify <atom_modify>` command.
neighbor list stencils
A 2d simulation sub-domain (thick black line) and the corresponding
A 2d simulation subdomain (thick black line) and the corresponding
ghost atom cutoff region (dashed blue line) for both orthogonal
(left) and triclinic (right) domains. A regular grid of neighbor
bins (thin lines) overlays the entire simulation domain and need not
align with sub-domain boundaries; only the portion overlapping the
augmented sub-domain is shown. In the triclinic case it overlaps the
align with subdomain boundaries; only the portion overlapping the
augmented subdomain is shown. In the triclinic case it overlaps the
bounding box of the tilted rectangle. The blue- and red-shaded bins
represent a stencil of bins searched to find neighbors of a particular
atom (black dot).
@ -52,8 +52,8 @@ its settings modified with the :doc:`atom_modify <atom_modify>` command.
To build a local neighbor list in linear time, the simulation domain is
overlaid (conceptually) with a regular 3d (or 2d) grid of neighbor bins,
as shown in the :ref:`neighbor-stencil` figure for 2d models and a
single MPI processor's sub-domain. Each processor stores a set of
neighbor bins which overlap its sub-domain extended by the neighbor
single MPI processor's subdomain. Each processor stores a set of
neighbor bins which overlap its subdomain extended by the neighbor
cutoff distance :math:`R_n`. As illustrated, the bins need not align
with processor boundaries; an integer number in each dimension is fit to
the size of the entire simulation box.
@ -144,7 +144,7 @@ supports:
- For small and sparse systems and as a fallback method, LAMMPS also
supports neighbor list construction without binning by using a full
:math:`O(N^2)` loop over all *i,j* atom pairs in a sub-domain when
:math:`O(N^2)` loop over all *i,j* atom pairs in a subdomain when
using the :doc:`neighbor nsq <neighbor>` command.
- Dependent on the "pair" setting of the :doc:`newton <newton>` command,

28
doc/src/Developer_par_part.rst
View File

@ -15,8 +15,8 @@ distributed-memory parallelism is set with the :doc:`comm_style command
for MPI parallelization: "brick" on the left with an orthogonal
(left) and a triclinic (middle) simulation domain, and a "tiled"
decomposition (right). The black lines show the division into
sub-domains and the contained atoms are "owned" by the corresponding
MPI process. The green dashed lines indicate how sub-domains are
subdomains and the contained atoms are "owned" by the corresponding
MPI process. The green dashed lines indicate how subdomains are
extended with "ghost" atoms up to the communication cutoff distance.
The LAMMPS simulation box is a 3d or 2d volume, which can be orthogonal
@ -32,14 +32,14 @@ means the position of the box face adjusts continuously to enclose all
the atoms.
For distributed-memory MPI parallelism, the simulation box is spatially
decomposed (partitioned) into non-overlapping sub-domains which fill the
decomposed (partitioned) into non-overlapping subdomains which fill the
box. The default partitioning, "brick", is most suitable when atom
density is roughly uniform, as shown in the left-side images of the
:ref:`domain-decomposition` figure. The sub-domains comprise a regular
grid and all sub-domains are identical in size and shape. Both the
:ref:`domain-decomposition` figure. The subdomains comprise a regular
grid and all subdomains are identical in size and shape. Both the
orthogonal and triclinic boxes can deform continuously during a
simulation, e.g. to compress a solid or shear a liquid, in which case
the processor sub-domains likewise deform.
the processor subdomains likewise deform.
For models with non-uniform density, the number of particles per
@ -50,14 +50,14 @@ load. For such models, LAMMPS supports multiple strategies to reduce
the load imbalance:
- The processor grid decomposition is by default based on the simulation
cell volume and tries to optimize the volume to surface ratio for the sub-domains.
cell volume and tries to optimize the volume to surface ratio for the subdomains.
This can be changed with the :doc:`processors command <processors>`.
- The parallel planes defining the size of the sub-domains can be shifted
- The parallel planes defining the size of the subdomains can be shifted
with the :doc:`balance command <balance>`. Which can be done in addition
to choosing a more optimal processor grid.
- The recursive bisectioning algorithm in combination with the "tiled"
communication style can produce a partitioning with equal numbers of
particles in each sub-domain.
particles in each subdomain.
.. |decomp1| image:: img/decomp-regular.png
@ -76,14 +76,14 @@ the load imbalance:
The pictures above demonstrate different decompositions for a 2d system
with 12 MPI ranks. The atom colors indicate the load imbalance of each
sub-domain with green being optimal and red the least optimal.
subdomain with green being optimal and red the least optimal.
Due to the vacuum in the system, the default decomposition is unbalanced
with several MPI ranks without atoms (left). By forcing a 1x12x1
processor grid, every MPI rank does computations now, but number of
atoms per sub-domain is still uneven and the thin slice shape increases
the amount of communication between sub-domains (center left). With a
2x6x1 processor grid and shifting the sub-domain divisions, the load
atoms per subdomain is still uneven and the thin slice shape increases
the amount of communication between subdomains (center left). With a
2x6x1 processor grid and shifting the subdomain divisions, the load
imbalance is further reduced and the amount of communication required
between sub-domains is less (center right). And using the recursive
between subdomains is less (center right). And using the recursive
bisectioning leads to further improved decomposition (right).

2
doc/src/Developer_parallel.rst
View File

@ -7,7 +7,7 @@ decomposition. The parallelization aims to be efficient, and resulting
in good strong scaling (= good speedup for the same system) and good
weak scaling (= the computational cost of enlarging the system is
proportional to the system size). Additional parallelization using GPUs
or OpenMP can also be applied within the sub-domain assigned to an MPI
or OpenMP can also be applied within the subdomain assigned to an MPI
process. For clarity, most of the following illustrations show the 2d
simulation case. The underlying algorithms in those cases, however,
apply to both 2d and 3d cases equally well.

2
doc/src/Developer_utils.rst
View File

@ -647,7 +647,7 @@ Communication buffer coding with *ubuf*
---------------------------------------
LAMMPS uses communication buffers where it collects data from various
class instances and then exchanges the data with neighboring sub-domains.
class instances and then exchanges the data with neighboring subdomains.
For simplicity those buffers are defined as ``double`` buffers and
used for doubles and integer numbers. This presents a unique problem
when 64-bit integers are used. While the storage needed for a ``double``

2
doc/src/Errors_common.rst
View File

@ -113,7 +113,7 @@ LAMMPS output, something is wrong with your simulation. If you
suspect this is happening, it is a good idea to print out
thermodynamic info frequently (e.g. every timestep) via the
:doc:`thermo <thermo>` so you can monitor what is happening.
Visualizing the atom movement is also a good idea to insure your model
Visualizing the atom movement is also a good idea to ensure your model
is behaving as you expect.
In parallel, one way LAMMPS can hang is due to how different MPI

20
doc/src/Errors_messages.rst
View File

@ -5635,7 +5635,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
Lost atoms are checked for each time thermo output is done. See the
thermo_modify lost command for options. Lost atoms usually indicate
bad dynamics, e.g. atoms have been blown far out of the simulation
box, or moved further than one processor's sub-domain away before
box, or moved further than one processor's subdomain away before
reneighboring.
*MEAM library error %d*
@ -6092,7 +6092,7 @@ keyword to allow for additional bonds to be formed
after a read_data, read_restart, or create_box command.
*Next command must list all universe and uloop variables*
This is to insure they stay in sync.
This is to ensure they stay in sync.
*No Kspace style defined for compute group/group*
Self-explanatory.
@ -6266,14 +6266,14 @@ keyword to allow for additional bonds to be formed
One or more atoms are attempting to map their charge to a MSM grid point
that is not owned by a processor. This is likely for one of two
reasons, both of them bad. First, it may mean that an atom near the
boundary of a processor's sub-domain has moved more than 1/2 the
boundary of a processor's subdomain has moved more than 1/2 the
:doc:`neighbor skin distance <neighbor>` without neighbor lists being
rebuilt and atoms being migrated to new processors. This also means
you may be missing pairwise interactions that need to be computed.
The solution is to change the re-neighboring criteria via the
:doc:`neigh_modify <neigh_modify>` command. The safest settings are
"delay 0 every 1 check yes". Second, it may mean that an atom has
moved far outside a processor's sub-domain or even the entire
moved far outside a processor's subdomain or even the entire
simulation box. This indicates bad physics, e.g. due to highly
overlapping atoms, too large a timestep, etc.
@ -6281,14 +6281,14 @@ keyword to allow for additional bonds to be formed
One or more atoms are attempting to map their charge to a PPPM grid
point that is not owned by a processor. This is likely for one of two
reasons, both of them bad. First, it may mean that an atom near the
boundary of a processor's sub-domain has moved more than 1/2 the
boundary of a processor's subdomain has moved more than 1/2 the
:doc:`neighbor skin distance <neighbor>` without neighbor lists being
rebuilt and atoms being migrated to new processors. This also means
you may be missing pairwise interactions that need to be computed.
The solution is to change the re-neighboring criteria via the
:doc:`neigh_modify <neigh_modify>` command. The safest settings are
"delay 0 every 1 check yes". Second, it may mean that an atom has
moved far outside a processor's sub-domain or even the entire
moved far outside a processor's subdomain or even the entire
simulation box. This indicates bad physics, e.g. due to highly
overlapping atoms, too large a timestep, etc.
@ -6296,14 +6296,14 @@ keyword to allow for additional bonds to be formed
One or more atoms are attempting to map their charge to a PPPM grid
point that is not owned by a processor. This is likely for one of two
reasons, both of them bad. First, it may mean that an atom near the
boundary of a processor's sub-domain has moved more than 1/2 the
boundary of a processor's subdomain has moved more than 1/2 the
:doc:`neighbor skin distance <neighbor>` without neighbor lists being
rebuilt and atoms being migrated to new processors. This also means
you may be missing pairwise interactions that need to be computed.
The solution is to change the re-neighboring criteria via the
:doc:`neigh_modify <neigh_modify>` command. The safest settings are
"delay 0 every 1 check yes". Second, it may mean that an atom has
moved far outside a processor's sub-domain or even the entire
moved far outside a processor's subdomain or even the entire
simulation box. This indicates bad physics, e.g. due to highly
overlapping atoms, too large a timestep, etc.
@ -7231,7 +7231,7 @@ keyword to allow for additional bonds to be formed
*Replacing a fix, but new style != old style*
A fix ID can be used a second time, but only if the style matches the
previous fix. In this case it is assumed you with to reset a fix's
previous fix. In this case it is assumed you want to reset a fix's
parameters. This error may mean you are mistakenly re-using a fix ID
when you do not intend to.
@ -7337,7 +7337,7 @@ keyword to allow for additional bonds to be formed
*Rigid body atoms %d %d missing on proc %d at step %ld*
This means that an atom cannot find the atom that owns the rigid body
it is part of, or vice versa. The solution is to use the communicate
cutoff command to insure ghost atoms are acquired from far enough away
cutoff command to ensure ghost atoms are acquired from far enough away
to encompass the max distance printed when the fix rigid/small command
was invoked.

18
doc/src/Errors_warnings.rst
View File

@ -109,9 +109,9 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
*Communication cutoff is shorter than a bond length based estimate. This may lead to errors.*
Since LAMMPS stores topology data with individual atoms, all atoms
comprising a bond, angle, dihedral or improper must be present on any
sub-domain that "owns" the atom with the information, either as a
subdomain that "owns" the atom with the information, either as a
local or a ghost atom. The communication cutoff is what determines up
to what distance from a sub-domain boundary ghost atoms are created.
to what distance from a subdomain boundary ghost atoms are created.
The communication cutoff is by default the largest non-bonded cutoff
plus the neighbor skin distance, but for short or non-bonded cutoffs
and/or long bonds, this may not be sufficient. This warning indicates
@ -351,7 +351,7 @@ This will most likely cause errors in kinetic fluctuations.
Self-explanatory.
*Kspace_modify slab param < 2.0 may cause unphysical behavior*
The kspace_modify slab parameter should be larger to insure periodic
The kspace_modify slab parameter should be larger to ensure periodic
grids padded with empty space do not overlap.
*Less insertions than requested*
@ -398,7 +398,7 @@ This will most likely cause errors in kinetic fluctuations.
Lost atoms are checked for each time thermo output is done. See the
thermo_modify lost command for options. Lost atoms usually indicate
bad dynamics, e.g. atoms have been blown far out of the simulation
box, or moved further than one processor's sub-domain away before
box, or moved further than one processor's subdomain away before
reneighboring.
*MSM mesh too small, increasing to 2 points in each direction*
@ -491,7 +491,7 @@ This will most likely cause errors in kinetic fluctuations.
*Neighbor exclusions used with KSpace solver may give inconsistent Coulombic energies*
This is because excluding specific pair interactions also excludes
them from long-range interactions which may not be the desired effect.
The special_bonds command handles this consistently by insuring
The special_bonds command handles this consistently by ensuring
excluded (or weighted) 1-2, 1-3, 1-4 interactions are treated
consistently by both the short-range pair style and the long-range
solver. This is not done for exclusions of charged atom pairs via the
@ -545,7 +545,7 @@ This will most likely cause errors in kinetic fluctuations.
If there are other fixes that act immediately after the initial stage
of time integration within a timestep (i.e. after atoms move), then
the command that sets up the dynamic group should appear after those
fixes. This will insure that dynamic group assignments are made
fixes. This will ensure that dynamic group assignments are made
after all atoms have moved.
*One or more respa levels compute no forces*
@ -582,13 +582,13 @@ This will most likely cause errors in kinetic fluctuations.
needed. The requested volume fraction may be too high, or other atoms
may be in the insertion region.
*Proc sub-domain size < neighbor skin, could lead to lost atoms*
*Proc subdomain size < neighbor skin, could lead to lost atoms*
The decomposition of the physical domain (likely due to load
balancing) has led to a processor's sub-domain being smaller than the
balancing) has led to a processor's subdomain being smaller than the
neighbor skin in one or more dimensions. Since reneighboring is
triggered by atoms moving the skin distance, this may lead to lost
atoms, if an atom moves all the way across a neighboring processor's
sub-domain before reneighboring is triggered.
subdomain before reneighboring is triggered.
*Reducing PPPM order b/c stencil extends beyond nearest neighbor processor*
This may lead to a larger grid than desired. See the kspace_modify overlap

8
doc/src/Examples.rst
View File

@ -1,7 +1,7 @@
Example scripts
===============
The LAMMPS distribution includes an examples sub-directory with many
The LAMMPS distribution includes an examples subdirectory with many
sample problems. Many are 2d models that run quickly and are
straightforward to visualize, requiring at most a couple of minutes to
run on a desktop machine. Each problem has an input script (in.\*) and
@ -29,7 +29,7 @@ be quickly post-processed into a movie using commands described on the
Animations of many of the examples can be viewed on the Movies section
of the `LAMMPS website <https://www.lammps.org/movies.html>`_.
There are two kinds of sub-directories in the examples folder. Lower
There are two kinds of subdirectories in the examples folder. Lower
case named directories contain one or a few simple, quick-to-run
problems. Upper case named directories contain up to several complex
scripts that illustrate a particular kind of simulation method or
@ -221,10 +221,10 @@ Uppercase directories
Nearly all of these directories have README files which give more
details on how to understand and use their contents.
The PACKAGES directory has a large number of sub-directories which
The PACKAGES directory has a large number of subdirectories which
correspond by name to specific packages. They contain scripts that
illustrate how to use the command(s) provided in those packages. Many
of the sub-directories have their own README files which give further
of the subdirectories have their own README files which give further
instructions. See the :doc:`Packages_details <Packages_details>` doc
page for more info on specific packages.

9
doc/src/Fortran.rst
View File

@ -47,6 +47,15 @@ Fortran code in order to uses the Fortran interface.
A working example can be found together with equivalent examples in C and
C++ in the ``examples/COUPLE/simple`` folder of the LAMMPS distribution.
.. admonition:: Fortran compiler compatibility
:class: note
A fully Fortran 2003 compatible Fortran compiler is required.
This means that currently only GNU Fortran 9 and later are
compatible and thus the default compilers of Red Hat or CentOS 7
and Ubuntu 18.04 LTS and not compatible. Either newer compilers
need to be installed or the Linux updated.
.. versionchanged:: TBD
.. note::

2
doc/src/Howto_2d.rst
View File

@ -22,7 +22,7 @@ atom in the file, assign a z coordinate so it falls inside the
z-boundaries of the box - e.g. 0.0.
Use the :doc:`fix enforce2d <fix_enforce2d>` command as the last
defined fix to insure that the z-components of velocities and forces
defined fix to ensure that the z-components of velocities and forces
are zeroed out every timestep. The reason to make it the last fix is
so that any forces induced by other fixes will be zeroed out.

2
doc/src/Howto_cmake.rst
View File

@ -89,7 +89,7 @@ different options (``build-parallel``, ``build-serial``) or with
different compilers (``build-gnu``, ``build-clang``, ``build-intel``)
and so on. All the auxiliary files created by one build process
(executable, object files, log files, etc) are stored in this directory
or sub-directories within it that CMake creates.
or subdirectories within it that CMake creates.
Running CMake

2
doc/src/Howto_coreshell.rst
View File

@ -111,7 +111,7 @@ Therefore it is typically desirable to decouple the relative motion of
the core/shell pair, which is an imaginary degree of freedom, from the
real physical system. To do that, the :doc:`compute temp/cs <compute_temp_cs>` command can be used, in conjunction with
any of the thermostat fixes, such as :doc:`fix nvt <fix_nh>` or :doc:`fix langevin <fix_langevin>`. This compute uses the center-of-mass velocity
of the core/shell pairs to calculate a temperature, and insures that
of the core/shell pairs to calculate a temperature, and ensures that
velocity is what is rescaled for thermostatting purposes. This
compute also works for a system with both core/shell pairs and
non-polarized ions (ions without an attached satellite particle). The

2
doc/src/Howto_github.rst
View File

@ -315,7 +315,7 @@ add changes. Please watch the comments to the pull requests. The two
"test" labels are used to trigger extended tests before the code is
merged. This is sometimes done by LAMMPS developers, if they suspect
that there may be some subtle side effects from your changes. It is not
done by default, because those tests are very time consuming. The
done by default, because those tests are very time-consuming. The
*ready_for_merge* label is usually attached when the LAMMPS developer
assigned to the pull request considers this request complete and to
trigger a final full test evaluation.

4
doc/src/Howto_grid.rst
View File

@ -11,7 +11,7 @@ more values (data).
The grid cells and data they store are distributed across processors.
Each processor owns the grid cells (and data) whose center points lie
within the spatial sub-domain of the processor. If needed for its
within the spatial subdomain of the processor. If needed for its
computations, a processor may also store ghost grid cells with their
data.
@ -28,7 +28,7 @@ box size, as set by the :doc:`boundary <boundary>` command for fixed
or shrink-wrapped boundaries.
If load-balancing is invoked by the :doc:`balance <balance>` or
:doc:`fix balance <fix_balance>` commands, then the sub-domain owned
:doc:`fix balance <fix_balance>` commands, then the subdomain owned
by a processor can change which may also change which grid cells they
own.

6
doc/src/Howto_output.rst
View File

@ -26,7 +26,7 @@ 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.
The following sub-sections discuss different LAMMPS commands related
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>`
@ -59,7 +59,7 @@ 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 sub-domain.
cells whose center point falls within its subdomain.
.. _scalar:
@ -322,7 +322,7 @@ The chief difference between the :doc:`fix ave/grid <fix_ave_grid>`
and :doc:`fix ave/chunk <fix_ave_chunk>` commands when used in this
context is that the former uses a distributed grid, while the latter
uses a global grid. Distributed means that each processor owns the
subset of grid cells within its sub-domain. Global means that each
subset of grid cells within its subdomain. Global means that each
processor owns a copy of the entire grid. The :doc:`fix ave/grid
<fix_ave_grid>` command is thus more efficient for large grids.

10
doc/src/Howto_peri.rst
View File

@ -783,19 +783,19 @@ Pitfalls
**Parallel Scalability**
LAMMPS operates in parallel in a :doc:`spatial-decomposition mode
<Developer_par_part>`, where each processor owns a spatial sub-domain of
<Developer_par_part>`, where each processor owns a spatial subdomain of
the overall simulation domain and communicates with its neighboring
processors via distributed-memory message passing (MPI) to acquire ghost
atom information to allow forces on the atoms it owns to be
computed. LAMMPS also uses Verlet neighbor lists which are recomputed
every few timesteps as particles move. On these timesteps, particles
also migrate to new processors as needed. LAMMPS decomposes the overall
simulation domain so that spatial sub-domains of nearly equal volume are
assigned to each processor. When each sub-domain contains nearly the
simulation domain so that spatial subdomains of nearly equal volume are
assigned to each processor. When each subdomain contains nearly the
same number of particles, this results in a reasonable load balance
among all processors. As is more typical with some peridynamic
simulations, some sub-domains may contain many particles while other
sub-domains contain few particles, resulting in a load imbalance that
simulations, some subdomains may contain many particles while other
subdomains contain few particles, resulting in a load imbalance that
impacts parallel scalability.
**Setting the "skin" distance**

2
doc/src/Howto_pylammps.rst
View File

@ -392,7 +392,7 @@ IPyLammps Examples
------------------
Examples of IPython notebooks can be found in the python/examples/pylammps
sub-directory. To open these notebooks launch *jupyter notebook* inside this
subdirectory. To open these notebooks launch *jupyter notebook* inside this
directory and navigate to one of them. If you compiled and installed
a LAMMPS shared library with exceptions, PNG, JPEG and FFMPEG support
you should be able to rerun all of these notebooks.

2
doc/src/Howto_spherical.rst
View File

@ -93,7 +93,7 @@ Some of the pair styles used to compute pairwise interactions between
finite-size particles also compute the correct interaction with point
particles as well, e.g. the interaction between a point particle and a
finite-size particle or between two point particles. If necessary,
:doc:`pair_style hybrid <pair_hybrid>` can be used to insure the correct
:doc:`pair_style hybrid <pair_hybrid>` can be used to ensure the correct
interactions are computed for the appropriate style of interactions.
Likewise, using groups to partition particles (ellipsoids versus
spheres versus point particles) will allow you to use the appropriate

2
doc/src/Howto_triclinic.rst
View File

@ -150,7 +150,7 @@ option with either of the commands.
Note that if a simulation box has a large tilt factor, LAMMPS will run
less efficiently, due to the large volume of communication needed to
acquire ghost atoms around a processor's irregular-shaped sub-domain.
acquire ghost atoms around a processor's irregular-shaped subdomain.
For extreme values of tilt, LAMMPS may also lose atoms and generate an
error.

70
doc/src/Install.rst
View File

@ -18,6 +18,8 @@ you **must** build LAMMPS from the source code.
developers have no control over their choices of how they configure
and build their packages and when they update them.
----
.. toctree::
:maxdepth: 1
@ -29,38 +31,40 @@ you **must** build LAMMPS from the source code.
Install_tarball
Install_git
These are the files and sub-directories in the LAMMPS distribution:
----
+------------+-------------------------------------------+
| README | Short description of the LAMMPS package |
+------------+-------------------------------------------+
| LICENSE | GNU General Public License (GPL) |
+------------+-------------------------------------------+
| SECURITY.md| Security Policy for the LAMMPS package |
+------------+-------------------------------------------+
| bench | benchmark problems |
+------------+-------------------------------------------+
| cmake | CMake build files |
+------------+-------------------------------------------+
| doc | documentation |
+------------+-------------------------------------------+
| examples | simple test problems |
+------------+-------------------------------------------+
| fortran | Fortran wrapper for LAMMPS |
+------------+-------------------------------------------+
| lib | additional provided or external libraries |
+------------+-------------------------------------------+
| potentials | interatomic potential files |
+------------+-------------------------------------------+
| python | Python wrappers for LAMMPS |
+------------+-------------------------------------------+
| src | source files |
+------------+-------------------------------------------+
| tools | pre- and post-processing tools |
+------------+-------------------------------------------+
| unittest | sources and inputs for testing LAMMPS |
+------------+-------------------------------------------+
These are the files and subdirectories in the LAMMPS distribution:
You will have all of these if you download source. You will only have
some of them if you download executables, as explained on the pages
listed above.
+------------+---------------------------------------------+
| README | Short description of the LAMMPS package |
+------------+---------------------------------------------+
| LICENSE | GNU General Public License (GPL) |
+------------+---------------------------------------------+
| SECURITY.md| Security policy for the LAMMPS package |
+------------+---------------------------------------------+
| bench | benchmark inputs |
+------------+---------------------------------------------+
| cmake | CMake build files |
+------------+---------------------------------------------+
| doc | documentation and tools to build the manual |
+------------+---------------------------------------------+
| examples | example input files |
+------------+---------------------------------------------+
| fortran | Fortran module for LAMMPS library interface |
+------------+---------------------------------------------+
| lib | additional provided or external libraries |
+------------+---------------------------------------------+
| potentials | selected interatomic potential files |
+------------+---------------------------------------------+
| python | Python module for LAMMPS library interface |
+------------+---------------------------------------------+
| src | LAMMPS source files |
+------------+---------------------------------------------+
| tools | pre- and post-processing tools |
+------------+---------------------------------------------+
| unittest | source code and inputs for testing LAMMPS |
+------------+---------------------------------------------+
You will have all of these if you downloaded the LAMMPS source code.
You will have only some of them if you downloaded executables, as
explained on the pages listed above.

18
doc/src/Install_conda.rst
View File

@ -1,10 +1,10 @@
Download an executable for Linux or Mac via Conda
-------------------------------------------------
Pre-compiled LAMMPS binaries are available for macOS or Linux via the
Pre-compiled LAMMPS binaries are available for macOS and Linux via the
`Conda <conda_>`_ package management system.
First, one must setup the Conda package manager on your system. Follow the
First, one must set up the Conda package manager on your system. Follow the
instructions to install `Miniconda <mini_conda_install_>`_, then create a conda
environment (named `my-lammps-env` or whatever you prefer) for your LAMMPS
install:
@ -21,19 +21,19 @@ Then, you can install LAMMPS on your system with the following command:
conda activate my-lammps-env
conda install lammps
The LAMMPS binary is built with the :ref:`KIM package <kim>` which
The LAMMPS binary is built with the :ref:`KIM package <kim>`, which
results in Conda also installing the `kim-api` binaries when LAMMPS is
installed. In order to use potentials from `openkim.org <openkim_>`_, you can
install the `openkim-models` package
installed. In order to use potentials from `openkim.org <openkim_>`_,
you can install the `openkim-models` package
.. code-block:: bash
conda install openkim-models
If you have problems with the installation you can post issues to
`this link <conda_forge_lammps_>`_.
Thanks to Jan Janssen (Max-Planck-Institut fuer Eisenforschung) for setting
up the Conda capability.
If you have problems with the installation, you can post issues to `this
link <conda_forge_lammps_>`_. Thanks to Jan Janssen
(Max-Planck-Institut fuer Eisenforschung) for setting up the Conda
capability.
.. _conda_forge_lammps: https://github.com/conda-forge/lammps-feedstock/issues
.. _openkim: https://openkim.org

42
doc/src/Install_git.rst
View File

@ -1,16 +1,16 @@
Download the LAMMPS source with git
-----------------------------------
All LAMMPS development is coordinated through the "LAMMPS GitHub
site". If you clone the LAMMPS repository onto your local machine, it
has several advantages:
LAMMPS development is coordinated through the "LAMMPS GitHub site".
If you clone the LAMMPS repository onto your local machine, it has
several advantages:
* You can stay current with changes to LAMMPS with a single git
command.
* You can create your own development branches to add code to LAMMPS.
* You can submit your new features back to GitHub for inclusion in
LAMMPS. For that you should first create your own :doc:`fork on
GitHub <Howto_github>`.
LAMMPS. For that, you should first create your own :doc:`fork on
GitHub <Howto_github>`, though.
You must have `git <git_>`_ installed on your system to use the
commands explained below to communicate with the git servers on
@ -31,8 +31,8 @@ You can follow the LAMMPS development on 3 different git branches:
* **stable** : this branch is updated from the *release* branch with
every stable release version and also has selected bug fixes and updates
back-ported from the *develop* branch
* **release** : this branch is updated with every patch release;
updates are always "fast forward" merges from *develop*
* **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
@ -58,12 +58,12 @@ between them at any time using "git checkout <branch name>".)
commit history (most people don't), you can speed up the "cloning"
process and reduce local disk space requirements by using the
*--depth* git command line flag. That will create a "shallow clone"
of the repository containing only a subset of the git history. Using
a depth of 1000 is usually sufficient to include the head commits of
the *develop* and the *release* branches. To include the head commit
of the *stable* branch you may need a depth of up to 10000. If you
later need more of the git history, you can always convert the
shallow clone into a "full clone".
of the repository, which contains only a subset of the git history.
Using a depth of 1000 is usually sufficient to include the head
commits of the *develop* and the *release* branches. To include the
head commit of the *stable* branch you may need a depth of up
to 10000. If you later need more of the git history, you can always
convert the shallow clone into a "full clone".
Once the command completes, your directory will contain the same files
as if you unpacked a current LAMMPS tarball, with the exception, that
@ -84,11 +84,11 @@ from within the "mylammps" directory:
git pull
Doing a "pull" will not change any files you have added to the LAMMPS
directory structure. It will also not change any existing LAMMPS
files you have edited, unless those files have changed in the
repository. In that case, git will attempt to merge the new
repository file with your version of the file and tell you if there
are any conflicts. See the git documentation for details.
directory structure. It will also not change any existing LAMMPS files
you have edited, unless those files have changed in the repository. In
that case, git will attempt to merge the changes from the repository
file with your version of the file and tell you if there are any
conflicts. See the git documentation for details.
If you want to access a particular previous release version of LAMMPS,
you can instead "check out" any version with a published tag. See the
@ -146,13 +146,13 @@ changed. How to do this depends on the build system you are using.
and package directories. This is OK to do even if you don't
use any packages. The ``make purge`` command removes any deprecated
src files if they were removed by the patch from a package
sub-directory.
subdirectory.
.. warning::
If you wish to edit/change a src file that is from a package,
you should edit the version of the file inside the package
sub-directory with src, then re-install the package. The
subdirectory with src, then re-install the package. The
version in the source directory is merely a copy and will be
wiped out if you type "make package-update".
@ -164,5 +164,5 @@ changed. How to do this depends on the build system you are using.
GitHub account, you may also use SSH protocol with the URL
"git@github.com:lammps/lammps.git".
The LAMMPS GitHub project is currently managed by Axel Kohlmeyer
The LAMMPS GitHub project is currently overseen by Axel Kohlmeyer
(Temple U, akohlmey at gmail.com).

101
doc/src/Install_linux.rst
View File

@ -3,7 +3,7 @@ Download an executable for Linux
Binaries are available for different versions of Linux:
- :ref:`Pre-built Ubuntu Linux executables <ubuntu>`
- :ref:`Pre-built Ubuntu and Debian Linux executables <ubuntu>`
- :ref:`Pre-built Fedora Linux executables <fedora>`
- :ref:`Pre-built EPEL Linux executables (RHEL, CentOS) <epel>`
- :ref:`Pre-built OpenSuse Linux executables <opensuse>`
@ -14,21 +14,23 @@ Binaries are available for different versions of Linux:
If you have questions about these pre-compiled LAMMPS executables,
you need to contact the people preparing those packages. The LAMMPS
developers have no control over their choices of how they configure
and build their packages and when they update them.
developers have no control over how they configure and build their
packages and when they update them. They may only provide packages
for stable release versions and not always update the packages in a
timely fashion after a new LAMMPS release is made.
----------
.. _ubuntu:
Pre-built Ubuntu Linux executables
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Pre-built Ubuntu and Debian Linux executables
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A pre-built LAMMPS executable suitable for running on the latest Ubuntu
Linux versions, can be downloaded as a Debian package. This allows you
to install LAMMPS with a single command, and stay (mostly) up-to-date
with the current stable version of LAMMPS by simply updating your
operating system.
A pre-built LAMMPS executable, suitable for running on the latest Ubuntu
and Debian Linux versions, can be downloaded as a Debian package. This
allows you to install LAMMPS with a single command, and stay (mostly)
up-to-date with the current stable version of LAMMPS by simply updating
your operating system.
To install LAMMPS do the following once:
@ -38,8 +40,22 @@ To install LAMMPS do the following once:
This downloads an executable named ``lmp`` to your box and multiple
packages with supporting data, examples and libraries as well as any
missing dependencies. This executable can then be used in the usual way
to run input scripts:
missing dependencies. For example, the LAMMPS binary in this package is
built with the :ref:`KIM package <kim>` enabled, which results in the
above command also installing the ``kim-api`` binaries when LAMMPS is
installed, unless they were installed already. In order to use
potentials from `openkim.org <openkim_>`_, you can also install the
``openkim-models`` package:
.. code-block:: bash
sudo apt-get install openkim-models
Or use the `KIM-API commands <https://openkim.org/doc/usage/obtaining-models/#installing_api>`_
to download and install individual models.
This LAMMPS executable can then be used in the usual way to run input
scripts:
.. code-block:: bash
@ -51,20 +67,9 @@ To update LAMMPS to the latest packaged version, do the following:
sudo apt-get update
which will also update other packages on your system.
This will also update other packages on your system.
The ``lmp`` binary is built with the :ref:`KIM package <kim>` included,
which results in the above command also installing the ``kim-api``
binaries when LAMMPS is installed. In order to use potentials from
`openkim.org <openkim_>`_, you can also install the ``openkim-models``
package
.. code-block:: bash
sudo apt-get install openkim-models
Or use the KIM-API commands to download and install individual models.
To un-install LAMMPS, do the following:
To uninstall LAMMPS, do the following:
.. code-block:: bash
@ -83,8 +88,9 @@ Ubuntu package capability.
Pre-built Fedora Linux executables
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Pre-built LAMMPS packages for stable releases are available in the
Fedora Linux distribution as of Fedora version 28. The packages can be
Pre-built `LAMMPS packages for stable releases
<https://packages.fedoraproject.org/pkgs/lammps/>`_ are available in the
Fedora Linux distribution since Fedora version 28. The packages can be
installed via the dnf package manager. There are 3 basic varieties
(lammps = no MPI, lammps-mpich = MPICH MPI library, lammps-openmpi =
OpenMPI MPI library) and for each support for linking to the C library
@ -107,9 +113,9 @@ To install LAMMPS with OpenMPI and run an input ``in.lj`` with 2 CPUs do:
module load mpi/openmpi-x86_64
mpirun -np 2 lmp -in in.lj
The ``dnf install`` command is needed only once. In case of a new LAMMPS
The ``dnf install`` command is needed only once. In case of a new LAMMPS
stable release, ``dnf update`` will automatically update to the newer
version as soon at the RPM files are built and uploaded to the download
version as soon as the RPM files are built and uploaded to the download
mirrors. The ``module load`` command is needed once per (shell) session
or shell terminal instance, unless it is automatically loaded from the
shell profile.
@ -165,7 +171,7 @@ in OpenSuse as of Leap 15.0. You can install the package with:
zypper install lammps
This includes support for OpenMPI. The name of the LAMMPS executable
is ``lmp``. Thus to run an input in parallel on 2 CPUs you would do:
is ``lmp``. To run an input in parallel on 2 CPUs you would do:
.. code-block:: bash
@ -192,17 +198,18 @@ Thanks to Christoph Junghans (LANL) for making LAMMPS available in OpenSuse.
Gentoo Linux executable
^^^^^^^^^^^^^^^^^^^^^^^
LAMMPS is part of Gentoo's main package tree and can be installed by
typing:
LAMMPS is part of `Gentoo's main package tree
<https://packages.gentoo.org/packages/sci-physics/lammps>`_ and can be
installed by typing:
.. code-block:: bash
emerge --ask lammps
Note that in Gentoo the LAMMPS source is downloaded and the package is
built on the your machine.
Note that in Gentoo the LAMMPS source code is downloaded and the package is
then compiled and installed on your machine.
Certain LAMMPS packages can be enable via USE flags, type
Certain LAMMPS packages can be enabled via USE flags, type
.. code-block:: bash
@ -221,8 +228,11 @@ Archlinux build-script
^^^^^^^^^^^^^^^^^^^^^^
LAMMPS is available via Arch's unofficial Arch User repository (AUR).
There are three scripts available, named lammps, lammps-beta and lammps-git.
They respectively package the stable, patch and git releases.
There are three scripts available, named `lammps
<https://aur.archlinux.org/packages/lammps>`_, `lammps-beta
<https://aur.archlinux.org/packages/lammps>`_ and `lammps-git
<https://aur.archlinux.org/packages/lammps>`_. They respectively
package the stable, patch and git releases.
To install, you will need to have the git package installed. You may use
any of the above names in-place of lammps.
@ -234,9 +244,9 @@ any of the above names in-place of lammps.
makepkg -s
makepkg -i
To update, you may repeat the above, or change into the cloned directory,
and execute the following, after which, if there are any changes, you may
use makepkg as above.
To update LAMMPS, you may repeat the above, or change into the cloned
directory, and execute the following, after which, if there are any
changes, you may use makepkg as above.
.. code-block:: bash
@ -244,12 +254,5 @@ use makepkg as above.
Alternatively, you may use an AUR helper to install these packages.
Note that the AUR provides build-scripts that download the source and
the build the package on your machine.
.. note::
It looks like the Arch Linux AUR repository build scripts for LAMMPS
have not been updated since the 29 October 2020 version. You may want
to consider installing a more current version of LAMMPS from source
directly.
Note that the AUR provides build-scripts that download the source code
and then build and install the package on your machine.

19
doc/src/Install_mac.rst
View File

@ -2,10 +2,11 @@ Download an executable for Mac
------------------------------
LAMMPS can be downloaded, built, and configured for OS X on a Mac with
`Homebrew <homebrew_>`_. (Alternatively, see the install instructions for
:doc:`Download an executable via Conda <Install_conda>`.) The following LAMMPS
packages are unavailable at this time because of additional needs not yet met:
GPU, KOKKOS, LATTE, MSCG, MPIIO, POEMS, VORONOI.
`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,
LATTE, MSCG, MPIIO, POEMS, VORONOI.
After installing Homebrew, you can install LAMMPS on your system with
the following commands:
@ -24,16 +25,16 @@ Lennard-Jones benchmark file:
brew test lammps -v
The LAMMPS binary is built with the :ref:`KIM package <kim>` which
results in Homebrew also installing the `kim-api` binaries when LAMMPS is
installed. In order to use potentials from `openkim.org <openkim_>`_, you can
install the `openkim-models` package
The LAMMPS binary is built with the :ref:`KIM package <kim>`, which
results in Homebrew also installing the `kim-api` binaries when LAMMPS
is installed. In order to use potentials from `openkim.org
<openkim_>`_, you can install the `openkim-models` package
.. code-block:: bash
brew install openkim-models
If you have problems with the installation you can post issues to
If you have problems with the installation, you can post issues to
`this link <https://github.com/Homebrew/homebrew-core/issues>`_.
.. _homebrew: https://brew.sh

19
doc/src/Install_tarball.rst
View File

@ -9,17 +9,19 @@ of the `LAMMPS website <lws_>`_.
.. _older: https://download.lammps.org/tars/
.. _lws: https://www.lammps.org
You have two choices of tarballs, either the most recent stable
release or the most current patch release. Stable releases occur a
few times per year, and undergo more testing before release. Patch
releases occur a couple times per month. The new contents in all
releases are listed on the `bug and feature page <bug_>`_ of the website.
You have two choices of tarballs, either the most recent stable release
or the most current patch or feature release. Stable releases occur a
few times per year, and undergo more testing before release. Feature
releases occur every 4 to 8 weeks. The new contents in all feature
releases are listed on the `bug and feature page <bug_>`_ of the LAMMPS
homepage.
Both tarballs include LAMMPS documentation (HTML and PDF files)
corresponding to that version. The download page also has an option
to download the current-version LAMMPS documentation by itself.
Older versions of LAMMPS can also be downloaded from `this page <older_>`_.
Tarballs of older LAMMPS versions can also be downloaded from `this page
<older_>`_.
Once you have a tarball, unzip and untar it with the following
command:
@ -36,14 +38,13 @@ in its name, e.g. lammps-23Jun18.
You can also download a compressed tar or zip archives from the
"Assets" sections of the `LAMMPS GitHub releases site <git_>`_.
The file name will be lammps-<version>.zip which can be unzipped
with the following command, to create a lammps-<version> dir:
with the following command, to create a lammps-<version> directory:
.. code-block:: bash
unzip lammps*.zip
This version corresponds to the selected LAMMPS patch or stable
release.
This version corresponds to the selected LAMMPS patch or stable release.
.. _git: https://github.com/lammps/lammps/releases

10
doc/src/Install_windows.rst
View File

@ -33,7 +33,7 @@ Windows, once it is installed, in both serial and parallel.
When you download the installer package, you run it on your Windows
machine. It will then prompt you with a dialog, where you can choose
the installation directory, unpack and copy several executables,
potential files, documentation pdfs, selected example files, etc. It
potential files, documentation PDFs, selected example files, etc. It
will then update a few system settings (e.g. PATH, LAMMPS_POTENTIALS)
and add an entry into the Start Menu (with references to the
documentation, LAMMPS homepage and more). From that menu, there is
@ -41,10 +41,10 @@ also a link to an uninstaller that removes the files and undoes the
environment manipulations.
Note that to update to a newer version of LAMMPS, you should typically
uninstall the version you currently have, download a new installer,
and go through the install procedure described above. I.e. the same
uninstall the version you currently have, download a new installer, and
go through the installation procedure described above. I.e. the same
procedure for installing/updating most Windows programs. You can
install multiple versions of LAMMPS (in different directories), but
only the executable for the last-installed package will be found
install multiple versions of LAMMPS (in different directories), but only
the executable for the last-installed package will be found
automatically, so this should only be done for debugging purposes.

1
doc/src/Intro.rst
View File

@ -10,6 +10,7 @@ These pages provide a brief introduction to LAMMPS.
Manual_version
Intro_features
Intro_nonfeatures
Intro_portability
Intro_opensource
Intro_authors
Intro_citing

6
doc/src/Intro_authors.rst
View File

@ -7,7 +7,7 @@ University:
* `Steve Plimpton <sjp_>`_, sjplimp at gmail.com
* Aidan Thompson, athomps at sandia.gov
* Stan Moore, stamoor at sandia.gov
* Axel Kohlmeyer, akohlmey at gmail.com
* `Axel Kohlmeyer <https://sites.google.com/site/akohlmey/>`_, akohlmey at gmail.com
* Richard Berger, richard.berger at outlook.com
.. _sjp: https://sjplimp.github.io
@ -37,10 +37,10 @@ general-purpose as it is without their expertise and efforts.
* Reese Jones (Sandia) and colleagues, ATC package for atom/continuum coupling
* Christoph Kloss (DCS Computing), LIGGGHTS code for granular materials, built on top of LAMMPS
* Rudra Mukherjee (JPL), POEMS package for articulated rigid body motion
* Trung Ngyuen (Northwestern U), GPU, RIGID, BODY, and DIELECTRIC packages
* Trung Ngyuen (U Chicago), GPU, RIGID, BODY, and DIELECTRIC packages
* Mike Parks (Sandia), PERI package for Peridynamics
* Roy Pollock (LLNL), Ewald and PPPM solvers
* Julien Tranchida (Sandia), SPIN package
* Julien Tranchida (CEA Cadarache), SPIN package
* Christian Trott (Sandia), CUDA and KOKKOS packages
* Ilya Valuev (JIHT), AWPMD package for wave packet MD
* Greg Wagner (Northwestern U), MEAM package for MEAM potential

10
doc/src/Intro_citing.rst
View File

@ -38,11 +38,11 @@ to create digital object identifiers (DOI) for stable releases of the
LAMMPS source code. There are two types of DOIs for the LAMMPS source code.
The canonical DOI for **all** versions of LAMMPS, which will always
point to the **latest** stable release version is:
point to the **latest** stable release version, is:
- DOI: `10.5281/zenodo.3726416 <https://dx.doi.org/10.5281/zenodo.3726416>`_
In addition there are DOIs for individual stable releases. Currently there are:
In addition there are DOIs generated for individual stable releases:
- 3 March 2020 version: `DOI:10.5281/zenodo.3726417 <https://dx.doi.org/10.5281/zenodo.3726417>`_
- 29 October 2020 version: `DOI:10.5281/zenodo.4157471 <https://dx.doi.org/10.5281/zenodo.4157471>`_
@ -65,6 +65,6 @@ for optional features used in a specific run is printed to the screen
and log file. Style and output location can be selected with the
:ref:`-cite command-line switch <cite>`. Additional references are
given in the documentation of the :doc:`corresponding commands
<Commands_all>` or in the :doc:`Howto tutorials <Howto>`. So please
make certain, that you provide the proper acknowledgments and citations
in any published works using LAMMPS.
<Commands_all>` or in the :doc:`Howto tutorials <Howto>`. Please make
certain, that you provide the proper acknowledgments and citations in
any published works using LAMMPS.

54
doc/src/Intro_features.rst
View File

@ -27,7 +27,7 @@ General features
* distributed memory message-passing parallelism (MPI)
* shared memory multi-threading parallelism (OpenMP)
* spatial decomposition of simulation domain for MPI parallelism
* particle decomposition inside of spatial decomposition for OpenMP and GPU parallelism
* particle decomposition inside spatial decomposition for OpenMP and GPU parallelism
* GPLv2 licensed open-source distribution
* highly portable C++-11
* modular code with most functionality in optional packages
@ -39,8 +39,11 @@ General features
* syntax for defining and using variables and formulas
* syntax for looping over runs and breaking out of loops
* run one or multiple simulations simultaneously (in parallel) from one script
* build as library, invoke LAMMPS through library interface or provided Python wrapper or SWIG based wrappers
* couple with other codes: LAMMPS calls other code, other code calls LAMMPS, umbrella code calls both
* build as library, invoke LAMMPS through library interface (from C, C++, Fortran) or provided Python wrapper or SWIG based wrappers
* couple with other codes: LAMMPS calls other code, other code calls LAMMPS, umbrella code calls both, MDI coupling interface
* call out to Python for computing forces, time integration, or other tasks
* plugin interface for loading external features at runtime
* large integrated collection of tests
.. _particle:
@ -54,6 +57,7 @@ Particle and model types
* united-atom polymers or organic molecules
* all-atom polymers, organic molecules, proteins, DNA
* metals
* metal oxides
* granular materials
* coarse-grained mesoscale models
* finite-size spherical and ellipsoidal particles
@ -74,27 +78,28 @@ Interatomic potentials (force fields)
:doc:`improper style <improper_style>`, :doc:`kspace style <kspace_style>`
commands)
* pairwise potentials: Lennard-Jones, Buckingham, Morse, Born-Mayer-Huggins, Yukawa, soft, class 2 (COMPASS), hydrogen bond, tabulated
* pairwise potentials: Lennard-Jones, Buckingham, Morse, Born-Mayer-Huggins, Yukawa, soft, Class II (COMPASS), hydrogen bond, harmonic, gaussian, tabulated, scripted
* charged pairwise potentials: Coulombic, point-dipole
* many-body potentials: EAM, Finnis/Sinclair EAM, modified EAM (MEAM), embedded ion method (EIM), EDIP, ADP, Stillinger-Weber, Tersoff, REBO, AIREBO, ReaxFF, COMB, Streitz-Mintmire, 3-body polymorphic, BOP, Vashishta
* machine learning potentials: SNAP, GAP, ACE, N2P2, RANN, AGNI
* long-range interactions for charge, point-dipoles, and LJ dispersion: Ewald, Wolf, PPPM (similar to particle-mesh Ewald), MSM
* polarization models: :doc:`QEq <fix_qeq>`, :doc:`core/shell model <Howto_coreshell>`, :doc:`Drude dipole model <Howto_drude>`
* many-body potentials: EAM, Finnis/Sinclair, MEAM, MEAM+SW, EIM, EDIP, ADP, Stillinger-Weber, Tersoff, REBO, AIREBO, ReaxFF, COMB, Streitz-Mintmire, 3-body polymorphic, BOP, Vashishta
* machine learning potentials: ACE, AGNI, GAP, Behler-Parrinello (N2P2), POD, RANN
* interfaces to ML potentials distributed by external groups: ANI, ChIMES, DeepPot, HIPNN, MTP
* long-range interactions for charge, point-dipoles, and LJ dispersion: Ewald, Wolf, PPPM (similar to particle-mesh Ewald), MSM, ScaFaCoS
* polarization models: :doc:`QEq <fix_qeq>`, :doc:`core/shell model <Howto_coreshell>`, :doc:`Drude dipole model <Howto_drude>`
* charge equilibration (QEq via dynamic, point, shielded, Slater methods)
* coarse-grained potentials: DPD, GayBerne, REsquared, colloidal, DLVO
* coarse-grained potentials: DPD, GayBerne, REsquared, colloidal, DLVO, oxDNA / oxRNA, SPICA
* mesoscopic potentials: granular, Peridynamics, SPH, mesoscopic tubular potential (MESONT)
* semi-empirical potentials: multi-ion generalized pseudopotential theory (MGPT), second moment tight binding + QEq (SMTB-Q), density functional tight-binding (LATTE)
* electron force field (eFF, AWPMD)
* bond potentials: harmonic, FENE, Morse, nonlinear, class 2, quartic (breakable), tabulated
* angle potentials: harmonic, CHARMM, cosine, cosine/squared, cosine/periodic, class 2 (COMPASS), tabulated
* dihedral potentials: harmonic, CHARMM, multi-harmonic, helix, class 2 (COMPASS), OPLS, tabulated
* improper potentials: harmonic, cvff, umbrella, class 2 (COMPASS), tabulated
* bond potentials: harmonic, FENE, Morse, nonlinear, Class II (COMPASS), quartic (breakable), tabulated, scripted
* angle potentials: harmonic, CHARMM, cosine, cosine/squared, cosine/periodic, Class II (COMPASS), tabulated, scripted
* dihedral potentials: harmonic, CHARMM, multi-harmonic, helix, Class II (COMPASS), OPLS, tabulated, scripted
* improper potentials: harmonic, cvff, umbrella, Class II (COMPASS), tabulated
* polymer potentials: all-atom, united-atom, bead-spring, breakable
* water potentials: TIP3P, TIP4P, SPC, SPC/E and variants
* interlayer potentials for graphene and analogues
* interlayer potentials for graphene and analogues, hetero-junctions
* metal-organic framework potentials (QuickFF, MO-FF)
* implicit solvent potentials: hydrodynamic lubrication, Debye
* force-field compatibility with common CHARMM, AMBER, DREIDING, OPLS, GROMACS, COMPASS options
* force-field compatibility with CHARMM, AMBER, DREIDING, OPLS, GROMACS, Class II (COMPASS), UFF, ClayFF, DREIDING, AMOEBA, INTERFACE
* access to the `OpenKIM Repository <https://openkim.org>`_ of potentials via the :doc:`kim command <kim_commands>`
* hybrid potentials: multiple pair, bond, angle, dihedral, improper potentials can be used in one simulation
* overlaid potentials: superposition of multiple pair potentials (including many-body) with optional scale factor
@ -108,7 +113,7 @@ Atom creation
:doc:`create_atoms <create_atoms>`, :doc:`delete_atoms <delete_atoms>`,
:doc:`displace_atoms <displace_atoms>`, :doc:`replicate <replicate>` commands)
* read in atom coords from files
* read in atom coordinates from files
* create atoms on one or more lattices (e.g. grain boundaries)
* delete geometric or logical groups of atoms (e.g. voids)
* replicate existing atoms multiple times
@ -129,7 +134,7 @@ Ensembles, constraints, and boundary conditions
* simulation box deformation (tensile and shear)
* harmonic (umbrella) constraint forces
* rigid body constraints
* SHAKE bond and angle constraints
* SHAKE / RATTLE bond and angle constraints
* motion constraints to manifold surfaces
* Monte Carlo bond breaking, formation, swapping, template based reaction modeling
* atom/molecule insertion and deletion
@ -147,8 +152,9 @@ Integrators
* velocity-Verlet integrator
* Brownian dynamics
* rigid body integration
* energy minimization via conjugate gradient or steepest descent relaxation
* energy minimization via conjugate gradient, steepest descent relaxation, or damped dynamics (FIRE, Quickmin)
* rRESPA hierarchical timestepping
* fixed or adaptive time step
* rerun command for post-processing of dump files
.. _diag:
@ -167,15 +173,17 @@ Output
(:doc:`dump <dump>`, :doc:`restart <restart>` commands)
* log file of thermodynamic info
* text dump files of atom coords, velocities, other per-atom quantities
* text dump files of atom coordinates, velocities, other per-atom quantities
* dump output on fixed and variable intervals, based timestep or simulated time
* binary restart files
* parallel I/O of dump and restart files
* per-atom quantities (energy, stress, centro-symmetry parameter, CNA, etc)
* per-atom quantities (energy, stress, centro-symmetry parameter, CNA, etc.)
* user-defined system-wide (log file) or per-atom (dump file) calculations
* custom partitioning (chunks) for binning, and static or dynamic grouping of atoms for analysis
* spatial, time, and per-chunk averaging of per-atom quantities
* time averaging and histogramming of system-wide quantities
* atom snapshots in native, XYZ, XTC, DCD, CFG formats
* atom snapshots in native, XYZ, XTC, DCD, CFG, NetCDF, HDF5, ADIOS2, YAML formats
* on-the-fly compression of output and decompression of read in files
.. _replica1:
@ -212,8 +220,8 @@ Pre- and post-processing
Specialized features
^^^^^^^^^^^^^^^^^^^^
LAMMPS can be built with optional packages which implement a variety
of additional capabilities. See the :doc:`Optional Packages <Packages>`
LAMMPS can be built with optional packages which implement a variety of
additional capabilities. See the :doc:`Optional Packages <Packages>`
page for details.
These are LAMMPS capabilities which you may not think of as typical

78
doc/src/Intro_nonfeatures.rst
View File

@ -20,22 +20,23 @@ that either closely interface with LAMMPS or extend LAMMPS.
Here are suggestions on how to perform these tasks:
* **GUI:** LAMMPS can be built as a library and a Python wrapper that wraps
the library interface is provided. Thus, GUI interfaces can be
written in Python (or C or C++ if desired) 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.
* **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 them
are simple programs that will build simple molecular systems, such as
linear bead-spring polymer chains. The moltemplate program is a true
molecular builder that will generate complex molecular models. See
the :doc:`Tools <Tools>` page for details on tools packaged with
LAMMPS. The `Pre/post processing page <https:/www.lammps.org/prepost.html>`_ of the LAMMPS website
* **GUI:** LAMMPS can be built as a library and a Python module that
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.
* **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
them are simple programs that will build simple molecular systems,
such as linear bead-spring polymer chains. The moltemplate program is
a true molecular builder that will generate complex molecular models.
See the :doc:`Tools <Tools>` page for details on tools packaged with
LAMMPS. The `Pre-/post-processing page
<https:/www.lammps.org/prepost.html>`_ of the LAMMPS homepage
describes a variety of third party tools for this task. Furthermore,
some LAMMPS internal commands allow to reconstruct, or selectively add
some internal LAMMPS commands allow reconstructing, or selectively adding
topology information, as well as provide the option to insert molecule
templates instead of atoms for building bulk molecular systems.
* **Force-field assignment:** The conversion tools described in the previous
@ -47,33 +48,34 @@ Here are suggestions on how to perform these tasks:
powerful and flexible in converting force field and topology data
between various MD simulation programs.
* **Simulation analysis:** If you want to perform analysis on-the-fly as
your simulation runs, see the :doc:`compute <compute>` and
:doc:`fix <fix>` doc pages, which list commands that can be used in a
LAMMPS input script. Also see the :doc:`Modify <Modify>` page for
info on how to add your own analysis code or algorithms to LAMMPS.
For post-processing, LAMMPS output such as :doc:`dump file snapshots <dump>` can be converted into formats used by other MD or
your simulation runs, see the :doc:`compute <compute>` and :doc:`fix
<fix>` doc pages, which list commands that can be used in a LAMMPS
input script. Also see the :doc:`Modify <Modify>` page for info on
how to add your own analysis code or algorithms to LAMMPS. For
post-processing, LAMMPS output such as :doc:`dump file snapshots
<dump>` can be converted into formats used by other MD or
post-processing codes. To some degree, that conversion can be done
directly inside of LAMMPS by interfacing to the VMD molfile plugins.
The :doc:`rerun <rerun>` command also allows to do some post-processing
of existing trajectories, and through being able to read a variety
of file formats, this can also be used for analyzing trajectories
from other MD codes. Some post-processing tools packaged with
LAMMPS will do these conversions. Scripts provided in the
tools/python directory can extract and massage data in dump files to
make it easier to import into other programs. See the
:doc:`Tools <Tools>` page for details on these various options.
* **Visualization:** LAMMPS can produce NETPBM, JPG or PNG snapshot images
on-the-fly via its :doc:`dump image <dump_image>` command and pass
them to an external program, `FFmpeg <https://www.ffmpeg.org>`_ to generate
movies from them. For high-quality, interactive visualization there are
many excellent and free tools available. See the
`Visualization Tools <https://www.lammps.org/viz.html>`_ page of the
LAMMPS website for
directly inside LAMMPS by interfacing to the VMD molfile plugins. The
:doc:`rerun <rerun>` command also allows post-processing of existing
trajectories, and through being able to read a variety of file
formats, this can also be used for analyzing trajectories from other
MD codes. Some post-processing tools packaged with LAMMPS will do
these conversions. Scripts provided in the tools/python directory can
extract and massage data in dump files to make it easier to import
into other programs. See the :doc:`Tools <Tools>` page for details on
these various options.
* **Visualization:** LAMMPS can produce NETPBM, JPG, or PNG format
snapshot images on-the-fly via its :doc:`dump image <dump_image>`
command and pass them to an external program, `FFmpeg
<https://www.ffmpeg.org>`_, to generate movies from them. For
high-quality, interactive visualization, there are many excellent and
free tools available. See the `Visualization Tools
<https://www.lammps.org/viz.html>`_ page of the LAMMPS website for
visualization packages that can process LAMMPS output data.
* **Plotting:** See the next bullet about Pizza.py as well as the
:doc:`Python <Python_head>` page for examples of plotting LAMMPS
output. Scripts provided with the *python* tool in the tools
directory will extract and massage data in log and dump files to make
output. Scripts provided with the *python* tool in the ``tools``
directory will extract and process data in log and dump files to make
it easier to analyze and plot. See the :doc:`Tools <Tools>` doc page
for more discussion of the various tools.
* **Pizza.py:** Our group has also written a separate toolkit called

55
doc/src/Intro_overview.rst
View File

@ -1,20 +1,20 @@
Overview of LAMMPS
------------------
LAMMPS is a classical molecular dynamics (MD) code that models
ensembles of particles in a liquid, solid, or gaseous state. It can
model atomic, polymeric, biological, solid-state (metals, ceramics,
oxides), granular, coarse-grained, or macroscopic systems using a
variety of interatomic potentials (force fields) and boundary
conditions. It can model 2d or 3d systems with only a few particles
up to millions or billions.
LAMMPS is a classical molecular dynamics (MD) code that models ensembles
of particles in a liquid, solid, or gaseous state. It can model atomic,
polymeric, biological, solid-state (metals, ceramics, oxides), granular,
coarse-grained, or macroscopic systems using a variety of interatomic
potentials (force fields) and boundary conditions. It can model 2d or
3d systems with sizes ranging from only a few particles up to billions.
LAMMPS can be built and run on a laptop or desktop machine, but is
LAMMPS can be built and run on single laptop or desktop machines, but is
designed for parallel computers. It will run in serial and on any
parallel machine that supports the `MPI <mpi_>`_ message-passing
library. This includes shared-memory boxes and distributed-memory
clusters and supercomputers. Parts of LAMMPS also support
`OpenMP multi-threading <omp_>`_, vectorization and GPU acceleration.
library. This includes shared-memory multicore, multi-CPU servers and
distributed-memory clusters and supercomputers. Parts of LAMMPS also
support `OpenMP multi-threading <omp_>`_, vectorization, and GPU
acceleration.
.. _mpi: https://en.wikipedia.org/wiki/Message_Passing_Interface
.. _lws: https://www.lammps.org
@ -29,25 +29,24 @@ versions can be downloaded as source code from the `LAMMPS website
LAMMPS is designed to be easy to modify or extend with new capabilities,
such as new force fields, atom types, boundary conditions, or
diagnostics. See the :doc:`Modify <Modify>` page for more details.
diagnostics. See the :doc:`Modify` section of for more details.
In the most general sense, LAMMPS integrates Newton's equations of
motion for a collection of interacting particles. A single particle
can be an atom or molecule or electron, a coarse-grained cluster of
atoms, or a mesoscopic or macroscopic clump of material. The
interaction models that LAMMPS includes are mostly short-range in
nature; some long-range models are included as well.
motion for a collection of interacting particles. A single particle can
be an atom or molecule or electron, a coarse-grained cluster of atoms,
or a mesoscopic or macroscopic clump of material. The interaction
models that LAMMPS includes are mostly short-ranged in nature; some
long-range models are included as well.
LAMMPS uses neighbor lists to keep track of nearby particles. The
lists are optimized for systems with particles that are repulsive at
short distances, so that the local density of particles never becomes
too large. This is in contrast to methods used for modeling plasma
or gravitational bodies (e.g. galaxy formation).
LAMMPS uses neighbor lists to keep track of nearby particles. The lists
are optimized for systems with particles that are repulsive at short
distances, so that the local density of particles never becomes too
large. This is in contrast to methods used for modeling plasma or
gravitational bodies (like galaxy formation).
On parallel machines, LAMMPS uses spatial-decomposition techniques with
MPI parallelization to partition the simulation domain into small
sub-domains of equal computational cost, one of which is assigned to
each processor. Processors communicate and store "ghost" atom
information for atoms that border their sub-domain. Multi-threading
parallelization and GPU acceleration with with particle-decomposition
can be used in addition.
MPI parallelization to partition the simulation domain into subdomains
of equal computational cost, one of which is assigned to each processor.
Processors communicate and store "ghost" atom information for atoms that
border their subdomain. Multi-threading parallelization and GPU
acceleration with particle-decomposition can be used in addition.

75
doc/src/Intro_portability.rst Normal file
View File

@ -0,0 +1,75 @@
LAMMPS portability and compatibility
------------------------------------
The primary form of distributing LAMMPS is through highly portable
source code. But also several ways of obtaining LAMMPS as `precompiled
packages or through automated build mechanisms <Install>` exist. Most
of LAMMPS is written in C++, some support tools are written in Fortran
or Python or MATLAB.
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
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.
Build systems
^^^^^^^^^^^^^
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.
Operating systems
^^^^^^^^^^^^^^^^^
The primary development platform for LAMMPS is Linux. Thus, the chances
for LAMMPS to compile without problems on Linux machines are the best.
Also, compilation and correct execution on macOS and Windows (using
Microsoft Visual C++) is checked automatically for largest part of the
source code. Some (optional) features are not compatible with all
operating systems, either through limitations of the corresponding
LAMMPS source code or through source code or build system
incompatibilities of required libraries.
Executables for Windows may be created natively using either Cygwin or
Visual Studio or with a Linux to Windows MinGW cross-compiler.
Additionally, FreeBSD and Solaris have been tested successfully.
Compilers
^^^^^^^^^
The most commonly used compilers are the GNU compilers, but also Clang
and the Intel compilers have been successfully used on Linux, macOS, and
Windows. Also, the Nvidia HPC SDK (formerly PGI compilers) will compile
LAMMPS (tested on Linux).
CPU architectures
^^^^^^^^^^^^^^^^^
The primary CPU architecture for running LAMMPS is 64-bit x86, but also
32-bit x86, and 64-bit ARM and PowerPC (64-bit, Little Endian) are
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.
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
to compile, link, and pass some runtime tests on a selection of Linux
flavors, macOS, and Windows, and on Linux with different compilers.
Thus portability issues are often found before a pull request is merged.
Other platforms may be checked occasionally or when portability bugs are
reported.

11
doc/src/Intro_website.rst
View File

@ -7,20 +7,15 @@ available online are listed below.
.. _lws: https://www.lammps.org
* `Brief intro and recently added significant features <lws_>`_
* `List of features <https://docs.lammps.org/Intro_features.html>`_
* `List of non-features <https://docs.lammps.org/Intro_nonfeatures.html>`_
* `Recent bug fixes and new features <https://www.lammps.org/bug.html>`_
* `LAMMPS source code repository on GitHub <https://github.com/lammps/lammps>`_
* `LAMMPS forum on matsci.org <https://matsci.org/lammps/>`_
* `Recent bug fixes and new features <https://www.lammps.org/bug.html>`_
* `Download info <https://www.lammps.org/download.html>`_
* `GitHub site <https://github.com/lammps/lammps>`_
* `SourceForge site <https://sourceforge.net/projects/lammps>`_
* `LAMMPS open-source license <https://docs.lammps.org/Intro_opensource.html>`_
* `Glossary of terms relevant to LAMMPS <https://www.lammps.org/glossary.html>`_
* `LAMMPS highlights with images <https://www.lammps.org/pictures.html>`_
* `LAMMPS highlights with movies <https://www.lammps.org/movies.html>`_
* `LAMMPS forum <https://www.lammps.org/forum.html>`_
* `Workshops <https://www.lammps.org/workshops.html>`_
* `Tutorials <https://www.lammps.org/tutorials.html>`_

6
doc/src/Library_properties.rst
View File

@ -16,8 +16,8 @@ This section documents the following functions:
--------------------
The library interface allows the extraction of different kinds of
information about the active simulation instance and also---in some
cases---to apply modifications to it. This enables combining of a
information about the active simulation instance and also - in some
cases - to apply modifications to it. This enables combining of a
LAMMPS simulation with other processing and simulation methods computed
by the calling code, or by another code that is coupled to LAMMPS via
the library interface. In some cases the data returned is direct
@ -30,7 +30,7 @@ course, changing values should be done with care. When accessing per-atom
data, please note that these data are the per-processor **local** data and are
indexed accordingly. Per-atom data can change sizes and ordering at
every neighbor list rebuild or atom sort event as atoms migrate between
sub-domains and processors.
subdomains and processors.
.. code-block:: c

53
doc/src/Manual.rst
View File

@ -5,16 +5,17 @@ LAMMPS Documentation (|version| version)
LAMMPS stands for **L**\ arge-scale **A**\ tomic/**M**\ olecular
**M**\ assively **P**\ arallel **S**\ imulator.
LAMMPS is a classical molecular dynamics simulation code with a focus
on materials modeling. It was designed to run efficiently on parallel
computers. It was developed originally at Sandia National
Laboratories, a US Department of Energy facility. The majority of
funding for LAMMPS has come from the US Department of Energy (DOE).
LAMMPS is an open-source code, distributed freely under the terms of
the GNU Public License Version 2 (GPLv2).
LAMMPS is a classical molecular dynamics simulation code focusing on
materials modeling. It was designed to run efficiently on parallel
computers and to be easy to extend and modify. Originally developed at
Sandia National Laboratories, a US Department of Energy facility, LAMMPS
now includes contributions from many research groups and individuals
from many institutions. Most of the funding for LAMMPS has come from
the US Department of Energy (DOE). LAMMPS is open-source software
distributed under the terms of the GNU Public License Version 2 (GPLv2).
The `LAMMPS website <lws_>`_ has a variety of information about the
code. It includes links to an on-line version of this manual, an
code. It includes links to an online version of this manual, an
`online forum <https://www.lammps.org/forum.html>`_ where users can post
questions and discuss LAMMPS, and a `GitHub site
<https://github.com/lammps/lammps>`_ where all LAMMPS development is
@ -23,27 +24,33 @@ coordinated.
----------
The content for this manual is part of the LAMMPS distribution. The
online version always corresponds to the latest development version.
If needed, you can download or 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 have difficulties viewing the pages
please :ref:`see this note <webbrowser>`.
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
have difficulties viewing the pages, please :ref:`see this note
<webbrowser>`.
-----------
The manual is organized in three parts:
1) the :ref:`User Guide <user_documentation>` for how to install
and use LAMMPS, 2) the :ref:`Programmer Guide <programmer_documentation>`
for how to write programs using the LAMMPS library from different
programming languages and how to modify and extend LAMMPS, and 3) the
:ref:`Command Reference <command_reference>` which includes detailed
descriptions of all commands included in the LAMMPS code.
The manual is organized into three parts:
1. The :ref:`User Guide <user_documentation>` with information about how
to obtain, configure, compile, install, and use LAMMPS,
2. the :ref:`Programmer Guide <programmer_documentation>` with
information about how to use the LAMMPS library interface from
different programming languages, how to modify and extend LAMMPS,
the program design, internal programming interfaces, and code
design conventions,
3. the :ref:`Command Reference <command_reference>` with detailed
descriptions of all input script commands available in LAMMPS.
----------
.. only:: html
Once you are familiar with LAMMPS, you may want to bookmark
:doc:`this page <Commands_all>` since it gives quick access to
the documentation for all LAMMPS commands.
After becoming familiar with LAMMPS, consider bookmarking
:doc:`this page <Commands_all>`, since it gives quick access to
tables with links to the documentation for all LAMMPS commands.
.. _lws: https://www.lammps.org

67
doc/src/Manual_version.rst
View File

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

8
doc/src/Modify_overview.rst
View File

@ -59,14 +59,6 @@ the executable and can be invoked with a pair_style command like the
example above. Arguments like 0.1 and 3.5 can be defined and
processed by your new class.
.. note::
With the traditional make process, simply adding the new files to the
src folder and compiling LAMMPS again for the desired configuration
with "make machine" is sufficient. When using CMake, you need to
re-run CMake with "cmake ." in the build folder to have it recognize
the added files and include them into the build system.
As illustrated by this example pair style, many kinds of options are
referred to in the LAMMPS documentation as the "style" of a particular
command.

2
doc/src/Packages.rst
View File

@ -8,7 +8,7 @@ systems or rigid-body constraints are in packages. You can see the
list of all packages and "make" commands to manage them by typing
"make package" from within the src directory of the LAMMPS
distribution. The :doc:`Build package <Build_package>` page gives
general info on how to install and un-install packages as part of the
general info on how to install and uninstall packages as part of the
LAMMPS build process.
.. toctree::

38
doc/src/Packages_details.rst
View File

@ -883,6 +883,8 @@ This package has :ref:`specific installation instructions <electrode>` on the
**Supporting info:**
* :doc:`fix electrode/conp <fix_electrode>`
* :doc:`fix electrode/conq <fix_electrode>`
* :doc:`fix electrode/thermo <fix_electrode>`
----------
@ -1619,25 +1621,23 @@ MESONT package
**Contents:**
MESONT is a LAMMPS package for simulation of nanomechanics of nanotubes
(NTs). The model is based on a coarse-grained representation of NTs as
(NTs). The model is based on a coarse-grained representation of NTs as
"flexible cylinders" consisting of a variable number of
segments. Internal interactions within a NT and the van der Waals
interaction between the tubes are described by a mesoscopic force field
designed and parameterized based on the results of atomic-level
molecular dynamics simulations. The description of the force field is
provided in the papers listed below.
provided in the papers listed in ``src/MESONT/README``.
This package contains two independent implementations of this model:
:doc:`pair_style mesont/tpm <pair_mesont_tpm>` is the original
implementation of the model based on a Fortran library in the
``lib/mesont`` folder. The second implementation is provided by the
mesocnt styles (:doc:`bond_style mesocnt <bond_mesocnt>`,
:doc:`angle_style mesocnt <angle_mesocnt>` and :doc:`pair_style mesocnt
<pair_mesocnt>`). The mesocnt implementation has the same features as
the original implementation with the addition of friction, but is
directly implemented in C++, interfaces more cleanly with general LAMMPS
functionality, and is typically faster. It also does not require its own
atom style and can be installed without any external libraries.
This package used to have two independent implementations of this model:
the original implementation using a Fortran library written by the
developers of the model and a second implementation written in C++ by
Philipp Kloza (U Cambridge). Since the C++ implementation offers the
same features as the original implementation with the addition of
friction, is typically faster, and easier to compile/install, the
Fortran library based implementation has since been obsoleted and
removed from the distribution. You have to download and compile
an older version of LAMMPS if you want to use those.
**Download of potential files:**
@ -1646,12 +1646,14 @@ not included in the regular downloaded packages of LAMMPS or the git
repositories. Instead, they will be automatically downloaded from a web
server when the package is installed for the first time.
**Authors of the *mesont* styles:**
**Authors of the obsoleted *mesont* styles:**
Maxim V. Shugaev (University of Virginia), Alexey N. Volkov (University
of Alabama), Leonid V. Zhigilei (University of Virginia)
**Author of the *mesocnt* styles:**
.. deprecated:: TBD
**Author of the C++ styles:**
Philipp Kloza (U Cambridge)
.. versionadded:: 15Jun2020
@ -1660,14 +1662,10 @@ Philipp Kloza (U Cambridge)
* src/MESONT: filenames -> commands
* src/MESONT/README
* :doc:`atom_style mesont <atom_style>`
* :doc:`pair_style mesont/tpm <pair_mesont_tpm>`
* :doc:`compute mesont <compute_mesont>`
* :doc:`bond_style mesocnt <bond_mesocnt>`
* :doc:`angle_style mesocnt <angle_mesocnt>`
* :doc:`pair_style mesocnt <pair_mesocnt>`
* examples/PACKAGES/mesont
* tools/mesont
----------
@ -2208,7 +2206,7 @@ packages, which have styles optimized for CPUs.
See src/MAKE/OPTIONS/Makefile.omp for an example.
Once you have an appropriate Makefile.machine, you can
install/un-install the package and build LAMMPS in the usual manner:
install/uninstall the package and build LAMMPS in the usual manner:
**Install:**

6
doc/src/Packages_list.rst
View File

@ -8,7 +8,7 @@ Packages are supported by either the LAMMPS developers or the
contributing authors and written in a syntax and style consistent with
the rest of LAMMPS.
The "Examples" column is a sub-directory in the examples directory of the
The "Examples" column is a subdirectory in the examples directory of the
distribution which has one or more input scripts that use the package.
E.g. "peptide" refers to the examples/peptide directory; PACKAGES/atc refers
to the examples/PACKAGES/atc directory. The "Lib" column indicates
@ -275,9 +275,9 @@ whether an extra library is needed to build and use the package:
- no
* - :ref:`MESONT <PKG-MESONT>`
- mesoscopic tubular potential model
- pair styles :doc:`mesont/tpm <pair_mesont_tpm>`, :doc:`mesocnt <pair_mesocnt>`
- pair styles :doc:`mesocnt <pair_mesocnt>`
- PACKAGES/mesont
- int
- no
* - :ref:`MGPT <PKG-MGPT>`
- fast MGPT multi-ion potentials
- :doc:`pair_style mgpt <pair_mgpt>`

2
doc/src/Python_atoms.rst
View File

@ -23,7 +23,7 @@ against invalid accesses.
When accessing per-atom data,
please note that this data is the per-processor local data and indexed
accordingly. These arrays can change sizes and order at every neighbor list
rebuild and atom sort event as atoms are migrating between sub-domains.
rebuild and atom sort event as atoms are migrating between subdomains.
.. tabs::

2
doc/src/Python_examples.rst
View File

@ -33,7 +33,7 @@ with ``gl`` or ``atomeye`` or ``pymol`` or ``vmd``, depending on what
visualization package you have installed.
Note that for GL, you need to be able to run the Pizza.py GL tool,
which is included in the pizza sub-directory. See the Pizza.py doc pages for more info:
which is included in the pizza subdirectory. See the Pizza.py doc pages for more info:
* `https://lammps.github.io/pizza <pizza_>`_

2
doc/src/Python_launch.rst
View File

@ -70,7 +70,7 @@ single processor outputs, mpi4py is not working correctly.
Also note that once you import the mpi4py module, mpi4py initializes MPI
for you, and you can use MPI calls directly in your Python script, as
described in the mpi4py documentation. The last line of your Python
script should be ``MPI.finalize()``, to insure MPI is shut down
script should be ``MPI.finalize()``, to ensure MPI is shut down
correctly.

2
doc/src/Python_properties.rst
View File

@ -23,7 +23,7 @@ against invalid accesses.
When accessing per-atom data,
please note that this data is the per-processor local data and indexed
accordingly. These arrays can change sizes and order at every neighbor list
rebuild and atom sort event as atoms are migrating between sub-domains.
rebuild and atom sort event as atoms are migrating between subdomains.
.. tabs::

30
doc/src/Run_options.rst
View File

@ -105,13 +105,12 @@ Either the full word or an abbreviation can be used for the keywords.
Note that the keywords do not use a leading minus sign. I.e. the
keyword is "t", not "-t". Also note that each of the keywords has a
default setting. Examples of when to use these options and what
settings to use on different platforms is given on the :doc:`KOKKOS package <Speed_kokkos>`
doc page.
settings to use on different platforms is given on the :doc:`KOKKOS
package <Speed_kokkos>` doc page.
* d or device
* g or gpus
* t or threads
* n or numa
.. parsed-literal::
@ -164,19 +163,10 @@ the number of physical cores per node, to use your available hardware
optimally. This also sets the number of threads used by the host when
LAMMPS is compiled with CUDA=yes.
.. parsed-literal::
.. deprecated:: 22Dec2022
numa Nm
This option is only relevant when using pthreads with hwloc support.
In this case Nm defines the number of NUMA regions (typically sockets)
on a node which will be utilized by a single MPI rank. By default Nm
= 1. If this option is used the total number of worker-threads per
MPI rank is threads\*numa. Currently it is always almost better to
assign at least one MPI rank per NUMA region, and leave numa set to
its default value of 1. This is because letting a single process span
multiple NUMA regions induces a significant amount of cross NUMA data
traffic which is slow.
Support for the "numa" or "n" option was removed as its functionality
was ignored in Kokkos for some time already.
----------
@ -334,7 +324,7 @@ writes log information to file.N. If file is none, then no partition
log files are created. This overrides the filename specified in the
-log command-line option. This option is useful when working with
large numbers of partitions, allowing the partition log files to be
suppressed (-plog none) or placed in a sub-directory (-plog
suppressed (-plog none) or placed in a subdirectory (-plog
replica_files/log.lammps) If this option is not used the log file for
partition N is log.lammps.N or whatever is specified by the -log
command-line option.
@ -351,7 +341,7 @@ partition screen files are created. This overrides the filename
specified in the -screen command-line option. This option is useful
when working with large numbers of partitions, allowing the partition
screen files to be suppressed (-pscreen none) or placed in a
sub-directory (-pscreen replica_files/screen). If this option is not
subdirectory (-pscreen replica_files/screen). If this option is not
used the screen file for partition N is screen.N or whatever is
specified by the -screen command-line option.
@ -372,10 +362,10 @@ Reorder the processors in the MPI communicator used to instantiate
LAMMPS, in one of several ways. The original MPI communicator ranks
all P processors from 0 to P-1. The mapping of these ranks to
physical processors is done by MPI before LAMMPS begins. It may be
useful in some cases to alter the rank order. E.g. to insure that
useful in some cases to alter the rank order. E.g. to ensure that
cores within each node are ranked in a desired order. Or when using
the :doc:`run_style verlet/split <run_style>` command with 2 partitions
to insure that a specific Kspace processor (in the second partition) is
to ensure that a specific Kspace processor (in the second partition) is
matched up with a specific set of processors in the first partition.
See the :doc:`General tips <Speed_tips>` page for more details.
@ -408,7 +398,7 @@ so that the processors in each partition will be
0 1 2 4 5 6 8 9 10
3 7 11
See the "processors" command for how to insure processors from each
See the "processors" command for how to ensure processors from each
partition could then be grouped optimally for quad-core nodes.
If the keyword is *custom*, then a file that specifies a permutation

2
doc/src/Run_output.rst
View File

@ -122,7 +122,7 @@ potentially *dangerous* rebuilds. If atom movement triggered neighbor
list rebuilding (see the :doc:`neigh_modify <neigh_modify>` command),
then dangerous reneighborings are those that were triggered on the
first timestep atom movement was checked for. If this count is
non-zero you may wish to reduce the delay factor to insure no force
non-zero you may wish to reduce the delay factor to ensure no force
interactions are missed by atoms moving beyond the neighbor skin
distance before a rebuild takes place.

2
doc/src/Run_windows.rst
View File

@ -33,7 +33,7 @@ path for the default location of this MPI package. After the
installation of the MPICH2 software, it needs to be integrated into
the system. For this you need to start a Command Prompt in
*Administrator Mode* (right click on the icon and select it). Change
into the MPICH2 installation directory, then into the sub-directory
into the MPICH2 installation directory, then into the subdirectory
**bin** and execute **smpd.exe -install**\ . Exit the command window.
* Get a new, regular command prompt by going to Start->Run... ,

2
doc/src/Speed.rst
View File

@ -9,7 +9,7 @@ There are two thrusts to the discussion that follows. The first is
using code options that implement alternate algorithms that can
speed-up a simulation. The second is to use one of the several
accelerator packages provided with LAMMPS that contain code optimized
for certain kinds of hardware, including multi-core CPUs, GPUs, and
for certain kinds of hardware, including multicore CPUs, GPUs, and
Intel Xeon Phi co-processors.
The `Benchmark page <https://www.lammps.org/bench.html>`_ of the LAMMPS

8
doc/src/Speed_gpu.rst
View File

@ -11,7 +11,7 @@ parts of the :doc:`kspace_style pppm <kspace_style>` for long-range
Coulombics. It has the following general features:
* It is designed to exploit common GPU hardware configurations where one
or more GPUs are coupled to many cores of one or more multi-core CPUs,
or more GPUs are coupled to many cores of one or more multicore CPUs,
e.g. within a node of a parallel machine.
* Atom-based data (e.g. coordinates, forces) are moved back-and-forth
between the CPU(s) and GPU every timestep.
@ -28,7 +28,7 @@ Coulombics. It has the following general features:
* LAMMPS-specific code is in the GPU package. It makes calls to a
generic GPU library in the lib/gpu directory. This library provides
either Nvidia support, AMD support, or more general OpenCL support
(for Nvidia GPUs, AMD GPUs, Intel GPUs, and multi-core CPUs).
(for Nvidia GPUs, AMD GPUs, Intel GPUs, and multicore CPUs).
so that the same functionality is supported on a variety of hardware.
**Required hardware/software:**
@ -146,7 +146,7 @@ GPUs/node to use, as well as other options.
**Speed-ups to expect:**
The performance of a GPU versus a multi-core CPU is a function of your
The performance of a GPU versus a multicore CPU is a function of your
hardware, which pair style is used, the number of atoms/GPU, and the
precision used on the GPU (double, single, mixed). Using the GPU package
in OpenCL mode on CPUs (which uses vectorization and multithreading) is
@ -174,7 +174,7 @@ deterministic results.
**Guidelines for best performance:**
* Using multiple MPI tasks per GPU will often give the best performance,
as allowed my most multi-core CPU/GPU configurations.
as allowed my most multicore CPU/GPU configurations.
* If the number of particles per MPI task is small (e.g. 100s of
particles), it can be more efficient to run with fewer MPI tasks per
GPU, even if you do not use all the cores on the compute node.

4
doc/src/Speed_kokkos.rst
View File

@ -79,7 +79,7 @@ manner via the ``mpirun`` or ``mpiexec`` commands, and is independent of
Kokkos. E.g. the mpirun command in OpenMPI does this via its ``-np`` and
``-npernode`` switches. Ditto for MPICH via ``-np`` and ``-ppn``.
Running on a multi-core CPU
Running on a multicore CPU
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Here is a quick overview of how to use the KOKKOS package
@ -254,7 +254,7 @@ is recommended in this scenario.
Using a GPU-aware MPI library is highly recommended. GPU-aware MPI use can be
avoided by using :doc:`-pk kokkos gpu/aware off <package>`. As above for
multi-core CPUs (and no GPU), if N is the number of physical cores/node,
multicore CPUs (and no GPU), if N is the number of physical cores/node,
then the number of MPI tasks/node should not exceed N.
.. parsed-literal::

6
doc/src/Speed_omp.rst
View File

@ -12,7 +12,7 @@ Required hardware/software
""""""""""""""""""""""""""
To enable multi-threading, your compiler must support the OpenMP interface.
You should have one or more multi-core CPUs, as multiple threads can only be
You should have one or more multicore CPUs, as multiple threads can only be
launched by each MPI task on the local node (using shared memory).
Building LAMMPS with the OPENMP package
@ -93,7 +93,7 @@ With multiple threads/task, the optimal choice of number of MPI
tasks/node and OpenMP threads/task can vary a lot and should always be
tested via benchmark runs for a specific simulation running on a
specific machine, paying attention to guidelines discussed in the next
sub-section.
subsection.
A description of the multi-threading strategy used in the OPENMP
package and some performance examples are
@ -157,7 +157,7 @@ Additional performance tips are as follows:
affinity setting that restricts each MPI task to a single CPU core.
Using multi-threading in this mode will force all threads to share the
one core and thus is likely to be counterproductive. Instead, binding
MPI tasks to a (multi-core) socket, should solve this issue.
MPI tasks to a (multicore) socket, should solve this issue.
Restrictions
""""""""""""

34
doc/src/Tools.rst
View File

@ -29,11 +29,11 @@ actively supported by the LAMMPS developers, as they were contributed
by LAMMPS users. If you have problems using them, we can direct you
to the authors.
The source code for each of these codes is in the tools sub-directory
The source code for each of these codes is in the tools subdirectory
of the LAMMPS distribution. There is a Makefile (which you may need
to edit for your platform) which will build several of the tools which
reside in that directory. Most of them are larger packages in their
own sub-directories with their own Makefiles and/or README files.
own subdirectories with their own Makefiles and/or README files.
----------
@ -109,7 +109,7 @@ Tool descriptions
amber2lmp tool
--------------------------
The amber2lmp sub-directory contains two Python scripts for converting
The amber2lmp subdirectory contains two Python scripts for converting
files back-and-forth between the AMBER MD code and LAMMPS. See the
README file in amber2lmp for more information.
@ -145,7 +145,7 @@ since binary files are not compatible across all platforms.
ch2lmp tool
------------------------
The ch2lmp sub-directory contains tools for converting files
The ch2lmp subdirectory contains tools for converting files
back-and-forth between the CHARMM MD code and LAMMPS.
They are intended to make it easy to use CHARMM as a builder and as a
@ -156,7 +156,7 @@ CHARMM22 and later is available as an option. This tool can also add
solvent water molecules and Na+ or Cl- ions to the system.
Using lammps2pdb.pl you can convert LAMMPS atom dumps into PDB files.
See the README file in the ch2lmp sub-directory for more information.
See the README file in the ch2lmp subdirectory for more information.
These tools were created by Pieter in't Veld (pjintve at sandia.gov)
and Paul Crozier (pscrozi at sandia.gov) at Sandia.
@ -638,7 +638,7 @@ you first need to use the :doc:`clear` command.
lmp2arc tool
------------
The lmp2arc sub-directory contains a tool for converting LAMMPS output
The lmp2arc subdirectory contains a tool for converting LAMMPS output
files to the format for Accelrys' Insight MD code (formerly
MSI/Biosym and its Discover MD code). See the README file for more
information.
@ -657,7 +657,7 @@ Greathouse at Sandia (jagreat at sandia.gov).
lmp2cfg tool
----------------------
The lmp2cfg sub-directory contains a tool for converting LAMMPS output
The lmp2cfg subdirectory contains a tool for converting LAMMPS output
files into a series of \*.cfg files which can be read into the
`AtomEye <http://li.mit.edu/Archive/Graphics/A/>`_ visualizer. See
the README file for more information.
@ -704,7 +704,7 @@ detect most LAMMPS restarts, dump, data and log files. Examples:
matlab tool
------------------------
The matlab sub-directory contains several `MATLAB <matlabhome_>`_ scripts for
The matlab subdirectory contains several `MATLAB <matlabhome_>`_ scripts for
post-processing LAMMPS output. The scripts include readers for log
and dump files, a reader for EAM potential files, and a converter that
reads LAMMPS dump files and produces CFG files that can be visualized
@ -747,7 +747,7 @@ definition file. This tool was used to create the system for the
moltemplate tool
----------------------------------
The moltemplate sub-directory contains instructions for installing
The moltemplate subdirectory contains instructions for installing
moltemplate, a Python-based tool for building molecular systems based
on a text-file description, and creating LAMMPS data files that encode
their molecular topology as lists of bonds, angles, dihedrals, etc.
@ -765,7 +765,7 @@ The latest sources can be found `on its GitHub page <https://github.com/jewettai
msi2lmp tool
----------------------
The msi2lmp sub-directory contains a tool for creating LAMMPS template
The msi2lmp subdirectory contains a tool for creating LAMMPS template
input and data files from BIOVIA's Materias Studio files (formerly
Accelrys' Insight MD code, formerly MSI/Biosym and its Discover MD code).
@ -882,7 +882,7 @@ dependencies and redirects the download to the local cache.
phonon tool
------------------------
The phonon sub-directory contains a post-processing tool useful for
The phonon subdirectory contains a post-processing tool useful for
analyzing the output of the :doc:`fix phonon <fix_phonon>` command in
the PHONON package.
@ -900,7 +900,7 @@ University.
polybond tool
----------------------------
The polybond sub-directory contains a Python-based tool useful for
The polybond subdirectory contains a Python-based tool useful for
performing "programmable polymer bonding". The Python file
lmpsdata.py provides a "Lmpsdata" class with various methods which can
be invoked by a user-written Python script to create data files with
@ -917,7 +917,7 @@ This tool was written by Zachary Kraus at Georgia Tech.
pymol_asphere tool
-------------------------------
The pymol_asphere sub-directory contains a tool for converting a
The pymol_asphere subdirectory contains a tool for converting a
LAMMPS dump file that contains orientation info for ellipsoidal
particles into an input file for the `PyMol visualization package <pymolhome_>`_ or its `open source variant <pymolopen_>`_.
@ -938,7 +938,7 @@ This tool was written by Mike Brown at Sandia.
python tool
-----------------------------
The python sub-directory contains several Python scripts
The python subdirectory contains several Python scripts
that perform common LAMMPS post-processing tasks, such as:
* extract thermodynamic info from a log file as columns of numbers
@ -975,7 +975,7 @@ while at the Shell lab at UC Santa Barbara. (tanmoy dot 7989 at gmail.com)
smd tool
------------------
The smd sub-directory contains a C++ file dump2vtk_tris.cpp and
The smd subdirectory contains a C++ file dump2vtk_tris.cpp and
Makefile which can be compiled and used to convert triangle output
files created by the Smooth-Mach Dynamics (MACHDYN) package into a
VTK-compatible unstructured grid file. It could then be read in and
@ -994,7 +994,7 @@ Ernst Mach Institute in Germany (georg.ganzenmueller at emi.fhg.de).
spin tool
--------------------
The spin sub-directory contains a C file interpolate.c which can
The spin subdirectory contains a C file interpolate.c which can
be compiled and used to perform a cubic polynomial interpolation of
the MEP following a GNEB calculation.
@ -1011,7 +1011,7 @@ Ivanov, at University of Iceland (ali5 at hi.is).
singularity/apptainer tool
--------------------------
The singularity sub-directory contains container definitions files that
The singularity subdirectory contains container definitions files that
can be used to build container images for building and testing LAMMPS on
specific OS variants using the `Apptainer <https://apptainer.org>`_ or
`Singularity <https://sylabs.io>`_ container software. Contributions for

2
doc/src/atom_modify.rst
View File

@ -113,7 +113,7 @@ your input script. LAMMPS does not use the group until a simulation
is run.
The *sort* keyword turns on a spatial sorting or reordering of atoms
within each processor's sub-domain every *Nfreq* timesteps. If
within each processor's subdomain every *Nfreq* timesteps. If
*Nfreq* is set to 0, then sorting is turned off. Sorting can improve
cache performance and thus speed-up a LAMMPS simulation, as discussed
in a paper by :ref:`(Meloni) <Meloni>`. Its efficacy depends on the problem

8
doc/src/atom_style.rst
View File

@ -10,7 +10,7 @@ Syntax
atom_style style args
* style = *amoeba* or *angle* or *atomic* or *body* or *bond* or *charge* or *dielectric* or *dipole* or *dpd* or *edpd* or *electron* or *ellipsoid* or *full* or *line* or *mdpd* or *mesont* or *molecular* or *oxdna* or *peri* or *smd* or *sph* or *sphere* or *bpm/sphere* or *spin* or *tdpd* or *tri* or *template* or *wavepacket* or *hybrid*
* style = *amoeba* or *angle* or *atomic* or *body* or *bond* or *charge* or *dielectric* or *dipole* or *dpd* or *edpd* or *electron* or *ellipsoid* or *full* or *line* or *mdpd* or *molecular* or *oxdna* or *peri* or *smd* or *sph* or *sphere* or *bpm/sphere* or *spin* or *tdpd* or *tri* or *template* or *wavepacket* or *hybrid*
.. parsed-literal::
@ -109,8 +109,6 @@ quantities.
+--------------+-----------------------------------------------------+--------------------------------------+
| *mdpd* | density | mDPD particles |
+--------------+-----------------------------------------------------+--------------------------------------+
| *mesont* | mass, radius, length, buckling, connections, tube id| mesoscopic nanotubes |
+--------------+-----------------------------------------------------+--------------------------------------+
| *molecular* | bonds, angles, dihedrals, impropers | uncharged molecules |
+--------------+-----------------------------------------------------+--------------------------------------+
| *oxdna* | nucleotide polarity | coarse-grained DNA and RNA models |
@ -284,7 +282,7 @@ showing the use of the *template* atom style versus *molecular*.
.. note::
When using the *template* style with a :doc:`molecule template
<molecule>` that contains multiple molecules, you should insure the
<molecule>` that contains multiple molecules, you should ensure the
atom types, bond types, angle_types, etc in all the molecules are
consistent. E.g. if one molecule represents H2O and another CO2,
then you probably do not want each molecule file to define 2 atom
@ -382,8 +380,6 @@ The *sph* style is part of the SPH package for smoothed particle
hydrodynamics (SPH). See `this PDF guide
<PDF/SPH_LAMMPS_userguide.pdf>`_ to using SPH in LAMMPS.
The *mesont* style is part of the MESONT package.
The *spin* style is part of the SPIN package.
The *wavepacket* style is part of the AWPMD package for the

34
doc/src/balance.rst
View File

@ -54,7 +54,7 @@ Syntax
*store* name = store weight in custom atom property defined by :doc:`fix property/atom <fix_property_atom>` command
name = atom property name (without d\_ prefix)
*out* arg = filename
filename = write each processor's sub-domain to a file
filename = write each processor's subdomain to a file
Examples
""""""""
@ -72,14 +72,14 @@ Examples
Description
"""""""""""
This command adjusts the size and shape of processor sub-domains
This command adjusts the size and shape of processor subdomains
within the simulation box, to attempt to balance the number of atoms
or particles and thus indirectly the computational cost (load) more
evenly across processors. The load balancing is "static" in the sense
that this command performs the balancing once, before or between
simulations. The processor sub-domains will then remain static during
simulations. The processor subdomains will then remain static during
the subsequent run. To perform "dynamic" balancing, see the :doc:`fix
balance <fix_balance>` command, which can adjust processor sub-domain
balance <fix_balance>` command, which can adjust processor subdomain
sizes and shapes on-the-fly during a :doc:`run <run>`.
Load-balancing is typically most useful if the particles in the
@ -90,7 +90,7 @@ an irregular-shaped geometry containing void regions, or :doc:`hybrid
pair style simulations <pair_hybrid>` which combine pair styles with
different computational cost. In these cases, the LAMMPS default of
dividing the simulation box volume into a regular-spaced grid of 3d
bricks, with one equal-volume sub-domain per processor, may assign
bricks, with one equal-volume subdomain per processor, may assign
numbers of particles per processor in a way that the computational
effort varies significantly. This can lead to poor performance when
the simulation is run in parallel.
@ -109,7 +109,7 @@ Specifically, for a Px by Py by Pz grid of processors, it allows
choice of Px, Py, and Pz, subject to the constraint that Px \* Py \*
Pz = P, the total number of processors. This is sufficient to achieve
good load-balance for some problems on some processor counts.
However, all the processor sub-domains will still have the same shape
However, all the processor subdomains will still have the same shape
and same volume.
The requested load-balancing operation is only performed if the
@ -162,7 +162,7 @@ fractions of the box length) are also printed.
simulation could run up to 20% faster if it were perfectly balanced,
versus when imbalanced. However, computational cost is not strictly
proportional to particle count, and changing the relative size and
shape of processor sub-domains may lead to additional computational
shape of processor subdomains may lead to additional computational
and communication overheads, e.g. in the PPPM solver used via the
:doc:`kspace_style <kspace_style>` command. Thus you should benchmark
the run times of a simulation before and after balancing.
@ -177,7 +177,7 @@ The *x*, *y*, *z*, and *shift* styles are "grid" methods which
produce a logical 3d grid of processors. They operate by changing the
cutting planes (or lines) between processors in 3d (or 2d), to adjust
the volume (area in 2d) assigned to each processor, as in the
following 2d diagram where processor sub-domains are shown and
following 2d diagram where processor subdomains are shown and
particles are colored by the processor that owns them.
.. |balance1| image:: img/balance_uniform.jpg
@ -226,7 +226,7 @@ The *x*, *y*, and *z* styles invoke a "grid" method for balancing, as
described above. Note that any or all of these 3 styles can be
specified together, one after the other, but they cannot be used with
any other style. This style adjusts the position of cutting planes
between processor sub-domains in specific dimensions. Only the
between processor subdomains in specific dimensions. Only the
specified dimensions are altered.
The *uniform* argument spaces the planes evenly, as in the left
@ -245,8 +245,8 @@ the cutting place. The left (or lower) edge of the box is 0.0, and
the right (or upper) edge is 1.0. Neither of these values is
specified. Only the interior Ps-1 positions are specified. Thus is
there are 2 processors in the x dimension, you specify a single value
such as 0.75, which would make the left processor's sub-domain 3x
larger than the right processor's sub-domain.
such as 0.75, which would make the left processor's subdomain 3x
larger than the right processor's subdomain.
----------
@ -288,10 +288,10 @@ adjacent planes are closer together than the neighbor skin distance
(as specified by the :doc:`neigh_modify <neigh_modify>` command), then
the plane positions are shifted to separate them by at least this
amount. This is to prevent particles being lost when dynamics are run
with processor sub-domains that are too narrow in one or more
with processor subdomains that are too narrow in one or more
dimensions.
Once the re-balancing is complete and final processor sub-domains
Once the re-balancing is complete and final processor subdomains
assigned, particles are migrated to their new owning processor, and
the balance procedure ends.
@ -299,7 +299,7 @@ the balance procedure ends.
At each re-balance operation, the bisectioning for each cutting
plane (line in 2d) typically starts with low and high bounds separated
by the extent of a processor's sub-domain in one dimension. The size
by the extent of a processor's subdomain in one dimension. The size
of this bracketing region shrinks by 1/2 every iteration. Thus if
*Niter* is specified as 10, the cutting plane will typically be
positioned to 1 part in 1000 accuracy (relative to the perfect target
@ -350,7 +350,7 @@ particles in that sub-box.
.. _weighted_balance:
This sub-section describes how to perform weighted load balancing
This subsection describes how to perform weighted load balancing
using the *weight* keyword.
By default, all particles have a weight of 1.0, which means each
@ -494,7 +494,7 @@ different kinds of custom atom vectors or arrays as arguments.
The *out* keyword writes a text file to the specified *filename* with
the results of the balancing operation. The file contains the bounds
of the sub-domain for each processor after the balancing operation
of the subdomain for each processor after the balancing operation
completes. The format of the file is compatible with the
`Pizza.py <pizza_>`_ *mdump* tool which has support for manipulating and
visualizing mesh files. An example is shown here for a balancing by 4
@ -538,7 +538,7 @@ processors for a 2d problem:
4 1 13 14 15 16
The coordinates of all the vertices are listed in the NODES section, 5
per processor. Note that the 4 sub-domains share vertices, so there
per processor. Note that the 4 subdomains share vertices, so there
will be duplicate nodes in the list.
The "SQUARES" section lists the node IDs of the 4 vertices in a

2
doc/src/boundary.rst
View File

@ -61,7 +61,7 @@ move. Note that when the difference between the current box dimensions
and the shrink-wrap box dimensions is large, this can lead to lost
atoms at the beginning of a run when running in parallel. This is due
to the large change in the (global) box dimensions also causing
significant changes in the individual sub-domain sizes. If these
significant changes in the individual subdomain sizes. If these
changes are farther than the communication cutoff, atoms will be lost.
This is best addressed by setting initial box dimensions to match the
shrink-wrapped dimensions more closely, by using *m* style boundaries

6
doc/src/comm_modify.rst
View File

@ -62,7 +62,7 @@ distances are used to determine which atoms to communicate.
The default mode is *single* which means each processor acquires
information for ghost atoms that are within a single distance from its
sub-domain. The distance is by default the maximum of the neighbor
subdomain. The distance is by default the maximum of the neighbor
cutoff across all atom type pairs.
For many systems this is an efficient algorithm, but for systems with
@ -81,7 +81,7 @@ with both the *multi* and *multi/old* neighbor styles.
The *cutoff* keyword allows you to extend the ghost cutoff distance
for communication mode *single*, which is the distance from the borders
of a processor's sub-domain at which ghost atoms are acquired from other
of a processor's subdomain at which ghost atoms are acquired from other
processors. By default the ghost cutoff = neighbor cutoff = pairwise
force cutoff + neighbor skin. See the :doc:`neighbor <neighbor>` command
for more information about the skin distance. If the specified Rcut is
@ -148,7 +148,7 @@ In the last scenario, a :doc:`fix <fix>` or :doc:`compute <compute>` or
:doc:`pairwise potential <pair_style>` needs to calculate with ghost
atoms beyond the normal pairwise cutoff for some computation it
performs (e.g. locate neighbors of ghost atoms in a manybody pair
potential). Setting the ghost cutoff appropriately can insure it will
potential). Setting the ghost cutoff appropriately can ensure it will
find the needed atoms.
.. note::

3
doc/src/compute.rst
View File

@ -54,7 +54,7 @@ per atom, e.g. a list of bond distances. Per-grid quantities are
calculated on a regular 2d or 3d grid which overlays a 2d or 3d
simulation domain. The grid points and the data they store are
distributed across processors; each processor owns the grid points
which fall within its sub-domain.
which fall within its subdomain.
Computes that produce per-atom quantities have the word "atom" at the
end of their style, e.g. *ke/atom*\ . Computes that produce local
@ -254,7 +254,6 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
* :doc:`pair/local <compute_pair_local>` - distance/energy/force of each pairwise interaction
* :doc:`pe <compute_pe>` - potential energy
* :doc:`pe/atom <compute_pe_atom>` - potential energy for each atom
* :doc:`mesont <compute_mesont>` - Nanotube bending,stretching, and intertube energies
* :doc:`pe/mol/tally <compute_tally>` - potential energy between two groups of atoms separated into intermolecular and intramolecular components via the tally callback mechanism
* :doc:`pe/tally <compute_tally>` - potential energy between two groups of atoms via the tally callback mechanism
* :doc:`plasticity/atom <compute_plasticity_atom>` - Peridynamic plasticity for each atom

2
doc/src/compute_adf.rst
View File

@ -75,7 +75,7 @@ neighbor atom in each requested ADF.
If you request any outer cutoff *Router* > force cutoff, or if no
pair style is defined, e.g. the :doc:`rerun <rerun>` command is being used to
post-process a dump file of snapshots you must insure ghost atom information
post-process a dump file of snapshots you must ensure ghost atom information
out to the largest value of *Router* + *skin* is communicated, via the
:doc:`comm_modify cutoff <comm_modify>` command, else the ADF computation
cannot be performed, and LAMMPS will give an error message. The *skin* value

2
doc/src/compute_cna_atom.rst
View File

@ -43,7 +43,7 @@ compute group. Note that normally a CNA calculation should only be
performed on mono-component systems.
The CNA calculation can be sensitive to the specified cutoff value.
You should insure the appropriate nearest neighbors of an atom are
You should ensure the appropriate nearest neighbors of an atom are
found within the cutoff distance for the presumed crystal structure
(e.g., 12 nearest neighbor for perfect FCC and HCP crystals, 14 nearest
neighbors for perfect BCC crystals). These formulas can be used to

2
doc/src/compute_efield_wolf_atom.rst
View File

@ -81,7 +81,7 @@ cutoff of any pair style force computation.
:class: note
This compute will loop over a full neighbor list just like a pair
style does when computing forces, thus it can be quite time consuming
style does when computing forces, thus it can be quite time-consuming
and slow down a calculation significantly when its data is used in
every time step. The :doc:`compute efield/atom
<compute_efield_atom>` command of the DIELECTRIC package is more

59
doc/src/compute_mesont.rst
View File

@ -1,59 +0,0 @@
.. index:: compute mesont
compute mesont command
======================
Syntax
""""""
.. code-block:: LAMMPS
compute ID group-ID mesont style
* ID, group-ID are documented in :doc:`compute <compute>` command
* mesont = style name of the compute command
* style = *estretch* or *ebend* or *etube*
Examples
""""""""
.. code-block:: LAMMPS
compute 1 all mesont estretch
Description
"""""""""""
These computes define computations for the stretching (*estretch*), bending
(*ebend*), and intertube (*etube*) per-node (atom) and total energies. The
evaluated value is selected by the style parameter passed to the compute
(*estretch*, *ebend*,or *etube*).
Output info
"""""""""""
These computes calculate per-node (per-atom) vectors, which can be accessed by
any command that uses per-atom values from a compute as input, and global
scalars. See the :doc:`Howto output <Howto_output>` page for an overview of
LAMMPS output options.
The computed values are provided in energy :doc:`units <units>`.
Restrictions
""""""""""""
These computes are part of the MESONT package. They are only enabled if
LAMMPS is built with that package. See the :doc:`Build package <Build_package>`
doc page for more info. In addition, :doc:`mesont pair_style <pair_style>`
must be used.
Related commands
""""""""""""""""
:doc:`dump custom <dump>`
Default
"""""""
none

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