Merge pull request #3818 from akohlmey/next_release

Update version strings for upcoming release

.github/CODEOWNERS

@@ -67,6 +67,7 @@ src/EXTRA-COMPUTE/compute_born_matrix.* @Bibobu @athomps
 src/MISC/*_tracker.*                @jtclemm
 src/MC/fix_gcmc.*                   @athomps
 src/MC/fix_sgcmc.*                  @athomps
+src/REPLICA/fix_pimd_langevin.*     @Yi-FanLi
 
 # core LAMMPS classes
 src/lammps.*              @sjplimp
@@ -150,12 +151,12 @@ tools/vim/*           @hammondkd
 unittest/*            @akohlmey
 
 # cmake
-cmake/*               @junghans @rbberger
+cmake/*               @rbberger
 cmake/Modules/LAMMPSInterfacePlugin.cmake @akohlmey
 cmake/Modules/MPI4WIN.cmake @akohlmey
 cmake/Modules/OpenCLLoader.cmake @akohlmey
-cmake/Modules/Packages/COLVARS.cmake @junghans @rbberger @giacomofiorin
-cmake/Modules/Packages/KIM.cmake @junghans @rbberger @ellio167
+cmake/Modules/Packages/COLVARS.cmake @rbberger @giacomofiorin
+cmake/Modules/Packages/KIM.cmake @rbberger @ellio167
 cmake/presets/*.cmake @akohlmey
 
 # python

SECURITY.md

@@ -32,17 +32,21 @@ for unicode characters and only all-ASCII source code is accepted.
 
 LAMMPS follows a continuous release development model.  We aim to keep
 the development version (`develop` branch) always fully functional and
-employ a variety of automatic testing procedures to detect failures
-of existing functionality from adding or modifying features.  Most of
-those tests are run on pull requests *before* merging to the `develop`
-branch.  The `develop` branch is protected, so all changes *must* be
-submitted as a pull request and thus cannot avoid the automated tests.
+employ a variety of automatic testing procedures to detect failures of
+existing functionality from adding or modifying features.  Most of those
+tests are run on pull requests and must be passed *before* merging to
+the `develop` branch.  The `develop` branch is protected, so all changes
+*must* be submitted as a pull request and thus cannot avoid the
+automated tests.
 
 Additional tests are run *after* merging.  Before releases are made
 *all* tests must have cleared.  Then a release tag is applied and the
-`release` branch is fast-forwarded to that tag.  This is often referred
-to as a patch release. Bug fixes and updates are
-applied first to the `develop` branch.  Later, they appear in the `release`
-branch when the next patch release occurs.
-For stable releases, selected bug fixes, updates, and new functionality
-are pushed to the `stable` branch and a new stable tag is applied.
+`release` branch is fast-forwarded to that tag.  This is referred to to
+as a "feature release".  Bug fixes and updates are applied first to the
+`develop` branch.  Later, they appear in the `release` branch when the
+next patch release occurs.  For stable releases, backported bug fixes
+and infrastructure updates are first applied to the `maintenance` branch
+and then merged to `stable` and published as "updates".  For a new
+stable release the `stable` branch is updated to the corresponding state
+of the `release` branch and a new stable tag is applied in addition to
+the release tag.

cmake/CMakeLists.txt

@@ -257,7 +257,6 @@ set(STANDARD_PACKAGES
   KIM
   KSPACE
   LATBOLTZ
-  LATTE
   LEPTON
   MACHDYN
   MANIFOLD
@@ -441,7 +440,7 @@ if(BUILD_OMP)
   target_link_libraries(lmp PRIVATE OpenMP::OpenMP_CXX)
 endif()
 
-if(PKG_MSCG OR PKG_ATC OR PKG_AWPMD OR PKG_ML-QUIP OR PKG_ML-POD OR PKG_LATTE OR PKG_ELECTRODE)
+if(PKG_MSCG OR 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)
@@ -521,7 +520,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 LATTE MSCG COMPRESS ML-PACE LEPTON)
+        PLUMED QMMM ML-QUIP SCAFACOS MACHDYN VTK KIM MSCG COMPRESS ML-PACE LEPTON)
   if(PKG_${PKG_WITH_INCL})
     include(Packages/${PKG_WITH_INCL})
   endif()
@@ -538,7 +537,10 @@ set(CMAKE_TUNE_FLAGS "${CMAKE_TUNE_DEFAULT}" CACHE STRING "Compiler and machine
 separate_arguments(CMAKE_TUNE_FLAGS)
 foreach(_FLAG ${CMAKE_TUNE_FLAGS})
   target_compile_options(lammps PRIVATE ${_FLAG})
+  # skip these flags when linking the main executable
+  if(NOT (("${_FLAG}" STREQUAL "-Xcudafe") OR (("${_FLAG}" STREQUAL "--diag_suppress=unrecognized_pragma"))))
     target_compile_options(lmp PRIVATE ${_FLAG})
+  endif()
 endforeach()
 ########################################################################
 # Basic system tests (standard libraries, headers, functions, types)   #
@@ -838,9 +840,8 @@ if(BUILD_SHARED_LIBS)
   set(LIBLAMMPS_SHARED_BINARY ${MY_BUILD_DIR}/liblammps${LAMMPS_MACHINE}${CMAKE_SHARED_LIBRARY_SUFFIX})
   if(Python_EXECUTABLE)
     add_custom_target(
-      install-python ${CMAKE_COMMAND} -E remove_directory build
-      COMMAND ${Python_EXECUTABLE} ${LAMMPS_PYTHON_DIR}/install.py -p ${LAMMPS_PYTHON_DIR}/lammps
-              -l ${LIBLAMMPS_SHARED_BINARY} -w ${MY_BUILD_DIR}
+      install-python ${Python_EXECUTABLE} ${LAMMPS_PYTHON_DIR}/install.py -p ${LAMMPS_PYTHON_DIR}/lammps
+      -l ${LIBLAMMPS_SHARED_BINARY} -w ${MY_BUILD_DIR} -v ${LAMMPS_SOURCE_DIR}/version.h
       COMMENT "Installing LAMMPS Python module")
   else()
     add_custom_target(
@@ -853,35 +854,6 @@ else()
     ${CMAKE_COMMAND} -E echo "Must build LAMMPS as a shared library to use the Python module")
 endif()
 
-###############################################################################
-# Add LAMMPS python module to "install" target. This is taylored for building
-# LAMMPS for package managers and with different prefix settings.
-# This requires either a shared library or that the PYTHON package is included.
-###############################################################################
-if(BUILD_SHARED_LIBS OR PKG_PYTHON)
-  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()
-  if(Python_EXECUTABLE)
-    file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/python/lib)
-    file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/python/src)
-    file(COPY ${LAMMPS_SOURCE_DIR}/version.h  DESTINATION ${CMAKE_BINARY_DIR}/python/src)
-    file(COPY ${LAMMPS_PYTHON_DIR}/README ${LAMMPS_PYTHON_DIR}/pyproject.toml ${LAMMPS_PYTHON_DIR}/setup.py ${LAMMPS_PYTHON_DIR}/lammps  DESTINATION ${CMAKE_BINARY_DIR}/python/lib)
-    install(CODE "if(\"\$ENV{DESTDIR}\" STREQUAL \"\")\n execute_process(COMMAND ${Python_EXECUTABLE} -m pip install -v ${CMAKE_BINARY_DIR}/python/lib --prefix=${CMAKE_INSTALL_PREFIX})\n else()\n execute_process(COMMAND ${Python_EXECUTABLE} -m pip install -v ${CMAKE_BINARY_DIR}/python/lib --prefix=${CMAKE_INSTALL_PREFIX} --root=\$ENV{DESTDIR})\n endif()")
-  endif()
-endif()
-
 include(Testing)
 include(CodeCoverage)
 include(CodingStandard)

cmake/Modules/CodingStandard.cmake

@@ -5,6 +5,10 @@ if(CMAKE_VERSION VERSION_LESS 3.12)
         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)
 endif()
 

cmake/Modules/DetectHIPInstallation.cmake

@@ -0,0 +1,16 @@
+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")
+    else()
+        set(ROCM_PATH $ENV{ROCM_PATH} CACHE PATH "Path to ROCm installation")
+    endif()
+endif()
+list(APPEND CMAKE_PREFIX_PATH ${HIP_PATH} ${ROCM_PATH})

cmake/Modules/Documentation.cmake

@@ -4,14 +4,18 @@
 option(BUILD_DOC "Build LAMMPS HTML documentation" OFF)
 
 if(BUILD_DOC)
-  # Sphinx 3.x requires at least Python 3.5
+  # Current Sphinx versions require at least Python 3.8
   if(CMAKE_VERSION VERSION_LESS 3.12)
-    find_package(PythonInterp 3.5 REQUIRED)
+    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.5)
-      message(FATAL_ERROR "Python 3.5 and up is required to build the HTML documentation")
+    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)
   endif()

cmake/Modules/LAMMPSInterfacePlugin.cmake

@@ -88,6 +88,18 @@ function(get_lammps_version version_header variable)
     set(${variable} "${date}" PARENT_SCOPE)
 endfunction()
 
+# determine canonical URL for downloading backup copy from download.lammps.org/thirdparty
+function(GetFallbackURL input output)
+  string(REPLACE "_URL" "" _tmp ${input})
+  string(TOLOWER ${_tmp} libname)
+  string(REGEX REPLACE "^https://.*/([^/]+gz)" "${LAMMPS_THIRDPARTY_URL}/${libname}-\\1" newurl "${${input}}")
+  if ("${newurl}" STREQUAL "${${input}}")
+    set(${output} "" PARENT_SCOPE)
+  else()
+    set(${output} ${newurl} PARENT_SCOPE)
+  endif()
+endfunction(GetFallbackURL)
+
 #################################################################################
 # LAMMPS C++ interface. We only need the header related parts except on windows.
 add_library(lammps INTERFACE)

cmake/Modules/LAMMPSUtils.cmake

@@ -152,13 +152,14 @@ endfunction(FetchPotentials)
 # set CMAKE_LINUX_DISTRO and CMAKE_DISTRO_VERSION on Linux
 if((CMAKE_SYSTEM_NAME STREQUAL "Linux") AND (EXISTS /etc/os-release))
   file(STRINGS /etc/os-release distro REGEX "^NAME=")
-  string(REGEX REPLACE "NAME=\"?([^\"]*)\"?" "\\1" distro "${distro}")
+  string(REGEX REPLACE "NAME=\"?([^ ]+).*\"?" "\\1" distro "${distro}")
   file(STRINGS /etc/os-release disversion REGEX "^VERSION_ID=")
   string(REGEX REPLACE "VERSION_ID=\"?([^\"]*)\"?" "\\1" disversion "${disversion}")
   set(CMAKE_LINUX_DISTRO ${distro})
   set(CMAKE_DISTRO_VERSION ${disversion})
 endif()
 
+# determine canonical URL for downloading backup copy from download.lammps.org/thirdparty
 function(GetFallbackURL input output)
   string(REPLACE "_URL" "" _tmp ${input})
   string(TOLOWER ${_tmp} libname)

cmake/Modules/Packages/GPU.cmake

@@ -60,9 +60,9 @@ if(GPU_API STREQUAL "CUDA")
   option(CUDA_MPS_SUPPORT "Enable tweaks to support CUDA Multi-process service (MPS)" OFF)
   if(CUDA_MPS_SUPPORT)
     if(CUDPP_OPT)
-      message(FATAL_ERROR "Must use -DCUDPP_OPT=OFF with -DGPU_CUDA_MPS_SUPPORT=ON")
+      message(FATAL_ERROR "Must use -DCUDPP_OPT=OFF with -DCUDA_MPS_SUPPORT=ON")
     endif()
-    set(GPU_CUDA_MPS_FLAGS "-DCUDA_PROXY")
+    set(GPU_CUDA_MPS_FLAGS "-DCUDA_MPS_SUPPORT")
   endif()
 
   set(GPU_ARCH "sm_50" CACHE STRING "LAMMPS GPU CUDA SM primary architecture (e.g. sm_60)")
@@ -98,9 +98,11 @@ if(GPU_API STREQUAL "CUDA")
   # comparison chart according to: https://en.wikipedia.org/wiki/CUDA#GPUs_supported
   if(CUDA_VERSION VERSION_LESS 8.0)
     message(FATAL_ERROR "CUDA Toolkit version 8.0 or later is required")
-  elseif(CUDA_VERSION VERSION_GREATER_EQUAL "12.0")
+  elseif(CUDA_VERSION VERSION_GREATER_EQUAL "13.0")
     message(WARNING "Untested CUDA Toolkit version ${CUDA_VERSION}. Use at your own risk")
     set(GPU_CUDA_GENCODE "-arch=all")
+  elseif(CUDA_VERSION VERSION_GREATER_EQUAL "12.0")
+    set(GPU_CUDA_GENCODE "-arch=all")
   else()
     # Kepler (GPU Arch 3.0) is supported by CUDA 5 to CUDA 10.2
     if((CUDA_VERSION VERSION_GREATER_EQUAL "5.0") AND (CUDA_VERSION VERSION_LESS "11.0"))
@@ -175,8 +177,6 @@ if(GPU_API STREQUAL "CUDA")
     target_compile_definitions(gpu PRIVATE -DUSE_CUDPP)
   endif()
 
-  target_link_libraries(lammps PRIVATE gpu)
-
   add_executable(nvc_get_devices ${LAMMPS_LIB_SOURCE_DIR}/gpu/geryon/ucl_get_devices.cpp)
   target_compile_definitions(nvc_get_devices PRIVATE -DUCL_CUDADR)
   target_link_libraries(nvc_get_devices PRIVATE ${CUDA_LIBRARIES} ${CUDA_CUDA_LIBRARY})
@@ -249,29 +249,14 @@ elseif(GPU_API STREQUAL "OPENCL")
   else()
     target_compile_definitions(gpu PRIVATE -DMPI_GERYON -DGERYON_NUMA_FISSION -DUCL_NO_EXIT)
   endif()
-  target_link_libraries(lammps PRIVATE gpu)
 
   add_executable(ocl_get_devices ${LAMMPS_LIB_SOURCE_DIR}/gpu/geryon/ucl_get_devices.cpp)
   target_compile_definitions(ocl_get_devices PRIVATE -DUCL_OPENCL)
   target_link_libraries(ocl_get_devices PRIVATE OpenCL::OpenCL)
   add_dependencies(ocl_get_devices OpenCL::OpenCL)
+
 elseif(GPU_API STREQUAL "HIP")
-  if(NOT DEFINED HIP_PATH)
-      if(NOT DEFINED ENV{HIP_PATH})
-          message(FATAL_ERROR "GPU_API=HIP 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")
-      else()
-          set(ROCM_PATH $ENV{ROCM_PATH} CACHE PATH "Path to ROCm installation")
-      endif()
-  endif()
-  list(APPEND CMAKE_PREFIX_PATH ${HIP_PATH} ${ROCM_PATH})
+  include(DetectHIPInstallation)
   find_package(hip REQUIRED)
   option(HIP_USE_DEVICE_SORT "Use GPU sorting" ON)
 
@@ -285,7 +270,7 @@ elseif(GPU_API STREQUAL "HIP")
 
   set(ENV{HIP_PLATFORM} ${HIP_PLATFORM})
 
-  if(HIP_PLATFORM STREQUAL "hcc" OR HIP_PLATFORM STREQUAL "amd")
+  if(HIP_PLATFORM STREQUAL "amd")
     set(HIP_ARCH "gfx906" CACHE STRING "HIP target architecture")
   elseif(HIP_PLATFORM STREQUAL "spirv")
     set(HIP_ARCH "spirv" CACHE STRING "HIP target architecture")
@@ -358,7 +343,7 @@ elseif(GPU_API STREQUAL "HIP")
     set(CUBIN_FILE   "${LAMMPS_LIB_BINARY_DIR}/gpu/${CU_NAME}.cubin")
     set(CUBIN_H_FILE "${LAMMPS_LIB_BINARY_DIR}/gpu/${CU_NAME}_cubin.h")
 
-    if(HIP_PLATFORM STREQUAL "hcc" OR HIP_PLATFORM STREQUAL "amd")
+    if(HIP_PLATFORM STREQUAL "amd")
         configure_file(${CU_FILE} ${CU_CPP_FILE} COPYONLY)
 
         if(HIP_COMPILER STREQUAL "clang")
@@ -412,7 +397,8 @@ elseif(GPU_API STREQUAL "HIP")
       set_property(TARGET gpu PROPERTY CXX_STANDARD 14)
     endif()
     # add hipCUB
-    target_include_directories(gpu PRIVATE ${HIP_ROOT_DIR}/../include)
+    find_package(hipcub REQUIRED)
+    target_link_libraries(gpu PRIVATE hip::hipcub)
     target_compile_definitions(gpu PRIVATE -DUSE_HIP_DEVICE_SORT)
 
     if(HIP_PLATFORM STREQUAL "nvcc")
@@ -461,35 +447,25 @@ elseif(GPU_API STREQUAL "HIP")
 
   add_executable(hip_get_devices ${LAMMPS_LIB_SOURCE_DIR}/gpu/geryon/ucl_get_devices.cpp)
   target_compile_definitions(hip_get_devices PRIVATE -DUCL_HIP)
-  target_link_libraries(hip_get_devices hip::host)
+  target_link_libraries(hip_get_devices PRIVATE hip::host)
 
   if(HIP_PLATFORM STREQUAL "nvcc")
     target_compile_definitions(gpu PRIVATE -D__HIP_PLATFORM_NVCC__)
-    target_include_directories(gpu PRIVATE ${HIP_ROOT_DIR}/../include)
     target_include_directories(gpu PRIVATE ${CUDA_INCLUDE_DIRS})
     target_link_libraries(gpu PRIVATE ${CUDA_LIBRARIES} ${CUDA_CUDA_LIBRARY})
 
     target_compile_definitions(hip_get_devices PRIVATE -D__HIP_PLATFORM_NVCC__)
-    target_include_directories(hip_get_devices PRIVATE ${HIP_ROOT_DIR}/include)
     target_include_directories(hip_get_devices PRIVATE ${CUDA_INCLUDE_DIRS})
     target_link_libraries(hip_get_devices PRIVATE ${CUDA_LIBRARIES} ${CUDA_CUDA_LIBRARY})
-  elseif(HIP_PLATFORM STREQUAL "hcc")
-    target_compile_definitions(gpu PRIVATE -D__HIP_PLATFORM_HCC__)
-    target_include_directories(gpu PRIVATE ${HIP_ROOT_DIR}/../include)
-
-    target_compile_definitions(hip_get_devices PRIVATE -D__HIP_PLATFORM_HCC__)
-    target_include_directories(hip_get_devices PRIVATE ${HIP_ROOT_DIR}/../include)
-  elseif(HIP_PLATFORM STREQUAL "amd")
-    target_compile_definitions(gpu PRIVATE -D__HIP_PLATFORM_AMD__)
-    target_include_directories(gpu PRIVATE ${HIP_ROOT_DIR}/../include)
-
-    target_compile_definitions(hip_get_devices PRIVATE -D__HIP_PLATFORM_AMD__)
-    target_include_directories(hip_get_devices PRIVATE ${HIP_ROOT_DIR}/../include)
   endif()
-
-  target_link_libraries(lammps PRIVATE gpu)
 endif()
 
+if(BUILD_OMP)
+  find_package(OpenMP COMPONENTS CXX REQUIRED)
+  target_link_libraries(gpu PRIVATE OpenMP::OpenMP_CXX)
+endif()
+target_link_libraries(lammps PRIVATE gpu)
+
 set_property(GLOBAL PROPERTY "GPU_SOURCES" "${GPU_SOURCES}")
 # detect styles which have a GPU version
 RegisterStylesExt(${GPU_SOURCES_DIR} gpu GPU_SOURCES)

cmake/Modules/Packages/KIM.cmake

@@ -19,7 +19,7 @@ if(CURL_FOUND)
     target_compile_definitions(lammps PRIVATE -DLMP_NO_SSL_CHECK)
   endif()
 endif()
-set(KIM_EXTRA_UNITTESTS OFF CACHE STRING "Set extra unit tests verbose mode on/off. If on, extra tests are included.")
+option(KIM_EXTRA_UNITTESTS "Enable extra unit tests for the KIM package." OFF)
 mark_as_advanced(KIM_EXTRA_UNITTESTS)
 find_package(PkgConfig QUIET)
 set(DOWNLOAD_KIM_DEFAULT ON)

cmake/Modules/Packages/KOKKOS.cmake

@@ -16,8 +16,8 @@ if(Kokkos_ENABLE_OPENMP)
   if(NOT BUILD_OMP)
     message(FATAL_ERROR "Must enable BUILD_OMP with Kokkos_ENABLE_OPENMP")
   else()
-    # NVHPC 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"))
+    # 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()
@@ -49,8 +49,8 @@ if(DOWNLOAD_KOKKOS)
   list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_CXX_EXTENSIONS=${CMAKE_CXX_EXTENSIONS}")
   list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}")
   include(ExternalProject)
-  set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/3.7.01.tar.gz" CACHE STRING "URL for KOKKOS tarball")
-  set(KOKKOS_MD5 "f140e02b826223b1045207d9bc10d404" CACHE STRING "MD5 checksum of KOKKOS tarball")
+  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")
   mark_as_advanced(KOKKOS_URL)
   mark_as_advanced(KOKKOS_MD5)
   GetFallbackURL(KOKKOS_URL KOKKOS_FALLBACK)
@@ -72,13 +72,11 @@ if(DOWNLOAD_KOKKOS)
   set_target_properties(LAMMPS::KOKKOSCONTAINERS PROPERTIES
     IMPORTED_LOCATION "${INSTALL_DIR}/lib/libkokkoscontainers.a")
   target_link_libraries(lammps PRIVATE LAMMPS::KOKKOSCORE LAMMPS::KOKKOSCONTAINERS)
-  target_link_libraries(lmp PRIVATE LAMMPS::KOKKOSCORE LAMMPS::KOKKOSCONTAINERS)
   add_dependencies(LAMMPS::KOKKOSCORE kokkos_build)
   add_dependencies(LAMMPS::KOKKOSCONTAINERS kokkos_build)
 elseif(EXTERNAL_KOKKOS)
-  find_package(Kokkos 3.7.01 REQUIRED CONFIG)
+  find_package(Kokkos 3.7.02 REQUIRED CONFIG)
   target_link_libraries(lammps PRIVATE Kokkos::kokkos)
-  target_link_libraries(lmp PRIVATE Kokkos::kokkos)
 else()
   set(LAMMPS_LIB_KOKKOS_SRC_DIR ${LAMMPS_LIB_SOURCE_DIR}/kokkos)
   set(LAMMPS_LIB_KOKKOS_BIN_DIR ${LAMMPS_LIB_BINARY_DIR}/kokkos)
@@ -98,7 +96,6 @@ else()
                           ${LAMMPS_LIB_KOKKOS_BIN_DIR})
   target_include_directories(lammps PRIVATE ${Kokkos_INCLUDE_DIRS})
   target_link_libraries(lammps PRIVATE kokkos)
-  target_link_libraries(lmp PRIVATE kokkos)
   if(BUILD_SHARED_LIBS_WAS_ON)
     set(BUILD_SHARED_LIBS ON)
   endif()
@@ -124,6 +121,11 @@ set(KOKKOS_PKG_SOURCES ${KOKKOS_PKG_SOURCES_DIR}/kokkos.cpp
                        ${KOKKOS_PKG_SOURCES_DIR}/domain_kokkos.cpp
                        ${KOKKOS_PKG_SOURCES_DIR}/modify_kokkos.cpp)
 
+# fix wall/gran has been refactored in an incompatible way. Use old version of base class for now
+if(PKG_GRANULAR)
+  list(APPEND KOKKOS_PKG_SOURCES ${KOKKOS_PKG_SOURCES_DIR}/fix_wall_gran_old.cpp)
+endif()
+
 if(PKG_KSPACE)
   list(APPEND KOKKOS_PKG_SOURCES ${KOKKOS_PKG_SOURCES_DIR}/fft3d_kokkos.cpp
                                  ${KOKKOS_PKG_SOURCES_DIR}/grid3d_kokkos.cpp
@@ -135,8 +137,10 @@ if(PKG_KSPACE)
     endif()
   elseif(Kokkos_ENABLE_HIP)
     if(NOT (FFT STREQUAL "KISS"))
+      include(DetectHIPInstallation)
+      find_package(hipfft REQUIRED)
       target_compile_definitions(lammps PRIVATE -DFFT_HIPFFT)
-      target_link_libraries(lammps PRIVATE hipfft)
+      target_link_libraries(lammps PRIVATE hip::hipfft)
     endif()
   endif()
 endif()

cmake/Modules/Packages/LATTE.cmake

@@ -1,54 +0,0 @@
-enable_language(Fortran)
-
-# using lammps in a super-build setting
-if(TARGET LATTE::latte)
-  target_link_libraries(lammps PRIVATE LATTE::latte)
-  return()
-endif()
-
-find_package(LATTE 1.2.2 CONFIG)
-if(LATTE_FOUND)
-  set(DOWNLOAD_LATTE_DEFAULT OFF)
-else()
-  set(DOWNLOAD_LATTE_DEFAULT ON)
-endif()
-option(DOWNLOAD_LATTE "Download the LATTE library instead of using an already installed one" ${DOWNLOAD_LATTE_DEFAULT})
-if(DOWNLOAD_LATTE)
-  message(STATUS "LATTE download requested - we will build our own")
-  set(LATTE_URL "https://github.com/lanl/LATTE/archive/v1.2.2.tar.gz" CACHE STRING "URL for LATTE tarball")
-  set(LATTE_MD5 "820e73a457ced178c08c71389a385de7" CACHE STRING "MD5 checksum of LATTE tarball")
-  mark_as_advanced(LATTE_URL)
-  mark_as_advanced(LATTE_MD5)
-  GetFallbackURL(LATTE_URL LATTE_FALLBACK)
-
-  # CMake cannot pass BLAS or LAPACK library variable to external project if they are a list
-  list(LENGTH BLAS_LIBRARIES} NUM_BLAS)
-  list(LENGTH LAPACK_LIBRARIES NUM_LAPACK)
-  if((NUM_BLAS GREATER 1) OR (NUM_LAPACK GREATER 1) AND NOT USE_INTERNAL_LINALG)
-    message(FATAL_ERROR "Cannot compile downloaded LATTE library due to a technical limitation. "
-                        "Try to configure LAMMPS with '-D USE_INTERNAL_LINALG=on' added as a workaround.")
-  endif()
-
-  include(ExternalProject)
-  ExternalProject_Add(latte_build
-    URL     ${LATTE_URL} ${LATTE_FALLBACK}
-    URL_MD5 ${LATTE_MD5}
-    SOURCE_SUBDIR cmake
-    CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR> ${CMAKE_REQUEST_PIC} -DCMAKE_INSTALL_LIBDIR=lib
-    -DBLAS_LIBRARIES=${BLAS_LIBRARIES} -DLAPACK_LIBRARIES=${LAPACK_LIBRARIES}
-    -DCMAKE_Fortran_COMPILER=${CMAKE_Fortran_COMPILER} -DCMAKE_Fortran_FLAGS=${CMAKE_Fortran_FLAGS}
-    -DCMAKE_Fortran_FLAGS_${BTYPE}=${CMAKE_Fortran_FLAGS_${BTYPE}} -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
-    -DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM} -DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}
-    BUILD_BYPRODUCTS <INSTALL_DIR>/lib/liblatte.a
-  )
-  ExternalProject_get_property(latte_build INSTALL_DIR)
-  add_library(LAMMPS::LATTE UNKNOWN IMPORTED)
-  set_target_properties(LAMMPS::LATTE PROPERTIES
-    IMPORTED_LOCATION "${INSTALL_DIR}/lib/liblatte.a"
-    INTERFACE_LINK_LIBRARIES "${LAPACK_LIBRARIES}")
-  target_link_libraries(lammps PRIVATE LAMMPS::LATTE)
-  add_dependencies(LAMMPS::LATTE latte_build)
-else()
-  find_package(LATTE 1.2.2 REQUIRED CONFIG)
-  target_link_libraries(lammps PRIVATE LATTE::latte)
-endif()

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.12.tar.gz" CACHE STRING "URL for MDI tarball")
-  set(MDI_MD5 "7a222353ae8e03961d5365e6cd48baee" CACHE STRING "MD5 checksum for MDI tarball")
+  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")
   mark_as_advanced(MDI_URL)
   mark_as_advanced(MDI_MD5)
   GetFallbackURL(MDI_URL MDI_FALLBACK)

cmake/Modules/Packages/MSCG.cmake

@@ -7,8 +7,8 @@ else()
 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/1.7.3.1.tar.gz" CACHE STRING "URL for MSCG tarball")
-  set(MSCG_MD5 "8c45e269ee13f60b303edd7823866a91" CACHE STRING "MD5 checksum of MSCG tarball")
+  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)
 

cmake/Modules/Packages/PLUMED.cmake

@@ -1,11 +1,91 @@
-set(PLUMED_MODE "static" CACHE STRING "Linkage mode for Plumed2 library")
-set(PLUMED_MODE_VALUES static shared runtime)
-set_property(CACHE PLUMED_MODE PROPERTY STRINGS ${PLUMED_MODE_VALUES})
-validate_option(PLUMED_MODE PLUMED_MODE_VALUES)
-string(TOUPPER ${PLUMED_MODE} PLUMED_MODE)
+# Plumed2 support for PLUMED package
 
-set(PLUMED_LINK_LIBS)
-if(PLUMED_MODE STREQUAL "STATIC")
+if(BUILD_MPI)
+  set(PLUMED_CONFIG_MPI "--enable-mpi")
+  set(PLUMED_CONFIG_CC  ${CMAKE_MPI_C_COMPILER})
+  set(PLUMED_CONFIG_CXX  ${CMAKE_MPI_CXX_COMPILER})
+  set(PLUMED_CONFIG_CPP "-I ${MPI_CXX_INCLUDE_PATH}")
+  set(PLUMED_CONFIG_LIB "${MPI_CXX_LIBRARIES}")
+  set(PLUMED_CONFIG_DEP "mpi4win_build")
+else()
+  set(PLUMED_CONFIG_MPI "--disable-mpi")
+  set(PLUMED_CONFIG_CC  ${CMAKE_C_COMPILER})
+  set(PLUMED_CONFIG_CXX  ${CMAKE_CXX_COMPILER})
+  set(PLUMED_CONFIG_CPP "")
+  set(PLUMED_CONFIG_LIB "")
+  set(PLUMED_CONFIG_DEP "")
+endif()
+if(BUILD_OMP)
+  set(PLUMED_CONFIG_OMP "--enable-openmp")
+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"
+  CACHE STRING "URL for PLUMED tarball")
+set(PLUMED_MD5 "599092b6a0aa6fff992612537ad98994" CACHE STRING "MD5 checksum of PLUMED tarball")
+
+mark_as_advanced(PLUMED_URL)
+mark_as_advanced(PLUMED_MD5)
+GetFallbackURL(PLUMED_URL PLUMED_FALLBACK)
+
+if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND (CMAKE_CROSSCOMPILING))
+  if(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
+    set(CROSS_CONFIGURE mingw64-configure)
+  elseif(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86")
+    set(CROSS_CONFIGURE mingw32-configure)
+  else()
+    message(FATAL_ERROR "Unsupported target system: ${CMAKE_SYSTEM_NAME}/${CMAKE_SYSTEM_PROCESSOR}")
+  endif()
+  message(STATUS "Downloading and cross-compiling Plumed2 for ${CMAKE_SYSTEM_NAME}/${CMAKE_SYSTEM_PROCESSOR} with ${CROSS_CONFIGURE}")
+  include(ExternalProject)
+  ExternalProject_Add(plumed_build
+    URL     ${PLUMED_URL} ${PLUMED_FALLBACK}
+    URL_MD5 ${PLUMED_MD5}
+    BUILD_IN_SOURCE 1
+    CONFIGURE_COMMAND ${CROSS_CONFIGURE} --disable-shared --disable-bsymbolic
+                                         --disable-python --enable-cxx=11
+                                         --enable-modules=-adjmat:+crystallization:-dimred:+drr:+eds:-fisst:+funnel:+logmfd:+manyrestraints:+maze:+opes:+multicolvar:-pamm:-piv:+s2cm:-sasa:-ves
+                                         ${PLUMED_CONFIG_OMP}
+                                         ${PLUMED_CONFIG_MPI}
+                                         CXX=${PLUMED_CONFIG_CXX}
+                                         CC=${PLUMED_CONFIG_CC}
+                                         CPPFLAGS=${PLUMED_CONFIG_CPP}
+                                         LIBS=${PLUMED_CONFIG_LIB}
+    INSTALL_COMMAND ""
+    BUILD_BYPRODUCTS "<SOURCE_DIR>/src/lib/install/libplumed.a" "<SOURCE_DIR>/src/lib/install/plumed.exe"
+    DEPENDS "${PLUMED_MPI_CONFIG_DEP}"
+  )
+  ExternalProject_Get_Property(plumed_build SOURCE_DIR)
+  set(PLUMED_BUILD_DIR ${SOURCE_DIR})
+  set(PLUMED_INSTALL_DIR ${PLUMED_BUILD_DIR}/src/lib/install)
+  file(MAKE_DIRECTORY ${PLUMED_BUILD_DIR}/src/include)
+
+  add_library(LAMMPS::PLUMED UNKNOWN IMPORTED)
+  add_dependencies(LAMMPS::PLUMED plumed_build)
+  set_target_properties(LAMMPS::PLUMED PROPERTIES
+    IMPORTED_LOCATION "${PLUMED_INSTALL_DIR}/libplumed.a"
+    INTERFACE_LINK_LIBRARIES "-Wl,--image-base -Wl,0x10000000 -lfftw3 -lz  -fstack-protector -lssp -fopenmp"
+    INTERFACE_INCLUDE_DIRECTORIES "${PLUMED_BUILD_DIR}/src/include")
+
+  add_custom_target(plumed_copy ALL ${CMAKE_COMMAND} -E rm -rf ${CMAKE_BINARY_DIR}/plumed.exe ${CMAKE_BINARY_DIR}/plumed_patches
+    COMMAND ${CMAKE_COMMAND} -E copy ${PLUMED_INSTALL_DIR}/plumed.exe ${CMAKE_BINARY_DIR}/plumed.exe
+    COMMAND ${CMAKE_COMMAND} -E copy_directory ${PLUMED_BUILD_DIR}/patches ${CMAKE_BINARY_DIR}/patches
+    BYPRODUCTS ${CMAKE_BINARY_DIR}/plumed.exe ${CMAKE_BINARY_DIR}/patches
+    DEPENDS plumed_build
+    COMMENT "Copying Plumed files"
+  )
+
+else()
+
+  set(PLUMED_MODE "static" CACHE STRING "Linkage mode for Plumed2 library")
+  set(PLUMED_MODE_VALUES static shared runtime)
+  set_property(CACHE PLUMED_MODE PROPERTY STRINGS ${PLUMED_MODE_VALUES})
+  validate_option(PLUMED_MODE PLUMED_MODE_VALUES)
+  string(TOUPPER ${PLUMED_MODE} PLUMED_MODE)
+
+  set(PLUMED_LINK_LIBS)
+  if(PLUMED_MODE STREQUAL "STATIC")
     find_package(LAPACK REQUIRED)
     find_package(BLAS REQUIRED)
     find_package(GSL REQUIRED)
@@ -18,33 +98,19 @@ if(PLUMED_MODE STREQUAL "STATIC")
     if(FFTW3_FOUND)
       list(APPEND PLUMED_LINK_LIBS FFTW3::FFTW3)
     endif()
-endif()
+  endif()
 
-find_package(PkgConfig QUIET)
-set(DOWNLOAD_PLUMED_DEFAULT ON)
-if(PKG_CONFIG_FOUND)
+  find_package(PkgConfig QUIET)
+  set(DOWNLOAD_PLUMED_DEFAULT ON)
+  if(PKG_CONFIG_FOUND)
     pkg_check_modules(PLUMED QUIET plumed)
     if(PLUMED_FOUND)
       set(DOWNLOAD_PLUMED_DEFAULT OFF)
     endif()
-endif()
+  endif()
 
-option(DOWNLOAD_PLUMED "Download Plumed package instead of using an already installed one" ${DOWNLOAD_PLUMED_DEFAULT})
-if(DOWNLOAD_PLUMED)
-  if(BUILD_MPI)
-    set(PLUMED_CONFIG_MPI "--enable-mpi")
-    set(PLUMED_CONFIG_CC  ${CMAKE_MPI_C_COMPILER})
-    set(PLUMED_CONFIG_CXX  ${CMAKE_MPI_CXX_COMPILER})
-  else()
-    set(PLUMED_CONFIG_MPI "--disable-mpi")
-    set(PLUMED_CONFIG_CC  ${CMAKE_C_COMPILER})
-    set(PLUMED_CONFIG_CXX  ${CMAKE_CXX_COMPILER})
-  endif()
-  if(BUILD_OMP)
-    set(PLUMED_CONFIG_OMP "--enable-openmp")
-  else()
-    set(PLUMED_CONFIG_OMP "--disable-openmp")
-  endif()
+  option(DOWNLOAD_PLUMED "Download Plumed package instead of using an already installed one" ${DOWNLOAD_PLUMED_DEFAULT})
+  if(DOWNLOAD_PLUMED)
     message(STATUS "PLUMED download requested - we will build our own")
     if(PLUMED_MODE STREQUAL "STATIC")
       set(PLUMED_BUILD_BYPRODUCTS "<INSTALL_DIR>/lib/${CMAKE_STATIC_LIBRARY_PREFIX}plumed${CMAKE_STATIC_LIBRARY_SUFFIX}")
@@ -54,13 +120,6 @@ if(DOWNLOAD_PLUMED)
       set(PLUMED_BUILD_BYPRODUCTS "<INSTALL_DIR>/lib/${CMAKE_STATIC_LIBRARY_PREFIX}plumedWrapper${CMAKE_STATIC_LIBRARY_PREFIX}")
     endif()
 
-  set(PLUMED_URL "https://github.com/plumed/plumed2/releases/download/v2.8.1/plumed-src-2.8.1.tgz" CACHE STRING "URL for PLUMED tarball")
-  set(PLUMED_MD5 "6bfe72ebdae63dc38a9ca27d9b0e08f8" CACHE STRING "MD5 checksum of PLUMED tarball")
-
-  mark_as_advanced(PLUMED_URL)
-  mark_as_advanced(PLUMED_MD5)
-  GetFallbackURL(PLUMED_URL PLUMED_FALLBACK)
-
     include(ExternalProject)
     ExternalProject_Add(plumed_build
       URL     ${PLUMED_URL} ${PLUMED_FALLBACK}
@@ -69,6 +128,8 @@ if(DOWNLOAD_PLUMED)
       CONFIGURE_COMMAND <SOURCE_DIR>/configure --prefix=<INSTALL_DIR>
                                              ${CONFIGURE_REQUEST_PIC}
                                              --enable-modules=all
+                                             --enable-cxx=11
+                                             --disable-python
                                              ${PLUMED_CONFIG_MPI}
                                              ${PLUMED_CONFIG_OMP}
                                              CXX=${PLUMED_CONFIG_CXX}
@@ -88,7 +149,7 @@ if(DOWNLOAD_PLUMED)
     endif()
     set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_INCLUDE_DIRECTORIES ${INSTALL_DIR}/include)
     file(MAKE_DIRECTORY ${INSTALL_DIR}/include)
-else()
+  else()
     find_package(PkgConfig REQUIRED)
     pkg_check_modules(PLUMED REQUIRED plumed)
     add_library(LAMMPS::PLUMED INTERFACE IMPORTED)
@@ -102,5 +163,7 @@ else()
     endif()
     set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_LINK_LIBRARIES "${PLUMED_LOAD}")
     set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_INCLUDE_DIRECTORIES "${PLUMED_INCLUDE_DIRS}")
