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/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
 
@@ -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
@@ -208,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})
@@ -222,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)
@@ -252,6 +257,7 @@ set(STANDARD_PACKAGES
   DRUDE
   EFF
   ELECTRODE
+  EXTRA-COMMAND
   EXTRA-COMPUTE
   EXTRA-DUMP
   EXTRA-FIX
@@ -277,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
@@ -439,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
@@ -553,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")
@@ -670,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()

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-2024.02.09.tar.gz" CACHE STRING "URL for OpenCL loader tarball")
-set(OPENCL_LOADER_MD5 "f3573cf9daa3558ba46fd5866517f38f" CACHE STRING "MD5 checksum of OpenCL loader tarball")
+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)
 

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

@@ -45,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.2.00.tar.gz" CACHE STRING "URL for KOKKOS tarball")
-  set(KOKKOS_MD5 "731647b61a4233f568d583702e9cd6d1" 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)
@@ -71,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.2.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)
@@ -139,8 +139,9 @@ if(PKG_KSPACE)
       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 cufft)
+      target_link_libraries(lammps PRIVATE CUDA::cufft)
     endif()
   elseif(Kokkos_ENABLE_HIP)
     if(NOT ((FFT_KOKKOS STREQUAL "KISS") OR (FFT_KOKKOS STREQUAL "HIPFFT")))

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/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.3/plumed-src-2.8.3.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 "76d23cd394eba9e6530316ed1184e219" 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/kokkos-cuda.cmake

@@ -10,7 +10,7 @@ get_filename_component(NVCC_WRAPPER_CMD ${CMAKE_CURRENT_SOURCE_DIR}/../lib/kokko
 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)
+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

@@ -13,7 +13,7 @@ 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)
+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/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/lammps.1

@@ -1,7 +1,7 @@
-.TH LAMMPS "1" "7 February 2024" "2024-02-07"
+.TH LAMMPS "1" "27 June 2024" "2024-06-27"
 .SH NAME
 .B LAMMPS
-\- Molecular Dynamics Simulator.  Version 7 February 2024
+\- 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

@@ -877,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_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
@@ -666,7 +660,7 @@ They must be specified in uppercase.
       - GPU
       - Intel GPU Ponte Vecchio
 
-This list was last updated for version 4.2 of the Kokkos library.
+This list was last updated for version 4.3.0 of the Kokkos library.
 
 .. tabs::
 

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>`
@@ -127,6 +128,7 @@ OPT.
    * :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

@@ -108,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>`

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>`
@@ -262,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>`
@@ -94,9 +94,10 @@ OPT.
    * :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>`
@@ -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,7 +270,7 @@ OPT.
    * :doc:`smd/ulsph <pair_smd_ulsph>`
    * :doc:`smtbq <pair_smtbq>`
    * :doc:`snap (ik) <pair_snap>`
-   * :doc:`soft (go) <pair_soft>`
+   * :doc:`soft (gko) <pair_soft>`
    * :doc:`sph/heatconduction (g) <pair_sph_heatconduction>`
    * :doc:`sph/idealgas <pair_sph_idealgas>`
    * :doc:`sph/lj (g) <pair_sph_lj>`
@@ -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

@@ -148,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_updating.rst

@@ -18,6 +18,7 @@ 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`_
@@ -130,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()
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -137,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:
 

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`
@@ -1255,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,
 

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>`
@@ -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_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_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/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_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/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

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

@@ -283,21 +283,22 @@ Note that there may be additional arguments required along with the
 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 normal unit
-vector (defined by normx, normy, normz), an area (area/patch), the
+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.
+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

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

doc/src/bond_oxdna.rst

@@ -27,6 +27,7 @@ Examples
 
 .. code-block:: LAMMPS
 
+   # LJ units
    bond_style oxdna/fene
    bond_coeff * 2.0 0.25 0.7525
 
@@ -36,6 +37,32 @@ Examples
    bond_style oxrna2/fene
    bond_coeff * 2.0 0.25 0.76107
 
+   bond_style oxdna/fene
+   bond_coeff * oxdna_lj.cgdna
+
+   # Real units
+   bond_style oxdna/fene
+   bond_coeff * 11.92337812042065 2.1295 6.409795
+
+   bond_style oxdna2/fene
+   bond_coeff * 11.92337812042065 2.1295 6.4430152
+
+   bond_style oxrna2/fene
+   bond_coeff * 11.92337812042065 2.1295 6.482800913
+
+   bond_style oxrna2/fene
+   bond_coeff * oxrna2_real.cgdna
+
+.. note::
+
+   The coefficients in the above examples have to be kept fixed and
+   cannot be changed without reparameterizing the entire model. They are
+   provided in forms compatible with both *units lj* and *units real*
+   (see documentation of :doc:`units <units>`).  These can also be read
+   from a potential file with correct unit style by specifying the name
+   of the file. Several potential files for each unit style are included
+   in the ``potentials`` directory of the LAMMPS distribution.
+
 Description
 """""""""""
 
@@ -46,15 +73,14 @@ The *oxdna/fene*, *oxdna2/fene*, and *oxrna2/fene* bond styles use the potential
    E = - \frac{\epsilon}{2} \ln \left[ 1 - \left(\frac{r-r_0}{\Delta}\right)^2\right]
 
 to define a modified finite extensible nonlinear elastic (FENE)
-potential :ref:`(Ouldridge) <Ouldridge0>` to model the connectivity of the
-phosphate backbone in the oxDNA/oxRNA force field for coarse-grained
+potential :ref:`(Ouldridge) <Ouldridge0>` to model the connectivity of
+the phosphate backbone in the oxDNA/oxRNA force field for coarse-grained
 modelling of DNA/RNA.
 
 The following coefficients must be defined for the bond type via the
 :doc:`bond_coeff <bond_coeff>` command as given in the above example, or
-in the data file or restart files read by the
-:doc:`read_data <read_data>` or :doc:`read_restart <read_restart>`
-commands:
+in the data file or restart files read by the :doc:`read_data
+<read_data>` or :doc:`read_restart <read_restart>` commands:
 
 * :math:`\epsilon` (energy)
 * :math:`\Delta` (distance)
@@ -62,41 +88,40 @@ commands:
 
 .. note::
 
-   The oxDNA bond style has to be used together with the
-   corresponding oxDNA pair styles for excluded volume interaction
-   *oxdna/excv* , stacking *oxdna/stk* , cross-stacking *oxdna/xstk* and
-   coaxial stacking interaction *oxdna/coaxstk* as well as
-   hydrogen-bonding interaction *oxdna/hbond* (see also documentation of
-   :doc:`pair_style oxdna/excv <pair_oxdna>`). For the oxDNA2
-   :ref:`(Snodin) <Snodin0>` bond style the analogous pair styles
-   *oxdna2/excv* , *oxdna2/stk* , *oxdna2/xstk* , *oxdna2/coaxstk* ,
-   *oxdna2/hbond* and an additional Debye-Hueckel pair style
-   *oxdna2/dh* have to be defined. The same applies to the oxRNA2
-   :ref:`(Sulc1) <Sulc01>` styles.
-   The coefficients in the above example have to be kept fixed and cannot
-   be changed without reparameterizing the entire model.
+   The oxDNA bond style has to be used together with the corresponding
+   oxDNA pair styles for excluded volume interaction *oxdna/excv* ,
+   stacking *oxdna/stk* , cross-stacking *oxdna/xstk* and coaxial
+   stacking interaction *oxdna/coaxstk* as well as hydrogen-bonding
+   interaction *oxdna/hbond* (see also documentation of :doc:`pair_style
+   oxdna/excv <pair_oxdna>`). For the oxDNA2 :ref:`(Snodin) <Snodin0>`
+   bond style the analogous pair styles *oxdna2/excv* , *oxdna2/stk* ,
+   *oxdna2/xstk* , *oxdna2/coaxstk* , *oxdna2/hbond* and an additional
+   Debye-Hueckel pair style *oxdna2/dh* have to be defined. The same
+   applies to the oxRNA2 :ref:`(Sulc1) <Sulc01>` styles.
 
 .. note::
 
-   This bond style has to be used with the *atom_style hybrid bond ellipsoid oxdna*
-   (see documentation of :doc:`atom_style <atom_style>`). The *atom_style oxdna*
-   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.
+   This bond style has to be used with the *atom_style hybrid bond
+   ellipsoid oxdna* (see documentation of :doc:`atom_style
+   <atom_style>`). The *atom_style oxdna* 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.
 
 .. warning::
 
-   If data files are produced with :doc:`write_data <write_data>`, then the
-   :doc:`newton <newton>` command should be set to *newton on* or *newton off on*.
-   Otherwise the data files will not have the same 3'-to-5' polarity as the
-   initial data file. This limitation does not apply to binary restart files
-   produced with :doc:`write_restart <write_restart>`.
+   If data files are produced with :doc:`write_data <write_data>`, then
+   the :doc:`newton <newton>` command should be set to *newton on* or
+   *newton off on*.  Otherwise the data files will not have the same
+   3'-to-5' polarity as the initial data file. This limitation does not
+   apply to binary restart files produced with :doc:`write_restart
+   <write_restart>`.
 
 Example input and data files for DNA and RNA duplexes can be found in
-examples/PACKAGES/cgdna/examples/oxDNA/ , /oxDNA2/ and /oxRNA2/.  A simple python
-setup tool which creates single straight or helical DNA strands, DNA/RNA
-duplexes or arrays of DNA/RNA duplexes can be found in
-examples/PACKAGES/cgdna/util/.
+``examples/PACKAGES/cgdna/examples/oxDNA/`, `.../oxDNA2/`` and
+``.../oxRNA2/``.  A simple python setup tool which creates single
+straight or helical DNA strands, DNA/RNA duplexes or arrays of DNA/RNA
+duplexes can be found in ``examples/PACKAGES/cgdna/util/``.
 
 Please cite :ref:`(Henrich) <Henrich0>` in any publication that uses
 this implementation. An updated documentation that contains general information
@@ -113,6 +138,39 @@ and for sequence-specific hydrogen-bonding and stacking interactions
 
 ----------
 
+Potential file reading
+""""""""""""""""""""""
+
+For each style oxdna, oxdna2 and oxrna2, the first parameter argument
+can be a filename, and if it is, no further arguments should be
+supplied. Therefore the following command:
+
+.. code-block:: LAMMPS
+
+   bond_style oxdna/fene
+   bond_coeff * oxdna_lj.cgdna
+
+will be interpreted as a request to read the (FENE) potential
+:ref:`(Ouldridge) <Ouldridge0>` parameters from the file with the given
+name.  The file can define multiple potential parameters for both bonded
+and pair interactions, but for the above bonded interactions there must
+exist in the file a line of the form:
+
+.. code-block:: LAMMPS
+
+   *   fene    epsilon delta r0
+
+There are sample potential files for each unit style in the
+``potentials`` directory of the LAMMPS distribution. The potential file
+unit system must align with the units defined via the :doc:`units
+<units>` command. For conversion between different *LJ* and *real* unit
+systems for oxDNA, the python tool *lj2real.py* located in the
+``examples/PACKAGES/cgdna/util/`` directory can be used. This tool
+assumes similar file structure to the examples found in
+``examples/PACKAGES/cgdna/examples/``.
+
+----------
+
 Restrictions
 """"""""""""
 

doc/src/boundary.rst

@@ -42,8 +42,10 @@ commands.
 The style *p* means the box is periodic, so that particles interact
 across the boundary, and they can exit one end of the box and re-enter
 the other end.  A periodic dimension can change in size due to
-constant pressure boundary conditions or box deformation (see the :doc:`fix npt <fix_nh>` and :doc:`fix deform <fix_deform>` commands).  The *p*
-style must be applied to both faces of a dimension.
+constant pressure boundary conditions or box deformation (see the
+:doc:`fix npt <fix_nh>` and :doc:`fix deform <fix_deform>` commands).
+The *p* style must be applied to both faces of a dimension.  For 2d
+simulations the z dimension must be periodic (which is the default).
 
 The styles *f*, *s*, and *m* mean the box is non-periodic, so that
 particles do not interact across the boundary and do not move from one
@@ -76,28 +78,44 @@ atoms becomes less than 50.0.  This can be useful if you start a
 simulation with an empty box or if you wish to leave room on one side
 of the box, e.g. for atoms to evaporate from a surface.
 
-For triclinic (non-orthogonal) simulation boxes, if the second dimension
-of a tilt factor (e.g. y for xy) is periodic, then the periodicity is
-enforced with the tilt factor offset.  If the first dimension is
-shrink-wrapped, then the shrink wrapping is applied to the tilted box
-face, to encompass the atoms.  E.g. for a positive xy tilt, the xlo
-and xhi faces of the box are planes tilting in the +y direction as y
-increases.  These tilted planes are shrink-wrapped around the atoms to
-determine the x extent of the box.
-
+LAMMPS also allows use of triclinic (non-orthogonal) simulation boxes.
 See the :doc:`Howto triclinic <Howto_triclinic>` page for a
-geometric description of triclinic boxes, as defined by LAMMPS, and
-how to transform these parameters to and from other commonly used
-triclinic representations.
+description of both general and restricted triclinic boxes and how to
+define them.  General triclinic boxes (arbitrary edge vectors **A**,
+**B**, and **C**) are converted internally to restricted triclinic
+boxes with tilt factors (xy,xz,yz) which skew an otherwise orthogonal
+box.
+
+The boundary <boundary> command settings explained above for the 6
+faces of an orthogonal box also apply in similar manner to the 6 faces
+of a restricted triclinic box (and thus to the corresponding 6 faces
+of a general triclinic box), with the following context.
+
+if the second dimension of a tilt factor (e.g. y for xy) is periodic,
+then the periodicity is enforced with the tilt factor offset.  This
+means that for y periodicity a particle which exits the lower y
+boundary is displaced in the x-direction by xy before it re-enters the
+upper y boundary.  And vice versa if a particle exits the upper y
+boundary.  Likewise the ghost atoms surrounding a particle near the
+lower y boundary include images of particles near the upper y-boundary
+which are displaced in the x-direction by xy.  Similar rules apply for
+z-periodicity and the xz and/or yz tilt factors.
+
+If the first dimension of a tilt factor is shrink-wrapped, then the
+shrink wrapping is applied to the tilted box face, to encompass the
+atoms.  E.g. for a positive xy tilt, the xlo and xhi faces of the box
+are planes tilting in the +y direction as y increases.  The position
+of these tilted planes are adjusted dynamically to shrink-wrap around
+the atoms to determine the xlo and xhi extents of the box.
 
 Restrictions
 """"""""""""
 
 This command cannot be used after the simulation box is defined by a
-:doc:`read_data <read_data>` or :doc:`create_box <create_box>` command or
-:doc:`read_restart <read_restart>` command.  See the
-:doc:`change_box <change_box>` command for how to change the simulation
-box boundaries after it has been defined.
+:doc:`read_data <read_data>` or :doc:`create_box <create_box>` command
+or :doc:`read_restart <read_restart>` command.  See the
+:doc:`change_box <change_box>` command for how to change the
+simulation box boundaries after it has been defined.
 
 For 2d simulations, the z dimension must be periodic.
 

doc/src/compute.rst

@@ -272,6 +272,10 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
 * :doc:`pe/mol/tally <compute_tally>` - potential energy between two groups of atoms separated into intermolecular and intramolecular components via the tally callback mechanism
 * :doc:`pe/tally <compute_tally>` - potential energy between two groups of atoms via the tally callback mechanism
 * :doc:`plasticity/atom <compute_plasticity_atom>` - Peridynamic plasticity for each atom
+* :doc:`pod/atom <compute_pod_atom>` - POD descriptors for each atom
+* :doc:`podd/atom <compute_pod_atom>` - derivative of POD descriptors for each atom
+* :doc:`pod/local <compute_pod_atom>` - local POD descriptors and their derivatives
+* :doc:`pod/global <compute_pod_atom>` - global POD descriptors and their derivatives
 * :doc:`pressure <compute_pressure>` - total pressure and pressure tensor
 * :doc:`pressure/alchemy <compute_pressure_alchemy>` - mixed system total pressure and pressure tensor for :doc:`fix alchemy <fix_alchemy>` runs
 * :doc:`pressure/uef <compute_pressure_uef>` - pressure tensor in the reference frame of an applied flow field

doc/src/compute_adf.rst

@@ -204,8 +204,23 @@ angles per atom satisfying the ADF criteria.
 Restrictions
 """"""""""""
 
-This compute is part of the EXTRA-COMPUTE package.  It is only enabled if
-LAMMPS was built with that package.  See the :doc:`Build package <Build_package>` page for more info.
+This compute is part of the EXTRA-COMPUTE package.  It is only enabled
+if LAMMPS was built with that package.  See the :doc:`Build package
+<Build_package>` page for more info.
+
+By default, the ADF is not computed for distances longer than the
+largest force cutoff, since the neighbor list creation will only contain
+pairs up to that distance (plus neighbor list skin).  If you use outer
+cutoffs larger than that, you must use :doc:`neighbor style 'bin' or
+'nsq' <neighbor>`.
+
+If you want an ADF for a larger outer cutoff, you can also use the
+:doc:`rerun <rerun>` command to post-process a dump file, use :doc:`pair
+style zero <pair_zero>` and set the force cutoff to be larger in the
+rerun script.  Note that in the rerun context, the force cutoff is
+arbitrary and with pair style zero you are not computing any forces, and
+since you are not running dynamics you are not changing the model that
+generated the trajectory.
 
 The ADF is not computed for neighbors outside the force cutoff,
 since processors (in parallel) don't know about atom coordinates for

doc/src/compute_ave_sphere_atom.rst

@@ -102,6 +102,8 @@ This compute is part of the EXTRA-COMPUTE package.  It is only enabled
 if LAMMPS was built with that package.  See the :doc:`Build package
 <Build_package>` page for more info.
 
+This compute requires :doc:`neighbor styles 'bin' or 'nsq' <neighbor>`.
+
 Related commands
 """"""""""""""""
 

doc/src/compute_composition_atom.rst

@@ -107,6 +107,8 @@ This compute is part of the EXTRA-COMPUTE package.  It is only enabled
 if LAMMPS was built with that package.  See the :doc:`Build package
 <Build_package>` page for more info.
 
+This compute requires :doc:`neighbor styles 'bin' or 'nsq' <neighbor>`.
+
 Related commands
 """"""""""""""""
 

doc/src/compute_count_type.rst

@@ -12,7 +12,7 @@ Syntax
 
 * ID, group-ID are documented in :doc:`compute <compute>` command
 * count/type = style name of this compute command
-* mode = {atom} or {bond} or {angle} or {dihedral} or {improper}
+* mode = *atom* or *bond* or *angle* or *dihedral* or *improper*
 
 Examples
 """"""""
@@ -69,29 +69,42 @@ for each type:
 
 ----------
 
-If the {mode} setting is {atom} then the count of atoms for each atom
+If the *mode* setting is *atom* then the count of atoms for each atom
 type is tallied.  Only atoms in the specified group are counted.
 
-If the {mode} setting is {bond} then the count of bonds for each bond
+The atom count for each type can be normalized by the total number of
+atoms like so:
+
+.. code-block:: LAMMPS
+
+   compute typevec all count/type atom # number of atoms of each type
+   variable normtypes vector c_typevec/atoms # divide by total number of atoms
+   variable ntypes equal extract_setting(ntypes) # number of atom types
+   thermo_style custom step v_normtypes[*${ntypes}] # vector variable needs upper limit
+
+Similarly, bond counts can be normalized by the total number of bonds.
+The same goes for angles, dihedrals, and impropers (see below).
+
+If the *mode* setting is *bond* then the count of bonds for each bond
 type is tallied.  Only bonds with both atoms in the specified group
 are counted.
 
