Merge pull request #4645 from akohlmey/improve-tests-for-set

Add or improve unit test programs to improve test coverage and specifically check recent additions

.github/release_steps.md

@@ -104,13 +104,13 @@ with a future release) from the `lammps-static` folder.
 rm -rf release-packages
 mkdir release-packages
 cd release-packages
-wget https://download.lammps.org/static/fedora41_musl.sif
-apptainer shell fedora41_musl.sif
+wget https://download.lammps.org/static/fedora41_musl_mingw.sif
+apptainer shell fedora41_musl_mingw.sif
 git clone -b release --depth 10 https://github.com/lammps/lammps.git lammps-release
 cmake -S lammps-release/cmake -B build-release -G Ninja -D CMAKE_INSTALL_PREFIX=$PWD/lammps-static -D CMAKE_TOOLCHAIN_FILE=/usr/musl/share/cmake/linux-musl.cmake -C lammps-release/cmake/presets/most.cmake -C lammps-release/cmake/presets/kokkos-openmp.cmake -D DOWNLOAD_POTENTIALS=OFF -D BUILD_MPI=OFF -D BUILD_TESTING=OFF -D CMAKE_BUILD_TYPE=Release -D PKG_ATC=ON -D PKG_AWPMD=ON -D PKG_MANIFOLD=ON -D PKG_MESONT=ON -D PKG_MGPT=ON -D PKG_ML-PACE=ON -D PKG_ML-RANN=ON -D PKG_MOLFILE=ON -D PKG_PTM=ON -D PKG_QTB=ON -D PKG_SMTBQ=ON
 cmake --build build-release --target all
 cmake --build build-release --target install