+  endif()
 endif()
+
 target_link_libraries(lammps PRIVATE LAMMPS::PLUMED)

cmake/Modules/StyleHeaderUtils.cmake

@@ -104,6 +104,7 @@ function(RegisterStyles search_path)
     FindStyleHeaders(${search_path} DIHEDRAL_CLASS     dihedral_     DIHEDRAL     ) # dihedral     ) # force
     FindStyleHeaders(${search_path} DUMP_CLASS         dump_         DUMP         ) # dump         ) # output    write_dump
     FindStyleHeaders(${search_path} FIX_CLASS          fix_          FIX          ) # fix          ) # modify
+    FindStyleHeaders(${search_path} GRAN_SUB_MOD_CLASS gran_sub_mod_ GRAN_SUB_MOD ) # gran_sub_mod ) # granular_model
     FindStyleHeaders(${search_path} IMPROPER_CLASS     improper_     IMPROPER     ) # improper     ) # force
     FindStyleHeaders(${search_path} INTEGRATE_CLASS    "[^.]"        INTEGRATE    ) # integrate    ) # update
     FindStyleHeaders(${search_path} KSPACE_CLASS       "[^.]"        KSPACE       ) # kspace       ) # force
@@ -127,6 +128,7 @@ function(RegisterStylesExt search_path extension sources)
     FindStyleHeadersExt(${search_path} DIHEDRAL_CLASS     ${extension}  DIHEDRAL     ${sources})
     FindStyleHeadersExt(${search_path} DUMP_CLASS         ${extension}  DUMP         ${sources})
     FindStyleHeadersExt(${search_path} FIX_CLASS          ${extension}  FIX          ${sources})
+    FindStyleHeadersExt(${search_path} GRAN_SUB_MOD_CLASS ${extension}  GRAN_SUB_MOD ${sources})
     FindStyleHeadersExt(${search_path} IMPROPER_CLASS     ${extension}  IMPROPER     ${sources})
     FindStyleHeadersExt(${search_path} INTEGRATE_CLASS    ${extension}  INTEGRATE    ${sources})
     FindStyleHeadersExt(${search_path} KSPACE_CLASS       ${extension}  KSPACE       ${sources})
@@ -151,6 +153,7 @@ function(GenerateStyleHeaders output_path)
     GenerateStyleHeader(${output_path} DIHEDRAL     dihedral     ) # force
     GenerateStyleHeader(${output_path} DUMP         dump         ) # output    write_dump
     GenerateStyleHeader(${output_path} FIX          fix          ) # modify
+    GenerateStyleHeader(${output_path} GRAN_SUB_MOD gran_sub_mod ) # granular_model
     GenerateStyleHeader(${output_path} IMPROPER     improper     ) # force
     GenerateStyleHeader(${output_path} INTEGRATE    integrate    ) # update
     GenerateStyleHeader(${output_path} KSPACE       kspace       ) # force

cmake/Modules/Testing.cmake

@@ -18,29 +18,33 @@ 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 (Ubuntu 20.04 fails)
+  # 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)
-      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))
+      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)))
         OR ((CMAKE_LINUX_DISTRO STREQUAL "Fedora") AND (CMAKE_DISTRO_VERSION VERSION_GREATER 30)))
       include(CheckCXXCompilerFlag)
       set(CMAKE_CUSTOM_LINKER_DEFAULT default)
+      check_cxx_compiler_flag(-fuse-ld=mold HAVE_MOLD_LINKER_FLAG)
       check_cxx_compiler_flag(-fuse-ld=lld HAVE_LLD_LINKER_FLAG)
       check_cxx_compiler_flag(-fuse-ld=gold HAVE_GOLD_LINKER_FLAG)
       check_cxx_compiler_flag(-fuse-ld=bfd HAVE_BFD_LINKER_FLAG)
+      find_program(HAVE_MOLD_LINKER_BIN ld.mold)
       find_program(HAVE_LLD_LINKER_BIN lld ld.lld)
       find_program(HAVE_GOLD_LINKER_BIN ld.gold)
       find_program(HAVE_BFD_LINKER_BIN ld.bfd)
-      if(HAVE_LLD_LINKER_FLAG AND HAVE_LLD_LINKER_BIN)
+      if(HAVE_MOLD_LINKER_FLAG AND HAVE_MOLD_LINKER_BIN)
+        set(CMAKE_CUSTOM_LINKER_DEFAULT mold)
+      elseif(HAVE_LLD_LINKER_FLAG AND HAVE_LLD_LINKER_BIN)
         set(CMAKE_CUSTOM_LINKER_DEFAULT lld)
       elseif(HAVE_GOLD_LINKER_FLAG AND HAVE_GOLD_LINKER_BIN)
         set(CMAKE_CUSTOM_LINKER_DEFAULT gold)
       elseif(HAVE_BFD_LINKER_FLAG AND HAVE_BFD_LINKER_BIN)
         set(CMAKE_CUSTOM_LINKER_DEFAULT bfd)
       endif()
-      set(CMAKE_CUSTOM_LINKER_VALUES lld gold bfd default)
-      set(CMAKE_CUSTOM_LINKER ${CMAKE_CUSTOM_LINKER_DEFAULT} CACHE STRING "Choose a custom linker for faster linking (lld, gold, bfd, default)")
+      set(CMAKE_CUSTOM_LINKER_VALUES mold lld gold bfd default)
+      set(CMAKE_CUSTOM_LINKER ${CMAKE_CUSTOM_LINKER_DEFAULT} CACHE STRING "Choose a custom linker for faster linking (mold, lld, gold, bfd, default)")
       validate_option(CMAKE_CUSTOM_LINKER CMAKE_CUSTOM_LINKER_VALUES)
       mark_as_advanced(CMAKE_CUSTOM_LINKER)
       if(NOT "${CMAKE_CUSTOM_LINKER}" STREQUAL "default")

cmake/Modules/Tools.cmake

@@ -33,6 +33,8 @@ if(BUILD_TOOLS)
   endif()
   install(TARGETS msi2lmp DESTINATION ${CMAKE_INSTALL_BINDIR})
   install(FILES ${LAMMPS_DOC_DIR}/msi2lmp.1 DESTINATION ${CMAKE_INSTALL_MANDIR}/man1)
+
+  add_subdirectory(${LAMMPS_TOOLS_DIR}/phonon ${CMAKE_BINARY_DIR}/phana_build)
 endif()
 
 if(BUILD_LAMMPS_SHELL)

cmake/presets/all_off.cmake