-For {mode} = {bond}, broken bonds with a bond type of zero are also
+For *mode* = *bond*, broken bonds with a bond type of zero are also
 counted.  The :doc:`bond_style quartic <bond_quartic>` and :doc:`BPM
-bond styles <Howto_bpm>` break bonds by doing this.  See the :doc:`
-Howto broken bonds <Howto_broken_bonds>` doc page for more details.
+bond styles <Howto_bpm>` break bonds by doing this.  See the
+:doc:`Howto broken bonds <Howto_broken_bonds>` doc page for more details.
 Note that the group setting is ignored for broken bonds; all broken
 bonds in the system are counted.
 
-If the {mode} setting is {angle} then the count of angles for each
+If the *mode* setting is *angle* then the count of angles for each
 angle type is tallied.  Only angles with all 3 atoms in the specified
 group are counted.
 
-If the {mode} setting is {dihedral} then the count of dihedrals for
+If the *mode* setting is *dihedral* then the count of dihedrals for
 each dihedral type is tallied.  Only dihedrals with all 4 atoms in the
 specified group are counted.
 
-If the {mode} setting is {improper} then the count of impropers for
+If the *mode* setting is *improper* then the count of impropers for
 each improper type is tallied.  Only impropers with all 4 atoms in the
 specified group are counted.
 
@@ -101,18 +114,19 @@ Output info
 """""""""""
 
 This compute calculates a global vector of counts.  If the mode is
-{atom} or {bond} or {angle} or {dihedral} or {improper}, then the
+*atom* or *bond* or *angle* or *dihedral* or *improper*, then the
 vector length is the number of atom types or bond types or angle types
 or dihedral types or improper types, respectively.
 
-If the mode is {bond} this compute also calculates a global scalar
+If the mode is *bond* this compute also calculates a global scalar
 which is the number of broken bonds with type = 0, as explained above.
 
 These values can be used by any command that uses global scalar or
 vector values from a compute as input.  See the :doc:`Howto output
 <Howto_output>` page for an overview of LAMMPS output options.
 
-The scalar and vector values calculated by this compute are "extensive".
+The scalar and vector values calculated by this compute are both
+"intensive".
 
 Restrictions
 """"""""""""

doc/src/compute_efield_wolf_atom.rst

@@ -106,6 +106,8 @@ Restrictions
 This compute is part of the EXTRA-COMPUTE package. It is only enabled if
 LAMMPS was built with that package.
 
+This compute requires :doc:`neighbor styles 'bin' or 'nsq' <neighbor>`.
+
 Related commands
 """"""""""""""""
 

doc/src/compute_fabric.rst

@@ -64,7 +64,7 @@ tangential force tensor. The contact tensor is calculated as
 
 .. math::
 
-   C_{ab}  =  \frac{15}{2} (\phi_{ab} - \mathrm{Tr}(\phi) \delta_{ab})
+   C_{ab}  =  \frac{15}{2} (\phi_{ab} - \frac{1}{3} \mathrm{Tr}(\phi) \delta_{ab})
 
 where :math:`a` and :math:`b` are the :math:`x`, :math:`y`, :math:`z`
 directions, :math:`\delta_{ab}` is the Kronecker delta function, and
@@ -83,7 +83,7 @@ The branch tensor is calculated as
 
 .. math::
 
-   B_{ab}  =  \frac{15}{6 \mathrm{Tr}(D)} (D_{ab} - \mathrm{Tr}(D) \delta_{ab})
+   B_{ab}  =  \frac{15}{2\, \mathrm{Tr}(D)} (D_{ab} - \frac{1}{3} \mathrm{Tr}(D) \delta_{ab})
 
 where the tensor :math:`D` is defined as
 
@@ -101,7 +101,7 @@ The normal force fabric tensor is calculated as
 
 .. math::
 
-   F^n_{ab}  =  \frac{15}{6\, \mathrm{Tr}(N)} (N_{ab} - \mathrm{Tr}(N) \delta_{ab})
+   F^n_{ab}  =  \frac{15}{2\, \mathrm{Tr}(N)} (N_{ab} - \frac{1}{3} \mathrm{Tr}(N) \delta_{ab})
 
 where the tensor :math:`N` is defined as
 
@@ -119,7 +119,7 @@ as
 
 .. math::
 
-   F^t_{ab}  =  \frac{15}{9\, \mathrm{Tr}(N)} (T_{ab} - \mathrm{Tr}(T) \delta_{ab})
+   F^t_{ab}  =  \frac{5}{\mathrm{Tr}(N)} (T_{ab} - \frac{1}{3} \mathrm{Tr}(T) \delta_{ab})
 
 where the tensor :math:`T` is defined as
 

doc/src/compute_mliap.rst

@@ -20,7 +20,7 @@ Syntax
        *model* values = style
          style = *linear* or *quadratic* or *mliappy*
        *descriptor* values = style filename
-         style = *sna*
+         style = *sna* or *ace*
          filename = name of file containing descriptor definitions
        *gradgradflag* value = 0/1
          toggle gradgrad method for force gradient
@@ -31,6 +31,7 @@ Examples
 .. code-block:: LAMMPS
 
    compute mliap model linear descriptor sna Ta06A.mliap.descriptor
+   compute mliap model linear descriptor ace H_N_O_ccs.yace gradgradflag 1
 
 Description
 """""""""""
@@ -40,18 +41,15 @@ of machine-learning interatomic potentials with respect to model parameters.
 It is used primarily for calculating the gradient of energy, force, and
 stress components with respect to model parameters, which is useful when
 training :doc:`mliap pair_style <pair_mliap>` models to match target data.
-It provides separate
-definitions of the interatomic potential functional form (*model*)
-and the geometric quantities that characterize the atomic positions
-(*descriptor*). By defining *model* and *descriptor* separately,
+It provides separate definitions of the interatomic potential functional
+form (*model*) and the geometric quantities that characterize the atomic
+positions (*descriptor*). By defining *model* and *descriptor* separately,
 it is possible to use many different models with a given descriptor,
-or many different descriptors with a given model. Currently, the
-compute supports just two models, *linear* and *quadratic*,
-and one descriptor, *sna*, the SNAP descriptor used by
-:doc:`pair_style snap <pair_snap>`, including the linear, quadratic,
-and chem variants. Work is currently underway to extend
-the interface to handle neural network energy models,
-and it is also straightforward to add new descriptor styles.
+or many different descriptors with a given model. Currently, the compute
+supports *linear* and *quadratic* SNAP descriptor computes used in
+:doc:`pair_style snap <pair_snap>`, *linear* SO3 descriptor computes, and
+*linear* ACE descriptor computes used in :doc:`pair_style pace <pair_pace>`,
+and it is straightforward to add new descriptor styles.
 
 The compute *mliap* command must be followed by two keywords
 *model* and *descriptor* in either order.
@@ -60,19 +58,31 @@ The *model* keyword is followed by the model style (*linear*,
 *quadratic* or *mliappy*).  The *mliappy* model is only available if
 LAMMPS is built with the *mliappy* Python module. There are
 :ref:`specific installation instructions <mliap>` for that module.
+For the *mliap* compute, specifying a *linear* model will compute the
+specified descriptors and gradients with respect to linear model parameters
+whereas *quadratic* will do the same, but for the quadratic products of
+descriptors.
 
 The *descriptor* keyword is followed by a descriptor style, and
-additional arguments.  The compute currently supports two descriptor
-styles *sna* and *so3*, but it is is straightforward to add additional
-descriptor styles.  The SNAP descriptor style *sna* is the same as that
-used by :doc:`pair_style snap <pair_snap>`, including the linear,
-quadratic, and chem variants.  A single additional argument specifies
-the descriptor filename containing the parameters and setting used by
-the SNAP descriptor.  The descriptor filename usually ends in the
+additional arguments.  The compute currently supports three descriptor
+styles: *sna*, *so3*, and *ace*, but it is is straightforward to add
+additional descriptor styles.  The SNAP descriptor style *sna* is the
+same as that used by :doc:`pair_style snap <pair_snap>`, including the
+linear, quadratic, and chem variants.  A single additional argument
+specifies the descriptor filename containing the parameters and setting used
+by the SNAP descriptor.  The descriptor filename usually ends in the
 *.mliap.descriptor* extension.  The format of this file is identical to
 the descriptor file in the :doc:`pair_style mliap <pair_mliap>`, and is
 described in detail there.
 
+The ACE descriptor style *ace* is the same as :doc:`pair_style pace <pair_pace>`.
+A single additional argument specifies the *ace* descriptor filename
+that contains parameters and settings for the ACE descriptors. This file
+format differs from the SNAP or SO3 descriptor files, and has a *.yace* or
+*.ace* extension. However, as with other mliap descriptor styles, this file
+is identical to the ace descriptor file in :doc:`pair_style mliap <pair_mliap>`,
+where it is described in further detail.
+
 .. note::
 
    The number of LAMMPS atom types (and the value of *nelems* in the model)
@@ -172,8 +182,10 @@ This compute is part of the ML-IAP package.  It is only enabled if
 LAMMPS was built with that package. In addition, building LAMMPS with
 the ML-IAP package requires building LAMMPS with the ML-SNAP package.
 The *mliappy* model also requires building LAMMPS with the PYTHON
-package.  See the :doc:`Build package <Build_package>` page for more
-info.
+package. The *ace* descriptor also requires building LAMMPS with the
+ML-PACE package. See the :doc:`Build package <Build_package>` page for
+more info. Note that `kk` (KOKKOS) accelerated variants of SNAP and
+ACE descriptors are not compatible with `mliap descriptor`.
 
 Related commands
 """"""""""""""""

doc/src/compute_pod_atom.rst

@@ -0,0 +1,145 @@
+.. index:: compute pod/atom
+.. index:: compute podd/atom
+.. index:: compute pod/local
+.. index:: compute pod/global
+
+compute pod/atom command
+========================
+
+compute podd/atom command
+=========================
+
+compute pod/local command
+=========================
+
+compute pod/global command
+==========================
+
+Syntax
+""""""
+
+.. code-block:: LAMMPS
+
+   compute ID group-ID pod/atom param.pod coefficients.pod
+   compute ID group-ID podd/atom param.pod coefficients.pod
+   compute ID group-ID pod/local param.pod coefficients.pod
+   compute ID group-ID pod/global param.pod coefficients.pod
+
+* ID, group-ID are documented in :doc:`compute <compute>` command
+* pod/atom = style name of this compute command
+* param.pod = the parameter file specifies parameters of the POD descriptors
+* coefficients.pod = the coefficient file specifies coefficients of the POD potential
+
+Examples
+""""""""
+
+.. code-block:: LAMMPS
+
+   compute d all pod/atom Ta_param.pod
+   compute dd all podd/atom Ta_param.pod
+   compute ldd all pod/local Ta_param.pod
+   compute gdd all podd/global Ta_param.pod
+   compute d all pod/atom Ta_param.pod Ta_coefficients.pod
+   compute dd all podd/atom Ta_param.pod Ta_coefficients.pod
+   compute ldd all pod/local Ta_param.pod Ta_coefficients.pod
+   compute gdd all podd/global Ta_param.pod Ta_coefficients.pod
+
+Description
+"""""""""""
+
+.. versionadded:: 27June2024
+
+Define a computation that calculates a set of quantities related to the
+POD descriptors of the atoms in a group. These computes are used
+primarily for calculating the dependence of energy and force components
+on the linear coefficients in the :doc:`pod pair_style <pair_pod>`,
+which is useful when training a POD potential to match target data. POD
+descriptors of an atom are characterized by the radial and angular
+distribution of neighbor atoms. The detailed mathematical definition is
+given in the papers by :ref:`(Nguyen and Rohskopf) <Nguyen20222c>`,
+:ref:`(Nguyen2023) <Nguyen20232c>`, :ref:`(Nguyen2024) <Nguyen20242c>`,
+and :ref:`(Nguyen and Sema) <Nguyen20243c>`.
+
+Compute *pod/atom* calculates the per-atom POD descriptors.
+
+Compute *podd/atom* calculates derivatives of the per-atom POD
+descriptors with respect to atom positions.
+
+Compute *pod/local* calculates the per-atom POD descriptors and their
+derivatives with respect to atom positions.
+
+Compute *pod/global* calculates the global POD descriptors and their
+derivatives with respect to atom positions.
+
+Examples how to use Compute POD commands are found in the directory
+``examples/PACKAGES/pod``.
+
+
+.. warning::
+
+   All of these compute styles produce *very* large per-atom output
+   arrays that scale with the total number of atoms in the system.
+   This will result in *very* large memory consumption for systems
+   with a large number of atoms.
+
+----------
+
+Output info
+"""""""""""
+
+Compute *pod/atom* produces an 2D array of size :math:`N \times M`,
+where :math:`N` is the number of atoms and :math:`M` is the number of
+descriptors. Each column corresponds to a particular POD descriptor.
+
+Compute *podd/atom* produces an 2D array of size :math:`N \times (M * 3
+N)`. Each column corresponds to a particular derivative of a POD
+descriptor.
+
+Compute *pod/local* produces an 2D array of size :math:`(1 + 3N) \times
+(M * N)`.  The first row contains the per-atom descriptors, and the last
+3N rows contain the derivatives of the per-atom descriptors with respect
+to atom positions.
+
+Compute *pod/global* produces an 2D array of size :math:`(1 + 3N) \times
+(M)`.  The first row contains the global descriptors, and the last 3N
+rows contain the derivatives of the global descriptors with respect to
+atom positions.
+
+Restrictions
+""""""""""""
+
+These computes are part of the ML-POD package.  They are only enabled
+if LAMMPS was built with that package.  See the :doc:`Build package
+<Build_package>` page for more info.
+
+Related commands
+""""""""""""""""
+
+:doc:`fitpod <fitpod_command>`,
+:doc:`pair_style pod <pair_pod>`
+
+
+Default
+"""""""
+
+none
+
+----------
+
+.. _Nguyen20222c:
+
+**(Nguyen and Rohskopf)** Nguyen and Rohskopf,  Journal of Computational Physics, 480, 112030, (2023).
+
+.. _Nguyen20232c:
+
+**(Nguyen2023)** Nguyen, Physical Review B, 107(14), 144103, (2023).
+
+.. _Nguyen20242c:
+
+**(Nguyen2024)** Nguyen, Journal of Computational Physics, 113102, (2024).
+
+.. _Nguyen20243c:
+
+**(Nguyen and Sema)** Nguyen and Sema, https://arxiv.org/abs/2405.00306, (2024).
+
+

doc/src/compute_pressure.rst

@@ -153,7 +153,8 @@ Related commands
 Default
 """""""
 
-none
+By default the compute includes contributions from the keywords:
+``ke pair bond angle dihedral improper kspace fix``
 
 ----------
 

doc/src/compute_property_atom.rst

@@ -23,8 +23,9 @@ Syntax
                              spx, spy, spz, sp, fmx, fmy, fmz,
                              nbonds,
                              radius, diameter, omegax, omegay, omegaz,
+                             temperature, heatflow,
                              angmomx, angmomy, angmomz,
-                             shapex,shapey, shapez,
+                             shapex, shapey, shapez,
                              quatw, quati, quatj, quatk, tqx, tqy, tqz,
                              end1x, end1y, end1z, end2x, end2y, end2z,
                              corner1x, corner1y, corner1z,
@@ -56,6 +57,8 @@ Syntax
            *nbonds* = number of bonds assigned to an atom
            *radius,diameter* = radius,diameter of spherical particle
            *omegax,omegay,omegaz* = angular velocity of spherical particle
+           *temperature* = internal temperature of spherical particle
+           *heatflow* = internal heat flow of spherical particle
            *angmomx,angmomy,angmomz* = angular momentum of aspherical particle
            *shapex,shapey,shapez* = 3 diameters of aspherical particle
            *quatw,quati,quatj,quatk* = quaternion components for aspherical or body particles

doc/src/compute_rdf.rst

@@ -13,8 +13,8 @@ Syntax
 * ID, group-ID are documented in :doc:`compute <compute>` command
 * rdf = style name of this compute command
 * Nbin = number of RDF bins
-* itypeN = central atom type for Nth RDF histogram (see asterisk form below)
-* jtypeN = distribution atom type for Nth RDF histogram (see asterisk form below)
+* itypeN = central atom type for Nth RDF histogram (integer, type label, or asterisk form)
+* jtypeN = distribution atom type for Nth RDF histogram (integer, type label, or asterisk form)
 * zero or more keyword/value pairs may be appended
 * keyword = *cutoff*
 
@@ -96,14 +96,16 @@ is computed for :math:`g(r)` between all atom types.  If one or more pairs are
 listed, then a separate histogram is generated for each
 *itype*,\ *jtype* pair.
 
-The *itypeN* and *jtypeN* settings can be specified in one of two
-ways.  An explicit numeric value can be used, as in the fourth example
-above.  Or a wild-card asterisk can be used to specify a range of atom
-types.  This takes the form "\*" or "\*n" or "m\*" or "m\*n".  If
-:math:`N` is the number of atom types, then an asterisk with no numeric values
-means all types from 1 to :math:`N`. A leading asterisk means all types from 1
-to n (inclusive).  A trailing asterisk means all types from m to :math:`N`
-(inclusive).  A middle asterisk means all types from m to n (inclusive).
+The *itypeN* and *jtypeN* settings can be specified in one of three
+ways.  One or both of the types in the I,J pair can be a
+:doc:`type label <Howto_type_labels>`.  Or an explicit numeric value can be
+used, as in the fourth example above. Or a wild-card asterisk can be used
+to specify a range of atom types.  This takes the form "\*" or "\*n" or
+"m\*" or "m\*n". If :math:`N` is the number of atom types, then an asterisk
+with no numeric values means all types from 1 to :math:`N`. A leading
+asterisk means all types from 1 to n (inclusive).  A trailing asterisk
+means all types from m to :math:`N` (inclusive).  A middle asterisk means
+all types from m to n (inclusive).
 
 If both *itypeN* and *jtypeN* are single values, as in the fourth example
 above, this means that a :math:`g(r)` is computed where atoms of type *itypeN*
@@ -176,22 +178,29 @@ also numbers :math:`\ge 0.0`.
 Restrictions
 """"""""""""
 
-The RDF is not computed for distances longer than the force cutoff,
-since processors (in parallel) do not know about atom coordinates for
-atoms further away than that distance.  If you want an RDF for larger
-distances, you can use the :doc:`rerun <rerun>` command to post-process
-a dump file and set the cutoff for the potential to be longer in the
+By default, the RDF is not computed for distances longer than the
+largest force cutoff, since the neighbor list creation will only contain
+pairs up to that distance (plus neighbor list skin).  This distance can
+be increased using the *cutoff* keyword but this keyword is only valid
+with :doc:`neighbor styles 'bin' and 'nsq' <neighbor>`.
+
+If you want an RDF for larger distances, you can also use the
+:doc:`rerun <rerun>` command to post-process a dump file, use :doc:`pair
+style zero <pair_zero>` and set the force cutoff to be longer in the
 rerun script.  Note that in the rerun context, the force cutoff is
-arbitrary, since you are not running dynamics and thus are not changing
-your model.  The definition of :math:`g(r)` used by LAMMPS is only appropriate
-for characterizing atoms that are uniformly distributed throughout the
-simulation cell. In such cases, the coordination number is still
-correct and meaningful.  As an example, if a large simulation cell
-contains only one atom of type *itypeN* and one of *jtypeN*, then :math:`g(r)`
-will register an arbitrarily large spike at whatever distance they
-happen to be at, and zero everywhere else.
-The function :math:`\text{coord}(r)` will show a step
-change from zero to one at the location of the spike in :math:`g(r)`.
+arbitrary and with pair style zero you are not computing any forces, and
+you are not running dynamics you are not changing the model that
+generated the trajectory.
+
+The definition of :math:`g(r)` used by LAMMPS is only appropriate for
+characterizing atoms that are uniformly distributed throughout the
+simulation cell. In such cases, the coordination number is still correct
+and meaningful.  As an example, if a large simulation cell contains only
+one atom of type *itypeN* and one of *jtypeN*, then :math:`g(r)` will
+register an arbitrarily large spike at whatever distance they happen to
+be at, and zero everywhere else.  The function :math:`\text{coord}(r)`
+will show a step change from zero to one at the location of the spike in
+:math:`g(r)`.
 
 .. note::
 

doc/src/compute_reduce.rst

@@ -56,8 +56,9 @@ Examples
    compute 1 all reduce sum c_force
    compute 1 all reduce/region subbox sum c_force
    compute 2 all reduce min c_press[2] f_ave v_myKE
-   compute 2 all reduce min c_press[*] f_ave v_myKE
+   compute 2 all reduce min c_press[*] f_ave v_myKE inputs peratom
    compute 3 fluid reduce max c_index[1] c_index[2] c_dist replace 1 3 replace 2 3
+   compute 4 all reduce max c_bond inputs local
 
 Description
 """""""""""

doc/src/compute_stress_atom.rst

@@ -289,7 +289,8 @@ Related commands
 Default
 """""""
 
-none
+By default the compute includes contributions from the keywords:
+``ke pair bond angle dihedral improper kspace fix``
 
 ----------
 

doc/src/compute_stress_mop.rst

@@ -126,16 +126,19 @@ These styles are part of the EXTRA-COMPUTE package. They are only
 enabled if LAMMPS is built with that package. See the :doc:`Build
 package <Build_package>` doc page on for more info.
 
-The method is only implemented for 3d orthogonal simulation boxes whose
+The method is implemented for orthogonal simulation boxes whose
 size does not change in time, and axis-aligned planes.
 
 The method only works with two-body pair interactions, because it
 requires the class method ``Pair::single()`` to be implemented, which is
 not possible for manybody potentials.  In particular, compute
-*stress/mop/profile* and *stress/mop* do not work with more than two-body pair
-interactions, long range (kspace) interactions and
+*stress/mop/profile* and *stress/mop* do not work with more than two-body
+pair interactions, long range (kspace) interactions and
 improper intramolecular interactions.
 
+The impact of fixes that affect the stress (e.g. fix langevin) is
+also not included in the stress computed here.
+
 Related commands
 """"""""""""""""
 

doc/src/create_atoms.rst

@@ -10,7 +10,7 @@ Syntax
 
    create_atoms type style args keyword values ...
 
-* type = atom type (1-Ntypes) of atoms to create (offset for molecule creation)
+* type = atom type (1-Ntypes or type label) of atoms to create (offset for molecule creation)
 * style = *box* or *region* or *single* or *mesh* or *random*
 
   .. parsed-literal::
@@ -37,7 +37,7 @@ Syntax
          seed = random # seed (positive integer)
        *basis* values = M itype
          M = which basis atom
-         itype = atom type (1-N) to assign to this basis atom
+         itype = atom type (1-Ntypes or type label) to assign to this basis atom
        *ratio* values = frac seed
          frac = fraction of lattice sites (0 to 1) to populate randomly
          seed = random # seed (positive integer)
@@ -74,6 +74,13 @@ Examples
 .. code-block:: LAMMPS
 
    create_atoms 1 box
+
+   labelmap atom 1 Pt
+   create_atoms Pt box
+
+   labelmap atom 1 C 2 Si
+   create_atoms C region regsphere basis Si C
+
    create_atoms 3 region regsphere basis 2 3
    create_atoms 3 region regsphere basis 2 3 ratio 0.5 74637
    create_atoms 3 single 0 0 5
@@ -86,25 +93,46 @@ Description
 """""""""""
 
 This command creates atoms (or molecules) within the simulation box,
-either on a lattice, or a single atom (or molecule), or on a surface
-defined by a triangulated mesh, or a random collection of atoms (or
-molecules).  It is an alternative to reading in atom coordinates
+either on a lattice, or at random points, or on a surface defined by a
+triangulated mesh.  Or it creates a single atom (or molecule) at a
+specified point.  It is an alternative to reading in atom coordinates
 explicitly via a :doc:`read_data <read_data>` or :doc:`read_restart
-<read_restart>` command.  A simulation box must already exist, which is
+<read_restart>` command.
+
+To use this command a simulation box must already exist, which is
 typically created via the :doc:`create_box <create_box>` command.
-Before using this command, a lattice must also be defined using the
-:doc:`lattice <lattice>` command, unless you specify the *single* style
-with units = box or the *random* style.  For the remainder of this doc
-page, a created atom or molecule is referred to as a "particle".
+Before using this command, a lattice must typically also be defined
+using the :doc:`lattice <lattice>` command, unless you specify the
+*single* or *mesh* style with units = box or the *random* style.  To
+create atoms on a lattice for general triclinic boxes, see the
+discussion below.
+
+For the remainder of this doc page, a created atom or molecule is
+referred to as a "particle".
 
 If created particles are individual atoms, they are assigned the
 specified atom *type*, though this can be altered via the *basis*
 keyword as discussed below.  If molecules are being created, the type
-of each atom in the created molecule is specified in the file read by
-the :doc:`molecule <molecule>` command, and those values are added to
-the specified atom *type* (e.g., if *type* = 2 and the file specifies
-atom types 1, 2, and 3, then each created molecule will have atom types
-3, 4, and 5).
+of each atom in the created molecule is specified in a specified file
+read by the :doc:`molecule <molecule>` command, and those values are
+added to the specified atom *type* (e.g., if *type* = 2 and the file
+specifies atom types 1, 2, and 3, then each created molecule will have
+atom types 3, 4, and 5).
+
+.. note::
+
+   You cannot use this command to create atoms that are outside the
+   simulation box; they will just be ignored by LAMMPS.  This is true
+   even if you are using shrink-wrapped box boundaries, as specified
+   by the :doc:`boundary <boundary>` command.  However, you can first
+   use the :doc:`change_box <change_box>` command to temporarily
+   expand the box, then add atoms via create_atoms, then finally use
+   change_box command again if needed to re-shrink-wrap the new atoms.
+   See the :doc:`change_box <change_box>` doc page for an example of
+   how to do this, using the create_atoms *single* style to insert a
+   new atom outside the current simulation box.
+
+----------
 
 For the *box* style, the create_atoms command fills the entire
 simulation box with particles on the lattice.  If your simulation box
@@ -126,10 +154,117 @@ periodic boundaries.  If this is desired, you should either use the
 *box* style, or tweak the region size to get precisely the particles
 you want.
 
