Merge branch 'develop' into fix-mdi-qmmm

.github/CODEOWNERS

@@ -63,6 +63,7 @@ src/MANYBODY/pair_vashishta_table.* @andeplane
 src/MANYBODY/pair_atm.*             @sergeylishchuk
 src/REPLICA/*_grem.*                @dstelter92
 src/EXTRA-COMPUTE/compute_stress_mop*.* @RomainVermorel
+src/EXTRA-COMPUTE/compute_born_matrix.* @Bibobu @athomps
 src/MISC/*_tracker.*                @jtclemm
 src/MC/fix_gcmc.*                   @athomps
 src/MC/fix_sgcmc.*                  @athomps

.github/workflows/codeql-analysis.yml

@@ -49,7 +49,9 @@ jobs:
       shell: bash
       working-directory: build
       run: |
-        cmake -C ../cmake/presets/most.cmake ../cmake
+        cmake -C ../cmake/presets/most.cmake \
+              -D DOWNLOAD_POTENTIALS=off \
+              ../cmake
         cmake --build . --parallel 2
 
     - name: Perform CodeQL Analysis

.github/workflows/compile-msvc.yml

@@ -36,6 +36,7 @@ jobs:
         nuget install MSMPIsdk
         nuget install MSMPIDIST
         cmake -C cmake/presets/windows.cmake \
+              -D DOWNLOAD_POTENTIALS=off \
               -D PKG_PYTHON=on \
               -D WITH_PNG=off \
               -D WITH_JPEG=off \

.github/workflows/unittest-macos.yml

@@ -47,6 +47,7 @@ jobs:
         python3 -m pip install pyyaml
         cmake -C ../cmake/presets/clang.cmake \
               -C ../cmake/presets/most.cmake \
+              -D DOWNLOAD_POTENTIALS=off \
               -D CMAKE_CXX_COMPILER_LAUNCHER=ccache \
               -D CMAKE_C_COMPILER_LAUNCHER=ccache \
               -D ENABLE_TESTING=on \

.gitignore

@@ -55,3 +55,5 @@ out/RelWithDebInfo
 out/Release
 out/x86
 out/x64
+src/Makefile.package-e
+src/Makefile.package.settings-e

cmake/CMakeLists.txt

@@ -265,6 +265,7 @@ set(STANDARD_PACKAGES
   MC
   MDI
   MEAM
+  MESONT
   MGPT
   MISC
   ML-HDNNP
@@ -308,9 +309,8 @@ set(STANDARD_PACKAGES
   YAFF)
 
 set(SUFFIX_PACKAGES CORESHELL GPU KOKKOS OPT INTEL OPENMP)
-set(EXTRA_PACKAGES MESONT)
 
-foreach(PKG ${STANDARD_PACKAGES} ${EXTRA_PACKAGES} ${SUFFIX_PACKAGES})
+foreach(PKG ${STANDARD_PACKAGES} ${SUFFIX_PACKAGES})
   option(PKG_${PKG} "Build ${PKG} Package" OFF)
 endforeach()
 
@@ -520,7 +520,7 @@ else()
   set(CUDA_REQUEST_PIC)
 endif()
 
-foreach(PKG_WITH_INCL KSPACE PYTHON ML-IAP VORONOI COLVARS ML-HDNNP MDI MOLFILE MESONT NETCDF
+foreach(PKG_WITH_INCL KSPACE PYTHON ML-IAP VORONOI COLVARS ML-HDNNP MDI MOLFILE NETCDF
         PLUMED QMMM ML-QUIP SCAFACOS MACHDYN VTK KIM LATTE MSCG COMPRESS ML-PACE LEPTON)
   if(PKG_${PKG_WITH_INCL})
     include(Packages/${PKG_WITH_INCL})
@@ -566,7 +566,9 @@ RegisterStyles(${LAMMPS_SOURCE_DIR})
 ########################################################
 # Fetch missing external files and archives for packages
 ########################################################
-foreach(PKG ${STANDARD_PACKAGES} ${EXTRA_PACKAGES} ${SUFFIX_PACKAGES})
+option(DOWNLOAD_POTENTIALS "Automatically download large potential files" ON)
+mark_as_advanced(DOWNLOAD_POTENTIALS)
+foreach(PKG ${STANDARD_PACKAGES} ${SUFFIX_PACKAGES})
   if(PKG_${PKG})
     FetchPotentials(${LAMMPS_SOURCE_DIR}/${PKG} ${LAMMPS_POTENTIALS_DIR})
   endif()
@@ -706,7 +708,7 @@ target_include_directories(lammps PRIVATE ${LAMMPS_STYLE_HEADERS_DIR})
 ######################################
 set(temp "#ifndef LMP_INSTALLED_PKGS_H\n#define LMP_INSTALLED_PKGS_H\n")
 set(temp "${temp}const char * LAMMPS_NS::LAMMPS::installed_packages[] =  {\n")
-set(temp_PKG_LIST ${STANDARD_PACKAGES} ${EXTRA_PACKAGES} ${SUFFIX_PACKAGES})
+set(temp_PKG_LIST ${STANDARD_PACKAGES} ${SUFFIX_PACKAGES})
 list(SORT temp_PKG_LIST)
 foreach(PKG ${temp_PKG_LIST})
     if(PKG_${PKG})
@@ -927,7 +929,7 @@ message(STATUS "<<< Build configuration >>>
 # Print package summary
 ###############################################################################
 set(ENABLED_PACKAGES)
-foreach(PKG ${STANDARD_PACKAGES} ${EXTRA_PACKAGES} ${SUFFIX_PACKAGES})
+foreach(PKG ${STANDARD_PACKAGES} ${SUFFIX_PACKAGES})
   if(PKG_${PKG})
     list(APPEND ENABLED_PACKAGES ${PKG})
   endif()

cmake/Modules/ExternalCMakeProject.cmake

@@ -9,8 +9,22 @@ function(ExternalCMakeProject target url hash basedir cmakedir cmakefile)
 
   get_filename_component(archive ${url} NAME)
   file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/_deps/src)
-  message(STATUS "Downloading ${url}")
+  if(EXISTS ${CMAKE_BINARY_DIR}/_deps/${archive})
-  file(DOWNLOAD ${url} ${CMAKE_BINARY_DIR}/_deps/${archive} EXPECTED_HASH MD5=${hash} SHOW_PROGRESS)
+    file(MD5 ${CMAKE_BINARY_DIR}/_deps/${archive} DL_MD5)
+  endif()
+  if(NOT "${DL_MD5}" STREQUAL "${hash}")
+    message(STATUS "Downloading ${url}")
+    file(DOWNLOAD ${url} ${CMAKE_BINARY_DIR}/_deps/${archive} STATUS DL_STATUS SHOW_PROGRESS)
+    file(MD5 ${CMAKE_BINARY_DIR}/_deps/${archive} DL_MD5)
+    if((NOT DL_STATUS EQUAL 0) OR (NOT "${DL_MD5}" STREQUAL "${hash}"))
+      set(${target}_URL ${url})
+      GetFallbackURL(${target}_URL fallback)
+      message(WARNING "Download from primary URL ${url} failed\nTrying fallback URL ${fallback}")
+      file(DOWNLOAD ${fallback} ${CMAKE_BINARY_DIR}/_deps/${archive} EXPECTED_HASH MD5=${hash} SHOW_PROGRESS)
+    endif()
+  else()
+    message(STATUS "Using already downloaded archive ${CMAKE_BINARY_DIR}/_deps/${archive}")
+  endif()
   message(STATUS "Unpacking and configuring ${archive}")
   execute_process(COMMAND ${CMAKE_COMMAND} -E tar xzf ${CMAKE_BINARY_DIR}/_deps/${archive}
     WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/_deps/src)

cmake/Modules/LAMMPSUtils.cmake

@@ -99,8 +99,15 @@ function(check_for_autogen_files source_dir)
 endfunction()
 
 macro(pkg_depends PKG1 PKG2)
-  if(PKG_${PKG1} AND NOT (PKG_${PKG2} OR BUILD_${PKG2}))
+  if(DEFINED BUILD_${PKG2})
-    message(FATAL_ERROR "The ${PKG1} package needs LAMMPS to be built with the ${PKG2} package")
+    if(PKG_${PKG1} AND NOT BUILD_${PKG2})
+      message(FATAL_ERROR "The ${PKG1} package needs LAMMPS to be built with -D BUILD_${PKG2}=ON")
+    endif()
+  elseif(DEFINED PKG_${PKG2})
+    if(PKG_${PKG1} AND NOT PKG_${PKG2})
+      message(WARNING "The ${PKG1} package depends on the ${PKG2} package. Enabling it.")
+      set(PKG_${PKG2} ON CACHE BOOL "" FORCE)
+    endif()
   endif()
 endmacro()
 
@@ -118,25 +125,27 @@ endfunction(GenerateBinaryHeader)
 
 # fetch missing potential files
 function(FetchPotentials pkgfolder potfolder)
-  if(EXISTS "${pkgfolder}/potentials.txt")
+  if(DOWNLOAD_POTENTIALS)
-    file(STRINGS "${pkgfolder}/potentials.txt" linelist REGEX "^[^#].")
+    if(EXISTS "${pkgfolder}/potentials.txt")
-    foreach(line ${linelist})
+      file(STRINGS "${pkgfolder}/potentials.txt" linelist REGEX "^[^#].")
-      string(FIND ${line} " " blank)
+      foreach(line ${linelist})
-      math(EXPR plusone "${blank}+1")
+        string(FIND ${line} " " blank)
-      string(SUBSTRING ${line} 0 ${blank} pot)
+        math(EXPR plusone "${blank}+1")
-      string(SUBSTRING ${line} ${plusone} -1 sum)
+        string(SUBSTRING ${line} 0 ${blank} pot)
-      if(EXISTS "${LAMMPS_POTENTIALS_DIR}/${pot}")
+        string(SUBSTRING ${line} ${plusone} -1 sum)
-        file(MD5 "${LAMMPS_POTENTIALS_DIR}/${pot}" oldsum)
+        if(EXISTS "${LAMMPS_POTENTIALS_DIR}/${pot}")
-      endif()
+          file(MD5 "${LAMMPS_POTENTIALS_DIR}/${pot}" oldsum)
-      if(NOT sum STREQUAL oldsum)
+        endif()
-        message(STATUS "Downloading external potential ${pot} from ${LAMMPS_POTENTIALS_URL}")
+        if(NOT sum STREQUAL oldsum)
-        string(MD5 TMP_EXT "${CMAKE_BINARY_DIR}")
+          message(STATUS "Downloading external potential ${pot} from ${LAMMPS_POTENTIALS_URL}")
-        file(DOWNLOAD "${LAMMPS_POTENTIALS_URL}/${pot}.${sum}" "${CMAKE_BINARY_DIR}/${pot}.${TMP_EXT}"
+          string(RANDOM LENGTH 10 TMP_EXT)
-          EXPECTED_HASH MD5=${sum} SHOW_PROGRESS)
+          file(DOWNLOAD "${LAMMPS_POTENTIALS_URL}/${pot}.${sum}" "${CMAKE_BINARY_DIR}/${pot}.${TMP_EXT}"
-        file(COPY "${CMAKE_BINARY_DIR}/${pot}.${TMP_EXT}" DESTINATION "${LAMMPS_POTENTIALS_DIR}")
+            EXPECTED_HASH MD5=${sum} SHOW_PROGRESS)
-        file(RENAME "${LAMMPS_POTENTIALS_DIR}/${pot}.${TMP_EXT}" "${LAMMPS_POTENTIALS_DIR}/${pot}")
+          file(COPY "${CMAKE_BINARY_DIR}/${pot}.${TMP_EXT}" DESTINATION "${LAMMPS_POTENTIALS_DIR}")
-      endif()
+          file(RENAME "${LAMMPS_POTENTIALS_DIR}/${pot}.${TMP_EXT}" "${LAMMPS_POTENTIALS_DIR}/${pot}")
-    endforeach()
+        endif()
+      endforeach()
+    endif()
   endif()
 endfunction(FetchPotentials)
 
@@ -149,3 +158,14 @@ if((CMAKE_SYSTEM_NAME STREQUAL "Linux") AND (EXISTS /etc/os-release))
   set(CMAKE_LINUX_DISTRO ${distro})
   set(CMAKE_DISTRO_VERSION ${disversion})
 endif()
+
+function(GetFallbackURL input output)
+  string(REPLACE "_URL" "" _tmp ${input})
+  string(TOLOWER ${_tmp} libname)
+  string(REGEX REPLACE "^https://.*/([^/]+gz)" "${LAMMPS_THIRDPARTY_URL}/${libname}-\\1" newurl "${${input}}")
+  if ("${newurl}" STREQUAL "${${input}}")
+    set(${output} "" PARENT_SCOPE)
+  else()
+    set(${output} ${newurl} PARENT_SCOPE)
+  endif()
+endfunction(GetFallbackURL)

cmake/Modules/Packages/COMPRESS.cmake

@@ -1,4 +1,9 @@
-find_package(ZLIB REQUIRED)
+find_package(ZLIB)
+if(NOT ZLIB_FOUND)
+  message(WARNING "No Zlib development support found. Disabling COMPRESS package...")
+  set(PKG_COMPRESS OFF CACHE BOOL "" FORCE)
+  return()
+endif()
 target_link_libraries(lammps PRIVATE ZLIB::ZLIB)
 
 find_package(PkgConfig QUIET)

cmake/Modules/Packages/GPU.cmake

@@ -26,6 +26,19 @@ elseif(GPU_PREC STREQUAL "SINGLE")
   set(GPU_PREC_SETTING "SINGLE_SINGLE")
 endif()
 
+option(GPU_DEBUG "Enable debugging code of the GPU package" OFF)
+mark_as_advanced(GPU_DEBUG)
+
+if(PKG_AMOEBA AND FFT_SINGLE)
+  message(FATAL_ERROR "GPU acceleration of AMOEBA is not (yet) compatible with single precision FFT")
+endif()
+
+if (PKG_AMOEBA)
+  list(APPEND GPU_SOURCES
+              ${GPU_SOURCES_DIR}/amoeba_convolution_gpu.h
+              ${GPU_SOURCES_DIR}/amoeba_convolution_gpu.cpp)
+endif()
+
 file(GLOB GPU_LIB_SOURCES ${CONFIGURE_DEPENDS} ${LAMMPS_LIB_SOURCE_DIR}/gpu/[^.]*.cpp)
 file(MAKE_DIRECTORY ${LAMMPS_LIB_BINARY_DIR}/gpu)
 
@@ -151,7 +164,12 @@ if(GPU_API STREQUAL "CUDA")
   add_library(gpu STATIC ${GPU_LIB_SOURCES} ${GPU_LIB_CUDPP_SOURCES} ${GPU_OBJS})
   target_link_libraries(gpu PRIVATE ${CUDA_LIBRARIES} ${CUDA_CUDA_LIBRARY})
   target_include_directories(gpu PRIVATE ${LAMMPS_LIB_BINARY_DIR}/gpu ${CUDA_INCLUDE_DIRS})
-  target_compile_definitions(gpu PRIVATE -DUSE_CUDA -D_${GPU_PREC_SETTING} -DMPI_GERYON -DUCL_NO_EXIT ${GPU_CUDA_MPS_FLAGS})
+  target_compile_definitions(gpu PRIVATE -DUSE_CUDA -D_${GPU_PREC_SETTING} ${GPU_CUDA_MPS_FLAGS})
+  if(GPU_DEBUG)
+    target_compile_definitions(gpu PRIVATE -DUCL_DEBUG -DGERYON_KERNEL_DUMP)
+  else()
+    target_compile_definitions(gpu PRIVATE -DMPI_GERYON -DUCL_NO_EXIT)
+  endif()
   if(CUDPP_OPT)
     target_include_directories(gpu PRIVATE ${LAMMPS_LIB_SOURCE_DIR}/gpu/cudpp_mini)
     target_compile_definitions(gpu PRIVATE -DUSE_CUDPP)
@@ -192,6 +210,7 @@ elseif(GPU_API STREQUAL "OPENCL")
     ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_tersoff.cu
     ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_tersoff_zbl.cu
     ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_tersoff_mod.cu
+    ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_hippo.cu
   )
 
   foreach(GPU_KERNEL ${GPU_LIB_CU})
@@ -208,6 +227,7 @@ elseif(GPU_API STREQUAL "OPENCL")
   GenerateOpenCLHeader(tersoff ${CMAKE_CURRENT_BINARY_DIR}/gpu/tersoff_cl.h ${OCL_COMMON_HEADERS} ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_tersoff_extra.h ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_tersoff.cu)
   GenerateOpenCLHeader(tersoff_zbl ${CMAKE_CURRENT_BINARY_DIR}/gpu/tersoff_zbl_cl.h ${OCL_COMMON_HEADERS} ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_tersoff_zbl_extra.h ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_tersoff_zbl.cu)
   GenerateOpenCLHeader(tersoff_mod ${CMAKE_CURRENT_BINARY_DIR}/gpu/tersoff_mod_cl.h ${OCL_COMMON_HEADERS} ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_tersoff_mod_extra.h ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_tersoff_mod.cu)
+  GenerateOpenCLHeader(hippo ${CMAKE_CURRENT_BINARY_DIR}/gpu/hippo_cl.h ${OCL_COMMON_HEADERS} ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_hippo_extra.h ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_hippo.cu)
 
   list(APPEND GPU_LIB_SOURCES
     ${CMAKE_CURRENT_BINARY_DIR}/gpu/gayberne_cl.h
@@ -217,14 +237,18 @@ elseif(GPU_API STREQUAL "OPENCL")
     ${CMAKE_CURRENT_BINARY_DIR}/gpu/tersoff_cl.h
     ${CMAKE_CURRENT_BINARY_DIR}/gpu/tersoff_zbl_cl.h
     ${CMAKE_CURRENT_BINARY_DIR}/gpu/tersoff_mod_cl.h
+    ${CMAKE_CURRENT_BINARY_DIR}/gpu/hippo_cl.h
   )
 
   add_library(gpu STATIC ${GPU_LIB_SOURCES})
   target_link_libraries(gpu PRIVATE OpenCL::OpenCL)
   target_include_directories(gpu PRIVATE ${CMAKE_CURRENT_BINARY_DIR}/gpu)
-  target_compile_definitions(gpu PRIVATE -D_${GPU_PREC_SETTING} -DMPI_GERYON -DGERYON_NUMA_FISSION -DUCL_NO_EXIT)
+  target_compile_definitions(gpu PRIVATE -DUSE_OPENCL -D_${GPU_PREC_SETTING})
-  target_compile_definitions(gpu PRIVATE -DUSE_OPENCL)
+  if(GPU_DEBUG)
-
+    target_compile_definitions(gpu PRIVATE -DUCL_DEBUG -DGERYON_KERNEL_DUMP)
+  else()
+    target_compile_definitions(gpu PRIVATE -DMPI_GERYON -DGERYON_NUMA_FISSION -DUCL_NO_EXIT)
+  endif()
   target_link_libraries(lammps PRIVATE gpu)
 
   add_executable(ocl_get_devices ${LAMMPS_LIB_SOURCE_DIR}/gpu/geryon/ucl_get_devices.cpp)
@@ -374,8 +398,12 @@ elseif(GPU_API STREQUAL "HIP")
 
   add_library(gpu STATIC ${GPU_LIB_SOURCES})
   target_include_directories(gpu PRIVATE ${LAMMPS_LIB_BINARY_DIR}/gpu)
-  target_compile_definitions(gpu PRIVATE -D_${GPU_PREC_SETTING} -DMPI_GERYON -DUCL_NO_EXIT)
+  target_compile_definitions(gpu PRIVATE -DUSE_HIP -D_${GPU_PREC_SETTING})
-  target_compile_definitions(gpu PRIVATE -DUSE_HIP)
+  if(GPU_DEBUG)
+    target_compile_definitions(gpu PRIVATE -DUCL_DEBUG -DGERYON_KERNEL_DUMP)
+  else()
+    target_compile_definitions(gpu PRIVATE -DMPI_GERYON -DUCL_NO_EXIT)
+  endif()
   target_link_libraries(gpu PRIVATE hip::host)
 
   if(HIP_USE_DEVICE_SORT)
@@ -400,15 +428,17 @@ elseif(GPU_API STREQUAL "HIP")
 
       if(DOWNLOAD_CUB)
         message(STATUS "CUB download requested")
-        set(CUB_URL "https://github.com/NVlabs/cub/archive/1.12.0.tar.gz" CACHE STRING "URL for CUB tarball")
+        # TODO: test update to current version 1.17.2
+        set(CUB_URL "https://github.com/nvidia/cub/archive/1.12.0.tar.gz" CACHE STRING "URL for CUB tarball")
         set(CUB_MD5 "1cf595beacafff104700921bac8519f3" CACHE STRING "MD5 checksum of CUB tarball")
         mark_as_advanced(CUB_URL)
         mark_as_advanced(CUB_MD5)
+        GetFallbackURL(CUB_URL CUB_FALLBACK)
 
         include(ExternalProject)
 
         ExternalProject_Add(CUB
-          URL     ${CUB_URL}
+          URL     ${CUB_URL} ${CUB_FALLBACK}
           URL_MD5 ${CUB_MD5}
           PREFIX "${CMAKE_CURRENT_BINARY_DIR}"
           CONFIGURE_COMMAND ""

cmake/Modules/Packages/KOKKOS.cmake

@@ -49,12 +49,14 @@ if(DOWNLOAD_KOKKOS)
   list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_CXX_EXTENSIONS=${CMAKE_CXX_EXTENSIONS}")
   list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}")
   include(ExternalProject)
-  set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/3.7.00.tar.gz" CACHE STRING "URL for KOKKOS tarball")
+  set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/3.7.01.tar.gz" CACHE STRING "URL for KOKKOS tarball")
-  set(KOKKOS_MD5 "84991eca9f066383abe119a5bc7a11c4" CACHE STRING "MD5 checksum of KOKKOS tarball")
+  set(KOKKOS_MD5 "f140e02b826223b1045207d9bc10d404" CACHE STRING "MD5 checksum of KOKKOS tarball")
   mark_as_advanced(KOKKOS_URL)
   mark_as_advanced(KOKKOS_MD5)
+  GetFallbackURL(KOKKOS_URL KOKKOS_FALLBACK)
+
   ExternalProject_Add(kokkos_build
-    URL     ${KOKKOS_URL}
+    URL     ${KOKKOS_URL} ${KOKKOS_FALLBACK}
     URL_MD5 ${KOKKOS_MD5}
     CMAKE_ARGS ${KOKKOS_LIB_BUILD_ARGS}
     BUILD_BYPRODUCTS <INSTALL_DIR>/lib/libkokkoscore.a <INSTALL_DIR>/lib/libkokkoscontainers.a
@@ -74,7 +76,7 @@ if(DOWNLOAD_KOKKOS)
   add_dependencies(LAMMPS::KOKKOSCORE kokkos_build)
   add_dependencies(LAMMPS::KOKKOSCONTAINERS kokkos_build)
 elseif(EXTERNAL_KOKKOS)
-  find_package(Kokkos 3.7.00 REQUIRED CONFIG)
+  find_package(Kokkos 3.7.01 REQUIRED CONFIG)
   target_link_libraries(lammps PRIVATE Kokkos::kokkos)
   target_link_libraries(lmp PRIVATE Kokkos::kokkos)
 else()
@@ -144,6 +146,7 @@ if(PKG_ML-IAP)
                                  ${KOKKOS_PKG_SOURCES_DIR}/mliap_descriptor_so3_kokkos.cpp
                                  ${KOKKOS_PKG_SOURCES_DIR}/mliap_model_linear_kokkos.cpp
                                  ${KOKKOS_PKG_SOURCES_DIR}/mliap_model_python_kokkos.cpp
+                                 ${KOKKOS_PKG_SOURCES_DIR}/mliap_unified_kokkos.cpp
                                  ${KOKKOS_PKG_SOURCES_DIR}/mliap_so3_kokkos.cpp)
 
   # Add KOKKOS version of ML-IAP Python coupling if non-KOKKOS version is included

cmake/Modules/Packages/LATTE.cmake

@@ -19,6 +19,7 @@ if(DOWNLOAD_LATTE)
   set(LATTE_MD5 "820e73a457ced178c08c71389a385de7" CACHE STRING "MD5 checksum of LATTE tarball")
   mark_as_advanced(LATTE_URL)
   mark_as_advanced(LATTE_MD5)
+  GetFallbackURL(LATTE_URL LATTE_FALLBACK)
 
   # CMake cannot pass BLAS or LAPACK library variable to external project if they are a list
   list(LENGTH BLAS_LIBRARIES} NUM_BLAS)
