Merge pull request #1207 from akohlmey/next-patch-release

Patch release 15 November 2018

.github/CODEOWNERS

@@ -17,6 +17,7 @@ src/GPU/*             @ndtrung81
 src/KOKKOS/*          @stanmoore1
 src/KIM/*             @ellio167
 src/LATTE/*           @cnegre
+src/MESSAGE/*         @sjplimp
 src/SPIN/*            @julient31
 src/USER-CGDNA/*      @ohenrich
 src/USER-CGSDK/*      @akohlmey
@@ -28,20 +29,88 @@ src/USER-MEAMC/*      @martok
 src/USER-MOFFF/*      @hheenen
 src/USER-MOLFILE/*    @akohlmey
 src/USER-NETCDF/*     @pastewka
+src/USER-PLUMED/*     @gtribello
 src/USER-PHONON/*     @lingtikong
+src/USER-PTM/*        @pmla
 src/USER-OMP/*        @akohlmey
 src/USER-QMMM/*       @akohlmey
 src/USER-REAXC/*      @hasanmetin
+src/USER-SCAFACOS/*   @rhalver
 src/USER-TALLY/*      @akohlmey
 src/USER-UEF/*        @danicholson
 src/USER-VTK/*        @rbberger
 
+
 # individual files in packages
 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-MISC/*_grem.*              @dstelter92
+src/USER-MISC/compute_stress_mop*.* @RomainVermorel
+
+# core LAMMPS classes
+src/lammps.*              @sjplimp
+src/pointers.h            @sjplimp
+src/atom.*                @sjplimp
+src/atom_vec.*            @sjplimp
+src/angle.*               @sjplimp
+src/bond.*                @sjplimp
+src/comm*.*               @sjplimp
+src/compute.*             @sjplimp
+src/dihedral.*            @sjplimp
+src/domain.*              @sjplimp
+src/dump*.*               @sjplimp
+src/error.*               @sjplimp
+src/finish.*              @sjplimp
+src/fix.*                 @sjplimp
+src/force.*               @sjplimp
+src/group.*               @sjplimp
+src/improper.*            @sjplimp
+src/kspace.*              @sjplimp
+src/lmptyp.h              @sjplimp
+src/library.*             @sjplimp
+src/main.cpp              @sjplimp
+src/memory.*              @sjplimp
+src/modify.*              @sjplimp
+src/molecule.*            @sjplimp
+src/my_page.h             @sjplimp
+src/my_pool_chunk.h       @sjplimp
+src/npair*.*              @sjplimp
+src/ntopo*.*              @sjplimp
+src/nstencil*.*           @sjplimp
+src/neighbor.*            @sjplimp
+src/nbin*.*               @sjplimp
+src/neigh_*.*             @sjplimp
+src/output.*              @sjplimp
+src/pair.*                @sjplimp
+src/rcb.*                 @sjplimp
+src/random_*.*            @sjplimp
+src/region*.*             @sjplimp
+src/rcb.*                 @sjplimp
+src/read*.*               @sjplimp
+src/rerun.*               @sjplimp
+src/run.*                 @sjplimp
+src/respa.*               @sjplimp
+src/set.*                 @sjplimp
+src/special.*             @sjplimp
+src/suffix.h              @sjplimp
+src/thermo.*              @sjplimp
+src/universe.*            @sjplimp
+src/update.*              @sjplimp
+src/variable.*            @sjplimp
+src/verlet.*              @sjplimp
+src/velocity.*            @sjplimp
+src/write_data.*          @sjplimp
+src/write_restart.*       @sjplimp
+
+# overrides for specific files
+src/dump_movie.*          @akohlmey
+src/exceptions.h          @rbberger
+src/fix_nh.*              @athomps
+src/info.*                @akohlmey @rbberger
+src/timer.*               @akohlmey
 
 # tools
 tools/msi2lmp/*       @akohlmey

.github/CONTRIBUTING.md

@@ -6,7 +6,7 @@ The following is a set of guidelines as well as explanations of policies and wor
 
 Thus please also have a look at:
 * [The Section on submitting new features for inclusion in LAMMPS of the Manual](http://lammps.sandia.gov/doc/Section_modify.html#mod-15)
-* [The LAMMPS GitHub Tutorial in the Manual](http://lammps.sandia.gov/doc/tutorial_github.html)
+* [The LAMMPS GitHub Tutorial in the Manual](http://lammps.sandia.gov/doc/Howto_github.html)
 
 ## Table of Contents
 
@@ -62,7 +62,7 @@ To be able to submit an issue on GitHub, you have to register for an account (fo
 
 We encourage users to submit new features or modifications for LAMMPS to the core developers so they can be added to the LAMMPS distribution. The preferred way to manage and coordinate this is by submitting a pull request at the LAMMPS project on GitHub. For any larger modifications or programming project, you are encouraged to contact the LAMMPS developers ahead of time, in order to discuss implementation strategies and coding guidelines, that will make it easier to integrate your contribution and result in less work for everybody involved. You are also encouraged to search through the list of open issues on GitHub and submit a new issue for a planned feature, so you would not duplicate the work of others (and possibly get scooped by them) or have your work duplicated by others.
 
-How quickly your contribution will be integrated depends largely on how much effort it will cause to integrate and test it, how much it requires changes to the core code base, and of how much interest it is to the larger LAMMPS community. Please see below for a checklist of typical requirements. Once you have prepared everything, see [this tutorial](http://lammps.sandia.gov/doc/tutorial_github.html)
+How quickly your contribution will be integrated depends largely on how much effort it will cause to integrate and test it, how much it requires changes to the core code base, and of how much interest it is to the larger LAMMPS community. Please see below for a checklist of typical requirements. Once you have prepared everything, see [this tutorial](http://lammps.sandia.gov/doc/Howto_github.html)
  for instructions on how to submit your changes or new files through a GitHub pull request
 
 Here is a checklist of steps you need to follow to submit a single file or user package for our consideration. Following these steps will save both you and us time. See existing files in packages in the source directory for examples. If you are uncertain, please ask on the lammps-users mailing list.
@@ -102,11 +102,11 @@ For bug reports, the next step is that one of the core LAMMPS developers will se
 
 ### Pull Requests
 
-For submitting pull requests, there is a [detailed tutorial](http://lammps.sandia.gov/doc/tutorial_github.html) in the LAMMPS manual. Thus only a brief breakdown of the steps is presented here.
+For submitting pull requests, there is a [detailed tutorial](http://lammps.sandia.gov/doc/Howto_github.html) in the LAMMPS manual. Thus only a brief breakdown of the steps is presented here. Please note, that the LAMMPS developers are still reviewing and trying to improve the process. If you are unsure about something, do not hesitate to post a question on the lammps-users mailing list or contact one fo the core LAMMPS developers.
 Immediately after the submission, the LAMMPS continuing integration server at ci.lammps.org will download your submitted branch and perform a simple compilation test, i.e. will test whether your submitted code can be compiled under various conditions. It will also do a check on whether your included documentation translates cleanly. Whether these tests are successful or fail will be recorded. If a test fails, please inspect the corresponding output on the CI server and take the necessary steps, if needed, so that the code can compile cleanly again. The test will be re-run each the pull request is updated with a push to the remote branch on GitHub.
 Next a LAMMPS core developer will self-assign and do an overall technical assessment of the submission. If you are not yet registered as a LAMMPS collaborator, you will receive an invitation for that.
 You may also receive comments and suggestions on the overall submission or specific details. If permitted, additional changes may be pushed into your pull request branch or a pull request may be filed in your LAMMPS fork on GitHub to include those changes.
 The LAMMPS developer may then decide to assign the pull request to another developer (e.g. when that developer is more knowledgeable about the submitted feature or enhancement or has written the modified code). It may also happen, that additional developers are requested to provide a review and approve the changes. For submissions, that may change the general behavior of LAMMPS, or where a possibility of unwanted side effects exists, additional tests may be requested by the assigned developer.
-If the assigned developer is satisfied and considers the submission ready for inclusion into LAMMPS, the pull request will be assigned to the LAMMPS lead developer, Steve Plimpton (@sjplimp), who will then have the final decision on whether the submission will be included, additional changes are required or it will be ultimately rejected. After the pull request is merged, you may delete the pull request branch in your personal LAMMPS fork.
-Since the learning curve for git is quite steep for efficiently managing remote repositories, local and remote branches, pull requests and more, do not hesitate to ask questions, if you are not sure about how to do certain steps that are asked of you. Even if the changes asked of you do not make sense to you, they may be important for the LAMMPS developers. Please also note, that these all are guidelines and not set in stone.
+If the assigned developer is satisfied and considers the submission ready for inclusion into LAMMPS, the pull request will receive approvals and be merged into the master branch by one of the core LAMMPS developers. After the pull request is merged, you may delete the feature branch used for the pull request in your personal LAMMPS fork.
+Since the learning curve for git is quite steep for efficiently managing remote repositories, local and remote branches, pull requests and more, do not hesitate to ask questions, if you are not sure about how to do certain steps that are asked of you. Even if the changes asked of you do not make sense to you, they may be important for the LAMMPS developers. Please also note, that these all are guidelines and nothing set in stone. So depending on the nature of the contribution, the workflow may be adjusted.
 

cmake/CMakeLists.txt

@@ -13,7 +13,7 @@ get_filename_component(LAMMPS_DOC_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../doc ABSOLUT
 
 
 # To avoid conflicts with the conventional Makefile build system, we build everything here
-file(GLOB LIB_SOURCES ${LAMMPS_SOURCE_DIR}/*.cpp)
+file(GLOB LIB_SOURCES ${LAMMPS_SOURCE_DIR}/[^.]*.cpp)
 file(GLOB LMP_SOURCES ${LAMMPS_SOURCE_DIR}/main.cpp)
 list(REMOVE_ITEM LIB_SOURCES ${LMP_SOURCES})
 
@@ -69,6 +69,8 @@ get_lammps_version(${LAMMPS_SOURCE_DIR}/version.h LAMMPS_VERSION)
 # Cmake modules/macros are in a subdirectory to keep this file cleaner
 set(CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/Modules)
 
+include(PreventInSourceBuilds)
+
 if(NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CXX_FLAGS)
   #release comes with -O3 by default
   set(CMAKE_BUILD_TYPE Release CACHE STRING "Choose the type of build, options are: None Debug Release RelWithDebInfo MinSizeRel." FORCE)
@@ -164,12 +166,14 @@ set(LAMMPS_DEPS)
 set(LAMMPS_API_DEFINES)
 
 set(DEFAULT_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS DIPOLE GRANULAR
-  KSPACE MANYBODY MC MEAM MESSAGE MISC MOLECULE PERI REAX REPLICA RIGID SHOCK SPIN SNAP
-  SRD KIM PYTHON MSCG MPIIO VORONOI POEMS LATTE USER-ATC USER-AWPMD USER-BOCS
-  USER-CGDNA USER-MESO USER-CGSDK USER-COLVARS USER-DIFFRACTION USER-DPD USER-DRUDE
-  USER-EFF USER-FEP USER-H5MD USER-LB USER-MANIFOLD USER-MEAMC USER-MGPT USER-MISC
-  USER-MOFFF USER-MOLFILE USER-NETCDF USER-PHONON USER-QTB USER-REAXC USER-SCAFACOS 
-  USER-SMD USER-SMTBQ USER-SPH USER-TALLY USER-UEF USER-VTK USER-QUIP USER-QMMM)
+  KSPACE MANYBODY MC MEAM MESSAGE MISC MOLECULE PERI REAX REPLICA RIGID SHOCK
+  SPIN SNAP SRD KIM PYTHON MSCG MPIIO VORONOI POEMS LATTE USER-ATC USER-AWPMD
+  USER-BOCS USER-CGDNA USER-MESO USER-CGSDK USER-COLVARS USER-DIFFRACTION
+  USER-DPD USER-DRUDE USER-EFF USER-FEP USER-H5MD USER-LB USER-MANIFOLD
+  USER-MEAMC USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE USER-NETCDF
+  USER-PHONON USER-PLUMED USER-PTM USER-QTB USER-REAXC USER-SCAFACOS
+  USER-SDPD USER-SMD USER-SMTBQ USER-SPH USER-TALLY USER-UEF USER-VTK
+  USER-QUIP USER-QMMM)
 set(ACCEL_PACKAGES USER-OMP KOKKOS OPT USER-INTEL GPU)
 set(OTHER_PACKAGES CORESHELL QEQ)
 foreach(PKG ${DEFAULT_PACKAGES})
@@ -190,6 +194,8 @@ if(PKG_MEAM OR PKG_USER-H5MD OR PKG_USER-QMMM OR PKG_USER-SCAFACOS)
   enable_language(C)
 endif()
 
+include_directories(${LAMMPS_SOURCE_DIR})
+
 # do MPI detection after language activation, if MPI for these language is required
 find_package(MPI QUIET)
 option(BUILD_MPI "Build MPI version" ${MPI_FOUND})
@@ -298,7 +304,7 @@ pkg_depends(USER-SCAFACOS MPI)
 
 find_package(OpenMP QUIET)
 option(BUILD_OMP "Build with OpenMP support" ${OpenMP_FOUND})
-if(BUILD_OMP OR PKG_USER-OMP OR PKG_KOKKOS OR PKG_USER-INTEL)
+if(BUILD_OMP OR PKG_KOKKOS OR PKG_USER-INTEL)
   find_package(OpenMP REQUIRED)
   set (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${OpenMP_C_FLAGS}")
   set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${OpenMP_CXX_FLAGS}")
@@ -343,12 +349,12 @@ if(PKG_KSPACE)
   endif()
 endif()
 
-if(PKG_MSCG OR PKG_USER-ATC OR PKG_USER-AWPMD OR PKG_USER-QUIP OR PKG_LATTE)
+if(PKG_MSCG OR PKG_USER-ATC OR PKG_USER-AWPMD OR PKG_USER-QUIP OR PKG_LATTE OR PKG_USER-PLUMED)
   find_package(LAPACK)
   find_package(BLAS)
   if(NOT LAPACK_FOUND OR NOT BLAS_FOUND)
     enable_language(Fortran)
-    file(GLOB LAPACK_SOURCES ${LAMMPS_LIB_SOURCE_DIR}/linalg/*.[fF])
+    file(GLOB LAPACK_SOURCES ${LAMMPS_LIB_SOURCE_DIR}/linalg/[^.]*.[fF])
     add_library(linalg STATIC ${LAPACK_SOURCES})
     set(LAPACK_LIBRARIES linalg)
   else()
@@ -523,6 +529,54 @@ if(PKG_USER-SCAFACOS)
   include_directories(${SCAFACOS_INCLUDE_DIRS})
 endif()
 
+if(PKG_USER-PLUMED)
+  find_package(GSL REQUIRED)
+  set(PLUMED_MODE "static" CACHE STRING "Linkage mode for Plumed2 library")
+  set(PLUMED_MODE_VALUES static shared runtime)
+  set_property(CACHE PLUMED_MODE PROPERTY STRINGS ${PLUMED_MODE_VALUES})
+  validate_option(PLUMED_MODE PLUMED_MODE_VALUES)
+  string(TOUPPER ${PLUMED_MODE} PLUMED_MODE)
+
+  option(DOWNLOAD_PLUMED "Download Plumed (instead of using the system's one)" OFF)
+  if(DOWNLOAD_PLUMED)
+    include(ExternalProject)
+    ExternalProject_Add(plumed_build
+      URL https://github.com/plumed/plumed2/releases/download/v2.4.3/plumed-src-2.4.3.tgz 
+      URL_MD5 b1be7c48971627febc11c61b70767fc5
+      BUILD_IN_SOURCE 1
+      CONFIGURE_COMMAND <SOURCE_DIR>/configure --prefix=<INSTALL_DIR> 
+                                               $<$<BOOL:${BUILD_SHARED_LIBS}>:--with-pic>                                                  )
+    ExternalProject_get_property(plumed_build INSTALL_DIR)
+    set(PLUMED_INSTALL_DIR ${INSTALL_DIR})
+    list(APPEND LAMMPS_DEPS plumed_build)
+    if(PLUMED_MODE STREQUAL "STATIC")
+      add_definitions(-D__PLUMED_WRAPPER_CXX=1)
+      list(APPEND LAMMPS_LINK_LIBS ${PLUMED_INSTALL_DIR}/lib/plumed/obj/kernel.o
+        "${PLUMED_INSTALL_DIR}/lib/plumed/obj/PlumedStatic.o" ${GSL_LIBRARIES} ${CMAKE_DL_LIBS} ${LAPACK_LIBRARIES})
+    elseif(PLUMED_MODE STREQUAL "SHARED")
+      list(APPEND LAMMPS_LINK_LIBS ${PLUMED_INSTALL_DIR}/lib/libplumed.so ${CMAKE_DL_LIBS})
+    elseif(PLUMED_MODE STREQUAL "RUNTIME")
+      add_definitions(-D__PLUMED_HAS_DLOPEN=1 -D__PLUMED_DEFAULT_KERNEL=${PLUMED_INSTALL_DIR}/lib/libplumedKernel.so)
+      list(APPEND LAMMPS_LINK_LIBS ${PLUMED_INSTALL_DIR}/lib/libplumedWrapper.a -rdynamic ${CMAKE_DL_LIBS})
+    endif()
+    set(PLUMED_INCLUDE_DIRS "${PLUMED_INSTALL_DIR}/include")
+  else()
+    find_package(PkgConfig REQUIRED)
+    pkg_check_modules(PLUMED plumed REQUIRED)
+    if(PLUMED_MODE STREQUAL "STATIC")
+      add_definitions(-D__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")
+      add_definitions(-D__PLUMED_HAS_DLOPEN=1 -D__PLUMED_DEFAULT_KERNEL=${PLUMED_LIBDIR}/libplumedKernel.so)
+      include(${PLUMED_LIBDIR}/plumed/src/lib/Plumed.cmake.runtime)
+    endif()
+    list(APPEND LAMMPS_LINK_LIBS ${PLUMED_LOAD})
+  endif()
+  include_directories(${PLUMED_INCLUDE_DIRS})
+endif()
+
 if(PKG_USER-MOLFILE)
   add_library(molfile INTERFACE)
   target_include_directories(molfile INTERFACE ${LAMMPS_LIB_SOURCE_DIR}/molfile)
@@ -550,8 +604,9 @@ if(PKG_USER-SMD)
     set(EIGEN3_INCLUDE_DIR ${SOURCE_DIR})
     list(APPEND LAMMPS_DEPS Eigen3_build)
   else()
-    find_package(Eigen3)
-    if(NOT Eigen3_FOUND)
+    find_package(Eigen3 NO_MODULE)
+    mark_as_advanced(Eigen3_DIR)
+    if(NOT EIGEN3_FOUND)
       message(FATAL_ERROR "Eigen3 not found, help CMake to find it by setting EIGEN3_INCLUDE_DIR, or set DOWNLOAD_EIGEN3=ON to download it")
     endif()
   endif()
@@ -603,8 +658,9 @@ endif()
 
 if(PKG_MESSAGE)
   option(MESSAGE_ZMQ "Use ZeroMQ in MESSAGE package" OFF)
-  file(GLOB_RECURSE cslib_SOURCES ${LAMMPS_LIB_SOURCE_DIR}/message/cslib/*.F
-      ${LAMMPS_LIB_SOURCE_DIR}/message/cslib/*.c ${LAMMPS_LIB_SOURCE_DIR}/message/cslib/*.cpp)
+  file(GLOB_RECURSE cslib_SOURCES ${LAMMPS_LIB_SOURCE_DIR}/message/cslib/[^.]*.F
+      ${LAMMPS_LIB_SOURCE_DIR}/message/cslib/[^.]*.c
+      ${LAMMPS_LIB_SOURCE_DIR}/message/cslib/[^.]*.cpp)
 
   if(BUILD_SHARED_LIBS)
       add_library(cslib SHARED ${cslib_SOURCES})
@@ -720,8 +776,8 @@ RegisterStyles(${LAMMPS_SOURCE_DIR})
 foreach(PKG ${DEFAULT_PACKAGES})
   set(${PKG}_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/${PKG})
 
-  file(GLOB ${PKG}_SOURCES ${${PKG}_SOURCES_DIR}/*.cpp)
-  file(GLOB ${PKG}_HEADERS ${${PKG}_SOURCES_DIR}/*.h)
+  file(GLOB ${PKG}_SOURCES ${${PKG}_SOURCES_DIR}/[^.]*.cpp)
+  file(GLOB ${PKG}_HEADERS ${${PKG}_SOURCES_DIR}/[^.]*.h)
 
   # check for package files in src directory due to old make system
   DetectBuildSystemConflict(${LAMMPS_SOURCE_DIR} ${${PKG}_SOURCES} ${${PKG}_HEADERS})
@@ -739,8 +795,8 @@ endforeach()
 foreach(PKG ${ACCEL_PACKAGES})
   set(${PKG}_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/${PKG})
 
-  file(GLOB ${PKG}_SOURCES ${${PKG}_SOURCES_DIR}/*.cpp)
-  file(GLOB ${PKG}_HEADERS ${${PKG}_SOURCES_DIR}/*.h)
+  file(GLOB ${PKG}_SOURCES ${${PKG}_SOURCES_DIR}/[^.]*.cpp)
+  file(GLOB ${PKG}_HEADERS ${${PKG}_SOURCES_DIR}/[^.]*.h)
 
   # check for package files in src directory due to old make system
   DetectBuildSystemConflict(${LAMMPS_SOURCE_DIR} ${${PKG}_SOURCES} ${${PKG}_HEADERS})
@@ -754,8 +810,10 @@ foreach(SIMPLE_LIB REAX MEAM POEMS USER-ATC USER-AWPMD USER-COLVARS USER-H5MD
   if(PKG_${SIMPLE_LIB})
     string(REGEX REPLACE "^USER-" "" PKG_LIB "${SIMPLE_LIB}")
     string(TOLOWER "${PKG_LIB}" PKG_LIB)
-    file(GLOB_RECURSE ${PKG_LIB}_SOURCES ${LAMMPS_LIB_SOURCE_DIR}/${PKG_LIB}/*.F
-      ${LAMMPS_LIB_SOURCE_DIR}/${PKG_LIB}/*.c ${LAMMPS_LIB_SOURCE_DIR}/${PKG_LIB}/*.cpp)
+    file(GLOB_RECURSE ${PKG_LIB}_SOURCES
+      ${LAMMPS_LIB_SOURCE_DIR}/${PKG_LIB}/[^.]*.F
+      ${LAMMPS_LIB_SOURCE_DIR}/${PKG_LIB}/[^.]*.c
+      ${LAMMPS_LIB_SOURCE_DIR}/${PKG_LIB}/[^.]*.cpp)
     add_library(${PKG_LIB} STATIC ${${PKG_LIB}_SOURCES})
     list(APPEND LAMMPS_LINK_LIBS ${PKG_LIB})
     if(PKG_LIB STREQUAL awpmd)
@@ -830,6 +888,7 @@ if(PKG_USER-OMP)
     set(USER-OMP_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/USER-OMP)
     set(USER-OMP_SOURCES ${USER-OMP_SOURCES_DIR}/thr_data.cpp
                          ${USER-OMP_SOURCES_DIR}/thr_omp.cpp
+                         ${USER-OMP_SOURCES_DIR}/fix_omp.cpp
                          ${USER-OMP_SOURCES_DIR}/fix_nh_omp.cpp
                          ${USER-OMP_SOURCES_DIR}/fix_nh_sphere_omp.cpp
                          ${USER-OMP_SOURCES_DIR}/domain_omp.cpp)
@@ -838,7 +897,7 @@ if(PKG_USER-OMP)
 
     # detects styles which have USER-OMP version
     RegisterStylesExt(${USER-OMP_SOURCES_DIR} omp OMP_SOURCES)
-
+    RegisterFixStyle("${USER-OMP_SOURCES_DIR}/fix_omp.h")
 
     get_property(USER-OMP_SOURCES GLOBAL PROPERTY OMP_SOURCES)
 
@@ -868,6 +927,20 @@ if(PKG_USER-OMP)
     include_directories(${USER-OMP_SOURCES_DIR})
 endif()
 
+# Fix rigid/meso requires RIGID to be installed
+if(PKG_USER-SDPD)
+  set(USER-SDPD_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/USER-SDPD)
+
+  get_property(hlist GLOBAL PROPERTY FIX)
+  if(NOT PKG_RIGID)
+    list(REMOVE_ITEM hlist ${USER-SDPD_SOURCES_DIR}/fix_rigid_meso.h)
+    list(REMOVE_ITEM LIB_SOURCES ${USER-SDPD_SOURCES_DIR}/fix_rigid_meso.cpp)
+  endif()
+  set_property(GLOBAL PROPERTY FIX "${hlist}")
+
+  include_directories(${USER-SDPD_SOURCES_DIR})
+endif()
+
 if(PKG_KOKKOS)
   set(LAMMPS_LIB_KOKKOS_SRC_DIR ${LAMMPS_LIB_SOURCE_DIR}/kokkos)
   set(LAMMPS_LIB_KOKKOS_BIN_DIR ${LAMMPS_LIB_BINARY_DIR}/kokkos)
@@ -1038,7 +1111,7 @@ if(PKG_GPU)
       set(GPU_PREC_SETTING "SINGLE_SINGLE")
     endif()
 
-    file(GLOB GPU_LIB_SOURCES ${LAMMPS_LIB_SOURCE_DIR}/gpu/*.cpp)
+    file(GLOB GPU_LIB_SOURCES ${LAMMPS_LIB_SOURCE_DIR}/gpu/[^.]*.cpp)
     file(MAKE_DIRECTORY ${LAMMPS_LIB_BINARY_DIR}/gpu)
 
     if(GPU_API STREQUAL "CUDA")
@@ -1051,15 +1124,15 @@ if(PKG_GPU)
 
       set(GPU_ARCH "sm_30" CACHE STRING "LAMMPS GPU CUDA SM architecture (e.g. sm_60)")
 
-      file(GLOB GPU_LIB_CU ${LAMMPS_LIB_SOURCE_DIR}/gpu/*.cu ${CMAKE_CURRENT_SOURCE_DIR}/gpu/*.cu)
+      file(GLOB GPU_LIB_CU ${LAMMPS_LIB_SOURCE_DIR}/gpu/[^.]*.cu ${CMAKE_CURRENT_SOURCE_DIR}/gpu/[^.]*.cu)
       list(REMOVE_ITEM GPU_LIB_CU ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_pppm.cu)
 
       cuda_include_directories(${LAMMPS_LIB_SOURCE_DIR}/gpu ${LAMMPS_LIB_BINARY_DIR}/gpu)
 
       if(CUDPP_OPT)
         cuda_include_directories(${LAMMPS_LIB_SOURCE_DIR}/gpu/cudpp_mini)
-        file(GLOB GPU_LIB_CUDPP_SOURCES ${LAMMPS_LIB_SOURCE_DIR}/gpu/cudpp_mini/*.cpp)
-        file(GLOB GPU_LIB_CUDPP_CU ${LAMMPS_LIB_SOURCE_DIR}/gpu/cudpp_mini/*.cu)
+        file(GLOB GPU_LIB_CUDPP_SOURCES ${LAMMPS_LIB_SOURCE_DIR}/gpu/cudpp_mini/[^.]*.cpp)
+        file(GLOB GPU_LIB_CUDPP_CU ${LAMMPS_LIB_SOURCE_DIR}/gpu/cudpp_mini/[^.]*.cu)
       endif()
 
       cuda_compile_cubin(GPU_GEN_OBJS ${GPU_LIB_CU} OPTIONS
@@ -1108,7 +1181,7 @@ if(PKG_GPU)
       include(OpenCLUtils)
       set(OCL_COMMON_HEADERS ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_preprocessor.h ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_aux_fun1.h)
 
-      file(GLOB GPU_LIB_CU ${LAMMPS_LIB_SOURCE_DIR}/gpu/*.cu)
+      file(GLOB GPU_LIB_CU ${LAMMPS_LIB_SOURCE_DIR}/gpu/[^.]*.cu)
       list(REMOVE_ITEM GPU_LIB_CU ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_gayberne.cu ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_gayberne_lj.cu)
 
       foreach(GPU_KERNEL ${GPU_LIB_CU})
@@ -1158,7 +1231,6 @@ set(LAMMPS_STYLE_HEADERS_DIR ${CMAKE_CURRENT_BINARY_DIR}/styles)
 
 GenerateStyleHeaders(${LAMMPS_STYLE_HEADERS_DIR})
 
-include_directories(${LAMMPS_SOURCE_DIR})
 include_directories(${LAMMPS_STYLE_HEADERS_DIR})
 
 ######################################
@@ -1235,7 +1307,7 @@ if(BUILD_DOC)
 
   set(VIRTUALENV ${PYTHON_EXECUTABLE} -m virtualenv)
 
-  file(GLOB DOC_SOURCES ${LAMMPS_DOC_DIR}/src/*.txt)
+  file(GLOB DOC_SOURCES ${LAMMPS_DOC_DIR}/src/[^.]*.txt)
   file(GLOB PDF_EXTRA_SOURCES ${LAMMPS_DOC_DIR}/src/lammps_commands*.txt ${LAMMPS_DOC_DIR}/src/lammps_support.txt ${LAMMPS_DOC_DIR}/src/lammps_tutorials.txt)
   list(REMOVE_ITEM DOC_SOURCES ${PDF_EXTRA_SOURCES})
 

cmake/Modules/PreventInSourceBuilds.cmake

@@ -0,0 +1,23 @@
+# - Prevent in-source builds.
+# https://stackoverflow.com/questions/1208681/with-cmake-how-would-you-disable-in-source-builds/
+
+function(prevent_in_source_builds)
+  # make sure the user doesn't play dirty with symlinks
+  get_filename_component(srcdir "${CMAKE_SOURCE_DIR}" REALPATH)
+  get_filename_component(srcdir2 "${CMAKE_SOURCE_DIR}/.." REALPATH)
+  get_filename_component(srcdir3 "${CMAKE_SOURCE_DIR}/../src" REALPATH)
+  get_filename_component(bindir "${CMAKE_BINARY_DIR}" REALPATH)
+
+  # disallow in-source builds
+  if("${srcdir}" STREQUAL "${bindir}" OR "${srcdir2}" STREQUAL "${bindir}" OR "${srcdir3}" STREQUAL "${bindir}")
+    message(FATAL_ERROR "\
+
+CMake must not to be run in the source directory. \
+Rather create a dedicated build directory and run CMake there. \
+To clean up after this aborted in-place compilation:
+  rm -r CMakeCache.txt CMakeFiles
+")
+  endif()
+endfunction()
+
+prevent_in_source_builds()

cmake/Modules/StyleHeaderUtils.cmake

@@ -85,19 +85,23 @@ function(RegisterNPairStyle path)
     AddStyleHeader(${path} NPAIR)
 endfunction(RegisterNPairStyle)
 
+function(RegisterFixStyle path)
+    AddStyleHeader(${path} FIX)
+endfunction(RegisterFixStyle)
+
 function(RegisterStyles search_path)
     FindStyleHeaders(${search_path} ANGLE_CLASS     angle_     ANGLE     ) # angle     ) # force
     FindStyleHeaders(${search_path} ATOM_CLASS      atom_vec_  ATOM_VEC  ) # atom      ) # atom      atom_vec_hybrid
     FindStyleHeaders(${search_path} BODY_CLASS      body_      BODY      ) # body      ) # atom_vec_body
     FindStyleHeaders(${search_path} BOND_CLASS      bond_      BOND      ) # bond      ) # force
-    FindStyleHeaders(${search_path} COMMAND_CLASS   ""         COMMAND   ) # command   ) # input
+    FindStyleHeaders(${search_path} COMMAND_CLASS   "[^.]"     COMMAND   ) # command   ) # input
     FindStyleHeaders(${search_path} COMPUTE_CLASS   compute_   COMPUTE   ) # compute   ) # modify
     FindStyleHeaders(${search_path} DIHEDRAL_CLASS  dihedral_  DIHEDRAL  ) # dihedral  ) # force
     FindStyleHeaders(${search_path} DUMP_CLASS      dump_      DUMP      ) # dump      ) # output    write_dump
     FindStyleHeaders(${search_path} FIX_CLASS       fix_       FIX       ) # fix       ) # modify
     FindStyleHeaders(${search_path} IMPROPER_CLASS  improper_  IMPROPER  ) # improper  ) # force
-    FindStyleHeaders(${search_path} INTEGRATE_CLASS ""         INTEGRATE ) # integrate ) # update
-    FindStyleHeaders(${search_path} KSPACE_CLASS    ""         KSPACE    ) # kspace    ) # force
+    FindStyleHeaders(${search_path} INTEGRATE_CLASS "[^.]"     INTEGRATE ) # integrate ) # update
+    FindStyleHeaders(${search_path} KSPACE_CLASS    "[^.]"     KSPACE    ) # kspace    ) # force
     FindStyleHeaders(${search_path} MINIMIZE_CLASS  min_       MINIMIZE  ) # minimize  ) # update
     FindStyleHeaders(${search_path} NBIN_CLASS      nbin_      NBIN      ) # nbin      ) # neighbor
     FindStyleHeaders(${search_path} NPAIR_CLASS     npair_     NPAIR     ) # npair     ) # neighbor

cmake/README.md

@@ -1492,6 +1492,11 @@ target API.
   </dl>
   </td>
 </tr>
+<tr>
+  <td><code>BIN2C</code> (CUDA only)</td>
+  <td>Path to bin2c executable, will automatically pick up the first one in your $PATH.</td>
+  <td>(automatic)</td>
+</tr>
 </tbody>
 </table>
 
@@ -1647,9 +1652,8 @@ requires `gzip` to be in your `PATH`
 </tr>
 <tr>
   <td><code>GZIP_EXECUTABLE</code></td>
-  <td></td>
-  <td>
-  </td>
+  <td>Path to gzip executable, will automatically pick up the first one in your $PATH.</td>
+  <td>(automatic)</td>
 </tr>
 </tbody>
 </table>
@@ -1679,9 +1683,8 @@ requires `ffmpeg` to be in your `PATH`
 </tr>
 <tr>
   <td><code>FFMPEG_EXECUTABLE</code></td>
-  <td></td>
-  <td>
-  </td>
+  <td>Path to ffmpeg executable, will automatically pick up the first one in your $PATH.</td>
+  <td>(automatic)</td>
 </tr>
 </tbody>
 </table>

cmake/pkgconfig/liblammps.pc.in

@@ -1,9 +1,29 @@
 # pkg-config file for lammps
 # https://people.freedesktop.org/~dbn/pkg-config-guide.html
-# Usage: cc `pkg-config --cflags --libs liblammps` -o myapp myapp.c
-# after you added @CMAKE_INSTALL_FULL_LIBDIR@/pkg-config to PKG_CONFIG_PATH,
+
+# Add the directory where lammps.pc got installed to your PKG_CONFIG_PATH
 # e.g. export PKG_CONFIG_PATH=@CMAKE_INSTALL_FULL_LIBDIR@/pkgconfig
 
+# Use this on commandline with:
+# c++ `pkg-config --cflags --libs lammps` -o myapp myapp.cpp
+
+# Use this in a Makefile:
+# myapp: myapp.cpp
+# 	$(CC) `pkg-config --cflags --libs lammps` -o $@ $<
+
+# Use this in autotools:
+# configure.ac:
+# PKG_CHECK_MODULES([LAMMPS], [lammps])
+# Makefile.am:
+# myapp_CFLAGS = $(LAMMPS_CFLAGS)
+# myapp_LDADD = $(LAMMPS_LIBS)
+
+# Use this in CMake:
+# CMakeLists.txt:
+# find_package(PkgConfig)
+# pkg_check_modules(LAMMPS IMPORTED_TARGET lammps)
+# target_link_libraries(<lib> PkgConfig::LAMMPS)
+
 prefix=@CMAKE_INSTALL_PREFIX@
 libdir=@CMAKE_INSTALL_FULL_LIBDIR@
 includedir=@CMAKE_INSTALL_FULL_INCLUDEDIR@

cmake/presets/all_off.cmake

@@ -8,12 +8,12 @@ set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVA
                   USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
                   USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
                   USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
-                  USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
+                  USER-QUIP USER-REAXC USER-SDPD USER-SMD USER-SMTBQ USER-SPH USER-TALLY
                   USER-UEF USER-VTK)
 
 set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
                       USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
-                      USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
+                      USER-NETCDF USER-PLUMED USER-QMMM USER-QUIP USER-SMD USER-VTK)
 
 set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
 

cmake/presets/all_on.cmake

@@ -8,12 +8,12 @@ set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVA
                   USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
                   USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
                   USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
-                  USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
+                  USER-QUIP USER-REAXC USER-SDPD USER-SMD USER-SMTBQ USER-SPH USER-TALLY
                   USER-UEF USER-VTK)
 
 set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
                       USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
-                      USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
+                      USER-NETCDF USER-PLUMED USER-QMMM USER-QUIP USER-SMD USER-VTK)
 
 set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
 

cmake/presets/manual_selection.cmake

@@ -56,11 +56,13 @@ set(PKG_USER-MOFFF OFF CACHE BOOL "" FORCE)
 set(PKG_USER-MOLFILE OFF CACHE BOOL "" FORCE)
 set(PKG_USER-NETCDF OFF CACHE BOOL "" FORCE)
 set(PKG_USER-OMP OFF CACHE BOOL "" FORCE)
-set(PKG_USER-PHOFFOFF OFF CACHE BOOL "" FORCE)
+set(PKG_USER-PHONON OFF CACHE BOOL "" FORCE)
+set(PKG_USER-PLUMED OFF CACHE BOOL "" FORCE)
 set(PKG_USER-QMMM OFF CACHE BOOL "" FORCE)
 set(PKG_USER-QTB OFF CACHE BOOL "" FORCE)
 set(PKG_USER-QUIP OFF CACHE BOOL "" FORCE)
 set(PKG_USER-REAXC OFF CACHE BOOL "" FORCE)
+set(PKG_USER-SDPD OFF CACHE BOOL "" FORCE)
 set(PKG_USER-SMD OFF CACHE BOOL "" FORCE)
 set(PKG_USER-SMTBQ OFF CACHE BOOL "" FORCE)
 set(PKG_USER-SPH OFF CACHE BOOL "" FORCE)

cmake/presets/nolib.cmake

@@ -8,12 +8,12 @@ set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVA
                   USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
                   USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
                   USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
-                  USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
+                  USER-QUIP USER-REAXC USER-SDPD USER-SMD USER-SMTBQ USER-SPH USER-TALLY
                   USER-UEF USER-VTK)
 
 set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
                       USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
-                      USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
+                      USER-NETCDF USER-PLUMED USER-QMMM USER-QUIP USER-SMD USER-VTK)
 
 set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
 

cmake/presets/std.cmake

@@ -8,7 +8,7 @@ set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVA
                   USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
                   USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
                   USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
-                  USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
+                  USER-QUIP USER-REAXC USER-SDPD USER-SMD USER-SMTBQ USER-SPH USER-TALLY
                   USER-UEF USER-VTK)
 
 set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI

cmake/presets/std_nolib.cmake

@@ -8,7 +8,7 @@ set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVA
                   USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
                   USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
                   USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
-                  USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
+                  USER-QUIP USER-REAXC USER-SDPD USER-SMD USER-SMTBQ USER-SPH USER-TALLY
                   USER-UEF USER-VTK)
 
 set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI

cmake/presets/user.cmake

@@ -8,12 +8,12 @@ set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVA
                   USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
                   USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
                   USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
-                  USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
+                  USER-QUIP USER-REAXC USER-SDPD USER-SMD USER-SMTBQ USER-SPH USER-TALLY
                   USER-UEF USER-VTK)
 
 set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
                       USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
-                      USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
+                      USER-NETCDF USER-PLUMED USER-QMMM USER-QUIP USER-SMD USER-VTK)
 
 set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
 

doc/Makefile

@@ -38,7 +38,7 @@ OBJECTS=$(SOURCES:src/%.txt=$(RSTDIR)/%.rst)
 help:
 	@echo "Please use \`make <target>' where <target> is one of"
 	@echo "  html       create HTML doc pages in html dir"
-	@echo "  pdf        create Manual.pdf and Developer.pdf in this dir"
+	@echo "  pdf        create Developer.pdf and Manual.pdf in this dir"
 	@echo "  old        create old-style HTML doc pages in old dir"
 	@echo "  fetch      fetch HTML and PDF files from LAMMPS web site"
 	@echo "  epub       create ePUB format manual for e-book readers"
@@ -95,9 +95,10 @@ spelling: $(OBJECTS) utils/sphinx-config/false_positives.txt
 	@echo "Spell check finished."
 
 epub: $(OBJECTS)
-	@mkdir -p epub
+	@mkdir -p epub/JPG
 	@rm -f LAMMPS.epub
 	@cp src/JPG/lammps-logo.png epub/
+	@cp src/JPG/*.* epub/JPG
 	@(\
 		. $(VENV)/bin/activate ;\
 		cp -r src/* $(RSTDIR)/ ;\
@@ -116,17 +117,17 @@ mobi: epub
 pdf: utils/txt2html/txt2html.exe
 	@(\
 		set -e; \
-		cd src; \
-		../utils/txt2html/txt2html.exe -b *.txt; \
-		htmldoc --batch lammps.book;          \
-		for s in `echo *.txt | sed -e 's,\.txt,\.html,g'` ; \
-			do grep -q $$s lammps.book || \
-			echo doc file $$s missing in src/lammps.book; done; \
-		rm *.html; \
-		cd Developer; \
+		cd src/Developer; \
 		pdflatex developer; \
 		pdflatex developer; \
 		mv developer.pdf ../../Developer.pdf; \
+		cd ..; \
+		../utils/txt2html/txt2html.exe -b *.txt; \
+		htmldoc --batch lammps.book;          \
+		for s in `echo *.txt | sed -e 's/ \(pairs\|bonds\|angles\|dihedrals\|impropers\|commands_list\|fixes\|computes\).txt/ /g' | sed -e 's,\.txt,\.html,g'` ; \
+			do grep -q ^$$s lammps.book || \
+			echo WARNING: doc file $$s missing in src/lammps.book; done; \
+		rm *.html; \
 	)
 
 old: utils/txt2html/txt2html.exe

doc/github-development-workflow.md

@@ -0,0 +1,184 @@
+# Outline of the GitHub Development Workflow
+
+This purpose of this document is to provide a point of reference for the
+core LAMMPS developers and other LAMMPS contibutors to understand the
+choices the LAMMPS developers have agreed on. Git and GitHub provide the
+tools, but do not set policies, so it is up to the developers to come to
+an agreement as to how to define and interpret policies. This document
+is likely to change as our experiences and needs change and we try to
+adapt accordingly. Last change 2018-11-15.
+
+## Table of Contents
+
+  * [GitHub Merge Management](#github-merge-management)
+  * [Pull Requests](#pull-requests)
+    * [Pull Request Assignments](#pull-request-assignments)
+    * [Pull Request Reviews](#pull-request-reviews)
+    * [Pull Request Discussions](#pull-request-discussions)
+    * [Checklist for Pull Requests](#checklist-for-pull-requests)
+  * [GitHub Issues](#github-issues)
+  * [Milestones and Release Planning](#milestones-and-release-planning)
+
+## GitHub Merge Management
+
+In the interest of consistency, ONLY ONE of the core LAMMPS developers
+should doing the merging itself.  This is currently
+[@akohlmey](https://github.com/akohlmey) (Axel Kohlmeyer).
+If this assignment needs to be changed, it shall be done right after a
+stable release.
+
+## Pull Requests
+
+ALL changes to the LAMMPS code and documentation, however trivial, MUST
+be submitted as a pull request to GitHub. All changes to the "master"
+branch must be made exclusively through merging pull requests. The
+"unstable" and "stable" branches, respectively are only to be updated
+upon patch or stable releases with fast-forward merges based on the
+associated tags. Pull requests may also be submitted to (long-running)
+feature branches created by LAMMPS developers inside the LAMMPS project,
+if needed. Those are not subject to the merge and review restrictions
+discussed in this document, though, but get manages as needed on a
+case-by-case basis.
+
+### Pull Request Assignments
+
+Pull requests can be "chaperoned" by one of the LAMMPS core developers.
+This is indicated by who the pull request is assigned to. LAMMPS core
+developers can self-assign or they can decide to assign a pull request
+to a different LAMMPS developer. Being assigned to a pull request means,
+that this pull request may need some work and the assignee is tasked to
+determine what this might be needed or not, and may either implement the
+required changes or ask the submitter of the pull request to implement
+them.  Even though, all LAMMPS developers may have write access to pull
+requests (if enabled by the submitter, which is the default), only the
+submitter or the assignee of a pull request may do so.  During this
+period the "work_in_progress" label shall be applied to the pull
+request.  The assignee gets to decide what happens to the pull request
+next, e.g. whether it should be assigned to a different developer for
+additional checks and changes, or is recommended to be merged.  Removing
+the "work_in_progress" label and assigning the pull request to the
+developer tasked with merging signals that a pull request is ready to be
+merged.
+
+### Pull Request Reviews
+
+People can be assigned to review a pull request in two ways:
+
+  * They can be assigned manually to review a pull request
+    by the submitter or a LAMMPS developer
+  * They can be automatically assigned, because a developers matches
+    a file pattern in the `.github/CODEOWNERS` file, which associates
+    developers with the code they contributed and maintain.
+
+Reviewers are requested to state their appraisal of the proposed changes
+and either approve or request changes. People may unassign themselves
+from review, if they feel not competent about the changes proposed. At
+least one review from a LAMMPS developer with write access is required
+before merging in addition to the automated compilation tests.  The
+feature, that reviews from code owners are "hard" reviews (i.e. they
+must all be approved before merging is allowed), is currently disabled
+and it is in the discretion of the merge maintainer to assess when
+a sufficient degree of approval has been reached.  Reviews may be
+(automatically) dismissed, when the reviewed code has been changed,
+and then approval is required a second time.
+
+### Pull Request Discussions
+
+All discussions about a pull request should be kept as much as possible
+on the pull request discussion page on GitHub, so that other developers
+can later review the entire discussion after the fact and understand the
+rationale behind choices made.  Exceptions to this policy are technical
+discussions, that are centered on tools or policies themselves
+(git, github, c++) rather than on the content of the pull request.
+
+### Checklist for Pull Requests
+
+Here are some items to check:
+  * source and text files should not have CR/LF line endings (use dos2unix to remove)
+  * every new command or style should have documentation. The names of
+  source files (c++ and manual) should follow the name of the style.
+  (example: `src/fix_nve.cpp`, `src/fix_nve.h` for `fix nve` command,
+  implementing the class `FixNVE`, documented in `doc/src/fix_nve.txt`)
+  * all new style names should be lower case, the must be no dashes,
+  blanks, or underscores separating words, only forward slashes.
+  * new style docs should be added to the "overview" files in
+  `doc/src/Commands_*.txt`, `doc/src/{fixes,computes,pairs,bonds,...}.txt`
+  and `doc/src/lammps.book`
+  * new files in packages should be added to `src/.gitignore`
+  * removed or renamed files in packages should be added to `src/Purge.list`
+  * C++ source files should use C++ style include files for accessing
+  C-library APIs, e.g. `#include <cstdlib>` instead of `#include <stdlib.h>`.
+  And they should use angular brackets instead of double quotes. Full list:
+    * assert.h -> cassert
+    * ctype.h -> cctype
+    * errno.h -> cerrno
+    * float.h -> cfloat
+    * limits.h -> climits
+    * math.h -> cmath
+    * omplex.h -> complex
+    * setjmp.h -> csetjmp
+    * signal.h -> csignal
+    * stddef.h -> cstddef
+    * stdint.h -> cstdint
+    * stdio.h -> cstdio
+    * stdlib.h -> cstdlib
+    * string.h -> cstring
+    * time.h -> ctime
+  Do not replace (as they are C++-11): `inttypes.h` and `stdint.h`.
+  * Code should follow the C++-98 standard. C++-11 is only accepted
+  in individual special purpose packages
+  * indentation is two spaces per level
+  * there should be no tabs and no trailing whitespace
+  * header files, especially of new styles, should not include any
+  other headers, except the header with the base class or cstdio.
+  Forward declarations should be used instead when possible.
+  * iostreams should be avoided. LAMMPS uses stdio from the C-library.
+  * use of STL in headers and class definitions should be avoided.
+  * static class members should be avoided at all cost.
+  * anything storing atom IDs should be using `tagint` and not `int`.
+  This can be flagged by the compiler only for pointers and only when
+  compiling LAMMPS with `-DLAMMPS_BIGBIG`.
+  * when including both `lmptype.h` (and using defines or macros from it)
+  and `mpi.h`, `lmptype.h` must be included first.
+
+## GitHub Issues
+
+The GitHub issue tracker is the location where the LAMMPS developers
+and other contributors or LAMMPS users can report issues or bugs with
+the LAMMPS code or request new features to be added. Feature requests
+are usually indicated by a `[Feature Request]` marker in the subject.
+Issues are assigned to a person, if this person is working on this
+feature or working to resolve an issue. Issues that have nobody working
+on them at the moment, have the label `volunteer needed` attached.
+
+When an issue, say `#125` is resolved by a specific pull request,
+the comment for the pull request shall contain the text `closes #125`
+or `fixes #125`, so that the issue is automatically deleted when
+the pull request is merged.
+
+## Milestones and Release Planning
+
+LAMMPS uses a continuous release development model with incremental
+changes, i.e. significant effort is made - including automated pre-merge
+testing - that the code in the branch "master" does not get broken.
+More extensive testing (including regression testing) is performed after
+code is merged to the "master" branch. There are patch releases of
+LAMMPS every 1-3 weeks at a point, when the LAMMPS developers feel, that
+a sufficient amount of changes have happened, and the post-merge testing
+has been successful. These patch releases are marked with a
+`patch_<version date>` tag and the "unstable" branch follows only these
+versions (and thus is always supposed to be of production quality,
+unlike "master", which may be temporary broken, in the case of larger
+change sets or unexpected incompatibilities or side effects.
+
+About 3-4 times each year, there are going to be "stable" releases
+of LAMMPS.  These have seen additional, manual testing and review of
+results from testing with instrumented code and static code analysis.
+Also, in the last 2-3 patch releases before a stable release are
+"release candidate" versions which only contain bugfixes and
+documentation updates.  For release planning and the information of
+code contributors, issues and pull requests being actively worked on
+are assigned a "milestone", which corresponds to the next stable
+release or the stable release after that, with a tentative release
+date.
+

doc/src/Build_basics.txt

@@ -137,9 +137,9 @@ simply loading the appropriate module before building LAMMPS.
 -D CMAKE_C_COMPILER=name              # name of C compiler
 -D CMAKE_Fortran_COMPILER=name        # name of Fortran compiler :pre
 
--D CMAKE_CXX_FlAGS=string             # flags to use with C++ compiler
--D CMAKE_C_FlAGS=string               # flags to use with C compiler
--D CMAKE_Fortran_FlAGS=string         # flags to use with Fortran compiler :pre
+-D CMAKE_CXX_FLAGS=string             # flags to use with C++ compiler
+-D CMAKE_C_FLAGS=string               # flags to use with C compiler
+-D CMAKE_Fortran_FLAGS=string         # flags to use with Fortran compiler :pre
 
 By default CMake will use a compiler it finds and it will add
 optimization flags appropriate to that compiler and any "accelerator
@@ -292,6 +292,10 @@ This will create a lammps/doc/html dir with the HTML doc pages so that
 you can browse them locally on your system.  Type "make" from the
 lammps/doc dir to see other options.
 
+NOTE: You can also download a tarball of the documention for the
+current LAMMPS version (HTML and PDF files), from the website
+"download page"_http://lammps.sandia.gov/download.html.
+
 :line
 
 Install LAMMPS after a build :h4,link(install)

doc/src/Build_extras.txt

@@ -45,6 +45,7 @@ This is the list of packages that may require additional steps.
 "USER-INTEL"_#user-intel,
 "USER-MOLFILE"_#user-molfile,
 "USER-NETCDF"_#user-netcdf,
+"USER-PLUMED"_#user-plumed,
 "USER-OMP"_#user-omp,
 "USER-QMMM"_#user-qmmm,
 "USER-QUIP"_#user-quip,
@@ -563,9 +564,9 @@ file.
 VORONOI package :h4,link(voronoi)
 
 To build with this package, you must download and build the "Voro++
-library"_voro_home.
+library"_voro-home.
 
-:link(voro_home,http://math.lbl.gov/voro++)
+:link(voro-home,http://math.lbl.gov/voro++)
 
 [CMake build]:
 
@@ -712,6 +713,103 @@ a corresponding Makefile.lammps.machine file.
 
 :line
 
+USER-PLUMED package :h4,link(user-plumed)
+
+Before building LAMMPS with this package, you must first build PLUMED.
+PLUMED can be built as part of the LAMMPS build or installed separately
+from LAMMPS using the generic "plumed installation instructions"_plumedinstall.
+:link(plumedinstall,http://plumed.github.io/doc-master/user-doc/html/_installation.html)
+
+PLUMED can be linked into MD codes in three different modes: static,
+shared, and runtime.  With the "static" mode, all required PLUMED code
+is linked statically into the MD code. The MD code is then fully
+independent from the PLUMED installation, but also you have to
+rebuild/relink the MD code to update the PLUMED code inside it.  With
+"shared" linkage mode, the MD code is linked to a shared library
+containing the PLUMED code, preferably after it was installed in a
+globally accessible location. This way the same installed PLUMED code
+can be shared across multiple MD packages and can be updated, for as
+long as the shared PLUMED library is ABI-compatible. The third linkage
+mode is "runtime" which allows to switch the PLUMED kernel at runtime
+between different variants through setting the PLUMED_KERNEL environment
+varible, which has to point to the location of the libplumedKernel.so
+dynamical shared object, which is then loaded at runtime. This is
+particularly convenient for doing PLUMED development and comparing
+multiple PLUMED versions without having to recompile the hosting MD
+code. All three linkage modes are supported by LAMMPS on selected
+operating systems (e.g. Linux) and using either CMake or traditional
+make build. The "static" mode should be most portable, the "runtime"
+mode support in LAMMPS makes the most assumptions about operating
+system and compiler environment. If one mode does not work, try a
+different one, or switch to a different build system, or consider
+a global PLUMED installation or downloading it during building LAMMPS.
+
+[CMake build]:
+
+-D DOWNLOAD_PLUMED=value   # download PLUMED for build, value = no (default) or yes
+-D PLUMED_MODE=value       # Linkage mode for PLUMED, value = static (default), shared, or runtime :pre
+
+If DOWNLOAD_PLUMED is set to "yes", the PLUMED library will be
+downloaded (the version of that is hardcoded to a vetted version of
+PLUMED, usually a recent stable release version) and built inside the
+CMake build directory.  If DOWNLOAD_PLUMED is set to "no" (the default),
+CMake will try to detect an installed version of PLUMED and link to
+that. For this to work, the PLUMED library has to be installed into a
+location where the pkg-config tool can find it or the PKG_CONFIG_PATH
+environment variable has to be set up accordingly.
+
+The PLUMED_MODE setting determines the linkage mode of the PLUMED
+library.  Allowed values are "static" (default), "shared", or "runtime".
+For a discussion of PLUMED linkage modes, please see above.  When
+enabling DOWNLOAD_PLUMED, the static linkage mode is recommended.
+
+[Traditional make]:
+
+Before installing the USER-PLUMED package, first the PLUMED library
+needs to be configured so that LAMMPS can find the right settings when
+compiling and linking the LAMMPS executable itself. You can either
+download and build PLUMED inside the LAMMPS plumed library folder or use
+a previously installed PLUMED library and point LAMMPS to its
+location. You also have to choose the linkage mode: "static" (default),
+"shared" or "runtime".  For a discussion of PLUMED linkage modes, please
+see above.
+
+Download/compilation/configuration of the plumed library can be done
+from the src folder through the following make args:
+
+make lib-plumed                         # print help message
+make lib-plumed args="-b"               # download and build PLUMED in lib/plumed/plumed2
+make lib-plumed args="-p $HOME/.local"  # use existing PLUMED installation in $HOME/.local
+make lib-plumed args="-p /usr/local -m shared"  # use existing PLUMED installation in
+                                                # /usr/local and use shared linkage mode
+:pre
+
+Note that 2 symbolic (soft) links, "includelink" and "liblink" are
+created in lib/plumed to point into the location of the PLUMED build to
+use and also a new file lib/plumed/Makefile.lammps is created with
+settings suitable for LAMMPS to compile and link PLUMED in the desired
+linkage mode. After this step is compleded, you can install the
+USER-PLUMED package and compile LAMMPS in the usual manner:
+
+make yes-user-plumed 
+make machine :pre
+
+Once this compilation completes you should be able to run LAMMPS in the
+usual way.  For shared linkage mode, libplumed.so must be found by the
+LAMMPS executable, which on many operating systems means, you have to
+set the LD_LIBRARY_PATH environment variable accordingly.
+
+Support for the different linkage modes in LAMMPS varies for different
+operating systems, using the static linkage is expected to be the most
+portable, and thus set to be the default.
+
+If you want to change the linkage mode, you have to re-run "make
+lib-plumed" with the desired settings [and] do a reinstall if the
+USER-PLUMED package with "make yes-user-plumed" to update the required
+makefile settings with the changes in the lib/plumed folder.
+
+:line
+
 USER-H5MD package :h4,link(user-h5md)
 
 To build with this package you must have the HDF5 software package
@@ -932,9 +1030,9 @@ successfully build on your system.
 USER-SCAFACOS package :h4,link(user-scafacos)
 
 To build with this package, you must download and build the "ScaFaCoS
-Coulomb solver library"_scafacos_home
+Coulomb solver library"_scafacos-home
 
-:link(scafacos_home,http://www.scafacos.de)
+:link(scafacos-home,http://www.scafacos.de)
 
 [CMake build]:
 

doc/src/Build_package.txt

@@ -42,7 +42,7 @@ packages:
 "KOKKOS"_Build_extras.html#kokkos,
 "LATTE"_Build_extras.html#latte,
 "MEAM"_Build_extras.html#meam,
-"MESSAGE"_#Build_extras.html#message,
+"MESSAGE"_Build_extras.html#message,
 "MSCG"_Build_extras.html#mscg,
 "OPT"_Build_extras.html#opt,
 "POEMS"_Build_extras.html#poems,
@@ -56,10 +56,11 @@ packages:
 "USER-INTEL"_Build_extras.html#user-intel,
 "USER-MOLFILE"_Build_extras.html#user-molfile,
 "USER-NETCDF"_Build_extras.html#user-netcdf,
+"USER-PLUMED"_Build_extras.html#user-plumed,
 "USER-OMP"_Build_extras.html#user-omp,
 "USER-QMMM"_Build_extras.html#user-qmmm,
 "USER-QUIP"_Build_extras.html#user-quip,
-"USER-SCAFACOS"_#Build_extras.html#user-scafacos,
+"USER-SCAFACOS"_Build_extras.html#user-scafacos,
 "USER-SMD"_Build_extras.html#user-smd,
 "USER-VTK"_Build_extras.html#user-vtk :tb(c=6,ea=c,a=l)
 

doc/src/Commands_all.txt

@@ -59,6 +59,7 @@ An alphabetic list of all LAMMPS commands.
 "fix_modify"_fix_modify.html,
 "group"_group.html,
 "group2ndx"_group2ndx.html,
+"hyper"_hyper.html,
 "if"_if.html,
 "info"_info.html,
 "improper_coeff"_improper_coeff.html,

doc/src/Commands_bond.txt

@@ -34,7 +34,7 @@ OPT.
 "fene (iko)"_bond_fene.html,
 "fene/expand (o)"_bond_fene_expand.html,
 "gromos (o)"_bond_gromos.html,
-"harmonic (ko)"_bond_harmonic.html,
+"harmonic (iko)"_bond_harmonic.html,
 "harmonic/shift (o)"_bond_harmonic_shift.html,
 "harmonic/shift/cut (o)"_bond_harmonic_shift_cut.html,
 "morse (o)"_bond_morse.html,
@@ -57,9 +57,11 @@ OPT.
 "zero"_angle_zero.html,
 "hybrid"_angle_hybrid.html :tb(c=3,ea=c)
 
-"charmm (ko)"_angle_charmm.html,
+"charmm (iko)"_angle_charmm.html,
 "class2 (ko)"_angle_class2.html,
+"class2/p6"_angle_class2.html,
 "cosine (o)"_angle_cosine.html,
+"cosine/buck6d"_angle_cosine_buck6d.html,
 "cosine/delta (o)"_angle_cosine_delta.html,
 "cosine/periodic (o)"_angle_cosine_periodic.html,
 "cosine/shift (o)"_angle_cosine_shift.html,
@@ -70,7 +72,7 @@ OPT.
 "fourier/simple (o)"_angle_fourier_simple.html,
 "harmonic (iko)"_angle_harmonic.html,
 "quartic (o)"_angle_quartic.html,
-"sdk"_angle_sdk.html,
+"sdk (o)"_angle_sdk.html,
 "table (o)"_angle_table.html :tb(c=4,ea=c)
 
 :line
@@ -97,7 +99,7 @@ OPT.
 "nharmonic (o)"_dihedral_nharmonic.html,
 "opls (iko)"_dihedral_opls.html,
 "quadratic (o)"_dihedral_quadratic.html,
-"spherical (o)"_dihedral_spherical.html,
+"spherical"_dihedral_spherical.html,
 "table (o)"_dihedral_table.html,
 "table/cut"_dihedral_table_cut.html :tb(c=4,ea=c)
 
@@ -112,7 +114,7 @@ OPT.
 
 "none"_improper_none.html,
 "zero"_improper_zero.html,
-"hybrid"_improper_hybrid.html  :tb(c=3,ea=c)
+"hybrid"_improper_hybrid.html :tb(c=3,ea=c)
 
 "class2 (ko)"_improper_class2.html,
 "cossq (o)"_improper_cossq.html,
@@ -120,5 +122,6 @@ OPT.
 "distance"_improper_distance.html,
 "fourier (o)"_improper_fourier.html,
 "harmonic (iko)"_improper_harmonic.html,
+"inversion/harmonic"_improper_inversion_harmonic.html,
 "ring (o)"_improper_ring.html,
 "umbrella (o)"_improper_umbrella.html :tb(c=4,ea=c)

doc/src/Commands_compute.txt

@@ -25,6 +25,7 @@ additional letters in parenthesis: g = GPU, i = USER-INTEL, k =
 KOKKOS, o = USER-OMP, t = OPT.
 
 "ackland/atom"_compute_ackland_atom.html,
+"adf"_compute_adf.html,
 "aggregate/atom"_compute_cluster_atom.html,
 "angle"_compute_angle.html,
 "angle/local"_compute_angle_local.html,
@@ -35,6 +36,7 @@ KOKKOS, o = USER-OMP, t = OPT.
 "bond/local"_compute_bond_local.html,
 "centro/atom"_compute_centro_atom.html,
 "chunk/atom"_compute_chunk_atom.html,
+"chunk/spread/atom"_compute_chunk_spread_atom.html,
 "cluster/atom"_compute_cluster_atom.html,
 "cna/atom"_compute_cna_atom.html,
 "cnp/atom"_compute_cnp_atom.html,
@@ -91,12 +93,15 @@ KOKKOS, o = USER-OMP, t = OPT.
 "pe/tally"_compute_tally.html,
 "plasticity/atom"_compute_plasticity_atom.html,
 "pressure"_compute_pressure.html,
+"pressure/cylinder"_compute_pressure_cylinder.html,
 "pressure/uef"_compute_pressure_uef.html,
 "property/atom"_compute_property_atom.html,
 "property/chunk"_compute_property_chunk.html,
 "property/local"_compute_property_local.html,
+"ptm/atom"_compute_ptm_atom.html,
 "rdf"_compute_rdf.html,
 "reduce"_compute_reduce.html,
+"reduce/chunk"_compute_reduce_chunk.html,
 "reduce/region"_compute_reduce.html,
 "rigid/local"_compute_rigid_local.html,
 "saed"_compute_saed.html,
@@ -115,7 +120,7 @@ KOKKOS, o = USER-OMP, t = OPT.
 "smd/tlsph/strain"_compute_smd_tlsph_strain.html,
 "smd/tlsph/strain/rate"_compute_smd_tlsph_strain_rate.html,
 "smd/tlsph/stress"_compute_smd_tlsph_stress.html,
-"smd/triangle/mesh/vertices"_compute_smd_triangle_mesh_vertices.html,
+"smd/triangle/vertices"_compute_smd_triangle_vertices.html,
 "smd/ulsph/num/neighs"_compute_smd_ulsph_num_neighs.html,
 "smd/ulsph/strain"_compute_smd_ulsph_strain.html,
 "smd/ulsph/strain/rate"_compute_smd_ulsph_strain_rate.html,
@@ -126,6 +131,8 @@ KOKKOS, o = USER-OMP, t = OPT.
 "snav/atom"_compute_sna_atom.html,
 "spin"_compute_spin.html,
 "stress/atom"_compute_stress_atom.html,
+"stress/mop"_compute_stress_mop.html,
+"stress/mop/profile"_compute_stress_mop.html,
 "stress/tally"_compute_tally.html,
 "tdpd/cc/atom"_compute_tdpd_cc_atom.html,
 "temp (k)"_compute_temp.html,
@@ -133,6 +140,7 @@ KOKKOS, o = USER-OMP, t = OPT.
 "temp/body"_compute_temp_body.html,
 "temp/chunk"_compute_temp_chunk.html,
 "temp/com"_compute_temp_com.html,
+"temp/cs"_compute_temp_cs.html,
 "temp/deform"_compute_temp_deform.html,
 "temp/deform/eff"_compute_temp_deform_eff.html,
 "temp/drude"_compute_temp_drude.html,

doc/src/Commands_fix.txt

@@ -40,11 +40,13 @@ OPT.
 "ave/time"_fix_ave_time.html,
 "aveforce"_fix_aveforce.html,
 "balance"_fix_balance.html,
+"bocs"_fix_bocs.html,
 "bond/break"_fix_bond_break.html,
 "bond/create"_fix_bond_create.html,
 "bond/react"_fix_bond_react.html,
 "bond/swap"_fix_bond_swap.html,
 "box/relax"_fix_box_relax.html,
+"client/md"_fix_client_md.html,
 "cmap"_fix_cmap.html,
 "colvars"_fix_colvars.html,
 "controller"_fix_controller.html,
@@ -54,7 +56,7 @@ OPT.
 "drag"_fix_drag.html,
 "drude"_fix_drude.html,
 "drude/transform/direct"_fix_drude_transform.html,
-"drude/transform/reverse"_fix_drude_transform.html,
+"drude/transform/inverse"_fix_drude_transform.html,
 "dt/reset"_fix_dt_reset.html,
 "edpd/source"_fix_dpd_source.html,
 "efield"_fix_efield.html,
@@ -65,16 +67,19 @@ OPT.
 "eos/table/rx (k)"_fix_eos_table_rx.html,
 "evaporate"_fix_evaporate.html,
 "external"_fix_external.html,
+"ffl"_fix_ffl.html,
 "filter/corotate"_fix_filter_corotate.html,
 "flow/gauss"_fix_flow_gauss.html,
-"freeze"_fix_freeze.html,
+"freeze (k)"_fix_freeze.html,
 "gcmc"_fix_gcmc.html,
 "gld"_fix_gld.html,
 "gle"_fix_gle.html,
-"gravity (o)"_fix_gravity.html,
+"gravity (ko)"_fix_gravity.html,
 "grem"_fix_grem.html,
 "halt"_fix_halt.html,
 "heat"_fix_heat.html,
+"hyper/global"_fix_hyper_global.html,
+"hyper/local"_fix_hyper_local.html,
 "imd"_fix_imd.html,
 "indent"_fix_indent.html,
 "ipi"_fix_ipi.html,
@@ -91,6 +96,7 @@ OPT.
 "lineforce"_fix_lineforce.html,
 "manifoldforce"_fix_manifoldforce.html,
 "meso"_fix_meso.html,
+"meso/move"_fix_meso_move.html,
 "meso/stationary"_fix_meso_stationary.html,
 "momentum (k)"_fix_momentum.html,
 "move"_fix_move.html,
@@ -106,15 +112,16 @@ OPT.
 "nph/eff"_fix_nh_eff.html,
 "nph/sphere (o)"_fix_nph_sphere.html,
 "nphug (o)"_fix_nphug.html,
-"npt (kio)"_fix_nh.html,
+"npt (iko)"_fix_nh.html,
 "npt/asphere (o)"_fix_npt_asphere.html,
 "npt/body"_fix_npt_body.html,
 "npt/eff"_fix_nh_eff.html,
 "npt/sphere (o)"_fix_npt_sphere.html,
 "npt/uef"_fix_nh_uef.html,
-"nve (kio)"_fix_nve.html,
+"nve (iko)"_fix_nve.html,
 "nve/asphere (i)"_fix_nve_asphere.html,
 "nve/asphere/noforce"_fix_nve_asphere_noforce.html,
+"nve/awpmd"_fix_nve_awpmd.html,
 "nve/body"_fix_nve_body.html,
 "nve/dot"_fix_nve_dot.html,
 "nve/dotc/langevin"_fix_nve_dotc_langevin.html,
@@ -123,7 +130,7 @@ OPT.
 "nve/line"_fix_nve_line.html,
 "nve/manifold/rattle"_fix_nve_manifold_rattle.html,
 "nve/noforce"_fix_nve_noforce.html,
-"nve/sphere (o)"_fix_nve_sphere.html,
+"nve/sphere (ko)"_fix_nve_sphere.html,
 "nve/spin"_fix_nve_spin.html,
 "nve/tri"_fix_nve_tri.html,
 "nvk"_fix_nvk.html,
@@ -142,6 +149,7 @@ OPT.
 "phonon"_fix_phonon.html,
 "pimd"_fix_pimd.html,
 "planeforce"_fix_planeforce.html,
+"plumed"_fix_plumed.html,
 "poems"_fix_poems.html,
 "pour"_fix_pour.html,
 "precession/spin"_fix_precession_spin.html,
@@ -168,27 +176,28 @@ OPT.
 "restrain"_fix_restrain.html,
 "rhok"_fix_rhok.html,
 "rigid (o)"_fix_rigid.html,
+"rigid/meso"_fix_rigid_meso.html,
 "rigid/nph (o)"_fix_rigid.html,
+"rigid/nph/small"_fix_rigid.html,
 "rigid/npt (o)"_fix_rigid.html,
+"rigid/npt/small"_fix_rigid.html,
 "rigid/nve (o)"_fix_rigid.html,
+"rigid/nve/small"_fix_rigid.html,
 "rigid/nvt (o)"_fix_rigid.html,
+"rigid/nvt/small"_fix_rigid.html,
 "rigid/small (o)"_fix_rigid.html,
-"rigid/small/nph"_fix_rigid.html,
-"rigid/small/npt"_fix_rigid.html,
-"rigid/small/nve"_fix_rigid.html,
-"rigid/small/nvt"_fix_rigid.html,
 "rx (k)"_fix_rx.html,
 "saed/vtk"_fix_saed_vtk.html,
 "setforce (k)"_fix_setforce.html,
 "shake"_fix_shake.html,
 "shardlow (k)"_fix_shardlow.html,
 "smd"_fix_smd.html,
-"smd/adjust/dt"_fix_smd_adjust_dt.html,
-"smd/integrate/tlsph"_fix_smd_integrate_tlsph.html,
-"smd/integrate/ulsph"_fix_smd_integrate_ulsph.html,
-"smd/move/triangulated/surface"_fix_smd_move_triangulated_surface.html,
+"smd/adjust_dt"_fix_smd_adjust_dt.html,
+"smd/integrate_tlsph"_fix_smd_integrate_tlsph.html,
+"smd/integrate_ulsph"_fix_smd_integrate_ulsph.html,
+"smd/move_tri_surf"_fix_smd_move_triangulated_surface.html,
 "smd/setvel"_fix_smd_setvel.html,
-"smd/wall/surface"_fix_smd_wall_surface.html,
+"smd/wall_surface"_fix_smd_wall_surface.html,
 "spring"_fix_spring.html,
 "spring/chunk"_fix_spring_chunk.html,
 "spring/rg"_fix_spring_rg.html,
@@ -216,7 +225,7 @@ OPT.
 "wall/body/polyhedron"_fix_wall_body_polyhedron.html,
 "wall/colloid"_fix_wall.html,
 "wall/ees"_fix_wall_ees.html,
-"wall/gran"_fix_wall_gran.html,
+"wall/gran (o)"_fix_wall_gran.html,
 "wall/gran/region"_fix_wall_gran_region.html,
 "wall/harmonic"_fix_wall.html,
 "wall/lj1043"_fix_wall.html,

doc/src/Commands_pair.txt

@@ -26,13 +26,13 @@ OPT.
 
 "none"_pair_none.html,
 "zero"_pair_zero.html,
-"hybrid"_pair_hybrid.html,
+"hybrid (k)"_pair_hybrid.html,
 "hybrid/overlay (k)"_pair_hybrid.html :tb(c=4,ea=c)
 
 "adp (o)"_pair_adp.html,
 "agni (o)"_pair_agni.html,
-"airebo (oi)"_pair_airebo.html,
-"airebo/morse (oi)"_pair_airebo.html,
+"airebo (io)"_pair_airebo.html,
+"airebo/morse (io)"_pair_airebo.html,
 "atm"_pair_atm.html,
 "awpmd/cut"_pair_awpmd.html,
 "beck (go)"_pair_beck.html,
@@ -42,21 +42,23 @@ OPT.
 "bop"_pair_bop.html,
 "born (go)"_pair_born.html,
 "born/coul/dsf"_pair_born.html,
-"born/coul/dsf/cs"_pair_born.html,
+"born/coul/dsf/cs"_pair_cs.html,
 "born/coul/long (go)"_pair_born.html,
-"born/coul/long/cs"_pair_born.html,
+"born/coul/long/cs (g)"_pair_cs.html,
 "born/coul/msm (o)"_pair_born.html,
 "born/coul/wolf (go)"_pair_born.html,
-"born/coul/wolf/cs"_pair_born.html,
+"born/coul/wolf/cs (g)"_pair_cs.html,
 "brownian (o)"_pair_brownian.html,
 "brownian/poly (o)"_pair_brownian.html,
 "buck (giko)"_pair_buck.html,
 "buck/coul/cut (giko)"_pair_buck.html,
 "buck/coul/long (giko)"_pair_buck.html,
-"buck/coul/long/cs"_pair_buck.html,
+"buck/coul/long/cs"_pair_cs.html,
 "buck/coul/msm (o)"_pair_buck.html,
 "buck/long/coul/long (o)"_pair_buck_long.html,
 "buck/mdf"_pair_mdf.html,
+"buck6d/coul/gauss/dsf"_pair_buck6d_coul_gauss.html,
+"buck6d/coul/gauss/long"_pair_buck6d_coul_gauss.html,
 "colloid (go)"_pair_colloid.html,
 "comb (o)"_pair_comb.html,
 "comb3"_pair_comb.html,
@@ -66,13 +68,13 @@ OPT.
 "coul/diel (o)"_pair_coul_diel.html,
 "coul/dsf (gko)"_pair_coul.html,
 "coul/long (gko)"_pair_coul.html,
-"coul/long/cs"_pair_coul.html,
+"coul/long/cs (g)"_pair_cs.html,
 "coul/long/soft (o)"_pair_lj_soft.html,
-"coul/msm"_pair_coul.html,
+"coul/msm (o)"_pair_coul.html,
 "coul/shield"_pair_coul_shield.html,
 "coul/streitz"_pair_coul.html,
 "coul/wolf (ko)"_pair_coul.html,
-"coul/wolf/cs"_pair_coul.html,
+"coul/wolf/cs"_pair_cs.html,
 "dpd (gio)"_pair_dpd.html,
 "dpd/fdt"_pair_dpd_fdt.html,
 "dpd/fdt/energy (k)"_pair_dpd_fdt.html,
@@ -81,6 +83,7 @@ OPT.
 "eam (gikot)"_pair_eam.html,
 "eam/alloy (gikot)"_pair_eam.html,
 "eam/cd (o)"_pair_eam.html,
+"eam/cd/old (o)"_pair_eam.html,
 "eam/fs (gikot)"_pair_eam.html,
 "edip (o)"_pair_edip.html,
 "edip/multi"_pair_edip.html,
@@ -90,11 +93,11 @@ OPT.
 "exp6/rx (k)"_pair_exp6_rx.html,
 "extep"_pair_extep.html,
 "gauss (go)"_pair_gauss.html,
-"gauss/cut"_pair_gauss.html,
+"gauss/cut (o)"_pair_gauss.html,
 "gayberne (gio)"_pair_gayberne.html,
 "gran/hertz/history (o)"_pair_gran.html,
 "gran/hooke (o)"_pair_gran.html,
-"gran/hooke/history (o)"_pair_gran.html,
+"gran/hooke/history (ko)"_pair_gran.html,
 "gw"_pair_gw.html,
 "gw/zbl"_pair_gw.html,
 "hbond/dreiding/lj (o)"_pair_hbond_dreiding.html,
@@ -109,9 +112,9 @@ OPT.
 "list"_pair_list.html,
 "lj/charmm/coul/charmm (iko)"_pair_charmm.html,
 "lj/charmm/coul/charmm/implicit (ko)"_pair_charmm.html,
-"lj/charmm/coul/long (giko)"_pair_charmm.html,
-"lj/charmm/coul/long/soft (o)"_pair_charmm.html,
-"lj/charmm/coul/msm"_pair_charmm.html,
+"lj/charmm/coul/long (gikot)"_pair_charmm.html,
+"lj/charmm/coul/long/soft (o)"_pair_lj_soft.html,
+"lj/charmm/coul/msm (o)"_pair_charmm.html,
 "lj/charmmfsw/coul/charmmfsh"_pair_charmm.html,
 "lj/charmmfsw/coul/long"_pair_charmm.html,
 "lj/class2 (gko)"_pair_class2.html,
@@ -124,12 +127,12 @@ OPT.
 "lj/cut/coul/debye (gko)"_pair_lj.html,
 "lj/cut/coul/dsf (gko)"_pair_lj.html,
 "lj/cut/coul/long (gikot)"_pair_lj.html,
-"lj/cut/coul/long/cs"_pair_lj.html,
+"lj/cut/coul/long/cs"_pair_cs.html,
 "lj/cut/coul/long/soft (o)"_pair_lj_soft.html,
 "lj/cut/coul/msm (go)"_pair_lj.html,
 "lj/cut/coul/wolf (o)"_pair_lj.html,
 "lj/cut/dipole/cut (go)"_pair_dipole.html,
-"lj/cut/dipole/long"_pair_dipole.html,
+"lj/cut/dipole/long (g)"_pair_dipole.html,
 "lj/cut/dipole/sf (go)"_pair_dipole.html,
 "lj/cut/soft (o)"_pair_lj_soft.html,
 "lj/cut/thole/long (o)"_pair_thole.html,
@@ -137,15 +140,17 @@ OPT.
 "lj/cut/tip4p/long (ot)"_pair_lj.html,
 "lj/cut/tip4p/long/soft (o)"_pair_lj_soft.html,
 "lj/expand (gko)"_pair_lj_expand.html,
+"lj/expand/coul/long (g)"_pair_lj_expand.html,
 "lj/gromacs (gko)"_pair_gromacs.html,
 "lj/gromacs/coul/gromacs (ko)"_pair_gromacs.html,
-"lj/long/coul/long (io)"_pair_lj_long.html,
+"lj/long/coul/long (iot)"_pair_lj_long.html,
 "lj/long/dipole/long"_pair_dipole.html,
-"lj/long/tip4p/long"_pair_lj_long.html,
+"lj/long/tip4p/long (o)"_pair_lj_long.html,
 "lj/mdf"_pair_mdf.html,
 "lj/sdk (gko)"_pair_sdk.html,
 "lj/sdk/coul/long (go)"_pair_sdk.html,
 "lj/sdk/coul/msm (o)"_pair_sdk.html,
+"lj/sf/dipole/sf (go)"_pair_dipole.html,
 "lj/smooth (o)"_pair_lj_smooth.html,
 "lj/smooth/linear (o)"_pair_lj_smooth_linear.html,
 "lj96/cut (go)"_pair_lj96.html,
@@ -160,14 +165,14 @@ OPT.
 "meam/spline (o)"_pair_meam_spline.html,
 "meam/sw/spline"_pair_meam_sw_spline.html,
 "mgpt"_pair_mgpt.html,
-"mie/cut (o)"_pair_mie.html,
+"mie/cut (g)"_pair_mie.html,
 "momb"_pair_momb.html,
 "morse (gkot)"_pair_morse.html,
-"morse/smooth/linear"_pair_morse.html,
+"morse/smooth/linear (o)"_pair_morse.html,
 "morse/soft"_pair_morse.html,
 "multi/lucy"_pair_multi_lucy.html,
 "multi/lucy/rx (k)"_pair_multi_lucy_rx.html,
-"nb3b/harmonic (o)"_pair_nb3b_harmonic.html,
+"nb3b/harmonic"_pair_nb3b_harmonic.html,
 "nm/cut (o)"_pair_nm.html,
 "nm/cut/coul/cut (o)"_pair_nm.html,
 "nm/cut/coul/long (o)"_pair_nm.html,
@@ -179,7 +184,9 @@ OPT.
 "oxdna2/coaxstk"_pair_oxdna2.html,
 "oxdna2/dh"_pair_oxdna2.html,
 "oxdna2/excv"_pair_oxdna2.html,
+"oxdna2/hbond"_pair_oxdna2.html,
 "oxdna2/stk"_pair_oxdna2.html,
+"oxdna2/xstk"_pair_oxdna2.html,
 "peri/eps"_pair_peri.html,
 "peri/lps (o)"_pair_peri.html,
 "peri/pmb (o)"_pair_peri.html,
@@ -189,11 +196,12 @@ OPT.
 "quip"_pair_quip.html,
 "reax"_pair_reax.html,
 "reax/c (ko)"_pair_reaxc.html,
-"rebo (oi)"_pair_airebo.html,
+"rebo (io)"_pair_airebo.html,
 "resquared (go)"_pair_resquared.html,
+"sdpd/taitwater/isothermal"_pair_sdpd_taitwater_isothermal.html,
 "smd/hertz"_pair_smd_hertz.html,
 "smd/tlsph"_pair_smd_tlsph.html,
-"smd/triangulated/surface"_pair_smd_triangulated_surface.html,
+"smd/tri_surface"_pair_smd_triangulated_surface.html,
 "smd/ulsph"_pair_smd_ulsph.html,
 "smtbq"_pair_smtbq.html,
 "snap (k)"_pair_snap.html,
@@ -225,8 +233,8 @@ OPT.
 "tip4p/long/soft (o)"_pair_lj_soft.html,
 "tri/lj"_pair_tri_lj.html,
 "ufm (got)"_pair_ufm.html,
-"vashishta (ko)"_pair_vashishta.html,
+"vashishta (gko)"_pair_vashishta.html,
 "vashishta/table (o)"_pair_vashishta.html,
-"yukawa (gok)"_pair_yukawa.html,
+"yukawa (gko)"_pair_yukawa.html,
 "yukawa/colloid (go)"_pair_yukawa_colloid.html,
-"zbl (gok)"_pair_zbl.html :tb(c=4,ea=c)
+"zbl (gko)"_pair_zbl.html :tb(c=4,ea=c)

doc/src/Developer/developer.tex

@@ -22,10 +22,10 @@ users.
 LAMMPS source files are in two directories of the distribution
 tarball.  The src directory has the majority of them, all of which are
 C++ files (*.cpp and *.h).  Many of these files are in the src
-directory itself.  There are also dozens of "packages", which can be
+directory itself.  There are also dozens of ``packages'', which can be
 included or excluded when LAMMPS is built.  See the
 doc/Section\_build.html section of the manual for more information
-about packages, or type "make" from within the src directory, which
+about packages, or type ``make'' from within the src directory, which
 lists package-related commands, such as ``make package-status''.  The
 source files for each package are in an all-uppercase sub-directory of
 src, like src/MOLECULE or src/USER-CUDA.  If the package is currently
@@ -38,17 +38,17 @@ The lib directory also contains source code for external libraries,
 used by a few of the packages.  Each sub-directory, like meam or gpu,
 contains the source files, some of which are in different languages
 such as Fortran.  The files are compiled into libraries from within
-each sub-directory, e.g. performing a "make" in the lib/meam directory
+each sub-directory, e.g. performing a ``make'' in the lib/meam directory
 creates a libmeam.a file.  These libraries are linked to during a
 LAMMPS build, if the corresponding package is installed.
 
 LAMMPS C++ source files almost always come in pairs, such as run.cpp
 and run.h.  The pair of files defines a C++ class, the Run class in
-this case, which contains the code invoked by the "run" command in a
+this case, which contains the code invoked by the ``run'' command in a
 LAMMPS input script.  As this example illustrates, source file and
 class names often have a one-to-one correspondence with a command used
 in a LAMMPS input script.  Some source files and classes do not have a
-corresponding input script command, e.g. force.cpp and the Force
+corresponding input script command, e.g. ``force.cpp'' and the Force
 class.  They are discussed in the next section.
 
 \pagebreak
@@ -57,12 +57,12 @@ class.  They are discussed in the next section.
 Though LAMMPS has a lot of source files and classes, its class
 hierarchy is quite simple, as outlined in Fig \ref{fig:classes}.  Each
 boxed name refers to a class and has a pair of associated source files
-in lammps/src, e.g. memory.cpp and memory.h.  More details on the
+in lammps/src, e.g. ``memory.cpp'' and ``memory.h''.  More details on the
 class and its methods and data structures can be found by examining
 its *.h file.
 
 LAMMPS (lammps.cpp/h) is the top-level class for the entire code.  It
-holds an "instance" of LAMMPS and can be instantiated one or more
+holds an ``instance'' of LAMMPS and can be instantiated one or more
 times by a calling code.  For example, the file src/main.cpp simply
 instantiates one instance of LAMMPS and passes it the input script.
 
@@ -81,7 +81,7 @@ enabled by a bit of cleverness in the Pointers class (see
 src/pointers.h) which every class inherits from.
 
 There are a handful of virtual parent classes in LAMMPS that define
-what LAMMPS calls "styles".  They are shaded red in Fig
+what LAMMPS calls ``styles''.  They are shaded red in Fig
 \ref{fig:classes}.  Each of these are parents of a number of child
 classes that implement the interface defined by the parent class.  For
 example, the fix style has around 100 child classes.  They are the
@@ -89,17 +89,17 @@ possible fixes that can be specified by the fix command in an input
 script, e.g. fix nve, fix shake, fix ave/time, etc.  The corresponding
 classes are Fix (for the parent class), FixNVE, FixShake, FixAveTime,
 etc.  The source files for these classes are easy to identify in the
-src directory, since they begin with the word "fix", e,g,
+src directory, since they begin with the word ``fix'', e,g,
 fix\_nve.cpp, fix\_shake,cpp, fix\_ave\_time.cpp, etc.
 
-The one exception is child class files for the "command" style.  These
+The one exception is child class files for the ``command'' style.  These
 implement specific commands in the input script that can be invoked
 before/after/between runs or which launch a simulation.  Examples are
 the create\_box, minimize, run, and velocity commands which encode the
 CreateBox, Minimize, Run, and Velocity classes.  The corresponding
 files are create\_box,cpp, minimize.cpp, run.cpp, and velocity.cpp.
-The list of command style files can be found by typing "grep
-COMMAND\_CLASS *.h" from within the src directory, since that word in
+The list of command style files can be found by typing ``grep
+COMMAND\_CLASS *.h'' from within the src directory, since that word in
 the header file identifies the class as an input script command.
 Similar words can be grepped to list files for the other LAMMPS
 styles.  E.g. ATOM\_CLASS, PAIR\_CLASS, BOND\_CLASS, REGION\_CLASS,
@@ -471,13 +471,13 @@ FixStyle(your/fix/name,FixMine)
   \end{verbatim}
  \end{center}
 
-Where "your/fix/name" is a name of your fix in the script and FixMine
+Where ``your/fix/name'' is a name of your fix in the script and FixMine
 is the name of the class. This code allows LAMMPS to find your fix
 when it parses input script. In addition, your fix header must be
-included in the file "style\_fix.h". In case if you use LAMMPS make,
+included in the file ``style\_fix.h''. In case if you use LAMMPS make,
 this file is generated automatically - all files starting with prefix
 fix\_ are included, so call your header the same way. Otherwise, don't
-forget to add your include into "style\_fix.h".
+forget to add your include into ``style\_fix.h''.
 
 Let's write a simple fix which will print average velocity at the end
 of each timestep. First of all, implement a constructor:
@@ -567,11 +567,11 @@ void FixPrintVel::end_of_step()
 \end{center}
 
 In the code above, we use MathExtra routines defined in
-"math\_extra.h".  There are bunch of math functions to work with
+``math\_extra.h''.  There are bunch of math functions to work with
 arrays of doubles as with math vectors.
 
 In this code we use an instance of Atom class. This object is stored
-in the Pointers class (see "pointers.h"). This object contains all
+in the Pointers class (see ``pointers.h''). This object contains all
 global information about the simulation system. Data from Pointers
 class available to all classes inherited from it using protected
 inheritance. Hence when you write you own class, which is going to use
@@ -689,7 +689,7 @@ int FixSavePos::unpack_exchange(int nlocal, double *buf)
 
 Now, a little bit about memory allocation. We used Memory class which
 is just a bunch of template functions for allocating 1D and 2D
-arrays. So you need to add include "memory.h" to have access to them.
+arrays. So you need to add include ``memory.h'' to have access to them.
 
 Finally, if you need to write/read some global information used in
 your fix to the restart file, you might do it by setting flag

doc/src/Eqs/ptm_rmsd.tex

@@ -0,0 +1,21 @@
+\documentclass[12pt,article]{article}
+
+\usepackage{indentfirst}
+\usepackage{amsmath}
+
+\newcommand{\set}[1]{\ensuremath{\mathbf{#1}}}
+\newcommand{\mean}[1]{\ensuremath{\overline{#1}}}
+\newcommand{\norm}[1]{\ensuremath{\left|\left|{#1}\right|\right|}}
+
+\begin{document}
+
+\begin{equation*}
+\text{RMSD}(\set{u}, \set{v}) = \min_{s, \set{Q}} \sqrt{\frac{1}{N} \sum\limits_{i=1}^{N}
+\norm{
+s[\vec{u_i} - \mean{\set{u}}]
+-
+\set{Q} \vec{v_i}
+}^2}
+\end{equation*}
+
+\end{document}

doc/src/Errors_messages.txt

@@ -1092,11 +1092,6 @@ correct. :dd
 The specified file cannot be opened.  Check that the path and name are
 correct. :dd
 
-{Cannot open fix ave/spatial file %s} :dt
-
-The specified file cannot be opened.  Check that the path and name are
-correct. :dd
-
 {Cannot open fix ave/time file %s} :dt
 
 The specified file cannot be opened.  Check that the path and name are
@@ -1677,10 +1672,6 @@ provided by an atom map.  An atom map does not exist (by default) for
 non-molecular problems.  Using the atom_modify map command will force
 an atom map to be created. :dd
 
-{Cannot use fix ave/spatial z for 2 dimensional model} :dt
-
-Self-explanatory. :dd
-
 {Cannot use fix bond/break with non-molecular systems} :dt
 
 Only systems with bonds that can be changed can be used.  Atom_style
@@ -2425,10 +2416,6 @@ Self-explanatory. :dd
 
 Self-explanatory. :dd
 
-{Compute ID for fix ave/spatial does not exist} :dt
-
-Self-explanatory. :dd
-
 {Compute ID for fix ave/time does not exist} :dt
 
 Self-explanatory. :dd
@@ -4074,10 +4061,6 @@ Self-explanatory. :dd
 
 Self-explanatory. :dd
 
-{Fix ID for fix ave/spatial does not exist} :dt
-
-Self-explanatory. :dd
-
 {Fix ID for fix ave/time does not exist} :dt
 
 Self-explanatory. :dd
@@ -4379,51 +4362,6 @@ same style. :dd
 
 Self-explanatory. :dd
 
-{Fix ave/spatial compute does not calculate a per-atom array} :dt
-
-Self-explanatory. :dd
-
-{Fix ave/spatial compute does not calculate a per-atom vector} :dt
-
-A compute used by fix ave/spatial must generate per-atom values. :dd
-
-{Fix ave/spatial compute does not calculate per-atom values} :dt
-
-A compute used by fix ave/spatial must generate per-atom values. :dd
-
-{Fix ave/spatial compute vector is accessed out-of-range} :dt
-
-The index for the vector is out of bounds. :dd
-
-{Fix ave/spatial fix does not calculate a per-atom array} :dt
-
-Self-explanatory. :dd
-
-{Fix ave/spatial fix does not calculate a per-atom vector} :dt
-
-A fix used by fix ave/spatial must generate per-atom values. :dd
-
-{Fix ave/spatial fix does not calculate per-atom values} :dt
-
-A fix used by fix ave/spatial must generate per-atom values. :dd
-
-{Fix ave/spatial fix vector is accessed out-of-range} :dt
-
-The index for the vector is out of bounds. :dd
-
-{Fix ave/spatial for triclinic boxes requires units reduced} :dt
-
-Self-explanatory. :dd
-
-{Fix ave/spatial settings invalid with changing box size} :dt
-
-If the box size changes, only the units reduced option can be
-used. :dd
-
-{Fix ave/spatial variable is not atom-style variable} :dt
-
-A variable used by fix ave/spatial must generate per-atom values. :dd
-
 {Fix ave/time cannot set output array intensive/extensive from these inputs} :dt
 
 One of more of the vector inputs has individual elements which are

doc/src/Errors_warnings.txt

@@ -291,24 +291,6 @@ This may cause accuracy problems. :dd
 
 This may cause accuracy problems. :dd
 
-{Fix thermal/conductivity comes before fix ave/spatial} :dt
-
-The order of these 2 fixes in your input script is such that fix
-thermal/conductivity comes first.  If you are using fix ave/spatial to
-measure the temperature profile induced by fix viscosity, then this
-may cause a glitch in the profile since you are averaging immediately
-after swaps have occurred.  Flipping the order of the 2 fixes
-typically helps. :dd
-
-{Fix viscosity comes before fix ave/spatial} :dt
-
-The order of these 2 fixes in your input script is such that
-fix viscosity comes first.  If you are using fix ave/spatial
-to measure the velocity profile induced by fix viscosity, then
-this may cause a glitch in the profile since you are averaging
-immediately after swaps have occurred.  Flipping the order
-of the 2 fixes typically helps. :dd
-
 {Fixes cannot send data in Kokkos communication, switching to classic communication} :dt
 
 This is current restriction with Kokkos. :dd

doc/src/Howto_chunk.txt

@@ -22,7 +22,7 @@ commands, to calculate various properties of a system:
 "fix ave/chunk"_fix_ave_chunk.html
 any of the "compute */chunk"_compute.html commands :ul
 