+----------
+
+If the simulation box is formulated as a general triclinic box defined
+by arbitrary edge vectors **A**, **B**, **C**, then the *box* and
+*region* styles will create atoms on a lattice commensurate with those
+edge vectors.  See the :doc:`Howto_triclinic <Howto_triclinic>` doc
+page for a detailed explanation of orthogonal, restricted triclinic,
+and general triclinic simulation boxes.  As with the :doc:`create_box
+<create_box>` command, the :doc:`lattice <lattice>` command used by
+this command must be of style *custom* and use its *triclinic/general*
+option.  The *a1, *a2*, *a3* settings of the :doc:`lattice <lattice>`
+command define the edge vectors of a unit cell of the general
+triclinic lattice. The :doc:`create_box <create_box>` command creates
+a simulation box which replicates that unit cell along each of the
+**A**, **B**, **C** edge vectors.
+
+.. note::
+
+   LAMMPS allows specification of general triclinic simulation boxes
+   as a convenience for users who may be converting data from
+   solid-state crystallographic representations or from DFT codes for
+   input to LAMMPS.  However, as explained on the
+   :doc:`Howto_triclinic <Howto_triclinic>` doc page, internally,
+   LAMMPS only uses restricted triclinic simulation boxes.  This means
+   the box created by the :doc:`create_box <create_box>` command as
+   well as the atoms created by this command with their per-atom
+   information (e.g. coordinates, velocities) are converted (rotated)
+   from general to restricted triclinic form when the two commands are
+   invoked.  The <Howto_triclinic>` doc page also discusses other
+   LAMMPS commands which can input/output general triclinic
+   representations of the simulation box and per-atom data.
+
+The *box* style will fill the entire general triclinic box with
+particles on the lattice, as explained above.
+
+.. note::
+
+    The *region* style also operates as explained above, but the check
+    for particles inside the region is performed *after* the particle
+    coordinates have been converted to the restricted triclinic box.
+    This means the region must also be defined with respect to the
+    restricted triclinic box, not the general triclinic box.
+
+If the simulation box is general triclinic, the *single*, *random*,
+and *mesh* styles described next operate on the box *after* it has
+been converted to restricted triclinic.  So all the settings for those
+styles should be made in that context.
+
+----------
+
 For the *single* style, a single particle is added to the system at
 the specified coordinates.  This can be useful for debugging purposes
 or to create a tiny system with a handful of particles at specified
-positions.
+positions.  For a 2d simulation the specified z coordinate must be
+0.0.
+
+.. versionchanged:: 2Jun2022
+
+The *porosity* style has been renamed to *random* with added functionality.
+
+For the *random* style, *N* particles are added to the system at
+randomly generated coordinates, which can be useful for generating an
+amorphous system.  For 2d simulations, the z coordinates of all added
+atoms will be 0.0.
+
+The particles are created one by one using the specified random number
+*seed*, resulting in the same set of particle coordinates, independent
+of how many processors are being used in the simulation.  Unless the
+*overlap* keyword is specified, particles created by the *random*
+style will typically be highly overlapped.  Various additional
+criteria can be used to accept or reject a random particle insertion;
+see the keyword discussion below.  Multiple attempts per particle are
+made (see the *maxtry* keyword) until the insertion is either
+successful or fails.  If this command fails to add all requested *N*
+particles, a warning will be output.
+
+If the *region-ID* argument is specified as NULL, then the randomly
+created particles will be anywhere in the simulation box.  If a
+*region-ID* is specified, a geometric volume is filled that is both
+inside the simulation box and is also consistent with the region
+volume.  See the :doc:`region <region>` command for details.  Note
+that a region can be specified so that its "volume" is either inside
+or outside its geometric boundary.
+
+Note that the create_atoms command adds particles to those that
+already exist.  This means it can be used to add particles to a system
+previously read in from a data or restart file.  Or the create_atoms
+command can be used multiple times, to add multiple sets of particles
+to the simulation.  For example, grain boundaries can be created, by
+interleaving the create_atoms command with :doc:`lattice <lattice>`
+commands specifying different orientations.
+
+When this command is used, care should be taken to ensure the
+resulting system does not contain particles that are highly
+overlapped.  Such overlaps will cause many interatomic potentials to
+compute huge energies and forces, leading to bad dynamics.  There are
+several strategies to avoid this problem:
+
+* Use the :doc:`delete_atoms overlap <delete_atoms>` command after
+  create_atoms.  For example, this strategy can be used to overlay and
+  surround a large protein molecule with a volume of water molecules,
+  then delete water molecules that overlap with the protein atoms.
+
+* For the *random* style, use the optional *overlap* keyword to avoid
+  overlaps when each new particle is created.
+
+* Before running dynamics on an overlapped system, perform an
+  :doc:`energy minimization <minimize>`.  Or run initial dynamics with
+  :doc:`pair_style soft <pair_soft>` or with :doc:`fix nve/limit
+  <fix_nve_limit>` to un-overlap the particles, before running normal
+  dynamics.
 
 .. figure:: img/marble_race.jpg
             :figwidth: 33%
@@ -189,73 +324,6 @@ to the area of that triangle.
    beneficial to exclude computing interactions between the created
    particles using :doc:`neigh_modify exclude <neigh_modify>`.
 
-.. versionchanged:: 2Jun2022
-
-The *porosity* style has been renamed to *random* with added functionality.
-
-For the *random* style, *N* particles are added to the system at
-randomly generated coordinates, which can be useful for generating an
-amorphous system.  The particles are created one by one using the
-specified random number *seed*, resulting in the same set of particle
-coordinates, independent of how many processors are being used in the
-simulation.  Unless the *overlap* keyword is specified, particles
-created by the *random* style will typically be highly overlapped.
-Various additional criteria can be used to accept or reject a random
-particle insertion; see the keyword discussion below.  Multiple
-attempts per particle are made (see the *maxtry* keyword) until the
-insertion is either successful or fails.  If this command fails to add
-all requested *N* particles, a warning will be output.
-
-If the *region-ID* argument is specified as NULL, then the randomly
-created particles will be anywhere in the simulation box.  If a
-*region-ID* is specified, a geometric volume is filled that is both
-inside the simulation box and is also consistent with the region
-volume.  See the :doc:`region <region>` command for details.  Note
-that a region can be specified so that its "volume" is either inside
-or outside its geometric boundary.
-
-Note that the create_atoms command adds particles to those that
-already exist.  This means it can be used to add particles to a system
-previously read in from a data or restart file.  Or the create_atoms
-command can be used multiple times, to add multiple sets of particles
-to the simulation.  For example, grain boundaries can be created, by
-interleaving the create_atoms command with :doc:`lattice <lattice>`
-commands specifying different orientations.
-
-When this command is used, care should be taken to ensure the
-resulting system does not contain particles that are highly
-overlapped.  Such overlaps will cause many interatomic potentials to
-compute huge energies and forces, leading to bad dynamics.  There are
-several strategies to avoid this problem:
-
-* Use the :doc:`delete_atoms overlap <delete_atoms>` command after
-  create_atoms.  For example, this strategy can be used to overlay and
-  surround a large protein molecule with a volume of water molecules,
-  then delete water molecules that overlap with the protein atoms.
-
-* For the *random* style, use the optional *overlap* keyword to avoid
-  overlaps when each new particle is created.
-
-* Before running dynamics on an overlapped system, perform an
-  :doc:`energy minimization <minimize>`.  Or run initial dynamics with
-  :doc:`pair_style soft <pair_soft>` or with :doc:`fix nve/limit
-  <fix_nve_limit>` to un-overlap the particles, before running normal
-  dynamics.
-
-.. note::
-
-   You cannot use any of the styles explained above to create atoms
-   that are outside the simulation box; they will just be ignored by
-   LAMMPS.  This is true even if you are using shrink-wrapped box
-   boundaries, as specified by the :doc:`boundary <boundary>` command.
-   However, you can first use the :doc:`change_box <change_box>`
-   command to temporarily expand the box, then add atoms via
-   create_atoms, then finally use change_box command again if needed
-   to re-shrink-wrap the new atoms.  See the :doc:`change_box
-   <change_box>` doc page for an example of how to do this, using the
-   create_atoms *single* style to insert a new atom outside the
-   current simulation box.
-
 ----------
 
 Individual atoms are inserted by this command, unless the *mol*
@@ -268,6 +336,12 @@ molecule can be specified in the molecule file.  See the
 required to be in this file are the coordinates and types of atoms in
 the molecule.
 
+.. note::
+
+  If you are using the *mol* keyword in combination with the
+  :doc:`atom style template <atom_style>` command, they must use
+  the same molecule template-ID.
+
 Using a lattice to add molecules, e.g. via the *box* or *region* or
 *single* styles, is exactly the same as adding atoms on lattice
 points, except that entire molecules are added at each point, i.e. on
@@ -401,12 +475,13 @@ to.
 
 The *overlap* keyword only applies to the *random* style.  It prevents
 newly created particles from being created closer than the specified
-*Doverlap* distance from any other particle.  When the particles being
-created are molecules, the radius of the molecule (from its geometric
-center) is added to *Doverlap*.  If particles have finite size (see
-:doc:`atom_style sphere <atom_style>` for example) *Doverlap* should
-be specified large enough to include the particle size in the
-non-overlapping criterion.
+*Doverlap* distance from any other particle.  If particles have finite
+size (see :doc:`atom_style sphere <atom_style>` for example) *Doverlap*
+should be specified large enough to include the particle size in the
+non-overlapping criterion.  If molecules are being randomly inserted, then
+an insertion is only accepted if each particle in the molecule meets the
+overlap criterion with respect to other particles (not including particles
+in the molecule itself).
 
 .. note::
 
@@ -463,12 +538,19 @@ on a single CPU core.
 -----
 
 The *units* keyword determines the meaning of the distance units used
-to specify the coordinates of the one particle created by the *single*
-style, or the overlap distance *Doverlap* by the *overlap* keyword.  A
-*box* value selects standard distance units as defined by the
-:doc:`units <units>` command (e.g., :math:`\AA` for
-units = *real* or *metal*\ .  A *lattice* value means the distance units are in
-lattice spacings.
+by parameters for various styles.  A *box* value selects standard
+distance units as defined by the :doc:`units <units>` command (e.g.,
+:math:`\AA` for units = *real* or *metal*\ .  A *lattice* value means
+the distance units are in lattice spacings.  These are affected settings:
+
+* for *single* style: coordinates of the particle created
+* for *random* style: overlap distance *Doverlap* by the *overlap* keyword
+* for *mesh* style: *bisect* threshold value for *meshmode* = *bisect*
+* for *mesh* style: *radthresh* value for *meshmode* = *bisect*
+* for *mesh* style: *density* value for *meshmode* = *qrand*
+
+Since *density* represents an area (distance ^2), the lattice spacing
+factor is also squared.
 
 ----------
 

doc/src/create_box.rst

@@ -9,9 +9,11 @@ Syntax
 .. code-block:: LAMMPS
 
    create_box N region-ID keyword value ...
+   create_box N NULL alo ahi blo bhi clo chi keyword value ...
 
 * N = # of atom types to use in this simulation
-* region-ID = ID of region to use as simulation domain
+* region-ID = ID of region to use as simulation domain or NULL for general triclinic box
+* alo,ahi,blo,bhi,clo,chi = multipliers on a1,a2,a3 vectors defined by :doc"`lattice <lattice>` command (only when region-ID = NULL)
 * zero or more keyword/value pairs may be appended
 * keyword = *bond/types* or *angle/types* or *dihedral/types* or *improper/types* or *extra/bond/per/atom* or *extra/angle/per/atom* or *extra/dihedral/per/atom* or *extra/improper/per/atom* or *extra/special/per/atom*
 
@@ -32,121 +34,204 @@ Examples
 
 .. code-block:: LAMMPS
 
+   # orthogonal or restricted triclinic box using regionID = mybox
    create_box 2 mybox
    create_box 2 mybox bond/types 2 extra/bond/per/atom 1
 
+.. code-block:: LAMMPS
+
+   # 2d general triclinic box using primitive cell for 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
+
+.. code-block:: LAMMPS
+
+   # 3d general triclinic box using primitive cell for 3d fcc lattice
+   lattice custom 1.0 a2 0.0 0.5 0.5 a1 0.5 0.0 0.5 a3 0.5 0.5 0.0 basis 0.0 0.0 0.0 triclinic/general
+   create box 1 NULL -5 5 -10 10 0 20
+
 Description
 """""""""""
 
-This command creates a simulation box based on the specified region.
-Thus a :doc:`region <region>` command must first be used to define a
-geometric domain.  It also partitions the simulation box into a
-regular 3d grid of rectangular bricks, one per processor, based on the
-number of processors being used and the settings of the
-:doc:`processors <processors>` command.  The partitioning can later be
-changed by the :doc:`balance <balance>` or :doc:`fix balance <fix_balance>` commands.
+This command creates a simulation box. It also partitions the box into
+a regular 3d grid of smaller sub-boxes, one per processor (MPI task).
+The geometry of the partitioning is based on the size and shape of the
+simulation box, the number of processors being used and the settings
+of the :doc:`processors <processors>` command.  The partitioning can
+later be changed by the :doc:`balance <balance>` or :doc:`fix balance
+<fix_balance>` commands.
 
-The argument N is the number of atom types that will be used in the
+Simulation boxes in LAMMPS can be either orthogonal or triclinic in
+shape.  Orthogonal boxes are a brick in 3d (rectangle in 2d) with 6
+faces that are each perpendicular to one of the standard xyz
+coordinate axes.  Triclinic boxes are a parallelepiped in 3d
+(parallelogram in 2d) with opposite pairs of faces parallel to each
+other.  LAMMPS supports two forms of triclinic boxes, restricted and
+general, which differ in how the box is oriented with respect to the
+xyz coordinate axes.  See the :doc:`Howto triclinic <Howto_triclinic>`
+for a detailed description of all 3 kinds of simulation boxes.
+
+The argument *N* is the number of atom types that will be used in the
 simulation.
 
+Orthogonal and restricted triclinic boxes are created by specifying a
+region ID previously defined by the :doc:`region <region>` command.
+General triclinic boxes are discussed below.
+
 If the region is not of style *prism*, then LAMMPS encloses the region
 (block, sphere, etc.) with an axis-aligned orthogonal bounding box
-which becomes the simulation domain.
+which becomes the simulation domain.  For a 2d simulation, the zlo and
+zhi values of the simulation box must straddle zero.
 
 If the region is of style *prism*, LAMMPS creates a non-orthogonal
 simulation domain shaped as a parallelepiped with triclinic symmetry.
 As defined by the :doc:`region prism <region>` command, the
-parallelepiped has its "origin" at (xlo,ylo,zlo) and is defined by three
-edge vectors starting from the origin given by
-:math:`\vec a = (x_\text{hi}-x_\text{lo},0,0)`;
-:math:`\vec b = (xy,y_\text{hi}-y_\text{lo},0)`; and
-:math:`\vec c = (xz,yz,z_\text{hi}-z_\text{lo})`.
-The parameters *xy*\ , *xz*\ , and *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.
+parallelepiped has an "origin" at (xlo,ylo,zlo) and three edge vectors
+starting from the origin given by :math:`\vec a =
+(x_\text{hi}-x_\text{lo},0,0)`; :math:`\vec b =
+(xy,y_\text{hi}-y_\text{lo},0)`; and :math:`\vec c =
+(xz,yz,z_\text{hi}-z_\text{lo})`.  In LAMMPS lingo, this is a
+restricted triclinic box because the three edge vectors cannot be
+defined in arbitrary (general) directions.  The parameters *xy*\ ,
+*xz*\ , and *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.  For a 2d simulation, the zlo and zhi values of
+the simulation box must straddle zero.
 
-By default, a *prism* region used with the create_box command must have
-tilt factors :math:`(xy,xz,yz)` that do not skew the box more than half
-the distance of the parallel box length.  For example, if
-:math:`x_\text{lo} = 2` and :math:`x_\text{hi} = 12`, then the :math:`x`
-box length is 10 and the :math:`xy` tilt factor must be between
-:math:`-5` and :math:`5`.  Similarly, both :math:`xz` and :math:`yz`
-must be between :math:`-(x_\text{hi}-x_\text{lo})/2` and
+Typically a *prism* region used with the create_box command should
+have tilt factors :math:`(xy,xz,yz)` that do not skew the box more
+than half the distance of the parallel box length.  For example, if
+:math:`x_\text{lo} = 2` and :math:`x_\text{hi} = 12`, then the
+:math:`x` box length is 10 and the :math:`xy` tilt factor must be
+between :math:`-5` and :math:`5`.  Similarly, both :math:`xz` and
+:math:`yz` must be between :math:`-(x_\text{hi}-x_\text{lo})/2` and
 :math:`+(y_\text{hi}-y_\text{lo})/2`.  Note that this is not a
-limitation, since if the maximum tilt factor is 5 (as in this example),
-then configurations with tilt :math:`= \dots, -15`, :math:`-5`,
-:math:`5`, :math:`15`, :math:`25, \dots` are all geometrically
-equivalent.  Simulations with large tilt factors will run inefficiently,
-since they require more ghost atoms and thus more communication.  With
-very large tilt factors, LAMMPS will eventually produce incorrect
-trajectories and stop with errors due to lost atoms or similar.
+limitation, since if the maximum tilt factor is 5 (as in this
+example), then configurations with tilt :math:`= \dots, -15`,
+:math:`-5`, :math:`5`, :math:`15`, :math:`25, \dots` are all
+geometrically equivalent.
 
-See the :doc:`Howto triclinic <Howto_triclinic>` page for a
-geometric description of triclinic boxes, as defined by LAMMPS, and
-how to transform these parameters to and from other commonly used
-triclinic representations.
+LAMMPS will issue a warning if the tilt factors of the created box do
+not meet this criterion.  This is because simulations with large tilt
+factors may run inefficiently, since they require more ghost atoms and
+thus more communication.  With very large tilt factors, LAMMPS may
+eventually produce incorrect trajectories and stop with errors due to
+lost atoms or similar issues.
 
-When a prism region is used, the simulation domain should normally be periodic
-in the dimension that the tilt is applied to, which is given by the second
-dimension of the tilt factor (e.g., :math:`y` for :math:`xy` tilt).  This is so
-that pairs of atoms interacting across that boundary will have one of them
-shifted by the tilt factor.  Periodicity is set by the
-:doc:`boundary <boundary>` command.  For example, if the :math:`xy` tilt factor
-is non-zero, then the :math:`y` dimension should be periodic.  Similarly, the
-:math:`z` dimension should be periodic if :math:`xz` or :math:`yz` is non-zero.
-LAMMPS does not require this periodicity, but you may lose atoms if this is not
-the case.
+See the :doc:`Howto triclinic <Howto_triclinic>` page for geometric
+descriptions of triclinic boxes and tilt factors, as well as how to
+transform the restricted triclinic parameters to and from other
+commonly used triclinic representations.
+
+When a prism region is used, the simulation domain should normally be
+periodic in the dimension that the tilt is applied to, which is given
+by the second dimension of the tilt factor (e.g., :math:`y` for
+:math:`xy` tilt).  This is so that pairs of atoms interacting across
+that boundary will have one of them shifted by the tilt factor.
+Periodicity is set by the :doc:`boundary <boundary>` command.  For
+example, if the :math:`xy` tilt factor is non-zero, then the :math:`y`
+dimension should be periodic.  Similarly, the :math:`z` dimension
+should be periodic if :math:`xz` or :math:`yz` is non-zero.  LAMMPS
+does not require this periodicity, but you may lose atoms if this is
+not the case.
 
 Note that if your simulation will tilt the box (e.g., via the
-:doc:`fix deform <fix_deform>` command), the simulation box must be set up to
-be triclinic, even if the tilt factors are initially 0.0.  You can
-also change an orthogonal box to a triclinic box or vice versa by
+:doc:`fix deform <fix_deform>` command), the simulation box must be
+created as triclinic, even if the tilt factors are initially 0.0.  You
+can also change an orthogonal box to a triclinic box or vice versa by
 using the :doc:`change box <change_box>` command with its *ortho* and
 *triclinic* options.
 
 .. note::
 
-   If the system is non-periodic (in a dimension), then you should
-   not make the lo/hi box dimensions (as defined in your
-   :doc:`region <region>` command) radically smaller/larger than the extent
-   of the atoms you eventually plan to create (e.g., via the
-   :doc:`create_atoms <create_atoms>` command).  For example, if your atoms
-   extend from 0 to 50, you should not specify the box bounds as :math:`-10000`
-   and :math:`10000`. This is because as described above, LAMMPS uses the
-   specified box size to lay out the 3d grid of processors.  A huge
-   (mostly empty) box will be sub-optimal for performance when using
-   "fixed" boundary conditions (see the :doc:`boundary <boundary>`
-   command).  When using "shrink-wrap" boundary conditions (see the
-   :doc:`boundary <boundary>` command), a huge (mostly empty) box may cause
-   a parallel simulation to lose atoms the first time that LAMMPS
-   shrink-wraps the box around the atoms.
+   If the system is non-periodic (in a dimension), then you should not
+   make the lo/hi box dimensions (as defined in your :doc:`region
+   <region>` command) radically smaller/larger than the extent of the
+   atoms you eventually plan to create (e.g., via the
+   :doc:`create_atoms <create_atoms>` command).  For example, if your
+   atoms extend from 0 to 50, you should not specify the box bounds as
+   :math:`-10000` and :math:`10000`. This is because as described
+   above, LAMMPS uses the specified box size to lay out the 3d grid of
+   processors.  A huge (mostly empty) box will be sub-optimal for
+   performance when using "fixed" boundary conditions (see the
+   :doc:`boundary <boundary>` command).  When using "shrink-wrap"
+   boundary conditions (see the :doc:`boundary <boundary>` command), a
+   huge (mostly empty) box may cause a parallel simulation to lose
+   atoms the first time that LAMMPS shrink-wraps the box around the
+   atoms.
+
+----------
+
+As noted above, general triclinic boxes in LAMMPS allow the box to
+have arbitrary edge vectors **A**, **B**, **C**.  The only
+restrictions are that the three vectors be distinct, non-zero, and not
+co-planar.  They must also define a right-handed system such that
+(**A** x **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.
+
+To create a general triclinic boxes, the region is specified as NULL
+and the next 6 parameters (alo,ahi,blo,bhi,clo,chi) define the three
+edge vectors **A**, **B**, **C** using additional information
+previously defined by the :doc:`lattice <lattice>` command.
+
+The lattice must be of style *custom* and use its *triclinic/general*
+option.  This insures the lattice satisfies the restrictions listed
+above.  The *a1, *a2*, *a3* settings of the :doc:`lattice <lattice>`
+command define the edge vectors of a unit cell of the general
+triclinic lattice.  This command uses them to define the three edge
+vectors and origin of the general triclinic box as:
+
+* **A** = (ahi-alo) * *a1*
+* **B** = (bhi-blo) * *a2*
+* **C** = (chi-clo) * *a3*
+* origin = (alo*a1 + blo*a2 + clo*a3)
+
+For 2d general triclinic boxes, clo = -0.5 and chi = 0.5 is required.
+
+.. note::
+
+   LAMMPS allows specification of general triclinic simulation boxes
+   as a convenience for users who may be converting data from
+   solid-state crystallographic representations or from DFT codes for
+   input to LAMMPS.  However, as explained on the
+   :doc:`Howto_triclinic <Howto_triclinic>` doc page, internally,
+   LAMMPS only uses restricted triclinic simulation boxes.  This means
+   the box defined by this command and per-atom information
+   (e.g. coordinates, velocities) defined by the :doc:`create_atoms
+   <create_atoms>` command are converted (rotated) from general to
+   restricted triclinic form when the two commands are invoked.  The
+   <Howto_triclinic>` doc page also discusses other LAMMPS commands
+   which can input/output general triclinic representations of the
+   simulation box and per-atom data.
 
 ----------
 
 The optional keywords can be used to create a system that allows for
 bond (angle, dihedral, improper) interactions, or for molecules with
-special 1--2, 1--3, or 1--4 neighbors to be added later.  These optional
-keywords serve the same purpose as the analogous keywords that can be
-used in a data file which are recognized by the
+special 1--2, 1--3, or 1--4 neighbors to be added later.  These
+optional keywords serve the same purpose as the analogous keywords
+that can be used in a data file which are recognized by the
 :doc:`read_data <read_data>` command when it sets up a system.
 
 Note that if these keywords are not used, then the create_box command
 creates an atomic (non-molecular) simulation that does not allow bonds
-between pairs of atoms to be defined, or a
-:doc:`bond potential <bond_style>` to be specified, or for molecules with
-special neighbors to be added to the system by commands such as
-:doc:`create_atoms mol <create_atoms>`, :doc:`fix deposit <fix_deposit>`
-or :doc:`fix pour <fix_pour>`.
+between pairs of atoms to be defined, or a :doc:`bond potential
+<bond_style>` to be specified, or for molecules with special neighbors
+to be added to the system by commands such as :doc:`create_atoms mol
+<create_atoms>`, :doc:`fix deposit <fix_deposit>` or :doc:`fix pour
+<fix_pour>`.
 
 As an example, see the examples/deposit/in.deposit.molecule script,
 which deposits molecules onto a substrate.  Initially there are no
-molecules in the system, but they are added later by the
-:doc:`fix deposit <fix_deposit>` command.  The create_box command in the
-script uses the bond/types and extra/bond/per/atom keywords to allow
-this.  If the added molecule contained more than one special bond
-(allowed by default), an extra/special/per/atom keyword would also
-need to be specified.
+molecules in the system, but they are added later by the :doc:`fix
+deposit <fix_deposit>` command.  The create_box command in the script
+uses the bond/types and extra/bond/per/atom keywords to allow this.
+If the added molecule contained more than one special bond (allowed by
+default), an extra/special/per/atom keyword would also need to be
+specified.
 
 ----------
 

doc/src/delete_bonds.rst

@@ -43,6 +43,9 @@ Examples
    delete_bonds all bond 0*3 special
    delete_bonds all stats
 
+   labelmap atom 4 hc
+   delete_bonds all atom hc special
+
 Description
 """""""""""
 
@@ -59,19 +62,20 @@ For all styles, by default, an interaction is only turned off (or on)
 if all the atoms involved are in the specified group.  See the *any*
 keyword to change the behavior.
 
-Several of the styles (\ *atom*, *bond*, *angle*, *dihedral*,
-*improper*\ ) take a *type* as an argument.  The specified *type* should
-be an integer from 0 to :math:`N`, where :math:`N` is the number of relevant
+Several of the styles (\ *atom*, *bond*, *angle*, *dihedral*, *improper*\ )
+take a *type* as an argument.  The specified *type* can be a
+:doc:`type label <Howto_type_labels>`.  Otherwise, the type should be an
+integer from 0 to :math:`N`, where :math:`N` is the number of relevant
 types (atom types, bond types, etc.).  A value of 0 is only relevant for
-style *bond*\ ; see details below.  In all cases, a wildcard asterisk
+style *bond*\ ; see details below.  For numeric types, a wildcard asterisk
 can be used in place of or in conjunction with the *type* argument to
 specify a range of types.  This takes the form "\*" or "\*n" or "m\*" or
-"m\*n".  If :math:`N` is the number of types, then an asterisk with no numeric
-values means all types from 0 to :math:`N`.  A leading asterisk means all
-types from 0 to n (inclusive).  A trailing asterisk means all types
-from m to N (inclusive).  A middle asterisk means all types from m to
-n (inclusive).  Note that it is fine to include a type of 0 for
-non-bond styles; it will simply be ignored.
+"m\*n".  If :math:`N` is the number of types, then an asterisk with no
+numeric values means all types from 0 to :math:`N`.  A leading asterisk
+means all types from 0 to n (inclusive).  A trailing asterisk means all
+types from m to N (inclusive).  A middle asterisk means all types from m to
+n (inclusive).  Note that it is fine to include a type of 0 for non-bond
+styles; it will simply be ignored.
 
 For style *multi* all bond, angle, dihedral, and improper interactions
 of any type, involving atoms in the group, are turned off.

doc/src/dihedral_cosine_squared_restricted.rst

@@ -0,0 +1,71 @@
+.. index:: dihedral_style cosine/squared/restricted
+
+dihedral_style cosine/squared/restricted command
+================================================
+
+
+Syntax
+""""""
+
+.. code-block:: LAMMPS
+
+   dihedral_style cosine/squared/restricted
+
+Examples
+""""""""
+
+.. code-block:: LAMMPS
+
+   dihedral_style cosine/squared/restricted
+   dihedral_coeff 1 10.0 120
+
+Description
+"""""""""""
+
+.. versionadded:: 17Apr2024
+
+The *cosine/squared/restricted* dihedral style uses the potential
+
+.. math::
+
+   E = K [\cos(\phi) - \cos(\phi_0)]^2 / \sin^2(\phi)
+
+, which is commonly used in the MARTINI force field.
+
+See :ref:`(Bulacu) <restricted-Bul>` for a description of the restricted dihedral for the MARTINI force field.
+
+The following coefficients must be defined for each dihedral type via the
+:doc:`dihedral_coeff <dihedral_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:`\phi_0` (degrees)
+
+:math:`\phi_0` is specified in degrees, but LAMMPS converts it to radians internally.
+
+----------
+
+Restrictions
+""""""""""""
+
+This dihedral 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:`dihedral_coeff <dihedral_coeff>`
+
+Default
+"""""""
+
+none
+
+----------
+
+.. _restricted-Bul:
+
+**(Bulacu)** Bulacu, Goga, Zhao, Rossi, Monticelli, Periole, Tieleman, Marrink, J Chem Theory Comput, 9, 3282-3292
+(2013).

doc/src/dihedral_style.rst

@@ -10,7 +10,7 @@ Syntax
 
    dihedral_style style
 
-* style = *none* or *zero* or *hybrid* or *charmm* or *charmmfsw* or *class2* or *cosine/shift/exp* or *fourier* or *harmonic* or *helix* or *lepton* or *multi/harmonic* or *nharmonic* or *opls* or *spherical* or *table* or *table/cut*
+* style = *none* or *zero* or *hybrid* or *charmm* or *charmmfsw* or *class2* or *cosine/shift/exp* or *cosine/squared/restricted* or *fourier* or *harmonic* or *helix* or *lepton* or *multi/harmonic* or *nharmonic* or *opls* or *spherical* or *table* or *table/cut*
 
 Examples
 """"""""
@@ -105,6 +105,7 @@ exist.
 * :doc:`charmmfsw <dihedral_charmm>` - CHARMM dihedral with force switching
 * :doc:`class2 <dihedral_class2>` - COMPASS (class 2) dihedral
 * :doc:`cosine/shift/exp <dihedral_cosine_shift_exp>` - dihedral with exponential in spring constant
+* :doc:`cosine/squared/restricted <dihedral_cosine_squared_restricted>` - squared cosine dihedral with restricted term
 * :doc:`fourier <dihedral_fourier>` - dihedral with multiple cosine terms
 * :doc:`harmonic <dihedral_harmonic>` - harmonic dihedral
 * :doc:`helix <dihedral_helix>` - helix dihedral

doc/src/dump.rst

@@ -104,7 +104,6 @@ Syntax
                                q, mux, muy, muz, mu,
                                radius, diameter, omegax, omegay, omegaz,
                                angmomx, angmomy, angmomz, tqx, tqy, tqz,
-                               heatflow, temperature,
                                c_ID, c_ID[I], f_ID, f_ID[I], v_name,
                                i_name, d_name, i2_name[I], d2_name[I]
 
@@ -115,6 +114,7 @@ Syntax
            proc = ID of processor that owns atom
            procp1 = ID+1 of processor that owns atom
            type = atom type
+           typelabel = atom :doc:`type label <Howto_type_labels>`
            element = name of atom element, as defined by :doc:`dump_modify <dump_modify>` command
            mass = atom mass
            x,y,z = unscaled atom coordinates
@@ -131,8 +131,6 @@ Syntax
            omegax,omegay,omegaz = angular velocity of spherical particle
            angmomx,angmomy,angmomz = angular momentum of aspherical particle
            tqx,tqy,tqz = torque on finite-size particles
-           heatflow = rate of heat flow into particle
-           temperature = temperature of particle
            c_ID = per-atom vector calculated by a compute with ID
            c_ID[I] = Ith column of per-atom array calculated by a compute with ID, I can include wildcard (see below)
            f_ID = per-atom vector calculated by a fix with ID
@@ -278,16 +276,20 @@ format <dump_modify>` command and its options.
 Format of native LAMMPS format dump files:
 
 The *atom*, *custom*, *grid*, and *local* styles create files in a
-simple LAMMPS-specific text format that is self-explanatory when
-viewing a dump file.  Many post-processing tools either included with
-LAMMPS or third-party tools can read this format, as does the
+simple LAMMPS-specific text format that is mostly self-explanatory
+when viewing a dump file.  Many post-processing tools either included
+with LAMMPS or third-party tools can read this format, as does the
 :doc:`rerun <rerun>` command.  See tools described on the :doc:`Tools
 <Tools>` doc page for examples, including `Pizza.py
 <https://lammps.github.io/pizza>`_.
 
 For all these styles, the dimensions of the simulation box are
-included in each snapshot.  For an orthogonal simulation box this
-information is formatted as:
+included in each snapshot.  The simulation box in LAMMPS can be
+defined in one of 3 ways: orthogonal, restricted triclinic, and
+general triclinic.  See the :doc:`Howto triclinic <Howto_triclinic>`
+doc page for a detailed description of all 3 options.
+
+For an orthogonal simulation box the box information is formatted as:
 
 .. parsed-literal::
 
@@ -304,10 +306,10 @@ the six characters is one of *p* (periodic), *f* (fixed), *s* (shrink wrap),
 or *m* (shrink wrapped with a minimum value).  See the
 :doc:`boundary <boundary>` command for details.
 
-For triclinic simulation boxes (non-orthogonal), an orthogonal
-bounding box which encloses the triclinic simulation box is output,
-along with the three tilt factors (*xy*, *xz*, *yz*) of the triclinic box,
-formatted as follows:
+For a restricted triclinic simulation box, an orthogonal bounding box
+which encloses the restricted triclinic simulation box is output,
+along with the three tilt factors (*xy*, *xz*, *yz*) of the triclinic
+box, formatted as follows:
 
 .. parsed-literal::
 
@@ -329,6 +331,10 @@ bounding box extents (xlo_bound, xhi_bound, etc.) are calculated from the
 triclinic parameters, and how to transform those parameters to and
 from other commonly used triclinic representations.
 
+For a general triclinic simulation box, see the "General triclinic"
+section below for a description of the ITEM: BOX BOUNDS format as well
+as how per-atom coordinates and per-atom vector quantities are output.
+
 The *atom* and *custom* styles output a "ITEM: NUMBER OF ATOMS" line
 with the count of atoms in the snapshot.  Likewise they output an
 "ITEM: ATOMS" line which includes column descriptors for the per-atom
@@ -400,7 +406,6 @@ command.
 
 Dump files in other popular formats:
 
-
 .. note::
 
    This section only discusses file formats relevant to this doc page.
@@ -466,8 +471,9 @@ followed by one line per atom with the atom type and the :math:`x`-,
 :math:`y`-, and :math:`z`-coordinate of that atom.  You can use the
 :doc:`dump_modify element <dump_modify>` option to change the output
 from using the (numerical) atom type to an element name (or some other
-label). This will help many visualization programs to guess bonds and
-colors.
+label). This option will help many visualization programs to guess bonds
+and colors. You can use the :doc:`dump_modify types labels <dump_modify>`
+option to replace numeric atom types with :doc:`type labels <Howto_type_labels>`.
 
 .. versionadded:: 22Dec2022
 
@@ -656,6 +662,87 @@ how to control the compression level in both variants.
 
 ----------
 
