patch 5Feb18

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

cmake/CMakeLists.txt

@@ -37,6 +37,10 @@ enable_language(CXX)
 #####################################################################
 include(CheckCCompilerFlag)
 
+if (${CMAKE_CXX_COMPILER_ID} STREQUAL "Intel")
+  set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -restrict")
+endif()
+
 ########################################################################
 # User input options                                                   #
 ########################################################################
@@ -76,7 +80,7 @@ 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")
+  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")
@@ -100,8 +104,8 @@ 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-MOFFF 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-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})
@@ -166,13 +170,6 @@ 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) # for liblammps
-  endif()
-endif()
-
 if(ENABLE_MSCG OR ENABLE_USER-ATC OR ENABLE_USER-AWPMD OR ENABLE_USER-QUIP OR ENABLE_LATTE)
   find_package(LAPACK)
   if(NOT LAPACK_FOUND)
@@ -194,14 +191,13 @@ if(ENABLE_PYTHON)
   add_definitions(-DLMP_PYTHON)
   include_directories(${PYTHON_INCLUDE_DIR})
   list(APPEND LAMMPS_LINK_LIBS ${PYTHON_LIBRARY})
-  if(NOT PYTHON_INSTDIR)
+  if(BUILD_SHARED_LIBS)
-    execute_process(COMMAND ${PYTHON_EXECUTABLE}
+    if(NOT PYTHON_INSTDIR)
-	  -c "import distutils.sysconfig as cg; print(cg.get_python_lib(1,0,prefix='${CMAKE_INSTALL_PREFIX}'))"
+      execute_process(COMMAND ${PYTHON_EXECUTABLE}
-      OUTPUT_VARIABLE PYTHON_INSTDIR OUTPUT_STRIP_TRAILING_WHITESPACE)
+        -c "import distutils.sysconfig as cg; print(cg.get_python_lib(1,0,prefix='${CMAKE_INSTALL_PREFIX}'))"
-  endif()
+        OUTPUT_VARIABLE PYTHON_INSTDIR OUTPUT_STRIP_TRAILING_WHITESPACE)
-  install(FILES ${CMAKE_CURRENT_SOURCE_DIR}/../python/lammps.py DESTINATION ${PYTHON_INSTDIR})
+    endif()
-  if(NOT BUILD_SHARED_LIBS)
+    install(FILES ${CMAKE_CURRENT_SOURCE_DIR}/../python/lammps.py DESTINATION ${PYTHON_INSTDIR})
-    message(FATAL_ERROR "Python package need lammps to be build shared, use -DBUILD_SHARED_LIBS=ON")
   endif()
 endif()
 
@@ -397,6 +393,10 @@ foreach(SIMPLE_LIB REAX MEAM POEMS USER-ATC USER-AWPMD USER-COLVARS USER-H5MD
       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()
@@ -476,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}")
@@ -483,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})
@@ -665,7 +678,9 @@ include_directories(${LAMMPS_STYLE_HEADERS_DIR})
 ############################################
 add_library(lammps ${LIB_SOURCES})
 target_link_libraries(lammps ${LAMMPS_LINK_LIBS})
-add_dependencies(lammps ${LAMMPS_DEPS})
+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})

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

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="22 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
-22 Sep 2017 version :c,h4
+5 Feb 2018 version :c,h4
 
 Version info: :h4
 

doc/src/Section_commands.txt

@@ -619,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,
+"property/atom (k)"_fix_property_atom.html,
-"python"_fix_python.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,
@@ -637,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/nph"_fix_rigid.html,
-"rigid/small/npt (o)"_fix_rigid.html,
+"rigid/small/npt"_fix_rigid.html,
-"rigid/small/nve (o)"_fix_rigid.html,
+"rigid/small/nve"_fix_rigid.html,
-"rigid/small/nvt (o)"_fix_rigid.html,
+"rigid/small/nvt"_fix_rigid.html,
 "setforce (k)"_fix_setforce.html,
 "shake"_fix_shake.html,
 "spring"_fix_spring.html,
@@ -668,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,
@@ -683,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,
@@ -720,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/bonds (k)"_fix_reax_bonds.html,
-"reax/c/species"_fix_reaxc_species.html,
+"reax/c/species (k)"_fix_reaxc_species.html,
-"rx"_fix_rx.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,
@@ -856,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,
@@ -884,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
@@ -901,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,
@@ -915,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 (giko)"_pair_buck.html,
-"buck/coul/cut (gkio)"_pair_buck.html,
+"buck/coul/cut (giko)"_pair_buck.html,
-"buck/coul/long (gkio)"_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,
@@ -934,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 (gikot)"_pair_eam.html,
-"eam/alloy (gkiot)"_pair_eam.html,
+"eam/alloy (gikot)"_pair_eam.html,
-"eam/fs (gkiot)"_pair_eam.html,
+"eam/fs (gikot)"_pair_eam.html,
 "eim (o)"_pair_eim.html,
 "gauss (go)"_pair_gauss.html,
 "gayberne (gio)"_pair_gayberne.html,
@@ -953,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,
@@ -1005,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
@@ -1031,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,
@@ -1063,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,
@@ -1080,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,
@@ -1087,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,
@@ -1111,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,
@@ -1177,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,
@@ -1190,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,
@@ -1213,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
@@ -1241,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
 

doc/src/Section_packages.txt

@@ -138,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, -
@@ -150,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
@@ -242,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.
@@ -705,7 +707,7 @@ dynamics can be run with LAMMPS using density-functional tight-binding
 quantum forces calculated by LATTE.
 
 More information on LATTE can be found at this web site:
-"https://github.com/lanl/LATTE"_#latte_home.  A brief technical
+"https://github.com/lanl/LATTE"_latte_home.  A brief technical
 description is given with the "fix latte"_fix_latte.html command.
 
 :link(latte_home,https://github.com/lanl/LATTE)
@@ -728,11 +730,12 @@ make lib-latte args="-b"                # download and build in lib/latte/LATTE-
 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", are created in lib/latte to point into the LATTE home dir.
+"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 apporpriate
+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
@@ -982,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)
@@ -1779,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.
@@ -2229,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.
 
@@ -2257,6 +2260,44 @@ 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:]
@@ -2493,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.
 