@@ -30,7 +31,7 @@ if(DOWNLOAD_LATTE)
 
   include(ExternalProject)
   ExternalProject_Add(latte_build
-    URL     ${LATTE_URL}
+    URL     ${LATTE_URL} ${LATTE_FALLBACK}
     URL_MD5 ${LATTE_MD5}
     SOURCE_SUBDIR cmake
     CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR> ${CMAKE_REQUEST_PIC} -DCMAKE_INSTALL_LIBDIR=lib

cmake/Modules/Packages/MDI.cmake

@@ -12,6 +12,7 @@ if(DOWNLOAD_MDI)
   set(MDI_MD5 "7a222353ae8e03961d5365e6cd48baee" CACHE STRING "MD5 checksum for MDI tarball")
   mark_as_advanced(MDI_URL)
   mark_as_advanced(MDI_MD5)
+  GetFallbackURL(MDI_URL MDI_FALLBACK)
   enable_language(C)
 
   # only ON/OFF are allowed for "mpi" flag when building MDI library
@@ -63,7 +64,7 @@ if(DOWNLOAD_MDI)
   # support cross-compilation and ninja-build
   include(ExternalProject)
   ExternalProject_Add(mdi_build
-    URL     ${MDI_URL}
+    URL     ${MDI_URL} ${MDI_FALLBACK}
     URL_MD5 ${MDI_MD5}
     PREFIX ${CMAKE_CURRENT_BINARY_DIR}/mdi_build_ext
     CMAKE_ARGS

cmake/Modules/Packages/MESONT.cmake

@@ -1,73 +0,0 @@
-
-
-set(MESONT_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/MESONT)
-include(StyleHeaderUtils)
-include(CheckLanguage)
-
-# always include C++-only sources
-file(GLOB MESONT_SOURCES ${CONFIGURE_DEPENDS} ${MESONT_SOURCES_DIR}/[^.]*mesocnt*.cpp)
-file(GLOB MESONT_HEADERS ${CONFIGURE_DEPENDS} ${MESONT_SOURCES_DIR}/[^.]*mesocnt*.h)
-# remove derived class when base class is not available
-if(NOT PKG_MOLECULE)
-  list(REMOVE_ITEM MESONT_SOURCES ${MESONT_SOURCES_DIR}/bond_mesocnt.cpp)
-  list(REMOVE_ITEM MESONT_HEADERS ${MESONT_SOURCES_DIR}/bond_mesocnt.h)
-endif()
-
-# include styles dependent on Fortran library only when Fortran is available.
-check_language(Fortran)
-if(CMAKE_Fortran_COMPILER)
-  enable_language(Fortran)
-  file(GLOB MESONT_LIB_SOURCES ${CONFIGURE_DEPENDS} ${LAMMPS_LIB_SOURCE_DIR}/mesont/[^.]*.f90)
-  add_library(mesont STATIC ${MESONT_LIB_SOURCES})
-  set_target_properties(mesont PROPERTIES OUTPUT_NAME lammps_mesont${LAMMPS_MACHINE})
-  target_link_libraries(lammps PRIVATE mesont)
-
-  list(APPEND MESONT_SOURCES ${MESONT_SOURCES_DIR}/pair_mesont_tpm.cpp)
-  list(APPEND MESONT_SOURCES ${MESONT_SOURCES_DIR}/atom_vec_mesont.cpp)
-  list(APPEND MESONT_SOURCES ${MESONT_SOURCES_DIR}/compute_mesont.cpp)
-  list(APPEND MESONT_HEADERS ${MESONT_SOURCES_DIR}/pair_mesont_tpm.h)
-  list(APPEND MESONT_HEADERS ${MESONT_SOURCES_DIR}/atom_vec_mesont.h)
-  list(APPEND MESONT_HEADERS ${MESONT_SOURCES_DIR}/compute_mesont.h)
-endif()
-
-# check for package files in src directory due to old make system
-DetectBuildSystemConflict(${LAMMPS_SOURCE_DIR} ${MESONT_SOURCES} ${MESONT_HEADERS})
-
-# manually register style headers
-get_property(alist GLOBAL PROPERTY ANGLE)
-get_property(blist GLOBAL PROPERTY BOND)
-get_property(clist GLOBAL PROPERTY COMPUTE)
-get_property(plist GLOBAL PROPERTY PAIR)
-get_property(vlist GLOBAL PROPERTY ATOM_VEC)
-foreach(fname ${MESONT_HEADERS})
-  file(STRINGS ${fname} is_style LIMIT_COUNT 1 REGEX ANGLE_CLASS)
-  if(is_style)
-    list(APPEND alist ${fname})
-  endif()
-  file(STRINGS ${fname} is_style LIMIT_COUNT 1 REGEX BOND_CLASS)
-  if(is_style)
-    list(APPEND blist ${fname})
-  endif()
-  file(STRINGS ${fname} is_style LIMIT_COUNT 1 REGEX COMPUTE_CLASS)
-  if(is_style)
-    list(APPEND clist ${fname})
-  endif()
-  file(STRINGS ${fname} is_style LIMIT_COUNT 1 REGEX PAIR_CLASS)
-  if(is_style)
-    list(APPEND plist ${fname})
-  endif()
-  file(STRINGS ${fname} is_style LIMIT_COUNT 1 REGEX ATOM_CLASS)
-  if(is_style)
-    list(APPEND vlist ${fname})
-  endif()
-endforeach()
-set_property(GLOBAL PROPERTY ANGLE "${alist}")
-set_property(GLOBAL PROPERTY BOND "${blist}")
-set_property(GLOBAL PROPERTY COMPUTE "${clist}")
-set_property(GLOBAL PROPERTY PAIR "${plist}")
-set_property(GLOBAL PROPERTY ATOM_VEC "${vlist}")
-
-target_sources(lammps PRIVATE ${MESONT_SOURCES})
-target_include_directories(lammps PRIVATE ${MESONT_SOURCES_DIR})
-
-RegisterPackages(${MESONT_SOURCES_DIR})

cmake/Modules/Packages/ML-HDNNP.cmake

@@ -6,10 +6,11 @@ else()
 endif()
 option(DOWNLOAD_N2P2 "Download n2p2 library instead of using an already installed one)" ${DOWNLOAD_N2P2_DEFAULT})
 if(DOWNLOAD_N2P2)
-  set(N2P2_URL "https://github.com/CompPhysVienna/n2p2/archive/v2.1.4.tar.gz" CACHE STRING "URL for n2p2 tarball")
+  set(N2P2_URL "https://github.com/CompPhysVienna/n2p2/archive/v2.2.0.tar.gz" CACHE STRING "URL for n2p2 tarball")
-  set(N2P2_MD5 "9595b066636cd6b90b0fef93398297a5" CACHE STRING "MD5 checksum of N2P2 tarball")
+  set(N2P2_MD5 "a2d9ab7f676b3a74a324fc1eda0a911d" CACHE STRING "MD5 checksum of N2P2 tarball")
   mark_as_advanced(N2P2_URL)
   mark_as_advanced(N2P2_MD5)
+  GetFallbackURL(N2P2_URL N2P2_FALLBACK)
 
   # adjust settings from detected compiler to compiler platform in n2p2 library
   # set compiler specific flag to turn on C++11 syntax (required on macOS and CentOS 7)
@@ -72,7 +73,7 @@ if(DOWNLOAD_N2P2)
   # download compile n2p2 library. much patch MPI calls in LAMMPS interface to accommodate MPI-2 (e.g. for cross-compiling)
   include(ExternalProject)
   ExternalProject_Add(n2p2_build
-    URL     ${N2P2_URL}
+    URL     ${N2P2_URL} ${N2P2_FALLBACK}
     URL_MD5 ${N2P2_MD5}
     UPDATE_COMMAND ""
     CONFIGURE_COMMAND ""

cmake/Modules/Packages/ML-PACE.cmake

@@ -1,11 +1,25 @@
-set(PACELIB_URL "https://github.com/ICAMS/lammps-user-pace/archive/refs/tags/v.2023.01.3.tar.gz" CACHE STRING "URL for PACE evaluator library sources")
+set(PACELIB_URL "https://github.com/ICAMS/lammps-user-pace/archive/refs/tags/v.2023.01.3.fix.tar.gz" CACHE STRING "URL for PACE evaluator library sources")
 
-set(PACELIB_MD5 "f418d32b60e531063ac4285bf702b468" CACHE STRING "MD5 checksum of PACE evaluator library tarball")
+set(PACELIB_MD5 "4f0b3b5b14456fe9a73b447de3765caa" CACHE STRING "MD5 checksum of PACE evaluator library tarball")
 mark_as_advanced(PACELIB_URL)
 mark_as_advanced(PACELIB_MD5)
+GetFallbackURL(PACELIB_URL PACELIB_FALLBACK)
 
 # download library sources to build folder
-file(DOWNLOAD ${PACELIB_URL} ${CMAKE_BINARY_DIR}/libpace.tar.gz EXPECTED_HASH MD5=${PACELIB_MD5}) #SHOW_PROGRESS
+if(EXISTS ${CMAKE_BINARY_DIR}/libpace.tar.gz)
+  file(MD5 ${CMAKE_BINARY_DIR}/libpace.tar.gz DL_MD5)
+endif()
+if(NOT "${DL_MD5}" STREQUAL "${PACELIB_MD5}")
+  message(STATUS "Downloading ${PACELIB_URL}")
+  file(DOWNLOAD ${PACELIB_URL} ${CMAKE_BINARY_DIR}/libpace.tar.gz STATUS DL_STATUS SHOW_PROGRESS)
+  file(MD5 ${CMAKE_BINARY_DIR}/libpace.tar.gz DL_MD5)
+  if((NOT DL_STATUS EQUAL 0) OR (NOT "${DL_MD5}" STREQUAL "${PACELIB_MD5}"))
+    message(WARNING "Download from primary URL ${PACELIB_URL} failed\nTrying fallback URL ${PACELIB_FALLBACK}")
+    file(DOWNLOAD ${PACELIB_FALLBACK} ${CMAKE_BINARY_DIR}/libpace.tar.gz EXPECTED_HASH MD5=${PACELIB_MD5} SHOW_PROGRESS)
+  else()
+    message(STATUS "Using already downloaded archive ${CMAKE_BINARY_DIR}/libpace.tar.gz")
+  endif()
+endif()
 
 # uncompress downloaded sources
 execute_process(

cmake/Modules/Packages/ML-QUIP.cmake

@@ -16,6 +16,7 @@ if(DOWNLOAD_QUIP)
     set(temp "${temp}DEFINES += -DGETARG_F2003 -DFORTRAN_UNDERSCORE\n")
     set(temp "${temp}F95FLAGS += -fpp -free -fPIC\n")
     set(temp "${temp}F77FLAGS += -fpp -fixed -fPIC\n")
+    set(temp "${temp}F95_PRE_FILENAME_FLAG = -Tf\n")
   elseif(CMAKE_Fortran_COMPILER_ID STREQUAL GNU)
     set(temp "${temp}FPP=${CMAKE_Fortran_COMPILER} -E -x f95-cpp-input\nOPTIM=${CMAKE_Fortran_FLAGS_${BTYPE}}\n")
     set(temp "${temp}DEFINES += -DGETARG_F2003 -DGETENV_F2003 -DGFORTRAN -DFORTRAN_UNDERSCORE\n")

cmake/Modules/Packages/PLUMED.cmake

@@ -59,10 +59,11 @@ if(DOWNLOAD_PLUMED)
 
   mark_as_advanced(PLUMED_URL)
   mark_as_advanced(PLUMED_MD5)
+  GetFallbackURL(PLUMED_URL PLUMED_FALLBACK)
 
   include(ExternalProject)
   ExternalProject_Add(plumed_build
-    URL     ${PLUMED_URL}
+    URL     ${PLUMED_URL} ${PLUMED_FALLBACK}
     URL_MD5 ${PLUMED_MD5}
     BUILD_IN_SOURCE 1
     CONFIGURE_COMMAND <SOURCE_DIR>/configure --prefix=<INSTALL_DIR>

cmake/Modules/Packages/SCAFACOS.cmake

@@ -18,6 +18,8 @@ if(DOWNLOAD_SCAFACOS)
   set(SCAFACOS_MD5 "bd46d74e3296bd8a444d731bb10c1738" CACHE STRING "MD5 checksum of SCAFACOS tarball")
   mark_as_advanced(SCAFACOS_URL)
   mark_as_advanced(SCAFACOS_MD5)
+  GetFallbackURL(SCAFACOS_URL SCAFACOS_FALLBACK)
+
 
   # version 1.0.1 needs a patch to compile and linke cleanly with GCC 10 and later.
   file(DOWNLOAD ${LAMMPS_THIRDPARTY_URL}/scafacos-1.0.1-fix.diff ${CMAKE_CURRENT_BINARY_DIR}/scafacos-1.0.1.fix.diff
@@ -30,7 +32,7 @@ if(DOWNLOAD_SCAFACOS)
 
   include(ExternalProject)
   ExternalProject_Add(scafacos_build
-    URL     ${SCAFACOS_URL}
+    URL     ${SCAFACOS_URL} ${SCAFACOS_FALLBACK}
     URL_MD5 ${SCAFACOS_MD5}
     PATCH_COMMAND patch -p1 < ${CMAKE_CURRENT_BINARY_DIR}/scafacos-1.0.1.fix.diff
     CONFIGURE_COMMAND <SOURCE_DIR>/configure --prefix=<INSTALL_DIR> --disable-doc

cmake/Modules/Tools.cmake

@@ -50,12 +50,16 @@ if(BUILD_LAMMPS_SHELL)
 
   add_executable(lammps-shell ${LAMMPS_TOOLS_DIR}/lammps-shell/lammps-shell.cpp ${ICON_RC_FILE})
   target_include_directories(lammps-shell PRIVATE ${LAMMPS_TOOLS_DIR}/lammps-shell)
+  target_link_libraries(lammps-shell PRIVATE lammps PkgConfig::READLINE)
 
   # workaround for broken readline pkg-config file on FreeBSD
   if(CMAKE_SYSTEM_NAME STREQUAL "FreeBSD")
     target_include_directories(lammps-shell PRIVATE /usr/local/include)
   endif()
-  target_link_libraries(lammps-shell PRIVATE lammps PkgConfig::READLINE)
+  if(CMAKE_SYSTEM_NAME STREQUAL "LinuxMUSL")
+    pkg_check_modules(TERMCAP IMPORTED_TARGET REQUIRED termcap)
+    target_link_libraries(lammps-shell PRIVATE lammps PkgConfig::TERMCAP)
+  endif()
   install(TARGETS lammps-shell EXPORT LAMMPS_Targets DESTINATION ${CMAKE_INSTALL_BINDIR})
   install(DIRECTORY ${LAMMPS_TOOLS_DIR}/lammps-shell/icons DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/)
   install(FILES ${LAMMPS_TOOLS_DIR}/lammps-shell/lammps-shell.desktop DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/applications/)

cmake/presets/most.cmake

@@ -40,6 +40,7 @@ set(ALL_PACKAGES
   MANYBODY
   MC
   MEAM
+  MESONT
   MISC
   ML-IAP
   ML-POD

cmake/presets/nolib.cmake

@@ -16,7 +16,6 @@ set(PACKAGES_WITH_LIB
   LEPTON
   MACHDYN
   MDI
-  MESONT
   ML-HDNNP
   ML-PACE
   ML-QUIP

cmake/presets/windows.cmake

@@ -36,6 +36,7 @@ set(WIN_PACKAGES
   MANYBODY
   MC
   MEAM
+  MESONT
   MISC
   ML-IAP
   ML-POD

doc/Makefile

@@ -86,13 +86,13 @@ html: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJAX)
 	@if [ "$(HAS_BASH)" == "NO" ] ; then echo "bash was not found at $(OSHELL)! Please use: $(MAKE) SHELL=/path/to/bash" 1>&2; exit 1; fi
 	@$(MAKE) $(MFLAGS) -C graphviz all
 	@(\
-		. $(VENV)/bin/activate ; env PYTHONWARNINGS= \
+		. $(VENV)/bin/activate ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
 		sphinx-build -E $(SPHINXEXTRA) -b html -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) html ;\
-		touch $(RSTDIR)/Fortran.rst ;\
+		touch $(RSTDIR)/Fortran.rst ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
 		sphinx-build $(SPHINXEXTRA) -b html -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) html ;\
 		ln -sf Manual.html html/index.html;\
 		rm -f $(BUILDDIR)/doxygen/xml/run.stamp;\
-		echo "############################################" ;\
+		echo "############################################" ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
 		rst_anchor_check src/*.rst ;\
 		python $(BUILDDIR)/utils/check-packages.py -s ../src -d src ;\
 		env LC_ALL=C grep -n '[^ -~]' $(RSTDIR)/*.rst ;\
@@ -114,9 +114,9 @@ fasthtml: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJAX)
 	@$(MAKE) $(MFLAGS) -C graphviz all
 	@mkdir -p fasthtml
 	@(\
-		. $(VENV)/bin/activate ; env PYTHONWARNINGS= \
+		. $(VENV)/bin/activate ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
 		sphinx-build $(SPHINXEXTRA) -b html -c $(SPHINXCONFIG) -d $(BUILDDIR)/fasthtml/doctrees $(RSTDIR) fasthtml ;\
-		touch $(RSTDIR)/Fortran.rst ;\
+		touch $(RSTDIR)/Fortran.rst ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
 		sphinx-build $(SPHINXEXTRA) -b html -c $(SPHINXCONFIG) -d $(BUILDDIR)/fasthtml/doctrees $(RSTDIR) fasthtml ;\
 		deactivate ;\
 	)
@@ -131,8 +131,8 @@ fasthtml: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJAX)
 spelling: xmlgen $(SPHINXCONFIG)/conf.py $(VENV) $(SPHINXCONFIG)/false_positives.txt
 	@if [ "$(HAS_BASH)" == "NO" ] ; then echo "bash was not found at $(OSHELL)! Please use: $(MAKE) SHELL=/path/to/bash" 1>&2; exit 1; fi
 	@(\
-		. $(VENV)/bin/activate ; env PYTHONWARNINGS= \
+		. $(VENV)/bin/activate ; \
-		cp $(SPHINXCONFIG)/false_positives.txt $(RSTDIR)/ ; env PYTHONWARNINGS= \
+		cp $(SPHINXCONFIG)/false_positives.txt $(RSTDIR)/;  env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
 		sphinx-build -b spelling -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) spelling ;\
 		rm -f $(BUILDDIR)/doxygen/xml/run.stamp;\
 		deactivate ;\
@@ -146,9 +146,9 @@ epub: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK)
 	@rm -f LAMMPS.epub
 	@cp src/JPG/*.* epub/JPG
 	@(\
-		. $(VENV)/bin/activate ;\
+		. $(VENV)/bin/activate ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
 		sphinx-build -E $(SPHINXEXTRA) -b epub -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) epub ;\
-		touch $(RSTDIR)/Fortran.rst ;\
+		touch $(RSTDIR)/Fortran.rst ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
 		sphinx-build $(SPHINXEXTRA) -b epub -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) epub ;\
 		rm -f $(BUILDDIR)/doxygen/xml/run.stamp;\
 		deactivate ;\
@@ -167,12 +167,12 @@ pdf: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK)
 	@$(MAKE) $(MFLAGS) -C graphviz all
 	@if [ "$(HAS_PDFLATEX)" == "NO" ] ; then echo "PDFLaTeX or latexmk were not found! Please check README for further instructions" 1>&2; exit 1; fi
 	@(\
-		. $(VENV)/bin/activate ; env PYTHONWARNINGS= \
+		. $(VENV)/bin/activate ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
 		sphinx-build -E $(SPHINXEXTRA) -b latex -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) latex ;\
-		touch $(RSTDIR)/Fortran.rst ;\
+		touch $(RSTDIR)/Fortran.rst ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
 		sphinx-build  $(SPHINXEXTRA) -b latex -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) latex ;\
 		rm -f $(BUILDDIR)/doxygen/xml/run.stamp;\
-		echo "############################################" ;\
+		echo "############################################" ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
 		rst_anchor_check src/*.rst ;\
 		python utils/check-packages.py -s ../src -d src ;\
 		env LC_ALL=C grep -n '[^ -~]' $(RSTDIR)/*.rst ;\
@@ -200,21 +200,21 @@ pdf: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK)
 
 anchor_check : $(ANCHORCHECK)
 	@(\
-		. $(VENV)/bin/activate ;\
+		. $(VENV)/bin/activate ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
 		rst_anchor_check src/*.rst ;\
 		deactivate ;\
 	)
 
 style_check : $(VENV)
 	@(\
-		. $(VENV)/bin/activate ;\
+		. $(VENV)/bin/activate ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
 		python utils/check-styles.py -s ../src -d src ;\
 		deactivate ;\
 	)
 
 package_check : $(VENV)
 	@(\
-		. $(VENV)/bin/activate ;\
+		. $(VENV)/bin/activate ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \\
 		python utils/check-packages.py -s ../src -d src ;\
 		deactivate ;\
 	)
@@ -252,7 +252,7 @@ $(MATHJAX):
 
 $(ANCHORCHECK): $(VENV)
 	@( \
-		. $(VENV)/bin/activate; \
+		. $(VENV)/bin/activate; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
 		pip $(PIP_OPTIONS) install -e utils/converters;\
 		deactivate;\
 	)

doc/src/2001/basics.html

@@ -63,7 +63,7 @@ In the src directory, there is one top-level Makefile and several
 low-level machine-specific files named Makefile.xxx where xxx = the
 machine name. If a low-level Makefile exists for your platform, you do
 not need to edit the top-level Makefile.  However you should check the
-system-specific section of the low-level Makefile to insure the
+system-specific section of the low-level Makefile to ensure the
 various paths are correct for your environment. If a low-level
 Makefile does not exist for your platform, you will need to add a
 suitable target to the top-level Makefile. You will also need to

doc/src/2001/input_commands.html

@@ -1206,7 +1206,7 @@ this command is not typically needed if the "nonbond style" and "
 an exception to this is if a short cutoff is used initially,
   but a longer cutoff will be used for a subsequent run (in the same
   input script), in this case the "maximum cutoff" command should be
-  used to insure enough memory is allocated for the later run
+  used to ensure enough memory is allocated for the later run
 note that a restart file contains nonbond cutoffs (so it is not necessary
   to use a "nonbond style" command before "read restart"), but LAMMPS
   still needs to know what the maximum cutoff will be before the

doc/src/Build.rst

@@ -6,9 +6,9 @@ either traditional makefiles for use with GNU make (which may require
 manual editing), or using a build environment generated by CMake (Unix
 Makefiles, Ninja, Xcode, Visual Studio, KDevelop, CodeBlocks and more).
 
-As an alternative you can download a package with pre-built executables
+As an alternative, you can download a package with pre-built executables
-or automated build trees as described on the :doc:`Install <Install>`
+or automated build trees, as described in the :doc:`Install <Install>`
-page.
+section of the manual.
 
 .. toctree::
    :maxdepth: 1

doc/src/Build_basics.rst

@@ -44,7 +44,7 @@ standard. A more detailed discussion of that is below.
 
       The executable created by CMake (after running make) is named
       ``lmp`` unless the ``LAMMPS_MACHINE`` option is set.  When setting
-      ``LAMMPS_MACHINE=name`` the executable will be called
+      ``LAMMPS_MACHINE=name``, the executable will be called
       ``lmp_name``.  Using ``BUILD_MPI=no`` will enforce building a
       serial executable using the MPI STUBS library.
 
@@ -60,7 +60,7 @@ standard. A more detailed discussion of that is below.
 
       Any ``make machine`` command will look up the make settings from a
       file ``Makefile.machine`` in the folder ``src/MAKE`` or one of its
-      sub-directories ``MINE``, ``MACHINES``, or ``OPTIONS``, create a
+      subdirectories ``MINE``, ``MACHINES``, or ``OPTIONS``, create a
       folder ``Obj_machine`` with all objects and generated files and an
       executable called ``lmp_machine``\ .  The standard parallel build
       with ``make mpi`` assumes a standard MPI installation with MPI
@@ -107,9 +107,9 @@ MPI and OpenMP support in LAMMPS
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 If you are installing MPI yourself to build a parallel LAMMPS
-executable, we recommend either MPICH or OpenMPI which are regularly
+executable, we recommend either MPICH or OpenMPI, which are regularly
 used and tested with LAMMPS by the LAMMPS developers.  MPICH can be
-downloaded from the `MPICH home page <https://www.mpich.org>`_ and
+downloaded from the `MPICH home page <https://www.mpich.org>`_, and
 OpenMPI can be downloaded correspondingly from the `OpenMPI home page
 <https://www.open-mpi.org>`_.  Other MPI packages should also work.  No
 specific vendor provided and standard compliant MPI library is currently
@@ -130,12 +130,12 @@ package can be compiled to include OpenMP threading.
 
 In addition, there are a few commands in LAMMPS that have native OpenMP
 support included as well.  These are commands in the ``MPIIO``,
-``ML-SNAP``, ``DIFFRACTION``, and ``DPD-REACT`` packages.  In addition
+``ML-SNAP``, ``DIFFRACTION``, and ``DPD-REACT`` packages.  Furthermore,
 some packages support OpenMP threading indirectly through the libraries
-they interface to: e.g. ``LATTE``, ``KSPACE``, and ``COLVARS``.
+they interface to: e.g. ``LATTE``, ``KSPACE``, and ``COLVARS``.  See the
-See the :doc:`Packages details <Packages_details>` page for more
+:doc:`Packages details <Packages_details>` page for more info on these
-info on these packages and the pages for their respective commands
+packages, and the pages for their respective commands for OpenMP
-for OpenMP threading info.
+threading info.
 
 For CMake, if you use ``BUILD_OMP=yes``, you can use these packages
 and turn on their native OpenMP support and turn on their native OpenMP
@@ -144,9 +144,9 @@ variable before you launch LAMMPS.
 
 For building via conventional make, the ``CCFLAGS`` and ``LINKFLAGS``
 variables in Makefile.machine need to include the compiler flag that
-enables OpenMP. For GNU compilers it is ``-fopenmp``\ .  For (recent) Intel
+enables OpenMP. For the GNU compilers or Clang, it is ``-fopenmp``\ .
-compilers it is ``-qopenmp``\ .  If you are using a different compiler,
+For (recent) Intel compilers, it is ``-qopenmp``\ .  If you are using a
-please refer to its documentation.
+different compiler, please refer to its documentation.
 
 .. _default-none-issues:
 
@@ -174,15 +174,16 @@ Choice of compiler and compile/link options
 The choice of compiler and compiler flags can be important for maximum
 performance.  Vendor provided compilers for a specific hardware can
 produce faster code than open-source compilers like the GNU compilers.
-On the most common x86 hardware most popular C++ compilers are quite
+On the most common x86 hardware, the most popular C++ compilers are
-similar in performance of C/C++ code at high optimization levels.  When
+quite similar in their ability to optimize regular C/C++ source code at
-using the ``INTEL`` package, there is a distinct advantage in using
+high optimization levels.  When using the ``INTEL`` package, there is a
-the `Intel C++ compiler <intel_>`_ due to much improved vectorization
+distinct advantage in using the `Intel C++ compiler <intel_>`_ due to
-through SSE and AVX instructions on compatible hardware as the source
+much improved vectorization through SSE and AVX instructions on
-code includes changes and Intel compiler specific directives to enable
+compatible hardware.  The source code in that package conditionally
-high degrees of vectorization.  This may change over time as equivalent
+includes compiler specific directives to enable these high degrees of
-vectorization directives are included into OpenMP standard revisions and
+vectorization.  This may change over time as equivalent vectorization
-other compilers adopt them.
+directives are included into the OpenMP standard and other compilers
+adopt them.
 
 .. _intel: https://software.intel.com/en-us/intel-compilers
 
@@ -196,7 +197,7 @@ LAMMPS.
    .. tab:: CMake build
 
       By default CMake will use the compiler it finds according to
-      internal preferences and it will add optimization flags
+      internal preferences, and it will add optimization flags
       appropriate to that compiler and any :doc:`accelerator packages
       <Speed_packages>` you have included in the build.  CMake will
       check if the detected or selected compiler is compatible with the
@@ -250,9 +251,9 @@ LAMMPS.
       and `-C ../cmake/presets/pgi.cmake`
       will switch the compiler to the PGI compilers.
 
-      In addition you can set ``CMAKE_TUNE_FLAGS`` to specifically add
+      Furthermore, you can set ``CMAKE_TUNE_FLAGS`` to specifically add
-      compiler flags to tune for optimal performance on given hosts. By
+      compiler flags to tune for optimal performance on given hosts.
-      default this variable is empty.
+      This variable is empty by default.
 
       .. note::
 
@@ -368,10 +369,10 @@ running LAMMPS from Python via its library interface.
                                       # no default value
 
       The compilation will always produce a LAMMPS library and an
-      executable linked to it.  By default this will be a static library
+      executable linked to it.  By default, this will be a static
-      named ``liblammps.a`` and an executable named ``lmp`` Setting
+      library named ``liblammps.a`` and an executable named ``lmp``
-      ``BUILD_SHARED_LIBS=yes`` will instead produce a shared library
+      Setting ``BUILD_SHARED_LIBS=yes`` will instead produce a shared
-      called ``liblammps.so`` (or ``liblammps.dylib`` or
+      library called ``liblammps.so`` (or ``liblammps.dylib`` or
       ``liblammps.dll`` depending on the platform) If
       ``LAMMPS_MACHINE=name`` is set in addition, the name of the
       generated libraries will be changed to either ``liblammps_name.a``
@@ -429,7 +430,7 @@ You may need to use ``sudo make install`` in place of the last line if
 you do not have write privileges for ``/usr/local/lib`` or use the
 ``--prefix`` configuration option to select an installation folder,
 where you do have write access.  The end result should be the file
-``/usr/local/lib/libmpich.so``.  On many Linux installations the folder
+``/usr/local/lib/libmpich.so``.  On many Linux installations, the folder
 ``${HOME}/.local`` is an alternative to using ``/usr/local`` and does
 not require superuser or sudo access.  In that case the configuration
 step becomes:
@@ -438,9 +439,10 @@ step becomes:
 
   ./configure --enable-shared --prefix=${HOME}/.local
 
-Avoiding to use "sudo" for custom software installation (i.e. from source
+Avoiding the use of "sudo" for custom software installation (i.e. from
-and not through a package manager tool provided by the OS) is generally
+source and not through a package manager tool provided by the OS) is
-recommended to ensure the integrity of the system software installation.
+generally recommended to ensure the integrity of the system software
+installation.
 
 ----------
 
@@ -514,11 +516,11 @@ using CMake or Make.
 Install LAMMPS after a build
 ------------------------------------------
 
-After building LAMMPS, you may wish to copy the LAMMPS executable of
+After building LAMMPS, you may wish to copy the LAMMPS executable or
-library, along with other LAMMPS files (library header, doc files) to
+library, along with other LAMMPS files (library header, doc files), to a
-a globally visible place on your system, for others to access.  Note
+globally visible place on your system, for others to access.  Note that
-that you may need super-user privileges (e.g. sudo) if the directory
+you may need super-user privileges (e.g. sudo) if the directory you want
-you want to copy files to is protected.
+to copy files to is protected.
 
 .. tabs::
 
@@ -536,7 +538,7 @@ you want to copy files to is protected.
       environment variable, if you are installing LAMMPS into a non-system
       location and/or are linking to libraries in a non-system location that
       depend on such runtime path settings.
-      As an alternative you may set the CMake variable ``LAMMPS_INSTALL_RPATH``
+      As an alternative, you may set the CMake variable ``LAMMPS_INSTALL_RPATH``
       to ``on`` and then the runtime paths for any linked shared libraries
       and the library installation folder for the LAMMPS library will be
       embedded and thus the requirement to set environment variables is avoided.

doc/src/Build_cmake.rst

@@ -9,10 +9,10 @@ page.
 
 The following text assumes some familiarity with CMake and focuses on
 using the command line tool ``cmake`` and what settings are supported
-for building LAMMPS.  A more detailed tutorial on how to use ``cmake``
+for building LAMMPS.  A more detailed tutorial on how to use CMake
-itself, the text mode or graphical user interface, change the generated
+itself, the text mode or graphical user interface, to change the
-output files for different build tools and development environments is
+generated output files for different build tools and development
-on a :doc:`separate page <Howto_cmake>`.
+environments is on a :doc:`separate page <Howto_cmake>`.
 
 .. note::
 
@@ -22,12 +22,12 @@ on a :doc:`separate page <Howto_cmake>`.
 .. warning::
 
    You must not mix the :doc:`traditional make based <Build_make>`
-   LAMMPS build procedure with using CMake.  Thus no packages may be
+   LAMMPS build procedure with using CMake.  No packages may be
    installed or a build been previously attempted in the LAMMPS source
    directory by using ``make <machine>``.  CMake will detect if this is
    the case and generate an error.  To remove conflicting files from the
    ``src`` you can use the command ``make no-all purge`` which will
-   un-install all packages and delete all auto-generated files.
+   uninstall all packages and delete all auto-generated files.
 
 
 Advantages of using CMake
@@ -44,9 +44,9 @@ software or for people that want to modify or extend LAMMPS.
   and adapt the LAMMPS default build configuration accordingly.
 - CMake can generate files for different build tools and integrated
   development environments (IDE).
-- CMake supports customization of settings with a text mode or graphical
+- CMake supports customization of settings with a command line, text
-  user interface. No knowledge of file formats or and complex command
+  mode, or graphical user interface.  No knowledge of file formats or
-  line syntax required.
+  complex command line syntax is required.
 - All enabled components are compiled in a single build operation.
 - Automated dependency tracking for all files and configuration options.
 - Support for true out-of-source compilation. Multiple configurations
@@ -55,23 +55,23 @@ software or for people that want to modify or extend LAMMPS.
   source tree.
 - Simplified packaging of LAMMPS for Linux distributions, environment
   modules, or automated build tools like `Homebrew <https://brew.sh/>`_.
-- Integration of automated regression testing (the LAMMPS side for that
+- Integration of automated unit and regression testing (the LAMMPS side
-  is still under development).
+  of this is still under active development).
 
 .. _cmake_build:
 
 Getting started
 ^^^^^^^^^^^^^^^
 
-Building LAMMPS with CMake is a two-step process.  First you use CMake
+Building LAMMPS with CMake is a two-step process.  In the first step,
-to generate a build environment in a new directory.  For that purpose
+you use CMake to generate a build environment in a new directory.  For
-you can use either the command-line utility ``cmake`` (or ``cmake3``),
+that purpose you can use either the command-line utility ``cmake`` (or
-the text-mode UI utility ``ccmake`` (or ``ccmake3``) or the graphical
+``cmake3``), the text-mode UI utility ``ccmake`` (or ``ccmake3``) or the
-utility ``cmake-gui``, or use them interchangeably.  The second step is
+graphical utility ``cmake-gui``, or use them interchangeably.  The
-then the compilation and linking of all objects, libraries, and
+second step is then the compilation and linking of all objects,
-executables. Here is a minimal example using the command line version of
+libraries, and executables using the selected build tool.  Here is a
-CMake to build LAMMPS with no add-on packages enabled and no
+minimal example using the command line version of CMake to build LAMMPS
-customization:
+with no add-on packages enabled and no customization:
 
 .. code-block:: bash
 
@@ -96,17 +96,17 @@ Compilation can take a long time, since LAMMPS is a large project with
 many features. If your machine has multiple CPU cores (most do these
 days), you can speed this up by compiling sources in parallel with
 ``make -j N`` (with N being the maximum number of concurrently executed
-tasks).  Also installation of the `ccache <https://ccache.dev/>`_ (=
+tasks).  Installation of the `ccache <https://ccache.dev/>`_ (= Compiler
-Compiler Cache) software may speed up repeated compilation even more,
+Cache) software may speed up repeated compilation even more, e.g. during
-e.g. during code development.
+code development, especially when repeatedly switching between branches.
 
 After the initial build, whenever you edit LAMMPS source files, enable
 or disable packages, change compiler flags or build options, you must
 re-compile and relink the LAMMPS executable with ``cmake --build .`` (or
 ``make``).  If the compilation fails for some reason, try running
 ``cmake .`` and then compile again. The included dependency tracking
-should make certain that only the necessary subset of files are
+should make certain that only the necessary subset of files is
-re-compiled.  You can also delete compiled objects, libraries and
+re-compiled.  You can also delete compiled objects, libraries, and
 executables with ``cmake --build . --target clean`` (or ``make clean``).
 
 After compilation, you may optionally install the LAMMPS executable into
@@ -132,12 +132,12 @@ file called ``CMakeLists.txt`` (for LAMMPS it is located in the
 ``CMakeCache.txt``, which is generated at the end of the CMake
 configuration step.  The cache file contains all current CMake settings.
 
-To modify settings, enable or disable features, you need to set *variables*
+To modify settings, enable or disable features, you need to set
-with either the *-D* command line flag (``-D VARIABLE1_NAME=value``) or
+*variables* with either the *-D* command line flag (``-D
-change them in the text mode of graphical user interface.  The *-D* flag
+VARIABLE1_NAME=value``) or change them in the text mode of the graphical
-can be used several times in one command.
+user interface.  The *-D* flag can be used several times in one command.
 
-For your convenience we provide :ref:`CMake presets <cmake_presets>`
+For your convenience, we provide :ref:`CMake presets <cmake_presets>`
 that combine multiple settings to enable optional LAMMPS packages or use
 a different compiler tool chain.  Those are loaded with the *-C* flag
 (``-C ../cmake/presets/basic.cmake``).  This step would only be needed
@@ -155,22 +155,23 @@ specific CMake version is given when running ``cmake --help``.
 Multi-configuration build systems
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Throughout this manual it is mostly assumed that LAMMPS is being built
+Throughout this manual, it is mostly assumed that LAMMPS is being built
 on a Unix-like operating system with "make" as the underlying "builder",
-since this is the most common case.  In this case the build "configuration"
+since this is the most common case.  In this case the build
-is chose using ``-D CMAKE_BUILD_TYPE=<configuration>`` with ``<configuration>``
+"configuration" is chose using ``-D CMAKE_BUILD_TYPE=<configuration>``
-being one of "Release", "Debug", "RelWithDebInfo", or "MinSizeRel".
+with ``<configuration>`` being one of "Release", "Debug",
-Some build tools, however, can also use or even require to have a so-called
+"RelWithDebInfo", or "MinSizeRel".  Some build tools, however, can also
-multi-configuration build system setup.  For those the built type (or
+use or even require having a so-called multi-configuration build system
-configuration) is chosen at compile time using the same build files. E.g.
+setup.  For a multi-configuration build, the built type (or
-with:
+configuration) is selected at compile time using the same build
+files. E.g.  with:
 
 .. code-block:: bash
 
    cmake --build build-multi --config Release
 
 In that case the resulting binaries are not in the build folder directly
-but in sub-directories corresponding to the build type (i.e. Release in
+but in subdirectories corresponding to the build type (i.e. Release in
 the example from above).  Similarly, for running unit tests the
 configuration is selected with the *-C* flag:
 
@@ -184,7 +185,7 @@ particular applicable to compiling packages that require additional libraries
 that would be downloaded and compiled by CMake.  The "windows" preset file
 tries to keep track of which packages can be compiled natively with the
 MSVC compilers out-of-the box.  Not all of those external libraries are
-portable to Windows either.
+portable to Windows, either.
 
 
 Installing CMake

doc/src/Build_development.rst

@@ -46,7 +46,7 @@ It can be enabled for all C++ code with the following CMake flag
 
 With this flag enabled all source files will be processed twice, first to
 be compiled and then to be analyzed. Please note that the analysis can be
-significantly more time consuming than the compilation itself.
+significantly more time-consuming than the compilation itself.
 
 ----------
 

doc/src/Build_extras.rst

@@ -47,7 +47,6 @@ This is the list of packages that may require additional steps.
    * :ref:`LEPTON <lepton>`
    * :ref:`MACHDYN <machdyn>`
    * :ref:`MDI <mdi>`
-   * :ref:`MESONT <mesont>`
    * :ref:`ML-HDNNP <ml-hdnnp>`
    * :ref:`ML-IAP <mliap>`
    * :ref:`ML-PACE <ml-pace>`
@@ -127,10 +126,11 @@ CMake build
    -D GPU_API=value             # value = opencl (default) or cuda or hip
    -D GPU_PREC=value            # precision setting
                                 # value = double or mixed (default) or single
-   -D HIP_PATH                  # path to HIP installation. Must be set if GPU_API=HIP
    -D GPU_ARCH=value            # primary GPU hardware choice for GPU_API=cuda
-                                # value = sm_XX, see below
+                                # value = sm_XX (see below, default is sm_50)
-                                # default is sm_50
+   -D GPU_DEBUG=value           # enable debug code in the GPU package library, mostly useful for developers
+                                # value = yes or no (default)
+   -D HIP_PATH=value            # value = path to HIP installation. Must be set if GPU_API=HIP
    -D HIP_ARCH=value            # primary GPU hardware choice for GPU_API=hip
                                 # value depends on selected HIP_PLATFORM
                                 # default is 'gfx906' for HIP_PLATFORM=amd and 'sm_50' for HIP_PLATFORM=nvcc
@@ -288,7 +288,7 @@ your machine are not correct, the LAMMPS build will fail, and
 .. note::
 
    If you re-build the GPU library in ``lib/gpu``, you should always
-   un-install the GPU package in ``lammps/src``, then re-install it and
+   uninstall the GPU package in ``lammps/src``, then re-install it and
    re-build LAMMPS.  This is because the compilation of files in the GPU
    package uses the library settings from the ``lib/gpu/Makefile.machine``
    used to build the GPU library.
@@ -1852,48 +1852,6 @@ MDI package
 
 ----------
 
-.. _mesont:
-
-MESONT package
--------------------------
-
-This package includes a library written in Fortran 90 in the
-``lib/mesont`` folder, so a working Fortran 90 compiler is required to
-compile it.  Also, the files with the force field data for running the
-bundled examples are not included in the source distribution. Instead
-they will be downloaded the first time this package is installed.
-
-.. tabs::
-
-   .. tab:: CMake build
-
-      No additional settings are needed besides ``-D PKG_MESONT=yes``
-
-   .. tab:: Traditional make
-
-      Before building LAMMPS, you must build the *mesont* library in
-      ``lib/mesont``\ .  You can also do it in one step from the
-      ``lammps/src`` dir, using a command like these, which simply
-      invokes the ``lib/mesont/Install.py`` script with the specified
-      args:
-
-      .. code-block:: bash
-
-         make lib-mesont                    # print help message
-         make lib-mesont args="-m gfortran" # build with GNU g++ compiler (settings as with "make serial")
-         make lib-mesont args="-m ifort"    # build with Intel icc compiler
-
-      The build should produce two files: ``lib/mesont/libmesont.a`` and
-      ``lib/mesont/Makefile.lammps``\ .  The latter is copied from an
-      existing ``Makefile.lammps.\*`` and has settings needed to build
-      LAMMPS with the *mesont* library (though typically the settings
-      contain only the Fortran runtime library).  If necessary, you can
-      edit/create a new ``lib/mesont/Makefile.machine`` file for your
-      system, which should define an ``EXTRAMAKE`` variable to specify a
-      corresponding ``Makefile.lammps.machine`` file.
-
-----------
-
 .. _molfile:
 
 MOLFILE package

doc/src/Build_link.rst

@@ -1,33 +1,32 @@
 Link LAMMPS as a library to another code
 ========================================
 
-LAMMPS is designed as a library of C++ objects that can be
+LAMMPS is designed as a library of C++ objects that can be integrated
-integrated into other applications including Python scripts.
+into other applications, including Python scripts.  The files
-The files ``src/library.cpp`` and ``src/library.h`` define a
+``src/library.cpp`` and ``src/library.h`` define a C-style API for using
-C-style API for using LAMMPS as a library.  See the
+LAMMPS as a library.  See the :doc:`Howto_library` page for a
-:doc:`Howto_library` page
+description of the interface and how to use it for your needs.
-for a description of the interface and how to use it for your needs.
 
-The :doc:`Build_basics` page explains how to build
+The :doc:`Build_basics` page explains how to build LAMMPS as either a
-LAMMPS as either a shared or static library.  This results in a file
+shared or static library.  This results in a file in the compilation
-in the compilation folder called ``liblammps.a`` or ``liblammps_<name>.a``
+folder called ``liblammps.a`` or ``liblammps_<name>.a`` in case of
-in case of building a static library.  In case of a shared library
+building a static library.  In case of a shared library, the name is the
-the name is the same only that the suffix is going to be either ``.so``
+same only that the suffix is going to be either ``.so`` or ``.dylib`` or
-or ``.dylib`` or ``.dll`` instead of ``.a`` depending on the OS.
+``.dll`` instead of ``.a`` depending on the OS.  In some cases, the
-In some cases the ``.so`` file may be a symbolic link to a file with
+``.so`` file may be a symbolic link to a file with the suffix ``.so.0``
-the suffix ``.so.0`` (or some other number).
+(or some other number).
 
 .. note::
 
    Care should be taken to use the same MPI library for the calling code
-   and the LAMMPS library unless LAMMPS is to be compiled without (real)
+   and the LAMMPS library, unless LAMMPS is to be compiled without (real)
-   MPI support using the include STUBS MPI library.
+   MPI support using the included STUBS MPI library.
 
 Link with LAMMPS as a static library
 ------------------------------------
 
 The calling application can link to LAMMPS as a static library with
-compilation and link commands as in the examples shown below.  These
+compilation and link commands, as in the examples shown below.  These
 are examples for a code written in C in the file ``caller.c``.
 The benefit of linking to a static library is, that the resulting
 executable is independent of that library since all required
@@ -142,10 +141,10 @@ Link with LAMMPS as a shared library
 When linking to LAMMPS built as a shared library, the situation becomes
 much simpler, as all dependent libraries and objects are either included
 in the shared library or registered as a dependent library in the shared
-library file.  Thus those libraries need not to be specified when
+library file.  Thus, those libraries need not be specified when linking
-linking the calling executable.  Only the *-I* flags are needed.  So the
+the calling executable.  Only the *-I* flags are needed.  So the example
-example case from above of the serial version static LAMMPS library with
+case from above of the serial version static LAMMPS library with the
-the POEMS package installed becomes:
+POEMS package installed becomes:
 
 .. tabs::
 

doc/src/Build_make.rst

@@ -20,21 +20,22 @@ with :doc:`CMake <Build_cmake>`.  The makefiles of the traditional
 make based build process and the scripts they are calling expect a few
 additional tools to be available and functioning.
 
-  * a working C/C++ compiler toolchain supporting the C++11 standard; on
+  * A working C/C++ compiler toolchain supporting the C++11 standard; on
-    Linux these are often the GNU compilers. Some older compilers
+    Linux, these are often the GNU compilers. Some older compiler versions
     require adding flags like ``-std=c++11`` to enable the C++11 mode.
-  * a Bourne shell compatible "Unix" shell program (often this is ``bash``)
+  * A Bourne shell compatible "Unix" shell program (frequently this is ``bash``)
-  * a few shell utilities: ``ls``, ``mv``, ``ln``, ``rm``, ``grep``, ``sed``, ``tr``, ``cat``, ``touch``, ``diff``, ``dirname``
+  * A few shell utilities: ``ls``, ``mv``, ``ln``, ``rm``, ``grep``, ``sed``, ``tr``, ``cat``, ``touch``, ``diff``, ``dirname``
-  * python (optional, required for ``make lib-<pkg>`` in the src folder).
+  * Python (optional, required for ``make lib-<pkg>`` in the src
-    python scripts are currently tested with python 2.7 and 3.6. The procedure
+    folder).  Python scripts are currently tested with python 2.7 and
-    for :doc:`building the documentation <Build_manual>` requires python 3.5 or later.
+    3.6 to 3.11. The procedure for :doc:`building the documentation
+    <Build_manual>` *requires* Python 3.5 or later.
 
 Getting started
 ^^^^^^^^^^^^^^^
 
 To include LAMMPS packages (i.e. optional commands and styles) you must
 enable (or "install") them first, as discussed on the :doc:`Build
-package <Build_package>` page.  If a packages requires (provided or
+package <Build_package>` page.  If a package requires (provided or
 external) libraries, you must configure and build those libraries
 **before** building LAMMPS itself and especially **before** enabling
 such a package with ``make yes-<package>``.  :doc:`Building LAMMPS with
@@ -56,36 +57,36 @@ Compilation can take a long time, since LAMMPS is a large project with
 many features. If your machine has multiple CPU cores (most do these
 days), you can speed this up by compiling sources in parallel with
 ``make -j N`` (with N being the maximum number of concurrently executed
-tasks).  Also installation of the `ccache <https://ccache.dev/>`_ (=
+tasks).  Installation of the `ccache <https://ccache.dev/>`_ (= Compiler
-Compiler Cache) software may speed up repeated compilation even more,
+Cache) software may speed up repeated compilation even more, e.g. during
-e.g. during code development.
+code development, especially when repeatedly switching between branches.
 
 After the initial build, whenever you edit LAMMPS source files, or add
 or remove new files to the source directory (e.g. by installing or
 uninstalling packages), you must re-compile and relink the LAMMPS
 executable with the same ``make <machine>`` command.  The makefile's
-dependency tracking should insure that only the necessary subset of
+dependency tracking should ensure that only the necessary subset of
-files are re-compiled.  If you change settings in the makefile, you have
+files is re-compiled.  If you change settings in the makefile, you have
-to recompile *everything*.  To delete all objects you can use ``make
+to recompile *everything*.  To delete all objects, you can use ``make
 clean-<machine>``.
 
 .. note::
 
    Before the actual compilation starts, LAMMPS will perform several
-   steps to collect information from the configuration and setup that
+   steps to collect information from the configuration and setup that is
-   is then embedded into the executable.  When you build LAMMPS for
+   then embedded into the executable.  When you build LAMMPS for the
-   the first time, it will also compile a tool to quickly assemble
+   first time, it will also compile a tool to quickly determine a list
-   a list of dependencies, that are required for the make program to
+   of dependencies.  Those are required for the make program to
-   correctly detect which parts need to be recompiled after changes
+   correctly detect, which files need to be recompiled or relinked
-   were made to the sources.
+   after changes were made to the sources.
 
 Customized builds and alternate makefiles
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 The ``src/MAKE`` directory tree contains the ``Makefile.<machine>``
 files included in the LAMMPS distribution.  Typing ``make example`` uses
-``Makefile.example`` from one of those folders, if available.  Thus the
+``Makefile.example`` from one of those folders, if available.  The
-``make serial`` and ``make mpi`` lines above use
+``make serial`` and ``make mpi`` lines above, for example, use
 ``src/MAKE/Makefile.serial`` and ``src/MAKE/Makefile.mpi``,
 respectively.  Other makefiles are in these directories:
 
@@ -106,12 +107,13 @@ a new name, please edit the first line with the description and machine
 name, so you will not confuse yourself, when looking at the machine
 summary.
 
-Makefiles you may wish to try include these (some require a package
+Makefiles you may wish to try out, include those listed below (some
-first be installed).  Many of these include specific compiler flags
+require a package first be installed).  Many of these include specific
-for optimized performance.  Please note, however, that some of these
+compiler flags for optimized performance.  Please note, however, that
-customized machine Makefile are contributed by users.  Since both
+some of these customized machine Makefile are contributed by users, and
-compilers, OS configurations, and LAMMPS itself keep changing, their
+thus may have modifications specific to the systems of those users.
-settings may become outdated:
+Since compilers, OS configurations, and LAMMPS itself keep changing,
+their settings may become outdated, too:
 
 .. code-block:: bash
 

doc/src/Build_manual.rst

@@ -2,7 +2,7 @@ Build the LAMMPS documentation
 ==============================
 
 Depending on how you obtained LAMMPS and whether you have built the
-manual yourself, this directory has a number of sub-directories and
+manual yourself, this directory has a number of subdirectories and
 files. Here is a list with descriptions:
 
 .. code-block:: bash

doc/src/Build_package.rst

@@ -4,13 +4,14 @@ Include packages in build
 In LAMMPS, a package is a group of files that enable a specific set of
 features.  For example, force fields for molecular systems or
 rigid-body constraints are in packages.  In the src directory, each
-package is a sub-directory with the package name in capital letters.
+package is a subdirectory with the package name in capital letters.
 
 An overview of packages is given on the :doc:`Packages <Packages>` doc
-page.  Brief overviews of each package are on the :doc:`Packages details <Packages_details>` page.
+page.  Brief overviews of each package are on the :doc:`Packages details
+<Packages_details>` page.
 
 When building LAMMPS, you can choose to include or exclude each
-package.  In general there is no need to include a package if you
+package.  Generally, there is no need to include a package if you
 never plan to use its features.
 
 If you get a run-time error that a LAMMPS command or style is
@@ -49,7 +50,6 @@ packages:
    * :ref:`LEPTON <lepton>`
    * :ref:`MACHDYN <machdyn>`
    * :ref:`MDI <mdi>`
-   * :ref:`MESONT <mesont>`
    * :ref:`ML-HDNNP <ml-hdnnp>`
    * :ref:`ML-IAP <mliap>`
    * :ref:`ML-PACE <ml-pace>`
@@ -94,7 +94,7 @@ versus make.
          If you switch between building with CMake and make builds, no
          packages in the src directory can be installed when you invoke
          ``cmake``.  CMake will give an error if that is not the case,
-         indicating how you can un-install all packages in the src dir.
+         indicating how you can uninstall all packages in the src dir.
 
    .. tab:: Traditional make
 
@@ -103,7 +103,7 @@ versus make.
          cd lammps/src
          make ps                    # check which packages are currently installed
          make yes-name              # install a package with name
-         make no-name               # un-install a package with name
+         make no-name               # uninstall a package with name
          make mpi                   # build LAMMPS with whatever packages are now installed
 
       Examples:
@@ -119,13 +119,13 @@ versus make.
       .. note::
 
          You must always re-build LAMMPS (via make) after installing or
-         un-installing a package, for the action to take effect. The
+         uninstalling a package, for the action to take effect. The
          included dependency tracking will make certain only files that
          are required to be rebuilt are recompiled.
 
       .. note::
 
-         You cannot install or un-install packages and build LAMMPS in a
+         You cannot install or uninstall packages and build LAMMPS in a
          single make command with multiple targets, e.g. ``make
          yes-colloid mpi``.  This is because the make procedure creates
          a list of source files that will be out-of-date for the build
@@ -150,7 +150,7 @@ other files dependent on that package are also excluded.
    if you downloaded a tarball, 3 packages (KSPACE, MANYBODY, MOLECULE)
    were pre-installed via the traditional make procedure in the ``src``
    directory.  That is no longer the case, so that CMake will build
-   as-is without needing to un-install those packages.
+   as-is without needing to uninstall those packages.
 
 ----------
 
@@ -167,9 +167,9 @@ control flow constructs for more complex operations.
 
 LAMMPS includes several of these files to define configuration
 "presets", similar to the options that exist for the Make based
-system. Using these files you can enable/disable portions of the
+system. Using these files, you can enable/disable portions of the
-available packages in LAMMPS. If you need a custom preset you can take
+available packages in LAMMPS. If you need a custom preset, you can
-one of them as a starting point and customize it to your needs.
+make a copy of one of them and modify it to suit your needs.
 
 .. code-block:: bash
 
@@ -183,7 +183,7 @@ one of them as a starting point and customize it to your needs.
     cmake -C ../cmake/presets/pgi.cmake      [OPTIONS] ../cmake  # change settings to use the PGI compilers by default
     cmake -C ../cmake/presets/all_on.cmake   [OPTIONS] ../cmake  # enable all packages
     cmake -C ../cmake/presets/all_off.cmake  [OPTIONS] ../cmake  # disable all packages
-    mingw64-cmake -C ../cmake/presets/mingw-cross.cmake [OPTIONS] ../cmake  #  compile with MinGW cross compilers
+    mingw64-cmake -C ../cmake/presets/mingw-cross.cmake [OPTIONS] ../cmake  #  compile with MinGW cross-compilers
 
 Presets that have names starting with "windows" are specifically for
 compiling LAMMPS :doc:`natively on Windows <Build_windows>` and
@@ -227,7 +227,7 @@ The following commands are useful for managing package source files
 and their installation when building LAMMPS via traditional make.
 Just type ``make`` in lammps/src to see a one-line summary.
 
-These commands install/un-install sets of packages:
+These commands install/uninstall sets of packages:
 
 .. code-block:: bash
 
@@ -243,40 +243,40 @@ These commands install/un-install sets of packages:
     make yes-ext                        # install packages that require external libraries
     make no-ext                         # uninstall packages that require external libraries
 
-which install/un-install various sets of packages.  Typing ``make
+which install/uninstall various sets of packages.  Typing ``make
 package`` will list all the these commands.
 
 .. note::
 
-   Installing or un-installing a package for the make based build process
+   Installing or uninstalling a package for the make based build process
    works by simply copying files back and forth between the main source
-   directory src and the sub-directories with the package name (e.g.
+   directory src and the subdirectories with the package name (e.g.
    src/KSPACE, src/ATC), so that the files are included or excluded
    when LAMMPS is built.  Only source files in the src folder will be
    compiled.
 
 The following make commands help manage files that exist in both the
-src directory and in package sub-directories.  You do not normally
+src directory and in package subdirectories.  You do not normally
 need to use these commands unless you are editing LAMMPS files or are
 updating LAMMPS via git.
 
 Type ``make package-status`` or ``make ps`` to show which packages are
 currently installed.  For those that are installed, it will list any
 files that are different in the src directory and package
-sub-directory.
+subdirectory.
 
 Type ``make package-installed`` or ``make pi`` to show which packages are
 currently installed, without listing the status of packages that are
 not installed.
 
 Type ``make package-update`` or ``make pu`` to overwrite src files with
-files from the package sub-directories if the package is installed.  It
+files from the package subdirectories if the package is installed.  It
 should be used after the checkout has been :doc:`updated or changed
-withy git <Install_git>`, this will only update the files in the package
+with git <Install_git>`, this will only update the files in the package
-sub-directories, but not the copies in the src folder.
+subdirectories, but not the copies in the src folder.
 
 Type ``make package-overwrite`` to overwrite files in the package
-sub-directories with src files.
+subdirectories with src files.
 
 Type ``make package-diff`` to list all differences between pairs of
 files in both the source directory and the package directory.

doc/src/Build_settings.rst

@@ -1,8 +1,8 @@
 Optional build settings
 =======================
 
-LAMMPS can be built with several optional settings.  Each sub-section
+LAMMPS can be built with several optional settings.  Each subsection
-explain how to do this for building both with CMake and make.
+explains how to do this for building both with CMake and make.
 
 * `C++11 standard compliance`_ when building all of LAMMPS
 * `FFT library`_ for use with the :doc:`kspace_style pppm <kspace_style>` command
@@ -41,7 +41,7 @@ FFT library
 When the KSPACE package is included in a LAMMPS build, the
 :doc:`kspace_style pppm <kspace_style>` command performs 3d FFTs which
 require use of an FFT library to compute 1d FFTs.  The KISS FFT
-library is included with LAMMPS but other libraries can be faster.
+library is included with LAMMPS, but other libraries can be faster.
 LAMMPS can use them if they are available on your system.
 
 .. tabs::
@@ -63,9 +63,9 @@ LAMMPS can use them if they are available on your system.
       Usually these settings are all that is needed.  If FFTW3 is
       selected, then CMake will try to detect, if threaded FFTW
       libraries are available and enable them by default.  This setting
-      is independent of whether OpenMP threads are enabled and a
+      is independent of whether OpenMP threads are enabled and a package
-      packages like KOKKOS or OPENMP is used.  If CMake cannot detect
+      like KOKKOS or OPENMP is used.  If CMake cannot detect the FFT
-      the FFT library, you can set these variables to assist:
+      library, you can set these variables to assist:
 
       .. code-block:: bash
 
@@ -141,18 +141,18 @@ The Intel MKL math library is part of the Intel compiler suite.  It
 can be used with the Intel or GNU compiler (see the ``FFT_LIB`` setting
 above).
 
-Performing 3d FFTs in parallel can be time consuming due to data
+Performing 3d FFTs in parallel can be time-consuming due to data access
-access and required communication.  This cost can be reduced by
+and required communication.  This cost can be reduced by performing
-performing single-precision FFTs instead of double precision.  Single
+single-precision FFTs instead of double precision.  Single precision
-precision means the real and imaginary parts of a complex datum are
+means the real and imaginary parts of a complex datum are 4-byte floats.
-4-byte floats.  Double precision means they are 8-byte doubles.  Note
+Double precision means they are 8-byte doubles.  Note that Fourier
-that Fourier transform and related PPPM operations are somewhat less
+transform and related PPPM operations are somewhat less sensitive to
-sensitive to floating point truncation errors and thus the resulting
+floating point truncation errors, and thus the resulting error is
-error is less than the difference in precision. Using the ``-DFFT_SINGLE``
+generally less than the difference in precision. Using the
-setting trades off a little accuracy for reduced memory use and
+``-DFFT_SINGLE`` setting trades off a little accuracy for reduced memory
-parallel communication costs for transposing 3d FFT data.
+use and parallel communication costs for transposing 3d FFT data.
 
-When using ``-DFFT_SINGLE`` with FFTW3 you may need to build the FFTW
+When using ``-DFFT_SINGLE`` with FFTW3, you may need to build the FFTW
 library a second time with support for single-precision.
 
 For FFTW3, do the following, which should produce the additional
@@ -177,11 +177,11 @@ ARRAY mode.
 Size of LAMMPS integer types and size limits
 --------------------------------------------
 
-LAMMPS has a few integer data types which can be defined as either
+LAMMPS uses a few custom integer data types, which can be defined as
-4-byte (= 32-bit) or 8-byte (= 64-bit) integers at compile time.
+either 4-byte (= 32-bit) or 8-byte (= 64-bit) integers at compile time.
-This has an impact on the size of a system that can be simulated
+This has an impact on the size of a system that can be simulated, or how
-or how large counters can become before "rolling over".
+large counters can become before "rolling over".  The default setting of
-The default setting of "smallbig" is almost always adequate.
+"smallbig" is almost always adequate.
 
 .. tabs::
 
@@ -254,7 +254,7 @@ topology information, though IDs are enabled by default.  The
 :doc:`atom_modify id no <atom_modify>` command will turn them off.  Atom
 IDs are required for molecular systems with bond topology (bonds,
 angles, dihedrals, etc).  Similarly, some force or compute or fix styles
-require atom IDs.  Thus if you model a molecular system or use one of
+require atom IDs.  Thus, if you model a molecular system or use one of
 those styles with more than 2 billion atoms, you need the "bigbig"
 setting.
 
@@ -264,7 +264,7 @@ systems and 500 million for systems with bonds (the additional
 restriction is due to using the 2 upper bits of the local atom index
 in neighbor lists for storing special bonds info).
 
-Image flags store 3 values per atom in a single integer which count the
+Image flags store 3 values per atom in a single integer, which count the
 number of times an atom has moved through the periodic box in each
 dimension.  See the :doc:`dump <dump>` manual page for a discussion.  If
 an atom moves through the periodic box more than this limit, the value
@@ -285,7 +285,7 @@ Output of JPG, PNG, and movie files
 --------------------------------------------------
 
 The :doc:`dump image <dump_image>` command has options to output JPEG or
-PNG image files.  Likewise the :doc:`dump movie <dump_image>` command
+PNG image files.  Likewise, the :doc:`dump movie <dump_image>` command
 outputs movie files in a variety of movie formats.  Using these options
 requires the following settings:
 
@@ -354,7 +354,7 @@ Read or write compressed files
 If this option is enabled, large files can be read or written with
 compression by ``gzip`` or similar tools by several LAMMPS commands,
 including :doc:`read_data <read_data>`, :doc:`rerun <rerun>`, and
-:doc:`dump <dump>`.  Currently supported compression tools are:
+:doc:`dump <dump>`.  Supported compression tools are currently
 ``gzip``, ``bzip2``, ``zstd``, and ``lzma``.
 
 .. tabs::
@@ -394,7 +394,7 @@ Memory allocation alignment
 ---------------------------------------
 
 This setting enables the use of the "posix_memalign()" call instead of
-"malloc()" when LAMMPS allocates large chunks or memory.  Vector
+"malloc()" when LAMMPS allocates large chunks of memory.  Vector
 instructions on CPUs may become more efficient, if dynamically allocated
 memory is aligned on larger-than-default byte boundaries.  On most
 current operating systems, the "malloc()" implementation returns
@@ -496,7 +496,7 @@ Trigger selected floating-point exceptions
 ------------------------------------------
 
 Many kinds of CPUs have the capability to detect when a calculation
-results in an invalid math operation like a division by zero or calling
+results in an invalid math operation, like a division by zero or calling
 the square root with a negative argument.  The default behavior on
 most operating systems is to continue and have values for ``NaN`` (= not
 a number) or ``Inf`` (= infinity).  This allows software to detect and

doc/src/Commands_compute.rst

@@ -88,7 +88,6 @@ KOKKOS, o = OPENMP, t = OPT.
    * :doc:`ke/atom/eff <compute_ke_atom_eff>`
    * :doc:`ke/eff <compute_ke_eff>`
    * :doc:`ke/rigid <compute_ke_rigid>`
-   * :doc:`mesont <compute_mesont>`
    * :doc:`mliap <compute_mliap>`
    * :doc:`momentum <compute_momentum>`
    * :doc:`msd <compute_msd>`

doc/src/Commands_pair.rst

@@ -39,7 +39,7 @@ OPT.
    * :doc:`agni (o) <pair_agni>`
    * :doc:`airebo (io) <pair_airebo>`
    * :doc:`airebo/morse (io) <pair_airebo>`
-   * :doc:`amoeba <pair_amoeba>`
+   * :doc:`amoeba (g) <pair_amoeba>`
    * :doc:`atm <pair_atm>`
    * :doc:`awpmd/cut <pair_awpmd>`
    * :doc:`beck (go) <pair_beck>`
@@ -126,7 +126,7 @@ OPT.
    * :doc:`hbond/dreiding/lj (o) <pair_hbond_dreiding>`
    * :doc:`hbond/dreiding/morse (o) <pair_hbond_dreiding>`
    * :doc:`hdnnp <pair_hdnnp>`
-   * :doc:`hippo <pair_amoeba>`
+   * :doc:`hippo (g) <pair_amoeba>`
    * :doc:`ilp/graphene/hbn (t) <pair_ilp_graphene_hbn>`
    * :doc:`ilp/tmd (t) <pair_ilp_tmd>`
    * :doc:`kolmogorov/crespi/full <pair_kolmogorov_crespi_full>`
@@ -200,11 +200,11 @@ OPT.
    * :doc:`mdpd <pair_mesodpd>`
    * :doc:`mdpd/rhosum <pair_mesodpd>`
    * :doc:`meam (k) <pair_meam>`
+   * :doc:`meam/ms (k) <pair_meam>`
    * :doc:`meam/spline (o) <pair_meam_spline>`
    * :doc:`meam/sw/spline <pair_meam_sw_spline>`
    * :doc:`mesocnt <pair_mesocnt>`
    * :doc:`mesocnt/viscous <pair_mesocnt>`
-   * :doc:`mesont/tpm <pair_mesont_tpm>`
    * :doc:`mgpt <pair_mgpt>`
    * :doc:`mie/cut (g) <pair_mie>`
    * :doc:`mliap (k) <pair_mliap>`

doc/src/Commands_removed.rst

@@ -59,6 +59,17 @@ Minimize style *fire/old* has been removed. Its functionality can be
 reproduced with *fire* with specific options. Please see the
 :doc:`min_modify command <min_modify>` documentation for details.
 
+Pair style mesont/tpm, compute style mesont, atom style mesont
+--------------------------------------------------------------
+
+.. deprecated:: TBD
+
+Pair style *mesont/tpm*, compute style *mesont*, and atom style
+*mesont* have been removed from the :ref:`MESONT package <PKG-MESONT>`.
+The same functionality is available through
+:doc:`pair style mesocnt <pair_mesocnt>`,
+:doc:`bond style mesocnt <bond_mesocnt>` and
+:doc:`angle style mesocnt <angle_mesocnt>`.
 
 REAX package
 ------------

doc/src/Developer_comm_ops.rst

@@ -14,8 +14,8 @@ Owned and ghost atoms
 As described on the :doc:`parallel partitioning algorithms
 <Developer_par_part>` page, LAMMPS spatially decomposes the simulation
 domain, either in a *brick* or *tiled* manner.  Each processor (MPI
-task) owns atoms within its sub-domain and additionally stores ghost
+task) owns atoms within its subdomain and additionally stores ghost
-atoms within a cutoff distance of its sub-domain.
+atoms within a cutoff distance of its subdomain.
 
 Forward and reverse communication
 =================================

doc/src/Developer_flow.rst

@@ -139,7 +139,7 @@ Periodic boundary conditions are then applied by the Domain class via
 its ``pbc()`` method to remap particles that have moved outside the
 simulation box back into the box.  Note that this is not done every
 timestep, but only when neighbor lists are rebuilt.  This is so that
-each processor's sub-domain will have consistent (nearby) atom
+each processor's subdomain will have consistent (nearby) atom
 coordinates for its owned and ghost atoms.  It is also why dumped atom
 coordinates may be slightly outside the simulation box if not dumped
 on a step where the neighbor lists are rebuilt.
@@ -153,10 +153,10 @@ method of the Comm class and ``setup_bins()`` method of the Neighbor
 class perform the update.
 
 The code is now ready to migrate atoms that have left a processor's
-geometric sub-domain to new processors.  The ``exchange()`` method of
+geometric subdomain to new processors.  The ``exchange()`` method of
 the Comm class performs this operation.  The ``borders()`` method of the
 Comm class then identifies ghost atoms surrounding each processor's
-sub-domain and communicates ghost atom information to neighboring
+subdomain and communicates ghost atom information to neighboring
 processors.  It does this by looping over all the atoms owned by a
 processor to make lists of those to send to each neighbor processor.  On
 subsequent timesteps, the lists are used by the ``Comm::forward_comm()``

doc/src/Developer_grid.rst

@@ -28,9 +28,9 @@ grid.
 
 More specifically, a grid point is defined for each cell (by default
 the center point), and a processor owns a grid cell if its point is
-within the processor's spatial sub-domain.  The union of processor
+within the processor's spatial subdomain.  The union of processor
-sub-domains is the global simulation box.  If a grid point is on the
+subdomains is the global simulation box.  If a grid point is on the
-boundary of two sub-domains, the lower processor owns the grid cell.  A
+boundary of two subdomains, the lower processor owns the grid cell.  A
 processor may also store copies of ghost cells which surround its
 owned cells.
 
@@ -62,7 +62,7 @@ y-dimension.  It is even possible to define a 1x1x1 3d grid, though it
 may be inefficient to use it in a computational sense.
 
 Note that the choice of grid size is independent of the number of
-processors or their layout in a grid of processor sub-domains which
+processors or their layout in a grid of processor subdomains which
 overlays the simulations domain.  Depending on the distributed grid
 size, a single processor may own many 1000s or no grid cells.
 
@@ -160,7 +160,7 @@ cells (the entire allocated grid).
 Grid class constructors
 ^^^^^^^^^^^^^^^^^^^^^^^
 
-The following sub-sections describe the public methods of the Grid3d
+The following subsections describe the public methods of the Grid3d
 class which a style command can invoke.  The Grid2d methods are
 similar; simply remove arguments which refer to the z-dimension.
 
@@ -235,7 +235,7 @@ invoked, because they influence its operation.
    void set_zfactor(double factor);
 
 Processors own a grid cell if a point within the grid cell is inside
-the processor's sub-domain.  By default this is the center point of the
+the processor's subdomain.  By default this is the center point of the
 grid cell.  The *set_shift_grid()* method can change this.  The *shift*
 argument is a value from 0.0 to 1.0 (inclusive) which is the offset of
 the point within the grid cell in each dimension.  The default is 0.5
@@ -245,9 +245,9 @@ typically no need to change the default as it is optimal for
 minimizing the number of ghost cells needed.
 
 If a processor maps its particles to grid cells, it needs to allow for
-its particles being outside its sub-domain between reneighboring.  The
+its particles being outside its subdomain between reneighboring.  The
 *distance* argument of the *set_distance()* method sets the furthest
-distance outside a processor's sub-domain which a particle can move.
+distance outside a processor's subdomain which a particle can move.
 Typically this is half the neighbor skin distance, assuming
 reneighboring is done appropriately.  This distance is used in
 determining how many ghost cells a processor needs to store to enable
@@ -295,7 +295,7 @@ to the Grid class via the *set_zfactor()* method (*set_yfactor()* for
 2d grids).  The Grid class will then assign ownership of the 1/3 of
 grid cells that overlay the simulation box to the processors which
 also overlay the simulation box.  The remaining 2/3 of the grid cells
-are assigned to processors whose sub-domains are adjacent to the upper
+are assigned to processors whose subdomains are adjacent to the upper
 z boundary of the simulation box.
 
 ----------
@@ -533,7 +533,7 @@ processor's ghost cells extend further than nearest neighbor
 processors.
 
 This can be checked by callers who have the option to change the
-global grid size to insure more efficient nearest-neighbor-only
+global grid size to ensure more efficient nearest-neighbor-only
 communication if they wish.  In this case, they instantiate a grid of
 a given size (resolution), then invoke *setup_comm()* followed by
 *ghost_adjacent()*.  If the ghost cells are not adjacent, they destroy
@@ -549,13 +549,13 @@ Grid class remap methods for load balancing
 The following methods are used when a load-balancing operation,
 triggered by the :doc:`balance <balance>` or :doc:`fix balance
 <fix_balance>` commands, changes the partitioning of the simulation
-domain into processor sub-domains.
+domain into processor subdomains.
 
 In order to work with load-balancing, any style command (compute, fix,
 pair, or kspace style) which allocates a grid and stores per-grid data
 should define a *reset_grid()* method; it takes no arguments.  It will
 be called by the two balance commands after they have reset processor
-sub-domains and migrated atoms (particles) to new owning processors.
+subdomains and migrated atoms (particles) to new owning processors.
 The *reset_grid()* method will typically perform some or all of the
 following operations.  See the src/fix_ave_grid.cpp and
 src/EXTRA_FIX/fix_ttm_grid.cpp files for examples of *reset_grid()*
@@ -564,7 +564,7 @@ functions.
 
 First, the *reset_grid()* method can instantiate new grid(s) of the
 same global size, then call *setup_grid()* to partition them via the
-new processor sub-domains.  At this point, it can invoke the
+new processor subdomains.  At this point, it can invoke the
 *identical()* method which compares the owned and ghost grid cell
 index bounds between two grids, the old grid passed as a pointer
 argument, and the new grid whose *identical()* method is being called.
@@ -753,7 +753,7 @@ their input script syntax, as described on the :doc:`Howto_grid
 * f_ID:gname:dname
 * f_ID:gname:dname[I]
 
-Each grid a command instantiates has a unique *gname*, defined by the
+Each grid command instantiates has a unique *gname*, defined by the
 command.  Likewise each grid cell data structure (scalar or vector)
 associated with a grid has a unique *dname*, also defined by the
 command.
@@ -784,8 +784,7 @@ The *get_grid_by_index()* method is called after the
 *get_grid_by_name()* method, using the grid index it returned as its
 argument.  This method will return a pointer to the Grid2d or Grid3d
 class.  The caller can use this to query grid attributes, such as the
-global size of the grid.  The :doc:`dump grid <dump>` to insure each
+global size of the grid, to ensure it is of the expected size.
-its grid reference arguments are for grids of the same size.
 
 The *get_griddata_by_name()* method takes a grid index *igrid* and a
 data name as input.  It returns two values.  The *ncol* argument is

doc/src/Developer_notes.rst

@@ -102,7 +102,7 @@ build is then :doc:`processed in parallel <Developer_par_neigh>`.
 The most commonly required neighbor list is a so-called "half" neighbor
 list, where each pair of atoms is listed only once (except when the
 :doc:`newton command setting <newton>` for pair is off; in that case
-pairs straddling sub-domains or periodic boundaries will be listed twice).
+pairs straddling subdomains or periodic boundaries will be listed twice).
 Thus these are the default settings when a neighbor list request is created in:
 
 .. code-block:: c++
@@ -361,7 +361,7 @@ allocated as a 1d vector or 3d array.  Either way, the ordering of
 values within contiguous memory x fastest, then y, z slowest.
 
 For the ``3d decomposition`` of the grid, the global grid is
-partitioned into bricks that correspond to the sub-domains of the
+partitioned into bricks that correspond to the subdomains of the
 simulation box that each processor owns.  Often, this is a regular 3d
 array (Px by Py by Pz) of bricks, where P = number of processors =
 Px * Py * Pz.  More generally it can be a tiled decomposition, where

doc/src/Developer_org.rst

@@ -7,7 +7,7 @@ but there are small a number of files in several other languages like C,
 Fortran, Shell script, or Python.
 
 The core of the code is located in the ``src`` folder and its
-sub-directories.  A sizable number of these files are in the ``src``
+subdirectories.  A sizable number of these files are in the ``src``
 directory itself, but there are plenty of :doc:`packages <Packages>`,
 which can be included or excluded when LAMMPS is built.  See the
 :doc:`Include packages in build <Build_package>` section of the manual
@@ -16,11 +16,11 @@ currently supports building with :doc:`conventional makefiles
 <Build_make>` and through :doc:`CMake <Build_cmake>`.  Those procedures
 differ in how packages are enabled or disabled for inclusion into a
 LAMMPS binary so they cannot be mixed.  The source files for each
-package are in all-uppercase sub-directories of the ``src`` folder, for
+package are in all-uppercase subdirectories of the ``src`` folder, for
 example ``src/MOLECULE`` or ``src/EXTRA-MOLECULE``.  The ``src/STUBS``
-sub-directory is not a package but contains a dummy MPI library, that is
+subdirectory is not a package but contains a dummy MPI library, that is
 used when building a serial version of the code. The ``src/MAKE``
-directory and its sub-directories contain makefiles with settings and
+directory and its subdirectories contain makefiles with settings and
 flags for a variety of configuration and machines for the build process
 with traditional makefiles.
 
@@ -28,7 +28,7 @@ The ``lib`` directory contains the source code for several supporting
 libraries or files with configuration settings to use globally installed
 libraries, that are required by some of the optional packages.  They may
 include python scripts that can transparently download additional source
-code on request.  Each sub-directory, like ``lib/poems`` or ``lib/gpu``,
+code on request.  Each subdirectory, like ``lib/poems`` or ``lib/gpu``,
 contains the source files, some of which are in different languages such
 as Fortran or CUDA. These libraries included in the LAMMPS build,
 if the corresponding package is installed.

doc/src/Developer_par_comm.rst

@@ -7,16 +7,16 @@ large systems provided it uses a correspondingly large number of MPI
 processes.  Since The per-atom data (atom IDs, positions, velocities,
 types, etc.)  To be able to compute the short-range interactions MPI
 processes need not only access to data of atoms they "own" but also
-information about atoms from neighboring sub-domains, in LAMMPS referred
+information about atoms from neighboring subdomains, in LAMMPS referred
 to as "ghost" atoms.  These are copies of atoms storing required
 per-atom data for up to the communication cutoff distance. The green
 dashed-line boxes in the :ref:`domain-decomposition` figure illustrate
-the extended ghost-atom sub-domain for one processor.
+the extended ghost-atom subdomain for one processor.
 
 This approach is also used to implement periodic boundary
 conditions: atoms that lie within the cutoff distance across a periodic
 boundary are also stored as ghost atoms and taken from the periodic
-replication of the sub-domain, which may be the same sub-domain, e.g. if
+replication of the subdomain, which may be the same subdomain, e.g. if
 running in serial.  As a consequence of this, force computation in
 LAMMPS is not subject to minimum image conventions and thus cutoffs may
 be larger than half the simulation domain.
@@ -28,10 +28,10 @@ be larger than half the simulation domain.
    ghost atom communication
 
    This figure shows the ghost atom communication patterns between
-   sub-domains for "brick" (left) and "tiled" communication styles for
+   subdomains for "brick" (left) and "tiled" communication styles for
    2d simulations.  The numbers indicate MPI process ranks.  Here the
-   sub-domains are drawn spatially separated for clarity.  The
+   subdomains are drawn spatially separated for clarity.  The
-   dashed-line box is the extended sub-domain of processor 0 which
+   dashed-line box is the extended subdomain of processor 0 which
    includes its ghost atoms.  The red- and blue-shaded boxes are the
    regions of communicated ghost atoms.
 
@@ -42,7 +42,7 @@ atom communication is performed in two stages for a 2d simulation (three
 in 3d) for both a regular and irregular partitioning of the simulation
 box.  For the regular case (left) atoms are exchanged first in the
 *x*-direction, then in *y*, with four neighbors in the grid of processor
-sub-domains.
+subdomains.
 
 In the *x* stage, processor ranks 1 and 2 send owned atoms in their
 red-shaded regions to rank 0 (and vice versa).  Then in the *y* stage,
@@ -55,7 +55,7 @@ For the irregular case (right) the two stages are similar, but a
 processor can have more than one neighbor in each direction.  In the
 *x* stage, MPI ranks 1,2,3 send owned atoms in their red-shaded regions to
 rank 0 (and vice versa).  These include only atoms between the lower
-and upper *y*-boundary of rank 0's sub-domain.  In the *y* stage, ranks
+and upper *y*-boundary of rank 0's subdomain.  In the *y* stage, ranks
 4,5,6 send atoms in their blue-shaded regions to rank 0.  This may
 include ghost atoms they received in the *x* stage, but only if they
 are needed by rank 0 to fill its extended ghost atom regions in the
@@ -110,11 +110,11 @@ performed in LAMMPS:
   over 3x the length of a stretched bond for dihedral interactions.  It
   can also exceed the periodic box size.  For the regular communication
   pattern (left), if the cutoff distance extends beyond a neighbor
-  processor's sub-domain, then multiple exchanges are performed in the
+  processor's subdomain, then multiple exchanges are performed in the
   same direction.  Each exchange is with the same neighbor processor,
   but buffers are packed/unpacked using a different list of atoms. For
   forward communication, in the first exchange a processor sends only
   owned atoms.  In subsequent exchanges, it sends ghost atoms received
   in previous exchanges.  For the irregular pattern (right) overlaps of
-  a processor's extended ghost-atom sub-domain with all other processors
+  a processor's extended ghost-atom subdomain with all other processors
   in each dimension are detected.

doc/src/Developer_par_long.rst

@@ -20,7 +20,7 @@ e) electric field values from grid points near each atom are interpolated to com
 
 For any of the spatial-decomposition partitioning schemes each processor
 owns the brick-shaped portion of FFT grid points contained within its
-sub-domain.  The two interpolation operations use a stencil of grid
+subdomain.  The two interpolation operations use a stencil of grid
 points surrounding each atom.  To accommodate the stencil size, each
 processor also stores a few layers of ghost grid points surrounding its
 brick.  Forward and reverse communication of grid point values is
@@ -64,7 +64,7 @@ direction of the 1d FFTs it has to perform. LAMMPS uses the
 pencil-decomposition algorithm as shown in the :ref:`fft-parallel` figure.
 
 Initially (far left), each processor owns a brick of same-color grid
-cells (actually grid points) contained within in its sub-domain.  A
+cells (actually grid points) contained within in its subdomain.  A
 brick-to-pencil communication operation converts this layout to 1d
 pencils in the *x*-dimension (center left).  Again, cells of the same
 color are owned by the same processor.  Each processor can then compute
@@ -161,8 +161,8 @@ grid/particle operations that LAMMPS supports:
   <partition>` calculation and then use the :doc:`verlet/split
   integrator <run_style>` to perform the PPPM computation on a
   dedicated, separate partition of MPI processes.  This uses an integer
-  "1:*p*" mapping of *p* sub-domains of the atom decomposition to one
+  "1:*p*" mapping of *p* subdomains of the atom decomposition to one
-  sub-domain of the FFT grid decomposition and where pairwise non-bonded
+  subdomain of the FFT grid decomposition and where pairwise non-bonded
   and bonded forces and energies are computed on the larger partition
   and the PPPM kspace computation concurrently on the smaller partition.
 
@@ -172,7 +172,7 @@ grid/particle operations that LAMMPS supports:
 
 - LAMMPS implements a ``GridComm`` class which overlays the simulation
   domain with a regular grid, partitions it across processors in a
-  manner consistent with processor sub-domains, and provides methods for
+  manner consistent with processor subdomains, and provides methods for
   forward and reverse communication of owned and ghost grid point
   values.  It is used for PPPM as an FFT grid (as outlined above) and
   also for the MSM algorithm which uses a cascade of grid sizes from

doc/src/Developer_par_neigh.rst

@@ -22,7 +22,7 @@ last reneighboring; this and other options of the neighbor list rebuild
 can be adjusted with the :doc:`neigh_modify <neigh_modify>` command.
 
 On steps when reneighboring is performed, atoms which have moved outside
-their owning processor's sub-domain are first migrated to new processors
+their owning processor's subdomain are first migrated to new processors
 via communication.  Periodic boundary conditions are also (only)
 enforced on these steps to ensure each atom is re-assigned to the
 correct processor.  After migration, the atoms owned by each processor
@@ -39,12 +39,12 @@ its settings modified with the :doc:`atom_modify <atom_modify>` command.
 
    neighbor list stencils
 
-   A 2d simulation sub-domain (thick black line) and the corresponding
+   A 2d simulation subdomain (thick black line) and the corresponding
    ghost atom cutoff region (dashed blue line) for both orthogonal
    (left) and triclinic (right) domains.  A regular grid of neighbor
    bins (thin lines) overlays the entire simulation domain and need not
-   align with sub-domain boundaries; only the portion overlapping the
+   align with subdomain boundaries; only the portion overlapping the
-   augmented sub-domain is shown.  In the triclinic case it overlaps the
+   augmented subdomain is shown.  In the triclinic case it overlaps the
    bounding box of the tilted rectangle.  The blue- and red-shaded bins
    represent a stencil of bins searched to find neighbors of a particular
    atom (black dot).
@@ -52,8 +52,8 @@ its settings modified with the :doc:`atom_modify <atom_modify>` command.
 To build a local neighbor list in linear time, the simulation domain is
 overlaid (conceptually) with a regular 3d (or 2d) grid of neighbor bins,
 as shown in the :ref:`neighbor-stencil` figure for 2d models and a
-single MPI processor's sub-domain.  Each processor stores a set of
+single MPI processor's subdomain.  Each processor stores a set of
-neighbor bins which overlap its sub-domain extended by the neighbor
+neighbor bins which overlap its subdomain extended by the neighbor
 cutoff distance :math:`R_n`.  As illustrated, the bins need not align
 with processor boundaries; an integer number in each dimension is fit to
 the size of the entire simulation box.
@@ -144,7 +144,7 @@ supports:
 
 - For small and sparse systems and as a fallback method, LAMMPS also
   supports neighbor list construction without binning by using a full
-  :math:`O(N^2)` loop over all *i,j* atom pairs in a sub-domain when
+  :math:`O(N^2)` loop over all *i,j* atom pairs in a subdomain when
   using the :doc:`neighbor nsq <neighbor>` command.
 
 - Dependent on the "pair" setting of the :doc:`newton <newton>` command,

doc/src/Developer_par_part.rst

@@ -15,8 +15,8 @@ distributed-memory parallelism is set with the :doc:`comm_style command
    for MPI parallelization: "brick" on the left with an orthogonal
    (left) and a triclinic (middle) simulation domain, and a "tiled"
    decomposition (right).  The black lines show the division into
-   sub-domains and the contained atoms are "owned" by the corresponding
+   subdomains and the contained atoms are "owned" by the corresponding
-   MPI process. The green dashed lines indicate how sub-domains are
+   MPI process. The green dashed lines indicate how subdomains are
    extended with "ghost" atoms up to the communication cutoff distance.
 
 The LAMMPS simulation box is a 3d or 2d volume, which can be orthogonal
@@ -32,14 +32,14 @@ means the position of the box face adjusts continuously to enclose all
 the atoms.
 
 For distributed-memory MPI parallelism, the simulation box is spatially
-decomposed (partitioned) into non-overlapping sub-domains which fill the
+decomposed (partitioned) into non-overlapping subdomains which fill the
 box. The default partitioning, "brick", is most suitable when atom
 density is roughly uniform, as shown in the left-side images of the
-:ref:`domain-decomposition` figure.  The sub-domains comprise a regular
+:ref:`domain-decomposition` figure.  The subdomains comprise a regular
-grid and all sub-domains are identical in size and shape.  Both the
+grid and all subdomains are identical in size and shape.  Both the
 orthogonal and triclinic boxes can deform continuously during a
 simulation, e.g. to compress a solid or shear a liquid, in which case
-the processor sub-domains likewise deform.
+the processor subdomains likewise deform.
 
 
 For models with non-uniform density, the number of particles per
@@ -50,14 +50,14 @@ load.  For such models, LAMMPS supports multiple strategies to reduce
 the load imbalance:
 
 - The processor grid decomposition is by default based on the simulation
-  cell volume and tries to optimize the volume to surface ratio for the sub-domains.
+  cell volume and tries to optimize the volume to surface ratio for the subdomains.
   This can be changed with the :doc:`processors command <processors>`.
-- The parallel planes defining the size of the sub-domains can be shifted
+- The parallel planes defining the size of the subdomains can be shifted
   with the :doc:`balance command <balance>`. Which can be done in addition
   to choosing a more optimal processor grid.
 - The recursive bisectioning algorithm in combination with the "tiled"
   communication style can produce a partitioning with equal numbers of
-  particles in each sub-domain.
+  particles in each subdomain.
 
 
 .. |decomp1| image:: img/decomp-regular.png
@@ -76,14 +76,14 @@ the load imbalance:
 
 The pictures above demonstrate different decompositions for a 2d system
 with 12 MPI ranks.  The atom colors indicate the load imbalance of each
-sub-domain with green being optimal and red the least optimal.
+subdomain with green being optimal and red the least optimal.
 
 Due to the vacuum in the system, the default decomposition is unbalanced
 with several MPI ranks without atoms (left). By forcing a 1x12x1
 processor grid, every MPI rank does computations now, but number of
-atoms per sub-domain is still uneven and the thin slice shape increases
+atoms per subdomain is still uneven and the thin slice shape increases
-the amount of communication between sub-domains (center left). With a
+the amount of communication between subdomains (center left). With a
-2x6x1 processor grid and shifting the sub-domain divisions, the load
+2x6x1 processor grid and shifting the subdomain divisions, the load
 imbalance is further reduced and the amount of communication required
-between sub-domains is less (center right).  And using the recursive
+between subdomains is less (center right).  And using the recursive
 bisectioning leads to further improved decomposition (right).

doc/src/Developer_parallel.rst

@@ -7,7 +7,7 @@ decomposition.  The parallelization aims to be efficient, and resulting
 in good strong scaling (= good speedup for the same system) and good
 weak scaling (= the computational cost of enlarging the system is
 proportional to the system size).  Additional parallelization using GPUs
-or OpenMP can also be applied within the sub-domain assigned to an MPI
+or OpenMP can also be applied within the subdomain assigned to an MPI
 process.  For clarity, most of the following illustrations show the 2d
 simulation case. The underlying algorithms in those cases, however,
 apply to both 2d and 3d cases equally well.

doc/src/Developer_utils.rst

@@ -647,7 +647,7 @@ Communication buffer coding with *ubuf*
 ---------------------------------------
 
 LAMMPS uses communication buffers where it collects data from various
-class instances and then exchanges the data with neighboring sub-domains.
+class instances and then exchanges the data with neighboring subdomains.
 For simplicity those buffers are defined as ``double`` buffers and
 used for doubles and integer numbers. This presents a unique problem
 when 64-bit integers are used.  While the storage needed for a ``double``

doc/src/Errors_common.rst

@@ -113,7 +113,7 @@ LAMMPS output, something is wrong with your simulation.  If you
 suspect this is happening, it is a good idea to print out
 thermodynamic info frequently (e.g. every timestep) via the
 :doc:`thermo <thermo>` so you can monitor what is happening.
-Visualizing the atom movement is also a good idea to insure your model
+Visualizing the atom movement is also a good idea to ensure your model
 is behaving as you expect.
 
 In parallel, one way LAMMPS can hang is due to how different MPI

doc/src/Errors_messages.rst

@@ -5635,7 +5635,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
    Lost atoms are checked for each time thermo output is done.  See the
    thermo_modify lost command for options.  Lost atoms usually indicate
    bad dynamics, e.g. atoms have been blown far out of the simulation
-   box, or moved further than one processor's sub-domain away before
+   box, or moved further than one processor's subdomain away before
    reneighboring.
 
 *MEAM library error %d*
@@ -6092,7 +6092,7 @@ keyword to allow for additional bonds to be formed
    after a read_data, read_restart, or create_box command.
 
 *Next command must list all universe and uloop variables*
-   This is to insure they stay in sync.
+   This is to ensure they stay in sync.
 
 *No Kspace style defined for compute group/group*
    Self-explanatory.
@@ -6266,14 +6266,14 @@ keyword to allow for additional bonds to be formed
    One or more atoms are attempting to map their charge to a MSM grid point
    that is not owned by a processor.  This is likely for one of two
    reasons, both of them bad.  First, it may mean that an atom near the
-   boundary of a processor's sub-domain has moved more than 1/2 the
+   boundary of a processor's subdomain has moved more than 1/2 the
    :doc:`neighbor skin distance <neighbor>` without neighbor lists being
    rebuilt and atoms being migrated to new processors.  This also means
    you may be missing pairwise interactions that need to be computed.
    The solution is to change the re-neighboring criteria via the
    :doc:`neigh_modify <neigh_modify>` command.  The safest settings are
    "delay 0 every 1 check yes".  Second, it may mean that an atom has
-   moved far outside a processor's sub-domain or even the entire
+   moved far outside a processor's subdomain or even the entire
    simulation box. This indicates bad physics, e.g. due to highly
    overlapping atoms, too large a timestep, etc.
 
@@ -6281,14 +6281,14 @@ keyword to allow for additional bonds to be formed
    One or more atoms are attempting to map their charge to a PPPM grid
    point that is not owned by a processor.  This is likely for one of two
    reasons, both of them bad.  First, it may mean that an atom near the
-   boundary of a processor's sub-domain has moved more than 1/2 the
+   boundary of a processor's subdomain has moved more than 1/2 the
    :doc:`neighbor skin distance <neighbor>` without neighbor lists being
    rebuilt and atoms being migrated to new processors.  This also means
    you may be missing pairwise interactions that need to be computed.
    The solution is to change the re-neighboring criteria via the
    :doc:`neigh_modify <neigh_modify>` command.  The safest settings are
    "delay 0 every 1 check yes".  Second, it may mean that an atom has
-   moved far outside a processor's sub-domain or even the entire
+   moved far outside a processor's subdomain or even the entire
    simulation box. This indicates bad physics, e.g. due to highly
    overlapping atoms, too large a timestep, etc.
 
@@ -6296,14 +6296,14 @@ keyword to allow for additional bonds to be formed
    One or more atoms are attempting to map their charge to a PPPM grid
    point that is not owned by a processor.  This is likely for one of two
    reasons, both of them bad.  First, it may mean that an atom near the
-   boundary of a processor's sub-domain has moved more than 1/2 the
+   boundary of a processor's subdomain has moved more than 1/2 the
    :doc:`neighbor skin distance <neighbor>` without neighbor lists being
    rebuilt and atoms being migrated to new processors.  This also means
    you may be missing pairwise interactions that need to be computed.
    The solution is to change the re-neighboring criteria via the
    :doc:`neigh_modify <neigh_modify>` command.  The safest settings are
    "delay 0 every 1 check yes".  Second, it may mean that an atom has
-   moved far outside a processor's sub-domain or even the entire
+   moved far outside a processor's subdomain or even the entire
    simulation box. This indicates bad physics, e.g. due to highly
    overlapping atoms, too large a timestep, etc.
 
@@ -7231,7 +7231,7 @@ keyword to allow for additional bonds to be formed
 
 *Replacing a fix, but new style != old style*
    A fix ID can be used a second time, but only if the style matches the
-   previous fix.  In this case it is assumed you with to reset a fix's
+   previous fix.  In this case it is assumed you want to reset a fix's
    parameters.  This error may mean you are mistakenly re-using a fix ID
    when you do not intend to.
 
@@ -7337,7 +7337,7 @@ keyword to allow for additional bonds to be formed
 *Rigid body atoms %d %d missing on proc %d at step %ld*
    This means that an atom cannot find the atom that owns the rigid body
    it is part of, or vice versa.  The solution is to use the communicate
-   cutoff command to insure ghost atoms are acquired from far enough away
+   cutoff command to ensure ghost atoms are acquired from far enough away
    to encompass the max distance printed when the fix rigid/small command
    was invoked.
 

doc/src/Errors_warnings.rst

@@ -109,9 +109,9 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
 *Communication cutoff is shorter than a bond length based estimate. This may lead to errors.*
    Since LAMMPS stores topology data with individual atoms, all atoms
    comprising a bond, angle, dihedral or improper must be present on any
-   sub-domain that "owns" the atom with the information, either as a
+   subdomain that "owns" the atom with the information, either as a
    local or a ghost atom. The communication cutoff is what determines up
-   to what distance from a sub-domain boundary ghost atoms are created.
+   to what distance from a subdomain boundary ghost atoms are created.
    The communication cutoff is by default the largest non-bonded cutoff
    plus the neighbor skin distance, but for short or non-bonded cutoffs
    and/or long bonds, this may not be sufficient. This warning indicates
@@ -351,7 +351,7 @@ This will most likely cause errors in kinetic fluctuations.
    Self-explanatory.
 
 *Kspace_modify slab param < 2.0 may cause unphysical behavior*
-   The kspace_modify slab parameter should be larger to insure periodic
+   The kspace_modify slab parameter should be larger to ensure periodic
    grids padded with empty space do not overlap.
 
 *Less insertions than requested*
@@ -398,7 +398,7 @@ This will most likely cause errors in kinetic fluctuations.
    Lost atoms are checked for each time thermo output is done.  See the
    thermo_modify lost command for options.  Lost atoms usually indicate
    bad dynamics, e.g. atoms have been blown far out of the simulation
-   box, or moved further than one processor's sub-domain away before
+   box, or moved further than one processor's subdomain away before
    reneighboring.
 
 *MSM mesh too small, increasing to 2 points in each direction*
@@ -491,7 +491,7 @@ This will most likely cause errors in kinetic fluctuations.
 *Neighbor exclusions used with KSpace solver may give inconsistent Coulombic energies*
    This is because excluding specific pair interactions also excludes
    them from long-range interactions which may not be the desired effect.
-   The special_bonds command handles this consistently by insuring
+   The special_bonds command handles this consistently by ensuring
    excluded (or weighted) 1-2, 1-3, 1-4 interactions are treated
    consistently by both the short-range pair style and the long-range
    solver.  This is not done for exclusions of charged atom pairs via the
@@ -545,7 +545,7 @@ This will most likely cause errors in kinetic fluctuations.
    If there are other fixes that act immediately after the initial stage
    of time integration within a timestep (i.e. after atoms move), then
    the command that sets up the dynamic group should appear after those
-   fixes.  This will insure that dynamic group assignments are made
+   fixes.  This will ensure that dynamic group assignments are made
    after all atoms have moved.
 
 *One or more respa levels compute no forces*
@@ -582,13 +582,13 @@ This will most likely cause errors in kinetic fluctuations.
    needed.  The requested volume fraction may be too high, or other atoms
    may be in the insertion region.
 
-*Proc sub-domain size < neighbor skin, could lead to lost atoms*
+*Proc subdomain size < neighbor skin, could lead to lost atoms*
    The decomposition of the physical domain (likely due to load
-   balancing) has led to a processor's sub-domain being smaller than the
+   balancing) has led to a processor's subdomain being smaller than the
    neighbor skin in one or more dimensions.  Since reneighboring is
    triggered by atoms moving the skin distance, this may lead to lost
    atoms, if an atom moves all the way across a neighboring processor's
-   sub-domain before reneighboring is triggered.
+   subdomain before reneighboring is triggered.
 
 *Reducing PPPM order b/c stencil extends beyond nearest neighbor processor*
    This may lead to a larger grid than desired.  See the kspace_modify overlap

doc/src/Examples.rst

@@ -1,7 +1,7 @@
 Example scripts
 ===============
 
-The LAMMPS distribution includes an examples sub-directory with many
+The LAMMPS distribution includes an examples subdirectory with many
 sample problems.  Many are 2d models that run quickly and are
 straightforward to visualize, requiring at most a couple of minutes to
 run on a desktop machine.  Each problem has an input script (in.\*) and
@@ -29,7 +29,7 @@ be quickly post-processed into a movie using commands described on the
 Animations of many of the examples can be viewed on the Movies section
 of the `LAMMPS website <https://www.lammps.org/movies.html>`_.
 
-There are two kinds of sub-directories in the examples folder.  Lower
+There are two kinds of subdirectories in the examples folder.  Lower
 case named directories contain one or a few simple, quick-to-run
 problems.  Upper case named directories contain up to several complex
 scripts that illustrate a particular kind of simulation method or
@@ -221,10 +221,10 @@ Uppercase directories
 Nearly all of these directories have README files which give more
 details on how to understand and use their contents.
 
-The PACKAGES directory has a large number of sub-directories which
+The PACKAGES directory has a large number of subdirectories which
 correspond by name to specific packages.  They contain scripts that
 illustrate how to use the command(s) provided in those packages.  Many
-of the sub-directories have their own README files which give further
+of the subdirectories have their own README files which give further
 instructions.  See the :doc:`Packages_details <Packages_details>` doc
 page for more info on specific packages.
 

doc/src/Fortran.rst

@@ -47,7 +47,8 @@ Fortran code in order to uses the Fortran interface.
 A working example can be found together with equivalent examples in C and
 C++ in the ``examples/COUPLE/simple`` folder of the LAMMPS distribution.
 
-.. admonitions:: Fortran compiler compatibility
+.. admonition:: Fortran compiler compatibility
+   :class: note
 
    A fully Fortran 2003 compatible Fortran compiler is required.
    This means that currently only GNU Fortran 9 and later are

doc/src/Howto_2d.rst

@@ -22,7 +22,7 @@ atom in the file, assign a z coordinate so it falls inside the
 z-boundaries of the box - e.g. 0.0.
 
 Use the :doc:`fix enforce2d <fix_enforce2d>` command as the last
-defined fix to insure that the z-components of velocities and forces
+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.
 

doc/src/Howto_cmake.rst

@@ -89,7 +89,7 @@ different options (``build-parallel``, ``build-serial``) or with
 different compilers (``build-gnu``, ``build-clang``, ``build-intel``)
 and so on.  All the auxiliary files created by one build process
 (executable, object files, log files, etc) are stored in this directory
-or sub-directories within it that CMake creates.
+or subdirectories within it that CMake creates.
 
 
 Running CMake

doc/src/Howto_coreshell.rst

@@ -111,7 +111,7 @@ Therefore it is typically desirable to decouple the relative motion of
 the core/shell pair, which is an imaginary degree of freedom, from the
 real physical system.  To do that, the :doc:`compute temp/cs <compute_temp_cs>` command can be used, in conjunction with
 any of the thermostat fixes, such as :doc:`fix nvt <fix_nh>` or :doc:`fix langevin <fix_langevin>`.  This compute uses the center-of-mass velocity
-of the core/shell pairs to calculate a temperature, and insures that
+of the core/shell pairs to calculate a temperature, and ensures that
 velocity is what is rescaled for thermostatting purposes.  This
 compute also works for a system with both core/shell pairs and
 non-polarized ions (ions without an attached satellite particle).  The

doc/src/Howto_github.rst

@@ -315,7 +315,7 @@ add changes. Please watch the comments to the pull requests. The two
 "test" labels are used to trigger extended tests before the code is
 merged. This is sometimes done by LAMMPS developers, if they suspect
 that there may be some subtle side effects from your changes. It is not
-done by default, because those tests are very time consuming.  The
+done by default, because those tests are very time-consuming.  The
 *ready_for_merge* label is usually attached when the LAMMPS developer
 assigned to the pull request considers this request complete and to
 trigger a final full test evaluation.

doc/src/Howto_grid.rst

@@ -11,7 +11,7 @@ more values (data).
 
 The grid cells and data they store are distributed across processors.
 Each processor owns the grid cells (and data) whose center points lie
-within the spatial sub-domain of the processor.  If needed for its
+within the spatial subdomain of the processor.  If needed for its
 computations, a processor may also store ghost grid cells with their
 data.
 
@@ -28,7 +28,7 @@ box size, as set by the :doc:`boundary <boundary>` command for fixed
 or shrink-wrapped boundaries.
 
 If load-balancing is invoked by the :doc:`balance <balance>` or
-:doc:`fix balance <fix_balance>` commands, then the sub-domain owned
+:doc:`fix balance <fix_balance>` commands, then the subdomain owned
 by a processor can change which may also change which grid cells they
 own.
 

doc/src/Howto_output.rst

@@ -26,7 +26,7 @@ discussion, note that users can also :doc:`add their own computes and
 fixes to LAMMPS <Modify>` which can then generate values that can then
 be output with these commands.
 
-The following sub-sections discuss different LAMMPS commands related
+The following subsections discuss different LAMMPS commands related
 to output and the kind of data they operate on and produce:
 
 * :ref:`Global/per-atom/local/per-grid data <global>`
@@ -59,7 +59,7 @@ of bond distances.
 A per-grid datum is one or more values per grid cell, for a grid which
 overlays the simulation domain.  The grid cells and the data they
 store are distributed across processors; each processor owns the grid
-cells whose center point falls within its sub-domain.
+cells whose center point falls within its subdomain.
 
 .. _scalar:
 
@@ -322,7 +322,7 @@ The chief difference between the :doc:`fix ave/grid <fix_ave_grid>`
 and :doc:`fix ave/chunk <fix_ave_chunk>` commands when used in this
 context is that the former uses a distributed grid, while the latter
 uses a global grid.  Distributed means that each processor owns the
-subset of grid cells within its sub-domain.  Global means that each
+subset of grid cells within its subdomain.  Global means that each
 processor owns a copy of the entire grid.  The :doc:`fix ave/grid
 <fix_ave_grid>` command is thus more efficient for large grids.
 

doc/src/Howto_peri.rst

@@ -783,19 +783,19 @@ Pitfalls
 **Parallel Scalability**
 
 LAMMPS operates in parallel in a :doc:`spatial-decomposition mode
-<Developer_par_part>`, where each processor owns a spatial sub-domain of
+<Developer_par_part>`, where each processor owns a spatial subdomain of
 the overall simulation domain and communicates with its neighboring
 processors via distributed-memory message passing (MPI) to acquire ghost
 atom information to allow forces on the atoms it owns to be
 computed. LAMMPS also uses Verlet neighbor lists which are recomputed
 every few timesteps as particles move. On these timesteps, particles
 also migrate to new processors as needed. LAMMPS decomposes the overall
-simulation domain so that spatial sub-domains of nearly equal volume are
+simulation domain so that spatial subdomains of nearly equal volume are
-assigned to each processor. When each sub-domain contains nearly the
+assigned to each processor. When each subdomain contains nearly the
 same number of particles, this results in a reasonable load balance
 among all processors. As is more typical with some peridynamic
-simulations, some sub-domains may contain many particles while other
+simulations, some subdomains may contain many particles while other
-sub-domains contain few particles, resulting in a load imbalance that
+subdomains contain few particles, resulting in a load imbalance that
 impacts parallel scalability.
 
 **Setting the "skin" distance**

doc/src/Howto_pylammps.rst

@@ -392,7 +392,7 @@ IPyLammps Examples
 ------------------
 
 Examples of IPython notebooks can be found in the python/examples/pylammps
-sub-directory. To open these notebooks launch *jupyter notebook* inside this
+subdirectory. To open these notebooks launch *jupyter notebook* inside this
 directory and navigate to one of them. If you compiled and installed
 a LAMMPS shared library with exceptions, PNG, JPEG and FFMPEG support
 you should be able to rerun all of these notebooks.

doc/src/Howto_spherical.rst

@@ -93,7 +93,7 @@ Some of the pair styles used to compute pairwise interactions between
 finite-size particles also compute the correct interaction with point
 particles as well, e.g. the interaction between a point particle and a
 finite-size particle or between two point particles.  If necessary,
-:doc:`pair_style hybrid <pair_hybrid>` can be used to insure the correct
+:doc:`pair_style hybrid <pair_hybrid>` can be used to ensure the correct
 interactions are computed for the appropriate style of interactions.
 Likewise, using groups to partition particles (ellipsoids versus
 spheres versus point particles) will allow you to use the appropriate

doc/src/Howto_triclinic.rst

@@ -150,7 +150,7 @@ 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 sub-domain.
+acquire ghost atoms around a processor's irregular-shaped subdomain.
 For extreme values of tilt, LAMMPS may also lose atoms and generate an
 error.
 

doc/src/Install.rst

@@ -18,6 +18,8 @@ you **must** build LAMMPS from the source code.
    developers have no control over their choices of how they configure
    and build their packages and when they update them.
 
+----
+
 .. toctree::
    :maxdepth: 1
 
@@ -29,38 +31,40 @@ you **must** build LAMMPS from the source code.
    Install_tarball
    Install_git
 
-These are the files and sub-directories in the LAMMPS distribution:
+----
 
-+------------+-------------------------------------------+
+These are the files and subdirectories in the LAMMPS distribution:
-| README     | Short description of the LAMMPS package   |
-+------------+-------------------------------------------+
-| LICENSE    | GNU General Public License (GPL)          |
-+------------+-------------------------------------------+
-| SECURITY.md| Security Policy for the LAMMPS package    |
-+------------+-------------------------------------------+
-| bench      | benchmark problems                        |
-+------------+-------------------------------------------+
-| cmake      | CMake build files                         |
-+------------+-------------------------------------------+
-| doc        | documentation                             |
-+------------+-------------------------------------------+
-| examples   | simple test problems                      |
-+------------+-------------------------------------------+
-| fortran    | Fortran wrapper for LAMMPS                |
-+------------+-------------------------------------------+
-| lib        | additional provided or external libraries |
-+------------+-------------------------------------------+
-| potentials | interatomic potential files               |
-+------------+-------------------------------------------+
-| python     | Python wrappers for LAMMPS                |
-+------------+-------------------------------------------+
-| src        | source files                              |
-+------------+-------------------------------------------+
-| tools      | pre- and post-processing tools            |
-+------------+-------------------------------------------+
-| unittest   | sources and inputs for testing LAMMPS     |
-+------------+-------------------------------------------+
 
-You will have all of these if you download source.  You will only have
++------------+---------------------------------------------+
-some of them if you download executables, as explained on the pages
+| README     | Short description of the LAMMPS package     |
-listed above.
++------------+---------------------------------------------+
+| LICENSE    | GNU General Public License (GPL)            |
++------------+---------------------------------------------+
+| SECURITY.md| Security policy for the LAMMPS package      |
++------------+---------------------------------------------+
+| bench      | benchmark inputs                            |
++------------+---------------------------------------------+
+| cmake      | CMake build files                           |
++------------+---------------------------------------------+
+| doc        | documentation and tools to build the manual |
++------------+---------------------------------------------+
+| examples   | example input files                         |
++------------+---------------------------------------------+
+| fortran    | Fortran module for LAMMPS library interface |
++------------+---------------------------------------------+
+| lib        | additional provided or external libraries   |
++------------+---------------------------------------------+
+| potentials | selected interatomic potential files        |
++------------+---------------------------------------------+
+| python     | Python module for LAMMPS library interface  |
++------------+---------------------------------------------+
+| src        | LAMMPS source files                         |
++------------+---------------------------------------------+
+| tools      | pre- and post-processing tools              |
++------------+---------------------------------------------+
+| unittest   | source code and inputs for testing LAMMPS   |
++------------+---------------------------------------------+
+
+You will have all of these if you downloaded the LAMMPS source code.
+You will have only some of them if you downloaded executables, as
+explained on the pages listed above.

doc/src/Install_conda.rst

@@ -1,10 +1,10 @@
 Download an executable for Linux or Mac via Conda
 -------------------------------------------------
 
-Pre-compiled LAMMPS binaries are available for macOS or Linux via the
+Pre-compiled LAMMPS binaries are available for macOS and Linux via the
 `Conda <conda_>`_ package management system.
 
-First, one must setup the Conda package manager on your system.  Follow the
+First, one must set up the Conda package manager on your system.  Follow the
 instructions to install `Miniconda <mini_conda_install_>`_, then create a conda
 environment (named `my-lammps-env` or whatever you prefer) for your LAMMPS
 install:
@@ -21,19 +21,19 @@ Then, you can install LAMMPS on your system with the following command:
    conda activate my-lammps-env
    conda install lammps
 
-The LAMMPS binary is built with the :ref:`KIM package <kim>` which
+The LAMMPS binary is built with the :ref:`KIM package <kim>`, which
 results in Conda also installing the `kim-api` binaries when LAMMPS is
-installed.  In order to use potentials from `openkim.org <openkim_>`_, you can
+installed.  In order to use potentials from `openkim.org <openkim_>`_,
-install the `openkim-models` package
+you can install the `openkim-models` package
 
 .. code-block:: bash
 
    conda install openkim-models
 
-If you have problems with the installation you can post issues to
+If you have problems with the installation, you can post issues to `this
-`this link <conda_forge_lammps_>`_.
+link <conda_forge_lammps_>`_.  Thanks to Jan Janssen
-Thanks to Jan Janssen (Max-Planck-Institut fuer Eisenforschung) for setting
+(Max-Planck-Institut fuer Eisenforschung) for setting up the Conda
-up the Conda capability.
+capability.
 
 .. _conda_forge_lammps: https://github.com/conda-forge/lammps-feedstock/issues
 .. _openkim: https://openkim.org

doc/src/Install_git.rst

@@ -1,16 +1,16 @@
 Download the LAMMPS source with git
 -----------------------------------
 
-All LAMMPS development is coordinated through the "LAMMPS GitHub
+LAMMPS development is coordinated through the "LAMMPS GitHub site".
-site".  If you clone the LAMMPS repository onto your local machine, it
+If you clone the LAMMPS repository onto your local machine, it has
-has several advantages:
+several advantages:
 
 * You can stay current with changes to LAMMPS with a single git
   command.
 * You can create your own development branches to add code to LAMMPS.
 * You can submit your new features back to GitHub for inclusion in
-  LAMMPS.  For that you should first create your own :doc:`fork on
+  LAMMPS.  For that, you should first create your own :doc:`fork on
-  GitHub <Howto_github>`.
+  GitHub <Howto_github>`, though.
 
 You must have `git <git_>`_ installed on your system to use the
 commands explained below to communicate with the git servers on
@@ -31,8 +31,8 @@ You can follow the LAMMPS development on 3 different git branches:
 * **stable**   :  this branch is updated from the *release* branch with
   every stable release version and also has selected bug fixes and updates
   back-ported from the *develop* branch
-* **release**  :  this branch is updated with every patch release;
+* **release**  :  this branch is updated with every patch or feature release;
-  updates are always "fast forward" merges from *develop*
+  updates are always "fast-forward" merges from *develop*
 * **develop**  :  this branch follows the ongoing development and
   is updated with every merge commit of a pull request
 
@@ -58,12 +58,12 @@ between them at any time using "git checkout <branch name>".)
    commit history (most people don't), you can speed up the "cloning"
    process and reduce local disk space requirements by using the
    *--depth* git command line flag.  That will create a "shallow clone"
-   of the repository containing only a subset of the git history.  Using
+   of the repository, which contains only a subset of the git history.
-   a depth of 1000 is usually sufficient to include the head commits of
+   Using a depth of 1000 is usually sufficient to include the head
-   the *develop* and the *release* branches.  To include the head commit
+   commits of the *develop* and the *release* branches.  To include the
-   of the *stable* branch you may need a depth of up to 10000.  If you
+   head commit of the *stable* branch you may need a depth of up
-   later need more of the git history, you can always convert the
+   to 10000.  If you later need more of the git history, you can always
-   shallow clone into a "full clone".
+   convert the shallow clone into a "full clone".
 
 Once the command completes, your directory will contain the same files
 as if you unpacked a current LAMMPS tarball, with the exception, that
@@ -84,11 +84,11 @@ from within the "mylammps" directory:
    git pull
 
 Doing a "pull" will not change any files you have added to the LAMMPS
-directory structure.  It will also not change any existing LAMMPS
+directory structure.  It will also not change any existing LAMMPS files
-files you have edited, unless those files have changed in the
+you have edited, unless those files have changed in the repository.  In
-repository.  In that case, git will attempt to merge the new
+that case, git will attempt to merge the changes from the repository
-repository file with your version of the file and tell you if there
+file with your version of the file and tell you if there are any
-are any conflicts.  See the git documentation for details.
+conflicts.  See the git documentation for details.
 
 If you want to access a particular previous release version of LAMMPS,
 you can instead "check out" any version with a published tag. See the
@@ -146,13 +146,13 @@ changed.  How to do this depends on the build system you are using.
       and package directories.  This is OK to do even if you don't
       use any packages. The ``make purge`` command removes any deprecated
       src files if they were removed by the patch from a package
-      sub-directory.
+      subdirectory.
 
       .. warning::
 
          If you wish to edit/change a src file that is from a package,
          you should edit the version of the file inside the package
-         sub-directory with src, then re-install the package.  The
+         subdirectory with src, then re-install the package.  The
          version in the source directory is merely a copy and will be
          wiped out if you type "make package-update".
 
@@ -164,5 +164,5 @@ changed.  How to do this depends on the build system you are using.
    GitHub account, you may also use SSH protocol with the URL
    "git@github.com:lammps/lammps.git".
 
-The LAMMPS GitHub project is currently managed by Axel Kohlmeyer
+The LAMMPS GitHub project is currently overseen by Axel Kohlmeyer
 (Temple U, akohlmey at gmail.com).

doc/src/Install_linux.rst

@@ -3,7 +3,7 @@ Download an executable for Linux
 
 Binaries are available for different versions of Linux:
 
-- :ref:`Pre-built Ubuntu Linux executables <ubuntu>`
+- :ref:`Pre-built Ubuntu and Debian Linux executables <ubuntu>`
 - :ref:`Pre-built Fedora Linux executables <fedora>`
 - :ref:`Pre-built EPEL Linux executables (RHEL, CentOS) <epel>`
 - :ref:`Pre-built OpenSuse Linux executables <opensuse>`
@@ -14,21 +14,23 @@ Binaries are available for different versions of Linux:
 
    If you have questions about these pre-compiled LAMMPS executables,
    you need to contact the people preparing those packages.  The LAMMPS
-   developers have no control over their choices of how they configure
+   developers have no control over how they configure and build their
-   and build their packages and when they update them.
+   packages and when they update them.  They may only provide packages
+   for stable release versions and not always update the packages in a
+   timely fashion after a new LAMMPS release is made.
 
 ----------
 
 .. _ubuntu:
 
-Pre-built Ubuntu Linux executables
+Pre-built Ubuntu and Debian Linux executables
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-A pre-built LAMMPS executable suitable for running on the latest Ubuntu
+A pre-built LAMMPS executable, suitable for running on the latest Ubuntu
-Linux versions, can be downloaded as a Debian package.  This allows you
+and Debian Linux versions, can be downloaded as a Debian package.  This
-to install LAMMPS with a single command, and stay (mostly) up-to-date
+allows you to install LAMMPS with a single command, and stay (mostly)
-with the current stable version of LAMMPS by simply updating your
+up-to-date with the current stable version of LAMMPS by simply updating
-operating system.
+your operating system.
 
 To install LAMMPS do the following once:
 
@@ -38,8 +40,22 @@ To install LAMMPS do the following once:
 
 This downloads an executable named ``lmp`` to your box and multiple
 packages with supporting data, examples and libraries as well as any
-missing dependencies.  This executable can then be used in the usual way
+missing dependencies.  For example, the LAMMPS binary in this package is
-to run input scripts:
+built with the :ref:`KIM package <kim>` enabled, which results in the
+above command also installing the ``kim-api`` binaries when LAMMPS is
+installed, unless they were installed already.  In order to use
+potentials from `openkim.org <openkim_>`_, you can also install the
+``openkim-models`` package:
+
+.. code-block:: bash
+
+   sudo apt-get install openkim-models
+
+Or use the `KIM-API commands <https://openkim.org/doc/usage/obtaining-models/#installing_api>`_
+to download and install individual models.
+
+This LAMMPS executable can then be used in the usual way to run input
+scripts:
 
 .. code-block:: bash
 
@@ -51,20 +67,9 @@ To update LAMMPS to the latest packaged version, do the following:
 
    sudo apt-get update
 
-which will also update other packages on your system.
+This will also update other packages on your system.
 
-The ``lmp`` binary is built with the :ref:`KIM package <kim>` included,
+To uninstall LAMMPS, do the following:
-which results in the above command also installing the ``kim-api``
-binaries when LAMMPS is installed.  In order to use potentials from
-`openkim.org <openkim_>`_, you can also install the ``openkim-models``
-package
-
-.. code-block:: bash
-
-   sudo apt-get install openkim-models
-
-Or use the KIM-API commands to download and install individual models.
-To un-install LAMMPS, do the following:
 
 .. code-block:: bash
 
@@ -83,8 +88,9 @@ Ubuntu package capability.
 Pre-built Fedora Linux executables
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Pre-built LAMMPS packages for stable releases are available in the
+Pre-built `LAMMPS packages for stable releases
-Fedora Linux distribution as of Fedora version 28. The packages can be
+<https://packages.fedoraproject.org/pkgs/lammps/>`_ are available in the
+Fedora Linux distribution since Fedora version 28. The packages can be
 installed via the dnf package manager. There are 3 basic varieties
 (lammps = no MPI, lammps-mpich = MPICH MPI library, lammps-openmpi =
 OpenMPI MPI library) and for each support for linking to the C library
@@ -107,9 +113,9 @@ To install LAMMPS with OpenMPI and run an input ``in.lj`` with 2 CPUs do:
    module load mpi/openmpi-x86_64
    mpirun -np 2 lmp -in in.lj
 
-The ``dnf install`` command is needed only once. In case of a new LAMMPS
+The ``dnf install`` command is needed only once.  In case of a new LAMMPS
 stable release, ``dnf update`` will automatically update to the newer
-version as soon at the RPM files are built and uploaded to the download
+version as soon as the RPM files are built and uploaded to the download
 mirrors. The ``module load`` command is needed once per (shell) session
 or shell terminal instance, unless it is automatically loaded from the
 shell profile.
@@ -165,7 +171,7 @@ in OpenSuse as of Leap 15.0. You can install the package with:
    zypper install lammps
 
 This includes support for OpenMPI. The name of the LAMMPS executable
-is ``lmp``. Thus to run an input in parallel on 2 CPUs you would do:
+is ``lmp``. To run an input in parallel on 2 CPUs you would do:
 
 .. code-block:: bash
 
@@ -192,17 +198,18 @@ Thanks to Christoph Junghans (LANL) for making LAMMPS available in OpenSuse.
 Gentoo Linux executable
 ^^^^^^^^^^^^^^^^^^^^^^^
 
-LAMMPS is part of Gentoo's main package tree and can be installed by
+LAMMPS is part of `Gentoo's main package tree
-typing:
+<https://packages.gentoo.org/packages/sci-physics/lammps>`_ and can be
+installed by typing:
 
 .. code-block:: bash
 
    emerge --ask lammps
 
-Note that in Gentoo the LAMMPS source is downloaded and the package is
+Note that in Gentoo the LAMMPS source code is downloaded and the package is
-built on the your machine.
+then compiled and installed on your machine.
 
-Certain LAMMPS packages can be enable via USE flags, type
+Certain LAMMPS packages can be enabled via USE flags, type
 
 .. code-block:: bash
 
@@ -221,8 +228,11 @@ Archlinux build-script
 ^^^^^^^^^^^^^^^^^^^^^^
 
 LAMMPS is available via Arch's unofficial Arch User repository (AUR).
-There are three scripts available, named lammps, lammps-beta and lammps-git.
+There are three scripts available, named `lammps
-They respectively package the stable, patch and git releases.
+<https://aur.archlinux.org/packages/lammps>`_, `lammps-beta
+<https://aur.archlinux.org/packages/lammps>`_ and `lammps-git
+<https://aur.archlinux.org/packages/lammps>`_.  They respectively
+package the stable, patch and git releases.
 
 To install, you will need to have the git package installed. You may use
 any of the above names in-place of lammps.
@@ -234,9 +244,9 @@ any of the above names in-place of lammps.
    makepkg -s
    makepkg -i
 
-To update, you may repeat the above, or change into the cloned directory,
+To update LAMMPS, you may repeat the above, or change into the cloned
-and execute the following, after which, if there are any changes, you may
+directory, and execute the following, after which, if there are any
-use makepkg as above.
+changes, you may use makepkg as above.
 
 .. code-block:: bash
 
@@ -244,12 +254,5 @@ use makepkg as above.
 
 Alternatively, you may use an AUR helper to install these packages.
 
-Note that the AUR provides build-scripts that download the source and
+Note that the AUR provides build-scripts that download the source code
-the build the package on your machine.
+and then build and install the package on your machine.
-
-.. note::
-
-   It looks like the Arch Linux AUR repository build scripts for LAMMPS
-   have not been updated since the 29 October 2020 version.  You may want
-   to consider installing a more current version of LAMMPS from source
-   directly.

doc/src/Install_mac.rst

@@ -2,10 +2,11 @@ Download an executable for Mac
 ------------------------------
 
 LAMMPS can be downloaded, built, and configured for OS X on a Mac with
-`Homebrew <homebrew_>`_.  (Alternatively, see the install instructions for
+`Homebrew <homebrew_>`_.  (Alternatively, see the installation
-:doc:`Download an executable via Conda <Install_conda>`.)  The following LAMMPS
+instructions for :doc:`downloading an executable via Conda
-packages are unavailable at this time because of additional needs not yet met:
+<Install_conda>`.)  The following LAMMPS packages are unavailable at
-GPU, KOKKOS, LATTE, MSCG, MPIIO, POEMS, VORONOI.
+this time because of additional requirements not yet met: GPU, KOKKOS,
+LATTE, MSCG, MPIIO, POEMS, VORONOI.
 
 After installing Homebrew, you can install LAMMPS on your system with
 the following commands:
@@ -24,16 +25,16 @@ Lennard-Jones benchmark file:
 
    brew test lammps -v
 
-The LAMMPS binary is built with the :ref:`KIM package <kim>` which
+The LAMMPS binary is built with the :ref:`KIM package <kim>`, which
-results in Homebrew also installing the `kim-api` binaries when LAMMPS is
+results in Homebrew also installing the `kim-api` binaries when LAMMPS
-installed.  In order to use potentials from `openkim.org <openkim_>`_, you can
+is installed.  In order to use potentials from `openkim.org
-install the `openkim-models` package
+<openkim_>`_, you can install the `openkim-models` package
 
 .. code-block:: bash
 
    brew install openkim-models
 
-If you have problems with the installation you can post issues to
+If you have problems with the installation, you can post issues to
 `this link <https://github.com/Homebrew/homebrew-core/issues>`_.
 
 .. _homebrew: https://brew.sh

doc/src/Install_tarball.rst

@@ -9,17 +9,19 @@ of the `LAMMPS website <lws_>`_.
 .. _older: https://download.lammps.org/tars/
 .. _lws: https://www.lammps.org
 
-You have two choices of tarballs, either the most recent stable
+You have two choices of tarballs, either the most recent stable release
-release or the most current patch release.  Stable releases occur a
+or the most current patch or feature release.  Stable releases occur a
-few times per year, and undergo more testing before release.  Patch
+few times per year, and undergo more testing before release.  Feature
-releases occur a couple times per month.  The new contents in all
+releases occur every 4 to 8 weeks.  The new contents in all feature
-releases are listed on the `bug and feature page <bug_>`_ of the website.
+releases are listed on the `bug and feature page <bug_>`_ of the LAMMPS
+homepage.
 
 Both tarballs include LAMMPS documentation (HTML and PDF files)
 corresponding to that version.  The download page also has an option
 to download the current-version LAMMPS documentation by itself.
 
-Older versions of LAMMPS can also be downloaded from `this page <older_>`_.
+Tarballs of older LAMMPS versions can also be downloaded from `this page
+<older_>`_.
 
 Once you have a tarball, unzip and untar it with the following
 command:
@@ -36,14 +38,13 @@ in its name, e.g. lammps-23Jun18.
 You can also download a compressed tar or zip archives from the
 "Assets" sections of the `LAMMPS GitHub releases site <git_>`_.
 The file name will be lammps-<version>.zip which can be unzipped
-with the following command, to create a lammps-<version> dir:
+with the following command, to create a lammps-<version> directory:
 
 .. code-block:: bash
 
    unzip lammps*.zip
 
-This version corresponds to the selected LAMMPS patch or stable
+This version corresponds to the selected LAMMPS patch or stable release.
-release.
 
 .. _git: https://github.com/lammps/lammps/releases
 

doc/src/Install_windows.rst

@@ -33,7 +33,7 @@ Windows, once it is installed, in both serial and parallel.
 When you download the installer package, you run it on your Windows
 machine.  It will then prompt you with a dialog, where you can choose
 the installation directory, unpack and copy several executables,
-potential files, documentation pdfs, selected example files, etc.  It
+potential files, documentation PDFs, selected example files, etc.  It
 will then update a few system settings (e.g. PATH, LAMMPS_POTENTIALS)
 and add an entry into the Start Menu (with references to the
 documentation, LAMMPS homepage and more).  From that menu, there is
@@ -41,10 +41,10 @@ also a link to an uninstaller that removes the files and undoes the
 environment manipulations.
 
 Note that to update to a newer version of LAMMPS, you should typically
-uninstall the version you currently have, download a new installer,
+uninstall the version you currently have, download a new installer, and
-and go through the install procedure described above.  I.e. the same
+go through the installation procedure described above.  I.e. the same
 procedure for installing/updating most Windows programs.  You can
-install multiple versions of LAMMPS (in different directories), but
+install multiple versions of LAMMPS (in different directories), but only
-only the executable for the last-installed package will be found
+the executable for the last-installed package will be found
 automatically, so this should only be done for debugging purposes.
 

doc/src/Intro.rst

@@ -10,6 +10,7 @@ These pages provide a brief introduction to LAMMPS.
    Manual_version
    Intro_features
    Intro_nonfeatures
+   Intro_portability
    Intro_opensource
    Intro_authors
    Intro_citing

doc/src/Intro_authors.rst

@@ -7,7 +7,7 @@ University:
 * `Steve Plimpton <sjp_>`_, sjplimp at gmail.com
 * Aidan Thompson, athomps at sandia.gov
 * Stan Moore, stamoor at sandia.gov
-* Axel Kohlmeyer, akohlmey at gmail.com
+* `Axel Kohlmeyer <https://sites.google.com/site/akohlmey/>`_, akohlmey at gmail.com
 * Richard Berger, richard.berger at outlook.com
 
 .. _sjp: https://sjplimp.github.io
@@ -37,10 +37,10 @@ general-purpose as it is without their expertise and efforts.
 * Reese Jones (Sandia) and colleagues, ATC package for atom/continuum coupling
 * Christoph Kloss (DCS Computing), LIGGGHTS code for granular materials, built on top of LAMMPS
 * Rudra Mukherjee (JPL), POEMS package for articulated rigid body motion
-* Trung Ngyuen (Northwestern U), GPU, RIGID, BODY, and DIELECTRIC packages
+* Trung Ngyuen (U Chicago), GPU, RIGID, BODY, and DIELECTRIC packages
 * Mike Parks (Sandia), PERI package for Peridynamics
 * Roy Pollock (LLNL), Ewald and PPPM solvers
-* Julien Tranchida (Sandia), SPIN package
+* Julien Tranchida (CEA Cadarache), SPIN package
 * Christian Trott (Sandia), CUDA and KOKKOS packages
 * Ilya Valuev (JIHT), AWPMD package for wave packet MD
 * Greg Wagner (Northwestern U), MEAM package for MEAM potential

doc/src/Intro_citing.rst

@@ -38,11 +38,11 @@ to create digital object identifiers (DOI) for stable releases of the
 LAMMPS source code.  There are two types of DOIs for the LAMMPS source code.
 
 The canonical DOI for **all** versions of LAMMPS, which will always
-point to the **latest** stable release version is:
+point to the **latest** stable release version, is:
 
 - DOI: `10.5281/zenodo.3726416 <https://dx.doi.org/10.5281/zenodo.3726416>`_
 
-In addition there are DOIs for individual stable releases. Currently there are:
+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>`_
@@ -65,6 +65,6 @@ for optional features used in a specific run is printed to the screen
 and log file.  Style and output location can be selected with the
 :ref:`-cite command-line switch <cite>`.  Additional references are
 given in the documentation of the :doc:`corresponding commands
-<Commands_all>` or in the :doc:`Howto tutorials <Howto>`.  So please
+<Commands_all>` or in the :doc:`Howto tutorials <Howto>`.  Please make
-make certain, that you provide the proper acknowledgments and citations
+certain, that you provide the proper acknowledgments and citations in
-in any published works using LAMMPS.
+any published works using LAMMPS.

doc/src/Intro_features.rst

@@ -27,7 +27,7 @@ General features
 * distributed memory message-passing parallelism (MPI)
 * shared memory multi-threading parallelism (OpenMP)
 * spatial decomposition of simulation domain for MPI parallelism
-* particle decomposition inside of spatial decomposition for OpenMP and GPU parallelism
+* particle decomposition inside spatial decomposition for OpenMP and GPU parallelism
 * GPLv2 licensed open-source distribution
 * highly portable C++-11
 * modular code with most functionality in optional packages
@@ -39,8 +39,11 @@ General features
 * syntax for defining and using variables and formulas
 * syntax for looping over runs and breaking out of loops
 * run one or multiple simulations simultaneously (in parallel) from one script
-* build as library, invoke LAMMPS through library interface or provided Python wrapper or SWIG based wrappers
+* build as library, invoke LAMMPS through library interface (from C, C++, Fortran) or provided Python wrapper or SWIG based wrappers
-* couple with other codes: LAMMPS calls other code, other code calls LAMMPS, umbrella code calls both
+* couple with other codes: LAMMPS calls other code, other code calls LAMMPS, umbrella code calls both, MDI coupling interface
+* call out to Python for computing forces, time integration, or other tasks
+* plugin interface for loading external features at runtime
+* large integrated collection of tests
 
 .. _particle:
 
@@ -54,6 +57,7 @@ Particle and model types
 * united-atom polymers or organic molecules
 * all-atom polymers, organic molecules, proteins, DNA
 * metals
+* metal oxides
 * granular materials
 * coarse-grained mesoscale models
 * finite-size spherical and ellipsoidal particles
@@ -74,27 +78,28 @@ Interatomic potentials (force fields)
 :doc:`improper style <improper_style>`, :doc:`kspace style <kspace_style>`
 commands)
 
-* pairwise potentials: Lennard-Jones, Buckingham, Morse, Born-Mayer-Huggins, Yukawa, soft, class 2 (COMPASS), hydrogen bond, tabulated
+* 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 EAM, modified EAM (MEAM), embedded ion method (EIM), EDIP, ADP, Stillinger-Weber, Tersoff, REBO, AIREBO, ReaxFF, COMB, Streitz-Mintmire, 3-body polymorphic, BOP, Vashishta
+* 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: SNAP, GAP, ACE, N2P2, RANN, AGNI
+* machine learning potentials: ACE, AGNI, GAP, Behler-Parrinello (N2P2), POD, RANN
-* long-range interactions for charge, point-dipoles, and LJ dispersion:  Ewald, Wolf, PPPM (similar to particle-mesh Ewald), MSM
+* interfaces to ML potentials distributed by external groups: ANI, ChIMES, DeepPot, HIPNN, MTP
-* polarization models: :doc:`QEq <fix_qeq>`,     :doc:`core/shell model <Howto_coreshell>`,     :doc:`Drude dipole model <Howto_drude>`
+* 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>`
 * charge equilibration (QEq via dynamic, point, shielded, Slater methods)
-* coarse-grained potentials: DPD, GayBerne, REsquared, colloidal, DLVO
+* coarse-grained potentials: DPD, GayBerne, REsquared, colloidal, DLVO, oxDNA / oxRNA, SPICA
 * mesoscopic potentials: granular, Peridynamics, SPH, mesoscopic tubular potential (MESONT)
 * semi-empirical potentials: multi-ion generalized pseudopotential theory (MGPT), second moment tight binding + QEq (SMTB-Q), density functional tight-binding (LATTE)
 * electron force field (eFF, AWPMD)
-* bond potentials: harmonic, FENE, Morse, nonlinear, class 2, quartic (breakable), tabulated
+* bond potentials: harmonic, FENE, Morse, nonlinear, Class II (COMPASS), quartic (breakable), tabulated, scripted
-* angle potentials: harmonic, CHARMM, cosine, cosine/squared, cosine/periodic, class 2 (COMPASS), tabulated
+* angle potentials: harmonic, CHARMM, cosine, cosine/squared, cosine/periodic, Class II (COMPASS), tabulated, scripted
-* dihedral potentials: harmonic, CHARMM, multi-harmonic, helix, class 2 (COMPASS), OPLS, tabulated
+* dihedral potentials: harmonic, CHARMM, multi-harmonic, helix, Class II (COMPASS), OPLS, tabulated, scripted
-* improper potentials: harmonic, cvff, umbrella, class 2 (COMPASS), tabulated
+* improper potentials: harmonic, cvff, umbrella, Class II (COMPASS), tabulated
 * polymer potentials: all-atom, united-atom, bead-spring, breakable
 * water potentials: TIP3P, TIP4P, SPC, SPC/E and variants
-* interlayer potentials for graphene and analogues
+* interlayer potentials for graphene and analogues, hetero-junctions
 * metal-organic framework potentials (QuickFF, MO-FF)
 * implicit solvent potentials: hydrodynamic lubrication, Debye
-* force-field compatibility with common CHARMM, AMBER, DREIDING, OPLS, GROMACS, COMPASS options
+* force-field compatibility with CHARMM, AMBER, DREIDING, OPLS, GROMACS, Class II (COMPASS), UFF, ClayFF, DREIDING, AMOEBA, INTERFACE
 * access to the `OpenKIM Repository <https://openkim.org>`_ of potentials via the :doc:`kim command <kim_commands>`
 * hybrid potentials: multiple pair, bond, angle, dihedral, improper potentials can be used in one simulation
 * overlaid potentials: superposition of multiple pair potentials (including many-body) with optional scale factor
@@ -108,7 +113,7 @@ Atom creation
 :doc:`create_atoms <create_atoms>`, :doc:`delete_atoms <delete_atoms>`,
 :doc:`displace_atoms <displace_atoms>`, :doc:`replicate <replicate>` commands)
 
-* read in atom coords from files
+* read in atom coordinates from files
 * create atoms on one or more lattices (e.g. grain boundaries)
 * delete geometric or logical groups of atoms (e.g. voids)
 * replicate existing atoms multiple times
@@ -129,7 +134,7 @@ Ensembles, constraints, and boundary conditions
 * simulation box deformation (tensile and shear)
 * harmonic (umbrella) constraint forces
 * rigid body constraints
-* SHAKE bond and angle constraints
+* SHAKE / RATTLE bond and angle constraints
 * motion constraints to manifold surfaces
 * Monte Carlo bond breaking, formation, swapping, template based reaction modeling
 * atom/molecule insertion and deletion
@@ -147,8 +152,9 @@ Integrators
 * velocity-Verlet integrator
 * Brownian dynamics
 * rigid body integration
-* energy minimization via conjugate gradient or steepest descent relaxation
+* energy minimization via conjugate gradient, steepest descent relaxation, or damped dynamics (FIRE, Quickmin)
 * rRESPA hierarchical timestepping
+* fixed or adaptive time step
 * rerun command for post-processing of dump files
 
 .. _diag:
@@ -167,15 +173,17 @@ Output
 (:doc:`dump <dump>`, :doc:`restart <restart>` commands)
 
 * log file of thermodynamic info
-* text dump files of atom coords, velocities, other per-atom quantities
+* text dump files of atom coordinates, velocities, other per-atom quantities
+* dump output on fixed and variable intervals, based timestep or simulated time
 * binary restart files
 * parallel I/O of dump and restart files
-* per-atom quantities (energy, stress, centro-symmetry parameter, CNA, etc)
+* per-atom quantities (energy, stress, centro-symmetry parameter, CNA, etc.)
 * user-defined system-wide (log file) or per-atom (dump file) calculations
 * custom partitioning (chunks) for binning, and static or dynamic grouping of atoms for analysis
 * spatial, time, and per-chunk averaging of per-atom quantities
 * time averaging and histogramming of system-wide quantities
-* atom snapshots in native, XYZ, XTC, DCD, CFG formats
+* atom snapshots in native, XYZ, XTC, DCD, CFG, NetCDF, HDF5, ADIOS2, YAML formats
+* on-the-fly compression of output and decompression of read in files
 
 .. _replica1:
 
@@ -212,8 +220,8 @@ Pre- and post-processing
 Specialized features
 ^^^^^^^^^^^^^^^^^^^^
 
-LAMMPS can be built with optional packages which implement a variety
+LAMMPS can be built with optional packages which implement a variety of
-of additional capabilities.  See the :doc:`Optional Packages <Packages>`
+additional capabilities.  See the :doc:`Optional Packages <Packages>`
 page for details.
 
 These are LAMMPS capabilities which you may not think of as typical

doc/src/Intro_nonfeatures.rst

@@ -20,22 +20,23 @@ that either closely interface with LAMMPS or extend LAMMPS.
 
 Here are suggestions on how to perform these tasks:
 
-* **GUI:** LAMMPS can be built as a library and a Python wrapper that wraps
+* **GUI:** LAMMPS can be built as a library and a Python module that
-  the library interface is provided.  Thus, GUI interfaces can be
+  wraps the library interface is provided.  Thus, GUI interfaces can be
-  written in Python (or C or C++ if desired) that run LAMMPS and
+  written in Python or C/C++ that run LAMMPS and visualize or plot its
-  visualize or plot its output.  Examples of this are provided in the
+  output.  Examples of this are provided in the python directory and
-  python directory and described on the :doc:`Python <Python_head>` doc
+  described on the :doc:`Python <Python_head>` doc page.  Also, there
-  page.  Also, there are several external wrappers or GUI front ends.
+  are several external wrappers or GUI front ends.
-* **Builder:** Several pre-processing tools are packaged with LAMMPS.  Some
+* **Builder:** Several pre-processing tools are packaged with LAMMPS.
-  of them convert input files in formats produced by other MD codes such
+  Some of them convert input files in formats produced by other MD codes
-  as CHARMM, AMBER, or Insight into LAMMPS input formats.  Some of them
+  such as CHARMM, AMBER, or Insight into LAMMPS input formats.  Some of
-  are simple programs that will build simple molecular systems, such as
+  them are simple programs that will build simple molecular systems,
-  linear bead-spring polymer chains.  The moltemplate program is a true
+  such as linear bead-spring polymer chains.  The moltemplate program is
-  molecular builder that will generate complex molecular models.  See
+  a true molecular builder that will generate complex molecular models.
-  the :doc:`Tools <Tools>` page for details on tools packaged with
+  See the :doc:`Tools <Tools>` page for details on tools packaged with
-  LAMMPS.  The `Pre/post processing page <https:/www.lammps.org/prepost.html>`_ of the LAMMPS website
+  LAMMPS.  The `Pre-/post-processing page
+  <https:/www.lammps.org/prepost.html>`_ of the LAMMPS homepage
   describes a variety of third party tools for this task.  Furthermore,
-  some LAMMPS internal commands allow to reconstruct, or selectively add
+  some internal LAMMPS commands allow reconstructing, or selectively adding
   topology information, as well as provide the option to insert molecule
   templates instead of atoms for building bulk molecular systems.
 * **Force-field assignment:** The conversion tools described in the previous
@@ -47,33 +48,34 @@ Here are suggestions on how to perform these tasks:
   powerful and flexible in converting force field and topology data
   between various MD simulation programs.
 * **Simulation analysis:** If you want to perform analysis on-the-fly as
-  your simulation runs, see the :doc:`compute <compute>` and
+  your simulation runs, see the :doc:`compute <compute>` and :doc:`fix
-  :doc:`fix <fix>` doc pages, which list commands that can be used in a
+  <fix>` doc pages, which list commands that can be used in a LAMMPS
-  LAMMPS input script.  Also see the :doc:`Modify <Modify>` page for
+  input script.  Also see the :doc:`Modify <Modify>` page for info on
-  info on how to add your own analysis code or algorithms to LAMMPS.
+  how to add your own analysis code or algorithms to LAMMPS.  For
-  For post-processing, LAMMPS output such as :doc:`dump file snapshots <dump>` can be converted into formats used by other MD or
+  post-processing, LAMMPS output such as :doc:`dump file snapshots
+  <dump>` can be converted into formats used by other MD or
   post-processing codes.  To some degree, that conversion can be done
-  directly inside of LAMMPS by interfacing to the VMD molfile plugins.
+  directly inside LAMMPS by interfacing to the VMD molfile plugins.  The
-  The :doc:`rerun <rerun>` command also allows to do some post-processing
+  :doc:`rerun <rerun>` command also allows post-processing of existing
-  of existing trajectories, and through being able to read a variety
+  trajectories, and through being able to read a variety of file
-  of file formats, this can also be used for analyzing trajectories
+  formats, this can also be used for analyzing trajectories from other
-  from other MD codes.  Some post-processing tools packaged with
+  MD codes.  Some post-processing tools packaged with LAMMPS will do
-  LAMMPS will do these conversions.  Scripts provided in the
+  these conversions.  Scripts provided in the tools/python directory can
-  tools/python directory can extract and massage data in dump files to
+  extract and massage data in dump files to make it easier to import
-  make it easier to import into other programs.  See the
+  into other programs.  See the :doc:`Tools <Tools>` page for details on
-  :doc:`Tools <Tools>` page for details on these various options.
+  these various options.
-* **Visualization:** LAMMPS can produce NETPBM, JPG or PNG snapshot images
+* **Visualization:** LAMMPS can produce NETPBM, JPG, or PNG format
-  on-the-fly via its :doc:`dump image <dump_image>` command and pass
+  snapshot images on-the-fly via its :doc:`dump image <dump_image>`
-  them to an external program, `FFmpeg <https://www.ffmpeg.org>`_ to generate
+  command and pass them to an external program, `FFmpeg
-  movies from them.  For high-quality, interactive visualization there are
+  <https://www.ffmpeg.org>`_, to generate movies from them.  For
-  many excellent and free tools available.  See the
+  high-quality, interactive visualization, there are many excellent and
-  `Visualization Tools <https://www.lammps.org/viz.html>`_ page of the
+  free tools available.  See the `Visualization Tools
-  LAMMPS website for
+  <https://www.lammps.org/viz.html>`_ page of the LAMMPS website for
   visualization packages that can process LAMMPS output data.
 * **Plotting:** See the next bullet about Pizza.py as well as the
   :doc:`Python <Python_head>` page for examples of plotting LAMMPS
-  output.  Scripts provided with the *python* tool in the tools
+  output.  Scripts provided with the *python* tool in the ``tools``
-  directory will extract and massage data in log and dump files to make
+  directory will extract and process data in log and dump files to make
   it easier to analyze and plot.  See the :doc:`Tools <Tools>` doc page
   for more discussion of the various tools.
 * **Pizza.py:** Our group has also written a separate toolkit called

doc/src/Intro_overview.rst

@@ -1,20 +1,20 @@
 Overview of LAMMPS
 ------------------
 
-LAMMPS is a classical molecular dynamics (MD) code that models
+LAMMPS is a classical molecular dynamics (MD) code that models ensembles
-ensembles of particles in a liquid, solid, or gaseous state.  It can
+of particles in a liquid, solid, or gaseous state.  It can model atomic,
-model atomic, polymeric, biological, solid-state (metals, ceramics,
+polymeric, biological, solid-state (metals, ceramics, oxides), granular,
-oxides), granular, coarse-grained, or macroscopic systems using a
+coarse-grained, or macroscopic systems using a variety of interatomic
-variety of interatomic potentials (force fields) and boundary
+potentials (force fields) and boundary conditions.  It can model 2d or
-conditions.  It can model 2d or 3d systems with only a few particles
+3d systems with sizes ranging from only a few particles up to billions.
-up to millions or billions.
 
-LAMMPS can be built and run on a laptop or desktop machine, but is
+LAMMPS can be built and run on single laptop or desktop machines, but is
 designed for parallel computers.  It will run in serial and on any
 parallel machine that supports the `MPI <mpi_>`_ message-passing
-library.  This includes shared-memory boxes and distributed-memory
+library.  This includes shared-memory multicore, multi-CPU servers and
-clusters and supercomputers. Parts of LAMMPS also support
+distributed-memory clusters and supercomputers. Parts of LAMMPS also
-`OpenMP multi-threading <omp_>`_, vectorization and GPU acceleration.
+support `OpenMP multi-threading <omp_>`_, vectorization, and GPU
+acceleration.
 
 .. _mpi: https://en.wikipedia.org/wiki/Message_Passing_Interface
 .. _lws: https://www.lammps.org
@@ -29,25 +29,24 @@ versions can be downloaded as source code from the `LAMMPS website
 
 LAMMPS is designed to be easy to modify or extend with new capabilities,
 such as new force fields, atom types, boundary conditions, or
-diagnostics.  See the :doc:`Modify <Modify>` page for more details.
+diagnostics.  See the :doc:`Modify` section of for more details.
 
 In the most general sense, LAMMPS integrates Newton's equations of
-motion for a collection of interacting particles.  A single particle
+motion for a collection of interacting particles.  A single particle can
-can be an atom or molecule or electron, a coarse-grained cluster of
+be an atom or molecule or electron, a coarse-grained cluster of atoms,
-atoms, or a mesoscopic or macroscopic clump of material.  The
+or a mesoscopic or macroscopic clump of material.  The interaction
-interaction models that LAMMPS includes are mostly short-range in
+models that LAMMPS includes are mostly short-ranged in nature; some
-nature; some long-range models are included as well.
+long-range models are included as well.
 
-LAMMPS uses neighbor lists to keep track of nearby particles.  The
+LAMMPS uses neighbor lists to keep track of nearby particles.  The lists
-lists are optimized for systems with particles that are repulsive at
+are optimized for systems with particles that are repulsive at short
-short distances, so that the local density of particles never becomes
+distances, so that the local density of particles never becomes too
-too large.  This is in contrast to methods used for modeling plasma
+large.  This is in contrast to methods used for modeling plasma or
-or gravitational bodies (e.g. galaxy formation).
+gravitational bodies (like galaxy formation).
 
 On parallel machines, LAMMPS uses spatial-decomposition techniques with
-MPI parallelization to partition the simulation domain into small
+MPI parallelization to partition the simulation domain into subdomains
-sub-domains of equal computational cost, one of which is assigned to
+of equal computational cost, one of which is assigned to each processor.
-each processor.  Processors communicate and store "ghost" atom
+Processors communicate and store "ghost" atom information for atoms that
-information for atoms that border their sub-domain.  Multi-threading
+border their subdomain.  Multi-threading parallelization and GPU
-parallelization and GPU acceleration with with particle-decomposition
+acceleration with particle-decomposition can be used in addition.
-can be used in addition.

doc/src/Intro_portability.rst

@@ -0,0 +1,75 @@
+LAMMPS portability and compatibility
+------------------------------------
+
+The primary form of distributing LAMMPS is through highly portable
+source code.  But also several ways of obtaining LAMMPS as `precompiled
+packages or through automated build mechanisms <Install>` exist.  Most
+of LAMMPS is written in C++, some support tools are written in Fortran
+or Python or MATLAB.
+
+
+Programming language standards
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Most of the C++ code currently requires a compiler compatible with the
+C++11 standard, the KOKKOS package currently requires C++14.  Most of
+the Python code is written to be compatible with Python 3.5 or later or
+Python 2.7.  Some Python scripts *require* Python 3 and a few others
+still need to be ported from Python 2 to Python 3.
+
+
+Build systems
+^^^^^^^^^^^^^
+
+LAMMPS can be compiled from source code using a (traditional) build
+system based on shell scripts, a few shell utilities (grep, sed, cat,
+tr) and the GNU make program. This requires running within a Bourne
+shell (``/bin/sh``).  Alternatively, a build system with different back ends
+can be created using CMake.  CMake must be at least version 3.10.
+
+Operating systems
+^^^^^^^^^^^^^^^^^
+
+The primary development platform for LAMMPS is Linux.  Thus, the chances
+for LAMMPS to compile without problems on Linux machines are the best.
+Also, compilation and correct execution on macOS and Windows (using
+Microsoft Visual C++) is checked automatically for largest part of the
+source code.  Some (optional) features are not compatible with all
+operating systems, either through limitations of the corresponding
+LAMMPS source code or through source code or build system
+incompatibilities of required libraries.
+
+Executables for Windows may be created natively using either Cygwin or
+Visual Studio or with a Linux to Windows MinGW cross-compiler.
+
+Additionally, FreeBSD and Solaris have been tested successfully.
+
+Compilers
+^^^^^^^^^
+
+The most commonly used compilers are the GNU compilers, but also Clang
+and the Intel compilers have been successfully used on Linux, macOS, and
+Windows.  Also, the Nvidia HPC SDK (formerly PGI compilers) will compile
+LAMMPS (tested on Linux).
+
+CPU architectures
+^^^^^^^^^^^^^^^^^
+
+The primary CPU architecture for running LAMMPS is 64-bit x86, but also
+32-bit x86, and 64-bit ARM and PowerPC (64-bit, Little Endian) are
+regularly tested.
+
+Portability compliance
+^^^^^^^^^^^^^^^^^^^^^^
+
+Only a subset of the LAMMPS source code is fully compliant to all of the
+above mentioned standards.  This is rather typical for projects like
+LAMMPS that largely depend on contributions from the user community.
+Not all contributors are trained as programmers and not all of them have
+access to multiple platforms for testing.  As part of the continuous
+integration process, however, all contributions are automatically tested
+to compile, link, and pass some runtime tests on a selection of Linux
+flavors, macOS, and Windows, and on Linux with different compilers.
+Thus portability issues are often found before a pull request is merged.
+Other platforms may be checked occasionally or when portability bugs are
+reported.

doc/src/Intro_website.rst

@@ -7,20 +7,15 @@ available online are listed below.
 
 .. _lws: https://www.lammps.org
 
-* `Brief intro and recently added significant features <lws_>`_
+* `LAMMPS source code repository on GitHub <https://github.com/lammps/lammps>`_
-* `List of features <https://docs.lammps.org/Intro_features.html>`_
+* `LAMMPS forum on matsci.org <https://matsci.org/lammps/>`_
-* `List of non-features <https://docs.lammps.org/Intro_nonfeatures.html>`_
-* `Recent bug fixes and new features <https://www.lammps.org/bug.html>`_
 
+* `Recent bug fixes and new features <https://www.lammps.org/bug.html>`_
 * `Download info <https://www.lammps.org/download.html>`_
-* `GitHub site <https://github.com/lammps/lammps>`_
-* `SourceForge site <https://sourceforge.net/projects/lammps>`_
-* `LAMMPS open-source license <https://docs.lammps.org/Intro_opensource.html>`_
 
 * `Glossary of terms relevant to LAMMPS <https://www.lammps.org/glossary.html>`_
 * `LAMMPS highlights with images <https://www.lammps.org/pictures.html>`_
 * `LAMMPS highlights with movies <https://www.lammps.org/movies.html>`_
-* `LAMMPS forum <https://www.lammps.org/forum.html>`_
 * `Workshops <https://www.lammps.org/workshops.html>`_
 * `Tutorials <https://www.lammps.org/tutorials.html>`_
 

doc/src/Library_properties.rst

@@ -30,7 +30,7 @@ course, changing values should be done with care.  When accessing per-atom
 data, please note that these data are the per-processor **local** data and are
 indexed accordingly. Per-atom data can change sizes and ordering at
 every neighbor list rebuild or atom sort event as atoms migrate between
-sub-domains and processors.
+subdomains and processors.
 
 .. code-block:: c
 

doc/src/Manual.rst

@@ -5,16 +5,17 @@ LAMMPS Documentation (|version| version)
 LAMMPS stands for **L**\ arge-scale **A**\ tomic/**M**\ olecular
 **M**\ assively **P**\ arallel **S**\ imulator.
 
-LAMMPS is a classical molecular dynamics simulation code with a focus
+LAMMPS is a classical molecular dynamics simulation code focusing on
-on materials modeling.  It was designed to run efficiently on parallel
+materials modeling.  It was designed to run efficiently on parallel
-computers.  It was developed originally at Sandia National
+computers and to be easy to extend and modify.  Originally developed at
-Laboratories, a US Department of Energy facility.  The majority of
+Sandia National Laboratories, a US Department of Energy facility, LAMMPS
-funding for LAMMPS has come from the US Department of Energy (DOE).
+now includes contributions from many research groups and individuals
-LAMMPS is an open-source code, distributed freely under the terms of
+from many institutions.  Most of the funding for LAMMPS has come from
-the GNU Public License Version 2 (GPLv2).
+the US Department of Energy (DOE).  LAMMPS is open-source software
+distributed under the terms of the GNU Public License Version 2 (GPLv2).
 
 The `LAMMPS website <lws_>`_ has a variety of information about the
-code.  It includes links to an on-line version of this manual, an
+code.  It includes links to an online version of this manual, an
 `online forum <https://www.lammps.org/forum.html>`_ where users can post
 questions and discuss LAMMPS, and a `GitHub site
 <https://github.com/lammps/lammps>`_ where all LAMMPS development is
@@ -23,27 +24,33 @@ coordinated.
 ----------
 
 The content for this manual is part of the LAMMPS distribution.  The
-online version always corresponds to the latest development version.
+online version always corresponds to the latest feature release version.
-If needed, you can download or build a local copy of the manual as
+If needed, you can build a local copy of the manual as HTML pages or a
-HTML pages or a PDF file by following the steps on the
+PDF file by following the steps on the :doc:`Build_manual` page.  If you
-:doc:`Build_manual` page. If you have difficulties viewing the pages
+have difficulties viewing the pages, please :ref:`see this note
-please :ref:`see this note <webbrowser>`.
+<webbrowser>`.
 
 -----------
 
-The manual is organized in three parts:
+The manual is organized into three parts:
-1) the :ref:`User Guide <user_documentation>` for how to install
+
-and use LAMMPS, 2) the :ref:`Programmer Guide <programmer_documentation>`
+1. The :ref:`User Guide <user_documentation>` with information about how
-for how to write programs using the LAMMPS library from different
+   to obtain, configure, compile, install, and use LAMMPS,
-programming languages and how to modify and extend LAMMPS, and 3) the
+2. the :ref:`Programmer Guide <programmer_documentation>` with
-:ref:`Command Reference <command_reference>` which includes detailed
+   information about how to use the LAMMPS library interface from
-descriptions of all commands included in the LAMMPS code.
+   different programming languages, how to modify and extend LAMMPS,
+   the program design, internal programming interfaces, and code
+   design conventions,
+3. the :ref:`Command Reference <command_reference>` with detailed
+   descriptions of all input script commands available in LAMMPS.
+
+----------
 
 .. only:: html
 
-   Once you are familiar with LAMMPS, you may want to bookmark
+   After becoming familiar with LAMMPS, consider bookmarking
-   :doc:`this page <Commands_all>` since it gives quick access to
+   :doc:`this page <Commands_all>`, since it gives quick access to
-   the documentation for all LAMMPS commands.
+   tables with links to the documentation for all LAMMPS commands.
 
 .. _lws: https://www.lammps.org
 

doc/src/Manual_version.rst

@@ -2,39 +2,54 @@ What does a LAMMPS version mean
 -------------------------------
 
 The LAMMPS "version" is the date when it was released, such as 1 May
-2014.  LAMMPS is updated continuously and we aim to keep it working
+2014.  LAMMPS is updated continuously, and we aim to keep it working
 correctly and reliably at all times.  You can follow its development
 in a public `git repository on GitHub <https://github.com/lammps/lammps>`_.
 
-Whenever we fix a bug or update or add a feature, it will be merged into
+Modifications of the LAMMPS source code (like bug fixes, code refactors,
-the *develop* branch of the git repository.  When a sufficient number of
+updates to existing features, or addition of new features) are organized
-changes have accumulated *and* the software passes a set of automated
+into pull requests.  Pull requests will be merged into the *develop*
-tests, we release it in the next *patch* release, which are made every
+branch of the git repository after they pass automated testing and code
-few weeks.  The *release* branch of the git repository is updated with
+review by the LAMMPS developers.  When a sufficient number of changes
-every such release.  Info on patch releases are on `this website page
+have accumulated *and* the *develop* branch version passes an extended
-<https://www.lammps.org/bug.html>`_.
+set of automated tests, we release it as a *feature release* (or patch
+release), which are currently made every 4 to 8 weeks.  The *release*
+branch of the git repository is updated with every such release.  A
+summary of the most important changes of the patch releases are on `this
+website page <https://www.lammps.org/bug.html>`_.  More detailed release
+notes are `available on GitHub
+<https://github.com/lammps/lammps/releases/>`_.
 
-Once or twice a year, we apply only bug fixes and small, non-intrusive
+Once or twice a year, we have a "stabilization period" where we apply
-changes to the *develop* branch and the code is subjected to more detailed
+only bug fixes and small, non-intrusive changes to the *develop*
-and thorough testing than the default automated testing.  The latest
+branch.  At the same time, the code is subjected to more detailed and
-patch release after such a period is then also labeled as a *stable* version
+thorough manual testing than the default automated testing.  Also,
-and the *stable* branch is updated with it.  Between stable releases
+several variants of static code analysis are run to improve the overall
-we occasionally release some updates to the stable release containing
+code quality, consistency, and compliance with programming standards,
-only bug fixes and updates back-ported from *develop* but no new features
+best practices and style conventions.
-and update the *stable* branch accordingly.
+
+The latest patch release after such a period is then also labeled as a
+*stable* version and the *stable* branch is updated with it.  Between
+stable releases, we occasionally release updates to the stable release
+containing only bug fixes and updates back-ported from the *develop*
+branch and update the *stable* branch accordingly.
 
 Each version of LAMMPS contains all the documented features up to and
-including its version date.
+including its version date.  For recently added features, we add markers
+to the documentation at which specific LAMMPS version a feature or
+keyword was added or significantly changed.
 
-The version date is printed to the screen and logfile every time you
+The version date is printed to the screen and log file every time you run
-run LAMMPS. It is also in the file src/version.h and in the LAMMPS
+LAMMPS.  It is also in the file src/version.h and in the LAMMPS
 directory name created when you unpack a tarball.  And it is on the
 first page of the :doc:`manual <Manual>`.
 
-* If you browse the HTML pages on the LAMMPS WWW site, they will by
+* If you browse the HTML pages of the online version of the LAMMPS
-  default describe the most current patch release version of LAMMPS.
+  manual, they will by default describe the most current patch release
-  In the navigation bar on the bottom left, there is the option to
+  version of LAMMPS.  In the navigation bar on the bottom left, there is
-  view instead the documentation for the most recent *stable* version
+  the option to view instead the documentation for the most recent
-  or the latest version from the current development branch.
+  *stable* version or the documentation corresponding to the state of
-* If you browse the HTML pages included in your tarball, they
+  the development branch.
-  describe the version you have, which may be older.
+* If you browse the HTML pages included in your downloaded tarball, they
+  describe the version you have, which may be older than the online
+  version.

doc/src/Modify_overview.rst

@@ -59,14 +59,6 @@ the executable and can be invoked with a pair_style command like the
 example above.  Arguments like 0.1 and 3.5 can be defined and
 processed by your new class.
 
-.. note::
-
-   With the traditional make process, simply adding the new files to the
-   src folder and compiling LAMMPS again for the desired configuration
-   with "make machine" is sufficient.  When using CMake, you need to
-   re-run CMake with "cmake ." in the build folder to have it recognize
-   the added files and include them into the build system.
-
 As illustrated by this example pair style, many kinds of options are
 referred to in the LAMMPS documentation as the "style" of a particular
 command.

doc/src/Packages.rst

@@ -8,7 +8,7 @@ systems or rigid-body constraints are in packages.  You can see the
 list of all packages and "make" commands to manage them by typing
 "make package" from within the src directory of the LAMMPS
 distribution.  The :doc:`Build package <Build_package>` page gives
-general info on how to install and un-install packages as part of the
+general info on how to install and uninstall packages as part of the
 LAMMPS build process.
 
 .. toctree::

doc/src/Packages_details.rst

@@ -1621,25 +1621,23 @@ MESONT package
 **Contents:**
 
 MESONT is a LAMMPS package for simulation of nanomechanics of nanotubes
-(NTs). The model is based on a coarse-grained representation of NTs as
+(NTs).  The model is based on a coarse-grained representation of NTs as
 "flexible cylinders" consisting of a variable number of
 segments. Internal interactions within a NT and the van der Waals
 interaction between the tubes are described by a mesoscopic force field
 designed and parameterized based on the results of atomic-level
 molecular dynamics simulations. The description of the force field is
-provided in the papers listed below.
+provided in the papers listed in ``src/MESONT/README``.
 
-This package contains two independent implementations of this model:
+This package used to have two independent implementations of this model:
-:doc:`pair_style mesont/tpm <pair_mesont_tpm>` is the original
+the original implementation using a Fortran library written by the
-implementation of the model based on a Fortran library in the
+developers of the model and a second implementation written in C++ by
-``lib/mesont`` folder. The second implementation is provided by the
+Philipp Kloza (U Cambridge).  Since the C++ implementation offers the
-mesocnt styles (:doc:`bond_style mesocnt <bond_mesocnt>`,
+same features as the original implementation with the addition of
-:doc:`angle_style mesocnt <angle_mesocnt>` and :doc:`pair_style mesocnt
+friction, is typically faster, and easier to compile/install, the
-<pair_mesocnt>`).  The mesocnt implementation has the same features as
+Fortran library based implementation has since been obsoleted and
-the original implementation with the addition of friction, but is
+removed from the distribution. You have to download and compile
-directly implemented in C++, interfaces more cleanly with general LAMMPS
+an older version of LAMMPS if you want to use those.
-functionality, and is typically faster. It also does not require its own
-atom style and can be installed without any external libraries.
 
 **Download of potential files:**
 
@@ -1648,12 +1646,14 @@ not included in the regular downloaded packages of LAMMPS or the git
 repositories.  Instead, they will be automatically downloaded from a web
 server when the package is installed for the first time.
 
-**Authors of the *mesont* styles:**
+**Authors of the obsoleted *mesont* styles:**
 
 Maxim V. Shugaev (University of Virginia), Alexey N. Volkov (University
 of Alabama), Leonid V. Zhigilei (University of Virginia)
 
-**Author of the *mesocnt* styles:**
+.. deprecated:: TBD
+
+**Author of the C++ styles:**
 Philipp Kloza (U Cambridge)
 
 .. versionadded:: 15Jun2020
@@ -1662,14 +1662,10 @@ Philipp Kloza (U Cambridge)
 
 * src/MESONT: filenames -> commands
 * src/MESONT/README
-* :doc:`atom_style mesont <atom_style>`
-* :doc:`pair_style mesont/tpm <pair_mesont_tpm>`
-* :doc:`compute mesont <compute_mesont>`
 * :doc:`bond_style mesocnt <bond_mesocnt>`
 * :doc:`angle_style mesocnt <angle_mesocnt>`
 * :doc:`pair_style mesocnt <pair_mesocnt>`
 * examples/PACKAGES/mesont
-* tools/mesont
 
 ----------
 
@@ -2210,7 +2206,7 @@ packages, which have styles optimized for CPUs.
    See src/MAKE/OPTIONS/Makefile.omp for an example.
 
 Once you have an appropriate Makefile.machine, you can
-install/un-install the package and build LAMMPS in the usual manner:
+install/uninstall the package and build LAMMPS in the usual manner:
 
 **Install:**
 

doc/src/Packages_list.rst

@@ -8,7 +8,7 @@ Packages are supported by either the LAMMPS developers or the
 contributing authors and written in a syntax and style consistent with
 the rest of LAMMPS.
 
-The "Examples" column is a sub-directory in the examples directory of the
+The "Examples" column is a subdirectory in the examples directory of the
 distribution which has one or more input scripts that use the package.
 E.g. "peptide" refers to the examples/peptide directory; PACKAGES/atc refers
 to the examples/PACKAGES/atc directory.  The "Lib" column indicates
@@ -275,9 +275,9 @@ whether an extra library is needed to build and use the package:
      - no
    * - :ref:`MESONT <PKG-MESONT>`
      - mesoscopic tubular potential model
-     - pair styles :doc:`mesont/tpm <pair_mesont_tpm>`, :doc:`mesocnt <pair_mesocnt>`
+     - pair styles :doc:`mesocnt <pair_mesocnt>`
      - PACKAGES/mesont
-     - int
+     - no
    * - :ref:`MGPT <PKG-MGPT>`
      - fast MGPT multi-ion potentials
      - :doc:`pair_style mgpt <pair_mgpt>`

doc/src/Python_atoms.rst

@@ -23,7 +23,7 @@ against invalid accesses.
    When accessing per-atom data,
    please note that this data is the per-processor local data and indexed
    accordingly. These arrays can change sizes and order at every neighbor list
-   rebuild and atom sort event as atoms are migrating between sub-domains.
+   rebuild and atom sort event as atoms are migrating between subdomains.
 
 .. tabs::
 

doc/src/Python_examples.rst

@@ -33,7 +33,7 @@ with ``gl`` or ``atomeye`` or ``pymol`` or ``vmd``, depending on what
 visualization package you have installed.
 
 Note that for GL, you need to be able to run the Pizza.py GL tool,
-which is included in the pizza sub-directory.  See the Pizza.py doc pages for more info:
+which is included in the pizza subdirectory.  See the Pizza.py doc pages for more info:
 
 * `https://lammps.github.io/pizza <pizza_>`_
 

doc/src/Python_launch.rst

@@ -70,7 +70,7 @@ single processor outputs, mpi4py is not working correctly.
 Also note that once you import the mpi4py module, mpi4py initializes MPI
 for you, and you can use MPI calls directly in your Python script, as
 described in the mpi4py documentation.  The last line of your Python
-script should be ``MPI.finalize()``, to insure MPI is shut down
+script should be ``MPI.finalize()``, to ensure MPI is shut down
 correctly.
 
 

doc/src/Python_properties.rst

@@ -23,7 +23,7 @@ against invalid accesses.
    When accessing per-atom data,
    please note that this data is the per-processor local data and indexed
    accordingly. These arrays can change sizes and order at every neighbor list
-   rebuild and atom sort event as atoms are migrating between sub-domains.
+   rebuild and atom sort event as atoms are migrating between subdomains.
 
 .. tabs::
 

doc/src/Run_options.rst

@@ -105,13 +105,12 @@ Either the full word or an abbreviation can be used for the keywords.
 Note that the keywords do not use a leading minus sign.  I.e. the
 keyword is "t", not "-t".  Also note that each of the keywords has a
 default setting.  Examples of when to use these options and what
-settings to use on different platforms is given on the :doc:`KOKKOS package <Speed_kokkos>`
+settings to use on different platforms is given on the :doc:`KOKKOS
-doc page.
+package <Speed_kokkos>` doc page.
 
 * d or device
 * g or gpus
 * t or threads
-* n or numa
 
 .. parsed-literal::
 
@@ -164,19 +163,10 @@ the number of physical cores per node, to use your available hardware
 optimally.  This also sets the number of threads used by the host when
 LAMMPS is compiled with CUDA=yes.
 
-.. parsed-literal::
+.. deprecated:: 22Dec2022
 
-   numa Nm
+Support for the "numa" or "n" option was removed as its functionality
-
+was ignored in Kokkos for some time already.
-This option is only relevant when using pthreads with hwloc support.
-In this case Nm defines the number of NUMA regions (typically sockets)
-on a node which will be utilized by a single MPI rank.  By default Nm
-= 1.  If this option is used the total number of worker-threads per
-MPI rank is threads\*numa.  Currently it is always almost better to
-assign at least one MPI rank per NUMA region, and leave numa set to
-its default value of 1. This is because letting a single process span
-multiple NUMA regions induces a significant amount of cross NUMA data
-traffic which is slow.
 
 ----------
 
@@ -334,7 +324,7 @@ writes log information to file.N. If file is none, then no partition
 log files are created.  This overrides the filename specified in the
 -log command-line option.  This option is useful when working with
 large numbers of partitions, allowing the partition log files to be
-suppressed (-plog none) or placed in a sub-directory (-plog
+suppressed (-plog none) or placed in a subdirectory (-plog
 replica_files/log.lammps) If this option is not used the log file for
 partition N is log.lammps.N or whatever is specified by the -log
 command-line option.
@@ -351,7 +341,7 @@ partition screen files are created.  This overrides the filename
 specified in the -screen command-line option.  This option is useful
 when working with large numbers of partitions, allowing the partition
 screen files to be suppressed (-pscreen none) or placed in a
-sub-directory (-pscreen replica_files/screen).  If this option is not
+subdirectory (-pscreen replica_files/screen).  If this option is not
 used the screen file for partition N is screen.N or whatever is
 specified by the -screen command-line option.
 
@@ -372,10 +362,10 @@ Reorder the processors in the MPI communicator used to instantiate
 LAMMPS, in one of several ways.  The original MPI communicator ranks
 all P processors from 0 to P-1.  The mapping of these ranks to
 physical processors is done by MPI before LAMMPS begins.  It may be
-useful in some cases to alter the rank order.  E.g. to insure that
+useful in some cases to alter the rank order.  E.g. to ensure that
 cores within each node are ranked in a desired order.  Or when using
 the :doc:`run_style verlet/split <run_style>` command with 2 partitions
-to insure that a specific Kspace processor (in the second partition) is
+to ensure that a specific Kspace processor (in the second partition) is
 matched up with a specific set of processors in the first partition.
 See the :doc:`General tips <Speed_tips>` page for more details.
 
@@ -408,7 +398,7 @@ so that the processors in each partition will be
    0 1 2 4 5 6 8 9 10
    3 7 11
 
-See the "processors" command for how to insure processors from each
+See the "processors" command for how to ensure processors from each
 partition could then be grouped optimally for quad-core nodes.
 
 If the keyword is *custom*, then a file that specifies a permutation

doc/src/Run_output.rst

@@ -122,7 +122,7 @@ potentially *dangerous* rebuilds.  If atom movement triggered neighbor
 list rebuilding (see the :doc:`neigh_modify <neigh_modify>` command),
 then dangerous reneighborings are those that were triggered on the
 first timestep atom movement was checked for.  If this count is
-non-zero you may wish to reduce the delay factor to insure no force
+non-zero you may wish to reduce the delay factor to ensure no force
 interactions are missed by atoms moving beyond the neighbor skin
 distance before a rebuild takes place.
 

doc/src/Run_windows.rst

@@ -33,7 +33,7 @@ path for the default location of this MPI package. After the
 installation of the MPICH2 software, it needs to be integrated into
 the system.  For this you need to start a Command Prompt in
 *Administrator Mode* (right click on the icon and select it). Change
-into the MPICH2 installation directory, then into the sub-directory
+into the MPICH2 installation directory, then into the subdirectory
 **bin** and execute **smpd.exe -install**\ . Exit the command window.
 
 * Get a new, regular command prompt by going to Start->Run... ,

doc/src/Speed.rst

@@ -9,7 +9,7 @@ There are two thrusts to the discussion that follows.  The first is
 using code options that implement alternate algorithms that can
 speed-up a simulation.  The second is to use one of the several
 accelerator packages provided with LAMMPS that contain code optimized
-for certain kinds of hardware, including multi-core CPUs, GPUs, and
+for certain kinds of hardware, including multicore CPUs, GPUs, and
 Intel Xeon Phi co-processors.
 
 The `Benchmark page <https://www.lammps.org/bench.html>`_ of the LAMMPS

doc/src/Speed_gpu.rst

@@ -11,7 +11,7 @@ parts of the :doc:`kspace_style pppm <kspace_style>` for long-range
 Coulombics.  It has the following general features:
 
 * It is designed to exploit common GPU hardware configurations where one
-  or more GPUs are coupled to many cores of one or more multi-core CPUs,
+  or more GPUs are coupled to many cores of one or more multicore CPUs,
   e.g. within a node of a parallel machine.
 * Atom-based data (e.g. coordinates, forces) are moved back-and-forth
   between the CPU(s) and GPU every timestep.
@@ -28,7 +28,7 @@ Coulombics.  It has the following general features:
 * LAMMPS-specific code is in the GPU package.  It makes calls to a
   generic GPU library in the lib/gpu directory.  This library provides
   either Nvidia support, AMD support, or more general OpenCL support
-  (for Nvidia GPUs, AMD GPUs, Intel GPUs, and multi-core CPUs).
+  (for Nvidia GPUs, AMD GPUs, Intel GPUs, and multicore CPUs).
   so that the same functionality is supported on a variety of hardware.
 
 **Required hardware/software:**
@@ -146,7 +146,7 @@ GPUs/node to use, as well as other options.
 
 **Speed-ups to expect:**
 
-The performance of a GPU versus a multi-core CPU is a function of your
+The performance of a GPU versus a multicore CPU is a function of your
 hardware, which pair style is used, the number of atoms/GPU, and the
 precision used on the GPU (double, single, mixed). Using the GPU package
 in OpenCL mode on CPUs (which uses vectorization and multithreading) is
@@ -174,7 +174,7 @@ deterministic results.
 **Guidelines for best performance:**
 
 * Using multiple MPI tasks per GPU will often give the best performance,
-  as allowed my most multi-core CPU/GPU configurations.
+  as allowed my most multicore CPU/GPU configurations.
 * If the number of particles per MPI task is small (e.g. 100s of
   particles), it can be more efficient to run with fewer MPI tasks per
   GPU, even if you do not use all the cores on the compute node.

doc/src/Speed_kokkos.rst

@@ -79,7 +79,7 @@ manner via the ``mpirun`` or ``mpiexec`` commands, and is independent of
 Kokkos. E.g. the mpirun command in OpenMPI does this via its ``-np`` and
 ``-npernode`` switches. Ditto for MPICH via ``-np`` and ``-ppn``.
 
-Running on a multi-core CPU
+Running on a multicore CPU
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Here is a quick overview of how to use the KOKKOS package
@@ -254,7 +254,7 @@ is recommended in this scenario.
 
 Using a GPU-aware MPI library is highly recommended. GPU-aware MPI use can be
 avoided by using :doc:`-pk kokkos gpu/aware off <package>`. As above for
-multi-core CPUs (and no GPU), if N is the number of physical cores/node,
+multicore CPUs (and no GPU), if N is the number of physical cores/node,
 then the number of MPI tasks/node should not exceed N.
 
 .. parsed-literal::

doc/src/Speed_omp.rst

@@ -12,7 +12,7 @@ Required hardware/software
 """"""""""""""""""""""""""
 
 To enable multi-threading, your compiler must support the OpenMP interface.
-You should have one or more multi-core CPUs, as multiple threads can only be
+You should have one or more multicore CPUs, as multiple threads can only be
 launched by each MPI task on the local node (using shared memory).
 
 Building LAMMPS with the OPENMP package
@@ -93,7 +93,7 @@ With multiple threads/task, the optimal choice of number of MPI
 tasks/node and OpenMP threads/task can vary a lot and should always be
 tested via benchmark runs for a specific simulation running on a
 specific machine, paying attention to guidelines discussed in the next
-sub-section.
+subsection.
 
 A description of the multi-threading strategy used in the OPENMP
 package and some performance examples are
@@ -157,7 +157,7 @@ Additional performance tips are as follows:
   affinity setting that restricts each MPI task to a single CPU core.
   Using multi-threading in this mode will force all threads to share the
   one core and thus is likely to be counterproductive.  Instead, binding
-  MPI tasks to a (multi-core) socket, should solve this issue.
+  MPI tasks to a (multicore) socket, should solve this issue.
 
 Restrictions
 """"""""""""

doc/src/Tools.rst

@@ -29,11 +29,11 @@ actively supported by the LAMMPS developers, as they were contributed
 by LAMMPS users.  If you have problems using them, we can direct you
 to the authors.
 
-The source code for each of these codes is in the tools sub-directory
+The source code for each of these codes is in the tools subdirectory
 of the LAMMPS distribution.  There is a Makefile (which you may need
 to edit for your platform) which will build several of the tools which
 reside in that directory.  Most of them are larger packages in their
-own sub-directories with their own Makefiles and/or README files.
+own subdirectories with their own Makefiles and/or README files.
 
 ----------
 
@@ -109,7 +109,7 @@ Tool descriptions
 amber2lmp tool
 --------------------------
 
-The amber2lmp sub-directory contains two Python scripts for converting
+The amber2lmp subdirectory contains two Python scripts for converting
 files back-and-forth between the AMBER MD code and LAMMPS.  See the
 README file in amber2lmp for more information.
 
@@ -145,7 +145,7 @@ since binary files are not compatible across all platforms.
 ch2lmp tool
 ------------------------
 
-The ch2lmp sub-directory contains tools for converting files
+The ch2lmp subdirectory contains tools for converting files
 back-and-forth between the CHARMM MD code and LAMMPS.
 
 They are intended to make it easy to use CHARMM as a builder and as a
@@ -156,7 +156,7 @@ CHARMM22 and later is available as an option. This tool can also add
 solvent water molecules and Na+ or Cl- ions to the system.
 Using lammps2pdb.pl you can convert LAMMPS atom dumps into PDB files.
 
-See the README file in the ch2lmp sub-directory for more information.
+See the README file in the ch2lmp subdirectory for more information.
 
 These tools were created by Pieter in't Veld (pjintve at sandia.gov)
 and Paul Crozier (pscrozi at sandia.gov) at Sandia.
@@ -638,7 +638,7 @@ you first need to use the :doc:`clear` command.
 lmp2arc tool
 ------------
 
-The lmp2arc sub-directory contains a tool for converting LAMMPS output
+The lmp2arc subdirectory contains a tool for converting LAMMPS output
 files to the format for Accelrys' Insight MD code (formerly
 MSI/Biosym and its Discover MD code).  See the README file for more
 information.
@@ -657,7 +657,7 @@ Greathouse at Sandia (jagreat at sandia.gov).
 lmp2cfg tool
 ----------------------
 
-The lmp2cfg sub-directory contains a tool for converting LAMMPS output
+The lmp2cfg subdirectory contains a tool for converting LAMMPS output
 files into a series of \*.cfg files which can be read into the
 `AtomEye <http://li.mit.edu/Archive/Graphics/A/>`_ visualizer.  See
 the README file for more information.
@@ -704,7 +704,7 @@ detect most LAMMPS restarts, dump, data and log files. Examples:
 matlab tool
 ------------------------
 
-The matlab sub-directory contains several `MATLAB <matlabhome_>`_ scripts for
+The matlab subdirectory contains several `MATLAB <matlabhome_>`_ scripts for
 post-processing LAMMPS output.  The scripts include readers for log
 and dump files, a reader for EAM potential files, and a converter that
 reads LAMMPS dump files and produces CFG files that can be visualized
@@ -747,7 +747,7 @@ definition file.  This tool was used to create the system for the
 moltemplate tool
 ----------------------------------
 
-The moltemplate sub-directory contains instructions for installing
+The moltemplate subdirectory contains instructions for installing
 moltemplate, a Python-based tool for building molecular systems based
 on a text-file description, and creating LAMMPS data files that encode
 their molecular topology as lists of bonds, angles, dihedrals, etc.
@@ -765,7 +765,7 @@ The latest sources can be found `on its GitHub page <https://github.com/jewettai
 msi2lmp tool
 ----------------------
 
-The msi2lmp sub-directory contains a tool for creating LAMMPS template
+The msi2lmp subdirectory contains a tool for creating LAMMPS template
 input and data files from BIOVIA's Materias Studio files (formerly
 Accelrys' Insight MD code, formerly MSI/Biosym and its Discover MD code).
 
@@ -882,7 +882,7 @@ dependencies and redirects the download to the local cache.
 phonon tool
 ------------------------
 
-The phonon sub-directory contains a post-processing tool useful for
+The phonon subdirectory contains a post-processing tool useful for
 analyzing the output of the :doc:`fix phonon <fix_phonon>` command in
 the PHONON package.
 
@@ -900,7 +900,7 @@ University.
 polybond tool
 ----------------------------
 
-The polybond sub-directory contains a Python-based tool useful for
+The polybond subdirectory contains a Python-based tool useful for
 performing "programmable polymer bonding".  The Python file
 lmpsdata.py provides a "Lmpsdata" class with various methods which can
 be invoked by a user-written Python script to create data files with
@@ -917,7 +917,7 @@ This tool was written by Zachary Kraus at Georgia Tech.
 pymol_asphere tool
 -------------------------------
 
-The pymol_asphere sub-directory contains a tool for converting a
+The pymol_asphere subdirectory contains a tool for converting a
 LAMMPS dump file that contains orientation info for ellipsoidal
 particles into an input file for the `PyMol visualization package <pymolhome_>`_ or its `open source variant <pymolopen_>`_.
 
@@ -938,7 +938,7 @@ This tool was written by Mike Brown at Sandia.
 python tool
 -----------------------------
 
-The python sub-directory contains several Python scripts
+The python subdirectory contains several Python scripts
 that perform common LAMMPS post-processing tasks, such as:
 
 * extract thermodynamic info from a log file as columns of numbers
@@ -975,7 +975,7 @@ while at the Shell lab at UC Santa Barbara. (tanmoy dot 7989 at gmail.com)
 smd tool
 ------------------
 
-The smd sub-directory contains a C++ file dump2vtk_tris.cpp and
+The smd subdirectory contains a C++ file dump2vtk_tris.cpp and
 Makefile which can be compiled and used to convert triangle output
 files created by the Smooth-Mach Dynamics (MACHDYN) package into a
 VTK-compatible unstructured grid file.  It could then be read in and
@@ -994,7 +994,7 @@ Ernst Mach Institute in Germany (georg.ganzenmueller at emi.fhg.de).
 spin tool
 --------------------
 
-The spin sub-directory contains a C file interpolate.c which can
+The spin subdirectory contains a C file interpolate.c which can
 be compiled and used to perform a cubic polynomial interpolation of
 the MEP following a GNEB calculation.
 
@@ -1011,7 +1011,7 @@ Ivanov, at University of Iceland (ali5 at hi.is).
 singularity/apptainer tool
 --------------------------
 
-The singularity sub-directory contains container definitions files that
+The singularity subdirectory contains container definitions files that
 can be used to build container images for building and testing LAMMPS on
 specific OS variants using the `Apptainer <https://apptainer.org>`_ or
 `Singularity <https://sylabs.io>`_ container software. Contributions for

doc/src/atom_modify.rst

@@ -113,7 +113,7 @@ your input script.  LAMMPS does not use the group until a simulation
 is run.
 
 The *sort* keyword turns on a spatial sorting or reordering of atoms
-within each processor's sub-domain every *Nfreq* timesteps.  If
+within each processor's subdomain every *Nfreq* timesteps.  If
 *Nfreq* is set to 0, then sorting is turned off.  Sorting can improve
 cache performance and thus speed-up a LAMMPS simulation, as discussed
 in a paper by :ref:`(Meloni) <Meloni>`.  Its efficacy depends on the problem