merge with current develop

.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
 

.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
 

.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
 

.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
 

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)

cmake/packaging/MacOSXBundleInfo.plist.in

@@ -17,7 +17,7 @@
 	<key>CFBundleLongVersionString</key>
 	<string>${MACOSX_BUNDLE_LONG_VERSION_STRING}</string>
 	<key>CFBundleName</key>
-	<string>LAMMPS</string>
+	<string>LAMMPS_GUI</string>
 	<key>CFBundlePackageType</key>
 	<string>APPL</string>
 	<key>CFBundleShortVersionString</key>

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
+   MacOS. If you customized MacOS to use a different shell, you'll need to
-   that shell's init file (.cshrc, .bashrc, etc.) instead with appropiate commands
+   modify that shell's init file (.cshrc, .bashrc, etc.) instead with
-   to modify the same environment variables.
+   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
+   Depending on the size and resolution of your screen, the fonts may be too
-   be too small to read. This can be adjusted by setting the environment
+   small to read. This can be adjusted by setting the environment variable
-   variable QT_FONT_DPI. The default value would be 72, so to increase
+   QT_FONT_DPI. The default value would be 72, so to increase the fonts by a
-   the fonts by a third one can add to the .zprofile file the line
+   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
+   MacOS will likely block the initial run of the executables, since they were
-   were downloaded from the internet and are missing a known signature from an
+   downloaded from the internet and are missing a known signature from an
-   identified developer. Go to "Settings" and search for "Security settings". It
+   identified developer. Go to "Settings" and search for "Security settings".
-   should display a message that an executable like "lmp" was blocked. Press
+   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.

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"

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
+mv ${APP_NAME}.app LAMMPS_GUI.app
-cd LAMMPS.app/Contents
+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
+Rez -a icon.rsrc -o LAMMPS_GUI-macOS-multiarch.dmg
-SetFile -a C LAMMPS-macOS-multiarch.dmg
+SetFile -a C LAMMPS_GUI-macOS-multiarch.dmg
 rm icon.rsrc
 
 echo "Delete temporary disk images"

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)

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)

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_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)
+         -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

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
+The CMake scripts in LAMMPS have basic support for being compiled using
-multi-config build system, but not all of it has been ported.  This is in
+a multi-config build system, but not all of it has been ported.  This is
-particular applicable to compiling packages that require additional libraries
+in particular applicable to compiling packages that require additional
-that would be downloaded and compiled by CMake.  The "windows" preset file
+libraries that would be downloaded and compiled by CMake.  The
-tries to keep track of which packages can be compiled natively with the
+``windows.cmake`` preset file tries to keep track of which packages can
-MSVC compilers out-of-the box.  Not all of those external libraries are
+be compiled natively with the MSVC compilers out-of-the box.  Not all of
-portable to Windows, either.
+the external libraries are portable to Windows, either.
 
 
 Installing CMake

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
+      the KOKKOS package and enable some hardware choices.  For GPU
-      with CUDA device parallelization (for GPUs with CC 5.0 and up)
+      support those preset files must be customized to match the
-      with some common packages enabled, you can do the following:
+      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

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 <Build_windows>` and

doc/src/Commands_fix.rst

@@ -69,7 +69,7 @@ OPT.
    * :doc:`drude/transform/inverse <fix_drude_transform>`
    * :doc:`dt/reset (k) <fix_dt_reset>`
    * :doc:`edpd/source <fix_dpd_source>`
-   * :doc:`efield <fix_efield>`
+   * :doc:`efield (k) <fix_efield>`
    * :doc:`efield/tip4p <fix_efield>`
    * :doc:`ehex <fix_ehex>`
    * :doc:`electrode/conp (i) <fix_electrode>`
@@ -181,6 +181,7 @@ OPT.
    * :doc:`pour <fix_pour>`
    * :doc:`precession/spin <fix_precession_spin>`
    * :doc:`press/berendsen <fix_press_berendsen>`
+   * :doc:`press/langevin <fix_press_langevin>`
    * :doc:`print <fix_print>`
    * :doc:`propel/self <fix_propel_self>`
    * :doc:`property/atom (k) <fix_property_atom>`
@@ -232,7 +233,7 @@ OPT.
    * :doc:`spring <fix_spring>`
    * :doc:`spring/chunk <fix_spring_chunk>`
    * :doc:`spring/rg <fix_spring_rg>`
-   * :doc:`spring/self <fix_spring_self>`
+   * :doc:`spring/self (k) <fix_spring_self>`
    * :doc:`srd <fix_srd>`
    * :doc:`store/force <fix_store_force>`
    * :doc:`store/state <fix_store_state>`

doc/src/Commands_pair.rst

@@ -265,7 +265,7 @@ OPT.
    * :doc:`smd/tri_surface <pair_smd_triangulated_surface>`
    * :doc:`smd/ulsph <pair_smd_ulsph>`
    * :doc:`smtbq <pair_smtbq>`
-   * :doc:`snap (k) <pair_snap>`
+   * :doc:`snap (ik) <pair_snap>`
    * :doc:`soft (go) <pair_soft>`
    * :doc:`sph/heatconduction <pair_sph_heatconduction>`
    * :doc:`sph/idealgas <pair_sph_idealgas>`
@@ -305,5 +305,5 @@ OPT.
    * :doc:`wf/cut <pair_wf_cut>`
    * :doc:`ylz <pair_ylz>`
    * :doc:`yukawa (gko) <pair_yukawa>`
-   * :doc:`yukawa/colloid (go) <pair_yukawa_colloid>`
+   * :doc:`yukawa/colloid (gko) <pair_yukawa_colloid>`
    * :doc:`zbl (gko) <pair_zbl>`

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

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

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
+Over the years many of these limitations have been reduced or
-removed, through features added to LAMMPS or external tools
+removed. In part through features added to LAMMPS and in part
-that either closely interface with LAMMPS or extend LAMMPS.
+through external tools that either closely interface with LAMMPS
+or extend LAMMPS.
 
 Here are suggestions on how to perform these tasks:
 
@@ -24,8 +25,9 @@ Here are suggestions on how to perform these tasks:
   wraps the library interface is provided.  Thus, GUI interfaces can be
   written in Python or C/C++ that run LAMMPS and visualize or plot its
   output.  Examples of this are provided in the python directory and
-  described on the :doc:`Python <Python_head>` doc page.  Also, there
+  described on the :doc:`Python <Python_head>` doc page.  As of version
-  are several external wrappers or GUI front ends.
+  2 August 2023 :ref:`a GUI tool <lammps_gui>` is included in LAMMPS.
+  Also, there are several external wrappers or GUI front ends.
 * **Builder:** Several pre-processing tools are packaged with LAMMPS.
   Some of them convert input files in formats produced by other MD codes
   such as CHARMM, AMBER, or Insight into LAMMPS input formats.  Some of

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

doc/src/Manual.rst

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

doc/src/Tools.rst

@@ -645,9 +645,14 @@ LAMMPS GUI
 Overview
 ^^^^^^^^
 
-LAMMPS GUI is a simple graphical text editor that is linked to the
+LAMMPS GUI is a graphical text editor customized for editing LAMMPS
-:ref:`LAMMPS C-library interface <lammps_c_api>` and thus can run LAMMPS
+input files that is linked to the :ref:`LAMMPS C-library <lammps_c_api>`
-directly using the contents of the editor's text buffer as input.
+and thus can run LAMMPS directly using the contents of the editor's text
+buffer as input.  It can retrieve and display information from LAMMPS
+while it is running, display visualizations created with the :doc:`dump
+image command <dump_image>`, and is adapted specifically for editing
+LAMMPS input files through text completion and reformatting, and linking
+to the online LAMMPS documentation for known LAMMPS commands and styles.
 
 This is similar to what people traditionally would do to run LAMMPS:
 using a regular text editor to edit the input and run the necessary
@@ -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
+All features have been extensively exposed to keyboard shortcuts, so
-also appeal for experienced LAMMPS users, too, especially for
+that there is also appeal for experienced LAMMPS users for prototyping
-prototyping and testing simulations setups.
+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
+- Support for most accelerator packages
-- Progress bar indicates that LAMMPS is running
+- Progress bar indicates how far a run command is completed
 - LAMMPS can be started and stopped with a hotkey
 - Screen output is captured in a Log Window
 - Thermodynamic output is captured and displayed as line graph in a Chart Window
+- Indicator for currently executed command
+- Indicator for line that caused an error
 - Visualization of current state in Image Viewer (via :doc:`dump image <dump_image>`)
 - Many adjustable settings and preferences that are persistent
 - Dialog to set variables from the LAMMPS command line
@@ -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 <https://www.qt.io/product/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
+recommended; support for Qt version 6.x is under active development and
-required.  The LAMMPS GUI has been successfully compiled and tested on:
+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),

doc/src/atom_modify.rst

@@ -65,6 +65,11 @@ switch.  This is described on the :doc:`Build_settings <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 <Howto_triclinic>` 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

doc/src/compute.rst

@@ -27,58 +27,62 @@ Examples
 Description
 """""""""""
 
-Define a computation that will be performed on a group of atoms.
+Define a diagnostic computation that will be performed on a group of
-Quantities calculated by a compute are instantaneous values, meaning
+atoms.  Quantities calculated by a compute are instantaneous values,
-they are calculated from information about atoms on the current
+meaning they are calculated from information about atoms on the
-timestep or iteration, though a compute may internally store some
+current timestep or iteration, though internally a compute may store
-information about a previous state of the system.  Defining a compute
+some information about a previous state of the system.  Defining a
-does not perform a computation.  Instead computes are invoked by other
+compute does not perform the computation.  Instead computes are
-LAMMPS commands as needed (e.g., to calculate a temperature needed for
+invoked by other LAMMPS commands as needed (e.g., to calculate a
-a thermostat fix or to generate thermodynamic or dump file output).
+temperature needed for a thermostat fix or to generate thermodynamic
-See the :doc:`Howto output <Howto_output>` page for a summary of
+or dump file output).  See the :doc:`Howto output <Howto_output>` page
-various LAMMPS output options, many of which involve computes.
+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,
+Computes calculate and store any of four *styles* of quantities:
-per-atom, local, or per-atom.  A global quantity is one or more
+global, per-atom, local, or per-grid.
-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 that produce per-atom quantities have the word "atom" at the
+A global quantity is one or more system-wide values, e.g. the
-end of their style, e.g. *ke/atom*\ .  Computes that produce local
+temperature of the system.  A per-atom quantity is one or more values
-quantities have the word "local" at the end of their style,
+per atom, e.g. the kinetic energy of each atom.  Per-atom values are
-e.g. *bond/local*\ .  Computes that produce per-grid quantities have
+set to 0.0 for atoms not in the specified compute group.  Local
-the word "grid" at the end of their style, e.g. *property/grid*\ .
+quantities are calculated by each processor based on the atoms it
-Styles with neither "atom" or "local" or "grid" at the end of their
+owns, but there may be zero or more per atom, e.g. a list of bond
-style name produce global quantities.
+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
+As a general rule of thumb, computes that produce per-atom quantities
-per-atom or local or per-grid values.  It does not compute both global
+have the word "atom" at the end of their style, e.g. *ke/atom*\ .
-and per-atom values.  It can produce local values or per-grid values
+Computes that produce local quantities have the word "local" at the
-in tandem with global or per-atom quantities.  The compute doc page
+end of their style, e.g. *bond/local*\ .  Computes that produce
-will explain the details.
+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:
+Global, per-atom, local, and per-grid quantities can also be of three
-a single scalar value, a vector of values, or a 2d array of values.
+*kinds*: a single scalar value (global only), a vector of values, or a
-The doc page for each compute describes the style and kind of values
+2d array of values.  For per-atom, local, and per-grid quantities, a
-it produces, e.g. a per-atom vector.  Some computes produce more than
+"vector" means a single value for each atom, each local entity
-one kind of a single style, e.g. a global scalar and a global vector.
+(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
+Note that a single compute can produce any combination of global,
-discussed below, it can be referenced via the following bracket
+per-atom, local, or per-grid values.  Likewise it can prouduce any
-notation, where ID is the ID of the compute:
+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
+quantity once (vector :math:`\to` scalar, array :math:`\to` vector).
-brackets reduces the dimension twice (array :math:`\to` scalar).  Thus a
+Using two brackets reduces the dimension twice (array :math:`\to`
-command that uses scalar compute values as input can also process elements of a
+scalar).  Thus, for example, a command that uses global scalar compute
-vector or array.
+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 <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 <variable>` which use compute
+Note that commands and :doc:`variables <variable>` which take compute
-quantities typically do not allow for all kinds (e.g., a command may
+outputs as input typically do not allow for all styles and kinds of
-require a vector of values, not a scalar).  This means there is no
+data (e.g., a command may require global but not per-atom values, or
-ambiguity about referring to a compute quantity as c_ID even if it
+it may require a vector of values, not a scalar).  This means there is
-produces, for example, both a scalar and vector.  The doc pages for
+typically no ambiguity about referring to a compute output as c_ID
-various commands explain the details.
+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.
 
 ----------
 

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
+scalar values, one per listed input.  For the compute reduce command,
-local quantities; they cannot be global quantities.  Atom attributes
+the inputs can be either per-atom or local quantities and must all be
-are per-atom quantities, :doc:`computes <compute>` and :doc:`fixes <fix>`
+of the same kind (per-atom or local); see discussion of the optional
-may generate any of the three kinds of quantities, and :doc:`atom-style variables <variable>` generate per-atom quantities.  See the
+*inputs* keyword below.  The compute reduce/region command can only be
-:doc:`variable <variable>` command and its special functions which can
+used with per-atom inputs.
-perform the same operations as the compute reduce command on global
+
-vectors.
+Atom attributes are per-atom quantities, :doc:`computes <compute>` and
+:doc:`fixes <fix>` can generate either per-atom or local quantities,
+and :doc:`atom-style variables <variable>` generate per-atom
+quantities.  See the :doc:`variable <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
+vector values into a global total, then divides by the number of
-in the vector.  The *sumsq* option sums the square of the values in the
+values in the vector.  The *sumsq* option sums the square of the
-vector into a global total.  The *avesq* setting does the same as *sumsq*,
+values in the vector into a global total.  The *avesq* setting does
-then divides the sum of squares by the number of values.  The last two options
+the same as *sumsq*, then divides the sum of squares by the number of
-can be useful for calculating the variance of some quantity (e.g., variance =
+values.  The last two options can be useful for calculating the
-sumsq :math:`-` ave\ :math:`^2`).  The *sumabs* option sums the absolute
+variance of some quantity (e.g., variance = sumsq :math:`-` ave\
-values in the vector into a global total.  The *aveabs* setting does the same
+:math:`^2`).  The *sumabs* option sums the absolute values in the
-as *sumabs*, then divides the sum of absolute values by the number of
+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
+group contribute to the result.  Likewise for per-atom inputs, if the
-reduce/region command is used, the atoms must also currently be within
+compute reduce/region command is used, the atoms must also currently
-the region.  Note that an input that produces per-atom quantities may
+be within the region.  Note that an input that produces per-atom
-define its own group which affects the quantities it returns.  For
+quantities may define its own group which affects the quantities it
-example, if a compute is used as an input which generates a per-atom
+returns.  For example, if a compute is used as an input which
-vector, it will generate values of 0.0 for atoms that are not in the
+generates a per-atom vector, it will generate values of 0.0 for atoms
-group specified for that compute.
+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 <compute>` or
@@ -123,52 +132,54 @@ array with six columns:
 
 ----------
 