@@ -43,7 +43,6 @@ set(ALL_PACKAGES
   KOKKOS
   KSPACE
   LATBOLTZ
-  LATTE
   LEPTON
   MACHDYN
   MANIFOLD

cmake/presets/all_on.cmake

@@ -45,7 +45,6 @@ set(ALL_PACKAGES
   KOKKOS
   KSPACE
   LATBOLTZ
-  LATTE
   LEPTON
   MACHDYN
   MANIFOLD

cmake/presets/download.cmake

@@ -1,14 +1,13 @@
 # Preset that turns on packages with automatic downloads of sources or potentials.
 # Compilation of libraries like Plumed or ScaFaCoS can take a considerable amount of time.
 
-set(ALL_PACKAGES KIM LATTE MSCG VORONOI PLUMED SCAFACOS MACHDYN MESONT MDI ML-PACE)
+set(ALL_PACKAGES KIM MSCG VORONOI PLUMED SCAFACOS MACHDYN MESONT MDI ML-PACE)
 
 foreach(PKG ${ALL_PACKAGES})
   set(PKG_${PKG} ON CACHE BOOL "" FORCE)
 endforeach()
 
 set(DOWNLOAD_KIM ON CACHE BOOL "" FORCE)
-set(DOWNLOAD_LATTE 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)

cmake/presets/mingw-cross.cmake

@@ -35,7 +35,6 @@ set(WIN_PACKAGES
   INTEL
   INTERLAYER
   KSPACE
-  LATTE
   LEPTON
   MACHDYN
   MANIFOLD

cmake/presets/nolib.cmake

@@ -12,7 +12,6 @@ set(PACKAGES_WITH_LIB
   KIM
   KOKKOS
   LATBOLTZ
-  LATTE
   LEPTON
   MACHDYN
   MDI

doc/Makefile

@@ -94,10 +94,11 @@ html: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJAX)
 		rm -f $(BUILDDIR)/doxygen/xml/run.stamp;\
 		echo "############################################" ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
 		rst_anchor_check src/*.rst ;\
-		python $(BUILDDIR)/utils/check-packages.py -s ../src -d src ;\
+		$(PYTHON) $(BUILDDIR)/utils/check-packages.py -s ../src -d src ;\
 		env LC_ALL=C grep -n '[^ -~]' $(RSTDIR)/*.rst ;\
 		env LC_ALL=C grep -n ' :[a-z]\+`' $(RSTDIR)/*.rst ;\
-		python $(BUILDDIR)/utils/check-styles.py -s ../src -d src ;\
+		env LC_ALL=C grep -n ' `[^`]\+<[a-z][^`]\+`[^_]' $(RSTDIR)/*.rst ;\
+		$(PYTHON) $(BUILDDIR)/utils/check-styles.py -s ../src -d src ;\
 		echo "############################################" ;\
 		deactivate ;\
 	)
@@ -174,10 +175,11 @@ pdf: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK)
 		rm -f $(BUILDDIR)/doxygen/xml/run.stamp;\
 		echo "############################################" ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
 		rst_anchor_check src/*.rst ;\
-		python utils/check-packages.py -s ../src -d src ;\
+		$(PYTHON) utils/check-packages.py -s ../src -d src ;\
 		env LC_ALL=C grep -n '[^ -~]' $(RSTDIR)/*.rst ;\
 		env LC_ALL=C grep -n ' :[a-z]\+`' $(RSTDIR)/*.rst ;\
-		python utils/check-styles.py -s ../src -d src ;\
+		env LC_ALL=C grep -n ' `[^`]\+<[a-z][^`]\+`[^_]' $(RSTDIR)/*.rst ;\
+		$(PYTHON) utils/check-styles.py -s ../src -d src ;\
 		echo "############################################" ;\
 		deactivate ;\
 	)
@@ -208,14 +210,14 @@ anchor_check : $(ANCHORCHECK)
 style_check : $(VENV)
 	@(\
 		. $(VENV)/bin/activate ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
-		python utils/check-styles.py -s ../src -d src ;\
+		$(PYTHON) utils/check-styles.py -s ../src -d src ;\
 		deactivate ;\
 	)
 
 package_check : $(VENV)
 	@(\
-		. $(VENV)/bin/activate ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \\
-		python utils/check-packages.py -s ../src -d src ;\
+		. $(VENV)/bin/activate ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
+		$(PYTHON) utils/check-packages.py -s ../src -d src ;\
 		deactivate ;\
 	)
 
@@ -224,6 +226,14 @@ 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 || : )
+
+link_check : $(VENV) html
+	@(\
+		. $(VENV)/bin/activate ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
+		linkchecker -F html --check-extern html/Manual.html ;\
+		deactivate ;\
+	)
 
 xmlgen : doxygen/xml/index.xml
 

doc/github-development-workflow.md

@@ -1,12 +1,12 @@
 # Outline of the GitHub Development Workflow
 
-This purpose of this document is to provide a point of reference for the
+The purpose of this document is to provide a point of reference for the
 core LAMMPS developers and other LAMMPS contributors to understand the
 choices the LAMMPS developers have agreed on. Git and GitHub provide the
 tools, but do not set policies, so it is up to the developers to come to
 an agreement as to how to define and interpret policies. This document
-is likely to change as our experiences and needs change and we try to
-adapt accordingly. Last change 2021-09-02.
+is likely to change as our experiences and needs change, and we try to
+adapt it accordingly. Last change 2023-02-10.
 
 ## Table of Contents
 
@@ -22,47 +22,50 @@ adapt accordingly. Last change 2021-09-02.
 ## GitHub Merge Management
 
 In the interest of consistency, ONLY ONE of the core LAMMPS developers
-should doing the merging itself.  This is currently
+should do the merging.  This is currently
 [@akohlmey](https://github.com/akohlmey) (Axel Kohlmeyer).  If this
 assignment needs to be changed, it shall be done right after a stable
 release.  If the currently assigned developer cannot merge outstanding
 pull requests in a timely manner, or in other extenuating circumstances,
-other core LAMMPS developers with merge rights can merge pull requests,
-when necessary.
+other core LAMMPS developers with merge permission may merge pull
+requests.
 
 ## Pull Requests
 
-ALL changes to the LAMMPS code and documentation, however trivial, 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 patch or stable releases with fast-forward merges based on the
-associated tags. Pull requests may also be submitted to (long-running)
-feature branches created by LAMMPS developers inside the LAMMPS project,
-if needed. Those are not subject to the merge and review restrictions
-discussed in this document, though, but get managed as needed on a
-case-by-case basis.
+*ALL* changes to the LAMMPS code and documentation, however trivial,
+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
+(for example, back-ported bug fixes) are first merged into the "maintenance"
+branch and then into the "stable" branch as update releases.
+
+Pull requests may also be submitted to (long-running) feature branches
+created by LAMMPS developers inside the LAMMPS project, if needed. Those
+are not subject to the merge and review restrictions discussed in this
+document, though, but get managed as needed on a case-by-case basis.
 
 ### Pull Request Assignments
 
 Pull requests can be "chaperoned" by one of the LAMMPS core developers.
-This is indicated by who the pull request is assigned to. LAMMPS core
-developers can self-assign or they can decide to assign a pull request
+This is indicated by whom the pull request is assigned to.  LAMMPS core
+developers can self-assign, or they can decide to assign a pull request
 to a different LAMMPS developer. Being assigned to a pull request means,
 that this pull request may need some work and the assignee is tasked to
-determine whether this might be needed or not, and may either implement
-the required changes or ask the submitter of the pull request to implement
-them.  Even though, all LAMMPS developers may have write access to pull
-requests (if enabled by the submitter, which is the default), only the
-submitter or the assignee of a pull request may do so.  During this
-period the `work_in_progress` label may be applied to the pull
-request.  The assignee gets to decide what happens to the pull request
-next, e.g. whether it should be assigned to a different developer for
-additional checks and changes, or is recommended to be merged.  Removing
-the `work_in_progress` label and assigning the pull request to the
-developer tasked with merging signals that a pull request is ready to be
-merged. In addition, a `ready_for_merge` label may also be assigned
-to signal urgency to merge this pull request quickly.
+determine whether this might be needed or not. The assignee may either
+choose to implement required changes or ask the submitter of the pull
+request to implement them.  Even though, all LAMMPS developers may have
+write access to pull requests (if enabled by the submitter, which is the
+default), only the submitter or the assignee of a pull request should do
+so.  During this period, the `work_in_progress` label may be applied to
+the pull request.  The assignee gets to decide what happens to the pull
+request next, e.g. whether it should be assigned to a different
+developer for additional checks and changes, or is recommended to be
+merged.  Removing the `work_in_progress` label and assigning the pull
+request to the developer tasked with merging signals that a pull request
+is ready to be merged. In addition, a `ready_for_merge` label may also
+be assigned to signal urgency to merge this pull request quickly.
 
 ### Pull Request Reviews
 
@@ -70,32 +73,33 @@ People can be assigned to review a pull request in two ways:
 
   * They can be assigned manually to review a pull request
     by the submitter or a LAMMPS developer
-  * They can be automatically assigned, because a developers matches
-    a file pattern in the `.github/CODEOWNERS` file, which associates
-    developers with the code they contributed and maintain.
+  * They can be automatically assigned, because a developer's GitHub
+    handle matches a file pattern in the `.github/CODEOWNERS` file,
+    which associates developers with the code they contributed and
+    maintain.
 
 Reviewers are requested to state their appraisal of the proposed changes
 and either approve or request changes. People may unassign themselves
 from review, if they feel not competent about the changes proposed. At
-least two approvals from LAMMPS developers with write access are required
-before merging in addition to the automated compilation tests.
-Merging counts as implicit approval, so does submission of a pull request
-(by a LAMMPS developer). So the person doing the merge may not also submit
-an approving review. The feature, that reviews from code owners are "hard"
-reviews (i.e. they must all be approved before merging is allowed), is
-currently disabled and it is in the discretion of the merge maintainer to
-assess when a sufficient degree of approval, especially from external
-contributors, has been reached in these cases.  Reviews may be
-(automatically) dismissed, when the reviewed code has been changed,
-and then approval is required a second time.
+least two approvals from LAMMPS developers with write access are
+required before merging, in addition to passing all automated
+compilation and unit tests.  Merging counts as implicit approval, so
+does submission of a pull request (by a LAMMPS developer). So the person
+doing the merge may not also submit an approving review.  The GitHub
+feature, that reviews from code owners are "hard" reviews (i.e. they
+must all approve before merging is allowed), is currently disabled.
+It is in the discretion of the merge maintainer to assess when a
+sufficient degree of approval has been reached, especially from external
+collaborators.  Reviews may be (automatically) dismissed, when the
+reviewed code has been changed. Review may be requested a second time.
 
 ### Pull Request Discussions
 
 All discussions about a pull request should be kept as much as possible
 on the pull request discussion page on GitHub, so that other developers
 can later review the entire discussion after the fact and understand the
-rationale behind choices made.  Exceptions to this policy are technical
-discussions, that are centered on tools or policies themselves
+rationale behind choices that were made.  Exceptions to this policy are
+technical discussions, that are centered on tools or policies themselves
 (git, GitHub, c++) rather than on the content of the pull request.
 
 ## GitHub Issues
@@ -109,39 +113,47 @@ marker in the subject. This is automatically done when using the
 corresponding template for submitting an issue.  Issues may be assigned
 to one or more developers, if they are working on this feature or
 working to resolve an issue.  Issues that have nobody working
-on them at the moment or in the near future, have the label
+on them at the moment, or in the near future, have the label
 `volunteer needed` attached.
 
-When an issue, say `#125` is resolved by a specific pull request,
-the comment for the pull request shall contain the text `closes #125`
-or `fixes #125`, so that the issue is automatically deleted when
-the pull request is merged.  The template for pull requests includes
-a header where connections between pull requests and issues can be listed
-and thus were this comment should be placed.
+When an issue, say `#125` is resolved by a specific pull request, the
+comment for the pull request shall contain the text `closes #125` or
+`fixes #125`, so that the issue is automatically deleted when the pull
+request is merged.  The template for pull requests includes a header
+where connections between pull requests and issues can be listed, and
+thus where this comment should be placed.
 
-## Milestones and Release Planning
+## Release Planning
 
 LAMMPS uses a continuous release development model with incremental
-changes, i.e. significant effort is made - including automated pre-merge
-testing - that the code in the branch "develop" does not get easily
+changes, i.e. significant effort is made -- including automated pre-merge
+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 patch
-releases of LAMMPS every 3-5 weeks at a point, when the LAMMPS
-developers feel, that a sufficient amount of changes have happened, and
-the post-merge testing has been successful. These patch releases are
+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
+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
-follows only these versions (and thus is always supposed to be of
-production quality, unlike "develop", which may be temporary broken, in
-the case of larger change sets or unexpected incompatibilities or side
-effects.
+follows only these versions with fast-forward merges.  While "develop" may
+be temporarily broken through issues only detected by the post-merge tests,
+The "release" branch is always supposed to be of production quality.
 
-About 1-2 times each year, there are going to be "stable" releases of
-LAMMPS.  These have seen additional, manual testing and review of
-results from testing with instrumented code and static code analysis.
-Also, the last 1-3 patch releases before a stable release are "release
-candidate" versions which only contain bugfixes and documentation
-updates.  For release planning and the information of code contributors,
-issues and pull requests being actively worked on are assigned a
-"milestone", which corresponds to the next stable release or the stable
-release after that, with a tentative release date.
+About once each year, there is a "stable" release of LAMMPS.  These have
+seen additional, manual testing and review of results from testing with
+instrumented code and static code analysis.  Also, the last few feature
+releases before a stable release are "release candidate" versions which
+only contain bug fixes, feature additions to peripheral functionality,
+and documentation updates.  In between stable releases, bug fixes and
+infrastructure updates are back-ported from the "develop" branch to the
+"maintenance" branch and occasionally merged into "stable" and published
+as update releases.
+
+## Project Management
+
+For release planning and the information of code contributors, issues
+and pull requests are being managed with GitHub Project Boards.  There
+are currently three boards: LAMMPS Feature Requests, LAMMPS Bug Reports,
+and LAMMPS Pull Requests.  Each board is organized in columns where
+submissions are categorized.  Within each column the entries are
+(manually) sorted according their priority.

doc/lammps.1

@@ -1,7 +1,7 @@
-.TH LAMMPS "1" "8 February 2023" "2023-02-08"
+.TH LAMMPS "1" "15 June 2023" "2023-06-15"
 .SH NAME
 .B LAMMPS
-\- Molecular Dynamics Simulator.  Version 8 February 2023
+\- Molecular Dynamics Simulator.  Version 15 June 2023
 
 .SH SYNOPSIS
 .B lmp

doc/msi2lmp.1

@@ -1,11 +1,11 @@
-.TH MSI2LMP "1" "v3.9.9" "2018-11-05"
+.TH MSI2LMP "1" "v3.9.10" "2023-03-10"
 .SH NAME
 .B MSI2LMP
 \- Converter for Materials Studio files to LAMMPS
 
 .SH SYNOPSIS
 .B msi2lmp
-<ROOTNAME> [-class <I|1|II|2|O|0>] [-frc <path to frc file>] [-print #] [-ignore] [-nocenter] [-oldstyle] [-shift <x> <y> <z>]
+[-help] <ROOTNAME> [-class <I|1|II|2|O|0>] [-frc <path to frc file>] [-print #] [-ignore] [-nocenter] [-oldstyle] [-shift <x> <y> <z>]
 
 .SH DESCRIPTION
 .PP
@@ -22,6 +22,9 @@ needed between .frc and .car/.mdf files are the atom types.
 
 .SH OPTIONS
 .TP
+\fB\-h\fR, \fB\-help\fR,
+Print detailed help message to the screen and stop.
+.TP
 \fB\<ROOTNAME>\fR
 This has to be the first argument and is a
 .B mandatory

doc/src/Build_basics.rst

@@ -128,14 +128,14 @@ 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. ``LATTE``, ``KSPACE``, and ``COLVARS``.  See the
-:doc:`Packages details <Packages_details>` page for more info on these
-packages, and the pages for their respective commands for OpenMP
-threading info.
+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.
 
 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

doc/src/Build_development.rst

@@ -523,6 +523,8 @@ The following options are available.
 These should help to make source and documentation files conforming
 to some the coding style preferences of the LAMMPS developers.
 
+.. _clang-format:
+
 Clang-format support
 --------------------
 

doc/src/Build_extras.rst

@@ -43,7 +43,6 @@ This is the list of packages that may require additional steps.
    * :ref:`INTEL <intel>`
    * :ref:`KIM <kim>`
    * :ref:`KOKKOS <kokkos>`
-   * :ref:`LATTE <latte>`
    * :ref:`LEPTON <lepton>`
    * :ref:`MACHDYN <machdyn>`
    * :ref:`MDI <mdi>`
@@ -181,6 +180,9 @@ way no local OpenCL development headers or library needs to be present and only
 OpenCL compatible drivers need to be installed to use OpenCL.  If this is not
 desired, you can set :code:`USE_STATIC_OPENCL_LOADER` to :code:`no`.
 
+The GPU library has some multi-thread support using OpenMP.  If LAMMPS is built
+with ``-D BUILD_OMP=on`` this will also be enabled.
+
 If you are compiling with HIP, note that before running CMake you will have to
 set appropriate environment variables. Some variables such as
 :code:`HCC_AMDGPU_TARGET` (for ROCm <= 4.0) or :code:`CUDA_PATH` are necessary for :code:`hipcc`
@@ -274,10 +276,13 @@ To enable GPU binning via CUDA performance primitives set the Makefile variable
 most modern GPUs.
 
 To support the CUDA multiprocessor server you can set the define
-``-DCUDA_PROXY``.  Please note that in this case you must **not** use
+``-DCUDA_MPS_SUPPORT``.  Please note that in this case you must **not** use
 the CUDA performance primitives and thus set the variable ``CUDPP_OPT``
 to empty.
 
+The GPU library has some multi-thread support using OpenMP.  You need to add
+the compiler flag that enables OpenMP to the ``CUDR_OPTS`` Makefile variable.
+
 If the library build is successful, 3 files should be created:
 ``lib/gpu/libgpu.a``\ , ``lib/gpu/nvc_get_devices``\ , and
 ``lib/gpu/Makefile.lammps``\ .  The latter has settings that enable LAMMPS
@@ -678,20 +683,11 @@ This list was last updated for version 3.7.1 of the Kokkos library.
          -D Kokkos_ARCH_GPUARCH=yes    # GPUARCH = GPU from list above
          -D Kokkos_ENABLE_CUDA=yes
          -D Kokkos_ENABLE_OPENMP=yes
-         -D CMAKE_CXX_COMPILER=wrapper # wrapper = full path to Cuda nvcc wrapper
 
       This will also enable executing FFTs on the GPU, either via the
       internal KISSFFT library, or - by preference - with the cuFFT
       library bundled with the CUDA toolkit, depending on whether CMake
-      can identify its location.  The *wrapper* value for
-      ``CMAKE_CXX_COMPILER`` variable is the path to the CUDA nvcc
-      compiler wrapper provided in the Kokkos library:
-      ``lib/kokkos/bin/nvcc_wrapper``\ .  The setting should include the
-      full path name to the wrapper, e.g.
-
-      .. code-block:: bash
-
-         -D CMAKE_CXX_COMPILER=${HOME}/lammps/lib/kokkos/bin/nvcc_wrapper
+      can identify its location.
 
       For AMD or NVIDIA GPUs using HIP, set these variables:
 
@@ -826,63 +822,6 @@ will thus always enable it.
 
 ----------
 
-.. _latte:
-
-LATTE package
--------------------------
-
-To build with this package, you must download and build the LATTE
-library.
-
-.. tabs::
-
-   .. tab:: CMake build
-
-      .. code-block:: bash
-
-         -D DOWNLOAD_LATTE=value      # download LATTE for build, value = no (default) or yes
-         -D LATTE_LIBRARY=path        # LATTE library file (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
-
-      If ``DOWNLOAD_LATTE`` is set, the LATTE library will be downloaded
-      and built inside the CMake build directory.  If the LATTE library
-      is already on your system (in a location CMake cannot find it),
-      ``LATTE_LIBRARY`` is the filename (plus path) of the LATTE library
-      file, not the directory the library file is in.
-
-      The LATTE library requires LAPACK (and BLAS) and CMake can identify
-      their locations and pass that info to the LATTE 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
-
-      You can download and build the LATTE library manually if you
-      prefer; follow the instructions in ``lib/latte/README``\ .  You
-      can also do it in one step from the ``lammps/src`` dir, using a
-      command like these, which simply invokes the
-      ``lib/latte/Install.py`` script with the specified args:
-
-      .. code-block:: bash
-
-         make lib-latte                        # print help message
-         make lib-latte args="-b"              # download and build in lib/latte/LATTE-master
-         make lib-latte args="-p $HOME/latte"  # use existing LATTE installation in $HOME/latte
-         make lib-latte args="-b -m gfortran"  # download and build in lib/latte and
-                                               #   copy Makefile.lammps.gfortran to Makefile.lammps
-
-      Note that 3 symbolic (soft) links, ``includelink`` and ``liblink``
-      and ``filelink.o``, are created in ``lib/latte`` to point to
-      required folders and files in the LATTE home directory.  When
-      LAMMPS itself is built it will use these links.  You should also
-      check that the ``Makefile.lammps`` file you create is appropriate
-      for the compiler you use on your system to build LATTE.
-
-----------
-
 .. _lepton:
 
 LEPTON package
@@ -1135,7 +1074,7 @@ VORONOI package
 -----------------------------
 
 To build with this package, you must download and build the
-`Voro++ library <https://math.lbl.gov/voro++>`_ or install a
+`Voro++ library <https://math.lbl.gov/voro++/>`_ or install a
 binary package provided by your operating system.
 
 .. tabs::
@@ -1407,9 +1346,9 @@ This package depends on the KSPACE package.
       KSPACE package so the latter one *must* be enabled.
 
       The ELECTRODE package also requires LAPACK (and BLAS) and CMake
-      can identify their locations and pass that info to the LATTE build
-      script.  But on some systems this may cause problems when linking
-      or the dependency is not desired.  Try enabling
+      can identify their locations and pass that info to the ELECTRODE
+      build script.  But on some systems this may cause problems when
+      linking or the dependency is not desired.  Try enabling
       ``USE_INTERNAL_LINALG`` in those cases to use the bundled linear
       algebra library and work around the limitation.
 
@@ -1964,10 +1903,10 @@ OPENMP package
    Apple offers the `Xcode package and IDE
    <https://developer.apple.com/xcode/>`_ for compiling software on
    macOS, so you have likely installed it to compile LAMMPS.  Their
-   compiler is based on `Clang <https://clang.llvm.org/>`, but while it
+   compiler is based on `Clang <https://clang.llvm.org/>`_, but while it
    is capable of processing OpenMP directives, the necessary header
    files and OpenMP runtime library are missing.  The `R developers
-   <https://www.r-project.org/>` have figured out a way to build those
+   <https://www.r-project.org/>`_ have figured out a way to build those
    in a compatible fashion. One can download them from
    `https://mac.r-project.org/openmp/
    <https://mac.r-project.org/openmp/>`_.  Simply adding those files as

doc/src/Build_make.rst

@@ -117,8 +117,8 @@ their settings may become outdated, too:
 
 .. code-block:: bash
 
-   make mac             # build serial LAMMPS on a Mac
-   make mac_mpi         # build parallel LAMMPS on a Mac
+   make mac             # build serial LAMMPS on macOS
+   make mac_mpi         # build parallel LAMMPS on macOS
    make intel_cpu       # build with the INTEL package optimized for CPUs
    make knl             # build with the INTEL package optimized for KNLs
    make opt             # build with the OPT package optimized for CPUs

doc/src/Build_manual.rst

@@ -33,7 +33,7 @@ various tools and files.  Some of them have to be installed (see below).  For
 the rest the build process will attempt to download and install them into
 a python virtual environment and local folders.
 
-A current version of the manual (latest patch release, that is the state
+A current version of the manual (latest feature release, that is the state
 of the *release* branch) is is available online at:
 `https://docs.lammps.org/ <https://docs.lammps.org/>`_.
 A version of the manual corresponding to the ongoing development (that is
@@ -48,15 +48,15 @@ Build using GNU make
 
 The LAMMPS manual is written in `reStructuredText <rst_>`_ format which
 can be translated to different output format using the `Sphinx
-<https://sphinx-doc.org>`_ document generator tool.  It also
+<https://www.sphinx-doc.org/>`_ document generator tool.  It also
 incorporates programmer documentation extracted from the LAMMPS C++
-sources through the `Doxygen <https://doxygen.nl>`_ program.  Currently
+sources through the `Doxygen <https://doxygen.nl/>`_ program.  Currently
 the translation to HTML, PDF (via LaTeX), ePUB (for many e-book readers)
 and MOBI (for Amazon Kindle readers) are supported.  For that to work a
-Python 3 interpreter, the ``doxygen`` tools and internet access to
-download additional files and tools are required.  This download is
-usually only required once or after the documentation folder is returned
-to a pristine state with ``make clean-all``.
+Python interpreter version 3.8 or later, the ``doxygen`` tools and
+internet access to download additional files and tools are required.
+This download is usually only required once or after the documentation
+folder is returned to a pristine state with ``make clean-all``.
 
 For the documentation build a python virtual environment is set up in
 the folder ``doc/docenv`` and various python packages are installed into
@@ -87,6 +87,7 @@ folder.  The following ``make`` commands are available:
    make anchor_check  # check for duplicate anchor labels
    make style_check   # check for complete and consistent style lists
    make package_check # check for complete and consistent package lists
+   make link_check    # check for broken or outdated URLs
    make spelling      # spell-check the manual
 
 ----------

doc/src/Build_package.rst

@@ -46,7 +46,6 @@ packages:
    * :ref:`INTEL <intel>`
    * :ref:`KIM <kim>`
    * :ref:`KOKKOS <kokkos>`
-   * :ref:`LATTE <latte>`
    * :ref:`LEPTON <lepton>`
    * :ref:`MACHDYN <machdyn>`
    * :ref:`MDI <mdi>`

doc/src/Commands_bond.rst

@@ -42,6 +42,7 @@ OPT.
    * :doc:`gaussian <bond_gaussian>`
    * :doc:`gromos (o) <bond_gromos>`
    * :doc:`harmonic (iko) <bond_harmonic>`
+   * :doc:`harmonic/restrain <bond_harmonic_restrain>`
    * :doc:`harmonic/shift (o) <bond_harmonic_shift>`
    * :doc:`harmonic/shift/cut (o) <bond_harmonic_shift_cut>`
    * :doc:`lepton (o) <bond_lepton>`

doc/src/Commands_compute.rst

@@ -46,12 +46,15 @@ KOKKOS, o = OPENMP, t = OPT.
    * :doc:`com/chunk <compute_com_chunk>`
    * :doc:`contact/atom <compute_contact_atom>`
    * :doc:`coord/atom (k) <compute_coord_atom>`
+   * :doc:`count/type <compute_count_type>`
    * :doc:`damage/atom <compute_damage_atom>`
    * :doc:`dihedral <compute_dihedral>`
    * :doc:`dihedral/local <compute_dihedral_local>`
    * :doc:`dilatation/atom <compute_dilatation_atom>`
    * :doc:`dipole <compute_dipole>`
    * :doc:`dipole/chunk <compute_dipole_chunk>`
+   * :doc:`dipole/tip4p <compute_dipole>`
+   * :doc:`dipole/tip4p/chunk <compute_dipole_chunk>`
    * :doc:`displace/atom <compute_displace_atom>`
    * :doc:`dpd <compute_dpd>`
    * :doc:`dpd/atom <compute_dpd_atom>`
@@ -61,7 +64,7 @@ KOKKOS, o = OPENMP, t = OPT.
    * :doc:`entropy/atom <compute_entropy_atom>`
    * :doc:`erotate/asphere <compute_erotate_asphere>`
    * :doc:`erotate/rigid <compute_erotate_rigid>`
-   * :doc:`erotate/sphere <compute_erotate_sphere>`
+   * :doc:`erotate/sphere (k) <compute_erotate_sphere>`
    * :doc:`erotate/sphere/atom <compute_erotate_sphere_atom>`
    * :doc:`event/displace <compute_event_displace>`
    * :doc:`fabric <compute_fabric>`
@@ -104,6 +107,7 @@ KOKKOS, o = OPENMP, t = OPT.
    * :doc:`pe/tally <compute_tally>`
    * :doc:`plasticity/atom <compute_plasticity_atom>`
    * :doc:`pressure <compute_pressure>`
+   * :doc:`pressure/alchemy <compute_pressure_alchemy>`
    * :doc:`pressure/uef <compute_pressure_uef>`
    * :doc:`property/atom <compute_property_atom>`
    * :doc:`property/chunk <compute_property_chunk>`
@@ -149,11 +153,11 @@ KOKKOS, o = OPENMP, t = OPT.
    * :doc:`sph/t/atom <compute_sph_t_atom>`
    * :doc:`spin <compute_spin>`
    * :doc:`stress/atom <compute_stress_atom>`
-   * :doc:`stress/cartesian <compute_stress_profile>`
-   * :doc:`stress/cylinder <compute_stress_profile>`
+   * :doc:`stress/cartesian <compute_stress_cartesian>`
+   * :doc:`stress/cylinder <compute_stress_curvilinear>`
    * :doc:`stress/mop <compute_stress_mop>`
    * :doc:`stress/mop/profile <compute_stress_mop>`
-   * :doc:`stress/spherical <compute_stress_profile>`
+   * :doc:`stress/spherical <compute_stress_curvilinear>`
    * :doc:`stress/tally <compute_tally>`
    * :doc:`tdpd/cc/atom <compute_tdpd_cc_atom>`
    * :doc:`temp (k) <compute_temp>`

doc/src/Commands_fix.rst

@@ -29,6 +29,7 @@ OPT.
    * :doc:`adapt/fep <fix_adapt_fep>`
    * :doc:`addforce <fix_addforce>`
    * :doc:`addtorque <fix_addtorque>`
+   * :doc:`alchemy <fix_alchemy>`
    * :doc:`amoeba/bitorsion <fix_amoeba_bitorsion>`
    * :doc:`amoeba/pitorsion <fix_amoeba_pitorsion>`
    * :doc:`append/atoms <fix_append_atoms>`
@@ -69,6 +70,7 @@ OPT.
    * :doc:`dt/reset (k) <fix_dt_reset>`
    * :doc:`edpd/source <fix_dpd_source>`
    * :doc:`efield <fix_efield>`
+   * :doc:`efield/tip4p <fix_efield>`
    * :doc:`ehex <fix_ehex>`
    * :doc:`electrode/conp (i) <fix_electrode>`
    * :doc:`electrode/conq (i) <fix_electrode>`
@@ -92,6 +94,7 @@ OPT.
    * :doc:`grem <fix_grem>`
    * :doc:`halt <fix_halt>`
    * :doc:`heat <fix_heat>`
+   * :doc:`heat/flow <fix_heat_flow>`
    * :doc:`hyper/global <fix_hyper_global>`
    * :doc:`hyper/local <fix_hyper_local>`
    * :doc:`imd <fix_imd>`
@@ -101,13 +104,13 @@ OPT.
    * :doc:`langevin/drude <fix_langevin_drude>`
    * :doc:`langevin/eff <fix_langevin_eff>`
    * :doc:`langevin/spin <fix_langevin_spin>`
-   * :doc:`latte <fix_latte>`
    * :doc:`lb/fluid <fix_lb_fluid>`
    * :doc:`lb/momentum <fix_lb_momentum>`
    * :doc:`lb/viscous <fix_lb_viscous>`
    * :doc:`lineforce <fix_lineforce>`
    * :doc:`manifoldforce <fix_manifoldforce>`
    * :doc:`mdi/qm <fix_mdi_qm>`
+   * :doc:`mdi/qmmm <fix_mdi_qmmm>`
    * :doc:`meso/move <fix_meso_move>`
    * :doc:`mol/swap <fix_mol_swap>`
    * :doc:`momentum (k) <fix_momentum>`
@@ -168,7 +171,8 @@ OPT.
    * :doc:`pafi <fix_pafi>`
    * :doc:`pair <fix_pair>`
    * :doc:`phonon <fix_phonon>`
-   * :doc:`pimd <fix_pimd>`
+   * :doc:`pimd/langevin <fix_pimd>`
+   * :doc:`pimd/nvt <fix_pimd>`
    * :doc:`planeforce <fix_planeforce>`
    * :doc:`plumed <fix_plumed>`
    * :doc:`poems <fix_poems>`
@@ -257,12 +261,13 @@ OPT.
    * :doc:`wall/body/polyhedron <fix_wall_body_polyhedron>`
    * :doc:`wall/colloid <fix_wall>`
    * :doc:`wall/ees <fix_wall_ees>`
-   * :doc:`wall/gran <fix_wall_gran>`
+   * :doc:`wall/gran (k) <fix_wall_gran>`
    * :doc:`wall/gran/region <fix_wall_gran_region>`
    * :doc:`wall/harmonic <fix_wall>`
    * :doc:`wall/lj1043 <fix_wall>`
    * :doc:`wall/lj126 <fix_wall>`
    * :doc:`wall/lj93 (k) <fix_wall>`
+   * :doc:`wall/lepton <fix_wall>`
    * :doc:`wall/morse <fix_wall>`
    * :doc:`wall/piston <fix_wall_piston>`
    * :doc:`wall/reflect (k) <fix_wall_reflect>`
@@ -270,4 +275,5 @@ OPT.
    * :doc:`wall/region <fix_wall_region>`
    * :doc:`wall/region/ees <fix_wall_ees>`
    * :doc:`wall/srd <fix_wall_srd>`
+   * :doc:`wall/table <fix_wall>`
    * :doc:`widom <fix_widom>`

doc/src/Commands_pair.rst

@@ -37,6 +37,7 @@ OPT.
    *
    * :doc:`adp (ko) <pair_adp>`
    * :doc:`agni (o) <pair_agni>`
+   * :doc:`aip/water/2dm (t) <pair_aip_water_2dm>`
    * :doc:`airebo (io) <pair_airebo>`
    * :doc:`airebo/morse (io) <pair_airebo>`
    * :doc:`amoeba (g) <pair_amoeba>`
@@ -55,6 +56,7 @@ OPT.
    * :doc:`born/coul/msm (o) <pair_born>`
    * :doc:`born/coul/wolf (go) <pair_born>`
    * :doc:`born/coul/wolf/cs (g) <pair_cs>`
+   * :doc:`born/gauss <pair_born_gauss>`
    * :doc:`bpm/spring <pair_bpm_spring>`
    * :doc:`brownian (o) <pair_brownian>`
    * :doc:`brownian/poly (o) <pair_brownian>`
@@ -136,6 +138,7 @@ OPT.
    * :doc:`lennard/mdf <pair_mdf>`
    * :doc:`lepton (o) <pair_lepton>`
    * :doc:`lepton/coul (o) <pair_lepton>`
+   * :doc:`lepton/sphere (o) <pair_lepton>`
    * :doc:`line/lj <pair_line_lj>`
    * :doc:`lj/charmm/coul/charmm (giko) <pair_charmm>`
    * :doc:`lj/charmm/coul/charmm/implicit (ko) <pair_charmm>`
@@ -170,12 +173,14 @@ OPT.
    * :doc:`lj/cut/dipole/long (g) <pair_dipole>`
    * :doc:`lj/cut/dipole/sf (go) <pair_dipole>`
    * :doc:`lj/cut/soft (o) <pair_fep_soft>`
+   * :doc:`lj/cut/sphere (o) <pair_lj_cut_sphere>`
    * :doc:`lj/cut/thole/long (o) <pair_thole>`
    * :doc:`lj/cut/tip4p/cut (o) <pair_lj_cut_tip4p>`
    * :doc:`lj/cut/tip4p/long (got) <pair_lj_cut_tip4p>`
    * :doc:`lj/cut/tip4p/long/soft (o) <pair_fep_soft>`
    * :doc:`lj/expand (gko) <pair_lj_expand>`
    * :doc:`lj/expand/coul/long (gk) <pair_lj_expand>`
+   * :doc:`lj/expand/sphere (o) <pair_lj_expand_sphere>`
    * :doc:`lj/gromacs (gko) <pair_gromacs>`
    * :doc:`lj/gromacs/coul/gromacs (ko) <pair_gromacs>`
    * :doc:`lj/long/coul/long (iot) <pair_lj_long>`

doc/src/Commands_removed.rst

@@ -38,6 +38,20 @@ been folded into the :doc:`reset_atoms <reset_atoms>` command.  If
 present, LAMMPS will replace the commands accordingly and print a
 warning.
 
+LATTE package
+-------------
+
+.. deprecated:: 15Jun2023
+
+The LATTE package with the fix latte command was removed from LAMMPS.
+This functionality has been superseded by :doc:`fix mdi/qm <fix_mdi_qm>`
+and :doc:`fix mdi/qmmm <fix_mdi_qmmm>` from the :ref:`MDI package
+<PKG-MDI>`.  These fixes are compatible with several quantum software
+packages, including LATTE.  See the ``examples/QUANTUM`` dir and the
+:doc:`MDI coupling HOWTO <Howto_mdi>` page.  MDI supports running LAMMPS
+with LATTE as a plugin library (similar to the way fix latte worked), as
+well as on a different set of MPI processors.
+
 MEAM package
 ------------
 

doc/src/Developer.rst

@@ -13,6 +13,7 @@ of time and requests from the LAMMPS user community.
    Developer_org
    Developer_code_design
    Developer_parallel
+   Developer_atom
    Developer_comm_ops
    Developer_flow
    Developer_write

doc/src/Developer_atom.rst

@@ -0,0 +1,88 @@
+Accessing per-atom data
+-----------------------
+
+This page discusses how per-atom data is managed in LAMMPS, how it can
+be accessed, what communication patters apply, and some of the utility
+functions that exist for a variety of purposes.
+
+
+Owned and ghost atoms
+^^^^^^^^^^^^^^^^^^^^^
+
+As described on the :doc:`parallel partitioning algorithms
+<Developer_par_part>` page, LAMMPS uses a domain decomposition of the
+simulation domain, either in a *brick* or *tiled* manner.  Each MPI
+process *owns* exactly one subdomain and the atoms within it. To compute
+forces for tuples of atoms that are spread across sub-domain boundaries,
+also a "halo" of *ghost* atoms are maintained within a the communication
+cutoff distance of its subdomain.
+
+The total number of atoms is stored in `Atom::natoms` (within any
+typical class this can be referred to at `atom->natoms`. The number of
+*owned* (or "local" atoms) are stored in `Atom::nlocal`; the number of
+*ghost* atoms is stored in `Atom::nghost`.  The sum of `Atom::nlocal`
+over all MPI processes should be `Atom::natoms`. This is by default
+regularly checked by the Thermo class, and if the sum does not match,
+LAMMPS stops with a "lost atoms" error.  For convenience also the
+property `Atom::nmax` is available, this is the maximum of
+`Atom::nlocal + Atom::nghost` across all MPI processes.
+
+Per-atom properties are either managed by the atom style, or individual
+classes.  or as custom arrays by the individual classes. If only access
+to *owned* atoms is needed, they are usually allocated to be of size
+`Atom::nlocal`, otherwise of size `Atom::nmax`. Please note that not all
+per-atom properties are available or updated on *ghost* atoms. For
+example, per-atom velocities are only updated with :doc:`comm_modify vel
+yes <comm_modify>`.
+
+
+Atom indexing
+^^^^^^^^^^^^^
+
+When referring to individual atoms, they may be indexed by their local
+*index*, their index in their `Atom::x` array. This is densely populated
+containing first all *owned* atoms (index < `Atom::nlocal`) and then all
+*ghost* atoms.  The order of atoms in these arrays can change due to
+atoms migrating between between subdomains, atoms being added or
+deleted, or atoms being sorted for better cache efficiency.  Atoms are
+globally uniquely identified by their *atom ID*. There may be multiple
+atoms with the same atom ID present, but only one of them may be an
+*owned* atom.
+
+To find the local *index* of an atom, when the *atom ID* is known, the
+`Atom::map()` function may be used. It will return the local atom index
+or -1. If the returned value is between 0 (inclusive) and `Atom::nlocal`
+(exclusive) it is an *owned* or "local" atom; for larger values the atom
+is present as a ghost atom; for a value of -1, the atom is not present
+on the current subdomain at all.
+
+If multiple atoms with the same tag exist in the same subdomain, they
+can be found via the `Atom::sametag` array. It points to the next atom
+index with the same tag or -1 if there are no more atoms with the same
+tag.  The list will be exhaustive when starting with an index of an
+*owned* atom, since the atom IDs are unique, so there can only be one
+such atom.  Example code to count atoms with same atom ID in subdomain:
+
+.. code-block:: c++
+
+   for (int i = 0; i < atom->nlocal; ++i) {
+     int count = 0;
+     while (sametag[i] >= 0) {
+       i = sametag[i];
+       ++count;
+     }
+     printf("Atom ID: %ld is present %d times\n", atom->tag[i], count);
+   }
+
+Atom class versus AtomVec classes
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The `Atom` class contains all kinds of flags and counters about atoms in
+the system and that includes pointers to **all** per-atom properties
+available for atoms.  However, only a subset of these pointers are
+non-NULL and which those are depends on the atom style.  For each atom
+style there is a corresponding `AtomVecXXX` class derived from the
+`AtomVec` base class, where the XXX indicates the atom style.  This
+`AtomVecXXX` class will update the counters and per-atom pointers if
+atoms are added or removed to the system or migrate between subdomains.
+

doc/src/Developer_comm_ops.rst

@@ -77,7 +77,7 @@ buffer, and they will be communicated together to minimize
 communication overhead.  The communication buffers are defined vectors
 containing ``double`` values.  To correctly store integers that may be
 64-bit (bigint, tagint, imageint) in the buffer, you need to use the
-`ubuf union <Communication buffer coding with ubuf>`_ construct.
+:ref:`ubuf union <communication_buffer_coding_with_ubuf>` construct.
 
 The *Fix*, *Compute*, and *Dump* classes can also invoke the same kind
 of forward and reverse communication operations using the same *Comm*

doc/src/Developer_notes.rst

@@ -11,6 +11,7 @@ Available topics are:
 
 - `Reading and parsing of text and text files`_
 - `Requesting and accessing neighbor lists`_
+- `Choosing between a custom atom style, fix property/atom, and fix STORE/ATOM`_
 - `Fix contributions to instantaneous energy, virial, and cumulative energy`_
 - `KSpace PPPM FFT grids`_
 
@@ -73,6 +74,8 @@ when converting "12.5", while the ValueTokenizer class will throw an
 :cpp:func:`ValueTokenizer::next_int()
 <LAMMPS_NS::ValueTokenizer::next_int>` is called on the same string.
 
+.. _request-neighbor-list:
+
 Requesting and accessing neighbor lists
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -216,6 +219,30 @@ command:
 
    neighbor->add_request(this, "delete_atoms", NeighConst::REQ_FULL);
 
+Choosing between a custom atom style, fix property/atom, and fix STORE/ATOM
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+There are multiple ways to manage per-atom data within LAMMPS.  Often
+the per-atom storage is only used locally and managed by the class that
+uses it.  If the data has to persist between multiple time steps and
+migrate with atoms when they move from sub-domain to sub-domain or
+across periodic boundaries, then using a custom atom style, or :doc:`fix
+property/atom <fix_property_atom>`, or the internal fix STORE/ATOM are
+possible options.
+
+- Using the atom style is usually the most programming effort and mostly
+  needed when the per-atom data is an integral part of the model like a
+  per-atom charge or diameter and thus should be part of the Atoms
+  section of a :doc:`data file <read_data>`.
+
+- Fix property/atom is useful if the data is optional or should be
+  entered by the user, or accessed as a (named) custom property. In this
+  case the fix should be entered as part of the input (and not
+  internally) which allows to enter and store its content with data files.
+
+- Fix STORE/ATOM should be used when the data should be accessed internally
+  only and thus the fix can be created internally.
+
 Fix contributions to instantaneous energy, virial, and cumulative energy
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 

doc/src/Developer_updating.rst

@@ -24,6 +24,7 @@ Available topics in mostly chronological order are:
 - `Use of "override" instead of "virtual"`_
 - `Simplified and more compact neighbor list requests`_
 - `Split of fix STORE into fix STORE/GLOBAL and fix STORE/PERATOM`_
+- `Rename of fix STORE/PERATOM to fix STORE/ATOM and change of arguments`_
 - `Use Output::get_dump_by_id() instead of Output::find_dump()`_
 - `Refactored grid communication using Grid3d/Grid2d classes instead of GridComm`_
 
@@ -385,6 +386,34 @@ New:
 
 This change is **required** or else the code will not compile.
 
+Rename of fix STORE/PERATOM to fix STORE/ATOM and change of arguments
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. versionchanged:: 28Mar2023
+
+The available functionality of the internal fix to store per-atom
+properties was expanded to enable storing data with ghost atoms and to
+support binary restart files.  With those changes, the fix was renamed
+to fix STORE/ATOM and the number and order of (required) arguments has
+changed.
+
+Old syntax: ``ID group-ID STORE/PERATOM rflag n1 n2 [n3]``
+
+- *rflag* = 0/1, *no*/*yes* store per-atom values in restart file
+- :math:`n1 = 1, n2 = 1, \mathrm{no}\;n3 \to` per-atom vector, single value per atom
+- :math:`n1 = 1, n2 > 1, \mathrm{no}\;n3 \to` per-atom array, *n2* values per atom
+- :math:`n1 = 1, n2 > 0, n3 > 0 \to` per-atom tensor, *n2* x *n3* values per atom
+
+New syntax:  ``ID group-ID STORE/ATOM n1 n2 gflag rflag``
+
+- :math:`n1 = 1, n2 = 0 \to` per-atom vector, single value per atom
+- :math:`n1 > 1, n2 = 0 \to` per-atom array, *n1* values per atom
+- :math:`n1 > 0, n2 > 0 \to` per-atom tensor, *n1* x *n2* values per atom
+- *gflag* = 0/1, *no*/*yes* communicate per-atom values with ghost atoms
+- *rflag* = 0/1, *no*/*yes* store per-atom values in restart file
+
+Since this is an internal fix, there is no user visible change.
+
 Use Output::get_dump_by_id() instead of Output::find_dump()
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 

doc/src/Developer_utils.rst

@@ -643,6 +643,8 @@ Tohoku University (under MIT license)
 
 ---------------------------
 
+.. _communication_buffer_coding_with_ubuf:
+
 Communication buffer coding with *ubuf*
 ---------------------------------------
 

doc/src/Developer_write.rst

@@ -6,250 +6,9 @@ be extended by writing new classes that derive from existing
 parent classes in LAMMPS.  Here, some specific coding
 details are provided for writing code for LAMMPS.
 
-Writing a new fix style
-^^^^^^^^^^^^^^^^^^^^^^^
 
-Writing fixes is a flexible way of extending LAMMPS.  Users can
-implement many things using fixes:
-
-- changing particles attributes (positions, velocities, forces, etc.). Examples: FixNVE, FixFreeze.
-- reading/writing data. Example: FixRestart.
-- adding or modifying properties due to geometry. Example: FixWall.
-- interacting with other subsystems or external code: Examples: FixTTM, FixExternal, FixLATTE
-- saving information for analysis or future use (previous positions,
-  for instance). Examples: Fix AveTime, FixStoreState.
-
-
-All fixes are derived from the Fix base class and must have a
-constructor with the signature: ``FixPrintVel(class LAMMPS *, int, char **)``.
-
-Every fix must be registered in LAMMPS by writing the following lines
-of code in the header before include guards:
-
-.. code-block:: c++
-
-   #ifdef FIX_CLASS
-   // clang-format off
-   FixStyle(print/vel,FixPrintVel);
-   // clang-format on
-   #else
-   /* the definition of the FixPrintVel class comes here */
-   ...
-   #endif
-
-Where ``print/vel`` is the style name of your fix in the input script and
-``FixPrintVel`` is the name of the class. The header file would be called
-``fix_print_vel.h`` and the implementation file ``fix_print_vel.cpp``.
-These conventions allow LAMMPS to automatically integrate it into the
-executable when compiling and associate your new fix class with the designated
-keyword when it parses the input script.
-
-Let's write a simple fix which will print the average velocity at the end
-of each timestep. First of all, implement a constructor:
-
-.. code-block:: c++
-
-   FixPrintVel::FixPrintVel(LAMMPS *lmp, int narg, char **arg)
-   : Fix(lmp, narg, arg)
-   {
-     if (narg < 4)
-       error->all(FLERR,"Illegal fix print/vel command");
-
-     nevery = utils::inumeric(FLERR,arg[3],false,lmp);
-     if (nevery <= 0)
-       error->all(FLERR,"Illegal fix print/vel command");
-   }
-
-In the constructor you should parse your fix arguments which are
-specified in the script. All fixes have pretty much the same syntax:
-``fix <fix-ID> <fix group> <fix name> <fix arguments ...>``. The
-first 3 parameters are parsed by Fix base class constructor, while
-``<fix arguments>`` should be parsed by you. In our case, we need to
-specify how often we want to print an average velocity. For instance,
-once in 50 timesteps: ``fix 1 print/vel 50``. There is a special variable
-in the Fix class called ``nevery`` which specifies how often the method
-``end_of_step()`` is called. Thus all we need to do is just set it up.
-
-The next method we need to implement is ``setmask()``:
-
-.. code-block:: c++
-
-   int FixPrintVel::setmask()
-   {
-     int mask = 0;
-     mask |= FixConst::END_OF_STEP;
-     return mask;
-   }
-
-Here the user specifies which methods of your fix should be called
-during execution. The constant ``END_OF_STEP`` corresponds to the
-``end_of_step()`` method. The most important available methods that
-are called during a timestep and the order in which they are called
-are shown in the previous section.
-
-.. code-block:: c++
-
-   void FixPrintVel::end_of_step()
-   {
-     // for add3, scale3
-     using namespace MathExtra;
-
-     double** v = atom->v;
-     int nlocal = atom->nlocal;
-     double localAvgVel[4]; // 4th element for particles count
-     memset(localAvgVel, 0, 4 * sizeof(double));
-     for (int particleInd = 0; particleInd < nlocal; ++particleInd) {
-       add3(localAvgVel, v[particleInd], localAvgVel);
-     }
-     localAvgVel[3] = nlocal;
-     double globalAvgVel[4];
-     memset(globalAvgVel, 0, 4 * sizeof(double));
-     MPI_Allreduce(localAvgVel, globalAvgVel, 4, MPI_DOUBLE, MPI_SUM, world);
-     scale3(1.0 / globalAvgVel[3], globalAvgVel);
-     if ((comm->me == 0) && screen) {
-       fmt::print(screen,"{}, {}, {}\n",
-                  globalAvgVel[0], globalAvgVel[1], globalAvgVel[2]);
-     }
-   }
-
-In the code above, we use MathExtra routines defined in
-``math_extra.h``.  There are bunch of math functions to work with
-arrays of doubles as with math vectors.  It is also important to note
-that LAMMPS code should always assume to be run in parallel and that
-atom data is thus distributed across the MPI ranks.  Thus you can
-only process data from local atoms directly and need to use MPI library
-calls to combine or exchange data.  For serial execution, LAMMPS
-comes bundled with the MPI STUBS library that contains the MPI library
-function calls in dummy versions that only work for a single MPI rank.
-
-In this code we use an instance of Atom class. This object is stored
-in the Pointers class (see ``pointers.h``) which is the base class of
-the Fix base class. This object contains references to various class
-instances (the original instances are created and held by the LAMMPS
-class) with all global information about the simulation system.
-Data from the Pointers class is available to all classes inherited from
-it using protected inheritance. Hence when you write you own class,
-which is going to use LAMMPS data, don't forget to inherit from Pointers
-or pass an Pointer to it to all functions that need access. When writing
-fixes we inherit from class Fix which is inherited from Pointers so
-there is no need to inherit from it directly.
-
-The code above computes average velocity for all particles in the
-simulation.  Yet you have one unused parameter in fix call from the
-script: ``group_name``.  This parameter specifies the group of atoms
-used in the fix. So we should compute average for all particles in the
-simulation only if ``group_name == "all"``, but it can be any group.
-The group membership information of an atom is contained in the *mask*
-property of and atom and the bit corresponding to a given group is
-stored in the groupbit variable which is defined in Fix base class:
-
-.. code-block:: c++
-
-   for (int i = 0; i < nlocal; ++i) {
-     if (atom->mask[i] & groupbit) {
-     // Do all job here
-     }
-   }
-
-Class Atom encapsulates atoms positions, velocities, forces, etc. User
-can access them using particle index. Note, that particle indexes are
-usually changed every few timesteps because of neighbor list rebuilds
-and spatial sorting (to improve cache efficiency).
-
-Let us consider another Fix example: We want to have a fix which stores
-atoms position from previous time step in your fix. The local atoms
-indexes may not be valid on the next iteration. In order to handle
-this situation there are several methods which should be implemented:
-
-- ``double memory_usage()``: return how much memory the fix uses (optional)
-- ``void grow_arrays(int)``: do reallocation of the per particle arrays in your fix
-- ``void copy_arrays(int i, int j, int delflag)``: copy i-th per-particle
-  information to j-th. Used when atom sorting is performed. if delflag is set
-  and atom j owns a body, move the body information to atom i.
-- ``void set_arrays(int i)``: sets i-th particle related information to zero
-
-Note, that if your class implements these methods, it must call add calls of
-add_callback and delete_callback to constructor and destructor. Since we want
-to store positions of atoms from previous timestep, we need to add
-``double** xold`` to the header file. Than add allocation code
-to the constructor:
-
-.. code-block:: c++
-
-   FixSavePos::FixSavePos(LAMMPS *lmp, int narg, char **arg), xold(nullptr)
-   {
-   //...
-     memory->create(xold, atom->nmax, 3, "FixSavePos:x");
-     atom->add_callback(0);
-   }
-
-   FixSavePos::~FixSavePos() {
-     atom->delete_callback(id, 0);
-     memory->destroy(xold);
-   }
-
-Implement the aforementioned methods:
-
-.. code-block:: c++
-
-   double FixSavePos::memory_usage()
-   {
-     int nmax = atom->nmax;
-     double bytes = 0.0;
-     bytes += nmax * 3 * sizeof(double);
-     return bytes;
-   }
-
-   void FixSavePos::grow_arrays(int nmax)
-   {
-     memory->grow(xold, nmax, 3, "FixSavePos:xold");
-   }
-
-   void FixSavePos::copy_arrays(int i, int j, int delflag)
-   {
-     memcpy(xold[j], xold[i], sizeof(double) * 3);
-   }
-
-   void FixSavePos::set_arrays(int i)
-   {
-     memset(xold[i], 0, sizeof(double) * 3);
-   }
-
-   int FixSavePos::pack_exchange(int i, double *buf)
-   {
-     int m = 0;
-     buf[m++] = xold[i][0];
-     buf[m++] = xold[i][1];
-     buf[m++] = xold[i][2];
-
-     return m;
-   }
-
-   int FixSavePos::unpack_exchange(int nlocal, double *buf)
-   {
-     int m = 0;
-     xold[nlocal][0] = buf[m++];
-     xold[nlocal][1] = buf[m++];
-     xold[nlocal][2] = buf[m++];
-
-     return m;
-   }
-
-Now, a little bit about memory allocation. We use the Memory class which
-is just a bunch of template functions for allocating 1D and 2D
-arrays. So you need to add include ``memory.h`` to have access to them.
-
-Finally, if you need to write/read some global information used in
-your fix to the restart file, you might do it by setting flag
-``restart_global = 1`` in the constructor and implementing methods void
-``write_restart(FILE *fp)`` and ``void restart(char *buf)``.
-If, in addition, you want to write the per-atom property to restart
-files additional settings and functions are needed:
-
-- a fix flag indicating this needs to be set ``restart_peratom = 1;``
-- ``atom->add_callback()`` and ``atom->delete_callback()`` must be called
-  a second time with the final argument set to 1 instead of 0 (indicating
-  restart processing instead of per-atom data memory management).
-- the functions ``void pack_restart(int i, double *buf)`` and
-  ``void unpack_restart(int nlocal, int nth)`` need to be implemented
+.. toctree::
+   :maxdepth: 1
 
+   Developer_write_pair
+   Developer_write_fix

doc/src/Developer_write_fix.rst

@@ -0,0 +1,245 @@
+Writing a new fix style
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Writing fix styles is a flexible way of extending LAMMPS.  Users can
+implement many things using fixes.  Some fix styles are only used
+internally to support compute styles or pair styles:
+
+- change particles attributes (positions, velocities, forces, etc.). Examples: ``FixNVE``, ``FixFreeze``.
+- read or write data.  Example: ``FixRestart``.
+- adding or modifying properties due to geometry. Example: ``FixWall``.
+- interacting with other subsystems or external code: Examples: ``FixTTM``, ``FixExternal``, ``FixMDI``
+- saving information for analysis or future use (previous positions,
+  for instance). Examples: ``FixAveTime``, ``FixStoreState``.
+
+All fixes are derived from the ``Fix`` base class and must have a
+constructor with the signature: ``FixPrintVel(class LAMMPS *, int, char **)``.
+
+Every fix must be registered in LAMMPS by writing the following lines
+of code in the header before include guards:
+
+.. code-block:: c++
+
+   #ifdef FIX_CLASS
+   // clang-format off
+   FixStyle(print/vel,FixPrintVel);
+   // clang-format on
+   #else
+   /* the definition of the FixPrintVel class comes here */
+   ...
+   #endif
+
+Where ``print/vel`` is the style name of your fix in the input script and
+``FixPrintVel`` is the name of the class. The header file would be called
+``fix_print_vel.h`` and the implementation file ``fix_print_vel.cpp``.
+These conventions allow LAMMPS to automatically integrate it into the
+executable when compiling and associate your new fix class with the designated
+keyword when it parses the input script.
+
+Let's write a simple fix which will print the average velocity at the end
+of each timestep. First of all, implement a constructor:
+
+.. code-block:: c++
+
+   FixPrintVel::FixPrintVel(LAMMPS *lmp, int narg, char **arg)
+   : Fix(lmp, narg, arg)
+   {
+     if (narg < 4) utils::missing_cmd_args(FLERR, "fix print/vel", error);
+
+     nevery = utils::inumeric(FLERR,arg[3],false,lmp);
+     if (nevery <= 0)
+       error->all(FLERR,"Illegal fix print/vel nevery value: {}", nevery);
+   }
+
+In the constructor you should parse the fix arguments which are
+specified in the script.  All fixes have pretty much the same syntax:
+``fix <fix-ID> <fix group> <fix name> <fix arguments ...>``. The first 3
+parameters are parsed by Fix base class constructor, while ``<fix
+arguments>`` should be parsed by you.  In our case, we need to specify
+how often we want to print an average velocity. For instance, once in 50
+timesteps: ``fix 1 print/vel 50``. There is a special variable in the
+Fix class called ``nevery`` which specifies how often the method
+``end_of_step()`` is called.  Thus all we need to do is just set it up.
+
+The next method we need to implement is ``setmask()``:
+
+.. code-block:: c++
+
+   int FixPrintVel::setmask()
+   {
+     int mask = 0;
+     mask |= FixConst::END_OF_STEP;
+     return mask;
+   }
+
+Here the we specify which methods of the fix should be called during
+:doc:`execution of a timestep <Developer_flow>`.  The constant
+``END_OF_STEP`` corresponds to the ``end_of_step()`` method. The most
+important available methods that are called during a timestep.
+
+.. code-block:: c++
+
+   void FixPrintVel::end_of_step()
+   {
+     // for add3, scale3
+     using namespace MathExtra;
+
+     double** v = atom->v;
+     int nlocal = atom->nlocal;
+     double localAvgVel[4]; // 4th element for particles count
+     memset(localAvgVel, 0, 4 * sizeof(double));
+     for (int particleInd = 0; particleInd < nlocal; ++particleInd) {
+       add3(localAvgVel, v[particleInd], localAvgVel);
+     }
+     localAvgVel[3] = nlocal;
+     double globalAvgVel[4];
+     memset(globalAvgVel, 0, 4 * sizeof(double));
+     MPI_Allreduce(localAvgVel, globalAvgVel, 4, MPI_DOUBLE, MPI_SUM, world);
+     scale3(1.0 / globalAvgVel[3], globalAvgVel);
+     if ((comm->me == 0) && screen) {
+       fmt::print(screen,"{}, {}, {}\n",
+                  globalAvgVel[0], globalAvgVel[1], globalAvgVel[2]);
+     }
+   }
+
+In the code above, we use MathExtra routines defined in
+``math_extra.h``.  There are bunch of math functions to work with
+arrays of doubles as with math vectors.  It is also important to note
+that LAMMPS code should always assume to be run in parallel and that
+atom data is thus distributed across the MPI ranks.  Thus you can
+only process data from local atoms directly and need to use MPI library
+calls to combine or exchange data.  For serial execution, LAMMPS
+comes bundled with the MPI STUBS library that contains the MPI library
+function calls in dummy versions that only work for a single MPI rank.
+
+In this code we use an instance of Atom class. This object is stored
+in the Pointers class (see ``pointers.h``) which is the base class of
+the Fix base class. This object contains references to various class
+instances (the original instances are created and held by the LAMMPS
+class) with all global information about the simulation system.
+Data from the Pointers class is available to all classes inherited from
+it using protected inheritance. Hence when you write you own class,
+which is going to use LAMMPS data, don't forget to inherit from Pointers
+or pass a Pointer to it to all functions that need access. When writing
+fixes we inherit from class Fix which is inherited from Pointers so
+there is no need to inherit from it directly.
+
+The code above computes average velocity for all particles in the
+simulation.  Yet you have one unused parameter in fix call from the
+script: ``group_name``.  This parameter specifies the group of atoms
+used in the fix. So we should compute average for all particles in the
+simulation only if ``group_name == "all"``, but it can be any group.
+The group membership information of an atom is contained in the *mask*
+property of an atom and the bit corresponding to a given group is
+stored in the groupbit variable which is defined in Fix base class:
+
+.. code-block:: c++
+
+   for (int i = 0; i < nlocal; ++i) {
+     if (atom->mask[i] & groupbit) {
+     // Do all job here
+     }
+   }
+
+Class Atom encapsulates atoms positions, velocities, forces, etc. Users
+can access them using particle index. Note, that particle indexes are
+usually changed every few timesteps because of neighbor list rebuilds
+and spatial sorting (to improve cache efficiency).
+
+Let us consider another Fix example: We want to have a fix which stores
+atoms position from the previous time step in your fix. The local atoms
+indexes may not be valid on the next iteration. In order to handle
+this situation there are several methods which should be implemented:
+
+- ``double memory_usage()``: return how much memory the fix uses (optional)
+- ``void grow_arrays(int)``: do reallocation of the per-particle arrays in your fix
+- ``void copy_arrays(int i, int j, int delflag)``: copy i-th per-particle
+  information to j-th. Used when atom sorting is performed. if delflag is set
+  and atom j owns a body, move the body information to atom i.
+- ``void set_arrays(int i)``: sets i-th particle related information to zero
+
+Note, that if your class implements these methods, it must add calls of
+add_callback and delete_callback to the constructor and destructor. Since we want
+to store positions of atoms from the previous timestep, we need to add
+``double** xold`` to the header file. Than add allocation code
+to the constructor:
+
+.. code-block:: c++
+
+   FixSavePos::FixSavePos(LAMMPS *lmp, int narg, char **arg), xold(nullptr)
+   {
+   //...
+     memory->create(xold, atom->nmax, 3, "FixSavePos:x");
+     atom->add_callback(0);
+   }
+
+   FixSavePos::~FixSavePos() {
+     atom->delete_callback(id, 0);
+     memory->destroy(xold);
+   }
+
+Implement the aforementioned methods:
+
+.. code-block:: c++
+
+   double FixSavePos::memory_usage()
+   {
+     int nmax = atom->nmax;
+     double bytes = 0.0;
+     bytes += nmax * 3 * sizeof(double);
+     return bytes;
+   }
+
+   void FixSavePos::grow_arrays(int nmax)
+   {
+     memory->grow(xold, nmax, 3, "FixSavePos:xold");
+   }
+
+   void FixSavePos::copy_arrays(int i, int j, int delflag)
+   {
+     memcpy(xold[j], xold[i], sizeof(double) * 3);
+   }
+
+   void FixSavePos::set_arrays(int i)
+   {
+     memset(xold[i], 0, sizeof(double) * 3);
+   }
+
+   int FixSavePos::pack_exchange(int i, double *buf)
+   {
+     int m = 0;
+     buf[m++] = xold[i][0];
+     buf[m++] = xold[i][1];
+     buf[m++] = xold[i][2];
+
+     return m;
+   }
+
+   int FixSavePos::unpack_exchange(int nlocal, double *buf)
+   {
+     int m = 0;
+     xold[nlocal][0] = buf[m++];
+     xold[nlocal][1] = buf[m++];
+     xold[nlocal][2] = buf[m++];
+
+     return m;
+   }
+
+Now, a little bit about memory allocation. We use the Memory class which
+is just a bunch of template functions for allocating 1D and 2D
+arrays. So you need to add include ``memory.h`` to have access to them.
+
+Finally, if you need to write/read some global information used in
+your fix to the restart file, you might do it by setting flag
+``restart_global = 1`` in the constructor and implementing methods void
+``write_restart(FILE *fp)`` and ``void restart(char *buf)``.
+If, in addition, you want to write the per-atom property to restart
+files additional settings and functions are needed:
+
+- a fix flag indicating this needs to be set ``restart_peratom = 1;``
+- ``atom->add_callback()`` and ``atom->delete_callback()`` must be called
+  a second time with the final argument set to 1 instead of 0 (indicating
+  restart processing instead of per-atom data memory management).
+- the functions ``void pack_restart(int i, double *buf)`` and
+  ``void unpack_restart(int nlocal, int nth)`` need to be implemented
+

doc/src/Errors_debug.rst

@@ -75,7 +75,7 @@ Using the GDB debugger to get a stack trace
 There are two options to use the GDB debugger for identifying the origin
 of the segmentation fault or similar crash. The GDB debugger has many
 more features and options, as can be seen for example its `online
-documentation <https://sourceware.org/gdb/current/onlinedocs/gdb/>`_.
+documentation <https://www.sourceware.org/gdb/documentation/>`_.
 
 Run LAMMPS from within the debugger
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

doc/src/Examples.rst

@@ -94,8 +94,6 @@ Lowercase directories
 +-------------+------------------------------------------------------------------+
 | kim         | use of potentials from the `OpenKIM Repository <openkim_>`_      |
 +-------------+------------------------------------------------------------------+
-| latte       | examples for using fix latte for DFTB via the LATTE library      |
-+-------------+------------------------------------------------------------------+
 | mdi         | use of the MDI package and MolSSI MDI code coupling library      |
 +-------------+------------------------------------------------------------------+
 | meam        | MEAM test for SiC and shear (same as shear examples)             |

doc/src/Fortran.rst

@@ -205,12 +205,14 @@ Below is an example demonstrating some of the possible uses.
 
    PROGRAM testprop
      USE LIBLAMMPS
-    USE, INTRINSIC :: ISO_C_BINDING, ONLY : c_double, c_int64_t
+     USE, INTRINSIC :: ISO_C_BINDING, ONLY : c_double, c_int64_t, c_int
      USE, INTRINSIC :: ISO_FORTRAN_ENV, ONLY : OUTPUT_UNIT
      TYPE(lammps) :: lmp
-    INTEGER(KIND=c_int64_t), POINTER :: natoms
-    REAL(KIND=c_double), POINTER :: dt
-    INTEGER(KIND=c_int64_t), POINTER :: ntimestep
+     INTEGER(KIND=c_int64_t), POINTER :: natoms, ntimestep, bval
+     REAL(KIND=c_double), POINTER :: dt, dval
+     INTEGER(KIND=c_int), POINTER :: nfield, typ, ival
+     INTEGER(KIND=c_int) :: i
+     CHARACTER(LEN=11) :: key
      REAL(KIND=c_double) :: pe, ke
 
      lmp = lammps()
@@ -222,6 +224,26 @@ Below is an example demonstrating some of the possible uses.
          lmp%extract_setting('ntypes'), ' atom types'
 
      CALL lmp%command('run 2 post no')
+
+     ntimestep = lmp%last_thermo('step', 0)
+     nfield = lmp%last_thermo('num', 0)
+     WRITE(OUTPUT_UNIT,'(A,I0,A,I0)') 'Last thermo output on step: ', ntimestep, &
+         ',  number of fields: ', nfield
+     DO i=1, nfield
+         key = lmp%last_thermo('keyword',i)
+         typ = lmp%last_thermo('type',i)
+         IF (typ == lmp%dtype%i32) THEN
+             ival = lmp%last_thermo('data',i)
+             WRITE(OUTPUT_UNIT,*) key, ':', ival
+         ELSE IF (typ == lmp%dtype%i64) THEN
+             bval = lmp%last_thermo('data',i)
+             WRITE(OUTPUT_UNIT,*) key, ':', bval
+         ELSE IF (typ == lmp%dtype%r64) THEN
+             dval = lmp%last_thermo('data',i)
+             WRITE(OUTPUT_UNIT,*) key, ':', dval
+         END IF
+     END DO
+
      dt = lmp%extract_global('dt')
      ntimestep = lmp%extract_global('ntimestep')
      WRITE(OUTPUT_UNIT,'(A,I0,A,F4.1,A)') 'At step: ', ntimestep, &
@@ -232,8 +254,8 @@ Below is an example demonstrating some of the possible uses.
      WRITE(OUTPUT_UNIT,'(A,I0)') 'At step: ', ntimestep
      pe = lmp%get_thermo('pe')
      ke = lmp%get_thermo('ke')
-    PRINT*, 'PE = ', pe
-    PRINT*, 'KE = ', ke
+     WRITE(OUTPUT_UNIT,*) 'PE = ', pe
+     WRITE(OUTPUT_UNIT,*) 'KE = ', ke
 
      CALL lmp%close(.TRUE.)
    END PROGRAM testprop
@@ -262,6 +284,8 @@ of the contents of the :f:mod:`LIBLAMMPS` Fortran interface to LAMMPS.
    :ftype style: type(lammps_style)
    :f type: derived type to access lammps type constants
    :ftype type: type(lammps_type)
+   :f dtype: derived type to access lammps data type constants
+   :ftype dtype: type(lammps_dtype)
    :f close: :f:subr:`close`
    :ftype close: subroutine
    :f subroutine error: :f:subr:`error`
@@ -278,6 +302,8 @@ of the contents of the :f:mod:`LIBLAMMPS` Fortran interface to LAMMPS.
    :ftype get_natoms: function
    :f get_thermo: :f:func:`get_thermo`
    :ftype get_thermo: function
+   :f last_thermo: :f:func:`last_thermo`
+   :ftype last_thermo: function
    :f extract_box: :f:subr:`extract_box`
    :ftype extract_box: subroutine
    :f reset_box: :f:subr:`reset_box`
@@ -587,6 +613,96 @@ Procedures Bound to the :f:type:`lammps` Derived Type
 
 --------
 
+.. f:function:: last_thermo(what, index)
+
+   This function will call :cpp:func:`lammps_last_thermo` and returns
+   either a string or a pointer to a cached copy of LAMMPS last thermodynamic
+   output, depending on the data requested through *what*.  Note that *index*
+   uses 1-based indexing to access thermo output columns.
+
+   .. versionadded:: 15Jun2023
+
+   Note that this function actually does not return a value, but rather
+   associates the pointer on the left side of the assignment to point to
+   internal LAMMPS data (with the exception of string data, which are
+   copied and returned as ordinary Fortran strings).  Pointers must be
+   of the correct data type to point to said data (typically
+   ``INTEGER(c_int)``, ``INTEGER(c_int64_t)``, or ``REAL(c_double)``).
+   The pointer being associated with LAMMPS data is type-checked at
+   run-time via an overloaded assignment operator.  The pointers
+   returned by this function point to temporary, read-only data that may
+   be overwritten at any time, so their target values need to be copied
+   to local storage if they are supposed to persist.
+
+   For example,
+
+   .. code-block:: fortran
+
+      PROGRAM thermo
+        USE LIBLAMMPS
+        USE, INTRINSIC :: ISO_C_BINDING, ONLY : c_double, c_int64_t, c_int
+        TYPE(lammps) :: lmp
+        INTEGER(KIND=c_int64_t), POINTER :: ntimestep, bval
+        REAL(KIND=c_double), POINTER :: dval
+        INTEGER(KIND=c_int), POINTER :: nfield, typ, ival
+        INTEGER(KIND=c_int) :: i
+        CHARACTER(LEN=11) :: key
+
+        lmp = lammps()
+        CALL lmp%file('in.sysinit')
+
+        ntimestep = lmp%last_thermo('step', 0)
+        nfield = lmp%last_thermo('num', 0)
+        PRINT*, 'Last thermo output on step: ', ntimestep, '  Number of fields: ', nfield
+        DO i=1, nfield
+            key = lmp%last_thermo('keyword',i)
+            typ = lmp%last_thermo('type',i)
+            IF (typ == lmp%dtype%i32) THEN
+                ival = lmp%last_thermo('data',i)
+                PRINT*, key, ':', ival
+            ELSE IF (typ == lmp%dtype%i64) THEN
+                bval = lmp%last_thermo('data',i)
+                PRINT*, key, ':', bval
+            ELSE IF (typ == lmp%dtype%r64) THEN
+                dval = lmp%last_thermo('data',i)
+                PRINT*, key, ':', dval
+            END IF
+        END DO
+        CALL lmp%close(.TRUE.)
+      END PROGRAM thermo
+
+   would extract the last timestep where thermo output was done and the number
+   of columns it printed.  Then it loops over the columns to print out column
+   header keywords and the corresponding data.
+
+   .. note::
+
+      If :f:func:`last_thermo` returns a string, the string must have a length
+      greater than or equal to the length of the string (not including the
+      terminal ``NULL`` character) that LAMMPS returns. If the variable's
+      length is too short, the string will be truncated.  As usual in Fortran,
+      strings are padded with spaces at the end.  If you use an allocatable
+      string, the string **must be allocated** prior to calling this function.
+
+   :p character(len=\*) what: string with the name of the thermo keyword
+   :p integer(c_int) index: 1-based column index
+   :to: :cpp:func:`lammps_last_thermo`
+   :r pointer [polymorphic]: pointer to LAMMPS data. The left-hand side of the
+    assignment should be either a string (if expecting string data) or a
+    C-compatible pointer (e.g., ``INTEGER(c_int), POINTER :: nlocal``) to the
+    extracted property.
+
+   .. warning::
+
+       Modifying the data in the location pointed to by the returned pointer
+       may lead to inconsistent internal data and thus may cause failures,
+       crashes, or bogus simulations.  In general, it is much better
+       to use a LAMMPS input command that sets or changes these parameters.
+       Using an input command will take care of all side effects and necessary
+       updates of settings derived from such settings.
+
+--------
+
 .. f:subroutine:: extract_box([boxlo][, boxhi][, xy][, yz][, xz][, pflags][, boxflag])
 
    This subroutine will call :cpp:func:`lammps_extract_box`. All
@@ -764,13 +880,14 @@ Procedures Bound to the :f:type:`lammps` Derived Type
 
    .. note::
 
-      If :f:func:`extract_global` returns a string, the string must have length
-      greater than or equal to the length of the string (not including the
-      terminal ``NULL`` character) that LAMMPS returns. If the variable's
-      length is too short, the string will be truncated. As usual in Fortran,
-      strings are padded with spaces at the end. If you use an allocatable
-      string, the string **must be allocated** prior to calling this function,
-      but you can automatically reallocate it to the correct length after the
+      If :f:func:`extract_global` returns a string, the string must have
+      a length greater than or equal to the length of the string (not
+      including the terminal ``NULL`` character) that LAMMPS returns. If
+      the variable's length is too short, the string will be
+      truncated. As usual in Fortran, strings are padded with spaces at
+      the end. If you use an allocatable string, the string **must be
+      allocated** prior to calling this function, but you can
+      automatically reallocate it to the correct length after the
       function returns, viz.,
 
       .. code-block :: fortran
@@ -2155,7 +2272,7 @@ Procedures Bound to the :f:type:`lammps` Derived Type
 
    The LAMMPS :doc:`dump style movie <dump_image>` supports generating movies
    from images on-the-fly via creating a pipe to the
-   `ffmpeg <https://ffmpeg.org/ffmpeg/>`_ program.
+   `ffmpeg <https://ffmpeg.org/>`_ program.
    This function checks whether this feature was
    :ref:`enabled at compile time <graphics>`.
    It does **not** check whether the ``ffmpeg`` itself is installed and usable.

doc/src/Howto.rst

@@ -23,7 +23,6 @@ General howto
    Howto_library
    Howto_couple
    Howto_mdi
-   Howto_bpm
    Howto_broken_bonds
 
 Settings howto
@@ -70,6 +69,7 @@ Force fields howto
    Howto_amoeba
    Howto_tip3p
    Howto_tip4p
+   Howto_tip5p
    Howto_spc
 
 Packages howto
@@ -82,6 +82,7 @@ Packages howto
    Howto_spherical
    Howto_granular
    Howto_body
+   Howto_bpm
    Howto_polarizable
    Howto_coreshell
    Howto_drude

doc/src/Howto_broken_bonds.rst

@@ -1,48 +1,56 @@
 Broken Bonds
 ============
 
-Typically, bond interactions persist for the duration of a simulation in
-LAMMPS. However, there are some exceptions that allow for bonds to
-break, including the :doc:`quartic bond style <bond_quartic>` and the
-bond styles in the :doc:`BPM package <Howto_bpm>` which contains the
-:doc:`bpm/spring <bond_bpm_spring>` and :doc:`bpm/rotational
-<bond_bpm_rotational>` bond styles. In these cases, a bond can be broken
-if it is stretched beyond a user-defined threshold.  LAMMPS accomplishes
-this by setting the bond type to 0, such that the bond force is no
-longer computed.
+Typically, molecular bond interactions persist for the duration of a
+simulation in LAMMPS.  However, some commands break bonds dynamically,
+including the following:
 
-Users are normally able to weight the contribution of pair forces to atoms
-that are bonded using the :doc:`special_bonds command <special_bonds>`.
-When bonds break, this is not always the case. For the quartic bond style,
-pair forces are always turned off between bonded particles. LAMMPS does
-this via a computational sleight-of-hand. It subtracts the pairwise
-interaction as part of the bond computation. When the bond breaks, the
-subtraction stops.  For this to work, the pairwise interaction must always
-be computed by the :doc:`pair_style <pair_style>` command, whether the bond
-is broken or not.  This means that :doc:`special_bonds <special_bonds>` must
-be set to 1,1,1. After the bond breaks, the pairwise interaction between the
-two atoms is turned on, since they are no longer bonded.
+* :doc:`bond_style quartic <bond_quartic>`
+* :doc:`fix bond/break <fix_bond_break>`
+* :doc:`fix bond/react <fix_bond_react>`
+* :doc:`BPM package <Howto_bpm>` bond styles
 
-In the BPM package, one can either turn off all pair interactions between
-bonded particles or leave them on, overlaying pair forces on top of bond
-forces. To remove pair forces, the special bond list is dynamically
-updated. More details can be found on the :doc:`Howto BPM <Howto_bpm>`
-page.
+A bond can break if it is stretched beyond a user-defined threshold or
+more generally if other criteria are met.
 
-Bonds can also be broken by fixes which change bond topology, including
-:doc:`fix bond/break <fix_bond_break>` and
-:doc:`fix bond/react <fix_bond_react>`. These fixes will automatically
-trigger a rebuild of the neighbor list and update special bond data structures
-when bonds are broken.
+For the quartic bond style, when a bond is broken its bond type is set
+to 0 to effectively break it and pairwise forces between the two atoms
+in the broken bond are "turned on".  Angles, dihedrals, etc cannot be
+defined for a system when :doc:`bond_style quartic <bond_quartic>` is
+used.
 
-Note that when bonds are dumped to a file via the :doc:`dump local <dump>` command, bonds with type 0 are not included.  The
-:doc:`delete_bonds <delete_bonds>` command can also be used to query the
-status of broken bonds or permanently delete them, e.g.:
+Similarly, bond styles in the BPM package are also incompatible with
+angles, dihedrals, etc. and when a bond breaks its type is set to zero.
+However, in the BPM package one can either turn off all pair interactions
+between bonded particles or leave them on, overlaying pair forces on
+top of bond forces. To remove pair forces, the special bond list is
+dynamically updated.  More details can be found on the :doc:`Howto BPM
+<Howto_bpm>` page.
+
+The :doc:`fix bond/break <fix_bond_break>` and :doc:`fix bond/react
+<fix_bond_react>` commands allow breaking of bonds within a molecular
+topology with may also define angles, dihedrals, etc.  These commands
+update internal topology data structures to remove broken bonds, as
+well as the appropriate angle, dihedral, etc interactions which
+include the bond.  They also trigger a rebuild of the neighbor list
+when this occurs, to turn on the appropriate pairwise forces.
+
+Note that when bonds are dumped to a file via the :doc:`dump local
+<dump>` command, bonds with type 0 are not included.
+
+The :doc:`delete_bonds <delete_bonds>` command can be used to query
+the status of broken bonds with type = 0 or permanently delete them,
+e.g.:
 
 .. code-block:: LAMMPS
 
    delete_bonds all stats
    delete_bonds all bond 0 remove
 
-The compute :doc:`nbond/atom <compute_nbond_atom>` can also be used
-to tally the current number of bonds per atom, excluding broken bonds.
+The compute :doc:`count/type <compute_count_type>` command tallies the
+current number of bonds (or angles, etc) for each bond (angle, etc)
+type.  It also tallies broken bonds with type = 0.
+
+The compute :doc:`nbond/atom <compute_nbond_atom>` command tallies the
+current number of bonds each atom is part of, excluding broken bonds
+with type = 0.

doc/src/Howto_couple.rst

@@ -12,16 +12,16 @@ LAMMPS can be coupled to other codes in at least 4 different ways.  Each
 has advantages and disadvantages, which you will have to think about in
 the context of your application.
 
-1. Define a new :doc:`fix <fix>` command that calls the other code.  In
-   this scenario, LAMMPS is the driver code.  During timestepping, the
-   fix is invoked, and can make library calls to the other code, which
-   has been linked to LAMMPS as a library.  This is the way the
-   :ref:`LATTE <PKG-LATTE>` package, which performs density-functional
-   tight-binding calculations using the `LATTE software
-   <https://github.com/lanl/LATTE>`_ to compute forces, is interfaced to
-   LAMMPS.  See the :doc:`fix latte <fix_latte>` command for more
+1. Define a new :doc:`fix <fix>` or :doc:`compute <compute>` command
+   that calls the other code.  In this scenario, LAMMPS is the driver
+   code.  During timestepping, the fix or compute is invoked, and can
+   make library calls to the other code, which has been linked to LAMMPS
+   as a library.  This is the way the :ref:`VORONOI <PKG-VORONOI>`
+   package, which computes Voronoi tesselations using the `Voro++
+   library <http://math.lbl.gov/voro++>`_, is interfaced to LAMMPS.  See
+   the :doc:`compute voronoi <compute_voronoi_atom>` command for more
    details.  Also see the :doc:`Modify <Modify>` pages for information
-   on how to add a new fix to LAMMPS.
+   on how to add a new fix or compute to LAMMPS.
 
 .. spacer
 

doc/src/Howto_github.rst

@@ -476,16 +476,25 @@ to your remote(s) as well:
 
 **Recent changes in the workflow**
 
-Some 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* and a *stable* branch;
-these have the same content as *develop*, but are only updated after a
-patch release or stable release was made.  Furthermore, the naming of
-the patches now follow the pattern "patch_<Day><Month><Year>" to
-simplify comparisons between releases.  Finally, all patches and
-submissions are subject to automatic testing and code checks to make
-sure they at the very least compile.
+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.
 
-A discussion of the LAMMPS developer GitHub workflow can be found in the
-file `doc/github-development-workflow.md
+Furthermore, the naming of the release tags now follow the pattern
+"patch_<Day><Month><Year>" to simplify comparisons between releases.
+For stable releases additional "stable_<Day><Month><Year>" tags are
+applied and update releases are tagged with
+"stable_<Day><Month><Year>_update<Number>", Finally, all releases and
+submissions are subject to automatic testing and code checks to make
+sure they compile with a variety of compilers and popular operating
+systems.  Some unit and regression testing is applied as well.
+
+A detailed discussion of the LAMMPS developer GitHub workflow can be
+found in the file `doc/github-development-workflow.md
 <https://github.com/lammps/lammps/blob/develop/doc/github-development-workflow.md>`_

doc/src/Howto_granular.rst

@@ -43,6 +43,15 @@ The fix style *freeze* zeroes both the force and torque of frozen
 atoms, and should be used for granular system instead of the fix style
 *setforce*\ .
 
+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>`
+
 For computational efficiency, you can eliminate needless pairwise
 computations between frozen atoms by using this command:
 
@@ -55,3 +64,6 @@ computations between frozen atoms by using this command:
    will be the same as in 3d.  If you wish to model granular particles in
    2d as 2d discs, see the note on this topic on the :doc:`Howto 2d <Howto_2d>`
    doc page, where 2d simulations are discussed.
+
+To add custom granular contact models, see the
+:doc:`modifying granular sub-models page <Modify_gran_sub_mod>`.

doc/src/Howto_mdi.rst

@@ -63,22 +63,29 @@ The package also provides a :doc:`mdi plugin <mdi>` command, which
 enables LAMMPS to operate as an MDI driver and load an MDI engine as a
 plugin library.
 
-The package furthermore includes a `fix mdi/qm <fix_mdi_qm>` command, in
-which LAMMPS operates as an MDI driver in conjunction with a quantum
-mechanics code as an MDI engine.  The post_force() method of the
-``fix_mdi_qm.cpp`` file shows how a driver issues MDI commands to another
-code.  This command can be used to couple to an MDI engine, which is
-either a stand-alone code or a plugin library.
+The package furthermore includes a :doc:`fix mdi/qm <fix_mdi_qm>`
+command, in which LAMMPS operates as an MDI driver in conjunction with a
+quantum mechanics code as an MDI engine.  The post_force() method of the
+``fix_mdi_qm.cpp`` file shows how a driver issues MDI commands to
+another code.  This command can be used to couple to an MDI engine,
+which is either a stand-alone code or a plugin library.
 
-As explained in the `fix mdi/qm <fix_mdi_qm>` command documentation, it
-can be used to perform *ab initio* MD simulations or energy
-minimizations, or to evaluate the quantum energy and forces for a series
-of independent systems.  The ``examples/mdi`` directory has example
-input scripts for all of these use cases.
+As explained in the :doc:`fix mdi/qm <fix_mdi_qm>` command
+documentation, it can be used to perform *ab initio* MD simulations or
+energy minimizations, or to evaluate the quantum energy and forces for a
+series of independent systems.  The ``examples/mdi`` directory has
+example input scripts for all of these use cases.
+
+The package also has a :doc:`fix mdi/qmmm <fix_mdi_qmmm>` command in
+which LAMMPS operates as an MDI driver in conjunction with a quantum
+mechanics code as an MDI engine to perform QM/MM simulations.  The
+LAMMPS input script partitions the system into QM and MM (molecular
+mechanics) atoms.  As described below the ``examples/QUANTUM`` directory
+has examples for coupling to 3 different quantum codes in this manner.
 
 ----------
 
-The examples/mdi directory contains Python scripts and LAMMPS input
+The ``examples/mdi`` directory contains Python scripts and LAMMPS input
 script which use LAMMPS as either an MDI driver or engine, or both.
 Currently, 5 example use cases are provided:
 
@@ -119,45 +126,26 @@ as a plugin library.
 
 -------------
 
-Currently, there are at least two quantum DFT codes which have direct MDI
+As of March 2023, these are quantum codes with MDI support provided via
+Python wrapper scripts included in the LAMMPS distribution.  These can
+be used with the fix mdi/qm and fix mdi/qmmm commands to perform QM
+calculations of an entire system (e.g. AIMD) or QM/MM simulations.  See
+the ``examples/QUANTUM`` sub-directories for more details:
+
+* LATTE - AIMD only
+* PySCF - QM/MM only
+* NWChem - AIMD or QM/MM
+
+There are also at least two quantum codes which have direct MDI
 support, `Quantum ESPRESSO (QE) <https://www.quantum-espresso.org/>`_
-and `INQ <https://qsg.llnl.gov/node/101.html>`_.  There are also several
-QM codes which have indirect support through QCEngine or i-PI.  The
-former means they require a wrapper program (QCEngine) with MDI support
-which writes/read files to pass data to the quantum code itself.  The
-list of QCEngine-supported and i-PI-supported quantum codes is on the
-`MDI webpage
+and `INQ <https://qsg.llnl.gov/node/101.html>`_.  There are also
+several QM codes which have indirect support through QCEngine or i-PI.
+The former means they require a wrapper program (QCEngine) with MDI
+support which writes/read files to pass data to the quantum code
+itself.  The list of QCEngine-supported and i-PI-supported quantum
+codes is on the `MDI webpage
 <https://molssi-mdi.github.io/MDI_Library/html/index.html>`_.
 
-Here is how to build QE as a stand-alone ``pw.x`` file which can be
-used in stand-alone mode:
-
-.. code-block:: bash
-
-   git clone --branch mdi_plugin https://github.com/MolSSI-MDI/q-e.git <base_path>/q-e
-   build the executable pw.x, following the `QE build guide <https://gitlab.com/QEF/q-e/-/wikis/Developers/CMake-build-system>`_
-
-Here is how to build QE as a shared library which can be used in plugin mode,
-which results in a ``libqemdi.so`` file in ``<base_path>/q-e/MDI/src``:
-
-.. code-block:: bash
-
-   git clone --branch mdi_plugin https://github.com/MolSSI-MDI/q-e.git <base_path>/q-e
-   cd <base_path>/q-e
-   ./configure --enable-parallel --enable-openmp --enable-shared FFLAGS="-fPIC" FCFLAGS="-fPIC" CFLAGS="-fPIC" foxflags="-fPIC" try_foxflags="-fPIC"
-   make -j 4 mdi
-
-INQ cannot be built as a stand-alone code; it is by design a library.
-Here is how to build INQ as a shared library which can be used in
-plugin mode, which results in a ``libinqmdi.so`` file in
-``<base_path>/inq/build/examples``:
-
-.. code-block:: bash
-
-   git clone --branch mdi --recurse-submodules https://gitlab.com/taylor-a-barnes/inq.git <base_path>/inq
-   cd <base_path>/inq
-   mkdir -p build
-   cd build
-   ../configure --prefix=<install_path>/install
-   make -j 4
-   make install
+These direct- and indirect-support codes should be usable for full
+system calculations (e.g. AIMD).  Whether they support QM/MM models
+depends on the individual QM code.

doc/src/Howto_spc.rst

@@ -20,7 +20,6 @@ atoms and the water molecule to run a rigid SPC model.
 | LJ :math:`\epsilon`, :math:`\sigma` of OH, HH = 0.0
 | :math:`r_0` of OH bond = 1.0
 | :math:`\theta_0` of HOH angle = 109.47\ :math:`^{\circ}`
-|
 
 Note that as originally proposed, the SPC model was run with a 9
 Angstrom cutoff for both LJ and Coulomb terms.  It can also be used
@@ -33,16 +32,121 @@ the partial charge assignments change:
 
 | O charge = -0.8476
 | H charge = 0.4238
-|
 
 See the :ref:`(Berendsen) <howto-Berendsen>` reference for more details on both
 the SPC and SPC/E models.
 
+Below is the code for a LAMMPS input file and a molecule file
+(``spce.mol``) of SPC/E water for use with the :doc:`molecule command
+<molecule>` demonstrating how to set up a small bulk water system for
+SPC/E with rigid bonds.
+
+.. code-block:: LAMMPS
+
+   units real
+   atom_style full
+   region box block -5 5 -5 5 -5 5
+   create_box 2 box  bond/types 1 angle/types 1 &
+                   extra/bond/per/atom 2 extra/angle/per/atom 1 extra/special/per/atom 2
+
+   mass 1 15.9994
+   mass 2 1.008
+
+   pair_style lj/cut/coul/cut 10.0
+   pair_coeff 1 1 0.1553 3.166
+   pair_coeff 1 2 0.0    1.0
+   pair_coeff 2 2 0.0    1.0
+
+   bond_style zero
+   bond_coeff 1 1.0
+
+   angle_style zero
+   angle_coeff 1 109.47
+
+   molecule water spce.mol
+   create_atoms 0 random 33 34564 NULL mol water 25367 overlap 1.33
+
+   timestep 1.0
+   fix rigid     all shake 0.0001 10 10000 b 1 a 1
+   minimize 0.0 0.0 1000 10000
+   velocity all create 300.0 5463576
+   fix integrate all nvt temp 300.0 300.0 100.0
+
+   thermo_style custom step temp press etotal density pe ke
+   thermo 1000
+   run 20000 upto
+   write_data spce.data nocoeff
+
+.. _spce_molecule:
+.. code-block::
+
+   # Water molecule. SPC/E geometry
+
+   3 atoms
+   2 bonds
+   1 angles
+
+   Coords
+
+   1    0.00000  -0.06461   0.00000
+   2    0.81649   0.51275   0.00000
+   3   -0.81649   0.51275   0.00000
+
+   Types
+
+   1        1   # O
+   2        2   # H
+   3        2   # H
+
+   Charges
+
+   1       -0.8476
+   2        0.4238
+   3        0.4238
+
+   Bonds
+
+   1   1      1      2
+   2   1      1      3
+
+   Angles
+
+   1   1      2      1      3
+
+   Shake Flags
+
+   1 1
+   2 1
+   3 1
+
+   Shake Atoms
+
+   1 1 2 3
+   2 1 2 3
+   3 1 2 3
+
+   Shake Bond Types
+
+   1 1 1 1
+   2 1 1 1
+   3 1 1 1
+
+   Special Bond Counts
+
+   1 2 0 0
+   2 1 1 0
+   3 1 1 0
+
+   Special Bonds
+
+   1 2 3
+   2 1 3
+   3 1 2
+
 Wikipedia also has a nice article on `water models <https://en.wikipedia.org/wiki/Water_model>`_.
 
 ----------
 
 .. _howto-Berendsen:
 
-**(Berendsen)** Berendsen, Grigera, Straatsma, J Phys Chem, 91,
-6269-6271 (1987).
+**(Berendsen)** Berendsen, Grigera, Straatsma, J Phys Chem, 91, 6269-6271 (1987).

doc/src/Howto_tip3p.rst

@@ -1,53 +1,211 @@
 TIP3P water model
 =================
 
-The TIP3P water model as implemented in CHARMM
-:ref:`(MacKerell) <howto-tip3p>` specifies a 3-site rigid water molecule with
-charges and Lennard-Jones parameters assigned to each of the 3 atoms.
-In LAMMPS the :doc:`fix shake <fix_shake>` command can be used to hold
-the two O-H bonds and the H-O-H angle rigid.  A bond style of
-*harmonic* and an angle style of *harmonic* or *charmm* should also be
-used.
+The TIP3P water model as implemented in CHARMM :ref:`(MacKerell)
+<howto-tip3p>` specifies a 3-site rigid water molecule with charges and
+Lennard-Jones parameters assigned to each of the 3 atoms.
 
-These are the additional parameters (in real units) to set for O and H
-atoms and the water molecule to run a rigid TIP3P-CHARMM model with a
-cutoff.  The K values can be used if a flexible TIP3P model (without
-fix shake) is desired.  If the LJ epsilon and sigma for HH and OH are
-set to 0.0, it corresponds to the original 1983 TIP3P model
-:ref:`(Jorgensen) <Jorgensen1>`.
+A suitable pair style with cutoff Coulomb would be:
 
-| O mass = 15.9994
-| H mass = 1.008
-| O charge = -0.834
-| H charge = 0.417
-| LJ :math:`\epsilon` of OO = 0.1521
-| LJ :math:`\sigma` of OO = 3.1507
-| LJ :math:`\epsilon` of HH = 0.0460
-| LJ :math:`\sigma` of HH = 0.4000
-| LJ :math:`\epsilon` of OH = 0.0836
-| LJ :math:`\sigma` of OH = 1.7753
-| K of OH bond = 450
-| :math:`r_0` of OH bond = 0.9572
-| K of HOH angle = 55
-| :math:`\theta` of HOH angle = 104.52\ :math:`^{\circ}`
-|
+* :doc:`pair_style lj/cut/coul/cut <pair_lj_cut_coul>`
 
-These are the parameters to use for TIP3P with a long-range Coulomb
-solver (e.g. Ewald or PPPM in LAMMPS), see :ref:`(Price) <Price1>` for
-details:
+or these commands for a long-range Coulomb model:
+
+* :doc:`pair_style lj/cut/coul/long <pair_lj_cut_coul>`
+* :doc:`pair_style lj/cut/coul/long/soft <pair_fep_soft>`
+* :doc:`kspace_style pppm <kspace_style>`
+* :doc:`kspace_style pppm/disp <kspace_style>`
+
+In LAMMPS the :doc:`fix shake or fix rattle <fix_shake>` command can be
+used to hold the two O-H bonds and the H-O-H angle rigid.  A bond style
+of :doc:`harmonic <bond_harmonic>` and an angle style of :doc:`harmonic
+<angle_harmonic>` or :doc:`charmm <angle_charmm>` should also be used.
+In case of rigid bonds also bond style :doc:`zero <bond_zero>` and angle
+style :doc:`zero <angle_zero>` can be used.
+
+The table below lists the force field parameters (in real :doc:`units
+<units>`) to for the water molecule atoms to run a rigid or flexible
+TIP3P-CHARMM model with a cutoff, the original 1983 TIP3P model
+:ref:`(Jorgensen) <Jorgensen1>`, or a TIP3P model with parameters
+optimized for a long-range Coulomb solver (e.g. Ewald or PPPM in LAMMPS)
+:ref:`(Price) <Price1>`.   The K values can be used if a flexible TIP3P
+model (without fix shake) is desired, for rigid bonds/angles they are
+ignored.
+
+   .. list-table::
+      :header-rows: 1
+      :widths: auto
+
+      * - Parameter
+        - TIP3P-CHARMM
+        - TIP3P (original)
+        - TIP3P (Ewald)
+      * - O mass (amu)
+        - 15.9994
+        - 15.9994
+        - 15.9994
+      * - H mass (amu)
+        - 1.008
+        - 1.008
+        - 1.008
+      * - O charge (:math:`e`)
+        - -0.834
+        - -0.834
+        - -0.834
+      * - H charge (:math:`e`)
+        - 0.417
+        - 0.417
+        - 0.417
+      * - LJ :math:`\epsilon` of OO (kcal/mole)
+        - 0.1521
+        - 0.1521
+        - 0.1020
+      * - LJ :math:`\sigma` of OO (:math:`\AA`)
+        - 3.1507
+        - 3.1507
+        - 3.188
+      * - LJ :math:`\epsilon` of HH (kcal/mole)
+        - 0.0460
+        - 0.0
+        - 0.0
+      * - LJ :math:`\sigma` of HH (:math:`\AA`)
+        - 0.4
+        - 1.0
+        - 1.0
+      * - LJ :math:`\epsilon` of OH (kcal/mole)
+        - 0.0836
+        - 0.0
+        - 0.0
+      * - LJ :math:`\sigma` of OH (:math:`\AA`)
+        - 1.7753
+        - 1.0
+        - 1.0
+      * - K of OH bond (kcal/mole/:math:`\AA^2`)
+        - 450
+        - 450
+        - 450
+      * - :math:`r_0` of OH bond (:math:`\AA`)
+        - 0.9572
+        - 0.9572
+        - 0.9572
+      * - K of HOH angle (kcal/mole)
+        - 55.0
+        - 55.0
+        - 55.0
+      * - :math:`\theta_0` of HOH angle
+        - 104.52\ :math:`^{\circ}`
+        - 104.52\ :math:`^{\circ}`
+        - 104.52\ :math:`^{\circ}`
+
+Below is the code for a LAMMPS input file and a molecule file
+(``tip3p.mol``) of TIP3P water for use with the :doc:`molecule command
+<molecule>` demonstrating how to set up a small bulk water system for
+TIP3P with rigid bonds.
+
+.. code-block:: LAMMPS
+
+    units real
+    atom_style full
+    region box block -5 5 -5 5 -5 5
+    create_box 2 box bond/types 1 angle/types 1 &
+                extra/bond/per/atom 2 extra/angle/per/atom 1 extra/special/per/atom 2
+
+    mass 1 15.9994
+    mass 2 1.008
+
+    pair_style lj/cut/coul/cut 8.0
+    pair_coeff 1 1 0.1521 3.1507
+    pair_coeff 2 2 0.0    1.0
+
+    bond_style zero
+    bond_coeff 1 0.9574
+
+    angle_style zero
+    angle_coeff 1 104.52
+
+    molecule water tip3p.mol
+    create_atoms 0 random 33 34564 NULL mol water 25367 overlap 1.33
+
+    fix rigid all shake 0.001 10 10000 b 1 a 1
+    minimize 0.0 0.0 1000 10000
+
+    reset_timestep 0
+    timestep 1.0
+    velocity all create 300.0 5463576
+    fix integrate all nvt temp 300 300 100.0
+
+    thermo_style custom step temp press etotal pe
+
+    thermo 1000
+    run 20000
+    write_data tip3p.data nocoeff
+
+.. _tip3p_molecule:
+.. code-block::
+
+   # Water molecule. TIP3P geometry
+
+   3 atoms
+   2 bonds
+   1 angles
+
+   Coords
+
+   1    0.00000  -0.06556   0.00000
+   2    0.75695   0.52032   0.00000
+   3   -0.75695   0.52032   0.00000
+
+   Types
+
+   1        1   # O
+   2        2   # H
+   3        2   # H
+
+   Charges
+
+   1       -0.834
+   2        0.417
+   3        0.417
+
+   Bonds
+
+   1   1      1      2
+   2   1      1      3
+
+   Angles
+
+   1   1      2      1      3
+
+   Shake Flags
+
+   1 1
+   2 1
+   3 1
+
+   Shake Atoms
+
+   1 1 2 3
+   2 1 2 3
+   3 1 2 3
+
+   Shake Bond Types
+
+   1 1 1 1
+   2 1 1 1
+   3 1 1 1
+
+   Special Bond Counts
+
+   1 2 0 0
+   2 1 1 0
+   3 1 1 0
+
+   Special Bonds
+
+   1 2 3
+   2 1 3
+   3 1 2
 
-| O mass = 15.9994
-| H mass = 1.008
-| O charge = -0.830
-| H charge = 0.415
-| LJ :math:`\epsilon` of OO = 0.102
-| LJ :math:`\sigma` of OO = 3.188
-| LJ :math:`\epsilon`, :math:`\sigma` of OH, HH = 0.0
-| K of OH bond = 450
-| :math:`r_0` of OH bond = 0.9572
-| K of HOH angle = 55
-| :math:`\theta` of HOH angle = 104.52\ :math:`^{\circ}`
-|
 
 Wikipedia also has a nice article on `water models <https://en.wikipedia.org/wiki/Water_model>`_.
 

doc/src/Howto_tip4p.rst

@@ -2,100 +2,138 @@ TIP4P water model
 =================
 
 The four-point TIP4P rigid water model extends the traditional
-three-point TIP3P model by adding an additional site, usually
-massless, where the charge associated with the oxygen atom is placed.
-This site M is located at a fixed distance away from the oxygen along
-the bisector of the HOH bond angle.  A bond style of *harmonic* and an
-angle style of *harmonic* or *charmm* should also be used.
+:doc:`three-point TIP3P <Howto_tip3p>` model by adding an additional
+site M, usually massless, where the charge associated with the oxygen
+atom is placed.  This site M is located at a fixed distance away from
+the oxygen along the bisector of the HOH bond angle.  A bond style of
+:doc:`harmonic <bond_harmonic>` and an angle style of :doc:`harmonic
+<angle_harmonic>` or :doc:`charmm <angle_charmm>` should also be used.
+In case of rigid bonds also bond style :doc:`zero <bond_zero>` and angle
+style :doc:`zero <angle_zero>` can be used.
 
-A TIP4P model is run with LAMMPS using either these commands
-for a cutoff model:
+There are two ways to implement TIP4P water in LAMMPS:
 
-* :doc:`pair_style tip4p/cut <pair_lj_cut_tip4p>`
-* :doc:`pair_style lj/cut/tip4p/cut <pair_lj_cut_tip4p>`
+#. Use a specially written pair style that uses the :ref:`TIP3P geometry
+   <tip3p_molecule>` without the point M. The point M location is then
+   implicitly derived from the other atoms or each water molecule and
+   used during the force computation.  The forces on M are then
+   projected on the oxygen and the two hydrogen atoms.  This is
+   computationally very efficient, but the charge distribution in space
+   is only correct within the tip4p labeled styles.  So all other
+   computations using charges will "see" the negative charge incorrectly
+   on the oxygen atom.
 
-or these commands for a long-range model:
+   This can be done with the following pair styles for Coulomb with a cutoff:
 
-* :doc:`pair_style tip4p/long <pair_coul>`
-* :doc:`pair_style lj/cut/tip4p/long <pair_lj_cut_tip4p>`
-* :doc:`pair_style lj/long/tip4p/long <pair_lj_long>`
-* :doc:`pair_style tip4p/long/soft <pair_fep_soft>`
-* :doc:`pair_style lj/cut/tip4p/long/soft <pair_fep_soft>`
-* :doc:`kspace_style pppm/tip4p <kspace_style>`
-* :doc:`kspace_style pppm/disp/tip4p <kspace_style>`
+   * :doc:`pair_style tip4p/cut <pair_lj_cut_tip4p>`
+   * :doc:`pair_style lj/cut/tip4p/cut <pair_lj_cut_tip4p>`
 
-The bond lengths and bond angles should be held fixed using the
-:doc:`fix shake <fix_shake>` or :doc:`fix rattle <fix_shake>` command,
-unless a parameterization for a flexible TIP4P model is used.  The
-parameter sets listed below are all for rigid TIP4P model variants and
-thus the bond and angle force constants are not used and can be set to
-any legal value; only equilibrium length and angle are used.
+   or these commands for a long-range Coulomb treatment:
 
-These are the additional parameters (in real units) to set for O and H
-atoms and the water molecule to run a rigid TIP4P model with a cutoff
-:ref:`(Jorgensen) <Jorgensen5>`.  Note that the OM distance is specified in
-the :doc:`pair_style <pair_style>` command, not as part of the pair
-coefficients.
+   * :doc:`pair_style tip4p/long <pair_coul>`
+   * :doc:`pair_style lj/cut/tip4p/long <pair_lj_cut_tip4p>`
+   * :doc:`pair_style lj/long/tip4p/long <pair_lj_long>`
+   * :doc:`pair_style tip4p/long/soft <pair_fep_soft>`
+   * :doc:`pair_style lj/cut/tip4p/long/soft <pair_fep_soft>`
+   * :doc:`kspace_style pppm/tip4p <kspace_style>`
+   * :doc:`kspace_style pppm/disp/tip4p <kspace_style>`
 
-| O mass = 15.9994
-| H mass = 1.008
-| O charge = -1.040
-| H charge = 0.520
-| :math:`r_0` of OH bond = 0.9572
-| :math:`\theta` of HOH angle = 104.52\ :math:`^{\circ}`
-| OM distance = 0.15
-| LJ :math:`\epsilon` of O-O = 0.1550
-| LJ :math:`\sigma` of O-O = 3.1536
-| LJ :math:`\epsilon`, :math:`\sigma` of OH, HH = 0.0
-| Coulomb cutoff = 8.5
-|
+   The bond lengths and bond angles should be held fixed using the
+   :doc:`fix shake <fix_shake>` or :doc:`fix rattle <fix_shake>` command,
+   unless a parameterization for a flexible TIP4P model is used.  The
+   parameter sets listed below are all for rigid TIP4P model variants and
+   thus the bond and angle force constants are not used and can be set to
+   any legal value; only equilibrium length and angle are used.
 
-For the TIP4/Ice model (J Chem Phys, 122, 234511 (2005);
-https://doi.org/10.1063/1.1931662) these values can be used:
+#. Use an :ref:`explicit 4 point TIP4P geometry <tip4p_molecule>` where
+   the oxygen atom carries no charge and the M point no Lennard-Jones
+   interactions.  Since :doc:`fix shake <fix_shake>` or :doc:`fix rattle
+   <fix_shake>` may not be applied to this kind of geometry, :doc:`fix
+   rigid or fix rigid/small <fix_rigid>` or its thermostatted variants
+   are required to maintain a rigid geometry.  This avoids some of the
+   issues with respect to analysis and non-tip4p styles, but it is a
+   more costly force computation (more atoms in the same volume and thus
+   more neighbors in the neighbor lists) and requires a much shorter
+   timestep for stable integration of the rigid body motion.  Since no
+   bonds or angles are required, they do not need to be defined and atom
+   style charge would be sufficient for a bulk TIP4P water system.  In
+   order to avoid that LAMMPS produces an error due to the massless M
+   site a tiny non-zero mass needs to be assigned.
 
-| O mass = 15.9994
-| H mass =  1.008
-| O charge = -1.1794
-| H charge =  0.5897
-| :math:`r_0` of OH bond = 0.9572
-| :math:`\theta` of HOH angle = 104.52\ :math:`^{\circ}`
-| OM distance = 0.1577
-| LJ :math:`\epsilon` of O-O = 0.21084
-| LJ :math:`\sigma` of O-O = 3.1668
-| LJ :math:`\epsilon`, :math:`\sigma` of OH, HH = 0.0
-| Coulomb cutoff = 8.5
-|
+The table below lists the force field parameters (in real :doc:`units
+<units>`) to for a selection of popular variants of the TIP4P model.
+There is the rigid TIP4P model with a cutoff :ref:`(Jorgensen)
+<Jorgensen5>`, the TIP4/Ice model :ref:`(Abascal1) <Abascal1>`, the
+TIP4P/2005 model :ref:`(Abascal2) <Abascal2>` and a version of TIP4P
+parameters adjusted for use with a long-range Coulombic solver
+(e.g. Ewald or PPPM in LAMMPS).  Note that for implicit TIP4P models the
+OM distance is specified in the :doc:`pair_style <pair_style>` command,
+not as part of the pair coefficients.
 
-For the TIP4P/2005 model (J Chem Phys, 123, 234505 (2005);
-https://doi.org/10.1063/1.2121687), these values can be used:
+   .. list-table::
+      :header-rows: 1
+      :widths: auto
 
-| O mass = 15.9994
-| H mass =  1.008
-| O charge = -1.1128
-| H charge = 0.5564
-| :math:`r_0` of OH bond = 0.9572
-| :math:`\theta` of HOH angle = 104.52\ :math:`^{\circ}`
-| OM distance = 0.1546
-| LJ :math:`\epsilon` of O-O = 0.1852
-| LJ :math:`\sigma` of O-O = 3.1589
-| LJ :math:`\epsilon`, :math:`\sigma` of OH, HH = 0.0
-| Coulomb cutoff = 8.5
-|
-
-These are the parameters to use for TIP4P with a long-range Coulombic
-solver (e.g. Ewald or PPPM in LAMMPS):
-
-| O mass = 15.9994
-| H mass = 1.008
-| O charge = -1.0484
-| H charge = 0.5242
-| :math:`r_0` of OH bond = 0.9572
-| :math:`\theta` of HOH angle = 104.52\ :math:`^{\circ}`
-| OM distance = 0.1250
-| LJ :math:`\epsilon` of O-O = 0.16275
-| LJ :math:`\sigma` of O-O = 3.16435
-| LJ :math:`\epsilon`, :math:`\sigma` of OH, HH = 0.0
-|
+      * - Parameter
+        - TIP4P (original)
+        - TIP4P/Ice
+        - TIP4P/2005
+        - TIP4P (Ewald)
+      * - O mass (amu)
+        - 15.9994
+        - 15.9994
+        - 15.9994
+        - 15.9994
+      * - H mass (amu)
+        - 1.008
+        - 1.008
+        - 1.008
+        - 1.008
+      * - O or M charge (:math:`e`)
+        - -1.040
+        - -1.1794
+        - -1.1128
+        - -1.04844
+      * - H charge (:math:`e`)
+        - 0.520
+        - 0.5897
+        - 0.5564
+        - 0.52422
+      * - LJ :math:`\epsilon` of OO (kcal/mole)
+        - 0.1550
+        - 0.21084
+        - 0.1852
+        - 0.16275
+      * - LJ :math:`\sigma` of OO (:math:`\AA`)
+        - 3.1536
+        - 3.1668
+        - 3.1589
+        - 3.16435
+      * - LJ :math:`\epsilon` of HH, MM, OH, OM, HM (kcal/mole)
+        - 0.0
+        - 0.0
+        - 0.0
+        - 0.0
+      * - LJ :math:`\sigma` of HH, MM, OH, OM, HM (:math:`\AA`)
+        - 1.0
+        - 1.0
+        - 1.0
+        - 1.0
+      * - :math:`r_0` of OH bond (:math:`\AA`)
+        - 0.9572
+        - 0.9572
+        - 0.9572
+        - 0.9572
+      * - :math:`\theta_0` of HOH angle
+        - 104.52\ :math:`^{\circ}`
+        - 104.52\ :math:`^{\circ}`
+        - 104.52\ :math:`^{\circ}`
+        - 104.52\ :math:`^{\circ}`
+      * - OM distance (:math:`\AA`)
+        - 0.15
+        - 0.1577
+        - 0.1546
+        - 0.1250
 
 Note that the when using the TIP4P pair style, the neighbor list cutoff
 for Coulomb interactions is effectively extended by a distance 2 \* (OM
@@ -108,6 +146,118 @@ trade-off for your model.  The OM distance and the LJ and Coulombic
 cutoffs are set in the :doc:`pair_style lj/cut/tip4p/long
 <pair_lj_cut_tip4p>` command.
 
+Below is the code for a LAMMPS input file using the implicit method and
+the :ref:`TIP3P molecule file <tip3p_molecule>`.  Because the TIP4P
+charges are different from TIP3P they need to be reset (or the molecule
+file changed):
+
+.. code-block:: LAMMPS
+
+    units real
+    atom_style full
+    region box block -5 5 -5 5 -5 5
+    create_box 2 box bond/types 1 angle/types 1 &
+                extra/bond/per/atom 2 extra/angle/per/atom 1 extra/special/per/atom 2
+
+    mass 1 15.9994
+    mass 2 1.008
+
+    pair_style lj/cut/tip4p/cut 1 2 1 1 0.15 8.0
+    pair_coeff 1 1 0.1550 3.1536
+    pair_coeff 2 2 0.0    1.0
+
+    bond_style zero
+    bond_coeff 1 0.9574
+
+    angle_style zero
+    angle_coeff 1 104.52
+
+    molecule water tip3p.mol  # this uses the TIP3P geometry
+    create_atoms 0 random 33 34564 NULL mol water 25367 overlap 1.33
+    # must change charges for TIP4P
+    set type 1 charge -1.040
+    set type 2 charge  0.520
+
+    fix rigid all shake 0.001 10 10000 b 1 a 1
+    minimize 0.0 0.0 1000 10000
+
+    reset_timestep 0
+    timestep 1.0
+    velocity all create 300.0 5463576
+    fix integrate all nvt temp 300 300 100.0
+
+    thermo_style custom step temp press etotal pe
+
+    thermo 1000
+    run 20000
+    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
+<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:
+
+.. code-block:: LAMMPS
+
+    units real
+    atom_style charge
+    atom_modify map array
+    region box block -5 5 -5 5 -5 5
+    create_box 3 box
+
+    mass 1 15.9994
+    mass 2 1.008
+    mass 3 1.0e-100
+
+    pair_style lj/cut/coul/cut 8.0
+    pair_coeff 1 1 0.1550 3.1536
+    pair_coeff 2 2 0.0    1.0
+    pair_coeff 3 3 0.0    1.0
+
+    fix mol all property/atom mol
+    molecule water tip4p.mol
+    create_atoms 0 random 33 34564 NULL mol water 25367 overlap 1.33
+
+    timestep 0.5
+    fix integrate all rigid/nvt/small molecule temp 300.0 300.0 100.0
+    velocity all create 300.0 5463576
+
+    thermo_style custom step temp press etotal density pe ke
+    thermo 1000
+    run 20000
+    write_data tip4p-explicit.data nocoeff
+
+.. _tip4p_molecule:
+.. code-block::
+
+   # Water molecule. Explicit TIP4P geometry for use with fix rigid
+
+   4 atoms
+
+   Coords
+
+   1    0.00000  -0.06556   0.00000
+   2    0.75695   0.52032   0.00000
+   3   -0.75695   0.52032   0.00000
+   4    0.00000   0.08444   0.00000
+
+   Types
+
+   1        1   # O
+   2        2   # H
+   3        2   # H
+   4        3   # M
+
+   Charges
+
+   1        0.000
+   2        0.520
+   3        0.520
+   4       -1.040
+
+
 Wikipedia also has a nice article on `water models <https://en.wikipedia.org/wiki/Water_model>`_.
 
 ----------
@@ -116,3 +266,13 @@ Wikipedia also has a nice article on `water models <https://en.wikipedia.org/wik
 
 **(Jorgensen)** Jorgensen, Chandrasekhar, Madura, Impey, Klein, J Chem
 Phys, 79, 926 (1983).
+
+.. _Abascal1:
+
+**(Abascal1)** Abascal, Sanz, Fernandez, Vega, J Chem Phys, 122, 234511 (2005)
+   https://doi.org/10.1063/1.1931662
+
+.. _Abascal2:
+
+**(Abascal2)** Abascal, J Chem Phys, 123, 234505 (2005)
+   https://doi.org/10.1063/1.2121687

doc/src/Howto_tip5p.rst

@@ -0,0 +1,162 @@
+TIP5P water model
+=================
+
+The five-point TIP5P rigid water model extends the :doc:`three-point
+TIP3P model <Howto_tip3p>` by adding two additional sites L, usually
+massless, where the charge associated with the oxygen atom is placed.
+These sites L are located at a fixed distance away from the oxygen atom,
+forming a tetrahedral angle that is rotated by 90 degrees from the HOH
+plane.  Those sites thus somewhat approximate lone pairs of the oxygen
+and consequently improve the water structure to become even more
+"tetrahedral" in comparison to the :doc:`four-point TIP4P model
+<Howto_tip4p>`.
+
+A suitable pair style with cutoff Coulomb would be:
+
+* :doc:`pair_style lj/cut/coul/cut <pair_lj_cut_coul>`
+
+or these commands for a long-range model:
+
+* :doc:`pair_style lj/cut/coul/long <pair_lj_cut_coul>`
+* :doc:`pair_style lj/cut/coul/long/soft <pair_fep_soft>`
+* :doc:`kspace_style pppm <kspace_style>`
+* :doc:`kspace_style pppm/disp <kspace_style>`
+
+A TIP5P model *must* be run using a :doc:`rigid fix <fix_rigid>` since
+there is no other option to keep this kind of structure rigid in LAMMPS.
+In order to avoid that LAMMPS produces an error due to the massless L
+sites, those need to be assigned a tiny non-zero mass.
+
+The table below lists the force field parameters (in real :doc:`units
+<units>`) to for a the TIP5P model with a cutoff :ref:`(Mahoney)
+<Mahoney>` and the TIP5P-E model :ref:`(Rick) <Rick>` for use with a
+long-range Coulombic solver (e.g. Ewald or PPPM in LAMMPS).
+
+   .. list-table::
+      :header-rows: 1
+      :widths: auto
+
+      * - Parameter
+        - TIP5P
+        - TIP5P-E
+      * - O mass (amu)
+        - 15.9994
+        - 15.9994
+      * - H mass (amu)
+        - 1.008
+        - 1.008
+      * - O charge (:math:`e`)
+        - 0.0
+        - 0.0
+      * - L charge (:math:`e`)
+        - -0.241
+        - -0.241
+      * - H charge (:math:`e`)
+        - 0.241
+        - 0.241
+      * - LJ :math:`\epsilon` of OO (kcal/mole)
+        - 0.1600
+        - 0.1780
+      * - LJ :math:`\sigma` of OO (:math:`\AA`)
+        - 3.1200
+        - 3.0970
+      * - LJ :math:`\epsilon` of HH, LL, OH, OL, HL (kcal/mole)
+        - 0.0
+        - 0.0
+      * - LJ :math:`\sigma` of HH, LL, OH, OL, HL (:math:`\AA`)
+        - 1.0
+        - 1.0
+      * - :math:`r_0` of OH bond (:math:`\AA`)
+        - 0.9572
+        - 0.9572
+      * - :math:`\theta_0` of HOH angle
+        - 104.52\ :math:`^{\circ}`
+        - 104.52\ :math:`^{\circ}`
+      * - OL distance (:math:`\AA`)
+        - 0.70
+        - 0.70
+      * - :math:`\theta_0` of LOL angle
+        - 109.47\ :math:`^{\circ}`
+        - 109.47\ :math:`^{\circ}`
+
+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
+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:
+
+.. code-block:: LAMMPS
+
+    units real
+    atom_style charge
+    atom_modify map array
+    region box block -5 5 -5 5 -5 5
+    create_box 3 box
+
+    mass 1 15.9994
+    mass 2 1.008
+    mass 3 1.0e-100
+
+    pair_style lj/cut/coul/cut 8.0
+    pair_coeff 1 1 0.160  3.12
+    pair_coeff 2 2 0.0    1.0
+    pair_coeff 3 3 0.0    1.0
+
+    fix mol all property/atom mol
+    molecule water tip5p.mol
+    create_atoms 0 random 33 34564 NULL mol water 25367 overlap 1.33
+
+    timestep 0.5
+    fix integrate all rigid/nvt/small molecule temp 300.0 300.0 100.0
+    reset_timestep 0
+    velocity all create 300.0 5463576
+
+    thermo_style custom step temp press etotal density pe ke
+    thermo 1000
+    run 20000
+    write_data tip5p.data nocoeff
+
+.. _tip5p_molecule:
+.. code-block::
+
+   # Water molecule. Explicit TIP5P geometry for use with fix rigid
+
+   5 atoms
+
+   Coords
+
+   1    0.00000  -0.06556   0.00000
+   2    0.75695   0.52032   0.00000
+   3   -0.75695   0.52032   0.00000
+   4    0.00000  -0.46971   0.57154
+   5    0.00000  -0.46971  -0.57154
+
+   Types
+
+   1        1   # O
+   2        2   # H
+   3        2   # H
+   4        3   # L
+   5        3   # L
+
+   Charges
+
+   1        0.000
+   2        0.241
+   3        0.241
+   4       -0.241
+   5       -0.241
+
+Wikipedia also has a nice article on `water models <https://en.wikipedia.org/wiki/Water_model>`_.
+
+----------
+
+.. _Mahoney:
+
+**(Mahoney)** Mahoney, Jorgensen, J Chem Phys 112, 8910 (2000)
+
+.. _Rick:
+
+**(Rick)** Rick, J Chem Phys 120, 6085 (2004)

doc/src/Howto_wsl.rst

@@ -11,12 +11,14 @@ LAMMPS in workshop settings, we had to redirect Windows users to
 Linux Virtual Machines such as VirtualBox or Unix-like compilation with
 Cygwin.
 
-With the latest updates in Windows 10 (Version 2004, Build 19041 or higher),
-Microsoft has added a new way to work on Linux-based code. The Windows
-Subsystem for Linux (WSL). With WSL Version 2, you now get a Linux Virtual
-Machine that transparently integrates into Windows. All you need is to ensure
-you have the latest Windows updates installed and enable this new feature.
-Linux VMs are then easily installed using the Microsoft Store.
+With the latest updates in Windows 10 (Version 2004, Build 19041 or
+higher), Microsoft has added a new way to work on Linux-based code. The
+`Windows Subsystem for Linux (WSL)
+<https://learn.microsoft.com/en-us/windows/wsl/>`_.  With WSL Version 2,
+you now get a Linux Virtual Machine that transparently integrates into
+Windows.  All you need is to ensure you have the latest Windows updates
+installed and enable this new feature.  Linux VMs are then easily
+installed using the Microsoft Store.
 
 In this tutorial, I'll show you how to set up and compile LAMMPS for both serial
 and MPI usage in WSL2.

doc/src/Install_conda.rst

@@ -1,13 +1,13 @@
-Download an executable for Linux or Mac via Conda
--------------------------------------------------
+Download an executable for Linux or macOS via Conda
+---------------------------------------------------
 
 Pre-compiled LAMMPS binaries are available for macOS and Linux via the
 `Conda <conda_>`_ package management system.
 
-First, one must set up the Conda package manager on your system.  Follow the
-instructions to install `Miniconda <mini_conda_install_>`_, then create a conda
-environment (named `my-lammps-env` or whatever you prefer) for your LAMMPS
-install:
+First, one must set up the Conda package manager on your system.  Follow
+the instructions to install `Miniconda <mini_conda_install_>`_, then
+create a conda environment (named `my-lammps-env` or whatever you
+prefer) for your LAMMPS install:
 
 .. code-block:: bash
 

doc/src/Install_git.rst

@@ -26,15 +26,18 @@ provides `limited support for subversion clients <svn_>`_.
 .. _git: https://git-scm.com
 .. _svn: https://help.github.com/en/github/importing-your-projects-to-github/working-with-subversion-on-github
 
-You can follow the LAMMPS development on 3 different git branches:
+You can follow the LAMMPS development on 4 different git branches:
 
-* **stable**   :  this branch is updated from the *release* branch with
-  every stable release version and also has selected bug fixes and updates
-  back-ported from the *develop* branch
 * **release**  :  this branch is updated with every patch 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.
 
 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:
@@ -60,17 +63,17 @@ between them at any time using "git checkout <branch name>".)
    *--depth* git command line flag.  That will create a "shallow clone"
    of the repository, which contains only a subset of the git history.
    Using a depth of 1000 is usually sufficient to include the head
-   commits of the *develop* and the *release* branches.  To include the
-   head commit of the *stable* branch you may need a depth of up
-   to 10000.  If you later need more of the git history, you can always
-   convert the shallow clone into a "full clone".
+   commits of the *develop*, the *release*, and the *maintenance*
+   branches.  To include the head commit of the *stable* branch you may
+   need a depth of up to 10000.  If you later need more of the git
+   history, you can always convert the shallow clone into a "full
+   clone".
 
 Once the command completes, your directory will contain the same files
 as if you unpacked a current LAMMPS tarball, with the exception, that
-the HTML documentation files are not included.  They can be fetched
-from the LAMMPS website by typing ``make fetch`` in the doc directory.
-Or they can be generated from the content provided in ``doc/src`` by
-typing ``make html`` from the ``doc`` directory.
+the HTML documentation files are not included. They can be generated
+from the content provided in ``doc/src`` by typing ``make html`` from
+the ``doc`` directory.
 
 After initial cloning, as bug fixes and new features are added to
 LAMMPS you can stay up-to-date by typing the following git commands
@@ -79,8 +82,9 @@ from within the "mylammps" directory:
 .. code-block:: bash
 
    git checkout release      # not needed if you always stay in this branch
-   git checkout stable       # use one of these 3 checkout commands
+   git checkout stable       # use one of these 4 checkout commands
    git checkout develop      # to choose the branch to follow
+   git checkout maintenance
    git pull
 
 Doing a "pull" will not change any files you have added to the LAMMPS
@@ -145,7 +149,7 @@ changed.  How to do this depends on the build system you are using.
       to enforce consistency of the source between the src folder
       and package directories.  This is OK to do even if you don't
       use any packages. The ``make purge`` command removes any deprecated
-      src files if they were removed by the patch from a package
+      src files if they were removed by the update from a package
       subdirectory.
 
       .. warning::
@@ -159,10 +163,10 @@ changed.  How to do this depends on the build system you are using.
 .. admonition:: Git protocols
    :class: note
 
-   The servers at github.com support the "https://" access protocol for
+   The servers at github.com support the "https" access protocol for
    anonymous, read-only access.  If you have a suitably configured
    GitHub account, you may also use SSH protocol with the URL
-   "git@github.com:lammps/lammps.git".
+   ``git@github.com:lammps/lammps.git``.
 
 The LAMMPS GitHub project is currently overseen by Axel Kohlmeyer
 (Temple U, akohlmey at gmail.com).

doc/src/Install_linux.rst

@@ -3,6 +3,7 @@ Download an executable for Linux
 
 Binaries are available for different versions of Linux:
 
+- :ref:`Pre-built static Linux x86_64 executables <static>`
 - :ref:`Pre-built Ubuntu and Debian Linux executables <ubuntu>`
 - :ref:`Pre-built Fedora Linux executables <fedora>`
 - :ref:`Pre-built EPEL Linux executables (RHEL, CentOS) <epel>`
@@ -21,6 +22,33 @@ Binaries are available for different versions of Linux:
 
 ----------
 
+.. _static:
+
+Pre-built static Linux x86_64 executables
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Pre-built LAMMPS executables for Linux, that are statically linked and
+compiled for 64-bit x86 CPUs (x86_64 or AMD64) are available for download
+at `https://download.lammps.org/static/ <https://download.lammps.org/static/>`_.
+Because of that static linkage (and unlike the Linux distribution specific
+packages listed below), they do not depend on any installed software and
+thus should run on *any* 64-bit x86 machine with *any* Linux version.
+
+These executable include most of the available packages and multi-thread
+parallelization (via INTEL, KOKKOS, or OPENMP package).  They are **not**
+compatible with MPI.  Several of the LAMMPS tools executables (e.g. ``msi2lmp``)
+and the ``lammps-shell`` program are included as well.  Because of the
+static linkage, there is no ``liblammps.so`` library file and thus also the
+LAMMPS python module, which depends on it, is not included.
+
+The compressed tar archives available for download have names following
+the pattern ``lammps-linux-x86_64-<version>.tar.gz`` and will all unpack
+into a ``lammps-static`` folder.  The executables are then in the
+``lammps-static/bin/`` folder.  Since they do not depend on any other
+software, they may be freely moved or copied around.
+
+----------
+
 .. _ubuntu:
 
 Pre-built Ubuntu and Debian Linux executables
@@ -144,7 +172,7 @@ Pre-built EPEL Linux executable
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Pre-built LAMMPS (and KIM) packages for stable releases are available
-in the `Extra Packages for Enterprise Linux (EPEL) repository <https://fedoraproject.org/wiki/EPEL>`_
+in the `Extra Packages for Enterprise Linux (EPEL) repository <https://docs.fedoraproject.org/en-US/epel/>`_
 for use with Red Hat Enterprise Linux (RHEL) or CentOS version 7.x
 and compatible Linux distributions. Names of packages, executable,
 and content are the same as described above for Fedora Linux.
@@ -232,7 +260,7 @@ There are three scripts available, named `lammps
 <https://aur.archlinux.org/packages/lammps>`_, `lammps-beta
 <https://aur.archlinux.org/packages/lammps>`_ and `lammps-git
 <https://aur.archlinux.org/packages/lammps>`_.  They respectively
-package the stable, patch and git releases.
+package the stable, feature, and git releases.
 
 To install, you will need to have the git package installed. You may use
 any of the above names in-place of lammps.

doc/src/Install_mac.rst

@@ -1,12 +1,12 @@
-Download an executable for Mac
-------------------------------
+Download an executable for macOS
+--------------------------------
 
-LAMMPS can be downloaded, built, and configured for OS X on a Mac 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,
-LATTE, MSCG, MPIIO, POEMS, VORONOI.
+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,
+VORONOI.
 
 After installing Homebrew, you can install LAMMPS on your system with
 the following commands:
@@ -15,8 +15,9 @@ the following commands:
 
    brew install lammps
 
-This will install the executables "lammps_serial" and "lammps_mpi", as well as
-the LAMMPS "doc", "potentials", "tools", "bench", and "examples" directories.
+This will install the executables "lammps_serial" and "lammps_mpi", as
+well as the LAMMPS "doc", "potentials", "tools", "bench", and "examples"
+directories.
 
 Once LAMMPS is installed, you can test the installation with the
 Lennard-Jones benchmark file:

doc/src/Install_tarball.rst

@@ -2,7 +2,7 @@ Download source and documentation as a tarball
 ----------------------------------------------
 
 You can download a current LAMMPS tarball from the `download page <download_>`_
-of the `LAMMPS website <lws_>`_.
+of the `LAMMPS website <lws_>`_ or from GitHub (see below).
 
 .. _download: https://www.lammps.org/download.html
 .. _bug: https://www.lammps.org/bug.html
@@ -10,28 +10,28 @@ of the `LAMMPS website <lws_>`_.
 .. _lws: https://www.lammps.org
 
 You have two choices of tarballs, either the most recent stable release
-or the most current patch or feature release.  Stable releases occur a
-few times per year, and undergo more testing before release.  Feature
-releases occur every 4 to 8 weeks.  The new contents in all feature
-releases are listed on the `bug and feature page <bug_>`_ of the LAMMPS
-homepage.
-
-Both tarballs include LAMMPS documentation (HTML and PDF files)
-corresponding to that version.  The download page also has an option
-to download the current-version LAMMPS documentation by itself.
+or the most recent feature release.  Stable releases occur a few times
+per year, and undergo more testing before release.  Also, between stable
+releases bug fixes from the feature releases are back-ported and the
+tarball occasionally updated.  Feature releases occur every 4 to 8
+weeks.  The new contents in all feature releases are listed on the `bug
+and feature page <bug_>`_ of the LAMMPS homepage.
 
 Tarballs of older LAMMPS versions can also be downloaded from `this page
 <older_>`_.
 
-Once you have a tarball, unzip and untar it with the following
+Tarballs downloaded from the LAMMPS homepage include the pre-translated
+LAMMPS documentation (HTML and PDF files) corresponding to that version.
+
+Once you have a tarball, uncompress and untar it with the following
 command:
 
 .. code-block:: bash
 
    tar -xzvf lammps*.tar.gz
 
-This will create a LAMMPS directory with the version date
-in its name, e.g. lammps-23Jun18.
+This will create a LAMMPS directory with the version date in its name,
+e.g. lammps-28Mar23.
 
 ----------
 
@@ -44,7 +44,9 @@ with the following command, to create a lammps-<version> directory:
 
    unzip lammps*.zip
 
-This version corresponds to the selected LAMMPS patch or stable release.
+This version corresponds to the selected LAMMPS feature or stable
+release (as indicated by the matching git tag) and will only contain the
+source code and no pre-built documentation.
 
 .. _git: https://github.com/lammps/lammps/releases
 

doc/src/Install_windows.rst

@@ -17,11 +17,12 @@ install the Windows MPI package (MPICH2 from Argonne National Labs),
 needed to run in parallel with MPI.
 
 The LAMMPS binaries contain *all* :doc:`optional packages <Packages>`
-included in the source distribution except: KIM, KOKKOS, MSCG, PYTHON,
-ADIOS, H5MD, NETCDF, QMMM, ML-QUIP, and VTK.
-The serial version also does not include the MPIIO and
-LATBOLTZ packages.  The GPU package is compiled for OpenCL with
-mixed precision kernels.
+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.
 
 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

@@ -46,7 +46,7 @@ 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>`_
+- 29 September 2021 version: `DOI:10.5281/zenodo.6386596 <https://dx.doi.org/10.5281/zenodo.6386596>`_
 
 Home page
 ^^^^^^^^^

doc/src/Intro_features.rst

@@ -88,7 +88,7 @@ commands)
 * charge equilibration (QEq via dynamic, point, shielded, Slater methods)
 * coarse-grained potentials: DPD, GayBerne, REsquared, colloidal, DLVO, oxDNA / oxRNA, SPICA
 * mesoscopic potentials: granular, Peridynamics, SPH, mesoscopic tubular potential (MESONT)
-* semi-empirical potentials: multi-ion generalized pseudopotential theory (MGPT), second moment tight binding + QEq (SMTB-Q), density functional tight-binding (LATTE)
+* semi-empirical potentials: multi-ion generalized pseudopotential theory (MGPT), second moment tight binding + QEq (SMTB-Q)
 * electron force field (eFF, AWPMD)
 * bond potentials: harmonic, FENE, Morse, nonlinear, Class II (COMPASS), quartic (breakable), tabulated, scripted
 * angle potentials: harmonic, CHARMM, cosine, cosine/squared, cosine/periodic, Class II (COMPASS), tabulated, scripted
@@ -195,7 +195,7 @@ Multi-replica models
 * :doc:`parallel replica dynamics <prd>`
 * :doc:`temperature accelerated dynamics <tad>`
 * :doc:`parallel tempering <temper>`
-* path-integral MD: `first variant <fix_pimd>`, `second variant <fix_ipi>`
+* path-integral MD: :doc:`first variant <fix_pimd>`, :doc:`second variant <fix_ipi>`
 * multi-walker collective variables with :doc:`Colvars <fix_colvars>` and :doc:`Plumed <fix_plumed>`
 
 .. _prepost:

doc/src/Intro_nonfeatures.rst

@@ -34,7 +34,7 @@ Here are suggestions on how to perform these tasks:
   a true molecular builder that will generate complex molecular models.
   See the :doc:`Tools <Tools>` page for details on tools packaged with
   LAMMPS.  The `Pre-/post-processing page
-  <https:/www.lammps.org/prepost.html>`_ of the LAMMPS homepage
+  <https://www.lammps.org/prepost.html>`_ of the LAMMPS homepage
   describes a variety of third party tools for this task.  Furthermore,
   some internal LAMMPS commands allow reconstructing, or selectively adding
   topology information, as well as provide the option to insert molecule
@@ -66,10 +66,9 @@ Here are suggestions on how to perform these tasks:
   these various options.
 * **Visualization:** LAMMPS can produce NETPBM, JPG, or PNG format
   snapshot images on-the-fly via its :doc:`dump image <dump_image>`
-  command and pass them to an external program, `FFmpeg
-  <https://www.ffmpeg.org>`_, to generate movies from them.  For
-  high-quality, interactive visualization, there are many excellent and
-  free tools available.  See the `Visualization Tools
+  command and pass them to an external program, `FFmpeg  <https://ffmpeg.org/>`_,
+  to generate movies from them.  For high-quality, interactive visualization,
+  there are many excellent and free tools available.  See the `Visualization Tools
   <https://www.lammps.org/viz.html>`_ page of the LAMMPS website for
   visualization packages that can process LAMMPS output data.
 * **Plotting:** See the next bullet about Pizza.py as well as the

doc/src/Library_properties.rst

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

doc/src/Manual.rst

@@ -136,10 +136,21 @@ Indices and tables
    :class: note
 
    The HTML version of the manual makes use of advanced features present
-   in "modern" web browsers.  This can lead to incompatibilities with older
-   web browsers (released more than 4 years ago) and specific vendor browsers
-   (e.g. Internet Explorer on Windows; Microsoft Edge works well though)
+   in "modern" web browsers.  This leads to incompatibilities with older
+   web browsers and specific vendor browsers (e.g. Internet Explorer on Windows)
    where parts of the pages are not rendered as expected (e.g. the layout is
    broken or mathematical expressions not typeset).  In that case we
    recommend to install/use a different/newer web browser or use
    the `PDF version of the manual <https://docs.lammps.org/Manual.pdf>`_.
+
+   The following web browser versions have been verified to work as
+   expected on Linux, macOS, and Windows where available:
+
+   - Safari version 11.1 and later
+   - Firefox version 54 and later
+   - Chrome version 54 and later
+   - Opera version 41 and later
+   - Edge version 80 and later
+
+   Also Android version 7.1 and later and iOS version 11 and later have
+   been verified to render this website as expected.

doc/src/Manual_version.rst

@@ -12,13 +12,12 @@ into pull requests.  Pull requests will be merged into the *develop*
 branch of the git repository after they pass automated testing and code
 review by the LAMMPS developers.  When a sufficient number of changes
 have accumulated *and* the *develop* branch version passes an extended
-set of automated tests, we release it as a *feature release* (or patch
-release), which are currently made every 4 to 8 weeks.  The *release*
-branch of the git repository is updated with every such release.  A
-summary of the most important changes of the patch releases are on `this
-website page <https://www.lammps.org/bug.html>`_.  More detailed release
-notes are `available on GitHub
-<https://github.com/lammps/lammps/releases/>`_.
+set of automated tests, we release it as a *feature release*, which are
+currently made every 4 to 8 weeks.  The *release* branch of the git
+repository is updated with every such release.  A summary of the most
+important changes of the patch releases are on `this website page
+<https://www.lammps.org/bug.html>`_.  More detailed release notes are
+`available on GitHub <https://github.com/lammps/lammps/releases/>`_.
 
 Once or twice a year, we have a "stabilization period" where we apply
 only bug fixes and small, non-intrusive changes to the *develop*
@@ -28,13 +27,14 @@ several variants of static code analysis are run to improve the overall
 code quality, consistency, and compliance with programming standards,
 best practices and style conventions.
 
-The latest patch release after such a period is then also labeled as a
-*stable* version and the *stable* branch is updated with it.  Between
-stable releases, we occasionally release updates to the stable release
-containing only bug fixes and updates back-ported from the *develop*
-branch and update the *stable* branch accordingly.
+The release after such a stabilization period is called a *stable*
+version and both, the *release* and the *stable* branches are updated
+with it.  Between stable releases, we collect back-ported bug fixes and
+updates from the *develop* branch in the *maintenance* branch.  From the
+*maintenance* branch we make occasional update releases and update the
+*stable* branch accordingly.
 
-Each version of LAMMPS contains all the documented features up to and
+Each version of LAMMPS contains all the documented *features* up to and
 including its version date.  For recently added features, we add markers
 to the documentation at which specific LAMMPS version a feature or
 keyword was added or significantly changed.
@@ -45,7 +45,7 @@ directory name created when you unpack a tarball.  And it is on the
 first page of the :doc:`manual <Manual>`.
 
 * If you browse the HTML pages of the online version of the LAMMPS
-  manual, they will by default describe the most current patch release
+  manual, they will by default describe the most current feature release
   version of LAMMPS.  In the navigation bar on the bottom left, there is
   the option to view instead the documentation for the most recent
   *stable* version or the documentation corresponding to the state of

doc/src/Modify.rst

@@ -1,23 +1,30 @@
 Modifying & extending LAMMPS
 ****************************
 
-LAMMPS is designed in a modular fashion and to be easy to modify or
-extend with new functionality.  In fact, about 95% of its source code
-are optional.  The following pages give basic instructions on what
-is required when adding new styles of different kinds to LAMMPS.
+LAMMPS has a modular design, so that it is easy to modify or extend with
+new functionality.  In fact, about 95% of its source code is optional.
+The following pages give basic instructions on adding new features to
+LAMMPS.  More in-depth explanations and documentation of individual
+functions and classes are given in :doc:`Developer`.
 
 If you add a new feature to LAMMPS and think it will be of general
 interest to other users, we encourage you to submit it for inclusion in
-LAMMPS as a pull request on our `GitHub site
-<https://github.com/lammps/lammps>`_, after reading about :doc:`how to
-prepare your code for submission <Modify_contribute>` and :doc:`the
-style requirements and recommendations <Modify_style>`.
+LAMMPS. This process is explained in the following three pages:
+
+* :doc:`how to prepare and submit your code <Modify_contribute>`
+* :doc:`requirements for submissions <Modify_requirements>`
+* :doc:`style guidelines <Modify_style>`
+
+A summary description of various types of styles in LAMMPS follows.
+A discussion of implementing specific styles from scratch is given
+in :doc:`writing new styles <Developer_write>`.
 
 .. toctree::
    :maxdepth: 1
 
    Modify_overview
    Modify_contribute
+   Modify_requirements
    Modify_style
 
 .. toctree::
@@ -34,5 +41,6 @@ style requirements and recommendations <Modify_style>`.
    Modify_min
    Modify_region
    Modify_body
+   Modify_gran_sub_mod
    Modify_thermo
    Modify_variable

doc/src/Modify_contribute.rst

@@ -2,74 +2,59 @@ Submitting new features for inclusion in LAMMPS
 ===============================================
 
 We encourage LAMMPS users to submit new features they wrote for LAMMPS
-to be included into the LAMMPS distribution and thus become easily
-accessible to all LAMMPS users.  The LAMMPS source code is managed with
-git and public development is hosted on `GitHub
-<https://github.com/lammps/lammps>`_.  You can monitor the repository to
-be notified of releases, follow the ongoing development, and comment on
-topics of interest to you.
+to be included in the LAMMPS distribution and thus become easily
+accessible to all LAMMPS users.  The LAMMPS source code is managed
+with git and public development is hosted on `GitHub
+<https://github.com/lammps/lammps>`_.  You can monitor the repository
+to be notified of releases, follow the ongoing development, and
+comment on topics of interest to you.
+
+This section contains general information regarding the preparation
+and submission of new features to LAMMPS. If you are new to
+development in LAMMPS, we recommend you read one of the tutorials on
+developing a new :doc:`pair style <Developer_write_pair>` or :doc:`fix
+style <Developer_write_fix>` which provide a friendly introduction to
+what LAMMPS development entails and common vocabulary used on this
+section.
+
 
 Communication with the LAMMPS developers
 ----------------------------------------
 
-For any larger modifications or programming project, you are encouraged
-to contact the LAMMPS developers ahead of time in order to discuss
-implementation strategies and coding guidelines.  That will make it
-easier to integrate your contribution and results in less work for
-everybody involved.  You are also encouraged to search through the list
-of `open issues on GitHub <https://github.com/lammps/lammps/issues>`_
-and submit a new issue for a planned feature, so you would not duplicate
-the work of others (and possibly get scooped by them) or have your work
-duplicated by others.
+For any larger modifications or programming project, you are
+encouraged to contact the LAMMPS developers ahead of time to discuss
+implementation strategies. That will make it easier to integrate your
+contribution and typically results in less work for everyone involved.
+You are also encouraged to search through the list of `open issues on
+GitHub <https://github.com/lammps/lammps/issues>`_ and submit a new
+issue for a planned feature, to avoid duplicating work (and possibly
+being scooped).
 
-For informal communication with the LAMMPS developers you may ask to
-join the `LAMMPS developers on Slack <https://lammps.slack.com>`_.  This
-slack work space is by invitation only.  Thus for access, please send an
-e-mail to ``slack@lammps.org`` explaining what part of LAMMPS you are
-working on.  Only discussions related to LAMMPS development are
-tolerated in that work space, so this is **NOT** for people that look
+For informal communication with the LAMMPS developers, you may ask to
+join the `LAMMPS developers on Slack <https://lammps.slack.com>`_.
+This slack work space is by invitation only.  For access, please send
+an e-mail to ``slack@lammps.org`` explaining what part of LAMMPS you
+are working on.  Only discussions related to LAMMPS development are
+tolerated in that work space, so this is **NOT** for people looking
 for help with compiling, installing, or using LAMMPS.  Please post a
 message to the `LAMMPS forum <https://www.lammps.org/forum.html>`_ for
 those purposes.
 
-Packages versus individual files
---------------------------------
-
-The remainder of this chapter describes how to add new "style" files of
-various kinds to LAMMPS.  Packages are simply collections of one or more
-such new class files which are invoked as a new style within a LAMMPS
-input script.  In some cases also collections of supporting functions or
-classes are included as separate files in a package, especially when
-they can be shared between multiple styles. If designed correctly, these
-additions typically do not require any changes to the core code of
-LAMMPS; they are simply add-on files that are compiled with the rest of
-LAMMPS.  To make those styles work, you may need some trivial changes to
-the core code; an example of a trivial change is making a parent-class
-method "virtual" when you derive a new child class from it.
-
-If you think your new feature or package requires some non-trivial
-changes in core LAMMPS files, you should communicate with the LAMMPS
-developers `on Slack <https://lammps.org/slack.html>`_, `on GitHub
-<https://github.com/lammps/lammps/issues>`_, or `via email
-<https://www.lammps.org/authors.html>`_, since we may have
-recommendations about what changes to do where, or may not want to
-include certain changes for some reason and thus you would need to look
-for alternatives.
 
 Time and effort required
 ------------------------
 
-How quickly your contribution will be integrated can vary a lot.  It
-depends largely on how much effort it will cause the LAMMPS developers
-to integrate and test it, how many and what kind of changes to the core
-code are required, how quickly you can address them and of how much
-interest it is to the larger LAMMPS community.  Please see the section
-on :doc:`LAMMPS programming style and requirements <Modify_style>` for
-instructions, recommendations, and formal requirements.  A small,
-modular, well written contribution may be integrated within hours, but a
-complex change that will require a redesign of some core functionality
-in LAMMPS for a clean integration can take many months until it is
-considered ready for inclusion (though this is rare).
+How quickly your contribution will be integrated can vary widely.  It
+depends largely on how much effort is required by the LAMMPS
+developers to integrate and test it, if any and what kind of changes
+to the core code are required, how quickly you can address them, and
+how much interest the contribution is to the larger LAMMPS
+community. This process can be streamlined by following the
+:doc:`requirements <Modify_requirements>` and :doc:`style
+guidelines<Modify_style>`.  A small, modular, well written
+contribution may be integrated within hours, but a complex change that
+requires a re-design of a core functionality in LAMMPS can take months
+before inclusion (though this is rare).
 
 
 Submission procedure
@@ -78,36 +63,24 @@ Submission procedure
 All changes to LAMMPS (including those from LAMMPS developers) are
 integrated via pull requests on GitHub and cannot be merged without
 passing the automated testing and an approving review by a LAMMPS core
-developer.  Thus before submitting your contribution, you should first
-make certain, that your added or modified code compiles and works
-correctly with the latest patch-level or development version of LAMMPS
-and contains all bug fixes from it.
+developer.  Before submitting your contribution, you should therefore
+first ensure that your added or modified code compiles and works
+correctly with the latest development version of LAMMPS and contains
+all bug fixes from it.
 
-Once you have prepared everything, see the :doc:`LAMMPS GitHub Tutorial
-<Howto_github>` page for instructions on how to submit your changes or
-new files through a GitHub pull request yourself.  If you are unable or
-unwilling to submit via GitHub yourself, you may also submit patch files
-or full files to the LAMMPS developers and ask them to submit a pull
-request on GitHub on your behalf.  Then create a gzipped tar file of
-all  changed or added files or a corresponding patch file using
-'diff -u' or 'diff -c' format and compress it with gzip.  Please only
-use gzip compression, as this works well and is available on all platforms.
+Once you have prepared everything, see the :doc:`LAMMPS GitHub
+Tutorial <Howto_github>` page for instructions on how to submit your
+changes or new files through a GitHub pull request.  If you are unable
+or unwilling to submit via GitHub yourself, you may also send patch
+files or full files to the `LAMMPS developers
+<https://www.lammps.org/authors.html>`_ and ask them to submit a pull
+request on GitHub on your behalf.  If this is the case, create a
+gzipped tar file of all new or changed files or a corresponding patch
+file using 'diff -u' or 'diff -c' format and compress it with gzip.
+Please only use gzip compression, as this works well and is available
+on all platforms.  This mode of submission may delay the integration
+as it depends more on the LAMMPS developers.
 
-If the new features/files are broadly useful we may add them as core
-files to LAMMPS or as part of a :doc:`package <Packages_list>`.  All
-packages are listed and described on the :doc:`Packages details
-<Packages_details>` doc page.
-
-Licensing
----------
-
-Note that by providing us files to release, you agree to make them
-open-source, i.e. we can release them under the terms of the GPL
-(version 2) with the rest of LAMMPS.  And similarly as part of a LGPL
-(version 2.1) distribution of LAMMPS that we make available to
-developers on request only and with files that are not authorized for
-that kind of distribution removed (e.g. interface to FFTW).  See the
-:doc:`LAMMPS license <Intro_opensource>` page for details.
 
 External contributions
 ----------------------
@@ -115,11 +88,42 @@ External contributions
 If you prefer to do so, you can also develop and support your add-on
 feature **without** having it included in the LAMMPS distribution, for
 example as a download from a website of your own.  See the `External
-LAMMPS packages and tools <https://www.lammps.org/external.html>`_ page
-of the LAMMPS website for examples of groups that do this.  We are happy
-to advertise your package and website from that page.  Simply email the
-`developers <https://www.lammps.org/authors.html>`_ with info about your
-package and we will post it there.  We recommend to name external
-packages USER-\<name\> so they can be easily distinguished from bundled
-packages that do not have the USER- prefix.
+LAMMPS packages and tools <https://www.lammps.org/external.html>`_
+page of the LAMMPS website for examples of groups that do this.  We
+are happy to advertise your package and website from that page.
+Simply email the `developers <https://www.lammps.org/authors.html>`_
+with info about your package, and we will post it there.  We recommend
+naming external packages USER-\<name\> so they can be easily
+distinguished from packages in the LAMMPS distribution which do not
+have the USER- prefix.
 
+
+Location of files: individual files and packages
+------------------------------------------------
+
+We rarely accept new styles in the core src folder.  Thus, please
+review the list of :doc:`available Packages <Packages_details>` to see
+if your contribution should be added to one of them.  It should fit
+into the general purpose of that package.  If it does not fit well, it
+may be added to one of the EXTRA- packages or the MISC package.
+
+However, if your project includes many related features that are not
+covered by one of the existing packages or is dependent on a library
+(bundled or external), it is best to create a new package with its own
+directory (with a name like FOO).  In addition to your new files, the
+directory should contain a README text file containing your name and
+contact information and a brief description of what your new package
+does.
+
+
+Changes to core LAMMPS files
+--------------------------------
+
+If designed correctly, most additions do not require any changes to
+the core code of LAMMPS; they are simply add-on files that are
+compiled with the rest of LAMMPS.  To make those styles work, you may
+need some trivial changes to the core code.  An example of a trivial
+change is making a parent-class method "virtual" when you derive a new
+child class from it.  If your features involve more substantive
+changes to the core LAMMPS files, it is particularly encouraged that
+you communicate with the LAMMPS developers early in development.

doc/src/Modify_gran_sub_mod.rst

@@ -0,0 +1,175 @@
+Granular Sub-Model styles
+===============================
+
+In granular models, particles are spheres with a finite radius and rotational
+degrees of freedom as further described in the
+:doc:`Howto granular page <Howto_granular>`. Interactions between pair of
+particles or particles and walls may therefore depend on many different modes
+of motion as described in :doc:`pair granular <pair_granular>` and
+:doc:`fix wall/gran <fix_wall_gran>`. In both cases, the exchange of forces,
+torques, and heat flow between two types of bodies is defined using a
+GranularModel class. The GranularModel class organizes the details of an
+interaction using a series of granular sub-models each of which describe a
+particular interaction mode (e.g. normal forces or rolling friction). From a
+parent GranSubMod class, several types of sub-model classes are derived:
+
+* GranSubModNormal: normal force sub-model
+* GranSubModDamping: normal damping sub-model
+* GranSubModTangential: tangential forces and sliding friction sub-model
+* GranSubModRolling: rolling friction sub-model
+* GranSubModTwisting: twisting friction sub-model
+* GranSubModHeat: heat conduction sub-model
+
+For each type of sub-model, more classes are further derived, each describing a
+specific implementation. For instance, from the GranSubModNormal class the
+GranSubModNormalHooke, GranSubModNormalHertz, and GranSubModNormalJKR classes
+are derived which calculate Hookean, Hertzian, or JKR normal forces,
+respectively.  This modular structure simplifies the addition of new granular
+contact models as one only needs to create a new GranSubMod class without
+having to modify the more complex PairGranular, FixGranWall, and GranularModel
+classes. Most GranSubMod methods are also already defined by the parent classes
+so new contact models typically only require edits to a few relevant methods
+(e.g. methods that define coefficients and calculate forces).
+
+Each GranSubMod class has a pointer to both the LAMMPS class and the GranularModel
+class which owns it, ``lmp`` and ``gm``, respectively. The GranularModel class
+includes several public variables that describe the geometry/dynamics of the
+contact such as
+
+.. list-table::
+
+   * - ``xi`` and ``xj``
+     - Positions of the two contacting bodies
+   * - ``vi`` and ``vj``
+     - Velocities of the two contacting bodies
+   * - ``omegai`` and ``omegaj``
+     - Angular velocities of the two contacting bodies
+   * - ``dx`` and ``nx``
+     - The displacement and normalized displacement vectors
+   * - ``r``, ``rsq``, and ``rinv``
+     - The distance, distance squared, and inverse distance
+   * - ``radsum``
+     - The sum of particle radii
+   * - ``vr``, ``vn``, and ``vt``
+     - The relative velocity vector and its normal and tangential components
+   * - ``wr``
+     - The relative rotational velocity
+
+These quantities, among others, are calculated in the ``GranularModel->check_contact()``
+and ``GranularModel->calculate_forces()`` methods which can be referred to for more
+details.
+
+To create a new GranSubMod class, it is recommended that one first looks at similar
+GranSubMod classes. All GranSubMod classes share several general methods which may
+need to be defined
+
+.. list-table::
+
+   * - ``GranSubMod->mix_coeff()``
+     - Optional method to define how coefficients are mixed for different atom types. By default, coefficients are mixed using a geometric mean.
+   * - ``GranSubMod->coeffs_to_local()``
+     - Parses coefficients to define local variables. Run once at model construction.
+   * - ``GranSubMod->init()``
+     - Optional method to define local variables after other GranSubMod types were created. For instance, this method may be used by a tangential model that derives parameters from the normal model.
+
+There are also several type-specific methods
+
+.. list-table::
+
+   * - ``GranSubModNormal->touch()``
+     - Optional method to test when particles are in contact. By default, this is when particles overlap.
+   * - ``GranSubModNormal->pulloff_distance()``
+     - Optional method to return the distance at which particles stop interacting. By default, this is when particles no longer overlap.
+   * - ``GranSubModNormal->calculate_radius()``
+     - Optional method to return the radius of the contact. By default, this returns the radius of the geometric cross section.
+   * - ``GranSubModNormal->set_fncrit()``
+     - Optional method that defines the critical force to break the contact used by some tangential, rolling, and twisting sub-models. By default, this is the current total normal force including damping.
+   * - ``GranSubModNormal->calculate_forces()``
+     - Required method that returns the normal contact force
+   * - ``GranSubModDamping->calculate_forces()``
+     - Required method that returns the normal damping force
+   * - ``GranSubModTangential->calculate_forces()``
+     - Required method that calculates tangential forces/torques
+   * - ``GranSubModTwisting->calculate_forces()``
+     - Required method that calculates twisting friction forces/torques
+   * - ``GranSubModRolling->calculate_forces()``
+     - Required method that calculates rolling friction forces/torques
+   * - ``GranSubModHeat->calculate_heat()``
+     - Required method that returns the rate of heat flow
+
+As an example, say one wanted to create a new normal force option that consisted
+of a Hookean force with a piecewise stiffness. This could be done by adding a new
+set of files ``gran_sub_mod_custom.h``:
+
+.. code-block:: c++
+
+   #ifdef GranSubMod_CLASS
+   // clang-format off
+   GranSubModStyle(hooke/piecewise,GranSubModNormalHookePiecewise,NORMAL);
+   // clang-format on
+   #else
+
+   #ifndef GRAN_SUB_MOD_CUSTOM_H_
+   #define GRAN_SUB_MOD_CUSTOM_H_
+
+   #include "gran_sub_mod.h"
+   #include "gran_sub_mod_normal.h"
+
+   namespace LAMMPS_NS {
+   namespace Granular_NS {
+     class GranSubModNormalHookePiecewise : public GranSubModNormal {
+      public:
+       GranSubModNormalHookePiecewise(class GranularModel *, class LAMMPS *);
+       void coeffs_to_local() override;
+       double calculate_forces() override;
+      protected:
+       double k1, k2, delta_switch;
+     };
+
+   }    // namespace Granular_NS
+   }    // namespace LAMMPS_NS
+
+   #endif /*GRAN_SUB_MOD_CUSTOM_H_ */
+   #endif /*GRAN_SUB_MOD_CLASS_H_ */
+
+
+and ``gran_sub_mod_custom.cpp``
+
+.. code-block:: c++
+
+   #include "gran_sub_mod_custom.h"
+   #include "gran_sub_mod_normal.h"
+   #include "granular_model.h"
+
+   using namespace LAMMPS_NS;
+   using namespace Granular_NS;
+
+   GranSubModNormalHookePiecewise::GranSubModNormalHookePiecewise(GranularModel *gm, LAMMPS *lmp) :
+       GranSubModNormal(gm, lmp)
+   {
+     num_coeffs = 4;
+   }
+
+   /* ---------------------------------------------------------------------- */
+
+   void GranSubModNormalHookePiecewise::coeffs_to_local()
+   {
+     k1 = coeffs[0];
+     k2 = coeffs[1];
+     damp = coeffs[2];
+     delta_switch = coeffs[3];
+   }
+
+   /* ---------------------------------------------------------------------- */
+
+   double GranSubModNormalHookePiecewise::calculate_forces()
+   {
+     double Fne;
+     if (gm->delta >= delta_switch) {
+       Fne = k1 * delta_switch + k2 * (gm->delta - delta_switch);
+     } else {
+       Fne = k1 * gm->delta;
+     }
+     return Fne;
+   }
+

doc/src/Modify_overview.rst

@@ -1,42 +1,44 @@
 Overview
 ========
 
-The best way to add a new feature to LAMMPS is to find a similar feature
-and look at the corresponding source and header files to figure out what
-it does.  You will need some knowledge of C++ to be able to understand
-the high-level structure of LAMMPS and its class organization, but
-functions (class methods) that do actual computations are mostly written
-in C-style code and operate on simple C-style data structures (vectors
-and arrays).  A high-level overview of the programming style choices in
-LAMMPS is :doc:`given elsewhere <Developer_code_design>`.
+The best way to add a new feature to LAMMPS is to find a similar
+feature and look at the corresponding source and header files to
+figure out what it does.  You will need some knowledge of C++ to
+understand the high-level structure of LAMMPS and its class
+organization.  Functions (class methods) that do actual computations
+are mostly written in C-style code and operate on simple C-style data
+structures (vectors and arrays).  A high-level overview of the
+programming style choices in LAMMPS is :doc:`given elsewhere
+<Developer_code_design>`.
 
 Most of the new features described on the :doc:`Modify <Modify>` doc
-page require you to write a new C++ derived class (except for exceptions
-described below, where you can make small edits to existing files).
-Creating a new class requires 2 files, a source code file (\*.cpp) and a
-header file (\*.h).  The derived class must provide certain methods to
-work as a new option.  Depending on how different your new feature is
-compared to existing features, you can either derive from the base class
-itself, or from a derived class that already exists.  Enabling LAMMPS to
-invoke the new class is as simple as putting the two source files in the
-src directory and re-building LAMMPS.
+page require you to write a new C++ derived class (except for
+exceptions described below, where you can make small edits to existing
+files).  Creating a new class requires 2 files, a source code file
+(\*.cpp) and a header file (\*.h).  The derived class must provide
+certain methods to work as a new option.  Depending on how different
+your new feature is compared to existing features, you can either
+derive from the base class itself, or from a derived class that
+already exists.  Enabling LAMMPS to invoke the new class is as simple
+as putting the two source files in the src directory and re-building
+LAMMPS.
 
 The advantage of C++ and its object-orientation is that all the code
 and variables needed to define the new feature are in the 2 files you
-write, and thus should not make the rest of LAMMPS more complex or
-cause side-effect bugs.
+write.  Thus, it should not make the rest of LAMMPS more complex or
+cause bugs through unwanted side effects.
 
-Here is a concrete example.  Suppose you write 2 files pair_foo.cpp
-and pair_foo.h that define a new class PairFoo that computes pairwise
-potentials described in the classic 1997 :ref:`paper <Foo>` by Foo, et al.
-If you wish to invoke those potentials in a LAMMPS input script with a
-command like
+Here is a concrete example.  Suppose you write 2 files
+``pair_foo.cpp`` and ``pair_foo.h`` that define a new class
+``PairFoo`` which computes pairwise potentials described in the
+classic 1997 :ref:`paper <Foo>` by Foo, *et al.* If you wish to invoke
+those potentials in a LAMMPS input script with a command like:
 
 .. code-block:: LAMMPS
 
    pair_style foo 0.1 3.5
 
-then your pair_foo.h file should be structured as follows:
+then your ``pair_foo.h`` file should be structured as follows:
 
 .. code-block:: c++
 
@@ -51,28 +53,27 @@ then your pair_foo.h file should be structured as follows:
    #endif
 
 where "foo" is the style keyword in the pair_style command, and
-PairFoo is the class name defined in your pair_foo.cpp and pair_foo.h
-files.
+``PairFoo`` is the class name defined in your ``pair_foo.cpp`` and
+``pair_foo.h`` files.
 
 When you re-build LAMMPS, your new pairwise potential becomes part of
 the executable and can be invoked with a pair_style command like the
 example above.  Arguments like 0.1 and 3.5 can be defined and
 processed by your new class.
 
-As illustrated by this example pair style, many kinds of options are
-referred to in the LAMMPS documentation as the "style" of a particular
-command.
+As illustrated by this example, many features referred to in the
+LAMMPS documentation are called a "style" of a particular command.
 
 The :doc:`Modify page <Modify>` lists all the common styles in LAMMPS,
-and discusses the header file for the base class that these styles are
-derived from.  Public variables in that file are ones used and set by
-the derived classes which are also used by the base class.  Sometimes
-they are also used by the rest of LAMMPS.  Pure functions, which means
-functions declared as virtual in the base class header file which are
-also set to 0, are functions you **must** implement in your new derived
-class to give it the functionality LAMMPS expects. Virtual functions
-that are not set to 0 are functions you may override or not.  Those
-are usually defined with an empty function body.
+and discusses the header file for the base class that these styles
+derive from.  Public variables in that file can be used and set by the
+derived classes, and may also be used by the base class.  Sometimes
+they are also accessed by the rest of LAMMPS.  Pure functions, which
+means functions declared as virtual in the base class header file and
+which are also set to 0, are functions you **must** implement in your
+new derived class to give it the functionality LAMMPS expects. Virtual
+functions that are not set to 0 are functions you may override or not.
+Those are usually defined with an empty function body.
 
 Additionally, new output options can be added directly to the
 thermo.cpp, dump_custom.cpp, and variable.cpp files.  These are also
@@ -85,9 +86,9 @@ functionality:
   post-processing step.  Many computations are more easily and more
   quickly done that way.
 * Do not try to do anything within the timestepping of a run that is not
-  parallel.  For example do not accumulate a bunch of data on a single
-  processor and analyze it.  You run the risk of seriously degrading
-  the parallel efficiency this way.
+  parallel.  For example, do not accumulate a bunch of data on a single
+  processor and analyze it.  That would run the risk of seriously degrading
+  the parallel efficiency.
 * If your new feature reads arguments or writes output, make sure you
   follow the unit conventions discussed by the :doc:`units <units>`
   command.

doc/src/Modify_pair.rst

@@ -2,11 +2,11 @@ Pair styles
 ===========
 
 Classes that compute pairwise non-bonded interactions are derived from
-the Pair class.  In LAMMPS, pairwise calculation include many-body
-potentials such as EAM, Tersoff, or ReaxFF where particles interact
-without an explicit bond topology but include interactions beyond
-pairwise non-bonded contributions.  New styles can be created to add
-support for additional pair potentials to LAMMPS.  When the
+the ``Pair`` class.  In LAMMPS, pairwise force calculations include
+many-body potentials such as EAM, Tersoff, or ReaxFF where particles
+interact without an explicit bond topology but include interactions
+beyond pairwise non-bonded contributions.  New styles can be created to
+add support for additional pair potentials to LAMMPS.  When the
 modifications are small, sometimes it is more effective to derive from
 an existing pair style class.  This latter approach is also used by
 :doc:`Accelerator packages <Speed_packages>` where the accelerated style
@@ -15,10 +15,13 @@ names differ from their base classes by an appended suffix.
 The file ``src/pair_lj_cut.cpp`` is an example of a Pair class with a
 very simple potential function.  It includes several optional methods to
 enable its use with :doc:`run_style respa <run_style>` and :doc:`compute
-group/group <compute_group_group>`.
+group/group <compute_group_group>`.  :doc:`Developer_write_pair` contains
+a detailed discussion of writing new pair styles from scratch, and how
+simple and more complex pair styles can be implemented with examples
+from existing pair styles.
 
 Here is a brief list of some the class methods in the Pair class that
-*must* be or *may* be overridden in a derived class.
+*must* be or *may* be overridden in a derived class for a new pair style.
 
 +---------------------------------+---------------------------------------------------------------------+
 | Required                        | "pure" methods that *must* be overridden in a derived class         |

doc/src/Modify_requirements.rst

@@ -0,0 +1,384 @@
+Requirements for contributions to LAMMPS
+========================================
+
+The following is a summary of the current requirements and
+recommendations for including contributed source code or documentation
+into the LAMMPS software distribution.
+
+Motivation
+----------
+
+The LAMMPS developers are committed to provide a software package that
+is versatile, reliable, high-quality, efficient, portable, and easy to
+maintain and modify.  Achieving all of these goals is challenging
+since a large part of LAMMPS consists of contributed code from many
+different authors who may not be professionally trained programmers or
+familiar with the idiosyncrasies of maintaining a large software
+package.  In addition, changes that interfere with the parallel
+efficiency of the core code must be avoided.  As LAMMPS continues to
+grow and more features and functionality are added, it is necessary to
+follow established guidelines when accepting new contributions while
+also working at the same time to improve the existing code.
+
+The following requirements and recommendations are provided as a
+guide.  They indicate which individual requirements are strict, and
+which represent a preference and thus are negotiable or optional.
+Please feel free to contact the LAMMPS core developers in case you
+need additional explanations or clarifications, or you need assistance
+in implementing the (strict) requirements for your contributions.
+Requirements include:
+
+* :ref:`Licensing requirements <ReqLicense>` (strict)
+* :ref:`Integration testing <ReqIntegrationTesting>` (strict)
+* :ref:`Documentation <ReqDocumentation>` (strict)
+* :ref:`Programming language standards <ReqProgrammingStandards>` (strict)
+* :ref:`Build system <ReqBuildSystem>` (strict)
+* :ref:`Command or style names <ReqNaming>` (strict)
+* :ref:`Programming style requirements <ReqProgrammingStyle>` (varied)
+* :ref:`Examples <ReqExamples>` (preferred)
+* :ref:`Error or warning messages and explanations <ReqErrorMessages>` (preferred)
+* :ref:`Citation reminder <ReqCitation>` (optional)
+* :ref:`Testing <ReqUnitTesting>` (optional)
+
+.. _ReqLicense:
+
+Licensing requirements (strict)
+-------------------------------
+
+Contributing authors agree when submitting a pull request that their
+contributions can be distributed under the LAMMPS license conditions.
+This is the GNU public license in version 2 (not 3 or later) for the
+publicly distributed versions, e.g. on the LAMMPS homepage or on
+GitHub.  We also have a version of LAMMPS under LGPL 2.1 terms which
+is available on request; this will usually be the latest available or
+a previous stable version with a few LGPL 2.1 incompatible files
+removed.  More details are found on the :doc:`LAMMPS open-source
+license page <Intro_opensource>`.
+
+Your new source files should have the LAMMPS copyright and GPL notice,
+followed by your name and email address at the top, like other
+user-contributed LAMMPS source files.
+
+Contributions may be under a different license as long as that license
+does not conflict with the aforementioned terms.  Contributions that
+use code with a conflicting license can be split into two parts:
+
+1. the core parts (i.e. parts that must be in the `src` tree) that are
+   licensed under compatible terms and bundled with the LAMMPS sources
+2. an external library that must be downloaded and compiled (either
+   separately or as part of the LAMMPS compilation)
+
+Please note, that this split licensing mode may complicate including
+the contribution in binary packages.
+
+.. _ReqIntegrationTesting:
+
+Integration testing (strict)
+----------------------------
+
+Where possible we use available continuous integration tools to search
+for common programming mistakes, portability limitations, incompatible
+formatting, and undesired side effects. Contributed code must pass the
+automated tests on GitHub before it can be merged with the LAMMPS
+distribution. These tests compile LAMMPS in a variety of environments
+and settings and run the bundled unit tests.  At the discretion of the
+LAMMPS developer managing the pull request, additional tests may be
+activated that test for "side effects" on running a collection of
+input decks and create consistent results.  The translation of the
+documentation to HTML and PDF is also tested.
+
+This means that contributed source code **must** compile with the most
+current version of LAMMPS with ``-DLAMMPS_BIGBIG`` in addition to the
+default setting of ``-DLAMMPS_SMALLBIG``.  The code needs to work
+correctly in both cases, and also in serial and parallel using MPI.
+
+Some "disruptive" changes may break tests and require updates to the
+testing tools or scripts or tests themselves.  This is rare.  If in
+doubt, contact the LAMMPS developer that is assigned to the pull
+request.
+
+.. _ReqDocumentation:
+
+Documentation (strict)
+----------------------
+
+Contributions that add new styles or commands or augment existing ones
+must include the corresponding new or modified documentation in
+`ReStructuredText format <rst_>`_ (.rst files in the ``doc/src/``
+folder). The documentation should be written in American English and the
+.rst file must only use ASCII characters, so it can be cleanly
+translated to PDF files (via `sphinx <https://www.sphinx-doc.org>`_ and
+PDFLaTeX).  Special characters may be included via embedded math
+expression typeset in a LaTeX subset.
+
+.. _rst: https://www.sphinx-doc.org/en/master/usage/restructuredtext/index.html
+
+When adding new commands, they need to be integrated into the sphinx
+documentation system, and the corresponding command tables and lists
+updated. When translating the documentation into html files there
+should be no warnings. When adding a new package, some lists
+describing packages must also be updated as well as a package specific
+description added.  Likewise, if necessary, some package specific
+build instructions should be included.
+
+As appropriate, the text files with the documentation can include
+inline mathematical expressions or figures (see ``doc/JPG`` for
+examples).  Additional PDF files with further details may also be
+included; see ``doc/PDF`` for examples.  The page should also include
+literature citations as appropriate; see the bottom of
+``doc/fix_nh.rst`` for examples and the earlier part of the same file
+for how to format the cite itself.  Citation labels must be unique
+across **all** .rst files.  The "Restrictions" section of the page
+should indicate if your command is only available if LAMMPS is built
+with the appropriate package.  See other command doc files for
+examples of how to do this.
+
+Please run at least "make html" and "make spelling" from within the
+doc/src directory, and carefully inspect and proofread the resulting
+HTML format doc page before submitting your code.  Upon submission of
+a pull request, checks for error free completion of the HTML and PDF
+build will be performed and also a spell check, a check for correct
+anchors and labels, and a check for completeness of references to all
+styles in their corresponding tables and lists is run.  In case the
+spell check reports false positives, they can be added to the file
+``doc/utils/sphinx-config/false_positives.txt``
+
+Contributions that add or modify the library interface or "public"
+APIs from the C++ code or the Fortran module must include suitable
+doxygen comments in the source and corresponding changes to the
+documentation sources for the "Programmer Guide" guide section of the
+LAMMPS manual.
+
+If your feature requires some more complex steps and explanations to
+be used correctly or some external or bundled tools or scripts, we
+recommend that you also contribute a :doc:`Howto document <Howto>`
+providing some more background information and some tutorial material.
+This can also be used to provide more in-depth explanations of models
+that require use of multiple commands.
+
+As a rule-of-thumb, the more clear and self-explanatory you make your
+documentation, README files and examples, and the easier you make it
+for people to get started, the more likely it is that users will try
+out your new feature.
+
+.. _ReqProgrammingStandards:
+
+Programming language standards (strict)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The core of LAMMPS is written in C++11 in a style that can be mostly
+described as "C with classes".  Advanced C++ features like operator
+overloading or excessive use of templates are avoided with the intent to
+keep the code readable to programmers that have limited C++ programming
+experience.  C++ constructs are acceptable when they help improve the
+readability and reliability of the code, e.g. when using the
+`std::string` class instead of manipulating pointers and calling the
+string functions of the C library.  In addition, a collection of
+convenient :doc:`utility functions and classes <Developer_utils>` for
+recurring tasks and a collection of :doc:`platform neutral functions
+<Developer_platform>` for improved portability are provided.
+Contributions with code requiring more recent C++ standards are only
+accepted as packages with the post C++11 standard code confined to the
+package so that it is optional.
+
+Included Fortran code has to be compatible with the Fortran 2003
+standard.  Since not all platforms supported by LAMMPS provide good
+support for compiling Fortran files, it should be considered to rewrite
+these parts as C++ code, if possible and thus allow for a wider adoption
+of the contribution.  As of January 2023, all previously included
+Fortran code for the LAMMPS executable has been replaced by equivalent
+C++ code.
+
+Python code must be compatible with Python 3.5 and later.  Large parts
+of LAMMPS (including the :ref:`PYTHON package <PKG-PYTHON>`) are also
+compatible with Python 2.7.  Compatibility with Python 2.7 is desirable,
+but compatibility with Python 3.5 is **required**.
+
+Compatibility with older programming language standards is very
+important to maintain portability and availability of LAMMPS on many
+platforms.  This applies especially to HPC cluster environments, which
+tend to be running older software stacks and where LAMMPS users may be
+required to use those older tools for access to advanced hardware
+features or not have the option to install newer compilers or libraries.
+
+.. _ReqBuildSystem:
+
+Build system (strict)
+---------------------
+
+LAMMPS currently supports two build systems: one that is based on
+:doc:`traditional Makefiles <Build_make>` and one that is based on
+:doc:`CMake <Build_cmake>`.  Therefore, your contribution must be
+compatible with and support both build systems.
+
+For a single pair of header and implementation files that are an
+independent feature, it is usually only required to add them to
+``src/.gitignore``.
+
+For traditional make, if your contributed files or package depend on
+other LAMMPS style files or packages also being installed
+(e.g. because your file is a derived class from the other LAMMPS
+class), then an ``Install.sh`` file is also needed to check for those
+dependencies and modifications to ``src/Depend.sh`` to trigger the checks.
+See other README and Install.sh files in other directories as
+examples.
+
+Similarly, for CMake support, changes may need to be made to
+``cmake/CMakeLists.txt``, some of the files in ``cmake/presets``, and
+possibly a file with specific instructions needs to be added to
+``cmake/Modules/Packages/``.  Please check out how this is handled for
+existing packages and ask the LAMMPS developers if you need assistance.
+
+.. _ReqNaming:
+
+Command or style names, file names, and keywords (strict)
+---------------------------------------------------------
+
+All user-visible command or style names should be all lower case and
+should only use letters, numbers, or forward slashes.  They should be
+descriptive and initialisms should be avoided unless they are well
+established (e.g. lj for Lennard-Jones).  For a compute style
+"some/name" the source files must be called ``compute_some_name.h`` and
+``compute_some_name.cpp``. The "include guard" in the header file would
+then be ``LMP_COMPUTE_SOME_NAME_H`` and the class name
+``ComputeSomeName``.
+
+.. _ReqProgrammingStyle:
+
+Programming style requirements (varied)
+---------------------------------------
+
+To maintain source code consistency across contributions from many
+people, there are various programming style requirements for
+contributions to LAMMPS.  Some of these requirements are strict and
+must be followed, while others are only preferred and thus may be
+skipped.  An in-depth discussion of the style guidelines is provided
+in the :doc:`programming style doc page <Modify_style>`.
+
+.. _ReqExamples:
+
+Examples (preferred)
+--------------------
+
+For many new features, it is preferred that example scripts (simple,
+small, fast to complete on 1 CPU) are included that demonstrate the
+use of new or extended functionality. These are typically include
+under the examples or examples/PACKAGES directory and are further
+described on the :doc:`examples page <Examples>`.  Guidelines for
+input scripts include:
+
+- commands that generate output should be commented out (except when the
+  output is the sole purpose or the feature, e.g. for a new compute)
+
+- commands like :doc:`log <log>`, :doc:`echo <echo>`, :doc:`package
+  <package>`, :doc:`processors <processors>`, :doc:`suffix <suffix>` may
+  **not** be used in the input file (exception: "processors * * 1" or
+  similar is acceptable when used to avoid unwanted domain decomposition
+  of empty volumes)
+
+- outside of the log files, no generated output should be included
+
+- custom thermo_style settings may not include output measuring CPU or other
+  time as it complicates comparisons between different runs
+
+- input files should be named ``in.name``, data files should be named
+  ``data.name`` and log files should be named ``log.version.name.<compiler>.<ncpu>``
+
+- the total file size of all the inputs and outputs should be small
+
+- where possible, potential files from the "potentials" folder or data
+  file from other folders should be re-used through symbolic links
+
+.. _ReqErrorMessages:
+
+Error or warning messages and explanations (preferred)
+------------------------------------------------------
+
+.. versionchanged:: 4May2022
+
+Starting with LAMMPS version 4 May 2022, the LAMMPS developers have
+agreed on a new policy for error and warning messages.
+
+Previously, all error and warning strings were supposed to be listed in
+the class header files with an explanation.  Those would then be
+regularly "harvested" and transferred to alphabetically sorted lists in
+the manual.  To avoid excessively long lists and to reduce effort, this
+came with a requirement to have rather generic error messages (e.g.
+"Illegal ... command").  To identify the specific cause, the name of the
+source file and the line number of the error location would be printed,
+so that one could look up the cause by reading the source code.
+
+The new policy encourages more specific error messages that ideally
+indicate the cause directly, and requiring no further lookup. This is
+aided by the `{fmt} library <https://fmt.dev>`_ enabling Error class
+methods that take a variable number of arguments and an error text that
+will be treated like a {fmt} syntax format string. Error messages should
+still preferably be kept to a single line or two lines at most.
+
+For more complex explanations or errors that have multiple possible
+reasons, a paragraph should be added to the `Error_details` page with an
+error code reference (e.g. ``.. _err0001:``) then the utility function
+:cpp:func:`utils::errorurl() <LAMMPS_NS::utils::errorurl>` can be used
+to generate a URL that will directly lead to that paragraph.  An error
+for missing arguments can be easily generated using the
+:cpp:func:`utils::missing_cmd_args()
+<LAMMPS_NS::utils::missing_cmd_args>` convenience function.
+An example for this approach would be the
+``src/read_data.cpp`` and ``src/atom.cpp`` files that implement the
+:doc:`read_data <read_data>` and :doc:`atom_modify <atom_modify>`
+commands and that may create :ref:`"Unknown identifier in data file" <err0001>`
+errors that may have multiple possible reasons which complicates debugging,
+and thus require some additional explanation.
+
+The transformation of existing LAMMPS code to this new scheme is
+ongoing.  Given the size of the LAMMPS code base, it will take a
+significant amount of time to complete.  For new code, however,
+following the new approach is strongly preferred.  The expectation is
+that the new scheme will make understanding errors easier for LAMMPS
+users, developers, and maintainers.
+
+.. _ReqCitation:
+
+Citation reminder (optional)
+-----------------------------
+
+If there is a paper of yours describing your feature (either the
+algorithm/science behind the feature itself, or its initial usage, or
+its implementation in LAMMPS), you can add the citation to the \*.cpp
+source file.  See ``src/DIFFRACTION/compute_saed.cpp`` for an example.
+A BibTeX format citation is stored in a string variable at the top of
+the file, and a single line of code registering this variable is added
+to the constructor of the class.  When your feature is used, then
+LAMMPS (by default) will print the brief info and the DOI in the first
+line to the screen and the full citation to the log file.
+
+If there is additional functionality (which may have been added later)
+described in a different publication, additional citation descriptions
+may be added so long as they are only registered when the
+corresponding keyword activating this functionality is used.
+
+With these options, it is possible to have LAMMPS output a specific
+citation reminder whenever a user invokes your feature from their
+input script.  Please note that you should *only* use this for the
+*most* relevant paper for a feature and a publication that you or your
+group authored.  E.g. adding a citation in the source code for a paper
+by Nose and Hoover if you write a fix that implements their integrator
+is not the intended usage.  That kind of citation should just be
+included in the documentation page you provide describing your
+contribution.  If you are not sure what the best option would be,
+please contact the LAMMPS developers for advice.
+
+.. _ReqUnitTesting:
+
+Testing (optional)
+------------------
+
+If your contribution contains new utility functions or a supporting
+class (i.e. anything that does not depend on a LAMMPS object), new
+unit tests should be added to a suitable folder in the ``unittest``
+tree.  When adding a new LAMMPS style computing forces or selected
+fixes, a ``.yaml`` file with a test configuration and reference data
+should be added for the styles where a suitable tester program already
+exists (e.g. pair styles, bond styles, etc.). Please see :ref:`this
+section in the manual <testing>` for more information on how to
+enable, run, and expand testing.