-Here, each of the 3 kinds of chunk-related commands is briefly
+Here, each of the 4 kinds of chunk-related commands is briefly
 overviewed.  Then some examples are given of how to compute different
 properties with chunk commands.
 
@@ -83,8 +83,9 @@ chunk.
 
 Compute */chunk commands: :h4
 
-Currently the following computes operate on chunks of atoms to produce
-per-chunk values.
+The following computes operate on chunks of atoms to produce per-chunk
+values.  Any compute whose style name ends in "/chunk" is in this
+category:
 
 "compute com/chunk"_compute_com_chunk.html
 "compute gyration/chunk"_compute_gyration_chunk.html
@@ -111,8 +112,8 @@ of a center of mass, which requires summing mass*position over the
 atoms and then dividing by summed mass.
 
 All of these computes produce a global vector or global array as
-output, wih one or more values per chunk.  They can be used
-in various ways:
+output, wih one or more values per chunk.  The output can be used in
+various ways:
 
 As input to the "fix ave/time"_fix_ave_time.html command, which can
 write the values to a file and optionally time average them. :ulb,l
@@ -122,9 +123,27 @@ histogram values across chunks.  E.g. a histogram of cluster sizes or
 molecule diffusion rates. :l
 
 As input to special functions of "equal-style
-variables"_variable.html, like sum() and max().  E.g. to find the
-largest cluster or fastest diffusing molecule. :l
-:ule
+variables"_variable.html, like sum() and max() and ave().  E.g. to
+find the largest cluster or fastest diffusing molecule or average
+radius-of-gyration of a set of molecules (chunks). :l,ule
+
+Other chunk commands: :h4
+
+"compute chunk/spread/atom"_compute_chunk_spread_atom.html
+"compute reduce/chunk"_compute_reduce_chunk.html :ul
+
+The "compute chunk/spread/atom"_compute_chunk_spread_atom.html command
+spreads per-chunk values to each atom in the chunk, producing per-atom
+values as its output.  This can be useful for outputting per-chunk
+values to a per-atom "dump file"_dump.html.  Or for using an atom's
+associated chunk value in an "atom-style variable"_variable.html.
+
+The "compute reduce/chunk"_compute_reduce_chunk.html command reduces a
+peratom value across the atoms in each chunk to produce a value per
+chunk.  When used with the "compute
+chunk/spread/atom"_compute_chunk_spread_atom.html command it can
+create peratom values that induce a new set of chunks with a second
+"compute chunk/atom"_compute_chunk_atom.html command.
 
 Example calculations with chunks :h4
 
