patch 5Feb18

USER-INTEL: Adding missing backslash for two Makefiles using Intel co…

cmake/CMakeLists.txt

@@ -6,8 +6,8 @@ cmake_minimum_required(VERSION 3.1)
 
 project(lammps)
 set(SOVERSION 0)
-set(LAMMPS_SOURCE_DIR ${CMAKE_SOURCE_DIR}/../src)
-set(LAMMPS_LIB_SOURCE_DIR ${CMAKE_SOURCE_DIR}/../lib)
+set(LAMMPS_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../src)
+set(LAMMPS_LIB_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../lib)
 set(LAMMPS_LIB_BINARY_DIR ${CMAKE_BINARY_DIR}/lib)
 
 #To not conflict with old Makefile build system, we build everything here
@@ -16,20 +16,18 @@ file(GLOB LMP_SOURCES ${LAMMPS_SOURCE_DIR}/main.cpp)
 list(REMOVE_ITEM LIB_SOURCES ${LMP_SOURCES})
 
 # Cmake modules/macros are in a subdirectory to keep this file cleaner
-set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/Modules)
+set(CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/Modules)
 
 if(NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CXX_FLAGS)
   #release comes with -O3 by default
   set(CMAKE_BUILD_TYPE Release CACHE STRING "Choose the type of build, options are: None Debug Release RelWithDebInfo MinSizeRel." FORCE)
 endif(NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CXX_FLAGS)
 
-foreach(STYLE_FILE style_angle.h style_atom.h style_body.h style_bond.h style_command.h style_compute.h style_dihedral.h style_dump.h
-             style_fix.h style_improper.h style_integrate.h style_kspace.h style_minimize.h style_nbin.h style_npair.h style_nstencil.h
-             style_ntopo.h style_pair.h style_reader.h style_region.h)
-  if(EXISTS ${LAMMPS_SOURCE_DIR}/${STYLE_FILE})
-    message(FATAL_ERROR "There is a ${STYLE_FILE} in ${LAMMPS_SOURCE_DIR}, please clean up the source directory first")
-  endif()
-endforeach()
+# remove any style headers in the src dir
+file(GLOB SRC_STYLE_FILES ${LAMMPS_SOURCE_DIR}/style_*.h)
+if(SRC_STYLE_FILES)
+  file(REMOVE ${SRC_STYLE_FILES})
+endif()
 
 enable_language(CXX)
 
@@ -39,14 +37,22 @@ enable_language(CXX)
 #####################################################################
 include(CheckCCompilerFlag)
 
+if (${CMAKE_CXX_COMPILER_ID} STREQUAL "Intel")
+  set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -restrict")
+endif()
+
 ########################################################################
 # User input options                                                   #
 ########################################################################
 option(BUILD_SHARED_LIBS "Build shared libs" OFF)
-option(INSTALL_LIB "Install lammps library and header" ON)
+if(BUILD_SHARED_LIBS) # for all pkg libs, mpi_stubs and linalg
+  set(CMAKE_POSITION_INDEPENDENT_CODE ON)
+endif()
 include(GNUInstallDirs)
 
 set(LAMMPS_LINK_LIBS)
+set(LAMMPS_DEPS)
+set(LAMMPS_API_DEFINES)
 option(ENABLE_MPI "Build MPI version" OFF)
 if(ENABLE_MPI)
   find_package(MPI REQUIRED)
@@ -58,13 +64,15 @@ if(ENABLE_MPI)
   endif()
 else()
   file(GLOB MPI_SOURCES ${LAMMPS_SOURCE_DIR}/STUBS/mpi.c)
-  list(APPEND LIB_SOURCES ${MPI_SOURCES})
+  add_library(mpi_stubs STATIC ${MPI_SOURCES})
   include_directories(${LAMMPS_SOURCE_DIR}/STUBS)
+  list(APPEND LAMMPS_LINK_LIBS mpi_stubs)
 endif()
 
 set(LAMMPS_SIZE_LIMIT "LAMMPS_SMALLBIG" CACHE STRING "Lammps size limit")
 set_property(CACHE LAMMPS_SIZE_LIMIT PROPERTY STRINGS LAMMPS_SMALLBIG LAMMPS_BIGBIG LAMMPS_SMALLSMALL)
 add_definitions(-D${LAMMPS_SIZE_LIMIT})
+set(LAMMPS_API_DEFINES "${LAMMPS_API_DEFINES} -D${LAMMPS_SIZE_LIMIT}")
 
 set(LAMMPS_MEMALIGN "64" CACHE STRING "enables the use of the posix_memalign() call instead of malloc() when large chunks or memory are allocated by LAMMPS")
 add_definitions(-DLAMMPS_MEMALIGN=${LAMMPS_MEMALIGN})
@@ -72,6 +80,13 @@ add_definitions(-DLAMMPS_MEMALIGN=${LAMMPS_MEMALIGN})
 option(LAMMPS_EXCEPTIONS "enable the use of C++ exceptions for error messages (useful for library interface)" OFF)
 if(LAMMPS_EXCEPTIONS)
   add_definitions(-DLAMMPS_EXCEPTIONS)
+  set(LAMMPS_API_DEFINES "${LAMMPS_API_DEFINES} -DLAMMPS_EXCEPTIONS")
+endif()
+
+set(LAMMPS_MACHINE "" CACHE STRING "Suffix to append to lmp binary and liblammps (WON'T enable any features automatically")
+mark_as_advanced(LAMMPS_MACHINE)
+if(LAMMPS_MACHINE)
+  set(LAMMPS_MACHINE "_${LAMMPS_MACHINE}")
 endif()
 
 option(CMAKE_VERBOSE_MAKEFILE "Verbose makefile" OFF)
@@ -85,12 +100,12 @@ option(ENABLE_ALL "Build all default packages" OFF)
 set(DEFAULT_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GRANULAR
   KSPACE MANYBODY MC MEAM MISC MOLECULE PERI QEQ
   REAX REPLICA RIGID SHOCK SNAP SRD)
-set(OTHER_PACKAGES KIM PYTHON MSCG MPIIO VORONOI POEMS
-   USER-ATC USER-AWPMD USER-CGDNA
+set(OTHER_PACKAGES KIM PYTHON MSCG MPIIO VORONOI POEMS LATTE
+  USER-ATC USER-AWPMD 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-MOLFILE USER-NETCDF USER-PHONON USER-QTB USER-REAXC USER-SMD 
-  USER-SMTBQ USER-SPH USER-TALLY USER-VTK USER-QUIP USER-QMMM)
+  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)
 foreach(PKG ${DEFAULT_PACKAGES})
   option(ENABLE_${PKG} "Build ${PKG} Package" ${ENABLE_ALL})
@@ -120,8 +135,10 @@ endif()
 ######################################################
 # packages with special compiler needs or external libs
 ######################################################
-if(ENABLE_REAX OR ENABLE_MEAM OR ENABLE_USER-QUIP OR ENABLE_USER-QMMM)
+if(ENABLE_REAX OR ENABLE_MEAM OR ENABLE_USER-QUIP OR ENABLE_USER-QMMM OR ENABLE_LATTE)
   enable_language(Fortran)
+  include(CheckFortranCompilerFlag)
+  check_Fortran_compiler_flag("-fno-second-underscore" FC_HAS_NO_SECOND_UNDERSCORE)
 endif()
 
 if(ENABLE_KOKKOS OR ENABLE_MSCG)
@@ -153,21 +170,18 @@ if(ENABLE_KSPACE)
   endif()
 endif()
 
-if(ENABLE_MISC)
-  option(LAMMPS_XDR "include XDR compatibility files for doing particle dumps in XTC format" OFF)
-  if(LAMMPS_XDR)
-    add_definitions(-DLAMMPS_XDR)
-  endif()
-endif()
-
-if(ENABLE_MSCG OR ENABLE_USER-ATC OR ENABLE_USER-AWPMD OR ENABLE_USER-QUIP)
+if(ENABLE_MSCG OR ENABLE_USER-ATC OR ENABLE_USER-AWPMD OR ENABLE_USER-QUIP OR ENABLE_LATTE)
   find_package(LAPACK)
