Merge pull request #4139 from akohlmey/eam-warning-bugfix

Later than last minute bugfix in EAM density warning for OPENMP package

.github/CODEOWNERS

@@ -37,7 +37,7 @@ src/MESONT/*          @iafoss
 src/ML-HDNNP/*        @singraber
 src/ML-IAP/*          @athomps
 src/ML-PACE/*         @yury-lysogorskiy
-src/ML-POD/*          @exapde @rohskopf
+src/ML-POD/*          @exapde
 src/MOFFF/*           @hheenen
 src/MOLFILE/*         @akohlmey
 src/NETCDF/*          @pastewka
@@ -61,12 +61,16 @@ src/GPU/pair_vashishta_gpu.*        @andeplane
 src/KOKKOS/pair_vashishta_kokkos.*  @andeplane
 src/MANYBODY/pair_vashishta_table.* @andeplane
 src/MANYBODY/pair_atm.*             @sergeylishchuk
+src/MANYBODY/pair_nb3b_screened.*   @flodesani
 src/REPLICA/*_grem.*                @dstelter92
 src/EXTRA-COMPUTE/compute_stress_mop*.* @RomainVermorel
 src/EXTRA-COMPUTE/compute_born_matrix.* @Bibobu @athomps
+src/EXTRA-FIX/fix_deform_pressure.* @jtclemm
 src/MISC/*_tracker.*                @jtclemm
 src/MC/fix_gcmc.*                   @athomps
 src/MC/fix_sgcmc.*                  @athomps
+src/REAXFF/compute_reaxff_atom.*    @rbberger
+src/KOKKOS/compute_reaxff_atom_kokkos.*    @rbberger
 src/REPLICA/fix_pimd_langevin.*     @Yi-FanLi
 
 # core LAMMPS classes
@@ -79,7 +83,7 @@ src/bond.*                @sjplimp
 src/comm*.*               @sjplimp
 src/compute.*             @sjplimp
 src/dihedral.*            @sjplimp
-src/domain.*              @sjplimp
+src/domain.*              @sjplimp @stanmoore1
 src/dump*.*               @sjplimp
 src/error.*               @sjplimp
 src/finish.*              @sjplimp
@@ -135,6 +139,7 @@ src/timer.*               @akohlmey
 src/utils.*               @akohlmey @rbberger
 src/verlet.*              @sjplimp @stanmoore1
 src/math_eigen_impl.h     @jewettaij
+src/fix_press_langevin.*  @Bibobu
 
 # tools
 tools/coding_standard/* @akohlmey @rbberger
@@ -151,12 +156,12 @@ tools/vim/*           @hammondkd
 unittest/*            @akohlmey
 
 # cmake
-cmake/*               @rbberger
+cmake/*               @akohlmey
 cmake/Modules/LAMMPSInterfacePlugin.cmake @akohlmey
 cmake/Modules/MPI4WIN.cmake @akohlmey
 cmake/Modules/OpenCLLoader.cmake @akohlmey
-cmake/Modules/Packages/COLVARS.cmake @rbberger @giacomofiorin
-cmake/Modules/Packages/KIM.cmake @rbberger @ellio167
+cmake/Modules/Packages/COLVARS.cmake @giacomofiorin
+cmake/Modules/Packages/KIM.cmake @ellio167
 cmake/presets/*.cmake @akohlmey
 
 # python

.github/CONTRIBUTING.md

@@ -5,9 +5,9 @@ Thank you for considering to contribute to the LAMMPS software project.
 The following is a set of guidelines as well as explanations of policies and work flows for contributing to the LAMMPS molecular dynamics software project. These guidelines focus on submitting issues or pull requests on the LAMMPS GitHub project.
 
 Thus please also have a look at:
-* [The guide for submitting new features in the LAMMPS manual](https://www.lammps.org/doc/Modify_contribute.html)
-* [The guide on programming style and requirement in the LAMMPS manual](https://www.lammps.org/doc/Modify_style.html)
-* [The GitHub tutorial in the LAMMPS manual](http://lammps.sandia.gov/doc/Howto_github.html)
+* [The guide for submitting new features in the LAMMPS manual](https://docs.lammps.org/Modify_contribute.html)
+* [The guide on programming style and requirement in the LAMMPS manual](https://docs.lammps.org/Modify_requirements.html)
+* [The GitHub tutorial in the LAMMPS manual](http://docs.lammps.org/Howto_github.html)
 
 ## Table of Contents
 
@@ -27,17 +27,17 @@ __
 
 ## I don't want to read this whole thing I just have a question!
 
-> **Note:** Please do not file an issue to ask a general question about LAMMPS, its features, how to use specific commands, or how perform simulations or analysis in LAMMPS. Instead post your question to either the ['lammps-users' mailing list](https://lammps.sandia.gov/mail.html) or the [LAMMPS Material Science Discourse forum](https://matsci.org/lammps). You do not need to be subscribed to post to the list (but a mailing list subscription avoids having your post delayed until it is approved by a mailing list moderator). Most posts to the mailing list receive a response within less than 24 hours. Before posting to the mailing list, please read the [mailing list guidelines](https://lammps.sandia.gov/guidelines.html). Following those guidelines will help greatly to get a helpful response. Always mention which LAMMPS version you are using. The LAMMPS forum was recently created as part of a larger effort to build a materials science community and have discussions not just about using LAMMPS. Thus the forum may be also used for discussions that would be off-topic for the mailing list. Those will just have to be posted to a more general category.
+> **Note:** Please do not file an issue to ask a general question about LAMMPS, its features, how to use specific commands, or how perform simulations or analysis in LAMMPS. Instead post your question to the [LAMMPS Material Science Discourse forum](https://matsci.org/lammps). Before posting to the forum, please read the general [guidelines](https://www.lammps.org/guidelines.html) and the forum specific [suggestions](https://matsci.org/t/please-read-this-first-guidelines-and-suggestions-for-posting-lammps-questions/49913). Following those guidelines and suggestions will help greatly to get a helpful response.  *Always* mention which LAMMPS version you are using. The MatSci website may be also used for discussions that would be off-topic for the LAMMPS categories. Those will just have to be posted to a different category.
 
 ## How Can I Contribute?
 
 There are several ways how you can actively contribute to the LAMMPS project: you can discuss compiling and using LAMMPS, and solving LAMMPS related problems with other LAMMPS users on the lammps-users mailing list or the forum, you can report bugs or suggest enhancements by creating issues on GitHub (or posting them to the lammps-users mailing list or posting in the LAMMPS Materials Science Discourse forum), and you can contribute by submitting pull requests on GitHub or e-mail your code
-to one of the [LAMMPS core developers](https://lammps.sandia.gov/authors.html). As you may see from the aforementioned developer page, the LAMMPS software package includes the efforts of a very large number of contributors beyond the principal authors and maintainers.
+to one of the [LAMMPS core developers](https://www.lammps.org/authors.html). As you may see from the aforementioned developer page, the LAMMPS software package includes the efforts of a very large number of contributors beyond the principal authors and maintainers.
 
 ### Discussing How To Use LAMMPS
 
 The LAMMPS mailing list is hosted at SourceForge. The mailing list began in 2005, and now includes tens of thousands of messages in thousands of threads. LAMMPS developers try to respond to posted questions in a timely manner, but there are no guarantees. Please consider that people live in different timezone and may not have time to answer e-mails outside of their work hours.
-You can post to list by sending your email to lammps-users at lists.sourceforge.net (no subscription required), but before posting, please read the [mailing list guidelines](https://lammps.sandia.gov/guidelines.html) to maximize your chances to receive a helpful response.
+You can post to list by sending your email to lammps-users at lists.sourceforge.net (no subscription required), but before posting, please read the [mailing list guidelines](https://www.lammps.org/guidelines.html) to maximize your chances to receive a helpful response.
 
 Anyone can browse/search previous questions/answers in the archives. You do not have to subscribe to the list to post questions, receive answers (to your questions), or browse/search the archives. You **do** need to subscribe to the list if you want emails for **all** the posts (as individual messages or in digest form), or to answer questions yourself. Feel free to sign up and help us out! Answering questions from fellow LAMMPS users is a great way to pay back the community for providing you a useful tool for free, and to pass on the advice you have received yourself to others. It improves your karma and helps you understand your own research better.
 
@@ -47,7 +47,7 @@ The LAMMPS Materials Science Discourse forum was created recently to facilitate
 
 ### Reporting Bugs
 
-While developers writing code for LAMMPS are careful to test their code, LAMMPS is such a large and complex software, that it is impossible to test for all combinations of features under all normal and not so normal circumstances. Thus bugs do happen, and if you suspect, that you have encountered one, please try to document it and report it as an [Issue](https://github.com/lammps/lammps/issues) on the LAMMPS GitHub project web page. However, before reporting a bug, you need to check whether this is something that may have already been corrected. The [Latest Features and Bug Fixes in LAMMPS](https://lammps.sandia.gov/bug.html) web page lists all significant changes to LAMMPS over the years. It also tells you what the current latest development version of LAMMPS is, and you should test whether your issue still applies to that version.
+While developers writing code for LAMMPS are careful to test their code, LAMMPS is such a large and complex software, that it is impossible to test for all combinations of features under all normal and not so normal circumstances. Thus bugs do happen, and if you suspect, that you have encountered one, please try to document it and report it as an [Issue](https://github.com/lammps/lammps/issues) on the LAMMPS GitHub project web page. However, before reporting a bug, you need to check whether this is something that may have already been corrected. The [Latest Features and Bug Fixes in LAMMPS](https://www.lammps.org/bug.html) web page lists all significant changes to LAMMPS over the years. It also tells you what the current latest development version of LAMMPS is, and you should test whether your issue still applies to that version.
 
 When you click on the green "New Issue" button, you will be provided with a text field, where you can enter your message. That text field with contain a template with several headlines and some descriptions. Keep the headlines that are relevant to your reported potential bug and replace the descriptions with the information as suggested by the descriptions.
 You can also attach small text files (please add the file name extension `.txt` or it will be rejected), images, or small compressed text files (using gzip, do not use RAR or 7-ZIP or similar tools that are uncommon outside of Windows machines). In many cases, bugs are best illustrated by providing a small input deck (do **not** attach your entire production input, but remove everything that is not required to reproduce the issue, and scale down your system size, that the resulting calculation runs fast and can be run on small desktop quickly).
@@ -65,9 +65,9 @@ To be able to submit an issue on GitHub, you have to register for an account (fo
 
 We encourage users to submit new features or modifications for LAMMPS. Instructions, guidelines, requirements,
 and recommendations are in the following sections of the LAMMPS manual:
-* [The guide for submitting new features in the LAMMPS manual](https://lammps.sandia.gov/doc/Modify_contribute.html)
-* [The guide on programming style and requirement in the LAMMPS manual](https://lammps.sandia.gov/doc/Modify_contribute.html)
-* [The GitHub tutorial in the LAMMPS manual](http://lammps.sandia.gov/doc/Howto_github.html)
+* [The guide for submitting new features in the LAMMPS manual](https://docs.lammps.org/Modify_contribute.html)
+* [The guide on programming style and requirement in the LAMMPS manual](https://docs.lammps.org/Modify_requirements.html)
+* [The GitHub tutorial in the LAMMPS manual](http://docs.lammps.org/Howto_github.html)
 
 
 ## GitHub Workflows
@@ -85,7 +85,7 @@ For bug reports, the next step is that one of the core LAMMPS developers will se
 ### Pull Requests
 
 Pull requests are the **only** way that changes get made to the LAMMPS distribution.  So also the LAMMPS core developers will submit pull requests for their own changes and discuss them on GitHub.  Thus if you submit a pull request it will be treated in a similar fashion. When you submit a pull request you may opt to submit a "Draft" pull request.  That means your changes are visible and will be subject to testing, but reviewers will not be (auto-)assigned and comments will take into account that this is not complete. On the other hand, this is a perfect way to ask the LAMMPS developers for comments on non-obvious changes and get feedback and possible suggestions for improvements or recommendations about what to avoid.
-Immediately after the submission, the LAMMPS continuing integration server at ci.lammps.org will download your submitted branch and perform a number of tests: it will tests whether it compiles cleanly under various conditions, it will also do a check on whether your included documentation translates cleanly and run some unit tests and other checks. Whether these tests are successful or fail will be recorded.  If a test fails, please inspect the corresponding output on the CI server and take the necessary steps, if needed, so that the code can compile cleanly again.  The test will be re-run each time the pull request is updated with a push to the remote branch on GitHub.  If you are unsure about what you need to change, ask a question in the discussion area of the pull request.
+Immediately after the submission, the LAMMPS continuing integration server at https://ci.lammps.org will download your submitted branch and perform a number of tests: it will tests whether it compiles cleanly under various conditions, it will also do a check on whether your included documentation translates cleanly and run some unit tests and other checks. Whether these tests are successful or fail will be recorded.  If a test fails, please inspect the corresponding output on the CI server and take the necessary steps, if needed, so that the code can compile cleanly again.  The test will be re-run each time the pull request is updated with a push to the remote branch on GitHub.  If you are unsure about what you need to change, ask a question in the discussion area of the pull request.
 Next a LAMMPS core developer will self-assign and do an overall technical assessment of the submission.  If you submitted a draft pull request, this will not happen unless you mark it "ready for review".  If you are not yet invited as a LAMMPS collaborator, and your contribution seems significant, you may also receive an invitation for collaboration on the LAMMPS repository.  As part of the assessment, the pull request will be categorized with labels. There are two special labels: `needs_work` (indicates that work from the submitter of the pull request is needed) and `work_in_progress` (indicates, that the assigned LAMMPS developer will make changes, if not done by the contributor who made the submit). 
 You may also receive comments and suggestions on the overall submission or specific details and on occasion specific requests for changes as part of the review. If permitted, also additional changes may be pushed into your pull request branch or a pull request may be filed in your LAMMPS fork on GitHub to include those changes.
 The LAMMPS developer may then decide to assign the pull request to another developer (e.g. when that developer is more knowledgeable about the submitted feature or enhancement or has written the modified code). It may also happen, that additional developers are requested to provide a review and approve the changes. For submissions, that may change the general behavior of LAMMPS, or where a possibility of unwanted side effects exists, additional tests may be requested by the assigned developer.

.github/workflows/codeql-analysis.yml

@@ -25,17 +25,17 @@ jobs:
 
     steps:
     - name: Checkout repository
-      uses: actions/checkout@v3
+      uses: actions/checkout@v4
       with:
         fetch-depth: 2
 
     - name: Setup Python
-      uses: actions/setup-python@v4
+      uses: actions/setup-python@v5
       with:
         python-version: '3.x'
 
     - name: Initialize CodeQL
-      uses: github/codeql-action/init@v2
+      uses: github/codeql-action/init@v3
       with:
         languages: ${{ matrix.language }}
         config-file: ./.github/codeql/${{ matrix.language }}.yml
@@ -55,4 +55,4 @@ jobs:
         cmake --build . --parallel 2
 
     - name: Perform CodeQL Analysis
-      uses: github/codeql-action/analyze@v2
+      uses: github/codeql-action/analyze@v3

.github/workflows/compile-msvc.yml

@@ -19,12 +19,12 @@ jobs:
 
     steps:
     - name: Checkout repository
-      uses: actions/checkout@v3
+      uses: actions/checkout@v4
       with:
         fetch-depth: 2
 
     - name: Select Python version
-      uses: actions/setup-python@v4
+      uses: actions/setup-python@v5
       with:
         python-version: '3.11'
 

.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
 
@@ -25,7 +25,7 @@ jobs:
 
     - name: Cache Coverity
       id: cache-coverity
-      uses: actions/cache@v3
+      uses: actions/cache@v4
       with:
         path: ./download/
         key: ${{ runner.os }}-download-${{ hashFiles('**/coverity_tool.*') }}
@@ -59,16 +59,13 @@ jobs:
         -D BUILD_SHARED_LIBS=on \
         -D LAMMPS_SIZES=SMALLBIG \
         -D LAMMPS_EXCEPTIONS=off \
-        -D PKG_MESSAGE=on \
-        -D PKG_MPIIO=on \
         -D PKG_ATC=on \
         -D PKG_AWPMD=on \
-        -D PKG_BOCS=on \
-        -D PKG_EFF=on \
         -D PKG_H5MD=on \
         -D PKG_INTEL=on \
         -D PKG_LATBOLTZ=on \
         -D PKG_MANIFOLD=on \
+        -D PKG_MDI=on \
         -D PKG_MGPT=on \
         -D PKG_ML-PACE=on \
         -D PKG_ML-RANN=on \
@@ -77,7 +74,6 @@ jobs:
         -D PKG_PTM=on \
         -D PKG_QTB=on \
         -D PKG_SMTBQ=on \
-        -D PKG_TALLY=on \
         ../cmake
 
     - name: Run Coverity Scan

.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
 
@@ -32,7 +32,7 @@ jobs:
       run: mkdir build
 
     - name: Set up ccache
-      uses: actions/cache@v3
+      uses: actions/cache@v4
       with:
         path: ${{ env.CCACHE_DIR }}
         key: macos-ccache-${{ github.sha }}

cmake/CMakeLists.txt

@@ -1,8 +1,8 @@
+# -*- CMake -*- master configuration file for building LAMMPS
 ########################################
 # CMake build system
 # This file is part of LAMMPS
-# Created by Christoph Junghans and Richard Berger
-cmake_minimum_required(VERSION 3.10)
+cmake_minimum_required(VERSION 3.16)
 ########################################
 # set policy to silence warnings about ignoring <PackageName>_ROOT but use it
 if(POLICY CMP0074)
@@ -12,22 +12,11 @@ endif()
 if(POLICY CMP0075)
   cmake_policy(SET CMP0075 NEW)
 endif()
-# set policy to silence warnings about missing executable permissions in
-# pythonx.y-config when cross-compiling. review occasionally if it may be set to NEW
-if(POLICY CMP0109)
-  cmake_policy(SET CMP0109 OLD)
-endif()
 # set policy to silence warnings about timestamps of downloaded files. review occasionally if it may be set to NEW
 if(POLICY CMP0135)
   cmake_policy(SET CMP0135 OLD)
 endif()
-########################################
-# Use CONFIGURE_DEPENDS as option for file(GLOB...) when available
-if(CMAKE_VERSION VERSION_LESS 3.12)
-  unset(CONFIGURE_DEPENDS)
-else()
-  set(CONFIGURE_DEPENDS CONFIGURE_DEPENDS)
-endif()
+
 ########################################
 
 project(lammps CXX)
@@ -116,7 +105,7 @@ if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
     if(CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.3 OR CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.4)
       set(CMAKE_TUNE_DEFAULT "-xCOMMON-AVX512")
     else()
-      set(CMAKE_TUNE_DEFAULT "-xHost -fp-model fast=2 -no-prec-div -qoverride-limits -diag-disable=10441 -diag-disable=2196")
+      set(CMAKE_TUNE_DEFAULT "-xHost -fp-model fast=2 -no-prec-div -qoverride-limits -diag-disable=10441 -diag-disable=11074 -diag-disable=11076 -diag-disable=2196")
     endif()
   endif()
 endif()
@@ -131,20 +120,33 @@ if((CMAKE_CXX_COMPILER_ID STREQUAL "NVHPC") OR (CMAKE_CXX_COMPILER_ID STREQUAL "
   set(CMAKE_TUNE_DEFAULT "-Minform=severe")
 endif()
 
+# this hack is required to compile fmt lib with CrayClang version 15.0.2
+# CrayClang is only directly recognized by version 3.28 and later
+if(CMAKE_VERSION VERSION_LESS 3.28)
+  get_filename_component(_exe "${CMAKE_CXX_COMPILER}" NAME)
+  if((CMAKE_CXX_COMPILER_ID STREQUAL "Clang") AND (_exe STREQUAL "crayCC"))
+    set(CMAKE_TUNE_DEFAULT "-DFMT_STATIC_THOUSANDS_SEPARATOR")
+  endif()
+else()
+  if(CMAKE_CXX_COMPILER_ID STREQUAL "CrayClang")
+    set(CMAKE_TUNE_DEFAULT "-DFMT_STATIC_THOUSANDS_SEPARATOR")
+  endif()
+endif()
+
 # silence nvcc warnings
 if((PKG_KOKKOS) AND (Kokkos_ENABLE_CUDA) AND NOT (CMAKE_CXX_COMPILER_ID STREQUAL "Clang"))
   set(CMAKE_TUNE_DEFAULT "${CMAKE_TUNE_DEFAULT} -Xcudafe --diag_suppress=unrecognized_pragma")
 endif()
 
-# we require C++11 without extensions. Kokkos requires at least C++14 (currently)
+# we require C++11 without extensions. Kokkos requires at least C++17 (currently)
 if(NOT CMAKE_CXX_STANDARD)
   set(CMAKE_CXX_STANDARD 11)
 endif()
 if(CMAKE_CXX_STANDARD LESS 11)
   message(FATAL_ERROR "C++ standard must be set to at least 11")
 endif()
-if(PKG_KOKKOS AND (CMAKE_CXX_STANDARD LESS 14))
-  set(CMAKE_CXX_STANDARD 14)
+if(PKG_KOKKOS AND (CMAKE_CXX_STANDARD LESS 17))
+  set(CMAKE_CXX_STANDARD 17)
 endif()
 set(CMAKE_CXX_STANDARD_REQUIRED ON)
 set(CMAKE_CXX_EXTENSIONS OFF CACHE BOOL "Use compiler extensions")
@@ -155,6 +157,7 @@ if(MSVC)
     add_compile_options(/Zc:__cplusplus)
     add_compile_options(/wd4244)
     add_compile_options(/wd4267)
+    add_compile_options(/wd4250)
     add_compile_options(/EHsc)
   endif()
   add_compile_definitions(_CRT_SECURE_NO_WARNINGS)
@@ -168,17 +171,20 @@ endif()
 ########################################################################
 # User input options                                                   #
 ########################################################################
-# set path to python interpreter and thus enforcing python version when
-# in a virtual environment and PYTHON_EXECUTABLE is not set on command line
-if(DEFINED ENV{VIRTUAL_ENV} AND NOT PYTHON_EXECUTABLE)
-  if(CMAKE_HOST_SYSTEM_NAME STREQUAL "Windows")
-    set(PYTHON_EXECUTABLE "$ENV{VIRTUAL_ENV}/Scripts/python.exe")
-  else()
-    set(PYTHON_EXECUTABLE "$ENV{VIRTUAL_ENV}/bin/python")
-  endif()
+# backward compatibility with CMake before 3.12 and older LAMMPS documentation
+if (PYTHON_EXECUTABLE)
   set(Python_EXECUTABLE "${PYTHON_EXECUTABLE}")
+endif()
+# set path to python interpreter and thus enforcing python version when
+# in a virtual environment and Python_EXECUTABLE is not set on command line
+if(DEFINED ENV{VIRTUAL_ENV} AND NOT Python_EXECUTABLE)
+  if(CMAKE_HOST_SYSTEM_NAME STREQUAL "Windows")
+    set(Python_EXECUTABLE "$ENV{VIRTUAL_ENV}/Scripts/python.exe")
+  else()
+    set(Python_EXECUTABLE "$ENV{VIRTUAL_ENV}/bin/python")
+  endif()
   message(STATUS "Running in virtual environment: $ENV{VIRTUAL_ENV}\n"
-    "   Setting Python interpreter to: ${PYTHON_EXECUTABLE}")
+    "   Setting Python interpreter to: ${Python_EXECUTABLE}")
 endif()
 
 set(LAMMPS_MACHINE "" CACHE STRING "Suffix to append to lmp binary (WON'T enable any features automatically")
@@ -203,8 +209,8 @@ else()
 endif()
 
 include(GNUInstallDirs)
-file(GLOB ALL_SOURCES ${CONFIGURE_DEPENDS} ${LAMMPS_SOURCE_DIR}/[^.]*.cpp)
-file(GLOB MAIN_SOURCES ${CONFIGURE_DEPENDS} ${LAMMPS_SOURCE_DIR}/main.cpp)
+file(GLOB ALL_SOURCES CONFIGURE_DEPENDS ${LAMMPS_SOURCE_DIR}/[^.]*.cpp)
+file(GLOB MAIN_SOURCES CONFIGURE_DEPENDS ${LAMMPS_SOURCE_DIR}/main.cpp)
 list(REMOVE_ITEM ALL_SOURCES ${MAIN_SOURCES})
 add_library(lammps ${ALL_SOURCES})
 
@@ -216,6 +222,10 @@ endif()
 add_executable(lmp ${MAIN_SOURCES})
 target_link_libraries(lmp PRIVATE lammps)
 set_target_properties(lmp PROPERTIES OUTPUT_NAME ${LAMMPS_BINARY})
+# re-export all symbols for plugins
+if(PKG_PLUGIN AND (NOT ((CMAKE_SYSTEM_NAME STREQUAL "Windows"))))
+  set_target_properties(lmp PROPERTIES ENABLE_EXPORTS TRUE)
+endif()
 install(TARGETS lmp EXPORT LAMMPS_Targets DESTINATION ${CMAKE_INSTALL_BINDIR})
 
 option(CMAKE_VERBOSE_MAKEFILE "Generate verbose Makefiles" OFF)
@@ -278,8 +288,6 @@ set(STANDARD_PACKAGES
   MOFFF
   MOLECULE
   MOLFILE
-  MPIIO
-  MSCG
   NETCDF
   ORIENT
   PERI
@@ -385,15 +393,9 @@ if(NOT ${LAMMPS_MEMALIGN} STREQUAL "0")
   target_compile_definitions(lammps PRIVATE -DLAMMPS_MEMALIGN=${LAMMPS_MEMALIGN})
 endif()
 
-option(LAMMPS_EXCEPTIONS "enable the use of C++ exceptions for error messages (useful for library interface)" ${ENABLE_TESTING})
-if(LAMMPS_EXCEPTIONS)
-  target_compile_definitions(lammps PUBLIC -DLAMMPS_EXCEPTIONS)
-endif()
-
 # "hard" dependencies between packages resulting
 # in an error instead of skipping over files
 pkg_depends(ML-IAP ML-SNAP)
-pkg_depends(MPIIO MPI)
 pkg_depends(ATC MANYBODY)
 pkg_depends(LATBOLTZ MPI)
 pkg_depends(SCAFACOS MPI)
@@ -404,6 +406,7 @@ pkg_depends(CG-DNA MOLECULE)
 pkg_depends(CG-DNA ASPHERE)
 pkg_depends(ELECTRODE KSPACE)
 pkg_depends(EXTRA-MOLECULE MOLECULE)
+pkg_depends(MESONT MOLECULE)
 
 # detect if we may enable OpenMP support by default
 set(BUILD_OMP_DEFAULT OFF)
@@ -429,6 +432,7 @@ if(BUILD_OMP)
       (CMAKE_CXX_COMPILER_ID STREQUAL "IntelLLVM") OR (CMAKE_CXX_COMPILER_ID STREQUAL "XLClang") OR
       ((CMAKE_CXX_COMPILER_ID STREQUAL "AppleClang") AND (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 10.0)) OR
       ((CMAKE_CXX_COMPILER_ID STREQUAL "Clang") AND (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 10.0)) OR
+      ((CMAKE_CXX_COMPILER_ID STREQUAL "CrayClang") AND (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 10.0)) OR
       ((CMAKE_CXX_COMPILER_ID STREQUAL "Intel") AND (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 19.0)))
     # GCC 9.x and later plus Clang 10.x and later implement strict OpenMP 4.0 semantics for consts.
     # Intel 18.0 was tested to support both, so we switch to OpenMP 4+ from 19.x onward to be safe.
@@ -439,16 +443,43 @@ if(BUILD_OMP)
   target_compile_definitions(lammps PRIVATE -DLAMMPS_OMP_COMPAT=${LAMMPS_OMP_COMPAT_LEVEL})
   target_link_libraries(lammps PRIVATE OpenMP::OpenMP_CXX)
   target_link_libraries(lmp PRIVATE OpenMP::OpenMP_CXX)
+
+  # this hack is required to correctly link with OpenMP support when using CrayClang version 15.0.2
+  # CrayClang is only directly recognized by version 3.28 and later
+  if(CMAKE_VERSION VERSION_LESS 3.28)
+    get_filename_component(_exe "${CMAKE_CXX_COMPILER}" NAME)
+    if((CMAKE_CXX_COMPILER_ID STREQUAL "Clang") AND (_exe STREQUAL "crayCC"))
+      set(CMAKE_SHARED_LINKER_FLAGS_${BTYPE} "${CMAKE_SHARED_LINKER_FLAGS_${BTYPE} -fopenmp")
+      set(CMAKE_STATIC_LINKER_FLAGS_${BTYPE} "${CMAKE_STATIC_LINKER_FLAGS_${BTYPE} -fopenmp")
+    endif()
+  else()
+    if(CMAKE_CXX_COMPILER_ID STREQUAL "CrayClang")
+      set(CMAKE_SHARED_LINKER_FLAGS_${BTYPE} "${CMAKE_SHARED_LINKER_FLAGS_${BTYPE} -fopenmp")
+      set(CMAKE_STATIC_LINKER_FLAGS_${BTYPE} "${CMAKE_STATIC_LINKER_FLAGS_${BTYPE} -fopenmp")
+    endif()
+  endif()
 endif()
 
-if(PKG_MSCG OR PKG_ATC OR PKG_AWPMD OR PKG_ML-QUIP OR PKG_ML-POD OR PKG_ELECTRODE OR BUILD_TOOLS)
+# lower C++ standard for fmtlib sources when using Intel classic compiler
+if((CMAKE_CXX_COMPILER_ID STREQUAL "Intel") AND (CMAKE_CXX_STANDARD GREATER_EQUAL 17)
+    AND (CMAKE_CXX_COMPILER_VERSION VERSION_LESS 2021.10))
+  message(STATUS "Lowering C++ standard for compiling fmtlib sources with Intel Classic compiler")
+  get_filename_component(LMP_UTILS_SRC "${LAMMPS_SOURCE_DIR}/utils.cpp" ABSOLUTE)
+  get_filename_component(LMP_VARIABLE_SRC "${LAMMPS_SOURCE_DIR}/variable.cpp" ABSOLUTE)
+  get_filename_component(FMT_FORMAT_SRC "${LAMMPS_SOURCE_DIR}/fmtlib_format.cpp" ABSOLUTE)
+  get_filename_component(FMT_OS_SRC "${LAMMPS_SOURCE_DIR}/fmtlib_os.cpp" ABSOLUTE)
+  set_source_files_properties("${FMT_FORMAT_SRC}" "${FMT_OS_SRC}" "${LMP_VARIABLE_SRC}" "${LMP_UTILS_SRC}"
+          PROPERTIES COMPILE_OPTIONS "-std=c++14")
+endif()
+
+if(PKG_ATC OR PKG_AWPMD OR PKG_ML-QUIP OR PKG_ML-POD OR PKG_ELECTRODE OR BUILD_TOOLS)
   enable_language(C)
   if (NOT USE_INTERNAL_LINALG)
     find_package(LAPACK)
     find_package(BLAS)
   endif()
   if(NOT LAPACK_FOUND OR NOT BLAS_FOUND OR USE_INTERNAL_LINALG)
-    file(GLOB LINALG_SOURCES ${CONFIGURE_DEPENDS} ${LAMMPS_LIB_SOURCE_DIR}/linalg/[^.]*.cpp)
+    file(GLOB LINALG_SOURCES CONFIGURE_DEPENDS ${LAMMPS_LIB_SOURCE_DIR}/linalg/[^.]*.cpp)
     add_library(linalg STATIC ${LINALG_SOURCES})
     set_target_properties(linalg PROPERTIES OUTPUT_NAME lammps_linalg${LAMMPS_MACHINE})
     set(BLAS_LIBRARIES "$<TARGET_FILE:linalg>")
@@ -466,12 +497,7 @@ option(WITH_JPEG "Enable JPEG support" ${JPEG_FOUND})
 if(WITH_JPEG)
   find_package(JPEG REQUIRED)
   target_compile_definitions(lammps PRIVATE -DLAMMPS_JPEG)
-  if(CMAKE_VERSION VERSION_LESS 3.12)
-    target_include_directories(lammps PRIVATE ${JPEG_INCLUDE_DIRS})
-    target_link_libraries(lammps PRIVATE ${JPEG_LIBRARIES})
-  else()
-    target_link_libraries(lammps PRIVATE JPEG::JPEG)
-  endif()
+  target_link_libraries(lammps PRIVATE JPEG::JPEG)
 endif()
 
 find_package(PNG QUIET)
@@ -521,7 +547,7 @@ else()
 endif()
 
 foreach(PKG_WITH_INCL KSPACE PYTHON ML-IAP VORONOI COLVARS ML-HDNNP MDI MOLFILE NETCDF
-        PLUMED QMMM ML-QUIP SCAFACOS MACHDYN VTK KIM MSCG COMPRESS ML-PACE LEPTON)
+        PLUMED QMMM ML-QUIP SCAFACOS MACHDYN VTK KIM COMPRESS ML-PACE LEPTON)
   if(PKG_${PKG_WITH_INCL})
     include(Packages/${PKG_WITH_INCL})
   endif()