-/usr/musl/bin/x86_64-linux-musl-strip lammps-static/bin/*
+/usr/musl/bin/x86_64-linux-musl-strip -g lammps-static/bin/*
 tar -czvvf ../lammps-linux-x86_64-4Feb2025.tar.gz lammps-static
 exit # fedora 41 container
 cd ..
@@ -204,7 +204,7 @@ cd ..
 rm -r release-packages
 ```
 
-#### Build Multi-arch App-bundle for macOS
+#### Build Multi-arch App-bundle with GUI for macOS
 
 Building app-bundles for macOS is not as easily automated and portable
 as some of the other steps.  It requires a machine actually running
@@ -251,7 +251,7 @@ attached to the GitHub release page.
 
 We are currently building the application images on macOS 12 (aka Monterey).
 
-#### Build Linux x86_64 binary tarball on Ubuntu 20.04LTS
+#### Build Linux x86_64 binary tarball with GUI on Ubuntu 20.04LTS
 
 While the flatpak Linux version uses portable runtime libraries provided
 by the flatpak environment, we also build regular Linux executables that

.github/workflows/check-cpp23.yml

@@ -1,4 +1,4 @@
-# GitHub action to build LAMMPS on Linux with gcc and C++23
+# GitHub action to build LAMMPS on Linux with gcc or clang and C++23
 name: "Check for C++23 Compatibility"
 
 on:
@@ -11,11 +11,19 @@ on:
 
   workflow_dispatch:
 
+concurrency:
+  group: ${{ github.event_name }}-${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: ${{github.event_name == 'pull_request'}}
+
 jobs:
   build:
     name: Build with C++23 support enabled
     if: ${{ github.repository == 'lammps/lammps' }}
     runs-on: ubuntu-latest
+    strategy:
+      max-parallel: 2
+      matrix:
+        idx: [ gcc, clang ]
     env:
       CCACHE_DIR: ${{ github.workspace }}/.ccache
 
@@ -29,8 +37,11 @@ jobs:
       run: |
         sudo apt-get update
         sudo apt-get install -y ccache \
-                                libeigen3-dev \
+                                clang \
                                 libcurl4-openssl-dev \
+                                libeigen3-dev \
+                                libfftw3-dev \
+                                libomp-dev \
                                 mold \
                                 mpi-default-bin \
                                 mpi-default-dev \
@@ -44,8 +55,8 @@ jobs:
       uses: actions/cache@v4
       with:
         path: ${{ env.CCACHE_DIR }}
-        key: linux-cpp23-ccache-${{ github.sha }}
-        restore-keys: linux-cpp23-ccache-
+        key: linux-cpp23-ccache-${{ matrix.idx }}-${{ github.sha }}
+        restore-keys: linux-cpp23-ccache-${{ matrix.idx }}
 
     - name: Building LAMMPS via CMake
       shell: bash
@@ -58,14 +69,14 @@ jobs:
         cmake -S cmake -B build \
               -C cmake/presets/most.cmake \
               -C cmake/presets/kokkos-openmp.cmake \
+              -C cmake/presets/${{ matrix.idx }}.cmake \
               -D CMAKE_CXX_STANDARD=23 \
-              -D CMAKE_CXX_COMPILER=g++ \
-              -D CMAKE_C_COMPILER=gcc \
               -D CMAKE_CXX_COMPILER_LAUNCHER=ccache \
               -D CMAKE_C_COMPILER_LAUNCHER=ccache \
               -D CMAKE_BUILD_TYPE=Debug \
               -D CMAKE_CXX_FLAGS_DEBUG="-Og -g" \
               -D DOWNLOAD_POTENTIALS=off \
+              -D FFT=KISS \
               -D BUILD_MPI=on \
               -D BUILD_SHARED_LIBS=on \
               -D BUILD_TOOLS=off \

README

@@ -34,6 +34,7 @@ lib                        additional provided or external libraries
 potentials                 interatomic potential files
 python                     Python module for LAMMPS
 src                        source files
+third_party                Copies of thirdparty software bundled with LAMMPS
 tools                      pre- and post-processing tools
 unittest                   test programs for use with CTest
 .github                    Git and GitHub related files and tools

cmake/CMakeLists.txt

@@ -3,10 +3,11 @@
 # CMake build system
 # This file is part of LAMMPS
 cmake_minimum_required(VERSION 3.16)
-if(CMAKE_VERSION VERSION_LESS 3.20)
-  message(WARNING "LAMMPS is planning to require at least CMake version 3.20 by Summer 2025. Please upgrade!")
-endif()
 ########################################
+# initialize version variables with project command
+if(POLICY CMP0048)
+  cmake_policy(SET CMP0048 NEW)
+endif()
 # set policy to silence warnings about ignoring <PackageName>_ROOT but use it
 if(POLICY CMP0074)
   cmake_policy(SET CMP0074 NEW)
@@ -27,7 +28,10 @@ endif()
 
 ########################################
 
-project(lammps CXX)
+project(lammps
+        DESCRIPTION "The LAMMPS Molecular Dynamics Simulator"
+        HOMEPAGE_URL "https://www.lammps.org"
+        LANGUAGES CXX C)
 set(SOVERSION 0)
 get_property(BUILD_IS_MULTI_CONFIG GLOBAL PROPERTY GENERATOR_IS_MULTI_CONFIG)
 
@@ -44,6 +48,7 @@ set(LAMMPS_DOC_DIR        ${LAMMPS_DIR}/doc)
 set(LAMMPS_TOOLS_DIR      ${LAMMPS_DIR}/tools)
 set(LAMMPS_PYTHON_DIR     ${LAMMPS_DIR}/python)
 set(LAMMPS_POTENTIALS_DIR ${LAMMPS_DIR}/potentials)
+set(LAMMPS_THIRDPARTY_DIR ${LAMMPS_DIR}/third_party)
 
 set(LAMMPS_DOWNLOADS_URL "https://download.lammps.org" CACHE STRING "Base URL for LAMMPS downloads")
 set(LAMMPS_POTENTIALS_URL "${LAMMPS_DOWNLOADS_URL}/potentials")
@@ -105,46 +110,35 @@ if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
       set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /Qrestrict")
     endif()
     if(CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.3 OR CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.4)
-      set(CMAKE_TUNE_DEFAULT "/QxCOMMON-AVX512")
+      set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /QxCOMMON-AVX512")
     else()
-      set(CMAKE_TUNE_DEFAULT "/QxHost")
+      set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /QxHost")
     endif()
   else()
     set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -restrict")
     if(CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.3 OR CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.4)
-      set(CMAKE_TUNE_DEFAULT "-xCOMMON-AVX512")
+      set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -xCOMMON-AVX512")
     else()
-      set(CMAKE_TUNE_DEFAULT "-xHost -fp-model fast=2 -no-prec-div -qoverride-limits -diag-disable=10441 -diag-disable=11074 -diag-disable=11076 -diag-disable=2196")
+      set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -xHost -fp-model fast=2 -no-prec-div -qoverride-limits -diag-disable=10441 -diag-disable=11074 -diag-disable=11076 -diag-disable=2196")
     endif()
   endif()
 endif()
 
 # silence excessive warnings for new Intel Compilers
 if(CMAKE_CXX_COMPILER_ID STREQUAL "IntelLLVM")
-  set(CMAKE_TUNE_DEFAULT "-fp-model precise -Wno-tautological-constant-compare -Wno-unused-command-line-argument")
+  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fp-model precise -Wno-tautological-constant-compare -Wno-unused-command-line-argument")
 endif()
 
 # silence excessive warnings for PGI/NVHPC compilers
 if((CMAKE_CXX_COMPILER_ID STREQUAL "NVHPC") OR (CMAKE_CXX_COMPILER_ID STREQUAL "PGI"))
-  set(CMAKE_TUNE_DEFAULT "-Minform=severe")
-endif()
-
-# this hack is required to compile fmt lib with CrayClang version 15.0.2
-# CrayClang is only directly recognized by version 3.28 and later
-if(CMAKE_VERSION VERSION_LESS 3.28)
-  get_filename_component(_exe "${CMAKE_CXX_COMPILER}" NAME)
-  if((CMAKE_CXX_COMPILER_ID STREQUAL "Clang") AND (_exe STREQUAL "crayCC"))
-    set(CMAKE_TUNE_DEFAULT "-DFMT_STATIC_THOUSANDS_SEPARATOR")
-  endif()
-else()
-  if(CMAKE_CXX_COMPILER_ID STREQUAL "CrayClang")
-    set(CMAKE_TUNE_DEFAULT "-DFMT_STATIC_THOUSANDS_SEPARATOR")
-  endif()
+  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Minform=severe")
 endif()
 
 # silence nvcc warnings
-if((PKG_KOKKOS) AND (Kokkos_ENABLE_CUDA) AND NOT (CMAKE_CXX_COMPILER_ID STREQUAL "Clang"))
-  set(CMAKE_TUNE_DEFAULT "${CMAKE_TUNE_DEFAULT}" "-Xcudafe --diag_suppress=unrecognized_pragma,--diag_suppress=128")
+if((PKG_KOKKOS) AND (Kokkos_ENABLE_CUDA) AND NOT
+    ((CMAKE_CXX_COMPILER_ID STREQUAL "Clang") OR (CMAKE_CXX_COMPILER_ID STREQUAL "IntelLLVM")
+    OR (CMAKE_CXX_COMPILER_ID STREQUAL "XLClang") OR (CMAKE_CXX_COMPILER_ID STREQUAL "CrayClang")))
+  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Xcudafe --diag_suppress=unrecognized_pragma,--diag_suppress=128")
 endif()
 
 # we *require* C++11 without extensions but prefer C++17.
@@ -159,9 +153,6 @@ endif()
 if(CMAKE_CXX_STANDARD LESS 11)
   message(FATAL_ERROR "C++ standard must be set to at least 11")
 endif()
-if(CMAKE_CXX_STANDARD LESS 17)
-  message(WARNING "Selecting C++17 standard is preferred over C++${CMAKE_CXX_STANDARD}")
-endif()
 if(PKG_KOKKOS AND (CMAKE_CXX_STANDARD LESS 17))
   set(CMAKE_CXX_STANDARD 17)
 endif()
@@ -206,6 +197,10 @@ if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND BUILD_SHARED_LIBS)
   set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON)
 endif()
 
+# do not include the (obsolete) MPI C++ bindings which makes for leaner object files
+# and avoids namespace conflicts. Put this early to increase its visbility.
+set(MPI_CXX_SKIP_MPICXX TRUE CACHE BOOL "Skip MPI C++ Bindings" FORCE)
+
 ########################################################################
 # User input options                                                   #
 ########################################################################
@@ -243,15 +238,6 @@ option(CMAKE_POSITION_INDEPENDENT_CODE "Create object compatible with shared lib
 option(BUILD_TOOLS "Build and install LAMMPS tools (msi2lmp, binary2txt, chain)" OFF)
 option(BUILD_LAMMPS_GUI "Build and install the LAMMPS GUI" OFF)
 
-# Support using clang-tidy for C++ files with selected options
-set(ENABLE_CLANG_TIDY OFF CACHE BOOL "Include clang-tidy processing when compiling")
-if(ENABLE_CLANG_TIDY)
-  set(CMAKE_CXX_CLANG_TIDY "clang-tidy;-checks=-*,performance-trivially-destructible,performance-unnecessary-copy-initialization,performance-unnecessary-value-param,readability-redundant-control-flow,readability-redundant-declaration,readability-redundant-function-ptr-dereference,readability-redundant-member-init,readability-redundant-string-cstr,readability-redundant-string-init,readability-simplify-boolean-expr,readability-static-accessed-through-instance,readability-static-definition-in-anonymous-namespace,readability-qualified-auto,misc-unused-parameters,modernize-deprecated-ios-base-aliases,modernize-loop-convert,modernize-shrink-to-fit,modernize-use-auto,modernize-use-using,modernize-use-override,modernize-use-bool-literals,modernize-use-emplace,modernize-return-braced-init-list,modernize-use-equals-default,modernize-use-equals-delete,modernize-replace-random-shuffle,modernize-deprecated-headers,modernize-use-nullptr,modernize-use-noexcept,modernize-redundant-void-arg;-fix;-header-filter=.*,header-filter=library.h,header-filter=fmt/*.h" CACHE STRING "clang-tidy settings")
-else()
-  unset(CMAKE_CXX_CLANG_TIDY CACHE)
-endif()
-
-
 file(GLOB ALL_SOURCES CONFIGURE_DEPENDS ${LAMMPS_SOURCE_DIR}/[^.]*.cpp)
 file(GLOB MAIN_SOURCES CONFIGURE_DEPENDS ${LAMMPS_SOURCE_DIR}/main.cpp)
 list(REMOVE_ITEM ALL_SOURCES ${MAIN_SOURCES})
@@ -276,6 +262,7 @@ option(CMAKE_VERBOSE_MAKEFILE "Generate verbose Makefiles" OFF)
 set(STANDARD_PACKAGES
   ADIOS
   AMOEBA
+  APIP
   ASPHERE
   ATC
   AWPMD
@@ -368,27 +355,16 @@ foreach(PKG ${STANDARD_PACKAGES} ${SUFFIX_PACKAGES})
   option(PKG_${PKG} "Build ${PKG} Package" OFF)
 endforeach()
 
-set(DEPRECATED_PACKAGES AWPMD ATC POEMS)
-foreach(PKG ${DEPRECATED_PACKAGES})
-  if(PKG_${PKG})
-    message(WARNING
-          "The ${PKG} package will be removed from LAMMPS in Summer 2025 due to lack of "
-          "maintenance and use of code constructs that conflict with modern C++ compilers "
-          "and standards.  Please contact developers@lammps.org if you have any concerns "
-          "about this step.")
-  endif()
-endforeach()
-
 ######################################################
 # packages with special compiler needs or external libs
 ######################################################
 target_include_directories(lammps PUBLIC $<BUILD_INTERFACE:${LAMMPS_SOURCE_DIR}>)
+target_include_directories(lammps PUBLIC $<BUILD_INTERFACE:${LAMMPS_THIRDPARTY_DIR}>)
 
 if(PKG_ADIOS)
   # The search for ADIOS2 must come before MPI because
   # it includes its own MPI search with the latest FindMPI.cmake
   # script that defines the MPI::MPI_C target
-  enable_language(C)
   find_package(ADIOS2 REQUIRED)
   if(BUILD_MPI)
     if(NOT ADIOS2_HAVE_MPI)
@@ -403,21 +379,18 @@ if(PKG_ADIOS)
 endif()
 
 if(NOT CMAKE_CROSSCOMPILING)
-  find_package(MPI QUIET)
+  find_package(MPI QUIET COMPONENTS CXX)
   option(BUILD_MPI "Build MPI version" ${MPI_FOUND})
 else()
   option(BUILD_MPI "Build MPI version" OFF)
 endif()
 
 if(BUILD_MPI)
-  # do not include the (obsolete) MPI C++ bindings which makes
-  # for leaner object files and avoids namespace conflicts
-  set(MPI_CXX_SKIP_MPICXX TRUE)
   # We use a non-standard procedure to cross-compile with MPI on Windows
   if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND CMAKE_CROSSCOMPILING)
     include(MPI4WIN)
   else()
-    find_package(MPI REQUIRED)
+    find_package(MPI REQUIRED COMPONENTS CXX)
     option(LAMMPS_LONGLONG_TO_LONG "Workaround if your system or MPI version does not recognize 'long long' data types" OFF)
     if(LAMMPS_LONGLONG_TO_LONG)
       target_compile_definitions(lammps PRIVATE -DLAMMPS_LONGLONG_TO_LONG)
@@ -450,6 +423,19 @@ if(NOT ${LAMMPS_MEMALIGN} STREQUAL "0")
   target_compile_definitions(lammps PRIVATE -DLAMMPS_MEMALIGN=${LAMMPS_MEMALIGN})
 endif()
 
+# this hack is required to compile fmt lib with CrayClang version 15.0.2
+# CrayClang is only directly recognized by CMake version 3.28 and later
+if(CMAKE_VERSION VERSION_LESS 3.28)
+  get_filename_component(_exe "${CMAKE_CXX_COMPILER}" NAME)
+  if((CMAKE_CXX_COMPILER_ID STREQUAL "Clang") AND (_exe STREQUAL "crayCC"))
+    target_compile_definitions(lammps PRIVATE -DFMT_STATIC_THOUSANDS_SEPARATOR)
+  endif()
+else()
+  if(CMAKE_CXX_COMPILER_ID STREQUAL "CrayClang")
+    target_compile_definitions(lammps PRIVATE -DFMT_STATIC_THOUSANDS_SEPARATOR)
+  endif()
+endif()
+
 # "hard" dependencies between packages resulting
 # in an error instead of skipping over files
 pkg_depends(ML-IAP ML-SNAP)
@@ -465,6 +451,7 @@ pkg_depends(ELECTRODE KSPACE)
 pkg_depends(EXTRA-MOLECULE MOLECULE)
 pkg_depends(MESONT MOLECULE)
 pkg_depends(RHEO BPM)
+pkg_depends(APIP ML-PACE)
 
 # detect if we may enable OpenMP support by default
 set(BUILD_OMP_DEFAULT OFF)
@@ -507,13 +494,13 @@ if(BUILD_OMP)
   if(CMAKE_VERSION VERSION_LESS 3.28)
     get_filename_component(_exe "${CMAKE_CXX_COMPILER}" NAME)
     if((CMAKE_CXX_COMPILER_ID STREQUAL "Clang") AND (_exe STREQUAL "crayCC"))
-      set(CMAKE_SHARED_LINKER_FLAGS_${BTYPE} "${CMAKE_SHARED_LINKER_FLAGS_${BTYPE}} -fopenmp")
-      set(CMAKE_STATIC_LINKER_FLAGS_${BTYPE} "${CMAKE_STATIC_LINKER_FLAGS_${BTYPE}} -fopenmp")
+      set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -fopenmp")
+      set(CMAKE_STATIC_LINKER_FLAGS "${CMAKE_STATIC_LINKER_FLAGS} -fopenmp")
     endif()
   else()
     if(CMAKE_CXX_COMPILER_ID STREQUAL "CrayClang")
-      set(CMAKE_SHARED_LINKER_FLAGS_${BTYPE} "${CMAKE_SHARED_LINKER_FLAGS_${BTYPE}} -fopenmp")
-      set(CMAKE_STATIC_LINKER_FLAGS_${BTYPE} "${CMAKE_STATIC_LINKER_FLAGS_${BTYPE}} -fopenmp")
+      set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -fopenmp")
+      set(CMAKE_STATIC_LINKER_FLAGS "${CMAKE_STATIC_LINKER_FLAGS} -fopenmp")
     endif()
   endif()
 endif()
@@ -531,7 +518,6 @@ if((CMAKE_CXX_COMPILER_ID STREQUAL "Intel") AND (CMAKE_CXX_STANDARD GREATER_EQUA
 endif()
 
 if(PKG_ATC OR PKG_AWPMD OR PKG_ML-QUIP OR PKG_ML-POD OR PKG_ELECTRODE OR PKG_RHEO OR BUILD_TOOLS)
-  enable_language(C)
   if (NOT USE_INTERNAL_LINALG)
     find_package(LAPACK)
     find_package(BLAS)
@@ -628,10 +614,6 @@ if(WITH_SWIG)
   add_subdirectory(${LAMMPS_SWIG_DIR} swig)
 endif()
 
-set(CMAKE_TUNE_FLAGS "${CMAKE_TUNE_DEFAULT}" CACHE STRING "Compiler and machine specific optimization flags (compilation only)")
-separate_arguments(CMAKE_TUNE_FLAGS)
-target_compile_options(lammps PRIVATE ${CMAKE_TUNE_FLAGS})
-target_compile_options(lmp PRIVATE ${CMAKE_TUNE_FLAGS})
 ########################################################################
 # Basic system tests (standard libraries, headers, functions, types)   #
 ########################################################################

cmake/Modules/LAMMPSInterfacePlugin.cmake

@@ -62,6 +62,9 @@ if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
 endif()
 set(CMAKE_POSITION_INDEPENDENT_CODE TRUE)
 
+# skip over obsolete MPI-2 C++ bindings
+set(MPI_CXX_SKIP_MPICXX TRUE)
+
 #######
 # helper functions from LAMMPSUtils.cmake
 function(validate_option name values)
@@ -128,8 +131,7 @@ endif()
 ################################################################################
 # MPI configuration
 if(NOT CMAKE_CROSSCOMPILING)
-  set(MPI_CXX_SKIP_MPICXX TRUE)
-  find_package(MPI QUIET)
+  find_package(MPI QUIET COMPONENTS CXX)
   option(BUILD_MPI "Build MPI version" ${MPI_FOUND})
 else()
   option(BUILD_MPI "Build MPI version" OFF)
@@ -141,9 +143,6 @@ if(BUILD_MPI)
   set(MPI_CXX_SKIP_MPICXX TRUE)
   # We use a non-standard procedure to cross-compile with MPI on Windows
   if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND CMAKE_CROSSCOMPILING)
-    # Download and configure MinGW compatible MPICH development files for Windows
-    option(USE_MSMPI "Use Microsoft's MS-MPI SDK instead of MPICH2-1.4.1" OFF)
-    if(USE_MSMPI)
     message(STATUS "Downloading and configuring MS-MPI 10.1 for Windows cross-compilation")
     set(MPICH2_WIN64_DEVEL_URL "${LAMMPS_THIRDPARTY_URL}/msmpi-win64-devel.tar.gz" CACHE STRING "URL for MS-MPI (win64) tarball")
     set(MPICH2_WIN64_DEVEL_MD5 "86314daf1bffb809f1fcbefb8a547490" CACHE STRING "MD5 checksum of MS-MPI (win64) tarball")
@@ -167,52 +166,15 @@ if(BUILD_MPI)
     set_target_properties(MPI::MPI_CXX PROPERTIES
       IMPORTED_LOCATION "${SOURCE_DIR}/lib/libmsmpi.a"
       INTERFACE_INCLUDE_DIRECTORIES "${SOURCE_DIR}/include"
-        INTERFACE_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
+      INTERFACE_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX=1")
     add_dependencies(MPI::MPI_CXX mpi4win_build)
 
     # set variables for status reporting at the end of CMake run
     set(MPI_CXX_INCLUDE_PATH "${SOURCE_DIR}/include")
-      set(MPI_CXX_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
+    set(MPI_CXX_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX=1")
     set(MPI_CXX_LIBRARIES "${SOURCE_DIR}/lib/libmsmpi.a")
   else()
-      # Download and configure custom MPICH files for Windows
-      message(STATUS "Downloading and configuring MPICH-1.4.1 for Windows")
-      set(MPICH2_WIN64_DEVEL_URL "${LAMMPS_THIRDPARTY_URL}/mpich2-win64-devel.tar.gz" CACHE STRING "URL for MPICH2 (win64) tarball")
-      set(MPICH2_WIN64_DEVEL_MD5 "4939fdb59d13182fd5dd65211e469f14" CACHE STRING "MD5 checksum of MPICH2 (win64) tarball")
-      mark_as_advanced(MPICH2_WIN64_DEVEL_URL)
-      mark_as_advanced(MPICH2_WIN64_DEVEL_MD5)
-
-      include(ExternalProject)
-      if(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
-        ExternalProject_Add(mpi4win_build
-          URL     ${MPICH2_WIN64_DEVEL_URL}
-          URL_MD5 ${MPICH2_WIN64_DEVEL_MD5}
-          CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
-          BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmpi.a)
-      else()
-        ExternalProject_Add(mpi4win_build
-          URL     ${MPICH2_WIN32_DEVEL_URL}
-          URL_MD5 ${MPICH2_WIN32_DEVEL_MD5}
-          CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
-          BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmpi.a)
-      endif()
-
-      ExternalProject_get_property(mpi4win_build SOURCE_DIR)
-      file(MAKE_DIRECTORY "${SOURCE_DIR}/include")
-      add_library(MPI::MPI_CXX UNKNOWN IMPORTED)
-      set_target_properties(MPI::MPI_CXX PROPERTIES
-        IMPORTED_LOCATION "${SOURCE_DIR}/lib/libmpi.a"
-        INTERFACE_INCLUDE_DIRECTORIES "${SOURCE_DIR}/include"
-        INTERFACE_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
-      add_dependencies(MPI::MPI_CXX mpi4win_build)
-
-      # set variables for status reporting at the end of CMake run
-      set(MPI_CXX_INCLUDE_PATH "${SOURCE_DIR}/include")
-      set(MPI_CXX_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
-      set(MPI_CXX_LIBRARIES "${SOURCE_DIR}/lib/libmpi.a")
-    endif()
-  else()
-    find_package(MPI REQUIRED)
+    find_package(MPI REQUIRED COMPONENTS CXX)
     option(LAMMPS_LONGLONG_TO_LONG "Workaround if your system or MPI version does not recognize 'long long' data types" OFF)
     if(LAMMPS_LONGLONG_TO_LONG)
       target_compile_definitions(lammps INTERFACE -DLAMMPS_LONGLONG_TO_LONG)

cmake/Modules/LAMMPSUtils.cmake

@@ -30,7 +30,7 @@ function(check_omp_h_include)
   if(OpenMP_CXX_FOUND)
     set(CMAKE_REQUIRED_FLAGS ${OpenMP_CXX_FLAGS})
     set(CMAKE_REQUIRED_INCLUDES ${OpenMP_CXX_INCLUDE_DIRS})
-    set(CMAKE_REQUIRED_LINK_OPTIONS ${OpenMP_CXX_FLAGS})
+    separate_arguments(CMAKE_REQUIRED_LINK_OPTIONS NATIVE_COMMAND ${OpenMP_CXX_FLAGS}) # needs to be a list
     set(CMAKE_REQUIRED_LIBRARIES ${OpenMP_CXX_LIBRARIES})
     # there are all kinds of problems with finding omp.h
     # for Clang and derived compilers so we pretend it is there.
@@ -75,13 +75,25 @@ function(get_lammps_version version_header variable)
     list(FIND MONTHS "${month}" month)
     string(LENGTH ${day} day_length)
     string(LENGTH ${month} month_length)
-    if(day_length EQUAL 1)
-        set(day "0${day}")
+    # no leading zero needed for new version string with dots
+    # if(day_length EQUAL 1)
+    #   set(day "0${day}")
+    # endif()
+    # if(month_length EQUAL 1)
+    #   set(month "0${month}")
+    #endif()
+    file(STRINGS ${version_header} line REGEX LAMMPS_UPDATE)
+    string(REGEX REPLACE "#define LAMMPS_UPDATE \"Update ([0-9]+)\"" "\\1" tweak "${line}")
+    if (line MATCHES "#define LAMMPS_UPDATE \"(Maintenance|Development)\"")
+      set(tweak "99")
     endif()
-    if(month_length EQUAL 1)
-        set(month "0${month}")
+    if(NOT tweak)
+      set(tweak "0")
     endif()
-    set(${variable} "${year}${month}${day}" PARENT_SCOPE)
+    # new version string with dots
+    set(${variable} "${year}.${month}.${day}.${tweak}" PARENT_SCOPE)
+    # old version string without dots
+    # set(${variable} "${year}${month}${day}" PARENT_SCOPE)
 endfunction()
 
 function(check_for_autogen_files source_dir)

cmake/Modules/MPI4WIN.cmake

@@ -1,74 +1,31 @@
-# Download and configure MinGW compatible MPICH development files for Windows
-option(USE_MSMPI "Use Microsoft's MS-MPI SDK instead of MPICH2-1.4.1" OFF)
+# set-up MS-MPI library for Windows with MinGW compatibility
+message(STATUS "Downloading and configuring MS-MPI 10.1 for Windows cross-compilation")
+set(MPICH2_WIN64_DEVEL_URL "${LAMMPS_THIRDPARTY_URL}/msmpi-win64-devel.tar.gz" CACHE STRING "URL for MS-MPI (win64) tarball")
+set(MPICH2_WIN64_DEVEL_MD5 "86314daf1bffb809f1fcbefb8a547490" CACHE STRING "MD5 checksum of MS-MPI (win64) tarball")
+mark_as_advanced(MPICH2_WIN64_DEVEL_URL)
+mark_as_advanced(MPICH2_WIN64_DEVEL_MD5)
 
-if(USE_MSMPI)
-  message(STATUS "Downloading and configuring MS-MPI 10.1 for Windows cross-compilation")
-  set(MPICH2_WIN64_DEVEL_URL "${LAMMPS_THIRDPARTY_URL}/msmpi-win64-devel.tar.gz" CACHE STRING "URL for MS-MPI (win64) tarball")
-  set(MPICH2_WIN64_DEVEL_MD5 "86314daf1bffb809f1fcbefb8a547490" CACHE STRING "MD5 checksum of MS-MPI (win64) tarball")
-  mark_as_advanced(MPICH2_WIN64_DEVEL_URL)
-  mark_as_advanced(MPICH2_WIN64_DEVEL_MD5)
-
-  include(ExternalProject)
-  if(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
+include(ExternalProject)
+if(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
   ExternalProject_Add(mpi4win_build
     URL     ${MPICH2_WIN64_DEVEL_URL}
     URL_MD5 ${MPICH2_WIN64_DEVEL_MD5}
     CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
     BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmsmpi.a)
-  else()
+else()
   message(FATAL_ERROR "Only x86 64-bit builds are supported with MS-MPI")
-  endif()
+endif()
 
-  ExternalProject_get_property(mpi4win_build SOURCE_DIR)
-  file(MAKE_DIRECTORY "${SOURCE_DIR}/include")
-  add_library(MPI::MPI_CXX UNKNOWN IMPORTED)
-  set_target_properties(MPI::MPI_CXX PROPERTIES
+ExternalProject_get_property(mpi4win_build SOURCE_DIR)
+file(MAKE_DIRECTORY "${SOURCE_DIR}/include")
+add_library(MPI::MPI_CXX UNKNOWN IMPORTED)
+set_target_properties(MPI::MPI_CXX PROPERTIES
   IMPORTED_LOCATION "${SOURCE_DIR}/lib/libmsmpi.a"
   INTERFACE_INCLUDE_DIRECTORIES "${SOURCE_DIR}/include"
-    INTERFACE_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
-  add_dependencies(MPI::MPI_CXX mpi4win_build)
+  INTERFACE_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX=1")
+add_dependencies(MPI::MPI_CXX mpi4win_build)
 
-  # set variables for status reporting at the end of CMake run
-  set(MPI_CXX_INCLUDE_PATH "${SOURCE_DIR}/include")
-  set(MPI_CXX_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
-  set(MPI_CXX_LIBRARIES "${SOURCE_DIR}/lib/libmsmpi.a")
-else()
-  message(STATUS "Downloading and configuring MPICH2-1.4.1 for Windows cross-compilation")
-  set(MPICH2_WIN64_DEVEL_URL "${LAMMPS_THIRDPARTY_URL}/mpich2-win64-devel.tar.gz" CACHE STRING "URL for MPICH2 (win64) tarball")
-  set(MPICH2_WIN32_DEVEL_URL "${LAMMPS_THIRDPARTY_URL}/mpich2-win32-devel.tar.gz" CACHE STRING "URL for MPICH2 (win32) tarball")
-  set(MPICH2_WIN64_DEVEL_MD5 "4939fdb59d13182fd5dd65211e469f14" CACHE STRING "MD5 checksum of MPICH2 (win64) tarball")
-  set(MPICH2_WIN32_DEVEL_MD5 "a61d153500dce44e21b755ee7257e031" CACHE STRING "MD5 checksum of MPICH2 (win32) tarball")
-  mark_as_advanced(MPICH2_WIN64_DEVEL_URL)
-  mark_as_advanced(MPICH2_WIN32_DEVEL_URL)
-  mark_as_advanced(MPICH2_WIN64_DEVEL_MD5)
-  mark_as_advanced(MPICH2_WIN32_DEVEL_MD5)
-
-  include(ExternalProject)
-  if(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
-    ExternalProject_Add(mpi4win_build
-      URL     ${MPICH2_WIN64_DEVEL_URL}
-      URL_MD5 ${MPICH2_WIN64_DEVEL_MD5}
-      CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
-      BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmpi.a)
-  else()
-    ExternalProject_Add(mpi4win_build
-      URL     ${MPICH2_WIN32_DEVEL_URL}
-      URL_MD5 ${MPICH2_WIN32_DEVEL_MD5}
-      CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
-      BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmpi.a)
-  endif()
-
-  ExternalProject_get_property(mpi4win_build SOURCE_DIR)
-  file(MAKE_DIRECTORY "${SOURCE_DIR}/include")
-  add_library(MPI::MPI_CXX UNKNOWN IMPORTED)
-  set_target_properties(MPI::MPI_CXX PROPERTIES
-    IMPORTED_LOCATION "${SOURCE_DIR}/lib/libmpi.a"
-    INTERFACE_INCLUDE_DIRECTORIES "${SOURCE_DIR}/include"
-    INTERFACE_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
-  add_dependencies(MPI::MPI_CXX mpi4win_build)
-
-  # set variables for status reporting at the end of CMake run
-  set(MPI_CXX_INCLUDE_PATH "${SOURCE_DIR}/include")
-  set(MPI_CXX_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
-  set(MPI_CXX_LIBRARIES "${SOURCE_DIR}/lib/libmpi.a")
-endif()
+# set variables for status reporting at the end of CMake run
+set(MPI_CXX_INCLUDE_PATH "${SOURCE_DIR}/include")
+set(MPI_CXX_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX=1")
+set(MPI_CXX_LIBRARIES "${SOURCE_DIR}/lib/libmsmpi.a")

cmake/Modules/Packages/COLVARS.cmake

@@ -14,10 +14,6 @@ endif()
 
 add_library(colvars STATIC ${COLVARS_SOURCES})
 target_compile_definitions(colvars PRIVATE -DCOLVARS_LAMMPS)
-separate_arguments(CMAKE_TUNE_FLAGS)
-foreach(_FLAG ${CMAKE_TUNE_FLAGS})
-  target_compile_options(colvars PRIVATE ${_FLAG})
-endforeach()
 set_target_properties(colvars PROPERTIES OUTPUT_NAME lammps_colvars${LAMMPS_MACHINE})
 target_include_directories(colvars PUBLIC ${LAMMPS_LIB_SOURCE_DIR}/colvars)
 # The line below is needed to locate math_eigen_impl.h
@@ -30,6 +26,10 @@ if(BUILD_OMP)
   target_link_libraries(colvars PRIVATE OpenMP::OpenMP_CXX)
 endif()
 
+if(BUILD_MPI)
+  target_link_libraries(colvars PUBLIC MPI::MPI_CXX)
+endif()
+
 if(COLVARS_DEBUG)
   # Need to export the define publicly to be valid in interface code
   target_compile_definitions(colvars PUBLIC -DCOLVARS_DEBUG)

cmake/Modules/Packages/EXTRA-COMMAND.cmake

@@ -1,10 +1,18 @@
 # the geturl command needs libcurl
 
-find_package(CURL QUIET COMPONENTS HTTP HTTPS)
+find_package(CURL QUIET)
 option(WITH_CURL "Enable libcurl support" ${CURL_FOUND})
 if(WITH_CURL)
-  find_package(CURL REQUIRED COMPONENTS HTTP HTTPS)
   target_compile_definitions(lammps PRIVATE -DLAMMPS_CURL)
+
+  # need to use pkgconfig for fully static bins to find custom static libs
+  if (CMAKE_SYSTEM_NAME STREQUAL "LinuxMUSL")
+    include(FindPkgConfig)
+    pkg_check_modules(CURL IMPORTED_TARGET libcurl libssl libcrypto)
+    target_link_libraries(lammps PUBLIC PkgConfig::CURL)
+  else()
+    find_package(CURL REQUIRED)
     target_link_libraries(lammps PRIVATE CURL::libcurl)
+  endif()
 endif()
 

cmake/Modules/Packages/GPU.cmake

@@ -189,7 +189,7 @@ if(GPU_API STREQUAL "CUDA")
   endif()
 
   add_executable(nvc_get_devices ${LAMMPS_LIB_SOURCE_DIR}/gpu/geryon/ucl_get_devices.cpp)
-  target_compile_definitions(nvc_get_devices PRIVATE -DUCL_CUDADR)
+  target_compile_definitions(nvc_get_devices PRIVATE -DUCL_CUDADR -DLAMMPS_${LAMMPS_SIZES})
   target_link_libraries(nvc_get_devices PRIVATE ${CUDA_LIBRARIES} ${CUDA_CUDA_LIBRARY})
   target_include_directories(nvc_get_devices PRIVATE ${CUDA_INCLUDE_DIRS})
 
@@ -489,7 +489,7 @@ else()
   target_link_libraries(gpu PRIVATE mpi_stubs)
 endif()
 
-target_compile_definitions(gpu PRIVATE -DLAMMPS_${LAMMPS_SIZES})
 set_target_properties(gpu PROPERTIES OUTPUT_NAME lammps_gpu${LAMMPS_MACHINE})
+target_compile_definitions(gpu PRIVATE -DLAMMPS_${LAMMPS_SIZES})
 target_sources(lammps PRIVATE ${GPU_SOURCES})
 target_include_directories(lammps PRIVATE ${GPU_SOURCES_DIR})

cmake/Modules/Packages/KOKKOS.cmake

@@ -57,8 +57,8 @@ if(DOWNLOAD_KOKKOS)
   list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_CXX_EXTENSIONS=${CMAKE_CXX_EXTENSIONS}")
   list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}")
   include(ExternalProject)
-  set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/4.6.00.tar.gz" CACHE STRING "URL for KOKKOS tarball")
-  set(KOKKOS_MD5 "61b2b69ae50d83eedcc7d47a3fa3d6cb" CACHE STRING "MD5 checksum of KOKKOS tarball")
+  set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/4.6.02.tar.gz" CACHE STRING "URL for KOKKOS tarball")
+  set(KOKKOS_MD5 "14c02fac07bfcec48a1654f88ddee9c6" CACHE STRING "MD5 checksum of KOKKOS tarball")
   mark_as_advanced(KOKKOS_URL)
   mark_as_advanced(KOKKOS_MD5)
   GetFallbackURL(KOKKOS_URL KOKKOS_FALLBACK)
@@ -83,7 +83,7 @@ if(DOWNLOAD_KOKKOS)
   add_dependencies(LAMMPS::KOKKOSCORE kokkos_build)
   add_dependencies(LAMMPS::KOKKOSCONTAINERS kokkos_build)
 elseif(EXTERNAL_KOKKOS)
-  find_package(Kokkos 4.6.00 REQUIRED CONFIG)
+  find_package(Kokkos 4.6.02 REQUIRED CONFIG)
   target_link_libraries(lammps PRIVATE Kokkos::kokkos)
 else()
   set(LAMMPS_LIB_KOKKOS_SRC_DIR ${LAMMPS_LIB_SOURCE_DIR}/kokkos)

cmake/Modules/Packages/MC.cmake

@@ -7,3 +7,23 @@ if(NOT PKG_MANYBODY)
   list(REMOVE_ITEM LAMMPS_SOURCES ${LAMMPS_SOURCE_DIR}/MC/fix_sgcmc.cpp)
   set_property(TARGET lammps PROPERTY SOURCES "${LAMMPS_SOURCES}")
 endif()
+
+# fix hmc may only be installed if also fix rigid/small from RIGID is installed
+if(NOT PKG_RIGID)
+  get_property(LAMMPS_FIX_HEADERS GLOBAL PROPERTY FIX)
+  list(REMOVE_ITEM LAMMPS_FIX_HEADERS ${LAMMPS_SOURCE_DIR}/MC/fix_hmc.h)
+  set_property(GLOBAL PROPERTY FIX "${LAMMPS_FIX_HEADERS}")
+  get_target_property(LAMMPS_SOURCES lammps SOURCES)
+  list(REMOVE_ITEM LAMMPS_SOURCES ${LAMMPS_SOURCE_DIR}/MC/fix_hmc.cpp)
+  set_property(TARGET lammps PROPERTY SOURCES "${LAMMPS_SOURCES}")
+endif()
+
+# fix neighbor/swap may only be installed if also the VORONOI package is installed
+if(NOT PKG_VORONOI)
+  get_property(LAMMPS_FIX_HEADERS GLOBAL PROPERTY FIX)
+  list(REMOVE_ITEM LAMMPS_FIX_HEADERS ${LAMMPS_SOURCE_DIR}/MC/fix_neighbor_swap.h)
+  set_property(GLOBAL PROPERTY FIX "${LAMMPS_FIX_HEADERS}")
+  get_target_property(LAMMPS_SOURCES lammps SOURCES)
+  list(REMOVE_ITEM LAMMPS_SOURCES ${LAMMPS_SOURCE_DIR}/MC/fix_neighbor_swap.cpp)
+  set_property(TARGET lammps PROPERTY SOURCES "${LAMMPS_SOURCES}")
+endif()

cmake/Modules/Packages/ML-PACE.cmake

@@ -53,7 +53,13 @@ else()
       add_library(yaml-cpp::yaml-cpp ALIAS yaml-cpp)
     endif()
 
-    add_subdirectory(${lib-pace} build-pace)
+    # fixup yaml-cpp/emitterutils.cpp for GCC 15+ until patch is applied
+    file(READ ${lib-pace}/yaml-cpp/src/emitterutils.cpp yaml_emitterutils)
+    string(REPLACE "#include <sstream>" "#include <sstream>\n#include <cinttypes>" yaml_tmp_emitterutils "${yaml_emitterutils}")
+    string(REPLACE "#include <cinttypes>\n#include <cinttypes>" "#include <cinttypes>" yaml_emitterutils "${yaml_tmp_emitterutils}")
+    file(WRITE ${lib-pace}/yaml-cpp/src/emitterutils.cpp "${yaml_emitterutils}")
+
+    add_subdirectory(${lib-pace} build-pace EXCLUDE_FROM_ALL)
     set_target_properties(pace PROPERTIES CXX_EXTENSIONS ON OUTPUT_NAME lammps_pace${LAMMPS_MACHINE})
 
     if(CMAKE_PROJECT_NAME STREQUAL "lammps")

cmake/Modules/Packages/SCAFACOS.cmake

@@ -14,27 +14,16 @@ endif()
 option(DOWNLOAD_SCAFACOS "Download ScaFaCoS library instead of using an already installed one" ${DOWNLOAD_SCAFACOS_DEFAULT})
 if(DOWNLOAD_SCAFACOS)
   message(STATUS "ScaFaCoS download requested - we will build our own")
-  set(SCAFACOS_URL "https://github.com/scafacos/scafacos/releases/download/v1.0.1/scafacos-1.0.1.tar.gz" CACHE STRING "URL for SCAFACOS tarball")
-  set(SCAFACOS_MD5 "bd46d74e3296bd8a444d731bb10c1738" CACHE STRING "MD5 checksum of SCAFACOS tarball")
+  set(SCAFACOS_URL "https://github.com/scafacos/scafacos/releases/download/v1.0.4/scafacos-1.0.4.tar.gz" CACHE STRING "URL for SCAFACOS tarball")
+  set(SCAFACOS_MD5 "23867540ec32e63ce71d6ecc105278d2" 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
-          EXPECTED_HASH MD5=4baa1333bb28fcce102d505e1992d032)
-
-  find_program(HAVE_PATCH patch)
-  if(NOT HAVE_PATCH)
-    message(FATAL_ERROR "The 'patch' program is required to build the ScaFaCoS library")
-  endif()
-
   include(ExternalProject)
   ExternalProject_Add(scafacos_build
     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
                                              --enable-fcs-solvers=fmm,p2nfft,direct,ewald,p3m
                                              --with-internal-fftw --with-internal-pfft

cmake/Modules/Testing.cmake

@@ -21,11 +21,11 @@ if(ENABLE_TESTING)
   # also only verified with Fedora Linux > 30 and Ubuntu 18.04 or 22.04+(Ubuntu 20.04 fails)
   if((CMAKE_SYSTEM_NAME STREQUAL "Linux")
       AND ((CMAKE_CXX_COMPILER_ID STREQUAL "GNU") OR (CMAKE_CXX_COMPILER_ID STREQUAL "Clang")))
-    if(((CMAKE_LINUX_DISTRO STREQUAL "Ubuntu") AND
-          ((CMAKE_DISTRO_VERSION VERSION_LESS_EQUAL 18.04) OR (CMAKE_DISTRO_VERSION VERSION_GREATER_EQUAL 22.04)))
+    if(((CMAKE_LINUX_DISTRO STREQUAL "Ubuntu") AND (CMAKE_DISTRO_VERSION VERSION_GREATER_EQUAL 22.04))
         OR ((CMAKE_LINUX_DISTRO STREQUAL "Fedora") AND (CMAKE_DISTRO_VERSION VERSION_GREATER 30)))
       include(CheckCXXCompilerFlag)
       set(CMAKE_CUSTOM_LINKER_DEFAULT default)
+      check_cxx_compiler_flag(--ld-path=${CMAKE_LINKER} HAVE_LD_PATH_FLAG)
       check_cxx_compiler_flag(-fuse-ld=mold HAVE_MOLD_LINKER_FLAG)
       check_cxx_compiler_flag(-fuse-ld=lld HAVE_LLD_LINKER_FLAG)
       check_cxx_compiler_flag(-fuse-ld=gold HAVE_GOLD_LINKER_FLAG)
@@ -50,6 +50,17 @@ if(ENABLE_TESTING)
       if(NOT "${CMAKE_CUSTOM_LINKER}" STREQUAL "default")
         target_link_options(lammps PUBLIC -fuse-ld=${CMAKE_CUSTOM_LINKER})
       endif()
+      if(HAVE_LD_PATH_FLAG)
+        if("${CMAKE_CUSTOM_LINKER}" STREQUAL "mold")
+          target_link_options(lammps PUBLIC --ld-path=${HAVE_MOLD_LINKER_BIN})
+        elseif("${CMAKE_CUSTOM_LINKER}" STREQUAL "lld")
+          target_link_options(lammps PUBLIC --ld-path=${HAVE_LLD_LINKER_BIN})
+        elseif("${CMAKE_CUSTOM_LINKER}" STREQUAL "gold")
+          target_link_options(lammps PUBLIC --ld-path=${HAVE_GOLD_LINKER_BIN})
+        elseif("${CMAKE_CUSTOM_LINKER}" STREQUAL "bfd")
+          target_link_options(lammps PUBLIC --ld-path=${HAVE_BFD_LINKER_BIN})
+        endif()
+      endif()
     endif()
   endif()
 

cmake/Modules/Tools.cmake

@@ -6,6 +6,10 @@ if(BUILD_TOOLS)
   add_executable(stl_bin2txt ${LAMMPS_TOOLS_DIR}/stl_bin2txt.cpp)
   install(TARGETS stl_bin2txt DESTINATION ${CMAKE_INSTALL_BINDIR})
 
+  add_executable(reformat-json ${LAMMPS_TOOLS_DIR}/json/reformat-json.cpp)
+  target_include_directories(reformat-json PRIVATE ${LAMMPS_SOURCE_DIR})
+  install(TARGETS reformat-json DESTINATION ${CMAKE_INSTALL_BINDIR})
+
   include(CheckGeneratorSupport)
   if(CMAKE_GENERATOR_SUPPORT_FORTRAN)
     include(CheckLanguage)

cmake/packaging/linux_wrapper.sh

@@ -7,6 +7,11 @@ export LC_ALL=C
 BASEDIR="$(dirname "$0")"
 EXENAME="$(basename "$0")"
 
+# save old settings (for restoring them later)
+OLDPATH="${PATH}"
+OLDLDLIB="${LD_LIBRARY_PATH}"
+
+# prepend path to find our custom executables
 PATH="${BASEDIR}/bin:${PATH}"
 
 # append to LD_LIBRARY_PATH to prefer local (newer) libs
@@ -15,6 +20,8 @@ LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:${BASEDIR}/lib"
 # set some environment variables for LAMMPS etc.
 LAMMPS_POTENTIALS="${BASEDIR}/share/lammps/potentials"
 MSI2LMP_LIBRARY="${BASEDIR}/share/lammps/frc_files"
-export LD_LIBRARY_PATH LAMMPS_POTENTIALS MSI2LMP_LIBRARY PATH
+
+# export everything
+export LD_LIBRARY_PATH LAMMPS_POTENTIALS MSI2LMP_LIBRARY PATH OLDPATH OLDLDLIB
 
 exec "${BASEDIR}/bin/${EXENAME}" "$@"

cmake/packaging/xdg-open

@@ -33,6 +33,14 @@
 #
 #---------------------------------------------
 
+# restore previously saved environment variables, if available
+if [ -n "${OLDPATH}" ]
+then
+    PATH="${OLDPATH}"
+    LD_LIBRARY_PATH="${OLDLDLIB}"
+    export PATH LD_LIBRARY_PATH
+fi
+
 NEW_LIBRARY_PATH="/usr/local/lib64"
 for s in $(echo $LD_LIBRARY_PATH | sed -e 's/:/ /g')
 do \

cmake/presets/all_off.cmake

@@ -4,6 +4,7 @@
 set(ALL_PACKAGES
   ADIOS
   AMOEBA
+  APIP
   ASPHERE
   ATC
   AWPMD

cmake/presets/all_on.cmake

@@ -6,6 +6,7 @@
 set(ALL_PACKAGES
   ADIOS
   AMOEBA
+  APIP
   ASPHERE
   ATC
   AWPMD

cmake/presets/hip_amd.cmake

@@ -19,12 +19,19 @@ set(CMAKE_C_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
 
 set(MPI_CXX "hipcc" CACHE STRING "" FORCE)
 set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
+set(MPI_C "hipcc" CACHE STRING "" FORCE)
+set(MPI_C_COMPILER "mpicc" CACHE STRING "" FORCE)
+
+# change as needed. This is for Fedora Linux 41 and 42
+set(_libomp_root "/usr/lib/clang/18")
+# we need to explicitly specify the include dir, since hipcc will
+# compile each file twice and doesn't find omp.h the second time
 
 unset(HAVE_OMP_H_INCLUDE CACHE)
 set(OpenMP_C "hipcc" CACHE STRING "" FORCE)
-set(OpenMP_C_FLAGS "-fopenmp" CACHE STRING "" FORCE)
+set(OpenMP_C_FLAGS "-fopenmp=libomp -I${_libomp_root}/include" CACHE STRING "" FORCE)
 set(OpenMP_C_LIB_NAMES "omp" CACHE STRING "" FORCE)
 set(OpenMP_CXX "hipcc" CACHE STRING "" FORCE)
-set(OpenMP_CXX_FLAGS "-fopenmp" CACHE STRING "" FORCE)
+set(OpenMP_CXX_FLAGS "-fopenmp=libomp -I${_libomp_root}/include" CACHE STRING "" FORCE)
 set(OpenMP_CXX_LIB_NAMES "omp" CACHE STRING "" FORCE)
 set(OpenMP_omp_LIBRARY "libomp.so" CACHE PATH "" FORCE)

cmake/presets/kokkos-cuda.cmake

@@ -1,9 +1,8 @@
 # preset that enables KOKKOS and selects CUDA compilation with OpenMP
-# enabled as well. The GPU architecture *must* match your hardware
+# enabled as well. The GPU architecture *must* match your hardware (If not manually set, Kokkos will try to autodetect it).
 set(PKG_KOKKOS ON CACHE BOOL "" FORCE)
 set(Kokkos_ENABLE_SERIAL ON CACHE BOOL "" FORCE)
 set(Kokkos_ENABLE_CUDA   ON CACHE BOOL "" FORCE)
-set(Kokkos_ARCH_PASCAL60 ON CACHE BOOL "" FORCE)
 set(BUILD_OMP ON CACHE BOOL "" FORCE)
 get_filename_component(NVCC_WRAPPER_CMD ${CMAKE_CURRENT_SOURCE_DIR}/../lib/kokkos/bin/nvcc_wrapper ABSOLUTE)
 set(CMAKE_CXX_COMPILER ${NVCC_WRAPPER_CMD} CACHE FILEPATH "" FORCE)

cmake/presets/kokkos-hip.cmake

@@ -1,22 +1,21 @@
-# preset that enables KOKKOS and selects HIP compilation with OpenMP
-# enabled as well. Also sets some performance related compiler flags.
+# preset that enables KOKKOS and selects HIP compilation withOUT OpenMP.
+# Kokkos OpenMP is not compatible with the second pass of hipcc.
 set(PKG_KOKKOS ON CACHE BOOL "" FORCE)
 set(Kokkos_ENABLE_SERIAL ON CACHE BOOL "" FORCE)
-set(Kokkos_ENABLE_OPENMP ON CACHE BOOL "" FORCE)
+set(Kokkos_ENABLE_OPENMP OFF CACHE BOOL "" FORCE)
 set(Kokkos_ENABLE_CUDA   OFF CACHE BOOL "" FORCE)
 set(Kokkos_ENABLE_HIP    ON CACHE BOOL "" FORCE)
 set(Kokkos_ARCH_VEGA90A on CACHE BOOL "" FORCE)
 set(Kokkos_ENABLE_HIP_MULTIPLE_KERNEL_INSTANTIATIONS ON CACHE BOOL "" FORCE)
 set(BUILD_OMP ON CACHE BOOL "" FORCE)
 
-set(CMAKE_CXX_COMPILER hipcc CACHE STRING "" FORCE)
-set(CMAKE_TUNE_FLAGS "-munsafe-fp-atomics" CACHE STRING "" FORCE)
+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -munsafe-fp-atomics" CACHE STRING "" FORCE)
 
-# If KSPACE is also enabled, use CUFFT for FFTs
+# If KSPACE is also enabled, use HIPFFT for FFTs
 set(FFT_KOKKOS "HIPFFT" CACHE STRING "" FORCE)
 
 # hide deprecation warnings temporarily for stable release
-set(Kokkos_ENABLE_DEPRECATION_WARNINGS OFF CACHE BOOL "" FORCE)
+#set(Kokkos_ENABLE_DEPRECATION_WARNINGS OFF CACHE BOOL "" FORCE)
 
 # these flags are needed to build with Cray MPICH on OLCF Crusher
 #-D CMAKE_CXX_FLAGS="-I/${MPICH_DIR}/include"

cmake/presets/kokkos-sycl-intel.cmake

@@ -21,9 +21,10 @@ set(CMAKE_C_COMPILER icx CACHE STRING "" FORCE)
 set(CMAKE_Fortran_COMPILER "" CACHE STRING "" FORCE)
 set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
 set(CMAKE_CXX_STANDARD 17 CACHE STRING "" FORCE)
-# Silence everything
-set(CMAKE_CXX_FLAGS "-w" CACHE STRING "" FORCE)
+
+# set(_intel_sycl_flags " -w -fsycl -flink-huge-device-code -fsycl-targets=spir64_gen "
+set(_intel_sycl_flags " -w -fsycl -fsycl-device-code-split=per_kernel -fsycl-targets=spir64_gen ")
+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${_intel_sycl_flags}" CACHE STRING "" FORCE)
+
 #set(CMAKE_EXE_LINKER_FLAGS "-fsycl -flink-huge-device-code -fsycl-targets=spir64_gen " CACHE STRING "" FORCE)
-#set(CMAKE_TUNE_FLAGS "-O3 -fsycl -fsycl-device-code-split=per_kernel -fsycl-targets=spir64_gen" CACHE STRING "" FORCE)
-set(CMAKE_EXE_LINKER_FLAGS "-fsycl -flink-huge-device-code " CACHE STRING "" FORCE)
-set(CMAKE_TUNE_FLAGS "-O3 -fsycl -fsycl-device-code-split=per_kernel " CACHE STRING "" FORCE)
+set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -fsycl -flink-huge-device-code " CACHE STRING "" FORCE)

cmake/presets/kokkos-sycl-nvidia.cmake

@@ -14,5 +14,7 @@ set(Kokkos_ENABLE_DEPRECATION_WARNINGS OFF CACHE BOOL "" FORCE)
 set(CMAKE_CXX_COMPILER clang++ CACHE STRING "" FORCE)
 set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
 set(CMAKE_CXX_STANDARD 17 CACHE STRING "" FORCE)
-set(CMAKE_SHARED_LINKER_FLAGS "-Xsycl-target-frontend -O3" CACHE STRING "" FORCE)
-set(CMAKE_TUNE_FLAGS "-fgpu-inline-threshold=100000 -Xsycl-target-frontend -O3  -Xsycl-target-frontend -ffp-contract=on -Wno-unknown-cuda-version" CACHE STRING "" FORCE)
+set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -Xsycl-target-frontend -O3 " CACHE STRING "" FORCE)
+
+set(_intel_sycl_flags "-fgpu-inline-threshold=100000 -Xsycl-target-frontend -O3  -Xsycl-target-frontend -ffp-contract=on -Wno-unknown-cuda-version")
+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${_intel_sycl_flags}" CACHE STRING "" FORCE)

cmake/presets/mingw-cross.cmake

@@ -91,7 +91,7 @@ endif()
 set(DOWNLOAD_VORO ON CACHE BOOL "" FORCE)
 set(DOWNLOAD_EIGEN3 ON CACHE BOOL "" FORCE)
 set(LAMMPS_MEMALIGN "0" CACHE STRING "" FORCE)
-set(CMAKE_TUNE_FLAGS "-Wno-missing-include-dirs" CACHE STRING "" FORCE)
+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-missing-include-dirs" CACHE STRING "" FORCE)
 set(CMAKE_EXE_LINKER_FLAGS "-Wl,--enable-stdcall-fixup,--as-needed,-lssp" CACHE STRING "" FORCE)
 set(CMAKE_SHARED_LINKER_FLAGS "-Wl,--enable-stdcall-fixup,--as-needed,-lssp" CACHE STRING "" FORCE)
 set(BUILD_TOOLS ON CACHE BOOL "" FORCE)

cmake/presets/nolib.cmake

@@ -3,6 +3,7 @@
 
 set(PACKAGES_WITH_LIB
   ADIOS
+  APIP
   ATC
   AWPMD
   COMPRESS

cmake/presets/windows-intel-llvm.cmake

@@ -5,4 +5,4 @@ set(CMAKE_C_COMPILER "icx" CACHE STRING "" FORCE)
 set(CMAKE_Fortran_COMPILER "ifx" CACHE STRING "" FORCE)
 set(INTEL_LRT_MODE "C++11" CACHE STRING "" FORCE)
 unset(HAVE_OMP_H_INCLUDE CACHE)
-set(CMAKE_TUNE_FLAGS -Wno-unused-command-line-argument)
+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-unused-command-line-argument" CACHE STRING "" FORCE)

doc/Makefile

@@ -99,8 +99,6 @@ html: xmlgen globbed-tocs $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJ
 	@(\
 		. $(VENV)/bin/activate ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
 		sphinx-build -E $(SPHINXEXTRA) -b html -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) html ;\
-		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 "############################################" ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
@@ -162,8 +160,6 @@ epub: xmlgen globbed-tocs $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK)
 	@(\
 		. $(VENV)/bin/activate ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
 		sphinx-build -E $(SPHINXEXTRA) -b epub -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) epub ;\
-		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 ;\
 	)
@@ -183,8 +179,6 @@ pdf: xmlgen globbed-tocs $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK)
 	@(\
 		. $(VENV)/bin/activate ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
 		sphinx-build -E $(SPHINXEXTRA) -b latex -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) latex ;\
-		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 "############################################" ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
 		rst_anchor_check src/*.rst ;\
@@ -256,6 +250,15 @@ link_check : $(VENV) html
 		deactivate ;\
 	)
 
+upgrade: $(VENV)
+	@(\
+		. $(VENV)/bin/activate; \
+		pip $(PIP_OPTIONS) install --upgrade pip; \
+		pip $(PIP_OPTIONS) install --upgrade wheel; \
+		pip $(PIP_OPTIONS) install --upgrade -r $(BUILDDIR)/utils/requirements.txt; \
+		deactivate;\
+	)
+
 xmlgen : doxygen/xml/index.xml
 
 doxygen/Doxyfile: doxygen/Doxyfile.in

doc/graphviz/lammps-releases.dot

@@ -5,13 +5,13 @@ digraph releases {
     github -> develop [label="Merge commits"];
     {
         rank = "same";
-        work [shape="none" label="Development branches:"]
+        work [shape="none" label="Development branches:" fontname="bold"]
         develop [label="'develop' branch" height=0.75];
         maintenance [label="'maintenance' branch" height=0.75];
     };
     {
         rank = "same";
-        upload [shape="none" label="Release branches:"]
+        upload [shape="none" label="Release branches:" fontname="bold"]
         release [label="'release' branch" height=0.75];
         stable [label="'stable' branch" height=0.75];
     };
@@ -22,7 +22,7 @@ digraph releases {
     maintenance -> stable [label="Updates to stable release"];
     {
         rank = "same";
-        tag [shape="none" label="Applied tags:"];
+        tag [shape="none" label="Applied tags:" fontname="bold"];
         patchtag [shape="box" label="patch_<date>"];
         stabletag [shape="box" label="stable_<date>"];
         updatetag [shape="box" label="stable_<date>_update<num>"];

doc/lammps.1

@@ -1,7 +1,7 @@
-.TH LAMMPS "1" "2 April 2025" "2025-04-02"
+.TH LAMMPS "1" "12 June 2025" "2025-06-12"
 .SH NAME
 .B LAMMPS
-\- Molecular Dynamics Simulator.  Version 2 April 2025
+\- Molecular Dynamics Simulator.  Version 12 June 2025
 
 .SH SYNOPSIS
 .B lmp

doc/src/Build.rst

@@ -14,32 +14,10 @@ As an alternative, you can download a package with pre-built executables
 or automated build trees, as described in the :doc:`Install <Install>`
 section of the manual.
 
-Prerequisites
--------------
-
-Which software you need to compile and use LAMMPS strongly depends on
-which :doc:`features and settings <Build_settings>` and which
-:doc:`optional packages <Packages_list>` you are trying to include.
-Common to all is that you need a C++ and C compiler, where the C++
-compiler has to support at least the C++11 standard (note that some
-compilers require command-line flag to activate C++11 support).
-Furthermore, if you are building with CMake, you need at least CMake
-version 3.20 and a compatible build tool (make or ninja-build); if you
-are building the the legacy GNU make based build system you need GNU
-make (other make variants are not going to work since the build system
-uses features unique to GNU make) and a Unix-like build environment with
-a Bourne shell, and shell tools like "sed", "grep", "touch", "test",
-"tr", "cp", "mv", "rm", "ln", "diff" and so on. Parts of LAMMPS
-interface with or use Python version 3.6 or later.
-
-The LAMMPS developers aim to keep LAMMPS very portable and usable -
-at least in parts - on most operating systems commonly used for
-running MD simulations.  Please see the :doc:`section on portablility
-<Intro_portability>` for more details.
-
 .. toctree::
    :maxdepth: 1
 
+   Build_prerequisites
    Build_cmake
    Build_make
    Build_link

doc/src/Build_basics.rst

@@ -212,11 +212,7 @@ LAMMPS.
       You can tell CMake to look for a specific compiler with setting
       CMake variables (listed below) during configuration.  For a few
       common choices, there are also presets in the ``cmake/presets``
-      folder.  For convenience, there is a ``CMAKE_TUNE_FLAGS`` variable
-      that can be set to apply global compiler options (applied to
-      compilation only), to be used for adding compiler or host specific
-      optimization flags in addition to the "flags" variables listed
-      below. You may also specify the corresponding ``CMAKE_*_FLAGS``
+      folder.  You may also specify the corresponding ``CMAKE_*_FLAGS``
       variables individually, if you want to experiment with alternate
       optimization flags.  You should specify all 3 compilers, so that
       the (few) LAMMPS source files written in C or Fortran are built
@@ -266,10 +262,6 @@ LAMMPS.
       ``-C ../cmake/presets/pgi.cmake`` will switch the compiler to the PGI compilers,
       and ``-C ../cmake/presets/nvhpc.cmake`` will switch to the NVHPC compilers.
 
-      Furthermore, you can set ``CMAKE_TUNE_FLAGS`` to specifically add
-      compiler flags to tune for optimal performance on given hosts.
-      This variable is empty by default.
-
       .. note::
 
          When the cmake command completes, it prints a summary to the

doc/src/Build_development.rst

@@ -28,28 +28,6 @@ variable VERBOSE set to 1:
 
 ----------
 
-.. _clang-tidy:
-
-Enable static code analysis with clang-tidy (CMake only)
---------------------------------------------------------
-
-The `clang-tidy tool <https://clang.llvm.org/extra/clang-tidy/>`_ is a
-static code analysis tool to diagnose (and potentially fix) typical
-programming errors or coding style violations.  It has a modular framework
-of tests that can be adjusted to help identifying problems before they
-become bugs and also assist in modernizing large code bases (like LAMMPS).
-It can be enabled for all C++ code with the following CMake flag
-
-.. code-block:: bash
-
-   -D ENABLE_CLANG_TIDY=value    # value = no (default) or yes
-
-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.
-
-----------
-
 .. _iwyu_processing:
 
 Report missing and unneeded '#include' statements (CMake only)
@@ -523,7 +501,7 @@ to do this to install it via pip:
 
 .. code-block:: bash
 
-   pip install git+https://github.com/gcovr/gcovr.git
+   python3 -m pip install gcovr
 
 After post-processing with ``gen_coverage_html`` the results are in
 a folder ``coverage_html`` and can be viewed with a web browser.

doc/src/Build_extras.rst

@@ -35,6 +35,7 @@ This is the list of packages that may require additional steps.
    :columns: 6
 
    * :ref:`ADIOS <adios>`
+   * :ref:`APIP <apip>`
    * :ref:`ATC <atc>`
    * :ref:`AWPMD <awpmd>`
    * :ref:`COLVARS <colvar>`
@@ -614,6 +615,9 @@ They must be specified in uppercase.
    *  - ZEN4
       - HOST
       - AMD Zen4 architecture
+   *  - ZEN5
+      - HOST
+      - AMD Zen5 architecture
    *  - RISCV_SG2042
       - HOST
       - SG2042 (RISC-V) CPUs
@@ -668,6 +672,12 @@ They must be specified in uppercase.
    *  - HOPPER90
       - GPU
       - NVIDIA Hopper generation CC 9.0
+   *  - BLACKWELL100
+      - GPU
+      - NVIDIA Blackwell generation CC 10.0
+   *  - BLACKWELL120
+      - GPU
+      - NVIDIA Blackwell generation CC 12.0
    *  - AMD_GFX906
       - GPU
       - AMD GPU MI50/60
@@ -716,8 +726,11 @@ They must be specified in uppercase.
    *  - INTEL_PVC
       - GPU
       - Intel GPU Ponte Vecchio
+   *  - INTEL_DG2
+      - GPU
+      - Intel GPU DG2
 
-This list was last updated for version 4.6.0 of the Kokkos library.
+This list was last updated for version 4.6.2 of the Kokkos library.
 
 .. tabs::
 
@@ -1272,6 +1285,34 @@ systems.
 
 ----------
 
+.. _apip:
+
+APIP package
+-----------------------------
+
+The APIP package depends on the library of the
+:ref:`ML-PACE <ml-pace>` package.
+The code for the library can be found
+at: `https://github.com/ICAMS/lammps-user-pace/ <https://github.com/ICAMS/lammps-user-pace/>`_
+
+.. tabs::
+
+   .. tab:: CMake build
+
+      No additional settings are needed besides ``-D PKG_APIP=yes``
+      and ``-D PKG_ML-PACE=yes``.
+      One can use a local version of the ML-PACE library instead of
+      automatically downloading the library as described :ref:`here <ml-pace>`.
+
+
+   .. tab:: Traditional make
+
+      You need to install the ML-PACE package *first* and follow
+      the instructions :ref:`here <ml-pace>` before installing
+      the APIP package.
+
+----------
+
 .. _atc:
 
 ATC package

doc/src/Build_manual.rst

@@ -57,6 +57,8 @@ Python interpreter version 3.8 or later, the ``doxygen`` tools and
 internet access to download additional files and tools are required.
 This download is usually only required once or after the documentation
 folder is returned to a pristine state with ``make clean-all``.
+You can also upgrade those packages to their latest available versions
+with ``make upgrade``.
 
 For the documentation build a python virtual environment is set up in
 the folder ``doc/docenv`` and various python packages are installed into
@@ -82,6 +84,7 @@ folder.  The following ``make`` commands are available:
 
    make clean         # remove intermediate RST files created by HTML build
    make clean-all     # remove entire build folder and any cached data
+   make upgrade       # upgrade the python packages in the virtual environment
 
    make anchor_check  # check for duplicate anchor labels
    make style_check   # check for complete and consistent style lists

doc/src/Build_prerequisites.rst

@@ -0,0 +1,22 @@
+Prerequisites
+-------------
+
+Which software you need to compile and use LAMMPS strongly depends on
+which :doc:`features and settings <Build_settings>` and which
+:doc:`optional packages <Packages_list>` you are trying to include.
+Common to all is that you need a C++ and C compiler, where the C++
+compiler has to support at least the C++11 standard (note that some
+compilers require command-line flag to activate C++11 support).
+Furthermore, if you are building with CMake, you need at least CMake
+version 3.20 and a compatible build tool (make or ninja-build); if you
+are building the the legacy GNU make based build system you need GNU
+make (other make variants are not going to work since the build system
+uses features unique to GNU make) and a Unix-like build environment with
+a Bourne shell, and shell tools like "sed", "grep", "touch", "test",
+"tr", "cp", "mv", "rm", "ln", "diff" and so on. Parts of LAMMPS
+interface with or use Python version 3.6 or later.
+
+The LAMMPS developers aim to keep LAMMPS very portable and usable -
+at least in parts - on most operating systems commonly used for
+running MD simulations.  Please see the :doc:`section on portablility
+<Intro_portability>` for more details.

doc/src/Build_settings.rst

@@ -18,7 +18,6 @@ explains how to do this for building both with CMake and make.
 * `Memory allocation alignment`_
 * `Workaround for long long integers`_
 * `Exception handling when using LAMMPS as a library`_ to capture errors
-* `Trigger selected floating-point exceptions`_
 
 ----------
 
@@ -659,40 +658,3 @@ code has to be set up to *catch* exceptions thrown from within LAMMPS.
    throw an exception and thus other MPI ranks may get stuck waiting for
    messages from the ones with errors.
 
-----------
-
-.. _trap_fpe:
-
-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
-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
-recover from such conditions.  This behavior can be changed, however,
-often through use of compiler flags.  On Linux systems (or more general
-on systems using the GNU C library), these so-called floating-point traps
-can also be selectively enabled through library calls.  LAMMPS supports
-that by setting the ``-DLAMMPS_TRAP_FPE`` pre-processor define.  As it is
-done in the ``main()`` function, this applies only to the standalone
-executable, not the library.
-
-.. tabs::
-
-   .. tab:: CMake build
-
-      .. code-block:: bash
-
-         -D CMAKE_TUNE_FLAGS=-DLAMMPS_TRAP_FPE
-
-   .. tab:: Traditional make
-
-      .. code-block:: make
-
-         LMP_INC = -DLAMMPS_TRAP_FPE  <other LMP_INC settings>
-
-After compilation with this flag set, the LAMMPS executable will stop
-and produce a core dump when a division by zero, overflow, illegal math
-function argument or other invalid floating point operation is encountered.

doc/src/Commands_fix.rst

@@ -22,6 +22,7 @@ OPT.
    * :doc:`append/atoms <fix_append_atoms>`
    * :doc:`atc <fix_atc>`
    * :doc:`atom/swap <fix_atom_swap>`
+   * :doc:`atom_weight/apip <fix_atom_weight_apip>`
    * :doc:`ave/atom <fix_ave_atom>`
    * :doc:`ave/chunk <fix_ave_chunk>`
    * :doc:`ave/correlate <fix_ave_correlate>`
@@ -29,6 +30,7 @@ OPT.
    * :doc:`ave/grid <fix_ave_grid>`
    * :doc:`ave/histo <fix_ave_histo>`
    * :doc:`ave/histo/weight <fix_ave_histo>`
+   * :doc:`ave/moments <fix_ave_moments>`
    * :doc:`ave/time <fix_ave_time>`
    * :doc:`aveforce <fix_aveforce>`
    * :doc:`balance <fix_balance>`
@@ -64,7 +66,7 @@ OPT.
    * :doc:`electrode/conp (i) <fix_electrode>`
    * :doc:`electrode/conq (i) <fix_electrode>`
    * :doc:`electrode/thermo (i) <fix_electrode>`
-   * :doc:`electron/stopping <fix_electron_stopping>`
+   * :doc:`electron/stopping (k) <fix_electron_stopping>`
    * :doc:`electron/stopping/fit <fix_electron_stopping>`
    * :doc:`enforce2d (k) <fix_enforce2d>`
    * :doc:`eos/cv <fix_eos_cv>`
@@ -77,6 +79,7 @@ OPT.
    * :doc:`flow/gauss <fix_flow_gauss>`
    * :doc:`freeze (k) <fix_freeze>`
    * :doc:`gcmc <fix_gcmc>`
+   * :doc:`gjf <fix_gjf>`
    * :doc:`gld <fix_gld>`
    * :doc:`gle <fix_gle>`
    * :doc:`gravity (ko) <fix_gravity>`
@@ -84,11 +87,14 @@ OPT.
    * :doc:`halt <fix_halt>`
    * :doc:`heat <fix_heat>`
    * :doc:`heat/flow <fix_heat_flow>`
+   * :doc:`hmc <fix_hmc>`
    * :doc:`hyper/global <fix_hyper_global>`
    * :doc:`hyper/local <fix_hyper_local>`
    * :doc:`imd <fix_imd>`
    * :doc:`indent <fix_indent>`
    * :doc:`ipi <fix_ipi>`
+   * :doc:`lambda/apip <fix_lambda_apip>`
+   * :doc:`lambda_thermostat/apip <fix_lambda_thermostat_apip>`
    * :doc:`langevin (k) <fix_langevin>`
    * :doc:`langevin/drude <fix_langevin_drude>`
    * :doc:`langevin/eff <fix_langevin_eff>`
@@ -111,6 +117,7 @@ OPT.
    * :doc:`mvv/tdpd <fix_mvv_dpd>`
    * :doc:`neb <fix_neb>`
    * :doc:`neb/spin <fix_neb_spin>`
+   * :doc:`neighbor/swap <fix_neighbor_swap>`
    * :doc:`nonaffine/displacement <fix_nonaffine_displacement>`
    * :doc:`nph (ko) <fix_nh>`
    * :doc:`nph/asphere (o) <fix_nph_asphere>`
@@ -216,6 +223,7 @@ OPT.
    * :doc:`rigid/small (o) <fix_rigid>`
    * :doc:`rx (k) <fix_rx>`
    * :doc:`saed/vtk <fix_saed_vtk>`
+   * :doc:`set <fix_set>`
    * :doc:`setforce (k) <fix_setforce>`
    * :doc:`setforce/spin <fix_setforce>`
    * :doc:`sgcmc <fix_sgcmc>`

doc/src/Commands_kspace.rst

@@ -31,3 +31,5 @@ OPT.
    * :doc:`pppm/dielectric <kspace_style>`
    * :doc:`pppm/electrode (i) <kspace_style>`
    * :doc:`scafacos <kspace_style>`
+   * :doc:`zero <kspace_style>`
+

doc/src/Commands_pair.rst

@@ -96,7 +96,9 @@ OPT.
    * :doc:`eam/cd <pair_eam>`
    * :doc:`eam/cd/old <pair_eam>`
    * :doc:`eam/fs (gikot) <pair_eam>`
+   * :doc:`eam/fs/apip <pair_eam_apip>`
    * :doc:`eam/he <pair_eam>`
+   * :doc:`eam/apip <pair_eam_apip>`
    * :doc:`edip (o) <pair_edip>`
    * :doc:`edip/multi <pair_edip>`
    * :doc:`edpd (g) <pair_mesodpd>`
@@ -124,6 +126,9 @@ OPT.
    * :doc:`ilp/tmd (t) <pair_ilp_tmd>`
    * :doc:`kolmogorov/crespi/full <pair_kolmogorov_crespi_full>`
    * :doc:`kolmogorov/crespi/z <pair_kolmogorov_crespi_z>`
+   * :doc:`lambda/input/apip <pair_lambda_input_apip>`
+   * :doc:`lambda/input/csp/apip <pair_lambda_input_apip>`
+   * :doc:`lambda/zone/apip <pair_lambda_zone_apip>`
    * :doc:`lcbop <pair_lcbop>`
    * :doc:`lebedeva/z <pair_lebedeva_z>`
    * :doc:`lennard/mdf <pair_mdf>`
@@ -179,6 +184,7 @@ OPT.
    * :doc:`lj/long/dipole/long <pair_dipole>`
    * :doc:`lj/long/tip4p/long (o) <pair_lj_long>`
    * :doc:`lj/mdf <pair_mdf>`
+   * :doc:`lj/pirani (o) <pair_lj_pirani>`
    * :doc:`lj/relres (o) <pair_lj_relres>`
    * :doc:`lj/spica (gko) <pair_spica>`
    * :doc:`lj/spica/coul/long (gko) <pair_spica>`
@@ -236,6 +242,9 @@ OPT.
    * :doc:`oxrna2/coaxstk <pair_oxrna2>`
    * :doc:`pace (k) <pair_pace>`
    * :doc:`pace/extrapolation (k) <pair_pace>`
+   * :doc:`pace/apip <pair_pace_apip>`
+   * :doc:`pace/fast/apip <pair_pace_apip>`
+   * :doc:`pace/precise/apip <pair_pace_apip>`
    * :doc:`pedone (o) <pair_pedone>`
    * :doc:`pod (k) <pair_pod>`
    * :doc:`peri/eps <pair_peri>`

doc/src/Commands_removed.rst

@@ -1,7 +1,7 @@
 Removed commands and packages
 =============================
 
-.. contents:: \
+.. contents::
 
 ------
 
@@ -12,10 +12,21 @@ stop LAMMPS and print a suitable error message in most cases, when a
 style/command is used that has been removed or will replace the command
 with the direct alternative (if available) and print a warning.
 
+GJF formulation in fix langevin
+-------------------------------
+
+.. deprecated:: 12Jun2025
+
+The *gjf* keyword in fix langevin is deprecated and will be removed
+soon.  The GJF functionality has been moved to its own fix style
+:doc:`fix gjf <fix_gjf>` and it is strongly recommended to use that
+fix instead.
+
+
 LAMMPS shell
 ------------
 
-.. versionchanged:: 29Aug2024
+.. deprecated:: 29Aug2024
 
 The LAMMPS shell has been removed from the LAMMPS distribution. Users
 are encouraged to use the :ref:`LAMMPS-GUI <lammps_gui>` tool instead.
@@ -23,7 +34,7 @@ are encouraged to use the :ref:`LAMMPS-GUI <lammps_gui>` tool instead.
 i-PI tool
 ---------
 
-.. versionchanged:: 27Jun2024
+.. deprecated:: 27Jun2024
 
 The i-PI tool has been removed from the LAMMPS distribution.  Instead,
 instructions to install i-PI from PyPI via pip are provided.

doc/src/Developer_plugins.rst

@@ -68,24 +68,25 @@ Members of ``lammpsplugin_t``
    * - author
      - String with the name and email of the author
    * - creator.v1
-     - Pointer to factory function for pair, bond, angle, dihedral, improper, kspace, or command styles
+     - Pointer to factory function for pair, bond, angle, dihedral, improper, kspace, command, or minimize styles
    * - creator.v2
-     - Pointer to factory function for compute, fix, or region styles
+     - Pointer to factory function for compute, fix, region, or run styles
    * - handle
      - Pointer to the open DSO file handle
 
 Only one of the two alternate creator entries can be used at a time and
 which of those is determined by the style of plugin. The "creator.v1"
 element is for factory functions of supported styles computing forces
-(i.e. pair, bond, angle, dihedral, or improper styles) or command styles
-and the function takes as single argument the pointer to the LAMMPS
-instance. The factory function is cast to the ``lammpsplugin_factory1``
-type before assignment.  The "creator.v2" element is for factory
-functions creating an instance of a fix, compute, or region style and
-takes three arguments: a pointer to the LAMMPS instance, an integer with
-the length of the argument list and a ``char **`` pointer to the list of
-arguments. The factory function pointer needs to be cast to the
-``lammpsplugin_factory2`` type before assignment.
+(i.e. pair, bond, angle, dihedral, or improper styles), command styles,
+or minimize styles and the function takes as single argument the pointer
+to the LAMMPS instance. The factory function is cast to the
+``lammpsplugin_factory1`` type before assignment.  The "creator.v2"
+element is for factory functions creating an instance of a fix, compute,
+region, or run style and takes three arguments: a pointer to the LAMMPS
+instance, an integer with the length of the argument list and a ``char
+**`` pointer to the list of arguments. The factory function pointer
+needs to be cast to the ``lammpsplugin_factory2`` type before
+assignment.
 
 Pair style example
 ^^^^^^^^^^^^^^^^^^
@@ -247,8 +248,8 @@ DSO handle.  The registration function is called with a pointer to the address
 of this struct and the pointer of the LAMMPS class.  The registration function
 will then add the factory function of the plugin style to the respective
 style map under the provided name.  It will also make a copy of the struct
-in a list of all loaded plugins and update the reference counter for loaded
-plugins from this specific DSO file.
+in a global list of all loaded plugins and update the reference counter for
+loaded plugins from this specific DSO file.
 
 The pair style itself (i.e. the PairMorse2 class in this example) can be
 written just like any other pair style that is included in LAMMPS.  For
@@ -263,6 +264,21 @@ the plugin will override the existing code.  This can be used to modify
 the behavior of existing styles or to debug new versions of them without
 having to re-compile or re-install all of LAMMPS.
 
+.. versionchanged:: 12Jun2025
+
+When using the :doc:`clear <clear>` command, plugins are not unloaded
+but restored to their respective style maps.  This also applies when
+multiple LAMMPS instances are created and deleted through the library
+interface.  The :doc:`plugin load <plugin>` load command may be issued
+again, but for existing plugins they will be skipped.  To replace
+plugins they must be explicitly unloaded with :doc:`plugin unload
+<plugin>`.  When multiple LAMMPS instances are created concurrently, any
+loaded plugins will be added to the global list of plugins, but are not
+immediately available to any LAMMPS instance that was created before
+loading the plugin.  To "import" such plugins, the :doc:`plugin restore
+<plugin>` may be used.  Plugins are only removed when they are explicitly
+unloaded or the LAMMPS interface is "finalized".
+
 Compiling plugins
 ^^^^^^^^^^^^^^^^^
 

doc/src/Developer_updating.rst

@@ -29,6 +29,8 @@ Available topics in mostly chronological order are:
 - `Rename of fix STORE/PERATOM to fix STORE/ATOM and change of arguments`_
 - `Use Output::get_dump_by_id() instead of Output::find_dump()`_
 - `Refactored grid communication using Grid3d/Grid2d classes instead of GridComm`_
+- `FLERR as first argument to minimum image functions in Domain class`_
+- `Use utils::logmesg() instead of error->warning()`_
 
 ----
 
@@ -610,3 +612,71 @@ KSpace solvers which use distributed FFT grids:
 - ``src/KSPACE/pppm.cpp``
 
 This change is **required** or else the code will not compile.
+
+FLERR as first argument to minimum image functions in Domain class
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. versionchanged:: 12Jun2025
+
+The ``Domain::minimum_image()`` and ``Domain::minimum_image_big()``
+functions were changed to take the ``FLERR`` macros as first argument.
+This way the error message indicates *where* the function was called
+instead of pointing to the implementation of the function.  Example:
+
+Old:
+
+.. code-block:: c++
+
+   double delx1 = x[i1][0] - x[i2][0];
+   double dely1 = x[i1][1] - x[i2][1];
+   double delz1 = x[i1][2] - x[i2][2];
+   domain->minimum_image(delx1, dely1, delz1);
+   double r1 = sqrt(delx1 * delx1 + dely1 * dely1 + delz1 * delz1);
+
+   double delx2 = x[i3][0] - x[i2][0];
+   double dely2 = x[i3][1] - x[i2][1];
+   double delz2 = x[i3][2] - x[i2][2];
+   domain->minimum_image_big(delx2, dely2, delz2);
+   double r2 = sqrt(delx2 * delx2 + dely2 * dely2 + delz2 * delz2);
+
+New:
+
+.. code-block:: c++
+
+   double delx1 = x[i1][0] - x[i2][0];
+   double dely1 = x[i1][1] - x[i2][1];
+   double delz1 = x[i1][2] - x[i2][2];
+   domain->minimum_image(FLERR, delx1, dely1, delz1);
+   double r1 = sqrt(delx1 * delx1 + dely1 * dely1 + delz1 * delz1);
+
+   double delx2 = x[i3][0] - x[i2][0];
+   double dely2 = x[i3][1] - x[i2][1];
+   double delz2 = x[i3][2] - x[i2][2];
+   domain->minimum_image_big(FLERR, delx2, dely2, delz2);
+   double r2 = sqrt(delx2 * delx2 + dely2 * dely2 + delz2 * delz2);
+
+This change is **required** or else the code will not compile.
+
+Use utils::logmesg() instead of error->warning()
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. versionchanged:: TBD
+
+The ``Error::message()`` method has been removed since its functionality
+has been superseded by the :cpp:func:`utils::logmesg` function.
+
+Old:
+
+.. code-block:: c++
+
+   if (comm->me == 0) {
+     error->message(FLERR, "INFO: About to read data file: {}", filename);
+  }
+
+New:
+
+.. code-block:: c++
+
+   if (comm->me == 0) utils::logmesg(lmp, "INFO: About to read data file: {}\n", filename);
+
+This change is **required** or else the code will not compile.

doc/src/Errors_common.rst

@@ -1,124 +1,149 @@
-Common problems
-===============
+Common issues that are often regarded as bugs
+=============================================
 
-If two LAMMPS runs do not produce the exact same answer on different
-machines or different numbers of processors, this is typically not a
-bug.  In theory you should get identical answers on any number of
-processors and on any machine.  In practice, numerical round-off can
-cause slight differences and eventual divergence of molecular dynamics
-phase space trajectories within a few 100s or few 1000s of timesteps.
-However, the statistical properties of the two runs (e.g. average
-energy or temperature) should still be the same.
+The list below are some random notes on behavior of LAMMPS that is
+sometimes unexpected or even considered a bug.  Most of the time, these
+are just issues of understanding how LAMMPS is implemented and
+parallelized.  Please also have a look at the :doc:`Error details
+discussions page <Errors_details>` that contains recommendations for
+tracking down issues and explanations for error messages that may
+sometimes be confusing or need additional explanations.
 
-If the :doc:`velocity <velocity>` command is used to set initial atom
-velocities, a particular atom can be assigned a different velocity
-when the problem is run on a different number of processors or on
-different machines.  If this happens, the phase space trajectories of
-the two simulations will rapidly diverge.  See the discussion of the
-*loop* option in the :doc:`velocity <velocity>` command for details and
-options that avoid this issue.
+- A LAMMPS simulation typically has two stages, 1) issuing commands
+  and 2) run or minimize.  Most LAMMPS errors are detected in stage 1),
+  others at the beginning of stage 2), and finally others like a bond
+  stretching too far may or lost atoms or bonds may not occur until the
+  middle of a run.
 
-Similarly, the :doc:`create_atoms <create_atoms>` command generates a
-lattice of atoms.  For the same physical system, the ordering and
-numbering of atoms by atom ID may be different depending on the number
-of processors.
+- If two LAMMPS runs do not produce the exact same answer on different
+  machines or different numbers of processors, this is typically not a
+  bug.  In theory you should get identical answers on any number of
+  processors and on any machine.  In practice, numerical round-off can
+  cause slight differences and eventual divergence of molecular dynamics
+  phase space trajectories within a few 100s or few 1000s of timesteps.
+  This can be triggered by different ordering of atoms due to different
+  domain decompositions, but also through different CPU architectures,
+  different operating systems, different compilers or compiler versions,
+  different compiler optimization levels, different FFT libraries.
+  However, the statistical properties of the two runs (e.g. average
+  energy or temperature) should still be the same.
 
-Some commands use random number generators which may be setup to
-produce different random number streams on each processor and hence
-will produce different effects when run on different numbers of
-processors.  A commonly-used example is the :doc:`fix langevin <fix_langevin>` command for thermostatting.
+- If the :doc:`velocity <velocity>` command is used to set initial atom
+  velocities, a particular atom can be assigned a different velocity
+  when the problem is run on a different number of processors or on
+  different machines.  If this happens, the phase space trajectories of
+  the two simulations will rapidly diverge.  See the discussion of the
+  *loop* option in the :doc:`velocity <velocity>` command for details
+  and options that avoid this issue.
 
-A LAMMPS simulation typically has two stages, setup and run.  Most
-LAMMPS errors are detected at setup time; others like a bond
-stretching too far may not occur until the middle of a run.
+- Similarly, the :doc:`create_atoms <create_atoms>` command generates a
+  lattice of atoms.  For the same physical system, the ordering and
+  numbering of atoms by atom ID may be different depending on the number
+  of processors.
 
-LAMMPS tries to flag errors and print informative error messages so
-you can fix the problem.  For most errors it will also print the last
-input script command that it was processing.  Of course, LAMMPS cannot
-figure out your physics or numerical mistakes, like choosing too big a
-timestep, specifying erroneous force field coefficients, or putting 2
-atoms on top of each other!  If you run into errors that LAMMPS
-does not catch that you think it should flag, please send an email to
-the `developers <https://www.lammps.org/authors.html>`_ or create an new
-topic on the dedicated `MatSci forum section <https://matsci.org/lammps/>`_.
+- Some commands use random number generators which may be setup to
+  produce different random number streams on each processor and hence
+  will produce different effects when run on different numbers of
+  processors.  A commonly-used example is the :doc:`fix langevin
+  <fix_langevin>` command for thermostatting.
 
-If you get an error message about an invalid command in your input
-script, you can determine what command is causing the problem by
-looking in the log.lammps file or using the :doc:`echo command <echo>`
-to see it on the screen.  If you get an error like "Invalid ...
-style", with ... being fix, compute, pair, etc, it means that you
-mistyped the style name or that the command is part of an optional
-package which was not compiled into your executable.  The list of
-available styles in your executable can be listed by using
-:doc:`the -h command-line switch <Run_options>`.  The installation and
-compilation of optional packages is explained on the
-:doc:`Build packages <Build_package>` doc page.
+- LAMMPS tries to flag errors and print informative error messages so
+  you can fix the problem.  For most errors it will also print the last
+  input script command that it was processing or even point to the
+  keyword that is causing troubles.  Of course, LAMMPS cannot figure out
+  your physics or numerical mistakes, like choosing too big a timestep,
+  specifying erroneous force field coefficients, or putting 2 atoms on
+  top of each other!  Also, LAMMPS does not know what you *intend* to
+  do, but very strictly applies the syntax as described in the
+  documentation.  If you run into errors that LAMMPS does not catch that
+  you think it should flag, please send an email to the `developers
+  <https://www.lammps.org/authors.html>`_ or create an new topic on the
+  dedicated `MatSci forum section <https://matsci.org/lammps/>`_.
 
-For a given command, LAMMPS expects certain arguments in a specified
-order.  If you mess this up, LAMMPS will often flag the error, but it
-may also simply read a bogus argument and assign a value that is
-valid, but not what you wanted.  E.g. trying to read the string "abc"
-as an integer value of 0.  Careful reading of the associated doc page
-for the command should allow you to fix these problems. In most cases,
-where LAMMPS expects to read a number, either integer or floating point,
-it performs a stringent test on whether the provided input actually
-is an integer or floating-point number, respectively, and reject the
-input with an error message (for instance, when an integer is required,
-but a floating-point number 1.0 is provided):
+- If you get an error message about an invalid command in your input
+  script, you can determine what command is causing the problem by
+  looking in the log.lammps file or using the :doc:`echo command <echo>`
+  to see it on the screen.  If you get an error like "Invalid ...
+  style", with ... being fix, compute, pair, etc, it means that you
+  mistyped the style name or that the command is part of an optional
+  package which was not compiled into your executable.  The list of
+  available styles in your executable can be listed by using
+  :doc:`the -h command-line switch <Run_options>`.  The installation and
+  compilation of optional packages is explained on the :doc:`Build
+  packages <Build_package>` doc page.
 
-.. parsed-literal::
+- For a given command, LAMMPS expects certain arguments in a specified
+  order.  If you mess this up, LAMMPS will often flag the error, but it
+  may also simply read a bogus argument and assign a value that is
+  valid, but not what you wanted.  E.g. trying to read the string "abc"
+  as an integer value of 0.  Careful reading of the associated doc page
+  for the command should allow you to fix these problems. In most cases,
+  where LAMMPS expects to read a number, either integer or floating
+  point, it performs a stringent test on whether the provided input
+  actually is an integer or floating-point number, respectively, and
+  reject the input with an error message (for instance, when an integer
+  is required, but a floating-point number 1.0 is provided):
+
+  .. parsed-literal::
 
      ERROR: Expected integer parameter instead of '1.0' in input script or data file
 
-Some commands allow for using variable references in place of numeric
-constants so that the value can be evaluated and may change over the
-course of a run.  This is typically done with the syntax *v_name* for a
-parameter, where name is the name of the variable. On the other hand,
-immediate variable expansion with the syntax ${name} is performed while
-reading the input and before parsing commands,
+- Some commands allow for using variable references in place of numeric
+  constants so that the value can be evaluated and may change over the
+  course of a run.  This is typically done with the syntax *v_name* for
+  a parameter, where name is the name of the variable. On the other
+  hand, immediate variable expansion with the syntax ${name} is
+  performed while reading the input and before parsing commands,
 
-.. note::
+  .. note::
 
      Using a variable reference (i.e. *v_name*) is only allowed if
      the documentation of the corresponding command explicitly says it is.
      Otherwise, you will receive an error message of this kind:
 
-.. parsed-literal::
+  .. parsed-literal::
 
      ERROR: Expected floating point parameter instead of 'v_name' in input script or data file
 
-Generally, LAMMPS will print a message to the screen and logfile and
-exit gracefully when it encounters a fatal error.  Sometimes it will
-print a WARNING to the screen and logfile and continue on; you can
-decide if the WARNING is important or not.  A WARNING message that is
-generated in the middle of a run is only printed to the screen, not to
-the logfile, to avoid cluttering up thermodynamic output.  If LAMMPS
-crashes or hangs without spitting out an error message first then it
-could be a bug (see :doc:`this section <Errors_bugs>`) or one of the following
-cases:
+- Generally, LAMMPS will print a message to the screen and logfile and
+  exit gracefully when it encounters a fatal error.  When running in
+  parallel this message may be stuck in an I/O buffer and LAMMPS will be
+  terminated before that buffer is printed.  In that case you can try
+  adding the ``-nonblock`` or ``-nb`` command-line flag to turn off that
+  buffering.  Please note that this should not be used for production
+  runs, since turning off buffering usually has a significant negative
+  impact on performance (even worse than :doc:`thermo_modify flush yes
+  <thermo_modify>`).  Sometimes LAMMPS will print a WARNING to the
+  screen and logfile and continue on; you can decide if the WARNING is
+  important or not, but as a general rule do not ignore warnings that
+  you not understand.  A WARNING message that is generated in the middle
+  of a run is only printed to the screen, not to the logfile, to avoid
+  cluttering up thermodynamic output.  If LAMMPS crashes or hangs
+  without generating an error message first then it could be a bug
+  (see :doc:`this section <Errors_bugs>`).
 
-LAMMPS runs in the available memory a processor allows to be
-allocated.  Most reasonable MD runs are compute limited, not memory
-limited, so this should not be a bottleneck on most platforms.  Almost
-all large memory allocations in the code are done via C-style malloc's
-which will generate an error message if you run out of memory.
-Smaller chunks of memory are allocated via C++ "new" statements.  If
-you are unlucky you could run out of memory just when one of these
-small requests is made, in which case the code will crash or hang (in
-parallel), since LAMMPS does not trap on those errors.
+- LAMMPS runs in the available memory a processor allows to be
+  allocated.  Most reasonable MD runs are compute limited, not memory
+  limited, so this should not be a bottleneck on most platforms.  Almost
+  all large memory allocations in the code are done via C-style malloc's
+  which will generate an error message if you run out of memory.
+  Smaller chunks of memory are allocated via C++ "new" statements.  If
+  you are unlucky you could run out of memory just when one of these
+  small requests is made, in which case the code will crash or hang (in
+  parallel).
 
-Illegal arithmetic can cause LAMMPS to run slow or crash.  This is
-typically due to invalid physics and numerics that your simulation is
-computing.  If you see wild thermodynamic values or NaN values in your
-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 ensure your model
-is behaving as you expect.
+- Illegal arithmetic can cause LAMMPS to run slow or crash.  This is
+  typically due to invalid physics and numerics that your simulation is
+  computing.  If you see wild thermodynamic values or NaN values in your
+  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 ensure your model
+  is behaving as you expect.
 
-In parallel, one way LAMMPS can hang is due to how different MPI
-implementations handle buffering of messages.  If the code hangs
-without an error message, it may be that you need to specify an MPI
-setting or two (usually via an environment variable) to enable
-buffering or boost the sizes of messages that can be buffered.
+- When running in parallel with MPI, one way LAMMPS can hang is because
+  LAMMPS has come across an error condition, but only on one or a few
+  MPI processes and not all of them.  LAMMPS has two different "stop
+  with an error message" functions and the correct one has to be called
+  or else it will hang.

doc/src/Errors_details.rst

@@ -51,8 +51,11 @@ Parallel versus serial
 ^^^^^^^^^^^^^^^^^^^^^^
 
 Issues where something is "lost" or "missing" often exhibit that issue
-only when running in parallel.  That doesn't mean there is no problem,
-only the symptoms are not triggering an error quickly.  Correspondingly,
+*only* when running in parallel.  That doesn't mean there is no problem
+when running in serial, only the symptoms are not triggering an error.
+This may be because there is no domain decomposition with just one
+processor and thus all atoms are accessible, or it may be because the
+problem will manifest faster with smaller subdomains.  Correspondingly,
 errors may be triggered faster with more processors and thus smaller
 sub-domains.
 
@@ -159,13 +162,17 @@ angle, dihedral, or improper with just one atom in the actual
 sub-domain.  Typically, this cutoff is set to the largest cutoff from
 the :doc:`pair style(s) <pair_style>` plus the :doc:`neighbor list skin
 distance <neighbor>` and will typically be sufficient for all bonded
-interactions.  But if the pair style cutoff is small, this may not be
-enough.  LAMMPS will print a warning in this case using some heuristic
-based on the equilibrium bond length, but that still may not be
-sufficient for cases where the force constants are small and thus bonds
-may be stretched very far.  The communication cutoff can be adjusted
-with :doc:`comm_modify cutoff \<value\> <comm_modify>`, but setting this
-too large will waste CPU time and memory.
+interactions.  But if the pair style cutoff is small (e.g. with a
+repulsive-only Lennard-Jones potential) this may not be enough.  It is
+even worse if there is no pair style defined (or the pair style is set
+to "none"), since then there will be no ghost atoms created at all.
+
+The communication cutoff can be set or adjusted with :doc:`comm_modify
+cutoff \<value\> <comm_modify>`, but setting this too large will waste
+CPU time and memory.  LAMMPS will print warnings in these cases.  For
+bonds it uses some heuristic based on the equilibrium bond length, but
+that still may not be sufficient for cases where the force constants are
+small and thus bonds may be stretched very far.
 
 .. _hint09:
 
@@ -240,6 +247,25 @@ equal style (or similar) variables can only be expanded before the box
 is defined if they do not reference anything that cannot be defined
 before the box (e.g. a compute or fix reference or a thermo keyword).
 
+.. _hint13:
+
+Illegal ... command
+^^^^^^^^^^^^^^^^^^^
+
+These are a catchall error messages that used to be used a lot in LAMMPS
+(also programmers are sometimes lazy).  They usually include the name of
+the source file and the line where the error happened.  This can be used
+to track down what caused the error (most often some form of syntax error)
+by looking at the source code.  However, this has two disadvantages: 1. one
+has to check the source file from the exact same LAMMPS version, or else
+the line number would be different or the core may have been rewritten and
+that specific error does not exist anymore.
+
+The LAMMPS developers are committed to replace these too generic error
+messages with more descriptive errors, e.g. listing *which* keyword was
+causing the error, so that it will be much simpler to look up the
+correct syntax in the manual (and without referring to the source code).
+
 ------
 
 .. _err0001:
@@ -982,3 +1008,61 @@ order of preference there are:
 - Send an email to ``developers@lammps.org``
 - Send an email to an :doc:`individual LAMMPS developer <Intro_authors>`
   that you know and trust
+
+.. _err0036:
+
+Neighbor list overflow, boost neigh_modify one
+----------------------------------------------
+
+The neighbor list code in LAMMPS uses a special memory allocation strategy
+to speed up building and accessing neighbor lists.
+
+Instead of making a memory allocation for each list of neighbors of the atoms
+LAMMPS allocates "pages" that have room for several neighbor lists.  This has
+two main advantages:
+
+#. It is not needed to first count how many neighbors there are for an
+   atom to determine the storage required.  Since the pages are much
+   larger than individual lists, LAMMPS just "fills up" the page until
+   there is not enough space left and then allocates a new page.
+
+#. There are fewer calls to the memory allocator functions (which can be
+   time consuming for long-running jobs and fragmented memory space) and
+   the resulting neighbor lists are close to each other physically which
+   improves cache efficiency.
+
+This is controlled by the two parameters "one" and "page", respectively,
+that can be set via the :doc:`neigh_modify command <neigh_modify>`. The
+parameter "one" is the maximum number of entries in a list of neighbors
+for a single atom.  If an atom has more neighbors as the "one" parameter
+allows, the "overflow" error message is triggered.  The parameter "page"
+sets the size of the page.  The neighbor list code checks, if there are
+"one" entries left in the current page.  If not, a new page is allocated.
+
+The default settings are suitable for most systems.  They need to be
+changed, for instance, when simulating a system with a very high density
+or when setting a very long cutoff (e.g. :math:`\gtrapprox 15 \AA` with
+:doc:`units real <units>`).  The value of "page" **must** be at least
+10x the value of "one", but 50x to 100x are recommended to avoid wasting
+memory.  The neighbor list storage is typically the largest amount of
+RAM required by a LAMMPS calculation.
+
+Even though the LAMMPS error message recommends to increase the "one"
+parameter, this may not always be the correct solution.  The neighbor
+list overflow can also be a symptom for some other error that cannot be
+easily detected.  For example, a frequent reason for an (unexpected)
+high density are incorrect box dimensions (since LAMMPS wraps atoms back
+into the principal box with periodic boundaries) or coordinates provided
+as fractional coordinates (LAMMPS does not support this for data files).
+In both cases, LAMMPS cannot easily know whether the input geometry has
+such a high density (and thus requiring more neighbor list storage per
+atom) on purpose or by accident.  Rather than blindly increasing the
+"one" parameter, it is thus worth checking if this is justified by the
+combination of density and cutoff.  This is particularly recommended
+when using some tool(s) to convert input or data files.
+
+When boosting (= increasing) the "one" parameter, it is recommended to
+also increase the value for the "page" parameter to maintain the ratio
+between "one" and "page" to reduce waste of memory.  For some more
+details, please check out the documentation for the :doc:`neigh_modify
+command <neigh_modify>`.

doc/src/Fortran.rst

@@ -69,10 +69,11 @@ statement.  Internally, it will call either
 :cpp:func:`lammps_open_fortran` or :cpp:func:`lammps_open_no_mpi` from
 the C library API to create the class instance.  All arguments are
 optional and :cpp:func:`lammps_mpi_init` will be called automatically
-if it is needed.  Similarly, a possible call to
-:cpp:func:`lammps_mpi_finalize` is integrated into the :f:func:`close`
-function and triggered with the optional logical argument set to
-``.TRUE.``. Here is a simple example:
+if it is needed.  Similarly, optional calls to
+:cpp:func:`lammps_mpi_finalize`, :cpp:func:`lammps_kokkos_finalize`,
+:cpp:func:`lammps_python_finalize`, and :cpp:func:`lammps_plugin_finalize`
+are integrated into the :f:func:`close` function and triggered with the
+optional logical argument set to ``.TRUE.``. Here is a simple example:
 
 .. code-block:: fortran
 
@@ -521,8 +522,8 @@ Procedures Bound to the :f:type:`lammps` Derived Type
    This method will close down the LAMMPS instance through calling
    :cpp:func:`lammps_close`.  If the *finalize* argument is present and
    has a value of ``.TRUE.``, then this subroutine also calls
-   :cpp:func:`lammps_kokkos_finalize` and
-   :cpp:func:`lammps_mpi_finalize`.
+   :cpp:func:`lammps_kokkos_finalize`, :cpp:func:`lammps_mpi_finalize`,
+   :cpp:func:`lammps_python_finalize`, and :cpp:func:`lammps_plugin_finalize`.
 
    :o finalize: shut down the MPI environment of the LAMMPS
     library if ``.TRUE.``.
@@ -530,6 +531,8 @@ Procedures Bound to the :f:type:`lammps` Derived Type
    :to: :cpp:func:`lammps_close`
    :to: :cpp:func:`lammps_mpi_finalize`
    :to: :cpp:func:`lammps_kokkos_finalize`
+   :to: :cpp:func:`lammps_python_finalize`
+   :to: :cpp:func:`lammps_plugin_finalize`
 
 --------
 
@@ -2096,7 +2099,7 @@ Procedures Bound to the :f:type:`lammps` Derived Type
 
 --------
 
-.. f:subroutine:: create_atoms([id,] type, x, [v,] [image,] [bexpand])
+.. f:function:: create_atoms([id,] type, x, [v,] [image,] [bexpand])
 
    This method calls :cpp:func:`lammps_create_atoms` to create additional atoms
    from a given list of coordinates and a list of atom types. Additionally,
@@ -2125,6 +2128,8 @@ Procedures Bound to the :f:type:`lammps` Derived Type
     will be created, not dropped, and the box dimensions will be extended.
     Default is ``.FALSE.``
    :otype bexpand: logical,optional
+   :r atoms: number of created atoms
+   :rtype atoms: integer(c_int)
    :to: :cpp:func:`lammps_create_atoms`
 
    .. note::
@@ -2149,6 +2154,18 @@ Procedures Bound to the :f:type:`lammps` Derived Type
 
 --------
 
+.. f:subroutine:: create_molecule(id, jsonstr)
+
+   Add molecule template from string with JSON data
+
+   .. versionadded:: TBD
+
+   :p character(len=\*) id: desired molecule-ID
+   :p character(len=\*) jsonstr: string with JSON data defining the molecule template
+   :to: :cpp:func:`lammps_create_molecule`
+
+--------
+
 .. f:function:: find_pair_neighlist(style[, exact][, nsub][, reqid])
 
    Find index of a neighbor list requested by a pair style.

doc/src/Howto.rst

@@ -66,6 +66,7 @@ Force fields howto
    :name: force_howto
    :maxdepth: 1
 
+   Howto_FFgeneral
    Howto_bioFF
    Howto_amoeba
    Howto_tip3p
@@ -92,6 +93,7 @@ Packages howto
    Howto_manifold
    Howto_rheo
    Howto_spins
+   Howto_apip
 
 Tutorials howto
 ===============

doc/src/Howto_FFgeneral.rst

@@ -0,0 +1,55 @@
+Some general force field considerations
+=======================================
+
+A compact summary of the concepts, definitions, and properties of force
+fields with explicit bonded interactions (like the ones discussed in
+this HowTo) is given in :ref:`(Gissinger) <Typelabel2>`.
+
+A force field has 2 parts: the formulas that define its potential
+functions and the coefficients used for a particular system.  To assign
+parameters it is first required to assign atom types.  Those are not
+only based on the elements, but also on the chemical environment due to
+the atoms bound to them.  This often follows the chemical concept of
+*functional groups*.  Example: a carbon atom bound with a single bond to
+a single OH-group (alcohol) would be a different atom type than a carbon
+atom bound to a methyl CH3 group (aliphatic carbon).  The atom types
+usually then determine the non-bonded Lennard-Jones parameters and the
+parameters for bonds, angles, dihedrals, and impropers.  On top of that,
+partial charges have to be applied.  Those are usually independent of
+the atom types and are determined either for groups of atoms called
+residues with some fitting procedure based on quantum mechanical
+calculations, or based on some increment system that add or subtract
+increments from the partial charge of an atom based on the types of
+the neighboring atoms.
+
+Force fields differ in the strategies they employ to determine the
+parameters and charge distribution in how generic or specific they are
+which in turn has an impact on the accuracy (compare for example
+CGenFF to CHARMM and GAFF to Amber).  Because of the different
+strategies, it is not a good idea to use a mix of parameters from
+different force field *families* (like CHARMM, Amber, or GROMOS)
+and that extends to the parameters for the solvent, especially
+water.  The publication describing the parameterization of a force
+field will describe which water model to use.  Changing the water
+model usually leads to overall worse results (even if it may improve
+on the water itself).
+
+In addition, one has to consider that *families* of force fields like
+CHARMM, Amber, OPLS, or GROMOS have evolved over time and thus provide
+different *revisions* of the force field parameters.  These often
+corresponds to changes in the functional form or the parameterization
+strategies.  This may also result in changes required for simulation
+settings like the preferred cutoff or how Coulomb interactions are
+computed (cutoff, smoothed/shifted cutoff, or long-range with Ewald
+summation or equivalent).  Unless explicitly stated in the publication
+describing the force field, the Coulomb interaction cannot be chosen at
+will but must match the revision of the force field.  That said,
+liberties may be taken during the initial equilibration of a system to
+speed up the process, but not for production simulations.
+
+----------
+
+.. _Typelabel2:
+
+**(Gissinger)** J. R. Gissinger, I. Nikiforov, Y. Afshar, B. Waters, M. Choi, D. S. Karls, A. Stukowski, W. Im, H. Heinz, A. Kohlmeyer, and E. B. Tadmor, J Phys Chem B, 128, 3282-3297 (2024).
+

doc/src/Howto_apip.rst

@@ -0,0 +1,225 @@
+Adaptive-precision interatomic potentials (APIP)
+================================================
+
+The :ref:`PKG-APIP <PKG-APIP>` enables use of adaptive-precision potentials
+as described in :ref:`(Immel) <Immel2025_1>`.
+In the context of this package, precision refers to the accuracy of an interatomic
+potential.
+
+Modern machine-learning (ML) potentials translate the accuracy of DFT
+simulations into MD simulations, i.e., ML potentials are more accurate
+compared to traditional empirical potentials.
+However, this accuracy comes at a cost: there is a considerable performance
+gap between the evaluation of classical and ML potentials, e.g., the force
+calculation of a classical EAM potential is 100-1000 times faster compared
+to the ML-based ACE method.
+The evaluation time difference results in a conflict between large time and
+length scales on the one hand and accuracy on the other.
+This conflict is resolved by an APIP model for simulations, in which the highest precision
+is required only locally but not globally.
+
+An APIP model uses a precise but
+expensive ML potential only for a subset of atoms, while a fast
+potential is used for the remaining atoms.
+Whether the precise or the fast potential is used is determined
+by a continuous switching parameter :math:`\lambda_i` that can be defined for each
+atom :math:`i`.
+The switching parameter can be adjusted dynamically during a simulation or
+kept constant as explained below.
+
+The potential energy :math:`E_i` of an atom :math:`i` described by an
+adaptive-precision
+interatomic potential is given by :ref:`(Immel) <Immel2025_1>`
+
+.. math::
+
+   E_i = \lambda_i E_i^\text{(fast)} + (1-\lambda_i) E_i^\text{(precise)},
+
+whereas :math:`E_i^\text{(fast)}` is the potential energy of atom :math:`i`
+according to a fast interatomic potential,
+:math:`E_i^\text{(precise)}` is the potential energy according to a precise
+interatomic potential and :math:`\lambda_i\in[0,1]` is the
+switching parameter that decides how the potential energies are weighted.
+
+Adaptive-precision saves computation time when the computation of the
+precise potential is not required for many atoms, i.e., when
+:math:`\lambda_i=1` applies for many atoms.
+
+The currently implemented potentials are:
+
+.. list-table::
+   :header-rows: 1
+
+   * - Fast potential
+     - Precise potential
+   * - :doc:`ACE <pair_pace_apip>`
+     - :doc:`ACE <pair_pace_apip>`
+   * - :doc:`EAM <pair_eam_apip>`
+     -
+
+In theory, any short-range potential can be used for an adaptive-precision
+interatomic potential. How to implement a new (fast or precise)
+adaptive-precision
+potential is explained in :ref:`here <implementing_new_apip_styles>`.
+
+The switching parameter :math:`\lambda_i` that combines the two potentials
+can be dynamically calculated during a
+simulation.
+Alternatively, one can set a constant switching parameter before the start
+of a simulation.
+To run a simulation with an adaptive-precision potential, one needs the
+following components:
+
+.. tabs::
+
+   .. tab:: dynamic switching parameter
+
+        #. :doc:`atom_style apip <atom_style>` so that the switching parameter :math:`\lambda_i` can be stored.
+        #. A fast potential: :doc:`eam/apip <pair_eam_apip>` or :doc:`pace/fast/apip <pair_pace_apip>`.
+        #. A precise potential: :doc:`pace/precise/apip <pair_pace_apip>`.
+        #. :doc:`pair_style lambda/input/apip  <pair_lambda_input_apip>` to calculate :math:`\lambda_i^\text{input}`, from which :math:`\lambda_i` is calculated.
+        #. :doc:`fix lambda/apip <fix_lambda_apip>` to calculate the switching parameter :math:`\lambda_i`.
+        #. :doc:`pair_style lambda/zone/apip <pair_lambda_zone_apip>` to calculate the spatial transition zone of the switching parameter.
+        #. :doc:`pair_style hybrid/overlay <pair_hybrid>` to combine the previously mentioned pair_styles.
+        #. :doc:`fix lambda_thermostat/apip <fix_lambda_thermostat_apip>` to conserve the energy when switching parameters change.
+        #. :doc:`fix atom_weight/apip <fix_atom_weight_apip>` to approximate the load caused by every atom, as the computations of the pair_styles are only required for a subset of atoms.
+        #. :doc:`fix balance <fix_balance>` to perform dynamic load balancing with the calculated load.
+
+   .. tab:: constant switching parameter
+
+        #. :doc:`atom_style apip <atom_style>` so that the switching parameter :math:`\lambda_i` can be stored.
+        #. A fast potential: :doc:`eam/apip <pair_eam_apip>` or :doc:`pace/fast/apip <pair_pace_apip>`.
+        #. A precise potential: :doc:`pace/precise/apip <pair_pace_apip>`.
+        #. :doc:`set <set>` command to set the switching parameter :math:`\lambda_i`.
+        #. :doc:`pair_style hybrid/overlay <pair_hybrid>` to combine the previously mentioned pair_styles.
+        #. :doc:`fix atom_weight/apip <fix_atom_weight_apip>` to approximate the load caused by every atom, as the computations of the pair_styles are only required for a subset of atoms.
+        #. :doc:`fix balance <fix_balance>` to perform dynamic load balancing with the calculated load.
+
+----------
+
+Example
+"""""""
+.. note::
+
+   How to select the values of the parameters of an adaptive-precision
+   interatomic potential is discussed in detail in :ref:`(Immel) <Immel2025_1>`.
+
+
+.. tabs::
+
+   .. tab:: dynamic switching parameter
+
+      Lines like these would appear in the input script:
+
+
+      .. code-block:: LAMMPS
+
+         atom_style apip
+         comm_style tiled
+
+         pair_style hybrid/overlay eam/fs/apip pace/precise/apip lambda/input/csp/apip fcc cutoff 5.0 lambda/zone/apip 12.0
+         pair_coeff * * eam/fs/apip Cu.eam.fs Cu
+         pair_coeff * * pace/precise/apip Cu.yace Cu
+         pair_coeff * * lambda/input/csp/apip
+         pair_coeff * * lambda/zone/apip
+
+         fix 2 all lambda/apip 2.5 3.0 time_averaged_zone 4.0 12.0 110 110 min_delta_lambda 0.01
+         fix 3 all lambda_thermostat/apip N_rescaling 200
+         fix 4 all atom_weight/apip 100 eam ace lambda/input lambda/zone all
+
+         variable myweight atom f_4
+
+         fix 5 all balance 100 1.1 rcb weight var myweight
+
+      First, the :doc:`atom_style apip <atom_style>` and the communication style are set.
+
+      .. note::
+         Note, that :doc:`comm_style <comm_style>` *tiled* is required for the style *rcb* of
+         :doc:`fix balance <fix_balance>`, but not for APIP.
+         However, the flexibility offered by the balancing style *rcb*, compared to the
+         balancing style *shift*, is advantageous for APIP.
+
+      An adaptive-precision EAM-ACE potential, for which the switching parameter
+      :math:`\lambda` is calculated from the CSP, is defined via
+      :doc:`pair_style hybrid/overlay <pair_hybrid>`.
+      The fixes ensure that the switching parameter is calculated, the energy conserved,
+      the weight for the load balancing calculated and the load-balancing itself is done.
+
+   .. tab:: constant switching parameter
+
+      Lines like these would appear in the input script:
+
+      .. code-block:: LAMMPS
+
+         atom_style apip
+         comm_style tiled
+
+         pair_style hybrid/overlay eam/fs/apip pace/precise/apip
+         pair_coeff * * eam/fs/apip Cu.eam.fs Cu
+         pair_coeff * * pace/precise/apip Cu.yace Cu
+
+         # calculate lambda somehow
+         variable lambda atom ...
+         set group all apip/lambda v_lambda
+
+         fix 4 all atom_weight/apip 100 eam ace lambda/input lambda/zone all
+
+         variable myweight atom f_4
+
+         fix 5 all balance 100 1.1 rcb weight var myweight
+
+      First, the :doc:`atom_style apip <atom_style>` and the communication style are set.
+
+      .. note::
+         Note, that :doc:`comm_style <comm_style>` *tiled* is required for the style *rcb* of
+         :doc:`fix balance <fix_balance>`, but not for APIP.
+         However, the flexibility offered by the balancing style *rcb*, compared to the
+         balancing style *shift*, is advantageous for APIP.
+
+      An adaptive-precision EAM-ACE potential is defined via
+      :doc:`pair_style hybrid/overlay <pair_hybrid>`.
+      The switching parameter :math:`\lambda_i` of the adaptive-precision
+      EAM-ACE potential is set via the :doc:`set command <set>`.
+      The parameter is not updated during the simulation.
+      Therefore, the potential is conservative.
+      The fixes ensure that the weight for the load balancing is calculated
+      and the load-balancing itself is done.
+
+----------
+
+.. _implementing_new_apip_styles:
+
+Implementing new APIP pair styles
+"""""""""""""""""""""""""""""""""
+
+One can introduce adaptive-precision to an existing pair style by modifying
+the original pair style.
+One should calculate the force
+:math:`F_i = - \nabla_i \sum_j E_j^\text{original}` for a fast potential or
+:math:`F_i = - (1-\nabla_i) \sum_j E_j^\text{original}` for a precise
+potential from the original potential
+energy :math:`E_j^\text{original}` to see where the switching parameter
+:math:`\lambda_i` needs to be introduced in the force calculation.
+The switching parameter :math:`\lambda_i` is known for all atoms :math:`i`
+in force calculation routine.
+One needs to introduce an abortion criterion based on :math:`\lambda_i` to
+ensure that all not required calculations are skipped and compute time can
+be saved.
+Furthermore, one needs to provide the number of calculations and measure the
+computation time.
+Communication within the force calculation needs to be prevented to allow
+effective load-balancing.
+With communication, the load balancer cannot balance few calculations of the
+precise potential on one processor with many computations of the fast
+potential on another processor.
+
+All changes in the pair_style pace/apip compared to the pair_style pace
+are annotated and commented.
+Thus, the pair_style pace/apip can serve as an example for the implementation
+of new adaptive-precision potentials.
+
+----------
+
+.. _Immel2025_1:
+
+**(Immel)** Immel, Drautz and Sutmann, J Chem Phys, 162, 114119 (2025)

doc/src/Howto_bioFF.rst

@@ -1,22 +1,16 @@
 CHARMM, AMBER, COMPASS, DREIDING, and OPLS force fields
 =======================================================
 
-A compact summary of the concepts, definitions, and properties of
-force fields with explicit bonded interactions (like the ones discussed
-in this HowTo) is given in :ref:`(Gissinger) <Typelabel2>`.
-
-A force field has 2 parts: the formulas that define it and the
-coefficients used for a particular system.  Here we only discuss
-formulas implemented in LAMMPS that correspond to formulas commonly used
-in the CHARMM, AMBER, COMPASS, and DREIDING force fields.  Setting
-coefficients is done either from special sections in an input data file
-via the :doc:`read_data <read_data>` command or in the input script with
-commands like :doc:`pair_coeff <pair_coeff>` or :doc:`bond_coeff
-<bond_coeff>` and so on.  See the :doc:`Tools <Tools>` doc page for
-additional tools that can use CHARMM, AMBER, or Materials Studio
-generated files to assign force field coefficients and convert their
-output into LAMMPS input. LAMMPS input scripts can also be generated by
-`charmm-gui.org <https://charmm-gui.org/>`_.
+Here we only discuss formulas implemented in LAMMPS that correspond to
+formulas commonly used in the CHARMM, AMBER, COMPASS, and DREIDING force
+fields.  Setting coefficients is done either from special sections in an
+input data file via the :doc:`read_data <read_data>` command or in the
+input script with commands like :doc:`pair_coeff <pair_coeff>` or
+:doc:`bond_coeff <bond_coeff>` and so on.  See the :doc:`Tools <Tools>`
+doc page for additional tools that can use CHARMM, AMBER, or Materials
+Studio generated files to assign force field coefficients and convert
+their output into LAMMPS input. LAMMPS input scripts can also be
+generated by `charmm-gui.org <https://charmm-gui.org/>`_.
 
 CHARMM and AMBER
 ----------------
@@ -203,9 +197,11 @@ rather than individual force constants and geometric parameters that
 depend on the particular combinations of atoms involved in the bond,
 angle, or torsion terms.  DREIDING has an :doc:`explicit hydrogen bond
 term <pair_hbond_dreiding>` to describe interactions involving a
-hydrogen atom on very electronegative atoms (N, O, F).  Unlike CHARMM
-or AMBER, the DREIDING force field has not been parameterized for
-considering solvents (like water).
+hydrogen atom on very electronegative atoms (N, O, F).  Unlike CHARMM or
+AMBER, the DREIDING force field has not been parameterized for
+considering solvents (like water) and has no rules for assigning
+(partial) charges.  That will seriously limit its accuracy when used for
+simulating systems where those matter.
 
 See :ref:`(Mayo) <howto-Mayo>` for a description of the DREIDING force field
 
@@ -272,10 +268,6 @@ compatible with a subset of OPLS interactions.
 
 ----------
 
-.. _Typelabel2:
-
-**(Gissinger)** J. R. Gissinger, I. Nikiforov, Y. Afshar, B. Waters, M. Choi, D. S. Karls, A. Stukowski, W. Im, H. Heinz, A. Kohlmeyer, and E. B. Tadmor, J Phys Chem B, 128, 3282-3297 (2024).
-
 .. _howto-MacKerell:
 
 **(MacKerell)** MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field, Fischer, Gao, Guo, Ha, et al (1998).  J Phys Chem, 102, 3586 . https://doi.org/10.1021/jp973084f

doc/src/Howto_cmake.rst

@@ -285,7 +285,7 @@ when used before the CMake directory, there may be a space between the
 can have boolean values (on/off, yes/no, or 1/0 are all valid) or are
 strings representing a choice, or a path, or are free format. If the
 string would contain whitespace, it must be put in quotes, for example
-``-D CMAKE_TUNE_FLAGS="-ftree-vectorize -ffast-math"``.
+``-D CMAKE_CXX_FLAGS="-O3 -Wall -ftree-vectorize -ffast-math"``.
 
 CMake variables fall into two categories: 1) common CMake variables that
 are used by default for any CMake configuration setup and 2) project
@@ -341,8 +341,6 @@ Some common LAMMPS specific variables
      - compile some additional executables from the ``tools`` folder (default: ``off``)
    * - ``BUILD_DOC``
      - include building the HTML format documentation for packaging/installing (default: ``off``)
-   * - ``CMAKE_TUNE_FLAGS``
-     - common compiler flags, for optimization or instrumentation (default:)
    * - ``LAMMPS_MACHINE``
      - when set to ``name`` the LAMMPS executable and library will be called ``lmp_name`` and ``liblammps_name.a``
    * - ``FFT``

doc/src/Howto_github.rst

@@ -498,3 +498,7 @@ systems.  Some unit and regression testing is applied as well.
 A detailed discussion of the LAMMPS developer GitHub workflow can be
 found in the file `doc/github-development-workflow.md
 <https://github.com/lammps/lammps/blob/develop/doc/github-development-workflow.md>`_
+
+.. raw:: latex
+
+   \clearpage

doc/src/Howto_lammps_gui.rst

@@ -1,47 +1,45 @@
 Using LAMMPS-GUI
 ================
 
-This document describes **LAMMPS-GUI version 1.6**.
+.. image:: JPG/lammps-gui-banner.png
+   :align: center
+   :scale: 75%
+
+LAMMPS-GUI is a graphical text editor programmed using the `Qt Framework
+<https://www.qt.io/>`_ and customized for editing and running LAMMPS
+input files.  It is linked to the :ref:`LAMMPS library <lammps_c_api>`
+and thus can run LAMMPS directly using the contents of the editor's text
+buffer as input and without having to launch the LAMMPS executable.
+
+It *differs* from other known interfaces to LAMMPS in that it can
+retrieve and display information from LAMMPS *while it is running*,
+display visualizations created with the :doc:`dump image command
+<dump_image>`, can launch the online LAMMPS documentation for known
+LAMMPS commands and styles, and directly integrates with a collection
+of LAMMPS tutorials (:ref:`Gravelle1 <Gravelle1>`).
+
+This document describes **LAMMPS-GUI version 1.7**.
 
 -----
 
-LAMMPS-GUI is a graphical text editor customized for editing LAMMPS
-input files that is linked to the :ref:`LAMMPS library <lammps_c_api>`
-and thus can run LAMMPS directly using the contents of the editor's text
-buffer as input.  It can retrieve and display information from LAMMPS
-while it is running, display visualizations created with the :doc:`dump
-image command <dump_image>`, and is adapted specifically for editing
-LAMMPS input files through text completion and reformatting, and linking
-to the online LAMMPS documentation for known LAMMPS commands and styles.
+.. contents::
 
-.. note::
+----
 
-   Pre-compiled, ready-to-use LAMMPS-GUI executables for Linux x86\_64
-   (Ubuntu 20.04LTS or later and compatible), macOS (version 11 aka Big
-   Sur or later), and Windows (version 10 or later) :ref:`are available
-   <lammps_gui_install>` for download.  Non-MPI LAMMPS executables (as
-   ``lmp``) for running LAMMPS from the command-line and :doc:`some
-   LAMMPS tools <Tools>` compiled executables are also included.
-   Also, the pre-compiled LAMMPS-GUI packages include the WHAM executables
-   from http://membrane.urmc.rochester.edu/content/wham/ for use with
-   LAMMPS tutorials.
+LAMMPS-GUI aims to provide the traditional experience of running LAMMPS
+using a text editor, a command-line window, and launching the LAMMPS
+text-mode executable printing output to the screen, but just integrated
+into a single application:
 
-   The source code for LAMMPS-GUI is included in the LAMMPS source code
-   distribution and can be found in the ``tools/lammps-gui`` folder.  It
-   can be compiled alongside LAMMPS when :doc:`compiling with CMake
-   <Build_cmake>`.
+- Write and edit LAMMPS input files using the built-in text editor.
+- Run LAMMPS on those input file with command-line flags to enable a
+  specific accelerator package (or none).
+- Extract data from the created files (like trajectory files, log files
+  with thermodynamic data, or images) and visualize it using external
+  software.
 
-LAMMPS-GUI tries to provide an experience similar to what people
-traditionally would have running LAMMPS using a command-line window and
-the console LAMMPS executable but just rolled into a single executable:
-
-- writing & editing LAMMPS input files with a text editor
-- run LAMMPS on those input file with selected command-line flags
-- extract data from the created files and visualize it with and
-  external software
-
-That procedure is quite effective for people proficient in using the
-command-line, as that allows them to use tools for the individual steps
+That traditional procedure is effective for people proficient in using the
+command-line, as it allows them to use the tools for the individual steps
 that they are most comfortable with.  In fact, it is often *required* to
 adopt this workflow when running LAMMPS simulations on high-performance
 computing facilities.
@@ -52,37 +50,69 @@ window or using external programs, let alone writing scripts to extract
 data from the generated output.  It also integrates well with graphical
 desktop environments where the `.lmp` filename extension can be
 registered with LAMMPS-GUI as the executable to launch when double
-clicking on such files.  Also, LAMMPS-GUI has support for drag-n-drop,
-i.e.  an input file can be selected and then moved and dropped on the
-LAMMPS-GUI executable, and LAMMPS-GUI will launch and read the file into
-its buffer.  In many cases LAMMPS-GUI will be integrated into the
-graphical desktop environment and can be launched like other
-applications.
+clicking on such files using a file manager.  LAMMPS-GUI also has
+support for 'drag and drop' for opening inputs: an input file can
+be selected and then moved and dropped on the LAMMPS-GUI executable;
+LAMMPS-GUI will launch and read the file into its buffer.  Input files
+also can be dropped into the editor window of the running LAMMPS-GUI
+application, which will close the current file and open the new file.
+In many cases LAMMPS-GUI will be integrated into the graphical desktop
+environment and can be launched just like any other applications from
+the graphical interface.
 
 LAMMPS-GUI thus makes it easier for beginners to get started running
-simple LAMMPS simulations.  It is very suitable for tutorials on LAMMPS
-since you only need to learn how to use a single program for most tasks
-and thus time can be saved and people can focus on learning LAMMPS.
-The tutorials at https://lammpstutorials.github.io/ are specifically
-updated for use with LAMMPS-GUI and can their tutorial materials can
-be downloaded and loaded directly from the GUI.
+LAMMPS and is well-suited for LAMMPS tutorials, since you only need to
+work with a single, ready-to-use program for most of the tasks.  Plus it
+is available for download as pre-compiled package for popular operating
+systems (Linux, macOS, Windows).  This saves time and allows users to
+focus on learning LAMMPS itself, without the need to learn how to
+compile LAMMPS, learn how to use the command line, or learn how to use a
+separate text editor.
 
-Another design goal is to keep the barrier low when replacing part of
-the functionality of LAMMPS-GUI with external tools.  That said, LAMMPS-GUI
-has some unique functionality that is not found elsewhere:
+The tutorials at https://lammpstutorials.github.io/ are specifically
+updated for use with LAMMPS-GUI and their tutorial materials can be
+downloaded and edited directly from within the GUI while automatically
+loading the matching tutorial instructions into a webbrowser.
+
+Yet the basic control flow remains similar to running LAMMPS from the
+command line, so the barrier for replacing parts of the functionality of
+LAMMPS-GUI with external tools is low.  That said, LAMMPS-GUI offer some
+unique features that are not easily found elsewhere:
 
 - auto-adapting to features available in the integrated LAMMPS library
-- auto-completion for LAMMPS commands and options
-- context-sensitive online help
+- auto-completion for available LAMMPS commands and options only
+- context-sensitive online help for known LAMMPS commands
 - start and stop of simulations via mouse or keyboard
-- monitoring of simulation progress
-- interactive visualization using the :doc:`dump image <dump_image>`
+- monitoring of simulation progress and CPU use
+- interactive visualization using the LAMMPS :doc:`dump image feature <dump_image>`
   command with the option to copy-paste the resulting settings
-- automatic slide show generation from dump image out at runtime
-- automatic plotting of thermodynamics data at runtime
+- automatic slide show generation from dump image output at runtime
+- automatic plotting of thermodynamic data at runtime
 - inspection of binary restart files
+- integration will a set of LAMMPS tutorials
 
-The following text provides a detailed tour of the features and
+.. admonition:: Download LAMMPS-GUI for your platform
+   :class: Hint
+
+   Pre-compiled, ready-to-use LAMMPS-GUI executables for Linux x86\_64
+   (Ubuntu 20.04LTS or later and compatible), macOS (version 11 aka Big
+   Sur or later), and Windows (version 10 or later) :ref:`are available
+   <lammps_gui_install>` for download.  Non-MPI LAMMPS executables (as
+   ``lmp``) for running LAMMPS from the command-line and :doc:`some
+   LAMMPS tools <Tools>` compiled executables are also included.  Also,
+   the pre-compiled LAMMPS-GUI packages include the WHAM executables
+   from http://membrane.urmc.rochester.edu/content/wham/ for use with
+   LAMMPS tutorials documented in this paper (:ref:`Gravelle1
+   <Gravelle1>`).
+
+   The source code for LAMMPS-GUI is included in the LAMMPS source code
+   distribution and can be found in the ``tools/lammps-gui`` folder.  It
+   can be compiled alongside LAMMPS when :doc:`compiling with CMake
+   <Build_cmake>`.
+
+-----
+
+The following text provides a documentation of the features and
 functionality of LAMMPS-GUI.  Suggestions for new features and
 reports of bugs are always welcome.  You can use the :doc:`the same
 channels as for LAMMPS itself <Errors_bugs>` for that purpose.
@@ -92,9 +122,12 @@ channels as for LAMMPS itself <Errors_bugs>` for that purpose.
 Installing Pre-compiled LAMMPS-GUI Packages
 -------------------------------------------
 
-LAMMPS-GUI is available as pre-compiled binary packages for Linux
-x86\_64, macOS 11 and later, and Windows 10 and later.  Alternately, it
-can be compiled from source.
+LAMMPS-GUI is available for download as pre-compiled binary packages for
+Linux x86\_64 (Ubuntu 20.04LTS or later and compatible), macOS (version
+11 aka Big Sur or later), and Windows (version 10 or later) from the
+`LAMMPS release pages on GitHub <https://github.com/lammps/lammps/releases/>`_.
+A backup download location is at https://download.lammps.org/static/
+Alternately, LAMMPS-GUI can be compiled from source when building LAMMPS.
 
 Windows 10 and later
 ^^^^^^^^^^^^^^^^^^^^
@@ -216,8 +249,8 @@ editor buffer, which may contain multiple :doc:`run <run>` or
 
 LAMMPS runs in a separate thread, so the GUI stays responsive and is
 able to interact with the running calculation and access data it
-produces.  It is important to note that running LAMMPS this way is
-using the contents of the input buffer for the run (via the
+produces.  It is important to note that running LAMMPS this way is using
+the contents of the input buffer for the run (via the
 :cpp:func:`lammps_commands_string()` function of the LAMMPS C-library
 interface), and **not** the original file it was read from.  Thus, if
 there are unsaved changes in the buffer, they *will* be used.  As an
@@ -226,28 +259,55 @@ of a file from the *Run LAMMPS from File* menu entry or with
 `Ctrl-Shift-Enter`.  This option may be required in some rare cases
 where the input uses some functionality that is not compatible with
 running LAMMPS from a string buffer.  For consistency, any unsaved
-changes in the buffer must be either saved to the file or undone
-before LAMMPS can be run from a file.
+changes in the buffer must be either saved to the file or undone before
+LAMMPS can be run from a file.
+
+The line number of the currently executed command is highlighted in
+green in the line number display for the *Editor* Window.
 
 .. image:: JPG/lammps-gui-running.png
    :align: center
    :scale: 75%
 
-While LAMMPS is running, the contents of the status bar change.  On
-the left side there is a text indicating that LAMMPS is running, which
-also indicates the number of active threads, when thread-parallel
-acceleration was selected in the *Preferences* dialog.  On the right
+While LAMMPS is running, the contents of the status bar change.  The
+text fields that normally show "Ready." and the current working
+directory, change into an area showing the CPU utilization in percent.
+Nest to it is a text indicating that LAMMPS is running, which also
+indicates the number of active threads (in case thread-parallel
+acceleration was selected in the *Preferences* dialog).  On the right
 side, a progress bar is shown that displays the estimated progress for
 the current :doc:`run <run>` or :doc:`minimize <minimize>` command.
 
-Also, the line number of the currently executed command is highlighted
-in green.
+.. admonition:: CPU Utilization
+   :class: note
+
+   The CPU Utilization should ideally be close to 100% times the number
+   of threads like in the screenshot image above.  Since the GUI is
+   running as a separate thread, the CPU utilization can be higher, for
+   example when the GUI needs to work hard to keep up with the
+   simulation.  This can be caused by having frequent thermo output or
+   running a simulation of a small system.  In the *Preferences* dialog,
+   the polling interval for updating the the *Output* and *Charts*
+   windows can be set. The intervals may need to be lowered to not miss
+   data between *Charts* data updates or to avoid stalling when the
+   thermo output is not transferred to the *Output* window fast enough.
+   It is also possible to reduce the amount of data by increasing the
+   :doc:`thermo interval <thermo>`.  LAMMPS-GUI detects, if the
+   associated I/O buffer is by a significant percentage and will print a
+   warning after the run with suggested adjustments.  The utilization
+   can also be lower, e.g.  when the simulation is slowed down by the
+   GUI or other processes also running on the host computer and
+   competing with LAMMPS-GUI for GPU resources.
+
+   .. image:: JPG/lammps-gui-buffer-warn.png
+      :align: center
+      :scale: 75%
 
 If an error occurs (in the example below the command :doc:`label
 <label>` was incorrectly capitalized as "Label"), an error message
 dialog is shown and the line of the input which triggered the error is
-highlighted.  The state of LAMMPS in the status bar is set to "Failed."
-instead of "Ready."
+highlighted in red.  The state of LAMMPS in the status bar is set to
+"Failed."  instead of "Ready."
 
 .. image:: JPG/lammps-gui-run-error.png
    :align: center
@@ -294,7 +354,10 @@ of the *Output* window showing how many warnings and errors were
 detected and how many lines the entire output has.  By clicking on the
 button on the right with the warning symbol or by using the keyboard
 shortcut `Ctrl-N` (`Command-N` on macOS), you can jump to the next
-line with a warning or error.
+line with a warning or error.  If there is a URL pointing to additional
+explanations in the online manual, that URL will be highlighted and
+double-clicking on it shall open the corresponding manual page in
+the web browser.  The option is also available from the context menu.
 
 By default, the *Output* window is replaced each time a run is started.
 The runs are counted and the run number for the current run is displayed
@@ -334,27 +397,28 @@ plot of thermodynamic output of the LAMMPS calculation as shown below.
    :align: center
    :scale: 33%
 
-The drop down menu on the top right allows selection of different
-properties that are computed and written to thermo output.  Only one
-property can be shown at a time.  The plots are updated regularly with
-new data as the run progresses, so they can be used to visually monitor
-the evolution of available properties.  The update interval can be set
-in the *Preferences* dialog.  By default, the raw data for the selected
-property is plotted as a blue graph. As soon as there are a sufficient
-number of data points, there will be a second graph shown in red with a
-smoothed version of the data.  From the drop down menu on the top left,
-you can select whether to plot only the raw data, only the smoothed
-data or both.  The smoothing uses a `Savitzky-Golay convolution filter
-<https://en.wikipedia.org/wiki/Savitzky%E2%80%93Golay_filter>`_ The
-window width (left) and order (right) parameters can be set in the boxes
-next to the drop down menu.  Default settings are 10 and 4 which means
-that the smoothing window includes 10 points each to the left and the
-right of the current data point and a fourth order polynomial is fit to
-the data in the window.
+The "Data:" drop down menu on the top right allows selection of
+different properties that are computed and written as thermodynamic
+output to the output window.  Only one property can be shown at a time.
+The plots are updated regularly with new data as the run progresses, so
+they can be used to visually monitor the evolution of available
+properties.  The update interval can be set in the *Preferences* dialog.
+By default, the raw data for the selected property is plotted as a blue
+graph.  From the "Plot:" drop menu on the second row and on the left,
+you can select whether to plot only raw data graph, only a smoothed data
+graph, or both graphs on top of each other.  The smoothing process uses
+a `Savitzky-Golay convolution filter
+<https://en.wikipedia.org/wiki/Savitzky%E2%80%93Golay_filter>`_.  The
+convolution window width (left) and order (right) parameters can be set
+in the boxes next to the drop down menu.  Default settings are 10 and 4
+which means that the smoothing window includes 10 points each to the
+left and the right of the current data point for a total of 21 points
+and a fourth order polynomial is fitted to the data in the window.
 
-You can use the mouse to zoom into the graph (hold the left button and
-drag to mark an area) or zoom out (right click) and you can reset the
-view with a click to the "lens" button next to the data drop down menu.
+The "Title:" and "Y:" input boxes allow to edit the text shown as the
+plot title and the y-axis label, respectively.  The text entered in the
+"Title:" box is applied to *all* charts, while the "Y:" text changes
+only the y-axis label of the currently *selected* plot.
 
 The window title shows the current run number that this chart window
 corresponds to.  Same as for the *Output* window, the chart window is
@@ -382,6 +446,40 @@ here you get the compounded data set starting with the last change of
 output fields or timestep setting, while the export from the log will
 contain *all* YAML output but *segmented* into individual runs.
 
+The *Preferences* dialog has a *Charts* tab, where you can configure
+multiple chart-related settings, like the default title, colors for the
+graphs, default choice of the raw / smooth graph selection, and the
+default chart graph size.
+
+
+
+.. admonition:: Slowdown of Simulations from Charts Data Processing
+   :class: warning
+
+   Using frequent thermo output during long simulations can result in a
+   significant slowdown of that simulation since it is accumulating many
+   data points for each of the thermo properties in the chart window to
+   be redrawn with every update.  The updates are consuming additional
+   CPU time when smoothing enabled.  This slowdown can be confirmed when
+   an increasing percentage of the total run time is spent in the
+   "Output" or "Other" sections of the :doc:`MPI task timing breakdown
+   <Run_output>`.  It is thus recommended to use a large enough value as
+   argument `N` for the :doc:`thermo command <thermo>` and to select
+   plotting only the "Raw" data in the *Charts Window* during such
+   simulations.  It is always possible to switch between the different
+   display styles for charts during the simulation and after it has
+   finished.
+
+   .. versionchanged:: 1.7
+
+      As of LAMMPS-GUI version 1.7 the chart data processing is
+      significantly optimized compared to older versions of LAMMPS-GUI.
+      The general problem of accumulating excessive amounts of data
+      and the overhead of too frequently polling LAMMPS for new data
+      cannot be optimized away, though.  If necessary, the command
+      line LAMMPS executable needs to be used and the output accumulated
+      of a very fast disk (e.g. a high-performance SSD).
+
 Image Slide Show
 ----------------
 
@@ -461,11 +559,11 @@ correspond to (via their mass) and then colorize them in the image and
 set their atom diameters accordingly.  If this is not possible, for
 instance when using reduced (= 'lj') :doc:`units <units>`, then
 LAMMPS-GUI will check the current pair style and if it is a
-Lennard-Jones type potential, it will extract the *sigma* parameter
-for each atom type and assign atom diameters from those numbers.
-For cases where atom diameters are not auto-detected, the *Atom size* field
-can be edited and a suitable value set manually. The default value
-is inferred from the x-direction lattice spacing.
+Lennard-Jones type potential, it will extract the *sigma* parameter for
+each atom type and assign atom diameters from those numbers.  For cases
+where atom diameters are not auto-detected, the *Atom size* field can be
+edited and a suitable value set manually. The default value is inferred
+from the x-direction lattice spacing.
 
 If elements cannot be detected the default sequence of colors of the
 :doc:`dump image <dump_image>` command is assigned to the different atom
@@ -480,22 +578,31 @@ types.
 |gui-image1|  |gui-image2|
 
 The default image size, some default image quality settings, the view
-style and some colors can be changed in the *Preferences* dialog
-window.  From the image viewer window further adjustments can be made:
-actual image size, high-quality (SSAO) rendering, anti-aliasing, view
-style, display of box or axes, zoom factor.  The view of the system can
-be rotated horizontally and vertically.  It is also possible to only
-display the atoms within a group defined in the input script (default is
-"all").  The image can also be re-centered on the center of mass of the
-selected group.  After each change, the image is rendered again and the
-display updated.  The small palette icon on the top left is colored
-while LAMMPS is running to render the new image; it is grayed out when
-LAMMPS is finished.  When there are many atoms to render and high
-quality images with anti-aliasing are requested, re-rendering may take
-several seconds.  From the *File* menu of the image window, the
-current image can be saved to a file (keyboard shortcut `Ctrl-S`) or
-copied to the clipboard (keyboard shortcut `Ctrl-C`) for pasting the
-image into another application.
+style and some colors can be changed in the *Preferences* dialog window.
+From the image viewer window further adjustments can be made: actual
+image size, high-quality (SSAO) rendering, anti-aliasing, view style,
+display of box or axes, zoom factor.  The view of the system can be
+rotated horizontally and vertically.
+
+It is also possible to display only the atoms within a :doc:`group
+defined in the input script <group>` (default is "all").  The available
+groups can be selected from the drop down list next to the "Group:"
+label.  Similarly, if there are :doc:`molecules defined in the input
+<molecule>`, it is possible to select one of them (default is "none")
+and visualize it (it will be shown at the center of the simulation box).
+While a molecule is selected, the group selection is disabled.  It can
+be restored by selecting the molecule "none".
+
+The image can also be re-centered on the center of mass of the selected
+group.  After each change, the image is rendered again and the display
+updated.  The small palette icon on the top left is colored while LAMMPS
+is running to render the new image; it is grayed out when LAMMPS is
+finished.  When there are many atoms to render and high quality images
+with anti-aliasing are requested, re-rendering may take several seconds.
+From the *File* menu of the image window, the current image can be saved
+to a file (keyboard shortcut `Ctrl-S`) or copied to the clipboard
+(keyboard shortcut `Ctrl-C`) for pasting the image into another
+application.
 
 From the *File* menu it is also possible to copy the current
 :doc:`dump image <dump_image>` and :doc:`dump_modify <dump_image>`
@@ -604,13 +711,27 @@ generated with a :doc:`write_data command <write_data>`.  The third
 window is a :ref:`Snapshot Image Viewer <snapshot_viewer>` containing a
 visualization of the system in the restart.
 
-If the restart file is larger than 250 MBytes, a dialog will ask
-for confirmation before continuing, since large restart files
-may require large amounts of RAM since the entire system must
-be read into RAM.  Thus restart file for large simulations that
-have been run on an HPC cluster may overload a laptop or local
-workstation. The *Show Details...* button will display a rough
-estimate of the additional memory required.
+.. |inspect1| image:: JPG/lammps-gui-inspect-data.png
+   :width: 32%
+
+.. |inspect2| image:: JPG/lammps-gui-inspect-info.png
+   :width: 32%
+
+.. |inspect3| image:: JPG/lammps-gui-inspect-image.png
+   :width: 32%
+
+|inspect1|  |inspect2|  |inspect3|
+
+.. admonition:: Large Restart Files
+   :class: warning
+
+   If the restart file is larger than 250 MBytes, a dialog will ask for
+   confirmation before continuing, since large restart files may require
+   large amounts of RAM since the entire system must be read into RAM.
+   Thus restart file for large simulations that have been run on an HPC
+   cluster may overload a laptop or local workstation. The *Show
+   Details...* button will display a rough estimate of the additional
+   memory required.
 
 Menu
 ----
@@ -682,6 +803,12 @@ timestep.  The *Stop LAMMPS* entry will do this by calling the
 :cpp:func:`lammps_force_timeout` library function, which is equivalent
 to a :doc:`timer timeout 0 <timer>` command.
 
+The *Relaunch LAMMPS Instance* will destroy the current LAMMPS thread
+and free its data and then create a new thread with a new LAMMPS
+instance.  This is usually not needed, since LAMMPS-GUI tries to detect
+when this is needed and does it automatically.  This is available
+in case it missed something and LAMMPS behaves in unexpected ways.
+
 The *Set Variables...* entry opens a dialog box where
 :doc:`index style variables <variable>` can be set. Those variables
 are passed to the LAMMPS instance when it is created and are thus
@@ -720,6 +847,26 @@ output, charts, slide show, variables, or snapshot images.  The
 default settings for their visibility can be changed in the
 *Preferences* dialog.
 
+Tutorials
+^^^^^^^^^
+
+The *Tutorials* menu is to support the set of LAMMPS tutorials for
+beginners and intermediate LAMMPS users documented in (:ref:`Gravelle1
+<Gravelle1>`).  From the drop down menu you can select which of the
+eight currently available tutorial sessions you want to begin.  This
+opens a 'wizard' dialog where you can choose in which folder you want to
+work, whether you want that folder to be wiped from *any* files, whether
+you want to download the solutions files (which can be large) to a
+``solution`` sub-folder, and whether you want the corresponding
+tutorial's online version opened in your web browser.  The dialog will
+then start downloading the files requested (download progress is
+reported in the status line) and load the first input file for the
+selected session into LAMMPS-GUI.
+
+.. image:: JPG/lammps-gui-tutorials.png
+   :align: center
+   :scale: 50%
+
 About
 ^^^^^
 
@@ -783,18 +930,21 @@ look of LAMMPS-GUI.  The settings are grouped and each group is
 displayed within a tab.
 
 .. |guiprefs1| image:: JPG/lammps-gui-prefs-general.png
-   :width: 24%
+   :width: 19%
 
 .. |guiprefs2| image:: JPG/lammps-gui-prefs-accel.png
-   :width: 24%
+   :width: 19%
 
 .. |guiprefs3| image:: JPG/lammps-gui-prefs-image.png
-   :width: 24%
+   :width: 19%
 
 .. |guiprefs4| image:: JPG/lammps-gui-prefs-editor.png
-   :width: 24%
+   :width: 19%
 
-|guiprefs1|  |guiprefs2|  |guiprefs3|  |guiprefs4|
+.. |guiprefs5| image:: JPG/lammps-gui-prefs-charts.png
+   :width: 19%
+
+|guiprefs1|  |guiprefs2|  |guiprefs3|  |guiprefs4|  |guiprefs5|
 
 General Settings:
 ^^^^^^^^^^^^^^^^^
@@ -823,13 +973,12 @@ General Settings:
 - *Replace image window on new render:* when checked, an existing
   chart window will be replaced when a new snapshot image is requested,
   otherwise each command will create a new image window.
-- *Path to LAMMPS Shared Library File:* this option is only visible
-  when LAMMPS-GUI was compiled to load the LAMMPS library at run time
-  instead of being linked to it directly.  With the *Browse..* button
-  or by changing the text, a different shared library file with a
-  different compilation of LAMMPS with different settings or from a
-  different version can be loaded.  After this setting was changed,
-  LAMMPS-GUI needs to be re-launched.
+- *Download tutorial solutions enabled* this controls whether the
+  "Download solutions" option is enabled by default when setting up
+  a tutorial.
+- *Open tutorial webpage enabled* this controls whether the "Open
+  tutorial webpage in web browser" option is enabled by default when
+  setting up a tutorial.
 - *Select Default Font:* Opens a font selection dialog where the type
   and size for the default font (used for everything but the editor and
   log) of the application can be set.
@@ -848,16 +997,36 @@ General Settings:
   the plots in the *Charts* window in milliseconds.  The default is to
   redraw the plots every 500 milliseconds.  This is just for the drawing,
   data collection is managed with the previous setting.
+- *HTTPS proxy setting:* Allows to enter a URL for an HTTPS proxy.  This
+  may be needed when the LAMMPS input contains :doc:`geturl commands <geturl>`
+  or for downloading tutorial files from the *Tutorials* menu.  If the
+  ``https_proxy`` environment variable was set externally, its value is
+  displayed but cannot be changed.
+- *Path to LAMMPS Shared Library File:* this option is only visible
+  when LAMMPS-GUI was compiled to load the LAMMPS library at run time
+  instead of being linked to it directly.  With the *Browse..* button
+  or by changing the text, a different shared library file with a
+  different compilation of LAMMPS with different settings or from a
+  different version can be loaded.  After this setting was changed,
+  LAMMPS-GUI needs to be re-launched.
 
 Accelerators:
 ^^^^^^^^^^^^^
 
-This tab enables selection of an accelerator package for LAMMPS to use
-and is equivalent to using the `-suffix` and `-package` flags on the
-command-line.  Only settings supported by the LAMMPS library and local
-hardware are available.  The `Number of threads` field allows setting
-the maximum number of threads for the accelerator packages that use
-threads.
+This tab enables selection of an accelerator package and modify some of
+its settings to use for running LAMMPS and is equivalent to using the
+:doc:`-sf <suffix>` and :doc:`-pk <package>` flags :doc:`on the
+command-line <Run_options>`.  Only settings supported by the LAMMPS
+library and local hardware are available.  The `Number of threads` field
+allows setting the number of threads for the accelerator packages that
+support using threads (OPENMP, INTEL, KOKKOS, and GPU).  Furthermore,
+the choice of precision mode (double, mixed, or single) for the INTEL
+package can be selected and for the GPU package, whether the neighbor
+lists are built on the GPU or the host (required for :doc:`pair style
+hybrid <pair_hybrid>`) and whether only pair styles should be
+accelerated (i.e. run PPPM entirely on the CPU, which sometimes leads
+to better overall performance).  Whether settings can be changed depends
+on which accelerator package is chosen (or "None").
 
 Snapshot Image:
 ^^^^^^^^^^^^^^^
@@ -884,7 +1053,7 @@ lists to select the background and box colors.
 Editor Settings:
 ^^^^^^^^^^^^^^^^
 
-This tab allows tweaking settings of the editor window.  Specifically
+This tab allows tweaking settings of the editor window.  Specifically,
 the amount of padding to be added to LAMMPS commands, types or type
 ranges, IDs (e.g. for fixes), and names (e.g. for groups).  The value
 set is the minimum width for the text element and it can be chosen in
@@ -896,6 +1065,16 @@ the completion pop-up window, and whether auto-save mode is enabled.
 In auto-save mode the editor buffer is saved before a run or before
 exiting LAMMPS-GUI.
 
+Charts Settings:
+----------------
+
+This tab allows tweaking settings of the *Charts* window.  Specifically,
+one can set the default chart title (if the title contains '%f' it will
+be replaced with the name of the current input file), one can select
+whether by default the raw data, the smoothed data or both will be
+plotted, one can set the colors for the two lines, the default smoothing
+parameters, and the default size of the chart graph in pixels.
+
 -----------
 
 Keyboard Shortcuts
@@ -976,10 +1155,25 @@ available (On macOS use the Command key instead of Ctrl/Control).
      - Ctrl+Shift+T
      - LAMMPS Tutorial
 
-Further editing keybindings `are documented with the Qt documentation
+Further keybindings of the editor window `are documented with the Qt
+documentation
 <https://doc.qt.io/qt-5/qplaintextedit.html#editing-key-bindings>`_.  In
 case of conflicts the list above takes precedence.
 
 All other windows only support a subset of keyboard shortcuts listed
 above.  Typically, the shortcuts `Ctrl-/` (Stop Run), `Ctrl-W` (Close
 Window), and `Ctrl-Q` (Quit Application) are supported.
+
+-------------
+
+.. _Gravelle1:
+
+**(Gravelle1)** Gravelle, Gissinger, Kohlmeyer, `arXiv:2503.14020 \[physics.comp-ph\] <https://doi.org/10.48550/arXiv.2503.14020>`_ (2025)
+
+.. _Gravelle2:
+
+**(Gravelle2)** Gravelle https://lammpstutorials.github.io/
+
+.. raw:: latex
+
+   \clearpage

doc/src/Howto_spc.rst

@@ -1,5 +1,5 @@
-SPC water model
-===============
+SPC and SPC/E water model
+=========================
 
 The SPC water model specifies a 3-site rigid water molecule with
 charges and Lennard-Jones parameters assigned to each of the three atoms.
@@ -8,6 +8,18 @@ the two O-H bonds and the H-O-H angle rigid.  A bond style of
 *harmonic* and an angle style of *harmonic* or *charmm* should also be
 used.
 
+One suitable pair style with cutoff Coulomb would for instance be:
+
+* :doc:`pair_style lj/cut/coul/cut <pair_lj_cut_coul>`
+
+These commands are examples for a long-range Coulomb model:
+
+* :doc:`pair_style lj/cut/coul/long <pair_lj_cut_coul>`
+* :doc:`pair_style lj/cut/coul/long/soft <pair_fep_soft>`
+* :doc:`kspace_style pppm <kspace_style>`
+* :doc:`pair_style lj/long/coul/long <pair_lj_long>`
+* :doc:`kspace_style pppm/disp <kspace_style>`
+
 These are the additional parameters (in real units) to set for O and H
 atoms and the water molecule to run a rigid SPC model.
 
@@ -39,7 +51,9 @@ the SPC and SPC/E models.
 Below is the code for a LAMMPS input file and a molecule file
 (``spce.mol``) of SPC/E water for use with the :doc:`molecule command
 <molecule>` demonstrating how to set up a small bulk water system for
-SPC/E with rigid bonds.
+SPC/E with rigid bonds.  For simplicity and speed the example uses a
+cutoff Coulomb.  Most production simulations require long-range Coulomb
+instead.
 
 .. code-block:: LAMMPS
 

doc/src/Howto_thermostat.rst

@@ -21,9 +21,14 @@ can be invoked via the *dpd/tstat* pair style:
 * :doc:`fix nvt/sllod <fix_nvt_sllod>`
 * :doc:`fix temp/berendsen <fix_temp_berendsen>`
 * :doc:`fix temp/csvr <fix_temp_csvr>`
+* :doc:`fix ffl <fix_ffl>`
+* :doc:`fix gjf <fix_gjf>`
+* :doc:`fix gld <fix_gld>`
+* :doc:`fix gle <fix_gle>`
 * :doc:`fix langevin <fix_langevin>`
 * :doc:`fix temp/rescale <fix_temp_rescale>`
 * :doc:`pair_style dpd/tstat <pair_dpd>`
+* :doc:`pair_style dpd/ext/tstat <pair_dpd_ext>`
 
 :doc:`Fix nvt <fix_nh>` only thermostats the translational velocity of
 particles.  :doc:`Fix nvt/sllod <fix_nvt_sllod>` also does this,
@@ -82,10 +87,10 @@ that:
 
 .. note::
 
-   Only the nvt fixes perform time integration, meaning they update
+   Not all thermostat fixes perform time integration, meaning they update
    the velocities and positions of particles due to forces and velocities
    respectively.  The other thermostat fixes only adjust velocities; they
-   do NOT perform time integration updates.  Thus they should be used in
+   do NOT perform time integration updates.  Thus, they should be used in
    conjunction with a constant NVE integration fix such as these:
 
 * :doc:`fix nve <fix_nve>`

doc/src/Howto_tip3p.rst

@@ -5,17 +5,24 @@ The TIP3P water model as implemented in CHARMM :ref:`(MacKerell)
 <howto-tip3p>` specifies a 3-site rigid water molecule with charges and
 Lennard-Jones parameters assigned to each of the three atoms.
 
-A suitable pair style with cutoff Coulomb would be:
+One suitable pair style with cutoff Coulomb would for instance be:
 
 * :doc:`pair_style lj/cut/coul/cut <pair_lj_cut_coul>`
 
-or these commands for a long-range Coulomb model:
+These commands are examples for a long-range Coulomb model:
 
 * :doc:`pair_style lj/cut/coul/long <pair_lj_cut_coul>`
 * :doc:`pair_style lj/cut/coul/long/soft <pair_fep_soft>`
 * :doc:`kspace_style pppm <kspace_style>`
+* :doc:`pair_style lj/long/coul/long <pair_lj_long>`
 * :doc:`kspace_style pppm/disp <kspace_style>`
 
+And these pair styles are compatible with the CHARMM force field:
+
+* :doc:`pair_style lj/charmm/coul/charmm <pair_charmm>`
+* :doc:`pair_style lj/charmm/coul/long <pair_charmm>`
+* :doc:`pair_style lj/charmmfsw/coul/long <pair_charmm>`
+
 In LAMMPS the :doc:`fix shake or fix rattle <fix_shake>` command can be
 used to hold the two O-H bonds and the H-O-H angle rigid.  A bond style
 of :doc:`harmonic <bond_harmonic>` and an angle style of :doc:`harmonic
@@ -100,7 +107,9 @@ ignored.
 Below is the code for a LAMMPS input file and a molecule file
 (``tip3p.mol``) of TIP3P water for use with the :doc:`molecule command
 <molecule>` demonstrating how to set up a small bulk water system for
-TIP3P with rigid bonds.
+TIP3P with rigid bonds.  For simplicity and speed the example uses a
+cutoff Coulomb.  Most production simulations require long-range Coulomb
+instead.
 
 .. code-block:: LAMMPS
 

doc/src/Howto_tip4p.rst

@@ -1,5 +1,5 @@
-TIP4P water model
-=================
+TIP4P and OPC water models
+==========================
 
 The four-point TIP4P rigid water model extends the traditional
 :doc:`three-point TIP3P <Howto_tip3p>` model by adding an additional
@@ -9,9 +9,11 @@ the oxygen along the bisector of the HOH bond angle.  A bond style of
 :doc:`harmonic <bond_harmonic>` and an angle style of :doc:`harmonic
 <angle_harmonic>` or :doc:`charmm <angle_charmm>` should also be used.
 In case of rigid bonds also bond style :doc:`zero <bond_zero>` and angle
-style :doc:`zero <angle_zero>` can be used.
+style :doc:`zero <angle_zero>` can be used.  Very similar to the TIP4P
+model is the OPC water model.  It can be realized the same way as TIP4P
+but has different geometry and force field parameters.
 
-There are two ways to implement TIP4P water in LAMMPS:
+There are two ways to implement TIP4P-like water in LAMMPS:
 
 #. Use a specially written pair style that uses the :ref:`TIP3P geometry
    <tip3p_molecule>` without the point M. The point M location is then
@@ -21,7 +23,10 @@ There are two ways to implement TIP4P water in LAMMPS:
    computationally very efficient, but the charge distribution in space
    is only correct within the tip4p labeled styles.  So all other
    computations using charges will "see" the negative charge incorrectly
-   on the oxygen atom.
+   located on the oxygen atom unless they are specially written for using
+   the TIP4P geometry internally as well, e.g. :doc:`compute dipole/tip4p
+   <compute_dipole>`, :doc:`fix efield/tip4p <fix_efield>`, or
+   :doc:`kspace_style pppm/tip4p <kspace_style>`.
 
    This can be done with the following pair styles for Coulomb with a cutoff:
 
@@ -68,77 +73,90 @@ TIP4P/2005 model :ref:`(Abascal2) <Abascal2>` and a version of TIP4P
 parameters adjusted for use with a long-range Coulombic solver
 (e.g. Ewald or PPPM in LAMMPS).  Note that for implicit TIP4P models the
 OM distance is specified in the :doc:`pair_style <pair_style>` command,
-not as part of the pair coefficients.
+not as part of the pair coefficients. Also parameters for the OPC
+model (:ref:`Izadi <Izadi>`) are provided.
 
 .. list-table::
       :header-rows: 1
-      :widths: 36 19 13 15 17
+      :widths: 40 12 12 14 11 11
 
       * - Parameter
         - TIP4P (original)
         - TIP4P/Ice
         - TIP4P/2005
         - TIP4P (Ewald)
+        - OPC
       * - O mass (amu)
         - 15.9994
         - 15.9994
         - 15.9994
         - 15.9994
+        - 15.9994
       * - H mass (amu)
         - 1.008
         - 1.008
         - 1.008
         - 1.008
+        - 1.008
       * - O or M charge (:math:`e`)
         - -1.040
         - -1.1794
         - -1.1128
         - -1.04844
+        - -1.3582
       * - H charge (:math:`e`)
         - 0.520
         - 0.5897
         - 0.5564
         - 0.52422
+        - 0.6791
       * - LJ :math:`\epsilon` of OO (kcal/mole)
         - 0.1550
         - 0.21084
         - 0.1852
         - 0.16275
+        - 0.21280
       * - LJ :math:`\sigma` of OO (:math:`\AA`)
         - 3.1536
         - 3.1668
         - 3.1589
         - 3.16435
+        - 3.1660
       * - LJ :math:`\epsilon` of HH, MM, OH, OM, HM (kcal/mole)
         - 0.0
         - 0.0
         - 0.0
         - 0.0
+        - 0.0
       * - LJ :math:`\sigma` of HH, MM, OH, OM, HM (:math:`\AA`)
         - 1.0
         - 1.0
         - 1.0
         - 1.0
+        - 1.0
       * - :math:`r_0` of OH bond (:math:`\AA`)
         - 0.9572
         - 0.9572
         - 0.9572
         - 0.9572
+        - 0.8724
       * - :math:`\theta_0` of HOH angle
         - 104.52\ :math:`^{\circ}`
         - 104.52\ :math:`^{\circ}`
         - 104.52\ :math:`^{\circ}`
         - 104.52\ :math:`^{\circ}`
+        - 103.60\ :math:`^{\circ}`
       * - OM distance (:math:`\AA`)
         - 0.15
         - 0.1577
         - 0.1546
         - 0.1250
+        - 0.1594
 
-Note that the when using the TIP4P pair style, the neighbor list cutoff
+Note that the when using a TIP4P pair style, the neighbor list cutoff
 for Coulomb interactions is effectively extended by a distance 2 \* (OM
 distance), to account for the offset distance of the fictitious charges
-on O atoms in water molecules.  Thus it is typically best in an
+on O atoms in water molecules.  Thus, it is typically best in an
 efficiency sense to use a LJ cutoff >= Coulomb cutoff + 2\*(OM
 distance), to shrink the size of the neighbor list.  This leads to
 slightly larger cost for the long-range calculation, so you can test the
@@ -149,7 +167,9 @@ cutoffs are set in the :doc:`pair_style lj/cut/tip4p/long
 Below is the code for a LAMMPS input file using the implicit method and
 the :ref:`TIP3P molecule file <tip3p_molecule>`.  Because the TIP4P
 charges are different from TIP3P they need to be reset (or the molecule
-file changed):
+file changed).  For simplicity and speed the example uses a cutoff
+Coulomb.  Most production simulations require long-range Coulomb
+instead.
 
 .. code-block:: LAMMPS
 
@@ -192,6 +212,94 @@ file changed):
     run 20000
     write_data tip4p-implicit.data nocoeff
 
+When constructing an OPC model, we cannot use the ``tip3p.mol`` file due
+to the different geometry.  Below is a molecule file providing the 3
+sites of an implicit OPC geometry for use with TIP4P styles.  Note, that
+the "Shake" and "Special" sections are missing here.  Those will be
+auto-generated by LAMMPS when the molecule file is loaded *after* the
+simulation box has been created.  These sections are required only when
+the molecule file is loaded *before*.
+
+.. _opc3p_molecule:
+.. code-block::
+
+   # Water molecule. 3 point geometry for OPC model
+
+   3 atoms
+   2 bonds
+   1 angles
+
+   Coords
+
+   1    0.00000  -0.06037   0.00000
+   2    0.68558   0.50250   0.00000
+   3   -0.68558   0.50250   0.00000
+
+   Types
+
+   1        1   # O
+   2        2   # H
+   3        2   # H
+
+   Charges
+
+   1       -1.3582
+   2        0.6791
+   3        0.6791
+
+   Bonds
+
+   1   1      1      2
+   2   1      1      3
+
+   Angles
+
+   1   1      2      1      3
+
+Below is a LAMMPS input file using the implicit method to implement
+the OPC model using the molecule file from above and including the
+PPPM long-range Coulomb solver.
+
+.. code-block:: LAMMPS
+
+    units real
+    atom_style full
+    region box block -5 5 -5 5 -5 5
+    create_box 2 box bond/types 1 angle/types 1 &
+                extra/bond/per/atom 2 extra/angle/per/atom 1 extra/special/per/atom 2
+
+    mass 1 15.9994
+    mass 2 1.008
+
+    pair_style lj/cut/tip4p/long 1 2 1 1 0.1594 12.0
+    pair_coeff 1 1 0.2128 3.166
+    pair_coeff 2 2 0.0    1.0
+
+    bond_style zero
+    bond_coeff 1 0.8724
+
+    angle_style zero
+    angle_coeff 1 103.6
+
+    kspace_style pppm/tip4p 1.0e-5
+
+    molecule water opc3p.mol  # this file has the OPC geometry but is without M
+    create_atoms 0 random 33 34564 NULL mol water 25367 overlap 1.33
+
+    fix rigid all shake 0.001 10 10000 b 1 a 1
+    minimize 0.0 0.0 1000 10000
+
+    reset_timestep 0
+    timestep 1.0
+    velocity all create 300.0 5463576
+    fix integrate all nvt temp 300 300 100.0
+
+    thermo_style custom step temp press etotal pe
+
+    thermo 1000
+    run 20000
+    write_data opc-implicit.data nocoeff
+
 Below is the code for a LAMMPS input file using the explicit method and
 a TIP4P molecule file.  Because of using :doc:`fix rigid/small
 <fix_rigid>` no bonds need to be defined and thus no extra storage needs
@@ -279,3 +387,8 @@ Phys, 79, 926 (1983).
 
 **(Abascal2)** Abascal, J Chem Phys, 123, 234505 (2005)
    https://doi.org/10.1063/1.2121687
+
+.. _Izadi:
+
+**(Izadi)** Izadi, Anandakrishnan, Onufriev, J. Phys. Chem. Lett., 5, 21, 3863 (2014)
+   https://doi.org/10.1021/jz501780a

doc/src/Howto_tip5p.rst

@@ -87,7 +87,9 @@ atom style full or use :doc:`fix property/atom mol <fix_property_atom>`
 so that fix rigid/small can identify rigid bodies by their molecule ID.
 Also a :doc:`neigh_modify exclude <neigh_modify>` command is added to
 exclude computing intramolecular non-bonded interactions, since those
-are removed by the rigid fix anyway:
+are removed by the rigid fix anyway.  For simplicity and speed the
+example uses a cutoff Coulomb.  Most production simulations require
+long-range Coulomb instead.
 
 .. code-block:: LAMMPS
 

doc/src/Install_git.rst

@@ -12,26 +12,17 @@ several advantages:
   LAMMPS.  For that, you should first create your own :doc:`fork on
   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
-GitHub.  For people still using subversion (svn), GitHub also
-provides `limited support for subversion clients <svn_>`_.
-
-.. note::
-
-   As of October 2016, the official home of public LAMMPS development is
-   on GitHub.  The previously advertised LAMMPS git repositories on
-   git.lammps.org and bitbucket.org are now offline or deprecated.
+You must have `git <git_>`_ installed on your system to use the commands
+explained below to communicate with the git servers on GitHub.
 
 .. _git: https://git-scm.com
-.. _svn: https://help.github.com/en/github/importing-your-projects-to-github/working-with-subversion-on-github
 
 You can follow the LAMMPS development on 4 different git branches:
 
 * **develop** : this branch follows the ongoing development and is
   updated with every merge commit of a pull request
-* **release** : this branch is updated with every "feature release";
-   updates are always "fast-forward" merges from *develop*
+* **release** : this branch is updated with every "feature release"
+  and updates are always "fast-forward" merges from *develop*
 * **maintenance** : this branch collects back-ported bug fixes from the
   *develop* branch to the *stable* branch.  It is used to update the
   *stable* branch for "stable update releases".

doc/src/Intro_authors.rst

@@ -84,8 +84,9 @@ lammps.org".  General questions about LAMMPS should be posted in the
 
    \normalsize
 
-Past developers include Paul Crozier and Mark Stevens, both at SNL,
-and Ray Shan, now at Materials Design.
+Past core developers include Paul Crozier and Mark Stevens, both at SNL,
+and Ray Shan while at SNL and later at Materials Design, now at Thermo
+Fisher Scientific.
 
 ----------
 

doc/src/Intro_portability.rst

@@ -28,8 +28,9 @@ 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.16.
+shell (``/bin/sh`` or ``/bin/bash``).  Alternatively, a build system
+with different back ends can be created using CMake.  CMake must be
+at least version 3.16.
 
 Operating systems
 ^^^^^^^^^^^^^^^^^
@@ -40,11 +41,18 @@ Also, compilation and correct execution on macOS and Windows (using
 Microsoft Visual C++) is checked automatically for the 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 incompatibilities of source code or
-build system of required external libraries or packages.
+LAMMPS source code or through incompatibilities or build system
+limitations of required external libraries or packages.
 
-Executables for Windows may be created natively using either Cygwin or
-Visual Studio or with a Linux to Windows MinGW cross-compiler.
+Executables for Windows may be created either natively using Cygwin,
+MinGW, Intel, Clang, or Microsoft Visual C++ compilers, or with a Linux
+to Windows MinGW cross-compiler.  Native compilation is supported using
+Microsoft Visual Studio or a terminal window (using the CMake build
+system).
+
+Executables for macOS may be created either using Xcode or GNU compilers
+installed with Homebrew.  In the latter case, building of LAMMPS through
+Homebrew instead of a manual compile is also possible.
 
 Additionally, FreeBSD and Solaris have been tested successfully to
 run LAMMPS and produce results consistent with those on Linux.
@@ -61,8 +69,9 @@ 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.
+64-bit ARM and PowerPC (64-bit, Little Endian) are currently regularly
+tested.  Further architectures are tested by Linux distributions that
+bundle LAMMPS.
 
 Portability compliance
 ^^^^^^^^^^^^^^^^^^^^^^

doc/src/Library.rst

@@ -93,14 +93,19 @@ run LAMMPS in serial mode.
 .. admonition:: Using the C library interface as a plugin
    :class: note
 
-   Rather than including the C library directly and link to the LAMMPS
+   Rather than including the C library interface directly using the
+   ``library.h`` header file and link to the LAMMPS (static or shared)
    library at compile time, you can use the ``liblammpsplugin.h`` header
    file and the ``liblammpsplugin.c`` C code in the
    ``examples/COUPLE/plugin`` folder for an interface to LAMMPS that is
    largely identical to the regular library interface, only that it will
    load a LAMMPS shared library file at runtime.  This can be useful for
    applications where the interface to LAMMPS would be an optional
-   feature.
+   feature or where you would like to load different version of the
+   LAMMPS library (e.g. an updated one) without replacing the executable.
+   The :ref:`LAMMPS-GUI <lammps_gui>` is an example for such a program.
+   It has its own wrapper that supports both modes and they can be
+   changed at compile time.
 
 .. warning::
 

doc/src/Library_create.rst

@@ -11,6 +11,7 @@ This section documents the following functions:
 - :cpp:func:`lammps_mpi_finalize`
 - :cpp:func:`lammps_kokkos_finalize`
 - :cpp:func:`lammps_python_finalize`
+- :cpp:func:`lammps_plugin_finalize`
 - :cpp:func:`lammps_error`
 
 --------------------
@@ -119,5 +120,10 @@ calling program.
 
 -----------------------
 
+.. doxygenfunction:: lammps_plugin_finalize
+   :project: progguide
+
+-----------------------
+
 .. doxygenfunction:: lammps_error
    :project: progguide

doc/src/Library_scatter.rst

@@ -27,6 +27,7 @@ It documents the following functions:
 - :cpp:func:`lammps_scatter`
 - :cpp:func:`lammps_scatter_subset`
 - :cpp:func:`lammps_create_atoms`
+- :cpp:func:`lammps_create_molecule`
 
 -----------------------
 
@@ -103,4 +104,8 @@ It documents the following functions:
 .. doxygenfunction:: lammps_create_atoms(void *handle, int n, const int *id, const int *type, const double *x, const double *v, const int *image, int bexpand)
    :project: progguide
 
+-----------------------
+
+.. doxygenfunction:: lammps_create_molecule
+   :project: progguide
 

doc/src/Modify_compute.rst

@@ -1,19 +1,21 @@
 Compute styles
 ==============
 
-Classes that compute scalar and vector quantities like temperature
-and the pressure tensor, as well as classes that compute per-atom
-quantities like kinetic energy and the centro-symmetry parameter
-are derived from the Compute class.  New styles can be created
-to add new calculations to LAMMPS.
+Classes that compute scalar and vector quantities like temperature and
+the pressure tensor, as well as classes that compute per-atom quantities
+like kinetic energy and the centro-symmetry parameter are derived from
+the Compute class.  New styles can be created to add new calculations to
+LAMMPS.
 
-Compute_temp.cpp is a simple example of computing a scalar
-temperature.  Compute_ke_atom.cpp is a simple example of computing
-per-atom kinetic energy.
+The ``src/compute_temp.cpp`` file is a simple example of computing a
+scalar temperature. The ``src/compute_ke_atom.cpp`` file is a simple
+example of computing per-atom kinetic energy.
 
 Here is a brief description of methods you define in your new derived
-class.  See compute.h for details.
+class.  See ``src/compute.h`` for additional details.
 
++-----------------------+------------------------------------------------------------------+
+| post_constructor      | perform tasks that cannot be run in the constructor (optional)   |
 +-----------------------+------------------------------------------------------------------+
 | init                  | perform one time setup (required)                                |
 +-----------------------+------------------------------------------------------------------+
@@ -50,10 +52,11 @@ class.  See compute.h for details.
 | memory_usage          | tally memory usage (optional)                                    |
 +-----------------------+------------------------------------------------------------------+
 
-Tally-style computes are a special case, as their computation is done
-in two stages: the callback function is registered with the pair style
-and then called from the Pair::ev_tally() function, which is called for
-each pair after force and energy has been computed for this pair. Then
-the tallied values are retrieved with the standard compute_scalar or
-compute_vector or compute_peratom methods. The :doc:`compute styles in the TALLY package <compute_tally>`
-provide *examples* for utilizing this mechanism.
+Tally-style computes are a special case, as their computation is done in
+two stages: the callback function is registered with the pair style and
+then called from the Pair::ev_tally() function, which is called for each
+pair after force and energy has been computed for this pair. Then the
+tallied values are retrieved with the standard compute_scalar or
+compute_vector or compute_peratom methods. The :doc:`compute styles in
+the TALLY package <compute_tally>` provide *examples* for utilizing this
+mechanism.

doc/src/Modify_fix.rst

@@ -1,23 +1,25 @@
 Fix styles
 ==========
 
-In LAMMPS, a "fix" is any operation that is computed during
-timestepping that alters some property of the system.  Essentially
-everything that happens during a simulation besides force computation,
-neighbor list construction, and output, is a "fix".  This includes
-time integration (update of coordinates and velocities), force
-constraints or boundary conditions (SHAKE or walls), and diagnostics
-(compute a diffusion coefficient).  New styles can be created to add
-new options to LAMMPS.
+In LAMMPS, a "fix" is any operation that is computed during timestepping
+that alters some property of the system.  Essentially everything that
+happens during a simulation besides force computation, neighbor list
+construction, and output, is a "fix".  This includes time integration
+(update of coordinates and velocities), force constraints or boundary
+conditions (SHAKE or walls), and diagnostics (compute a diffusion
+coefficient).  New styles can be created to add new options to LAMMPS.
 
-Fix_setforce.cpp is a simple example of setting forces on atoms to
-prescribed values.  There are dozens of fix options already in LAMMPS;
-choose one as a template that is similar to what you want to
-implement.
+The file ``src/fix_setforce.cpp`` is a simple example of setting forces
+on atoms to prescribed values.  There are dozens of fix options already
+in LAMMPS; choose one as a template that is similar to what you want to
+implement.  There also is a detailed discussion of :doc:`how to write
+new fix styles <Developer_write_fix>` in LAMMPS.
 
 Here is a brief description of methods you can define in your new
-derived class.  See fix.h for details.
+derived class.  See ``src/fix.h`` for additional details.
 
++---------------------------+--------------------------------------------------------------------------------------------+
+| post_constructor          | perform tasks that cannot be run in the constructor (optional)                             |
 +---------------------------+--------------------------------------------------------------------------------------------+
 | setmask                   | determines when the fix is called during the timestep (required)                           |
 +---------------------------+--------------------------------------------------------------------------------------------+
@@ -130,10 +132,11 @@ derived class.  See fix.h for details.
 
 Typically, only a small fraction of these methods are defined for a
 particular fix.  Setmask is mandatory, as it determines when the fix
-will be invoked during the timestep.  Fixes that perform time
-integration (\ *nve*, *nvt*, *npt*\ ) implement initial_integrate() and
-final_integrate() to perform velocity Verlet updates.  Fixes that
-constrain forces implement post_force().
+will be invoked during :doc:`the evolution of a timestep
+<Developer_flow>`.  Fixes that perform time integration (\ *nve*, *nvt*,
+*npt*\ ) implement initial_integrate() and final_integrate() to perform
+velocity Verlet updates.  Fixes that constrain forces implement
+post_force().
 
 Fixes that perform diagnostics typically implement end_of_step().  For
 an end_of_step fix, one of your fix arguments must be the variable
@@ -143,13 +146,13 @@ is the first argument the fix defines (after the ID, group-ID, style).
 
 If the fix needs to store information for each atom that persists from
 timestep to timestep, it can manage that memory and migrate the info
-with the atoms as they move from processors to processor by
-implementing the grow_arrays, copy_arrays, pack_exchange, and
-unpack_exchange methods.  Similarly, the pack_restart and
-unpack_restart methods can be implemented to store information about
-the fix in restart files.  If you wish an integrator or force
-constraint fix to work with rRESPA (see the :doc:`run_style <run_style>`
-command), the initial_integrate, post_force_integrate, and
-final_integrate_respa methods can be implemented.  The thermo method
-enables a fix to contribute values to thermodynamic output, as printed
-quantities and/or to be summed to the potential energy of the system.
+with the atoms as they move from processors to processor by implementing
+the grow_arrays, copy_arrays, pack_exchange, and unpack_exchange
+methods.  Similarly, the pack_restart and unpack_restart methods can be
+implemented to store information about the fix in restart files.  If you
+wish an integrator or force constraint fix to work with rRESPA (see the
+:doc:`run_style <run_style>` command), the initial_integrate,
+post_force_integrate, and final_integrate_respa methods can be
+implemented.  The thermo method enables a fix to contribute values to
+thermodynamic output, as printed quantities and/or to be summed to the
+potential energy of the system.

doc/src/Modify_pair.rst

@@ -46,6 +46,8 @@ Here is a brief list of some the class methods in the Pair class that
 +---------------------------------+------------------------------------------------------------------------+
 | compute_inner/middle/outer      | versions of compute used by rRESPA                                     |
 +---------------------------------+------------------------------------------------------------------------+
+| compute_atomic_energy           | energy of one atom, equivalent to per-atom energy                      |
++---------------------------------+------------------------------------------------------------------------+
 | memory_usage                    | return estimated amount of memory used by the pair style               |
 +---------------------------------+------------------------------------------------------------------------+
 | modify_params                   | process arguments to pair_modify command                               |
@@ -122,3 +124,5 @@ setting.
 +---------------------------------+-------------------------------------------------------------+---------+
 | spinflag                        | 1 if compatible with spin kspace_style                      | 0       |
 +---------------------------------+-------------------------------------------------------------+---------+
+| atomic_energy_enable            | 1 if compute_atomic_energy() routine exists                 | 0       |
++---------------------------------+-------------------------------------------------------------+---------+

doc/src/Packages_details.rst

@@ -28,6 +28,7 @@ gives those details.
 
    * :ref:`ADIOS <PKG-ADIOS>`
    * :ref:`AMOEBA <PKG-AMOEBA>`
+   * :ref:`APIP <PKG-APIP>`
    * :ref:`ASPHERE <PKG-ASPHERE>`
    * :ref:`ATC <PKG-ATC>`
    * :ref:`AWPMD <PKG-AWPMD>`
@@ -186,6 +187,60 @@ provided by the Ponder group in their
 
 ----------
 
+.. _PKG-APIP:
+
+APIP package
+------------
+
+**Contents:**
+
+This package provides adaptive-precision interatomic potentials (APIP) as
+described in:
+
+D. Immel, R. Drautz and G. Sutmann, "Adaptive-precision potentials for
+large-scale atomistic simulations", J. Chem. Phys. 162, 114119 (2025)
+`link <immel2025_doi_>`_
+
+Adaptive-precision means, that a fast interatomic potential, such as EAM,
+is coupled to a precise interatomic potential, such as ACE.
+This package provides the required pair_styles and fixes to run an efficient,
+energy-conserving adaptive-precision simulation.
+
+In the context of this package, precision refers to the accuracy of an interatomic
+potential.
+
+.. _immel2025_doi: https://doi.org/10.1063/5.0245877
+
+**Authors:**
+
+This package was written by David Immel^1,
+Ralf Drautz^2 and Godehard Sutmann^1^2.
+
+ ^1: Forschungszentrum Juelich, Juelich, Germany
+
+ ^2: Ruhr-University Bochum, Bochum, Germany
+
+**Install:**
+
+The APIP package requires also the installation of ML-PACE, which has
+:ref:`specific installation instructions <ml-pace>` on the
+:doc:`Build extras <Build_extras>` page.
+
+**Supporting info:**
+
+* ``src/APIP``: filenames -> commands
+* :doc:`Howto APIP <Howto_apip>`
+* ``examples/PACKAGES/apip``
+* :doc:`fix atom_weight/apip <fix_atom_weight_apip>`
+* :doc:`fix lambda/apip <fix_lambda_apip>`
+* :doc:`fix lambda_thermostat/apip <fix_lambda_thermostat_apip>`
+* :doc:`pair_style eam/apip <pair_eam_apip>`
+* :doc:`pair_style lambda/zone/apip <pair_lambda_zone_apip>`
+* :doc:`pair_style lambda/input/apip <pair_lambda_input_apip>`
+* :doc:`pair_style pace/apip <pair_pace_apip>`
+
+----------
+
 .. _PKG-ASPHERE:
 
 ASPHERE package

doc/src/Packages_list.rst

@@ -38,6 +38,11 @@ whether an extra library is needed to build and use the package:
      - :doc:`AMOEBA and HIPPO howto <Howto_amoeba>`
      - amoeba
      - no
+   * - :ref:`APIP <PKG-APIP>`
+     - adaptive-precision interatomic potentials
+     - :doc:`Howto APIP <Howto_apip>`
+     - ``PACKAGES/apip``
+     - ext
    * - :ref:`ASPHERE <PKG-ASPHERE>`
      - aspherical particle models
      - :doc:`Howto spherical <Howto_spherical>`

doc/src/Python_call.rst

@@ -5,18 +5,28 @@ LAMMPS has several commands which can be used to invoke Python
 code directly from an input script:
 
 * :doc:`python <python>`
-* :doc:`variable python <variable>`
+* :doc:`python-style variables <variable>`
+* :doc:`equal-style and atom-style variables with formulas containing Python function wrappers <variable>`
 * :doc:`fix python/invoke <fix_python_invoke>`
 * :doc:`pair_style python <pair_python>`
 
-The :doc:`python <python>` command which can be used to define and
-execute a Python function that you write the code for.  The Python
-function can also be assigned to a LAMMPS python-style variable via
-the :doc:`variable <variable>` command.  Each time the variable is
+The :doc:`python <python>` command can be used to define and execute a
+Python function that you write the code for.  The Python function can
+also be assigned to a LAMMPS python-style variable via the
+:doc:`variable <variable>` command.  Each time the variable is
 evaluated, either in the LAMMPS input script itself, or by another
 LAMMPS command that uses the variable, this will trigger the Python
 function to be invoked.
 
+The Python function can also be referenced in the formula used to
+define an :doc:`equal-style or atom-style variable <variable>`, using
+the syntax for a :doc:`Python function wrapper <variable>`.  This make
+it easy to pass LAMMPS-related arguments to the Python function, as
+well as to invoke it whenever the equal- or atom-style variable is
+evaluated.  For an atom-style variable it means the Python function
+can be invoked once per atom, using per-atom properties as arguments
+to the function.
+
 The Python code for the function can be included directly in the input
 script or in an auxiliary file.  The function can have arguments which
 are mapped to LAMMPS variables (also defined in the input script) and

doc/src/Python_install.rst

@@ -106,20 +106,37 @@ folder that the dynamic loader searches or inside of the installed
       has to be made during the CMake configuration step.
 
       If the default settings of ``make install-python`` are not what you want,
-      you can invoke ``install.py`` from the python directory manually as
+      you can invoke ``install.py`` from the ``python`` directory manually as
 
       .. code-block:: bash
 
-         python install.py -p <python package> -l <shared library> -v <version.h file> [-n] [-f]
+         python3 install.py -p <python package> -l <shared library> -v <version.h file> [-n] [-f]
+
+      * The ``-p`` flag argument is the full path to the
+        ``python/lammps`` folder to be installed,
+      * the ``-l`` flag argument is the full path to the LAMMPS shared
+        library file to be installed,
+      * the ``-v`` flag argument is the full path to the ``src/version.h`` file
+      * the optional ``-n`` flag instructs the script to only build a
+        wheel file but not attempt to install it (default is to try installing),
+      * the optional ``-w`` flag argument is the path to a folder where
+        to store the resulting wheel file (default is the current folder)
+      * and the optional ``-f`` argument instructs the script to force
+        installation even if pip would otherwise refuse installation
+        with an :ref:`error about externally managed environments
+        <externally_managed>`. The Python developers recommend to not
+        augment a Python installation with custom packages, both at the
+        user and the system level, and advise to use virtual
+        environments instead.  Some recent Linux distributions enforce
+        that recommendation by default.
+
+      Example command line for building only the wheel after building
+      LAMMPS with ``cmake`` in the folder ``build``:
+
+      .. code-block:: bash
+
+         python3 python/install.py -n -p python/lammps -l build/liblammps.so -v src/version.h -w build
 
-      * The ``-p`` flag points to the ``lammps`` Python package folder to be installed,
-      * the ``-l`` flag points to the LAMMPS shared library file to be installed,
-      * the ``-v`` flag points to the LAMMPS version header file to extract the version date,
-      * the optional ``-n`` instructs the script to only build a wheel file but not attempt
-        to install it,
-      * and the optional ``-f`` argument instructs the script to force installation even if
-        pip would otherwise refuse installation with an
-        :ref:`error about externally managed environments <externally_managed>`.
 
    .. tab:: Virtual environment
 
@@ -335,4 +352,3 @@ that the order of the lines is not deterministic
    Proc 1 out of 4 procs
    Proc 2 out of 4 procs
    Proc 3 out of 4 procs
-

doc/src/Python_launch.rst

@@ -1,7 +1,7 @@
 Running LAMMPS and Python in serial
 -----------------------------------
 
-To run a LAMMPS in serial, type these lines into Python
+To run a LAMMPS input in serial, type these lines into Python
 interactively from the ``bench`` directory:
 
 .. code-block:: python

doc/src/Python_scatter.rst

@@ -3,17 +3,16 @@ Scatter/gather operations
 
 .. code-block:: python
 
-   data = lmp.gather_atoms(name,type,count)  # return per-atom property of all atoms gathered into data, ordered by atom ID
-                                             # name = "x", "charge", "type", etc
-   data = lmp.gather_atoms_concat(name,type,count)  # ditto, but concatenated atom values from each proc (unordered)
-   data = lmp.gather_atoms_subset(name,type,count,ndata,ids)  # ditto, but for subset of Ndata atoms with IDs
+   data = lmp.gather_atoms(name,dtype,count)  # return per-atom property of all atoms gathered into data, ordered by atom ID
+                                              # name = "x", "q", "type", etc
+   data = lmp.gather_atoms_concat(name,dtype,count)  # ditto, but concatenated atom values from each proc (unordered)
+   data = lmp.gather_atoms_subset(name,dtype,count,ndata,ids)  # ditto, but for subset of Ndata atoms with IDs
 
-   lmp.scatter_atoms(name,type,count,data)   # scatter per-atom property to all atoms from data, ordered by atom ID
-                                             # name = "x", "charge", "type", etc
+   lmp.scatter_atoms(name,dtype,count,data)   # scatter per-atom property to all atoms from data, ordered by atom ID
+                                              # name = "x", "q", "type", etc
                                               # count = # of per-atom values, 1 or 3, etc
 
-   lmp.scatter_atoms_subset(name,type,count,ndata,ids,data)  # ditto, but for subset of Ndata atoms with IDs
-
+   lmp.scatter_atoms_subset(name,dtype,count,ndata,ids,data)  # ditto, but for subset of Ndata atoms with IDs
 
 The gather methods collect peratom info of the requested type (atom
 coords, atom types, forces, etc) from all processors, and returns the
@@ -22,6 +21,12 @@ functions do the inverse.  They distribute a vector of peratom values,
 passed by all calling processors, to individual atoms, which may be
 owned by different processors.
 
+The *dtype* parameter is 0 for ``int`` values and 1 for ``double``
+values.  The *count* parameter is 1 for per-atom vectors like "type"
+or "q" and 3 for per-atom arrays like "x", "v", "f". Use *count* = 3
+with name = "image" if you want the single integer storing the image
+flags unpacked into 3 components ("x", "y", and "z").
+
 Note that the data returned by the gather methods,
 e.g. :py:meth:`gather_atoms("x") <lammps.lammps.gather_atoms()>`, is
 different from the data structure returned by

doc/src/Speed_compare.rst

@@ -75,15 +75,34 @@ section below for examples where this has been done.
 **Differences between the GPU and KOKKOS packages:**
 
 * The GPU package accelerates only pair force, neighbor list, and (parts
-  of) PPPM calculations. The KOKKOS package attempts to run most of the
+  of) PPPM calculations (and runs the remaining force computations on
+  the CPU concurrently).  The KOKKOS package attempts to run most of the
   calculation on the GPU, but can transparently support non-accelerated
   code (with a performance penalty due to having data transfers between
   host and GPU).
+* The list of which styles are accelerated by the GPU or KOKKOS package
+  differs with some overlap.
 * The GPU package requires neighbor lists to be built on the CPU when using
   hybrid pair styles, exclusion lists, or a triclinic simulation box.
-* The GPU package can be compiled for CUDA, HIP, or OpenCL and thus supports
-  NVIDIA, AMD, and Intel GPUs well. On NVIDIA hardware, using CUDA is
-  typically resulting in equal or better performance over OpenCL.
-* OpenCL in the GPU package does theoretically also support Intel CPUs or
-  Intel Xeon Phi, but the native support for those in KOKKOS (or INTEL)
-  is superior.
+* The GPU package benefits from running multiple MPI processes (2-8) per
+  GPU to parallelize the non-GPU accelerated styles.  The KOKKOS package
+  usually not, especially when all parts of the calculation have KOKKOS
+  support.
+* The GPU package can be compiled for CUDA, HIP, or OpenCL and thus
+  supports NVIDIA, AMD, and Intel GPUs well. On NVIDIA or AMD hardware,
+  using native CUDA or HIP compilation, respectively, with either GPU or
+  KOKKOS results in equal or better performance over OpenCL.
+* OpenCL in the GPU package supports NVIDIA, AMD, and Intel GPUs at the
+  *same time* and with the *same executable*.  KOKKOS currently does not
+  support OpenCL.
+* The GPU package supports single precision floating point, mixed
+  precision floating point, and double precision floating point math on
+  the GPU.  This must be chosen at compile time.  KOKKOS currently only
+  supports double precision floating point math.  Using single or mixed
+  precision (recommended) results in significantly improved performance
+  on consumer GPUs for some loss in accuracy (which is rather small with
+  mixed precision).  Single and mixed precision support for KOKKOS is in
+  development (no ETA yet).
+* Some pair styles (for example :doc:`snap <pair_snap>`, :doc:`mliap
+  <pair_mliap>` or :doc:`reaxff <pair_reaxff>` in the KOKKOS package have
+  seen extensive optimizations and specializations for GPUs and CPUs.

doc/src/Speed_measure.rst

@@ -1,16 +1,218 @@
 Measuring performance
 =====================
 
-Before trying to make your simulation run faster, you should
-understand how it currently performs and where the bottlenecks are.
+Factors that influence performance
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-The best way to do this is run the your system (actual number of
-atoms) for a modest number of timesteps (say 100 steps) on several
-different processor counts, including a single processor if possible.
-Do this for an equilibrium version of your system, so that the
-100-step timings are representative of a much longer run.  There is
-typically no need to run for 1000s of timesteps to get accurate
-timings; you can simply extrapolate from short runs.
+Before trying to make your simulation run faster, you should understand
+how it currently performs and where the bottlenecks are.  We generally
+distinguish between serial performance (how fast can a single process do
+the calculations?) and parallel efficiency (how much faster does a
+calculation get by using more processes?).  There are many factors
+affecting either and below are some lists discussing some commonly
+known but also some less known factors.
+
+Factors affecting serial performance (in no specific order):
+
+* CPU hardware: clock rate, cache sizes, CPU architecture (instructions
+  per clock, vectorization support, fused multiply-add support and more)
+* RAM speed and number of channels that the CPU can use to access RAM
+* Cooling: CPUs can change the CPU clock based on thermal load, thus the
+  degree of cooling can affect the speed of a CPU.  Sometimes even the
+  temperature of neighboring compute nodes in a cluster can make a
+  difference.
+* Compiler optimization: most of LAMMPS is written to be easy to modify
+  and thus compiler optimization can speed up calculations. However, too
+  aggressive compiler optimization can produce incorrect results or
+  crashes (during compilation or at runtime).
+* Source code improvements: styles in the OPT, OPENMP, and INTEL package
+  can be faster than their base implementation due to improved data
+  access patterns, cache efficiency, or vectorization. Compiler optimization
+  is required to take full advantage of these.
+* Number and kind of fixes, computes, or variables used during a simulation,
+  especially if they result in collective communication operations
+* Pair style cutoffs and system density: calculations get slower the more
+  neighbors are in the neighbor list and thus for which interactions need
+  to be computed.  Force fields with pair styles that compute interactions
+  between triples or quadruples of atoms or that use embedding energies or
+  charge equilibration will need to walk the neighbor lists multiple times.
+* Neighbor list settings: tradeoff between neighbor list skin (larger
+  skin = more neighbors, more distances to compute before applying the
+  cutoff) and frequency of neighbor list builds (larger skin = fewer
+  neighbor list builds).
+* Proximity of per-atom data in physical memory that for atoms that are
+  close in space improves cache efficiency (thus LAMMPS will by default
+  sort atoms in local storage accordingly)
+* Using r-RESPA multi-timestepping or a SHAKE or RATTLE fix to constrain
+  bonds with higher-frequency vibrations may allow a larger (outer) timestep
+  and thus fewer force evaluations (usually the most time consuming step in
+  MD) for the same simulated time (with some tradeoff in accuracy).
+
+Factors affecting parallel efficiency (in no specific order):
+
+* Bandwidth and latency of communication between processes. This can vary a
+  lot between processes on the same CPU or physical node and processes
+  on different physical nodes and there vary between different
+  communication technologies (like Ethernet or InfiniBand or other
+  high-speed interconnects)
+* Frequency and complexity of communication patterns required
+* Number of "work units" (usually correlated with the number of atoms
+  and choice of force field) per MPI-process required for one time step
+  (if this number becomes too small, the cost of communication becomes
+  dominant).
+* Choice of parallelization method (MPI-only, OpenMP-only, MPI+OpenMP,
+  MPI+GPU, MPI+GPU+OpenMP)
+* Algorithmic complexity of the chosen force field (pair-wise vs. many-body
+  potential, Ewald vs. PPPM vs. (compensated or smoothed) cutoff-Coulomb)
+* Communication cutoff: a larger cutoff results in more ghost atoms and
+  thus more data that needs to be communicated
+* Frequency of neighbor list builds: during a neighbor list build the
+  domain decomposition is updated and the list of ghost atoms rebuilt
+  which requires multiple global communication steps
+* FFT-grid settings and number of MPI processes for kspace style PPPM:
+  PPPM uses parallel 3d FFTs which will drop much faster in parallel
+  efficiency with respect to the number of MPI processes than other
+  parts of the force computation.  Thus using MPI+OpenMP parallelization
+  or :doc:`run style verlet/split <run_style>` can improve parallel
+  efficiency by limiting the number of MPI processes used for the FFTs.
+* Load (im-)balance: LAMMPS' domain decomposition assumes that atoms are
+  evenly distributed across the entire simulation box. If there are
+  areas of vacuum, this may lead to different amounts of work for
+  different MPI processes. Using the :doc:`processors command
+  <processors>` to change the spatial decomposition, or MPI+OpenMP
+  parallelization instead of only-MPI to have larger sub-domains, or the
+  (fix) balance command (without or with switching to communication style
+  tiled) to change the sub-domain volumes are all methods that
+  can help to avoid load imbalances.
+
+Examples comparing serial performance
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Before looking at your own input deck(s), you should get some reference
+data from a known input so that you know what kind of performance you
+should expect from your input.  For the following we therefore use the
+``in.rhodo.scaled`` input file and ``data.rhodo`` data file from the
+``bench`` folder. This is a system of 32000 atoms using the CHARMM force
+field and long-range electrostatics running for 100 MD steps.  The
+performance data is printed at the end of a run and only measures the
+performance during propagation and excludes the setup phase.
+
+Running with a single MPI process on an AMD Ryzen Threadripper PRO
+9985WX CPU (64 cores, 128 threads, base clock: 3.2GHz, max. clock
+5.4GHz, L1/L2/L3 cache 5MB/64MB/256MB, 8 DDR5-6400 memory channels) one
+gets the following performance report:
+
+.. code-block::
+
+   Performance: 1.232 ns/day, 19.476 hours/ns, 7.131 timesteps/s, 228.197 katom-step/s
+   99.2% CPU use with 1 MPI tasks x 1 OpenMP threads
+
+The %CPU value should be at 100% or very close.  Lower values would
+be an indication that there are *other* processes also using the same
+CPU core and thus invalidating the performance data.  The katom-step/s
+value is best suited for comparisons, since it is fairly independent
+from the system size. The `in.rhodo.scaled` input can be easily made
+larger through replication in the three dimensions by settings variables
+"x", "y", "z" to values other than 1 from the command line with the
+"-var" flag. Example:
+
+- 32000 atoms: 228.8 katom-step/s
+- 64000 atoms: 231.6 katom-step/s
+- 128000 atoms: 231.1 katom-step/s
+- 256000 atoms: 226.4 katom-step/s
+- 864000 atoms: 229.6 katom-step/s
+
+Comparing to an AMD Ryzen 7 7840HS CPU (8 cores, 16 threads, base clock
+3.8GHz, max. clock 5.1GHz, L1/L2/L3 cache 512kB/8MB/16MB, 2 DDR5-5600
+memory channels), we get similar single core performance (~220
+katom-step/s vs. ~230 katom-step/s) due to the similar clock and
+architecture:
+
+- 32000 atoms: 219.8 katom-step/s
+- 64000 atoms: 222.5 katom-step/s
+- 128000 atoms: 216.8 katom-step/s
+- 256000 atoms: 221.0 katom-step/s
+- 864000 atoms: 221.1 katom-step/s
+
+Switching to an older Intel Xeon E5-2650 v4 CPU (12 cores, 12 threads,
+base clock 2.2GHz, max. clock 2.9GHz, L1/L2/L3 cache (64kB/256kB/30MB, 4
+DDR4-2400 memory channels) leads to a lower performance of approximately
+109 katom-step/s due to differences in architecture and clock.  In all
+cases, when looking at multiple runs, the katom-step/s property
+fluctuates by approximately 1% around the average.
+
+From here on we are looking at the performance for the 256000 atom system only
+and change several settings incrementally:
+
+#. No compiler optimization GCC (-Og -g): 183.8 katom-step/s
+#. Moderate optimization with debug info GCC (-O2 -g): 231.1 katom-step/s
+#. Full compiler optimization GCC (-DNDEBUG -O3): 236.0 katom-step/s
+#. Aggressive compiler optimization GCC (-O3 -ffast-math -march=native): 239.9 katom-step/s
+#. Source code optimization in OPENMP package (1 thread): 266.7 katom-step/s
+#. Use *fix nvt* instead of *fix npt* (compute virial only every 50 steps): 272.9 katom-step/s
+#. Increase pair style cutoff by 2 :math:`\AA`: 181.2 katom-step/s
+#. Use tight PPPM convergence (1.0e-6 instead of 1.0e-4): 161.9 katom-step/s
+#. Use Ewald summation instead of PPPM (at 1.0e-4 convergence): 19.9 katom-step/s
+
+The numbers show that gains from aggressive compiler optimizations are
+rather small in LAMMPS, the data access optimizations in the OPENMP (and
+OPT) packages are more prominent.  On the other side, using more
+accurate force field settings causes, not unexpectedly, a significant
+slowdown (to about half the speed).  Finally, using regular Ewald
+summation causes a massive slowdown due to the bad algorithmic scaling
+with system size.
+
+Examples comparing parallel performance
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The parallel performance usually goes on top of the serial performance.
+Using twice as many processors should increase the performance metric
+by up to a factor of two.  With the number of processors *N* and the
+serial performance :math:`p_1` and the performance for *N* processors
+:math:`p_N` we can define a *parallel efficiency* in percent as follows:
+
+.. math::
+
+   P_{eff} = \frac{p_N}{p_1 \cdot N} \cdot 100\%
+
+For the AMD Ryzen Threadripper PRO 9985WX CPU and the serial
+simulation settings of point 6. from above, we get the following
+parallel efficiency data for the 256000 atom system:
+
+- 1 MPI task: 273.6 katom-step/s, :math:`P_{eff} = 100\%`
+- 2 MPI tasks: 530.6 katom-step/s, :math:`P_{eff} = 97\%`
+- 4 MPI tasks: 1.021 Matom-step/s, :math:`P_{eff} = 93\%`
+- 8 MPI tasks: 1.837 Matom-step/s, :math:`P_{eff} = 84\%`
+- 16 MPI tasks: 3.574 Matom-step/s, :math:`P_{eff} = 82\%`
+- 32 MPI tasks: 6.479 Matom-step/s, :math:`P_{eff} = 74\%`
+- 64 MPI tasks: 9.032 Matom-step/s, :math:`P_{eff} = 52\%`
+- 128 MPI tasks: 12.03 Matom-step/s, :math:`P_{eff} = 34\%`
+
+The 128 MPI tasks run uses CPU cores from hyper-threading.
+
+For a small system with only 32000 atoms the parallel efficiency
+drops off earlier when the number of work units is too small relative
+to the communication overhead:
+
+- 1 MPI task:  270.8  katom-step/s, :math:`P_{eff} = 100\%`
+- 2 MPI tasks: 529.3  katom-step/s, :math:`P_{eff} = 98\%`
+- 4 MPI tasks: 989.8  katom-step/s, :math:`P_{eff} = 91\%`
+- 8 MPI tasks: 1.832  Matom-step/s, :math:`P_{eff} = 85\%`
+- 16 MPI tasks: 3.463 Matom-step/s, :math:`P_{eff} = 80\%`
+- 32 MPI tasks: 5.970 Matom-step/s, :math:`P_{eff} = 69\%`
+- 64 MPI tasks: 7.477 Matom-step/s, :math:`P_{eff} = 42\%`
+- 128 MPI tasks: 8.069 Matom-step/s, :math:`P_{eff} = 23\%`
+
+Measuring performance of your input deck
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The best way to do this is run the your system (actual number of atoms)
+for a modest number of timesteps (say 100 steps) on several different
+processor counts, including a single processor if possible.  Do this for
+an equilibrium version of your system, so that the 100-step timings are
+representative of a much longer run.  There is typically no need to run
+for 1000s of timesteps to get accurate timings; you can simply
+extrapolate from short runs.
 
 For the set of runs, look at the timing data printed to the screen and
 log file at the end of each LAMMPS run.  The
@@ -28,12 +230,15 @@ breakdown and relative percentages.  For example, trying different
 options for speeding up the long-range solvers will have little impact
 if they only consume 10% of the run time.  If the pairwise time is
 dominating, you may want to look at GPU or OMP versions of the pair
-style, as discussed below.  Comparing how the percentages change as
-you increase the processor count gives you a sense of how different
-operations within the timestep are scaling.  Note that if you are
-running with a Kspace solver, there is additional output on the
-breakdown of the Kspace time.  For PPPM, this includes the fraction
-spent on FFTs, which can be communication intensive.
+style, as discussed below.  Comparing how the percentages change as you
+increase the processor count gives you a sense of how different
+operations within the timestep are scaling.  If you are using PPPM as
+Kspace solver, you can turn on an additional output with
+:doc:`kspace_modify fftbench yes <kspace_modify>` which measures the
+time spent during PPPM on the 3d FFTs, which can be communication
+intensive for larger processor counts.  This provides an indication
+whether it is worth trying out alternatives to the default FFT settings
+for additional performance.
 
 Another important detail in the timing info are the histograms of
 atoms counts and neighbor counts.  If these vary widely across

doc/src/Tools.rst

@@ -92,6 +92,7 @@ Miscellaneous tools
    * :ref:`LAMMPS coding standards <coding_standard>`
    * :ref:`emacs <emacs>`
    * :ref:`i-PI <ipi>`
+   * :ref:`JSON support <json>`
    * :ref:`kate <kate>`
    * :ref:`LAMMPS-GUI <lammps_gui>`
    * :ref:`LAMMPS magic patterns for file(1) <magic>`
@@ -364,7 +365,7 @@ These tools were provided by Aidan Thompson at Sandia
 .. _fep:
 
 fep tool
-------------------
+--------
 
 The tools/fep directory contains Python scripts useful for
 post-processing results from performing free-energy perturbation
@@ -379,7 +380,7 @@ See README file in the tools/fep directory.
 .. _ipi:
 
 i-PI tool
--------------------
+---------
 
 .. versionchanged:: 27June2024
 
@@ -432,6 +433,87 @@ tools/createatoms tool's input file.
 
 ----------
 
+.. _json:
+
+JSON support files
+------------------
+
+.. versionadded:: 12June2025
+
+The ``tools/json`` directory contains files and tools to support
+using `JSON format <https://www.json.org/>`_ files in LAMMPS.
+Currently only the :doc:`molecule command <molecule>` supports
+files in JSON format directly, but this is planned to be expanded
+in the future.
+
+JSON file validation
+^^^^^^^^^^^^^^^^^^^^
+
+The JSON syntax is independent of its content, and thus the data in the
+file must follow suitable conventions to be correctly parsed during
+input.  This can be done in a portable fashion using a `JSON schema file
+<https://json-schema.org/>`_ (which is in JSON format as well) to define
+those conventions.  A suitable JSON validator software can then validate
+JSON files against the requirements.  Validating a particular JSON file
+against a schema ensures that both, the syntax *and* the conventions
+are followed.  This is useful when writing or editing JSON files in a
+text editor or when writing a pre-processing script or tool to create
+JSON files for a specific purpose in LAMMPS.  It **cannot** check
+whether the file contents are physically meaningful, though.
+
+One such validator tool is `check-jsonschema
+<https://check-jsonschema.readthedocs.io/>`_ which is written in Python
+and can be installed using the `pip Python package manager
+<https://pypi.org/>`_, best in a virtual environment as shown below (for
+a Bourne Shell command line):
+
+.. code-block:: sh
+
+   python -m venv validate-json
+   source validate-json/bin/activate
+   pip install --upgrade pip
+   pip install check-jsonschema
+
+To validate a specific JSON file against a provided schema (here for
+a :doc:`molecule command file <molecule>` you would then run for example:
+
+.. code-block:: sh
+
+   check-jsonschema --schemafile molecule-schema.json tip3p.json
+
+The latest schema files are also maintained and available for download
+at https://download.lammps.org/json .  This enables validation of JSON
+files even if the LAMMPS sources are not locally available. Example:
+
+.. code-block:: sh
+
+   check-jsonschema --schemafile https://download.lammps.org/json/molecule-schema.json tip3p.json
+
+JSON file format normalization
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+There are extensions to the strict JSON format that allow for comments
+or ignore additional (dangling) commas. The ``reformat-json.cpp`` tool
+will read JSON files in relaxed format, but write it out in strict format.
+It is also possible to change the level of indentation from -1 (all data
+one long line) to any positive integer value.  The original file will be
+backed up (.bak added to file name) and then overwritten.
+
+Manual compilation (it will be automatically included in the CMake build
+if building tools is requested during CMake configuration):
+
+.. code-block:: sh
+
+   g++ -I <path/to/lammps/src> -o reformat-json reformat-json.cpp
+
+Usage:
+
+.. parsed-literal::
+
+   reformat-json <indent-width> <json-file-1> [<json-file-2> ...]
+
+----------
+
 .. _kate:
 
 kate tool
@@ -475,9 +557,13 @@ beginners to start with LAMMPS, it is also the expectation that
 LAMMPS-GUI users will eventually transition to workflows that most
 experienced LAMMPS users employ.
 
-All features have been extensively exposed to keyboard shortcuts, so
-that there is also appeal for experienced LAMMPS users for prototyping
-and testing simulation setups.
+.. image:: JPG/lammps-gui-screen.png
+   :align: center
+   :scale: 50%
+
+Features have been extensively exposed to keyboard shortcuts, so that
+there is also appeal for experienced LAMMPS users for prototyping and
+testing simulation setups.
 
 Features
 ^^^^^^^^
@@ -502,7 +588,7 @@ Here are a few highlights of LAMMPS-GUI
 - Visualization of current state in Image Viewer (via calling :doc:`write_dump image <dump_image>`)
 - Capture of images created via :doc:`dump image <dump_image>` in Slide show window
 - Dialog to set variables, similar to the LAMMPS command-line flag '-v' / '-var'
-- Support for GPU, INTEL, KOKKOS/OpenMP, OPENMAP, and OPT and accelerator packages
+- Support for GPU, INTEL, KOKKOS/OpenMP, OPENMP, and OPT accelerator packages
 
 Parallelization
 ^^^^^^^^^^^^^^^
@@ -523,8 +609,8 @@ with CMake is required.
 The LAMMPS-GUI has been successfully compiled and tested on:
 
 - Ubuntu Linux 20.04LTS x86_64 using GCC 9, Qt version 5.12
-- Fedora Linux 40 x86\_64 using GCC 14 and Clang 17, Qt version 5.15LTS
-- Fedora Linux 40 x86\_64 using GCC 14, Qt version 6.7
+- Fedora Linux 41 x86\_64 using GCC 14 and Clang 17, Qt version 5.15LTS
+- Fedora Linux 41 x86\_64 using GCC 14, Qt version 6.8
 - Apple macOS 12 (Monterey) and macOS 13 (Ventura) with Xcode on arm64 and x86\_64, Qt version 5.15LTS
 - Windows 10 and 11 x86_64 with Visual Studio 2022 and Visual C++ 14.36, Qt version 5.15LTS
 - Windows 10 and 11 x86_64 with Visual Studio 2022 and Visual C++ 14.40, Qt version 6.7
@@ -1250,10 +1336,10 @@ tabulate tool
 
 .. versionadded:: 22Dec2022
 
-The ``tabulate`` folder contains Python scripts scripts to generate tabulated
-potential files for LAMMPS.  The bulk of the code is in the ``tabulate`` module
-in the ``tabulate.py`` file.  Some example files demonstrating its use are
-included.  See the README file for more information.
+The ``tabulate`` folder contains Python scripts scripts to generate and
+visualize tabulated potential files for LAMMPS.  The bulk of the code is in the
+``tabulate`` module in the ``tabulate.py`` file.  Some example files
+demonstrating its use are included.  See the README file for more information.
 
 ----------
 
@@ -1276,11 +1362,13 @@ Those scripts were written by Steve Plimpton sjplimp at gmail.com
 valgrind tool
 -------------
 
-The ``valgrind`` folder contains additional suppressions fur LAMMPS when using
-valgrind's memcheck tool to search for memory access violation and memory
-leaks. These suppressions are automatically invoked when running tests through
-CMake "ctest -T memcheck". See the provided README file to add these
-suppressions when running LAMMPS.
+The ``valgrind`` folder contains additional suppressions for LAMMPS when
+using `valgrind's <https://valgrind.org/>`_ ` `memcheck tool
+<https://valgrind.org/info/tools.html#memcheck>`_ to search for memory
+access violation and memory leaks.  These suppressions are automatically
+invoked when running tests through CMake "ctest -T memcheck".  See the
+instruction in the ``README`` file to add these suppressions when using
+valgrind with LAMMPS or other programs.
 
 ----------
 

doc/src/atom_style.rst

@@ -10,7 +10,7 @@ Syntax
 
    atom_style style args
 
-* style = *amoeba* or *angle* or *atomic* or *body* or *bond* or *charge* or *dielectric* or *dipole* or  *dpd* or *edpd* or *electron* or *ellipsoid* or *full* or *line* or *mdpd* or *molecular* or *oxdna* or *peri* or *smd* or *sph* or *sphere* or *bpm/sphere* or *spin* or *tdpd* or *tri* or *template* or *wavepacket* or *hybrid*
+* style = *amoeba* or *angle* or *apip* or *atomic* or *body* or *bond* or *charge* or *dielectric* or *dipole* or  *dpd* or *edpd* or *electron* or *ellipsoid* or *full* or *line* or *mdpd* or *molecular* or *oxdna* or *peri* or *smd* or *sph* or *sphere* or *bpm/sphere* or *spin* or *tdpd* or *tri* or *template* or *wavepacket* or *hybrid*
 
   .. parsed-literal::
 
@@ -117,6 +117,10 @@ the Additional Information section below.
      - *bond* + "angle data"
      - :ref:`MOLECULE <PKG-MOLECULE>`
      - bead-spring polymers with stiffness
+   * - *apip*
+     - *atomic* + apip_lambda, apip_lambda_required, apip_lambda_input, apip_lambda_const, apip_lambda_input_ta, apip_e_fast, apip_e_precise, apip_f_const_lambda, apip_f_dyn_lambda
+     - :ref:`APIP <PKG-APIP>`
+     - adaptive-precision interatomic potentials(APIP), see :doc:`APIP howto <Howto_apip>`
    * - *atomic*
      - tag, type, x, v, f, image, mask
      -

doc/src/bond_bpm_rotational.rst

@@ -215,6 +215,9 @@ for an overview of LAMMPS output options.
 The vector or array will be floating point values that correspond to
 the specified attribute.
 
+Any settings with the *store/local* option are not saved to a restart
+file and must be redefined.
+
 The single() function of this bond style returns 0.0 for the energy
 of a bonded interaction, since energy is not conserved in these
 dissipative potentials.  It also returns only the normal component of

doc/src/bond_bpm_spring.rst

@@ -215,6 +215,9 @@ for an overview of LAMMPS output options.
 The vector or array will be floating point values that correspond to
 the specified attribute.
 
+Any settings with the *store/local* option are not saved to a restart
+file and must be redefined.
+
 The potential energy and the single() function of this bond style return
 :math:`k (r - r_0)^2 / 2` as a proxy of the energy of a bonded interaction,
 ignoring any volumetric/smoothing factors or dissipative forces.  The single()

doc/src/compute_angle_local.rst

@@ -53,15 +53,17 @@ The value *eng* is the interaction energy for the angle.
 
 The value *v_name* can be used together with the *set* keyword to
 compute a user-specified function of the angle theta.  The *name*
-specified for the *v_name* value is the name of an :doc:`equal-style variable <variable>` which should evaluate a formula based on a
+specified for the *v_name* value is the name of an :doc:`equal-style
+variable <variable>` which should evaluate a formula based on a
 variable which will store the angle theta.  This other variable must
-be an :doc:`internal-style variable <variable>` defined in the input
-script; its initial numeric value can be anything.  It must be an
-internal-style variable, because this command resets its value
-directly.  The *set* keyword is used to identify the name of this
-other variable associated with theta.
+be an :doc:`internal-style variable <variable>` specified by the *set*
+keyword.  It is an internal-style variable, because this command
+resets its value directly.  The internal-style variable does not need
+to be defined in the input script (though it can be); if it is not
+defined, then the *set* option creates an :doc:`internal-style
+variable <variable>` with the specified name.
 
-Note that the value of theta for each angle which stored in the
+Note that the value of theta for each angle which is stored in the
 internal variable is in radians, not degrees.
 
 As an example, these commands can be added to the bench/in.rhodo
@@ -70,7 +72,6 @@ system and output the statistics in various ways:
 
 .. code-block:: LAMMPS
 
-   variable t internal 0.0
    variable cos equal cos(v_t)
    variable cossq equal cos(v_t)*cos(v_t)
 

doc/src/compute_bond_local.rst

@@ -64,20 +64,32 @@ All these properties are computed for the pair of atoms in a bond,
 whether the two atoms represent a simple diatomic molecule, or are part
 of some larger molecule.
 
-The value *dist* is the current length of the bond.
-The values *dx*, *dy*, and *dz* are the xyz components of the
-*distance* between the pair of atoms. This value is always the
-distance from the atom of lower to the one with the higher id.
+.. versionchanged:: 12Jun2025
+
+   The sign of *dx*, *dy*, *dz* is no longer determined by the atom IDs
+   of the bonded atoms but by their order in the bond list to be
+   consistent with *fx*, *fy*, and *fz*.
+
+The value *dist* is the current length of the bond.  The values *dx*,
+*dy*, and *dz* are the :math:`(x,y,z)` components of the distance vector
+:math:`\vec{x_i} - \vec{x_j}` between the atoms in the bond.  The order
+of the atoms is determined by the bond list and the respective atom-IDs
+can be output with :doc:`compute property/local
+<compute_property_local>`.
 
 The value *engpot* is the potential energy for the bond,
 based on the current separation of the pair of atoms in the bond.
 
-The value *force* is the magnitude of the force acting between the
-pair of atoms in the bond.
+The value *force* is the magnitude of the force acting between the pair
+of atoms in the bond, which is positive for a repulsive force and
+negative for an attractive force.
 
-The values *fx*, *fy*, and *fz* are the xyz components of
-*force* between the pair of atoms in the bond. For bond styles that apply
-non-central forces, such as :doc:`bond_style bpm/rotational
+The values *fx*, *fy*, and *fz* are the :math:`(x,y,z)` components of
+the force on the first atom *i* in the bond due to the second atom *j*.
+Mathematically, they are obtained by multiplying the value of *force*
+from above with a unit vector created from the *dx*, *dy*, and *dz*
+components of the distance vector also described above.  For bond styles
+that apply non-central forces, such as :doc:`bond_style bpm/rotational
 <bond_bpm_rotational>`, these values only include the :math:`(x,y,z)`
 components of the normal force component.
 
@@ -118,13 +130,15 @@ moving apart.
 
 The value *v_name* can be used together with the *set* keyword to
 compute a user-specified function of the bond distance.  The *name*
-specified for the *v_name* value is the name of an :doc:`equal-style variable <variable>` which should evaluate a formula based on a
-variable which will store the bond distance.  This other variable must
-be an :doc:`internal-style variable <variable>` defined in the input
-script; its initial numeric value can be anything.  It must be an
-internal-style variable, because this command resets its value
-directly.  The *set* keyword is used to identify the name of this
-other variable associated with theta.
+specified for the *v_name* value is the name of an :doc:`equal-style
+variable <variable>` which should evaluate a formula based on a
+variable which stores the bond distance.  This other variable must be
+the :doc:`internal-style variable <variable>` specified by the *set*
+keyword.  It is an internal-style variable, because this command
+resets its value directly.  The internal-style variable does not need
+to be defined in the input script (though it can be); if it is not
+defined, then the *set* option creates an :doc:`internal-style
+variable <variable>` with the specified name.
 
 As an example, these commands can be added to the bench/in.rhodo
 script to compute the length\ :math:`^2` of every bond in the system and
@@ -132,7 +146,6 @@ output the statistics in various ways:
 
 .. code-block:: LAMMPS
 
-   variable d internal 0.0
    variable dsq equal v_d*v_d
 
    compute 1 all property/local batom1 batom2 btype

doc/src/compute_dihedral_local.rst

@@ -45,30 +45,31 @@ interactions.  The number of datums generated, aggregated across all
 processors, equals the number of dihedral angles in the system, modified
 by the group parameter as explained below.
 
-The value *phi* (:math:`\phi`) is the dihedral angle, as defined in the diagram
-on the :doc:`dihedral_style <dihedral_style>` doc page.
+The value *phi* (:math:`\phi`) is the dihedral angle, as defined in
+the diagram on the :doc:`dihedral_style <dihedral_style>` doc page.
 
-The value *v_name* can be used together with the *set* keyword to compute a
-user-specified function of the dihedral angle :math:`\phi`.  The *name*
-specified for the *v_name* value is the name of an
-:doc:`equal-style variable <variable>` which should evaluate a formula based on
-a variable which will store the angle :math:`\phi`.  This other variable must
-be an :doc:`internal-style variable <variable>` defined in the input
-script; its initial numeric value can be anything.  It must be an
-internal-style variable, because this command resets its value
-directly.  The *set* keyword is used to identify the name of this
-other variable associated with :math:`\phi`.
+The value *v_name* can be used together with the *set* keyword to
+compute a user-specified function of the dihedral angle :math:`\phi`.
+The *name* specified for the *v_name* value is the name of an
+:doc:`equal-style variable <variable>` which should evaluate a formula
+based on a variable which will store the angle :math:`\phi`.  This
+other variable must be an :doc:`internal-style variable <variable>`
+specified by the *set* keyword.  It is an internal-style variable,
+because this command resets its value directly.  The internal-style
+variable does not need to be defined in the input script (though it
+can be); if it is not defined, then the *set* option creates an
+:doc:`internal-style variable <variable>` with the specified name.
 
-Note that the value of :math:`\phi` for each angle which stored in the internal
-variable is in radians, not degrees.
+Note that the value of :math:`\phi` for each angle which stored in the
+internal variable is in radians, not degrees.
 
 As an example, these commands can be added to the bench/in.rhodo
-script to compute the :math:`\cos\phi` and :math:`\cos^2\phi` of every dihedral
-angle in the system and output the statistics in various ways:
+script to compute the :math:`\cos\phi` and :math:`\cos^2\phi` of every
+dihedral angle in the system and output the statistics in various
+ways:
 
 .. code-block:: LAMMPS
 
-   variable p internal 0.0
    variable cos equal cos(v_p)
    variable cossq equal cos(v_p)*cos(v_p)
 
@@ -100,10 +101,10 @@ no consistent ordering of the entries within the local vector or array
 from one timestep to the next.  The only consistency that is
 guaranteed is that the ordering on a particular timestep will be the
 same for local vectors or arrays generated by other compute commands.
-For example, dihedral output from the
-:doc:`compute property/local <compute_property_local>` command can be combined
-with data from this command and output by the :doc:`dump local <dump>`
-command in a consistent way.
+For example, dihedral output from the :doc:`compute property/local
+<compute_property_local>` command can be combined with data from this
+command and output by the :doc:`dump local <dump>` command in a
+consistent way.
 
 Here is an example of how to do this:
 

doc/src/compute_msd.rst

@@ -49,8 +49,6 @@ proportional to the diffusion coefficient of the diffusing atoms.
 The displacement of an atom is from its reference position. This is
 normally the original position at the time
 the compute command was issued, unless the *average* keyword is set to *yes*\ .
-The value of the displacement will be
-0.0 for atoms not in the specified compute group.
 
 If the *com* option is set to *yes* then the effect of any drift in
 the center-of-mass of the group of atoms is subtracted out before the
@@ -111,7 +109,10 @@ distance\ :math:`^2` :doc:`units <units>`.
 Restrictions
 """"""""""""
 
-Compute *msd* cannot be used with a dynamic group.
+Compute *msd* cannot be used with a dynamic group and the number of
+atoms in the compute group must not be changed by some fixes like,
+for example, :doc:`fix deposit <fix_deposit>` or
+:doc:`fix evaporate <fix_evaporate>`.
 
 Related commands
 """"""""""""""""