@@ -2552,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)
@@ -2770,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
+A "dump vtk"_dump_vtk.html command which outputs snapshot info in the
-snapshot info in the "VTK format"_vtk, enabling visualization by
+"VTK format"_vtk, enabling visualization by "Paraview"_paraview or
-"Paraview"_paraview or other visuzlization packages.
+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
@@ -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)
+In this case Nm defines the number of NUMA regions (typically sockets)
-on a node which will be utilizied by a single MPI rank.  By default Nm
+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
+data, into its LAMMPS equivalent. Support for the CMAP correction of
-LAMMPS atom dumps into PDB files.
+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, 
+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,
+lj/charmm/coul/long, lj/cut, lj/cut/coul/long, lj/long/coul/long, 
-sw, tersoff :l
+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 Broadwell), Intel Xeon Phi 7250 processors (code-named
-(code-named Knights Landing) with "June 2017" LAMMPS built with
+Knights Landing), and Intel Xeon Gold 6148 processors (code-named
-Intel Parallel Studio 2017 update 2. Results are with 1 MPI task
+Skylake) with "June 2017" LAMMPS built with Intel Parallel Studio
-per physical core. See {src/USER-INTEL/TEST/README} for the raw
+2017 update 2. Results are with 1 MPI task per physical core. See
-simulation rates and instructions to reproduce.
+{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
@@ -108,7 +114,7 @@ $t should be 2 for Intel Xeon CPUs and 2 or 4 for Intel Xeon Phi :l
 For some of the simple 2-body potentials without long-range
 electrostatics, performance and scalability can be better with
 the "newton off" setting added to the input script :l
-For simulations on higher node counts, add "processors * * * grid 
+For simulations on higher node counts, add "processors * * * grid
 numa" to the beginning of the input script for better scalability :l
 If using {kspace_style pppm} in the input script, add
 "kspace_modify diff ad" for better performance :l
@@ -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
+For simulations using {kspace_style pppm} on Intel CPUs supporting
-supporting AVX-512:
+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
+are as follows. When using Intel compilers, "-restrict" is required 
-using Intel compilers, "-restrict" is required and "-qopenmp" is
+and "-qopenmp" is highly recommended for CCFLAGS and LINKFLAGS. 
-highly recommended for CCFLAGS and LINKFLAGS. LIB should include
+CCFLAGS should include "-DLMP_INTEL_USELRT" (unless POSIX Threads
-"-ltbbmalloc". For builds supporting offload, "-DLMP_INTEL_OFFLOAD"
+are not supported in the build environment) and "-DLMP_USE_MKL_RNG"
-is required for CCFLAGS and "-qoffload" is required for LINKFLAGS.
+(unless Intel Math Kernel Library (MKL) is not available in the build
-Other recommended CCFLAG options for best performance are
+environment). For Intel compilers, LIB should include "-ltbbmalloc" 
-"-O2 -fno-alias -ansi-alias -qoverride-limits fp-model fast=2
+or if the library is not available, "-DLMP_INTEL_NO_TBB" can be added
--no-prec-div".
+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

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)
+Kokkos is a templated C++ library that provides abstractions to allow
-with contributions of various styles by others, including Sikandar
+a single implementation of an application kernel (e.g. a pair style) to run efficiently on
-Mashayak (UIUC), Stan Moore (Sandia), and Ray Shan (Sandia).  The
+different kinds of hardware, such as GPUs, Intel Xeon Phis, or many-core
-underlying Kokkos library was written primarily by Carter Edwards,
+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.
+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
-The Kokkos library is part of
+Mashayak (UIUC), Ray Shan (Sandia), and Dan Ibanez (Sandia). For more information on developing using Kokkos abstractions
-"Trilinos"_http://trilinos.sandia.gov/packages/kokkos and can also be
+see the Kokkos programmers' guide at /lib/kokkos/doc/Kokkos_PG.pdf.
-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.
 
 Kokkos currently provides support for 3 modes of execution (per MPI
-task).  These are OpenMP (for many-core CPUs), Cuda (for NVIDIA GPUs),
+task). These are Serial (MPI-only for CPUs and Intel Phi), OpenMP (threading
-and OpenMP (for Intel Phi).  Note that the KOKKOS package supports
+for many-core CPUs and Intel Phi), and CUDA (for NVIDIA GPUs). You choose the mode at build time to
-running on the Phi in native mode, not offload mode like the
-USER-INTEL package supports.  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.
-
-use a C++11 compatible compiler
-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
-
-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
-
-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
-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
-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.
-
-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.
-
 [Building LAMMPS with the KOKKOS package:]
 
-You must choose at build time whether to build for CPUs (OpenMP),
+NOTE: Kokkos support within LAMMPS must be built with a C++11 compatible
-GPUs, or Phi.
+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.
 
-You can do any of these in one line, using the suitable make command
+The recommended method of building the KOKKOS package is to start with the provided Kokkos
-line flags as described in "Section 4"_Section_packages.html of the
+Makefiles in /src/MAKE/OPTIONS/. You may need to modify the KOKKOS_ARCH variable in the Makefile
-manual. If run from the src directory, these
+to match your specific hardware. For example:
-commands will create src/lmp_kokkos_omp, lmp_kokkos_cuda_mpi, 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_mpi.
 
-The latter two steps can be done using the "-k on", "-pk kokkos" and
+for Sandy Bridge CPUs, set KOKKOS_ARCH=SNB
-"-sf kk" "command-line switches"_Section_start.html#start_6
+for Broadwell CPUs, set KOKKOS_ARCH=BWD
-respectively.  Or the effect of the "-pk" or "-sf" switches can be
+for K80 GPUs, set KOKKOS_ARCH=Kepler37
-duplicated by adding the "package kokkos"_package.html or "suffix
+for P100 GPUs and Power8 CPUs, set KOKKOS_ARCH=Pascal60,Power8 :ul
-kk"_suffix.html commands respectively to your input script.
 
+See the [Advanced Kokkos Options] section below for a listing of all KOKKOS_ARCH options.
 
-Or you can follow these steps:
+[Compile for CPU-only (MPI only, no threading):]
 