+General triclinic simulation box output for the *atom* and *custom* styles:
+
+As mentioned above, the simulation box can be defined as a general
+triclinic box, which means that 3 arbitrary box edge vectors **A**,
+**B**, **C** can be specified.  See the :doc:`Howto triclinic
+<Howto_triclinic>` doc page for a detailed description of general
+triclinic boxes.
+
+This option is provided as a convenience for users who may be
+converting data from solid-state crystallographic representations or
+from DFT codes for input to LAMMPS.  However, as explained on the
+:doc:`Howto_triclinic <Howto_triclinic>` doc page, internally, LAMMPS
+only uses restricted triclinic simulation boxes.  This means the box
+and per-atom information (e.g. coordinates, velocities) LAMMPS stores
+are converted (rotated) from general to restricted triclinic form when
+the system is created.
+
+For dump output, if the :doc:`dump_modify triclinic/general
+<dump_modify>` command is used, the box description and per-atom
+coordinates and other per-atom vectors will be converted (rotated)
+from restricted to general form when each dump file snapshots is
+output.  This option can only be used if the simulation box was
+initially created as general triclinic.  If the option is not used,
+and the simulation box is general triclinic, then the dump file
+snapshots will reflect the internal restricted triclinic geometry.
+
+The dump_modify triclinic/general option affects 3 aspects of the dump
+file output.
+
+First, the format for the BOX BOUNDS is as follows
+
+.. parsed-literal::
+
+   ITEM: BOX BOUNDS abc origin
+   ax ay az originx
+   bx by bz originy
+   cx cy cz originz
+
+where the **A** edge vector of the box is (ax,ay,az) and similarly
+for **B** and **C**.  The origin of all 3 edge vectors is (originx,
+originy, originz).
+
+Second, the coordinates of each atom are converted (rotated) so that
+the atom is inside (or near) the general triclinic box defined by the
+**A**, **B**, **C** edge vectors.  For style *atom*, this only alters
+output for unscaled atom coords, via the :doc:`dump_modify scaled no
+<dump_modify>` setting. For style *custom*, this alters output for
+either unscaled or unwrapped output of atom coords, via the *x,y,z* or
+*xu,yu,zu* attributes.  For output of scaled atom coords by both
+styles, there is no difference between restricted and general
+triclinic values.
+
+Third, the output for any attribute of the *custom* style which
+represents a per-atom vector quantity will be converted (rotated) to
+be oriented consistent with the general triclinic box and its
+orientation relative to the standard xyz coordinate axes.
+
+This applies to the following *custom* style attributes:
+
+* vx,vy,vz = atom velocities
+* fx,fy,fz = forces on atoms
+* mux,muy,muz = orientation of dipole moment of atom
+* omegax,omegay,omegaz = angular velocity of spherical particle
+* angmomx,angmomy,angmomz = angular momentum of aspherical particle
+* tqx,tqy,tqz = torque on finite-size particles
+
+For example, if the velocity of an atom in a restricted triclinic box
+is along the x-axis, then it will be output for a general triclinic
+box as a vector along the **A** edge vector of the box.
+
+.. note::
+
+   For style *custom*, the :doc:`dump_modify thresh <dump_modify>`
+   command may access per-atom attributes either directly or
+   indirectly through a compute or variable.  If the attribute is an
+   atom coordinate or one of the vectors mentioned above, its value
+   will *NOT* be a general triclinic (rotated) value.  Rather it will
+   be a restricted triclinic value.
+
+----------
+
 Arguments for different styles:
 
 The sections below describe per-atom, local, and per grid cell
@@ -689,21 +776,21 @@ command creates a per-atom array with six columns:
 
 Per-atom attributes used as arguments to the *custom* and *cfg* styles:
 
-The *id*, *mol*, *proc*, *procp1*, *type*, *element*, *mass*, *vx*,
-*vy*, *vz*, *fx*, *fy*, *fz*, *q* attributes are self-explanatory.
+The *id*, *mol*, *proc*, *procp1*, *type*, *typelabel*, *element*, *mass*,
+*vx*, *vy*, *vz*, *fx*, *fy*, *fz*, *q* attributes are self-explanatory.
 