@@ -546,12 +572,12 @@ endforeach()
 ########################################################################
 # Basic system tests (standard libraries, headers, functions, types)   #
 ########################################################################
-foreach(HEADER cmath)
-  check_include_file_cxx(${HEADER} FOUND_${HEADER})
-  if(NOT FOUND_${HEADER})
-    message(FATAL_ERROR "Could not find needed header - ${HEADER}")
-  endif(NOT FOUND_${HEADER})
-endforeach(HEADER)
+if (NOT ((CMAKE_CXX_COMPILER_ID STREQUAL "Intel") OR (CMAKE_CXX_COMPILER_ID STREQUAL "IntelLLVM")))
+  check_include_file_cxx(cmath FOUND_CMATH)
+  if(NOT FOUND_CMATH)
+    message(FATAL_ERROR "Could not find the required 'cmath' header")
+  endif(NOT FOUND_CMATH)
+endif()
 
 # make the standard math library overrideable and autodetected (for systems that don't have it)
 find_library(STANDARD_MATH_LIB m DOC "Standard Math library")
@@ -583,8 +609,8 @@ endforeach()
 foreach(PKG ${STANDARD_PACKAGES})
   set(${PKG}_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/${PKG})
 
-  file(GLOB ${PKG}_SOURCES ${CONFIGURE_DEPENDS} ${${PKG}_SOURCES_DIR}/[^.]*.cpp)
-  file(GLOB ${PKG}_HEADERS ${CONFIGURE_DEPENDS} ${${PKG}_SOURCES_DIR}/[^.]*.h)
+  file(GLOB ${PKG}_SOURCES CONFIGURE_DEPENDS ${${PKG}_SOURCES_DIR}/[^.]*.cpp)
+  file(GLOB ${PKG}_HEADERS CONFIGURE_DEPENDS ${${PKG}_SOURCES_DIR}/[^.]*.h)
 
   # check for package files in src directory due to old make system
   DetectBuildSystemConflict(${LAMMPS_SOURCE_DIR} ${${PKG}_SOURCES} ${${PKG}_HEADERS})
@@ -600,19 +626,12 @@ foreach(PKG ${STANDARD_PACKAGES})
   RegisterPackages(${${PKG}_SOURCES_DIR})
 endforeach()
 
-# packages that need defines set
-foreach(PKG MPIIO)
-  if(PKG_${PKG})
-    target_compile_definitions(lammps PRIVATE -DLMP_${PKG})
-  endif()
-endforeach()
-
 # dedicated check for entire contents of accelerator packages
 foreach(PKG ${SUFFIX_PACKAGES})
   set(${PKG}_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/${PKG})
 
-  file(GLOB ${PKG}_SOURCES ${CONFIGURE_DEPENDS} ${${PKG}_SOURCES_DIR}/[^.]*.cpp)
-  file(GLOB ${PKG}_HEADERS ${CONFIGURE_DEPENDS} ${${PKG}_SOURCES_DIR}/[^.]*.h)
+  file(GLOB ${PKG}_SOURCES CONFIGURE_DEPENDS ${${PKG}_SOURCES_DIR}/[^.]*.cpp)
+  file(GLOB ${PKG}_HEADERS CONFIGURE_DEPENDS ${${PKG}_SOURCES_DIR}/[^.]*.h)
 
   # check for package files in src directory due to old make system
   DetectBuildSystemConflict(${LAMMPS_SOURCE_DIR} ${${PKG}_SOURCES} ${${PKG}_HEADERS})
@@ -626,7 +645,7 @@ endforeach()
 foreach(PKG_LIB POEMS ATC AWPMD H5MD)
   if(PKG_${PKG_LIB})
     string(TOLOWER "${PKG_LIB}" PKG_LIB)