-The atom attribute values (*x*, *y*, *z*, *vx*, *vy*, *vz*, *fx*, *fy*, and
+The atom attribute values (*x*, *y*, *z*, *vx*, *vy*, *vz*, *fx*,
-*fz*) are self-explanatory.  Note that other atom attributes can be used as
+*fy*, and *fz*) are self-explanatory.  Note that other atom attributes
-inputs to this fix by using the
+can be used as inputs to this fix by using the :doc:`compute
-:doc:`compute property/atom <compute_property_atom>` command and then specifying
+property/atom <compute_property_atom>` command and then specifying an
-an input value from that compute.
+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
+previously defined in the input script.  Valid computes can generate
-per-atom or local quantities.  See the individual
+per-atom or local quantities.  See the individual :doc:`compute
-:doc:`compute <compute>` page for details.  If no bracketed integer
+<compute>` page for details.  If no bracketed integer is appended, the
-is appended, the vector calculated by the compute is used.  If a
+vector calculated by the compute is used.  If a bracketed integer is
-bracketed integer is appended, the Ith column of the array calculated
+appended, the Ith column of the array calculated by the compute is
-by the compute is used.  Users can also write code for their own
+used.  Users can also write code for their own compute styles and
-compute styles and :doc:`add them to LAMMPS <Modify>`.  See the
+:doc:`add them to LAMMPS <Modify>`.  See the discussion above for how
-discussion above for how :math:`I` can be specified with a wildcard asterisk
+:math:`I` can be specified with a wildcard asterisk to effectively
-to effectively specify multiple values.
+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
+previously defined in the input script.  Valid fixes can generate
-or local quantities.  See the individual :doc:`fix <fix>` page for
+per-atom or local quantities.  See the individual :doc:`fix <fix>`
-details.  Note that some fixes only produce their values on certain
+page for details.  Note that some fixes only produce their values on
-timesteps, which must be compatible with when compute reduce
+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 <Modify>`.  See the discussion above for how
-:math:`I` can be specified with a wildcard asterisk to effectively specify
+:math:`I` can be specified with a wildcard asterisk to effectively
-multiple values.
+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 <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.
+specified, where each index ranges from 1 to the number of input
-The replace keyword can only be used if the *mode* is *min* or *max*\ .
+values.  The replace keyword can only be used if the *mode* is *min*
-It works as follows.  A min/max is computed as usual on the *vec2*
+or *max*\ .  It works as follows.  A min/max is computed as usual on
-input vector.  The index :math:`N` of that value within *vec2* is also stored.
+the *vec2* input vector.  The index :math:`N` of that value within
-Then, instead of performing a min/max on the *vec1* input vector, the
+*vec2* is also stored.  Then, instead of performing a min/max on the
-stored index is used to select the :math:`N`\ th element of the *vec1* vector.
+*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 <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)
+As discussed below, for the *sum*, *sumabs*, and *sumsq* modes, the
-produced by this compute are all "extensive", meaning their value
+value(s) produced by this compute are all "extensive", meaning their
-scales linearly with the number of atoms involved.  If normalized
+value scales linearly with the number of atoms involved.  If
-values are desired, this compute can be accessed by the
+normalized values are desired, this compute can be accessed by the
 :doc:`thermo_style custom <thermo_style>` command with
-:doc:`thermo_modify norm yes <thermo_modify>` set as an option.
+:doc:`thermo_modify norm yes <thermo_modify>` set as an option.  Or it
-Or it can be accessed by a
+can be accessed by a :doc:`variable <variable>` that divides by the
-:doc:`variable <variable>` that divides by the appropriate atom count.
+appropriate atom count.
 
 ----------
 
 Output info
 """""""""""
 
-This compute calculates a global scalar if a single input value is specified
+This compute calculates a global scalar if a single input value is
-or a global vector of length :math:`N`, where :math:`N` is the number of
+specified or a global vector of length :math:`N`, where :math:`N` is
-inputs, and which can be accessed by indices 1 to :math:`N`.  These values can
+the number of inputs, and which can be accessed by indices 1 to
-be used by any command that uses global scalar or vector values from a
+:math:`N`.  These values can be used by any command that uses global
-compute as input.  See the :doc:`Howto output <Howto_output>` doc page
+scalar or vector values from a compute as input.  See the :doc:`Howto
-for an overview of LAMMPS output options.
+output <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 <units>` the
+The scalar or vector values will be in whatever :doc:`units <units>`
-quantities being reduced are in.
+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.

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.

doc/src/compute_voronoi_atom.rst

@@ -13,7 +13,7 @@ Syntax
 * ID, group-ID are documented in :doc:`compute <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.
+Two per-atom quantities are calculated by this compute.  The first is
-The first is the volume of the Voronoi cell around each atom.  Any
+the volume of the Voronoi cell around each atom.  Any point in an
-point in an atom's Voronoi cell is closer to that atom than any other.
+atom's Voronoi cell is closer to that atom than any other.  The second
-The second is the number of faces of the Voronoi cell. This is
+is the number of faces of the Voronoi cell. This is equal to the
-equal to the number of nearest neighbors of the central atom,
+number of nearest neighbors of the central atom, plus any exterior
-plus any exterior faces (see note below). If the *peratom* keyword
+faces (see note below).
-is set to "no", the per-atom quantities are still calculated,
-but they are not accessible.
 
 ----------
 
@@ -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
+group. The argument *maxedge* of the this keyword is the largest
-of edges on a single Voronoi cell face expected to occur in the
+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
+sample. This keyword generates output of a global vector by this
-*maxedge*\ +1 entries. The last entry in the vector contains the number of
+compute with *maxedge*\ +1 entries. The last entry in the vector
-faces with more than *maxedge* edges. Since the polygon with the
+contains the number of faces with more than *maxedge* edges. Since the
-smallest amount of edges is a triangle, entries 1 and 2 of the vector
+polygon with the smallest amount of edges is a triangle, entries 1 and
-will always be zero.
+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
+If the *neighbors* value is set to yes, then this compute also creates
-local array with 3 columns. There is one row for each face of each
+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
+If the *face_threshold* keyword is used, then only faces with areas
-with areas greater than the threshold are stored.
+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 calculation of Voronoi volumes is performed by each processor
-   the atoms it owns, and includes the effect of ghost atoms stored by
+   for the atoms it owns, and includes the effect of ghost atoms
-   the processor.  This assumes that the Voronoi cells of owned atoms
+   stored by the processor.  This assumes that the Voronoi cells of
-   are not affected by atoms beyond the ghost atom cut-off distance.
+   owned atoms are not affected by atoms beyond the ghost atom cut-off
-   This is usually a good assumption for liquid and solid systems, but
+   distance.  This is usually a good assumption for liquid and solid
-   may lead to underestimation of Voronoi volumes in low density
+   systems, but may lead to underestimation of Voronoi volumes in low
-   systems.  By default, the set of ghost atoms stored by each processor
+   density systems.  By default, the set of ghost atoms stored by each
-   is determined by the cutoff used for :doc:`pair_style <pair_style>`
+   processor is determined by the cutoff used for :doc:`pair_style
-   interactions.  The cutoff can be set explicitly via the
+   <pair_style>` interactions.  The cutoff can be set explicitly via
-   :doc:`comm_modify cutoff <comm_modify>` command.  The Voronoi cells
+   the :doc:`comm_modify cutoff <comm_modify>` command.  The Voronoi
-   for atoms adjacent to empty regions will extend into those regions up
+   cells for atoms adjacent to empty regions will extend into those
-   to the communication cutoff in :math:`x`, :math:`y`, or :math:`z`.
+   regions up to the communication cutoff in :math:`x`, :math:`y`, or
-   In that situation, an exterior face is created at the cutoff distance
+   :math:`z`.  In that situation, an exterior face is created at the
-   normal to the :math:`x`, :math:`y`, or :math:`z` direction.  For
+   cutoff distance normal to the :math:`x`, :math:`y`, or :math:`z`
-   triclinic systems, the exterior face is parallel to the corresponding
+   direction.  For triclinic systems, the exterior face is parallel to
-   reciprocal lattice vector.
+   the corresponding reciprocal lattice vector.
 
 .. note::
 
-   The Voro++ package performs its calculation in 3d.  This will
+   The Voro++ package performs its calculation in 3d.  This will still
-   still work for a 2d LAMMPS simulation, provided all the atoms have the
+   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
+   same :math:`z`-coordinate. The Voronoi cell of each atom will be a
-   polyhedron with constant cross-sectional area along the :math:`z`-direction
+   columnar polyhedron with constant cross-sectional area along the
-   and two exterior faces at the top and bottom of the simulation box. If
+   :math:`z`-direction and two exterior faces at the top and bottom of
-   the atoms do not all have the same :math:`z`-coordinate, then the columnar
+   the simulation box. If the atoms do not all have the same
-   cells will be accordingly distorted. The cross-sectional area of each
+   :math:`z`-coordinate, then the columnar cells will be accordingly
-   Voronoi cell can be obtained by dividing its volume by the :math:`z` extent
+   distorted. The cross-sectional area of each Voronoi cell can be
-   of the simulation box.  Note that you define the :math:`z` extent of the
+   obtained by dividing its volume by the :math:`z` extent of the
-   simulation box for 2d simulations when using the
+   simulation box.  Note that you define the :math:`z` extent of the
-   :doc:`create_box <create_box>` or :doc:`read_data <read_data>` commands.
+   simulation box for 2d simulations when using the :doc:`create_box
+   <create_box>` or :doc:`read_data <read_data>` commands.
 
 Output info
 """""""""""
 
-By default, this compute calculates a per-atom array with two
+.. deprecated:: TBD
-columns. In regular dynamic tessellation mode the first column is the
+
-Voronoi volume, the second is the neighbor count, as described above
+   The *peratom* keyword was removed as it is no longer required.
-(read above for the output data in case the *occupation* keyword is
+
-specified).  These values can be accessed by any command that uses
+This compute calculates a per-atom array with two columns. In regular
-per-atom values from a compute as input.  See the :doc:`Howto output <Howto_output>` page for an overview of LAMMPS output
+dynamic tessellation mode the first column is the Voronoi volume, the
-options. If the *peratom* keyword is set to "no", the per-atom array
+second is the neighbor count, as described above (read above for the
-is still created, but it is not accessible.
+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 <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 <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 <units>` cubed.
 The Voronoi face area will be in distance :doc:`units <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 <Build_package>` page for more info.
+LAMMPS was built with that package.  See the :doc:`Build package
+<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.
-

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,
+Some fixes calculate and store any of four *styles* of quantities:
-per-atom, local, or per-grid, which can be used by other commands or
+global, per-atom, local, or per-grid.
-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.
 
-Note that a single fix typically produces either global or per-atom or
+A global quantity is one or more system-wide values, e.g. the energy
-local or per-grid values (or none at all).  It does not produce both
+of a wall interacting with particles.  A per-atom quantity is one or
-global and per-atom.  It can produce local or per-grid values in
+more values per atom, e.g. the original coordinates of each atom at
-tandem with global or per-atom values.  The fix doc page will explain
+time 0.  Per-atom values are set to 0.0 for atoms not in the specified
-the details.
+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:
+As a general rule of thumb, fixes that produce per-atom quantities
-a single scalar value, a vector of values, or a 2d array of values.
+have the word "atom" at the end of their style, e.g. *ave/atom*\ .
-The doc page for each fix describes the style and kind of values it
+Fixes that produce local quantities have the word "local" at the end
-produces, e.g. a per-atom vector.  Some fixes produce more than one
+of their style, e.g. *store/local*\ .  Fixes that produce per-grid
-kind of a single style, e.g. a global scalar and a global vector.
+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
+Global, per-atom, local, and per-grid quantities can also be of three
-discussed below, it can be referenced via the following bracket
+*kinds*: a single scalar value (global only), a vector of values, or a
-notation, where ID is the ID of the fix:
+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
+quantity once (vector :math:`\to` scalar, array :math:`\to` vector).
-brackets reduces the dimension twice (array :math:`\to` scalar).  Thus, a
+Using two brackets reduces the dimension twice (array :math:`\to`
-command that uses scalar fix values as input can also process elements of a
+scalar).  Thus, for example, a command that uses global scalar fix
-vector or array.
+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 <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 <variable>` that use fix
+Note that commands and :doc:`variables <variable>` which take fix
-quantities typically do not allow for all kinds (e.g., a command may
+outputs as input typically do not allow for all styles and kinds of
-require a vector of values, not a scalar), and even if they do, the context
+data (e.g., a command may require global but not per-atom values, or
-in which they are called can be used to resolve which output is being
+it may require a vector of values, not a scalar).  This means there is
-requested.  This means there is no
+typically no ambiguity about referring to a fix output as c_ID even if
-ambiguity about referring to a fix quantity as f_ID even if it
+it produces, for example, both a scalar and vector.  The doc pages for
-produces, for example, both a scalar and vector.  The doc pages for
+various commands explain the details, including how any ambiguities
-various commands explain the details.
+are resolved.
 
 ----------
 
@@ -333,6 +346,7 @@ accelerated styles exist.
 * :doc:`pour <fix_pour>` - pour new atoms/molecules into a granular simulation domain
 * :doc:`precession/spin <fix_precession_spin>` - apply a precession torque to each magnetic spin
 * :doc:`press/berendsen <fix_press_berendsen>` - pressure control by Berendsen barostat
+* :doc:`press/langevin <fix_press_langevin>` - pressure control by Langevin barostat
 * :doc:`print <fix_print>` - print text and variables during a simulation
 * :doc:`propel/self <fix_propel_self>` - model self-propelled particles
 * :doc:`property/atom <fix_property_atom>` - add customized per-atom values

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 <Howto_output>`, and can also be written to a file.  The
+timescales.  The resulting histogram can be used by other :doc:`output
-fix ave/histo/weight command has identical syntax to fix ave/histo,
+commands <Howto_output>`, and can also be written to a file.  The fix
-except that exactly two values must be specified.  See details below.
+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 <compute>` or
-:doc:`fix <fix>` or the evaluation of an equal-style or vector-style or
+:doc:`fix <fix>` or the evaluation of an equal-style or vector-style
-atom-style :doc:`variable <variable>`.  The set of input values can be
+or atom-style :doc:`variable <variable>`.  The set of input values can
-either all global, all per-atom, or all local quantities.  Inputs of
+be either all global, all per-atom, or all local quantities.  Inputs
-different kinds (e.g. global and per-atom) cannot be mixed.  Atom
+of different kinds (e.g. global and per-atom) cannot be mixed.  Atom
-attributes are per-atom vector values.  See the page for
+attributes are per-atom vector values.  See the page for individual
-individual "compute" and "fix" commands to see what kinds of
+"compute" and "fix" commands to see what kinds of quantities they
-quantities they generate.  See the optional *kind* keyword below for
+generate.
-how to force the fix ave/histo command to disambiguate if necessary.
+
+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
+The *kind* keyword only needs to be used if any of the specfied input
-more than one kind of output (global, per-atom, local).  If this is
+computes or fixes produce more than one kind of output (global,
-not the case, then LAMMPS will determine what kind of input is
+per-atom, local).  If not, LAMMPS will determine the kind of data all
-provided and whether all the input arguments are consistent.  If a
+the inputs produce and verify it is all the same kind.  If not, an
-compute or fix produces more than one kind of output, the *kind*
+error will be triggered.  If a compute or fix produces more than one
-keyword should be used to specify which output will be used.  The
+kind of output, the *kind* keyword should be used to specify which
-remaining input arguments must still be consistent.
+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

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 <fix_modify>` *energy* option for this fix.
 
+----------
+
+.. include:: accel_styles.rst
+
+----------
+
 Restrictions
 """"""""""""
 

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
 """""""""""

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 <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) <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 <fix_nh>` or :doc:`fix nph <fix_nh>` 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 <fix_nve>` or :doc:`fix nvt <fix_nh>` 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
+   <fix_nh>` or :doc:`fix langevin <fix_langevin>` or :doc:`fix temp/berendsen
+   <fix_temp_berendsen>`.
+
+See the :doc:`Howto barostat <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 <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 <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 <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 <thermo_style>` command) with ID = *thermo_press*. This
+means you can change the attributes of this fix's pressure via the
+:doc:`compute_modify <compute_modify>` command or print this temperature or
+pressure during thermodynamic output via the :doc:`thermo_style custom
+<thermo_style>` 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 <restart>`.
+
+The :doc:`fix_modify <fix_modify>` *press* option is
+supported by this fix.  You can use it to assign a
+:doc:`compute <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 <Howto_output>`.
+
+This fix can ramp its target pressure and temperature over multiple runs, using
+the *start* and *stop* keywords of the :doc:`run <run>` command.  See the
+:doc:`run <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 <minimize>`.
+
+Restrictions
+""""""""""""
+
+Any dimension being adjusted by this fix must be periodic.
+
+Related commands
+""""""""""""""""
+
+:doc:`fix press/berendsen <fix_press_berendsen>`,
+:doc:`fix nve <fix_nve>`, :doc:`fix nph <fix_nh>`, :doc:`fix npt <fix_nh>`, :doc:`fix langevin <fix_langevin>`,
+:doc:`fix_modify <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).

doc/src/fix_rigid.rst

@@ -843,7 +843,7 @@ stress/atom <compute_stress_atom>` commands.  The former can be
 accessed by :doc:`thermodynamic output <thermo_style>`.  The default
 setting for this fix is :doc:`fix_modify virial yes <fix_modify>`.
 
-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 <Howto_output>`.  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 <Build_package>` page for more info.
+LAMMPS was built with that package.  See the :doc:`Build package
+<Build_package>` page for more info.
 
 Assigning a temperature via the :doc:`velocity create <velocity>`
 command to a system with :doc:`rigid bodies <fix_rigid>` may not have

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 <minimize>` command.
    you MUST enable the :doc:`fix_modify <fix_modify>` *energy* option for
    this fix.
 
+----------
+
+.. include:: accel_styles.rst
+
+----------
+
 Restrictions
 """"""""""""
  none

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 <fix_deform>`, :doc:`fix viscosity <fix_viscosity>`, and :doc:`fix nvt/sllod <fix_nvt_sllod>`,
+simulations, such as :doc:`fix deform <fix_deform>`,
+:doc:`fix viscosity <fix_viscosity>`, and :doc:`fix nvt/sllod <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 <Petersen1>` describes the implementation and usage of pure SRD
+For more details on how the SRD model is implemented in LAMMPS,
-fluids.  :ref:`This paper <Lechman>`, which is nearly complete, describes
+:ref:`(Petersen) <Petersen1>` describes the implementation and usage of
-the implementation and usage of mixture systems (solute particles in
+pure SRD fluids.  See the ``examples/srd`` directory for sample input
-an SRD fluid).  See the examples/srd directory for sample input
+scripts using SRD particles for that and for mixture systems (solute
-scripts using SRD particles in both settings.
+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
+(1) # of SRD/big collision checks performed
-* (2) # of SRDs which had a collision
+(2) # of SRDs which had a collision
-* (3) # of SRD/big collisions (including multiple bounces)
+(3) # of SRD/big collisions (including multiple bounces)
-* (4) # of SRD particles inside a big particle
+(4) # of SRD particles inside a big particle
-* (5) # of SRD particles whose velocity was rescaled to be < Vmax
+(5) # of SRD particles whose velocity was rescaled to be < Vmax
-* (6) # of bins for collision searching
+(6) # of bins for collision searching
-* (7) # of bins for SRD velocity rotation
+(7) # of bins for SRD velocity rotation
-* (8) # of bins in which SRD temperature was computed
+(8) # of bins in which SRD temperature was computed
-* (9) SRD temperature
+(9) SRD temperature
-* (10) # of SRD particles which have undergone max # of bounces
+(10) # of SRD particles which have undergone max # of bounces
-* (11) max # of bounces any SRD particle has had in a single step
+(11) max # of bounces any SRD particle has had in a single step
-* (12) # of reneighborings due to SRD particles moving too far
+(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 <run>` command.  This fix is not invoked during :doc:`energy minimization <minimize>`.
+the :doc:`run <run>` command.  This fix is not invoked during
+:doc:`energy minimization <minimize>`.
 
 Restrictions
 """"""""""""
 
-This command can only be used if LAMMPS was built with the SRD
+This command can only be used if LAMMPS was built with the SRD package.
-package.  See the :doc:`Build package <Build_package>` doc
+See the :doc:`Build package <Build_package>` doc page for more info.
-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).

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 <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

doc/src/pair_reaxff.rst

@@ -43,22 +43,22 @@ Examples
 Description
 """""""""""
 
