Merge pull request #2120 from lammps/next_lammps_version

Update version strings for the next patch release

.github/CODEOWNERS

@@ -22,7 +22,6 @@ src/SPIN/*            @julient31
 src/USER-CGDNA/*      @ohenrich
 src/USER-CGSDK/*      @akohlmey
 src/USER-COLVARS/*    @giacomofiorin
-src/USER-DPD/*        @timattox
 src/USER-INTEL/*      @wmbrownintel
 src/USER-MANIFOLD/*   @Pakketeretet2
 src/USER-MEAMC/*      @martok
@@ -46,7 +45,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/USER-MISC/fix_bond_react.*      @jrgissing
+src/USER-REACTION/fix_bond_react.*  @jrgissing
 src/USER-MISC/*_grem.*              @dstelter92
 src/USER-MISC/compute_stress_mop*.* @RomainVermorel
 
@@ -116,6 +115,10 @@ src/min*                  @sjplimp @stanmoore1
 # tools
 tools/msi2lmp/*       @akohlmey
 tools/emacs/*         @HaoZeke
+tools/singularity/*   @akohlmey @rbberger
+
+# tests
+unittest/*            @akohlmey @rbberger
 
 # cmake
 cmake/*               @junghans @rbberger

.github/ISSUE_TEMPLATE/bug_report.md

@@ -9,24 +9,24 @@ assignees: ''
 
 **Summary**
 
-_Please provide a clear and concise description of what the bug is._
+<!--Please provide a clear and concise description of what the bug is.-->
 
 **LAMMPS Version and Platform**
 
-_Please specify precisely which LAMMPS version this issue was detected with (the first line of the output) and what platform (operating system and its version, hardware) you are running on. If possible, test with the most recent LAMMPS patch version_
+<!--Please specify precisely which LAMMPS version this issue was detected with (the first line of the output) and what platform (operating system and its version, hardware) you are running on. If possible, test with the most recent LAMMPS patch version-->
 
 **Expected Behavior**
 
-_Describe the expected behavior.  Quote from the LAMMPS manual where needed, or explain why the expected behavior is meaningful, especially when it differs from the manual_
+<!--Describe the expected behavior.  Quote from the LAMMPS manual where needed, or explain why the expected behavior is meaningful, especially when it differs from the manual-->
 
 **Actual Behavior**
 
-_Describe the actual behavior, how it differs from the expected behavior, and how this can be observed.  Try to be specific and do **not** use vague terms like "doesn't work" or "wrong result".  Do not assume that the person reading this has any experience with or knowledge of your specific area of research._
+<!--Describe the actual behavior, how it differs from the expected behavior, and how this can be observed.  Try to be specific and do **not** use vague terms like "doesn't work" or "wrong result".  Do not assume that the person reading this has any experience with or knowledge of your specific area of research.-->
 
 **Steps to Reproduce**
 
-_Describe the steps required to (quickly) reproduce the issue. You can attach (small) files to the section below or add URLs where to download an archive with all necessary files. Please try to create an input set that is as minimal and small as possible and reproduces the bug as quickly as possible. **NOTE:** the less effort and time it takes to reproduce your reported bug, the more likely it becomes, that somebody will look into it and fix the problem._
+<!--Describe the steps required to (quickly) reproduce the issue. You can attach (small) files to the section below or add URLs where to download an archive with all necessary files. Please try to create an input set that is as minimal and small as possible and reproduces the bug as quickly as possible. **NOTE:** the less effort and time it takes to reproduce your reported bug, the more likely it becomes, that somebody will look into it and fix the problem.-->
 
 **Further Information, Files, and Links**
 
-_Put any additional information here, attach relevant text or image files and URLs to external sites, e.g. relevant publications_
+<!--Put any additional information here, attach relevant text or image files and URLs to external sites, e.g. relevant publications-->

.github/ISSUE_TEMPLATE/feature_request.md

@@ -9,12 +9,12 @@ assignees: ''
 
 **Summary**
 
-_Please provide a brief and concise description of the suggested feature or change_
+<!--Please provide a brief and concise description of the suggested feature or change-->
 
 **Detailed Description**
 
-_Please explain how you would like to see LAMMPS enhanced, what feature(s) you are looking for, what specific problems this will solve. If possible, provide references to relevant background information like publications or web pages, and whether you are planning to implement the enhancement yourself or would like to participate in the implementation. If applicable add a reference to an existing bug report or issue that this will address._
+<!--Please explain how you would like to see LAMMPS enhanced, what feature(s) you are looking for, what specific problems this will solve. If possible, provide references to relevant background information like publications or web pages, and whether you are planning to implement the enhancement yourself or would like to participate in the implementation. If applicable add a reference to an existing bug report or issue that this will address.-->
 
 **Further Information, Files, and Links**
 
-_Put any additional information here, attach relevant text or image files and URLs to external sites, e.g. relevant publications_
+<!--Put any additional information here, attach relevant text or image files and URLs to external sites, e.g. relevant publications-->

.github/ISSUE_TEMPLATE/generic.md

@@ -9,13 +9,13 @@ assignees: ''
 
 **Summary**
 
-_Please provide a clear and concise description of what this issue report is about._
+<!--Please provide a clear and concise description of what this issue report is about.-->
 
 **LAMMPS Version and Platform**
 
-_Please specify precisely which LAMMPS version this issue was detected with (the first line of the output) and what platform (operating system and its version, hardware) you are running on. If possible, test with the most recent LAMMPS patch version_
+<!--Please specify precisely which LAMMPS version this issue was detected with (the first line of the output) and what platform (operating system and its version, hardware) you are running on. If possible, test with the most recent LAMMPS patch version-->
 
 **Details**
 
-_Please explain the issue in detail here_
+<!--Please explain the issue in detail here-->
 

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,14 +1,14 @@
 **Summary**
 
-_Briefly describe the new feature(s), enhancement(s), or bugfix(es) included in this pull request._
+<!--Briefly describe the new feature(s), enhancement(s), or bugfix(es) included in this pull request.-->
 
 **Related Issues**
 
-_If this addresses an open GitHub issue for this project, please mention the issue number here, and describe the relation. Use the phrases `fixes #221` or `closes #135`, when you want an issue to be automatically closed when the pull request is merged_
+<!--If this addresses an open GitHub issue for this project, please mention the issue number here, and describe the relation. Use the phrases `fixes #221` or `closes #135`, when you want an issue to be automatically closed when the pull request is merged-->
 
 **Author(s)**
 
-_Please state name and affiliation of the author or authors that should be credited with the changes in this pull request. If this pull request adds new files to the distribution, please also provide a suitable "long-lived" e-mail address (ideally something that can outlive your institution's e-mail, in case you change jobs) for the *corresponding* author, i.e. the person the LAMMPS developers can contact directly with questions and requests related to maintenance and support of this contributed code._
+<!--Please state name and affiliation of the author or authors that should be credited with the changes in this pull request. If this pull request adds new files to the distribution, please also provide a suitable "long-lived" e-mail address (ideally something that can outlive your institution's e-mail, in case you change jobs) for the *corresponding* author, i.e. the person the LAMMPS developers can contact directly with questions and requests related to maintenance and support of this contributed code.-->
 
 **Licensing**
 
@@ -16,15 +16,15 @@ By submitting this pull request, I agree, that my contribution will be included
 
 **Backward Compatibility**
 
-_Please state whether any changes in the pull request will break backward compatibility for inputs, and - if yes - explain what has been changed and why_
+<!--Please state whether any changes in the pull request will break backward compatibility for inputs, and - if yes - explain what has been changed and why-->
 
 **Implementation Notes**
 
-_Provide any relevant details about how the changes are implemented, how correctness was verified, how other features - if any - in LAMMPS are affected_
+<!--Provide any relevant details about how the changes are implemented, how correctness was verified, how other features - if any - in LAMMPS are affected-->
 
 **Post Submission Checklist**
 
-_Please check the fields below as they are completed **after** the pull request has been submitted. Delete lines that don't apply_
+<!--Please check the fields below as they are completed **after** the pull request has been submitted. Delete lines that don't apply-->
 
 - [ ] The feature or features in this pull request is complete
 - [ ] Licensing information is complete
@@ -39,6 +39,6 @@ _Please check the fields below as they are completed **after** the pull request
 
 **Further Information, Files, and Links**
 
-_Put any additional information here, attach relevant text or image files, and URLs to external sites (e.g. DOIs or webpages)_
+<!--Put any additional information here, attach relevant text or image files, and URLs to external sites (e.g. DOIs or webpages)-->
 
 

.github/PULL_REQUEST_TEMPLATE/bug_fix.md

@@ -9,15 +9,15 @@ assignees: ''
 
 **Summary**
 
-_Briefly describe the bug or bugs, that are eliminated by this pull request._
+<!--Briefly describe the bug or bugs, that are eliminated by this pull request.-->
 
 **Related Issue(s)**
 
-_If this request addresses or is related to an existing (open) GitHub issue, e.g. a bug report, mention the issue number number here following a pound sign (aka hashmark), e.g.`#222`._
+<!--If this request addresses or is related to an existing (open) GitHub issue, e.g. a bug report, mention the issue number number here following a pound sign (aka hashmark), e.g.`#222`.-->
 
 **Author(s)**
 
-_Please state name and affiliation of the author or authors that should be credited with the changes in this pull request_
+<!--Please state name and affiliation of the author or authors that should be credited with the changes in this pull request-->
 
 **Licensing**
 
@@ -25,18 +25,18 @@ By submitting this pull request I implicitly accept, that my submission is subje
 
 **Backward Compatibility**
 
-_Please state whether any changes in the pull request break backward compatibility for inputs, and - if yes - explain what has been changed and why_
+<!--Please state whether any changes in the pull request break backward compatibility for inputs, and - if yes - explain what has been changed and why-->
 
 **Detailed Description**
 
-_Provide any relevant details about how the fixed bug can be reproduced, how the changes are implemented, how correctness was verified, how other features - if any - in LAMMPS are affected_
+<!--Provide any relevant details about how the fixed bug can be reproduced, how the changes are implemented, how correctness was verified, how other features - if any - in LAMMPS are affected-->
 
 ## Post Submission Checklist
 
-_Please check the fields below as they are completed *after* the pull request is submitted_
+<!--Please check the fields below as they are completed *after* the pull request is submitted-->
 - [ ] The code in this pull request is complete
 - [ ] The source code follows the LAMMPS formatting guidelines
 
 ## Further Information, Files, and Links
 
-_Put any additional information here, attach relevant text or image files, and URLs to external sites (e.g. to download input decks for testing)_
+<!--Put any additional information here, attach relevant text or image files, and URLs to external sites (e.g. to download input decks for testing)-->

.github/PULL_REQUEST_TEMPLATE/maintenance_refactoring.md

@@ -9,15 +9,15 @@ assignees: ''
 
 **Summary**
 
-_Briefly describe the included changes._
+<!--Briefly describe the included changes.-->
 
 **Related Issue(s)**
 
-_If this request addresses or is related to an existing (open) GitHub issue, e.g. a bug report, mention the issue number number here following a pound sign (aka hashmark), e.g.`#222`.
+<!--If this request addresses or is related to an existing (open) GitHub issue, e.g. a bug report, mention the issue number number here following a pound sign (aka hashmark), e.g.`#222`.
 
 **Author(s)**
 
-_Please state name and affiliation of the author or authors that should be credited with the changes in this pull request_
+<!--Please state name and affiliation of the author or authors that should be credited with the changes in this pull request-->
 
 **Licensing**
 
@@ -25,11 +25,11 @@ By submitting this pull request I implicitly accept, that my submission is subje
 
 **Detailed Description**
 
-_Provide any relevant details about the included changes._
+<!--Provide any relevant details about the included changes.-->
 
 ## Post Submission Checklist
 
-_Please check the fields below as they are completed *after* the pull request is submitted_
+<!--Please check the fields below as they are completed *after* the pull request is submitted-->
 - [ ] The pull request is complete
 - [ ] The source code follows the LAMMPS formatting guidelines
 

.github/PULL_REQUEST_TEMPLATE/new_feature.md

@@ -9,34 +9,34 @@ assignees: ''
 
 **Summary**
 
-_Briefly describe the new feature(s) included in this pull request._
+<!--Briefly describe the new feature(s) included in this pull request.-->
 
 **Related Issues**
 
-_If this addresses an existing (open) GitHub issue, e.g. a feature request, mention the issue number here following a pound sign (aka hashmark), e.g. `#331`._
+<!--If this addresses an existing (open) GitHub issue, e.g. a feature request, mention the issue number here following a pound sign (aka hashmark), e.g. `#331`.-->
 
 **Author(s)**
 
-_Please state name and affiliation of the author or authors that should be credited with the features added in this pull request. Please provide a suitable "long-lived" e-mail address (e.g. from gmail, yahoo, outlook, etc.) for the *corresponding* author, i.e. the person the LAMMPS developers can contact directly with questions and requests related to maintenance and support of this code. now and in the future_
+<!--Please state name and affiliation of the author or authors that should be credited with the features added in this pull request. Please provide a suitable "long-lived" e-mail address (e.g. from gmail, yahoo, outlook, etc.) for the *corresponding* author, i.e. the person the LAMMPS developers can contact directly with questions and requests related to maintenance and support of this code. now and in the future-->
 
 **Licensing**
 
-_Please add *yes* or *no* to the following two statements (please contact @lammps/core if you have questions about this)_
+<!--Please add *yes* or *no* to the following two statements (please contact @lammps/core if you have questions about this)-->
 
 My contribution may be licensed as GPL v2 (default LAMMPS license):
 My contribution may be licensed as LGPL (for use as a library with proprietary software):
 
 **Backward Compatibility**
 
-_Please state if any of the changes in this pull request will affect backward compatibility for inputs, and - if yes - explain what has been changed and why_
+<!--Please state if any of the changes in this pull request will affect backward compatibility for inputs, and - if yes - explain what has been changed and why-->
 
 **Implementation Notes**
 
-_Provide any relevant details about how the new features are implemented, how correctness was verified, what platforms (OS, compiler, MPI, hardware, number of processors, accelerator(s)) it was tested on_
+<!--Provide any relevant details about how the new features are implemented, how correctness was verified, what platforms (OS, compiler, MPI, hardware, number of processors, accelerator(s)) it was tested on-->
 
 ## Post Submission Checklist
 
-_Please check the fields below as they are completed *after* the pull request has been submitted_
+<!--Please check the fields below as they are completed *after* the pull request has been submitted-->
 
 - [ ] The feature or features in this pull request is complete
 - [ ] Licensing information is complete
@@ -51,6 +51,6 @@ _Please check the fields below as they are completed *after* the pull request ha
 
 ## Further Information, Files, and Links
 
-_Put any additional information here, attach relevant text or image files, and URLs to external sites (e.g. DOIs or webpages)_
+<!--Put any additional information here, attach relevant text or image files, and URLs to external sites (e.g. DOIs or webpages)-->
 
 

.github/PULL_REQUEST_TEMPLATE/update_enhancement.md

@@ -9,11 +9,11 @@ assignees: ''
 
 **Summary**
 
-_Briefly describe what kind of updates or enhancements for a package or feature are included. If you are not the original author of the package or feature, please mention, whether your contribution was created independently or in collaboration/cooperation with the original author._
+<!--Briefly describe what kind of updates or enhancements for a package or feature are included. If you are not the original author of the package or feature, please mention, whether your contribution was created independently or in collaboration/cooperation with the original author.-->
 
 **Author(s)**
 
-_Please state name and affiliation of the author or authors that should be credited with the changes in this pull request_
+<!--Please state name and affiliation of the author or authors that should be credited with the changes in this pull request-->
 
 **Licensing**
 
@@ -21,15 +21,15 @@ By submitting this pull request I implicitly accept, that my submission is subje
 
 **Backward Compatibility**
 
-_Please state whether any changes in the pull request break backward compatibility for inputs, and - if yes - explain what has been changed and why_
+<!--Please state whether any changes in the pull request break backward compatibility for inputs, and - if yes - explain what has been changed and why-->
 
 **Implementation Notes**
 
-_Provide any relevant details about how the changes are implemented, how correctness was verified, how other features - if any - in LAMMPS are affected_
+<!--Provide any relevant details about how the changes are implemented, how correctness was verified, how other features - if any - in LAMMPS are affected-->
 
 **Post Submission Checklist**
 
-_Please check the fields below as they are completed_
+<!--Please check the fields below as they are completed-->
 - [ ] The feature or features in this pull request is complete
 - [ ] Suitable updates to the existing docs are included
 - [ ] One or more example input decks are included
@@ -37,6 +37,6 @@ _Please check the fields below as they are completed_
 
 **Further Information, Files, and Links**
 
-_Put any additional information here, attach relevant text or image files, and URLs to external sites (e.g. DOIs or webpages)_
+<!--Put any additional information here, attach relevant text or image files, and URLs to external sites (e.g. DOIs or webpages)-->
 
 

cmake/CMakeLists.txt

@@ -3,16 +3,24 @@
 # This file is part of LAMMPS
 # Created by Christoph Junghans and Richard Berger
 cmake_minimum_required(VERSION 3.10)
+# set policy to silence warnings about ignoring <PackageName>_ROOT but use it
+if(POLICY CMP0074)
+  cmake_policy(SET CMP0074 NEW)
+endif()
+########################################
 
 project(lammps CXX)
 set(SOVERSION 0)
-get_filename_component(LAMMPS_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../src ABSOLUTE)
-get_filename_component(LAMMPS_LIB_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../lib ABSOLUTE)
+
+get_filename_component(LAMMPS_DIR ${CMAKE_CURRENT_SOURCE_DIR}/.. ABSOLUTE)
 get_filename_component(LAMMPS_LIB_BINARY_DIR ${CMAKE_BINARY_DIR}/lib ABSOLUTE)
-get_filename_component(LAMMPS_DOC_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../doc ABSOLUTE)
-get_filename_component(LAMMPS_TOOLS_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../tools ABSOLUTE)
-get_filename_component(LAMMPS_PYTHON_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../python ABSOLUTE)
-get_filename_component(LAMMPS_POTENTIALS_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../potentials ABSOLUTE)
+
+set(LAMMPS_SOURCE_DIR     ${LAMMPS_DIR}/src)
+set(LAMMPS_LIB_SOURCE_DIR ${LAMMPS_DIR}/lib)
+set(LAMMPS_DOC_DIR        ${LAMMPS_DIR}/doc)
+set(LAMMPS_TOOLS_DIR      ${LAMMPS_DIR}/tools)
+set(LAMMPS_PYTHON_DIR     ${LAMMPS_DIR}/python)
+set(LAMMPS_POTENTIALS_DIR ${LAMMPS_DIR}/potentials)
 
 find_package(Git)
 
@@ -57,11 +65,11 @@ if(${CMAKE_CXX_COMPILER_ID} STREQUAL "Intel")
 endif()
 
 if(${CMAKE_CXX_COMPILER_ID} STREQUAL "GNU")
-  set(CMAKE_TUNE_DEFAULT "-ffast-math -march=native")
+  set(CMAKE_TUNE_DEFAULT "-march=native")
 endif()
 
 if(${CMAKE_CXX_COMPILER_ID} STREQUAL "Clang")
-  set(CMAKE_TUNE_DEFAULT "-ffast-math -march=native")
+  set(CMAKE_TUNE_DEFAULT "-march=native")
 endif()
 
 # we require C++11 without extensions
@@ -135,23 +143,20 @@ if(PKG_USER-ADIOS)
   target_link_libraries(lammps PRIVATE adios2::adios2)
 endif()
 
-if (CMAKE_SYSTEM_NAME STREQUAL Windows)
-  option(BUILD_MPI "Build MPI version" OFF)
-else()
-  # do MPI detection after language activation,
-  # in case MPI for these languages is required
+if(NOT CMAKE_CROSSCOMPILING)
   set(MPI_CXX_SKIP_MPICXX TRUE)
   find_package(MPI QUIET)
   option(BUILD_MPI "Build MPI version" ${MPI_FOUND})
+else()
+  option(BUILD_MPI "Build MPI version" OFF)
 endif()
 
 if(BUILD_MPI)
-  # We use a non-standard procedure to compile with MPI on windows
-  if (CMAKE_SYSTEM_NAME STREQUAL Windows)
+  # We use a non-standard procedure to cross-compile with MPI on Windows
+  if((CMAKE_SYSTEM_NAME STREQUAL Windows) AND CMAKE_CROSSCOMPILING)
     include(MPI4WIN)
     target_link_libraries(lammps PUBLIC MPI::MPI_CXX)
   else()
-    set(MPI_CXX_SKIP_MPICXX ON)
     find_package(MPI REQUIRED)
     target_link_libraries(lammps PUBLIC MPI::MPI_CXX)
     option(LAMMPS_LONGLONG_TO_LONG "Workaround if your system or MPI version does not recognize 'long long' data types" OFF)
@@ -163,9 +168,6 @@ else()
   enable_language(C)
   file(GLOB MPI_SOURCES ${LAMMPS_SOURCE_DIR}/STUBS/mpi.c)
   add_library(mpi_stubs STATIC ${MPI_SOURCES})
-  if(NOT BUILD_SHARED_LIBS)
-    install(TARGETS mpi_stubs EXPORT LAMMPS_Targets LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR} ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR})
-  endif()
   set_target_properties(mpi_stubs PROPERTIES OUTPUT_NAME lammps_mpi_stubs${LAMMPS_MACHINE})
   target_include_directories(mpi_stubs PUBLIC $<BUILD_INTERFACE:${LAMMPS_SOURCE_DIR}/STUBS> $<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}/lammps/mpi>)
   install(FILES ${LAMMPS_SOURCE_DIR}/STUBS/mpi.h DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/lammps/mpi)
@@ -252,9 +254,6 @@ if(PKG_MSCG OR PKG_USER-ATC OR PKG_USER-AWPMD OR PKG_USER-QUIP OR PKG_LATTE)
     enable_language(Fortran)
     file(GLOB LAPACK_SOURCES ${LAMMPS_LIB_SOURCE_DIR}/linalg/[^.]*.[fF])
     add_library(linalg STATIC ${LAPACK_SOURCES})
-    if(NOT BUILD_SHARED_LIBS)
-      install(TARGETS linalg EXPORT LAMMPS_Targets LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR} ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR})
-    endif()
     set_target_properties(linalg PROPERTIES OUTPUT_NAME lammps_linalg${LAMMPS_MACHINE})
     set(BLAS_LIBRARIES "$<TARGET_FILE:linalg>")
     set(LAPACK_LIBRARIES "$<TARGET_FILE:linalg>")
@@ -332,8 +331,9 @@ set(CMAKE_TUNE_FLAGS "${CMAKE_TUNE_DEFAULT}" CACHE STRING "Compiler specific opt
 separate_arguments(CMAKE_TUNE_FLAGS)
 include(CheckCXXCompilerFlag)
 foreach(_FLAG ${CMAKE_TUNE_FLAGS})
-  check_cxx_compiler_flag("${_FLAG}" COMPILER_SUPPORTS${_FLAG})
-  if(COMPILER_SUPPORTS${_FLAG})
+  string(REGEX REPLACE "[=\"]" "" _FLAGX ${_FLAG})
+  check_cxx_compiler_flag("${_FLAG}" COMPILER_SUPPORTS${_FLAGX})
+  if(COMPILER_SUPPORTS${_FLAGX})
     target_compile_options(lammps PRIVATE ${_FLAG})
   else()
     message(WARNING "${_FLAG} found in CMAKE_TUNE_FLAGS, but not supported by the compiler, skipping")
@@ -413,9 +413,6 @@ foreach(SIMPLE_LIB POEMS USER-ATC USER-AWPMD USER-H5MD)
       ${LAMMPS_LIB_SOURCE_DIR}/${PKG_LIB}/[^.]*.c
       ${LAMMPS_LIB_SOURCE_DIR}/${PKG_LIB}/[^.]*.cpp)
     add_library(${PKG_LIB} STATIC ${${PKG_LIB}_SOURCES})
-    if(NOT BUILD_SHARED_LIBS)
-      install(TARGETS ${PKG_LIB} EXPORT LAMMPS_Targets LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR} ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR})
-    endif()
     set_target_properties(${PKG_LIB} PROPERTIES OUTPUT_NAME lammps_${PKG_LIB}${LAMMPS_MACHINE})
     target_link_libraries(lammps PRIVATE ${PKG_LIB})
     if(PKG_LIB STREQUAL awpmd)
@@ -436,7 +433,12 @@ if(PKG_USER-ATC)
   if(LAMMPS_SIZES STREQUAL BIGBIG)
     message(FATAL_ERROR "The USER-ATC Package is not compatible with -DLAMMPS_BIGBIG")
   endif()
-  target_link_libraries(atc PRIVATE ${LAPACK_LIBRARIES} MPI::MPI_CXX)
+  target_link_libraries(atc PRIVATE ${LAPACK_LIBRARIES})
+  if(BUILD_MPI)
+    target_link_libraries(atc PRIVATE MPI::MPI_CXX)
+  else()
+    target_link_libraries(atc PRIVATE mpi_stubs)
+  endif()
   target_include_directories(atc PRIVATE ${LAMMPS_SOURCE_DIR})
   target_compile_definitions(atc PRIVATE -DLAMMPS_${LAMMPS_SIZES})
 endif()
@@ -497,7 +499,7 @@ execute_process(COMMAND ${CMAKE_COMMAND} -E copy_if_different "${LAMMPS_STYLE_HE
 # Generate lmpgitversion.h
 ######################################
 add_custom_target(gitversion COMMAND ${CMAKE_COMMAND}
-  -DCMAKE_CURRENT_SOURCE_DIR="${CMAKE_CURRENT_SOURCE_DIR}"
+  -DLAMMPS_DIR="${LAMMPS_DIR}"
   -DGIT_EXECUTABLE="${GIT_EXECUTABLE}"
   -DGIT_FOUND="${GIT_FOUND}"
   -DLAMMPS_STYLE_HEADERS_DIR="${LAMMPS_STYLE_HEADERS_DIR}"
@@ -522,14 +524,15 @@ endif()
 
 set_target_properties(lammps PROPERTIES OUTPUT_NAME lammps${LAMMPS_MACHINE})
 set_target_properties(lammps PROPERTIES SOVERSION ${SOVERSION})
-install(TARGETS lammps EXPORT LAMMPS_Targets LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR} ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR})
 target_include_directories(lammps PUBLIC $<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}>)
 file(MAKE_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/includes/lammps)
 foreach(_HEADER ${LAMMPS_CXX_HEADERS})
   add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/includes/lammps/${_HEADER} COMMAND ${CMAKE_COMMAND} -E copy_if_different ${LAMMPS_SOURCE_DIR}/${_HEADER} ${CMAKE_CURRENT_BINARY_DIR}/includes/lammps/${_HEADER} DEPENDS ${LAMMPS_SOURCE_DIR}/${_HEADER})
   add_custom_target(${_HEADER} DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/includes/lammps/${_HEADER})
   add_dependencies(lammps ${_HEADER})
-  install(FILES ${LAMMPS_SOURCE_DIR}/${_HEADER} DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/lammps)
+  if(BUILD_SHARED_LIBS)
+    install(FILES ${LAMMPS_SOURCE_DIR}/${_HEADER} DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/lammps)
+  endif()
 endforeach()
 target_include_directories(lammps INTERFACE $<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR}/includes>)
 add_library(LAMMPS::lammps ALIAS lammps)
@@ -538,15 +541,16 @@ set(LAMMPS_API_DEFINES)
 foreach(_DEF ${LAMMPS_DEFINES})
   set(LAMMPS_API_DEFINES "${LAMMPS_API_DEFINES} -D${_DEF}")
 endforeach()
-configure_file(pkgconfig/liblammps.pc.in ${CMAKE_CURRENT_BINARY_DIR}/liblammps${LAMMPS_MACHINE}.pc @ONLY)
-install(FILES ${CMAKE_CURRENT_BINARY_DIR}/liblammps${LAMMPS_MACHINE}.pc DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig)
-install(EXPORT LAMMPS_Targets FILE LAMMPS_Targets.cmake NAMESPACE LAMMPS:: DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/LAMMPS)
-file(GLOB MODULE_FILES ${CMAKE_CURRENT_SOURCE_DIR}/Modules/Find*.cmake)
-install(FILES ${MODULE_FILES} DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/LAMMPS)
-include(CMakePackageConfigHelpers)
-configure_file(LAMMPSConfig.cmake.in ${CMAKE_CURRENT_BINARY_DIR}/LAMMPSConfig.cmake @ONLY)
-write_basic_package_version_file("LAMMPSConfigVersion.cmake" VERSION ${PROJECT_VERSION} COMPATIBILITY ExactVersion)
-install(FILES "${CMAKE_CURRENT_BINARY_DIR}/LAMMPSConfig.cmake" "${CMAKE_CURRENT_BINARY_DIR}/LAMMPSConfigVersion.cmake" DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/LAMMPS)
+if(BUILD_SHARED_LIBS)
+  install(TARGETS lammps EXPORT LAMMPS_Targets LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR} ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR})
+  configure_file(pkgconfig/liblammps.pc.in ${CMAKE_CURRENT_BINARY_DIR}/liblammps${LAMMPS_MACHINE}.pc @ONLY)
+  install(FILES ${CMAKE_CURRENT_BINARY_DIR}/liblammps${LAMMPS_MACHINE}.pc DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig)
+  install(EXPORT LAMMPS_Targets FILE LAMMPS_Targets.cmake NAMESPACE LAMMPS:: DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/LAMMPS)
+  include(CMakePackageConfigHelpers)
+  configure_file(LAMMPSConfig.cmake.in ${CMAKE_CURRENT_BINARY_DIR}/LAMMPSConfig.cmake @ONLY)
+  write_basic_package_version_file("LAMMPSConfigVersion.cmake" VERSION ${PROJECT_VERSION} COMPATIBILITY ExactVersion)
+  install(FILES "${CMAKE_CURRENT_BINARY_DIR}/LAMMPSConfig.cmake" "${CMAKE_CURRENT_BINARY_DIR}/LAMMPSConfigVersion.cmake" DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/LAMMPS)
+endif()
 install(FILES ${LAMMPS_DOC_DIR}/lammps.1 DESTINATION ${CMAKE_INSTALL_MANDIR}/man1 RENAME ${LAMMPS_BINARY}.1)
 
 if(BUILD_TOOLS)
@@ -556,10 +560,16 @@ if(BUILD_TOOLS)
 
   include(CheckGeneratorSupport)
   if(CMAKE_GENERATOR_SUPPORT_FORTRAN)
-    enable_language(Fortran)
-    add_executable(chain.x ${LAMMPS_TOOLS_DIR}/chain.f)
-    target_link_libraries(chain.x PRIVATE ${CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES})
-    install(TARGETS chain.x DESTINATION ${CMAKE_INSTALL_BINDIR})
+    include(CheckLanguage)
+    check_language(Fortran)
+    if(CMAKE_Fortran_COMPILER)
+      enable_language(Fortran)
+      add_executable(chain.x ${LAMMPS_TOOLS_DIR}/chain.f)
+      target_link_libraries(chain.x PRIVATE ${CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES})
+      install(TARGETS chain.x DESTINATION ${CMAKE_INSTALL_BINDIR})
+    else()
+      message(WARNING "No suitable Fortran compiler found, skipping building 'chain.x'")
+    endif()
   else()
     message(WARNING "CMake build doesn't support fortran, skipping building 'chain.x'")
   endif()
@@ -705,6 +715,7 @@ else()
 endif()
 if(BUILD_MPI)
   message(STATUS "<<< MPI flags >>>
+-- MPI_defines:      ${MPI_CXX_COMPILE_DEFINITIONS}
 -- MPI includes:     ${MPI_CXX_INCLUDE_PATH}
 -- MPI libraries:    ${MPI_CXX_LIBRARIES};${MPI_Fortran_LIBRARIES}")
 endif()

cmake/LAMMPSConfig.cmake.in

@@ -1,87 +1,5 @@
-set(CMAKE_MODULE_PATH ${CMAKE_CURRENT_LIST_DIR})
 include(CMakeFindDependencyMacro)
 if(@BUILD_MPI@)
   find_dependency(MPI REQUIRED CXX)
 endif()
-if(@PKG_KSPACE@)
-  if(@FFT@ STREQUAL "FFTW3")
-    find_dependency(@FFTW@ REQUIRED MODULE)
-  endif()
-endif()
-if(NOT @BUILD_SHARED_LIBS@)
-  if(@BUILD_OMP@)
-    find_dependency(OpenMP REQUIRED)
-  endif()
-  if(@WITH_JPEG@)
-    find_dependency(JPEG REQUIRED)
-  endif()
-  if(@WITH_PNG@)
-    find_dependency(PNG REQUIRED)
-    find_dependency(ZLIB REQUIRED)
-  endif()
-  if(@PKG_KIM@)
-    find_dependency(PkgConfig REQUIRED)
-    pkg_check_modules(KIM-API REQUIRED IMPORTED_TARGET libkim-api>=@KIM-API_MIN_VERSION@)
-    if(@CURL_FOUND@)
-      find_dependency(CURL REQUIRED)
-    endif()
-  endif()
-  if(@PKG_USER-SMD@)
-    find_dependency(Eigen3 NO_MODULE REQUIRED)
-  endif()
-  if(@PKG_USER-SCAFACOS@)
-    find_dependency(PkgConfig REQUIRED)
-    find_ependency(GSL REQUIRED)
-    find_dependency(MPI REQUIRED C Fortran)
-    pkg_check_modules(SCAFACOS REQUIRED IMPORTED_TARGET scafacos)
-  endif()
-  if(@PKG_PYTHON@ AND NOT CMAKE_VERSION VERSION_LESS 3.12)
-    find_package(Python REQUIRED COMPONENTS Development)
-  endif()
-  if(@PKG_COMPRESS@)
-    find_dependency(ZLIB REQUIRED)
-  endif()
-  if(@PKG_KOKKOS@)
-    if(@EXTERNAL_KOKKOS@)
-      find_dependency(Kokkos 3 REQUIRED)
-    endif()
-  endif()
-  if(@PKG_VORONOI@)
-    find_dependency(VORO REQUIRED)
-  endif()
-  if(@PKG_USER-INTEL@)
-    if(@INTEL_LRT_MODE@ STREQUAL "THREADS")
-      find_dependency(Threads REQUIRED)
-    endif()
-    if(@TBB_MALLOC_FOUND@)
-      find_ependency(TBB_MALLOC REQUIRED)
-    endif()
-  endif()
-  if(@PKG_USER-ADIOS@)
-    find_ependency(ADIOS2 REQUIRED)
-  endif()
-  if(@PKG_LATTE@)
-    find_ependency(LATTE REQUIRED)
-  endif()
-  if(@PKG_MESSAGE@)
-    if(@MESSAGE_ZMQ@)
-      find_ependency(ZMQ REQUIRED)
-    endif()
-  endif()
-  if(@PKG_MSCG@)
-    find_ependency(GSL REQUIRED)
-    find_ependency(MSCG REQUIRED)
-  endif()
-  if(@USER-NETCDF@)
-    if(@NETCDF_FOUND@)
-      find_ependency(NetCDF REQUIRED)
-    endif()
-    if(@PNETCDF_FOUND@)
-      find_ependency(PNetCDF REQUIRED)
-    endif()
-  endif()
-  if(@PKG_QUIP@)
-    find_ependency(QUIP REQUIRED)
-  endif()
-endif()
 include("${CMAKE_CURRENT_LIST_DIR}/LAMMPS_Targets.cmake")

cmake/Modules/CodeCoverage.cmake

@@ -15,14 +15,35 @@ if(ENABLE_COVERAGE)
             gen_coverage_xml
             COMMAND ${GCOVR_BINARY} -s -x -r ${ABSOLUTE_LAMMPS_SOURCE_DIR} --object-directory=${CMAKE_BINARY_DIR} -o coverage.xml
             WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
-            COMMENT "Generating XML Coverage Report..."
+            COMMENT "Generating XML coverage report..."
         )
 
+        set(COVERAGE_HTML_DIR ${CMAKE_BINARY_DIR}/coverage_html)
+
+        add_custom_target(coverage_html_folder
+            COMMAND ${CMAKE_COMMAND} -E make_directory ${COVERAGE_HTML_DIR})
+
         add_custom_target(
             gen_coverage_html
-            COMMAND ${GCOVR_BINARY} -s  --html --html-details -r ${ABSOLUTE_LAMMPS_SOURCE_DIR} --object-directory=${CMAKE_BINARY_DIR} -o coverage.html
+            COMMAND ${GCOVR_BINARY} -s  --html --html-details -r ${ABSOLUTE_LAMMPS_SOURCE_DIR} --object-directory=${CMAKE_BINARY_DIR} -o ${COVERAGE_HTML_DIR}/index.html
             WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
-            COMMENT "Generating HTML Coverage Report..."
+            COMMENT "Generating HTML coverage report..."
         )
+        add_dependencies(gen_coverage_html coverage_html_folder)
+
+        add_custom_target(clean_coverage_html
+            ${CMAKE_COMMAND} -E remove_directory ${COVERAGE_HTML_DIR}
+            COMMENT "Deleting HTML coverage report..."
+        )
+
+        add_custom_target(reset_coverage
+            ${CMAKE_COMMAND} -E remove -f */*.gcda */*/*.gcda */*/*/*.gcda
+                              */*/*/*/*.gcda */*/*/*/*/*.gcda */*/*/*/*/*/*.gcda
+                              */*/*/*/*/*/*/*.gcda */*/*/*/*/*/*/*/*.gcda
+                              */*/*/*/*/*/*/*/*/*.gcda */*/*/*/*/*/*/*/*/*/*.gcda
+            WORKIND_DIRECTORY ${CMAKE_BINARY_DIR}
+            COMMENT "Deleting coverage data files..."
+        )
+        add_dependencies(reset_coverage clean_coverage_html)
     endif()
 endif()