-CPU-only (run all-MPI or with OpenMP 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
-cd lammps/src
+following:
-make yes-kokkos
-make kokkos_omp :pre
-
-CPU-only (only MPI, no threading):
 
 cd lammps/src
 make yes-kokkos
 make kokkos_mpi_only :pre
 
-Intel Xeon Phi (Intel Compiler, Intel MPI):
+[Compile for CPU-only (MPI plus OpenMP threading):]
+
+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.
+
+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
 
-CPUs and GPUs (with MPICH or OpenMPI):
+[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
 
-These examples set the KOKKOS-specific OMP, MIC, CUDA variables on the
+[Alternative Methods of Compiling:]
-make command line which requires a GNU-compatible make command.  Try
+
+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, e.g. g++ in the
+with different KOKKOS options and the *same* target, then you *must* perform a "make clean-all"
-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
-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
+[Running LAMMPS with the KOKKOS package:]
-package.  All compilation and computation is performed in double
-precision.
 
-There are other allowed options when building with the KOKKOS package.
+All Kokkos operations occur within the
-As above, they can be set either as variables on the make command line
+context of an individual MPI task running on a single node of the
-or in Makefile.machine.  This is the full list of options, including
+machine. The total number of MPI tasks used by LAMMPS (one or
-those discussed above, Each takes a value shown below.  The
+multiple per compute node) is set in the usual manner via the mpirun
-default value is listed, which is set in the
+or mpiexec commands, and is independent of Kokkos. E.g. the mpirun
-lib/kokkos/Makefile.kokkos file.
+command in OpenMPI does this via its
+-np and -npernode switches. Ditto for MPICH via -np and -ppn.
 
-#Default settings specific options
+[Running on a multi-core CPU:]
-#Options: force_uvm,use_ldg,rdc
 
-KOKKOS_DEVICES, values = {OpenMP}, {Serial}, {Pthreads}, {Cuda}, default = {OpenMP}
+Here is a quick overview of how to use the KOKKOS package
-KOKKOS_ARCH, values = {KNC}, {SNB}, {HSW}, {Kepler}, {Kepler30}, {Kepler32}, {Kepler35}, {Kepler37}, {Maxwell}, {Maxwell50}, {Maxwell52}, {Maxwell53}, {ARMv8}, {BGQ}, {Power7}, {Power8}, default = {none}
+for CPU acceleration, assuming one or more 16-core nodes.
-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
+mpirun -np 16 lmp_kokkos_mpi_only -k on -sf kk -in in.lj        # 1 node, 16 MPI tasks/node, no multi-threading
-(within LAMMPS).  KOKKOS_DEVICES=OpenMP means that OpenMP will be
+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
-used.  KOKKOS_DEVICES=Pthreads means that pthreads will be used.
+mpirun -np 2 lmp_kokkos_omp -k on t 8 -sf kk -in in.lj          # 1 node,  2 MPI tasks/node, 8 threads/task
-KOKKOS_DEVICES=Cuda means an NVIDIA GPU running CUDA will be used.
+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
-
-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.
 
+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_6 to enable the KOKKOS package.  It
+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
+system. Those arguments are "documented
-here"_Section_start.html#start_6.  The two most commonly used
+here"_Section_start.html#start_7. For OpenMP use:
-options are:
 
--k on t Nt g Ng :pre
+-k on t Nt :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 "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.
 
-Use the "-sf kk" "command-line switch"_Section_start.html#start_6,
+The "-sf kk" "command-line switch"_Section_start.html#start_7
-which will automatically append "kk" to styles that support it.  Use
+will automatically append the "/kk" suffix to styles that support it.
-the "-pk kokkos" "command-line switch"_Section_start.html#start_6 if
+In this manner no modification to the input script is needed. Alternatively,
-you wish to change any of the default "package kokkos"_package.html
+one can run with the KOKKOS package by editing the input script as described below.
-optionns set by the "-k on" "command-line
-switch"_Section_start.html#start_6.
 
-
+NOTE: The default for the "package kokkos"_package.html command is
-
-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
+pairwise and bonded interactions. However, when running on CPUs, it
-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
+styles. It can also be faster to use non-threaded communication.
-switch"_Section_start.html#start_6.
+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:
 
-[Or run with the KOKKOS package by editing an input script:]
+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
 
-The discussion above for the mpirun/mpiexec command and setting
+If the "newton"_newton.html command is used in the input
-appropriate thread and GPU values for host=OMP or host=MIC or
+script, it can also override the Newton flag defaults.
-device=CUDA are the same.
+
+[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).
+
+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.
+
+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.
+
+[Run with the KOKKOS package by editing an input script:]
+
+Alternatively the effect of the "-sf" or "-pk" switches can be
+duplicated by adding the "package kokkos"_package.html or "suffix
+kk"_suffix.html commands to your input script.
+
+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:]
 
@@ -353,7 +363,7 @@ Generally speaking, the following rules of thumb apply:
 When running on CPUs only, with a single thread per MPI task,
 performance of a KOKKOS style is somewhere between the standard
 (un-accelerated) styles (MPI-only mode), and those provided by the
-USER-OMP package.  However the difference between all 3 is small (less
+USER-OMP package. However the difference between all 3 is small (less
 than 20%). :ulb,l
 
 When running on CPUs only, with multiple threads per MPI task,
@@ -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
+There are other allowed options when building with the KOKKOS package.
-hardware configurations listed above.
+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
+KOKKOS_DEVICES, values = {Serial}, {OpenMP}, {Pthreads}, {Cuda}, default = {OpenMP}
-See its doc page for details and default settings.  Experimenting with
+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}
-its options can provide a speed-up for specific calculations.
+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
+KOKKOS_ARCH enables compiler switches needed when compiling for a
-tasks/node * number of threads/task should not exceed N, and should
+specific hardware:
-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).
 
-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
+KOKKOS_USE_TPLS=hwloc binds threads to hardware cores, so they do not
-run with N MPI tasks/node and 1 thread/task
+migrate during a simulation. KOKKOS_USE_TPLS=hwloc should always be
-run with settings in between these extremes :ul
+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
+KOKKOS_DEBUG is only useful when developing a Kokkos-enabled style
-performance to bind both MPI tasks to physical cores, and threads to
+within LAMMPS. KOKKOS_DEBUG=yes enables printing of run-time
-physical cores, so they do not migrate during a simulation.
+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
+KOKKOS_CXX_STANDARD and KOKKOS_OPTIONS are typically not changed when building LAMMPS.
-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 ...
+KOKKOS_CUDA_OPTIONS are additional options for CUDA. The LAMMPS KOKKOS package must be compiled
-Mvapich2 2.0: mpiexec -np 2 -bind-to socket -map-by socket ./lmp_mvapich ... :pre
+with the {enable_lambda} option when using GPUs.
-
-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.
 
 [Restrictions:]
 
-As noted above, if using GPUs, the number of MPI tasks per compute
+Currently, there are no precision options with the KOKKOS
-node should equal to the number of GPUs per compute node.  In the
+package. All compilation and computation is performed in double
-future Kokkos will support assigning multiple MPI tasks to a single
+precision.
-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.

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
+package.  For the {class2/p6} style LAMMPS needs to be built with the
-for more info on packages.
+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 yes
-atom_modify map array sort 10000 2.0
+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
+The {map} keyword determines how atoms with specific IDs are found
-atom styles.  Lookups are performed by bond (angle, etc) routines in
+when required.  An example are the bond (angle, etc) methods which
-LAMMPS to find the local atom index associated with a global atom ID.
+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
+When the {map} keyword is not specified in your input script, LAMMPS
-of length N, where N is the largest atom ID in the system.  This is a
+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
+for large simulations.  For a {hash}-style map, a hash table is
-the lookups.  This can be slightly slower than the {array} method, but
+created on each processor, which finds an atom ID in constant time
-its memory cost is proportional to the number of atoms owned by a
+(independent of the global number of atom IDs).  It can be slightly
-processor, i.e. N/P when N is the total number of atoms in the system
+slower than the {array} map, but its memory cost is proportional to
-and P is the number of processors.
+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.
 
 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

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
+processors, equals the number of dihedral angles in the system, modified
-group parameter as explained below.
+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
+  {rotate} values = theta Rx Ry Rz
-    Rx,Ry,Rz = rotation vector for single molecule
     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        xx internal 0.0