-Style *reaxff* computes the ReaxFF potential of van Duin, Goddard and
+Pair style *reaxff* computes the ReaxFF potential of van Duin, Goddard
-co-workers.  ReaxFF uses distance-dependent bond-order functions to
+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) <Chenoweth_20082>`.  The version integrated
+:ref:`(Chenoweth et al., 2008) <Chenoweth_20082>` and matches the
-into LAMMPS matches the version of ReaxFF From Summer 2010.  For more
+version of the reference ReaxFF implementation from Summer 2010.  For
-technical details about the pair reaxff implementation of ReaxFF, see
+more technical details about the implementation of ReaxFF in pair style
-the :ref:`(Aktulga) <Aktulga>` paper. The *reaxff* style was initially
+*reaxff*, see the :ref:`(Aktulga) <Aktulga>` paper. The *reaxff* style
-implemented as a stand-alone C code and is now converted to C++ and
+was initially implemented as a stand-alone C code and is now converted
-integrated into LAMMPS as a package.
+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
+is derived from the *reaxff* style.  The Kokkos version can run on GPUs
-and can also use OpenMP multithreading. For more information about the
+and can also use OpenMP multithreading.  For more information about the
 Kokkos package, see :doc:`Packages details <Packages_details>` and
 :doc:`Speed kokkos <Speed_kokkos>` doc pages.  One important
 consideration when using the *reaxff/kk* style is the choice of either

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
 <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
 """"""""""""""""
 

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
 """"""""""""""""
 

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 <compute>` doc page, computes can calculate global,
-per-atom, or local values.  Only global values can be referenced by
+per-atom, local, and per-grid values.  Only global values can be
-this command.  However, per-atom compute values for an individual atom
+referenced by this command.  However, per-atom compute values for an
-can be referenced in a :doc:`variable <variable>` and the variable
+individual atom can be referenced in a :doc:`equal-style variable
-referenced by thermo_style custom, as discussed below.  See the
+<variable>` and the variable referenced by thermo_style custom, as
-discussion above for how the I in *c_ID[I]* can be specified with a
+discussed below.  See the discussion above for how the I in *c_ID[I]*
-wildcard asterisk to effectively specify multiple values from a global
+can be specified with a wildcard asterisk to effectively specify
-compute vector.
+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 <compute>` command for details.  If the compute calculates
+:doc:`compute <compute>` command for details.  If the compute
-a global scalar, vector, or array, then the keyword formats with 0, 1,
+calculates a global scalar, vector, or array, then the keyword formats
-or 2 brackets will reference a scalar value from the compute.
+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 <thermo_modify>` 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
-<fix>` doc page, fixes can calculate global, per-atom, or local
+<fix>` doc page, fixes can calculate global, per-atom, local, and
-values.  Only global values can be referenced by this command.
+per-grid values.  Only global values can be referenced by this
-However, per-atom fix values can be referenced for an individual atom
+command.  However, per-atom fix values can be referenced for an
-in a :doc:`variable <variable>` and the variable referenced by
+individual atom in a :doc:`equal-style variable <variable>` and the
-thermo_style custom, as discussed below.  See the discussion above for
+variable referenced by thermo_style custom, as discussed below.  See
-how the I in *f_ID[I]* can be specified with a wildcard asterisk to
+the discussion above for how the I in *f_ID[I]* can be specified with
-effectively specify multiple values from a global fix vector.
+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
+calculated by the variable.  However, an equal-style variable can use
-referenced for an individual atom by an equal-style variable and that
+an atom-style variable in its formula indexed by the ID of an
-variable referenced.  See the :doc:`variable <variable>` command for
+individual atom.  This is a way to output a speciic atom's per-atom
-details.  Variables of style *equal* and *vector* and *atom* define a
+coordinates or other per-atom properties in thermo output.  See the
-formula which can reference per-atom properties or thermodynamic
+:doc:`variable <variable>` command for details.  Note that variables
-keywords, or they can invoke other computes, fixes, or variables when
+of style *equal* and *vector* and *atom* define a formula which can
-evaluated, so this is a very general means of creating thermodynamic
+reference per-atom properties or thermodynamic keywords, or they can
-output.
+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,

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
+vectors are produced by atom vectors, computes or fixes which output a
-represent a per-atom vector, fix references that represent a per-atom
+per-atom vector or array, and variables that are atom-style variables.
-vector, and variables that are atom-style variables.  Math functions
+Math functions that operate on scalar values produce a scalar value;
-that operate on scalar values produce a scalar value; math function
+math function that operate on global or per-atom vectors do so
-that operate on global or per-atom vectors do so element-by-element
+element-by-element and produce a global or per-atom vector.
-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 <group>` on which they operate, e.g. a :doc:`dump <dump>` or
+:doc:`group <group>` on which they operate, e.g. a :doc:`dump <dump>`
-:doc:`compute <compute>` or :doc:`fix <fix>` command.  When they invoke
+or :doc:`compute <compute>` or :doc:`fix <fix>` command.  When they
-the atom-style variable, only atoms in the group are included in the
+invoke the atom-style variable, only atoms in the group are included
-formula evaluation.  The variable evaluates to 0.0 for atoms not in
+in the formula evaluation.  The variable evaluates to 0.0 for atoms
-the group.
+not in the group.
 
 ----------
 
@@ -1138,69 +1138,74 @@ only defined if an :doc:`atom_style <atom_style>` is being used that
 defines molecule IDs.
 
 Note that many other atom attributes can be used as inputs to a
-variable by using the :doc:`compute property/atom <compute_property_atom>` command and then specifying
+variable by using the :doc:`compute property/atom
-a quantity from that compute.
+<compute_property_atom>` command and then specifying a quantity from
+that compute.
 
 ----------
 
 Compute References
 ------------------
 
-Compute references access quantities calculated by a
+Compute references access quantities calculated by a :doc:`compute
-:doc:`compute <compute>`.  The ID in the reference should be replaced by
+<compute>`.  The ID in the reference should be replaced by the ID of a
-the ID of a compute defined elsewhere in the input script.  As
+compute defined elsewhere in the input script.
-discussed in the page for the :doc:`compute <compute>` command,
-computes can produce global, per-atom, or local values.  Only global
-and per-atom values can be used in a variable.  Computes can also
-produce a scalar, vector, or array.
 
-An equal-style variable can only use scalar values, which means a
+As discussed on the page for the :doc:`compute <compute>` command,
-global scalar, or an element of a global or per-atom vector or array.
+computes can produce global, per-atom, local, and per-grid values.
-A vector-style variable can use scalar values or a global vector of
+Only global and per-atom values can be used in a variable.  Computes
-values, or a column of a global array of values.  Atom-style variables
+can also produce scalars (global only), vectors, and arrays.  See the
-can use global scalar values.  They can also use per-atom vector
+doc pages for individual computes to see what different kinds of data
-values, or a column of a per-atom array.  See the doc pages for
+they produce.
-individual computes to see what kind of values they produce.
 
-Examples of different kinds of compute references are as follows.
+An equal-style variable can only use scalar values, either from global
-There is typically no ambiguity (see exception below) as to what a
+or per-atom data.  In the case of per-atom data, this would be a value
-reference means, since computes only produce either global or per-atom
+for a specific atom.
-quantities, never both.
 
-+-------------+-------------------------------------------------------------------------------------------------------+
+A vector-style variable can use scalar values (same as for equal-style
-| c_ID       | global scalar, or per-atom vector                                                                      |
+variables), or global vectors of values.  The latter can also be a
-+-------------+-------------------------------------------------------------------------------------------------------+
+column of a global array.
-| c_ID[I]    | Ith element of global vector, or atom I's value in per-atom vector, or Ith column from per-atom array  |
-+-------------+-------------------------------------------------------------------------------------------------------+
-| c_ID[I][J] | I,J element of global array, or atom I's Jth value in per-atom array                                   |
-+-------------+-------------------------------------------------------------------------------------------------------+
 
-For I and J indices, integers can be specified or a variable name,
+Atom-style variables can use scalar values (same as for equal-style
-specified as v_name, where name is the name of the variable.  The
+varaibles), or per-atom vectors of values.  The latter can also be a
-rules for this syntax are the same as for the "Atom Values and
+column of a per-atom array.
-Vectors" discussion above.
 
-One source of ambiguity for compute references is when a vector-style
+The various allowed compute references in the variable formulas for
-variable refers to a compute that produces both a global scalar and a
+equal-, vector-, and atom-style variables are listed in the following
-global vector.  Consider a compute with ID "foo" that does this,
+table:
-referenced as follows by variable "a", where "myVec" is another
-vector-style variable:
 
-.. code-block:: LAMMPS
++--------+------------+------------------------------------------+
+| equal  | c_ID       | global scalar                            |
+| equal  | c_ID[I]    | element of global vector                 |
+| equal  | c_ID[I][J] | element of global array                  |
+| equal  | C_ID[I]    | element of per-atom vector (I = atom ID) |
+| equal  | C_ID[I][J] | element of per-atom array (I = atom ID)  |
++--------+------------+------------------------------------------+
+| vector | c_ID       | global vector                            |
+| vector | c_ID[I]    | column of global array                   |
+---------+------------+------------------------------------------+
+| atom   | c_ID       | per-atom vector                          |
+| atom   | c_ID[I]    | column of per-atom array                 |
++--------+------------+------------------------------------------+
 
-   variable a vector c_foo*v_myVec
+Note that if an equal-style variable formula wishes to access per-atom
+data from a compute, it must use capital "C" as the ID prefix and not
+lower-case "c".
 
-The reference "c_foo" could refer to either the global scalar or
+Also note that if a vector- or atom-style variable formula needs to
-global vector produced by compute "foo".  In this case, "c_foo" will
+access a scalar value from a compute (i.e. the 5 kinds of values in
-always refer to the global scalar, and "C_foo" can be used to
+the first 5 lines of the table), it can not do so directly.  Instead,
-reference the global vector.  Similarly if the compute produces both a
+it can use a reference to an equal-style variable which stores the
-global vector and global array, then "c_foo[I]" will always refer to
+scalar value from the compute.
-an element of the global vector, and "C_foo[I]" can be used to
-reference the Ith column of the global array.
 
-Note that if a variable containing a compute is evaluated directly in
+The I and J indices in these compute references can be integers or can
-an input script (not during a run), then the values accessed by the
+be a variable name, specified as v_name, where name is the name of the
-compute must be current.  See the discussion below about "Variable
+variable.  The rules for this syntax are the same as for indices in
+the "Atom Values and Vectors" discussion above.
+
+If a variable containing a compute is evaluated directly in an input
+script (not during a run), then the values accessed by the compute
+should be current.  See the discussion below about "Variable
 Accuracy".
 
 ----------
@@ -1208,51 +1213,59 @@ Accuracy".
 Fix References
 --------------
 
-Fix references access quantities calculated by a :doc:`fix <compute>`.
+Fix references access quantities calculated by a :doc:`fix <fix>`.
 The ID in the reference should be replaced by the ID of a fix defined
-elsewhere in the input script.  As discussed in the page for the
+elsewhere in the input script.
-:doc:`fix <fix>` command, fixes can produce global, per-atom, or local
-values.  Only global and per-atom values can be used in a variable.
-Fixes can also produce a scalar, vector, or array.  An equal-style
-variable can only use scalar values, which means a global scalar, or
-an element of a global or per-atom vector or array.  Atom-style
-variables can use the same scalar values.  They can also use per-atom
-vector values.  A vector value can be a per-atom vector itself, or a
-column of an per-atom array.  See the doc pages for individual fixes
-to see what kind of values they produce.
 
-The different kinds of fix references are exactly the same as the
+As discussed on the page for the :doc:`fix <fix>` command, fixes can
-compute references listed in the above table, where "c\_" is replaced
+produce global, per-atom, local, and per-grid values.  Only global and
-by "f\_".  Again, there is typically no ambiguity (see exception below)
+per-atom values can be used in a variable.  Fixes can also produce
-as to what a reference means, since fixes only produce either global
+scalars (global only), vectors, and arrays.  See the doc pages for
-or per-atom quantities, never both.
+individual fixes to see what different kinds of data they produce.
 
-+-------------+-------------------------------------------------------------------------------------------------------+
+An equal-style variable can only use scalar values, either from global
-| f_ID       | global scalar, or per-atom vector                                                                      |
+or per-atom data.  In the case of per-atom data, this would be a value
-+-------------+-------------------------------------------------------------------------------------------------------+
+for a specific atom.
-| f_ID[I]    | Ith element of global vector, or atom I's value in per-atom vector, or Ith column from per-atom array  |
-+-------------+-------------------------------------------------------------------------------------------------------+
-| f_ID[I][J] | I,J element of global array, or atom I's Jth value in per-atom array                                   |
-+-------------+-------------------------------------------------------------------------------------------------------+
 
-For I and J indices, integers can be specified or a variable name,
+A vector-style variable can use scalar values (same as for equal-style
-specified as v_name, where name is the name of the variable.  The
+variables), or global vectors of values.  The latter can also be a
-rules for this syntax are the same as for the "Atom Values and
+column of a global array.
-Vectors" discussion above.
 
-One source of ambiguity for fix references is the same ambiguity
+Atom-style variables can use scalar values (same as for equal-style
-discussed for compute references above.  Namely when a vector-style
+varaibles), or per-atom vectors of values.  The latter can also be a
-variable refers to a fix that produces both a global scalar and a
+column of a per-atom array.
-global vector.  The solution is the same as for compute references.
-For a fix with ID "foo", "f_foo" will always refer to the global
-scalar, and "F_foo" can be used to reference the global vector.  And
-similarly for distinguishing between a fix's global vector versus
-global array with "f_foo[I]" versus "F_foo[I]".
 
-Note that if a variable containing a fix is evaluated directly in an
+The allowed fix references in variable formulas for equal-, vector-,
-input script (not during a run), then the values accessed by the fix
+and atom-style variables are listed in the following table:
-should be current.  See the discussion below about "Variable
+
-Accuracy".
++--------+------------+------------------------------------------+
+| equal  | f_ID       | global scalar                            |
+| equal  | f_ID[I]    | element of global vector                 |
+| equal  | f_ID[I][J] | element of global array                  |
+| equal  | F_ID[I]    | element of per-atom vector (I = atom ID) |
+| equal  | F_ID[I][J] | element of per-atom array (I = atom ID)  |
++--------+------------+------------------------------------------+
+| vector | f_ID       | global vector                            |
+| vector | f_ID[I]    | column of global array                   |
+---------+------------+------------------------------------------+
+| atom   | f_ID       | per-atom vector                          |
+| atom   | f_ID[I]    | column of per-atom array                 |
++--------+------------+------------------------------------------+
+
+Note that if an equal-style variable formula wishes to access per-atom
+data from a fix, it must use capital "F" as the ID prefix and not
+lower-case "f".
+
+Also note that if a vector- or atom-style variable formula needs to
+access a scalar value from a fix (i.e. the 5 kinds of values in the
+first 5 lines of the table), it can not do so directly.  Instead, it
+can use a reference to an equal-style variable which stores the scalar
+value from the fix.
+
+The I and J indices in these fix references can be integers or can be
+a variable name, specified as v_name, where name is the name of the
+variable.  The rules for this syntax are the same as for indices in
+the "Atom Values and Vectors" discussion above.
 
 Note that some fixes only generate quantities on certain timesteps.
 If a variable attempts to access the fix on non-allowed timesteps, an
@@ -1260,6 +1273,10 @@ error is generated.  For example, the :doc:`fix ave/time <fix_ave_time>`
 command may only generate averaged quantities every 100 steps.  See
 the doc pages for individual fix commands for details.
 
+If a variable containing a fix is evaluated directly in an input
+script (not during a run), then the values accessed by the fix should
+be current.  See the discussion below about "Variable Accuracy".
+
 ----------
 
 Variable References
@@ -1294,26 +1311,32 @@ including other atom-style or atomfile-style variables.  If it uses a
 vector-style variable, a subscript must be used to access a single
 value from the vector-style variable.
 
-Examples of different kinds of variable references are as follows.
+The allowed variable references in variable formulas for equal-,
-There is no ambiguity as to what a reference means, since variables
+vector-, and atom-style variables are listed in the following table.
-produce only a global scalar or global vector or per-atom vector.
+Note that there is no ambiguity as to what a reference means, since
+referenced variables produce only a global scalar or global vector or
+per-atom vector.
 
-+------------+----------------------------------------------------------------------+
++--------+-----------+-----------------------------------------------------------------------------------+
-| v_name    | global scalar from equal-style variable                               |
+| equal  | v_name    | global scalar from an equal-style variable                                        |
-+------------+----------------------------------------------------------------------+
+| equal  | v_name[I] | element of global vector from a vector-style variable                             |
-| v_name    | global vector from vector-style variable                              |
+| equal  | v_name[I] | element of per-atom vector (I = atom ID) from an atom- or atomfile-style variable |
-+------------+----------------------------------------------------------------------+
++--------+-----------+-----------------------------------------------------------------------------------+
-| v_name    | per-atom vector from atom-style or atomfile-style variable            |
+| vector | v_name    | global scalar from an equal-style variable                                        |
-+------------+----------------------------------------------------------------------+
+| vector | v_name    | global vector from a vector-style variable                                        |
-| v_name[I] | Ith element of a global vector from vector-style variable             |
+| vector | v_name[I] | element of global vector from a vector-style variable                             |
-+------------+----------------------------------------------------------------------+
+| vector | v_name[I] | element of per-atom vector (I = atom ID) from an atom- or atomfile-style variable |
-| v_name[I] | value of atom with ID = I from atom-style or atomfile-style variable  |
++--------+-----------+-----------------------------------------------------------------------------------+
-+------------+----------------------------------------------------------------------+
+| atom   | v_name    | global scalar from an equal-style variable                                        |
+| atom   | v_name    | per-atom vector from an atom-style or atomfile-style variable                     |
+| atom   | v_name[I] | element of global vector from a vector-style variable                             |
+| atom   | v_name[I] | element of per-atom vector (I = atom ID) from an atom- or atomfile-style variable |
++--------+-----------+-----------------------------------------------------------------------------------+
 
 For the I index, an integer can be specified or a variable name,
 specified as v_name, where name is the name of the variable.  The
-rules for this syntax are the same as for the "Atom Values and
+rules for this syntax are the same as for indices in the "Atom Values
-Vectors" discussion above.
+and Vectors" discussion above.
 
 ----------
 

doc/utils/requirements.txt

@@ -1,4 +1,4 @@
-Sphinx >= 5.3.0, <7.2.0
+Sphinx >= 5.3.0, <8.0
 sphinxcontrib-spelling
 sphinxcontrib-jquery
 git+https://github.com/akohlmey/sphinx-fortran@parallel-read

doc/utils/sphinx-config/false_positives.txt

@@ -1506,6 +1506,7 @@ Im
 imageint
 Imageint
 Imagemagick
+imagename
 imd
 Impey
 impl
@@ -2587,6 +2588,7 @@ Nurdin
 Nvalue
 nvaluelast
 Nvalues
+nvar
 nvc
 nvcc
 nve
@@ -2890,6 +2892,7 @@ pscrozi
 pseudocode
 Pseudocode
 pseudodynamics
+pseudoparticle
 pseudopotential
 psllod
 pSp
@@ -3753,6 +3756,7 @@ uncomment
 uncommented
 uncompress
 uncompute
+underdamped
 underprediction
 undump
 uniaxial

examples/COUPLE/plugin/liblammpsplugin.c

@@ -110,6 +110,7 @@ liblammpsplugin_t *liblammpsplugin_load(const char *lib)
   ADDSYM(extract_variable);
   ADDSYM(extract_variable_datatype);
   ADDSYM(set_variable);
+  ADDSYM(variable_info);
 
   ADDSYM(gather_atoms);
   ADDSYM(gather_atoms_concat);

examples/COUPLE/plugin/liblammpsplugin.h

@@ -106,7 +106,7 @@ typedef void (*FixExternalFnPtr)(void *, int, int, int *, double **, double **);
 typedef void (*FixExternalFnPtr)(void *, int64_t, int, int *, double **, double **);
 #endif
 
-#define LAMMPSPLUGIN_ABI_VERSION 1
+#define LAMMPSPLUGIN_ABI_VERSION 2
 struct _liblammpsplugin {
   int abiversion;
   int has_exceptions;
@@ -127,7 +127,7 @@ struct _liblammpsplugin {
 
   void (*error)(void *, int, const char *);
 
-  void (*file)(void *, char *);
+  void (*file)(void *, const char *);
   char *(*command)(void *, const char *);
   void (*commands_list)(void *, int, const char **);
   void (*commands_string)(void *, const char *);
@@ -155,6 +155,7 @@ struct _liblammpsplugin {
   void *(*extract_variable)(void *, const char *, char *);
   int (*extract_variable_datatype)(void *, const char *);
   int (*set_variable)(void *, char *, char *);
+  int (*variable_info)(void *, int, char *, int);
 
   void (*gather_atoms)(void *, const char *, int, int, void *);
   void (*gather_atoms_concat)(void *, const char *, int, int, void *);

examples/mliap/in.mliap.quadratic.compute

@@ -65,7 +65,7 @@ compute         bsum2 snapgroup2 reduce sum c_b[*]
 # fix 		bsum2 all ave/time 1 1 1 c_bsum2 file bsum2.dat mode vector
 compute		vbsum all reduce sum c_vb[*]
 # fix 		vbsum all ave/time 1 1 1 c_vbsum file vbsum.dat mode vector
-variable	db_2_100 equal c_db[2][100]
+variable	db_2_100 equal C_db[2][100]
 
 # test output:   1: total potential energy
 #                2: xy component of stress tensor

examples/mliap/in.mliap.snap.compute

@@ -65,7 +65,7 @@ compute         bsum2 snapgroup2 reduce sum c_b[*]
 # fix 		bsum2 all ave/time 1 1 1 c_bsum2 file bsum2.dat mode vector
 compute		vbsum all reduce sum c_vb[*]
 # fix 		vbsum all ave/time 1 1 1 c_vbsum file vbsum.dat mode vector
-variable	db_2_25 equal c_db[2][25]
+variable	db_2_25 equal C_db[2][25]
 
 thermo 		100
 

examples/snap/in.grid.snap

@@ -67,18 +67,18 @@ compute 	mygridlocal all sna/grid/local grid ${ngrid} ${ngrid} ${ngrid} &
 
 # define output
 
-variable	B5atom equal c_b[2][5]
+variable	B5atom equal C_b[2][5]
 variable	B5grid equal c_mygrid[8][8]
 
 variable	rmse_global equal "sqrt(   &
 	 (c_mygrid[8][1] - x[2])^2 +      &
 	 (c_mygrid[8][2] - y[2])^2 +      &
 	 (c_mygrid[8][3] - z[2])^2 +      &
-	 (c_mygrid[8][4] - c_b[2][1])^2 + &
+	 (c_mygrid[8][4] - C_b[2][1])^2 + &
-	 (c_mygrid[8][5] - c_b[2][2])^2 + &
+	 (c_mygrid[8][5] - C_b[2][2])^2 + &
-	 (c_mygrid[8][6] - c_b[2][3])^2 + &
+	 (c_mygrid[8][6] - C_b[2][3])^2 + &
-	 (c_mygrid[8][7] - c_b[2][4])^2 + &
+	 (c_mygrid[8][7] - C_b[2][4])^2 + &
-	 (c_mygrid[8][8] - c_b[2][5])^2   &
+	 (c_mygrid[8][8] - C_b[2][5])^2   &
 	 )"
 
 thermo_style	custom step v_B5atom v_B5grid v_rmse_global

examples/snap/in.grid.tri

@@ -87,18 +87,18 @@ compute 	mygridlocal all sna/grid/local grid ${ngridx} ${ngridy} ${ngridz} &
 
 # define output
 
-variable	B5atom equal c_b[7][5]
+variable	B5atom equal C_b[7][5]
 variable	B5grid equal c_mygrid[13][8]
 
 # do not compare x,y,z because assignment of ids
 # to atoms is not unnique for different processor grids
 
 variable	rmse_global equal "sqrt(    &
-	 (c_mygrid[13][4] - c_b[7][1])^2 + &
+	 (c_mygrid[13][4] - C_b[7][1])^2 + &
-	 (c_mygrid[13][5] - c_b[7][2])^2 + &
+	 (c_mygrid[13][5] - C_b[7][2])^2 + &
-	 (c_mygrid[13][6] - c_b[7][3])^2 + &
+	 (c_mygrid[13][6] - C_b[7][3])^2 + &
-	 (c_mygrid[13][7] - c_b[7][4])^2 + &
+	 (c_mygrid[13][7] - C_b[7][4])^2 + &
-	 (c_mygrid[13][8] - c_b[7][5])^2   &
+	 (c_mygrid[13][8] - C_b[7][5])^2   &
 	 )"
 
 thermo_style	custom step v_B5atom v_B5grid v_rmse_global

examples/snap/in.snap.compute

@@ -70,7 +70,7 @@ compute         bsum2 snapgroup2 reduce sum c_b[*]
 # fix 		bsum2 all ave/time 1 1 1 c_bsum2 file bsum2.dat mode vector
 compute		vbsum all reduce sum c_vb[*]
 # fix 		vbsum all ave/time 1 1 1 c_vbsum file vbsum.dat mode vector
-variable	db_2_25 equal c_db[2][25]
+variable	db_2_25 equal C_db[2][25]
 
 # set up compute snap generating global array
 

examples/snap/in.snap.compute.quadratic

@@ -70,7 +70,7 @@ compute         bsum2 snapgroup2 reduce sum c_b[*]
 # fix 		bsum2 all ave/time 1 1 1 c_bsum2 file bsum2.dat mode vector
 compute		vbsum all reduce sum c_vb[*]
 # fix 		vbsum all ave/time 1 1 1 c_vbsum file vbsum.dat mode vector
-variable	db_2_100 equal c_db[2][100]
+variable	db_2_100 equal C_db[2][100]
 
 # set up compute snap generating global array
 

examples/voronoi/in.voronoi

@@ -146,10 +146,10 @@ variable i2 equal 257
 compute v1 all voronoi/atom occupation
 compute r0 all   reduce sum c_v1[1]
 compute r1 all   reduce sum c_v1[2]
-variable d5a equal c_v1[${i1}][1]
+variable d5a equal C_v1[${i1}][1]
-variable d5b equal c_v1[${i2}][1]
+variable d5b equal C_v1[${i2}][1]
-variable d5c equal c_v1[${i1}][2]
+variable d5c equal C_v1[${i1}][2]
-variable d5d equal c_v1[${i2}][2]
+variable d5d equal C_v1[${i2}][2]
 thermo_style custom c_r0 c_r1 v_d5a v_d5b v_d5c v_d5d
 
 run 0

examples/voronoi/in.voronoi.data

@@ -63,11 +63,9 @@ undump          dlocal
 # TEST 2: 
 #
 
-# This compute voronoi generates  
+# This compute voronoi generates peratom and local and global quantities
-# local and global quantities, but
-# not per-atom quantities
 
-compute 	v2 all voronoi/atom neighbors yes edge_histo 6 peratom no
+compute 	v2 all voronoi/atom neighbors yes edge_histo 6
 
 # write voronoi local quantities to a file
 
@@ -75,7 +73,7 @@ dump            d2 all local  1 dump.neighbors2 index c_v2[1] c_v2[2] c_v2[3]
 
 # sum up a voronoi local quantity
 
-compute 	sumarea all reduce sum c_v2[3]
+compute 	sumarea all reduce sum c_v2[3] inputs local
 
 # output voronoi global quantities
 
@@ -83,6 +81,3 @@ thermo_style 	custom c_sumarea c_v2[3] c_v2[4] c_v2[5] c_v2[6] c_v2[7]
 thermo 		1
 
 run  		0
-
-
-

lib/colvars/colvar.cpp

@@ -30,6 +30,7 @@ colvar::colvar()
   after_restart = false;
   kinetic_energy = 0.0;
   potential_energy = 0.0;
+  period = 0.0;
 
 #ifdef LEPTON
   dev_null = 0.0;

lib/machdyn/Install.py

@@ -31,8 +31,8 @@ checksums = { \
 # help message
 
 HELP = """
-Syntax from src dir: make lib-smd args="-b"
+Syntax from src dir: make lib-machdyn args="-b"
-                 or: make lib-smd args="-p /usr/include/eigen3"
+                 or: make lib-machdyn args="-p /usr/include/eigen3"
 
 Syntax from lib dir: python Install.py -b
                  or: python Install.py -p /usr/include/eigen3"
@@ -40,8 +40,8 @@ Syntax from lib dir: python Install.py -b
 
 Example:
 
-make lib-smd args="-b"   # download/build in default lib/smd/eigen-eigen-*
+make lib-machdyn args="-b"   # download/build in default lib/machdyn/eigen-eigen-*
-make lib-smd args="-p /usr/include/eigen3" # use existing Eigen installation in /usr/include/eigen3
+make lib-machdyn args="-p /usr/include/eigen3" # use existing Eigen installation in /usr/include/eigen3
 """
 
 pgroup = parser.add_mutually_exclusive_group()
@@ -105,7 +105,7 @@ if buildflag:
   edir = os.path.join(homepath, "eigen-%s" % version)
   os.rename(edir, eigenpath)
 
-# create link in lib/smd to Eigen src dir
+# create link in lib/machdyn to Eigen src dir
 
 print("Creating link to Eigen include folder")
 if os.path.isfile("includelink") or os.path.islink("includelink"):

lib/machdyn/README

@@ -4,7 +4,7 @@ to use the MACHDYN package in a LAMMPS input script.
 The Eigen library is available at http://eigen.tuxfamily.org.  It's
 a general C++ template library for linear algebra.
 
-You can type "make lib-smd" from the src directory to see help on how
+You can type "make lib-machdyn" from the src directory to see help on how
 to download build this library via make commands, or you can do the
 same thing by typing "python Install.py" from within this directory,
 or you can do it manually by following the instructions below.
@@ -12,13 +12,13 @@ or you can do it manually by following the instructions below.
 Instructions:
 
 1.  Download the Eigen tarball at http://eigen.tuxfamily.org and
-    unpack the tarball either in this /lib/smd directory or somewhere
+    unpack the tarball either in this lib/machdyn directory or somewhere
     else on your system.  It should unpack with into a directory with
     a name similar to eigen-eigen-bdd17ee3b1b3.  You can rename
     the directory to just "eigen" if you wish.  Note that Eigen is a
     template library, so you do not have to build it.
 
-2.  Create a soft link in this dir (lib/smd)
+2.  Create a soft link in this dir (lib/machdyn)
     to the eigen directory.  E.g if you unpacked Eigen in this dir:
       % ln -s eigen-eigen-bdd17ee3b1b3 includelink
     If you unpacked Eigen somewhere else and renamed

lib/pace/Install.py

@@ -18,11 +18,11 @@ from install_helpers import fullpath, geturl, checkmd5sum, getfallback
 # settings
 
 thisdir = fullpath('.')
-version ='v.2023.01.3.fix'
+version ='v.2023.10.04'
 
 # known checksums for different PACE versions. used to validate the download.
 checksums = { \
-    'v.2023.01.3.fix': '4f0b3b5b14456fe9a73b447de3765caa'
+    'v.2023.10.04': '70ff79f4e59af175e55d24f3243ad1ff'
 }
 
 parser = ArgumentParser(prog='Install.py', description="LAMMPS library build wrapper script")

src/ADIOS/dump_atom_adios.cpp

@@ -281,8 +281,8 @@ void DumpAtomADIOS::init_style()
       auto nstreams = std::to_string(num_aggregators);
       internal->io.SetParameters({{"substreams", nstreams}});
       if (me == 0)
-        utils::logmesg(lmp, "ADIOS method for {} is n-to-m (aggregation with {} writers)\n", filename,
+        utils::logmesg(lmp, "ADIOS method for {} is n-to-m (aggregation with {} writers)\n",
-                       nstreams);
+                       filename, nstreams);
     }
 
     internal->io.DefineVariable<uint64_t>("ntimestep");
@@ -325,6 +325,6 @@ void DumpAtomADIOS::init_style()
     // it will be correctly defined at the moment of write
     size_t UnknownSizeYet = 1;
     internal->varAtoms = internal->io.DefineVariable<double>(
-      "atoms", {UnknownSizeYet, nColumns}, {UnknownSizeYet, 0}, {UnknownSizeYet, nColumns});
+        "atoms", {UnknownSizeYet, nColumns}, {UnknownSizeYet, 0}, {UnknownSizeYet, nColumns});
   }
 }

src/ADIOS/dump_custom_adios.cpp

@@ -290,58 +290,60 @@ void DumpCustomADIOS::init_style()
 
   /* Define the group of variables for the atom style here since it's a fixed
    * set */
-  internal->io = internal->ad->DeclareIO(internal->ioName);
+  if (!internal->io) {
-  if (!internal->io.InConfigFile()) {
+    internal->io = internal->ad->DeclareIO(internal->ioName);
-    // if not defined by user, we can change the default settings
+    if (!internal->io.InConfigFile()) {
-    // BPFile is the default writer
+      // if not defined by user, we can change the default settings
-    internal->io.SetEngine("BPFile");
+      // BPFile is the default writer
-    int num_aggregators = multiproc;
+      internal->io.SetEngine("BPFile");
-    if (num_aggregators == 0) num_aggregators = 1;
+      int num_aggregators = multiproc;
-    auto nstreams = std::to_string(num_aggregators);
+      if (num_aggregators == 0) num_aggregators = 1;
-    internal->io.SetParameters({{"substreams", nstreams}});
+      auto nstreams = std::to_string(num_aggregators);
-    if (me == 0)
+      internal->io.SetParameters({{"substreams", nstreams}});
-      utils::logmesg(lmp, "ADIOS method for {} is n-to-m (aggregation with {} writers)\n", filename,
+      if (me == 0)
-                     nstreams);
+        utils::logmesg(lmp, "ADIOS method for {} is n-to-m (aggregation with {} writers)\n",
+                       filename, nstreams);
+    }
+
+    internal->io.DefineVariable<uint64_t>("ntimestep");
+    internal->io.DefineVariable<uint64_t>("natoms");
+
+    internal->io.DefineVariable<int>("nprocs");
+    internal->io.DefineVariable<int>("ncolumns");
+
+    internal->io.DefineVariable<double>("boxxlo");
+    internal->io.DefineVariable<double>("boxxhi");
+    internal->io.DefineVariable<double>("boxylo");
+    internal->io.DefineVariable<double>("boxyhi");
+    internal->io.DefineVariable<double>("boxzlo");
+    internal->io.DefineVariable<double>("boxzhi");
+
+    internal->io.DefineVariable<double>("boxxy");
+    internal->io.DefineVariable<double>("boxxz");
+    internal->io.DefineVariable<double>("boxyz");
+
+    internal->io.DefineAttribute<int>("triclinic", domain->triclinic);
+
+    int *boundaryptr = reinterpret_cast<int *>(domain->boundary);
+    internal->io.DefineAttribute<int>("boundary", boundaryptr, 6);
+
+    auto nColumns = static_cast<size_t>(size_one);
+    internal->io.DefineAttribute<std::string>("columns", internal->columnNames.data(), nColumns);
+    internal->io.DefineAttribute<std::string>("columnstr", columns);
+    internal->io.DefineAttribute<std::string>("boundarystr", boundstr);
+    internal->io.DefineAttribute<std::string>("LAMMPS/dump_style", "custom");
+    internal->io.DefineAttribute<std::string>("LAMMPS/version", lmp->version);
+    internal->io.DefineAttribute<std::string>("LAMMPS/num_ver", std::to_string(lmp->num_ver));
+
+    internal->io.DefineVariable<uint64_t>("nme",
+                                          {adios2::LocalValueDim});    // local dimension variable
+    internal->io.DefineVariable<uint64_t>("offset",
+                                          {adios2::LocalValueDim});    // local dimension variable
+
+    // atom table size is not known at the moment
+    // it will be correctly defined at the moment of write
+    size_t UnknownSizeYet = 1;
+    internal->varAtoms = internal->io.DefineVariable<double>(
+        "atoms", {UnknownSizeYet, nColumns}, {UnknownSizeYet, 0}, {UnknownSizeYet, nColumns});
   }
-
-  internal->io.DefineVariable<uint64_t>("ntimestep");
-  internal->io.DefineVariable<uint64_t>("natoms");
-
-  internal->io.DefineVariable<int>("nprocs");
-  internal->io.DefineVariable<int>("ncolumns");
-
-  internal->io.DefineVariable<double>("boxxlo");
-  internal->io.DefineVariable<double>("boxxhi");
-  internal->io.DefineVariable<double>("boxylo");
-  internal->io.DefineVariable<double>("boxyhi");
-  internal->io.DefineVariable<double>("boxzlo");
-  internal->io.DefineVariable<double>("boxzhi");
-
-  internal->io.DefineVariable<double>("boxxy");
-  internal->io.DefineVariable<double>("boxxz");
-  internal->io.DefineVariable<double>("boxyz");
-
-  internal->io.DefineAttribute<int>("triclinic", domain->triclinic);
-
-  int *boundaryptr = reinterpret_cast<int *>(domain->boundary);
-  internal->io.DefineAttribute<int>("boundary", boundaryptr, 6);
-
-  auto nColumns = static_cast<size_t>(size_one);
-  internal->io.DefineAttribute<std::string>("columns", internal->columnNames.data(), nColumns);
-  internal->io.DefineAttribute<std::string>("columnstr", columns);
-  internal->io.DefineAttribute<std::string>("boundarystr", boundstr);
-  internal->io.DefineAttribute<std::string>("LAMMPS/dump_style", "custom");
-  internal->io.DefineAttribute<std::string>("LAMMPS/version", lmp->version);
-  internal->io.DefineAttribute<std::string>("LAMMPS/num_ver", std::to_string(lmp->num_ver));
-
-  internal->io.DefineVariable<uint64_t>("nme",
-                                        {adios2::LocalValueDim});    // local dimension variable
-  internal->io.DefineVariable<uint64_t>("offset",
-                                        {adios2::LocalValueDim});    // local dimension variable
-
-  // atom table size is not known at the moment
-  // it will be correctly defined at the moment of write
-  size_t UnknownSizeYet = 1;
-  internal->varAtoms = internal->io.DefineVariable<double>(
-      "atoms", {UnknownSizeYet, nColumns}, {UnknownSizeYet, 0}, {UnknownSizeYet, nColumns});
 }

src/BOCS/fix_bocs.cpp

@@ -1024,7 +1024,10 @@ void FixBocs::final_integrate()
 
   if (pstat_flag) {
     if (pstyle == ISO) pressure->compute_scalar();
-    else pressure->compute_vector();
+    else {
+      temperature->compute_vector();
+      pressure->compute_vector();
+    }
     couple();
     pressure->addstep(update->ntimestep+1);
   }
@@ -1961,6 +1964,7 @@ void FixBocs::nhc_press_integrate()
   int ich,i,pdof;
   double expfac,factor_etap,kecurrent;
   double kt = boltz * t_target;
+  double lkt_press;
 
   // Update masses, to preserve initial freq, if flag set
 
@@ -2006,7 +2010,8 @@ void FixBocs::nhc_press_integrate()
     }
   }
 
-  double lkt_press = pdof * kt;
+  if (pstyle == ISO) lkt_press = kt;
+  else lkt_press = pdof * kt;
   etap_dotdot[0] = (kecurrent - lkt_press)/etap_mass[0];
 
   double ncfac = 1.0/nc_pchain;

src/BODY/fix_wall_body_polyhedron.cpp

@@ -17,18 +17,20 @@
 ------------------------------------------------------------------------- */
 
 #include "fix_wall_body_polyhedron.h"
-#include <cmath>
+
-#include <cstring>
 #include "atom.h"
 #include "atom_vec_body.h"
 #include "body_rounded_polyhedron.h"
 #include "domain.h"
-#include "update.h"
+#include "error.h"
 #include "force.h"
 #include "math_const.h"
 #include "math_extra.h"
 #include "memory.h"
-#include "error.h"
+#include "update.h"
+
+#include <cmath>
+#include <cstring>
 
 using namespace LAMMPS_NS;
 using namespace FixConst;

src/Depend.sh

@@ -64,6 +64,7 @@ fi
 
 if (test $1 = "COLLOID") then
   depend GPU
+  depend KOKKOS
   depend OPENMP
 fi
 
@@ -185,6 +186,7 @@ fi
 if (test $1 = "ML-SNAP") then
   depend ML-IAP
   depend KOKKOS
+  depend INTEL
 fi
 
 if (test $1 = "CG-SPICA") then

src/ELECTRODE/electrode_matrix.cpp

@@ -84,7 +84,7 @@ void ElectrodeMatrix::compute_array(double **array, bool timer_flag)
   electrode_kspace->compute_matrix(&mpos[0], array, timer_flag);
   MPI_Barrier(world);
   if (timer_flag && (comm->me == 0))
-    utils::logmesg(lmp, fmt::format("KSpace time: {:.4g} s\n", MPI_Wtime() - kspace_time));
+    utils::logmesg(lmp, "KSpace time: {:.4g} s\n", MPI_Wtime() - kspace_time);
   //cout << array[0][0] << ", " << array[0][1] << endl;
   pair_contribution(array);
   //cout << array[0][0] << ", " << array[0][1] << endl;

src/ELECTRODE/electrode_vector.cpp

@@ -60,10 +60,10 @@ ElectrodeVector::~ElectrodeVector()
 {
   if (timer_flag && (comm->me == 0)) {
     try {
-      utils::logmesg(lmp, fmt::format("B time: {:.4g} s\n", b_time_total));
+      utils::logmesg(lmp, "B time: {:.4g} s\n", b_time_total);
-      utils::logmesg(lmp, fmt::format("B kspace time: {:.4g} s\n", kspace_time_total));
+      utils::logmesg(lmp, "B kspace time: {:.4g} s\n", kspace_time_total);
-      utils::logmesg(lmp, fmt::format("B pair time: {:.4g} s\n", pair_time_total));
+      utils::logmesg(lmp, "B pair time: {:.4g} s\n", pair_time_total);
-      utils::logmesg(lmp, fmt::format("B boundary time: {:.4g} s\n", boundary_time_total));
+      utils::logmesg(lmp, "B boundary time: {:.4g} s\n", boundary_time_total);
     } catch (std::exception &) {
     }
   }

src/ELECTRODE/pppm_electrode.cpp

@@ -136,7 +136,7 @@ void PPPMElectrode::init()
   }
 
   if (order < 2 || order > MAXORDER)
-    error->all(FLERR, fmt::format("PPPM/electrode order cannot be < 2 or > {}", MAXORDER));
+    error->all(FLERR, "PPPM/electrode order cannot be < 2 or > {}", MAXORDER);
 
   // compute two charge force
 
@@ -816,7 +816,7 @@ void PPPMElectrode::one_step_multiplication(bigint *imat, double *greens_real, d
   memory->destroy(rho1d_j);
   MPI_Barrier(world);
   if (timer_flag && (comm->me == 0))
-    utils::logmesg(lmp, fmt::format("Single step time: {:.4g} s\n", MPI_Wtime() - step1_time));
+    utils::logmesg(lmp, "Single step time: {:.4g} s\n", MPI_Wtime() - step1_time);
 }
 
 /* ----------------------------------------------------------------------*/
@@ -917,7 +917,7 @@ void PPPMElectrode::two_step_multiplication(bigint *imat, double *greens_real, d
   }
   MPI_Barrier(world);
   if (timer_flag && (comm->me == 0))
-    utils::logmesg(lmp, fmt::format("step 1 time: {:.4g} s\n", MPI_Wtime() - step1_time));
+    utils::logmesg(lmp, "step 1 time: {:.4g} s\n", MPI_Wtime() - step1_time);
 
   // nested loop over electrode atoms i and j and stencil of i
   // in theory could reuse make_rho1d_j here -- but this step is already
@@ -958,7 +958,7 @@ void PPPMElectrode::two_step_multiplication(bigint *imat, double *greens_real, d
   MPI_Barrier(world);
   memory->destroy(gw);
   if (timer_flag && (comm->me == 0))
-    utils::logmesg(lmp, fmt::format("step 2 time: {:.4g} s\n", MPI_Wtime() - step2_time));
+    utils::logmesg(lmp, "step 2 time: {:.4g} s\n", MPI_Wtime() - step2_time);
 }
 
 /* ----------------------------------------------------------------------

src/EXTRA-COMPUTE/compute_ackland_atom.cpp

@@ -33,6 +33,7 @@
 
 #include <cmath>
 #include <cstring>
+#include <utility>
 
 using namespace LAMMPS_NS;
 
@@ -346,35 +347,24 @@ void ComputeAcklandAtom::compute_peratom()
    2nd routine sorts auxiliary array at same time
 ------------------------------------------------------------------------- */
 
-#define SWAP(a,b)   tmp = a; (a) = b; (b) = tmp;
-#define ISWAP(a,b) itmp = a; (a) = b; (b) = itmp;
-
 void ComputeAcklandAtom::select(int k, int n, double *arr)
   {
   int i,ir,j,l,mid;
-  double a,tmp;
+  double a;
 
   arr--;
   l = 1;
   ir = n;
   while (true) {
     if (ir <= l+1) {
-      if (ir == l+1 && arr[ir] < arr[l]) {
+      if (ir == l+1 && arr[ir] < arr[l]) std::swap(arr[l],arr[ir]);
-        SWAP(arr[l],arr[ir])
-      }
       return;
     } else {
       mid=(l+ir) >> 1;
-      SWAP(arr[mid],arr[l+1])
+      std::swap(arr[mid],arr[l+1]);
-      if (arr[l] > arr[ir]) {
+      if (arr[l] > arr[ir]) std::swap(arr[l],arr[ir]);
-        SWAP(arr[l],arr[ir])
+      if (arr[l+1] > arr[ir]) std::swap(arr[l+1],arr[ir]);
-      }
+      if (arr[l] > arr[l+1]) std::swap(arr[l],arr[l+1]);
-      if (arr[l+1] > arr[ir]) {
-        SWAP(arr[l+1],arr[ir])
-      }
-      if (arr[l] > arr[l+1]) {
-        SWAP(arr[l],arr[l+1])
-      }
       i = l+1;
       j = ir;
       a = arr[l+1];
@@ -382,7 +372,7 @@ void ComputeAcklandAtom::select(int k, int n, double *arr)
         do i++; while (arr[i] < a);
         do j--; while (arr[j] > a);
         if (j < i) break;
-        SWAP(arr[i],arr[j])
+        std::swap(arr[i],arr[j]);
       }
       arr[l+1] = arr[j];
       arr[j] = a;
@@ -396,8 +386,8 @@ void ComputeAcklandAtom::select(int k, int n, double *arr)
 
 void ComputeAcklandAtom::select2(int k, int n, double *arr, int *iarr)
 {
-  int i,ir,j,l,mid,ia,itmp;
+  int i,ir,j,l,mid,ia;
-  double a,tmp;
+  double a;
 
   arr--;
   iarr--;
@@ -406,25 +396,25 @@ void ComputeAcklandAtom::select2(int k, int n, double *arr, int *iarr)
   while (true) {
     if (ir <= l+1) {
       if (ir == l+1 && arr[ir] < arr[l]) {
-        SWAP(arr[l],arr[ir])
+        std::swap(arr[l],arr[ir]);
-        ISWAP(iarr[l],iarr[ir])
+        std::swap(iarr[l],iarr[ir]);
       }
       return;
     } else {
       mid=(l+ir) >> 1;
-      SWAP(arr[mid],arr[l+1])
+      std::swap(arr[mid],arr[l+1]);
-      ISWAP(iarr[mid],iarr[l+1])
+      std::swap(iarr[mid],iarr[l+1]);
       if (arr[l] > arr[ir]) {
-        SWAP(arr[l],arr[ir])
+        std::swap(arr[l],arr[ir]);
-        ISWAP(iarr[l],iarr[ir])
+        std::swap(iarr[l],iarr[ir]);
       }
       if (arr[l+1] > arr[ir]) {
-        SWAP(arr[l+1],arr[ir])
+        std::swap(arr[l+1],arr[ir]);
-        ISWAP(iarr[l+1],iarr[ir])
+        std::swap(iarr[l+1],iarr[ir]);
       }
       if (arr[l] > arr[l+1]) {
-        SWAP(arr[l],arr[l+1])
+        std::swap(arr[l],arr[l+1]);
-        ISWAP(iarr[l],iarr[l+1])
+        std::swap(iarr[l],iarr[l+1]);
       }
       i = l+1;
       j = ir;
@@ -434,8 +424,8 @@ void ComputeAcklandAtom::select2(int k, int n, double *arr, int *iarr)
         do i++; while (arr[i] < a);
         do j--; while (arr[j] > a);
         if (j < i) break;
-        SWAP(arr[i],arr[j])
+        std::swap(arr[i],arr[j]);
-        ISWAP(iarr[i],iarr[j])
+        std::swap(iarr[i],iarr[j]);
       }
       arr[l+1] = arr[j];
       arr[j] = a;

src/EXTRA-COMPUTE/compute_basal_atom.cpp

@@ -31,6 +31,7 @@
 #include "update.h"
 
 #include <cmath>
+#include <utility>
 
 using namespace LAMMPS_NS;
 
@@ -431,35 +432,24 @@ void ComputeBasalAtom::compute_peratom()
    2nd routine sorts auxiliary array at same time
 ------------------------------------------------------------------------- */
 
-#define SWAP(a,b)   tmp = a; (a) = b; (b) = tmp;
-#define ISWAP(a,b) itmp = a; (a) = b; (b) = itmp;
-
 void ComputeBasalAtom::select(int k, int n, double *arr)
   {
   int i,ir,j,l,mid;
-  double a,tmp;
+  double a;
 
   arr--;
   l = 1;
   ir = n;
   while (true) {
     if (ir <= l+1) {
-      if (ir == l+1 && arr[ir] < arr[l]) {
+      if (ir == l+1 && arr[ir] < arr[l]) std::swap(arr[l],arr[ir]);
-        SWAP(arr[l],arr[ir])
-      }
       return;
     } else {
       mid=(l+ir) >> 1;
-      SWAP(arr[mid],arr[l+1])
+      std::swap(arr[mid],arr[l+1]);
-      if (arr[l] > arr[ir]) {
+      if (arr[l] > arr[ir]) std::swap(arr[l],arr[ir]);
-        SWAP(arr[l],arr[ir])
+      if (arr[l+1] > arr[ir]) std::swap(arr[l+1],arr[ir]);
-      }
+      if (arr[l] > arr[l+1]) std::swap(arr[l],arr[l+1]);
-      if (arr[l+1] > arr[ir]) {
-        SWAP(arr[l+1],arr[ir])
-      }
-      if (arr[l] > arr[l+1]) {
-        SWAP(arr[l],arr[l+1])
-      }
       i = l+1;
       j = ir;
       a = arr[l+1];
@@ -467,7 +457,7 @@ void ComputeBasalAtom::select(int k, int n, double *arr)
         do i++; while (arr[i] < a);
         do j--; while (arr[j] > a);
         if (j < i) break;
-        SWAP(arr[i],arr[j])
+        std::swap(arr[i],arr[j]);
       }
       arr[l+1] = arr[j];
       arr[j] = a;
@@ -481,8 +471,8 @@ void ComputeBasalAtom::select(int k, int n, double *arr)
 
 void ComputeBasalAtom::select2(int k, int n, double *arr, int *iarr)
 {
-  int i,ir,j,l,mid,ia,itmp;
+  int i,ir,j,l,mid,ia;
-  double a,tmp;
+  double a;
 
   arr--;
   iarr--;
@@ -491,25 +481,25 @@ void ComputeBasalAtom::select2(int k, int n, double *arr, int *iarr)
   while (true) {
     if (ir <= l+1) {
       if (ir == l+1 && arr[ir] < arr[l]) {
-        SWAP(arr[l],arr[ir])
+        std::swap(arr[l],arr[ir]);
-        ISWAP(iarr[l],iarr[ir])
+        std::swap(iarr[l],iarr[ir]);
       }
       return;
     } else {
       mid=(l+ir) >> 1;
-      SWAP(arr[mid],arr[l+1])
+      std::swap(arr[mid],arr[l+1]);
-      ISWAP(iarr[mid],iarr[l+1])
+      std::swap(iarr[mid],iarr[l+1]);
       if (arr[l] > arr[ir]) {
-        SWAP(arr[l],arr[ir])
+        std::swap(arr[l],arr[ir]);
-        ISWAP(iarr[l],iarr[ir])
+        std::swap(iarr[l],iarr[ir]);
       }
       if (arr[l+1] > arr[ir]) {
-        SWAP(arr[l+1],arr[ir])
+        std::swap(arr[l+1],arr[ir]);
-        ISWAP(iarr[l+1],iarr[ir])
+        std::swap(iarr[l+1],iarr[ir]);
       }
       if (arr[l] > arr[l+1]) {
-        SWAP(arr[l],arr[l+1])
+        std::swap(arr[l],arr[l+1]);
-        ISWAP(iarr[l],iarr[l+1])
+        std::swap(iarr[l],iarr[l+1]);
       }
       i = l+1;
       j = ir;
@@ -519,8 +509,8 @@ void ComputeBasalAtom::select2(int k, int n, double *arr, int *iarr)
         do i++; while (arr[i] < a);
         do j--; while (arr[j] > a);
         if (j < i) break;
-        SWAP(arr[i],arr[j])
+        std::swap(arr[i],arr[j]);
-        ISWAP(iarr[i],iarr[j])
+        std::swap(iarr[i],iarr[j]);
       }
       arr[l+1] = arr[j];
       arr[j] = a;

src/EXTRA-COMPUTE/compute_hexorder_atom.cpp

@@ -33,6 +33,7 @@
 #include <cmath>
 #include <complex>
 #include <cstring>
+#include <utility>
 
 #ifdef DBL_EPSILON
   #define MY_EPSILON (10.0*DBL_EPSILON)
@@ -267,15 +268,12 @@ inline void ComputeHexOrderAtom::calc_qn_trig(double delx, double dely, double &
    sort auxiliary array at same time
 ------------------------------------------------------------------------- */
 
-#define SWAP(a,b)   tmp = a; (a) = b; (b) = tmp;
-#define ISWAP(a,b) itmp = a; (a) = b; (b) = itmp;
-
 /* ---------------------------------------------------------------------- */
 
 void ComputeHexOrderAtom::select2(int k, int n, double *arr, int *iarr)
 {
-  int i,ir,j,l,mid,ia,itmp;
+  int i,ir,j,l,mid,ia;
-  double a,tmp;
+  double a;
 
   arr--;
   iarr--;
@@ -284,25 +282,25 @@ void ComputeHexOrderAtom::select2(int k, int n, double *arr, int *iarr)
   while (true) {
     if (ir <= l+1) {
       if (ir == l+1 && arr[ir] < arr[l]) {
-        SWAP(arr[l],arr[ir])
+        std::swap(arr[l],arr[ir]);
-        ISWAP(iarr[l],iarr[ir])
+        std::swap(iarr[l],iarr[ir]);
       }
       return;
     } else {
       mid=(l+ir) >> 1;
-      SWAP(arr[mid],arr[l+1])
+      std::swap(arr[mid],arr[l+1]);
-      ISWAP(iarr[mid],iarr[l+1])
+      std::swap(iarr[mid],iarr[l+1]);
       if (arr[l] > arr[ir]) {
-        SWAP(arr[l],arr[ir])
+        std::swap(arr[l],arr[ir]);
-        ISWAP(iarr[l],iarr[ir])
+        std::swap(iarr[l],iarr[ir]);
       }
       if (arr[l+1] > arr[ir]) {
-        SWAP(arr[l+1],arr[ir])
+        std::swap(arr[l+1],arr[ir]);
-        ISWAP(iarr[l+1],iarr[ir])
+        std::swap(iarr[l+1],iarr[ir]);
       }
       if (arr[l] > arr[l+1]) {
-        SWAP(arr[l],arr[l+1])
+        std::swap(arr[l],arr[l+1]);
-        ISWAP(iarr[l],iarr[l+1])
+        std::swap(iarr[l],iarr[l+1]);
       }
       i = l+1;
       j = ir;
@@ -312,8 +310,8 @@ void ComputeHexOrderAtom::select2(int k, int n, double *arr, int *iarr)
         do i++; while (arr[i] < a);
         do j--; while (arr[j] > a);
         if (j < i) break;
-        SWAP(arr[i],arr[j])
+        std::swap(arr[i],arr[j]);
-        ISWAP(iarr[i],iarr[j])
+        std::swap(iarr[i],iarr[j]);
       }
       arr[l+1] = arr[j];
       arr[j] = a;

src/INTEL/TEST/in.intel.snap

@@ -0,0 +1,70 @@
+# Toy demonstration of SNAP "scale" parameter, using fix/adapt and hybrid/overlay
+# Mixing linear and quadratic SNAP Ni potentials by Zuo et al. JCPA 2020
+
+variable	w index 10	# Warmup Timesteps
+variable	t index 100	# Main Run Timesteps
+variable	m index 1	# Main Run Timestep Multiplier
+variable	n index 0	# Use NUMA Mapping for Multi-Node
+
+variable	x index 4
+variable	y index 2
+variable	z index 2
+
+variable	rr equal floor($t*$m)
+variable        root getenv LMP_ROOT
+
+if "$n > 0"	then "processors * * * grid numa"
+
+# mixing parameter
+
+variable lambda equal 0.2
+
+# Initialize simulation
+
+variable a equal 3.52
+units           metal
+
+# generate the box and atom positions using a FCC lattice
+variable nx equal 20*$x
+variable ny equal 20*$y
+variable nz equal 20*$z
+
+boundary        p p p
+
+lattice         fcc $a
+region          box block 0 ${nx} 0 ${ny} 0 ${nz}
+create_box      1 box
+create_atoms    1 box
+
+mass 1 34.
+
+# choose bundled SNAP Ni potential from Zuo et al. JCPA 2020
+pair_style hybrid/overlay snap snap
+pair_coeff * * snap 1 &
+    ${root}/examples/snap/Ni_Zuo_JPCA2020.snapcoeff &
+    ${root}/examples/snap/Ni_Zuo_JPCA2020.snapparam Ni
+pair_coeff * * snap 2 &
+    ${root}/examples/snap/Ni_Zuo_JPCA2020.quadratic.snapcoeff &
+    ${root}/examples/snap/Ni_Zuo_JPCA2020.quadratic.snapparam Ni
+
+# scale according to mixing parameter
+variable l1 equal ${lambda}
+variable l2 equal 1.0-${lambda}
+fix scale1 all adapt 1 pair snap:1 scale * * v_l1
+fix scale2 all adapt 1 pair snap:2 scale * * v_l2
+
+# Setup output
+thermo          1
+thermo_modify norm yes
+
+# Set up NVE run
+timestep 0.5e-3
+neighbor 1.0 bin
+neigh_modify every 1 delay 0 check yes
+
+# Run MD
+velocity all create 300.0 4928459 loop geom
+fix 1 all nve
+
+if "$w > 0"	then "run $w"
+run		${rr}

src/INTEL/TEST/run_benchmarks.sh

@@ -35,7 +35,7 @@ export I_MPI_PIN_DOMAIN=core
 # End settings for your system
 #########################################################################
 
-export WORKLOADS="lj rhodo lc sw water eam airebo dpd tersoff"
+export WORKLOADS="lj rhodo lc sw water eam airebo dpd tersoff snap"
 export LMP_ARGS="-pk intel 0 -sf intel -screen none -v d 1"
 export RLMP_ARGS="-pk intel 0 lrt yes -sf intel -screen none -v d 1"
 

src/INTEL/angle_charmm_intel.h

@@ -59,7 +59,7 @@ class AngleCharmmIntel : public AngleCharmm {
 
     fc_packed1 *fc;
     ForceConst() : fc(nullptr), _nangletypes(0) {}
-    ~ForceConst() { set_ntypes(0, nullptr); }
+    ~ForceConst() noexcept(false) { set_ntypes(0, nullptr); }
 
     void set_ntypes(const int nangletypes, Memory *memory);
 

src/INTEL/angle_harmonic_intel.h

@@ -60,7 +60,7 @@ class AngleHarmonicIntel : public AngleHarmonic {
 
     fc_packed1 *fc;
     ForceConst() : fc(nullptr), _nangletypes(0) {}
-    ~ForceConst() { set_ntypes(0, nullptr); }
+    ~ForceConst() noexcept(false) { set_ntypes(0, nullptr); }
 
     void set_ntypes(const int nangletypes, Memory *memory);
 

src/INTEL/bond_fene_intel.h

@@ -59,7 +59,7 @@ class BondFENEIntel : public BondFENE {
     fc_packed1 *fc;
 
     ForceConst() : fc(nullptr), _nbondtypes(0) {}
-    ~ForceConst() { set_ntypes(0, nullptr); }
+    ~ForceConst() noexcept(false) { set_ntypes(0, nullptr); }
 
     void set_ntypes(const int nbondtypes, Memory *memory);
 

src/INTEL/bond_harmonic_intel.h

@@ -59,7 +59,7 @@ class BondHarmonicIntel : public BondHarmonic {
     fc_packed1 *fc;
 
     ForceConst() : fc(nullptr), _nbondtypes(0) {}
-    ~ForceConst() { set_ntypes(0, nullptr); }
+    ~ForceConst() noexcept(false) { set_ntypes(0, nullptr); }
 
     void set_ntypes(const int nbondtypes, Memory *memory);
 

src/INTEL/dihedral_charmm_intel.h

@@ -68,7 +68,7 @@ class DihedralCharmmIntel : public DihedralCharmm {
     flt_t *weight;
 
     ForceConst() : ljp(nullptr), fc(nullptr), weight(nullptr), _npairtypes(0), _ndihderaltypes(0) {}
-    ~ForceConst() { set_ntypes(0, 0, nullptr); }
+    ~ForceConst() noexcept(false) { set_ntypes(0, 0, nullptr); }
 
     void set_ntypes(const int npairtypes, const int ndihderaltypes, Memory *memory);
 

src/INTEL/dihedral_fourier_intel.h

@@ -63,7 +63,7 @@ class DihedralFourierIntel : public DihedralFourier {
     fc_packed1 **fc;
 
     ForceConst() : fc(nullptr), _ndihedraltypes(0) {}
-    ~ForceConst() { set_ntypes(0, nullptr, nullptr, nullptr); }
+    ~ForceConst() noexcept(false) { set_ntypes(0, nullptr, nullptr, nullptr); }
 
     void set_ntypes(const int ndihedraltypes, int *setflag, int *nterms, Memory *memory);
 

src/INTEL/dihedral_harmonic_intel.h

@@ -63,7 +63,7 @@ class DihedralHarmonicIntel : public DihedralHarmonic {
     fc_packed1 *fc;
 
     ForceConst() : fc(nullptr), _ndihderaltypes(0) {}
-    ~ForceConst() { set_ntypes(0, nullptr); }
+    ~ForceConst() noexcept(false) { set_ntypes(0, nullptr); }
 
     void set_ntypes(const int ndihderaltypes, Memory *memory);
 

src/INTEL/dihedral_opls_intel.h

@@ -62,7 +62,7 @@ class DihedralOPLSIntel : public DihedralOPLS {
     fc_packed1 *fc;
 
     ForceConst() : fc(nullptr), _ndihderaltypes(0) {}
-    ~ForceConst() { set_ntypes(0, nullptr); }
+    ~ForceConst() noexcept(false) { set_ntypes(0, nullptr); }
 
     void set_ntypes(const int ndihderaltypes, Memory *memory);
 

src/INTEL/fix_intel.cpp

@@ -20,6 +20,7 @@
 #include "fix_intel.h"
 
 #include "comm.h"
+#include "domain.h"
 #include "error.h"
 #include "force.h"
 #include "neighbor.h"
@@ -470,6 +471,7 @@ void FixIntel::pair_init_check(const bool cdmessage)
 
   int need_tag = 0;
   if (atom->molecular != Atom::ATOMIC || three_body_neighbor()) need_tag = 1;
+  if (domain->triclinic && force->newton_pair) need_tag = 1;
 
   // Clear buffers used for pair style
   char kmode[80];

src/INTEL/improper_cvff_intel.h

@@ -61,7 +61,7 @@ class ImproperCvffIntel : public ImproperCvff {
     fc_packed1 *fc;
 
     ForceConst() : fc(nullptr), _nimpropertypes(0) {}
-    ~ForceConst() { set_ntypes(0, nullptr); }
+    ~ForceConst() noexcept(false) { set_ntypes(0, nullptr); }
 
     void set_ntypes(const int nimpropertypes, Memory *memory);
 

src/INTEL/improper_harmonic_intel.h

@@ -60,7 +60,7 @@ class ImproperHarmonicIntel : public ImproperHarmonic {
     fc_packed1 *fc;
 
     ForceConst() : fc(nullptr), _nimpropertypes(0) {}
-    ~ForceConst() { set_ntypes(0, nullptr); }
+    ~ForceConst() noexcept(false) { set_ntypes(0, nullptr); }
 
     void set_ntypes(const int nimpropertypes, Memory *memory);
 

src/INTEL/intel_simd.h

@@ -46,13 +46,38 @@ namespace ip_simd {
 
   typedef __mmask16 SIMD_mask;
 
+  inline bool any(const SIMD_mask &m) { return m != 0; }
+
   struct SIMD_int {
     __m512i v;
     SIMD_int() {}
     SIMD_int(const __m512i in) : v(in) {}
+    inline int & operator[](const int i) { return ((int *)&(v))[i]; }
+    inline const int & operator[](const int i) const
+      { return ((int *)&(v))[i]; }
     operator __m512i() const { return v;}
   };
 
+  struct SIMD256_int {
+    __m256i v;
+    SIMD256_int() {}
+    SIMD256_int(const __m256i in) : v(in) {}
+    SIMD256_int(const int in) : v(_mm256_set1_epi32(in)) {}
+    inline int & operator[](const int i) { return ((int *)&(v))[i]; }
+    inline const int & operator[](const int i) const
+      { return ((int *)&(v))[i]; }
+#ifdef __INTEL_LLVM_COMPILER
+    inline SIMD256_int operator&=(const int i)
+      { v=_mm256_and_epi32(v, _mm256_set1_epi32(i)); return *this; };
+#else
+    inline SIMD256_int operator&=(const int i)
+      { v=_mm256_and_si256(v, _mm256_set1_epi32(i)); return *this; };
+#endif
+    inline SIMD256_int operator+=(const int i)
+      { v=_mm256_add_epi32(v, _mm256_set1_epi32(i)); return *this; };
+    operator __m256i() const { return v;}
+  };
+
   struct SIMD_float {
     __m512 v;
     SIMD_float() {}
@@ -64,7 +89,24 @@ namespace ip_simd {
     __m512d v;
     SIMD_double() {}
     SIMD_double(const __m512d in) : v(in) {}
+    SIMD_double(const double in) { v=_mm512_set1_pd(in); }
+    inline double & operator[](const int i) { return ((double *)&(v))[i]; }
+    inline const double & operator[](const int i) const
+      { return ((double *)&(v))[i]; }
     operator __m512d() const { return v;}
+
+    SIMD_double & operator=(const double i)
+      { _mm512_set1_pd(i); return *this; }
+    SIMD_double &operator=(const SIMD_double &i)
+      { v = i.v; return *this; }
+
+    SIMD_double operator-() { return _mm512_xor_pd(v, _mm512_set1_pd(-0.0)); }
+    SIMD_double & operator+=(const SIMD_double & two)
+      { v = _mm512_add_pd(v, two.v); return *this; }
+    SIMD_double & operator-=(const SIMD_double & two)
+      { v = _mm512_sub_pd(v, two.v); return *this; }
+    SIMD_double & operator*=(const SIMD_double & two)
+      { v = _mm512_mul_pd(v, two.v); return *this; }
   };
 
   template<class flt_t>
@@ -99,6 +141,12 @@ namespace ip_simd {
 
   // ------- Set Operations
 
+  inline SIMD256_int SIMD256_set(const int l0, const int l1, const int l2,
+                                 const int l3, const int l4, const int l5,
+                                 const int l6, const int l7) {
+    return _mm256_setr_epi32(l0,l1,l2,l3,l4,l5,l6,l7);
+  }
+
   inline SIMD_int SIMD_set(const int l0, const int l1, const int l2,
                            const int l3, const int l4, const int l5,
                            const int l6, const int l7, const int l8,
@@ -109,6 +157,10 @@ namespace ip_simd {
                              l8,l9,l10,l11,l12,l13,l14,l15);
   }
 
+  inline SIMD256_int SIMD256_set(const int l) {
+    return _mm256_set1_epi32(l);
+  }
+
   inline SIMD_int SIMD_set(const int l) {
     return _mm512_set1_epi32(l);
   }
@@ -121,6 +173,10 @@ namespace ip_simd {
     return _mm512_set1_pd(l);
   }
 
+  inline SIMD256_int SIMD256_count() {
+    return SIMD256_set(0,1,2,3,4,5,6,7);
+  }
+
   inline SIMD_int SIMD_zero_masked(const SIMD_mask &m, const SIMD_int &one) {
     return _mm512_maskz_mov_epi32(m, one);
   }
@@ -147,6 +203,10 @@ namespace ip_simd {
 
   // -------- Load Operations
 
+  inline SIMD256_int SIMD_load(const SIMD256_int *p) {
+    return _mm256_load_epi32((int *)p);
+  }
+
   inline SIMD_int SIMD_load(const int *p) {
     return _mm512_load_epi32(p);
   }
@@ -159,6 +219,10 @@ namespace ip_simd {
     return _mm512_load_pd(p);
   }
 
+  inline SIMD_double SIMD_load(const SIMD_double *p) {
+    return _mm512_load_pd((double *)p);
+  }
+
   inline SIMD_int SIMD_loadz(const SIMD_mask &m, const int *p) {
     return _mm512_maskz_load_epi32(m, p);
   }
@@ -171,6 +235,10 @@ namespace ip_simd {
     return _mm512_maskz_load_pd(m, p);
   }
 
+  inline SIMD256_int SIMD_gather(const int *p, const SIMD256_int &i) {
+    return _mm256_i32gather_epi32(p, i, _MM_SCALE_4);
+  }
+
   inline SIMD_int SIMD_gather(const int *p, const SIMD_int &i) {
     return _mm512_i32gather_epi32(i, p, _MM_SCALE_4);
   }
@@ -179,6 +247,10 @@ namespace ip_simd {
     return _mm512_i32gather_ps(i, p, _MM_SCALE_4);
   }
 
+  inline SIMD_double SIMD_gather(const double *p, const SIMD256_int &i) {
+    return _mm512_i32gather_pd(i, p, _MM_SCALE_8);
+  }
+
   inline SIMD_double SIMD_gather(const double *p, const SIMD_int &i) {
     return _mm512_i32gather_pd(_mm512_castsi512_si256(i), p, _MM_SCALE_8);
   }
@@ -201,6 +273,12 @@ namespace ip_simd {
                                     _mm512_castsi512_si256(i), p, _MM_SCALE_8);
   }
 
+  inline SIMD_double SIMD_gather(const SIMD_mask &m, const double *p,
+                                 const SIMD256_int &i) {
+    return _mm512_mask_i32gather_pd(_mm512_undefined_pd(), m,
+                                    i, p, _MM_SCALE_8);
+  }
+
   template <typename T>
   inline SIMD_int SIMD_gatherz_offset(const SIMD_mask &m, const int *p,
                                       const SIMD_int &i) {
@@ -252,6 +330,15 @@ namespace ip_simd {
     return _mm512_store_pd(p,one);
   }
 
+  inline void SIMD_store(SIMD_double *p, const SIMD_double &one) {
+    return _mm512_store_pd((double *)p,one);
+  }
+
+  inline void SIMD_scatter(const SIMD_mask &m, int *p,
+                           const SIMD256_int &i, const SIMD256_int &vec) {
+    _mm256_mask_i32scatter_epi32(p, m, i, vec, _MM_SCALE_4);
+  }
+
   inline void SIMD_scatter(const SIMD_mask &m, int *p,
                            const SIMD_int &i, const SIMD_int &vec) {
     _mm512_mask_i32scatter_epi32(p, m, i, vec, _MM_SCALE_4);
@@ -268,8 +355,22 @@ namespace ip_simd {
                               _MM_SCALE_8);
   }
 
+  inline void SIMD_scatter(const SIMD_mask &m, double *p,
+                           const SIMD256_int &i, const SIMD_double &vec) {
+    _mm512_mask_i32scatter_pd(p, m, i, vec, _MM_SCALE_8);
+  }
+
+  inline void SIMD_scatter(double *p,
+                           const SIMD256_int &i, const SIMD_double &vec) {
+    _mm512_i32scatter_pd(p, i, vec, _MM_SCALE_8);
+  }
+
   // ------- Arithmetic Operations
 
+  inline SIMD256_int operator+(const SIMD256_int &one, const SIMD256_int &two) {
+    return _mm256_add_epi32(one,two);
+  }
+
   inline SIMD_int operator+(const SIMD_int &one, const SIMD_int &two) {
     return _mm512_add_epi32(one,two);
   }
@@ -286,6 +387,10 @@ namespace ip_simd {
     return _mm512_add_epi32(one,SIMD_set(two));
   }
 
+  inline SIMD256_int operator+(const SIMD256_int &one, const int two) {
+    return _mm256_add_epi32(one,SIMD256_set(two));
+  }
+
   inline SIMD_float operator+(const SIMD_float &one, const float two) {
     return _mm512_add_ps(one,SIMD_set(two));
   }
@@ -299,6 +404,11 @@ namespace ip_simd {
     return _mm512_mask_add_epi32(one,m,one,SIMD_set(two));
   }
 
+  inline SIMD256_int SIMD_add(const SIMD_mask &m,
+                           const SIMD256_int &one, const int two) {
+    return _mm256_mask_add_epi32(one,m,one,SIMD256_set(two));
+  }
+
   inline SIMD_float SIMD_add(const SIMD_mask &m,
                              const SIMD_float &one, const float two) {
     return _mm512_mask_add_ps(one,m,one,SIMD_set(two));
@@ -309,6 +419,11 @@ namespace ip_simd {
     return _mm512_mask_add_pd(one,m,one,SIMD_set(two));
   }
 
+  inline SIMD_double SIMD_add(const SIMD_mask &m,
+                              const SIMD_double &one, const SIMD_double &two) {
+    return _mm512_mask_add_pd(one,m,one,two);
+  }
+
   inline SIMD_int SIMD_add(const SIMD_int &s, const SIMD_mask &m,
                            const SIMD_int &one, const SIMD_int &two) {
     return _mm512_mask_add_epi32(s,m,one,two);
@@ -387,6 +502,10 @@ namespace ip_simd {
     return _mm512_mul_pd(one,two);
   }
 
+  inline SIMD256_int operator*(const SIMD256_int &one, const int two) {
+    return _mm256_mullo_epi32(one,SIMD256_set(two));
+  }
+
   inline SIMD_int operator*(const SIMD_int &one, const int two) {
     return _mm512_mullo_epi32(one,SIMD_set(two));
   }
@@ -417,6 +536,12 @@ namespace ip_simd {
     return _mm512_fmadd_pd(one,two,three);
   }
 
+  inline SIMD_double SIMD_fma(const SIMD_mask m, const SIMD_double &one,
+                              const SIMD_double &two,
+                              const SIMD_double &three) {
+    return _mm512_mask3_fmadd_pd(one,two,three,m);
+  }
+
   inline SIMD_float SIMD_fms(const SIMD_float &one, const SIMD_float &two,
                              const SIMD_float &three) {
     return _mm512_fmsub_ps(one,two,three);
@@ -493,6 +618,10 @@ namespace ip_simd {
     return _mm512_pow_pd(one, two);
   }
 
+  inline SIMD_double SIMD_pow(const SIMD_double &one, const double two) {
+    return _mm512_pow_pd(one, SIMD_set(two));
+  }
+
   inline SIMD_float SIMD_exp(const SIMD_float &one) {
     return _mm512_exp_ps(one);
   }
@@ -501,6 +630,18 @@ namespace ip_simd {
     return _mm512_exp_pd(one);
   }
 
+  inline SIMD_double SIMD_cos(const SIMD_double &one) {
+    return _mm512_cos_pd(one);
+  }
+
+  inline SIMD_double SIMD_sin(const SIMD_double &one) {
+    return _mm512_sin_pd(one);
+  }
+
+  inline SIMD_double SIMD_tan(const SIMD_double &one) {
+    return _mm512_tan_pd(one);
+  }
+
   // ------- Comparison operations
 
   inline SIMD_mask SIMD_lt(SIMD_mask m, const SIMD_int &one,
@@ -533,6 +674,14 @@ namespace ip_simd {
     return _mm512_mask_cmplt_pd_mask(m, SIMD_set(one), two);
   }
 
+  inline SIMD_mask operator<(const SIMD256_int &one, const SIMD256_int &two) {
+    return _mm256_cmplt_epi32_mask(one,two);
+  }
+
+  inline SIMD_mask operator<(const int one, const SIMD256_int &two) {
+    return _mm256_cmplt_epi32_mask(SIMD256_set(one),two);
+  }
+
   inline SIMD_mask operator<(const SIMD_int &one, const SIMD_int &two) {
     return _mm512_cmplt_epi32_mask(one,two);
   }
@@ -577,6 +726,10 @@ namespace ip_simd {
     return _mm512_cmple_ps_mask(SIMD_set(one), two);
   }
 
+  inline SIMD_mask operator<=(const SIMD_double &one, const SIMD_double &two) {
+    return _mm512_cmple_pd_mask(one, two);
+  }
+
   inline SIMD_mask operator<=(const double one, const SIMD_double &two) {
     return _mm512_cmple_pd_mask(SIMD_set(one), two);
   }
@@ -593,6 +746,14 @@ namespace ip_simd {
     return _mm512_cmplt_pd_mask(two,one);
   }
 
+  inline SIMD_mask operator>(const SIMD_double &one, const double two) {
+    return _mm512_cmplt_pd_mask(SIMD_set(two),one);
+  }
+
+  inline SIMD_mask operator==(const SIMD256_int &one, const int two) {
+    return _mm256_cmpeq_epi32_mask(one,_mm256_set1_epi32(two));
+  }
+
   inline SIMD_mask operator==(const SIMD_int &one, const SIMD_int &two) {
     return _mm512_cmpeq_epi32_mask(one,two);
   }

src/INTEL/npair_halffull_newton_intel.cpp

@@ -20,7 +20,9 @@
 
 #include "atom.h"
 #include "comm.h"
+#include "domain.h"
 #include "error.h"
+#include "force.h"
 #include "modify.h"
 #include "my_page.h"
 #include "neigh_list.h"
@@ -56,6 +58,9 @@ void NPairHalffullNewtonIntel::build_t(NeighList *list,
   const int * _noalias const numneigh_full = list->listfull->numneigh;
   const int ** _noalias const firstneigh_full = (const int ** const)list->listfull->firstneigh;  // NOLINT
 
+  const double delta = 0.01 * force->angstrom;
+  const int triclinic = domain->triclinic;
+
   #if defined(_OPENMP)
   #pragma omp parallel
   #endif
@@ -82,25 +87,50 @@ void NPairHalffullNewtonIntel::build_t(NeighList *list,
       const int * _noalias const jlist = firstneigh_full[i];
       const int jnum = numneigh_full[i];
 
-      #if defined(LMP_SIMD_COMPILER)
+      if (!triclinic) {
-      #pragma vector aligned
+        #if defined(LMP_SIMD_COMPILER)
-      #pragma ivdep
+        #pragma vector aligned
-      #endif
+        #pragma ivdep
-      for (int jj = 0; jj < jnum; jj++) {
+        #endif
-        const int joriginal = jlist[jj];
+        for (int jj = 0; jj < jnum; jj++) {
-        const int j = joriginal & NEIGHMASK;
+          const int joriginal = jlist[jj];
-        int addme = 1;
+          const int j = joriginal & NEIGHMASK;
-        if (j < nlocal) {
+          int addme = 1;
-          if (i > j) addme = 0;
+          if (j < nlocal) {
-        } else {
+            if (i > j) addme = 0;
-          if (x[j].z < ztmp) addme = 0;
+          } else {
-          if (x[j].z == ztmp) {
+            if (x[j].z < ztmp) addme = 0;
-            if (x[j].y < ytmp) addme = 0;
+            if (x[j].z == ztmp) {
-            if (x[j].y == ytmp && x[j].x < xtmp) addme = 0;
+              if (x[j].y < ytmp) addme = 0;
+              if (x[j].y == ytmp && x[j].x < xtmp) addme = 0;
+            }
           }
+          if (addme)
+            neighptr[n++] = joriginal;
+        }
+      } else {
+        #if defined(LMP_SIMD_COMPILER)
+        #pragma vector aligned
+        #pragma ivdep
+        #endif
+        for (int jj = 0; jj < jnum; jj++) {
+          const int joriginal = jlist[jj];
+          const int j = joriginal & NEIGHMASK;
+          int addme = 1;
+          if (j < nlocal) {
+            if (i > j) addme = 0;
+          } else {
+            if (fabs(x[j].z-ztmp) > delta) {
+              if (x[j].z < ztmp) addme = 0;
+            } else if (fabs(x[j].y-ytmp) > delta) {
+              if (x[j].y < ytmp) addme = 0;
+            } else {
+              if (x[j].x < xtmp) addme = 0;
+            }
+          }
+          if (addme)
+            neighptr[n++] = joriginal;
         }
-        if (addme)
-          neighptr[n++] = joriginal;
       }
 
       ilist[ii] = i;
@@ -203,7 +233,7 @@ void NPairHalffullNewtonIntel::build_t3(NeighList *list, int *numhalf)
 
 void NPairHalffullNewtonIntel::build(NeighList *list)
 {
-  if (_fix->three_body_neighbor() == 0) {
+  if (_fix->three_body_neighbor() == 0 || domain->triclinic) {
     if (_fix->precision() == FixIntel::PREC_MODE_MIXED)
       build_t(list, _fix->get_mixed_buffers());
     else if (_fix->precision() == FixIntel::PREC_MODE_DOUBLE)

src/INTEL/npair_halffull_newton_trim_intel.cpp

@@ -20,7 +20,9 @@
 
 #include "atom.h"
 #include "comm.h"
+#include "domain.h"
 #include "error.h"
+#include "force.h"
 #include "modify.h"
 #include "my_page.h"
 #include "neigh_list.h"
@@ -57,6 +59,8 @@ void NPairHalffullNewtonTrimIntel::build_t(NeighList *list,
   const int ** _noalias const firstneigh_full = (const int ** const)list->listfull->firstneigh;  // NOLINT
 
   const flt_t cutsq_custom = cutoff_custom * cutoff_custom;
+  const double delta = 0.01 * force->angstrom;
+  const int triclinic = domain->triclinic;
 
   #if defined(_OPENMP)
   #pragma omp parallel
@@ -84,35 +88,70 @@ void NPairHalffullNewtonTrimIntel::build_t(NeighList *list,
       const int * _noalias const jlist = firstneigh_full[i];
       const int jnum = numneigh_full[i];
 
-      #if defined(LMP_SIMD_COMPILER)
+      if (!triclinic) {
-      #pragma vector aligned
+        #if defined(LMP_SIMD_COMPILER)
-      #pragma ivdep
+        #pragma vector aligned
-      #endif
+        #pragma ivdep
-      for (int jj = 0; jj < jnum; jj++) {
+        #endif
-        const int joriginal = jlist[jj];
+        for (int jj = 0; jj < jnum; jj++) {
-        const int j = joriginal & NEIGHMASK;
+          const int joriginal = jlist[jj];
-        int addme = 1;
+          const int j = joriginal & NEIGHMASK;
-        if (j < nlocal) {
+          int addme = 1;
-          if (i > j) addme = 0;
+          if (j < nlocal) {
-        } else {
+            if (i > j) addme = 0;
-          if (x[j].z < ztmp) addme = 0;
+          } else {
-          if (x[j].z == ztmp) {
+            if (x[j].z < ztmp) addme = 0;
-            if (x[j].y < ytmp) addme = 0;
+            if (x[j].z == ztmp) {
-            if (x[j].y == ytmp && x[j].x < xtmp) addme = 0;
+              if (x[j].y < ytmp) addme = 0;
+              if (x[j].y == ytmp && x[j].x < xtmp) addme = 0;
+            }
           }
+
+          // trim to shorter cutoff
+
+          const flt_t delx = xtmp - x[j].x;
+          const flt_t dely = ytmp - x[j].y;
+          const flt_t delz = ztmp - x[j].z;
+          const flt_t rsq = delx * delx + dely * dely + delz * delz;
+
+          if (rsq > cutsq_custom) addme = 0;
+
+          if (addme)
+            neighptr[n++] = joriginal;
         }
+      } else {
+        #if defined(LMP_SIMD_COMPILER)
+        #pragma vector aligned
+        #pragma ivdep
+        #endif
+        for (int jj = 0; jj < jnum; jj++) {
+          const int joriginal = jlist[jj];
+          const int j = joriginal & NEIGHMASK;
+          int addme = 1;
+          if (j < nlocal) {
+            if (i > j) addme = 0;
+          } else {
+            if (fabs(x[j].z-ztmp) > delta) {
+              if (x[j].z < ztmp) addme = 0;
+            } else if (fabs(x[j].y-ytmp) > delta) {
+              if (x[j].y < ytmp) addme = 0;
+            } else {
+              if (x[j].x < xtmp) addme = 0;
+            }
+          }
 
-        // trim to shorter cutoff
+          // trim to shorter cutoff
 
-        const flt_t delx = xtmp - x[j].x;
+          const flt_t delx = xtmp - x[j].x;
-        const flt_t dely = ytmp - x[j].y;
+          const flt_t dely = ytmp - x[j].y;
-        const flt_t delz = ztmp - x[j].z;
+          const flt_t delz = ztmp - x[j].z;
-        const flt_t rsq = delx * delx + dely * dely + delz * delz;
+          const flt_t rsq = delx * delx + dely * dely + delz * delz;
 
-        if (rsq > cutsq_custom) addme = 0;
+          if (rsq > cutsq_custom) addme = 0;
 
-        if (addme)
+          if (addme)
-          neighptr[n++] = joriginal;
+            neighptr[n++] = joriginal;
+        }
       }
 
       ilist[ii] = i;
@@ -235,7 +274,7 @@ void NPairHalffullNewtonTrimIntel::build_t3(NeighList *list, int *numhalf,
 
 void NPairHalffullNewtonTrimIntel::build(NeighList *list)
 {
-  if (_fix->three_body_neighbor() == 0) {
+  if (_fix->three_body_neighbor() == 0 || domain->triclinic) {
     if (_fix->precision() == FixIntel::PREC_MODE_MIXED)
       build_t(list, _fix->get_mixed_buffers());
     else if (_fix->precision() == FixIntel::PREC_MODE_DOUBLE)

src/INTEL/npair_intel.cpp

@@ -204,6 +204,8 @@ void NPairIntel::bin_newton(const int offload, NeighList *list,
   }
   const int special_bound = sb;
 
+  const double delta = 0.01 * force->angstrom;
+
   #ifdef _LMP_INTEL_OFFLOAD
   const int * _noalias const binhead = this->binhead;
   const int * _noalias const bins = this->bins;
@@ -229,7 +231,7 @@ void NPairIntel::bin_newton(const int offload, NeighList *list,
     in(ncache_stride,maxnbors,nthreads,maxspecial,nstencil,e_nall,offload) \
     in(offload_end,separate_buffers,astart,aend,nlocal,molecular) \
     in(ntypes,xperiodic,yperiodic,zperiodic,xprd_half,yprd_half,zprd_half) \
-    in(pack_width,special_bound)                                        \
+    in(pack_width,special_bound,delta)                                  \
     out(overflow:length(5) alloc_if(0) free_if(0)) \
     out(timer_compute:length(1) alloc_if(0) free_if(0)) \
     signal(tag)
@@ -331,7 +333,7 @@ void NPairIntel::bin_newton(const int offload, NeighList *list,
         const flt_t ztmp = x[i].z;
         const int itype = x[i].w;
         tagint itag;
-        if (THREE) itag = tag[i];
+        if (THREE || (TRI && !FULL)) itag = tag[i];
         const int ioffset = ntypes * itype;
 
         const int ibin = atombin[i];
@@ -365,7 +367,7 @@ void NPairIntel::bin_newton(const int offload, NeighList *list,
             ty[u] = x[j].y;
             tz[u] = x[j].z;
             tjtype[u] = x[j].w;
-            if (THREE) ttag[u] = tag[j];
+            if (THREE || (TRI && !FULL)) ttag[u] = tag[j];
           }
 
           if (FULL == 0 && TRI != 1) {
@@ -486,12 +488,32 @@ void NPairIntel::bin_newton(const int offload, NeighList *list,
 
           // Triclinic
           if (TRI) {
-            if (tz[u] < ztmp) addme = 0;
+            if (FULL) {
-            if (tz[u] == ztmp) {
+              if (tz[u] < ztmp) addme = 0;
-              if (ty[u] < ytmp) addme = 0;
+              if (tz[u] == ztmp) {
-              if (ty[u] == ytmp) {
+                if (ty[u] < ytmp) addme = 0;
-                if (tx[u] < xtmp) addme = 0;
+                if (ty[u] == ytmp) {
-                if (tx[u] == xtmp && j <= i) addme = 0;
+                  if (tx[u] < xtmp) addme = 0;
+                  if (tx[u] == xtmp && j <= i) addme = 0;
+                }
+              }
+            } else {
+              if (j <= i) addme = 0;
+              if (j >= nlocal) {
+                const tagint jtag = ttag[u];
+                if (itag > jtag) {
+                  if ((itag+jtag) % 2 == 0) addme = 0;
+                } else if (itag < jtag) {
+                  if ((itag+jtag) % 2 == 1) addme = 0;
+                } else {
+                  if (fabs(tz[u]-ztmp) > delta) {
+                    if (tz[u] < ztmp) addme = 0;
+                  } else if (fabs(ty[u]-ytmp) > delta) {
+                    if (ty[u] < ytmp) addme = 0;
+                  } else {
+                    if (tx[u] < xtmp) addme = 0;
+                  }
+                }
               }
             }
           }