doc/src/Modify_style.rst

@@ -1,350 +1,58 @@
-LAMMPS programming style and requirements for contributions
-===========================================================
+LAMMPS programming style
+========================
 
-The following is a summary of the current requirements and
-recommendations for including contributed source code or documentation
-into the LAMMPS software distribution.
+The aim of the LAMMPS developers is to use a consistent programming
+style and naming conventions across the entire code base, as this
+helps with maintenance, debugging, and understanding the code, both
+for developers and users.  This page provides a list of standard style
+choices used in LAMMPS.  Some of these standards are required, while
+others are just preferred.  Following these conventions will make it
+much easier to integrate your contribution.  If you are uncertain,
+please ask.
 
-Motivation
-----------
+The files `pair_lj_cut.h`, `pair_lj_cut.cpp`, `utils.h`, and
+`utils.cpp` may serve as representative examples.
 
-The LAMMPS developers are committed to providing a software package that
-is versatile, reliable, high-quality, efficient, portable, and easy to
-maintain and modify.  Achieving all of these goals is challenging since
-a large part of LAMMPS consists of contributed code from many different
-authors and not many of them are professionally trained programmers and
-familiar with the idiosyncrasies of maintaining a large software
-package.  In addition, changes that interfere with the parallel
-efficiency of the core code must be avoided.  As LAMMPS continues to
-grow and more features and functionality are added, it becomes a
-necessity to be more discriminating with new contributions while also
-working at the same time to improve the existing code.
+Include files (varied)
+^^^^^^^^^^^^^^^^^^^^^^
 