@@ -164,3 +183,13 @@ compute cluster all cluster/atom 1.0
 compute cc1 all chunk/atom c_cluster compress yes
 compute size all property/chunk cc1 count
 fix 1 all ave/histo 100 1 100 0 20 20 c_size mode vector ave running beyond ignore file tmp.histo :pre
+
+(6) An example of using a per-chunk value to apply per-atom forces to
+compress individual polymer chains (molecules) in a mixture, is
+explained on the "compute
+chunk/spread/atom"_compute_chunk_spread_atom.html command doc page.
+
+(7) An example of using one set of per-chunk values for molecule
+chunks, to create a 2nd set of micelle-scale chunks (clustered
+molecules, due to hydrophobicity), is explained on the "compute
+chunk/reduce"_compute_reduce_chunk.html command doc page.

doc/src/Howto_client_server.txt

@@ -7,7 +7,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :line
 
-Using LAMMPS in client/server mode
+Using LAMMPS in client/server mode :h3
 
 Client/server coupling of two codes is where one code is the "client"
 and sends request messages to a "server" code.  The server responds to
@@ -61,7 +61,7 @@ client or server.
 "message"_message.html
 "fix client md"_fix_client_md.html = LAMMPS is a client for running MD
 "server md"_server_md.html = LAMMPS is a server for computing MD forces
-"server mc"_server_mc.html = LAMMPS is a server for computing a Monte Carlo energy
+"server mc"_server_mc.html = LAMMPS is a server for computing a Monte Carlo energy :ul
 
 The server doc files give details of the message protocols
 for data that is exchanged bewteen the client and server.
@@ -119,7 +119,7 @@ For message exchange in {mpi/one} mode:
 
 Launch both codes in a single mpirun command:
 
-mpirun -np 2 lmp_mpi -mpicolor 0 -in in.message.client -log log.client : -np 4 lmp_mpi -mpicolor 1 -in in.message.server -log log.server
+mpirun -np 2 lmp_mpi -mpicolor 0 -in in.message.client -log log.client : -np 4 lmp_mpi -mpicolor 1 -in in.message.server -log log.server :pre
 
 The two -np values determine how many procs the client and the server
 run on.

doc/src/Howto_nemd.txt

@@ -24,6 +24,11 @@ by subtracting out the streaming velocity of the shearing atoms.  The
 velocity profile or other properties of the fluid can be monitored via
 the "fix ave/chunk"_fix_ave_chunk.html command.
 
+NOTE: A recent (2017) book by "(Daivis and Todd)"_#Daivis-nemd
+discusses use of the SLLOD method and non-equilibrium MD (NEMD)
+thermostatting generally, for both simple and complex fluids,
+e.g. molecular systems.  The latter can be tricky to do correctly.
+
 As discussed in the previous section on non-orthogonal simulation
 boxes, the amount of tilt or skew that can be applied is limited by
 LAMMPS for computational efficiency to be 1/2 of the parallel box
@@ -46,3 +51,9 @@ An alternative method for calculating viscosities is provided via the
 NEMD simulations can also be used to measure transport properties of a fluid
 through a pore or channel. Simulations of steady-state flow can be performed
 using the "fix flow/gauss"_fix_flow_gauss.html command.
