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

update version number for next patch release

.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
@@ -29,19 +30,86 @@ src/USER-MOFFF/*      @hheenen
 src/USER-MOLFILE/*    @akohlmey
 src/USER-NETCDF/*     @pastewka
 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

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})
 
@@ -136,6 +136,7 @@ if(BUILD_EXE)
   if(LAMMPS_MACHINE)
     set(LAMMPS_MACHINE "_${LAMMPS_MACHINE}")
   endif()
+  set(LAMMPS_BINARY lmp${LAMMPS_MACHINE})
 endif()
 
 option(BUILD_LIB "Build LAMMPS library" OFF)
@@ -162,6 +163,35 @@ set(LAMMPS_LINK_LIBS)
 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-PTM USER-QTB USER-REAXC USER-SCAFACOS 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})
+  option(PKG_${PKG} "Build ${PKG} Package" OFF)
+endforeach()
+foreach(PKG ${ACCEL_PACKAGES} ${OTHER_PACKAGES})
+  option(PKG_${PKG} "Build ${PKG} Package" OFF)
+endforeach()
+
+######################################################
+# packages with special compiler needs or external libs
+######################################################
+if(PKG_REAX OR PKG_MEAM OR PKG_USER-QUIP OR PKG_USER-QMMM OR PKG_LATTE OR PKG_USER-SCAFACOS)
+  enable_language(Fortran)
+endif()
+
+if(PKG_MEAM OR PKG_USER-H5MD OR PKG_USER-QMMM OR PKG_USER-SCAFACOS)
+  enable_language(C)
+endif()
+
+# 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})
 if(BUILD_MPI)
@@ -206,25 +236,52 @@ endif()
 option(CMAKE_VERBOSE_MAKEFILE "Verbose makefile" OFF)
 
 option(ENABLE_TESTING "Enable testing" OFF)
-if(ENABLE_TESTING)
+if(ENABLE_TESTING AND BUILD_EXE)
   enable_testing()
-endif(ENABLE_TESTING)
+  option(LAMMPS_TESTING_SOURCE_DIR "Location of lammps-testing source directory" "")
+  option(LAMMPS_TESTING_GIT_TAG    "Git tag of lammps-testing" "master")
+  mark_as_advanced(LAMMPS_TESTING_SOURCE_DIR LAMMPS_TESTING_GIT_TAG)
 
-set(DEFAULT_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS DIPOLE GRANULAR
-  KSPACE MANYBODY MC MEAM 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-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})
-  option(PKG_${PKG} "Build ${PKG} Package" OFF)
-endforeach()
-foreach(PKG ${ACCEL_PACKAGES} ${OTHER_PACKAGES})
-  option(PKG_${PKG} "Build ${PKG} Package" OFF)
-endforeach()
+  if (CMAKE_VERSION VERSION_GREATER "3.10.3" AND NOT LAMMPS_TESTING_SOURCE_DIR)
+    include(FetchContent)
+
+    FetchContent_Declare(lammps-testing
+      GIT_REPOSITORY https://github.com/lammps/lammps-testing.git
+      GIT_TAG ${LAMMPS_TESTING_GIT_TAG}
+    )
+
+    FetchContent_GetProperties(lammps-testing)
+    if(NOT lammps-testing_POPULATED)
+      message(STATUS "Downloading tests...")
+      FetchContent_Populate(lammps-testing)
+    endif()
+
+    set(LAMMPS_TESTING_SOURCE_DIR ${lammps-testing_SOURCE_DIR})
+  elseif(NOT LAMMPS_TESTING_SOURCE_DIR)
+    message(WARNING "Full test-suite requires CMake >= 3.11 or copy of\n"
+                    "https://github.com/lammps/lammps-testing in LAMMPS_TESTING_SOURCE_DIR")
+  endif()
+
+  if(EXISTS ${LAMMPS_TESTING_SOURCE_DIR})
+    message(STATUS "Running test discovery...")
+
+    file(GLOB_RECURSE TEST_SCRIPTS ${LAMMPS_TESTING_SOURCE_DIR}/tests/core/*/in.*)
+    foreach(script_path ${TEST_SCRIPTS})
+      get_filename_component(TEST_NAME ${script_path} EXT)
+      get_filename_component(SCRIPT_NAME ${script_path} NAME)
+      get_filename_component(PARENT_DIR ${script_path} DIRECTORY)
+      string(SUBSTRING ${TEST_NAME} 1 -1 TEST_NAME)
+      string(REPLACE "-" "_" TEST_NAME ${TEST_NAME})
+      string(REPLACE "+" "_" TEST_NAME ${TEST_NAME})
+      set(TEST_NAME "test_core_${TEST_NAME}_serial")
+      add_test(${TEST_NAME} ${CMAKE_BINARY_DIR}/${LAMMPS_BINARY} -in ${SCRIPT_NAME})
+      set_tests_properties(${TEST_NAME} PROPERTIES WORKING_DIRECTORY ${PARENT_DIR})
+    endforeach()
+    list(LENGTH TEST_SCRIPTS NUM_TESTS)
+
+    message(STATUS "Found ${NUM_TESTS} tests.")
+  endif()
+endif()
 
 macro(pkg_depends PKG1 PKG2)
   if(PKG_${PKG1} AND NOT (PKG_${PKG2} OR BUILD_${PKG2}))
@@ -238,17 +295,7 @@ pkg_depends(MPIIO MPI)
 pkg_depends(USER-ATC MANYBODY)
 pkg_depends(USER-LB MPI)
 pkg_depends(USER-PHONON KSPACE)
-
-######################################################
-# packages with special compiler needs or external libs
-######################################################
-if(PKG_REAX OR PKG_MEAM OR PKG_USER-QUIP OR PKG_USER-QMMM OR PKG_LATTE)
-  enable_language(Fortran)
-endif()
-
-if(PKG_MEAM OR PKG_USER-H5MD OR PKG_USER-QMMM)
-  enable_language(C)
-endif()
+pkg_depends(USER-SCAFACOS MPI)
 
 find_package(OpenMP QUIET)
 option(BUILD_OMP "Build with OpenMP support" ${OpenMP_FOUND})
@@ -302,7 +349,7 @@ if(PKG_MSCG OR PKG_USER-ATC OR PKG_USER-AWPMD OR PKG_USER-QUIP OR PKG_LATTE)
   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()
@@ -426,6 +473,57 @@ if(PKG_LATTE)
   list(APPEND LAMMPS_LINK_LIBS ${LATTE_LIBRARIES} ${LAPACK_LIBRARIES})
 endif()
 
+if(PKG_USER-SCAFACOS)
+  find_package(GSL REQUIRED)
+  option(DOWNLOAD_SCAFACOS "Download ScaFaCoS (instead of using the system's one)" OFF)
+  if(DOWNLOAD_SCAFACOS)
+    include(ExternalProject)
+    ExternalProject_Add(scafacos_build
+      URL https://github.com/scafacos/scafacos/releases/download/v1.0.1/scafacos-1.0.1.tar.gz
+      URL_MD5 bd46d74e3296bd8a444d731bb10c1738
+      CONFIGURE_COMMAND <SOURCE_DIR>/configure --prefix=<INSTALL_DIR> 
+                                               --disable-doc 
+                                               --enable-fcs-solvers=fmm,p2nfft,direct,ewald,p3m
+                                               --with-internal-fftw
+                                               --with-internal-pfft
+                                               --with-internal-pnfft
+                                               $<$<BOOL:${BUILD_SHARED_LIBS}>:--with-pic>                                               
+                                               FC=${CMAKE_MPI_Fortran_COMPILER} 
+                                               CXX=${CMAKE_MPI_CXX_COMPILER} 
+                                               CC=${CMAKE_MPI_C_COMPILER}
+                                               F77=
+      )
+    ExternalProject_get_property(scafacos_build INSTALL_DIR)
+    set(SCAFACOS_BUILD_DIR ${INSTALL_DIR})
+    set(SCAFACOS_INCLUDE_DIRS ${SCAFACOS_BUILD_DIR}/include)
+    list(APPEND LAMMPS_DEPS scafacos_build)
+    # list and order from pkg_config file of ScaFaCoS build
+    list(APPEND LAMMPS_LINK_LIBS ${SCAFACOS_BUILD_DIR}/lib/libfcs.a)
+    list(APPEND LAMMPS_LINK_LIBS ${SCAFACOS_BUILD_DIR}/lib/libfcs_direct.a)
+    list(APPEND LAMMPS_LINK_LIBS ${SCAFACOS_BUILD_DIR}/lib/libfcs_ewald.a)
+    list(APPEND LAMMPS_LINK_LIBS ${SCAFACOS_BUILD_DIR}/lib/libfcs_fmm.a)
+    list(APPEND LAMMPS_LINK_LIBS ${SCAFACOS_BUILD_DIR}/lib/libfcs_p2nfft.a)
+    list(APPEND LAMMPS_LINK_LIBS ${SCAFACOS_BUILD_DIR}/lib/libfcs_p3m.a)
+    list(APPEND LAMMPS_LINK_LIBS ${GSL_LIBRARIES})
+    list(APPEND LAMMPS_LINK_LIBS ${SCAFACOS_BUILD_DIR}/lib/libfcs_near.a)
+    list(APPEND LAMMPS_LINK_LIBS ${SCAFACOS_BUILD_DIR}/lib/libfcs_gridsort.a)
+    list(APPEND LAMMPS_LINK_LIBS ${SCAFACOS_BUILD_DIR}/lib/libfcs_resort.a)
+    list(APPEND LAMMPS_LINK_LIBS ${SCAFACOS_BUILD_DIR}/lib/libfcs_redist.a)
+    list(APPEND LAMMPS_LINK_LIBS ${SCAFACOS_BUILD_DIR}/lib/libfcs_common.a)
+    list(APPEND LAMMPS_LINK_LIBS ${SCAFACOS_BUILD_DIR}/lib/libfcs_pnfft.a)
+    list(APPEND LAMMPS_LINK_LIBS ${SCAFACOS_BUILD_DIR}/lib/libfcs_pfft.a)
+    list(APPEND LAMMPS_LINK_LIBS ${SCAFACOS_BUILD_DIR}/lib/libfcs_fftw3_mpi.a)
+    list(APPEND LAMMPS_LINK_LIBS ${SCAFACOS_BUILD_DIR}/lib/libfcs_fftw3.a)
+    list(APPEND LAMMPS_LINK_LIBS ${MPI_Fortran_LIBRARIES})
+    list(APPEND LAMMPS_LINK_LIBS ${MPI_C_LIBRARIES})
+  else()
+    FIND_PACKAGE(PkgConfig REQUIRED)
+    PKG_CHECK_MODULES(SCAFACOS scafacos REQUIRED)
+    list(APPEND LAMMPS_LINK_LIBS ${SCAFACOS_LDFLAGS})
+  endif()
+  include_directories(${SCAFACOS_INCLUDE_DIRS})
+endif()
+
 if(PKG_USER-MOLFILE)
   add_library(molfile INTERFACE)
   target_include_directories(molfile INTERFACE ${LAMMPS_LIB_SOURCE_DIR}/molfile)
@@ -435,8 +533,8 @@ endif()
 
 if(PKG_USER-NETCDF)
   find_package(NetCDF REQUIRED)
-  include_directories(NETCDF_INCLUDE_DIR)
-  list(APPEND LAMMPS_LINK_LIBS ${NETCDF_LIBRARY})
+  include_directories(${NETCDF_INCLUDE_DIRS})
+  list(APPEND LAMMPS_LINK_LIBS ${NETCDF_LIBRARIES})
   add_definitions(-DLMP_HAS_NETCDF -DNC_64BIT_DATA=0x0020)
 endif()
 
@@ -453,8 +551,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()
@@ -504,6 +603,40 @@ if(PKG_KIM)
   include_directories(${KIM_INCLUDE_DIRS})
 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)
+
+  if(BUILD_SHARED_LIBS)
+      add_library(cslib SHARED ${cslib_SOURCES})
+  else()
+      add_library(cslib STATIC ${cslib_SOURCES})
+  endif()
+
+  if(BUILD_MPI)
+    target_compile_definitions(cslib PRIVATE -DMPI_YES)
+    set_target_properties(cslib PROPERTIES OUTPUT_NAME "csmpi")
+  else()
+    target_compile_definitions(cslib PRIVATE -DMPI_NO)
+    set_target_properties(cslib PROPERTIES OUTPUT_NAME "csnompi")
+  endif()
+
+  if(MESSAGE_ZMQ)
+    target_compile_definitions(cslib PRIVATE -DZMQ_YES)
+    find_package(ZMQ REQUIRED)
+    target_include_directories(cslib PRIVATE ${ZMQ_INCLUDE_DIRS})
+    target_link_libraries(cslib PUBLIC ${ZMQ_LIBRARIES})
+  else()
+    target_compile_definitions(cslib PRIVATE -DZMQ_NO)
+    target_include_directories(cslib PRIVATE ${LAMMPS_LIB_SOURCE_DIR}/message/cslib/src/STUBS_ZMQ)
+  endif()
+
+  list(APPEND LAMMPS_LINK_LIBS cslib)
+  include_directories(${LAMMPS_LIB_SOURCE_DIR}/message/cslib/src)
+endif()
+
 if(PKG_MSCG)
   find_package(GSL REQUIRED)
   option(DOWNLOAD_MSCG "Download latte (instead of using the system's one)" OFF)
@@ -590,8 +723,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})
@@ -609,8 +742,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})
@@ -624,8 +757,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)
@@ -700,6 +835,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)
@@ -708,7 +844,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)
 
@@ -908,7 +1044,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")
@@ -921,15 +1057,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
@@ -978,7 +1114,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})
@@ -1086,11 +1222,11 @@ if(BUILD_EXE)
     endif()
   endif()
   
-  set_target_properties(lmp PROPERTIES OUTPUT_NAME lmp${LAMMPS_MACHINE})
+  set_target_properties(lmp PROPERTIES OUTPUT_NAME ${LAMMPS_BINARY})
   install(TARGETS lmp DESTINATION ${CMAKE_INSTALL_BINDIR})
-  install(FILES ${LAMMPS_DOC_DIR}/lammps.1 DESTINATION ${CMAKE_INSTALL_MANDIR}/man1 RENAME lmp${LAMMPS_MACHINE}.1)
+  install(FILES ${LAMMPS_DOC_DIR}/lammps.1 DESTINATION ${CMAKE_INSTALL_MANDIR}/man1 RENAME ${LAMMPS_BINARY}.1)
   if(ENABLE_TESTING)
-    add_test(ShowHelp lmp${LAMMPS_MACHINE} -help)
+    add_test(ShowHelp ${LAMMPS_BINARY} -help)
   endif()
 endif()
 
@@ -1105,7 +1241,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})
 
@@ -1200,7 +1336,7 @@ endif()
 ###############################################################################
 # Print package summary
 ###############################################################################
-foreach(PKG ${DEFAULT_PACKAGES} ${ACCEL_PACKAGES})
+foreach(PKG ${DEFAULT_PACKAGES} ${ACCEL_PACKAGES} ${OTHER_PACKAGES})
   if(PKG_${PKG})
     message(STATUS "Building package: ${PKG}")
   endif()

cmake/Modules/FindZMQ.cmake

@@ -0,0 +1,8 @@
+find_path(ZMQ_INCLUDE_DIR zmq.h)
+find_library(ZMQ_LIBRARY NAMES zmq)
+
+set(ZMQ_LIBRARIES ${ZMQ_LIBRARY})
+set(ZMQ_INCLUDE_DIRS ${ZMQ_INCLUDE_DIR})
+
+include(FindPackageHandleStandardArgs)
+find_package_handle_standard_args(ZMQ DEFAULT_MSG ZMQ_LIBRARY ZMQ_INCLUDE_DIR)

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/pkgconfig/liblammps.pc.in

