diff --git a/.github/workflows/codeql-analysis.yml b/.github/workflows/codeql-analysis.yml
index c33628ac04..58b001be24 100644
--- a/.github/workflows/codeql-analysis.yml
+++ b/.github/workflows/codeql-analysis.yml
@@ -25,7 +25,7 @@ jobs:
steps:
- name: Checkout repository
- uses: actions/checkout@v3
+ uses: actions/checkout@v4
with:
fetch-depth: 2
diff --git a/.github/workflows/compile-msvc.yml b/.github/workflows/compile-msvc.yml
index 5ae0654ee0..5c6ceeefb4 100644
--- a/.github/workflows/compile-msvc.yml
+++ b/.github/workflows/compile-msvc.yml
@@ -19,7 +19,7 @@ jobs:
steps:
- name: Checkout repository
- uses: actions/checkout@v3
+ uses: actions/checkout@v4
with:
fetch-depth: 2
diff --git a/.github/workflows/coverity.yml b/.github/workflows/coverity.yml
index 7bda3a071f..b1c23e1f6a 100644
--- a/.github/workflows/coverity.yml
+++ b/.github/workflows/coverity.yml
@@ -16,7 +16,7 @@ jobs:
steps:
- name: Checkout repository
- uses: actions/checkout@v3
+ uses: actions/checkout@v4
with:
fetch-depth: 2
diff --git a/.github/workflows/unittest-macos.yml b/.github/workflows/unittest-macos.yml
index ea979ca94f..6970faceaa 100644
--- a/.github/workflows/unittest-macos.yml
+++ b/.github/workflows/unittest-macos.yml
@@ -21,7 +21,7 @@ jobs:
steps:
- name: Checkout repository
- uses: actions/checkout@v3
+ uses: actions/checkout@v4
with:
fetch-depth: 2
diff --git a/cmake/Modules/Packages/ML-PACE.cmake b/cmake/Modules/Packages/ML-PACE.cmake
index 6cdb751617..ce8f02f5f4 100644
--- a/cmake/Modules/Packages/ML-PACE.cmake
+++ b/cmake/Modules/Packages/ML-PACE.cmake
@@ -1,6 +1,6 @@
-set(PACELIB_URL "https://github.com/ICAMS/lammps-user-pace/archive/refs/tags/v.2023.01.3.fix.tar.gz" CACHE STRING "URL for PACE evaluator library sources")
+set(PACELIB_URL "https://github.com/ICAMS/lammps-user-pace/archive/refs/tags/v.2023.10.04.tar.gz" CACHE STRING "URL for PACE evaluator library sources")
-set(PACELIB_MD5 "4f0b3b5b14456fe9a73b447de3765caa" CACHE STRING "MD5 checksum of PACE evaluator library tarball")
+set(PACELIB_MD5 "70ff79f4e59af175e55d24f3243ad1ff" CACHE STRING "MD5 checksum of PACE evaluator library tarball")
mark_as_advanced(PACELIB_URL)
mark_as_advanced(PACELIB_MD5)
GetFallbackURL(PACELIB_URL PACELIB_FALLBACK)
diff --git a/cmake/packaging/LAMMPS_DMG_Background.png b/cmake/packaging/LAMMPS_DMG_Background.png
index 5ceb55c5e7..978b7d1987 100644
Binary files a/cmake/packaging/LAMMPS_DMG_Background.png and b/cmake/packaging/LAMMPS_DMG_Background.png differ
diff --git a/cmake/packaging/MacOSXBundleInfo.plist.in b/cmake/packaging/MacOSXBundleInfo.plist.in
index 33ce5a602b..bc08591e97 100644
--- a/cmake/packaging/MacOSXBundleInfo.plist.in
+++ b/cmake/packaging/MacOSXBundleInfo.plist.in
@@ -17,7 +17,7 @@
CFBundleLongVersionString
${MACOSX_BUNDLE_LONG_VERSION_STRING}
CFBundleName
- LAMMPS
+ LAMMPS_GUI
CFBundlePackageType
APPL
CFBundleShortVersionString
diff --git a/cmake/packaging/README.macos b/cmake/packaging/README.macos
index 0325045983..d7583e7034 100644
--- a/cmake/packaging/README.macos
+++ b/cmake/packaging/README.macos
@@ -9,7 +9,7 @@ of the available packages.
The following individual commands are included:
binary2txt lammps-gui lmp msi2lmp phana stl_bin2txt
-After copying the lammps-gui folder into your Applications folder, please follow
+After copying the LAMMPS_GUI folder into your Applications folder, please follow
these steps:
1. Open the Terminal app
@@ -23,7 +23,7 @@ these steps:
3. Add the following lines to the end of the file, save it, and close the editor
- LAMMPS_INSTALL_DIR=/Applications/LAMMPS.app/Contents
+ LAMMPS_INSTALL_DIR=/Applications/LAMMPS_GUI.app/Contents
LAMMPS_POTENTIALS=${LAMMPS_INSTALL_DIR}/share/lammps/potentials
LAMMPS_BENCH_DIR=${LAMMPS_INSTALL_DIR}/share/lammps/bench
MSI2LMP_LIBRARY=${LAMMPS_INSTALL_DIR}/share/lammps/frc_files
@@ -38,9 +38,9 @@ these steps:
the changes from .zprofile automatically.
Note: the above assumes you use the default shell (zsh) that comes with
- MacOS. If you customized MacOS to use a different shell, you'll need to modify
- that shell's init file (.cshrc, .bashrc, etc.) instead with appropiate commands
- to modify the same environment variables.
+ MacOS. If you customized MacOS to use a different shell, you'll need to
+ modify that shell's init file (.cshrc, .bashrc, etc.) instead with
+ appropiate commands to modify the same environment variables.
5. Try running LAMMPS (which might fail, see step 7)
@@ -50,10 +50,10 @@ these steps:
lammps-gui ${LAMMPS_BENCH_DIR}/in.rhodo
- Depending on the size and resolution of your screen, the fonts may
- be too small to read. This can be adjusted by setting the environment
- variable QT_FONT_DPI. The default value would be 72, so to increase
- the fonts by a third one can add to the .zprofile file the line
+ Depending on the size and resolution of your screen, the fonts may be too
+ small to read. This can be adjusted by setting the environment variable
+ QT_FONT_DPI. The default value would be 72, so to increase the fonts by a
+ third, one can add to the .zprofile file the line
export QT_FONT_DPI=96
@@ -61,9 +61,9 @@ these steps:
7. Give permission to execute the commands (lmp, lammps-gui, msi2lmp, binary2txt, phana, stl_bin2txt)
- MacOS will likely block the initial run of the executables, since they
- were downloaded from the internet and are missing a known signature from an
- identified developer. Go to "Settings" and search for "Security settings". It
- should display a message that an executable like "lmp" was blocked. Press
+ MacOS will likely block the initial run of the executables, since they were
+ downloaded from the internet and are missing a known signature from an
+ identified developer. Go to "Settings" and search for "Security settings".
+ It should display a message that an executable like "lmp" was blocked. Press
"Open anyway", which might prompt you for your admin credentials. Afterwards
"lmp" and the other executables should work as expected.
diff --git a/cmake/packaging/build_linux_tgz.sh b/cmake/packaging/build_linux_tgz.sh
index e0222858ce..48e3017f61 100755
--- a/cmake/packaging/build_linux_tgz.sh
+++ b/cmake/packaging/build_linux_tgz.sh
@@ -4,7 +4,7 @@ APP_NAME=lammps-gui
DESTDIR=${PWD}/../LAMMPS_GUI
echo "Delete old files, if they exist"
-rm -rf ${DESTDIR} ../LAMMPS-Linux-amd64.tar.gz
+rm -rf ${DESTDIR} ../LAMMPS_GUI-Linux-amd64.tar.gz
echo "Create staging area for deployment and populate"
DESTDIR=${DESTDIR} cmake --install . --prefix "/"
@@ -69,7 +69,7 @@ do \
done
pushd ..
-tar -czvvf LAMMPS-Linux-amd64.tar.gz LAMMPS_GUI
+tar -czvvf LAMMPS_GUI-Linux-amd64.tar.gz LAMMPS_GUI
popd
echo "Cleanup dir"
diff --git a/cmake/packaging/build_macos_dmg.sh b/cmake/packaging/build_macos_dmg.sh
index 5204e519c2..4da3e40eaf 100755
--- a/cmake/packaging/build_macos_dmg.sh
+++ b/cmake/packaging/build_macos_dmg.sh
@@ -3,7 +3,7 @@
APP_NAME=lammps-gui
echo "Delete old files, if they exist"
-rm -f ${APP_NAME}.dmg ${APP_NAME}-rw.dmg LAMMPS-macOS-multiarch.dmg
+rm -f ${APP_NAME}.dmg ${APP_NAME}-rw.dmg LAMMPS_GUI-macOS-multiarch.dmg
echo "Create initial dmg file with macdeployqt"
macdeployqt lammps-gui.app -dmg
@@ -22,8 +22,8 @@ ln -s /Applications .
mv ${APP_NAME}.app/Contents/Resources/README.txt .
mkdir .background
mv ${APP_NAME}.app/Contents/Resources/LAMMPS_DMG_Background.png .background/background.png
-mv ${APP_NAME}.app LAMMPS.app
-cd LAMMPS.app/Contents
+mv ${APP_NAME}.app LAMMPS_GUI.app
+cd LAMMPS_GUI.app/Contents
echo "Attach icons to LAMMPS console and GUI executables"
echo "read 'icns' (-16455) \"Resources/lammps.icns\";" > icon.rsrc
@@ -75,7 +75,7 @@ echo '
set statusbar visible to false
set toolbar visible to false
set the bounds to { 100, 40, 868, 640 }
- set position of item "'LAMMPS'.app" to { 190, 216 }
+ set position of item "'LAMMPS_GUI'.app" to { 190, 216 }
set position of item "Applications" to { 576, 216 }
set position of item "README.txt" to { 190, 400 }
end tell
@@ -96,12 +96,12 @@ sync
echo "Unmount modified disk image and convert to compressed read-only image"
hdiutil detach "${DEVICE}"
-hdiutil convert "${APP_NAME}-rw.dmg" -format UDZO -o "LAMMPS-macOS-multiarch.dmg"
+hdiutil convert "${APP_NAME}-rw.dmg" -format UDZO -o "LAMMPS_GUI-macOS-multiarch.dmg"
echo "Attach icon to .dmg file"
echo "read 'icns' (-16455) \"lammps-gui.app/Contents/Resources/lammps.icns\";" > icon.rsrc
-Rez -a icon.rsrc -o LAMMPS-macOS-multiarch.dmg
-SetFile -a C LAMMPS-macOS-multiarch.dmg
+Rez -a icon.rsrc -o LAMMPS_GUI-macOS-multiarch.dmg
+SetFile -a C LAMMPS_GUI-macOS-multiarch.dmg
rm icon.rsrc
echo "Delete temporary disk images"
diff --git a/cmake/packaging/build_windows_vs.cmake b/cmake/packaging/build_windows_vs.cmake
index f051ff351f..283425ff65 100644
--- a/cmake/packaging/build_windows_vs.cmake
+++ b/cmake/packaging/build_windows_vs.cmake
@@ -1,7 +1,7 @@
# CMake script to be run post installation to build zipped package
# clean up old zipfile and deployment tree
-file(REMOVE LAMMPS-Win10-amd64.zip)
+file(REMOVE LAMMPS_GUI-Win10-amd64.zip)
file(REMOVE_RECURSE LAMMPS_GUI)
file(RENAME ${INSTNAME} LAMMPS_GUI)
@@ -21,8 +21,15 @@ file(WRITE qtdeploy.bat "@ECHO OFF\r\nset VSCMD_DEBUG=0\r\nCALL ${VC_INIT} x64\r
execute_process(COMMAND cmd.exe /c qtdeploy.bat COMMAND_ECHO STDERR)
file(REMOVE qtdeploy.bat)
+# download and uncompress static FFMpeg and gzip binaries
+file(DOWNLOAD "https://download.lammps.org/thirdparty/ffmpeg-gzip.zip" ffmpeg-gzip.zip)
+file(WRITE unpackzip.ps1 "Expand-Archive -Path ffmpeg-gzip.zip -DestinationPath LAMMPS_GUI")
+execute_process(COMMAND powershell -ExecutionPolicy Bypass -File unpackzip.ps1)
+file(REMOVE unpackzip.ps1)
+file(REMOVE ffmpeg-gzip.zip)
+
# create zip archive
-file(WRITE makearchive.ps1 "Compress-Archive -Path LAMMPS_GUI -CompressionLevel Optimal -DestinationPath LAMMPS-Win10-amd64.zip")
+file(WRITE makearchive.ps1 "Compress-Archive -Path LAMMPS_GUI -CompressionLevel Optimal -DestinationPath LAMMPS_GUI-Win10-amd64.zip")
execute_process(COMMAND powershell -ExecutionPolicy Bypass -File makearchive.ps1)
file(REMOVE makearchive.ps1)
file(REMOVE_RECURSE LAMMPS_GUI)
diff --git a/cmake/presets/macos-multiarch.cmake b/cmake/presets/macos-multiarch.cmake
index 58ef013f68..8ceaec11f8 100644
--- a/cmake/presets/macos-multiarch.cmake
+++ b/cmake/presets/macos-multiarch.cmake
@@ -10,5 +10,3 @@ set(CMAKE_CXX_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
set(CMAKE_C_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
set(BUILD_MPI FALSE CACHE BOOL "" FORCE)
-set(BUILD_SHARED_LIBS FALSE CACHE BOOL "" FORCE)
-set(LAMMPS_EXCEPTIONS TRUE CACHE BOOL "" FORCE)
diff --git a/doc/src/Build_basics.rst b/doc/src/Build_basics.rst
index e250b3ec7c..233b825d01 100644
--- a/doc/src/Build_basics.rst
+++ b/doc/src/Build_basics.rst
@@ -488,8 +488,9 @@ using CMake or Make.
.. code-block:: bash
- -D BUILD_TOOLS=value # yes or no (default)
- -D BUILD_LAMMPS_SHELL=value # yes or no (default)
+ -D BUILD_TOOLS=value # yes or no (default). Build binary2txt, chain.x, micelle2d.x, msi2lmp, phana, stl_bin2txt
+ -D BUILD_LAMMPS_SHELL=value # yes or no (default). Build lammps-shell
+ -D BUILD_LAMMPS_GUI=value # yes or no (default). Build lammps-gui
The generated binaries will also become part of the LAMMPS installation
(see below).
@@ -503,7 +504,6 @@ using CMake or Make.
make binary2txt # build only binary2txt tool
make chain # build only chain tool
make micelle2d # build only micelle2d tool
- make thermo_extract # build only thermo_extract tool
cd lammps/tools/lammps-shell
make # build LAMMPS shell
diff --git a/doc/src/Build_cmake.rst b/doc/src/Build_cmake.rst
index 6c46f6d672..e622f9f208 100644
--- a/doc/src/Build_cmake.rst
+++ b/doc/src/Build_cmake.rst
@@ -177,13 +177,13 @@ configuration is selected with the *-C* flag:
ctest -C Debug
-The CMake scripts in LAMMPS have basic support for being compiled using a
-multi-config build system, but not all of it has been ported. This is in
-particular applicable to compiling packages that require additional libraries
-that would be downloaded and compiled by CMake. The "windows" preset file
-tries to keep track of which packages can be compiled natively with the
-MSVC compilers out-of-the box. Not all of those external libraries are
-portable to Windows, either.
+The CMake scripts in LAMMPS have basic support for being compiled using
+a multi-config build system, but not all of it has been ported. This is
+in particular applicable to compiling packages that require additional
+libraries that would be downloaded and compiled by CMake. The
+``windows.cmake`` preset file tries to keep track of which packages can
+be compiled natively with the MSVC compilers out-of-the box. Not all of
+the external libraries are portable to Windows, either.
Installing CMake
diff --git a/doc/src/Build_extras.rst b/doc/src/Build_extras.rst
index 6e2069c0ec..393d7e1c20 100644
--- a/doc/src/Build_extras.rst
+++ b/doc/src/Build_extras.rst
@@ -722,9 +722,10 @@ This list was last updated for version 4.0.1 of the Kokkos library.
``cmake/presets`` folder, ``kokkos-serial.cmake``,
``kokkos-openmp.cmake``, ``kokkos-cuda.cmake``,
``kokkos-hip.cmake``, and ``kokkos-sycl.cmake``. They will enable
- the KOKKOS package and enable some hardware choice. So to compile
- with CUDA device parallelization (for GPUs with CC 5.0 and up)
- with some common packages enabled, you can do the following:
+ the KOKKOS package and enable some hardware choices. For GPU
+ support those preset files must be customized to match the
+ hardware used. So to compile with CUDA device parallelization with
+ some common packages enabled, you can do the following:
.. code-block:: bash
@@ -886,6 +887,50 @@ included in the LAMMPS source distribution in the ``lib/lepton`` folder.
----------
+.. _machdyn:
+
+MACHDYN package
+-------------------------------
+
+To build with this package, you must download the Eigen3 library.
+Eigen3 is a template library, so you do not need to build it.
+
+.. tabs::
+
+ .. tab:: CMake build
+
+ .. code-block:: bash
+
+ -D DOWNLOAD_EIGEN3 # download Eigen3, value = no (default) or yes
+ -D EIGEN3_INCLUDE_DIR=path # path to Eigen library (only needed if a custom location)
+
+ If ``DOWNLOAD_EIGEN3`` is set, the Eigen3 library will be
+ downloaded and inside the CMake build directory. If the Eigen3
+ library is already on your system (in a location where CMake
+ cannot find it), set ``EIGEN3_INCLUDE_DIR`` to the directory the
+ ``Eigen3`` include file is in.
+
+ .. tab:: Traditional make
+
+ You can download the Eigen3 library manually if you prefer; follow
+ the instructions in ``lib/machdyn/README``. You can also do it in one
+ step from the ``lammps/src`` dir, using a command like these,
+ which simply invokes the ``lib/machdyn/Install.py`` script with the
+ specified args:
+
+ .. code-block:: bash
+
+ make lib-machdyn # print help message
+ make lib-machdyn args="-b" # download to lib/machdyn/eigen3
+ make lib-machdyn args="-p /usr/include/eigen3" # use existing Eigen installation in /usr/include/eigen3
+
+ Note that a symbolic (soft) link named ``includelink`` is created
+ in ``lib/machdyn`` to point to the Eigen dir. When LAMMPS builds it
+ will use this link. You should not need to edit the
+ ``lib/machdyn/Makefile.lammps`` file.
+
+----------
+
.. _mliap:
ML-IAP package
@@ -1431,6 +1476,55 @@ ML-POD package
----------
+.. _ml-quip:
+
+ML-QUIP package
+---------------------------------
+
+To build with this package, you must download and build the QUIP
+library. It can be obtained from GitHub. For support of GAP
+potentials, additional files with specific licensing conditions need
+to be downloaded and configured. The automatic download will from
+within CMake will download the non-commercial use version.
+
+.. tabs::
+
+ .. tab:: CMake build
+
+ .. code-block:: bash
+
+ -D DOWNLOAD_QUIP=value # download QUIP library for build, value = no (default) or yes
+ -D QUIP_LIBRARY=path # path to libquip.a (only needed if a custom location)
+ -D USE_INTERNAL_LINALG=value # Use the internal linear algebra library instead of LAPACK
+ # value = no (default) or yes
+
+ CMake will try to download and build the QUIP library from GitHub,
+ if it is not found on the local machine. This requires to have git
+ installed. It will use the same compilers and flags as used for
+ compiling LAMMPS. Currently this is only supported for the GNU
+ and the Intel compilers. Set the ``QUIP_LIBRARY`` variable if you
+ want to use a previously compiled and installed QUIP library and
+ CMake cannot find it.
+
+ The QUIP library requires LAPACK (and BLAS) and CMake can identify
+ their locations and pass that info to the QUIP build script. But
+ on some systems this triggers a (current) limitation of CMake and
+ the configuration will fail. Try enabling ``USE_INTERNAL_LINALG`` in
+ those cases to use the bundled linear algebra library and work around
+ the limitation.
+
+ .. tab:: Traditional make
+
+ The download/build procedure for the QUIP library, described in
+ ``lib/quip/README`` file requires setting two environment
+ variables, ``QUIP_ROOT`` and ``QUIP_ARCH``. These are accessed by
+ the ``lib/quip/Makefile.lammps`` file which is used when you
+ compile and link LAMMPS with this package. You should only need
+ to edit ``Makefile.lammps`` if the LAMMPS build can not use its
+ settings to successfully build on your system.
+
+----------
+
.. _plumed:
PLUMED package
@@ -1952,55 +2046,6 @@ verified to work in February 2020 with Quantum Espresso versions 6.3 to
----------
-.. _ml-quip:
-
-ML-QUIP package
----------------------------------
-
-To build with this package, you must download and build the QUIP
-library. It can be obtained from GitHub. For support of GAP
-potentials, additional files with specific licensing conditions need
-to be downloaded and configured. The automatic download will from
-within CMake will download the non-commercial use version.
-
-.. tabs::
-
- .. tab:: CMake build
-
- .. code-block:: bash
-
- -D DOWNLOAD_QUIP=value # download QUIP library for build, value = no (default) or yes
- -D QUIP_LIBRARY=path # path to libquip.a (only needed if a custom location)
- -D USE_INTERNAL_LINALG=value # Use the internal linear algebra library instead of LAPACK
- # value = no (default) or yes
-
- CMake will try to download and build the QUIP library from GitHub,
- if it is not found on the local machine. This requires to have git
- installed. It will use the same compilers and flags as used for
- compiling LAMMPS. Currently this is only supported for the GNU
- and the Intel compilers. Set the ``QUIP_LIBRARY`` variable if you
- want to use a previously compiled and installed QUIP library and
- CMake cannot find it.
-
- The QUIP library requires LAPACK (and BLAS) and CMake can identify
- their locations and pass that info to the QUIP build script. But
- on some systems this triggers a (current) limitation of CMake and
- the configuration will fail. Try enabling ``USE_INTERNAL_LINALG`` in
- those cases to use the bundled linear algebra library and work around
- the limitation.
-
- .. tab:: Traditional make
-
- The download/build procedure for the QUIP library, described in
- ``lib/quip/README`` file requires setting two environment
- variables, ``QUIP_ROOT`` and ``QUIP_ARCH``. These are accessed by
- the ``lib/quip/Makefile.lammps`` file which is used when you
- compile and link LAMMPS with this package. You should only need
- to edit ``Makefile.lammps`` if the LAMMPS build can not use its
- settings to successfully build on your system.
-
-----------
-
.. _scafacos:
SCAFACOS package
@@ -2048,50 +2093,6 @@ To build with this package, you must download and build the
----------
-.. _machdyn:
-
-MACHDYN package
--------------------------------
-
-To build with this package, you must download the Eigen3 library.
-Eigen3 is a template library, so you do not need to build it.
-
-.. tabs::
-
- .. tab:: CMake build
-
- .. code-block:: bash
-
- -D DOWNLOAD_EIGEN3 # download Eigen3, value = no (default) or yes
- -D EIGEN3_INCLUDE_DIR=path # path to Eigen library (only needed if a custom location)
-
- If ``DOWNLOAD_EIGEN3`` is set, the Eigen3 library will be
- downloaded and inside the CMake build directory. If the Eigen3
- library is already on your system (in a location where CMake
- cannot find it), set ``EIGEN3_INCLUDE_DIR`` to the directory the
- ``Eigen3`` include file is in.
-
- .. tab:: Traditional make
-
- You can download the Eigen3 library manually if you prefer; follow
- the instructions in ``lib/smd/README``. You can also do it in one
- step from the ``lammps/src`` dir, using a command like these,
- which simply invokes the ``lib/smd/Install.py`` script with the
- specified args:
-
- .. code-block:: bash
-
- make lib-smd # print help message
- make lib-smd args="-b" # download to lib/smd/eigen3
- make lib-smd args="-p /usr/include/eigen3" # use existing Eigen installation in /usr/include/eigen3
-
- Note that a symbolic (soft) link named ``includelink`` is created
- in ``lib/smd`` to point to the Eigen dir. When LAMMPS builds it
- will use this link. You should not need to edit the
- ``lib/smd/Makefile.lammps`` file.
-
-----------
-
.. _vtk:
VTK package
diff --git a/doc/src/Build_package.rst b/doc/src/Build_package.rst
index bc6445f813..63ccac534d 100644
--- a/doc/src/Build_package.rst
+++ b/doc/src/Build_package.rst
@@ -182,6 +182,7 @@ make a copy of one of them and modify it to suit your needs.
cmake -C ../cmake/presets/all_on.cmake [OPTIONS] ../cmake # enable all packages
cmake -C ../cmake/presets/all_off.cmake [OPTIONS] ../cmake # disable all packages
mingw64-cmake -C ../cmake/presets/mingw-cross.cmake [OPTIONS] ../cmake # compile with MinGW cross-compilers
+ cmake -C ../cmake/presets/macos-multiarch.cmake [OPTIONS] ../cmake # compile serial multi-arch binaries on macOS
Presets that have names starting with "windows" are specifically for
compiling LAMMPS :doc:`natively on Windows ` and
diff --git a/doc/src/Commands_fix.rst b/doc/src/Commands_fix.rst
index 5aabb7967c..7301d1345e 100644
--- a/doc/src/Commands_fix.rst
+++ b/doc/src/Commands_fix.rst
@@ -69,7 +69,7 @@ OPT.
* :doc:`drude/transform/inverse `
* :doc:`dt/reset (k) `
* :doc:`edpd/source `
- * :doc:`efield `
+ * :doc:`efield (k) `
* :doc:`efield/tip4p `
* :doc:`ehex `
* :doc:`electrode/conp (i) `
@@ -181,6 +181,7 @@ OPT.
* :doc:`pour `
* :doc:`precession/spin `
* :doc:`press/berendsen `
+ * :doc:`press/langevin `
* :doc:`print `
* :doc:`propel/self `
* :doc:`property/atom (k) `
@@ -232,7 +233,7 @@ OPT.
* :doc:`spring `
* :doc:`spring/chunk `
* :doc:`spring/rg `
- * :doc:`spring/self `
+ * :doc:`spring/self (k) `
* :doc:`srd `
* :doc:`store/force `
* :doc:`store/state `
diff --git a/doc/src/Commands_pair.rst b/doc/src/Commands_pair.rst
index c45a1d778c..923c040aaf 100644
--- a/doc/src/Commands_pair.rst
+++ b/doc/src/Commands_pair.rst
@@ -265,7 +265,7 @@ OPT.
* :doc:`smd/tri_surface `
* :doc:`smd/ulsph `
* :doc:`smtbq `
- * :doc:`snap (k) `
+ * :doc:`snap (ik) `
* :doc:`soft (go) `
* :doc:`sph/heatconduction `
* :doc:`sph/idealgas `
@@ -305,5 +305,5 @@ OPT.
* :doc:`wf/cut `
* :doc:`ylz `
* :doc:`yukawa (gko) `
- * :doc:`yukawa/colloid (go) `
+ * :doc:`yukawa/colloid (gko) `
* :doc:`zbl (gko) `
diff --git a/doc/src/Howto_lammps_gui.rst b/doc/src/Howto_lammps_gui.rst
index 4b89af53b7..165ed84d95 100644
--- a/doc/src/Howto_lammps_gui.rst
+++ b/doc/src/Howto_lammps_gui.rst
@@ -1,111 +1,310 @@
Using the LAMMPS GUI
====================
-LAMMPS GUI is a simple graphical text editor that is linked to the
-:ref:`LAMMPS C-library interface ` and thus can run LAMMPS
-directly using the contents of the editor's text buffer as input.
-
-This is similar to what people traditionally would do to run LAMMPS:
-using a regular text editor to edit the input and run the necessary
-commands, possibly including the text editor, too, from a command line
-terminal window. That is quite effective when running LAMMPS on
-high-performance computing facilities and when you are very proficient
-in using the command line. The main benefit of a GUI application is
-that this integrates well with graphical desktop environments and many
-basic tasks can be done directly from within the GUI without switching
-to a text console or requiring external programs or scripts to extract
-data from the generated output. This makes it easier for beginners to
-get started running simple LAMMPS simulations and thus very suitable for
-tutorials on LAMMPS. But also makes it easier to switch to a full
-featured text editor and more sophisticated visualization and analysis
-tools.
+This document describes **LAMMPS GUI version 1.5**.
-----
+LAMMPS GUI is a graphical text editor customized for editing LAMMPS
+input files that is linked to the :ref:`LAMMPS library `
+and thus can run LAMMPS directly using the contents of the editor's text
+buffer as input. It can retrieve and display information from LAMMPS
+while it is running, display visualizations created with the :doc:`dump
+image command `, and is adapted specifically for editing
+LAMMPS input files through text completion and reformatting, and linking
+to the online LAMMPS documentation for known LAMMPS commands and styles.
+
+.. note::
+
+ Pre-compiled, ready-to-use LAMMPS GUI executables for Linux (Ubuntu
+ 20.04LTS or later and compatible), macOS (version 11 aka Big Sur or
+ later), and Windows (version 10 or later) :ref:`are available
+ ` for download. They may be linked to a
+ development version of LAMMPS in case they need features not yet
+ available in a released version. Serial LAMMPS executables of the
+ same LAMMPS version are included as well. The source code for the
+ LAMMPS GUI is included in the LAMMPS source code and can be found in
+ the ``tools/lammps-gui`` folder. It can be compiled alongside LAMMPS
+ when :doc:`compiling with CMake `.
+
+LAMMPS GUI tries to provide an experience similar to what people
+traditionally would do to run LAMMPS using a command line window:
+
+- editing inputs with a text editor
+- run LAMMPS on the input with selected command line flags
+- and then use or extract data from the created files and visualize it
+
+That procedure is quite effective for people proficient in using the
+command line, as that allows them to use tools for the individual steps
+which they are most comfortable with. It is often required when running
+LAMMPS on high-performance computing facilities.
+
+The main benefit of using the LAMMPS GUI application instead is that
+many basic tasks can be done directly from the GUI without switching to
+a text console window or using external programs, let alone writing
+scripts to extract data from the generated output. It also integrates
+well with graphical desktop environments.
+
+LAMMPS GUI thus makes it easier for beginners to get started running
+simple LAMMPS simulations. It is very suitable for tutorials on LAMMPS
+since you only need to learn how to use a single program for most tasks
+and thus time can be saved and people can focus on learning LAMMPS. It
+is also designed to keep the barrier low when you decide to switch to a
+full featured, standalone programming editor and more sophisticated
+visualization and analysis tools and run LAMMPS from a command line.
+
The following text provides a detailed tour of the features and
-functionality of the LAMMPS GUI. This document describes LAMMPS GUI
-version 1.2.
+functionality of the LAMMPS GUI.
+
+Suggestions for new features and reports of bugs are always welcome.
+You can use the :doc:`the same channels as for LAMMPS itself
+` for that purpose.
+
+-----
Main window
-----------
-When LAMMPS GUI starts, it will show the main window with either an
-empty buffer, or have a file loaded. In the latter case it may look like
-the following:
+When LAMMPS GUI starts, it will show a main window with either an
+empty buffer or the contents of a loaded file. In the latter case it
+may look like the following:
.. image:: JPG/lammps-gui-main.png
:align: center
:scale: 50%
-There is the menu bar at the top, then the main editor buffer with the
-input file contents in the center with line numbers on the left and the
-input colored according to the LAMMPS input file syntax. At the bottom
-is the status bar, which shows the status of LAMMPS execution on the
-left ("Ready." when idle) and the current working directory on the
-right. The size of the main window will be stored when exiting and
-restored when starting again. The name of the current file in the
-buffer is shown in the window title and the text `*modified*` is added
-in case the buffer has modifications that are not yet saved to a file.
+There is the typical menu bar at the top, then the main editor buffer,
+and a status bar at the bottom. The input file contents are shown
+with line numbers on the left and the input is colored according to
+the LAMMPS input file syntax. The status bar shows the status of
+LAMMPS execution on the left (e.g. "Ready." when idle) and the current
+working directory on the right. The name of the current file in the
+buffer is shown in the window title; the word `*modified*` is added if
+the buffer edits have not yet saved to a file. The size of the main
+window will be stored when exiting and restored when starting again.
Opening Files
^^^^^^^^^^^^^
The LAMMPS GUI application will try to open the first command line
-argument as input file, further arguments are ignored. When no
-argument is given LAMMPS GUI will start with an empty buffer.
-Files can also be opened via the ``File`` menu or by drag-and-drop
-of a file from a file manager to the editor window. Only one
-file can be open at a time, so opening a new file with a filled
-buffer will close this buffer and in case the buffer has unsaved
-modifications will ask to either cancel the load, discard the
-changes or save them.
-
+argument as a LAMMPS input script, further arguments are ignored.
+When no argument is given, LAMMPS GUI will start with an empty buffer.
+Files can also be opened via the ``File`` menu or by drag-and-drop of
+a file from a graphical file manager into the editor window. Only one
+file can be open at a time, so opening a new file with a filled buffer
+will close the buffer. If the buffer has unsaved modifications, you
+will be asked to either cancel the operation, discard the changes, or
+save them.
Running LAMMPS
^^^^^^^^^^^^^^
From within the LAMMPS GUI main window LAMMPS can be started either from
-the ``Run`` menu, by the hotkey `Ctrl-Enter` (`Command-Enter` on macOS),
-or by clicking on the green button in the status bar. LAMMPS runs in a
-separate thread, so the GUI stays responsive and thus it is able to
-interact with the calculation and access its data. It is important to
-note, that LAMMPS is using the contents of the input buffer for the run,
-**not** the file it was read from. If there are unsaved changes in the
-buffer, they *will* be used.
+the ``Run`` menu using the ``Run LAMMPS from Editor Buffer`` entry, by
+the keyboard shortcut `Ctrl-Enter` (`Command-Enter` on macOS), or by
+clicking on the green "Run" button in the status bar. All of these
+operations will cause LAMMPS to process the entire input script, which
+may contain multiple :doc:`run ` or :doc:`minimize `
+commands.
+
+LAMMPS runs in a separate thread, so the GUI stays responsive and is
+able to interact with the running calculation and access data it
+produces. It is important to note that running LAMMPS this way is
+using the contents of the input buffer for the run (via the
+:cpp:func:`lammps_commands_string()` function of the LAMMPS C-library
+interface), and **not** the original file it was read from. Thus, if
+there are unsaved changes in the buffer, they *will* be used. As an
+alternative, it is also possible to run LAMMPS by reading the contents
+of a file from the ``Run LAMMPS from File`` menu entry or with
+`Ctrl-Shift-Enter`. This option may be required in some rare cases
+where the input uses some functionality that is not compatible with
+running LAMMPS from a string buffer. For consistency, any unsaved
+changes in the buffer must be either saved to the file or undone
+before LAMMPS can be run from a file.
.. image:: JPG/lammps-gui-running.png
:align: center
:scale: 75%
-While LAMMPS is running, the contents of the status bar change: on the
-left side there is a text indicating that LAMMPS is running, which will
-contain the selected number of threads, if thread-parallel acceleration
-was selected in the ``Preferences`` dialog. On the right side, a
-progress bar is shown that displays the estimated progress on the
-current :doc:`run command `. Additionally, two windows will open:
-the log window with the captured screen output and the chart window with
-a line graph created from the thermodynamic output of the run.
+While LAMMPS is running, the contents of the status bar change. On
+the left side there is a text indicating that LAMMPS is running, which
+will also show the number of active threads, if thread-parallel
+acceleration was selected in the ``Preferences`` dialog. On the right
+side, a progress bar is shown that displays the estimated progress for
+the current :doc:`run command `.
-The run can be stopped cleanly by using either the ``Stop LAMMPS`` entry
-in the ``Run`` menu, the hotkey `Ctrl-/` (`Command-/` on macOS), or
-clicking on the red button in the status bar. This will cause that the
-running LAMMPS process will complete the current iteration and then
-stop. This is equivalent to the command :doc:`timer timeout 0 `
-and implemented by calling the :cpp:func:`lammps_force_timeout()`
-function of the LAMMPS C-library interface.
+Also, the line number of the currently executed command will be
+highlighted in green.
+.. image:: JPG/lammps-gui-run-highlight.png
+ :align: center
+ :scale: 75%
+
+If an error occurs (in the example below the command :doc:`label
+` was incorrectly capitalized as "Label"), an error message
+dialog will be shown and the line of the input which triggered the
+error will be highlighted. The state of LAMMPS in the status bar will
+be set to "Failed." instead of "Ready."
+
+.. image:: JPG/lammps-gui-run-error.png
+ :align: center
+ :scale: 75%
+
+Up to three additional windows will open during a run:
+
+- a log window with the captured screen output
+- a chart window with a line graph created from the thermodynamic output of the run
+- a slide show window with images created by a :doc:`dump image command `
+
+More information on those windows and how to adjust their behavior and
+contents is given below.
+
+An active LAMMPS run can be stopped cleanly by using either the ``Stop
+LAMMPS`` entry in the ``Run`` menu, the keyboard shortcut `Ctrl-/`
+(`Command-/` on macOS), or by clicking on the red button in the status
+bar. This will cause the running LAMMPS process to complete the current
+timestep (or iteration for energy minimization) and then complete the
+processing of the buffer while skipping all run or minimize commands.
+This is equivalent to the input script command :doc:`timer timeout 0
+` and is implemented by calling the
+:cpp:func:`lammps_force_timeout()` function of the LAMMPS C-library
+interface. Please see the corresponding documentation pages to
+understand the implications of this operation.
+
+Log Window
+----------
+
+By default, when starting a run, a "Log Window" will open that displays
+the current screen output of the LAMMPS calculation, that would normally
+be seen in the command line window, as shown below.
+
+.. image:: JPG/lammps-gui-log.png
+ :align: center
+ :scale: 50%
+
+LAMMPS GUI captures the screen output as it is generated and updates
+the log window regularly during a run.
+
+By default, the log window will be replaced each time a run is started.
+The runs are counted and the run number for the current run is displayed
+in the window title. It is possible to change the behavior of LAMMPS
+GUI in the preferences dialog to create a *new* log window for every run
+or to not show the current log window. It is also possible to show or
+hide the *current* log window from the ``View`` menu.
+
+The text in the log window is read-only and cannot be modified, but
+keyboard shortcuts to select and copy all or parts of the text can be
+used to transfer text to another program. Also, the keyboard shortcut
+`Ctrl-S` (`Command-S` on macOS) is available to save the log buffer to a
+file. The "Select All" and "Copy" functions, as well as a "Save Log to
+File" option are also available from a context menu by clicking with the
+right mouse button into the log window text area.
+
+Chart Window
+------------
+
+By default, when starting a run, a "Chart Window" will open that
+displays a plot of thermodynamic output of the LAMMPS calculation as
+shown below.
+
+.. image:: JPG/lammps-gui-chart.png
+ :align: center
+ :scale: 50%
+
+The drop down menu on the top right allows selection of different
+properties that are computed and written to thermo output. Only one
+property can be shown at a time. The plots will be updated with new
+data as the run progresses, so they can be used to visually monitor the
+evolution of available properties. The window title will show the
+current run number that this chart window corresponds to. Same as
+explained for the log window above, by default, the chart window will
+be replaced on each new run, but the behavior can be changed in the
+preferences dialog.
+
+From the ``File`` menu on the top left, it is possible to save an image
+of the currently displayed plot or export the data in either plain text
+columns (for use by plotting tools like `gnuplot
+ `_ or `grace
+ `_), or as CSV data which can
+be imported for further processing with Microsoft Excel or `pandas
+ `_
+
+Thermo output data from successive run commands in the input script will
+be combined into a single data set unless the format, number, or names
+of output columns are changed with a :doc:`thermo_style `
+or a :doc:`thermo_modify ` command, or the current time
+step is reset with :doc:`reset_timestep `, or if a
+:doc:`clear ` command is issued.
+
+Image Slide Show
+----------------
+
+By default, if the LAMMPS input contains a :doc:`dump image
+` command, a "Slide Show" window will open which loads and
+displays the images created by LAMMPS as they are written.
+
+.. image:: JPG/lammps-gui-slideshow.png
+ :align: center
+ :scale: 50%
+
+The various buttons at the bottom right of the window allow single
+stepping through the sequence of images or playing an animation (as a
+continuous loop or once from first to last). It is also possible to
+zoom in or zoom out of the displayed images, and to export the slide
+show animation to a movie file, if `ffmpeg `_ is
+installed.
+
+Variable Info
+-------------
+
+During a run, it may be of interest to monitor the value of input script
+variables, for example to monitor the progress of loops. This can be
+done by enabling the "Variables Window" in the ``View`` menu or by using
+the `Ctrl-Shift-W` keyboard shortcut. This will show info similar to
+the :doc:`info variables ` command in a separate window as shown
+below.
+
+.. image:: JPG/lammps-gui-variable-info.png
+ :align: center
+ :scale: 75%
+
+Like the log and chart windows, its content is continuously updated
+during a run. It will show "(none)" if there are no variables
+defined. Note that it is also possible to *set* :doc:`index style
+variables `, that would normally be set via command line
+flags, via the "Set Variables..." dialog from the ``Run`` menu.
+LAMMPS GUI will automatically set the variable "gui_run" to the
+current value of the run counter. That way it would be possible
+to automatically record a log for each run attempt by using the
+command
+
+.. code-block:: LAMMPS
+
+ log logfile-${gui_run}.txt
+
+at the beginning of an input file. That would record logs to files
+``logfile-1.txt``, ``logfile-2.txt``, and so on for successive runs.
Viewing Snapshot Images
-^^^^^^^^^^^^^^^^^^^^^^^
+-----------------------
-By selecting the ``View Image`` entry in the ``Run`` menu, by hitting
-the `Ctrl-I` (`Command-I` on macOS) hotkey or by clicking on the
-"palette" button in the status bar, LAMMPS GUI will issue a
-:doc:`write_dump image ` command and read the resulting
-snapshot image into an image viewer window. When possible, LAMMPS
-GUI will try to detect which elements the atoms correspond to (via
-their mass) and then colorize them accordingly. Otherwise just some
-predefined sequence of colors are assigned to different atom types.
+By selecting the ``Create Image`` entry in the ``Run`` menu, or by
+hitting the `Ctrl-I` (`Command-I` on macOS) keyboard shortcut, or by
+clicking on the "palette" button in the status bar, LAMMPS GUI will send
+a custom :doc:`write_dump image ` command to LAMMPS and read
+the resulting snapshot image with the current state of the system into
+an image viewer window. This functionality is not available *during* an
+ongoing run. When LAMMPS is not yet initialized, LAMMPS GUI will try to
+identify the line with the first run or minimize command and execute all
+command up to that line from the input buffer and then add a "run 0"
+command. This will initialize the system so an image of the initial
+state of the system can be rendered. If there was an error, the
+snapshot image viewer will not appear.
+
+When possible, LAMMPS GUI will try to detect which elements the atoms
+correspond to (via their mass) and then colorize them in the image
+accordingly. Otherwise the default predefined sequence of colors is
+assigned to the different atom types.
.. image:: JPG/lammps-gui-image.png
:align: center
@@ -114,28 +313,68 @@ predefined sequence of colors are assigned to different atom types.
The default image size, some default image quality settings, the view
style and some colors can be changed in the ``Preferences`` dialog
window. From the image viewer window further adjustments can be made:
-actual image size, high-quality rendering, anti-aliasing, view style,
-display of box or axes, zoom factor. The the image can be rotated
-horizontally and vertically and it is possible to only display the atoms
-within a predefined group (default is "all"). After each change, the
-image is rendered again and the display updated. The small palette icon
-on the top left will be colored while LAMMPS is running to render the
-image and it will be grayed out again, when it is done. When there are
-many items to show and high quality images with anti-aliasing are
-requested, re-rendering can take several seconds. From the ``File``
-menu, the shown image can be saved to a file permanently or copied into
-the cut-n-paste buffer for pasting into another application.
-
+actual image size, high-quality (SSAO) rendering, anti-aliasing, view
+style, display of box or axes, zoom factor. The view of the system
+can be rotated horizontally and vertically. It is also possible to
+only display the atoms within a group defined in the input script
+(default is "all"). After each change, the image is rendered again
+and the display updated. The small palette icon on the top left will
+be colored while LAMMPS is running to render the new image; it will be
+grayed out when it is finished. When there are many atoms to render
+and high quality images with anti-aliasing are requested, re-rendering
+may take several seconds. From the ``File`` menu of the image window,
+the current image can be saved to a file or copied into the
+cut-n-paste buffer for pasting into another application.
Editor Functions
-^^^^^^^^^^^^^^^^
+----------------
-The editor has most the usual functionality that similar programs have:
-text selection via mouse or with cursor moves while holding the Shift
-key, Cut, Copy, Paste, Undo, Redo. All of these editing functions are
-available via hotkeys. When trying to exit the editor with a modified
-buffer, a dialog will pop up asking whether to cancel the quit, or don't
-save or save the buffer's contents to a file.
+The editor has most of the usual functionality that similar programs
+have: text selection via mouse or with cursor moves while holding the
+Shift key, Cut (`Ctrl-X`), Copy (`Ctrl-C`), Paste (`Ctrl-V`), Undo
+(`Ctrl-Z`), Redo (`Ctrl-Shift-Z`), Select All (`Ctrl-A`). When trying
+to exit the editor with a modified buffer, a dialog will pop up asking
+whether to cancel the exit operation, or to save or not save the buffer
+contents to a file.
+
+Context Specific Word Completion
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+By default, LAMMPS GUI will display a small pop-up frame with possible
+choices for LAMMPS input script commands or styles after 2 characters of
+a word have been typed.
+
+.. image:: JPG/lammps-gui-complete.png
+ :align: center
+ :scale: 75%
+
+The word can then be completed through selecting an entry by scrolling
+up and down with the cursor keys and selecting with the 'Enter' key or
+by clicking on the entry with the mouse. The automatic completion
+pop-up can be disabled in the ``Preferences`` dialog, but the completion
+can still be requested manually by either hitting the 'Shift-TAB' key or
+by right-clicking with the mouse and selecting the option from the
+context menu. Most of the completion information is taken from the
+LAMMPS instance and thus it will be adjusted to only show available
+options that have been enabled while compiling LAMMPS. That, however,
+excludes accelerated styles and commands; for improved clarity, only the
+non-suffix version of styles are shown.
+
+Line Reformatting
+^^^^^^^^^^^^^^^^^
+
+The editor supports reformatting lines according to the syntax in order
+to have consistently aligned lines. This primarily means adding
+whitespace padding to commands, type specifiers, IDs and names. This
+reformatting is performed by default when hitting the 'Enter' key to
+start a new line. This feature can be turned on or off in the
+``Preferences`` dialog, but it can still be manually performed by
+hitting the 'TAB' key. The amount of padding can also be changed in the
+``Preferences`` dialog.
+
+Internally this functionality is achieved by splitting the line into
+"words" and then putting it back together with padding added where the
+context can be detected; otherwise a single space is used between words.
Context Specific Help
^^^^^^^^^^^^^^^^^^^^^
@@ -145,22 +384,23 @@ Context Specific Help
:scale: 50%
A unique feature of the LAMMPS GUI is the option to look up the
-documentation for the command in the current line. This can be achieved
-by either clicking the right mouse button or by using the `Ctrl-?`
-hotkey. When clicking the mouse there are additional entries in the
+documentation for the command in the current line. This can be done by
+either clicking the right mouse button or by using the `Ctrl-?` keyboard
+shortcut. When clicking the mouse there are additional entries in the
context menu that will open the corresponding documentation page in the
-online LAMMPS documentation. When using the hotkey, the first of those
-entries will be chosen directly.
+online LAMMPS documentation. When using the keyboard, the first of
+those entries will be chosen directly.
Menu
----
-The menu bar the entries ``File``, ``Edit``, ``Run``, ``View``, and ``About``.
-Instead of using the mouse to click on them, the individual menus can also
-be activated by hitting the `Alt` key together with the corresponding underlined
-letter, that is `Alt-f` will activate the ``File`` menu. For the corresponding
-activated sub-menus, also the underlined letter, together with the `Alt` key can
-be used to select instead of the mouse.
+The menu bar has entries ``File``, ``Edit``, ``Run``, ``View``, and
+``About``. Instead of using the mouse to click on them, the individual
+menus can also be activated by hitting the `Alt` key together with the
+corresponding underlined letter, that is `Alt-F` will activate the
+``File`` menu. For the corresponding activated sub-menus, the key
+corresponding the underlined letters can again be used to select entries
+instead of using the mouse.
File
^^^^
@@ -174,104 +414,121 @@ The ``File`` menu offers the usual options:
- ``Save As`` will open a dialog to select and new file name and save
the buffer to it
- ``Quit`` will exit LAMMPS GUI. If there are unsaved changes, a dialog
- will appear to either cancel the quit, save or don't save the file.
+ will appear to either cancel the operation, or to save or not save the
+ edited file.
-In addition, up to 5 recent file names will be listed after the ``Open``
-entry that allows to re-open recent files. This list is stored when
-quitting and recovered when starting again.
+In addition, up to 5 recent file names will be listed after the
+``Open`` entry that allows re-opening recent files. This list is
+stored when quitting and recovered when starting again.
Edit
^^^^
The ``Edit`` menu offers the usual editor functions like ``Undo``,
-``Redo``, ``Cut``, ``Copy``, ``Paste``, but also offers to open the
-``Preferences`` dialog and to delete all stored preferences so they
-will be reset to their defaults.
+``Redo``, ``Cut``, ``Copy``, ``Paste``. It can also open a
+``Preferences`` dialog (keyboard shortcut `Ctrl-P`) and allows deletion
+of all stored preferences so they will be reset to default values.
Run
^^^
-The ``Run`` menu allows to start and stop a LAMMPS process. Rather than
-calling the LAMMPS executable as a separate executable, the LAMMPS GUI
-is linked to the LAMMPS library and thus can run LAMMPS internally
-through the :ref:`LAMMPS C-library interface `.
+The ``Run`` menu has options to start and stop a LAMMPS process.
+Rather than calling the LAMMPS executable as a separate executable,
+the LAMMPS GUI is linked to the LAMMPS library and thus can run LAMMPS
+internally through the :ref:`LAMMPS C-library interface
+`.
+
Specifically, a LAMMPS instance will be created by calling
-:cpp:func:`lammps_open_no_mpi` and then the buffer contents run by
+:cpp:func:`lammps_open_no_mpi`. The buffer contents then executed by
calling :cpp:func:`lammps_commands_string`. Certain commands and
-features are only available, after a LAMMPS instance is created. Its
-presence is indicated by a small LAMMPS ``L`` logo in the status bar at
-the bottom left of the main window.
+features are only available after a LAMMPS instance is created. Its
+presence is indicated by a small LAMMPS ``L`` logo in the status bar
+at the bottom left of the main window. As an alternative, it is also
+possible to run LAMMPS using the contents of the edited file by
+reading the file. This is mainly provided as a fallback option in
+case the input uses some feature that is not available when running
+from a string buffer.
The LAMMPS calculation will be run in a concurrent thread so that the
-GUI will stay responsive and will be updated during the run. This can
-be used to tell the running LAMMPS instance to stop at the next
-timestep. The ``Stop LAMMPS`` entry will do this by calling
+GUI can stay responsive and be updated during the run. This can be
+used to tell the running LAMMPS instance to stop at the next timestep.
+The ``Stop LAMMPS`` entry will do this by calling
:cpp:func:`lammps_force_timeout`, which is equivalent to a :doc:`timer
timeout 0 ` command.
-The ``Set Variables`` entry will open a dialog box where :doc:`index style variables `
-can be set. Those variables will be passed to the LAMMPS instance when
-it is created and are thus set *before* a run is started.
+The ``Set Variables...`` entry will open a dialog box where
+:doc:`index style variables ` can be set. Those variables
+will be passed to the LAMMPS instance when it is created and are thus
+set *before* a run is started.
.. image:: JPG/lammps-gui-variables.png
:align: center
:scale: 75%
-The ``Set Variables`` dialog will be pre-populated with entries that are
-set as index variables in the input and any variables that are used but
-not defined as far as the built-in parser can detect them. New rows for
-additional variables can be added through the ``Add Row`` button and
-existing rows deleted by clicking on the ``X`` icons on the right.
+The ``Set Variables`` dialog will be pre-populated with entries that
+are set as index variables in the input and any variables that are
+used but not defined, if the built-in parser can detect them. New
+rows for additional variables can be added through the ``Add Row``
+button and existing rows can be deleted by clicking on the ``X`` icons
+on the right.
-The ``View Image`` entry will send a :doc:`dump image `
-command to the LAMMPS instance, read the resulting file, and show it in
-an ``Image Viewer`` window.
+The ``Create Image`` entry will send a :doc:`dump image `
+command to the LAMMPS instance, read the resulting file, and show it
+in an ``Image Viewer`` window.
The ``View in OVITO`` entry will launch `OVITO `_
-with a :doc:`data file ` of the current state of the system.
-This option is only available, if the LAMMPS GUI can find the OVITO
-executable in the system path.
+with a :doc:`data file ` containing the current state of
+the system. This option is only available if the LAMMPS GUI can find
+the OVITO executable in the system path.
-The ``View in VMD`` entry will instead launch VMD, also to load a
-:doc:`data file ` of the current state of the system. This
-option is only available, if the LAMMPS GUI can find the VMD executable
-in the system path.
+The ``View in VMD`` entry will launch VMD with a :doc:`data file
+` containing the current state of the system. This option
+is only available if the LAMMPS GUI can find the VMD executable in the
+system path.
View
^^^^
-The ``View`` menu offers to show or hide the three optional windows
-with log output, graphs, or images. The default settings for those
-can be changed in the ``Preferences dialog``.
+The ``View`` menu offers to show or hide additional windows with log
+output, charts, slide show, variables, or snapshot images. The
+default settings for their visibility can be changed in the
+``Preferences dialog``.
About
^^^^^
The ``About`` menu finally offers a couple of dialog windows and an
-option to launch the LAMMPS online documentation in a web browser. The
-``About LAMMPS GUI`` entry displays a dialog with a summary of the
+option to launch the LAMMPS online documentation in a web browser.
+The ``About LAMMPS`` entry displays a dialog with a summary of the
configuration settings of the LAMMPS library in use and the version
-number of LAMMPS GUI itself. The ``Quick Help`` displays a dialog with
-a minimal description of LAMMPS GUI. And ``LAMMPS Manual`` will open
-the main page of this LAMMPS documentation at https://docs.lammps.org/.
+number of LAMMPS GUI itself. The ``Quick Help`` displays a dialog
+with a minimal description of LAMMPS GUI. The ``LAMMPS GUI Howto``
+entry will open this documentation page from the online documentation
+in a web browser window. The ``LAMMPS Manual`` entry will open the
+main page of the LAMMPS documentation in the web browser.
+
+-----
Preferences
-----------
-The ``Preferences`` dialog allows to customize some of the behavior
-and looks of the LAMMPS GUI application. The settings are grouped
-and each group is displayed within a tab.
+The ``Preferences`` dialog allows customization of the behavior and
+look of the LAMMPS GUI application. The settings are grouped and each
+group is displayed within a tab.
.. |guiprefs1| image:: JPG/lammps-gui-prefs-general.png
- :width: 25%
+ :width: 24%
.. |guiprefs2| image:: JPG/lammps-gui-prefs-accel.png
- :width: 25%
+ :width: 24%
.. |guiprefs3| image:: JPG/lammps-gui-prefs-image.png
- :width: 25%
+ :width: 24%
-|guiprefs1| |guiprefs2| |guiprefs3|
+.. |guiprefs4| image:: JPG/lammps-gui-prefs-editor.png
+ :width: 24%
+
+|guiprefs1| |guiprefs2| |guiprefs3| |guiprefs4|
General Settings:
^^^^^^^^^^^^^^^^^
@@ -279,7 +536,7 @@ General Settings:
- *Echo input to log:* when checked, all input commands, including
variable expansions, will be echoed to the log window. This is
equivalent to using `-echo screen` at the command line. There is no
- log *file* produced since it always uses `-log none`.
+ log *file* produced by default, since LAMMPS GUI uses `-log none`.
- *Include citation details:* when checked full citation info will be
included to the log window. This is equivalent to using `-cite
screen` on the command line.
@@ -288,6 +545,9 @@ General Settings:
- *Show chart window by default:* when checked, the thermodynamic
output of a LAMMPS run will be collected and displayed in a chart
window as line graphs.
+- *Show slide show window by default:* when checked, a slide show
+ window will be shown with images from a dump image command, if
+ present, in the LAMMPS input.
- *Replace log window on new run:* when checked, an existing log
window will be replaced on a new LAMMPS run, otherwise each run will
create a new log window.
@@ -297,7 +557,7 @@ General Settings:
- *Replace image window on new render:* when checked, an existing
chart window will be replaced when a new snapshot image is requested,
otherwise each command will create a new image window.
-- *Path to LAMMPS Shared Library File:* this options is only available
+- *Path to LAMMPS Shared Library File:* this option is only visible
when LAMMPS GUI was compiled to load the LAMMPS library at run time
instead of being linked to it directly. With the ``Browse..`` button
or by changing the text, a different shared library file with a
@@ -309,94 +569,132 @@ General Settings:
log) of the application can be set.
- *Select Text Font:* Opens a font selection dialog where the type and
size for the text editor and log font of the application can be set.
+- *GUI update interval:* Allows to set the time interval between GUI
+ and data updates during a LAMMPS run in milliseconds. The default is
+ to update the GUI every 100 milliseconds. This is good for most cases.
+ For LAMMPS runs that run very fast, however, data may be missed and
+ through lowering this interval, this can be corrected. However, this
+ will make the GUI use more resources, which may be a problem on some
+ computers with slower CPUs. The default value is 100 milliseconds.
Accelerators:
^^^^^^^^^^^^^
-This tab enables to select which accelerator package is used and is
-equivalent to using the `-suffix` and `-package` flags on the command
-line. Only settings supported by the LAMMPS library and local hardware
-are available. The `Number of threads` field allows to set the maximum
-number of threads for the accelerator packages that use threads.
+This tab enables selection of an accelerator package for LAMMPS to use
+and is equivalent to using the `-suffix` and `-package` flags on the
+command line. Only settings supported by the LAMMPS library and local
+hardware are available. The `Number of threads` field allows setting
+the maximum number of threads for the accelerator packages that use
+threads.
Snapshot Image:
^^^^^^^^^^^^^^^
-This tab allows to set some defaults for the snapshot images displayed
-in the ``Image Viewer`` window, like its dimensions and the zoom factor
-applied. The *Antialias* switch requests to render images with twice
-the number of pixels for width and height and then smoothly scales the
+This tab allows setting defaults for the snapshot images displayed in
+the ``Image Viewer`` window, such as its dimensions and the zoom
+factor applied. The *Antialias* switch will render images with twice
+the number of pixels for width and height and then smoothly scale the
image back to the requested size. This produces higher quality images
-with smoother edges at the expense of requiring more CPU time to render
-the image. The *HQ Image mode* option turns on using a screen space
-ambient occlusion mode (SSAO) when rendering images. This is also more
-time consuming, but produces a more 'spatial' representation of the
-system. The *VDW Style* checkbox selects whether atoms are represented
-by space filling spheres when checked or by smaller spheres and stick.
-Finally there are a couple of drop down lists to select the background
-and box color.
+with smoother edges at the expense of requiring more CPU time to
+render the image. The *HQ Image mode* option turns on screen space
+ambient occlusion (SSAO) mode when rendering images. This is also
+more time consuming, but produces a more 'spatial' representation of
+the system shading of atoms by their depth. The *VDW Style* checkbox
+selects whether atoms are represented by space filling spheres when
+checked or by smaller spheres and sticks. Finally there are a couple
+of drop down lists to select the background and box colors.
+Editor Settings:
+^^^^^^^^^^^^^^^^
-Hotkeys
--------
+This tab allows tweaking settings of the editor window. Specifically
+the amount of padding to be added to LAMMPS commands, types or type
+ranges, IDs (e.g. for fixes), and names (e.g. for groups). The value
+set is the minimum width for the text element and it can be chosen in
+the range between 1 and 32.
-Almost all functionality is accessible from the menu or via hotkeys.
-The following hotkeys are available (On macOS use the Command key
-instead of Ctrl/Control).
+The two settings which follow enable or disable the automatic
+reformatting when hitting the 'Enter' key and the automatic display of
+the completion pop-up window.
+
+-----------
+
+Keyboard Shortcuts
+------------------
+
+Almost all functionality is accessible from the menu of the editor
+window or through keyboard shortcuts. The following shortcuts are
+available (On macOS use the Command key instead of Ctrl/Control).
.. list-table::
:header-rows: 1
:widths: auto
- * - Hotkey
+ * - Shortcut
- Function
- - Hotkey
+ - Shortcut
- Function
- - Hotkey
- - Function
- - Hotkey
+ - Shortcut
- Function
* - Ctrl+N
- New File
- Ctrl+Z
- Undo edit
- Ctrl+Enter
- - Run LAMMPS
- - Ctrl+Shift+A
- - About LAMMPS GUI
+ - Run Input
* - Ctrl+O
- Open File
- Ctrl+Shift+Z
- Redo edit
- Ctrl+/
- Stop Active Run
- - Ctrl+Shift+H
- - Quick Help
- * - CTRL+S
+ * - Ctrl+S
- Save File
- Ctrl+C
- Copy text
- Ctrl+Shift+V
- Set Variables
- - Ctrl+Shift+G
- - LAMMPS GUI Howto
* - Ctrl+Shift+S
- Save File As
- Ctrl+X
- Cut text
- Ctrl+I
- - Create Snapshot Image
- - Ctrl+Shift+M
- - LAMMPS Manual
+ - Snapshot Image
* - Ctrl+Q
- - Quit
+ - Quit Application
- Ctrl+V
- Paste text
+ - Ctrl+L
+ - Slide Show
+ * - Ctrl+W
+ - Close Window
+ - Ctrl+A
+ - Select All
- Ctrl+P
- Preferences
+ * - Ctrl+Shift+A
+ - About LAMMPS
+ - Ctrl+Shift+H
+ - Quick Help
+ - Ctrl+Shift+G
+ - LAMMPS GUI Howto
+ * - Ctrl+Shift+M
+ - LAMMPS Manual
- Ctrl+?
- Context Help
+ - Ctrl+Shift+W
+ - Show Variables
+ * - Ctrl+Shift+Enter
+ - Run File
+ - TAB
+ - Reformat line
+ - Shift+TAB
+ - Show Completions
Further editing keybindings `are documented with the Qt documentation
`_. In
case of conflicts the list above takes precedence.
+
+All other windows only support a subset of keyboard shortcuts listed
+above. Typically, the shortcuts `Ctrl-/` (Stop Run), `Ctrl-W` (Close
+Window), and `Ctrl-Q` (Quit Application) are supported.
diff --git a/doc/src/Howto_output.rst b/doc/src/Howto_output.rst
index 851b7703fd..6fcd36ab56 100644
--- a/doc/src/Howto_output.rst
+++ b/doc/src/Howto_output.rst
@@ -1,7 +1,7 @@
Output from LAMMPS (thermo, dumps, computes, fixes, variables)
==============================================================
-There are four basic kinds of LAMMPS output:
+There are four basic forms of LAMMPS output:
* :doc:`Thermodynamic output `, which is a list of
quantities printed every few timesteps to the screen and logfile.
@@ -20,18 +20,17 @@ output files, depending on what :doc:`dump ` and :doc:`fix `
commands you specify.
As discussed below, LAMMPS gives you a variety of ways to determine
-what quantities are computed and printed when the thermodynamics,
+what quantities are calculated and printed when the thermodynamics,
dump, or fix commands listed above perform output. Throughout this
discussion, note that users can also :doc:`add their own computes and
-fixes to LAMMPS ` which can then generate values that can then
-be output with these commands.
+fixes to LAMMPS ` which can generate values that can then be
+output with these commands.
The following subsections discuss different LAMMPS commands related
to output and the kind of data they operate on and produce:
* :ref:`Global/per-atom/local/per-grid data `
* :ref:`Scalar/vector/array data `
-* :ref:`Per-grid data `
* :ref:`Disambiguation `
* :ref:`Thermodynamic output `
* :ref:`Dump file output `
@@ -48,34 +47,65 @@ to output and the kind of data they operate on and produce:
Global/per-atom/local/per-grid data
-----------------------------------
-Various output-related commands work with four different styles of
+Various output-related commands work with four different "styles" of
data: global, per-atom, local, and per-grid. A global datum is one or
more system-wide values, e.g. the temperature of the system. A
per-atom datum is one or more values per atom, e.g. the kinetic energy
of each atom. Local datums are calculated by each processor based on
-the atoms it owns, but there may be zero or more per atom, e.g. a list
+the atoms it owns, and there may be zero or more per atom, e.g. a list
of bond distances.
A per-grid datum is one or more values per grid cell, for a grid which
-overlays the simulation domain. The grid cells and the data they
-store are distributed across processors; each processor owns the grid
-cells whose center point falls within its subdomain.
+overlays the simulation domain. Similar to atoms and per-atom data,
+the grid cells and the data they store are distributed across
+processors; each processor owns the grid cells whose center points
+fall within its subdomain.
.. _scalar:
Scalar/vector/array data
------------------------
-Global, per-atom, and local datums can come in three kinds: a single
-scalar value, a vector of values, or a 2d array of values. The doc
-page for a "compute" or "fix" or "variable" that generates data will
-specify both the style and kind of data it produces, e.g. a per-atom
-vector.
+Global, per-atom, local, and per-grid datums can come in three
+"kinds": a single scalar value, a vector of values, or a 2d array of
+values. More specifically these are the valid kinds for each style:
-When a quantity is accessed, as in many of the output commands
-discussed below, it can be referenced via the following bracket
-notation, where ID in this case is the ID of a compute. The leading
-"c\_" would be replaced by "f\_" for a fix, or "v\_" for a variable:
+* global scalar
+* global vector
+* global array
+* per-atom vector
+* per-atom array
+* local vector
+* local array
+* per-grid vector
+* per-grid array
+
+A per-atom vector means a single value per atom; the "vector" is the
+length of the number of atoms. A per-atom array means multiple values
+per atom. Similarly a local vector or array means one or multiple
+values per entity (e.g. per bond in the system). And a per-grid
+vector or array means one or multiple values per grid cell.
+
+The doc page for a compute or fix or variable that generates data will
+specify both the styles and kinds of data it produces, e.g. a per-atom
+vector. Note that a compute or fix may generate multiple styles and
+kinds of output. However, for per-atom data only a vector or array is
+output, never both. Likewise for per-local and per-grid data. An
+example of a fix which generates multiple styles and kinds of data is
+the :doc:`fix mdi/qm ` command. It outputs a global
+scalar, global vector, and per-atom array for the quantum mechanical
+energy and virial of the system and forces on each atom.
+
+By contrast, different variable styles generate only a single kind of
+data: a global scalar for an equal-style variable, global vector for a
+vector-style variable, and a per-atom vector for an atom-style
+variable.
+
+When data is accessed by another command, as in many of the output
+commands discussed below, it can be referenced via the following
+bracket notation, where ID in this case is the ID of a compute. The
+leading "c\_" would be replaced by "f\_" for a fix, or "v\_" for a
+variable (and ID would be the name of the variable):
+-------------+--------------------------------------------+
| c_ID | entire scalar, vector, or array |
@@ -85,40 +115,56 @@ notation, where ID in this case is the ID of a compute. The leading
| c_ID[I][J] | one element of array |
+-------------+--------------------------------------------+
-In other words, using one bracket reduces the dimension of the data
-once (vector -> scalar, array -> vector). Using two brackets reduces
-the dimension twice (array -> scalar). Thus a command that uses
-scalar values as input can typically also process elements of a vector
-or array.
+Note that using one bracket reduces the dimension of the data once
+(vector -> scalar, array -> vector). Using two brackets reduces the
+dimension twice (array -> scalar). Thus a command that uses scalar
+values as input can also conceptually operate on an element of a
+vector or array.
-.. _grid:
-
-Per-grid data
-------------------------
-
-Per-grid data can come in two kinds: a vector of values (one per grid
-cekk), or a 2d array of values (multiple values per grid ckk). The
-doc page for a "compute" or "fix" that generates data will specify
-names for both the grid(s) and datum(s) it produces, e.g. per-grid
-vectors or arrays, which can be referenced by other commands. See the
-:doc:`Howto grid ` doc page for more details.
+Per-grid vectors or arrays are accessed similarly, except that the ID
+for the compute or fix includes a grid name and a data name. This is
+because a fix or compute can create multiple grids (of different
+sizes) and multiple sets of data (for each grid). The fix or compute
+defines names for each grid and for each data set, so that all of them
+can be accessed by other commands. See the :doc:`Howto grid
+` doc page for more details.
.. _disambiguation:
Disambiguation
--------------
-Some computes and fixes produce data in multiple styles, e.g. a global
-scalar and a per-atom vector. Usually the context in which the input
-script references the data determines which style is meant. Example:
-if a compute provides both a global scalar and a per-atom vector, the
-former will be accessed by using ``c_ID`` in an equal-style variable,
-while the latter will be accessed by using ``c_ID`` in an atom-style
-variable. Note that atom-style variable formulas can also access
-global scalars, but in this case it is not possible to do this
-directly because of the ambiguity. Instead, an equal-style variable
-can be defined which accesses the global scalar, and that variable can
-be used in the atom-style variable formula in place of ``c_ID``.
+When a compute or fix produces data in multiple styles, e.g. global
+and per-atom, a reference to the data can sometimes be ambiguous.
+Usually the context in which the input script references the data
+determines which style is meant.
+
+For example, if a compute outputs a global vector and a per-atom
+array, an element of the global vector will be accessed by using
+``c_ID[I]`` in :doc:`thermodynamic output `, while a
+column of the per-atom array will be accessed by using ``c_ID[I]`` in
+a :doc:`dump custom ` command.
+
+However, if a :doc:`atom-style variable ` references
+``c_ID[I]``, then it could be intended to refer to a single element of
+the global vector or a column of the per-atom array. The doc page for
+any command that has a potential ambiguity (variables are the most
+common) will explain how to resolve the ambiguity.
+
+In this case, an atom-style variables references per-atom data if it
+exists. If access to an element of a global vector is needed (as in
+this example), an equal-style variable which references the value can
+be defined and used in the atom-style variable formula instead.
+
+Similarly, :doc:`thermodynamic output ` can only
+reference global data from a compute or fix. But you can indirectly
+access per-atom data as follows. The reference ``c_ID[245][2]`` for
+the ID of a :doc:`compute displace/atom `
+command, refers to the y-component of displacement for the atom with
+ID 245. While you cannot use that reference directly in the
+:doc:`thermo_style ` command, you can use it an
+equal-style variable formula, and then reference the variable in
+thermodynamic output.
.. _thermo:
@@ -389,7 +435,7 @@ output and input data types must match, e.g. global/per-atom/local
data and scalar/vector/array data.
Also note that, as described above, when a command takes a scalar as
-input, that could be an element of a vector or array. Likewise a
+input, that could also be an element of a vector or array. Likewise a
vector input could be a column of an array.
+--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+
diff --git a/doc/src/Intro_nonfeatures.rst b/doc/src/Intro_nonfeatures.rst
index 3289b838d6..ea12e8c0b5 100644
--- a/doc/src/Intro_nonfeatures.rst
+++ b/doc/src/Intro_nonfeatures.rst
@@ -5,7 +5,7 @@ LAMMPS is designed to be a fast, parallel engine for molecular
dynamics (MD) simulations. It provides only a modest amount of
functionality for setting up simulations and analyzing their output.
-Specifically, LAMMPS was not conceived and designed for:
+Originally, LAMMPS was not conceived and designed for:
* being run through a GUI
* building molecular systems, or building molecular topologies
@@ -14,9 +14,10 @@ Specifically, LAMMPS was not conceived and designed for:
* visualize your MD simulation interactively
* plot your output data
-Over the years some of these limitations have been reduced or
-removed, through features added to LAMMPS or external tools
-that either closely interface with LAMMPS or extend LAMMPS.
+Over the years many of these limitations have been reduced or
+removed. In part through features added to LAMMPS and in part
+through external tools that either closely interface with LAMMPS
+or extend LAMMPS.
Here are suggestions on how to perform these tasks:
@@ -24,8 +25,9 @@ Here are suggestions on how to perform these tasks:
wraps the library interface is provided. Thus, GUI interfaces can be
written in Python or C/C++ that run LAMMPS and visualize or plot its
output. Examples of this are provided in the python directory and
- described on the :doc:`Python ` doc page. Also, there
- are several external wrappers or GUI front ends.
+ described on the :doc:`Python ` doc page. As of version
+ 2 August 2023 :ref:`a GUI tool ` is included in LAMMPS.
+ Also, there are several external wrappers or GUI front ends.
* **Builder:** Several pre-processing tools are packaged with LAMMPS.
Some of them convert input files in formats produced by other MD codes
such as CHARMM, AMBER, or Insight into LAMMPS input formats. Some of
diff --git a/doc/src/JPG/lammps-gui-chart.png b/doc/src/JPG/lammps-gui-chart.png
index 447e709625..a16fcb167c 100644
Binary files a/doc/src/JPG/lammps-gui-chart.png and b/doc/src/JPG/lammps-gui-chart.png differ
diff --git a/doc/src/JPG/lammps-gui-complete.png b/doc/src/JPG/lammps-gui-complete.png
new file mode 100644
index 0000000000..8e80aa1998
Binary files /dev/null and b/doc/src/JPG/lammps-gui-complete.png differ
diff --git a/doc/src/JPG/lammps-gui-log.png b/doc/src/JPG/lammps-gui-log.png
index 1e9b9533f0..3dbae1e424 100644
Binary files a/doc/src/JPG/lammps-gui-log.png and b/doc/src/JPG/lammps-gui-log.png differ
diff --git a/doc/src/JPG/lammps-gui-main.png b/doc/src/JPG/lammps-gui-main.png
index 1e43827aa4..f700b4264f 100644
Binary files a/doc/src/JPG/lammps-gui-main.png and b/doc/src/JPG/lammps-gui-main.png differ
diff --git a/doc/src/JPG/lammps-gui-popup-help.png b/doc/src/JPG/lammps-gui-popup-help.png
index 0d692f1795..395e06ff43 100644
Binary files a/doc/src/JPG/lammps-gui-popup-help.png and b/doc/src/JPG/lammps-gui-popup-help.png differ
diff --git a/doc/src/JPG/lammps-gui-prefs-accel.png b/doc/src/JPG/lammps-gui-prefs-accel.png
index 30368fe3e2..3cab94136a 100644
Binary files a/doc/src/JPG/lammps-gui-prefs-accel.png and b/doc/src/JPG/lammps-gui-prefs-accel.png differ
diff --git a/doc/src/JPG/lammps-gui-prefs-editor.png b/doc/src/JPG/lammps-gui-prefs-editor.png
new file mode 100644
index 0000000000..5d2fe50380
Binary files /dev/null and b/doc/src/JPG/lammps-gui-prefs-editor.png differ
diff --git a/doc/src/JPG/lammps-gui-prefs-general.png b/doc/src/JPG/lammps-gui-prefs-general.png
index aefadaa70f..765ba8f84d 100644
Binary files a/doc/src/JPG/lammps-gui-prefs-general.png and b/doc/src/JPG/lammps-gui-prefs-general.png differ
diff --git a/doc/src/JPG/lammps-gui-prefs-image.png b/doc/src/JPG/lammps-gui-prefs-image.png
index f45e5a173c..b87e8f2d20 100644
Binary files a/doc/src/JPG/lammps-gui-prefs-image.png and b/doc/src/JPG/lammps-gui-prefs-image.png differ
diff --git a/doc/src/JPG/lammps-gui-run-error.png b/doc/src/JPG/lammps-gui-run-error.png
new file mode 100644
index 0000000000..cbfa0774a9
Binary files /dev/null and b/doc/src/JPG/lammps-gui-run-error.png differ
diff --git a/doc/src/JPG/lammps-gui-run-highlight.png b/doc/src/JPG/lammps-gui-run-highlight.png
new file mode 100644
index 0000000000..042d52efc8
Binary files /dev/null and b/doc/src/JPG/lammps-gui-run-highlight.png differ
diff --git a/doc/src/JPG/lammps-gui-slideshow.png b/doc/src/JPG/lammps-gui-slideshow.png
new file mode 100644
index 0000000000..21ef80e210
Binary files /dev/null and b/doc/src/JPG/lammps-gui-slideshow.png differ
diff --git a/doc/src/JPG/lammps-gui-variable-info.png b/doc/src/JPG/lammps-gui-variable-info.png
new file mode 100644
index 0000000000..5b8cb0b07a
Binary files /dev/null and b/doc/src/JPG/lammps-gui-variable-info.png differ
diff --git a/doc/src/Library_objects.rst b/doc/src/Library_objects.rst
index 8ebecfcc94..db21817cfd 100644
--- a/doc/src/Library_objects.rst
+++ b/doc/src/Library_objects.rst
@@ -9,6 +9,7 @@ fixes, or variables in LAMMPS using the following functions:
- :cpp:func:`lammps_extract_variable_datatype`
- :cpp:func:`lammps_extract_variable`
- :cpp:func:`lammps_set_variable`
+- :cpp:func:`lammps_variable_info`
-----------------------
@@ -37,6 +38,11 @@ fixes, or variables in LAMMPS using the following functions:
-----------------------
+.. doxygenfunction:: lammps_variable_info
+ :project: progguide
+
+-----------------------
+
.. doxygenenum:: _LMP_DATATYPE_CONST
.. doxygenenum:: _LMP_STYLE_CONST
diff --git a/doc/src/Manual.rst b/doc/src/Manual.rst
index eb630c4fe2..df18f62164 100644
--- a/doc/src/Manual.rst
+++ b/doc/src/Manual.rst
@@ -23,10 +23,23 @@ coordinated.
----------
-The content for this manual is part of the LAMMPS distribution. The
-online version always corresponds to the latest feature release version.
-If needed, you can build a local copy of the manual as HTML pages or a
-PDF file by following the steps on the :doc:`Build_manual` page. If you
+The content for this manual is part of the LAMMPS distribution in its
+doc directory.
+
+* The version of the manual on the LAMMPS website corresponds to the
+ latest LAMMPS feature release. It is available at:
+ `https://docs.lammps.org/ `_.
+* A version of the manual corresponding to the latest LAMMPS stable
+ release (state of the *stable* branch on GitHub) is available online
+ at: `https://docs.lammps.org/stable/
+ `_
+* A version of the manual with the features most recently added to
+ LAMMPS (state of the *develop* branch on GitHub) is available at:
+ `https://docs.lammps.org/latest/ `_
+
+If needed, you can build a copy on your local machine of the manual
+(HTML pages or PDF file) for the version of LAMMPS you have
+downloaded. Follow the steps on the :doc:`Build_manual` page. If you
have difficulties viewing the pages, please :ref:`see this note
`.
diff --git a/doc/src/Tools.rst b/doc/src/Tools.rst
index 160d04246b..49022a4ee9 100644
--- a/doc/src/Tools.rst
+++ b/doc/src/Tools.rst
@@ -645,9 +645,14 @@ LAMMPS GUI
Overview
^^^^^^^^
-LAMMPS GUI is a simple graphical text editor that is linked to the
-:ref:`LAMMPS C-library interface ` and thus can run LAMMPS
-directly using the contents of the editor's text buffer as input.
+LAMMPS GUI is a graphical text editor customized for editing LAMMPS
+input files that is linked to the :ref:`LAMMPS C-library `
+and thus can run LAMMPS directly using the contents of the editor's text
+buffer as input. It can retrieve and display information from LAMMPS
+while it is running, display visualizations created with the :doc:`dump
+image command `, and is adapted specifically for editing
+LAMMPS input files through text completion and reformatting, and linking
+to the online LAMMPS documentation for known LAMMPS commands and styles.
This is similar to what people traditionally would do to run LAMMPS:
using a regular text editor to edit the input and run the necessary
@@ -656,9 +661,9 @@ terminal window. This similarity is a design goal. While making it easy
for beginners to start with LAMMPS, it is also the intention to simplify
the transition to workflows like most experienced LAMMPS users do.
-All features have been extensively exposed to hotkeys, so that there is
-also appeal for experienced LAMMPS users, too, especially for
-prototyping and testing simulations setups.
+All features have been extensively exposed to keyboard shortcuts, so
+that there is also appeal for experienced LAMMPS users for prototyping
+and testing simulations setups.
Features
^^^^^^^^
@@ -673,11 +678,13 @@ Here are a few highlights of LAMMPS GUI
- Text editor will remember up to 5 recent files
- Context specific LAMMPS command help via online documentation
- LAMMPS is running in a concurrent thread, so the GUI remains responsive
-- Support for accelerator packages
-- Progress bar indicates that LAMMPS is running
+- Support for most accelerator packages
+- Progress bar indicates how far a run command is completed
- LAMMPS can be started and stopped with a hotkey
- Screen output is captured in a Log Window
- Thermodynamic output is captured and displayed as line graph in a Chart Window
+- Indicator for currently executed command
+- Indicator for line that caused an error
- Visualization of current state in Image Viewer (via :doc:`dump image `)
- Many adjustable settings and preferences that are persistent
- Dialog to set variables from the LAMMPS command line
@@ -695,19 +702,26 @@ Prerequisites and portability
LAMMPS GUI is programmed in C++ based on the C++11 standard and using
the `Qt GUI framework `_.
Currently, Qt version 5.12 or later is required; Qt 5.15LTS is
-recommended; Qt 6.x not (yet) supported. Building LAMMPS with CMake is
-required. The LAMMPS GUI has been successfully compiled and tested on:
+recommended; support for Qt version 6.x is under active development and
+thus far only tested with Qt 6.5LTS on Linux. Building LAMMPS with
+CMake is required.
+
+The LAMMPS GUI has been successfully compiled and tested on:
- Ubuntu Linux 20.04LTS x86_64 using GCC 9, Qt version 5.12
- Fedora Linux 38 x86\_64 using GCC 13 and Clang 16, Qt version 5.15LTS
+- Fedora Linux 38 x86\_64 using GCC 13, Qt version 6.5LTS
- Apple macOS 12 (Monterey) and macOS 13 (Ventura) with Xcode on arm64 and x86\_64, Qt version 5.15LTS
- Windows 10 and 11 x86_64 with Visual Studio 2022 and Visual C++ 14.36, Qt version 5.15LTS
- Windows 10 and 11 x86_64 with MinGW / GCC 10.0 cross-compiler on Fedora 38, Qt version 5.15LTS
+.. _lammps_gui_install:
+
+
Pre-compiled executables
^^^^^^^^^^^^^^^^^^^^^^^^
-Pre-compiled LAMMPS executables including the GUI are currently
+Pre-compiled LAMMPS executable packages that include the GUI are currently
available from https://download.lammps.org/static or
https://github.com/lammps/lammps/releases. You can unpack the archives
(or mount the macOS disk image) and run the GUI directly in place. The
@@ -732,7 +746,10 @@ stored in a location where CMake can find them without additional help.
Otherwise, the location of the Qt library installation must be indicated
by setting ``-D Qt5_DIR=/path/to/qt5/lib/cmake/Qt5``, which is a path to
a folder inside the Qt installation that contains the file
-``Qt5Config.cmake``.
+``Qt5Config.cmake``. Similarly, for Qt6 the location of the Qt library
+installation can be indicated by setting ``-D Qt6_DIR=/path/to/qt6/lib/cmake/Qt6``,
+if necessary. When both, Qt5 and Qt6 are available, Qt6 will be preferred
+unless ``-D LAMMPS_GUI_USE_QT5=yes`` is set.
It should be possible to build the LAMMPS GUI as a standalone
compilation (e.g. when LAMMPS has been compiled with traditional make),
diff --git a/doc/src/atom_modify.rst b/doc/src/atom_modify.rst
index 1e5a3d49ff..21590e6680 100644
--- a/doc/src/atom_modify.rst
+++ b/doc/src/atom_modify.rst
@@ -65,6 +65,11 @@ switch. This is described on the :doc:`Build_settings `
doc page. If atom IDs are not used, they must be specified as 0 for
all atoms, e.g. in a data or restart file.
+.. note::
+
+ If a :doc:`triclinic simulation box ` is used,
+ atom IDs are required, due to how neighbor lists are built.
+
The *map* keyword determines how atoms with specific IDs are found
when required. An example are the bond (angle, etc) methods which
need to find the local index of an atom with a specific global ID
diff --git a/doc/src/compute.rst b/doc/src/compute.rst
index abc89fb663..cc26d9acc9 100644
--- a/doc/src/compute.rst
+++ b/doc/src/compute.rst
@@ -27,58 +27,62 @@ Examples
Description
"""""""""""
-Define a computation that will be performed on a group of atoms.
-Quantities calculated by a compute are instantaneous values, meaning
-they are calculated from information about atoms on the current
-timestep or iteration, though a compute may internally store some
-information about a previous state of the system. Defining a compute
-does not perform a computation. Instead computes are invoked by other
-LAMMPS commands as needed (e.g., to calculate a temperature needed for
-a thermostat fix or to generate thermodynamic or dump file output).
-See the :doc:`Howto output ` page for a summary of
-various LAMMPS output options, many of which involve computes.
+Define a diagnostic computation that will be performed on a group of
+atoms. Quantities calculated by a compute are instantaneous values,
+meaning they are calculated from information about atoms on the
+current timestep or iteration, though internally a compute may store
+some information about a previous state of the system. Defining a
+compute does not perform the computation. Instead computes are
+invoked by other LAMMPS commands as needed (e.g., to calculate a
+temperature needed for a thermostat fix or to generate thermodynamic
+or dump file output). See the :doc:`Howto output ` page
+for a summary of various LAMMPS output options, many of which involve
+computes.
The ID of a compute can only contain alphanumeric characters and
underscores.
----------
-Computes calculate one or more of four styles of quantities: global,
-per-atom, local, or per-atom. A global quantity is one or more
-system-wide values, e.g. the temperature of the system. A per-atom
-quantity is one or more values per atom, e.g. the kinetic energy of
-each atom. Per-atom values are set to 0.0 for atoms not in the
-specified compute group. Local quantities are calculated by each
-processor based on the atoms it owns, but there may be zero or more
-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 subdomain.
+Computes calculate and store any of four *styles* of quantities:
+global, per-atom, local, or per-grid.
-Computes that produce per-atom quantities have the word "atom" at the
-end of their style, e.g. *ke/atom*\ . Computes that produce local
-quantities have the word "local" at the end of their style,
-e.g. *bond/local*\ . Computes that produce per-grid quantities have
-the word "grid" at the end of their style, e.g. *property/grid*\ .
-Styles with neither "atom" or "local" or "grid" at the end of their
-style name produce global quantities.
+A global quantity is one or more system-wide values, e.g. the
+temperature of the system. A per-atom quantity is one or more values
+per atom, e.g. the kinetic energy of each atom. Per-atom values are
+set to 0.0 for atoms not in the specified compute group. Local
+quantities are calculated by each processor based on the atoms it
+owns, but there may be zero or more 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 subdomain.
-Note that a single compute typically produces either global or
-per-atom or local or per-grid values. It does not compute both global
-and per-atom values. It can produce local values or per-grid values
-in tandem with global or per-atom quantities. The compute doc page
-will explain the details.
+As a general rule of thumb, computes that produce per-atom quantities
+have the word "atom" at the end of their style, e.g. *ke/atom*\ .
+Computes that produce local quantities have the word "local" at the
+end of their style, e.g. *bond/local*\ . Computes that produce
+per-grid quantities have the word "grid" at the end of their style,
+e.g. *property/grid*\ . And styles with neither "atom" or "local" or
+"grid" at the end of their style name produce global quantities.
-Global, per-atom, local, and per-grid quantities come in three kinds:
-a single scalar value, a vector of values, or a 2d array of values.
-The doc page for each compute describes the style and kind of values
-it produces, e.g. a per-atom vector. Some computes produce more than
-one kind of a single style, e.g. a global scalar and a global vector.
+Global, per-atom, local, and per-grid quantities can also be of three
+*kinds*: a single scalar value (global only), a vector of values, or a
+2d array of values. For per-atom, local, and per-grid quantities, a
+"vector" means a single value for each atom, each local entity
+(e.g. bond), or grid cell. Likewise an "array", means multiple values
+for each atom, each local entity, or each grid cell.
-When a compute quantity is accessed, as in many of the output commands
-discussed below, it can be referenced via the following bracket
-notation, where ID is the ID of the compute:
+Note that a single compute can produce any combination of global,
+per-atom, local, or per-grid values. Likewise it can prouduce any
+combination of scalar, vector, or array output for each style. The
+exception is that for per-atom, local, and per-grid output, either a
+vector or array can be produced, but not both. The doc page for each
+compute explains the values it produces.
+
+When a compute output is accessed by another input script command it
+is referenced via the following bracket notation, where ID is the ID
+of the compute:
+-------------+--------------------------------------------+
| c_ID | entire scalar, vector, or array |
@@ -89,17 +93,23 @@ notation, where ID is the ID of the compute:
+-------------+--------------------------------------------+
In other words, using one bracket reduces the dimension of the
-quantity once (vector :math:`\to` scalar, array :math:`\to` vector). Using two
-brackets reduces the dimension twice (array :math:`\to` scalar). Thus a
-command that uses scalar compute values as input can also process elements of a
-vector or array.
+quantity once (vector :math:`\to` scalar, array :math:`\to` vector).
+Using two brackets reduces the dimension twice (array :math:`\to`
+scalar). Thus, for example, a command that uses global scalar compute
+values as input can also process elements of a vector or array.
+Depending on the command, this can either be done directly using the
+syntax in the table, or by first defining a :doc:`variable `
+of the appropriate style to store the quantity, then using the
+variable as an input to the command.
-Note that commands and :doc:`variables ` which use compute
-quantities typically do not allow for all kinds (e.g., a command may
-require a vector of values, not a scalar). This means there is no
-ambiguity about referring to a compute quantity as c_ID even if it
-produces, for example, both a scalar and vector. The doc pages for
-various commands explain the details.
+Note that commands and :doc:`variables ` which take compute
+outputs as input typically do not allow for all styles and kinds of
+data (e.g., a command may require global but not per-atom values, or
+it may require a vector of values, not a scalar). This means there is
+typically no ambiguity about referring to a compute output as c_ID
+even if it produces, for example, both a scalar and vector. The doc
+pages for various commands explain the details, including how any
+ambiguities are resolved.
----------
diff --git a/doc/src/compute_reduce.rst b/doc/src/compute_reduce.rst
index 204f1c090d..6820d2ee04 100644
--- a/doc/src/compute_reduce.rst
+++ b/doc/src/compute_reduce.rst
@@ -37,13 +37,16 @@ Syntax
v_name = per-atom vector calculated by an atom-style variable with name
* zero or more keyword/args pairs may be appended
-* keyword = *replace*
+* keyword = *replace* or *inputs*
.. parsed-literal::
*replace* args = vec1 vec2
vec1 = reduced value from this input vector will be replaced
vec2 = replace it with vec1[N] where N is index of max/min value from vec2
+ *inputs* arg = peratom or local
+ peratom = all inputs are per-atom quantities (default)
+ local = all input are local quantities
Examples
""""""""
@@ -60,38 +63,44 @@ Description
"""""""""""
Define a calculation that "reduces" one or more vector inputs into
-scalar values, one per listed input. The inputs can be per-atom or
-local quantities; they cannot be global quantities. Atom attributes
-are per-atom quantities, :doc:`computes ` and :doc:`fixes `
-may generate any of the three kinds of quantities, and :doc:`atom-style variables ` generate per-atom quantities. See the
-:doc:`variable ` command and its special functions which can
-perform the same operations as the compute reduce command on global
-vectors.
+scalar values, one per listed input. For the compute reduce command,
+the inputs can be either per-atom or local quantities and must all be
+of the same kind (per-atom or local); see discussion of the optional
+*inputs* keyword below. The compute reduce/region command can only be
+used with per-atom inputs.
+
+Atom attributes are per-atom quantities, :doc:`computes ` and
+:doc:`fixes ` can generate either per-atom or local quantities,
+and :doc:`atom-style variables ` generate per-atom
+quantities. See the :doc:`variable ` command and its
+special functions which can perform the same reduction operations as
+the compute reduce command on global vectors.
The reduction operation is specified by the *mode* setting. The *sum*
option adds the values in the vector into a global total. The *min*
or *max* options find the minimum or maximum value across all vector
values. The *minabs* or *maxabs* options find the minimum or maximum
value across all absolute vector values. The *ave* setting adds the
-vector values into a global total, then divides by the number of values
-in the vector. The *sumsq* option sums the square of the values in the
-vector into a global total. The *avesq* setting does the same as *sumsq*,
-then divides the sum of squares by the number of values. The last two options
-can be useful for calculating the variance of some quantity (e.g., variance =
-sumsq :math:`-` ave\ :math:`^2`). The *sumabs* option sums the absolute
-values in the vector into a global total. The *aveabs* setting does the same
-as *sumabs*, then divides the sum of absolute values by the number of
+vector values into a global total, then divides by the number of
+values in the vector. The *sumsq* option sums the square of the
+values in the vector into a global total. The *avesq* setting does
+the same as *sumsq*, then divides the sum of squares by the number of
+values. The last two options can be useful for calculating the
+variance of some quantity (e.g., variance = sumsq :math:`-` ave\
+:math:`^2`). The *sumabs* option sums the absolute values in the
+vector into a global total. The *aveabs* setting does the same as
+*sumabs*, then divides the sum of absolute values by the number of
values.
Each listed input is operated on independently. For per-atom inputs,
the group specified with this command means only atoms within the
-group contribute to the result. For per-atom inputs, if the compute
-reduce/region command is used, the atoms must also currently be within
-the region. Note that an input that produces per-atom quantities may
-define its own group which affects the quantities it returns. For
-example, if a compute is used as an input which generates a per-atom
-vector, it will generate values of 0.0 for atoms that are not in the
-group specified for that compute.
+group contribute to the result. Likewise for per-atom inputs, if the
+compute reduce/region command is used, the atoms must also currently
+be within the region. Note that an input that produces per-atom
+quantities may define its own group which affects the quantities it
+returns. For example, if a compute is used as an input which
+generates a per-atom vector, it will generate values of 0.0 for atoms
+that are not in the group specified for that compute.
Each listed input can be an atom attribute (position, velocity, force
component) or can be the result of a :doc:`compute ` or
@@ -123,52 +132,54 @@ array with six columns:
----------
-The atom attribute values (*x*, *y*, *z*, *vx*, *vy*, *vz*, *fx*, *fy*, and
-*fz*) are self-explanatory. Note that other atom attributes can be used as
-inputs to this fix by using the
-:doc:`compute property/atom ` command and then specifying
-an input value from that compute.
+The atom attribute values (*x*, *y*, *z*, *vx*, *vy*, *vz*, *fx*,
+*fy*, and *fz*) are self-explanatory. Note that other atom attributes
+can be used as inputs to this fix by using the :doc:`compute
+property/atom ` command and then specifying an
+input value from that compute.
If a value begins with "c\_", a compute ID must follow which has been
-previously defined in the input script. Computes can generate
-per-atom or local quantities. See the individual
-:doc:`compute ` page for details. If no bracketed integer
-is appended, the vector calculated by the compute is used. If a
-bracketed integer is appended, the Ith column of the array calculated
-by the compute is used. Users can also write code for their own
-compute styles and :doc:`add them to LAMMPS `. See the
-discussion above for how :math:`I` can be specified with a wildcard asterisk
-to effectively specify multiple values.
+previously defined in the input script. Valid computes can generate
+per-atom or local quantities. See the individual :doc:`compute
+` page for details. If no bracketed integer is appended, the
+vector calculated by the compute is used. If a bracketed integer is
+appended, the Ith column of the array calculated by the compute is
+used. Users can also write code for their own compute styles and
+:doc:`add them to LAMMPS `. See the discussion above for how
+:math:`I` can be specified with a wildcard asterisk to effectively
+specify multiple values.
If a value begins with "f\_", a fix ID must follow which has been
-previously defined in the input script. Fixes can generate per-atom
-or local quantities. See the individual :doc:`fix ` page for
-details. Note that some fixes only produce their values on certain
-timesteps, which must be compatible with when compute reduce
+previously defined in the input script. Valid fixes can generate
+per-atom or local quantities. See the individual :doc:`fix `
+page for details. Note that some fixes only produce their values on
+certain timesteps, which must be compatible with when compute reduce
references the values, else an error results. If no bracketed integer
is appended, the vector calculated by the fix is used. If a bracketed
integer is appended, the Ith column of the array calculated by the fix
is used. Users can also write code for their own fix style and
:doc:`add them to LAMMPS `. See the discussion above for how
-:math:`I` can be specified with a wildcard asterisk to effectively specify
-multiple values.
+:math:`I` can be specified with a wildcard asterisk to effectively
+specify multiple values.
If a value begins with "v\_", a variable name must follow which has
been previously defined in the input script. It must be an
:doc:`atom-style variable `. Atom-style variables can
reference thermodynamic keywords and various per-atom attributes, or
invoke other computes, fixes, or variables when they are evaluated, so
-this is a very general means of generating per-atom quantities to reduce.
+this is a very general means of generating per-atom quantities to
+reduce.
----------
If the *replace* keyword is used, two indices *vec1* and *vec2* are
-specified, where each index ranges from 1 to the number of input values.
-The replace keyword can only be used if the *mode* is *min* or *max*\ .
-It works as follows. A min/max is computed as usual on the *vec2*
-input vector. The index :math:`N` of that value within *vec2* is also stored.
-Then, instead of performing a min/max on the *vec1* input vector, the
-stored index is used to select the :math:`N`\ th element of the *vec1* vector.
+specified, where each index ranges from 1 to the number of input
+values. The replace keyword can only be used if the *mode* is *min*
+or *max*\ . It works as follows. A min/max is computed as usual on
+the *vec2* input vector. The index :math:`N` of that value within
+*vec2* is also stored. Then, instead of performing a min/max on the
+*vec1* input vector, the stored index is used to select the :math:`N`\
+th element of the *vec1* vector.
Thus, for example, if you wish to use this compute to find the bond
with maximum stretch, you can do it as follows:
@@ -190,6 +201,16 @@ information in this context, the *replace* keywords will extract the
atom IDs for the two atoms in the bond of maximum stretch. These atom
IDs and the bond stretch will be printed with thermodynamic output.
+.. versionadded:: TBD
+
+The *inputs* keyword allows selection of whether all the inputs are
+per-atom or local quantities. As noted above, all the inputs must be
+the same kind (per-atom or local). Per-atom is the default setting.
+If a compute or fix is specified as an input, it must produce per-atom
+or local data to match this setting. If it produces both, e.g. for
+the :doc:`compute voronoi/atom ` command, then
+this keyword selects between them.
+
----------
If a single input is specified this compute produces a global scalar
@@ -197,38 +218,41 @@ value. If multiple inputs are specified, this compute produces a
global vector of values, the length of which is equal to the number of
inputs specified.
-As discussed below, for the *sum*, *sumabs*, and *sumsq* modes, the value(s)
-produced by this compute are all "extensive", meaning their value
-scales linearly with the number of atoms involved. If normalized
-values are desired, this compute can be accessed by the
+As discussed below, for the *sum*, *sumabs*, and *sumsq* modes, the
+value(s) produced by this compute are all "extensive", meaning their
+value scales linearly with the number of atoms involved. If
+normalized values are desired, this compute can be accessed by the
:doc:`thermo_style custom ` command with
-:doc:`thermo_modify norm yes ` set as an option.
-Or it can be accessed by a
-:doc:`variable ` that divides by the appropriate atom count.
+:doc:`thermo_modify norm yes ` set as an option. Or it
+can be accessed by a :doc:`variable ` that divides by the
+appropriate atom count.
----------
Output info
"""""""""""
-This compute calculates a global scalar if a single input value is specified
-or a global vector of length :math:`N`, where :math:`N` is the number of
-inputs, and which can be accessed by indices 1 to :math:`N`. These values can
-be used by any command that uses global scalar or vector values from a
-compute as input. See the :doc:`Howto output ` doc page
-for an overview of LAMMPS output options.
+This compute calculates a global scalar if a single input value is
+specified or a global vector of length :math:`N`, where :math:`N` is
+the number of inputs, and which can be accessed by indices 1 to
+:math:`N`. These values can be used by any command that uses global
+scalar or vector values from a compute as input. See the :doc:`Howto
+output ` doc page for an overview of LAMMPS output
+options.
All the scalar or vector values calculated by this compute are
"intensive", except when the *sum*, *sumabs*, or *sumsq* modes are used on
per-atom or local vectors, in which case the calculated values are
"extensive".
-The scalar or vector values will be in whatever :doc:`units ` the
-quantities being reduced are in.
+The scalar or vector values will be in whatever :doc:`units `
+the quantities being reduced are in.
Restrictions
""""""""""""
- none
+
+As noted above, the compute reduce/region command can only be used
+with per-atom inputs.
Related commands
""""""""""""""""
@@ -238,4 +262,4 @@ Related commands
Default
"""""""
-none
+The default value for the *inputs* keyword is peratom.
diff --git a/doc/src/compute_stress_atom.rst b/doc/src/compute_stress_atom.rst
index 3b21fbf102..8a45171dfe 100644
--- a/doc/src/compute_stress_atom.rst
+++ b/doc/src/compute_stress_atom.rst
@@ -223,7 +223,7 @@ result. I.e. the last 2 columns of thermo output will be the same:
system pressure.
The compute stress/atom can be used in a number of ways. Here is an
-example to compute a 1-d pressure profile in z-direction across the
+example to compute a 1-d pressure profile in x-direction across the
complete simulation box. You will need to adjust the number of bins and the
selections for time averaging to your specific simulation. This assumes
that the dimensions of the simulation cell does not change.
diff --git a/doc/src/compute_voronoi_atom.rst b/doc/src/compute_voronoi_atom.rst
index 274be1b702..37e5386341 100644
--- a/doc/src/compute_voronoi_atom.rst
+++ b/doc/src/compute_voronoi_atom.rst
@@ -13,7 +13,7 @@ Syntax
* ID, group-ID are documented in :doc:`compute ` command
* voronoi/atom = style name of this compute command
* zero or more keyword/value pairs may be appended
-* keyword = *only_group* or *occupation* or *surface* or *radius* or *edge_histo* or *edge_threshold* or *face_threshold* or *neighbors* or *peratom*
+* keyword = *only_group* or *occupation* or *surface* or *radius* or *edge_histo* or *edge_threshold* or *face_threshold* or *neighbors*
.. parsed-literal::
@@ -31,7 +31,6 @@ Syntax
*face_threshold* arg = minarea
minarea = minimum area for a face to be counted
*neighbors* value = *yes* or *no* = store list of all neighbors or no
- *peratom* value = *yes* or *no* = per-atom quantities accessible or no
Examples
""""""""
@@ -53,14 +52,12 @@ atoms in the simulation box. The tessellation is calculated using all
atoms in the simulation, but non-zero values are only stored for atoms
in the group.
-By default two per-atom quantities are calculated by this compute.
-The first is the volume of the Voronoi cell around each atom. Any
-point in an atom's Voronoi cell is closer to that atom than any other.
-The second is the number of faces of the Voronoi cell. This is
-equal to the number of nearest neighbors of the central atom,
-plus any exterior faces (see note below). If the *peratom* keyword
-is set to "no", the per-atom quantities are still calculated,
-but they are not accessible.
+Two per-atom quantities are calculated by this compute. The first is
+the volume of the Voronoi cell around each atom. Any point in an
+atom's Voronoi cell is closer to that atom than any other. The second
+is the number of faces of the Voronoi cell. This is equal to the
+number of nearest neighbors of the central atom, plus any exterior
+faces (see note below).
----------
@@ -97,13 +94,13 @@ present in atom_style sphere for granular models.
The *edge_histo* keyword activates the compilation of a histogram of
number of edges on the faces of the Voronoi cells in the compute
-group. The argument *maxedge* of the this keyword is the largest number
-of edges on a single Voronoi cell face expected to occur in the
-sample. This keyword adds the generation of a global vector with
-*maxedge*\ +1 entries. The last entry in the vector contains the number of
-faces with more than *maxedge* edges. Since the polygon with the
-smallest amount of edges is a triangle, entries 1 and 2 of the vector
-will always be zero.
+group. The argument *maxedge* of the this keyword is the largest
+number of edges on a single Voronoi cell face expected to occur in the
+sample. This keyword generates output of a global vector by this
+compute with *maxedge*\ +1 entries. The last entry in the vector
+contains the number of faces with more than *maxedge* edges. Since the
+polygon with the smallest amount of edges is a triangle, entries 1 and
+2 of the vector will always be zero.
The *edge_threshold* and *face_threshold* keywords allow the
suppression of edges below a given minimum length and faces below a
@@ -127,8 +124,8 @@ to locate vacancies (the coordinates are given by the atom coordinates
at the time step when the compute was first invoked), while column two
data can be used to identify interstitial atoms.
-If the *neighbors* value is set to yes, then this compute creates a
-local array with 3 columns. There is one row for each face of each
+If the *neighbors* value is set to yes, then this compute also creates
+a local array with 3 columns. There is one row for each face of each
Voronoi cell. The 3 columns are the atom ID of the atom that owns the
cell, the atom ID of the atom in the neighboring cell (or zero if the
face is external), and the area of the face. The array can be
@@ -143,8 +140,8 @@ containing all the Voronoi neighbors in a system:
compute 6 all voronoi/atom neighbors yes
dump d2 all local 1 dump.neighbors index c_6[1] c_6[2] c_6[3]
-If the *face_threshold* keyword is used, then only faces
-with areas greater than the threshold are stored.
+If the *face_threshold* keyword is used, then only faces with areas
+greater than the threshold are stored.
----------
@@ -158,48 +155,52 @@ Voro++ software in the src/VORONOI/README file.
.. note::
- The calculation of Voronoi volumes is performed by each processor for
- the atoms it owns, and includes the effect of ghost atoms stored by
- the processor. This assumes that the Voronoi cells of owned atoms
- are not affected by atoms beyond the ghost atom cut-off distance.
- This is usually a good assumption for liquid and solid systems, but
- may lead to underestimation of Voronoi volumes in low density
- systems. By default, the set of ghost atoms stored by each processor
- is determined by the cutoff used for :doc:`pair_style `
- interactions. The cutoff can be set explicitly via the
- :doc:`comm_modify cutoff ` command. The Voronoi cells
- for atoms adjacent to empty regions will extend into those regions up
- to the communication cutoff in :math:`x`, :math:`y`, or :math:`z`.
- In that situation, an exterior face is created at the cutoff distance
- normal to the :math:`x`, :math:`y`, or :math:`z` direction. For
- triclinic systems, the exterior face is parallel to the corresponding
- reciprocal lattice vector.
+ The calculation of Voronoi volumes is performed by each processor
+ for the atoms it owns, and includes the effect of ghost atoms
+ stored by the processor. This assumes that the Voronoi cells of
+ owned atoms are not affected by atoms beyond the ghost atom cut-off
+ distance. This is usually a good assumption for liquid and solid
+ systems, but may lead to underestimation of Voronoi volumes in low
+ density systems. By default, the set of ghost atoms stored by each
+ processor is determined by the cutoff used for :doc:`pair_style
+ ` interactions. The cutoff can be set explicitly via
+ the :doc:`comm_modify cutoff ` command. The Voronoi
+ cells for atoms adjacent to empty regions will extend into those
+ regions up to the communication cutoff in :math:`x`, :math:`y`, or
+ :math:`z`. In that situation, an exterior face is created at the
+ cutoff distance normal to the :math:`x`, :math:`y`, or :math:`z`
+ direction. For triclinic systems, the exterior face is parallel to
+ the corresponding reciprocal lattice vector.
.. note::
- The Voro++ package performs its calculation in 3d. This will
- still work for a 2d LAMMPS simulation, provided all the atoms have the
- same :math:`z`-coordinate. The Voronoi cell of each atom will be a columnar
- polyhedron with constant cross-sectional area along the :math:`z`-direction
- and two exterior faces at the top and bottom of the simulation box. If
- the atoms do not all have the same :math:`z`-coordinate, then the columnar
- cells will be accordingly distorted. The cross-sectional area of each
- Voronoi cell can be obtained by dividing its volume by the :math:`z` extent
- of the simulation box. Note that you define the :math:`z` extent of the
- simulation box for 2d simulations when using the
- :doc:`create_box ` or :doc:`read_data ` commands.
+ The Voro++ package performs its calculation in 3d. This will still
+ work for a 2d LAMMPS simulation, provided all the atoms have the
+ same :math:`z`-coordinate. The Voronoi cell of each atom will be a
+ columnar polyhedron with constant cross-sectional area along the
+ :math:`z`-direction and two exterior faces at the top and bottom of
+ the simulation box. If the atoms do not all have the same
+ :math:`z`-coordinate, then the columnar cells will be accordingly
+ distorted. The cross-sectional area of each Voronoi cell can be
+ obtained by dividing its volume by the :math:`z` extent of the
+ simulation box. Note that you define the :math:`z` extent of the
+ simulation box for 2d simulations when using the :doc:`create_box
+ ` or :doc:`read_data ` commands.
Output info
"""""""""""
-By default, this compute calculates a per-atom array with two
-columns. In regular dynamic tessellation mode the first column is the
-Voronoi volume, the second is the neighbor count, as described above
-(read above for the output data in case the *occupation* keyword is
-specified). These values can be accessed by any command that uses
-per-atom values from a compute as input. See the :doc:`Howto output ` page for an overview of LAMMPS output
-options. If the *peratom* keyword is set to "no", the per-atom array
-is still created, but it is not accessible.
+.. deprecated:: TBD
+
+ The *peratom* keyword was removed as it is no longer required.
+
+This compute calculates a per-atom array with two columns. In regular
+dynamic tessellation mode the first column is the Voronoi volume, the
+second is the neighbor count, as described above (read above for the
+output data in case the *occupation* keyword is specified). These
+values can be accessed by any command that uses per-atom values from a
+compute as input. See the :doc:`Howto output ` page for
+an overview of LAMMPS output options.
If the *edge_histo* keyword is used, then this compute generates a
global vector of length *maxedge*\ +1, containing a histogram of the
@@ -209,17 +210,6 @@ If the *neighbors* value is set to *yes*, then this compute calculates a
local array with three columns. There is one row for each face of each
Voronoi cell.
-.. note::
-
- Some LAMMPS commands such as the :doc:`compute reduce `
- command can accept either a per-atom or local quantity. If this compute
- produces both quantities, the command
- may access the per-atom quantity, even if you want to access the local
- quantity. This effect can be eliminated by using the *peratom*
- keyword to turn off the production of the per-atom quantities. For
- the default value *yes* both quantities are produced. For the value
- *no*, only the local array is produced.
-
The Voronoi cell volume will be in distance :doc:`units ` cubed.
The Voronoi face area will be in distance :doc:`units ` squared.
@@ -227,7 +217,8 @@ Restrictions
""""""""""""
This compute is part of the VORONOI package. It is only enabled if
-LAMMPS was built with that package. See the :doc:`Build package ` page for more info.
+LAMMPS was built with that package. See the :doc:`Build package
+` page for more info.
It also requires you have a copy of the Voro++ library built and
installed on your system. See instructions on obtaining and
@@ -241,5 +232,4 @@ Related commands
Default
"""""""
-*neighbors* no, *peratom* yes
-
+The default for the neighobrs keyword is no.
diff --git a/doc/src/fix.rst b/doc/src/fix.rst
index 09fc05d500..3dd7e224e7 100644
--- a/doc/src/fix.rst
+++ b/doc/src/fix.rst
@@ -77,35 +77,44 @@ for individual fixes for info on which ones can be restarted.
----------
-Some fixes calculate one or more of four styles of quantities: global,
-per-atom, local, or per-grid, which can be used by other commands or
-output as described below. A global quantity is one or more
-system-wide values, e.g. the energy of a wall interacting with
-particles. A per-atom quantity is one or more values per atom,
-e.g. the displacement vector for each atom since time 0. Per-atom
-values are set to 0.0 for atoms not in the specified fix group. Local
-quantities are calculated by each processor based on the atoms it
-owns, but there may be zero or more per atoms. 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 subdomain.
+Some fixes calculate and store any of four *styles* of quantities:
+global, per-atom, local, or per-grid.
-Note that a single fix typically produces either global or per-atom or
-local or per-grid values (or none at all). It does not produce both
-global and per-atom. It can produce local or per-grid values in
-tandem with global or per-atom values. The fix doc page will explain
-the details.
+A global quantity is one or more system-wide values, e.g. the energy
+of a wall interacting with particles. A per-atom quantity is one or
+more values per atom, e.g. the original coordinates of each atom at
+time 0. Per-atom values are set to 0.0 for atoms not in the specified
+fix group. Local quantities are calculated by each processor based on
+the atoms it owns, but there may be zero or more per atom, e.g. values
+for each bond. 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 subdomain.
-Global, per-atom, local, and per-grid quantities come in three kinds:
-a single scalar value, a vector of values, or a 2d array of values.
-The doc page for each fix describes the style and kind of values it
-produces, e.g. a per-atom vector. Some fixes produce more than one
-kind of a single style, e.g. a global scalar and a global vector.
+As a general rule of thumb, fixes that produce per-atom quantities
+have the word "atom" at the end of their style, e.g. *ave/atom*\ .
+Fixes that produce local quantities have the word "local" at the end
+of their style, e.g. *store/local*\ . Fixes that produce per-grid
+quantities have the word "grid" at the end of their style,
+e.g. *ave/grid*\ .
-When a fix quantity is accessed, as in many of the output commands
-discussed below, it can be referenced via the following bracket
-notation, where ID is the ID of the fix:
+Global, per-atom, local, and per-grid quantities can also be of three
+*kinds*: a single scalar value (global only), a vector of values, or a
+2d array of values. For per-atom, local, and per-grid quantities, a
+"vector" means a single value for each atom, each local entity
+(e.g. bond), or grid cell. Likewise an "array", means multiple values
+for each atom, each local entity, or each grid cell.
+
+Note that a single fix can produce any combination of global,
+per-atom, local, or per-grid values. Likewise it can prouduce any
+combination of scalar, vector, or array output for each style. The
+exception is that for per-atom, local, and per-grid output, either a
+vector or array can be produced, but not both. The doc page for each
+fix explains the values it produces, if any.
+
+When a fix output is accessed by another input script command it is
+referenced via the following bracket notation, where ID is the ID of
+the fix:
+-------------+--------------------------------------------+
| f_ID | entire scalar, vector, or array |
@@ -116,19 +125,23 @@ notation, where ID is the ID of the fix:
+-------------+--------------------------------------------+
In other words, using one bracket reduces the dimension of the
-quantity once (vector :math:`\to` scalar, array :math:`\to` vector). Using two
-brackets reduces the dimension twice (array :math:`\to` scalar). Thus, a
-command that uses scalar fix values as input can also process elements of a
-vector or array.
+quantity once (vector :math:`\to` scalar, array :math:`\to` vector).
+Using two brackets reduces the dimension twice (array :math:`\to`
+scalar). Thus, for example, a command that uses global scalar fix
+values as input can also process elements of a vector or array.
+Depending on the command, this can either be done directly using the
+syntax in the table, or by first defining a :doc:`variable `
+of the appropriate style to store the quantity, then using the
+variable as an input to the command.
-Note that commands and :doc:`variables ` that use fix
-quantities typically do not allow for all kinds (e.g., a command may
-require a vector of values, not a scalar), and even if they do, the context
-in which they are called can be used to resolve which output is being
-requested. This means there is no
-ambiguity about referring to a fix quantity as f_ID even if it
-produces, for example, both a scalar and vector. The doc pages for
-various commands explain the details.
+Note that commands and :doc:`variables ` which take fix
+outputs as input typically do not allow for all styles and kinds of
+data (e.g., a command may require global but not per-atom values, or
+it may require a vector of values, not a scalar). This means there is
+typically no ambiguity about referring to a fix output as c_ID even if
+it produces, for example, both a scalar and vector. The doc pages for
+various commands explain the details, including how any ambiguities
+are resolved.
----------
@@ -333,6 +346,7 @@ accelerated styles exist.
* :doc:`pour ` - pour new atoms/molecules into a granular simulation domain
* :doc:`precession/spin ` - apply a precession torque to each magnetic spin
* :doc:`press/berendsen ` - pressure control by Berendsen barostat
+* :doc:`press/langevin ` - pressure control by Langevin barostat
* :doc:`print ` - print text and variables during a simulation
* :doc:`propel/self ` - model self-propelled particles
* :doc:`property/atom ` - add customized per-atom values
diff --git a/doc/src/fix_ave_histo.rst b/doc/src/fix_ave_histo.rst
index 8bb66f0615..31e5476f9e 100644
--- a/doc/src/fix_ave_histo.rst
+++ b/doc/src/fix_ave_histo.rst
@@ -79,9 +79,10 @@ Description
Use one or more values as inputs every few timesteps to create a
single histogram. The histogram can then be averaged over longer
-timescales. The resulting histogram can be used by other :doc:`output commands `, and can also be written to a file. The
-fix ave/histo/weight command has identical syntax to fix ave/histo,
-except that exactly two values must be specified. See details below.
+timescales. The resulting histogram can be used by other :doc:`output
+commands `, and can also be written to a file. The fix
+ave/histo/weight command has identical syntax to fix ave/histo, except
+that exactly two values must be specified. See details below.
The group specified with this command is ignored for global and local
input values. For per-atom input values, only atoms in the group
@@ -96,14 +97,18 @@ different ways; see the discussion of the *beyond* keyword below.
Each input value can be an atom attribute (position, velocity, force
component) or can be the result of a :doc:`compute ` or
-:doc:`fix ` or the evaluation of an equal-style or vector-style or
-atom-style :doc:`variable `. The set of input values can be
-either all global, all per-atom, or all local quantities. Inputs of
-different kinds (e.g. global and per-atom) cannot be mixed. Atom
-attributes are per-atom vector values. See the page for
-individual "compute" and "fix" commands to see what kinds of
-quantities they generate. See the optional *kind* keyword below for
-how to force the fix ave/histo command to disambiguate if necessary.
+:doc:`fix ` or the evaluation of an equal-style or vector-style
+or atom-style :doc:`variable `. The set of input values can
+be either all global, all per-atom, or all local quantities. Inputs
+of different kinds (e.g. global and per-atom) cannot be mixed. Atom
+attributes are per-atom vector values. See the page for individual
+"compute" and "fix" commands to see what kinds of quantities they
+generate.
+
+Note that a compute or fix can produce multiple kinds of data (global,
+per-atom, local). If LAMMPS cannot unambiguosly determine which kind
+of data to use, the optional *kind* keyword discussed below can force
+the desired disambiguation.
Note that the output of this command is a single histogram for all
input values combined together, not one histogram per input value.
@@ -258,13 +263,14 @@ keyword is set to *vector*, then all input values must be global or
per-atom or local vectors, or columns of global or per-atom or local
arrays.
-The *kind* keyword only needs to be set if a compute or fix produces
-more than one kind of output (global, per-atom, local). If this is
-not the case, then LAMMPS will determine what kind of input is
-provided and whether all the input arguments are consistent. If a
-compute or fix produces more than one kind of output, the *kind*
-keyword should be used to specify which output will be used. The
-remaining input arguments must still be consistent.
+The *kind* keyword only needs to be used if any of the specfied input
+computes or fixes produce more than one kind of output (global,
+per-atom, local). If not, LAMMPS will determine the kind of data all
+the inputs produce and verify it is all the same kind. If not, an
+error will be triggered. If a compute or fix produces more than one
+kind of output, the *kind* keyword should be used to specify which
+output will be used. The other input arguments must still be
+consistent.
The *beyond* keyword determines how input values that fall outside the
*lo* to *hi* bounds are treated. Values such that *lo* :math:`\le` value
diff --git a/doc/src/fix_efield.rst b/doc/src/fix_efield.rst
index 2958d89794..a870590856 100644
--- a/doc/src/fix_efield.rst
+++ b/doc/src/fix_efield.rst
@@ -1,4 +1,5 @@
.. index:: fix efield
+.. index:: fix efield/kk
.. index:: fix efield/tip4p
fix efield command
@@ -210,6 +211,12 @@ the iteration count during the minimization.
system (the quantity being minimized), you MUST enable the
:doc:`fix_modify ` *energy* option for this fix.
+----------
+
+.. include:: accel_styles.rst
+
+----------
+
Restrictions
""""""""""""
diff --git a/doc/src/fix_plumed.rst b/doc/src/fix_plumed.rst
index ca56f83958..614c49f25c 100644
--- a/doc/src/fix_plumed.rst
+++ b/doc/src/fix_plumed.rst
@@ -24,7 +24,7 @@ Examples
.. code-block:: LAMMPS
- fix pl all plumed all plumed plumedfile plumed.dat outfile p.log
+ fix pl all plumed plumedfile plumed.dat outfile p.log
Description
"""""""""""
diff --git a/doc/src/fix_press_langevin.rst b/doc/src/fix_press_langevin.rst
new file mode 100644
index 0000000000..8438d72192
--- /dev/null
+++ b/doc/src/fix_press_langevin.rst
@@ -0,0 +1,301 @@
+.. index:: fix press/langevin
+
+fix press/langevin command
+===========================
+
+Syntax
+""""""
+
+.. parsed-literal::
+
+ fix ID group-ID press/langevin keyword value ...
+
+* ID, group-ID are documented in :doc:`fix ` command
+* press/langevin = style name of this fix command
+
+ .. parsed-literal::
+
+ one or more keyword value pairs may be appended
+ keyword = *iso* or *aniso* or *tri* or *x* or *y* or *z* or *xy* or *xz* or *yz* or *couple* or *dilate* or *modulus* or *temp* or *flip*
+ *iso* or *aniso* or *tri* values = Pstart Pstop Pdamp
+ Pstart,Pstop = scalar external pressure at start/end of run (pressure units)
+ Pdamp = pressure damping parameter (time units)
+ *x* or *y* or *z* or *xy* or *xz* or *yz* values = Pstart Pstop Pdamp
+ Pstart,Pstop = external stress tensor component at start/end of run (pressure units)
+ Pdamp = pressure damping parameter
+ *flip* value = *yes* or *no* = allow or disallow box flips when it becomes highly skewed
+ *couple* = *none* or *xyz* or *xy* or *yz* or *xz*
+ *friction* value = Friction coefficient for the barostat (time units)
+ *temp* values = Tstart, Tstop, seed
+ Tstart, Tstop = target temperature used for the barostat at start/end of run
+ seed = seed of the random number generator
+ *dilate* value = *all* or *partial*
+
+Examples
+""""""""
+
+.. code-block:: LAMMPS
+
+ fix 1 all press/langevin iso 0.0 0.0 1000.0 temp 300 300 487374
+ fix 2 all press/langevin aniso 0.0 0.0 1000.0 temp 100 300 238 dilate partial
+
+Description
+"""""""""""
+
+Adjust the pressure of the system by using a Langevin stochastic barostat
+:ref:`(Gronbech) `, which rescales the system volume and
+(optionally) the atoms coordinates within the simulation box every
+timestep.
+
+The Langevin barostat couple each direction *L* with a pseudo-particle that obeys
+the Langevin equation such as:
+
+.. math::
+
+ f_P = & \frac{N k_B T_{target}}{V} + \frac{1}{V d}\sum_{i=1}^{N} \vec r_i \cdot \vec f_i - P_{target} \\
+ Q\ddot{L} + \alpha{}\dot{L} = & f_P + \beta(t)\\
+ L^{n+1} = & L^{n} + bdt\dot{L}^{n} \frac{bdt^{2}}{2Q} \\
+ \dot{L}^{n+1} = & \alpha\dot{L}^{n} + \frac{dt}{2Q}\left(a f^{n}_{P} + f^{n+1}_{P}\right) + \frac{b}{Q}\beta^{n+1} \\
+ a = & \frac{1-\frac{\alpha{}dt}{2Q}}{1+\frac{\alpha{}dt}{2Q}} \\
+ b = & \frac{1}{1+\frac{\alpha{}dt}{2Q}} \\
+ \left< \beta(t)\beta(t') \right> = & 2\alpha k_B Tdt
+
+Where :math:`dt` is the timestep :math:`\dot{L}` and :math:`\ddot{L}` the first
+and second derivatives of the coupled direction with regard to time,
+:math:`\alpha` is a friction coefficient, :math:`\beta` is a random gaussian
+variable and :math:`Q` the effective mass of the coupled pseudoparticle. The
+two first terms on the right-hand side of the first equation are the virial
+expression of the canonical pressure. It is to be noted that the temperature
+used to compute the pressure is not based on the atom velocities but rather on
+the canonical
+target temperature directly. This temperature is specified using the *temp*
+keyword parameter and should be close to the expected target temperature of the
+system.
+
+Regardless of what atoms are in the fix group, a global pressure is
+computed for all atoms. Similarly, when the size of the simulation
+box is changed, all atoms are re-scaled to new positions, unless the
+keyword *dilate* is specified with a value of *partial*, in which case
+only the atoms in the fix group are re-scaled. The latter can be
+useful for leaving the coordinates of atoms in a solid substrate
+unchanged and controlling the pressure of a surrounding fluid.
+
+.. note::
+
+ Unlike the :doc:`fix npt ` or :doc:`fix nph ` commands which
+ perform Nose-Hoover barostatting AND time integration, this fix does NOT
+ perform time integration of the atoms but only of the barostat coupled
+ coordinate. It then only modifies the box size and atom coordinates to
+ effect barostatting. Thus you must use a separate time integration fix,
+ like :doc:`fix nve ` or :doc:`fix nvt ` to actually update
+ the positions and velocities of atoms. This fix can be used in conjunction
+ with thermostatting fixes to control the temperature, such as :doc:`fix nvt
+ ` or :doc:`fix langevin ` or :doc:`fix temp/berendsen
+ `.
+
+See the :doc:`Howto barostat ` page for a
+discussion of different ways to perform barostatting.
+
+----------
+
+The barostat is specified using one or more of the *iso*, *aniso*, *tri* *x*,
+*y*, *z*, *xy*, *xz*, *yz*, and *couple* keywords. These keywords give you the
+ability to specify the 3 diagonal components of an external stress tensor, and
+to couple various of these components together so that the dimensions they
+represent are varied together during a constant-pressure simulation.
+
+The target pressures for each of the 6 diagonal components of the stress tensor
+can be specified independently via the *x*, *y*, *z*, keywords, which
+correspond to the 3 simulation box dimensions, and the *xy*, *xz* and *yz*
+keywords which corresponds to the 3 simulation box tilt factors. For each
+component, the external pressure or tensor component at each timestep is a
+ramped value during the run from *Pstart* to *Pstop*\ . If a target pressure is
+specified for a component, then the corresponding box dimension will change
+during a simulation. For example, if the *y* keyword is used, the y-box length
+will change. A box dimension will not change if that component is not
+specified, although you have the option to change that dimension via the
+:doc:`fix deform ` command.
+
+The *Pdamp* parameter can be seen in the same way as a Nose-Hoover parameter as
+it is used to compute the mass of the fictitious particle. Without friction,
+the barostat can be compared to a single particle Nose-Hoover barostat and
+should follow a similar decay in time. The mass of the barostat is
+linked to *Pdamp* by the relation
+:math:`Q=(N_{at}+1)\cdot{}k_BT_{target}\cdot{}P_{damp}^2`. Note that *Pdamp*
+should be expressed in time units.
+
+.. note::
+
+ As for Berendsen barostat, a Langevin barostat will not work well for
+ arbitrary values of *Pdamp*\ . If *Pdamp* is too small, the pressure and
+ volume can fluctuate wildly; if it is too large, the pressure will take a
+ very long time to equilibrate. A good choice for many models is a *Pdamp*
+ of around 1000 timesteps. However, note that *Pdamp* is specified in time
+ units, and that timesteps are NOT the same as time units for most
+ :doc:`units ` settings.
+
+----------
+
+The *temp* keyword sets the temperature to use in the equation of motion of the
+barostat. This value is used to compute the value of the force :math:`f_P` in
+the equation of motion. It is important to note that this value is not the
+instantaneous temperature but a target temperature that ramps from *Tstart* to
+*Tstop*. Also the required argument *seed* sets the seed for the random
+number generator used in the generation of the random forces.
+
+----------
+
+The *couple* keyword allows two or three of the diagonal components of
+the pressure tensor to be "coupled" together. The value specified
+with the keyword determines which are coupled. For example, *xz*
+means the *Pxx* and *Pzz* components of the stress tensor are coupled.
+*Xyz* means all 3 diagonal components are coupled. Coupling means two
+things: the instantaneous stress will be computed as an average of the
+corresponding diagonal components, and the coupled box dimensions will
+be changed together in lockstep, meaning coupled dimensions will be
+dilated or contracted by the same percentage every timestep. The
+*Pstart*, *Pstop*, *Pdamp* parameters for any coupled dimensions must
+be identical. *Couple xyz* can be used for a 2d simulation; the *z*
+dimension is simply ignored.
+
+----------
+
+The *iso*, *aniso* and *tri* keywords are simply shortcuts that are
+equivalent to specifying several other keywords together.
+
+The keyword *iso* means couple all 3 diagonal components together when
+pressure is computed (hydrostatic pressure), and dilate/contract the
+dimensions together. Using "iso Pstart Pstop Pdamp" is the same as
+specifying these 4 keywords:
+
+.. parsed-literal::
+
+ x Pstart Pstop Pdamp
+ y Pstart Pstop Pdamp
+ z Pstart Pstop Pdamp
+ couple xyz
+
+The keyword *aniso* means *x*, *y*, and *z* dimensions are controlled
+independently using the *Pxx*, *Pyy*, and *Pzz* components of the
+stress tensor as the driving forces, and the specified scalar external
+pressure. Using "aniso Pstart Pstop Pdamp" is the same as specifying
+these 4 keywords:
+
+.. parsed-literal::
+
+ x Pstart Pstop Pdamp
+ y Pstart Pstop Pdamp
+ z Pstart Pstop Pdamp
+ couple none
+
+The keyword *tri* is the same as *aniso* but also adds the control on the
+shear pressure coupled with the tilt factors.
+
+.. parsed-literal::
+
+ x Pstart Pstop Pdamp
+ y Pstart Pstop Pdamp
+ z Pstart Pstop Pdamp
+ xy Pstart Pstop Pdamp
+ xz Pstart Pstop Pdamp
+ yz Pstart Pstop Pdamp
+ couple none
+
+----------
+
+The *flip* keyword allows the tilt factors for a triclinic box to
+exceed half the distance of the parallel box length, as discussed
+below. If the *flip* value is set to *yes*, the bound is enforced by
+flipping the box when it is exceeded. If the *flip* value is set to
+*no*, the tilt will continue to change without flipping. Note that if
+applied stress induces large deformations (e.g. in a liquid), this
+means the box shape can tilt dramatically and LAMMPS will run less
+efficiently, due to the large volume of communication needed to
+acquire ghost atoms around a processor's irregular-shaped subdomain.
+For extreme values of tilt, LAMMPS may also lose atoms and generate an
+error.
+
+----------
+
+The *friction* keyword sets the friction parameter :math:`\alpha` in the
+equations of motion of the barostat. For each barostat direction, the value of
+:math:`\alpha` depends on both *Pdamp* and *friction*. The value given as a
+parameter is the Langevin characteristic time
+:math:`\tau_{L}=\frac{Q}{\alpha}` in time units. The langevin time can be understood as a
+decorrelation time for the pressure. A long Langevin time value will make the
+barostat act as an underdamped oscillator while a short value will make it
+act as an overdamped oscillator. The ideal configuration would be to find
+the critical parameter of the barostat. Empirically this is observed to
+occur for :math:`\tau_{L}\approx{}P_{damp}`. For this reason, if the *friction*
+keyword is not used, the default value *Pdamp* is used for each barostat direction.
+
+----------
+
+This fix computes pressure each timestep. To do
+this, the fix creates its own computes of style "pressure",
+as if this command had been issued:
+
+.. code-block:: LAMMPS
+
+ compute fix-ID_press group-ID pressure NULL virial
+
+The kinetic contribution to the pressure is taken as the ensemble value
+:math:`\frac{Nk_bT}{V}` and computed by the fix itself.
+
+See the :doc:`compute pressure ` command for details. Note
+that the IDs of the new compute is the fix-ID + underscore + "press" and the
+group for the new computes is the same as the fix group.
+
+Note that this is NOT the compute used by thermodynamic output (see the
+:doc:`thermo_style ` command) with ID = *thermo_press*. This
+means you can change the attributes of this fix's pressure via the
+:doc:`compute_modify ` command or print this temperature or
+pressure during thermodynamic output via the :doc:`thermo_style custom
+` command using the appropriate compute-ID. It also means that
+changing attributes of *thermo_temp* or *thermo_press* will have no effect on
+this fix.
+
+Restart, fix_modify, output, run start/stop, minimize info
+"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
+
+No information about this fix is written to :doc:`binary restart files `.
+
+The :doc:`fix_modify ` *press* option is
+supported by this fix. You can use it to assign a
+:doc:`compute ` you have defined to this fix which will be used
+in its pressure calculations.
+
+No global or per-atom quantities are stored by this fix for access by
+various :doc:`output commands `.
+
+This fix can ramp its target pressure and temperature over multiple runs, using
+the *start* and *stop* keywords of the :doc:`run ` command. See the
+:doc:`run ` command for details of how to do this. It is recommended that
+the ramped temperature is the same as the effective temperature of the
+thermostatted system. That is, if the system's temperature is ramped by other
+commands, it is recommended to do the same with this pressure control.
+
+This fix is not invoked during :doc:`energy minimization `.
+
+Restrictions
+""""""""""""
+
+Any dimension being adjusted by this fix must be periodic.
+
+Related commands
+""""""""""""""""
+
+:doc:`fix press/berendsen `,
+:doc:`fix nve `, :doc:`fix nph `, :doc:`fix npt `, :doc:`fix langevin `,
+:doc:`fix_modify `
+
+Default
+"""""""
+
+The keyword defaults are *dilate* = all, *flip* = yes, and *friction* = *Pdamp*.
+
+----------
+
+.. _Gronbech:
+
+**(Gronbech)** Gronbech-Jensen, Farago, J Chem Phys, 141, 194108 (2014).
diff --git a/doc/src/fix_rigid.rst b/doc/src/fix_rigid.rst
index 89759da817..a50e215681 100644
--- a/doc/src/fix_rigid.rst
+++ b/doc/src/fix_rigid.rst
@@ -843,7 +843,7 @@ stress/atom ` commands. The former can be
accessed by :doc:`thermodynamic output `. The default
setting for this fix is :doc:`fix_modify virial yes `.
-All of the *rigid* styles (not the *rigid/small* styles) compute a
+All of the *rigid* styles (but not the *rigid/small* styles) compute a
global array of values which can be accessed by various :doc:`output
commands `. Similar information about the bodies
defined by the *rigid/small* styles can be accessed via the
@@ -887,7 +887,8 @@ Restrictions
""""""""""""
These fixes are all part of the RIGID package. It is only enabled if
-LAMMPS was built with that package. See the :doc:`Build package ` page for more info.
+LAMMPS was built with that package. See the :doc:`Build package
+` page for more info.
Assigning a temperature via the :doc:`velocity create `
command to a system with :doc:`rigid bodies ` may not have
diff --git a/doc/src/fix_spring_self.rst b/doc/src/fix_spring_self.rst
index 3383f27ebb..4453fd61c5 100644
--- a/doc/src/fix_spring_self.rst
+++ b/doc/src/fix_spring_self.rst
@@ -1,4 +1,5 @@
.. index:: fix spring/self
+.. index:: fix spring/self/kk
fix spring/self command
=======================
@@ -80,6 +81,12 @@ invoked by the :doc:`minimize ` command.
you MUST enable the :doc:`fix_modify ` *energy* option for
this fix.
+----------
+
+.. include:: accel_styles.rst
+
+----------
+
Restrictions
""""""""""""
none
diff --git a/doc/src/fix_srd.rst b/doc/src/fix_srd.rst
index 1fc574a7ad..8bfbcf2387 100644
--- a/doc/src/fix_srd.rst
+++ b/doc/src/fix_srd.rst
@@ -71,14 +71,15 @@ imbue the SRD particles with fluid-like properties, including an
effective viscosity. Thus simulations with large solute particles can
be run more quickly, to measure solute properties like diffusivity
and viscosity in a background fluid. The usual LAMMPS fixes for such
-simulations, such as :doc:`fix deform `, :doc:`fix viscosity `, and :doc:`fix nvt/sllod `,
+simulations, such as :doc:`fix deform `,
+:doc:`fix viscosity `, and :doc:`fix nvt/sllod `,
can be used in conjunction with the SRD model.
-For more details on how the SRD model is implemented in LAMMPS, :ref:`this paper ` describes the implementation and usage of pure SRD
-fluids. :ref:`This paper `, which is nearly complete, describes
-the implementation and usage of mixture systems (solute particles in
-an SRD fluid). See the examples/srd directory for sample input
-scripts using SRD particles in both settings.
+For more details on how the SRD model is implemented in LAMMPS,
+:ref:`(Petersen) ` describes the implementation and usage of
+pure SRD fluids. See the ``examples/srd`` directory for sample input
+scripts using SRD particles for that and for mixture systems (solute
+particles in an SRD fluid).
This fix does two things:
@@ -357,28 +358,28 @@ These are the 12 quantities. All are values for the current timestep,
except for quantity 5 and the last three, each of which are
cumulative quantities since the beginning of the run.
-* (1) # of SRD/big collision checks performed
-* (2) # of SRDs which had a collision
-* (3) # of SRD/big collisions (including multiple bounces)
-* (4) # of SRD particles inside a big particle
-* (5) # of SRD particles whose velocity was rescaled to be < Vmax
-* (6) # of bins for collision searching
-* (7) # of bins for SRD velocity rotation
-* (8) # of bins in which SRD temperature was computed
-* (9) SRD temperature
-* (10) # of SRD particles which have undergone max # of bounces
-* (11) max # of bounces any SRD particle has had in a single step
-* (12) # of reneighborings due to SRD particles moving too far
+(1) # of SRD/big collision checks performed
+(2) # of SRDs which had a collision
+(3) # of SRD/big collisions (including multiple bounces)
+(4) # of SRD particles inside a big particle
+(5) # of SRD particles whose velocity was rescaled to be < Vmax
+(6) # of bins for collision searching
+(7) # of bins for SRD velocity rotation
+(8) # of bins in which SRD temperature was computed
+(9) SRD temperature
+(10) # of SRD particles which have undergone max # of bounces
+(11) max # of bounces any SRD particle has had in a single step
+(12) # of reneighborings due to SRD particles moving too far
No parameter of this fix can be used with the *start/stop* keywords of
-the :doc:`run ` command. This fix is not invoked during :doc:`energy minimization `.
+the :doc:`run ` command. This fix is not invoked during
+:doc:`energy minimization `.
Restrictions
""""""""""""
-This command can only be used if LAMMPS was built with the SRD
-package. See the :doc:`Build package ` doc
-page for more info.
+This command can only be used if LAMMPS was built with the SRD package.
+See the :doc:`Build package ` doc page for more info.
Related commands
""""""""""""""""
@@ -403,7 +404,3 @@ no, and rescale = yes.
**(Petersen)** Petersen, Lechman, Plimpton, Grest, in' t Veld, Schunk, J
Chem Phys, 132, 174106 (2010).
-
-.. _Lechman:
-
-**(Lechman)** Lechman, et al, in preparation (2010).
diff --git a/doc/src/pair_ilp_tmd.rst b/doc/src/pair_ilp_tmd.rst
index 482d75a100..70a4768389 100644
--- a/doc/src/pair_ilp_tmd.rst
+++ b/doc/src/pair_ilp_tmd.rst
@@ -22,12 +22,12 @@ Examples
.. code-block:: LAMMPS
pair_style hybrid/overlay ilp/tmd 16.0 1
- pair_coeff * * ilp/tmd TMD.ILP Mo S S
+ pair_coeff * * ilp/tmd MoS2.ILP Mo S S
pair_style hybrid/overlay sw/mod sw/mod ilp/tmd 16.0
pair_coeff * * sw/mod 1 tmd.sw.mod Mo S S NULL NULL NULL
pair_coeff * * sw/mod 2 tmd.sw.mod NULL NULL NULL Mo S S
- pair_coeff * * ilp/tmd TMD.ILP Mo S S Mo S S
+ pair_coeff * * ilp/tmd MoS2.ILP Mo S S Mo S S
Description
"""""""""""
@@ -69,7 +69,7 @@ calculating the normals.
each atom `i`, its six nearest neighboring atoms belonging to the same
sub-layer are chosen to define the normal vector `{\bf n}_i`.
-The parameter file (e.g. TMD.ILP), is intended for use with *metal*
+The parameter file (e.g. MoS2.ILP), is intended for use with *metal*
:doc:`units `, with energies in meV. Two additional parameters,
*S*, and *rcut* are included in the parameter file. *S* is designed to
facilitate scaling of energies. *rcut* is designed to build the neighbor
@@ -77,7 +77,7 @@ list for calculating the normals for each atom pair.
.. note::
- The parameters presented in the parameter file (e.g. TMD.ILP),
+ The parameters presented in the parameter file (e.g. MoS2.ILP),
are fitted with taper function by setting the cutoff equal to 16.0
Angstrom. Using different cutoff or taper function should be careful.
These parameters provide a good description in both short- and long-range
@@ -133,10 +133,10 @@ if LAMMPS was built with that package. See the :doc:`Build package
This pair style requires the newton setting to be *on* for pair
interactions.
-The TMD.ILP potential file provided with LAMMPS (see the potentials
+The MoS2.ILP potential file provided with LAMMPS (see the potentials
directory) are parameterized for *metal* units. You can use this
potential with any LAMMPS units, but you would need to create your own
-custom TMD.ILP potential file with coefficients listed in the appropriate
+custom MoS2.ILP potential file with coefficients listed in the appropriate
units, if your simulation does not use *metal* units.
Related commands
diff --git a/doc/src/pair_reaxff.rst b/doc/src/pair_reaxff.rst
index 4dac9baf85..067eb3afc3 100644
--- a/doc/src/pair_reaxff.rst
+++ b/doc/src/pair_reaxff.rst
@@ -43,22 +43,22 @@ Examples
Description
"""""""""""
-Style *reaxff* computes the ReaxFF potential of van Duin, Goddard and
-co-workers. ReaxFF uses distance-dependent bond-order functions to
+Pair style *reaxff* computes the ReaxFF potential of van Duin, Goddard
+and co-workers. ReaxFF uses distance-dependent bond-order functions to
represent the contributions of chemical bonding to the potential
-energy. There is more than one version of ReaxFF. The version
+energy. There is more than one version of ReaxFF. The version
implemented in LAMMPS uses the functional forms documented in the
supplemental information of the following paper:
-:ref:`(Chenoweth et al., 2008) `. The version integrated
-into LAMMPS matches the version of ReaxFF From Summer 2010. For more
-technical details about the pair reaxff implementation of ReaxFF, see
-the :ref:`(Aktulga) ` paper. The *reaxff* style was initially
-implemented as a stand-alone C code and is now converted to C++ and
-integrated into LAMMPS as a package.
+:ref:`(Chenoweth et al., 2008) ` and matches the
+version of the reference ReaxFF implementation from Summer 2010. For
+more technical details about the implementation of ReaxFF in pair style
+*reaxff*, see the :ref:`(Aktulga) ` paper. The *reaxff* style
+was initially implemented as a stand-alone C code and is now converted
+to C++ and integrated into LAMMPS as a package.
The *reaxff/kk* style is a Kokkos version of the ReaxFF potential that
-is derived from the *reaxff* style. The Kokkos version can run on GPUs
-and can also use OpenMP multithreading. For more information about the
+is derived from the *reaxff* style. The Kokkos version can run on GPUs
+and can also use OpenMP multithreading. For more information about the
Kokkos package, see :doc:`Packages details ` and
:doc:`Speed kokkos ` doc pages. One important
consideration when using the *reaxff/kk* style is the choice of either
diff --git a/doc/src/pair_snap.rst b/doc/src/pair_snap.rst
index ebedb288c1..ffc43c712a 100644
--- a/doc/src/pair_snap.rst
+++ b/doc/src/pair_snap.rst
@@ -1,10 +1,11 @@
.. index:: pair_style snap
+.. index:: pair_style snap/intel
.. index:: pair_style snap/kk
pair_style snap command
=======================
-Accelerator Variants: *snap/kk*
+Accelerator Variants: *snap/intel*, *snap/kk*
Syntax
""""""
@@ -260,6 +261,14 @@ This style is part of the ML-SNAP package. It is only enabled if LAMMPS
was built with that package. See the :doc:`Build package
` page for more info.
+The *snap/intel* accelerator variant will *only* be available if LAMMPS
+is built with Intel *compilers* and for CPUs with AVX-512 support.
+While the INTEL package in general allows multiple floating point
+precision modes to be selected, *snap/intel* will currently always use
+full double precision regardless of the precision mode selected.
+Additionally, the *intel* variant of snap will **NOT** use multiple
+threads with OpenMP.
+
Related commands
""""""""""""""""
diff --git a/doc/src/pair_yukawa_colloid.rst b/doc/src/pair_yukawa_colloid.rst
index 6611ea04e4..c6f201d249 100644
--- a/doc/src/pair_yukawa_colloid.rst
+++ b/doc/src/pair_yukawa_colloid.rst
@@ -1,11 +1,12 @@
.. index:: pair_style yukawa/colloid
.. index:: pair_style yukawa/colloid/gpu
+.. index:: pair_style yukawa/colloid/kk
.. index:: pair_style yukawa/colloid/omp
pair_style yukawa/colloid command
=================================
-Accelerator Variants: *yukawa/colloid/gpu*, *yukawa/colloid/omp*
+Accelerator Variants: *yukawa/colloid/gpu*, *yukawa/colloid/kk*, *yukawa/colloid/omp*
Syntax
""""""
@@ -131,6 +132,12 @@ per-type polydispersity is allowed. This means all particles of the
same type must have the same diameter. Each type can have a different
diameter.
+----------
+
+.. include:: accel_styles.rst
+
+----------
+
Related commands
""""""""""""""""
diff --git a/doc/src/thermo_style.rst b/doc/src/thermo_style.rst
index 63ad59e553..c3c607a479 100644
--- a/doc/src/thermo_style.rst
+++ b/doc/src/thermo_style.rst
@@ -385,19 +385,20 @@ creates a global vector with 6 values.
The *c_ID* and *c_ID[I]* and *c_ID[I][J]* keywords allow global values
calculated by a compute to be output. As discussed on the
:doc:`compute ` doc page, computes can calculate global,
-per-atom, or local values. Only global values can be referenced by
-this command. However, per-atom compute values for an individual atom
-can be referenced in a :doc:`variable ` and the variable
-referenced by thermo_style custom, as discussed below. See the
-discussion above for how the I in *c_ID[I]* can be specified with a
-wildcard asterisk to effectively specify multiple values from a global
-compute vector.
+per-atom, local, and per-grid values. Only global values can be
+referenced by this command. However, per-atom compute values for an
+individual atom can be referenced in a :doc:`equal-style variable
+` and the variable referenced by thermo_style custom, as
+discussed below. See the discussion above for how the I in *c_ID[I]*
+can be specified with a wildcard asterisk to effectively specify
+multiple values from a global compute vector.
The ID in the keyword should be replaced by the actual ID of a compute
that has been defined elsewhere in the input script. See the
-:doc:`compute ` command for details. If the compute calculates
-a global scalar, vector, or array, then the keyword formats with 0, 1,
-or 2 brackets will reference a scalar value from the compute.
+:doc:`compute ` command for details. If the compute
+calculates a global scalar, vector, or array, then the keyword formats
+with 0, 1, or 2 brackets will reference a scalar value from the
+compute.
Note that some computes calculate "intensive" global quantities like
temperature; others calculate "extensive" global quantities like
@@ -410,13 +411,14 @@ norm ` option being used.
The *f_ID* and *f_ID[I]* and *f_ID[I][J]* keywords allow global values
calculated by a fix to be output. As discussed on the :doc:`fix
-` doc page, fixes can calculate global, per-atom, or local
-values. Only global values can be referenced by this command.
-However, per-atom fix values can be referenced for an individual atom
-in a :doc:`variable ` and the variable referenced by
-thermo_style custom, as discussed below. See the discussion above for
-how the I in *f_ID[I]* can be specified with a wildcard asterisk to
-effectively specify multiple values from a global fix vector.
+` doc page, fixes can calculate global, per-atom, local, and
+per-grid values. Only global values can be referenced by this
+command. However, per-atom fix values can be referenced for an
+individual atom in a :doc:`equal-style variable ` and the
+variable referenced by thermo_style custom, as discussed below. See
+the discussion above for how the I in *f_ID[I]* can be specified with
+a wildcard asterisk to effectively specify multiple values from a
+global fix vector.
The ID in the keyword should be replaced by the actual ID of a fix
that has been defined elsewhere in the input script. See the
@@ -438,14 +440,15 @@ output. The name in the keyword should be replaced by the variable
name that has been defined elsewhere in the input script. Only
equal-style and vector-style variables can be referenced; the latter
requires a bracketed term to specify the Ith element of the vector
-calculated by the variable. However, an atom-style variable can be
-referenced for an individual atom by an equal-style variable and that
-variable referenced. See the :doc:`variable ` command for
-details. Variables of style *equal* and *vector* and *atom* define a
-formula which can reference per-atom properties or thermodynamic
-keywords, or they can invoke other computes, fixes, or variables when
-evaluated, so this is a very general means of creating thermodynamic
-output.
+calculated by the variable. However, an equal-style variable can use
+an atom-style variable in its formula indexed by the ID of an
+individual atom. This is a way to output a speciic atom's per-atom
+coordinates or other per-atom properties in thermo output. See the
+:doc:`variable ` command for details. Note that variables
+of style *equal* and *vector* and *atom* define a formula which can
+reference per-atom properties or thermodynamic keywords, or they can
+invoke other computes, fixes, or variables when evaluated, so this is
+a very general means of creating thermodynamic output.
Note that equal-style and vector-style variables are assumed to
produce "intensive" global quantities, which are thus printed as-is,
diff --git a/doc/src/variable.rst b/doc/src/variable.rst
index 28c0d29799..f1a316da1f 100644
--- a/doc/src/variable.rst
+++ b/doc/src/variable.rst
@@ -550,12 +550,11 @@ variables.
Most of the formula elements produce a scalar value. Some produce a
global or per-atom vector of values. Global vectors can be produced
by computes or fixes or by other vector-style variables. Per-atom
-vectors are produced by atom vectors, compute references that
-represent a per-atom vector, fix references that represent a per-atom
-vector, and variables that are atom-style variables. Math functions
-that operate on scalar values produce a scalar value; math function
-that operate on global or per-atom vectors do so element-by-element
-and produce a global or per-atom vector.
+vectors are produced by atom vectors, computes or fixes which output a
+per-atom vector or array, and variables that are atom-style variables.
+Math functions that operate on scalar values produce a scalar value;
+math function that operate on global or per-atom vectors do so
+element-by-element and produce a global or per-atom vector.
A formula for equal-style variables cannot use any formula element
that produces a global or per-atom vector. A formula for a
@@ -564,12 +563,13 @@ scalar value or a global vector value, but cannot use a formula
element that produces a per-atom vector. A formula for an atom-style
variable can use formula elements that produce either a scalar value
or a per-atom vector, but not one that produces a global vector.
+
Atom-style variables are evaluated by other commands that define a
-:doc:`group ` on which they operate, e.g. a :doc:`dump ` or
-:doc:`compute ` or :doc:`fix ` command. When they invoke
-the atom-style variable, only atoms in the group are included in the
-formula evaluation. The variable evaluates to 0.0 for atoms not in
-the group.
+:doc:`group ` on which they operate, e.g. a :doc:`dump `
+or :doc:`compute ` or :doc:`fix