Merge pull request #3978 from akohlmey/next_patch_release

Update version strings for 21 Nov 2023 feature release

.github/CODEOWNERS

@@ -61,6 +61,7 @@ src/GPU/pair_vashishta_gpu.*        @andeplane
 src/KOKKOS/pair_vashishta_kokkos.*  @andeplane
 src/MANYBODY/pair_vashishta_table.* @andeplane
 src/MANYBODY/pair_atm.*             @sergeylishchuk
+src/MANYBODY/pair_nb3b_screened.*   @flodesani
 src/REPLICA/*_grem.*                @dstelter92
 src/EXTRA-COMPUTE/compute_stress_mop*.* @RomainVermorel
 src/EXTRA-COMPUTE/compute_born_matrix.* @Bibobu @athomps
@@ -135,6 +136,7 @@ src/timer.*               @akohlmey
 src/utils.*               @akohlmey @rbberger
 src/verlet.*              @sjplimp @stanmoore1
 src/math_eigen_impl.h     @jewettaij
+src/fix_press_langevin.*  @Bibobu
 
 # tools
 tools/coding_standard/* @akohlmey @rbberger
@@ -151,12 +153,12 @@ tools/vim/*           @hammondkd
 unittest/*            @akohlmey
 
 # cmake
-cmake/*               @rbberger
+cmake/*               @akohlmey
 cmake/Modules/LAMMPSInterfacePlugin.cmake @akohlmey
 cmake/Modules/MPI4WIN.cmake @akohlmey
 cmake/Modules/OpenCLLoader.cmake @akohlmey
-cmake/Modules/Packages/COLVARS.cmake @rbberger @giacomofiorin
-cmake/Modules/Packages/KIM.cmake @rbberger @ellio167
+cmake/Modules/Packages/COLVARS.cmake @giacomofiorin
+cmake/Modules/Packages/KIM.cmake @ellio167
 cmake/presets/*.cmake @akohlmey
 
 # python

.github/CONTRIBUTING.md

@@ -5,9 +5,9 @@ Thank you for considering to contribute to the LAMMPS software project.
 The following is a set of guidelines as well as explanations of policies and work flows for contributing to the LAMMPS molecular dynamics software project. These guidelines focus on submitting issues or pull requests on the LAMMPS GitHub project.
 
 Thus please also have a look at:
-* [The guide for submitting new features in the LAMMPS manual](https://www.lammps.org/doc/Modify_contribute.html)
-* [The guide on programming style and requirement in the LAMMPS manual](https://www.lammps.org/doc/Modify_style.html)
-* [The GitHub tutorial in the LAMMPS manual](http://lammps.sandia.gov/doc/Howto_github.html)
+* [The guide for submitting new features in the LAMMPS manual](https://docs.lammps.org/Modify_contribute.html)
+* [The guide on programming style and requirement in the LAMMPS manual](https://docs.lammps.org/Modify_requirements.html)
+* [The GitHub tutorial in the LAMMPS manual](http://docs.lammps.org/Howto_github.html)
 
 ## Table of Contents
 
@@ -27,17 +27,17 @@ __
 
 ## I don't want to read this whole thing I just have a question!
 
-> **Note:** Please do not file an issue to ask a general question about LAMMPS, its features, how to use specific commands, or how perform simulations or analysis in LAMMPS. Instead post your question to either the ['lammps-users' mailing list](https://lammps.sandia.gov/mail.html) or the [LAMMPS Material Science Discourse forum](https://matsci.org/lammps). You do not need to be subscribed to post to the list (but a mailing list subscription avoids having your post delayed until it is approved by a mailing list moderator). Most posts to the mailing list receive a response within less than 24 hours. Before posting to the mailing list, please read the [mailing list guidelines](https://lammps.sandia.gov/guidelines.html). Following those guidelines will help greatly to get a helpful response. Always mention which LAMMPS version you are using. The LAMMPS forum was recently created as part of a larger effort to build a materials science community and have discussions not just about using LAMMPS. Thus the forum may be also used for discussions that would be off-topic for the mailing list. Those will just have to be posted to a more general category.
+> **Note:** Please do not file an issue to ask a general question about LAMMPS, its features, how to use specific commands, or how perform simulations or analysis in LAMMPS. Instead post your question to the [LAMMPS Material Science Discourse forum](https://matsci.org/lammps). Before posting to the forum, please read the general [guidelines](https://www.lammps.org/guidelines.html) and the forum specific [suggestions](https://matsci.org/t/please-read-this-first-guidelines-and-suggestions-for-posting-lammps-questions/49913). Following those guidelines and suggestions will help greatly to get a helpful response.  *Always* mention which LAMMPS version you are using. The MatSci website may be also used for discussions that would be off-topic for the LAMMPS categories. Those will just have to be posted to a different category.
 
 ## How Can I Contribute?
 
 There are several ways how you can actively contribute to the LAMMPS project: you can discuss compiling and using LAMMPS, and solving LAMMPS related problems with other LAMMPS users on the lammps-users mailing list or the forum, you can report bugs or suggest enhancements by creating issues on GitHub (or posting them to the lammps-users mailing list or posting in the LAMMPS Materials Science Discourse forum), and you can contribute by submitting pull requests on GitHub or e-mail your code
-to one of the [LAMMPS core developers](https://lammps.sandia.gov/authors.html). As you may see from the aforementioned developer page, the LAMMPS software package includes the efforts of a very large number of contributors beyond the principal authors and maintainers.
+to one of the [LAMMPS core developers](https://www.lammps.org/authors.html). As you may see from the aforementioned developer page, the LAMMPS software package includes the efforts of a very large number of contributors beyond the principal authors and maintainers.
 
 ### Discussing How To Use LAMMPS
 
 The LAMMPS mailing list is hosted at SourceForge. The mailing list began in 2005, and now includes tens of thousands of messages in thousands of threads. LAMMPS developers try to respond to posted questions in a timely manner, but there are no guarantees. Please consider that people live in different timezone and may not have time to answer e-mails outside of their work hours.
-You can post to list by sending your email to lammps-users at lists.sourceforge.net (no subscription required), but before posting, please read the [mailing list guidelines](https://lammps.sandia.gov/guidelines.html) to maximize your chances to receive a helpful response.
+You can post to list by sending your email to lammps-users at lists.sourceforge.net (no subscription required), but before posting, please read the [mailing list guidelines](https://www.lammps.org/guidelines.html) to maximize your chances to receive a helpful response.
 
 Anyone can browse/search previous questions/answers in the archives. You do not have to subscribe to the list to post questions, receive answers (to your questions), or browse/search the archives. You **do** need to subscribe to the list if you want emails for **all** the posts (as individual messages or in digest form), or to answer questions yourself. Feel free to sign up and help us out! Answering questions from fellow LAMMPS users is a great way to pay back the community for providing you a useful tool for free, and to pass on the advice you have received yourself to others. It improves your karma and helps you understand your own research better.
 
@@ -47,7 +47,7 @@ The LAMMPS Materials Science Discourse forum was created recently to facilitate
 
 ### Reporting Bugs
 
-While developers writing code for LAMMPS are careful to test their code, LAMMPS is such a large and complex software, that it is impossible to test for all combinations of features under all normal and not so normal circumstances. Thus bugs do happen, and if you suspect, that you have encountered one, please try to document it and report it as an [Issue](https://github.com/lammps/lammps/issues) on the LAMMPS GitHub project web page. However, before reporting a bug, you need to check whether this is something that may have already been corrected. The [Latest Features and Bug Fixes in LAMMPS](https://lammps.sandia.gov/bug.html) web page lists all significant changes to LAMMPS over the years. It also tells you what the current latest development version of LAMMPS is, and you should test whether your issue still applies to that version.
+While developers writing code for LAMMPS are careful to test their code, LAMMPS is such a large and complex software, that it is impossible to test for all combinations of features under all normal and not so normal circumstances. Thus bugs do happen, and if you suspect, that you have encountered one, please try to document it and report it as an [Issue](https://github.com/lammps/lammps/issues) on the LAMMPS GitHub project web page. However, before reporting a bug, you need to check whether this is something that may have already been corrected. The [Latest Features and Bug Fixes in LAMMPS](https://www.lammps.org/bug.html) web page lists all significant changes to LAMMPS over the years. It also tells you what the current latest development version of LAMMPS is, and you should test whether your issue still applies to that version.
 
 When you click on the green "New Issue" button, you will be provided with a text field, where you can enter your message. That text field with contain a template with several headlines and some descriptions. Keep the headlines that are relevant to your reported potential bug and replace the descriptions with the information as suggested by the descriptions.
 You can also attach small text files (please add the file name extension `.txt` or it will be rejected), images, or small compressed text files (using gzip, do not use RAR or 7-ZIP or similar tools that are uncommon outside of Windows machines). In many cases, bugs are best illustrated by providing a small input deck (do **not** attach your entire production input, but remove everything that is not required to reproduce the issue, and scale down your system size, that the resulting calculation runs fast and can be run on small desktop quickly).
@@ -65,9 +65,9 @@ To be able to submit an issue on GitHub, you have to register for an account (fo
 
 We encourage users to submit new features or modifications for LAMMPS. Instructions, guidelines, requirements,
 and recommendations are in the following sections of the LAMMPS manual:
-* [The guide for submitting new features in the LAMMPS manual](https://lammps.sandia.gov/doc/Modify_contribute.html)
-* [The guide on programming style and requirement in the LAMMPS manual](https://lammps.sandia.gov/doc/Modify_contribute.html)
-* [The GitHub tutorial in the LAMMPS manual](http://lammps.sandia.gov/doc/Howto_github.html)
+* [The guide for submitting new features in the LAMMPS manual](https://docs.lammps.org/Modify_contribute.html)
+* [The guide on programming style and requirement in the LAMMPS manual](https://docs.lammps.org/Modify_requirements.html)
+* [The GitHub tutorial in the LAMMPS manual](http://docs.lammps.org/Howto_github.html)
 
 
 ## GitHub Workflows
@@ -85,7 +85,7 @@ For bug reports, the next step is that one of the core LAMMPS developers will se
 ### Pull Requests
 
 Pull requests are the **only** way that changes get made to the LAMMPS distribution.  So also the LAMMPS core developers will submit pull requests for their own changes and discuss them on GitHub.  Thus if you submit a pull request it will be treated in a similar fashion. When you submit a pull request you may opt to submit a "Draft" pull request.  That means your changes are visible and will be subject to testing, but reviewers will not be (auto-)assigned and comments will take into account that this is not complete. On the other hand, this is a perfect way to ask the LAMMPS developers for comments on non-obvious changes and get feedback and possible suggestions for improvements or recommendations about what to avoid.
-Immediately after the submission, the LAMMPS continuing integration server at ci.lammps.org will download your submitted branch and perform a number of tests: it will tests whether it compiles cleanly under various conditions, it will also do a check on whether your included documentation translates cleanly and run some unit tests and other checks. Whether these tests are successful or fail will be recorded.  If a test fails, please inspect the corresponding output on the CI server and take the necessary steps, if needed, so that the code can compile cleanly again.  The test will be re-run each time the pull request is updated with a push to the remote branch on GitHub.  If you are unsure about what you need to change, ask a question in the discussion area of the pull request.
+Immediately after the submission, the LAMMPS continuing integration server at https://ci.lammps.org will download your submitted branch and perform a number of tests: it will tests whether it compiles cleanly under various conditions, it will also do a check on whether your included documentation translates cleanly and run some unit tests and other checks. Whether these tests are successful or fail will be recorded.  If a test fails, please inspect the corresponding output on the CI server and take the necessary steps, if needed, so that the code can compile cleanly again.  The test will be re-run each time the pull request is updated with a push to the remote branch on GitHub.  If you are unsure about what you need to change, ask a question in the discussion area of the pull request.
 Next a LAMMPS core developer will self-assign and do an overall technical assessment of the submission.  If you submitted a draft pull request, this will not happen unless you mark it "ready for review".  If you are not yet invited as a LAMMPS collaborator, and your contribution seems significant, you may also receive an invitation for collaboration on the LAMMPS repository.  As part of the assessment, the pull request will be categorized with labels. There are two special labels: `needs_work` (indicates that work from the submitter of the pull request is needed) and `work_in_progress` (indicates, that the assigned LAMMPS developer will make changes, if not done by the contributor who made the submit). 
 You may also receive comments and suggestions on the overall submission or specific details and on occasion specific requests for changes as part of the review. If permitted, also additional changes may be pushed into your pull request branch or a pull request may be filed in your LAMMPS fork on GitHub to include those changes.
 The LAMMPS developer may then decide to assign the pull request to another developer (e.g. when that developer is more knowledgeable about the submitted feature or enhancement or has written the modified code). It may also happen, that additional developers are requested to provide a review and approve the changes. For submissions, that may change the general behavior of LAMMPS, or where a possibility of unwanted side effects exists, additional tests may be requested by the assigned developer.

.github/workflows/codeql-analysis.yml

@@ -25,7 +25,7 @@ jobs:
 
     steps:
     - name: Checkout repository
-      uses: actions/checkout@v3
+      uses: actions/checkout@v4
       with:
         fetch-depth: 2
 

.github/workflows/compile-msvc.yml

@@ -19,7 +19,7 @@ jobs:
 
     steps:
     - name: Checkout repository
-      uses: actions/checkout@v3
+      uses: actions/checkout@v4
       with:
         fetch-depth: 2
 

.github/workflows/coverity.yml

@@ -16,7 +16,7 @@ jobs:
 
     steps:
     - name: Checkout repository
-      uses: actions/checkout@v3
+      uses: actions/checkout@v4
       with:
         fetch-depth: 2
 

.github/workflows/unittest-macos.yml

@@ -21,7 +21,7 @@ jobs:
 
     steps:
     - name: Checkout repository
-      uses: actions/checkout@v3
+      uses: actions/checkout@v4
       with:
         fetch-depth: 2
 

cmake/CMakeLists.txt

@@ -2,8 +2,7 @@
 ########################################
 # CMake build system
 # This file is part of LAMMPS
-# Created by Christoph Junghans and Richard Berger
-cmake_minimum_required(VERSION 3.10)
+cmake_minimum_required(VERSION 3.16)
 ########################################
 # set policy to silence warnings about ignoring <PackageName>_ROOT but use it
 if(POLICY CMP0074)
@@ -17,13 +16,7 @@ endif()
 if(POLICY CMP0135)
   cmake_policy(SET CMP0135 OLD)
 endif()
-########################################
-# Use CONFIGURE_DEPENDS as option for file(GLOB...) when available
-if(CMAKE_VERSION VERSION_LESS 3.12)
-  unset(CONFIGURE_DEPENDS)
-else()
-  set(CONFIGURE_DEPENDS CONFIGURE_DEPENDS)
-endif()
+
 ########################################
 
 project(lammps CXX)
@@ -112,7 +105,7 @@ if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
     if(CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.3 OR CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.4)
       set(CMAKE_TUNE_DEFAULT "-xCOMMON-AVX512")
     else()
-      set(CMAKE_TUNE_DEFAULT "-xHost -fp-model fast=2 -no-prec-div -qoverride-limits -diag-disable=10441 -diag-disable=2196")
+      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")
     endif()
   endif()
 endif()
@@ -132,15 +125,15 @@ if((PKG_KOKKOS) AND (Kokkos_ENABLE_CUDA) AND NOT (CMAKE_CXX_COMPILER_ID STREQUAL
   set(CMAKE_TUNE_DEFAULT "${CMAKE_TUNE_DEFAULT} -Xcudafe --diag_suppress=unrecognized_pragma")
 endif()
 
-# we require C++11 without extensions. Kokkos requires at least C++14 (currently)
+# we require C++11 without extensions. Kokkos requires at least C++17 (currently)
 if(NOT CMAKE_CXX_STANDARD)
   set(CMAKE_CXX_STANDARD 11)
 endif()
 if(CMAKE_CXX_STANDARD LESS 11)
   message(FATAL_ERROR "C++ standard must be set to at least 11")
 endif()
-if(PKG_KOKKOS AND (CMAKE_CXX_STANDARD LESS 14))
-  set(CMAKE_CXX_STANDARD 14)
+if(PKG_KOKKOS AND (CMAKE_CXX_STANDARD LESS 17))
+  set(CMAKE_CXX_STANDARD 17)
 endif()
 set(CMAKE_CXX_STANDARD_REQUIRED ON)
 set(CMAKE_CXX_EXTENSIONS OFF CACHE BOOL "Use compiler extensions")
@@ -151,6 +144,7 @@ if(MSVC)
     add_compile_options(/Zc:__cplusplus)
     add_compile_options(/wd4244)
     add_compile_options(/wd4267)
+    add_compile_options(/wd4250)
     add_compile_options(/EHsc)
   endif()
   add_compile_definitions(_CRT_SECURE_NO_WARNINGS)
@@ -164,17 +158,20 @@ endif()
 ########################################################################
 # User input options                                                   #
 ########################################################################
-# set path to python interpreter and thus enforcing python version when
-# in a virtual environment and PYTHON_EXECUTABLE is not set on command line
-if(DEFINED ENV{VIRTUAL_ENV} AND NOT PYTHON_EXECUTABLE)
-  if(CMAKE_HOST_SYSTEM_NAME STREQUAL "Windows")
-    set(PYTHON_EXECUTABLE "$ENV{VIRTUAL_ENV}/Scripts/python.exe")
-  else()
-    set(PYTHON_EXECUTABLE "$ENV{VIRTUAL_ENV}/bin/python")
-  endif()
+# backward compatibility with CMake before 3.12 and older LAMMPS documentation
+if (PYTHON_EXECUTABLE)
   set(Python_EXECUTABLE "${PYTHON_EXECUTABLE}")
+endif()
+# set path to python interpreter and thus enforcing python version when
+# in a virtual environment and Python_EXECUTABLE is not set on command line
+if(DEFINED ENV{VIRTUAL_ENV} AND NOT Python_EXECUTABLE)
+  if(CMAKE_HOST_SYSTEM_NAME STREQUAL "Windows")
+    set(Python_EXECUTABLE "$ENV{VIRTUAL_ENV}/Scripts/python.exe")
+  else()
+    set(Python_EXECUTABLE "$ENV{VIRTUAL_ENV}/bin/python")
+  endif()
   message(STATUS "Running in virtual environment: $ENV{VIRTUAL_ENV}\n"
-    "   Setting Python interpreter to: ${PYTHON_EXECUTABLE}")
+    "   Setting Python interpreter to: ${Python_EXECUTABLE}")
 endif()
 
 set(LAMMPS_MACHINE "" CACHE STRING "Suffix to append to lmp binary (WON'T enable any features automatically")
@@ -199,8 +196,8 @@ else()
 endif()
 
 include(GNUInstallDirs)
-file(GLOB ALL_SOURCES ${CONFIGURE_DEPENDS} ${LAMMPS_SOURCE_DIR}/[^.]*.cpp)
-file(GLOB MAIN_SOURCES ${CONFIGURE_DEPENDS} ${LAMMPS_SOURCE_DIR}/main.cpp)
+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})
 add_library(lammps ${ALL_SOURCES})
 
@@ -274,8 +271,6 @@ set(STANDARD_PACKAGES
   MOFFF
   MOLECULE
   MOLFILE
-  MPIIO
-  MSCG
   NETCDF
   ORIENT
   PERI
@@ -381,15 +376,9 @@ if(NOT ${LAMMPS_MEMALIGN} STREQUAL "0")
   target_compile_definitions(lammps PRIVATE -DLAMMPS_MEMALIGN=${LAMMPS_MEMALIGN})
 endif()
 
-option(LAMMPS_EXCEPTIONS "enable the use of C++ exceptions for error messages (useful for library interface)" ${ENABLE_TESTING})
-if(LAMMPS_EXCEPTIONS)
-  target_compile_definitions(lammps PUBLIC -DLAMMPS_EXCEPTIONS)
-endif()
-
 # "hard" dependencies between packages resulting
 # in an error instead of skipping over files
 pkg_depends(ML-IAP ML-SNAP)
-pkg_depends(MPIIO MPI)
 pkg_depends(ATC MANYBODY)
 pkg_depends(LATBOLTZ MPI)
 pkg_depends(SCAFACOS MPI)
@@ -438,14 +427,26 @@ if(BUILD_OMP)
   target_link_libraries(lmp PRIVATE OpenMP::OpenMP_CXX)
 endif()
 
-if(PKG_MSCG OR PKG_ATC OR PKG_AWPMD OR PKG_ML-QUIP OR PKG_ML-POD OR PKG_ELECTRODE OR BUILD_TOOLS)
+# lower C++ standard for fmtlib sources when using Intel classic compiler
+if((CMAKE_CXX_COMPILER_ID STREQUAL "Intel") AND (CMAKE_CXX_STANDARD GREATER_EQUAL 17)
+    AND (CMAKE_CXX_COMPILER_VERSION VERSION_LESS 2021.10))
+  message(STATUS "Lowering C++ standard for compiling fmtlib sources with Intel Classic compiler")
+  get_filename_component(LMP_UTILS_SRC "${LAMMPS_SOURCE_DIR}/utils.cpp" ABSOLUTE)
+  get_filename_component(LMP_VARIABLE_SRC "${LAMMPS_SOURCE_DIR}/variable.cpp" ABSOLUTE)
+  get_filename_component(FMT_FORMAT_SRC "${LAMMPS_SOURCE_DIR}/fmtlib_format.cpp" ABSOLUTE)
+  get_filename_component(FMT_OS_SRC "${LAMMPS_SOURCE_DIR}/fmtlib_os.cpp" ABSOLUTE)
+  set_source_files_properties("${FMT_FORMAT_SRC}" "${FMT_OS_SRC}" "${LMP_VARIABLE_SRC}" "${LMP_UTILS_SRC}"
+          PROPERTIES COMPILE_OPTIONS "-std=c++14")
+endif()
+
+if(PKG_ATC OR PKG_AWPMD OR PKG_ML-QUIP OR PKG_ML-POD OR PKG_ELECTRODE OR BUILD_TOOLS)
   enable_language(C)
   if (NOT USE_INTERNAL_LINALG)
     find_package(LAPACK)
     find_package(BLAS)
   endif()
   if(NOT LAPACK_FOUND OR NOT BLAS_FOUND OR USE_INTERNAL_LINALG)
-    file(GLOB LINALG_SOURCES ${CONFIGURE_DEPENDS} ${LAMMPS_LIB_SOURCE_DIR}/linalg/[^.]*.cpp)
+    file(GLOB LINALG_SOURCES CONFIGURE_DEPENDS ${LAMMPS_LIB_SOURCE_DIR}/linalg/[^.]*.cpp)
     add_library(linalg STATIC ${LINALG_SOURCES})
     set_target_properties(linalg PROPERTIES OUTPUT_NAME lammps_linalg${LAMMPS_MACHINE})
     set(BLAS_LIBRARIES "$<TARGET_FILE:linalg>")
@@ -463,12 +464,7 @@ option(WITH_JPEG "Enable JPEG support" ${JPEG_FOUND})
 if(WITH_JPEG)
   find_package(JPEG REQUIRED)
   target_compile_definitions(lammps PRIVATE -DLAMMPS_JPEG)
-  if(CMAKE_VERSION VERSION_LESS 3.12)
-    target_include_directories(lammps PRIVATE ${JPEG_INCLUDE_DIRS})
-    target_link_libraries(lammps PRIVATE ${JPEG_LIBRARIES})
-  else()
   target_link_libraries(lammps PRIVATE JPEG::JPEG)
-  endif()
 endif()
 
 find_package(PNG QUIET)
@@ -518,7 +514,7 @@ else()
 endif()
 
 foreach(PKG_WITH_INCL KSPACE PYTHON ML-IAP VORONOI COLVARS ML-HDNNP MDI MOLFILE NETCDF
-        PLUMED QMMM ML-QUIP SCAFACOS MACHDYN VTK KIM MSCG COMPRESS ML-PACE LEPTON)
+        PLUMED QMMM ML-QUIP SCAFACOS MACHDYN VTK KIM COMPRESS ML-PACE LEPTON)
   if(PKG_${PKG_WITH_INCL})
     include(Packages/${PKG_WITH_INCL})
   endif()
@@ -580,8 +576,8 @@ endforeach()
 foreach(PKG ${STANDARD_PACKAGES})
   set(${PKG}_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/${PKG})
 
-  file(GLOB ${PKG}_SOURCES ${CONFIGURE_DEPENDS} ${${PKG}_SOURCES_DIR}/[^.]*.cpp)
-  file(GLOB ${PKG}_HEADERS ${CONFIGURE_DEPENDS} ${${PKG}_SOURCES_DIR}/[^.]*.h)
+  file(GLOB ${PKG}_SOURCES CONFIGURE_DEPENDS ${${PKG}_SOURCES_DIR}/[^.]*.cpp)
+  file(GLOB ${PKG}_HEADERS CONFIGURE_DEPENDS ${${PKG}_SOURCES_DIR}/[^.]*.h)
 
   # check for package files in src directory due to old make system
   DetectBuildSystemConflict(${LAMMPS_SOURCE_DIR} ${${PKG}_SOURCES} ${${PKG}_HEADERS})
@@ -597,19 +593,12 @@ foreach(PKG ${STANDARD_PACKAGES})
   RegisterPackages(${${PKG}_SOURCES_DIR})
 endforeach()
 
-# packages that need defines set
-foreach(PKG MPIIO)
-  if(PKG_${PKG})
-    target_compile_definitions(lammps PRIVATE -DLMP_${PKG})
-  endif()
-endforeach()
-
 # dedicated check for entire contents of accelerator packages
 foreach(PKG ${SUFFIX_PACKAGES})
   set(${PKG}_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/${PKG})
 
-  file(GLOB ${PKG}_SOURCES ${CONFIGURE_DEPENDS} ${${PKG}_SOURCES_DIR}/[^.]*.cpp)
-  file(GLOB ${PKG}_HEADERS ${CONFIGURE_DEPENDS} ${${PKG}_SOURCES_DIR}/[^.]*.h)
+  file(GLOB ${PKG}_SOURCES CONFIGURE_DEPENDS ${${PKG}_SOURCES_DIR}/[^.]*.cpp)
+  file(GLOB ${PKG}_HEADERS CONFIGURE_DEPENDS ${${PKG}_SOURCES_DIR}/[^.]*.h)
 
   # check for package files in src directory due to old make system
   DetectBuildSystemConflict(${LAMMPS_SOURCE_DIR} ${${PKG}_SOURCES} ${${PKG}_HEADERS})
@@ -623,7 +612,7 @@ endforeach()
 foreach(PKG_LIB POEMS ATC AWPMD H5MD)
   if(PKG_${PKG_LIB})
     string(TOLOWER "${PKG_LIB}" PKG_LIB)
-    file(GLOB_RECURSE ${PKG_LIB}_SOURCES ${CONFIGURE_DEPENDS}
+    file(GLOB_RECURSE ${PKG_LIB}_SOURCES CONFIGURE_DEPENDS
       ${LAMMPS_LIB_SOURCE_DIR}/${PKG_LIB}/[^.]*.c ${LAMMPS_LIB_SOURCE_DIR}/${PKG_LIB}/[^.]*.cpp)
     add_library(${PKG_LIB} STATIC ${${PKG_LIB}_SOURCES})
     set_target_properties(${PKG_LIB} PROPERTIES OUTPUT_NAME lammps_${PKG_LIB}${LAMMPS_MACHINE})
@@ -818,20 +807,8 @@ install(
 # This is primarily for people that only want to use the Python wrapper.
 ###############################################################################
 if(BUILD_SHARED_LIBS)
-  if(CMAKE_VERSION VERSION_LESS 3.12)
-    # adjust so we find Python 3 versions before Python 2 on old systems with old CMake
-    set(Python_ADDITIONAL_VERSIONS 3.12 3.11 3.10 3.9 3.8 3.7 3.6)
-    find_package(PythonInterp) # Deprecated since version 3.12
-    if(PYTHONINTERP_FOUND)
-      set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
-    endif()
-  else()
   # backward compatibility
-    if(PYTHON_EXECUTABLE)
-      set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
-    endif()
   find_package(Python COMPONENTS Interpreter)
-  endif()
   if(BUILD_IS_MULTI_CONFIG)
     set(MY_BUILD_DIR ${CMAKE_BINARY_DIR}/$<CONFIG>)
   else()
@@ -950,11 +927,9 @@ if(_index GREATER -1)
 endif()
 message(STATUS "<<< Linker flags: >>>")
 message(STATUS "Executable name:  ${LAMMPS_BINARY}")
-if(CMAKE_VERSION VERSION_GREATER_EQUAL 3.13)
-  get_target_property(OPTIONS lammps LINK_OPTIONS)
-  if(OPTIONS)
+get_target_property(OPTIONS lammps LINK_OPTIONS)
+if(OPTIONS)
   message(STATUS "Linker options:   ${OPTIONS}")
-  endif()
 endif()
 if(CMAKE_EXE_LINKER_FLAGS)
   message(STATUS "Executable linker flags: ${CMAKE_EXE_LINKER_FLAGS}")

cmake/Modules/CodingStandard.cmake

@@ -1,19 +1,11 @@
-if(CMAKE_VERSION VERSION_LESS 3.12)
-    find_package(PythonInterp 3.5 QUIET) # Deprecated since version 3.12
-    if(PYTHONINTERP_FOUND)
-        set(Python3_EXECUTABLE ${PYTHON_EXECUTABLE})
-        set(Python3_VERSION ${PYTHON_VERSION_STRING})
-    endif()
-else()
-    # use default (or custom) Python executable, if version is sufficient
-    if(Python_VERSION VERSION_GREATER_EQUAL 3.5)
+# use default (or custom) Python executable, if version is sufficient
+if(Python_VERSION VERSION_GREATER_EQUAL 3.6)
   set(Python3_EXECUTABLE ${Python_EXECUTABLE})
-    endif()
-    find_package(Python3 COMPONENTS Interpreter QUIET)
 endif()
+find_package(Python3 COMPONENTS Interpreter)
 
 if(Python3_EXECUTABLE)
-    if(Python3_VERSION VERSION_GREATER_EQUAL 3.5)
+    if(Python3_VERSION VERSION_GREATER_EQUAL 3.6)
         add_custom_target(
           check-whitespace
           ${Python3_EXECUTABLE} ${LAMMPS_TOOLS_DIR}/coding_standard/whitespace.py .

cmake/Modules/Documentation.cmake

@@ -5,10 +5,6 @@ option(BUILD_DOC "Build LAMMPS HTML documentation" OFF)
 
 if(BUILD_DOC)
   # Current Sphinx versions require at least Python 3.8
-  if(CMAKE_VERSION VERSION_LESS 3.12)
-    find_package(PythonInterp 3.8 REQUIRED)
-    set(VIRTUALENV ${PYTHON_EXECUTABLE} -m venv)
-  else()
   # use default (or custom) Python executable, if version is sufficient
   if(Python_VERSION VERSION_GREATER_EQUAL 3.8)
     set(Python3_EXECUTABLE ${Python_EXECUTABLE})
@@ -18,11 +14,9 @@ if(BUILD_DOC)
     message(FATAL_ERROR "Python 3.8 and up is required to build the HTML documentation")
   endif()
   set(VIRTUALENV ${Python3_EXECUTABLE} -m venv)
-  endif()
+
   find_package(Doxygen 1.8.10 REQUIRED)
-
-  file(GLOB DOC_SOURCES ${CONFIGURE_DEPENDS} ${LAMMPS_DOC_DIR}/src/[^.]*.rst)
-
+  file(GLOB DOC_SOURCES CONFIGURE_DEPENDS ${LAMMPS_DOC_DIR}/src/[^.]*.rst)
 
   add_custom_command(
     OUTPUT docenv
@@ -80,7 +74,7 @@ if(BUILD_DOC)
       message(STATUS "Using already downloaded archive ${CMAKE_BINARY_DIR}/libpace.tar.gz")
     endif()
     execute_process(COMMAND ${CMAKE_COMMAND} -E tar xzf mathjax.tar.gz WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR})
-    file(GLOB MATHJAX_VERSION_DIR ${CONFIGURE_DEPENDS} ${CMAKE_CURRENT_BINARY_DIR}/MathJax-*)
+    file(GLOB MATHJAX_VERSION_DIR CONFIGURE_DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/MathJax-*)
     execute_process(COMMAND ${CMAKE_COMMAND} -E rename ${MATHJAX_VERSION_DIR} ${DOC_BUILD_STATIC_DIR}/mathjax)
   endif()
 

cmake/Modules/FindCythonize.cmake

@@ -7,15 +7,7 @@
 # adapted from https://github.com/cmarshall108/cython-cmake-example/blob/master/cmake/FindCython.cmake
 #=============================================================================
 
-if(CMAKE_VERSION VERSION_LESS 3.12)
-    set(Python_ADDITIONAL_VERSIONS 3.12 3.11 3.10 3.9 3.8 3.7 3.6)
-    find_package(PythonInterp 3.6 QUIET) # Deprecated since version 3.12
-    if(PYTHONINTERP_FOUND)
-        set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
-    endif()
-else()
-    find_package(Python 3.6 COMPONENTS Interpreter QUIET)
-endif()
+find_package(Python 3.6 COMPONENTS Interpreter QUIET)
 
 # Use the Cython executable that lives next to the Python executable
 # if it is a local installation.

cmake/Modules/LAMMPSInterfacePlugin.cmake

@@ -28,10 +28,9 @@ if(MSVC)
     add_compile_options(/Zc:__cplusplus)
     add_compile_options(/wd4244)
     add_compile_options(/wd4267)
-    if(LAMMPS_EXCEPTIONS)
+    add_compile_options(/wd4250)
     add_compile_options(/EHsc)
   endif()
-  endif()
   add_compile_definitions(_CRT_SECURE_NO_WARNINGS)
 endif()
 
@@ -65,7 +64,7 @@ endfunction(validate_option)
 
 # helper function for getting the most recently modified file or folder from a glob pattern
 function(get_newest_file path variable)
-  file(GLOB _dirs ${CONFIGURE_DEPENDS} ${path})
+  file(GLOB _dirs CONFIGURE_DEPENDS ${path})
   set(_besttime 2000-01-01T00:00:00)
   set(_bestfile "<unknown>")
   foreach(_dir ${_dirs})

cmake/Modules/LAMMPSUtils.cmake

@@ -41,7 +41,7 @@ endfunction()
 
 # helper function for getting the most recently modified file or folder from a glob pattern
 function(get_newest_file path variable)
-  file(GLOB _dirs ${CONFIGURE_DEPENDS} ${path})
+  file(GLOB _dirs CONFIGURE_DEPENDS ${path})
   set(_besttime 2000-01-01T00:00:00)
   set(_bestfile "<unknown>")
   foreach(_dir ${_dirs})
@@ -80,15 +80,15 @@ endfunction()
 
 function(check_for_autogen_files source_dir)
     message(STATUS "Running check for auto-generated files from make-based build system")
-    file(GLOB SRC_AUTOGEN_FILES ${CONFIGURE_DEPENDS} ${source_dir}/style_*.h)
-    file(GLOB SRC_AUTOGEN_PACKAGES ${CONFIGURE_DEPENDS} ${source_dir}/packages_*.h)
+    file(GLOB SRC_AUTOGEN_FILES CONFIGURE_DEPENDS ${source_dir}/style_*.h)
+    file(GLOB SRC_AUTOGEN_PACKAGES CONFIGURE_DEPENDS ${source_dir}/packages_*.h)
     list(APPEND SRC_AUTOGEN_FILES ${SRC_AUTOGEN_PACKAGES} ${source_dir}/lmpinstalledpkgs.h ${source_dir}/lmpgitversion.h)
-    list(APPEND SRC_AUTOGEN_FILES ${SRC_AUTOGEN_PACKAGES} ${source_dir}/mliap_model_python_couple.h ${source_dir}/mliap_model_python_couple.cpp)
+    list(APPEND SRC_AUTOGEN_FILES ${source_dir}/mliap_model_python_couple.h ${source_dir}/mliap_model_python_couple.cpp)
     foreach(_SRC ${SRC_AUTOGEN_FILES})
       get_filename_component(FILENAME "${_SRC}" NAME)
       if(EXISTS ${source_dir}/${FILENAME})
         message(FATAL_ERROR "\n########################################################################\n"
-                              "Found header file(s) generated by the make-based build system\n"
+                            "Found header file ${source_dir}/${FILENAME} generated by the make-based build system\n"
                             "\n"
                             "Please run\n"
                             "make -C ${source_dir} purge\n"

cmake/Modules/Packages/COLVARS.cmake

@@ -1,6 +1,6 @@
 set(COLVARS_SOURCE_DIR ${LAMMPS_LIB_SOURCE_DIR}/colvars)
 
-file(GLOB COLVARS_SOURCES ${CONFIGURE_DEPENDS} ${COLVARS_SOURCE_DIR}/[^.]*.cpp)
+file(GLOB COLVARS_SOURCES CONFIGURE_DEPENDS ${COLVARS_SOURCE_DIR}/[^.]*.cpp)
 
 option(COLVARS_DEBUG "Enable debugging messages for Colvars (quite verbose)" OFF)
 

cmake/Modules/Packages/GPU.cmake

@@ -39,7 +39,7 @@ if (PKG_AMOEBA)
               ${GPU_SOURCES_DIR}/amoeba_convolution_gpu.cpp)
 endif()
 
-file(GLOB GPU_LIB_SOURCES ${CONFIGURE_DEPENDS} ${LAMMPS_LIB_SOURCE_DIR}/gpu/[^.]*.cpp)
+file(GLOB GPU_LIB_SOURCES CONFIGURE_DEPENDS ${LAMMPS_LIB_SOURCE_DIR}/gpu/[^.]*.cpp)
 file(MAKE_DIRECTORY ${LAMMPS_LIB_BINARY_DIR}/gpu)
 
 if(GPU_API STREQUAL "CUDA")
@@ -70,7 +70,7 @@ if(GPU_API STREQUAL "CUDA")
   set(GPU_ARCH "sm_50" CACHE STRING "LAMMPS GPU CUDA SM primary architecture (e.g. sm_60)")
 
   # ensure that no *cubin.h files exist from a compile in the lib/gpu folder
-  file(GLOB GPU_LIB_OLD_CUBIN_HEADERS ${CONFIGURE_DEPENDS} ${LAMMPS_LIB_SOURCE_DIR}/gpu/*_cubin.h)
+  file(GLOB GPU_LIB_OLD_CUBIN_HEADERS CONFIGURE_DEPENDS ${LAMMPS_LIB_SOURCE_DIR}/gpu/*_cubin.h)
   if(GPU_LIB_OLD_CUBIN_HEADERS)
     message(FATAL_ERROR "########################################################################\n"
       "Found file(s) generated by the make-based build system in lib/gpu\n"
@@ -80,15 +80,15 @@ if(GPU_API STREQUAL "CUDA")
       "########################################################################")
   endif()
 
-  file(GLOB GPU_LIB_CU ${CONFIGURE_DEPENDS} ${LAMMPS_LIB_SOURCE_DIR}/gpu/[^.]*.cu ${CMAKE_CURRENT_SOURCE_DIR}/gpu/[^.]*.cu)
+  file(GLOB GPU_LIB_CU CONFIGURE_DEPENDS ${LAMMPS_LIB_SOURCE_DIR}/gpu/[^.]*.cu ${CMAKE_CURRENT_SOURCE_DIR}/gpu/[^.]*.cu)
   list(REMOVE_ITEM GPU_LIB_CU ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_pppm.cu)
 
   cuda_include_directories(${LAMMPS_LIB_SOURCE_DIR}/gpu ${LAMMPS_LIB_BINARY_DIR}/gpu)
 
   if(CUDPP_OPT)
     cuda_include_directories(${LAMMPS_LIB_SOURCE_DIR}/gpu/cudpp_mini)
-    file(GLOB GPU_LIB_CUDPP_SOURCES ${CONFIGURE_DEPENDS} ${LAMMPS_LIB_SOURCE_DIR}/gpu/cudpp_mini/[^.]*.cpp)
-    file(GLOB GPU_LIB_CUDPP_CU ${CONFIGURE_DEPENDS} ${LAMMPS_LIB_SOURCE_DIR}/gpu/cudpp_mini/[^.]*.cu)
+    file(GLOB GPU_LIB_CUDPP_SOURCES CONFIGURE_DEPENDS ${LAMMPS_LIB_SOURCE_DIR}/gpu/cudpp_mini/[^.]*.cpp)
+    file(GLOB GPU_LIB_CUDPP_CU CONFIGURE_DEPENDS ${LAMMPS_LIB_SOURCE_DIR}/gpu/cudpp_mini/[^.]*.cu)
   endif()
 
   # build arch/gencode commands for nvcc based on CUDA toolkit version and use choice
@@ -205,7 +205,7 @@ elseif(GPU_API STREQUAL "OPENCL")
   include(OpenCLUtils)
   set(OCL_COMMON_HEADERS ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_preprocessor.h ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_aux_fun1.h)
 
-  file(GLOB GPU_LIB_CU ${CONFIGURE_DEPENDS} ${LAMMPS_LIB_SOURCE_DIR}/gpu/[^.]*.cu)
+  file(GLOB GPU_LIB_CU CONFIGURE_DEPENDS ${LAMMPS_LIB_SOURCE_DIR}/gpu/[^.]*.cu)
   list(REMOVE_ITEM GPU_LIB_CU
     ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_gayberne.cu
     ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_gayberne_lj.cu
@@ -335,7 +335,7 @@ elseif(GPU_API STREQUAL "HIP")
     endif()
   endif()
 
-  file(GLOB GPU_LIB_CU ${CONFIGURE_DEPENDS} ${LAMMPS_LIB_SOURCE_DIR}/gpu/[^.]*.cu ${CMAKE_CURRENT_SOURCE_DIR}/gpu/[^.]*.cu)
+  file(GLOB GPU_LIB_CU CONFIGURE_DEPENDS ${LAMMPS_LIB_SOURCE_DIR}/gpu/[^.]*.cu ${CMAKE_CURRENT_SOURCE_DIR}/gpu/[^.]*.cu)
   list(REMOVE_ITEM GPU_LIB_CU ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_pppm.cu)
 
   set(GPU_LIB_CU_HIP "")

cmake/Modules/Packages/KIM.cmake

@@ -1,12 +1,7 @@
 set(KIM-API_MIN_VERSION 2.1.3)
 find_package(CURL)
 if(CURL_FOUND)
-  if(CMAKE_VERSION VERSION_LESS 3.12)
-    target_include_directories(lammps PRIVATE ${CURL_INCLUDE_DIRS})
-    target_link_libraries(lammps PRIVATE ${CURL_LIBRARIES})
-  else()
   target_link_libraries(lammps PRIVATE CURL::libcurl)
-  endif()
   target_compile_definitions(lammps PRIVATE -DLMP_KIM_CURL)
   set(LMP_DEBUG_CURL OFF CACHE STRING "Set libcurl verbose mode on/off. If on, it displays a lot of verbose information about its operations.")
   mark_as_advanced(LMP_DEBUG_CURL)

cmake/Modules/Packages/KOKKOS.cmake

@@ -1,7 +1,8 @@
 ########################################################################
-# As of version 3.3.0 Kokkos requires C++14
-if(CMAKE_CXX_STANDARD LESS 14)
-  message(FATAL_ERROR "The KOKKOS package requires the C++ standard to be set to at least C++14")
+# As of version 4.0.0 Kokkos requires C++17
+if(CMAKE_CXX_STANDARD LESS 17)
+  message(FATAL_ERROR "The KOKKOS package requires the C++ standard to
+be set to at least C++17")
 endif()
 
 ########################################################################
@@ -49,8 +50,8 @@ if(DOWNLOAD_KOKKOS)
   list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_CXX_EXTENSIONS=${CMAKE_CXX_EXTENSIONS}")
   list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}")
   include(ExternalProject)
-  set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/3.7.02.tar.gz" CACHE STRING "URL for KOKKOS tarball")
-  set(KOKKOS_MD5 "34d7860d548c06a4040236d959c9f99a" CACHE STRING "MD5 checksum of KOKKOS tarball")
+  set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/4.1.00.tar.gz" CACHE STRING "URL for KOKKOS tarball")
+  set(KOKKOS_MD5 "a5f096bd8ad01b97fdc7a32583b17a33" CACHE STRING "MD5 checksum of KOKKOS tarball")
   mark_as_advanced(KOKKOS_URL)
   mark_as_advanced(KOKKOS_MD5)
   GetFallbackURL(KOKKOS_URL KOKKOS_FALLBACK)
@@ -75,7 +76,7 @@ if(DOWNLOAD_KOKKOS)
   add_dependencies(LAMMPS::KOKKOSCORE kokkos_build)
   add_dependencies(LAMMPS::KOKKOSCONTAINERS kokkos_build)
 elseif(EXTERNAL_KOKKOS)
-  find_package(Kokkos 3.7.02 REQUIRED CONFIG)
+  find_package(Kokkos 4.1.00 REQUIRED CONFIG)
   target_link_libraries(lammps PRIVATE Kokkos::kokkos)
 else()
   set(LAMMPS_LIB_KOKKOS_SRC_DIR ${LAMMPS_LIB_SOURCE_DIR}/kokkos)
@@ -155,7 +156,7 @@ if(PKG_ML-IAP)
 
   # Add KOKKOS version of ML-IAP Python coupling if non-KOKKOS version is included
   if(MLIAP_ENABLE_PYTHON AND Cythonize_EXECUTABLE)
-    file(GLOB MLIAP_KOKKOS_CYTHON_SRC ${CONFIGURE_DEPENDS} ${LAMMPS_SOURCE_DIR}/KOKKOS/*.pyx)
+    file(GLOB MLIAP_KOKKOS_CYTHON_SRC CONFIGURE_DEPENDS ${LAMMPS_SOURCE_DIR}/KOKKOS/*.pyx)
     foreach(MLIAP_CYTHON_FILE ${MLIAP_KOKKOS_CYTHON_SRC})
       get_filename_component(MLIAP_CYTHON_BASE ${MLIAP_CYTHON_FILE} NAME_WE)
       add_custom_command(OUTPUT  ${MLIAP_BINARY_DIR}/${MLIAP_CYTHON_BASE}.cpp ${MLIAP_BINARY_DIR}/${MLIAP_CYTHON_BASE}.h

cmake/Modules/Packages/LEPTON.cmake

@@ -4,7 +4,7 @@ if(LEPTON_SOURCE_DIR)
 endif()
 set(LEPTON_SOURCE_DIR ${LAMMPS_LIB_SOURCE_DIR}/lepton)
 
-file(GLOB LEPTON_SOURCES ${CONFIGURE_DEPENDS} ${LEPTON_SOURCE_DIR}/src/[^.]*.cpp)
+file(GLOB LEPTON_SOURCES CONFIGURE_DEPENDS ${LEPTON_SOURCE_DIR}/src/[^.]*.cpp)
 
 if((CMAKE_HOST_SYSTEM_PROCESSOR STREQUAL "amd64") OR
    (CMAKE_HOST_SYSTEM_PROCESSOR STREQUAL "AMD64") OR
@@ -15,7 +15,7 @@ else()
 endif()
 
 if(LEPTON_ENABLE_JIT)
-  file(GLOB ASMJIT_SOURCES ${CONFIGURE_DEPENDS} ${LEPTON_SOURCE_DIR}/asmjit/*/[^.]*.cpp)
+  file(GLOB ASMJIT_SOURCES CONFIGURE_DEPENDS ${LEPTON_SOURCE_DIR}/asmjit/*/[^.]*.cpp)
 endif()
 
 add_library(lepton STATIC ${LEPTON_SOURCES} ${ASMJIT_SOURCES})

cmake/Modules/Packages/MDI.cmake

@@ -26,30 +26,10 @@ if(DOWNLOAD_MDI)
 
   # detect if we have python development support and thus can enable python plugins
   set(MDI_USE_PYTHON_PLUGINS OFF)
-  if(CMAKE_VERSION VERSION_LESS 3.12)
-    if(NOT PYTHON_VERSION_STRING)
-      set(Python_ADDITIONAL_VERSIONS 3.12 3.11 3.10 3.9 3.8 3.7 3.6)
-      # search for interpreter first, so we have a consistent library
-      find_package(PythonInterp) # Deprecated since version 3.12
-      if(PYTHONINTERP_FOUND)
-        set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
-      endif()
-    endif()
-    # search for the library matching the selected interpreter
-    set(Python_ADDITIONAL_VERSIONS ${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR})
-    find_package(PythonLibs QUIET) # Deprecated since version 3.12
-    if(PYTHONLIBS_FOUND)
-      if(NOT (PYTHON_VERSION_STRING STREQUAL PYTHONLIBS_VERSION_STRING))
-        message(FATAL_ERROR "Python Library version ${PYTHONLIBS_VERSION_STRING} does not match Interpreter version ${PYTHON_VERSION_STRING}")
-      endif()
-      set(MDI_USE_PYTHON_PLUGINS ON)
-    endif()
-  else()
   find_package(Python QUIET COMPONENTS Development)
   if(Python_Development_FOUND)
     set(MDI_USE_PYTHON_PLUGINS ON)
   endif()
-  endif()
   # python plugins are not supported and thus must be always off on Windows
   if(CMAKE_SYSTEM_NAME STREQUAL "Windows")
     unset(Python_Development_FOUND)
@@ -102,13 +82,9 @@ if(DOWNLOAD_MDI)
   # if compiling with python plugins we need
   # to add python libraries as dependency.
   if(MDI_USE_PYTHON_PLUGINS)
-    if(CMAKE_VERSION VERSION_LESS 3.12)
-      list(APPEND MDI_DEP_LIBS ${PYTHON_LIBRARIES})
-    else()
     list(APPEND MDI_DEP_LIBS Python::Python)
   endif()
 
-  endif()
   # need to add support for dlopen/dlsym, except when compiling for Windows.
   if(NOT (CMAKE_SYSTEM_NAME STREQUAL "Windows"))
     list(APPEND MDI_DEP_LIBS "${CMAKE_DL_LIBS}")

cmake/Modules/Packages/ML-IAP.cmake

@@ -2,12 +2,7 @@
 set(MLIAP_ENABLE_PYTHON_DEFAULT OFF)
 if(PKG_PYTHON)
   find_package(Cythonize QUIET)
-  if (CMAKE_VERSION VERSION_GREATER_EQUAL 3.14)
   find_package(Python COMPONENTS NumPy QUIET)
-  else()
-    # assume we have NumPy
-    set(Python_NumPy_FOUND ON)
-  endif()
   if(Cythonize_FOUND AND Python_NumPy_FOUND)
     set(MLIAP_ENABLE_PYTHON_DEFAULT ON)
   endif()
@@ -17,24 +12,16 @@ option(MLIAP_ENABLE_PYTHON "Build ML-IAP package with Python support" ${MLIAP_EN
 
 if(MLIAP_ENABLE_PYTHON)
   find_package(Cythonize REQUIRED)
-  if (CMAKE_VERSION VERSION_GREATER_EQUAL 3.14)
   find_package(Python COMPONENTS NumPy REQUIRED)
-  endif()
   if(NOT PKG_PYTHON)
     message(FATAL_ERROR "Must enable PYTHON package for including Python support in ML-IAP")
   endif()
-  if(CMAKE_VERSION VERSION_LESS 3.12)
-    if(PYTHONLIBS_VERSION_STRING VERSION_LESS 3.6)
-      message(FATAL_ERROR "Python support in ML-IAP requires Python 3.6 or later")
-    endif()
-  else()
   if(Python_VERSION VERSION_LESS 3.6)
     message(FATAL_ERROR "Python support in ML-IAP requires Python 3.6 or later")
   endif()
-  endif()
 
   set(MLIAP_BINARY_DIR ${CMAKE_BINARY_DIR}/cython)
-  file(GLOB MLIAP_CYTHON_SRC ${CONFIGURE_DEPENDS} ${LAMMPS_SOURCE_DIR}/ML-IAP/*.pyx)
+  file(GLOB MLIAP_CYTHON_SRC CONFIGURE_DEPENDS ${LAMMPS_SOURCE_DIR}/ML-IAP/*.pyx)
   file(MAKE_DIRECTORY ${MLIAP_BINARY_DIR})
   foreach(MLIAP_CYTHON_FILE ${MLIAP_CYTHON_SRC})
     get_filename_component(MLIAP_CYTHON_BASE ${MLIAP_CYTHON_FILE} NAME_WE)

cmake/Modules/Packages/ML-PACE.cmake

@@ -1,6 +1,6 @@
-set(PACELIB_URL "https://github.com/ICAMS/lammps-user-pace/archive/refs/tags/v.2023.01.3.fix.tar.gz" CACHE STRING "URL for PACE evaluator library sources")
+set(PACELIB_URL "https://github.com/ICAMS/lammps-user-pace/archive/refs/tags/v.2023.10.04.tar.gz" CACHE STRING "URL for PACE evaluator library sources")
 
-set(PACELIB_MD5 "4f0b3b5b14456fe9a73b447de3765caa" CACHE STRING "MD5 checksum of PACE evaluator library tarball")
+set(PACELIB_MD5 "70ff79f4e59af175e55d24f3243ad1ff" CACHE STRING "MD5 checksum of PACE evaluator library tarball")
 mark_as_advanced(PACELIB_URL)
 mark_as_advanced(PACELIB_MD5)
 GetFallbackURL(PACELIB_URL PACELIB_FALLBACK)

cmake/Modules/Packages/MSCG.cmake

@@ -1,28 +0,0 @@
-find_package(GSL REQUIRED)
-find_package(MSCG QUIET)
-if(MSGC_FOUND)
-  set(DOWNLOAD_MSCG_DEFAULT OFF)
-else()
-  set(DOWNLOAD_MSCG_DEFAULT ON)
-endif()
-option(DOWNLOAD_MSCG "Download MSCG library instead of using an already installed one)" ${DOWNLOAD_MSCG_DEFAULT})
-if(DOWNLOAD_MSCG)
-  set(MSCG_URL "https://github.com/uchicago-voth/MSCG-release/archive/491270a73539e3f6951e76f7dbe84e258b3ebb45.tar.gz" CACHE STRING "URL for MSCG tarball")
-  set(MSCG_MD5 "7ea50748fba5c3a372e0266bd31d2f11" CACHE STRING "MD5 checksum of MSCG tarball")
-  mark_as_advanced(MSCG_URL)
-  mark_as_advanced(MSCG_MD5)
-
-  include(ExternalCMakeProject)
-  ExternalCMakeProject(mscg ${MSCG_URL} ${MSCG_MD5} MSCG-release src/CMake "")
-
-  # set include and link library
-  target_include_directories(lammps PRIVATE "${CMAKE_BINARY_DIR}/_deps/mscg-src/src")
-  target_link_libraries(lammps PRIVATE mscg)
-else()
-  find_package(MSCG)
-  if(NOT MSCG_FOUND)
-    message(FATAL_ERROR "MSCG not found, help CMake to find it by setting MSCG_LIBRARY and MSCG_INCLUDE_DIR, or set DOWNLOAD_MSCG=ON to download it")
-  endif()
-  target_link_libraries(lammps PRIVATE MSCG::MSCG)
-endif()
-target_link_libraries(lammps PRIVATE GSL::gsl ${LAPACK_LIBRARIES})

cmake/Modules/Packages/PYTHON.cmake

@@ -1,29 +1,11 @@
-if(CMAKE_VERSION VERSION_LESS 3.12)
-  if(NOT PYTHON_VERSION_STRING)
-    set(Python_ADDITIONAL_VERSIONS 3.12 3.11 3.10 3.9 3.8 3.7 3.6)
-    # search for interpreter first, so we have a consistent library
-    find_package(PythonInterp) # Deprecated since version 3.12
-    if(PYTHONINTERP_FOUND)
-      set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
-    endif()
-  endif()
-  # search for the library matching the selected interpreter
-  set(Python_ADDITIONAL_VERSIONS ${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR})
-  find_package(PythonLibs REQUIRED) # Deprecated since version 3.12
-  if(NOT (PYTHON_VERSION_STRING STREQUAL PYTHONLIBS_VERSION_STRING))
-    message(FATAL_ERROR "Python Library version ${PYTHONLIBS_VERSION_STRING} does not match Interpreter version ${PYTHON_VERSION_STRING}")
-  endif()
-  target_include_directories(lammps PRIVATE ${PYTHON_INCLUDE_DIRS})
-  target_link_libraries(lammps PRIVATE ${PYTHON_LIBRARIES})
-else()
-  if(NOT Python_INTERPRETER)
-    # backward compatibility
+
+if(NOT Python_INTERPRETER)
+  # backward compatibility with CMake before 3.12 and older LAMMPS documentation
   if(PYTHON_EXECUTABLE)
     set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
   endif()
   find_package(Python COMPONENTS Interpreter)
-  endif()
-  find_package(Python REQUIRED COMPONENTS Interpreter Development)
-  target_link_libraries(lammps PRIVATE Python::Python)
 endif()
+find_package(Python REQUIRED COMPONENTS Interpreter Development)
+target_link_libraries(lammps PRIVATE Python::Python)
 target_compile_definitions(lammps PRIVATE -DLMP_PYTHON)

cmake/Modules/StyleHeaderUtils.cmake

@@ -1,5 +1,5 @@
 function(FindStyleHeaders path style_class file_pattern headers)
-    file(GLOB files ${CONFIGURE_DEPENDS} "${path}/${file_pattern}*.h")
+    file(GLOB files CONFIGURE_DEPENDS "${path}/${file_pattern}*.h")
     get_property(hlist GLOBAL PROPERTY ${headers})
 
     foreach(file_name ${files})
@@ -187,7 +187,7 @@ endfunction(DetectBuildSystemConflict)
 
 
 function(FindPackagesHeaders path style_class file_pattern headers)
-    file(GLOB files ${CONFIGURE_DEPENDS} "${path}/${file_pattern}*.h")
+    file(GLOB files CONFIGURE_DEPENDS "${path}/${file_pattern}*.h")
     get_property(plist GLOBAL PROPERTY ${headers})
 
     foreach(file_name ${files})

cmake/Modules/Testing.cmake

@@ -6,7 +6,7 @@ if(ENABLE_TESTING)
   find_program(VALGRIND_BINARY NAMES valgrind)
   # generate custom suppression file
   file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/lammps.supp "\n")
-  file(GLOB VALGRIND_SUPPRESSION_FILES ${CONFIGURE_DEPENDS} ${LAMMPS_TOOLS_DIR}/valgrind/[^.]*.supp)
+  file(GLOB VALGRIND_SUPPRESSION_FILES CONFIGURE_DEPENDS ${LAMMPS_TOOLS_DIR}/valgrind/[^.]*.supp)
   foreach(SUPP ${VALGRIND_SUPPRESSION_FILES})
     file(READ ${SUPP} SUPPRESSIONS)
     file(APPEND ${CMAKE_CURRENT_BINARY_DIR}/lammps.supp "${SUPPRESSIONS}")
@@ -19,7 +19,7 @@ if(ENABLE_TESTING)
   # we need to build and link a LOT of tester executables, so it is worth checking if
   # a faster linker is available. requires GNU or Clang compiler, newer CMake.
   # also only verified with Fedora Linux > 30 and Ubuntu 18.04 or 22.04+(Ubuntu 20.04 fails)
-  if((CMAKE_SYSTEM_NAME STREQUAL "Linux") AND (CMAKE_VERSION VERSION_GREATER_EQUAL 3.13)
+  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)))
@@ -66,17 +66,9 @@ if(CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
   option(ENABLE_COVERAGE "Enable collecting code coverage data" OFF)
   mark_as_advanced(ENABLE_COVERAGE)
   if(ENABLE_COVERAGE)
-    if(CMAKE_VERSION VERSION_LESS 3.13)
-      if(CMAKE_CXX_FLAGS)
-        set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} --coverage")
-      else()
-        set(CMAKE_CXX_FLAGS "${CMAKE_CXX_${CMAKE_BUILD_TYPE}_FLAGS} --coverage")
-      endif()
-    else()
     target_compile_options(lammps PUBLIC --coverage)
     target_link_options(lammps PUBLIC --coverage)
   endif()
-  endif()
 endif()
 
 #######################################
@@ -118,16 +110,8 @@ validate_option(ENABLE_SANITIZER ENABLE_SANITIZER_VALUES)
 string(TOLOWER ${ENABLE_SANITIZER} ENABLE_SANITIZER)
 if(NOT ENABLE_SANITIZER STREQUAL "none")
   if((${CMAKE_CXX_COMPILER_ID} STREQUAL "GNU") OR (${CMAKE_CXX_COMPILER_ID} STREQUAL "Clang"))
-    if(CMAKE_VERSION VERSION_LESS 3.13)
-      if(CMAKE_CXX_FLAGS)
-        set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=${ENABLE_SANITIZER}")
-      else()
-        set(CMAKE_CXX_FLAGS "${CMAKE_CXX_${CMAKE_BUILD_TYPE}_FLAGS} -fsanitize=${ENABLE_SANITIZER}")
-      endif()
-    else()
     target_compile_options(lammps PUBLIC -fsanitize=${ENABLE_SANITIZER})
     target_link_options(lammps PUBLIC -fsanitize=${ENABLE_SANITIZER})
-    endif()
   else()
     message(WARNING "ENABLE_SANITIZER option not supported by ${CMAKE_CXX_COMPILER_ID} compilers. Ignoring.")
     set(ENABLE_SANITIZER "none")

cmake/Modules/Tools.cmake

@@ -26,7 +26,7 @@ if(BUILD_TOOLS)
 
   enable_language(C)
   get_filename_component(MSI2LMP_SOURCE_DIR ${LAMMPS_TOOLS_DIR}/msi2lmp/src ABSOLUTE)
-  file(GLOB MSI2LMP_SOURCES ${CONFIGURE_DEPENDS} ${MSI2LMP_SOURCE_DIR}/[^.]*.c)
+  file(GLOB MSI2LMP_SOURCES CONFIGURE_DEPENDS ${MSI2LMP_SOURCE_DIR}/[^.]*.c)
   add_executable(msi2lmp ${MSI2LMP_SOURCES})
   if(STANDARD_MATH_LIB)
     target_link_libraries(msi2lmp PRIVATE ${STANDARD_MATH_LIB})
@@ -44,9 +44,6 @@ if(BUILD_LAMMPS_SHELL)
   endif()
   find_package(PkgConfig REQUIRED)
   pkg_check_modules(READLINE IMPORTED_TARGET REQUIRED readline)
-  if(NOT LAMMPS_EXCEPTIONS)
-    message(WARNING "The LAMMPS shell needs LAMMPS_EXCEPTIONS enabled for full functionality")
-  endif()
 
   # include resource compiler to embed icons into the executable on Windows
   if(CMAKE_SYSTEM_NAME STREQUAL "Windows")

cmake/packaging/MacOSXBundleInfo.plist.in

@@ -17,7 +17,7 @@
 	<key>CFBundleLongVersionString</key>
 	<string>${MACOSX_BUNDLE_LONG_VERSION_STRING}</string>
 	<key>CFBundleName</key>
-	<string>LAMMPS</string>
+	<string>LAMMPS_GUI</string>
 	<key>CFBundlePackageType</key>
 	<string>APPL</string>
 	<key>CFBundleShortVersionString</key>

cmake/packaging/README.macos

@@ -9,7 +9,7 @@ of the available packages.
 The following individual commands are included:
 binary2txt lammps-gui lmp msi2lmp phana stl_bin2txt
 
-After copying the lammps-gui folder into your Applications folder, please follow
+After copying the LAMMPS_GUI folder into your Applications folder, please follow
 these steps:
 
 1. Open the Terminal app
@@ -23,7 +23,7 @@ these steps:
 
 3. Add the following lines to the end of the file, save it, and close the editor
 
-   LAMMPS_INSTALL_DIR=/Applications/LAMMPS.app/Contents
+   LAMMPS_INSTALL_DIR=/Applications/LAMMPS_GUI.app/Contents
    LAMMPS_POTENTIALS=${LAMMPS_INSTALL_DIR}/share/lammps/potentials
    LAMMPS_BENCH_DIR=${LAMMPS_INSTALL_DIR}/share/lammps/bench
    MSI2LMP_LIBRARY=${LAMMPS_INSTALL_DIR}/share/lammps/frc_files
@@ -38,9 +38,9 @@ these steps:
    the changes from .zprofile automatically.
 
    Note: the above assumes you use the default shell (zsh) that comes with
-   MacOS. If you customized MacOS to use a different shell, you'll need to modify
-   that shell's init file (.cshrc, .bashrc, etc.) instead with appropiate commands
-   to modify the same environment variables.
+   MacOS. If you customized MacOS to use a different shell, you'll need to
+   modify that shell's init file (.cshrc, .bashrc, etc.) instead with
+   appropiate commands to modify the same environment variables.
 
 5. Try running LAMMPS (which might fail, see step 7)
 
@@ -50,10 +50,10 @@ these steps:
 
    lammps-gui ${LAMMPS_BENCH_DIR}/in.rhodo
 
-   Depending on the size and resolution of your screen, the fonts may
-   be too small to read. This can be adjusted by setting the environment
-   variable QT_FONT_DPI. The default value would be 72, so to increase
-   the fonts by a third one can add to the .zprofile file the line
+   Depending on the size and resolution of your screen, the fonts may be too
+   small to read. This can be adjusted by setting the environment variable
+   QT_FONT_DPI. The default value would be 72, so to increase the fonts by a
+   third, one can add to the .zprofile file the line
 
    export QT_FONT_DPI=96
 
@@ -61,9 +61,9 @@ these steps:
 
 7. Give permission to execute the commands (lmp, lammps-gui, msi2lmp, binary2txt, phana, stl_bin2txt)
 
-   MacOS will likely block the initial run of the executables, since they
-   were downloaded from the internet and are missing a known signature from an
-   identified developer. Go to "Settings" and search for "Security settings". It
-   should display a message that an executable like "lmp" was blocked. Press
+   MacOS will likely block the initial run of the executables, since they were
+   downloaded from the internet and are missing a known signature from an
+   identified developer. Go to "Settings" and search for "Security settings".
+   It should display a message that an executable like "lmp" was blocked. Press
    "Open anyway", which might prompt you for your admin credentials. Afterwards
    "lmp" and the other executables should work as expected.

cmake/packaging/build_linux_tgz.sh

@@ -4,7 +4,7 @@ APP_NAME=lammps-gui
 DESTDIR=${PWD}/../LAMMPS_GUI
 
 echo "Delete old files, if they exist"
-rm -rf ${DESTDIR} ../LAMMPS-Linux-amd64.tar.gz
+rm -rf ${DESTDIR} ../LAMMPS_GUI-Linux-amd64.tar.gz
 
 echo "Create staging area for deployment and populate"
 DESTDIR=${DESTDIR} cmake --install .  --prefix "/"
@@ -69,7 +69,7 @@ do \
 done
 
 pushd ..
-tar -czvvf LAMMPS-Linux-amd64.tar.gz LAMMPS_GUI
+tar -czvvf LAMMPS_GUI-Linux-amd64.tar.gz LAMMPS_GUI
 popd
 
 echo "Cleanup dir"

cmake/packaging/build_macos_dmg.sh

@@ -3,7 +3,7 @@
 APP_NAME=lammps-gui
 
 echo "Delete old files, if they exist"
-rm -f ${APP_NAME}.dmg ${APP_NAME}-rw.dmg LAMMPS-macOS-multiarch.dmg
+rm -f ${APP_NAME}.dmg ${APP_NAME}-rw.dmg LAMMPS_GUI-macOS-multiarch.dmg
 
 echo "Create initial dmg file with macdeployqt"
 macdeployqt  lammps-gui.app -dmg
@@ -22,8 +22,8 @@ ln -s /Applications .
 mv  ${APP_NAME}.app/Contents/Resources/README.txt .
 mkdir  .background
 mv ${APP_NAME}.app/Contents/Resources/LAMMPS_DMG_Background.png .background/background.png
-mv ${APP_NAME}.app LAMMPS.app
-cd LAMMPS.app/Contents
+mv ${APP_NAME}.app LAMMPS_GUI.app
+cd LAMMPS_GUI.app/Contents
 
 echo "Attach icons to LAMMPS console and GUI executables"
 echo "read 'icns' (-16455) \"Resources/lammps.icns\";" > icon.rsrc
@@ -75,7 +75,7 @@ echo '
           set statusbar visible to false
           set toolbar visible to false
           set the bounds to { 100, 40, 868, 640 }
-          set position of item "'LAMMPS'.app" to { 190, 216 }
+          set position of item "'LAMMPS_GUI'.app" to { 190, 216 }
           set position of item "Applications" to { 576, 216 }
           set position of item "README.txt" to { 190, 400 }
         end tell
@@ -96,12 +96,12 @@ sync
 
 echo "Unmount modified disk image and convert to compressed read-only image"
 hdiutil detach "${DEVICE}"
-hdiutil convert "${APP_NAME}-rw.dmg" -format UDZO -o "LAMMPS-macOS-multiarch.dmg"
+hdiutil convert "${APP_NAME}-rw.dmg" -format UDZO -o "LAMMPS_GUI-macOS-multiarch.dmg"
 
 echo "Attach icon to .dmg file"
 echo "read 'icns' (-16455) \"lammps-gui.app/Contents/Resources/lammps.icns\";" > icon.rsrc
-Rez -a icon.rsrc -o LAMMPS-macOS-multiarch.dmg
-SetFile -a C LAMMPS-macOS-multiarch.dmg
+Rez -a icon.rsrc -o LAMMPS_GUI-macOS-multiarch.dmg
+SetFile -a C LAMMPS_GUI-macOS-multiarch.dmg
 rm icon.rsrc
 
 echo "Delete temporary disk images"

cmake/packaging/build_windows_vs.cmake

@@ -1,7 +1,7 @@
 # CMake script to be run post installation to build zipped package
 
 # clean up old zipfile and deployment tree
-file(REMOVE LAMMPS-Win10-amd64.zip)
+file(REMOVE LAMMPS_GUI-Win10-amd64.zip)
 file(REMOVE_RECURSE LAMMPS_GUI)
 file(RENAME ${INSTNAME} LAMMPS_GUI)
 
@@ -21,8 +21,15 @@ file(WRITE qtdeploy.bat "@ECHO OFF\r\nset VSCMD_DEBUG=0\r\nCALL ${VC_INIT} x64\r
 execute_process(COMMAND cmd.exe /c qtdeploy.bat COMMAND_ECHO STDERR)
 file(REMOVE qtdeploy.bat)
 
+# download and uncompress static FFMpeg and gzip binaries
+file(DOWNLOAD "https://download.lammps.org/thirdparty/ffmpeg-gzip.zip" ffmpeg-gzip.zip)
+file(WRITE unpackzip.ps1 "Expand-Archive -Path ffmpeg-gzip.zip -DestinationPath LAMMPS_GUI")
+execute_process(COMMAND powershell -ExecutionPolicy Bypass -File unpackzip.ps1)
+file(REMOVE unpackzip.ps1)
+file(REMOVE ffmpeg-gzip.zip)
+
 # create zip archive
-file(WRITE makearchive.ps1 "Compress-Archive -Path LAMMPS_GUI -CompressionLevel Optimal -DestinationPath LAMMPS-Win10-amd64.zip")
+file(WRITE makearchive.ps1 "Compress-Archive -Path LAMMPS_GUI -CompressionLevel Optimal -DestinationPath LAMMPS_GUI-Win10-amd64.zip")
 execute_process(COMMAND powershell -ExecutionPolicy Bypass -File makearchive.ps1)
 file(REMOVE makearchive.ps1)
 file(REMOVE_RECURSE LAMMPS_GUI)

cmake/presets/all_off.cmake

@@ -63,8 +63,6 @@ set(ALL_PACKAGES
   MOFFF
   MOLECULE
   MOLFILE
-  MPIIO
-  MSCG
   NETCDF
   OPENMP
   OPT

cmake/presets/all_on.cmake

@@ -65,8 +65,6 @@ set(ALL_PACKAGES
   MOFFF
   MOLECULE
   MOLFILE
-  MPIIO
-  MSCG
   NETCDF
   OPENMP
   OPT

cmake/presets/download.cmake

@@ -9,7 +9,6 @@ endforeach()
 
 set(DOWNLOAD_KIM ON CACHE BOOL "" FORCE)
 set(DOWNLOAD_MDI ON CACHE BOOL "" FORCE)
-set(DOWNLOAD_MSCG ON CACHE BOOL "" FORCE)
 set(DOWNLOAD_VORO ON CACHE BOOL "" FORCE)
 set(DOWNLOAD_EIGEN3 ON CACHE BOOL "" FORCE)
 set(DOWNLOAD_PACE ON CACHE BOOL "" FORCE)

cmake/presets/macos-multiarch.cmake

@@ -10,5 +10,3 @@ set(CMAKE_CXX_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
 set(CMAKE_C_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
 
 set(BUILD_MPI FALSE CACHE BOOL "" FORCE)
-set(BUILD_SHARED_LIBS FALSE CACHE BOOL "" FORCE)
-set(LAMMPS_EXCEPTIONS TRUE CACHE BOOL "" FORCE)

cmake/presets/mingw-cross.cmake

@@ -83,7 +83,6 @@ endforeach()
 
 # these two packages require a full MPI implementation
 if(BUILD_MPI)
-  set(PKG_MPIIO ON CACHE BOOL "" FORCE)
   set(PKG_LATBOLTZ ON CACHE BOOL "" FORCE)
 endif()
 

cmake/presets/most.cmake

@@ -24,8 +24,8 @@ set(ALL_PACKAGES
   DPD-REACT
   DPD-SMOOTH
   DRUDE
-  ELECTRODE
   EFF
+  ELECTRODE
   EXTRA-COMPUTE
   EXTRA-DUMP
   EXTRA-FIX

cmake/presets/nolib.cmake

@@ -19,8 +19,6 @@ set(PACKAGES_WITH_LIB
   ML-PACE
   ML-QUIP
   MOLFILE
-  MPIIO
-  MSCG
   NETCDF
   PLUMED
   PYTHON

doc/Makefile

@@ -63,6 +63,7 @@ help:
 	@echo "  anchor_check  scan for duplicate anchor labels"
 	@echo "  style_check   check for complete and consistent style lists"
 	@echo "  package_check check for complete and consistent package lists"
+	@echo "  role_check    check for misformatted role keywords"
 	@echo "  spelling      spell-check the manual"
 
 # ------------------------------------------
@@ -98,6 +99,7 @@ html: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJAX)
 		env LC_ALL=C grep -n '[^ -~]' $(RSTDIR)/*.rst ;\
 		env LC_ALL=C grep -n ' :[a-z]\+`' $(RSTDIR)/*.rst ;\
 		env LC_ALL=C grep -n ' `[^`]\+<[a-z][^`]\+`[^_]' $(RSTDIR)/*.rst ;\
+		env LC_ALL=C grep -n ':\(ref\|doc\):[^`]' $(RSTDIR)/*.rst ;\
 		$(PYTHON) $(BUILDDIR)/utils/check-styles.py -s ../src -d src ;\
 		echo "############################################" ;\
 		deactivate ;\
@@ -179,6 +181,7 @@ pdf: xmlgen $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK)
 		env LC_ALL=C grep -n '[^ -~]' $(RSTDIR)/*.rst ;\
 		env LC_ALL=C grep -n ' :[a-z]\+`' $(RSTDIR)/*.rst ;\
 		env LC_ALL=C grep -n ' `[^`]\+<[a-z][^`]\+`[^_]' $(RSTDIR)/*.rst ;\
+		env LC_ALL=C grep -n ':\(ref\|doc\):[^`]' $(RSTDIR)/*.rst ;\
 		$(PYTHON) utils/check-styles.py -s ../src -d src ;\
 		echo "############################################" ;\
 		deactivate ;\
@@ -227,6 +230,7 @@ char_check :
 role_check :
 	@( env LC_ALL=C grep -n ' :[a-z]\+`' $(RSTDIR)/*.rst && exit 1 || : )
 	@( env LC_ALL=C grep -n ' `[^`]\+<[a-z][^`]\+`[^_]' $(RSTDIR)/*.rst && exit 1 || : )
+	@( env LC_ALL=C grep -n ':\(ref\|doc\):[^`]' $(RSTDIR)/*.rst && exit 1 || : )
 
 link_check : $(VENV) html
 	@(\

doc/lammps.1

@@ -1,7 +1,7 @@
-.TH LAMMPS "1" "2 August 2023" "2023-08-2"
+.TH LAMMPS "1" "21 November 2023" "2023-11-21"
 .SH NAME
 .B LAMMPS
-\- Molecular Dynamics Simulator.  Version 2 August 2023
+\- Molecular Dynamics Simulator.  Version 21 November 2023
 
 .SH SYNOPSIS
 .B lmp

doc/src/Build_basics.rst

@@ -90,7 +90,7 @@ standard. A more detailed discussion of that is below.
       directory, or ``make`` from the ``src/STUBS`` dir.  If the build
       fails, you may need to edit the ``STUBS/Makefile`` for your
       platform.  The stubs library does not provide MPI/IO functions
-      required by some LAMMPS packages, e.g. ``MPIIO`` or ``LATBOLTZ``,
+      required by some LAMMPS packages, e.g. ``LATBOLTZ``,
       and thus is not compatible with those packages.
 
       .. note::
@@ -128,14 +128,13 @@ and adds vectorization support when compiled with compatible compilers,
 in particular the Intel compilers on top of OpenMP. Also, the ``KOKKOS``
 package can be compiled to include OpenMP threading.
 
-In addition, there are a few commands in LAMMPS that have native
-OpenMP support included as well.  These are commands in the ``MPIIO``,
-``ML-SNAP``, ``DIFFRACTION``, and ``DPD-REACT`` packages.
-Furthermore, some packages support OpenMP threading indirectly through
-the libraries they interface to: e.g. ``KSPACE``, and ``COLVARS``.
-See the :doc:`Packages details <Packages_details>` page for more info
-on these packages, and the pages for their respective commands for
-OpenMP threading info.
+In addition, there are a few commands in LAMMPS that have native OpenMP
+support included as well.  These are commands in the ``ML-SNAP``,
+``DIFFRACTION``, and ``DPD-REACT`` packages.  Furthermore, some packages
+support OpenMP threading indirectly through the libraries they interface
+to: e.g. ``KSPACE``, and ``COLVARS``.  See the :doc:`Packages details
+<Packages_details>` page for more info on these packages, and the pages
+for their respective commands for OpenMP threading info.
 
 For CMake, if you use ``BUILD_OMP=yes``, you can use these packages
 and turn on their native OpenMP support and turn on their native OpenMP

doc/src/Build_cmake.rst

@@ -16,8 +16,7 @@ environments is on a :doc:`separate page <Howto_cmake>`.
 
 .. note::
 
-   LAMMPS currently requires that CMake version 3.10 or later is available;
-   version 3.12 or later is preferred.
+   LAMMPS currently requires that CMake version 3.16 or later is available.
 
 .. warning::
 
@@ -34,19 +33,18 @@ Advantages of using CMake
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
 CMake is an alternative to compiling LAMMPS in the traditional way
-through :doc:`(manually customized) makefiles <Build_make>` and a recent
-addition to LAMMPS thanks to the efforts of Christoph Junghans (LANL)
-and Richard Berger (Temple U).  Using CMake has multiple advantages that
-are specifically helpful for people with limited experience in compiling
-software or for people that want to modify or extend LAMMPS.
+through :doc:`(manually customized) makefiles <Build_make>`.  Using
+CMake has multiple advantages that are specifically helpful for
+people with limited experience in compiling software or for people
+that want to modify or extend LAMMPS.
 
 - CMake can detect available hardware, tools, features, and libraries
   and adapt the LAMMPS default build configuration accordingly.
 - CMake can generate files for different build tools and integrated
   development environments (IDE).
 - CMake supports customization of settings with a command line, text
-  mode, or graphical user interface.  No knowledge of file formats or
-  complex command line syntax is required.
+  mode, or graphical user interface.  No manual editing of files,
+  knowledge of file formats or complex command line syntax is required.
 - All enabled components are compiled in a single build operation.
 - Automated dependency tracking for all files and configuration options.
 - Support for true out-of-source compilation. Multiple configurations
@@ -179,13 +177,13 @@ configuration is selected with the *-C* flag:
 
    ctest -C Debug
 
-The CMake scripts in LAMMPS have basic support for being compiled using a
-multi-config build system, but not all of it has been ported.  This is in
-particular applicable to compiling packages that require additional libraries
-that would be downloaded and compiled by CMake.  The "windows" preset file
-tries to keep track of which packages can be compiled natively with the
-MSVC compilers out-of-the box.  Not all of those external libraries are
-portable to Windows, either.
+The CMake scripts in LAMMPS have basic support for being compiled using
+a multi-config build system, but not all of it has been ported.  This is
+in particular applicable to compiling packages that require additional
+libraries that would be downloaded and compiled by CMake.  The
+``windows.cmake`` preset file tries to keep track of which packages can
+be compiled natively with the MSVC compilers out-of-the box.  Not all of
+the external libraries are portable to Windows, either.
 
 
 Installing CMake

doc/src/Build_extras.rst

@@ -52,7 +52,6 @@ This is the list of packages that may require additional steps.
    * :ref:`ML-POD <ml-pod>`
    * :ref:`ML-QUIP <ml-quip>`
    * :ref:`MOLFILE <molfile>`
-   * :ref:`MSCG <mscg>`
    * :ref:`NETCDF <netcdf>`
    * :ref:`OPENMP <openmp>`
    * :ref:`OPT <opt>`
@@ -639,6 +638,12 @@ They must be specified in uppercase.
    *  - VEGA90A
       - GPU
       - AMD GPU MI200 GFX90A
+   *  - NAVI1030
+      - GPU
+      - AMD GPU V620/W6800
+   *  - NAVI1100
+      - GPU
+      - AMD GPU RX7900XTX
    *  - INTEL_GEN
       - GPU
       - SPIR64-based devices, e.g. Intel GPUs, using JIT
@@ -661,7 +666,7 @@ They must be specified in uppercase.
       - GPU
       - Intel GPU Ponte Vecchio
 
-This list was last updated for version 3.7.1 of the Kokkos library.
+This list was last updated for version 4.0.1 of the Kokkos library.
 
 .. tabs::
 
@@ -717,9 +722,10 @@ This list was last updated for version 3.7.1 of the Kokkos library.
       ``cmake/presets`` folder, ``kokkos-serial.cmake``,
       ``kokkos-openmp.cmake``, ``kokkos-cuda.cmake``,
       ``kokkos-hip.cmake``, and ``kokkos-sycl.cmake``.  They will enable
-      the KOKKOS package and enable some hardware choice.  So to compile
-      with CUDA device parallelization (for GPUs with CC 5.0 and up)
-      with some common packages enabled, you can do the following:
+      the KOKKOS package and enable some hardware choices.  For GPU
+      support those preset files must be customized to match the
+      hardware used. So to compile with CUDA device parallelization with
+      some common packages enabled, you can do the following:
 
       .. code-block:: bash
 
@@ -975,59 +981,6 @@ Python version 3.6 or later.
 
 ----------
 
-.. _mscg:
-
-MSCG package
------------------------
-
-To build with this package, you must download and build the MS-CG
-library.  Building the MS-CG library requires that the GSL
-(GNU Scientific Library) headers and libraries are installed on your
-machine.  See the ``lib/mscg/README`` and ``MSCG/Install`` files for
-more details.
-
-.. tabs::
-
-   .. tab:: CMake build
-
-      .. code-block:: bash
-
-         -D DOWNLOAD_MSCG=value    # download MSCG for build, value = no (default) or yes
-         -D MSCG_LIBRARY=path      # MSCG library file (only needed if a custom location)
-         -D MSCG_INCLUDE_DIR=path  # MSCG include directory (only needed if a custom location)
-
-      If ``DOWNLOAD_MSCG`` is set, the MSCG library will be downloaded
-      and built inside the CMake build directory.  If the MSCG library
-      is already on your system (in a location CMake cannot find it),
-      ``MSCG_LIBRARY`` is the filename (plus path) of the MSCG library
-      file, not the directory the library file is in.
-      ``MSCG_INCLUDE_DIR`` is the directory the MSCG include file is in.
-
-   .. tab:: Traditional make
-
-      You can download and build the MS-CG library manually if you
-      prefer; follow the instructions in ``lib/mscg/README``\ .  You can
-      also do it in one step from the ``lammps/src`` dir, using a
-      command like these, which simply invokes the
-      ``lib/mscg/Install.py`` script with the specified args:
-
-      .. code-block:: bash
-
-         make lib-mscg             # print help message
-         make lib-mscg args="-b -m serial"   # download and build in lib/mscg/MSCG-release-master
-                                             # with the settings compatible with "make serial"
-         make lib-mscg args="-b -m mpi"      # download and build in lib/mscg/MSCG-release-master
-                                             # with the settings compatible with "make mpi"
-         make lib-mscg args="-p /usr/local/mscg-release" # use the existing MS-CG installation in /usr/local/mscg-release
-
-      Note that 2 symbolic (soft) links, ``includelink`` and ``liblink``,
-      will be created in ``lib/mscg`` to point to the MS-CG
-      ``src/installation`` dir.  When LAMMPS is built in src it will use
-      these links.  You should not need to edit the
-      ``lib/mscg/Makefile.lammps`` file.
-
-----------
-
 .. _opt:
 
 OPT package
@@ -1103,12 +1056,12 @@ additional details.
 
       .. code-block:: bash
 
-         -D PYTHON_EXECUTABLE=path   # path to Python executable to use
+         -D Python_EXECUTABLE=path   # path to Python executable to use
 
       Without this setting, CMake will guess the default Python version
       on your system.  To use a different Python version, you can either
       create a virtualenv, activate it and then run cmake.  Or you can
-      set the PYTHON_EXECUTABLE variable to specify which Python
+      set the Python_EXECUTABLE variable to specify which Python
       interpreter should be used.  Note note that you will also need to
       have the development headers installed for this version,
       e.g. python2-devel.

doc/src/Build_package.rst

@@ -55,7 +55,6 @@ packages:
    * :ref:`ML-POD <ml-pod>`
    * :ref:`ML-QUIP <ml-quip>`
    * :ref:`MOLFILE <molfile>`
-   * :ref:`MSCG <mscg>`
    * :ref:`NETCDF <netcdf>`
    * :ref:`OPENMP <openmp>`
    * :ref:`OPT <opt>`
@@ -183,6 +182,7 @@ make a copy of one of them and modify it to suit your needs.
     cmake -C ../cmake/presets/all_on.cmake   [OPTIONS] ../cmake  # enable all packages
     cmake -C ../cmake/presets/all_off.cmake  [OPTIONS] ../cmake  # disable all packages
     mingw64-cmake -C ../cmake/presets/mingw-cross.cmake [OPTIONS] ../cmake  #  compile with MinGW cross-compilers
+    cmake -C ../cmake/presets/macos-multiarch.cmake [OPTIONS] ../cmake # compile serial multi-arch binaries on macOS
 
 Presets that have names starting with "windows" are specifically for
 compiling LAMMPS :doc:`natively on Windows <Build_windows>` and

doc/src/Build_settings.rst

@@ -459,27 +459,13 @@ those systems:
 .. _exceptions:
 
 Exception handling when using LAMMPS as a library
-------------------------------------------------------------------
+-------------------------------------------------
 
-This setting is useful when external codes drive LAMMPS as a library.
-With this option enabled, LAMMPS errors do not kill the calling code.
-Instead, the call stack is unwound and control returns to the caller,
-e.g. to Python. Of course, the calling code has to be set up to
-*catch* exceptions thrown from within LAMMPS.
-
-.. tabs::
-
-   .. tab:: CMake build
-
-      .. code-block:: bash
-
-         -D LAMMPS_EXCEPTIONS=value        # yes or no (default)
-
-   .. tab:: Traditional make
-
-      .. code-block:: make
-
-         LMP_INC = -DLAMMPS_EXCEPTIONS   <other LMP_INC settings>
+LAMMPS errors do not kill the calling code, but throw an exception.  In
+the C-library interface, the call stack is unwound and control returns
+to the caller, e.g. to Python or a code that is coupled to LAMMPS and
+the error status can be queried.  When using C++ directly, the calling
+code has to be set up to *catch* exceptions thrown from within LAMMPS.
 
 .. note::
 

doc/src/Commands_compute.rst

@@ -91,6 +91,7 @@ KOKKOS, o = OPENMP, t = OPT.
    * :doc:`ke/atom/eff <compute_ke_atom_eff>`
    * :doc:`ke/eff <compute_ke_eff>`
    * :doc:`ke/rigid <compute_ke_rigid>`
+   * :doc:`composition/atom (k) <compute_composition_atom>`
    * :doc:`mliap <compute_mliap>`
    * :doc:`momentum <compute_momentum>`
    * :doc:`msd <compute_msd>`

doc/src/Commands_dump.rst

@@ -23,17 +23,14 @@ An alphabetic list of all LAMMPS :doc:`dump <dump>` commands.
    * :doc:`atom <dump>`
    * :doc:`atom/adios <dump_adios>`
    * :doc:`atom/gz <dump>`
-   * :doc:`atom/mpiio <dump>`
    * :doc:`atom/zstd <dump>`
    * :doc:`cfg <dump>`
    * :doc:`cfg/gz <dump>`
-   * :doc:`cfg/mpiio <dump>`
    * :doc:`cfg/uef <dump_cfg_uef>`
    * :doc:`cfg/zstd <dump>`
    * :doc:`custom <dump>`
    * :doc:`custom/adios <dump_adios>`
    * :doc:`custom/gz <dump>`
-   * :doc:`custom/mpiio <dump>`
    * :doc:`custom/zstd <dump>`
    * :doc:`dcd <dump>`
    * :doc:`grid <dump>`
@@ -51,7 +48,6 @@ An alphabetic list of all LAMMPS :doc:`dump <dump>` commands.
    * :doc:`xtc <dump>`
    * :doc:`xyz <dump>`
    * :doc:`xyz/gz <dump>`
-   * :doc:`xyz/mpiio <dump>`
    * :doc:`xyz/zstd <dump>`
    * :doc:`yaml <dump>`
 

doc/src/Commands_fix.rst

@@ -69,7 +69,7 @@ OPT.
    * :doc:`drude/transform/inverse <fix_drude_transform>`
    * :doc:`dt/reset (k) <fix_dt_reset>`
    * :doc:`edpd/source <fix_dpd_source>`
-   * :doc:`efield <fix_efield>`
+   * :doc:`efield (k) <fix_efield>`
    * :doc:`efield/tip4p <fix_efield>`
    * :doc:`ehex <fix_ehex>`
    * :doc:`electrode/conp (i) <fix_electrode>`
@@ -116,7 +116,6 @@ OPT.
    * :doc:`momentum (k) <fix_momentum>`
    * :doc:`momentum/chunk <fix_momentum>`
    * :doc:`move <fix_move>`
-   * :doc:`mscg <fix_mscg>`
    * :doc:`msst <fix_msst>`
    * :doc:`mvv/dpd <fix_mvv_dpd>`
    * :doc:`mvv/edpd <fix_mvv_dpd>`
@@ -182,6 +181,7 @@ OPT.
    * :doc:`pour <fix_pour>`
    * :doc:`precession/spin <fix_precession_spin>`
    * :doc:`press/berendsen <fix_press_berendsen>`
+   * :doc:`press/langevin <fix_press_langevin>`
    * :doc:`print <fix_print>`
    * :doc:`propel/self <fix_propel_self>`
    * :doc:`property/atom (k) <fix_property_atom>`
@@ -233,7 +233,7 @@ OPT.
    * :doc:`spring <fix_spring>`
    * :doc:`spring/chunk <fix_spring_chunk>`
    * :doc:`spring/rg <fix_spring_rg>`
-   * :doc:`spring/self <fix_spring_self>`
+   * :doc:`spring/self (k) <fix_spring_self>`
    * :doc:`srd <fix_srd>`
    * :doc:`store/force <fix_store_force>`
    * :doc:`store/state <fix_store_state>`

doc/src/Commands_pair.rst

@@ -220,7 +220,8 @@ OPT.
    * :doc:`morse/soft <pair_fep_soft>`
    * :doc:`multi/lucy <pair_multi_lucy>`
    * :doc:`multi/lucy/rx (k) <pair_multi_lucy_rx>`
-   * :doc:`nb3b/harmonic <pair_nb3b_harmonic>`
+   * :doc:`nb3b/harmonic <pair_nb3b>`
+   * :doc:`nb3b/screened <pair_nb3b>`
    * :doc:`nm/cut (o) <pair_nm>`
    * :doc:`nm/cut/coul/cut (o) <pair_nm>`
    * :doc:`nm/cut/coul/long (o) <pair_nm>`
@@ -265,7 +266,7 @@ OPT.
    * :doc:`smd/tri_surface <pair_smd_triangulated_surface>`
    * :doc:`smd/ulsph <pair_smd_ulsph>`
    * :doc:`smtbq <pair_smtbq>`
-   * :doc:`snap (k) <pair_snap>`
+   * :doc:`snap (ik) <pair_snap>`
    * :doc:`soft (go) <pair_soft>`
    * :doc:`sph/heatconduction <pair_sph_heatconduction>`
    * :doc:`sph/idealgas <pair_sph_idealgas>`
@@ -305,5 +306,5 @@ OPT.
    * :doc:`wf/cut <pair_wf_cut>`
    * :doc:`ylz <pair_ylz>`
    * :doc:`yukawa (gko) <pair_yukawa>`
-   * :doc:`yukawa/colloid (go) <pair_yukawa_colloid>`
+   * :doc:`yukawa/colloid (gko) <pair_yukawa_colloid>`
    * :doc:`zbl (gko) <pair_zbl>`

doc/src/Commands_removed.rst

@@ -85,6 +85,35 @@ The same functionality is available through
 :doc:`bond style mesocnt <bond_mesocnt>` and
 :doc:`angle style mesocnt <angle_mesocnt>`.
 
+MPIIO package
+-------------
+
+.. deprecated:: 21Nov2023
+
+The MPIIO package has been removed from LAMMPS since it was unmaintained
+for many years and thus not updated to incorporate required changes that
+had been applied to the corresponding non-MPIIO commands. As a
+consequence the MPIIO commands had become unreliable and sometimes
+crashing LAMMPS or corrupting data.  Similar functionality is available
+through the :ref:`ADIOS package <PKG-ADIOS>` and the :ref:`NETCDF
+package <PKG-NETCDF>`.  Also, the :doc:`dump_modify nfile or dump_modify
+fileper <dump_modify>` keywords may be used for an efficient way of
+writing out dump files when running on large numbers of processors.
+Similarly, the "nfile" and "fileper" keywords exist for restarts:
+see :doc:`restart <restart>`, :doc:`read_restart <read_restart>`,
+:doc:`write_restart <write_restart>`.
+
+
+MSCG package
+------------
+
+.. deprecated:: 21Nov2023
+
+The MSCG package has been removed from LAMMPS since it was unmaintained
+for many years and instead superseded by the `OpenMSCG software
+<https://software.rcc.uchicago.edu/mscg/>`_ of the Voth group at the
+University of Chicago, which can be used independent from LAMMPS.
+
 REAX package
 ------------
 

doc/src/Errors_messages.rst

@@ -7148,9 +7148,6 @@ keyword to allow for additional bonds to be formed
 *Read_dump xyz fields do not have consistent scaling/wrapping*
    Self-explanatory.
 
-*Reading from MPI-IO filename when MPIIO package is not installed*
-   Self-explanatory.
-
 *Reax_defs.h setting for NATDEF is too small*
    Edit the setting in the ReaxFF library and re-compile the
    library and re-build LAMMPS.
@@ -8489,9 +8486,6 @@ keyword to allow for additional bonds to be formed
    The write_restart command cannot be used before a read_data,
    read_restart, or create_box command.
 
-*Writing to MPI-IO filename when MPIIO package is not installed*
-   Self-explanatory.
-
 *Zero length rotation vector with displace_atoms*
    Self-explanatory.
 

doc/src/Examples.rst

@@ -104,8 +104,6 @@ Lowercase directories
 +-------------+------------------------------------------------------------------+
 | min         | energy minimization of 2d LJ melt                                |
 +-------------+------------------------------------------------------------------+
-| mscg        | parameterize a multi-scale coarse-graining (MSCG) model          |
-+-------------+------------------------------------------------------------------+
 | msst        | MSST shock dynamics                                              |
 +-------------+------------------------------------------------------------------+
 | multi       | multi neighboring for systems with large interaction disparities |

doc/src/Fortran.rst

@@ -2278,19 +2278,13 @@ Procedures Bound to the :f:type:`lammps` Derived Type
 
    .. versionadded:: 3Nov2022
 
-   In case of an error, LAMMPS will either abort or throw a C++ exception.
-   The latter has to be :ref:`enabled at compile time <exceptions>`.
-   This function checks if exceptions were enabled.
-
-   When using the library interface with C++ exceptions enabled, the library
-   interface functions will "catch" them, and the error status can then be
-   checked by calling :f:func:`has_error`. The most recent error message can be
-   retrieved via :f:func:`get_last_error_message`.
-   This can allow one to restart a calculation or delete and recreate
-   the LAMMPS instance when a C++ exception occurs.  One application
-   of using exceptions this way is the :ref:`lammps_shell`.  If C++
-   exceptions are disabled and an error happens during a call to
-   LAMMPS or the Fortran API, the application will terminate.
+   When using the library interface, the library interface functions
+   will "catch" exceptions, and then the error status can be checked by
+   calling :f:func:`has_error`.  The most recent error message can be
+   retrieved via :f:func:`get_last_error_message`.  This allows to
+   restart a calculation or delete and recreate the LAMMPS instance when
+   a C++ exception occurs.  One application of using exceptions this way
+   is the :ref:`lammps_shell`.
 
    :to: :cpp:func:`lammps_config_has_exceptions`
    :r has_exceptions:

doc/src/Howto_body.rst

@@ -170,9 +170,9 @@ with this body style to compute body/body and body/non-body interactions.
 The *rounded/polygon* body style represents body particles as a 2d
 polygon with a variable number of N vertices.  This style can only be
 used for 2d models; see the :doc:`boundary <boundary>` command.  See the
-"pair_style body/rounded/polygon" page for a diagram of two
-squares with rounded circles at the vertices.  Special cases for N = 1
-(circle) and N = 2 (rod with rounded ends) can also be specified.
+:doc:`pair_style body/rounded/polygon <pair_body_rounded_polygon>` page for
+a diagram of two squares with rounded circles at the vertices.  Special cases
+for N = 1 (circle) and N = 2 (rod with rounded ends) can also be specified.
 
 One use of this body style is for 2d discrete element models, as
 described in :ref:`Fraige <body-Fraige>`.

doc/src/Howto_cmake.rst

@@ -1,11 +1,11 @@
-Using CMake with LAMMPS tutorial
-================================
+Using CMake with LAMMPS
+=======================
 
 The support for building LAMMPS with CMake is a recent addition to
 LAMMPS thanks to the efforts of Christoph Junghans (LANL) and Richard
-Berger (Temple U).  One of the key strengths of CMake is that it is not
-tied to a specific platform or build system and thus generate the files
-necessary to build and develop for different build systems and on
+Berger (LANL).  One of the key strengths of CMake is that it is not
+tied to a specific platform or build system. Instead it generates the
+files necessary to build and develop for different build systems and on
 different platforms.  Note, that this applies to the build system itself
 not the LAMMPS code. In other words, without additional porting effort,
 it is not possible - for example - to compile LAMMPS with Visual C++ on
@@ -14,7 +14,7 @@ necessary to program LAMMPS as a project in integrated development
 environments (IDE) like Eclipse, Visual Studio, QtCreator, Xcode,
 CodeBlocks, Kate and others.
 
-A second important feature of CMake is, that it can detect and validate
+A second important feature of CMake is that it can detect and validate
 available libraries, optimal settings, available support tools and so
 on, so that by default LAMMPS will take advantage of available tools
 without requiring to provide the details about how to enable/integrate
@@ -32,8 +32,8 @@ program ``cmake`` (or ``cmake3``), a text mode interactive user
 interface (TUI) program ``ccmake`` (or ``ccmake3``), or a graphical user
 interface (GUI) program ``cmake-gui``.  All of them are portable
 software available on all supported platforms and can be used
-interchangeably.  The minimum supported CMake version is 3.10 (3.12 or
-later is recommended).
+interchangeably.  As of LAMMPS version 2 August 2023, the minimum
+required CMake version is 3.16.
 
 All details about features and settings for CMake are in the `CMake
 online documentation <https://cmake.org/documentation/>`_. We focus
@@ -43,11 +43,20 @@ Prerequisites
 -------------
 
 This tutorial assumes that you are operating in a command-line environment
-using a shell like Bash.
+using a shell like Bash or Zsh.
 
-- Linux: any Terminal window will work
-- macOS: launch the Terminal application.
-- Windows 10: install and run the :doc:`Windows Subsystem for Linux <Howto_wsl>`
+- Linux: any Terminal window will work or text console
+- macOS: launch the Terminal application
+- Windows 10 or 11: install and run the :doc:`Windows Subsystem for Linux <Howto_wsl>`
+- other Unix-like operating systems like FreeBSD
+
+.. note::
+
+   It is also possible to use CMake on Windows 10 or 11 through either the Microsoft
+   Visual Studio IDE with the bundled CMake or from the Windows command prompt using
+   a separately installed CMake package, both using the native Microsoft Visual C++
+   compilers and (optionally) the Microsoft MPI SDK.  This tutorial, however, only
+   covers unix-like command line interfaces.
 
 We also assume that you have downloaded and unpacked a recent LAMMPS source code package
 or used Git to create a clone of the LAMMPS sources on your compilation machine.
@@ -338,8 +347,6 @@ Some common LAMMPS specific variables
      - 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``
-   * - ``LAMMPS_EXCEPTIONS``
-     - when set to ``on`` errors will throw a C++ exception instead of aborting (default: ``off``)
    * - ``FFT``
      - select which FFT library to use: ``FFTW3``, ``MKL``, ``KISS`` (default, unless FFTW3 is found)
    * - ``FFT_SINGLE``
@@ -412,9 +419,9 @@ interface (``ccmake`` or ``cmake-gui``).
 
    Using a preset to select a compiler package (``clang.cmake``,
    ``gcc.cmake``, ``intel.cmake``, ``oneapi.cmake``, or ``pgi.cmake``)
-   are an exception to the mechanism of updating the configuration incrementally,
-   as they will trigger a reset of cached internal CMake settings and thus
-   reset settings to their default values.
+   are an exception to the mechanism of updating the configuration
+   incrementally, as they will trigger a reset of cached internal CMake
+   settings and thus reset settings to their default values.
 
 Compilation and build targets
 -----------------------------

doc/src/Howto_lammps_gui.rst

@@ -1,111 +1,310 @@
 Using the LAMMPS GUI
 ====================
 
-LAMMPS GUI is a simple graphical text editor that is linked to the
-:ref:`LAMMPS C-library interface <lammps_c_api>` and thus can run LAMMPS
-directly using the contents of the editor's text buffer as input.
-
-This is similar to what people traditionally would do to run LAMMPS:
-using a regular text editor to edit the input and run the necessary
-commands, possibly including the text editor, too, from a command line
-terminal window.  That is quite effective when running LAMMPS on
-high-performance computing facilities and when you are very proficient
-in using the command line.  The main benefit of a GUI application is
-that this integrates well with graphical desktop environments and many
-basic tasks can be done directly from within the GUI without switching
-to a text console or requiring external programs or scripts to extract
-data from the generated output.  This makes it easier for beginners to
-get started running simple LAMMPS simulations and thus very suitable for
-tutorials on LAMMPS.  But also makes it easier to switch to a full
-featured text editor and more sophisticated visualization and analysis
-tools.
+This document describes **LAMMPS GUI version 1.5**.
 
 -----
 
+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.
+
+.. note::
+
+   Pre-compiled, ready-to-use LAMMPS GUI executables for Linux (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.  They may be linked to a
+   development version of LAMMPS in case they need features not yet
+   available in a released version. Serial LAMMPS executables of the
+   same LAMMPS version are included as well.  The source code for the
+   LAMMPS GUI is included in the LAMMPS source code and can be found in
+   the ``tools/lammps-gui`` folder.  It can be compiled alongside LAMMPS
+   when :doc:`compiling with CMake <Build_cmake>`.
+
+LAMMPS GUI tries to provide an experience similar to what people
+traditionally would do to run LAMMPS using a command line window:
+
+- editing inputs with a text editor
+- run LAMMPS on the input with selected command line flags
+- and then use or extract data from the created files and visualize it
+
+That procedure is quite effective for people proficient in using the
+command line, as that allows them to use tools for the individual steps
+which they are most comfortable with.  It is often required when running
+LAMMPS on high-performance computing facilities.
+
+The main benefit of using the LAMMPS GUI application instead is that
+many basic tasks can be done directly from the GUI without switching to
+a text console window or using external programs, let alone writing
+scripts to extract data from the generated output.  It also integrates
+well with graphical desktop environments.
+
+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.  It
+is also designed to keep the barrier low when you decide to switch to a
+full featured, standalone programming editor and more sophisticated
+visualization and analysis tools and run LAMMPS from a command line.
+
 The following text provides a detailed tour of the features and
-functionality of the LAMMPS GUI.  This document describes LAMMPS GUI
-version 1.2.
+functionality of the 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.
+
+-----
 
 Main window
 -----------
 
-When LAMMPS GUI starts, it will show the main window with either an
-empty buffer, or have a file loaded. In the latter case it may look like
-the following:
+When LAMMPS GUI starts, it will show a main window with either an
+empty buffer or the contents of a loaded file. In the latter case it
+may look like the following:
 
 .. image:: JPG/lammps-gui-main.png
    :align: center
    :scale: 50%
 
-There is the menu bar at the top, then the main editor buffer with the
-input file contents in the center with line numbers on the left and the
-input colored according to the LAMMPS input file syntax.  At the bottom
-is the status bar, which shows the status of LAMMPS execution on the
-left ("Ready." when idle) and the current working directory on the
-right.  The size of the main window will be stored when exiting and
-restored when starting again.  The name of the current file in the
-buffer is shown in the window title and the text `*modified*` is added
-in case the buffer has modifications that are not yet saved to a file.
+There is the typical menu bar at the top, then the main editor buffer,
+and a status bar at the bottom.  The input file contents are shown
+with line numbers on the left and the input is colored according to
+the LAMMPS input file syntax.  The status bar shows the status of
+LAMMPS execution on the left (e.g. "Ready." when idle) and the current
+working directory on the right.  The name of the current file in the
+buffer is shown in the window title; the word `*modified*` is added if
+the buffer edits have not yet saved to a file.  The size of the main
+window will be stored when exiting and restored when starting again.
 
 Opening Files
 ^^^^^^^^^^^^^
 
 The LAMMPS GUI application will try to open the first command line
-argument as input file, further arguments are ignored.  When no
-argument is given LAMMPS GUI will start with an empty buffer.
-Files can also be opened via the ``File`` menu or by drag-and-drop
-of a file from a file manager to the editor window.  Only one
-file can be open at a time, so opening a new file with a filled
-buffer will close this buffer and in case the buffer has unsaved
-modifications will ask to either cancel the load, discard the
-changes or save them.
-
+argument as a LAMMPS input script, further arguments are ignored.
+When no argument is given, LAMMPS GUI will start with an empty buffer.
+Files can also be opened via the ``File`` menu or by drag-and-drop of
+a file from a graphical file manager into the editor window.  Only one
+file can be open at a time, so opening a new file with a filled buffer
+will close the buffer.  If the buffer has unsaved modifications, you
+will be asked to either cancel the operation, discard the changes, or
+save them.
 
 Running LAMMPS
 ^^^^^^^^^^^^^^
 
 From within the LAMMPS GUI main window LAMMPS can be started either from
-the ``Run`` menu, by the hotkey `Ctrl-Enter` (`Command-Enter` on macOS),
-or by clicking on the green button in the status bar.  LAMMPS runs in a
-separate thread, so the GUI stays responsive and thus it is able to
-interact with the calculation and access its data.  It is important to
-note, that LAMMPS is using the contents of the input buffer for the run,
-**not** the file it was read from. If there are unsaved changes in the
-buffer, they *will* be used.
+the ``Run`` menu using the ``Run LAMMPS from Editor Buffer`` entry, by
+the keyboard shortcut `Ctrl-Enter` (`Command-Enter` on macOS), or by
+clicking on the green "Run" button in the status bar.  All of these
+operations will cause LAMMPS to process the entire input script, which
+may contain multiple :doc:`run <run>` or :doc:`minimize <minimize>`
+commands.
+
+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
+: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
+alternative, it is also possible to run LAMMPS by reading the contents
+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.
 
 .. 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 will
-contain the selected number of threads, if thread-parallel acceleration
-was selected in the ``Preferences`` dialog.  On the right side, a
-progress bar is shown that displays the estimated progress on the
-current :doc:`run command <run>`.  Additionally, two windows will open:
-the log window with the captured screen output and the chart window with
-a line graph created from the thermodynamic output of the run.
+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
+will also show the number of active threads, if 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 command <run>`.
 
-The run can be stopped cleanly by using either the ``Stop LAMMPS`` entry
-in the ``Run`` menu, the hotkey `Ctrl-/` (`Command-/` on macOS), or
-clicking on the red button in the status bar.  This will cause that the
-running LAMMPS process will complete the current iteration and then
-stop.  This is equivalent to the command `timer timeout 0 <timer>` and
-implemented by calling the :cpp:func:`lammps_force_timeout()` function
-of the LAMMPS C-library interface.
+Also, the line number of the currently executed command will be
+highlighted in green.
 
+.. image:: JPG/lammps-gui-run-highlight.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 will be shown and the line of the input which triggered the
+error will be highlighted.  The state of LAMMPS in the status bar will
+be set to "Failed." instead of "Ready."
+
+.. image:: JPG/lammps-gui-run-error.png
+   :align: center
+   :scale: 75%
+
+Up to three additional windows will open during a run:
+
+- a log window with the captured screen output
+- a chart window with a line graph created from the thermodynamic output of the run
+- a slide show window with images created by a :doc:`dump image command <dump_image>`
+
+More information on those windows and how to adjust their behavior and
+contents is given below.
+
+An active LAMMPS run can be stopped cleanly by using either the ``Stop
+LAMMPS`` entry in the ``Run`` menu, the keyboard shortcut `Ctrl-/`
+(`Command-/` on macOS), or by clicking on the red button in the status
+bar.  This will cause the running LAMMPS process to complete the current
+timestep (or iteration for energy minimization) and then complete the
+processing of the buffer while skipping all run or minimize commands.
+This is equivalent to the input script command :doc:`timer timeout 0
+<timer>` and is implemented by calling the
+:cpp:func:`lammps_force_timeout()` function of the LAMMPS C-library
+interface.  Please see the corresponding documentation pages to
+understand the implications of this operation.
+
+Log Window
+----------
+
+By default, when starting a run, a "Log Window" will open that displays
+the current screen output of the LAMMPS calculation, that would normally
+be seen in the command line window, as shown below.
+
+.. image:: JPG/lammps-gui-log.png
+   :align: center
+   :scale: 50%
+
+LAMMPS GUI captures the screen output as it is generated and updates
+the log window regularly during a run.
+
+By default, the log window will be replaced each time a run is started.
+The runs are counted and the run number for the current run is displayed
+in the window title.  It is possible to change the behavior of LAMMPS
+GUI in the preferences dialog to create a *new* log window for every run
+or to not show the current log window.  It is also possible to show or
+hide the *current* log window from the ``View`` menu.
+
+The text in the log window is read-only and cannot be modified, but
+keyboard shortcuts to select and copy all or parts of the text can be
+used to transfer text to another program. Also, the keyboard shortcut
+`Ctrl-S` (`Command-S` on macOS) is available to save the log buffer to a
+file.  The "Select All" and "Copy" functions, as well as a "Save Log to
+File" option are also available from a context menu by clicking with the
+right mouse button into the log window text area.
+
+Chart Window
+------------
+
+By default, when starting a run, a "Chart Window" will open that
+displays a plot of thermodynamic output of the LAMMPS calculation as
+shown below.
+
+.. image:: JPG/lammps-gui-chart.png
+   :align: center
+   :scale: 50%
+
+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 will be updated with new
+data as the run progresses, so they can be used to visually monitor the
+evolution of available properties.  The window title will show the
+current run number that this chart window corresponds to.  Same as
+explained for the log window above, by default, the chart window will
+be replaced on each new run, but the behavior can be changed in the
+preferences dialog.
+
+From the ``File`` menu on the top left, it is possible to save an image
+of the currently displayed plot or export the data in either plain text
+columns (for use by plotting tools like `gnuplot
+<http://www.gnuplot.info/>`_ or `grace
+<https://plasma-gate.weizmann.ac.il/Grace/>`_), or as CSV data which can
+be imported for further processing with Microsoft Excel or `pandas
+<https://pandas.pydata.org/>`_
+
+Thermo output data from successive run commands in the input script will
+be combined into a single data set unless the format, number, or names
+of output columns are changed with a :doc:`thermo_style <thermo_style>`
+or a :doc:`thermo_modify <thermo_modify>` command, or the current time
+step is reset with :doc:`reset_timestep <reset_timestep>`, or if a
+:doc:`clear <clear>` command is issued.
+
+Image Slide Show
+----------------
+
+By default, if the LAMMPS input contains a :doc:`dump image
+<dump_image>` command, a "Slide Show" window will open which loads and
+displays the images created by LAMMPS as they are written.
+
+.. image:: JPG/lammps-gui-slideshow.png
+   :align: center
+   :scale: 50%
+
+The various buttons at the bottom right of the window allow single
+stepping through the sequence of images or playing an animation (as a
+continuous loop or once from first to last).  It is also possible to
+zoom in or zoom out of the displayed images, and to export the slide
+show animation to a movie file, if `ffmpeg <https://ffmpeg.org/>`_ is
+installed.
+
+Variable Info
+-------------
+
+During a run, it may be of interest to monitor the value of input script
+variables, for example to monitor the progress of loops.  This can be
+done by enabling the "Variables Window" in the ``View`` menu or by using
+the `Ctrl-Shift-W` keyboard shortcut.  This will show info similar to
+the :doc:`info variables <info>` command in a separate window as shown
+below.
+
+.. image:: JPG/lammps-gui-variable-info.png
+   :align: center
+   :scale: 75%
+
+Like the log and chart windows, its content is continuously updated
+during a run.  It will show "(none)" if there are no variables
+defined.  Note that it is also possible to *set* :doc:`index style
+variables <variable>`, that would normally be set via command line
+flags, via the "Set Variables..." dialog from the ``Run`` menu.
+LAMMPS GUI will automatically set the variable "gui_run" to the
+current value of the run counter.  That way it would be possible
+to automatically record a log for each run attempt by using the
+command
+
+.. code-block:: LAMMPS
+
+   log logfile-${gui_run}.txt
+
+at the beginning of an input file. That would record logs to files
+``logfile-1.txt``, ``logfile-2.txt``, and so on for successive runs.
 
 Viewing Snapshot Images
-^^^^^^^^^^^^^^^^^^^^^^^
+-----------------------
 
-By selecting the ``View Image`` entry in the ``Run`` menu, by hitting
-the `Ctrl-I` (`Command-I` on macOS) hotkey or by clicking on the
-"palette" button in the status bar, LAMMPS GUI will issue a
-:doc:`write_dump image <dump_image>` command and read the resulting
-snapshot image into an image viewer window.  When possible, LAMMPS
-GUI will try to detect which elements the atoms correspond to (via
-their mass) and then colorize them accordingly. Otherwise just some
-predefined sequence of colors are assigned to different atom types.
+By selecting the ``Create Image`` entry in the ``Run`` menu, or by
+hitting the `Ctrl-I` (`Command-I` on macOS) keyboard shortcut, or by
+clicking on the "palette" button in the status bar, LAMMPS GUI will send
+a custom :doc:`write_dump image <dump_image>` command to LAMMPS and read
+the resulting snapshot image with the current state of the system into
+an image viewer window.  This functionality is not available *during* an
+ongoing run.  When LAMMPS is not yet initialized, LAMMPS GUI will try to
+identify the line with the first run or minimize command and execute all
+command up to that line from the input buffer and then add a "run 0"
+command.  This will initialize the system so an image of the initial
+state of the system can be rendered.  If there was an error, the
+snapshot image viewer will not appear.
+
+When possible, LAMMPS GUI will try to detect which elements the atoms
+correspond to (via their mass) and then colorize them in the image
+accordingly.  Otherwise the default predefined sequence of colors is
+assigned to the different atom types.
 
 .. image:: JPG/lammps-gui-image.png
    :align: center
@@ -114,28 +313,68 @@ predefined sequence of colors are assigned to different atom types.
 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 rendering, anti-aliasing, view style,
-display of box or axes, zoom factor. The the image can be rotated
-horizontally and vertically and it is possible to only display the atoms
-within a predefined group (default is "all").  After each change, the
-image is rendered again and the display updated.  The small palette icon
-on the top left will be colored while LAMMPS is running to render the
-image and it will be grayed out again, when it is done.  When there are
-many items to show and high quality images with anti-aliasing are
-requested, re-rendering can take several seconds.  From the ``File``
-menu, the shown image can be saved to a file permanently or copied into
-the cut-n-paste buffer for pasting into another application.
-
+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").  After each change, the image is rendered again
+and the display updated.  The small palette icon on the top left will
+be colored while LAMMPS is running to render the new image; it will be
+grayed out when it 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 or copied into the
+cut-n-paste buffer for pasting into another application.
 
 Editor Functions
-^^^^^^^^^^^^^^^^
+----------------
 
-The editor has most the usual functionality that similar programs have:
-text selection via mouse or with cursor moves while holding the Shift
-key, Cut, Copy, Paste, Undo, Redo.  All of these editing functions are
-available via hotkeys.  When trying to exit the editor with a modified
-buffer, a dialog will pop up asking whether to cancel the quit, or don't
-save or save the buffer's contents to a file.
+The editor has most of the usual functionality that similar programs
+have: text selection via mouse or with cursor moves while holding the
+Shift key, Cut (`Ctrl-X`), Copy (`Ctrl-C`), Paste (`Ctrl-V`), Undo
+(`Ctrl-Z`), Redo (`Ctrl-Shift-Z`), Select All (`Ctrl-A`).  When trying
+to exit the editor with a modified buffer, a dialog will pop up asking
+whether to cancel the exit operation, or to save or not save the buffer
+contents to a file.
+
+Context Specific Word Completion
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+By default, LAMMPS GUI will display a small pop-up frame with possible
+choices for LAMMPS input script commands or styles after 2 characters of
+a word have been typed.
+
+.. image:: JPG/lammps-gui-complete.png
+   :align: center
+   :scale: 75%
+
+The word can then be completed through selecting an entry by scrolling
+up and down with the cursor keys and selecting with the 'Enter' key or
+by clicking on the entry with the mouse.  The automatic completion
+pop-up can be disabled in the ``Preferences`` dialog, but the completion
+can still be requested manually by either hitting the 'Shift-TAB' key or
+by right-clicking with the mouse and selecting the option from the
+context menu.  Most of the completion information is taken from the
+LAMMPS instance and thus it will be adjusted to only show available
+options that have been enabled while compiling LAMMPS. That, however,
+excludes accelerated styles and commands; for improved clarity, only the
+non-suffix version of styles are shown.
+
+Line Reformatting
+^^^^^^^^^^^^^^^^^
+
+The editor supports reformatting lines according to the syntax in order
+to have consistently aligned lines.  This primarily means adding
+whitespace padding to commands, type specifiers, IDs and names.  This
+reformatting is performed by default when hitting the 'Enter' key to
+start a new line.  This feature can be turned on or off in the
+``Preferences`` dialog, but it can still be manually performed by
+hitting the 'TAB' key.  The amount of padding can also be changed in the
+``Preferences`` dialog.
+
+Internally this functionality is achieved by splitting the line into
+"words" and then putting it back together with padding added where the
+context can be detected; otherwise a single space is used between words.
 
 Context Specific Help
 ^^^^^^^^^^^^^^^^^^^^^
@@ -145,22 +384,23 @@ Context Specific Help
    :scale: 50%
 
 A unique feature of the LAMMPS GUI is the option to look up the
-documentation for the command in the current line.  This can be achieved
-by either clicking the right mouse button or by using the `Ctrl-?`
-hotkey.  When clicking the mouse there are additional entries in the
+documentation for the command in the current line.  This can be done by
+either clicking the right mouse button or by using the `Ctrl-?` keyboard
+shortcut.  When clicking the mouse there are additional entries in the
 context menu that will open the corresponding documentation page in the
-online LAMMPS documentation.  When using the hotkey, the first of those
-entries will be chosen directly.
+online LAMMPS documentation.  When using the keyboard, the first of
+those entries will be chosen directly.
 
 Menu
 ----
 
-The menu bar the entries ``File``, ``Edit``, ``Run``, ``View``, and ``About``.
-Instead of using the mouse to click on them, the individual menus can also
-be activated by hitting the `Alt` key together with the corresponding underlined
-letter, that is `Alt-f` will activate the ``File`` menu.  For the corresponding
-activated sub-menus, also the underlined letter, together with the `Alt` key can
-be used to select instead of the mouse.
+The menu bar has entries ``File``, ``Edit``, ``Run``, ``View``, and
+``About``.  Instead of using the mouse to click on them, the individual
+menus can also be activated by hitting the `Alt` key together with the
+corresponding underlined letter, that is `Alt-F` will activate the
+``File`` menu.  For the corresponding activated sub-menus, the key
+corresponding the underlined letters can again be used to select entries
+instead of using the mouse.
 
 File
 ^^^^
@@ -174,104 +414,121 @@ The ``File`` menu offers the usual options:
 - ``Save As`` will open a dialog to select and new file name and save
   the buffer to it
 - ``Quit`` will exit LAMMPS GUI. If there are unsaved changes, a dialog
-  will appear to either cancel the quit, save or don't save the file.
+  will appear to either cancel the operation, or to save or not save the
+  edited file.
 
-In addition, up to 5 recent file names will be listed after the ``Open``
-entry that allows to re-open recent files. This list is stored when
-quitting and recovered when starting again.
+In addition, up to 5 recent file names will be listed after the
+``Open`` entry that allows re-opening recent files.  This list is
+stored when quitting and recovered when starting again.
 
 Edit
 ^^^^
 
 The ``Edit`` menu offers the usual editor functions like ``Undo``,
-``Redo``, ``Cut``, ``Copy``, ``Paste``, but also offers to open the
-``Preferences`` dialog and to delete all stored preferences so they
-will be reset to their defaults.
+``Redo``, ``Cut``, ``Copy``, ``Paste``.  It can also open a
+``Preferences`` dialog (keyboard shortcut `Ctrl-P`) and allows deletion
+of all stored preferences so they will be reset to default values.
 
 Run
 ^^^
 
-The ``Run`` menu allows to start and stop a LAMMPS process.  Rather than
-calling the LAMMPS executable as a separate executable, the LAMMPS GUI
-is linked to the LAMMPS library and thus can run LAMMPS internally
-through the :ref:`LAMMPS C-library interface <lammps_c_api>`.
+The ``Run`` menu has options to start and stop a LAMMPS process.
+Rather than calling the LAMMPS executable as a separate executable,
+the LAMMPS GUI is linked to the LAMMPS library and thus can run LAMMPS
+internally through the :ref:`LAMMPS C-library interface
+<lammps_c_api>`.
+
 Specifically, a LAMMPS instance will be created by calling
-:cpp:func:`lammps_open_no_mpi` and then the buffer contents run by
+:cpp:func:`lammps_open_no_mpi`.  The buffer contents then executed by
 calling :cpp:func:`lammps_commands_string`.  Certain commands and
-features are only available, after a LAMMPS instance is created.  Its
-presence is indicated by a small LAMMPS ``L`` logo in the status bar at
-the bottom left of the main window.
+features are only available after a LAMMPS instance is created.  Its
+presence is indicated by a small LAMMPS ``L`` logo in the status bar
+at the bottom left of the main window.  As an alternative, it is also
+possible to run LAMMPS using the contents of the edited file by
+reading the file.  This is mainly provided as a fallback option in
+case the input uses some feature that is not available when running
+from a string buffer.
 
 The LAMMPS calculation will be run in a concurrent thread so that the
-GUI will stay responsive and will be updated during the run.  This can
-be used to tell the running LAMMPS instance to stop at the next
-timestep.  The ``Stop LAMMPS`` entry will do this by calling
+GUI can stay responsive and be updated during the run.  This can be
+used to tell the running LAMMPS instance to stop at the next timestep.
+The ``Stop LAMMPS`` entry will do this by calling
 :cpp:func:`lammps_force_timeout`, which is equivalent to a :doc:`timer
 timeout 0 <timer>` command.
 
-The ``Set Variables`` entry will open a dialog box where :doc:`index style variables <variable>`
-can be set. Those variables will be passed to the LAMMPS instance when
-it is created and are thus set *before* a run is started.
+The ``Set Variables...`` entry will open a dialog box where
+:doc:`index style variables <variable>` can be set. Those variables
+will be passed to the LAMMPS instance when it is created and are thus
+set *before* a run is started.
 
 .. image:: JPG/lammps-gui-variables.png
    :align: center
    :scale: 75%
 
-The ``Set Variables`` dialog will be pre-populated with entries that are
-set as index variables in the input and any variables that are used but
-not defined as far as the built-in parser can detect them.  New rows for
-additional variables can be added through the ``Add Row`` button and
-existing rows deleted by clicking on the ``X`` icons on the right.
+The ``Set Variables`` dialog will be pre-populated with entries that
+are set as index variables in the input and any variables that are
+used but not defined, if the built-in parser can detect them.  New
+rows for additional variables can be added through the ``Add Row``
+button and existing rows can be deleted by clicking on the ``X`` icons
+on the right.
 
-The ``View Image`` entry will send a :doc:`dump image <dump_image>`
-command to the LAMMPS instance, read the resulting file, and show it in
-an ``Image Viewer`` window.
+The ``Create Image`` entry will send a :doc:`dump image <dump_image>`
+command to the LAMMPS instance, read the resulting file, and show it
+in an ``Image Viewer`` window.
 
 The ``View in OVITO`` entry will launch `OVITO <https://ovito.org>`_
-with a :doc:`data file <write_data>` of the current state of the system.
-This option is only available, if the LAMMPS GUI can find the OVITO
-executable in the system path.
+with a :doc:`data file <write_data>` containing the current state of
+the system.  This option is only available if the LAMMPS GUI can find
+the OVITO executable in the system path.
 
-The ``View in VMD`` entry will instead launch VMD, also to load a
-:doc:`data file <write_data>` of the current state of the system.  This
-option is only available, if the LAMMPS GUI can find the VMD executable
-in the system path.
+The ``View in VMD`` entry will launch VMD with a :doc:`data file
+<write_data>` containing the current state of the system.  This option
+is only available if the LAMMPS GUI can find the VMD executable in the
+system path.
 
 View
 ^^^^
 
-The ``View`` menu offers to show or hide the three optional windows
-with log output, graphs, or images.  The default settings for those
-can be changed in the ``Preferences dialog``.
+The ``View`` menu offers to show or hide additional windows with log
+output, charts, slide show, variables, or snapshot images.  The
+default settings for their visibility can be changed in the
+``Preferences dialog``.
 
 About
 ^^^^^
 
 The ``About`` menu finally offers a couple of dialog windows and an
-option to launch the LAMMPS online documentation in a web browser.  The
-``About LAMMPS GUI`` entry displays a dialog with a summary of the
+option to launch the LAMMPS online documentation in a web browser.
+The ``About LAMMPS`` entry displays a dialog with a summary of the
 configuration settings of the LAMMPS library in use and the version
-number of LAMMPS GUI itself.  The ``Quick Help`` displays a dialog with
-a minimal description of LAMMPS GUI.  And ``LAMMPS Manual`` will open
-the main page of this LAMMPS documentation at https://docs.lammps.org/.
+number of LAMMPS GUI itself.  The ``Quick Help`` displays a dialog
+with a minimal description of LAMMPS GUI.  The ``LAMMPS GUI Howto``
+entry will open this documentation page from the online documentation
+in a web browser window.  The ``LAMMPS Manual`` entry will open the
+main page of the LAMMPS documentation in the web browser.
+
+-----
 
 Preferences
 -----------
 
-The ``Preferences`` dialog allows to customize some of the behavior
-and looks of the LAMMPS GUI application.  The settings are grouped
-and each group is displayed within a tab.
+The ``Preferences`` dialog allows customization of the behavior and
+look of the LAMMPS GUI application.  The settings are grouped and each
+group is displayed within a tab.
 
 .. |guiprefs1| image:: JPG/lammps-gui-prefs-general.png
-   :width: 25%
+   :width: 24%
 
 .. |guiprefs2| image:: JPG/lammps-gui-prefs-accel.png
-   :width: 25%
+   :width: 24%
 
 .. |guiprefs3| image:: JPG/lammps-gui-prefs-image.png
-   :width: 25%
+   :width: 24%
 
-|guiprefs1|  |guiprefs2|  |guiprefs3|
+.. |guiprefs4| image:: JPG/lammps-gui-prefs-editor.png
+   :width: 24%
+
+|guiprefs1|  |guiprefs2|  |guiprefs3|  |guiprefs4|
 
 General Settings:
 ^^^^^^^^^^^^^^^^^
@@ -279,7 +536,7 @@ General Settings:
 - *Echo input to log:* when checked, all input commands, including
   variable expansions, will be echoed to the log window. This is
   equivalent to using `-echo screen` at the command line.  There is no
-  log *file* produced since it always uses `-log none`.
+  log *file* produced by default, since LAMMPS GUI uses `-log none`.
 - *Include citation details:* when checked full citation info will be
   included to the log window.  This is equivalent to using `-cite
   screen` on the command line.
@@ -288,6 +545,9 @@ General Settings:
 - *Show chart window by default:* when checked, the thermodynamic
   output of a LAMMPS run will be collected and displayed in a chart
   window as line graphs.
+- *Show slide show window by default:* when checked, a slide show
+  window will be shown with images from a dump image command, if
+  present, in the LAMMPS input.
 - *Replace log window on new run:* when checked, an existing log
   window will be replaced on a new LAMMPS run, otherwise each run will
   create a new log window.
@@ -297,7 +557,7 @@ 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 options is only available
+- *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
@@ -309,94 +569,132 @@ General Settings:
   log) of the application can be set.
 - *Select Text Font:* Opens a font selection dialog where the type and
   size for the text editor and log font of the application can be set.
+- *GUI update interval:* Allows to set the time interval between GUI
+  and data updates during a LAMMPS run in milliseconds. The default is
+  to update the GUI every 100 milliseconds. This is good for most cases.
+  For LAMMPS runs that run very fast, however, data may be missed and
+  through lowering this interval, this can be corrected. However, this
+  will make the GUI use more resources, which may be a problem on some
+  computers with slower CPUs. The default value is 100 milliseconds.
 
 Accelerators:
 ^^^^^^^^^^^^^
 
-This tab enables to select which accelerator package is used 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 to set the maximum
-number of threads for the accelerator packages that use threads.
+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.
 
 Snapshot Image:
 ^^^^^^^^^^^^^^^
 
-This tab allows to set some defaults for the snapshot images displayed
-in the ``Image Viewer`` window, like its dimensions and the zoom factor
-applied.  The *Antialias* switch requests to render images with twice
-the number of pixels for width and height and then smoothly scales the
+This tab allows setting defaults for the snapshot images displayed in
+the ``Image Viewer`` window, such as its dimensions and the zoom
+factor applied.  The *Antialias* switch will render images with twice
+the number of pixels for width and height and then smoothly scale the
 image back to the requested size.  This produces higher quality images
-with smoother edges at the expense of requiring more CPU time to render
-the image.  The *HQ Image mode* option turns on using a screen space
-ambient occlusion mode (SSAO) when rendering images.  This is also more
-time consuming, but produces a more 'spatial' representation of the
-system.  The *VDW Style* checkbox selects whether atoms are represented
-by space filling spheres when checked or by smaller spheres and stick.
-Finally there are a couple of drop down lists to select the background
-and box color.
+with smoother edges at the expense of requiring more CPU time to
+render the image.  The *HQ Image mode* option turns on screen space
+ambient occlusion (SSAO) mode when rendering images.  This is also
+more time consuming, but produces a more 'spatial' representation of
+the system shading of atoms by their depth.  The *VDW Style* checkbox
+selects whether atoms are represented by space filling spheres when
+checked or by smaller spheres and sticks.  Finally there are a couple
+of drop down lists to select the background and box colors.
 
+Editor Settings:
+^^^^^^^^^^^^^^^^
 
-Hotkeys
--------
+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
+the range between 1 and 32.
 
-Almost all functionality is accessible from the menu or via hotkeys.
-The following hotkeys are available (On macOS use the Command key
-instead of Ctrl/Control).
+The two settings which follow enable or disable the automatic
+reformatting when hitting the 'Enter' key and the automatic display of
+the completion pop-up window.
+
+-----------
+
+Keyboard Shortcuts
+------------------
+
+Almost all functionality is accessible from the menu of the editor
+window or through keyboard shortcuts.  The following shortcuts are
+available (On macOS use the Command key instead of Ctrl/Control).
 
 .. list-table::
    :header-rows: 1
    :widths: auto
 
-   * - Hotkey
+   * - Shortcut
      - Function
-     - Hotkey
+     - Shortcut
      - Function
-     - Hotkey
-     - Function
-     - Hotkey
+     - Shortcut
      - Function
    * - Ctrl+N
      - New File
      - Ctrl+Z
      - Undo edit
      - Ctrl+Enter
-     - Run LAMMPS
-     - Ctrl+Shift+A
-     - About LAMMPS GUI
+     - Run Input
    * - Ctrl+O
      - Open File
      - Ctrl+Shift+Z
      - Redo edit
      - Ctrl+/
      - Stop Active Run
-     - Ctrl+Shift+H
-     - Quick Help
-   * - CTRL+S
+   * - Ctrl+S
      - Save File
      - Ctrl+C
      - Copy text
      - Ctrl+Shift+V
      - Set Variables
-     - Ctrl+Shift+G
-     - LAMMPS GUI Howto
    * - Ctrl+Shift+S
      - Save File As
      - Ctrl+X
      - Cut text
      - Ctrl+I
-     - Create Snapshot Image
-     - Ctrl+Shift+M
-     - LAMMPS Manual
+     - Snapshot Image
    * - Ctrl+Q
-     - Quit
+     - Quit Application
      - Ctrl+V
      - Paste text
+     - Ctrl+L
+     - Slide Show
+   * - Ctrl+W
+     - Close Window
+     - Ctrl+A
+     - Select All
      - Ctrl+P
      - Preferences
+   * - Ctrl+Shift+A
+     - About LAMMPS
+     - Ctrl+Shift+H
+     - Quick Help
+     - Ctrl+Shift+G
+     - LAMMPS GUI Howto
+   * - Ctrl+Shift+M
+     - LAMMPS Manual
      - Ctrl+?
      - Context Help
+     - Ctrl+Shift+W
+     - Show Variables
+   * - Ctrl+Shift+Enter
+     - Run File
+     - TAB
+     - Reformat line
+     - Shift+TAB
+     - Show Completions
 
 Further editing keybindings `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.

doc/src/Howto_output.rst

@@ -1,7 +1,7 @@
 Output from LAMMPS (thermo, dumps, computes, fixes, variables)
 ==============================================================
 
-There are four basic kinds of LAMMPS output:
+There are four basic forms of LAMMPS output:
 
 * :doc:`Thermodynamic output <thermo_style>`, which is a list of
   quantities printed every few timesteps to the screen and logfile.
@@ -20,18 +20,17 @@ output files, depending on what :doc:`dump <dump>` and :doc:`fix <fix>`
 commands you specify.
 
 As discussed below, LAMMPS gives you a variety of ways to determine
-what quantities are computed and printed when the thermodynamics,
+what quantities are calculated and printed when the thermodynamics,
 dump, or fix commands listed above perform output.  Throughout this
 discussion, note that users can also :doc:`add their own computes and
-fixes to LAMMPS <Modify>` which can then generate values that can then
-be output with these commands.
+fixes to LAMMPS <Modify>` which can generate values that can then be
+output with these commands.
 
 The following subsections discuss different LAMMPS commands related
 to output and the kind of data they operate on and produce:
 
 * :ref:`Global/per-atom/local/per-grid data <global>`
 * :ref:`Scalar/vector/array data <scalar>`
-* :ref:`Per-grid data <grid>`
 * :ref:`Disambiguation <disambiguation>`
 * :ref:`Thermodynamic output <thermo>`
 * :ref:`Dump file output <dump>`
@@ -48,34 +47,65 @@ to output and the kind of data they operate on and produce:
 Global/per-atom/local/per-grid data
 -----------------------------------
 
-Various output-related commands work with four different styles of
+Various output-related commands work with four different "styles" of
 data: global, per-atom, local, and per-grid.  A global datum is one or
 more system-wide values, e.g. the temperature of the system.  A
 per-atom datum is one or more values per atom, e.g. the kinetic energy
 of each atom.  Local datums are calculated by each processor based on
-the atoms it owns, but there may be zero or more per atom, e.g. a list
+the atoms it owns, and there may be zero or more per atom, e.g. a list
 of bond distances.
 
 A per-grid datum is one or more values per grid cell, for a grid which
-overlays the simulation domain.  The grid cells and the data they
-store are distributed across processors; each processor owns the grid
-cells whose center point falls within its subdomain.
+overlays the simulation domain.  Similar to atoms and per-atom data,
+the grid cells and the data they store are distributed across
+processors; each processor owns the grid cells whose center points
+fall within its subdomain.
 
 .. _scalar:
 
 Scalar/vector/array data
 ------------------------
 
-Global, per-atom, and local datums can come in three kinds: a single
-scalar value, a vector of values, or a 2d array of values.  The doc
-page for a "compute" or "fix" or "variable" that generates data will
-specify both the style and kind of data it produces, e.g. a per-atom
-vector.
+Global, per-atom, local, and per-grid datums can come in three
+"kinds": a single scalar value, a vector of values, or a 2d array of
+values.  More specifically these are the valid kinds for each style:
 
-When a quantity is accessed, as in many of the output commands
-discussed below, it can be referenced via the following bracket
-notation, where ID in this case is the ID of a compute.  The leading
-"c\_" would be replaced by "f\_" for a fix, or "v\_" for a variable:
+* global scalar
+* global vector
+* global array
+* per-atom vector
+* per-atom array
+* local vector
+* local array
+* per-grid vector
+* per-grid array
+
+A per-atom vector means a single value per atom; the "vector" is the
+length of the number of atoms.  A per-atom array means multiple values
+per atom.  Similarly a local vector or array means one or multiple
+values per entity (e.g. per bond in the system).  And a per-grid
+vector or array means one or multiple values per grid cell.
+
+The doc page for a compute or fix or variable that generates data will
+specify both the styles and kinds of data it produces, e.g. a per-atom
+vector.  Note that a compute or fix may generate multiple styles and
+kinds of output.  However, for per-atom data only a vector or array is
+output, never both.  Likewise for per-local and per-grid data.  An
+example of a fix which generates multiple styles and kinds of data is
+the :doc:`fix mdi/qm <fix_mdi_qm>` command.  It outputs a global
+scalar, global vector, and per-atom array for the quantum mechanical
+energy and virial of the system and forces on each atom.
+
+By contrast, different variable styles generate only a single kind of
+data: a global scalar for an equal-style variable, global vector for a
+vector-style variable, and a per-atom vector for an atom-style
+variable.
+
+When data is accessed by another command, as in many of the output
+commands discussed below, it can be referenced via the following
+bracket notation, where ID in this case is the ID of a compute.  The
+leading "c\_" would be replaced by "f\_" for a fix, or "v\_" for a
+variable (and ID would be the name of the variable):
 
 +-------------+--------------------------------------------+
 | c_ID        | entire scalar, vector, or array            |
@@ -85,40 +115,56 @@ notation, where ID in this case is the ID of a compute.  The leading
 | c_ID[I][J]  | one element of array                       |
 +-------------+--------------------------------------------+
 
-In other words, using one bracket reduces the dimension of the data
-once (vector -> scalar, array -> vector).  Using two brackets reduces
-the dimension twice (array -> scalar).  Thus a command that uses
-scalar values as input can typically also process elements of a vector
-or array.
+Note that using one bracket reduces the dimension of the data once
+(vector -> scalar, array -> vector).  Using two brackets reduces the
+dimension twice (array -> scalar).  Thus a command that uses scalar
+values as input can also conceptually operate on an element of a
+vector or array.
 
-.. _grid:
-
-Per-grid data
-------------------------
-
-Per-grid data can come in two kinds: a vector of values (one per grid
-cekk), or a 2d array of values (multiple values per grid ckk).  The
-doc page for a "compute" or "fix" that generates data will specify
-names for both the grid(s) and datum(s) it produces, e.g. per-grid
-vectors or arrays, which can be referenced by other commands.  See the
-:doc:`Howto grid <Howto_grid>` doc page for more details.
+Per-grid vectors or arrays are accessed similarly, except that the ID
+for the compute or fix includes a grid name and a data name.  This is
+because a fix or compute can create multiple grids (of different
+sizes) and multiple sets of data (for each grid).  The fix or compute
+defines names for each grid and for each data set, so that all of them
+can be accessed by other commands.  See the :doc:`Howto grid
+<Howto_grid>` doc page for more details.
 
 .. _disambiguation:
 
 Disambiguation
 --------------
 
-Some computes and fixes produce data in multiple styles, e.g. a global
-scalar and a per-atom vector. Usually the context in which the input
-script references the data determines which style is meant. Example:
-if a compute provides both a global scalar and a per-atom vector, the
-former will be accessed by using ``c_ID`` in an equal-style variable,
-while the latter will be accessed by using ``c_ID`` in an atom-style
-variable.  Note that atom-style variable formulas can also access
-global scalars, but in this case it is not possible to do this
-directly because of the ambiguity.  Instead, an equal-style variable
-can be defined which accesses the global scalar, and that variable can
-be used in the atom-style variable formula in place of ``c_ID``.
+When a compute or fix produces data in multiple styles, e.g. global
+and per-atom, a reference to the data can sometimes be ambiguous.
+Usually the context in which the input script references the data
+determines which style is meant.
+
+For example, if a compute outputs a global vector and a per-atom
+array, an element of the global vector will be accessed by using
+``c_ID[I]`` in :doc:`thermodynamic output <thermo_style>`, while a
+column of the per-atom array will be accessed by using ``c_ID[I]`` in
+a :doc:`dump custom <dump>` command.
+
+However, if a :doc:`atom-style variable <variable>` references
+``c_ID[I]``, then it could be intended to refer to a single element of
+the global vector or a column of the per-atom array.  The doc page for
+any command that has a potential ambiguity (variables are the most
+common) will explain how to resolve the ambiguity.
+
+In this case, an atom-style variables references per-atom data if it
+exists.  If access to an element of a global vector is needed (as in
+this example), an equal-style variable which references the value can
+be defined and used in the atom-style variable formula instead.
+
+Similarly, :doc:`thermodynamic output <thermo_style>` can only
+reference global data from a compute or fix.  But you can indirectly
+access per-atom data as follows.  The reference ``c_ID[245][2]`` for
+the ID of a :doc:`compute displace/atom <compute_displace_atom>`
+command, refers to the y-component of displacement for the atom with
+ID 245.  While you cannot use that reference directly in the
+:doc:`thermo_style <thermo_style>` command, you can use it an
+equal-style variable formula, and then reference the variable in
+thermodynamic output.
 
 .. _thermo:
 
@@ -389,7 +435,7 @@ output and input data types must match, e.g. global/per-atom/local
 data and scalar/vector/array data.
 
 Also note that, as described above, when a command takes a scalar as
-input, that could be an element of a vector or array.  Likewise a
+input, that could also be an element of a vector or array.  Likewise a
 vector input could be a column of an array.
 
 +--------------------------------------------------------+----------------------------------------------+----------------------------------------------------+

doc/src/Howto_pylammps.rst

@@ -53,10 +53,10 @@ System-wide Installation
 Step 1: Building LAMMPS as a shared library
 """""""""""""""""""""""""""""""""""""""""""
 
-To use LAMMPS inside of Python it has to be compiled as shared library. This
-library is then loaded by the Python interface. In this example we enable the
-MOLECULE package and compile LAMMPS with C++ exceptions, PNG, JPEG and FFMPEG
-output support enabled.
+To use LAMMPS inside of Python it has to be compiled as shared
+library. This library is then loaded by the Python interface. In this
+example we enable the MOLECULE package and compile LAMMPS with PNG, JPEG
+and FFMPEG output support enabled.
 
 Step 1a: For the CMake based build system, the steps are:
 
@@ -66,7 +66,7 @@ Step 1a: For the CMake based build system, the steps are:
    cd  $LAMMPS_DIR/build-shared
 
    # MPI, PNG, Jpeg, FFMPEG are auto-detected
-   cmake ../cmake -DPKG_MOLECULE=yes -DLAMMPS_EXCEPTIONS=yes -DBUILD_LIB=yes -DBUILD_SHARED_LIBS=yes
+   cmake ../cmake -DPKG_MOLECULE=yes -DBUILD_LIB=yes -DBUILD_SHARED_LIBS=yes
    make
 
 Step 1b: For the legacy, make based build system, the steps are:
@@ -79,7 +79,7 @@ Step 1b: For the legacy, make based build system, the steps are:
    make yes-MOLECULE
 
    # compile shared library using Makefile
-   make mpi mode=shlib LMP_INC="-DLAMMPS_PNG -DLAMMPS_JPEG -DLAMMPS_FFMPEG -DLAMMPS_EXCEPTIONS" JPG_LIB="-lpng -ljpeg"
+   make mpi mode=shlib LMP_INC="-DLAMMPS_PNG -DLAMMPS_JPEG -DLAMMPS_FFMPEG" JPG_LIB="-lpng -ljpeg"
 
 Step 2: Installing the LAMMPS Python package
 """"""""""""""""""""""""""""""""""""""""""""
@@ -133,7 +133,7 @@ to the location in the virtual environment with:
 
 .. code-block:: bash
 
-   cmake . -DPYTHON_EXECUTABLE=$(which python)
+   cmake . -DPython_EXECUTABLE=$(which python)
 
    # install LAMMPS package in virtualenv
    (testing) make install-python
@@ -356,18 +356,16 @@ Together with matplotlib plotting data out of LAMMPS becomes simple:
 Error handling with PyLammps
 ----------------------------
 
-Compiling the shared library with C++ exception support provides a better error
-handling experience.  Without exceptions the LAMMPS code will terminate the
-current Python process with an error message.  C++ exceptions allow capturing
-them on the C++ side and rethrowing them on the Python side. This way you
-can handle LAMMPS errors through the Python exception handling mechanism.
+Using C++ exceptions in LAMMPS for errors allows capturing them on the
+C++ side and rethrowing them on the Python side.  This way you can handle
+LAMMPS errors through the Python exception handling mechanism.
 
 .. warning::
 
    Capturing a LAMMPS exception in Python can still mean that the
-   current LAMMPS process is in an illegal state and must be terminated. It is
-   advised to save your data and terminate the Python instance as quickly as
-   possible.
+   current LAMMPS process is in an illegal state and must be
+   terminated. It is advised to save your data and terminate the Python
+   instance as quickly as possible.
 
 Using PyLammps in IPython notebooks and Jupyter
 -----------------------------------------------

doc/src/Howto_structured_data.rst

@@ -119,6 +119,45 @@ for example :doc:`dump yaml <dump>` or :doc:`fix ave/time <fix_ave_time>`
 Depending on the kind of data being written, organization of the data
 or the specific syntax used may change, but the principles are very
 similar and all files should be readable with a suitable YAML parser.
+A simple example for this is given below:
+
+.. code-block:: python
+
+   import yaml
+   try:
+       from yaml import CSafeLoader as YamlLoader
+   except ImportError:
+       from yaml import SafeLoader as YamlLoader
+
+   timesteps = []
+   with open("dump.yaml", "r") as f:
+       data = yaml.load_all(f, Loader=YamlLoader)
+
+       for d in data:
+           print('Processing timestep %d' % d['timestep'])
+           timesteps.append(d)
+
+   print('Read %d timesteps from yaml dump' % len(timesteps))
+   print('Second timestep: ', timesteps[1]['timestep'])
+   print('Box info: x: ' , timesteps[1]['box'][0], ' y:', timesteps[1]['box'][1], ' z:',timesteps[1]['box'][2])
+   print('First 5 per-atom columns: ', timesteps[1]['keywords'][0:5])
+   print('Corresponding 10th atom data: ', timesteps[1]['data'][9][0:5])
+
+The corresponding output for a YAML dump command added to the "melt" example is:
+
+.. parsed-literal::
+
+   Processing timestep 0
+   Processing timestep 50
+   Processing timestep 100
+   Processing timestep 150
+   Processing timestep 200
+   Processing timestep 250
+   Read 6 timesteps from yaml dump
+   Second timestep:  50
+   Box info: x:  [0, 16.795961913825074]  y: [0, 16.795961913825074]  z: [0, 16.795961913825074]
+   First 5 per-atom columns:  ['id', 'type', 'x', 'y', 'z']
+   Corresponding 10th atom data:  [10, 1, 4.43828, 0.968481, 0.108555]
 
 Processing scalar data with Python
 ----------------------------------

doc/src/Howto_triclinic.rst

@@ -12,7 +12,8 @@ is created, e.g. by the :doc:`create_box <create_box>` or
 :doc:`read_data <read_data>` or :doc:`read_restart <read_restart>`
 commands.  Additionally, LAMMPS defines box size parameters lx,ly,lz
 where lx = xhi-xlo, and similarly in the y and z dimensions.  The 6
-parameters, as well as lx,ly,lz, can be output via the :doc:`thermo_style custom <thermo_style>` command.
+parameters, as well as lx,ly,lz, can be output via the
+:doc:`thermo_style custom <thermo_style>` command.
 
 LAMMPS also allows simulations to be performed in triclinic
 (non-orthogonal) simulation boxes shaped as a parallelepiped with

doc/src/Install_mac.rst

@@ -5,7 +5,7 @@ LAMMPS can be downloaded, built, and configured for macOS with `Homebrew
 <homebrew_>`_.  (Alternatively, see the installation instructions for
 :doc:`downloading an executable via Conda <Install_conda>`.)  The
 following LAMMPS packages are unavailable at this time because of
-additional requirements not yet met: GPU, KOKKOS, MSCG, MPIIO, POEMS,
+additional requirements not yet met: GPU, KOKKOS, MSCG, POEMS,
 VORONOI.
 
 After installing Homebrew, you can install LAMMPS on your system with

doc/src/Install_windows.rst

@@ -18,11 +18,10 @@ needed to run in parallel with MPI.
 
 The LAMMPS binaries contain *all* :doc:`optional packages <Packages>`
 included in the source distribution except: ADIOS, H5MD, KIM, ML-PACE,
-ML-QUIP, MSCG, NETCDF, PLUMED, QMMM, SCAFACOS, and VTK.  The serial
-version also does not include the MPIIO and LATBOLTZ packages.  The
-PYTHON package is only available in the Python installers that bundle a
-Python runtime.  The GPU package is compiled for OpenCL with mixed
-precision kernels.
+ML-QUIP, MSCG, NETCDF, QMMM, SCAFACOS, and VTK.  The serial version also
+does not include the LATBOLTZ package.  The PYTHON package is only
+available in the Python installers that bundle a Python runtime.  The
+GPU package is compiled for OpenCL with mixed precision kernels.
 
 The LAMMPS library is compiled as a shared library and the
 :doc:`LAMMPS Python module <Python_module>` is installed, so that

doc/src/Intro_nonfeatures.rst

@@ -5,7 +5,7 @@ LAMMPS is designed to be a fast, parallel engine for molecular
 dynamics (MD) simulations.  It provides only a modest amount of
 functionality for setting up simulations and analyzing their output.
 
-Specifically, LAMMPS was not conceived and designed for:
+Originally, LAMMPS was not conceived and designed for:
 
 * being run through a GUI
 * building molecular systems, or building molecular topologies
@@ -14,9 +14,10 @@ Specifically, LAMMPS was not conceived and designed for:
 * visualize your MD simulation interactively
 * plot your output data
 
-Over the years some of these limitations have been reduced or
-removed, through features added to LAMMPS or external tools
-that either closely interface with LAMMPS or extend LAMMPS.
+Over the years many of these limitations have been reduced or
+removed. In part through features added to LAMMPS and in part
+through external tools that either closely interface with LAMMPS
+or extend LAMMPS.
 
 Here are suggestions on how to perform these tasks:
 
@@ -24,8 +25,9 @@ Here are suggestions on how to perform these tasks:
   wraps the library interface is provided.  Thus, GUI interfaces can be
   written in Python or C/C++ that run LAMMPS and visualize or plot its
   output.  Examples of this are provided in the python directory and
-  described on the :doc:`Python <Python_head>` doc page.  Also, there
-  are several external wrappers or GUI front ends.
+  described on the :doc:`Python <Python_head>` doc page.  As of version
+  2 August 2023 :ref:`a GUI tool <lammps_gui>` is included in LAMMPS.
+  Also, there are several external wrappers or GUI front ends.
 * **Builder:** Several pre-processing tools are packaged with LAMMPS.
   Some of them convert input files in formats produced by other MD codes
   such as CHARMM, AMBER, or Insight into LAMMPS input formats.  Some of

doc/src/Intro_portability.rst

@@ -12,7 +12,7 @@ Programming language standards
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Most of the C++ code currently requires a compiler compatible with the
-C++11 standard, the KOKKOS package currently requires C++14.  Most of
+C++11 standard, the KOKKOS package currently requires C++17.  Most of
 the Python code is written to be compatible with Python 3.5 or later or
 Python 2.7.  Some Python scripts *require* Python 3 and a few others
 still need to be ported from Python 2 to Python 3.
@@ -25,7 +25,7 @@ LAMMPS can be compiled from source code using a (traditional) build
 system based on shell scripts, a few shell utilities (grep, sed, cat,
 tr) and the GNU make program. This requires running within a Bourne
 shell (``/bin/sh``).  Alternatively, a build system with different back ends
-can be created using CMake.  CMake must be at least version 3.10.
+can be created using CMake.  CMake must be at least version 3.16.
 
 Operating systems
 ^^^^^^^^^^^^^^^^^
@@ -62,9 +62,9 @@ regularly tested.
 Portability compliance
 ^^^^^^^^^^^^^^^^^^^^^^
 
-Only a subset of the LAMMPS source code is fully compliant to all of the
-above mentioned standards.  This is rather typical for projects like
-LAMMPS that largely depend on contributions from the user community.
+Only a subset of the LAMMPS source code is *fully* compliant to *all*
+of the above mentioned standards.  This is rather typical for projects
+like LAMMPS that largely depend on contributions from the user community.
 Not all contributors are trained as programmers and not all of them have
 access to multiple platforms for testing.  As part of the continuous
 integration process, however, all contributions are automatically tested

doc/src/Library_objects.rst

@@ -9,6 +9,7 @@ fixes, or variables in LAMMPS using the following functions:
 - :cpp:func:`lammps_extract_variable_datatype`
 - :cpp:func:`lammps_extract_variable`
 - :cpp:func:`lammps_set_variable`
+- :cpp:func:`lammps_variable_info`
 
 -----------------------
 
@@ -37,6 +38,11 @@ fixes, or variables in LAMMPS using the following functions:
 
 -----------------------
 
+.. doxygenfunction:: lammps_variable_info
+   :project: progguide
+
+-----------------------
+
 .. doxygenenum:: _LMP_DATATYPE_CONST
 
 .. doxygenenum:: _LMP_STYLE_CONST

doc/src/Packages_details.rst

@@ -87,8 +87,6 @@ page gives those details.
    * :ref:`MOFFF <PKG-MOFFF>`
    * :ref:`MOLECULE <PKG-MOLECULE>`
    * :ref:`MOLFILE <PKG-MOLFILE>`
-   * :ref:`MPIIO <PKG-MPIIO>`
-   * :ref:`MSCG <PKG-MSCG>`
    * :ref:`NETCDF <PKG-NETCDF>`
    * :ref:`OPENMP <PKG-OPENMP>`
    * :ref:`OPT <PKG-OPT>`
@@ -1257,7 +1255,7 @@ Also see the :ref:`GPU <PKG-GPU>`, :ref:`OPT <PKG-OPT>`, :ref:`INTEL
 <PKG-INTEL>`, and :ref:`OPENMP <PKG-OPENMP>` packages, which have styles
 optimized for CPUs, KNLs, and GPUs.
 
-You must have a C++14 compatible compiler to use this package.
+You must have a C++17 compatible compiler to use this package.
 KOKKOS makes extensive use of advanced C++ features, which can
 expose compiler bugs, especially when compiling for maximum
 performance at high optimization levels. Please see the file
@@ -2034,70 +2032,6 @@ This package has :ref:`specific installation instructions <molfile>` on the :doc
 
 ----------
 
-.. _PKG-MPIIO:
-
-MPIIO package
--------------
-
-**Contents:**
-
-Support for parallel output/input of dump and restart files via the
-MPIIO library.  It adds :doc:`dump styles <dump>` with a "mpiio" in
-their style name.  Restart files with an ".mpiio" suffix are also
-written and read in parallel.
-
-.. warning::
-
-   The MPIIO package is currently unmaintained and has become
-   unreliable. Use with caution.
-
-
-**Install:**
-
-The MPIIO package requires that LAMMPS is build in :ref:`MPI parallel mode <serial>`.
-
-**Supporting info:**
-
-* src/MPIIO: filenames -> commands
-* :doc:`dump <dump>`
-* :doc:`restart <restart>`
-* :doc:`write_restart <write_restart>`
-* :doc:`read_restart <read_restart>`
-
-----------
-
-.. _PKG-MSCG:
-
-MSCG package
-------------
-
-**Contents:**
-
-A :doc:`fix mscg <fix_mscg>` command which can parameterize a
-Multi-Scale Coarse-Graining (MSCG) model using the open-source `MS-CG library <mscg-home_>`_.
-
-.. _mscg-home: https://github.com/uchicago-voth/MSCG-release
-
-To use this package you must have the MS-CG library available on your
-system.
-
-**Authors:** The fix was written by Lauren Abbott (Sandia).  The MS-CG
-library was developed by Jacob Wagner in Greg Voth's group at the
-University of Chicago.
-
-**Install:**
-
-This package has :ref:`specific installation instructions <mscg>` on the :doc:`Build extras <Build_extras>` page.
-
-**Supporting info:**
-
-* src/MSCG: filenames -> commands
-* src/MSCG/README
-* lib/mscg/README
-* examples/mscg
-
-----------
-
 .. _PKG-NETCDF:
 
 NETCDF package

doc/src/Packages_list.rst

@@ -333,16 +333,6 @@ whether an extra library is needed to build and use the package:
      - :doc:`dump molfile <dump_molfile>`
      - n/a
      - ext
-   * - :ref:`MPIIO <PKG-MPIIO>`
-     - MPI parallel I/O dump and restart
-     - :doc:`dump <dump>`
-     - n/a
-     - no
-   * - :ref:`MSCG <PKG-MSCG>`
-     - multi-scale coarse-graining wrapper
-     - :doc:`fix mscg <fix_mscg>`
-     - mscg
-     - ext
    * - :ref:`NETCDF <PKG-NETCDF>`
      - dump output via NetCDF
      - :doc:`dump netcdf <dump_netcdf>`

doc/src/Python_error.rst

@@ -1,11 +1,11 @@
 Handling LAMMPS errors
-*******************************
+**********************
 
-Compiling the shared library with :ref:`C++ exception support <exceptions>` provides a better error
-handling experience. Without exceptions the LAMMPS code will terminate the
-current Python process with an error message.  C++ exceptions allow capturing
-them on the C++ side and rethrowing them on the Python side. This way
-LAMMPS errors can be handled through the Python exception handling mechanism.
+The shared library is compiled with :ref:`C++ exception support
+<exceptions>` to provide a better error handling experience.  C++
+exceptions allow capturing errors on the C++ side and rethrowing them on
+the Python side.  This way LAMMPS errors can be handled through the
+Python exception handling mechanism.
 
 .. code-block:: python
 
@@ -31,6 +31,6 @@ LAMMPS errors can be handled through the Python exception handling mechanism.
 .. warning::
 
    Capturing a LAMMPS exception in Python can still mean that the
-   current LAMMPS process is in an illegal state and must be terminated. It is
-   advised to save your data and terminate the Python instance as quickly as
-   possible.
+   current LAMMPS process is in an illegal state and must be
+   terminated. It is advised to save your data and terminate the Python
+   instance as quickly as possible when running in parallel with MPI.

doc/src/Speed_kokkos.rst

@@ -26,12 +26,12 @@ task). These are Serial (MPI-only for CPUs and Intel Phi), OpenMP
 GPUs) and HIP (for AMD GPUs). You choose the mode at build time to
 produce an executable compatible with a specific hardware.
 
-.. admonition:: C++14 support
+.. admonition:: C++17 support
    :class: note
 
-   Kokkos version 3.x requires using a compiler that supports the c++14 standard.
-   For some compilers, it may be necessary to add a flag to enable c++14 support.
-   For example, the GNU compiler uses the -std=c++14 flag. For a list of
+   Kokkos requires using a compiler that supports the c++17 standard. For
+   some compilers, it may be necessary to add a flag to enable c++17 support.
+   For example, the GNU compiler uses the -std=c++17 flag. For a list of
    compilers that have been tested with the Kokkos library, see the
    `requirements document of the Kokkos Wiki
    <https://kokkos.github.io/kokkos-core-wiki/requirements.html>`_.
@@ -40,10 +40,16 @@ produce an executable compatible with a specific hardware.
    :class: note
 
    To build with Kokkos support for NVIDIA GPUs, the NVIDIA CUDA toolkit
-   software version 9.0 or later must be installed on your system. See
+   software version 11.0 or later must be installed on your system. See
    the discussion for the :doc:`GPU package <Speed_gpu>` for details of
    how to check and do this.
 
+.. admonition:: AMD ROCm (HIP) support
+   :class: note
+
+   To build with Kokkos support for AMD GPUs, the AMD ROCm toolkit
+   software version 5.2.0 or later must be installed on your system.
+
 .. admonition:: CUDA and MPI library compatibility
    :class: note
 

doc/src/Tools.rst

@@ -645,9 +645,14 @@ LAMMPS GUI
 Overview
 ^^^^^^^^
 
-LAMMPS GUI is a simple graphical text editor that is linked to the
-:ref:`LAMMPS C-library interface <lammps_c_api>` and thus can run LAMMPS
-directly using the contents of the editor's text buffer as input.
+LAMMPS GUI is a graphical text editor customized for editing LAMMPS
+input files that is linked to the :ref:`LAMMPS C-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.
 
 This is similar to what people traditionally would do to run LAMMPS:
 using a regular text editor to edit the input and run the necessary
@@ -656,9 +661,9 @@ terminal window.  This similarity is a design goal. While making it easy
 for beginners to start with LAMMPS, it is also the intention to simplify
 the transition to workflows like most experienced LAMMPS users do.
 
-All features have been extensively exposed to hotkeys, so that there is
-also appeal for experienced LAMMPS users, too, especially for
-prototyping and testing simulations setups.
+All features have been extensively exposed to keyboard shortcuts, so
+that there is also appeal for experienced LAMMPS users for prototyping
+and testing simulations setups.
 
 Features
 ^^^^^^^^
@@ -673,11 +678,13 @@ Here are a few highlights of LAMMPS GUI
 - Text editor will remember up to 5 recent files
 - Context specific LAMMPS command help via online documentation
 - LAMMPS is running in a concurrent thread, so the GUI remains responsive
-- Support for accelerator packages
-- Progress bar indicates that LAMMPS is running
+- Support for most accelerator packages
+- Progress bar indicates how far a run command is completed
 - LAMMPS can be started and stopped with a hotkey
 - Screen output is captured in a Log Window
 - Thermodynamic output is captured and displayed as line graph in a Chart Window
+- Indicator for currently executed command
+- Indicator for line that caused an error
 - Visualization of current state in Image Viewer (via :doc:`dump image <dump_image>`)
 - Many adjustable settings and preferences that are persistent
 - Dialog to set variables from the LAMMPS command line
@@ -695,19 +702,26 @@ Prerequisites and portability
 LAMMPS GUI is programmed in C++ based on the C++11 standard and using
 the `Qt GUI framework <https://www.qt.io/product/framework>`_.
 Currently, Qt version 5.12 or later is required; Qt 5.15LTS is
-recommended; Qt 6.x not (yet) supported.  Building LAMMPS with CMake 3.16
-or later is required.  The LAMMPS GUI has been successfully compiled and tested on:
+recommended; support for Qt version 6.x is under active development and
+thus far only tested with Qt 6.5LTS on Linux.  Building LAMMPS 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 38 x86\_64 using GCC 13 and Clang 16, Qt version 5.15LTS
+- Fedora Linux 38 x86\_64 using GCC 13, Qt version 6.5LTS
 - Apple macOS 12 (Monterey) and macOS 13 (Ventura) with Xcode on arm64 and x86\_64, Qt version 5.15LTS
 - Windows 10 and 11 x86_64 with Visual Studio 2022 and Visual C++ 14.36, Qt version 5.15LTS
 - Windows 10 and 11 x86_64 with MinGW / GCC 10.0 cross-compiler on Fedora 38, Qt version 5.15LTS
 
+.. _lammps_gui_install:
+
+
 Pre-compiled executables
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
-Pre-compiled LAMMPS executables including the GUI are currently
+Pre-compiled LAMMPS executable packages that include the GUI are currently
 available from https://download.lammps.org/static or
 https://github.com/lammps/lammps/releases.  You can unpack the archives
 (or mount the macOS disk image) and run the GUI directly in place. The
@@ -732,7 +746,10 @@ stored in a location where CMake can find them without additional help.
 Otherwise, the location of the Qt library installation must be indicated
 by setting ``-D Qt5_DIR=/path/to/qt5/lib/cmake/Qt5``, which is a path to
 a folder inside the Qt installation that contains the file
-``Qt5Config.cmake``.
+``Qt5Config.cmake``. Similarly, for Qt6 the location of the Qt library
+installation can be indicated by setting ``-D Qt6_DIR=/path/to/qt6/lib/cmake/Qt6``,
+if necessary.  When both, Qt5 and Qt6 are available, Qt6 will be preferred
+unless ``-D LAMMPS_GUI_USE_QT5=yes`` is set.
 
 It should be possible to build the LAMMPS GUI as a standalone
 compilation (e.g. when LAMMPS has been compiled with traditional make),

doc/src/atom_modify.rst

@@ -65,6 +65,11 @@ switch.  This is described on the :doc:`Build_settings <Build_settings>`
 doc page.  If atom IDs are not used, they must be specified as 0 for
 all atoms, e.g. in a data or restart file.
 
+.. note::
+
+   If a :doc:`triclinic simulation box <Howto_triclinic>` is used,
+   atom IDs are required, due to how neighbor lists are built.
+
 The *map* keyword determines how atoms with specific IDs are found
 when required.  An example are the bond (angle, etc) methods which
 need to find the local index of an atom with a specific global ID

doc/src/compute.rst

@@ -27,58 +27,62 @@ Examples
 Description
 """""""""""
 
-Define a computation that will be performed on a group of atoms.
-Quantities calculated by a compute are instantaneous values, meaning
-they are calculated from information about atoms on the current
-timestep or iteration, though a compute may internally store some
-information about a previous state of the system.  Defining a compute
-does not perform a computation.  Instead computes are invoked by other
-LAMMPS commands as needed (e.g., to calculate a temperature needed for
-a thermostat fix or to generate thermodynamic or dump file output).
-See the :doc:`Howto output <Howto_output>` page for a summary of
-various LAMMPS output options, many of which involve computes.
+Define a diagnostic computation that will be performed on a group of
+atoms.  Quantities calculated by a compute are instantaneous values,
+meaning they are calculated from information about atoms on the
+current timestep or iteration, though internally a compute may store
+some information about a previous state of the system.  Defining a
+compute does not perform the computation.  Instead computes are
+invoked by other LAMMPS commands as needed (e.g., to calculate a
+temperature needed for a thermostat fix or to generate thermodynamic
+or dump file output).  See the :doc:`Howto output <Howto_output>` page
+for a summary of various LAMMPS output options, many of which involve
+computes.
 
 The ID of a compute can only contain alphanumeric characters and
 underscores.
 
 ----------
 
-Computes calculate one or more of four styles of quantities: global,
-per-atom, local, or per-atom.  A global quantity is one or more
-system-wide values, e.g. the temperature of the system.  A per-atom
-quantity is one or more values per atom, e.g. the kinetic energy of
-each atom.  Per-atom values are set to 0.0 for atoms not in the
-specified compute group.  Local quantities are calculated by each
-processor based on the atoms it owns, but there may be zero or more
-per atom, e.g. a list of bond distances.  Per-grid quantities are
-calculated on a regular 2d or 3d grid which overlays a 2d or 3d
-simulation domain.  The grid points and the data they store are
-distributed across processors; each processor owns the grid points
-which fall within its subdomain.
+Computes calculate and store any of four *styles* of quantities:
+global, per-atom, local, or per-grid.
 
-Computes that produce per-atom quantities have the word "atom" at the
-end of their style, e.g. *ke/atom*\ .  Computes that produce local
-quantities have the word "local" at the end of their style,
-e.g. *bond/local*\ .  Computes that produce per-grid quantities have
-the word "grid" at the end of their style, e.g. *property/grid*\ .
-Styles with neither "atom" or "local" or "grid" at the end of their
-style name produce global quantities.
+A global quantity is one or more system-wide values, e.g. the
+temperature of the system.  A per-atom quantity is one or more values
+per atom, e.g. the kinetic energy of each atom.  Per-atom values are
+set to 0.0 for atoms not in the specified compute group.  Local
+quantities are calculated by each processor based on the atoms it
+owns, but there may be zero or more per atom, e.g. a list of bond
+distances.  Per-grid quantities are calculated on a regular 2d or 3d
+grid which overlays a 2d or 3d simulation domain.  The grid points and
+the data they store are distributed across processors; each processor
+owns the grid points which fall within its subdomain.
 
-Note that a single compute typically produces either global or
-per-atom or local or per-grid values.  It does not compute both global
-and per-atom values.  It can produce local values or per-grid values
-in tandem with global or per-atom quantities.  The compute doc page
-will explain the details.
+As a general rule of thumb, computes that produce per-atom quantities
+have the word "atom" at the end of their style, e.g. *ke/atom*\ .
+Computes that produce local quantities have the word "local" at the
+end of their style, e.g. *bond/local*\ .  Computes that produce
+per-grid quantities have the word "grid" at the end of their style,
+e.g. *property/grid*\ .  And styles with neither "atom" or "local" or
+"grid" at the end of their style name produce global quantities.
 
-Global, per-atom, local, and per-grid quantities come in three kinds:
-a single scalar value, a vector of values, or a 2d array of values.
-The doc page for each compute describes the style and kind of values
-it produces, e.g. a per-atom vector.  Some computes produce more than
-one kind of a single style, e.g. a global scalar and a global vector.
+Global, per-atom, local, and per-grid quantities can also be of three
+*kinds*: a single scalar value (global only), a vector of values, or a
+2d array of values.  For per-atom, local, and per-grid quantities, a
+"vector" means a single value for each atom, each local entity
+(e.g. bond), or grid cell.  Likewise an "array", means multiple values
+for each atom, each local entity, or each grid cell.
 
-When a compute quantity is accessed, as in many of the output commands
-discussed below, it can be referenced via the following bracket
-notation, where ID is the ID of the compute:
+Note that a single compute can produce any combination of global,
+per-atom, local, or per-grid values.  Likewise it can produce any
+combination of scalar, vector, or array output for each style.  The
+exception is that for per-atom, local, and per-grid output, either a
+vector or array can be produced, but not both.  The doc page for each
+compute explains the values it produces.
+
+When a compute output is accessed by another input script command it
+is referenced via the following bracket notation, where ID is the ID
+of the compute:
 
 +-------------+--------------------------------------------+
 | c_ID        | entire scalar, vector, or array            |
@@ -89,17 +93,23 @@ notation, where ID is the ID of the compute:
 +-------------+--------------------------------------------+
 
 In other words, using one bracket reduces the dimension of the
-quantity once (vector :math:`\to` scalar, array :math:`\to` vector).  Using two
-brackets reduces the dimension twice (array :math:`\to` scalar).  Thus a
-command that uses scalar compute values as input can also process elements of a
-vector or array.
+quantity once (vector :math:`\to` scalar, array :math:`\to` vector).
+Using two brackets reduces the dimension twice (array :math:`\to`
+scalar).  Thus, for example, a command that uses global scalar compute
+values as input can also process elements of a vector or array.
+Depending on the command, this can either be done directly using the
+syntax in the table, or by first defining a :doc:`variable <variable>`
+of the appropriate style to store the quantity, then using the
+variable as an input to the command.
 
-Note that commands and :doc:`variables <variable>` which use compute
-quantities typically do not allow for all kinds (e.g., a command may
-require a vector of values, not a scalar).  This means there is no
-ambiguity about referring to a compute quantity as c_ID even if it
-produces, for example, both a scalar and vector.  The doc pages for
-various commands explain the details.
+Note that commands and :doc:`variables <variable>` which take compute
+outputs as input typically do not allow for all styles and kinds of
+data (e.g., a command may require global but not per-atom values, or
+it may require a vector of values, not a scalar).  This means there is
+typically no ambiguity about referring to a compute output as c_ID
+even if it produces, for example, both a scalar and vector.  The doc
+pages for various commands explain the details, including how any
+ambiguities are resolved.
 
 ----------
 
@@ -245,6 +255,7 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
 * :doc:`ke/atom/eff <compute_ke_atom_eff>` - per-atom translational and radial kinetic energy in the electron force field model
 * :doc:`ke/eff <compute_ke_eff>` - kinetic energy of a group of nuclei and electrons in the electron force field model
 * :doc:`ke/rigid <compute_ke_rigid>` - translational kinetic energy of rigid bodies
+* :doc:`composition/atom <compute_composition_atom>` - local composition for each atom
 * :doc:`mliap <compute_mliap>` - gradients of energy and forces with respect to model parameters and related quantities for training machine learning interatomic potentials
 * :doc:`momentum <compute_momentum>` - translational momentum
 * :doc:`msd <compute_msd>` - mean-squared displacement of group of atoms

doc/src/compute_composition_atom.rst

@@ -0,0 +1,118 @@
+.. index:: compute composition/atom
+.. index:: compute composition/atom/kk
+
+compute composition/atom command
+================================
+
+Accelerator Variants: *composition/atom/kk*
+
+Syntax
+""""""
+
+.. code-block:: LAMMPS
+
+   compute ID group-ID composition/atom keyword values ...
+
+* ID, group-ID are documented in :doc:`compute <compute>` command
+* composition/atom = style name of this compute command
+* one or more keyword/value pairs may be appended
+
+  .. parsed-literal::
+
+     keyword = *cutoff*
+       *cutoff* value = distance cutoff
+
+Examples
+""""""""
+
+.. code-block:: LAMMPS
+
+   compute 1 all composition/atom
+
+   compute 1 all composition/atom cutoff 9.0
+   comm_modify cutoff 9.0
+
+
+Description
+"""""""""""
+
+.. versionadded:: 21Nov2023
+
+Define a computation that calculates a local composition vector for each
+atom. For a central atom with :math:`M` neighbors within the neighbor cutoff sphere,
+composition is defined as the number of atoms of a given type
+(including the central atom) divided by (:math:`M+1`).  For a given central atom,
+the sum of all compositions equals one.
+
+.. note::
+
+   This compute uses the number of atom types, not chemical species, assigned in
+   :doc:`pair_coeff <pair_coeff>` command.  If an interatomic potential has two
+   species (i.e., Cu and Ni) assigned to four different atom types in
+   :doc:`pair_coeff <pair_coeff>` (i.e., 'Cu Cu Ni Ni'), the compute will
+   output four fractional values.  In those cases, the user may desire an extra
+   calculation step to consolidate per-type fractions into per-species fractions.
+   This calculation can be conducted within LAMMPS using another compute such as
+   :doc:`compute reduce <compute_reduce>`, an atom-style :doc:`variable`, or as a
+   post-processing step.
+
+----------
+
+The optional keyword *cutoff* defines the distance cutoff used when
+searching for neighbors. The default value is the cutoff specified by
+the pair style. If no pair style is defined, then a cutoff must be
+defined using this keyword. If the specified cutoff is larger than
+that of the pair_style plus neighbor skin (or no pair style is
+defined), the *comm_modify cutoff* option must also be set to match
+that of the *cutoff* keyword.
+
+The neighbor list needed to compute this quantity is constructed each
+time the calculation is performed (i.e. each time a snapshot of atoms
+is dumped).  Thus it can be inefficient to compute/dump this quantity
+too frequently.
+
+.. note::
+
+   If you have a bonded system, then the settings of
+   :doc:`special_bonds <special_bonds>` command can remove pairwise
+   interactions between atoms in the same bond, angle, or dihedral.
+   This is the default setting for the :doc:`special_bonds
+   <special_bonds>` command, and means those pairwise interactions do
+   not appear in the neighbor list.  Because this compute uses the
+   neighbor list, it also means those pairs will not be included in
+   the order parameter.  This difficulty can be circumvented by
+   writing a dump file, and using the :doc:`rerun <rerun>` command to
+   compute the order parameter for snapshots in the dump file.  The
+   rerun script can use a :doc:`special_bonds <special_bonds>` command
+   that includes all pairs in the neighbor list.
+
+----------
+
+Output info
+"""""""""""
+
+This compute calculates a per-atom array with :math:`1 + N` columns, where :math:`N`
+is the number of atom types. The first column is a count of the number of atoms
+used to calculate composition (including the central atom), and each subsequent
+column indicates the fraction of that atom type within the cutoff sphere.
+
+These values can be accessed by any command that uses per-atom values
+from a compute as input.  See the :doc:`Howto output <Howto_output>`
+doc page for an overview of LAMMPS output options.
+
+Restrictions
+""""""""""""
+
+This compute is part of the EXTRA-COMPUTE package.  It is only enabled
+if LAMMPS was built with that package.  See the :doc:`Build package
+<Build_package>` page for more info.
+
+Related commands
+""""""""""""""""
+
+:doc:`comm_modify <comm_modify>`
+
+Default
+"""""""
+
+The option defaults are *cutoff* = pair style cutoff.

doc/src/compute_property_grid.rst

@@ -19,6 +19,7 @@ Syntax
 
        attributes = id, ix, iy, iz, x, y, z, xs, ys, zs, xc, yc, zc, xsc, ysc, zsc
          id = ID of grid cell, x fastest, y next, z slowest
+         proc = processor ID (0 to Nprocs-1) which owns the grid cell
          ix,iy,iz = grid indices in each dimension (1 to N inclusive)
          x,y,z = coords of lower left corner of grid cell
          xs,ys,zs = scaled coords of lower left corner of grid cell (0.0 to 1.0)
@@ -30,8 +31,8 @@ Examples
 
 .. code-block:: LAMMPS
 
-   compute 1 all property/grid id ix iy iz
-   compute 1 all property/grid id xc yc zc
+   compute 1 all property/grid 10 10 20 id ix iy iz
+   compute 1 all property/grid 100 100 1 id xc yc zc
 
 Description
 """""""""""
@@ -53,13 +54,20 @@ to output per-grid values from other computes of fixes, the grid size
 specified for this command must be consistent with the grid sizes
 used by the other commands.
 
-The *id* attribute stores the grid ID for each grid cell.  For a
-global grid of size Nx by Ny by Nz (in 3d simulations) the grid IDs
-range from 1 to Nx*Ny*Nz.  They are ordered with the X index of the 3d
-grid varying fastest, then Y, then Z slowest.  For 2d grids (in 2d
+The *id* attribute is the grid ID for each grid cell.  For a global
+grid of size Nx by Ny by Nz (in 3d simulations) the grid IDs range
+from 1 to Nx*Ny*Nz.  They are ordered with the X index of the 3d grid
+varying fastest, then Y, then Z slowest.  For 2d grids (in 2d
 simulations), the grid IDs range from 1 to Nx*Ny, with X varying
 fastest and Y slowest.
 
+.. versionadded:: 21Nov2023
+
+The *proc* attribute is the ID of the processor which owns the grid
+cell.  Processor IDs range from 0 to Nprocs - 1, where Nprocs is the
+number of processors the simulation is running on.  Each grid cell is
+owned by a single processor.
+
 The *ix*, *iy*, *iz* attributes are the indices of a grid cell in
 each dimension.  They range from 1 to Nx inclusive in the X dimension,
 and similar for Y and Z.

doc/src/compute_reduce.rst

@@ -37,13 +37,16 @@ Syntax
        v_name = per-atom vector calculated by an atom-style variable with name
 
 * zero or more keyword/args pairs may be appended
-* keyword = *replace*
+* keyword = *replace* or *inputs*
 
   .. parsed-literal::
 
        *replace* args = vec1 vec2
          vec1 = reduced value from this input vector will be replaced
          vec2 = replace it with vec1[N] where N is index of max/min value from vec2
+       *inputs* arg = peratom or local
+         peratom = all inputs are per-atom quantities (default)
+         local = all input are local quantities
 
 Examples
 """"""""
@@ -60,38 +63,44 @@ Description
 """""""""""
 
 Define a calculation that "reduces" one or more vector inputs into
-scalar values, one per listed input.  The inputs can be per-atom or
-local quantities; they cannot be global quantities.  Atom attributes
-are per-atom quantities, :doc:`computes <compute>` and :doc:`fixes <fix>`
-may generate any of the three kinds of quantities, and :doc:`atom-style variables <variable>` generate per-atom quantities.  See the
-:doc:`variable <variable>` command and its special functions which can
-perform the same operations as the compute reduce command on global
-vectors.
+scalar values, one per listed input.  For the compute reduce command,
+the inputs can be either per-atom or local quantities and must all be
+of the same kind (per-atom or local); see discussion of the optional
+*inputs* keyword below.  The compute reduce/region command can only be
+used with per-atom inputs.
+
+Atom attributes are per-atom quantities, :doc:`computes <compute>` and
+:doc:`fixes <fix>` can generate either per-atom or local quantities,
+and :doc:`atom-style variables <variable>` generate per-atom
+quantities.  See the :doc:`variable <variable>` command and its
+special functions which can perform the same reduction operations as
+the compute reduce command on global vectors.
 
 The reduction operation is specified by the *mode* setting.  The *sum*
 option adds the values in the vector into a global total.  The *min*
 or *max* options find the minimum or maximum value across all vector
 values.  The *minabs* or *maxabs* options find the minimum or maximum
 value across all absolute vector values.  The *ave* setting adds the
-vector values into a global total, then divides by the number of values
-in the vector.  The *sumsq* option sums the square of the values in the
-vector into a global total.  The *avesq* setting does the same as *sumsq*,
-then divides the sum of squares by the number of values.  The last two options
-can be useful for calculating the variance of some quantity (e.g., variance =
-sumsq :math:`-` ave\ :math:`^2`).  The *sumabs* option sums the absolute
-values in the vector into a global total.  The *aveabs* setting does the same
-as *sumabs*, then divides the sum of absolute values by the number of
+vector values into a global total, then divides by the number of
+values in the vector.  The *sumsq* option sums the square of the
+values in the vector into a global total.  The *avesq* setting does
+the same as *sumsq*, then divides the sum of squares by the number of
+values.  The last two options can be useful for calculating the
+variance of some quantity (e.g., variance = sumsq :math:`-` ave\
+:math:`^2`).  The *sumabs* option sums the absolute values in the
+vector into a global total.  The *aveabs* setting does the same as
+*sumabs*, then divides the sum of absolute values by the number of
 values.
 
 Each listed input is operated on independently.  For per-atom inputs,
 the group specified with this command means only atoms within the
-group contribute to the result.  For per-atom inputs, if the compute
-reduce/region command is used, the atoms must also currently be within
-the region.  Note that an input that produces per-atom quantities may
-define its own group which affects the quantities it returns.  For
-example, if a compute is used as an input which generates a per-atom
-vector, it will generate values of 0.0 for atoms that are not in the
-group specified for that compute.
+group contribute to the result.  Likewise for per-atom inputs, if the
+compute reduce/region command is used, the atoms must also currently
+be within the region.  Note that an input that produces per-atom
+quantities may define its own group which affects the quantities it
+returns.  For example, if a compute is used as an input which
+generates a per-atom vector, it will generate values of 0.0 for atoms
+that are not in the group specified for that compute.
 
 Each listed input can be an atom attribute (position, velocity, force
 component) or can be the result of a :doc:`compute <compute>` or
@@ -123,52 +132,54 @@ array with six columns:
 
 ----------
 
-The atom attribute values (*x*, *y*, *z*, *vx*, *vy*, *vz*, *fx*, *fy*, and
-*fz*) are self-explanatory.  Note that other atom attributes can be used as
-inputs to this fix by using the
-:doc:`compute property/atom <compute_property_atom>` command and then specifying
-an input value from that compute.
+The atom attribute values (*x*, *y*, *z*, *vx*, *vy*, *vz*, *fx*,
+*fy*, and *fz*) are self-explanatory.  Note that other atom attributes
+can be used as inputs to this fix by using the :doc:`compute
+property/atom <compute_property_atom>` command and then specifying an
+input value from that compute.
 
 If a value begins with "c\_", a compute ID must follow which has been
-previously defined in the input script.  Computes can generate
-per-atom or local quantities.  See the individual
-:doc:`compute <compute>` page for details.  If no bracketed integer
-is appended, the vector calculated by the compute is used.  If a
-bracketed integer is appended, the Ith column of the array calculated
-by the compute is used.  Users can also write code for their own
-compute styles and :doc:`add them to LAMMPS <Modify>`.  See the
-discussion above for how :math:`I` can be specified with a wildcard asterisk
-to effectively specify multiple values.
+previously defined in the input script.  Valid computes can generate
+per-atom or local quantities.  See the individual :doc:`compute
+<compute>` page for details.  If no bracketed integer is appended, the
+vector calculated by the compute is used.  If a bracketed integer is
+appended, the Ith column of the array calculated by the compute is
+used.  Users can also write code for their own compute styles and
+:doc:`add them to LAMMPS <Modify>`.  See the discussion above for how
+:math:`I` can be specified with a wildcard asterisk to effectively
+specify multiple values.
 
 If a value begins with "f\_", a fix ID must follow which has been
-previously defined in the input script.  Fixes can generate per-atom
-or local quantities.  See the individual :doc:`fix <fix>` page for
-details.  Note that some fixes only produce their values on certain
-timesteps, which must be compatible with when compute reduce
+previously defined in the input script.  Valid fixes can generate
+per-atom or local quantities.  See the individual :doc:`fix <fix>`
+page for details.  Note that some fixes only produce their values on
+certain timesteps, which must be compatible with when compute reduce
 references the values, else an error results.  If no bracketed integer
 is appended, the vector calculated by the fix is used.  If a bracketed
 integer is appended, the Ith column of the array calculated by the fix
 is used.  Users can also write code for their own fix style and
 :doc:`add them to LAMMPS <Modify>`.  See the discussion above for how
-:math:`I` can be specified with a wildcard asterisk to effectively specify
-multiple values.
+:math:`I` can be specified with a wildcard asterisk to effectively
+specify multiple values.
 
 If a value begins with "v\_", a variable name must follow which has
 been previously defined in the input script.  It must be an
 :doc:`atom-style variable <variable>`.  Atom-style variables can
 reference thermodynamic keywords and various per-atom attributes, or
 invoke other computes, fixes, or variables when they are evaluated, so
-this is a very general means of generating per-atom quantities to reduce.
+this is a very general means of generating per-atom quantities to
+reduce.
 
 ----------
 
 If the *replace* keyword is used, two indices *vec1* and *vec2* are
-specified, where each index ranges from 1 to the number of input values.
-The replace keyword can only be used if the *mode* is *min* or *max*\ .
-It works as follows.  A min/max is computed as usual on the *vec2*
-input vector.  The index :math:`N` of that value within *vec2* is also stored.
-Then, instead of performing a min/max on the *vec1* input vector, the
-stored index is used to select the :math:`N`\ th element of the *vec1* vector.
+specified, where each index ranges from 1 to the number of input
+values.  The replace keyword can only be used if the *mode* is *min*
+or *max*\ .  It works as follows.  A min/max is computed as usual on
+the *vec2* input vector.  The index :math:`N` of that value within
+*vec2* is also stored.  Then, instead of performing a min/max on the
+*vec1* input vector, the stored index is used to select the :math:`N`\
+th element of the *vec1* vector.
 
 Thus, for example, if you wish to use this compute to find the bond
 with maximum stretch, you can do it as follows:
@@ -190,6 +201,16 @@ information in this context, the *replace* keywords will extract the
 atom IDs for the two atoms in the bond of maximum stretch.  These atom
 IDs and the bond stretch will be printed with thermodynamic output.
 
+.. versionadded:: 21Nov2023
+
+The *inputs* keyword allows selection of whether all the inputs are
+per-atom or local quantities.  As noted above, all the inputs must be
+the same kind (per-atom or local).  Per-atom is the default setting.
+If a compute or fix is specified as an input, it must produce per-atom
+or local data to match this setting.  If it produces both, e.g. for
+the :doc:`compute voronoi/atom <compute_voronoi_atom>` command, then
+this keyword selects between them.
+
 ----------
 
 If a single input is specified this compute produces a global scalar
@@ -197,38 +218,41 @@ value.  If multiple inputs are specified, this compute produces a
 global vector of values, the length of which is equal to the number of
 inputs specified.
 
-As discussed below, for the *sum*, *sumabs*, and *sumsq* modes, the value(s)
-produced by this compute are all "extensive", meaning their value
-scales linearly with the number of atoms involved.  If normalized
-values are desired, this compute can be accessed by the
+As discussed below, for the *sum*, *sumabs*, and *sumsq* modes, the
+value(s) produced by this compute are all "extensive", meaning their
+value scales linearly with the number of atoms involved.  If
+normalized values are desired, this compute can be accessed by the
 :doc:`thermo_style custom <thermo_style>` command with
-:doc:`thermo_modify norm yes <thermo_modify>` set as an option.
-Or it can be accessed by a
-:doc:`variable <variable>` that divides by the appropriate atom count.
+:doc:`thermo_modify norm yes <thermo_modify>` set as an option.  Or it
+can be accessed by a :doc:`variable <variable>` that divides by the
+appropriate atom count.
 
 ----------
 
 Output info
 """""""""""
 
-This compute calculates a global scalar if a single input value is specified
-or a global vector of length :math:`N`, where :math:`N` is the number of
-inputs, and which can be accessed by indices 1 to :math:`N`.  These values can
-be used by any command that uses global scalar or vector values from a
-compute as input.  See the :doc:`Howto output <Howto_output>` doc page
-for an overview of LAMMPS output options.
+This compute calculates a global scalar if a single input value is
+specified or a global vector of length :math:`N`, where :math:`N` is
+the number of inputs, and which can be accessed by indices 1 to
+:math:`N`.  These values can be used by any command that uses global
+scalar or vector values from a compute as input.  See the :doc:`Howto
+output <Howto_output>` doc page for an overview of LAMMPS output
+options.
 
 All the scalar or vector values calculated by this compute are
 "intensive", except when the *sum*, *sumabs*, or *sumsq* modes are used on
 per-atom or local vectors, in which case the calculated values are
 "extensive".
 
-The scalar or vector values will be in whatever :doc:`units <units>` the
-quantities being reduced are in.
+The scalar or vector values will be in whatever :doc:`units <units>`
+the quantities being reduced are in.
 
 Restrictions
 """"""""""""
- none
+
+As noted above, the compute reduce/region command can only be used
+with per-atom inputs.
 
 Related commands
 """"""""""""""""
@@ -238,4 +262,4 @@ Related commands
 Default
 """""""
 
-none
+The default value for the *inputs* keyword is peratom.

doc/src/compute_voronoi_atom.rst

@@ -13,7 +13,7 @@ Syntax
 * ID, group-ID are documented in :doc:`compute <compute>` command
 * voronoi/atom = style name of this compute command
 * zero or more keyword/value pairs may be appended
-* keyword = *only_group* or *occupation* or *surface* or *radius* or *edge_histo* or *edge_threshold* or *face_threshold* or *neighbors* or *peratom*
+* keyword = *only_group* or *occupation* or *surface* or *radius* or *edge_histo* or *edge_threshold* or *face_threshold* or *neighbors*
 
   .. parsed-literal::
 
@@ -31,7 +31,6 @@ Syntax
        *face_threshold* arg = minarea
          minarea = minimum area for a face to be counted
        *neighbors* value = *yes* or *no* = store list of all neighbors or no
-       *peratom* value = *yes* or *no* = per-atom quantities accessible or no
 
 Examples
 """"""""
@@ -53,14 +52,12 @@ atoms in the simulation box.  The tessellation is calculated using all
 atoms in the simulation, but non-zero values are only stored for atoms
 in the group.
 
-By default two per-atom quantities are calculated by this compute.
-The first is the volume of the Voronoi cell around each atom.  Any
-point in an atom's Voronoi cell is closer to that atom than any other.
-The second is the number of faces of the Voronoi cell. This is
-equal to the number of nearest neighbors of the central atom,
-plus any exterior faces (see note below). If the *peratom* keyword
-is set to "no", the per-atom quantities are still calculated,
-but they are not accessible.
+Two per-atom quantities are calculated by this compute.  The first is
+the volume of the Voronoi cell around each atom.  Any point in an
+atom's Voronoi cell is closer to that atom than any other.  The second
+is the number of faces of the Voronoi cell. This is equal to the
+number of nearest neighbors of the central atom, plus any exterior
+faces (see note below).
 
 ----------
 
@@ -97,13 +94,13 @@ present in atom_style sphere for granular models.
 
 The *edge_histo* keyword activates the compilation of a histogram of
 number of edges on the faces of the Voronoi cells in the compute
-group. The argument *maxedge* of the this keyword is the largest number
-of edges on a single Voronoi cell face expected to occur in the
-sample. This keyword adds the generation of a global vector with
-*maxedge*\ +1 entries. The last entry in the vector contains the number of
-faces with more than *maxedge* edges. Since the polygon with the
-smallest amount of edges is a triangle, entries 1 and 2 of the vector
-will always be zero.
+group. The argument *maxedge* of the this keyword is the largest
+number of edges on a single Voronoi cell face expected to occur in the
+sample. This keyword generates output of a global vector by this
+compute with *maxedge*\ +1 entries. The last entry in the vector
+contains the number of faces with more than *maxedge* edges. Since the
+polygon with the smallest amount of edges is a triangle, entries 1 and
+2 of the vector will always be zero.
 
 The *edge_threshold* and *face_threshold* keywords allow the
 suppression of edges below a given minimum length and faces below a
@@ -127,8 +124,8 @@ to locate vacancies (the coordinates are given by the atom coordinates
 at the time step when the compute was first invoked), while column two
 data can be used to identify interstitial atoms.
 
-If the *neighbors* value is set to yes, then this compute creates a
-local array with 3 columns. There is one row for each face of each
+If the *neighbors* value is set to yes, then this compute also creates
+a local array with 3 columns. There is one row for each face of each
 Voronoi cell. The 3 columns are the atom ID of the atom that owns the
 cell, the atom ID of the atom in the neighboring cell (or zero if the
 face is external), and the area of the face.  The array can be
@@ -143,8 +140,8 @@ containing all the Voronoi neighbors in a system:
    compute 6 all voronoi/atom neighbors yes
    dump d2 all local 1 dump.neighbors index c_6[1] c_6[2] c_6[3]
 
-If the *face_threshold* keyword is used, then only faces
-with areas greater than the threshold are stored.
+If the *face_threshold* keyword is used, then only faces with areas
+greater than the threshold are stored.
 
 ----------
 
@@ -158,48 +155,52 @@ Voro++ software in the src/VORONOI/README file.
 
 .. note::
 
-   The calculation of Voronoi volumes is performed by each processor for
-   the atoms it owns, and includes the effect of ghost atoms stored by
-   the processor.  This assumes that the Voronoi cells of owned atoms
-   are not affected by atoms beyond the ghost atom cut-off distance.
-   This is usually a good assumption for liquid and solid systems, but
-   may lead to underestimation of Voronoi volumes in low density
-   systems.  By default, the set of ghost atoms stored by each processor
-   is determined by the cutoff used for :doc:`pair_style <pair_style>`
-   interactions.  The cutoff can be set explicitly via the
-   :doc:`comm_modify cutoff <comm_modify>` command.  The Voronoi cells
-   for atoms adjacent to empty regions will extend into those regions up
-   to the communication cutoff in :math:`x`, :math:`y`, or :math:`z`.
-   In that situation, an exterior face is created at the cutoff distance
-   normal to the :math:`x`, :math:`y`, or :math:`z` direction.  For
-   triclinic systems, the exterior face is parallel to the corresponding
-   reciprocal lattice vector.
+   The calculation of Voronoi volumes is performed by each processor
+   for the atoms it owns, and includes the effect of ghost atoms
+   stored by the processor.  This assumes that the Voronoi cells of
+   owned atoms are not affected by atoms beyond the ghost atom cut-off
+   distance.  This is usually a good assumption for liquid and solid
+   systems, but may lead to underestimation of Voronoi volumes in low
+   density systems.  By default, the set of ghost atoms stored by each
+   processor is determined by the cutoff used for :doc:`pair_style
+   <pair_style>` interactions.  The cutoff can be set explicitly via
+   the :doc:`comm_modify cutoff <comm_modify>` command.  The Voronoi
+   cells for atoms adjacent to empty regions will extend into those
+   regions up to the communication cutoff in :math:`x`, :math:`y`, or
+   :math:`z`.  In that situation, an exterior face is created at the
+   cutoff distance normal to the :math:`x`, :math:`y`, or :math:`z`
+   direction.  For triclinic systems, the exterior face is parallel to
+   the corresponding reciprocal lattice vector.
 
 .. note::
 
-   The Voro++ package performs its calculation in 3d.  This will
-   still work for a 2d LAMMPS simulation, provided all the atoms have the
-   same :math:`z`-coordinate. The Voronoi cell of each atom will be a columnar
-   polyhedron with constant cross-sectional area along the :math:`z`-direction
-   and two exterior faces at the top and bottom of the simulation box. If
-   the atoms do not all have the same :math:`z`-coordinate, then the columnar
-   cells will be accordingly distorted. The cross-sectional area of each
-   Voronoi cell can be obtained by dividing its volume by the :math:`z` extent
-   of the simulation box.  Note that you define the :math:`z` extent of the
-   simulation box for 2d simulations when using the
-   :doc:`create_box <create_box>` or :doc:`read_data <read_data>` commands.
+   The Voro++ package performs its calculation in 3d.  This will still
+   work for a 2d LAMMPS simulation, provided all the atoms have the
+   same :math:`z`-coordinate. The Voronoi cell of each atom will be a
+   columnar polyhedron with constant cross-sectional area along the
+   :math:`z`-direction and two exterior faces at the top and bottom of
+   the simulation box. If the atoms do not all have the same
+   :math:`z`-coordinate, then the columnar cells will be accordingly
+   distorted. The cross-sectional area of each Voronoi cell can be
+   obtained by dividing its volume by the :math:`z` extent of the
+   simulation box.  Note that you define the :math:`z` extent of the
+   simulation box for 2d simulations when using the :doc:`create_box
+   <create_box>` or :doc:`read_data <read_data>` commands.
 
 Output info
 """""""""""
 
-By default, this compute calculates a per-atom array with two
-columns. In regular dynamic tessellation mode the first column is the
-Voronoi volume, the second is the neighbor count, as described above
-(read above for the output data in case the *occupation* keyword is
-specified).  These values can be accessed by any command that uses
-per-atom values from a compute as input.  See the :doc:`Howto output <Howto_output>` page for an overview of LAMMPS output
-options. If the *peratom* keyword is set to "no", the per-atom array
-is still created, but it is not accessible.
+.. deprecated:: 21Nov2023
+
+   The *peratom* keyword was removed as it is no longer required.
+
+This compute calculates a per-atom array with two columns. In regular
+dynamic tessellation mode the first column is the Voronoi volume, the
+second is the neighbor count, as described above (read above for the
+output data in case the *occupation* keyword is specified).  These
+values can be accessed by any command that uses per-atom values from a
+compute as input.  See the :doc:`Howto output <Howto_output>` page for
+an overview of LAMMPS output options.
 
 If the *edge_histo* keyword is used, then this compute generates a
 global vector of length *maxedge*\ +1, containing a histogram of the
@@ -209,17 +210,6 @@ If the *neighbors* value is set to *yes*, then this compute calculates a
 local array with three columns. There is one row for each face of each
 Voronoi cell.
 
-.. note::
-
-   Some LAMMPS commands such as the :doc:`compute reduce <compute_reduce>`
-   command can accept either a per-atom or local quantity. If this compute
-   produces both quantities, the command
-   may access the per-atom quantity, even if you want to access the local
-   quantity.  This effect can be eliminated by using the *peratom*
-   keyword to turn off the production of the per-atom quantities.  For
-   the default value *yes* both quantities are produced.  For the value
-   *no*, only the local array is produced.
-
 The Voronoi cell volume will be in distance :doc:`units <units>` cubed.
 The Voronoi face area will be in distance :doc:`units <units>` squared.
 
@@ -227,7 +217,8 @@ Restrictions
 """"""""""""
 
 This compute is part of the VORONOI package.  It is only enabled if
-LAMMPS was built with that package.  See the :doc:`Build package <Build_package>` page for more info.
+LAMMPS was built with that package.  See the :doc:`Build package
+<Build_package>` page for more info.
 
 It also requires you have a copy of the Voro++ library built and
 installed on your system.  See instructions on obtaining and
@@ -241,5 +232,4 @@ Related commands
 Default
 """""""
 
-*neighbors* no, *peratom* yes
-
+The default for the neighbors keyword is no.

doc/src/dump.rst

@@ -14,10 +14,6 @@
 .. index:: dump custom/gz
 .. index:: dump local/gz
 .. index:: dump xyz/gz
-.. index:: dump atom/mpiio
-.. index:: dump cfg/mpiio
-.. index:: dump custom/mpiio
-.. index:: dump xyz/mpiio
 .. index:: dump atom/zstd
 .. index:: dump cfg/zstd
 .. index:: dump custom/zstd
@@ -63,7 +59,7 @@ Syntax
 
 * ID = user-assigned name for the dump
 * group-ID = ID of the group of atoms to be dumped
-* style = *atom* or *atom/adios* or *atom/gz* or *atom/zstd* or *atom/mpiio* or *cfg* or *cfg/gz* or *cfg/zstd* or *cfg/mpiio* or *cfg/uef* or *custom* or *custom/gz* or *custom/zstd* or *custom/mpiio* or *custom/adios* or *dcd* or *grid* or *grid/vtk* or *h5md* or *image* or *local* or *local/gz* or *local/zstd* or *molfile* or *movie* or *netcdf* or *netcdf/mpiio* or *vtk* or *xtc* or *xyz* or *xyz/gz* or *xyz/zstd* or *xyz/mpiio* or *yaml*
+* style = *atom* or *atom/adios* or *atom/gz* or *atom/zstd* or *cfg* or *cfg/gz* or *cfg/zstd* or *cfg/uef* or *custom* or *custom/gz* or *custom/zstd* or *custom/adios* or *dcd* or *grid* or *grid/vtk* or *h5md* or *image* or *local* or *local/gz* or *local/zstd* or *molfile* or *movie* or *netcdf* or *netcdf/mpiio* or *vtk* or *xtc* or *xyz* or *xyz/gz* or *xyz/zstd* or *yaml*
 * N = dump on timesteps which are multiples of N
 * file = name of file to write dump info to
 * attribute1,attribute2,... = list of attributes for a particular style
@@ -74,13 +70,11 @@ Syntax
        *atom/adios* attributes = none,  discussed on :doc:`dump atom/adios <dump_adios>` page
        *atom/gz* attributes = none
        *atom/zstd* attributes = none
-       *atom/mpiio* attributes = none
        *cfg* attributes = same as *custom* attributes, see below
        *cfg/gz* attributes = same as *custom* attributes, see below
        *cfg/zstd* attributes = same as *custom* attributes, see below
-       *cfg/mpiio* attributes = same as *custom* attributes, see below
        *cfg/uef* attributes = same as *custom* attributes, discussed on :doc:`dump cfg/uef <dump_cfg_uef>` page
-       *custom*, *custom/gz*, *custom/zstd*, *custom/mpiio* attributes = see below
+       *custom*, *custom/gz*, *custom/zstd* attributes = see below
        *custom/adios* attributes = same as *custom* attributes, discussed on :doc:`dump custom/adios <dump_adios>` page
        *dcd* attributes = none
        *h5md* attributes = discussed on :doc:`dump h5md <dump_h5md>` page
@@ -97,10 +91,9 @@ Syntax
        *xyz* attributes = none
        *xyz/gz* attributes = none
        *xyz/zstd* attributes = none
-       *xyz/mpiio* attributes = none
        *yaml* attributes = same as *custom* attributes, see below
 
-* *custom* or *custom/gz* or *custom/zstd* or *custom/mpiio* or *cfg* or *cfg/gz* or *cfg/zstd* or *cfg/mpiio* or *cfg/uef* or *netcdf* or *netcdf/mpiio* or *yaml* attributes:
+* *custom* or *custom/gz* or *custom/zstd* or *cfg* or *cfg/gz* or *cfg/zstd* or *cfg/uef* or *netcdf* or *netcdf/mpiio* or *yaml* attributes:
 
   .. parsed-literal::
 
@@ -179,11 +172,9 @@ Examples
 .. code-block:: LAMMPS
 
    dump myDump all atom 100 dump.lammpstrj
-   dump myDump all atom/mpiio 100 dump.atom.mpiio
    dump myDump all atom/gz 100 dump.atom.gz
    dump myDump all atom/zstd 100 dump.atom.zst
    dump 2 subgroup atom 50 dump.run.bin
-   dump 2 subgroup atom/mpiio 50 dump.run.mpiio.bin
    dump 4a all custom 100 dump.myforce.* id type x y vx fx
    dump 4a all custom 100 dump.myvel.lammpsbin id type x y z vx vy vz
    dump 4b flow custom 100 dump.%.myforce id type c_myF[3] v_ke
@@ -622,27 +613,10 @@ when running on large numbers of processors.
 Note that using the "\*" and "%" characters together can produce a
 large number of small dump files!
 
-For styles that end with *mpiio* an ".mpiio" must appear somewhere in
-the specified filename.  These styles write their dump file in
-parallel via the MPI-IO library, which is part of the MPI standard for
-versions 2.0 and above.  Note these styles are identical in command
-syntax to the corresponding styles without "mpiio".  Likewise, the
-dump files produced by these MPI-IO styles are identical in format to
-the files produced by their non-MPI-IO style counterparts.  This means
-you can write a dump file using MPI-IO and use the :doc:`read_dump
-<read_dump>` command or perform other post-processing, just as if the
-dump file was not written using MPI-IO.
+.. deprecated:: 21Nov2023
 
-Because MPI-IO dump files are one large file which all processors
-write to, you cannot use the "%" wildcard character described above in
-the filename.  However you can use the ".bin" or ".lammpsbin" suffix
-described below.  Again, this file will be written in parallel and
-have the same binary format as if it were written without MPI-IO.
-
-.. warning::
-
-   The MPIIO package within LAMMPS is currently unmaintained and has
-   become unreliable. Use with caution.
+The MPIIO package and the the corresponding "/mpiio" dump styles, except
+for the unrelated "netcdf/mpiio" style were removed from LAMMPS.
 
 ----------
 
@@ -956,11 +930,6 @@ the COMPRESS package.  They are only enabled if LAMMPS was built with
 that package.  See the :doc:`Build package <Build_package>` page for
 more info.
 
-The *atom/mpiio*, *cfg/mpiio*, *custom/mpiio*, and *xyz/mpiio* styles
-are part of the MPIIO package.  They are only enabled if LAMMPS was
-built with that package.  See the :doc:`Build package <Build_package>`
-page for more info.
-
 The *xtc*, *dcd*, and *yaml* styles are part of the EXTRA-DUMP package.
 They are only enabled if LAMMPS was built with that package.  See the
 :doc:`Build package <Build_package>` page for more info.
@@ -971,6 +940,7 @@ Related commands
 :doc:`dump atom/adios <dump_adios>`, :doc:`dump custom/adios <dump_adios>`,
 :doc:`dump cfg/uef <dump_cfg_uef>`, :doc:`dump h5md <dump_h5md>`,
 :doc:`dump image <dump_image>`, :doc:`dump molfile <dump_molfile>`,
+:doc:`dump netcdf <dump_netcdf>`, :doc:`dump netcdf/mpiio <dump_netcdf>`,
 :doc:`dump_modify <dump_modify>`, :doc:`undump <undump>`,
 :doc:`write_dump <write_dump>`
 

doc/src/dump_image.rst

@@ -24,7 +24,7 @@ Syntax
 * color = atom attribute that determines color of each atom
 * diameter = atom attribute that determines size of each atom
 * zero or more keyword/value pairs may be appended
-* keyword = *atom* or *adiam* or *bond* or *grid* or *line* or *tri* or *body* or *fix* or *size* or *view* or *center* or *up* or *zoom* or *box* or *axes* or *subbox* or *shiny* or *ssao*
+* keyword = *atom* or *adiam* or *bond* or *grid* or *line* or *tri* or *body* or *fix* or *size* or *view* or *center* or *up* or *zoom* or *box* or *axes* or *subbox* or *shiny* or *fsaa* or *ssao*
 
   .. parsed-literal::
 
@@ -85,6 +85,8 @@ Syntax
          diam = diameter of subdomain lines as fraction of shortest box length
        *shiny* value = sfactor = shinyness of spheres and cylinders
          sfactor = shinyness of spheres and cylinders from 0.0 to 1.0
+       *fsaa* arg = yes/no
+         yes/no = do or do not apply anti-aliasing
        *ssao* value = shading seed dfactor = SSAO depth shading
          shading = *yes* or *no* = turn depth shading on/off
          seed = random # seed (positive integer)
@@ -597,13 +599,47 @@ image will appear.  The *sfactor* value must be a value 0.0 <=
 *sfactor* <= 1.0, where *sfactor* = 1 is a highly reflective surface
 and *sfactor* = 0 is a rough non-shiny surface.
 
-The *ssao* keyword turns on/off a screen space ambient occlusion
-(SSAO) model for depth shading.  If *yes* is set, then atoms further
-away from the viewer are darkened via a randomized process, which is
-perceived as depth.  The calculation of this effect can increase the
-cost of computing the image by roughly 2x.  The strength of the effect
-can be scaled by the *dfactor* parameter.  If *no* is set, no depth
-shading is performed.
+.. versionadded:: 21Nov2023
+
+The *fsaa* keyword can be used with the dump image command to improve
+the image quality by enabling full scene anti-aliasing.  Internally the
+image is rendered at twice the width and height and then scaled down by
+computing the average of each 2x2 block of pixels to produce a single
+pixel in the final image at the original size. This produces images with
+smoother, less ragged edges.  The application of this algorithm can
+increase the cost of computing the image by about 3x or more.
+
+The *ssao* keyword turns on/off a screen space ambient occlusion (SSAO)
+model for depth shading.  If *yes* is set, then atoms further away from
+the viewer are darkened via a randomized process, which is perceived as
+depth.  The strength of the effect can be scaled by the *dfactor*
+parameter.  If *no* is set, no depth shading is performed.  The
+calculation of this effect can increase the cost of computing the image
+substantially by 5x or more, especially with larger images.  When used
+in combination with the *fsaa* keyword the computational cost of depth
+shading is particularly large.
+
+----------
+
+Image Quality Settings
+""""""""""""""""""""""
+
+The two keywords *fsaa* and *ssao* can be used to improve the image
+quality at the expense of additional computational cost to render the
+images. The images below show from left to right the same render with
+default settings, with *fsaa* added, with *ssao* added, and with both
+keywords added.
+
+.. |imagequality1| image:: JPG/image.default.png
+   :width: 24%
+.. |imagequality2| image:: JPG/image.fsaa.png
+   :width: 24%
+.. |imagequality3| image:: JPG/image.ssao.png
+   :width: 24%
+.. |imagequality4| image:: JPG/image.both.png
+   :width: 24%
+
+|imagequality1|  |imagequality2|  |imagequality3|  |imagequality4|
 
 ----------
 
@@ -1051,6 +1087,7 @@ The defaults for the dump_modify keywords specific to dump image and dump movie
 * boxcolor = yellow
 * color = 140 color names are pre-defined as listed below
 * framerate = 24
+* fsaa = no
 * gmap = min max cf 0.0 2 min blue max red
 
 ----------

doc/src/dump_modify.rst

@@ -124,17 +124,6 @@ Description
 Modify the parameters of a previously defined dump command.  Not all
 parameters are relevant to all dump styles.
 
-As explained on the :doc:`dump <dump>` doc page, the *atom/mpiio*,
-*custom/mpiio*, and *xyz/mpiio* dump styles are identical in command
-syntax and in the format of the dump files they create, to the
-corresponding styles without "mpiio", except the single dump file they
-produce is written in parallel via the MPI-IO library.  Thus if a
-dump_modify option below is valid for the *atom* style, it is also
-valid for the *atom/mpiio* style, and similarly for the other styles
-which allow for use of MPI-IO.
-
-----------
-
 Unless otherwise noted, the following keywords apply to all the
 various dump styles, including the :doc:`dump image <dump_image>` and
 :doc:`dump movie <dump_image>` styles.
@@ -181,19 +170,20 @@ extra buffering.
 .. versionadded:: 4May2022
 
 The *colname* keyword can be used to change the default header keyword
-for dump styles: *atom*, *custom*, *cfg*, and *local* and their compressed,
-ADIOS, and MPIIO variants.  The setting for *ID string* replaces the default
-text with the provided string.  *ID* can be a positive integer when it
-represents the column number counting from the left, a negative integer
-when it represents the column number from the right (i.e. -1 is the last
-column/keyword), or a custom dump keyword (or compute, fix, property, or
-variable reference) and then it replaces the string for that specific
-keyword. For *atom* dump styles only the keywords "id", "type", "x",
-"y", "z", "ix", "iy", "iz" can be accessed via string regardless of
-whether scaled or unwrapped coordinates were enabled or disabled, and
-it always assumes 8 columns for indexing regardless of whether image
-flags are enabled or not.  For dump style *cfg* only changes to the
-"auxiliary" keywords (6th or later keyword) will become visible.
+for dump styles: *atom*, *custom*, *cfg*, and *local* and their
+compressed, ADIOS variants.  The setting for *ID string* replaces the
+default text with the provided string.  *ID* can be a positive integer
+when it represents the column number counting from the left, a negative
+integer when it represents the column number from the right (i.e. -1 is
+the last column/keyword), or a custom dump keyword (or compute, fix,
+property, or variable reference) and then it replaces the string for
+that specific keyword. For *atom* dump styles only the keywords "id",
+"type", "x", "y", "z", "ix", "iy", "iz" can be accessed via string
+regardless of whether scaled or unwrapped coordinates were enabled or
+disabled, and it always assumes 8 columns for indexing regardless of
+whether image flags are enabled or not.  For dump style *cfg* only
+changes to the "auxiliary" keywords (6th or later keyword) will become
+visible.
 
 The *colname* keyword can be used multiple times. If multiple *colname*
 settings refer to the same keyword, the last setting has precedence.  A
@@ -417,10 +407,10 @@ performed with dump style *xtc*\ .
 
 ----------
 
-The *format* keyword can be used to change the default numeric format output
-by the text-based dump styles: *atom*, *local*, *custom*, *cfg*, and
-*xyz* styles, and their MPIIO variants. Only the *line* or *none*
-options can be used with the *atom* and *xyz* styles.
+The *format* keyword can be used to change the default numeric format
+output by the text-based dump styles: *atom*, *local*, *custom*, *cfg*,
+and *xyz* styles. Only the *line* or *none* options can be used with the
+*atom* and *xyz* styles.
 
 All the specified format strings are C-style formats, such as used by
 the C/C++ printf() command.  The *line* keyword takes a single

doc/src/fix.rst

@@ -77,35 +77,44 @@ for individual fixes for info on which ones can be restarted.
 
 ----------
 
-Some fixes calculate one or more of four styles of quantities: global,
-per-atom, local, or per-grid, which can be used by other commands or
-output as described below.  A global quantity is one or more
-system-wide values, e.g. the energy of a wall interacting with
-particles.  A per-atom quantity is one or more values per atom,
-e.g. the displacement vector for each atom since time 0.  Per-atom
-values are set to 0.0 for atoms not in the specified fix group.  Local
-quantities are calculated by each processor based on the atoms it
-owns, but there may be zero or more per atoms.  Per-grid quantities
-are calculated on a regular 2d or 3d grid which overlays a 2d or 3d
-simulation domain.  The grid points and the data they store are
-distributed across processors; each processor owns the grid points
-which fall within its subdomain.
+Some fixes calculate and store any of four *styles* of quantities:
+global, per-atom, local, or per-grid.
 
-Note that a single fix typically produces either global or per-atom or
-local or per-grid values (or none at all).  It does not produce both
-global and per-atom.  It can produce local or per-grid values in
-tandem with global or per-atom values.  The fix doc page will explain
-the details.
+A global quantity is one or more system-wide values, e.g. the energy
+of a wall interacting with particles.  A per-atom quantity is one or
+more values per atom, e.g. the original coordinates of each atom at
+time 0.  Per-atom values are set to 0.0 for atoms not in the specified
+fix group.  Local quantities are calculated by each processor based on
+the atoms it owns, but there may be zero or more per atom, e.g. values
+for each bond.  Per-grid quantities are calculated on a regular 2d or
+3d grid which overlays a 2d or 3d simulation domain.  The grid points
+and the data they store are distributed across processors; each
+processor owns the grid points which fall within its subdomain.
 
-Global, per-atom, local, and per-grid quantities come in three kinds:
-a single scalar value, a vector of values, or a 2d array of values.
-The doc page for each fix describes the style and kind of values it
-produces, e.g. a per-atom vector.  Some fixes produce more than one
-kind of a single style, e.g. a global scalar and a global vector.
+As a general rule of thumb, fixes that produce per-atom quantities
+have the word "atom" at the end of their style, e.g. *ave/atom*\ .
+Fixes that produce local quantities have the word "local" at the end
+of their style, e.g. *store/local*\ .  Fixes that produce per-grid
+quantities have the word "grid" at the end of their style,
+e.g. *ave/grid*\ .
 
-When a fix quantity is accessed, as in many of the output commands
-discussed below, it can be referenced via the following bracket
-notation, where ID is the ID of the fix:
+Global, per-atom, local, and per-grid quantities can also be of three
+*kinds*: a single scalar value (global only), a vector of values, or a
+2d array of values.  For per-atom, local, and per-grid quantities, a
+"vector" means a single value for each atom, each local entity
+(e.g. bond), or grid cell.  Likewise an "array", means multiple values
+for each atom, each local entity, or each grid cell.
+
+Note that a single fix can produce any combination of global,
+per-atom, local, or per-grid values.  Likewise it can produce any
+combination of scalar, vector, or array output for each style.  The
+exception is that for per-atom, local, and per-grid output, either a
+vector or array can be produced, but not both.  The doc page for each
+fix explains the values it produces, if any.
+
+When a fix output is accessed by another input script command it is
+referenced via the following bracket notation, where ID is the ID of
+the fix:
 
 +-------------+--------------------------------------------+
 | f_ID        | entire scalar, vector, or array            |
@@ -116,19 +125,23 @@ notation, where ID is the ID of the fix:
 +-------------+--------------------------------------------+
 
 In other words, using one bracket reduces the dimension of the
-quantity once (vector :math:`\to` scalar, array :math:`\to` vector).  Using two
-brackets reduces the dimension twice (array :math:`\to` scalar).  Thus, a
-command that uses scalar fix values as input can also process elements of a
-vector or array.
+quantity once (vector :math:`\to` scalar, array :math:`\to` vector).
+Using two brackets reduces the dimension twice (array :math:`\to`
+scalar).  Thus, for example, a command that uses global scalar fix
+values as input can also process elements of a vector or array.
+Depending on the command, this can either be done directly using the
+syntax in the table, or by first defining a :doc:`variable <variable>`
+of the appropriate style to store the quantity, then using the
+variable as an input to the command.
 
-Note that commands and :doc:`variables <variable>` that use fix
-quantities typically do not allow for all kinds (e.g., a command may
-require a vector of values, not a scalar), and even if they do, the context
-in which they are called can be used to resolve which output is being
-requested.  This means there is no
-ambiguity about referring to a fix quantity as f_ID even if it
-produces, for example, both a scalar and vector.  The doc pages for
-various commands explain the details.
+Note that commands and :doc:`variables <variable>` which take fix
+outputs as input typically do not allow for all styles and kinds of
+data (e.g., a command may require global but not per-atom values, or
+it may require a vector of values, not a scalar).  This means there is
+typically no ambiguity about referring to a fix output as c_ID even if
+it produces, for example, both a scalar and vector.  The doc pages for
+various commands explain the details, including how any ambiguities
+are resolved.
 
 ----------
 
@@ -268,7 +281,6 @@ accelerated styles exist.
 * :doc:`momentum <fix_momentum>` - zero the linear and/or angular momentum of a group of atoms
 * :doc:`momentum/chunk <fix_momentum>` - zero the linear and/or angular momentum of a chunk of atoms
 * :doc:`move <fix_move>` - move atoms in a prescribed fashion
-* :doc:`mscg <fix_mscg>` - apply MSCG method for force-matching to generate coarse grain models
 * :doc:`msst <fix_msst>` - multi-scale shock technique (MSST) integration
 * :doc:`mvv/dpd <fix_mvv_dpd>` - DPD using the modified velocity-Verlet integration algorithm
 * :doc:`mvv/edpd <fix_mvv_dpd>` - constant energy DPD using the modified velocity-Verlet algorithm
@@ -334,6 +346,7 @@ accelerated styles exist.
 * :doc:`pour <fix_pour>` - pour new atoms/molecules into a granular simulation domain
 * :doc:`precession/spin <fix_precession_spin>` - apply a precession torque to each magnetic spin
 * :doc:`press/berendsen <fix_press_berendsen>` - pressure control by Berendsen barostat
+* :doc:`press/langevin <fix_press_langevin>` - pressure control by Langevin barostat
 * :doc:`print <fix_print>` - print text and variables during a simulation
 * :doc:`propel/self <fix_propel_self>` - model self-propelled particles
 * :doc:`property/atom <fix_property_atom>` - add customized per-atom values

doc/src/fix_ave_chunk.rst

@@ -541,10 +541,10 @@ Restrictions
 Related commands
 """"""""""""""""
 
-:doc:`compute <compute>`, :doc:`fix ave/atom <fix_ave_atom>`, `fix
-:doc:ave/histo <fix_ave_histo>`, :doc:`fix ave/time <fix_ave_time>`,
-:doc:`variable <variable>`, :doc:`fix ave/correlate
-:doc:<fix_ave_correlate>`, `fix ave/atogrid <fix_ave_grid>`
+:doc:`compute <compute>`, :doc:`fix ave/atom <fix_ave_atom>`,
+:doc:`fix ave/histo <fix_ave_histo>`, :doc:`fix ave/time <fix_ave_time>`,
+:doc:`variable <variable>`, :doc:`fix ave/correlate <fix_ave_correlate>`,
+:doc:`fix ave/grid <fix_ave_grid>`
 
 
 Default

doc/src/fix_ave_histo.rst

@@ -79,9 +79,10 @@ Description
 
 Use one or more values as inputs every few timesteps to create a
 single histogram.  The histogram can then be averaged over longer
-timescales.  The resulting histogram can be used by other :doc:`output commands <Howto_output>`, and can also be written to a file.  The
-fix ave/histo/weight command has identical syntax to fix ave/histo,
-except that exactly two values must be specified.  See details below.
+timescales.  The resulting histogram can be used by other :doc:`output
+commands <Howto_output>`, and can also be written to a file.  The fix
+ave/histo/weight command has identical syntax to fix ave/histo, except
+that exactly two values must be specified.  See details below.
 
 The group specified with this command is ignored for global and local
 input values.  For per-atom input values, only atoms in the group
@@ -96,14 +97,18 @@ different ways; see the discussion of the *beyond* keyword below.
 
 Each input value can be an atom attribute (position, velocity, force
 component) or can be the result of a :doc:`compute <compute>` or
-:doc:`fix <fix>` or the evaluation of an equal-style or vector-style or
-atom-style :doc:`variable <variable>`.  The set of input values can be
-either all global, all per-atom, or all local quantities.  Inputs of
-different kinds (e.g. global and per-atom) cannot be mixed.  Atom
-attributes are per-atom vector values.  See the page for
-individual "compute" and "fix" commands to see what kinds of
-quantities they generate.  See the optional *kind* keyword below for
-how to force the fix ave/histo command to disambiguate if necessary.
+:doc:`fix <fix>` or the evaluation of an equal-style or vector-style
+or atom-style :doc:`variable <variable>`.  The set of input values can
+be either all global, all per-atom, or all local quantities.  Inputs
+of different kinds (e.g. global and per-atom) cannot be mixed.  Atom
+attributes are per-atom vector values.  See the page for individual
+"compute" and "fix" commands to see what kinds of quantities they
+generate.
+
+Note that a compute or fix can produce multiple kinds of data (global,
+per-atom, local).  If LAMMPS cannot unambiguously determine which kind
+of data to use, the optional *kind* keyword discussed below can force
+the desired disambiguation.
 
 Note that the output of this command is a single histogram for all
 input values combined together, not one histogram per input value.
@@ -258,13 +263,14 @@ keyword is set to *vector*, then all input values must be global or
 per-atom or local vectors, or columns of global or per-atom or local
 arrays.
 
-The *kind* keyword only needs to be set if a compute or fix produces
-more than one kind of output (global, per-atom, local).  If this is
-not the case, then LAMMPS will determine what kind of input is
-provided and whether all the input arguments are consistent.  If a
-compute or fix produces more than one kind of output, the *kind*
-keyword should be used to specify which output will be used.  The
-remaining input arguments must still be consistent.
+The *kind* keyword only needs to be used if any of the specified input
+computes or fixes produce more than one kind of output (global,
+per-atom, local).  If not, LAMMPS will determine the kind of data all
+the inputs produce and verify it is all the same kind.  If not, an
+error will be triggered.  If a compute or fix produces more than one
+kind of output, the *kind* keyword should be used to specify which
+output will be used.  The other input arguments must still be
+consistent.
 
 The *beyond* keyword determines how input values that fall outside the
 *lo* to *hi* bounds are treated.  Values such that *lo* :math:`\le` value

doc/src/fix_deposit.rst

@@ -17,12 +17,16 @@ Syntax
 * M = insert a single atom or molecule every M steps
 * seed = random # seed (positive integer)
 * one or more keyword/value pairs may be appended to args
-* keyword = *region* or *id* or *global* or *local* or *near* or *gaussian* or *attempt* or *rate* or *vx* or *vy* or *vz* or *target* or *mol* or *molfrac* or *rigid* or *shake* or *orient* or *units*
+* keyword = *region* or *var* or *set* or *id* or *global* or *local* or *near* or *gaussian* or *attempt* or *rate* or *vx* or *vy* or *vz* or *target* or *mol* or *molfrac* or *rigid* or *shake* or *orient* or *units*
 
   .. parsed-literal::
 
        *region* value = region-ID
          region-ID = ID of region to use as insertion volume
+       *var* value = name = variable name to evaluate for test of atom creation
+       *set* values = dim name
+         dim = *x* or *y* or *z*
+         name = name of variable to set with x, y, or z atom position
        *id* value = *max* or *next*
          max = atom ID for new atom(s) is max ID of all current atoms plus one
          next = atom ID for new atom(s) increments by one for every deposition
@@ -193,17 +197,19 @@ simulation that is "nearby" the chosen x,y position.  In this context,
 particles is less than the *delta* setting.
 
 Once a trial x,y,z position has been selected, the insertion is only
-performed if no current atom in the simulation is within a distance R
-of any atom in the new particle, including the effect of periodic
-boundary conditions if applicable.  R is defined by the *near*
-keyword.  Note that the default value for R is 0.0, which will allow
-atoms to strongly overlap if you are inserting where other atoms are
-present.  This distance test is performed independently for each atom
-in an inserted molecule, based on the randomly rotated configuration
-of the molecule.  If this test fails, a new random position within the
-insertion volume is chosen and another trial is made.  Up to Q
-attempts are made.  If the particle is not successfully inserted,
-LAMMPS prints a warning message.
+performed if both the *near* and *var* keywords are satisfied (see below).
+If either the *near* or the *var* keyword is not satisfied, a new random
+position within the insertion volume is chosen and another trial is made.
+Up to Q attempts are made.  If one or more particle insertions are not
+successful, LAMMPS prints a warning message.
+
+The *near* keyword ensures that no current atom in the simulation is within
+a distance R of any atom in the new particle, including the effect of
+periodic boundary conditions if applicable.  Note that the default value
+for R is 0.0, which will allow atoms to strongly overlap if you are
+inserting where other atoms are present.  This distance test is performed
+independently for each atom in an inserted molecule, based on the randomly
+rotated configuration of the molecule.
 
 .. note::
 
@@ -214,6 +220,26 @@ LAMMPS prints a warning message.
    existing particle.  LAMMPS will issue a warning if R is smaller than
    this value, based on the radii of existing and inserted particles.
 
+.. versionadded:: 21Nov2023
+
+The *var* and *set* keywords can be used together to provide a criterion
+for accepting or rejecting the addition of an individual atom, based on its
+coordinates.  The *name* specified for the *var* keyword is the name of an
+:doc:`equal-style variable <variable>` that should evaluate to a zero or
+non-zero value based on one or two or three variables that will store the
+*x*, *y*, or *z* coordinates of an atom (one variable per coordinate).  If
+used, these other variables must be :doc:`internal-style variables
+<variable>` defined in the input script; their initial numeric value can be
+anything. They must be internal-style variables, because this command
+resets their values directly.  The *set* keyword is used to identify the
+names of these other variables, one variable for the *x*-coordinate of a
+created atom, one for *y*, and one for *z*.  When an atom is created, its
+:math:`(x,y,z)` coordinates become the values for any *set* variable that
+is defined.  The *var* variable is then evaluated.  If the returned value
+is 0.0, the atom is not created.  If it is non-zero, the atom is created.
+For an example of how to use these keywords, see the
+:doc:`create_atoms <create_atoms>` command.
+
 The *rate* option moves the insertion volume in the z direction (3d)
 or y direction (2d).  This enables particles to be inserted from a
 successively higher height over time.  Note that this parameter is
@@ -289,10 +315,11 @@ operation of the fix continues in an uninterrupted fashion.
    The fix will try to detect it and stop with an error.
 
 None of the :doc:`fix_modify <fix_modify>` options are relevant to this
-fix.  No global or per-atom quantities are stored by this fix for
-access by various :doc:`output commands <Howto_output>`.  No parameter
-of this fix can be used with the *start/stop* keywords of the
-:doc:`run <run>` command.  This fix is not invoked during :doc:`energy minimization <minimize>`.
+fix.  This fix computes a global scalar, which can be accessed by various
+output commands.  The scalar is the cumulative number of insertions.  The
+scalar value calculated by this fix is "intensive".  No parameter of this
+fix can be used with the *start/stop* keywords of the :doc:`run <run>`
+command.  This fix is not invoked during :doc:`energy minimization <minimize>`.
 
 Restrictions
 """"""""""""