cmake/Modules/FindLATTE.cmake

@@ -1,27 +0,0 @@
-# - Find latte
-# Find the native LATTE libraries.
-#
-#  LATTE_LIBRARIES    - List of libraries when using latte.
-#  LATTE_FOUND        - True if latte found.
-#
-
-find_library(LATTE_LIBRARY NAMES latte)
-
-include(FindPackageHandleStandardArgs)
-# handle the QUIETLY and REQUIRED arguments and set LATTE_FOUND to TRUE
-# if all listed variables are TRUE
-
-find_package_handle_standard_args(LATTE DEFAULT_MSG LATTE_LIBRARY)
-
-# Copy the results to the output variables and target.
-if(LATTE_FOUND)
-  set(LATTE_LIBRARIES ${LATTE_LIBRARY})
-
-  if(NOT TARGET LATTE::latte)
-    add_library(LATTE::latte UNKNOWN IMPORTED)
-    set_target_properties(LATTE::latte PROPERTIES
-      IMPORTED_LOCATION "${LATTE_LIBRARY}")
-  endif()
-endif()
-
-mark_as_advanced(LATTE_LIBRARY)

cmake/Modules/FindTBB_MALLOC.cmake

@@ -6,12 +6,12 @@
 #  TBB_MALLOC_FOUND        - True if tbb found.
 #
 
-
 ########################################################
 # TBB Malloc
 
 find_path(TBB_MALLOC_INCLUDE_DIR NAMES tbb/tbb.h PATHS $ENV{TBBROOT}/include)
-find_library(TBB_MALLOC_LIBRARY NAMES tbbmalloc PATHS $ENV{TBBROOT}/lib/intel64/gcc4.7
+find_library(TBB_MALLOC_LIBRARY NAMES tbbmalloc PATHS $ENV{TBBROOT}/lib/intel64/gcc4.8
+                                                      $ENV{TBBROOT}/lib/intel64/gcc4.7
                                                       $ENV{TBBROOT}/lib/intel64/gcc4.4
                                                       $ENV{TBBROOT}/lib/intel64/gcc4.1)
 

cmake/Modules/FindYAML.cmake

@@ -0,0 +1,30 @@
+# - Find libyaml
+# Find the native Yaml headers and libraries.
+#
+#  YAML_INCLUDE_DIRS - where to find yaml.h
+#  YAML_LIBRARIES    - List of libraries when using libyaml
+#  YAML_FOUND        - True if libyaml is found.
+#
+
+find_path(YAML_INCLUDE_DIR yaml.h PATH_SUFFIXES yaml)
+find_library(YAML_LIBRARY NAMES yaml)
+
+# handle the QUIET and REQUIRED arguments and
+# set YAML_FOUND to TRUE if all variables are non-zero
+include(FindPackageHandleStandardArgs)
+find_package_handle_standard_args(YAML DEFAULT_MSG YAML_LIBRARY YAML_INCLUDE_DIR)
+
+# Copy the results to the output variables and target.
+if(YAML_FOUND)
+  set(YAML_LIBRARIES ${YAML_LIBRARY})
+  set(YAML_INCLUDE_DIRS ${YAML_INCLUDE_DIR})
+
+  if(NOT TARGET Yaml::Yaml)
+    add_library(Yaml::Yaml UNKNOWN IMPORTED)
+    set_target_properties(Yaml::Yaml PROPERTIES
+      IMPORTED_LOCATION "${YAML_LIBRARY}"
+      INTERFACE_INCLUDE_DIRECTORIES "${YAML_INCLUDE_DIR}")
+  endif()
+endif()
+
+mark_as_advanced(YAML_INCLUDE_DIR YAML_LIBRARY)

cmake/Modules/GTest.cmake

@@ -0,0 +1,77 @@
+message(STATUS "Downloading and building Google Test library")
+
+if(CMAKE_BUILD_TYPE STREQUAL Debug)
+  set(GTEST_LIB_POSTFIX d)
+else()
+  set(GTEST_LIB_POSTFIX)
+endif()
+
+include(ExternalProject)
+ExternalProject_Add(googletest
+                    GIT_REPOSITORY  https://github.com/google/googletest.git
+                    GIT_TAG         release-1.10.0
+                    SOURCE_DIR      "${CMAKE_BINARY_DIR}/gtest-src"
+                    BINARY_DIR      "${CMAKE_BINARY_DIR}/gtest-build"
+                    CMAKE_ARGS      ${CMAKE_REQUEST_PIC} ${CMAKE_EXTRA_GTEST_OPTS}
+                                    -DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER}
+                                    -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR>
+                                    -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
+                                    -DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
+                                    -DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}
+                    BUILD_BYPRODUCTS <BINARY_DIR>/lib/${CMAKE_FIND_LIBRARY_PREFIXES}gtest${GTEST_LIB_POSTFIX}.a
+                                     <BINARY_DIR>/lib/${CMAKE_FIND_LIBRARY_PREFIXES}gmock${GTEST_LIB_POSTFIX}.a
+                                     <BINARY_DIR>/lib/${CMAKE_FIND_LIBRARY_PREFIXES}gtest_main${GTEST_LIB_POSTFIX}.a
+                                     <BINARY_DIR>/lib/${CMAKE_FIND_LIBRARY_PREFIXES}gmock_main${GTEST_LIB_POSTFIX}.a
+                    LOG_DOWNLOAD ON
+                    LOG_CONFIGURE ON
+                    LOG_BUILD ON
+                    INSTALL_COMMAND ""
+                    TEST_COMMAND    "")
+
+ExternalProject_Get_Property(googletest SOURCE_DIR)
+set(GTEST_INCLUDE_DIR ${SOURCE_DIR}/googletest/include)
+set(GMOCK_INCLUDE_DIR ${SOURCE_DIR}/googlemock/include)
+
+# workaround for CMake 3.10 on ubuntu 18.04
+file(MAKE_DIRECTORY ${GTEST_INCLUDE_DIR})
+file(MAKE_DIRECTORY ${GMOCK_INCLUDE_DIR})
+
+ExternalProject_Get_Property(googletest BINARY_DIR)
+set(GTEST_LIBRARY_PATH ${BINARY_DIR}/lib/${CMAKE_FIND_LIBRARY_PREFIXES}gtest${GTEST_LIB_POSTFIX}.a)
+set(GMOCK_LIBRARY_PATH ${BINARY_DIR}/lib/${CMAKE_FIND_LIBRARY_PREFIXES}gmock${GTEST_LIB_POSTFIX}.a)
+set(GTEST_MAIN_LIBRARY_PATH ${BINARY_DIR}/lib/${CMAKE_FIND_LIBRARY_PREFIXES}gtest_main${GTEST_LIB_POSTFIX}.a)
+set(GMOCK_MAIN_LIBRARY_PATH ${BINARY_DIR}/lib/${CMAKE_FIND_LIBRARY_PREFIXES}gmock_main${GTEST_LIB_POSTFIX}.a)
+
+# Prevent GoogleTest from overriding our compiler/linker options
+# when building with Visual Studio
+set(gtest_force_shared_crt ON CACHE BOOL "" FORCE)
+
+find_package(Threads QUIET)
+
+add_library(GTest::GTest UNKNOWN IMPORTED)
+set_target_properties(GTest::GTest PROPERTIES
+        IMPORTED_LOCATION ${GTEST_LIBRARY_PATH}
+        INTERFACE_INCLUDE_DIRECTORIES ${GTEST_INCLUDE_DIR}
+        IMPORTED_LINK_INTERFACE_LIBRARIES ${CMAKE_THREAD_LIBS_INIT})
+add_dependencies(GTest::GTest googletest)
+
+add_library(GTest::GMock UNKNOWN IMPORTED)
+set_target_properties(GTest::GMock PROPERTIES
+        IMPORTED_LOCATION ${GMOCK_LIBRARY_PATH}
+        INTERFACE_INCLUDE_DIRECTORIES ${GMOCK_INCLUDE_DIR}
+        IMPORTED_LINK_INTERFACE_LIBRARIES ${CMAKE_THREAD_LIBS_INIT})
+add_dependencies(GTest::GMock googletest)
+
+add_library(GTest::GTestMain UNKNOWN IMPORTED)
+set_target_properties(GTest::GTestMain PROPERTIES
+        IMPORTED_LOCATION ${GTEST_MAIN_LIBRARY_PATH}
+        INTERFACE_INCLUDE_DIRECTORIES ${GTEST_INCLUDE_DIR}
+        IMPORTED_LINK_INTERFACE_LIBRARIES ${CMAKE_THREAD_LIBS_INIT})
+add_dependencies(GTest::GTestMain googletest)
+
+add_library(GTest::GMockMain UNKNOWN IMPORTED)
+set_target_properties(GTest::GMockMain PROPERTIES
+        IMPORTED_LOCATION ${GMOCK_MAIN_LIBRARY_PATH}
+        INTERFACE_INCLUDE_DIRECTORIES ${GMOCK_INCLUDE_DIR}
+        IMPORTED_LINK_INTERFACE_LIBRARIES ${CMAKE_THREAD_LIBS_INIT})
+add_dependencies(GTest::GMockMain googletest)

cmake/Modules/MPI4WIN.cmake

@@ -23,3 +23,8 @@ set_target_properties(MPI::MPI_CXX PROPERTIES
   INTERFACE_INCLUDE_DIRECTORIES "${SOURCE_DIR}/include"
   INTERFACE_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
 add_dependencies(MPI::MPI_CXX mpi4win_build)
+
+# set variables for status reporting at the end of CMake run
+set(MPI_CXX_INCLUDE_PATH "${SOURCE_DIR}/include")
+set(MPI_CXX_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
+set(MPI_CXX_LIBRARIES "${SOURCE_DIR}/lib/libmpi.a")

cmake/Modules/Packages/GPU.cmake

@@ -330,7 +330,7 @@ elseif(GPU_API STREQUAL "HIP")
 
   if(HIP_PLATFORM STREQUAL "nvcc")
     target_compile_definitions(gpu PRIVATE -D__HIP_PLATFORM_NVCC__)
-    target_include_directories(gpu PRIVATE ${HIP_ROOT_DIR}/include)
+    target_include_directories(gpu PRIVATE ${HIP_ROOT_DIR}/../include)
     target_include_directories(gpu PRIVATE ${CUDA_INCLUDE_DIRS})
     target_link_libraries(gpu PRIVATE ${CUDA_LIBRARIES} ${CUDA_CUDA_LIBRARY})
 
@@ -338,6 +338,12 @@ elseif(GPU_API STREQUAL "HIP")
     target_include_directories(hip_get_devices PRIVATE ${HIP_ROOT_DIR}/include)
     target_include_directories(hip_get_devices PRIVATE ${CUDA_INCLUDE_DIRS})
     target_link_libraries(hip_get_devices PRIVATE ${CUDA_LIBRARIES} ${CUDA_CUDA_LIBRARY})
+  elseif(HIP_PLATFORM STREQUAL "hcc")
+    target_compile_definitions(gpu PRIVATE -D__HIP_PLATFORM_HCC__)
+    target_include_directories(gpu PRIVATE ${HIP_ROOT_DIR}/../include)
+
+    target_compile_definitions(hip_get_devices PRIVATE -D__HIP_PLATFORM_HCC__)
+    target_include_directories(hip_get_devices PRIVATE ${HIP_ROOT_DIR}/../include)
   endif()
 
   target_link_libraries(lammps PRIVATE gpu)
@@ -353,9 +359,11 @@ RegisterStylesExt(${GPU_SOURCES_DIR} gpu GPU_SOURCES)
 
 get_property(GPU_SOURCES GLOBAL PROPERTY GPU_SOURCES)
 
-target_link_libraries(gpu PRIVATE MPI::MPI_CXX)
-if(NOT BUILD_SHARED_LIBS)
-  install(TARGETS gpu EXPORT LAMMPS_Targets LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR} ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR})
+if(NOT BUILD_MPI)
+  # mpistubs is aliased to MPI::MPI_CXX, but older versions of cmake won't work forward the include path
+  target_link_libraries(gpu PRIVATE mpi_stubs)
+else()
+  target_link_libraries(gpu PRIVATE MPI::MPI_CXX)
 endif()
 target_compile_definitions(gpu PRIVATE -DLAMMPS_${LAMMPS_SIZES})
 set_target_properties(gpu PROPERTIES OUTPUT_NAME lammps_gpu${LAMMPS_MACHINE})

cmake/Modules/Packages/KIM.cmake

@@ -1,7 +1,12 @@
 set(KIM-API_MIN_VERSION 2.1.3)
 find_package(CURL)
 if(CURL_FOUND)
-  target_link_libraries(lammps PRIVATE CURL::libcurl)
+  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)
@@ -51,9 +56,6 @@ if(DOWNLOAD_KIM)
     INTERFACE_INCLUDE_DIRECTORIES "${INSTALL_DIR}/include/kim-api")
   target_link_libraries(lammps PRIVATE LAMMPS::KIM)
   add_dependencies(LAMMPS::KIM kim_build)
-  if(NOT BUILD_SHARED_LIBS)
-    install(CODE "MESSAGE(FATAL_ERROR \"Installing liblammps with downloaded libraries is currently not supported.\")")
-  endif()
 else()
   find_package(PkgConfig REQUIRED)
   pkg_check_modules(KIM-API REQUIRED IMPORTED_TARGET libkim-api>=${KIM-API_MIN_VERSION})

cmake/Modules/Packages/KOKKOS.cmake

@@ -14,16 +14,30 @@ endif()
 option(EXTERNAL_KOKKOS "Build against external kokkos library" OFF)
 option(DOWNLOAD_KOKKOS "Download the KOKKOS library instead of using the bundled one" OFF)
 if(DOWNLOAD_KOKKOS)
+  # extract Kokkos-related variables and values so we can forward them to the Kokkos library build
+  get_cmake_property(_VARS VARIABLES)
+  list(FILTER _VARS INCLUDE REGEX ^Kokkos_)
+  foreach(_VAR IN LISTS _VARS)
+    list(APPEND KOKKOS_LIB_BUILD_ARGS "-D${_VAR}=${${_VAR}}")
+  endforeach()
   message(STATUS "KOKKOS download requested - we will build our own")
-  file(DOWNLOAD https://github.com/kokkos/kokkos/compare/3.0.00...stanmoore1:lammps.diff ${CMAKE_CURRENT_BINARY_DIR}/kokkos-lammps.patch)
+  list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_INSTALL_PREFIX=<INSTALL_DIR>")
+  if(CMAKE_REQUEST_PIC)
+    list(APPEND KOKKOS_LIB_BUILD_ARGS ${CMAKE_REQUEST_PIC})
+  endif()
+  # append other CMake variables that need to be forwarded to CMAKE_ARGS
+  list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}")
+  list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_INSTALL_LIBDIR=lib")
+  list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}")
+  list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER}")
+  list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_CXX_STANDARD=${CMAKE_CXX_STANDARD}")
+  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)
   ExternalProject_Add(kokkos_build
-    URL https://github.com/kokkos/kokkos/archive/3.0.00.tar.gz
-    URL_MD5 281c7093aa3a603276e93abdf4be23b9
-    PATCH_COMMAND patch -p1 < ${CMAKE_CURRENT_BINARY_DIR}/kokkos-lammps.patch
-    CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR> ${CMAKE_REQUEST_PIC}
-    -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE} -DCMAKE_INSTALL_LIBDIR=lib
-    -DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM} -DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}
+    URL https://github.com/kokkos/kokkos/archive/3.1.01.tar.gz
+    URL_MD5 3ccb2100f7fc316891e7dad3bc33fa37
+    CMAKE_ARGS ${KOKKOS_LIB_BUILD_ARGS}
     BUILD_BYPRODUCTS <INSTALL_DIR>/lib/libkokkoscore.a
   )
   ExternalProject_get_property(kokkos_build INSTALL_DIR)
@@ -35,14 +49,8 @@ if(DOWNLOAD_KOKKOS)
     INTERFACE_LINK_LIBRARIES ${CMAKE_DL_LIBS})
   target_link_libraries(lammps PRIVATE LAMMPS::KOKKOS)
   add_dependencies(LAMMPS::KOKKOS kokkos_build)
-  if(NOT BUILD_SHARED_LIBS)
-    install(CODE "MESSAGE(FATAL_ERROR \"Installing liblammps with downloaded libraries is currently not supported.\")")
-  endif()
 elseif(EXTERNAL_KOKKOS)
-  find_package(Kokkos 3)
-  if(NOT Kokkos_FOUND)
-    message(FATAL_ERROR "KOKKOS library not found, help CMake to find it by setting KOKKOS_LIBRARY, or set DOWNLOAD_KOKKOS=ON to download it")
-  endif()
+  find_package(Kokkos 3.1.01 REQUIRED CONFIG)
   target_link_libraries(lammps PRIVATE Kokkos::kokkos)
 else()
   set(LAMMPS_LIB_KOKKOS_SRC_DIR ${LAMMPS_LIB_SOURCE_DIR}/kokkos)

cmake/Modules/Packages/KSPACE.cmake

@@ -2,7 +2,7 @@ option(FFT_SINGLE "Use single precision FFTs instead of double precision FFTs" O
 set(FFTW "FFTW3")
 if(FFT_SINGLE)
   set(FFTW "FFTW3F")
-  target_compile_definitions(lammps PUBLIC -DFFT_SINGLE)
+  target_compile_definitions(lammps PRIVATE -DFFT_SINGLE)
 endif()
 find_package(${FFTW} QUIET)
 if(${FFTW}_FOUND)
@@ -17,8 +17,8 @@ string(TOUPPER ${FFT} FFT)
 
 if(FFT STREQUAL "FFTW3")
   find_package(${FFTW} REQUIRED)
-  target_compile_definitions(lammps PUBLIC -DFFT_FFTW3)
-  target_link_libraries(lammps PUBLIC ${FFTW}::${FFTW})
+  target_compile_definitions(lammps PRIVATE -DFFT_FFTW3)
+  target_link_libraries(lammps PRIVATE ${FFTW}::${FFTW})
   if(FFTW3_OMP_LIBRARY OR FFTW3F_OMP_LIBRARY)
     option(FFT_FFTW_THREADS "Use threaded FFTW library" ON)
   else()

cmake/Modules/Packages/LATTE.cmake

@@ -1,5 +1,12 @@
 enable_language(Fortran)
-find_package(LATTE)
+
+# using lammps in a super-build setting
+if(TARGET LATTE::latte)
+  target_link_libraries(lammps PRIVATE LATTE::latte)
+  return()
+endif()
+
+find_package(LATTE 1.2.2 CONFIG)
 if(LATTE_FOUND)
   set(DOWNLOAD_LATTE_DEFAULT OFF)
 else()
@@ -10,8 +17,8 @@ if(DOWNLOAD_LATTE)
   message(STATUS "LATTE download requested - we will build our own")
   include(ExternalProject)
   ExternalProject_Add(latte_build
-    URL https://github.com/lanl/LATTE/archive/v1.2.1.tar.gz
-    URL_MD5 85ac414fdada2d04619c8f936344df14
+    URL https://github.com/lanl/LATTE/archive/v1.2.2.tar.gz
+    URL_MD5 820e73a457ced178c08c71389a385de7
     SOURCE_SUBDIR cmake
     CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR> ${CMAKE_REQUEST_PIC} -DCMAKE_INSTALL_LIBDIR=lib
     -DBLAS_LIBRARIES=${BLAS_LIBRARIES} -DLAPACK_LIBRARIES=${LAPACK_LIBRARIES}
@@ -27,13 +34,7 @@ if(DOWNLOAD_LATTE)
     INTERFACE_LINK_LIBRARIES "${LAPACK_LIBRARIES}")
   target_link_libraries(lammps PRIVATE LAMMPS::LATTE)
   add_dependencies(LAMMPS::LATTE latte_build)
-  if(NOT BUILD_SHARED_LIBS)
-    install(CODE "MESSAGE(FATAL_ERROR \"Installing liblammps with downloaded libraries is currently not supported.\")")
-  endif()
 else()
-  find_package(LATTE)
-  if(NOT LATTE_FOUND)
-    message(FATAL_ERROR "LATTE library not found, help CMake to find it by setting LATTE_LIBRARY, or set DOWNLOAD_LATTE=ON to download it")
-  endif()
+  find_package(LATTE 1.2.2 REQUIRED CONFIG)
   target_link_libraries(lammps PRIVATE LATTE::latte)
 endif()

cmake/Modules/Packages/MESSAGE.cmake

@@ -7,9 +7,6 @@ file(GLOB_RECURSE cslib_SOURCES ${LAMMPS_LIB_SOURCE_DIR}/message/cslib/[^.]*.F
     ${LAMMPS_LIB_SOURCE_DIR}/message/cslib/[^.]*.cpp)
 
 add_library(cslib STATIC ${cslib_SOURCES})
-if(NOT BUILD_SHARED_LIBS)
-  install(TARGETS cslib EXPORT LAMMPS_Targets LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR} ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR})
-endif()
 target_compile_definitions(cslib PRIVATE -DLAMMPS_${LAMMPS_SIZES})
 set_target_properties(cslib PROPERTIES OUTPUT_NAME lammps_cslib${LAMMPS_MACHINE})
 if(BUILD_MPI)

cmake/Modules/Packages/MSCG.cmake

@@ -35,9 +35,6 @@ if(DOWNLOAD_MSCG)
     INTERFACE_LINK_LIBRARIES "${LAPACK_LIBRARIES}")
   target_link_libraries(lammps PRIVATE LAMMPS::MSCG)
   add_dependencies(LAMMPS::MSCG mscg_build)
-  if(NOT BUILD_SHARED_LIBS)
-    install(CODE "MESSAGE(FATAL_ERROR \"Installing liblammps with downloaded libraries is currently not supported.\")")
-  endif()
 else()
   find_package(MSCG)
   if(NOT MSCG_FOUND)

cmake/Modules/Packages/USER-COLVARS.cmake

@@ -9,9 +9,6 @@ if(COLVARS_LEPTON)
   set(LEPTON_DIR ${LAMMPS_LIB_SOURCE_DIR}/colvars/lepton)
   file(GLOB LEPTON_SOURCES ${LEPTON_DIR}/src/[^.]*.cpp)
   add_library(lepton STATIC ${LEPTON_SOURCES})
-  if(NOT BUILD_SHARED_LIBS)
-    install(TARGETS lepton EXPORT LAMMPS_Targets LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR} ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR})
-  endif()
   # Change the define below to LEPTON_BUILDING_SHARED_LIBRARY when linking Lepton as a DLL with MSVC
   target_compile_definitions(lepton PRIVATE -DLEPTON_BUILDING_STATIC_LIBRARY)
   set_target_properties(lepton PROPERTIES OUTPUT_NAME lammps_lepton${LAMMPS_MACHINE})
@@ -19,9 +16,6 @@ if(COLVARS_LEPTON)
 endif()
 
 add_library(colvars STATIC ${COLVARS_SOURCES})
-if(NOT BUILD_SHARED_LIBS)
-  install(TARGETS colvars EXPORT LAMMPS_Targets LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR} ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR})
-endif()
 target_compile_definitions(colvars PRIVATE -DLAMMPS_${LAMMPS_SIZES})
 set_target_properties(colvars PROPERTIES OUTPUT_NAME lammps_colvars${LAMMPS_MACHINE})
 target_include_directories(colvars PUBLIC ${LAMMPS_LIB_SOURCE_DIR}/colvars)

cmake/Modules/Packages/USER-MOLFILE.cmake

@@ -1,8 +1,5 @@
 set(MOLFILE_INCLUDE_DIRS "${LAMMPS_LIB_SOURCE_DIR}/molfile" CACHE STRING "Path to VMD molfile plugin headers")
 add_library(molfile INTERFACE)
-if(NOT BUILD_SHARED_LIBS)
-  install(TARGETS molfile EXPORT LAMMPS_Targets LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR} ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR})
-endif()
 target_include_directories(molfile INTERFACE ${MOLFILE_INCLUDE_DIRS})
 # no need to link with -ldl on windows
 if(NOT ${CMAKE_SYSTEM_NAME} STREQUAL "Windows")

cmake/Modules/Packages/USER-NETCDF.cmake

@@ -1,11 +1,17 @@
 # USER-NETCDF can use NetCDF, Parallel NetCDF (PNetCDF), or both. At least one necessary.
 # NetCDF library enables dump style "netcdf", while PNetCDF enables dump style "netcdf/mpiio"
-find_package(NetCDF)
-if(NETCDF_FOUND)
-  find_package(PNetCDF)
-else(NETCDF_FOUND)
-  find_package(PNetCDF REQUIRED)
-endif(NETCDF_FOUND)
+
+# may use NetCDF or PNetCDF with MPI, but must have NetCDF without
+if(NOT BUILD_MPI)
+  find_package(NetCDF REQUIRED)
+else()
+  find_package(NetCDF)
+  if(NETCDF_FOUND)
+    find_package(PNetCDF)
+  else()
+    find_package(PNetCDF REQUIRED)
+  endif()
+endif()
 
 if(NETCDF_FOUND)
   target_link_libraries(lammps PRIVATE NetCDF::NetCDF)

cmake/Modules/Packages/USER-PLUMED.cmake

@@ -70,16 +70,12 @@ if(DOWNLOAD_PLUMED)
   ExternalProject_get_property(plumed_build INSTALL_DIR)
   add_library(LAMMPS::PLUMED UNKNOWN IMPORTED)
   add_dependencies(LAMMPS::PLUMED plumed_build)
-  if(NOT BUILD_SHARED_LIBS)
-    install(CODE "MESSAGE(FATAL_ERROR \"Installing liblammps with downloaded libraries is currently not supported.\")")
-  endif()
   if(PLUMED_MODE STREQUAL "STATIC")
-    set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_COMPILE_DEFINITIONS "__PLUMED_WRAPPER_CXX=1")
     set_target_properties(LAMMPS::PLUMED PROPERTIES IMPORTED_LOCATION ${INSTALL_DIR}/lib/libplumed.a INTERFACE_LINK_LIBRARIES "${PLUMED_LINK_LIBS};${CMAKE_DL_LIBS}")
   elseif(PLUMED_MODE STREQUAL "SHARED")
     set_target_properties(LAMMPS::PLUMED PROPERTIES IMPORTED_LOCATION ${INSTALL_DIR}/lib/libplumed${CMAKE_SHARED_LIBRARY_SUFFIX} INTERFACE_LINK_LIBRARIES "${INSTALL_DIR}/lib/libplumedKernel${CMAKE_SHARED_LIBRARY_SUFFIX};${CMAKE_DL_LIBS}")
   elseif(PLUMED_MODE STREQUAL "RUNTIME")
-    set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_COMPILE_DEFINITIONS "__PLUMED_HAS_DLOPEN=1;__PLUMED_DEFAULT_KERNEL=${INSTALL_DIR}/lib/libplumedKernel${CMAKE_SHARED_LIBRARY_SUFFIX}")
+    set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_COMPILE_DEFINITIONS "__PLUMED_DEFAULT_KERNEL=${INSTALL_DIR}/lib/libplumedKernel${CMAKE_SHARED_LIBRARY_SUFFIX}")
     set_target_properties(LAMMPS::PLUMED PROPERTIES IMPORTED_LOCATION ${INSTALL_DIR}/lib/libplumedWrapper.a INTERFACE_LINK_LIBRARIES "${CMAKE_DL_LIBS}")
   endif()
   set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_INCLUDE_DIRECTORIES ${INSTALL_DIR}/include)
@@ -89,12 +85,11 @@ else()
   pkg_check_modules(PLUMED REQUIRED plumed)
   add_library(LAMMPS::PLUMED INTERFACE IMPORTED)
   if(PLUMED_MODE STREQUAL "STATIC")
-    set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_COMPILE_DEFINITIONS "__PLUMED_WRAPPER_CXX=1")
     include(${PLUMED_LIBDIR}/plumed/src/lib/Plumed.cmake.static)
   elseif(PLUMED_MODE STREQUAL "SHARED")
     include(${PLUMED_LIBDIR}/plumed/src/lib/Plumed.cmake.shared)
   elseif(PLUMED_MODE STREQUAL "RUNTIME")
-    set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_COMPILE_DEFINITIONS "__PLUMED_HAS_DLOPEN=1;__PLUMED_DEFAULT_KERNEL=${PLUMED_LIBDIR}/libplumedKernel${CMAKE_SHARED_LIBRARY_SUFFIX}")
+    set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_COMPILE_DEFINITIONS "__PLUMED_DEFAULT_KERNEL=${PLUMED_LIBDIR}/libplumedKernel${CMAKE_SHARED_LIBRARY_SUFFIX}")
     include(${PLUMED_LIBDIR}/plumed/src/lib/Plumed.cmake.runtime)
   endif()
   set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_LINK_LIBRARIES "${PLUMED_LOAD}")

cmake/Modules/Packages/USER-QMMM.cmake

@@ -1,12 +1,6 @@
 enable_language(C)
 
-if(NOT BUILD_SHARED_LIBS)
-  message(WARNING "It is recommended to use BUILD_SHARED_LIBS=yes with USER-QMMM")
-endif()
 add_library(qmmm STATIC ${LAMMPS_LIB_SOURCE_DIR}/qmmm/libqmmm.c)
-if(NOT BUILD_SHARED_LIBS)
-  install(TARGETS qmmm EXPORT LAMMPS_Targets LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR} ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR})
-endif()
 set_target_properties(qmmm PROPERTIES OUTPUT_NAME lammps_qmmm${LAMMPS_MACHINE})
 target_link_libraries(lammps PRIVATE qmmm)
 target_include_directories(qmmm PUBLIC ${LAMMPS_LIB_SOURCE_DIR}/qmmm)

cmake/Modules/Packages/USER-SCAFACOS.cmake

@@ -52,9 +52,6 @@ if(DOWNLOAD_SCAFACOS)
     INTERFACE_LINK_LIBRARIES "${INSTALL_DIR}/lib/libfcs.a;${INSTALL_DIR}/lib/libfcs_direct.a;${INSTALL_DIR}/lib/libfcs_ewald.a;${INSTALL_DIR}/lib/libfcs_fmm.a;${INSTALL_DIR}/lib/libfcs_p2nfft.a;${INSTALL_DIR}/lib/libfcs_p3m.a;GSL::gsl;${INSTALL_DIR}/lib/libfcs_near.a;${INSTALL_DIR}/lib/libfcs_gridsort.a;${INSTALL_DIR}/lib/libfcs_resort.a;${INSTALL_DIR}/lib/libfcs_redist.a;${INSTALL_DIR}/lib/libfcs_common.a;${INSTALL_DIR}/lib/libfcs_pnfft.a;${INSTALL_DIR}/lib/libfcs_pfft.a;${INSTALL_DIR}/lib/libfcs_fftw3_mpi.a;${INSTALL_DIR}/lib/libfcs_fftw3.a;MPI::MPI_Fortran;MPI::MPI_C")
   target_link_libraries(lammps PRIVATE LAMMPS::SCAFACOS)
   add_dependencies(LAMMPS::SCAFACOS scafacos_build)
-  if(NOT BUILD_SHARED_LIBS)
-    install(CODE "MESSAGE(FATAL_ERROR \"Installing liblammps with downloaded libraries is currently not supported.\")")
-  endif()
 else()
   find_package(PkgConfig REQUIRED)
   pkg_check_modules(SCAFACOS REQUIRED IMPORTED_TARGET scafacos)

cmake/Modules/Packages/USER-SMD.cmake

@@ -18,9 +18,6 @@ if(DOWNLOAD_EIGEN3)
   set_target_properties(LAMMPS::EIGEN3 PROPERTIES INTERFACE_INCLUDE_DIRECTORIES "${SOURCE_DIR}")
   target_link_libraries(lammps PRIVATE LAMMPS::EIGEN3)
   add_dependencies(LAMMPS::EIGEN3 Eigen3_build)
-  if(NOT BUILD_SHARED_LIBS)
-    install(CODE "MESSAGE(FATAL_ERROR \"Installing liblammps with downloaded libraries is currently not supported.\")")
-  endif()
 else()
   find_package(Eigen3 NO_MODULE)
   mark_as_advanced(Eigen3_DIR)

cmake/Modules/Packages/VORONOI.cmake

@@ -24,7 +24,11 @@ if(DOWNLOAD_VORO)
   ExternalProject_Add(voro_build
     URL https://download.lammps.org/thirdparty/voro++-0.4.6.tar.gz
     URL_MD5 2338b824c3b7b25590e18e8df5d68af9
-    CONFIGURE_COMMAND "" BUILD_COMMAND make ${VORO_BUILD_OPTIONS} BUILD_IN_SOURCE 1 INSTALL_COMMAND ""
+    PATCH_COMMAND patch -b -p0 < ${LAMMPS_LIB_SOURCE_DIR}/voronoi/voro-make.patch
+    CONFIGURE_COMMAND ""
+    BUILD_COMMAND make ${VORO_BUILD_OPTIONS}
+    BUILD_IN_SOURCE 1
+    INSTALL_COMMAND ""
     BUILD_BYPRODUCTS <SOURCE_DIR>/src/libvoro++.a
     )
   ExternalProject_get_property(voro_build SOURCE_DIR)
@@ -35,9 +39,6 @@ if(DOWNLOAD_VORO)
     INTERFACE_INCLUDE_DIRECTORIES "${SOURCE_DIR}/src")
   target_link_libraries(lammps PRIVATE LAMMPS::VORO)
   add_dependencies(LAMMPS::VORO voro_build)
-  if(NOT BUILD_SHARED_LIBS)
-    install(CODE "MESSAGE(FATAL_ERROR \"Installing liblammps with downloaded libraries is currently not supported.\")")
-  endif()
 else()
   find_package(VORO)
   if(NOT VORO_FOUND)

cmake/Modules/Testing.cmake

@@ -4,48 +4,7 @@
 option(ENABLE_TESTING "Enable testing" OFF)
 if(ENABLE_TESTING)
   enable_testing()
