Merge pull request #4205 from akohlmey/next-release

Update version tags for next feature release

.github/CODEOWNERS

@@ -37,7 +37,8 @@ src/MESONT/*          @iafoss
 src/ML-HDNNP/*        @singraber
 src/ML-IAP/*          @athomps
 src/ML-PACE/*         @yury-lysogorskiy
-src/ML-POD/*          @exapde @rohskopf
+src/ML-POD/*          @exapde
+src/ML-UF3/*          @monk-04
 src/MOFFF/*           @hheenen
 src/MOLFILE/*         @akohlmey
 src/NETCDF/*          @pastewka
@@ -58,17 +59,23 @@ src/VTK/*             @rbberger
 
 # individual files in packages
 src/GPU/pair_vashishta_gpu.*        @andeplane
-src/KOKKOS/pair_vashishta_kokkos.*  @andeplane
+src/KOKKOS/pair_vashishta_kokkos.*  @andeplane @stanmoore1
+src/KOSSOS/pair_pod_kokkos.*        @exapde @stanmoore1
 src/MANYBODY/pair_vashishta_table.* @andeplane
 src/MANYBODY/pair_atm.*             @sergeylishchuk
 src/MANYBODY/pair_nb3b_screened.*   @flodesani
 src/REPLICA/*_grem.*                @dstelter92
 src/EXTRA-COMPUTE/compute_stress_mop*.* @RomainVermorel
 src/EXTRA-COMPUTE/compute_born_matrix.* @Bibobu @athomps
+src/EXTRA-FIX/fix_deform_pressure.* @jtclemm
 src/MISC/*_tracker.*                @jtclemm
 src/MC/fix_gcmc.*                   @athomps
 src/MC/fix_sgcmc.*                  @athomps
+src/REAXFF/compute_reaxff_atom.*    @rbberger
+src/KOKKOS/compute_reaxff_atom_kokkos.*    @rbberger
 src/REPLICA/fix_pimd_langevin.*     @Yi-FanLi
+src/DPD-BASIC/pair_dpd_coul_slater_long.* @Eddy-Barraud
+src/GPU/pair_dpd_coul_slater_long.* @Eddy-Barraud
 
 # core LAMMPS classes
 src/lammps.*              @sjplimp
@@ -80,7 +87,7 @@ src/bond.*                @sjplimp
 src/comm*.*               @sjplimp
 src/compute.*             @sjplimp
 src/dihedral.*            @sjplimp
-src/domain.*              @sjplimp
+src/domain.*              @sjplimp @stanmoore1
 src/dump*.*               @sjplimp
 src/error.*               @sjplimp
 src/finish.*              @sjplimp

.github/workflows/codeql-analysis.yml

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

.github/workflows/compile-msvc.yml

@@ -24,7 +24,7 @@ jobs:
         fetch-depth: 2
 
     - name: Select Python version
-      uses: actions/setup-python@v4
+      uses: actions/setup-python@v5
       with:
         python-version: '3.11'
 

.github/workflows/coverity.yml

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

.github/workflows/unittest-macos.yml

@@ -15,7 +15,7 @@ jobs:
   build:
     name: MacOS Unit Test
     if: ${{ github.repository == 'lammps/lammps' }}
-    runs-on: macos-latest
+    runs-on: macos-13
     env:
       CCACHE_DIR: ${{ github.workspace }}/.ccache
 
@@ -32,7 +32,7 @@ jobs:
       run: mkdir build
 
     - name: Set up ccache
-      uses: actions/cache@v3
+      uses: actions/cache@v4
       with:
         path: ${{ env.CCACHE_DIR }}
         key: macos-ccache-${{ github.sha }}
@@ -43,6 +43,8 @@ jobs:
       working-directory: build
       run: |
         ccache -z
+        python3 -m venv macosenv
+        source macosenv/bin/activate
         python3 -m pip install numpy
         python3 -m pip install pyyaml
         cmake -C ../cmake/presets/clang.cmake \

.gitignore

@@ -43,12 +43,12 @@ Thumbs.db
 
 #cmake
 /build*
-/CMakeCache.txt
-/CMakeFiles/
-/Testing
+CMakeCache.txt
+CMakeFiles
 /Makefile
-/Testing
-/cmake_install.cmake
+Testing
+Temporary
+cmake_install.cmake
 /lmp
 out/Debug
 out/RelWithDebInfo
@@ -60,3 +60,4 @@ src/Makefile.package.settings-e
 /cmake/build/x64-Debug-Clang
 /install/x64-GUI-MSVC
 /install
+.Rhistory

cmake/CMakeLists.txt

@@ -23,6 +23,7 @@ project(lammps CXX)
 set(SOVERSION 0)
 get_property(BUILD_IS_MULTI_CONFIG GLOBAL PROPERTY GENERATOR_IS_MULTI_CONFIG)
 
+include(GNUInstallDirs)
 get_filename_component(LAMMPS_DIR ${CMAKE_CURRENT_SOURCE_DIR}/.. ABSOLUTE)
 get_filename_component(LAMMPS_LIB_BINARY_DIR ${CMAKE_BINARY_DIR}/lib ABSOLUTE)
 # collect all executables and shared libs in the top level build folder
@@ -120,6 +121,19 @@ if((CMAKE_CXX_COMPILER_ID STREQUAL "NVHPC") OR (CMAKE_CXX_COMPILER_ID STREQUAL "
   set(CMAKE_TUNE_DEFAULT "-Minform=severe")
 endif()
 
+# this hack is required to compile fmt lib with CrayClang version 15.0.2
+# CrayClang is only directly recognized by version 3.28 and later
+if(CMAKE_VERSION VERSION_LESS 3.28)
+  get_filename_component(_exe "${CMAKE_CXX_COMPILER}" NAME)
+  if((CMAKE_CXX_COMPILER_ID STREQUAL "Clang") AND (_exe STREQUAL "crayCC"))
+    set(CMAKE_TUNE_DEFAULT "-DFMT_STATIC_THOUSANDS_SEPARATOR")
+  endif()
+else()
+  if(CMAKE_CXX_COMPILER_ID STREQUAL "CrayClang")
+    set(CMAKE_TUNE_DEFAULT "-DFMT_STATIC_THOUSANDS_SEPARATOR")
+  endif()
+endif()
+
 # silence nvcc warnings
 if((PKG_KOKKOS) AND (Kokkos_ENABLE_CUDA) AND NOT (CMAKE_CXX_COMPILER_ID STREQUAL "Clang"))
   set(CMAKE_TUNE_DEFAULT "${CMAKE_TUNE_DEFAULT} -Xcudafe --diag_suppress=unrecognized_pragma")
@@ -195,7 +209,7 @@ else()
   unset(CMAKE_CXX_CLANG_TIDY CACHE)
 endif()
 
-include(GNUInstallDirs)
+
 file(GLOB ALL_SOURCES CONFIGURE_DEPENDS ${LAMMPS_SOURCE_DIR}/[^.]*.cpp)
 file(GLOB MAIN_SOURCES CONFIGURE_DEPENDS ${LAMMPS_SOURCE_DIR}/main.cpp)
 list(REMOVE_ITEM ALL_SOURCES ${MAIN_SOURCES})
@@ -209,6 +223,10 @@ endif()
 add_executable(lmp ${MAIN_SOURCES})
 target_link_libraries(lmp PRIVATE lammps)
 set_target_properties(lmp PROPERTIES OUTPUT_NAME ${LAMMPS_BINARY})
+# re-export all symbols for plugins
+if(PKG_PLUGIN AND (NOT ((CMAKE_SYSTEM_NAME STREQUAL "Windows"))))
+  set_target_properties(lmp PROPERTIES ENABLE_EXPORTS TRUE)
+endif()
 install(TARGETS lmp EXPORT LAMMPS_Targets DESTINATION ${CMAKE_INSTALL_BINDIR})
 
 option(CMAKE_VERBOSE_MAKEFILE "Generate verbose Makefiles" OFF)
@@ -239,6 +257,7 @@ set(STANDARD_PACKAGES
   DRUDE
   EFF
   ELECTRODE
+  EXTRA-COMMAND
   EXTRA-COMPUTE
   EXTRA-DUMP
   EXTRA-FIX
@@ -264,10 +283,11 @@ set(STANDARD_PACKAGES
   ML-HDNNP
   ML-IAP
   ML-PACE
+  ML-POD
   ML-QUIP
   ML-RANN
   ML-SNAP
-  ML-POD
+  ML-UF3
   MOFFF
   MOLECULE
   MOLFILE
@@ -415,6 +435,7 @@ if(BUILD_OMP)
       (CMAKE_CXX_COMPILER_ID STREQUAL "IntelLLVM") OR (CMAKE_CXX_COMPILER_ID STREQUAL "XLClang") OR
       ((CMAKE_CXX_COMPILER_ID STREQUAL "AppleClang") AND (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 10.0)) OR
       ((CMAKE_CXX_COMPILER_ID STREQUAL "Clang") AND (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 10.0)) OR
+      ((CMAKE_CXX_COMPILER_ID STREQUAL "CrayClang") AND (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 10.0)) OR
       ((CMAKE_CXX_COMPILER_ID STREQUAL "Intel") AND (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 19.0)))
     # GCC 9.x and later plus Clang 10.x and later implement strict OpenMP 4.0 semantics for consts.
     # Intel 18.0 was tested to support both, so we switch to OpenMP 4+ from 19.x onward to be safe.
@@ -425,6 +446,21 @@ if(BUILD_OMP)
   target_compile_definitions(lammps PRIVATE -DLAMMPS_OMP_COMPAT=${LAMMPS_OMP_COMPAT_LEVEL})
   target_link_libraries(lammps PRIVATE OpenMP::OpenMP_CXX)
   target_link_libraries(lmp PRIVATE OpenMP::OpenMP_CXX)
+
+  # this hack is required to correctly link with OpenMP support when using CrayClang version 15.0.2
+  # CrayClang is only directly recognized by version 3.28 and later
+  if(CMAKE_VERSION VERSION_LESS 3.28)
+    get_filename_component(_exe "${CMAKE_CXX_COMPILER}" NAME)
+    if((CMAKE_CXX_COMPILER_ID STREQUAL "Clang") AND (_exe STREQUAL "crayCC"))
+      set(CMAKE_SHARED_LINKER_FLAGS_${BTYPE} "${CMAKE_SHARED_LINKER_FLAGS_${BTYPE} -fopenmp")
+      set(CMAKE_STATIC_LINKER_FLAGS_${BTYPE} "${CMAKE_STATIC_LINKER_FLAGS_${BTYPE} -fopenmp")
+    endif()
+  else()
+    if(CMAKE_CXX_COMPILER_ID STREQUAL "CrayClang")
+      set(CMAKE_SHARED_LINKER_FLAGS_${BTYPE} "${CMAKE_SHARED_LINKER_FLAGS_${BTYPE} -fopenmp")
+      set(CMAKE_STATIC_LINKER_FLAGS_${BTYPE} "${CMAKE_STATIC_LINKER_FLAGS_${BTYPE} -fopenmp")
+    endif()
+  endif()
 endif()
 
 # lower C++ standard for fmtlib sources when using Intel classic compiler
@@ -539,12 +575,12 @@ endforeach()
 ########################################################################
 # Basic system tests (standard libraries, headers, functions, types)   #
 ########################################################################
-foreach(HEADER cmath)
-  check_include_file_cxx(${HEADER} FOUND_${HEADER})
-  if(NOT FOUND_${HEADER})
-    message(FATAL_ERROR "Could not find needed header - ${HEADER}")
-  endif(NOT FOUND_${HEADER})
-endforeach(HEADER)
+if (NOT ((CMAKE_CXX_COMPILER_ID STREQUAL "Intel") OR (CMAKE_CXX_COMPILER_ID STREQUAL "IntelLLVM")))
+  check_include_file_cxx(cmath FOUND_CMATH)
+  if(NOT FOUND_CMATH)
+    message(FATAL_ERROR "Could not find the required 'cmath' header")
+  endif(NOT FOUND_CMATH)
+endif()
 
 # make the standard math library overrideable and autodetected (for systems that don't have it)
 find_library(STANDARD_MATH_LIB m DOC "Standard Math library")
@@ -656,7 +692,7 @@ endif()
 # packages which selectively include variants based on enabled styles
 # e.g. accelerator packages
 ######################################################################
-foreach(PKG_WITH_INCL CORESHELL DPD-SMOOTH MC MISC PHONON QEQ OPENMP KOKKOS OPT INTEL GPU)
+foreach(PKG_WITH_INCL CORESHELL DPD-BASIC DPD-SMOOTH MC MISC PHONON QEQ OPENMP KOKKOS OPT INTEL GPU)
   if(PKG_${PKG_WITH_INCL})
     include(Packages/${PKG_WITH_INCL})
   endif()
@@ -971,34 +1007,37 @@ if(PKG_KOKKOS)
   endif()
 endif()
 if(PKG_KSPACE)
-  message(STATUS "<<< FFT settings >>>
+  if (FFT_USE_HEFFTE)
+    message(STATUS "<<< FFT settings >>>
+-- Primary FFT lib:  heFFTe")
+    if (FFT_HEFFTE_BACKEND)
+      message(STATUS "heFFTe backend:  ${FFT_HEFFTE_BACKEND}")
+    else()
+      message(STATUS "heFFTe backend:  stock (builtin FFT implementation, tested for corrected but not optimized for production)")
+    endif()
+    message(STATUS "Using distributed FFT algorithms from heFTTe")
+    if(FFT_SINGLE)
+      message(STATUS "Using single precision FFTs")
+    else()
+      message(STATUS "Using double precision FFTs")
+    endif()
+  else()
+    message(STATUS "<<< FFT settings >>>
 -- Primary FFT lib:  ${FFT}")
-  if(FFT_SINGLE)
-    message(STATUS "Using single precision FFTs")
-  else()
-    message(STATUS "Using double precision FFTs")
-  endif()
-  if(FFT_FFTW_THREADS OR FFT_MKL_THREADS)
-    message(STATUS "Using threaded FFTs")
-  else()
-    message(STATUS "Using non-threaded FFTs")
+    if(FFT_SINGLE)
+      message(STATUS "Using single precision FFTs")
+    else()
+      message(STATUS "Using double precision FFTs")
+    endif()
+    if(FFT_FFTW_THREADS OR FFT_MKL_THREADS)
+      message(STATUS "Using threaded FFTs")
+    else()
+      message(STATUS "Using non-threaded FFTs")
+    endif()
+    message(STATUS "Using builtin distributed FFT algorithms")
   endif()
   if(PKG_KOKKOS)
-    if(Kokkos_ENABLE_CUDA)
-      if(FFT STREQUAL "KISS")
-        message(STATUS "Kokkos FFT: KISS")
-      else()
-        message(STATUS "Kokkos FFT: cuFFT")
-      endif()
-    elseif(Kokkos_ENABLE_HIP)
-      if(FFT STREQUAL "KISS")
-        message(STATUS "Kokkos FFT: KISS")
-      else()
-        message(STATUS "Kokkos FFT: hipFFT")
-      endif()
-    else()
-      message(STATUS "Kokkos FFT: ${FFT}")
-    endif()
+    message(STATUS "Kokkos FFT: ${FFT_KOKKOS}")
   endif()
 endif()
 if(BUILD_DOC)

cmake/Modules/DetectHIPInstallation.cmake

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

cmake/Modules/ExternalCMakeProject.cmake

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

cmake/Modules/OpenCLLoader.cmake

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

cmake/Modules/Packages/DPD-BASIC.cmake

@@ -0,0 +1,9 @@
+# pair style dpd/coul/slater/long may only be installed if also KSPACE is installed
+if(NOT PKG_KSPACE)
+  get_property(LAMMPS_PAIR_HEADERS GLOBAL PROPERTY PAIR)
+  list(REMOVE_ITEM LAMMPS_PAIR_HEADERS ${LAMMPS_SOURCE_DIR}/DPD-BASIC/pair_dpd_coul_slater_long.h)
+  set_property(GLOBAL PROPERTY PAIR "${LAMMPS_PAIR_HEADERS}")
+  get_target_property(LAMMPS_SOURCES lammps SOURCES)
+  list(REMOVE_ITEM LAMMPS_SOURCES ${LAMMPS_SOURCE_DIR}/DPD-BASIC/pair_dpd_coul_slater_long.cpp)
+  set_property(TARGET lammps PROPERTY SOURCES "${LAMMPS_SOURCES}")
+endif()

cmake/Modules/Packages/GPU.cmake

@@ -1,3 +1,10 @@
+
+# Silence CMake warnings about FindCUDA being obsolete.
+# We may need to eventually rewrite this section to use enable_language(CUDA)
+if(POLICY CMP0146)
+  cmake_policy(SET CMP0146 OLD)
+endif()
+
 set(GPU_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/GPU)
 set(GPU_SOURCES ${GPU_SOURCES_DIR}/gpu_extra.h
                 ${GPU_SOURCES_DIR}/fix_gpu.h
@@ -151,10 +158,10 @@ if(GPU_API STREQUAL "CUDA")
   endif()
 
   cuda_compile_fatbin(GPU_GEN_OBJS ${GPU_LIB_CU} OPTIONS ${CUDA_REQUEST_PIC}
-          -DUNIX -O3 --use_fast_math -Wno-deprecated-gpu-targets -DNV_KERNEL -DUCL_CUDADR ${GPU_CUDA_GENCODE} -D_${GPU_PREC_SETTING} -DLAMMPS_${LAMMPS_SIZES})
+          -DUNIX -O3 --use_fast_math -Wno-deprecated-gpu-targets -allow-unsupported-compiler -DNV_KERNEL -DUCL_CUDADR ${GPU_CUDA_GENCODE} -D_${GPU_PREC_SETTING} -DLAMMPS_${LAMMPS_SIZES})
 
   cuda_compile(GPU_OBJS ${GPU_LIB_CUDPP_CU} OPTIONS ${CUDA_REQUEST_PIC}
-          -DUNIX -O3 --use_fast_math -Wno-deprecated-gpu-targets -DUCL_CUDADR ${GPU_CUDA_GENCODE} -D_${GPU_PREC_SETTING} -DLAMMPS_${LAMMPS_SIZES})
+          -DUNIX -O3 --use_fast_math -Wno-deprecated-gpu-targets -allow-unsupported-compiler -DUCL_CUDADR ${GPU_CUDA_GENCODE} -D_${GPU_PREC_SETTING} -DLAMMPS_${LAMMPS_SIZES})
 
   foreach(CU_OBJ ${GPU_GEN_OBJS})
     get_filename_component(CU_NAME ${CU_OBJ} NAME_WE)

cmake/Modules/Packages/INTEL.cmake

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

cmake/Modules/Packages/KOKKOS.cmake

@@ -16,11 +16,6 @@ endif()
 if(Kokkos_ENABLE_OPENMP)
   if(NOT BUILD_OMP)
     message(FATAL_ERROR "Must enable BUILD_OMP with Kokkos_ENABLE_OPENMP")
-  else()
-    # NVHPC/(AMD)Clang does not seem to provide a detectable OpenMP version, but is far beyond version 3.1
-    if((OpenMP_CXX_VERSION VERSION_LESS 3.1) AND NOT ((CMAKE_CXX_COMPILER_ID STREQUAL "NVHPC") OR (CMAKE_CXX_COMPILER_ID STREQUAL "Clang")))
-      message(FATAL_ERROR "Compiler must support OpenMP 3.1 or later with Kokkos_ENABLE_OPENMP")
-    endif()
   endif()
 endif()
 ########################################################################
@@ -50,8 +45,8 @@ if(DOWNLOAD_KOKKOS)
   list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_CXX_EXTENSIONS=${CMAKE_CXX_EXTENSIONS}")
   list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}")
   include(ExternalProject)
-  set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/4.1.00.tar.gz" CACHE STRING "URL for KOKKOS tarball")
-  set(KOKKOS_MD5 "a5f096bd8ad01b97fdc7a32583b17a33" CACHE STRING "MD5 checksum of KOKKOS tarball")
+  set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/4.3.01.tar.gz" CACHE STRING "URL for KOKKOS tarball")
+  set(KOKKOS_MD5 "243de871b3dc2cf3990c1c404032df83" CACHE STRING "MD5 checksum of KOKKOS tarball")
   mark_as_advanced(KOKKOS_URL)
   mark_as_advanced(KOKKOS_MD5)
   GetFallbackURL(KOKKOS_URL KOKKOS_FALLBACK)
@@ -76,7 +71,7 @@ if(DOWNLOAD_KOKKOS)
   add_dependencies(LAMMPS::KOKKOSCORE kokkos_build)
   add_dependencies(LAMMPS::KOKKOSCONTAINERS kokkos_build)
 elseif(EXTERNAL_KOKKOS)
-  find_package(Kokkos 4.1.00 REQUIRED CONFIG)
+  find_package(Kokkos 4.3.01 REQUIRED CONFIG)
   target_link_libraries(lammps PRIVATE Kokkos::kokkos)
 else()
   set(LAMMPS_LIB_KOKKOS_SRC_DIR ${LAMMPS_LIB_SOURCE_DIR}/kokkos)
@@ -131,16 +126,33 @@ if(PKG_KSPACE)
   list(APPEND KOKKOS_PKG_SOURCES ${KOKKOS_PKG_SOURCES_DIR}/fft3d_kokkos.cpp
                                  ${KOKKOS_PKG_SOURCES_DIR}/grid3d_kokkos.cpp
                                  ${KOKKOS_PKG_SOURCES_DIR}/remap_kokkos.cpp)
+  set(FFT_KOKKOS "KISS" CACHE STRING "FFT library for Kokkos-enabled KSPACE package")
+  set(FFT_KOKKOS_VALUES KISS FFTW3 MKL HIPFFT CUFFT)
+  set_property(CACHE FFT_KOKKOS PROPERTY STRINGS ${FFT_KOKKOS_VALUES})
+  validate_option(FFT_KOKKOS FFT_KOKKOS_VALUES)
+  string(TOUPPER ${FFT_KOKKOS} FFT_KOKKOS)
+
   if(Kokkos_ENABLE_CUDA)
-    if(NOT (FFT STREQUAL "KISS"))
-      target_compile_definitions(lammps PRIVATE -DFFT_CUFFT)
-      target_link_libraries(lammps PRIVATE cufft)
+    if(NOT ((FFT_KOKKOS STREQUAL "KISS") OR (FFT_KOKKOS STREQUAL "CUFFT")))
+      message(FATAL_ERROR "The CUDA backend of Kokkos requires either KISS FFT or CUFFT.")
+    elseif(FFT_KOKKOS STREQUAL "KISS")
+      message(WARNING "Using KISS FFT with the CUDA backend of Kokkos may be sub-optimal.")
+      target_compile_definitions(lammps PRIVATE -DFFT_KOKKOS_KISS)
+    elseif(FFT_KOKKOS STREQUAL "CUFFT")
+      find_package(CUDAToolkit REQUIRED)
+      target_compile_definitions(lammps PRIVATE -DFFT_KOKKOS_CUFFT)
+      target_link_libraries(lammps PRIVATE CUDA::cufft)
     endif()
   elseif(Kokkos_ENABLE_HIP)
-    if(NOT (FFT STREQUAL "KISS"))
+    if(NOT ((FFT_KOKKOS STREQUAL "KISS") OR (FFT_KOKKOS STREQUAL "HIPFFT")))
+      message(FATAL_ERROR "The HIP backend of Kokkos requires either KISS FFT or HIPFFT.")
+    elseif(FFT_KOKKOS STREQUAL "KISS")
+      message(WARNING "Using KISS FFT with the HIP backend of Kokkos may be sub-optimal.")
+      target_compile_definitions(lammps PRIVATE -DFFT_KOKKOS_KISS)
+    elseif(FFT_KOKKOS STREQUAL "HIPFFT")
       include(DetectHIPInstallation)
       find_package(hipfft REQUIRED)
-      target_compile_definitions(lammps PRIVATE -DFFT_HIPFFT)
+      target_compile_definitions(lammps PRIVATE -DFFT_KOKKOS_HIPFFT)
       target_link_libraries(lammps PRIVATE hip::hipfft)
     endif()
   endif()

cmake/Modules/Packages/KSPACE.cmake

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

cmake/Modules/Packages/MDI.cmake

@@ -8,8 +8,8 @@ option(DOWNLOAD_MDI "Download and compile the MDI library instead of using an al
 
 if(DOWNLOAD_MDI)
   message(STATUS "MDI download requested - we will build our own")
-  set(MDI_URL "https://github.com/MolSSI-MDI/MDI_Library/archive/v1.4.16.tar.gz" CACHE STRING "URL for MDI tarball")
-  set(MDI_MD5 "407db44e2d79447ab5c1233af1965f65" CACHE STRING "MD5 checksum for MDI tarball")
+  set(MDI_URL "https://github.com/MolSSI-MDI/MDI_Library/archive/v1.4.26.tar.gz" CACHE STRING "URL for MDI tarball")
+  set(MDI_MD5 "3124bb85259471e2a53a891f04bf697a" CACHE STRING "MD5 checksum for MDI tarball")
   mark_as_advanced(MDI_URL)
   mark_as_advanced(MDI_MD5)
   GetFallbackURL(MDI_URL MDI_FALLBACK)

cmake/Modules/Packages/ML-IAP.cmake

@@ -10,6 +10,14 @@ endif()
 
 option(MLIAP_ENABLE_PYTHON "Build ML-IAP package with Python support" ${MLIAP_ENABLE_PYTHON_DEFAULT})
 
+# if ML-PACE package *and* MLIAP with Python is enabled is included we may also include ML-PACE support in ML-IAP
+set(MLIAP_ENABLE_ACE_DEFAULT OFF)
+if(PKG_ML-PACE)
+  set(MLIAP_ENABLE_ACE_DEFAULT ON)
+endif()
+
+option(MLIAP_ENABLE_ACE "Build ML-IAP package with ACE support" ${MLIAP_ENABLE_ACE_DEFAULT})
+
 if(MLIAP_ENABLE_PYTHON)
   find_package(Cythonize REQUIRED)
   find_package(Python COMPONENTS NumPy REQUIRED)
@@ -36,3 +44,10 @@ if(MLIAP_ENABLE_PYTHON)
   target_compile_definitions(lammps PRIVATE -DMLIAP_PYTHON)
   target_include_directories(lammps PRIVATE ${MLIAP_BINARY_DIR})
 endif()
+
+if(MLIAP_ENABLE_ACE)
+  if(NOT PKG_ML-PACE)
+    message(FATAL_ERROR "Must enable ML-PACE package for including ACE support in ML-IAP")
+  endif()
+  target_compile_definitions(lammps PRIVATE -DMLIAP_ACE)
+endif()

cmake/Modules/Packages/ML-PACE.cmake

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

cmake/Modules/Packages/ML-QUIP.cmake

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

cmake/Modules/Packages/PLUMED.cmake

@@ -1,5 +1,9 @@
 # Plumed2 support for PLUMED package
 
+# for supporting multiple concurrent plumed2 installations for debugging and testing
+set(PLUMED_SUFFIX "" CACHE STRING "Suffix for Plumed2 library")
+mark_as_advanced(PLUMED_SUFFIX)
+
 if(BUILD_MPI)
   set(PLUMED_CONFIG_MPI "--enable-mpi")
   set(PLUMED_CONFIG_CC  ${CMAKE_MPI_C_COMPILER})
@@ -21,9 +25,11 @@ 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"
+# Note: must also adjust check for supported API versions in
+# fix_plumed.cpp when version changes from v2.n.x to v2.n+1.y
+set(PLUMED_URL "https://github.com/plumed/plumed2/releases/download/v2.9.1/plumed-src-2.9.1.tgz"
   CACHE STRING "URL for PLUMED tarball")
-set(PLUMED_MD5 "599092b6a0aa6fff992612537ad98994" CACHE STRING "MD5 checksum of PLUMED tarball")
+set(PLUMED_MD5 "c3b2d31479c1e9ce211719d40e9efbd7" CACHE STRING "MD5 checksum of PLUMED tarball")
 
 mark_as_advanced(PLUMED_URL)
 mark_as_advanced(PLUMED_MD5)
@@ -151,15 +157,15 @@ else()
     file(MAKE_DIRECTORY ${INSTALL_DIR}/include)
   else()
     find_package(PkgConfig REQUIRED)
-    pkg_check_modules(PLUMED REQUIRED plumed)
+    pkg_check_modules(PLUMED REQUIRED plumed${PLUMED_SUFFIX})
     add_library(LAMMPS::PLUMED INTERFACE IMPORTED)
     if(PLUMED_MODE STREQUAL "STATIC")
-      include(${PLUMED_LIBDIR}/plumed/src/lib/Plumed.cmake.static)
+      include(${PLUMED_LIBDIR}/plumed${PLUMED_SUFFIX}/src/lib/Plumed.cmake.static)
     elseif(PLUMED_MODE STREQUAL "SHARED")
-      include(${PLUMED_LIBDIR}/plumed/src/lib/Plumed.cmake.shared)
+      include(${PLUMED_LIBDIR}/plumed${PLUMED_SUFFIX}/src/lib/Plumed.cmake.shared)
     elseif(PLUMED_MODE STREQUAL "RUNTIME")
-      set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_COMPILE_DEFINITIONS "__PLUMED_DEFAULT_KERNEL=${PLUMED_LIBDIR}/${CMAKE_SHARED_LIBRARY_PREFIX}plumedKernel${CMAKE_SHARED_LIBRARY_SUFFIX}")
-      include(${PLUMED_LIBDIR}/plumed/src/lib/Plumed.cmake.runtime)
+      set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_COMPILE_DEFINITIONS "__PLUMED_DEFAULT_KERNEL=${PLUMED_LIBDIR}/${CMAKE_SHARED_LIBRARY_PREFIX}plumed${PLUMED_SUFFIX}Kernel${CMAKE_SHARED_LIBRARY_SUFFIX}")
+      include(${PLUMED_LIBDIR}/plumed${PLUMED_SUFFIX}/src/lib/Plumed.cmake.runtime)
     endif()
     set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_LINK_LIBRARIES "${PLUMED_LOAD}")
     set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_INCLUDE_DIRECTORIES "${PLUMED_INCLUDE_DIRS}")

cmake/packaging/build_linux_tgz.sh

@@ -59,12 +59,14 @@ done
 
 echo "Set up wrapper script"
 MYDIR=$(dirname "$0")
+cp ${MYDIR}/xdg-open ${DESTDIR}/bin
 cp ${MYDIR}/linux_wrapper.sh ${DESTDIR}/bin
 for s in ${DESTDIR}/bin/*
 do \
         EXE=$(basename $s)
         test ${EXE} = linux_wrapper.sh && continue
         test ${EXE} = qt.conf && continue
+        test ${EXE} = xdg-open && continue
         ln -s bin/linux_wrapper.sh ${DESTDIR}/${EXE}
 done
 

cmake/packaging/linux_wrapper.sh

@@ -4,15 +4,17 @@
 # reset locale to avoid problems with decimal numbers
 export LC_ALL=C
 
-BASEDIR=$(dirname "$0")
-EXENAME=$(basename "$0")
+BASEDIR="$(dirname "$0")"
+EXENAME="$(basename "$0")"
+
+PATH="${BASEDIR}/bin:${PATH}"
 
 # append to LD_LIBRARY_PATH to prefer local (newer) libs
-LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:${BASEDIR}/lib
+LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:${BASEDIR}/lib"
 
 # set some environment variables for LAMMPS etc.
-LAMMPS_POTENTIALS=${BASEDIR}/share/lammps/potentials
-MSI2LMP_LIBRARY=${BASEDIR}/share/lammps/frc_files
-export LD_LIBRARY_PATH LAMMPS_POTENTIALS MSI2LMP_LIBRARY
+LAMMPS_POTENTIALS="${BASEDIR}/share/lammps/potentials"
+MSI2LMP_LIBRARY="${BASEDIR}/share/lammps/frc_files"
+export LD_LIBRARY_PATH LAMMPS_POTENTIALS MSI2LMP_LIBRARY PATH
 
 exec "${BASEDIR}/bin/${EXENAME}" "$@"

cmake/presets/all_off.cmake

@@ -26,8 +26,9 @@ set(ALL_PACKAGES
   DPD-REACT
   DPD-SMOOTH
   DRUDE
-  ELECTRODE
   EFF
+  ELECTRODE
+  EXTRA-COMMAND
   EXTRA-COMPUTE
   EXTRA-DUMP
   EXTRA-FIX
@@ -60,6 +61,7 @@ set(ALL_PACKAGES
   ML-QUIP
   ML-RANN
   ML-SNAP
+  ML-UF3
   MOFFF
   MOLECULE
   MOLFILE

cmake/presets/all_on.cmake

@@ -28,8 +28,9 @@ set(ALL_PACKAGES
   DPD-REACT
   DPD-SMOOTH
   DRUDE
-  ELECTRODE
   EFF
+  ELECTRODE
+  EXTRA-COMMAND
   EXTRA-COMPUTE
   EXTRA-DUMP
   EXTRA-FIX
@@ -62,6 +63,7 @@ set(ALL_PACKAGES
   ML-QUIP
   ML-RANN
   ML-SNAP
+  ML-UF3
   MOFFF
   MOLECULE
   MOLFILE

cmake/presets/gpu-cuda.cmake

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

cmake/presets/kokkos-cuda.cmake

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

cmake/presets/kokkos-hip.cmake

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

cmake/presets/mingw-cross.cmake

@@ -22,8 +22,9 @@ set(WIN_PACKAGES
   DPD-REACT
   DPD-SMOOTH
   DRUDE
-  ELECTRODE
   EFF
+  ELECTRODE
+  EXTRA-COMMAND
   EXTRA-COMPUTE
   EXTRA-DUMP
   EXTRA-FIX
@@ -50,6 +51,7 @@ set(WIN_PACKAGES
   ML-POD
   ML-RANN
   ML-SNAP
+  ML-UF3
   MOFFF
   MOLECULE
   MOLFILE

cmake/presets/most.cmake

@@ -26,6 +26,7 @@ set(ALL_PACKAGES
   DRUDE
   EFF
   ELECTRODE
+  EXTRA-COMMAND
   EXTRA-COMPUTE
   EXTRA-DUMP
   EXTRA-FIX
@@ -45,6 +46,7 @@ set(ALL_PACKAGES
   ML-IAP
   ML-POD
   ML-SNAP
+  ML-UF3
   MOFFF
   MOLECULE
   OPENMP

cmake/presets/oneapi.cmake

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

cmake/presets/windows.cmake

@@ -22,6 +22,7 @@ set(WIN_PACKAGES
   DRUDE
   EFF
   ELECTRODE
+  EXTRA-COMMAND
   EXTRA-COMPUTE
   EXTRA-DUMP
   EXTRA-FIX
@@ -42,6 +43,7 @@ set(WIN_PACKAGES
   ML-IAP
   ML-POD
   ML-SNAP
+  ML-UF3
   MOFFF
   MOLECULE
   MOLFILE
@@ -50,8 +52,8 @@ set(WIN_PACKAGES
   ORIENT
   PERI
   PHONON
-  POEMS
   PLUGIN
+  POEMS
   PTM
   QEQ
   QTB

doc/Makefile

@@ -100,6 +100,7 @@ html: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJAX)
 		env LC_ALL=C grep -n ' :[a-z]\+`' $(RSTDIR)/*.rst ;\
 		env LC_ALL=C grep -n ' `[^`]\+<[a-z][^`]\+`[^_]' $(RSTDIR)/*.rst ;\
 		env LC_ALL=C grep -n ':\(ref\|doc\):[^`]' $(RSTDIR)/*.rst ;\
+		env LC_ALL=C grep -n '\(ref\|doc\)`[^`]' $(RSTDIR)/*.rst ;\
 		$(PYTHON) $(BUILDDIR)/utils/check-styles.py -s ../src -d src ;\
 		echo "############################################" ;\
 		deactivate ;\
@@ -182,6 +183,7 @@ pdf: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK)
 		env LC_ALL=C grep -n ' :[a-z]\+`' $(RSTDIR)/*.rst ;\
 		env LC_ALL=C grep -n ' `[^`]\+<[a-z][^`]\+`[^_]' $(RSTDIR)/*.rst ;\
 		env LC_ALL=C grep -n ':\(ref\|doc\):[^`]' $(RSTDIR)/*.rst ;\
+		env LC_ALL=C grep -n '\(ref\|doc\)`[^`]' $(RSTDIR)/*.rst ;\
 		$(PYTHON) utils/check-styles.py -s ../src -d src ;\
 		echo "############################################" ;\
 		deactivate ;\
@@ -231,6 +233,7 @@ role_check :
 	@( env LC_ALL=C grep -n ' :[a-z]\+`' $(RSTDIR)/*.rst && exit 1 || : )
 	@( env LC_ALL=C grep -n ' `[^`]\+<[a-z][^`]\+`[^_]' $(RSTDIR)/*.rst && exit 1 || : )
 	@( env LC_ALL=C grep -n ':\(ref\|doc\):[^`]' $(RSTDIR)/*.rst && exit 1 || : )
+	@( env LC_ALL=C grep -n '\(ref\|doc\)`[^`]' $(RSTDIR)/*.rst && exit 1 || : )
 
 link_check : $(VENV) html
 	@(\

doc/github-development-workflow.md

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

doc/graphviz/Makefile

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

doc/graphviz/lammps-releases.dot

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

doc/lammps.1

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

doc/src/Bibliography.rst

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

doc/src/Build_development.rst

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

doc/src/Build_extras.rst

@@ -533,9 +533,6 @@ They must be specified in uppercase.
    *  - A64FX
       - HOST
       - ARMv8.2 with SVE Support
-   *  - WSM
-      - HOST
-      - Intel Westmere CPU (SSE 4.2)
    *  - SNB
       - HOST
       - Intel Sandy/Ivy Bridge CPU (AVX 1)
@@ -566,18 +563,15 @@ They must be specified in uppercase.
    *  - KNL
       - HOST
       - Intel Knights Landing Xeon Phi
-   *  - BGQ
-      - HOST
-      - IBM Blue Gene/Q CPU
-   *  - POWER7
-      - HOST
-      - IBM POWER7 CPU
    *  - POWER8
       - HOST
       - IBM POWER8 CPU
    *  - POWER9
       - HOST
       - IBM POWER9 CPU
+   *  - RISCV_SG2042
+      - HOST
+      - SG2042 (RISC-V) CPU
    *  - KEPLER30
       - GPU
       - NVIDIA Kepler generation CC 3.0 GPU
@@ -626,22 +620,22 @@ They must be specified in uppercase.
    *  - HOPPER90
       - GPU
       - NVIDIA Hopper generation CC 9.0 GPU
-   *  - VEGA900
+   *  - AMD_GFX906
       - GPU
-      - AMD GPU MI25 GFX900
-   *  - VEGA906
+      - AMD GPU MI50/MI60
+   *  - AMD_GFX908
       - GPU
-      - AMD GPU MI50/MI60 GFX906
-   *  - VEGA908
+      - AMD GPU MI100
+   *  - AMD_GFX90A
       - GPU
-      - AMD GPU MI100 GFX908
-   *  - VEGA90A
+      - AMD GPU MI200
+   *  - AMD_GFX942
       - GPU
-      - AMD GPU MI200 GFX90A
-   *  - NAVI1030
+      - AMD GPU MI300
+   *  - AMD_GFX1030
       - GPU
       - AMD GPU V620/W6800
-   *  - NAVI1100
+   *  - AMD_GFX1100
       - GPU
       - AMD GPU RX7900XTX
    *  - INTEL_GEN
@@ -666,7 +660,7 @@ They must be specified in uppercase.
       - GPU
       - Intel GPU Ponte Vecchio
 
-This list was last updated for version 4.0.1 of the Kokkos library.
+This list was last updated for version 4.3.0 of the Kokkos library.
 
 .. tabs::
 

doc/src/Build_settings.rst

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

doc/src/Commands_bond.rst

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

doc/src/Commands_compute.rst

@@ -100,6 +100,7 @@ KOKKOS, o = OPENMP, t = OPT.
    * :doc:`nbond/atom <compute_nbond_atom>`
    * :doc:`omega/chunk <compute_omega_chunk>`
    * :doc:`orientorder/atom (k) <compute_orientorder_atom>`
+   * :doc:`pace <compute_pace>`
    * :doc:`pair <compute_pair>`
    * :doc:`pair/local <compute_pair_local>`
    * :doc:`pe <compute_pe>`
@@ -107,6 +108,10 @@ KOKKOS, o = OPENMP, t = OPT.
    * :doc:`pe/mol/tally <compute_tally>`
    * :doc:`pe/tally <compute_tally>`
    * :doc:`plasticity/atom <compute_plasticity_atom>`
+   * :doc:`pod/atom <compute_pod_atom>`
+   * :doc:`podd/atom <compute_pod_atom>`
+   * :doc:`pod/local <compute_pod_atom>`
+   * :doc:`pod/global <compute_pod_atom>`
    * :doc:`pressure <compute_pressure>`
    * :doc:`pressure/alchemy <compute_pressure_alchemy>`
    * :doc:`pressure/uef <compute_pressure_uef>`
@@ -115,12 +120,15 @@ KOKKOS, o = OPENMP, t = OPT.
    * :doc:`property/grid <compute_property_grid>`
    * :doc:`property/local <compute_property_local>`
    * :doc:`ptm/atom <compute_ptm_atom>`
+   * :doc:`rattlers/atom <compute_rattlers_atom>`
    * :doc:`rdf <compute_rdf>`
+   * :doc:`reaxff/atom (k) <compute_reaxff_atom>`
    * :doc:`reduce <compute_reduce>`
    * :doc:`reduce/chunk <compute_reduce_chunk>`
    * :doc:`reduce/region <compute_reduce>`
    * :doc:`rigid/local <compute_rigid_local>`
    * :doc:`saed <compute_saed>`
+   * :doc:`slcsa/atom <compute_slcsa_atom>`
    * :doc:`slice <compute_slice>`
    * :doc:`smd/contact/radius <compute_smd_contact_radius>`
    * :doc:`smd/damage <compute_smd_damage>`

doc/src/Commands_fix.rst

@@ -61,6 +61,7 @@ OPT.
    * :doc:`controller <fix_controller>`
    * :doc:`damping/cundall <fix_damping_cundall>`
    * :doc:`deform (k) <fix_deform>`
+   * :doc:`deform/pressure <fix_deform_pressure>`
    * :doc:`deposit <fix_deposit>`
    * :doc:`dpd/energy (k) <fix_dpd_energy>`
    * :doc:`drag <fix_drag>`
@@ -122,6 +123,7 @@ OPT.
    * :doc:`mvv/tdpd <fix_mvv_dpd>`
    * :doc:`neb <fix_neb>`
    * :doc:`neb/spin <fix_neb_spin>`
+   * :doc:`nonaffine/displacement <fix_nonaffine_displacement>`
    * :doc:`nph (ko) <fix_nh>`
    * :doc:`nph/asphere (o) <fix_nph_asphere>`
    * :doc:`nph/body <fix_nph_body>`
@@ -238,10 +240,10 @@ OPT.
    * :doc:`store/force <fix_store_force>`
    * :doc:`store/state <fix_store_state>`
    * :doc:`tdpd/source <fix_dpd_source>`
-   * :doc:`temp/berendsen <fix_temp_berendsen>`
+   * :doc:`temp/berendsen (k) <fix_temp_berendsen>`
    * :doc:`temp/csld <fix_temp_csvr>`
    * :doc:`temp/csvr <fix_temp_csvr>`
-   * :doc:`temp/rescale <fix_temp_rescale>`
+   * :doc:`temp/rescale (k) <fix_temp_rescale>`
    * :doc:`temp/rescale/eff <fix_temp_rescale_eff>`
    * :doc:`tfmc <fix_tfmc>`
    * :doc:`tgnpt/drude <fix_tgnh_drude>`
@@ -261,6 +263,7 @@ OPT.
    * :doc:`wall/body/polyhedron <fix_wall_body_polyhedron>`
    * :doc:`wall/colloid <fix_wall>`
    * :doc:`wall/ees <fix_wall_ees>`
+   * :doc:`wall/flow (k) <fix_wall_flow>`
    * :doc:`wall/gran (k) <fix_wall_gran>`
    * :doc:`wall/gran/region <fix_wall_gran_region>`
    * :doc:`wall/harmonic <fix_wall>`

doc/src/Commands_pair.rst

@@ -25,16 +25,16 @@ OPT.
 
    * :doc:`none <pair_none>`
    * :doc:`zero <pair_zero>`
-   * :doc:`hybrid (k) <pair_hybrid>`
-   * :doc:`hybrid/overlay (k) <pair_hybrid>`
-   * :doc:`hybrid/scaled <pair_hybrid>`
+   * :doc:`hybrid (ko) <pair_hybrid>`
+   * :doc:`hybrid/molecular (o) <pair_hybrid>`
+   * :doc:`hybrid/overlay (ko) <pair_hybrid>`
+   * :doc:`hybrid/scaled (o) <pair_hybrid>`
    * :doc:`kim <pair_kim>`
    * :doc:`list <pair_list>`
    * :doc:`tracker <pair_tracker>`
    *
    *
    *
-   *
    * :doc:`adp (ko) <pair_adp>`
    * :doc:`agni (o) <pair_agni>`
    * :doc:`aip/water/2dm (t) <pair_aip_water_2dm>`
@@ -87,16 +87,17 @@ OPT.
    * :doc:`coul/long/soft (o) <pair_fep_soft>`
    * :doc:`coul/msm (o) <pair_coul>`
    * :doc:`coul/slater/cut <pair_coul_slater>`
-   * :doc:`coul/slater/long <pair_coul_slater>`
+   * :doc:`coul/slater/long (g) <pair_coul_slater>`
    * :doc:`coul/shield <pair_coul_shield>`
    * :doc:`coul/streitz <pair_coul>`
    * :doc:`coul/tt <pair_coul_tt>`
    * :doc:`coul/wolf (ko) <pair_coul>`
    * :doc:`coul/wolf/cs <pair_cs>`
    * :doc:`dpd (giko) <pair_dpd>`
-   * :doc:`dpd/fdt <pair_dpd_fdt>`
+   * :doc:`dpd/coul/slater/long (g) <pair_dpd_coul_slater_long>`
    * :doc:`dpd/ext (ko) <pair_dpd_ext>`
    * :doc:`dpd/ext/tstat (ko) <pair_dpd_ext>`
+   * :doc:`dpd/fdt <pair_dpd_fdt>`
    * :doc:`dpd/fdt/energy (k) <pair_dpd_fdt>`
    * :doc:`dpd/tstat (gko) <pair_dpd>`
    * :doc:`dsmc <pair_dsmc>`
@@ -110,7 +111,7 @@ OPT.
    * :doc:`eam/he <pair_eam>`
    * :doc:`edip (o) <pair_edip>`
    * :doc:`edip/multi <pair_edip>`
-   * :doc:`edpd <pair_mesodpd>`
+   * :doc:`edpd (g) <pair_mesodpd>`
    * :doc:`eff/cut <pair_eff>`
    * :doc:`eim (o) <pair_eim>`
    * :doc:`exp6/rx (k) <pair_exp6_rx>`
@@ -146,7 +147,7 @@ OPT.
    * :doc:`lj/charmm/coul/long/soft (o) <pair_fep_soft>`
    * :doc:`lj/charmm/coul/msm (o) <pair_charmm>`
    * :doc:`lj/charmmfsw/coul/charmmfsh <pair_charmm>`
-   * :doc:`lj/charmmfsw/coul/long <pair_charmm>`
+   * :doc:`lj/charmmfsw/coul/long (k) <pair_charmm>`
    * :doc:`lj/class2 (gko) <pair_class2>`
    * :doc:`lj/class2/coul/cut (ko) <pair_class2>`
    * :doc:`lj/class2/coul/cut/soft <pair_fep_soft>`
@@ -158,14 +159,14 @@ OPT.
    * :doc:`lj/cut (gikot) <pair_lj>`
    * :doc:`lj/cut/coul/cut (gko) <pair_lj_cut_coul>`
    * :doc:`lj/cut/coul/cut/dielectric (o) <pair_dielectric>`
-   * :doc:`lj/cut/coul/cut/soft (o) <pair_fep_soft>`
+   * :doc:`lj/cut/coul/cut/soft (go) <pair_fep_soft>`
    * :doc:`lj/cut/coul/debye (gko) <pair_lj_cut_coul>`
    * :doc:`lj/cut/coul/debye/dielectric (o) <pair_dielectric>`
    * :doc:`lj/cut/coul/dsf (gko) <pair_lj_cut_coul>`
    * :doc:`lj/cut/coul/long (gikot) <pair_lj_cut_coul>`
    * :doc:`lj/cut/coul/long/cs <pair_cs>`
    * :doc:`lj/cut/coul/long/dielectric (o) <pair_dielectric>`
-   * :doc:`lj/cut/coul/long/soft (o) <pair_fep_soft>`
+   * :doc:`lj/cut/coul/long/soft (go) <pair_fep_soft>`
    * :doc:`lj/cut/coul/msm (go) <pair_lj_cut_coul>`
    * :doc:`lj/cut/coul/msm/dielectric <pair_dielectric>`
    * :doc:`lj/cut/coul/wolf (o) <pair_lj_cut_coul>`
@@ -202,7 +203,7 @@ OPT.
    * :doc:`lubricate/poly (o) <pair_lubricate>`
    * :doc:`lubricateU <pair_lubricateU>`
    * :doc:`lubricateU/poly <pair_lubricateU>`
-   * :doc:`mdpd <pair_mesodpd>`
+   * :doc:`mdpd (g) <pair_mesodpd>`
    * :doc:`mdpd/rhosum <pair_mesodpd>`
    * :doc:`meam (k) <pair_meam>`
    * :doc:`meam/ms (k) <pair_meam>`
@@ -245,7 +246,8 @@ OPT.
    * :doc:`oxrna2/coaxstk <pair_oxrna2>`
    * :doc:`pace (k) <pair_pace>`
    * :doc:`pace/extrapolation (k) <pair_pace>`
-   * :doc:`pod <pair_pod>`
+   * :doc:`pedone (o) <pair_pedone>`
+   * :doc:`pod (k) <pair_pod>`
    * :doc:`peri/eps <pair_peri>`
    * :doc:`peri/lps (o) <pair_peri>`
    * :doc:`peri/pmb (o) <pair_peri>`
@@ -256,6 +258,7 @@ OPT.
    * :doc:`rann <pair_rann>`
    * :doc:`reaxff (ko) <pair_reaxff>`
    * :doc:`rebo (io) <pair_airebo>`
+   * :doc:`rebomos (o) <pair_rebomos>`
    * :doc:`resquared (go) <pair_resquared>`
    * :doc:`saip/metal (t) <pair_saip_metal>`
    * :doc:`sdpd/taitwater/isothermal <pair_sdpd_taitwater_isothermal>`
@@ -267,12 +270,12 @@ OPT.
    * :doc:`smd/ulsph <pair_smd_ulsph>`
    * :doc:`smtbq <pair_smtbq>`
    * :doc:`snap (ik) <pair_snap>`
-   * :doc:`soft (go) <pair_soft>`
-   * :doc:`sph/heatconduction <pair_sph_heatconduction>`
+   * :doc:`soft (gko) <pair_soft>`
+   * :doc:`sph/heatconduction (g) <pair_sph_heatconduction>`
    * :doc:`sph/idealgas <pair_sph_idealgas>`
-   * :doc:`sph/lj <pair_sph_lj>`
+   * :doc:`sph/lj (g) <pair_sph_lj>`
    * :doc:`sph/rhosum <pair_sph_rhosum>`
-   * :doc:`sph/taitwater <pair_sph_taitwater>`
+   * :doc:`sph/taitwater (g) <pair_sph_taitwater>`
    * :doc:`sph/taitwater/morris <pair_sph_taitwater_morris>`
    * :doc:`spin/dipole/cut <pair_spin_dipole>`
    * :doc:`spin/dipole/long <pair_spin_dipole>`
@@ -301,6 +304,7 @@ OPT.
    * :doc:`tip4p/long/soft (o) <pair_fep_soft>`
    * :doc:`tri/lj <pair_tri_lj>`
    * :doc:`ufm (got) <pair_ufm>`
+   * :doc:`uf3 (k) <pair_uf3>`
    * :doc:`vashishta (gko) <pair_vashishta>`
    * :doc:`vashishta/table (o) <pair_vashishta>`
    * :doc:`wf/cut <pair_wf_cut>`

doc/src/Commands_removed.rst

@@ -126,6 +126,17 @@ syntax compatible with the removed reax pair style, so input files will
 have to be adapted.  The REAXFF package was originally called
 USER-REAXC.
 
+USER-REAXC package
+------------------
+
+.. deprecated:: 7Feb2024
+
+The USER-REAXC package has been renamed to :ref:`REAXFF <PKG-REAXFF>`.
+In the process also the pair style and related fixes were renamed to use
+the "reaxff" string instead of "reax/c". For a while LAMMPS was maintaining
+backward compatibility by providing aliases for the styles.  These have
+been removed, so using "reaxff" is now *required*.
+
 USER-CUDA package
 -----------------
 
@@ -137,6 +148,14 @@ performance characteristics on NVIDIA GPUs. Both, the KOKKOS
 and the :ref:`GPU package <PKG-GPU>` are maintained
 and allow running LAMMPS with GPU acceleration.
 
+i-PI tool
+---------
+
+.. versionchanged:: 27June2024
+
+The i-PI tool has been removed from the LAMMPS distribution.  Instead,
+instructions to install i-PI from PyPI via pip are provided.
+
 restart2data tool
 -----------------
 

doc/src/Developer_platform.rst

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

doc/src/Developer_unittest.rst

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

doc/src/Developer_updating.rst

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

doc/src/Developer_utils.rst

@@ -211,6 +211,9 @@ Argument processing
 .. doxygenfunction:: bounds
    :project: progguide
 
+.. doxygenfunction:: bounds_typelabel
+   :project: progguide
+
 .. doxygenfunction:: expand_args
    :project: progguide
 
@@ -635,10 +638,10 @@ Tohoku University (under MIT license)
 
 ----------
 
-.. doxygenfunction:: MathEigen::jacobi3(double const *const *mat, double *eval, double **evec)
+.. doxygenfunction:: MathEigen::jacobi3(double const *const *mat, double *eval, double **evec, int sort)
    :project: progguide
 
-.. doxygenfunction:: MathEigen::jacobi3(double const mat[3][3], double *eval, double evec[3][3])
+.. doxygenfunction:: MathEigen::jacobi3(double const mat[3][3], double *eval, double evec[3][3], int sort)
    :project: progguide
 
 ---------------------------

doc/src/Errors_details.rst

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

doc/src/Errors_messages.rst

@@ -7883,12 +7883,6 @@ keyword to allow for additional bonds to be formed
    Fix poems cannot (yet) work with coupled bodies whose joints connect
    the bodies in a tree structure.
 
-*Triclinic box skew is too large*
-   The displacement in a skewed direction must be less than half the box
-   length in that dimension.  E.g. the xy tilt must be between -half and
-   +half of the x box length.  This constraint can be relaxed by using
-   the box tilt command.
-
 *Tried to convert a double to int, but input_double > INT_MAX*
    Self-explanatory.
 

doc/src/Errors_warnings.rst

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

doc/src/Fortran.rst

@@ -305,6 +305,8 @@ of the contents of the :f:mod:`LIBLAMMPS` Fortran interface to LAMMPS.
    :ftype extract_setting: function
    :f extract_global: :f:func:`extract_global`
    :ftype extract_global: function
+   :f map_atom: :f:func:`map_atom`
+   :ftype map_atom: function
    :f extract_atom: :f:func:`extract_atom`
    :ftype extract_atom: function
    :f extract_compute: :f:func:`extract_compute`
@@ -315,6 +317,10 @@ of the contents of the :f:mod:`LIBLAMMPS` Fortran interface to LAMMPS.
    :ftype extract_variable: function
    :f set_variable: :f:subr:`set_variable`
    :ftype set_variable: subroutine
+   :f set_string_variable: :f:subr:`set_set_string_variable`
+   :ftype set_string_variable: subroutine
+   :f set_internal_variable: :f:subr:`set_internal_variable`
+   :ftype set_internal_variable: subroutine
    :f gather_atoms: :f:subr:`gather_atoms`
    :ftype gather_atoms: subroutine
    :f gather_atoms_concat: :f:subr:`gather_atoms_concat`
@@ -1251,8 +1257,8 @@ Procedures Bound to the :f:type:`lammps` Derived Type
    three elements of the global vector calculated by fix recenter into the
    variables *dx*, *dy*, and *dz*, respectively.
 
-   If asked for per-atom or local data, :f:func:`extract_compute` returns a
-   pointer to actual LAMMPS data. The pointer so returned will have the
+   If asked for per-atom or local data, :f:func:`extract_fix` returns a
+   pointer to actual LAMMPS data.  The pointer returned will have the
    appropriate size to match the internal data, and will be
    type/kind/rank-checked at the time of the assignment. For example,
 
@@ -1398,7 +1404,28 @@ Procedures Bound to the :f:type:`lammps` Derived Type
 
    Set the value of a string-style variable.
 
-   .. versionadded:: 3Nov2022
+   .. deprecated:: 7Feb2024
+
+   This function assigns a new value from the string *str* to the string-style
+   variable *name*\ . If *name* does not exist or is not a string-style
+   variable, an error is generated.
+
+   .. warning::
+
+      This subroutine is deprecated and :f:subr:`set_string_variable`
+      should be used instead.
+
+   :p character(len=*) name: name of the variable
+   :p character(len=*) str:  new value to assign to the variable
+   :to: :cpp:func:`lammps_set_variable`
+
+--------
+
+.. f:subroutine:: set_string_variable(name, str)
+
+   Set the value of a string-style variable.
+
+   .. versionadded:: 7Feb2024
 
    This function assigns a new value from the string *str* to the string-style
    variable *name*\ . If *name* does not exist or is not a string-style
@@ -1406,7 +1433,23 @@ Procedures Bound to the :f:type:`lammps` Derived Type
 
    :p character(len=*) name: name of the variable
    :p character(len=*) str:  new value to assign to the variable
-   :to: :cpp:func:`lammps_set_variable`
+   :to: :cpp:func:`lammps_set_string_variable`
+
+--------
+
+.. f:subroutine:: set_internal_variable(name, val)
+
+   Set the value of a internal-style variable.
+
+   .. versionadded:: 7Feb2024
+
+   This function assigns a new value from the floating-point number *val* to
+   the internal-style variable *name*\ . If *name* does not exist or is not
+   an internal-style variable, an error is generated.
+
+   :p character(len=*) name: name of the variable
+   :p read(c_double) val:  new value to assign to the variable
+   :to: :cpp:func:`lammps_set_internal_variable`
 
 --------
 
@@ -3038,14 +3081,6 @@ Procedures Bound to the :f:type:`lammps` Derived Type
    This function can be used to query if an error inside of LAMMPS
    has thrown a :ref:`C++ exception <exceptions>`.
 
-   .. note::
-
-      This function will always report "no error" when the LAMMPS library
-      has been compiled without ``-DLAMMPS_EXCEPTIONS``, which turns fatal
-      errors aborting LAMMPS into C++ exceptions. You can use the library
-      function :cpp:func:`lammps_config_has_exceptions` to check if this is
-      the case.
-
    :to: :cpp:func:`lammps_has_error`
    :r has_error: ``.TRUE.`` if there is an error.
    :rtype has_error: logical
@@ -3068,13 +3103,6 @@ Procedures Bound to the :f:type:`lammps` Derived Type
    would happen only in a single MPI rank and thus may not be recoverable, as
    other MPI ranks may be waiting on the failing MPI rank(s) to send messages.
 
-   .. note::
-
-      This function will do nothing when the LAMMPS library has been
-      compiled without ``-DLAMMPS_EXCEPTIONS``, which turns errors aborting
-      LAMMPS into C++ exceptions.  You can use the function
-      :f:func:`config_has_exceptions` to check whether this is the case.
-
    :p character(len=\*) buffer: string buffer to copy the error message into
    :o integer(c_int) status [optional]: 1 when all ranks had the error,
     2 on a single-rank error.

doc/src/Howto.rst

@@ -101,6 +101,7 @@ Tutorials howto
    Howto_cmake
    Howto_github
    Howto_lammps_gui
+   Howto_moltemplate
    Howto_pylammps
    Howto_wsl
 

doc/src/Howto_2d.rst

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

doc/src/Howto_bioFF.rst

@@ -1,6 +1,10 @@
 CHARMM, AMBER, COMPASS, and DREIDING force fields
 =================================================
 
+A compact summary of the concepts, definitions, and properties of
+force fields with explicit bonded interactions (like the ones discussed
+in this HowTo) is given in :ref:`(Gissinger) <Typelabel2>`.
+
 A force field has 2 parts: the formulas that define it and the
 coefficients used for a particular system.  Here we only discuss
 formulas implemented in LAMMPS that correspond to formulas commonly used
@@ -11,12 +15,42 @@ commands like :doc:`pair_coeff <pair_coeff>` or :doc:`bond_coeff
 <bond_coeff>` and so on.  See the :doc:`Tools <Tools>` doc page for
 additional tools that can use CHARMM, AMBER, or Materials Studio
 generated files to assign force field coefficients and convert their
-output into LAMMPS input.
+output into LAMMPS input. LAMMPS input scripts can also be generated by
+`charmm-gui.org <https://charmm-gui.org/>`_.
 
-See :ref:`(MacKerell) <howto-MacKerell>` for a description of the CHARMM
-force field.  See :ref:`(Cornell) <howto-Cornell>` for a description of
-the AMBER force field.  See :ref:`(Sun) <howto-Sun>` for a description
-of the COMPASS force field.
+CHARMM and AMBER
+----------------
+
+The `CHARMM force field
+<https://mackerell.umaryland.edu/charmm_ff.shtml>`_ :ref:`(MacKerell)
+<howto-MacKerell>` and `AMBER force field
+<https://ambermd.org/AmberModels.php>`_ :ref:`(Cornell) <howto-Cornell>`
+have potential energy function of the form
+
+.. math::
+
+  V & = \sum_{bonds} E_b + \sum_{angles} \!E_a + \!\overbrace{\sum_{dihedral} \!\!E_d}^{\substack{
+         \text{charmm} \\
+        \text{charmmfsw}
+      }} +\!\!\! \sum_{impropers} \!\!\!E_i \\[.6em]
+      & \quad + \!\!\!\!\!\!\!\!\!\!\underbrace{~\sum_{pairs} \left(E_{LJ}+E_{coul}\right)}_{\substack{
+         \text{lj/charmm/coul/charmm} \\
+        \text{lj/charmm/coul/charmm/implicit} \\
+        \text{lj/charmm/coul/long} \\
+        \text{lj/charmm/coul/msm} \\
+         \text{lj/charmmfsw/coul/charmmfsh} \\
+        \text{lj/charmmfsw/coul/long}
+      }} \!\!\!\!\!\!\!\!+ \!\!\sum_{special}\! E_s + \!\!\!\!\sum_{residues} \!\!\!{\scriptstyle\mathrm{CMAP}(\phi,\psi)}
+
+
+The terms are computed by bond styles (relationship between 2 atoms),
+angle styles (between 3 atoms) , dihedral/improper styles (between 4
+atoms), pair styles (non-covalently bonded pair interactions) and
+special bonds. The CMAP term (see :doc:`fix cmap <fix_cmap>` command for
+details) corrects for pairs of dihedral angles ("Correction MAP") to
+significantly improve the structural and dynamic properties of proteins
+in crystalline and solution environments :ref:`(Brooks)
+<howto-Brooks>`. The AMBER force field does not include the CMAP term.
 
 The interaction styles listed below compute force field formulas that
 are consistent with common options in CHARMM or AMBER.  See each
@@ -31,10 +65,81 @@ command's documentation for the formula it computes.
 * :doc:`pair_style <pair_charmm>` lj/charmm/coul/charmm
 * :doc:`pair_style <pair_charmm>` lj/charmm/coul/charmm/implicit
 * :doc:`pair_style <pair_charmm>` lj/charmm/coul/long
-
 * :doc:`special_bonds <special_bonds>` charmm
 * :doc:`special_bonds <special_bonds>` amber
 
+The pair styles compute Lennard Jones (LJ) and Coulombic interactions
+with additional switching or shifting functions that ramp the energy
+and/or force smoothly to zero between an inner :math:`(a)` and outer
+:math:`(b)` cutoff. The older styles with *charmm* (not *charmmfsw* or
+*charmmfsh*\ ) in their name compute the LJ and Coulombic interactions
+with an energy switching function (esw) S(r) which ramps the energy
+smoothly to zero between the inner and outer cutoff. This can cause
+irregularities in pairwise forces (due to the discontinuous second
+derivative of energy at the boundaries of the switching region), which
+in some cases can result in complications in energy minimization and
+detectable artifacts in MD simulations.
+
+.. grid:: 1 1 2 2
+
+   .. grid-item::
+
+      .. math::
+
+         LJ(r) &= 4 \epsilon \left[ \left(\frac{\sigma}{r}\right)^{12} -
+                  \left(\frac{\sigma}{r}\right)^6 \right]\\[.6em]
+         C(r) &= \frac{C q_i q_j}{ \epsilon r}\\[.6em]
+         S(r) &=  \frac{ \left(b^2 - r^2\right)^2 \left(b^2 + 2r^2 - 3{a^2}\right)}
+                 { \left(b^2 - a^2\right)^3 }\\[.6em]
+         E_{LJ}(r) &=  \begin{cases}
+           LJ(r), & r \leq a \\
+           LJ(r) S(r), & a < r \leq b \\
+           0, &r > b
+         \end{cases} \\[.6em]
+         E_{coul}(r) &=  \begin{cases}
+           C(r), & r \leq a \\
+           C(r) S(r), & a < r \leq b \\
+           0, & r > b
+         \end{cases}
+
+   .. grid-item::
+
+      .. image:: img/howto_charmm_ELJ.png
+         :align: center
+
+The newer styles with *charmmfsw* or *charmmfsh* in their name replace
+energy switching with force switching (fsw) for LJ interactions and
+force shifting (fsh) functions for Coulombic interactions
+:ref:`(Steinbach) <howto-Steinbach>`
+
+.. grid:: 1 1 2 2
+
+   .. grid-item::
+
+      .. math::
+
+           E_{LJ}(r) = & \begin{cases}
+       4  \epsilon \sigma^6  \left(\frac{\displaystyle\sigma
+         ^6-r^6}{\displaystyle r^{12}}-\frac{\displaystyle\sigma ^6}{\displaystyle a^6
+         b^6}+\frac{\displaystyle 1}{\displaystyle a^3 b^3}\right) & r\leq a \\
+       \frac{\displaystyle 4 \epsilon \sigma^6   \left(\sigma ^6
+         \left(b^6-r^6\right)^2-b^3 r^6 \left(a^3+b^3\right)
+         \left(b^3-r^3\right)^2\right)}{\displaystyle b^6 r^{12}
+         \left(b^6-a^6\right)} & a<r \leq b\\
+         0, & r>b
+        \end{cases}\\[.6em]
+         E_{coul}(r) & =  \begin{cases}
+              C(r) \frac{\displaystyle (b-r)^2}{\displaystyle r b^2}, &  r \leq b \\
+              0, & r > b
+            \end{cases}
+
+   .. grid-item::
+      .. image:: img/howto_charmmfsw_ELJ.png
+         :align: center
+
+These styles are used by LAMMPS input scripts generated by
+https://charmm-gui.org/ :ref:`(Brooks) <howto-Brooks>`.
+
 .. note::
 
    For CHARMM, newer *charmmfsw* or *charmmfsh* styles were released in
@@ -43,17 +148,33 @@ command's documentation for the formula it computes.
    <pair_charmm>` and :doc:`dihedral charmm <dihedral_charmm>` doc
    pages.
 
+.. note::
+
+  The TIP3P water model is strongly recommended for use with the CHARMM
+  force field. In fact, `"using the SPC model with CHARMM parameters is
+  a bad idea"
+  <https://matsci.org/t/using-spc-water-with-charmm-ff/24715>`_ and `"to
+  enable TIP4P style water in CHARMM, you would have to write a new pair
+  style"
+  <https://matsci.org/t/hybrid-pair-styles-for-charmm-and-tip4p-ew/32609>`_
+  . LAMMPS input scripts generated by Solution Builder on https://charmm-gui.org
+  use TIP3P molecules for solvation.  Any other water model can and
+  probably will lead to false conclusions.
+
+COMPASS
+-------
+
 COMPASS is a general force field for atomistic simulation of common
 organic molecules, inorganic small molecules, and polymers which was
-developed using ab initio and empirical parameterization techniques.
-See the :doc:`Tools <Tools>` page for the msi2lmp tool for creating
-LAMMPS template input and data files from BIOVIA's Materials Studio
-files.  Please note that the msi2lmp tool is very old and largely
-unmaintained, so it does not support all features of Materials Studio
-provided force field files, especially additions during the last decade.
-You should watch the output carefully and compare results, where
-possible.  See :ref:`(Sun) <howto-Sun>` for a description of the COMPASS force
-field.
+developed using ab initio and empirical parameterization techniques
+:ref:`(Sun) <howto-Sun>`.  See the :doc:`Tools <Tools>` page for the
+msi2lmp tool for creating LAMMPS template input and data files from
+BIOVIA's Materials Studio files.  Please note that the msi2lmp tool is
+very old and largely unmaintained, so it does not support all features
+of Materials Studio provided force field files, especially additions
+during the last decade.  You should watch the output carefully and
+compare results, where possible.  See :ref:`(Sun) <howto-Sun>` for a
+description of the COMPASS force field.
 
 These interaction styles listed below compute force field formulas that
 are consistent with the COMPASS force field.  See each command's
@@ -70,14 +191,21 @@ documentation for the formula it computes.
 
 * :doc:`special_bonds <special_bonds>` lj/coul 0 0 1
 
-DREIDING is a generic force field developed by the `Goddard group <http://www.wag.caltech.edu>`_ at Caltech and is useful for
-predicting structures and dynamics of organic, biological and main-group
-inorganic molecules. The philosophy in DREIDING is to use general force
-constants and geometry parameters based on simple hybridization
-considerations, rather than individual force constants and geometric
-parameters that depend on the particular combinations of atoms involved
-in the bond, angle, or torsion terms. DREIDING has an :doc:`explicit hydrogen bond term <pair_hbond_dreiding>` to describe interactions involving a
-hydrogen atom on very electronegative atoms (N, O, F).
+DREIDING
+--------
+
+DREIDING is a generic force field developed by the `Goddard group
+<http://www.wag.caltech.edu>`_ at Caltech and is useful for predicting
+structures and dynamics of organic, biological and main-group inorganic
+molecules.  The philosophy in DREIDING is to use general force constants
+and geometry parameters based on simple hybridization considerations,
+rather than individual force constants and geometric parameters that
+depend on the particular combinations of atoms involved in the bond,
+angle, or torsion terms.  DREIDING has an :doc:`explicit hydrogen bond
+term <pair_hbond_dreiding>` to describe interactions involving a
+hydrogen atom on very electronegative atoms (N, O, F).  Unlike CHARMM
+or AMBER, the DREIDING force field has not been parameterized for
+considering solvents (like water).
 
 See :ref:`(Mayo) <howto-Mayo>` for a description of the DREIDING force field
 
@@ -110,21 +238,31 @@ documentation for the formula it computes.
 
 ----------
 
+.. _Typelabel2:
+
+**(Gissinger)** J. R. Gissinger, I. Nikiforov, Y. Afshar, B. Waters, M. Choi, D. S. Karls, A. Stukowski, W. Im, H. Heinz, A. Kohlmeyer, and E. B. Tadmor, J Phys Chem B, 128, 3282-3297 (2024).
+
 .. _howto-MacKerell:
 
-**(MacKerell)** MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field,
-Fischer, Gao, Guo, Ha, et al, J Phys Chem, 102, 3586 (1998).
+**(MacKerell)** MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field, Fischer, Gao, Guo, Ha, et al (1998).  J Phys Chem, 102, 3586 . https://doi.org/10.1021/jp973084f
 
 .. _howto-Cornell:
 
-**(Cornell)** Cornell, Cieplak, Bayly, Gould, Merz, Ferguson,
-Spellmeyer, Fox, Caldwell, Kollman, JACS 117, 5179-5197 (1995).
+**(Cornell)** Cornell, Cieplak, Bayly, Gould, Merz, Ferguson, Spellmeyer, Fox, Caldwell, Kollman (1995).  JACS 117, 5179-5197. https://doi.org/10.1021/ja00124a002
+
+.. _howto-Steinbach:
+
+**(Steinbach)** Steinbach, Brooks (1994). J Comput Chem, 15, 667. https://doi.org/10.1002/jcc.540150702
+
+.. _howto-Brooks:
+
+**(Brooks)** Brooks, et al (2009). J Comput Chem, 30, 1545. https://onlinelibrary.wiley.com/doi/10.1002/jcc.21287
 
 .. _howto-Sun:
 
-**(Sun)** Sun, J. Phys. Chem. B, 102, 7338-7364 (1998).
+**(Sun)** Sun (1998). J. Phys. Chem. B, 102, 7338-7364. https://doi.org/10.1021/jp980939v
 
 .. _howto-Mayo:
 
-**(Mayo)** Mayo, Olfason, Goddard III, J Phys Chem, 94, 8897-8909
-(1990).
+**(Mayo)** Mayo, Olfason, Goddard III (1990). J Phys Chem, 94, 8897-8909. https://doi.org/10.1021/j100389a010
+

doc/src/Howto_body.rst

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

doc/src/Howto_bpm.rst

@@ -15,7 +15,8 @@ orientation for rotational models. This produces a stress-free initial
 state. Furthermore, bonds are allowed to break under large strains,
 producing fracture. The examples/bpm directory has sample input scripts
 for simulations of the fragmentation of an impacted plate and the
-pouring of extended, elastic bodies.
+pouring of extended, elastic bodies. See :ref:`(Clemmer) <howto-Clemmer>`
+for more general information on the approach and the LAMMPS implementation.
 
 ----------
 
@@ -150,3 +151,9 @@ the following are currently compatible with BPM bond styles:
    interactions, one will need to switch between different *special_bonds*
    settings in the input script. An example is found in
    ``examples/bpm/impact``.
+
+----------
+
+.. _howto-Clemmer:
+
+**(Clemmer)** Clemmer, Monti, Lechman, Soft Matter, 20, 1702 (2024).

doc/src/Howto_cmake.rst

@@ -349,6 +349,8 @@ Some common LAMMPS specific variables
      - when set to ``name`` the LAMMPS executable and library will be called ``lmp_name`` and ``liblammps_name.a``
    * - ``FFT``
      - select which FFT library to use: ``FFTW3``, ``MKL``, ``KISS`` (default, unless FFTW3 is found)
+   * - ``FFT_KOKKOS``
+     - select which FFT library to use in Kokkos-enabled styles: ``FFTW3``, ``MKL``, ``HIPFFT``, ``CUFFT``, ``KISS`` (default)
    * - ``FFT_SINGLE``
      - select whether to use single precision FFTs (default: ``off``)
    * - ``WITH_JPEG``

doc/src/Howto_github.rst

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

doc/src/Howto_granular.rst

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

doc/src/Howto_moltemplate.rst

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

doc/src/Howto_structured_data.rst

@@ -52,8 +52,8 @@ JSON
      "ke": 2.4962152903997174569
    }
 
-YAML format thermo_style output
-===============================
+YAML format thermo_style or dump_style output
+=============================================
 
 Extracting data from log file
 -----------------------------
@@ -112,6 +112,9 @@ of that run:
    Number of runs:  2
    TotEng  =  -4.62140097780047
 
+Extracting data from dump file
+------------------------------
+
 .. versionadded:: 4May2022
 
 YAML format output has been added to multiple commands in LAMMPS,

doc/src/Howto_tip4p.rst

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

doc/src/Howto_tip5p.rst

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

doc/src/Howto_triclinic.rst

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

doc/src/Howto_type_labels.rst

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

doc/src/Install_git.rst

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

doc/src/Intro_citing.rst

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

doc/src/Intro_features.rst

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

doc/src/Library.rst

@@ -80,13 +80,15 @@ run LAMMPS in serial mode.
    :class: note
 
    If the LAMMPS executable encounters an error condition, it will abort
-   after printing an error message. For a library interface this is
-   usually not desirable.  Thus LAMMPS can be compiled to to :ref:`throw
-   a C++ exception <exceptions>` instead.  If enabled, the library
-   functions will catch those exceptions and return.  The error status
-   :cpp:func:`can be queried <lammps_has_error>` and an :cpp:func:`error
-   message retrieved <lammps_get_last_error_message>`.  We thus
-   recommend enabling C++ exceptions when using the library interface,
+   after printing an error message.  It does so by catching the
+   exceptions that LAMMPS could throw.  For a C library interface this
+   is usually not desirable since the calling code might lack the
+   ability to catch such exceptions.  Thus, the library functions will
+   catch those exceptions and return from the affected functions.  The
+   error status :cpp:func:`can be queried <lammps_has_error>` and an
+   :cpp:func:`error message retrieved <lammps_get_last_error_message>`.
+   This is, for example used by the :doc:`LAMMPS python module
+   <Python_module>` and then a suitable Python exception is thrown.
 
 .. admonition:: Using the C library interface as a plugin
    :class: note

doc/src/Library_objects.rst

@@ -9,6 +9,8 @@ fixes, or variables in LAMMPS using the following functions:
 - :cpp:func:`lammps_extract_variable_datatype`
 - :cpp:func:`lammps_extract_variable`
 - :cpp:func:`lammps_set_variable`
+- :cpp:func:`lammps_set_string_variable`
+- :cpp:func:`lammps_set_internal_variable`
 - :cpp:func:`lammps_variable_info`
 
 -----------------------
@@ -38,6 +40,16 @@ fixes, or variables in LAMMPS using the following functions:
 
 -----------------------
 
+.. doxygenfunction:: lammps_set_string_variable
+   :project: progguide
+
+-----------------------
+
+.. doxygenfunction:: lammps_set_internal_variable
+   :project: progguide
+
+-----------------------
+
 .. doxygenfunction:: lammps_variable_info
    :project: progguide
 

doc/src/Library_properties.rst

@@ -13,6 +13,7 @@ This section documents the following functions:
 - :cpp:func:`lammps_extract_setting`
 - :cpp:func:`lammps_extract_global_datatype`
 - :cpp:func:`lammps_extract_global`
+- :cpp:func:`lammps_map_atom`
 
 --------------------
 
@@ -120,3 +121,8 @@ subdomains and processors.
 .. doxygenfunction:: lammps_extract_global
    :project: progguide
 
+-----------------------
+
+.. doxygenfunction:: lammps_map_atom
+   :project: progguide
+

doc/src/Manual_version.rst

@@ -3,45 +3,25 @@ What does a LAMMPS version mean
 
 The LAMMPS "version" is the date when it was released, such as 1 May
 2014.  LAMMPS is updated continuously, and we aim to keep it working
-correctly and reliably at all times.  You can follow its development
-in a public `git repository on GitHub <https://github.com/lammps/lammps>`_.
-
-Modifications of the LAMMPS source code (like bug fixes, code refactors,
-updates to existing features, or addition of new features) are organized
-into pull requests.  Pull requests will be merged into the *develop*
-branch of the git repository after they pass automated testing and code
-review by the LAMMPS developers.  When a sufficient number of changes
-have accumulated *and* the *develop* branch version passes an extended
-set of automated tests, we release it as a *feature release*, 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*
-branch.  At the same time, the code is subjected to more detailed and
-thorough manual testing than the default automated testing.  Also,
-several variants of static code analysis are run to improve the overall
-code quality, consistency, and compliance with programming standards,
-best practices and style conventions.
-
-The 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.
+correctly and reliably at all times.  Also, several variants of static
+code analysis are run regularly to maintain or improve the overall code
+quality, consistency, and compliance with programming standards, best
+practices and style conventions.  You can follow its development in a
+public `git repository on GitHub <https://github.com/lammps/lammps>`_.
 
 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.
 
-The version date is printed to the screen and log file every time you run
-LAMMPS.  It is also in the file src/version.h and in the LAMMPS
-directory name created when you unpack a tarball.  And it is on the
+Identifying the Version
+^^^^^^^^^^^^^^^^^^^^^^^
+
+The version date is printed to the screen and log file every time you
+run LAMMPS.  There also is an indication, if a LAMMPS binary was
+compiled from version with modifications **after** a release.
+It is also visible in the file src/version.h and in the LAMMPS directory
+name created when you unpack a downloaded 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
@@ -53,3 +33,56 @@ first page of the :doc:`manual <Manual>`.
 * If you browse the HTML pages included in your downloaded tarball, they
   describe the version you have, which may be older than the online
   version.
+
+LAMMPS releases, branches, and tags
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. figure:: JPG/lammps-releases.png
+   :figclass: align-center
+
+   Relations between releases, main branches, and tags in the LAMMPS git repository
+
+Development
+"""""""""""
+
+Modifications of the LAMMPS source code (like bug fixes, code
+refactoring, updates to existing features, or addition of new features)
+are organized into pull requests.  Pull requests will be merged into the
+*develop* branch of the git repository after they pass automated testing
+and code review by the LAMMPS developers.
+
+Feature Releases
+""""""""""""""""
+
+When a sufficient number of new features and updates have accumulated
+*and* the LAMMPS version on the *develop* branch passes an extended 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 *feature release* and a tag in the
+format ``patch_1May2014`` is added.  A summary of the most important
+changes of these releases for the current year are posted on `this
+website page <https://www.lammps.org/bug.html>`_.  More detailed release
+notes are `available on GitHub
+<https://github.com/lammps/lammps/releases/>`_.
+
+Stable Releases
+"""""""""""""""
+
+About once a year, we release a *stable release* version of LAMMPS.
+This is done after a "stabilization period" where we apply only bug
+fixes and small, non-intrusive changes to the *develop* branch but no
+new features.  At the same time, the code is subjected to more detailed
+and thorough manual testing than the default automated testing.
+After such a *stable release*, both the *release* and the *stable*
+branches are updated and two tags are applied, a ``patch_1May2014`` format
+and a ``stable_1May2014`` format tag.
+
+Stable Release Updates
+""""""""""""""""""""""
+
+Between *stable releases*, we collect bug fixes and updates back-ported
+from the *develop* branch in a branch called *maintenance*.  From the
+*maintenance* branch we make occasional *stable update releases* and
+update the *stable* branch accordingly.  The first update to the
+``stable_1May2014`` release would be tagged as
+``stable_1May2014_update1``.  These updates contain no new features.

doc/src/Modify_style.rst

@@ -96,6 +96,39 @@ 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.
 
+Constants (strongly preferred)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Global or per-file constants should be declared as `static constexpr`
+variables rather than via the pre-processor with `#define`.  The name of
+constants should be all uppercase.  This has multiple advantages:
+
+- constants are easily identified as such by their all upper case name
+- rather than a pure text substitution during pre-processing, `constexpr
+  variables` have a type associated with them and are processed later in
+  the parsing process where the syntax checks and type specific
+  processing (e.g. via overloads) can be applied to them.
+- compilers can emit a warning if the constant is not used and thus can
+  be removed (we regularly check for and remove dead code like this)
+- there are no unexpected substitutions and thus confusing syntax errors
+  when compiling leading to, for instance, conflicts so that LAMMPS
+  cannot be compiled with certain combinations of packages (this *has*
+  happened multiple times in the past).
+
+Pre-processor defines should be limited to macros (but consider C++
+templates) and conditional compilation.  If a per-processor define must
+be used, it should be defined at the top of the .cpp file after the
+include statements and at all cost it should be avoided to put them into
+header files.
+
+Some sets of commonly used constants are provided in the ``MathConst``
+and ``EwaldConst`` namespaces and implemented in the files
+``math_const.h`` and ``ewald_const.h``, respectively.
+
+There are always exceptions, special cases, and legacy code in LAMMPS,
+so please contact the LAMMPS developers if you are not sure.
+
+
 Placement of braces (strongly preferred)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 

doc/src/Packages_details.rst

@@ -52,6 +52,7 @@ page gives those details.
    * :ref:`DRUDE <PKG-DRUDE>`
    * :ref:`EFF <PKG-EFF>`
    * :ref:`ELECTRODE <PKG-ELECTRODE>`
+   * :ref:`EXTRA-COMMAND <PKG-EXTRA-COMMAND>`
    * :ref:`EXTRA-COMPUTE <PKG-EXTRA-COMPUTE>`
    * :ref:`EXTRA-DUMP <PKG-EXTRA-DUMP>`
    * :ref:`EXTRA-FIX <PKG-EXTRA-FIX>`
@@ -84,6 +85,7 @@ page gives those details.
    * :ref:`ML-QUIP <PKG-ML-QUIP>`
    * :ref:`ML-RANN <PKG-ML-RANN>`
    * :ref:`ML-SNAP <PKG-ML-SNAP>`
+   * :ref:`ML-UF3 <PKG-ML-UF3>`
    * :ref:`MOFFF <PKG-MOFFF>`
    * :ref:`MOLECULE <PKG-MOLECULE>`
    * :ref:`MOLFILE <PKG-MOLFILE>`
@@ -403,6 +405,7 @@ and :ref:`ASPHERE <PKG-ASPHERE>` packages are installed.
 * :doc:`bond_style oxdna2/\* <bond_oxdna>`
 * :doc:`bond_style oxrna2/\* <bond_oxdna>`
 * :doc:`fix nve/dotc/langevin <fix_nve_dotc_langevin>`
+* examples/PACKAGES/cgdna
 
 ----------
 
@@ -676,7 +679,12 @@ DPD-BASIC package
 Pair styles for the basic dissipative particle dynamics (DPD) method
 and DPD thermostatting.
 
-**Author:** Kurt Smith (U Pittsburgh), Martin Svoboda, Martin Lisal (ICPF and UJEP)
+Pair style :doc:`dpd/coul/slater/long <pair_dpd_coul_slater_long>` also
+includes smeared charges for coulomb interactions and thus requires the
+:ref:`KSPACE <PKG-KSPACE>` package to be installed to handle the long-range
+Coulomb part of the interactions.
+
+**Authors:** Kurt Smith (U Pittsburgh), Martin Svoboda, Martin Lisal (ICPF and UJEP), Eddy Barraud (IFPEN)
 
 **Supporting info:**
 
@@ -685,6 +693,7 @@ and DPD thermostatting.
 * :doc:`pair_style dpd/tstat <pair_dpd>`
 * :doc:`pair_style dpd/ext <pair_dpd_ext>`
 * :doc:`pair_style dpd/ext/tstat <pair_dpd_ext>`
+* :doc:`pair_style dpd/coul/slater/long <pair_dpd_coul_slater_long>`
 * examples/PACKAGES/dpd-basic
 
 ----------
@@ -886,6 +895,22 @@ This package has :ref:`specific installation instructions <electrode>` on the
 
 ----------
 
+.. _PKG-EXTRA-COMMAND:
+
+EXTRA-COMMAND package
+---------------------
+
+**Contents:**
+
+Additional command styles that are less commonly used.
+
+**Supporting info:**
+
+* src/EXTRA-COMMAND: filenames -> commands
+* :doc:`general commands <Commands_all>`
+
+----------
+
 .. _PKG-EXTRA-COMPUTE:
 
 EXTRA-COMPUTE package
@@ -1925,6 +1950,31 @@ computes which analyze attributes of the potential.
 
 ----------
 
+.. _PKG-ML-UF3:
+
+ML-UF3 package
+--------------
+
+**Contents:**
+
+A pair style for the ultra-fast force field potentials (UF3). UF3 is a
+methodology for deriving a highly accurate classical potential which is
+fast to evaluate and is fitted to a large archives of quantum mechanical
+(DFT) data.  The use of b-spline basis set in UF3 enables the rapid
+evaluation of 2-body and 3-body interactions.
+
+**Authors:** Ajinkya C Hire (University of Florida),
+Hendrik Krass (University of Constance),
+Matthias Rupp (Luxembourg Institute of Science and Technology),
+Richard Hennig (University of Florida)
+
+**Supporting info:**
+
+* src/ML-UF3: filenames -> commands
+* :doc:`pair_style uf3 <pair_uf3>`
+* examples/uf3
+* https://github.com/uf3/uf3
+
 .. _PKG-MOFFF:
 
 MOFFF package
@@ -2226,7 +2276,7 @@ and third order tensor from finite differences.
 
 **Install:**
 
-The PHONON package requires that also the :ref:`KSPACE <PKG-KSPACE>`
+The fix phonon command also requires that the :ref:`KSPACE <PKG-KSPACE>`
 package is installed.
 
 

doc/src/Packages_list.rst

@@ -158,6 +158,11 @@ whether an extra library is needed to build and use the package:
      - :doc:`fix electrode/conp <fix_electrode>`
      - PACKAGES/electrode
      - no
+   * - :ref:`EXTRA-COMMAND <PKG-EXTRA-COMMAND>`
+     - additional command styles
+     - :doc:`general commands <Commands_all>`
+     - n/a
+     - no
    * - :ref:`EXTRA-COMPUTE <PKG-EXTRA-COMPUTE>`
      - additional compute styles
      - :doc:`compute <compute>`
@@ -318,6 +323,11 @@ whether an extra library is needed to build and use the package:
      - :doc:`pair_style snap <pair_snap>`
      - snap
      - no
+   * - :ref:`ML-UF3 <PKG-ML-UF3>`
+     - quantum-fitted ultra fast potentials
+     - :doc:`pair_style uf3 <pair_uf3>`
+     - PACKAGES/uf3
+     - no
    * - :ref:`MOFFF <PKG-MOFFF>`
      - styles for `MOF-FF <MOFplus_>`_ force field
      - :doc:`pair_style buck6d/coul/gauss <pair_buck6d_coul_gauss>`

doc/src/Python_error.rst

@@ -1,11 +1,11 @@
 Handling LAMMPS errors
 **********************
 
-The shared library is compiled with :ref:`C++ exception support
-<exceptions>` to provide a better error handling experience.  C++
-exceptions allow capturing errors on the C++ side and rethrowing them on
-the Python side.  This way LAMMPS errors can be handled through the
-Python exception handling mechanism.
+LAMMPS and the LAMMPS library are compiled with :ref:`C++ exception support
+<exceptions>` to provide a better error handling experience.  LAMMPS errors
+trigger throwing a C++ exception. These exceptions allow capturing errors on
+the C++ side and rethrowing them on the Python side.  This way LAMMPS errors
+can be handled through the Python exception handling mechanism.
 
 .. code-block:: python
 
@@ -15,9 +15,7 @@ Python exception handling mechanism.
 
    try:
       # LAMMPS will normally terminate itself and the running process if an error
-      # occurs. This would kill the Python interpreter. To avoid this, make sure to
-      # compile with LAMMPS_EXCEPTIONS enabled. This ensures the library API calls
-      # will not terminate the parent process. Instead, the library wrapper will
+      # occurs. This would kill the Python interpreter.  The library wrapper will
       # detect that an error has occured and throw a Python exception
 
       lmp.command('unknown')

doc/src/Python_install.rst

@@ -5,8 +5,7 @@ The LAMMPS Python module enables calling the :ref:`LAMMPS C library API
 <lammps_c_api>` from Python by dynamically loading functions in the
 LAMMPS shared library through the Python `ctypes <ctypes_>`_
 module.  Because of the dynamic loading, it is required that LAMMPS is
-compiled in :ref:`"shared" mode <exe>`.  It is also recommended to
-compile LAMMPS with :ref:`C++ exceptions <exceptions>` enabled.
+compiled in :ref:`"shared" mode <exe>`.
 
 Two components are necessary for Python to be able to invoke LAMMPS code:
 

doc/src/Python_scatter.rst

@@ -54,8 +54,21 @@ like this:
    x[3] = x coord of atom with ID 2
    ...
    x[n3-1] = z coord of atom with ID natoms
-   lmp.scatter_atoms("x",1,3,x)
+   lmp.scatter_atoms("x", 1, 3, x)
+
+The coordinates can also be provided as arguments to the initializer of x:
+
+.. code-block:: python
+
+   from ctypes import c_double
+   natoms = 2
+   n3 = 3*natoms
+   # init in constructor
+   x = (n3*c_double)(0.0, 0.0, 0.0, 1.0, 1.0, 1.0)
+   lmp.scatter_atoms("x", 1, 3, x)
+   # or using a list
+   coords = [1.0, 2.0, 3.0, -3.0, -2.0, -1.0]
+   x = (c_double*len(coords))(*coords)
 
 Alternatively, you can just change values in the vector returned by
 the gather methods, since they are also ctypes vectors.
-

doc/src/Run_output.rst

@@ -49,14 +49,17 @@ simulation.  An example set of statistics is shown here:
 ----------
 
 The first section provides a global loop timing summary. The *loop time*
-is the total wall-clock time for the simulation to run.  The
-*Performance* line is provided for convenience to help predict how long
-it will take to run a desired physical simulation and to have numbers
-useful for performance comparison between different simulation settings
-or system sizes.  The *CPU use* line provides the CPU utilization per
-MPI task; it should be close to 100% times the number of OpenMP threads
-(or 1 of not using OpenMP).  Lower numbers correspond to delays due to
-file I/O or insufficient thread utilization.
+is the total wall-clock time for the MD steps of the simulation run,
+excluding the time for initialization and setup (i.e. the parts that may
+be skipped with :doc:`run N pre no <run>`).  The *Performance* line is
+provided for convenience to help predict how long it will take to run a
+desired physical simulation and to have numbers useful for performance
+comparison between different simulation settings or system sizes.  The
+*CPU use* line provides the CPU utilization per MPI task; it should be
+close to 100% times the number of OpenMP threads (or 1 if not using
+OpenMP).  Lower numbers correspond to delays due to file I/O or
+insufficient thread utilization from parts of the code that have not
+been multi-threaded.
 
 ----------
 

doc/src/Speed_kokkos.rst

@@ -20,11 +20,28 @@ including Sikandar Mashayak (UIUC), Ray Shan (Sandia), and Dan Ibanez
 (Sandia). For more information on developing using Kokkos abstractions
 see the `Kokkos Wiki <https://github.com/kokkos/kokkos/wiki>`_.
 
-Kokkos currently provides support for 4 modes of execution (per MPI
+.. note::
+
+   The Kokkos library is under active development and tracking the
+   availability of accelerator hardware, so is the KOKKOS package in
+   LAMMPS.  This means that only a certain range of versions of the
+   Kokkos library are compatible with the KOKKOS package of a certain
+   range of LAMMPS versions.  For that reason LAMMPS comes with a
+   bundled version of the Kokkos library that has been validated on
+   multiple platforms and may contain selected back-ported bug fixes
+   from upstream Kokkos versions.  While it is possible to build LAMMPS
+   with an external version of Kokkos, it is untested and may result in
+   incorrect execution or crashes.
+
+Kokkos currently provides full support for 4 modes of execution (per MPI
 task). These are Serial (MPI-only for CPUs and Intel Phi), OpenMP
-(threading for many-core CPUs and Intel Phi), CUDA (for NVIDIA
-GPUs) and HIP (for AMD GPUs). You choose the mode at build time to
-produce an executable compatible with a specific hardware.
+(threading for many-core CPUs and Intel Phi), CUDA (for NVIDIA GPUs) and
+HIP (for AMD GPUs).  Additional modes (e.g. OpenMP target, Intel data
+center GPUs) are under development.  You choose the mode at build time
+to produce an executable compatible with a specific hardware.
+
+The following compatibility notes have been last updated for LAMMPS
+version 23 November 2023 and Kokkos version 4.2.
 
 .. admonition:: C++17 support
    :class: note
@@ -54,22 +71,22 @@ produce an executable compatible with a specific hardware.
    :class: note
 
    Kokkos with CUDA currently implicitly assumes that the MPI library is
-   GPU-aware. This is not always the case, especially when using
+   GPU-aware.  This is not always the case, especially when using
    pre-compiled MPI libraries provided by a Linux distribution. This is
    not a problem when using only a single GPU with a single MPI
-   rank. When running with multiple MPI ranks, you may see segmentation
+   rank.  When running with multiple MPI ranks, you may see segmentation
    faults without GPU-aware MPI support. These can be avoided by adding
    the flags :doc:`-pk kokkos gpu/aware off <Run_options>` to the
    LAMMPS command line or by using the command :doc:`package kokkos
    gpu/aware off <package>` in the input file.
 
-.. admonition:: AMD GPU support
+.. admonition:: Intel Data Center GPU support
    :class: note
 
-   To build with Kokkos the HIPCC compiler from the AMD ROCm software
-   version 3.5 or later is required.  Supporting this Kokkos mode in
-   LAMMPS is still work in progress.  Please contact the LAMMPS developers
-   if you run into problems.
+   Support for Kokkos with Intel Data Center GPU accelerators (formerly
+   known under the code name "Ponte Vecchio") in LAMMPS is still a work
+   in progress.  Only a subset of the functionality works correctly.
+   Please contact the LAMMPS developers if you run into problems.
 
 Building LAMMPS with the KOKKOS package
 """""""""""""""""""""""""""""""""""""""
@@ -292,6 +309,10 @@ one or more nodes, each with two GPUs:
    settings. Experimenting with its options can provide a speed-up for
    specific calculations. For example:
 
+.. 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
+
 .. note::
 
    The default binsize for :doc:`atom sorting <atom_modify>` on GPUs
@@ -302,9 +323,15 @@ one or more nodes, each with two GPUs:
    frequent sorting than default (e.g. sorting every 100 time steps
    instead of 1000) may improve performance.
 
-.. code-block:: bash
+.. note::
 
-   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
+   When running on GPUs with many MPI ranks (tens of thousands and
+   more), the creation of the atom map (required for molecular systems)
+   on the GPU can slow down significantly or run out of GPU memory and
+   thus slow down the whole calculation or cause a crash.  You can use
+   the "-pk kokkos atom/map no" :doc:`command-line switch <Run_options>`
+   of the :doc:`package kokkos atom/map no <package>` command to create
+   the atom map on the CPU instead.
 
 .. note::
 
@@ -416,15 +443,22 @@ Generally speaking, the following rules of thumb apply:
   performance of a KOKKOS style is a bit slower than the OPENMP
   package.
 * When running large number of atoms per GPU, KOKKOS is typically faster
-  than the GPU package when compiled for double precision. The benefit
+  than the GPU package when compiled for double precision.  The benefit
   of using single or mixed precision with the GPU package depends
   significantly on the hardware in use and the simulated system and pair
   style.
-* When running on Intel hardware, KOKKOS is not as fast as
+* When running on Intel Phi hardware, KOKKOS is not as fast as
   the INTEL package, which is optimized for x86 hardware (not just
   from Intel) and compilation with the Intel compilers.  The INTEL
   package also can increase the vector length of vector instructions
   by switching to single or mixed precision mode.
+* The KOKKOS package by default assumes that you are using exactly one
+  MPI rank per GPU. When trying to use multiple MPI ranks per GPU it is
+  mandatory to enable `CUDA Multi-Process Service (MPS)
+  <https://docs.nvidia.com/deploy/mps/index.html>`_ to get good
+  performance.  In this case it is better to not use all available
+  MPI ranks in order to avoid competing with the MPS daemon for
+  CPU resources.
 
 See the `Benchmark page <https://www.lammps.org/bench.html>`_ of the
 LAMMPS website for performance of the KOKKOS package on different

doc/src/Tools.rst

@@ -90,7 +90,7 @@ Miscellaneous tools
 
    * :ref:`LAMMPS coding standards <coding_standard>`
    * :ref:`emacs <emacs>`
-   * :ref:`i-pi <ipi>`
+   * :ref:`i-PI <ipi>`
    * :ref:`kate <kate>`
    * :ref:`LAMMPS shell <lammps_shell>`
    * :ref:`LAMMPS GUI <lammps_gui>`
@@ -376,21 +376,40 @@ See README file in the tools/fep directory.
 
 .. _ipi:
 
-i-pi tool
+i-PI tool
 -------------------
 
-The tools/i-pi directory contains a version of the i-PI package, with
-all the LAMMPS-unrelated files removed.  It is provided so that it can
-be used with the :doc:`fix ipi <fix_ipi>` command to perform
-path-integral molecular dynamics (PIMD).
+.. versionchanged:: 27June2024
+
+The tools/i-pi directory used to contain a bundled version of the i-PI
+software package for use with LAMMPS.  This version, however, was
+removed in 06/2024.
 
 The i-PI package was created and is maintained by Michele Ceriotti,
 michele.ceriotti at gmail.com, to interface to a variety of molecular
 dynamics codes.
 
-See the tools/i-pi/manual.pdf file for an overview of i-PI, and the
-:doc:`fix ipi <fix_ipi>` page for further details on running PIMD
-calculations with LAMMPS.
+i-PI is now available via PyPI using the pip package manager at:
+https://pypi.org/project/ipi/
+
+Here are the commands to set up a virtual environment and install
+i-PI into it with all its dependencies.
+
+.. code-block:: sh
+
+   python -m venv ipienv
+   source ipienv/bin/activate
+   pip install --upgrade pip
+   pip install ipi
+
+To install the development version from GitHub, please use:
+
+.. code-block:: sh
+
+   pip install git+https://github.com/i-pi/i-pi.git
+
+For further information, please consult the [i-PI home
+page](https://ipi-code.org).
 
 ----------
 
@@ -709,8 +728,8 @@ CMake is required.
 The LAMMPS GUI has been successfully compiled and tested on:
 
 - Ubuntu Linux 20.04LTS x86_64 using GCC 9, Qt version 5.12
-- Fedora Linux 38 x86\_64 using GCC 13 and Clang 16, Qt version 5.15LTS
-- Fedora Linux 38 x86\_64 using GCC 13, Qt version 6.5LTS
+- Fedora Linux 40 x86\_64 using GCC 14 and Clang 17, Qt version 5.15LTS
+- Fedora Linux 40 x86\_64 using GCC 14, Qt version 6.5LTS
 - Apple macOS 12 (Monterey) and macOS 13 (Ventura) with Xcode on arm64 and x86\_64, Qt version 5.15LTS
 - Windows 10 and 11 x86_64 with Visual Studio 2022 and Visual C++ 14.36, Qt version 5.15LTS
 - Windows 10 and 11 x86_64 with MinGW / GCC 10.0 cross-compiler on Fedora 38, Qt version 5.15LTS
@@ -752,22 +771,23 @@ if necessary.  When both, Qt5 and Qt6 are available, Qt6 will be preferred
 unless ``-D LAMMPS_GUI_USE_QT5=yes`` is set.
 
 It should be possible to build the LAMMPS GUI as a standalone
-compilation (e.g. when LAMMPS has been compiled with traditional make),
-then the CMake configuration needs to be told where to find the LAMMPS
+compilation (e.g. when LAMMPS has been compiled with traditional make).
+Then the CMake configuration needs to be told where to find the LAMMPS
 headers and the LAMMPS library, via ``-D
 LAMMPS_SOURCE_DIR=/path/to/lammps/src``.  CMake will try to guess a
 build folder with the LAMMPS library from that path, but it can also be
 set with ``-D LAMMPS_LIB_DIR=/path/to/lammps/lib``.
 
 Rather than linking to the LAMMPS library during compilation, it is also
-possible to compile the GUI with a plugin loader library that will load
+possible to compile the GUI with a plugin loader that will load
 the LAMMPS library dynamically at runtime during the start of the GUI
 from a shared library; e.g. ``liblammps.so`` or ``liblammps.dylib`` or
 ``liblammps.dll`` (depending on the operating system).  This has the
-advantage that the LAMMPS library can be updated LAMMPS without having
-to recompile the GUI.  The ABI of the LAMMPS C-library interface is very
-stable and generally backward compatible.  This feature is enabled by
-setting ``-D LAMMPS_GUI_USE_PLUGIN=on`` and then ``-D
+advantage that the LAMMPS library can be built from updated or modified
+LAMMPS source without having to recompile the GUI.  The ABI of the
+LAMMPS C-library interface is very stable and generally backward
+compatible.  This feature is enabled by setting
+``-D LAMMPS_GUI_USE_PLUGIN=on`` and then ``-D
 LAMMPS_PLUGINLIB_DIR=/path/to/lammps/plugin/loader``. Typically, this
 would be the ``examples/COUPLE/plugin`` folder of the LAMMPS
 distribution.
@@ -779,8 +799,8 @@ macOS
 """""
 
 When building on macOS, the build procedure will try to manufacture a
-drag-n-drop installer, LAMMPS-macOS-multiarch.dmg, when using the 'dmg'
-target (i.e. ``cmake --build <build dir> --target dmg`` or ``make dmg``.
+drag-n-drop installer, ``LAMMPS-macOS-multiarch.dmg``, when using the
+'dmg' target (i.e. ``cmake --build <build dir> --target dmg`` or ``make dmg``.
 
 To build multi-arch executables that will run on both, arm64 and x86_64
 architectures natively, it is necessary to set the CMake variable ``-D
@@ -819,12 +839,12 @@ and LAMMPS GUI can be launched from anywhere from the command line.
 
 The standard CMake build procedure can be applied and the
 ``mingw-cross.cmake`` preset used. By using ``mingw64-cmake`` the CMake
-command will automatically include a suitable CMake toolset file (the
-regular cmake command can be used after that).  After building the
-libraries and executables, you can build the target 'zip'
-(i.e. ``cmake --build <build dir> --target zip`` or ``make zip``
-to stage all installed files into a LAMMPS_GUI folder and then
-run a script to copy all required dependencies, some other files,
+command will automatically include a suitable CMake toolchain file (the
+regular cmake command can be used after that to modify the configuration
+settings, if needed).  After building the libraries and executables,
+you can build the target 'zip' (i.e. ``cmake --build <build dir> --target zip``
+or ``make zip`` to stage all installed files into a LAMMPS_GUI folder
+and then run a script to copy all required dependencies, some other files,
 and create a zip file from it.
 
 Linux

doc/src/angle_charmm.rst

@@ -70,7 +70,9 @@ for more info.
 Related commands
 """"""""""""""""
 
-:doc:`angle_coeff <angle_coeff>`
+:doc:`angle_coeff <angle_coeff>`, :doc:`pair_style lj/charmm variants <pair_charmm>`,
+:doc:`dihedral_style charmm <dihedral_charmm>`,
+:doc:`dihedral_style charmmfsw <dihedral_charmm>`, :doc:`fix cmap <fix_cmap>`
 
 Default
 """""""

doc/src/angle_cosine_squared_restricted.rst

@@ -0,0 +1,80 @@
+.. index:: angle_style cosine/squared/restricted
+.. index:: angle_style cosine/squared/restricted/omp
+
+angle_style cosine/squared/restricted command
+=============================================
+
+Accelerator Variants: *cosine/squared/restricted/omp*
+
+Syntax
+""""""
+
+.. code-block:: LAMMPS
+
+   angle_style cosine/squared/restricted
+
+Examples
+""""""""
+
+.. code-block:: LAMMPS
+
+   angle_style cosine/squared/restricted
+   angle_coeff 2*4 75.0 100.0
+
+Description
+"""""""""""
+
+.. versionadded:: 17Apr2024
+
+The *cosine/squared/restricted* angle style uses the potential
+
+.. math::
+
+   E = K [\cos(\theta) - \cos(\theta_0)]^2 / \sin^2(\theta)
+
+, which is commonly used in the MARTINI force field,
+where :math:`\theta_0` is the equilibrium value of the angle, and :math:`K`
+is a prefactor.  Note that the usual 1/2 factor is included in :math:`K`.
+
+See :ref:`(Bulacu) <restricted-Bulacu>` for a description of the restricted angle for the MARTINI force field.
+
+The following coefficients must be defined for each angle type via the
+:doc:`angle_coeff <angle_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)
+* :math:`\theta_0` (degrees)
+
+:math:`\theta_0` is specified in degrees, but LAMMPS converts it to radians
+internally.
+
+----------
+
+.. include:: accel_styles.rst
+
+----------
+
+Restrictions
+""""""""""""
+
+This angle style can only be used if LAMMPS was built with the
+EXTRA-MOLECULE package.  See the :doc:`Build package <Build_package>` doc page
+for more info.
+
+Related commands
+""""""""""""""""
+
+:doc:`angle_coeff <angle_coeff>`
+
+Default
+"""""""
+
+none
+
+----------
+
+.. _restricted-Bulacu:
+
+**(Bulacu)** Bulacu, Goga, Zhao, Rossi, Monticelli, Periole, Tieleman, Marrink, J Chem Theory Comput, 9, 3282-3292
+(2013).

doc/src/angle_lepton.rst

@@ -11,7 +11,16 @@ Syntax
 
 .. code-block:: LAMMPS
 
-   angle_style lepton
+   angle_style style args
+
+* style = *lepton*
+* args = optional arguments
+
+.. parsed-literal::
+
+   args = *auto_offset* or *no_offset*
+     *auto_offset* = offset the potential energy so that the value at theta0 is 0.0 (default)
+     *no_offset* = do not offset the potential energy
 
 Examples
 """"""""
@@ -19,6 +28,7 @@ Examples
 .. code-block:: LAMMPS
 
    angle_style lepton
+   angle_style lepton no_offset
 
    angle_coeff  1  120.0  "k*theta^2; k=250.0"
    angle_coeff  2   90.0  "k2*theta^2 + k3*theta^3 + k4*theta^4; k2=300.0; k3=-100.0; k4=50.0"
@@ -41,6 +51,13 @@ angle coefficient.  For example `"200.0*theta^2"` represents a
 
    U_{angle,i} = K (\theta_i - \theta_0)^2 = K \theta^2 \qquad \theta = \theta_i - \theta_0
 
+.. versionchanged:: 7Feb2024
+
+By default the potential energy U is shifted so that the value U is 0.0
+for $theta = theta_0$.  This is equivalent to using the optional keyword
+*auto_offset*.  When using the keyword *no_offset* instead, the
+potential energy is not shifted.
+
 The `Lepton library <https://simtk.org/projects/lepton>`_, that the
 *lepton* angle style interfaces with, evaluates this expression string
 at run time to compute the pairwise energy.  It also creates an

doc/src/angle_style.rst

@@ -10,7 +10,7 @@ Syntax
 
    angle_style style
 
-* style = *none* or *zero* or *hybrid* or *amoeba* or *charmm* or *class2* or *class2/p6* or *cosine* or *cosine/buck6d* or *cosine/delta* or *cosine/periodic* or *cosine/shift* or *cosine/shift/exp* or *cosine/squared* or *cross* or *dipole* or *fourier* or *fourier/simple* or *gaussian* or *harmonic* or *lepton* or *mm3* or *quartic* or *spica* or *table*
+* style = *none* or *zero* or *hybrid* or *amoeba* or *charmm* or *class2* or *class2/p6* or *cosine* or *cosine/buck6d* or *cosine/delta* or *cosine/periodic* or *cosine/shift* or *cosine/shift/exp* or *cosine/squared* or *cosine/squared/restricted* or *cross* or *dipole* or *fourier* or *fourier/simple* or *gaussian* or *harmonic* or *lepton* or *mm3* or *quartic* or *spica* or *table*
 
 Examples
 """"""""
@@ -84,6 +84,7 @@ of (g,i,k,o,t) to indicate which accelerated styles exist.
 * :doc:`cosine/shift <angle_cosine_shift>` - angle cosine with a shift
 * :doc:`cosine/shift/exp <angle_cosine_shift_exp>` - cosine with shift and exponential term in spring constant
 * :doc:`cosine/squared <angle_cosine_squared>` - angle with cosine squared term
+* :doc:`cosine/squared/restricted <angle_cosine_squared_restricted>` - angle with restricted cosine squared term
 * :doc:`cross <angle_cross>` - cross term coupling angle and bond lengths
 * :doc:`dipole <angle_dipole>` - angle that controls orientation of a point dipole
 * :doc:`fourier <angle_fourier>` - angle with multiple cosine terms

doc/src/atom_style.rst

@@ -49,248 +49,221 @@ Examples
 Description
 """""""""""
 
-Define what style of atoms to use in a simulation.  This determines
-what attributes are associated with the atoms.  This command must be
-used before a simulation is setup via a :doc:`read_data <read_data>`,
-:doc:`read_restart <read_restart>`, or :doc:`create_box <create_box>`
-command.
+The *atom_style* command selects which per-atom attributes are
+associated with atoms in a LAMMPS simulation and thus stored and
+communicated with those atoms as well as read from and stored in data
+and restart files.  Different models (e.g. :doc:`pair styles
+<pair_style>`) require access to specific per-atom attributes and thus
+require a specific atom style.  For example, to compute Coulomb
+interactions, the atom must have a "charge" (aka "q") attribute.
+
+A number of distinct atom styles exist that combine attributes.  Some
+atom styles are a superset of other atom styles.  Further attributes
+may be added to atoms either via using a hybrid style which provides a
+union of the attributes of the sub-styles, or via the :doc:`fix
+property/atom <fix_property_atom>` command.  The *atom_style* command
+must be used before a simulation is setup via a :doc:`read_data
+<read_data>`, :doc:`read_restart <read_restart>`, or :doc:`create_box
+<create_box>` command.
 
 .. note::
 
-   Many of the atom styles discussed here are only enabled if
-   LAMMPS was built with a specific package, as listed below in the
-   Restrictions section.
+   Many of the atom styles discussed here are only enabled if LAMMPS was
+   built with a specific package, as listed below in the Restrictions
+   section.
 
-Once a style is assigned, it cannot be changed, so use a style general
-enough to encompass all attributes.  E.g. with style *bond*, angular
-terms cannot be used or added later to the model.  It is OK to use a
-style more general than needed, though it may be slightly inefficient.
+Once a style is selected and the simulation box defined, it cannot be
+changed but only augmented with the :doc:`fix property/atom
+<fix_property_atom>` command.  So one should select an atom style
+general enough to encompass all attributes required.  E.g. with atom
+style *bond*, it is not possible to define angles and use angle styles.
 
-The choice of style affects what quantities are stored by each atom,
-what quantities are communicated between processors to enable forces
-to be computed, and what quantities are listed in the data file read
-by the :doc:`read_data <read_data>` command.
+It is OK to use a style more general than needed, though it may be
+slightly inefficient because it will allocate and communicate
+additional unused data.
 
-These are the additional attributes of each style and the typical
-kinds of physical systems they are used to model.  All styles store
-coordinates, velocities, atom IDs and types.  See the
+Atom style attributes
+"""""""""""""""""""""
+
+The atom style *atomic* has the minimum subset of per-atom attributes
+and is also the default setting.  It encompasses the following per-atom
+attributes (name of the vector or array in the :doc:`Atom class
+<Classes_atom>` is given in parenthesis): atom-ID (tag), type (type),
+position (x), velocities (v), forces (f), image flags (image), group
+membership (mask).  Since all atom styles are a superset of atom style
+*atomic*\ , they all include these attributes.
+
+This table lists all the available atom styles, which attributes they
+provide, which :doc:`package <Packages>` is required to use them, and
+what the typical applications are that use them.  See the
 :doc:`read_data <read_data>`, :doc:`create_atoms <create_atoms>`, and
-:doc:`set <set>` commands for info on how to set these various
-quantities.
+:doc:`set <set>` commands for details on how to set these various
+quantities.  More information about many of the styles is provided in
+the Additional Information section below.
 
-+--------------+-----------------------------------------------------+--------------------------------------+
-| *amoeba*     | molecular + charge + 1/5 neighbors                  | AMOEBA/HIPPO polarized force fields  |
-+--------------+-----------------------------------------------------+--------------------------------------+
-| *angle*      | bonds and angles                                    | bead-spring polymers with stiffness  |
-+--------------+-----------------------------------------------------+--------------------------------------+
-| *atomic*     | only the default values                             | coarse-grain liquids, solids, metals |
-+--------------+-----------------------------------------------------+--------------------------------------+
-| *body*       | mass, inertia moments, quaternion, angular momentum | arbitrary bodies                     |
-+--------------+-----------------------------------------------------+--------------------------------------+
-| *bond*       | bonds                                               | bead-spring polymers                 |
-+--------------+-----------------------------------------------------+--------------------------------------+
-| *charge*     | charge                                              | atomic system with charges           |
-+--------------+-----------------------------------------------------+--------------------------------------+
-| *dielectric* | normx normy normz area/patch ed em epsilon curv     | system with surface polarization     |
-+--------------+-----------------------------------------------------+--------------------------------------+
-| *dipole*     | charge and dipole moment                            | system with dipolar particles        |
-+--------------+-----------------------------------------------------+--------------------------------------+
-| *dpd*        | internal temperature and internal energies          | DPD particles                        |
-+--------------+-----------------------------------------------------+--------------------------------------+
-| *edpd*       | temperature and heat capacity                       | eDPD particles                       |
-+--------------+-----------------------------------------------------+--------------------------------------+
-| *electron*   | charge and spin and eradius                         | electronic force field               |
-+--------------+-----------------------------------------------------+--------------------------------------+
-| *ellipsoid*  | shape, quaternion, angular momentum                 | aspherical particles                 |
-+--------------+-----------------------------------------------------+--------------------------------------+
-| *full*       | molecular + charge                                  | bio-molecules                        |
-+--------------+-----------------------------------------------------+--------------------------------------+
-| *line*       | end points, angular velocity                        | rigid bodies                         |
-+--------------+-----------------------------------------------------+--------------------------------------+
-| *mdpd*       | density                                             | mDPD particles                       |
-+--------------+-----------------------------------------------------+--------------------------------------+
-| *molecular*  | bonds, angles, dihedrals, impropers                 | uncharged molecules                  |
-+--------------+-----------------------------------------------------+--------------------------------------+
-| *oxdna*      | nucleotide polarity                                 | coarse-grained DNA and RNA models    |
-+--------------+-----------------------------------------------------+--------------------------------------+
-| *peri*       | mass, volume                                        | mesoscopic Peridynamic models        |
-+--------------+-----------------------------------------------------+--------------------------------------+
-| *smd*        | volume, kernel diameter, contact radius, mass       | solid and fluid SPH particles        |
-+--------------+-----------------------------------------------------+--------------------------------------+
-| *sph*        | rho, esph, cv                                       | SPH particles                        |
-+--------------+-----------------------------------------------------+--------------------------------------+
-| *sphere*     | diameter, mass, angular velocity                    | granular models                      |
-+--------------+-----------------------------------------------------+--------------------------------------+
-| *bpm/sphere* | diameter, mass, angular velocity, quaternion        | granular bonded particle models (BPM)|
-+--------------+-----------------------------------------------------+--------------------------------------+
-| *spin*       | magnetic moment                                     | system with magnetic particles       |
-+--------------+-----------------------------------------------------+--------------------------------------+
-| *tdpd*       | chemical concentration                              | tDPD particles                       |
-+--------------+-----------------------------------------------------+--------------------------------------+
-| *template*   | template index, template atom                       | small molecules with fixed topology  |
-+--------------+-----------------------------------------------------+--------------------------------------+
-| *tri*        | corner points, angular momentum                     | rigid bodies                         |
-+--------------+-----------------------------------------------------+--------------------------------------+
-| *wavepacket* | charge, spin, eradius, etag, cs_re, cs_im           | AWPMD                                |
-+--------------+-----------------------------------------------------+--------------------------------------+
+.. list-table::
+   :header-rows: 1
+   :widths: auto
+
+   * - Atom style
+     - Attributes
+     - Required package
+     - Applications
+   * - *amoeba*
+     - *full* + "1-5 special neighbor data"
+     - :ref:`AMOEBA <PKG-AMOEBA>`
+     - AMOEBA/HIPPO force fields
+   * - *angle*
+     - *bond* + "angle data"
+     - :ref:`MOLECULE <PKG-MOLECULE>`
+     - bead-spring polymers with stiffness
+   * - *atomic*
+     - tag, type, x, v, f, image, mask
+     -
+     - atomic liquids, solids, metals
+   * - *body*
+     - *atomic* + radius, rmass, angmom, torque, body
+     - :ref:`BODY <PKG-BODY>`
+     - arbitrary bodies, see :doc:`body howto <Howto_body>`
+   * - *bond*
+     - *atomic* + molecule, nspecial, special + "bond data"
+     - :ref:`MOLECULE <PKG-MOLECULE>`
+     - bead-spring polymers
+   * - *bpm/sphere*
+     - *bond* + radius, rmass, omega, torque, quat
+     - :ref:`BPM <PKG-BPM>`
+     - granular bonded particle models, see :doc:`BPM howto <Howto_bpm>`
+   * - *charge*
+     - *atomic* + q
+     -
+     - atomic systems with charges
+   * - *dielectric*
+     - *full* + mu, area, ed, em, epsilon, curvature, q_scaled
+     - :ref:`DIELECTRIC <PKG-DIELECTRIC>`
+     - systems with surface polarization
+   * - *dipole*
+     - *charge* + mu
+     - :ref:`DIPOLE <PKG-DIPOLE>`
+     - atomic systems with charges and point dipoles
+   * - *dpd*
+     - *atomic* + rho + "reactive DPD data"
+     - :ref:`DPD-REACT <PKG-DPD-REACT>`
+     - reactive DPD
+   * - *edpd*
+     - *atomic* + "eDPD data"
+     - :ref:`DPD-MESO <PKG-DPD-MESO>`
+     - Energy conservative DPD (eDPD)
+   * - *electron*
+     - *charge* + espin, eradius, ervel, erforce
+     - :ref:`EFF <PKG-EFF>`
+     - Electron force field systems
+   * - *ellipsoid*
+     - *atomic* + rmass, angmom, torque, ellipsoid
+     -
+     - aspherical particles
+   * - *full*
+     - *molecular* + q
+     - :ref:`MOLECULE <PKG-MOLECULE>`
+     - molecular force fields
+   * - *line*
+     - *atomic* + molecule, radius, rmass, omega, torque, line
+     -
+     - 2-d rigid body particles
+   * - *mdpd*
+     - *atomic* + rho, drho, vest
+     - :ref:`DPD-MESO <PKG-DPD-MESO>`
+     - Many-body DPD (mDPD)
+   * - *molecular*
+     - *angle* + "dihedral and improper data"
+     - :ref:`MOLECULE <PKG-MOLECULE>`
+     - apolar and uncharged molecules
+   * - *oxdna*
+     - *atomic* + id5p
+     - :ref:`CG-DNA <PKG-CG-DNA>`
+     - coarse-grained DNA and RNA models
+   * - *peri*
+     - *atomic* + rmass, vfrac, s0, x0
+     - :ref:`PERI <PKG-PERI>`
+     - mesoscopic Peridynamics models
+   * - *smd*
+     - *atomic* + molecule, radius, rmass + "smd data"
+     - :ref:`MACHDYN <PKG-MACHDYN>`
+     - Smooth Mach Dynamics models
+   * - *sph*
+     - *atomic* + "sph data"
+     - :ref:`SPH <PKG-SPH>`
+     - Smoothed particle hydrodynamics models
+   * - *sphere*
+     - *atomic* + radius, rmass, omega, torque
+     -
+     - finite size spherical particles, e.g. granular models
+   * - *spin*
+     - *atomic* + "magnetic moment data"
+     - :ref:`SPIN <PKG-SPIN>`
+     - magnetic particles
+   * - *tdpd*
+     - *atomic* + cc, cc_flux, vest
+     - :ref:`DPD-MESO <PKG-DPD-MESO>`
+     - Transport DPD (tDPD)
+   * - *template*
+     - *atomic* + molecule, molindex, molatom
+     - :ref:`MOLECULE <PKG-MOLECULE>`
+     - molecular systems where attributes are taken from :doc:`molecule files <molecule>`
+   * - *tri*
+     - *sphere* + molecule, angmom, tri
+     -
+     - 3-d triangulated rigid body LJ particles
+   * - *wavepacket*
+     - *charge* + "wavepacket data"
+     - :ref:`AWPMD <PKG-AWPMD>`
+     - Antisymmetrized wave packet MD
 
 .. note::
 
-   It is possible to add some attributes, such as a molecule ID, to
-   atom styles that do not have them via the :doc:`fix property/atom
-   <fix_property_atom>` command.  This command also allows new custom
-   attributes consisting of extra integer or floating-point values to
-   be added to atoms.  See the :doc:`fix property/atom
-   <fix_property_atom>` page for examples of cases where this is
-   useful and details on how to initialize, access, and output the
-   custom values.
+   It is possible to add some attributes, such as a molecule ID and
+   charge, to atom styles that do not have them built in using the
+   :doc:`fix property/atom <fix_property_atom>` command.  This command
+   also allows new custom-named attributes consisting of extra integer
+   or floating-point values or vectors to be added to atoms.  See the
+   :doc:`fix property/atom <fix_property_atom>` page for examples of
+   cases where this is useful and details on how to initialize,
+   access, and output these custom values.
 
-All of the above styles define point particles, except the *sphere*,
-*bpm/sphere*, *ellipsoid*, *electron*, *peri*, *wavepacket*, *line*,
-*tri*, and *body* styles, which define finite-size particles.  See the
-:doc:`Howto spherical <Howto_spherical>` page for an overview of using
-finite-size particle models with LAMMPS.
+----------
 
-All of the point-particle styles assign mass to particles on a
-per-type basis, using the :doc:`mass <mass>` command, The finite-size
-particle styles assign mass to individual particles on a per-particle
-basis.
+Particle size and mass
+""""""""""""""""""""""
 
-For the *sphere* and *bpm/sphere* styles, the particles are spheres
-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.  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.
+All of the atom styles define point particles unless they (1) define
+finite-size spherical particles via the *radius* attribute, or (2)
+define finite-size aspherical particles (e.g. the *body*, *ellipsoid*,
+*line*, and *tri* styles).  Most of these styles can also be used with
+mixtures of point and finite-size particles.
 
-For the *ellipsoid* style, the particles are ellipsoids and each
-stores a flag which indicates whether it is a finite-size ellipsoid or
-a point particle.  If it is an ellipsoid, it also stores a shape
-vector with the 3 diameters of the ellipsoid and a quaternion 4-vector
-with its orientation.
+Note that the *radius* property may need to be provided as a
+*diameter* (e.g. in :doc:`molecule files <molecule>` or :doc:`data
+files <read_data>`).  See the :doc:`Howto spherical <Howto_spherical>`
+page for an overview of using finite-size spherical and aspherical
+particle models with LAMMPS.
 
-For the *dielectric* style, each particle can be either a physical
-particle (e.g. an ion), or an interface particle representing a boundary
-element between two regions of different dielectric constant. For
-interface particles, in addition to the properties associated with
-atom_style full, each particle also should be assigned a normal unit
-vector (defined by normx, normy, normz), an area (area/patch), the
-difference and mean of the dielectric constants of two sides of the
-interface along the direction of the normal vector (ed and em), the
-local dielectric constant at the boundary element (epsilon), and a mean
-local curvature (curv).  Physical particles must be assigned these
-values, as well, but only their local dielectric constants will be used;
-see documentation for associated :doc:`pair styles <pair_dielectric>`
-and :doc:`fixes <fix_polarize>`.  The distinction between the physical
-and interface particles is only meaningful when :doc:`fix polarize
-<fix_polarize>` commands are applied to the interface particles. This
-style is part of the DIELECTRIC package.
+Unless an atom style defines the per-atom *rmass* attribute, particle
+masses are defined on a per-type basis, using the :doc:`mass <mass>`
+command.  This means each particle's mass is indexed by its atom
+*type*.
 
-For the *dipole* style, a point dipole is defined for each point
-particle.  Note that if you wish the particles to be finite-size
-spheres as in a Stockmayer potential for a dipolar fluid, so that the
-particles can rotate due to dipole-dipole interactions, then you need
-to use atom_style hybrid sphere dipole, which will assign both a
-diameter and dipole moment to each particle.
+A few styles define the per-atom *rmass* attribute which can also be
+added using the :doc:`fix property/atom <fix_property_atom>` command.
+In this case each particle stores its own mass.  Atom styles that have
+a per-atom rmass may define it indirectly through setting particle
+diameter and density on a per-particle basis.  If both per-type mass
+and per-atom *rmass* are defined (e.g. in a hybrid style), the
+per-atom mass will take precedence in any operation which which works
+with both flavors of mass.
 
-For the *electron* style, the particles representing electrons are 3d
-Gaussians with a specified position and bandwidth or uncertainty in
-position, which is represented by the eradius = electron size.
+----------
 
-For the *peri* style, the particles are spherical and each stores a
-per-particle mass and volume.
-
-The *bpm/sphere* style is part of the BPM package.
-
-The *oxdna* style is for coarse-grained nucleotides and stores the
-3'-to-5' polarity of the nucleotide strand, which is set through
-the bond topology in the data file. The first (second) atom in a
-bond definition is understood to point towards the 3'-end (5'-end)
-of the strand. Note that this style is part of the CG-DNA package.
-
-The *dpd* style is for dissipative particle dynamics (DPD) particles.
-Note that it is part of the DPD-REACT package, and is not for use with
-the :doc:`pair_style dpd or dpd/stat <pair_dpd>` commands, which can
-simply use atom_style atomic.  Atom_style dpd extends DPD particle
-properties with internal temperature (dpdTheta), internal conductive
-energy (uCond), internal mechanical energy (uMech), and internal
-chemical energy (uChem).
-
-The *edpd* style is for energy-conserving dissipative particle
-dynamics (eDPD) particles which store a temperature (edpd_temp), and
-heat capacity(edpd_cv).
-
-The *mdpd* style is for many-body dissipative particle dynamics (mDPD)
-particles which store a density (rho) for considering
-density-dependent many-body interactions.
-
-The *tdpd* style is for transport dissipative particle dynamics (tDPD)
-particles which store a set of chemical concentration. An integer
-"cc_species" is required to specify the number of chemical species
-involved in a tDPD system.
-
-The *sph* style is for smoothed particle hydrodynamics (SPH)
-particles which store a density (rho), energy (esph), and heat capacity
-(cv).
-
-The *smd* style is for a general formulation of Smooth Particle
-Hydrodynamics.  Both fluids and solids can be modeled.  Particles
-store the mass and volume of an integration point, a kernel diameter
-used for calculating the field variables (e.g. stress and deformation)
-and a contact radius for calculating repulsive forces which prevent
-individual physical bodies from penetrating each other.
-
-For the *spin* style, a magnetic spin is associated to each atom.
-Those spins have a norm (their magnetic moment) and a direction.
-
-The *wavepacket* style is similar to *electron*, but the electrons may
-consist of several Gaussian wave packets, summed up with coefficients
-cs= (cs_re,cs_im).  Each of the wave packets is treated as a separate
-particle in LAMMPS, wave packets belonging to the same electron must
-have identical *etag* values.
-
-For the *line* style, the particles are idealized line segments and
-each stores a per-particle mass and length and orientation (i.e. the
-end points of the line segment).
-
-For the *tri* style, the particles are planar triangles and each
-stores a per-particle mass and size and orientation (i.e. the corner
-points of the triangle).
-
-The *template* style allows molecular topology (bonds,angles,etc) to be
-defined via a molecule template using the :doc:`molecule <molecule>`
-command.  The template stores one or more molecules with a single copy
-of the topology info (bonds,angles,etc) of each.  Individual atoms
-only store a template index and template atom to identify which
-molecule and which atom-within-the-molecule they represent.  Using the
-*template* style instead of the *bond*, *angle*, *molecular* styles
-can save memory for systems comprised of a large number of small
-molecules, all of a single type (or small number of types).  See the
-paper by Grime and Voth, in :ref:`(Grime) <Grime>`, for examples of how this
-can be advantageous for large-scale coarse-grained systems.
-The ``examples/template`` directory has a few demo inputs and examples
-showing the use of the *template* atom style versus *molecular*.
-
-.. note::
-
-   When using the *template* style with a :doc:`molecule template
-   <molecule>` that contains multiple molecules, you should ensure the
-   atom types, bond types, angle_types, etc in all the molecules are
-   consistent.  E.g. if one molecule represents H2O and another CO2,
-   then you probably do not want each molecule file to define 2 atom
-   types and a single bond type, because they will conflict with each
-   other when a mixture system of H2O and CO2 molecules is defined,
-   e.g. by the :doc:`read_data <read_data>` command.  Rather the H2O
-   molecule should define atom types 1 and 2, and bond type 1.  And
-   the CO2 molecule should define atom types 3 and 4 (or atom types 3
-   and 2 if a single oxygen type is desired), and bond type 2.
+Additional information about specific atom styles
+"""""""""""""""""""""""""""""""""""""""""""""""""
 
 For the *body* style, the particles are arbitrary bodies with internal
 attributes defined by the "style" of the bodies, which is specified by
@@ -309,6 +282,149 @@ Note that there may be additional arguments required along with the
 *bstyle* specification, in the atom_style body command.  These
 arguments are described on the :doc:`Howto body <Howto_body>` doc page.
 
+For the *dielectric* style, each particle can be either a physical
+particle (e.g. an ion), or an interface particle representing a
+boundary element between two regions of different dielectric
+constant. For interface particles, in addition to the properties
+associated with atom_style full, each particle also should be assigned
+a unit dipole vector (mu) representing the direction of the induced
+dipole moment at each interface particle, an area (area/patch), the
+difference and mean of the dielectric constants of two sides of the
+interface along the direction of the normal vector (ed and em), the
+local dielectric constant at the boundary element (epsilon), and a
+mean local curvature (curv).  Physical particles must be assigned
+these values, as well, but only their local dielectric constants will
+be used; see documentation for associated :doc:`pair styles
+<pair_dielectric>` and :doc:`fixes <fix_polarize>`.  The distinction
+between the physical and interface particles is only meaningful when
+:doc:`fix polarize <fix_polarize>` commands are applied to the
+interface particles. This style is part of the DIELECTRIC package.
+
+For the *dipole* style, a point dipole vector mu is defined for each
+point particle.  Note that if you wish the particles to be finite-size
+spheres as in a Stockmayer potential for a dipolar fluid, so that the
+particles can rotate due to dipole-dipole interactions, then you need
+to use the command `atom_style hybrid sphere dipole`, which will
+assign both a diameter and dipole moment to each particle.  This also
+requires using an integrator with a "/sphere" suffix like :doc:`fix
+nve/sphere <fix_nve_sphere>` or :doc:`fix nvt/sphere <fix_nvt_sphere>`
+and the "update dipole" or "update dlm" parameters to the fix
+commands.
+
+The *dpd* style is for reactive dissipative particle dynamics (DPD)
+particles.  Note that it is part of the DPD-REACT package, and is not
+required for use with the :doc:`pair_style dpd or dpd/stat <pair_dpd>`
+commands, which only require the attributes from atom_style *atomic*.
+Atom_style *dpd* extends DPD particle properties with internal
+temperature (dpdTheta), internal conductive energy (uCond), internal
+mechanical energy (uMech), and internal chemical energy (uChem).
+
+The *edpd* style is for energy-conserving dissipative particle
+dynamics (eDPD) particles which store a temperature (edpd_temp), and
+heat capacity (edpd_cv).
+
+For the *electron* style, the particles representing electrons are 3d
+Gaussians with a specified position and bandwidth or uncertainty in
+position, which is represented by the eradius = electron size.
+
+For the *ellipsoid* style, particles can be ellipsoids which each
+stores a shape vector with the 3 diameters of the ellipsoid and a
+quaternion 4-vector with its orientation.  Each particle stores a flag
+in the ellipsoid vector which indicates whether it is an ellipsoid (1)
+or a point particle (0).
+
+For the *line* style, particles can be are idealized line segments
+which store a per-particle mass and length and orientation (i.e. the
+end points of the line segment).  Each particle stores a flag in the
+line vector which indicates whether it is a line segment (1) or a
+point particle (0).
+
+The *mdpd* style is for many-body dissipative particle dynamics (mDPD)
+particles which store a density (rho) for considering density-dependent
+many-body interactions.
+
+The *oxdna* style is for coarse-grained nucleotides and stores the
+3'-to-5' polarity of the nucleotide strand, which is set through
+the bond topology in the data file. The first (second) atom in a
+bond definition is understood to point towards the 3'-end (5'-end)
+of the strand.
+
+For the *peri* style, the particles are spherical and each stores a
+per-particle mass and volume.
+
+The *smd* style is for Smooth Particle Mach dynamics.  Both fluids and
+solids can be modeled.  Particles store the mass and volume of an
+integration point, a kernel diameter used for calculating the field
+variables (e.g. stress and deformation) and a contact radius for
+calculating repulsive forces which prevent individual physical bodies
+from penetrating each other.
+
+The *sph* style is for smoothed particle hydrodynamics (SPH) particles
+which store a density (rho), energy (esph), and heat capacity (cv).
+
+For the *spin* style, a magnetic spin is associated with each atom.
+Those spins have a norm (their magnetic moment) and a direction.
+
+The *tdpd* style is for transport dissipative particle dynamics (tDPD)
+particles which store a set of chemical concentration. An integer
+"cc_species" is required to specify the number of chemical species
+involved in a tDPD system.
+
+The *wavepacket* style is similar to the *electron* style, but the
+electrons may consist of several Gaussian wave packets, summed up with
+coefficients cs= (cs_re,cs_im).  Each of the wave packets is treated
+as a separate particle in LAMMPS, wave packets belonging to the same
+electron must have identical *etag* values.
+
+The *sphere* and *bpm/sphere* styles allow particles to be either point
+particles or finite-size particles.  If the *radius* attribute is >
+0.0, the particle is a finite-size sphere.  If the diameter = 0.0, it
+is a point particle.  Note that by using 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.  These styles also
+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 (this is
+the default).  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.
+
+The *template* style allows molecular topology (bonds,angles,etc) to be
+defined via a molecule template using the :doc:`molecule <molecule>`
+command.  The template stores one or more molecules with a single copy
+of the topology info (bonds,angles,etc) of each.  Individual atoms only
+store a template index and template atom to identify which molecule and
+which atom-within-the-molecule they represent.  Using the *template*
+style instead of the *bond*, *angle*, *molecular* styles can save memory
+for systems comprised of a large number of small molecules, all of a
+single type (or small number of types).  See the paper by Grime and
+Voth, in :ref:`(Grime) <Grime>`, for examples of how this can be
+advantageous for large-scale coarse-grained systems.  The
+``examples/template`` directory has a few demo inputs and examples
+showing the use of the *template* atom style versus *molecular*.
+
+.. note::
+
+   When using the *template* style with a :doc:`molecule template
+   <molecule>` that contains multiple molecules, you should ensure the
+   atom types, bond types, angle_types, etc in all the molecules are
+   consistent.  E.g. if one molecule represents H2O and another CO2,
+   then you probably do not want each molecule file to define 2 atom
+   types and a single bond type, because they will conflict with each
+   other when a mixture system of H2O and CO2 molecules is defined,
+   e.g. by the :doc:`read_data <read_data>` command.  Rather the H2O
+   molecule should define atom types 1 and 2, and bond type 1.  And
+   the CO2 molecule should define atom types 3 and 4 (or atom types 3
+   and 2 if a single oxygen type is desired), and bond type 2.
+
+For the *tri* style, particles can be planar triangles which each
+stores a per-particle mass and size and orientation (i.e. the corner
+points of the triangle).  Each particle stores a flag in the tri
+vector which indicates whether it is a triangle (1) or a point
+particle (0).
+
 ----------
 
 Typically, simulations require only a single (non-hybrid) atom style.
@@ -326,11 +442,12 @@ dipole".  When a hybrid style is used, atoms store and communicate the
 union of all quantities implied by the individual styles.
 
 When using the *hybrid* style, you cannot combine the *template* style
-with another molecular style that stores bond,angle,etc info on a
+with another molecular style that stores bond, angle, etc info on a
 per-atom basis.
 
-LAMMPS can be extended with new atom styles as well as new body
-styles; see the :doc:`Modify <Modify>` doc page.
+LAMMPS can be extended with new atom styles as well as new body styles;
+see the corresponding manual page on :doc:`modifying & extending LAMMPS
+<Modify_atom>`.
 
 ----------
 
@@ -346,54 +463,20 @@ This command cannot be used after the simulation box is defined by a
 
 Many of the styles listed above are only enabled if LAMMPS was built
 with a specific package, as listed below.  See the :doc:`Build package
-<Build_package>` page for more info.
-
-The *amoeba* style is part of the AMOEBA package.
-
-The *angle*, *bond*, *full*, *molecular*, and *template* styles are
-part of the MOLECULE package.
-
-The *line* and *tri* styles are part of the ASPHERE package.
-
-The *body* style is part of the BODY package.
-
-The *dipole* style is part of the DIPOLE package.
-
-The *peri* style is part of the PERI package for Peridynamics.
-
-The *oxdna* style is part of the CG-DNA package for coarse-grained
-simulation of DNA and RNA.
-
-The *electron* style is part of the EFF package for :doc:`electronic
-force fields <pair_eff>`.
-
-The *dpd* style is part of the DPD-REACT package for dissipative
-particle dynamics (DPD).
-
-The *edpd*, *mdpd*, and *tdpd* styles are part of the DPD-MESO package
-for energy-conserving dissipative particle dynamics (eDPD), many-body
-dissipative particle dynamics (mDPD), and transport dissipative particle
-dynamics (tDPD), respectively.
-
-The *sph* style is part of the SPH package for smoothed particle
-hydrodynamics (SPH).  See `this PDF guide
-<PDF/SPH_LAMMPS_userguide.pdf>`_ to using SPH in LAMMPS.
-
-The *spin* style is part of the SPIN package.
-
-The *wavepacket* style is part of the AWPMD package for the
-:doc:`antisymmetrized wave packet MD method <pair_awpmd>`.
+<Build_package>` page for more info.  The table above lists which package
+is required for individual atom styles.
 
 Related commands
 """"""""""""""""
 
-:doc:`read_data <read_data>`, :doc:`pair_style <pair_style>`
+:doc:`read_data <read_data>`, :doc:`pair_style <pair_style>`,
+:doc:`fix property/atom <fix_property_atom>`, :doc:`set <set>`
 
 Default
 """""""
 
-The default atom style is atomic.  If atom_style sphere is used its
-default argument is 0.
+The default atom style is *atomic*.  If atom_style *sphere* or
+*bpm/sphere* is used, its default argument is 0.
 
 ----------
 

doc/src/bond_bpm_rotational.rst

@@ -147,8 +147,8 @@ By default, pair forces are not calculated between bonded particles.
 Pair forces can alternatively be overlaid on top of bond forces by setting
 the *overlay/pair* keyword to *yes*. 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.
+restrictions.  Further details can be found in the :doc:`how to <Howto_bpm>`
+page on BPMs.
 
 .. versionadded:: 28Mar2023
 

doc/src/bond_bpm_spring.rst

@@ -113,8 +113,8 @@ By default, pair forces are not calculated between bonded particles.
 Pair forces can alternatively be overlaid on top of bond forces by setting
 the *overlay/pair* keyword to *yes*. 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.
+restrictions.  Further details can be found in the :doc:`how to <Howto_bpm>`
+page on BPMs.
 
 .. versionadded:: 28Mar2023
 

doc/src/bond_hybrid.rst

@@ -1,8 +1,11 @@
 .. index:: bond_style hybrid
+.. index:: bond_style hybrid/kk
 
 bond_style hybrid command
 =========================
 
+Accelerator Variants: *hybrid/kk*
+
 Syntax
 """"""
 
@@ -15,7 +18,7 @@ Syntax
 Examples
 """"""""
 
-.. code-block: LAMMPS
+.. code-block:: LAMMPS
 
    bond_style hybrid harmonic fene
    bond_coeff 1 harmonic 80.0 1.2
@@ -60,6 +63,10 @@ bond types.
 
 ----------
 
+.. include:: accel_styles.rst
+
+----------
+
 Restrictions
 """"""""""""