-The following requirements and recommendations are provided to help
-maintaining or improving that status.  Where possible we utilize
-available continuous integration tools to search for common programming
-mistakes, portability limitations, incompatible formatting, and
-undesired side effects.  It is indicated which requirements are strict,
-and which represent a preference and thus are negotiable or optional.
+- Header files that define a new LAMMPS style (i.e. that have a
+  ``SomeStyle(some/name,SomeName);`` macro in them) should only use
+  the include file for the base class and otherwise use forward
+  declarations and pointers; when interfacing to a library use the
+  PIMPL (pointer to implementation) approach where you have a pointer
+  to a struct that contains all library specific data (and thus
+  requires the library header) but use a forward declaration and
+  define the struct only in the implementation file. This is a
+  **strict** requirement since this is where type clashes between
+  packages and hard-to-find bugs have regularly manifested in the
+  past.
 
-Please feel free to contact the LAMMPS core developers in case you need
-additional explanations or clarifications or in case you need assistance
-in realizing the (strict) requirements for your contributions.
+- Header files, especially those defining a "style", should only use
+  the absolute minimum number of include files and **must not**
+  contain any ``using`` statements. Typically, that would only be the
+  header for the base class.  Instead, any include statements should
+  be put in the corresponding implementation files and forward
+  declarations be used.  For implementation files, the "include what
+  you use" principle should be employed.  However, there is the
+  notable exception that when the ``pointers.h`` header is included
+  (or one of the base classes derived from it) certain headers will
+  always be included and thus do not need to be explicitly specified.
+  These are: `mpi.h`, `cstddef`, `cstdio`, `cstdlib`, `string`,
+  `utils.h`, `vector`, `fmt/format.h`, `climits`, `cinttypes`.  This
+  also means any such file can assume that `FILE`, `NULL`, and
+  `INT_MAX` are defined.
 