-  option(LAMMPS_TESTING_SOURCE_DIR "Location of lammps-testing source directory" "")
-  option(LAMMPS_TESTING_GIT_TAG    "Git tag of lammps-testing" "master")
-  mark_as_advanced(LAMMPS_TESTING_SOURCE_DIR LAMMPS_TESTING_GIT_TAG)
-
-  if (CMAKE_VERSION VERSION_GREATER "3.10.3" AND NOT LAMMPS_TESTING_SOURCE_DIR)
-    include(FetchContent)
-
-    FetchContent_Declare(lammps-testing
-      GIT_REPOSITORY https://github.com/lammps/lammps-testing.git
-      GIT_TAG ${LAMMPS_TESTING_GIT_TAG}
-    )
-
-    FetchContent_GetProperties(lammps-testing)
-    if(NOT lammps-testing_POPULATED)
-      message(STATUS "Downloading tests...")
-      FetchContent_Populate(lammps-testing)
-    endif()
-
-    set(LAMMPS_TESTING_SOURCE_DIR ${lammps-testing_SOURCE_DIR})
-  elseif(NOT LAMMPS_TESTING_SOURCE_DIR)
-    message(WARNING "Full test-suite requires CMake >= 3.11 or copy of\n"
-                    "https://github.com/lammps/lammps-testing in LAMMPS_TESTING_SOURCE_DIR")
-  endif()
-
-  add_test(NAME ShowHelp COMMAND $<TARGET_FILE:lmp> -help)
-
-  if(EXISTS ${LAMMPS_TESTING_SOURCE_DIR})
-    message(STATUS "Running test discovery...")
-
-    file(GLOB_RECURSE TEST_SCRIPTS ${LAMMPS_TESTING_SOURCE_DIR}/tests/core/*/in.*)
-    foreach(script_path ${TEST_SCRIPTS})
-      get_filename_component(TEST_NAME ${script_path} EXT)
-      get_filename_component(SCRIPT_NAME ${script_path} NAME)
-      get_filename_component(PARENT_DIR ${script_path} DIRECTORY)
-      string(SUBSTRING ${TEST_NAME} 1 -1 TEST_NAME)
-      string(REPLACE "-" "_" TEST_NAME ${TEST_NAME})
-      string(REPLACE "+" "_" TEST_NAME ${TEST_NAME})
-      set(TEST_NAME "test_core_${TEST_NAME}_serial")
-      add_test(NAME ${TEST_NAME} COMMAND $<TARGET_FILE:lmp> -in ${SCRIPT_NAME} WORKING_DIRECTORY ${PARENT_DIR})
-    endforeach()
-    list(LENGTH TEST_SCRIPTS NUM_TESTS)
-
-    message(STATUS "Found ${NUM_TESTS} tests.")
-  endif()
+  get_filename_component(LAMMPS_UNITTEST_DIR ${LAMMPS_SOURCE_DIR}/../unittest ABSOLUTE)
+  get_filename_component(LAMMPS_UNITTEST_BIN ${CMAKE_BINARY_DIR}/unittest ABSOLUTE)
+  add_subdirectory(${LAMMPS_UNITTEST_DIR} ${LAMMPS_UNITTEST_BIN})
 endif()

cmake/Modules/generate_lmpgitversion.cmake

@@ -3,17 +3,19 @@ set(temp_git_commit "(unknown)")
 set(temp_git_branch "(unknown)")
 set(temp_git_describe "(unknown)")
 set(temp_git_info "false")
-if(GIT_FOUND AND EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/../.git)
+
+message(STATUS "Git Directory: ${LAMMPS_DIR}/.git")
+if(GIT_FOUND AND EXISTS ${LAMMPS_DIR}/.git)
   set(temp_git_info "true")
-  execute_process(COMMAND ${GIT_EXECUTABLE} -C ${CMAKE_CURRENT_SOURCE_DIR}/.. rev-parse HEAD
+  execute_process(COMMAND ${GIT_EXECUTABLE} -C ${LAMMPS_DIR} rev-parse HEAD
     OUTPUT_VARIABLE temp_git_commit
     ERROR_QUIET
     OUTPUT_STRIP_TRAILING_WHITESPACE)
-  execute_process(COMMAND ${GIT_EXECUTABLE} -C ${CMAKE_CURRENT_SOURCE_DIR}/.. rev-parse --abbrev-ref HEAD
+  execute_process(COMMAND ${GIT_EXECUTABLE} -C ${LAMMPS_DIR} rev-parse --abbrev-ref HEAD
     OUTPUT_VARIABLE temp_git_branch
     ERROR_QUIET
     OUTPUT_STRIP_TRAILING_WHITESPACE)
-  execute_process(COMMAND ${GIT_EXECUTABLE} -C ${CMAKE_CURRENT_SOURCE_DIR}/.. describe --dirty=-modified
+  execute_process(COMMAND ${GIT_EXECUTABLE} -C ${LAMMPS_DIR} describe --dirty=-modified
     OUTPUT_VARIABLE temp_git_describe
     ERROR_QUIET
     OUTPUT_STRIP_TRAILING_WHITESPACE)

cmake/presets/clang.cmake

@@ -2,7 +2,7 @@
 
 set(CMAKE_CXX_COMPILER "clang++" CACHE STRING "" FORCE)
 set(CMAKE_C_COMPILER "clang" CACHE STRING "" FORCE)
-set(CMAKE_CXX_FLAGS "-Wall -Wextra -g -O2 -DNDEBG" CACHE STRING "" FORCE)
+set(CMAKE_CXX_FLAGS "-Wall -Wextra -g -O2 -DNDEBUG" CACHE STRING "" FORCE)
 set(MPI_CXX "clang++" CACHE STRING "" FORCE)
 set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
 unset(HAVE_OMP_H_INCLUDE CACHE)

cmake/presets/hip.cmake

@@ -0,0 +1,12 @@
+# preset that will enable hipcc plus gcc with support for MPI and OpenMP (on Linux boxes)
+
+set(CMAKE_CXX_COMPILER "hipcc" CACHE STRING "" FORCE)
+set(CMAKE_C_COMPILER "gcc" CACHE STRING "" FORCE)
+set(CMAKE_CXX_FLAGS "-Wall -Wextra -g -O2 -DNDEBUG" CACHE STRING "" FORCE)
+unset(HAVE_OMP_H_INCLUDE CACHE)
+
+set(OpenMP_CXX "hipcc" CACHE STRING "" FORCE)
+set(OpenMP_CXX_FLAGS "-fopenmp" CACHE STRING "" FORCE)
+set(OpenMP_CXX_LIB_NAMES "omp" CACHE STRING "" FORCE)
+set(OpenMP_omp_LIBRARY "libomp.so" CACHE PATH "" FORCE)
+

cmake/presets/most.cmake

@@ -5,10 +5,10 @@
 set(ALL_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL
         DIPOLE GRANULAR KSPACE MANYBODY MC MISC MOLECULE OPT PERI
         POEMS PYTHON QEQ REPLICA RIGID SHOCK SNAP SPIN SRD VORONOI
-        USER-CGDNA USER-CGSDK USER-COLVARS USER-DIFFRACTION
-        USER-DPD USER-DRUDE USER-FEP USER-MEAMC USER-MESODPD
+        USER-BOCS USER-CGDNA USER-CGSDK USER-COLVARS USER-DIFFRACTION
+        USER-DPD USER-DRUDE USER-EFF USER-FEP USER-MEAMC USER-MESODPD
         USER-MISC USER-MOFFF USER-OMP USER-PHONON USER-REACTION
-        USER-REAXC USER-SPH USER-SMD USER-UEF USER-YAFF)
+        USER-REAXC USER-SDPD USER-SPH USER-SMD USER-UEF USER-YAFF)
 
 foreach(PKG ${ALL_PACKAGES})
   set(PKG_${PKG} ON CACHE BOOL "" FORCE)

doc/include-file-conventions.md

@@ -49,22 +49,15 @@ include files provided with LAMMPS are included with double quotes
 
 For headers declaring functions of the C-library, the corresponding
 C++ versions should be included (examples: `#include <cstdlib>` or
-`#include <cctypes>`).  However, these includes are limited to those defined
-in the C++98 standard.  Some files thus must use the older style until
-the minimum C++ standard requirement of LAMMPS is lifted to C++11 or
-even beyond (examples: `#include <stdint.h>` versus `#include <cstdint>`
-or `#include <inttypes.h>` versus `#include <cinttypes>`).
+`#include <cctypes>` instead of `#include <stdlib.h>` or
+`#include<ctypes.h>` ).
 
 ### C++ Standard Compliance
 
-LAMMPS core files currently correspond to the C++98 standard. Files
-requiring C++11 or later are only permitted in (optional) packages
-and particularly packages that are not part of the list of commonly
-used packages such as MOLECULE, KSPACE, MANYBODY, or RIGID.
-
-Also, LAMMPS uses the C-style stdio library for I/O instead of iostreams.
-Since using both at the same time can cause problems, iostreams should
-be avoided where possible.
+LAMMPS core files use standard conforming C++ compatible with the
+C++11 standard, unless explicitly noted.  Also, LAMMPS uses the C-style
+stdio library for I/O instead of iostreams.  Since using both at the
+same time can cause problems, iostreams should be avoided where possible.
 
 ### Lean Header Files
 

doc/lammps.1

@@ -1,4 +1,4 @@
-.TH LAMMPS "15 April 2020" "2020-04-15"
+.TH LAMMPS "2 June 2020" "2020-06-02"
 .SH NAME
 .B LAMMPS
 \- Molecular Dynamics Simulator.

doc/src/Build_cmake.rst

@@ -107,7 +107,7 @@ re-compile and relink the LAMMPS executable with ``cmake --build .`` (or
 ``cmake .`` and then compile again. The included dependency tracking
 should make certain that only the necessary subset of files are
 re-compiled.  You can also delete compiled objects, libraries and
-executables with ``cmake --build . clean`` (or ``make clean``).
+executables with ``cmake --build . --target clean`` (or ``make clean``).
 
 After compilation, you may optionally install the LAMMPS executable into
 your system with:

doc/src/Build_development.rst

@@ -57,53 +57,252 @@ variable during configuration. Examples:
 
 .. _testing:
 
-Code Coverage and Testing
----------------------------------------
+Code Coverage and Unit Testing
+------------------------------
 
-We do extensive regression testing of the LAMMPS code base on a continuous
-basis. Some of the logic to do this has been added to the CMake build so
-developers can run the tests directly on their workstation.
+The LAMMPS code is subject to multiple levels of automated testing
+during development: integration testing (i.e. whether the code compiles
+on various platforms and with a variety of settings), unit testing
+(i.e. whether certain individual parts of the code produce the expected
+results for given inputs), run testing (whether selected complete input
+decks run without crashing for multiple configurations), and regression
+testing (i.e. whether selected input examples reproduce the same
+results over a given number of steps and operations within a given
+error margin).  The status of this automated testing can be viewed on
+`https://ci.lammps.org <https://ci.lammps.org>`_.
+
+The unit testing facility is integrated into the CMake build process
+of the LAMMPS source code distribution itself.  It can be enabled by
+setting ``-D ENABLE_TESTING=on`` during the CMake configuration step.
+It requires the `YAML <http://pyyaml.org/>`_ library and development
+headers to compile and will download and compile a recent version of the
+`Googletest <https://github.com/google/googletest/>`_ C++ test framework
+for implementing the tests.
+
+After compilation is complete, the unit testing is started in the build
+folder using the ``ctest`` command, which is part of the CMake software.
+The output of this command will be looking something like this::
+
+   [...]$ ctest
+   Test project /home/akohlmey/compile/lammps/build-testing
+         Start  1: MolPairStyle:hybrid-overlay
+    1/26 Test  #1: MolPairStyle:hybrid-overlay .........   Passed    0.02 sec
+         Start  2: MolPairStyle:hybrid
+    2/26 Test  #2: MolPairStyle:hybrid .................   Passed    0.01 sec
+         Start  3: MolPairStyle:lj_class2
+    [...]
+         Start 25: AngleStyle:harmonic
+   25/26 Test #25: AngleStyle:harmonic .................   Passed    0.01 sec
+         Start 26: AngleStyle:zero
+   26/26 Test #26: AngleStyle:zero .....................   Passed    0.01 sec
+   
+   100% tests passed, 0 tests failed out of 26
+   
+   Total Test time (real) =   0.27 sec
+
+
+The ``ctest`` command has many options, the most important ones are:
+
+.. list-table::
+
+   * - Option
+     - Function
+   * - -V
+     - verbose output: display output of individual test runs
+   * - -j <num>
+     - parallel run: run <num> tests in parallel
+   * - -R <regex>
+     - run subset of tests matching the regular expression <regex>
+   * - -E <regex>
+     - exclude subset of tests matching the regular expression <regex>
+   * - -N
+     - dry-run: display list of tests without running them
+
+In its full implementation, the unit test framework will consist of multiple
+kinds of tests implemented in different programming languages (C++, C, Python,
+Fortran) and testing different aspects of the LAMMPS software and its features.
+At the moment only tests for "force styles" are implemented. More on those
+in the next section.
 
 .. note::
 
-   this is incomplete and only represents a small subset of tests that we run
+   This unit test framework is new and still under development.
+   The coverage is only minimal and will be expanded over time.
+   Tests styles of the same kind of style (e.g. pair styles or
+   bond styles) are performed with the same executable using
+   different input files in YAML format.  So to add a test for
+   another pair style can be done by copying the YAML file and
+   editing the style settings and then running the individual test
+   program with a flag to update the computed reference data.
+   Detailed documentation about how to add new test program and
+   the contents of the YAML files for existing test programs
+   will be provided in time as well.
+
+Unit tests for force styles
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+A large part of LAMMPS are different "styles" for computing non-bonded
+and bonded interactions selected through the :doc:`pair_style`,
+:doc:`bond_style`, :doc:`angle_style`, :doc:`dihedral_style`,
+:doc:`improper_style`, and :doc:`kspace_style`.  Since these all share
+common interfaces, it is possible to write generic test programs that
+will call those common interfaces for small test systems with less than
+100 atoms and compare the results with pre-recorded reference results.
+A test run is then a a collection multiple individual test runs each
+with many comparisons to reference results based on template input
+files, individual command settings, relative error margins, and
+reference data stored in a YAML format file with ``.yaml``
+suffix. Currently the programs ``pair_style``, ``bond_style``, and
+``angle_style`` are implemented.  They will compare forces, energies and
+(global) stress for all atoms after a ``run 0`` calculation and after a
+few steps of MD with :doc:`fix nve <fix_nve>`, each in multiple variants
+with different settings and also for multiple accelerated styles. If a
+prerequisite style or package is missing, the individual tests are
+skipped.  All tests will be executed on a single MPI process, so using
+the CMake option ``-D BUILD_MPI=off`` can significantly speed up testing,
+since this will skip the MPI initialization for each test run.
+Below is an example command and output:
+
+.. parsed-literal::
+
+   [tests]$ pair_style mol-pair-lj_cut.yaml
+   [==========] Running 6 tests from 1 test suite.
+   [----------] Global test environment set-up.
+   [----------] 6 tests from PairStyle
+   [ RUN      ] PairStyle.plain
+   [       OK ] PairStyle.plain (24 ms)
+   [ RUN      ] PairStyle.omp
+   [       OK ] PairStyle.omp (18 ms)
+   [ RUN      ] PairStyle.intel
+   [       OK ] PairStyle.intel (6 ms)
+   [ RUN      ] PairStyle.opt
+   [  SKIPPED ] PairStyle.opt (0 ms)
+   [ RUN      ] PairStyle.single
+   [       OK ] PairStyle.single (7 ms)
+   [ RUN      ] PairStyle.extract
+   [       OK ] PairStyle.extract (6 ms)
+   [----------] 6 tests from PairStyle (62 ms total)
+
+   [----------] Global test environment tear-down
+   [==========] 6 tests from 1 test suite ran. (63 ms total)
+   [  PASSED  ] 5 tests.
+   [  SKIPPED ] 1 test, listed below:
+   [  SKIPPED ] PairStyle.opt
+
+In this particular case, 5 out of 6 sets of tests were conducted, the
+tests for the ``lj/cut/opt`` pair style was skipped, since the tests
+executable did not include it.  To learn what individual tests are performed,
+you (currently) need to read the source code.  You can use code coverage
+recording (see next section) to confirm how well the tests cover the individual
+source files.
+
+The force style test programs have a common set of options:
+
+.. list-table::
+
+   * - Option
+     - Function
+   * - -g <newfile>
+     - regenerate reference data in new YAML file
+   * - -u
+     - update reference data in the original YAML file
+   * - -s
+     - print error statistics for each group of comparisons
+   * - -v
+     - verbose output: also print the executed LAMMPS commands
+
+To add a test for a style that is not yet covered, it is usually best
+to copy a YAML file for a similar style to a new file, edit the details
+of the style (how to call it, how to set its coefficients) and then
+run test command with either the *-g* and the replace the initial
+test file with the regenerated one or the *-u* option.  The *-u* option
+will destroy the original file, if the generation run does not complete,
+so using *-g* is recommended unless the YAML file is fully tested
+and working.
+
+.. admonition:: Recommendations and notes for YAML files
+   :class: note
+
+   - The reference results should be recorded without any code
+     optimization or related compiler flags enabled.
+   - The ``epsilon`` parameter defines the relative precision with which
+     the reference results must be met.  The test geometries often have
+     high and low energy parts and thus a significant impact from
+     floating-point math truncation errors is to be expected. Some
+     functional forms and potentials are more noisy than others, so this
+     parameter needs to be adjusted. Typically a value around 1.0e-13
+     can be used, but it may need to be as large as 1.0e-8 in some
+     cases.
+   - The tests for pair styles from OPT, USER-OMP and USER-INTEL are
+     performed with automatically rescaled epsilon to account for
+     additional loss of precision from code optimizations and different
+     summation orders.
+   - When compiling with aggressive compiler optimization, some tests
+     are likely to fail.  It is recommended to inspect the individual
+     tests in detail to decide whether the specific error for a specific
+     property is acceptable (it often is), or this may be an indication
+     of mis-compiled code (or undesired large of precision due to
+     reordering of operations).
+
+Collect and visualize code coverage metrics
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+You can also collect code coverage metrics while running LAMMPS or the
+tests by enabling code coverage support during the CMake configuration:
 
 .. code-block:: bash
 
-   -D ENABLE_TESTING=value               # enable simple run tests of LAMMPS, value = no (default) or yes
-   -D LAMMPS_TESTING_SOURCE_DIR=path     # path to lammps-testing repository (option if in custom location)
-   -D LAMMPS_TESTING_GIT_TAG=value       # version of lammps-testing repository that should be used, value = master (default) or custom git commit or tag
+   -D ENABLE_COVERAGE=on  # enable coverage measurements (off by default)
 
-If you enable testing in the CMake build it will create an additional
-target called "test". You can run them with:
+This will instrument all object files to write information about which
+lines of code were accessed during execution in files next to the
+corresponding object files.  These can be post-processed to visually
+show the degree of coverage and which code paths are accessed and which
+are not taken.  When working on unit tests (see above), this can be
+extremely helpful to determine which parts of the code are not executed
+and thus what kind of tests are still missing. The coverage data is
+cumulative, i.e. new data is added with each new run.
+
+Enabling code coverage will also add the following build targets to
+generate coverage reports after running the LAMMPS executable or the
+unit tests:
 
 .. code-block:: bash
 
-   cmake --build . test
+   make gen_coverage_html   # generate coverage report in HTML format
+   make gen_coverage_xml    # generate coverage report in XML format
+   make clean_coverage_html # delete folder with HTML format coverage report
+   make reset_coverage      # delete all collected coverage data and HTML output
 
-The test cases used come from the lammps-testing repository. They are
-derivatives of the examples folder with some modifications to make the
-run faster.
-
-You can also collect code coverage metrics while running the tests by
-enabling coverage support during building.
-
-.. code-block:: bash
-
-   -D ENABLE_COVERAGE=value  # enable coverage measurements, value = no (default) or yes
-
-This will also add the following targets to generate coverage reports
-after running the LAMMPS executable:
-
-.. code-block:: bash
-
-   make test               # run tests first!
-   make gen_coverage_html  # generate coverage report in HTML format
-   make gen_coverage_xml   # generate coverage report in XML format
-
-These reports require GCOVR to be installed. The easiest way to do this
-to install it via pip:
+These reports require `GCOVR <https://gcovr.com/>`_ to be installed. The easiest way
+to do this to install it via pip:
 
 .. code-block:: bash
 
    pip install git+https://github.com/gcovr/gcovr.git
+
+After post-processing with ``gen_coverage_html`` the results are in
+a folder ``coverage_html`` and can be viewed with a web browser.
+The images below illustrate how the data is presented.
+
+.. list-table::
+
+      * - .. figure:: JPG/coverage-overview-top.png
+             :target: JPG/coverage-overview-top.png
+
+          Top of the overview page
+
+        - .. figure:: JPG/coverage-overview-manybody.png
+             :target: JPG/coverage-overview-manybody.png
+
+          Styles with good coverage
+
+        - .. figure:: JPG/coverage-file-top.png
+             :target: JPG/coverage-file-top.png
+
+          Top of individual source page
+
+        - .. figure:: JPG/coverage-file-branches.png
+             :target: JPG/coverage-file-branches.png
+
+          Source page with branches

doc/src/Build_extras.rst

@@ -320,11 +320,13 @@ to have an executable that will run on this and newer architectures.
 
 .. note::
 
-   NVIDIA GPUs with CC 5.0 (Maxwell) and newer are not compatible with
-   CC 3.x (Kepler).  If you run Kokkos on a newer architecture than what
-   LAMMPS was compiled with, there will be a significant delay during
-   device initialization since the just-in-time compiler has to
-   recompile the GPU kernel code for the new hardware.
+   If you run Kokkos on a different GPU architecture than what LAMMPS
+   was compiled with, there will be a delay during device initialization
+   while the just-in-time compiler is recompiling all GPU kernels for
+   the new hardware.  This is, however, only supported for GPUs of the
+   **same** major hardware version and different minor hardware versions,
+   e.g. 5.0 and 5.2 but not 5.2 and 6.0.  LAMMPS will abort with an
+   error message indicating a mismatch, if that happens.
 
 The settings discussed below have been tested with LAMMPS and are
 confirmed to work.  Kokkos is an active project with ongoing improvements
@@ -343,73 +345,109 @@ be specified in uppercase.
    :widths: auto
 
    *  - **Arch-ID**
+      - **HOST or GPU**
       - **Description**
    *  - AMDAVX
+      - HOST
       - AMD 64-bit x86 CPU (AVX 1)
    *  - EPYC
+      - HOST
       - AMD EPYC Zen class CPU (AVX 2)
    *  - ARMV80
+      - HOST
       - ARMv8.0 Compatible CPU
    *  - ARMV81
+      - HOST
       - ARMv8.1 Compatible CPU
    *  - ARMV8_THUNDERX
+      - HOST
       - ARMv8 Cavium ThunderX CPU
    *  - ARMV8_THUNDERX2
+      - HOST
       - ARMv8 Cavium ThunderX2 CPU
    *  - WSM
+      - HOST
       - Intel Westmere CPU (SSE 4.2)
    *  - SNB
+      - HOST
       - Intel Sandy/Ivy Bridge CPU (AVX 1)
    *  - HSW
+      - HOST
       - Intel Haswell CPU (AVX 2)
    *  - BDW
+      - HOST
       - Intel Broadwell Xeon E-class CPU (AVX 2 + transactional mem)
    *  - SKX
+      - HOST
       - Intel Sky Lake Xeon E-class HPC CPU (AVX512 + transactional mem)
    *  - KNC
+      - HOST
       - Intel Knights Corner Xeon Phi
    *  - KNL
+      - HOST
       - Intel Knights Landing Xeon Phi
    *  - BGQ
+      - HOST
       - IBM Blue Gene/Q CPU
    *  - POWER7
-      - IBM POWER8 CPU
+      - HOST
+      - IBM POWER7 CPU
    *  - POWER8
+      - HOST
       - IBM POWER8 CPU
    *  - POWER9
+      - HOST
       - IBM POWER9 CPU
    *  - KEPLER30
+      - GPU
       - NVIDIA Kepler generation CC 3.0 GPU
    *  - KEPLER32
+      - GPU
       - NVIDIA Kepler generation CC 3.2 GPU
    *  - KEPLER35
+      - GPU
       - NVIDIA Kepler generation CC 3.5 GPU
    *  - KEPLER37
+      - GPU
       - NVIDIA Kepler generation CC 3.7 GPU
    *  - MAXWELL50
+      - GPU
       - NVIDIA Maxwell generation CC 5.0 GPU
    *  - MAXWELL52
+      - GPU
       - NVIDIA Maxwell generation CC 5.2 GPU
    *  - MAXWELL53
+      - GPU
       - NVIDIA Maxwell generation CC 5.3 GPU
    *  - PASCAL60
+      - GPU
       - NVIDIA Pascal generation CC 6.0 GPU
    *  - PASCAL61
+      - GPU
       - NVIDIA Pascal generation CC 6.1 GPU
    *  - VOLTA70
+      - GPU
       - NVIDIA Volta generation CC 7.0 GPU
    *  - VOLTA72
+      - GPU
       - NVIDIA Volta generation CC 7.2 GPU
    *  - TURING75
+      - GPU
       - NVIDIA Turing generation CC 7.5 GPU
+   *  - VEGA900
+      - GPU
+      - AMD GPU MI25 GFX900
+   *  - VEGA906
+      - GPU
+      - AMD GPU MI50/MI60 GFX906
 
-CMake build settings:
-^^^^^^^^^^^^^^^^^^^^^
+Basic CMake build settings:
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
 For multicore CPUs using OpenMP, set these 2 variables.
 
 .. code-block:: bash
 
-   -D Kokkos_ARCH_CPUARCH=yes  # CPUARCH = CPU from list above
+   -D Kokkos_ARCH_HOSTARCH=yes  # HOSTARCH = HOST from list above
    -D Kokkos_ENABLE_OPENMP=yes
    -D BUILD_OMP=yes
 
@@ -427,15 +465,19 @@ For NVIDIA GPUs using CUDA, set these variables:
 
 .. code-block:: bash
 
-   -D Kokkos_ARCH_CPUARCH=yes    # CPUARCH = CPU from list above
+   -D Kokkos_ARCH_HOSTARCH=yes   # HOSTARCH = HOST from list above
    -D Kokkos_ARCH_GPUARCH=yes    # GPUARCH = GPU from list above
    -D Kokkos_ENABLE_CUDA=yes
    -D Kokkos_ENABLE_OPENMP=yes
    -D CMAKE_CXX_COMPILER=wrapper # wrapper = full path to Cuda nvcc wrapper
 
-The wrapper value is the Cuda nvcc compiler wrapper provided in the
-Kokkos library: ``lib/kokkos/bin/nvcc_wrapper``\ .  The setting should
-include the full path name to the wrapper, e.g.
+This will also enable executing FFTs on the GPU, either via the internal
+KISSFFT library, or - by preference - with the cuFFT library bundled
+with the CUDA toolkit, depending on whether CMake can identify its
+location.  The *wrapper* value for ``CMAKE_CXX_COMPILER`` variable is
+the path to the CUDA nvcc compiler wrapper provided in the Kokkos
+library: ``lib/kokkos/bin/nvcc_wrapper``\ .  The setting should include
+the full path name to the wrapper, e.g.
 
 .. code-block:: bash
 
@@ -455,8 +497,8 @@ common packages enabled, you can do the following:
    cmake -C ../cmake/presets/minimal.cmake -C ../cmake/presets/kokkos-cuda.cmake ../cmake
    cmake --build .
 
-Traditional make settings:
-^^^^^^^^^^^^^^^^^^^^^^^^^^
+Basic traditional make settings:
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Choose which hardware to support in ``Makefile.machine`` via
 ``KOKKOS_DEVICES`` and ``KOKKOS_ARCH`` settings.  See the
@@ -467,7 +509,7 @@ For multicore CPUs using OpenMP:
 .. code-block:: make
 
    KOKKOS_DEVICES = OpenMP
-   KOKKOS_ARCH = CPUARCH          # CPUARCH = CPU from list above
+   KOKKOS_ARCH = HOSTARCH          # HOSTARCH = HOST from list above
 
 For Intel KNLs using OpenMP:
 
@@ -481,7 +523,8 @@ For NVIDIA GPUs using CUDA:
 .. code-block:: make
 
    KOKKOS_DEVICES = Cuda
-   KOKKOS_ARCH = CPUARCH,GPUARCH  # CPUARCH = CPU from list above that is hosting the GPU
+   KOKKOS_ARCH = HOSTARCH,GPUARCH  # HOSTARCH = HOST from list above that is hosting the GPU
+   KOKKOS_CUDA_OPTIONS = "enable_lambda"
                                   # GPUARCH = GPU from list above
    FFT_INC = -DFFT_CUFFT          # enable use of cuFFT (optional)
    FFT_LIB = -lcufft              # link to cuFFT library
@@ -504,6 +547,49 @@ C++ compiler for non-Kokkos, non-CUDA files.
    KOKKOS_ABSOLUTE_PATH = $(shell cd $(KOKKOS_PATH); pwd)
    CC = mpicxx -cxx=$(KOKKOS_ABSOLUTE_PATH)/config/nvcc_wrapper
 
+
+Advanced KOKKOS compilation settings
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+There are other allowed options when building with the KOKKOS package
+that can improve performance or assist in debugging or profiling. Below
+are some examples that may be useful in combination with LAMMPS.  For
+the full list (which keeps changing as the Kokkos package itself evolves),
+please consult the Kokkos library documentation.
+
+As alternative to using multi-threading via OpenMP
+(``-DKokkos_ENABLE_OPENMP=on`` or ``KOKKOS_DEVICES=OpenMP``) it is also
+possible to use Posix threads directly (``-DKokkos_ENABLE_PTHREAD=on``
+or ``KOKKOS_DEVICES=Pthread``).  While binding of threads to individual
+or groups of CPU cores is managed in OpenMP with environment variables,
+you need assistance from either the "hwloc" or "libnuma" library for the
+Pthread thread parallelization option. To enable use with CMake:
+``-DKokkos_ENABLE_HWLOC=on`` or ``-DKokkos_ENABLE_LIBNUMA=on``; and with
+conventional make: ``KOKKOS_USE_TPLS=hwloc`` or
+``KOKKOS_USE_TPLS=libnuma``.
+
+The CMake option ``-DKokkos_ENABLE_LIBRT=on`` or the makefile setting
+``KOKKOS_USE_TPLS=librt`` enables the use of a more accurate timer
+mechanism on many Unix-like platforms for internal profiling.
+
+The CMake option ``-DKokkos_ENABLE_DEBUG=on`` or the makefile setting
+``KOKKOS_DEBUG=yes`` enables printing of run-time
+debugging information that can be useful. It also enables runtime
+bounds checking on Kokkos data structures.  As to be expected, enabling
+this option will negatively impact the performance and thus is only
+recommended when developing a Kokkos-enabled style in LAMMPS.
+
+The CMake option ``-DKokkos_ENABLE_CUDA_UVM=on`` or the makefile
+setting ``KOKKOS_CUDA_OPTIONS=enable_lambda,force_uvm`` enables the
+use of CUDA "Unified Virtual Memory" (UVM) in Kokkos.  UVM allows to
+transparently use RAM on the host to supplement the memory used on the
+GPU (with some performance penalty) and thus enables running larger
+problems that would otherwise not fit into the RAM on the GPU.
+
+Please note, that the LAMMPS KOKKOS package must **always** be compiled
+with the *enable_lambda* option when using GPUs.  The CMake configuration
+will thus always enable it.
+
 ----------
 
 .. _latte:

doc/src/Commands_compute.rst

@@ -42,7 +42,7 @@ KOKKOS, o = USER-OMP, t = OPT.
    * :doc:`com <compute_com>`
    * :doc:`com/chunk <compute_com_chunk>`
    * :doc:`contact/atom <compute_contact_atom>`
-   * :doc:`coord/atom <compute_coord_atom>`
+   * :doc:`coord/atom (k) <compute_coord_atom>`
    * :doc:`damage/atom <compute_damage_atom>`
    * :doc:`dihedral <compute_dihedral>`
    * :doc:`dihedral/local <compute_dihedral_local>`
@@ -79,15 +79,12 @@ KOKKOS, o = USER-OMP, t = OPT.
    * :doc:`ke/atom/eff <compute_ke_atom_eff>`
    * :doc:`ke/eff <compute_ke_eff>`
    * :doc:`ke/rigid <compute_ke_rigid>`
-   * :doc:`meso/e/atom <compute_meso_e_atom>`
-   * :doc:`meso/rho/atom <compute_meso_rho_atom>`
-   * :doc:`meso/t/atom <compute_meso_t_atom>`
    * :doc:`momentum <compute_momentum>`
    * :doc:`msd <compute_msd>`
    * :doc:`msd/chunk <compute_msd_chunk>`
    * :doc:`msd/nongauss <compute_msd_nongauss>`
    * :doc:`omega/chunk <compute_omega_chunk>`
-   * :doc:`orientorder/atom <compute_orientorder_atom>`
+   * :doc:`orientorder/atom (k) <compute_orientorder_atom>`
    * :doc:`pair <compute_pair>`
    * :doc:`pair/local <compute_pair_local>`
    * :doc:`pe <compute_pe>`
@@ -133,6 +130,9 @@ KOKKOS, o = USER-OMP, t = OPT.
    * :doc:`sna/atom <compute_sna_atom>`
    * :doc:`snad/atom <compute_sna_atom>`
    * :doc:`snav/atom <compute_sna_atom>`
+   * :doc:`sph/e/atom <compute_sph_e_atom>`
+   * :doc:`sph/rho/atom <compute_sph_rho_atom>`
+   * :doc:`sph/t/atom <compute_sph_t_atom>`
    * :doc:`spin <compute_spin>`
    * :doc:`stress/atom <compute_stress_atom>`
    * :doc:`stress/mop <compute_stress_mop>`
@@ -161,5 +161,6 @@ KOKKOS, o = USER-OMP, t = OPT.
    * :doc:`torque/chunk <compute_torque_chunk>`
    * :doc:`vacf <compute_vacf>`
    * :doc:`vcm/chunk <compute_vcm_chunk>`
+   * :doc:`viscosity/cos <compute_viscosity_cos>`
    * :doc:`voronoi/atom <compute_voronoi_atom>`
    * :doc:`xrd <compute_xrd>`

doc/src/Commands_fix.rst

@@ -22,6 +22,7 @@ OPT.
 .. table_from_list::
    :columns: 5
 
+   * :doc:`accelerate/cos <fix_accelerate_cos>`
    * :doc:`adapt <fix_adapt>`
    * :doc:`adapt/fep <fix_adapt_fep>`
    * :doc:`addforce <fix_addforce>`
@@ -94,9 +95,7 @@ OPT.
    * :doc:`lb/viscous <fix_lb_viscous>`
    * :doc:`lineforce <fix_lineforce>`
    * :doc:`manifoldforce <fix_manifoldforce>`
-   * :doc:`meso <fix_meso>`
    * :doc:`meso/move <fix_meso_move>`
-   * :doc:`meso/stationary <fix_meso_stationary>`
    * :doc:`momentum (k) <fix_momentum>`
    * :doc:`move <fix_move>`
    * :doc:`mscg <fix_mscg>`
@@ -201,6 +200,8 @@ OPT.
    * :doc:`smd/move_tri_surf <fix_smd_move_triangulated_surface>`
    * :doc:`smd/setvel <fix_smd_setvel>`
    * :doc:`smd/wall_surface <fix_smd_wall_surface>`
+   * :doc:`sph <fix_sph>`
+   * :doc:`sph/stationary <fix_sph_stationary>`
    * :doc:`spring <fix_spring>`
    * :doc:`spring/chunk <fix_spring_chunk>`
    * :doc:`spring/rg <fix_spring_rg>`

doc/src/Commands_pair.rst

@@ -92,8 +92,8 @@ OPT.
    * :doc:`drip <pair_drip>`
    * :doc:`eam (gikot) <pair_eam>`
    * :doc:`eam/alloy (gikot) <pair_eam>`
-   * :doc:`eam/cd (o) <pair_eam>`
-   * :doc:`eam/cd/old (o) <pair_eam>`
+   * :doc:`eam/cd <pair_eam>`
+   * :doc:`eam/cd/old <pair_eam>`
    * :doc:`eam/fs (gikot) <pair_eam>`
    * :doc:`edip (o) <pair_edip>`
    * :doc:`edip/multi <pair_edip>`

doc/src/Howto_cmake.rst

@@ -378,9 +378,9 @@ change some variables later with additional *-D* flags.  A few examples:
 
 .. code-block:: bash
 
-   cmake -C ../cmake/preset/minimal.cmake -D PKG_MISC=on ../cmake
-   cmake -C ../cmake/preset/clang.cmake -C ../cmake/preset/most.cmake ../cmake
-   cmake -C ../cmake/preset/minimal.cmake -D BUILD_MPI=off ../cmake
+   cmake -C ../cmake/presets/minimal.cmake -D PKG_MISC=on ../cmake
+   cmake -C ../cmake/presets/clang.cmake -C ../cmake/presets/most.cmake ../cmake
+   cmake -C ../cmake/presets/minimal.cmake -D BUILD_MPI=off ../cmake
 
 The first command will install the packages ``KSPACE``, ``MANYBODY``,
 ``MOLECULE``, ``RIGID`` and ``MISC``; the first four from the preset
@@ -396,7 +396,7 @@ It is also possible to do this incrementally.
 
 .. code-block:: bash
 
-   cmake -C ../cmake/preset/minimal.cmake ../cmake
+   cmake -C ../cmake/presets/minimal.cmake ../cmake
    cmake -D PKG_MISC=on .
 
 will achieve the same configuration like in the first example above.  In
@@ -415,8 +415,10 @@ This is particularly convenient, if you have set a custom build command
 via the ``CMAKE_MAKE_PROGRAM`` variable.
 
 When calling the build program, you can also select which "target" is to
-be build through appending the name of the target to the build command.
-Example: ``cmake --build . all``. The following abstract targets are available:
+be build through appending the ``--target`` flag and the name of the target
+to the build command.  When using ``make`` as build tool, you can just append
+the target name to the command. Example: ``cmake --build . --target all`` or
+``make all``.  The following abstract targets are available:
 
 .. list-table::
    :header-rows: 1
@@ -432,7 +434,7 @@ Example: ``cmake --build . all``. The following abstract targets are available:
    * - ``install``
      - install all target files into folders in ``CMAKE_INSTALL_PREFIX``
    * - ``test``
-     - run some simple tests (if configured with ``-D ENABLE_TESTING=on``)
+     - run some tests (if configured with ``-D ENABLE_TESTING=on``)
    * - ``clean``
      - remove all generated files
 

doc/src/Howto_viscosity.rst

@@ -1,10 +1,11 @@
 Calculate viscosity
 ===================
 
-The shear viscosity eta of a fluid can be measured in at least 5 ways
+The shear viscosity eta of a fluid can be measured in at least 6 ways
 using various options in LAMMPS.  See the examples/VISCOSITY directory
 for scripts that implement the 5 methods discussed here for a simple
-Lennard-Jones fluid model.  Also, see the :doc:`Howto kappa <Howto_kappa>` doc page for an analogous discussion for
+Lennard-Jones fluid model and 1 method for SPC/E water model.
+Also, see the :doc:`Howto kappa <Howto_kappa>` doc page for an analogous discussion for
 thermal conductivity.
 
 Eta is a measure of the propensity of a fluid to transmit momentum in
@@ -130,9 +131,25 @@ time-integrated momentum fluxes play the role of Cartesian
 coordinates, whose mean-square displacement increases linearly
 with time at sufficiently long times.
 
+The sixth is periodic perturbation method. It is also a non-equilibrium MD method.
+However, instead of measure the momentum flux in response of applied velocity gradient,
+it measures the velocity profile in response of applied stress.
+A cosine-shaped periodic acceleration is added to the system via the
+:doc:`fix accelerate/cos <fix_accelerate_cos>` command,
+and the :doc:`compute viscosity/cos<compute_viscosity_cos>` command is used to monitor the
+generated velocity profile and remove the velocity bias before thermostatting.
+
+.. note::
+
+    An article by :ref:`(Hess) <Hess3>` discussed the accuracy and efficiency of these methods.
+
 ----------
 
 .. _Daivis-viscosity:
 
 **(Daivis and Todd)** Daivis and Todd, Nonequilibrium Molecular Dynamics (book),
 Cambridge University Press, https://doi.org/10.1017/9781139017848, (2017).
+
+.. _Hess3:
+
+**(Hess)** Hess, B. The Journal of Chemical Physics 2002, 116 (1), 209-217.

doc/src/Install_linux.rst

@@ -24,12 +24,13 @@ allows you to install LAMMPS with a single command, and stay
 up-to-date with the current version of LAMMPS by simply updating your
 operating system.
 
-To install the appropriate personal-package archive (PPA), do the
+To install the appropriate personal-package archives (PPAs), do the
 following once:
 
 .. code-block:: bash
 
    $ sudo add-apt-repository ppa:gladky-anton/lammps
+   $ sudo add-apt-repository ppa:openkim/latest
    $ sudo apt-get update
 
 To install LAMMPS do the following once:
@@ -38,7 +39,7 @@ To install LAMMPS do the following once:
 
    $ sudo apt-get install lammps-daily
 
-This downloads an executable named "lmp_daily" to your box, which
+This downloads an executable named ``lmp_daily`` to your box, which
 can then be used in the usual way to run input scripts:
 
 .. code-block:: bash
@@ -60,11 +61,29 @@ To get a copy of the current documentation and examples:
    $ sudo apt-get install lammps-daily-doc
 
 which will download the doc files in
-/usr/share/doc/lammps-daily-doc/doc and example problems in
-/usr/share/doc/lammps-doc/examples.
+``/usr/share/doc/lammps-daily-doc/doc`` and example problems in
+``/usr/share/doc/lammps-doc/examples``.
 
-Note that you may still wish to download the tarball to get potential
-files and auxiliary tools.
+To get a copy of the current potentials files:
+
+.. code-block:: bash
+
+   $ sudo apt-get install lammps-daily-data
+
+which will download the potentials files to
+``/usr/share/lammps-daily/potentials``.  The ``lmp_daily`` binary is
+hard-coded to look for potential files in this directory (it does not
+use the `LAMMPS_POTENTIALS` environment variable, as described
+in :doc:`pair_coeff <pair_coeff>` command).
+
+The ``lmp_daily`` binary is built with the :ref:`KIM package <kim>` which
+results in the above command also installing the `kim-api` binaries when LAMMPS
+is installed.  In order to use potentials from `openkim.org <openkim_>`_, you
+can install the `openkim-models` package
+
+.. code-block:: bash
+
+   $ sudo apt-get install openkim-models
 
 To un-install LAMMPS, do the following:
 
@@ -72,17 +91,8 @@ To un-install LAMMPS, do the following:
 
    $ sudo apt-get remove lammps-daily
 
-Note that the lammps-daily executable is built with the following
-sequence of make commands, as if you had done the same with the
-unpacked tarball files in the src directory:
-
-.. code-block:: bash
-
-    $ make yes-all
-    $ make no-lib
-    $ make mpi
-
-Thus it builds with FFTW3 and OpenMPI.
+Please use ``lmp_daily -help`` to see which compilation options, packages,
+and styles are included in the binary.
 
 Thanks to Anton Gladky (gladky.anton at gmail.com) for setting up this
 Ubuntu package capability.
@@ -103,14 +113,14 @@ linking to the C library interface (lammps-devel, lammps-mpich-devel,
 lammps-openmpi-devel), the header for compiling programs using
 the C library interface (lammps-headers), and the LAMMPS python
 module for Python 3. All packages can be installed at the same
-time and the name of the LAMMPS executable is *lmp* and *lmp_openmpi*
-or *lmp_mpich* respectively.  By default, *lmp* will refer to the
+time and the name of the LAMMPS executable is ``lmp`` and ``lmp_openmpi``
+or ``lmp_mpich`` respectively.  By default, ``lmp`` will refer to the
 serial executable, unless one of the MPI environment modules is loaded
-("module load mpi/mpich-x86_64" or "module load mpi/openmpi-x86_64").
+(``module load mpi/mpich-x86_64`` or ``module load mpi/openmpi-x86_64``).
 Then the corresponding parallel LAMMPS executable can be used.
 The same mechanism applies when loading the LAMMPS python module.
 
-To install LAMMPS with OpenMPI and run an input in.lj with 2 CPUs do:
+To install LAMMPS with OpenMPI and run an input ``in.lj`` with 2 CPUs do:
 
 .. code-block:: bash
 
@@ -118,10 +128,10 @@ To install LAMMPS with OpenMPI and run an input in.lj with 2 CPUs do:
    $ module load mpi/openmpi-x86_64
    $ mpirun -np 2 lmp -in in.lj
 
-The "dnf install" command is needed only once. In case of a new LAMMPS
-stable release, "dnf update" will automatically update to the newer
+The ``dnf install`` command is needed only once. In case of a new LAMMPS
+stable release, ``dnf update`` will automatically update to the newer
 version as soon at the RPM files are built and uploaded to the download
-mirrors. The "module load" command is needed once per (shell) session
+mirrors. The ``module load`` command is needed once per (shell) session
 or shell terminal instance, unless it is automatically loaded from the
 shell profile.
 
@@ -134,7 +144,7 @@ can install the `openkim-models` package
 
    $ dnf install openkim-models
 
-Please use "lmp -help" to see which compilation options, packages,
+Please use ``lmp -help`` to see which compilation options, packages,
 and styles are included in the binary.
 
 Thanks to Christoph Junghans (LANL) for making LAMMPS available in Fedora.
@@ -153,10 +163,10 @@ in the `Extra Packages for Enterprise Linux (EPEL) repository <https://fedorapro
 for use with Red Hat Enterprise Linux (RHEL) or CentOS version 7.x
 and compatible Linux distributions. Names of packages, executable,
 and content are the same as described above for Fedora Linux.
-But RHEL/CentOS 7.x uses the "yum" package manager instead of "dnf"
+But RHEL/CentOS 7.x uses the ``yum`` package manager instead of ``dnf``
 in Fedora 28.
 
-Please use "lmp -help" to see which compilation options, packages,
+Please use ``lmp -help`` to see which compilation options, packages,
 and styles are included in the binary.
 
 Thanks to Christoph Junghans (LANL) for making LAMMPS available in EPEL.
@@ -176,13 +186,13 @@ in OpenSuse as of Leap 15.0. You can install the package with:
    $ zypper install lammps
 
 This includes support for OpenMPI. The name of the LAMMPS executable
-is *lmp*\ . Thus to run an input in parallel on 2 CPUs you would do:
+is ``lmp``. Thus to run an input in parallel on 2 CPUs you would do:
 
 .. code-block:: bash
 
    $ mpirun -np 2 lmp -in in.lj
 
-Please use "lmp -help" to see which compilation options, packages,
+Please use ``lmp -help`` to see which compilation options, packages,
 and styles are included in the binary.
 
 The LAMMPS binary is built with the :ref:`KIM package <kim>` which

doc/src/Modify_atom.rst

@@ -3,115 +3,169 @@ Atom styles
 
 Classes that define an :doc:`atom style <atom_style>` are derived from
 the AtomVec class and managed by the Atom class.  The atom style
-determines what attributes are associated with an atom.  A new atom
-style can be created if one of the existing atom styles does not
-define all the attributes you need to store and communicate with
-atoms.
+determines what attributes are associated with an atom and
+communicated when it is a ghost atom or migrates to a new processor.
+A new atom style can be created if one of the existing atom styles
+does not define all the attributes you need to store and communicate
+with atoms.
 
-Atom_vec_atomic.cpp is a simple example of an atom style.
+Atom_vec_atomic.cpp is the simplest example of an atom style.
+Examining the code for others will make these instructions more clear.
 
-Here is a brief description of methods you define in your new derived
-class.  See atom_vec.h for details.
+Note that the :doc:`atom style hybrid <atom_style>` command can be
+used to define atoms or particles which have the union of properties
+of individual styles.  Also the :doc:`fix property/atom <fix_property_atom>`
+command can be used to add a single property (e.g. charge
+or a molecule ID) to a style that does not have it.  It can also be
+used to add custom properties to an atom, with options to communicate
+them with ghost atoms or read them from a data file.  Other LAMMPS
+commands can access these custom properties, as can new pair, fix,
+compute styles that are written to work with these properties.  For
+example, the :doc:`set <set>` command can be used to set the values of
+custom per-atom properties from an input script.  All of these methods
+are less work than writing code for a new atom style.
 
-+-------------------------+--------------------------------------------------------------------------------+
-| init                    | one time setup (optional)                                                      |
-+-------------------------+--------------------------------------------------------------------------------+
-| grow                    | re-allocate atom arrays to longer lengths (required)                           |
-+-------------------------+--------------------------------------------------------------------------------+
-| grow_reset              | make array pointers in Atom and AtomVec classes consistent (required)          |
-+-------------------------+--------------------------------------------------------------------------------+
-| copy                    | copy info for one atom to another atom's array locations (required)            |
-+-------------------------+--------------------------------------------------------------------------------+
-| pack_comm               | store an atom's info in a buffer communicated every timestep (required)        |
-+-------------------------+--------------------------------------------------------------------------------+
-| pack_comm_vel           | add velocity info to communication buffer (required)                           |
-+-------------------------+--------------------------------------------------------------------------------+
-| pack_comm_hybrid        | store extra info unique to this atom style (optional)                          |
-+-------------------------+--------------------------------------------------------------------------------+
-| unpack_comm             | retrieve an atom's info from the buffer (required)                             |
-+-------------------------+--------------------------------------------------------------------------------+
-| unpack_comm_vel         | also retrieve velocity info (required)                                         |
-+-------------------------+--------------------------------------------------------------------------------+
-| unpack_comm_hybrid      | retrieve extra info unique to this atom style (optional)                       |
-+-------------------------+--------------------------------------------------------------------------------+
-| pack_reverse            | store an atom's info in a buffer communicating partial forces  (required)      |
-+-------------------------+--------------------------------------------------------------------------------+
-| pack_reverse_hybrid     | store extra info unique to this atom style (optional)                          |
-+-------------------------+--------------------------------------------------------------------------------+
-| unpack_reverse          | retrieve an atom's info from the buffer (required)                             |
-+-------------------------+--------------------------------------------------------------------------------+
-| unpack_reverse_hybrid   | retrieve extra info unique to this atom style (optional)                       |
-+-------------------------+--------------------------------------------------------------------------------+
-| pack_border             | store an atom's info in a buffer communicated on neighbor re-builds (required) |
-+-------------------------+--------------------------------------------------------------------------------+
-| pack_border_vel         | add velocity info to buffer (required)                                         |
-+-------------------------+--------------------------------------------------------------------------------+
-| pack_border_hybrid      | store extra info unique to this atom style (optional)                          |
-+-------------------------+--------------------------------------------------------------------------------+
-| unpack_border           | retrieve an atom's info from the buffer (required)                             |
-+-------------------------+--------------------------------------------------------------------------------+
-| unpack_border_vel       | also retrieve velocity info (required)                                         |
-+-------------------------+--------------------------------------------------------------------------------+
-| unpack_border_hybrid    | retrieve extra info unique to this atom style (optional)                       |
-+-------------------------+--------------------------------------------------------------------------------+
-| pack_exchange           | store all an atom's info to migrate to another processor (required)            |
-+-------------------------+--------------------------------------------------------------------------------+
-| unpack_exchange         | retrieve an atom's info from the buffer (required)                             |
-+-------------------------+--------------------------------------------------------------------------------+
-| size_restart            | number of restart quantities associated with proc's atoms (required)           |
-+-------------------------+--------------------------------------------------------------------------------+
-| pack_restart            | pack atom quantities into a buffer (required)                                  |
-+-------------------------+--------------------------------------------------------------------------------+
-| unpack_restart          | unpack atom quantities from a buffer (required)                                |
-+-------------------------+--------------------------------------------------------------------------------+
-| create_atom             | create an individual atom of this style (required)                             |
-+-------------------------+--------------------------------------------------------------------------------+
-| data_atom               | parse an atom line from the data file (required)                               |
-+-------------------------+--------------------------------------------------------------------------------+
-| data_atom_hybrid        | parse additional atom info unique to this atom style (optional)                |
-+-------------------------+--------------------------------------------------------------------------------+
-| data_vel                | parse one line of velocity information from data file (optional)               |
-+-------------------------+--------------------------------------------------------------------------------+
-| data_vel_hybrid         | parse additional velocity data unique to this atom style (optional)            |
-+-------------------------+--------------------------------------------------------------------------------+
-| memory_usage            | tally memory allocated by atom arrays (required)                               |
-+-------------------------+--------------------------------------------------------------------------------+
+If you follow these directions your new style will automatically work
+in tandem with others via the :doc:`atom_style hybrid <atom_style>`
+command.
 
-The constructor of the derived class sets values for several variables
-that you must set when defining a new atom style, which are documented
-in atom_vec.h.  New atom arrays are defined in atom.cpp.  Search for
-the word "customize" and you will find locations you will need to
-modify.
+The first step is to define a set of strings in the constructor of the
+new derived class.  Each string will have zero or more space-separated
+variable names which are identical to those used in the atom.h header
+file for per-atom properties.  Note that some represent per-atom
+vectors (q, molecule) while other are per-atom arrays (x,v).  For all
+but the last 2 strings you do not need to specify any of
+(id,type,x,v,f).  Those are included automatically as needed in the
+other strings.
 
-.. note::
+.. list-table::
 
-   It is possible to add some attributes, such as a molecule ID, to
-   atom styles that do not have them via the :doc:`fix property/atom <fix_property_atom>` command.  This command also
-   allows new custom attributes consisting of extra integer or
-   floating-point values to be added to atoms.  See the :doc:`fix property/atom <fix_property_atom>` doc page for examples of cases
-   where this is useful and details on how to initialize, access, and
-   output the custom values.
+   * - fields_grow
+     - full list of properties which is allocated and stored
+   * - fields_copy
+     - list of properties to copy atoms are rearranged on-processor
+   * - fields_comm
+     - list of properties communicated to ghost atoms every step
+   * - fields_comm_vel
+     - additional properties communicated if :doc:`comm_modify vel <atom_style>` is used
+   * - fields_reverse
+     - list of properties summed from ghost atoms every step
+   * - fields_border
+     - list of properties communicated with ghost atoms every reneighboring step
+   * - fields_border_vel
+     - additional properties communicated if :doc:`comm_modify vel <atom_style>` is used
+   * - fields_exchange
+     - list of properties communicated when an atom migrates to another processor
+   * - fields_restart
+     - list of properties written/read to/from a restart file
+   * - fields_create
+     - list of properties defined when an atom is created by :doc:`create_atoms <create_atoms>`
+   * - fields_data_atom
+     - list of properties (in order) in the Atoms section of a data file, as read by :doc:`read_data <read_data>`
+   * - fields_data_vel
+     - list of properties (in order) in the Velocities section of a data file, as read by :doc:`read_data <read_data>`
 
-New :doc:`pair styles <pair_style>`, :doc:`fixes <fix>`, or
-:doc:`computes <compute>` can be added to LAMMPS, as discussed below.
-The code for these classes can use the per-atom properties defined by
-fix property/atom.  The Atom class has a find_custom() method that is
-useful in this context:
+In these strings you can list variable names which LAMMPS already
+defines (in some other atom style), or you can create new variable
+names.  You should not re-use a LAMMPS variable for something with
+different meaning in your atom style.  If the meaning is related, but
+interpreted differently by your atom style, then using the same
+variable name means a user should not use your style and the other
+style together in a :doc:`atom_style hybrid <atom_style>` command.
+Because there will only be one value of the variable and different
+parts of LAMMPS will then likely use it differently.  LAMMPS has
+no way of checking for this.
 
-.. code-block:: c++
+If you are defining new variable names then make them descriptive and
+unique to your new atom style.  For example choosing "e" for energy is
+a bad choice; it is too generic.  A better choice would be "e_foo",
+where "foo" is specific to your style.
 
-   int index = atom->find_custom(char *name, int &flag);
+If any of the variable names in your new atom style do not exist in
+LAMMPS, you need to add them to the src/atom.h and atom.cpp files.
 
-The "name" of a custom attribute, as specified in the :doc:`fix property/atom <fix_property_atom>` command, is checked to verify
-that it exists and its index is returned.  The method also sets flag =
-0/1 depending on whether it is an integer or floating-point attribute.
-The vector of values associated with the attribute can then be
-accessed using the returned index as
+Search for the word "customize" or "customization" in these 2 files to
+see where to add your variable.  Adding a flag to the 2nd
+customization section in atom.h is only necessary if your code (e.g. a
+pair style) needs to check that a per-atom property is defined.  These
+flags should also be set in the constructor of the atom style child
+class.
 
-.. code-block:: c++
+In atom.cpp, aside from the constructor and destructor, there are 3
+methods that a new variable name or flag needs to be added to.
 
-   int *ivector = atom->ivector[index];
-   double *dvector = atom->dvector[index];
+In Atom::peratom_create() when using the add_peratom() method, a
+final length argument of 0 is for per-atom vectors, a length > 1 is
+for per-atom arrays.  Note the use of an extra per-thread flag and the
+add_peratom_vary() method when last dimension of the array is
+variable-length.
 
-Ivector or dvector are vectors of length Nlocal = # of owned atoms,
-which store the attributes of individual atoms.
+Adding the variable name to Atom::extract() enable the per-atom data
+to be accessed through the :doc:`LAMMPS library interface
+<Howto_library>` by a calling code, including from :doc:`Python
+<Python_head>`.
+
+The constructor of the new atom style will also typically set a few
+flags which are defined at the top of atom_vec.h.  If these are
+unclear, see how other atom styles use them.
+
+The grow_pointers() method is also required to make
+a copy of peratom data pointers, as explained in the code.
+
+There are a number of other optional methods which your atom style can
+implement.  These are only needed if you need to do something
+out-of-the-ordinary which the default operation of the AtomVec parent
+class does not take care of.  The best way to figure out why they are
+sometimes useful is to look at how other atom styles use them.
+
+* process_args = use if the atom style has arguments
+* init = called before each run
+* force_clear = called before force computations each timestep
+
+A few atom styles define "bonus" data associated with some or all of
+their particles, such as :doc:`atom_style ellipsoid or tri
+<atom_style>`.  These methods work with that data:
+
+* copy_bonus
+* clear_bonus
+* pack_comm_bonus
+* unpack_comm_bonus
+* pack_border_bonus
+* unpack_border_bonus
+* pack_exchange_bonus
+* unpack_exchange_bonus
+* size_restart_bonus
+* pack_restart_bonus
+* unpack_restart_bonus
+* data_atom_bonus
+* memory_usage_bonus
+
+The :doc:`atom_style body <atom_style>` command can define a particle
+geometry with an arbitrary number of values.  This method reads it
+from a data file:
+
+* data_body
+
+These methods are called before or after operations handled by the
+parent AtomVec class.  They allow an atom style to do customized
+operations on the per-atom values.  For example :doc:`atom_style
+sphere <atom_style>` reads a diameter and density of each particle
+from a data file.  But these need to be converted internally to a
+radius and mass.  That operation is done in the data_atom_post()
+method.
+
+* pack_restart_pre
+* pack_restart_post
+* unpack_restart_init
+* create_atom_post
+* data_atom_post
+* pack_data_pre
+* pack_data_post
+
+These methods enable the :doc:`compute property/atom <compute_property_atom>`
+command to access per-atom variables it does not
+already define as arguments, so that they can be written to a dump
+file or used by other LAMMPS commands.
+
+* property_atom
+* pack_property_atom

doc/src/Packages_details.rst

@@ -2064,7 +2064,7 @@ molecules, and chiral-sensitive reactions.
 * examples/USER/reaction
 * `2017 LAMMPS Workshop <https://lammps.sandia.gov/workshops/Aug17/pdf/gissinger.pdf>`_
 * `2019 LAMMPS Workshop <https://lammps.sandia.gov/workshops/Aug19/talk_gissinger.pdf>`_
-* disarmmd.org
+* reacter.org
 
 ----------
 

doc/src/Speed_kokkos.rst

@@ -9,10 +9,7 @@ different back end languages such as CUDA, OpenMP, or Pthreads.  The
 Kokkos library also provides data abstractions to adjust (at compile
 time) the memory layout of data structures like 2d and 3d arrays to
 optimize performance on different hardware. For more information on
-Kokkos, see `GitHub <https://github.com/kokkos/kokkos>`_. Kokkos is
-part of `Trilinos <https://www.trilinos.org/>`_. The Kokkos
-library was written primarily by Carter Edwards, Christian Trott, and
-Dan Sunderland (all Sandia).
+Kokkos, see `GitHub <https://github.com/kokkos/kokkos>`_.
 
 The LAMMPS KOKKOS package contains versions of pair, fix, and atom
 styles that use data structures and macros provided by the Kokkos
@@ -21,7 +18,7 @@ package was developed primarily by Christian Trott (Sandia) and Stan
 Moore (Sandia) with contributions of various styles by others,
 including Sikandar Mashayak (UIUC), Ray Shan (Sandia), and Dan Ibanez
 (Sandia). For more information on developing using Kokkos abstractions
-see the Kokkos programmers' guide at /lib/kokkos/doc/Kokkos_PG.pdf.
+see the Kokkos `Wiki <https://github.com/kokkos/kokkos/wiki>`_.
 
 Kokkos currently provides support for 3 modes of execution (per MPI
 task). These are Serial (MPI-only for CPUs and Intel Phi), OpenMP
@@ -31,33 +28,30 @@ compatible with specific hardware.
 
 .. note::
 
-   Kokkos support within LAMMPS must be built with a C++11 compatible
-   compiler. This means GCC version 4.7.2 or later, Intel 14.0.4 or later, or
-   Clang 3.5.2 or later is required.
-
-.. note::
-
-   To build with Kokkos support for NVIDIA GPUs, NVIDIA CUDA
+   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
-   the discussion for the :doc:`GPU package <Speed_gpu>` for details of how
-   to check and do this.
+   the discussion for the :doc:`GPU package <Speed_gpu>` for details of
+   how to check and do this.
 
 .. note::
 
-   Kokkos with CUDA currently implicitly assumes that the MPI library
-   is CUDA-aware. This is not always the case, especially when using
-   pre-compiled MPI libraries provided by a Linux distribution. This is not
-   a problem when using only a single GPU with a single MPI rank. When
-   running with multiple MPI ranks, you may see segmentation faults without
-   CUDA-aware MPI support. These can be avoided by adding the flags :doc:`-pk kokkos cuda/aware off <Run_options>` to the LAMMPS command line or by
-   using the command :doc:`package kokkos cuda/aware off <package>` in the
-   input file.
+   Kokkos with CUDA currently implicitly assumes that the MPI library is
+   CUDA-aware. This is not always the case, especially when using
+   pre-compiled MPI libraries provided by a Linux distribution. This is
+   not a problem when using only a single GPU with a single MPI
+   rank. When running with multiple MPI ranks, you may see segmentation
+   faults without CUDA-aware MPI support. These can be avoided by adding
+   the flags :doc:`-pk kokkos cuda/aware off <Run_options>` to the
+   LAMMPS command line or by using the command :doc:`package kokkos
+   cuda/aware off <package>` in the input file.
 
-**Building LAMMPS with the KOKKOS package:**
+Building LAMMPS with the KOKKOS package
+"""""""""""""""""""""""""""""""""""""""
 
 See the :ref:`Build extras <kokkos>` doc page for instructions.
 
-**Running LAMMPS with the KOKKOS package:**
+Running LAMMPS with the KOKKOS package
+""""""""""""""""""""""""""""""""""""""
 
 All Kokkos operations occur within the context of an individual MPI
 task running on a single node of the machine. The total number of MPI
@@ -66,7 +60,8 @@ usual manner via the mpirun or mpiexec commands, and is independent of
 Kokkos. E.g. the mpirun command in OpenMPI does this via its -np and
 -npernode switches. Ditto for MPICH via -np and -ppn.
 
-**Running on a multi-core CPU:**
+Running on a multi-core CPU
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Here is a quick overview of how to use the KOKKOS package
 for CPU acceleration, assuming one or more 16-core nodes.
@@ -142,7 +137,8 @@ atom.  When using the Kokkos Serial back end or the OpenMP back end with
 a single thread, no duplication or atomic operations are used. For CUDA
 and half neighbor lists, the KOKKOS package always uses atomic operations.
 
-**Core and Thread Affinity:**
+CPU Cores, Sockets and Thread Affinity
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 When using multi-threading, it is important for performance to bind
 both MPI tasks to physical cores, and threads to physical cores, so
@@ -156,15 +152,16 @@ for your MPI installation), binding can be forced with these flags:
    OpenMPI 1.8: mpirun -np 2 --bind-to socket --map-by socket ./lmp_openmpi ...
    Mvapich2 2.0: mpiexec -np 2 --bind-to socket --map-by socket ./lmp_mvapich ...
 
-For binding threads with KOKKOS OpenMP, use thread affinity
-environment variables to force binding. With OpenMP 3.1 (gcc 4.7 or
-later, intel 12 or later) setting the environment variable
-OMP_PROC_BIND=true should be sufficient. In general, for best
-performance with OpenMP 4.0 or better set OMP_PROC_BIND=spread and
-OMP_PLACES=threads.  For binding threads with the KOKKOS pthreads
-option, compile LAMMPS the KOKKOS HWLOC=yes option as described below.
+For binding threads with KOKKOS OpenMP, use thread affinity environment
+variables to force binding. With OpenMP 3.1 (gcc 4.7 or later, intel 12
+or later) setting the environment variable ``OMP_PROC_BIND=true`` should
+be sufficient. In general, for best performance with OpenMP 4.0 or later
+set ``OMP_PROC_BIND=spread`` and ``OMP_PLACES=threads``.  For binding
+threads with the KOKKOS pthreads option, compile LAMMPS with the hwloc
+or libnuma support enabled as described in the :ref:`extra build options page <kokkos>`.
 
-**Running on Knight's Landing (KNL) Intel Xeon Phi:**
+Running on Knight's Landing (KNL) Intel Xeon Phi
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Here is a quick overview of how to use the KOKKOS package for the
 Intel Knight's Landing (KNL) Xeon Phi:
@@ -222,7 +219,8 @@ threads/task as Nt. The product of these two values should be N, i.e.
    them in "native" mode, not "offload" mode like the USER-INTEL package
    supports.
 
-**Running on GPUs:**
+Running on GPUs
+^^^^^^^^^^^^^^^
 
 Use the "-k" :doc:`command-line switch <Run_options>` to specify the
 number of GPUs per node. Typically the -np setting of the mpirun command
@@ -257,7 +255,7 @@ one or more nodes, each with two GPUs:
    running on GPUs is to use "full" neighbor lists and set the Newton flag
    to "off" for both pairwise and bonded interactions, along with threaded
    communication. When running on Maxwell or Kepler GPUs, this will
-   typically be best. For Pascal GPUs, using "half" neighbor lists and
+   typically be best. For Pascal GPUs and beyond, using "half" neighbor lists and
    setting the Newton flag to "on" may be faster. For many pair styles,
    setting the neighbor binsize equal to twice the CPU default value will
    give speedup, which is the default when running on GPUs. Use the "-pk
@@ -270,13 +268,6 @@ one or more nodes, each with two GPUs:
 
    mpirun -np 2 lmp_kokkos_cuda_openmpi -k on g 2 -sf kk -pk kokkos newton on neigh half binsize 2.8 -in in.lj      # Newton on, half neighbor list, set binsize = neighbor ghost cutoff
 
-.. note::
-
-   For good performance of the KOKKOS package on GPUs, you must
-   have Kepler generation GPUs (or later). The Kokkos library exploits
-   texture cache options not supported by Telsa generation GPUs (or
-   older).
-
 .. note::
 
    When using a GPU, you will achieve the best performance if your
@@ -293,7 +284,8 @@ one or more nodes, each with two GPUs:
    kspace, etc., you must set the environment variable CUDA_LAUNCH_BLOCKING=1.
    However, this will reduce performance and is not recommended for production runs.
 
-**Run with the KOKKOS package by editing an input script:**
+Run with the KOKKOS package by editing an input script
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Alternatively the effect of the "-sf" or "-pk" switches can be
 duplicated by adding the :doc:`package kokkos <package>` or :doc:`suffix kk <suffix>` commands to your input script.
@@ -316,17 +308,24 @@ You only need to use the :doc:`package kokkos <package>` command if you
 wish to change any of its option defaults, as set by the "-k on"
 :doc:`command-line switch <Run_options>`.
 
-**Using OpenMP threading and CUDA together (experimental):**
+**Using OpenMP threading and CUDA together:**
 
 With the KOKKOS package, both OpenMP multi-threading and GPUs can be
-used together in a few special cases. In the Makefile, the
-KOKKOS_DEVICES variable must include both "Cuda" and "OpenMP", as is
-the case for /src/MAKE/OPTIONS/Makefile.kokkos_cuda_mpi
+compiled and used together in a few special cases. In the makefile for
+the conventional build, the KOKKOS_DEVICES variable must include both,
+"Cuda" and "OpenMP", as is the case for ``/src/MAKE/OPTIONS/Makefile.kokkos_cuda_mpi``.
 
 .. code-block:: bash
 
    KOKKOS_DEVICES=Cuda,OpenMP
 
+When building with CMake you need to enable both features as it is done
+in the ``kokkos-cuda.cmake`` CMake preset file.
+
+.. code-block:: bash
+
+   cmake ../cmake -DKokkos_ENABLE_CUDA=yes -DKokkos_ENABLE_OPENMP=yes
+
 The suffix "/kk" is equivalent to "/kk/device", and for Kokkos CUDA,
 using the "-sf kk" in the command line gives the default CUDA version
 everywhere.  However, if the "/kk/host" suffix is added to a specific
@@ -360,7 +359,8 @@ suffix for kspace and bonds, angles, etc.  in the input file and the
 sure the environment variable CUDA_LAUNCH_BLOCKING is not set to "1"
 so CPU/GPU overlap can occur.
 
-**Speed-ups to expect:**
+Performance to expect
+"""""""""""""""""""""
 
 The performance of KOKKOS running in different modes is a function of
 your hardware, which KOKKOS-enable styles are used, and the problem
@@ -377,52 +377,26 @@ Generally speaking, the following rules of thumb apply:
   performance of a KOKKOS style is a bit slower than the USER-OMP
   package.
 * When running large number of atoms per GPU, KOKKOS is typically faster
-  than the GPU package.
+  than the GPU package when compiled for double precision. The benefit
+  of using single or mixed precision with the GPU package depends
+  significantly on the hardware in use and the simulated system and pair
+  style.
 * When running on Intel hardware, KOKKOS is not as fast as
-  the USER-INTEL package, which is optimized for that hardware.
+  the USER-INTEL package, which is optimized for x86 hardware (not just
+  from Intel) and compilation with the Intel compilers.  The USER-INTEL
+  package also can increase the vector length of vector instructions
+  by switching to single or mixed precision mode.
 
 See the `Benchmark page <https://lammps.sandia.gov/bench.html>`_ of the
 LAMMPS web site for performance of the KOKKOS package on different
 hardware.
 
-**Advanced Kokkos options:**
+Advanced Kokkos options
+"""""""""""""""""""""""
 
-There are other allowed options when building with the KOKKOS package.
-As explained on the :ref:`Build extras <kokkos>` doc page,
-they can be set either as variables on the make command line or in
-Makefile.machine, or they can be specified as CMake variables.  Each
-takes a value shown below.  The default value is listed, which is set
-in the lib/kokkos/Makefile.kokkos file.
-
-* KOKKOS_DEBUG, values = *yes*\ , *no*\ , default = *no*
-* KOKKOS_USE_TPLS, values = *hwloc*\ , *librt*\ , *experimental_memkind*, default = *none*
-* KOKKOS_CXX_STANDARD, values = *c++11*\ , *c++1z*\ , default = *c++11*
-* KOKKOS_OPTIONS, values = *aggressive_vectorization*, *disable_profiling*, default = *none*
-* KOKKOS_CUDA_OPTIONS, values = *force_uvm*, *use_ldg*, *rdc*\ , *enable_lambda*, default = *enable_lambda*
-
-KOKKOS_USE_TPLS=hwloc binds threads to hardware cores, so they do not
-migrate during a simulation. KOKKOS_USE_TPLS=hwloc should always be
-used if running with KOKKOS_DEVICES=Pthreads for pthreads. It is not
-necessary for KOKKOS_DEVICES=OpenMP for OpenMP, because OpenMP
-provides alternative methods via environment variables for binding
-threads to hardware cores.  More info on binding threads to cores is
-given on the :doc:`Speed omp <Speed_omp>` doc page.
-
-KOKKOS_USE_TPLS=librt enables use of a more accurate timer mechanism
-on most Unix platforms. This library is not available on all
-platforms.
-
-KOKKOS_DEBUG is only useful when developing a Kokkos-enabled style
-within LAMMPS. KOKKOS_DEBUG=yes enables printing of run-time
-debugging information that can be useful. It also enables runtime
-bounds checking on Kokkos data structures.
-
-KOKKOS_CXX_STANDARD and KOKKOS_OPTIONS are typically not changed when
-building LAMMPS.
-
-KOKKOS_CUDA_OPTIONS are additional options for CUDA. The LAMMPS KOKKOS
-package must be compiled with the *enable_lambda* option when using
-GPUs.
+There are other allowed options when building with the KOKKOS package
+that can improve performance or assist in debugging or profiling.
+They are explained on the :ref:`KOKKOS section of the build extras <kokkos>` doc page,
 
 Restrictions
 """"""""""""

doc/src/atom_style.rst

@@ -10,7 +10,7 @@ Syntax
 
    atom_style style args
 
-* style = *angle* or *atomic* or *body* or *bond* or *charge* or *dipole* or         *dpd* or *edpd* or *mdpd* or *tdpd* or *electron* or *ellipsoid* or         *full* or *line* or *meso* or *molecular* or *peri* or *smd* or         *sphere* or *spin* or *tri* or *template* or *hybrid*
+* style = *angle* or *atomic* or *body* or *bond* or *charge* or *dipole* or  *dpd* or *edpd* or *electron* or *ellipsoid* or *full* or *line* or *mdpd* or *molecular* or *peri* or *smd* or *sph* or *sphere* or *spin* or *tdpd* or *tri* or *template* or *hybrid*
 
   .. parsed-literal::
 
@@ -18,7 +18,9 @@ Syntax
          *body* args = bstyle bstyle-args
            bstyle = style of body particles
            bstyle-args = additional arguments specific to the bstyle
-                         see the :doc:`Howto body <Howto_body>` doc page for details
+                         see the :doc:`Howto body <Howto_body>` doc
+                         page for details
+         *sphere* arg = 0/1 (optional) for static/dynamic particle radii
          *tdpd* arg = Nspecies
            Nspecies = # of chemical species
          *template* arg = template-ID
@@ -91,10 +93,6 @@ quantities.
 +--------------+-----------------------------------------------------+--------------------------------------+
 | *edpd*       | temperature and heat capacity                       | eDPD particles                       |
 +--------------+-----------------------------------------------------+--------------------------------------+
-| *mdpd*       | density                                             | mDPD particles                       |
-+--------------+-----------------------------------------------------+--------------------------------------+
-| *tdpd*       | chemical concentration                              | tDPD particles                       |
-+--------------+-----------------------------------------------------+--------------------------------------+
 | *electron*   | charge and spin and eradius                         | electronic force field               |
 +--------------+-----------------------------------------------------+--------------------------------------+
 | *ellipsoid*  | shape, quaternion, angular momentum                 | aspherical particles                 |
@@ -103,7 +101,7 @@ quantities.
 +--------------+-----------------------------------------------------+--------------------------------------+
 | *line*       | end points, angular velocity                        | rigid bodies                         |
 +--------------+-----------------------------------------------------+--------------------------------------+
-| *meso*       | rho, e, cv                                          | SPH particles                        |
+| *mdpd*       | density                                             | mDPD particles                       |
 +--------------+-----------------------------------------------------+--------------------------------------+
 | *molecular*  | bonds, angles, dihedrals, impropers                 | uncharged molecules                  |
 +--------------+-----------------------------------------------------+--------------------------------------+
@@ -111,10 +109,14 @@ quantities.
 +--------------+-----------------------------------------------------+--------------------------------------+
 | *smd*        | volume, kernel diameter, contact radius, mass       | solid and fluid SPH particles        |
 +--------------+-----------------------------------------------------+--------------------------------------+
+| *sph*        | rho, esph, cv                                       | SPH particles                        |
++--------------+-----------------------------------------------------+--------------------------------------+
 | *sphere*     | diameter, mass, angular velocity                    | granular models                      |
 +--------------+-----------------------------------------------------+--------------------------------------+
 | *spin*       | magnetic moment                                     | system with magnetic particles       |
 +--------------+-----------------------------------------------------+--------------------------------------+
+| *tdpd*       | chemical concentration                              | tDPD particles                       |
++--------------+-----------------------------------------------------+--------------------------------------+
 | *template*   | template index, template atom                       | small molecules with fixed topology  |
 +--------------+-----------------------------------------------------+--------------------------------------+
 | *tri*        | corner points, angular momentum                     | rigid bodies                         |
@@ -144,9 +146,16 @@ basis.
 For the *sphere* style, the particles are spheres and each stores a
 per-particle diameter and mass.  If the diameter > 0.0, the particle
 is a finite-size sphere.  If the diameter = 0.0, it is a point
-particle.  Note that by use of the *disc* keyword with the :doc:`fix nve/sphere <fix_nve_sphere>`, :doc:`fix nvt/sphere <fix_nvt_sphere>`,
-:doc:`fix nph/sphere <fix_nph_sphere>`, :doc:`fix npt/sphere <fix_npt_sphere>` commands, spheres can be effectively
-treated as 2d discs for a 2d simulation if desired.  See also the :doc:`set density/disc <set>` command.
+particle.  Note that by use of the *disc* keyword with the :doc:`fix
+nve/sphere <fix_nve_sphere>`, :doc:`fix nvt/sphere <fix_nvt_sphere>`,
+:doc:`fix nph/sphere <fix_nph_sphere>`, :doc:`fix npt/sphere
+<fix_npt_sphere>` commands, spheres can be effectively treated as 2d
+discs for a 2d simulation if desired.  See also the :doc:`set
+density/disc <set>` command.  The *sphere* style takes an optional 0
+or 1 argument.  A value of 0 means the radius of each sphere is
+constant for the duration of the simulation.  A value of 1 means the
+radii may vary dynamically during the simulation, e.g. due to use of
+the :doc:`fix adapt <fix_adapt>` command.
 
 For the *ellipsoid* style, the particles are ellipsoids and each
 stores a flag which indicates whether it is a finite-size ellipsoid or
@@ -189,8 +198,8 @@ particles which store a set of chemical concentration. An integer
 "cc_species" is required to specify the number of chemical species
 involved in a tDPD system.
 
-The *meso* style is for smoothed particle hydrodynamics (SPH)
-particles which store a density (rho), energy (e), and heat capacity
+The *sph* style is for smoothed particle hydrodynamics (SPH)
+particles which store a density (rho), energy (esph), and heat capacity
 (cv).
 
 The *smd* style is for a general formulation of Smooth Particle
@@ -335,7 +344,7 @@ for energy-conserving dissipative particle dynamics (eDPD), many-body
 dissipative particle dynamics (mDPD), and transport dissipative particle
 dynamics (tDPD), respectively.
 
-The *meso* style is part of the USER-SPH package for smoothed particle
+The *sph* style is part of the USER-SPH package for smoothed particle
 hydrodynamics (SPH).  See `this PDF guide <USER/sph/SPH_LAMMPS_userguide.pdf>`_ to using SPH in LAMMPS.
 
 The *spin* style is part of the SPIN package.
@@ -351,7 +360,8 @@ Related commands
 Default
 """""""
 
-atom_style atomic
+The default atom style is atomic.  If atom_style sphere is used its
+default argument is 0.
 
 ----------
 

doc/src/change_box.rst

@@ -299,6 +299,12 @@ match what is stored in the restart file.  So if you wish to change
 them, you should use the change_box command after the read_restart
 command.
 
+.. note::
+
+   Changing a periodic boundary to a non-periodic one will also
+   cause the image flag for that dimension to be reset to 0 for
+   all atoms.  LAMMPS will print a warning message, if that happens.
+
 ----------
 
 The *ortho* and *triclinic* keywords convert the simulation box to be

doc/src/compute.rst

@@ -225,9 +225,6 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` doc
 * :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:`meso/e/atom <compute_meso_e_atom>` - per-atom internal energy of Smooth-Particle Hydrodynamics atoms
-* :doc:`meso/rho/atom <compute_meso_rho_atom>` - per-atom mesoscopic density of Smooth-Particle Hydrodynamics atoms
-* :doc:`meso/t/atom <compute_meso_t_atom>` - per-atom internal temperature of Smooth-Particle Hydrodynamics atoms
 * :doc:`momentum <compute_momentum>` - translational momentum
 * :doc:`msd <compute_msd>` - mean-squared displacement of group of atoms
 * :doc:`msd/chunk <compute_msd_chunk>` - mean-squared displacement for each chunk
@@ -279,6 +276,9 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` doc
 * :doc:`sna/atom <compute_sna_atom>` - bispectrum components for each atom
 * :doc:`snad/atom <compute_sna_atom>` - derivative of bispectrum components for each atom
 * :doc:`snav/atom <compute_sna_atom>` - virial contribution from bispectrum components for each atom
+* :doc:`sph/e/atom <compute_sph_e_atom>` - per-atom internal energy of Smooth-Particle Hydrodynamics atoms
+* :doc:`sph/rho/atom <compute_sph_rho_atom>` - per-atom density of Smooth-Particle Hydrodynamics atoms
+* :doc:`sph/t/atom <compute_sph_t_atom>` - per-atom internal temperature of Smooth-Particle Hydrodynamics atoms
 * :doc:`spin <compute_spin>` - magnetic quantities for a system of atoms having spins
 * :doc:`stress/atom <compute_stress_atom>` - stress tensor for each atom
 * :doc:`stress/mop <compute_stress_mop>` - normal components of the local stress tensor using the method of planes
@@ -307,6 +307,7 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` doc
 * :doc:`torque/chunk <compute_torque_chunk>` - torque applied on each chunk
 * :doc:`vacf <compute_vacf>` - velocity auto-correlation function of group of atoms
 * :doc:`vcm/chunk <compute_vcm_chunk>` - velocity of center-of-mass for each chunk
+* :doc:`viscosity/cos <compute_viscosity_cos>` - velocity profile under cosine-shaped acceleration
 * :doc:`voronoi/atom <compute_voronoi_atom>` - Voronoi volume and neighbors for each atom
 * :doc:`xrd <compute_xrd>` - x-ray diffraction intensity on a mesh of reciprocal lattice nodes
 

doc/src/compute_coord_atom.rst

@@ -3,6 +3,9 @@
 compute coord/atom command
 ==========================
 
+compute coord/atom/kk command
+===================================
+
 Syntax
 """"""
 
@@ -109,6 +112,30 @@ too frequently.
    :doc:`special_bonds <special_bonds>` command that includes all pairs in
    the neighbor list.
 
+----------
+
+
+Styles with a *gpu*\ , *intel*\ , *kk*\ , *omp*\ , or *opt* suffix are
+functionally the same as the corresponding style without the suffix.
+They have been optimized to run faster, depending on your available
+hardware, as discussed on the :doc:`Speed packages <Speed_packages>` doc
+page.  The accelerated styles take the same arguments and should
+produce the same results, except for round-off and precision issues.
+
+These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively.  They are only enabled if
+LAMMPS was built with those packages.  See the :doc:`Build package <Build_package>` doc page for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the :doc:`-suffix command-line switch <Run_options>` when you invoke LAMMPS, or you can use the
+:doc:`suffix <suffix>` command in your input script.
+
+See the :doc:`Speed packages <Speed_packages>` doc page for more
+instructions on how to use the accelerated styles effectively.
+
+
+----------
+
 **Output info:**
 
 For *cstyle* cutoff, this compute can calculate a per-atom vector or

doc/src/compute_gyration_shape_chunk.rst

@@ -37,7 +37,7 @@ and the relative shape anisotropy, k:
  b = & l_y - l_x \\
  k = & \frac{3}{2} \frac{l_x^2+l_y^2+l_z^2}{(l_x+l_y+l_z)^2} - \frac{1}{2}
 
-where :math:`l_x` <= :math:`l_y` <= :math`l_z` are the three eigenvalues of the gyration tensor. A general description
+where :math:`l_x` <= :math:`l_y` <= :math:`l_z` are the three eigenvalues of the gyration tensor. A general description
 of these parameters is provided in :ref:`(Mattice) <Mattice2>` while an application to polymer systems
 can be found in :ref:`(Theodorou) <Theodorou2>`. The asphericity  is always non-negative and zero
 only when the three principal moments are equal. This zero condition is met when the distribution

doc/src/compute_orientorder_atom.rst

@@ -3,6 +3,9 @@
 compute orientorder/atom command
 ================================
 
+compute orientorder/atom/kk command
+===================================
+
 Syntax
 """"""
 
@@ -16,13 +19,14 @@ Syntax
 
   .. parsed-literal::
 
-     keyword = *cutoff* or *nnn* or *degrees* or *components*
+     keyword = *cutoff* or *nnn* or *degrees* or *components* or *chunksize*
        *cutoff* value = distance cutoff
        *nnn* value = number of nearest neighbors
        *degrees* values = nlvalues, l1, l2,...
        *wl* value = yes or no
        *wl/hat* value = yes or no
        *components* value = ldegree
+       *chunksize* value = number of atoms in each pass 
 
 Examples
 """"""""
@@ -104,6 +108,14 @@ in conjunction with :doc:`compute coord_atom <compute_coord_atom>` to
 calculate the ten Wolde's criterion to identify crystal-like
 particles, as discussed in :ref:`ten Wolde <tenWolde2>`.
 
+The optional keyword *chunksize* is only applicable when using the
+the KOKKOS package and is ignored otherwise. This keyword controls
+the number of atoms in each pass used to compute the bond-orientational
+order parameters and is used to avoid running out of memory. For example
+if there are 4000 atoms in the simulation and the *chunksize*
+is set to 2000, the parameter calculation will be broken up
+into two passes.
+
 The value of :math:`Q_l` is set to zero for atoms not in the
 specified compute group, as well as for atoms that have less than
 *nnn* neighbors within the distance cutoff, unless *nnn* is NULL.
@@ -128,6 +140,30 @@ too frequently.
    :doc:`special_bonds <special_bonds>` command that includes all pairs in
    the neighbor list.
 
+----------
+
+
+Styles with a *gpu*\ , *intel*\ , *kk*\ , *omp*\ , or *opt* suffix are
+functionally the same as the corresponding style without the suffix.
+They have been optimized to run faster, depending on your available
+hardware, as discussed on the :doc:`Speed packages <Speed_packages>` doc
+page.  The accelerated styles take the same arguments and should
+produce the same results, except for round-off and precision issues.
+
+These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
+USER-OMP and OPT packages, respectively.  They are only enabled if
+LAMMPS was built with those packages.  See the :doc:`Build package <Build_package>` doc page for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the :doc:`-suffix command-line switch <Run_options>` when you invoke LAMMPS, or you can use the
+:doc:`suffix <suffix>` command in your input script.
+
+See the :doc:`Speed packages <Speed_packages>` doc page for more
+instructions on how to use the accelerated styles effectively.
+
+
+----------
+
 **Output info:**
 
 This compute calculates a per-atom array with *nlvalues* columns,
@@ -165,7 +201,7 @@ Default
 
 The option defaults are *cutoff* = pair style cutoff, *nnn* = 12,
 *degrees* = 5 4 6 8 10 12 i.e. :math:`Q_4`, :math:`Q_6`, :math:`Q_8`, :math:`Q_{10}`, and :math:`Q_{12}`,
-*wl* = no, *wl/hat* = no, and *components* off
+*wl* = no, *wl/hat* = no, *components* off, and *chunksize* = 2000
 
 ----------
 

doc/src/compute_property_atom.rst

@@ -67,8 +67,8 @@ Syntax
   .. parsed-literal::
 
            PERI package per-atom properties:
-           vfrac = ???
-           s0 = ???
+           vfrac = volume fraction
+           s0 = max stretch of any bond a particle is part of
 
   .. parsed-literal::
 
@@ -81,11 +81,11 @@ Syntax
   .. parsed-literal::
 
            USER-SPH package per-atom properties:
-           rho = ???
-           drho = ???
-           e = ???
-           de = ???
-           cv = ???
+           rho = density of SPH particles
+           drho = change in density
+           e = energy
+           de = change in thermal energy
+           cv = heat capacity
 
   .. parsed-literal::
 
@@ -108,13 +108,17 @@ Description
 
 Define a computation that simply stores atom attributes for each atom
 in the group.  This is useful so that the values can be used by other
-:doc:`output commands <Howto_output>` that take computes as inputs.  See
-for example, the :doc:`compute reduce <compute_reduce>`, :doc:`fix ave/atom <fix_ave_atom>`, :doc:`fix ave/histo <fix_ave_histo>`, :doc:`fix ave/chunk <fix_ave_chunk>`, and :doc:`atom-style variable <variable>`
-commands.
+:doc:`output commands <Howto_output>` that take computes as inputs.
+See for example, the :doc:`compute reduce <compute_reduce>`, :doc:`fix
+ave/atom <fix_ave_atom>`, :doc:`fix ave/histo <fix_ave_histo>`,
+:doc:`fix ave/chunk <fix_ave_chunk>`, and :doc:`atom-style variable
+<variable>` commands.
 
-The list of possible attributes is the same as that used by the :doc:`dump custom <dump>` command, which describes their meaning, with some
-additional quantities that are only defined for certain :doc:`atom styles <atom_style>`.  Basically, this augmented list gives an
-input script access to any per-atom quantity stored by LAMMPS.
+The list of possible attributes is the same as that used by the
+:doc:`dump custom <dump>` command, which describes their meaning, with
+some additional quantities that are only defined for certain
+:doc:`atom styles <atom_style>`.  Basically, this augmented list gives
+an input script access to any per-atom quantity stored by LAMMPS.
 
 The values are stored in a per-atom vector or array as discussed
 below.  Zeroes are stored for atoms not in the specified group or for
@@ -132,8 +136,9 @@ particles and body particles and store the 4-vector quaternion
 representing the orientation of each particle.  See the :doc:`set <set>`
 command for an explanation of the quaternion vector.
 
-*End1x*\ , *end1y*\ , *end1z*\ , *end2x*\ , *end2y*\ , *end2z*\ , are defined for
-line segment particles and define the end points of each line segment.
+*End1x*\ , *end1y*\ , *end1z*\ , *end2x*\ , *end2y*\ , *end2z*\ , are
+defined for line segment particles and define the end points of each
+line segment.
 
 *Corner1x*\ , *corner1y*\ , *corner1z*\ , *corner2x*\ , *corner2y*\ ,
 *corner2z*\ , *corner3x*\ , *corner3y*\ , *corner3z*\ , are defined for
@@ -144,14 +149,14 @@ number of explicit bonds assigned to an atom.  Note that if the
 :doc:`newton bond <newton>` command is set to *on*\ , which is the
 default, then every bond in the system is assigned to only one of the
 two atoms in the bond.  Thus a bond between atoms I,J may be tallied
-for either atom I or atom J.  If :doc:`newton bond off <newton>` is set,
-it will be tallied with both atom I and atom J.
+for either atom I or atom J.  If :doc:`newton bond off <newton>` is
+set, it will be tallied with both atom I and atom J.
 
 The *i_name* and *d_name* attributes refer to custom integer and
 floating-point properties that have been added to each atom via the
-:doc:`fix property/atom <fix_property_atom>` command.  When that command
-is used specific names are given to each attribute which are what is
-specified as the "name" portion of *i_name* or *d_name*.
+:doc:`fix property/atom <fix_property_atom>` command.  When that
+command is used specific names are given to each attribute which are
+what is specified as the "name" portion of *i_name* or *d_name*.
 
 **Output info:**
 
@@ -160,8 +165,8 @@ on the number of input values.  If a single input is specified, a
 per-atom vector is produced.  If two or more inputs are specified, a
 per-atom array is produced where the number of columns = the number of
 inputs.  The vector or array 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.
+per-atom values from a compute as input.  See the :doc:`Howto output
+<Howto_output>` doc page for an overview of LAMMPS output options.
 
 The vector or array values will be in whatever :doc:`units <units>` the
 corresponding attribute is in, e.g. velocity units for vx, charge
@@ -178,7 +183,8 @@ Restrictions
 Related commands
 """"""""""""""""
 
-:doc:`dump custom <dump>`, :doc:`compute reduce <compute_reduce>`, :doc:`fix ave/atom <fix_ave_atom>`, :doc:`fix ave/chunk <fix_ave_chunk>`,
-:doc:`fix property/atom <fix_property_atom>`
+:doc:`dump custom <dump>`, :doc:`compute reduce <compute_reduce>`,
+:doc::doc:`fix ave/atom <fix_ave_atom>`, :doc:`fix ave/chunk
+:doc:<fix_ave_chunk>`, `fix property/atom <fix_property_atom>`
 
 **Default:** none

doc/src/compute_sph_e_atom.rst

@@ -1,6 +1,6 @@
-.. index:: compute meso/e/atom
+.. index:: compute sph/e/atom
 
-compute meso/e/atom command
+compute sph/e/atom command
 ===========================
 
 Syntax
@@ -8,17 +8,17 @@ Syntax
 
 .. parsed-literal::
 
-   compute ID group-ID meso/e/atom
+   compute ID group-ID sph/e/atom
 
 * ID, group-ID are documented in :doc:`compute <compute>` command
-* meso/e/atom = style name of this compute command
+* sph/e/atom = style name of this compute command
 
 Examples
 """"""""
 
 .. code-block:: LAMMPS
 
-   compute 1 all meso/e/atom
+   compute 1 all sph/e/atom
 
 Description
 """""""""""
@@ -27,8 +27,8 @@ Define a computation that calculates the per-atom internal energy
 for each atom in a group.
 
 The internal energy is the energy associated with the internal degrees
-of freedom of a mesoscopic particles, e.g. a Smooth-Particle
-Hydrodynamics particle.
+of freedom of an SPH particle, i.e. a Smooth-Particle Hydrodynamics
+particle.
 
 See `this PDF guide <USER/sph/SPH_LAMMPS_userguide.pdf>`_ to using SPH in
 LAMMPS.

doc/src/compute_sph_rho_atom.rst

@@ -1,6 +1,6 @@
-.. index:: compute meso/rho/atom
+.. index:: compute sph/rho/atom
 
-compute meso/rho/atom command
+compute sph/rho/atom command
 =============================
 
 Syntax
@@ -8,32 +8,31 @@ Syntax
 
 .. parsed-literal::
 
-   compute ID group-ID meso/rho/atom
+   compute ID group-ID sph/rho/atom
 
 * ID, group-ID are documented in :doc:`compute <compute>` command
-* meso/rho/atom = style name of this compute command
+* sph/rho/atom = style name of this compute command
 
 Examples
 """"""""
 
 .. code-block:: LAMMPS
 
-   compute 1 all meso/rho/atom
+   compute 1 all sph/rho/atom
 
 Description
 """""""""""
 
-Define a computation that calculates the per-atom mesoscopic density
-for each atom in a group.
+Define a computation that calculates the per-atom SPH density for each
+atom in a group, i.e. a Smooth-Particle Hydrodynamics density.
 
-The mesoscopic density is the mass density of a mesoscopic particle,
-calculated by kernel function interpolation using "pair style
-sph/rhosum".
+The SPH density is the mass density of an SPH particle, calculated by
+kernel function interpolation using "pair style sph/rhosum".
 
 See `this PDF guide <USER/sph/SPH_LAMMPS_userguide.pdf>`_ to using SPH in
 LAMMPS.
 
-The value of the mesoscopic density will be 0.0 for atoms not in the
+The value of the SPH density will be 0.0 for atoms not in the
 specified compute group.
 
 **Output info:**

doc/src/compute_sph_t_atom.rst

@@ -1,6 +1,6 @@
-.. index:: compute meso/t/atom
+.. index:: compute sph/t/atom
 
-compute meso/t/atom command
+compute sph/t/atom command
 ===========================
 
 Syntax
@@ -8,17 +8,17 @@ Syntax
 
 .. parsed-literal::
 
-   compute ID group-ID meso/t/atom
+   compute ID group-ID sph/t/atom
 
 * ID, group-ID are documented in :doc:`compute <compute>` command
-* meso/t/atom = style name of this compute command
+* sph/t/atom = style name of this compute command
 
 Examples
 """"""""
 
 .. code-block:: LAMMPS
 
-   compute 1 all meso/t/atom
+   compute 1 all sph/t/atom
 
 Description
 """""""""""
@@ -27,8 +27,8 @@ Define a computation that calculates the per-atom internal temperature
 for each atom in a group.
 
 The internal temperature is the ratio of internal energy over the heat
-capacity associated with the internal degrees of freedom of a mesoscopic
-particles, e.g. a Smooth-Particle Hydrodynamics particle.
+capacity associated with the internal degrees of freedom of an SPH
+particles, i.e. a Smooth-Particle Hydrodynamics particle.
 
 .. math::
 

doc/src/compute_stress_atom.rst

@@ -2,6 +2,7 @@
 
 compute stress/atom command
 ===========================
+
 compute centroid/stress/atom command
 ====================================
 
@@ -223,15 +224,14 @@ The per-atom array values will be in pressure\*volume
 
 Restrictions
 """"""""""""
-Currently, compute *centroid/stress/atom* does not support
-pair styles with many-body interactions,
-such as :doc:`Tersoff <pair_tersoff>`,
-and LAMMPS will generate an error in such cases.
-In principal, equivalent formulation
-to that of angle, dihedral and improper contributions
-in the virial :math:`W_{ab}` formula
-can also be applied to the many-body pair styles,
-and is planned in the future.
+
+Currently (Spring 2020), compute *centroid/stress/atom* does not support
+pair styles with many-body interactions, such as :doc:`Tersoff
+<pair_tersoff>`, or pair styles with long-range Coulomb interactions.
+LAMMPS will generate an error in such cases.  In principal, equivalent
+formulation to that of angle, dihedral and improper contributions in the
+virial :math:`W_{ab}` formula can also be applied to the many-body pair
+styles, and is planned in the future.
 
 Related commands
 """"""""""""""""

doc/src/compute_viscosity_cos.rst

@@ -0,0 +1,156 @@
+.. index:: compute viscosity/cos
+
+compute viscosity/cos command
+=============================
+
+Syntax
+""""""
+
+
+.. parsed-literal::
+
+   compute ID group-ID viscosity/cos
+
+* ID, group-ID are documented in :doc:`compute <compute>` command
+* viscosity/cos = style name of this compute command
+
+
+Examples
+""""""""
+
+
+.. code-block:: LAMMPS
+
+   compute  cos all viscosity/cos
+   variable V equal c_cos[7]
+   variable A equal 0.02E-5
+   variable density equal density
+   variable lz equal lz
+   variable reciprocalViscosity equal v_V/${A}/v_density*39.4784/v_lz/v_lz*100
+
+Description
+"""""""""""
+
+Define a computation that calculates the velocity amplitude of a group of atoms
+with an cosine-shaped velocity profile and the temperature of them
+after subtracting out the velocity profile before computing the kinetic energy.
+A compute of this style can be used by any command that computes a temperature,
+e.g. :doc:`thermo_modify <thermo_modify>`, :doc:`fix npt <fix_nh>`, etc.
+
+This command together with :doc:`fix_accelerate/cos<fix_accelerate_cos>`
+enables viscosity calculation with periodic perturbation method,
+as described by :ref:`Hess<Hess1>`.
+An acceleration along the x-direction is applied to the simulation system
+by using :doc:`fix_accelerate/cos<fix_accelerate_cos>` command.
+The acceleration is a periodic function along the z-direction:
+
+.. math::
+
+   a_{x}(z) = A \cos \left(\frac{2 \pi z}{l_{z}}\right)
+
+where :math:`A` is the acceleration amplitude, :math:`l_z` is the z-length
+of the simulation box. At steady state, the acceleration generates
+a velocity profile:
+
+.. math::
+
+   v_{x}(z) = V \cos \left(\frac{2 \pi z}{l_{z}}\right)
+
+The generated velocity amplitude :math:`V` is related to the
+shear viscosity :math:`\eta` by:
+
+.. math::
+
+   V = \frac{A \rho}{\eta}\left(\frac{l_{z}}{2 \pi}\right)^{2}
+
+
+and it can be obtained from ensemble average of the velocity profile:
+
+.. math::
+
+   V = \frac{\sum_i 2 m_{i} v_{i, x} \cos \left(\frac{2 \pi z_i}{l_{z}}\right)}{\sum_i m_{i}}
+
+
+where :math:`m_i`, :math:`v_{i,x}` and :math:`z_i` are the mass,
+x-component velocity and z coordinate of a particle.
+
+After the cosine-shaped collective velocity in :math:`x` direction
+has been subtracted for each atom, the temperature is calculated by the formula
+KE = dim/2 N k T, where KE = total kinetic energy of the group of
+atoms (sum of 1/2 m v\^2), dim = 2 or 3 = dimensionality of the
+simulation, N = number of atoms in the group, k = Boltzmann constant,
+and T = temperature.
+
+A kinetic energy tensor, stored as a 6-element vector, is also
+calculated by this compute for use in the computation of a pressure
+tensor. The formula for the components of the tensor is the same as
+the above formula, except that v\^2 is replaced by vx\*vy for the xy
+component, etc. The 6 components of the vector are ordered xx, yy,
+zz, xy, xz, yz.
+
+The number of atoms contributing to the temperature is assumed to be
+constant for the duration of the run; use the *dynamic* option of the
+:doc:`compute_modify <compute_modify>` command if this is not the case.
+However, in order to get meaningful result, the group ID of this compute should be all.
+
+The removal of the cosine-shaped velocity component by this command is
+essentially computing the temperature after a "bias" has been removed
+from the velocity of the atoms.  If this compute is used with a fix
+command that performs thermostatting then this bias will be subtracted
+from each atom, thermostatting of the remaining thermal velocity will
+be performed, and the bias will be added back in.  Thermostatting
+fixes that work in this way include :doc:`fix nvt <fix_nh>`, :doc:`fix temp/rescale <fix_temp_rescale>`, :doc:`fix temp/berendsen <fix_temp_berendsen>`, and :doc:`fix langevin <fix_langevin>`.
+
+This compute subtracts out degrees-of-freedom due to fixes that
+constrain molecular motion, such as :doc:`fix shake <fix_shake>` and
+:doc:`fix rigid <fix_rigid>`.  This means the temperature of groups of
+atoms that include these constraints will be computed correctly.  If
+needed, the subtracted degrees-of-freedom can be altered using the
+*extra* option of the :doc:`compute_modify <compute_modify>` command.
+
+See the :doc:`Howto thermostat <Howto_thermostat>` doc page for a
+discussion of different ways to compute temperature and perform
+thermostatting.
+
+----------
+
+**Output info:**
+
+This compute calculates a global scalar (the temperature) and a global
+vector of length 7, which can be accessed by indices 1-7.
+The first 6 elements of the vector are the KE tensor,
+and the 7-th is the cosine-shaped velocity amplitude :math:`V`,
+which can be used to calculate the reciprocal viscosity, as shown in the example.
+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.
+
+The scalar value calculated by this compute is "intensive".  The
+first 6 elements of vector values are "extensive",
+and the 7-th element of vector values is "intensive".
+
+The scalar value will be in temperature :doc:`units <units>`.  The
+first 6 elements of vector values will be in energy :doc:`units <units>`.
+The 7-th element of vector value will be in velocity :doc:`units <units>`.
+
+Restrictions
+""""""""""""
+
+This command is only available when LAMMPS was built with the USER-MISC package.
+Since this compute depends on :doc:`fix accelerate/cos <fix_accelerate_cos>` which can
+only work for 3d systems, it cannot be used for 2d systems.
+
+Related commands
+""""""""""""""""
+
+:doc:`fix accelerate/cos <fix_accelerate_cos>`
+
+Default
+"""""""
+ none
+
+----------
+
+.. _Hess1:
+
+**(Hess)** Hess, B. The Journal of Chemical Physics 2002, 116 (1), 209-217.

doc/src/dump_modify.rst

@@ -552,9 +552,9 @@ when writing to XTC files.  By default they are initialized for
 whatever :doc:`units <units>` style is being used, to write out
 coordinates in nanometers and time in picoseconds.  I.e. for *real*
 units, LAMMPS defines *sfactor* = 0.1 and *tfactor* = 0.001, since the
-Angstroms and fmsec used by *real* units are 0.1 nm and 0.001 psec
+Angstroms and fs used by *real* units are 0.1 nm and 0.001 ps
 respectively.  If you are using a units system with distance and time
-units far from nm and psec, you may wish to write XTC files with
+units far from nm and ps, you may wish to write XTC files with
 different units, since the compression algorithm used in XTC files is
 most effective when the typical magnitude of position data is between
 10.0 and 0.1.

doc/src/fix.rst

@@ -165,6 +165,7 @@ The individual style names on the :doc:`Commands fix <Commands_fix>` doc
 page are followed by one or more of (g,i,k,o,t) to indicate which
 accelerated styles exist.
 
+* :doc:`accelerate/cos <fix_accelerate_cos>` - apply cosine-shaped acceleration to atoms
 * :doc:`adapt <fix_adapt>` - change a simulation parameter over time
 * :doc:`adapt/fep <fix_adapt_fep>` - enhanced version of fix adapt
 * :doc:`addforce <fix_addforce>` - add a force to each atom
@@ -237,9 +238,7 @@ accelerated styles exist.
 * :doc:`lb/viscous <fix_lb_viscous>` -
 * :doc:`lineforce <fix_lineforce>` - constrain atoms to move in a line
 * :doc:`manifoldforce <fix_manifoldforce>` - restrain atoms to a manifold during minimization
-* :doc:`meso <fix_meso>` - time integration for SPH/DPDE particles
 * :doc:`meso/move <fix_meso_move>` - move mesoscopic SPH/SDPD particles in a prescribed fashion
-* :doc:`meso/stationary <fix_meso_stationary>` -
 * :doc:`momentum <fix_momentum>` - zero the linear and/or angular momentum of a group 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
@@ -344,6 +343,8 @@ accelerated styles exist.
 * :doc:`smd/move_tri_surf <fix_smd_move_triangulated_surface>` -
 * :doc:`smd/setvel <fix_smd_setvel>` -
 * :doc:`smd/wall_surface <fix_smd_wall_surface>` -
+* :doc:`sph <fix_sph>` - time integration for SPH/DPDE particles
+* :doc:`sph/stationary <fix_sph_stationary>` -
 * :doc:`spring <fix_spring>` - apply harmonic spring force to group of atoms
 * :doc:`spring/chunk <fix_spring_chunk>` - apply harmonic spring force to each chunk of atoms
 * :doc:`spring/rg <fix_spring_rg>` - spring on radius of gyration of group of atoms

doc/src/fix_accelerate_cos.rst

@@ -0,0 +1,104 @@
+.. index:: fix accelerate/cos
+
+fix accelerate/cos command
+==========================
+
+Syntax
+""""""
+
+
+.. parsed-literal::
+
+   fix ID group-ID accelerate value
+
+* ID, group-ID are documented in :doc:`fix <fix>` command
+* accelerate/cos = style name of this fix command
+* value = amplitude of acceleration (in unit of force/mass)
+
+
+Examples
+""""""""
+
+
+.. code-block:: LAMMPS
+
+   fix 1 all accelerate/cos 0.02e-5
+
+Description
+"""""""""""
+
+Give each atom a acceleration in x-direction based on its z coordinate.
+The acceleration is a periodic function along the z-direction:
+
+.. math::
+
+   a_{x}(z) = A \cos \left(\frac{2 \pi z}{l_{z}}\right)
+
+where :math:`A` is the acceleration amplitude, :math:`l_z` is the z-length
+of the simulation box.
+At steady state, the acceleration generates a velocity profile:
+
+.. math::
+
+   v_{x}(z) = V \cos \left(\frac{2 \pi z}{l_{z}}\right)
+
+The generated velocity amplitude :math:`V` is related to the
+shear viscosity :math:`\eta` by:
+
+.. math::
+
+   V = \frac{A \rho}{\eta}\left(\frac{l_{z}}{2 \pi}\right)^{2}
+
+
+and it can be obtained from ensemble average of the velocity profile:
+
+.. math::
+
+   V = \frac{\sum_i 2 m_{i} v_{i, x} \cos \left(\frac{2 \pi z_i}{l_{z}}\right)}{\sum_i m_{i}}
+
+where :math:`m_i`, :math:`v_{i,x}` and :math:`z_i` are the mass,
+x-component velocity and z coordinate of a particle.
+
+The velocity amplitude :math:`V` can be calculated with :doc:`compute viscosity/cos <compute_viscosity_cos>`,
+which enables viscosity calculation with periodic perturbation method,
+as described by :ref:`Hess<Hess2>`.
+Because the applied acceleration drives the system away from equilibration,
+the calculated shear viscosity is lower than the intrinsic viscosity
+due to the shear-thinning effect.
+Extrapolation to zero acceleration should generally be performed to
+predict the zero-shear viscosity.
+As the shear stress decreases, the signal-noise ratio decreases rapidly,
+the simulation time must be extended accordingly to get converged result.
+
+In order to get meaningful result, the group ID of this fix should be all.
+
+----------
+
+**Restart, fix_modify, output, run start/stop, minimize info:**
+
+No information about this fix is written to binary restart files.
+None of the fix_modify options are relevant to this fix.
+No global or per-atom quantities are stored by this fix for access by various output commands.
+No parameter of this fix can be used with the start/stop keywords of the run command.
+This fix is not invoked during energy minimization.
+
+Restrictions
+""""""""""""
+
+This command is only available when LAMMPS was built with the USER-MISC package.
+Since this fix depends on the z-coordinate of atoms, it cannot be used in 2d simulations.
+
+Related commands
+""""""""""""""""
+
+:doc:`compute viscosity/cos <compute_viscosity_cos>`
+
+Default
+"""""""
+ none
+
+----------
+
+.. _Hess2:
+
+**(Hess)** Hess, B. The Journal of Chemical Physics 2002, 116 (1), 209-217.

doc/src/fix_ave_correlate_long.rst

@@ -26,7 +26,7 @@ Syntax
        v_name = global value calculated by an equal-style variable with name
 
 * zero or more keyword/arg pairs may be appended
-* keyword = *type* or *start* or *file* or *overwrite* or *title1* or *title2* or *ncorr* or *p* or *m*
+* keyword = *type* or *start* or *file* or *overwrite* or *title1* or *title2* or *ncorr* or *nlen* or *ncount*
 
   .. parsed-literal::
 

doc/src/fix_bond_react.rst

@@ -158,7 +158,9 @@ The following comments pertain to each *react* argument (in other
 words, can be customized for each reaction, or reaction step):
 
 A check for possible new reaction sites is performed every *Nevery*
-timesteps.
+timesteps. *Nevery* can be specified with an equal-style
+:doc:`variable <variable>`, whose value is rounded up to the nearest
+integer.
 
 Three physical conditions must be met for a reaction to occur. First,
 a bonding atom pair must be identified within the reaction distance
@@ -171,19 +173,29 @@ modified to match the post-reaction template.
 A bonding atom pair will be identified if several conditions are met.
 First, a pair of atoms I,J within the specified react-group-ID of type
 itype and jtype must be separated by a distance between *Rmin* and
-*Rmax*\ . It is possible that multiple bonding atom pairs are
-identified: if the bonding atoms in the pre-reacted template are  1-2
-neighbors, i.e. directly bonded, the farthest bonding atom partner is
-set as its bonding partner; otherwise, the closest potential partner
-is chosen. Then, if both an atom I and atom J have each other as their
-bonding partners, these two atoms are identified as the bonding atom
-pair of the reaction site. Once this unique bonding atom pair is
-identified for each reaction, there could two or more reactions that
-involve a given atom on the same timestep. If this is the case, only
-one such reaction is permitted to occur. This reaction is chosen
-randomly from all potential reactions. This capability allows e.g. for
-different reaction pathways to proceed from identical reaction sites
-with user-specified probabilities.
+*Rmax*\ . *Rmin* and *Rmax* can be specified with equal-style
+:doc:`variables <variable>`. For example, these reaction cutoffs can
+be a function of the reaction conversion using the following commands:
+
+.. code-block:: LAMMPS
+
+   variable rmax equal 0 # initialize variable before bond/react
+   fix myrxn all bond/react react myrxn1 all 1 0 v_rmax mol1 mol2 map_file.txt
+   variable rmax equal 3+f_myrxn[1]/100 # arbitrary function of reaction count
+
+It is possible that multiple bonding atom pairs are identified: if the
+bonding atoms in the pre-reacted template are  1-2 neighbors, i.e.
+directly bonded, the farthest bonding atom partner is set as its
+bonding partner; otherwise, the closest potential partner is chosen.
+Then, if both an atom I and atom J have each other as their bonding
+partners, these two atoms are identified as the bonding atom pair of
+the reaction site. Once this unique bonding atom pair is identified
+for each reaction, there could two or more reactions that involve a
+given atom on the same timestep. If this is the case, only one such
+reaction is permitted to occur. This reaction is chosen randomly from
+all potential reactions. This capability allows e.g. for different
+reaction pathways to proceed from identical reaction sites with
+user-specified probabilities.
 
 The pre-reacted molecule template is specified by a molecule command.
 This molecule template file contains a sample reaction site and its
@@ -288,7 +300,8 @@ either 'none' or 'charges.' Further details are provided in the
 discussion of the 'update_edges' keyword. The fifth optional section
 begins with the keyword 'Constraints' and lists additional criteria
 that must be satisfied in order for the reaction to occur. Currently,
-there are four types of constraints available, as discussed below.
+there are four types of constraints available, as discussed below:
+'distance', 'angle', 'dihedral', and 'arrhenius'.
 
 A sample map file is given below:
 
@@ -341,8 +354,9 @@ has syntax as follows:
    distance *ID1* *ID2* *rmin* *rmax*
 
 where 'distance' is the required keyword, *ID1* and *ID2* are
-pre-reaction atom IDs, and these two atoms must be separated by a
-distance between *rmin* and *rmax* for the reaction to occur.
+pre-reaction atom IDs (or molecule-fragment IDs, see below), and these
+two atoms must be separated by a distance between *rmin* and *rmax*
+for the reaction to occur.
 
 The constraint of type 'angle' has the following syntax:
 
@@ -351,11 +365,11 @@ The constraint of type 'angle' has the following syntax:
    angle *ID1* *ID2* *ID3* *amin* *amax*
 
 where 'angle' is the required keyword, *ID1*\ , *ID2* and *ID3* are
-pre-reaction atom IDs, and these three atoms must form an angle
-between *amin* and *amax* for the reaction to occur (where *ID2* is
-the central atom). Angles must be specified in degrees. This
-constraint can be used to enforce a certain orientation between
-reacting molecules.
+pre-reaction atom IDs (or molecule-fragment IDs, see below), and these
+three atoms must form an angle between *amin* and *amax* for the
+reaction to occur (where *ID2* is the central atom). Angles must be
+specified in degrees. This constraint can be used to enforce a certain
+orientation between reacting molecules.
 
 The constraint of type 'dihedral' has the following syntax:
 
@@ -364,15 +378,23 @@ The constraint of type 'dihedral' has the following syntax:
    dihedral *ID1* *ID2* *ID3* *ID4* *amin* *amax* *amin2* *amax2*
 
 where 'dihedral' is the required keyword, and *ID1*\ , *ID2*\ , *ID3*
-and *ID4* are pre-reaction atom IDs. Dihedral angles are calculated in
-the interval (-180,180]. Refer to the :doc:`dihedral style <dihedral_style>`
-documentation for further details on convention. If *amin* is less
-than *amax*, these four atoms must form a dihedral angle greater than
-*amin* **and** less than *amax* for the reaction to occur. If *amin*
-is greater than *amax*, these four atoms must form a dihedral angle
-greater than *amin* **or** less than *amax* for the reaction to occur.
-Angles must be specified in degrees. Optionally, a second range of
-permissible angles *amin2*-*amax2* can be specified.
+and *ID4* are pre-reaction atom IDs (or molecule-fragment IDs, see
+below). Dihedral angles are calculated in the interval (-180,180].
+Refer to the :doc:`dihedral style <dihedral_style>` documentation for
+further details on convention. If *amin* is less than *amax*, these
+four atoms must form a dihedral angle greater than *amin* **and** less
+than *amax* for the reaction to occur. If *amin* is greater than
+*amax*, these four atoms must form a dihedral angle greater than
+*amin* **or** less than *amax* for the reaction to occur. Angles must
+be specified in degrees. Optionally, a second range of permissible
+angles *amin2*-*amax2* can be specified.
+
+For the 'distance', 'angle', and 'dihedral' constraints (explained
+above), atom IDs can be replaced by pre-reaction molecule-fragment
+IDs. The molecule-fragment ID must begin with a letter. The location
+of the ID is the geometric center of all atom positions in the
+fragment. The molecule fragment must have been defined in the
+:doc:`molecule <molecule>` command for the pre-reaction template.
 
 The constraint of type 'arrhenius' imposes an additional reaction
 probability according to the temperature-dependent Arrhenius equation:
@@ -419,7 +441,8 @@ it occurs:
 
 The *prob* keyword can affect whether or not an eligible reaction
 actually occurs. The fraction setting must be a value between 0.0 and
-1.0. A uniform random number between 0.0 and 1.0 is generated and the
+1.0, and can be specified with an equal-style :doc:`variable <variable>`.
+A uniform random number between 0.0 and 1.0 is generated and the
 eligible reaction only occurs if the random number is less than the
 fraction. Up to N reactions are permitted to occur, as optionally
 specified by the *max_rxn* keyword.
@@ -489,10 +512,11 @@ local command.
 
 **Restart, fix_modify, output, run start/stop, minimize info:**
 
-Cumulative reaction counts for each reaction are written to :doc:`binary restart files <restart>`. These values are associated with the
-reaction name (react-ID). Additionally, internally-created per-atom
-properties are stored to allow for smooth restarts. None of the
-:doc:`fix_modify <fix_modify>` options are relevant to this fix.
+Cumulative reaction counts for each reaction are written to :doc:`binary restart files <restart>`.
+These values are associated with the reaction name (react-ID).
+Additionally, internally-created per-atom properties are stored to
+allow for smooth restarts. None of the :doc:`fix_modify <fix_modify>`
+options are relevant to this fix.
 
 This fix computes one statistic for each *react* argument that it
 stores in a global vector, of length 'number of react arguments', that

doc/src/fix_deform.rst

@@ -154,8 +154,8 @@ specified in units of distance/time.  This is effectively a "constant
 engineering strain rate", where rate = V/L0 and L0 is the initial box
 length.  The distance can be in lattice or box distance units.  See
 the discussion of the units keyword below.  For example, if the
-initial box length is 100 Angstroms, and V is 10 Angstroms/psec, then
-after 10 psec, the box length will have doubled.  After 20 psec, it
+initial box length is 100 Angstroms, and V is 10 Angstroms/ps, then
+after 10 ps, the box length will have doubled.  After 20 ps, it
 will have tripled.
 
 The *erate* style changes a dimension of the box at a "constant
@@ -174,7 +174,7 @@ function of time will change as
 where dt is the elapsed time (in time units).  Thus if *erate* R is
 specified as 0.1 and time units are picoseconds, this means the box
 length will increase by 10% of its original length every picosecond.
-I.e. strain after 1 psec = 0.1, strain after 2 psec = 0.2, etc.  R =
+I.e. strain after 1 ps = 0.1, strain after 2 ps = 0.2, etc.  R =
 -0.01 means the box length will shrink by 1% of its original length
 every picosecond.  Note that for an "engineering" rate the change is
 based on the original box length, so running with R = 1 for 10
@@ -201,7 +201,7 @@ The box length L as a function of time will change as
 where dt is the elapsed time (in time units).  Thus if *trate* R is
 specified as ln(1.1) and time units are picoseconds, this means the
 box length will increase by 10% of its current (not original) length
-every picosecond.  I.e. strain after 1 psec = 0.1, strain after 2 psec
+every picosecond.  I.e. strain after 1 ps = 0.1, strain after 2 ps
 = 0.21, etc.  R = ln(2) or ln(3) means the box length will double or
 triple every picosecond.  R = ln(0.99) means the box length will
 shrink by 1% of its current length every picosecond.  Note that for a
@@ -317,8 +317,8 @@ specified in units of distance/time.  This is effectively an
 initial box length perpendicular to the direction of shear.  The
 distance can be in lattice or box distance units.  See the discussion
 of the units keyword below.  For example, if the initial tilt factor
-is 5 Angstroms, and the V is 10 Angstroms/psec, then after 1 psec, the
-tilt factor will be 15 Angstroms.  After 2 psec, it will be 25
+is 5 Angstroms, and the V is 10 Angstroms/ps, then after 1 ps, the
+tilt factor will be 15 Angstroms.  After 2 ps, it will be 25
 Angstroms.
 
 The *erate* style changes a tilt factor at a "constant engineering
@@ -342,9 +342,9 @@ box perpendicular to the shear direction (e.g. y box length for xy
 deformation), and dt is the elapsed time (in time units).  Thus if
 *erate* R is specified as 0.1 and time units are picoseconds, this
 means the shear strain will increase by 0.1 every picosecond.  I.e. if
-the xy shear strain was initially 0.0, then strain after 1 psec = 0.1,
-strain after 2 psec = 0.2, etc.  Thus the tilt factor would be 0.0 at
-time 0, 0.1\*ybox at 1 psec, 0.2\*ybox at 2 psec, etc, where ybox is the
+the xy shear strain was initially 0.0, then strain after 1 ps = 0.1,
+strain after 2 ps = 0.2, etc.  Thus the tilt factor would be 0.0 at
+time 0, 0.1\*ybox at 1 ps, 0.2\*ybox at 2 ps, etc, where ybox is the
 original y box length.  R = 1 or 2 means the tilt factor will increase
 by 1 or 2 every picosecond.  R = -0.01 means a decrease in shear
 strain by 0.01 every picosecond.
@@ -373,7 +373,7 @@ where T0 is the initial tilt factor and dt is the elapsed time (in
 time units).  Thus if *trate* R is specified as ln(1.1) and time units
 are picoseconds, this means the shear strain or tilt factor will
 increase by 10% every picosecond.  I.e. if the xy shear strain was
-initially 0.1, then strain after 1 psec = 0.11, strain after 2 psec =
+initially 0.1, then strain after 1 ps = 0.11, strain after 2 ps =
 0.121, etc.  R = ln(2) or ln(3) means the tilt factor will double or
 triple every picosecond.  R = ln(0.99) means the tilt factor will
 shrink by 1% every picosecond.  Note that the change is continuous, so

doc/src/fix_halt.rst

@@ -160,7 +160,7 @@ the :doc:`run <run>` command.
 
 Restrictions
 """"""""""""
-The *diskfree* attribute is currently only supported on Linux and MacOS.
+The *diskfree* attribute is currently only supported on Linux, MacOSX, and BSD.
 
 Related commands
 """"""""""""""""

doc/src/fix_heat.rst

@@ -47,16 +47,22 @@ and the specified geometric :doc:`region <region>` in order to have
 energy added or subtracted to it.  If not specified, then the atoms in
 the group are affected wherever they may move to.
 
-Heat addition/subtraction is performed every N timesteps.  The *eflux*
-parameter can be specified as a numeric constant or as a variable (see
-below).  If it is a numeric constant or equal-style variable which
-evaluates to a scalar value, then the *eflux* determines the change in
-aggregate energy of the entire group of atoms per unit time, e.g. in
-eV/psec for :doc:`metal units <units>`.  In this case it is an
-"extensive" quantity, meaning its magnitude should be scaled with the
-number of atoms in the group.  Note that since *eflux* has per-time
-units (i.e. it is a flux), this means that a larger value of N will
-add/subtract a larger amount of energy each time the fix is invoked.
+Heat addition/subtraction is performed every N timesteps.
+
+The *eflux* parameter can be specified as a numeric constant or as an
+equal- or atom-style :doc:`variable <variable>`.  If the value is a
+variable, it should be specified as v_name, where *name* is the variable
+name.  In this case, the variable will be evaluated each timestep, and
+its current value(s) used to determine the flux.
+
+If *eflux* is a numeric constant or equal-style variable which evaluates
+to a scalar value, then *eflux* determines the change in aggregate energy
+of the entire group of atoms per unit time, e.g. in eV/ps for
+:doc:`metal units <units>`.  In this case it is an "extensive" quantity,
+meaning its magnitude should be scaled with the number of atoms in the
+group.  Note that since *eflux* also has per-time units (i.e. it is a
+flux), this means that a larger value of N will add/subtract a larger
+amount of energy each time the fix is invoked.
 
 .. note::
 
@@ -71,12 +77,6 @@ the energy flux for a single atom, again in units of energy per unit
 time.  In this case, each value is an "intensive" quantity, which need
 not be scaled with the number of atoms in the group.
 
-As mentioned above, the *eflux* parameter can be specified as an
-equal-style or atom_style :doc:`variable <variable>`.  If the value is a
-variable, it should be specified as v_name, where name is the variable
-name.  In this case, the variable will be evaluated each timestep, and
-its value(s) used to determine the flux.
-
 Equal-style variables can specify formulas with various mathematical
 functions, and include :doc:`thermo_style <thermo_style>` command
 keywords for the simulation box parameters and timestep and elapsed

doc/src/fix_langevin_drude.rst

@@ -188,7 +188,7 @@ particles.
 *damp_com* is the characteristic time for reaching thermal equilibrium
 of the centers of mass.  For example, a value of 100.0 means to relax
 the temperature of the centers of mass in a timespan of (roughly) 100
-time units (tau or fmsec or psec - see the :doc:`units <units>`
+time units (tau or fs or ps - see the :doc:`units <units>`
 command).  *damp_drude* is the characteristic time for reaching
 thermal equilibrium of the dipoles. It is typically a few timesteps.
 

doc/src/fix_meso_move.rst

@@ -60,17 +60,19 @@ internal energy and extrapolated velocity are also updated.
 
 .. note::
 
-   The particles affected by this fix should not be time integrated
-   by other fixes (e.g. :doc:`fix meso <fix_meso>`, :doc:`fix meso/stationary <fix_meso_stationary>`), since that will change their
+   The particles affected by this fix should not be time integrated by
+   other fixes (e.g. :doc:`fix sph <fix_sph>`, :doc:`fix
+   sph/stationary <fix_sph_stationary>`), since that will change their
    positions and velocities twice.
 
 .. note::
 
    As particles move due to this fix, they will pass through periodic
    boundaries and be remapped to the other side of the simulation box,
-   just as they would during normal time integration (e.g. via the :doc:`fix meso <fix_meso>` command).  It is up to you to decide whether periodic
-   boundaries are appropriate with the kind of particle motion you are
-   prescribing with this fix.
+   just as they would during normal time integration (e.g. via the
+   :doc:`fix sph <fix_sph>` command).  It is up to you to decide
+   whether periodic boundaries are appropriate with the kind of
+   particle motion you are prescribing with this fix.
 
 .. note::
 
@@ -100,7 +102,7 @@ specified, *V* is the specified velocity vector with components
 specified.  This style also sets the velocity of each particle to V =
 (Vx,Vy,Vz).  If any of the velocity components is specified as NULL,
 then the position and velocity of that component is time integrated
-the same as the :doc:`fix meso <fix_meso>` command would perform, using
+the same as the :doc:`fix sph <fix_sph>` command would perform, using
 the corresponding force component on the particle.
 
 Note that the *linear* style is identical to using the *variable*
@@ -128,7 +130,7 @@ elapsed since the fix was specified.  This style also sets the
 velocity of each particle to the time derivative of this expression.
 If any of the amplitude components is specified as NULL, then the
 position and velocity of that component is time integrated the same as
-the :doc:`fix meso <fix_meso>` command would perform, using the
+the :doc:`fix sph <fix_sph>` command would perform, using the
 corresponding force component on the particle.
 
 Note that the *wiggle* style is identical to using the *variable*
@@ -180,21 +182,21 @@ particle.
 Any of the 6 variables can be specified as NULL.  If both the
 displacement and velocity variables for a particular x,y,z component
 are specified as NULL, then the position and velocity of that
-component is time integrated the same as the :doc:`fix meso <fix_meso>`
+component is time integrated the same as the :doc:`fix sph <fix_sph>`
 command would perform, using the corresponding force component on the
-particle.  If only the velocity variable for a component is specified as
-NULL, then the displacement variable will be used to set the position
-of the particle, and its velocity component will not be changed. If only
-the displacement variable for a component is specified as NULL, then
-the velocity variable will be used to set the velocity of the particle,
-and the position of the particle will be time integrated using that
-velocity.
+particle.  If only the velocity variable for a component is specified
+as NULL, then the displacement variable will be used to set the
+position of the particle, and its velocity component will not be
+changed. If only the displacement variable for a component is
+specified as NULL, then the velocity variable will be used to set the
+velocity of the particle, and the position of the particle will be
+time integrated using that velocity.
 
 The *units* keyword determines the meaning of the distance units used
 to define the *linear* velocity and *wiggle* amplitude and *rotate*
 origin.  This setting is ignored for the *variable* style.  A *box*
 value selects standard units as defined by the :doc:`units <units>`
-command, e.g. velocity in Angstroms/fmsec and amplitude and position
+command, e.g. velocity in Angstroms/fs and amplitude and position
 in Angstroms for units = real.  A *lattice* value means the velocity
 units are in lattice spacings per time and the amplitude and position
 are in lattice spacings.  The :doc:`lattice <lattice>` command must have
@@ -236,17 +238,18 @@ Restrictions
 """"""""""""
 
 This fix is part of the USER-SDPD package.  It is only enabled if
-LAMMPS was built with that package. See the :doc:`Build package <Build_package>` doc page for more info.
+LAMMPS was built with that package. See the :doc:`Build package
+<Build_package>` doc page for more info.
 
 This fix requires that atoms store density and internal energy as
-defined by the :doc:`atom_style meso <atom_style>` command.
+defined by the :doc:`atom_style sph <atom_style>` command.
 
 All particles in the group must be mesoscopic SPH/SDPD particles.
 
 Related commands
 """"""""""""""""
 
-:doc:`fix move <fix_move>`, :doc:`fix meso <fix_meso>`,
+:doc:`fix move <fix_move>`, :doc:`fix sph <fix_sph>`,
 :doc:`displace_atoms <displace_atoms>`
 
 Default

doc/src/fix_move.rst

@@ -193,7 +193,7 @@ The *units* keyword determines the meaning of the distance units used
 to define the *linear* velocity and *wiggle* amplitude and *rotate*
 origin.  This setting is ignored for the *variable* style.  A *box*
 value selects standard units as defined by the :doc:`units <units>`
-command, e.g. velocity in Angstroms/fmsec and amplitude and position
+command, e.g. velocity in Angstroms/fs and amplitude and position
 in Angstroms for units = real.  A *lattice* value means the velocity
 units are in lattice spacings per time and the amplitude and position
 are in lattice spacings.  The :doc:`lattice <lattice>` command must have

doc/src/fix_nh.rst

@@ -137,8 +137,8 @@ description below.  The desired temperature at each timestep is a
 ramped value during the run from *Tstart* to *Tstop*\ .  The *Tdamp*
 parameter is specified in time units and determines how rapidly the
 temperature is relaxed.  For example, a value of 10.0 means to relax
-the temperature in a timespan of (roughly) 10 time units (e.g. tau or
-fmsec or psec - see the :doc:`units <units>` command).  The atoms in the
+the temperature in a timespan of (roughly) 10 time units (e.g. :math:`\tau`
+or fs or ps - see the :doc:`units <units>` command).  The atoms in the
 fix group are the only ones whose velocities and positions are updated
 by the velocity/position update portion of the integration.
 
@@ -195,8 +195,8 @@ simulation box must be triclinic, even if its initial tilt factors are
 For all barostat keywords, the *Pdamp* parameter operates like the
 *Tdamp* parameter, determining the time scale on which pressure is
 relaxed.  For example, a value of 10.0 means to relax the pressure in
-a timespan of (roughly) 10 time units (e.g. tau or fmsec or psec - see
-the :doc:`units <units>` command).
+a timespan of (roughly) 10 time units (e.g. :math:`\tau` or fs or ps
+- see the :doc:`units <units>` command).
 
 .. note::
 

doc/src/fix_npt_cauchy.rst

@@ -103,8 +103,8 @@ description below.  The desired temperature at each timestep is a
 ramped value during the run from *Tstart* to *Tstop*\ .  The *Tdamp*
 parameter is specified in time units and determines how rapidly the
 temperature is relaxed.  For example, a value of 10.0 means to relax
-the temperature in a timespan of (roughly) 10 time units (e.g. tau or
-fmsec or psec - see the :doc:`units <units>` command).  The atoms in the
+the temperature in a timespan of (roughly) 10 time units (e.g. :math:`\tau`
+or fs or ps - see the :doc:`units <units>` command).  The atoms in the
 fix group are the only ones whose velocities and positions are updated
 by the velocity/position update portion of the integration.
 
@@ -154,8 +154,8 @@ simulation box must be triclinic, even if its initial tilt factors are
 For all barostat keywords, the *Pdamp* parameter operates like the
 *Tdamp* parameter, determining the time scale on which pressure is
 relaxed.  For example, a value of 10.0 means to relax the pressure in
-a timespan of (roughly) 10 time units (e.g. tau or fmsec or psec - see
-the :doc:`units <units>` command).
+a timespan of (roughly) 10 time units (e.g. :math:`\tau` or fs or ps
+- see the :doc:`units <units>` command).
 
 .. note::
 

doc/src/fix_nve_dotc_langevin.rst

@@ -94,7 +94,7 @@ corresponds to T = 300 K.
 The *damp* parameter is specified in time units and determines how
 rapidly the temperature is relaxed.  For example, a value of 0.03
 means to relax the temperature in a timespan of (roughly) 0.03 time
-units tau (see the :doc:`units <units>` command).
+units :math:`\tau` (see the :doc:`units <units>` command).
 The damp factor can be thought of as inversely related to the
 viscosity of the solvent, i.e. a small relaxation time implies a
 high-viscosity solvent and vice versa.  See the discussion about gamma

doc/src/fix_press_berendsen.rst

@@ -90,7 +90,7 @@ although you have the option to change that dimension via the :doc:`fix deform <
 For all barostat keywords, the *Pdamp* parameter determines the time
 scale on which pressure is relaxed.  For example, a value of 10.0
 means to relax the pressure in a timespan of (roughly) 10 time units
-(tau or fmsec or psec - see the :doc:`units <units>` command).
+(tau or fs or ps - see the :doc:`units <units>` command).
 
 .. note::
 

doc/src/fix_rigid.rst

@@ -429,8 +429,8 @@ that dimension via the :doc:`fix deform <fix_deform>` command.
 For all barostat keywords, the *Pdamp* parameter operates like the
 *Tdamp* parameter, determining the time scale on which pressure is
 relaxed.  For example, a value of 10.0 means to relax the pressure in
-a timespan of (roughly) 10 time units (e.g. tau or fmsec or psec - see
-the :doc:`units <units>` command).
+a timespan of (roughly) 10 time units (e.g. :math:`\tau` or fs or ps
+- see the :doc:`units <units>` command).
 
 Regardless of what atoms are in the fix group (the only atoms which
 are time integrated), a global pressure or stress tensor is computed
@@ -514,7 +514,7 @@ desired temperature at each timestep is a ramped value during the run
 from *Tstart* to *Tstop*\ .  The *Tdamp* parameter is specified in time
 units and determines how rapidly the temperature is relaxed.  For
 example, a value of 100.0 means to relax the temperature in a timespan
-of (roughly) 100 time units (tau or fmsec or psec - see the
+of (roughly) 100 time units (:math:`\tau` or fs or ps - see the
 :doc:`units <units>` command).  The random # *seed* must be a positive
 integer.
 
@@ -539,7 +539,7 @@ timestep is a ramped value during the run from *Tstart* to *Tstop*\ .
 The *Tdamp* parameter is specified in time units and determines how
 rapidly the temperature is relaxed.  For example, a value of 100.0
 means to relax the temperature in a timespan of (roughly) 100 time
-units (tau or fmsec or psec - see the :doc:`units <units>` command).
+units (tau or fs or ps - see the :doc:`units <units>` command).
 
 Nose/Hoover chains are used in conjunction with this thermostat.  The
 *tparam* keyword can optionally be used to change the chain settings

doc/src/fix_rigid_meso.rst

@@ -75,19 +75,21 @@ internal energy and extrapolated velocity are also updated.
 .. note::
 
    You should not update the particles in rigid bodies via other
-   time-integration fixes (e.g. :doc:`fix meso <fix_meso>`,
-   :doc:`fix meso/stationary <fix_meso_stationary>`), or you will have conflicting
-   updates to positions and velocities resulting in unphysical behavior in most
-   cases. When performing a hybrid simulation with some atoms in rigid bodies,
-   and some not, a separate time integration fix like :doc:`fix meso <fix_meso>`
-   should be used for the non-rigid particles.
+   time-integration fixes (e.g. :doc:`fix sph <fix_sph>`, :doc:`fix
+   sph/stationary <fix_sph_stationary>`), or you will have conflicting
+   updates to positions and velocities resulting in unphysical
+   behavior in most cases. When performing a hybrid simulation with
+   some atoms in rigid bodies, and some not, a separate time
+   integration fix like :doc:`fix sph <fix_sph>` should be used for
+   the non-rigid particles.
 
 .. note::
 
-   These fixes are overkill if you simply want to hold a collection
-   of particles stationary or have them move with a constant velocity. To
-   hold particles stationary use :doc:`fix meso/stationary <fix_meso_stationary>` instead. If you would like to
-   move particles with a constant velocity use :doc:`fix meso/move <fix_meso_move>`.
+   These fixes are overkill if you simply want to hold a collection of
+   particles stationary or have them move with a constant velocity. To
+   hold particles stationary use :doc:`fix sph/stationary
+   <fix_sph_stationary>` instead. If you would like to move particles
+   with a constant velocity use :doc:`fix meso/move <fix_meso_move>`.
 
 .. warning::
 
@@ -346,7 +348,7 @@ package.  It is only enabled if LAMMPS was built with both packages. See
 the :doc:`Build package <Build_package>` doc page for more info.
 
 This fix requires that atoms store density and internal energy as
-defined by the :doc:`atom_style meso <atom_style>` command.
+defined by the :doc:`atom_style sph <atom_style>` command.
 
 All particles in the group must be mesoscopic SPH/SDPD particles.
 

doc/src/fix_sph.rst

@@ -1,6 +1,6 @@
-.. index:: fix meso
+.. index:: fix sph
 
-fix meso command
+fix sph command
 ================
 
 Syntax
@@ -8,25 +8,26 @@ Syntax
 
 .. parsed-literal::
 
-   fix ID group-ID meso
+   fix ID group-ID sph
 
 * ID, group-ID are documented in :doc:`fix <fix>` command
-* meso = style name of this fix command
+* sph = style name of this fix command
 
 Examples
 """"""""
 
 .. code-block:: LAMMPS
 
-   fix 1 all meso
+   fix 1 all sph
 
 Description
 """""""""""
 
 Perform time integration to update position, velocity, internal energy
 and local density for atoms in the group each timestep. This fix is
-needed to time-integrate mesoscopic systems where particles carry
-internal variables such as SPH or DPDE.
+needed to time-integrate SPH systems where particles carry internal
+variables such as internal energy.  SPH stands for Smoothed Particle
+Hydrodynamics.
 
 See `this PDF guide <USER/sph/SPH_LAMMPS_userguide.pdf>`_ to using SPH in
 LAMMPS.
@@ -48,6 +49,6 @@ LAMMPS was built with that package.  See the :doc:`Build package <Build_package>
 Related commands
 """"""""""""""""
 
-"fix meso/stationary"
+:doc:`fix sph/stationary <fix_sph_stationary>`
 
 **Default:** none

doc/src/fix_sph_stationary.rst

@@ -1,6 +1,6 @@
-.. index:: fix meso/stationary
+.. index:: fix sph/stationary
 
-fix meso/stationary command
+fix sph/stationary command
 ===========================
 
 Syntax
@@ -8,17 +8,17 @@ Syntax
 
 .. parsed-literal::
 
-   fix ID group-ID meso/stationary
+   fix ID group-ID sph/stationary
 
 * ID, group-ID are documented in :doc:`fix <fix>` command
-* meso = style name of this fix command
+* sph = style name of this fix command
 
 Examples
 """"""""
 
 .. code-block:: LAMMPS
 
-   fix 1 boundary meso/stationary
+   fix 1 boundary sph/stationary
 
 Description
 """""""""""
@@ -27,7 +27,7 @@ Perform time integration to update internal energy and local density,
 but not position or velocity for atoms in the group each timestep.
 This fix is needed for SPH simulations to correctly time-integrate
 fixed boundary particles which constrain a fluid to a given region in
-space.
+space.  SPH stands for Smoothed Particle Hydrodynamics.
 
 See `this PDF guide <USER/sph/SPH_LAMMPS_userguide.pdf>`_ to using SPH in
 LAMMPS.
@@ -49,6 +49,6 @@ LAMMPS was built with that package.  See the :doc:`Build package <Build_package>
 Related commands
 """"""""""""""""
 
-"fix meso"
+:doc:`fix sph <fix_sph>`
 
 **Default:** none

doc/src/fix_temp_berendsen.rst

@@ -45,7 +45,7 @@ The desired temperature at each timestep is a ramped value during the
 run from *Tstart* to *Tstop*\ .  The *Tdamp* parameter is specified in
 time units and determines how rapidly the temperature is relaxed.  For
 example, a value of 100.0 means to relax the temperature in a timespan
-of (roughly) 100 time units (tau or fmsec or psec - see the
+of (roughly) 100 time units (tau or fs or ps - see the
 :doc:`units <units>` command).
 
 *Tstart* can be specified as an equal-style :doc:`variable <variable>`.

doc/src/fix_temp_csvr.rst

@@ -59,7 +59,7 @@ The desired temperature at each timestep is a ramped value during the
 run from *Tstart* to *Tstop*\ .  The *Tdamp* parameter is specified in
 time units and determines how rapidly the temperature is relaxed.  For
 example, a value of 100.0 means to relax the temperature in a timespan
-of (roughly) 100 time units (tau or fmsec or psec - see the
+of (roughly) 100 time units (tau or fs or ps - see the
 :doc:`units <units>` command).
 
 *Tstart* can be specified as an equal-style :doc:`variable <variable>`.

doc/src/fix_ti_spring.rst

@@ -88,7 +88,7 @@ time:
 
   \lambda(\tau) = \tau
 
-where tau is the scaled time variable *t/t_s*. The option *2* performs
+where :math:`\tau` is the scaled time variable *t/t_s*. The option *2* performs
 the lambda switching at a rate defined by the following switching
 function
 

doc/src/fix_wall_body_polyhedron.rst

@@ -15,15 +15,14 @@ Syntax
 * k_n = normal repulsion strength (force/distance units or pressure units - see discussion below)
 * c_n = normal damping coefficient (force/distance units or pressure units - see discussion below)
 * c_t = tangential damping coefficient (force/distance units or pressure units - see discussion below)
-* wallstyle = *xplane* or *yplane* or *zplane* or *zcylinder*
+* wallstyle = *xplane* or *yplane* or *zplane*
 * args = list of arguments for a particular style
 
   .. parsed-literal::
 
-       *xplane* or *yplane* args = lo hi
+       *xplane* or *yplane* or *zplane* args = lo hi
          lo,hi = position of lower and upper plane (distance units), either can be NULL)
-       *zcylinder* args = radius
-         radius = cylinder radius (distance units)
+
 
 * zero or more keyword/value pairs may be appended to args
 * keyword = *wiggle*
@@ -60,8 +59,7 @@ those specified with the :doc:`pair_style body/rounded/polyhedron <pair_body_rou
 The *wallstyle* can be planar or cylindrical.  The 3 planar options
 specify a pair of walls in a dimension.  Wall positions are given by
 *lo* and *hi*\ .  Either of the values can be specified as NULL if a
-single wall is desired.  For a *zcylinder* wallstyle, the cylinder's
-axis is at x = y = 0.0, and the radius of the cylinder is specified.
+single wall is desired.
 
 Optionally, the wall can be moving, if the *wiggle* keyword is appended.
 
@@ -71,8 +69,7 @@ particles.  The arguments to the *wiggle* keyword specify a dimension
 for the motion, as well as it's *amplitude* and *period*\ .  Note that
 if the dimension is in the plane of the wall, this is effectively a
 shearing motion.  If the dimension is perpendicular to the wall, it is
-more of a shaking motion.  A *zcylinder* wall can only be wiggled in
-the z dimension.
+more of a shaking motion.
 
 Each timestep, the position of a wiggled wall in the appropriate *dim*
 is set according to this equation:

doc/src/hyper.rst

@@ -51,19 +51,17 @@ each timestep.  In the bond-boost hyperdynamics context, a "bond" is
 not a covalent bond between a pair of atoms in a molecule.  Rather it
 is simply a pair of nearby atoms as discussed below.
 
-Both global and local HD are described in :ref:`(Voter2013) <Voter2013>` by
-Art Voter and collaborators.  Similar to parallel replica dynamics
-(PRD), global and local HD are methods for performing accelerated
-dynamics that are suitable for infrequent-event systems that obey
-first-order kinetics.  A good overview of accelerated dynamics methods
-for such systems in given in :ref:`(Voter2002) <Voter2002hd>` from the same
-group.  To quote from the review paper: "The dynamical evolution is
-characterized by vibrational excursions within a potential basin,
-punctuated by occasional transitions between basins."  The transition
-probability is characterized by p(t) = k\*exp(-kt) where k is the rate
-constant.  Running multiple replicas gives an effective enhancement in
-the timescale spanned by the multiple simulations, while waiting for
-an event to occur.
+Both global and local HD are described in :ref:`(Voter2013)
+<Voter2013>` by Art Voter and collaborators.  Similar to parallel
+replica dynamics (PRD), global and local HD are methods for performing
+accelerated dynamics that are suitable for infrequent-event systems
+that obey first-order kinetics.  A good overview of accelerated
+dynamics methods (AMD) for such systems in given in :ref:`(Voter2002)
+<Voter2002hd>` from the same group.  To quote from the review paper:
+"The dynamical evolution is characterized by vibrational excursions
+within a potential basin, punctuated by occasional transitions between
+basins.  The transition probability is characterized by p(t) =
+k\*exp(-kt) where k is the rate constant."
 
 Both HD and PRD produce a time-accurate trajectory that effectively
 extends the timescale over which a system can be simulated, but they

doc/src/kspace_modify.rst

@@ -145,16 +145,16 @@ parameters, see the :doc:`How-To <Howto_dispersion>` discussion.
 
 The *fftbench* keyword applies only to PPPM. It is off by default. If
 this option is turned on, LAMMPS will perform a short FFT benchmark
-computation and report its timings, and will thus finish a some seconds
+computation and report its timings, and will thus finish some seconds
 later than it would if this option were off.
 
 ----------
 
 The *force/disp/real* and *force/disp/kspace* keywords set the force
-accuracy for the real and space computations for the dispersion part
-of pppm/disp. As shown in :ref:`(Isele-Holder) <Isele-Holder1>`, optimal
-performance and accuracy in the results is obtained when these values
-are different.
+accuracy for the real and reciprocal space computations for the dispersion
+part of pppm/disp. As shown in :ref:`(Isele-Holder) <Isele-Holder1>`,
+optimal performance and accuracy in the results is obtained when these
+values are different.
 
 ----------
 
@@ -413,10 +413,10 @@ slab correction has also been extended to point dipole interactions
 ----------
 
 The *force/disp/real* and *force/disp/kspace* keywords set the force
-accuracy for the real and space computations for the dispersion part
-of pppm/disp. As shown in :ref:`(Isele-Holder) <Isele-Holder1>`, optimal
-performance and accuracy in the results is obtained when these values
-are different.
+accuracy for the real and reciprocal space computations for the dispersion
+part of pppm/disp. As shown in :ref:`(Isele-Holder) <Isele-Holder1>`,
+optimal performance and accuracy in the results is obtained when these
+values are different.
 
 The *disp/auto* option controls whether the pppm/disp is allowed to
 generate PPPM parameters automatically. If set to *no*\ , parameters

doc/src/pair_eam.rst

@@ -39,15 +39,9 @@ pair_style eam/alloy/opt command
 pair_style eam/cd command
 =========================
 
-pair_style eam/cd/omp command
-=============================
-
 pair_style eam/cd/old command
 =============================
 
-pair_style eam/cd/old/omp command
-=================================
-
 pair_style eam/fs command
 =========================
 

doc/src/pair_momb.rst

@@ -31,7 +31,7 @@ Style *momb* computes pairwise van der Waals (vdW) and short-range
 interactions using the Morse potential and :ref:`(Grimme) <Grimme>` method
 implemented in the Many-Body Metal-Organic (MOMB) force field
 described comprehensively in :ref:`(Fichthorn) <Fichthorn>` and
-:ref:`(Zhou) <Zhou4>`. Grimme's method is widely used to correct for
+:ref:`(Zhou) <Zhou5>`. Grimme's method is widely used to correct for
 dispersion in density functional theory calculations.
 
 .. math::
@@ -76,6 +76,6 @@ Related commands
 
 **(Fichthorn)** Fichthorn, Balankura, Qi, CrystEngComm, 18(29), 5410-5417 (2016).
 
-.. _Zhou4:
+.. _Zhou5:
 
 **(Zhou)** Zhou, Saidi, Fichthorn, J Phys Chem C, 118(6), 3366-3374 (2014).

doc/src/pair_polymorphic.rst

@@ -18,21 +18,22 @@ Examples
 .. code-block:: LAMMPS
 
    pair_style polymorphic
-   pair_coeff * * TlBr_msw.polymorphic Tl Br
-   pair_coeff * * AlCu_eam.polymorphic Al Cu
-   pair_coeff * * GaN_tersoff.polymorphic Ga N
-   pair_coeff * * GaN_sw.polymorphic GaN
+   pair_coeff * * FeCH_BOP_I.poly Fe C H
+   pair_coeff * * TlBr_msw.poly Tl Br
+   pair_coeff * * CuTa_eam.poly Cu Ta
+   pair_coeff * * GaN_tersoff.poly Ga N
+   pair_coeff * * GaN_sw.poly Ga N
 
 Description
 """""""""""
 
 The *polymorphic* pair style computes a 3-body free-form potential
-(:ref:`Zhou <Zhou3>`) for the energy E of a system of atoms as
+(:ref:`Zhou3 <Zhou3>`) for the energy E of a system of atoms as
 
 .. math::
 
-   E & = \frac{1}{2}\sum_{i=1}^{i=N}\sum_{j=1}^{j=N}\left[\left(1-\delta_{ij}\right)\cdot U_{IJ}\left(r_{ij}\right)-\left(1-\eta_{ij}\right)\cdot F_{IJ}\left(r_{ij}\right)\cdot V_{IJ}\left(r_{ij}\right)\right] \\
-   X_{ij} & = \sum_{k=i_1,k\neq i,j}^{i_N}W_{IK}\left(r_{ik}\right)\cdot G_{JIK}\left(\theta_{jik}\right)\cdot P_{IK}\left(\Delta r_{jik}\right) \\
+   E & = \frac{1}{2}\sum_{i=1}^{i=N}\sum_{j=1}^{j=N}\left[\left(1-\delta_{ij}\right)\cdot U_{IJ}\left(r_{ij}\right)-\left(1-\eta_{ij}\right)\cdot F_{IJ}\left(X_{ij}\right)\cdot V_{IJ}\left(r_{ij}\right)\right] \\
+   X_{ij} & = \sum_{k=i_1,k\neq j}^{i_N}W_{IK}\left(r_{ik}\right)\cdot G_{JIK}\left(\cos\theta_{jik}\right)\cdot P_{JIK}\left(\Delta r_{jik}\right) \\
    \Delta r_{jik} & = r_{ij}-\xi_{IJ}\cdot r_{ik}
 
 where I, J, K represent species of atoms i, j, and k, :math:`i_1, ...,
@@ -42,230 +43,267 @@ Dirac constant (i.e., :math:`\delta_{ij} = 1` when :math:`i = j`, and
 constant that can be set either to :math:`\eta_{ij} = \delta_{ij}` or
 :math:`\eta_{ij} = 1 - \delta_{ij}` depending on the potential type,
 :math:`U_{IJ}(r_{ij})`, :math:`V_{IJ}(r_{ij})`, :math:`W_{IK}(r_{ik})`
-are pair functions, :math:`G_{JIK}(\cos(\theta))` is an angular
-function, :math:`P_{IK}(\Delta r_{jik})` is a function of atomic spacing
-differential :math:`\Delta r_{jik} = r_{ij} - \xi_{IJ} \cdot r_{ik}`
-with :math:`\xi_{IJ}` being a pair-dependent parameter, and
+are pair functions, :math:`G_{JIK}(\cos\theta_{jik})` is an angular
+function, :math:`P_{JIK}(\Delta r_{jik})` is a function of atomic
+spacing differential :math:`\Delta r_{jik} = r_{ij} - \xi_{IJ} \cdot
+r_{ik}` with :math:`\xi_{IJ}` being a pair-dependent parameter, and
 :math:`F_{IJ}(X_{ij})` is a function of the local environment variable
 :math:`X_{ij}`. This generic potential is fully defined once the
 constants :math:`\eta_{ij}` and :math:`\xi_{IJ}`, and the six functions
 :math:`U_{IJ}(r_{ij})`, :math:`V_{IJ}(r_{ij})`, :math:`W_{IK}(r_{ik})`,
-:math:`G_{JIK}(\cos(\theta))`, :math:`P_{IK}(\Delta r_{jik})`, and
-:math:`F_{IJ}(X_{ij})` are given. Note that these six functions are all
-one dimensional, and hence can be provided in an analytic or tabular
-form. This allows users to design different potentials solely based on a
-manipulation of these functions. For instance, the potential reduces to
-Stillinger-Weber potential (:ref:`SW <SW>`) if we set
+:math:`G_{JIK}(\cos\theta_{jik})`, :math:`P_{JIK}(\Delta r_{jik})`, and
+:math:`F_{IJ}(X_{ij})` are given. Here LAMMPS uses a global parameter
+:math:`\eta` to represent :math:`\eta_{ij}`. When :math:`\eta = 1`,
+:math:`\eta_{ij} = 1 - \delta_{ij}`, otherwise :math:`\eta_{ij} =
+\delta_{ij}`. Additionally, :math:`\eta = 3` indicates that the function
+:math:`P_{JIK}(\Delta r)` depends on species I, J and K, otherwise
+:math:`P_{JIK}(\Delta r) = P_{IK}(\Delta r)` only depends on species I
+and K. Note that these six functions are all one dimensional, and hence
+can be provided in a tabular form. This allows users to design different
+potentials solely based on a manipulation of these functions. For
+instance, the potential reduces to a Stillinger-Weber potential
+(:ref:`SW <SW>`) if we set
 
 .. math::
 
-   \left\{\begin{array}{l}
-   \eta_{ij} = \delta_{ij},\xi_{IJ}=0 \\
-   U_{IJ}\left(r\right)=A_{IJ}\cdot\epsilon_{IJ}\cdot \left(\frac{\sigma_{IJ}}{r}\right)^q\cdot \left[B_{IJ}\cdot \left(\frac{\sigma_{IJ}}{r}\right)^{p-q}-1\right]\cdot exp\left(\frac{\sigma_{IJ}}{r-a_{IJ}\cdot \sigma_{IJ}}\right) \\
-   V_{IJ}\left(r\right)=\sqrt{\lambda_{IJ}\cdot \epsilon_{IJ}}\cdot exp\left(\frac{\gamma_{IJ}\cdot \sigma_{IJ}}{r-a_{IJ}\cdot \sigma_{IJ}}\right) \\
-   F_{IJ}\left(X\right)=-X \\
-   P_{IJ}\left(\Delta r\right)=1 \\
-   W_{IJ}\left(r\right)=\sqrt{\lambda_{IJ}\cdot \epsilon_{IJ}}\cdot exp\left(\frac{\gamma_{IJ}\cdot \sigma_{IJ}}{r-a_{IJ}\cdot \sigma_{IJ}}\right) \\
-   G_{JIK}\left(\theta\right)=\left(cos\theta+\frac{1}{3}\right)^2
-   \end{array}\right.
+   \eta_{ij} & = \delta_{ij} (\eta = 2~or~\eta = 0),\xi_{IJ}=0 \\
+   U_{IJ}\left(r\right) & = A_{IJ}\cdot\epsilon_{IJ}\cdot \left(\frac{\sigma_{IJ}}{r}\right)^q\cdot \left[B_{IJ}\cdot \left(\frac{\sigma_{IJ}}{r}\right)^{p-q}-1\right]\cdot exp\left(\frac{\sigma_{IJ}}{r-a_{IJ}\cdot \sigma_{IJ}}\right) \\
+   V_{IJ}\left(r\right) & = \sqrt{\lambda_{IJ}\cdot \epsilon_{IJ}}\cdot exp\left(\frac{\gamma_{IJ}\cdot \sigma_{IJ}}{r-a_{IJ}\cdot \sigma_{IJ}}\right) \\
+   F_{IJ}\left(X\right) & = -X \\
+   P_{JIK}\left(\Delta r\right) & = P_{IK}\left(\Delta r\right) = 1 \\
+   W_{IJ}\left(r\right) & = \sqrt{\lambda_{IJ}\cdot \epsilon_{IJ}}\cdot exp\left(\frac{\gamma_{IJ}\cdot \sigma_{IJ}}{r-a_{IJ}\cdot \sigma_{IJ}}\right) \\
+   G_{JIK}\left(\cos\theta\right) & = \left(\cos\theta+\frac{1}{3}\right)^2
 
-The potential reduces to Tersoff types of potential
-(:ref:`Tersoff <Tersoff>` or :ref:`Albe <poly-Albe>`) if we set
+The potential reduces to a Tersoff potential (:ref:`Tersoff <Tersoff>`
+or :ref:`Albe <poly-Albe>`) if we set
 
 .. math::
 
-   \left\{\begin{array}{l}
-   \eta_{ij}=\delta_{ij},\xi_{IJ}=1 \\
-   U_{IJ}\left(r\right)=\frac{D_{e,IJ}}{S_{IJ}-1}\cdot exp\left[-\beta_{IJ}\sqrt{2S_{IJ}\left(r-r_{e,IJ}\right)}\right]\cdot f_{c,IJ}\left(r\right) \\
-   V_{IJ}\left(r\right)=\frac{S_{IJ}\cdot D_{e,IJ}}{S_{IJ}-1}\cdot exp\left[-\beta_{IJ}\sqrt{\frac{2}{S_{IJ}}\left(r-r_{e,IJ}\right)}\right]\cdot f_{c,IJ}\left(r\right) \\
-   F_{IJ}\left(X\right)=\left(1+X\right)^{-\frac{1}{2}} \\
-   P_{IJ}\left(\Delta r\right)=exp\left(2\mu_{IK}\cdot \Delta r\right) \\
-   W_{IJ}\left(r\right)=f_{c,IK}\left(r\right) \\
-   G_{JIK}\left(\theta\right)=\gamma_{IK}\left[1+\frac{c_{IK}^2}{d_{IK}^2}-\frac{c_{IK}^2}{d_{IK}^2+\left(h_{IK}+cos\theta\right)^2}\right]
-   \end{array}\right.
+   \eta_{ij} & = \delta_{ij} (\eta = 2~or~\eta = 0),\xi_{IJ}=1 \\
+   U_{IJ}\left(r\right) & = \frac{D_{e,IJ}}{S_{IJ}-1}\cdot exp\left[-\beta_{IJ}\sqrt{2S_{IJ}}\left(r-r_{e,IJ}\right)\right]\cdot f_{c,IJ}\left(r\right) \\
+   V_{IJ}\left(r\right) & = \frac{S_{IJ}\cdot D_{e,IJ}}{S_{IJ}-1}\cdot exp\left[-\beta_{IJ}\sqrt{\frac{2}{S_{IJ}}}\left(r-r_{e,IJ}\right)\right]\cdot f_{c,IJ}\left(r\right) \\
+   F_{IJ}\left(X\right) & = \left(1+X\right)^{-\frac{1}{2}} \\
+   P_{JIK}\left(\Delta r\right) & = P_{IK}\left(\Delta r\right) = exp\left(2\mu_{IK}\cdot \Delta r\right) \\
+   W_{IJ}\left(r\right) & = f_{c,IJ}\left(r\right) \\
+   G_{JIK}\left(\cos\theta\right) & = \gamma_{IK}\left[1+\frac{c_{IK}^2}{d_{IK}^2}-\frac{c_{IK}^2}{d_{IK}^2+\left(h_{IK}+\cos\theta\right)^2}\right]
+
+where
 
 .. math::
 
-   f_{c,IJ}=\left\{\begin{array}{lr}
-   1, & r\leq r_{s,IJ} \\
-   \frac{1}{2}+\frac{1}{2} cos \left[\frac{\pi \left(r-r_{s,IJ}\right)}{r_{c,IJ}-r_{s,IJ}}\right], & r_{s,IJ}<r<r_{c,IJ} \\
-   0, & r \geq r_{c,IJ} \\
+   f_{c,IJ}\left(r\right)=\left\{\begin{array}{l}
+   1, r\leq R_{IJ}-D_{IJ} \\
+   \frac{1}{2}+\frac{1}{2}cos\left[\frac{\pi\left(r+D_{IJ}-R_{IJ}\right)}{2D_{IJ}}\right], R_{IJ}-D_{IJ} < r < R_{IJ}+D_{IJ} \\
+   0, r \geq R_{IJ}+D_{IJ}
    \end{array}\right.
 
-The potential reduces to Rockett-Tersoff (:ref:`Wang <Wang3>`) type if we set
+The potential reduces to a modified Stillinger-Weber potential
+(:ref:`Zhou3 <Zhou3>`) if we set
 
 .. math::
 
-   \left\{\begin{array}{l}
-   \eta_{ij}=\delta_{ij},\xi_{IJ}=1 \\
-   U_{IJ}\left(r\right)=\left\{\begin{array}{lr}
-   A_{IJ}\cdot exp\left(-\lambda_{1,IJ}\cdot r\right)\cdot f_{c,IJ}\left(r\right), & r\leq r_{s,1,IJ} \\
-   A_{IJ}\cdot exp\left(-\lambda_{1,IJ}\cdot r\right)\cdot f_{c,IJ}\left(r\right)\cdot f_{c,1,IJ}\left(r\right), & r_{s,1,IJ}<r<r_{c,1,IJ} \\
-   0, & r\ge r_{c,1,IJ}
-   \end{array}\right. \\
-   V_{IJ}\left(r\right)=\left\{\begin{array}{lr}
-   B_{IJ} \cdot exp\left(-\lambda_{2,IJ}\cdot r\right)\cdot f_{c,IJ}\left(r\right), & r\le r_{s,1,IJ} \\
-   B_{IJ} \cdot exp\left(-\lambda_{2,IJ}\cdot r\right)\cdot f_{c,IJ}\left(r\right)+A_{IJ}\cdot exp\left(-\lambda_{1,IJ}\cdot r\right)\cdot & \\ ~~~~~~ f_{c,IJ}\left(r\right)\cdot \left[1-f_{c,1,IJ}\left(r\right)\right], & r_{s,1,IJ}<r<r_{c,1,IJ} \\
-   B_{IJ} \cdot exp\left(-\lambda_{2,IJ}\cdot r\right)\cdot f_{c,IJ}\left(r\right)+A_{IJ}\cdot exp\left(-\lambda_{1,IJ}\cdot r\right)\cdot & \\ ~~~~~~ f_{c,IJ}\left(r\right) & r \ge r_{c,1,IJ}
-   \end{array}\right. \\
-   F_{IJ}\left(X\right)=\left[1+\left(\beta_{IJ}\cdot X\right)^{n_{IJ}}\right]^{-\frac{1}{2n_{IJ}}} \\
-   P_{IJ}\left(\Delta r\right)=exp\left(\lambda_{3,IK}\cdot \Delta r^3\right) \\
-   W_{IJ}\left(r\right)=f_{c,IK}\left(r\right) \\
-   G_{JIK}\left(\theta\right)=1+\frac{c_{IK}^2}{d_{IK}^2}-\frac{c_{IK}^2}{d_{IK}^2+\left(h_{IK}+cos\theta\right)^2}
-   \end{array}\right.
+   \eta_{ij} & = \delta_{ij} (\eta = 2~or~\eta = 0),\xi_{IJ}=0 \\
+   U_{IJ}\left(r\right) & = \varphi_{R,IJ}\left(r\right)-\varphi_{A,IJ}\left(r\right) \\
+   V_{IJ}\left(r\right) & = u_{IJ}\left(r\right) \\
+   F_{IJ}\left(X\right) & = -X \\
+   P_{JIK}\left(\Delta r\right) & = P_{IK}\left(\Delta r\right) = 1 \\
+   W_{IJ}\left(r\right) & = u_{IJ}\left(r\right) \\
+   G_{JIK}\left(\cos\theta\right) & = g_{JIK}\left(\cos\theta\right)
+
+The potential reduces to a Rockett-Tersoff potential (:ref:`Wang3
+<Wang3>`) if we set
 
 .. math::
 
-   f_{c,IJ}=\left\{\begin{array}{lr}
-   1, & r\leq r_{s,IJ} \\
-   \frac{1}{2}+\frac{1}{2} cos \left[\frac{\pi \left(r-r_{s,IJ}\right)}{r_{c,IJ}-r_{s,IJ}}\right], & r_{s,IJ}<r<r_{c,IJ} \\
-   0, & r \geq r_{c,IJ} \\
-   \end{array}\right.
+   \eta_{ij} & = \delta_{ij} (\eta = 2~or~\eta = 0),\xi_{IJ}=1 \\
+   U_{IJ}\left(r\right) & = A_{IJ}exp\left(-\lambda_{1,IJ}\cdot r\right)f_{c,IJ}\left(r\right)f_{ca,IJ}\left(r\right) \\
+   V_{IJ}\left(r\right) & = \left\{\begin{array}{l}B_{IJ}exp\left(-\lambda_{2,IJ}\cdot r\right)f_{c,IJ}\left(r\right)+ \\ A_{IJ}exp\left(-\lambda_{1,IJ}\cdot r\right)f_{c,IJ}\left(r\right) \left[1-f_{ca,IJ}\left(r\right)\right]\end{array} \right\} \\
+   F_{IJ}\left(X\right) & = \left[1+\left(\beta_{IJ}X\right)^{n_{IJ}}\right]^{-\frac{1}{2n_{IJ}}} \\
+   P_{JIK}\left(\Delta r\right) & = P_{IK}\left(\Delta r\right) = exp\left(\lambda_{3,IK}\cdot \Delta r^3\right) \\
+   W_{IJ}\left(r\right) & = f_{c,IJ}\left(r\right) \\
+   G_{JIK}\left(\cos\theta\right) & = 1+\frac{c_{IK}^2}{d_{IK}^2}-\frac{c_{IK}^2}{d_{IK}^2+\left(h_{IK}+\cos\theta\right)^2}
+
+where :math:`f_{ca,IJ}(r)` is similar to the :math:`f_{c,IJ}(r)` defined
+above:
 
 .. math::
 
-   f_{c,1,IJ}=\left\{\begin{array}{lr}
-   1, & r\leq r_{s,1,IJ} \\
-   \frac{1}{2}+\frac{1}{2} cos \left[\frac{\pi \left(r-r_{s,1,IJ}\right)}{r_{c,1,IJ}-r_{s,1,IJ}}\right], & r_{s,1,IJ}<r<r_{c,1,IJ} \\
-   0, & r \geq r_{c,1,IJ} \\
+   f_{ca,IJ}\left(r\right)=\left\{\begin{array}{l}
+   1, r\leq R_{a,IJ}-D_{a,IJ} \\
+   \frac{1}{2}+\frac{1}{2}cos\left[\frac{\pi\left(r+D_{a,IJ}-R_{a,IJ}\right)}{2D_{a,IJ}}\right], R_{a,IJ}-D_{a,IJ} < r < R_{a,IJ}+D_{a,IJ} \\
+   0, r \geq R_{a,IJ}+D_{a,IJ}
    \end{array}\right.
 
-The potential becomes embedded atom method (:ref:`Daw <poly-Daw>`) if we set
+The potential becomes the embedded atom method (:ref:`Daw <poly-Daw>`)
+if we set
 
 .. math::
 
-   \left\{\begin{array}{l}
-   \eta_{ij}=1-\delta_{ij},\xi_{IJ}=0 \\
-   U_{IJ}\left(r\right)=\phi_{IJ}\left(r\right) \\
-   V_{IJ}\left(r\right)=1 \\
-   F_{II}\left(X\right)=-2F_I\left(X\right) \\
-   P_{IJ}\left(\Delta r\right)=1 \\
-   W_{IJ}\left(r\right)=f_{K}\left(r\right) \\
-   G_{JIK}\left(\theta\right)=1
-   \end{array}\right.
+   \eta_{ij} & = 1-\delta_{ij} (\eta = 1),\xi_{IJ}=0 \\
+   U_{IJ}\left(r\right) & = \phi_{IJ}\left(r\right) \\
+   V_{IJ}\left(r\right) & = 1 \\
+   F_{II}\left(X\right) & = -2F_I\left(X\right) \\
+   P_{JIK}\left(\Delta r\right) & = P_{IK}\left(\Delta r\right) = 1 \\
+   W_{IJ}\left(r\right) & = f_{J}\left(r\right) \\
+   G_{JIK}\left(\cos\theta\right) & = 1
 
-In the embedded atom method case, :math:`\phi_{IJ}(r_{ij})` is the pair
+In the embedded atom method case, :math:`\phi_{IJ}(r)` is the pair
 energy, :math:`F_I(X)` is the embedding energy, *X* is the local
-electron density, and :math:`f_K(r)` is the atomic electron density function.
+electron density, and :math:`f_J(r)` is the atomic electron density
+function.
 
-If the tabulated functions are created using the parameters of sw,
-tersoff, and eam potentials, the polymorphic pair style will produce
-the same global properties (energies and stresses) and the same forces
-as the sw, tersoff, and eam pair styles. The polymorphic pair style
-also produces the same atom properties (energies and stresses) as the
-corresponding tersoff and eam pair styles. However, due to a different
-partition of global properties to atom properties, the polymorphic
-pair style will produce different atom properties (energies and
-stresses) as the sw pair style. This does not mean that polymorphic
-pair style is different from the sw pair style in this case. It just
-means that the definitions of the atom energies and atom stresses are
-different.
+The potential reduces to another type of Tersoff potential (:ref:`Zhou4
+<Zhou4>`) if we set
 
-Only a single pair_coeff command is used with the polymorphic style
-which specifies an potential file for all needed elements. These are
+.. math::
+
+   \eta_{ij} & = \delta_{ij} (\eta = 3),\xi_{IJ}=1 \\
+   U_{IJ}\left(r\right) & = \frac{D_{e,IJ}}{S_{IJ}-1}\cdot exp\left[-\beta_{IJ}\sqrt{2S_{IJ}}\left(r-r_{e,IJ}\right)\right]\cdot f_{c,IJ}\left(r\right) \cdot T_{IJ}\left(r\right)+V_{ZBL,IJ}\left(r\right)\left[1-T_{IJ}\left(r\right)\right] \\
+   V_{IJ}\left(r\right) & = \frac{S_{IJ}\cdot D_{e,IJ}}{S_{IJ}-1}\cdot exp\left[-\beta_{IJ}\sqrt{\frac{2}{S_{IJ}}}\left(r-r_{e,IJ}\right)\right]\cdot f_{c,IJ}\left(r\right) \cdot T_{IJ}\left(r\right) \\
+   F_{IJ}\left(X\right) & = \left(1+X\right)^{-\frac{1}{2}} \\
+   P_{JIK}\left(\Delta r\right) & = \omega_{JIK} \cdot exp\left(\alpha_{JIK}\cdot \Delta r\right) \\
+   W_{IJ}\left(r\right) & = f_{c,IJ}\left(r\right) \\
+   G_{JIK}\left(\cos\theta\right) & = \gamma_{JIK}\left[1+\frac{c_{JIK}^2}{d_{JIK}^2}-\frac{c_{JIK}^2}{d_{JIK}^2+\left(h_{JIK}+\cos\theta\right)^2}\right] \\
+   T_{IJ}\left(r\right) & = \frac{1}{1+exp\left[-b_{f,IJ}\left(r-r_{f,IJ}\right)\right]} \\
+   V_{ZBL,IJ}\left(r\right) & = 14.4 \cdot \frac{Z_I \cdot Z_J}{r}\sum_{k=1}^{4}\mu_k \cdot exp\left[-\nu_k \left(Z_I^{0.23}+Z_J^{0.23}\right) r\right]
+
+where :math:`f_{c,IJ}(r)` is the same as defined above. This Tersoff
+potential differs from the one above because the :math:`P_{JIK}(\Delta
+r)` function is now dependent on all three species I, J, and K.
+
+If the tabulated functions are created using the parameters of
+Stillinger-Weber, Tersoff, and EAM potentials, the polymorphic pair
+style will produce the same global properties (energies and stresses)
+and the same forces as the :doc:`sw <pair_sw>`, :doc:`tersoff
+<pair_tersoff>`, and :doc:`eam <pair_eam>` pair styles. The polymorphic
+pair style also produces the same per-atom properties (energies and
+stresses) as the corresponding :doc:`tersoff <pair_tersoff>` and
+:doc:`eam <pair_eam>` pair styles. However, due to a different
+partitioning of global properties to per-atom properties, the
+polymorphic pair style will produce different per-atom properties
+(energies and stresses) as the :doc:`sw <pair_sw>` pair style. This does
+not mean that polymorphic pair style is different from the sw pair
+style. It just means that the definitions of the atom energies and atom
+stresses are different.
+
+Only a single pair_coeff command is used with the polymorphic pair style
+which specifies a potential file for all needed elements.  These are
 mapped to LAMMPS atom types by specifying N additional arguments after
-the filename in the pair_coeff command, where N is the number of
-LAMMPS atom types:
+the filename in the pair_coeff command, where N is the number of LAMMPS
+atom types:
 
 * filename
-* N element names = mapping of Tersoff elements to atom types
+* N element names = mapping of polymorphic potential elements to atom types
 
 See the pair_coeff doc page for alternate ways to specify the path for
-the potential file.  Several files for polymorphic potentials are
-included in the potentials directory of the LAMMPS distribution.  They
+the potential file. Several files for polymorphic potentials are
+included in the potentials directory of the LAMMPS distribution. They
 have a "poly" suffix.
 
-As an example, imagine the SiC_tersoff.poly file has tabulated
-functions for Si-C tersoff potential. If your LAMMPS simulation has 4
-atoms types and you want the 1st 3 to be Si, and the 4th to be C, you
-would use the following pair_coeff command:
+As an example, imagine the GaN_tersoff.poly file has tabulated functions
+for Ga-N tersoff potential. If your LAMMPS simulation has 4 atoms types
+and you want the 1st 3 to be Ga, and the 4th to be N, you would use the
+following pair_coeff command:
 
 .. code-block:: LAMMPS
 
-   pair_coeff * * SiC_tersoff.poly Si Si Si C
+   pair_coeff * * GaN_tersoff.poly Ga Ga Ga N
 
-The 1st 2 arguments must be \* \* so as to span all LAMMPS atom
-types. The first three Si arguments map LAMMPS atom types 1,2,3 to the
-Si element in the polymorphic file. The final C argument maps LAMMPS
-atom type 4 to the C element in the polymorphic file. If a mapping
-value is specified as NULL, the mapping is not performed. This can be
-used when an polymorphic potential is used as part of the hybrid pair
-style. The NULL values are placeholders for atom types that will be
-used with other potentials.
+The first two arguments must be \* \* to span all pairs of LAMMPS atom
+types. The first three Ga arguments map LAMMPS atom types 1,2,3 to the
+Ga element in the polymorphic file. The final N argument maps LAMMPS
+atom type 4 to the N element in the polymorphic file. If a mapping value
+is specified as NULL, the mapping is not performed. This can be used
+when an polymorphic potential is used as part of the hybrid pair
+style. The NULL values are placeholders for atom types that will be used
+with other potentials.
 
 Potential files in the potentials directory of the LAMMPS distribution
 have a ".poly" suffix. At the beginning of the files, an unlimited
-number of lines starting with '#' are used to describe the potential
-and are ignored by LAMMPS. The next line lists two numbers:
+number of lines starting with '#' are used to describe the potential and
+are ignored by LAMMPS. The next line lists two numbers:
 
 .. parsed-literal::
 
-   ntypes :math:`\eta`
+   ntypes eta
 
-Here ntypes represent total number of species defined in the potential
-file, and :math:`\eta = 0` or 1. The number ntypes must equal the total
-number of different species defined in the pair_coeff command. When
-:math:`\eta = 1`, :math:\eta_{ij}` defined in the potential functions
-above is set to :math:`1 - \delta_{ij}`, otherwise :math:`\eta_{ij}` is
-set to :math:`\delta_{ij}`. The next ntypes lines each lists two numbers
-and a character string representing atomic number, atomic mass, and name
-of the species of the ntypes elements:
+Here *ntypes* represent total number of species defined in the potential
+file, :math:`\eta = 1` reduces to embedded atom method, :math:`\eta = 3`
+assumes a three species dependent :math:`P_{JIK}(\Delta r)` function,
+and all other values of :math:`\eta` assume a two species dependent
+:math:`P_{JK}(\Delta r)` function. The value of *ntypes* must equal the
+total number of different species defined in the pair_coeff command. The
+next *ntypes* lines each lists two numbers and a character string
+representing atomic number, atomic mass, and name of the species of the
+ntypes elements:
 
 .. parsed-literal::
 
-   atomic_number atomic-mass element (1)
-   atomic_number atomic-mass element (2)
+   atomic-number atomic-mass element-name(1)
+   atomic-number atomic-mass element-name(2)
    ...
-   atomic_number atomic-mass element (ntypes)
+   atomic-number atomic-mass element-name(ntypes)
+
+The next line contains four numbers:
+
+.. parsed-literal::
+
+   nr ntheta nx xmax
+
+Here nr is total number of tabular points for radial functions U, V, W,
+P, ntheta is total number of tabular points for the angular function G,
+nx is total number of tabular points for the function F, xmax is a
+maximum value of the argument of function F. Note that the pair
+functions :math:`U_{IJ}(r)`, :math:`V_{IJ}(r)`, :math:`W_{IJ}(r)` are
+uniformly tabulated between 0 and cutoff distance of the IJ pair,
+:math:`G_{JIK}(\cos\theta)` is uniformly tabulated between -1 and 1,
+:math:`P_{JIK}(\Delta r)` is uniformly tabulated between -rcmax and
+rcmax where rcmax is the maximum cutoff distance of all pairs, and
+:math:`F_{IJ}(X)` is uniformly tabulated between 0 and xmax. Linear
+extrapolation is assumed if actual simulations exceed these ranges.
 
 The next ntypes\*(ntypes+1)/2 lines contain two numbers:
 
 .. parsed-literal::
 
-   cut :math:`xi` (1)
-   cut :math:`xi` (2)
+   cut xi(1)
+   cut xi(2)
    ...
-   cut :math:`xi` (ntypes\*(ntypes+1)/2)
+   cut xi(ntypes\*(ntypes+1)/2)
 
-Here cut means the cutoff distance of the pair functions, :math:`\xi` is
-the same as defined in the potential functions above. The
+Here cut means the cutoff distance of the pair functions, "xi" is
+:math:`\xi` as defined in the potential functions above. The
 ntypes\*(ntypes+1)/2 lines are related to the pairs according to the
-sequence of first ii (self) pairs, i = 1, 2, ..., ntypes, and then then
-ij (cross) pairs, i = 1, 2, ..., ntypes-1, and j = i+1, i+2, ..., ntypes
+sequence of first ii (self) pairs, i = 1, 2, ..., ntypes, and then ij
+(cross) pairs, i = 1, 2, ..., ntypes-1, and j = i+1, i+2, ..., ntypes
 (i.e., the sequence of the ij pairs follows 11, 22, ..., 12, 13, 14,
 ..., 23, 24, ...).
 
-The final blocks of the potential file are the U, V, W, P, G, and F
-functions are listed sequentially. First, U functions are given for
-each of the ntypes\*(ntypes+1)/2 pairs according to the sequence
-described above. For each of the pairs, nr values are listed. Next,
-similar arrays are given for V, W, and P functions. Then G functions
-are given for all the ntypes\*ntypes\*ntypes ijk triplets in a natural
-sequence i from 1 to ntypes, j from 1 to ntypes, and k from 1 to
-ntypes (i.e., ijk = 111, 112, 113, ..., 121, 122, 123 ..., 211, 212,
-...). Each of the ijk functions contains ng values. Finally, the F
-functions are listed for all ntypes\*(ntypes+1)/2 pairs, each
-containing nx values. Either analytic or tabulated functions can be
-specified. Currently, constant, exponential, sine and cosine analytic
-functions are available which are specified with: constant c1 , where
-f(x) = c1 exponential c1 c2 , where f(x) = c1 exp(c2\*x) sine c1 c2 ,
-where f(x) = c1 sin(c2\*x) cos c1 c2 , where f(x) = c1 cos(c2\*x)
-Tabulated functions are specified by spline n x1 x2, where n=number of
-point, (x1,x2)=range and then followed by n values evaluated uniformly
-over these argument ranges.  The valid argument ranges of the
-functions are between 0 <= r <= cut for the U(r), V(r), W(r)
-functions, -cutmax <= delta_r <= cutmax for the P(delta_r) functions,
--1 <= :math:`\cos\theta` <= 1 for the G(:math:`\cos\theta`) functions,
-and 0 <= X <= maxX for the F(X) functions.
+In the final blocks of the potential file, U, V, W, P, G, and F
+functions are listed sequentially. First, U functions are given for each
+of the ntypes\*(ntypes+1)/2 pairs according to the sequence described
+above. For each of the pairs, nr values are listed. Next, similar arrays
+are given for V and W functions. If P functions depend only on pair
+species, i.e., :math:`\eta \neq 3`, then P functions are also listed the
+same way the next. If P functions depend on three species, i.e.,
+:math:`\eta = 3`, then P functions are listed for all the
+ntypes*ntypes*ntypes IJK triplets in a natural sequence I from 1 to
+ntypes, J from 1 to ntypes, and K from 1 to ntypes (i.e., IJK = 111,
+112, 113, ..., 121, 122, 123 ..., 211, 212, ...). Next, G functions are
+listed for all the ntypes*ntypes*ntypes IJK triplets similarly. For each
+of the G functions, ntheta values are listed. Finally, F functions are
+listed for all the ntypes*(ntypes+1)/2 pairs in the same sequence as
+described above.  For each of the F functions, nx values are listed.
 
 **Mixing, shift, table tail correction, restart**\ :
 
 This pair styles does not support the :doc:`pair_modify <pair_modify>`
 shift, table, and tail options.
 
-This pair style does not write their information to :doc:`binary restart files <restart>`, since it is stored in potential files. Thus, you
-need to re-specify the pair_style and pair_coeff commands in an input
-script that reads a restart file.
+This pair style does not write their information to :doc:`binary restart
+files <restart>`, since it is stored in potential files. Thus, you need
+to re-specify the pair_style and pair_coeff commands in an input script
+that reads a restart file.
 
 ----------
 
@@ -277,15 +315,15 @@ input script. If using read_data, atomic masses must be defined in the
 atomic structure data file.
 
 This pair style is part of the MANYBODY package. It is only enabled if
-LAMMPS was built with that package. See the :doc:`Build package <Build_package>` doc page for more info.
+LAMMPS was built with that package. See the :doc:`Build package
+<Build_package>` doc page for more info.
 
 This pair potential requires the :doc:`newtion <newton>` setting to be
 "on" for pair interactions.
 
-The potential files provided with LAMMPS (see the potentials
-directory) are parameterized for metal :doc:`units <units>`. You can use
-any LAMMPS units, but you would need to create your own potential
-files.
+The potential files provided with LAMMPS (see the potentials directory)
+are parameterized for metal :doc:`units <units>`. You can use any LAMMPS
+units, but you would need to create your own potential files.
 
 Related commands
 """"""""""""""""
@@ -296,12 +334,15 @@ Related commands
 
 .. _Zhou3:
 
-**(Zhou)** X. W. Zhou, M. E. Foster, R. E. Jones, P. Yang, H. Fan, and
-F. P. Doty, J. Mater. Sci. Res., 4, 15 (2015).
+**(Zhou3)** X. W. Zhou, M. E. Foster, R. E. Jones, P. Yang, H. Fan, and F. P. Doty, J. Mater. Sci. Res., 4, 15 (2015).
+
+.. _Zhou4:
+
+**(Zhou4)** X. W. Zhou, M. E. Foster, J. A. Ronevich, and C. W. San Marchi, J. Comp. Chem., 41, 1299 (2020).
 
 .. _SW:
 
-**(SW)** F. H. Stillinger-Weber, and T. A. Weber, Phys. Rev. B, 31, 5262 (1985).
+**(SW)** F. H. Stillinger, and T. A. Weber, Phys. Rev. B, 31, 5262 (1985).
 
 .. _Tersoff:
 
@@ -309,8 +350,7 @@ F. P. Doty, J. Mater. Sci. Res., 4, 15 (2015).
 
 .. _poly-Albe:
 
-**(Albe)** K. Albe, K. Nordlund, J. Nord, and A. Kuronen, Phys. Rev. B,
-66, 035205 (2002).
+**(Albe)** K. Albe, K. Nordlund, J. Nord, and A. Kuronen, Phys. Rev. B, 66, 035205 (2002).
 
 .. _Wang3:
 

doc/src/pair_reaxc.rst

@@ -21,12 +21,13 @@ Syntax
 
   .. parsed-literal::
 
-     keyword = *checkqeq* or *lgvdw* or *safezone* or *mincap*
+     keyword = *checkqeq* or *lgvdw* or *safezone* or *mincap* or *minhbonds*
        *checkqeq* value = *yes* or *no* = whether or not to require qeq/reax fix
        *enobonds* value = *yes* or *no* = whether or not to tally energy of atoms with no bonds
        *lgvdw* value = *yes* or *no* = whether or not to use a low gradient vdW correction
        *safezone* = factor used for array allocation
        *mincap* = minimum size for array allocation
+       *minhbonds* = minimum size use for storing hydrogen bonds
 
 Examples
 """"""""
@@ -146,11 +147,11 @@ zero.  The latter behavior is usual not desired, as it causes
 discontinuities in the potential energy when the bonding of an atom
 drops to zero.
 
-Optional keywords *safezone* and *mincap* are used for allocating
-reax/c arrays.  Increasing these values can avoid memory problems,
-such as segmentation faults and bondchk failed errors, that could
-occur under certain conditions. These keywords are not used by the
-Kokkos version, which instead uses a more robust memory allocation
+Optional keywords *safezone*\ , *mincap*\ , and *minhbonds* are used
+for allocating reax/c arrays.  Increasing these values can avoid memory
+problems, such as segmentation faults and bondchk failed errors, that
+could occur under certain conditions. These keywords are not used by
+the Kokkos version, which instead uses a more robust memory allocation
 scheme that checks if the sizes of the arrays have been exceeded and
 automatically allocates more memory.
 
@@ -352,7 +353,7 @@ Default
 """""""
 
 The keyword defaults are checkqeq = yes, enobonds = yes, lgvdw = no,
-safezone = 1.2, mincap = 50.
+safezone = 1.2, mincap = 50, minhbonds = 25.
 
 ----------
 

doc/src/prd.rst

@@ -52,19 +52,16 @@ replicas of a system.  One or more replicas can be used.  The total
 number of steps *N* to run can be interpreted in one of two ways; see
 discussion of the *time* keyword below.
 
-PRD is described in :ref:`(Voter1998) <Voter1998>` by Art Voter.  Similar to
-global or local hyperdynamics (HD), PRD is a method for performing
-accelerated dynamics that is suitable for infrequent-event systems
-that obey first-order kinetics.  A good overview of accelerated
-dynamics methods for such systems in given in this review paper
-:ref:`(Voter2002) <Voter2002prd>` from Art's group.  To quote from the
-paper: "The dynamical evolution is characterized by vibrational
-excursions within a potential basin, punctuated by occasional
-transitions between basins."  The transition probability is
-characterized by p(t) = k\*exp(-kt) where k is the rate constant.
-Running multiple replicas gives an effective enhancement in the
-timescale spanned by the multiple simulations, while waiting for an
-event to occur.
+PRD is described in :ref:`(Voter1998) <Voter1998>` by Art Voter.
+Similar to global or local hyperdynamics (HD), PRD is a method for
+performing accelerated dynamics that is suitable for infrequent-event
+systems that obey first-order kinetics.  A good overview of
+accelerated dynamics methods (AMD) for such systems in given in this
+review paper :ref:`(Voter2002) <Voter2002prd>` from Art's group.  To
+quote from the paper: "The dynamical evolution is characterized by
+vibrational excursions within a potential basin, punctuated by
+occasional transitions between basins.  The transition probability is
+characterized by p(t) = k\*exp(-kt) where k is the rate constant."
 
 Both PRD and HD produce a time-accurate trajectory that effectively
 extends the timescale over which a system can be simulated, but they

doc/src/read_data.rst

@@ -107,11 +107,11 @@ command, after the third read_data command is used.
 The *add*\ , *offset*\ , *shift*\ , *extra*\ , and *group* keywords are
 useful in this context.
 
-If a simulation box does not yet exist, the *add* keyword
-cannot be used; the read_data command is being used for the first
-time.  If a simulation box does exist, due to using the
-:doc:`create_box <create_box>` command, or a previous read_data command,
-then the *add* keyword must be used.
+If a simulation box does not yet exist, the *add* keyword cannot be
+used; the read_data command is being used for the first time.  If a
+simulation box does exist, due to using the :doc:`create_box
+<create_box>` command, or a previous read_data command, then the *add*
+keyword must be used.
 
 .. note::
 
@@ -571,68 +571,69 @@ appended to it, which indicate which image of a periodic simulation
 box the atom is in.  These may be important to include for some kinds
 of analysis.
 
-+------------+---------------------------------------------------------------------------+
-| angle      | atom-ID molecule-ID atom-type x y z                                       |
-+------------+---------------------------------------------------------------------------+
-| atomic     | atom-ID atom-type x y z                                                   |
-+------------+---------------------------------------------------------------------------+
-| body       | atom-ID atom-type bodyflag mass x y z                                     |
-+------------+---------------------------------------------------------------------------+
-| bond       | atom-ID molecule-ID atom-type x y z                                       |
-+------------+---------------------------------------------------------------------------+
-| charge     | atom-ID atom-type q x y z                                                 |
-+------------+---------------------------------------------------------------------------+
-| dipole     | atom-ID atom-type q x y z mux muy muz                                     |
-+------------+---------------------------------------------------------------------------+
-| dpd        | atom-ID atom-type theta x y z                                             |
-+------------+---------------------------------------------------------------------------+
-| edpd       | atom-ID atom-type edpd_temp edpd_cv x y z                                 |
-+------------+---------------------------------------------------------------------------+
-| mdpd       | atom-ID atom-type rho x y z                                               |
-+------------+---------------------------------------------------------------------------+
-| tdpd       | atom-ID atom-type x y z cc1 cc2 ... ccNspecies                            |
-+------------+---------------------------------------------------------------------------+
-| electron   | atom-ID atom-type q spin eradius x y z                                    |
-+------------+---------------------------------------------------------------------------+
-| ellipsoid  | atom-ID atom-type ellipsoidflag density x y z                             |
-+------------+---------------------------------------------------------------------------+
-| full       | atom-ID molecule-ID atom-type q x y z                                     |
-+------------+---------------------------------------------------------------------------+
-| line       | atom-ID molecule-ID atom-type lineflag density x y z                      |
-+------------+---------------------------------------------------------------------------+
-| meso       | atom-ID atom-type rho e cv x y z                                          |
-+------------+---------------------------------------------------------------------------+
-| molecular  | atom-ID molecule-ID atom-type x y z                                       |
-+------------+---------------------------------------------------------------------------+
-| peri       | atom-ID atom-type volume density x y z                                    |
-+------------+---------------------------------------------------------------------------+
-| smd        | atom-ID atom-type molecule volume mass kernel-radius contact-radius x y z |
-+------------+---------------------------------------------------------------------------+
-| sphere     | atom-ID atom-type diameter density x y z                                  |
-+------------+---------------------------------------------------------------------------+
-| spin       | atom-ID atom-type sp x y z spx spy spz                                    |
-+------------+---------------------------------------------------------------------------+
-| template   | atom-ID molecule-ID template-index template-atom atom-type x y z          |
-+------------+---------------------------------------------------------------------------+
-| tri        | atom-ID molecule-ID atom-type triangleflag density x y z                  |
-+------------+---------------------------------------------------------------------------+
-| wavepacket | atom-ID atom-type charge spin eradius etag cs_re cs_im x y z              |
-+------------+---------------------------------------------------------------------------+
-| hybrid     | atom-ID atom-type x y z sub-style1 sub-style2 ...                         |
-+------------+---------------------------------------------------------------------------+
+.. list-table::
+
+   * - angle
+     - atom-ID molecule-ID atom-type x y z
+   * - atomic
+     - atom-ID atom-type x y z
+   * - body
+     - atom-ID atom-type bodyflag mass x y z
+   * - bond
+     - atom-ID molecule-ID atom-type x y z
+   * - charge
+     - atom-type q x y z
+   * - dipole
+     - atom-ID atom-type q x y z mux muy muz
+   * - dpd
+     - atom-ID atom-type theta x y z
+   * - edpd
+     - atom-ID atom-type edpd_temp edpd_cv x y z
+   * - electron
+     - atom-ID atom-type q spin eradius x y z
+   * - ellipsoid
+     - atom-ID atom-type ellipsoidflag density x y z
+   * - full
+     - atom-ID molecule-ID atom-type q x y z
+   * - line
+     - atom-ID molecule-ID atom-type lineflag density x y z
+   * - mdpd
+     - atom-ID atom-type rho x y z
+   * - molecular
+     - atom-ID molecule-ID atom-type x y z
+   * - peri
+     - atom-ID atom-type volume density x y z
+   * - smd
+     - atom-ID atom-type molecule volume mass kernel-radius contact-radius x0 y0 z0 x y z
+   * - sph
+     - atom-ID atom-type rho esph cv x y z
+   * - sphere
+     - atom-ID atom-type diameter density x y z
+   * - spin
+     - atom-ID atom-type x y z spx spy spz sp
+   * - tdpd
+     - atom-ID atom-type x y z cc1 cc2 ... ccNspecies
+   * - template
+     - atom-ID molecule-ID template-index template-atom atom-type x y z
+   * - tri
+     - atom-ID molecule-ID atom-type triangleflag density x y z
+   * - wavepacket
+     - atom-ID atom-type charge spin eradius etag cs_re cs_im x y z
+   * - hybrid
+     - atom-ID atom-type x y z sub-style1 sub-style2 ...
 
 The per-atom values have these meanings and units, listed alphabetically:
 
 * atom-ID = integer ID of atom
 * atom-type = type of atom (1-Ntype)
 * bodyflag = 1 for body particles, 0 for point particles
-* cc = chemical concentration for tDPD particles for each species (mole/volume units)
+* ccN = chemical concentration for tDPD particles for each species (mole/volume units)
 * contact-radius = ??? (distance units)
 * cs_re,cs_im = real/imaginary parts of wave packet coefficients
 * cv = heat capacity (need units) for SPH particles
 * density = density of particle (mass/distance\^3 or mass/distance\^2 or mass/distance units, depending on dimensionality of particle)
 * diameter = diameter of spherical atom (distance units)
-* e = energy (need units) for SPH particles
+* esph = energy (need units) for SPH particles
 * edpd_temp = temperature for eDPD particles (temperature units)
 * edpd_cv = volumetric heat capacity for eDPD particles (energy/temperature/volume units)
 * ellipsoidflag = 1 for ellipsoidal particles, 0 for point particles
@@ -646,14 +647,15 @@ The per-atom values have these meanings and units, listed alphabetically:
 * q = charge on atom (charge units)
 * rho = density (need units) for SPH particles
 * spin = electron spin (+1/-1), 0 = nuclei, 2 = fixed-core, 3 = pseudo-cores (i.e. ECP)
-* sp = norm of magnetic spin of atom (in number of Bohr magnetons)
-* spx,spy,spz = components of magnetic spin of atom (adim normalized vector)
+* sp = magnitude of magnetic spin of atom (Bohr magnetons)
+* spx,spy,spz = components of magnetic spin of atom (unit vector)
 * template-atom = which atom within a template molecule the atom is
 * template-index = which molecule within the molecule template the atom is part of
 * theta = internal temperature of a DPD particle
 * triangleflag = 1 for triangular particles, 0 for point or spherical particles
 * volume = volume of Peridynamic particle (distance\^3 units)
 * x,y,z = coordinates of atom (distance units)
+* x0,y0,z0 = original (strain-free) coordinates of atom (distance units)
 
 The units for these quantities depend on the unit style; see the
 :doc:`units <units>` command for details.
@@ -715,17 +717,18 @@ as spheres when converting density to mass.  However, they can also be
 modeled as 2d discs (circles) if the :doc:`set density/disc <set>`
 command is used to reset their mass after the read_data command is
 used.  A *disc* keyword can also be used with time integration fixes,
-such as :doc:`fix nve/sphere <fix_nve_sphere>` and :doc:`fix nvt/sphere <fix_nve_sphere>` to time integrate their motion as 2d
+such as :doc:`fix nve/sphere <fix_nve_sphere>` and :doc:`fix
+nvt/sphere <fix_nve_sphere>` to time integrate their motion as 2d
 discs (not 3d spheres), by changing their moment of inertia.
 
-For atom_style hybrid, following the 5 initial values (ID,type,x,y,z),
-specific values for each sub-style must be listed.  The order of the
-sub-styles is the same as they were listed in the
-:doc:`atom_style <atom_style>` command.  The sub-style specific values
-are those that are not the 5 standard ones (ID,type,x,y,z).  For
-example, for the "charge" sub-style, a "q" value would appear.  For
-the "full" sub-style, a "molecule-ID" and "q" would appear.  These are
-listed in the same order they appear as listed above.  Thus if
+For atom\_style hybrid, following the 5 initial values
+(ID,type,x,y,z), specific values for each sub-style must be listed.
+The order of the sub-styles is the same as they were listed in the
+:doc:`atom_style <atom_style>` command.  The specific values for each
+sub-style are those that are not the 5 standard ones (ID,type,x,y,z).
+For example, for the "charge" sub-style, a "q" value would appear.
+For the "full" sub-style, a "molecule-ID" and "q" would appear.  These
+are listed in the same order they appear as listed above.  Thus if
 
 .. parsed-literal::
 
@@ -738,12 +741,14 @@ were used in the input script, each atom line would have these fields:
    atom-ID atom-type x y z q diameter density
 
 Note that if a non-standard value is defined by multiple sub-styles,
-it must appear multiple times in the atom line.  E.g. the atom line
-for atom_style hybrid dipole full would list "q" twice:
+it only appears once in the atom line.  E.g. the atom line for
+atom_style hybrid dipole full would list "q" only once, with the
+dipole sub-style fields; "q" does not appear with the full sub-style
+fields.
 
 .. parsed-literal::
 
-   atom-ID atom-type x y z q mux muy myz molecule-ID q
+   atom-ID atom-type x y z q mux muy myz molecule-ID
 
 Atom lines specify the (x,y,z) coordinates of atoms.  These can be
 inside or outside the simulation box.  When the data file is read,
@@ -1176,9 +1181,9 @@ pair style.  See the :doc:`pair_style <pair_style>` and
 :doc:`pair_coeff <pair_coeff>` commands for details.  Since pair
 coefficients for types I != J are not specified, these will be
 generated automatically by the pair style's mixing rule.  See the
-individual pair_style doc pages and the :doc:`pair_modify mix <pair_modify>` command for details.  Pair coefficients can also
-be set via the :doc:`pair_coeff <pair_coeff>` command in the input
-script.
+individual pair_style doc pages and the :doc:`pair_modify mix
+<pair_modify>` command for details.  Pair coefficients can also be set
+via the :doc:`pair_coeff <pair_coeff>` command in the input script.
 
 ----------
 
@@ -1200,15 +1205,15 @@ script.
        3 3 0.022 2.35197 0.022 2.35197
        3 5 0.022 2.35197 0.022 2.35197
 
-This section must have N\*(N+1)/2 lines where N = # of atom types.  The
-number and meaning of the coefficients are specific to the defined
+This section must have N\*(N+1)/2 lines where N = # of atom types.
+The number and meaning of the coefficients are specific to the defined
 pair style.  See the :doc:`pair_style <pair_style>` and
 :doc:`pair_coeff <pair_coeff>` commands for details.  Since pair
 coefficients for types I != J are all specified, these values will
 turn off the default mixing rule defined by the pair style.  See the
-individual pair_style doc pages and the :doc:`pair_modify mix <pair_modify>` command for details.  Pair coefficients can also
-be set via the :doc:`pair_coeff <pair_coeff>` command in the input
-script.
+individual pair_style doc pages and the :doc:`pair_modify mix
+<pair_modify>` command for details.  Pair coefficients can also be set
+via the :doc:`pair_coeff <pair_coeff>` command in the input script.
 
 ----------
 

doc/src/run_style.rst

@@ -150,8 +150,8 @@ timestep, angle interactions computed 4x, pair interactions computed
 
 The :doc:`timestep <timestep>` command sets the large timestep for the
 outermost rRESPA level.  Thus if the 3 loop factors are "2 2 2" for
-4-level rRESPA, and the outer timestep is set to 4.0 fmsec, then the
-inner timestep would be 8x smaller or 0.5 fmsec.  All other LAMMPS
+4-level rRESPA, and the outer timestep is set to 4.0 fs, then the
+inner timestep would be 8x smaller or 0.5 fs.  All other LAMMPS
 commands that specify number of timesteps (e.g. :doc:`thermo <thermo>`
 for thermo output every N steps, :doc:`neigh_modify delay/every <neigh_modify>` parameters, :doc:`dump <dump>` every N
 steps, etc) refer to the outermost timesteps.
@@ -213,10 +213,10 @@ With that caveat, a few rules-of-thumb may be useful in selecting
 simulations using the CHARMM or a similar all-atom force field, but
 the concepts are adaptable to other problems.  Without SHAKE, bonds
 involving hydrogen atoms exhibit high-frequency vibrations and require
-a timestep on the order of 0.5 fmsec in order to conserve energy.  The
+a timestep on the order of 0.5 fs in order to conserve energy.  The
 relatively inexpensive force computations for the bonds, angles,
-impropers, and dihedrals can be computed on this innermost 0.5 fmsec
-step.  The outermost timestep cannot be greater than 4.0 fmsec without
+impropers, and dihedrals can be computed on this innermost 0.5 fs
+step.  The outermost timestep cannot be greater than 4.0 fs without
 risking energy drift.  Smooth switching of forces between the levels
 of the rRESPA hierarchy is also necessary to avoid drift, and a 1-2
 angstrom "healing distance" (the distance between the outer and inner
@@ -230,14 +230,14 @@ simulations:
    run_style respa 4 2 2 2 inner 2 4.5 6.0 middle 3 8.0 10.0 outer 4
 
 With these settings, users can expect good energy conservation and
-roughly a 2.5 fold speedup over the *verlet* style with a 0.5 fmsec
+roughly a 2.5 fold speedup over the *verlet* style with a 0.5 fs
 timestep.
 
 If SHAKE is used with the *respa* style, time reversibility is lost,
 but substantially longer time steps can be achieved.  For biomolecular
 simulations using the CHARMM or similar all-atom force field, bonds
 involving hydrogen atoms exhibit high frequency vibrations and require
-a time step on the order of 0.5 fmsec in order to conserve energy.
+a time step on the order of 0.5 fs in order to conserve energy.
 These high frequency modes also limit the outer time step sizes since
 the modes are coupled.  It is therefore desirable to use SHAKE with
 respa in order to freeze out these high frequency motions and increase
@@ -253,7 +253,7 @@ rRESPA:
 
 With these settings, users can expect good energy conservation and
 roughly a 1.5 fold speedup over the *verlet* style with SHAKE and a
-2.0 fmsec timestep.
+2.0 fs timestep.
 
 For non-biomolecular simulations, the *respa* style can be
 advantageous if there is a clear separation of time scales - fast and

doc/src/set.rst

@@ -13,7 +13,7 @@ Syntax
 * style = *atom* or *type* or *mol* or *group* or *region*
 * ID = atom ID range or type range or mol ID range or group ID or region ID
 * one or more keyword/value pairs may be appended
-* keyword = *type* or *type/fraction* or *type/ratio* or *type/subset* or *mol* or *x* or *y* or *z* or           *charge* or *dipole* or *dipole/random* or *quat* or           *spin* or *spin/random* or *quat* or           *quat/random* or *diameter* or *shape* or           *length* or *tri* or *theta* or *theta/random* or           *angmom* or *omega* or           *mass* or *density* or *density/disc* or *volume* or *image* or           *bond* or *angle* or *dihedral* or *improper* or           *meso/e* or *meso/cv* or *meso/rho* or           *smd/contact/radius* or *smd/mass/density* or *dpd/theta* or           *edpd/temp* or *edpd/cv* or *cc* or *i_name* or *d_name*
+* keyword = *type* or *type/fraction* or *type/ratio* or *type/subset* or *mol* or *x* or *y* or *z* or           *charge* or *dipole* or *dipole/random* or *quat* or           *spin* or *spin/random* or *quat* or           *quat/random* or *diameter* or *shape* or           *length* or *tri* or *theta* or *theta/random* or           *angmom* or *omega* or           *mass* or *density* or *density/disc* or *volume* or *image* or           *bond* or *angle* or *dihedral* or *improper* or           *sph/e* or *sph/cv* or *sph/rho* or           *smd/contact/radius* or *smd/mass/density* or *dpd/theta* or           *edpd/temp* or *edpd/cv* or *cc* or *i_name* or *d_name*
 
   .. parsed-literal::
 
@@ -94,11 +94,11 @@ Syntax
        *angle* value = angle type for all angles between selected atoms
        *dihedral* value = dihedral type for all dihedrals between selected atoms
        *improper* value = improper type for all impropers between selected atoms
-       *meso/e* value = energy of SPH particles (need units)
+       *sph/e* value = energy of SPH particles (need units)
          value can be an atom-style variable (see below)
-       *meso/cv* value = heat capacity of SPH particles (need units)
+       *sph/cv* value = heat capacity of SPH particles (need units)
          value can be an atom-style variable (see below)
-       *meso/rho* value = density of SPH particles (need units)
+       *sph/rho* value = density of SPH particles (need units)
          value can be an atom-style variable (see below)
        *smd/contact/radius* = radius for short range interactions, i.e. contact and friction
          value can be an atom-style variable (see below)
@@ -299,29 +299,31 @@ for each particle set by this command.  This keyword does not allow
 use of an atom-style variable.
 
 Keyword *diameter* sets the size of the selected atoms.  The particles
-must be finite-size spheres as defined by the :doc:`atom_style sphere <atom_style>` command.  The diameter of a particle can be
-set to 0.0, which means they will be treated as point particles.  Note
-that this command does not adjust the particle mass, even if it was
-defined with a density, e.g. via the :doc:`read_data <read_data>`
-command.
+must be finite-size spheres as defined by the :doc:`atom_style sphere
+<atom_style>` command.  The diameter of a particle can be set to 0.0,
+which means they will be treated as point particles.  Note that this
+command does not adjust the particle mass, even if it was defined with
+a density, e.g. via the :doc:`read_data <read_data>` command.
 
 Keyword *shape* sets the size and shape of the selected atoms.  The
-particles must be ellipsoids as defined by the :doc:`atom_style ellipsoid <atom_style>` command.  The *Sx*\ , *Sy*\ , *Sz* settings are
-the 3 diameters of the ellipsoid in each direction.  All 3 can be set
-to the same value, which means the ellipsoid is effectively a sphere.
-They can also all be set to 0.0 which means the particle will be
-treated as a point particle.  Note that this command does not adjust
-the particle mass, even if it was defined with a density, e.g. via the
-:doc:`read_data <read_data>` command.
+particles must be ellipsoids as defined by the :doc:`atom_style
+ellipsoid <atom_style>` command.  The *Sx*\ , *Sy*\ , *Sz* settings
+are the 3 diameters of the ellipsoid in each direction.  All 3 can be
+set to the same value, which means the ellipsoid is effectively a
+sphere.  They can also all be set to 0.0 which means the particle will
+be treated as a point particle.  Note that this command does not
+adjust the particle mass, even if it was defined with a density,
+e.g. via the :doc:`read_data <read_data>` command.
 
 Keyword *length* sets the length of selected atoms.  The particles
-must be line segments as defined by the :doc:`atom_style line <atom_style>` command.  If the specified value is non-zero the
-line segment is (re)set to a length = the specified value, centered
-around the particle position, with an orientation along the x-axis.
-If the specified value is 0.0, the particle will become a point
-particle.  Note that this command does not adjust the particle mass,
-even if it was defined with a density, e.g. via the
-:doc:`read_data <read_data>` command.
+must be line segments as defined by the :doc:`atom_style line
+<atom_style>` command.  If the specified value is non-zero the line
+segment is (re)set to a length = the specified value, centered around
+the particle position, with an orientation along the x-axis.  If the
+specified value is 0.0, the particle will become a point particle.
+Note that this command does not adjust the particle mass, even if it
+was defined with a density, e.g. via the :doc:`read_data <read_data>`
+command.
 
 Keyword *tri* sets the size of selected atoms.  The particles must be
 triangles as defined by the :doc:`atom_style tri <atom_style>` command.
@@ -335,7 +337,8 @@ does not adjust the particle mass, even if it was defined with a
 density, e.g. via the :doc:`read_data <read_data>` command.
 
 Keyword *theta* sets the orientation of selected atoms.  The particles
-must be line segments as defined by the :doc:`atom_style line <atom_style>` command.  The specified value is used to set the
+must be line segments as defined by the :doc:`atom_style line
+<atom_style>` command.  The specified value is used to set the
 orientation angle of the line segments with respect to the x axis.
 
 Keyword *theta/random* randomizes the orientation of theta for the
@@ -346,44 +349,47 @@ regardless of how many processors are being used.  This keyword does
 not allow use of an atom-style variable.
 
 Keyword *angmom* sets the angular momentum of selected atoms.  The
-particles must be ellipsoids as defined by the :doc:`atom_style ellipsoid <atom_style>` command or triangles as defined by the
-:doc:`atom_style tri <atom_style>` command.  The angular momentum vector
-of the particles is set to the 3 specified components.
+particles must be ellipsoids as defined by the :doc:`atom_style
+ellipsoid <atom_style>` command or triangles as defined by the
+:doc:`atom_style tri <atom_style>` command.  The angular momentum
+vector of the particles is set to the 3 specified components.
 
 Keyword *omega* sets the angular velocity of selected atoms.  The
-particles must be spheres as defined by the
-:doc:`atom_style sphere <atom_style>` command.  The angular velocity
-vector of the particles is set to the 3 specified components.
+particles must be spheres as defined by the :doc:`atom_style sphere
+<atom_style>` command.  The angular velocity vector of the particles
+is set to the 3 specified components.
 
 Keyword *mass* sets the mass of all selected particles.  The particles
 must have a per-atom mass attribute, as defined by the
-:doc:`atom_style <atom_style>` command.  See the "mass" command for how
-to set mass values on a per-type basis.
+:doc:`atom_style <atom_style>` command.  See the "mass" command for
+how to set mass values on a per-type basis.
 
 Keyword *density* or *density/disc* also sets the mass of all selected
 particles, but in a different way.  The particles must have a per-atom
 mass attribute, as defined by the :doc:`atom_style <atom_style>`
-command.  If the atom has a radius attribute (see :doc:`atom_style sphere <atom_style>`) and its radius is non-zero, its mass is set
-from the density and particle volume for 3d systems (the input density
-is assumed to be in mass/distance\^3 units).  For 2d, the default is
-for LAMMPS to model particles with a radius attribute as spheres.
+command.  If the atom has a radius attribute (see :doc:`atom_style
+sphere <atom_style>`) and its radius is non-zero, its mass is set from
+the density and particle volume for 3d systems (the input density is
+assumed to be in mass/distance\^3 units).  For 2d, the default is for
+LAMMPS to model particles with a radius attribute as spheres.
 However, if the *density/disc* keyword is used, then they can be
 modeled as 2d discs (circles).  Their mass is set from the density and
 particle area (the input density is assumed to be in mass/distance\^2
 units).
 
-If the atom has a shape attribute (see :doc:`atom_style ellipsoid <atom_style>`) and its 3 shape parameters are non-zero,
-then its mass is set from the density and particle volume (the input
-density is assumed to be in mass/distance\^3 units).  The
-*density/disc* keyword has no effect; it does not (yet) treat 3d
-ellipsoids as 2d ellipses.
+If the atom has a shape attribute (see :doc:`atom_style ellipsoid
+<atom_style>`) and its 3 shape parameters are non-zero, then its mass
+is set from the density and particle volume (the input density is
+assumed to be in mass/distance\^3 units).  The *density/disc* keyword
+has no effect; it does not (yet) treat 3d ellipsoids as 2d ellipses.
 
-If the atom has a length attribute (see :doc:`atom_style line <atom_style>`) and its length is non-zero, then its mass is
-set from the density and line segment length (the input density is
-assumed to be in mass/distance units).  If the atom has an area
-attribute (see :doc:`atom_style tri <atom_style>`) and its area is
-non-zero, then its mass is set from the density and triangle area (the
-input density is assumed to be in mass/distance\^2 units).
+If the atom has a length attribute (see :doc:`atom_style line
+<atom_style>`) and its length is non-zero, then its mass is set from
+the density and line segment length (the input density is assumed to
+be in mass/distance units).  If the atom has an area attribute (see
+:doc:`atom_style tri <atom_style>`) and its area is non-zero, then its
+mass is set from the density and triangle area (the input density is
+assumed to be in mass/distance\^2 units).
 
 If none of these cases are valid, then the mass is set to the density
 value directly (the input density is assumed to be in mass units).
@@ -399,14 +405,15 @@ defined.  A value of 2 means add 2 box lengths to get the true value.
 A value of -1 means subtract 1 box length to get the true value.
 LAMMPS updates these flags as atoms cross periodic boundaries during
 the simulation.  The flags can be output with atom snapshots via the
-:doc:`dump <dump>` command.  If a value of NULL is specified for any of
-nx,ny,nz, then the current image value for that dimension is unchanged.
-For non-periodic dimensions only a value of 0 can be specified.
-This command can be useful after a system has been equilibrated and
-atoms have diffused one or more box lengths in various directions.
-This command can then reset the image values for atoms so that they
-are effectively inside the simulation box, e.g if a diffusion
-coefficient is about to be measured via the :doc:`compute msd <compute_msd>` command.  Care should be taken not to reset the
+:doc:`dump <dump>` command.  If a value of NULL is specified for any
+of nx,ny,nz, then the current image value for that dimension is
+unchanged.  For non-periodic dimensions only a value of 0 can be
+specified.  This command can be useful after a system has been
+equilibrated and atoms have diffused one or more box lengths in
+various directions.  This command can then reset the image values for
+atoms so that they are effectively inside the simulation box, e.g if a
+diffusion coefficient is about to be measured via the :doc:`compute
+msd <compute_msd>` command.  Care should be taken not to reset the
 image flags of two atoms in a bond to the same value if the bond
 straddles a periodic boundary (rather they should be different by +/-
 1).  This will not affect the dynamics of a simulation, but may mess
@@ -423,10 +430,10 @@ etc) was set by the *bond types* (\ *angle types*\ , etc) field in the
 header of the data file read by the :doc:`read_data <read_data>`
 command.  These keywords do not allow use of an atom-style variable.
 
-Keywords *meso/e*\ , *meso/cv*\ , and *meso/rho* set the energy, heat
+Keywords *sph/e*\ , *sph/cv*\ , and *sph/rho* set the energy, heat
 capacity, and density of smoothed particle hydrodynamics (SPH)
-particles.  See `this PDF guide <USER/sph/SPH_LAMMPS_userguide.pdf>`_ to
-using SPH in LAMMPS.
+particles.  See `this PDF guide <USER/sph/SPH_LAMMPS_userguide.pdf>`_
+to using SPH in LAMMPS.
 
 Keyword *smd/mass/density* sets the mass of all selected particles,
 but it is only applicable to the Smooth Mach Dynamics package