-  if(LAPACK_FOUND)
-    list(APPEND LAMMPS_LINK_LIBS ${LAPACK_LIBRARIES})
-  else()
+  if(NOT LAPACK_FOUND)
     enable_language(Fortran)
     file(GLOB LAPACK_SOURCES ${LAMMPS_LIB_SOURCE_DIR}/linalg/*.f)
-    list(APPEND LIB_SOURCES ${LAPACK_SOURCES})
+    add_library(linalg STATIC ${LAPACK_SOURCES})
+    include(CheckFortranCompilerFlag)
+    check_Fortran_compiler_flag("-fno-second-underscore" FC_HAS_NO_SECOND_UNDERSCORE)
+    if(FC_HAS_NO_SECOND_UNDERSCORE)
+      target_compile_options(linalg PRIVATE -fno-second-underscore)
+    endif()
+    set(LAPACK_LIBRARIES linalg)
   endif()
 endif()
 
@@ -177,14 +191,13 @@ if(ENABLE_PYTHON)
   add_definitions(-DLMP_PYTHON)
   include_directories(${PYTHON_INCLUDE_DIR})
   list(APPEND LAMMPS_LINK_LIBS ${PYTHON_LIBRARY})
+  if(BUILD_SHARED_LIBS)
     if(NOT PYTHON_INSTDIR)
       execute_process(COMMAND ${PYTHON_EXECUTABLE}
         -c "import distutils.sysconfig as cg; print(cg.get_python_lib(1,0,prefix='${CMAKE_INSTALL_PREFIX}'))"
         OUTPUT_VARIABLE PYTHON_INSTDIR OUTPUT_STRIP_TRAILING_WHITESPACE)
     endif()
-  install(FILES ${CMAKE_SOURCE_DIR}/../python/lammps.py DESTINATION ${PYTHON_INSTDIR})
-  if(NOT BUILD_SHARED_LIBS)
-    message(FATAL_ERROR "Python package need lammps to be build shared, use -DBUILD_SHARED_LIBS=ON")
+    install(FILES ${CMAKE_CURRENT_SOURCE_DIR}/../python/lammps.py DESTINATION ${PYTHON_INSTDIR})
   endif()
 endif()
 
@@ -221,8 +234,29 @@ if(ENABLE_VORONOI)
   list(APPEND LAMMPS_LINK_LIBS ${VORO_LIBRARIES})
 endif()
 
+if(ENABLE_LATTE)
+  find_package(LATTE QUIET)
+  if(NOT LATTE_FOUND)
+    message(STATUS "LATTE not found - we will build our own")
+    include(ExternalProject)
+    ExternalProject_Add(latte_build
+      URL https://github.com/lanl/LATTE/archive/v1.0.1.tar.gz
+      URL_MD5 5137e28cb1a64444bd571c98c98a6eee
+      SOURCE_SUBDIR cmake
+      CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR> -DCMAKE_POSITION_INDEPENDENT_CODE=${CMAKE_POSITION_INDEPENDENT_CODE}
+      )
+    ExternalProject_get_property(latte_build INSTALL_DIR)
+    set(LATTE_LIBRARIES ${INSTALL_DIR}/${CMAKE_INSTALL_LIBDIR}/liblatte.a)
+    list(APPEND LAMMPS_DEPS latte_build)
+  endif()
+  list(APPEND LAMMPS_LINK_LIBS ${LATTE_LIBRARIES} ${LAPACK_LIBRARIES} ${CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES})
+endif()
+
 if(ENABLE_USER-MOLFILE)
-  list(APPEND LAMMPS_LINK_LIBS ${CMAKE_DL_LIBS})
+  add_library(molfile INTERFACE)
+  target_include_directories(molfile INTERFACE ${LAMMPS_LIB_SOURCE_DIR}/molfile)
+  target_link_libraries(molfile INTERFACE ${CMAKE_DL_LIBS})
+  list(APPEND LAMMPS_LINK_LIBS molfile)
 endif()
 
 if(ENABLE_USER-NETCDF)
@@ -239,7 +273,7 @@ endif()
 
 if(ENABLE_USER-QUIP)
   find_package(QUIP REQUIRED)
-  list(APPEND LAMMPS_LINK_LIBS ${QUIP_LIBRARIES} ${CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES})
+  list(APPEND LAMMPS_LINK_LIBS ${QUIP_LIBRARIES} ${LAPACK_LIBRARIES} ${CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES})
 endif()
 
 if(ENABLE_USER-QMMM)
@@ -248,17 +282,6 @@ if(ENABLE_USER-QMMM)
   list(APPEND LAMMPS_LINK_LIBS ${QE_LIBRARIES} ${CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES})
 endif()
 
-if(ENABLE_USER-AWPMD)
-  include_directories(${LAMMPS_LIB_SOURCE_DIR}/awpmd/systems/interact
-    ${LAMMPS_LIB_SOURCE_DIR}/awpmd/ivutils/include)
-endif()
-
-if(ENABLE_USER-H5MD)
-  find_package(HDF5 REQUIRED)
-  list(APPEND LAMMPS_LINK_LIBS ${HDF5_LIBRARIES})
-  include_directories(${HDF5_INCLUDE_DIRS} ${LAMMPS_LIB_SOURCE_DIR}/h5md/include)
-endif()
-
 if(ENABLE_USER-VTK)
   find_package(VTK REQUIRED NO_MODULE)
   include(${VTK_USE_FILE})
@@ -289,13 +312,11 @@ if(ENABLE_MSCG)
       WORKING_DIRECTORY ${LAMMPS_LIB_BINARY_DIR}/mscg)
   endif()
   file(GLOB MSCG_SOURCES ${LAMMPS_LIB_MSCG_BIN_DIR}/*.cpp)
-  list(APPEND LIB_SOURCES ${MSCG_SOURCES})
-  foreach(MSCG_SOURCE ${MSCG_SOURCES})
-    set_property(SOURCE ${MSCG_SOURCE} APPEND PROPERTY COMPILE_DEFINITIONS
-      DIMENSION=3 _exclude_gromacs=1)
-  endforeach()
-  include_directories(${LAMMPS_LIB_MSCG_BIN_DIR} ${GSL_INCLUDE_DIRS})
-  list(APPEND LAMMPS_LINK_LIBS ${GSL_LIBRARIES})
+  add_library(mscg STATIC ${MSCG_SOURCES})
+  list(APPEND LAMMPS_LINK_LIBS mscg)
+  target_compile_options(mscg PRIVATE -DDIMENSION=3 -D_exclude_gromacs=1)
+  target_include_directories(mscg PUBLIC ${LAMMPS_LIB_MSCG_BIN_DIR})
+  target_link_libraries(mscg ${GSL_LIBRARIES} ${LAPACK_LIBRARIES})
 endif()
 
 ########################################################################
@@ -330,13 +351,27 @@ RegisterStyles(${LAMMPS_SOURCE_DIR})
 # add sources of enabled packages
 ############################################
 foreach(PKG ${DEFAULT_PACKAGES} ${OTHER_PACKAGES})
-  if(ENABLE_${PKG})
   set(${PKG}_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/${PKG})
 
+  # ignore PKG files which were manually installed in src folder
+  # headers are ignored during RegisterStyles
+  file(GLOB ${PKG}_SOURCES ${${PKG}_SOURCES_DIR}/*.cpp)
+  file(GLOB ${PKG}_HEADERS ${${PKG}_SOURCES_DIR}/*.h)
+
+  foreach(PKG_FILE in ${${PKG}_SOURCES})
+      get_filename_component(FNAME ${PKG_FILE} NAME)
+      list(REMOVE_ITEM LIB_SOURCES ${LAMMPS_SOURCE_DIR}/${FNAME})
+  endforeach()
+
+  foreach(PKG_FILE in ${${PKG}_HEADERS})
+      get_filename_component(FNAME ${PKG_FILE} NAME)
+      DetectAndRemovePackageHeader(${LAMMPS_SOURCE_DIR}/${FNAME})
+  endforeach()
+
+  if(ENABLE_${PKG})
     # detects styles in package and adds them to global list
     RegisterStyles(${${PKG}_SOURCES_DIR})
 
-    file(GLOB ${PKG}_SOURCES ${${PKG}_SOURCES_DIR}/*.cpp)
     list(APPEND LIB_SOURCES ${${PKG}_SOURCES})
     include_directories(${${PKG}_SOURCES_DIR})
   endif()
@@ -346,17 +381,57 @@ endforeach()
 # add lib sources of (simple) enabled packages
 ############################################
 foreach(SIMPLE_LIB REAX MEAM POEMS USER-ATC USER-AWPMD USER-COLVARS USER-H5MD
-  USER-MOLFILE USER-QMMM)
+  USER-QMMM)
   if(ENABLE_${SIMPLE_LIB})
-    string(REGEX REPLACE "^USER-" "" SIMPLE_LIB "${SIMPLE_LIB}")
-    string(TOLOWER "${SIMPLE_LIB}" INC_DIR)
-    file(GLOB_RECURSE ${SIMPLE_LIB}_SOURCES ${LAMMPS_LIB_SOURCE_DIR}/${INC_DIR}/*.F
-      ${LAMMPS_LIB_SOURCE_DIR}/${INC_DIR}/*.c ${LAMMPS_LIB_SOURCE_DIR}/${INC_DIR}/*.cpp)
-    list(APPEND LIB_SOURCES ${${SIMPLE_LIB}_SOURCES})
-    include_directories(${LAMMPS_LIB_SOURCE_DIR}/${INC_DIR})
+    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)
+    add_library(${PKG_LIB} STATIC ${${PKG_LIB}_SOURCES})
+    list(APPEND LAMMPS_LINK_LIBS ${PKG_LIB})
+    if(PKG_LIB STREQUAL awpmd)
+      target_include_directories(awpmd PUBLIC ${LAMMPS_LIB_SOURCE_DIR}/awpmd/systems/interact ${LAMMPS_LIB_SOURCE_DIR}/awpmd/ivutils/include)
+    elseif(PKG_LIB STREQUAL h5md)
+      target_include_directories(h5md PUBLIC ${LAMMPS_LIB_SOURCE_DIR}/h5md/include)
+    elseif(PKG_LIB STREQUAL colvars)
+      target_compile_options(colvars PRIVATE -DLEPTON)
+      target_include_directories(colvars PRIVATE ${LAMMPS_LIB_SOURCE_DIR}/colvars/lepton/include)
+      target_include_directories(colvars PUBLIC ${LAMMPS_LIB_SOURCE_DIR}/colvars)
+    else()
+      target_include_directories(${PKG_LIB} PUBLIC ${LAMMPS_LIB_SOURCE_DIR}/${PKG_LIB})
+    endif()
   endif()
 endforeach()
 
+if(ENABLE_USER-AWPMD)
+  target_link_libraries(awpmd ${LAPACK_LIBRARIES})
+endif()
+
+if(ENABLE_USER-ATC)
+  target_link_libraries(atc ${LAPACK_LIBRARIES})
+endif()
+
+if(ENABLE_USER-H5MD)
+  find_package(HDF5 REQUIRED)
+  target_link_libraries(h5md ${HDF5_LIBRARIES})
+  target_include_directories(h5md PRIVATE ${HDF5_INCLUDE_DIRS})
+endif()
+
+if(ENABLE_MEAM AND FC_HAS_NO_SECOND_UNDERSCORE)
+  foreach(FSRC ${meam_SOURCES})
+    string(REGEX REPLACE "^.*\\." "" FEXT "${FSRC}")
+    list(FIND CMAKE_Fortran_SOURCE_FILE_EXTENSIONS "${FEXT}" FINDEX)
+    if(FINDEX GREATER -1)
+      set_property(SOURCE ${FSRC} APPEND PROPERTY COMPILE_FLAGS "-fno-second-underscore")
+    endif()
+  endforeach()
+endif()
+
+if(ENABLE_REAX AND FC_HAS_NO_SECOND_UNDERSCORE)
+  target_compile_options(reax PRIVATE -fno-second-underscore)
+endif()
+
+
 ######################################################################
 # packages which selectively include variants based on enabled styles
 # e.g. accelerator packages
@@ -401,6 +476,8 @@ if(ENABLE_KOKKOS)
                          ${KOKKOS_PKG_SOURCES_DIR}/neigh_list_kokkos.cpp
                          ${KOKKOS_PKG_SOURCES_DIR}/neigh_bond_kokkos.cpp
                          ${KOKKOS_PKG_SOURCES_DIR}/fix_nh_kokkos.cpp
+                         ${KOKKOS_PKG_SOURCES_DIR}/nbin_kokkos.cpp
+                         ${KOKKOS_PKG_SOURCES_DIR}/npair_kokkos.cpp
                          ${KOKKOS_PKG_SOURCES_DIR}/domain_kokkos.cpp
                          ${KOKKOS_PKG_SOURCES_DIR}/modify_kokkos.cpp)
   set_property(GLOBAL PROPERTY "KOKKOS_PKG_SOURCES" "${KOKKOS_PKG_SOURCES}")
@@ -408,6 +485,17 @@ if(ENABLE_KOKKOS)
   # detects styles which have KOKKOS version
   RegisterStylesExt(${KOKKOS_PKG_SOURCES_DIR} kokkos KOKKOS_PKG_SOURCES)
 
+  # register kokkos-only styles
+  RegisterNBinStyle(${KOKKOS_PKG_SOURCES_DIR}/nbin_kokkos.h)
+  RegisterNPairStyle(${KOKKOS_PKG_SOURCES_DIR}/npair_kokkos.h)
+
+  if(ENABLE_USER-DPD)
+    get_property(KOKKOS_PKG_SOURCES GLOBAL PROPERTY KOKKOS_PKG_SOURCES)
+    list(APPEND KOKKOS_PKG_SOURCES ${KOKKOS_PKG_SOURCES_DIR}/npair_ssa_kokkos.cpp)
+    RegisterNPairStyle(${KOKKOS_PKG_SOURCES_DIR}/npair_ssa_kokkos.h)
+    set_property(GLOBAL PROPERTY "KOKKOS_PKG_SOURCES" "${KOKKOS_PKG_SOURCES}")
+  endif()
+
   get_property(KOKKOS_PKG_SOURCES GLOBAL PROPERTY KOKKOS_PKG_SOURCES)
 
   list(APPEND LIB_SOURCES ${KOKKOS_PKG_SOURCES})
@@ -453,57 +541,125 @@ if(ENABLE_USER-INTEL)
 endif()
 
 if(ENABLE_GPU)
+    set(GPU_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/GPU)
+    set(GPU_SOURCES ${GPU_SOURCES_DIR}/gpu_extra.h
+                    ${GPU_SOURCES_DIR}/fix_gpu.h
+                    ${GPU_SOURCES_DIR}/fix_gpu.cpp)
+
+    set(GPU_API "OpenCL" CACHE STRING "API used by GPU package")
+    set_property(CACHE GPU_API PROPERTY STRINGS OpenCL CUDA)
+
+    set(GPU_PREC "SINGLE_DOUBLE" CACHE STRING "LAMMPS GPU precision size")
+    set_property(CACHE GPU_PREC PROPERTY STRINGS SINGLE_DOUBLE SINGLE_SINGLE DOUBLE_DOUBLE)
+
+    file(GLOB GPU_LIB_SOURCES ${LAMMPS_LIB_SOURCE_DIR}/gpu/*.cpp)
+    file(MAKE_DIRECTORY ${LAMMPS_LIB_BINARY_DIR}/gpu)
+
+    if(GPU_API STREQUAL "CUDA")
       find_package(CUDA REQUIRED)
       find_program(BIN2C bin2c)
       if(NOT BIN2C)
         message(FATAL_ERROR "Couldn't find bin2c, use -DBIN2C helping cmake to find it.")
       endif()
-    include_directories(${CUDA_INCLUDE_DIRS})
-    list(APPEND LAMMPS_LINK_LIBS ${CUDA_LIBRARIES} ${CUDA_CUDA_LIBRARY})
-    set(GPU_PREC "SINGLE_DOUBLE" CACHE STRING "Lammps gpu precision size")
-    set_property(CACHE GPU_PREC PROPERTY STRINGS SINGLE_DOUBLE SINGLE_SINGLE DOUBLE_DOUBLE)
-    add_definitions(-D_${GPU_PREC})
-    add_definitions(-DNV_KERNEL -DUCL_CUDADR)
       option(CUDPP_OPT "Enable CUDPP_OPT" ON)
 
-    set(GPU_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/GPU)
-    set(GPU_SOURCES ${GPU_SOURCES_DIR}/gpu_extra.h)
+      set(GPU_ARCH "sm_30" CACHE STRING "LAMMPS GPU CUDA SM architecture")
+      set_property(CACHE GPU_ARCH PROPERTY STRINGS sm_10 sm_20 sm_30 sm_60)
 
-    set_property(GLOBAL PROPERTY "GPU_SOURCES" "${GPU_SOURCES}")
+      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)
 
-    # detects styles which have GPU version
-    RegisterStylesExt(${GPU_SOURCES_DIR} opt GPU_SOURCES)
+      cuda_include_directories(${LAMMPS_LIB_SOURCE_DIR}/gpu ${LAMMPS_LIB_BINARY_DIR}/gpu)
 
-    get_property(GPU_SOURCES GLOBAL PROPERTY GPU_SOURCES)
-    
-    file(GLOB GPU_LIB_SOURCES ${LAMMPS_LIB_SOURCE_DIR}/gpu/*.cpp)
-    file(GLOB GPU_LIB_CU ${LAMMPS_LIB_SOURCE_DIR}/gpu/*.cu ${CMAKE_SOURCE_DIR}/gpu/*.cu)
-    file(GLOB_RECURSE GPU_NOT_LIB_CU ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_pppm.cu)
-    list(REMOVE_ITEM GPU_LIB_CU ${GPU_NOT_LIB_CU})
-    include_directories(${GPU_SOURCES_DIR} ${LAMMPS_LIB_SOURCE_DIR}/gpu ${LAMMPS_LIB_BINARY_DIR}/gpu)
       if(CUDPP_OPT)
-      include_directories(${LAMMPS_LIB_SOURCE_DIR}/gpu/cudpp_mini)
-      add_definitions(-DCUDPP_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)
       endif()
-    cuda_compile(GPU_OBJS ${GPU_LIB_CU} ${GPU_LIB_CUDPP_CU} OPTIONS $<$<BOOL:${BUILD_SHARED_LIBS}>:-Xcompiler=-fPIC>)    
-    file(MAKE_DIRECTORY ${LAMMPS_LIB_BINARY_DIR}/gpu)
-    foreach(CU_OBJ ${GPU_OBJS})
+
+      cuda_compile_cubin(GPU_GEN_OBJS ${GPU_LIB_CU} OPTIONS
+                   -DUNIX -O3 -Xptxas -v --use_fast_math -DNV_KERNEL -DUCL_CUDADR -arch=${GPU_ARCH} -D_${GPU_PREC})
+
+      cuda_compile(GPU_OBJS ${GPU_LIB_CUDPP_CU} OPTIONS $<$<BOOL:${BUILD_SHARED_LIBS}>:-Xcompiler=-fPIC>
+                   -DUNIX -O3 -Xptxas -v --use_fast_math -DUCL_CUDADR -arch=${GPU_ARCH} -D_${GPU_PREC})
+
+      foreach(CU_OBJ ${GPU_GEN_OBJS})
         get_filename_component(CU_NAME ${CU_OBJ} NAME_WE)
         string(REGEX REPLACE "^.*_lal_" "" CU_NAME "${CU_NAME}")
         add_custom_command(OUTPUT ${LAMMPS_LIB_BINARY_DIR}/gpu/${CU_NAME}_cubin.h
           COMMAND ${BIN2C} -c -n ${CU_NAME} ${CU_OBJ} > ${LAMMPS_LIB_BINARY_DIR}/gpu/${CU_NAME}_cubin.h
           DEPENDS ${CU_OBJ}
           COMMENT "Generating ${CU_NAME}_cubin.h")
-      list(APPEND LIB_SOURCES ${LAMMPS_LIB_BINARY_DIR}/gpu/${CU_NAME}_cubin.h)
-      if(${CU_NAME} STREQUAL "pppm_d") #pppm_d doesn't get linked into the lib
-        set(CU_FORBIDDEN_OBJ "${CU_OBJ}") 
-      endif()
+        list(APPEND GPU_LIB_SOURCES ${LAMMPS_LIB_BINARY_DIR}/gpu/${CU_NAME}_cubin.h)
       endforeach()
-    list(REMOVE_ITEM GPU_OBJS "${CU_FORBIDDEN_OBJ}")
-    list(APPEND LIB_SOURCES ${GPU_SOURCES} ${GPU_LIB_SOURCES} ${GPU_LIB_CUDPP_SOURCES} ${GPU_OBJS})
       set_directory_properties(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES "${LAMMPS_LIB_BINARY_DIR}/gpu/*_cubin.h")
+
+
+      add_library(gpu STATIC ${GPU_LIB_SOURCES} ${GPU_LIB_CUDPP_SOURCES} ${GPU_OBJS})
+      target_link_libraries(gpu ${CUDA_LIBRARIES} ${CUDA_CUDA_LIBRARY})
+      target_include_directories(gpu PRIVATE ${LAMMPS_LIB_BINARY_DIR}/gpu ${CUDA_INCLUDE_DIRS})
+      target_compile_definitions(gpu PRIVATE -D_${GPU_PREC} -DMPI_GERYON -DUCL_NO_EXIT)
+      if(CUDPP_OPT)
+        target_include_directories(gpu PRIVATE ${LAMMPS_LIB_SOURCE_DIR}/gpu/cudpp_mini)
+        target_compile_definitions(gpu PRIVATE -DUSE_CUDPP)
+      endif()
+
+      list(APPEND LAMMPS_LINK_LIBS gpu)
+
+      add_executable(nvc_get_devices ${LAMMPS_LIB_SOURCE_DIR}/gpu/geryon/ucl_get_devices.cpp)
+      target_compile_definitions(nvc_get_devices PRIVATE -DUCL_CUDADR)
+      target_link_libraries(nvc_get_devices PRIVATE ${CUDA_LIBRARIES} ${CUDA_CUDA_LIBRARY})
+      target_include_directories(nvc_get_devices PRIVATE ${CUDA_INCLUDE_DIRS})
+
+
+    elseif(GPU_API STREQUAL "OpenCL")
+      find_package(OpenCL REQUIRED)
+      set(OCL_TUNE "GENERIC" CACHE STRING "OpenCL Device Tuning")
+      set_property(CACHE OCL_TUNE PROPERTY STRINGS INTEL FERMI KEPLER CYPRESS GENERIC)
+
+      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)
+      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})
+          get_filename_component(basename ${GPU_KERNEL} NAME_WE)
+          string(SUBSTRING ${basename} 4 -1 KERNEL_NAME)
+          GenerateOpenCLHeader(${KERNEL_NAME} ${CMAKE_CURRENT_BINARY_DIR}/gpu/${KERNEL_NAME}_cl.h ${OCL_COMMON_HEADERS} ${GPU_KERNEL})
+          list(APPEND GPU_LIB_SOURCES ${CMAKE_CURRENT_BINARY_DIR}/gpu/${KERNEL_NAME}_cl.h)
+      endforeach()
+
+      GenerateOpenCLHeader(gayberne ${CMAKE_CURRENT_BINARY_DIR}/gpu/gayberne_cl.h ${OCL_COMMON_HEADERS} ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_ellipsoid_extra.h ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_gayberne.cu)
+      GenerateOpenCLHeader(gayberne_lj ${CMAKE_CURRENT_BINARY_DIR}/gpu/gayberne_lj_cl.h ${OCL_COMMON_HEADERS} ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_ellipsoid_extra.h ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_gayberne_lj.cu)
+      list(APPEND GPU_LIB_SOURCES ${CMAKE_CURRENT_BINARY_DIR}/gpu/gayberne_cl.h ${CMAKE_CURRENT_BINARY_DIR}/gpu/gayberne_lj_cl.h)
+
+      add_library(gpu STATIC ${GPU_LIB_SOURCES})
+      target_link_libraries(gpu ${OpenCL_LIBRARIES})
+      target_include_directories(gpu PRIVATE ${CMAKE_CURRENT_BINARY_DIR}/gpu ${OpenCL_INCLUDE_DIRS})
+      target_compile_definitions(gpu PRIVATE -D_${GPU_PREC} -DMPI_GERYON -DUCL_NO_EXIT)
+      target_compile_definitions(gpu PRIVATE -DUSE_OPENCL)
+
+      list(APPEND LAMMPS_LINK_LIBS gpu)
+
+      add_executable(ocl_get_devices ${LAMMPS_LIB_SOURCE_DIR}/gpu/geryon/ucl_get_devices.cpp)
+      target_compile_definitions(ocl_get_devices PRIVATE -DUCL_OPENCL)
+      target_link_libraries(ocl_get_devices PRIVATE ${OpenCL_LIBRARIES})
+      target_include_directories(ocl_get_devices PRIVATE ${OpenCL_INCLUDE_DIRS})
+    endif()
+
+    # GPU package
+    FindStyleHeaders(${GPU_SOURCES_DIR} FIX_CLASS fix_ FIX)
+
+    set_property(GLOBAL PROPERTY "GPU_SOURCES" "${GPU_SOURCES}")
+
+    # detects styles which have GPU version
+    RegisterStylesExt(${GPU_SOURCES_DIR} gpu GPU_SOURCES)
+
+    get_property(GPU_SOURCES GLOBAL PROPERTY GPU_SOURCES)
+
+    list(APPEND LIB_SOURCES ${GPU_SOURCES})
+    include_directories(${GPU_SOURCES_DIR})
 endif()
 
 ######################################################
@@ -522,19 +678,24 @@ include_directories(${LAMMPS_STYLE_HEADERS_DIR})
 ############################################
 add_library(lammps ${LIB_SOURCES})
 target_link_libraries(lammps ${LAMMPS_LINK_LIBS})
-set_target_properties(lammps PROPERTIES SOVERSION ${SOVERSION})
-if(INSTALL_LIB)
+if(LAMMPS_DEPS)
+  add_dependencies(lammps ${LAMMPS_DEPS})
+endif()
+set_target_properties(lammps PROPERTIES OUTPUT_NAME lammps${LAMMPS_MACHINE})
+if(BUILD_SHARED_LIBS)
+  set_target_properties(lammps PROPERTIES SOVERSION ${SOVERSION})
   install(TARGETS lammps LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR} ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR})
-  install(FILES ${LAMMPS_SOURCE_DIR}/lammps.h DESTINATION ${CMAKE_INSTALL_INCLUDEDIR})
-elseif(BUILD_SHARED_LIBS)
-  message(FATAL_ERROR "Shared library has to be installed, use -DINSTALL_LIB=ON to install lammps with a library")
+  install(FILES ${LAMMPS_SOURCE_DIR}/library.h DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/lammps)
+  configure_file(pkgconfig/liblammps.pc.in ${CMAKE_CURRENT_BINARY_DIR}/liblammps${LAMMPS_MACHINE}.pc @ONLY)
+  install(FILES ${CMAKE_CURRENT_BINARY_DIR}/liblammps${LAMMPS_MACHINE}.pc DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig)
 endif()
 
 add_executable(lmp ${LMP_SOURCES})
 target_link_libraries(lmp lammps)
+set_target_properties(lmp PROPERTIES OUTPUT_NAME lmp${LAMMPS_MACHINE})
 install(TARGETS lmp DESTINATION ${CMAKE_INSTALL_BINDIR})
 if(ENABLE_TESTING)
-  add_test(ShowHelp ${CMAKE_CURRENT_BINARY_DIR}/lmp -help)
+  add_test(ShowHelp lmp${LAMMPS_MACHINE} -help)
 endif()
 
 ##################################
@@ -545,3 +706,27 @@ foreach(PKG ${DEFAULT_PACKAGES} ${OTHER_PACKAGES} ${ACCEL_PACKAGES})
     message(STATUS "Building package: ${PKG}")
   endif()
 endforeach()
+
+string(TOUPPER "${CMAKE_BUILD_TYPE}" BTYPE)
+message(STATUS "<<< Build configuration >>>
+   Build type       ${CMAKE_BUILD_TYPE}
+   Install path     ${CMAKE_INSTALL_PREFIX}
+   Compilers and Flags:
+   C++ Compiler     ${CMAKE_CXX_COMPILER}
+       Type         ${CMAKE_CXX_COMPILER_ID}
+   C++ Flags        ${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_${BTYPE}}")
+get_property(LANGUAGES GLOBAL PROPERTY ENABLED_LANGUAGES)
+if(LANGUAGES MATCHES ".*Fortran.*")
+  message(STATUS "Fortran Compiler ${CMAKE_Fortran_COMPILER} 
+           Type     ${CMAKE_Fortran_COMPILER_ID}
+   Fortran Flags    ${CMAKE_Fortran_FLAGS} ${CMAKE_Fortran_FLAGS_${BTYPE}}")
+endif()
+message(STATUS "Linker flags:
+   Executable      ${CMAKE_EXE_LINKER_FLAGS}")
+if(BUILD_SHARED_LIBS)
+  message(STATUS "Shared libries  ${CMAKE_SHARED_LINKER_FLAGS}")
+else()
+  message(STATUS "Static libries  ${CMAKE_STATIC_LINKER_FLAGS}")
+endif()
+message(STATUS "Link libraries: ${LAMMPS_LINK_LIBS}")
+

cmake/Modules/FindLATTE.cmake

@@ -0,0 +1,18 @@
+# - Find latte
+# Find the native LATTE libraries.
+#
+#  LATTE_LIBRARIES    - List of libraries when using latte.
+#  LATTE_FOUND        - True if latte found.
+#
+
+find_library(LATTE_LIBRARY NAMES latte)
+
+set(LATTE_LIBRARIES ${LATTE_LIBRARY})
+
+include(FindPackageHandleStandardArgs)
+# handle the QUIETLY and REQUIRED arguments and set LATTE_FOUND to TRUE
+# if all listed variables are TRUE
+
+find_package_handle_standard_args(LATTE DEFAULT_MSG LATTE_LIBRARY)
+
+mark_as_advanced(LATTE_LIBRARY)

cmake/Modules/OpenCLUtils.cmake

@@ -0,0 +1,18 @@
+function(GenerateOpenCLHeader varname outfile files)
+    message("Creating ${outfile}...")
+    file(WRITE ${outfile} "const char * ${varname} = \n")
+    math(EXPR ARG_END   "${ARGC}-1")
+
+    foreach(IDX RANGE 2 ${ARG_END})
+        list(GET ARGV ${IDX} filename)
+        file(READ ${filename} content)
+        string(REGEX REPLACE "\\s*//[^\n]*\n" "" content "${content}")
+        string(REGEX REPLACE "\\\\" "\\\\\\\\" content "${content}")
+        string(REGEX REPLACE "\"" "\\\\\"" content "${content}")
+        string(REGEX REPLACE "([^\n]+)\n" "\"\\1\\\\n\"\n" content "${content}")
+        string(REGEX REPLACE "\n+" "\n" content "${content}")
+        file(APPEND ${outfile} "${content}")
+    endforeach()
+
+    file(APPEND ${outfile} ";\n")
+endfunction(GenerateOpenCLHeader)

cmake/Modules/StyleHeaderUtils.cmake

@@ -11,6 +11,12 @@ function(FindStyleHeaders path style_class file_pattern headers)
     set_property(GLOBAL PROPERTY ${headers} "${hlist}")
 endfunction(FindStyleHeaders)
 
+function(AddStyleHeader path headers)
+    get_property(hlist GLOBAL PROPERTY ${headers})
+    list(APPEND hlist ${path})
+    set_property(GLOBAL PROPERTY ${headers} "${hlist}")
+endfunction(AddStyleHeader)
+
 function(FindStyleHeadersExt path style_class extension headers sources)
     get_property(hlist GLOBAL PROPERTY ${headers})
     get_property(slist GLOBAL PROPERTY ${sources})
@@ -62,6 +68,22 @@ function(GenerateStyleHeader path property style)
     CreateStyleHeader("${path}" "style_${style}.h" ${files})
 endfunction(GenerateStyleHeader)
 
+function(RegisterNBinStyles search_path)
+    FindStyleHeaders(${search_path} NBIN_CLASS      nbin_      NBIN      ) # nbin      ) # neighbor
+endfunction(RegisterNBinStyles)
+
+function(RegisterNPairStyles search_path)
+    FindStyleHeaders(${search_path} NPAIR_CLASS     npair_     NPAIR     ) # npair     ) # neighbor
+endfunction(RegisterNPairStyles)
+
+function(RegisterNBinStyle path)
+    AddStyleHeader(${path} NBIN)
+endfunction(RegisterNBinStyle)
+
+function(RegisterNPairStyle path)
+    AddStyleHeader(${path} NPAIR)
+endfunction(RegisterNPairStyle)
+
 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
@@ -85,6 +107,35 @@ function(RegisterStyles search_path)
     FindStyleHeaders(${search_path} REGION_CLASS    region_    REGION    ) # region    ) # domain
 endfunction(RegisterStyles)
 
+function(RemovePackageHeader headers pkg_header)
+    get_property(hlist GLOBAL PROPERTY ${headers})
+    list(REMOVE_ITEM hlist ${pkg_header})
+    set_property(GLOBAL PROPERTY ${headers} "${hlist}")
+endfunction(RemovePackageHeader)
+
+function(DetectAndRemovePackageHeader fname)
+    RemovePackageHeader(ANGLE     ${fname})
+    RemovePackageHeader(ATOM_VEC  ${fname})
+    RemovePackageHeader(BODY      ${fname})
+    RemovePackageHeader(BOND      ${fname})
+    RemovePackageHeader(COMMAND   ${fname})
+    RemovePackageHeader(COMPUTE   ${fname})
+    RemovePackageHeader(DIHEDRAL  ${fname})
+    RemovePackageHeader(DUMP      ${fname})
+    RemovePackageHeader(FIX       ${fname})
+    RemovePackageHeader(IMPROPER  ${fname})
+    RemovePackageHeader(INTEGRATE ${fname})
+    RemovePackageHeader(KSPACE    ${fname})
+    RemovePackageHeader(MINIMIZE  ${fname})
+    RemovePackageHeader(NBIN      ${fname})
+    RemovePackageHeader(NPAIR     ${fname})
+    RemovePackageHeader(NSTENCIL  ${fname})
+    RemovePackageHeader(NTOPO     ${fname})
+    RemovePackageHeader(PAIR      ${fname})
+    RemovePackageHeader(READER    ${fname})
+    RemovePackageHeader(REGION    ${fname})
+endfunction(DetectAndRemovePackageHeader)
+
 function(RegisterStylesExt search_path extension sources)
     FindStyleHeadersExt(${search_path} ANGLE_CLASS     ${extension}  ANGLE     ${sources})
     FindStyleHeadersExt(${search_path} ATOM_CLASS      ${extension}  ATOM_VEC  ${sources})

cmake/pkgconfig/liblammps.pc.in

@@ -0,0 +1,18 @@
+# pkg-config file for lammps
+# https://people.freedesktop.org/~dbn/pkg-config-guide.html
+# Usage: cc `pkg-config --cflags --libs liblammps` -o myapp myapp.c
+# after you added @CMAKE_INSTALL_FULL_LIBDIR@/pkg-config to PKG_CONFIG_PATH,
+# e.g. export PKG_CONFIG_PATH=@CMAKE_INSTALL_FULL_LIBDIR@/pkgconfig
+
+prefix=@CMAKE_INSTALL_FULL_PREFIX@
+libdir=@CMAKE_INSTALL_FULL_LIBDIR@
+includedir=@CMAKE_INSTALL_FULL_INCLUDEDIR@
+
+Name: liblammps@LAMMPS_MACHINE@
+Description: Large-scale Atomic/Molecular Massively Parallel Simulator Library
+URL: http://lammps.sandia.gov
+Version:
+Requires:
+Libs: -L${libdir} -llammps@LAMMPS_MACHINE@
+Libs.private: -lm
+Cflags: -I${includedir} @LAMMPS_API_DEFINES@

doc/Makefile

@@ -20,6 +20,7 @@ ifeq ($(shell which virtualenv >/dev/null 2>&1; echo $$?), 0)
 HAS_VIRTUALENV = YES
 endif
 
+SPHINXEXTRA = -j $(shell $(PYTHON) -c 'import multiprocessing;print(multiprocessing.cpu_count())')
 SOURCES=$(wildcard src/*.txt)
 OBJECTS=$(SOURCES:src/%.txt=$(RSTDIR)/%.rst)
 
@@ -55,7 +56,7 @@ html: $(OBJECTS) $(ANCHORCHECK)
 	@(\
 		. $(VENV)/bin/activate ;\
 		cp -r src/* $(RSTDIR)/ ;\
-		sphinx-build -j 8 -b html -c utils/sphinx-config -d $(BUILDDIR)/doctrees $(RSTDIR) html ;\
+		sphinx-build $(SPHINXEXTRA) -b html -c utils/sphinx-config -d $(BUILDDIR)/doctrees $(RSTDIR) html ;\
 		echo "############################################" ;\
 		doc_anchor_check src/*.txt ;\
 		echo "############################################" ;\
@@ -91,7 +92,7 @@ epub: $(OBJECTS)
 	@(\
 		. $(VENV)/bin/activate ;\
 		cp -r src/* $(RSTDIR)/ ;\
-		sphinx-build -j 8 -b epub -c utils/sphinx-config -d $(BUILDDIR)/doctrees $(RSTDIR) epub ;\
+		sphinx-build $(SPHINXEXTRA) -b epub -c utils/sphinx-config -d $(BUILDDIR)/doctrees $(RSTDIR) epub ;\
 		deactivate ;\
 	)
 	@mv  epub/LAMMPS.epub .
@@ -159,7 +160,7 @@ $(VENV):
 	@( \
 		virtualenv -p $(PYTHON) $(VENV); \
 		. $(VENV)/bin/activate; \
-		pip install Sphinx==1.5.6; \
+		pip install Sphinx; \
 		pip install sphinxcontrib-images; \
 		deactivate;\
 	)

doc/src/Eqs/bond_gromos.tex

@@ -0,0 +1,10 @@
+\documentclass[12pt]{article}
+\pagestyle{empty}
+
+\begin{document}
+
+$$
+   E = K (r^2 - r_0^2)^2
+$$
+
+\end{document}

doc/src/Eqs/fix_rhok.tex

@@ -0,0 +1,11 @@
+\documentclass[12pt]{article}
+
+\begin{document}
+
+\begin{eqnarray*}
+ U &=&  \frac{1}{2} K (|\rho_{\vec{k}}| - a)^2 \\
+ \rho_{\vec{k}} &=& \sum_j^N \exp(-i\vec{k} \cdot \vec{r}_j )/\sqrt{N} \\
+ \vec{k} &=& (2\pi n_x /L_x , 2\pi n_y  /L_y , 2\pi n_z/L_z ) 
+\end{eqnarray*}
+
+\end{document}

doc/src/Eqs/pair_buck6d.txt

@@ -0,0 +1,9 @@
+\documentclass[12pt]{article}
+
+\begin{document}
+
+\begin{eqnarray*}
+  E = A e^{-\kappa r} - \frac{C}{r^6} \cdot \frac{1}{1 + D r^{14}} \qquad r < r_c \\
+\end{eqnarray*}
+
+\end{document}

doc/src/Eqs/pair_ufm.tex

@@ -0,0 +1,14 @@
+\documentclass[12pt]{article}
+
+\begin{document}
+
+$$
+	E = -\varepsilon\, \ln{\left[1-\exp{\left(-r^{2}/\sigma^{2}\right)}\right]} \qquad  r < r_c
+$$
+
+$$
+  \varepsilon = p\,k_B\,T
+$$
+
+\end{document}
+

doc/src/Manual.txt

@@ -1,7 +1,7 @@
 <!-- HTML_ONLY -->
 <HEAD>
 <TITLE>LAMMPS Users Manual</TITLE>
-<META NAME="docnumber" CONTENT="1 Sep 2017 version">
+<META NAME="docnumber" CONTENT="5 Feb 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 @@
 <H1></H1>
 
 LAMMPS Documentation :c,h3
-1 Sep 2017 version :c,h4
+5 Feb 2018 version :c,h4
 
 Version info: :h4
 

doc/src/Section_commands.txt

@@ -532,7 +532,8 @@ package"_Section_start.html#start_3.
 "dump vtk"_dump_vtk.html,
 "group2ndx"_group2ndx.html,
 "ndx2group"_group2ndx.html,
-"temper/grem"_temper_grem.html :tb(c=3,ea=c)
+"temper/grem"_temper_grem.html,
+"temper/npt"_temper_npt.html :tb(c=3,ea=c)
 
 :line
 
@@ -579,6 +580,7 @@ USER-INTEL, k = KOKKOS, o = USER-OMP, t = OPT.
 "halt"_fix_halt.html,
 "heat"_fix_heat.html,
 "indent"_fix_indent.html,
+"latte"_fix_latte.html,
 "langevin (k)"_fix_langevin.html,
 "lineforce"_fix_lineforce.html,
 "momentum (k)"_fix_momentum.html,
@@ -617,8 +619,9 @@ USER-INTEL, k = KOKKOS, o = USER-OMP, t = OPT.
 "pour"_fix_pour.html,
 "press/berendsen"_fix_press_berendsen.html,
 "print"_fix_print.html,
-"property/atom"_fix_property_atom.html,
-"python"_fix_python.html,
+"property/atom (k)"_fix_property_atom.html,
+"python/invoke"_fix_python_invoke.html,
+"python/move"_fix_python_move.html,
 "qeq/comb (o)"_fix_qeq_comb.html,
 "qeq/dynamic"_fix_qeq.html,
 "qeq/fire"_fix_qeq.html,
@@ -635,10 +638,10 @@ USER-INTEL, k = KOKKOS, o = USER-OMP, t = OPT.
 "rigid/nve (o)"_fix_rigid.html,
 "rigid/nvt (o)"_fix_rigid.html,
 "rigid/small (o)"_fix_rigid.html,
-"rigid/small/nph (o)"_fix_rigid.html,
-"rigid/small/npt (o)"_fix_rigid.html,
-"rigid/small/nve (o)"_fix_rigid.html,
-"rigid/small/nvt (o)"_fix_rigid.html,
+"rigid/small/nph"_fix_rigid.html,
+"rigid/small/npt"_fix_rigid.html,
+"rigid/small/nve"_fix_rigid.html,
+"rigid/small/nvt"_fix_rigid.html,
 "setforce (k)"_fix_setforce.html,
 "shake"_fix_shake.html,
 "spring"_fix_spring.html,
@@ -666,7 +669,7 @@ USER-INTEL, k = KOKKOS, o = USER-OMP, t = OPT.
 "wall/harmonic"_fix_wall.html,
 "wall/lj1043"_fix_wall.html,
 "wall/lj126"_fix_wall.html,
-"wall/lj93"_fix_wall.html,
+"wall/lj93 (k)"_fix_wall.html,
 "wall/piston"_fix_wall_piston.html,
 "wall/reflect (k)"_fix_wall_reflect.html,
 "wall/region"_fix_wall_region.html,
@@ -681,14 +684,14 @@ package"_Section_start.html#start_3.
 "atc"_fix_atc.html,
 "ave/correlate/long"_fix_ave_correlate_long.html,
 "colvars"_fix_colvars.html,
-"dpd/energy"_fix_dpd_energy.html,
+"dpd/energy (k)"_fix_dpd_energy.html,
 "drude"_fix_drude.html,
 "drude/transform/direct"_fix_drude_transform.html,
 "drude/transform/reverse"_fix_drude_transform.html,
 "edpd/source"_fix_dpd_source.html,
 "eos/cv"_fix_eos_cv.html,
 "eos/table"_fix_eos_table.html,
-"eos/table/rx"_fix_eos_table_rx.html,
+"eos/table/rx (k)"_fix_eos_table_rx.html,
 "filter/corotate"_fix_filter_corotate.html,
 "flow/gauss"_fix_flow_gauss.html,
 "gle"_fix_gle.html,
@@ -718,17 +721,20 @@ package"_Section_start.html#start_3.
 "nve/eff"_fix_nve_eff.html,
 "nvt/eff"_fix_nh_eff.html,
 "nvt/sllod/eff"_fix_nvt_sllod_eff.html,
+"npt/uef"_fix_nh_uef.html,
+"nvt/uef"_fix_nh_uef.html,
 "phonon"_fix_phonon.html,
 "pimd"_fix_pimd.html,
 "qbmsst"_fix_qbmsst.html,
 "qeq/reax (ko)"_fix_qeq_reax.html,
 "qmmm"_fix_qmmm.html,
 "qtb"_fix_qtb.html,
-"reax/c/bonds"_fix_reax_bonds.html,
-"reax/c/species"_fix_reaxc_species.html,
-"rx"_fix_rx.html,
+"reax/c/bonds (k)"_fix_reax_bonds.html,
+"reax/c/species (k)"_fix_reaxc_species.html,
+"rhok"_fix_rhok.html,
+"rx (k)"_fix_rx.html,
 "saed/vtk"_fix_saed_vtk.html,
-"shardlow"_fix_shardlow.html,
+"shardlow (k)"_fix_shardlow.html,
 "smd"_fix_smd.html,
 "smd/adjust/dt"_fix_smd_adjust_dt.html,
 "smd/integrate/tlsph"_fix_smd_integrate_tlsph.html,
@@ -755,6 +761,7 @@ package"_Section_accelerate.html.  This is indicated by additional
 letters in parenthesis: g = GPU, i = USER-INTEL, k =
 KOKKOS, o = USER-OMP, t = OPT.
 
+"aggregate/atom"_compute_cluster_atom.html,
 "angle"_compute_angle.html,
 "angle/local"_compute_angle_local.html,
 "angmom/chunk"_compute_angmom_chunk.html,
@@ -853,6 +860,7 @@ package"_Section_start.html#start_3.
 "meso/t/atom"_compute_meso_t_atom.html,
 "pe/tally"_compute_tally.html,
 "pe/mol/tally"_compute_tally.html,
+"pressure/uef"_compute_pressure_uef.html,
 "saed"_compute_saed.html,
 "smd/contact/radius"_compute_smd_contact_radius.html,
 "smd/damage"_compute_smd_damage.html,
@@ -881,6 +889,7 @@ package"_Section_start.html#start_3.
 "temp/deform/eff"_compute_temp_deform_eff.html,
 "temp/region/eff"_compute_temp_region_eff.html,
 "temp/rotate"_compute_temp_rotate.html,
+"temp/uef"_compute_temp_uef.html,
 "xrd"_compute_xrd.html :tb(c=6,ea=c)
 
 :line
@@ -898,7 +907,7 @@ KOKKOS, o = USER-OMP, t = OPT.
 "none"_pair_none.html,
 "zero"_pair_zero.html,
 "hybrid"_pair_hybrid.html,
-"hybrid/overlay"_pair_hybrid.html,
+"hybrid/overlay (k)"_pair_hybrid.html,
 "adp (o)"_pair_adp.html,
 "airebo (oi)"_pair_airebo.html,
 "airebo/morse (oi)"_pair_airebo.html,
@@ -912,11 +921,12 @@ KOKKOS, o = USER-OMP, t = OPT.
 "born/coul/long/cs"_pair_born.html,
 "born/coul/msm (o)"_pair_born.html,
 "born/coul/wolf (go)"_pair_born.html,
+"born/coul/wolf/cs"_pair_born.html,
 "brownian (o)"_pair_brownian.html,
 "brownian/poly (o)"_pair_brownian.html,
-"buck (gkio)"_pair_buck.html,
-"buck/coul/cut (gkio)"_pair_buck.html,
-"buck/coul/long (gkio)"_pair_buck.html,
+"buck (giko)"_pair_buck.html,
+"buck/coul/cut (giko)"_pair_buck.html,
+"buck/coul/long (giko)"_pair_buck.html,
 "buck/coul/long/cs"_pair_buck.html,
 "buck/coul/msm (o)"_pair_buck.html,
 "buck/long/coul/long (o)"_pair_buck_long.html,
@@ -931,12 +941,13 @@ KOKKOS, o = USER-OMP, t = OPT.
 "coul/msm"_pair_coul.html,
 "coul/streitz"_pair_coul.html,
 "coul/wolf (ko)"_pair_coul.html,
-"dpd (go)"_pair_dpd.html,
+"coul/wolf/cs"_pair_coul.html,
+"dpd (gio)"_pair_dpd.html,
 "dpd/tstat (go)"_pair_dpd.html,
 "dsmc"_pair_dsmc.html,
-"eam (gkiot)"_pair_eam.html,
-"eam/alloy (gkiot)"_pair_eam.html,
-"eam/fs (gkiot)"_pair_eam.html,
+"eam (gikot)"_pair_eam.html,
+"eam/alloy (gikot)"_pair_eam.html,
+"eam/fs (gikot)"_pair_eam.html,
 "eim (o)"_pair_eim.html,
 "gauss (go)"_pair_gauss.html,
 "gayberne (gio)"_pair_gayberne.html,
@@ -950,9 +961,9 @@ KOKKOS, o = USER-OMP, t = OPT.
 "kim"_pair_kim.html,
 "lcbop"_pair_lcbop.html,
 "line/lj"_pair_line_lj.html,
-"lj/charmm/coul/charmm (kio)"_pair_charmm.html,
+"lj/charmm/coul/charmm (iko)"_pair_charmm.html,
 "lj/charmm/coul/charmm/implicit (ko)"_pair_charmm.html,
-"lj/charmm/coul/long (gkio)"_pair_charmm.html,
+"lj/charmm/coul/long (giko)"_pair_charmm.html,
 "lj/charmm/coul/msm"_pair_charmm.html,
 "lj/charmmfsw/coul/charmmfsh"_pair_charmm.html,
 "lj/charmmfsw/coul/long"_pair_charmm.html,
@@ -1002,20 +1013,21 @@ KOKKOS, o = USER-OMP, t = OPT.
 "resquared (go)"_pair_resquared.html,
 "snap"_pair_snap.html,
 "soft (go)"_pair_soft.html,
-"sw (gkio)"_pair_sw.html,
+"sw (giko)"_pair_sw.html,
 "table (gko)"_pair_table.html,
-"tersoff (gkio)"_pair_tersoff.html,
+"tersoff (giko)"_pair_tersoff.html,
 "tersoff/mod (gko)"_pair_tersoff_mod.html,
 "tersoff/mod/c (o)"_pair_tersoff_mod.html,
 "tersoff/zbl (gko)"_pair_tersoff_zbl.html,
 "tip4p/cut (o)"_pair_coul.html,
 "tip4p/long (o)"_pair_coul.html,
 "tri/lj"_pair_tri_lj.html,
+"ufm (got)"_pair_ufm.html,
 "vashishta (ko)"_pair_vashishta.html,
 "vashishta/table (o)"_pair_vashishta.html,
-"yukawa (go)"_pair_yukawa.html,
+"yukawa (gok)"_pair_yukawa.html,
 "yukawa/colloid (go)"_pair_yukawa_colloid.html,
-"zbl (go)"_pair_zbl.html :tb(c=4,ea=c)
+"zbl (gok)"_pair_zbl.html :tb(c=4,ea=c)
 
 These are additional pair styles in USER packages, which can be used
 if "LAMMPS is built with the appropriate
@@ -1028,13 +1040,14 @@ package"_Section_start.html#start_3.
 "coul/diel (o)"_pair_coul_diel.html,
 "coul/long/soft (o)"_pair_lj_soft.html,
 "dpd/fdt"_pair_dpd_fdt.html,
-"dpd/fdt/energy"_pair_dpd_fdt.html,
+"dpd/fdt/energy (k)"_pair_dpd_fdt.html,
 "eam/cd (o)"_pair_eam.html,
 "edip (o)"_pair_edip.html,
 "edip/multi"_pair_edip.html,
 "edpd"_pair_meso.html,
 "eff/cut"_pair_eff.html,
-"exp6/rx"_pair_exp6_rx.html,
+"exp6/rx (k)"_pair_exp6_rx.html,
+"extep"_pair_extep.html,
 "gauss/cut"_pair_gauss.html,
 "kolmogorov/crespi/z"_pair_kolmogorov_crespi_z.html,
 "lennard/mdf"_pair_mdf.html,
@@ -1060,7 +1073,7 @@ package"_Section_start.html#start_3.
 "morse/smooth/linear"_pair_morse.html,
 "morse/soft"_pair_morse.html,
 "multi/lucy"_pair_multi_lucy.html,
-"multi/lucy/rx"_pair_multi_lucy_rx.html,
+"multi/lucy/rx (k)"_pair_multi_lucy_rx.html,
 "oxdna/coaxstk"_pair_oxdna.html,
 "oxdna/excv"_pair_oxdna.html,
 "oxdna/hbond"_pair_oxdna.html,
@@ -1077,6 +1090,7 @@ package"_Section_start.html#start_3.
 "smd/triangulated/surface"_pair_smd_triangulated_surface.html,
 "smd/ulsph"_pair_smd_ulsph.html,
 "smtbq"_pair_smtbq.html,
+"snap (k)"_pair_snap.html,
 "sph/heatconduction"_pair_sph_heatconduction.html,
 "sph/idealgas"_pair_sph_idealgas.html,
 "sph/lj"_pair_sph_lj.html,
@@ -1084,7 +1098,7 @@ package"_Section_start.html#start_3.
 "sph/taitwater"_pair_sph_taitwater.html,
 "sph/taitwater/morris"_pair_sph_taitwater_morris.html,
 "srp"_pair_srp.html,
-"table/rx"_pair_table_rx.html,
+"table/rx (k)"_pair_table_rx.html,
 "tdpd"_pair_meso.html,
 "tersoff/table (o)"_pair_tersoff.html,
 "thole"_pair_thole.html,
@@ -1108,6 +1122,7 @@ KOKKOS, o = USER-OMP, t = OPT.
 "class2 (ko)"_bond_class2.html,
 "fene (iko)"_bond_fene.html,
 "fene/expand (o)"_bond_fene_expand.html,
+"gromos (o)"_bond_gromos.html,
 "harmonic (ko)"_bond_harmonic.html,
 "morse (o)"_bond_morse.html,
 "nonlinear (o)"_bond_nonlinear.html,
@@ -1174,7 +1189,7 @@ USER-OMP, t = OPT.
 "none"_dihedral_none.html,
 "zero"_dihedral_zero.html,
 "hybrid"_dihedral_hybrid.html,
-"charmm (ko)"_dihedral_charmm.html,
+"charmm (iko)"_dihedral_charmm.html,
 "charmmfsw"_dihedral_charmm.html,
 "class2 (ko)"_dihedral_class2.html,
 "harmonic (io)"_dihedral_harmonic.html,
@@ -1187,7 +1202,7 @@ used if "LAMMPS is built with the appropriate
 package"_Section_start.html#start_3.
 
 "cosine/shift/exp (o)"_dihedral_cosine_shift_exp.html,
-"fourier (o)"_dihedral_fourier.html,
+"fourier (io)"_dihedral_fourier.html,
 "nharmonic (o)"_dihedral_nharmonic.html,
 "quadratic (o)"_dihedral_quadratic.html,
 "spherical (o)"_dihedral_spherical.html,
@@ -1210,7 +1225,7 @@ USER-OMP, t = OPT.
 "hybrid"_improper_hybrid.html,
 "class2 (ko)"_improper_class2.html,
 "cvff (io)"_improper_cvff.html,
-"harmonic (ko)"_improper_harmonic.html,
+"harmonic (iko)"_improper_harmonic.html,
 "umbrella (o)"_improper_umbrella.html :tb(c=4,ea=c)
 
 These are additional improper styles in USER packages, which can be
@@ -1238,7 +1253,7 @@ USER-OMP, t = OPT.
 "ewald/disp"_kspace_style.html,
 "msm (o)"_kspace_style.html,
 "msm/cg (o)"_kspace_style.html,
-"pppm (go)"_kspace_style.html,
+"pppm (gok)"_kspace_style.html,
 "pppm/cg (o)"_kspace_style.html,
 "pppm/disp (i)"_kspace_style.html,
 "pppm/disp/tip4p"_kspace_style.html,

doc/src/Section_howto.txt

@@ -454,7 +454,7 @@ NOTE: By default, for 2d systems, granular particles are still modeled
 as 3d spheres, not 2d discs (circles), meaning their moment of inertia
 will be the same as in 3d.  If you wish to model granular particles in
 2d as 2d discs, see the note on this topic in "Section
-6.2"_Section_howto.html#howto_2, where 2d simulations are disussed.
+6.2"_Section_howto.html#howto_2, where 2d simulations are discussed.
 
 :line
 
@@ -2859,8 +2859,8 @@ The nature of the atoms (core, Drude particle or non-polarizable) is
 specified via the "fix drude"_fix_drude.html command.  The special
 list of neighbors is automatically refactored to account for the
 equivalence of core and Drude particles as regards special 1-2 to 1-4
-screening. It may be necessary to use the {extra} keyword of the
-"special_bonds"_special_bonds.html command. If using "fix
+screening. It may be necessary to use the {extra/special/per/atom}
+keyword of the "read_data"_read_data.html command. If using "fix
 shake"_fix_shake.html, make sure no Drude particle is in this fix
 group.
 

doc/src/Section_packages.txt

@@ -96,6 +96,7 @@ Package, Description, Doc page, Example, Library
 "KIM"_#KIM, OpenKIM wrapper, "pair_style kim"_pair_kim.html, kim, ext
 "KOKKOS"_#KOKKOS, Kokkos-enabled styles, "Section 5.3.3"_accelerate_kokkos.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
 "KSPACE"_#KSPACE, long-range Coulombic solvers, "kspace_style"_kspace_style.html, peptide, -
+"LATTE"_#LATTE, quantum DFTB forces via LATTE, "fix latte"_fix_latte.html, latte, ext
 "MANYBODY"_#MANYBODY, many-body potentials, "pair_style tersoff"_pair_tersoff.html, shear, -
 "MC"_#MC, Monte Carlo options, "fix gcmc"_fix_gcmc.html, -, -
 "MEAM"_#MEAM, modified EAM potential, "pair_style meam"_pair_meam.html, meam, int
@@ -137,6 +138,7 @@ Package, Description, Doc page, Example, Library
 "USER-MESO"_#USER-MESO, mesoscale DPD models, "pair_style edpd"_pair_meso.html, USER/meso, -
 "USER-MGPT"_#USER-MGPT, fast MGPT multi-ion potentials, "pair_style mgpt"_pair_mgpt.html, USER/mgpt, -
 "USER-MISC"_#USER-MISC, single-file contributions, USER-MISC/README, USER/misc, -
+"USER-MOFFF"_#USER-MOFFF, styles for "MOF-FF"_MOFplus force field, "pair_style buck6d/coul/gauss"_pair_buck6d_coul_gauss.html, USER/mofff, -
 "USER-MOLFILE"_#USER-MOLFILE, "VMD"_vmd_home molfile plug-ins,"dump molfile"_dump_molfile.html, -, ext
 "USER-NETCDF"_#USER-NETCDF, dump output via NetCDF,"dump netcdf"_dump_netcdf.html, -, ext
 "USER-OMP"_#USER-OMP, OpenMP-enabled styles,"Section 5.3.4"_accelerate_omp.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
@@ -149,6 +151,7 @@ Package, Description, Doc page, Example, Library
 "USER-SMTBQ"_#USER-SMTBQ, second moment tight binding QEq potential,"pair_style smtbq"_pair_smtbq.html, USER/smtbq, -
 "USER-SPH"_#USER-SPH, smoothed particle hydrodynamics,"SPH User Guide"_PDF/SPH_LAMMPS_userguide.pdf, USER/sph, -
 "USER-TALLY"_#USER-TALLY, pairwise tally computes,"compute XXX/tally"_compute_tally.html, USER/tally, -
+"USER-UEF"_#USER-UEF, extensional flow,"fix nvt/uef"_fix_nh_uef.html, USER/uef, -
 "USER-VTK"_#USER-VTK, dump output via VTK, "compute vtk"_dump_vtk.html, -, ext :tb(ea=c,ca1=l)
 
 :line
@@ -241,7 +244,7 @@ COLLOID package :link(COLLOID),h4
 
 [Contents:]
 
-Coarse-grained finite-size colloidal particles.  Pair stayle and fix
+Coarse-grained finite-size colloidal particles.  Pair styles and fix
 wall styles for colloidal interactions.  Includes the Fast Lubrication
 Dynamics (FLD) method for hydrodynamic interactions, which is a
 simplified approximation to Stokesian dynamics.
@@ -695,6 +698,66 @@ bench/in.rhodo :ul
 
 :line
 
+LATTE package :link(LATTE),h4
+
+[Contents:]
+
+A fix command which wraps the LATTE DFTB code, so that molecular
+dynamics can be run with LAMMPS using density-functional tight-binding
+quantum forces calculated by LATTE.
+
+More information on LATTE can be found at this web site:
+"https://github.com/lanl/LATTE"_latte_home.  A brief technical
+description is given with the "fix latte"_fix_latte.html command.
+
+:link(latte_home,https://github.com/lanl/LATTE)
+
+[Authors:] Christian Negre (LANL) and Steve Plimpton (Sandia).  LATTE
+itself is developed at Los Alamos National Laboratory by Marc
+Cawkwell, Anders Niklasson, and Christian Negre.
+
+[Install or un-install:]
+
+Before building LAMMPS with this package, you must first download and
+build the LATTE library.  You can do this manually if you prefer;
+follow the instructions in lib/latte/README.  You can also do it in
+one step from the lammps/src dir, using a command like these, which
+simply invokes the lib/latte/Install.py script with the specified
+args:
+
+make lib-latte                          # print help message
+make lib-latte args="-b"                # download and build in lib/latte/LATTE-master
+make lib-latte args="-p $HOME/latte"    # use existing LATTE installation in $HOME/latte
+make lib-latte args="-b -m gfortran"    # download and build in lib/latte and 
+                                        #   copy Makefile.lammps.gfortran to Makefile.lammps
+:pre
+
+Note that 3 symbolic (soft) links, "includelink" and "liblink" and
+"filelink.o", are created in lib/latte to point into the LATTE home dir.
+When LAMMPS builds in src it will use these links.  You should 
+also check that the Makefile.lammps file you create is appropriate
+for the compiler you use on your system to build LATTE.
+
+You can then install/un-install the package and build LAMMPS in the
+usual manner:
+
+make yes-latte
+make machine :pre
+
+make no-latte
+make machine :pre
+
+[Supporting info:]
+
+src/LATTE: filenames -> commands
+src/LATTE/README
+lib/latte/README
+"fix latte"_fix_latte.html
+examples/latte
+"LAMMPS-LATTE tutorial"_https://github.com/lanl/LATTE/wiki/Using-LATTE-through-LAMMPS :ul
+
+:line
+
 MANYBODY package :link(MANYBODY),h4
 
 [Contents:]
@@ -922,7 +985,7 @@ MSCG package :link(mscg),h4
 [Contents:]
 
 A "fix mscg"_fix_mscg.html command which can parameterize a
-Mulit-Scale Coarse-Graining (MSCG) model using the open-source "MS-CG
+Multi-Scale Coarse-Graining (MSCG) model using the open-source "MS-CG
 library"_mscg_home.
 
 :link(mscg_home,https://github.com/uchicago-voth/MSCG-release)
@@ -1719,7 +1782,7 @@ coarse-grained DPD-based models for energetic, reactive molecular
 crystalline materials.  It includes many pair styles specific to these
 systems, including for reactive DPD, where each particle has internal
 state for multiple species and a coupled set of chemical reaction ODEs
-are integrated each timestep.  Highly accurate time intergrators for
+are integrated each timestep.  Highly accurate time integrators for
 isothermal, isoenergetic, isobaric and isenthalpic conditions are
 included.  These enable long timesteps via the Shardlow splitting
 algorithm.
@@ -2169,7 +2232,7 @@ Several extensions of the the dissipative particle dynamics (DPD)
 method.  Specifically, energy-conserving DPD (eDPD) that can model
 non-isothermal processes, many-body DPD (mDPD) for simulating
 vapor-liquid coexistence, and transport DPD (tDPD) for modeling
-advection-diffuion-reaction systems. The equations of motion of these
+advection-diffusion-reaction systems. The equations of motion of these
 DPD extensions are integrated through a modified velocity-Verlet (MVV)
 algorithm.
 
@@ -2191,12 +2254,50 @@ src/USER-MESO/README
 "pair_style edpd"_pair_meso.html
 "pair_style mdpd"_pair_meso.html
 "pair_style tdpd"_pair_meso.html
-"fix mvv/dpd"_fix_mvv.html
+"fix mvv/dpd"_fix_mvv_dpd.html
 examples/USER/meso
 http://lammps.sandia.gov/movies.html#mesodpd :ul
 
 :line
 
+USER-MOFFF package :link(USER-MOFFF),h4
+
+[Contents:]
+
+Pair, angle and improper styles needed to employ the MOF-FF
+force field by Schmid and coworkers with LAMMPS. 
+MOF-FF is a first principles derived force field with the primary aim
+to simulate MOFs and related porous framework materials, using spherical 
+Gaussian charges. It is described in S. Bureekaew et al., Phys. Stat. Sol. B
+2013, 250, 1128-1141.
+For the usage of MOF-FF see the example in the example directory as 
+well as the "MOF+"_MOFplus website.
+
+:link(MOFplus,https://www.mofplus.org/content/show/MOF-FF)
+
+[Author:] Hendrik Heenen (Technical U of Munich), 
+Rochus Schmid (Ruhr-University Bochum).
+
+[Install or un-install:]
+
+make yes-user-mofff
+make machine :pre
+
+make no-user-mofff
+make machine :pre
+
+[Supporting info:]
+
+src/USER-MOFFF: filenames -> commands
+src/USER-MOFFF/README
+"pair_style buck6d/coul/gauss"_pair_buck6d_coul_gauss.html
+"angle_style class2"_angle_class2.html
+"angle_style cosine/buck6d"_angle_cosine_buck6d.html
+"improper_style inversion/harmonic"_improper_inversion_harmonic.html
+examples/USER/mofff :ul
+
+:line
+
 USER-MOLFILE package :link(USER-MOLFILE),h4
 
 [Contents:]
@@ -2433,7 +2534,7 @@ make machine :pre
 
 NOTE: The LAMMPS executable these steps produce is not yet functional
 for a QM/MM simulation.  You must also build Quantum ESPRESSO and
-create a new executable which links LAMMPS and Quanutm ESPRESSO
+create a new executable which links LAMMPS and Quantum ESPRESSO
 together.  These are steps 3 and 4 described in the lib/qmmm/README
 file.
 
@@ -2492,7 +2593,7 @@ developed by the Cambridge University group.
 
 :link(quip,https://github.com/libAtoms/QUIP)
 
-To use this package you must have the QUIP libAatoms library available
+To use this package you must have the QUIP libAtoms library available
 on your system.
 
 [Author:] Albert Bartok (Cambridge University)
@@ -2710,13 +2811,44 @@ examples/USER/tally :ul
 
 :line
 
+USER-UEF package :link(USER-UEF),h4
+
+[Contents:]
+
+A fix style for the integration of the equations of motion under
+extensional flow with proper boundary conditions, as well as several
+supporting compute styles and an output option.
+
+[Author:] David Nicholson (MIT).
+
+[Install or un-install:]
+
+make yes-user-uef
+make machine :pre
+
+make no-user-uef
+make machine :pre
+
+[Supporting info:]
+
+src/USER-UEF: filenames -> commands
+src/USER-UEF/README
+"fix nvt/uef"_fix_nh_uef.html
+"fix npt/uef"_fix_nh_uef.html
+"compute pressure/uef"_compute_pressure_uef.html
+"compute temp/uef"_compute_temp_uef.html
+"dump cfg/uef"_dump_cfg_uef.html
+examples/uef :ul
+
+:line
+
 USER-VTK package :link(USER-VTK),h4
 
 [Contents:]
 
-A "dump vtk"_dump_vtk.html command which outputs
-snapshot info in the "VTK format"_vtk, enabling visualization by
-"Paraview"_paraview or other visuzlization packages.
+A "dump vtk"_dump_vtk.html command which outputs snapshot info in the
+"VTK format"_vtk, enabling visualization by "Paraview"_paraview or
+other visualization packages.
 
 :link(vtk,http://www.vtk.org)
 :link(paraview,http://www.paraview.org)

doc/src/Section_python.txt

@@ -123,7 +123,7 @@ code directly from an input script:
 
 "python"_python.html
 "variable python"_variable.html
-"fix python"_fix_python.html
+"fix python/invoke"_fix_python_invoke.html
 "pair_style python"_pair_python.html :ul
 
 The "python"_python.html command which can be used to define and
@@ -165,7 +165,7 @@ doc page for its python-style variables for more info, including
 examples of Python code you can write for both pure Python operations
 and callbacks to LAMMPS.
 
-The "fix python"_fix_python.html command can execute
+The "fix python/invoke"_fix_python_invoke.html command can execute
 Python code at selected timesteps during a simulation run.
 
 The "pair_style python"_pair_python command allows you to define

doc/src/Section_start.txt

@@ -79,7 +79,7 @@ This section has the following sub-sections:
 
 Read this first :h5,link(start_2_1)
 
-If you want to avoid building LAMMPS yourself, read the preceeding
+If you want to avoid building LAMMPS yourself, read the preceding
 section about options available for downloading and installing
 executables.  Details are discussed on the "download"_download page.
 
@@ -252,14 +252,13 @@ re-compile, after typing "make clean" (which will describe different
 clean options).
 
 The LMP_INC variable is used to include options that turn on ifdefs
-within the LAMMPS code.  The options that are currently recogized are:
+within the LAMMPS code.  The options that are currently recognized are:
 
 -DLAMMPS_GZIP
 -DLAMMPS_JPEG
 -DLAMMPS_PNG
 -DLAMMPS_FFMPEG
 -DLAMMPS_MEMALIGN
--DLAMMPS_XDR
 -DLAMMPS_SMALLBIG
 -DLAMMPS_BIGBIG
 -DLAMMPS_SMALLSMALL
@@ -308,11 +307,6 @@ has to be aligned on larger than default byte boundaries (e.g. 16
 bytes instead of 8 bytes on x86 type platforms) for optimal
 performance.
 
-If you use -DLAMMPS_XDR, the build will include XDR compatibility
-files for doing particle dumps in XTC format.  This is only necessary
-if your platform does have its own XDR files available.  See the
-Restrictions section of the "dump"_dump.html command for details.
-
 Use at most one of the -DLAMMPS_SMALLBIG, -DLAMMPS_BIGBIG,
 -DLAMMPS_SMALLSMALL settings.  The default is -DLAMMPS_SMALLBIG. These
 settings refer to use of 4-byte (small) vs 8-byte (big) integers
@@ -363,7 +357,7 @@ installed on your platform.  If MPI is installed on your system in the
 usual place (under /usr/local), you also may not need to specify these
 3 variables, assuming /usr/local is in your path.  On some large
 parallel machines which use "modules" for their compile/link
-environements, you may simply need to include the correct module in
+environments, you may simply need to include the correct module in
 your build environment, before building LAMMPS.  Or the parallel
 machine may have a vendor-provided MPI which the compiler has no
 trouble finding.
@@ -431,7 +425,7 @@ use the KISS library described above.
 You may also need to set the FFT_INC, FFT_PATH, and FFT_LIB variables,
 so the compiler and linker can find the needed FFT header and library
 files.  Note that on some large parallel machines which use "modules"
-for their compile/link environements, you may simply need to include
+for their compile/link environments, you may simply need to include
 the correct module in your build environment.  Or the parallel machine
 may have a vendor-provided FFT library which the compiler has no
 trouble finding.  See the src/MAKE/OPTIONS/Makefile.fftw file for an
@@ -470,7 +464,7 @@ precision.
 
 The FFT_INC variable also allows for a -DFFT_SINGLE setting that will
 use single-precision FFTs with PPPM, which can speed-up long-range
-calulations, particularly in parallel or on GPUs.  Fourier transform
+calculations, particularly in parallel or on GPUs.  Fourier transform
 and related PPPM operations are somewhat insensitive to floating point
 truncation errors and thus do not always need to be performed in
 double precision.  Using the -DFFT_SINGLE setting trades off a little
@@ -483,7 +477,7 @@ with support for single-precision, as explained above.  For FFTW3 you
 also need to include -lfftw3f with the FFT_LIB setting, in addition to
 -lfftw3.  For FFTW2, you also need to specify -DFFT_SIZE with the
 FFT_INC setting and -lsfftw with the FFT_LIB setting (in place of
--lfftw).  Similarly, if FFTW2 has been preinstalled with an explicit
+-lfftw).  Similarly, if FFTW2 has been pre-installed with an explicit
 double-precision library (libdfftw.a and not the default libfftw.a),
 then you can specify -DFFT_SIZE (and not -DFFT_SINGLE), and specify
 -ldfftw to use double-precision FFTs.
@@ -714,7 +708,7 @@ list various make commands that can be used to manage packages.
 If you use a command in a LAMMPS input script that is part of a
 package, you must have built LAMMPS with that package, else you will
 get an error that the style is invalid or the command is unknown.
-Every command's doc page specfies if it is part of a package.  You can
+Every command's doc page specifies if it is part of a package.  You can
 type
 
 lmp_machine -h :pre
@@ -859,7 +853,7 @@ details for each package.
 [External libraries:]
 
 Packages in the tables "Section 4"_Section_packages.html with an "ext"
-in the last column link to exernal libraries whose source code is not
+in the last column link to external libraries whose source code is not
 included with LAMMPS.  You must first download and install the library
 before building LAMMPS with that package installed.  E.g. the voronoi
 package links to the freely available "Voro++ library"_voro_home2.  You
@@ -920,7 +914,7 @@ CPUs and KNLs; the KOKKOS package builds for CPUs (OpenMP), GPUs
 Makefile.intel_cpu
 Makefile.intel_phi
 Makefile.kokkos_omp
-Makefile.kokkos_cuda
+Makefile.kokkos_cuda_mpi
 Makefile.kokkos_phi
 Makefile.omp
 Makefile.opt :ul
@@ -963,7 +957,7 @@ src/MAKE/Makefile.foo and perform the build in the directory
 Obj_shared_foo.  This is so that each file can be compiled with the
 -fPIC flag which is required for inclusion in a shared library.  The
 build will create the file liblammps_foo.so which another application
-can link to dyamically.  It will also create a soft link liblammps.so,
+can link to dynamically.  It will also create a soft link liblammps.so,
 which will point to the most recently built shared library.  This is
 the file the Python wrapper loads by default.
 
@@ -1329,8 +1323,8 @@ LAMMPS is compiled with CUDA=yes.
 numa Nm :pre
 
 This option is only relevant when using pthreads with hwloc support.
-In this case Nm defines the number of NUMA regions (typicaly sockets)
-on a node which will be utilizied by a single MPI rank.  By default Nm
+In this case Nm defines the number of NUMA regions (typically sockets)
+on a node which will be utilized by a single MPI rank.  By default Nm
 = 1.  If this option is used the total number of worker-threads per
 MPI rank is threads*numa.  Currently it is always almost better to
 assign at least one MPI rank per NUMA region, and leave numa set to
@@ -1394,7 +1388,7 @@ replica runs on on one or a few processors.  Note that with MPI
 installed on a machine (e.g. your desktop), you can run on more
 (virtual) processors than you have physical processors.
 
-To run multiple independent simulatoins from one input script, using
+To run multiple independent simulations from one input script, using
 multiple partitions, see "Section 6.4"_Section_howto.html#howto_4
 of the manual.  World- and universe-style "variables"_variable.html
 are useful in this context.
@@ -1673,7 +1667,7 @@ The first section provides a global loop timing summary. The {loop time}
 is the total wall time for the section.  The {Performance} line is
 provided for convenience to help predicting the number of loop
 continuations required and for comparing performance with other,
-similar MD codes.  The {CPU use} line provides the CPU utilzation per
+similar MD codes.  The {CPU use} line provides the CPU utilization per
 MPI task; it should be close to 100% times the number of OpenMP
 threads (or 1 of no OpenMP). Lower numbers correspond to delays due
 to file I/O or insufficient thread utilization.

doc/src/Section_tools.txt

@@ -48,6 +48,7 @@ own sub-directories with their own Makefiles and/or README files.
 "chain"_#chain
 "colvars"_#colvars
 "createatoms"_#createatoms
+"doxygen"_#doxygen
 "drude"_#drude
 "eam database"_#eamdb
 "eam generate"_#eamgn
@@ -110,14 +111,21 @@ back-and-forth between the CHARMM MD code and LAMMPS.
 They are intended to make it easy to use CHARMM as a builder and as a
 post-processor for LAMMPS. Using charmm2lammps.pl, you can convert a
 PDB file with associated CHARMM info, including CHARMM force field
-data, into its LAMMPS equivalent.  Using lammps2pdb.pl you can convert
-LAMMPS atom dumps into PDB files.
+data, into its LAMMPS equivalent. Support for the CMAP correction of
+CHARMM22 and later is available as an option. This tool can also add
+solvent water molecules and Na+ or Cl- ions to the system.
+Using lammps2pdb.pl you can convert LAMMPS atom dumps into PDB files.
 
 See the README file in the ch2lmp sub-directory for more information.
 
 These tools were created by Pieter in't Veld (pjintve at sandia.gov)
 and Paul Crozier (pscrozi at sandia.gov) at Sandia.
 
+CMAP support added and tested by Xiaohu Hu (hux2 at ornl.gov) and
+Robert A. Latour (latourr at clemson.edu), David Hyde-Volpe, and
+Tigran Abramyan, (Clemson University) and
+Chris Lorenz (chris.lorenz at kcl.ac.uk), King's College London.
+
 :line
 
 chain tool :h4,link(chain)
@@ -172,6 +180,18 @@ The tool is authored by Xiaowang Zhou (Sandia), xzhou at sandia.gov.
 
 :line
 
+doxygen tool :h4,link(doxygen)
+
+The tools/doxygen directory contains a shell script called
+doxygen.sh which can generate a call graph and API lists using
+the "Doxygen"_http://doxygen.org software.
+
+See the included README file for details.
+
+The tool is authored by Nandor Tamaskovics, numericalfreedom at googlemail.com.
+
+:line
+
 drude tool :h4,link(drude)
 
 The tools/drude directory contains a Python script called

doc/src/accelerate_intel.txt

@@ -25,14 +25,14 @@ LAMMPS to run on the CPU cores and coprocessor cores simultaneously.
 [Currently Available USER-INTEL Styles:]
 
 Angle Styles: charmm, harmonic :ulb,l
-Bond Styles: fene, harmonic :l
+Bond Styles: fene, fourier, harmonic :l
 Dihedral Styles: charmm, harmonic, opls :l
-Fixes: nve, npt, nvt, nvt/sllod :l
+Fixes: nve, npt, nvt, nvt/sllod, nve/asphere :l
 Improper Styles: cvff, harmonic :l
 Pair Styles: airebo, airebo/morse, buck/coul/cut, buck/coul/long, 
-buck, eam, eam/alloy, eam/fs, gayberne, lj/charmm/coul/charmm, 
-lj/charmm/coul/long, lj/cut, lj/cut/coul/long, lj/long/coul/long, rebo,
-sw, tersoff :l
+buck, dpd, eam, eam/alloy, eam/fs, gayberne, lj/charmm/coul/charmm, 
+lj/charmm/coul/long, lj/cut, lj/cut/coul/long, lj/long/coul/long, 
+rebo, sw, tersoff :l
 K-Space Styles: pppm, pppm/disp :l
 :ule
 
@@ -54,11 +54,12 @@ warmup run (for use with offload benchmarks).
 :c,image(JPG/user_intel.png)
 
 Results are speedups obtained on Intel Xeon E5-2697v4 processors
-(code-named Broadwell) and Intel Xeon Phi 7250 processors
-(code-named Knights Landing) with "June 2017" LAMMPS built with
-Intel Parallel Studio 2017 update 2. Results are with 1 MPI task
-per physical core. See {src/USER-INTEL/TEST/README} for the raw
-simulation rates and instructions to reproduce.
+(code-named Broadwell), Intel Xeon Phi 7250 processors (code-named
+Knights Landing), and Intel Xeon Gold 6148 processors (code-named
+Skylake) with "June 2017" LAMMPS built with Intel Parallel Studio
+2017 update 2. Results are with 1 MPI task per physical core. See
+{src/USER-INTEL/TEST/README} for the raw simulation rates and
+instructions to reproduce.
 
 :line
 
@@ -77,11 +78,16 @@ order of operations compared to LAMMPS without acceleration:
 Neighbor lists can be created in a different order :ulb,l
 Bins used for sorting atoms can be oriented differently :l
 The default stencil order for PPPM is 7. By default, LAMMPS will
-calculate other PPPM parameters to fit the desired acuracy with
+calculate other PPPM parameters to fit the desired accuracy with
 this order :l
 The {newton} setting applies to all atoms, not just atoms shared
 between MPI tasks :l
 Vectorization can change the order for adding pairwise forces :l
+When using the -DLMP_USE_MKL_RNG define (all included intel optimized
+makefiles do) at build time, the random number generator for
+dissipative particle dynamics (pair style dpd/intel) uses the Mersenne
+Twister generator included in the Intel MKL library (that should be
+more robust than the default Masaglia random number generator) :l
 :ule
 
 The precision mode (described below) used with the USER-INTEL
@@ -119,8 +125,8 @@ For Intel Xeon Phi CPUs:
 Runs should be performed using MCDRAM. :ulb,l
 :ule
 
-For simulations using {kspace_style pppm} on Intel CPUs
-supporting AVX-512:
+For simulations using {kspace_style pppm} on Intel CPUs supporting
+AVX-512:
 
 Add "kspace_modify diff ad" to the input script :ulb,l
 The command-line option should be changed to
@@ -237,14 +243,17 @@ However, if you do not have coprocessors on your system, building
 without offload support will produce a smaller binary.
 
 The general requirements for Makefiles with the USER-INTEL package
-are as follows. "-DLAMMPS_MEMALIGN=64" is required for CCFLAGS. When
-using Intel compilers, "-restrict" is required and "-qopenmp" is
-highly recommended for CCFLAGS and LINKFLAGS. LIB should include
-"-ltbbmalloc". For builds supporting offload, "-DLMP_INTEL_OFFLOAD"
-is required for CCFLAGS and "-qoffload" is required for LINKFLAGS.
-Other recommended CCFLAG options for best performance are
-"-O2 -fno-alias -ansi-alias -qoverride-limits fp-model fast=2
--no-prec-div".
+are as follows. When using Intel compilers, "-restrict" is required 
+and "-qopenmp" is highly recommended for CCFLAGS and LINKFLAGS. 
+CCFLAGS should include "-DLMP_INTEL_USELRT" (unless POSIX Threads
+are not supported in the build environment) and "-DLMP_USE_MKL_RNG"
+(unless Intel Math Kernel Library (MKL) is not available in the build
+environment). For Intel compilers, LIB should include "-ltbbmalloc" 
+or if the library is not available, "-DLMP_INTEL_NO_TBB" can be added
+to CCFLAGS. For builds supporting offload, "-DLMP_INTEL_OFFLOAD" is
+required for CCFLAGS and "-qoffload" is required for LINKFLAGS. Other
+recommended CCFLAG options for best performance are "-O2 -fno-alias
+-ansi-alias -qoverride-limits fp-model fast=2 -no-prec-div".
 
 NOTE: The vectorization and math capabilities can differ depending on
 the CPU. For Intel compilers, the "-x" flag specifies the type of
@@ -361,10 +370,14 @@ intel"_package.html command that can improve performance when using
 "PPPM"_kspace_style.html for long-range electrostatics on processors
 with SMT. It generates an extra pthread for each MPI task. The thread
 is dedicated to performing some of the PPPM calculations and MPI
-communications. On Intel Xeon Phi x200 series CPUs, this will likely
-always improve performance, even on a single node. On Intel Xeon
-processors, using this mode might result in better performance when
-using multiple nodes, depending on the machine. To use this mode,
+communications. This feature requires setting the preprocessor flag
+-DLMP_INTEL_USELRT in the makefile when compiling LAMMPS. It is unset
+in the default makefiles ({Makefile.mpi} and {Makefile.serial}) but
+it is set in all makefiles tuned for the USER-INTEL package.  On Intel
+Xeon Phi x200 series CPUs, the LRT feature will likely improve
+performance, even on a single node. On Intel Xeon processors, using
+this mode might result in better performance when using multiple nodes,
+depending on the specific machine configuration. To enable LRT mode,
 specify that the number of OpenMP threads is one less than would
 normally be used for the run and add the "lrt yes" option to the "-pk"
 command-line suffix or "package intel" command. For example, if a run

doc/src/accelerate_kokkos.txt

@@ -11,336 +11,346 @@
 
 5.3.3 KOKKOS package :h5
 
-The KOKKOS package was developed primarily by Christian Trott (Sandia)
-with contributions of various styles by others, including Sikandar
-Mashayak (UIUC), Stan Moore (Sandia), and Ray Shan (Sandia).  The
-underlying Kokkos library was written primarily by Carter Edwards,
+Kokkos is a templated C++ library that provides abstractions to allow
+a single implementation of an application kernel (e.g. a pair style) to run efficiently on
+different kinds of hardware, such as GPUs, Intel Xeon Phis, or many-core
+CPUs. Kokkos maps the C++ kernel onto different backend languages such as CUDA, OpenMP, or Pthreads.
+The Kokkos library also provides data abstractions to adjust (at
+compile time) the memory layout of data structures like 2d and
+3d arrays to optimize performance on different hardware. For more information on Kokkos, see
+"Github"_https://github.com/kokkos/kokkos. Kokkos is part of
+"Trilinos"_http://trilinos.sandia.gov/packages/kokkos. The Kokkos library was written primarily by Carter Edwards,
 Christian Trott, and Dan Sunderland (all Sandia).
 
-The KOKKOS package contains versions of pair, fix, and atom styles
+The LAMMPS KOKKOS package contains versions of pair, fix, and atom styles
 that use data structures and macros provided by the Kokkos library,
-which is included with LAMMPS in lib/kokkos.
-
-The Kokkos library is part of
-"Trilinos"_http://trilinos.sandia.gov/packages/kokkos and can also be
-downloaded from "Github"_https://github.com/kokkos/kokkos. Kokkos is a
-templated C++ library that provides two key abstractions for an
-application like LAMMPS.  First, it allows a single implementation of
-an application kernel (e.g. a pair style) to run efficiently on
-different kinds of hardware, such as a GPU, Intel Phi, or many-core
-CPU.
-
-The Kokkos library also provides data abstractions to adjust (at
-compile time) the memory layout of basic data structures like 2d and
-3d arrays and allow the transparent utilization of special hardware
-load and store operations.  Such data structures are used in LAMMPS to
-store atom coordinates or forces or neighbor lists.  The layout is
-chosen to optimize performance on different platforms.  Again this
-functionality is hidden from the developer, and does not affect how
-the kernel is coded.
-
-These abstractions are set at build time, when LAMMPS is compiled with
-the KOKKOS package installed.  All Kokkos operations occur within the
-context of an individual MPI task running on a single node of the
-machine.  The total number of MPI tasks used by LAMMPS (one or
-multiple per compute node) is set in the usual manner via the mpirun
-or mpiexec commands, and is independent of Kokkos.
+which is included with LAMMPS in /lib/kokkos. The KOKKOS package was developed primarily by Christian Trott (Sandia)
+and Stan Moore (Sandia) with contributions of various styles by others, including Sikandar
+Mashayak (UIUC), Ray Shan (Sandia), and Dan Ibanez (Sandia). For more information on developing using Kokkos abstractions
+see the Kokkos programmers' guide at /lib/kokkos/doc/Kokkos_PG.pdf.
 
 Kokkos currently provides support for 3 modes of execution (per MPI
-task).  These are OpenMP (for many-core CPUs), Cuda (for NVIDIA GPUs),
-and OpenMP (for Intel Phi).  Note that the KOKKOS package supports
-running on the Phi in native mode, not offload mode like the
-USER-INTEL package supports.  You choose the mode at build time to
+task). These are Serial (MPI-only for CPUs and Intel Phi), OpenMP (threading
+for many-core CPUs and Intel Phi), and CUDA (for NVIDIA GPUs). You choose the mode at build time to
 produce an executable compatible with specific hardware.
 
-Here is a quick overview of how to use the KOKKOS package
-for CPU acceleration, assuming one or more 16-core nodes.
-More details follow.
+[Building LAMMPS with the KOKKOS package:]
 
-use a C++11 compatible compiler
+NOTE: Kokkos support within LAMMPS must be built with a C++11 compatible
+compiler. This means GCC version 4.7.2 or later, Intel 14.0.4 or later, or
+Clang 3.5.2 or later is required.
+
+The recommended method of building the KOKKOS package is to start with the provided Kokkos
+Makefiles in /src/MAKE/OPTIONS/. You may need to modify the KOKKOS_ARCH variable in the Makefile
+to match your specific hardware. For example:
+
+for Sandy Bridge CPUs, set KOKKOS_ARCH=SNB
+for Broadwell CPUs, set KOKKOS_ARCH=BWD
+for K80 GPUs, set KOKKOS_ARCH=Kepler37
+for P100 GPUs and Power8 CPUs, set KOKKOS_ARCH=Pascal60,Power8 :ul
+
+See the [Advanced Kokkos Options] section below for a listing of all KOKKOS_ARCH options.
+
+[Compile for CPU-only (MPI only, no threading):]
+
+use a C++11 compatible compiler and set KOKKOS_ARCH variable in
+/src/MAKE/OPTIONS/Makefile.kokkos_mpi_only as described above. Then do the
+following:
+
+cd lammps/src
 make yes-kokkos
-make mpi KOKKOS_DEVICES=OpenMP                 # build with the KOKKOS package
-make kokkos_omp                                # or Makefile.kokkos_omp already has variable set :pre
+make kokkos_mpi_only :pre
 
-mpirun -np 16 lmp_mpi -k on -sf kk -in in.lj              # 1 node, 16 MPI tasks/node, no threads
-mpirun -np 2 -ppn 1 lmp_mpi -k on t 16 -sf kk -in in.lj   # 2 nodes, 1 MPI task/node, 16 threads/task
-mpirun -np 2 lmp_mpi -k on t 8 -sf kk -in in.lj           # 1 node, 2 MPI tasks/node, 8 threads/task
-mpirun -np 32 -ppn 4 lmp_mpi -k on t 4 -sf kk -in in.lj   # 8 nodes, 4 MPI tasks/node, 4 threads/task :pre
+[Compile for CPU-only (MPI plus OpenMP threading):]
 
-specify variables and settings in your Makefile.machine that enable OpenMP, GPU, or Phi support
-include the KOKKOS package and build LAMMPS
-enable the KOKKOS package and its hardware options via the "-k on" command-line switch use KOKKOS styles in your input script :ul
-
-Here is a quick overview of how to use the KOKKOS package for GPUs,
-assuming one or more nodes, each with 16 cores and a GPU.  More
-details follow.
-
-discuss use of NVCC, which Makefiles to examine
-
-use a C++11 compatible compiler
-KOKKOS_DEVICES = Cuda, OpenMP
-KOKKOS_ARCH = Kepler35
-make yes-kokkos
-make machine :pre
-
-mpirun -np 1 lmp_cuda -k on t 6 -sf kk -in in.lj          # one MPI task, 6 threads on CPU
-mpirun -np 4 -ppn 1 lmp_cuda -k on t 6 -sf kk -in in.lj   # ditto on 4 nodes :pre
-
-mpirun -np 2 lmp_cuda -k on t 8 g 2 -sf kk -in in.lj           # two MPI tasks, 8 threads per CPU
-mpirun -np 32 -ppn 2 lmp_cuda -k on t 8 g 2 -sf kk -in in.lj   # ditto on 16 nodes :pre
-
-Here is a quick overview of how to use the KOKKOS package
-for the Intel Phi:
-
-use a C++11 compatible compiler
-KOKKOS_DEVICES = OpenMP
-KOKKOS_ARCH = KNC
-make yes-kokkos
-make machine :pre
-
-host=MIC, Intel Phi with 61 cores (240 threads/phi via 4x hardware threading):
-mpirun -np 1 lmp_g++ -k on t 240 -sf kk -in in.lj           # 1 MPI task on 1 Phi, 1*240 = 240
-mpirun -np 30 lmp_g++ -k on t 8 -sf kk -in in.lj            # 30 MPI tasks on 1 Phi, 30*8 = 240
-mpirun -np 12 lmp_g++ -k on t 20 -sf kk -in in.lj           # 12 MPI tasks on 1 Phi, 12*20 = 240
-mpirun -np 96 -ppn 12 lmp_g++ -k on t 20 -sf kk -in in.lj   # ditto on 8 Phis :pre
-
-[Required hardware/software:]
-
-Kokkos support within LAMMPS must be built with a C++11 compatible
-compiler.  If using gcc, version 4.7.2 or later is required.
-
-To build with Kokkos support for CPUs, your compiler must support the
+NOTE: To build with Kokkos support for OpenMP threading, your compiler must support the
 OpenMP interface. You should have one or more multi-core CPUs so that
 multiple threads can be launched by each MPI task running on a CPU.
 
-To build with Kokkos support for NVIDIA GPUs, NVIDIA CUDA software
+use a C++11 compatible compiler and set KOKKOS_ARCH variable in
+/src/MAKE/OPTIONS/Makefile.kokkos_omp as described above.  Then do the
+following:
+
+cd lammps/src
+make yes-kokkos
+make kokkos_omp :pre
+
+[Compile for Intel KNL Xeon Phi (Intel Compiler, OpenMPI):]
+
+use a C++11 compatible compiler and do the following:
+
+cd lammps/src
+make yes-kokkos
+make kokkos_phi :pre
+
+[Compile for CPUs and GPUs (with OpenMPI or MPICH):]
+
+NOTE: To build with Kokkos support for NVIDIA GPUs, NVIDIA CUDA software
 version 7.5 or later must be installed on your system. See the
 discussion for the "GPU"_accelerate_gpu.html package for details of
 how to check and do this.
 
+use a C++11 compatible compiler and set KOKKOS_ARCH variable in
+/src/MAKE/OPTIONS/Makefile.kokkos_cuda_mpi for both GPU and CPU as described
+above.  Then do the following:
+
+cd lammps/src
+make yes-kokkos
+make kokkos_cuda_mpi :pre
+
+[Alternative Methods of Compiling:]
+
+Alternatively, the KOKKOS package can be built by specifying Kokkos variables
+on the make command line. For example:
+
+make mpi KOKKOS_DEVICES=OpenMP KOKKOS_ARCH=SNB     # set the KOKKOS_DEVICES and KOKKOS_ARCH variable explicitly
+make kokkos_cuda_mpi KOKKOS_ARCH=Pascal60,Power8   # set the KOKKOS_ARCH variable explicitly :pre
+
+Setting the KOKKOS_DEVICES and KOKKOS_ARCH variables on the
+make command line requires a GNU-compatible make command. Try
+"gmake" if your system's standard make complains.
+
+NOTE: If you build using make line variables and re-build LAMMPS twice
+with different KOKKOS options and the *same* target, then you *must* perform a "make clean-all"
+or "make clean-machine" before each build. This is to force all the
+KOKKOS-dependent files to be re-compiled with the new options.
+
+[Running LAMMPS with the KOKKOS package:]
+
+All Kokkos operations occur within the
+context of an individual MPI task running on a single node of the
+machine. The total number of MPI tasks used by LAMMPS (one or
+multiple per compute node) is set in the usual manner via the mpirun
+or mpiexec commands, and is independent of Kokkos. E.g. the mpirun
+command in OpenMPI does this via its
+-np and -npernode switches. Ditto for MPICH via -np and -ppn.
+
+[Running on a multi-core CPU:]
+
+Here is a quick overview of how to use the KOKKOS package
+for CPU acceleration, assuming one or more 16-core nodes.
+
+mpirun -np 16 lmp_kokkos_mpi_only -k on -sf kk -in in.lj        # 1 node, 16 MPI tasks/node, no multi-threading
+mpirun -np 2 -ppn 1 lmp_kokkos_omp -k on t 16 -sf kk -in in.lj  # 2 nodes, 1 MPI task/node, 16 threads/task
+mpirun -np 2 lmp_kokkos_omp -k on t 8 -sf kk -in in.lj          # 1 node,  2 MPI tasks/node, 8 threads/task
+mpirun -np 32 -ppn 4 lmp_kokkos_omp -k on t 4 -sf kk -in in.lj  # 8 nodes, 4 MPI tasks/node, 4 threads/task :pre
+
+To run using the KOKKOS package, use the "-k on", "-sf kk" and "-pk kokkos" "command-line switches"_Section_start.html#start_7 in your mpirun command.
+You must use the "-k on" "command-line
+switch"_Section_start.html#start_7 to enable the KOKKOS package. It
+takes additional arguments for hardware settings appropriate to your
+system. Those arguments are "documented
+here"_Section_start.html#start_7. For OpenMP use:
+
+-k on t Nt :pre
+
+The "t Nt" option specifies how many OpenMP threads per MPI
+task to use with a node. The default is Nt = 1, which is MPI-only mode.
+Note that the product of MPI tasks * OpenMP
+threads/task should not exceed the physical number of cores (on a
+node), otherwise performance will suffer. If hyperthreading is enabled, then
+the product of MPI tasks * OpenMP threads/task should not exceed the
+physical number of cores * hardware threads.
+The "-k on" switch also issues a "package kokkos" command (with no
+additional arguments) which sets various KOKKOS options to default
+values, as discussed on the "package"_package.html command doc page.
+
+The "-sf kk" "command-line switch"_Section_start.html#start_7
+will automatically append the "/kk" suffix to styles that support it.
+In this manner no modification to the input script is needed. Alternatively,
+one can run with the KOKKOS package by editing the input script as described below.
+
+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
+will typically be faster to use "half" neighbor lists and set the
+Newton flag to "on", just as is the case for non-accelerated pair
+styles. It can also be faster to use non-threaded communication.
+Use the "-pk kokkos" "command-line switch"_Section_start.html#start_7 to
+change the default "package kokkos"_package.html
+options. See its doc page for details and default settings. Experimenting with
+its options can provide a speed-up for specific calculations. For example:
+
+mpirun -np 16 lmp_kokkos_mpi_only -k on -sf kk -pk kokkos newton on neigh half comm no -in in.lj       # Newton on, Half neighbor list, non-threaded comm :pre
+
+If the "newton"_newton.html command is used in the input
+script, it can also override the Newton flag defaults.
+
+[Core and Thread Affinity:]
+
+When using multi-threading, it is important for
+performance to bind both MPI tasks to physical cores, and threads to
+physical cores, so they do not migrate during a simulation.
+
+If you are not certain MPI tasks are being bound (check the defaults
+for your MPI installation), binding can be forced with these flags:
+
+OpenMPI 1.8: mpirun -np 2 --bind-to socket --map-by socket ./lmp_openmpi ...
+Mvapich2 2.0: mpiexec -np 2 --bind-to socket --map-by socket ./lmp_mvapich ... :pre
+
+For binding threads with KOKKOS OpenMP, use thread affinity
+environment variables to force binding. With OpenMP 3.1 (gcc 4.7 or
+later, intel 12 or later) setting the environment variable
+OMP_PROC_BIND=true should be sufficient. In general, for best performance
+with OpenMP 4.0 or better set OMP_PROC_BIND=spread and OMP_PLACES=threads.
+For binding threads with the
+KOKKOS pthreads option, compile LAMMPS the KOKKOS HWLOC=yes option
+as described below.
+
+[Running on Knight's Landing (KNL) Intel Xeon Phi:]
+
+Here is a quick overview of how to use the KOKKOS package
+for the Intel Knight's Landing (KNL) Xeon Phi:
+
+KNL Intel Phi chips have 68 physical cores. Typically 1 to 4 cores
+are reserved for the OS, and only 64 or 66 cores are used. Each core
+has 4 hyperthreads,so there are effectively N = 256 (4*64) or
+N = 264 (4*66) cores to run on. The product of MPI tasks * OpenMP threads/task should not exceed this limit,
+otherwise performance will suffer. Note that with the KOKKOS package you do not need to
+specify how many KNLs there are per node; each
+KNL is simply treated as running some number of MPI tasks.
+
+Examples of mpirun commands that follow these rules are shown below.
+
+Intel KNL node with 68 cores (272 threads/node via 4x hardware threading):
+mpirun -np 64 lmp_kokkos_phi -k on t 4 -sf kk -in in.lj      # 1 node, 64 MPI tasks/node, 4 threads/task
+mpirun -np 66 lmp_kokkos_phi -k on t 4 -sf kk -in in.lj      # 1 node, 66 MPI tasks/node, 4 threads/task
+mpirun -np 32 lmp_kokkos_phi -k on t 8 -sf kk -in in.lj      # 1 node, 32 MPI tasks/node, 8 threads/task
+mpirun -np 512 -ppn 64 lmp_kokkos_phi -k on t 4 -sf kk -in in.lj  # 8 nodes, 64 MPI tasks/node, 4 threads/task :pre
+
+The -np setting of the mpirun command sets the number of MPI
+tasks/node. The "-k on t Nt" command-line switch sets the number of
+threads/task as Nt. The product of these two values should be N, i.e.
+256 or 264.
+
+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. When running on KNL, this
+will typically be best for pair-wise potentials. For manybody potentials,
+using "half" neighbor lists and setting the
+Newton flag to "on" may be faster. It can also be faster to use non-threaded communication.
+Use the "-pk kokkos" "command-line switch"_Section_start.html#start_7 to
+change the default "package kokkos"_package.html
+options. See its doc page for details and default settings. Experimenting with
+its options can provide a speed-up for specific calculations. For example:
+
+mpirun -np 64 lmp_kokkos_phi -k on t 4 -sf kk -pk kokkos comm no -in in.lj      #  Newton off, full neighbor list, non-threaded comm
+mpirun -np 64 lmp_kokkos_phi -k on t 4 -sf kk -pk kokkos newton on neigh half comm no -in in.reax      # Newton on, half neighbor list, non-threaded comm :pre
+
+NOTE: MPI tasks and threads should be bound to cores as described above for CPUs.
+
+NOTE: To build with Kokkos support for Intel Xeon Phi coprocessors such as Knight's Corner (KNC), your
+system must be configured to use them in "native" mode, not "offload"
+mode like the USER-INTEL package supports.
+
+[Running on GPUs:]
+
+Use the "-k" "command-line switch"_Section_commands.html#start_7 to
+specify the number of GPUs per node. Typically the -np setting
+of the mpirun command should set the number of MPI
+tasks/node to be equal to the # of physical GPUs on the node.
+You can assign multiple MPI tasks to the same GPU with the
+KOKKOS package, but this is usually only faster if significant portions
+of the input script have not been ported to use Kokkos. Using CUDA MPS
+is recommended in this scenario. As above for multi-core CPUs (and no GPU), if N is the number
+of physical cores/node, then the number of MPI tasks/node should not exceed N.
+
+-k on g Ng :pre
+
+Here are examples of how to use the KOKKOS package for GPUs,
+assuming one or more nodes, each with two GPUs:
+
+mpirun -np 2 lmp_kokkos_cuda_openmpi -k on g 2 -sf kk -in in.lj          # 1 node,   2 MPI tasks/node, 2 GPUs/node
+mpirun -np 32 -ppn 2 lmp_kokkos_cuda_openmpi -k on g 2 -sf kk -in in.lj  # 16 nodes, 2 MPI tasks/node, 2 GPUs/node (32 GPUs total) :pre
+
+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, along with threaded communication.
+When running on Maxwell or Kepler GPUs, this will typically be best. For Pascal GPUs,
+using "half" neighbor lists and setting the
+Newton flag to "on" may be faster. For many pair styles, setting the neighbor binsize
+equal to the ghost atom cutoff will give speedup.
+Use the "-pk kokkos" "command-line switch"_Section_start.html#start_7 to
+change the default "package kokkos"_package.html
+options. See its doc page for details and default settings. Experimenting with
+its options can provide a speed-up for specific calculations. For example:
+
+mpirun -np 2 lmp_kokkos_cuda_openmpi -k on g 2 -sf kk -pk kokkos binsize 2.8 -in in.lj      # Set binsize = neighbor ghost cutoff
+mpirun -np 2 lmp_kokkos_cuda_openmpi -k on g 2 -sf kk -pk kokkos newton on neigh half binsize 2.8 -in in.lj      # Newton on, half neighborlist, set binsize = neighbor ghost cutoff :pre
+
 NOTE: For good performance of the KOKKOS package on GPUs, you must
 have Kepler generation GPUs (or later). The Kokkos library exploits
 texture cache options not supported by Telsa generation GPUs (or
 older).
 
-To build with Kokkos support for Intel Xeon Phi coprocessors, your
-sysmte must be configured to use them in "native" mode, not "offload"
-mode like the USER-INTEL package supports.
+NOTE: When using a GPU, you will achieve the best performance if your
+input script does not use fix or compute styles which are not yet
+Kokkos-enabled. This allows data to stay on the GPU for multiple
+timesteps, without being copied back to the host CPU. Invoking a
+non-Kokkos fix or compute, or performing I/O for
+"thermo"_thermo_style.html or "dump"_dump.html output will cause data
+to be copied back to the CPU incurring a performance penalty.
 
-[Building LAMMPS with the KOKKOS package:]
+NOTE: To get an accurate timing breakdown between time spend in pair,
+kspace, etc., you must set the environment variable CUDA_LAUNCH_BLOCKING=1.
+However, this will reduce performance and is not recommended for production runs.
 
-You must choose at build time whether to build for CPUs (OpenMP),
-GPUs, or Phi.
+[Run with the KOKKOS package by editing an input script:]
 
-You can do any of these in one line, using the suitable make command
-line flags as described in "Section 4"_Section_packages.html of the
-manual. If run from the src directory, these
-commands will create src/lmp_kokkos_omp, lmp_kokkos_cuda, and
-lmp_kokkos_phi.  Note that the OMP and PHI options use
-src/MAKE/Makefile.mpi as the starting Makefile.machine.  The CUDA
-option uses src/MAKE/OPTIONS/Makefile.kokkos_cuda.
-
-The latter two steps can be done using the "-k on", "-pk kokkos" and
-"-sf kk" "command-line switches"_Section_start.html#start_6
-respectively.  Or the effect of the "-pk" or "-sf" switches can be
+Alternatively the effect of the "-sf" or "-pk" switches can be
 duplicated by adding the "package kokkos"_package.html or "suffix
-kk"_suffix.html commands respectively to your input script.
+kk"_suffix.html commands to your input script.
 
-
-Or you can follow these steps:
-
-CPU-only (run all-MPI or with OpenMP threading):
-
-cd lammps/src
-make yes-kokkos
-make kokkos_omp :pre
-
-CPU-only (only MPI, no threading):
-
-cd lammps/src
-make yes-kokkos
-make kokkos_mpi :pre
-
-Intel Xeon Phi (Intel Compiler, Intel MPI):
-
-cd lammps/src
-make yes-kokkos
-make kokkos_phi :pre
-
-CPUs and GPUs (with MPICH):
-
-cd lammps/src
-make yes-kokkos
-make kokkos_cuda_mpich :pre
-
-These examples set the KOKKOS-specific OMP, MIC, CUDA variables on the
-make command line which requires a GNU-compatible make command.  Try
-"gmake" if your system's standard make complains.
-
-NOTE: If you build using make line variables and re-build LAMMPS twice
-with different KOKKOS options and the *same* target, e.g. g++ in the
-first two examples above, then you *must* perform a "make clean-all"
-or "make clean-machine" before each build.  This is to force all the
-KOKKOS-dependent files to be re-compiled with the new options.
-
-NOTE: Currently, there are no precision options with the KOKKOS
-package.  All compilation and computation is performed in double
-precision.
-
-There are other allowed options when building with the KOKKOS package.
-As above, they can be set either as variables on the make command line
-or in Makefile.machine.  This is the full list of options, including
-those discussed above, Each takes a value shown below.  The
-default value is listed, which is set in the
-lib/kokkos/Makefile.kokkos file.
-
-#Default settings specific options
-#Options: force_uvm,use_ldg,rdc
-
-KOKKOS_DEVICES, values = {OpenMP}, {Serial}, {Pthreads}, {Cuda}, default = {OpenMP}
-KOKKOS_ARCH, values = {KNC}, {SNB}, {HSW}, {Kepler}, {Kepler30}, {Kepler32}, {Kepler35}, {Kepler37}, {Maxwell}, {Maxwell50}, {Maxwell52}, {Maxwell53}, {ARMv8}, {BGQ}, {Power7}, {Power8}, default = {none}
-KOKKOS_DEBUG, values = {yes}, {no}, default = {no}
-KOKKOS_USE_TPLS, values = {hwloc}, {librt}, default = {none}
-KOKKOS_CUDA_OPTIONS, values = {force_uvm}, {use_ldg}, {rdc} :ul
-
-KOKKOS_DEVICE sets the parallelization method used for Kokkos code
-(within LAMMPS).  KOKKOS_DEVICES=OpenMP means that OpenMP will be
-used.  KOKKOS_DEVICES=Pthreads means that pthreads will be used.
-KOKKOS_DEVICES=Cuda means an NVIDIA GPU running CUDA will be used.
-
-If KOKKOS_DEVICES=Cuda, then the lo-level Makefile in the src/MAKE
-directory must use "nvcc" as its compiler, via its CC setting.  For
-best performance its CCFLAGS setting should use -O3 and have a
-KOKKOS_ARCH setting that matches the compute capability of your NVIDIA
-hardware and software installation, e.g. KOKKOS_ARCH=Kepler30.  Note
-the minimal required compute capability is 2.0, but this will give
-significantly reduced performance compared to Kepler generation GPUs
-with compute capability 3.x.  For the LINK setting, "nvcc" should not
-be used; instead use g++ or another compiler suitable for linking C++
-applications.  Often you will want to use your MPI compiler wrapper
-for this setting (i.e. mpicxx).  Finally, the lo-level Makefile must
-also have a "Compilation rule" for creating *.o files from *.cu files.
-See src/Makefile.cuda for an example of a lo-level Makefile with all
-of these settings.
-
-KOKKOS_USE_TPLS=hwloc binds threads to hardware cores, so they do not
-migrate during a simulation.  KOKKOS_USE_TPLS=hwloc should always be
-used if running with KOKKOS_DEVICES=Pthreads for pthreads.  It is not
-necessary for KOKKOS_DEVICES=OpenMP for OpenMP, because OpenMP
-provides alternative methods via environment variables for binding
-threads to hardware cores.  More info on binding threads to cores is
-given in "Section 5.3"_Section_accelerate.html#acc_3.
-
-KOKKOS_ARCH=KNC enables compiler switches needed when compiling for an
-Intel Phi processor.
-
-KOKKOS_USE_TPLS=librt enables use of a more accurate timer mechanism
-on most Unix platforms.  This library is not available on all
-platforms.
-
-KOKKOS_DEBUG is only useful when developing a Kokkos-enabled style
-within LAMMPS.  KOKKOS_DEBUG=yes enables printing of run-time
-debugging information that can be useful.  It also enables runtime
-bounds checking on Kokkos data structures.
-
-KOKKOS_CUDA_OPTIONS are additional options for CUDA.
-
-For more information on Kokkos see the Kokkos programmers' guide here:
-/lib/kokkos/doc/Kokkos_PG.pdf.
-
-[Run with the KOKKOS package from the command line:]
-
-The mpirun or mpiexec command sets the total number of MPI tasks used
-by LAMMPS (one or multiple per compute node) and the number of MPI
-tasks used per node.  E.g. the mpirun command in MPICH does this via
-its -np and -ppn switches.  Ditto for OpenMPI via -np and -npernode.
-
-When using KOKKOS built with host=OMP, you need to choose how many
-OpenMP threads per MPI task will be used (via the "-k" command-line
-switch discussed below).  Note that the product of MPI tasks * OpenMP
-threads/task should not exceed the physical number of cores (on a
-node), otherwise performance will suffer.
-
-When using the KOKKOS package built with device=CUDA, you must use
-exactly one MPI task per physical GPU.
-
-When using the KOKKOS package built with host=MIC for Intel Xeon Phi
-coprocessor support you need to insure there are one or more MPI tasks
-per coprocessor, and choose the number of coprocessor threads to use
-per MPI task (via the "-k" command-line switch discussed below).  The
-product of MPI tasks * coprocessor threads/task should not exceed the
-maximum number of threads the coprocessor is designed to run,
-otherwise performance will suffer.  This value is 240 for current
-generation Xeon Phi(TM) chips, which is 60 physical cores * 4
-threads/core.  Note that with the KOKKOS package you do not need to
-specify how many Phi coprocessors there are per node; each
-coprocessors is simply treated as running some number of MPI tasks.
-
-You must use the "-k on" "command-line
-switch"_Section_start.html#start_6 to enable the KOKKOS package.  It
-takes additional arguments for hardware settings appropriate to your
-system.  Those arguments are "documented
-here"_Section_start.html#start_6.  The two most commonly used
-options are:
-
--k on t Nt g Ng :pre
-
-The "t Nt" option applies to host=OMP (even if device=CUDA) and
-host=MIC.  For host=OMP, it specifies how many OpenMP threads per MPI
-task to use with a node.  For host=MIC, it specifies how many Xeon Phi
-threads per MPI task to use within a node.  The default is Nt = 1.
-Note that for host=OMP this is effectively MPI-only mode which may be
-fine.  But for host=MIC you will typically end up using far less than
-all the 240 available threads, which could give very poor performance.
-
-The "g Ng" option applies to device=CUDA.  It specifies how many GPUs
-per compute node to use.  The default is 1, so this only needs to be
-specified is you have 2 or more GPUs per compute node.
-
-The "-k on" switch also issues a "package kokkos" command (with no
-additional arguments) which sets various KOKKOS options to default
-values, as discussed on the "package"_package.html command doc page.
-
-Use the "-sf kk" "command-line switch"_Section_start.html#start_6,
-which will automatically append "kk" to styles that support it.  Use
-the "-pk kokkos" "command-line switch"_Section_start.html#start_6 if
-you wish to change any of the default "package kokkos"_package.html
-optionns set by the "-k on" "command-line
-switch"_Section_start.html#start_6.
-
-
-
-Note that 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.  This typically gives fastest
-performance.  If the "newton"_newton.html command is used in the input
-script, it can override the Newton flag defaults.
-
-However, when running in MPI-only mode with 1 thread per MPI task, it
-will typically be faster to use "half" neighbor lists and set the
-Newton flag to "on", just as is the case for non-accelerated pair
-styles.  You can do this with the "-pk" "command-line
-switch"_Section_start.html#start_6.
-
-[Or run with the KOKKOS package by editing an input script:]
-
-The discussion above for the mpirun/mpiexec command and setting
-appropriate thread and GPU values for host=OMP or host=MIC or
-device=CUDA are the same.
+The discussion above for building LAMMPS with the KOKKOS package, the mpirun/mpiexec command, and setting
+appropriate thread are the same.
 
 You must still use the "-k on" "command-line
-switch"_Section_start.html#start_6 to enable the KOKKOS package, and
+switch"_Section_start.html#start_7 to enable the KOKKOS package, and
 specify its additional arguments for hardware options appropriate to
 your system, as documented above.
 
-Use the "suffix kk"_suffix.html command, or you can explicitly add a
+You can use the "suffix kk"_suffix.html command, or you can explicitly add a
 "kk" suffix to individual styles in your input script, e.g.
 
 pair_style lj/cut/kk 2.5 :pre
 
 You only need to use the "package kokkos"_package.html command if you
 wish to change any of its option defaults, as set by the "-k on"
-"command-line switch"_Section_start.html#start_6.
+"command-line switch"_Section_start.html#start_7.
+
+[Using OpenMP threading and CUDA together (experimental):]
+
+With the KOKKOS package, both OpenMP multi-threading and GPUs can be used
+together in a few special cases. In the Makefile, the KOKKOS_DEVICES variable must
+include both "Cuda" and "OpenMP", as is the case for /src/MAKE/OPTIONS/Makefile.kokkos_cuda_mpi
+
+KOKKOS_DEVICES=Cuda,OpenMP :pre
+
+The suffix "/kk" is equivalent to "/kk/device", and for Kokkos CUDA,
+using the "-sf kk" in the command line gives the default CUDA version everywhere.
+However, if the "/kk/host" suffix is added to a specific style in the input
+script, the Kokkos OpenMP (CPU) version of that specific style will be used instead.
+Set the number of OpenMP threads as "t Nt" and the number of GPUs as "g Ng"
+
+-k on t Nt g Ng :pre
+
+For example, the command to run with 1 GPU and 8 OpenMP threads is then:
+
+mpiexec -np 1 lmp_kokkos_cuda_openmpi -in in.lj -k on g 1 t 8 -sf kk :pre
+
+Conversely, if the "-sf kk/host" is used in the command line and then the
+"/kk" or "/kk/device" suffix is added to a specific style in your input script,
+then only that specific style will run on the GPU while everything else will
+run on the CPU in OpenMP mode. Note that the execution of the CPU and GPU
+styles will NOT overlap, except for a special case:
+
+A kspace style and/or molecular topology (bonds, angles, etc.) running on
+the host CPU can overlap with a pair style running on the GPU. First compile
+with "--default-stream per-thread" added to CCFLAGS in the Kokkos CUDA Makefile.
+Then explicitly use the "/kk/host" suffix for kspace and bonds, angles, etc.
+in the input file and the "kk" suffix (equal to "kk/device") on the command line.
+Also make sure the environment variable CUDA_LAUNCH_BLOCKING is not set to "1"
+so CPU/GPU overlap can occur.
 
 [Speed-ups to expect:]
 
@@ -363,7 +373,7 @@ package. :l
 When running large number of atoms per GPU, KOKKOS is typically faster
 than the GPU package. :l
 
-When running on Intel Xeon Phi, KOKKOS is not as fast as
+When running on Intel hardware, KOKKOS is not as fast as
 the USER-INTEL package, which is optimized for that hardware. :l
 :ule
 
@@ -371,123 +381,78 @@ See the "Benchmark page"_http://lammps.sandia.gov/bench.html of the
 LAMMPS web site for performance of the KOKKOS package on different
 hardware.
 
-[Guidelines for best performance:]
+[Advanced Kokkos options:]
 
-Here are guidline for using the KOKKOS package on the different
-hardware configurations listed above.
+There are other allowed options when building with the KOKKOS package.
+As above, they can be set either as variables on the make command line
+or in Makefile.machine. This is the full list of options, including
+those discussed above. Each takes a value shown below. The
+default value is listed, which is set in the
+/lib/kokkos/Makefile.kokkos file.
 
-Many of the guidelines use the "package kokkos"_package.html command
-See its doc page for details and default settings.  Experimenting with
-its options can provide a speed-up for specific calculations.
+KOKKOS_DEVICES, values = {Serial}, {OpenMP}, {Pthreads}, {Cuda}, default = {OpenMP}
+KOKKOS_ARCH, values = {KNC}, {SNB}, {HSW}, {Kepler30}, {Kepler32}, {Kepler35}, {Kepler37}, {Maxwell50}, {Maxwell52}, {Maxwell53}, {Pascal60}, {Pascal61}, {ARMv80}, {ARMv81}, {ARMv81}, {ARMv8-ThunderX}, {BGQ}, {Power7}, {Power8}, {Power9}, {KNL}, {BDW}, {SKX}, default = {none}
+KOKKOS_DEBUG, values = {yes}, {no}, default = {no}
+KOKKOS_USE_TPLS, values = {hwloc}, {librt}, {experimental_memkind}, default = {none}
+KOKKOS_CXX_STANDARD, values = {c++11}, {c++1z}, default = {c++11}
+KOKKOS_OPTIONS, values = {aggressive_vectorization}, {disable_profiling}, default = {none}
+KOKKOS_CUDA_OPTIONS, values = {force_uvm}, {use_ldg}, {rdc}, {enable_lambda}, default = {enable_lambda} :ul
 
-[Running on a multi-core CPU:]
+KOKKOS_DEVICES sets the parallelization method used for Kokkos code
+(within LAMMPS). KOKKOS_DEVICES=Serial means that no threading will be used.
+KOKKOS_DEVICES=OpenMP means that OpenMP threading will be
+used. KOKKOS_DEVICES=Pthreads means that pthreads will be used.
+KOKKOS_DEVICES=Cuda means an NVIDIA GPU running CUDA will be used.
 
-If N is the number of physical cores/node, then the number of MPI
-tasks/node * number of threads/task should not exceed N, and should
-typically equal N.  Note that the default threads/task is 1, as set by
-the "t" keyword of the "-k" "command-line
-switch"_Section_start.html#start_6.  If you do not change this, no
-additional parallelism (beyond MPI) will be invoked on the host
-CPU(s).
+KOKKOS_ARCH enables compiler switches needed when compiling for a
+specific hardware:
 
-You can compare the performance running in different modes:
+ARMv80 = ARMv8.0 Compatible CPU
+ARMv81 = ARMv8.1 Compatible CPU
+ARMv8-ThunderX = ARMv8 Cavium ThunderX CPU
+SNB = Intel Sandy/Ivy Bridge CPUs
+HSW = Intel Haswell CPUs
+BDW = Intel Broadwell Xeon E-class CPUs
+SKX = Intel Sky Lake Xeon E-class HPC CPUs (AVX512)
+KNC = Intel Knights Corner Xeon Phi
+KNL = Intel Knights Landing Xeon Phi
+Kepler30 = NVIDIA Kepler generation CC 3.0
+Kepler32 = NVIDIA Kepler generation CC 3.2
+Kepler35 = NVIDIA Kepler generation CC 3.5
+Kepler37 = NVIDIA Kepler generation CC 3.7
+Maxwell50 = NVIDIA Maxwell generation CC 5.0
+Maxwell52 = NVIDIA Maxwell generation CC 5.2
+Maxwell53 = NVIDIA Maxwell generation CC 5.3
+Pascal60 = NVIDIA Pascal generation CC 6.0
+Pascal61 = NVIDIA Pascal generation CC 6.1
+BGQ = IBM Blue Gene/Q CPUs
+Power8 = IBM POWER8 CPUs
+Power9 = IBM POWER9 CPUs :ul
 
-run with 1 MPI task/node and N threads/task
-run with N MPI tasks/node and 1 thread/task
-run with settings in between these extremes :ul
+KOKKOS_USE_TPLS=hwloc binds threads to hardware cores, so they do not
+migrate during a simulation. KOKKOS_USE_TPLS=hwloc should always be
+used if running with KOKKOS_DEVICES=Pthreads for pthreads. It is not
+necessary for KOKKOS_DEVICES=OpenMP for OpenMP, because OpenMP
+provides alternative methods via environment variables for binding
+threads to hardware cores. More info on binding threads to cores is
+given in "Section 5.3"_Section_accelerate.html#acc_3.
 
-Examples of mpirun commands in these modes are shown above.
+KOKKOS_USE_TPLS=librt enables use of a more accurate timer mechanism
+on most Unix platforms. This library is not available on all
+platforms.
 
-When using KOKKOS to perform multi-threading, it is important for
-performance to bind both MPI tasks to physical cores, and threads to
-physical cores, so they do not migrate during a simulation.
+KOKKOS_DEBUG is only useful when developing a Kokkos-enabled style
+within LAMMPS. KOKKOS_DEBUG=yes enables printing of run-time
+debugging information that can be useful. It also enables runtime
+bounds checking on Kokkos data structures.
 
-If you are not certain MPI tasks are being bound (check the defaults
-for your MPI installation), binding can be forced with these flags:
+KOKKOS_CXX_STANDARD and KOKKOS_OPTIONS are typically not changed when building LAMMPS.
 
-OpenMPI 1.8: mpirun -np 2 -bind-to socket -map-by socket ./lmp_openmpi ...
-Mvapich2 2.0: mpiexec -np 2 -bind-to socket -map-by socket ./lmp_mvapich ... :pre
-
-For binding threads with the KOKKOS OMP option, use thread affinity
-environment variables to force binding.  With OpenMP 3.1 (gcc 4.7 or
-later, intel 12 or later) setting the environment variable
-OMP_PROC_BIND=true should be sufficient.  For binding threads with the
-KOKKOS pthreads option, compile LAMMPS the KOKKOS HWLOC=yes option
-(see "this section"_Section_packages.html#KOKKOS of the manual for
-details).
-
-[Running on GPUs:]
-
-Insure the -arch setting in the machine makefile you are using,
-e.g. src/MAKE/Makefile.cuda, is correct for your GPU hardware/software.
-(see "this section"_Section_packages.html#KOKKOS of the manual for
-details).
-
-The -np setting of the mpirun command should set the number of MPI
-tasks/node to be equal to the # of physical GPUs on the node.
-
-Use the "-k" "command-line switch"_Section_commands.html#start_6 to
-specify the number of GPUs per node, and the number of threads per MPI
-task.  As above for multi-core CPUs (and no GPU), if N is the number
-of physical cores/node, then the number of MPI tasks/node * number of
-threads/task should not exceed N.  With one GPU (and one MPI task) it
-may be faster to use less than all the available cores, by setting
-threads/task to a smaller value.  This is because using all the cores
-on a dual-socket node will incur extra cost to copy memory from the
-2nd socket to the GPU.
-
-Examples of mpirun commands that follow these rules are shown above.
-
-NOTE: When using a GPU, you will achieve the best performance if your
-input script does not use any fix or compute styles which are not yet
-Kokkos-enabled.  This allows data to stay on the GPU for multiple
-timesteps, without being copied back to the host CPU.  Invoking a
-non-Kokkos fix or compute, or performing I/O for
-"thermo"_thermo_style.html or "dump"_dump.html output will cause data
-to be copied back to the CPU.
-
-You cannot yet assign multiple MPI tasks to the same GPU with the
-KOKKOS package.  We plan to support this in the future, similar to the
-GPU package in LAMMPS.
-
-You cannot yet use both the host (multi-threaded) and device (GPU)
-together to compute pairwise interactions with the KOKKOS package.  We
-hope to support this in the future, similar to the GPU package in
-LAMMPS.
-
-[Running on an Intel Phi:]
-
-Kokkos only uses Intel Phi processors in their "native" mode, i.e.
-not hosted by a CPU.
-
-As illustrated above, build LAMMPS with OMP=yes (the default) and
-MIC=yes.  The latter insures code is correctly compiled for the Intel
-Phi.  The OMP setting means OpenMP will be used for parallelization on
-the Phi, which is currently the best option within Kokkos.  In the
-future, other options may be added.
-
-Current-generation Intel Phi chips have either 61 or 57 cores.  One
-core should be excluded for running the OS, leaving 60 or 56 cores.
-Each core is hyperthreaded, so there are effectively N = 240 (4*60) or
-N = 224 (4*56) cores to run on.
-
-The -np setting of the mpirun command sets the number of MPI
-tasks/node.  The "-k on t Nt" command-line switch sets the number of
-threads/task as Nt.  The product of these 2 values should be N, i.e.
-240 or 224.  Also, the number of threads/task should be a multiple of
-4 so that logical threads from more than one MPI task do not run on
-the same physical core.
-
-Examples of mpirun commands that follow these rules are shown above.
+KOKKOS_CUDA_OPTIONS are additional options for CUDA. The LAMMPS KOKKOS package must be compiled
+with the {enable_lambda} option when using GPUs.
 
 [Restrictions:]
 
-As noted above, if using GPUs, the number of MPI tasks per compute
-node should equal to the number of GPUs per compute node.  In the
-future Kokkos will support assigning multiple MPI tasks to a single
-GPU.
-
-Currently Kokkos does not support AMD GPUs due to limits in the
-available backend programming models.  Specifically, Kokkos requires
-extensive C++ support from the Kernel language.  This is expected to
-change in the future.
+Currently, there are no precision options with the KOKKOS
+package. All compilation and computation is performed in double
+precision.

doc/src/angle_class2.txt

@@ -9,6 +9,7 @@
 angle_style class2 command :h3
 angle_style class2/omp command :h3
 angle_style class2/kk command :h3
+angle_style class2/p6 command :h3
 
 [Syntax:]
 
@@ -102,11 +103,29 @@ more instructions on how to use the accelerated styles effectively.
 
 :line
 
+The {class2/p6} angle style uses the {class2} potential expanded to sixth order:
+
+:c,image(Eqs/angle_class2_p6.jpg)
+
+In this expanded term 6 coefficients for the Ea formula need to be set:
+
+theta0 (degrees)
+K2 (energy/radian^2)
+K3 (energy/radian^3)
+K4 (energy/radian^4)
+K5 (energy/radian^5)
+K6 (energy/radian^6) :ul
+
+The bond-bond and bond-angle terms remain unchanged.
+
+:line
+
 [Restrictions:]
 
 This angle style can only be used if LAMMPS was built with the CLASS2
-package.  See the "Making LAMMPS"_Section_start.html#start_3 section
-for more info on packages.
+package.  For the {class2/p6} style LAMMPS needs to be built with the
+USER-MOFFF package.  See the "Making LAMMPS"_Section_start.html#start_3 
+section for more info on packages.
 
 [Related commands:]
 

doc/src/angle_cosine_buck6d.txt

@@ -0,0 +1,65 @@
+"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
+
+angle_style cosine/buck6d command :h3
+
+[Syntax:]
+
+angle_style cosine/buck6d :pre
+
+[Examples:]
+
+angle_style cosine/buck6d
+angle_coeff 1  cosine/buck6d  1.978350  4  180.000000 :pre
+
+[Description:]
+
+The {cosine/buck6d} angle style uses the potential
+
+:c,image(Eqs/angle_cosine_buck6d.jpg)
+
+where K is the energy constant, n is the periodic multiplicity and 
+Theta0 is the equilibrium angle.
+
+The coefficients must be defined for each angle type via the 
+"angle_coeff"_angle_coeff.html command as in the example above, or in
+the data file or restart files read by the "read_data"_read_data.html
+or "read_restart"_read_restart.html commands in the following order:
+
+K (energy)
+n 
+Theta0 (degrees) :ul
+
+Theta0 is specified in degrees, but LAMMPS converts it to radians 
+internally.
+
+Additional to the cosine term the {cosine/buck6d} angle style computes 
+the short range (vdW) interaction belonging to the 
+"pair_buck6d"_pair_buck6d_coul_gauss.html between the end atoms of 
+the angle.  For this reason this angle style only works in combination
+with the "pair_buck6d"_pair_buck6d_coul_gauss.html styles and needs
+the "special_bonds"_special_bonds.html 1-3 interactions to be weighted
+0.0 to prevent double counting.
+
+:line
+
+[Restrictions:]
+
+{cosine/buck6d} can only be used in combination with the
+"pair_buck6d"_pair_buck6d_coul_gauss.html style and with a 
+"special_bonds"_special_bonds.html 0.0 weighting of 1-3 interactions.  
+
+This angle style can only be used if LAMMPS was built with the
+USER-MOFFF package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
+
+[Related commands:]
+
+"angle_coeff"_angle_coeff.html
+
+[Default:] none

doc/src/angles.txt

@@ -8,6 +8,7 @@ Angle Styles :h1
    angle_charmm
    angle_class2
    angle_cosine
+   angle_cosine_buck6d
    angle_cosine_delta
    angle_cosine_periodic
    angle_cosine_shift

doc/src/atom_modify.txt

@@ -16,7 +16,7 @@ atom_modify keyword values ... :pre
 one or more keyword/value pairs may be appended :ulb,l
 keyword = {id} or {map} or {first} or {sort} :l
    {id} value = {yes} or {no}
-   {map} value = {array} or {hash}
+   {map} value = {yes} or {array} or {hash}
    {first} value = group-ID = group whose atoms will appear first in internal atom lists
    {sort} values = Nfreq binsize
      Nfreq = sort atoms spatially every this many time steps
@@ -25,8 +25,8 @@ keyword = {id} or {map} or {first} or {sort} :l
 
 [Examples:]
 
-atom_modify map hash
-atom_modify map array sort 10000 2.0
+atom_modify map yes
+atom_modify map hash sort 10000 2.0
 atom_modify first colloid :pre
 
 [Description:]
@@ -62,29 +62,33 @@ switch.  This is described in "Section 2.2"_Section_start.html#start_2
 of the manual.  If atom IDs are not used, they must be specified as 0
 for all atoms, e.g. in a data or restart file.
 
-The {map} keyword determines how atom ID lookup is done for molecular
-atom styles.  Lookups are performed by bond (angle, etc) routines in
-LAMMPS to find the local atom index associated with a global atom ID.
+The {map} keyword determines how atoms with specific IDs are found
+when required.  An example are the bond (angle, etc) methods which
+need to find the local index of an atom with a specific global ID
+which is a bond (angle, etc) partner.  LAMMPS performs this operation
+efficiently by creating a "map", which is either an {array} or {hash}
+table, as descibed below.
 
-When the {array} value is used, each processor stores a lookup table
-of length N, where N is the largest atom ID in the system.  This is a
+When the {map} keyword is not specified in your input script, LAMMPS
+only creates a map for "atom_styles"_atom_style.html for molecular
+systems which have permanent bonds (angles, etc).  No map is created
+for atomic systems, since it is normally not needed.  However some
+LAMMPS commands require a map, even for atomic systems, and will
+generate an error if one does not exist.  The {map} keyword thus
+allows you to force the creation of a map.  The {yes} value will
+create either an {array} or {hash} style map, as explained in the next
+paragraph.  The {array} and {hash} values create an atom-style or
+hash-style map respectively.
+
+For an {array}-style map, each processor stores a lookup table of
+length N, where N is the largest atom ID in the system.  This is a
 fast, simple method for many simulations, but requires too much memory
-for large simulations.  The {hash} value uses a hash table to perform
-the lookups.  This can be slightly slower than the {array} method, but
-its memory cost is proportional to the number of atoms owned by a
-processor, i.e. N/P when N is the total number of atoms in the system
-and P is the number of processors.
-
-When this setting is not specified in your input script, LAMMPS
-creates a map, if one is needed, as an array or hash.  See the
-discussion of default values below for how LAMMPS chooses which kind
-of map to build.  Note that atomic systems do not normally need to
-create a map.  However, even in this case some LAMMPS commands will
-create a map to find atoms (and then destroy it), or require a
-permanent map.  An example of the former is the "velocity loop
-all"_velocity.html command, which uses a map when looping over all
-atoms and insuring the same velocity values are assigned to an atom
-ID, no matter which processor owns it.
+for large simulations.  For a {hash}-style map, a hash table is
+created on each processor, which finds an atom ID in constant time
+(independent of the global number of atom IDs).  It can be slightly
+slower than the {array} map, but its memory cost is proportional to
+the number of atoms owned by a processor, i.e. N/P when N is the total
+number of atoms in the system and P is the number of processors.
 
 The {first} keyword allows a "group"_group.html to be specified whose
 atoms will be maintained as the first atoms in each processor's list

doc/src/body.txt

@@ -261,7 +261,7 @@ For images created by the "dump image"_dump_image.html command, if the
 polygon consisting of N line segments.  Note that the line segments
 are drawn between the N vertices, which does not correspond exactly to
 the physical extent of the body (because the "pair_style
-rounded/polygon"_pair_body_rounded_polygon.cpp defines finite-size
+rounded/polygon"_pair_body_rounded_polygon.html defines finite-size
 spheres at those point and the line segments between the spheres are
 tangent to the spheres).  The drawn diameter of each line segment is
 determined by the {bflag1} parameter for the {body} keyword.  The

doc/src/bond_gromos.txt

@@ -0,0 +1,73 @@
+"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
+
+bond_style gromos command :h3
+bond_style gromos/omp command :h3
+
+[Syntax:]
+
+bond_style gromos :pre
+
+[Examples:]
+
+bond_style gromos
+bond_coeff 5 80.0 1.2 :pre
+
+[Description:]
+
+The {gromos} bond style uses the potential
+
+:c,image(Eqs/bond_gromos.jpg)
+
+where r0 is the equilibrium bond distance.  Note that the usual 1/4
+factor is included in K.
+
+The following coefficients must be defined for each bond type via the
+"bond_coeff"_bond_coeff.html command as in the example above, or in
+the data file or restart files read by the "read_data"_read_data.html
+or "read_restart"_read_restart.html commands:
+
+K (energy/distance^4)
+r0 (distance) :ul
+
+: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 in "Section 5"_Section_accelerate.html
+of the manual.  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 "Making
+LAMMPS"_Section_start.html#start_3 section 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"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "Section 5"_Section_accelerate.html of the manual for
+more instructions on how to use the accelerated styles effectively.
+
+:line
+
+[Restrictions:]
+
+This bond style can only be used if LAMMPS was built with the
+MOLECULE package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
+
+[Related commands:]
+
+"bond_coeff"_bond_coeff.html, "delete_bonds"_delete_bonds.html
+
+[Default:] none

doc/src/bonds.txt

@@ -8,6 +8,7 @@ Bond Styles :h1
    bond_class2
    bond_fene
    bond_fene_expand
+   bond_gromos
    bond_harmonic
    bond_harmonic_shift
    bond_harmonic_shift_cut

doc/src/commands.txt

@@ -32,6 +32,7 @@ Commands :h1
    dimension
    displace_atoms
    dump
+   dump_cfg_uef
    dump_h5md
    dump_image
    dump_modify
@@ -92,6 +93,7 @@ Commands :h1
    tad
    temper
    temper_grem
+   temper_npt
    thermo
    thermo_modify
    thermo_style

doc/src/compute.txt

@@ -169,6 +169,7 @@ by users which are included in the LAMMPS distribution.  The list of
 these with links to the individual styles are given in the compute
 section of "this page"_Section_commands.html#cmd_5.
 
+"aggregate/atom"_compute_cluster_atom.html - aggregate ID for each atom
 "angle/local"_compute_bond_local.html - theta and energy of each angle
 "angmom/chunk"_compute_angmom_chunk.html - angular momentum for each chunk
 "body/local"_compute_body_local.html - attributes of body sub-particles
@@ -191,6 +192,7 @@ section of "this page"_Section_commands.html#cmd_5.
 "erotate/sphere"_compute_erotate_sphere.html - rotational energy of spherical particles
 "erotate/sphere/atom"_compute_erotate_sphere.html - rotational energy for each spherical particle
 "event/displace"_compute_event_displace.html - detect event on atom displacement
+"fragment/atom"_compute_cluster_atom.html - fragment ID for each atom
 "group/group"_compute_group_group.html - energy/force between two groups of atoms
 "gyration"_compute_gyration.html - radius of gyration of group of atoms
 "gyration/chunk"_compute_gyration_chunk.html - radius of gyration for each chunk

doc/src/compute_cluster_atom.txt

@@ -28,7 +28,7 @@ compute 1 all aggregate/atom 3.5 :pre
 
 [Description:]
 
-Define a computation that assigns each atom a cluster, fragement,
+Define a computation that assigns each atom a cluster, fragment,
 or aggregate ID.
 
 A cluster is defined as a set of atoms, each of which is within the
@@ -53,7 +53,7 @@ like micelles.
 Only atoms in the compute group are clustered and assigned cluster
 IDs. Atoms not in the compute group are assigned a cluster ID = 0.
 For fragments, only bonds where [both] atoms of the bond are included
-in the compute group are assigned to fragments, so that only fragmets
+in the compute group are assigned to fragments, so that only fragments
 are detected where [all] atoms are in the compute group. Thus atoms
 may be included in the compute group, yes still have a fragment ID of 0.
 

doc/src/compute_dihedral_local.txt

@@ -27,8 +27,8 @@ compute 1 all dihedral/local phi :pre
 
 Define a computation that calculates properties of individual dihedral
 interactions.  The number of datums generated, aggregated across all
-processors, equals the number of angles in the system, modified by the
-group parameter as explained below.
+processors, equals the number of dihedral angles in the system, modified
+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.

doc/src/compute_orientorder_atom.txt

@@ -67,7 +67,7 @@ parameters. This is followed by that number of integers giving the
 degree of each order parameter. Because {Q}2 and all odd-degree order
 parameters are zero for atoms in cubic crystals (see
 "Steinhardt"_#Steinhardt), the default order parameters are {Q}4,
-{Q}6, {Q}8, {Q}10, and {Q}12. For the FCC crystal with {nnn}=12, {Q}4
+{Q}6, {Q}8, {Q}10, and {Q}12. For the FCC crystal with {nnn} =12, {Q}4
 = sqrt(7/3)/8 = 0.19094....  The numerical values of all order
 parameters up to {Q}12 for a range of commonly encountered
 high-symmetry structures are given in Table I of "Mickel et

doc/src/compute_pressure_uef.txt

@@ -0,0 +1,61 @@
+"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/uef command :h3
+
+[Syntax:]
+
+compute ID group-ID pressure/uef temp-ID keyword ... :pre
+
+ID, group-ID are documented in "compute"_compute.html command
+pressure/uef = style name of this compute command
+temp-ID = ID of compute that calculates temperature, can be NULL if not needed
+zero or more keywords may be appended
+keyword = {ke} or {pair} or {bond} or {angle} or {dihedral} or {improper} or {kspace} or {fix} or {virial} :ul
+
+[Examples:]
+
+compute 1 all pressure/uef my_temp_uef
+compute 2 all pressure/uef my_temp_uef virial :pre
+
+[Description:]
+
+This command is used to compute the pressure tensor in
+the reference frame of the applied flow field when
+"fix nvt/uef"_fix_nh_uef.html" or
+"fix npt/uef"_fix_nh_uef.html" is used.
+It is not necessary to use this command to compute the scalar
+value of the pressure. A "compute pressure"_compute_pressure.html
+may be used for that purpose.
+
+The keywords and output information are documented in
+"compute_pressure"_compute_pressure.html.
+
+[Restrictions:]
+
+This fix is part of the USER-UEF package. It is only enabled if
+LAMMPS was built with that package. See the
+"Making LAMMPS"_Section_start.html#start_3 section for more info.
+
+This command can only be used when "fix nvt/uef"_fix_nh_uef.html
+or "fix npt/uef"_fix_nh_uef.html is active.
+
+The kinetic contribution to the pressure tensor
+will be accurate only when
+the compute specified by {temp-ID} is a
+"compute temp/uef"_compute_temp_uef.html.
+
+[Related commands:]
+
+"compute pressure"_compute_pressure.html,
+"fix nvt/uef"_fix_nh_uef.html,
+"compute temp/uef"_compute_temp_uef.html
+
+[Default:] none
+
+

doc/src/compute_sna_atom.txt

@@ -224,7 +224,7 @@ block contains six sub-blocks corresponding to the {xx}, {yy}, {zz},
 notation.  Each of these sub-blocks contains one column for each
 bispectrum component, the same as for compute {sna/atom}
 
-For example, if {K}=30 and ntypes=1, the number of columns in the per-atom
+For example, if {K} =30 and ntypes=1, the number of columns in the per-atom
 arrays generated by {sna/atom}, {snad/atom}, and {snav/atom}
 are 30, 90, and 180, respectively. With {quadratic} value=1,
 the numbers of columns are 930, 2790, and 5580, respectively.

doc/src/compute_temp_uef.txt

@@ -0,0 +1,52 @@
+"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 temp/uef command :h3
+
+[Syntax:]
+
+compute ID group-ID temp/uef :pre
+
+ID, group-ID are documented in "compute"_compute.html command
+temp/uef = style name of this compute command :ul
+
+[Examples:]
+
+compute 1 all temp/uef 
+compute 2 sel temp/uef :pre
+
+[Description:]
+
+This command is used to compute the kinetic energy tensor in 
+the reference frame of the applied flow field when
+"fix nvt/uef"_fix_nh_uef.html" or
+"fix npt/uef"_fix_nh_uef.html" is used.
+It is not necessary to use this command to compute the scalar
+value of the temperature. A "compute temp"_compute_temp.html 
+may be used for that purpose.
+
+Output information for this command can be found in the
+documentation for "compute temp"_compute_temp.html.
+
+[Restrictions:]
+
+This fix is part of the USER-UEF package. It is only enabled if 
+LAMMPS was built with that package. See the 
+"Making LAMMPS"_Section_start.html#start_3 section for more info.
+
+This command can only be used when "fix nvt/uef"_fix_nh_uef.html 
+or "fix npt/uef"_fix_nh_uef.html is active.
+
+[Related commands:]
+
+"compute temp"_compute_temp.html,
+"fix nvt/uef"_fix_nh_uef.html,
+"compute pressure/uef"_compute_pressure_uef.html
+
+
+[Default:] none

doc/src/computes.txt

@@ -65,6 +65,7 @@ Computes :h1
    compute_pe_atom
    compute_plasticity_atom
    compute_pressure
+   compute_pressure_uef
    compute_property_atom
    compute_property_chunk
    compute_property_local
@@ -114,6 +115,7 @@ Computes :h1
    compute_temp_region_eff
    compute_temp_rotate
    compute_temp_sphere
+   compute_temp_uef
    compute_ti
    compute_torque_chunk
    compute_vacf

doc/src/create_atoms.txt

@@ -36,9 +36,9 @@ keyword = {mol} or {basis} or {remap} or {var} or {set} or {units} :l
   {set} values = dim name
     dim = {x} or {y} or {z}
     name = name of variable to set with x, y, or z atom position
-  {rotate} values = Rx Ry Rz theta
-    Rx,Ry,Rz = rotation vector for single molecule
+  {rotate} values = theta Rx Ry Rz
     theta = rotation angle for single molecule (degrees)
+    Rx,Ry,Rz = rotation vector for single molecule
   {units} value = {lattice} or {box}
     {lattice} = the geometry is defined in lattice units
     {box} = the geometry is defined in simulation box units :pre
@@ -227,28 +227,30 @@ the sinusoid would appear to be "smoother".  Also note the use of the
 converts lattice spacings to distance.  Click on the image for a
 larger version.
 
+dimension       2
 variable        x equal 100
 variable        y equal 25
 lattice         hex 0.8442
 region          box block 0 $x 0 $y -0.5 0.5
 create_box      1 box :pre
 
-variable        xx equal 0.0
-variable        yy equal 0.0
+variable        xx internal 0.0
+variable        yy internal 0.0
 variable        v equal "(0.2*v_y*ylat * cos(v_xx/xlat * 2.0*PI*4.0/v_x) + 0.5*v_y*ylat - v_yy) > 0.0"
-create_atoms    1 box var v set x xx set y yy :pre
+create_atoms    1 box var v set x xx set y yy
+write_dump      all atom sinusoid.lammpstrj :pre
 
 :c,image(JPG/sinusoid_small.jpg,JPG/sinusoid.jpg)
 
-The {rotate} keyword can be used with the {single} style, when adding
-a single molecule to specify the orientation at which the molecule is
-inserted.  The axis of rotation is determined by the rotation vector
-(Rx,Ry,Rz) that goes through the insertion point.  The specified
-{theta} determines the angle of rotation around that axis.  Note that
-the direction of rotation for the atoms around the rotation axis is
-consistent with the right-hand rule: if your right-hand's thumb points
-along {R}, then your fingers wrap around the axis in the direction of
-rotation.
+The {rotate} keyword can only be used with the {single} style and
+when adding a single molecule. It allows to specify the orientation
+at which the molecule is inserted.  The axis of rotation is
+determined by the rotation vector (Rx,Ry,Rz) that goes through the
+insertion point.  The specified {theta} determines the angle of
+rotation around that axis.  Note that the direction of rotation for
+the atoms around the rotation axis is consistent with the right-hand
+rule: if your right-hand's thumb points along {R}, then your fingers
+wrap around the axis in the direction of rotation.
 
 The {units} keyword determines the meaning of the distance units used
 to specify the coordinates of the one particle created by the {single}

doc/src/create_bonds.txt

@@ -18,7 +18,7 @@ style = {many} or {single/bond} or {single/angle} or {single/dihedral} :ule,l
     group2-ID = ID of second group, bonds will be between atoms in the 2 groups
     btype = bond type of created bonds
     rmin = minimum distance between pair of atoms to bond together
-    rmax = minimum distance between pair of atoms to bond together
+    rmax = maximum distance between pair of atoms to bond together
   {single/bond} args = btype batom1 batom2
     btype = bond type of new bond
     batom1,batom2 = atom IDs for two atoms in bond

doc/src/dihedral_fourier.txt

@@ -7,6 +7,7 @@
 :line
 
 dihedral_style fourier command :h3
+dihedral_style fourier/intel command :h3
 dihedral_style fourier/omp command :h3
 
 [Syntax:]

doc/src/dump.txt

@@ -45,7 +45,7 @@ args = list of arguments for a particular style :l
   {xyz/gz} args = none
   {xyz/mpiio} args = none :pre
 
-{custom} or {custom/gz} or {custom/mpiio} args = list of atom attributes :l
+{custom} or {custom/gz} or {custom/mpiio} or {netcdf} or {netcdf/mpiio} args = list of atom attributes :l
     possible attributes = id, mol, proc, procp1, type, element, mass,
                           x, y, z, xs, ys, zs, xu, yu, zu,
                           xsu, ysu, zsu, ix, iy, iz,
@@ -649,20 +649,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.
 
 The {xtc} style is part of the MISC package.  It is only enabled if
 LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.  This is
-because some machines may not support the low-level XDR data format
-that XTC files are written with, which will result in a compile-time
-error when a low-level include file is not found.  Putting this style
-in a package makes it easy to exclude from a LAMMPS build for those
-machines.  However, the MISC package also includes two compatibility
-header files and associated functions, which should be a suitable
-substitute on machines that do not have the appropriate native header
-files.  This option can be invoked at build time by adding
--DLAMMPS_XDR to the CCFLAGS variable in the appropriate low-level
-Makefile, e.g. src/MAKE/Makefile.foo.  This compatibility mode has
-been tested successfully on Cray XT3/XT4/XT5 and IBM BlueGene/L
-machines and should also work on IBM BG/P, and Windows XP/Vista/7
-machines.
+LAMMPS"_Section_start.html#start_3 section for more info.
 
 [Related commands:]
 

doc/src/dump_cfg_uef.txt

@@ -0,0 +1,53 @@
+ "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
+
+dump cfg/uef command :h3
+
+[Syntax:]
+
+dump ID group-ID cfg/uef N file mass type xs ys zs args :pre
+
+ID = user-assigned name for the dump :ulb,l
+group-ID = ID of the group of atoms to be dumped :l
+N = dump every this many timesteps :l
+file = name of file to write dump info to :l
+args = same as args for "dump custom"_dump.html :pre
+
+:ule
+
+[Examples:]
+
+dump 1 all cfg/uef 10 dump.*.cfg mass type xs ys zs
+dump 2 all cfg/uef 100 dump.*.cfg mass type xs ys zs id c_stress :pre
+
+[Description:]
+
+This command is used to dump atomic coordinates in the
+reference frame of the applied flow field when 
+"fix nvt/uef"_fix_nh_uef.html or
+"fix npt/uef"_fix_nh_uef.html or is used. Only the atomic 
+coordinates and frame-invariant scalar quantities 
+will be in the flow frame. If velocities are selected
+as output, for example, they will not be in the same
+reference frame as the atomic positions.
+
+[Restrictions:]
+
+This fix is part of the USER-UEF package. It is only enabled if
+LAMMPS was built with that package. See the
+"Making LAMMPS"_Section_start.html#start_3 section for more info.
+
+This command can only be used when "fix nvt/uef"_fix_nh_uef.html
+or "fix npt/uef"_fix_nh_uef.html is active.
+
+[Related commands:]
+
+"dump"_dump.html,
+"fix nvt/uef"_fix_nh_uef.html
+
+[Default:] none

doc/src/dump_modify.txt

@@ -15,8 +15,9 @@ dump_modify dump-ID keyword values ... :pre
 dump-ID = ID of dump to modify :ulb,l
 one or more keyword/value pairs may be appended :l
 these keywords apply to various dump styles :l
-keyword = {append} or {buffer} or {element} or {every} or {fileper} or {first} or {flush} or {format} or {image} or {label} or {nfile} or {pad} or {precision} or {region} or {scale} or {sort} or {thresh} or {unwrap} :l
-  {append} arg = {yes} or {no} or {at} N
+keyword = {append} or {at} or {buffer} or {element} or {every} or {fileper} or {first} or {flush} or {format} or {image} or {label} or {nfile} or {pad} or {precision} or {region} or {scale} or {sort} or {thresh} or {unwrap} :l
+  {append} arg = {yes} or {no}
+  {at} arg = N
     N = index of frame written upon first dump
   {buffer} arg = {yes} or {no}
   {element} args = E1 E2 ... EN, where N = # of atom types
@@ -141,13 +142,18 @@ and {dcd}.  It also applies only to text output files, not to binary
 or gzipped or image/movie files.  If specified as {yes}, then dump
 snapshots are appended to the end of an existing dump file.  If
 specified as {no}, then a new dump file will be created which will
-overwrite an existing file with the same name.  If the {at} option is present
-({netcdf} only), then the frame to append to can be specified.  Negative values
-are counted from the end of the file.  This keyword can only take effect if the
-dump_modify command is used after the "dump"_dump.html command, but before the
-first command that causes dump snapshots to be output, e.g. a "run"_run.html or
-"minimize"_minimize.html command.  Once the dump file has been opened, this
-keyword has no further effect.
+overwrite an existing file with the same name.
+
+:line
+
+The {at} keyword only applies to the {netcdf} dump style.  It can only
+be used if the {append yes} keyword is also used.  The {N} argument is
+the index of which frame to append to.  A negative value can be
+specified for {N}, which means a frame counted from the end of the
+file.  The {at} keyword can only be used if the dump_modify command is
+before the first command that causes dump snapshots to be output,
+e.g. a "run"_run.html or "minimize"_minimize.html command.  Once the
+dump file has been opened, this keyword has no further effect.
 
 :line
 

doc/src/dump_netcdf.txt

@@ -25,7 +25,8 @@ args = list of atom attributes, same as for "dump_style custom"_dump.html :l,ule
 
 dump 1 all netcdf 100 traj.nc type x y z vx vy vz
 dump_modify 1 append yes at -1 thermo yes
-dump 1 all netcdf/mpiio 1000 traj.nc id type x y z :pre
+dump 1 all netcdf/mpiio 1000 traj.nc id type x y z
+dump 1 all netcdf 1000 traj.*.nc id type x y z :pre
 
 [Description:]
 
@@ -73,4 +74,3 @@ section for more info.
 [Related commands:]
 
 "dump"_dump.html, "dump_modify"_dump_modify.html, "undump"_undump.html
-

doc/src/fix.txt

@@ -193,6 +193,7 @@ of "this page"_Section_commands.html#cmd_5.
 "halt"_fix_halt.html - terminate a dynamics run or minimization
 "heat"_fix_heat.html - add/subtract momentum-conserving heat
 "indent"_fix_indent.html - impose force due to an indenter
+"latte"_fix_latte.html - wrapper on LATTE density-functional tight-binding code
 "langevin"_fix_langevin.html - Langevin temperature control
 "lineforce"_fix_lineforce.html - constrain atoms to move in a line
 "momentum"_fix_momentum.html - zero the linear and/or angular momentum of a group of atoms

doc/src/fix_addforce.txt

@@ -139,6 +139,11 @@ forces added by this fix in a consistent manner.  I.e. there is a
 decrease in potential energy when atoms move in the direction of the
 added force.
 
+The "fix_modify"_fix_modify.html {virial} option is supported by this
+fix to add the contribution due to the added forces on atoms to the
+system's virial as part of "thermodynamic output"_thermo_style.html.
+The default is {virial no}
+
 The "fix_modify"_fix_modify.html {respa} option is supported by this
 fix. This allows to set at which level of the "r-RESPA"_run_style.html
 integrator the fix is adding its forces. Default is the outermost

doc/src/fix_cmap.txt

@@ -97,6 +97,11 @@ The "fix_modify"_fix_modify.html {energy} option is supported by this
 fix to add the potential "energy" of the CMAP interactions 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 contribution due to the interaction between atoms 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"_Section_howto.html#howto_15.  The scalar is the
 potential energy discussed above.  The scalar value calculated by this
@@ -115,6 +120,10 @@ quantity being minimized), you MUST enable the
 
 [Restrictions:]
 
+To function as expected this fix command must be issued {before} a
+"read_data"_read_data.html command but {after} a
+"read_restart"_read_restart.html command.
+
 This fix can only be used if LAMMPS was built with the MOLECULE
 package.  See the "Making
 LAMMPS"_Section_start.html#start_3 section for more info on packages.

doc/src/fix_controller.txt

@@ -83,7 +83,7 @@ the following dynamic equation:
 :c,image(Eqs/fix_controller1.jpg)
 
 where {c} is the continuous time analog of the control variable,
-{e}={pvar}-{setpoint} is the error in the process variable, and
+{e} ={pvar}-{setpoint} is the error in the process variable, and
 {alpha}, {Kp}, {Ki}, and {Kd} are constants set by the corresponding
 keywords described above. The discretized version of this equation is:
 
@@ -106,10 +106,10 @@ the value of {alpha} to reflect this, while leaving {Kp}, {Ki}, and
 When choosing the values of the four constants, it is best to first
 pick a value and sign for {alpha} that is consistent with the
 magnitudes and signs of {pvar} and {cvar}.  The magnitude of {Kp}
-should then be tested over a large positive range keeping {Ki}={Kd}=0.
+should then be tested over a large positive range keeping {Ki} = {Kd} =0.
 A good value for {Kp} will produce a fast response in {pvar}, without
 overshooting the {setpoint}.  For many applications, proportional
-feedback is sufficient, and so {Ki}={Kd}=0 can be used. In cases where
+feedback is sufficient, and so {Ki} = {Kd} =0 can be used. In cases where
 there is a substantial lag time in the response of {pvar} to a change
 in {cvar}, this can be counteracted by increasing {Kd}. In situations
 where {pvar} plateaus without reaching {setpoint}, this can be

doc/src/fix_deform.txt

@@ -86,11 +86,16 @@ Change the volume and/or shape of the simulation box during a dynamics
 run.  Orthogonal simulation boxes have 3 adjustable parameters
 (x,y,z).  Triclinic (non-orthogonal) simulation boxes have 6
 adjustable parameters (x,y,z,xy,xz,yz).  Any or all of them can be
-adjusted independently and simultaneously by this command.  This fix
-can be used to perform non-equilibrium MD (NEMD) simulations of a
-continuously strained system.  See the "fix
+adjusted independently and simultaneously by this command.  
+
+This fix can be used to perform non-equilibrium MD (NEMD) simulations
+of a continuously strained system.  See the "fix
 nvt/sllod"_fix_nvt_sllod.html and "compute
-temp/deform"_compute_temp_deform.html commands for more details.
+temp/deform"_compute_temp_deform.html commands for more details.  Note
+that simulation of a continuously extended system (extensional flow)
+can be modeled using the "USER-UEF
+package"_Section_packages.html#USER-UEF and its "fix
+commands"_fix_nh_uef.html.
 
 For the {x}, {y}, {z} parameters, the associated dimension cannot be
 shrink-wrapped.  For the {xy}, {yz}, {xz} parameters, the associated

doc/src/fix_dpd_energy.txt

@@ -7,6 +7,7 @@
 :line
 
 fix dpd/energy command :h3
+fix dpd/energy/kk command :h3
 
 [Syntax:]
 
@@ -46,6 +47,29 @@ examples/USER/dpd directory.
 
 :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 in "Section 5"_Section_accelerate.html
+of the manual.  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 "Making
+LAMMPS"_Section_start.html#start_3 section 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"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "Section 5"_Section_accelerate.html of the manual for
+more instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restrictions:]
 
 This command is part of the USER-DPD package.  It is only enabled if

doc/src/fix_efield.txt

@@ -124,6 +124,11 @@ can include the forces added by this fix in a consistent manner.
 I.e. there is a decrease in potential energy when atoms move in the
 direction of the added force due to the electric field.
 
+The "fix_modify"_fix_modify.html {virial} option is supported by this
+fix to add the contribution due to the added forces on atoms to the
+system's virial as part of "thermodynamic output"_thermo_style.html.
+The default is {virial no}
+
 The "fix_modify"_fix_modify.html {respa} option is supported by this
 fix. This allows to set at which level of the "r-RESPA"_run_style.html
 integrator the fix adding its forces. Default is the outermost level.

doc/src/fix_eos_table_rx.txt

@@ -7,6 +7,7 @@
 :line
 
 fix eos/table/rx command :h3
+fix eos/table/rx/kk command :h3
 
 [Syntax:]
 
@@ -152,6 +153,29 @@ no      0.93 0.00 0.000 -1.76 :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 in "Section 5"_Section_accelerate.html
+of the manual.  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 "Making
+LAMMPS"_Section_start.html#start_3 section 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"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "Section 5"_Section_accelerate.html of the manual for
+more instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restrictions:]
 
 This command is part of the USER-DPD package.  It is only enabled if

doc/src/fix_external.txt

@@ -131,6 +131,11 @@ forces added by this fix in a consistent manner.  I.e. there is a
 decrease in potential energy when atoms move in the direction of the
 added force.
 
+The "fix_modify"_fix_modify.html {virial} option is supported by this
+fix to add the contribution due to the interactions computed by the
+external program 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"_Section_howto.html#howto_15.  The scalar is the
 potential energy discussed above.  The scalar stored by this fix

doc/src/fix_gcmc.txt

@@ -26,16 +26,20 @@ zero or more keyword/value pairs may be appended to args :l
 keyword = {mol}, {region}, {maxangle}, {pressure}, {fugacity_coeff}, {full_energy}, {charge}, {group}, {grouptype}, {intra_energy}, {tfac_insert}, or {overlap_cutoff}
   {mol} value = template-ID
     template-ID = ID of molecule template specified in a separate "molecule"_molecule.html command
+  {mcmoves} values = Patomtrans Pmoltrans Pmolrotate
+    Patomtrans = proportion of atom translation MC moves
+    Pmoltrans = proportion of molecule translation MC moves
+    Pmolrotate = proportion of molecule rotation MC moves
   {rigid} value = fix-ID
     fix-ID = ID of "fix rigid/small"_fix_rigid.html command
   {shake} value = fix-ID
     fix-ID = ID of "fix shake"_fix_shake.html command
   {region} value = region-ID
-    region-ID = ID of region where MC moves are allowed
+    region-ID = ID of region where GCMC exchanges and MC moves are allowed
   {maxangle} value = maximum molecular rotation angle (degrees)
   {pressure} value = pressure of the gas reservoir (pressure units)
   {fugacity_coeff} value = fugacity coefficient of the gas reservoir (unitless)
-  {full_energy} = compute the entire system energy when performing MC moves
+  {full_energy} = compute the entire system energy when performing GCMC exchanges and MC moves
   {charge} value = charge of inserted atoms (charge units)
   {group} value = group-ID
     group-ID = group-ID for inserted atoms (string)
@@ -56,34 +60,42 @@ fix 4 my_gas gcmc 1 10 10 1 123456543 300.0 -12.5 1.0 region disk :pre
 [Description:]
 
 This fix performs grand canonical Monte Carlo (GCMC) exchanges of
-atoms or molecules of the given type with an imaginary ideal gas
+atoms or molecules with an imaginary ideal gas
 reservoir at the specified T and chemical potential (mu) as discussed
-in "(Frenkel)"_#Frenkel. If used with the "fix nvt"_fix_nh.html
+in "(Frenkel)"_#Frenkel. It also
+attempts  Monte Carlo (MC) moves (translations and molecule
+rotations) within the simulation cell or
+region. If used with the "fix nvt"_fix_nh.html
 command, simulations in the grand canonical ensemble (muVT, constant
 chemical potential, constant volume, and constant temperature) can be
 performed.  Specific uses include computing isotherms in microporous
 materials, or computing vapor-liquid coexistence curves.
 
-Every N timesteps the fix attempts a number of GCMC exchanges
-(insertions or deletions) of gas atoms or molecules of the given type
-between the simulation cell and the imaginary reservoir. It also
-attempts a number of Monte Carlo moves (translations and molecule
-rotations) of gas of the given type within the simulation cell or
-region.  The average number of attempted GCMC exchanges is X. The
-average number of attempted MC moves is M.  M should typically be
+Every N timesteps the fix attempts both GCMC exchanges
+(insertions or deletions) and MC moves of gas atoms or molecules.
+On those timesteps, the average number of attempted GCMC exchanges is X,
+while the average number of attempted MC moves is M. 
+For GCMC exchanges of either molecular or atomic gasses,
+these exchanges can be either deletions or insertions,
+with equal probability.
+
+The possible choices for MC moves are translation of an atom,
+translation of a molecule, and rotation of a molecule.
+The relative amounts of each are determined by the optional
+{mcmoves} keyword (see below).
+The default behavior is as follows.
+If the {mol} keyword is used, only molecule translations
+and molecule rotations are performed with equal probability.
+Conversely, if the {mol} keyword is not used, only atom
+translations are performed.
+M should typically be
 chosen to be approximately equal to the expected number of gas atoms
 or molecules of the given type within the simulation cell or region,
-which will result in roughly one MC translation per atom or molecule
+which will result in roughly one MC move per atom or molecule
 per MC cycle.
 
-For MC moves of molecular gasses, rotations and translations are each
-attempted with 50% probability. For MC moves of atomic gasses,
-translations are attempted 100% of the time. For MC exchanges of
-either molecular or atomic gasses, deletions and insertions are each
-attempted with 50% probability.
-
-All inserted particles are always assigned to two groups: the default
-group "all" and the group specified in the fix gcmc command (which can
+All inserted particles are always added to two groups: the default
+group "all" and the fix group specified in the fix command (which can
 also be "all"). In addition, particles are also added to any groups
 specified by the {group} and {grouptype} keywords.  If inserted
 particles are individual atoms, they are assigned the atom type given
@@ -92,9 +104,9 @@ effect and must be set to zero. Instead, the type of each atom in the
 inserted molecule is specified in the file read by the
 "molecule"_molecule.html command.
 
-This fix cannot be used to perform MC insertions of gas atoms or
-molecules other than the exchanged type, but MC deletions,
-translations, and rotations can be performed on any atom/molecule in
+This fix cannot be used to perform GCMC insertions of gas atoms or
+molecules other than the exchanged type, but GCMC deletions,
+and MC translations, and rotations can be performed on any atom/molecule in
 the fix group.  All atoms in the simulation cell can be moved using
 regular time integration translations, e.g. via "fix nvt"_fix_nh.html,
 resulting in a hybrid GCMC+MD simulation. A smaller-than-usual
@@ -150,8 +162,8 @@ about this point.
 Individual atoms are inserted, unless the {mol} keyword is used.  It
 specifies a {template-ID} previously defined using the
 "molecule"_molecule.html command, which reads a file that defines the
-molecule.  The coordinates, atom types, charges, etc, as well as any
-bond/angle/etc and special neighbor information for the molecule can
+molecule.  The coordinates, atom types, charges, etc., as well as any
+bonding and special neighbor information for the molecule can
 be specified in the molecule file.  See the "molecule"_molecule.html
 command for details.  The only settings required to be in this file
 are the coordinates and types of atoms in the molecule.
@@ -162,7 +174,7 @@ error when it tries to find bonded neighbors.  LAMMPS will warn you if
 any of the atoms eligible for deletion have a non-zero molecule ID,
 but does not check for this at the time of deletion.
 
-If you wish to insert molecules via the {mol} keyword, that will be
+If you wish to insert molecules using the {mol} keyword that will be
 treated as rigid bodies, use the {rigid} keyword, specifying as its
 value the ID of a separate "fix rigid/small"_fix_rigid.html command
 which also appears in your input script.
@@ -178,6 +190,15 @@ their bonds or angles constrained via SHAKE, use the {shake} keyword,
 specifying as its value the ID of a separate "fix
 shake"_fix_shake.html command which also appears in your input script.
 
+Optionally, users may specify the relative amounts of different MC
+moves using the {mcmoves} keyword. The values {Patomtrans},
+{Pmoltrans}, {Pmolrotate} specify the average proportion of
+atom translations, molecule translations, and molecule rotations,
+respectively. The values must be non-negative integers or real
+numbers, with at least one non-zero value. For example, (10,30,0)
+would result in 25% of the MC moves being atomic translations, 75%
+molecular translations, and no molecular rotations. 
+
 Optionally, users may specify the maximum rotation angle for molecular
 rotations using the {maxangle} keyword and specifying the angle in
 degrees. Rotations are performed by generating a random point on the
@@ -188,19 +209,19 @@ to the unit vector defined by the point on the unit sphere.  The same
 procedure is used for randomly rotating molecules when they are
 inserted, except that the maximum angle is 360 degrees.
 
-Note that fix GCMC does not use configurational bias MC or any other
+Note that fix gcmc does not use configurational bias MC or any other
 kind of sampling of intramolecular degrees of freedom.  Inserted
 molecules can have different orientations, but they will all have the
 same intramolecular configuration, which was specified in the molecule
 command input.
 
 For atomic gasses, inserted atoms have the specified atom type, but
-deleted atoms are any atoms that have been inserted or that belong to
-the user-specified fix group. For molecular gasses, exchanged
+deleted atoms are any atoms that have been inserted or that already
+belong to the fix group. For molecular gasses, exchanged
 molecules use the same atom types as in the template molecule supplied
 by the user.  In both cases, exchanged atoms/molecules are assigned to
-two groups: the default group "all" and the group specified in the fix
-gcmc command (which can also be "all").
+two groups: the default group "all" and the fix group
+(which can also be "all").
 
 The chemical potential is a user-specified input parameter defined
 as:
@@ -241,13 +262,16 @@ which case the user-specified chemical potential is ignored. The user
 may also specify the fugacity coefficient phi using the
 {fugacity_coeff} keyword, which defaults to unity.
 
-The {full_energy} option means that fix GCMC will compute the total
-potential energy of the entire simulated system. The total system
-energy before and after the proposed GCMC move is then used in the
+The {full_energy} option means that the fix calculates the total
+potential energy of the entire simulated system, instead of just
+the energy of the part that is changed. The total system
+energy before and after the proposed GCMC exchange or MC move
+is then used in the
 Metropolis criterion to determine whether or not to accept the
-proposed GCMC move. By default, this option is off, in which case only
-partial energies are computed to determine the difference in energy
-that would be caused by the proposed GCMC move.
+proposed change. By default, this option is off,
+in which case only
+partial energies are computed to determine the energy difference
+due to the proposed change.
 
 The {full_energy} option is needed for systems with complicated
 potential energy calculations, including the following:
@@ -263,10 +287,11 @@ In these cases, LAMMPS will automatically apply the {full_energy}
 keyword and issue a warning message.
 
 When the {mol} keyword is used, the {full_energy} option also includes
-the intramolecular energy of inserted and deleted molecules. If this
+the intramolecular energy of inserted and deleted molecules, whereas
+this energy is not included when {full_energy} is not used. If this
 is not desired, the {intra_energy} keyword can be used to define an
 amount of energy that is subtracted from the final energy when a
-molecule is inserted, and added to the initial energy when a molecule
+molecule is inserted, and subtracted from the initial energy when a molecule
 is deleted. For molecules that have a non-zero intramolecular energy,
 this will ensure roughly the same behavior whether or not the
 {full_energy} option is used.
@@ -291,7 +316,8 @@ include: "efield"_fix_efield.html, "gravity"_fix_gravity.html,
 "temp/berendsen"_fix_temp_berendsen.html,
 "temp/rescale"_fix_temp_rescale.html, and "wall fixes"_fix_wall.html.
 For that energy to be included in the total potential energy of the
-system (the quantity used when performing GCMC moves), you MUST enable
+system (the quantity used when performing GCMC exchange and MC moves),
+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.
@@ -305,9 +331,14 @@ about simulating non-neutral systems with kspace on.
 
 Use of this fix typically will cause the number of atoms to fluctuate,
 therefore, you will want to use the
-"compute_modify"_compute_modify.html command to insure that the
+"compute_modify dynamic/dof"_compute_modify.html command to insure that the
 current number of atoms is used as a normalizing factor each time
-temperature is computed.  Here is the necessary command:
+temperature is computed. A simple example of this is:
+
+compute_modify thermo_temp dynamic yes :pre
+
+A more complicated example is listed earlier on this page
+in the context of NVT dynamics.
 
 NOTE: If the density of the cell is initially very small or zero, and
 increases to a much larger density after a period of equilibration,
@@ -327,17 +358,9 @@ assigning an infinite positive energy to all new configurations that
 place any pair of atoms closer than the specified overlap cutoff
 distance.
 
-compute_modify thermo_temp dynamic yes :pre
-
-If LJ units are used, note that a value of 0.18292026 is used by this
-fix as the reduced value for Planck's constant.  This value was
-derived from LJ parameters for argon, where h* = h/sqrt(sigma^2 *
-epsilon * mass), sigma = 3.429 angstroms, epsilon/k = 121.85 K, and
-mass = 39.948 amu.
-
-The {group} keyword assigns all inserted atoms to the
+The {group} keyword adds all inserted atoms to the
 "group"_group.html of the group-ID value. The {grouptype} keyword
-assigns all inserted atoms of the specified type to the
+adds all inserted atoms of the specified type to the
 "group"_group.html of the group-ID value.
 
 [Restart, fix_modify, output, run start/stop, minimize info:]
@@ -384,7 +407,8 @@ Can be run in parallel, but aspects of the GCMC part will not scale
 well in parallel. Only usable for 3D simulations.
 
 When using fix gcmc in combination with fix shake or fix rigid,
-only gcmc exchange moves are supported.
+only GCMC exchange moves are supported, so the argument
+{M} must be zero.
 
 Note that very lengthy simulations involving insertions/deletions of
 billions of gas molecules may run out of atom or molecule IDs and
@@ -409,7 +433,9 @@ the user for each subsequent fix gcmc command.
 [Default:]
 
 The option defaults are mol = no, maxangle = 10, overlap_cutoff = 0.0,
-fugacity_coeff = 1, and full_energy = no,
+fugacity_coeff = 1.0, intra_energy = 0.0, tfac_insert = 1.0.
+(Patomtrans, Pmoltrans, Pmolrotate) = (1, 0, 0) for mol = no and
+(0, 1, 1) for mol = yes. full_energy = no,
 except for the situations where full_energy is required, as
 listed above.
 

doc/src/fix_halt.txt

@@ -64,10 +64,10 @@ not performed once every {N} steps by this command.  Instead it is
 performed (typically) only a small number of times and the elapsed
 times are used to predict when the end-of-the-run will be.  Both of
 these attributes can be useful when performing benchmark calculations
-for a desired length of time with minmimal overhead.  For example, if
+for a desired length of time with minimal overhead.  For example, if
 a run is performing 1000s of timesteps/sec, the overhead for syncing
 the timer frequently across a large number of processors may be
-non-negligble.
+non-negligible.
 
 Equal-style variables evaluate to a numeric value.  See the
 "variable"_variable.html command for a description.  They calculate
@@ -125,7 +125,7 @@ to the screen and logfile when the halt condition is triggered.  If
 {message} is set to yes, a one line message with the values that
 triggered the halt is printed.  If {message} is set to no, no message
 is printed; the run simply exits.  The latter may be desirable for
-post-processing tools that extract thermodyanmic information from log
+post-processing tools that extract thermodynamic information from log
 files.
 
 [Restart, fix_modify, output, run start/stop, minimize info:]

doc/src/fix_latte.txt

@@ -0,0 +1,210 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+fix latte command :h3
+
+[Syntax:]
+
+fix ID group-ID latte peID :pre
+
+ID, group-ID are documented in "fix"_fix.html command
+latte = style name of this fix command
+peID = NULL or ID of compute used to calculate per-atom energy :ul
+
+[Examples:]
+
+fix dftb all latte NULL :pre
+
+[Description:]
+
+This fix style is a wrapper on the self-consistent charge transfer
+density functional based tight binding (DFTB) code LATTE. If you
+download and build LATTE, it can be called as a library by LAMMPS via
+this fix to run dynamics or perform energy minimization using DFTB
+forces and energies computed by LATTE.
+
+LATTE is principally developed and supported by Marc Cawkwell and
+co-workers at Los Alamos National Laboratory (LANL).  See the full
+list of contributors in the src/LATTE/README file.
+
+To use this fix, the LATTE program needs to be compiled as a library
+and linked with LAMMPS.  LATTE can be downloaded (or cloned) from
+"https://github.com/lanl/LATTE"_https://github.com/lanl/LATTE.
+Instructions on how to download and build LATTE on your system can be
+found in the lib/latte/README.  Note that you can also use the "make
+lib-latte" command from the LAMMPS src directory to automate this
+process.
+
+Once LAMMPS is built with the LATTE package, you can run the example
+input scripts for molecular dynamics or energy minimization that are
+found in examples/latte.
+
+A step-by-step tutorial can be follwed at: "LAMMPS-LATTE
+tutorial"_https://github.com/lanl/LATTE/wiki/Using-LATTE-through-LAMMPS
+
+The {peID} argument is not yet supported by fix latte, so it must be
+specified as NULL.  Eventually it will be used to enable LAMMPS to
+calculate a Coulomb potential as an alternative to LATTE performing
+the calculation.
+
+:line
+
+LATTE is a code for performing self-consistent charge transfer
+tight-binding (SC-TB) calculations of total energies and the forces
+acting on atoms in molecules and solids. This tight-binding method is
+becoming more and more popular and widely used in chemistry,
+biochemistry, material science, etc.  
+
+The SC-TB formalism is derived from an expansion of the Kohn-Sham
+density functional to second order in charge fluctuations about a
+reference charge of overlapping atom-centered densities and bond
+integrals are parameterized using a Slater-Koster tight-binding
+approach. This procedure, which usually is referred to as the DFTB
+method has been described in detail by ("Elstner"_#Elstner) and
+("Finnis"_#Finnis2) and coworkers. 
+
+The work of the LATTE developers follows that of Elstner closely with
+respect to the physical model.  However, the development of LATTE is
+geared principally toward large-scale, long duration, microcanonical
+quantum-based Born-Oppenheimer molecular dynamics (QMD) simulations.
+One of the main bottlenecks of an electronic structure calculation is
+the solution of the generalized eigenvalue problem which scales with
+the cube of the system size O(N^3).
+
+The Theoretical and Computer sciences divisions at Los Alamos National
+Laboratory have accumulated large experience addressing this issue by
+calculating the density matrix directly instead of using
+diagonalization. We typically use a recursive sparse Fermi-operator
+expansion using second-order spectral projection functions
+(SP2-algorithm), which was introduced by Niklasson in 2002
+("Niklasson2002"_#Niklasson2002), ("Rubensson"_#Rubensson),
+("Mniszewski"_#Mniszewski).  When the matrices involved in the
+recursive expansion are sufficiently sparse, the calculation of the
+density matrix scales linearly as a function of the system size O(N).
+
+Another important feature is the extended Lagrangian framework for
+Born-Oppenheimer molecular dynamics (XL-BOMD)
+("Niklasson2008"_#Niklasson2008) ("Niklasson2014"_#Niklasson2014),
+("Niklasson2017"_#Niklasson2017) that allows for a drastic reduction
+or even a complete removal of the iterative self-consistent field
+optimization.  Often only a single density matrix calculation per
+molecular dynamics time step is required, yet total energy stability
+is well maintained.  The SP2 and XL-BOMD techniques enables stable
+linear scaling MD simulations with a very small computational
+overhead.  This opens a number of opportunities in many different
+areas of chemistry and materials science, as we now can simulate
+larger system sizes and longer time scales
+("Cawkwell2012"_#Cawkwell2012), ("Negre2016"_#Negre2016).
+
+: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 LATTE 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 LATTE DFTB 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"_Section_howto.html#howto_15.  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.
+
+The DFTB forces computed by LATTE via this fix are imposed during an
+energy minimization, invoked by the "minimize"_minimize.html command.
+
+NOTE: If you want the potential energy associated with the DFTB
+forces to be included in the total potential energy of the system (the
+quantity being minimized), you MUST enable the
+"fix_modify"_fix_modify.html {energy} option for this fix.
+
+[Restrictions:]
+
+This fix is part of the LATTE package.  It is only enabled if LAMMPS
+was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+You must use metal units, as set by the "units"_units command to use
+this fix.
+
+LATTE does not currently compute per-atom energy or per-atom virial
+contributions.  So they will not show up as part of the calculations
+performed by the "compute pe/atom"_compute_pe_atom.html or "compute
+stress/atom"_compute_stress_atom.html commands.
+
+Currently, LAMMPS must be run in serial or as a single MPI task, to
+use this fix.  This is typically not a bottleneck, since LATTE will be
+doing 99% or more of the work to compute quantum-accurate forces.
+
+NOTE: NEB calculations can be done using this fix using multiple
+replicas and running LAMMPS in parallel.  However, each replica must
+be run on a single MPI task.  For details, see the "neb"_neb.html
+command and -partition command-line explained in "Section
+2.6"_Section_start.html#start_6 of the manual.
+
+[Related commands:] none
+
+[Default:] none
+
+:line
+
+:link(Elstner)
+[(Elstner)] M. Elstner, D. Poresag, G. Jungnickel, J. Elsner,
+M. Haugk, T. Frauenheim, S. Suhai, and G. Seifert, Phys. Rev. B, 58,
+7260 (1998).
+
+:link(Elstner1)
+[(Elstner)] M. Elstner, D. Poresag, G. Jungnickel, J. Elsner,
+M. Haugk, T. Frauenheim, S. Suhai, and G. Seifert, Phys. Rev. B, 58,
+7260 (1998).
+
+:link(Finnis2)
+[(Finnis)] M. W. Finnis, A. T. Paxton, M. Methfessel, and M. van
+Schilfgarde, Phys. Rev. Lett., 81, 5149 (1998).
+
+:link(Mniszewski)
+[(Mniszewski)] S. M. Mniszewski, M. J. Cawkwell, M. E. Wall,
+J. Mohd-Yusof, N. Bock, T. C.  Germann, and A. M. N. Niklasson,
+J. Chem. Theory Comput., 11, 4644 (2015).
+
+:link(Niklasson2002)
+[(Niklasson2002)] A. M. N. Niklasson, Phys. Rev. B, 66, 155115 (2002).
+
+:link(Rubensson)
+[(Rubensson)] E. H. Rubensson, A. M. N. Niklasson, SIAM
+J. Sci. Comput. 36 (2), 147-170, (2014).
+
+:link(Niklasson2008)
+[(Niklasson2008)] A. M. N. Niklasson, Phys. Rev. Lett., 100, 123004
+(2008).
+
+:link(Niklasson2014)
+[(Niklasson2014)] A. M. N. Niklasson and M. Cawkwell, J. Chem. Phys.,
+141, 164123, (2014).
+
+:link(Niklasson2017)
+[(Niklasson2017)] A. M. N. Niklasson, J. Chem. Phys., 147, 054103 (2017).
+
+:link(Cawkwell2012)
+[(Cawkwell2012)] A. M. N. Niklasson, M. J. Cawkwell, Phys. Rev. B, 86
+(17), 174308 (2012).
+
+:link(Negre2016)
+[(Negre2016)] C. F. A. Negre, S. M. Mniszewski, M. J. Cawkwell,
+N. Bock, M. E. Wall, and A. M. N. Niklasson, J. Chem. Theory Comp.,
+12, 3063 (2016).

doc/src/fix_modify.txt

@@ -14,10 +14,11 @@ fix_modify fix-ID keyword value ... :pre
 
 fix-ID = ID of the fix to modify :ulb,l
 one or more keyword/value pairs may be appended :l
-keyword = {temp} or {press} or {energy} or {respa} or {dynamic/dof} :l
+keyword = {temp} or {press} or {energy} or {virial} or {respa} or {dynamic/dof} :l
   {temp} value = compute ID that calculates a temperature
   {press} value = compute ID that calculates a pressure
   {energy} value = {yes} or {no}
+  {virial} value = {yes} or {no}
   {respa} value = {1} to {max respa level} or {0} (for outermost level)
   {dynamic/dof} value = {yes} or {no}
     yes/no = do or do not recompute the number of degrees of freedom (DOF) contributing to the temperature :pre
@@ -52,11 +53,10 @@ define their own compute by default, as described in their
 documentation.  Thus this option allows the user to override the
 default method for computing P.
 
-For fixes that calculate a contribution to the potential energy of the
-system, the {energy} keyword will include that contribution in
-thermodynamic output of potential energy.  This is because the {energy
-yes} setting must be specified to include the fix's global or per-atom
-energy in the calculation performed by the "compute
+The {energy} keyword can be used with fixes that support it.
+{energy yes} adds a contribution to the potential energy of the
+system. The fix's global and per-atom
+energy is included in the calculation performed by the "compute
 pe"_compute_pe.html or "compute pe/atom"_compute_pe_atom.html
 commands.  See the "thermo_style"_thermo_style.html command for info
 on how potential energy is output.  For fixes that tally a global
@@ -69,6 +69,25 @@ are using it when performing an "energy minimization"_minimize.html
 and if you want the energy and forces it produces to be part of the
 optimization criteria.
 
+The {virial} keyword can be used with fixes that support it.
+{virial yes} adds a contribution to the virial of the
+system. The fix's global and per-atom
+virial is included in the calculation performed by the "compute
+pressure"_compute_pressure.html or
+"compute stress/atom"_compute_stress_atom.html
+commands.  See the "thermo_style"_thermo_style.html command for info
+on how pressure is output. 
+
+NOTE: You must specify the {virial yes} setting for a fix if you
+are doing "box relaxation"_fix_box_relax.html and
+if you want virial contribution of the fix to be part of the
+relaxation criteria, although this seems unlikely.
+
+NOTE: This option is only supported by fixes that explicitly say
+so. For some of these (e.g. the
+"fix shake"_fix_shake.html command) the default setting is
+{virial yes}, for others it is {virial no}.
+
 For fixes that set or modify forces, it may be possible to select at
 which "r-RESPA"_run_style.html level the fix operates via the {respa}
 keyword. The RESPA level at which the fix is active can be selected.
@@ -111,4 +130,4 @@ pressure"_compute_pressure.html, "thermo_style"_thermo_style.html
 [Default:]
 
 The option defaults are temp = ID defined by fix, press = ID defined
-by fix, energy = no, respa = 0.
+by fix, energy = no, virial = different for each fix style, respa = 0.

doc/src/fix_mvv_dpd.txt

@@ -44,7 +44,7 @@ the velocity for the force evaluation:
 
 where the parameter <font size="4">&lambda;</font> depends on the
 specific choice of DPD parameters, and needs to be tuned on a
-case-by-case basis.  Specification of a {lambda} value is opttional.
+case-by-case basis.  Specification of a {lambda} value is optional.
 If specified, the setting must be from 0.0 to 1.0.  If not specified,
 a default value of 0.5 is used, which effectively reproduces the
 standard velocity-Verlet (VV) scheme.  For more details, see

doc/src/fix_neb.txt

@@ -93,7 +93,7 @@ intermediate replica with the previous and the next image:
 
 Fnudge_parallel = {Kspring} * (|Ri+1 - Ri| - |Ri - Ri-1|) :pre
 
-Note that in this case the specified {Kspring) is in force/distance
+Note that in this case the specified {Kspring} is in force/distance
 units.
 
 With a value of {ideal}, the spring force is computed as suggested in
@@ -105,7 +105,7 @@ where RD is the "reaction coordinate" see "neb"_neb.html section, and
 RDideal is the ideal RD for which all the images are equally spaced.
 I.e. RDideal = (I-1)*meanDist when the climbing replica is off, where
 I is the replica number).  The meanDist is the average distance
-between replicas.  Note that in this case the specified {Kspring) is
+between replicas.  Note that in this case the specified {Kspring} is
 in force units.
 
 Note that the {ideal} form of nudging can often be more effective at
@@ -113,9 +113,9 @@ keeping the replicas equally spaced.
 
 :line
 
-The keyword {perp} specifies if and how a perpendicual nudging force
+The keyword {perp} specifies if and how a perpendicular nudging force
 is computed.  It adds a spring force perpendicular to the path in
-order to prevent the path from becoming too kinky.  It can
+order to prevent the path from becoming too strongly kinked.  It can
 significantly improve the convergence of the NEB calculation when the
 resolution is poor.  I.e. when few replicas are used; see
 "(Maras)"_#Maras1 for details.
@@ -138,17 +138,17 @@ By default, no additional forces act on the first and last replicas
 during the NEB relaxation, so these replicas simply relax toward their
 respective local minima.  By using the key word {end}, additional
 forces can be applied to the first and/or last replicas, to enable
-them to relax toward a MEP while constraining their energy.
+them to relax toward a MEP while constraining their energy E to the
+target energy ETarget.
 
-The interatomic force Fi for the specified replica becomes:
+If ETarget>E, the interatomic force Fi for the specified replica becomes:
 
 Fi = -Grad(V) + (Grad(V) dot T' + (E-ETarget)*Kspring3) T',  {when} Grad(V) dot T' < 0
 Fi = -Grad(V) + (Grad(V) dot T' + (ETarget- E)*Kspring3) T', {when} Grad(V) dot T' > 0
 :pre
 
-where E is the current energy of the replica and ETarget is the target
-energy.  The "spring" constant on the difference in energies is the
-specified {Kspring3} value.
+The "spring" constant on the difference in energies is the specified
+{Kspring3} value.
 
 When {estyle} is specified as {first}, the force is applied to the
 first replica.  When {estyle} is specified as {last}, the force is
@@ -183,10 +183,9 @@ After converging a NEB calculation using an {estyle} of
 have a larger energy than the first replica. If this is not the case,
 the path is probably not a MEP.
 
-Finally, note that if the last replica converges toward a local
-minimum which has a larger energy than the energy of the first
-replica, a NEB calculation using an {estyle} of {last/efirst} or
-{last/efirst/middle} cannot reach final convergence.
+Finally, note that the last replica may never reach the target energy
+if it is stuck in a local minima which has a larger energy than the
+target energy.
 
 [Restart, fix_modify, output, run start/stop, minimize info:]
 

doc/src/fix_nh.txt

@@ -393,32 +393,36 @@ thermostatting and barostatting.
 :line
 
 These fixes compute a temperature and pressure each timestep.  To do
-this, the fix creates its own computes of style "temp" and "pressure",
-as if one of these two sets of commands had been issued:
+this, the thermostat and barostat fixes create their own computes of
+style "temp" and "pressure", as if one of these sets of commands had
+been issued:
 
+For fix nvt:
 compute fix-ID_temp group-ID temp
-compute fix-ID_press group-ID pressure fix-ID_temp :pre
 
+For fix npt and fix nph:
 compute fix-ID_temp all temp
 compute fix-ID_press all pressure fix-ID_temp :pre
 
-See the "compute temp"_compute_temp.html and "compute
-pressure"_compute_pressure.html commands for details.  Note that the
-IDs of the new computes are the fix-ID + underscore + "temp" or fix_ID
-+ underscore + "press".  For fix nvt, the group for the new computes
-is the same as the fix group.  For fix nph and fix npt, the group for
-the new computes is "all" since pressure is computed for the entire
-system.
+For fix nvt, the group for the new temperature compute is the same as
+the fix group.  For fix npt and fix nph, the group for both the new
+temperature and pressure compute is "all" since pressure is computed
+for the entire system.  In the case of fix nph, the temperature
+compute is not used for thermostatting, but just for a kinetic-energy
+contribution to the pressure.  See the "compute
+temp"_compute_temp.html and "compute pressure"_compute_pressure.html
+commands for details.  Note that the IDs of the new computes are the
+fix-ID + underscore + "temp" or fix_ID + underscore + "press".
 
 Note that these are NOT the computes used by thermodynamic output (see
 the "thermo_style"_thermo_style.html command) with ID = {thermo_temp}
-and {thermo_press}.  This means you can change the attributes of this
+and {thermo_press}.  This means you can change the attributes of these
 fix's temperature or pressure via the
-"compute_modify"_compute_modify.html command or print this temperature
-or pressure during thermodynamic output via the "thermo_style
-custom"_thermo_style.html command using the appropriate compute-ID.
-It also means that changing attributes of {thermo_temp} or
-{thermo_press} will have no effect on this fix.
+"compute_modify"_compute_modify.html command.  Or you can print this
+temperature or pressure during thermodynamic output via the
+"thermo_style custom"_thermo_style.html command using the appropriate
+compute-ID.  It also means that changing attributes of {thermo_temp}
+or {thermo_press} will have no effect on this fix.
 
 Like other fixes that perform thermostatting, fix nvt and fix npt can
 be used with "compute commands"_compute.html that calculate a

doc/src/fix_nh_uef.txt

@@ -0,0 +1,228 @@
+<"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+fix nvt/uef command :h3
+fix npt/uef command :h3
+
+[Syntax:]
+
+fix ID group-ID style_name erate edot_x edot_y temp Tstart Tstop Tdamp keyword value ... :pre
+
+ID, group-ID are documented in "fix"_fix.html command :ulb,l
+style_name = {nvt/uef} or {npt/uef} :l
+{Tstart}, {Tstop}, and {Tdamp} are documented in the "fix npt"_fix_nh.html command :l
+{edot_x} and {edot_y} are the strain rates in the x and y directions (1/(time units)) :l
+one or more keyword/value pairs may be appended :l
+keyword = {ext} or {strain} or {iso} or {x} or {y} or {z} or {tchain} or {pchain} or {tloop} or {ploop} or {mtk}
+  {ext} value = {x} or {y} or {z} or {xy} or {yz} or {xz} = external dimensions
+    sets the external dimensions used to calculate the scalar pressure
+  {strain} values = e_x e_y = initial strain
+    usually not needed, but may be needed to resume a run with a data file.
+  {iso}, {x}, {y}, {z}, {tchain}, {pchain}, {tloop}, {ploop}, {mtk} keywords
+    documented by the "fix npt"_fix_nh.html command :pre
+:ule
+
+[Examples:]
+
+fix uniax_nvt all nvt/uef temp 400 400 100 erate 0.00001 -0.000005
+fix biax_nvt all nvt/uef temp 400 400 100 erate 0.000005 0.000005
+fix uniax_npt all npt/uef temp 400 400 300 iso 1 1 3000 erate 0.00001 -0.000005 ext yz
+fix biax_npt all npt/uef temp 400 400 100 erate -0.00001 0.000005 x 1 1 3000 :pre
+
+[Description:]
+
+This fix can be used to simulate non-equilibrium molecular dynamics
+(NEMD) under diagonal flow fields, including uniaxial and biaxial
+flow.  Simulations under continuous extensional flow may be carried
+out for an indefinite amount of time.  It is an implementation of the
+boundary conditions from "(Dobson)"_#Dobson, and also uses numerical
+lattice reduction as was proposed by "(Hunt)"_#Hunt. The lattice
+reduction algorithm is from "(Semaev)"_Semaev. The fix is intended for
+simulations of homogeneous flows, and integrates the SLLOD equations
+of motion, originally proposed by Hoover and Ladd (see "(Evans and
+Morriss)"_#Sllod).  Additional detail about this implementation can be
+found in "(Nicholson and Rutledge)"_#Nicholson.
+
+Note that NEMD simulations of a continuously strained system can be
+performed using the "fix deform"_fix_deform.html, "fix
+nvt/sllod"_fix_nvt_sllod.html, and "compute
+temp/deform"_compute_temp_deform.html commands.
+
+The applied flow field is set by the {eps} keyword. The values
+{edot_x} and {edot_y} correspond to the strain rates in the xx and yy
+directions.  It is implicitly assumed that the flow field is
+traceless, and therefore the strain rate in the zz direction is eqal
+to -({edot_x} + {edot_y}).
+
+NOTE: Due to an instability in the SLLOD equations under extension,
+"fix momentum"_fix_momentum.html should be used to regularly reset the
+linear momentum.
+
+The boundary conditions require a simulation box that does not have a
+consistent alignment relative to the applied flow field. Since LAMMPS
+utilizes an upper-triangular simulation box, it is not possible to
+express the evolving simulation box in the same coordinate system as
+the flow field.  This fix keeps track of two coordinate systems: the
+flow frame, and the upper triangular LAMMPS frame. The coordinate
+systems are related to each other through the QR decomposition, as is
+illustrated in the image below.
+
+:c,image(JPG/uef_frames.jpg)
+
+During most molecular dynamics operations, the system is represented
+in the LAMMPS frame. Only when the positions and velocities are
+updated is the system rotated to the flow frame, and it is rotated
+back to the LAMMPS frame immediately afterwards. For this reason, all
+vector-valued quantities (except for the tensors from
+"compute_pressure/uef"_compute_pressure_uef.html and
+"compute_temp/uef"_compute_temp_uef.html) will be computed in the
+LAMMPS frame. Rotationally invariant scalar quantities like the
+temperature and hydrostatic pressure are frame-invariant and will be
+computed correctly. Additionally, the system is in the LAMMPS frame
+during all of the output steps, and therefore trajectory files made
+using the dump command will be in the LAMMPS frame unless the
+"dump_cfg/uef"_dump_cfg_uef.html command is used.
+
+:line
+
+Temperature control is achieved with the default Nose-Hoover style
+thermostat documented in "fix npt"_fix_nh.html. When this fix is
+active, only the peculiar velocity of each atom is stored, defined as
+the velocity relative to the streaming velocity. This is in contrast
+to "fix nvt/sllod"_fix_nvt_sllod.html, which uses a lab-frame
+velocity, and removes the contribution from the streaming velocity in
+order to compute the temperature.
+
+Pressure control is achieved using the default Nose-Hoover barostat
+documented in "fix npt"_fix_nh.html. There are two ways to control the
+pressure using this fix. The first method involves using the {ext}
+keyword along with the {iso} pressure style. With this method, the
+pressure is controlled by scaling the simulation box isotropically to
+achieve the average pressure only in the directions specified by
+{ext}.  For example, if the {ext} value is set to {xy}, the average
+pressure (Pxx+Pyy)/2 will be controlled.
+
+This example command will control the total hydrostatic pressure under
+uniaxial tension:
+
+fix f1 all npt/uef temp 0.7 0.7 0.5 iso 1 1 5 erate -0.5 -0.5 ext xyz :pre
+
+This example command will control the average stress in compression
+directions, which would typically correspond to free surfaces under
+drawing with uniaxial tension:
+
+fix f2 all npt/uef temp 0.7 0.7 0.5 iso 1 1 5 erate -0.5 -0.5 ext xy :pre
+
+The second method for pressure control involves setting the normal
+stresses using the {x}, {y} , and/or {z} keywords. When using this
+method, the same pressure must be specified via {Pstart} and {Pstop}
+for all dimensions controlled. Any choice of pressure conditions that
+would cause LAMMPS to compute a deviatoric stress are not permissible
+and will result in an error. Additionally, all dimensions with
+controlled stress must have the same applied strain rate. The {ext}
+keyword must be set to the default value ({xyz}) when using this
+method.
+
+For example, the following commands will work:
+
+fix f3 all npt/uef temp 0.7 0.7 0.5 x 1 1 5 y 1 1 5 erate -0.5 -0.5
+fix f4 all npt/uef temp 0.7 0.7 0.5 z 1 1 5 erate 0.5 0.5 :pre
+
+The following commands will not work:
+
+fix f5 all npt/uef temp 0.7 0.7 0.5 x 1 1 5 z 1 1 5 erate -0.5 -0.5
+fix f6 all npt/uef temp 0.7 0.7 0.5 x 1 1 5 z 2 2 5 erate 0.5 0.5 :pre
+
+:line
+
+These fix computes a temperature and pressure each timestep.  To do
+this, it creates its own computes of style "temp/uef" and
+"pressure/uef", as if one of these two sets of commands had been
+issued:
+
+compute fix-ID_temp group-ID temp/uef
+compute fix-ID_press group-ID pressure/uef fix-ID_temp :pre
+
+compute fix-ID_temp all temp/uef
+compute fix-ID_press all pressure/uef fix-ID_temp :pre
+
+See the "compute temp/uef"_compute_temp_uef.html and "compute
+pressure/uef"_compute_pressure_uef.html commands for details.  Note
+that the IDs of the new computes are the fix-ID + underscore + "temp"
+or fix_ID + underscore + "press".
+
+[Restart, fix_modify, output, run start/stop, minimize info:]
+
+The fix writes the state of all the thermostat and barostat variables,
+as well as the cumulative strain applied, to "binary restart
+files"_restart.html.  See the "read_restart"_read_restart.html command
+for info on how to re-specify a fix in an input script that reads a
+restart file, so that the operation of the fix continues in an
+uninterrupted fashion.
+
+NOTE: It is not necessary to set the {strain} keyword when resuming a
+run from a restart file. Only for resuming from data files, which do
+not contain the cumulative applied strain, will this keyword be
+necessary.
+
+This fix can be used with the "fix_modify"_fix_modify.html {temp} and
+{press} options. The temperature and pressure computes used must be of
+type {temp/uef} and {pressure/uef}.
+
+This fix computes the same global scalar and vecor quantities as "fix
+npt"_fix_nh.html.
+
+The fix is not invoked during "energy minimization"_minimize.html.
+
+[Restrictions:]
+
+This fix is part of the USER-UEF package. It is only enabled if LAMMPS
+was built with that package. See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+Due to requirements of the boundary conditions, when the {strain}
+keyword is set to zero (or unset), the initial simulation box must be
+cubic and have style triclinic. If the box is initially of type ortho,
+use "change_box"_change_box.html before invoking the fix.
+
+NOTE: When resuming from restart files, you may need to use "box tilt
+large"_box.html since lammps has internal criteria from lattice
+reduction that are not the same as the criteria in the numerical
+lattice reduction algorithm.
+
+[Related commands:]
+
+"fix nvt"_fix_nh.html, "fix nvt/sllod"_fix_nvt_sllod.html, "compute
+temp/uef"_compute_temp_uef.html, "compute
+pressure/uef"_compute_pressure_uef.html, "dump
+cfg/uef"_dump_cfg_uef.html
+
+[Default:]
+
+The default keyword values specific to this fix are exy = xyz, strain
+= 0 0.  The remaining defaults are the same as for {fix
+npt}_fix_nh.html except tchain = 1.  The reason for this change is
+given in "fix nvt/sllod"_fix_nvt_sllod.html.
+
+:line
+
+:link(Dobson)
+[(Dobson)] Dobson, J Chem Phys, 141, 184103 (2014).
+
+:link(Hunt)
+[(Hunt)] Hunt, Mol Simul, 42, 347 (2016).
+
+:link(Semaev)
+[(Semaev)] Semaev, Cryptography and Lattices, 181 (2001).
+
+:link(Sllod)
+[(Evans and Morriss)] Evans and Morriss, Phys Rev A, 30, 1528 (1984).
+
+:link(Nicholson)
+[(Nicholson and Rutledge)] Nicholson and Rutledge, J Chem Phys, 145,
+244903 (2016).

doc/src/fix_nve_dot.txt

@@ -44,7 +44,7 @@ A technical report with more information on this integrator can be found
 [Restrictions:]
 
 These pair styles can only be used if LAMMPS was built with the
-USER-CGDNA package and the MOLECULE and ASPHERE package.  See the "Making
+"USER-CGDNA"_#USER-CGDNA package and the MOLECULE and ASPHERE package.  See the "Making
 LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]

doc/src/fix_nve_dotc_langevin.txt

@@ -24,7 +24,8 @@ keyword = {angmom} :l
 
 [Examples:]
 
-fix 1 all nve/dotc/langevin 1.0 1.0 0.03 457145 angmom 10 :pre
+fix 1 all nve/dotc/langevin 1.0 1.0 0.03 457145 angmom 10 
+fix 1 all nve/dotc/langevin 0.1 0.1 78.9375 457145 angmom 10 :pre
 
 [Description:]
 
@@ -78,7 +79,9 @@ a Gaussian random number) for speed.
 :line
 
 {Tstart} and {Tstop} have to be constant values, i.e. they cannot
-be variables.
+be variables. If used together with the oxDNA force field for 
+coarse-grained simulation of DNA please note that T = 0.1 in oxDNA units
+corresponds to T = 300 K.  
 
 The {damp} parameter is specified in time units and determines how
 rapidly the temperature is relaxed.  For example, a value of 0.03
@@ -89,6 +92,10 @@ viscosity of the solvent, i.e. a small relaxation time implies a
 hi-viscosity solvent and vice versa.  See the discussion about gamma
 and viscosity in the documentation for the "fix
 viscous"_fix_viscous.html command for more details.
+Note that the value 78.9375 in the second example above corresponds 
+to a diffusion constant, which is about an order of magnitude larger 
+than realistic ones. This has been used to sample configurations faster
+in Brownian dynamics simulations. 
 
 The random # {seed} must be a positive integer. A Marsaglia random
 number generator is used.  Each processor uses the input seed to
@@ -115,12 +122,12 @@ A technical report with more information on this integrator can be found
 [Restrictions:]
 
 These pair styles can only be used if LAMMPS was built with the
-USER-CGDNA package and the MOLECULE and ASPHERE package.  See the "Making
+"USER-CGDNA"_#USER-CGDNA package and the MOLECULE and ASPHERE package.  See the "Making
 LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]
 
-"fix nve"_fix_nve.html, "fix langevin"_fix_langevin.html, "fix nve/dot"_fix_nve_dot.html,
+"fix nve"_fix_nve.html, "fix langevin"_fix_langevin.html, "fix nve/dot"_fix_nve_dot.html, "bond_style oxdna/fene"_bond_oxdna.html, "bond_style oxdna2/fene"_bond_oxdna.html, "pair_style oxdna/excv"_pair_oxdna.html, "pair_style oxdna2/excv"_pair_oxdna2.html
 
 [Default:] none
 

doc/src/fix_property_atom.txt

@@ -111,6 +111,10 @@ need to communicate their new values to/from ghost atoms, an operation
 that can be invoked from within a "pair style"_pair_style.html or
 "fix"_fix.html or "compute"_compute.html that you write.
 
+NOTE: If this fix is defined [after] the simulation box is created,
+a 'run 0' command should be issued to properly initialize the storage
+created by this fix.
+
 :line
 
 This fix is one of a small number that can be defined in an input
@@ -155,7 +159,7 @@ these commands could be used:
 
 fix prop all property/atom mol
 variable cluster atom ((id-1)/10)+1
-set id * mol v_cluster :pre
+set atom * mol v_cluster :pre
 
 The "atom-style variable"_variable.html will create values for atoms
 with IDs 31,32,33,...40 that are 4.0,4.1,4.2,...,4.9.  When the

doc/src/fix_python_invoke.txt

@@ -6,14 +6,14 @@
 
 :line
 
-fix python command :h3
+fix python/invoke command :h3
 
 [Syntax:]
 
-fix ID group-ID python N callback function_name :pre
+fix ID group-ID python/invoke N callback function_name :pre
 
 ID, group-ID are ignored by this fix :ulb,l
-python = style name of this fix command :l
+python/invoke = style name of this fix command :l
 N = execute every N steps :l
 callback = {post_force} or {end_of_step} :l
   {post_force} = callback after force computations on atoms every N time steps
@@ -36,8 +36,8 @@ def end_of_step_callback(lammps_ptr):
     # access LAMMPS state using Python interface
 """ :pre
 
-fix pf  all python 50 post_force post_force_callback
-fix eos all python 50 end_of_step end_of_step_callback :pre
+fix pf  all python/invoke 50 post_force post_force_callback
+fix eos all python/invoke 50 end_of_step end_of_step_callback :pre
 
 [Description:]
 

doc/src/fix_python_move.txt

@@ -0,0 +1,102 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+fix python/move command :h3
+
+[Syntax:]
+
+fix python/move pymodule.CLASS :pre
+
+pymodule.CLASS = use class [CLASS] in module/file [pymodule] to compute how to move atoms
+
+[Examples:]
+
+fix  1 all python/move py_nve.NVE
+fix  1 all python/move py_nve.NVE_OPT :pre
+
+[Description:]
+
+The {python/move} fix style provides a way to define ways how particles
+are moved during an MD run from python script code, that is loaded from
+a file into LAMMPS and executed at the various steps where other fixes
+can be executed. This python script must contain specific python class
+definitions.
+
+This allows to implement complex position updates and also modified
+time integration methods. Due to python being an interpreted language,
+however, the performance of this fix can be moderately to significantly
+slower than the corresponding C++ code. For specific cases, this
+performance penalty can be limited through effective use of NumPy.
+
+:line
+
+The python module file has to start with the following code:
+
+from __future__ import print_function
+import lammps
+import ctypes
+import traceback
+import numpy as np
+#
+class LAMMPSFix(object):
+    def __init__(self, ptr, group_name="all"):
+        self.lmp = lammps.lammps(ptr=ptr)
+        self.group_name = group_name
+#
+class LAMMPSFixMove(LAMMPSFix):
+    def __init__(self, ptr, group_name="all"):
+        super(LAMMPSFixMove, self).__init__(ptr, group_name)
+#
+    def init(self):
+        pass
+#
+    def initial_integrate(self, vflag):
+        pass
+#
+    def final_integrate(self):
+        pass
+#
+    def initial_integrate_respa(self, vflag, ilevel, iloop):
+        pass
+#
+    def final_integrate_respa(self, ilevel, iloop):
+        pass
+#
+    def reset_dt(self):
+        pass :pre
+
+Any classes implementing new atom motion functionality have to be
+derived from the [LAMMPSFixMove] class, overriding the available
+methods as needed.
+
+Examples for how to do this are in the {examples/python} folder.
+
+: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"_Section_howto.html#howto_15.  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 pair style is part of the PYTHON package.  It is only enabled if
+LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+[Related commands:]
+
+"fix nve"_fix_nve.html, "fix python/invoke"_fix_python_invoke.html
+
+[Default:] none
+

doc/src/fix_rhok.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,Section_commands.html#comm)
+
+:line
+
+fix rhok command :h3
+
+fix ID group-ID rhok nx ny nz K a :pre
+
+ID, group-ID are documented in "fix"_fix.html command
+nx, ny, nz = k-vektor of collective density field
+K = spring constant of bias potential
+a = anchor point of bias potential :ul
+
+[Examples:]
+
+fix bias all rhok 16 0 0 4.0 16.0
+fix 1 all npt temp 0.8 0.8 4.0 z 2.2 2.2 8.0
+# output of 4 values from fix rhok: U_bias rho_k_RE  rho_k_IM  |rho_k|
+thermo_style custom step temp pzz lz f_bias f_bias\[1\] f_bias\[2\] f_bias\[3\] :pre
+
+[Description:]
+
+The fix applies a force to atoms given by the potential
+
+:c,image(Eqs/fix_rhok.jpg)
+
+as described in "(Pedersen)"_#Pedersen.
+
+This field, which biases configurations with long-range order, can be
+used to study crystal-liquid interfaces and determine melting
+temperatures "(Pedersen)"_#Pedersen.
+
+An example of using the interface pinning method is located in the
+{examples/USER/misc/rhok} directory.
+
+[Restrictions:]
+
+This fix is part of the MISC package.  It is only enabled if LAMMPS
+was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+[Related commands:]
+
+"thermo_style"_thermo_style.html
+
+[Default:] none
+
+:line
+
+:link(Pedersen)
+[(Pedersen)] Pedersen, J. Chem. Phys., 139, 104102 (2013).
+

doc/src/fix_rigid.txt

@@ -7,11 +7,17 @@
 :line
 
 fix rigid command :h3
+fix rigid/omp command :h3
 fix rigid/nve command :h3
+fix rigid/nve/omp command :h3
 fix rigid/nvt command :h3
+fix rigid/nvt/omp command :h3
 fix rigid/npt command :h3
+fix rigid/npt/omp command :h3
 fix rigid/nph command :h3
+fix rigid/nph/omp command :h3
 fix rigid/small command :h3
+fix rigid/small/omp command :h3
 fix rigid/nve/small command :h3
 fix rigid/nvt/small command :h3
 fix rigid/npt/small command :h3
@@ -26,6 +32,9 @@ style = {rigid} or {rigid/nve} or {rigid/nvt} or {rigid/npt} or {rigid/nph} or {
 bodystyle = {single} or {molecule} or {group} :l
   {single} args = none
   {molecule} args = none
+  {custom} args = {i_propname} or {v_varname}
+    i_propname = an integer property defined via fix property/atom
+    v_varname  = an atom-style or atomfile-style variable
   {group} args = N groupID1 groupID2 ...
     N = # of groups
     groupID1, groupID2, ... = list of N group IDs :pre
@@ -81,6 +90,16 @@ fix 1 particles rigid/npt molecule temp 1.0 1.0 5.0 x 0.5 0.5 1.0 z 0.5 0.5 1.0
 fix 1 water rigid/nph molecule iso 0.5 0.5 1.0
 fix 1 particles rigid/npt/small molecule temp 1.0 1.0 1.0 iso 0.5 0.5 1.0 :pre
 
+variable bodyid atom 1.0*gmask(clump1)+2.0*gmask(clump2)+3.0*gmask(clump3)
+fix 1 clump rigid custom v_bodyid :pre
+
+variable bodyid atomfile bodies.txt
+fix 1 clump rigid custom v_bodyid :pre
+
+fix 0 all property/atom i_bodyid
+read_restart data.rigid fix 0 NULL Bodies
+fix 1 clump rigid/small custom i_bodyid :pre
+
 [Description:]
 
 Treat one or more sets of atoms as independent rigid bodies.  This
@@ -100,7 +119,7 @@ of a biomolecule such as a protein.
 
 Example of small rigid bodies are patchy nanoparticles, such as those
 modeled in "this paper"_#Zhang1 by Sharon Glotzer's group, clumps of
-granular particles, lipid molecules consiting of one or more point
+granular particles, lipid molecules consisting of one or more point
 dipoles connected to other spheroids or ellipsoids, irregular
 particles built from line segments (2d) or triangles (3d), and
 coarse-grain models of nano or colloidal particles consisting of a
@@ -203,11 +222,11 @@ most one rigid body.  Which atoms are in which bodies can be defined
 via several options.
 
 NOTE: With the {rigid/small} styles, which require that {bodystyle} be
-specified as {molecule}, you can define a system that has no rigid
-bodies initially.  This is useful when you are using the {mol} keyword
-in conjunction with another fix that is adding rigid bodies on-the-fly
-as molecules, such as "fix deposit"_fix_deposit.html or "fix
-pour"_fix_pour.html.
+specified as {molecule} or {custom}, you can define a system that has
+no rigid bodies initially.  This is useful when you are using the {mol}
+keyword in conjunction with another fix that is adding rigid bodies
+on-the-fly as molecules, such as "fix deposit"_fix_deposit.html or
+"fix pour"_fix_pour.html.
 
 For bodystyle {single} the entire fix group of atoms is treated as one
 rigid body.  This option is only allowed for the {rigid} styles.
@@ -222,6 +241,15 @@ molecule ID = 0) surrounding rigid bodies, this may not be what you
 want.  Thus you should be careful to use a fix group that only
 includes atoms you want to be part of rigid bodies.
 
+Bodystyle {custom} is similar to bodystyle {molecule}, however some
+custom properties are used to group atoms into rigid bodies. The
+special case for molecule/body ID = 0 is not available. Possible
+custom properties are an integer property associated with atoms through
+"fix property/atom"_fix_property_atom.html or an atom style variable
+or an atomfile style variable. For the latter two, the variable value
+will be rounded to an integer and then rigid bodies defined from
+those values.
+
 For bodystyle {group}, each of the listed groups is treated as a
 separate rigid body.  Only atoms that are also in the fix group are
 included in each rigid body.  This option is only allowed for the
@@ -703,6 +731,11 @@ NVT, NPT, NPH rigid styles to add the energy change induced by the
 thermostatting 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 contribution due to keeping the objects rigid to the
+system's virial as part of "thermodynamic output"_thermo_style.html.
+The default is {virial yes}
+
 The "fix_modify"_fix_modify.html {temp} and {press} options are
 supported by the 4 NPT and NPH rigid styles to change the computes
 used to calculate the instantaneous pressure tensor.  Note that the 2

doc/src/fix_rx.txt

@@ -7,6 +7,7 @@
 :line
 
 fix rx command :h3
+fix rx/kk command :h3
 
 [Syntax:]
 
@@ -182,6 +183,29 @@ read_data    data.dpd fix foo_SPECIES NULL Species
 
 :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 in "Section 5"_Section_accelerate.html
+of the manual.  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 "Making
+LAMMPS"_Section_start.html#start_3 section 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"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "Section 5"_Section_accelerate.html of the manual for
+more instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restrictions:]
 
 This command is part of the USER-DPD package.  It is only enabled if

doc/src/fix_saed_vtk.txt

@@ -37,8 +37,8 @@ keyword = {file} or {ave} or {start} or {file} or {overwrite}:l
 compute 1 all saed 0.0251 Al O Kmax 1.70 Zone 0 0 1 dR_Ewald 0.01 c 0.5 0.5 0.5
 compute 2 all saed 0.0251 Ni Kmax 1.70 Zone 0 0 0 c 0.05 0.05 0.05 manual echo :pre
 
-fix saed/vtk 1 1 1 c_1 file Al2O3_001.saed
-fix saed/vtk 1 1 1 c_2 file Ni_000.saed :pre
+fix 1 all saed/vtk 1 1 1 c_1 file Al2O3_001.saed
+fix 2 all saed/vtk 1 1 1 c_2 file Ni_000.saed :pre
 
 [Description:]
 

doc/src/fix_shake.txt

@@ -58,7 +58,7 @@ required in order to eliminate velocity components along the bonds
 In order to formulate individual constraints for SHAKE and RATTLE,
 focus on a single molecule whose bonds are constrained.  Let Ri and Vi
 be the position and velocity of atom {i} at time {n}, for
-{i}=1,...,{N}, where {N} is the number of sites of our reference
+{i} =1,...,{N}, where {N} is the number of sites of our reference
 molecule. The distance vector between sites {i} and {j} is given by
 
 :c,image(Eqs/fix_rattle_rij.jpg)
@@ -186,6 +186,11 @@ to 1 and recompiling LAMMPS.
 
 [Restart, fix_modify, output, run start/stop, minimize info:]
 
+The "fix_modify"_fix_modify.html {virial} option is supported by this
+fix to add the contribution due to keeping the constraints to the
+system's virial as part of "thermodynamic output"_thermo_style.html.
+The default is {virial yes}
+
 No information about these fixes is written to "binary restart
 files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to these fixes.  No global or per-atom quantities are

doc/src/fix_shardlow.txt

@@ -7,6 +7,7 @@
 :line
 
 fix shardlow command :h3
+fix shardlow/kk command :h3
 
 [Syntax:]
 
@@ -52,6 +53,29 @@ examples/USER/dpd directory.
 
 :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 in "Section 5"_Section_accelerate.html
+of the manual.  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 "Making
+LAMMPS"_Section_start.html#start_3 section 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"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "Section 5"_Section_accelerate.html of the manual for
+more instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restrictions:]
 
 This command is part of the USER-DPD package.  It is only enabled if

doc/src/fix_smd.txt

@@ -101,6 +101,11 @@ See the "read_restart"_read_restart.html command for info on how to
 re-specify a fix in an input script that reads a restart file, so that
 the operation of the fix continues in an uninterrupted fashion.
 
+The "fix_modify"_fix_modify.html {virial} option is supported by this
+fix to add the contribution due to the added forces on atoms to the
+system's virial as part of "thermodynamic output"_thermo_style.html.
+The default is {virial no}
+
 The "fix_modify"_fix_modify.html {respa} option is supported by
 this fix. This allows to set at which level of the "r-RESPA"_run_style.html
 integrator the fix is adding its forces. Default is the outermost level.

doc/src/fix_smd_integrate_tlsph.txt

@@ -14,15 +14,12 @@ fix ID group-ID smd/integrate_tlsph keyword values :pre
 
 ID, group-ID are documented in "fix"_fix.html command
 smd/integrate_tlsph = style name of this fix command
-zero or more keyword/value pairs may be appended :ul
-
-keyword = {limit_velocity}  :l
+zero or more keyword/value pairs may be appended
+keyword = {limit_velocity}  :ul
 
   {limit_velocity} value = max_vel
     max_vel = maximum allowed velocity :pre
 
-:ule
-
 [Examples:]
 
 fix 1 all smd/integrate_tlsph

doc/src/fix_smd_integrate_ulsph.txt

@@ -14,9 +14,8 @@ fix ID group-ID smd/integrate_ulsph keyword :pre
 
 ID, group-ID are documented in "fix"_fix.html command
 smd/integrate_ulsph = style name of this fix command
-zero or more keyword/value pairs may be appended :ul
-
-keyword = adjust_radius or limit_velocity
+zero or more keyword/value pairs may be appended
+keyword = adjust_radius or limit_velocity :ul
 
 adjust_radius values = adjust_radius_factor min_nn max_nn
       adjust_radius_factor = factor which scale the smooth/kernel radius
@@ -28,7 +27,7 @@ limit_velocity values = max_velocity
 
 [Examples:]
 
-fix 1 all smd/integrate_ulsph adjust_radius 1.02 25 50 :pre
+fix 1 all smd/integrate_ulsph adjust_radius 1.02 25 50
 fix 1 all smd/integrate_ulsph limit_velocity 1000 :pre
 
 [Description:]
@@ -38,7 +37,7 @@ See "this PDF guide"_PDF/SMD_LAMMPS_userguide.pdf to using Smooth Mach Dynamics
 
 The {adjust_radius} keyword activates dynamic adjustment of the per-particle SPH smoothing kernel radius such that the number of neighbors per particles remains
 within the interval {min_nn} to {max_nn}. The parameter {adjust_radius_factor} determines the amount of adjustment per timestep. Typical values are
-{adjust_radius_factor}=1.02, {min_nn}=15, and {max_nn}=20.
+{adjust_radius_factor} =1.02, {min_nn} =15, and {max_nn} =20.
 
 The {limit_velocity} keyword will control the velocity, scaling the norm of
 the velocity vector to max_vel in case it exceeds this velocity limit.

doc/src/fix_surface_global.txt

@@ -0,0 +1,19 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+fix wall/surface/globale command :h3
+
+[Description:]
+
+This feature is not yet implemented.
+
+[Related commands:]
+
+"dump image"_dump_image.html
+
+

doc/src/fix_ti_spring.txt

@@ -34,7 +34,7 @@ by performing a nonequilibrium thermodynamic integration between the
 solid of interest and an Einstein crystal. A detailed explanation of
 how to use this command and choose its parameters for optimal
 performance and accuracy is given in the paper by
-"Freitas"_#Freitas. The paper also presents a short summary of the
+"Freitas"_#Freitas1. The paper also presents a short summary of the
 theory of nonequilibrium thermodynamic integrations.
 
 The thermodynamic integration procedure is performed by rescaling the
@@ -67,13 +67,13 @@ of lambda is kept equal to zero and the fix has no other effect on the
 dynamics of the system.
 
 The processes described above is known as nonequilibrium thermodynamic
-integration and is has been shown ("Freitas"_#Freitas) to present a
+integration and is has been shown ("Freitas"_#Freitas1) to present a
 much superior efficiency when compared to standard equilibrium
 methods. The reason why the switching it is made in both directions
 (potential to Einstein crystal and back) is to eliminate the
 dissipated heat due to the nonequilibrium process. Further details
 about nonequilibrium thermodynamic integration and its implementation
-in LAMMPS is available in "Freitas"_#Freitas.
+in LAMMPS is available in "Freitas"_#Freitas1.
 
 The {function} keyword allows the use of two different lambda
 paths. Option {1} results in a constant rate of change of lambda with
@@ -94,7 +94,7 @@ thermodynamic integration. The use of option {2} is recommended since
 it results in better accuracy and less dissipation without any
 increase in computational resources cost.
 
-NOTE: As described in "Freitas"_#Freitas, it is important to keep the
+NOTE: As described in "Freitas"_#Freitas1, it is important to keep the
 center-of-mass fixed during the thermodynamic integration. A nonzero
 total velocity will result in divergences during the integration due
 to the fact that the atoms are 'attached' to their equilibrium
@@ -156,7 +156,7 @@ The keyword default is function = 1.
 
 :line
 
-:link(Freitas)
+:link(Freitas1)
 [(Freitas)] Freitas, Asta, and de Koning, Computational Materials
 Science, 112, 333 (2016).
 

doc/src/fix_wall.txt

@@ -7,6 +7,7 @@
 :line
 
 fix wall/lj93 command :h3
+fix wall/lj93/kk command :h3
 fix wall/lj126 command :h3
 fix wall/lj1043 command :h3
 fix wall/colloid command :h3
@@ -251,6 +252,11 @@ fix to add the energy of interaction between atoms and each wall 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 contribution due to the interaction between
+atoms and each wall to the system's virial as part of "thermodynamic
+output"_thermo_style.html. The default is {virial no}
+
 The "fix_modify"_fix_modify.html {respa} option is supported by this
 fix. This allows to set at which level of the "r-RESPA"_run_style.html
 integrator the fix is adding its forces. Default is the outermost level.
@@ -277,6 +283,31 @@ the total potential energy of the system (the quantity being
 minimized), you MUST enable the "fix_modify"_fix_modify.html {energy}
 option for this fix.
 
+: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 in "Section 5"_Section_accelerate.html
+of the manual.  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 "Making
+LAMMPS"_Section_start.html#start_3 section 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"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "Section 5"_Section_accelerate.html of the manual for
+more instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restrictions:] none
 
 [Related commands:]

doc/src/fix_wall_region.txt

@@ -15,7 +15,7 @@ fix ID group-ID wall/region region-ID style epsilon sigma cutoff :pre
 ID, group-ID are documented in "fix"_fix.html command
 wall/region = style name of this fix command
 region-ID = region whose boundary will act as wall
-style = {lj93} or {lj126} or {colloid} or {harmonic}
+style = {lj93} or {lj126} or {lj1043} or {colloid} or {harmonic}
 epsilon = strength factor for wall-particle interaction (energy or energy/distance^2 units)
 sigma = size factor for wall-particle interaction (distance units)
 cutoff = distance from wall at which wall-particle interaction is cut off (distance units) :ul
@@ -112,6 +112,10 @@ For style {lj126}, the energy E is given by the 12/6 potential:
 
 :c,image(Eqs/pair_lj.jpg)
 
+For style {wall/lj1043}, the energy E is given by the 10/4/3 potential:
+
+:c,image(Eqs/fix_wall_lj1043.jpg)
+
 For style {colloid}, the energy E is given by an integrated form of
 the "pair_style colloid"_pair_colloid.html potential:
 
@@ -128,49 +132,8 @@ surface no longer interact.  The energy of the wall potential is
 shifted so that the wall-particle interaction energy is 0.0 at the
 cutoff distance.
 
-For the {lj93} and {lj126} styles, {epsilon} and {sigma} are the usual
-Lennard-Jones parameters, which determine the strength and size of the
-particle as it interacts with the wall.  Epsilon has energy units.
-Note that this {epsilon} and {sigma} may be different than any
-{epsilon} or {sigma} values defined for a pair style that computes
-particle-particle interactions.
-
-The {lj93} interaction is derived by integrating over a 3d
-half-lattice of Lennard-Jones 12/6 particles.  The {lj126} interaction
-is effectively a harder, more repulsive wall interaction.
-
-For the {colloid} style, {epsilon} is effectively a Hamaker constant
-with energy units for the colloid-wall interaction, {R} is the radius
-of the colloid particle, {D} is the distance from the surface of the
-colloid particle to the wall (r-R), and {sigma} is the size of a
-constituent LJ particle inside the colloid particle.  Note that the
-cutoff distance Rc in this case is the distance from the colloid
-particle center to the wall.
-
-The {colloid} interaction is derived by integrating over constituent
-LJ particles of size {sigma} within the colloid particle and a 3d
-half-lattice of Lennard-Jones 12/6 particles of size {sigma} in the
-wall.
-
-For the {wall/harmonic} style, {epsilon} is effectively the spring
-constant K, and has units (energy/distance^2).  The input parameter
-{sigma} is ignored.  The minimum energy position of the harmonic
-spring is at the {cutoff}.  This is a repulsive-only spring since the
-interaction is truncated at the {cutoff}
-
-NOTE: For all of the styles, you must insure that r is always > 0 for
-all particles in the group, or LAMMPS will generate an error.  This
-means you cannot start your simulation with particles on the region
-surface (r = 0) or with particles on the wrong side of the region
-surface (r < 0).  For the {wall/lj93} and {wall/lj126} styles, the
-energy of the wall/particle interaction (and hence the force on the
-particle) blows up as r -> 0.  The {wall/colloid} style is even more
-restrictive, since the energy blows up as D = r-R -> 0.  This means
-the finite-size particles of radius R must be a distance larger than R
-from the region surface.  The {harmonic} style is a softer potential
-and does not blow up as r -> 0, but you must use a large enough
-{epsilon} that particles always reamin on the correct side of the
-region surface (r > 0).
+For a full description of these wall styles, see fix_style
+"wall"_fix_wall.html
 
 [Restart, fix_modify, output, run start/stop, minimize info:]
 
@@ -182,6 +145,11 @@ fix to add the energy of interaction between atoms and the wall 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 contribution due to the interaction between
+atoms and each wall to the system's virial as part of "thermodynamic
+output"_thermo_style.html. The default is {virial no}
+
 The "fix_modify"_fix_modify.html {respa} option is supported by this
 fix. This allows to set at which level of the "r-RESPA"_run_style.html
 integrator the fix is adding its forces. Default is the outermost level.

doc/src/fixes.txt

@@ -59,6 +59,7 @@ Fixes :h1
    fix_langevin
    fix_langevin_drude
    fix_langevin_eff
+   fix_latte
    fix_lb_fluid
    fix_lb_momentum
    fix_lb_pc
@@ -76,6 +77,7 @@ Fixes :h1
    fix_neb
    fix_nh
    fix_nh_eff
+   fix_nh_uef
    fix_nph_asphere
    fix_nph_body
    fix_nph_sphere
@@ -113,7 +115,8 @@ Fixes :h1
    fix_press_berendsen
    fix_print
    fix_property_atom
-   fix_python
+   fix_python_invoke
+   fix_python_move
    fix_qbmsst
    fix_qeq
    fix_qeq_comb
@@ -124,6 +127,7 @@ Fixes :h1
    fix_reaxc_species
    fix_recenter
    fix_restrain
+   fix_rhok
    fix_rigid
    fix_rx
    fix_saed_vtk
@@ -144,6 +148,7 @@ Fixes :h1
    fix_srd
    fix_store_force
    fix_store_state
+   fix_surface_global
    fix_temp_berendsen
    fix_temp_csvr
    fix_temp_rescale

doc/src/improper_inversion_harmonic.txt

@@ -0,0 +1,65 @@
+"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
+
+improper_style inversion/harmonic command :h3
+
+[Syntax:]
+
+improper_style inversion/harmonic :pre
+
+[Examples:]
+
+improper_style inversion/harmonic
+improper_coeff 1 18.776340 0.000000 :pre 
+
+[Description:]
+
+The {inversion/harmonic} improper style follows the Wilson-Decius
+out-of-plane angle definition and uses an harmonic potential:
+
+:c,image(Eqs/improper_inversion_harmonic.jpg)
+
+where K is the force constant and omega is the angle evaluated for 
+all three axis-plane combinations centered around the atom I.  For
+the IL axis and the IJK plane omega looks as follows:
+
+:c,image(Eqs/umbrella.jpg)
+
+Note that the {inversion/harmonic} angle term evaluation differs to 
+the "improper_umbrella"_improper_umbrella.html due to the cyclic 
+evaluation of all possible angles omega. 
+
+The following coefficients must be defined for each improper type via
+the "improper_coeff"_improper_coeff.html command as in the example
+above, or in the data file or restart files read by the
+"read_data"_read_data.html or "read_restart"_read_restart.html
+commands:
+
+K (energy)
+omega0 (degrees) :ul
+
+If omega0 = 0 the potential term has a minimum for the planar
+structure.  Otherwise it has two minima at +/- omega0, with a barrier
+in between. 
+
+:line
+
+[Restrictions:]
+
+This improper style can only be used if LAMMPS was built with the
+USER-MOFFF package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
+
+[Related commands:]
+
+"improper_coeff"_improper_coeff.html
+
+[Default:] none
+
+:line
+

doc/src/impropers.txt

@@ -12,6 +12,7 @@ Improper Styles :h1
    improper_fourier
    improper_harmonic
    improper_hybrid
+   improper_inversion_harmonic
    improper_none
    improper_ring
    improper_umbrella

doc/src/info.txt

@@ -12,7 +12,7 @@ info command :h3
 
 info args :pre
 
-args = one or more of the following keywords: {out}, {all}, {system}, {memory}, {communication}, {computes}, {dumps}, {fixes}, {groups}, {regions}, {variables}, {styles}, {time}, or {configuration}
+args = one or more of the following keywords: {out}, {all}, {system}, {memory}, {communication}, {computes}, {dumps}, {fixes}, {groups}, {regions}, {variables}, {coeffs}, {styles}, {time}, or {configuration}
      {out} values = {screen}, {log}, {append} filename, {overwrite} filename
      {styles} values = {all}, {angle}, {atom}, {bond}, {compute}, {command}, {dump}, {dihedral}, {fix}, {improper}, {integrate}, {kspace}, {minimize}, {pair}, {region} :ul
 
@@ -81,6 +81,11 @@ The {variables} category prints a list of all currently defined
 variables, their names, styles, definition and last computed value, if
 available.
 
+The {coeffs} category prints a list for each defined force style
+(pair, bond, angle, dihedral, improper) indicating which of the
+corresponding coefficients have been set. This can be very helpful
+to debug error messages like "All pair coeffs are not set".
+
 The {styles} category prints the list of styles available in the
 current LAMMPS binary. It supports one of the following options
 to control which category of styles is printed out:

doc/src/lammps.book

@@ -1,6 +1,5 @@
-#HTMLDOC 1.8.27
--t pdf14 -f "../Manual.pdf" --book --toclevels 4 --no-numbered --toctitle "Table of Contents" --title --textcolor #000000 --linkcolor #0000ff --linkstyle plain --bodycolor #ffffff --size Universal --left 1.00in --right 0.50in --top 0.50in --bottom 0.50in --header .t. --header1 ... --footer ..1 --nup 1 --tocheader .t. --tocfooter ..i --portrait --color --no-pscommands --no-xrxcomments --compression=1 --jpeg=0 --fontsize 11.0 --fontspacing 1.2 --headingfont helvetica --bodyfont times --headfootsize 11.0 --headfootfont helvetica --charset iso-8859-1 --links --embedfonts --pagemode document --pagelayout single --firstpage c1 --pageeffect none --pageduration 10 --effectduration 1.0 --no-encryption --permissions all  --owner-password ""  --user-password "" --browserwidth 680 --no-strict --no-overflow
-
+#HTMLDOC 1.8.28
+-t pdf14 -f "../Manual.pdf" --book --toclevels 4 --no-numbered --toctitle "Table of Contents" --title --textcolor #000000 --linkcolor #0000ff --linkstyle plain --bodycolor #ffffff --size Universal --left 1.00in --right 0.50in --top 0.50in --bottom 0.50in --header .t. --header1 ... --footer ..1 --nup 1 --tocheader .t. --tocfooter ..i --portrait --color --no-pscommands --no-xrxcomments --compression=9 --jpeg=0 --fontsize 11.0 --fontspacing 1.2 --headingfont Sans --bodyfont Serif --headfootsize 11.0 --headfootfont Sans-Bold --charset iso-8859-15 --links --embedfonts --pagemode document --pagelayout single --firstpage c1 --pageeffect none --pageduration 10 --effectduration 1.0 --no-encryption --permissions all  --owner-password ""  --user-password "" --browserwidth 680 --no-strict --no-overflow
 Manual.html
 Section_intro.html
 Section_start.html
@@ -62,6 +61,7 @@ dump_modify.html
 dump_molfile.html
 dump_netcdf.html
 dump_vtk.html
+dump_cfg_uef.html
 echo.html
 fix.html
 fix_modify.html
@@ -116,6 +116,7 @@ suffix.html
 tad.html
 temper.html
 temper_grem.html
+temper_npt.html
 thermo.html
 thermo_modify.html
 thermo_style.html
@@ -186,6 +187,7 @@ fix_ipi.html
 fix_langevin.html
 fix_langevin_drude.html
 fix_langevin_eff.html
+fix_latte.html
 fix_lb_fluid.html
 fix_lb_momentum.html
 fix_lb_pc.html
@@ -230,6 +232,7 @@ fix_nvt_manifold_rattle.html
 fix_nvt_sllod.html
 fix_nvt_sllod_eff.html
 fix_nvt_sphere.html
+fix_nh_uef.html
 fix_oneway.html
 fix_orient.html
 fix_phonon.html
@@ -240,7 +243,8 @@ fix_pour.html
 fix_press_berendsen.html
 fix_print.html
 fix_property_atom.html
-fix_python.html
+fix_python_invoke.html
+fix_python_move.html
 fix_qbmsst.html
 fix_qeq.html
 fix_qeq_comb.html
@@ -252,6 +256,7 @@ fix_reaxc_species.html
 fix_recenter.html
 fix_restrain.html
 fix_rigid.html
+fix_rhok.html
 fix_rx.html
 fix_saed_vtk.html
 fix_setforce.html
@@ -353,6 +358,7 @@ compute_pe.html
 compute_pe_atom.html
 compute_plasticity_atom.html
 compute_pressure.html
+compute_pressure_uef.html
 compute_property_atom.html
 compute_property_chunk.html
 compute_property_local.html
@@ -402,6 +408,7 @@ compute_temp_region.html
 compute_temp_region_eff.html
 compute_temp_rotate.html
 compute_temp_sphere.html
+compute_temp_uef.html
 compute_ti.html
 compute_torque_chunk.html
 compute_vacf.html
@@ -436,6 +443,7 @@ pair_edip.html
 pair_eff.html
 pair_eim.html
 pair_exp6_rx.html
+pair_extep.html
 pair_gauss.html
 pair_gayberne.html
 pair_gran.html
@@ -504,6 +512,7 @@ pair_tersoff_mod.html
 pair_tersoff_zbl.html
 pair_thole.html
 pair_tri_lj.html
+pair_ufm.html
 pair_vashishta.html
 pair_yukawa.html
 pair_yukawa_colloid.html
@@ -513,7 +522,7 @@ pair_zero.html
 bond_class2.html
 bond_fene.html
 bond_fene_expand.html
-bond_oxdna.html
+bond_gromos.html
 bond_harmonic.html
 bond_harmonic_shift.html
 bond_harmonic_shift_cut.html
@@ -521,6 +530,7 @@ bond_hybrid.html
 bond_morse.html
 bond_none.html
 bond_nonlinear.html
+bond_oxdna.html
 bond_quartic.html
 bond_table.html
 bond_zero.html

doc/src/neb.txt

@@ -322,9 +322,9 @@ the fix neb command.
 The forward (reverse) energy barrier is the potential energy of the
 highest replica minus the energy of the first (last) replica.
 
-Supplementary informations for all replicas can be printed out to the
-screen and master log.lammps file by adding the verbose keyword. These
-informations include the following.  The "path angle" (pathangle) for
+Supplementary information for all replicas can be printed out to the
+screen and master log.lammps file by adding the verbose keyword. This
+information include the following.  The "path angle" (pathangle) for
 the replica i which is the angle between the 3N-length vectors (Ri-1 -
 Ri) and (Ri+1 - Ri) (where Ri is the atomic coordinates of replica
 i). A "path angle" of 180 indicates that replicas i-1, i and i+1 are
@@ -339,8 +339,8 @@ energy gradient of image i.  ReplicaForce is the two-norm of the
 3N-length force vector (including nudging forces) for replica i.
 MaxAtomForce is the maximum force component of any atom in replica i.
 
-When a NEB calculation does not converge properly, these suplementary
-informations can help understanding what is going wrong. For instance
+When a NEB calculation does not converge properly, the suplementary
+information can help understanding what is going wrong. For instance
 when the path angle becomes accute the definition of tangent used in
 the NEB calculation is questionable and the NEB cannot may diverge
 "(Maras)"_#Maras2.

doc/src/package.txt

@@ -62,7 +62,7 @@ args = arguments specific to the style :l
       {no_affinity} values = none
   {kokkos} args = keyword value ...
     zero or more keyword/value pairs may be appended
-    keywords = {neigh} or {neigh/qeq} or {newton} or {binsize} or {comm} or {comm/exchange} or {comm/forward}
+    keywords = {neigh} or {neigh/qeq} or {newton} or {binsize} or {comm} or {comm/exchange} or {comm/forward} or {comm/reverse}
       {neigh} value = {full} or {half}
         full = full neighbor list
         half = half neighbor list built in thread-safe manner
@@ -75,9 +75,10 @@ args = arguments specific to the style :l
       {binsize} value = size
         size = bin size for neighbor list construction (distance units)
       {comm} value = {no} or {host} or {device}
-        use value for both comm/exchange and comm/forward
+        use value for comm/exchange and comm/forward and comm/reverse
       {comm/exchange} value = {no} or {host} or {device}
       {comm/forward} value = {no} or {host} or {device}
+      {comm/reverse} value = {no} or {host} or {device}
         no = perform communication pack/unpack in non-KOKKOS mode
         host = perform pack/unpack on host (e.g. with OpenMP threading)
         device = perform pack/unpack on device (e.g. on GPU)
@@ -335,7 +336,8 @@ from the USER-INTEL package is not used, then the LRT setting is
 ignored and no extra threads are generated. Enabling LRT will replace
 the "run_style"_run_style.html with the {verlet/lrt/intel} style that
 is identical to the default {verlet} style aside from supporting the
-LRT feature.
+LRT feature. This feature requires setting the preprocessor flag
+-DLMP_INTEL_USELRT in the makefile when compiling LAMMPS.
 
 The {balance} keyword sets the fraction of "pair
 style"_pair_style.html work offloaded to the coprocessor for split
@@ -428,17 +430,18 @@ Coulombic solver"_kspace_style.html because the GPU is faster at
 performing pairwise interactions, then this rule of thumb may give too
 large a binsize.
 
-The {comm} and {comm/exchange} and {comm/forward} keywords determine
+The {comm} and {comm/exchange} and {comm/forward} and {comm/reverse} keywords determine
 whether the host or device performs the packing and unpacking of data
 when communicating per-atom data between processors.  "Exchange"
 communication happens only on timesteps that neighbor lists are
 rebuilt.  The data is only for atoms that migrate to new processors.
-"Forward" communication happens every timestep.  The data is for atom
+"Forward" communication happens every timestep. "Reverse" communication
+happens every timestep if the {newton} option is on.  The data is for atom
 coordinates and any other atom properties that needs to be updated for
 ghost atoms owned by each processor.
 
 The {comm} keyword is simply a short-cut to set the same value
-for both the {comm/exchange} and {comm/forward} keywords.
+for both the {comm/exchange} and {comm/forward} and {comm/reverse} keywords.
 
 The value options for all 3 keywords are {no} or {host} or {device}.
 A value of {no} means to use the standard non-KOKKOS method of

doc/src/pair_body_rounded_polygon.txt

@@ -0,0 +1,19 @@
+"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
+
+pair_style body/rounded/polygon command :h3
+
+[Description:]
+
+Note: This feature is not yet implemented.
+
+[Related commands:]
+
+"pair_style body"_pair_body.html
+
+[Default:] none

doc/src/pair_born.txt

@@ -17,6 +17,7 @@ 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/gpu command :h3
 pair_style born/coul/wolf/omp command :h3
 pair_style born/coul/dsf command :h3
@@ -36,7 +37,7 @@ args = list of arguments for a particular style :ul
   {born/coul/msm} args = cutoff (cutoff2)
     cutoff = global cutoff for non-Coulombic (and Coulombic if only 1 arg) (distance units)
     cutoff2 = global cutoff for Coulombic (optional) (distance units)
-  {born/coul/wolf} args = alpha cutoff (cutoff2)
+  {born/coul/wolf} or {born/coul/wolf/cs} args = alpha cutoff (cutoff2)
     alpha = damping parameter (inverse distance units)
     cutoff = global cutoff for non-Coulombic (and Coulombic if only 1 arg) (distance units)
     cutoff2 = global cutoff for Coulombic (optional) (distance units)
@@ -65,6 +66,7 @@ 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
 
@@ -106,8 +108,9 @@ 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"_Section_howto.html#howto_25
 to allow charges on core and shell particles to be separated by r =
-0.0. The same correction is introduced for {born/coul/dsf/cs} style
-which is identical to {born/coul/dsf}.
+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.

doc/src/pair_buck6d_coul_gauss.txt

@@ -0,0 +1,138 @@
+"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
+
+pair_style buck6d/coul/gauss/dsf :h3
+pair_style buck6d/coul/gauss/long :h3
+
+[Syntax:]
+
+pair_style style args :pre
+
+style = {buck6d/coul/gauss/dsf} or {buck6d/coul/gauss/long}
+args = list of arguments for a particular style :ul
+  {buck6d/coul/gauss/dsf} args = smooth cutoff (cutoff2)
+    smooth  = smoothing onset within Buckingham cutoff (ratio)
+    cutoff  = global cutoff for Buckingham (and Coulombic if only 1 arg) (distance units)
+    cutoff2 = global cutoff for Coulombic (optional) (distance units)
+  {buck6d/coul/gauss/long} args = smooth smooth2 cutoff (cutoff2)
+    smooth   = smoothing onset within Buckingham cutoff (ratio)
+    smooth2  = smoothing onset within Coulombic cutoff (ratio)
+    cutoff   = global cutoff for Buckingham (and Coulombic if only 1 arg) (distance units)
+    cutoff2  = global cutoff for Coulombic (optional) (distance units) :pre
+
+[Examples:]
+
+pair_style buck6d/coul/gauss/dsf    0.9000    12.0000
+pair_coeff 1  1  1030.  3.061  457.179  4.521  0.608 :pre
+
+pair_style buck6d/coul/gauss/long   0.9000  1.0000  12.0000
+pair_coeff 1  1  1030.  3.061  457.179  4.521  0.608 :pre
+
+[Description:]
+
+The {buck6d/coul/gauss} styles evaluate vdW and Coulomb
+interactions following the MOF-FF force field after
+"(Schmid)"_#Schmid. The vdW term of the {buck6d} styles 
+computes a dispersion damped Buckingham potential:
+
+:c,image(Eqs/pair_buck6d.jpg)
+
+where A and C are a force constant, kappa is an ionic-pair dependent 
+reciprocal length parameter, D is a dispersion correction parameter, 
+and the cutoff Rc truncates the interaction distance.
+The first term in the potential corresponds to the Buckingham 
+repulsion term and the second term to the dispersion attraction with 
+a damping correction analog to the Grimme correction used in DFT.  
+The latter corrects for artifacts occurring at short distances which 
+become an issue for soft vdW potentials. 
+
+The {buck6d} styles include a smoothing function which is invoked 
+according to the global smooting parameter within the specified 
+cutoff.  Hereby a parameter of i.e. 0.9 invokes the smoothing 
+within 90% of the cutoff.  No smoothing is applied at a value
+of 1.0. For the {gauss/dsf} style this smoothing is only applicable 
+for the dispersion damped Buckingham potential. For the {gauss/long}
+styles the smoothing function can also be invoked for the real
+space coulomb interactions which enforce continous energies and 
+forces at the cutoff.
+
+Both styles {buck6d/coul/gauss/dsf} and {buck6d/coul/gauss/long} 
+evaluate a Coulomb potential using spherical Gaussian type charge 
+distributions which effectively dampen electrostatic ineractions 
+for high charges at close distances.  The electrostatic potential
+is thus evaluated as:
+
+:c,image(Eqs/pair_coul_gauss.jpg)
+
+where C is an energy-conversion constant, Qi and Qj are the 
+charges on the 2 atoms, epsilon is the dielectric constant which 
+can be set by the "dielectric"_dielectric.html command, alpha is 
+ion pair dependent damping parameter and erf() is the error-function.  
+The cutoff Rc truncates the interaction distance.
+
+The style {buck6d/coul/gauss/dsf} computes the Coulomb interaction
+via the damped shifted force model described in "(Fennell)"_#Fennell 
+approximating an Ewald sum similar to the "pair coul/dsf"_pair_coul.html
+styles. In {buck6d/coul/gauss/long} an additional damping factor is 
+applied to the Coulombic term so it can be used in conjunction with the 
+"kspace_style"_kspace_style.html command and its {ewald} or {pppm} 
+options. The Coulombic cutoff in this case separates the real and 
+reciprocal space evaluation of the Ewald sum.
+
+If one cutoff is specified it is used for both the vdW and Coulomb
+terms.  If two cutoffs are specified, the first is used as the cutoff 
+for the vdW terms, and the second is the cutoff for the Coulombic term.
+
+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:
+
+A (energy units)
+rho (distance^-1 units)
+C (energy-distance^6 units)
+D (distance^14 units)
+alpha (distance^-1 units)
+cutoff (distance units) :ul
+
+The second coefficient, rho, must be greater than zero. The latter 
+coefficient is optional.  If not specified, the global vdW cutoff 
+is used. 
+
+:line
+
+[Mixing, shift, table, tail correction, restart, rRESPA info]:
+
+These pair styles do not support mixing.  Thus, coefficients for all
+I,J pairs must be specified explicitly.
+
+These styles do not support the "pair_modify"_pair_modify.html shift
+option for the energy. Instead the smoothing function should be applied
+by setting the global smoothing parameter to a value < 1.0.
+
+These styles write their information to "binary restart
+files"_restart.html, so pair_style and pair_coeff commands do not need
+to be specified in an input script that reads a restart file.
+
+[Restrictions:]
+
+These styles are part of the USER-MOFFF package.  They are only enabled 
+if LAMMPS was built with that package.  See the
+"Making LAMMPS"_Section_start.html#start_3 section for more info.
+
+[Related commands:]
+
+"pair_coeff"_pair_coeff.html
+
+[Default:] none
+
+:link(Schmid)
+[(Schmid)] S. Bureekaew, S. Amirjalayer, M. Tafipolsky, C. Spickermann, T.K. Roy and R. Schmid, Phys. Status Solidi B, 6, 1128 (2013).
+:link(Fennell)
+[(Fennell)] C. J. Fennell, J. D. Gezelter, J Chem Phys, 124, 234104 (2006).