@@ -11,7 +11,7 @@ includedir=@CMAKE_INSTALL_FULL_INCLUDEDIR@
 Name: liblammps@LAMMPS_MACHINE@
 Description: Large-scale Atomic/Molecular Massively Parallel Simulator Library
 URL: http://lammps.sandia.gov
-Version:
+Version: @LAMMPS_VERSION@
 Requires:
 Libs: -L${libdir} -llammps@LAMMPS_LIB_SUFFIX@
 Libs.private: -lm

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"
@@ -116,17 +116,17 @@ mobi: epub
 pdf: utils/txt2html/txt2html.exe
 	@(\
 		set -e; \
-		cd src; \
+		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,\.txt,\.html,g'` ; \
 			do grep -q $$s lammps.book || \
 			echo doc file $$s missing in src/lammps.book; done; \
 		rm *.html; \
-		cd Developer; \
-		pdflatex developer; \
-		pdflatex developer; \
-		mv developer.pdf ../../Developer.pdf; \
 	)
 
 old: utils/txt2html/txt2html.exe

doc/src/Build_basics.txt

@@ -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

@@ -31,6 +31,7 @@ This is the list of packages that may require additional steps.
 "KOKKOS"_#kokkos,
 "LATTE"_#latte,
 "MEAM"_#meam,
+"MESSAGE"_#message,
 "MSCG"_#mscg,
 "OPT"_#opt,
 "POEMS"_#poems,
@@ -47,6 +48,7 @@ This is the list of packages that may require additional steps.
 "USER-OMP"_#user-omp,
 "USER-QMMM"_#user-qmmm,
 "USER-QUIP"_#user-quip,
+"USER-SCAFACOS"_#user-scafacos,
 "USER-SMD"_#user-smd,
 "USER-VTK"_#user-vtk :tb(c=6,ea=c,a=l)
 
@@ -361,6 +363,10 @@ make lib-meam args="-m mpi"    # build with default Fortran compiler compatible
 make lib-meam args="-m serial" # build with compiler compatible with "make serial" (GNU Fortran)
 make lib-meam args="-m ifort"  # build with Intel Fortran compiler using Makefile.ifort :pre
 
+NOTE: You should test building the MEAM library with both the Intel
+and GNU compilers to see if a simulation runs faster with one versus
+the other on your system.
+
 The build should produce two files: lib/meam/libmeam.a and
 lib/meam/Makefile.lammps.  The latter is copied from an existing
 Makefile.lammps.* and has settings needed to link C++ (LAMMPS) with
@@ -373,6 +379,35 @@ file.
 
 :line
  
+MESSAGE package :h4,link(message)
+
+This package can optionally include support for messaging via sockets,
+using the open-source "ZeroMQ library"_http://zeromq.org, which must
+be installed on your system.
+
+[CMake build]:
+
+-D MESSAGE_ZMQ=value    # build with ZeroMQ support, value = no (default) or yes
+
+[Traditional make]:
+
+Before building LAMMPS, you must build the CSlib library in
+lib/message.  You can build the CSlib library manually if you prefer;
+follow the instructions in lib/message/README.  You can also do it in
+one step from the lammps/src dir, using a command like these, which
+simply invoke the lib/message/Install.py script with the specified args:
+
+make lib-message               # print help message
+make lib-message args="-m -z"  # build with MPI and socket (ZMQ) support
+make lib-message args="-s"     # build as serial lib with no ZMQ support
+
+The build should produce two files: lib/message/cslib/src/libmessage.a
+and lib/message/Makefile.lammps.  The latter is copied from an
+existing Makefile.lammps.* and has settings to link with the ZeroMQ
+library if requested in the build.
+
+:line
+ 
 MSCG package :h4,link(mscg)
 
 To build with this package, you must download and build the MS-CG
@@ -894,6 +929,45 @@ successfully build on your system.
 
 :line
 
+USER-SCAFACOS package :h4,link(user-scafacos)
+
+To build with this package, you must download and build the "ScaFaCoS
+Coulomb solver library"_scafacos_home
+
+:link(scafacos_home,http://www.scafacos.de)
+
+[CMake build]:
+
+-D DOWNLOAD_SCAFACOS=value    # download ScaFaCoS for build, value = no (default) or yes
+-D SCAFACOS_LIBRARY=path      # ScaFaCos library file (only needed if at custom location) 
+-D SCAFACOS_INCLUDE_DIR=path  # ScaFaCoS include directory (only needed if at custom location) :pre
+
+If DOWNLOAD_SCAFACOS is set, the ScaFaCoS library will be downloaded
+and built inside the CMake build directory.  If the ScaFaCoS library
+is already on your system (in a location CMake cannot find it),
+SCAFACOS_LIBRARY is the filename (plus path) of the ScaFaCoS library
+file, not the directory the library file is in.  SCAFACOS_INCLUDE_DIR
+is the directory the ScaFaCoS include file is in.
+
+[Traditional make]:
+
+You can download and build the ScaFaCoS library manually if you
+prefer; follow the instructions in lib/scafacos/README.  You can also
+do it in one step from the lammps/src dir, using a command like these,
+which simply invoke the lib/scafacos/Install.py script with the
+specified args:
+
+make lib-scafacos                         # print help message
+make lib-scafacos args="-b"               # download and build in lib/scafacos/scafacos-<version>
+make lib-scafacos args="-p $HOME/scafacos  # use existing ScaFaCoS installation in $HOME/scafacos
+
+Note that 2 symbolic (soft) links, "includelink" and "liblink", are
+created in lib/scafacos to point to the ScaFaCoS src dir.  When LAMMPS
+builds in src it will use these links.  You should not need to edit
+the lib/scafacos/Makefile.lammps file.
+
+:line
+
 USER-SMD package :h4,link(user-smd)
 
 To build with this package, you must download the Eigen3 library.

doc/src/Build_package.txt

@@ -42,6 +42,7 @@ packages:
 "KOKKOS"_Build_extras.html#kokkos,
 "LATTE"_Build_extras.html#latte,
 "MEAM"_Build_extras.html#meam,
+"MESSAGE"_Build_extras.html#message,
 "MSCG"_Build_extras.html#mscg,
 "OPT"_Build_extras.html#opt,
 "POEMS"_Build_extras.html#poems,
@@ -58,6 +59,7 @@ packages:
 "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-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

@@ -71,6 +71,7 @@ An alphabetic list of all LAMMPS commands.
 "lattice"_lattice.html,
 "log"_log.html,
 "mass"_mass.html,
+"message"_message.html,
 "minimize"_minimize.html,
 "min_modify"_min_modify.html,
 "min_style"_min_style.html,
@@ -103,6 +104,7 @@ An alphabetic list of all LAMMPS commands.
 "restart"_restart.html,
 "run"_run.html,
 "run_style"_run_style.html,
+"server"_server.html,
 "set"_set.html,
 "shell"_shell.html,
 "special_bonds"_special_bonds.html,

doc/src/Commands_bond.txt

@@ -70,7 +70,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

doc/src/Commands_compute.txt

@@ -35,6 +35,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,
@@ -95,8 +96,10 @@ KOKKOS, o = USER-OMP, t = OPT.
 "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 +118,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/mesh/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,

doc/src/Commands_fix.txt

@@ -65,6 +65,7 @@ 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,
@@ -216,7 +217,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_kspace.txt

@@ -33,4 +33,5 @@ OPT.
 "pppm/disp (i)"_kspace_style.html,
 "pppm/disp/tip4p"_kspace_style.html,
 "pppm/stagger"_kspace_style.html,
-"pppm/tip4p (o)"_kspace_style.html :tb(c=4,ea=c)
+"pppm/tip4p (o)"_kspace_style.html,
+"scafacos"_kspace_style.html :tb(c=4,ea=c)

doc/src/Commands_pair.txt

@@ -26,7 +26,7 @@ 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,
@@ -81,6 +81,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,
@@ -167,7 +168,7 @@ OPT.
 "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,

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.txt

@@ -54,6 +54,7 @@ General howto :h3
    Howto_replica
    Howto_library
    Howto_couple
+   Howto_client_server
 
 END_RST -->
 
@@ -64,7 +65,8 @@ END_RST -->
 "Run multiple simulations from one input script"_Howto_multiple.html
 "Multi-replica simulations"_Howto_replica.html
 "Library interface to LAMMPS"_Howto_library.html
-"Couple LAMMPS to other codes"_Howto_couple.html :all(b)
+"Couple LAMMPS to other codes"_Howto_couple.html
+"Using LAMMPS in client/server mode"_Howto_client_server.html :all(b)
 
 <!-- END_HTML_ONLY -->
 

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

@@ -0,0 +1,131 @@
+"Higher level section"_Howto.html - "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
+
+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
+each request with a reply message.  This enables the two codes to work
+in tandem to perform a simulation.  LAMMPS can act as either a client
+or server code.
+
+Some advantages of client/server coupling are that the two codes run
+as stand-alone executables; they are not linked together.  Thus
+neither code needs to have a library interface.  This often makes it
+easier to run the two codes on different numbers of processors.  If a
+message protocol (format and content) is defined for a particular kind
+of simulation, then in principle any code that implements the
+client-side protocol can be used in tandem with any code that
+implements the server-side protocol, without the two codes needing to
+know anything more specific about each other.
+
+A simple example of client/server coupling is where LAMMPS is the
+client code performing MD timestepping.  Each timestep it sends a
+message to a server quantum code containing current coords of all the
+atoms.  The quantum code computes energy and forces based on the
+coords.  It returns them as a message to LAMMPS, which completes the
+timestep.
+
+Alternate methods for code coupling with LAMMPS are described on
+the "Howto couple"_Howto_couple.html doc page.
+
+LAMMPS support for client/server coupling is in its "MESSAGE
+package"_Packages_details.html#PKG-MESSAGE which implements several
+commands that enable LAMMPS to act as a client or server, as discussed
+below.  The MESSAGE package also wraps a client/server library called
+CSlib which enables two codes to exchange messages in different ways,
+either via files, sockets, or MPI.  The CSlib is provided with LAMMPS
+in the lib/message dir.  The CSlib has its own
+"website"_http://cslib.sandia.gov with documentation and test
+programs.
+
+NOTE: For client/server coupling to work between LAMMPS and another
+code, the other code also has to use the CSlib.  This can sometimes be
+done without any modifications to the other code by simply wrapping it
+with a Python script that exchanges CSlib messages with LAMMPS and
+prepares input for or processes output from the other code.  The other
+code also has to implement a matching protocol for the format and
+content of messages that LAMMPS exchanges with it.
+
+These are the commands currently in the MESSAGE package for two
+protocols, MD and MC (Monte Carlo).  New protocols can easily be
+defined and added to this directory, where LAMMPS acts as either the
+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 :ul
+
+The server doc files give details of the message protocols
+for data that is exchanged bewteen the client and server.
+
+These example directories illustrate how to use LAMMPS as either a
+client or server code:
+
+examples/message
+examples/COUPLE/README
+examples/COUPLE/lammps_mc
+examples/COUPLE/lammps_vasp :ul
+
+The examples/message dir couples a client instance of LAMMPS to a
+server instance of LAMMPS.  
+
+The lammps_mc dir shows how to couple LAMMPS as a server to a simple
+Monte Carlo client code as the driver.
+
+The lammps_vasp dir shows how to couple LAMMPS as a client code
+running MD timestepping to VASP acting as a server providing quantum
+DFT forces, thru a Python wrapper script on VASP.
+
+Here is how to launch a client and server code together for any of the
+4 modes of message exchange that the "message"_message.html command
+and the CSlib support.  Here LAMMPS is used as both the client and
+server code.  Another code could be subsitituted for either.
+
+The examples below show launching both codes from the same window (or
+batch script), using the "&" character to launch the first code in the
+background.  For all modes except {mpi/one}, you could also launch the
+codes in separate windows on your desktop machine.  It does not
+matter whether you launch the client or server first.
+
+In these examples either code can be run on one or more processors.
+If running in a non-MPI mode (file or zmq) you can launch a code on a
+single processor without using mpirun.
+
+IMPORTANT: If you run in mpi/two mode, you must launch both codes via
+mpirun, even if one or both of them runs on a single processor.  This
+is so that MPI can figure out how to connect both MPI processes
+together to exchange MPI messages between them.
+
+For message exchange in {file}, {zmq}, or {mpi/two} modes:
+
+% mpirun -np 1 lmp_mpi -log log.client < in.client & 
+% mpirun -np 2 lmp_mpi -log log.server < in.server :pre
+
+% mpirun -np 4 lmp_mpi -log log.client < in.client & 
+% mpirun -np 1 lmp_mpi -log log.server < in.server :pre
+
+% mpirun -np 2 lmp_mpi -log log.client < in.client & 
+% mpirun -np 4 lmp_mpi -log log.server < in.server :pre
+
+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 :pre
+
+The two -np values determine how many procs the client and the server
+run on.
+
+A LAMMPS executable run in this manner must use the -mpicolor color
+command-line option as their its option, where color is an integer
+label that will be used to distinguish one executable from another in
+the multiple executables that the mpirun command launches.  In this
+example the client was colored with a 0, and the server with a 1.

doc/src/Howto_couple.txt

@@ -16,10 +16,12 @@ atoms and pass those forces to LAMMPS.  Or a continuum finite element
 nodal points, compute a FE solution, and return interpolated forces on
 MD atoms.
 
-LAMMPS can be coupled to other codes in at least 3 ways.  Each has
+LAMMPS can be coupled to other codes in at least 4 ways.  Each has
 advantages and disadvantages, which you'll have to think about in the
 context of your application.
 
+:line
+
 (1) Define a new "fix"_fix.html command that calls the other code.  In
 this scenario, LAMMPS is the driver code.  During its timestepping,
 the fix is invoked, and can make library calls to the other code,
@@ -32,6 +34,8 @@ LAMMPS.
 
 :link(poems,http://www.rpi.edu/~anderk5/lab)
 
+:line
+
 (2) Define a new LAMMPS command that calls the other code.  This is
 conceptually similar to method (1), but in this case LAMMPS and the
 other code are on a more equal footing.  Note that now the other code
@@ -52,6 +56,8 @@ command writes and reads.
 See the "Modify command"_Modify_command.html doc page for info on how
 to add a new command to LAMMPS.
 
+:line
+
 (3) Use LAMMPS as a library called by another code.  In this case the
 other code is the driver and calls LAMMPS as needed.  Or a wrapper
 code could link and call both LAMMPS and another code as libraries.
@@ -102,3 +108,9 @@ on all the processors.  Or it might allocate half the processors to
 LAMMPS and half to the other code and run both codes simultaneously
 before syncing them up periodically.  Or it might instantiate multiple
 instances of LAMMPS to perform different calculations.
+
+:line
+
+(4) Couple LAMMPS with another code in a client/server mode.  This is
+described on the "Howto client/server"_Howto_client_server.html doc
+page.

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_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="31 Aug 2018 version">
+<META NAME="docnumber" CONTENT="10 Oct 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
-31 Aug 2018 version :c,h2
+10 Oct 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,10 +89,12 @@ as contained in the file name.
 "USER-NETCDF"_#PKG-USER-NETCDF,
 "USER-OMP"_#PKG-USER-OMP,
 "USER-PHONON"_#PKG-USER-PHONON,
+"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"_#PKG-USER-SCAFACOS,
 "USER-SMD"_#PKG-USER-SMD,
 "USER-SMTBQ"_#PKG-USER-SMTBQ,
 "USER-SPH"_#PKG-USER-SPH,
@@ -549,10 +552,6 @@ This package has "specific installation
 instructions"_Build_extras.html#gpu on the "Build
 extras"_Build_extras.html doc page.
 
-NOTE: You should test building the MEAM library with both the Intel
-and GNU compilers to see if a simulation runs faster with one versus
-the other on your system.
-
 [Supporting info:]
 
 src/MEAM: filenames -> commands
@@ -563,6 +562,31 @@ examples/meam :ul
 
 :line
 
+MESSAGE package :link(PKG-MESSAGE),h4
+
+[Contents:]
+
+Commands to use LAMMPS as either a client or server and couple it to
+another application.
+
+[Install:]
+
+This package has "specific installation
+instructions"_Build_extras.html#message on the "Build
+extras"_Build_extras.html doc page.
+
+[Supporting info:]
+
+src/MESSAGE: filenames -> commands
+lib/message/README
+"message"_message.html
+"fix client/md"_fix_client_md.html
+"server md"_server_md.html
+"server mc"_server_mc.html
+examples/message :ul
+
+:line
+
 MISC package :link(PKG-MISC),h4
 
 [Contents:]
@@ -1721,6 +1745,24 @@ 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: filename starting with ptm_ -> supporting code, other filenames -> commands
+src/USER-PTM/LICENSE
+"compute ptm/atom"_compute_ptm_atom.html :ul
+
+:line
+
 USER-QMMM package :link(PKG-USER-QMMM),h4
 
 [Contents:]
@@ -1838,6 +1880,41 @@ examples/reax :ul
 
 :line
 
+USER-SCAFACOS package :link(PKG-USER-SCAFACOS),h4
+
+[Contents:]
+
+A KSpace style which wraps the "ScaFaCoS Coulomb solver
+library"_http://www.scafacos.de to compute long-range Coulombic
+interactions.
+
+To use this package you must have the ScaFaCoS library available on
+your system.
+
+[Author:] Rene Halver (JSC) wrote the scafacos LAMMPS command.
+
+ScaFaCoS itself was developed by a consortium of German research
+facilities with a BMBF (German Ministry of Science and Education)
+funded project in 2009-2012. Participants of the consortium were the
+Universities of Bonn, Chemnitz, Stuttgart, and Wuppertal as well as
+the Forschungszentrum Juelich.
+
+[Install:]
+
+This package has "specific installation
+instructions"_Build_extras.html#user-scafacos on the "Build
+extras"_Build_extras.html doc page.
+
+[Supporting info:]
+
+src/USER-SCAFACOS: filenames -> commands
+src/USER-SCAFACOS/README
+"kspace_style scafacos"_kspace_style.html
+"kspace_modify"_kspace_modify.html
+examples/USER/scafacos :ul
+
+:line
+
 USER-SMD package :link(PKG-USER-SMD),h4
 
 [Contents:]

doc/src/Packages_standard.txt

@@ -47,6 +47,7 @@ Package, Description, Doc page, Example, Library
 "MANYBODY"_Packages_details.html#PKG-MANYBODY, many-body potentials, "pair_style tersoff"_pair_tersoff.html, shear, no
 "MC"_Packages_details.html#PKG-MC, Monte Carlo options, "fix gcmc"_fix_gcmc.html, n/a, no
 "MEAM"_Packages_details.html#PKG-MEAM, modified EAM potential, "pair_style meam"_pair_meam.html, meam, int
+"MESSAGE"_Packages_details.html#PKG-MESSAGE, client/server messaging, "message"_message.html, message, int
 "MISC"_Packages_details.html#PKG-MISC, miscellaneous single-file commands, n/a, no, no
 "MOLECULE"_Packages_details.html#PKG-MOLECULE, molecular system force fields, "Howto bioFF"_Howto_bioFF.html, peptide, no
 "MPIIO"_Packages_details.html#PKG-MPIIO, MPI parallel I/O dump and restart, "dump"_dump.html, n/a, no

doc/src/Packages_user.txt

@@ -62,10 +62,12 @@ 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-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-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

doc/src/Run_options.txt

@@ -18,6 +18,7 @@ letter abbreviation can be used:
 "-i or -in"_#file
 "-k or -kokkos"_#run-kokkos
 "-l or -log"_#log
+"-m or -mpicolor"_#mpicolor
 "-nc or -nocite"_#nocite
 "-pk or -package"_#package
 "-p or -partition"_#partition
@@ -175,6 +176,30 @@ Option -plog will override the name of the partition log files file.N.
 
 :line
 
+[-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
+command which also launches another executable(s) at the same time.
+(The other executable could be LAMMPS as well.)  The color is an
+integer value which should be different for each executable (another
+application may set this value in a different way).  LAMMPS and the
+other executable(s) perform an MPI_Comm_split() with their own colors
+to shrink the MPI_COMM_WORLD communication to be the subset of
+processors they are actually running on.
+
+Currently, this is only used in LAMMPS to perform client/server
+messaging with another application.  LAMMPS can act as either a client
+or server (or both).  More details are given on the "Howto
+client/server"_Howto_client_server.html doc page.
+
+Specifically, this refers to the "mpi/one" mode of messaging provided
+by the "message"_message.html command and the CSlib library LAMMPS
+links with from the lib/message directory.  See the
+"message"_message.html command for more details.
+
+:line
+
 [-nocite] :link(nocite)
 
 Disable writing the log.cite file which is normally written to list

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_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/commands_list.txt

@@ -56,6 +56,7 @@ Commands :h1
    lattice
    log
    mass
+   message
    min_modify
    min_style
    minimize
@@ -87,6 +88,9 @@ Commands :h1
    restart
    run
    run_style
+   server
+   server_mc
+   server_md
    set
    shell
    special_bonds

doc/src/compute.txt

@@ -183,6 +183,7 @@ compute"_Commands_compute.html doc page are followed by one or more of
 "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
 "com"_compute_com.html - center-of-mass of group of atoms
@@ -225,6 +226,7 @@ compute"_Commands_compute.html doc page are followed by one or more of
 "property/chunk"_compute_property_chunk.html - extract various per-chunk attributes
 "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
 "slice"_compute_slice.html - extract values from global vector or array

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, Schiøtz, Modelling Simul Mater Sci Eng, 24, 055007 (2016).
+

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

@@ -15,6 +15,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 +67,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 +93,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 +102,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/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_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

@@ -0,0 +1,106 @@
+"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 client/md command :h3
+
+[Syntax:]
+
+fix ID group-ID client/md :pre
+
+ID, group-ID are documented in "fix"_fix.html command
+client/md = style name of this fix command :ul
+
+[Examples:]
+
+fix 1 all client/md :pre
+
+[Description:]
+
+This fix style enables LAMMPS to run as a "client" code and
+communicate each timestep with a separate "server" code to perform an
+MD simulation together.
+
+The "Howto client/server"_Howto_client_server.html doc page gives an
+overview of client/server coupling of LAMMPS with another code where
+one code is the "client" and sends request messages to a "server"
+code.  The server responds to each request with a reply message.  This
+enables the two codes to work in tandem to perform a simulation.
+
+When using this fix, LAMMPS (as the client code) passes the current
+coordinates of all particles to the server code each timestep, which
+computes their interaction, and returns the energy, forces, and virial
+for the interacting particles to LAMMPS, so it can complete the
+timestep.
+
+The server code could be a quantum code, or another classical MD code
+which encodes a force field (pair_style in LAMMPS lingo) which LAMMPS
+does not have.  In the quantum case, this fix is a mechanism for
+running {ab initio} MD with quantum forces.
+
+The group associated with this fix is ignored.
+
+The protocol and "units"_units.html for message format and content
+that LAMMPS exchanges with the server code is defined on the "server
+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"_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
+specify boundary conditions or force constraints in the usual way,
+which will be added to the per-atom forces returned by the server
+code.
+
+See the examples/message dir for example scripts where LAMMPS is both
+the "client" and/or "server" code for this kind of client/server MD
+simulation.  The examples/message/README file explains how to launch
+LAMMPS and another code in tandem to perform a coupled simulation.
+
+: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 potential energy computed by the server application to
+the system's potential energy as part of "thermodynamic
+output"_thermo_style.html.
+
+The "fix_modify"_fix_modify.html {virial} option is supported by this
+fix to add the server application's contribution to the system's
+virial as part of "thermodynamic output"_thermo_style.html.  The
+default is {virial yes}
+
+This fix computes a global scalar which can be accessed by various
+"output commands"_Howto_output.html.  The scalar is the potential
+energy discussed above.  The scalar value calculated by this fix is
+"extensive".
+
+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 MESSAGE package.  It is only enabled if LAMMPS
+was built with that package.  See the "Build
+package"_Build_package.html doc page for more info.
+
+A script that uses this command must also use the
+"message"_message.html command to setup the messaging protocol with
+the other server code.
+
+[Related commands:]
+
+"message"_message.html, "server"_server.html
+
+[Default:] none

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_msst.txt

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

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_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_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_shake.txt

@@ -214,8 +214,10 @@ which can lead to poor energy conservation.  You can test for this in
 your system by running a constant NVE simulation with a particular set
 of SHAKE parameters and monitoring the energy versus time.
 
-SHAKE or RATTLE should not be used to constrain an angle at 180 degrees
-(e.g. linear CO2 molecule).  This causes numeric difficulties.
+SHAKE or RATTLE should not be used to constrain an angle at 180
+degrees (e.g. linear CO2 molecule).  This causes numeric difficulties.
+You can use "fix rigid or fix rigid/small"_fix_rigid.html instead to
+make a linear molecule rigid.
 
 [Related commands:] none
 

doc/src/fix_smd_move_triangulated_surface.txt

@@ -73,7 +73,7 @@ package"_Build_package.html doc page for more info.
 
 [Related commands:]
 
-"smd/triangle_mesh_vertices"_compute_smd_triangle_mesh_vertices.html,
+"smd/triangle_mesh_vertices"_compute_smd_triangle_vertices.html,
 "smd/wall_surface"_fix_smd_wall_surface.html
 
 [Default:] none

doc/src/fix_smd_wall_surface.txt

@@ -64,7 +64,7 @@ multiple objects in one file.
 
 [Related commands:]
 
-"smd/triangle_mesh_vertices"_compute_smd_triangle_mesh_vertices.html,
+"smd/triangle_mesh_vertices"_compute_smd_triangle_vertices.html,
 "smd/move_tri_surf"_fix_smd_move_triangulated_surface.html,
 "smd/tri_surface"_pair_smd_triangulated_surface.html
 

doc/src/fix_surface_global.txt

@@ -1,19 +0,0 @@
-"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 wall/surface/global command :h3
-
-[Description:]
-
-This feature is not yet implemented.
-
-[Related commands:]
-
-"dump image"_dump_image.html
-
-

doc/src/fix_wall_gran.txt

@@ -7,6 +7,7 @@
 :line
 
 fix wall/gran command :h3
+fix wall/gran/omp command :h3
 
 [Syntax:]
 
@@ -136,6 +137,28 @@ the clockwise direction for {vshear} > 0 or counter-clockwise for
 {vshear} < 0.  In this case, {vshear} is the tangential velocity of
 the wall at whatever {radius} has been defined.
 
+: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.
+
 [Restart, fix_modify, output, run start/stop, minimize info:]
 
 This fix writes the shear friction state of atoms interacting with the

doc/src/fixes.txt

@@ -26,6 +26,7 @@ Fixes :h1
    fix_bond_swap
    fix_bond_react
    fix_box_relax
+   fix_client_md
    fix_cmap
    fix_colvars
    fix_controller
@@ -45,6 +46,7 @@ Fixes :h1
    fix_eos_table_rx
    fix_evaporate
    fix_external
+   fix_ffl
    fix_filter_corotate
    fix_flow_gauss
    fix_freeze
@@ -91,6 +93,7 @@ Fixes :h1
    fix_nve
    fix_nve_asphere
    fix_nve_asphere_noforce
+   fix_nve_awpmd
    fix_nve_body
    fix_nve_dot
    fix_nve_dotc_langevin
@@ -153,7 +156,6 @@ Fixes :h1
    fix_srd
    fix_store_force
    fix_store_state
-   fix_surface_global
    fix_temp_berendsen
    fix_temp_csvr
    fix_temp_rescale

doc/src/kspace_modify.txt

@@ -13,47 +13,53 @@ kspace_modify command :h3
 kspace_modify keyword value ... :pre
 
 one or more keyword/value pairs may be listed :ulb,l
-keyword = {mesh} or {order} or {order/disp} or {mix/disp} or {overlap} or {minorder} or {force} or {gewald} or {gewald/disp} or {slab} or (nozforce} or {compute} or {cutoff/adjust} or {fftbench} or {collective} or {diff} or {kmax/ewald} or {force/disp/real} or {force/disp/kspace} or {splittol} or {disp/auto}:l
-  {mesh} value = x y z
-    x,y,z = grid size in each dimension for long-range Coulombics
-  {mesh/disp} value = x y z
-    x,y,z = grid size in each dimension for 1/r^6 dispersion
-  {order} value = N
-    N = extent of Gaussian for PPPM or MSM mapping of charge to grid
-  {order/disp} value = N
-    N = extent of Gaussian for PPPM mapping of dispersion term to grid
-  {mix/disp} value = {pair} or {geom} or {none}
-  {overlap} = {yes} or {no} = whether the grid stencil for PPPM is allowed to overlap into more than the nearest-neighbor processor
-  {minorder} value = M
-    M = min allowed extent of Gaussian when auto-adjusting to minimize grid communication
+keyword = {collective} or {compute} or {cutoff/adjust} or {diff} or {disp/auto} or {fftbench} or {force/disp/kspace} or {force/disp/real} or {force} or {gewald/disp} or {gewald} or {kmax/ewald} or {mesh} or {minorder} or {mix/disp} or {order/disp} or {order} or {overlap} or {scafacos} or {slab} or {splittol} :l
+  {collective} value = {yes} or {no}
+  {compute} value = {yes} or {no}
+  {cutoff/adjust} value = {yes} or {no}
+  {diff} value = {ad} or {ik} = 2 or 4 FFTs for PPPM in smoothed or non-smoothed mode
+  {disp/auto} value = yes or no
+  {fftbench} value = {yes} or {no}
+  {force/disp/real} value = accuracy (force units)
+  {force/disp/kspace} value = accuracy (force units)
   {force} value = accuracy (force units)
   {gewald} value = rinv (1/distance units)
     rinv = G-ewald parameter for Coulombics
   {gewald/disp} value = rinv (1/distance units)
     rinv = G-ewald parameter for dispersion
+  {kmax/ewald} value = kx ky kz
+    kx,ky,kz = number of Ewald sum kspace vectors in each dimension
+  {mesh} value = x y z
+    x,y,z = grid size in each dimension for long-range Coulombics
+  {mesh/disp} value = x y z
+    x,y,z = grid size in each dimension for 1/r^6 dispersion
+  {minorder} value = M
+    M = min allowed extent of Gaussian when auto-adjusting to minimize grid communication
+  {mix/disp} value = {pair} or {geom} or {none}
+  {order} value = N
+    N = extent of Gaussian for PPPM or MSM mapping of charge to grid
+  {order/disp} value = N
+    N = extent of Gaussian for PPPM mapping of dispersion term to grid
+  {overlap} = {yes} or {no} = whether the grid stencil for PPPM is allowed to overlap into more than the nearest-neighbor processor
+  {pressure/scalar} value = {yes} or {no}
+  {scafacos} values = option value1 value2 ...
+    option = {tolerance}
+      value = {energy} or {energy_rel} or {field} or {field_rel} or {potential} or {potential_rel}
+    option = {fmm_tuning}
+      value = {0} or {1}
   {slab} value = volfactor or {nozforce}
     volfactor = ratio of the total extended volume used in the
       2d approximation compared with the volume of the simulation domain
     {nozforce} turns off kspace forces in the z direction
-  {compute} value = {yes} or {no}
-  {cutoff/adjust} value = {yes} or {no}
-  {pressure/scalar} value = {yes} or {no}
-  {fftbench} value = {yes} or {no}
-  {collective} value = {yes} or {no}
-  {diff} value = {ad} or {ik} = 2 or 4 FFTs for PPPM in smoothed or non-smoothed mode
-  {kmax/ewald} value = kx ky kz
-    kx,ky,kz = number of Ewald sum kspace vectors in each dimension
-  {force/disp/real} value = accuracy (force units)
-  {force/disp/kspace} value = accuracy (force units)
   {splittol} value = tol
-    tol = relative size of two eigenvalues (see discussion below)
-  {disp/auto} value = yes or no :pre
+    tol = relative size of two eigenvalues (see discussion below) :pre
 :ule
 
 [Examples:]
 
 kspace_modify mesh 24 24 30 order 6
-kspace_modify slab 3.0 :pre
+kspace_modify slab 3.0 
+kspace_modify scafacos tolerance energy :pre
 
 [Description:]
 
@@ -61,6 +67,132 @@ Set parameters used by the kspace solvers defined by the
 "kspace_style"_kspace_style.html command.  Not all parameters are
 relevant to all kspace styles.
 
+:line
+
+The {collective} keyword applies only to PPPM.  It is set to {no} by
+default, except on IBM BlueGene machines.  If this option is set to
+{yes}, LAMMPS will use MPI collective operations to remap data for
+3d-FFT operations instead of the default point-to-point communication.
+This is faster on IBM BlueGene machines, and may also be faster on
+other machines if they have an efficient implementation of MPI
+collective operations and adequate hardware.
+
+:line
+
+The {compute} keyword allows Kspace computations to be turned off,
+even though a "kspace_style"_kspace_style.html is defined.  This is
+not useful for running a real simulation, but can be useful for
+debugging purposes or for computing only partial forces that do not
+include the Kspace contribution.  You can also do this by simply not
+defining a "kspace_style"_kspace_style.html, but a Kspace-compatible
+"pair_style"_pair_style.html requires a kspace style to be defined.
+This keyword gives you that option.
+
+:line
+
+The {cutoff/adjust} keyword applies only to MSM. If this option is
+turned on, the Coulombic cutoff will be automatically adjusted at the
+beginning of the run to give the desired estimated error. Other
+cutoffs such as LJ will not be affected. If the grid is not set using
+the {mesh} command, this command will also attempt to use the optimal
+grid that minimizes cost using an estimate given by
+"(Hardy)"_#Hardy1. Note that this cost estimate is not exact, somewhat
+experimental, and still may not yield the optimal parameters.
+
+:line
+
+The {diff} keyword specifies the differentiation scheme used by the
+PPPM method to compute forces on particles given electrostatic
+potentials on the PPPM mesh.  The {ik} approach is the default for
+PPPM and is the original formulation used in "(Hockney)"_#Hockney1.  It
+performs differentiation in Kspace, and uses 3 FFTs to transfer each
+component of the computed fields back to real space for total of 4
+FFTs per timestep.
+
+The analytic differentiation {ad} approach uses only 1 FFT to transfer
+information back to real space for a total of 2 FFTs per timestep.  It
+then performs analytic differentiation on the single quantity to
+generate the 3 components of the electric field at each grid point.
+This is sometimes referred to as "smoothed" PPPM.  This approach
+requires a somewhat larger PPPM mesh to achieve the same accuracy as
+the {ik} method. Currently, only the {ik} method (default) can be
+used for a triclinic simulation cell with PPPM. The {ad} method is
+always used for MSM.
+
+NOTE: Currently, not all PPPM styles support the {ad} option.  Support
+for those PPPM variants will be added later.
+
+:line
+
+The {disp/auto} option controls whether the pppm/disp is allowed to
+generate PPPM parameters automatically. If set to {no}, parameters have
+to be specified using the {gewald/disp}, {mesh/disp},
+{force/disp/real} or {force/disp/kspace} keywords, or
+the code will stop with an error message. When this option is set to
+{yes}, the error message will not appear and the simulation will start.
+For a typical application, using the automatic parameter generation
+will provide simulations that are either inaccurate or slow. Using this
+option is thus not recommended. For guidelines on how to obtain good
+parameters, see the "How-To"_Howto_dispersion.html discussion.
+
+:line
+
+The {fftbench} keyword applies only to PPPM. It is off by default. If
+this option is turned on, LAMMPS will perform a short FFT benchmark
+computation and report its timings, and will thus finish a some seconds
+later than it would if this option were off.
+
+:line
+
+The {force/disp/real} and {force/disp/kspace} keywords set the force
+accuracy for the real and space computations for the dispersion part
+of pppm/disp. As shown in "(Isele-Holder)"_#Isele-Holder1, optimal
+performance and accuracy in the results is obtained when these values
+are different.
+
+:line
+
+The {force} keyword overrides the relative accuracy parameter set by
+the "kspace_style"_kspace_style.html command with an absolute
+accuracy.  The accuracy determines the RMS error in per-atom forces
+calculated by the long-range solver and is thus specified in force
+units.  A negative value for the accuracy setting means to use the
+relative accuracy parameter.  The accuracy setting is used in
+conjunction with the pairwise cutoff to determine the number of
+K-space vectors for style {ewald}, the FFT grid size for style
+{pppm}, or the real space grid size for style {msm}.
+
+:line
+
+The {gewald} keyword sets the value of the Ewald or PPPM G-ewald
+parameter for charge as {rinv} in reciprocal distance units.  Without
+this setting, LAMMPS chooses the parameter automatically as a function
+of cutoff, precision, grid spacing, etc.  This means it can vary from
+one simulation to the next which may not be desirable for matching a
+KSpace solver to a pre-tabulated pairwise potential.  This setting can
+also be useful if Ewald or PPPM fails to choose a good grid spacing
+and G-ewald parameter automatically.  If the value is set to 0.0,
+LAMMPS will choose the G-ewald parameter automatically.  MSM does not
+use the {gewald} parameter.
+
+:line
+
+The {gewald/disp} keyword sets the value of the Ewald or PPPM G-ewald
+parameter for dispersion as {rinv} in reciprocal distance units.  It
+has the same meaning as the {gewald} setting for Coulombics.
+
+:line
+
+The {kmax/ewald} keyword sets the number of kspace vectors in each
+dimension for kspace style {ewald}.  The three values must be positive
+integers, or else (0,0,0), which unsets the option.  When this option
+is not set, the Ewald sum scheme chooses its own kspace vectors,
+consistent with the user-specified accuracy and pairwise cutoff. In
+any case, if kspace style {ewald} is invoked, the values used are
+printed to the screen and the log file at the start of the run.
+
+:line
+
 The {mesh} keyword sets the grid size for kspace style {pppm} or
 {msm}.  In the case of PPPM, this is the FFT mesh, and each dimension
 must be factorizable into powers of 2, 3, and 5.  In the case of MSM,
@@ -70,6 +202,8 @@ or MSM solver chooses its own grid size, consistent with the
 user-specified accuracy and pairwise cutoff.  Values for x,y,z of
 0,0,0 unset the option.
 
+:line
+
 The {mesh/disp} keyword sets the grid size for kspace style
 {pppm/disp}.  This is the FFT mesh for long-range dispersion and ach
 dimension must be factorizable into powers of 2, 3, and 5.  When this
@@ -77,39 +211,7 @@ option is not set, the PPPM solver chooses its own grid size,
 consistent with the user-specified accuracy and pairwise cutoff.
 Values for x,y,z of 0,0,0 unset the option.
 
-The {order} keyword determines how many grid spacings an atom's charge
-extends when it is mapped to the grid in kspace style {pppm} or {msm}.
-The default for this parameter is 5 for PPPM and 8 for MSM, which
-means each charge spans 5 or 8 grid cells in each dimension,
-respectively.  For the LAMMPS implementation of MSM, the order can
-range from 4 to 10 and must be even. For PPPM, the minimum allowed
-setting is 2 and the maximum allowed setting is 7.  The larger the
-value of this parameter, the smaller that LAMMPS will set the grid
-size, to achieve the requested accuracy.  Conversely, the smaller the
-order value, the larger the grid size will be.  Note that there is an
-inherent trade-off involved: a small grid will lower the cost of FFTs
-or MSM direct sum, but a larger order parameter will increase the cost
-of interpolating charge/fields to/from the grid.
-
-The {order/disp} keyword determines how many grid spacings an atom's
-dispersion term extends when it is mapped to the grid in kspace style
-{pppm/disp}.  It has the same meaning as the {order} setting for
-Coulombics.
-
-The {overlap} keyword can be used in conjunction with the {minorder}
-keyword with the PPPM styles to adjust the amount of communication
-that occurs when values on the FFT grid are exchanged between
-processors.  This communication is distinct from the communication
-inherent in the parallel FFTs themselves, and is required because
-processors interpolate charge and field values using grid point values
-owned by neighboring processors (i.e. ghost point communication).  If
-the {overlap} keyword is set to {yes} then this communication is
-allowed to extend beyond nearest-neighbor processors, e.g. when using
-lots of processors on a small problem.  If it is set to {no} then the
-communication will be limited to nearest-neighbor processors and the
-{order} setting will be reduced if necessary, as explained by the
-{minorder} keyword discussion. The {overlap} keyword is always set to
-{yes} in MSM.
+:line
 
 The {minorder} keyword allows LAMMPS to reduce the {order} setting if
 necessary to keep the communication of ghost grid point limited to
@@ -126,6 +228,42 @@ error if the grid communication is non-nearest-neighbor and {overlap}
 is set to {no}. The {minorder} keyword is not currently supported in
 MSM.
 
+:line
+
+The {mix/disp} keyword selects the mixing rule for the dispersion
+coefficients.  With {pair}, the dispersion coefficients of unlike
+types are computed as indicated with "pair_modify"_pair_modify.html.
+With {geom}, geometric mixing is enforced on the dispersion
+coefficients in the kspace coefficients. When using the arithmetic
+mixing rule, this will speed-up the simulations but introduces some
+error in the force computations, as shown in "(Wennberg)"_#Wennberg.
+With {none}, it is assumed that no mixing rule is
+applicable. Splitting of the dispersion coefficients will be performed
+as described in "(Isele-Holder)"_#Isele-Holder1.
+
+This splitting can be influenced with the {splittol} keywords.  Only
+the eigenvalues that are larger than tol compared to the largest
+eigenvalues are included. Using this keywords the original matrix of
+dispersion coefficients is approximated. This leads to faster
+computations, but the accuracy in the reciprocal space computations of
+the dispersion part is decreased.
+
+:line
+
+The {order} keyword determines how many grid spacings an atom's charge
+extends when it is mapped to the grid in kspace style {pppm} or {msm}.
+The default for this parameter is 5 for PPPM and 8 for MSM, which
+means each charge spans 5 or 8 grid cells in each dimension,
+respectively.  For the LAMMPS implementation of MSM, the order can
+range from 4 to 10 and must be even. For PPPM, the minimum allowed
+setting is 2 and the maximum allowed setting is 7.  The larger the
+value of this parameter, the smaller that LAMMPS will set the grid
+size, to achieve the requested accuracy.  Conversely, the smaller the
+order value, the larger the grid size will be.  Note that there is an
+inherent trade-off involved: a small grid will lower the cost of FFTs
+or MSM direct sum, but a larger order parameter will increase the cost
+of interpolating charge/fields to/from the grid.
+
 The PPPM order parameter may be reset by LAMMPS when it sets up the
 FFT grid if the implied grid stencil extends beyond the grid cells
 owned by neighboring processors.  Typically this will only occur when
@@ -134,30 +272,102 @@ be generated indicating the order parameter is being reduced to allow
 LAMMPS to run the problem. Automatic adjustment of the order parameter
 is not supported in MSM.
 
-The {force} keyword overrides the relative accuracy parameter set by
-the "kspace_style"_kspace_style.html command with an absolute
-accuracy.  The accuracy determines the RMS error in per-atom forces
-calculated by the long-range solver and is thus specified in force
-units.  A negative value for the accuracy setting means to use the
-relative accuracy parameter.  The accuracy setting is used in
-conjunction with the pairwise cutoff to determine the number of
-K-space vectors for style {ewald}, the FFT grid size for style
-{pppm}, or the real space grid size for style {msm}.
+:line
 
-The {gewald} keyword sets the value of the Ewald or PPPM G-ewald
-parameter for charge as {rinv} in reciprocal distance units.  Without
-this setting, LAMMPS chooses the parameter automatically as a function
-of cutoff, precision, grid spacing, etc.  This means it can vary from
-one simulation to the next which may not be desirable for matching a
-KSpace solver to a pre-tabulated pairwise potential.  This setting can
-also be useful if Ewald or PPPM fails to choose a good grid spacing
-and G-ewald parameter automatically.  If the value is set to 0.0,
-LAMMPS will choose the G-ewald parameter automatically.  MSM does not
-use the {gewald} parameter.
+The {order/disp} keyword determines how many grid spacings an atom's
+dispersion term extends when it is mapped to the grid in kspace style
+{pppm/disp}.  It has the same meaning as the {order} setting for
+Coulombics.
 
-The {gewald/disp} keyword sets the value of the Ewald or PPPM G-ewald
-parameter for dispersion as {rinv} in reciprocal distance units.  It
-has the same meaning as the {gewald} setting for Coulombics.
+:line
+
+The {overlap} keyword can be used in conjunction with the {minorder}
+keyword with the PPPM styles to adjust the amount of communication
+that occurs when values on the FFT grid are exchanged between
+processors.  This communication is distinct from the communication
+inherent in the parallel FFTs themselves, and is required because
+processors interpolate charge and field values using grid point values
+owned by neighboring processors (i.e. ghost point communication).  If
+the {overlap} keyword is set to {yes} then this communication is
+allowed to extend beyond nearest-neighbor processors, e.g. when using
+lots of processors on a small problem.  If it is set to {no} then the
+communication will be limited to nearest-neighbor processors and the
+{order} setting will be reduced if necessary, as explained by the
+{minorder} keyword discussion. The {overlap} keyword is always set to
+{yes} in MSM.
+
+:line
+
+The {pressure/scalar} keyword applies only to MSM. If this option is
+turned on, only the scalar pressure (i.e. (Pxx + Pyy + Pzz)/3.0) will
+be computed, which can be used, for example, to run an isotropic barostat.
+Computing the full pressure tensor with MSM is expensive, and this option
+provides a faster alternative. The scalar pressure is computed using a
+relationship between the Coulombic energy and pressure "(Hummer)"_#Hummer
+instead of using the virial equation. This option cannot be used to access
+individual components of the pressure tensor, to compute per-atom virial,
+or with suffix kspace/pair styles of MSM, like OMP or GPU.
+
+:line
+
+The {scafacos} keyword is used for settings that are passed to the
+ScaFaCoS library when using "kspace_style scafacos"_kspace_style.html.
+
+The {tolerance} option affects how the {accuracy} specified with the
+"kspace_style"_kspace_style.html command is interpreted by ScaFaCoS.
+The following values may be used:
+
+energy = absolute accuracy in total Coulomic energy
+energy_rel = relative accuracy in total Coulomic energy
+potential = absolute accuracy in total Coulomic potential
+potential_rel = relative accuracy in total Coulomic potential
+field = absolute accuracy in electric field
+field_rel = relative accuracy in electric field :ul
+
+The values with suffix _rel indicate the tolerance is a relative
+tolerance; the other values impose an absolute tolerance on the given
+quantity. Absoulte tolerance in this case means, that for a given
+quantity q and a given absolute tolerance of t_a the result should
+be between q-t_a and q+t_a. For a relative tolerance t_r the relative 
+error should not be greater than t_r, i.e. abs(1 - (result/q)) < t_r. 
+As a consequence of this, the tolerance type should be checked, when
+performing computations with a high absolute field / energy. E.g.
+if the total energy in the system is 1000000.0 an absolute tolerance
+of 1e-3 would mean that the result has to be between 999999.999 and
+1000000.001, which would be equivalent to a relative tolerance of
+1e-9.
+
+The energy and energy_rel values, set a tolerance based on the total
+Coulomic energy of the system.  The potential and potential_rel set a
+tolerance based on the per-atom Coulomic energy.  The field and
+field_rel tolerance types set a tolerance based on the electric field
+values computed by ScaFaCoS.  Since per-atom forces are derived from
+the per-atom electric field, this effectively sets a tolerance on the
+forces, simimlar to other LAMMPS KSpace styles, as explained on the
+"kspace_style"_kspace_style.html doc page.
+
+Note that not all ScaFaCoS solvers support all tolerance types.
+These are the allowed values for each method:
+
+fmm = energy and energy_rel
+p2nfft = field (1d-,2d-,3d-periodic systems) or potential (0d-periodic)
+p3m = field
+ewald = field
+direct = has no tolerance tuning :ul
+
+If the tolerance type is not changed, the default values for the
+tolerance type are the first values in the above list, e.g. energy
+is the default tolerance type for the fmm solver.
+
+The {fmm_tuning} option is only relevant when using the FMM method.
+It activates (value=1) or deactivates (value=0) an internal tuning
+mechanism for the FMM solver.  The tuning operation runs sequentially
+and can be very time-consuming.  Usually it is not needed for systems
+with a homogenous charge distribution. The default for this option is
+therefore {0}. The FMM internal tuning is performed once, when the
+solver is set up.
+
+:line
 
 The {slab} keyword allows an Ewald or PPPM solver to be used for a
 systems that are periodic in x,y but non-periodic in z - a
@@ -191,92 +401,7 @@ the "fix efield"_fix_efield.html command, it will not give the correct
 dielectric constant due to the Yeh/Berkowitz "(Yeh)"_#Yeh correction
 not being compatible with how "fix efield"_fix_efield.html works.
 
-The {compute} keyword allows Kspace computations to be turned off,
-even though a "kspace_style"_kspace_style.html is defined.  This is
-not useful for running a real simulation, but can be useful for
-debugging purposes or for computing only partial forces that do not
-include the Kspace contribution.  You can also do this by simply not
-defining a "kspace_style"_kspace_style.html, but a Kspace-compatible
-"pair_style"_pair_style.html requires a kspace style to be defined.
-This keyword gives you that option.
-
-The {cutoff/adjust} keyword applies only to MSM. If this option is
-turned on, the Coulombic cutoff will be automatically adjusted at the
-beginning of the run to give the desired estimated error. Other
-cutoffs such as LJ will not be affected. If the grid is not set using
-the {mesh} command, this command will also attempt to use the optimal
-grid that minimizes cost using an estimate given by
-"(Hardy)"_#Hardy1. Note that this cost estimate is not exact, somewhat
-experimental, and still may not yield the optimal parameters.
-
-The {pressure/scalar} keyword applies only to MSM. If this option is
-turned on, only the scalar pressure (i.e. (Pxx + Pyy + Pzz)/3.0) will
-be computed, which can be used, for example, to run an isotropic barostat.
-Computing the full pressure tensor with MSM is expensive, and this option
-provides a faster alternative. The scalar pressure is computed using a
-relationship between the Coulombic energy and pressure "(Hummer)"_#Hummer
-instead of using the virial equation. This option cannot be used to access
-individual components of the pressure tensor, to compute per-atom virial,
-or with suffix kspace/pair styles of MSM, like OMP or GPU.
-
-The {fftbench} keyword applies only to PPPM. It is off by default. If
-this option is turned on, LAMMPS will perform a short FFT benchmark
-computation and report its timings, and will thus finish a some seconds
-later than it would if this option were off.
-
-The {collective} keyword applies only to PPPM.  It is set to {no} by
-default, except on IBM BlueGene machines.  If this option is set to
-{yes}, LAMMPS will use MPI collective operations to remap data for
-3d-FFT operations instead of the default point-to-point communication.
-This is faster on IBM BlueGene machines, and may also be faster on
-other machines if they have an efficient implementation of MPI
-collective operations and adequate hardware.
-
-The {diff} keyword specifies the differentiation scheme used by the
-PPPM method to compute forces on particles given electrostatic
-potentials on the PPPM mesh.  The {ik} approach is the default for
-PPPM and is the original formulation used in "(Hockney)"_#Hockney1.  It
-performs differentiation in Kspace, and uses 3 FFTs to transfer each
-component of the computed fields back to real space for total of 4
-FFTs per timestep.
-
-The analytic differentiation {ad} approach uses only 1 FFT to transfer
-information back to real space for a total of 2 FFTs per timestep.  It
-then performs analytic differentiation on the single quantity to
-generate the 3 components of the electric field at each grid point.
-This is sometimes referred to as "smoothed" PPPM.  This approach
-requires a somewhat larger PPPM mesh to achieve the same accuracy as
-the {ik} method. Currently, only the {ik} method (default) can be
-used for a triclinic simulation cell with PPPM. The {ad} method is
-always used for MSM.
-
-NOTE: Currently, not all PPPM styles support the {ad} option.  Support
-for those PPPM variants will be added later.
-
-The {kmax/ewald} keyword sets the number of kspace vectors in each
-dimension for kspace style {ewald}.  The three values must be positive
-integers, or else (0,0,0), which unsets the option.  When this option
-is not set, the Ewald sum scheme chooses its own kspace vectors,
-consistent with the user-specified accuracy and pairwise cutoff. In
-any case, if kspace style {ewald} is invoked, the values used are
-printed to the screen and the log file at the start of the run.
-
-With the {mix/disp} keyword one can select the mixing rule for the
-dispersion coefficients.  With {pair}, the dispersion coefficients of
-unlike types are computed as indicated with
-"pair_modify"_pair_modify.html.  With {geom}, geometric mixing is
-enforced on the dispersion coefficients in the kspace
-coefficients. When using the arithmetic mixing rule, this will
-speed-up the simulations but introduces some error in the force
-computations, as shown in "(Wennberg)"_#Wennberg.  With {none}, it is
-assumed that no mixing rule is applicable. Splitting of the dispersion
-coefficients will be performed as described in
-"(Isele-Holder)"_#Isele-Holder1.  This splitting can be influenced with
-the {splittol} keywords. Only the eigenvalues that are larger than tol
-compared to the largest eigenvalues are included. Using this keywords
-the original matrix of dispersion coefficients is approximated. This
-leads to faster computations, but the accuracy in the reciprocal space
-computations of the dispersion part is decreased.
+:line
 
 The {force/disp/real} and {force/disp/kspace} keywords set the force
 accuracy for the real and space computations for the dispersion part
@@ -295,6 +420,8 @@ provide simulations that are either inaccurate or slow. Using this
 option is thus not recommended.  For guidelines on how to obtain good
 parameters, see the "Howto dispersion"_Howto_dispersion.html doc page.
 
+:line
+
 [Restrictions:] none
 
 [Related commands:]
@@ -306,10 +433,12 @@ parameters, see the "Howto dispersion"_Howto_dispersion.html doc page.
 The option defaults are mesh = mesh/disp = 0 0 0, order = order/disp =
 5 (PPPM), order = 10 (MSM), minorder = 2, overlap = yes, force = -1.0,
 gewald = gewald/disp = 0.0, slab = 1.0, compute = yes, cutoff/adjust =
-yes (MSM), pressure/scalar = yes (MSM), fftbench = no (PPPM), diff = ik
-(PPPM), mix/disp = pair, force/disp/real = -1.0, force/disp/kspace = -1.0,
-split = 0, tol = 1.0e-6, and disp/auto = no. For pppm/intel, order =
-order/disp = 7.
+yes (MSM), pressure/scalar = yes (MSM), fftbench = no (PPPM), diff =
+ik (PPPM), mix/disp = pair, force/disp/real = -1.0, force/disp/kspace
+= -1.0, split = 0, tol = 1.0e-6, and disp/auto = no. For pppm/intel,
+order = order/disp = 7.  For scafacos settings, the scafacos tolerance
+option depends on the method chosen, as documented above.  The
+scafacos fmm_tuning default = 0.
 
 :line
 

doc/src/kspace_style.txt

@@ -12,7 +12,7 @@ kspace_style command :h3
 
 kspace_style style value :pre
 
-style = {none} or {ewald} or {ewald/disp} or {ewald/omp} or {pppm} or {pppm/cg} or {pppm/disp} or {pppm/tip4p} or {pppm/stagger} or {pppm/disp/tip4p} or {pppm/gpu} or {pppm/kk} or {pppm/omp} or {pppm/cg/omp} or {pppm/tip4p/omp} or {msm} or {msm/cg} or {msm/omp} or {msm/cg/omp} :ulb,l
+style = {none} or {ewald} or {ewald/disp} or {ewald/omp} or {pppm} or {pppm/cg} or {pppm/disp} or {pppm/tip4p} or {pppm/stagger} or {pppm/disp/tip4p} or {pppm/gpu} or {pppm/kk} or {pppm/omp} or {pppm/cg/omp} or {pppm/tip4p/omp} or {msm} or {msm/cg} or {msm/omp} or {msm/cg/omp} or {scafacos} :ulb,l
   {none} value = none
   {ewald} value = accuracy
     accuracy = desired relative error in forces
@@ -22,7 +22,7 @@ style = {none} or {ewald} or {ewald/disp} or {ewald/omp} or {pppm} or {pppm/cg}
     accuracy = desired relative error in forces
   {pppm} value = accuracy
     accuracy = desired relative error in forces
-  {pppm/cg} value = accuracy (smallq)
+  {pppm/cg} values = accuracy (smallq)
     accuracy = desired relative error in forces
     smallq = cutoff for charges to be considered (optional) (charge units)
   {pppm/disp} value = accuracy
@@ -56,7 +56,10 @@ style = {none} or {ewald} or {ewald/disp} or {ewald/omp} or {pppm} or {pppm/cg}
     accuracy = desired relative error in forces
   {msm/cg/omp} value = accuracy (smallq)
     accuracy = desired relative error in forces
-    smallq = cutoff for charges to be considered (optional) (charge units) :pre
+    smallq = cutoff for charges to be considered (optional) (charge units)
+  {scafacos} values = method accuracy
+    method = fmm or p2nfft or ewald or direct 
+    accuracy = desired relative error in forces :pre
 :ule
 
 [Examples:]
@@ -64,6 +67,7 @@ style = {none} or {ewald} or {ewald/disp} or {ewald/omp} or {pppm} or {pppm/cg}
 kspace_style pppm 1.0e-4
 kspace_style pppm/cg 1.0e-5 1.0e-6
 kspace style msm 1.0e-4
+kspace style scafacos fmm 1.0e-4
 kspace_style none :pre
 
 [Description:]
@@ -211,6 +215,63 @@ pressure simulation with MSM will cause the code to run slower.
 
 :line
 
+The {scafacos} style is a wrapper on the "ScaFaCoS Coulomb solver
+library"_http://www.scafacos.de which provides a variety of solver
+methods which can be used with LAMMPS.  The paper by "(Who)"_#Who2012
+gives an overview of ScaFaCoS.
+
+ScaFaCoS was developed by a consortium of German research facilities
+with a BMBF (German Ministry of Science and Education) funded project
+in 2009-2012. Participants of the consortium were the Universities of
+Bonn, Chemnitz, Stuttgart, and Wuppertal as well as the
+Forschungszentrum Juelich.
+
+The library is available for download at "http://scafacos.de" or can
+be cloned from the git-repository
+"git://github.com/scafacos/scafacos.git".
+
+In order to use this KSpace style, you must download and build the
+ScaFaCoS library, then build LAMMPS with the USER-SCAFACOS package
+installed package which links LAMMPS to the ScaFaCoS library.
+See details on "this page"_Section_packages.html#USER-SCAFACOS.
+
+NOTE: Unlike other KSpace solvers in LAMMPS, ScaFaCoS computes all
+Coulombic interactions, both short- and long-range.  Thus you should
+NOT use a Coulmbic pair style when using kspace_style scafacos.  This
+also means the total Coulombic energy (short- and long-range) will be
+tallied for "thermodynamic output"_thermo_style.html command as part
+of the {elong} keyword; the {ecoul} keyword will be zero.
+
+NOTE: See the current restriction below about use of ScaFaCoS in
+LAMMPS with molecular charged systems or the TIP4P water model.
+
+The specified {method} determines which ScaFaCoS algorithm is used.
+These are the ScaFaCoS methods currently available from LAMMPS:
+
+{fmm} = Fast Multi-Pole method
+{p2nfft} = FFT-based Coulomb solver
+{ewald} = Ewald summation
+{direct} = direct O(N^2) summation
+{p3m} = PPPM :ul
+
+We plan to support additional ScaFaCoS solvers from LAMMPS in the
+future.  For an overview of the included solvers, refer to
+"(Sutmann)"_#Sutmann2013
+
+The specified {accuracy} is similar to the accuracy setting for other
+LAMMPS KSpace styles, but is passed to ScaFaCoS, which can interpret
+it in different ways for different methods it supports.  Within the
+ScaFaCoS library the {accuracy} is treated as a tolerance level
+(either absolute or relative) for the chosen quantity, where the
+quantity can be either the Columic field values, the per-atom Columic
+energy or the total Columic energy.  To select from these options, see
+the "kspace_modify scafacos accuracy"_kspace_modify.html doc page.
+
+The "kspace_modify scafacos"_kspace_modify.html command also explains
+other ScaFaCoS options currently exposed to LAMMPS.
+
+:line
+
 The specified {accuracy} determines the relative RMS error in per-atom
 forces calculated by the long-range solver.  It is set as a
 dimensionless number, relative to the force that two unit point
@@ -321,12 +382,24 @@ dimensions.  The only exception is if the slab option is set with
 "kspace_modify"_kspace_modify.html, in which case the xy dimensions
 must be periodic and the z dimension must be non-periodic.
 
+The scafacos KSpace style will only be enabled if LAMMPS is built with
+the USER-SCAFACOS package.  See the "Build package"_Build_package.html
+doc page for more info.
+
+The use of ScaFaCos in LAMMPS does not yet support molecular charged
+systems where the short-range Coulombic interactions between atoms in
+the same bond/angle/dihedral are weighted by the
+"special_bonds"_special_bonds.html command.  Likewise it does not
+support the "TIP4P water style" where a fictitious charge site is
+introduced in each water molecule.
+
 [Related commands:]
 
 "kspace_modify"_kspace_modify.html, "pair_style
 lj/cut/coul/long"_pair_lj.html, "pair_style
 lj/charmm/coul/long"_pair_charmm.html, "pair_style
-lj/long/coul/long"_pair_lj_long.html, "pair_style buck/coul/long"_pair_buck.html
+lj/long/coul/long"_pair_lj_long.html, "pair_style
+buck/coul/long"_pair_buck.html
 
 [Default:]
 
@@ -384,5 +457,12 @@ Evaluation of Forces for the Simulation of Biomolecules, University of
 Illinois at Urbana-Champaign, (2006).
 
 :link(Hardy2009)
-[(Hardy2)] Hardy, Stone, Schulten, Parallel Computing 35 (2009)
-164-177.
+[(Hardy2)] Hardy, Stone, Schulten, Parallel Computing, 35, 164-177
+(2009).
+
+:link(Sutmann2013)
+[(Sutmann)] Sutmann, Arnold, Fahrenberger, et. al., Physical review / E 88(6), 063308 (2013)
+
+:link(Who2012)
+[(Who)] Who, Author2, Author3, J of Long Range Solvers, 35, 164-177
+(2012).

doc/src/lammps.book

@@ -67,6 +67,7 @@ Howto_multiple.html
 Howto_replica.html
 Howto_library.html
 Howto_couple.html
+Howto_client_server.html
 Howto_output.html
 Howto_chunk.html
 Howto_2d.html
@@ -167,6 +168,7 @@ label.html
 lattice.html
 log.html
 mass.html
+message.html
 min_modify.html
 min_style.html
 minimize.html
@@ -194,6 +196,9 @@ reset_timestep.html
 restart.html
 run.html
 run_style.html
+server.html
+server_mc.html
+server_md.html
 set.html
 shell.html
 special_bonds.html
@@ -241,6 +246,7 @@ fix_bond_create.html
 fix_bond_react.html
 fix_bond_swap.html
 fix_box_relax.html
+fix_client_md.html
 fix_cmap.html
 fix_colvars.html
 fix_controller.html
@@ -260,6 +266,7 @@ fix_eos_table.html
 fix_eos_table_rx.html
 fix_evaporate.html
 fix_external.html
+fix_ffl.html
 fix_filter_corotate.html
 fix_flow_gauss.html
 fix_freeze.html
@@ -305,6 +312,7 @@ fix_npt_sphere.html
 fix_nve.html
 fix_nve_asphere.html
 fix_nve_asphere_noforce.html
+fix_nve_awpmd.html
 fix_nve_body.html
 fix_nve_dot.html
 fix_nve_dotc_langevin.html
@@ -368,7 +376,6 @@ fix_spring_self.html
 fix_srd.html
 fix_store_force.html
 fix_store_state.html
-fix_surface_global.html
 fix_temp_berendsen.html
 fix_temp_csvr.html
 fix_temp_rescale.html
@@ -406,6 +413,7 @@ compute_bond.html
 compute_bond_local.html
 compute_centro_atom.html
 compute_chunk_atom.html
+compute_chunk_spread_atom.html
 compute_cluster_atom.html
 compute_cna_atom.html
 compute_cnp_atom.html
@@ -457,12 +465,15 @@ compute_pe.html
 compute_pe_atom.html
 compute_plasticity_atom.html
 compute_pressure.html
+compute_pressure_cylinder.html
 compute_pressure_uef.html
 compute_property_atom.html
 compute_property_chunk.html
 compute_property_local.html
+compute_ptm_atom.html
 compute_rdf.html
 compute_reduce.html
+compute_reduce_chunk.html
 compute_rigid_local.html
 compute_saed.html
 compute_slice.html
@@ -480,7 +491,7 @@ compute_smd_tlsph_shape.html
 compute_smd_tlsph_strain.html
 compute_smd_tlsph_strain_rate.html
 compute_smd_tlsph_stress.html
-compute_smd_triangle_mesh_vertices.html
+compute_smd_triangle_vertices.html
 compute_smd_ulsph_num_neighs.html
 compute_smd_ulsph_strain.html
 compute_smd_ulsph_strain_rate.html
@@ -489,6 +500,7 @@ compute_smd_vol.html
 compute_sna_atom.html
 compute_spin.html
 compute_stress_atom.html
+compute_stress_mop.html
 compute_tally.html
 compute_tdpd_cc_atom.html
 compute_temp.html

doc/src/message.txt

@@ -0,0 +1,162 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Command_all.html)
+
+:line
+
+message command :h3
+
+[Syntax:]
+
+message which protocol mode arg :pre
+
+which = {client} or {server} :ulb,l
+protocol = {md} or {mc} :l
+mode = {file} or {zmq} or {mpi/one} or {mpi/two} :l
+  {file} arg = filename
+    filename = file used for message exchanges
+  {zmq} arg = socket-ID
+    socket-ID for client = localhost:5555, see description below
+    socket-ID for server = *:5555, see description below
+  {mpi/one} arg = none
+  {mpi/two} arg = filename
+    filename = file used to establish communication bewteen 2 MPI jobs :pre
+:ule
+
+[Examples:]
+  
+message client md file tmp.couple
+message server md file tmp.couple :pre
+
+message client md zmq localhost:5555
+message server md zmq *:5555 :pre
+
+message client md mpi/one
+message server md mpi/one :pre
+
+message client md mpi/two tmp.couple
+message server md mpi/two tmp.couple :pre
+
+[Description:]
+
+Establish a messaging protocol between LAMMPS and another code for the
+purpose of client/server coupling.
+
+The "Howto client/server"_Howto_client_server.html doc page gives an
+overview of client/server coupling of LAMMPS with another code where
+one code is the "client" and sends request messages to a "server"
+code.  The server responds to each request with a reply message.  This
+enables the two codes to work in tandem to perform a simulation.
+
+:line
+
+The {which} argument defines LAMMPS to be the client or the server.
+
+:line
+
+The {protocol} argument defines the format and content of messages
+that will be exchanged between the two codes.  The current options
+are:
+
+md = run dynamics with another code
+mc = perform Monte Carlo moves with another code :ul
+
+For protocol {md}, LAMMPS can be either a client or server.  See the
+"server md"_server_md.html doc page for details on the protocol.
+
+For protocol {mc}, LAMMPS can be the server.  See the "server
+mc"_server_mc.html doc page for details on the protocol.
+
+:line
+
+The {mode} argument specifies how messages are exchanged between the
+client and server codes.  Both codes must use the same mode and use
+consistent parameters.
+
+For mode {file}, the 2 codes communicate via binary files.  They must
+use the same filename, which is actually a file prefix.  Several files
+with that prefix will be created and deleted as a simulation runs.
+The filename can include a path.  Both codes must be able to access
+the path/file in a common filesystem.
+
+For mode {zmq}, the 2 codes communicate via a socket on the server
+code's machine.  Support for socket messaging is provided by the
+open-source "ZeroMQ library"_http://zeromq.org, which must be
+installed on your system.  The client specifies an IP address (IPv4
+format) or the DNS name of the machine the server code is running on,
+followed by a 4-digit port ID for the socket, separated by a colon.
+E.g.
+
+localhost:5555        # client and server running on same machine
+192.168.1.1:5555      # server is 192.168.1.1
+deptbox.uni.edu:5555  # server is deptbox.uni.edu :pre
+
+The server specifes "*:5555" where "*" represents all available
+interfaces on the server's machine, and the port ID must match
+what the client specifies.
+
+NOTE: What are allowed port IDs?
+
+NOTE: Additional explanation is needed here about how to use the {zmq}
+mode on a parallel machine, e.g. a cluster with many nodes.
+
+For mode {mpi/one}, the 2 codes communicate via MPI and are launched
+by the same mpirun command, e.g. with this syntax for OpenMPI:
+
+mpirun -np 2 lmp_mpi -mpicolor 0 -in in.client -log log.client : -np 4 othercode args  # LAMMPS is client
+mpirun -np 2 othercode args : -np 4 lmp_mpi -mpicolor 1 -in in.server  # LAMMPS is server :pre
+
+Note the use of the "-mpicolor color" command-line argument with
+LAMMPS.  See the "command-line args"_Run_options.html doc page for
+further explanation.
+
+For mode {mpi/two}, the 2 codes communicate via MPI, but are launched
+be 2 separate mpirun commands.  The specified {filename} argument is a
+file the 2 MPI processes will use to exchange info so that an MPI
+inter-communicator can be established to enable the 2 codes to send
+MPI messages to each other.  Both codes must be able to access the
+path/file in a common filesystem.
+
+:line
+
+Normally, the message command should be used at the top of a LAMMPS
+input script.  It performs an initial handshake with the other code to
+setup messaging and to verify that both codes are using the same
+message protocol and mode.  Assuming both codes are launched at
+(nearly) the same time, the other code should perform the same kind of
+initialization.
+
+If LAMMPS is the client code, it will begin sending messages when a
+LAMMPS client command begins its operation.  E.g. for the "fix
+client/md"_fix_client_md.html command, it is when a "run"_run.html
+command is executed.
+
+If LAMMPS is the server code, it will begin receiving messages when
+the "server"_server.html command is invoked.
+
+A fix client command will terminate its messaging with the server when
+LAMMPS ends, or the fix is deleted via the "unfix"_unfix command.  The
+server command will terminate its messaging with the client when the
+client signals it.  Then the remainder of the LAMMPS input script will
+be processed.
+
+If both codes do something similar, this means a new round of
+client/server messaging can be initiated after termination by re-using
+a 2nd message command in your LAMMPS input script, followed by a new
+fix client or server command.
+
+:line
+
+[Restrictions:]
+
+This command is part of the MESSAGE 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:]
+
+"server"_server.html, "fix client/md"_fix_client_md.html
+
+[Default:] none

doc/src/minimize.txt

@@ -216,10 +216,10 @@ The "fix box/relax"_fix_box_relax.html command can be used to apply an
 external pressure to the simulation box and allow it to shrink/expand
 during the minimization.
 
-Only a few other fixes (typically those that apply force constraints)
-are invoked during minimization.  See the doc pages for individual
-"fix"_fix.html commands to see which ones are relevant.  Current
-examples of fixes that can be used include:
+Only a few other fixes (typically those that add forces) are invoked
+during minimization.  See the doc pages for individual "fix"_fix.html
+commands to see which ones are relevant.  Current examples of fixes
+that can be used include:
 
 "fix addforce"_fix_addforce.html
 "fix addtorque"_fix_addtorque.html
@@ -242,6 +242,11 @@ you MUST enable the "fix_modify"_fix_modify.html {energy} option for
 that fix.  The doc pages for individual "fix"_fix.html commands
 specify if this should be done.
 
+NOTE: The minimizers in LAMMPS do not allow for bonds (or angles, etc)
+to be held fixed while atom coordinates are being relaxed, e.g. via
+"fix shake"_fix_shake.html or "fix rigid"_fix_rigid.html.  See more
+info in the Restrictions section below.
+
 :line
 
 [Restrictions:]

doc/src/pair_body_nparticle.txt

@@ -6,7 +6,7 @@
 
 :line
 
-pair_style body command :h3
+pair_style body/nparticle command :h3
 
 [Syntax:]
 

doc/src/pair_born.txt

@@ -11,19 +11,14 @@ pair_style born command :h3
 pair_style born/omp command :h3
 pair_style born/gpu command :h3
 pair_style born/coul/long command :h3
-pair_style born/coul/long/cs command :h3
-pair_style born/coul/long/cs/gpu command :h3
 pair_style born/coul/long/gpu command :h3
 pair_style born/coul/long/omp command :h3
 pair_style born/coul/msm command :h3
 pair_style born/coul/msm/omp command :h3
 pair_style born/coul/wolf command :h3
-pair_style born/coul/wolf/cs command :h3
-pair_style born/coul/wolf/cs/gpu command :h3
 pair_style born/coul/wolf/gpu command :h3
 pair_style born/coul/wolf/omp command :h3
 pair_style born/coul/dsf command :h3
-pair_style born/coul/dsf/cs command :h3
 
 [Syntax:]
 
@@ -55,9 +50,7 @@ pair_coeff * * 6.08 0.317 2.340 24.18 11.51
 pair_coeff 1 1 6.08 0.317 2.340 24.18 11.51 :pre
 
 pair_style born/coul/long 10.0
-pair_style born/coul/long/cs 10.0
-pair_style born/coul/long 10.0 8.0
-pair_style born/coul/long/cs 10.0 8.0
+pair_style born/coul/long 10.0 8.
 pair_coeff * * 6.08 0.317 2.340 24.18 11.51
 pair_coeff 1 1 6.08 0.317 2.340 24.18 11.51 :pre
 
@@ -68,7 +61,6 @@ pair_coeff 1 1 6.08 0.317 2.340 24.18 11.51 :pre
 
 pair_style born/coul/wolf 0.25 10.0
 pair_style born/coul/wolf 0.25 10.0 9.0
-pair_style born/coul/wolf/cs 0.25 10.0 9.0
 pair_coeff * * 6.08 0.317 2.340 24.18 11.51
 pair_coeff 1 1 6.08 0.317 2.340 24.18 11.51 :pre
 
@@ -107,13 +99,6 @@ Wolf potential in the "coul/wolf"_pair_coul.html pair style.
 The {born/coul/dsf} style computes the Coulomb contribution with the
 damped shifted force model as in the "coul/dsf"_pair_coul.html style.
 
-Style {born/coul/long/cs} is identical to {born/coul/long} except that
-a term is added for the "core/shell model"_Howto_coreshell.html to
-allow charges on core and shell particles to be separated by r = 0.0.
-The same correction is introduced for the {born/coul/dsf/cs} style
-which is identical to {born/coul/dsf}.  And likewise for
-{born/coul/wolf/cs} style which is identical to {born/coul/wolf}.
-
 Note that these potentials are related to the "Buckingham
 potential"_pair_buck.html.
 
@@ -174,7 +159,7 @@ for the energy of the exp(), 1/r^6, and 1/r^8 portion of the pair
 interaction.
 
 The {born/coul/long} pair style supports the
-"pair_modify"_pair_modify.html table option ti tabulate the
+"pair_modify"_pair_modify.html table option to tabulate the
 short-range portion of the long-range Coulombic interaction.
 
 These styles support the pair_modify tail option for adding long-range

doc/src/pair_buck.txt

@@ -17,7 +17,6 @@ pair_style buck/coul/cut/intel command :h3
 pair_style buck/coul/cut/kk command :h3
 pair_style buck/coul/cut/omp command :h3
 pair_style buck/coul/long command :h3
-pair_style buck/coul/long/cs command :h3
 pair_style buck/coul/long/gpu command :h3
 pair_style buck/coul/long/intel command :h3
 pair_style buck/coul/long/kk command :h3
@@ -29,14 +28,14 @@ pair_style buck/coul/msm/omp command :h3
 
 pair_style style args :pre
 
-style = {buck} or {buck/coul/cut} or {buck/coul/long} or {buck/coul/long/cs} or {buck/coul/msm}
+style = {buck} or {buck/coul/cut} or {buck/coul/long} or {buck/coul/msm}
 args = list of arguments for a particular style :ul
   {buck} args = cutoff
     cutoff = global cutoff for Buckingham interactions (distance units)
   {buck/coul/cut} args = cutoff (cutoff2)
     cutoff = global cutoff for Buckingham (and Coulombic if only 1 arg) (distance units)
     cutoff2 = global cutoff for Coulombic (optional) (distance units)
-  {buck/coul/long} or {buck/coul/long/cs} args = cutoff (cutoff2)
+  {buck/coul/long} args = cutoff (cutoff2)
     cutoff = global cutoff for Buckingham (and Coulombic if only 1 arg) (distance units)
     cutoff2 = global cutoff for Coulombic (optional) (distance units)
   {buck/coul/msm} args = cutoff (cutoff2)
@@ -56,9 +55,7 @@ pair_coeff 1 1 100.0 1.5 200.0 9.0
 pair_coeff 1 1 100.0 1.5 200.0 9.0 8.0 :pre
 
 pair_style buck/coul/long 10.0
-pair_style buck/coul/long/cs 10.0
 pair_style buck/coul/long 10.0 8.0
-pair_style buck/coul/long/cs 10.0 8.0
 pair_coeff * * 100.0 1.5 200.0
 pair_coeff 1 1 100.0 1.5 200.0 9.0 :pre
 
@@ -92,10 +89,6 @@ A,C and Coulombic terms.  If two cutoffs are specified, the first is
 used as the cutoff for the A,C terms, and the second is the cutoff for
 the Coulombic term.
 
-Style {buck/coul/long/cs} is identical to {buck/coul/long} except that
-a term is added for the "core/shell model"_Howto_coreshell.html to
-allow charges on core and shell particles to be separated by r = 0.0.
-
 Note that these potentials are related to the "Born-Mayer-Huggins
 potential"_pair_born.html.
 
@@ -184,8 +177,7 @@ respa"_run_style.html command.  They do not support the {inner},
 
 [Restrictions:]
 
-The {buck/coul/long} style is part of the KSPACE package.  The
-{buck/coul/long/cs} style is part of the CORESHELL package.  They are
+The {buck/coul/long} style is part of the KSPACE package.  They are
 only enabled if LAMMPS was built with that package.  See the "Build
 package"_Build_package.html doc page for more info.
 

doc/src/pair_buck6d_coul_gauss.txt

@@ -6,8 +6,8 @@
 
 :line
 
-pair_style buck6d/coul/gauss/dsf :h3
-pair_style buck6d/coul/gauss/long :h3
+pair_style buck6d/coul/gauss/dsf command :h3
+pair_style buck6d/coul/gauss/long command :h3
 
 [Syntax:]
 

doc/src/pair_charmm.txt

@@ -8,12 +8,15 @@
 
 pair_style lj/charmm/coul/charmm command :h3
 pair_style lj/charmm/coul/charmm/intel command :h3
+pair_style lj/charmm/coul/charmm/kk command :h3
 pair_style lj/charmm/coul/charmm/omp command :h3
 pair_style lj/charmm/coul/charmm/implicit command :h3
+pair_style lj/charmm/coul/charmm/implicit/kk command :h3
 pair_style lj/charmm/coul/charmm/implicit/omp command :h3
 pair_style lj/charmm/coul/long command :h3
 pair_style lj/charmm/coul/long/gpu command :h3
 pair_style lj/charmm/coul/long/intel command :h3
+pair_style lj/charmm/coul/long/kk command :h3
 pair_style lj/charmm/coul/long/opt command :h3
 pair_style lj/charmm/coul/long/omp command :h3
 pair_style lj/charmm/coul/msm command :h3

doc/src/pair_coul_shield.txt

@@ -38,7 +38,8 @@ charge and molecule ID information is included.
 
 Where Tap(r_ij) is the taper function which provides a continuous cutoff
 (up to third derivative) for inter-atomic separations larger than r_c
-"(Maaravi)"_#Maaravi1. Here {lambda} is the shielding parameter that
+"(Leven1)"_#Leven3, "(Leven2)"_#Leven4 and "(Maaravi)"_#Maaravi1.
+Here {lambda} is the shielding parameter that
 eliminates the short-range singularity of the classical mono-polar
 electrostatic interaction expression "(Maaravi)"_#Maaravi1.
 
@@ -82,5 +83,11 @@ package"_Build_package.html doc page for more info.
 
 :line
 
+:link(Leven3)
+[(Leven1)] I. Leven, I. Azuri, L. Kronik and O. Hod, J. Chem. Phys. 140, 104106 (2014).
+
+:link(Leven4)
+[(Leven2)] I. Leven et al, J. Chem.Theory Comput. 12, 2896-905 (2016).
+
 :link(Maaravi1)
 [(Maaravi)] T. Maaravi et al, J. Phys. Chem. C 121, 22826-22835 (2017).

doc/src/pair_cs.txt

@@ -7,9 +7,11 @@
 :line
 
 pair_style born/coul/long/cs command :h3
+pair_style born/coul/long/cs/gpu command :h3
 pair_style buck/coul/long/cs command :h3
 pair_style born/coul/dsf/cs command :h3
 pair_style born/coul/wolf/cs command :h3
+pair_style born/coul/wolf/cs/gpu command :h3
 
 [Syntax:]
 
@@ -97,6 +99,38 @@ a long-range solver, thus the only correction is the addition of a
 minimal distance to avoid the possible r = 0.0 case for a
 core/shell pair.
 
+: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
+
+[Mixing, shift, table, tail correction, restart, rRESPA info]:
+
+See the corresponding doc pages for pair styles without the "cs"
+suffix to see how mixing, shifting, tabulation, tail correction,
+restarting, and rRESPA are handled by theses pair styles.
+
+:line
+
 [Restrictions:]
 
 These pair styles are part of the CORESHELL package.  They are only

doc/src/pair_dipole.txt

@@ -13,6 +13,7 @@ pair_style lj/sf/dipole/sf command :h3
 pair_style lj/sf/dipole/sf/gpu command :h3
 pair_style lj/sf/dipole/sf/omp command :h3
 pair_style lj/cut/dipole/long command :h3
+pair_style lj/cut/dipole/long/gpu command :h3
 pair_style lj/long/dipole/long command :h3
 
 [Syntax:]

doc/src/pair_eam.txt

@@ -20,6 +20,8 @@ pair_style eam/alloy/omp command :h3
 pair_style eam/alloy/opt command :h3
 pair_style eam/cd command :h3
 pair_style eam/cd/omp command :h3
+pair_style eam/cd/old command :h3
+pair_style eam/cd/old/omp command :h3
 pair_style eam/fs command :h3
 pair_style eam/fs/gpu command :h3
 pair_style eam/fs/intel command :h3
@@ -31,7 +33,7 @@ pair_style eam/fs/opt command :h3
 
 pair_style style :pre
 
-style = {eam} or {eam/alloy} or {eam/cd} or {eam/fs} :ul
+style = {eam} or {eam/alloy} or {eam/cd} or {eam/cd/old} or {eam/fs} :ul
 
 [Examples:]
 
@@ -268,7 +270,8 @@ Style {eam/cd} is similar to the {eam/alloy} style, except that it
 computes alloy pairwise interactions using the concentration-dependent
 embedded-atom method (CD-EAM).  This model can reproduce the enthalpy
 of mixing of alloys over the full composition range, as described in
-"(Stukowski)"_#Stukowski.
+"(Stukowski)"_#Stukowski. Style {eam/cd/old} is an older, slightly
+different and slower two-site formulation of the model "(Caro)"_#Caro.
 
 The pair_coeff command is specified the same as for the {eam/alloy}
 style.  However the DYNAMO {setfl} file must has two
@@ -442,3 +445,6 @@ Daw, Baskes, Phys Rev B, 29, 6443 (1984).
 :link(Stukowski)
 [(Stukowski)] Stukowski, Sadigh, Erhart, Caro; Modeling Simulation
 Materials Science & Engineering, 7, 075005 (2009).
+
+:link(Caro)
+[(Caro)] A Caro, DA Crowson, M Caro; Phys Rev Lett, 95, 075702 (2005)

doc/src/pair_edip.txt

@@ -7,6 +7,7 @@
 :line
 
 pair_style edip command :h3
+pair_style edip/omp command :h3
 pair_style edip/multi command :h3
 
 [Syntax:]

doc/src/pair_gran.txt

@@ -7,7 +7,7 @@
 :line
 
 pair_style gran/hooke command :h3
-pair_style gran/omp command :h3
+pair_style gran/hooke/omp command :h3
 pair_style gran/hooke/history command :h3
 pair_style gran/hooke/history/omp command :h3
 pair_style gran/hertz/history command :h3

doc/src/pair_gromacs.txt

@@ -8,8 +8,10 @@
 
 pair_style lj/gromacs command :h3
 pair_style lj/gromacs/gpu command :h3
+pair_style lj/gromacs/kk command :h3
 pair_style lj/gromacs/omp command :h3
 pair_style lj/gromacs/coul/gromacs command :h3
+pair_style lj/gromacs/coul/gromacs/kk command :h3
 pair_style lj/gromacs/coul/gromacs/omp command :h3
 
 [Syntax:]

doc/src/pair_hybrid.txt

@@ -7,9 +7,8 @@
 :line
 
 pair_style hybrid command :h3
-pair_style hybrid/omp command :h3
+pair_style hybrid/kk command :h3
 pair_style hybrid/overlay command :h3
-pair_style hybrid/overlay/omp command :h3
 pair_style hybrid/overlay/kk command :h3
 
 [Syntax:]

doc/src/pair_ilp_graphene_hbn.txt

@@ -25,22 +25,24 @@ pair_coeff  * * rebo                 CH.airebo   NULL NULL C
 pair_coeff  * * tersoff              BNC.tersoff B    N    NULL
 pair_coeff  * * ilp/graphene/hbn     BNCH.ILP    B    N    C
 pair_coeff  1 1 coul/shield 0.70
-pair_coeff  1 2 coul/shield 0.69498201415576216335
+pair_coeff  1 2 coul/shield 0.695
 pair_coeff  2 2 coul/shield 0.69 :pre
 
 [Description:]
 
 The {ilp/graphene/hbn} style computes the registry-dependent interlayer
-potential (ILP) potential as described in "(Leven)"_#Leven and
-"(Maaravi)"_#Maaravi2. The normals are calculated in the way as described
+potential (ILP) potential as described in "(Leven1)"_#Leven1,
+"(Leven2)"_#Leven2 and "(Maaravi)"_#Maaravi2.
+The normals are calculated in the way as described
 in "(Kolmogorov)"_#Kolmogorov2.
 
 :c,image(Eqs/pair_ilp_graphene_hbn.jpg)
 
 Where Tap(r_ij) is the taper function which provides a continuous
 cutoff (up to third derivative) for interatomic separations larger than
-r_c "(Maaravi)"_#Maaravi2. The definitions of each parameter in the above
-equation can be found in "(Leven)"_#Leven and "(Maaravi)"_#Maaravi2.
+r_c "(Maaravi)"_#Maaravi2. The definitons of each parameter in the above
+equation can be found in "(Leven1)"_#Leven1 and "(Maaravi)"_#Maaravi2.
+
 
 It is important to include all the pairs to build the neighbor list for
 calculating the normals.
@@ -61,13 +63,15 @@ NOTE: The parameters presented in the parameter file (e.g. BNCH.ILP),
 are fitted with taper function by setting the cutoff equal to 16.0
 Angstrom.  Using different cutoff or taper function should be careful.
 
-NOTE: Two new sets of parameters of ILP for two-dimensional hexagonal Materials
-are presented in "(Ouyang)"_#Ouyang1. These parameters provide a good description
-in both short- and long-range interaction regime, while the old ILP parameters
-published in "(Leven)"_#Leven and "(Maaravi)"_#Maaravi2 are only suitable for
-long-range interaction regime. This feature is essential for simulations in
-high-pressure regime (i.e., the interlayer distance smaller than the equilibrium distance).
-The benchmark tests and comparison of these parameters can be found in "(Ouyang)"_#Ouyang1.
+NOTE: Two new sets of parameters of ILP for two-dimensional hexagonal
+Materials are presented in "(Ouyang)"_#Ouyang.  These parameters provide
+a good description in both short- and long-range interaction regimes.
+While the old ILP parameters published in "(Leven2)"_#Leven2 and
+"(Maaravi)"_#Maaravi2 are only suitable for long-range interaction
+regime. This feature is essential for simulations in high pressure
+regime (i.e., the interlayer distance is smaller than the equilibrium
+distance).  The benchmark tests and comparison of these parameters can
+be found in "(Ouyang)"_#Ouyang.
 
 This potential must be used in combination with hybrid/overlay.
 Other interactions can be set to zero using pair_style {none}.
@@ -112,14 +116,17 @@ units, if your simulation does not use {metal} units.
 
 :line
 
-:link(Leven)
-[(Leven)] I. Leven et al, J. Chem.Theory Comput. 12, 2896-905 (2016)
+:link(Leven1)
+[(Leven1)] I. Leven, I. Azuri, L. Kronik and O. Hod, J. Chem. Phys. 140, 104106 (2014).
+
+:link(Leven2)
+[(Leven2)] I. Leven et al, J. Chem.Theory Comput. 12, 2896-905 (2016).
 
 :link(Maaravi2)
 [(Maaravi)] T. Maaravi et al, J. Phys. Chem. C 121, 22826-22835 (2017).
 
 :link(Kolmogorov2)
-[(Kolmogorov)] A. N. Kolmogorov, V. H. Crespi, Phys. Rev. B 71, 235415 (2005)
+[(Kolmogorov)] A. N. Kolmogorov, V. H. Crespi, Phys. Rev. B 71, 235415 (2005).
 
-:link(Ouyang1)
-[(Ouyang)] W. Ouyang, D. Mandelli,  M. Urbakh, O. Hod, arXiv:1806.09555 (2018).
+:link(Ouyang)
+[(Ouyang)] W. Ouyang, D. Mandelli, M. Urbakh and O. Hod, Nano Lett. 18, 6009-6016 (2018).

doc/src/pair_kolmogorov_crespi_full.txt

@@ -19,11 +19,11 @@ tap_flag = 0/1 to turn off/on the taper function
 
 pair_style hybrid/overlay kolmogorov/crespi/full 20.0 0
 pair_coeff * * none
-pair_coeff * * kolmogorov/crespi/full  CC.KC   C C :pre
+pair_coeff * * kolmogorov/crespi/full  CH.KC   C C :pre
 
-pair_style hybrid/overlay rebo kolmogorov/crespi/full 16.0
-pair_coeff * * rebo                    CH.airebo  C C
-pair_coeff * * kolmogorov/crespi/full  CC.KC      C C :pre
+pair_style hybrid/overlay rebo kolmogorov/crespi/full 16.0 1
+pair_coeff * * rebo                    CH.airebo    C H
+pair_coeff * * kolmogorov/crespi/full  CH_taper.KC  C H :pre
 
 [Description:]
 
@@ -38,27 +38,32 @@ forces and to include all the pairs to build the neighbor list for
 calculating the normals.  Energies are shifted so that they go
 continuously to zero at the cutoff assuming that the exponential part of
 {Vij} (first term) decays sufficiently fast.  This shift is achieved by
-the last term in the equation for {Vij} above.
+the last term in the equation for {Vij} above. This is essential only
+when the tapper function is turned off. The formula of taper function
+can be found in pair style "ilp/graphene/hbn"_pair_ilp_graphene_hbn.html.
 
 NOTE: This potential is intended for interactions between two different
 graphene layers. Therefore, to avoid interaction within the same layers,
 each layer should have a separate molecule id and is recommended to use
 "full" atom style in the data file.
 
-The parameter file (e.g. CC.KC), is intended for use with {metal}
+The parameter file (e.g. CH.KC), is intended for use with {metal}
 "units"_units.html, with energies in meV. Two additional parameters, {S},
 and {rcut} are included in the parameter file. {S} is designed to
 facilitate scaling of energies. {rcut} is designed to build the neighbor
 list for calculating the normals for each atom pair.
 
-NOTE: A new set of parameters of KC potential for hydrocarbons (CH.KC)
-is presented in "(Ouyang)"_#Ouyang2. The parameters in CH.KC provides
-a good description in both short- and long-range interaction regime,
-while the original parameters (CC.KC) published in "(Kolmogorov)"_#Kolmogorov1
-are only suitable for long-range interaction regime. 
-This feature is essential for simulations in high-pressure regime
-(i.e., the interlayer distance smaller than the equilibrium distance).
-The benchmark tests and comparison of these parameters can be found in "(Ouyang)"_#Ouyang2.
+NOTE: Two new sets of parameters of KC potential for hydrocarbons, CH.KC
+(without the taper function) and CH_taper.KC (with the taper function)
+are presented in "(Ouyang)"_#Ouyang1.  The energy for the KC potential
+with the taper function goes continuously to zero at the cutoff.  The
+parameters in both CH.KC and CH_taper.KC provide a good description in
+both short- and long-range interaction regimes. While the original
+parameters (CC.KC) published in "(Kolmogorov)"_#Kolmogorov1 are only
+suitable for long-range interaction regime.  This feature is essential
+for simulations in high pressure regime (i.e., the interlayer distance
+is smaller than the equilibrium distance).  The benchmark tests and
+comparison of these parameters can be found in "(Ouyang)"_#Ouyang1.
 
 This potential must be used in combination with hybrid/overlay.
 Other interactions can be set to zero using pair_style {none}.
@@ -84,7 +89,7 @@ package"_Build_package.html doc page for more info.
 This pair potential requires the newton setting to be {on} for pair
 interactions.
 
-The CC.KC potential file provided with LAMMPS (see the potentials
+The CH.KC potential file provided with LAMMPS (see the potentials
 folder) are parameterized for metal units.  You can use this potential
 with any LAMMPS units, but you would need to create your own custom
 CC.KC potential file with all coefficients converted to the appropriate
@@ -105,5 +110,5 @@ units.
 :link(Kolmogorov1)
 [(Kolmogorov)] A. N. Kolmogorov, V. H. Crespi, Phys. Rev. B 71, 235415 (2005)
 
-:link(Ouyang2)
-[(Ouyang)] W. Ouyang, D. Mandelli,  M. Urbakh, O. Hod, arXiv:1806.09555 (2018).
+:link(Ouyang1)
+[(Ouyang)] W. Ouyang, D. Mandelli, M. Urbakh and O. Hod, Nano Lett. 18, 6009-6016 (2018).

doc/src/pair_lj.txt

@@ -14,6 +14,7 @@ pair_style lj/cut/opt command :h3
 pair_style lj/cut/omp command :h3
 pair_style lj/cut/coul/cut command :h3
 pair_style lj/cut/coul/cut/gpu command :h3
+pair_style lj/cut/coul/cut/kk command :h3
 pair_style lj/cut/coul/cut/omp command :h3
 pair_style lj/cut/coul/debye command :h3
 pair_style lj/cut/coul/debye/gpu command :h3
@@ -26,6 +27,7 @@ pair_style lj/cut/coul/dsf/omp command :h3
 pair_style lj/cut/coul/long command :h3
 pair_style lj/cut/coul/long/cs command :h3
 pair_style lj/cut/coul/long/gpu command :h3
+pair_style lj/cut/coul/long/kk command :h3
 pair_style lj/cut/coul/long/intel command :h3
 pair_style lj/cut/coul/long/opt command :h3
 pair_style lj/cut/coul/long/omp command :h3

doc/src/pair_lj_expand.txt

@@ -8,7 +8,10 @@
 
 pair_style lj/expand command :h3
 pair_style lj/expand/gpu command :h3
+pair_style lj/expand/kk command :h3
 pair_style lj/expand/omp command :h3
+pair_style lj/expand/coul/long command :h3
+pair_style lj/expand/coul/long/gpu command :h3
 
 [Syntax:]
 
@@ -22,6 +25,11 @@ pair_style lj/expand 2.5
 pair_coeff * * 1.0 1.0 0.5
 pair_coeff 1 1 1.0 1.0 -0.2 2.0 :pre
 
+pair_style lj/expand/coul/long 2.5
+pair_style lj/expand/coul/long 2.5 4.0
+pair_coeff * * 1.0 1.0 0.5
+pair_coeff 1 1 1.0 1.0 -0.2 3.0 :pre
+
 [Description:]
 
 Style {lj/expand} computes a LJ interaction with a distance shifted by
@@ -34,11 +42,12 @@ formula:
 Rc is the cutoff which does not include the delta distance.  I.e. the
 actual force cutoff is the sum of cutoff + delta.
 
-The following coefficients must be defined for each pair of atoms
-types via the "pair_coeff"_pair_coeff.html command as in the examples
-above, or in the data file or restart files read by the
-"read_data"_read_data.html or "read_restart"_read_restart.html
-commands, or by mixing as described below:
+For all of the {lj/expand} pair styles, the following coefficients must
+be defined for each pair of atoms types via the
+"pair_coeff"_pair_coeff.html command as in the examples above, or in
+the data file or restart files read by the "read_data"_read_data.html
+or "read_restart"_read_restart.html commands, or by mixing as
+described below:
 
 epsilon (energy units)
 sigma (distance units)
@@ -48,6 +57,11 @@ cutoff (distance units) :ul
 The delta values can be positive or negative.  The last coefficient is
 optional.  If not specified, the global LJ cutoff is used.
 
+For {lj/expand/coul/long} only the LJ cutoff can be specified since a
+Coulombic cutoff cannot be specified for an individual I,J type pair.
+All type pairs use the same global Coulombic cutoff specified in the
+pair_style command.
+
 :line
 
 Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are

doc/src/pair_lj_long.txt

@@ -11,6 +11,7 @@ pair_style lj/long/coul/long/intel command :h3
 pair_style lj/long/coul/long/omp command :h3
 pair_style lj/long/coul/long/opt command :h3
 pair_style lj/long/tip4p/long command :h3
+pair_style lj/long/tip4p/long/omp command :h3
 
 [Syntax:]
 

doc/src/pair_meam_spline.txt

@@ -6,8 +6,8 @@
 
 :line
 
-pair_style meam/spline :h3
-pair_style meam/spline/omp :h3
+pair_style meam/spline command :h3
+pair_style meam/spline/omp command :h3
 
 [Syntax:]
 

doc/src/pair_meam_sw_spline.txt

@@ -6,8 +6,7 @@
 
 :line
 
-pair_style meam/sw/spline :h3
-pair_style meam/sw/spline/omp :h3
+pair_style meam/sw/spline command :h3
 
 [Syntax:]
 

doc/src/pair_nb3b_harmonic.txt

@@ -7,7 +7,6 @@
 :line
 
 pair_style nb3b/harmonic command :h3
-pair_style nb3b/harmonic/omp command :h3
 
 [Syntax:]
 
@@ -89,28 +88,6 @@ a particular simulation; LAMMPS ignores those entries.
 
 :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 pair style can only be used if LAMMPS was built with the MANYBODY

doc/src/pair_sdk.txt

@@ -13,6 +13,8 @@ pair_style lj/sdk/omp command :h3
 pair_style lj/sdk/coul/long command :h3
 pair_style lj/sdk/coul/long/gpu command :h3
 pair_style lj/sdk/coul/long/omp command :h3
+pair_style lj/sdk/coul/msm command :h3
+pair_style lj/sdk/coul/msm/omp command :h3
 
 [Syntax:]
 
@@ -35,6 +37,10 @@ pair_style lj/sdk/coul/long 10.0
 pair_style lj/sdk/coul/long 10.0 12.0
 pair_coeff 1 1 lj9_6 100.0 3.5 12.0 :pre
 
+pair_style lj/sdk/coul/msm 10.0
+pair_style lj/sdk/coul/msm 10.0 12.0
+pair_coeff 1 1 lj9_6 100.0 3.5 12.0 :pre
+
 [Description:]
 
 The {lj/sdk} styles compute a 9/6, 12/4, or 12/6 Lennard-Jones potential,
@@ -75,10 +81,10 @@ and Coulombic interactions for this type pair.  If both coefficients
 are specified, they are used as the LJ and Coulombic cutoffs for this
 type pair.
 
-For {lj/sdk/coul/long} only the LJ cutoff can be specified since a
-Coulombic cutoff cannot be specified for an individual I,J type pair.
-All type pairs use the same global Coulombic cutoff specified in the
-pair_style command.
+For {lj/sdk/coul/long} and {lj/sdk/coul/msm} only the LJ cutoff can be
+specified since a Coulombic cutoff cannot be specified for an
+individual I,J type pair.  All type pairs use the same global
+Coulombic cutoff specified in the pair_style command.
 
 :line
 

doc/src/pair_spin_magelec.txt

@@ -6,11 +6,11 @@
 
 :line
 
-pair_style spin/me command :h3
+pair_style spin/magelec command :h3
 
 [Syntax:]
 
-pair_style spin/me cutoff :pre
+pair_style spin/magelec cutoff :pre
 
 cutoff = global cutoff pair (distance in metal units) :ulb,l
 
@@ -18,8 +18,8 @@ cutoff = global cutoff pair (distance in metal units) :ulb,l
 
 [Examples:]
 
-pair_style spin/me 4.5
-pair_coeff * * me 4.5 0.00109 1.0 1.0 1.0 :pre
+pair_style spin/magelec 4.5
+pair_coeff * * magelec 4.5 0.00109 1.0 1.0 1.0 :pre
 
 [Description:]
 

doc/src/pair_spin_neel.txt

@@ -29,34 +29,36 @@ between pairs of magnetic spins:
 
 :c,image(Eqs/pair_spin_neel_interaction.jpg)
 
-where si and sj are two neighboring magnetic spins of two particles, 
+where si and sj are two neighboring magnetic spins of two particles,
 rij = ri - rj is the inter-atomic distance between the two particles,
-eij = (ri - rj)/|ri-rj| is their normalized separation vector 
-and g1, q1 and q2 are three functions defining the intensity of the
-dipolar and quadrupolar contributions, with:
+eij = (ri - rj)/|ri-rj| is their normalized separation vector and g1,
+q1 and q2 are three functions defining the intensity of the dipolar
+and quadrupolar contributions, with:
 
 :c,image(Eqs/pair_spin_neel_functions.jpg)
 
-With the functions g(rij) and q(rij) defined and fitted according to the same
-Bethe-Slater function used to fit the exchange interaction: 
+With the functions g(rij) and q(rij) defined and fitted according to
+the same Bethe-Slater function used to fit the exchange interaction:
 
 :c,image(Eqs/pair_spin_exchange_function.jpg)
 
-where a, b and d are the three constant coefficients defined in the associated 
-"pair_coeff" command.   
+where a, b and d are the three constant coefficients defined in the
+associated "pair_coeff" command.
 
-The coefficients a, b, and d need to be fitted so that the function above matches with 
-the values of the magneto-elastic constant of the materials at stake. 
+The coefficients a, b, and d need to be fitted so that the function
+above matches with the values of the magneto-elastic constant of the
+materials at stake.
 
-Examples and more explanations about this function and its parametrization are reported 
-in "(Tranchida)"_#Tranchida6. More examples of parametrization will be provided in 
-future work.
+Examples and more explanations about this function and its
+parametrization are reported in "(Tranchida)"_#Tranchida6. More
+examples of parametrization will be provided in future work.
 
-From this DM interaction, each spin i will be submitted to a magnetic torque
-omega and its associated atom to a force F (for spin-lattice calculations only). 
+From this DM interaction, each spin i will be submitted to a magnetic
+torque omega and its associated atom to a force F (for spin-lattice
+calculations only).
 
-More details about the derivation of these torques/forces are reported in
-"(Tranchida)"_#Tranchida6.
+More details about the derivation of these torques/forces are reported
+in "(Tranchida)"_#Tranchida6.
 
 :line
 

doc/src/pair_tersoff.txt

@@ -8,10 +8,10 @@
 
 pair_style tersoff command :h3
 pair_style tersoff/table command :h3
-pair_style tersoff/gpu :h3
-pair_style tersoff/intel :h3
-pair_style tersoff/kk :h3
-pair_style tersoff/omp :h3
+pair_style tersoff/gpu command :h3
+pair_style tersoff/intel command :h3
+pair_style tersoff/kk command :h3
+pair_style tersoff/omp command :h3
 pair_style tersoff/table/omp command :h3
 
 [Syntax:]

doc/src/server.txt

@@ -0,0 +1,71 @@
+"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
+
+server command :h3
+
+[Syntax:]
+
+server protocol :pre
+
+protocol = {md} or {mc} :ul
+
+[Examples:]
+  
+server md :pre
+
+[Description:]
+
+This command starts LAMMPS running in "server" mode, where it receives
+messages from a separate "client" code and responds by sending a reply
+message back to the client.  The specified {protocol} determines the
+format and content of messages LAMMPS expects to receive and how it
+responds.
+
+The "Howto client/server"_Howto_client_server.html doc page gives an
+overview of client/server coupling of LAMMPS with another code where
+one code is the "client" and sends request messages to a "server"
+code.  The server responds to each request with a reply message.  This
+enables the two codes to work in tandem to perform a simulation.
+
+When this command is invoked, LAMMPS will run in server mode in an
+endless loop, waiting for messages from the client code.  The client
+signals when it is done sending messages to LAMMPS, at which point the
+loop will exit, and the remainder of the LAMMPS script will be
+processed.
+
+The {protocol} argument defines the format and content of messages
+that will be exchanged between the two codes.  The current options
+are:
+
+"md"_server_md.html = run dynamics with another code
+"mc"_server_mc.html = perform Monte Carlo moves with another code :ul
+
+For protocol {md}, LAMMPS can be either a client (via the "fix
+client/md"_fix_client_md.html command) or server.  See the "server
+md"_server_md.html doc page for details on the protocol.
+
+For protocol {mc}, LAMMPS can be the server.  See the "server
+mc"_server_mc.html doc page for details on the protocol.
+
+:line
+
+[Restrictions:]
+
+This command is part of the MESSAGE package.  It is only enabled if
+LAMMPS was built with that package.  See the "Build
+package"_Build_package.html doc page for more info.
+
+A script that uses this command must also use the
+"message"_message.html command to setup the messaging protocol with
+the other client code.
+
+[Related commands:]
+
+"message"_message.html, "fix client/md"_fix_client_md.html
+
+[Default:] none

doc/src/server_mc.txt

@@ -0,0 +1,116 @@
+"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
+
+server mc command :h3
+
+[Syntax:]
+
+server mc :pre
+
+mc = the protocol argument to the "server"_server.html command
+
+[Examples:]
+  
+server mc :pre
+
+[Description:]
+
+This command starts LAMMPS running in "server" mode, where it will
+expect messages from a separate "client" code that match the {mc}
+protocol for format and content explained below.  For each message
+LAMMPS receives it will send a message back to the client.
+
+The "Howto client/server"_Howto_client_server.html doc page gives an
+overview of client/server coupling of LAMMPS with another code where
+one code is the "client" and sends request messages to a "server"
+code.  The server responds to each request with a reply message.  This
+enables the two codes to work in tandem to perform a simulation.
+
+When this command is invoked, LAMMPS will run in server mode in an
+endless loop, waiting for messages from the client code.  The client
+signals when it is done sending messages to LAMMPS, at which point the
+loop will exit, and the remainder of the LAMMPS script will be
+processed.
+
+The "server"_server.html doc page gives other options for using LAMMPS
+See an example of how this command is used in
+examples/COUPLE/lammps_mc/in.server.
+
+:line
+
+When using this command, LAMMPS (as the server code) receives
+instructions from a Monte Carlo (MC) driver to displace random atoms,
+compute the energy before and after displacement, and run dynamics to
+equilibrate the system.  
+
+The MC driver performs the random displacements on random atoms,
+accepts or rejects the move in an MC sense, and orchestrates the MD
+runs.
+
+The format and content of the exchanged messages are explained here in
+a conceptual sense.  Python-style pseudo code for the library calls to
+the CSlib is shown, which performs the actual message exchange between
+the two codes.  See the "CSlib website"_http://cslib.sandia.gov doc
+pages for more details on the actual library syntax.  The "cs" object
+in this pseudo code is a pointer to an instance of the CSlib.
+
+See the src/MESSAGE/server_mc.cpp file for details on how LAMMPS uses
+these messages.  See the examples/COUPLE/lammmps_mc/mc.cpp file for an
+example of how an MC driver code can use these messages.
+
+Define NATOMS=1, EINIT=2, DISPLACE=3, ACCEPT=4, RUN=5.
+
+[Client sends one of these kinds of message]:
+
+cs->send(NATOMS,0)      # msgID = 1 with no fields :pre
+
+cs->send(EINIT,0)       # msgID = 2 with no fields :pre
+
+cs->send(DISPLACE,2)    # msgID = 3 with 2 fields
+cs->pack_int(1,ID)        # 1st field = ID of atom to displace
+cs->pack(2,3,xnew)      # 2nd field = new xyz coords of displaced atom :pre
+
+cs->send(ACCEPT,1)      # msgID = 4 with 1 field
+cs->pack_int(1,flag)    # 1st field = accept/reject flag :pre
+
+cs->send(RUN,1)         # msgID = 5 with 1 field
+cs->pack_int(1,nsteps)  # 1st field = # of timesteps to run MD :pre
+
+[Server replies]:
+
+cs->send(NATOMS,1)      # msgID = 1 with 1 field 
+cs->pack_int(1,natoms)  # 1st field = number of atoms :pre
+
+cs->send(EINIT,2)         # msgID = 2 with 2 fields
+cs->pack_double(1,poteng) # 1st field = potential energy of system
+cs->pack(2,3*natoms,x)    # 2nd field = 3N coords of Natoms :pre
+
+cs->send(DISPLACE,1)      # msgID = 3 with 1 field
+cs->pack_double(1,poteng) # 1st field = new potential energy of system :pre
+
+cs->send(ACCEPT,0)      # msgID = 4 with no fields :pre
+
+cs->send(RUN,0)         # msgID = 5 with no fields :pre
+
+:line
+
+[Restrictions:]
+
+This command is part of the MESSAGE package.  It is only enabled if
+LAMMPS was built with that package.  See the "Build
+package"_Build_package.html doc page for more info.
+
+A script that uses this command must also use the
+"message"_message.html command to setup the messaging protocol with
+the other client code.
+
+[Related commands:]
+
+"message"_message.html
+
+[Default:] none