-Licensing requirements (strict)
--------------------------------
+- System headers or headers from installed libraries are included with
+  angular brackets (example: ``#include <vector>``), while local
+  include files use double quotes (example: ``#include "atom.h"``)
 
-Contributing authors agree when submitting a pull request that their
-contributions can be distributed under the LAMMPS license
-conditions. This is the GNU public license in version 2 (not 3 or later)
-for the publicly distributed versions, e.g. on the LAMMPS homepage or on
-GitHub.  On request we also make a version of LAMMPS available under
-LGPL 2.1 terms; this will usually be the latest available or a previous
-stable version with a few LGPL 2.1 incompatible files removed.
-
-Your new source files should have the LAMMPS copyright, GPL notice, and
-your name and email address at the top, like other user-contributed
-LAMMPS source files.
-
-Contributions may be under a different license for long as that
-license does not conflict with the aforementioned terms.  Contributions
-that use code with a conflicting license can be split into two parts:
-
-1. the core parts (i.e. parts that must be in the `src` tree) that are
-   licensed under compatible terms and bundled with the LAMMPS sources
-2. an external library that must be downloaded and compiled (either
-   separately or as part of the LAMMPS compilation)
-
-Please note, that this split licensed mode may complicate including the
-contribution in binary packages.
-
-Using Pull Requests on GitHub (preferred)
------------------------------------------
-
-All contributions to LAMMPS are processed as pull requests on GitHub
-(this also applies to the work of the core LAMMPS developers).  A
-:doc:`tutorial for submitting pull requests on GitHub <Howto_github>` is
-provided.  If this is still problematic, contributors may contact any of
-the core LAMMPS developers for help or to create a pull request on their
-behalf.  This latter way of submission may delay the integration as it
-depends on the amount of time required to prepare the pull request and
-free time available by the LAMMPS developer in question to spend on this
-task.
-
-Integration Testing (strict)
-----------------------------
-
-Contributed code, like all pull requests, must pass the automated
-tests on GitHub before it can be merged with the LAMMPS distribution.
-These tests compile LAMMPS in a variety of environments and settings and
-run the bundled unit tests.  At the discretion of the LAMMPS developer
-managing the pull request, additional tests may be activated that test
-for "side effects" on running a collection of input decks and create
-consistent results.  Also, the translation of the documentation to HTML
-and PDF is tested for.
-
-More specifically, this means that contributed source code **must**
-compile with the most current version of LAMMPS with ``-DLAMMPS_BIGBIG``
-in addition to the default setting of ``-DLAMMPS_SMALLBIG``.  The code
-needs to work correctly in both cases and also in serial and parallel
-using MPI.
-
-Some "disruptive" changes may break tests and require updates to the
-testing tools or scripts or tests themselves.  This is rare.  If in
-doubt, contact the LAMMPS developer that is assigned to the pull request
-for further details and explanations and suggestions of what needs to be
-done.
-
-Documentation (strict)
-----------------------
-
-Contributions that add new styles or commands or augment existing ones
-must include the corresponding new or modified documentation in
-`ReStructuredText format <rst_>`_ (.rst files in the ``doc/src/``
-folder). The documentation shall be written in American English and the
-.rst file must use only ASCII characters so it can be cleanly translated
-to PDF files (via `sphinx <https://www.sphinx-doc.org>`_ and PDFLaTeX).
-Special characters may be included via embedded math expression typeset
-in a LaTeX subset.
-
-.. _rst: https://www.sphinx-doc.org/en/master/usage/restructuredtext/index.html
-
-When adding new commands, they need to be integrated into the sphinx
-documentation system, and the corresponding command tables and lists
-updated. When translating the documentation into html files there should
-be no warnings. When adding a new package also some lists describing
-packages must be updated as well as a package specific description added
-and, if necessary, some package specific build instructions included.
-
-As appropriate, the text files with the documentation can include inline
-mathematical expression or figures (see ``doc/JPG`` for examples).
-Additional PDF files with further details (see ``doc/PDF`` for examples) may
-also be included.  The page should also include literature citations as
-appropriate; see the bottom of ``doc/fix_nh.rst`` for examples and the
-earlier part of the same file for how to format the cite itself.
-Citation labels must be unique across **all** .rst files.  The
-"Restrictions" section of the page should indicate if your command is
-only available if LAMMPS is built with the appropriate FOO package.  See
-other package doc files for examples of how to do this.
-
-Please run at least "make html" and "make spelling" and carefully
-inspect and proofread the resulting HTML format doc page before
-submitting your code.  Upon submission of a pull request, checks for
-error free completion of the HTML and PDF build will be performed and
-also a spell check, a check for correct anchors and labels, and a check
-for completeness of references all styles in their corresponding tables
-and lists is run.  In case the spell check reports false positives they
-can be added to the file ``doc/utils/sphinx-config/false_positives.txt``
-
-Contributions that add or modify the library interface or "public" APIs
-from the C++ code or the Fortran module must include suitable doxygen
-comments in the source and corresponding changes to the documentation
-sources for the "Programmer Guide" guide section of the LAMMPS manual.
-
-Examples (preferred)
---------------------
-
-In most cases, it is preferred that example scripts (simple, small, fast
-to complete on 1 CPU) are included that demonstrate the use of new or
-extended functionality. These are typically under the examples or
-examples/PACKAGES directory.  A few guidelines for such example input
-decks.
-
-- commands that generate output should be commented out (except when the
-  output is the sole purpose or the feature, e.g. for a new compute).
-
-- commands like :doc:`log <log>`, :doc:`echo <echo>`, :doc:`package
-  <package>`, :doc:`processors <processors>`, :doc:`suffix <suffix>` may
-  **not** be used in the input file (exception: "processors * * 1" or
-  similar is acceptable when used to avoid unwanted domain decomposition
-  of empty volumes).
-
-- outside of the log files no generated output should be included
-
-- custom thermo_style settings may not include output measuring CPU or other time
-  as that makes comparing the thermo output between different runs more complicated.
-
-- input files should be named ``in.name``, data files should be named
-  ``data.name`` and log files should be named ``log.version.name.<compiler>.<ncpu>``
-
-- the total file size of all the inputs and outputs should be small
-
-- where possible potential files from the "potentials" folder or data
-  file from other folders should be re-used through symbolic links
-
-Howto document (optional)
--------------------------
-
-If your feature requires some more complex steps and explanations to be
-used correctly or some external or bundled tools or scripts, we
-recommend that you also contribute a :doc:`Howto document <Howto>`
-providing some more background information and some tutorial material.
-This can also be used to provide more in-depth explanations for bundled
-examples.
-
-As a general rule-of-thumb, the more clear and self-explanatory you make
-your documentation, README files and examples, and the easier you make
-it for people to get started, the more likely it is that users will try
-out your new feature.
-
-Programming Style Requirements (varied)
----------------------------------------
-
-The LAMMPS developers aim to employ a consistent programming style and
-naming conventions across the entire code base, as this helps with
-maintenance, debugging, and understanding the code, both for developers
-and users.
-
-The files `pair_lj_cut.h`, `pair_lj_cut.cpp`, `utils.h`, and `utils.cpp`
-may serve as representative examples.
-
-Command or Style names, file names, and keywords (mostly strict)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-All user-visible command or style names should be all lower case and
-should only use letters, numbers, or forward slashes.  They should be
-descriptive and initialisms should be avoided unless they are well
-established (e.g. lj for Lennard-Jones).  For a compute style
-"some/name" the source files must be called `compute_some_name.h` and
-`compute_some_name.cpp`. The "include guard" would then be
-`LMP_COMPUTE_SOME_NAME_H` and the class name `ComputeSomeName`.
-
-Whitespace and permissions (preferred)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Source files should not contain TAB characters unless required by the
-syntax (e.g. in makefiles) and no trailing whitespace.  Text files
-should be added with Unix-style line endings (LF-only). Git will
-automatically convert those in both directions when running on Windows;
-use dos2unix on Linux machines to convert files.  Text files should have
-a line ending on the last line.
-
-All files should have 0644 permissions, i.e writable to the user only
-and readable by all and no executable permissions.  Executable
-permissions (0755) should only be on shell scripts or python or similar
-scripts for interpreted script languages.
-
-You can check for these issues with the python scripts in the
-:ref:`"tools/coding_standard" <coding_standard>` folder.  When run
-normally with a source file or a source folder as argument, they will
-list all non-conforming lines.  By adding the `-f` flag to the command
-line, they will modify the flagged files to try removing the detected
-issues.
-
-Indentation and Placement of Braces (strongly preferred)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-LAMMPS uses 2 characters per indentation level and lines should be
-kept within 100 characters wide.
-
-For new files added to the "src" tree, a `clang-format
-<https://clang.llvm.org/docs/ClangFormat.html>`_ configuration file is
-provided under the name `.clang-format`.  This file is compatible with
-clang-format version 8 and later. With that file present files can be
-reformatted according to the configuration with a command like:
-`clang-format -i new-file.cpp`.  Ideally, this is done while writing the
-code or before a pull request is submitted.  Blocks of code where the
-reformatting from clang-format yields undesirable output may be
-protected with placing a pair `// clang-format off` and `// clang-format
-on` comments around that block.
-
-Error or warning messages and explanations (preferred)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. versionchanged:: 4May2022
-
-Starting with LAMMPS version 4 May 2022 the LAMMPS developers have
-agreed on a new policy for error and warning messages.
-
-Previously, all error and warning strings were supposed to be listed in
-the class header files with an explanation.  Those would then be
-regularly "harvested" and transferred to alphabetically sorted lists in
-the manual.  To avoid excessively long lists and to reduce effort, this
-came with a requirement to have rather generic error messages (e.g.
-"Illegal ... command").  To identify the specific cause, the name of the
-source file and the line number of the error location would be printed,
-so that one could look up the cause by reading the source code.
-
-The new policy encourages more specific error messages that ideally
-indicate the cause directly and no further lookup would be needed.
-This is aided by using the `{fmt} library <https://fmt.dev>`_ to convert
-the Error class commands so that they take a variable number of arguments
-and error text will be treated like a {fmt} syntax format string.
-Error messages should still kept to a single line or two lines at the most.
-
-For more complex explanations or errors that have multiple possible
-reasons, a paragraph should be added to the `Error_details` page with an
-error code reference (e.g. ``.. _err0001:``) then the utility function
-:cpp:func:`utils::errorurl() <LAMMPS_NS::utils::errorurl>` can be used
-to generate an URL that will directly lead to that paragraph.  An error
-for missing arguments can be easily generated using the
-:cpp:func:`utils::missing_cmd_args()
-<LAMMPS_NS::utils::missing_cmd_args>` convenience function.
-
-The transformation of existing LAMMPS code to this new scheme is ongoing
-and - given the size of the LAMMPS source code - will take a significant
-amount of time until completion.  However, for new code following the
-new approach is strongly preferred.  The expectation is that the new
-scheme will make it easier for LAMMPS users, developers, and
-maintainers.
-
-An example for this approach would be the
-``src/read_data.cpp`` and ``src/atom.cpp`` files that implement the
-:doc:`read_data <read_data>` and :doc:`atom_modify <atom_modify>`
-commands and that may create :ref:`"Unknown identifier in data file" <err0001>`
-errors that seem difficult to debug for users because they may have
-one of multiple possible reasons, and thus require some additional explanations.
-
-Programming language standards (required)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The core of LAMMPS is written in C++11 in a style that can be mostly
-described as "C with classes".  Advanced C++ features like operator
-overloading or excessive use of templates are avoided with the intent to
-keep the code readable to programmers that have limited C++ programming
-experience.  C++ constructs are acceptable when they help improving the
-readability and reliability of the code, e.g. when using the
-`std::string` class instead of manipulating pointers and calling the
-string functions of the C library.  In addition a collection of
-convenient :doc:`utility functions and classes <Developer_utils>` for
-recurring tasks and a collection of
-:doc:`platform neutral functions <Developer_platform>` for improved
-portability are provided.
-
-Included Fortran code has to be compatible with the Fortran 2003
-standard.  Python code must be compatible with Python 3.5.  Large parts
-or LAMMPS (including the :ref:`PYTHON package <PKG-PYTHON>`) are also
-compatible with Python 2.7.  Compatibility with Python 2.7 is
-desirable, but compatibility with Python 3.5 is **required**.
-
-Compatibility with these older programming language standards is very
-important to maintain portability and availability of LAMMPS on many
-platforms.  This applies especially to HPC cluster environments, which
-tend to be running older software stacks and LAMMPS users may be
-required to use those older tools for access to advanced hardware
-features or not have the option to install newer compilers or libraries.
-
-Programming conventions (varied)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The following is a collection of conventions that should be applied when
-writing code for LAMMPS.  Following these steps will make it much easier
-to integrate your contribution. Please have a look at the existing files
-in packages in the src directory for examples.  As a demonstration for
-how can be adapted to these conventions you may compare the REAXFF
-package with the what it looked like when it was called USER-REAXC.  If
-you are uncertain, please ask.
-
-- system headers or from installed libraries are include with angular
-  brackets (example: ``#include <vector>``), while local include file
-  use double quotes (example: ``#include "atom.h"``).
-
-- when including system header files from the C library use the
+- When including system header files from the C library use the
   C++-style names (``<cstdlib>`` or ``<cstring>``) instead of the
   C-style names (``<stdlib.h>`` or ``<string.h>``)
 
-- the order of ``#include`` statements in a file ``some_name.cpp`` that
-  implements a class ``SomeName`` defined in a header file
+- The order of ``#include`` statements in a file ``some_name.cpp``
+  that implements a class ``SomeName`` defined in a header file
   ``some_name.h`` should be as follows:
 
   - ``#include "some_name.h"`` followed by an empty line
@@ -352,34 +60,70 @@ you are uncertain, please ask.
   - LAMMPS include files e.g. ``#include "comm.h"`` or ``#include
     "modify.h"`` in alphabetical order followed by an empty line
 
-  - system header files from the C++ or C standard library followed by
+  - System header files from the C++ or C standard library followed by
     an empty line
 
   - ``using namespace LAMMPS_NS`` or other namespace imports.
 
+Whitespace (preferred)
+^^^^^^^^^^^^^^^^^^^^^^
+
+Source files should not contain TAB characters unless required by the
+syntax (e.g. in makefiles) and no trailing whitespace.  Text files
+should have Unix-style line endings (LF-only). Git will automatically
+convert those in both directions when running on Windows; use dos2unix
+on Linux machines to convert files to Unix-style line endings.  The
+last line of text files include a line ending.
+
+You can check for these issues with the python scripts in the
+:ref:`"tools/coding_standard" <coding_standard>` folder.  When run
+normally with a source file or a source folder as argument, they will
+list all non-conforming lines.  By adding the `-f` flag to the command
+line, they will modify the flagged files to try to remove the detected
+issues.
+
+Placement of braces (strongly preferred)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+For new files added to the "src" tree, a `clang-format
+<https://clang.llvm.org/docs/ClangFormat.html>`_ configuration file is
+provided under the name `.clang-format`.  This file is compatible with
+clang-format version 8 and later. With that file present, files can be
+reformatted according to the configuration with a command like:
+`clang-format -i new-file.cpp`.  Ideally, this is done while writing
+the code or before a pull request is submitted.  Blocks of code where
+the reformatting from clang-format yields hard-to-read or otherwise
+undesirable output may be protected with placing a pair `//
+clang-format off` and `// clang-format on` comments around that block.
+
+Miscellaneous standards (varied)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
 - I/O is done via the C-style stdio library and **not** iostreams.
 
 - Do not use so-called "alternative tokens" like ``and``, ``or``,
   ``not`` and similar, but rather use the corresponding operators
   ``&&``, ``||``, and ``!``.  The alternative tokens are not available
-  by default on all compilers, and also we want to maintain a consistent
-  programming style.
+  by default on all compilers.
 
-- Output to the screen and the logfile should be using the corresponding
-  FILE pointers and only be done on MPI rank 0.  Use the :cpp:func:`utils::logmesg`
-  convenience function where possible.
+- Output to the screen and the logfile should use the corresponding
+  FILE pointers and only be done on MPI rank 0.  Use the
+  :cpp:func:`utils::logmesg` convenience function where possible.
 
-- Usage of C++11 `virtual`, `override`, `final` keywords: Please follow the
-  `C++ Core Guideline C.128 <https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rh-override>`_.
+- Usage of C++11 `virtual`, `override`, `final` keywords: Please
+  follow the `C++ Core Guideline C.128
+  <https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rh-override>`_.
   That means, you should only use `virtual` to declare a new virtual
-  function, `override` to indicate you are overriding an existing virtual
-  function, and `final` to prevent any further overriding.
+  function, `override` to indicate you are overriding an existing
+  virtual function, and `final` to prevent any further overriding.
 
-- Trivial destructors: Prefer not writing destructors when they are empty and `default`.
+- Trivial destructors: Do not write destructors when they are empty
+  and `default`.
 
   .. code-block:: c++
 
      // don't write destructors for A or B like this
+
      class A : protected Pointers {
       public:
         A();
@@ -393,6 +137,7 @@ you are uncertain, please ask.
      };
 
      // instead, let the compiler create the implicit default destructor by not writing it
+
      class A : protected Pointers {
       public:
         A();
@@ -403,37 +148,11 @@ you are uncertain, please ask.
         B();
      };
 
-- Header files, especially those defining a "style", should only use
-  the absolute minimum number of include files and **must not** contain
-  any ``using`` statements. Typically that would be only the header for
-  the base class. Instead any include statements should be put into the
-  corresponding implementation files and forward declarations be used.
-  For implementation files, the "include what you use" principle should
-  be employed.  However, there is the notable exception that when the
-  ``pointers.h`` header is included (or one of the base classes derived
-  from it) certain headers will always be included and thus do not need
-  to be explicitly specified.
-  These are: `mpi.h`, `cstddef`, `cstdio`, `cstdlib`, `string`, `utils.h`,
-  `vector`, `fmt/format.h`, `climits`, `cinttypes`.
-  This also means any such file can assume that `FILE`, `NULL`, and
-  `INT_MAX` are defined.
-
-- Header files that define a new LAMMPS style (i.e. that have a
-  ``SomeStyle(some/name,SomeName);`` macro in them) should only use the
-  include file for the base class and otherwise use forward declarations
-  and pointers; when interfacing to a library use the PIMPL (pointer
-  to implementation) approach where you have a pointer to a struct
-  that contains all library specific data (and thus requires the library
-  header) but use a forward declaration and define the struct only in
-  the implementation file. This is a **strict** requirement since this
-  is where type clashes between packages and hard to find bugs have
-  regularly manifested in the past.
-
 - Please use clang-format only to reformat files that you have
   contributed.  For header files containing a ``SomeStyle(keyword,
-  ClassName)`` macros it is required to have this macro embedded with a
-  pair of ``// clang-format off``, ``// clang-format on`` commends and
-  the line must be terminated with a semi-colon (;).  Example:
+  ClassName)`` macros it is required to have this macro embedded with
+  a pair of ``// clang-format off``, ``// clang-format on`` comments
+  and the line must be terminated with a semicolon (;).  Example:
 
   .. code-block:: c++
 
@@ -446,92 +165,10 @@ you are uncertain, please ask.
      #ifndef LMP_RUN_H
      [...]
 
-  You may also use ``// clang-format on/off`` throughout your files
-  to protect individual sections from being reformatted.
+  You may also use ``// clang-format on/off`` throughout your files to
+  protect individual sections from being reformatted.
 
-- We rarely accept new styles in the core src folder.  Thus please
-  review the list of :doc:`available Packages <Packages_details>` to see
-  if your contribution could be added to be added to one of them.  It
-  should fit into the general purposed of that package.  If it does not
-  fit well, it may be added to one of the EXTRA- packages or the MISC
-  package.
-
-
-Contributing a package
-----------------------
-
-If your contribution has several related features that are not covered
-by one of the existing packages or is dependent on a library (bundled or
-external), it is best to make it a package directory with a name like
-FOO.  In addition to your new files, the directory should contain a
-README text file.  The README should contain your name and contact
-information and a brief description of what your new package does.
-
-
-Build system (strongly preferred)
----------------------------------
-
-LAMMPS currently supports two build systems: one that is based on
-:doc:`traditional Makefiles <Build_make>` and one that is based on
-:doc:`CMake <Build_cmake>`.  Thus your contribution must be compatible
-with and support both.
-
-For a single pair of header and implementation files that are an
-independent feature, it is usually only required to add them to
-`src/.gitignore``.
-
-For traditional make, if your contributed files or package depend on
-other LAMMPS style files or packages also being installed (e.g. because
-your file is a derived class from the other LAMMPS class), then an
-Install.sh file is also needed to check for those dependencies and
-modifications to src/Depend.sh to trigger the checks.  See other README
-and Install.sh files in other directories as examples.
-
-Similarly for CMake support, changes may need to be made to
-cmake/CMakeLists.txt, some of the files in cmake/presets, and possibly a
-file with specific instructions needs to be added to
-cmake/Modules/Packages/.  Please check out how this is handled for
-existing packages and ask the LAMMPS developers if you need assistance.
-
-
-Citation reminder (suggested)
------------------------------
-
-If there is a paper of yours describing your feature (either the
-algorithm/science behind the feature itself, or its initial usage, or
-its implementation in LAMMPS), you can add the citation to the \*.cpp
-source file.  See ``src/DIFFRACTION/compute_saed.cpp`` for an example.
-A BibTeX format citation is stored in a string variable at the top
-of the file and  a single line of code registering this variable is
-added to the constructor of the class.  When your feature is used,
-by default, LAMMPS will print the brief info and the DOI
-in the first line to the screen and the full citation to the log file.
-
-If there is additional functionality (which may have been added later)
-described in a different publication, additional citation descriptions
-may be added for as long as they are only registered when the
-corresponding keyword activating this functionality is used.  With these
-options it is possible to have LAMMPS output a specific citation
-reminder whenever a user invokes your feature from their input script.
-Please note that you should *only* use this for the *most* relevant
-paper for a feature and a publication that you or your group authored.
-E.g. adding a citation in the code for a paper by Nose and Hoover if you
-write a fix that implements their integrator is not the intended usage.
-That latter kind of citation should just be included in the
-documentation page you provide describing your contribution.  If you are
-not sure what the best option would be, please contact the LAMMPS
-developers for advice.
-
-
-Testing (optional)
-------------------
-
-If your contribution contains new utility functions or a supporting class
-(i.e. anything that does not depend on a LAMMPS object), new unit tests
-should be added to a suitable folder in the ``unittest`` tree.
-When adding a new LAMMPS style computing forces or selected fixes,
-a ``.yaml`` file with a test configuration and reference data should be
-added for the styles where a suitable tester program already exists
-(e.g. pair styles, bond styles, etc.). Please see
-:ref:`this section in the manual <testing>` for more information on
-how to enable, run, and expand testing.
+- All files should have 0644 permissions, i.e. writable by the user
+  only and readable by all and no executable permissions.  Executable
+  permissions (0755) should only be for shell scripts or python or
+  similar scripts for interpreted script languages.

doc/src/Packages_details.rst

@@ -67,7 +67,6 @@ page gives those details.
    * :ref:`KOKKOS <PKG-KOKKOS>`
    * :ref:`KSPACE <PKG-KSPACE>`
    * :ref:`LATBOLTZ <PKG-LATBOLTZ>`
-   * :ref:`LATTE <PKG-LATTE>`
    * :ref:`LEPTON <PKG-LEPTON>`
    * :ref:`MACHDYN <PKG-MACHDYN>`
    * :ref:`MANIFOLD <PKG-MANIFOLD>`
@@ -228,8 +227,9 @@ conversion of atomic information to continuum fields.
 
 **Install:**
 
-This package has :ref:`specific installation instructions <atc>` on the :doc:`Build extras <Build_extras>` page.
-The ATC package requires that also the `MANYBODY <PKG-MANYBODY>`_ package is installed.
+This package has :ref:`specific installation instructions <atc>` on the
+:doc:`Build extras <Build_extras>` page.  The ATC package requires that
+also the :ref:`MANYBODY <PKG-MANYBODY>` package is installed.
 
 **Supporting info:**
 
@@ -391,8 +391,8 @@ rigid-body integrators with improved stability.
 
 **Install:**
 
-The CG-DNA package requires that also the `MOLECULE <PKG-MOLECULE>`_ and
-`ASPHERE <PKG-ASPHERE>`_ packages are installed.
+The CG-DNA package requires that also the :ref:`MOLECULE <PKG-MOLECULE>`
+and :ref:`ASPHERE <PKG-ASPHERE>` packages are installed.
 
 **Supporting info:**
 
@@ -1114,15 +1114,15 @@ INTEL package
 
 **Contents:**
 
-Dozens of pair, fix, bond, angle, dihedral, improper, and kspace
-styles which are optimized for Intel CPUs and KNLs (Knights Landing).
-All of them have an "intel" in their style name.  The
-:doc:`INTEL package <Speed_intel>` page gives details of what hardware and
-compilers are required on your system, and how to build and use this
-package.  Its styles can be invoked at run time via the "-sf intel" or
-"-suffix intel" :doc:`command-line switches <Run_options>`.  Also see
-the :ref:`KOKKOS <PKG-KOKKOS>`, :ref:`OPT <PKG-OPT>`, and :ref:`OPENMP <PKG-OPENMP>` packages,
-which have styles optimized for CPUs and KNLs.
+Dozens of pair, fix, bond, angle, dihedral, improper, and kspace styles
+which are optimized for Intel CPUs and KNLs (Knights Landing).  All of
+them have an "intel" in their style name.  The :doc:`INTEL package
+<Speed_intel>` page gives details of what hardware and compilers are
+required on your system, and how to build and use this package.  Its
+styles can be invoked at run time via the "-sf intel" or "-suffix intel"
+:doc:`command-line switches <Run_options>`.  Also see the :ref:`KOKKOS
+<PKG-KOKKOS>`, :ref:`OPT <PKG-OPT>`, and :ref:`OPENMP <PKG-OPENMP>`
+packages, which have styles optimized for CPUs and KNLs.
 
 You need to have an Intel compiler, version 14 or higher to take full
 advantage of this package. While compilation with GNU compilers is
@@ -1249,12 +1249,13 @@ Dozens of atom, pair, bond, angle, dihedral, improper, fix, compute
 styles adapted to compile using the Kokkos library which can convert
 them to OpenMP or CUDA code so that they run efficiently on multicore
 CPUs, KNLs, or GPUs.  All the styles have a "kk" as a suffix in their
-style name.  The :doc:`KOKKOS package <Speed_kokkos>` page gives
-details of what hardware and software is required on your system, and
-how to build and use this package.  Its styles can be invoked at run
-time via the "-sf kk" or "-suffix kk" :doc:`command-line switches <Run_options>`.  Also see the :ref:`GPU <PKG-GPU>`, :ref:`OPT <PKG-OPT>`,
-:ref:`INTEL <PKG-INTEL>`, and :ref:`OPENMP <PKG-OPENMP>` packages, which
-have styles optimized for CPUs, KNLs, and GPUs.
+style name.  The :doc:`KOKKOS package <Speed_kokkos>` page gives details
+of what hardware and software is required on your system, and how to
+build and use this package.  Its styles can be invoked at run time via
+the "-sf kk" or "-suffix kk" :doc:`command-line switches <Run_options>`.
+Also see the :ref:`GPU <PKG-GPU>`, :ref:`OPT <PKG-OPT>`, :ref:`INTEL
+<PKG-INTEL>`, and :ref:`OPENMP <PKG-OPENMP>` packages, which have styles
+optimized for CPUs, KNLs, and GPUs.
 
 You must have a C++14 compatible compiler to use this package.
 KOKKOS makes extensive use of advanced C++ features, which can
@@ -1355,43 +1356,6 @@ The LATBOLTZ package requires that LAMMPS is build in :ref:`MPI parallel mode <s
 
 ----------
 
-.. _PKG-LATTE:
-
-LATTE package
--------------
-
-**Contents:**
-
-A fix command which wraps the LATTE DFTB code, so that molecular
-dynamics can be run with LAMMPS using density-functional tight-binding
-quantum forces calculated by LATTE.
-
-More information on LATTE can be found at this website:
-`https://github.com/lanl/LATTE <latte-home_>`_.  A brief technical
-description is given with the :doc:`fix latte <fix_latte>` command.
-
-.. _latte-home: https://github.com/lanl/LATTE
-
-**Authors:** Christian Negre (LANL) and Steve Plimpton (Sandia).  LATTE
-itself is developed at Los Alamos National Laboratory by Marc
-Cawkwell, Anders Niklasson, and Christian Negre.
-
-**Install:**
-
-This package has :ref:`specific installation instructions <latte>` on
-the :doc:`Build extras <Build_extras>` page.
-
-**Supporting info:**
-
-* src/LATTE: filenames -> commands
-* src/LATTE/README
-* lib/latte/README
-* :doc:`fix latte <fix_latte>`
-* examples/latte
-* `LAMMPS-LATTE tutorial <https://github.com/lanl/LATTE/wiki/Using-LATTE-through-LAMMPS>`_
-
-----------
-
 .. _PKG-LEPTON:
 
 LEPTON package
@@ -2328,7 +2292,7 @@ and third order tensor from finite differences.
 
 **Install:**
 
-The PHONON package requires that also the `KSPACE <PKG-KSPACE>`_
+The PHONON package requires that also the :ref:`KSPACE <PKG-KSPACE>`
 package is installed.
 
 
@@ -2929,11 +2893,9 @@ VORONOI package
 **Contents:**
 
 A compute command which calculates the Voronoi tesselation of a
-collection of atoms by wrapping the `Voro++ library <voro-home_>`_.  This
-can be used to calculate the local volume or each atoms or its near
-neighbors.
-
-.. _voro-home: https://math.lbl.gov/voro++
+collection of atoms by wrapping the `Voro++ library
+<https://math.lbl.gov/voro++/>`_.  This can be used to calculate the
+local volume or each atoms or its near neighbors.
 
 To use this package you must have the Voro++ library available on your
 system.

doc/src/Packages_list.rst

@@ -233,11 +233,6 @@ whether an extra library is needed to build and use the package:
      - :doc:`fix lb/fluid <fix_lb_fluid>`
      - PACKAGES/latboltz
      - no
-   * - :ref:`LATTE <PKG-LATTE>`
-     - quantum DFTB forces via LATTE
-     - :doc:`fix latte <fix_latte>`
-     - latte
-     - ext
    * - :ref:`LEPTON <PKG-LEPTON>`
      - evaluate strings as potential function
      - :doc:`pair_style lepton <pair_lepton>`

doc/src/Python_install.rst

@@ -15,9 +15,6 @@ Two components are necessary for Python to be able to invoke LAMMPS code:
   ``liblammps.dll``) from the folder where you compiled LAMMPS.
 
 .. _ctypes: https://docs.python.org/3/library/ctypes.html
-.. _python_virtualenv: https://packaging.python.org/guides/installing-using-pip-and-virtual-environments/#creating-a-virtual-environment
-.. _python_venv: https://docs.python.org/3/library/venv.html
-.. _python_pep405: https://www.python.org/dev/peps/pep-0405
 
 .. _python_install_guides:
 
@@ -30,140 +27,36 @@ interpreter can find it and installing the LAMMPS shared library into a
 folder that the dynamic loader searches or inside of the installed
 ``lammps`` package folder.  There are multiple ways to achieve this.
 
-#. Do a full LAMMPS installation of libraries, executables, selected
-   headers, documentation (if enabled), and supporting files (only
-   available via CMake), which can also be either system-wide or into
-   user specific folders.
-
 #. Install both components into a Python ``site-packages`` folder, either
    system-wide or in the corresponding user-specific folder. This way no
    additional environment variables need to be set, but the shared
    library is otherwise not accessible.
 
-#. Do an installation into a virtual environment. This can either be an
-   installation of the Python package only or a full installation of LAMMPS.
+#. Do an installation into a virtual environment.
 
 #. Leave the files where they are in the source/development tree and
    adjust some environment variables.
 
 .. tabs::
 
-   .. tab:: Full install (CMake-only)
-
-      :ref:`Build the LAMMPS executable and library <library>` with
-      ``-DBUILD_SHARED_LIBS=on``, ``-DLAMMPS_EXCEPTIONS=on`` and
-      ``-DPKG_PYTHON=on`` (The first option is required, the other two
-      are optional by recommended).  The exact file name of the shared
-      library depends on the platform (Unix/Linux, macOS, Windows) and
-      the build configuration being used.  The installation base folder
-      is already set by default to the ``$HOME/.local`` directory, but
-      it can be changed to a custom location defined by the
-      ``CMAKE_INSTALL_PREFIX`` CMake variable.  This uses a folder
-      called ``build`` to store files generated during compilation.
-
-      .. code-block:: bash
-
-         # create build folder
-         mkdir build
-         cd build
-
-         # configure LAMMPS compilation
-         cmake -C ../cmake/presets/basic.cmake -D BUILD_SHARED_LIBS=on \
-               -D LAMMPS_EXCEPTIONS=on -D PKG_PYTHON=on ../cmake
-
-         # compile LAMMPS
-         cmake --build .
-
-         # install LAMMPS into $HOME/.local
-         cmake --install .
-
-
-      This leads to an installation to the following locations:
-
-      +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
-      | File                   | Location                                                        | Notes                                                       |
-      +========================+=================================================================+=============================================================+
-      | LAMMPS Python package  | * ``$HOME/.local/lib/pythonX.Y/site-packages/lammps`` (32bit)   | ``X.Y`` depends on the installed Python version             |
-      |                        | * ``$HOME/.local/lib64/pythonX.Y/site-packages/lammps`` (64bit) |                                                             |
-      +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
-      | LAMMPS shared library  | * ``$HOME/.local/lib/`` (32bit)                                 | Set shared loader environment variable to this path         |
-      |                        | * ``$HOME/.local/lib64/`` (64bit)                               | (see below for more info on this)                           |
-      +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
-      | LAMMPS executable      | * ``$HOME/.local/bin/``                                         |                                                             |
-      +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
-      | LAMMPS potential files | * ``$HOME/.local/share/lammps/potentials/``                     | Set ``LAMMPS_POTENTIALS`` environment variable to this path |
-      +------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
-
-      For a system-wide installation you need to set
-      ``CMAKE_INSTALL_PREFIX`` to a system folder like ``/usr`` (or
-      ``/usr/local``); the default is ``${HOME}/.local``.  The
-      installation step for a system folder installation (**not** the
-      configuration/compilation) needs to be done with superuser
-      privilege, e.g. by using ``sudo cmake --install .``.  The
-      installation folders will then be changed to (assuming ``/usr`` as
-      prefix):
-
-      +------------------------+---------------------------------------------------------+-------------------------------------------------------------+
-      | File                   | Location                                                | Notes                                                       |
-      +========================+=========================================================+=============================================================+
-      | LAMMPS Python package  | * ``/usr/lib/pythonX.Y/site-packages/lammps`` (32bit)   | ``X.Y`` depends on the installed Python version             |
-      |                        | * ``/usr/lib64/pythonX.Y/site-packages/lammps`` (64bit) |                                                             |
-      +------------------------+---------------------------------------------------------+-------------------------------------------------------------+
-      | LAMMPS shared library  | * ``/usr/lib/`` (32bit)                                 |                                                             |
-      |                        | * ``/usr/lib64/`` (64bit)                               |                                                             |
-      +------------------------+---------------------------------------------------------+-------------------------------------------------------------+
-      | LAMMPS executable      | * ``/usr/bin/``                                         |                                                             |
-      +------------------------+---------------------------------------------------------+-------------------------------------------------------------+
-      | LAMMPS potential files | * ``/usr/share/lammps/potentials/``                     |                                                             |
-      +------------------------+---------------------------------------------------------+-------------------------------------------------------------+
-
-      To be able to use the "user" installation you have to ensure that
-      the folder containing the LAMMPS shared library is either included
-      in a path searched by the shared linker (e.g. like
-      ``/usr/lib64/``) or part of the ``LD_LIBRARY_PATH`` environment
-      variable (or ``DYLD_LIBRARY_PATH`` on macOS).  Otherwise you will
-      get an error when trying to create a LAMMPS object through the
-      Python module.
-
-      .. code-block:: bash
-
-         # Unix/Linux
-         export LD_LIBRARY_PATH=$HOME/.local/lib:$LD_LIBRARY_PATH
-
-         # macOS
-         export DYLD_LIBRARY_PATH=$HOME/.local/lib:$DYLD_LIBRARY_PATH
-
-      If you plan to use the LAMMPS executable (e.g., ``lmp``), you may
-      also need to adjust the ``PATH`` environment variable (but many
-      newer Linux distributions already have ``$HOME/.local/bin``
-      included). Example:
-
-      .. code-block:: bash
-
-         export PATH=$HOME/.local/bin:$PATH
-
-      To make those changes permanent, you can add the commands to your
-      ``$HOME/.bashrc`` file.  For a system-wide installation is is not
-      necessary due to files installed in system folders that are loaded
-      automatically when a login shell is started.
-
-   .. tab:: Python package only
+   .. tab:: Python package
 
       Compile LAMMPS with either :doc:`CMake <Build_cmake>` or the
       :doc:`traditional make <Build_make>` procedure in :ref:`shared
-      mode <exe>`.  After compilation has finished type (in the
+      mode <exe>`.  After compilation has finished, type (in the
       compilation folder):
 
       .. code-block:: bash
 
          make install-python
 
-      This will try to build a so-called (binary) 'wheel', a compressed
-      binary python package and then install it with the python package
-      manager 'pip'.  Installation will be attempted into a system-wide
-      ``site-packages`` folder and if that fails into the corresponding
-      folder in the user's home directory.  For a system-wide installation you
-      would have to gain superuser privilege, e.g. though ``sudo``
+      This will try to build a so-called (binary) wheel file, a
+      compressed binary python package and then install it with the
+      python package manager 'pip'.  Installation will be attempted into
+      a system-wide ``site-packages`` folder and if that fails into the
+      corresponding folder in the user's home directory.  For a
+      system-wide installation you usually would have to gain superuser
+      privilege first, e.g. though ``sudo``
 
       +------------------------+----------------------------------------------------------+-------------------------------------------------------------+
       | File                   | Location                                                 | Notes                                                       |
@@ -214,10 +107,11 @@ folder that the dynamic loader searches or inside of the installed
 
       .. code-block:: bash
 
-         python install.py -p <python package> -l <shared library> [-n]
+         python install.py -p <python package> -l <shared library> -v <version.h file> [-n]
 
       * The ``-p`` flag points to the ``lammps`` Python package folder to be installed,
       * the ``-l`` flag points to the LAMMPS shared library file to be installed,
+      * the ``-v`` flag points to the LAMMPS version header file to extract the version date,
       * and the optional ``-n`` instructs the script to only build a wheel file
         but not attempt to install it.
 
@@ -232,11 +126,11 @@ folder that the dynamic loader searches or inside of the installed
       install (newer/different) versions of Python packages that would
       potentially conflict with already installed system packages.  It
       also does not requite any superuser privileges. See `PEP 405:
-      Python Virtual Environments <python_pep405>`_ for more
+      Python Virtual Environments <https://peps.python.org/pep-0405/>`_ for more
       information.
 
       To create a virtual environment in the folder ``$HOME/myenv``,
-      use the `venv <python_venv>`_ module as follows.
+      use the `venv <https://docs.python.org/3/library/venv.html>`_ module as follows.
 
       .. code-block:: bash
 
@@ -244,8 +138,9 @@ folder that the dynamic loader searches or inside of the installed
          python3 -m venv $HOME/myenv
 
       For Python versions prior 3.3 you can use `virtualenv
-      <python_virtualenv>`_ command instead of "python3 -m venv".  This
-      step has to be done only once.
+      <https://packaging.python.org/en/latest/key_projects/#virtualenv>`_
+      command instead of "python3 -m venv".  This step has to be done
+      only once.
 
       To activate the virtual environment type:
 
@@ -274,38 +169,6 @@ folder that the dynamic loader searches or inside of the installed
       | LAMMPS shared library  | * ``$VIRTUAL_ENV/lib/pythonX.Y/site-packages/lammps``  | ``X.Y`` depends on the installed Python version             |
       +------------------------+--------------------------------------------------------+-------------------------------------------------------------+
 
-      If you do a full installation (CMake only) with "install", this
-      leads to the following installation locations:
-
-      +------------------------+--------------------------------------------------------+-------------------------------------------------------------+
-      | File                   | Location                                               | Notes                                                       |
-      +========================+========================================================+=============================================================+
-      | LAMMPS Python Module   | * ``$VIRTUAL_ENV/lib/pythonX.Y/site-packages/lammps``  | ``X.Y`` depends on the installed Python version             |
-      +------------------------+--------------------------------------------------------+-------------------------------------------------------------+
-      | LAMMPS shared library  | * ``$VIRTUAL_ENV/lib/`` (32bit)                        | Set shared loader environment variable to this path         |
-      |                        | * ``$VIRTUAL_ENV/lib64/`` (64bit)                      | (see below for more info on this)                           |
-      +------------------------+--------------------------------------------------------+-------------------------------------------------------------+
-      | LAMMPS executable      | * ``$VIRTUAL_ENV/bin/``                                |                                                             |
-      +------------------------+--------------------------------------------------------+-------------------------------------------------------------+
-      | LAMMPS potential files | * ``$VIRTUAL_ENV/share/lammps/potentials/``            | Set ``LAMMPS_POTENTIALS`` environment variable to this path |
-      +------------------------+--------------------------------------------------------+-------------------------------------------------------------+
-
-      In that case you need to modify the ``$HOME/myenv/bin/activate``
-      script in a similar fashion you need to update your
-      ``$HOME/.bashrc`` file to include the shared library and
-      executable locations in ``LD_LIBRARY_PATH`` (or
-      ``DYLD_LIBRARY_PATH`` on macOS) and ``PATH``, respectively.
-
-      For example with:
-
-      .. code-block:: bash
-
-         # Unix/Linux
-         echo 'export LD_LIBRARY_PATH=$VIRTUAL_ENV/lib:$LD_LIBRARY_PATH' >> $HOME/myenv/bin/activate
-
-         # macOS
-         echo 'export DYLD_LIBRARY_PATH=$VIRTUAL_ENV/lib:$DYLD_LIBRARY_PATH' >> $HOME/myenv/bin/activate
-
    .. tab:: In place usage
 
       You can also :doc:`compile LAMMPS <Build>` as usual in
@@ -414,10 +277,8 @@ follows:
 
      sudo pip install mpi4py
 
-.. _mpi4py_install: https://mpi4py.readthedocs.io/en/stable/install.html
-
 For more detailed installation instructions and additional options,
-please see the `mpi4py installation <mpi4py_install>`_ page.
+please see the `mpi4py installation <https://mpi4py.readthedocs.io/en/stable/install.html>`_ page.
 
 
 To use ``mpi4py`` and LAMMPS in parallel from Python, you **must** make

doc/src/Python_properties.rst

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

doc/src/Speed_kokkos.rst

@@ -285,6 +285,16 @@ one or more nodes, each with two GPUs:
    settings. Experimenting with its options can provide a speed-up for
    specific calculations. For example:
 
+.. note::
+
+   The default binsize for :doc:`atom sorting <atom_modify>` on GPUs
+   is equal to the default CPU neighbor binsize (i.e. 2x smaller than the
+   default GPU neighbor binsize). When running simple pair-wise
+   potentials like Lennard Jones on GPUs, using a 2x larger binsize for
+   atom sorting (equal to the default GPU neighbor binsize) and a more
+   frequent sorting than default (e.g. sorting every 100 time steps
+   instead of 1000) may improve performance.
+
 .. code-block:: bash
 
    mpirun -np 2 lmp_kokkos_cuda_openmpi -k on g 2 -sf kk -pk kokkos newton on neigh half binsize 2.8 -in in.lj      # Newton on, half neighbor list, set binsize = neighbor ghost cutoff

doc/src/Tools.rst

@@ -320,7 +320,8 @@ eam generate tool
 -----------------------------
 
 The tools/eam_generate directory contains several one-file C programs
-that convert an analytic formula into a tabulated :doc:`embedded atom method (EAM) <pair_eam>` setfl potential file.  The potentials they
+that convert an analytic formula into a tabulated :doc:`embedded atom
+method (EAM) <pair_eam>` setfl potential file.  The potentials they
 produce are in the potentials directory, and can be used with the
 :doc:`pair_style eam/alloy <pair_eam>` command.
 
@@ -882,9 +883,9 @@ dependencies and redirects the download to the local cache.
 phonon tool
 ------------------------
 
-The phonon subdirectory contains a post-processing tool useful for
-analyzing the output of the :doc:`fix phonon <fix_phonon>` command in
-the PHONON package.
+The phonon subdirectory contains a post-processing tool, *phana*, useful
+for analyzing the output of the :doc:`fix phonon <fix_phonon>` command
+in the PHONON package.
 
 See the README file for instruction on building the tool and what
 library it needs.  And see the examples/PACKAGES/phonon directory

doc/src/angle_dipole.rst

@@ -28,15 +28,15 @@ The *dipole* angle style is used to control the orientation of a dipolar
 atom within a molecule :ref:`(Orsi) <Orsi>`. Specifically, the *dipole* angle
 style restrains the orientation of a point dipole :math:`\mu_j` (embedded in atom
 :math:`j`) with respect to a reference (bond) vector
-:math:`\vec{r_{ij}} = \vec{r_i} - \vec{r_j}`, where :math:`i` is another atom of
+:math:`\vec{r}_{ij} = \vec{r}_i - \vec{r}_j`, where :math:`i` is another atom of
 the same molecule (typically, :math:`i` and :math:`j` are also covalently bonded).
 
-It is convenient to define an angle gamma between the 'free' vector :math:`\vec{\mu_j}`
-and the reference (bond) vector :math:`\vec{r_{ij}}`:
+It is convenient to define an angle gamma between the 'free' vector :math:`\vec{\mu}_j`
+and the reference (bond) vector :math:`\vec{r}_{ij}`:
 
 .. math::
 
-   \cos\gamma = \frac{\vec{\mu_j}\cdot\vec{r_{ij}}}{\mu_j\,r_{ij}}
+   \cos\gamma = \frac{\vec{\mu}_j\cdot\vec{r}_{ij}}{\mu_j\,r_{ij}}
 
 The *dipole* angle style uses the potential:
 
@@ -53,23 +53,23 @@ potential using the 'chain rule' as in appendix C.3 of
 
 .. math::
 
-   \vec{T_j} = \frac{2K(\cos\gamma - \cos\gamma_0)}{\mu_j\,r_{ij}}\, \vec{r_{ij}} \times \vec{\mu_j}
+   \vec{T}_j = \frac{2K(\cos\gamma - \cos\gamma_0)}{\mu_j\,r_{ij}}\, \vec{r}_{ij} \times \vec{\mu}_j
 
 Example: if :math:`\gamma_0` is set to 0 degrees, the torque generated by
 the potential will tend to align the dipole along the reference
-direction defined by the (bond) vector :math:`\vec{r_{ij}}` (in other words, :math:`\vec{\mu_j}` is
+direction defined by the (bond) vector :math:`\vec{r}_{ij}` (in other words, :math:`\vec{\mu}_j` is
 restrained to point towards atom :math:`i`).
 
-The dipolar torque :math:`\vec{T_j}` must be counterbalanced in order to conserve
+The dipolar torque :math:`\vec{T}_j` must be counterbalanced in order to conserve
 the local angular momentum. This is achieved via an additional force
-couple generating a torque equivalent to the opposite of :math:`\vec{T_j}`:
+couple generating a torque equivalent to the opposite of :math:`\vec{T}_j`:
 
 .. math::
 
-   -\vec{T_j} & = \vec{r_{ij}} \times \vec{F_i} \\
-   \vec{F_j}  & = -\vec{F_i}
+   -\vec{T}_j & = \vec{r}_{ij} \times \vec{F}_i \\
+   \vec{F}_j  & = -\vec{F}_i
 
-where :math:`\vec{F_i}` and :math:`\vec{F_j}` are applied on atoms :math:`i`
+where :math:`\vec{F}_i` and :math:`\vec{F}_j` are applied on atoms :math:`i`
 and :math:`j`, respectively.
 
 The following coefficients must be defined for each angle type via the

doc/src/atom_modify.rst

@@ -153,6 +153,13 @@ cache locality will be undermined.
    order of atoms in a :doc:`dump <dump>` file will also typically change
    if sorting is enabled.
 
+.. note::
+
+   When running simple pair-wise potentials like Lennard Jones on GPUs
+   with the KOKKOS package, using a larger binsize (e.g. 2x larger than
+   default) and a more frequent reordering than default (e.g. every 100
+   time steps) may improve performance.
+
 Restrictions
 """"""""""""
 

doc/src/atom_style.rst

@@ -161,15 +161,14 @@ and each stores a per-particle diameter and mass.  If the diameter >
 0.0, the particle is a finite-size sphere.  If the diameter = 0.0, it
 is a point particle.  Note that by use of the *disc* keyword with 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 for the *sphere* style, spheres
-can be effectively treated as 2d discs for a 2d simulation if desired.
-See also the :doc:`set density/disc <set>` command.  The *sphere* and
-*bpm/sphere* styles take an optional 0 or 1 argument.  A value of 0
-means the radius of each sphere is constant for the duration of the
-simulation.  A value of 1 means the radii may vary dynamically during
-the simulation, e.g. due to use of the :doc:`fix adapt <fix_adapt>`
-command.
+<fix_nvt_sphere>`, :doc:`fix nph/sphere <fix_nph_sphere>`,
+:doc:`fix npt/sphere <fix_npt_sphere>` commands for the *sphere* style,
+spheres can be effectively treated as 2d discs for a 2d simulation if
+desired.  See also the :doc:`set density/disc <set>` command.  These
+styles take an optional 0 or 1 argument.  A value of 0 means the
+radius of each sphere is constant for the duration of the simulation.
+A value of 1 means the radii may vary dynamically during the simulation,
+e.g. due to use of the :doc:`fix adapt <fix_adapt>` command.
 
 For the *ellipsoid* style, the particles are ellipsoids and each
 stores a flag which indicates whether it is a finite-size ellipsoid or

doc/src/balance.rst

@@ -53,6 +53,7 @@ Syntax
              name = name of the atom-style variable
            *store* name = store weight in custom atom property defined by :doc:`fix property/atom <fix_property_atom>` command
              name = atom property name (without d\_ prefix)
+       *sort* arg = *no* or *yes*
        *out* arg = filename
          filename = write each processor's subdomain to a file
 
@@ -492,6 +493,14 @@ different kinds of custom atom vectors or arrays as arguments.
 
 ----------
 
+The *sort* keyword determines whether the communication of per-atom
+data to other processors during load-balancing will be random or
+deterministic.  Random is generally faster; deterministic will ensure
+the new ordering of atoms on each processor is the same each time the
+same simulation is run.  This can be useful for debugging purposes.
+Since the balance command is a one-time operation, the default is
+*yes* to perform sorting.
+
 The *out* keyword writes a text file to the specified *filename* with
 the results of the balancing operation.  The file contains the bounds
 of the subdomain for each processor after the balancing operation
@@ -569,4 +578,5 @@ Related commands
 Default
 """""""
 
-none
+The default setting is sort = yes.
+

doc/src/bond_bpm_rotational.rst

@@ -10,7 +10,7 @@ Syntax
 
    bond_style bpm/rotational keyword value attribute1 attribute2 ...
 
-* optional keyword = *overlay/pair* or *store/local* or *smooth*
+* optional keyword = *overlay/pair* or *store/local* or *smooth* or *break/no*
 
   .. parsed-literal::
 
@@ -24,12 +24,18 @@ Syntax
             *x, y, z* = the center of mass position of the 2 atoms when the bond broke (distance units)
             *x/ref, y/ref, z/ref* = the initial center of mass position of the 2 atoms (distance units)
 
-       *overlay/pair* value = none
+       *overlay/pair* value = *yes* or *no*
           bonded particles will still interact with pair forces
 
        *smooth* value = *yes* or *no*
           smooths bond forces near the breaking point
 
+       *normalize* value = *yes* or *no*
+          normalizes normal and shear forces by the reference length
+
+       *break* value = *yes* or *no*
+          indicates whether bonds break during a run
+
 Examples
 """"""""
 
@@ -133,13 +139,22 @@ or :doc:`read_restart <read_restart>` commands:
 * :math:`\gamma_r`      (force*distance/velocity units)
 * :math:`\gamma_t`      (force*distance/velocity units)
 
+However, the *normalize* option will normalize the radial and shear forces
+by :math:`r_0` such that :math:`k_r` and :math:`k_s` are unit less.
+
 By default, pair forces are not calculated between bonded particles.
 Pair forces can alternatively be overlaid on top of bond forces using
-the *overlay/pair* keyword. These settings require specific
+the *overlay/pair* option. These settings require specific
 :doc:`special_bonds <special_bonds>` settings described in the
 restrictions.  Further details can be found in the `:doc: how to
 <Howto_BPM>` page on BPMs.
 
+.. versionadded:: 28Mar2023
+
+If the *break* option is used, then LAMMPS assumes bonds should not break
+during a simulation run. This will prevent some unnecessary calculation.
+However, if a bond does break, it will trigger an error.
+
 If the *store/local* keyword is used, an internal fix will track bonds that
 break during the simulation. Whenever a bond breaks, data is processed
 and transferred to an internal fix labeled *fix_ID*. This allows the
@@ -242,7 +257,7 @@ Related commands
 Default
 """""""
 
-The option defaults are *smooth* = *yes*
+The option defaults are *overlay/pair* = *no*, *smooth* = *yes*, *normalize* = *no*, and *break* = *yes*
 
 ----------
 

doc/src/bond_bpm_spring.rst

@@ -10,7 +10,7 @@ Syntax
 
    bond_style bpm/spring keyword value attribute1 attribute2 ...
 
-* optional keyword = *overlay/pair* or *store/local* or *smooth*
+* optional keyword = *overlay/pair* or *store/local* or *smooth* or *break/no*
 
   .. parsed-literal::
 
@@ -24,12 +24,18 @@ Syntax
             *x, y, z* = the center of mass position of the 2 atoms when the bond broke (distance units)
             *x/ref, y/ref, z/ref* = the initial center of mass position of the 2 atoms (distance units)
 
-       *overlay/pair* value = none
+       *overlay/pair* value = *yes* or *no*
           bonded particles will still interact with pair forces
 
        *smooth* value = *yes* or *no*
           smooths bond forces near the breaking point
 
+       *normalize* value = *yes* or *no*
+          normalizes bond forces by the reference length
+
+       *break* value = *yes* or *no*
+          indicates whether bonds break during a run
+
 Examples
 """"""""
 
@@ -47,7 +53,7 @@ Description
 
 .. versionadded:: 4May2022
 
-The *bpm/spring* bond style computes forces and torques based on
+The *bpm/spring* bond style computes forces based on
 deviations from the initial reference state of the two atoms.  The
 reference state is stored by each bond when it is first computed in
 the setup of a run. Data is then preserved across run commands and is
@@ -56,13 +62,14 @@ the system will not reset the reference state of a bond.
 
 This bond style only applies central-body forces which conserve the
 translational and rotational degrees of freedom of a bonded set of
-particles. The force has a magnitude of
+particles based on a model described by Clemmer and Robbins
+:ref:`(Clemmer) <fragment-Clemmer>`. The force has a magnitude of
 
 .. math::
 
    F = k (r - r_0) w
 
-where :math:`k_r` is a stiffness, :math:`r` is the current distance
+where :math:`k` is a stiffness, :math:`r` is the current distance
 and :math:`r_0` is the initial distance between the two particles, and
 :math:`w` is an optional smoothing factor discussed below. Bonds will
 break at a strain of :math:`\epsilon_c`.  This is done by setting by
@@ -98,13 +105,22 @@ the data file or restart files read by the :doc:`read_data
 * :math:`\epsilon_c`    (unit less)
 * :math:`\gamma`        (force/velocity units)
 
+However, the *normalize* option will normalize the elastic bond force by
+:math:`r_0` such that :math:`k` is unit less.
+
 By default, pair forces are not calculated between bonded particles.
 Pair forces can alternatively be overlaid on top of bond forces using
-the *overlay/pair* keyword. These settings require specific
+the *overlay/pair* option. These settings require specific
 :doc:`special_bonds <special_bonds>` settings described in the
 restrictions.  Further details can be found in the `:doc: how to
 <Howto_BPM>` page on BPMs.
 
+.. versionadded:: 28Mar2023
+
+If the *break* option is used, then LAMMPS assumes bonds should not break
+during a simulation run. This will prevent some unnecessary calculation.
+However, if a bond does break, it will trigger an error.
+
 If the *store/local* keyword is used, an internal fix will track bonds that
 break during the simulation. Whenever a bond breaks, data is processed
 and transferred to an internal fix labeled *fix_ID*. This allows the
@@ -196,10 +212,14 @@ Related commands
 Default
 """""""
 
-The option defaults are *smooth* = *yes*
+The option defaults are *overlay/pair* = *no*, *smooth* = *yes*, *normalize* = *no*, and *break* = *yes*
 
 ----------
 
+.. _fragment-Clemmer:
+
+**(Clemmer)** Clemmer and Robbins, Phys. Rev. Lett. (2022).
+
 .. _Groot4:
 
 **(Groot)** Groot and Warren, J Chem Phys, 107, 4423-35 (1997).

doc/src/bond_fene.rst

@@ -51,7 +51,7 @@ in the same form as in pair style :doc:`nm/cut <pair_nm>`. The bond energy is th
 
 .. math::
 
-  E = -0.5 K r_0^2  \ln \left[ 1 - \left(\frac{r}{R_0}\right)^2\right] + \frac{E_0}{(n-m)} \left[ m \left(\frac{r_0}{r}\right)^n - n \left(\frac{r_0}{r}\right)^m \right]
+  E = -0.5 K R_0^2  \ln \left[ 1 - \left(\frac{r}{R_0}\right)^2\right] + \frac{E_0}{(n-m)} \left[ m \left(\frac{r_0}{r}\right)^n - n \left(\frac{r_0}{r}\right)^m \right]
 
 Similar to the *fene* style, the generalized Lennard-Jones is cut off at
 the potential minimum, :math:`r_0`, to be repulsive only.  The following

doc/src/bond_harmonic_restrain.rst

@@ -0,0 +1,90 @@
+.. index:: bond_style harmonic/restrain
+
+bond_style harmonic/restrain command
+====================================
+
+Syntax
+""""""
+
+.. code-block:: LAMMPS
+
+   bond_style harmonic/restrain
+
+Examples
+""""""""
+
+.. code-block:: LAMMPS
+
+   bond_style harmonic
+   bond_coeff 5 80.0
+
+Description
+"""""""""""
+
+.. versionadded:: 28Mar2023
+
+The *harmonic/restrain* bond style uses the potential
+
+.. math::
+
+   E = K (r - r_{t=0})^2
+
+where :math:`r_{t=0}` is the distance between the bonded atoms at the
+beginning of the first :doc:`run <run>` or :doc:`minimize <minimize>`
+command after the bond style has been defined (*t=0*).  Note that the
+usual 1/2 factor is included in :math:`K`.  This will effectively
+restrain bonds to their initial length, whatever that is.  This is where
+this bond style differs from :doc:`bond style harmonic <bond_harmonic>`
+where the bond length is set through the per bond type coefficients.
+
+The following coefficient must be defined for each bond type via the
+:doc:`bond_coeff <bond_coeff>` command as in the example above, or in
+the data file or restart files read by the :doc:`read_data <read_data>`
+or :doc:`read_restart <read_restart>` commands
+
+* :math:`K` (energy/distance\^2)
+
+This bond style differs from other options to add harmonic restraints
+like :doc:`fix restrain <fix_restrain>` or :doc:`pair style list
+<pair_list>` or :doc:`fix colvars <fix_colvars>` in that it requires a
+bond topology, and thus the defined bonds will trigger exclusion of
+special neighbors from the neighbor list according to the
+:doc:`special_bonds <special_bonds>` settings.
+
+Restart info
+""""""""""""
+
+This bond style supports the :doc:`write_restart <write_restart>` and
+:doc:`read_restart <read_restart>` commands. The state of the initial
+bond lengths is stored with restart files and read back.
+
+Restrictions
+""""""""""""
+
+This bond style can only be used if LAMMPS was built with the
+EXTRA-MOLECULE package.  See the :doc:`Build package <Build_package>`
+page for more info.
+
+This bond style maintains internal data to determine the original bond
+lengths :math:`r_{t=0}`.  This information will be written to
+:doc:`binary restart files <write_restart>` but **not** to :doc:`data
+files <write_data>`.  Thus, continuing a simulation is *only* possible
+with :doc:`read_restart <read_restart>`.  When using the :doc:`read_data
+command <read_data>`, the reference bond lengths :math:`r_{t=0}` will be
+re-initialized from the current geometry.
+
+This bond style cannot be used with :doc:`fix shake or fix rattle
+<fix_shake>`, with :doc:`fix filter/corotate <fix_filter_corotate>`, or
+any :doc:`tip4p pair style <pair_lj_cut_tip4p>` since there is no specific
+equilibrium distance for a given bond type.
+
+Related commands
+""""""""""""""""
+
+:doc:`bond_coeff <bond_coeff>`,  :doc:`bond_harmonic <bond_harmonic>`,
+:doc:`fix restrain <fix_restrain>`, :doc:`pair style list <pair_list>`
+
+Default
+"""""""
+
+none

doc/src/bond_style.rst

@@ -10,7 +10,7 @@ Syntax
 
    bond_style style args
 
-* style = *none* or *zero* or *hybrid* or *bpm/rotational* or *bpm/spring* or *class2* or *fene* or *fene/expand* or *fene/nm* or *gaussian* or *gromos* or *harmonic* or *harmonic/shift* or *harmonic/shift/cut* or *lepton* or *morse* or *nonlinear* or *oxdna/fene* or *oxdena2/fene* or *oxrna2/fene* or *quartic* or *special* or *table*
+* style = *none* or *zero* or *hybrid* or *bpm/rotational* or *bpm/spring* or *class2* or *fene* or *fene/expand* or *fene/nm* or *gaussian* or *gromos* or *harmonic* or *harmonic/restrain* *harmonic/shift* or *harmonic/shift/cut* or *lepton* or *morse* or *nonlinear* or *oxdna/fene* or *oxdena2/fene* or *oxrna2/fene* or *quartic* or *special* or *table*
 
 * args = none for any style except *hybrid*
 
@@ -32,13 +32,13 @@ Set the formula(s) LAMMPS uses to compute bond interactions between
 pairs of atoms.  In LAMMPS, a bond differs from a pairwise
 interaction, which are set via the :doc:`pair_style <pair_style>`
 command.  Bonds are defined between specified pairs of atoms and
-remain in force for the duration of the simulation (unless the bond
-breaks which is possible in some bond potentials).  The list of bonded
-atoms is read in by a :doc:`read_data <read_data>` or
-:doc:`read_restart <read_restart>` command from a data or restart file.
-By contrast, pair potentials are typically defined between all pairs
-of atoms within a cutoff distance and the set of active interactions
-changes over time.
+remain in force for the duration of the simulation (unless new bonds
+are created or existing bonds break, which is possible in some fixes
+and bond potentials).  The list of bonded atoms is read in by a
+:doc:`read_data <read_data>` or :doc:`read_restart <read_restart>`
+command from a data or restart file.  By contrast, pair potentials are
+typically defined between all pairs of atoms within a cutoff distance
+and the set of active interactions changes over time.
 
 Hybrid models where bonds are computed using different bond potentials
 can be setup using the *hybrid* bond style.
@@ -93,6 +93,7 @@ accelerated styles exist.
 * :doc:`gaussian <bond_gaussian>` - multicentered Gaussian-based bond potential
 * :doc:`gromos <bond_gromos>` - GROMOS force field bond
 * :doc:`harmonic <bond_harmonic>` - harmonic bond
+* :doc:`harmonic/restrain <bond_harmonic_restrain>` - harmonic bond to restrain to original bond distance
 * :doc:`harmonic/shift <bond_harmonic_shift>` - shifted harmonic bond
 * :doc:`harmonic/shift/cut <bond_harmonic_shift_cut>` - shifted harmonic bond with a cutoff
 * :doc:`lepton <bond_lepton>` - bond potential from evaluating a string

doc/src/bond_table.rst

@@ -112,8 +112,9 @@ are estimated (less accurately) by the first two and last two force
 values in the table.
 
 The "EQ" parameter is also optional.  If used, it is followed by a the
-equilibrium bond length, which is used, for example, by the :doc:`fix shake <fix_shake>` command.  If not used, the equilibrium bond
-length is to the distance in the table with the lowest potential energy.
+equilibrium bond length, which is used, for example, by the :doc:`fix
+shake <fix_shake>` command.  If not used, the equilibrium bond length is
+to the distance in the table with the lowest potential energy.
 
 Following a blank line, the next N lines list the tabulated values.
 On each line, the first value is the index from 1 to N, the second value is
@@ -135,16 +136,15 @@ one that matches the specified keyword.
 
 ----------
 
-Restart, fix_modify, output, run start/stop, minimize info
-"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
+Restart info
+""""""""""""
 
-This bond style writes the settings for the "bond_style table"
-command to :doc:`binary restart files <restart>`, so a bond_style
-command does not need to specified in an input script that reads a
-restart file.  However, the coefficient information is not stored in
-the restart file, since it is tabulated in the potential files.  Thus,
-bond_coeff commands do need to be specified in the restart input
-script.
+This bond style writes the settings for the "bond_style table" command
+to :doc:`binary restart files <restart>`, so a bond_style command does
+not need to specified in an input script that reads a restart file.
+However, the coefficient information is not stored in the restart file,
+since it is tabulated in the potential files.  Thus, bond_coeff commands
+do need to be specified in the restart input script.
 
 Restrictions
 """"""""""""

doc/src/bond_write.rst

@@ -70,7 +70,7 @@ be specified even if the potential has a finite value at r = 0.0.
 Related commands
 """"""""""""""""
 
-:doc:`bond_style table <bond_table>`, `angle_write <angle_write>`,
+:doc:`bond_style table <bond_table>`, :doc:`angle_write <angle_write>`,
 :doc:`bond_style <bond_style>`, :doc:`bond_coeff <bond_coeff>`
 
 Default

doc/src/comm_modify.rst

@@ -69,6 +69,7 @@ For many systems this is an efficient algorithm, but for systems with
 widely varying cutoffs for different type pairs, the *multi* or *multi/old* mode can
 be faster.  In *multi*, each atom is assigned to a collection which should
 correspond to a set of atoms with similar interaction cutoffs.
+See the :doc:`neighbor <neighbor>` command for a detailed description of collections.
 In this case, each atom collection is assigned its own distance
 cutoff for communication purposes, and fewer atoms will be
 communicated. in *multi/old*, a similar technique is used but atoms

doc/src/compute.rst

@@ -200,12 +200,15 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
 * :doc:`com/chunk <compute_com_chunk>` - center of mass for each chunk
 * :doc:`contact/atom <compute_contact_atom>` - contact count for each spherical particle
 * :doc:`coord/atom <compute_coord_atom>` - coordination number for each atom
+* :doc:`count/type <compute_count_type>` - count of atoms or bonds by type
 * :doc:`damage/atom <compute_damage_atom>` - Peridynamic damage for each atom
 * :doc:`dihedral <compute_dihedral>` - energy of each dihedral sub-style
 * :doc:`dihedral/local <compute_dihedral_local>` - angle of each dihedral
 * :doc:`dilatation/atom <compute_dilatation_atom>` - Peridynamic dilatation for each atom
 * :doc:`dipole <compute_dipole>` - dipole vector and total dipole
 * :doc:`dipole/chunk <compute_dipole_chunk>` - dipole vector and total dipole for each chunk
+* :doc:`dipole/tip4p <compute_dipole>` - dipole vector and total dipole with TIP4P pair style
+* :doc:`dipole/tip4p/chunk <compute_dipole_chunk>` - dipole vector and total dipole for each chunk with TIP4P pair style
 * :doc:`displace/atom <compute_displace_atom>` - displacement of each atom
 * :doc:`dpd <compute_dpd>` - total values of internal conductive energy, internal mechanical energy, chemical energy, and harmonic average of internal temperature
 * :doc:`dpd/atom <compute_dpd_atom>` - per-particle values of internal conductive energy, internal mechanical energy, chemical energy, and internal temperature
@@ -258,6 +261,7 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
 * :doc:`pe/tally <compute_tally>` - potential energy between two groups of atoms via the tally callback mechanism
 * :doc:`plasticity/atom <compute_plasticity_atom>` - Peridynamic plasticity for each atom
 * :doc:`pressure <compute_pressure>` - total pressure and pressure tensor
+* :doc:`pressure/alchemy <compute_pressure_alchemy>` - mixed system total pressure and pressure tensor for :doc:`fix alchemy <fix_alchemy>` runs
 * :doc:`pressure/uef <compute_pressure_uef>` - pressure tensor in the reference frame of an applied flow field
 * :doc:`property/atom <compute_property_atom>` - convert atom attributes to per-atom vectors/arrays
 * :doc:`property/chunk <compute_property_chunk>` - extract various per-chunk attributes
@@ -303,11 +307,11 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
 * :doc:`sph/t/atom <compute_sph_t_atom>` - per-atom internal temperature of Smooth-Particle Hydrodynamics atoms
 * :doc:`spin <compute_spin>` - magnetic quantities for a system of atoms having spins
 * :doc:`stress/atom <compute_stress_atom>` - stress tensor for each atom
-* :doc:`stress/cartesian <compute_stress_profile>` - stress tensor in cartesian coordinates
-* :doc:`stress/cylinder <compute_stress_profile>` - stress tensor in cylindrical coordinates
+* :doc:`stress/cartesian <compute_stress_cartesian>` - stress tensor in cartesian coordinates
+* :doc:`stress/cylinder <compute_stress_curvilinear>` - stress tensor in cylindrical coordinates
 * :doc:`stress/mop <compute_stress_mop>` - normal components of the local stress tensor using the method of planes
 * :doc:`stress/mop/profile <compute_stress_mop>` - profile of the normal components of the local stress tensor using the method of planes
-* :doc:`stress/spherical <compute_stress_profile>` - stress tensor in spherical coordinates
+* :doc:`stress/spherical <compute_stress_curvilinear>` - stress tensor in spherical coordinates
 * :doc:`stress/tally <compute_tally>` - stress between two groups of atoms via the tally callback mechanism
 * :doc:`tdpd/cc/atom <compute_tdpd_cc_atom>` - per-atom chemical concentration of a specified species for each tDPD particle
 * :doc:`temp <compute_temp>` - temperature of group of atoms