-*Id* is the atom ID.  *Mol* is the molecule ID, included in the data
-file for molecular systems.  *Proc* is the ID of the processor (0 to
+*Id* is the atom ID.  *Mol* is the molecule ID, included in the data file
+for molecular systems.  *Proc* is the ID of the processor (0 to
 :math:`N_\text{procs}-1`) that currently owns the atom.  *Procp1* is the
 proc ID+1, which can be convenient in place of a *type* attribute (1 to
 :math:`N_\text{types}`) for coloring atoms in a visualization program.
-*Type* is the atom type (1 to :math:`N_\text{types}`).  *Element* is
-typically the chemical name of an element, which you must assign to each
-type via the :doc:`dump_modify element <dump_modify>` command.  More
-generally, it can be any string you wish to associated with an atom
-type.  *Mass* is the atom mass. The quantities *vx*, *vy*, *vz*, *fx*,
-*fy*, *fz*, and *q* are components of atom velocity and force and atomic
-charge.
+*Type* is the atom type (1 to :math:`N_\text{types}`).  *Typelabel* is the
+atom :doc:`type label <Howto_type_labels>`.  *Element* is typically the
+chemical name of an element, which you must assign to each type via the
+:doc:`dump_modify element <dump_modify>` command.  More generally, it can
+be any string you wish to associated with an atom type.  *Mass* is the atom
+mass.  The quantities *vx*, *vy*, *vz*, *fx*, *fy*, *fz*, and *q* are
+components of atom velocity and force and atomic charge.
 
 There are several options for outputting atom coordinates.  The *x*,
 *y*, and *z* attributes write atom coordinates "unscaled", in the

doc/src/dump_modify.rst

@@ -17,7 +17,7 @@ Syntax
 * one or more keyword/value pairs may be appended
 
 * these keywords apply to various dump styles
-* keyword = *append* or *at* or *balance* or *buffer* or *colname* or *delay* or *element* or *every* or *every/time* or *fileper* or *first* or *flush* or *format* or *header* or *image* or *label* or *maxfiles* or *nfile* or *pad* or *pbc* or *precision* or *region* or *refresh* or *scale* or *sfactor* or *skip* or *sort* or *tfactor* or *thermo* or *thresh* or *time* or *units* or *unwrap*
+* keyword = *append* or *at* or *balance* or *buffer* or *colname* or *delay* or *element* or *every* or *every/time* or *fileper* or *first* or *flush* or *format* or *header* or *image* or *label* or *maxfiles* or *nfile* or *pad* or *pbc* or *precision* or *region* or *refresh* or *scale* or *sfactor* or *skip* or *sort* or *tfactor* or *thermo* or *thresh* or *time* or *triclinic/general* or *types* or *units* or *unwrap*
 
   .. parsed-literal::
 
@@ -74,12 +74,14 @@ Syntax
           -N = sort per-atom lines in descending order by the Nth column
        *tfactor* arg = time scaling factor (> 0.0)
        *thermo* arg = *yes* or *no*
-       *time* arg = *yes* or *no*
        *thresh* args = attribute operator value
          attribute = same attributes (x,fy,etotal,sxx,etc) used by dump custom style
          operator = "<" or "<=" or ">" or ">=" or "==" or "!=" or "\|\^"
          value = numeric value to compare to, or LAST
          these 3 args can be replaced by the word "none" to turn off thresholding
+       *time* arg = *yes* or *no*
+       *triclinic/general* arg = *yes* or *no*
+       *types* value = *numeric* or *labels*
        *units* arg = *yes* or *no*
        *unwrap* arg = *yes* or *no*
 
@@ -802,8 +804,9 @@ region since the last dump.
    dump_modify ... thresh v_charge |^ LAST
 
 This will dump atoms whose charge has changed from an absolute value
-less than :math:`\frac12` to greater than :math:`\frac12` (or vice versa) since the last dump (e.g., due to reactions and subsequent charge equilibration in a
-reactive force field).
+less than :math:`\frac12` to greater than :math:`\frac12` (or vice
+versa) since the last dump (e.g., due to reactions and subsequent
+charge equilibration in a reactive force field).
 
 The choice of operators listed above are the usual comparison
 operators.  The XOR operation (exclusive or) is also included as "\|\^".
@@ -811,6 +814,18 @@ In this context, XOR means that if either the attribute or value is
 0.0 and the other is non-zero, then the result is "true" and the
 threshold criterion is met.  Otherwise it is not met.
 
+.. note::
+
+   For style *custom*, the *triclinic/general* keyword can alter dump
+   output for general triclinic simulation boxes and their atoms.  See
+   the :doc:`dump <dump>` command for details of how this changes the
+   format of dump file snapshots.  The thresh keyword may access
+   per-atom attributes either directly or indirectly through a compute
+   or variable.  If the attribute is an atom coordinate or a per-atom
+   vector (such as velocity, force, or dipole moment), its value will
+   *NOT* be a general triclinic (rotated) value.  Rather it will be a
+   restricted triclinic value.
+
 ----------
 
 The *time* keyword only applies to the dump *atom*, *custom*, *local*,
@@ -835,6 +850,36 @@ The default setting is *no*\ .
 
 ----------
 
+The *types* keyword applies only to the dump xyz style. If this keyword is
+used with a value of *numeric*, then numeric atom types are printed in the
+xyz file (default). If the value *labels* is specified, then
+:doc:`type labels <Howto_type_labels>` are printed for atom types.
+
+----------
+
+The *triclinic/general* keyword only applies to the dump *atom* and
+*custom* styles.  It can only be used with a value of *yes* if the
+simulation box was created as a general triclinic box.  See the
+:doc:`Howto_triclinic <Howto_triclinic>` doc page for a detailed
+explanation of orthogonal, restricted triclinic, and general triclinic
+simulation boxes.
+
+If this keyword is used with a value of *yes*, the box information at
+the beginning of each snapshot will include information about the 3
+arbitrary edge vectors **A**, **B**, **C** that define the general
+triclinic box as well as their origin.  The format is described on the
+:doc:`dump <dump>` doc page.
+
+The coordinates of each atom will likewise be output as values in (or
+near) the general triclinic box.  Likewise, per-atom vector quantities
+such as velocity, omega, dipole moment, etc will have orientations
+consistent with the general triclinic box, meaning they will be
+rotated relative to the standard xyz coordinate axes.  See the
+:doc:`dump <dump>` doc page for a full list of which dump attributes
+this affects.
+
+----------
+
 The *units* keyword only applies to the dump *atom*, *custom*, and
 *local* styles (and their COMPRESS package versions *atom/gz*,
 *custom/gz* and *local/gz*\ ). If set to *yes*, each individual dump
@@ -922,10 +967,12 @@ The option defaults are
 * sort = off for dump styles *atom*, *custom*, *cfg*, and *local*
 * sort = id for dump styles *dcd*, *xtc*, and *xyz*
 * thresh = none
+* time = no
+* triclinic/general = no
+* types = numeric
 * units = no
 * unwrap = no
 
 * compression_level = 9 (gz variants)
 * compression_level = 0 (zstd variants)
 * checksum = yes (zstd variants)
-

doc/src/fitpod_command.rst

@@ -1,18 +1,19 @@
 .. index:: fitpod
 
 fitpod command
-======================
+==============
 
 Syntax
 """"""
 
 .. code-block:: LAMMPS
 
-   fitpod Ta_param.pod Ta_data.pod
+   fitpod Ta_param.pod Ta_data.pod Ta_coefficients.pod
 
 * fitpod = style name of this command
 * Ta_param.pod = an input file that describes proper orthogonal descriptors (PODs)
 * Ta_data.pod = an input file that specifies DFT data used to fit a POD potential
+* Ta_coefficients.pod (optional) = an input file that specifies trainable coefficients of a POD potential
 
 Examples
 """"""""
@@ -20,20 +21,26 @@ Examples
 .. code-block:: LAMMPS
 
    fitpod Ta_param.pod Ta_data.pod
+   fitpod Ta_param.pod Ta_data.pod Ta_coefficients.pod
 
 Description
 """""""""""
 .. versionadded:: 22Dec2022
 
 Fit a machine-learning interatomic potential (ML-IAP) based on proper
-orthogonal descriptors (POD).  Two input files are required for this
-command. The first input file describes a POD potential parameter
-settings, while the second input file specifies the DFT data used for
-the fitting procedure.
+orthogonal descriptors (POD); please see :ref:`(Nguyen and Rohskopf)
+<Nguyen20222a>`, :ref:`(Nguyen2023) <Nguyen20232a>`, :ref:`(Nguyen2024)
+<Nguyen20242a>`, and :ref:`(Nguyen and Sema) <Nguyen20243a>` for details.
+The fitted POD potential can be used to run MD simulations via
+:doc:`pair_style pod <pair_pod>`.
 
-The table below has one-line descriptions of all the keywords that can
-be used in the first input file (i.e. ``Ta_param.pod`` in the example
-above):
+Two input files are required for this command. The first input file
+describes a POD potential parameter settings, while the second input
+file specifies the DFT data used for the fitting procedure. All keywords
+except *species* have default values. If a keyword is not set in the
+input file, its default value is used. The table below has one-line
+descriptions of all the keywords that can be used in the first input
+file (i.e. ``Ta_param.pod``)
 
 .. list-table::
    :header-rows: 1
@@ -52,7 +59,7 @@ above):
      - INT
      - three integer constants specify boundary conditions
    * - rin
-     - 1.0
+     - 0.5
      - REAL
      - a real number specifies the inner cut-off radius
    * - rcut
@@ -60,46 +67,75 @@ above):
      - REAL
      - a real number specifies the outer cut-off radius
    * - bessel_polynomial_degree
-     - 3
+     - 4
      - INT
      - the maximum degree of Bessel polynomials
    * - inverse_polynomial_degree
-     - 6
+     - 8
      - INT
      - the maximum degree of inverse radial basis functions
+   * - number_of_environment_clusters
+     - 1
+     - INT
+     - the number of clusters for environment-adaptive potentials
+   * - number_of_principal_components
+     - 2
+     - INT
+     - the number of principal components for dimensionality reduction
    * - onebody
      - 1
      - BOOL
      - turns on/off one-body potential
    * - twobody_number_radial_basis_functions
-     - 6
+     - 8
      - INT
      - number of radial basis functions for two-body potential
    * - threebody_number_radial_basis_functions
-     - 5
+     - 6
      - INT
      - number of radial basis functions for three-body potential
-   * - threebody_number_angular_basis_functions
+   * - threebody_angular_degree
      - 5
      - INT
-     - number of angular basis functions for three-body potential
-   * - fourbody_snap_twojmax
+     - angular degree for three-body potential
+   * - fourbody_number_radial_basis_functions
+     - 4
+     - INT
+     - number of radial basis functions for four-body potential
+   * - fourbody_angular_degree
+     - 3
+     - INT
+     - angular degree for four-body potential
+   * - fivebody_number_radial_basis_functions
      - 0
      - INT
-     - band limit for SNAP bispectrum components (0,2,4,6,8... allowed)
-   * - fourbody_snap_chemflag
+     - number of radial basis functions for five-body potential
+   * - fivebody_angular_degree
      - 0
-     - BOOL
-     - turns on/off the explicit multi-element variant of the SNAP bispectrum components
-   * - quadratic_pod_potential
+     - INT
+     - angular degree for five-body potential
+   * - sixbody_number_radial_basis_functions
      - 0
-     - BOOL
-     - turns on/off quadratic POD potential
+     - INT
+     - number of radial basis functions for six-body potential
+   * - sixbody_angular_degree
+     - 0
+     - INT
+     - angular degree for six-body potential
+   * - sevenbody_number_radial_basis_functions
+     - 0
+     - INT
+     - number of radial basis functions for seven-body potential
+   * - sevenbody_angular_degree
+     - 0
+     - INT
+     - angular degree for seven-body potential
+
+Note that both the number of radial basis functions and angular degree
+must decrease as the body order increases. The next table describes all
+keywords that can be used in the second input file (i.e. ``Ta_data.pod``
+in the example above):
 
-All keywords except *species* have default values. If a keyword is not
-set in the input file, its default value is used.  The next table
-describes all keywords that can be used in the second input file
-(i.e. ``Ta_data.pod`` in the example above):
 
 .. list-table::
    :header-rows: 1
@@ -125,6 +161,10 @@ describes all keywords that can be used in the second input file
      - ""
      - STRING
      - specifies the path to test data files in double quotes
+   * - path_to_environment_configuration_set
+     - ""
+     - STRING
+     - specifies the path to environment configuration files in double quotes
    * - fraction_training_data_set
      - 1.0
      - REAL
@@ -133,6 +173,14 @@ describes all keywords that can be used in the second input file
      - 0
      - BOOL
      - turns on/off randomization of the training set
+   * - fraction_test_data_set
+     - 1.0
+     - REAL
+     - a real number (<= 1.0) specifies the fraction of the test set used to validate POD
+   * - randomize_test_data_set
+     - 0
+     - BOOL
+     - turns on/off randomization of the test set
    * - fitting_weight_energy
      - 100.0
      - REAL
@@ -161,6 +209,10 @@ describes all keywords that can be used in the second input file
      - 8
      - INT
      - number of digits after the decimal points for numbers in the coefficient file
+   * - group_weights
+     - global
+     - STRING
+     - ``table`` uses group weights defined for each group named by filename
 
 All keywords except *path_to_training_data_set* have default values. If
 a keyword is not set in the input file, its default value is used.  After
@@ -172,14 +224,44 @@ successful training, a number of output files are produced, if enabled:
 * ``<basename>_test_analysis.pod`` reports detailed errors for all test configurations
 * ``<basename>_coefficients.pod`` contains the coefficients of the POD potential
 
-After training the POD potential, ``Ta_param.pod`` and ``<basename>_coefficients.pod``
-are the two files needed to use the POD potential in LAMMPS. See
-:doc:`pair_style pod <pair_pod>` for using the POD potential. Examples
-about training and using POD potentials are found in the directory
-lammps/examples/PACKAGES/pod.
+After training the POD potential, ``Ta_param.pod`` and
+``<basename>_coefficients.pod`` are the two files needed to use the POD
+potential in LAMMPS.  See :doc:`pair_style pod <pair_pod>` for using the
+POD potential. Examples about training and using POD potentials are
+found in the directory lammps/examples/PACKAGES/pod and the Github repo
+https://github.com/cesmix-mit/pod-examples.
 
-Parameterized Potential Energy Surface
-""""""""""""""""""""""""""""""""""""""
+Loss Function Group Weights
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The *group_weights* keyword in the ``data.pod`` file is responsible for
+weighting certain groups of configurations in the loss function. For
+example:
+
+.. code-block:: LAMMPS
+
+    group_weights table
+    Displaced_A15 100.0 1.0
+    Displaced_BCC 100.0 1.0
+    Displaced_FCC 100.0 1.0
+    Elastic_BCC   100.0 1.0
+    Elastic_FCC   100.0 1.0
+    GSF_110       100.0 1.0
+    GSF_112       100.0 1.0
+    Liquid        100.0 1.0
+    Surface       100.0 1.0
+    Volume_A15    100.0 1.0
+    Volume_BCC    100.0 1.0
+    Volume_FCC    100.0 1.0
+
+This will apply an energy weight of ``100.0`` and a force weight of
+``1.0`` for all groups in the ``Ta`` example. The groups are named by
+their respective filename. If certain groups are left out of this table,
+then the globally defined weights from the ``fitting_weight_energy`` and
+``fitting_weight_force`` keywords will be used.
+
+POD Potential
+"""""""""""""
 
 We consider a multi-element system of *N* atoms with :math:`N_{\rm e}`
 unique elements.  We denote by :math:`\boldsymbol r_n` and :math:`Z_n`
@@ -187,535 +269,82 @@ position vector and type of an atom *n* in the system,
 respectively. Note that we have :math:`Z_n \in \{1, \ldots, N_{\rm e}
 \}`, :math:`\boldsymbol R = (\boldsymbol r_1, \boldsymbol r_2, \ldots,
 \boldsymbol r_N) \in \mathbb{R}^{3N}`, and :math:`\boldsymbol Z = (Z_1,
-Z_2, \ldots, Z_N) \in \mathbb{N}^{N}`. The potential energy surface
-(PES) of the system can be expressed as a many-body expansion of the
-form
+Z_2, \ldots, Z_N) \in \mathbb{N}^{N}`. The total energy of the
+POD potential is expressed as :math:`E(\boldsymbol R, \boldsymbol Z) =
+\sum_{i=1}^N E_i(\boldsymbol R_i, \boldsymbol Z_i)`, where
 
 .. math::
 
-    E(\boldsymbol R, \boldsymbol Z, \boldsymbol{\eta}, \boldsymbol{\mu}) \ = \ & \sum_{i} V^{(1)}(\boldsymbol r_i, Z_i, \boldsymbol \mu^{(1)} ) + \frac12 \sum_{i,j} V^{(2)}(\boldsymbol r_i, \boldsymbol r_j, Z_i, Z_j, \boldsymbol \eta, \boldsymbol \mu^{(2)})  \\
-    & + \frac16 \sum_{i,j,k} V^{(3)}(\boldsymbol r_i, \boldsymbol r_j, \boldsymbol r_k, Z_i, Z_j, Z_k, \boldsymbol \eta, \boldsymbol \mu^{(3)}) + \ldots
-
-where :math:`V^{(1)}` is the one-body potential often used for
-representing external field or energy of isolated elements, and the
-higher-body potentials :math:`V^{(2)}, V^{(3)}, \ldots` are symmetric,
-uniquely defined, and zero if two or more indices take identical values.
-The superscript on each potential denotes its body order. Each *q*-body
-potential :math:`V^{(q)}` depends on :math:`\boldsymbol \mu^{(q)}` which
-are sets of parameters to fit the PES. Note that :math:`\boldsymbol \mu`
-is a collection of all potential parameters :math:`\boldsymbol
-\mu^{(1)}`, :math:`\boldsymbol \mu^{(2)}`, :math:`\boldsymbol
-\mu^{(3)}`, etc, and that :math:`\boldsymbol \eta` is a set of
-hyper-parameters such as inner cut-off radius :math:`r_{\rm in}` and
-outer cut-off radius :math:`r_{\rm cut}`.
-
-Interatomic potentials rely on parameters to learn relationship between
-atomic environments and interactions.  Since interatomic potentials are
-approximations by nature, their parameters need to be set to some
-reference values or fitted against data by necessity.  Typically,
-potential fitting finds optimal parameters, :math:`\boldsymbol \mu^*`,
-to minimize a certain loss function of the predicted quantities and
-data. Since the fitted potential depends on the data set used to fit it,
-different data sets will yield different optimal parameters and thus
-different fitted potentials. When fitting the same functional form on
-*Q* different data sets, we would obtain *Q* different optimized
-potentials, :math:`E(\boldsymbol R,\boldsymbol Z, \boldsymbol \eta,
-\boldsymbol \mu_q^*), 1 \le q \le Q`.  Consequently, there exist many
-different sets of optimized parameters for empirical interatomic
-potentials.
-
-Instead of optimizing the potential parameters, inspired by the reduced
-basis method :ref:`(Grepl) <Grepl20072>` for parameterized partial
-differential equations, we view the parameterized PES as a parametric
-manifold of potential energies
-
-.. math::
-
-    \mathcal{M} = \{E(\boldsymbol R, \boldsymbol Z, \boldsymbol \eta, \boldsymbol \mu) \ | \  \boldsymbol \mu \in \Omega^{\boldsymbol \mu} \}
-
-where :math:`\Omega^{\boldsymbol \mu}` is a parameter domain in which
-:math:`\boldsymbol \mu` resides.  The parametric manifold
-:math:`\mathcal{M}` contains potential energy surfaces for all values of
-:math:`\boldsymbol \mu \in \Omega^{\boldsymbol \mu}`.  Therefore, the
-parametric manifold yields a much richer and more transferable atomic
-representation than any particular individual PES :math:`E(\boldsymbol
-R, \boldsymbol Z, \boldsymbol \eta, \boldsymbol \mu^*)`.
-
-We propose specific forms of the parameterized potentials for one-body,
-two-body, and three-body interactions. We apply the Karhunen-Loeve
-expansion to snapshots of the parameterized potentials to obtain sets of
-orthogonal basis functions. These basis functions are aggregated
-according to the chemical elements of atoms, thus leading to
-multi-element proper orthogonal descriptors.
-
-Proper Orthogonal Descriptors
-"""""""""""""""""""""""""""""
-
-Proper orthogonal descriptors are finger prints characterizing the
-radial and angular distribution of a system of atoms. The detailed
-mathematical definition is given in the paper by Nguyen and Rohskopf
-:ref:`(Nguyen) <Nguyen20222>`.
-
-The descriptors for the one-body interaction are used to capture energy
-of isolated elements and defined as follows
-
-.. math::
-
-    D_{ip}^{(1)} =  \left\{
-        \begin{array}{ll}
-        1, & \mbox{if } Z_i = p \\
-        0, & \mbox{if } Z_i \neq p
-        \end{array}
-    \right.
-
-for :math:`1 \le i \le N, 1 \le p \le N_{\rm e}`. The number of one-body
-descriptors per atom is equal to the number of elements. The one-body
-descriptors are independent of atom positions, but dependent on atom
-types. The one-body descriptors are active only when the keyword
-*onebody* is set to 1.
-
-We adopt the usual assumption that the direct interaction between two
-atoms vanishes smoothly when their distance is greater than the outer
-cutoff distance :math:`r_{\rm cut}`. Furthermore, we assume that two
-atoms can not get closer than the inner cutoff distance :math:`r_{\rm
-in}` due to the Pauli repulsion principle. Let :math:`r \in (r_{\rm in},
-r_{\rm cut})`, we introduce the following parameterized radial functions
-
-.. math::
-
-    \phi(r, r_{\rm in}, r_{\rm cut}, \alpha, \beta)  = \frac{\sin (\alpha \pi x) }{r - r_{\rm in}}, \qquad  \varphi(r, \gamma)  = \frac{1}{r^\gamma} ,
-
-where the scaled distance function :math:`x` is defined below to enrich the two-body manifold
-
-.. math::
-
-    x(r, r_{\rm in}, r_{\rm cut}, \beta) = \frac{e^{-\beta(r - r_{\rm in})/(r_{\rm cut} - r_{\rm in})} - 1}{e^{-\beta} - 1} .
-
-We introduce the following function as a convex combination of the two functions
-
-.. math::
-
-    \psi(r, r_{\rm in}, r_{\rm cut}, \alpha, \beta, \gamma, \kappa)  = \kappa \phi(r, r_{\rm in}, r_{\rm cut}, \alpha, \beta) + (1- \kappa)  \varphi(r, \gamma) .
-
-We see that :math:`\psi` is a function of distance :math:`r`, cut-off
-distances :math:`r_{\rm in}` and :math:`r_{\rm cut}`, and parameters
-:math:`\alpha, \beta, \gamma, \kappa`. Together these parameters allow
-the function :math:`\psi` to characterize a diverse spectrum of two-body
-interactions within the cut-off interval :math:`(r_{\rm in}, r_{\rm
-cut})`.
-
-Next, we introduce the following parameterized potential
-
-.. math::
-
-    W^{(2)}(r_{ij}, \boldsymbol \eta, \boldsymbol \mu^{(2)})  = f_{\rm c}(r_{ij}, \boldsymbol \eta) \psi(r_{ij}, \boldsymbol \eta, \boldsymbol \mu^{(2)})
-
-where :math:`\eta_1 = r_{\rm in}, \eta_2 = r_{\rm cut}, \mu_1^{(2)} =
-\alpha, \mu_2^{(2)} = \beta, \mu_3^{(2)} = \gamma`, and
-:math:`\mu_4^{(2)} = \kappa`. Here the cut-off function :math:`f_{\rm
-c}(r_{ij}, \boldsymbol \eta)` proposed in [refs] is used to ensure the
-smooth vanishing of the potential and its derivative for :math:`r_{ij}
-\ge r_{\rm cut}`:
-
-.. math::
-
-    f_{\rm c}(r_{ij},  r_{\rm in}, r_{\rm cut})  =  \exp \left(1 -\frac{1}{\sqrt{\left(1 - \frac{(r-r_{\rm in})^3}{(r_{\rm cut} - r_{\rm in})^3} \right)^2 + 10^{-6}}} \right)
-
-Based on the parameterized potential, we form a set of snapshots as
-follows.  We assume that we are given :math:`N_{\rm s}` parameter tuples
-:math:`\boldsymbol \mu^{(2)}_\ell, 1 \le \ell \le N_{\rm s}`. We
-introduce the following set of snapshots on :math:`(r_{\rm in}, r_{\rm
-cut})`:
-
-.. math::
-
-    \xi_\ell(r_{ij}, \boldsymbol \eta) =  W^{(2)}(r_{ij}, \boldsymbol \eta, \boldsymbol \mu^{(2)}_\ell),  \quad \ell = 1, \ldots, N_{\rm s} .
-
-To ensure adequate sampling of the PES for different parameters, we
-choose :math:`N_{\rm s}` parameter points :math:`\boldsymbol
-\mu^{(2)}_\ell = (\alpha_\ell, \beta_\ell, \gamma_\ell, \kappa_\ell), 1
-\le \ell \le N_{\rm s}` as follows. The parameters :math:`\alpha \in [1,
-N_\alpha]` and :math:`\gamma \in [1, N_\gamma]` are integers, where
-:math:`N_\alpha` and :math:`N_\gamma` are the highest degrees for
-:math:`\alpha` and :math:`\gamma`, respectively. We next choose
-:math:`N_\beta` different values of :math:`\beta` in the interval
-:math:`[\beta_{\min}, \beta_{\max}]`, where :math:`\beta_{\min} = 0` and
-:math:`\beta_{\max} = 4`. The parameter :math:`\kappa` can be set either
-0 or 1.  Hence, the total number of parameter points is :math:`N_{\rm s}
-= N_\alpha N_\beta + N_\gamma`.  Although :math:`N_\alpha, N_\beta,
-N_\gamma` can be chosen conservatively large, we find that
-:math:`N_\alpha = 6, N_\beta = 3, N_\gamma = 8` are adequate for most
-problems.  Note that :math:`N_\alpha` and :math:`N_\gamma` correspond to
-*bessel_polynomial_degree* and *inverse_polynomial_degree*,
-respectively.
-
-We employ the Karhunen-Loeve (KL) expansion to generate an orthogonal
-basis set which is known to be optimal for representation of the
-snapshot family :math:`\{\xi_\ell\}_{\ell=1}^{N_{\rm s}}`. The two-body
-orthogonal basis functions are computed as follows
-
-.. math::
-
-    U^{(2)}_m(r_{ij}, \boldsymbol \eta) = \sum_{\ell = 1}^{N_{\rm s}} A_{\ell m}(\boldsymbol \eta) \,  \xi_\ell(r_{ij}, \boldsymbol \eta), \qquad m = 1, \ldots, N_{\rm 2b} ,
-
-where the matrix :math:`\boldsymbol A \in \mathbb{R}^{N_{\rm s} \times
-N_{\rm s}}` consists of eigenvectors of the eigenvalue problem
-
-.. math::
-
-    \boldsymbol C \boldsymbol a = \lambda \boldsymbol a
-
-with the entries of :math:`\boldsymbol C \in \mathbb{R}^{N_{\rm s} \times N_{\rm s}}` being given by
-
-.. math::
-
-    C_{ij}  = \frac{1}{N_{\rm s}} \int_{r_{\rm in}}^{r_{\rm cut}} \xi_i(x, \boldsymbol \eta) \xi_j(x, \boldsymbol \eta) dx, \quad 1 \le i, j \le N_{\rm s}
-
-Note that the eigenvalues :math:`\lambda_\ell, 1 \le \ell \le N_{\rm
-s}`, are ordered such that :math:`\lambda_1 \ge \lambda_2 \ge \ldots \ge
-\lambda_{N_{\rm s}}`, and that the matrix :math:`\boldsymbol A` is
-pe-computed and stored for any given :math:`\boldsymbol \eta`.  Owing to
-the rapid convergence of the KL expansion, only a small number of
-orthogonal basis functions is needed to obtain accurate
-approximation. The value of :math:`N_{\rm 2b}` corresponds to
-*twobody_number_radial_basis_functions*.
-
-The two-body proper orthogonal descriptors at each atom *i* are computed
-by summing the orthogonal basis functions over the neighbors of atom *i*
-and numerating on the atom types as follows
-
-.. math::
-
-    D^{(2)}_{im l(p, q) }(\boldsymbol \eta)  = \left\{
-    \begin{array}{ll}
-    \displaystyle \sum_{\{j | Z_j = q\}} U^{(2)}_m(r_{ij},  \boldsymbol \eta), & \mbox{if } Z_i = p \\
-    0, & \mbox{if } Z_i \neq p
-    \end{array}
-    \right.
-
-for :math:`1 \le i \le N, 1 \le m \le N_{\rm 2b}, 1 \le q, p \le N_{\rm
-e}`. Here :math:`l(p,q)` is a symmetric index mapping such that
-
-.. math::
-
-    l(p,q)  = \left\{
-    \begin{array}{ll}
-    q + (p-1) N_{\rm e} - p(p-1)/2, & \mbox{if } q \ge p \\
-    p + (q-1) N_{\rm e} - q(q-1)/2, & \mbox{if } q < p .
-    \end{array}
-    \right.
-
-The number of two-body descriptors per atom is thus :math:`N_{\rm 2b}
-N_{\rm e}(N_{\rm e}+1)/2`.
-
-It is important to note that the orthogonal basis functions do not
-depend on the atomic numbers :math:`Z_i` and :math:`Z_j`. Therefore, the
-cost of evaluating the basis functions and their derivatives with
-respect to :math:`r_{ij}` is independent of the number of elements
-:math:`N_{\rm e}`. Consequently, even though the two-body proper
-orthogonal descriptors depend on :math:`\boldsymbol Z`, their
-computational complexity is independent of :math:`N_{\rm e}`.
-
-In order to provide proper orthogonal descriptors for three-body
-interactions, we need to introduce a three-body parameterized
-potential. In particular, the three-body potential is defined as a
-product of radial and angular functions as follows
-
-.. math::
-
-    W^{(3)}(r_{ij}, r_{ik}, \theta_{ijk}, \boldsymbol \eta, \boldsymbol \mu^{(3)})  =  \psi(r_{ij}, r_{\rm min}, r_{\rm max}, \alpha, \beta, \gamma, \kappa) f_{\rm c}(r_{ij}, r_{\rm min}, r_{\rm max}) \\
-    \psi(r_{ik}, r_{\rm min}, r_{\rm max}, \alpha, \beta, \gamma, \kappa) f_{\rm c}(r_{ik}, r_{\rm min}, r_{\rm max}) \\
-    \cos (\sigma \theta_{ijk} + \zeta)
-
-where :math:`\sigma` is the periodic multiplicity, :math:`\zeta` is the
-equilibrium angle, :math:`\boldsymbol \mu^{(3)} = (\alpha, \beta,
-\gamma, \kappa, \sigma, \zeta)`. The three-body potential provides an
-angular fingerprint of the atomic environment through the bond angles
-:math:`\theta_{ijk}` formed with each pair of neighbors :math:`j` and
-:math:`k`.  Compared to the two-body potential, the three-body potential
-has two extra parameters :math:`(\sigma, \zeta)` associated with the
-angular component.
-
-Let :math:`\boldsymbol \varrho = (\alpha, \beta, \gamma, \kappa)`. We
-assume that we are given :math:`L_{\rm r}` parameter tuples
-:math:`\boldsymbol \varrho_\ell, 1 \le \ell \le L_{\rm r}`.  We
-introduce the following set of snapshots on :math:`(r_{\min},
-r_{\max})`:
-
-.. math::
-
-    \zeta_\ell(r_{ij}, r_{\rm min}, r_{\rm max} ) =  \psi(r_{ij}, r_{\rm min}, r_{\rm max}, \boldsymbol \varrho_\ell) f_{\rm c}(r_{ij}, r_{\rm min},  r_{\rm max}), \quad 1 \le \ell \le L_{\rm r} .
-
-We apply the Karhunen-Loeve (KL) expansion to this set of snapshots to
-obtain orthogonal basis functions as follows
-
-.. math::
-
-    U^{r}_m(r_{ij}, r_{\rm min}, r_{\rm max} ) = \sum_{\ell = 1}^{L_{\rm r}} A_{\ell m} \,  \zeta_\ell(r_{ij}, r_{\rm min}, r_{\rm max} ), \qquad m = 1, \ldots, N_{\rm r} ,
-
-where the matrix :math:`\boldsymbol A \in \mathbb{R}^{L_{\rm r} \times L_{\rm r}}` consists
-of eigenvectors of the eigenvalue problem. For the parameterized angular function,
-we consider angular basis functions
-
-.. math::
-
-    U^{a}_n(\theta_{ijk}) = \cos ((n-1) \theta_{ijk}), \qquad  n = 1,\ldots, N_{\rm a},
-
-where :math:`N_{\rm a}` is the number of angular basis functions. The orthogonal
-basis functions for the parameterized potential are computed as follows
-
-.. math::
-
-    U^{(3)}_{mn}(r_{ij}, r_{ik}, \theta_{ijk}, \boldsymbol \eta) = U^{r}_m(r_{ij}, \boldsymbol \eta) U^{r}_m(r_{ik}, \boldsymbol \eta) U^{a}_n(\theta_{ijk}),
-
-for :math:`1 \le m \le N_{\rm r}, 1 \le n \le N_{\rm a}`. The number of three-body
-orthogonal basis functions is equal to :math:`N_{\rm 3b} = N_{\rm r} N_{\rm a}` and
-independent of the number of elements. The value of :math:`N_{\rm r}` corresponds to
-*threebody_number_radial_basis_functions*, while that of :math:`N_{\rm a}` to
-*threebody_number_angular_basis_functions*.
-
-The three-body proper orthogonal descriptors at each atom *i*
-are obtained by summing over the neighbors *j* and *k* of atom *i* as
-
-.. math::
-
-    D^{(3)}_{imn \ell(p, q, s)}(\boldsymbol \eta)  = \left\{
-    \begin{array}{ll}
-    \displaystyle \sum_{\{j | Z_j = q\}} \sum_{\{k | Z_k = s\}} U^{(3)}_{mn}(r_{ij}, r_{ik}, \theta_{ijk}, \boldsymbol \eta), & \mbox{if } Z_i = p \\
-    0, & \mbox{if } Z_i \neq p
-    \end{array}
-    \right.
-
-for :math:`1 \le i \le N, 1 \le m \le N_{\rm r}, 1 \le n \le N_{\rm a}, 1 \le q, p, s \le N_{\rm e}`,
-where
-
-.. math::
-
-    \ell(p,q,s)  = \left\{
-    \begin{array}{ll}
-    s + (q-1) N_{\rm e} - q(q-1)/2 + (p-1)N_{\rm e}(1+N_{\rm e})/2 , & \mbox{if } s \ge q \\
-    q + (s-1) N_{\rm e} - s(s-1)/2 + (p-1)N_{\rm e}(1+N_{\rm e})/2, & \mbox{if } s < q .
-    \end{array}
-    \right.
-
-The number of three-body descriptors per atom is thus :math:`N_{\rm 3b} N_{\rm e}^2(N_{\rm e}+1)/2`.
-While the number of three-body PODs is cubic function of the number of elements,
-the computational complexity of the three-body PODs is independent of the number of elements.
-
-Four-Body SNAP Descriptors
-""""""""""""""""""""""""""
-
-In addition to the proper orthogonal descriptors described above, we also employ
-the spectral neighbor analysis potential (SNAP) descriptors. SNAP uses bispectrum components
-to characterize the local neighborhood of each atom in a very general way. The mathematical definition
-of the bispectrum calculation and its derivatives w.r.t. atom positions is described in
-:doc:`compute snap <compute_sna_atom>`. In SNAP, the
-total energy is decomposed into a sum over atom energies. The energy of
-atom *i* is expressed as a weighted sum over bispectrum components.
-
-.. math::
-
-   E_i^{\rm SNAP} = \sum_{k=1}^{N_{\rm 4b}} \sum_{p=1}^{N_{\rm e}} c_{kp}^{(4)} D_{ikp}^{(4)}
-
-
-where the SNAP descriptors are related to the bispectrum components by
-
-.. math::
-
-    D^{(4)}_{ikp}  = \left\{
-    \begin{array}{ll}
-    \displaystyle B_{ik}, & \mbox{if } Z_i = p \\
-    0, & \mbox{if } Z_i \neq p
-    \end{array}
-    \right.
-
-Here :math:`B_{ik}` is the *k*\ -th bispectrum component of atom *i*. The number of
-bispectrum components :math:`N_{\rm 4b}` depends on the value of *fourbody_snap_twojmax* :math:`= 2 J_{\rm max}`
-and *fourbody_snap_chemflag*. If *fourbody_snap_chemflag* = 0
-then :math:`N_{\rm 4b} = (J_{\rm max}+1)(J_{\rm max}+2)(J_{\rm max}+1.5)/3`.
-If *fourbody_snap_chemflag* = 1 then :math:`N_{\rm 4b} = N_{\rm e}^3 (J_{\rm max}+1)(J_{\rm max}+2)(J_{\rm max}+1.5)/3`.
-The bispectrum calculation is described in more detail in :doc:`compute sna/atom <compute_sna_atom>`.
-
-Linear Proper Orthogonal Descriptor Potentials
-""""""""""""""""""""""""""""""""""""""""""""""
-
-The proper orthogonal descriptors and SNAP descriptors are used to define the atomic energies
-in the following expansion
-
-.. math::
-
-    E_{i}(\boldsymbol \eta) = \sum_{p=1}^{N_{\rm e}} c^{(1)}_p D^{(1)}_{ip} + \sum_{m=1}^{N_{\rm 2b}}  \sum_{l=1}^{N_{\rm e}(N_{\rm e}+1)/2} c^{(2)}_{ml} D^{(2)}_{iml}(\boldsymbol \eta) + \sum_{m=1}^{N_{\rm r}} \sum_{n=1}^{N_{\rm a}}  \sum_{\ell=1}^{N_{\rm e}^2(N_{\rm e}+1)/2} c^{(3)}_{mn\ell} D^{(3)}_{imn\ell}(\boldsymbol \eta) + \sum_{k=1}^{N_{\rm 4b}} \sum_{p=1}^{N_{\rm e}} c_{kp}^{(4)} D_{ikp}^{(4)}(\boldsymbol \eta),
-
-where :math:`D^{(1)}_{ip}, D^{(2)}_{iml}, D^{(3)}_{imn\ell}, D^{(4)}_{ikp}` are the  one-body, two-body, three-body, four-body descriptors,
-respectively, and :math:`c^{(1)}_p, c^{(2)}_{ml}, c^{(3)}_{mn\ell}, c^{(4)}_{kp}` are their respective expansion
-coefficients. In a more compact notation that implies summation over descriptor indices
-the atomic energies can be written as
-
-.. math::
-
-    E_i(\boldsymbol \eta) =  \sum_{m=1}^{N_{\rm e}} c^{(1)}_m D^{(1)}_{im} +  \sum_{m=1}^{N_{\rm d}^{(2)}} c^{(2)}_k D^{(2)}_{im} + \sum_{m=1}^{N_{\rm d}^{(3)}} c^{(3)}_m D^{(3)}_{im} + \sum_{m=1}^{N_{\rm d}^{(4)}} c^{(4)}_m D^{(4)}_{im}
-
-where :math:`N_{\rm d}^{(2)} = N_{\rm 2b} N_{\rm e} (N_{\rm e}+1)/2`,
-:math:`N_{\rm d}^{(3)} = N_{\rm 3b} N_{\rm e}^2 (N_{\rm e}+1)/2`, and
-:math:`N_{\rm d}^{(4)} = N_{\rm 4b} N_{\rm e}` are
-the number of two-body, three-body, and four-body descriptors, respectively.
-
-The potential energy is then obtained by summing local atomic energies :math:`E_i`
-for all atoms :math:`i` in the system
-
-.. math::
-
-    E(\boldsymbol \eta) = \sum_{i}^N E_{i}(\boldsymbol \eta)
-
-Because the descriptors are one-body, two-body, and three-body terms,
-the resulting POD potential is a three-body PES. We can express the potential
-energy as a linear combination of the global descriptors as follows
-
-.. math::
-
-    E(\boldsymbol \eta) = \sum_{m=1}^{N_{\rm e}} c^{(1)}_m d^{(1)}_{m} +  \sum_{m=1}^{N_{\rm d}^{(2)}} c^{(2)}_m d^{(2)}_{m} + \sum_{m=1}^{N_{\rm d}^{(3)}} c^{(3)}_m d^{(3)}_{m} + \sum_{m=1}^{N_{\rm d}^{(4)}} c^{(4)}_m d^{(4)}_{m}
-
-where  the global descriptors are given by
-
-.. math::
-
-    d_{m}^{(1)}(\boldsymbol \eta) = \sum_{i=1}^N D_{im}^{(1)}(\boldsymbol \eta), \quad d_{m}^{(2)}(\boldsymbol \eta) = \sum_{i=1}^N D_{im}^{(2)}(\boldsymbol \eta), \quad d_{m}^{(3)}(\boldsymbol \eta) = \sum_{i=1}^N D_{im}^{(3)}(\boldsymbol \eta), \quad d_{m}^{(4)}(\boldsymbol \eta) = \sum_{i=1}^N D_{im}^{(4)}(\boldsymbol \eta)
-
-Hence, we obtain the atomic forces as
-
-.. math::
-
-    \boldsymbol F = -\nabla E(\boldsymbol \eta) = - \sum_{m=1}^{N_{\rm d}^{(2)}}  c^{(2)}_m  \nabla d_m^{(2)} - \sum_{m=1}^{N_{\rm d}^{(3)}}  c^{(3)}_m \nabla d_m^{(3)} - \sum_{m=1}^{N_{\rm d}^{(4)}}  c^{(4)}_m \nabla d_m^{(4)}
-
-where :math:`\nabla d_m^{(2)}`, :math:`\nabla d_m^{(3)}` and :math:`\nabla d_m^{(4)}` are derivatives of the two-body
-three-body, and four-body global descriptors with respect to atom positions, respectively.
-Note that since the first-body global descriptors are constant, their derivatives are zero.
-
-Quadratic Proper Orthogonal Descriptor Potentials
-"""""""""""""""""""""""""""""""""""""""""""""""""
-
-We recall two-body PODs :math:`D^{(2)}_{ik}, 1 \le k \le N_{\rm d}^{(2)}`,
-and three-body PODs :math:`D^{(3)}_{im}, 1 \le m \le N_{\rm d}^{(3)}`,
-with :math:`N_{\rm d}^{(2)} = N_{\rm 2b} N_{\rm e} (N_{\rm e}+1)/2` and
-:math:`N_{\rm d}^{(3)} = N_{\rm 3b} N_{\rm e}^2 (N_{\rm e}+1)/2` being
-the number of descriptors per atom for the two-body PODs and three-body PODs,
-respectively. We employ them to define a new set of atomic descriptors as follows
-
-.. math::
-
-    D^{(2*3)}_{ikm} = \frac{1}{2N}\left( D^{(2)}_{ik} \sum_{j=1}^N D^{(3)}_{jm} + D^{(3)}_{im} \sum_{j=1}^N D^{(2)}_{jk}  \right)
-
-for :math:`1 \le i \le N, 1 \le k \le N_{\rm d}^{(2)}, 1 \le m \le N_{\rm d}^{(3)}`.
-The new descriptors are four-body because they involve central atom :math:`i` together
-with three neighbors :math:`j, k` and :math:`l`. The total number of new  descriptors per atom is equal to
-
-.. math::
-
-    N_{\rm d}^{(2*3)} = N_{\rm d}^{(2)} * N_{\rm d}^{(3)} = N_{\rm 2b} N_{\rm 3b} N_{\rm e}^3 (N_{\rm e}+1)^2/4 .
-
-The new global descriptors are calculated as
-
-.. math::
-
-    d^{(2*3)}_{km} = \sum_{i=1}^N D^{(2*3)}_{ikm} = \left( \sum_{i=1}^N D^{(2)}_{ik} \right) \left( \sum_{i=1}^N D^{(3)}_{im} \right) = d^{(2)}_{k} d^{(3)}_m,
-
-for :math:`1 \le k \le N_{\rm d}^{(2)}, 1 \le m \le N_{\rm d}^{(3)}`. Hence, the gradient
-of the new global descriptors with respect to atom positions is calculated as
-
-.. math::
-
-    \nabla d^{(2*3)}_{km} = d^{(3)}_m \nabla d^{(2)}_{k}  +  d^{(2)}_{k} \nabla d^{(3)}_m, \quad 1 \le k \le N_{\rm d}^{(2)}, 1 \le m \le N_{\rm d}^{(3)} .
-
-The quadratic  POD potential is defined as a linear combination of the
-original and new global descriptors as follows
-
-.. math::
-
-    E^{(2*3)} = \sum_{k=1}^{N_{\rm 2d}^{(2*3)}} \sum_{m=1}^{N_{\rm 3d}^{(2*3)}} c^{(2*3)}_{km} d^{(2*3)}_{km} .
-
-It thus follows that
-
-.. math::
-
-    E^{(2*3)} = 0.5 \sum_{k=1}^{N_{\rm 2d}^{(2*3)}} \left( \sum_{m=1}^{N_{\rm 3d}^{(2*3)}} c^{(2*3)}_{km} d_m^{(3)} \right) d_k^{(2)} + 0.5 \sum_{m=1}^{N_{\rm 3d}^{(2*3)}} \left( \sum_{k=1}^{N_{\rm 2d}^{(2*3)}} c^{(2*3)}_{km} d_k^{(2)} \right) d_m^{(3)}  ,
-
-which is simplified to
-
-.. math::
-
-    E^{(2*3)} =  0.5 \sum_{k=1}^{N_{\rm 2d}^{(2*3)}} b_k^{(2)} d_k^{(2)} +  0.5 \sum_{m=1}^{N_{\rm 3d}^{(2*3)}}   b_m^{(3)} d_m^{(3)}
-
-where
-
-.. math::
-
-    b_k^{(2)} & = \sum_{m=1}^{N_{\rm 3d}^{(2*3)}} c^{(2*3)}_{km} d_m^{(3)}, \quad k = 1,\ldots, N_{\rm 2d}^{(2*3)}, \\
-    b_m^{(3)} & = \sum_{k=1}^{N_{\rm 2d}^{(2*3)}} c^{(2*3)}_{km} d_k^{(2)}, \quad m = 1,\ldots, N_{\rm 3d}^{(2*3)} .
-
-The quadratic POD potential results in the following atomic forces
-
-.. math::
-
-    \boldsymbol F^{(2*3)} = - \sum_{k=1}^{N_{\rm 2d}^{(2*3)}} \sum_{m=1}^{N_{\rm 3d}^{(2*3)}} c^{(2*3)}_{km}  \nabla d^{(2*3)}_{km} .
-
-It can be shown that
-
-.. math::
-
-    \boldsymbol F^{(2*3)} = - \sum_{k=1}^{N_{\rm 2d}^{(2*3)}}   b^{(2)}_k \nabla d_k^{(2)} - \sum_{m=1}^{N_{\rm 3d}^{(2*3)}}  b^{(3)}_m  \nabla d_m^{(3)} .
-
-The calculation of the atomic forces for the quadratic POD  potential
-only requires the extra calculation of :math:`b_k^{(2)}` and :math:`b_m^{(3)}` which can be negligible.
-As a result, the quadratic  POD potential does not increase the computational complexity.
-
+    E_i(\boldsymbol R_i, \boldsymbol Z_i) \ = \ \sum_{m=1}^M c_m \mathcal{D}_{im}(\boldsymbol R_i, \boldsymbol Z_i)
+
+
+Here :math:`c_m` are trainable coefficients and
+:math:`\mathcal{D}_{im}(\boldsymbol R_i, \boldsymbol Z_i)` are per-atom
+POD descriptors. Summing the per-atom descriptors over :math:`i` yields
+the global descriptors :math:`d_m(\boldsymbol R, \boldsymbol Z) =
+\sum_{i=1}^N \mathcal{D}_{im}(\boldsymbol R_i, \boldsymbol Z_i)`.  It
+thus follows that :math:`E(\boldsymbol R, \boldsymbol Z) = \sum_{m=1}^M
+c_m d_m(\boldsymbol R, \boldsymbol Z)`.
+
+The per-atom POD descriptors include one, two, three, four, five, six,
+and seven-body descriptors, which can be specified in the first input
+file. Furthermore, the per-atom POD descriptors also depend on the
+number of environment clusters specified in the first input file.
+Please see :ref:`(Nguyen2024) <Nguyen20242a>` and :ref:`(Nguyen and Sema)
+<Nguyen20243a>` for the detailed description of the per-atom POD
+descriptors.
 
 Training
 """"""""
 
-POD potentials are trained using the least-squares regression against
+A POD potential is trained using the least-squares regression against
 density functional theory (DFT) data.  Let :math:`J` be the number of
 training configurations, with :math:`N_j` being the number of atoms in
-the j-th configuration. Let :math:`\{E^{\star}_j\}_{j=1}^{J}` and
-:math:`\{\boldsymbol F^{\star}_j\}_{j=1}^{J}` be the DFT energies and
-forces for :math:`J` configurations. Next, we calculate the global
-descriptors and their derivatives for all training configurations. Let
-:math:`d_{jm}, 1 \le m \le M`, be the global descriptors associated with
-the j-th configuration, where :math:`M` is the number of global
-descriptors. We then form a matrix :math:`\boldsymbol A \in
-\mathbb{R}^{J \times M}` with entries :math:`A_{jm} = d_{jm}/ N_j` for
-:math:`j=1,\ldots,J` and :math:`m=1,\ldots,M`.  Moreover, we form a
-matrix :math:`\boldsymbol B \in \mathbb{R}^{\mathcal{N} \times M}` by
-stacking the derivatives of the global descriptors for all training
-configurations from top to bottom, where :math:`\mathcal{N} =
-3\sum_{j=1}^{J} N_j`.
+the j-th configuration. The training configurations are extracted from
+the extended XYZ files located in a directory (i.e.,
+path_to_training_data_set in the second input file).  Let
+:math:`\{E^{\star}_j\}_{j=1}^{J}` and :math:`\{\boldsymbol
+F^{\star}_j\}_{j=1}^{J}` be the DFT energies and forces for :math:`J`
+configurations. Next, we calculate the global descriptors and their
+derivatives for all training configurations. Let :math:`d_{jm}, 1 \le m
+\le M`, be the global descriptors associated with the j-th
+configuration, where :math:`M` is the number of global descriptors. We
+then form a matrix :math:`\boldsymbol A \in \mathbb{R}^{J \times M}`
+with entries :math:`A_{jm} = d_{jm}/ N_j` for :math:`j=1,\ldots,J` and
+:math:`m=1,\ldots,M`.  Moreover, we form a matrix :math:`\boldsymbol B
+\in \mathbb{R}^{\mathcal{N} \times M}` by stacking the derivatives of
+the global descriptors for all training configurations from top to
+bottom, where :math:`\mathcal{N} = 3\sum_{j=1}^{J} N_j`.
 
 The coefficient vector :math:`\boldsymbol c` of the POD potential is
 found by solving the following least-squares problem
 
 .. math::
 
-    {\min}_{\boldsymbol c \in \mathbb{R}^{M}} \ w_E \|\boldsymbol A(\boldsymbol \eta) \boldsymbol c - \bar{\boldsymbol E}^{\star} \|^2 + w_F \|\boldsymbol B(\boldsymbol \eta) \boldsymbol c + \boldsymbol F^{\star} \|^2 + w_R \|\boldsymbol c \|^2,
+    {\min}_{\boldsymbol c \in \mathbb{R}^{M}} \ w_E \|\boldsymbol A \boldsymbol c - \bar{\boldsymbol E}^{\star} \|^2 + w_F \|\boldsymbol B \boldsymbol c + \boldsymbol F^{\star} \|^2 + w_R \|\boldsymbol c \|^2,
 
 where :math:`w_E` and :math:`w_F` are weights for the energy
 (*fitting_weight_energy*) and force (*fitting_weight_force*),
-respectively; and :math:`w_R` is the regularization parameter (*fitting_regularization_parameter*).  Here :math:`\bar{\boldsymbol E}^{\star} \in
-\mathbb{R}^{J}` is a vector of with entries :math:`\bar{E}^{\star}_j =
-E^{\star}_j/N_j` and :math:`\boldsymbol F^{\star}` is a vector of
-:math:`\mathcal{N}` entries obtained by stacking :math:`\{\boldsymbol
-F^{\star}_j\}_{j=1}^{J}` from top to bottom.
+respectively; and :math:`w_R` is the regularization parameter
+(*fitting_regularization_parameter*).  Here :math:`\bar{\boldsymbol
+E}^{\star} \in \mathbb{R}^{J}` is a vector of with entries
+:math:`\bar{E}^{\star}_j = E^{\star}_j/N_j` and :math:`\boldsymbol
+F^{\star}` is a vector of :math:`\mathcal{N}` entries obtained by
+stacking :math:`\{\boldsymbol F^{\star}_j\}_{j=1}^{J}` from top to
+bottom.
 
-The training procedure is the same for both the linear and quadratic POD
-potentials.  However, since the quadratic POD potential has a
-significantly larger number of the global descriptors, it is more
-expensive to train the linear POD potential. This is because the
-training of the quadratic POD potential still requires us to calculate
-and store the quadratic global descriptors and their
-gradient. Furthermore, the quadratic POD potential may require more
-training data in order to prevent over-fitting. In order to reduce the
-computational cost of fitting the quadratic POD potential and avoid
-over-fitting, we can use subsets of two-body and three-body PODs for
-constructing the new descriptors.
+Validation
+""""""""""
 
+POD potential can be validated on a test dataset in a directory
+specified by setting path_to_test_data_set in the second input file.  It
+is possible to validate the POD potential after the training is
+complete.  This is done by providing the coefficient file as an input to
+:doc:`fitpod <fitpod_command>`, for example,
+
+.. code-block:: LAMMPS
+
+   fitpod Ta_param.pod Ta_data.pod Ta_coefficients.pod
 
 Restrictions
 """"""""""""
@@ -727,7 +356,11 @@ LAMMPS was built with that package. See the :doc:`Build package
 Related commands
 """"""""""""""""
 
-:doc:`pair_style pod <pair_pod>`
+:doc:`pair_style pod <pair_pod>`,
+:doc:`compute pod/atom <compute_pod_atom>`,
+:doc:`compute podd/atom <compute_pod_atom>`,
+:doc:`compute pod/local <compute_pod_atom>`,
+:doc:`compute pod/global <compute_pod_atom>`
 
 Default
 """""""
@@ -736,10 +369,20 @@ The keyword defaults are also given in the description of the input files.
 
 ----------
 
-.. _Grepl20072:
+.. _Nguyen20222a:
 
-**(Grepl)** Grepl, Maday, Nguyen, and Patera, ESAIM: Mathematical Modelling and Numerical Analysis 41(3), 575-605, (2007).
+**(Nguyen and Rohskopf)** Nguyen and Rohskopf,  Journal of Computational Physics, 480, 112030, (2023).
+
+.. _Nguyen20232a:
+
+**(Nguyen2023)** Nguyen, Physical Review B, 107(14), 144103, (2023).
+
+.. _Nguyen20242a:
+
+**(Nguyen2024)** Nguyen, Journal of Computational Physics, 113102, (2024).
+
+.. _Nguyen20243a:
+
+**(Nguyen and Sema)** Nguyen and Sema, https://arxiv.org/abs/2405.00306, (2024).
 
-.. _Nguyen20222:
 
-**(Nguyen)** Nguyen and Rohskopf, arXiv preprint arXiv:2209.02362 (2022).

doc/src/fix.rst

@@ -226,6 +226,7 @@ accelerated styles exist.
 * :doc:`controller <fix_controller>` - apply control loop feedback mechanism
 * :doc:`damping/cundall <fix_damping_cundall>` - Cundall non-viscous damping for granular simulations
 * :doc:`deform <fix_deform>` - change the simulation box size/shape
+* :doc:`deform/pressure <fix_deform_pressure>` - change the simulation box size/shape with additional loading conditions
 * :doc:`deposit <fix_deposit>` - add new atoms above a surface
 * :doc:`dpd/energy <fix_dpd_energy>` - constant energy dissipative particle dynamics
 * :doc:`drag <fix_drag>` - drag atoms towards a defined coordinate
@@ -427,6 +428,7 @@ accelerated styles exist.
 * :doc:`wall/body/polyhedron <fix_wall_body_polyhedron>` - time integration for body particles of style :doc:`rounded/polyhedron <Howto_body>`
 * :doc:`wall/colloid <fix_wall>` - Lennard-Jones wall interacting with finite-size particles
 * :doc:`wall/ees <fix_wall_ees>` - wall for ellipsoidal particles
+* :doc:`wall/flow <fix_wall_flow>` - flow boundary conditions
 * :doc:`wall/gran <fix_wall_gran>` - frictional wall(s) for granular simulations
 * :doc:`wall/gran/region <fix_wall_gran_region>` - :doc:`fix wall/region <fix_wall_region>` equivalent for use with granular particles
 * :doc:`wall/harmonic <fix_wall>` - harmonic spring wall

doc/src/fix_adapt.rst

@@ -21,17 +21,17 @@ Syntax
        *pair* args = pstyle pparam I J v_name
          pstyle = pair style name (e.g., lj/cut)
          pparam = parameter to adapt over time
-         I,J = type pair(s) to set parameter for
+         I,J = type pair(s) to set parameter for (integer or type label)
          v_name = variable with name that calculates value of pparam
        *bond* args = bstyle bparam I v_name
          bstyle = bond style name (e.g., harmonic)
          bparam = parameter to adapt over time
-         I = type bond to set parameter for
+         I = type bond to set parameter for (integer or type label)
          v_name = variable with name that calculates value of bparam
        *angle* args = astyle aparam I v_name
          astyle = angle style name (e.g., harmonic)
          aparam = parameter to adapt over time
-         I = type angle to set parameter for
+         I = type angle to set parameter for (integer or type label)
          v_name = variable with name that calculates value of aparam
        *kspace* arg = v_name
          v_name = variable with name that calculates scale factor on :math:`k`-space terms
@@ -67,6 +67,9 @@ Examples
    variable ramp_up equal "ramp(0.01,0.5)"
    fix stretch all adapt 1 bond harmonic r0 1 v_ramp_up
 
+   labelmap atom 1 c1
+   fix 1 all adapt 1 pair soft a c1 c1 v_prefactor
+
 Description
 """""""""""
 
@@ -254,10 +257,12 @@ should be specified to indicate which type pairs to apply it to.  If a global
 parameter is specified, the :math:`I` and :math:`J` settings still need to be
 specified, but are ignored.
 
-Similar to the :doc:`pair_coeff command <pair_coeff>`, :math:`I` and :math:`J`
-can be specified in one of two ways.  Explicit numeric values can be used for
-each, as in the first example above.  :math:`I \le J` is required.  LAMMPS sets
-the coefficients for the symmetric :math:`J,I` interaction to the same values.
+Similar to the :doc:`pair_coeff command <pair_coeff>`, :math:`I` and
+:math:`J` can be specified in one of several ways.  Explicit numeric values
+can be used for each, as in the first example above.  Or, one or both of
+the types in the I,J pair can be a :doc:`type label <Howto_type_labels>`.
+LAMMPS sets the coefficients for the symmetric :math:`J,I` interaction to
+the same values.
 
 A wild-card asterisk can be used in place of or in conjunction with
 the :math:`I,J` arguments to set the coefficients for multiple pairs of atom
@@ -266,8 +271,9 @@ is the number of atom types, then an asterisk with no numeric values
 means all types from 1 to :math:`N`.  A leading asterisk means all types from
 1 to n (inclusive).  A trailing asterisk means all types from m to :math:`N`
 (inclusive).  A middle asterisk means all types from m to n
-(inclusive).  Note that only type pairs with :math:`I \le J` are considered; if
-asterisks imply type pairs where :math:`J < I`, they are ignored.
+(inclusive).  For the asterisk syntax, note that only type pairs with
+:math:`I \le J` are considered; if asterisks imply type pairs where
+:math:`J < I`, they are ignored.
 
 IMPORTANT NOTE: If :doc:`pair_style hybrid or hybrid/overlay
 <pair_hybrid>` is being used, then the *pstyle* will be a sub-style

doc/src/fix_adapt_fep.rst

@@ -21,13 +21,13 @@ Syntax
        *pair* args = pstyle pparam I J v_name
          pstyle = pair style name (e.g., lj/cut)
          pparam = parameter to adapt over time
-         I,J = type pair(s) to set parameter for
+         I,J = type pair(s) to set parameter for (integer or type label)
          v_name = variable with name that calculates value of pparam
        *kspace* arg = v_name
          v_name = variable with name that calculates scale factor on K-space terms
        *atom* args = aparam v_name
          aparam = parameter to adapt over time
-         I = type(s) to set parameter for
+         I = type(s) to set parameter for (integer or type label)
          v_name = variable with name that calculates value of aparam
 
 * zero or more keyword/value pairs may be appended
@@ -56,6 +56,9 @@ Examples
    fix 1 all adapt/fep 1 pair lj/cut epsilon * * v_scale1 coul/cut scale 3 3 v_scale2 scale yes reset yes
    fix 1 all adapt/fep 10 atom diameter 1 v_size
 
+   labelmap atom 1 c1
+   fix 1 all adapt/fep 1 pair soft a c1 c1 v_prefactor
+
 
 Example input scripts available: examples/PACKAGES/fep
 
@@ -218,10 +221,12 @@ be specified to indicate which type pairs to apply it to.  If a global
 parameter is specified, the *I* and *J* settings still need to be
 specified, but are ignored.
 
-Similar to the :doc:`pair_coeff command <pair_coeff>`, I and J can be
-specified in one of two ways.  Explicit numeric values can be used for
-each, as in the first example above.  :math:`I \le J` is required.  LAMMPS sets
-the coefficients for the symmetric J,I interaction to the same values.
+Similar to the :doc:`pair_coeff command <pair_coeff>`, :math:`I` and
+:math:`J` can be specified in one of several ways.  Explicit numeric values
+can be used for each, as in the first example above.  Or, one or both of
+the types in the I,J pair can be a :doc:`type label <Howto_type_labels>`.
+LAMMPS sets the coefficients for the symmetric :math:`J,I` interaction to
+the same values.
 
 A wild-card asterisk can be used in place of or in conjunction with
 the :math:`I,J` arguments to set the coefficients for multiple pairs of atom
@@ -230,8 +235,9 @@ the number of atom types, then an asterisk with no numeric values means
 all types from 1 to :math:`N`.  A leading asterisk means all types from 1 to n
 (inclusive).  A trailing asterisk means all types from m to :math:`N`
 (inclusive).  A middle asterisk means all types from m to n
-(inclusive).  Note that only type pairs with :math:`I \le J` are considered; if
-asterisks imply type pairs where :math:`J < I`, they are ignored.
+(inclusive).  For the asterisk syntax, note that only type pairs with
+:math:`I \le J` are considered; if asterisks imply type pairs where
+:math:`J < I`, they are ignored.
 
 IMPROTANT NOTE: If :doc:`pair_style hybrid or hybrid/overlay <pair_hybrid>` is
 being used, then the *pstyle* will be a sub-style name.  You must specify

doc/src/fix_amoeba_bitorsion.rst

@@ -35,7 +35,11 @@ the implementation of AMOEBA and HIPPO in LAMMPS.
 
 Bitorsion interactions add additional potential energy contributions
 to pairs of overlapping phi-psi dihedrals of amino-acids, which are
-important to properly represent their conformational behavior.
+important to properly represent their conformational behavior.  Each
+bitorsion interaction is thus defined for a 5-tuple of atoms
+:math:`IJKLM` with bonds between successive atoms in the list,
+i.e. two overlapping dihedral interactions for atoms :math:`IJKL` and
+:math:`JKLM`.
 
 The examples/amoeba directory has a sample input script and data file
 for ubiquitin, which illustrates use of the fix amoeba/bitorsion
@@ -68,14 +72,15 @@ lines:
           [...]
           N       3     314     315     317      318    330
 
-The first column is an index from 1 to :math:`N` to enumerate the bitorsion
-5-atom tuples; it is ignored by LAMMPS.  The second column is the
-*type* of the interaction; it is an index into the bitorsion force
-field file.  The remaining 5 columns are the atom IDs of the atoms in
-the two 4-atom dihedrals that overlap to create the bitorsion 5-body
-interaction.  Note that the *bitorsions* and *BiTorsions* keywords for
-the header and body sections match those specified in the
-:doc:`read_data <read_data>` command following the data file name.
+The first column is an index from 1 to :math:`N` to enumerate the
+bitorsion 5-atom tuples; it is ignored by LAMMPS.  The second column
+is the *type* of the interaction; it is an index into the bitorsion
+force field file.  The remaining 5 columns are the atom IDs of the
+atoms (in order) for the 5-tuple :math:`IJKLM`, as described above.
+
+Note that the *bitorsions* and *BiTorsions* keywords for the header
+and body sections match those specified in the :doc:`read_data
+<read_data>` command following the data file name.
 
 The data file should be generated by using the
 tools/tinker/tinker2lmp.py conversion script which creates a LAMMPS

doc/src/fix_amoeba_pitorsion.rst

@@ -57,7 +57,7 @@ should have two lines like these in its header section:
    M pitorsion types
    N pitorsions
 
-where :math:`N` is the number of pitorsion 5-body interactions and :math:`M` is
+where :math:`N` is the number of pitorsion 6-body interactions and :math:`M` is
 the number of pitorsion types.  It should also have two sections in the body
 of the data file like these with :math:`M` and :math:`N` lines each:
 
@@ -74,21 +74,20 @@ of the data file like these with :math:`M` and :math:`N` lines each:
 
    PiTorsions
 
-          1       1       8      10      12      18      20
-          2       5      18      20      22      25      27
+          1       1       2      4      3      20      21      24
+          2       5      21     23     22      37      38      41
           [...]
-          N       3     314     315     317      318    330
+          N       7      27     29     28      30      35      36
 
-For PiTorsion Coeffs, the first column is an index from 1 to :math:`M` to
-enumerate the pitorsion types.  The second column is the single
+For PiTorsion Coeffs, the first column is an index from 1 to :math:`M`
+to enumerate the pitorsion types.  The second column is the single
 prefactor coefficient needed for each type.
 
-For PiTorsions, the first column is an index from 1 to :math:`N` to enumerate
-the pitorsion 5-atom tuples; it is ignored by LAMMPS.  The second
-column is the "type" of the interaction; it is an index into the
-PiTorsion Coeffs.  The remaining 5 columns are the atom IDs of the
-atoms in the two 4-atom dihedrals that overlap to create the pitorsion
-5-body interaction.
+For PiTorsions, the first column is an index from 1 to :math:`N` to
+enumerate the pitorsion 6-atom tuples; it is ignored by LAMMPS.  The
+second column is the "type" of the interaction; it is an index into
+the PiTorsion Coeffs.  The remaining 6 columns are the atom IDs of the
+atoms (in order) for the 6-tuple :math:`IJKLMN`, as described above.
 
 Note that the *pitorsion types* and *pitorsions* and *PiTorsion
 Coeffs* and *PiTorsions* keywords for the header and body sections of

doc/src/fix_atom_swap.rst

@@ -21,7 +21,7 @@ Syntax
 
   .. parsed-literal::
 
-       *types* values = two or more atom types
+       *types* values = two or more atom types (1-Ntypes or type label)
        *mu* values = chemical potential of swap types (energy units)
        *ke* value = *no* or *yes*
          *no* = no conservation of kinetic energy after atom swaps
@@ -168,7 +168,7 @@ the following global cumulative quantities:
 * 1 = swap attempts
 * 2 = swap accepts
 
-The vector values calculated by this fix are "extensive".
+The vector values calculated by this fix are "intensive".
 
 No parameter of this fix can be used with the *start/stop* keywords of
 the :doc:`run <run>` command.  This fix is not invoked during

doc/src/fix_ave_chunk.rst

@@ -31,7 +31,7 @@ Syntax
        v_name = per-atom vector calculated by an atom-style variable with name
 
 * zero or more keyword/arg pairs may be appended
-* keyword = *norm* or *ave* or *bias* or *adof* or *cdof* or *file* or *overwrite* or *format* or *title1* or *title2* or *title3*
+* keyword = *norm* or *ave* or *bias* or *adof* or *cdof* or *file* or *append* or *overwrite* or *format* or *title1* or *title2* or *title3*
 
   .. parsed-literal::
 
@@ -51,6 +51,8 @@ Syntax
          dof_per_chunk = define this many degrees-of-freedom per chunk for temperature calculation
        *file* arg = filename
          filename = file to write results to
+       *append* arg = filename
+         filename = file to append results to
        *overwrite* arg = none = overwrite output file with only latest output
        *format* arg = string
          string = C-style format string
@@ -433,15 +435,21 @@ molecule.
 
 ----------
 
-The *file* keyword allows a filename to be specified.  Every
-:math:`N_\text{freq}` timesteps, a section of chunk info will be written to a
-text file in the following format.  A line with the timestep and number of
-chunks is written.  Then one line per chunk is written, containing the chunk
-ID :math:`(1-N_\text{chunk}),` an optional original ID value, optional
-coordinate values for chunks that represent spatial bins, the number of atoms
-in the chunk, and one or more calculated values.  More explanation of the
-optional values is given below.  The number of values in each line
-corresponds to the number of values specified in the fix ave/chunk
+.. versionadded:: 17Apr2024
+   new keyword *append*
+
+The *file* or *append* keywords allow a filename to be specified.  If
+*file* is used, then the filename is overwritten if it already exists.
+If *append* is used, then the filename is appended to if it already
+exists, or created if it does not exist.  Every :math:`N_\text{freq}`
+timesteps, a section of chunk info will be written to a text file in the
+following format.  A line with the timestep and number of chunks is
+written.  Then one line per chunk is written, containing the chunk ID
+:math:`(1-N_\text{chunk}),` an optional original ID value, optional
+coordinate values for chunks that represent spatial bins, the number of
+atoms in the chunk, and one or more calculated values.  More explanation
+of the optional values is given below.  The number of values in each
+line corresponds to the number of values specified in the fix ave/chunk
 command.  The number of atoms and the value(s) are summed or average
 quantities, as explained above.
 

doc/src/fix_ave_correlate.rst

@@ -65,7 +65,6 @@ Examples
    fix 1 all ave/correlate 1 50 10000 &
              c_thermo_press[1] c_thermo_press[2] c_thermo_press[3] &
              type upper ave running title1 "My correlation data"
-
    fix 1 all ave/correlate 1 50 10000 c_thermo_press[*]
 
 Description

doc/src/fix_ave_correlate_long.rst

@@ -20,11 +20,11 @@ Syntax
   .. parsed-literal::
 
        c_ID = global scalar calculated by a compute with ID
-       c_ID[I] = Ith component of global vector calculated by a compute with ID
+       c_ID[I] = Ith component of global vector calculated by a compute with ID, I can include wildcard (see below)
        f_ID = global scalar calculated by a fix with ID
-       f_ID[I] = Ith component of global vector calculated by a fix with ID
+       f_ID[I] = Ith component of global vector calculated by a fix with ID, I can include wildcard (see below)
        v_name = global value calculated by an equal-style variable with name
-       v_name[I] = Ith component of global vector calculated by a vector-style variable with name
+       v_name[I] = Ith component of a vector-style variable with name, I can include wildcard (see below)
 
 * zero or more keyword/arg pairs may be appended
 * keyword = *type* or *start* or *file* or *overwrite* or *title1* or *title2* or *ncorr* or *nlen* or *ncount*
@@ -63,6 +63,7 @@ Examples
    fix 1 all ave/correlate/long 1 10000 &
              c_thermo_press[1] c_thermo_press[2] c_thermo_press[3] &
              type upper title1 "My correlation data" nlen 15 ncount 3
+   fix 1 all ave/correlate/long 1 10000 c_thermo_press[*]
 
 Description
 """""""""""
@@ -80,8 +81,10 @@ specified values may represent calculations performed by computes and
 fixes which store their own "group" definitions.
 
 Each listed value can be the result of a compute or fix or the
-evaluation of an equal-style variable. See the
-:doc:`fix ave/correlate <fix_ave_correlate>` page for details.
+evaluation of an equal-style or vector-style variable.  For
+vector-style variables, the specified indices can include a wildcard
+character.  See the :doc:`fix ave/correlate <fix_ave_correlate>` page
+for details.
 
 The *Nevery* and *Nfreq* arguments specify on what time steps the input
 values will be used to calculate correlation data and the frequency

doc/src/fix_ave_histo.rst

@@ -35,7 +35,7 @@ Syntax
        v_name[I] = value calculated by a vector-style variable with name, I can include wildcard (see below)
 
 * zero or more keyword/arg pairs may be appended
-* keyword = *mode* or *kind* or *file* or *ave* or *start* or *beyond* or *overwrite* or *title1* or *title2* or *title3*
+* keyword = *mode* or *kind* or *file* or *append* or *ave* or *start* or *beyond* or *overwrite* or *title1* or *title2* or *title3*
 
   .. parsed-literal::
 
@@ -45,6 +45,8 @@ Syntax
        *kind* arg = *global* or *peratom* or *local*
        *file* arg = filename
          filename = name of file to output histogram(s) to
+       *append* arg = filename
+         filename = name of file to append histogram(s) to
        *ave* args = *one* or *running* or *window*
          one = output a new average value every Nfreq steps
          running = output cumulative average of all previous Nfreq steps
@@ -317,19 +319,25 @@ on.  The default is step 0.  Often input values can be 0.0 at time 0,
 so setting *start* to a larger value can avoid including a 0.0 in
 a running or windowed histogram.
 
-The *file* keyword allows a filename to be specified.  Every *Nfreq*
-steps, one histogram is written to the file.  This includes a leading
-line that contains the timestep, number of bins, the total count of
-values contributing to the histogram, the count of values that were
-not histogrammed (see the *beyond* keyword), the minimum value
-encountered, and the maximum value encountered.  The min/max values
-include values that were not histogrammed.  Following the leading
-line, one line per bin is written into the file.  Each line contains
-the bin #, the coordinate for the center of the bin (between *lo* and
-*hi*\ ), the count of values in the bin, and the normalized count.  The
-normalized count is the bin count divided by the total count (not
-including values not histogrammed), so that the normalized values sum
-to 1.0 across all bins.
+.. versionadded:: 17Apr2024
+   new keyword *append*
+
+The *file* or *append* keywords allow a filename to be specified.  If
+*file* is used, then the filename is overwritten if it already exists.
+If *append* is used, then the filename is appended to if it already
+exists, or created if it does not exist.  Every *Nfreq* steps, one
+histogram is written to the file.  This includes a leading line that
+contains the timestep, number of bins, the total count of values
+contributing to the histogram, the count of values that were not
+histogrammed (see the *beyond* keyword), the minimum value encountered,
+and the maximum value encountered.  The min/max values include values
+that were not histogrammed.  Following the leading line, one line per
+bin is written into the file.  Each line contains the bin #, the
+coordinate for the center of the bin (between *lo* and *hi*\ ), the
+count of values in the bin, and the normalized count.  The normalized
+count is the bin count divided by the total count (not including values
+not histogrammed), so that the normalized values sum to 1.0 across all
+bins.
 
 The *overwrite* keyword will continuously overwrite the output file
 with the latest output, so that it only contains one timestep worth of

doc/src/fix_ave_time.rst

@@ -28,7 +28,7 @@ Syntax
        v_name[I] = value calculated by a vector-style variable with name, I can include wildcard (see below)
 
 * zero or more keyword/arg pairs may be appended
-* keyword = *mode* or *file* or *ave* or *start* or *off* or *overwrite* or *format* or *title1* or *title2* or *title3*
+* keyword = *mode* or *file* or *append* or *ave* or *start* or *off* or *overwrite* or *format* or *title1* or *title2* or *title3*
 
   .. parsed-literal::
 
@@ -45,6 +45,8 @@ Syntax
          M = value # from 1 to Nvalues
        *file* arg = filename
          filename = name of file to output time averages to
+       *append* arg = filename
+         filename = name of file to append time averages to
        *overwrite* arg = none = overwrite output file with only latest output
        *format* arg = string
          string = C-style format string
@@ -270,16 +272,21 @@ are effectively constant or are simply current values (e.g., they are
 being written to a file with other time-averaged values for purposes
 of creating well-formatted output).
 
-The *file* keyword allows a filename to be specified.  Every *Nfreq*
-steps, one quantity or vector of quantities is written to the file for
-each input value specified in the fix ave/time command.  For *mode* =
-scalar, this means a single line is written each time output is
-performed.  Thus the file ends up to be a series of lines, i.e. one
-column of numbers for each input value.  For *mode* = vector, an array
-of numbers is written each time output is performed.  The number of rows
-is the length of the input vectors, and the number of columns is the
-number of values.  Thus the file ends up to be a series of these array
-sections.
+.. versionadded:: 17Apr2024
+   new keyword *append*
+
+The *file* or *append* keywords allow a filename to be specified.  If
+*file* is used, then the filename is overwritten if it already exists.
+If *append* is used, then the filename is appended to if it already
+exists, or created if it does not exist.  Every *Nfreq* steps, one
+quantity or vector of quantities is written to the file for each input
+value specified in the fix ave/time command.  For *mode* = scalar, this
+means a single line is written each time output is performed.  Thus the
+file ends up to be a series of lines, i.e. one column of numbers for
+each input value.  For *mode* = vector, an array of numbers is written
+each time output is performed.  The number of rows is the length of the
+input vectors, and the number of columns is the number of values.  Thus
+the file ends up to be a series of these array sections.
 
 .. versionadded:: 4May2022
 

doc/src/fix_balance.rst

@@ -14,15 +14,15 @@ Syntax
 * balance = style name of this fix command
 * Nfreq = perform dynamic load balancing every this many steps
 * thresh = imbalance threshold that must be exceeded to perform a re-balance
-* style = *shift* or *rcb*
-
+* style = *shift* or *rcb* or *report*
   .. parsed-literal::
 
-       shift args = dimstr Niter stopthresh
+       *shift* args = dimstr Niter stopthresh
          dimstr = sequence of letters containing *x* or *y* or *z*, each not more than once
          Niter = # of times to iterate within each dimension of dimstr sequence
          stopthresh = stop balancing when this imbalance threshold is reached
        *rcb* args = none
+       *report* args = none
 
 * zero or more keyword/arg pairs may be appended
 * keyword = *weight* or *out*
@@ -70,6 +70,13 @@ re-balancing is performed periodically during the simulation.  To
 perform "static" balancing, before or between runs, see the
 :doc:`balance <balance>` command.
 
+.. versionadded:: 17Apr2024
+
+The *report* balance style only computes the load imbalance but
+does not attempt any re-balancing.  This way the load imbalance
+information can be used otherwise, for instance for stopping a
+run with :doc:`fix halt <fix_halt>`.
+
 Load-balancing is typically most useful if the particles in the
 simulation box have a spatially-varying density distribution or
 where the computational cost varies significantly between different

doc/src/fix_bond_break.rst

@@ -13,7 +13,7 @@ Syntax
 * ID, group-ID are documented in :doc:`fix <fix>` command
 * bond/break = style name of this fix command
 * Nevery = attempt bond breaking every this many steps
-* bondtype = type of bonds to break
+* bondtype = type of bonds to break (integer or type label)
 * Rmax = bond longer than Rmax can break (distance units)
 * zero or more keyword/value pairs may be appended
 * keyword = *prob*

doc/src/fix_bond_create.rst

@@ -17,9 +17,9 @@ Syntax
 * ID, group-ID are documented in :doc:`fix <fix>` command
 * bond/create = style name of this fix command
 * Nevery = attempt bond creation every this many steps
-* itype,jtype = atoms of itype can bond to atoms of jtype
+* itype,jtype = atoms of itype can bond to atoms of jtype (1-Ntypes or type label)
 * Rmin = 2 atoms separated by less than Rmin can bond (distance units)
-* bondtype = type of created bonds
+* bondtype = type of created bonds (integer or type label)
 * zero or more keyword/value pairs may be appended to args
 * keyword = *iparam* or *jparam* or *prob* or *atype* or *dtype* or *itype* or *aconstrain*
 
@@ -27,19 +27,19 @@ Syntax
 
        *iparam* values = maxbond, newtype
          maxbond = max # of bonds of bondtype the itype atom can have
-         newtype = change the itype atom to this type when maxbonds exist
+         newtype = change the itype atom to this type when maxbonds exist (1-Ntypes or type label)
        *jparam* values = maxbond, newtype
          maxbond = max # of bonds of bondtype the jtype atom can have
-         newtype = change the jtype atom to this type when maxbonds exist
+         newtype = change the jtype atom to this type when maxbonds exist (1-Ntypes or type label)
        *prob* values = fraction seed
          fraction = create a bond with this probability if otherwise eligible
          seed = random number seed (positive integer)
        *atype* value = angletype
-         angletype = type of created angles
+         angletype = type of created angles (integer or type label)
        *dtype* value = dihedraltype
-         dihedraltype = type of created dihedrals
+         dihedraltype = type of created dihedrals (integer or type label)
        *itype* value = impropertype
-         impropertype = type of created impropers
+         impropertype = type of created impropers (integer or type label)
        *aconstrain* value = amin amax
          amin = minimal angle at which new bonds can be created
          amax = maximal angle at which new bonds can be created
@@ -54,6 +54,10 @@ Examples
    fix 5 all bond/create 1 3 3 0.8 1 prob 0.5 85784 iparam 2 3 atype 1 dtype 2
    fix 5 all bond/create/angle 10 1 2 1.122 1 aconstrain 120 180 prob 1 4928459 iparam 2 1 jparam 2 2
 
+   labelmap atom 1 c1 2 n2
+   labelmap bond 1 c1-n2
+   fix 5 all bond/create 10 c1 n2 0.8 c1-n2
+
 Description
 """""""""""
 

doc/src/fix_charge_regulation.rst

@@ -13,8 +13,8 @@ Syntax
 
 * ID, group-ID are documented in fix command
 * charge/regulation = style name of this fix command
-* cation_type = atom type of free cations
-* anion_type = atom type of free anions
+* cation_type = atom type of free cations (integer or type label)
+* anion_type = atom type of free anions (integer or type label)
 
 * zero or more keyword/value pairs may be appended
 
@@ -27,8 +27,8 @@ Syntax
      *pIp* value = activity (effective concentration) of free cations (in the -log10 representation)
      *pIm* value = activity (effective concentration) of free anions (in the -log10 representation)
      *pKs* value = solvent self-dissociation constant (in the -log10 representation)
-     *acid_type* = atom type of acid groups
-     *base_type*  = atom type of base groups
+     *acid_type* = atom type of acid groups (integer or type label)
+     *base_type*  = atom type of base groups (integer or type label)
      *lunit_nm* value = unit length used by LAMMPS (# in the units of nanometers)
      *temp* value = temperature
      *tempfixid* value = fix ID of temperature thermostat
@@ -51,6 +51,9 @@ Examples
     fix chareg all charge/regulation 1 2 acid_type 3 base_type 4 pKa 5.0 pKb 6.0 pH 7.0 pIp 3.0 pIm 3.0 nevery 200 nmc 200 seed 123 tempfixid fT
     fix chareg all charge/regulation 1 2 pIp 3 pIm 3 onlysalt yes 2 -1 seed 123 tag yes temp 1.0
 
+    labelmap atom 1 H+ 2 OH-
+    fix chareg all charge/regulation H+ OH- pIp 3 pIm 3 onlysalt yes 2 -1 seed 123 tag yes temp 1.0
+
 Description
 """""""""""
 
@@ -253,11 +256,11 @@ built with that package.  See the :doc:`Build package <Build_package>`
 page for more info.
 
 The :doc:`atom_style <atom_style>`, used must contain the charge
-property, for example, the style could be *charge* or *full*. Only
-usable for 3D simulations. Atoms specified as free ions cannot be part
-of rigid bodies or molecules and cannot have bonding interactions. The
-scheme is limited to integer charges, any atoms with non-integer charges
-will not be considered by the fix.
+property and have per atom type masses, for example, the style could be
+*charge* or *full*. Only usable for 3D simulations.  Atoms specified as
+free ions cannot be part of rigid bodies or molecules and cannot have
+bonding interactions.  The scheme is limited to integer charges, any
+atoms with non-integer charges will not be considered by the fix.
 
 All interaction potentials used must be continuous, otherwise the MD
 integration and the particle exchange MC moves do not correspond to the

doc/src/fix_deform.rst

@@ -4,6 +4,9 @@
 fix deform command
 ==================
 
+:doc:`fix deform/pressure <fix_deform_pressure>` command
+========================================================
+
 Accelerator Variants: *deform/kk*
 
 Syntax
@@ -11,18 +14,18 @@ Syntax
 
 .. code-block:: LAMMPS
 
-   fix ID group-ID deform N parameter args ... keyword value ...
+   fix ID group-ID fix_style N parameter style args ... keyword value ...
 
 * ID, group-ID are documented in :doc:`fix <fix>` command
-* deform = style name of this fix command
+* fix_style = *deform* or *deform/pressure*
 * N = perform box deformation every this many timesteps
-* one or more parameter/arg pairs may be appended
+* one or more parameter/style/args sequences of arguments may be appended
 
   .. parsed-literal::
 
      parameter = *x* or *y* or *z* or *xy* or *xz* or *yz*
        *x*, *y*, *z* args = style value(s)
-         style = *final* or *delta* or *scale* or *vel* or *erate* or *trate* or *volume* or *wiggle* or *variable*
+         style = *final* or *delta* or *scale* or *vel* or *erate* or *trate* or *volume* or *wiggle* or *variable* or *pressure* or *pressure/mean*
            *final* values = lo hi
              lo hi = box boundaries at end of run (distance units)
            *delta* values = dlo dhi
@@ -43,8 +46,15 @@ Syntax
            *variable* values = v_name1 v_name2
              v_name1 = variable with name1 for box length change as function of time
              v_name2 = variable with name2 for change rate as function of time
+           *pressure* values = target gain (ONLY available in :doc:`fix deform/pressure <fix_deform_pressure>` command)
+             target = target pressure (pressure units)
+             gain = proportional gain constant (1/(time * pressure) or 1/time units)
+           *pressure/mean* values = target gain (ONLY available in :doc:`fix deform/pressure <fix_deform_pressure>` command)
+             target = target pressure (pressure units)
+             gain = proportional gain constant (1/(time * pressure) or 1/time units)
+
        *xy*, *xz*, *yz* args = style value
-         style = *final* or *delta* or *vel* or *erate* or *trate* or *wiggle*
+         style = *final* or *delta* or *vel* or *erate* or *trate* or *wiggle* or *variable*
            *final* value = tilt
              tilt = tilt factor at end of run (distance units)
            *delta* value = dtilt
@@ -54,6 +64,8 @@ Syntax
                  effectively an engineering shear strain rate
            *erate* value = R
              R = engineering shear strain rate (1/time units)
+           *erate/rescale* value = R (ONLY available in :doc:`fix deform/pressure <fix_deform_pressure>` command)
+             R = engineering shear strain rate (1/time units)
            *trate* value = R
              R = true shear strain rate (1/time units)
            *wiggle* values = A Tp
@@ -62,9 +74,12 @@ Syntax
            *variable* values = v_name1 v_name2
              v_name1 = variable with name1 for tilt change as function of time
              v_name2 = variable with name2 for change rate as function of time
+           *pressure* values = target gain (ONLY available in :doc:`fix deform/pressure <fix_deform_pressure>` command)
+             target = target pressure (pressure units)
+             gain = proportional gain constant (1/(time * pressure) or 1/time units)
 
 * zero or more keyword/value pairs may be appended
-* keyword = *remap* or *flip* or *units*
+* keyword = *remap* or *flip* or *units* or *couple* or *vol/balance/p* or *max/rate* or *normalize/pressure*
 
   .. parsed-literal::
 
@@ -77,6 +92,15 @@ Syntax
        *units* value = *lattice* or *box*
          lattice = distances are defined in lattice units
          box = distances are defined in simulation box units
+       *couple* value = *none* or *xyz* or *xy* or *yz* or *xz* (ONLY available in :doc:`fix deform/pressure <fix_deform_pressure>` command)
+         couple pressure values of various dimensions
+       *vol/balance/p* value = *yes* or *no* (ONLY available in :doc:`fix deform/pressure <fix_deform_pressure>` command)
+         Modifies the behavior of the *volume* option to try and balance pressures
+       *max/rate* value = *rate* (ONLY available in :doc:`fix deform/pressure <fix_deform_pressure>` command)
+         rate = maximum strain rate for pressure control
+       *normalize/pressure* value = *yes* or *no* (ONLY available in :doc:`fix deform/pressure <fix_deform_pressure>` command)
+         Modifies pressure controls such that the deviation in pressure is normalized by the target pressure
+
 
 Examples
 """"""""
@@ -88,6 +112,8 @@ Examples
    fix 1 all deform 1 xy erate 0.001 remap v
    fix 1 all deform 10 y delta -0.5 0.5 xz vel 1.0
 
+See examples for :doc:`fix deform/pressure <fix_deform_pressure>` on its doc page
+
 Description
 """""""""""
 
@@ -95,29 +121,46 @@ Change the volume and/or shape of the simulation box during a dynamics
 run.  Orthogonal simulation boxes have 3 adjustable parameters
 (x,y,z).  Triclinic (non-orthogonal) simulation boxes have 6
 adjustable parameters (x,y,z,xy,xz,yz).  Any or all of them can be
-adjusted independently and simultaneously by this command.
+adjusted independently and simultaneously.
 
-This fix can be used to perform non-equilibrium MD (NEMD) simulations
-of a continuously strained system.  See the :doc:`fix nvt/sllod <fix_nvt_sllod>` and :doc:`compute temp/deform <compute_temp_deform>` commands for more details.  Note
-that simulation of a continuously extended system (extensional flow)
-can be modeled using the :ref:`UEF package <PKG-UEF>` and its :doc:`fix commands <fix_nh_uef>`.
+The fix deform command allows use of all the arguments listed above,
+except those flagged as available ONLY for the :doc:`fix
+deform/pressure <fix_deform_pressure>` command, which are
+pressure-based controls.  The fix deform/pressure command allows use
+of all the arguments listed above.
+
+The rest of this doc page explains the options common to both
+commands.  The :doc:`fix deform/pressure <fix_deform_pressure>` doc
+page explains the options available ONLY with the fix deform/pressure
+command.  Note that a simulation can define only a single deformation
+command: fix deform or fix deform/pressure.
+
+Both these fixes can be used to perform non-equilibrium MD (NEMD)
+simulations of a continuously strained system.  See the :doc:`fix
+nvt/sllod <fix_nvt_sllod>` and :doc:`compute temp/deform
+<compute_temp_deform>` commands for more details.  Note that
+simulation of a continuously extended system (extensional flow) can be
+modeled using the :ref:`UEF package <PKG-UEF>` and its :doc:`fix
+commands <fix_nh_uef>`.
 
 For the *x*, *y*, *z* parameters, the associated dimension cannot be
 shrink-wrapped.  For the *xy*, *yz*, *xz* parameters, the associated
-second dimension cannot be shrink-wrapped.  Dimensions not varied by this
-command can be periodic or non-periodic.  Dimensions corresponding to
-unspecified parameters can also be controlled by a :doc:`fix npt <fix_nh>` or :doc:`fix nph <fix_nh>` command.
+second dimension cannot be shrink-wrapped.  Dimensions not varied by
+this command can be periodic or non-periodic.  Dimensions
+corresponding to unspecified parameters can also be controlled by a
+:doc:`fix npt <fix_nh>` or :doc:`fix nph <fix_nh>` command.
 
 The size and shape of the simulation box at the beginning of the
-simulation run were either specified by the
-:doc:`create_box <create_box>` or :doc:`read_data <read_data>` or
-:doc:`read_restart <read_restart>` command used to setup the simulation
-initially if it is the first run, or they are the values from the end
-of the previous run.  The :doc:`create_box <create_box>`, :doc:`read data <read_data>`, and :doc:`read_restart <read_restart>` commands
-specify whether the simulation box is orthogonal or non-orthogonal
-(triclinic) and explain the meaning of the xy,xz,yz tilt factors.  If
-fix deform changes the xy,xz,yz tilt factors, then the simulation box
-must be triclinic, even if its initial tilt factors are 0.0.
+simulation run were either specified by the :doc:`create_box
+<create_box>` or :doc:`read_data <read_data>` or :doc:`read_restart
+<read_restart>` command used to setup the simulation initially if it
+is the first run, or they are the values from the end of the previous
+run.  The :doc:`create_box <create_box>`, :doc:`read data
+<read_data>`, and :doc:`read_restart <read_restart>` commands specify
+whether the simulation box is orthogonal or non-orthogonal (triclinic)
+and explain the meaning of the xy,xz,yz tilt factors.  If fix deform
+changes the xy,xz,yz tilt factors, then the simulation box must be
+triclinic, even if its initial tilt factors are 0.0.
 
 As described below, the desired simulation box size and shape at the
 end of the run are determined by the parameters of the fix deform
@@ -258,21 +301,22 @@ of the units keyword below.
 
 The *variable* style changes the specified box length dimension by
 evaluating a variable, which presumably is a function of time.  The
-variable with *name1* must be an :doc:`equal-style variable <variable>`
-and should calculate a change in box length in units of distance.
-Note that this distance is in box units, not lattice units; see the
-discussion of the *units* keyword below.  The formula associated with
-variable *name1* can reference the current timestep.  Note that it
-should return the "change" in box length, not the absolute box length.
-This means it should evaluate to 0.0 when invoked on the initial
-timestep of the run following the definition of fix deform.  It should
-evaluate to a value > 0.0 to dilate the box at future times, or a
-value < 0.0 to compress the box.
+variable with *name1* must be an :doc:`equal-style variable
+<variable>` and should calculate a change in box length in units of
+distance.  Note that this distance is in box units, not lattice units;
+see the discussion of the *units* keyword below.  The formula
+associated with variable *name1* can reference the current timestep.
+Note that it should return the "change" in box length, not the
+absolute box length.  This means it should evaluate to 0.0 when
+invoked on the initial timestep of the run following the definition of
+fix deform.  It should evaluate to a value > 0.0 to dilate the box at
+future times, or a value < 0.0 to compress the box.
 
-The variable *name2* must also be an :doc:`equal-style variable <variable>` and should calculate the rate of box length
-change, in units of distance/time, i.e. the time-derivative of the
-*name1* variable.  This quantity is used internally by LAMMPS to reset
-atom velocities when they cross periodic boundaries.  It is computed
+The variable *name2* must also be an :doc:`equal-style variable
+<variable>` and should calculate the rate of box length change, in
+units of distance/time, i.e. the time-derivative of the *name1*
+variable.  This quantity is used internally by LAMMPS to reset atom
+velocities when they cross periodic boundaries.  It is computed
 internally for the other styles, but you must provide it when using an
 arbitrary variable.
 
@@ -414,12 +458,13 @@ can reference the current timestep.  Note that it should return the
 should evaluate to 0.0 when invoked on the initial timestep of the run
 following the definition of fix deform.
 
-The variable *name2* must also be an :doc:`equal-style variable <variable>` and should calculate the rate of tilt change,
-in units of distance/time, i.e. the time-derivative of the *name1*
-variable.  This quantity is used internally by LAMMPS to reset atom
-velocities when they cross periodic boundaries.  It is computed
-internally for the other styles, but you must provide it when using an
-arbitrary variable.
+The variable *name2* must also be an :doc:`equal-style variable
+<variable>` and should calculate the rate of tilt change, in units of
+distance/time, i.e. the time-derivative of the *name1* variable.  This
+quantity is used internally by LAMMPS to reset atom velocities when
+they cross periodic boundaries.  It is computed internally for the
+other styles, but you must provide it when using an arbitrary
+variable.
 
 Here is an example of using the *variable* style to perform the same
 box deformation as the *wiggle* style formula listed above, where we
@@ -510,33 +555,40 @@ box without explicit remapping of their coordinates.
 .. note::
 
    For non-equilibrium MD (NEMD) simulations using "remap v" it is
-   usually desirable that the fluid (or flowing material, e.g. granular
-   particles) stream with a velocity profile consistent with the
-   deforming box.  As mentioned above, using a thermostat such as :doc:`fix nvt/sllod <fix_nvt_sllod>` or :doc:`fix lavgevin <fix_langevin>`
-   (with a bias provided by :doc:`compute temp/deform <compute_temp_deform>`), will typically accomplish
-   that.  If you do not use a thermostat, then there is no driving force
-   pushing the atoms to flow in a manner consistent with the deforming
-   box.  E.g. for a shearing system the box deformation velocity may vary
+   usually desirable that the fluid (or flowing material,
+   e.g. granular particles) stream with a velocity profile consistent
+   with the deforming box.  As mentioned above, using a thermostat
+   such as :doc:`fix nvt/sllod <fix_nvt_sllod>` or :doc:`fix lavgevin
+   <fix_langevin>` (with a bias provided by :doc:`compute temp/deform
+   <compute_temp_deform>`), will typically accomplish that.  If you do
+   not use a thermostat, then there is no driving force pushing the
+   atoms to flow in a manner consistent with the deforming box.
+   E.g. for a shearing system the box deformation velocity may vary
    from 0 at the bottom to 10 at the top of the box.  But the stream
-   velocity profile of the atoms may vary from -5 at the bottom to +5 at
-   the top.  You can monitor these effects using the :doc:`fix ave/chunk <fix_ave_chunk>`, :doc:`compute temp/deform <compute_temp_deform>`, and :doc:`compute temp/profile <compute_temp_profile>` commands.  One way to induce
-   atoms to stream consistent with the box deformation is to give them an
+   velocity profile of the atoms may vary from -5 at the bottom to +5
+   at the top.  You can monitor these effects using the :doc:`fix
+   ave/chunk <fix_ave_chunk>`, :doc:`compute temp/deform
+   <compute_temp_deform>`, and :doc:`compute temp/profile
+   <compute_temp_profile>` commands.  One way to induce atoms to
+   stream consistent with the box deformation is to give them an
    initial velocity profile, via the :doc:`velocity ramp <velocity>`
-   command, that matches the box deformation rate.  This also typically
-   helps the system come to equilibrium more quickly, even if a
-   thermostat is used.
+   command, that matches the box deformation rate.  This also
+   typically helps the system come to equilibrium more quickly, even
+   if a thermostat is used.
 
 .. note::
 
    If a :doc:`fix rigid <fix_rigid>` is defined for rigid bodies, and
    *remap* is set to *x*, then the center-of-mass coordinates of rigid
-   bodies will be remapped to the changing simulation box.  This will be
-   done regardless of whether atoms in the rigid bodies are in the fix
-   deform group or not.  The velocity of the centers of mass are not
-   remapped even if *remap* is set to *v*, since :doc:`fix nvt/sllod <fix_nvt_sllod>` does not currently do anything special
+   bodies will be remapped to the changing simulation box.  This will
+   be done regardless of whether atoms in the rigid bodies are in the
+   fix deform group or not.  The velocity of the centers of mass are
+   not remapped even if *remap* is set to *v*, since :doc:`fix
+   nvt/sllod <fix_nvt_sllod>` does not currently do anything special
    for rigid particles.  If you wish to perform a NEMD simulation of
    rigid particles, you can either thermostat them independently or
-   include a background fluid and thermostat the fluid via :doc:`fix nvt/sllod <fix_nvt_sllod>`.
+   include a background fluid and thermostat the fluid via :doc:`fix
+   nvt/sllod <fix_nvt_sllod>`.
 
 The *flip* keyword allows the tilt factors for a triclinic box to
 exceed half the distance of the parallel box length, as discussed
@@ -568,7 +620,8 @@ command if you want to include lattice spacings in a variable formula.
 Restart, fix_modify, output, run start/stop, minimize info
 """""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 
-This fix will restore the initial box settings from :doc:`binary restart files <restart>`, which allows the fix to be properly continue
+This fix will restore the initial box settings from :doc:`binary
+restart files <restart>`, which allows the fix to be properly continue
 deformation, when using the start/stop options of the :doc:`run <run>`
 command.  None of the :doc:`fix_modify <fix_modify>` options are
 relevant to this fix.  No global or per-atom quantities are stored by
@@ -586,12 +639,14 @@ Restrictions
 You cannot apply x, y, or z deformations to a dimension that is
 shrink-wrapped via the :doc:`boundary <boundary>` command.
 
-You cannot apply xy, yz, or xz deformations to a second dimension (y in
-xy) that is shrink-wrapped via the :doc:`boundary <boundary>` command.
+You cannot apply xy, yz, or xz deformations to a second dimension (y
+in xy) that is shrink-wrapped via the :doc:`boundary <boundary>`
+command.
 
 Related commands
 """"""""""""""""
 
+:doc:`fix deform/pressure <fix_deform_pressure>`,
 :doc:`change_box <change_box>`
 
 Default

doc/src/fix_deform_pressure.rst

@@ -0,0 +1,340 @@
+.. index:: fix deform/pressure
+
+fix deform/pressure command
+===========================
+
+Syntax
+""""""
+
+.. parsed-literal::
+
+   fix ID group-ID deform/pressure N parameter style args ... keyword value ...
+
+* ID, group-ID are documented in :doc:`fix <fix>` command
+* deform/pressure = style name of this fix command
+* N = perform box deformation every this many timesteps
+* one or more parameter/arg sequences may be appended
+
+  .. parsed-literal::
+
+     parameter = *x* or *y* or *z* or *xy* or *xz* or *yz* or *box*
+       *x*, *y*, *z* args = style value(s)
+         style = *final* or *delta* or *scale* or *vel* or *erate* or *trate* or *volume* or *wiggle* or *variable* or *pressure* or *pressure/mean*
+           *pressure* values = target gain
+             target = target pressure (pressure units)
+             gain = proportional gain constant (1/(time * pressure) or 1/time units)
+           *pressure/mean* values = target gain
+             target = target pressure (pressure units)
+             gain = proportional gain constant (1/(time * pressure) or 1/time units)
+           NOTE: All other styles are documented by the :doc:`fix deform <fix_deform>` command
+
+       *xy*, *xz*, *yz* args = style value
+         style = *final* or *delta* or *vel* or *erate* or *trate* or *wiggle* or *variable* or *pressure* or *erate/rescale*
+           *pressure* values = target gain
+             target = target pressure (pressure units)
+             gain = proportional gain constant (1/(time * pressure) or 1/time units)
+           *erate/rescale* value = R
+             R = engineering shear strain rate (1/time units)
+           NOTE: All other styles are documented by the :doc:`fix deform <fix_deform>` command
+
+       *box* = style value
+         style = *volume* or *pressure*
+           *volume* value = none = isotropically adjust system to preserve volume of system
+           *pressure* values = target gain
+             target = target mean pressure (pressure units)
+             gain = proportional gain constant (1/(time * pressure) or 1/time units)
+
+* zero or more keyword/value pairs may be appended
+* keyword = *remap* or *flip* or *units* or *couple* or *vol/balance/p* or *max/rate* or *normalize/pressure*
+
+  .. parsed-literal::
+
+       *couple* value = *none* or *xyz* or *xy* or *yz* or *xz*
+         couple pressure values of various dimensions
+       *vol/balance/p* value = *yes* or *no*
+         Modifies the behavior of the *volume* option to try and balance pressures
+       *max/rate* value = *rate*
+         rate = maximum strain rate for pressure control
+       *normalize/pressure* value = *yes* or *no*
+         Modifies pressure controls such that the deviation in pressure is normalized by the target pressure
+       NOTE: All other keywords are documented by the :doc:`fix deform <fix_deform>` command
+
+Examples
+""""""""
+
+.. code-block:: LAMMPS
+
+   fix 1 all deform/pressure 1 x pressure 2.0 0.1 normalize/pressure yes max/rate 0.001
+   fix 1 all deform/pressure 1 x trate 0.1 y volume z volume vol/balance/p yes
+   fix 1 all deform/pressure 1 x trate 0.1 y pressure/mean 0.0 1.0 z pressure/mean 0.0 1.0
+
+Description
+"""""""""""
+
+.. versionadded:: 17Apr2024
+
+This fix is an extension of the :doc:`fix deform <fix_deform>`
+command, which allows all of its options to be used as well as new
+pressure-based controls implemented by this command.
+
+All arguments described on the :doc:`fix deform <fix_deform>` doc page
+also apply to this fix unless otherwise noted below.  The rest of this
+doc page explains the arguments specific to this fix.  Note that a
+simulation can define only a single deformation command: fix deform or
+fix deform/pressure.
+
+----------
+
+For the *x*, *y*, and *z* parameters, this is the meaning of the
+styles and values provided by this fix.
+
+The *pressure* style adjusts a dimension's box length to control the
+corresponding component of the pressure tensor. This option attempts to
+maintain a specified target pressure using a linear controller where the
+box length :math:`L` evolves according to the equation
+
+.. math::
+
+   \frac{d L(t)}{dt} = L(t) k (P_t - P)
+
+where :math:`k` is a proportional gain constant, :math:`P_t` is the target
+pressure, and :math:`P` is the current pressure along that dimension. This
+approach is similar to the method used to control the pressure by
+:doc:`fix press/berendsen <fix_press_berendsen>`. The target pressure
+accepts either a constant numeric value or a LAMMPS :ref:`variable <variable>`.
+Notably, this variable can be a function of time or other components of
+the pressure tensor. By default, :math:`k` has units of 1/(time * pressure)
+although this will change if the *normalize/pressure* option is set as
+:ref:`discussed below <deform_normalize>`. There is no proven method
+to choosing an appropriate value of :math:`k` as it will depend on the
+specific details of a simulation. Testing different values is recommended.
+
+By default, there is no limit on the resulting strain rate in any dimension.
+A maximum limit can be applied using the :ref:`max/rate <deform_max_rate>`
+option. Akin to :doc:`fix nh <fix_nh>`, pressures in different dimensions
+can be coupled using the :ref:`couple <deform_couple>` option. This means
+the instantaneous pressure along coupled dimensions are averaged and the box
+strains identically along the coupled dimensions.
+
+The *pressure/mean* style changes a dimension's box length to maintain
+a constant mean pressure defined as the trace of the pressure tensor.
+This option has identical arguments to the *pressure* style and a similar
+functional equation, except the current and target pressures refer to the
+mean trace of the pressure tensor. All options for the *pressure* style
+also apply to the *pressure/mean* style except for the
+:ref:`couple <deform_couple>` option.
+
+Note that while this style can be identical to coupled *pressure* styles,
+it is generally not the same. For instance in 2D, a coupled *pressure*
+style in the *x* and *y* dimensions would be equivalent to using the
+*pressure/mean* style with identical settings in each dimension. However,
+it would not be the same if settings (e.g. gain constants) were used in
+the *x* and *y* dimensions or if the *pressure/mean* command was only applied
+along one dimension.
+
+----------
+
+For the *xy*, *xz*, and *yz* parameters, this is the meaning of the
+styles and values provided by this fix.  Note that changing the
+tilt factors of a triclinic box does not change its volume.
+
+The *pressure* style adjusts a tilt factor to control the corresponding
+off-diagonal component of the pressure tensor. This option attempts to
+maintain a specified target value using a linear controller where the
+tilt factor T evolves according to the equation
+
+.. parsed-literal::
+
+   \frac{d T(t)}{dt} = L(t) k (P - P_t)
+
+where :math:`k` is a proportional gain constant, :math:`P_t` is the
+target pressure, :math:`P` is the current pressure, and :math:`L` is
+the perpendicular box length. The target pressure accepts either a
+constant numeric value or a LAMMPS :ref:`variable
+<variable>`. Notably, this variable can be a function of time or other
+components of the pressure tensor. By default, :math:`k` has units of
+1/(time * pressure) although this will change if the
+*normalize/pessure* option is set as :ref:`discussed below
+<deform_normalize>`.  There is no proven method to choosing an
+appropriate value of :math:`k` as it will depend on the specific
+details of a simulation and testing different values is
+recommended. One can also apply a maximum limit to the magnitude of
+the applied strain using the :ref:`max/rate <deform_max_rate>` option.
+
+The *erate/rescale* style operates similarly to the *erate* style with
+a specified strain rate in units of 1/time. The difference is that
+the change in the tilt factor will depend on the current length of
+the box perpendicular to the shear direction, L, instead of the
+original length, L0. The tilt factor T as a function of time will
+change as
+
+.. parsed-literal::
+
+   T(t) = T(t-1) + L\*erate\* \Delta t
+
+where T(t-1) is the tilt factor on the previous timestep and :math:`\Delta t`
+is the timestep size. This option may be useful in scenarios where
+L changes in time.
+
+----------
+
+The *box* parameter provides an additional control over the *x*, *y*,
+and *z* box lengths by isotropically dilating or contracting the box
+to either maintain a fixed mean pressure or volume. This isotropic
+scaling is applied after the box is deformed by the above *x*, *y*,
+*z*, *xy*, *xz*, and *yz* styles, acting as a second deformation
+step. This parameter will change the overall strain rate in the *x*,
+*y*, or *z* dimensions.  This parameter can only be used in
+combination with the *x*, *y*, or *z* commands: *vel*, *erate*,
+*trate*, *pressure*, or *wiggle*. This is the meaning of its styles
+and values.
+
+The *volume* style isotropically scales box lengths to maintain a constant
+box volume in response to deformation from other parameters. This style
+may be useful in scenarios where one wants to apply a constant deviatoric
+pressure using *pressure* styles in the *x*, *y*, and *z* dimensions (
+deforming the shape of the box), while maintaining a constant volume.
+
+The *pressure* style isotropically scales box lengths in an attempt to
+maintain a target mean pressure (the trace of the pressure tensor) of the
+system. This is accomplished by isotropically scaling all box lengths
+:math:`L` by an additional factor of :math:`k (P_t - P_m)` where :math:`k`
+is the proportional gain constant, :math:`P_t` is the target pressure, and
+:math:`P_m` is the current mean pressure. This style may be useful in
+scenarios where one wants to apply a constant deviatoric strain rate
+using various strain-based styles (e.g. *trate*) along the *x*, *y*, and *z*
+dimensions (deforming the shape of the box), while maintaining a mean pressure.
+
+----------
+
+The optional keywords provided by this fix are described below.
+
+.. _deform_normalize:
+
+The *normalize/pressure* keyword changes how box dimensions evolve when
+using the *pressure* or *pressure/mean* deformation styles. If the
+*deform/normalize* value is set to *yes*, then the deviation from the
+target pressure is normalized by the absolute value of the target
+pressure such that the proportional gain constant scales a percentage
+error and has units of 1/time. If the target pressure is ever zero, this
+will produce an error unless the *max/rate* keyword is defined,
+described below, which will cap the divergence.
+
+.. _deform_max_rate:
+
+The *max/rate* keyword sets an upper threshold, *rate*, that limits the
+maximum magnitude of the instantaneous strain rate applied in any dimension.
+This keyword only applies to the *pressure* and *pressure/mean* options. If
+a pressure-controlled rate is used for both *box* and either *x*, *y*, or
+*z*, then this threshold will apply separately to each individual controller
+such that the cumulative strain rate on a box dimension may be up to twice
+the value of *rate*.
+
+.. _deform_couple:
+
+The *couple* keyword allows two or three of the diagonal components of
+the pressure tensor to be "coupled" together for the *pressure* option.
+The value specified with the keyword determines which are coupled. For
+example, *xz* means the *Pxx* and *Pzz* components of the stress tensor
+are coupled. *Xyz* means all 3 diagonal components are coupled. Coupling
+means two things: the instantaneous stress will be computed as an average
+of the corresponding diagonal components, and the coupled box dimensions
+will be changed together in lockstep, meaning coupled dimensions will be
+dilated or contracted by the same percentage every timestep. If a *pressure*
+style is defined for more than one coupled dimension, the target pressures
+and gain constants must be identical. Alternatively, if a *pressure*
+style is only defined for one of the coupled dimensions, its settings are
+copied to other dimensions with undefined styles. *Couple xyz* can be used
+for a 2d simulation; the *z* dimension is simply ignored.
+
+.. _deform_balance:
+
+The *vol/balance/p* keyword modifies the behavior of the *volume* style when
+applied to two of the *x*, *y*, and *z* dimensions. Instead of straining
+the two dimensions in lockstep, the two dimensions are allowed to
+separately dilate or contract in a manner to maintain a constant
+volume while simultaneously trying to keep the pressure along each
+dimension equal using a method described in :ref:`(Huang2014) <Huang2014>`.
+
+----------
+
+If any pressure controls are used, this fix computes a temperature and
+pressure each timestep. To do this, the fix creates its own computes
+of style "temp" and "pressure", as if these commands had been issued:
+
+.. code-block:: LAMMPS
+
+   compute fix-ID_temp group-ID temp
+   compute fix-ID_press group-ID pressure fix-ID_temp
+
+See the :doc:`compute temp <compute_temp>` and :doc:`compute pressure
+<compute_pressure>` commands for details.  Note that the IDs of the
+new computes are the fix-ID + underscore + "temp" or fix_ID
++ underscore + "press", and the group for the new computes is the same
+as the fix group.
+
+Note that these are NOT the computes used by thermodynamic output (see
+the :doc:`thermo_style <thermo_style>` command) with ID =
+*thermo_temp* and *thermo_press*.  This means you can change the
+attributes of this fix's temperature or pressure via the
+:doc:`compute_modify <compute_modify>` command or print this
+temperature or pressure during thermodynamic output via the
+:doc:`thermo_style custom <thermo_style>` command using the
+appropriate compute-ID. It also means that changing attributes of
+*thermo_temp* or *thermo_press* will have no effect on this fix.
+
+Restart, fix_modify, output, run start/stop, minimize info
+"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
+
+This fix will restore the initial box settings from :doc:`binary
+restart files <restart>`, which allows the fix to be properly continue
+deformation, when using the start/stop options of the :doc:`run <run>`
+command.  No global or per-atom quantities are stored by this fix for
+access by various :doc:`output commands <Howto_output>`.
+
+If any pressure controls are used, the :doc:`fix_modify <fix_modify>`
+*temp* and *press* options are supported by this fix, unlike in
+:doc:`fix deform <fix_deform>`.  You can use them to assign a
+:doc:`compute <compute>` you have defined to this fix which will be
+used in its temperature and pressure calculations.  If you do this,
+note that the kinetic energy derived from the compute temperature
+should be consistent with the virial term computed using all atoms for
+the pressure.  LAMMPS will warn you if you choose to compute
+temperature on a subset of atoms.
+
+This fix can perform deformation over multiple runs, using the *start*
+and *stop* keywords of the :doc:`run <run>` command.  See the
+:doc:`run <run>` command for details of how to do this.
+
+This fix is not invoked during :doc:`energy minimization <minimize>`.
+
+Restrictions
+""""""""""""
+
+This fix is part of the EXTRA-FIX package.  It is only enabled if LAMMPS
+was built with that package.  See the :doc:`Build package <Build_package>`
+page for more info.
+
+You cannot apply x, y, or z deformations to a dimension that is
+shrink-wrapped via the :doc:`boundary <boundary>` command.
+
+You cannot apply xy, yz, or xz deformations to a second dimension (y
+in xy) that is shrink-wrapped via the :doc:`boundary <boundary>`
+command.
+
+Related commands
+""""""""""""""""
+
+:doc:`fix deform <fix_deform>`, :doc:`change_box <change_box>`
+
+Default
+"""""""
+
+The option defaults are normalize/pressure = no.
+
+----------
+
+.. _Huang2014:
+
+**(Huang2014)** X. Huang, "Exploring critical-state behavior using DEM",
+Doctoral dissertation, Imperial College. (2014). https://doi.org/10.25560/25316

doc/src/fix_deposit.rst

@@ -13,7 +13,7 @@ Syntax
 * ID, group-ID are documented in :doc:`fix <fix>` command
 * deposit = style name of this fix command
 * N = # of atoms or molecules to insert
-* type = atom type to assign to inserted atoms (offset for molecule insertion)
+* type = atom type (1-Ntypes or type label) to assign to inserted atoms (offset for molecule insertion)
 * M = insert a single atom or molecule every M steps
 * seed = random # seed (positive integer)
 * one or more keyword/value pairs may be appended to args
@@ -76,6 +76,9 @@ Examples
    fix 4 sputter deposit 1000 2 500 12235 region sphere vz -1.0 -1.0 target 5.0 5.0 0.0 units lattice
    fix 5 insert deposit 200 2 100 777 region disk gaussian 5.0 5.0 9.0 1.0 units box
 
+   labelmap atom 1 Au
+   fix 4 sputter deposit 1000 Au 500 12235 region sphere vz -1.0 -1.0 target 5.0 5.0 0.0 units lattice
+
 Description
 """""""""""
 

doc/src/fix_electrode.rst

@@ -45,7 +45,7 @@ Syntax
                 rng_v = integer used to initialize random number generator
 
 * zero or more keyword/value pairs may be appended
-* keyword = *algo* or *symm* or *couple* or *etypes* or *ffield* or *write_mat* or *write_inv* or *read_mat* or *read_inv*
+* keyword = *algo* or *symm* or *couple* or *etypes* or *ffield* or *write_mat* or *write_inv* or *read_mat* or *read_inv* or *qtotal* or *eta*
 
 .. parsed-literal::
 
@@ -68,6 +68,10 @@ Syntax
         filename = file from which to read elastance matrix
     *read_inv* value = filename
         filename = file from which to read inverted matrix
+    *qtotal* value = number or *v_* equal-style variable
+        add overall potential so that all electrode charges add up to *qtotal*
+    *eta* value = d_propname
+        d_propname = a custom double vector defined via fix property/atom
 
 Examples
 """"""""
@@ -249,6 +253,27 @@ be enabled if any electrode particle has the same type as any
 electrolyte particle (which would be unusual in a typical simulation)
 and the fix will issue an error in that case.
 
+.. versionadded:: 17Apr2024
+
+The keyword *qtotal* causes *fix electrode/conp* and *fix
+electrode/thermo* to add an overall potential to all electrodes so that
+the total charge on the electrodes is a specified amount (which may be
+an equal-style variable).  For example, if a user wanted to simulate a
+solution of excess cations such that the total electrolyte charge is +2,
+setting *qtotal -2* would cause the total electrode charge to be -2, so
+that the simulation box remains overall electroneutral. Since *fix
+electrode/conq* constrains the total charges of individual electrodes,
+and since *symm on* constrains the total charge of all electrodes to be
+zero, either option is incompatible with the *qtotal* keyword (even if
+*qtotal* is set to zero).
+
+.. versionadded:: 17Apr2024
+
+The keyword *eta* takes the name of a custom double vector defined via
+fix property/atom.  The values will be used instead of the standard eta
+value.  The property/atom fix must be for vector of double values and
+use the *ghost on* option.
+
 Restart, fix_modify, output, run start/stop, minimize info
 """""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 

doc/src/fix_gcmc.rst

@@ -15,7 +15,7 @@ Syntax
 * N = invoke this fix every N steps
 * X = average number of GCMC exchanges to attempt every N steps
 * M = average number of MC moves to attempt every N steps
-* type = atom type for inserted atoms (must be 0 if mol keyword used)
+* type = atom type (1-Ntypes or type label) for inserted atoms (must be 0 if mol keyword used)
 * seed = random # seed (positive integer)
 * T = temperature of the ideal gas reservoir (temperature units)
 * mu = chemical potential of the ideal gas reservoir (energy units)
@@ -45,7 +45,7 @@ Syntax
        *group* value = group-ID
          group-ID = group-ID for inserted atoms (string)
        *grouptype* values = type group-ID
-         type = atom type (int)
+         type = atom type (1-Ntypes or type label)
          group-ID = group-ID for inserted atoms (string)
        *intra_energy* value = intramolecular energy (energy units)
        *tfac_insert* value = scale up/down temperature of inserted atoms (unitless)
@@ -62,52 +62,47 @@ Examples
    fix 3 water gcmc 10 100 100 0 3456543 3.0 -2.5 0.1 mol my_one_water maxangle 180 full_energy
    fix 4 my_gas gcmc 1 10 10 1 123456543 300.0 -12.5 1.0 region disk
 
+   labelmap atom 1 Li
+   fix 2 ion gcmc 10 1000 1000 Li 29494 298.0 -0.5 0.01
+
 Description
 """""""""""
 
-This fix performs grand canonical Monte Carlo (GCMC) exchanges of
-atoms or molecules with an imaginary ideal gas
-reservoir at the specified T and chemical potential (mu) as discussed
-in :ref:`(Frenkel) <Frenkel2>`. It also
-attempts  Monte Carlo (MC) moves (translations and molecule
-rotations) within the simulation cell or
-region. If used with the :doc:`fix nvt <fix_nh>`
+This fix performs grand canonical Monte Carlo (GCMC) exchanges of atoms or
+molecules with an imaginary ideal gas reservoir at the specified T and
+chemical potential (mu) as discussed in :ref:`(Frenkel) <Frenkel2>`.  It
+also attempts Monte Carlo (MC) moves (translations and molecule rotations)
+within the simulation cell or region.  If used with the :doc:`fix nvt <fix_nh>`
 command, simulations in the grand canonical ensemble (muVT, constant
 chemical potential, constant volume, and constant temperature) can be
 performed.  Specific uses include computing isotherms in microporous
 materials, or computing vapor-liquid coexistence curves.
 
-Every N timesteps the fix attempts both GCMC exchanges
-(insertions or deletions) and MC moves of gas atoms or molecules.
-On those timesteps, the average number of attempted GCMC exchanges is X,
-while the average number of attempted MC moves is M.
-For GCMC exchanges of either molecular or atomic gasses,
-these exchanges can be either deletions or insertions,
-with equal probability.
+Every N timesteps the fix attempts both GCMC exchanges (insertions or
+deletions) and MC moves of gas atoms or molecules.  On those timesteps, the
+average number of attempted GCMC exchanges is X, while the average number
+of attempted MC moves is M.  For GCMC exchanges of either molecular or
+atomic gasses, these exchanges can be either deletions or insertions, with
+equal probability.
 
-The possible choices for MC moves are translation of an atom,
-translation of a molecule, and rotation of a molecule.
-The relative amounts of each are determined by the optional
-*mcmoves* keyword (see below).
-The default behavior is as follows.
-If the *mol* keyword is used, only molecule translations
-and molecule rotations are performed with equal probability.
-Conversely, if the *mol* keyword is not used, only atom
-translations are performed.
-M should typically be
-chosen to be approximately equal to the expected number of gas atoms
-or molecules of the given type within the simulation cell or region,
-which will result in roughly one MC move per atom or molecule
-per MC cycle.
+The possible choices for MC moves are translation of an atom, translation
+of a molecule, and rotation of a molecule.  The relative amounts of each are
+determined by the optional *mcmoves* keyword (see below).  The default
+behavior is as follows. If the *mol* keyword is used, only molecule
+translations and molecule rotations are performed with equal probability.
+Conversely, if the *mol* keyword is not used, only atom translations are
+performed.  M should typically be chosen to be approximately equal to the
+expected number of gas atoms or molecules of the given type within the
+simulation cell or region, which will result in roughly one MC move per
+atom or molecule per MC cycle.
 
-All inserted particles are always added to two groups: the default
-group "all" and the fix group specified in the fix command.
-In addition, particles are also added to any groups
-specified by the *group* and *grouptype* keywords.  If inserted
-particles are individual atoms, they are assigned the atom type given
-by the type argument.  If they are molecules, the type argument has no
-effect and must be set to zero. Instead, the type of each atom in the
-inserted molecule is specified in the file read by the
+All inserted particles are always added to two groups: the default group
+"all" and the fix group specified in the fix command.  In addition,
+particles are also added to any groups specified by the *group* and
+*grouptype* keywords.  If inserted particles are individual atoms, they are
+assigned the atom type given by the type argument.  If they are molecules,
+the type argument has no effect and must be set to zero. Instead, the type
+of each atom in the inserted molecule is specified in the file read by the
 :doc:`molecule <molecule>` command.
 
 .. note::
@@ -427,7 +422,7 @@ the following global cumulative quantities:
 * 7 = rotation attempts
 * 8 = rotation successes
 
-The vector values calculated by this fix are "extensive".
+The vector values calculated by this fix are "intensive".
 
 No parameter of this fix can be used with the *start/stop* keywords of
 the :doc:`run <run>` command.  This fix is not invoked during
@@ -440,8 +435,11 @@ This fix is part of the MC package.  It is only enabled if LAMMPS was
 built with that package.  See the :doc:`Build package <Build_package>`
 doc page for more info.
 
+This fix style requires an :doc:`atom style <atom_style>` with per atom
+type masses.
+
 Do not set "neigh_modify once yes" or else this fix will never be
-called.  Reneighboring is required.
+called.  Reneighboring is **required**.
 
 Only usable for 3D simulations.
 

doc/src/fix_hyper_local.rst

@@ -512,8 +512,7 @@ Value 27 computes the average boost for biased bonds only on this step.
 Value 28 is the count of bonds with an absolute value of strain >= q
 on this step.
 
-The scalar value is an "extensive" quantity since it grows with the
-system size; the vector values are all "intensive".
+The scalar value and vector values are all "intensive".
 
 This fix also computes a local vector of length the number of bonds
 currently in the system.  The value for each bond is its :math:`C_{ij}`

doc/src/fix_indent.rst

@@ -8,33 +8,44 @@ Syntax
 
 .. code-block:: LAMMPS
 
-   fix ID group-ID indent K keyword values ...
+   fix ID group-ID indent K gstyle args keyword value ...
 
 * ID, group-ID are documented in :doc:`fix <fix>` command
 * indent = style name of this fix command
 * K = force constant for indenter surface (force/distance\^2 units)
-* one or more keyword/value pairs may be appended
-* keyword = *sphere* or *cylinder* or *plane* or *side* or *units*
+* gstyle = *sphere* or *cylinder* or *cone* or *plane*
 
   .. parsed-literal::
 
        *sphere* args = x y z R
-         x,y,z = position of center of indenter (distance units)
+         x, y, z = position of center of indenter (distance units)
          R = sphere radius of indenter (distance units)
-         any of x,y,z,R can be a variable (see below)
+         any of x, y, z, R can be a variable (see below)
        *cylinder* args = dim c1 c2 R
          dim = *x* or *y* or *z* = axis of cylinder
-         c1,c2 = coords of cylinder axis in other 2 dimensions (distance units)
+         c1, c2 = coords of cylinder axis in other 2 dimensions (distance units)
          R = cylinder radius of indenter (distance units)
          any of c1,c2,R can be a variable (see below)
+       *cone* args = dim c1 c2 radlo radhi lo hi
+         dim = *x* or *y* or *z* = axis of cone
+         c1, c2 = coords of cone axis in other 2 dimensions (distance units)
+         radlo,radhi = cone radii at lo and hi end (distance units)
+         lo,hi = bounds of cone in dim (distance units)
+         any of c1, c2, radlo, radhi, lo, hi can be a variable (see below)
        *plane* args = dim pos side
          dim = *x* or *y* or *z* = plane perpendicular to this dimension
          pos = position of plane in dimension x, y, or z (distance units)
          pos can be a variable (see below)
          side = *lo* or *hi*
+
+* zero or more keyword/value pairs may be appended
+* keyword = *side* or *units*
+
+  .. parsed-literal::
+
        *side* value = *in* or *out*
-         *in* = the indenter acts on particles inside the sphere or cylinder
-         *out* = the indenter acts on particles outside the sphere or cylinder
+         *in* = the indenter acts on particles inside the sphere or cylinder or cone
+         *out* = the indenter acts on particles outside the sphere or cylinder or cone
        *units* value = *lattice* or *box*
          lattice = the geometry is defined in lattice units
          box = the geometry is defined in simulation box units
@@ -53,12 +64,12 @@ Description
 
 Insert an indenter within a simulation box.  The indenter repels all
 atoms in the group that touch it, so it can be used to push into a
-material or as an obstacle in a flow.  Or it can be used as a
+material or as an obstacle in a flow.  Alternatively, it can be used as a
 constraining wall around a simulation; see the discussion of the
 *side* keyword below.
 
-The indenter can either be spherical or cylindrical or planar.  You
-must set one of those 3 keywords.
+The *gstyle* geometry of the indenter can either be a sphere, a
+cylinder, a cone, or a plane.
 
 A spherical indenter exerts a force of magnitude
 
@@ -75,15 +86,20 @@ A cylindrical indenter exerts the same force, except that *r* is the
 distance from the atom to the center axis of the cylinder.  The
 cylinder extends infinitely along its axis.
 
-Spherical and cylindrical indenters account for periodic boundaries in
-two ways.  First, the center point of a spherical indenter (x,y,z) or
-axis of a cylindrical indenter (c1,c2) is remapped back into the
-simulation box, if the box is periodic in a particular dimension.
-This occurs every timestep if the indenter geometry is specified with
-a variable (see below), e.g. it is moving over time.  Second, the
-calculation of distance to the indenter center or axis accounts for
-periodic boundaries.  Both of these mean that an indenter can
-effectively move through and straddle one or more periodic boundaries.
+A conical indenter is similar to a cylindrical indenter except that it
+has a finite length (between *lo* and *hi*), and that two different
+radii (one at each end, *radlo* and *radhi*) can be defined.
+
+Spherical, cylindrical, and conical indenters account for periodic
+boundaries in two ways.  First, the center point of a spherical
+indenter (x,y,z) or axis of a cylindrical/conical indenter (c1,c2) is
+remapped back into the simulation box, if the box is periodic in a
+particular dimension.  This occurs every timestep if the indenter
+geometry is specified with a variable (see below), e.g. it is moving
+over time.  Second, the calculation of distance to the indenter center
+or axis accounts for periodic boundaries.  Both of these mean that an
+indenter can effectively move through and straddle one or more
+periodic boundaries.
 
 A planar indenter is really an axis-aligned infinite-extent wall
 exerting the same force on atoms in the system, where *R* is the
@@ -97,9 +113,13 @@ is specified as *hi*\ .
 
 Any of the 4 quantities defining a spherical indenter's geometry can
 be specified as an equal-style :doc:`variable <variable>`, namely *x*,
-*y*, *z*, or *R*\ .  Similarly, for a cylindrical indenter, any of *c1*,
-*c2*, or *R*, can be a variable.  For a planar indenter, *pos* can be
-a variable.  If the value is a variable, it should be specified as
+*y*, *z*, or *R*\ .  For a cylindrical indenter, any of the 3
+quantities *c1*, *c2*, or *R*, can be a variable.  For a conical
+indenter, any of the 6 quantities *c1*, *c2*, *radlo*, *radhi*, *lo*,
+or *hi* can be a variable.  For a planar indenter, the single value
+*pos* can be a variable.
+
+If any of these values is a variable, it should be specified as
 v_name, where name is the variable name.  In this case, the variable
 will be evaluated each timestep, and its value used to define the
 indenter geometry.
@@ -110,7 +130,8 @@ command keywords for the simulation box parameters and timestep and
 elapsed time.  Thus it is easy to specify indenter properties that
 change as a function of time or span consecutive runs in a continuous
 fashion.  For the latter, see the *start* and *stop* keywords of the
-:doc:`run <run>` command and the *elaplong* keyword of :doc:`thermo_style custom <thermo_style>` for details.
+:doc:`run <run>` command and the *elaplong* keyword of
+:doc:`thermo_style custom <thermo_style>` for details.
 
 For example, if a spherical indenter's x-position is specified as v_x,
 then this variable definition will keep it's center at a relative
@@ -141,12 +162,13 @@ rate.
 
 If the *side* keyword is specified as *out*, which is the default,
 then particles outside the indenter are pushed away from its outer
-surface, as described above.  This only applies to spherical or
-cylindrical indenters.  If the *side* keyword is specified as *in*,
-the action of the indenter is reversed.  Particles inside the indenter
-are pushed away from its inner surface.  In other words, the indenter
-is now a containing wall that traps the particles inside it.  If the
-radius shrinks over time, it will squeeze the particles.
+surface, as described above.  This only applies to spherical,
+cylindrical, and conical indenters.  If the *side* keyword is
+specified as *in*, the action of the indenter is reversed.  Particles
+inside the indenter are pushed away from its inner surface.  In other
+words, the indenter is now a containing wall that traps the particles
+inside it.  If the radius shrinks over time, it will squeeze the
+particles.
 
 The *units* keyword determines the meaning of the distance units used
 to define the indenter geometry.  A *box* value selects standard
@@ -166,10 +188,10 @@ lattice spacings in a variable formula.
 
 The force constant *K* is not affected by the *units* keyword.  It is
 always in force/distance\^2 units where force and distance are defined
-by the :doc:`units <units>` command.  If you wish K to be scaled by the
-lattice spacing, you can define K with a variable whose formula
-contains *xlat*, *ylat*, *zlat* keywords of the
-:doc:`thermo_style <thermo_style>` command, e.g.
+by the :doc:`units <units>` command.  If you wish K to be scaled by
+the lattice spacing, you can define K with a variable whose formula
+contains *xlat*, *ylat*, *zlat* keywords of the :doc:`thermo_style
+<thermo_style>` command, e.g.
 
 .. code-block:: LAMMPS