-    file(GLOB_RECURSE ${PKG_LIB}_SOURCES ${CONFIGURE_DEPENDS}
+    file(GLOB_RECURSE ${PKG_LIB}_SOURCES CONFIGURE_DEPENDS
       ${LAMMPS_LIB_SOURCE_DIR}/${PKG_LIB}/[^.]*.c ${LAMMPS_LIB_SOURCE_DIR}/${PKG_LIB}/[^.]*.cpp)
     add_library(${PKG_LIB} STATIC ${${PKG_LIB}_SOURCES})
     set_target_properties(${PKG_LIB} PROPERTIES OUTPUT_NAME lammps_${PKG_LIB}${LAMMPS_MACHINE})
@@ -821,20 +840,8 @@ install(
 # This is primarily for people that only want to use the Python wrapper.
 ###############################################################################
 if(BUILD_SHARED_LIBS)
-  if(CMAKE_VERSION VERSION_LESS 3.12)
-    # adjust so we find Python 3 versions before Python 2 on old systems with old CMake
-    set(Python_ADDITIONAL_VERSIONS 3.12 3.11 3.10 3.9 3.8 3.7 3.6)
-    find_package(PythonInterp) # Deprecated since version 3.12
-    if(PYTHONINTERP_FOUND)
-      set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
-    endif()
-  else()
-    # backward compatibility
-    if(PYTHON_EXECUTABLE)
-      set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
-    endif()
-    find_package(Python COMPONENTS Interpreter)
-  endif()
+  # backward compatibility
+  find_package(Python COMPONENTS Interpreter)
   if(BUILD_IS_MULTI_CONFIG)
     set(MY_BUILD_DIR ${CMAKE_BINARY_DIR}/$<CONFIG>)
   else()
@@ -893,13 +900,23 @@ else()
 endif()
 include(FeatureSummary)
 feature_summary(DESCRIPTION "The following tools and libraries have been found and configured:" WHAT PACKAGES_FOUND)
+if(GIT_FOUND AND EXISTS ${LAMMPS_DIR}/.git)
+  execute_process(COMMAND ${GIT_EXECUTABLE} describe --dirty=-modified --always
+    OUTPUT_VARIABLE GIT_DESCRIBE
+    ERROR_QUIET
+    WORKING_DIRECTORY ${LAMMPS_DIR}
+    OUTPUT_STRIP_TRAILING_WHITESPACE)
+endif()
 message(STATUS "<<< Build configuration >>>
-   LAMMPS Version:   ${PROJECT_VERSION}
+   LAMMPS Version:   ${PROJECT_VERSION} ${GIT_DESCRIBE}
    Operating System: ${CMAKE_SYSTEM_NAME} ${CMAKE_LINUX_DISTRO} ${CMAKE_DISTRO_VERSION}
    CMake Version:    ${CMAKE_VERSION}
    Build type:       ${LAMMPS_BUILD_TYPE}
    Install path:     ${CMAKE_INSTALL_PREFIX}
    Generator:        ${CMAKE_GENERATOR} using ${CMAKE_MAKE_PROGRAM}")
+if(CMAKE_CROSSCOMPILING)
+  message(STATUS "Cross compiling on ${CMAKE_HOST_SYSTEM}")
+endif()
 ###############################################################################
 # Print package summary
 ###############################################################################
@@ -943,11 +960,9 @@ if(_index GREATER -1)
 endif()
 message(STATUS "<<< Linker flags: >>>")
 message(STATUS "Executable name:  ${LAMMPS_BINARY}")
-if(CMAKE_VERSION VERSION_GREATER_EQUAL 3.13)
-  get_target_property(OPTIONS lammps LINK_OPTIONS)
-  if(OPTIONS)
-    message(STATUS "Linker options:   ${OPTIONS}")
-  endif()
+get_target_property(OPTIONS lammps LINK_OPTIONS)
+if(OPTIONS)
+  message(STATUS "Linker options:   ${OPTIONS}")
 endif()
 if(CMAKE_EXE_LINKER_FLAGS)
   message(STATUS "Executable linker flags: ${CMAKE_EXE_LINKER_FLAGS}")
@@ -989,34 +1004,37 @@ if(PKG_KOKKOS)
   endif()
 endif()
 if(PKG_KSPACE)
-  message(STATUS "<<< FFT settings >>>
+  if (FFT_USE_HEFFTE)
+    message(STATUS "<<< FFT settings >>>
+-- Primary FFT lib:  heFFTe")
+    if (FFT_HEFFTE_BACKEND)
+      message(STATUS "heFFTe backend:  ${FFT_HEFFTE_BACKEND}")
+    else()
+      message(STATUS "heFFTe backend:  stock (builtin FFT implementation, tested for corrected but not optimized for production)")
+    endif()
+    message(STATUS "Using distributed FFT algorithms from heFTTe")
+    if(FFT_SINGLE)
+      message(STATUS "Using single precision FFTs")
+    else()
+      message(STATUS "Using double precision FFTs")
+    endif()
+  else()
+    message(STATUS "<<< FFT settings >>>
 -- Primary FFT lib:  ${FFT}")
-  if(FFT_SINGLE)
-    message(STATUS "Using single precision FFTs")
-  else()
-    message(STATUS "Using double precision FFTs")
-  endif()
-  if(FFT_FFTW_THREADS OR FFT_MKL_THREADS)
-    message(STATUS "Using threaded FFTs")
-  else()
-    message(STATUS "Using non-threaded FFTs")
+    if(FFT_SINGLE)
+      message(STATUS "Using single precision FFTs")
+    else()
+      message(STATUS "Using double precision FFTs")
+    endif()
+    if(FFT_FFTW_THREADS OR FFT_MKL_THREADS)
+      message(STATUS "Using threaded FFTs")
+    else()
+      message(STATUS "Using non-threaded FFTs")
+    endif()
+    message(STATUS "Using builtin distributed FFT algorithms")
   endif()
   if(PKG_KOKKOS)
-    if(Kokkos_ENABLE_CUDA)
-      if(FFT STREQUAL "KISS")
-        message(STATUS "Kokkos FFT: KISS")
-      else()
-        message(STATUS "Kokkos FFT: cuFFT")
-      endif()
-    elseif(Kokkos_ENABLE_HIP)
-      if(FFT STREQUAL "KISS")
-        message(STATUS "Kokkos FFT: KISS")
-      else()
-        message(STATUS "Kokkos FFT: hipFFT")
-      endif()
-    else()
-      message(STATUS "Kokkos FFT: ${FFT}")
-    endif()
+    message(STATUS "Kokkos FFT: ${FFT_KOKKOS}")
   endif()
 endif()
 if(BUILD_DOC)
@@ -1028,6 +1046,14 @@ endif()
 if(BUILD_LAMMPS_SHELL)
   message(STATUS "<<< Building LAMMPS Shell >>>")
 endif()
+if(BUILD_LAMMPS_GUI)
+  message(STATUS "<<< Building LAMMPS GUI >>>")
+  if(LAMMPS_GUI_USE_PLUGIN)
+    message(STATUS "Loading LAMMPS library as plugin at run time")
+  else()
+    message(STATUS "Linking LAMMPS library at compile time")
+  endif()
+endif()
 if(ENABLE_TESTING)
   message(STATUS "<<< Building Unit Tests >>>")
   if(ENABLE_COVERAGE)

cmake/Modules/CodingStandard.cmake

@@ -1,19 +1,11 @@
-if(CMAKE_VERSION VERSION_LESS 3.12)
-    find_package(PythonInterp 3.5 QUIET) # Deprecated since version 3.12
-    if(PYTHONINTERP_FOUND)
-        set(Python3_EXECUTABLE ${PYTHON_EXECUTABLE})
-        set(Python3_VERSION ${PYTHON_VERSION_STRING})
-    endif()
-else()
-    # use default (or custom) Python executable, if version is sufficient
-    if(Python_VERSION VERSION_GREATER_EQUAL 3.5)
-      set(Python3_EXECUTABLE ${Python_EXECUTABLE})
-    endif()
-    find_package(Python3 COMPONENTS Interpreter QUIET)
+# use default (or custom) Python executable, if version is sufficient
+if(Python_VERSION VERSION_GREATER_EQUAL 3.6)
+  set(Python3_EXECUTABLE ${Python_EXECUTABLE})
 endif()
+find_package(Python3 COMPONENTS Interpreter)
 
 if(Python3_EXECUTABLE)
-    if(Python3_VERSION VERSION_GREATER_EQUAL 3.5)
+    if(Python3_VERSION VERSION_GREATER_EQUAL 3.6)
         add_custom_target(
           check-whitespace
           ${Python3_EXECUTABLE} ${LAMMPS_TOOLS_DIR}/coding_standard/whitespace.py .

cmake/Modules/DetectHIPInstallation.cmake

@@ -1,11 +1,3 @@
-if(NOT DEFINED HIP_PATH)
-    if(NOT DEFINED ENV{HIP_PATH})
-        message(FATAL_ERROR "HIP support requires HIP_PATH to be defined.\n"
-        "Either pass the HIP_PATH as a CMake option via -DHIP_PATH=... or set the HIP_PATH environment variable.")
-    else()
-        set(HIP_PATH $ENV{HIP_PATH} CACHE PATH "Path to HIP installation")
-    endif()
-endif()
 if(NOT DEFINED ROCM_PATH)
     if(NOT DEFINED ENV{ROCM_PATH})
         set(ROCM_PATH "/opt/rocm" CACHE PATH "Path to ROCm installation")
@@ -13,4 +5,4 @@ if(NOT DEFINED ROCM_PATH)
         set(ROCM_PATH $ENV{ROCM_PATH} CACHE PATH "Path to ROCm installation")
     endif()
 endif()
-list(APPEND CMAKE_PREFIX_PATH ${HIP_PATH} ${ROCM_PATH})
+list(APPEND CMAKE_PREFIX_PATH ${ROCM_PATH})

cmake/Modules/Documentation.cmake

@@ -5,24 +5,18 @@ option(BUILD_DOC "Build LAMMPS HTML documentation" OFF)
 
 if(BUILD_DOC)
   # Current Sphinx versions require at least Python 3.8
-  if(CMAKE_VERSION VERSION_LESS 3.12)
-    find_package(PythonInterp 3.8 REQUIRED)
-    set(VIRTUALENV ${PYTHON_EXECUTABLE} -m venv)
-  else()
-    # use default (or custom) Python executable, if version is sufficient
-    if(Python_VERSION VERSION_GREATER_EQUAL 3.8)
-      set(Python3_EXECUTABLE ${Python_EXECUTABLE})
-    endif()
-    find_package(Python3 REQUIRED COMPONENTS Interpreter)
-    if(Python3_VERSION VERSION_LESS 3.8)
-      message(FATAL_ERROR "Python 3.8 and up is required to build the HTML documentation")
-    endif()
-    set(VIRTUALENV ${Python3_EXECUTABLE} -m venv)
+  # use default (or custom) Python executable, if version is sufficient
+  if(Python_VERSION VERSION_GREATER_EQUAL 3.8)
+    set(Python3_EXECUTABLE ${Python_EXECUTABLE})
   endif()
+  find_package(Python3 REQUIRED COMPONENTS Interpreter)
+  if(Python3_VERSION VERSION_LESS 3.8)
+    message(FATAL_ERROR "Python 3.8 and up is required to build the HTML documentation")
+  endif()
+  set(VIRTUALENV ${Python3_EXECUTABLE} -m venv)
+
   find_package(Doxygen 1.8.10 REQUIRED)
-
-  file(GLOB DOC_SOURCES ${CONFIGURE_DEPENDS} ${LAMMPS_DOC_DIR}/src/[^.]*.rst)
-
+  file(GLOB DOC_SOURCES CONFIGURE_DEPENDS ${LAMMPS_DOC_DIR}/src/[^.]*.rst)
 
   add_custom_command(
     OUTPUT docenv
@@ -80,7 +74,7 @@ if(BUILD_DOC)
       message(STATUS "Using already downloaded archive ${CMAKE_BINARY_DIR}/libpace.tar.gz")
     endif()
     execute_process(COMMAND ${CMAKE_COMMAND} -E tar xzf mathjax.tar.gz WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR})
-    file(GLOB MATHJAX_VERSION_DIR ${CONFIGURE_DEPENDS} ${CMAKE_CURRENT_BINARY_DIR}/MathJax-*)
+    file(GLOB MATHJAX_VERSION_DIR CONFIGURE_DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/MathJax-*)
     execute_process(COMMAND ${CMAKE_COMMAND} -E rename ${MATHJAX_VERSION_DIR} ${DOC_BUILD_STATIC_DIR}/mathjax)
   endif()
 

cmake/Modules/ExternalCMakeProject.cmake

@@ -43,5 +43,5 @@ function(ExternalCMakeProject target url hash basedir cmakedir cmakefile)
       "${CMAKE_BINARY_DIR}/_deps/${target}-src/${cmakedir}/CMakeLists.txt")
   endif()
   add_subdirectory("${CMAKE_BINARY_DIR}/_deps/${target}-src/${cmakedir}"
-    "${CMAKE_BINARY_DIR}/_deps/${target}-build")
+    "${CMAKE_BINARY_DIR}/_deps/${target}-build" EXCLUDE_FROM_ALL)
 endfunction(ExternalCMakeProject)

cmake/Modules/FindClangFormat.cmake

@@ -1,5 +1,7 @@
 # Find clang-format
 find_program(ClangFormat_EXECUTABLE NAMES clang-format
+                                          clang-format-17.0
+                                          clang-format-16.0
                                           clang-format-15.0
                                           clang-format-14.0
                                           clang-format-13.0
@@ -19,7 +21,7 @@ if(ClangFormat_EXECUTABLE)
                   OUTPUT_VARIABLE clang_format_version
                   ERROR_QUIET OUTPUT_STRIP_TRAILING_WHITESPACE)
 
-  if(clang_format_version MATCHES "^(Ubuntu |)clang-format version .*")
+  if(clang_format_version MATCHES "^(Ubuntu |Debian |)clang-format version .*")
     # Arch Linux output:
     # clang-format version 10.0.0
     #
@@ -32,9 +34,15 @@ if(ClangFormat_EXECUTABLE)
     # Ubuntu 22.04 LTS output:
     # Ubuntu clang-format version 14.0.0-1ubuntu1
     #
+    # Debian 11 output:
+    # Debian clang-format version 11.0.1-2
+    #
+    # Debian 12 output:
+    # Debian clang-format version 14.0.6
+    #
     # Fedora 36 output:
     # clang-format version 14.0.5 (Fedora 14.0.5-1.fc36)
-    string(REGEX REPLACE "^(Ubuntu |)clang-format version ([0-9.]+).*"
+    string(REGEX REPLACE "^(Ubuntu |Debian |)clang-format version ([0-9.]+).*"
                          "\\2"
                          ClangFormat_VERSION
                          "${clang_format_version}")

cmake/Modules/FindCythonize.cmake

@@ -7,15 +7,7 @@
 # adapted from https://github.com/cmarshall108/cython-cmake-example/blob/master/cmake/FindCython.cmake
 #=============================================================================
 
-if(CMAKE_VERSION VERSION_LESS 3.12)
-    set(Python_ADDITIONAL_VERSIONS 3.12 3.11 3.10 3.9 3.8 3.7 3.6)
-    find_package(PythonInterp 3.6 QUIET) # Deprecated since version 3.12
-    if(PYTHONINTERP_FOUND)
-        set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
-    endif()
-else()
-    find_package(Python 3.6 COMPONENTS Interpreter QUIET)
-endif()
+find_package(Python 3.6 COMPONENTS Interpreter QUIET)
 
 # Use the Cython executable that lives next to the Python executable
 # if it is a local installation.

cmake/Modules/LAMMPSInterfacePlugin.cmake

@@ -28,9 +28,8 @@ if(MSVC)
     add_compile_options(/Zc:__cplusplus)
     add_compile_options(/wd4244)
     add_compile_options(/wd4267)
-    if(LAMMPS_EXCEPTIONS)
-      add_compile_options(/EHsc)
-    endif()
+    add_compile_options(/wd4250)
+    add_compile_options(/EHsc)
   endif()
   add_compile_definitions(_CRT_SECURE_NO_WARNINGS)
 endif()
@@ -65,7 +64,7 @@ endfunction(validate_option)
 
 # helper function for getting the most recently modified file or folder from a glob pattern
 function(get_newest_file path variable)
-  file(GLOB _dirs ${CONFIGURE_DEPENDS} ${path})
+  file(GLOB _dirs CONFIGURE_DEPENDS ${path})
   set(_besttime 2000-01-01T00:00:00)
   set(_bestfile "<unknown>")
   foreach(_dir ${_dirs})

cmake/Modules/LAMMPSUtils.cmake

@@ -41,7 +41,7 @@ endfunction()
 
 # helper function for getting the most recently modified file or folder from a glob pattern
 function(get_newest_file path variable)
-  file(GLOB _dirs ${CONFIGURE_DEPENDS} ${path})
+  file(GLOB _dirs CONFIGURE_DEPENDS ${path})
   set(_besttime 2000-01-01T00:00:00)
   set(_bestfile "<unknown>")
   foreach(_dir ${_dirs})
@@ -80,20 +80,20 @@ endfunction()
 
 function(check_for_autogen_files source_dir)
     message(STATUS "Running check for auto-generated files from make-based build system")
-    file(GLOB SRC_AUTOGEN_FILES ${CONFIGURE_DEPENDS} ${source_dir}/style_*.h)
-    file(GLOB SRC_AUTOGEN_PACKAGES ${CONFIGURE_DEPENDS} ${source_dir}/packages_*.h)
+    file(GLOB SRC_AUTOGEN_FILES CONFIGURE_DEPENDS ${source_dir}/style_*.h)
+    file(GLOB SRC_AUTOGEN_PACKAGES CONFIGURE_DEPENDS ${source_dir}/packages_*.h)
     list(APPEND SRC_AUTOGEN_FILES ${SRC_AUTOGEN_PACKAGES} ${source_dir}/lmpinstalledpkgs.h ${source_dir}/lmpgitversion.h)
-    list(APPEND SRC_AUTOGEN_FILES ${SRC_AUTOGEN_PACKAGES} ${source_dir}/mliap_model_python_couple.h ${source_dir}/mliap_model_python_couple.cpp)
+    list(APPEND SRC_AUTOGEN_FILES ${source_dir}/mliap_model_python_couple.h ${source_dir}/mliap_model_python_couple.cpp)
     foreach(_SRC ${SRC_AUTOGEN_FILES})
       get_filename_component(FILENAME "${_SRC}" NAME)
       if(EXISTS ${source_dir}/${FILENAME})
         message(FATAL_ERROR "\n########################################################################\n"
-                              "Found header file(s) generated by the make-based build system\n"
-                              "\n"
-                              "Please run\n"
-                              "make -C ${source_dir} purge\n"
-                              "to remove\n"
-                              "########################################################################")
+                            "Found header file ${source_dir}/${FILENAME} generated by the make-based build system\n"
+                            "\n"
+                            "Please run\n"
+                            "make -C ${source_dir} purge\n"
+                            "to remove\n"
+                            "########################################################################")
       endif()
     endforeach()
 endfunction()

cmake/Modules/OpenCLLoader.cmake

@@ -1,6 +1,6 @@
 message(STATUS "Downloading and building OpenCL loader library")
-set(OPENCL_LOADER_URL "${LAMMPS_THIRDPARTY_URL}/opencl-loader-2022.01.04.tar.gz" CACHE STRING "URL for OpenCL loader tarball")
-set(OPENCL_LOADER_MD5 "8d3a801e87a2c6653bf0e27707063914" CACHE STRING "MD5 checksum of OpenCL loader tarball")
+set(OPENCL_LOADER_URL "${LAMMPS_THIRDPARTY_URL}/opencl-loader-2024.02.09.tar.gz" CACHE STRING "URL for OpenCL loader tarball")
+set(OPENCL_LOADER_MD5 "f3573cf9daa3558ba46fd5866517f38f" CACHE STRING "MD5 checksum of OpenCL loader tarball")
 mark_as_advanced(OPENCL_LOADER_URL)
 mark_as_advanced(OPENCL_LOADER_MD5)
 
@@ -8,4 +8,3 @@ set(INSTALL_LIBOPENCL OFF CACHE BOOL "" FORCE)
 include(ExternalCMakeProject)
 ExternalCMakeProject(opencl_loader ${OPENCL_LOADER_URL} ${OPENCL_LOADER_MD5} opencl-loader . "")
 
-add_library(OpenCL::OpenCL ALIAS OpenCL)

cmake/Modules/Packages/COLVARS.cmake

@@ -1,6 +1,6 @@
 set(COLVARS_SOURCE_DIR ${LAMMPS_LIB_SOURCE_DIR}/colvars)
 
-file(GLOB COLVARS_SOURCES ${CONFIGURE_DEPENDS} ${COLVARS_SOURCE_DIR}/[^.]*.cpp)
+file(GLOB COLVARS_SOURCES CONFIGURE_DEPENDS ${COLVARS_SOURCE_DIR}/[^.]*.cpp)
 
 option(COLVARS_DEBUG "Enable debugging messages for Colvars (quite verbose)" OFF)
 

cmake/Modules/Packages/GPU.cmake

@@ -1,3 +1,10 @@
+
+# Silence CMake warnings about FindCUDA being obsolete.
+# We may need to eventually rewrite this section to use enable_language(CUDA)
+if(POLICY CMP0146)
+  cmake_policy(SET CMP0146 OLD)
+endif()
+
 set(GPU_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/GPU)
 set(GPU_SOURCES ${GPU_SOURCES_DIR}/gpu_extra.h
                 ${GPU_SOURCES_DIR}/fix_gpu.h
@@ -39,7 +46,7 @@ if (PKG_AMOEBA)
               ${GPU_SOURCES_DIR}/amoeba_convolution_gpu.cpp)
 endif()
 
-file(GLOB GPU_LIB_SOURCES ${CONFIGURE_DEPENDS} ${LAMMPS_LIB_SOURCE_DIR}/gpu/[^.]*.cpp)
+file(GLOB GPU_LIB_SOURCES CONFIGURE_DEPENDS ${LAMMPS_LIB_SOURCE_DIR}/gpu/[^.]*.cpp)
 file(MAKE_DIRECTORY ${LAMMPS_LIB_BINARY_DIR}/gpu)
 
 if(GPU_API STREQUAL "CUDA")
@@ -70,7 +77,7 @@ if(GPU_API STREQUAL "CUDA")
   set(GPU_ARCH "sm_50" CACHE STRING "LAMMPS GPU CUDA SM primary architecture (e.g. sm_60)")
 
   # ensure that no *cubin.h files exist from a compile in the lib/gpu folder
-  file(GLOB GPU_LIB_OLD_CUBIN_HEADERS ${CONFIGURE_DEPENDS} ${LAMMPS_LIB_SOURCE_DIR}/gpu/*_cubin.h)
+  file(GLOB GPU_LIB_OLD_CUBIN_HEADERS CONFIGURE_DEPENDS ${LAMMPS_LIB_SOURCE_DIR}/gpu/*_cubin.h)
   if(GPU_LIB_OLD_CUBIN_HEADERS)
     message(FATAL_ERROR "########################################################################\n"
       "Found file(s) generated by the make-based build system in lib/gpu\n"
@@ -80,15 +87,15 @@ if(GPU_API STREQUAL "CUDA")
       "########################################################################")
   endif()
 
-  file(GLOB GPU_LIB_CU ${CONFIGURE_DEPENDS} ${LAMMPS_LIB_SOURCE_DIR}/gpu/[^.]*.cu ${CMAKE_CURRENT_SOURCE_DIR}/gpu/[^.]*.cu)
+  file(GLOB GPU_LIB_CU CONFIGURE_DEPENDS ${LAMMPS_LIB_SOURCE_DIR}/gpu/[^.]*.cu ${CMAKE_CURRENT_SOURCE_DIR}/gpu/[^.]*.cu)
   list(REMOVE_ITEM GPU_LIB_CU ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_pppm.cu)
 
   cuda_include_directories(${LAMMPS_LIB_SOURCE_DIR}/gpu ${LAMMPS_LIB_BINARY_DIR}/gpu)
 
   if(CUDPP_OPT)
     cuda_include_directories(${LAMMPS_LIB_SOURCE_DIR}/gpu/cudpp_mini)
-    file(GLOB GPU_LIB_CUDPP_SOURCES ${CONFIGURE_DEPENDS} ${LAMMPS_LIB_SOURCE_DIR}/gpu/cudpp_mini/[^.]*.cpp)
-    file(GLOB GPU_LIB_CUDPP_CU ${CONFIGURE_DEPENDS} ${LAMMPS_LIB_SOURCE_DIR}/gpu/cudpp_mini/[^.]*.cu)
+    file(GLOB GPU_LIB_CUDPP_SOURCES CONFIGURE_DEPENDS ${LAMMPS_LIB_SOURCE_DIR}/gpu/cudpp_mini/[^.]*.cpp)
+    file(GLOB GPU_LIB_CUDPP_CU CONFIGURE_DEPENDS ${LAMMPS_LIB_SOURCE_DIR}/gpu/cudpp_mini/[^.]*.cu)
   endif()
 
   # build arch/gencode commands for nvcc based on CUDA toolkit version and use choice
@@ -151,10 +158,10 @@ if(GPU_API STREQUAL "CUDA")
   endif()
 
   cuda_compile_fatbin(GPU_GEN_OBJS ${GPU_LIB_CU} OPTIONS ${CUDA_REQUEST_PIC}
-          -DUNIX -O3 --use_fast_math -Wno-deprecated-gpu-targets -DNV_KERNEL -DUCL_CUDADR ${GPU_CUDA_GENCODE} -D_${GPU_PREC_SETTING} -DLAMMPS_${LAMMPS_SIZES})
+          -DUNIX -O3 --use_fast_math -Wno-deprecated-gpu-targets -allow-unsupported-compiler -DNV_KERNEL -DUCL_CUDADR ${GPU_CUDA_GENCODE} -D_${GPU_PREC_SETTING} -DLAMMPS_${LAMMPS_SIZES})
 
   cuda_compile(GPU_OBJS ${GPU_LIB_CUDPP_CU} OPTIONS ${CUDA_REQUEST_PIC}
-          -DUNIX -O3 --use_fast_math -Wno-deprecated-gpu-targets -DUCL_CUDADR ${GPU_CUDA_GENCODE} -D_${GPU_PREC_SETTING} -DLAMMPS_${LAMMPS_SIZES})
+          -DUNIX -O3 --use_fast_math -Wno-deprecated-gpu-targets -allow-unsupported-compiler -DUCL_CUDADR ${GPU_CUDA_GENCODE} -D_${GPU_PREC_SETTING} -DLAMMPS_${LAMMPS_SIZES})
 
   foreach(CU_OBJ ${GPU_GEN_OBJS})
     get_filename_component(CU_NAME ${CU_OBJ} NAME_WE)
@@ -205,7 +212,7 @@ elseif(GPU_API STREQUAL "OPENCL")
   include(OpenCLUtils)
   set(OCL_COMMON_HEADERS ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_preprocessor.h ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_aux_fun1.h)
 
-  file(GLOB GPU_LIB_CU ${CONFIGURE_DEPENDS} ${LAMMPS_LIB_SOURCE_DIR}/gpu/[^.]*.cu)
+  file(GLOB GPU_LIB_CU CONFIGURE_DEPENDS ${LAMMPS_LIB_SOURCE_DIR}/gpu/[^.]*.cu)
   list(REMOVE_ITEM GPU_LIB_CU
     ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_gayberne.cu
     ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_gayberne_lj.cu
@@ -335,7 +342,7 @@ elseif(GPU_API STREQUAL "HIP")
     endif()
   endif()
 
-  file(GLOB GPU_LIB_CU ${CONFIGURE_DEPENDS} ${LAMMPS_LIB_SOURCE_DIR}/gpu/[^.]*.cu ${CMAKE_CURRENT_SOURCE_DIR}/gpu/[^.]*.cu)
+  file(GLOB GPU_LIB_CU CONFIGURE_DEPENDS ${LAMMPS_LIB_SOURCE_DIR}/gpu/[^.]*.cu ${CMAKE_CURRENT_SOURCE_DIR}/gpu/[^.]*.cu)
   list(REMOVE_ITEM GPU_LIB_CU ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_pppm.cu)
 
   set(GPU_LIB_CU_HIP "")

cmake/Modules/Packages/INTEL.cmake

@@ -111,6 +111,9 @@ if(PKG_KSPACE)
   list(APPEND INTEL_SOURCES ${INTEL_SOURCES_DIR}/verlet_lrt_intel.cpp)
   RegisterIntegrateStyle(${INTEL_SOURCES_DIR}/verlet_lrt_intel.h)
 endif()
+if(PKG_ML-SNAP)
+  list(APPEND INTEL_SOURCES ${INTEL_SOURCES_DIR}/sna_intel.cpp)
+endif()
 
 target_sources(lammps PRIVATE ${INTEL_SOURCES})
 target_include_directories(lammps PRIVATE ${INTEL_SOURCES_DIR})

cmake/Modules/Packages/KIM.cmake

@@ -1,12 +1,7 @@
 set(KIM-API_MIN_VERSION 2.1.3)
 find_package(CURL)
 if(CURL_FOUND)
-  if(CMAKE_VERSION VERSION_LESS 3.12)
-    target_include_directories(lammps PRIVATE ${CURL_INCLUDE_DIRS})
-    target_link_libraries(lammps PRIVATE ${CURL_LIBRARIES})
-  else()
-    target_link_libraries(lammps PRIVATE CURL::libcurl)
-  endif()
+  target_link_libraries(lammps PRIVATE CURL::libcurl)
   target_compile_definitions(lammps PRIVATE -DLMP_KIM_CURL)
   set(LMP_DEBUG_CURL OFF CACHE STRING "Set libcurl verbose mode on/off. If on, it displays a lot of verbose information about its operations.")
   mark_as_advanced(LMP_DEBUG_CURL)

cmake/Modules/Packages/KOKKOS.cmake

@@ -1,7 +1,8 @@
 ########################################################################
-# As of version 3.3.0 Kokkos requires C++14
-if(CMAKE_CXX_STANDARD LESS 14)
-  message(FATAL_ERROR "The KOKKOS package requires the C++ standard to be set to at least C++14")
+# As of version 4.0.0 Kokkos requires C++17
+if(CMAKE_CXX_STANDARD LESS 17)
+  message(FATAL_ERROR "The KOKKOS package requires the C++ standard to
+be set to at least C++17")
 endif()
 
 ########################################################################
@@ -15,11 +16,6 @@ endif()
 if(Kokkos_ENABLE_OPENMP)
   if(NOT BUILD_OMP)
     message(FATAL_ERROR "Must enable BUILD_OMP with Kokkos_ENABLE_OPENMP")
-  else()
-    # NVHPC/(AMD)Clang does not seem to provide a detectable OpenMP version, but is far beyond version 3.1
-    if((OpenMP_CXX_VERSION VERSION_LESS 3.1) AND NOT ((CMAKE_CXX_COMPILER_ID STREQUAL "NVHPC") OR (CMAKE_CXX_COMPILER_ID STREQUAL "Clang")))
-      message(FATAL_ERROR "Compiler must support OpenMP 3.1 or later with Kokkos_ENABLE_OPENMP")
-    endif()
   endif()
 endif()
 ########################################################################
@@ -49,8 +45,8 @@ if(DOWNLOAD_KOKKOS)
   list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_CXX_EXTENSIONS=${CMAKE_CXX_EXTENSIONS}")
   list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}")
   include(ExternalProject)
-  set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/3.7.02.tar.gz" CACHE STRING "URL for KOKKOS tarball")
-  set(KOKKOS_MD5 "34d7860d548c06a4040236d959c9f99a" CACHE STRING "MD5 checksum of KOKKOS tarball")
+  set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/4.3.00.tar.gz" CACHE STRING "URL for KOKKOS tarball")
+  set(KOKKOS_MD5 "889dcea2b5ced3debdc5b0820044bdc4" CACHE STRING "MD5 checksum of KOKKOS tarball")
   mark_as_advanced(KOKKOS_URL)
   mark_as_advanced(KOKKOS_MD5)
   GetFallbackURL(KOKKOS_URL KOKKOS_FALLBACK)
@@ -75,7 +71,7 @@ if(DOWNLOAD_KOKKOS)
   add_dependencies(LAMMPS::KOKKOSCORE kokkos_build)
   add_dependencies(LAMMPS::KOKKOSCONTAINERS kokkos_build)
 elseif(EXTERNAL_KOKKOS)
-  find_package(Kokkos 3.7.02 REQUIRED CONFIG)
+  find_package(Kokkos 4.3.00 REQUIRED CONFIG)
   target_link_libraries(lammps PRIVATE Kokkos::kokkos)
 else()
   set(LAMMPS_LIB_KOKKOS_SRC_DIR ${LAMMPS_LIB_SOURCE_DIR}/kokkos)
@@ -130,16 +126,33 @@ if(PKG_KSPACE)
   list(APPEND KOKKOS_PKG_SOURCES ${KOKKOS_PKG_SOURCES_DIR}/fft3d_kokkos.cpp
                                  ${KOKKOS_PKG_SOURCES_DIR}/grid3d_kokkos.cpp
                                  ${KOKKOS_PKG_SOURCES_DIR}/remap_kokkos.cpp)
+  set(FFT_KOKKOS "KISS" CACHE STRING "FFT library for Kokkos-enabled KSPACE package")
+  set(FFT_KOKKOS_VALUES KISS FFTW3 MKL HIPFFT CUFFT)
+  set_property(CACHE FFT_KOKKOS PROPERTY STRINGS ${FFT_KOKKOS_VALUES})
+  validate_option(FFT_KOKKOS FFT_KOKKOS_VALUES)
+  string(TOUPPER ${FFT_KOKKOS} FFT_KOKKOS)
+
   if(Kokkos_ENABLE_CUDA)
-    if(NOT (FFT STREQUAL "KISS"))
-      target_compile_definitions(lammps PRIVATE -DFFT_CUFFT)
-      target_link_libraries(lammps PRIVATE cufft)
+    if(NOT ((FFT_KOKKOS STREQUAL "KISS") OR (FFT_KOKKOS STREQUAL "CUFFT")))
+      message(FATAL_ERROR "The CUDA backend of Kokkos requires either KISS FFT or CUFFT.")
+    elseif(FFT_KOKKOS STREQUAL "KISS")
+      message(WARNING "Using KISS FFT with the CUDA backend of Kokkos may be sub-optimal.")
+      target_compile_definitions(lammps PRIVATE -DFFT_KOKKOS_KISS)
+    elseif(FFT_KOKKOS STREQUAL "CUFFT")
+      find_package(CUDAToolkit REQUIRED)
+      target_compile_definitions(lammps PRIVATE -DFFT_KOKKOS_CUFFT)
+      target_link_libraries(lammps PRIVATE CUDA::cufft)
     endif()
   elseif(Kokkos_ENABLE_HIP)
-    if(NOT (FFT STREQUAL "KISS"))
+    if(NOT ((FFT_KOKKOS STREQUAL "KISS") OR (FFT_KOKKOS STREQUAL "HIPFFT")))
+      message(FATAL_ERROR "The HIP backend of Kokkos requires either KISS FFT or HIPFFT.")
+    elseif(FFT_KOKKOS STREQUAL "KISS")
+      message(WARNING "Using KISS FFT with the HIP backend of Kokkos may be sub-optimal.")
+      target_compile_definitions(lammps PRIVATE -DFFT_KOKKOS_KISS)
+    elseif(FFT_KOKKOS STREQUAL "HIPFFT")
       include(DetectHIPInstallation)
       find_package(hipfft REQUIRED)
-      target_compile_definitions(lammps PRIVATE -DFFT_HIPFFT)
+      target_compile_definitions(lammps PRIVATE -DFFT_KOKKOS_HIPFFT)
       target_link_libraries(lammps PRIVATE hip::hipfft)
     endif()
   endif()
@@ -155,7 +168,7 @@ if(PKG_ML-IAP)
 
   # Add KOKKOS version of ML-IAP Python coupling if non-KOKKOS version is included
   if(MLIAP_ENABLE_PYTHON AND Cythonize_EXECUTABLE)
-    file(GLOB MLIAP_KOKKOS_CYTHON_SRC ${CONFIGURE_DEPENDS} ${LAMMPS_SOURCE_DIR}/KOKKOS/*.pyx)
+    file(GLOB MLIAP_KOKKOS_CYTHON_SRC CONFIGURE_DEPENDS ${LAMMPS_SOURCE_DIR}/KOKKOS/*.pyx)
     foreach(MLIAP_CYTHON_FILE ${MLIAP_KOKKOS_CYTHON_SRC})
       get_filename_component(MLIAP_CYTHON_BASE ${MLIAP_CYTHON_FILE} NAME_WE)
       add_custom_command(OUTPUT  ${MLIAP_BINARY_DIR}/${MLIAP_CYTHON_BASE}.cpp ${MLIAP_BINARY_DIR}/${MLIAP_CYTHON_BASE}.h

cmake/Modules/Packages/KSPACE.cmake

@@ -46,6 +46,61 @@ else()
   target_compile_definitions(lammps PRIVATE -DFFT_KISS)
 endif()
 
+option(FFT_USE_HEFFTE  "Use heFFTe as the distributed FFT engine, overrides the FFT option."  OFF)
+if(FFT_USE_HEFFTE)
+  # if FFT_HEFFTE is enabled, use the heFFTe parallel engine instead of the builtin fftMPI engine
+
+  # map standard FFT choices to available heFFTe backends: FFTW3 -> FFTW, KISS -> BUILTIN
+  set(FFT_HEFFTE_BACKEND_VALUES FFTW MKL BUILTIN)
+  string(REPLACE FFTW3 FFTW FFT_HEFFTE_BACKEND_DEFAULT ${FFT})
+  string(REPLACE KISS BUILTIN FFT_HEFFTE_BACKEND_DEFAULT ${FFT_HEFFTE_BACKEND_DEFAULT})
+  set(FFT_HEFFTE_BACKEND "${FFT_HEFFTE_BACKEND_DEFAULT}" CACHE STRING "Select heFFTe backend, e.g., FFTW or MKL")
+  set_property(CACHE FFT_HEFFTE_BACKEND PROPERTY STRINGS ${FFT_HEFFTE_BACKEND_VALUES})
+  validate_option(FFT_HEFFTE_BACKEND FFT_HEFFTE_BACKEND_VALUES)
+
+  if(FFT_HEFFTE_BACKEND STREQUAL "FFTW") # respect the backend choice, FFTW or MKL
+    set(HEFFTE_COMPONENTS "FFTW")
+    set(Heffte_ENABLE_FFTW "ON" CACHE BOOL "Enables FFTW backend for heFFTe")
+  elseif(FFT_HEFFTE_BACKEND STREQUAL "MKL")
+    set(HEFFTE_COMPONENTS "MKL")
+    set(Heffte_ENABLE_MKL "ON" CACHE BOOL "Enables MKL backend for heFFTe")
+  else()
+    set(HEFFTE_COMPONENTS "BUILTIN")
+    message(WARNING "FFT_HEFFTE_BACKEND not selected, defaulting to the builtin 'stock' backend, which is intended for testing and is not optimized for production runs")
+  endif()
+
+  find_package(Heffte 2.4.0 QUIET COMPONENTS ${HEFFTE_COMPONENTS})
+  if (NOT Heffte_FOUND) # download and build
+    if(BUILD_SHARED_LIBS)
+      set(BUILD_SHARED_LIBS_WAS_ON YES)
+      set(BUILD_SHARED_LIBS OFF)
+    endif()
+    if(CMAKE_REQUEST_PIC)
+      set(CMAKE_POSITION_INDEPENDENT_CODE ON)
+    endif()
+    set(Heffte_ENABLE_${FFT_HEFFTE_BACKEND} ON)
+    include(FetchContent)
+    FetchContent_Declare(HEFFTE_PROJECT # using v2.4.0
+      URL  "https://github.com/icl-utk-edu/heffte/archive/refs/tags/v2.4.0.tar.gz"
+      URL_HASH SHA256=02310fb4f9688df02f7181667e61c3adb7e38baf79611d80919d47452ff7881d
+      )
+    FetchContent_Populate(HEFFTE_PROJECT)
+
+    # fixup git hash to show "(unknown)" to avoid compilation failures.
+    file(READ ${heffte_project_SOURCE_DIR}/include/heffte_config.cmake.h HEFFTE_CFG_FILE_TEXT)
+    string(REPLACE "@Heffte_GIT_HASH@" "(unknown)" HEFFTE_CFG_FILE_TEXT "${HEFFTE_CFG_FILE_TEXT}")
+    file(WRITE ${heffte_project_SOURCE_DIR}/include/heffte_config.cmake.h "${HEFFTE_CFG_FILE_TEXT}")
+
+    add_subdirectory(${heffte_project_SOURCE_DIR} ${heffte_project_BINARY_DIR} EXCLUDE_FROM_ALL)
+    add_library(Heffte::Heffte ALIAS Heffte)
+    if(BUILD_SHARED_LIBS_WAS_ON)
+      set(BUILD_SHARED_LIBS ON)
+    endif()
+  endif()
+  target_compile_definitions(lammps PRIVATE -DFFT_HEFFTE "-DFFT_HEFFTE_${FFT_HEFFTE_BACKEND}")
+  target_link_libraries(lammps PRIVATE Heffte::Heffte)
+endif()
+
 set(FFT_PACK "array" CACHE STRING "Optimization for FFT")
 set(FFT_PACK_VALUES array pointer memcpy)
 set_property(CACHE FFT_PACK PROPERTY STRINGS ${FFT_PACK_VALUES})

cmake/Modules/Packages/LEPTON.cmake

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

cmake/Modules/Packages/MDI.cmake

@@ -8,8 +8,8 @@ option(DOWNLOAD_MDI "Download and compile the MDI library instead of using an al
 
 if(DOWNLOAD_MDI)
   message(STATUS "MDI download requested - we will build our own")
-  set(MDI_URL "https://github.com/MolSSI-MDI/MDI_Library/archive/v1.4.16.tar.gz" CACHE STRING "URL for MDI tarball")
-  set(MDI_MD5 "407db44e2d79447ab5c1233af1965f65" CACHE STRING "MD5 checksum for MDI tarball")
+  set(MDI_URL "https://github.com/MolSSI-MDI/MDI_Library/archive/v1.4.26.tar.gz" CACHE STRING "URL for MDI tarball")
+  set(MDI_MD5 "3124bb85259471e2a53a891f04bf697a" CACHE STRING "MD5 checksum for MDI tarball")
   mark_as_advanced(MDI_URL)
   mark_as_advanced(MDI_MD5)
   GetFallbackURL(MDI_URL MDI_FALLBACK)
@@ -26,29 +26,9 @@ if(DOWNLOAD_MDI)
 
   # detect if we have python development support and thus can enable python plugins
   set(MDI_USE_PYTHON_PLUGINS OFF)
-  if(CMAKE_VERSION VERSION_LESS 3.12)
-    if(NOT PYTHON_VERSION_STRING)
-      set(Python_ADDITIONAL_VERSIONS 3.12 3.11 3.10 3.9 3.8 3.7 3.6)
-      # search for interpreter first, so we have a consistent library
-      find_package(PythonInterp) # Deprecated since version 3.12
-      if(PYTHONINTERP_FOUND)
-        set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
-      endif()
-    endif()
-    # search for the library matching the selected interpreter
-    set(Python_ADDITIONAL_VERSIONS ${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR})
-    find_package(PythonLibs QUIET) # Deprecated since version 3.12
-    if(PYTHONLIBS_FOUND)
-      if(NOT (PYTHON_VERSION_STRING STREQUAL PYTHONLIBS_VERSION_STRING))
-        message(FATAL_ERROR "Python Library version ${PYTHONLIBS_VERSION_STRING} does not match Interpreter version ${PYTHON_VERSION_STRING}")
-      endif()
-      set(MDI_USE_PYTHON_PLUGINS ON)
-    endif()
-  else()
-    find_package(Python QUIET COMPONENTS Development)
-    if(Python_Development_FOUND)
-      set(MDI_USE_PYTHON_PLUGINS ON)
-    endif()
+  find_package(Python QUIET COMPONENTS Development)
+  if(Python_Development_FOUND)
+    set(MDI_USE_PYTHON_PLUGINS ON)
   endif()
   # python plugins are not supported and thus must be always off on Windows
   if(CMAKE_SYSTEM_NAME STREQUAL "Windows")
@@ -102,13 +82,9 @@ if(DOWNLOAD_MDI)
   # if compiling with python plugins we need
   # to add python libraries as dependency.
   if(MDI_USE_PYTHON_PLUGINS)
-    if(CMAKE_VERSION VERSION_LESS 3.12)
-      list(APPEND MDI_DEP_LIBS ${PYTHON_LIBRARIES})
-    else()
-      list(APPEND MDI_DEP_LIBS Python::Python)
-    endif()
-
+    list(APPEND MDI_DEP_LIBS Python::Python)
   endif()
+
   # need to add support for dlopen/dlsym, except when compiling for Windows.
   if(NOT (CMAKE_SYSTEM_NAME STREQUAL "Windows"))
     list(APPEND MDI_DEP_LIBS "${CMAKE_DL_LIBS}")

cmake/Modules/Packages/ML-IAP.cmake

@@ -2,12 +2,7 @@
 set(MLIAP_ENABLE_PYTHON_DEFAULT OFF)
 if(PKG_PYTHON)
   find_package(Cythonize QUIET)
-  if (CMAKE_VERSION VERSION_GREATER_EQUAL 3.14)
-    find_package(Python COMPONENTS NumPy QUIET)
-  else()
-    # assume we have NumPy
-    set(Python_NumPy_FOUND ON)
-  endif()
+  find_package(Python COMPONENTS NumPy QUIET)
   if(Cythonize_FOUND AND Python_NumPy_FOUND)
     set(MLIAP_ENABLE_PYTHON_DEFAULT ON)
   endif()
@@ -15,26 +10,26 @@ endif()
 
 option(MLIAP_ENABLE_PYTHON "Build ML-IAP package with Python support" ${MLIAP_ENABLE_PYTHON_DEFAULT})
 
+# if ML-PACE package *and* MLIAP with Python is enabled is included we may also include ML-PACE support in ML-IAP
+set(MLIAP_ENABLE_ACE_DEFAULT OFF)
+if(PKG_ML-PACE)
+  set(MLIAP_ENABLE_ACE_DEFAULT ON)
+endif()
+
+option(MLIAP_ENABLE_ACE "Build ML-IAP package with ACE support" ${MLIAP_ENABLE_ACE_DEFAULT})
+
 if(MLIAP_ENABLE_PYTHON)
   find_package(Cythonize REQUIRED)
-  if (CMAKE_VERSION VERSION_GREATER_EQUAL 3.14)
-    find_package(Python COMPONENTS NumPy REQUIRED)
-  endif()
+  find_package(Python COMPONENTS NumPy REQUIRED)
   if(NOT PKG_PYTHON)
     message(FATAL_ERROR "Must enable PYTHON package for including Python support in ML-IAP")
   endif()
-  if(CMAKE_VERSION VERSION_LESS 3.12)
-    if(PYTHONLIBS_VERSION_STRING VERSION_LESS 3.6)
-      message(FATAL_ERROR "Python support in ML-IAP requires Python 3.6 or later")
-    endif()
-  else()
-    if(Python_VERSION VERSION_LESS 3.6)
-      message(FATAL_ERROR "Python support in ML-IAP requires Python 3.6 or later")
-    endif()
+  if(Python_VERSION VERSION_LESS 3.6)
+    message(FATAL_ERROR "Python support in ML-IAP requires Python 3.6 or later")
   endif()
 
   set(MLIAP_BINARY_DIR ${CMAKE_BINARY_DIR}/cython)
-  file(GLOB MLIAP_CYTHON_SRC ${CONFIGURE_DEPENDS} ${LAMMPS_SOURCE_DIR}/ML-IAP/*.pyx)
+  file(GLOB MLIAP_CYTHON_SRC CONFIGURE_DEPENDS ${LAMMPS_SOURCE_DIR}/ML-IAP/*.pyx)
   file(MAKE_DIRECTORY ${MLIAP_BINARY_DIR})
   foreach(MLIAP_CYTHON_FILE ${MLIAP_CYTHON_SRC})
     get_filename_component(MLIAP_CYTHON_BASE ${MLIAP_CYTHON_FILE} NAME_WE)
@@ -49,3 +44,10 @@ if(MLIAP_ENABLE_PYTHON)
   target_compile_definitions(lammps PRIVATE -DMLIAP_PYTHON)
   target_include_directories(lammps PRIVATE ${MLIAP_BINARY_DIR})
 endif()
+
+if(MLIAP_ENABLE_ACE)
+  if(NOT PKG_ML-PACE)
+    message(FATAL_ERROR "Must enable ML-PACE package for including ACE support in ML-IAP")
+  endif()
+  target_compile_definitions(lammps PRIVATE -DMLIAP_ACE)
+endif()

cmake/Modules/Packages/ML-PACE.cmake

@@ -1,33 +1,40 @@
-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.11.25.fix.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 "b45de9a633f42ed65422567e3ce56f9f" CACHE STRING "MD5 checksum of PACE evaluator library tarball")
 mark_as_advanced(PACELIB_URL)
 mark_as_advanced(PACELIB_MD5)
 GetFallbackURL(PACELIB_URL PACELIB_FALLBACK)
 
-# download library sources to build folder
-if(EXISTS ${CMAKE_BINARY_DIR}/libpace.tar.gz)
-  file(MD5 ${CMAKE_BINARY_DIR}/libpace.tar.gz DL_MD5)
-endif()
-if(NOT "${DL_MD5}" STREQUAL "${PACELIB_MD5}")
-  message(STATUS "Downloading ${PACELIB_URL}")
-  file(DOWNLOAD ${PACELIB_URL} ${CMAKE_BINARY_DIR}/libpace.tar.gz STATUS DL_STATUS SHOW_PROGRESS)
-  file(MD5 ${CMAKE_BINARY_DIR}/libpace.tar.gz DL_MD5)
-  if((NOT DL_STATUS EQUAL 0) OR (NOT "${DL_MD5}" STREQUAL "${PACELIB_MD5}"))
-    message(WARNING "Download from primary URL ${PACELIB_URL} failed\nTrying fallback URL ${PACELIB_FALLBACK}")
-    file(DOWNLOAD ${PACELIB_FALLBACK} ${CMAKE_BINARY_DIR}/libpace.tar.gz EXPECTED_HASH MD5=${PACELIB_MD5} SHOW_PROGRESS)
-  endif()
+# LOCAL_ML-PACE points to top-level dir with local lammps-user-pace repo,
+# to make it easier to check local build without going through the public github releases
+if(LOCAL_ML-PACE)
+ set(lib-pace "${LOCAL_ML-PACE}")
 else()
-  message(STATUS "Using already downloaded archive ${CMAKE_BINARY_DIR}/libpace.tar.gz")
-endif()
+  # download library sources to build folder
+  if(EXISTS ${CMAKE_BINARY_DIR}/libpace.tar.gz)
+    file(MD5 ${CMAKE_BINARY_DIR}/libpace.tar.gz DL_MD5)
+  endif()
+  if(NOT "${DL_MD5}" STREQUAL "${PACELIB_MD5}")
+    message(STATUS "Downloading ${PACELIB_URL}")
+    file(DOWNLOAD ${PACELIB_URL} ${CMAKE_BINARY_DIR}/libpace.tar.gz STATUS DL_STATUS SHOW_PROGRESS)
+    file(MD5 ${CMAKE_BINARY_DIR}/libpace.tar.gz DL_MD5)
+    if((NOT DL_STATUS EQUAL 0) OR (NOT "${DL_MD5}" STREQUAL "${PACELIB_MD5}"))
+      message(WARNING "Download from primary URL ${PACELIB_URL} failed\nTrying fallback URL ${PACELIB_FALLBACK}")
+      file(DOWNLOAD ${PACELIB_FALLBACK} ${CMAKE_BINARY_DIR}/libpace.tar.gz EXPECTED_HASH MD5=${PACELIB_MD5} SHOW_PROGRESS)
+    endif()
+  else()
+    message(STATUS "Using already downloaded archive ${CMAKE_BINARY_DIR}/libpace.tar.gz")
+  endif()
 
-# uncompress downloaded sources
-execute_process(
-  COMMAND ${CMAKE_COMMAND} -E remove_directory lammps-user-pace*
-  COMMAND ${CMAKE_COMMAND} -E tar xzf libpace.tar.gz
-  WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
-)
-get_newest_file(${CMAKE_BINARY_DIR}/lammps-user-pace-* lib-pace)
+
+  # uncompress downloaded sources
+  execute_process(
+    COMMAND ${CMAKE_COMMAND} -E remove_directory lammps-user-pace*
+    COMMAND ${CMAKE_COMMAND} -E tar xzf libpace.tar.gz
+    WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
+  )
+  get_newest_file(${CMAKE_BINARY_DIR}/lammps-user-pace-* lib-pace)
+endif()
 
 add_subdirectory(${lib-pace} build-pace)
 set_target_properties(pace PROPERTIES CXX_EXTENSIONS ON OUTPUT_NAME lammps_pace${LAMMPS_MACHINE})

cmake/Modules/Packages/ML-QUIP.cmake

@@ -18,7 +18,9 @@ if(DOWNLOAD_QUIP)
     set(temp "${temp}F77FLAGS += -fpp -fixed -fPIC\n")
     set(temp "${temp}F95_PRE_FILENAME_FLAG = -Tf\n")
   elseif(CMAKE_Fortran_COMPILER_ID STREQUAL GNU)
-    set(temp "${temp}FPP=${CMAKE_Fortran_COMPILER} -E -x f95-cpp-input\nOPTIM=${CMAKE_Fortran_FLAGS_${BTYPE}}\n")
+    # quip library uses GNU fortran extensions. If any more restrictive standards are set, reset them
+    string(REGEX REPLACE -std=f[0-9]+ -std=gnu _fopt "${CMAKE_Fortran_FLAGS_${BTYPE}}")
+    set(temp "${temp}FPP=${CMAKE_Fortran_COMPILER} -E -x f95-cpp-input\nOPTIM=${_fopt} -fmax-stack-var-size=6553600\n")
     set(temp "${temp}DEFINES += -DGETARG_F2003 -DGETENV_F2003 -DGFORTRAN -DFORTRAN_UNDERSCORE\n")
     set(temp "${temp}F95FLAGS += -x f95-cpp-input -ffree-line-length-none -ffree-form -fno-second-underscore -fPIC\n")
     set(temp "${temp}F77FLAGS += -x f77-cpp-input -fno-second-underscore -fPIC\n")
@@ -56,7 +58,7 @@ if(DOWNLOAD_QUIP)
     GIT_SUBMODULES "src/fox;src/GAP"
     PATCH_COMMAND ${CMAKE_COMMAND} -E copy_if_different ${CMAKE_BINARY_DIR}/quip.config <SOURCE_DIR>/arch/Makefile.lammps
     CONFIGURE_COMMAND env QUIP_ARCH=lammps make config
-    BUILD_COMMAND env QUIP_ARCH=lammps make libquip
+    BUILD_COMMAND env QUIP_ARCH=lammps make -j1 libquip
     INSTALL_COMMAND ""
     BUILD_IN_SOURCE YES
     BUILD_BYPRODUCTS <SOURCE_DIR>/build/lammps/${CMAKE_STATIC_LIBRARY_PREFIX}quip${CMAKE_STATIC_LIBRARY_SUFFIX}

cmake/Modules/Packages/MSCG.cmake

@@ -1,28 +0,0 @@
-find_package(GSL REQUIRED)
-find_package(MSCG QUIET)
-if(MSGC_FOUND)
-  set(DOWNLOAD_MSCG_DEFAULT OFF)
-else()
-  set(DOWNLOAD_MSCG_DEFAULT ON)
-endif()
-option(DOWNLOAD_MSCG "Download MSCG library instead of using an already installed one)" ${DOWNLOAD_MSCG_DEFAULT})
-if(DOWNLOAD_MSCG)
-  set(MSCG_URL "https://github.com/uchicago-voth/MSCG-release/archive/491270a73539e3f6951e76f7dbe84e258b3ebb45.tar.gz" CACHE STRING "URL for MSCG tarball")
-  set(MSCG_MD5 "7ea50748fba5c3a372e0266bd31d2f11" CACHE STRING "MD5 checksum of MSCG tarball")
-  mark_as_advanced(MSCG_URL)
-  mark_as_advanced(MSCG_MD5)
-
-  include(ExternalCMakeProject)
-  ExternalCMakeProject(mscg ${MSCG_URL} ${MSCG_MD5} MSCG-release src/CMake "")
-
-  # set include and link library
-  target_include_directories(lammps PRIVATE "${CMAKE_BINARY_DIR}/_deps/mscg-src/src")
-  target_link_libraries(lammps PRIVATE mscg)
-else()
-  find_package(MSCG)
-  if(NOT MSCG_FOUND)
-    message(FATAL_ERROR "MSCG not found, help CMake to find it by setting MSCG_LIBRARY and MSCG_INCLUDE_DIR, or set DOWNLOAD_MSCG=ON to download it")
-  endif()
-  target_link_libraries(lammps PRIVATE MSCG::MSCG)
-endif()
-target_link_libraries(lammps PRIVATE GSL::gsl ${LAPACK_LIBRARIES})

cmake/Modules/Packages/PLUMED.cmake

@@ -21,9 +21,9 @@ else()
   set(PLUMED_CONFIG_OMP "--disable-openmp")
 endif()
 
-set(PLUMED_URL "https://github.com/plumed/plumed2/releases/download/v2.8.2/plumed-src-2.8.2.tgz"
+set(PLUMED_URL "https://github.com/plumed/plumed2/releases/download/v2.8.3/plumed-src-2.8.3.tgz"
   CACHE STRING "URL for PLUMED tarball")
-set(PLUMED_MD5 "599092b6a0aa6fff992612537ad98994" CACHE STRING "MD5 checksum of PLUMED tarball")
+set(PLUMED_MD5 "76d23cd394eba9e6530316ed1184e219" CACHE STRING "MD5 checksum of PLUMED tarball")
 
 mark_as_advanced(PLUMED_URL)
 mark_as_advanced(PLUMED_MD5)

cmake/Modules/Packages/PYTHON.cmake

@@ -1,29 +1,11 @@
-if(CMAKE_VERSION VERSION_LESS 3.12)
-  if(NOT PYTHON_VERSION_STRING)
-    set(Python_ADDITIONAL_VERSIONS 3.12 3.11 3.10 3.9 3.8 3.7 3.6)
-    # search for interpreter first, so we have a consistent library
-    find_package(PythonInterp) # Deprecated since version 3.12
-    if(PYTHONINTERP_FOUND)
-      set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
-    endif()
+
+if(NOT Python_INTERPRETER)
+  # backward compatibility with CMake before 3.12 and older LAMMPS documentation
+  if(PYTHON_EXECUTABLE)
+    set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
   endif()
-  # search for the library matching the selected interpreter
-  set(Python_ADDITIONAL_VERSIONS ${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR})
-  find_package(PythonLibs REQUIRED) # Deprecated since version 3.12
-  if(NOT (PYTHON_VERSION_STRING STREQUAL PYTHONLIBS_VERSION_STRING))
-    message(FATAL_ERROR "Python Library version ${PYTHONLIBS_VERSION_STRING} does not match Interpreter version ${PYTHON_VERSION_STRING}")
-  endif()
-  target_include_directories(lammps PRIVATE ${PYTHON_INCLUDE_DIRS})
-  target_link_libraries(lammps PRIVATE ${PYTHON_LIBRARIES})
-else()
-  if(NOT Python_INTERPRETER)
-    # backward compatibility
-    if(PYTHON_EXECUTABLE)
-      set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
-    endif()
-    find_package(Python COMPONENTS Interpreter)
-  endif()
-  find_package(Python REQUIRED COMPONENTS Interpreter Development)
-  target_link_libraries(lammps PRIVATE Python::Python)
+  find_package(Python COMPONENTS Interpreter)
 endif()
+find_package(Python REQUIRED COMPONENTS Interpreter Development)
+target_link_libraries(lammps PRIVATE Python::Python)
 target_compile_definitions(lammps PRIVATE -DLMP_PYTHON)

cmake/Modules/StyleHeaderUtils.cmake

@@ -1,5 +1,5 @@
 function(FindStyleHeaders path style_class file_pattern headers)
-    file(GLOB files ${CONFIGURE_DEPENDS} "${path}/${file_pattern}*.h")
+    file(GLOB files CONFIGURE_DEPENDS "${path}/${file_pattern}*.h")
     get_property(hlist GLOBAL PROPERTY ${headers})
 
     foreach(file_name ${files})
@@ -187,7 +187,7 @@ endfunction(DetectBuildSystemConflict)
 
 
 function(FindPackagesHeaders path style_class file_pattern headers)
-    file(GLOB files ${CONFIGURE_DEPENDS} "${path}/${file_pattern}*.h")
+    file(GLOB files CONFIGURE_DEPENDS "${path}/${file_pattern}*.h")
     get_property(plist GLOBAL PROPERTY ${headers})
 
     foreach(file_name ${files})

cmake/Modules/Testing.cmake

@@ -6,7 +6,7 @@ if(ENABLE_TESTING)
   find_program(VALGRIND_BINARY NAMES valgrind)
   # generate custom suppression file
   file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/lammps.supp "\n")
-  file(GLOB VALGRIND_SUPPRESSION_FILES ${CONFIGURE_DEPENDS} ${LAMMPS_TOOLS_DIR}/valgrind/[^.]*.supp)
+  file(GLOB VALGRIND_SUPPRESSION_FILES CONFIGURE_DEPENDS ${LAMMPS_TOOLS_DIR}/valgrind/[^.]*.supp)
   foreach(SUPP ${VALGRIND_SUPPRESSION_FILES})
     file(READ ${SUPP} SUPPRESSIONS)
     file(APPEND ${CMAKE_CURRENT_BINARY_DIR}/lammps.supp "${SUPPRESSIONS}")
@@ -19,7 +19,7 @@ if(ENABLE_TESTING)
   # we need to build and link a LOT of tester executables, so it is worth checking if
   # a faster linker is available. requires GNU or Clang compiler, newer CMake.
   # also only verified with Fedora Linux > 30 and Ubuntu 18.04 or 22.04+(Ubuntu 20.04 fails)
-  if((CMAKE_SYSTEM_NAME STREQUAL "Linux") AND (CMAKE_VERSION VERSION_GREATER_EQUAL 3.13)
+  if((CMAKE_SYSTEM_NAME STREQUAL "Linux")
       AND ((CMAKE_CXX_COMPILER_ID STREQUAL "GNU") OR (CMAKE_CXX_COMPILER_ID STREQUAL "Clang")))
     if(((CMAKE_LINUX_DISTRO STREQUAL "Ubuntu") AND
           ((CMAKE_DISTRO_VERSION VERSION_LESS_EQUAL 18.04) OR (CMAKE_DISTRO_VERSION VERSION_GREATER_EQUAL 22.04)))
@@ -66,16 +66,8 @@ if(CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
   option(ENABLE_COVERAGE "Enable collecting code coverage data" OFF)
   mark_as_advanced(ENABLE_COVERAGE)
   if(ENABLE_COVERAGE)
-    if(CMAKE_VERSION VERSION_LESS 3.13)
-      if(CMAKE_CXX_FLAGS)
-        set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} --coverage")
-      else()
-        set(CMAKE_CXX_FLAGS "${CMAKE_CXX_${CMAKE_BUILD_TYPE}_FLAGS} --coverage")
-      endif()
-    else()
-      target_compile_options(lammps PUBLIC --coverage)
-      target_link_options(lammps PUBLIC --coverage)
-    endif()
+    target_compile_options(lammps PUBLIC --coverage)
+    target_link_options(lammps PUBLIC --coverage)
   endif()
 endif()
 
@@ -118,16 +110,8 @@ validate_option(ENABLE_SANITIZER ENABLE_SANITIZER_VALUES)
 string(TOLOWER ${ENABLE_SANITIZER} ENABLE_SANITIZER)
 if(NOT ENABLE_SANITIZER STREQUAL "none")
   if((${CMAKE_CXX_COMPILER_ID} STREQUAL "GNU") OR (${CMAKE_CXX_COMPILER_ID} STREQUAL "Clang"))
-    if(CMAKE_VERSION VERSION_LESS 3.13)
-      if(CMAKE_CXX_FLAGS)
-        set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=${ENABLE_SANITIZER}")
-      else()
-        set(CMAKE_CXX_FLAGS "${CMAKE_CXX_${CMAKE_BUILD_TYPE}_FLAGS} -fsanitize=${ENABLE_SANITIZER}")
-      endif()
-    else()
-      target_compile_options(lammps PUBLIC -fsanitize=${ENABLE_SANITIZER})
-      target_link_options(lammps PUBLIC -fsanitize=${ENABLE_SANITIZER})
-    endif()
+    target_compile_options(lammps PUBLIC -fsanitize=${ENABLE_SANITIZER})
+    target_link_options(lammps PUBLIC -fsanitize=${ENABLE_SANITIZER})
   else()
     message(WARNING "ENABLE_SANITIZER option not supported by ${CMAKE_CXX_COMPILER_ID} compilers. Ignoring.")
     set(ENABLE_SANITIZER "none")

cmake/Modules/Tools.cmake

@@ -26,7 +26,7 @@ if(BUILD_TOOLS)
 
   enable_language(C)
   get_filename_component(MSI2LMP_SOURCE_DIR ${LAMMPS_TOOLS_DIR}/msi2lmp/src ABSOLUTE)
-  file(GLOB MSI2LMP_SOURCES ${CONFIGURE_DEPENDS} ${MSI2LMP_SOURCE_DIR}/[^.]*.c)
+  file(GLOB MSI2LMP_SOURCES CONFIGURE_DEPENDS ${MSI2LMP_SOURCE_DIR}/[^.]*.c)
   add_executable(msi2lmp ${MSI2LMP_SOURCES})
   if(STANDARD_MATH_LIB)
     target_link_libraries(msi2lmp PRIVATE ${STANDARD_MATH_LIB})
@@ -44,9 +44,6 @@ if(BUILD_LAMMPS_SHELL)
   endif()
   find_package(PkgConfig REQUIRED)
   pkg_check_modules(READLINE IMPORTED_TARGET REQUIRED readline)
-  if(NOT LAMMPS_EXCEPTIONS)
-    message(WARNING "The LAMMPS shell needs LAMMPS_EXCEPTIONS enabled for full functionality")
-  endif()
 
   # include resource compiler to embed icons into the executable on Windows
   if(CMAKE_SYSTEM_NAME STREQUAL "Windows")

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
-   that shell's init file (.cshrc, .bashrc, etc.) instead with appropiate commands
-   to modify the same environment variables.
+   MacOS. If you customized MacOS to use a different shell, you'll need to
+   modify that shell's init file (.cshrc, .bashrc, etc.) instead with
+   appropiate commands to modify the same environment variables.
 
 5. Try running LAMMPS (which might fail, see step 7)
 
@@ -50,10 +50,10 @@ these steps:
 
    lammps-gui ${LAMMPS_BENCH_DIR}/in.rhodo
 
-   Depending on the size and resolution of your screen, the fonts may
-   be too small to read. This can be adjusted by setting the environment
-   variable QT_FONT_DPI. The default value would be 72, so to increase
-   the fonts by a third one can add to the .zprofile file the line
+   Depending on the size and resolution of your screen, the fonts may be too
+   small to read. This can be adjusted by setting the environment variable
+   QT_FONT_DPI. The default value would be 72, so to increase the fonts by a
+   third, one can add to the .zprofile file the line
 
    export QT_FONT_DPI=96
 
@@ -61,9 +61,9 @@ these steps:
 
 7. Give permission to execute the commands (lmp, lammps-gui, msi2lmp, binary2txt, phana, stl_bin2txt)
 
-   MacOS will likely block the initial run of the executables, since they
-   were downloaded from the internet and are missing a known signature from an
-   identified developer. Go to "Settings" and search for "Security settings". It
-   should display a message that an executable like "lmp" was blocked. Press
+   MacOS will likely block the initial run of the executables, since they were
+   downloaded from the internet and are missing a known signature from an
+   identified developer. Go to "Settings" and search for "Security settings".
+   It should display a message that an executable like "lmp" was blocked. Press
    "Open anyway", which might prompt you for your admin credentials. Afterwards
    "lmp" and the other executables should work as expected.

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
-cd LAMMPS.app/Contents
+mv ${APP_NAME}.app LAMMPS_GUI.app
+cd LAMMPS_GUI.app/Contents
 
 echo "Attach icons to LAMMPS console and GUI executables"
 echo "read 'icns' (-16455) \"Resources/lammps.icns\";" > icon.rsrc
@@ -75,7 +75,7 @@ echo '
           set statusbar visible to false
           set toolbar visible to false
           set the bounds to { 100, 40, 868, 640 }
-          set position of item "'LAMMPS'.app" to { 190, 216 }
+          set position of item "'LAMMPS_GUI'.app" to { 190, 216 }
           set position of item "Applications" to { 576, 216 }
           set position of item "README.txt" to { 190, 400 }
         end tell
@@ -96,12 +96,12 @@ sync
 
 echo "Unmount modified disk image and convert to compressed read-only image"
 hdiutil detach "${DEVICE}"
-hdiutil convert "${APP_NAME}-rw.dmg" -format UDZO -o "LAMMPS-macOS-multiarch.dmg"
+hdiutil convert "${APP_NAME}-rw.dmg" -format UDZO -o "LAMMPS_GUI-macOS-multiarch.dmg"
 
 echo "Attach icon to .dmg file"
 echo "read 'icns' (-16455) \"lammps-gui.app/Contents/Resources/lammps.icns\";" > icon.rsrc
-Rez -a icon.rsrc -o LAMMPS-macOS-multiarch.dmg
-SetFile -a C LAMMPS-macOS-multiarch.dmg
+Rez -a icon.rsrc -o LAMMPS_GUI-macOS-multiarch.dmg
+SetFile -a C LAMMPS_GUI-macOS-multiarch.dmg
 rm icon.rsrc
 
 echo "Delete temporary disk images"

cmake/packaging/build_windows_cross_zip.sh

@@ -1,26 +1,64 @@
-#!/bin/bash -vx
+#!/bin/bash
 
 APP_NAME=lammps-gui
-DESTDIR=${PWD}/../LAMMPS_GUI
+DESTDIR=${PWD}/LAMMPS_GUI
+SYSROOT="$1"
 
 echo "Delete old files, if they exist"
-rm -rvf ${DESTDIR} LAMMPS-Win10-amd64.zip
+rm -rvf ${DESTDIR}/LAMMPS_GUI ${DESTDIR}/LAMMPS-Win10-amd64.zip
 
 echo "Create staging area for deployment and populate"
 DESTDIR=${DESTDIR} cmake --install .  --prefix "/"
 
-echo "Add required dependencies for Qt"
-for dll in Qt5Core.dll Qt5Gui.dll Qt5Widgets.dll
+# no static libs needed
+rm -rvf ${DESTDIR}/lib
+# but the LAMMPS lib
+
+echo "Copying required DLL files"
+for dll in $(objdump -p *.exe *.dll | sed -n -e '/DLL Name:/s/^.*DLL Name: *//p' | sort | uniq)
 do \
-    cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/${dll} ${DESTDIR}/bin/
-done
-for dir in styles platforms imageformats
-do \
-    mkdir -p ${DESTDIR}/${dir}
-    cp -r /usr/x86_64-w64-mingw32/sys-root/mingw/lib/qt5/plugins/${dir}/*.dll ${DESTDIR}/${dir}
+    doskip=0
+    for skip in ADVAPI32 CFGMGR32 GDI32 KERNEL32 MPR NETAPI32 PSAPI SHELL32 USER32 USERENV UxTheme VERSION WS2_32 WSOCK32 d3d11 dwmapi liblammps msvcrt_ole32
+    do \
+        test ${dll} = ${skip}.dll && doskip=1
+    done
+    test ${doskip} -eq 1 && continue
+    test -f ${DESTDIR}/bin/${dll} || cp -v ${SYSROOT}/bin/${dll} ${DESTDIR}/bin
 done
 
-pushd ..
-zip -9rv LAMMPS-Win10-amd64.zip LAMMPS_GUI
-popd
-exit 0
+echo "Copy required Qt plugins"
+mkdir -p ${DESTDIR}/qt5plugins
+for plugin in imageformats platforms styles
+do \
+    cp -r ${SYSROOT}/lib/qt5/plugins/${plugin} ${DESTDIR}/qt5plugins/
+done
+
+echo "Check dependencies of DLL files"
+for dll in $(objdump -p ${DESTDIR}/bin/*.dll ${DESTDIR}/qt5plugins/*/*.dll | sed -n -e '/DLL Name:/s/^.*DLL Name: *//p' | sort | uniq)
+do \
+    doskip=0
+    for skip in ADVAPI32 CFGMGR32 GDI32 KERNEL32 MPR NETAPI32 PSAPI SHELL32 USER32 USERENV UxTheme VERSION WS2_32 WSOCK32 d3d11 dwmapi liblammps msvcrt_ole32
+    do \
+        test ${dll} = ${skip}.dll && doskip=1
+    done
+    test ${doskip} -eq 1 && continue
+    test -f ${DESTDIR}/bin/${dll} || cp -v ${SYSROOT}/bin/${dll} ${DESTDIR}/bin
+done
+
+for dll in $(objdump -p ${DESTDIR}/bin/*.dll ${DESTDIR}/qt5plugins/*/*.dll | sed -n -e '/DLL Name:/s/^.*DLL Name: *//p' | sort | uniq)
+do \
+    doskip=0
+    for skip in ADVAPI32 CFGMGR32 GDI32 KERNEL32 MPR NETAPI32 PSAPI SHELL32 USER32 USERENV UxTheme VERSION WS2_32 WSOCK32 d3d11 dwmapi liblammps msvcrt_ole32
+    do \
+        test ${dll} = ${skip}.dll && doskip=1
+    done
+    test ${doskip} -eq 1 && continue
+    test -f ${DESTDIR}/bin/${dll} || cp -v ${SYSROOT}/bin/${dll} ${DESTDIR}/bin
+done
+
+cat > ${DESTDIR}/bin/qt.conf <<EOF
+[Paths]
+Plugins = ../qt5plugins
+EOF
+zip -9rvD LAMMPS-Win10-amd64.zip LAMMPS_GUI
+

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/packaging/linux_wrapper.sh

@@ -1,6 +1,9 @@
 #!/bin/sh
 # wrapper for bundled executables
 
+# reset locale to avoid problems with decimal numbers
+export LC_ALL=C
+
 BASEDIR=$(dirname "$0")
 EXENAME=$(basename "$0")
 

cmake/presets/all_off.cmake

@@ -63,8 +63,6 @@ set(ALL_PACKAGES
   MOFFF
   MOLECULE
   MOLFILE
-  MPIIO
-  MSCG
   NETCDF
   OPENMP
   OPT

cmake/presets/all_on.cmake

@@ -65,8 +65,6 @@ set(ALL_PACKAGES
   MOFFF
   MOLECULE
   MOLFILE
-  MPIIO
-  MSCG
   NETCDF
   OPENMP
   OPT

cmake/presets/download.cmake

@@ -9,7 +9,6 @@ endforeach()
 
 set(DOWNLOAD_KIM ON CACHE BOOL "" FORCE)
 set(DOWNLOAD_MDI ON CACHE BOOL "" FORCE)
-set(DOWNLOAD_MSCG ON CACHE BOOL "" FORCE)
 set(DOWNLOAD_VORO ON CACHE BOOL "" FORCE)
 set(DOWNLOAD_EIGEN3 ON CACHE BOOL "" FORCE)
 set(DOWNLOAD_PACE ON CACHE BOOL "" FORCE)

cmake/presets/gpu-cuda.cmake

@@ -0,0 +1,11 @@
+# preset that enables GPU and selects CUDA API
+
+set(PKG_GPU ON CACHE BOOL "Build GPU package" FORCE)
+set(GPU_API "cuda" CACHE STRING "APU used by GPU package" FORCE)
+set(GPU_PREC "mixed" CACHE STRING "" FORCE)
+
+set(CUDA_NVCC_FLAGS "-allow-unsupported-compiler" CACHE STRING "" FORCE)
+set(CUDA_NVCC_FLAGS_DEBUG "-allow-unsupported-compiler" CACHE STRING "" FORCE)
+set(CUDA_NVCC_FLAGS_MINSIZEREL "-allow-unsupported-compiler" CACHE STRING "" FORCE)
+set(CUDA_NVCC_FLAGS_RELWITHDEBINFO "-allow-unsupported-compiler" CACHE STRING "" FORCE)
+set(CUDA_NVCC_FLAGS_RELEASE "-allow-unsupported-compiler" CACHE STRING "" FORCE)

cmake/presets/kokkos-cuda.cmake

@@ -6,6 +6,11 @@ set(Kokkos_ENABLE_SERIAL ON CACHE BOOL "" FORCE)
 set(Kokkos_ENABLE_CUDA   ON CACHE BOOL "" FORCE)
 set(Kokkos_ARCH_PASCAL60 ON CACHE BOOL "" FORCE)
 set(BUILD_OMP ON CACHE BOOL "" FORCE)
+get_filename_component(NVCC_WRAPPER_CMD ${CMAKE_CURRENT_SOURCE_DIR}/../lib/kokkos/bin/nvcc_wrapper ABSOLUTE)
+set(CMAKE_CXX_COMPILER ${NVCC_WRAPPER_CMD} CACHE FILEPATH "" FORCE)
+
+# If KSPACE is also enabled, use CUFFT for FFTs
+set(FFT_KOKKOS "CUFFT" CACHE STRING "" FORCE)
 
 # hide deprecation warnings temporarily for stable release
 set(Kokkos_ENABLE_DEPRECATION_WARNINGS OFF CACHE BOOL "" FORCE)

cmake/presets/kokkos-hip.cmake

@@ -12,6 +12,9 @@ set(BUILD_OMP ON CACHE BOOL "" FORCE)
 set(CMAKE_CXX_COMPILER hipcc CACHE STRING "" FORCE)
 set(CMAKE_TUNE_FLAGS "-munsafe-fp-atomics" CACHE STRING "" FORCE)
 
+# If KSPACE is also enabled, use CUFFT for FFTs
+set(FFT_KOKKOS "HIPFFT" CACHE STRING "" FORCE)
+
 # hide deprecation warnings temporarily for stable release
 set(Kokkos_ENABLE_DEPRECATION_WARNINGS OFF CACHE BOOL "" FORCE)
 

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)

cmake/presets/mingw-cross.cmake

@@ -83,7 +83,6 @@ endforeach()
 
 # these two packages require a full MPI implementation
 if(BUILD_MPI)
-  set(PKG_MPIIO ON CACHE BOOL "" FORCE)
   set(PKG_LATBOLTZ ON CACHE BOOL "" FORCE)
 endif()
 

cmake/presets/most.cmake

@@ -24,8 +24,8 @@ set(ALL_PACKAGES
   DPD-REACT
   DPD-SMOOTH
   DRUDE
-  ELECTRODE
   EFF
+  ELECTRODE
   EXTRA-COMPUTE
   EXTRA-DUMP
   EXTRA-FIX

cmake/presets/nolib.cmake

@@ -19,8 +19,6 @@ set(PACKAGES_WITH_LIB
   ML-PACE
   ML-QUIP
   MOLFILE
-  MPIIO
-  MSCG
   NETCDF
   PLUMED
   PYTHON

cmake/presets/oneapi.cmake

@@ -18,11 +18,11 @@ set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
 
 unset(HAVE_OMP_H_INCLUDE CACHE)
 set(OpenMP_C "icx" CACHE STRING "" FORCE)
-set(OpenMP_C_FLAGS "-qopenmp -qopenmp-simd" CACHE STRING "" FORCE)
+set(OpenMP_C_FLAGS "-qopenmp;-qopenmp-simd" CACHE STRING "" FORCE)
 set(OpenMP_C_LIB_NAMES "omp" CACHE STRING "" FORCE)
 set(OpenMP_CXX "icpx" CACHE STRING "" FORCE)
-set(OpenMP_CXX_FLAGS "-qopenmp -qopenmp-simd" CACHE STRING "" FORCE)
+set(OpenMP_CXX_FLAGS "-qopenmp;-qopenmp-simd" CACHE STRING "" FORCE)
 set(OpenMP_CXX_LIB_NAMES "omp" CACHE STRING "" FORCE)
-set(OpenMP_Fortran_FLAGS "-qopenmp -qopenmp-simd" CACHE STRING "" FORCE)
+set(OpenMP_Fortran_FLAGS "-qopenmp;-qopenmp-simd" CACHE STRING "" FORCE)
 set(OpenMP_omp_LIBRARY "libiomp5.so" CACHE PATH "" FORCE)
 

cmake/presets/windows.cmake

@@ -32,6 +32,7 @@ set(WIN_PACKAGES
   INTERLAYER
   KSPACE
   LEPTON
+  MACHDYN
   MANIFOLD
   MANYBODY
   MC
@@ -45,6 +46,7 @@ set(WIN_PACKAGES
   MOLECULE
   MOLFILE
   OPENMP
+  OPT
   ORIENT
   PERI
   PHONON

doc/Makefile

@@ -63,6 +63,7 @@ help:
 	@echo "  anchor_check  scan for duplicate anchor labels"
 	@echo "  style_check   check for complete and consistent style lists"
 	@echo "  package_check check for complete and consistent package lists"
+	@echo "  role_check    check for misformatted role keywords"
 	@echo "  spelling      spell-check the manual"
 
 # ------------------------------------------
@@ -98,6 +99,8 @@ html: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJAX)
 		env LC_ALL=C grep -n '[^ -~]' $(RSTDIR)/*.rst ;\
 		env LC_ALL=C grep -n ' :[a-z]\+`' $(RSTDIR)/*.rst ;\
 		env LC_ALL=C grep -n ' `[^`]\+<[a-z][^`]\+`[^_]' $(RSTDIR)/*.rst ;\
+		env LC_ALL=C grep -n ':\(ref\|doc\):[^`]' $(RSTDIR)/*.rst ;\
+		env LC_ALL=C grep -n '\(ref\|doc\)`[^`]' $(RSTDIR)/*.rst ;\
 		$(PYTHON) $(BUILDDIR)/utils/check-styles.py -s ../src -d src ;\
 		echo "############################################" ;\
 		deactivate ;\
@@ -179,6 +182,8 @@ pdf: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK)
 		env LC_ALL=C grep -n '[^ -~]' $(RSTDIR)/*.rst ;\
 		env LC_ALL=C grep -n ' :[a-z]\+`' $(RSTDIR)/*.rst ;\
 		env LC_ALL=C grep -n ' `[^`]\+<[a-z][^`]\+`[^_]' $(RSTDIR)/*.rst ;\
+		env LC_ALL=C grep -n ':\(ref\|doc\):[^`]' $(RSTDIR)/*.rst ;\
+		env LC_ALL=C grep -n '\(ref\|doc\)`[^`]' $(RSTDIR)/*.rst ;\
 		$(PYTHON) utils/check-styles.py -s ../src -d src ;\
 		echo "############################################" ;\
 		deactivate ;\
@@ -227,6 +232,8 @@ char_check :
 role_check :
 	@( env LC_ALL=C grep -n ' :[a-z]\+`' $(RSTDIR)/*.rst && exit 1 || : )
 	@( env LC_ALL=C grep -n ' `[^`]\+<[a-z][^`]\+`[^_]' $(RSTDIR)/*.rst && exit 1 || : )
+	@( env LC_ALL=C grep -n ':\(ref\|doc\):[^`]' $(RSTDIR)/*.rst && exit 1 || : )
+	@( env LC_ALL=C grep -n '\(ref\|doc\)`[^`]' $(RSTDIR)/*.rst && exit 1 || : )
 
 link_check : $(VENV) html
 	@(\

doc/github-development-workflow.md

@@ -36,10 +36,10 @@ requests.
 MUST be submitted as a pull request to GitHub.  All changes to the
 "develop" branch must be made exclusively through merging pull requests.
 The "release" and "stable" branches, respectively, are only to be
-updated upon feature or stable releases based on the associated
-tags.  Updates to the stable release in between stable releases
+updated upon "feature releases" or "stable releases" based on the
+associated tags.  Updates to the stable release in between stable releases
 (for example, back-ported bug fixes) are first merged into the "maintenance"
-branch and then into the "stable" branch as update releases.
+branch and then into the "stable" branch as "stable update releases".
 
 Pull requests may also be submitted to (long-running) feature branches
 created by LAMMPS developers inside the LAMMPS project, if needed. Those
@@ -131,7 +131,7 @@ testing -- that the code in the branch "develop" does not get easily
 broken.  These tests are run after every update to a pull request.  More
 extensive and time-consuming tests (including regression testing) are
 performed after code is merged to the "develop" branch.  There are feature
-releases of LAMMPS made about every 4-6 weeks at a point, when the LAMMPS
+releases of LAMMPS made about every 4-8 weeks at a point, when the LAMMPS
 developers feel, that a sufficient number of changes have been included
 and all post-merge testing has been successful.  These feature releases are
 marked with a `patch_<version date>` tag and the "release" branch

doc/graphviz/Makefile

@@ -16,8 +16,11 @@ clean:
 	rm -f $(IMGSVG) $(IMGPDF) $(IMGPNG) *~
 
 ifeq ($(HAS_DOT),YES)
-$(IMGDIR)/%.png: %.dot
+$(IMGDIR)/lammps-classes.png : lammps-classes.dot
 	dot -Tpng -Kneato -o $@ $<
+
+$(IMGDIR)/%.png: %.dot
+	dot -Tpng -Kdot -o $@ $<
 endif
 
 ifeq ($(HAS_DOT),NO)

doc/graphviz/lammps-releases.dot

@@ -0,0 +1,34 @@
+// LAMMPS branches and releases
+digraph releases {
+    rankdir="LR";
+    github [shape="box" label="Pull Requests\non GitHub" height=0.75];
+    github -> develop [label="Merge commits"];
+    {
+        rank = "same";
+        work [shape="none" label="Development branches:"]
+        develop [label="'develop' branch" height=0.75];
+        maintenance [label="'maintenance' branch" height=0.75];
+    };
+    {
+        rank = "same";
+        upload [shape="none" label="Release branches:"]
+        release [label="'release' branch" height=0.75];
+        stable [label="'stable' branch" height=0.75];
+    };
+    develop -> release [label="Feature release\n(every 4-8 weeks)"];
+    release -> stable [label="Stable release\n(once per year)"];
+    stable -> maintenance [label="Reset on stable release" style="setlinewidth(2)"];
+    develop -> maintenance [label="Backports of bugfixes" style="dashed"];
+    maintenance -> stable [label="Updates to stable release"];
+    {
+        rank = "same";
+        tag [shape="none" label="Applied tags:"];
+        patchtag [shape="box" label="patch_<date>"];
+        stabletag [shape="box" label="stable_<date>"];
+        updatetag [shape="box" label="stable_<date>_update<num>"];
+    };
+    release -> patchtag [label="feature release" style="dotted"];
+    stable -> stabletag [label="stable release" style="dotted"];
+    stable -> updatetag [label="update release" style="dotted"];
+}
+

doc/lammps.1

@@ -1,7 +1,7 @@
-.TH LAMMPS "1" "2 August 2023" "2023-08-2"
+.TH LAMMPS "1" "17 April 2024" "2024-04-17"
 .SH NAME
 .B LAMMPS
-\- Molecular Dynamics Simulator.  Version 2 August 2023
+\- Molecular Dynamics Simulator.  Version 17 April 2024
 
 .SH SYNOPSIS
 .B lmp
@@ -297,7 +297,7 @@ the chapter on errors in the
 manual gives some additional information about error messages, if possible.
 
 .SH COPYRIGHT
-© 2003--2022 Sandia Corporation
+© 2003--2024 Sandia Corporation
 
 This package is free software; you can redistribute it and/or modify
 it under the terms of the GNU General Public License version 2 as

doc/src/Bibliography.rst

@@ -562,6 +562,9 @@ Bibliography
 **(Kumar)**
    Kumar and Skinner, J. Phys. Chem. B, 112, 8311 (2008)
 
+**(Lafourcade)**
+  Lafourcade, Maillet, Denoual, Duval, Allera, Goryaeva, and Marinica, `Comp. Mat. Science, 230, 112534 (2023) <https://doi.org/10.1016/j.commatsci.2023.112534>`_
+
 **(Lamoureux and Roux)**
    G.\  Lamoureux, B. Roux, J. Chem. Phys 119, 3025 (2003)
 
@@ -874,6 +877,9 @@ Bibliography
 **(PLUMED)**
    G.A. Tribello, M. Bonomi, D. Branduardi, C. Camilloni and G. Bussi, Comp. Phys. Comm 185, 604 (2014)
 
+**(Pavlov)**
+D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Journal of High Performance Computing Applications, 38, 34-49 (2024).
+
 **(Paquay)**
    Paquay and Kusters, Biophys. J., 110, 6, (2016). preprint available at `arXiv:1411.3019 <https://arxiv.org/abs/1411.3019/>`_.
 

doc/src/Build_basics.rst

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

doc/src/Build_cmake.rst

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

doc/src/Build_development.rst

@@ -122,32 +122,39 @@ Code Coverage and Unit Testing (CMake only)
 -------------------------------------------
 
 The LAMMPS code is subject to multiple levels of automated testing
-during development: integration testing (i.e. whether the code compiles
-on various platforms and with a variety of settings), unit testing
-(i.e. whether certain individual parts of the code produce the expected
-results for given inputs), run testing (whether selected complete input
-decks run without crashing for multiple configurations), and regression
-testing (i.e. whether selected input examples reproduce the same
-results over a given number of steps and operations within a given
-error margin).  The status of this automated testing can be viewed on
-`https://ci.lammps.org <https://ci.lammps.org>`_.
+during development:
+
+- Integration testing (i.e. whether the code compiles
+  on various platforms and with a variety of compilers and settings),
+- Unit testing (i.e. whether certain functions or classes of the code
+  produce the expected results for given inputs),
+- Run testing (i.e. whether selected input decks can run to completion
+  without crashing for multiple configurations),
+- Regression testing (i.e. whether selected input examples reproduce the
+  same results over a given number of steps and operations within a
+  given error margin).
+
+The status of this automated testing can be viewed on `https://ci.lammps.org
+<https://ci.lammps.org>`_.
 
 The scripts and inputs for integration, run, and regression testing
 are maintained in a
 `separate repository <https://github.com/lammps/lammps-testing>`_
-of the LAMMPS project on GitHub.
+of the LAMMPS project on GitHub.  A few tests are also run as GitHub
+Actions and their configuration files are in the ``.github/workflows/``
+folder of the LAMMPS git tree.
 
-The unit testing facility is integrated into the CMake build process
-of the LAMMPS source code distribution itself.  It can be enabled by
+The unit testing facility is integrated into the CMake build process of
+the LAMMPS source code distribution itself.  It can be enabled by
 setting ``-D ENABLE_TESTING=on`` during the CMake configuration step.
-It requires the `YAML <https://pyyaml.org/>`_ library and development
-headers (if those are not found locally a recent version will be
-downloaded and compiled along with LAMMPS and the test program) to
-compile and will download and compile a specific recent version of the
-`Googletest <https://github.com/google/googletest/>`_ C++ test framework
-for implementing the tests.
+It requires the `YAML <https://pyyaml.org/>`_ library and matching
+development headers to compile (if those are not found locally a recent
+version of that library will be downloaded and compiled along with
+LAMMPS and the test programs) and will download and compile a specific
+version of the `GoogleTest <https://github.com/google/googletest/>`_ C++
+test framework that is used to implement the tests.
 
-.. admonition:: Software version requirements for testing
+.. admonition:: Software version and LAMMPS configuration requirements
    :class: note
 
    The compiler and library version requirements for the testing
@@ -155,7 +162,7 @@ for implementing the tests.
    example the default GNU C++ and Fortran compilers of RHEL/CentOS 7.x
    (version 4.8.x) are not sufficient.  The CMake configuration will try
    to detect incompatible versions and either skip incompatible tests or
-   stop with an error.  Also the number of tests will depend on
+   stop with an error.  Also the number of available tests will depend on
    installed LAMMPS packages, development environment, operating system,
    and configuration settings.
 
@@ -234,12 +241,31 @@ will be skipped if prerequisite features are not available in LAMMPS.
    time.  Preference is given to parts of the code base that are easy to
    test or commonly used.
 
-Tests for styles of the same kind of style (e.g. pair styles or bond
-styles) are performed with the same test executable using different
-input files in YAML format.  So to add a test for another style of the
-same kind it may be sufficient to add a suitable YAML file.
-:doc:`Detailed instructions for adding tests <Developer_unittest>` are
-provided in the Programmer Guide part of the manual.
+Tests as shown by the ``ctest`` program are command lines defined in the
+``CMakeLists.txt`` files in the ``unittest`` directory tree.  A few
+tests simply execute LAMMPS with specific command line flags and check
+the output to the screen for expected content.  A large number of unit
+tests are special tests programs using the `GoogleTest framework
+<https://github.com/google/googletest/>`_ and linked to the LAMMPS
+library that test individual functions or create a LAMMPS class
+instance, execute one or more commands and check data inside the LAMMPS
+class hierarchy.  There are also tests for the C-library, Fortran, and
+Python module interfaces to LAMMPS.  The Python tests use the Python
+"unittest" module in a similar fashion than the others use `GoogleTest`.
+These special test programs are structured to perform multiple
+individual tests internally and each of those contains several checks
+(aka assertions) for internal data being changed as expected.
+
+Tests for force computing or modifying styles (e.g. styles for non-bonded
+and bonded interactions and selected fixes) are run by using a more generic
+test program that reads its input from files in YAML format. The YAML file
+provides the information on how to customized the test program to test
+a specific style and - if needed - with specific settings.
+To add a test for another, similar style (e.g. a new pair style) it is
+usually sufficient to add a suitable YAML file.  :doc:`Detailed
+instructions for adding tests <Developer_unittest>` are provided in the
+Programmer Guide part of the manual.  A description of what happens
+during the tests is given below.
 
 Unit tests for force styles
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -255,16 +281,18 @@ A test run is then a a collection multiple individual test runs each
 with many comparisons to reference results based on template input
 files, individual command settings, relative error margins, and
 reference data stored in a YAML format file with ``.yaml``
-suffix. Currently the programs ``test_pair_style``, ``test_bond_style``, and
-``test_angle_style`` are implemented.  They will compare forces, energies and
-(global) stress for all atoms after a ``run 0`` calculation and after a
-few steps of MD with :doc:`fix nve <fix_nve>`, each in multiple variants
-with different settings and also for multiple accelerated styles. If a
-prerequisite style or package is missing, the individual tests are
-skipped.  All tests will be executed on a single MPI process, so using
-the CMake option ``-D BUILD_MPI=off`` can significantly speed up testing,
-since this will skip the MPI initialization for each test run.
-Below is an example command and output:
+suffix. Currently the programs ``test_pair_style``, ``test_bond_style``,
+``test_angle_style``, ``test_dihedral_style``, and
+``test_improper_style`` are implemented.  They will compare forces,
+energies and (global) stress for all atoms after a ``run 0`` calculation
+and after a few steps of MD with :doc:`fix nve <fix_nve>`, each in
+multiple variants with different settings and also for multiple
+accelerated styles. If a prerequisite style or package is missing, the
+individual tests are skipped.  All force style tests will be executed on
+a single MPI process, so using the CMake option ``-D BUILD_MPI=off`` can
+significantly speed up testing, since this will skip the MPI
+initialization for each test run.  Below is an example command and
+output:
 
 .. code-block:: console
 
@@ -416,15 +444,16 @@ When compiling LAMMPS with enabled tests, most test executables will
 need to be linked against the LAMMPS library.  Since this can be a very
 large library with many C++ objects when many packages are enabled, link
 times can become very long on machines that use the GNU BFD linker (e.g.
-Linux systems).  Alternatives like the ``lld`` linker of the LLVM project
-or the ``gold`` linker available with GNU binutils can speed up this step
-substantially. CMake will by default test if any of the two can be
-enabled and use it when ``ENABLE_TESTING`` is active.  It can also be
-selected manually through the ``CMAKE_CUSTOM_LINKER`` CMake variable.
-Allowed values are ``lld``, ``gold``, ``bfd``, or ``default``.  The
-``default`` option will use the system default linker otherwise, the
-linker is chosen explicitly.  This option is only available for the
-GNU or Clang C++ compiler.
+Linux systems).  Alternatives like the ``mold`` linker, the ``lld``
+linker of the LLVM project, or the ``gold`` linker available with GNU
+binutils can speed up this step substantially (in this order).  CMake
+will by default test if any of the three can be enabled and use it when
+``ENABLE_TESTING`` is active.  It can also be selected manually through
+the ``CMAKE_CUSTOM_LINKER`` CMake variable.  Allowed values are
+``mold``, ``lld``, ``gold``, ``bfd``, or ``default``.  The ``default``
+option will use the system default linker otherwise, the linker is
+chosen explicitly.  This option is only available for the GNU or Clang
+C++ compilers.
 
 Tests for other components and utility functions
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -518,6 +547,8 @@ The following options are available.
    make fix-errordocs       # remove error docs in header files
    make check-permissions   # search for files with permissions issues
    make fix-permissions     # correct permissions issues in files
+   make check-docs          # search for several issues in the manual
+   make check-version       # list files with pending release version tags
    make check               # run all check targets from above
 
 These should help to make source and documentation files conforming

doc/src/Build_extras.rst

@@ -52,7 +52,6 @@ This is the list of packages that may require additional steps.
    * :ref:`ML-POD <ml-pod>`
    * :ref:`ML-QUIP <ml-quip>`
    * :ref:`MOLFILE <molfile>`
-   * :ref:`MSCG <mscg>`
    * :ref:`NETCDF <netcdf>`
    * :ref:`OPENMP <openmp>`
    * :ref:`OPT <opt>`
@@ -534,9 +533,6 @@ They must be specified in uppercase.
    *  - A64FX
       - HOST
       - ARMv8.2 with SVE Support
-   *  - WSM
-      - HOST
-      - Intel Westmere CPU (SSE 4.2)
    *  - SNB
       - HOST
       - Intel Sandy/Ivy Bridge CPU (AVX 1)
@@ -567,18 +563,15 @@ They must be specified in uppercase.
    *  - KNL
       - HOST
       - Intel Knights Landing Xeon Phi
-   *  - BGQ
-      - HOST
-      - IBM Blue Gene/Q CPU
-   *  - POWER7
-      - HOST
-      - IBM POWER7 CPU
    *  - POWER8
       - HOST
       - IBM POWER8 CPU
    *  - POWER9
       - HOST
       - IBM POWER9 CPU
+   *  - RISCV_SG2042
+      - HOST
+      - SG2042 (RISC-V) CPU
    *  - KEPLER30
       - GPU
       - NVIDIA Kepler generation CC 3.0 GPU
@@ -627,18 +620,24 @@ They must be specified in uppercase.
    *  - HOPPER90
       - GPU
       - NVIDIA Hopper generation CC 9.0 GPU
-   *  - VEGA900
+   *  - AMD_GFX906
       - GPU
-      - AMD GPU MI25 GFX900
-   *  - VEGA906
+      - AMD GPU MI50/MI60
+   *  - AMD_GFX908
       - GPU
-      - AMD GPU MI50/MI60 GFX906
-   *  - VEGA908
+      - AMD GPU MI100
+   *  - AMD_GFX90A
       - GPU
-      - AMD GPU MI100 GFX908
-   *  - VEGA90A
+      - AMD GPU MI200
+   *  - AMD_GFX942
       - GPU
-      - AMD GPU MI200 GFX90A
+      - AMD GPU MI300
+   *  - AMD_GFX1030
+      - GPU
+      - AMD GPU V620/W6800
+   *  - AMD_GFX1100
+      - GPU
+      - AMD GPU RX7900XTX
    *  - INTEL_GEN
       - GPU
       - SPIR64-based devices, e.g. Intel GPUs, using JIT
@@ -661,7 +660,7 @@ They must be specified in uppercase.
       - GPU
       - Intel GPU Ponte Vecchio
 
-This list was last updated for version 3.7.1 of the Kokkos library.
+This list was last updated for version 4.3.0 of the Kokkos library.
 
 .. tabs::
 
@@ -717,9 +716,10 @@ This list was last updated for version 3.7.1 of the Kokkos library.
       ``cmake/presets`` folder, ``kokkos-serial.cmake``,
       ``kokkos-openmp.cmake``, ``kokkos-cuda.cmake``,
       ``kokkos-hip.cmake``, and ``kokkos-sycl.cmake``.  They will enable
-      the KOKKOS package and enable some hardware choice.  So to compile
-      with CUDA device parallelization (for GPUs with CC 5.0 and up)
-      with some common packages enabled, you can do the following:
+      the KOKKOS package and enable some hardware choices.  For GPU
+      support those preset files must be customized to match the
+      hardware used. So to compile with CUDA device parallelization with
+      some common packages enabled, you can do the following:
 
       .. code-block:: bash
 
@@ -881,6 +881,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
@@ -931,59 +975,6 @@ Python version 3.6 or later.
 
 ----------
 
-.. _mscg:
-
-MSCG package
------------------------
-
-To build with this package, you must download and build the MS-CG
-library.  Building the MS-CG library requires that the GSL
-(GNU Scientific Library) headers and libraries are installed on your
-machine.  See the ``lib/mscg/README`` and ``MSCG/Install`` files for
-more details.
-
-.. tabs::
-
-   .. tab:: CMake build
-
-      .. code-block:: bash
-
-         -D DOWNLOAD_MSCG=value    # download MSCG for build, value = no (default) or yes
-         -D MSCG_LIBRARY=path      # MSCG library file (only needed if a custom location)
-         -D MSCG_INCLUDE_DIR=path  # MSCG include directory (only needed if a custom location)
-
-      If ``DOWNLOAD_MSCG`` is set, the MSCG library will be downloaded
-      and built inside the CMake build directory.  If the MSCG library
-      is already on your system (in a location CMake cannot find it),
-      ``MSCG_LIBRARY`` is the filename (plus path) of the MSCG library
-      file, not the directory the library file is in.
-      ``MSCG_INCLUDE_DIR`` is the directory the MSCG include file is in.
-
-   .. tab:: Traditional make
-
-      You can download and build the MS-CG library manually if you
-      prefer; follow the instructions in ``lib/mscg/README``\ .  You can
-      also do it in one step from the ``lammps/src`` dir, using a
-      command like these, which simply invokes the
-      ``lib/mscg/Install.py`` script with the specified args:
-
-      .. code-block:: bash
-
-         make lib-mscg             # print help message
-         make lib-mscg args="-b -m serial"   # download and build in lib/mscg/MSCG-release-master
-                                             # with the settings compatible with "make serial"
-         make lib-mscg args="-b -m mpi"      # download and build in lib/mscg/MSCG-release-master
-                                             # with the settings compatible with "make mpi"
-         make lib-mscg args="-p /usr/local/mscg-release" # use the existing MS-CG installation in /usr/local/mscg-release
-
-      Note that 2 symbolic (soft) links, ``includelink`` and ``liblink``,
-      will be created in ``lib/mscg`` to point to the MS-CG
-      ``src/installation`` dir.  When LAMMPS is built in src it will use
-      these links.  You should not need to edit the
-      ``lib/mscg/Makefile.lammps`` file.
-
-----------
-
 .. _opt:
 
 OPT package
@@ -1059,12 +1050,12 @@ additional details.
 
       .. code-block:: bash
 
-         -D PYTHON_EXECUTABLE=path   # path to Python executable to use
+         -D Python_EXECUTABLE=path   # path to Python executable to use
 
       Without this setting, CMake will guess the default Python version
       on your system.  To use a different Python version, you can either
       create a virtualenv, activate it and then run cmake.  Or you can
-      set the PYTHON_EXECUTABLE variable to specify which Python
+      set the Python_EXECUTABLE variable to specify which Python
       interpreter should be used.  Note note that you will also need to
       have the development headers installed for this version,
       e.g. python2-devel.
@@ -1479,6 +1470,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
@@ -2000,55 +2040,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
@@ -2096,50 +2087,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

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

doc/src/Build_settings.rst

@@ -44,6 +44,14 @@ require use of an FFT library to compute 1d FFTs.  The KISS FFT
 library is included with LAMMPS, but other libraries can be faster.
 LAMMPS can use them if they are available on your system.
 
+.. versionadded:: 7Feb2024
+
+Alternatively, LAMMPS can use the `heFFTe
+<https://icl-utk-edu.github.io/heffte/>`_ library for the MPI
+communication algorithms, which comes with many optimizations for
+special cases, e.g. leveraging available 2D and 3D FFTs in the back end
+libraries and better pipelining for packing and communication.
+
 .. tabs::
 
    .. tab:: CMake build
@@ -51,14 +59,19 @@ LAMMPS can use them if they are available on your system.
       .. code-block:: bash
 
          -D FFT=value              # FFTW3 or MKL or KISS, default is FFTW3 if found, else KISS
+         -D FFT_KOKKOS=value       # FFTW3 or MKL or KISS or CUFFT or HIPFFT, default is KISS
          -D FFT_SINGLE=value       # yes or no (default), no = double precision
          -D FFT_PACK=value         # array (default) or pointer or memcpy
+         -D FFT_USE_HEFFTE=value   # yes or no (default), yes links to heFFTe
 
       .. note::
 
-         The values for the FFT variable must be in upper-case.  This is
-         an exception to the rule that all CMake variables can be specified
-         with lower-case values.
+         When the Kokkos variant of a package is compiled and selected at run time,
+         the FFT library selected by the FFT_KOKKOS variable applies. Otherwise,
+         the FFT library selected by the FFT variable applies.
+         The same FFT settings apply to both. FFT_KOKKOS must be compatible with the
+         Kokkos back end - for example, when using the CUDA back end of Kokkos,
+         you must use either CUFFT or KISS.
 
       Usually these settings are all that is needed.  If FFTW3 is
       selected, then CMake will try to detect, if threaded FFTW
@@ -76,6 +89,16 @@ LAMMPS can use them if they are available on your system.
          -D MKL_INCLUDE_DIR=path     # ditto for Intel MKL library
          -D FFT_MKL_THREADS=on       # enable using threaded FFTs with MKL libraries
          -D MKL_LIBRARY=path         # path to MKL libraries
+         -D FFT_HEFFTE_BACKEND=value # FFTW or MKL or empty/undefined for the stock heFFTe back end
+         -D Heffte_ROOT=path         # path to an existing heFFTe installation
+
+      .. note::
+
+         heFFTe comes with a builtin (= stock) back end for FFTs, i.e. a
+         default internal FFT implementation; however, this stock back
+         end is intended for testing purposes only and is not optimized
+         for production runs.
+
 
    .. tab:: Traditional make
 
@@ -87,6 +110,8 @@ LAMMPS can use them if they are available on your system.
 
          FFT_INC = -DFFT_FFTW3         # -DFFT_FFTW3, -DFFT_FFTW (same as -DFFT_FFTW3), -DFFT_MKL, or -DFFT_KISS
                                        # default is KISS if not specified
+         FFT_INC = -DFFT_KOKKOS_CUFFT  # -DFFT_KOKKOS_{FFTW,FFTW3,MKL,CUFFT,HIPFFT,KISS}
+                                       # default is KISS if not specified
          FFT_INC = -DFFT_SINGLE        # do not specify for double precision
          FFT_INC = -DFFT_FFTW_THREADS  # enable using threaded FFTW3 libraries
          FFT_INC = -DFFT_MKL_THREADS   # enable using threaded FFTs with MKL libraries
@@ -97,6 +122,8 @@ LAMMPS can use them if they are available on your system.
 
          FFT_INC =       -I/usr/local/include
          FFT_PATH =      -L/usr/local/lib
+         FFT_LIB =       -lhipfft            # hipFFT either precision
+         FFT_LIB =       -lcufft             # cuFFT either precision
          FFT_LIB =       -lfftw3             # FFTW3 double precision
          FFT_LIB =       -lfftw3 -lfftw3_omp # FFTW3 double precision with threads (needs -DFFT_FFTW_THREADS)
          FFT_LIB =       -lfftw3 -lfftw3f    # FFTW3 single precision
@@ -111,6 +138,24 @@ LAMMPS can use them if they are available on your system.
       files in its default search path.  You must specify ``FFT_LIB``
       with the appropriate FFT libraries to include in the link.
 
+      Traditional make can also link to heFFTe using an existing installation
+
+      .. code-block:: make
+
+         include <path-to-heffte-installation>/share/heffte/HeffteMakefile.in
+         FFT_INC = -DFFT_HEFFTE -DFFT_HEFFTE_FFTW $(heffte_include)
+         FFT_PATH =
+         FFT_LIB = $(heffte_link) $(heffte_libs)
+
+      The heFFTe install path will contain `HeffteMakefile.in`.
+      which will define the `heffte_` include variables needed to link to heFFTe from
+      an external project using traditional make.
+      The `-DFFT_HEFFTE` is required to switch to using heFFTe, while the optional `-DFFT_HEFFTE_FFTW`
+      selects the desired heFFTe back end, e.g., `-DFFT_HEFFTE_FFTW` or `-DFFT_HEFFTE_MKL`,
+      omitting the variable will default to the `stock` back end.
+      The heFFTe `stock` back end is intended to be used for testing and debugging,
+      but is not performance optimized for large scale production runs.
+
 The `KISS FFT library <https://github.com/mborgerding/kissfft>`_ is
 included in the LAMMPS distribution.  It is portable across all
 platforms.  Depending on the size of the FFTs and the number of
@@ -141,6 +186,11 @@ The Intel MKL math library is part of the Intel compiler suite.  It
 can be used with the Intel or GNU compiler (see the ``FFT_LIB`` setting
 above).
 
+The cuFFT and hipFFT FFT libraries are packaged with NVIDIA's CUDA and
+AMD's HIP installations, respectively. These FFT libraries require the
+Kokkos acceleration package to be enabled and the Kokkos back end to be
+GPU-resident (i.e., HIP or CUDA).
+
 Performing 3d FFTs in parallel can be time-consuming due to data access
 and required communication.  This cost can be reduced by performing
 single-precision FFTs instead of double precision.  Single precision
@@ -152,11 +202,11 @@ generally less than the difference in precision. Using the
 ``-DFFT_SINGLE`` setting trades off a little accuracy for reduced memory
 use and parallel communication costs for transposing 3d FFT data.
 
-When using ``-DFFT_SINGLE`` with FFTW3, you may need to build the FFTW
-library a second time with support for single-precision.
+When using ``-DFFT_SINGLE`` with FFTW3, you may need to ensure that
+the FFTW3 installation includes support for single-precision.
 
-For FFTW3, do the following, which should produce the additional
-library ``libfftw3f.a`` or ``libfftw3f.so``\ .
+When compiler FFTW3 from source, you can do the following, which should
+produce the additional libraries ``libfftw3f.a`` and/or ``libfftw3f.so``\ .
 
 .. code-block:: bash
 
@@ -170,6 +220,16 @@ Depending on the machine, the size of the FFT grid, the number of
 processors used, one option may be slightly faster.  The default is
 ARRAY mode.
 
+When using ``-DFFT_HEFFTE`` CMake will first look for an existing
+install with hints provided by ``-DHeffte_ROOT``, as recommended by the
+CMake standard and note that the name is case sensitive. If CMake cannot
+find a heFFTe installation with the correct back end (e.g., FFTW or
+MKL), it will attempt to download and build the library automatically.
+In this case, LAMMPS CMake will also accept all heFFTe specific
+variables listed in the `heFFTe documentation
+<https://mkstoyanov.bitbucket.io/heffte/md_doxygen_installation.html>`_
+and those variables will be passed into the heFFTe build.
+
 ----------
 
 .. _size:
@@ -459,27 +519,13 @@ those systems:
 .. _exceptions:
 
 Exception handling when using LAMMPS as a library
-------------------------------------------------------------------
+-------------------------------------------------
 
-This setting is useful when external codes drive LAMMPS as a library.
-With this option enabled, LAMMPS errors do not kill the calling code.
-Instead, the call stack is unwound and control returns to the caller,
-e.g. to Python. Of course, the calling code has to be set up to
-*catch* exceptions thrown from within LAMMPS.
-
-.. tabs::
-
-   .. tab:: CMake build
-
-      .. code-block:: bash
-
-         -D LAMMPS_EXCEPTIONS=value        # yes or no (default)
-
-   .. tab:: Traditional make
-
-      .. code-block:: make
-
-         LMP_INC = -DLAMMPS_EXCEPTIONS   <other LMP_INC settings>
+LAMMPS errors do not kill the calling code, but throw an exception.  In
+the C-library interface, the call stack is unwound and control returns
+to the caller, e.g. to Python or a code that is coupled to LAMMPS. The
+error status can then be queried.  When using C++ directly, the calling
+code has to be set up to *catch* exceptions thrown from within LAMMPS.
 
 .. note::
 

doc/src/Commands_bond.rst

@@ -89,6 +89,7 @@ OPT.
    * :doc:`cosine/shift (o) <angle_cosine_shift>`
    * :doc:`cosine/shift/exp (o) <angle_cosine_shift_exp>`
    * :doc:`cosine/squared (o) <angle_cosine_squared>`
+   * :doc:`cosine/squared/restricted (o) <angle_cosine_squared_restricted>`
    * :doc:`cross <angle_cross>`
    * :doc:`dipole (o) <angle_dipole>`
    * :doc:`fourier (o) <angle_fourier>`
@@ -124,9 +125,10 @@ OPT.
    *
    *
    * :doc:`charmm (iko) <dihedral_charmm>`
-   * :doc:`charmmfsw <dihedral_charmm>`
+   * :doc:`charmmfsw (k) <dihedral_charmm>`
    * :doc:`class2 (ko) <dihedral_class2>`
    * :doc:`cosine/shift/exp (o) <dihedral_cosine_shift_exp>`
+   * :doc:`cosine/squared/restricted <dihedral_cosine_squared_restricted>`
    * :doc:`fourier (io) <dihedral_fourier>`
    * :doc:`harmonic (iko) <dihedral_harmonic>`
    * :doc:`helix (o) <dihedral_helix>`

doc/src/Commands_compute.rst

@@ -91,6 +91,7 @@ KOKKOS, o = OPENMP, t = OPT.
    * :doc:`ke/atom/eff <compute_ke_atom_eff>`
    * :doc:`ke/eff <compute_ke_eff>`
    * :doc:`ke/rigid <compute_ke_rigid>`
+   * :doc:`composition/atom (k) <compute_composition_atom>`
    * :doc:`mliap <compute_mliap>`
    * :doc:`momentum <compute_momentum>`
    * :doc:`msd <compute_msd>`
@@ -99,6 +100,7 @@ KOKKOS, o = OPENMP, t = OPT.
    * :doc:`nbond/atom <compute_nbond_atom>`
    * :doc:`omega/chunk <compute_omega_chunk>`
    * :doc:`orientorder/atom (k) <compute_orientorder_atom>`
+   * :doc:`pace <compute_pace>`
    * :doc:`pair <compute_pair>`
    * :doc:`pair/local <compute_pair_local>`
    * :doc:`pe <compute_pe>`
@@ -114,12 +116,15 @@ KOKKOS, o = OPENMP, t = OPT.
    * :doc:`property/grid <compute_property_grid>`
    * :doc:`property/local <compute_property_local>`
    * :doc:`ptm/atom <compute_ptm_atom>`
+   * :doc:`rattlers/atom <compute_rattlers_atom>`
    * :doc:`rdf <compute_rdf>`
+   * :doc:`reaxff/atom (k) <compute_reaxff_atom>`
    * :doc:`reduce <compute_reduce>`
    * :doc:`reduce/chunk <compute_reduce_chunk>`
    * :doc:`reduce/region <compute_reduce>`
    * :doc:`rigid/local <compute_rigid_local>`
    * :doc:`saed <compute_saed>`
+   * :doc:`slcsa/atom <compute_slcsa_atom>`
    * :doc:`slice <compute_slice>`
    * :doc:`smd/contact/radius <compute_smd_contact_radius>`
    * :doc:`smd/damage <compute_smd_damage>`

doc/src/Commands_dump.rst

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

doc/src/Commands_fix.rst

@@ -61,6 +61,7 @@ OPT.
    * :doc:`controller <fix_controller>`
    * :doc:`damping/cundall <fix_damping_cundall>`
    * :doc:`deform (k) <fix_deform>`
+   * :doc:`deform/pressure <fix_deform_pressure>`
    * :doc:`deposit <fix_deposit>`
    * :doc:`dpd/energy (k) <fix_dpd_energy>`
    * :doc:`drag <fix_drag>`
@@ -69,7 +70,7 @@ OPT.
    * :doc:`drude/transform/inverse <fix_drude_transform>`
    * :doc:`dt/reset (k) <fix_dt_reset>`
    * :doc:`edpd/source <fix_dpd_source>`
-   * :doc:`efield <fix_efield>`
+   * :doc:`efield (k) <fix_efield>`
    * :doc:`efield/tip4p <fix_efield>`
    * :doc:`ehex <fix_ehex>`
    * :doc:`electrode/conp (i) <fix_electrode>`
@@ -116,13 +117,13 @@ OPT.
    * :doc:`momentum (k) <fix_momentum>`
    * :doc:`momentum/chunk <fix_momentum>`
    * :doc:`move <fix_move>`
-   * :doc:`mscg <fix_mscg>`
    * :doc:`msst <fix_msst>`
    * :doc:`mvv/dpd <fix_mvv_dpd>`
    * :doc:`mvv/edpd <fix_mvv_dpd>`
    * :doc:`mvv/tdpd <fix_mvv_dpd>`
    * :doc:`neb <fix_neb>`
    * :doc:`neb/spin <fix_neb_spin>`
+   * :doc:`nonaffine/displacement <fix_nonaffine_displacement>`
    * :doc:`nph (ko) <fix_nh>`
    * :doc:`nph/asphere (o) <fix_nph_asphere>`
    * :doc:`nph/body <fix_nph_body>`
@@ -182,6 +183,7 @@ OPT.
    * :doc:`pour <fix_pour>`
    * :doc:`precession/spin <fix_precession_spin>`
    * :doc:`press/berendsen <fix_press_berendsen>`
+   * :doc:`press/langevin <fix_press_langevin>`
    * :doc:`print <fix_print>`
    * :doc:`propel/self <fix_propel_self>`
    * :doc:`property/atom (k) <fix_property_atom>`
@@ -233,15 +235,15 @@ OPT.
    * :doc:`spring <fix_spring>`
    * :doc:`spring/chunk <fix_spring_chunk>`
    * :doc:`spring/rg <fix_spring_rg>`
-   * :doc:`spring/self <fix_spring_self>`
+   * :doc:`spring/self (k) <fix_spring_self>`
    * :doc:`srd <fix_srd>`
    * :doc:`store/force <fix_store_force>`
    * :doc:`store/state <fix_store_state>`
    * :doc:`tdpd/source <fix_dpd_source>`
-   * :doc:`temp/berendsen <fix_temp_berendsen>`
+   * :doc:`temp/berendsen (k) <fix_temp_berendsen>`
    * :doc:`temp/csld <fix_temp_csvr>`
    * :doc:`temp/csvr <fix_temp_csvr>`
-   * :doc:`temp/rescale <fix_temp_rescale>`
+   * :doc:`temp/rescale (k) <fix_temp_rescale>`
    * :doc:`temp/rescale/eff <fix_temp_rescale_eff>`
    * :doc:`tfmc <fix_tfmc>`
    * :doc:`tgnpt/drude <fix_tgnh_drude>`
@@ -261,6 +263,7 @@ OPT.
    * :doc:`wall/body/polyhedron <fix_wall_body_polyhedron>`
    * :doc:`wall/colloid <fix_wall>`
    * :doc:`wall/ees <fix_wall_ees>`
+   * :doc:`wall/flow (k) <fix_wall_flow>`
    * :doc:`wall/gran (k) <fix_wall_gran>`
    * :doc:`wall/gran/region <fix_wall_gran_region>`
    * :doc:`wall/harmonic <fix_wall>`

doc/src/Commands_pair.rst

@@ -87,7 +87,7 @@ OPT.
    * :doc:`coul/long/soft (o) <pair_fep_soft>`
    * :doc:`coul/msm (o) <pair_coul>`
    * :doc:`coul/slater/cut <pair_coul_slater>`
-   * :doc:`coul/slater/long <pair_coul_slater>`
+   * :doc:`coul/slater/long (g) <pair_coul_slater>`
    * :doc:`coul/shield <pair_coul_shield>`
    * :doc:`coul/streitz <pair_coul>`
    * :doc:`coul/tt <pair_coul_tt>`
@@ -110,7 +110,7 @@ OPT.
    * :doc:`eam/he <pair_eam>`
    * :doc:`edip (o) <pair_edip>`
    * :doc:`edip/multi <pair_edip>`
-   * :doc:`edpd <pair_mesodpd>`
+   * :doc:`edpd (g) <pair_mesodpd>`
    * :doc:`eff/cut <pair_eff>`
    * :doc:`eim (o) <pair_eim>`
    * :doc:`exp6/rx (k) <pair_exp6_rx>`
@@ -146,7 +146,7 @@ OPT.
    * :doc:`lj/charmm/coul/long/soft (o) <pair_fep_soft>`
    * :doc:`lj/charmm/coul/msm (o) <pair_charmm>`
    * :doc:`lj/charmmfsw/coul/charmmfsh <pair_charmm>`
-   * :doc:`lj/charmmfsw/coul/long <pair_charmm>`
+   * :doc:`lj/charmmfsw/coul/long (k) <pair_charmm>`
    * :doc:`lj/class2 (gko) <pair_class2>`
    * :doc:`lj/class2/coul/cut (ko) <pair_class2>`
    * :doc:`lj/class2/coul/cut/soft <pair_fep_soft>`
@@ -158,14 +158,14 @@ OPT.
    * :doc:`lj/cut (gikot) <pair_lj>`
    * :doc:`lj/cut/coul/cut (gko) <pair_lj_cut_coul>`
    * :doc:`lj/cut/coul/cut/dielectric (o) <pair_dielectric>`
-   * :doc:`lj/cut/coul/cut/soft (o) <pair_fep_soft>`
+   * :doc:`lj/cut/coul/cut/soft (go) <pair_fep_soft>`
    * :doc:`lj/cut/coul/debye (gko) <pair_lj_cut_coul>`
    * :doc:`lj/cut/coul/debye/dielectric (o) <pair_dielectric>`
    * :doc:`lj/cut/coul/dsf (gko) <pair_lj_cut_coul>`
    * :doc:`lj/cut/coul/long (gikot) <pair_lj_cut_coul>`
    * :doc:`lj/cut/coul/long/cs <pair_cs>`
    * :doc:`lj/cut/coul/long/dielectric (o) <pair_dielectric>`
-   * :doc:`lj/cut/coul/long/soft (o) <pair_fep_soft>`
+   * :doc:`lj/cut/coul/long/soft (go) <pair_fep_soft>`
    * :doc:`lj/cut/coul/msm (go) <pair_lj_cut_coul>`
    * :doc:`lj/cut/coul/msm/dielectric <pair_dielectric>`
    * :doc:`lj/cut/coul/wolf (o) <pair_lj_cut_coul>`
@@ -202,7 +202,7 @@ OPT.
    * :doc:`lubricate/poly (o) <pair_lubricate>`
    * :doc:`lubricateU <pair_lubricateU>`
    * :doc:`lubricateU/poly <pair_lubricateU>`
-   * :doc:`mdpd <pair_mesodpd>`
+   * :doc:`mdpd (g) <pair_mesodpd>`
    * :doc:`mdpd/rhosum <pair_mesodpd>`
    * :doc:`meam (k) <pair_meam>`
    * :doc:`meam/ms (k) <pair_meam>`
@@ -220,7 +220,8 @@ OPT.
    * :doc:`morse/soft <pair_fep_soft>`
    * :doc:`multi/lucy <pair_multi_lucy>`
    * :doc:`multi/lucy/rx (k) <pair_multi_lucy_rx>`
-   * :doc:`nb3b/harmonic <pair_nb3b_harmonic>`
+   * :doc:`nb3b/harmonic <pair_nb3b>`
+   * :doc:`nb3b/screened <pair_nb3b>`
    * :doc:`nm/cut (o) <pair_nm>`
    * :doc:`nm/cut/coul/cut (o) <pair_nm>`
    * :doc:`nm/cut/coul/long (o) <pair_nm>`
@@ -244,6 +245,7 @@ OPT.
    * :doc:`oxrna2/coaxstk <pair_oxrna2>`
    * :doc:`pace (k) <pair_pace>`
    * :doc:`pace/extrapolation (k) <pair_pace>`
+   * :doc:`pedone (o) <pair_pedone>`
    * :doc:`pod <pair_pod>`
    * :doc:`peri/eps <pair_peri>`
    * :doc:`peri/lps (o) <pair_peri>`
@@ -255,6 +257,7 @@ OPT.
    * :doc:`rann <pair_rann>`
    * :doc:`reaxff (ko) <pair_reaxff>`
    * :doc:`rebo (io) <pair_airebo>`
+   * :doc:`rebomos (o) <pair_rebomos>`
    * :doc:`resquared (go) <pair_resquared>`
    * :doc:`saip/metal (t) <pair_saip_metal>`
    * :doc:`sdpd/taitwater/isothermal <pair_sdpd_taitwater_isothermal>`
@@ -265,13 +268,13 @@ OPT.
    * :doc:`smd/tri_surface <pair_smd_triangulated_surface>`
    * :doc:`smd/ulsph <pair_smd_ulsph>`
    * :doc:`smtbq <pair_smtbq>`
-   * :doc:`snap (k) <pair_snap>`
+   * :doc:`snap (ik) <pair_snap>`
    * :doc:`soft (go) <pair_soft>`
-   * :doc:`sph/heatconduction <pair_sph_heatconduction>`
+   * :doc:`sph/heatconduction (g) <pair_sph_heatconduction>`
    * :doc:`sph/idealgas <pair_sph_idealgas>`
-   * :doc:`sph/lj <pair_sph_lj>`
+   * :doc:`sph/lj (g) <pair_sph_lj>`
    * :doc:`sph/rhosum <pair_sph_rhosum>`
-   * :doc:`sph/taitwater <pair_sph_taitwater>`
+   * :doc:`sph/taitwater (g) <pair_sph_taitwater>`
    * :doc:`sph/taitwater/morris <pair_sph_taitwater_morris>`
    * :doc:`spin/dipole/cut <pair_spin_dipole>`
    * :doc:`spin/dipole/long <pair_spin_dipole>`
@@ -305,5 +308,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/Commands_removed.rst

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

doc/src/Developer_platform.rst

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

doc/src/Developer_unittest.rst

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

doc/src/Developer_updating.rst

@@ -18,8 +18,10 @@ Available topics in mostly chronological order are:
 - `Setting flags in the constructor`_
 - `Rename of pack/unpack_comm() to pack/unpack_forward_comm()`_
 - `Use ev_init() to initialize variables derived from eflag and vflag`_
+- `Use utils::count_words() functions instead of atom->count_words()`_
 - `Use utils::numeric() functions instead of force->numeric()`_
 - `Use utils::open_potential() function to open potential files`_
+- `Use symbolic Atom and AtomVec constants instead of numerical values`_
 - `Simplify customized error messages`_
 - `Use of "override" instead of "virtual"`_
 - `Simplified and more compact neighbor list requests`_
@@ -129,6 +131,41 @@ Not applying this change will not cause a compilation error, but
 can lead to inconsistent behavior and incorrect tallying of
 energy or virial.
 
+Use utils::count_words() functions instead of atom->count_words()
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. versionchanged:: 2Jun2020
+
+The "count_words()" functions for parsing text have been moved from the
+Atom class to the :doc:`utils namespace <Developer_utils>`.  The
+"count_words()" function in "utils" uses the Tokenizer class internally
+to split a line into words and count them, thus it will not modify the
+argument string as the function in the Atoms class did and thus had a
+variant using a copy buffer.  Unlike the old version, the new version
+does not remove comments. For that you can use the
+:cpp:func:`utils::trim_comment() function
+<LAMMPS_NS::utils::trim_comment>` as shown in the example below.
+
+Old:
+
+.. code-block:: c++
+
+   nwords = atom->count_words(line);
+   int nwords = atom->count_words(buf);
+
+New:
+
+.. code-block:: c++
+
+   nwords = utils::count_words(line);
+   int nwords = utils::count_words(utils::trim_comment(buf));
+
+.. seealso::
+
+   :cpp:func:`utils::count_words() <LAMMPS_NS::utils::count_words>`,
+   :cpp:func:`utils::trim_comments() <LAMMPS_NS::utils::trim_comments>`
+
+
 Use utils::numeric() functions instead of force->numeric()
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -136,11 +173,12 @@ Use utils::numeric() functions instead of force->numeric()
 
 The "numeric()" conversion functions (including "inumeric()",
 "bnumeric()", and "tnumeric()") have been moved from the Force class to
-the utils namespace.  Also they take an additional argument that selects
-whether the ``Error::all()`` or ``Error::one()`` function should be
-called in case of an error.  The former should be used when *all* MPI
-processes call the conversion function and the latter *must* be used
-when they are called from only one or a subset of the MPI processes.
+the :doc:`utils namespace <Developer_utils>`.  Also they take an
+additional argument that selects whether the ``Error::all()`` or
+``Error::one()`` function should be called in case of an error.  The
+former should be used when *all* MPI processes call the conversion
+function and the latter *must* be used when they are called from only
+one or a subset of the MPI processes.
 
 Old:
 
@@ -196,6 +234,71 @@ New:
 
    fp = utils::open_potential(filename, lmp);
 
+Use symbolic Atom and AtomVec constants instead of numerical values
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. versionchanged:: 18Sep2020
+
+Properties in LAMMPS that were represented by integer values (0, 1,
+2, 3) to indicate settings in the ``Atom`` and ``AtomVec`` classes (or
+classes derived from it) (and its derived classes) have been converted
+to use scoped enumerators instead.
+
+.. list-table::
+   :header-rows: 1
+   :widths: auto
+
+   * - Symbolic Constant
+     - Value
+     - Symbolic Constant
+     - Value
+   * - Atom::GROW
+     - 0
+     - Atom::MAP_NONE
+     - 0
+   * - Atom::RESTART
+     - 1
+     - Atom::MAP_ARRAY
+     - 1
+   * - Atom::BORDER
+     - 2
+     - Atom::MAP_HASH
+     - 2
+   * - Atom::ATOMIC
+     - 0
+     - Atom::MAP_YES
+     - 3
+   * - Atom::MOLECULAR
+     - 1
+     - AtomVec::PER_ATOM
+     - 0
+   * - Atom::TEMPLATE
+     - 2
+     - AtomVec::PER_TYPE
+     - 1
+
+Old:
+
+.. code-block:: c++
+
+   molecular = 0;
+   mass_type = 1;
+   if (atom->molecular == 2)
+   if (atom->map_style == 2)
+   atom->add_callback(0);
+   atom->delete_callback(id,1);
+
+New:
+
+.. code-block:: c++
+
+   molecular = Atom::ATOMIC;
+   mass_type = AtomVec::PER_TYPE;
+   if (atom->molecular == Atom::TEMPLATE)
+   if (atom->map_style == Atom::MAP_HASH)
+   atom->add_callback(Atom::GROW);
+   atom->delete_callback(id,Atom::RESTART);
+
 Simplify customized error messages
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 

doc/src/Developer_utils.rst

@@ -635,10 +635,10 @@ Tohoku University (under MIT license)
 
 ----------
 
-.. doxygenfunction:: MathEigen::jacobi3(double const *const *mat, double *eval, double **evec)
+.. doxygenfunction:: MathEigen::jacobi3(double const *const *mat, double *eval, double **evec, int sort)
    :project: progguide
 
-.. doxygenfunction:: MathEigen::jacobi3(double const mat[3][3], double *eval, double evec[3][3])
+.. doxygenfunction:: MathEigen::jacobi3(double const mat[3][3], double *eval, double evec[3][3], int sort)
    :project: progguide
 
 ---------------------------

doc/src/Errors_details.rst

@@ -13,15 +13,44 @@ discussions of such cases.
 Unknown identifier in data file
 -------------------------------
 
-This error happens when LAMMPS encounters a line of text in an unexpected format
-while reading a data file. This is most commonly cause by inconsistent header and
-section data.  The header section informs LAMMPS how many entries or lines are expected in the
-various sections (like Atoms, Masses, Pair Coeffs, *etc.*\ ) of the data file.
-If there is a mismatch, LAMMPS will either keep reading beyond the end of a section
-or stop reading before the section has ended.
+This error happens when LAMMPS encounters a line of text with an
+unexpected keyword while :doc:`reading a data file <read_data>`.  This
+would be either header keywords or section header keywords.  This is
+most commonly due to a mistyped keyword or due to a keyword that is
+inconsistent with the :doc:`atom style <atom_style>` used.
 
-Such a mismatch can happen unexpectedly when the first line of the data
-is *not* a comment as required by the format.  That would result in
-LAMMPS expecting, for instance, 0 atoms because the "atoms" header line
-is treated as a comment.
+The header section informs LAMMPS how many entries or lines are expected
+in the various sections (like Atoms, Masses, Pair Coeffs, *etc.*\ ) of
+the data file.  If there is a mismatch, LAMMPS will either keep reading
+beyond the end of a section or stop reading before the section has
+ended.  In that case the next line will not contain a recognized keyword.
 
+Such a mismatch can also happen when the first line of the data
+is *not* a comment as required by the format, but a line with a valid
+header keyword.  That would result in LAMMPS expecting, for instance,
+0 atoms because the "atoms" header line is the first line and thus
+treated as a comment.
+
+Another possibility to trigger this error is to have a keyword in the
+data file that corresponds to a fix (e.g. :doc:`fix cmap <fix_cmap>`)
+but the :doc:`read_data <read_data>` command is missing the (optional)
+arguments that identify the fix and the header keyword and section
+keyword or those arguments are inconsistent with the keywords in the
+data file.
+
+.. _err0002:
+
+Incorrect format in ... section of data file
+--------------------------------------------
+
+This error happens when LAMMPS reads the contents of a section of a
+:doc:`data file <read_data>` and the number of parameters in the line
+differs from what is expected.  This most commonly happens, when the
+atom style is different from what is expected for a specific data file
+since changing the atom style usually changes the format of the line.
+
+This error can also happen when the number of entries indicated in the
+header of a data file (e.g. the number of atoms) is larger than the
+number of lines provided (e.g. in the corresponding Atoms section)
+and then LAMMPS will continue reading into the next section and that
+would have a completely different format.

doc/src/Errors_messages.rst

@@ -7148,9 +7148,6 @@ keyword to allow for additional bonds to be formed
 *Read_dump xyz fields do not have consistent scaling/wrapping*
    Self-explanatory.
 
-*Reading from MPI-IO filename when MPIIO package is not installed*
-   Self-explanatory.
-
 *Reax_defs.h setting for NATDEF is too small*
    Edit the setting in the ReaxFF library and re-compile the
    library and re-build LAMMPS.
@@ -7886,12 +7883,6 @@ keyword to allow for additional bonds to be formed
    Fix poems cannot (yet) work with coupled bodies whose joints connect
    the bodies in a tree structure.
 
-*Triclinic box skew is too large*
-   The displacement in a skewed direction must be less than half the box
-   length in that dimension.  E.g. the xy tilt must be between -half and
-   +half of the x box length.  This constraint can be relaxed by using
-   the box tilt command.
-
 *Tried to convert a double to int, but input_double > INT_MAX*
    Self-explanatory.
 
@@ -8489,9 +8480,6 @@ keyword to allow for additional bonds to be formed
    The write_restart command cannot be used before a read_data,
    read_restart, or create_box command.
 
-*Writing to MPI-IO filename when MPIIO package is not installed*
-   Self-explanatory.
-
 *Zero length rotation vector with displace_atoms*
    Self-explanatory.
 

doc/src/Errors_warnings.rst

@@ -752,13 +752,6 @@ This will most likely cause errors in kinetic fluctuations.
    More than the maximum # of neighbors was found multiple times.  This
    was unexpected.
 
-*Triclinic box skew is large*
-   The displacement in a skewed direction is normally required to be less
-   than half the box length in that dimension.  E.g. the xy tilt must be
-   between -half and +half of the x box length.  You have relaxed the
-   constraint using the box tilt command, but the warning means that a
-   LAMMPS simulation may be inefficient as a result.
-
 *Use special bonds = 0,1,1 with bond style fene*
    Most FENE models need this setting for the special_bonds command.
 

doc/src/Examples.rst

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

doc/src/Fortran.rst

@@ -315,6 +315,10 @@ of the contents of the :f:mod:`LIBLAMMPS` Fortran interface to LAMMPS.
    :ftype extract_variable: function
    :f set_variable: :f:subr:`set_variable`
    :ftype set_variable: subroutine
+   :f set_string_variable: :f:subr:`set_set_string_variable`
+   :ftype set_string_variable: subroutine
+   :f set_internal_variable: :f:subr:`set_internal_variable`
+   :ftype set_internal_variable: subroutine
    :f gather_atoms: :f:subr:`gather_atoms`
    :ftype gather_atoms: subroutine
    :f gather_atoms_concat: :f:subr:`gather_atoms_concat`
@@ -1251,8 +1255,8 @@ Procedures Bound to the :f:type:`lammps` Derived Type
    three elements of the global vector calculated by fix recenter into the
    variables *dx*, *dy*, and *dz*, respectively.
 
-   If asked for per-atom or local data, :f:func:`extract_compute` returns a
-   pointer to actual LAMMPS data. The pointer so returned will have the
+   If asked for per-atom or local data, :f:func:`extract_fix` returns a
+   pointer to actual LAMMPS data.  The pointer returned will have the
    appropriate size to match the internal data, and will be
    type/kind/rank-checked at the time of the assignment. For example,
 
@@ -1398,7 +1402,28 @@ Procedures Bound to the :f:type:`lammps` Derived Type
 
    Set the value of a string-style variable.
 
-   .. versionadded:: 3Nov2022
+   .. deprecated:: 7Feb2024
+
+   This function assigns a new value from the string *str* to the string-style
+   variable *name*\ . If *name* does not exist or is not a string-style
+   variable, an error is generated.
+
+   .. warning::
+
+      This subroutine is deprecated and :f:subr:`set_string_variable`
+      should be used instead.
+
+   :p character(len=*) name: name of the variable
+   :p character(len=*) str:  new value to assign to the variable
+   :to: :cpp:func:`lammps_set_variable`
+
+--------
+
+.. f:subroutine:: set_string_variable(name, str)
+
+   Set the value of a string-style variable.
+
+   .. versionadded:: 7Feb2024
 
    This function assigns a new value from the string *str* to the string-style
    variable *name*\ . If *name* does not exist or is not a string-style
@@ -1406,7 +1431,23 @@ Procedures Bound to the :f:type:`lammps` Derived Type
 
    :p character(len=*) name: name of the variable
    :p character(len=*) str:  new value to assign to the variable
-   :to: :cpp:func:`lammps_set_variable`
+   :to: :cpp:func:`lammps_set_string_variable`
+
+--------
+
+.. f:subroutine:: set_internal_variable(name, val)
+
+   Set the value of a internal-style variable.
+
+   .. versionadded:: 7Feb2024
+
+   This function assigns a new value from the floating-point number *val* to
+   the internal-style variable *name*\ . If *name* does not exist or is not
+   an internal-style variable, an error is generated.
+
+   :p character(len=*) name: name of the variable
+   :p read(c_double) val:  new value to assign to the variable
+   :to: :cpp:func:`lammps_set_internal_variable`
 
 --------
 
@@ -2278,19 +2319,13 @@ Procedures Bound to the :f:type:`lammps` Derived Type
 
    .. versionadded:: 3Nov2022
 
-   In case of an error, LAMMPS will either abort or throw a C++ exception.
-   The latter has to be :ref:`enabled at compile time <exceptions>`.
-   This function checks if exceptions were enabled.
-
-   When using the library interface with C++ exceptions enabled, the library
-   interface functions will "catch" them, and the error status can then be
-   checked by calling :f:func:`has_error`. The most recent error message can be
-   retrieved via :f:func:`get_last_error_message`.
-   This can allow one to restart a calculation or delete and recreate
-   the LAMMPS instance when a C++ exception occurs.  One application
-   of using exceptions this way is the :ref:`lammps_shell`.  If C++
-   exceptions are disabled and an error happens during a call to
-   LAMMPS or the Fortran API, the application will terminate.
+   When using the library interface, the library interface functions
+   will "catch" exceptions, and then the error status can be checked by
+   calling :f:func:`has_error`.  The most recent error message can be
+   retrieved via :f:func:`get_last_error_message`.  This allows to
+   restart a calculation or delete and recreate the LAMMPS instance when
+   a C++ exception occurs.  One application of using exceptions this way
+   is the :ref:`lammps_shell`.
 
    :to: :cpp:func:`lammps_config_has_exceptions`
    :r has_exceptions:
@@ -3044,14 +3079,6 @@ Procedures Bound to the :f:type:`lammps` Derived Type
    This function can be used to query if an error inside of LAMMPS
    has thrown a :ref:`C++ exception <exceptions>`.
 
-   .. note::
-
-      This function will always report "no error" when the LAMMPS library
-      has been compiled without ``-DLAMMPS_EXCEPTIONS``, which turns fatal
-      errors aborting LAMMPS into C++ exceptions. You can use the library
-      function :cpp:func:`lammps_config_has_exceptions` to check if this is
-      the case.
-
    :to: :cpp:func:`lammps_has_error`
    :r has_error: ``.TRUE.`` if there is an error.
    :rtype has_error: logical
@@ -3074,13 +3101,6 @@ Procedures Bound to the :f:type:`lammps` Derived Type
    would happen only in a single MPI rank and thus may not be recoverable, as
    other MPI ranks may be waiting on the failing MPI rank(s) to send messages.
 
-   .. note::
-
-      This function will do nothing when the LAMMPS library has been
-      compiled without ``-DLAMMPS_EXCEPTIONS``, which turns errors aborting
-      LAMMPS into C++ exceptions.  You can use the function
-      :f:func:`config_has_exceptions` to check whether this is the case.
-
    :p character(len=\*) buffer: string buffer to copy the error message into
    :o integer(c_int) status [optional]: 1 when all ranks had the error,
     2 on a single-rank error.

doc/src/Howto.rst

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

doc/src/Howto_2d.rst

@@ -1,42 +1,112 @@
-2d simulations
-==============
+================
+ 2d simulations
+================
 
-Use the :doc:`dimension <dimension>` command to specify a 2d simulation.
+You must use the :doc:`dimension <dimension>` command to specify a 2d
+simulation.  The default is 3d.
 
-Make the simulation box periodic in z via the :doc:`boundary <boundary>`
-command.  This is the default.
+A 2d simulation box must be periodic in z as set by the :doc:`boundary
+<boundary>` command.  This is the default.
 
-If using the :doc:`create_box <create_box>` command to define a
-simulation box, set the z dimensions narrow, but finite, so that the
-:doc:`create_atoms <create_atoms>` command will fill the 3d simulation
-box with a single z plane of atoms - e.g.
+Simulation boxes in LAMMPS can be either orthogonal or triclinic in
+shape.  Orthogonal boxes in 2d are a rectangle with 4 edges that are
+each perpendicular to either the x or y coordinate axes.  Triclinic
+boxes in 2d are a parallelogram with opposite pairs of faces parallel
+to each other.  LAMMPS supports two forms of triclinic boxes,
+restricted and general, which for 2d differ in how the box is oriented
+with respect to the xy coordinate axes.  See the :doc:`Howto triclinic
+<Howto_triclinic>` for a detailed description of all 3 kinds of
+simulation boxes.
+
+Here are examples of using the :doc:`create_box <create_box>` command
+to define the simulation box for a 2d system.
 
 .. code-block:: LAMMPS
 
-   create_box 1 -10 10 -10 10 -0.25 0.25
+   # 2d orthogonal box using a block-style region
+   region mybox block -10 10 0 10 -0.5 0.5
+   create_box 1 mybox
 
-If using the :doc:`read_data <read_data>` command to read in a file of
-atom coordinates, set the "zlo zhi" values to be finite but narrow,
-similar to the create_box command settings just described.  For each
-atom in the file, assign a z coordinate so it falls inside the
-z-boundaries of the box - e.g. 0.0.
+   # 2d restricted triclinic box using a prism-style region with only xy tilt
+   region mybox prism 0 10 0 10 -0.5 0.5 2.0 0.0 0.0
+   create_box 1 mybox
 
-Use the :doc:`fix enforce2d <fix_enforce2d>` command as the last
-defined fix to ensure that the z-components of velocities and forces
-are zeroed out every timestep.  The reason to make it the last fix is
-so that any forces induced by other fixes will be zeroed out.
+   # 2d general triclinic box using a primitive cell for a 2d hex lattice
+   lattice       custom 1.0 a1 1.0 0.0 0.0 a2 0.5 0.86602540378 0.0 &
+                 a3 0.0 0.0 1.0 basis 0.0 0.0 0.0 triclinic/general
+   create_box    1 NULL 0 5 0 5 -0.5 0.5
 
-Many of the example input scripts included in the LAMMPS distribution
+Note that for 2d orthogonal or restricted triclinic boxes, the box has
+a 3rd dimension which must straddle z = 0.0 in the z dimension.
+Typically the width of box in the z dimension should be narrow,
+e.g. -0.5 to 0.5, but that is not required.  For a 2d general
+triclinic box, the *a3* vector defined by the :doc:`lattice <lattice>`
+command must be (0.0,0.0,1.0), which is its default value.  Also the
+*clo* and *chi* arguments of the :doc:`create_box <create_box>`
+command must be -0.5 and 0.5.
+
+Here are examples of using the :doc:`read_data <read_data>` command
+to define the simulation box for a 2d system via keywords in the
+header section of the data file.  These are the same boxes as the examples
+for the :doc:`create_box <create_box>` command
+
+.. code-block:: LAMMPS
+
+   # 2d orthogonal box
+   -10 10   xlo xhi
+   0 10     ylo yhi
+   -0.5 0.5 zlo zhi       # this is the default, so no need to specify
+
+   # 2d restricted triclinic box with only xy tilt
+   -10 10   xlo xhi
+   0 10     ylo yhi
+   -0.5 0.5 zlo zhi       # this is the default, so no need to specify
+   2.0 0.0 0.0 xy xz yz
+
+   # 3d general triclinic box using a primitive cell for a 2d hex lattice
+   5 0 0              avec
+   2.5 4.3301270189 0 bvec
+   0 0 1              cvec           # this is the default, so no need to specify
+   0 0 -0.5           abc origin     # this is the default for 2d, so no need to specify
+
+Note that for 2d orthogonal or restricted triclinic boxes, the box has
+a 3rd dimension specified by the *zlo zhi* values, which must straddle
+z = 0.0.  Typically the width of box in the z dimension should be
+narrow, e.g. -0.5 to 0.5, but that is not required.  For a 2d general
+triclinic box, the z component of *avec* and *bvec* must be zero, and
+*cvec* must be (0,0,1), which is the default.  The z component of *abc
+origin* must also be -0.5, which is the default.
+
+If using the :doc:`create_atoms <create_atoms>` command to create
+atoms in the 2d simulation box, all the z coordinates of created atoms
+will be zero.
+
+If using the :doc:`read_data <read_data>` command to read in a data
+file of atom coordinates for a 2d system, the z coordinates of all
+atoms should be zero.  A value within epsilon of zero is also allowed
+in case the data file was generated by another program with finite
+numeric precision, in which case the z coord for the atom will be set
+to zero.
+
+Use the :doc:`fix enforce2d <fix_enforce2d>` command as the last fix
+defined in the input script.  It ensures that the z-components of
+velocities and forces are zeroed out every timestep.  The reason to
+make it the last fix is so that any forces added by other fixes will
+also be zeroed out.
+
+Many of the example input scripts included in the examples directory
 are for 2d models.
 
 .. note::
 
    Some models in LAMMPS treat particles as finite-size spheres, as
-   opposed to point particles.  See the :doc:`atom_style sphere <atom_style>` and :doc:`fix nve/sphere <fix_nve_sphere>`
-   commands for details.  By default, for 2d simulations, such particles
-   will still be modeled as 3d spheres, not 2d discs (circles), meaning
+   opposed to point particles.  See the :doc:`atom_style sphere
+   <atom_style>` and :doc:`fix nve/sphere <fix_nve_sphere>` commands
+   for details.  By default, for 2d simulations, such particles will
+   still be modeled as 3d spheres, not 2d discs (circles), meaning
    their moment of inertia will be that of a sphere.  If you wish to
-   model them as 2d discs, see the :doc:`set density/disc <set>` command
-   and the *disc* option for the :doc:`fix nve/sphere <fix_nve_sphere>`,
-   :doc:`fix nvt/sphere <fix_nvt_sphere>`, :doc:`fix nph/sphere <fix_nph_sphere>`, :doc:`fix npt/sphere <fix_npt_sphere>`
-   commands.
+   model them as 2d discs, see the :doc:`set density/disc <set>`
+   command and the *disc* option for the :doc:`fix nve/sphere
+   <fix_nve_sphere>`, :doc:`fix nvt/sphere <fix_nvt_sphere>`,
+   :doc:`fix nph/sphere <fix_nph_sphere>`, :doc:`fix npt/sphere
+   <fix_npt_sphere>` commands.

doc/src/Howto_body.rst

@@ -102,8 +102,19 @@ particles of different styles
 | :doc:`dump image <dump_image>`                 | output body particle attributes as an image         |
 +------------------------------------------------+-----------------------------------------------------+
 
-The pair styles defined for use with specific body styles are listed
-in the sections below.
+The pair styles currently defined for use with specific body styles
+are listed in the sections below.
+
+Note that for all the body styles, if the data file defines a general
+triclinic box, then the orientation of the body particle and its
+corresponding 6 moments of inertia and other orientation-dependent
+values should reflect the fact the body is defined withing a general
+triclinic box with edge vectors **A**,**B**,**C**.  LAMMPS will rotate
+the box to convert it to a restricted triclinic box.  This operation
+will also rotate the orientation of the body particles.  See the
+:doc:`Howto triclinic <Howto_triclinic>` doc page for more details.
+The sections below highlight the orientation-dependent values specific
+to each body style.
 
 ----------
 
@@ -154,12 +165,18 @@ values consistent with the current orientation of the rigid body
 around its center of mass.  The values are with respect to the
 simulation box XYZ axes, not with respect to the principal axes of the
 rigid body itself.  LAMMPS performs the latter calculation internally.
+
 The coordinates of each sub-particle are specified as its x,y,z
 displacement from the center-of-mass of the body particle.  The
 center-of-mass position of the particle is specified by the x,y,z
 values in the *Atoms* section of the data file, as is the total mass
 of the body particle.
 
+Note that if the data file defines a general triclinic simulation box,
+these sub-particle displacements are orientation-dependent and, as
+mentioned above, should reflect the body particle's orientation within
+the general triclinic box.
+
 The :doc:`pair_style body/nparticle <pair_body_nparticle>` command can be used
 with this body style to compute body/body and body/non-body interactions.
 
@@ -170,9 +187,9 @@ with this body style to compute body/body and body/non-body interactions.
 The *rounded/polygon* body style represents body particles as a 2d
 polygon with a variable number of N vertices.  This style can only be
 used for 2d models; see the :doc:`boundary <boundary>` command.  See the
-"pair_style body/rounded/polygon" page for a diagram of two
-squares with rounded circles at the vertices.  Special cases for N = 1
-(circle) and N = 2 (rod with rounded ends) can also be specified.
+:doc:`pair_style body/rounded/polygon <pair_body_rounded_polygon>` page for
+a diagram of two squares with rounded circles at the vertices.  Special cases
+for N = 1 (circle) and N = 2 (rod with rounded ends) can also be specified.
 
 One use of this body style is for 2d discrete element models, as
 described in :ref:`Fraige <body-Fraige>`.
@@ -226,6 +243,7 @@ values consistent with the current orientation of the rigid body
 around its center of mass.  The values are with respect to the
 simulation box XYZ axes, not with respect to the principal axes of the
 rigid body itself.  LAMMPS performs the latter calculation internally.
+
 The coordinates of each vertex are specified as its x,y,z displacement
 from the center-of-mass of the body particle.  The center-of-mass
 position of the particle is specified by the x,y,z values in the
@@ -270,6 +288,11 @@ A disk, whose diameter is 3.0, mass 1.0, is specified as follows:
    0 0 0
    3.0
 
+Note that if the data file defines a general triclinic simulation box,
+these polygon vertex displacements are orientation-dependent and, as
+mentioned above, should reflect the body particle's orientation within
+the general triclinic box.
+
 The :doc:`pair_style body/rounded/polygon <pair_body_rounded_polygon>`
 command can be used with this body style to compute body/body
 interactions.  The :doc:`fix wall/body/polygon <fix_wall_body_polygon>`
@@ -335,7 +358,7 @@ faces are listed, so that M = 6 + 3\*N + 1.
 The integer line has three values: number of vertices (N), number of
 edges (E) and number of faces (F). The floating point line(s) list 6
 moments of inertia followed by the coordinates of the N vertices (x1
-to zN) as 3N values, followed by 2N vertex indices corresponding to
+to zN) as 3N values, followed by 2E vertex indices corresponding to
 the end points of the E edges, then 4\*F vertex indices defining F
 faces.  The last value is the diameter value = the rounded diameter of
 the sphere that surrounds each vertex. The diameter value can be
@@ -366,6 +389,7 @@ values consistent with the current orientation of the rigid body
 around its center of mass.  The values are with respect to the
 simulation box XYZ axes, not with respect to the principal axes of the
 rigid body itself.  LAMMPS performs the latter calculation internally.
+
 The coordinates of each vertex are specified as its x,y,z displacement
 from the center-of-mass of the body particle.  The center-of-mass
 position of the particle is specified by the x,y,z values in the
@@ -435,6 +459,11 @@ A sphere whose diameter is 3.0 and mass 1.0, is specified as follows:
 The number of edges and faces for a rod or sphere must be listed,
 but is ignored.
 
+Note that if the data file defines a general triclinic simulation box,
+these polyhedron vertex displacements are orientation-dependent and,
+as mentioned above, should reflect the body particle's orientation
+within the general triclinic box.
+
 The :doc:`pair_style body/rounded/polhedron
 <pair_body_rounded_polyhedron>` command can be used with this body
 style to compute body/body interactions.  The :doc:`fix

doc/src/Howto_cmake.rst

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

doc/src/Howto_github.rst

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

doc/src/Howto_granular.rst

@@ -45,10 +45,15 @@ atoms, and should be used for granular system instead of the fix style
 
 To model heat conduction, one must add the temperature and heatflow
 atom variables with:
+
 * :doc:`fix property/atom <fix_property_atom>`
+
 a temperature integration fix
+
 * :doc:`fix heat/flow <fix_heat_flow>`
+
 and a heat conduction option defined in both
+
 * :doc:`pair_style granular <pair_granular>`
 * :doc:`fix wall/gran <fix_wall_gran>`
 

doc/src/Howto_lammps_gui.rst

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

doc/src/Howto_moltemplate.rst

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

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

doc/src/Howto_pylammps.rst

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

doc/src/Howto_structured_data.rst

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

doc/src/Howto_tip4p.rst

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

doc/src/Howto_tip5p.rst

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

doc/src/Howto_triclinic.rst

@@ -2,42 +2,195 @@ Triclinic (non-orthogonal) simulation boxes
 ===========================================
 
 By default, LAMMPS uses an orthogonal simulation box to encompass the
-particles.  The :doc:`boundary <boundary>` command sets the boundary
-conditions of the box (periodic, non-periodic, etc).  The orthogonal
-box has its "origin" at (xlo,ylo,zlo) and is defined by 3 edge vectors
-starting from the origin given by **a** = (xhi-xlo,0,0); **b** =
-(0,yhi-ylo,0); **c** = (0,0,zhi-zlo).  The 6 parameters
+particles.  The orthogonal box has its "origin" at (xlo,ylo,zlo) and
+extends to (xhi,yhi,zhi).  Conceptually it is defined by 3 edge
+vectors starting from the origin given by **A** = (xhi-xlo,0,0); **B**
+= (0,yhi-ylo,0); **C** = (0,0,zhi-zlo).  The :doc:`boundary
+<boundary>` command sets the boundary conditions for the 6 faces of
+the box (periodic, non-periodic, etc).  The 6 parameters
 (xlo,xhi,ylo,yhi,zlo,zhi) are defined at the time the simulation box
-is created, e.g. by the :doc:`create_box <create_box>` or
-:doc:`read_data <read_data>` or :doc:`read_restart <read_restart>`
-commands.  Additionally, LAMMPS defines box size parameters lx,ly,lz
-where lx = xhi-xlo, and similarly in the y and z dimensions.  The 6
-parameters, as well as lx,ly,lz, can be output via the :doc:`thermo_style custom <thermo_style>` command.
+is created by one of these commands:
 
-LAMMPS also allows simulations to be performed in triclinic
-(non-orthogonal) simulation boxes shaped as a parallelepiped with
-triclinic symmetry.  The parallelepiped has its "origin" at
-(xlo,ylo,zlo) and is defined by 3 edge vectors starting from the
-origin given by **a** = (xhi-xlo,0,0); **b** = (xy,yhi-ylo,0); **c** =
-(xz,yz,zhi-zlo).  *xy,xz,yz* can be 0.0 or positive or negative values
-and are called "tilt factors" because they are the amount of
-displacement applied to faces of an originally orthogonal box to
-transform it into the parallelepiped.  In LAMMPS the triclinic
-simulation box edge vectors **a**, **b**, and **c** cannot be arbitrary
-vectors.  As indicated, **a** must lie on the positive x axis.  **b** must
-lie in the xy plane, with strictly positive y component. **c** may have
-any orientation with strictly positive z component.  The requirement
-that **a**, **b**, and **c** have strictly positive x, y, and z components,
-respectively, ensures that **a**, **b**, and **c** form a complete
-right-handed basis.  These restrictions impose no loss of generality,
-since it is possible to rotate/invert any set of 3 crystal basis
-vectors so that they conform to the restrictions.
+* :doc:`create_box <create_box>`
+* :doc:`read_data <read_data>`
+* :doc:`read_restart <read_restart>`
+* :doc:`read_dump <read_dump>`
 
-For example, assume that the 3 vectors **A**,\ **B**,\ **C** are the edge
-vectors of a general parallelepiped, where there is no restriction on
-**A**,\ **B**,\ **C** other than they form a complete right-handed basis i.e.
-**A** x **B** . **C** > 0.  The equivalent LAMMPS **a**,\ **b**,\ **c** are a linear
-rotation of **A**, **B**, and **C** and can be computed as follows:
+Internally, LAMMPS defines box size parameters lx,ly,lz where lx =
+xhi-xlo, and similarly in the y and z dimensions.  The 6 parameters, as
+well as lx,ly,lz, can be output via the :doc:`thermo_style custom
+<thermo_style>` command.  See the :doc:`Howto 2d <Howto_2d>` doc page
+for info on how zlo and zhi are defined for 2d simulations.
+
+----------
+
+Triclinic simulation boxes
+""""""""""""""""""""""""""
+
+LAMMPS also allows simulations to be performed using triclinic
+(non-orthogonal) simulation boxes shaped as a 3d parallelepiped with
+triclinic symmetry.  For 2d simulations a triclinic simulation box is
+effectively a parallelogram; see the :doc:`Howto 2d <Howto_2d>` doc
+page for details.
+
+One use of triclinic simulation boxes is to model solid-state crystals
+with triclinic symmetry.  The :doc:`lattice <lattice>` command can be
+used with non-orthogonal basis vectors to define a lattice that will
+tile a triclinic simulation box via the :doc:`create_atoms
+<create_atoms>` command.
+
+A second use is to run Parrinello-Rahman dynamics via the :doc:`fix
+npt <fix_nh>` command, which will adjust the xy, xz, yz tilt factors
+to compensate for off-diagonal components of the pressure tensor.  The
+analog for an :doc:`energy minimization <minimize>` is the :doc:`fix
+box/relax <fix_box_relax>` command.
+
+A third use is to shear a bulk solid to study the response of the
+material.  The :doc:`fix deform <fix_deform>` command can be used for
+this purpose.  It allows dynamic control of the xy, xz, yz tilt
+factors as a simulation runs.  This is discussed in the :doc:`Howto
+NEMD <Howto_nemd>` doc page on non-equilibrium MD (NEMD) simulations.
+
+Conceptually, a triclinic parallelepiped is defined with an "origin"
+at (xlo,ylo,zhi) and 3 edge vectors **A** = (ax,ay,az), **B** =
+(bx,by,bz), **C** = (cx,cy,cz) which can be arbitrary vectors, so long
+as they are non-zero, distinct, and not co-planar.  In addition, they
+must define a right-handed system, such that (**A** cross **B**)
+points in the direction of **C**.  Note that a left-handed system can
+be converted to a right-handed system by simply swapping the order of
+any pair of the **A**, **B**, **C** vectors.
+
+The 4 commands listed above for defining orthogonal simulation boxes
+have triclinic options which allow for specification of the origin and
+edge vectors **A**, **B**, **C**.  For each command, this can be done
+in one of two ways, for what LAMMPS calls a *general* triclinic box or
+a *restricted* triclinic box.
+
+A *general* triclinic box is specified by an origin (xlo, ylo, zlo)
+and arbitrary edge vectors **A** = (ax,ay,az), **B** = (bx,by,bz), and
+**C** = (cx,cy,cz).  So there are 12 parameters in total.
+
+A *restricted* triclinic box also has an origin (xlo,ylo,zlo), but its
+edge vectors are of the following restricted form: **A** =
+(xhi-xlo,0,0), **B** = (xy,yhi-ylo,0), **C** = (xz,yz,zhi-zlo).  So
+there are 9 parameters in total.  Note that the restricted form
+requires **A** to be along the x-axis, **B** to be in the xy plane
+with a y-component in the +y direction, and **C** to have its
+z-component in the +z direction.  Note that a restricted triclinic box
+is *right-handed* by construction since (**A** cross **B**) points in
+the direction of **C**.
+
+The *xy,xz,yz* values can be zero or positive or negative.  They are
+called "tilt factors" because they are the amount of displacement
+applied to edges of faces of an orthogonal box to change it into a
+restricted triclinic parallelepiped.
+
+.. note::
+
+   Any right-handed general triclinic box (i.e. solid-state crystal
+   basis vectors) can be rotated in 3d around its origin in order to
+   conform to the LAMMPS definition of a restricted triclinic box.
+   See the discussion in the next sub-section about general triclinic
+   simulation boxes in LAMMPS.
+
+Note that the :doc:`thermo_style custom <thermo_style>` command has
+keywords for outputting the various parameters that define the size
+and shape of orthogonal, restricted triclinic, and general triclinic
+simulation boxes.
+
+For orthogonal boxes there 6 thermo keywords (xlo,ylo,zlo) and
+(xhi,yhi,zhi).
+
+For restricted triclinic boxes there are 9 thermo keywords for
+(xlo,ylo,zlo), (xhi,yhi,zhi), and the (xy,xz,yz) tilt factors.
+
+For general triclinic boxes there are 12 thermo keywords for
+(xlo,ylo,zhi) and the components of the **A**, **B**, **C** edge
+vectors, namely (avecx,avecy,avecz), (bvecx,bvecy,bvecz), and
+(cvecx,cvecy,cvecz),
+
+The remainder of this doc page explains (a) how LAMMPS operates with
+general triclinic simulation boxes, (b) mathematical transformations
+between general and restricted triclinic boxes which may be useful
+when creating LAMMPS inputs or interpreting outputs for triclinic
+simulations, and (c) how LAMMPS uses tilt factors for restricted
+triclinic simulation boxes.
+
+----------
+
+General triclinic simulation boxes in LAMMPS
+""""""""""""""""""""""""""""""""""""""""""""
+
+LAMMPS allows specification of general triclinic simulation boxes with
+their atoms as a convenience for users who may be converting data from
+solid-state crystallographic representations or from DFT codes for
+input to LAMMPS.  Likewise it allows output of dump files, data files,
+and thermodynamic data (e.g. pressure tensor) in a general triclinic
+format.
+
+However internally, LAMMPS only uses restricted triclinic simulation
+boxes.  This is for parallel efficiency and to formulate partitioning
+of the simulation box across processors, neighbor list building, and
+inter-processor communication of per-atom data with methods similar to
+those used for orthogonal boxes.
+
+This means 4 things which are important to understand:
+
+* Input of a general triclinic system is immediately converted to a
+  restricted triclinic system.
+* If output of per-atom data for a general triclinic system is
+  requested (e.g. for atom coordinates in a dump file),
+  conversion from a restricted to general triclinic system is done at
+  the time of output.
+* The conversion of the simulation box and per-atom data from general
+  triclinic to restricted triclinic (and vice versa) is a 3d rotation
+  operation around an origin, which is the lower left corner of the
+  simulation box.  This means an input data file for a general
+  triclinic system should specify all per-atom quantities consistent
+  with the general triclinic box and its orientation relative to the
+  standard x,y,z coordinate axes.  For example, atom coordinates
+  should be inside the general triclinic simulation box defined by the
+  edge vectors **A**, **B**, **C** and its origin.  Likewise per-atom
+  velocities should be in directions consistent with the general
+  triclinic box orientation.  E.g. a velocity vector which will be in
+  the +x direction once LAMMPS converts from a general to restricted
+  triclinic box, should be specified in the data file in the direction
+  of the **A** edge vector.  See the :doc:`read_data <read_data>` doc
+  page for info on all the per-atom vector quantities to which this
+  rule applies when a data file for a general triclinic box is input.
+* If commands such as :doc:`write_data <write_data>` or :doc:`dump
+  custom <dump>` are used to output general triclinic information, it
+  is effectively the inverse of the operation described in the
+  preceding bullet.
+* Other LAMMPS commands such as :doc:`region <region>` or
+  :doc:`velocity <velocity>` or :doc:`set <set>`, operate on a
+  restricted triclinic system even if a general triclinic system was
+  defined initially.
+
+This is the list of commands which have general triclinic options:
+
+* :doc:`create_box <create_box>` - define a general triclinic box
+* :doc:`create_atoms <create_atoms>` - add atoms to a general triclinic box
+* :doc:`lattice <lattice>` - define a custom lattice consistent with the **A**, **B**, **C** edge vectors of a general triclinic box
+* :doc:`read_data <read_data>` - read a data file for a general triclinic system
+* :doc:`write_data <write_data>` - write a data file for a general triclinic system
+* :doc:`dump atom, dump custom <dump>` - output dump snapshots in general triclinic format
+* :doc:`dump_modify triclinic/general <dump_modify>` - select general triclinic format for dump output
+* :doc:`thermo_style <thermo_style>` - output the pressure tensor in
+  general triclinic format
+* :doc:`thermo_modify triclinic/general <thermo_modify>` - select general triclinic format for thermo output
+* :doc:`read_restart <read_restart>` - read a restart file for a general triclinic system
+* :doc:`write_restart <read_restart>` - write a restart file for a general triclinic system
+
+----------
+
+Transformation from general to restricted triclinic boxes
+"""""""""""""""""""""""""""""""""""""""""""""""""""""""""
+
+Let **A**,\ **B**,\ **C** be the right-handed edge vectors of a
+general triclinic simulation box.  The equivalent LAMMPS **a**,\
+**b**,\ **c** for a restricted triclinic box are a 3d rotation of
+**A**, **B**, and **C** and can be computed as follows:
 
 .. math::
 
@@ -54,23 +207,17 @@ rotation of **A**, **B**, and **C** and can be computed as follows:
   c_y = & \mathbf{C} \cdot \widehat{(\mathbf{A} \times \mathbf{B})} \times \mathbf{\hat{A}} \quad = \quad \frac{\mathbf{B} \cdot \mathbf{C} - b_x c_x}{b_y} \\
   c_z = & |\mathbf{C} \cdot \widehat{(\mathbf{A} \times \mathbf{B})}|\quad = \quad \sqrt{C^2 - {c_x}^2 - {c_y}^2}
 
-where A = \| **A** \| indicates the scalar length of **A**\ . The hat symbol (\^)
-indicates the corresponding unit vector. :math:`\beta` and :math:`\gamma` are angles
-between the vectors described below. Note that by construction,
-**a**, **b**, and **c** have strictly positive x, y, and z components, respectively.
-If it should happen that
-**A**, **B**, and **C** form a left-handed basis, then the above equations
-are not valid for **c**\ . In this case, it is necessary
-to first apply an inversion. This can be achieved
-by interchanging two basis vectors or by changing the sign of one of them.
+where A = \| **A** \| indicates the scalar length of **A**\ . The hat
+symbol (\^) indicates the corresponding unit vector. :math:`\beta` and
+:math:`\gamma` are angles between the **A**, **B**, **C** vectors
+as described below.
 
-For consistency, the same rotation/inversion applied to the basis vectors
-must also be applied to atom positions, velocities,
-and any other vector quantities.
-This can be conveniently achieved by first converting to
-fractional coordinates in the
-old basis and then converting to distance coordinates in the new basis.
-The transformation is given by the following equation:
+For consistency, the same rotation applied to the triclinic box edge
+vectors can also be applied to atom positions, velocities, and other
+vector quantities.  This can be conveniently achieved by first
+converting to fractional coordinates in the general triclinic
+coordinates and then converting to coordinates in the restricted
+triclinic basis.  The transformation is given by the following equation:
 
 .. math::
 
@@ -81,87 +228,24 @@ The transformation is given by the following equation:
       \mathbf{A \times B}
     \end{pmatrix} \cdot \mathbf{X}
 
-where *V* is the volume of the box, **X** is the original vector quantity and
-**x** is the vector in the LAMMPS basis.
+where *V* is the volume of the box (same in either basis), **X** is
+the fractional vector in the general triclinic basis and **x** is the
+resulting vector in the restricted triclinic basis.
 
-There is no requirement that a triclinic box be periodic in any
-dimension, though it typically should be in at least the second dimension
-of the tilt (y in xy) if you want to enforce a shift in periodic
-boundary conditions across that boundary.  Some commands that work
-with triclinic boxes, e.g. the :doc:`fix deform <fix_deform>` and :doc:`fix npt <fix_nh>` commands, require periodicity or non-shrink-wrap
-boundary conditions in specific dimensions.  See the command doc pages
-for details.
+----------
 
-The 9 parameters (xlo,xhi,ylo,yhi,zlo,zhi,xy,xz,yz) are defined at the
-time the simulation box is created.  This happens in one of 3 ways.
-If the :doc:`create_box <create_box>` command is used with a region of
-style *prism*, then a triclinic box is setup.  See the
-:doc:`region <region>` command for details.  If the
-:doc:`read_data <read_data>` command is used to define the simulation
-box, and the header of the data file contains a line with the "xy xz
-yz" keyword, then a triclinic box is setup.  See the
-:doc:`read_data <read_data>` command for details.  Finally, if the
-:doc:`read_restart <read_restart>` command reads a restart file which
-was written from a simulation using a triclinic box, then a triclinic
-box will be setup for the restarted simulation.
+Crystallographic general triclinic representation of a simulation box
+"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 
-Note that you can define a triclinic box with all 3 tilt factors =
-0.0, so that it is initially orthogonal.  This is necessary if the box
-will become non-orthogonal, e.g. due to the :doc:`fix npt <fix_nh>` or
-:doc:`fix deform <fix_deform>` commands.  Alternatively, you can use the
-:doc:`change_box <change_box>` command to convert a simulation box from
-orthogonal to triclinic and vice versa.
-
-As with orthogonal boxes, LAMMPS defines triclinic box size parameters
-lx,ly,lz where lx = xhi-xlo, and similarly in the y and z dimensions.
-The 9 parameters, as well as lx,ly,lz, can be output via the
-:doc:`thermo_style custom <thermo_style>` command.
-
-To avoid extremely tilted boxes (which would be computationally
-inefficient), LAMMPS normally requires that no tilt factor can skew
-the box more than half the distance of the parallel box length, which
-is the first dimension in the tilt factor (x for xz).  This is required
-both when the simulation box is created, e.g. via the
-:doc:`create_box <create_box>` or :doc:`read_data <read_data>` commands,
-as well as when the box shape changes dynamically during a simulation,
-e.g. via the :doc:`fix deform <fix_deform>` or :doc:`fix npt <fix_nh>`
-commands.
-
-For example, if xlo = 2 and xhi = 12, then the x box length is 10 and
-the xy tilt factor must be between -5 and 5.  Similarly, both xz and
-yz must be between -(xhi-xlo)/2 and +(yhi-ylo)/2.  Note that this is
-not a limitation, since if the maximum tilt factor is 5 (as in this
-example), then configurations with tilt = ..., -15, -5, 5, 15, 25,
-... are geometrically all equivalent.  If the box tilt exceeds this
-limit during a dynamics run (e.g. via the :doc:`fix deform <fix_deform>`
-command), then the box is "flipped" to an equivalent shape with a tilt
-factor within the bounds, so the run can continue.  See the :doc:`fix deform <fix_deform>` page for further details.
-
-One exception to this rule is if the first dimension in the tilt
-factor (x for xy) is non-periodic.  In that case, the limits on the
-tilt factor are not enforced, since flipping the box in that dimension
-does not change the atom positions due to non-periodicity.  In this
-mode, if you tilt the system to extreme angles, the simulation will
-simply become inefficient, due to the highly skewed simulation box.
-
-Box flips that may occur using the :doc:`fix deform <fix_deform>` or
-:doc:`fix npt <fix_nh>` commands can be turned off using the *flip no*
-option with either of the commands.
-
-Note that if a simulation box has a large tilt factor, LAMMPS will run
-less efficiently, due to the large volume of communication needed to
-acquire ghost atoms around a processor's irregular-shaped subdomain.
-For extreme values of tilt, LAMMPS may also lose atoms and generate an
-error.
-
-Triclinic crystal structures are often defined using three lattice
-constants *a*, *b*, and *c*, and three angles :math:`\alpha`,
-:math:`\beta`, and :math:`\gamma`. Note that in this nomenclature,
-the a, b, and c lattice constants are the scalar lengths of the edge
+General triclinic crystal structures are often defined using three
+lattice constants *a*, *b*, and *c*, and three angles :math:`\alpha`,
+:math:`\beta`, and :math:`\gamma`. Note that in this nomenclature, the
+a, b, and c lattice constants are the scalar lengths of the edge
 vectors **a**, **b**, and **c** defined above.  The relationship
 between these 6 quantities (a, b, c, :math:`\alpha`, :math:`\beta`,
-:math:`\gamma`) and the LAMMPS box sizes (lx,ly,lz) =
-(xhi-xlo,yhi-ylo,zhi-zlo) and tilt factors (xy,xz,yz) is as follows:
+:math:`\gamma`) and the LAMMPS restricted triclinic box sizes
+(lx,ly,lz) = (xhi-xlo,yhi-ylo,zhi-zlo) and tilt factors (xy,xz,yz) is
+as follows:
 
 .. math::
 
@@ -185,15 +269,19 @@ The inverse relationship can be written as follows:
 
 The values of *a*, *b*, *c*, :math:`\alpha` , :math:`\beta`, and
 :math:`\gamma` can be printed out or accessed by computes using the
-:doc:`thermo_style custom <thermo_style>` keywords
-*cella*, *cellb*, *cellc*, *cellalpha*, *cellbeta*, *cellgamma*,
-respectively.
+:doc:`thermo_style custom <thermo_style>` keywords *cella*, *cellb*,
+*cellc*, *cellalpha*, *cellbeta*, *cellgamma*, respectively.
+
+----------
+
+Output of restricted and general triclinic boxes in a dump file
+"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 
 As discussed on the :doc:`dump <dump>` command doc page, when the BOX
-BOUNDS for a snapshot is written to a dump file for a triclinic box,
-an orthogonal bounding box which encloses the triclinic simulation box
-is output, along with the 3 tilt factors (xy, xz, yz) of the triclinic
-box, formatted as follows:
+BOUNDS for a snapshot is written to a dump file for a restricted
+triclinic box, an orthogonal bounding box which encloses the triclinic
+simulation box is output, along with the 3 tilt factors (xy, xz, yz) of
+the restricted triclinic box, formatted as follows:
 
 .. parsed-literal::
 
@@ -203,7 +291,7 @@ box, formatted as follows:
    zlo_bound zhi_bound yz
 
 This bounding box is convenient for many visualization programs and is
-calculated from the 9 triclinic box parameters
+calculated from the 9 restricted triclinic box parameters
 (xlo,xhi,ylo,yhi,zlo,zhi,xy,xz,yz) as follows:
 
 .. parsed-literal::
@@ -216,22 +304,66 @@ calculated from the 9 triclinic box parameters
    zhi_bound = zhi
 
 These formulas can be inverted if you need to convert the bounding box
-back into the triclinic box parameters, e.g. xlo = xlo_bound -
-MIN(0.0,xy,xz,xy+xz).
+back into the restricted triclinic box parameters, e.g. xlo =
+xlo_bound - MIN(0.0,xy,xz,xy+xz).
 
-One use of triclinic simulation boxes is to model solid-state crystals
-with triclinic symmetry.  The :doc:`lattice <lattice>` command can be
-used with non-orthogonal basis vectors to define a lattice that will
-tile a triclinic simulation box via the
-:doc:`create_atoms <create_atoms>` command.
+----------
 
-A second use is to run Parrinello-Rahman dynamics via the :doc:`fix npt <fix_nh>` command, which will adjust the xy, xz, yz tilt
-factors to compensate for off-diagonal components of the pressure
-tensor.  The analog for an :doc:`energy minimization <minimize>` is
-the :doc:`fix box/relax <fix_box_relax>` command.
+Periodicity and tilt factors for triclinic simulation boxes
+"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 
-A third use is to shear a bulk solid to study the response of the
-material.  The :doc:`fix deform <fix_deform>` command can be used for
-this purpose.  It allows dynamic control of the xy, xz, yz tilt
-factors as a simulation runs.  This is discussed in the next section
-on non-equilibrium MD (NEMD) simulations.
+There is no requirement that a triclinic box be periodic in any
+dimension, though it typically should be in y or z if you wish to
+enforce a shift in coordinates due to periodic boundary conditions
+across the y or z boundaries.  See the doc page for the :doc:`boundary
+<boundary>` command for an explanation of shifted coordinates for
+restricted triclinic boxes which are periodic.
+
+Some commands that work with triclinic boxes, e.g. the :doc:`fix
+deform <fix_deform>` and :doc:`fix npt <fix_nh>` commands, require
+periodicity or non-shrink-wrap boundary conditions in specific
+dimensions.  See the command doc pages for details.
+
+A restricted triclinic box can be defined with all 3 tilt factors =
+0.0, so that it is initially orthogonal.  This is necessary if the box
+will become non-orthogonal, e.g. due to use of the :doc:`fix npt
+<fix_nh>` or :doc:`fix deform <fix_deform>` commands.  Alternatively,
+you can use the :doc:`change_box <change_box>` command to convert a
+simulation box from orthogonal to restricted triclinic and vice versa.
+
+.. note::
+
+   Highly tilted restricted triclinic simulation boxes can be
+   computationally inefficient.  This is 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.
+
+LAMMPS will issue a warning if you define a restricted triclinic box
+with a tilt factor which skews the box more than half the distance of
+the parallel box length, which is the first dimension in the tilt
+factor (e.g. x for xz).
+
+For example, if xlo = 2 and xhi = 12, then the x box length is 10 and
+the xy tilt factor should be between -5 and 5 to avoid the warning.
+Similarly, both xz and yz should be between -(xhi-xlo)/2 and
++(yhi-ylo)/2.  Note that these are not limitations, since if the
+maximum tilt factor is 5 (as in this example), then simulations boxes
+and atom configurations with tilt = ..., -15, -5, 5, 15, 25, ... are
+all geometrically equivalent.
+
+If the box tilt exceeds this limit during a dynamics run (e.g. due to
+the :doc:`fix deform <fix_deform>` command), then by default the box
+is "flipped" to an equivalent shape with a tilt factor within the
+warning bounds, and the run continues.  See the :doc:`fix deform
+<fix_deform>` page for further details.  Box flips that would normally
+occur using the :doc:`fix deform <fix_deform>` or :doc:`fix npt
+<fix_nh>` commands can be suppressed using the *flip no* option with
+either of the commands.
+
+One exception to box flipping is if the first dimension in the tilt
+factor (e.g. x for xy) is non-periodic.  In that case, the limits on
+the tilt factor are not enforced, since flipping the box in that
+dimension would not change the atom positions due to non-periodicity.
+In this mode, if the system tilts to large angles, the simulation will
+simply become inefficient, due to the highly skewed simulation box.

doc/src/Howto_type_labels.rst

@@ -14,16 +14,17 @@ wherever they appear in LAMMPS input or output files.  The total number
 Ntypes for each interaction is "locked in" when the simulation box
 is created.
 
-A recent addition to LAMMPS is the option to use strings - referred
-to as type labels - as an alternative.  Using type labels instead of
+A recent addition to LAMMPS is the option to use strings - referred to
+as type labels - as an alternative.  Using type labels instead of
 numeric types can be advantageous in various scenarios.  For example,
-type labels can make inputs more readable and generic (i.e. usable through
-the :doc:`include command <include>` for different systems with different
-numerical values assigned to types.  This generality also applies to
-other inputs like data files read by :doc:`read_data <read_data>` or
-molecule template files read by the :doc:`molecule <molecule>`
-command.  See below for a list of other commands that can use
-type labels in different ways.
+type labels can make inputs more readable and generic (i.e. usable
+through the :doc:`include command <include>` for different systems with
+different numerical values assigned to types.  This generality also
+applies to other inputs like data files read by :doc:`read_data
+<read_data>` or molecule template files read by the :doc:`molecule
+<molecule>` command.  A discussion of the current type label support can
+be found in :ref:`(Gissinger) <Typelabel24>`.  See below for a list of
+other commands that can use type labels in different ways.
 
 LAMMPS will *internally* continue to use numeric types, which means
 that many previous restrictions still apply.  For example, the total
@@ -124,3 +125,9 @@ between the files.  The creation of simulation-ready reaction templates
 for :doc:`fix bond/react <fix_bond_react>` is much simpler when using
 type labels, and results in templates that can be used without
 modification in multiple simulations or different systems.
+
+-----------
+
+.. _Typelabel24:
+
+**(Gissinger)** J. R. Gissinger, I. Nikiforov, Y. Afshar, B. Waters, M. Choi, D. S. Karls, A. Stukowski, W. Im, H. Heinz, A. Kohlmeyer, and E. B. Tadmor, J Phys Chem B, 128, 3282-3297 (2024).

doc/src/Install_git.rst

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

doc/src/Install_mac.rst

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

doc/src/Install_windows.rst

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

doc/src/Intro_citing.rst

@@ -47,6 +47,8 @@ In addition there are DOIs generated for individual stable releases:
 - 3 March 2020 version: `DOI:10.5281/zenodo.3726417 <https://dx.doi.org/10.5281/zenodo.3726417>`_
 - 29 October 2020 version: `DOI:10.5281/zenodo.4157471 <https://dx.doi.org/10.5281/zenodo.4157471>`_
 - 29 September 2021 version: `DOI:10.5281/zenodo.6386596 <https://dx.doi.org/10.5281/zenodo.6386596>`_
+- 23 June 2022 version: `DOI:10.5281/zenodo.10806836 <https://doi.org/10.5281/zenodo.10806836>`_
+- 2 August 2023 version: `DOI:10.5281/zenodo.10806852 <https://doi.org/10.5281/zenodo.10806852>`_
 
 Home page
 ^^^^^^^^^

doc/src/Intro_features.rst

@@ -29,7 +29,7 @@ General features
 * spatial decomposition of simulation domain for MPI parallelism
 * particle decomposition inside spatial decomposition for OpenMP and GPU parallelism
 * GPLv2 licensed open-source distribution
-* highly portable C++-11
+* highly portable C++-11 (optional packages may require C++17)
 * modular code with most functionality in optional packages
 * only depends on MPI library for basic parallel functionality, MPI stub for serial compilation
 * other libraries are optional and only required for specific packages
@@ -81,7 +81,7 @@ commands)
 * pairwise potentials: Lennard-Jones, Buckingham, Morse, Born-Mayer-Huggins, Yukawa, soft, Class II (COMPASS), hydrogen bond, harmonic, gaussian, tabulated, scripted
 * charged pairwise potentials: Coulombic, point-dipole
 * many-body potentials: EAM, Finnis/Sinclair, MEAM, MEAM+SW, EIM, EDIP, ADP, Stillinger-Weber, Tersoff, REBO, AIREBO, ReaxFF, COMB, Streitz-Mintmire, 3-body polymorphic, BOP, Vashishta
-* machine learning potentials: ACE, AGNI, GAP, Behler-Parrinello (N2P2), POD, RANN
+* machine learning potentials: ACE, AGNI, GAP, Behler-Parrinello (N2P2), POD, RANN, SNAP
 * interfaces to ML potentials distributed by external groups: ANI, ChIMES, DeepPot, HIPNN, MTP
 * long-range interactions for charge, point-dipoles, and LJ dispersion:  Ewald, Wolf, PPPM (similar to particle-mesh Ewald), MSM, ScaFaCoS
 * polarization models: :doc:`QEq <fix_qeq>`, :doc:`core/shell model <Howto_coreshell>`, :doc:`Drude dipole model <Howto_drude>`