-variable        yy equal 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
+The {rotate} keyword can only be used with the {single} style and
-a single molecule to specify the orientation at which the molecule is
+when adding a single molecule. It allows to specify the orientation
-inserted.  The axis of rotation is determined by the rotation vector
+at which the molecule is inserted.  The axis of rotation is
-(Rx,Ry,Rz) that goes through the insertion point.  The specified
+determined by the rotation vector (Rx,Ry,Rz) that goes through the
-{theta} determines the angle of rotation around that axis.  Note that
+insertion point.  The specified {theta} determines the angle of
-the direction of rotation for the atoms around the rotation axis is
+rotation around that axis.  Note that the direction of rotation for
-consistent with the right-hand rule: if your right-hand's thumb points
+the atoms around the rotation axis is consistent with the right-hand
-along {R}, then your fingers wrap around the axis in the direction of
+rule: if your right-hand's thumb points along {R}, then your fingers
-rotation.
+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
+LAMMPS"_Section_start.html#start_3 section for more info.
-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.
 
 [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
+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} or {at} N
+  {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
+overwrite an existing file with the same name.
-({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
+:line
-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
+The {at} keyword only applies to the {netcdf} dump style.  It can only
-"minimize"_minimize.html command.  Once the dump file has been opened, this
+be used if the {append yes} keyword is also used.  The {N} argument is
-keyword has no further effect.
+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_cmap.txt

@@ -120,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
+adjusted independently and simultaneously by this command.  
-can be used to perform non-equilibrium MD (NEMD) simulations of a
+
-continuously strained system.  See the "fix
+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_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
+Every N timesteps the fix attempts both GCMC exchanges
-(insertions or deletions) of gas atoms or molecules of the given type
+(insertions or deletions) and MC moves of gas atoms or molecules.
-between the simulation cell and the imaginary reservoir. It also
+On those timesteps, the average number of attempted GCMC exchanges is X,
-attempts a number of Monte Carlo moves (translations and molecule
+while the average number of attempted MC moves is M. 
-rotations) of gas of the given type within the simulation cell or
+For GCMC exchanges of either molecular or atomic gasses,
-region.  The average number of attempted GCMC exchanges is X. The
+these exchanges can be either deletions or insertions,
-average number of attempted MC moves is M.  M should typically be
+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
+All inserted particles are always added to two groups: the default
-attempted with 50% probability. For MC moves of atomic gasses,
+group "all" and the fix group specified in the fix command (which can
-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
 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
+This fix cannot be used to perform GCMC insertions of gas atoms or
-molecules other than the exchanged type, but MC deletions,
+molecules other than the exchanged type, but GCMC deletions,
-translations, and rotations can be performed on any atom/molecule in
+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
+molecule.  The coordinates, atom types, charges, etc., as well as any
-bond/angle/etc and special neighbor information for the molecule can
+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
+deleted atoms are any atoms that have been inserted or that already
-the user-specified fix group. For molecular gasses, exchanged
+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
+two groups: the default group "all" and the fix group
-gcmc command (which can also be "all").
+(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
+The {full_energy} option means that the fix calculates the total
-potential energy of the entire simulated system. The total system
+potential energy of the entire simulated system, instead of just
-energy before and after the proposed GCMC move is then used in the
+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
+proposed change. By default, this option is off,
-partial energies are computed to determine the difference in energy
+in which case only
-that would be caused by the proposed GCMC move.
+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
+The {group} keyword adds all inserted atoms to the
-
-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
 "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

@@ -66,7 +66,7 @@ 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"_#Finnis) and coworkers. 
+("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
@@ -173,7 +173,7 @@ M. Haugk, T. Frauenheim, S. Suhai, and G. Seifert, Phys. Rev. B, 58,
 M. Haugk, T. Frauenheim, S. Suhai, and G. Seifert, Phys. Rev. B, 58,
 7260 (1998).
 
-:link(Finnis)
+:link(Finnis2)
 [(Finnis)] M. W. Finnis, A. T. Paxton, M. Methfessel, and M. van
 Schilfgarde, Phys. Rev. Lett., 81, 5149 (1998).
 
@@ -197,11 +197,11 @@ J. Sci. Comput. 36 (2), 147-170, (2014).
 [(Niklasson2014)] A. M. N. Niklasson and M. Cawkwell, J. Chem. Phys.,
 141, 164123, (2014).
 
-:link(Niklasson2014)
+:link(Niklasson2017)
 [(Niklasson2017)] A. M. N. Niklasson, J. Chem. Phys., 147, 054103 (2017).
 
-:link(Niklasson2012)
+:link(Cawkwell2012)
-[(Niklasson2017)] A. M. N. Niklasson, M. J. Cawkwell, Phys. Rev. B, 86
+[(Cawkwell2012)] A. M. N. Niklasson, M. J. Cawkwell, Phys. Rev. B, 86
 (17), 174308 (2012).
 
 :link(Negre2016)

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
+The "spring" constant on the difference in energies is the specified
-energy.  The "spring" constant on the difference in energies is the
+{Kspring3} value.
-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
+Finally, note that the last replica may never reach the target energy
-minimum which has a larger energy than the energy of the first
+if it is stuck in a local minima which has a larger energy than the
-replica, a NEB calculation using an {estyle} of {last/efirst} or
+target energy.
-{last/efirst/middle} cannot reach final convergence.
 
 [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",
+this, the thermostat and barostat fixes create their own computes of
-as if one of these two sets of commands had been issued:
+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
+For fix nvt, the group for the new temperature compute is the same as
-pressure"_compute_pressure.html commands for details.  Note that the
+the fix group.  For fix npt and fix nph, the group for both the new
-IDs of the new computes are the fix-ID + underscore + "temp" or fix_ID
+temperature and pressure compute is "all" since pressure is computed
-+ underscore + "press".  For fix nvt, the group for the new computes
+for the entire system.  In the case of fix nph, the temperature
-is the same as the fix group.  For fix nph and fix npt, the group for
+compute is not used for thermostatting, but just for a kinetic-energy
-the new computes is "all" since pressure is computed for the entire
+contribution to the pressure.  See the "compute
-system.
+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
+"compute_modify"_compute_modify.html command.  Or you can print this
-or pressure during thermodynamic output via the "thermo_style
+temperature or pressure during thermodynamic output via the
-custom"_thermo_style.html command using the appropriate compute-ID.
+"thermo_style custom"_thermo_style.html command using the appropriate
-It also means that changing attributes of {thermo_temp} or
+compute-ID.  It also means that changing attributes of {thermo_temp}
-{thermo_press} will have no effect on this fix.
+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_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 pf  all python/invoke 50 post_force post_force_callback
-fix eos all python 50 end_of_step end_of_step_callback :pre
+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
@@ -80,7 +89,17 @@ fix 1 rods rigid/npt molecule temp 300.0 300.0 100.0 iso 0.5 0.5 10.0
 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 couple xz
 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
+specified as {molecule} or {custom}, you can define a system that has
-bodies initially.  This is useful when you are using the {mol} keyword
+no rigid bodies initially.  This is useful when you are using the {mol}
-in conjunction with another fix that is adding rigid bodies on-the-fly
+keyword in conjunction with another fix that is adding rigid bodies
-as molecules, such as "fix deposit"_fix_deposit.html or "fix
+on-the-fly as molecules, such as "fix deposit"_fix_deposit.html or
-pour"_fix_pour.html.
+"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

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)

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
+zero or more keyword/value pairs may be appended
-
+keyword = {limit_velocity}  :ul
-keyword = {limit_velocity}  :l
 
   {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
+zero or more keyword/value pairs may be appended
-
+keyword = adjust_radius or limit_velocity :ul
-keyword = adjust_radius or limit_velocity
 
 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/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
+#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=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
+-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
@@ -187,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
@@ -231,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
@@ -241,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
@@ -253,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
@@ -354,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
@@ -403,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
@@ -437,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
@@ -505,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
@@ -514,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
@@ -522,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
+Supplementary information for all replicas can be printed out to the
-screen and master log.lammps file by adding the verbose keyword. These
+screen and master log.lammps file by adding the verbose keyword. This
-informations include the following.  The "path angle" (pathangle) for
+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
+When a NEB calculation does not converge properly, the suplementary
-informations can help understanding what is going wrong. For instance
+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)
@@ -429,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
+0.0.  The same correction is introduced for the {born/coul/dsf/cs}
-which is identical to {born/coul/dsf}.
+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).

doc/src/pair_coul.txt

@@ -29,6 +29,7 @@ pair_style coul/streitz command :h3
 pair_style coul/wolf command :h3
 pair_style coul/wolf/kk command :h3
 pair_style coul/wolf/omp command :h3
+pair_style coul/wolf/cs command :h3
 pair_style tip4p/cut command :h3
 pair_style tip4p/long command :h3
 pair_style tip4p/cut/omp command :h3
@@ -43,6 +44,7 @@ pair_style coul/long cutoff
 pair_style coul/long/cs cutoff
 pair_style coul/long/gpu cutoff
 pair_style coul/wolf alpha cutoff
+pair_style coul/wolf/cs alpha cutoff
 pair_style coul/streitz cutoff keyword alpha
 pair_style tip4p/cut otype htype btype atype qdist cutoff
 pair_style tip4p/long otype htype btype atype qdist cutoff :pre
@@ -72,6 +74,7 @@ pair_style coul/msm 10.0
 pair_coeff * * :pre
 
 pair_style coul/wolf 0.2 9.0
+pair_style coul/wolf/cs 0.2 9.0
 pair_coeff * * :pre
 
 pair_style coul/streitz 12.0 ewald
@@ -202,7 +205,9 @@ interactions outside that distance are computed in reciprocal space.
 
 Style {coul/long/cs} is identical to {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.
+charges on core and shell particles to be separated by r = 0.0.  The
+same correction is introduced for the {coul/wolf/cs} style which is
+identical to {coul/wolf}.
 
 Styles {tip4p/cut} and {tip4p/long} implement the coulomb part of
 the TIP4P water model of "(Jorgensen)"_#Jorgensen3, which introduces

doc/src/pair_cs.txt

@@ -9,12 +9,13 @@
 pair_style born/coul/long/cs command :h3
 pair_style buck/coul/long/cs command :h3
 pair_style born/coul/dsf/cs command :h3
+pair_style born/coul/wolf/cs command :h3
 
 [Syntax:]
 
 pair_style style args :pre
 
-style = {born/coul/long/cs} or {buck/coul/long/cs} or {born/coul/dsf/cs}
+style = {born/coul/long/cs} or {buck/coul/long/cs} or {born/coul/dsf/cs} or {born/coul/wolf/cs}
 args = list of arguments for a particular style :ul
   {born/coul/long/cs} args = cutoff (cutoff2)
     cutoff = global cutoff for non-Coulombic (and Coulombic if only 1 arg) (distance units)
@@ -26,6 +27,10 @@ args = list of arguments for a particular style :ul
     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 (distance units) :pre
+  {born/coul/wolf/cs} args = alpha cutoff (cutoff2)
+    alpha = damping parameter (inverse distance units)
+    cutoff = global cutoff for Buckingham (and Coulombic if only 1 arg) (distance units)
+    cutoff2 = global cutoff for Coulombic (optional) (distance units)
 
 [Examples:]
 
@@ -41,6 +46,10 @@ pair_style born/coul/dsf/cs 0.1 10.0 12.0
 pair_coeff * *   0.0 1.00 0.00 0.00 0.00
 pair_coeff 1 1 480.0 0.25 0.00 1.05 0.50 :pre
 
+pair_style born/coul/wolf/cs 0.25 10.0 12.0
+pair_coeff * *   0.0 1.00 0.00 0.00 0.00
+pair_coeff 1 1 480.0 0.25 0.00 1.05 0.50 :pre
+
 [Description:]
 
 These pair styles are designed to be used with the adiabatic
@@ -73,13 +82,21 @@ the core and shell, epsilon is the dielectric constant and r_min is the
 minimal distance.
 
 The pair style {born/coul/dsf/cs} is identical to the
-"pair_style born/coul/dsf"_pair_born.html style, which uses the
+"pair_style born/coul/dsf"_pair_born.html style, which uses
 the damped shifted force model as in "coul/dsf"_pair_coul.html
 to compute the Coulomb contribution. This approach does not require
 a long-range solver, thus the only correction is the addition of a
 minimal distance to avoid the possible r = 0.0 case for a
 core/shell pair.
 
+The pair style {born/coul/wolf/cs} is identical to the
+"pair_style born/coul/wolf"_pair_born.html style, which uses
+the Wolf summation as in "coul/wolf"_pair_coul.html to compute
+the Coulomb contribution. This approach does not require
+a long-range solver, thus the only correction is the addition of a
+minimal distance to avoid the possible r = 0.0 case for a
+core/shell pair.
+
 [Restrictions:]
 
 These pair styles are part of the CORESHELL package.  They are only

doc/src/pair_dpd.txt

@@ -8,6 +8,7 @@
 
 pair_style dpd command :h3
 pair_style dpd/gpu command :h3
+pair_style dpd/intel command :h3
 pair_style dpd/omp command :h3
 pair_style dpd/tstat command :h3
 pair_style dpd/tstat/gpu command :h3

doc/src/pair_eam.txt

@@ -294,7 +294,7 @@ distribution have a ".cdeam" suffix.
 
 Style {eam/fs} computes pairwise interactions for metals and metal
 alloys using a generalized form of EAM potentials due to Finnis and
-Sinclair "(Finnis)"_#Finnis.  The total energy Ei of an atom I is
+Sinclair "(Finnis)"_#Finnis1.  The total energy Ei of an atom I is
 given by
 
 :c,image(Eqs/pair_eam_fs.jpg)
@@ -442,7 +442,7 @@ of Physics: Condensed Matter, 16, S2629 (2004).
 [(Daw)] Daw, Baskes, Phys Rev Lett, 50, 1285 (1983).
 Daw, Baskes, Phys Rev B, 29, 6443 (1984).
 
-:link(Finnis)
+:link(Finnis1)
 [(Finnis)] Finnis, Sinclair, Philosophical Magazine A, 50, 45 (1984).
 
 :link(Stukowski)

doc/src/pair_extep.txt

@@ -0,0 +1,40 @@
+"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 extep command :h3
+
+[Syntax:]
+
+pair_style extep :pre
+
+[Examples:]
+
+pair_style extep
+pair_coeff * * BN.extep B N :pre
+
+[Description:]
+
+Style {extep} computes the Extended Tersoff Potential (ExTeP)
+interactions as described in "(Los2017)"_#Los2017.
+
+:line
+
+[Restrictions:] none
+
+[Related commands:]
+
+"pair_tersoff" pair_tersoff.html
+
+[Default:] none
+
+:line
+
+:link(Los2017)
+[(Los2017)] J. H. Los et al. "Extended Tersoff potential for boron nitride: 
+Energetics and elastic properties of pristine and defective h-BN", 
+Phys. Rev. B 96 (184108), 2017.

doc/src/pair_smd_hertz.txt

@@ -28,7 +28,7 @@ The parameter <contact_stiffness> has units of pressure and should equal roughly
 of the Young's modulus (or bulk modulus in the case of fluids) of the material model associated with the SPH particles.
 
 The parameter {scale_factor} can be used to scale the particles' contact radii. This can be useful to control how close
-particles can approach each other. Usually, {scale_factor}=1.0.
+particles can approach each other. Usually, {scale_factor} =1.0.
 
 :line
 

doc/src/pair_smd_triangulated_surface.txt

@@ -29,7 +29,7 @@ The parameter <contact_stiffness> has units of pressure and should equal roughly
 of the Young's modulus (or bulk modulus in the case of fluids) of the material model associated with the SPH particle
 
 The parameter {scale_factor} can be used to scale the particles' contact radii. This can be useful to control how close
-particles can approach the triangulated surface. Usually, {scale_factor}=1.0.
+particles can approach the triangulated surface. Usually, {scale_factor} =1.0.
 
 :line
 

doc/src/pair_smd_ulsph.txt

@@ -12,8 +12,8 @@ pair_style smd/ulsph command :h3
 
 pair_style smd/ulsph args :pre
 
-these keywords must be given :l
+these keywords must be given :ul
-keyword = {*DENSITY_SUMMATION} or {*DENSITY_CONTINUITY} and {*VELOCITY_GRADIENT} or {*NO_VELOCITY_GRADIENT} and {*GRADIENT_CORRECTION} or {*NO_GRADIENT_CORRECTION}
+keyword = {*DENSITY_SUMMATION} or {*DENSITY_CONTINUITY} and {*VELOCITY_GRADIENT} or {*NO_VELOCITY_GRADIENT} and {*GRADIENT_CORRECTION} or {*NO_GRADIENT_CORRECTION} :pre
 
 [Examples:]
 

doc/src/pair_snap.txt

@@ -7,6 +7,7 @@
 :line
 
 pair_style snap command :h3
+pair_style snap/kk command :h3
 
 [Syntax:]
 
@@ -171,6 +172,29 @@ This pair style can only be used via the {pair} keyword of the
 
 :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 style is part of the SNAP package.  It is only enabled if

doc/src/pair_ufm.txt

@@ -0,0 +1,135 @@
+"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 ufm command :h3
+pair_style ufm/gpu command :h3
+pair_style ufm/omp command :h3
+pair_style ufm/opt command :h3
+
+[Syntax:]
+
+pair_style ufm cutoff :pre
+
+cutoff = global cutoff for {ufm} interactions (distance units) :ul
+
+[Examples:]
+
+pair_style ufm 4.0
+pair_coeff 1 1 100.0 1.0 2.5
+pair_coeff * * 100.0 1.0 :pre
+
+
+pair_style ufm 4.0
+pair_coeff * * 10.0 1.0
+variable prefactor equal ramp(10,100)
+fix 1 all adapt 1 pair ufm epsilon * * v_prefactor :pre
+
+[Description:]
+
+Style {ufm} computes pairwise interactions using the Uhlenbeck-Ford model (UFM) potential "(Paula Leite2016)"_#PL2 which is given by
+
+:c,image(Eqs/pair_ufm.jpg)
+
+where rc is the cutoff, sigma is a distance-scale and epsilon is an energy-scale, i.e., a product of Boltzmann constant kB, temperature T and the Uhlenbeck-Ford p-parameter which is responsible
+to control the softness of the interactions "(Paula Leite2017)"_#PL1.
+This model is useful as a reference system for fluid-phase free-energy calculations "(Paula Leite2016)"_#PL2. 
+
+The following coefficients must be defined for each pair of atom types
+via the "pair_coeff"_pair_coeff.html command as in the examples above,
+or in the data file or restart files read by the
+"read_data"_read_data.html or "read_restart"_read_restart.html
+commands, or by mixing as described below:
+
+epsilon (energy units)
+sigma (distance units)
+cutoff (distance units) :ul
+
+The last coefficient is optional.  If not specified, the global {ufm}
+cutoff is used.
+
+
+The "fix adapt"_fix_adapt.html command can be used to vary epsilon and sigma for this pair style over the course of a simulation, in which case
+pair_coeff settings for epsilon and sigma must still be specified, but will be
+overridden.  For example these commands will vary the prefactor epsilon for
+all pairwise interactions from 10.0 at the beginning to 100.0 at the end
+of a run:
+
+variable prefactor equal ramp(10,100)
+fix 1 all adapt 1 pair ufm epsilon * * v_prefactor :pre
+
+NOTE: The thermodynamic integration procedure can be performed with this potential using "fix adapt"_fix_adapt.html. This command will rescale the force on each atom by varying a scale variable, which always starts with value 1.0. The syntax is the same described above, however, changing epsilon to scale. A detailed explanation of how to use this command and perform nonequilibrium thermodynamic integration in LAMMPS is given in the paper by "(Freitas)"_#Freitas2.
+
+: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
+
+[Mixing, shift, table, tail correction, restart, rRESPA info]:
+
+For atom type pairs I,J and I != J, the A coefficient and cutoff
+distance for this pair style can be mixed.  A is always mixed via a
+{geometric} rule.  The cutoff is mixed according to the pair_modify
+mix value.  The default mix value is {geometric}.  See the
+"pair_modify" command for details.
+
+This pair style support the "pair_modify"_pair_modify.html shift option for the energy of the pair interaction.
+
+The "pair_modify"_pair_modify.html table and tail are not relevant for this
+pair style.
+
+This pair style does not support the "pair_modify"_pair_modify.html tail option for adding long-range tail corrections to energy and pressure.
+
+This pair style writes its 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.
+
+This pair style can only be used via the {pair} keyword of the
+"run_style respa"_run_style.html command.  It does not support the
+{inner}, {middle}, {outer} keywords.
+
+:line
+
+[Restrictions:] none
+
+[Related commands:]
+
+"pair_coeff"_pair_coeff.html, "fix adapt"_fix_adapt.html
+
+[Default:] none
+
+
+:link(PL1)
+[(Paula Leite2017)] Paula Leite, Santos-Florez, and de Koning, Phys Rev E, 96,
+32115 (2017).
+
+:link(PL2)
+[(Paula Leite2016)] Paula Leite , Freitas, Azevedo, and de Koning, J Chem Phys, 126,
+044509 (2016).
+
+:link(Freitas2)
+[(Freitas)] Freitas, Asta, and de Koning, Computational Materials Science, 112, 333 (2016).

doc/src/pair_yukawa.txt

@@ -9,6 +9,7 @@
 pair_style yukawa command :h3
 pair_style yukawa/gpu command :h3
 pair_style yukawa/omp command :h3
+pair_style yukawa/kk command :h3
 
 [Syntax:]
 

doc/src/pair_zbl.txt

@@ -8,6 +8,7 @@
 
 pair_style zbl command :h3
 pair_style zbl/gpu command :h3
+pair_style zbl/kk command :h3
 pair_style zbl/omp command :h3
 
 [Syntax:]

doc/src/pairs.txt

@@ -11,11 +11,13 @@ Pair Styles :h1
    pair_awpmd
    pair_beck
    pair_body
+   pair_body_rounded_polygon
    pair_bop
    pair_born
    pair_brownian
    pair_buck
    pair_buck_long
+   pair_buck6d_coul_gauss
    pair_charmm
    pair_class2
    pair_colloid
@@ -32,6 +34,7 @@ Pair Styles :h1
    pair_eff
    pair_eim
    pair_exp6_rx
+   pair_extep
    pair_gauss
    pair_gayberne
    pair_gran
@@ -100,6 +103,7 @@ Pair Styles :h1
    pair_tersoff_zbl
    pair_thole
    pair_tri_lj
+   pair_ufm
    pair_vashishta
    pair_yukawa
    pair_yukawa_colloid

doc/src/print.txt

@@ -14,10 +14,11 @@ print string keyword value :pre
 
 string = text string to print, which may contain variables :ulb,l
 zero or more keyword/value pairs may be appended :l
-keyword = {file} or {append} or {screen} :l
+keyword = {file} or {append} or {screen} or {universe} :l
   {file} value = filename
   {append} value = filename
-  {screen} value = {yes} or {no} :pre
+  {screen} value = {yes} or {no}
+  {universe} value = {yes} or {no} :pre
 :ule
 
 [Examples:]
@@ -26,6 +27,7 @@ print "Done with equilibration" file info.dat
 print Vol=$v append info.dat screen no
 print "The system volume is now $v"
 print 'The system volume is now $v'
+print "NEB calculation 1 complete" screen no universe yes
 print """
 System volume = $v
 System temperature = $t
@@ -49,6 +51,11 @@ it does not exist.
 If the {screen} keyword is used, output to the screen and logfile can
 be turned on or off as desired.
 
+If the {universe} keyword is used, output to the global screen and
+logfile can be turned on or off as desired. In multi-partition
+calculations, the {screen} option and the corresponding output only
+apply to the screen and logfile of the individual partition.
+
 If you want the print command to be executed multiple times (with
 changing variable values), there are 3 options.  First, consider using
 the "fix print"_fix_print.html command, which will print a string
@@ -74,4 +81,4 @@ thermodynamic properties, global values calculated by a
 
 [Default:]
 
-The option defaults are no file output and screen = yes.
+The option defaults are no file output, screen = yes, and universe = no.

doc/src/python.txt

@@ -406,7 +406,7 @@ cases, LAMMPS has no simple way to check that something illogical is
 being attempted.
 
 The same applies to Python functions called during a simulation run at
-each time step using "fix python"_fix_python.html.
+each time step using "fix python/invoke"_fix_python_invoke.html.
 
 :line
 
@@ -493,6 +493,6 @@ different source files, problems may occur.
 
 [Related commands:]
 
-"shell"_shell.html, "variable"_variable.html, "fix python"_fix_python.html
+"shell"_shell.html, "variable"_variable.html, "fix python/invoke"_fix_python_invoke.html
 
 [Default:] none

doc/src/replicate.txt

@@ -10,9 +10,11 @@ replicate command :h3
 
 [Syntax:]
 
-replicate nx ny nz :pre
+replicate nx ny nz {keyword} :pre
 
-nx,ny,nz = replication factors in each dimension :ul
+nx,ny,nz = replication factors in each dimension :ulb
+optional {keyword} = {bbox} :l
+  {bbox} = only check atoms in replicas that overlap with a processor's subdomain :ule
 
 [Examples:]
 
@@ -43,6 +45,12 @@ file that crosses a periodic boundary should be between two atoms with
 image flags that differ by 1.  This will allow the bond to be
 unwrapped appropriately.
 
+The optional keyword {bbox} uses a bounding box to only check atoms
+in replicas that overlap with a processor's subdomain when assigning
+atoms to processors, and thus can result in substantial speedups for
+calculations using a large number of processors. It does require
+temporarily using more memory.
+
 [Restrictions:]
 
 A 2d simulation cannot be replicated in the z dimension.

doc/utils/converters/lammpsdoc/txt2rst.py

@@ -67,7 +67,8 @@ class RSTMarkup(Markup):
         text = text.replace('*', '\\*')
         text = text.replace('^', '\\^')
         text = text.replace('|', '\\|')
-        text = re.sub(r'([^"])_', r'\1\\_', text)
+        text = re.sub(r'([^"])_([ \t\n\r\f])', r'\1\\\\_\2', text)
+        text = re.sub(r'([^"])_([^ \t\n\r\f])', r'\1\\_\2', text)
         return text
 
     def unescape_rst_chars(self, text):
@@ -148,15 +149,18 @@ class RSTFormatting(Formatting):
         return "\n----------\n\n" + content.strip()
 
     def image(self, content, file, link=None):
-        if link and (link.lower().endswith('.jpg') or
+        # 2017-12-07: commented out to disable thumbnail processing due to dropping
-                         link.lower().endswith('.jpeg') or
+        #             support for obsolete sphinxcontrib.images extension
-                         link.lower().endswith('.png') or
+        #
-                         link.lower().endswith('.gif')):
+        #if link and (link.lower().endswith('.jpg') or
-            converted = ".. thumbnail:: " + self.markup.unescape_rst_chars(link) + "\n"
+        #                 link.lower().endswith('.jpeg') or
-        else:
+        #                 link.lower().endswith('.png') or
-            converted = ".. image:: " + self.markup.unescape_rst_chars(file) + "\n"
+        #                 link.lower().endswith('.gif')):
-            if link:
+        #    converted = ".. thumbnail:: " + self.markup.unescape_rst_chars(link) + "\n"
-                converted += "   :target: " + self.markup.unescape_rst_chars(link) + "\n"
+        #else:
+        converted = ".. image:: " + self.markup.unescape_rst_chars(file) + "\n"
+        if link:
+            converted += "   :target: " + self.markup.unescape_rst_chars(link) + "\n"
 
         if "c" in self.current_command_list:
             converted += "   :align: center\n"

doc/utils/sphinx-config/conf.py

@@ -31,8 +31,11 @@ import os
 # ones.
 extensions = [
     'sphinx.ext.mathjax',
-    'sphinxcontrib.images',
 ]
+# 2017-12-07: commented out, since this package is broken with Sphinx 16.x
+#             yet we can no longer use Sphinx 15.x, since that breaks with
+#             newer version of the multiprocessor module.
+#    'sphinxcontrib.images',
 
 images_config = {
   'default_image_width' : '25%',

examples/COUPLE/simple/README

@@ -17,33 +17,36 @@ additional wrapper library that interfaces the C interface of the
 LAMMPS library to Fortran and also translates the MPI communicator
 from Fortran to C.
 
-Once you have built LAMMPS as a library (see examples/COUPLE/README),
+First build LAMMPS as a library (see examples/COUPLE/README), e.g. 
-you can then build any of the driver codes with compile lines like
-these, which include paths to the LAMMPS library interface, MPI (an
-installed MPICH in this case), and FFTW (assuming you built LAMMPS as
-a library with its PPPM solver).
 
-This builds the C++ driver with the LAMMPS library using a C++ compiler:
+make mode=shlib mpi
 
-g++ -I/home/sjplimp/lammps/src -c simple.cpp
+You can then build any of the driver codes with compile lines like
-g++ -L/home/sjplimp/lammps/src simple.o \
+these, which include paths to the LAMMPS library interface, and
-    -llammps -lfftw -lmpich -lmpl -lpthread -o simpleCC
+linking with FFTW (only needed if you built LAMMPS as a library with
+its PPPM solver).
 
-This builds the C driver with the LAMMPS library using a C compiler:
+This builds the C++ driver with the LAMMPS library using the mpiCC
+(C++) compiler:
 
-gcc -I/home/sjplimp/lammps/src -c simple.c
+mpiCC -I/home/sjplimp/lammps/src -c simple.cpp
-gcc -L/home/sjplimp/lammps/src simple.o \
+mpiCC -L/home/sjplimp/lammps/src simple.o -llammps -lfftw -o simpleCC
-    -llammps -lfftw -lmpich -lmpl -lpthread -lstdc++ -o simpleC
+
+This builds the C driver with the LAMMPS library using the mpicc (C)
+compiler:
+
+mpicc -I/home/sjplimp/lammps/src -c simple.c
+mpicc -L/home/sjplimp/lammps/src simple.o -llammps -lfftw -o simpleC
 
 This builds the Fortran wrapper and driver with the LAMMPS library
-using a Fortran and C compiler, using the wrapper in the fortran
+using the mpicc (C) and mpifort (Fortran) compilers, using the wrapper
-directory:
+in the fortran directory:
 
 cp ../fortran/libfwrapper.c .
-gcc -I/home/sjplimp/lammps/src -c libfwrapper.c
+mpicc -I/home/sjplimp/lammps/src -c libfwrapper.c
-gfortran -I/home/sjplimp/lammps/src -c simple.f90
+mpifort -c simple.f90
-gfortran -L/home/sjplimp/lammps/src simple.o libfwrapper.o \
+mpifort -L/home/sjplimp/lammps/src simple.o libfwrapper.o \
-    -llammps -lfftw -lfmpich -lmpich -lpthread -lstdc++ -o simpleF
+    -llammps -lfftw -o simpleF
 
 You then run simpleCC, simpleC, or simpleF on a parallel machine
 on some number of processors Q with 2 arguments:

examples/COUPLE/simple/simple.c

@@ -145,7 +145,7 @@ int main(int narg, char **arg)
     for (i = 0; i < natoms; i++) type[i] = 1;
 
     lammps_command(lmp,"delete_atoms group all");
-    lammps_create_atoms(lmp,natoms,NULL,type,x,v);
+    lammps_create_atoms(lmp,natoms,NULL,type,x,v,NULL,0);
     lammps_command(lmp,"run 10");
   }
 

examples/COUPLE/simple/simple.cpp

@@ -109,11 +109,11 @@ int main(int narg, char **arg)
     int natoms = static_cast<int> (lmp->atom->natoms);
     x = new double[3*natoms];
     v = new double[3*natoms];
-    lammps_gather_atoms(lmp,"x",1,3,x);
+    lammps_gather_atoms(lmp,(char *) "x",1,3,x);
-    lammps_gather_atoms(lmp,"v",1,3,v);
+    lammps_gather_atoms(lmp,(char *) "v",1,3,v);
     double epsilon = 0.1;
     x[0] += epsilon;
-    lammps_scatter_atoms(lmp,"x",1,3,x);
+    lammps_scatter_atoms(lmp,(char *) "x",1,3,x);
 
     // these 2 lines are the same
 
@@ -124,21 +124,22 @@ int main(int narg, char **arg)
   // extract force on single atom two different ways
 
   if (lammps == 1) {
-    double **f = (double **) lammps_extract_atom(lmp,"f");
+    double **f = (double **) lammps_extract_atom(lmp,(char *) "f");
     printf("Force on 1 atom via extract_atom: %g\n",f[0][0]);
 
-    double *fx = (double *) lammps_extract_variable(lmp,"fx","all");
+    double *fx = (double *) 
+      lammps_extract_variable(lmp,(char *) "fx",(char *) "all");
     printf("Force on 1 atom via extract_variable: %g\n",fx[0]);
   }
 
   // use commands_string() and commands_list() to invoke more commands
 
-  char *strtwo = "run 10\nrun 20";
+  char *strtwo = (char *) "run 10\nrun 20";
   if (lammps == 1) lammps_commands_string(lmp,strtwo);
 
   char *cmds[2];
-  cmds[0] = "run 10";
+  cmds[0] = (char *) "run 10";
-  cmds[1] = "run 20";
+  cmds[1] = (char *) "run 20";
   if (lammps == 1) lammps_commands_list(lmp,2,cmds);
 
   // delete all atoms