+
+:line
+
+:link(Daivis-nemd)
+[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dyanmics (book),
+Cambridge University Press, https://doi.org/10.1017/9781139017848, (2017).

doc/src/Howto_thermostat.txt

@@ -43,6 +43,11 @@ nvt/asphere"_fix_nvt_asphere.html thermostat not only translation
 velocities but also rotational velocities for spherical and aspherical
 particles.
 
+NOTE: A recent (2017) book by "(Daivis and Todd)"_#Daivis-thermostat
+discusses use of the SLLOD method and non-equilibrium MD (NEMD)
+thermostatting generally, for both simple and complex fluids,
+e.g. molecular systems.  The latter can be tricky to do correctly.
+
 DPD thermostatting alters pairwise interactions in a manner analogous
 to the per-particle thermostatting of "fix
 langevin"_fix_langevin.html.
@@ -87,3 +92,9 @@ specify them explicitly via the "thermo_style
 custom"_thermo_style.html command.  Or you can use the
 "thermo_modify"_thermo_modify.html command to re-define what
 temperature compute is used for default thermodynamic output.
+
+:line
+
+:link(Daivis-thermostat)
+[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dyanmics (book),
+Cambridge University Press, https://doi.org/10.1017/9781139017848, (2017).

doc/src/Howto_viscosity.txt

@@ -37,6 +37,11 @@ used to shear the fluid in between them, again with some kind of
 thermostat that modifies only the thermal (non-shearing) components of
 velocity to prevent the fluid from heating up.
 
+NOTE: A recent (2017) book by "(Daivis and Todd)"_#Daivis-viscosity
+discusses use of the SLLOD method and non-equilibrium MD (NEMD)
+thermostatting generally, for both simple and complex fluids,
+e.g. molecular systems.  The latter can be tricky to do correctly.
+
 In both cases, the velocity profile setup in the fluid by this
 procedure can be monitored by the "fix ave/chunk"_fix_ave_chunk.html
 command, which determines grad(Vstream) in the equation above.
@@ -131,3 +136,9 @@ mean-square-displacement formulation for self-diffusivity. The
 time-integrated momentum fluxes play the role of Cartesian
 coordinates, whose mean-square displacement increases linearly
 with time at sufficiently long times.
+
+:line
+
+:link(Daivis-viscosity)
+[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dyanmics (book),
+Cambridge University Press, https://doi.org/10.1017/9781139017848, (2017).

doc/src/Install_linux.txt

@@ -9,39 +9,16 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 Download an executable for Linux :h3
 
-Binaries are available for many different versions of Linux:
+Binaries are available for different versions of Linux:
 
-"Pre-built binary RPMs for Fedora/RedHat/CentOS/openSUSE"_#rpm
 "Pre-built Ubuntu Linux executables"_#ubuntu
+"Pre-built Fedora Linux executables"_#fedora
+"Pre-built EPEL Linux executables (RHEL, CentOS)"_#epel
+"Pre-built OpenSuse Linux executables"_#opensuse
 "Pre-built Gentoo Linux executable"_#gentoo :all(b)
 
 :line
 
-Pre-built binary RPMs for Fedora/RedHat/CentOS/openSUSE :h4,link(rpm)
-
-Pre-built LAMMPS executables for various Linux distributions
-can be downloaded as binary RPM files from this site:
-
-"http://rpm.lammps.org"_http://rpm.lammps.org
-
-There are multiple package variants supporting serial, parallel and
-Python wrapper versions.  The LAMMPS binaries contain all optional
-packages included in the source distribution except: GPU, KIM, REAX,
-and USER-INTEL.
-
-Installation instructions for the various versions are here:
-
-"http://rpm.lammps.org/install.html"_http://rpm.lammps.org/install.html
-
-The instructions show how to enable the repository in the respective
-system's package management system.  Installing and updating are then
-straightforward and automatic.  
-
-Thanks to Axel Kohlmeyer (Temple U, akohlmey at gmail.com) for setting
-up this RPM capability.
-
-:line
-
 Pre-built Ubuntu Linux executables :h4,link(ubuntu)
 
 A pre-built LAMMPS executable suitable for running on the latest
@@ -60,10 +37,10 @@ To install LAMMPS do the following once:
 
 sudo apt-get install lammps-daily :pre
 
-This downloads an executable named "lammps-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:
 
-lammps-daily < in.lj :pre
+lmp_daily -in in.lj :pre
 
 To update LAMMPS to the most current version, do the following:
 
@@ -99,6 +76,80 @@ Ubuntu package capability.
 
 :line
 
+Pre-built Fedora Linux executables :h4,link(fedora)
+
+Pre-built LAMMPS packages for stable releases are available
+in the Fedora Linux distribution as of version 28. The packages
+can be installed via the dnf package manager. There are 3 basic
+varieties (lammps = no MPI, lammps-mpich = MPICH MPI library,
+lammps-openmpi = OpenMPI MPI library) and for each support for
+linking to the C library 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} in all 3 cases.
+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").
+Then the corresponding parallel LAMMPS executable is 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:
+
+dnf install lammps-openmpi
+module load mpi/openmpi-x86_64
+mpirun -np 2 lmp -in in.lj :pre
+
+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
+or shell terminal instance, unless it is automatically loaded from the
+shell profile.
+
+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.
+
+:line
+
+Pre-built EPEL Linux executable :h4,link(epel)
+
+Pre-built LAMMPS packages for stable releases are available
+in the "Extra Packages for Enterprise Linux (EPEL) repository"_https://fedoraproject.org/wiki/EPEL
+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"
+in Fedora 28.
+
+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.
+
+:line
+
+Pre-built OpenSuse Linux executable :h4,link(opensuse)
+
+A pre-built LAMMPS package for stable releases is available
+in OpenSuse as of Leap 15.0. You can install the package with:
+
+zypper install lammps :pre
+
+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:
+
+mpirun -np 2 lmp -in in.lj :pre
+
+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 OpenSuse.
+
+:line
+
 Pre-built Gentoo Linux executable :h4,link(gentoo)
 
 LAMMPS is part of Gentoo's main package tree and can be installed by

doc/src/Install_mac.txt

@@ -49,7 +49,8 @@ Lennard-Jones benchmark file:
 % brew test lammps -v :pre
 
 If you have problems with the installation you can post issues to
-"this link"_https://github.com/Homebrew/homebrew-science/issues.
+"this link"_homebrew.
 
 Thanks to Derek Thomas (derekt at cello.t.u-tokyo.ac.jp) for setting
 up the Homebrew capability.
+:link(homebrew,https://github.com/Homebrew/homebrew-science/issues)

doc/src/Install_tarball.txt

@@ -7,7 +7,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :line
 
-Download source as a tarball :h3
+Download source and documentation as a tarball :h3
 
 You can download a current LAMMPS tarball from the "download page"_download
 of the "LAMMPS website"_lws.
@@ -22,6 +22,10 @@ few times per year, and undergo more testing before release.  Patch
 releases occur a couple times per month.  The new contents in all
 releases are listed on the "bug and feature page"_bug of the website.
 
+Both tarballs include LAMMPS documentation (HTML and PDF files)
+corresponding to that version.  The download page also has an option
+to download the current-version LAMMPS documentation by itself.
+
 Older versions of LAMMPS can also be downloaded from "this
 page"_older.
 

doc/src/Manual.txt

@@ -1,7 +1,7 @@
 <!-- HTML_ONLY -->
 <HEAD>
 <TITLE>LAMMPS Users Manual</TITLE>
-<META NAME="docnumber" CONTENT="5 Sep 2018 version">
+<META NAME="docnumber" CONTENT="15 Nov 2018 version">
 <META NAME="author" CONTENT="http://lammps.sandia.gov - Sandia National Laboratories">
 <META NAME="copyright" CONTENT="Copyright (2003) Sandia Corporation. This software and manual is distributed under the GNU General Public License.">
 </HEAD>
@@ -21,7 +21,7 @@
 :line
 
 LAMMPS Documentation :c,h1
-5 Sep 2018 version :c,h2
+15 Nov 2018 version :c,h2
 
 "What is a LAMMPS version?"_Manual_version.html
 

doc/src/Packages_details.txt

@@ -46,6 +46,7 @@ as contained in the file name.
 "MANYBODY"_#PKG-MANYBODY,
 "MC"_#PKG-MC,
 "MEAM"_#PKG-MEAM,
+"MESSAGE"_#PKG-MESSAGE,
 "MISC"_#PKG-MISC,
 "MOLECULE"_#PKG-MOLECULE,
 "MPIIO"_#PKG-MPIIO,
@@ -88,11 +89,14 @@ as contained in the file name.
 "USER-NETCDF"_#PKG-USER-NETCDF,
 "USER-OMP"_#PKG-USER-OMP,
 "USER-PHONON"_#PKG-USER-PHONON,
+"USER-PLUMED"_#PKG-USER-PLUMED,
+"USER-PTM"_#PKG-USER-PTM,
 "USER-QMMM"_#PKG-USER-QMMM,
 "USER-QTB"_#PKG-USER-QTB,
 "USER-QUIP"_#PKG-USER-QUIP,
 "USER-REAXC"_#PKG-USER-REAXC,
-"USER-SCAFACOS"_#USER-SCAFACOS,
+"USER-SCAFACOS"_#PKG-USER-SCAFACOS,
+"USER-SDPD"_#PKG-USER-SDPD,
 "USER-SMD"_#PKG-USER-SMD,
 "USER-SMTBQ"_#PKG-USER-SMTBQ,
 "USER-SPH"_#PKG-USER-SPH,
@@ -460,10 +464,10 @@ dynamics can be run with LAMMPS using density-functional tight-binding
 quantum forces calculated by LATTE.
 
 More information on LATTE can be found at this web site:
-"https://github.com/lanl/LATTE"_latte_home.  A brief technical
+"https://github.com/lanl/LATTE"_latte-home.  A brief technical
 description is given with the "fix latte"_fix_latte.html command.
 
-:link(latte_home,https://github.com/lanl/LATTE)
+:link(latte-home,https://github.com/lanl/LATTE)
 
 [Authors:] Christian Negre (LANL) and Steve Plimpton (Sandia).  LATTE
 itself is developed at Los Alamos National Laboratory by Marc
@@ -666,9 +670,9 @@ MSCG package :link(PKG-mscg),h4
 
 A "fix mscg"_fix_mscg.html command which can parameterize a
 Multi-Scale Coarse-Graining (MSCG) model using the open-source "MS-CG
-library"_mscg_home.
+library"_mscg-home.
 
-:link(mscg_home,https://github.com/uchicago-voth/MSCG-release)
+:link(mscg-home,https://github.com/uchicago-voth/MSCG-release)
 
 To use this package you must have the MS-CG library available on your
 system.
@@ -1006,11 +1010,11 @@ VORONOI package :link(PKG-VORONOI),h4
 [Contents:]
 
 A compute command which calculates the Voronoi tesselation of a
-collection of atoms by wrapping the "Voro++ library"_voro_home.  This
+collection of atoms by wrapping the "Voro++ library"_voro-home.  This
 can be used to calculate the local volume or each atoms or its near
 neighbors.
 
-:link(voro_home,http://math.lbl.gov/voro++)
+:link(voro-home,http://math.lbl.gov/voro++)
 
 To use this package you must have the Voro++ library available on your
 system.
@@ -1184,7 +1188,7 @@ the NAMD MD code, but with portability in mind.  Axel Kohlmeyer
 [Install:] 
 
 This package has "specific installation
-instructions"_Build_extras.html#gpu on the "Build
+instructions"_Build_extras.html#user-colvars on the "Build
 extras"_Build_extras.html doc page.
 
 [Supporting info:]
@@ -1198,6 +1202,36 @@ examples/USER/colvars :ul
 
 :line
 
+USER-PLUMED package :link(PKG-USER-PLUMED),h4
+
+[Contents:]
+
+The fix plumed command allows you to use the PLUMED free energy plugin
+for molecular dynamics to analyse and bias your LAMMPS trajectory on
+the fly.  The PLUMED library is called from within the LAMMPS input
+script by using the "fix plumed _fix_plumed.html command.
+
+[Authors:] The "PLUMED library"_#PLUMED is written and maintained by
+Massimilliano Bonomi, Giovanni Bussi, Carlo Camiloni and Gareth
+Tribello.
+
+:link(PLUMED,http://www.plumed.org)
+
+[Install:]
+
+This package has "specific installation
+instructions"_Build_extras.html#gpu on the "Build
+extras"_Build_extras.html doc page.
+
+[Supporting info:]
+
+src/USER-PLUMED/README
+lib/plumed/README
+"fix plumed"_fix_plumed.html
+examples/USER/plumed :ul
+
+:line
+
 USER-DIFFRACTION package :link(PKG-USER-DIFFRACTION),h4
 
 [Contents:]
@@ -1518,7 +1552,7 @@ USER-MEAMC package :link(PKG-USER-MEAMC),h4
 [Contents:]
 
 A pair style for the modified embedded atom (MEAM) potential
-translated from the Fortran version in the "MEAM"_MEAM package
+translated from the Fortran version in the "MEAM"_#PKG-MEAM package
 to plain C++. In contrast to the MEAM package, no library
 needs to be compiled and the pair style can be instantiated
 multiple times.
@@ -1599,7 +1633,7 @@ USER-MOLFILE package :link(PKG-USER-MOLFILE),h4
 [Contents:]
 
 A "dump molfile"_dump_molfile.html command which uses molfile plugins
-that are bundled with the "VMD"_vmd_home
+that are bundled with the "VMD"_vmd-home
 molecular visualization and analysis program, to enable LAMMPS to dump
 snapshots in formats compatible with various molecular simulation
 tools.
@@ -1651,11 +1685,11 @@ Note that NetCDF files can be directly visualized with the following
 tools:
 
 "Ovito"_ovito (Ovito supports the AMBER convention and the extensions mentioned above)
-"VMD"_vmd_home
+"VMD"_vmd-home
 "AtomEye"_atomeye (the libAtoms version of AtomEye contains a NetCDF reader not present in the standard distribution) :ul
 
 :link(ovito,http://www.ovito.org)
-:link(vmd_home,https://www.ks.uiuc.edu/Research/vmd/)
+:link(vmd-home,https://www.ks.uiuc.edu/Research/vmd/)
 :link(atomeye,http://www.libatoms.org)
 
 [Author:] Lars Pastewka (Karlsruhe Institute of Technology).
@@ -1743,6 +1777,25 @@ examples/USER/phonon :ul
 
 :line
 
+USER-PTM package :link(PKG-USER-PTM),h4
+
+[Contents:]
+
+A "compute ptm/atom"_compute_ptm_atom.html command that calculates
+local structure characterization using the Polyhedral Template
+Matching methodology.
+
+[Author:] Peter Mahler Larsen (MIT).
+
+[Supporting info:]
+
+src/USER-PTM: filenames not starting with ptm_ -> commands
+src/USER-PTM: filenames starting with ptm_ -> supporting code
+src/USER-PTM/LICENSE
+"compute ptm/atom"_compute_ptm_atom.html :ul
+
+:line
+
 USER-QMMM package :link(PKG-USER-QMMM),h4
 
 [Contents:]
@@ -1860,7 +1913,7 @@ examples/reax :ul
 
 :line
 
-USER-SCAFACOS package :link(USER-SCAFACOS),h4
+USER-SCAFACOS package :link(PKG-USER-SCAFACOS),h4
 
 [Contents:]
 
@@ -1895,6 +1948,31 @@ examples/USER/scafacos :ul
 
 :line
 
+USER-SDPD package :link(PKG-USER-SDPD),h4
+
+[Contents:]
+
+A pair style for smoothed dissipative particle dynamics (SDPD), which
+is an extension of smoothed particle hydrodynamics (SPH) to mesoscale
+where thermal fluctuations are important (see the
+"USER-SPH package"_#PKG-USER-SPH).
+Also two fixes for moving and rigid body integration of SPH/SDPD particles
+(particles of atom_style meso).
+
+[Author:] Morteza Jalalvand (Institute for Advanced Studies in Basic
+Sciences, Iran).
+
+[Supporting info:]
+
+src/USER-SDPD: filenames -> commands
+src/USER-SDPD/README
+"pair_style sdpd/taitwater/isothermal"_pair_sdpd_taitwater_isothermal.html
+"fix meso/move"_fix_meso_move.html
+"fix rigid/meso"_fix_rigid_meso.html
+examples/USER/sdpd :ul
+
+:line
+
 USER-SMD package :link(PKG-USER-SMD),h4
 
 [Contents:]

doc/src/Packages_user.txt

@@ -62,14 +62,20 @@ Package, Description, Doc page, Example, Library
 "USER-NETCDF"_Packages_details.html#PKG-USER-NETCDF, dump output via NetCDF,"dump netcdf"_dump_netcdf.html, n/a, ext
 "USER-OMP"_Packages_details.html#PKG-USER-OMP, OpenMP-enabled styles,"Speed omp"_Speed_omp.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, no
 "USER-PHONON"_Packages_details.html#PKG-USER-PHONON, phonon dynamical matrix,"fix phonon"_fix_phonon.html, USER/phonon, no
+"USER-PLUMED"_Packages_details.html#PKG-USER-PLUMED, "PLUMED"_#PLUMED free energy library,"fix plumed"_fix_plumed.html, USER/plumed, ext
+"USER-PTM"_Packages_details.html#PKG-USER-PTM, Polyhedral Template Matching,"compute ptm/atom"_compute_ptm_atom.html, n/a, no
 "USER-QMMM"_Packages_details.html#PKG-USER-QMMM, QM/MM coupling,"fix qmmm"_fix_qmmm.html, USER/qmmm, ext
 "USER-QTB"_Packages_details.html#PKG-USER-QTB, quantum nuclear effects,"fix qtb"_fix_qtb.html "fix qbmsst"_fix_qbmsst.html, qtb, no
 "USER-QUIP"_Packages_details.html#PKG-USER-QUIP, QUIP/libatoms interface,"pair_style quip"_pair_quip.html, USER/quip, ext
 "USER-REAXC"_Packages_details.html#PKG-USER-REAXC, ReaxFF potential (C/C++) ,"pair_style reaxc"_pair_reaxc.html, reax, no
 "USER-SCAFACOS"_Packages_details.html#PKG-USER-SCAFACOS, wrapper on ScaFaCoS solver,"kspace_style scafacos"_kspace_style.html, USER/scafacos, ext
+"USER-SDPD"_Packages_details.html#PKG-USER-SDPD, smoothed dissipative particle dynamics,"pair_style sdpd/taitwater/isothermal"_pair_sdpd_taitwater_isothermal.html, USER/sdpd, no
 "USER-SMD"_Packages_details.html#PKG-USER-SMD, smoothed Mach dynamics,"SMD User Guide"_PDF/SMD_LAMMPS_userguide.pdf, USER/smd, ext
 "USER-SMTBQ"_Packages_details.html#PKG-USER-SMTBQ, second moment tight binding QEq potential,"pair_style smtbq"_pair_smtbq.html, USER/smtbq, no
 "USER-SPH"_Packages_details.html#PKG-USER-SPH, smoothed particle hydrodynamics,"SPH User Guide"_PDF/SPH_LAMMPS_userguide.pdf, USER/sph, no
 "USER-TALLY"_Packages_details.html#PKG-USER-TALLY, pairwise tally computes,"compute XXX/tally"_compute_tally.html, USER/tally, no
 "USER-UEF"_Packages_details.html#PKG-USER-UEF, extensional flow,"fix nvt/uef"_fix_nh_uef.html, USER/uef, no
 "USER-VTK"_Packages_details.html#PKG-USER-VTK, dump output via VTK, "compute vtk"_dump_vtk.html, n/a, ext :tb(ea=c,ca1=l)
+
+:link(MOFplus,https://www.mofplus.org/content/show/MOF-FF)
+:link(PLUMED,http://www.plumed.org)

doc/src/Run_options.txt

@@ -24,8 +24,9 @@ letter abbreviation can be used:
 "-p or -partition"_#partition
 "-pl or -plog"_#plog
 "-ps or -pscreen"_#pscreen
-"-r or -restart"_#restart
 "-ro or -reorder"_#reorder
+"-r2data or -restart2data"_#restart2data
+"-r2dump or -restart2dump"_#restart2dump
 "-sc or -screen"_#screen
 "-sf or -suffix"_#suffix
 "-v or -var"_#var :ul
@@ -176,7 +177,7 @@ Option -plog will override the name of the partition log files file.N.
 
 :line
 
-[-mpicolor] color :link(mpi)
+[-mpicolor] color :link(mpicolor)
 
 If used, this must be the first command-line argument after the LAMMPS
 executable name.  It is only used when LAMMPS is launched by an mpirun
@@ -280,34 +281,6 @@ specified by the -screen command-line option.
 
 :line
 
-[-restart restartfile {remap} datafile keyword value ...] :link(restart)
-
-Convert the restart file into a data file and immediately exit.  This
-is the same operation as if the following 2-line input script were
-run:
-
-read_restart restartfile {remap}
-write_data datafile keyword value ... :pre
-
-Note that the specified restartfile and datafile can have wild-card
-characters ("*",%") as described by the
-"read_restart"_read_restart.html and "write_data"_write_data.html
-commands.  But a filename such as file.* will need to be enclosed in
-quotes to avoid shell expansion of the "*" character.
-
-Note that following restartfile, the optional flag {remap} can be
-used.  This has the same effect as adding it to the
-"read_restart"_read_restart.html command, as explained on its doc
-page.  This is only useful if the reading of the restart file triggers
-an error that atoms have been lost.  In that case, use of the remap
-flag should allow the data file to still be produced.
-
-Also note that following datafile, the same optional keyword/value
-pairs can be listed as used by the "write_data"_write_data.html
-command.
-
-:line
-
 [-reorder] :link(reorder)
 
 This option has 2 forms:
@@ -381,6 +354,77 @@ the LAMMPS simulation domain.
 
 :line
 
+[-restart2data restartfile (remap) datafile keyword value ...] :link(restart2data)
+
+Convert the restart file into a data file and immediately exit.  This
+is the same operation as if the following 2-line input script were
+run:
+
+read_restart restartfile (remap)
+write_data datafile keyword value ... :pre
+
+Note that the specified restartfile and/or datafile can have the
+wild-card character "*".  The restartfile can also have the wild-card
+character "%".  The meaning of these characters is explained on the
+"read_restart"_read_restart.html and "write_data"_write_data.html doc
+pages.  The use of "%" means that a parallel restart file can be read.
+Note that a filename such as file.* will need to be enclosed in quotes
+to avoid shell expansion of the "*" character.
+
+Note that following restartfile, the optional word "remap" can be
+used.  This has the effect of adding it to the
+"read_restart"_read_restart.html command, as explained on its doc
+page.  This is useful if reading the restart file triggers an error
+that atoms have been lost.  In that case, use of the remap flag should
+allow the data file to still be produced.
+
+The syntax following restartfile (or remap), namely
+
+datafile keyword value ... :pre
+
+is identical to the arguments of the "write_data"_write_data.html
+command.  See its doc page for details.  This includes its
+optional keyword/value settings.
+
+:line
+
+[-restart2dump restartfile {remap} group-ID dumpstyle dumpfile arg1 arg2 ...] :link(restart2dump)
+
+Convert the restart file into a dump file and immediately exit.  This
+is the same operation as if the following 2-line input script were
+run:
+
+read_restart restartfile (remap)
+write_dump group-ID dumpstyle dumpfile arg1 arg2 ... :pre
+
+Note that the specified restartfile and dumpfile can have wild-card
+characters ("*","%") as explained on the
+"read_restart"_read_restart.html and "write_dump"_write_dump.html doc
+pages.  The use of "%" means that a parallel restart file and/or
+parallel dump file can be read and/or written.  Note that a filename
+such as file.* will need to be enclosed in quotes to avoid shell
+expansion of the "*" character.
+
+Note that following restartfile, the optional word "remap" can be
+used.  This has the effect as adding it to the
+"read_restart"_read_restart.html command, as explained on its doc
+page.  This is useful if reading the restart file triggers an error
+that atoms have been lost.  In that case, use of the remap flag should
+allow the dump file to still be produced.
+
+The syntax following restartfile (or remap), namely
+
+group-ID dumpstyle dumpfile arg1 arg2 ... :pre
+
+is identical to the arguments of the "write_dump"_write_dump.html
+command.  See its doc page for details.  This includes what per-atom
+fields are written to the dump file and optional dump_modify settings,
+including ones that affect how parallel dump files are written, e.g.
+the {nfile} and {fileper} keywords.  See the
+"dump_modify"_dump_modify.html doc page for details.
+
+:line
+
 [-screen file] :link(screen)
 
 Specify a file for LAMMPS to write its screen information to.  In

doc/src/Speed_intel.txt

@@ -499,7 +499,7 @@ MPI task.
 When offloading to a coprocessor, "hybrid"_pair_hybrid.html styles
 that require skip lists for neighbor builds cannot be offloaded.
 Using "hybrid/overlay"_pair_hybrid.html is allowed.  Only one intel
-accelerated style may be used with hybrid styles.
+accelerated style may be used with hybrid styles when offloading.
 "Special_bonds"_special_bonds.html exclusion lists are not currently
 supported with offload, however, the same effect can often be
 accomplished by setting cutoffs for excluded atom types to 0.  None of

doc/src/Speed_kokkos.txt

@@ -106,6 +106,11 @@ modification to the input script is needed. Alternatively, one can run
 with the KOKKOS package by editing the input script as described
 below.
 
+NOTE: When using a single OpenMP thread, the Kokkos Serial backend (i.e. 
+Makefile.kokkos_mpi_only) will give better performance than the OpenMP 
+backend (i.e. Makefile.kokkos_omp) because some of the overhead to make 
+the code thread-safe is removed. 
+
 NOTE: The default for the "package kokkos"_package.html command is to
 use "full" neighbor lists and set the Newton flag to "off" for both
 pairwise and bonded interactions. However, when running on CPUs, it
@@ -122,6 +127,22 @@ mpirun -np 16 lmp_kokkos_mpi_only -k on -sf kk -pk kokkos newton on neigh half c
 If the "newton"_newton.html command is used in the input
 script, it can also override the Newton flag defaults.
 
+For half neighbor lists and OpenMP, the KOKKOS package uses data 
+duplication (i.e. thread-private arrays) by default to avoid 
+thread-level write conflicts in the force arrays (and other data 
+structures as necessary). Data duplication is typically fastest for 
+small numbers of threads (i.e. 8 or less) but does increase memory 
+footprint and is not scalable to large numbers of threads. An 
+alternative to data duplication is to use thread-level atomics, which 
+don't require duplication. The use of atomics can be forced by compiling 
+with the "-DLMP_KOKKOS_USE_ATOMICS" compile switch. Most but not all 
+Kokkos-enabled pair_styles support data duplication. Alternatively, full 
+neighbor lists avoid the need for duplication or atomics but require 
+more compute operations per atom. When using the Kokkos Serial backend 
+or the OpenMP backend with a single thread, no duplication or atomics are 
+used. For CUDA and half neighbor lists, the KOKKOS package always uses 
+atomics.
+
 [Core and Thread Affinity:]
 
 When using multi-threading, it is important for performance to bind

doc/src/angle_class2.txt

@@ -7,8 +7,8 @@
 :line
 
 angle_style class2 command :h3
-angle_style class2/omp command :h3
 angle_style class2/kk command :h3
+angle_style class2/omp command :h3
 angle_style class2/p6 command :h3
 
 [Syntax:]

doc/src/angle_cosine_buck6d.txt

@@ -38,10 +38,10 @@ Theta0 (degrees) :ul
 Theta0 is specified in degrees, but LAMMPS converts it to radians 
 internally.
 
-Additional to the cosine term the {cosine/buck6d} angle style computes 
-the short range (vdW) interaction belonging to the 
-"pair_buck6d"_pair_buck6d_coul_gauss.html between the end atoms of 
-the angle.  For this reason this angle style only works in combination
+Additional to the cosine term the {cosine/buck6d} angle style computes
+the short range (vdW) interaction belonging to the
+"pair_buck6d"_pair_buck6d_coul_gauss.html between the end atoms of the
+angle.  For this reason this angle style only works in combination
 with the "pair_buck6d"_pair_buck6d_coul_gauss.html styles and needs
 the "special_bonds"_special_bonds.html 1-3 interactions to be weighted
 0.0 to prevent double counting.

doc/src/angle_sdk.txt

@@ -7,6 +7,7 @@
 :line
 
 angle_style sdk command :h3
+angle_style sdk/omp command :h3
 
 [Syntax:]
 
@@ -43,6 +44,30 @@ internally; hence the units of K are in energy/radian^2.
 The also required {lj/sdk} parameters will be extracted automatically
 from the pair_style.
 
+:line
+
+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 "Speed packages"_Speed_packages.html 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 "Build
+package"_Build_package.html 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 "-suffix command-line
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
+
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restrictions:]
 
 This angle style can only be used if LAMMPS was built with the

doc/src/angle_style.txt

@@ -62,18 +62,27 @@ which are included in the LAMMPS distribution.  The full list of all
 angle styles are is on the "Commands bond"_Commands_bond.html#angle
 doc page.
 
-"angle_style none"_angle_none.html - turn off angle interactions
-"angle_style zero"_angle_zero.html - topology but no interactions
-"angle_style hybrid"_angle_hybrid.html - define multiple styles of angle interactions :ul
+"none"_angle_none.html - turn off angle interactions
+"zero"_angle_zero.html - topology but no interactions
+"hybrid"_angle_hybrid.html - define multiple styles of angle interactions :ul
 
-"angle_style charmm"_angle_charmm.html - CHARMM angle
-"angle_style class2"_angle_class2.html - COMPASS (class 2) angle
-"angle_style cosine"_angle_cosine.html - cosine angle potential
-"angle_style cosine/delta"_angle_cosine_delta.html - difference of cosines angle potential
-"angle_style cosine/periodic"_angle_cosine_periodic.html - DREIDING angle
-"angle_style cosine/squared"_angle_cosine_squared.html - cosine squared angle potential
-"angle_style harmonic"_angle_harmonic.html - harmonic angle
-"angle_style table"_angle_table.html - tabulated by angle :ul
+"charmm"_angle_charmm.html - CHARMM angle
+"class2"_angle_class2.html - COMPASS (class 2) angle
+"class2/p6"_angle_class2.html - COMPASS (class 2) angle expanded to 6th order
+"cosine"_angle_cosine.html - angle with cosine term
+"cosine/buck6d"_angle_cosine_buck6d.html - same as cosine with Buckingham term between 1-3 atoms
+"cosine/delta"_angle_cosine_delta.html - angle with difference of cosines
+"cosine/periodic"_angle_cosine_periodic.html - DREIDING angle
+"cosine/shift"_angle_cosine_shift.html - angle cosine with a shift
+"cosine/shift/exp"_angle_cosine_shift_exp.html - cosine with shift and exponential term in spring constant
+"cosine/squared"_angle_cosine_squared.html - angle with cosine squared term
+"dipole"_angle_dipole.html - angle that controls orientation of a point dipole
+"fourier"_angle_fourier.html - angle with multiple cosine terms
+"fourier/simple"_angle_fourier_simple.html - angle with a single cosine term
+"harmonic"_angle_harmonic.html - harmonic angle
+"quartic"_angle_quartic.html - angle with cubic and quartic terms
+"sdk"_angle_sdk.html - harmonic angle with repulsive SDK pair style between 1-3 atoms
+"table"_angle_table.html - tabulated by angle :ul
 
 :line
 

doc/src/balance.txt

@@ -516,3 +516,4 @@ appear in {dimstr} for the {shift} style.
 "fix balance"_fix_balance.html
 
 [Default:] none
+:link(pizza,http://pizza.sandia.gov)

doc/src/bond_oxdna.txt

@@ -28,34 +28,44 @@ The {oxdna/fene} and {oxdna2/fene} bond styles use the potential
 
 :c,image(Eqs/bond_oxdna_fene.jpg)
 
-to define a modified finite extensible nonlinear elastic (FENE) potential
-"(Ouldridge)"_#oxdna_fene to model the connectivity of the phosphate backbone
-in the oxDNA force field for coarse-grained modelling of DNA.
+to define a modified finite extensible nonlinear elastic (FENE)
+potential "(Ouldridge)"_#oxdna_fene to model the connectivity of the
+phosphate backbone in the oxDNA force field for coarse-grained
+modelling of DNA.
 
 The following coefficients must be defined for the bond type via the
-"bond_coeff"_bond_coeff.html command as given in the above example, or in
-the data file or restart files read by the "read_data"_read_data.html
-or "read_restart"_read_restart.html commands:
+"bond_coeff"_bond_coeff.html command as given in the above example, or
+in the data file or restart files read by the
+"read_data"_read_data.html or "read_restart"_read_restart.html
+commands:
 
 epsilon (energy)
 Delta (distance)
 r0 (distance) :ul
 
-NOTE: The oxDNA bond style has to be used together with the corresponding oxDNA pair styles
-for excluded volume interaction {oxdna/excv}, stacking {oxdna/stk}, cross-stacking {oxdna/xstk}
-and coaxial stacking interaction {oxdna/coaxstk} as well as hydrogen-bonding interaction {oxdna/hbond} (see also documentation of
-"pair_style oxdna/excv"_pair_oxdna.html). For the oxDNA2 "(Snodin)"_#oxdna2 bond style the analogous pair styles and an additional Debye-Hueckel pair
-style {oxdna2/dh} have to be defined.
-The coefficients in the above example have to be kept fixed and cannot be changed without reparametrizing the entire model.
+NOTE: The oxDNA bond style has to be used together with the
+corresponding oxDNA pair styles for excluded volume interaction
+{oxdna/excv}, stacking {oxdna/stk}, cross-stacking {oxdna/xstk} and
+coaxial stacking interaction {oxdna/coaxstk} as well as
+hydrogen-bonding interaction {oxdna/hbond} (see also documentation of
+"pair_style oxdna/excv"_pair_oxdna.html). For the oxDNA2
+"(Snodin)"_#oxdna2 bond style the analogous pair styles and an
+additional Debye-Hueckel pair style {oxdna2/dh} have to be defined.
+The coefficients in the above example have to be kept fixed and cannot
+be changed without reparametrizing the entire model.
 
-Example input and data files for DNA duplexes can be found in examples/USER/cgdna/examples/oxDNA/ and /oxDNA2/.
-A simple python setup tool which creates single straight or helical DNA strands,
-DNA duplexes or arrays of DNA duplexes can be found in examples/USER/cgdna/util/.
+Example input and data files for DNA duplexes can be found in
+examples/USER/cgdna/examples/oxDNA/ and /oxDNA2/.  A simple python
+setup tool which creates single straight or helical DNA strands, DNA
+duplexes or arrays of DNA duplexes can be found in
+examples/USER/cgdna/util/.
 
-Please cite "(Henrich)"_#Henrich2 and the relevant oxDNA articles in any publication that uses this implementation. 
-The article contains more information on the model, the structure of the input file, the setup tool
-and the performance of the LAMMPS-implementation of oxDNA.
-The preprint version of the article can be found "here"_PDF/USER-CGDNA.pdf.
+Please cite "(Henrich)"_#Henrich2 and the relevant oxDNA articles in
+any publication that uses this implementation.  The article contains
+more information on the model, the structure of the input file, the
+setup tool and the performance of the LAMMPS-implementation of oxDNA.
+The preprint version of the article can be found
+"here"_PDF/USER-CGDNA.pdf.
 
 :line
 
@@ -65,20 +75,25 @@ This bond style can only be used if LAMMPS was built with the
 USER-CGDNA package and the MOLECULE and ASPHERE package.  See the
 "Build package"_Build_package.html doc page for more info.
 
-
 [Related commands:]
 
-"pair_style oxdna/excv"_pair_oxdna.html, "pair_style oxdna2/excv"_pair_oxdna2.html, "fix nve/dotc/langevin"_fix_nve_dotc_langevin.html, "bond_coeff"_bond_coeff.html
+"pair_style oxdna/excv"_pair_oxdna.html, "pair_style
+oxdna2/excv"_pair_oxdna2.html, "fix
+nve/dotc/langevin"_fix_nve_dotc_langevin.html,
+"bond_coeff"_bond_coeff.html
 
 [Default:] none
 
 :line
 
 :link(Henrich2)
-[(Henrich)] O. Henrich, Y. A. Gutierrez-Fosado, T. Curk, T. E. Ouldridge, Eur. Phys. J. E 41, 57 (2018).
+[(Henrich)] O. Henrich, Y. A. Gutierrez-Fosado, T. Curk,
+T. E. Ouldridge, Eur. Phys. J. E 41, 57 (2018).
 
 :link(oxdna_fene)
-[(Ouldridge)] T.E. Ouldridge, A.A. Louis, J.P.K. Doye, J. Chem. Phys. 134, 085101 (2011).
+[(Ouldridge)] T.E. Ouldridge, A.A. Louis, J.P.K. Doye,
+J. Chem. Phys. 134, 085101 (2011).
 
 :link(oxdna2)
-[(Snodin)] B.E. Snodin, F. Randisi, M. Mosayebi, et al., J. Chem. Phys. 142, 234901 (2015).
+[(Snodin)] B.E. Snodin, F. Randisi, M. Mosayebi, et al.,
+J. Chem. Phys. 142, 234901 (2015).

doc/src/bond_style.txt

@@ -69,18 +69,23 @@ Note that there are also additional bond styles submitted by users
 which are included in the LAMMPS distribution.  The full list of all
 bond styles is on the "Commands bond"_Commands_bond.html doc page.
 
-"bond_style none"_bond_none.html - turn off bonded interactions
-"bond_style zero"_bond_zero.html - topology but no interactions
-"bond_style hybrid"_bond_hybrid.html - define multiple styles of bond interactions :ul
+"none"_bond_none.html - turn off bonded interactions
+"zero"_bond_zero.html - topology but no interactions
+"hybrid"_bond_hybrid.html - define multiple styles of bond interactions :ul
 
-"bond_style class2"_bond_class2.html - COMPASS (class 2) bond
-"bond_style fene"_bond_fene.html - FENE (finite-extensible non-linear elastic) bond
-"bond_style fene/expand"_bond_fene_expand.html - FENE bonds with variable size particles
-"bond_style harmonic"_bond_harmonic.html - harmonic bond
-"bond_style morse"_bond_morse.html - Morse bond
-"bond_style nonlinear"_bond_nonlinear.html - nonlinear bond
-"bond_style quartic"_bond_quartic.html - breakable quartic bond
-"bond_style table"_bond_table.html - tabulated by bond length :ul
+"class2"_bond_class2.html - COMPASS (class 2) bond
+"fene"_bond_fene.html - FENE (finite-extensible non-linear elastic) bond
+"fene/expand"_bond_fene_expand.html - FENE bonds with variable size particles
+"gromos"_bond_gromos.html - GROMOS force field bond
+"harmonic"_bond_harmonic.html - harmonic bond
+"harmonic/shift"_bond_harmonic_shift.html - shifted harmonic bond
+"harmonic/shift/cut"_bond_harmonic_shift_cut.html - shifted harmonic bond with a cutoff
+"morse"_bond_morse.html - Morse bond
+"nonlinear"_bond_nonlinear.html - nonlinear bond
+"oxdna/fene"_bond_oxdna.html - modified FENE bond suitable for DNA modeling
+"oxdna2/fene"_bond_oxdna.html - same as oxdna but used with different pair styles 
+"quartic"_bond_quartic.html - breakable quartic bond
+"table"_bond_table.html - tabulated by bond length :ul
 
 :line
 

doc/src/commands_list.txt

@@ -44,6 +44,7 @@ Commands :h1
    fix_modify
    group
    group2ndx
+   hyper
    if
    improper_coeff
    improper_style
@@ -89,6 +90,8 @@ Commands :h1
    run
    run_style
    server
+   server_mc
+   server_md
    set
    shell
    special_bonds

doc/src/compute.txt

@@ -175,40 +175,64 @@ The individual style names on the "Commands
 compute"_Commands_compute.html doc page are followed by one or more of
 (g,i,k,o,t) to indicate which accelerated styles exist.
 
+"ackland/atom"_compute_ackland_atom.html - 
+"adf"_compute_adf.html - angular distribution function
 "aggregate/atom"_compute_cluster_atom.html - aggregate ID for each atom
+"angle"_compute_angle.html - 
+"angle/local"_compute_angle_local.html - 
 "angle/local"_compute_bond_local.html - theta and energy of each angle
 "angmom/chunk"_compute_angmom_chunk.html - angular momentum for each chunk
+"basal/atom"_compute_basal_atom.html - 
 "body/local"_compute_body_local.html - attributes of body sub-particles
 "bond"_compute_bond.html - values computed by a bond style
 "bond/local"_compute_bond_local.html - distance and energy of each bond
 "centro/atom"_compute_centro_atom.html - centro-symmetry parameter for each atom
 "chunk/atom"_compute_chunk_atom.html - assign chunk IDs to each atom
+"chunk/spread/atom"_compute_chunk_spread_atom.html - spreads chunk values to each atom in chunk
 "cluster/atom"_compute_cluster_atom.html - cluster ID for each atom
 "cna/atom"_compute_cna_atom.html - common neighbor analysis (CNA) for each atom
+"cnp/atom"_compute_cnp_atom.html - 
 "com"_compute_com.html - center-of-mass of group of atoms
 "com/chunk"_compute_com_chunk.html - center-of-mass for each chunk
 "contact/atom"_compute_contact_atom.html - contact count for each spherical particle
 "coord/atom"_compute_coord_atom.html - coordination number for each atom
 "damage/atom"_compute_damage_atom.html - Peridynamic damage for each atom
+"dihedral"_compute_dihedral.html - 
 "dihedral/local"_compute_dihedral_local.html - angle of each dihedral
 "dilatation/atom"_compute_dilatation_atom.html - Peridynamic dilatation for each atom
+"dipole/chunk"_compute_dipole_chunk.html - 
 "displace/atom"_compute_displace_atom.html - displacement of each atom
+"dpd"_compute_dpd.html - 
+"dpd/atom"_compute_dpd_atom.html - 
+"edpd/temp/atom"_compute_edpd_temp_atom.html - 
+"entropy/atom"_compute_entropy_atom.html - 
 "erotate/asphere"_compute_erotate_asphere.html - rotational energy of aspherical particles
 "erotate/rigid"_compute_erotate_rigid.html - rotational energy of rigid bodies
 "erotate/sphere"_compute_erotate_sphere.html - rotational energy of spherical particles
 "erotate/sphere/atom"_compute_erotate_sphere.html - rotational energy for each spherical particle
+"erotate/sphere/atom"_compute_erotate_sphere_atom.html - 
 "event/displace"_compute_event_displace.html - detect event on atom displacement
+"fep"_compute_fep.html - 
+"force/tally"_compute_tally.html - 
 "fragment/atom"_compute_cluster_atom.html - fragment ID for each atom
+"global/atom"_compute_global_atom.html - 
 "group/group"_compute_group_group.html - energy/force between two groups of atoms
 "gyration"_compute_gyration.html - radius of gyration of group of atoms
 "gyration/chunk"_compute_gyration_chunk.html - radius of gyration for each chunk
 "heat/flux"_compute_heat_flux.html - heat flux through a group of atoms
+"heat/flux/tally"_compute_tally.html - 
 "hexorder/atom"_compute_hexorder_atom.html - bond orientational order parameter q6
+"improper"_compute_improper.html - 
 "improper/local"_compute_improper_local.html - angle of each improper
 "inertia/chunk"_compute_inertia_chunk.html - inertia tensor for each chunk
 "ke"_compute_ke.html - translational kinetic energy
 "ke/atom"_compute_ke_atom.html - kinetic energy for each atom
+"ke/atom/eff"_compute_ke_atom_eff.html - 
+"ke/eff"_compute_ke_eff.html - 
 "ke/rigid"_compute_ke_rigid.html - translational kinetic energy of rigid bodies
+"meso/e/atom"_compute_meso_e_atom.html - 
+"meso/rho/atom"_compute_meso_rho_atom.html - 
+"meso/t/atom"_compute_meso_t_atom.html - 
 "msd"_compute_msd.html - mean-squared displacement of group of atoms
 "msd/chunk"_compute_msd_chunk.html - mean-squared displacement for each chunk
 "msd/nongauss"_compute_msd_nongauss.html - MSD and non-Gaussian parameter of group of atoms
@@ -218,36 +242,77 @@ compute"_Commands_compute.html doc page are followed by one or more of
 "pair/local"_compute_pair_local.html - distance/energy/force of each pairwise interaction
 "pe"_compute_pe.html - potential energy
 "pe/atom"_compute_pe_atom.html - potential energy for each atom
+"pe/mol/tally"_compute_tally.html - 
+"pe/tally"_compute_tally.html - 
 "plasticity/atom"_compute_plasticity_atom.html - Peridynamic plasticity for each atom
 "pressure"_compute_pressure.html - total pressure and pressure tensor
+"pressure/cylinder"_compute_pressure_cylinder.html - 
+"pressure/uef"_compute_pressure_uef.html - 
 "property/atom"_compute_property_atom.html - convert atom attributes to per-atom vectors/arrays
-"property/local"_compute_property_local.html - convert local attributes to localvectors/arrays
 "property/chunk"_compute_property_chunk.html - extract various per-chunk attributes
+"property/local"_compute_property_local.html - convert local attributes to localvectors/arrays
+"ptm/atom"_compute_ptm_atom.html - 
 "rdf"_compute_rdf.html - radial distribution function g(r) histogram of group of atoms
 "reduce"_compute_reduce.html - combine per-atom quantities into a single global value
+"reduce/chunk"_compute_reduce_chunk.html - reduce per-atom quantities within each chunk
 "reduce/region"_compute_reduce.html - same as compute reduce, within a region
 "rigid/local"_compute_rigid_local.html - extract rigid body attributes
+"saed"_compute_saed.html - 
 "slice"_compute_slice.html - extract values from global vector or array
+"smd/contact/radius"_compute_smd_contact_radius.html - 
+"smd/damage"_compute_smd_damage.html - 
+"smd/hourglass/error"_compute_smd_hourglass_error.html - 
+"smd/internal/energy"_compute_smd_internal_energy.html - 
+"smd/plastic/strain"_compute_smd_plastic_strain.html - 
+"smd/plastic/strain/rate"_compute_smd_plastic_strain_rate.html - 
+"smd/rho"_compute_smd_rho.html - 
+"smd/tlsph/defgrad"_compute_smd_tlsph_defgrad.html - 
+"smd/tlsph/dt"_compute_smd_tlsph_dt.html - 
+"smd/tlsph/num/neighs"_compute_smd_tlsph_num_neighs.html - 
+"smd/tlsph/shape"_compute_smd_tlsph_shape.html - 
+"smd/tlsph/strain"_compute_smd_tlsph_strain.html - 
+"smd/tlsph/strain/rate"_compute_smd_tlsph_strain_rate.html - 
+"smd/tlsph/stress"_compute_smd_tlsph_stress.html - 
+"smd/triangle/vertices"_compute_smd_triangle_vertices.html -
+"smd/triangle/vertices"_compute_smd_triangle_vertices.html - 
+"smd/ulsph/num/neighs"_compute_smd_ulsph_num_neighs.html - 
+"smd/ulsph/strain"_compute_smd_ulsph_strain.html - 
+"smd/ulsph/strain/rate"_compute_smd_ulsph_strain_rate.html - 
+"smd/ulsph/stress"_compute_smd_ulsph_stress.html - 
+"smd/vol"_compute_smd_vol.html - 
 "sna/atom"_compute_sna_atom.html - calculate bispectrum coefficients for each atom
 "snad/atom"_compute_sna_atom.html - derivative of bispectrum coefficients for each atom
 "snav/atom"_compute_sna_atom.html - virial contribution from bispectrum coefficients for each atom
+"spin"_compute_spin.html - 
 "stress/atom"_compute_stress_atom.html - stress tensor for each atom
+"stress/mop"_compute_stress_mop.html - 
+"stress/mop/profile"_compute_stress_mop.html - 
+"stress/tally"_compute_tally.html - 
+"tdpd/cc/atom"_compute_tdpd_cc_atom.html - 
 "temp"_compute_temp.html - temperature of group of atoms
 "temp/asphere"_compute_temp_asphere.html - temperature of aspherical particles
 "temp/body"_compute_temp_body.html - temperature of body particles
 "temp/chunk"_compute_temp_chunk.html - temperature of each chunk
 "temp/com"_compute_temp_com.html - temperature after subtracting center-of-mass velocity
+"temp/cs"_compute_temp_cs.html - 
 "temp/deform"_compute_temp_deform.html - temperature excluding box deformation velocity
+"temp/deform/eff"_compute_temp_deform_eff.html - 
+"temp/drude"_compute_temp_drude.html - 
+"temp/eff"_compute_temp_eff.html - 
 "temp/partial"_compute_temp_partial.html - temperature excluding one or more dimensions of velocity
 "temp/profile"_compute_temp_profile.html - temperature excluding a binned velocity profile
 "temp/ramp"_compute_temp_ramp.html - temperature excluding ramped velocity component
 "temp/region"_compute_temp_region.html - temperature of a region of atoms
+"temp/region/eff"_compute_temp_region_eff.html - 
+"temp/rotate"_compute_temp_rotate.html - 
 "temp/sphere"_compute_temp_sphere.html - temperature of spherical particles
+"temp/uef"_compute_temp_uef.html - 
 "ti"_compute_ti.html - thermodynamic integration free energy values
 "torque/chunk"_compute_torque_chunk.html - torque applied on each chunk
 "vacf"_compute_vacf.html - velocity-autocorrelation function of group of atoms
 "vcm/chunk"_compute_vcm_chunk.html - velocity of center-of-mass for each chunk
-"voronoi/atom"_compute_voronoi_atom.html - Voronoi volume and neighbors for each atom :ul
+"voronoi/atom"_compute_voronoi_atom.html - Voronoi volume and neighbors for each atom
+"xrd"_compute_xrd.html - :ul
 
 [Restrictions:] none
 

doc/src/compute_adf.txt

@@ -0,0 +1,213 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+compute adf command :h3
+
+[Syntax:]
+
+compute ID group-ID adf Nbin itype1 jtype1 ktype1 Rjinner1 Rjouter1 Rkinner1 Rkouter1 ... :pre
+
+ID, group-ID are documented in "compute"_compute.html command :ulb,l
+adf = style name of this compute command :l
+Nbin = number of ADF bins :l
+itypeN = central atom type for Nth ADF histogram (see asterisk form below) :l
+jtypeN = J atom type for Nth ADF histogram (see asterisk form below) :l
+ktypeN = K atom type for Nth ADF histogram (see asterisk form below) :l
+RjinnerN =  inner radius of J atom shell for Nth ADF histogram (distance units) :l
+RjouterN =  outer radius of J atom shell for Nth ADF histogram (distance units) :l
+RkinnerN = inner radius of K atom shell for Nth ADF histogram (distance units) :l
+RkouterN =  outer radius of K atom shell for Nth ADF histogram (distance units) :l
+
+zero or one keyword/value pairs may be appended :l
+keyword = {ordinate} :l
+  {ordinate} value = {degree} or {radian} or {cosine}
+    Choose the ordinate parameter for the histogram :pre
+:ule
+
+[Examples:]
+
+compute 1 fluid adf 32 1 1 1 0.0 1.2 0.0 1.2 &
+                       1 1 2 0.0 1.2 0.0 1.5 &
+                       1 2 2 0.0 1.5 0.0 1.5 & 
+                       2 1 1 0.0 1.2 0.0 1.2 &
+                       2 1 2 0.0 1.5 2.0 3.5 &
+                       2 2 2 2.0 3.5 2.0 3.5  
+compute 1 fluid adf 32 1*2 1*2 1*2 0.5 3.5
+compute 1 fluid adf 32 :pre
+
+[Description:]
+
+Define a computation that calculates one or more angular distribution functions
+(ADF) for a group of particles.  Each ADF is calculated in histogram form 
+by measuring the angle formed by a central atom and two neighbor atoms and
+binning these angles into {Nbin} bins.
+Only neighbors for which {Rinner} < {R} < {Router} are counted, where
+{Rinner} and {Router} are specified separately for the first and second
+neighbor atom in each requested ADF. 
+
+NOTE: If you have a bonded system, then the settings of
+"special_bonds"_special_bonds.html command can remove pairwise
+interactions between atoms in the same bond, angle, or dihedral.  This
+is the default setting for the "special_bonds"_special_bonds.html
+command, and means those pairwise interactions do not appear in the
+neighbor list.  Because this fix uses a neighbor list, it also means
+those pairs will not be included in the ADF. This does not apply when
+using long-range coulomb interactions ({coul/long}, {coul/msm},
+{coul/wolf} or similar.  One way to get around this would be to set
+special_bond scaling factors to very tiny numbers that are not exactly
+zero (e.g. 1.0e-50). Another workaround is to write a dump file, and
+use the "rerun"_rerun.html command to compute the ADF for snapshots in
+the dump file.  The rerun script can use a
+"special_bonds"_special_bonds.html command that includes all pairs in
+the neighbor list.
+
+NOTE: If you request any outer cutoff {Router} > force cutoff, or if no 
+pair style is defined,  e.g. the "rerun"_rerun.html command is being used to
+post-process a dump file of snapshots you must insure ghost atom information 
+out to the largest value of {Router} + {skin} is communicated, via the 
+"comm_modify cutoff"_comm_modify.html command, else the ADF computation 
+cannot be performed, and LAMMPS will give an error message.  The {skin} value 
+is what is specified with the "neighbor"_neighbor.html command.  
+
+The {itypeN},{jtypeN},{ktypeN} settings can be specified in one of two
+ways.  An explicit numeric value can be used, as in the 1st example
+above.  Or a wild-card asterisk can be used to specify a range of atom
+types as in the 2nd example above.  
+This takes the form "*" or "*n" or "n*" or "m*n".  If N = the
+number of atom types, then an asterisk with no numeric values means
+all types from 1 to N.  A leading asterisk means all types from 1 to n
+(inclusive).  A trailing asterisk means all types from n to N
+(inclusive).  A middle asterisk means all types from m to n
+(inclusive).
+
+If {itypeN}, {jtypeN}, and {ktypeN} are single values, as in the 1st example
+above, this means that the ADF is computed where atoms of type {itypeN}
+are the central atom, and neighbor atoms of type {jtypeN} and {ktypeN}
+are forming the angle.  If any of {itypeN}, {jtypeN}, or {ktypeN} 
+represent a range of values via
+the wild-card asterisk, as in the 2nd example above, this means that the
+ADF is computed where atoms of any of the range of types represented
+by {itypeN} are the central atom, and the angle is formed by two neighbors,
+one neighbor in the range of types represented by {jtypeN} and another neighbor 
+in the range of types represented by {ktypeN}. 
+
+If no {itypeN}, {jtypeN}, {ktypeN} settings are specified, then
+LAMMPS will generate a single ADF for all atoms in the group.
+The inner cutoff is set to zero and the outer cutoff is set
+to the force cutoff. If no pair_style is specified, there is no
+force cutoff and LAMMPS will give an error message. Note that
+in most cases, generating an ADF for all atoms is not a good thing.
+Such an ADF is both uninformative and
+extremely expensive to compute.  For example, with liquid water
+with a 10 A force cutoff, there are 80,000 angles per atom.
+In addition, most of the interesting angular structure occurs for
+neighbors that are the closest to the central atom, involving 
+just a few dozen angles.
+
+Angles for each ADF are generated by double-looping over the list of 
+neighbors of each central atom I, 
+just as they would be in the force calculation for 
+a threebody potential such as "Stillinger-Weber"_pair_sw.html.  
+The angle formed by central atom I and neighbor atoms J and K is included in an
+ADF if the following criteria are met:
+
+atoms I,J,K are all in the specified compute group
+the distance between atoms I,J is between Rjinner and Rjouter
+the distance between atoms I,K is between Rkinner and Rkouter
+the type of the I atom matches itypeN (one or a range of types)
+atoms I,J,K are distinct
+the type of the J atom matches jtypeN (one or a range of types) 
+the type of the K atom matches ktypeN (one or a range of types) :ul
+
+Each unique angle satisfying the above criteria is counted only once, regardless
+of whether either or both of the neighbor atoms making up the
+angle appear in both the J and K lists. 
+It is OK if a particular angle is included in more than
+one individual histogram, due to the way the {itypeN}, {jtypeN}, {ktypeN}
+arguments are specified.
+
+The first ADF value for a bin is calculated from the histogram count by
+dividing by the total number of triples satisfying the criteria,
+so that the integral of the ADF w.r.t. angle is 1, i.e. the ADF
+is a probability density function.
+
+The second ADF value is reported as a cumulative sum of
+all bins up to the current bins, averaged
+over atoms of type {itypeN}. It represents the
+number of angles per central atom with angle less
+than or equal to the angle of the current bin,
+analogous to the coordination
+number radial distribution function.
+
+The {ordinate} optional keyword determines
+whether the bins are of uniform angular size from zero
+to 180 ({degree}), zero to Pi ({radian}), or the 
+cosine of the angle uniform in the range \[-1,1\] ({cosine}).
+{cosine} has the advantage of eliminating the {acos()} function
+call, which speeds up the compute by 2-3x, and it is also preferred
+on physical grounds, because the for uniformly distributed particles 
+in 3D, the angular probability density w.r.t dtheta is
+sin(theta)/2, while for d(cos(theta)), it is 1/2,  
+Regardless of which ordinate is chosen, the first column of ADF 
+values is normalized w.r.t. the range of that ordinate, so that 
+the integral is 1.
+
+The simplest way to output the results of the compute adf calculation
+to a file is to use the "fix ave/time"_fix_ave_time.html command, for
+example:
+
+compute myADF all adf 32 2 2 2 0.5 3.5 0.5 3.5
+fix 1 all ave/time 100 1 100 c_myADF\[*\] file tmp.adf mode vector :pre
+
+[Output info:]
+
+This compute calculates a global array with the number of rows =
+{Nbins}, and the number of columns = 1 + 2*Ntriples, where Ntriples is the
+number of I,J,K triples specified.  The first column has the bin
+coordinate (angle-related ordinate at midpoint of bin). Each subsequent column has
+the two ADF values for a specific set of ({itypeN},{jtypeN},{ktypeN}) 
+interactions, as described above.  These values can be used
+by any command that uses a global values from a compute as input.  See
+the "Howto output"_Howto_output.html doc page for an overview of
+LAMMPS output options.
+
+The array values calculated by this compute are all "intensive".
+
+The first column of array values is the angle-related ordinate, either
+the angle in degrees or radians, or the cosine of the angle.  Each
+subsequent pair of columns gives the first and second kinds of ADF
+for a specific set of ({itypeN},{jtypeN},{ktypeN}). The values 
+in the first ADF column are normalized numbers >= 0.0,
+whose integral w.r.t. the ordinate is 1,
+i.e. the first ADF is a normalized probability distribution. 
+The values in the second ADF column are also numbers >= 0.0.
+They are the cumulative density distribution of angles per atom.
+By definition, this ADF is monotonically increasing from zero to
+a maximum value equal to the average total number of
+angles per atom satisfying the ADF criteria. 
+
+[Restrictions:]
+
+The ADF is not computed for neighbors outside the force cutoff,
+since processors (in parallel) don't know about atom coordinates for
+atoms further away than that distance.  If you want an ADF for larger
+distances, you can use the "rerun"_rerun.html command to post-process
+a dump file and set the cutoff for the potential to be longer in the
+rerun script.  Note that in the rerun context, the force cutoff is
+arbitrary, since you aren't running dynamics and thus are not changing
+your model.  
+
+[Related commands:]
+
+"compute rdf"_compute_rdf.html, "fix ave/time"_fix_ave_time.html, "compute_modify"_compute_modify.html
+
+[Default:]
+
+The keyword default is ordinate = degree.
+
+

doc/src/compute_angle_local.txt

@@ -10,20 +10,27 @@ compute angle/local command :h3
 
 [Syntax:]
 
-compute ID group-ID angle/local value1 value2 ... :pre
+compute ID group-ID angle/local value1 value2 ... keyword args ... :pre
 
 ID, group-ID are documented in "compute"_compute.html command :ulb,l
 angle/local = style name of this compute command :l
 one or more values may be appended :l
-value = {theta} or {eng} :l
+value = {theta} or {eng} or {v_name} :l
   {theta} = tabulate angles
-  {eng} = tabulate angle energies :pre
+  {eng} = tabulate angle energies
+  {v_name} = equal-style variable with name (see below) :pre
+zero or more keyword/args pairs may be appended :l
+keyword = {set} :l
+  {set} args = theta name
+    theta = only currently allowed arg
+    name = name of variable to set with theta :pre
 :ule
 
 [Examples:]
 
 compute 1 all angle/local theta
-compute 1 all angle/local eng theta :pre
+compute 1 all angle/local eng theta 
+compute 1 all angle/local theta v_cos set theta t :pre
 
 [Description:]
 
@@ -36,6 +43,47 @@ The value {theta} is the angle for the 3 atoms in the interaction.
 
 The value {eng} is the interaction energy for the angle.
 
+The value {v_name} can be used together with the {set} keyword to
+compute a user-specified function of the angle theta.  The {name}
+specified for the {v_name} value is the name of an "equal-style
+variable"_variable.html which should evaluate a formula based on a
+variable which will store the angle theta.  This other variable must
+be an "internal-style variable"_variable.html defined in the input
+script; its initial numeric value can be anything.  It must be an
+internal-style variable, because this command resets its value
+directly.  The {set} keyword is used to identify the name of this
+other variable associated with theta.
+
+Note that the value of theta for each angle which stored in the
+internal variable is in radians, not degrees.
+
+As an example, these commands can be added to the bench/in.rhodo
+script to compute the cosine and cosine^2 of every angle in the system
+and output the statistics in various ways:
+
+variable t internal 0.0
+variable cos equal cos(v_t)
+variable cossq equal cos(v_t)*cos(v_t) :pre
+
+compute 1 all property/local aatom1 aatom2 aatom3 atype
+compute 2 all angle/local eng theta v_cos v_cossq set theta t
+dump 1 all local 100 tmp.dump c_1[*] c_2[*] :pre
+
+compute 3 all reduce ave c_2[*]
+thermo_style custom step temp press c_3[*] :pre
+
+fix 10 all ave/histo 10 10 100 -1 1 20 c_2[3] mode vector file tmp.histo :pre
+
+The "dump local"_dump.html command will output the energy, angle,
+cosine(angle), cosine^2(angle) for every angle in the system.  The
+"thermo_style"_thermo_style.html command will print the average of
+those quantities via the "compute reduce"_compute_reduce.html command
+with thermo output.  And the "fix ave/histo"_fix_ave_histo.html
+command will histogram the cosine(angle) values and write them to a
+file.
+
+:line
+
 The local data stored by this command is generated by looping over all
 the atoms owned on a processor and their angles.  An angle will only
 be included if all 3 atoms in the angle are in the specified compute
@@ -65,12 +113,12 @@ dump 1 all local 1000 tmp.dump index c_1\[1\] c_1\[2\] c_1\[3\] c_1\[4\] c_2\[1\
 [Output info:]
 
 This compute calculates a local vector or local array depending on the
-number of keywords.  The length of the vector or number of rows in the
-array is the number of angles.  If a single keyword is specified, a
-local vector is produced.  If two or more keywords are specified, a
+number of values.  The length of the vector or number of rows in the
+array is the number of angles.  If a single value is specified, a
+local vector is produced.  If two or more values are specified, a
 local array is produced where the number of columns = the number of
-keywords.  The vector or array can be accessed by any command that
-uses local values from a compute as input.  See the "Howto
+values.  The vector or array can be accessed by any command that uses
+local values from a compute as input.  See the "Howto
 output"_Howto_output.html doc page for an overview of LAMMPS output
 options.
 

doc/src/compute_bond_local.txt

@@ -10,12 +10,12 @@ compute bond/local command :h3
 
 [Syntax:]
 
-compute ID group-ID bond/local value1 value2 ... :pre
+compute ID group-ID bond/local value1 value2 ... keyword args ... :pre
 
 ID, group-ID are documented in "compute"_compute.html command :ulb,l
 bond/local = style name of this compute command :l
 one or more values may be appended :l
-value = {dist} or {engpot} or {force} or {engvib} or {engrot} or {engtrans} or {omega} or {velvib} :l
+value = {dist} or {engpot} or {force} or {engvib} or {engrot} or {engtrans} or {omega} or {velvib} or {v_name} :l
   {dist} = bond distance
   {engpot} = bond potential energy
   {force} = bond force :pre
@@ -23,13 +23,22 @@ value = {dist} or {engpot} or {force} or {engvib} or {engrot} or {engtrans} or {
   {engrot} = bond kinetic energy of rotation
   {engtrans} = bond kinetic energy of translation
   {omega} = magnitude of bond angular velocity
-  {velvib} = vibrational velocity along the bond length :pre
+  {velvib} = vibrational velocity along the bond length
+  {v_name} = equal-style variable with name (see below) :pre
+zero or more keyword/args pairs may be appended :l
+keyword = {set} :l
+  {set} args = dist name
+    dist = only currently allowed arg
+    name = name of variable to set with distance (dist) :pre
+:ule
+
 :ule
 
 [Examples:]
 
 compute 1 all bond/local engpot
 compute 1 all bond/local dist engpot force :pre
+compute 1 all angle/local dist v_distsq set dist d :pre
 
 [Description:]
 
@@ -38,6 +47,10 @@ interactions.  The number of datums generated, aggregated across all
 processors, equals the number of bonds in the system, modified by the
 group parameter as explained below.
 
+All these properties are computed for the pair of atoms in a bond,
+whether the 2 atoms represent a simple diatomic molecule, or are part
+of some larger molecule.
+
 The value {dist} is the current length of the bond.
 
 The value {engpot} is the potential energy for the bond,
@@ -79,9 +92,41 @@ two atoms in the bond towards each other.  A negative value means the
 2 atoms are moving toward each other; a positive value means they are
 moving apart.
 
-Note that all these properties are computed for the pair of atoms in a
-bond, whether the 2 atoms represent a simple diatomic molecule, or are
-part of some larger molecule.
+The value {v_name} can be used together with the {set} keyword to
+compute a user-specified function of the bond distance.  The {name}
+specified for the {v_name} value is the name of an "equal-style
+variable"_variable.html which should evaluate a formula based on a
+variable which will store the bond distance.  This other variable must
+be an "internal-style variable"_variable.html defined in the input
+script; its initial numeric value can be anything.  It must be an
+internal-style variable, because this command resets its value
+directly.  The {set} keyword is used to identify the name of this
+other variable associated with theta.
+
+As an example, these commands can be added to the bench/in.rhodo
+script to compute the distance^2 of every bond in the system and
+output the statistics in various ways:
+
+variable d internal 0.0
+variable dsq equal v_d*v_d :pre
+
+compute 1 all property/local batom1 batom2 btype
+compute 2 all bond/local engpot dist v_dsq set dist d
+dump 1 all local 100 tmp.dump c_1[*] c_2[*] :pre
+
+compute 3 all reduce ave c_2[*]
+thermo_style custom step temp press c_3[*] :pre
+
+fix 10 all ave/histo 10 10 100 0 6 20 c_2[3] mode vector file tmp.histo :pre
+
+The "dump local"_dump.html command will output the energy, distance,
+distance^2 for every bond in the system.  The
+"thermo_style"_thermo_style.html command will print the average of
+those quantities via the "compute reduce"_compute_reduce.html command
+with thermo output.  And the "fix ave/histo"_fix_ave_histo.html
+command will histogram the distance^2 values and write them to a file.
+
+:line
 
 The local data stored by this command is generated by looping over all
 the atoms owned on a processor and their bonds.  A bond will only be
@@ -111,12 +156,12 @@ dump 1 all local 1000 tmp.dump index c_1\[*\] c_2\[*\] :pre
 [Output info:]
 
 This compute calculates a local vector or local array depending on the
-number of keywords.  The length of the vector or number of rows in the
-array is the number of bonds.  If a single keyword is specified, a
-local vector is produced.  If two or more keywords are specified, a
-local array is produced where the number of columns = the number of
-keywords.  The vector or array can be accessed by any command that
-uses local values from a compute as input.  See the "Howto
+number of values.  The length of the vector or number of rows in the
+array is the number of bonds.  If a single value is specified, a local
+vector is produced.  If two or more values are specified, a local
+array is produced where the number of columns = the number of values.
+The vector or array can be accessed by any command that uses local
+values from a compute as input.  See the "Howto
 output"_Howto_output.html doc page for an overview of LAMMPS output
 options.
 

doc/src/compute_chunk_atom.txt

@@ -14,7 +14,7 @@ compute ID group-ID chunk/atom style args keyword values ... :pre
 
 ID, group-ID are documented in "compute"_compute.html command :ulb,l
 chunk/atom = style name of this compute command :l
-style = {bin/1d} or {bin/2d} or {bin/3d} or {bin/sphere} or {type} or {molecule} or {compute/fix/variable}
+style = {bin/1d} or {bin/2d} or {bin/3d} or {bin/sphere} or {type} or {molecule} or c_ID, c_ID\[I\], f_ID, f_ID\[I\], v_name
   {bin/1d} args = dim origin delta
     dim = {x} or {y} or {z}
     origin = {lower} or {center} or {upper} or coordinate value (distance units)
@@ -40,7 +40,7 @@ style = {bin/1d} or {bin/2d} or {bin/3d} or {bin/sphere} or {type} or {molecule}
     ncbin = # of concentric circle bins between rmin and rmax
   {type} args = none
   {molecule} args = none
-  {compute/fix/variable} = c_ID, c_ID\[I\], f_ID, f_ID\[I\], v_name with no args
+  c_ID, c_ID\[I\], f_ID, f_ID\[I\], v_name args = none
     c_ID = per-atom vector calculated by a compute with ID
     c_ID\[I\] = Ith column of per-atom array calculated by a compute with ID
     f_ID = per-atom vector calculated by a fix with ID
@@ -85,7 +85,8 @@ compute 1 all chunk/atom bin/1d z lower 0.02 units reduced
 compute 1 all chunk/atom bin/2d z lower 1.0 y 0.0 2.5
 compute 1 all chunk/atom molecule region sphere nchunk once ids once compress yes
 compute 1 all chunk/atom bin/sphere 5 5 5 2.0 5.0 5 discard yes
-compute 1 all chunk/atom bin/cylinder z lower 2 10 10 2.0 5.0 3 discard yes :pre
+compute 1 all chunk/atom bin/cylinder z lower 2 10 10 2.0 5.0 3 discard yes
+compute 1 all chunk/atom c_cluster :pre
 
 [Description:]
 
@@ -386,8 +387,8 @@ described below, which resets {Nchunk}.  The {limit} keyword is then
 applied to the new {Nchunk} value, exactly as described in the
 preceding paragraph.  Note that in this case, all atoms will end up
 with chunk IDs <= {Nc}, but their original values (e.g. molecule ID or
-compute/fix/variable value) may have been > {Nc}, because of the
-compression operation.
+compute/fix/variable) may have been > {Nc}, because of the compression
+operation.
 
 If {compress yes} is set, and the {compress} keyword comes after the
 {limit} keyword, then the {limit} value of {Nc} is applied first to

doc/src/compute_chunk_spread_atom.txt

@@ -0,0 +1,174 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+compute chunk/spread/atom command :h3
+
+[Syntax:]
+
+compute ID group-ID chunk/spread/atom chunkID input1 input2 ... :pre
+
+ID, group-ID are documented in "compute"_compute.html command :ulb,l
+chunk/spread/atom = style name of this compute command :l
+chunkID = ID of "compute chunk/atom"_compute_chunk_atom.html command :l
+one or more inputs can be listed :l
+input = c_ID, c_ID\[N\], f_ID, f_ID\[N\] :l
+  c_ID = global vector calculated by a compute with ID
+  c_ID\[I\] = Ith column of global array calculated by a compute with ID, I can include wildcard (see below)
+  f_ID = global vector calculated by a fix with ID
+  f_ID\[I\] = Ith column of global array calculated by a fix with ID, I can include wildcard (see below) :pre
+:ule
+
+[Examples:]
+
+compute 1 all chunk/spread/atom mychunk c_com[*] c_gyration :pre
+
+[Description:]
+
+Define a calculation that "spreads" one or more per-chunk values to
+each atom in the chunk.  This can be useful for creating a "dump
+file"_dump.html where each atom lists info about the chunk it is in,
+e.g. for post-processing purposes.  It can also be used in "atom-style
+variables"_variable.html that need info about the chunk each atom is
+in.  Examples are given below.
+
+In LAMMPS, chunks are collections of atoms defined by a "compute
+chunk/atom"_compute_chunk_atom.html command, which assigns each atom
+to a single chunk (or no chunk).  The ID for this command is specified
+as chunkID.  For example, a single chunk could be the atoms in a
+molecule or atoms in a spatial bin.  See the "compute
+chunk/atom"_compute_chunk_atom.html and "Howto chunk"_Howto_chunk.html
+doc pages for details of how chunks can be defined and examples of how
+they can be used to measure properties of a system.
+
+For inputs that are computes, they must be a compute that calculates
+per-chunk values.  These are computes whose style names end in
+"/chunk".
+
+For inputs that are fixes, they should be a a fix that calculates
+per-chunk values.  For example, "fix ave/chunk"_fix_ave_chunk.html or
+"fix ave/time"_fix_ave_time.html (assuming it is time-averaging
+per-chunk data).
+
+For each atom, this compute accesses its chunk ID from the specified
+{chunkID} compute, then accesses the per-chunk value in each input.
+Those values are copied to this compute to become the output for that
+atom.
+
+The values generated by this compute will be 0.0 for atoms not in the
+specified compute group {group-ID}.  They will also be 0.0 if the atom
+is not in a chunk, as assigned by the {chunkID} compute.  They will
+also be 0.0 if the current chunk ID for the atom is out-of-bounds with
+respect to the number of chunks stored by a particular input compute
+or fix.
+
+NOTE: LAMMPS does not check that a compute or fix which calculates
+per-chunk values uses the same definition of chunks as this compute.
+It's up to you to be consistent.  Likewise, for a fix input, LAMMPS
+does not check that it is per-chunk data.  It only checks that the fix
+produces a global vector or array.
+
+:line
+
+Each listed input is operated on independently.  
+
+If a bracketed index I is used, it can be specified using a wildcard
+asterisk with the index to effectively specify multiple values.  This
+takes the form "*" or "*n" or "n*" or "m*n".  If N = the number of
+columns in the array, then an asterisk with no numeric values means
+all indices from 1 to N.  A leading asterisk means all indices from 1
+to n (inclusive).  A trailing asterisk means all indices from n to N
+(inclusive).  A middle asterisk means all indices from m to n
+(inclusive).
+
+Using a wildcard is the same as if the individual columns of the array
+had been listed one by one.  E.g. these 2 compute chunk/spread/atom
+commands are equivalent, since the "compute
+com/chunk"_compute_com_chunk.html command creates a per-atom array
+with 3 columns:
+
+compute com all com/chunk mychunk
+compute 10 all chunk/spread/atom mychunk c_com\[*\]
+compute 10 all chunk/spread/atom mychunk c_com\[1\] c_com\[2\] c_com\[3\] :pre
+
+:line
+
+Here is an example of writing a dump file the with the center-of-mass
+(COM) for the chunk each atom is in.  The commands below can be added
+to the bench/in.chain script.
+
+compute         cmol all chunk/atom molecule
+compute         com all com/chunk cmol
+compute         comchunk all chunk/spread/atom cmol c_com[*]
+dump            1 all custom 50 tmp.dump id mol type x y z c_comchunk[*]
+dump_modify     1 sort id :pre
+
+The same per-chunk data for each atom could be used to define per-atom
+forces for the "fix addforce"_fix_addforce.html command.  In this
+example the forces act to pull atoms of an extended polymer chain
+towards its COM in an attractive manner.
+
+compute         prop all property/atom xu yu zu
+variable        k equal 0.1
+variable        fx atom v_k*(c_comchunk\[1\]-c_prop\[1\])
+variable        fy atom v_k*(c_comchunk\[2\]-c_prop\[2\])
+variable        fz atom v_k*(c_comchunk\[3\]-c_prop\[3\])
+fix             3 all addforce v_fx v_fy v_fz :pre
+
+Note that "compute property/atom"_compute_property_atom.html is used
+to generate unwrapped coordinates for use in the per-atom force
+calculation, so that the effect of periodic boundaries is accounted
+for properly.
+
+Over time this applied force could shrink each polymer chain's radius
+of gyration in a polymer mixture simulation.  Here is output from the
+bench/in.chain script.  Thermo output is shown for 1000 steps, where
+the last column is the average radius of gyration over all 320 chains
+in the 32000 atom system:
+
+compute         gyr all gyration/chunk cmol
+variable        ave equal ave(c_gyr)
+thermo_style    custom step etotal press v_ave :pre
+
+       0    22.394765    4.6721833     5.128278 
+     100    22.445002    4.8166709    5.0348372 
+     200    22.500128    4.8790392    4.9364875 
+     300    22.534686    4.9183766    4.8590693 
+     400    22.557196    4.9492211    4.7937849 
+     500    22.571017    4.9161853    4.7412008 
+     600    22.573944    5.0229708    4.6931243 
+     700    22.581804    5.0541301    4.6440647 
+     800    22.584683    4.9691734    4.6000016 
+     900     22.59128    5.0247538    4.5611513 
+    1000    22.586832      4.94697    4.5238362 :pre
+
+:line
+
+[Output info:]
+
+This compute calculates a per-atom vector or array, which can be
+accessed by any command that uses per-atom values from a compute as
+input.  See the "Howto output"_Howto_output.html doc page for an
+overview of LAMMPS output options.
+
+The output is a per-atom vector if a single input value is specified,
+otherwise a per-atom array is output.  The number of columns in the
+array is the number of inputs provided.  The per-atom values for the
+vector or each column of the array will be in whatever
+"units"_units.html the corresponding input value is in.
+
+The vector or array values are "intensive".
+
+[Restrictions:] none
+
+[Related commands:]
+
+"compute chunk/atom"_compute_chunk_atom.html, "fix
+ave/chunk"_fix_ave_chunk.html, "compute
+reduce/chunk"_compute_reduce_chunk.html
+
+[Default:] none

doc/src/compute_dihedral_local.txt

@@ -10,18 +10,25 @@ compute dihedral/local command :h3
 
 [Syntax:]
 
-compute ID group-ID dihedral/local value1 value2 ... :pre
+compute ID group-ID dihedral/local value1 value2 ... keyword args ... :pre
 
 ID, group-ID are documented in "compute"_compute.html command :ulb,l
 dihedral/local = style name of this compute command :l
 one or more values may be appended :l
-value = {phi} :l
-  {phi} = tabulate dihedral angles :pre
+value = {phi} or {v_name} :l
+  {phi} = tabulate dihedral angles
+  {v_name} = equal-style variable with name (see below) :pre
+zero or more keyword/args pairs may be appended :l
+keyword = {set} :l
+  {set} args = phi name
+    phi = only currently allowed arg
+    name = name of variable to set with phi :pre
 :ule
 
 [Examples:]
 
 compute 1 all dihedral/local phi :pre
+compute 1 all dihedral/local phi v_cos set phi p :pre
 
 [Description:]
 
@@ -33,6 +40,47 @@ by the group parameter as explained below.
 The value {phi} is the dihedral angle, as defined in the diagram on
 the "dihedral_style"_dihedral_style.html doc page.
 
+The value {v_name} can be used together with the {set} keyword to
+compute a user-specified function of the dihedral angle phi.  The
+{name} specified for the {v_name} value is the name of an "equal-style
+variable"_variable.html which should evaluate a formula based on a
+variable which will store the angle phi.  This other variable must
+be an "internal-style variable"_variable.html defined in the input
+script; its initial numeric value can be anything.  It must be an
+internal-style variable, because this command resets its value
+directly.  The {set} keyword is used to identify the name of this
+other variable associated with phi.
+
+Note that the value of phi for each angle which stored in the internal
+variable is in radians, not degrees.
+
+As an example, these commands can be added to the bench/in.rhodo
+script to compute the cosine and cosine^2 of every dihedral angle in
+the system and output the statistics in various ways:
+
+variable p internal 0.0
+variable cos equal cos(v_p)
+variable cossq equal cos(v_p)*cos(v_p) :pre
+
+compute 1 all property/local datom1 datom2 datom3 datom4 dtype
+compute 2 all dihedral/local phi v_cos v_cossq set phi p
+dump 1 all local 100 tmp.dump c_1[*] c_2[*] :pre
+
+compute 3 all reduce ave c_2[*]
+thermo_style custom step temp press c_3[*] :pre
+
+fix 10 all ave/histo 10 10 100 -1 1 20 c_2[2] mode vector file tmp.histo :pre
+
+The "dump local"_dump.html command will output the angle,
+cosine(angle), cosine^2(angle) for every dihedral in the system.  The
+"thermo_style"_thermo_style.html command will print the average of
+those quantities via the "compute reduce"_compute_reduce.html command
+with thermo output.  And the "fix ave/histo"_fix_ave_histo.html
+command will histogram the cosine(angle) values and write them to a
+file.
+
+:line
+
 The local data stored by this command is generated by looping over all
 the atoms owned on a processor and their dihedrals.  A dihedral will
 only be included if all 4 atoms in the dihedral are in the specified
@@ -57,12 +105,12 @@ dump 1 all local 1000 tmp.dump index c_1\[1\] c_1\[2\] c_1\[3\] c_1\[4\] c_1\[5\
 [Output info:]
 
 This compute calculates a local vector or local array depending on the
-number of keywords.  The length of the vector or number of rows in the
-array is the number of dihedrals.  If a single keyword is specified, a
-local vector is produced.  If two or more keywords are specified, a
+number of values.  The length of the vector or number of rows in the
+array is the number of dihedrals.  If a single value is specified, a
+local vector is produced.  If two or more values are specified, a
 local array is produced where the number of columns = the number of
-keywords.  The vector or array can be accessed by any command that
-uses local values from a compute as input.  See the "Howto
+values.  The vector or array can be accessed by any command that uses
+local values from a compute as input.  See the "Howto
 output"_Howto_output.html doc page for an overview of LAMMPS output
 options.
 

doc/src/compute_msd_chunk.txt

@@ -90,12 +90,12 @@ This is so that the fix this compute creates to store per-chunk
 quantities will also have the same ID, and thus be initialized
 correctly with chunk reference positions from the restart file.
 
-The simplest way to output the results of the compute com/msd
+The simplest way to output the results of the compute msd/chunk
 calculation to a file is to use the "fix ave/time"_fix_ave_time.html
 command, for example:
 
 compute cc1 all chunk/atom molecule
-compute myChunk all com/msd cc1
+compute myChunk all msd/chunk cc1
 fix 1 all ave/time 100 1 100 c_myChunk\[*\] file tmp.out mode vector :pre
 
 [Output info:]

doc/src/compute_pair.txt

@@ -10,17 +10,20 @@ compute pair command :h3
 
 [Syntax:]
 
-compute ID group-ID pair pstyle evalue :pre
+compute ID group-ID pair pstyle \[nstyle\] \[evalue\]  :pre
 
-ID, group-ID are documented in "compute"_compute.html command
-pair = style name of this compute command
-pstyle = style name of a pair style that calculates additional values
-evalue = {epair} or {evdwl} or {ecoul} or blank (optional setting) :ul
+ID, group-ID are documented in "compute"_compute.html command :ulb,l
+pair = style name of this compute command :l
+pstyle = style name of a pair style that calculates additional values :l
+nsub = {n}-instance of a substyle, if a pair style is used multiple times in a hybrid style :l
+{evalue} = {epair} or {evdwl} or {ecoul} or blank (optional) :l
+:ule
 
 [Examples:]
 
 compute 1 all pair gauss
 compute 1 all pair lj/cut/coul/cut ecoul
+compute 1 all pair tersoff 2 epair
 compute 1 all pair reax :pre
 
 [Description:]
@@ -33,15 +36,19 @@ NOTE: The group specified for this command is [ignored].
 
 The specified {pstyle} must be a pair style used in your simulation
 either by itself or as a sub-style in a "pair_style hybrid or
-hybrid/overlay"_pair_hybrid.html command.
+hybrid/overlay"_pair_hybrid.html command. If the sub-style is
+used more than once, an additional number {nsub} has to be specified
+in order to choose which instance of the sub-style will be used by
+the compute. Not specifying the number in this case will cause the
+compute to fail.
 
-The {evalue} setting is optional; it may be left off the command.  All
+The {evalue} setting is optional.  All
 pair styles tally a potential energy {epair} which may be broken into
 two parts: {evdwl} and {ecoul} such that {epair} = {evdwl} + {ecoul}.
 If the pair style calculates Coulombic interactions, their energy will
 be tallied in {ecoul}.  Everything else (whether it is a Lennard-Jones
 style van der Waals interaction or not) is tallied in {evdwl}.  If
-{evalue} is specified as {epair} or left out, then {epair} is stored
+{evalue} is blank or specified as {epair}, then {epair} is stored
 as a global scalar by this compute.  This is useful when using
 "pair_style hybrid"_pair_hybrid.html if you want to know the portion
 of the total energy contributed by one sub-style.  If {evalue} is
@@ -82,4 +89,4 @@ the doc page for the pair style for details.
 
 [Default:]
 
-The default for {evalue} is {epair}.
+The keyword defaults are {evalue} = {epair}, nsub = 0.

doc/src/compute_pressure_cylinder.txt

@@ -0,0 +1,81 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+compute pressure/cylinder command :h3
+
+[Syntax:]
+
+compute ID group-ID pressure/cylinder zlo zhi Rmax bin_width :pre
+
+ID, group-ID are documented in "compute"_compute.html command
+pressure/cylinder = style name of this compute command
+zlo = minimum z-boundary for cylinder
+zhi = maximum z-boundary for cylinder
+Rmax = maximum radius to perform calculation to
+bin_width = width of radial bins to use for calculation :ul
+
+[Examples:]
+
+compute 1 all pressure/cylinder -10.0 10.0 15.0 0.25 :pre
+
+[Description:]
+
+Define a computation that calculates the pressure tensor of a system in
+cylindrical coordinates, as discussed in "(Addington)"_#Addington1.
+This is useful for systems with a single axis of rotational symmetry,
+such as cylindrical micelles or carbon nanotubes. The compute splits the
+system into radial, cylindrical-shell-type bins of width bin_width,
+centered at x=0,y=0, and calculates the radial (P_rhorho), azimuthal
+(P_phiphi), and axial (P_zz) components of the configurational pressure
+tensor. The local density is also calculated for each bin, so that the
+true pressure can be recovered as P_kin+P_conf=density*k*T+P_conf.  The
+output is a global array with 5 columns; one each for bin radius, local
+number density, P_rhorho, P_phiphi, and P_zz. The number of rows is
+governed by the values of Rmax and bin_width. Pressure tensor values are
+output in pressure units.
+
+[Output info:]
+
+This compute calculates a global array with 5 columns and Rmax/bin_width
+rows. The output columns are: R (distance units), number density (inverse 
+volume units), configurational radial pressure (pressure units), 
+configurational azimuthal pressure (pressure units), and configurational
+axial pressure (pressure units).
+
+The values calculated by this compute are
+"intensive".  The pressure values will be in pressure
+"units"_units.html. The number density values will be in 
+inverse volume "units"_units.html.
+
+[Restrictions:]
+
+This compute currently calculates the pressure tensor contributions
+for pair styles only (i.e. no bond, angle, dihedral, etc. contributions
+and in the presence of bonded interactions, the result will be incorrect
+due to exclusions for special bonds)  and requires pair-wise force
+calculations not available for most manybody pair styles. K-space
+calculations are also excluded. Note that this pressure compute outputs
+the configurational terms only; the kinetic contribution is not included
+and may be calculated from the number density output by P_kin=density*k*T.
+
+This compute is part of the USER-MISC package.  It is only enabled
+if LAMMPS was built with that package.  See the "Build
+package"_Build_package.html doc page for more info.
+
+[Related commands:]
+
+"compute temp"_compute_temp.html, "compute
+stress/atom"_compute_stress_atom.html,
+"thermo_style"_thermo_style.html,
+
+[Default:] none
+
+:line
+
+:link(Addington1)
+[(Addington)] Addington, Long, Gubbins, J Chem Phys, 149, 084109 (2018).

doc/src/compute_ptm_atom.txt

@@ -0,0 +1,121 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+compute ptm/atom command :h3
+
+[Syntax:]
+
+compute ID group-ID ptm/atom structures threshold :pre
+
+ID, group-ID are documented in "compute"_compute.html command
+ptm/atom = style name of this compute command
+structures = structure types to search for
+threshold = lattice distortion threshold (RMSD) :ul
+
+[Examples:]
+
+compute 1 all ptm/atom default 0.1
+compute 1 all ptm/atom fcc-hcp-dcub-dhex 0.15
+compute 1 all ptm/atom all 0 :pre
+
+[Description:]
+
+Define a computation that determines the local lattice structure
+around an atom using the PTM (Polyhedral Template Matching) method.
+The PTM method is described in "(Larsen)"_#Larsen.
+
+Currently, there are seven lattice structures PTM recognizes:
+
+fcc = 1
+hcp = 2
+bcc = 3
+ico (icosahedral) = 4
+sc (simple cubic) = 5
+dcub (diamond cubic) = 6
+dhex (diamond hexagonal) = 7
+other = 8 :ul
+
+The value of the PTM structure will be 0 for atoms not in the specified
+compute group.  The choice of structures to search for can be specified using the "structures"
+argument, which is a hyphen-separated list of structure keywords.
+Two convenient pre-set options are provided:
+
+default: fcc-hcp-bcc-ico
+all: fcc-hcp-bcc-ico-sc-dcub-dhex :ul
+
+The 'default' setting detects the same structures as the Common Neighbor Analysis method.
+The 'all' setting searches for all structure types.  A small performance penalty is
+incurred for the diamond structures, so it is not recommended to use this option if
+it is known that the simulation does not contain diamond structures.
+
+
+PTM identifies structures using two steps.  First, a graph isomorphism test is used
+to identify potential structure matches.  Next, the deviation is computed between the
+local structure (in the simulation) and a template of the ideal lattice structure.
+The deviation is calculated as:
+
+:c,image(Eqs/ptm_rmsd.jpg)
+
+Here, u and v contain the coordinates of the local and ideal structures respectively,
+s is a scale factor, and Q is a rotation.  The best match is identified by the
+lowest RMSD value, using the optimal scaling, rotation, and correspondence between the
+points.
+
+The 'threshold' keyword sets an upper limit on the maximum permitted deviation before
+a local structure is identified as disordered.  Typical values are in the range 0.1-0.15,
+but larger values may be desirable at higher temperatures.
+A value of 0 is equivalent to infinity and can be used if no threshold is desired.
+
+
+The neighbor list needed to compute this quantity is constructed each
+time the calculation is performed (e.g. each time a snapshot of atoms
+is dumped).  Thus it can be inefficient to compute/dump this quantity
+too frequently or to have multiple compute/dump commands, each with a
+{ptm/atom} style.
+
+[Output info:]
+
+This compute calculates a per-atom arry, which can be accessed by
+any command that uses per-atom values from a compute as input.  See
+the "Howto output"_Howto_output.html doc page for an overview of
+LAMMPS output options.
+
+Results are stored in the per-atom array in the following order:
+
+type
+rmsd
+interatomic distance
+qw
+qx
+qy
+qw :ul
+
+The type is a number from 0 to 8.  The rmsd is a positive real number.
+The interatomic distance is computed from the scale factor in the RMSD equation.
+The (qw,qx,qy,qz) parameters represent the orientation of the local structure
+in quaternion form.  The reference coordinates for each template (from which the
+orientation is determined) can be found in the {ptm_constants.h} file in the PTM source directory.
+
+[Restrictions:]
+
+This fix is part of the USER-PTM package.  It is only enabled if
+LAMMPS was built with that package.  See the "Build
+package"_Build_package.html doc page for more info.
+
+[Related commands:]
+
+"compute centro/atom"_compute_centro_atom.html
+"compute cna/atom"_compute_cna_atom.html
+
+[Default:] none
+
+:line
+
+:link(Larsen)
+[(Larsen)] Larsen, Schmidt, Schiotz, Modelling Simul Mater Sci Eng, 24, 055007 (2016).
+

doc/src/compute_rdf.txt

@@ -191,7 +191,8 @@ via "compute_modify dynamic yes"_compute_modify.html
 
 [Related commands:]
 
-"fix ave/time"_fix_ave_time.html, "compute_modify"_compute_modify.html
+"fix ave/time"_fix_ave_time.html, "compute_modify"_compute_modify.html,
+"compute adf"_compute_adf.html
 
 [Default:]
 

doc/src/compute_reduce.txt

@@ -97,9 +97,9 @@ equivalent, since the "compute stress/atom"_compute_stress_atom.html
 command creates a per-atom array with 6 columns:
 
 compute myPress all stress/atom NULL
-compute 2 all reduce min myPress\[*\]
-compute 2 all reduce min myPress\[1\] myPress\[2\] myPress\[3\] &
-                         myPress\[4\] myPress\[5\] myPress\[6\] :pre
+compute 2 all reduce min c_myPress\[*\]
+compute 2 all reduce min c_myPress\[1\] c_myPress\[2\] c_myPress\[3\] &
+                         c_myPress\[4\] c_myPress\[5\] c_myPress\[6\] :pre
 
 :line
 

doc/src/compute_reduce_chunk.txt

@@ -0,0 +1,177 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+compute reduce/chunk command :h3
+
+[Syntax:]
+
+compute ID group-ID reduce/chunk chunkID mode input1 input2 ... :pre
+
+ID, group-ID are documented in "compute"_compute.html command :ulb,l
+reduce/chunk = style name of this compute command :l
+chunkID = ID of "compute chunk/atom"_compute_chunk_atom.html command :l
+mode = {sum} or {min} or {max} :l
+one or more inputs can be listed :l
+input = c_ID, c_ID\[N\], f_ID, f_ID\[N\], v_ID :l
+  c_ID = per-atom vector calculated by a compute with ID
+  c_ID\[I\] = Ith column of per-atom array calculated by a compute with ID, I can include wildcard (see below)
+  f_ID = per-atom vector calculated by a fix with ID
+  f_ID\[I\] = Ith column of per-atom array calculated by a fix with ID, I can include wildcard (see below)
+  v_name = per-atom vector calculated by an atom-style variable with name :pre
+:ule
+
+[Examples:]
+
+compute 1 all reduce/chunk/atom mychunk min c_cluster :pre
+
+[Description:]
+
+Define a calculation that reduces one or more per-atom vectors into
+per-chunk values.  This can be useful for diagnostic output.  Or when
+used in conjunction with the "compute
+chunk/spread/atom"_compute_chunk_spread_atom.html command it can be
+used ot create per-atom values that induce a new set of chunks with a
+second "compute chunk/atom"_compute_chunk_atom.html command.  An
+example is given below.
+
+In LAMMPS, chunks are collections of atoms defined by a "compute
+chunk/atom"_compute_chunk_atom.html command, which assigns each atom
+to a single chunk (or no chunk).  The ID for this command is specified
+as chunkID.  For example, a single chunk could be the atoms in a
+molecule or atoms in a spatial bin.  See the "compute
+chunk/atom"_compute_chunk_atom.html and "Howto chunk"_Howto_chunk.html
+doc pages for details of how chunks can be defined and examples of how
+they can be used to measure properties of a system.
+
+For each atom, this compute accesses its chunk ID from the specified
+{chunkID} compute.  The per-atom value from an input contributes
+to a per-chunk value corresponding the the chunk ID.
+
+The reduction operation is specified by the {mode} setting and is
+performed over all the per-atom values from the atoms in each chunk.
+The {sum} option adds the pre-atom values to a per-chunk total.  The
+{min} or {max} options find the minimum or maximum value of the
+per-atom values for each chunk.
+
+Note that only atoms in the specified group contribute to the
+reduction operation.  If the {chunkID} compute returns a 0 for the
+chunk ID of an atom (i.e. the atom is not in a chunk defined by the
+"compute chunk/atom"_compute_chunk_atom.html command), that atom will
+also not contribute to the reduction operation.  An input that is a
+compute or fix may define its own group which affects the quantities
+it returns.  For example, a compute with return a zero value for atoms
+that are not in the group specified for that compute.
+
+Each listed input is operated on independently.  Each input can be the
+result of a "compute"_compute.html or "fix"_fix.html or the evaluation
+of an atom-style "variable"_variable.html.
+
+Note that for values from a compute or fix, the bracketed index I can
+be specified using a wildcard asterisk with the index to effectively
+specify multiple values.  This takes the form "*" or "*n" or "n*" or
+"m*n".  If N = the size of the vector (for {mode} = scalar) or the
+number of columns in the array (for {mode} = vector), then an asterisk
+with no numeric values means all indices from 1 to N.  A leading
+asterisk means all indices from 1 to n (inclusive).  A trailing
+asterisk means all indices from n to N (inclusive).  A middle asterisk
+means all indices from m to n (inclusive).
+
+Using a wildcard is the same as if the individual columns of the array
+had been listed one by one.  E.g. these 2 compute reduce/chunk
+commands are equivalent, since the "compute
+property/chunk"_compute_property_chunk.html command creates a per-atom
+array with 3 columns:
+
+compute prop all property/atom vx vy vz
+compute 10 all reduce/chunk mychunk max c_prop\[*\]
+compute 10 all reduce/chunk mychunk max c_prop\[1\] c_prop\[2\] c_prop\[3\] :pre
+
+:line
+
+Here is an example of using this compute, in conjunction with the
+compute chunk/spread/atom command to identify self-assembled micelles.
+The commands below can be added to the examples/in.micelle script.
+
+Imagine a collection of polymer chains or small molecules with
+hydrophobic end groups.  All the hydrophobic (HP) atoms are assigned
+to a group called "phobic".
+
+These commands will assign a unique cluster ID to all HP atoms within
+a specified distance of each other.  A cluster will contain all HP
+atoms in a single molecule, but also the HP atoms in nearby molecules,
+e.g. molecules that have clumped to form a micelle due to the
+attraction induced by the hydrophobicity.  The output of the
+chunk/reduce command will be a cluster ID per chunk (molecule).
+Molecules with the same cluster ID are in the same micelle.
+
+group phobic type 4     # specific to in.micelle model
+compute cluster phobic cluster/atom 2.0
+compute cmol all chunk/atom molecule
+compute reduce phobic reduce/chunk cmol min c_cluster :pre
+
+This per-chunk info could be output in at least two ways:
+
+fix 10 all ave/time 1000 1 1000 c_reduce file tmp.phobic mode vector :pre
+
+compute spread all chunk/spread/atom cmol c_reduce
+dump 1 all custom 1000 tmp.dump id type mol x y z c_cluster c_spread
+dump_modify 1 sort id :pre
+
+In the first case, each snapshot in the tmp.phobic file will contain
+one line per molecule.  Molecules with the same value are in the same
+micelle.  In the second case each dump snapshot contains all atoms,
+each with a final field with the cluster ID of the micelle that the HP
+atoms of that atom's molecule belong to.
+
+The result from compute chunk/spread/atom can be used to define a new
+set of chunks, where all the atoms in all the molecules in the same
+micelle are assigned to the same chunk, i.e. one chunk per micelle.
+
+compute micelle all chunk/atom c_spread compress yes :pre
+
+Further analysis on a per-micelle basis can now be performed using any
+of the per-chunk computes listed on the "Howto chunk"_Howto_chunk.html
+doc page.  E.g. count the number of atoms in each micelle, calculate
+its center or mass, shape (moments of intertia), radius of gyration,
+etc.
+
+compute prop all property/chunk micelle count
+fix 20 all ave/time 1000 1 1000 c_prop file tmp.micelle mode vector :pre
+
+Each snapshot in the tmp.micelle file will have one line per micelle
+with its count of atoms, plus a first line for a chunk with all the
+solvent atoms.  By the time 50000 steps have elapsed there are a
+handful of large micelles.
+
+:line
+
+[Output info:]
+
+This compute calculates a global vector if a single input value is
+specified, otherwise a global array is output.  The number of columns
+in the array is the number of inputs provided.  The length of the
+vector or the number of vector elements or array rows = the number of
+chunks {Nchunk} as calculated by the specified "compute
+chunk/atom"_compute_chunk_atom.html command.  The vector or array can
+be accessed by any command that uses global values from a compute as
+input.  See the "Howto output"_Howto_output.html doc page for an
+overview of LAMMPS output options.
+
+The per-atom values for the vector or each column of the array will be
+in whatever "units"_units.html the corresponding input value is in.
+The vector or array values are "intensive".
+
+[Restrictions:] none
+
+[Related commands:]
+
+"compute chunk/atom"_compute_chunk_atom.html, "compute
+reduce"_compute_reduce.html, "compute
+chunk/spread/atom"_compute_chunk_spread_atom.html
+
+[Default:] none

doc/src/compute_smd_triangle_vertices.txt

@@ -6,14 +6,14 @@
 
 :line
 
-compute smd/triangle/mesh/vertices :h3
+compute smd/triangle/vertices command :h3
 
 [Syntax:]
 
-compute ID group-ID smd/triangle/mesh/vertices :pre
+compute ID group-ID smd/triangle/vertices :pre
 
 ID, group-ID are documented in "compute"_compute.html command
-smd/triangle/mesh/vertices = style name of this compute command :ul
+smd/triangle/vertices = style name of this compute command :ul
 
 [Examples:]
 

doc/src/compute_spin.txt

@@ -10,14 +10,14 @@ compute spin command :h3
 
 [Syntax:]
 
-compute ID group-ID compute/spin :pre
+compute ID group-ID spin :pre
 
 ID, group-ID are documented in "compute"_compute.html command
-compute/spin = style name of this compute command :ul
+spin = style name of this compute command :ul
 
 [Examples:]
 
-compute out_mag all compute/spin :pre
+compute out_mag all spin :pre
 
 [Description:]
 
@@ -26,7 +26,8 @@ of atoms having spins.
 
 This compute calculates 6 magnetic quantities.
 
-The three first quantities are the x,y and z coordinates of the total magnetization.
+The three first quantities are the x,y and z coordinates of the total
+magnetization.
 
 The fourth quantity is the norm of the total magnetization.
 
@@ -39,7 +40,7 @@ The simplest way to output the results of the compute spin calculation
 is to define some of the quantities as variables, and to use the thermo and
 thermo_style commands, for example:
 
-compute out_mag		all compute/spin :pre
+compute out_mag		all spin :pre
 
 variable mag_z      	equal c_out_mag\[3\]
 variable mag_norm	equal c_out_mag\[4\]
@@ -53,7 +54,6 @@ the total magnetization, and the magnetic temperature. Three variables are
 assigned to those quantities. The thermo and thermo_style commands print them 
 every 10 timesteps.
 
-
 [Output info:]
 
 The array values are "intensive".  The array values will be in
@@ -68,7 +68,6 @@ has to be "spin" for this compute to be valid.
 
 [Related commands:] none
 
-
 [Default:] none
 
 :line

doc/src/compute_stress_mop.txt

@@ -0,0 +1,111 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+compute stress/mop command :h3
+compute stress/mop/profile command :h3
+
+
+[Syntax:]
+
+compute ID group-ID style dir args keywords ... :pre
+
+ID, group-ID are documented in "compute"_compute.html command
+style = {stress/mop} or {stress/mop/profile}
+dir = {x} or {y} or {z} is the direction normal to the plane
+args = argument specific to the compute style
+keywords = {kin} or {conf} or {total} (one of more can be specified) :ul
+  {stress/mop} args = pos
+    pos = {lower} or {center} or {upper} or coordinate value (distance units) is the position of the plane
+  {stress/mop/profile} args = origin delta
+    origin = {lower} or {center} or {upper} or coordinate value (distance units) is the position of the first plane
+    delta = value (distance units) is the distance between planes :pre
+
+compute 1 all stress/mop x lower total
+compute 1 liquid stress/mop z 0.0 kin conf
+fix 1 all ave/time 10 1000 10000 c_1\[*\] file mop.time
+fix 1 all ave/time 10 1000 10000 c_1\[2\] file mop.time :pre
+
+compute 1 all stress/mop/profile x lower 0.1 total
+compute 1 liquid stress/mop/profile z 0.0 0.25 kin conf
+fix 1 all ave/time 500 20 10000 c_1\[*\] ave running overwrite file mopp.time mode vector :pre
+
+
+[Description:]
+
+Compute {stress/mop} and compute {stress/mop/profile} define computations that
+calculate components of the local stress tensor using the method of
+planes "(Todd)"_#mop-todd.  Specifically in compute {stress/mop} calculates 3
+components are computed in directions {dir},{x}; {dir},{y}; and
+{dir},{z}; where {dir} is the direction normal to the plane, while
+in compute {stress/mop/profile} the profile of the stress is computed.
+
+Contrary to methods based on histograms of atomic stress (i.e. using
+"compute stress/atom"_compute_stress_atom.html), the method of planes is
+compatible with mechanical balance in heterogeneous systems and at
+interfaces "(Todd)"_#mop-todd.
+
+The stress tensor is the sum of a kinetic term and a configurational
+term, which are given respectively by Eq. (21) and Eq. (16) in
+"(Todd)"_#mop-todd. For the kinetic part, the algorithm considers that
+atoms have crossed the plane if their positions at times t-dt and t are
+one on either side of the plane, and uses the velocity at time t-dt/2
+given by the velocity-Verlet algorithm.
+
+Between one and three keywords can be used to indicate which
+contributions to the stress must be computed: kinetic stress (kin),
+configurational stress (conf), and/or total stress (total).
+
+NOTE 1: The configurational stress is computed considering all pairs of atoms where at least one atom belongs to group group-ID. 
+
+NOTE 2: The local stress does not include any Lennard-Jones tail
+corrections to the pressure added by the "pair_modify tail
+yes"_pair_modify.html command, since those are contributions to the global system pressure.
+
+[Output info:]
+
+Compute {stress/mop} calculates a global vector (indices starting at 1), with 3
+values for each declared keyword (in the order the keywords have been
+declared). For each keyword, the stress tensor components are ordered as
+follows: stress_dir,x, stress_dir,y, and stress_dir,z.
+
+Compute {stress/mop/profile} instead calculates a global array, with 1 column
+giving the position of the planes where the stress tensor was computed,
+and with 3 columns of values for each declared keyword (in the order the
+keywords have been declared). For each keyword, the profiles of stress
+tensor components are ordered as follows: stress_dir,x; stress_dir,y;
+and stress_dir,z.
+
+The values are in pressure "units"_units.html. 
+
+The values produced by this compute can be accessed by various "output commands"_Howto_output.html. For instance, the results can be written to a file using the "fix ave/time"_fix_ave_time.html command. Please see the example in the examples/USER/mop folder.
+
+[Restrictions:] 
+
+These styles are part of the USER-MISC package. They are only enabled if
+LAMMPS is built with that package. See the "Build package"_Build_package.html
+doc page on for more info.
+
+The method is only implemented for 3d orthogonal simulation boxes whose
+size does not change in time, and axis-aligned planes.
+
+The method only works with two-body pair interactions, because it
+requires the class method pair->single() to be implemented. In
+particular, it does not work with more than two-body pair interactions,
+intra-molecular interactions, and long range (kspace) interactions.
+
+[Related commands:]
+
+"compute stress/atom"_compute_stress_atom.html
+
+[Default:] none
+
+:line
+
+:link(mop-todd)
+[(Todd)] B. D. Todd, Denis J. Evans, and Peter J. Daivis: "Pressure tensor for inhomogeneous fluids", 
+Phys. Rev. E 52, 1627 (1995).

doc/src/computes.txt

@@ -6,6 +6,7 @@ Computes :h1
    :maxdepth: 1
 
    compute_ackland_atom
+   compute_adf
    compute_angle
    compute_angle_local
    compute_angmom_chunk
@@ -15,6 +16,7 @@ Computes :h1
    compute_bond_local
    compute_centro_atom
    compute_chunk_atom
+   compute_chunk_spread_atom
    compute_cluster_atom
    compute_cna_atom
    compute_cnp_atom
@@ -66,12 +68,15 @@ Computes :h1
    compute_pe_atom
    compute_plasticity_atom
    compute_pressure
+   compute_pressure_cylinder
    compute_pressure_uef
    compute_property_atom
    compute_property_chunk
    compute_property_local
+   compute_ptm_atom
    compute_rdf
    compute_reduce
+   compute_reduce_chunk
    compute_rigid_local
    compute_saed
    compute_slice
@@ -89,7 +94,7 @@ Computes :h1
    compute_smd_tlsph_strain
    compute_smd_tlsph_strain_rate
    compute_smd_tlsph_stress
-   compute_smd_triangle_mesh_vertices
+   compute_smd_triangle_vertices
    compute_smd_ulsph_num_neighs
    compute_smd_ulsph_strain
    compute_smd_ulsph_strain_rate
@@ -98,6 +103,7 @@ Computes :h1
    compute_sna_atom
    compute_spin
    compute_stress_atom
+   compute_stress_mop
    compute_tally
    compute_tdpd_cc_atom
    compute_temp

doc/src/dihedral_nharmonic.txt

@@ -16,7 +16,7 @@ dihedral_style nharmonic :pre
 [Examples:]
 
 dihedral_style nharmonic
-dihedral_coeff 3 10.0 20.0 30.0 :pre
+dihedral_coeff * 3 10.0 20.0 30.0 :pre
 
 [Description:]
 

doc/src/dihedral_style.txt

@@ -85,16 +85,24 @@ which are included in the LAMMPS distribution.  The full list of all
 dihedral styles is on the "Commands bond"_Commands_bond.html#dihedral
 doc page.
 
-"dihedral_style none"_dihedral_none.html - turn off dihedral interactions
-"dihedral_style zero"_dihedral_zero.html - topology but no interactions
-"dihedral_style hybrid"_dihedral_hybrid.html - define multiple styles of dihedral interactions :ul
+"none"_dihedral_none.html - turn off dihedral interactions
+"zero"_dihedral_zero.html - topology but no interactions
+"hybrid"_dihedral_hybrid.html - define multiple styles of dihedral interactions :ul
 
-"dihedral_style charmm"_dihedral_charmm.html - CHARMM dihedral
-"dihedral_style class2"_dihedral_class2.html - COMPASS (class 2) dihedral
-"dihedral_style harmonic"_dihedral_harmonic.html - harmonic dihedral
-"dihedral_style helix"_dihedral_helix.html - helix dihedral
-"dihedral_style multi/harmonic"_dihedral_multi_harmonic.html - multi-harmonic dihedral
-"dihedral_style opls"_dihedral_opls.html - OPLS dihedral :ul
+"charmm"_dihedral_charmm.html - CHARMM dihedral
+"charmmfsw"_dihedral_charmm.html - CHARMM dihedral with force switching
+"class2"_dihedral_class2.html - COMPASS (class 2) dihedral
+"cosine/shift/exp"_dihedral_cosine_shift_exp.html - dihedral with exponential in spring constant
+"fourier"_dihedral_fourier.html - dihedral with multiple cosine terms
+"harmonic"_dihedral_harmonic.html - harmonic dihedral
+"helix"_dihedral_helix.html - helix dihedral
+"multi/harmonic"_dihedral_multi_harmonic.html - dihedral with 5 harmonic terms
+"nharmonic"_dihedral_nharmonic.html - same as multi-harmonic with N terms
+"opls"_dihedral_opls.html - OPLS dihedral
+"quadratic"_dihedral_quadratic.html - dihedral with quadratic term in angle
+"spherical"_dihedral_spherical.html - dihedral which includes angle terms to avoid singularities
+"table"_dihedral_table.html - tabulated dihedral
+"table/cut"_dihedral_table_cut.html - tabulated dihedral with analytic cutoff :ul
 
 :line
 

doc/src/dump_h5md.txt

@@ -50,7 +50,7 @@ dump h5md1 all h5md 100 dump_h5md.h5 velocity author "John Doe" :pre
 [Description:]
 
 Dump a snapshot of atom coordinates every N timesteps in the
-"HDF5"_HDF5_ws based "H5MD"_h5md file format "(de Buyl)"_#h5md_cpc.
+"HDF5"_HDF5-ws based "H5MD"_h5md file format "(de Buyl)"_#h5md_cpc.
 HDF5 files are binary, portable and self-describing.  This dump style
 will write only one file, on the root node.
 
@@ -102,11 +102,11 @@ enabled if LAMMPS was built with that package. See the "Build
 package"_Build_package.html doc page for more info. It also requires
 (i) building the ch5md library provided with LAMMPS (See the "Build
 package"_Build_package.html doc page for more info.) and (ii) having
-the "HDF5"_HDF5_ws library installed (C bindings are sufficient) on
+the "HDF5"_HDF5-ws library installed (C bindings are sufficient) on
 your system.  The library ch5md is compiled with the h5cc wrapper
 provided by the HDF5 library.
 
-:link(HDF5_ws,http://www.hdfgroup.org/HDF5/)
+:link(HDF5-ws,http://www.hdfgroup.org/HDF5/)
 
 :line
 

doc/src/dump_image.txt

@@ -384,12 +384,7 @@ change this via the "dump_modify"_dump_modify.html command.
 :line
 
 The {fix} keyword can be used with a "fix"_fix.html that produces
-objects to be drawn.  An example is the "fix
-surface/global"_fix_surface_global.html command which can draw lines
-or triangles for 2d/3d simulations.
-
-NOTE: Aug 2016 - The fix surface/global command is not yet added to
-LAMMPS.
+objects to be drawn.
 
 The {fflag1} and {fflag2} settings are numerical values which are
 passed to the fix to affect how the drawing of its objects is done.

doc/src/fix.txt

@@ -167,136 +167,217 @@ page are followed by one or more of (g,i,k,o,t) to indicate which
 accelerated styles exist.
 
 "adapt"_fix_adapt.html - change a simulation parameter over time
+"adapt/fep"_fix_adapt_fep.html - 
 "addforce"_fix_addforce.html - add a force to each atom
+"addtorque"_fix_addtorque.html - 
 "append/atoms"_fix_append_atoms.html - append atoms to a running simulation
+"atc"_fix_atc.html - 
 "atom/swap"_fix_atom_swap.html - Monte Carlo atom type swapping
-"aveforce"_fix_aveforce.html - add an averaged force to each atom
 "ave/atom"_fix_ave_atom.html - compute per-atom time-averaged quantities
 "ave/chunk"_fix_ave_chunk.html - compute per-chunk time-averaged quantities
 "ave/correlate"_fix_ave_correlate.html - compute/output time correlations
+"ave/correlate/long"_fix_ave_correlate_long.html - 
 "ave/histo"_fix_ave_histo.html - compute/output time-averaged histograms
+"ave/histo/weight"_fix_ave_histo.html - 
 "ave/time"_fix_ave_time.html - compute/output global time-averaged quantities
+"aveforce"_fix_aveforce.html - add an averaged force to each atom
 "balance"_fix_balance.html - perform dynamic load-balancing
+"bocs"_fix_bocs.html - 
 "bond/break"_fix_bond_break.html - break bonds on the fly
 "bond/create"_fix_bond_create.html - create bonds on the fly
+"bond/react"_fix_bond_react.html - 
 "bond/swap"_fix_bond_swap.html - Monte Carlo bond swapping
 "box/relax"_fix_box_relax.html - relax box size during energy minimization
+"client/md"_fix_client_md.html - 
+"cmap"_fix_cmap.html - 
+"colvars"_fix_colvars.html - 
+"controller"_fix_controller.html - 
 "deform"_fix_deform.html - change the simulation box size/shape
 "deposit"_fix_deposit.html - add new atoms above a surface
+"dpd/energy"_fix_dpd_energy.html - 
 "drag"_fix_drag.html - drag atoms towards a defined coordinate
+"drude"_fix_drude.html - 
+"drude/transform/direct"_fix_drude_transform.html - 
+"drude/transform/inverse"_fix_drude_transform.html - 
 "dt/reset"_fix_dt_reset.html - reset the timestep based on velocity, forces
+"edpd/source"_fix_dpd_source.html - 
 "efield"_fix_efield.html - impose electric field on system
 "ehex"_fix_ehex.html - ehanced heat exchange algorithm
 "enforce2d"_fix_enforce2d.html - zero out z-dimension velocity and force
+"eos/cv"_fix_eos_cv.html - 
+"eos/table"_fix_eos_table.html - 
+"eos/table/rx"_fix_eos_table_rx.html - 
 "evaporate"_fix_evaporate.html - remove atoms from simulation periodically
 "external"_fix_external.html - callback to an external driver program
+"ffl"_fix_ffl.html - 
+"filter/corotate"_fix_filter_corotate.html - 
+"flow/gauss"_fix_flow_gauss.html - 
 "freeze"_fix_freeze.html - freeze atoms in a granular simulation
 "gcmc"_fix_gcmc.html - grand canonical insertions/deletions
 "gld"_fix_gcmc.html - generalized Langevin dynamics integrator
+"gld"_fix_gld.html - 
+"gle"_fix_gle.html - 
 "gravity"_fix_gravity.html - add gravity to atoms in a granular simulation
+"grem"_fix_grem.html - 
 "halt"_fix_halt.html - terminate a dynamics run or minimization
 "heat"_fix_heat.html - add/subtract momentum-conserving heat
+"hyper/global"_fix_hyper_global.html - global hyperdynamics
+"hyper/local"_fix_hyper_local.html - local hyperdynamics
+"imd"_fix_imd.html - 
 "indent"_fix_indent.html - impose force due to an indenter
-"latte"_fix_latte.html - wrapper on LATTE density-functional tight-binding code
+"ipi"_fix_ipi.html - 
 "langevin"_fix_langevin.html - Langevin temperature control
+"langevin/drude"_fix_langevin_drude.html - 
+"langevin/eff"_fix_langevin_eff.html - 
+"langevin/spin"_fix_langevin_spin.html - 
+"latte"_fix_latte.html - wrapper on LATTE density-functional tight-binding code
+"lb/fluid"_fix_lb_fluid.html - 
+"lb/momentum"_fix_lb_momentum.html - 
+"lb/pc"_fix_lb_pc.html - 
+"lb/rigid/pc/sphere"_fix_lb_rigid_pc_sphere.html - 
+"lb/viscous"_fix_lb_viscous.html - 
 "lineforce"_fix_lineforce.html - constrain atoms to move in a line
+"manifoldforce"_fix_manifoldforce.html - 
+"meso"_fix_meso.html - 
+"meso"_fix_meso_move.html - move mesoscopic SPH/SDPD particles in a prescribed fashion
+"meso/move"_fix_meso_move.html - 
+"meso/stationary"_fix_meso_stationary.html - 
 "momentum"_fix_momentum.html - zero the linear and/or angular momentum of a group of atoms
 "move"_fix_move.html - move atoms in a prescribed fashion
+"mscg"_fix_mscg.html - 
 "msst"_fix_msst.html - multi-scale shock technique (MSST) integration
+"mvv/dpd"_fix_mvv_dpd.html - 
+"mvv/edpd"_fix_mvv_dpd.html - 
+"mvv/tdpd"_fix_mvv_dpd.html - 
 "neb"_fix_neb.html - nudged elastic band (NEB) spring forces
 "nph"_fix_nh.html - constant NPH time integration via Nose/Hoover
-"nphug"_fix_nphug.html - constant-stress Hugoniostat integration
 "nph/asphere"_fix_nph_asphere.html - NPH for aspherical particles
+"nph/body"_fix_nph_body.html - 
 "nph/body"_fix_nve_body.html - NPH for body particles
+"nph/eff"_fix_nh_eff.html - 
 "nph/sphere"_fix_nph_sphere.html - NPH for spherical particles
+"nphug"_fix_nphug.html - constant-stress Hugoniostat integration
 "npt"_fix_nh.html - constant NPT time integration via Nose/Hoover
 "npt/asphere"_fix_npt_asphere.html - NPT for aspherical particles
+"npt/body"_fix_npt_body.html - 
 "npt/body"_fix_nve_body.html - NPT for body particles
+"npt/eff"_fix_nh_eff.html - 
 "npt/sphere"_fix_npt_sphere.html - NPT for spherical particles
+"npt/uef"_fix_nh_uef.html - 
 "nve"_fix_nve.html - constant NVE time integration
 "nve/asphere"_fix_nve_asphere.html - NVE for aspherical particles
 "nve/asphere/noforce"_fix_nve_asphere_noforce.html - NVE for aspherical particles without forces"
+"nve/awpmd"_fix_nve_awpmd.html - 
 "nve/body"_fix_nve_body.html - NVE for body particles
+"nve/dot"_fix_nve_dot.html - 
+"nve/dotc/langevin"_fix_nve_dotc_langevin.html - 
+"nve/eff"_fix_nve_eff.html - 
 "nve/limit"_fix_nve_limit.html - NVE with limited step length
 "nve/line"_fix_nve_line.html - NVE for line segments
+"nve/manifold/rattle"_fix_nve_manifold_rattle.html - 
 "nve/noforce"_fix_nve_noforce.html - NVE without forces (v only)
 "nve/sphere"_fix_nve_sphere.html - NVE for spherical particles
+"nve/spin"_fix_nve_spin.html - 
 "nve/tri"_fix_nve_tri.html - NVE for triangles
+"nvk"_fix_nvk.html - 
 "nvt"_fix_nh.html - constant NVT time integration via Nose/Hoover
 "nvt/asphere"_fix_nvt_asphere.html - NVT for aspherical particles
 "nvt/body"_fix_nve_body.html - NVT for body particles
+"nvt/body"_fix_nvt_body.html - 
+"nvt/eff"_fix_nh_eff.html - 
+"nvt/manifold/rattle"_fix_nvt_manifold_rattle.html - 
 "nvt/sllod"_fix_nvt_sllod.html - NVT for NEMD with SLLOD equations
+"nvt/sllod/eff"_fix_nvt_sllod_eff.html - 
 "nvt/sphere"_fix_nvt_sphere.html - NVT for spherical particles
+"nvt/uef"_fix_nh_uef.html - 
 "oneway"_fix_oneway.html - constrain particles on move in one direction
 "orient/bcc"_fix_orient.html - add grain boundary migration force for BCC
 "orient/fcc"_fix_orient.html - add grain boundary migration force for FCC
+"phonon"_fix_phonon.html - 
+"pimd"_fix_pimd.html - 
 "planeforce"_fix_planeforce.html - constrain atoms to move in a plane
-"poems"_fix_poems.html - constrain clusters of atoms to move \
-  as coupled rigid bodies
+"plumed"_fix_plumed.html - wrapper on PLUMED free energy library
+"poems"_fix_poems.html - constrain clusters of atoms to move as coupled rigid bodies
 "pour"_fix_pour.html - pour new atoms/molecules into a granular simulation domain
-"press/berendsen"_fix_press_berendsen.html - pressure control by \
-     Berendsen barostat
+"precession/spin"_fix_precession_spin.html - 
+"press/berendsen"_fix_press_berendsen.html - pressure control by Berendsen barostat
 "print"_fix_print.html - print text and variables during a simulation
 "property/atom"_fix_property_atom.html - add customized per-atom values
-"qeq/comb"_fix_qeq_comb.html - charge equilibration for COMB potential \
-"qeq/dynamic"_fix_qeq.html - charge equilibration via dynamic method \
-"qeq/fire"_fix_qeq.html - charge equilibration via FIRE minimizer \
-"qeq/point"_fix_qeq.html - charge equilibration via point method \
-"qeq/shielded"_fix_qeq.html - charge equilibration via shielded method \
-"qeq/slater"_fix_qeq.html - charge equilibration via Slater method \
+"python/invoke"_fix_python_invoke.html - 
+"python/move"_fix_python_move.html - 
+"qbmsst"_fix_qbmsst.html - 
+"qeq/comb"_fix_qeq_comb.html - charge equilibration for COMB potential
+"qeq/dynamic"_fix_qeq.html - charge equilibration via dynamic method
+"qeq/fire"_fix_qeq.html - charge equilibration via FIRE minimizer
+"qeq/point"_fix_qeq.html - charge equilibration via point method
+"qeq/reax"_fix_qeq_reax.html - 
+"qeq/shielded"_fix_qeq.html - charge equilibration via shielded method
+"qeq/slater"_fix_qeq.html - charge equilibration via Slater method
+"qmmm"_fix_qmmm.html - 
+"qtb"_fix_qtb.html - 
 "rattle"_fix_shake.html - RATTLE constraints on bonds and/or angles
-"reax/bonds"_fix_reax_bonds.html - write out ReaxFF bond information \
-"recenter"_fix_recenter.html - constrain the center-of-mass position \
-  of a group of atoms
+"reax/bonds"_fix_reax_bonds.html - write out ReaxFF bond information
+"reax/c/bonds"_fix_reax_bonds.html - 
+"reax/c/species"_fix_reaxc_species.html - 
+"recenter"_fix_recenter.html - constrain the center-of-mass position of a group of atoms
 "restrain"_fix_restrain.html - constrain a bond, angle, dihedral
-"rigid"_fix_rigid.html - constrain one or more clusters of atoms to \
-     move as a rigid body with NVE integration
-"rigid/nph"_fix_rigid.html - constrain one or more clusters of atoms to \
-     move as a rigid body with NPH integration
-"rigid/npt"_fix_rigid.html - constrain one or more clusters of atoms to \
-     move as a rigid body with NPT integration
-"rigid/nve"_fix_rigid.html - constrain one or more clusters of atoms to \
-     move as a rigid body with alternate NVE integration
-"rigid/nvt"_fix_rigid.html - constrain one or more clusters of atoms to \
-     move as a rigid body with NVT integration
-"rigid/small"_fix_rigid.html - constrain many small clusters of atoms to \
-     move as a rigid body with NVE integration
-"rigid/small/nph"_fix_rigid.html - constrain many small clusters of atoms to \
-     move as a rigid body with NPH integration
-"rigid/small/npt"_fix_rigid.html - constrain many small clusters of atoms to \
-     move as a rigid body with NPT integration
-"rigid/small/nve"_fix_rigid.html - constrain many small clusters of atoms to \
-     move as a rigid body with alternate NVE integration
-"rigid/small/nvt"_fix_rigid.html - constrain many small clusters of atoms to \
-     move as a rigid body with NVT integration
+"rhok"_fix_rhok.html - 
+"rigid"_fix_rigid.html - constrain one or more clusters of atoms to move as a rigid body with NVE integration
+"rigid/nph"_fix_rigid.html - constrain one or more clusters of atoms to move as a rigid body with NPH integration
+"rigid/nph/small"_fix_rigid.html - 
+"rigid/npt"_fix_rigid.html - constrain one or more clusters of atoms to move as a rigid body with NPT integration
+"rigid/npt/small"_fix_rigid.html - 
+"rigid/nve"_fix_rigid.html - constrain one or more clusters of atoms to move as a rigid body with alternate NVE integration
+"rigid/nve/small"_fix_rigid.html - 
+"rigid/nvt"_fix_rigid.html - constrain one or more clusters of atoms to move as a rigid body with NVT integration
+"rigid/nvt/small"_fix_rigid.html - 
+"rigid/small"_fix_rigid.html - constrain many small clusters of atoms to move as a rigid body with NVE integration
+"rigid/small/nph"_fix_rigid.html - constrain many small clusters of atoms to move as a rigid body with NPH integration
+"rigid/small/npt"_fix_rigid.html - constrain many small clusters of atoms to move as a rigid body with NPT integration
+"rigid/small/nve"_fix_rigid.html - constrain many small clusters of atoms to move as a rigid body with alternate NVE integration
+"rigid/small/nvt"_fix_rigid.html - constrain many small clusters of atoms to move as a rigid body with NVT integration
+"rigid/meso"_fix_rigid_meso.html - constrain clusters of mesoscopic SPH/SDPD particles to move as a rigid body
+"rx"_fix_rx.html - 
+"saed/vtk"_fix_saed_vtk.html - 
 "setforce"_fix_setforce.html - set the force on each atom
 "shake"_fix_shake.html - SHAKE constraints on bonds and/or angles
+"shardlow"_fix_shardlow.html - 
+"smd"_fix_smd.html - 
+"smd/adjust_dt"_fix_smd_adjust_dt.html - 
+"smd/integrate_tlsph"_fix_smd_integrate_tlsph.html - 
+"smd/integrate_ulsph"_fix_smd_integrate_ulsph.html - 
+"smd/move_tri_surf"_fix_smd_move_triangulated_surface.html - 
+"smd/setvel"_fix_smd_setvel.html - 
+"smd/wall_surface"_fix_smd_wall_surface.html - 
 "spring"_fix_spring.html - apply harmonic spring force to group of atoms
 "spring/chunk"_fix_spring_chunk.html - apply harmonic spring force to each chunk of atoms
-"spring/rg"_fix_spring_rg.html - spring on radius of gyration of \
-     group of atoms
+"spring/rg"_fix_spring_rg.html - spring on radius of gyration of group of atoms
 "spring/self"_fix_spring_self.html - spring from each atom to its origin
 "srd"_fix_srd.html - stochastic rotation dynamics (SRD)
 "store/force"_fix_store_force.html - store force on each atom
 "store/state"_fix_store_state.html - store attributes for each atom
-"temp/berendsen"_fix_temp_berendsen.html - temperature control by \
-     Berendsen thermostat
+"tdpd/source"_fix_dpd_source.html - 
+"temp/berendsen"_fix_temp_berendsen.html - temperature control by Berendsen thermostat
 "temp/csld"_fix_temp_csvr.html - canonical sampling thermostat with Langevin dynamics
 "temp/csvr"_fix_temp_csvr.html - canonical sampling thermostat with Hamiltonian dynamics
-"temp/rescale"_fix_temp_rescale.html - temperature control by \
-     velocity rescaling
+"temp/rescale"_fix_temp_rescale.html - temperature control by velocity rescaling
+"temp/rescale/eff"_fix_temp_rescale_eff.html - 
 "tfmc"_fix_tfmc.html - perform force-bias Monte Carlo with time-stamped method
-"thermal/conductivity"_fix_thermal_conductivity.html - Muller-Plathe kinetic energy exchange for \
-     thermal conductivity calculation
+"thermal/conductivity"_fix_thermal_conductivity.html - Muller-Plathe kinetic energy exchange for thermal conductivity calculation
+"ti/spring"_fix_ti_spring.html - 
 "tmd"_fix_tmd.html - guide a group of atoms to a new configuration
 "ttm"_fix_ttm.html - two-temperature model for electronic/atomic coupling
+"ttm/mod"_fix_ttm.html - 
 "tune/kspace"_fix_tune_kspace.html - auto-tune KSpace parameters
 "vector"_fix_vector.html - accumulate a global vector every N timesteps
-"viscosity"_fix_viscosity.html - Muller-Plathe momentum exchange for \
-     viscosity calculation
+"viscosity"_fix_viscosity.html - Muller-Plathe momentum exchange for viscosity calculation
 "viscous"_fix_viscous.html - viscous damping for granular simulations
+"wall/body/polygon"_fix_wall_body_polygon.html - 
+"wall/body/polyhedron"_fix_wall_body_polyhedron.html - 
 "wall/colloid"_fix_wall.html - Lennard-Jones wall interacting with finite-size particles
+"wall/ees"_fix_wall_ees.html - 
 "wall/gran"_fix_wall_gran.html - frictional wall(s) for granular simulations
+"wall/gran/region"_fix_wall_gran_region.html - 
 "wall/harmonic"_fix_wall.html - harmonic spring wall
 "wall/lj1043"_fix_wall.html - Lennard-Jones 10-4-3 wall
 "wall/lj126"_fix_wall.html - Lennard-Jones 12-6 wall
@@ -304,6 +385,7 @@ accelerated styles exist.
 "wall/piston"_fix_wall_piston.html - moving reflective piston wall
 "wall/reflect"_fix_wall_reflect.html - reflecting wall(s)
 "wall/region"_fix_wall_region.html - use region surface as wall
+"wall/region/ees"_fix_wall_ees.html - 
 "wall/srd"_fix_wall_srd.html - slip/no-slip wall for SRD particles :ul
 
 [Restrictions:]

doc/src/fix_balance.txt

@@ -376,3 +376,4 @@ appear in {dimstr} for the {shift} style.
 "group"_group.html, "processors"_processors.html, "balance"_balance.html
 
 [Default:] none
+:link(pizza,http://pizza.sandia.gov)

doc/src/fix_bond_break.txt

@@ -137,8 +137,8 @@ doc page for more info.
 [Related commands:]
 
 "fix bond/create"_fix_bond_create.html, "fix
-bond/swap"_fix_bond_swap.html, "dump local"_dump.html,
-"special_bonds"_special_bonds.html
+bond/react"_fix_bond_react.html, "fix bond/swap"_fix_bond_swap.html,
+"dump local"_dump.html, "special_bonds"_special_bonds.html
 
 [Default:]
 

doc/src/fix_bond_create.txt

@@ -232,8 +232,8 @@ doc page for more info.
 [Related commands:]
 
 "fix bond/break"_fix_bond_break.html, "fix
-bond/swap"_fix_bond_swap.html, "dump local"_dump.html,
-"special_bonds"_special_bonds.html
+bond/react"_fix_bond_react.html, "fix bond/swap"_fix_bond_swap.html,
+"dump local"_dump.html, "special_bonds"_special_bonds.html
 
 [Default:]
 

doc/src/fix_bond_react.txt

@@ -24,11 +24,11 @@ common_keyword = {stabilization} :l
   {stabilization} values = {no} or {yes} {group-ID} {xmax}
     {no} = no reaction site stabilization
     {yes} = perform reaction site stabilization
-      {group-ID} = user-assigned ID for all non-reacting atoms (group created internally)
+      {group-ID} = user-assigned prefix for the dynamic group of non-reacting atoms
       {xmax} = xmax value that is used by an internally created "nve/limit"_fix_nve_limit.html integrator :pre
 react = mandatory argument indicating new reaction specification :l
   react-ID = user-assigned name for the reaction :l
-  react-group-ID = only atoms in this group are available for the reaction :l
+  react-group-ID = only atoms in this group are considered for the reaction :l
   Nevery = attempt reaction every this many steps :l
   Rmin = bonding pair atoms must be separated by more than Rmin to initiate reaction (distance units) :l
   Rmax = bonding pair atoms must be separated by less than Rmax to initiate reaction (distance units) :l
@@ -41,14 +41,18 @@ react = mandatory argument indicating new reaction specification :l
       fraction = initiate reaction with this probability if otherwise eligible
       seed = random number seed (positive integer)
     {stabilize_steps} value = timesteps
-      timesteps = number of timesteps to apply internally created nve/limit.html :pre
+      timesteps = number of timesteps to apply internally created nve/limit fix :pre
+    {update_edges} value = {none} or {charges} :l
+      none = do not update topology near the edges of reaction templates
+      charges = update atomic charges of all atoms in reaction templates
+      custom = force the update of user-specified atomic charges :pre
 :ule
 
 [Examples:]
 
 molecule mol1 pre_reacted_topology.txt
 molecule mol2 post_reacted_topology.txt
-fix 5 all bond/react stabilization no react myrxn1 all 1 0 3.25 mol1 mol2 map_file.txt :pre
+fix 5 all bond/react react myrxn1 all 1 0 3.25 mol1 mol2 map_file.txt :pre
 
 molecule mol1 pre_reacted_rxn1.txt
 molecule mol2 post_reacted_rxn1.txt
@@ -57,7 +61,7 @@ molecule mol4 post_reacted_rxn2.txt
 fix 5 all bond/react stabilization yes nvt_grp .03 &
   react myrxn1 all 1 0 3.25 mol1 mol2 map_file_rxn1.txt prob 0.50 12345 &
   react myrxn2 all 1 0 2.75 mol3 mol4 map_file_rxn2.txt prob 0.25 12345
-fix 6 nvt_grp nvt temp 300 300 100 # set thermostat after bond/react :pre
+fix 6 nvt_grp_REACT nvt temp 300 300 100 # set thermostat after bond/react :pre
 
 [Description:]
 
@@ -99,19 +103,29 @@ involved in any new reactions. The {xmax} value keyword should
 typically be set to the maximum distance that non-reacting atoms move
 during the simulation.
 
-The group-ID set using the {stabilization} keyword should be a
-previously unused group-ID. It cannot be specified as 'all'. The fix
-bond/react command creates a "dynamic group"_group.html of this name
-that includes all non-reacting atoms. This dynamic group-ID should
-then be used by a subsequent system-wide time integrator such as nvt,
-npt, or nve, as shown in the second example above. It is currently
-necessary to place the time integration command after the fix
-bond/react command due to the internal dynamic grouping performed by
-fix bond/react.
+The group-ID set using the {stabilization} keyword can be an existing
+static group or a previously-unused group-ID. It cannot be specified
+as 'all'. If the group-ID is previously unused, the fix bond/react
+command creates a "dynamic group"_group.html that is initialized to
+include all atoms. If the group-ID is that of an existing static
+group, the group is used as the parent group of new,
+internally-created dynamic group. In both cases, this new dynamic
+group is named by appending '_REACT' to the group-ID, e.g.
+nvt_grp_REACT. By specifying an existing group, you may thermostat
+constant-topology parts of your system separately. The dynamic group
+contains only non-reacting atoms at a given timestep, and therefore
+should be used by a subsequent system-wide time integrator such as
+nvt, npt, or nve, as shown in the second example above. The time
+integration command should be placed after the fix bond/react command
+due to the internal dynamic grouping performed by fix bond/react.
 
-NOTE: The internally created group currently applies to all atoms in
-the system, i.e. you should generally not have a separate thermostat
-which acts on the 'all' group.
+NOTE: If the group-ID is an existing static group, react-group-IDs
+should also be specified as this static group, or a subset.
+
+NOTE: If the group-ID is previously unused, the internally created
+group applies to all atoms in the system, i.e. you should generally
+not have a separate thermostat which acts on the 'all' group, or any
+other group.
 
 The following comments pertain to each {react} argument:
 
@@ -155,7 +169,17 @@ Some atoms in the pre-reacted template that are not reacting may have
 missing topology with respect to the simulation. For example, the
 pre-reacted template may contain an atom that would connect to the
 rest of a long polymer chain. These are referred to as edge atoms, and
-are also specified in the map file.
+are also specified in the map file. When the pre-reaction template
+contains edge atoms, not all atoms, bonds, charges, etc. specified in
+the reaction templates will be updated. Specifically, topology that
+involves only atoms that are 'too near' to template edges will not be
+updated. The definition of 'too near the edge' depends on which
+interactions are defined in the simulation. If the simulation has
+defined dihedrals, atoms within two bonds of edge atoms are considered
+'too near the edge.' If the simulation defines angles, but not
+dihedrals, atoms within one bond of edge atoms are considered 'too
+near the edge.' If just bonds are defined, only edge atoms are
+considered 'too near the edge.'
 
 Note that some care must be taken when a building a molecule template
 for a given simulation. All atom types in the pre-reacted template
@@ -178,23 +202,30 @@ A discussion of correctly handling this is also provided on the
 The map file is a text document with the following format:
 
 A map file has a header and a body. The header of map file the
-contains one mandatory keyword and one optional keyword. The mandatory
-keyword is 'equivalences' and the optional keyword is 'edgeIDs':
+contains one mandatory keyword and two optional keywords. The mandatory
+keyword is 'equivalences' and the optional keywords are 'edgeIDs' and
+'customIDs':
 
 N {equivalences} = # of atoms N in the reaction molecule templates
-N {edgeIDs} = # of edge atoms N in the pre-reacted molecule template :pre
+N {edgeIDs} = # of edge atoms N in the pre-reacted molecule template
+N {customIDs} = # of atoms N that are specified for a custom update :pre
 
-The body of the map file contains two mandatory sections and one
-optional section. The first mandatory section begins with the keyword
+The body of the map file contains two mandatory sections and two
+optional sections. The first mandatory section begins with the keyword
 'BondingIDs' and lists the atom IDs of the bonding atom pair in the
 pre-reacted molecule template. The second mandatory section begins
 with the keyword 'Equivalences' and lists a one-to-one correspondence
 between atom IDs of the pre- and post-reacted templates. The first
 column is an atom ID of the pre-reacted molecule template, and the
 second column is the corresponding atom ID of the post-reacted
-molecule template. The optional section begins with the keyword
+molecule template. The first optional section begins with the keyword
 'EdgeIDs' and lists the atom IDs of edge atoms in the pre-reacted
-molecule template.
+molecule template. The second optional section begins with the keyword
+'Custom Edges' and allows for forcing the update of a specific atom's
+atomic charge. The first column is the ID of an atom near the edge of
+the pre-reacted molecule template, and the value of the second column
+is either 'none' or 'charges.' Further details are provided in the
+discussion of the 'update_edges' keyword.
 
 A sample map file is given below:
 
@@ -255,6 +286,18 @@ The {stabilize_steps} keyword allows for the specification of how many
 timesteps a reaction site is stabilized before being returned to the
 overall system thermostat.
 
+The {update_edges} keyword can increase the number of atoms whose
+atomic charges are updated, when the pre-reaction template contains
+edge atoms. When the value is set to 'charges,' all atoms' atomic
+charges are updated to those specified by the post-reaction template,
+including atoms near the edge of reaction templates. When the value is
+set to 'custom,' an additional section must be included in the map
+file that specifies whether to update charges, on a per-atom basis.
+The format of this section is detailed above. Listing a pre-reaction
+atom ID with a value of 'charges' will force the update of the atom's
+charge, even if it is near a template edge. Atoms not near a template
+edge are unaffected by this setting.
+
 In order to produce the most physical behavior, this 'reaction site
 equilibration time' should be tuned to be as small as possible while
 retaining stability for a given system or reaction step. After a
@@ -323,7 +366,7 @@ bond/break"_fix_bond_break.html, "fix bond/swap"_fix_bond_swap.html,
 
 [Default:]
 
-The option defaults are stabilization = no, prob = 1.0, stabilize_steps = 60
+The option defaults are stabilization = no, prob = 1.0, stabilize_steps = 60, update_edges = none
 
 :line
 

doc/src/fix_box_relax.txt

@@ -221,8 +221,8 @@ This equation only applies when the box dimensions are equal to those
 of the reference dimensions. If this is not the case, then the
 converged stress tensor will not equal that specified by the user.  We
 can resolve this problem by periodically resetting the reference
-dimensions. The keyword {nreset_ref} controls how often this is done.
-If this keyword is not used, or is given a value of zero, then the
+dimensions. The keyword {nreset} controls how often this is done.  If
+this keyword is not used, or is given a value of zero, then the
 reference dimensions are set to those of the initial simulation domain
 and are never changed. A value of {nstep} means that every {nstep}
 minimization steps, the reference dimensions are set to those of the

doc/src/fix_client_md.txt

@@ -50,7 +50,7 @@ md"_server_md.html doc page.
 
 Note that when using LAMMPS as an MD client, your LAMMPS input script
 should not normally contain force field commands, like a
-"pair_style"_doc/pair_style.html, "bond_style"_doc/bond_style.html, or
+"pair_style"_pair_style.html, "bond_style"_bond_style.html, or
 "kspace_style"_kspace_style.html commmand.  However it is possible for
 a server code to only compute a portion of the full force-field, while
 LAMMPS computes the remaining part.  Your LAMMPS script can also

doc/src/fix_colvars.txt

@@ -116,7 +116,8 @@ not a limitation of functionality.
 
 [Related commands:]
 
-"fix smd"_fix_smd.html
+"fix smd"_fix_smd.html, "fix spring"_fix_spring.html,
+"fix plumed"_fix_plumed.html
 
 [Default:]
 
@@ -126,4 +127,4 @@ and tstat = NULL.
 :line
 
 :link(Fiorin)
-[(Fiorin)] Fiorin , Klein, Henin, Mol. Phys., DOI:10.1080/00268976.2013.813594
+[(Fiorin)] Fiorin, Klein, Henin, Mol. Phys., DOI:10.1080/00268976.2013.813594

doc/src/fix_ffl.txt

@@ -0,0 +1,124 @@
+<script type="text/javascript"
+  src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML">
+</script>
+<script type="text/x-mathjax-config">
+  MathJax.Hub.Config({ TeX: { equationNumbers: {autoNumber: "AMS"} } });
+</script>
+
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+fix ffl command :h3
+
+[Syntax:]
+
+fix ID id-group ffl tau Tstart Tstop seed \[flip-type\]  :pre
+
+ID, group-ID are documented in "fix"_fix.html command :ulb,l
+ffl = style name of this fix command :l
+tau = thermostat parameter (positive real) :l
+Tstart, Tstop = temperature ramp during the run :l
+seed = random number seed to use for generating noise (positive integer) :l
+one more value may be appended :l
+    flip-type  = determines the flipping type, can be chosen between rescale - no_flip - hard - soft, if no flip type is given, rescale will be chosen by default :pre
+:ule
+
+[Examples:]
+
+fix 3 boundary ffl 10 300 300 31415
+fix 1 all ffl 100 500 500 9265 soft :pre
+
+[Description:]
+
+Apply a Fast-Forward Langevin Equation (FFL) thermostat as described
+in "(Hijazi)"_#Hijazi. Contrary to
+"fix langevin"_fix_langevin.html, this fix performs both
+thermostatting and evolution of the Hamiltonian equations of motion, so it
+should not be used together with "fix nve"_fix_nve.html -- at least not
+on the same atom groups.
+
+The time-evolution of a single particle undergoing Langevin dynamics is described
+by the equations
+
+\begin\{equation\} \frac \{dq\}\{dt\} = \frac\{p\}\{m\}, \end\{equation\}
+
+\begin\{equation\} \frac \{dp\}\{dt\} = -\gamma p + W + F, \end\{equation\}
+
+where \(F\) is the physical force, \(\gamma\) is the friction coefficient, and \(W\) is a
+Gaussian random force.
+
+The friction coefficient is the inverse of the thermostat parameter : \(\gamma = 1/\tau\), with \(\tau\) the thermostat parameter {tau}.
+The thermostat parameter is given in the time units, \(\gamma\) is in inverse time units.
+
+Equilibrium sampling a temperature T is obtained by specifying the
+target value as the {Tstart} and {Tstop} arguments, so that the internal
+constants depending on the temperature are computed automatically.
+
+The random number {seed} must be a positive integer.  A Marsaglia random
+number generator is used.  Each processor uses the input seed to
+generate its own unique seed and its own stream of random numbers.
+Thus the dynamics of the system will not be identical on two runs on
+different numbers of processors.
+
+The flipping type {flip-type} can be chosen between 4 types described in
+"(Hijazi)"_#Hijazi. The flipping operation occurs during the thermostatting
+step and it flips the momenta of the atoms. If no_flip is chosen, no flip
+will be executed and the integration will be the same as a standard
+Langevin thermostat "(Bussi)"_#Bussi3. The other flipping types are : rescale - hard - soft.
+
+[Restart, fix_modify, output, run start/stop, minimize info:]
+
+The instantaneous values of the extended variables are written to
+"binary restart files"_restart.html.  Because the state of the random
+number generator is not saved in restart files, this means you cannot
+do "exact" restarts with this fix, where the simulation continues on
+the same as if no restart had taken place. However, in a statistical
+sense, a restarted simulation should produce the same behavior.
+Note however that you should use a different seed each time you
+restart, otherwise the same sequence of random numbers will be used
+each time, which might lead to stochastic synchronization and
+subtle artefacts in the sampling.
+
+This fix can ramp its target temperature over multiple runs, using the
+{start} and {stop} keywords of the "run"_run.html command.  See the
+"run"_run.html command for details of how to do this.
+
+The "fix_modify"_fix_modify.html {energy} option is supported by this
+fix to add the energy change induced by Langevin thermostatting to the
+system's potential energy as part of "thermodynamic
+output"_thermo_style.html.
+
+This fix computes a global scalar which can be accessed by various
+"output commands"_Howto_output.html.  The scalar is the cumulative
+energy change due to this fix.  The scalar value calculated by this
+fix is "extensive".
+
+[Restrictions:]
+
+In order to perform constant-pressure simulations please use
+"fix press/berendsen"_fix_press_berendsen.html, rather than
+"fix npt"_fix_nh.html, to avoid duplicate integration of the
+equations of motion.
+
+This fix is part of the USER-MISC package.  It is only enabled if
+LAMMPS was built with that package.  See the "Build
+package"_Build_package.html doc page for more info.
+
+[Related commands:]
+
+"fix nvt"_fix_nh.html, "fix temp/rescale"_fix_temp_rescale.html, "fix
+viscous"_fix_viscous.html, "fix nvt"_fix_nh.html, "pair_style
+dpd/tstat"_pair_dpd.html, "fix gld"_fix_gld.html, "fix gle"_fix_gle.html
+
+:line
+
+:link(Hijazi)
+[(Hijazi)] M. Hijazi, D. M. Wilkins, M. Ceriotti, J. Chem. Phys. 148, 184109 (2018)
+:link(Bussi3)
+[(Bussi)] G. Bussi, M. Parrinello, Phs. Rev. E 75, 056707 (2007)
+

doc/src/fix_freeze.txt

@@ -7,6 +7,7 @@
 :line
 
 fix freeze command :h3
+fix freeze/kk command :h3
 
 [Syntax:]
 

doc/src/fix_gravity.txt

@@ -8,6 +8,7 @@
 
 fix gravity command :h3
 fix gravity/omp command :h3
+fix gravity/kk command :h3
 
 [Syntax:]
 

doc/src/fix_halt.txt

@@ -135,8 +135,7 @@ files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.  No global or per-atom quantities are stored
 by this fix for access by various "output commands"_Howto_output.html.
 No parameter of this fix can be used with the {start/stop} keywords of
-the "run"_run.html command.  This fix is not invoked during "energy
-minimization"_minimize.html.
+the "run"_run.html command.
 
 [Restrictions:] none
 

doc/src/fix_hyper_global.txt

@@ -0,0 +1,260 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+fix hyper/global command :h3
+
+[Syntax:]
+
+fix ID group-ID hyper/global cutbond qfactor Vmax Tequil :pre
+
+ID, group-ID are documented in "fix"_fix.html command
+hyper/global = style name of this fix command
+cutbond = max distance at which a pair of atoms is considered bonded (distance units)
+qfactor = max strain at which bias potential goes to 0.0 (unitless)
+Vmax = height of bias potential (energy units)
+Tequil = equilibration temperature (temperature units) :ul
+
+[Examples:]
+
+fix 1 all hyper/global 1.0 0.3 0.8 300.0 :pre
+
+[Description:]
+
+This fix is meant to be used with the "hyper"_hyper.html command to
+perform a bond-boost global hyperdynamics (GHD) simulation.  The role
+of this fix is to a select a single pair of atoms in the system at
+each timestep to add a global bias potential to, which will alter the
+dynamics of the system in a manner that effectively accelerates time.
+This is in contrast to the "fix hyper/local"_fix_hyper_local.html
+command, which can be user to perform a local hyperdynamics (LHD)
+simulation, by adding a local bias potential to multiple pairs of
+atoms at each timestep.  GHD can time accelerate a small simulation
+with up to a few 100 atoms.  For larger systems, LHD is needed to
+achieve good time acceleration.
+
+For a system that undergoes rare transition events, where one or more
+atoms move over an energy barrier to a new potential energy basin, the
+effect of the bias potential is to induce more rapid transitions.
+This can lead to a dramatic speed-up in the rate at which events
+occurs, without altering their relative frequencies, thus leading to
+an overall increase in the elapsed real time of the simulation as
+compared to running for the same number of timesteps with normal MD.
+See the "hyper"_hyper.html doc page for a more general discussion of
+hyperdynamics and citations that explain both GHD and LHD.
+
+The equations and logic used by this fix and described here to perform
+GHD follow the description given in "(Voter2013)"_#Voter2013ghd.  The
+bond-boost form of a bias potential for HD is due to Miron and
+Fichthorn as described in "(Miron)"_#Mironghd.  In LAMMPS we use a
+simplified version of bond-boost GHD where a single bond in the system
+is biased at any one timestep.
+
+Bonds are defined between each pair of I,J atoms whose R0ij distance
+is less than {cutbond}, when the system is in a quenched state
+(minimum) energy.  Note that these are not "bonds" in a covalent
+sense.  A bond is simply any pair of atoms that meet the distance
+criterion.  {Cutbond} is an argument to this fix; it is discussed
+below.  A bond is only formed if one or both of the I.J atoms are in
+the specified group.
+
+The current strain of bond IJ (when running dynamics) is defined as
+
+Eij = (Rij - R0ij) / R0ij :pre
+
+where Rij is the current distance between atoms I,J, and R0ij is the
+equilibrium distance in the quenched state.
+
+The bias energy Vij of any bond IJ is defined as
+
+Vij = Vmax * (1 - (Eij/q)^2) for abs(Eij) < qfactor
+    = 0 otherwise :pre
+
+where the prefactor {Vmax} and the cutoff {qfactor} are arguments to
+this fix; they are discussed below.  This functional form is an
+inverse parabola centered at 0.0 with height Vmax and which goes to
+0.0 at +/- qfactor.
+
+Let Emax = the maximum of abs(Eij) for all IJ bonds in the system on a
+given timestep.  On that step, Vij is added as a bias potential to
+only the single bond with strain Emax, call it Vij(max).  Note that
+Vij(max) will be 0.0 if Emax >= qfactor on that timestep.  Also note
+that Vij(max) is added to the normal interatomic potential that is
+computed between all atoms in the system at every step.
+
+The derivative of Vij(max) with respect to the position of each atom
+in the Emax bond gives a bias force Fij(max) acting on the bond as
+
+Fij(max) = - dVij(max)/dEij = 2 Vmax Eij / qfactor^2   for abs(Eij) < qfactor
+         = 0 otherwise :pre
+
+which can be decomposed into an equal and opposite force acting on
+only the two I,J atoms in the Emax bond.
+
+The time boost factor for the system is given each timestep I by
+
+Bi = exp(beta * Vij(max)) :pre
+
+where beta = 1/kTequil, and {Tequil} is the temperature of the system
+and an argument to this fix.  Note that Bi >= 1 at every step.
+
+NOTE: To run GHD, the input script must also use the "fix
+langevin"_fix_langevin.html command to thermostat the atoms at the
+same {Tequil} as specified by this fix, so that the system is running
+constant-temperature (NVT) dynamics.  LAMMPS does not check that this
+is done.
+
+The elapsed time t_hyper for a GHD simulation running for {N}
+timesteps is simply
+
+t_hyper = Sum (i = 1 to N) Bi * dt :pre
+
+where dt is the timestep size defined by the "timestep"_timestep.html
+command.  The effective time acceleration due to GHD is thus t_hyper /
+N*dt, where N*dt is elapsed time for a normal MD run of N timesteps.
+
+Note that in GHD, the boost factor varies from timestep to timestep.
+Likewise, which bond has Emax strain and thus which pair of atoms the
+bias potential is added to, will also vary from timestep to timestep.
+This is in contrast to local hyperdynamics (LHD) where the boost
+factor is an input parameter; see the "fix
+hyper/local"_fix_hyper_local.html doc page for details.
+
+:line
+
+Here is additional information on the input parameters for GHD.
+
+The {cutbond} argument is the cutoff distance for defining bonds
+between pairs of nearby atoms.  A pair of I,J atoms in their
+equilibrium, minimum-energy configuration, which are separated by a
+distance Rij < {cutbond}, are flagged as a bonded pair.  Setting
+{cubond} to be ~25% larger than the nearest-neighbor distance in a
+crystalline lattice is a typical choice for solids, so that bonds
+exist only between nearest neighbor pairs.
+
+The {qfactor} argument is the limiting strain at which the bias
+potential goes to 0.0.  It is dimensionless, so a value of 0.3 means a
+bond distance can be up to 30% larger or 30% smaller than the
+equilibrium (quenched) R0ij distance and the two atoms in the bond
+could still experience a non-zero bias force.
+
+If {qfactor} is set too large, then transitions from one energy basin
+to another are affected because the bias potential is non-zero at the
+transition state (e.g. saddle point).  If {qfactor} is set too small
+than little boost is achieved because the Eij strain of some bond in
+the system will (nearly) always exceed {qfactor}.  A value of 0.3 for
+{qfactor} is typically reasonable.
+
+The {Vmax} argument is the prefactor on the bias potential.  Ideally,
+tt should be set to a value slightly less than the smallest barrier
+height for an event to occur.  Otherwise the applied bias potential
+may be large enough (when added to the interatomic potential) to
+produce a local energy basin with a maxima in the center.  This can
+produce artificial energy minima in the same basin that trap an atom.
+Or if {Vmax} is even larger, it may induce an atom(s) to rapidly
+transition to another energy basin.  Both cases are "bad dynamics"
+which violate the assumptions of GHD that guarantee an accelerated
+time-accurate trajectory of the system.
+
+Note that if {Vmax} is set too small, the GHD simulation will run
+correctly.  There will just be fewer events because the hyper time
+(t_hyper equation above) will be shorter.
+
+NOTE: If you have no physical intuition as to the smallest barrier
+height in your system, a reasonable strategy to determine the largest
+{Vmax} you can use for an LHD model, is to run a sequence of
+simulations with smaller and smaller {Vmax} values, until the event
+rate does not change.
+
+The {Tequil} argument is the temperature at which the system is
+simulated; see the comment above about the "fix
+langevin"_fix_langevin.html thermostatting.  It is also part of the
+beta term in the exponential factor that determines how much boost is
+achieved as a function of the bias potential.
+
+In general, the lower the value of {Tequil} and the higher the value
+of {Vmax}, the more boost will be achievable by the GHD algorithm.
+
+:line
+
+[Restart, fix_modify, output, run start/stop, minimize info:]
+
+No information about this fix is written to "binary restart
+files"_restart.html.
+
+The "fix_modify"_fix_modify.html {energy} option is supported by this
+fix to add the energy of the bias potential to the the system's
+potential energy as part of "thermodynamic output"_thermo_style.html.
+
+This fix computes a global scalar and global vector of length 11, which
+can be accessed by various "output commands"_Howto_output.html.  The
+scalar is the magnitude of the bias potential (energy units) applied on
+the current timestep.  The vector stores the following quantities:
+
+1 = boost factor on this step (unitless)
+2 = max strain Eij of any bond on this step (unitless)
+3 = ID of first atom in the max-strain bond
+4 = ID of second atom in the max-strain bond
+5 = average # of bonds/atom on this step :ul
+
+6 = fraction of timesteps with bias = 0.0 during this run
+7 = max drift distance of any atom during this run (distance units)
+8 = max bond length during this run (distance units) :ul
+
+9 = cummulative hyper time since fix was defined (time units)
+10 = cummulative count of event timesteps since fix was defined
+11 = cummulative count of atoms in events since fix was defined :ul
+
+The first 5 quantities are for the current timestep.  Quantities 6-8
+are for the current hyper run.  Quantities 9-11 are cummulative across
+multiple runs (since the fix was defined in the input script).
+
+For value 7, drift is the distance an atom moves between timesteps
+when the bond list is reset, i.e. between events.  Atoms involved in
+an event will typically move the greatest distance since others are
+typically oscillating around their lattice site.
+
+For value 10, events are checked for by the "hyper"_hyper.html command
+once every {Nevent} timesteps.  This value is the count of those
+timesteps on which one (or more) events was detected.  It is NOT the
+number of distinct events, since more than one event may occur in the
+same {Nevent} time window.
+
+For value 11, each time the "hyper"_hyper.html command checks for an
+event, it invokes a compute to flag zero or more atoms as
+participating in one or more events.  E.g. atoms that have displaced
+more than some distance from the previous quench state.  Value 11 is
+the cummulative count of the number of atoms participating in any of
+the events that were found.
+
+The scalar and vector values calculated by this fix are all
+"intensive".
+
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command.  This fix is not invoked during "energy
+minimization"_minimize.html.
+
+[Restrictions:]
+
+This command can only be used if LAMMPS was built with the REPLICA
+package.  See the "Build package"_Build_package.html doc page for more
+info.
+
+[Related commands:]
+
+"hyper"_hyper.html, "fix hyper/local"_fix_hyper_local.html
+
+[Default:] None
+
+:line
+
+:link(Voter2013ghd)
+[(Voter2013)] S. Y. Kim, D. Perez, A. F. Voter, J Chem Phys, 139,
+144110 (2013).
+
+:link(Mironghd)
+[(Miron)] R. A. Miron and K. A. Fichthorn, J Chem Phys, 119, 6210 (2003).

doc/src/fix_hyper_local.txt

@@ -0,0 +1,404 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+fix hyper/local command :h3
+
+[Syntax:]
+
+fix ID group-ID hyper/local cutbond qfactor Vmax Tequil Dcut alpha Btarget :pre
+
+ID, group-ID are documented in "fix"_fix.html command :ulb,l
+hyper/local = style name of this fix command :l
+cutbond = max distance at which a pair of atoms is considered bonded (distance units) :l
+qfactor = max strain at which bias potential goes to 0.0 (unitless) :l
+Vmax = estimated height of bias potential (energy units) :l
+Tequil = equilibration temperature (temperature units) :l
+Dcut = minimum distance between boosted bonds (distance units) :l
+alpha = boostostat relaxation time (time units) :l
+Btarget = desired time boost factor (unitless) :l
+zero or more keyword/value pairs may be appended :l
+keyword = {lost} or {check/bias} or {check/coeff}
+  {lostbond} value = error/warn/ignore
+  {check/bias} values = Nevery error/warn/ignore
+  {check/coeff} values = Nevery error/warn/ignore :pre
+:ule
+
+[Examples:]
+
+fix 1 all hyper/local 1.0 0.3 0.8 300.0 :pre
+
+[Description:]
+
+This fix is meant to be used with the "hyper"_hyper.html command to
+perform a bond-boost local hyperdynamics (LHD) simulation.  The role
+of this fix is to a select multiple pairs of atoms in the system at
+each timestep to add a local bias potential to, which will alter the
+dynamics of the system in a manner that effectively accelerates time.
+This is in contrast to the "fix hyper/global"_fix_hyper_global.html
+command, which can be user to perform a global hyperdynamics (GHD)
+simulation, by adding a global bias potential to a single pair of
+atoms at each timestep.  GHD can time accelerate a small simulation
+with up to a few 100 atoms.  For larger systems, LHD is needed to
+achieve good time acceleration.
+
+For a system that undergoes rare transition events, where one or more
+atoms move over an energy barrier to a new potential energy basin, the
+effect of the bias potential is to induce more rapid transitions.
+This can lead to a dramatic speed-up in the rate at which events
+occurs, without altering their relative frequencies, thus leading to
+an overall increase in the elapsed real time of the simulation as
+compared to running for the same number of timesteps with normal MD.
+See the "hyper"_hyper.html doc page for a more general discussion of
+hyperdynamics and citations that explain both GHD and LHD.
+
+The equations and logic used by this fix and described here to perform
+LHD follow the description given in "(Voter2013)"_#Voter2013lhd.  The
+bond-boost form of a bias potential for HD is due to Miron and
+Fichthorn as described in "(Miron)"_#Mironlhd.
+
+To understand this description, you should first read the description
+of the GHD algorithm on the "fix hyper/global"_fix_hyper_global.html
+doc page.  This description of LHD builds on the GHD description.
+
+The definition of bonds, Eij, and Emax are the same for GHD and LHD.
+The formulas for Vij(max) and Fij(max) are also the same except for a
+pre-factor Cij, explained below.
+
+The bias energy Vij applied to a bond IJ with maximum strain is
+
+Vij(max) = Cij * Vmax * (1 - (Eij/q)^2) for abs(Eij) < qfactor
+         = 0 otherwise :pre
+
+The derivative of Vij(max) with respect to the position of each atom
+in the IJ bond gives a bias force Fij(max) acting on the bond as
+
+Fij(max) = - dVij(max)/dEij = 2 Cij Vmax Eij / qfactor^2   for abs(Eij) < qfactor
+         = 0 otherwise :pre
+
+which can be decomposed into an equal and opposite force acting on
+only the two I,J atoms in the IJ bond.
+
+The key difference is that in GHD a bias energy and force is added (on
+a particular timestep) to only one bond (pair of atoms) in the system,
+which is the bond with maximum strain Emax.
+
+In LHD, a bias energy and force can be added to multiple bonds
+separated by the specified {Dcut} distance or more.  A bond IJ is
+biased if it is the maximum strain bond within its local
+"neighborhood", which is defined as the bond IJ plus any neighbor
+bonds within a distance {Dcut} from IJ.  The "distance" between bond
+IJ and bond KL is the minimum distance between any of the IK, IL, JK,
+JL pairs of atoms.
+
+For a large system, multiple bonds will typically meet this
+requirement, and thus a bias potential Vij(max) will be applied to
+many bonds on the same timestep.
+
+In LHD, all bonds store a Cij prefactor which appears in the Vij(max)
+and Fij(max) equations above.  Note that the Cij factor scales the
+strength of the bias energy and forces whenever bond IJ is the maximum
+strain bond in its neighborhood.
+
+Cij is initialized to 1.0 when a bond between the I,J atoms is first
+defined.  The specified {Btarget} factor is then used to adjust the
+Cij prefactors for each bond every timestep in the following manner.
+
+An instantaneous boost factor Bij is computed each timestep
+for each bond, as
+
+Bij = exp(beta * Vkl(max)) :pre
+
+where Vkl(max) is the bias energy of the maxstrain bond KL within bond
+IJ's neighborhood, beta = 1/kTequil, and {Tequil} is the temperature
+of the system and an argument to this fix.
+
+NOTE: To run LHD, the input script must also use the "fix
+langevin"_fix_langevin.html command to thermostat the atoms at the
+same {Tequil} as specified by this fix, so that the system is running
+constant-temperature (NVT) dynamics.  LAMMPS does not check that this
+is done.
+
+Note that if IJ = KL, then bond IJ is a biased bond on that timestep,
+otherwise it is not.  But regardless, the boost factor Bij can be
+thought of an estimate of time boost currently being applied within a
+local region centered on bond IJ.  For LHD, we want this to be the
+specified {Btarget} value everywhere in the simulation domain.
+
+To accomplish this, if Bij < Btarget, the Cij prefactor for bond IJ is
+incremented on the current timestep by an amount proportional to the
+inverse of the specified {alpha} and the difference (Bij - Btarget).
+Conversely if Bij > Btarget, Cij is decremented by the same amount.
+This procedure is termed "boostostatting" in
+"(Voter2013)"_#Voter2013lhd.  It drives all of the individual Cij to
+values such that when Vij{max} is applied as a bias to bond IJ, the
+resulting boost factor Bij will be close to {Btarget} on average.
+Thus the LHD time acceleration factor for the overall system is
+effectively {Btarget}.
+
+Note that in LHD, the boost factor {Btarget} is specified by the user.
+This is in contrast to global hyperdynamics (GHD) where the boost
+factor varies each timestep and is computed as a function of {Vmax},
+Emax, and {Tequil}; see the "fix hyper/global"_fix_hyper_global.html
+doc page for details.
+
+:line
+
+Here is additional information on the input parameters for LHD.
+
+Note that the {cutbond}, {qfactor}, and {Tequil} arguments have the
+same meaning as for GHD.  The {Vmax} argument is slightly different.
+The {Dcut}, {alpha}, and {Btarget} parameters are unique to LHD.
+
+The {cutbond} argument is the cutoff distance for defining bonds
+between pairs of nearby atoms.  A pair of I,J atoms in their
+equilibrium, minimum-energy configuration, which are separated by a
+distance Rij < {cutbond}, are flagged as a bonded pair.  Setting
+{cubond} to be ~25% larger than the nearest-neighbor distance in a
+crystalline lattice is a typical choice for solids, so that bonds
+exist only between nearest neighbor pairs.
+
+The {qfactor} argument is the limiting strain at which the bias
+potential goes to 0.0.  It is dimensionless, so a value of 0.3 means a
+bond distance can be up to 30% larger or 30% smaller than the
+equilibrium (quenched) R0ij distance and the two atoms in the bond
+could still experience a non-zero bias force.
+
+If {qfactor} is set too large, then transitions from one energy basin
+to another are affected because the bias potential is non-zero at the
+transition state (e.g. saddle point).  If {qfactor} is set too small
+than little boost can be achieved because the Eij strain of some bond in
+the system will (nearly) always exceed {qfactor}.  A value of 0.3 for
+{qfactor} is typically a reasonable value.
+
+The {Vmax} argument is a fixed prefactor on the bias potential.  There
+is a also a dynamic prefactor Cij, driven by the choice of {Btarget}
+as discussed above.  The product of these should be a value less than
+the smallest barrier height for an event to occur.  Otherwise the
+applied bias potential may be large enough (when added to the
+interatomic potential) to produce a local energy basin with a maxima
+in the center.  This can produce artificial energy minima in the same
+basin that trap an atom.  Or if Cij*{Vmax} is even larger, it may
+induce an atom(s) to rapidly transition to another energy basin.  Both
+cases are "bad dynamics" which violate the assumptions of LHD that
+guarantee an accelerated time-accurate trajectory of the system.
+
+NOTE: It may seem that {Vmax} can be set to any value, and Cij will
+compensate to reduce the overall prefactor if necessary.  However the
+Cij are initialized to 1.0 and the boostostatting procedure typically
+operates slowly enough that there can be a time period of bad dynamics
+if {Vmax} is set too large.  A better strategy is to set {Vmax} to the
+smallest barrier height for an event (the same as for GHD), so that
+the Cij remain near unity.
+
+The {Tequil} argument is the temperature at which the system is
+simulated; see the comment above about the "fix
+langevin"_fix_langevin.html thermostatting.  It is also part of the
+beta term in the exponential factor that determines how much boost is
+achieved as a function of the bias potential.  See the discussion of
+the {Btarget} argument below.
+
+As discussed above, the {Dcut} argument is the distance required
+between two locally maxstrain bonds for them to both be selected as
+biased bonds on the same timestep.  Computationally, the larger {Dcut}
+is, the more work (computation and communication) must be done each
+timestep within the LHD algorithm.  And the fewer bonds can be
+simultaneously biased, which may mean the specified {Btarget} time
+acceleration cannot be achieved.
+
+Physically {Dcut} should be a long enough distance that biasing two
+pairs of atoms that close together will not influence the dynamics of
+each pair.  E.g. something like 2x the cutoff of the interatomic
+potential.  In practice a {Dcut} value of ~10 Angstroms seems to work
+well for many solid-state systems.
+
+NOTE: You must also insure that ghost atom communication is performed
+for a distance of at least {Dcut} + {cutevent} where {cutevent} = the
+distance one or more atoms move (between quenched states) to be
+considered an "event".  It is an argument to the "compute
+event/displace" command used to detect events.  By default the ghost
+communication distance is set by the pair_style cutoff, which will
+typically be < {Dcut}.  The "comm_modify cutoff"_comm_modify.html
+command can be used to set the ghost cutoff explicitly, e.g.
+
+comm_modify cutoff 12.0 :pre
+
+This fix does not know the {cutevent} parameter, but uses half the
+bond length as an estimate to warn if the ghost cutoff is not long
+enough.
+
+As described above the {alpha} argument is a pre-factor in the
+boostostat update equation for each bond's Cij prefactor.  {Alpha} is
+specified in time units, similar to other thermostat or barostat
+damping parameters.  It is roughly the physical time it will take the
+boostostat to adjust a Cij value from a too high (or too low) value to
+a correct one.  An {alpha} setting of a few ps is typically good for
+solid-state systems.  Note that the {alpha} argument here is the
+inverse of the alpha parameter discussed in
+"(Voter2013)"_#Voter2013lhd.
+
+The {Btarget} argument is the desired time boost factor (a value > 1)
+that all the atoms in the system will experience.  The elapsed time
+t_hyper for an LHD simulation running for {N} timesteps is simply
+
+t_hyper = Btarget * N*dt :pre
+
+where dt is the timestep size defined by the "timestep"_timestep.html
+command.  The effective time acceleration due to LHD is thus t_hyper /
+N*dt = Btarget, where N*dt is elapsed time for a normal MD run
+of N timesteps.
+
+You cannot choose an arbitrarily large setting for {Btarget}.  The
+maximum value you should choose is
+
+Btarget = exp(beta * Vsmall) :pre
+
+where Vsmall is the smallest event barrier height in your system, beta
+= 1/kTequil, and {Tequil} is the specified temperature of the system
+(both by this fix and the Langevin thermostat).
+
+Note that if {Btarget} is set smaller than this, the LHD simulation
+will run correctly.  There will just be fewer events because the hyper
+time (t_hyper equation above) will be shorter.
+
+NOTE: If you have no physical intuition as to the smallest barrier
+height in your system, a reasonable strategy to determine the largest
+{Btarget} you can use for an LHD model, is to run a sequence of
+simulations with smaller and smaller {Btarget} values, until the event
+rate does not change.
+
+:line
+
+[Restart, fix_modify, output, run start/stop, minimize info:]
+
+No information about this fix is written to "binary restart
+files"_restart.html.
+
+The "fix_modify"_fix_modify.html {energy} option is supported by this
+fix to add the energy of the bias potential to the the system's
+potential energy as part of "thermodynamic output"_thermo_style.html.
+
+This fix computes a global scalar and global vector of length 23,
+which can be accessed by various "output
+commands"_Howto_output.html.  The scalar is the magnitude of
+the bias potential (energy units) applied on the current timestep,
+summed over all biased bonds.  The vector stores the following
+quantities:
+
+1 = # of biased bonds on this step
+2 = max strain Eij of any bond on this step (unitless)
+3 = average bias potential for all biased bonds on this step (energy units)
+4 = average # of bonds/atom on this step
+5 = average neighbor bonds/bond on this step within {Dcut} :ul
+
+6 = fraction of steps and bonds with no bias during this run
+7 = max drift distance of any atom during this run (distance units)
+8 = max bond length during this run (distance units)
+9 = average # of biased bonds/step during this run
+10 = average bias potential for all biased bonds during this run (energy units)
+11 = max bias potential for any biased bond during this run (energy units)
+12 = min bias potential for any biased bond during this run (energy units)
+13 = max distance from my sub-box of any ghost atom with maxstrain < qfactor during this run (distance units)
+14 = max distance outside my box of any ghost atom with any maxstrain during this run (distance units)
+15 = count of ghost neighbor atoms not found on reneighbor steps during this run
+16 = count of lost bond partners during this run
+17 = average bias coeff for lost bond partners during this run
+18 = count of bias overlaps found during this run
+19 = count of non-matching bias coefficients found during this run :ul
+
+20 = cummulative hyper time since fix created (time units)
+21 = cummulative count of event timesteps since fix created
+22 = cummulative count of atoms in events since fix created
+23 = cummulative # of new bonds since fix created :ul
+
+The first quantities (1-5) are for the current timestep.  Quantities
+6-19 are for the current hyper run.  They are reset each time a new
+hyper run is performed.  Quantities 20-23 are cummulative across
+multiple runs (since the fix was defined in the input script).
+
+For value 6, the numerator is a count of all biased bonds on every
+timestep whose bias energy = 0.0 due to Eij >= {qfactor}.  The
+denominator is the count of all biased bonds on all timesteps.
+
+For value 7, drift is the distance an atom moves between timesteps
+when the bond list is reset, i.e. between events.  Atoms involved in
+an event will typically move the greatest distance since others are
+typically oscillating around their lattice site.
+
+For values 13 and 14, the maxstrain of a ghost atom is the maxstrain
+of any bond it is part of, and it is checked for ghost atoms within
+the bond neighbor cutoff.
+
+Values 15-19 are mostly useful for debugging and diagnositc purposes.
+
+For values 15-17, it is possible that a ghost atom owned by another
+processor will move far enough (e.g. as part of an event-in-progress)
+that it will no longer be within the communication cutoff distance for
+acquiring ghost atoms.  Likewise it may be a ghost atom bond partner
+that cannot be found because it has moved too far.  These values count
+those occurrences.  Because they typically involve atoms that are part
+of events, they do not usually indicate bad dynamics.  Value 16 is the
+average bias coefficient for bonds where a partner atom was lost.
+
+For value 18, no two bonds should be biased if they are within a
+{Dcut} distance of each other.  This value should be zero, indicating
+that no pair of bonds "overlap", meaning they are closer than {Dcut}
+from each other.
+
+For value 19, the same bias coefficient is stored by both atoms in an
+IJ bond.  This value should be zero, indicating that for all bonds,
+each atom in the bond stores the a bias coefficient with the same
+value.
+
+Value 20 is simply the specified {boost} factor times the number of
+timestep times the timestep size.
+
+For value 21, events are checked for by the "hyper"_hyper.html command
+once every {Nevent} timesteps.  This value is the count of those
+timesteps on which one (or more) events was detected.  It is NOT the
+number of distinct events, since more than one event may occur in the
+same {Nevent} time window.
+
+For value 22, each time the "hyper"_hyper.html command checks for an
+event, it invokes a compute to flag zero or more atoms as
+participating in one or more events.  E.g. atoms that have displaced
+more than some distance from the previous quench state.  Value 22 is
+the cummulative count of the number of atoms participating in any of
+the events that were found.
+
+Value 23 tallies the number of new bonds created by the bond reset
+operation.  Bonds between a specific I,J pair of atoms may persist for
+the entire hyperdynamics simulation if neither I or J are involved in
+an event.
+
+The scalar and vector values calculated by this fix are all
+"intensive".
+
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command.  This fix is not invoked during "energy
+minimization"_minimize.html.
+
+[Restrictions:]
+
+This fix is part of the REPLICA package.  It is only enabled if LAMMPS
+was built with that package.  See the "Build package"_Build_package.html
+doc page for more info.
+
+[Related commands:]
+
+"hyper"_hyper.html, "fix hyper/global"_fix_hyper_global.html
+
+[Default:] None
+
+:line
+
+:link(Voter2013lhd)
+[(Voter2013)] S. Y. Kim, D. Perez, A. F. Voter, J Chem Phys, 139,
+144110 (2013).
+
+:link(Mironlhd)
+[(Miron)] R. A. Miron and K. A. Fichthorn, J Chem Phys, 119, 6210 (2003).

doc/src/fix_meso_move.txt

@@ -0,0 +1,233 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+fix meso/move command :h3
+
+[Syntax:]
+
+fix ID group-ID meso/move style args keyword values ... :pre
+
+ID, group-ID are documented in "fix"_fix.html command :ulb,l
+meso/move = style name of this fix command :l
+style = {linear} or {wiggle} or {rotate} or {variable} :l
+  {linear} args = Vx Vy Vz
+    Vx,Vy,Vz = components of velocity vector (velocity units), any component can be specified as NULL
+  {wiggle} args = Ax Ay Az period
+    Ax,Ay,Az = components of amplitude vector (distance units), any component can be specified as NULL
+    period = period of oscillation (time units)
+  {rotate} args = Px Py Pz Rx Ry Rz period
+    Px,Py,Pz = origin point of axis of rotation (distance units)
+    Rx,Ry,Rz = axis of rotation vector
+    period = period of rotation (time units)
+  {variable} args = v_dx v_dy v_dz v_vx v_vy v_vz
+    v_dx,v_dy,v_dz = 3 variable names that calculate x,y,z displacement as function of time, any component can be specified as NULL
+    v_vx,v_vy,v_vz = 3 variable names that calculate x,y,z velocity as function of time, any component can be specified as NULL :pre
+
+zero or more keyword/value pairs may be appended :l
+keyword = {units} :l
+  {units} value = {box} or {lattice} :pre
+:ule
+
+[Examples:]
+
+fix 1 boundary meso/move wiggle 3.0 0.0 0.0 1.0 units box
+fix 2 boundary meso/move rotate 0.0 0.0 0.0 0.0 0.0 1.0 5.0
+fix 2 boundary meso/move variable v_myx v_myy NULL v_VX v_VY NULL :pre
+
+[Description:]
+
+Perform updates of position, velocity, internal energy and local
+density for mesoscopic particles in the group each timestep using the
+specified settings or formulas, without regard to forces on the
+particles. This can be useful for boundary, solid bodies or other
+particles, whose movement can influence nearby particles.
+
+The operation of this fix is exactly like that described by the
+"fix move"_fix_move.html command, except that particles' density,
+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. "fix meso"_fix_meso.html, "fix
+meso/stationary"_fix_meso_stationary.html), since that will change their
+positions and velocities twice.
+
+NOTE: As particles move due to this fix, they will pass thru 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 "fix
+meso"_fix_meso.html 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: As dicsussed below, particles are moved relative to their initial
+position at the time the fix is specified.  These initial coordinates
+are stored by the fix in "unwrapped" form, by using the image flags
+associated with each particle.  See the "dump custom"_dump.html command
+for a discussion of "unwrapped" coordinates.  See the Atoms section of
+the "read_data"_read_data.html command for a discussion of image flags
+and how they are set for each particle.  You can reset the image flags
+(e.g. to 0) before invoking this fix by using the "set image"_set.html
+command.
+
+:line
+
+The {linear} style moves particles at a constant velocity, so that their
+position {X} = (x,y,z) as a function of time is given in vector
+notation as
+
+X(t) = X0 + V * delta :pre
+
+where {X0} = (x0,y0,z0) is their position at the time the fix is
+specified, {V} is the specified velocity vector with components
+(Vx,Vy,Vz), and {delta} is the time elapsed since the fix was
+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 "fix meso"_fix_meso.html command would perform, using
+the corresponding force component on the particle.
+
+Note that the {linear} style is identical to using the {variable}
+style with an "equal-style variable"_variable.html that uses the
+vdisplace() function.  E.g.
+
+variable V equal 10.0
+variable x equal vdisplace(0.0,$V)
+fix 1 boundary move variable v_x NULL NULL v_V NULL NULL :pre
+
+The {wiggle} style moves particles in an oscillatory fashion, so that
+their position {X} = (x,y,z) as a function of time is given in vector
+notation as
+
+X(t) = X0 + A sin(omega*delta) :pre
+
+where {X0} = (x0,y0,z0) is their position at the time the fix is
+specified, {A} is the specified amplitude vector with components
+(Ax,Ay,Az), {omega} is 2 PI / {period}, and {delta} is the time
+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 "fix meso"_fix_meso.html command would perform, using the
+corresponding force component on the particle.
+
+Note that the {wiggle} style is identical to using the {variable}
+style with "equal-style variables"_variable.html that use the
+swiggle() and cwiggle() functions.  E.g.
+
+variable A equal 10.0
+variable T equal 5.0
+variable omega equal 2.0*PI/$T
+variable x equal swiggle(0.0,$A,$T)
+variable v equal v_omega*($A-cwiggle(0.0,$A,$T))
+fix 1 boundary move variable v_x NULL NULL v_v NULL NULL :pre
+
+The {rotate} style rotates particles around a rotation axis {R} =
+(Rx,Ry,Rz) that goes thru a point {P} = (Px,Py,Pz).  The {period} of
+the rotation is also specified.  The direction of rotation for the
+particles around the rotation axis is consistent with the right-hand
+rule: if your right-hand thumb points along {R}, then your fingers wrap
+around the axis in the direction of rotation.
+
+This style also sets the velocity of each particle to (omega cross
+Rperp) where omega is its angular velocity around the rotation axis and
+Rperp is a perpendicular vector from the rotation axis to the particle.
+
+The {variable} style allows the position and velocity components of
+each particle to be set by formulas specified via the
+"variable"_variable.html command.  Each of the 6 variables is
+specified as an argument to the fix as v_name, where name is the
+variable name that is defined elsewhere in the input script.
+
+Each variable must be of either the {equal} or {atom} style.
+{Equal}-style variables compute a single numeric quantity, that can be
+a function of the timestep as well as of other simulation values.
+{Atom}-style variables compute a numeric quantity for each particle, that
+can be a function per-atom quantities, such as the particle's position, as
+well as of the timestep and other simulation values.  Note that this
+fix stores the original coordinates of each particle (see note below) so
+that per-atom quantity can be used in an atom-style variable formula.
+See the "variable"_variable.html command for details.
+
+The first 3 variables (v_dx,v_dy,v_dz) specified for the {variable}
+style are used to calculate a displacement from the particle's original
+position at the time the fix was specified.  The second 3 variables
+(v_vx,v_vy,v_vz) specified are used to compute a velocity for each
+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 "fix meso"_fix_meso.html
+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.
+
+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 "units"_units.html
+command, e.g. velocity in Angstroms/fmsec 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 "lattice"_lattice.html command must have
+been previously used to define the lattice spacing.  Each of these 3
+quantities may be dependent on the x,y,z dimension, since the lattice
+spacings can be different in x,y,z.
+
+:line
+
+[Restart, fix_modify, output, run start/stop, minimize info:]
+
+This fix writes the original coordinates of moving particles to "binary
+restart files"_restart.html, as well as the initial timestep, so that
+the motion can be continuous in a restarted simulation.  See the
+"read_restart"_read_restart.html command for info on how to re-specify
+a fix in an input script that reads a restart file, so that the
+operation of the fix continues in an uninterrupted fashion.
+
+NOTE: Because the move positions are a function of the current
+timestep and the initial timestep, you cannot reset the timestep to a
+different value after reading a restart file, if you expect a fix move
+command to work in an uninterrupted fashion.
+
+None of the "fix_modify"_fix_modify.html options are relevant to this
+fix.
+
+This fix produces a per-atom array which can be accessed by various
+"output commands"_Howto_output.html.  The number of columns for each
+atom is 3, and the columns store the original unwrapped x,y,z coords
+of each particle.  The per-atom values can be accessed on any timestep.
+
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command.
+
+This fix is not invoked during "energy minimization"_minimize.html.
+
+[Restrictions:]
+
+This fix is part of the USER-SDPD package.  It is only enabled if
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
+
+This fix requires that atoms store density and internal energy as
+defined by the "atom_style meso"_atom_style.html command.
+
+All particles in the group must be mesoscopic SPH/SDPD particles.
+
+[Related commands:]
+
+"fix move"_fix_move.html, "fix meso"_fix_meso.html,
+"displace_atoms"_displace_atoms.html
+
+[Default:]
+
+The option default is units = lattice.

doc/src/fix_msst.txt

@@ -6,7 +6,7 @@
 
 :line
 
- fix msst command :h3
+fix msst command :h3
 
 [Syntax:]
 

doc/src/fix_neb.txt

@@ -35,7 +35,7 @@ keyword = {parallel} or {perp} or {end} :l
 fix 1 active neb 10.0
 fix 2 all neb 1.0 perp 1.0 end last
 fix 2 all neb 1.0 perp 1.0 end first 1.0 end last 1.0
-fix 1 all neb 1.0 nudge ideal end last/efirst 1 :pre
+fix 1 all neb 1.0 parallel ideal end last/efirst 1 :pre
 
 [Description:]
 
@@ -212,7 +212,7 @@ page for more info.
 
 [Default:]
 
-The option defaults are nudge = neigh, perp = 0.0, ends is not
+The option defaults are parallel = neigh, perp = 0.0, ends is not
 specified (no inter-replica force on the end replicas).
 
 :line

doc/src/fix_nve_awpmd.txt

@@ -0,0 +1,56 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+fix nve/awpmd command :h3
+
+[Syntax:]
+
+fix ID group-ID nve/awpmd :pre
+
+ID, group-ID are documented in "fix"_fix.html command
+nve/awpmd = style name of this fix command :ul
+
+[Examples:]
+
+fix 1 all nve/awpmd :pre
+
+[Description:]
+
+Perform constant NVE integration to update position and velocity for
+nuclei and electrons in the group for the "Antisymmetrized Wave Packet
+Molecular Dynamics"_pair_awpmd.html model.  V is volume; E is energy.
+This creates a system trajectory consistent with the microcanonical
+ensemble.
+
+The operation of this fix is exactly like that described by the "fix
+nve"_fix_nve.html command, except that the width and width-velocity of
+the electron wavefunctions are also updated.
+
+:line
+
+[Restart, fix_modify, output, run start/stop, minimize info:]
+
+No information about this fix is written to "binary restart
+files"_restart.html.  None of the "fix_modify"_fix_modify.html options
+are relevant to this fix.  No global or per-atom quantities are stored
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command.  This fix is not invoked during "energy
+minimization"_minimize.html.
+
+[Restrictions:]
+
+This fix is part of the USER-AWPMD package.  It is only enabled if
+LAMMPS was built with that package.  See the "Build
+package"_Build_package.html doc page for more info.
+
+[Related commands:]
+
+"fix nve"_fix_nve.html
+
+[Default:] none

doc/src/fix_nve_dot.txt

@@ -36,8 +36,8 @@ The command is equivalent to the "fix nve"_fix_nve.html.
 The particles are always considered to have a finite size.
 
 An example input file can be found in /examples/USER/cgdna/examples/duplex1/.
-A technical report with more information on this integrator can be found
-"here"_PDF/USER-CGDNA-overview.pdf.
+Further details of the implementation and stability of the integrator are contained in "(Henrich)"_#Henrich3. 
+The preprint version of the article can be found "here"_PDF/USER-CGDNA.pdf.
 
 :line
 
@@ -59,3 +59,5 @@ See the "Build package"_Build_package.html doc page for more info.
 [(Davidchack)] R.L Davidchack, T.E. Ouldridge, and M.V. Tretyakov. J. Chem. Phys. 142, 144114 (2015).
 :link(Miller1)
 [(Miller)] T. F. Miller III, M. Eleftheriou, P. Pattnaik, A. Ndirango, G. J. Martyna, J. Chem. Phys., 116, 8649-8659 (2002).
+:link(Henrich3)
+[(Henrich)] O. Henrich, Y. A. Gutierrez-Fosado, T. Curk, T. E. Ouldridge, Eur. Phys. J. E 41, 57 (2018).

doc/src/fix_nve_dotc_langevin.txt

@@ -114,8 +114,8 @@ The scale factor after the {angmom} keyword gives the ratio of the rotational to
 the translational friction coefficient.
 
 An example input file can be found in /examples/USER/cgdna/examples/duplex2/.
-A technical report with more information on this integrator can be found
-"here"_PDF/USER-CGDNA-overview.pdf.
+Further details of the implementation and stability of the integrators are contained in "(Henrich)"_#Henrich4.              
+The preprint version of the article can be found "here"_PDF/USER-CGDNA.pdf.
 
 :line
 
@@ -139,3 +139,5 @@ See the "Build package"_Build_package.html doc page for more info.
 [(Miller)] T. F. Miller III, M. Eleftheriou, P. Pattnaik, A. Ndirango, G. J. Martyna, J. Chem. Phys., 116, 8649-8659 (2002).
 :link(Dunweg3)
 [(Dunweg)] B. Dunweg, W. Paul, Int. J. Mod. Phys. C, 2, 817-27 (1991).
+:link(Henrich4)
+[(Henrich)] O. Henrich, Y. A. Gutierrez-Fosado, T. Curk, T. E. Ouldridge, Eur. Phys. J. E 41, 57 (2018).

doc/src/fix_nve_sphere.txt

@@ -8,6 +8,7 @@
 
 fix nve/sphere command :h3
 fix nve/sphere/omp command :h3
+fix nve/sphere/kk command :h3
 
 [Syntax:]
 

doc/src/fix_nvt_sllod.txt

@@ -63,6 +63,11 @@ implemented in LAMMPS, they are coupled to a Nose/Hoover chain
 thermostat in a velocity Verlet formulation, closely following the
 implementation used for the "fix nvt"_fix_nh.html command.
 
+NOTE: A recent (2017) book by "(Daivis and Todd)"_#Daivis-sllod
+discusses use of the SLLOD method and non-equilibrium MD (NEMD)
+thermostatting generally, for both simple and complex fluids,
+e.g. molecular systems.  The latter can be tricky to do correctly.
+
 Additional parameters affecting the thermostat are specified by
 keywords and values documented with the "fix nvt"_fix_nh.html
 command.  See, for example, discussion of the {temp} and {drag}
@@ -177,3 +182,7 @@ Same as "fix nvt"_fix_nh.html, except tchain = 1.
 
 :link(Daivis)
 [(Daivis and Todd)] Daivis and Todd, J Chem Phys, 124, 194103 (2006).
+
+:link(Daivis-sllod)
+[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dyanmics (book),
+Cambridge University Press, https://doi.org/10.1017/9781139017848, (2017).

doc/src/fix_plumed.txt

@@ -0,0 +1,117 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+fix plumed command :h3
+
+[Syntax:]
+
+fix ID group-ID plumed keyword value ... :pre
+
+ID, group-ID are documented in "fix"_fix.html command :ulb,l
+plumed = style name of this fix command :l
+keyword = {plumedfile} or {outfile} :l
+  {plumedfile} arg = name of PLUMED input file to use (default: NULL)
+  {outfile} arg = name of file on which to write the PLUMED log (default: NULL) :pre
+:ule
+
+[Examples:]
+
+fix pl all plumed all plumed plumedfile plumed.dat outfile p.log
+
+[Description:]
+
+This fix instructs LAMMPS to call the "PLUMED"_plumedhome library, which
+allows one to perform various forms of trajectory analysis on the fly
+and to also use methods such as umbrella sampling and metadynamics to
+enhance the sampling of phase space.
+
+The documentation included here only describes the fix plumed command
+itself.  This command is LAMMPS specific, whereas most of the
+functionality implemented in PLUMED, however, will work with a range of
+MD codes, and when PLUMED is used as a stand alone code for analysis.
+The full "documentation for PLUMED"_plumeddocs is available online and
+included in the PLUMED source code.  The PLUMED library development is
+hosted at
+"https://github.com/plumed/plumed2"_https://github.com/plumed/plumed2
+A detailed discussion of the code can be found in "(PLUMED)"_#PLUMED.
+
+There is an example input for using this package with LAMMPS in the
+examples/USER/plumed directory.
+
+:line
+
+The command to make LAMMPS call PLUMED during a run requires two keyword
+value pairs pointing to the PLUMED input file and an output file for the
+PLUMED log. The user must specify these arguments every time PLUMED is
+to be used.  Furthermore, the fix plumed command should appear in the
+LAMMPS input file [after] relevant input paramters (e.g. the timestep)
+have been set.
+
+The {group-ID} entry is ignored. LAMMPS will always pass all the atoms
+to PLUMED and there can only be one instance of the plumed fix at a
+time. The plumed fix communicates the minimum amount of information
+required and the PLUMED supports multiple, completely independent
+collective variables, multiple independent biases and multiple
+independent forms of analysis.  There is thus really no restriction in
+functionality by only allowing only one plumed fix in the LAMMPS input.
+
+The {plumedfile} keyword allows the user to specify the name of the
+PLUMED input file.  Instructions as to what should be included in a
+plumed input file can be found in the "documentation for
+PLUMED"_plumeddocs
+
+The {outfile} keyword allows the user to specify the name of a file on
+which to output the PLUMED log.  This log file normally just parrots the
+information that is contained in the input file.  The names of the files
+on which the results from the various analyses that have been performed
+using PLUMED will be specified by the user in the PLUMED input file.
+
+[Restart, fix_modify, output, run start/stop, minimize info:]
+
+When performing a restart of a calculation that involves PLUMED you must
+include a RESTART command in the PLUMED input file as detailed in the
+"PLUMED documentation"_plumeddocs.  When the restart command is found in
+the PLUMED input PLUMED will append to the files that were generated in
+the run that was performed previously.  No part of the PLUMED restart
+data is included in the LAMMPS restart files.  Furthermore, any history
+dependent bias potentials that were accumulated in previous calculations
+will be read in when the RESTART command is included in the PLUMED
+input.
+
+The "fix_modify"_fix_modify.html {energy} option is not supported by
+this fix.
+
+Nothing is computed by this fix that can be accessed by any of the
+"output commands"_Howto_output.html within LAMMPS.  All the quantities
+of interest can be output by commands that are native to PLUMED,
+however.
+
+[Restrictions:]
+
+This fix is part of the USER-PLUMED package.  It is only enabled if
+LAMMPS was built with that package.  See the "Build
+package"_Build_package.html doc page for more info.
+
+There can only be one plumed fix active at a time.
+
+[Related commands:]
+
+"fix smd"_fix_smd.html
+"fix colvars"_fix_colvars.html
+
+[Default:]
+
+The default options are plumedfile = NULL and outfile = NULL
+
+:line
+
+:link(PLUMED)
+[(PLUMED)] G.A. Tribello, M. Bonomi, D. Branduardi, C. Camilloni and G. Bussi, Comp. Phys. Comm 185, 604 (2014)
+
+:link(plumeddocs,http://www.plumed.org/documentation)
+:link(plumedhome,http://www.plumed.org/)

doc/src/fix_poems.txt

@@ -6,7 +6,7 @@
 
 :line
 
-fix poems :h3
+fix poems command :h3
 
 Syntax:
 

doc/src/fix_property_atom.txt

@@ -7,6 +7,7 @@
 :line
 
 fix property/atom command :h3
+fix property/atom/kk command :h3
 
 [Syntax:]
 
@@ -201,6 +202,7 @@ added classes.
 :line
 
 :link(isotopes)
+
 Example for using per-atom masses with TIP4P water to
 study isotope effects. When setting up simulations with the "TIP4P
 pair styles"_Howto_tip4p.html for water, you have to provide exactly
@@ -238,6 +240,28 @@ set group hwat mass 2.0141018 :pre
 
 :line
 
+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 "Speed packages"_Speed_packages.html 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 "Build
+package"_Build_package.html 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 "-suffix command-line
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
+
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restart, fix_modify, output, run start/stop, minimize info:]
 
 This fix writes the per-atom values it stores to "binary restart

doc/src/fix_rigid_meso.txt

@@ -0,0 +1,349 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+fix rigid/meso command :h3
+
+[Syntax:]
+
+fix ID group-ID rigid/meso bodystyle args keyword values ... :pre
+
+ID, group-ID are documented in "fix"_fix.html command :ulb,l
+rigid/meso = style name of this fix command :l
+bodystyle = {single} or {molecule} or {group} :l
+  {single} args = none
+  {molecule} args = none
+  {custom} args = {i_propname} or {v_varname}
+    i_propname = an integer property defined via fix property/atom
+    v_varname  = an atom-style or atomfile-style variable
+  {group} args = N groupID1 groupID2 ...
+    N = # of groups
+    groupID1, groupID2, ... = list of N group IDs :pre
+
+zero or more keyword/value pairs may be appended :l
+keyword = {reinit} or {force} or {torque} or {infile} :l
+  {reinit} = {yes} or {no}
+  {force} values = M xflag yflag zflag
+    M = which rigid body from 1-Nbody (see asterisk form below)
+    xflag,yflag,zflag = off/on if component of center-of-mass force is active
+  {torque} values = M xflag yflag zflag
+    M = which rigid body from 1-Nbody (see asterisk form below)
+    xflag,yflag,zflag = off/on if component of center-of-mass torque is active
+  {infile} filename
+    filename = file with per-body values of mass, center-of-mass, moments of inertia :pre
+:ule
+
+[Examples:]
+
+fix 1 ellipsoid rigid/meso single
+fix 1 rods      rigid/meso molecule
+fix 1 spheres   rigid/meso single force 1 off off on
+fix 1 particles rigid/meso molecule force 1*5 off off off force 6*10 off off on
+fix 2 spheres   rigid/meso group 3 sphere1 sphere2 sphere3 torque * off off off  :pre
+	
+[Description:]
+
+Treat one or more sets of mesoscopic SPH/SDPD particles as independent
+rigid bodies.  This means that each timestep the total force and torque
+on each rigid body is computed as the sum of the forces and torques on
+its constituent particles.  The coordinates and velocities of the
+particles in each body are then updated so that the body moves and
+rotates as a single entity using the methods described in the paper by
+"(Miller)"_#Miller. Density and internal energy of the particles will
+also be updated. This is implemented by creating internal data structures
+for each rigid body and performing time integration on these data
+structures.  Positions and velocities of the constituent particles are
+regenerated from the rigid body data structures in every time step. This
+restricts which operations and fixes can be applied to rigid bodies. See
+below for a detailed discussion.
+
+The operation of this fix is exactly like that described by the
+"fix rigid/nve"_fix_rigid.html command, except that particles' density,
+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. "fix meso"_fix_meso.html,
+"fix meso/stationary"_fix_meso_stationary.html), 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 "fix meso"_fix_meso.html
+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 "fix
+meso/stationary"_fix_meso_stationary.html instead. If you would like to
+move particles with a constant velocity use "fix
+meso/move"_fix_meso_move.html.
+
+IMPORTANT NOTE: The aggregate properties of each rigid body are
+calculated at the start of a simulation run and are maintained in
+internal data structures. The properties include the position and
+velocity of the center-of-mass of the body, its moments of inertia, and
+its angular momentum.  This is done using the properties of the
+constituent particles of the body at that point in time (or see the {infile}
+keyword option).  Thereafter, changing these properties of individual
+particles in the body will have no effect on a rigid body's dynamics, unless
+they effect any computation of per-particle forces or torques. If the
+keyword {reinit} is set to {yes} (the default), the rigid body data
+structures will be recreated at the beginning of each {run} command;
+if the keyword {reinit} is set to {no}, the rigid body data structures
+will be built only at the very first {run} command and maintained for
+as long as the rigid fix is defined. For example, you might think you
+could displace the particles in a body or add a large velocity to each particle
+in a body to make it move in a desired direction before a 2nd run is
+performed, using the "set"_set.html or
+"displace_atoms"_displace_atoms.html or "velocity"_velocity.html
+commands.  But these commands will not affect the internal attributes
+of the body unless {reinit} is set to {yes}. With {reinit} set to {no}
+(or using the {infile} option, which implies {reinit} {no}) the position
+and velocity of individual particles in the body will be reset when time
+integration starts again.
+
+:line
+
+Each rigid body must have two or more particles.  A particle can belong
+to at most one rigid body.  Which particles are in which bodies can be
+defined via several options.
+
+For bodystyle {single} the entire fix group of particles is treated as
+one rigid body.
+
+For bodystyle {molecule}, particles are grouped into rigid bodies by their
+respective molecule IDs: each set of particles in the fix group with the
+same molecule ID is treated as a different rigid body.  Note that particles
+with a molecule ID = 0 will be treated as a single rigid body. For a
+system with solvent (typically this is particles with molecule ID = 0)
+surrounding rigid bodies, this may not be what you want.  Thus you
+should be careful to use a fix group that only includes particles you
+want to be part of rigid bodies.
+
+Bodystyle {custom} is similar to bodystyle {molecule} except that it
+is more flexible in using other per-atom properties to define the sets
+of particles that form rigid bodies.  An integer vector defined by the
+"fix property/atom"_fix_property_atom.html command can be used.  Or an
+"atom-style or atomfile-style variable"_variable.html can be used; the
+floating-point value produced by the variable is rounded to an
+integer.  As with bondstyle {molecule}, each set of particles in the fix
+groups with the same integer value is treated as a different rigid
+body.  Since fix property/atom vectors and atom-style variables
+produce values for all particles, you should be careful to use a fix group
+that only includes particles you want to be part of rigid bodies.
+
+For bodystyle {group}, each of the listed groups is treated as a
+separate rigid body.  Only particles that are also in the fix group are
+included in each rigid body.
+
+NOTE: To compute the initial center-of-mass position and other
+properties of each rigid body, the image flags for each particle in the
+body are used to "unwrap" the particle coordinates.  Thus you must
+insure that these image flags are consistent so that the unwrapping
+creates a valid rigid body (one where the particles are close together)
+, particularly if the particles in a single rigid body straddle a
+periodic boundary.  This means the input data file or restart file must
+define the image flags for each particle consistently or that you have
+used the "set"_set.html command to specify them correctly.  If a
+dimension is non-periodic then the image flag of each particle must be
+0 in that dimension, else an error is generated.
+
+By default, each rigid body is acted on by other particles which induce
+an external force and torque on its center of mass, causing it to
+translate and rotate.  Components of the external center-of-mass force
+and torque can be turned off by the {force} and {torque} keywords.
+This may be useful if you wish a body to rotate but not translate, or
+vice versa, or if you wish it to rotate or translate continuously
+unaffected by interactions with other particles.  Note that if you
+expect a rigid body not to move or rotate by using these keywords, you
+must insure its initial center-of-mass translational or angular
+velocity is 0.0. Otherwise the initial translational or angular
+momentum the body has will persist.
+
+An xflag, yflag, or zflag set to {off} means turn off the component of
+force or torque in that dimension.  A setting of {on} means turn on
+the component, which is the default.  Which rigid body(s) the settings
+apply to is determined by the first argument of the {force} and
+{torque} keywords.  It can be an integer M from 1 to Nbody, where
+Nbody is the number of rigid bodies defined.  A wild-card asterisk can
+be used in place of, or in conjunction with, the M argument to set the
+flags for multiple rigid bodies.  This takes the form "*" or "*n" or
+"n*" or "m*n".  If N = the number of rigid bodies, then an asterisk
+with no numeric values means all bodies from 1 to N.  A leading
+asterisk means all bodies from 1 to n (inclusive).  A trailing
+asterisk means all bodies from n to N (inclusive).  A middle asterisk
+means all bodies from m to n (inclusive).  Note that you can use the
+{force} or {torque} keywords as many times as you like.  If a
+particular rigid body has its component flags set multiple times, the
+settings from the final keyword are used.
+
+For computational efficiency, you should typically define one fix
+rigid/meso command which includes all the desired rigid bodies. LAMMPS
+will allow multiple rigid/meso fixes to be defined, but it is more
+expensive.
+
+:line
+
+The keyword/value option pairs are used in the following ways.
+
+The {reinit} keyword determines, whether the rigid body properties
+are re-initialized between run commands. With the option {yes} (the
+default) this is done, with the option {no} this is not done. Turning
+off the re-initialization can be helpful to protect rigid bodies against
+unphysical manipulations between runs or when properties cannot be
+easily re-computed (e.g. when read from a file). When using the {infile}
+keyword, the {reinit} option is automatically set to {no}.
+
+:line
+
+The {infile} keyword allows a file of rigid body attributes to be read
+in from a file, rather then having LAMMPS compute them.  There are 5
+such attributes: the total mass of the rigid body, its center-of-mass
+position, its 6 moments of inertia, its center-of-mass velocity, and
+the 3 image flags of the center-of-mass position.  For rigid bodies
+consisting of point particles or non-overlapping finite-size
+particles, LAMMPS can compute these values accurately.  However, for
+rigid bodies consisting of finite-size particles which overlap each
+other, LAMMPS will ignore the overlaps when computing these 4
+attributes.  The amount of error this induces depends on the amount of
+overlap.  To avoid this issue, the values can be pre-computed
+(e.g. using Monte Carlo integration).
+
+The format of the file is as follows.  Note that the file does not
+have to list attributes for every rigid body integrated by fix rigid.
+Only bodies which the file specifies will have their computed
+attributes overridden.  The file can contain initial blank lines or
+comment lines starting with "#" which are ignored.  The first
+non-blank, non-comment line should list N = the number of lines to
+follow.  The N successive lines contain the following information:
+
+ID1 masstotal xcm ycm zcm ixx iyy izz ixy ixz iyz vxcm vycm vzcm lx ly lz ixcm iycm izcm
+ID2 masstotal xcm ycm zcm ixx iyy izz ixy ixz iyz vxcm vycm vzcm lx ly lz ixcm iycm izcm
+...
+IDN masstotal xcm ycm zcm ixx iyy izz ixy ixz iyz vxcm vycm vzcm lx ly lz ixcm iycm izcm :pre
+
+The rigid body IDs are all positive integers.  For the {single}
+bodystyle, only an ID of 1 can be used.  For the {group} bodystyle,
+IDs from 1 to Ng can be used where Ng is the number of specified
+groups.  For the {molecule} bodystyle, use the molecule ID for the
+atoms in a specific rigid body as the rigid body ID.
+
+The masstotal and center-of-mass coordinates (xcm,ycm,zcm) are
+self-explanatory.  The center-of-mass should be consistent with what
+is calculated for the position of the rigid body with all its atoms
+unwrapped by their respective image flags.  If this produces a
+center-of-mass that is outside the simulation box, LAMMPS wraps it
+back into the box.
+
+The 6 moments of inertia (ixx,iyy,izz,ixy,ixz,iyz) should be the
+values consistent with the current orientation of the rigid body
+around its center of mass.  The values are with respect to the
+simulation box XYZ axes, not with respect to the principal axes of the
+rigid body itself.  LAMMPS performs the latter calculation internally.
+
+The (vxcm,vycm,vzcm) values are the velocity of the center of mass.
+The (lx,ly,lz) values are the angular momentum of the body.  The
+(vxcm,vycm,vzcm) and (lx,ly,lz) values can simply be set to 0 if you
+wish the body to have no initial motion.
+
+The (ixcm,iycm,izcm) values are the image flags of the center of mass
+of the body.  For periodic dimensions, they specify which image of the
+simulation box the body is considered to be in.  An image of 0 means
+it is inside the box as 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 the rigid bodies
+cross periodic boundaries during the simulation.
+
+NOTE: If you use the {infile} keyword and write restart
+files during a simulation, then each time a restart file is written,
+the fix also write an auxiliary restart file with the name
+rfile.rigid, where "rfile" is the name of the restart file,
+e.g. tmp.restart.10000 and tmp.restart.10000.rigid.  This auxiliary
+file is in the same format described above.  Thus it can be used in a
+new input script that restarts the run and re-specifies a rigid fix
+using an {infile} keyword and the appropriate filename.  Note that the
+auxiliary file will contain one line for every rigid body, even if the
+original file only listed a subset of the rigid bodies.
+
+:line
+
+[Restart, fix_modify, output, run start/stop, minimize info:]
+
+No information is written to "binary restart files"_restart.html.
+If the {infile} keyword is used, an auxiliary file is written out
+with rigid body information each time a restart file is written, as
+explained above for the {infile} keyword.
+
+None of the "fix_modify"_fix_modify.html options are relevant to this
+fix.
+
+This fix computes a global array of values which can be accessed by
+various "output commands"_Howto_output.html.
+
+The number of rows in the array is equal to the number of rigid
+bodies.  The number of columns is 28.  Thus for each rigid body, 28
+values are stored: the xyz coords of the center of mass (COM), the xyz
+components of the COM velocity, the xyz components of the force acting
+on the COM, the components of the 4-vector quaternion representing the
+orientation of the rigid body, the xyz components of the angular momentum
+of the body around its COM, the xyz components of the torque acting on the
+COM, the 3 principal components of the moment of inertia and the xyz image
+flags of the COM.
+
+The center of mass (COM) for each body is similar to unwrapped
+coordinates written to a dump file.  It will always be inside (or
+slightly outside) the simulation box.  The image flags have the same
+meaning as image flags for particle positions (see the "dump" command).
+This means you can calculate the unwrapped COM by applying the image
+flags to the COM, the same as when unwrapped coordinates are written
+to a dump file.
+
+The force and torque values in the array are not affected by the
+{force} and {torque} keywords in the fix rigid command; they reflect
+values before any changes are made by those keywords.
+
+The ordering of the rigid bodies (by row in the array) is as follows.
+For the {single} keyword there is just one rigid body.  For the
+{molecule} keyword, the bodies are ordered by ascending molecule ID.
+For the {group} keyword, the list of group IDs determines the ordering
+of bodies.
+
+The array values calculated by this fix are "intensive", meaning they
+are independent of the number of particles in the simulation.
+
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command.
+
+This fix is not invoked during "energy minimization"_minimize.html.
+
+:line
+
+[Restrictions:]
+
+This fix is part of the USER-SDPD package and also depends on the RIGID
+package.  It is only enabled if LAMMPS was built with both packages. See
+the "Build package"_Build_package.html doc page for more info.
+
+This fix requires that atoms store density and internal energy as
+defined by the "atom_style meso"_atom_style.html command.
+
+All particles in the group must be mesoscopic SPH/SDPD particles.
+
+[Related commands:]
+
+"fix meso/move"_fix_meso_move.html, "fix rigid"_fix_rigid.html,
+"neigh_modify exclude"_neigh_modify.html
+
+[Default:]
+
+The option defaults are force * on on on and torque * on on on,
+meaning all rigid bodies are acted on by center-of-mass force and
+torque. Also reinit = yes.
+
+:line
+
+:link(Miller)
+[(Miller)] Miller, Eleftheriou, Pattnaik, Ndirango, and Newns, 
+J Chem Phys, 116, 8649 (2002).