patch 20Jun17

Merge pull request #537 from lammps/neb
minor changes to NEB doc pages and examples
2017-06-20 12:06:02 -06:00 · 2017-06-20 09:38:32 -06:00 · 2017-06-20 10:36:30 -04:00 · 2017-06-20 08:19:23 -06:00 · 2017-06-20 07:44:40 -06:00 · 2017-06-20 07:44:17 -06:00
1373 changed files with 131042 additions and 41958 deletions
--- a/doc/Makefile
+++ b/doc/Makefile
@ -100,6 +100,7 @@ epub: $(OBJECTS)
 pdf: utils/txt2html/txt2html.exe
 	@(\
 		set -e; \
 		cd src; \
 		../utils/txt2html/txt2html.exe -b *.txt; \
 		htmldoc --batch lammps.book;          \
@ -158,7 +159,7 @@ $(VENV):
 	@( \
 		virtualenv -p $(PYTHON) $(VENV); \
 		. $(VENV)/bin/activate; \
-		pip install Sphinx; \
+		pip install Sphinx==1.5.6; \
 		pip install sphinxcontrib-images; \
 		deactivate;\
 	)
--- a/doc/src/Eqs/cnp_cutoff.jpg
+++ b/doc/src/Eqs/cnp_cutoff.jpg
--- a/doc/src/Eqs/cnp_cutoff.tex
+++ b/doc/src/Eqs/cnp_cutoff.tex
@ -0,0 +1,14 @@
 \documentclass[12pt,article]{article}
 \usepackage{indentfirst}
 \usepackage{amsmath}
 \begin{document}
 \begin{eqnarray*}
  r_{c}^{fcc} & = & \frac{1}{2} \left(\frac{\sqrt{2}}{2} + 1\right) \mathrm{a} \simeq 0.8536 \:\mathrm{a} \\
  r_{c}^{bcc} & = & \frac{1}{2}(\sqrt{2} + 1) \mathrm{a} \simeq 1.207 \:\mathrm{a} \\
  r_{c}^{hcp} & = & \frac{1}{2}\left(1+\sqrt{\frac{4+2x^{2}}{3}}\right) \mathrm{a}
 \end{eqnarray*}
 \end{document}
--- a/doc/src/Eqs/cnp_cutoff2.jpg
+++ b/doc/src/Eqs/cnp_cutoff2.jpg
--- a/doc/src/Eqs/cnp_cutoff2.tex
+++ b/doc/src/Eqs/cnp_cutoff2.tex
@ -0,0 +1,12 @@
 \documentclass[12pt,article]{article}
 \usepackage{indentfirst}
 \usepackage{amsmath}
 \begin{document}
 $$
  Rc + Rs > 2*{\rm cutoff}
 $$
 \end{document}
--- a/doc/src/Eqs/cnp_eq.jpg
+++ b/doc/src/Eqs/cnp_eq.jpg
--- a/doc/src/Eqs/cnp_eq.tex
+++ b/doc/src/Eqs/cnp_eq.tex
@ -0,0 +1,9 @@
 \documentclass[12pt]{article}
 \begin{document}
 $$
   Q_{i} = \frac{1}{n_i}\sum_{j = 1}^{n_i} | \sum_{k = 1}^{n_{ij}}  \vec{R}_{ik} + \vec{R}_{jk} |^2
 $$
 \end{document}
--- a/doc/src/Eqs/pair_lj_sf.jpg
+++ b/doc/src/Eqs/pair_lj_sf.jpg
--- a/doc/src/Eqs/pair_lj_sf.tex
+++ b/doc/src/Eqs/pair_lj_sf.tex
@ -1,11 +0,0 @@
 \documentclass[12pt]{article}
 \begin{document}
 \begin{eqnarray*}
 F & = & F_{\mathrm{LJ}}(r) - F_{\mathrm{LJ}}(r_{\mathrm{c}}) \qquad r < r_{\mathrm{c}} \\
 E & = & E_{\mathrm{LJ}}(r) - E_{\mathrm{LJ}}(r_{\mathrm{c}}) + (r - r_{\mathrm{c}}) F_{\mathrm{LJ}}(r_{\mathrm{c}}) \qquad r < r_{\mathrm{c}} \\
 \mathrm{with} \qquad E_{\mathrm{LJ}}(r) & = & 4 \epsilon \left[ \left(\frac{\sigma}{r}\right)^{12} - \left(\frac{\sigma}{r}\right)^6 \right] \qquad \mathrm{and} \qquad F_{\mathrm{LJ}}(r) = - E^\prime_{\mathrm{LJ}}(r)
 \end{eqnarray*}                           
 \end{document}
--- a/doc/src/Eqs/pair_meam_spline.jpg
+++ b/doc/src/Eqs/pair_meam_spline.jpg
--- a/doc/src/Eqs/pair_meam_spline.tex
+++ b/doc/src/Eqs/pair_meam_spline.tex
@ -1,13 +1,14 @@
 \documentclass[12pt]{article}
 \usepackage{amsmath}
 \begin{document}
 $$
-   E=\sum_{ij}\phi(r_{ij})+\sum_{i}U(\rho_{i}),
+   E=\sum_{i<j}\phi(r_{ij})+\sum_{i}U(n_{i}),
 $$
 $$
-   \rho_{i}=\sum_{j}\rho(r_{ij})+\sum_{jk}f(r_{ij})f(r_{ik})g[\cos(\theta_{jik})]
+   n_{i}=\sum_{j}\rho(r_{ij})+\sum_{\substack{j<k,\\j,k\neq i}}f(r_{ij})f(r_{ik})g[\cos(\theta_{jik})]
 $$
 \end{document}
--- a/doc/src/Eqs/pair_meam_spline_multicomponent.jpg
+++ b/doc/src/Eqs/pair_meam_spline_multicomponent.jpg
--- a/doc/src/Eqs/pair_meam_spline_multicomponent.tex
+++ b/doc/src/Eqs/pair_meam_spline_multicomponent.tex
@ -0,0 +1,14 @@
 \documentclass[12pt]{article}
 \usepackage{amsmath}
 \begin{document}
 $$
   E=\sum_{i<j}\phi_{ij}(r_{ij})+\sum_{i}U_i(n_{i}),
 $$
 $$
   n_{i}=\sum_{j\ne i}\rho_j(r_{ij})+\sum_{\substack{j<k,\\j,k\neq i}}f_{j}(r_{ij})f_{k}(r_{ik})g_{jk}[\cos(\theta_{jik})]
 $$
 \end{document}
--- a/doc/src/JPG/user_intel.png
+++ b/doc/src/JPG/user_intel.png
--- a/doc/src/Manual.txt
+++ b/doc/src/Manual.txt
@ -1,7 +1,7 @@
 <!-- HTML_ONLY -->
 <HEAD>
 <TITLE>LAMMPS Users Manual</TITLE>
-<META NAME="docnumber" CONTENT="11 Apr 2017 version">
+<META NAME="docnumber" CONTENT="20 Jun 2017 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
-11 Apr 2017 version :c,h4
+20 Jun 2017 version :c,h4
 Version info: :h4
@ -158,12 +158,11 @@ END_RST -->
  2.1 "What's in the LAMMPS distribution"_start_1 :ulb,b
  2.2 "Making LAMMPS"_start_2 :b
  2.3 "Making LAMMPS with optional packages"_start_3 :b
-  2.4 "Building LAMMPS via the Make.py script"_start_4 :b
+  2.4 "Building LAMMPS as a library"_start_4 :b
-  2.5 "Building LAMMPS as a library"_start_5 :b
+  2.5 "Running LAMMPS"_start_5 :b
-  2.6 "Running LAMMPS"_start_6 :b
+  2.6 "Command-line options"_start_6 :b
-  2.7 "Command-line options"_start_7 :b
+  2.7 "Screen output"_start_7 :b
-  2.8 "Screen output"_start_8 :b
+  2.8 "Tips for users of previous versions"_start_8 :ule,b
  2.9 "Tips for users of previous versions"_start_9 :ule,b
 "Commands"_Section_commands.html :l
  3.1 "LAMMPS input script"_cmd_1 :ulb,b
  3.2 "Parsing rules"_cmd_2 :b
--- a/doc/src/Section_commands.txt
+++ b/doc/src/Section_commands.txt
@ -527,9 +527,9 @@ These are additional commands in USER packages, which can be used if
 "LAMMPS is built with the appropriate
 package"_Section_start.html#start_3.
-"dump custom/vtk"_dump_custom_vtk.html,
+"dump netcdf"_dump_netcdf.html,
-"dump nc"_dump_nc.html,
+"dump netcdf/mpiio"_dump_netcdf.html,
-"dump nc/mpiio"_dump_nc.html,
+"dump vtk"_dump_vtk.html,
 "group2ndx"_group2ndx.html,
 "ndx2group"_group2ndx.html,
 "temper/grem"_temper_grem.html :tb(c=3,ea=c)
@ -618,6 +618,7 @@ USER-INTEL, k = KOKKOS, o = USER-OMP, t = OPT.
 "press/berendsen"_fix_press_berendsen.html,
 "print"_fix_print.html,
 "property/atom"_fix_property_atom.html,
 "python"_fix_python.html,
 "qeq/comb (o)"_fix_qeq_comb.html,
 "qeq/dynamic"_fix_qeq.html,
 "qeq/fire"_fix_qeq.html,
@ -716,7 +717,7 @@ package"_Section_start.html#start_3.
 "phonon"_fix_phonon.html,
 "pimd"_fix_pimd.html,
 "qbmsst"_fix_qbmsst.html,
-"qeq/reax"_fix_qeq_reax.html,
+"qeq/reax (ko)"_fix_qeq_reax.html,
 "qmmm"_fix_qmmm.html,
 "qtb"_fix_qtb.html,
 "reax/c/bonds"_fix_reax_bonds.html,
@ -830,6 +831,7 @@ package"_Section_start.html#start_3.
 "ackland/atom"_compute_ackland_atom.html,
 "basal/atom"_compute_basal_atom.html,
 "cnp/atom"_compute_cnp_atom.html,
 "dpd"_compute_dpd.html,
 "dpd/atom"_compute_dpd_atom.html,
 "fep"_compute_fep.html,
@ -931,6 +933,8 @@ KOKKOS, o = USER-OMP, t = OPT.
 "gran/hertz/history (o)"_pair_gran.html,
 "gran/hooke (o)"_pair_gran.html,
 "gran/hooke/history (o)"_pair_gran.html,
 "gw"_pair_gw.html,
 "gw/zbl"_pair_gw.html,
 "hbond/dreiding/lj (o)"_pair_hbond_dreiding.html,
 "hbond/dreiding/morse (o)"_pair_hbond_dreiding.html,
 "kim"_pair_kim.html,
@ -960,7 +964,7 @@ KOKKOS, o = USER-OMP, t = OPT.
 "lj/expand (gko)"_pair_lj_expand.html,
 "lj/gromacs (gko)"_pair_gromacs.html,
 "lj/gromacs/coul/gromacs (ko)"_pair_gromacs.html,
-"lj/long/coul/long (o)"_pair_lj_long.html,
+"lj/long/coul/long (io)"_pair_lj_long.html,
 "lj/long/dipole/long"_pair_dipole.html,
 "lj/long/tip4p/long"_pair_lj_long.html,
 "lj/smooth (o)"_pair_lj_smooth.html,
@ -982,6 +986,7 @@ KOKKOS, o = USER-OMP, t = OPT.
 "peri/pmb (o)"_pair_peri.html,
 "peri/ves"_pair_peri.html,
 "polymorphic"_pair_polymorphic.html,
 "python"_pair_python.html,
 "reax"_pair_reax.html,
 "rebo (o)"_pair_airebo.html,
 "resquared (go)"_pair_resquared.html,
@ -1016,6 +1021,7 @@ package"_Section_start.html#start_3.
 "dpd/fdt/energy"_pair_dpd_fdt.html,
 "eam/cd (o)"_pair_eam.html,
 "edip (o)"_pair_edip.html,
 "edip/multi"_pair_edip.html,
 "eff/cut"_pair_eff.html,
 "exp6/rx"_pair_exp6_rx.html,
 "gauss/cut"_pair_gauss.html,
@ -1033,7 +1039,6 @@ package"_Section_start.html#start_3.
 "lj/sdk (gko)"_pair_sdk.html,
 "lj/sdk/coul/long (go)"_pair_sdk.html,
 "lj/sdk/coul/msm (o)"_pair_sdk.html,
 "lj/sf (o)"_pair_lj_sf.html,
 "meam/spline (o)"_pair_meam_spline.html,
 "meam/sw/spline"_pair_meam_sw_spline.html,
 "mgpt"_pair_mgpt.html,
@ -1052,7 +1057,7 @@ package"_Section_start.html#start_3.
 "oxdna2/excv"_pair_oxdna2.html,
 "oxdna2/stk"_pair_oxdna2.html,
 "quip"_pair_quip.html,
-"reax/c (k)"_pair_reax_c.html,
+"reax/c (ko)"_pair_reaxc.html,
 "smd/hertz"_pair_smd_hertz.html,
 "smd/tlsph"_pair_smd_tlsph.html,
 "smd/triangulated/surface"_pair_smd_triangulated_surface.html,
@ -1220,7 +1225,7 @@ USER-OMP, t = OPT.
 "msm/cg (o)"_kspace_style.html,
 "pppm (go)"_kspace_style.html,
 "pppm/cg (o)"_kspace_style.html,
-"pppm/disp"_kspace_style.html,
+"pppm/disp (i)"_kspace_style.html,
 "pppm/disp/tip4p"_kspace_style.html,
 "pppm/stagger"_kspace_style.html,
 "pppm/tip4p (o)"_kspace_style.html :tb(c=4,ea=c)
--- a/doc/src/Section_errors.txt
+++ b/doc/src/Section_errors.txt
@ -8890,6 +8890,14 @@ This is a requirement to use this potential. :dd
 See the newton command.  This is a restriction to use this potential. :dd
 {Pair style vashishta/gpu requires atom IDs} :dt
 This is a requirement to use this potential. :dd
 {Pair style vashishta/gpu requires newton pair off} :dt
 See the newton command.  This is a restriction to use this potential. :dd
 {Pair style tersoff/gpu requires atom IDs} :dt
 This is a requirement to use the tersoff/gpu potential. :dd
@ -11171,6 +11179,12 @@ Self-explanatory. :dd
 If the fix changes the timestep, the dump dcd file will not
 reflect the change. :dd
 {Energy due to X extra global DOFs will be included in minimizer energies} :dt
 When using fixes like box/relax, the potential energy used by the minimizer
 is augmented by an additional energy provided by the fix. Thus the printed
 converged energy may be different from the total potential energy. :dd
 {Energy tally does not account for 'zero yes'} :dt
 The energy removed by using the 'zero yes' flag is not accounted
--- a/doc/src/Section_intro.txt
+++ b/doc/src/Section_intro.txt
@ -249,8 +249,12 @@ Pizza.py WWW site"_pizza. :l
 Specialized features :h5
-These are LAMMPS capabilities which you may not think of as typical
+LAMMPS can be built with optional packages which implement a variety
-molecular dynamics options:
+of additional capabilities.  An overview of all the packages is "given
 here"_Section_packages.html.
 These are some LAMMPS capabilities which you may not think of as
 typical classical molecular dynamics options:
 "static"_balance.html and "dynamic load-balancing"_fix_balance.html
 "generalized aspherical particles"_body.html
@ -515,7 +519,7 @@ the packages they have written are somewhat unique to LAMMPS and the
 code would not be as general-purpose as it is without their expertise
 and efforts.
-Axel Kohlmeyer (Temple U), akohlmey at gmail.com, SVN and Git repositories, indefatigable mail list responder, USER-CG-CMM and USER-OMP packages
+Axel Kohlmeyer (Temple U), akohlmey at gmail.com, SVN and Git repositories, indefatigable mail list responder, USER-CGSDK and USER-OMP packages
 Roy Pollock (LLNL), Ewald and PPPM solvers
 Mike Brown (ORNL), brownw at ornl.gov, GPU package
 Greg Wagner (Sandia), gjwagne at sandia.gov, MEAM package for MEAM potential
--- a/doc/src/Section_packages.txt
+++ b/doc/src/Section_packages.txt
--- a/doc/src/Section_python.txt
+++ b/doc/src/Section_python.txt
@ -118,18 +118,21 @@ check which version of Python you have installed, by simply typing
 11.2 Overview of using Python from a LAMMPS script :link(py_2),h4
-NOTE: It is not currently possible to use the "python"_python.html
+LAMMPS has several commands which can be used to invoke Python
-command described in this section with Python 3, only with Python 2.
+code directly from an input script:
 The C API changed from Python 2 to 3 and the LAMMPS code is not
 compatible with both.
-LAMMPS has a "python"_python.html command which can be used in an
+"python"_python.html
-input script to define and execute a Python function that you write
+"variable python"_variable.html
-the code for.  The Python function can also be assigned to a LAMMPS
+"fix python"_fix_python.html
-python-style variable via the "variable"_variable.html command.  Each
+"pair_style python"_pair_python.html :ul
-time the variable is evaluated, either in the LAMMPS input script
+
-itself, or by another LAMMPS command that uses the variable, this will
+The "python"_python.html command which can be used to define and
-trigger the Python function to be invoked.
+execute a Python function that you write the code for.  The Python
 function can also be assigned to a LAMMPS python-style variable via
 the "variable"_variable.html command.  Each time the variable is
 evaluated, either in the LAMMPS input script itself, or by another
 LAMMPS command that uses the variable, this will trigger the Python
 function to be invoked.
 The Python code for the function can be included directly in the input
 script or in an auxiliary file.  The function can have arguments which
@ -162,8 +165,16 @@ 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.
-To run pure Python code from LAMMPS, you only need to build LAMMPS
+The "fix python"_fix_python.html command can execute
-with the PYTHON package installed:
+Python code at selected timesteps during a simulation run.
 The "pair_style python"_pair_python command allows you to define
 pairwise potentials as python code which encodes a single pairwise
 interaction.  This is useful for rapid-developement and debugging of a
 new potential.
 To use any of these commands, you only need to build LAMMPS with the
 PYTHON package installed:
 make yes-python
 make machine :pre
--- a/doc/src/Section_start.txt
+++ b/doc/src/Section_start.txt
@ -14,12 +14,11 @@ experienced users.
 2.1 "What's in the LAMMPS distribution"_#start_1
 2.2 "Making LAMMPS"_#start_2
 2.3 "Making LAMMPS with optional packages"_#start_3
-2.4 "Building LAMMPS via the Make.py script"_#start_4
+2.5 "Building LAMMPS as a library"_#start_4
-2.5 "Building LAMMPS as a library"_#start_5
+2.6 "Running LAMMPS"_#start_5
-2.6 "Running LAMMPS"_#start_6
+2.7 "Command-line options"_#start_6
-2.7 "Command-line options"_#start_7
+2.8 "Screen output"_#start_7
-2.8 "Screen output"_#start_8
+2.9 "Tips for users of previous versions"_#start_8 :all(b)
 2.9 "Tips for users of previous versions"_#start_9 :all(b)
 :line
@ -80,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 preceding
+If you want to avoid building LAMMPS yourself, read the preceeding
 section about options available for downloading and installing
 executables.  Details are discussed on the "download"_download page.
@ -96,7 +95,7 @@ make serial :pre
 Note that on a facility supercomputer, there are often "modules"
 loaded in your environment that provide the compilers and MPI you
 should use.  In this case, the "mpicxx" compile/link command in
-Makefile.mpi should just work by accessing those modules.
+Makefile.mpi should simply work by accessing those modules.
 It may be the case that one of the other Makefile.machine files in the
 src/MAKE sub-directories is a better match to your system (type "make"
@ -107,33 +106,35 @@ make stampede :pre
 If any of these builds (with an existing Makefile.machine) works on
 your system, then you're done!
 If you need to install an optional package with a LAMMPS command you
 want to use, and the package does not depend on an extra library, you
 can simply type
 make name :pre
 before invoking (or re-invoking) the above steps.  "Name" is the
 lower-case name of the package, e.g. replica or user-misc.
 If you want to do one of the following:
-use optional LAMMPS features that require additional libraries
+use a LAMMPS command that requires an extra library (e.g. "dump image"_dump_image.html)
-use optional packages that require additional libraries
+build with a package that requires an extra library
-use optional accelerator packages that require special compiler/linker settings
+build with an accelerator package that requires special compiler/linker settings
-run on a specialized platform that has its own compilers, settings, or other libs to use :ul
+run on a machine that has its own compilers, settings, or libraries :ul
 then building LAMMPS is more complicated.  You may need to find where
-auxiliary libraries exist on your machine or install them if they
+extra libraries exist on your machine or install them if they don't.
-don't.  You may need to build additional libraries that are part of
+You may need to build extra libraries that are included in the LAMMPS
-the LAMMPS package, before building LAMMPS.  You may need to edit a
+distribution, before building LAMMPS itself.  You may need to edit a
 Makefile.machine file to make it compatible with your system.
 Note that there is a Make.py tool in the src directory that automates
 several of these steps, but you still have to know what you are doing.
 "Section 2.4"_#start_4 below describes the tool.  It is a convenient
 way to work with installing/un-installing various packages, the
 Makefile.machine changes required by some packages, and the auxiliary
 libraries some of them use.
 Please read the following sections carefully.  If you are not
 comfortable with makefiles, or building codes on a Unix platform, or
 running an MPI job on your machine, please find a local expert to help
-you.  Many compilation, linking, and run problems that users have are
+you.  Many compilation, linking, and run problems users experience are
-often not really LAMMPS issues - they are peculiar to the user's
+often not LAMMPS issues - they are peculiar to the user's system,
-system, compilers, libraries, etc.  Such questions are better answered
+compilers, libraries, etc.  Such questions are better answered by a
-by a local expert.
+local expert.
 If you have a build problem that you are convinced is a LAMMPS issue
 (e.g. the compiler complains about a line of LAMMPS source code), then
@ -251,7 +252,7 @@ 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 recognized are:
+within the LAMMPS code.  The options that are currently recogized are:
 -DLAMMPS_GZIP
 -DLAMMPS_JPEG
@ -362,7 +363,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
-environments, you may simply need to include the correct module in
+environements, 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.
@ -430,7 +431,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 environments, you may simply need to include
+for their compile/link environements, 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.
@ -450,12 +451,13 @@ you must also manually specify the correct library, namely -lsfftw or
 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
-calculations, particularly in parallel or on GPUs.  Fourier transform
+calulations, 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
 accuracy for reduced memory use and parallel communication costs for
-transposing 3d FFT data.
+transposing 3d FFT data.  Note that single precision FFTs have only
 been tested with the FFTW3, FFTW2, MKL, and KISS FFT options.
 Step 7 :h6
@ -507,13 +509,13 @@ You should get the executable lmp_foo when the build is complete.
 Errors that can occur when making LAMMPS: h5 :link(start_2_3)
-NOTE: If an error occurs when building LAMMPS, the compiler or linker
+If an error occurs when building LAMMPS, the compiler or linker will
-will state very explicitly what the problem is.  The error message
+state very explicitly what the problem is.  The error message should
-should give you a hint as to which of the steps above has failed, and
+give you a hint as to which of the steps above has failed, and what
-what you need to do in order to fix it.  Building a code with a
+you need to do in order to fix it.  Building a code with a Makefile is
-Makefile is a very logical process.  The compiler and linker need to
+a very logical process.  The compiler and linker need to find the
-find the appropriate files and those files need to be compatible with
+appropriate files and those files need to be compatible with LAMMPS
-LAMMPS source files.  When a make fails, there is usually a very
+settings and source files.  When a make fails, there is usually a very
 simple reason, which you or a local expert will need to fix.
 Here are two non-obvious errors that can occur:
@ -556,7 +558,8 @@ Typing "make clean-all" or "make clean-machine" will delete *.o object
 files created when LAMMPS is built, for either all builds or for a
 particular machine.
-Changing the LAMMPS size limits via -DLAMMPS_SMALLBIG or -DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL :h6
+Changing the LAMMPS size limits via -DLAMMPS_SMALLBIG or
 -DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL :h6
 As explained above, any of these 3 settings can be specified on the
 LMP_INC line in your low-level src/MAKE/Makefile.foo.
@ -652,13 +655,7 @@ This section has the following sub-sections:
 2.3.1 "Package basics"_#start_3_1
 2.3.2 "Including/excluding packages"_#start_3_2
-2.3.3 "Packages that require extra libraries"_#start_3_3
+2.3.3 "Packages that require extra libraries"_#start_3_3 :all(b)
 2.3.4 "Packages that require Makefile.machine settings"_#start_3_4 :all(b)
 Note that the following "Section 2.4"_#start_4 describes the Make.py
 tool which can be used to install/un-install packages and build the
 auxiliary libraries which some of them use.  It can also auto-edit a
 Makefile.machine to add settings needed by some packages.
 :line
@ -669,235 +666,221 @@ are always included, plus optional packages.  Packages are groups of
 files that enable a specific set of features.  For example, force
 fields for molecular systems or granular systems are in packages.
-"Section 4"_Section_packages.html in the manual has details
+"Section 4"_Section_packages.html in the manual has details about all
-about all the packages, including specific instructions for building
+the packages, which come in two flavors: [standard] and [user]
-LAMMPS with each package, which are covered in a more general manner
+packages. It also has specific instructions for building LAMMPS with
 any package which requires an extra library.  General instructions are
 below.
 You can see the list of all packages by typing "make package" from
-within the src directory of the LAMMPS distribution.  This also lists
+within the src directory of the LAMMPS distribution.  It will also
-various make commands that can be used to manipulate packages.
+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 specifies if it is part of a package.  You can
+Every command's doc page specfies if it is part of a package.  You can
-also type
+type
 lmp_machine -h :pre
 to run your executable with the optional "-h command-line
-switch"_#start_7 for "help", which will simply list the styles and
+switch"_#start_7 for "help", which will list the styles and commands
-commands known to your executable, and immediately exit.
+known to your executable, and immediately exit.
 There are two kinds of packages in LAMMPS, standard and user packages.
 More information about the contents of standard and user packages is
 given in "Section 4"_Section_packages.html of the manual.  The
 difference between standard and user packages is as follows:
 Standard packages, such as molecule or kspace, are supported by the
 LAMMPS developers and are written in a syntax and style consistent
 with the rest of LAMMPS.  This means we will answer questions about
 them, debug and fix them if necessary, and keep them compatible with
 future changes to LAMMPS.
 User packages, such as user-atc or user-omp, have been contributed by
 users, and always begin with the user prefix.  If they are a single
 command (single file), they are typically in the user-misc package.
 Otherwise, they are a set of files grouped together which add a
 specific functionality to the code.
 User packages don't necessarily meet the requirements of the standard
 packages.  If you have problems using a feature provided in a user
 package, you may need to contact the contributor directly to get help.
 Information on how to submit additions you make to LAMMPS as single
 files or either a standard or user-contributed package are given in
 "this section"_Section_modify.html#mod_15 of the documentation.
 :line
 Including/excluding packages :h5,link(start_3_2)
-To use (or not use) a package you must include it (or exclude it)
+To use (or not use) a package you must install it (or un-install it)
-before building LAMMPS.  From the src directory, this is typically as
+before building LAMMPS.  From the src directory, this is as simple as:
 simple as:
 make yes-colloid
 make mpi :pre
 or
-make no-manybody
+make no-user-omp
 make mpi :pre
-NOTE: You should NOT include/exclude packages and build LAMMPS in a
+NOTE: You should NOT install/un-install packages and build LAMMPS in a
 single make command using multiple targets, e.g. make yes-colloid mpi.
 This is because the make procedure creates a list of source files that
 will be out-of-date for the build if the package configuration changes
 within the same command.
-Some packages have individual files that depend on other packages
+Any package can be installed or not in a LAMMPS build, independent of
-being included.  LAMMPS checks for this and does the right thing.
+all other packages.  However, some packages include files derived from
-I.e. individual files are only included if their dependencies are
+files in other packages.  LAMMPS checks for this and does the right
-already included.  Likewise, if a package is excluded, other files
+thing.  I.e. individual files are only included if their dependencies
 are already included.  Likewise, if a package is excluded, other files
 dependent on that package are also excluded.
 NOTE: The one exception is that we do not recommend building with both
 the KOKKOS package installed and any of the other acceleration
 packages (GPU, OPT, USER-INTEL, USER-OMP) also installed.  This is
 because of how Kokkos sometimes builds using a wrapper compiler which
 can make it difficult to invoke all the compile/link flags correctly
 for both Kokkos and non-Kokkos files.
 If you will never run simulations that use the features in a
 particular packages, there is no reason to include it in your build.
-For some packages, this will keep you from having to build auxiliary
+For some packages, this will keep you from having to build extra
-libraries (see below), and will also produce a smaller executable
+libraries, and will also produce a smaller executable which may run a
-which may run a bit faster.
+bit faster.
-When you download a LAMMPS tarball, these packages are pre-installed
+When you download a LAMMPS tarball, three packages are pre-installed
-in the src directory: KSPACE, MANYBODY,MOLECULE, because they are so
+in the src directory -- KSPACE, MANYBODY, MOLECULE -- because they are
-commonly used.  When you download LAMMPS source files from the SVN or
+so commonly used.  When you download LAMMPS source files from the SVN
-Git repositories, no packages are pre-installed.
+or Git repositories, no packages are pre-installed.
-Packages are included or excluded by typing "make yes-name" or "make
+Packages are installed or un-installed by typing
 no-name", where "name" is the name of the package in lower-case, e.g.
 name = kspace for the KSPACE package or name = user-atc for the
 USER-ATC package.  You can also type "make yes-standard", "make
 no-standard", "make yes-std", "make no-std", "make yes-user", "make
 no-user", "make yes-lib", "make no-lib", "make yes-all", or "make
 no-all" to include/exclude various sets of packages.  Type "make
 package" to see all of the package-related make options.
-NOTE: Inclusion/exclusion of a package works by simply moving files
+make yes-name
-back and forth between the main src directory and sub-directories with
+make no-name :pre
 the package name (e.g. src/KSPACE, src/USER-ATC), so that the files
 are seen or not seen when LAMMPS is built.  After you have included or
 excluded a package, you must re-build LAMMPS.
-Additional package-related make options exist to help manage LAMMPS
+where "name" is the name of the package in lower-case, e.g.  name =
-files that exist in both the src directory and in package
+kspace for the KSPACE package or name = user-atc for the USER-ATC
-sub-directories.  You do not normally need to use these commands
+package.  You can also type any of these commands:
 unless you are editing LAMMPS files or have downloaded a patch from
 the LAMMPS WWW site.
-Typing "make package-update" or "make pu" will overwrite src files
+make yes-all | install all packages
-with files from the package sub-directories if the package has been
+make no-all | un-install all packages
-included.  It should be used after a patch is installed, since patches
+make yes-standard or make yes-std | install standard packages
-only update the files in the package sub-directory, but not the src
+make no-standard or make no-std| un-install standard packages
-files.  Typing "make package-overwrite" will overwrite files in the
+make yes-user | install user packages
-package sub-directories with src files.
+make no-user | un-install user packages
 make yes-lib | install packages that require extra libraries
 make no-lib | un-install packages that require extra libraries
 make yes-ext | install packages that require external libraries
 make no-ext | un-install packages that require external libraries :tb(s=|)
 which install/un-install various sets of packages.  Typing "make
 package" will list all the these commands.
 NOTE: Installing or un-installing a package works by simply moving
 files back and forth between the main src directory and
 sub-directories with the package name (e.g. src/KSPACE, src/USER-ATC),
 so that the files are included or excluded when LAMMPS is built.
 After you have installed or un-installed a package, you must re-build
 LAMMPS for the action to take effect.
 The following make commands help manage files that exist in both the
 src directory and in package sub-directories.  You do not normally
 need to use these commands unless you are editing LAMMPS files or have
 downloaded a patch from the LAMMPS web site.
 Typing "make package-status" or "make ps" will show which packages are
-currently included. For those that are included, it will list any
+currently installed. For those that are installed, it will list any
 files that are different in the src directory and package
-sub-directory.  Typing "make package-diff" lists all differences
+sub-directory.
-between these files.  Again, type "make package" to see all of the
+
-package-related make options.
+Typing "make package-update" or "make pu" will overwrite src files
 with files from the package sub-directories if the package is
 installed.  It should be used after a patch has been applied, since
 patches only update the files in the package sub-directory, but not
 the src files.
 Typing "make package-overwrite" will overwrite files in the package
 sub-directories with src files.
 Typing "make package-diff" lists all differences between these files.
 Again, just type "make package" to see all of the package-related make
 options.
 :line
 Packages that require extra libraries :h5,link(start_3_3)
-A few of the standard and user packages require additional auxiliary
+A few of the standard and user packages require extra libraries.  See
-libraries.  Many of them are provided with LAMMPS, in which case they
+"Section 4"_Section_packages.html for two tables of packages which
-must be compiled first, before LAMMPS is built, if you wish to include
+indicate which ones require libraries.  For each such package, the
-that package.  If you get a LAMMPS build error about a missing
+Section 4 doc page gives details on how to build the extra library,
-library, this is likely the reason.  See the
+including how to download it if necessary.  The basic ideas are
-"Section 4"_Section_packages.html doc page for a list of
+summarized here.
 packages that have these kinds of auxiliary libraries.
-The lib directory in the distribution has sub-directories with package
+[System libraries:]
 names that correspond to the needed auxiliary libs, e.g. lib/gpu.
 Each sub-directory has a README file that gives more details.  Code
 for most of the auxiliary libraries is included in that directory.
 Examples are the USER-ATC and MEAM packages.
-A few of the lib sub-directories do not include code, but do include
+Packages in the tables "Section 4"_Section_packages.html with a "sys"
-instructions (and sometimes scripts) that automate the process of
+in the last column link to system libraries that typically already
-downloading the auxiliary library and installing it so LAMMPS can link
+exist on your machine.  E.g. the python package links to a system
-to it.  Examples are the KIM, VORONOI, USER-MOLFILE, and USER-SMD
+Python library.  If your machine does not have the required library,
-packages.
+you will have to download and install it on your machine, in either
 the system or user space.
-The lib/python directory (for the PYTHON package) contains only a
+[Internal libraries:]
 choice of Makefile.lammps.* files.  This is because no auxiliary code
 or libraries are needed, only the Python library and other system libs
 that should already available on your system.  However, the
 Makefile.lammps file is needed to tell LAMMPS which libs to use and
 where to find them.
-For libraries with provided code, the sub-directory README file
+Packages in the tables "Section 4"_Section_packages.html with an "int"
-(e.g. lib/atc/README) has instructions on how to build that library.
+in the last column link to internal libraries whose source code is
-This information is also summarized in "Section
+included with LAMMPS, in the lib/name directory where name is the
-4"_Section_packages.html.  Typically this is done by typing
+package name.  You must first build the library in that directory
-something like:
+before building LAMMPS with that package installed.  E.g. the gpu
 package links to a library you build in the lib/gpu dir.  You can
 often do the build in one step by typing "make lib-name args=..."
 from the src dir, with appropriate arguments.  You can leave off the
 args to see a help message.  See "Section 4"_Section_packages.html for
 details for each package.
-make -f Makefile.g++ :pre
+[External libraries:]
-If one of the provided Makefiles is not appropriate for your system
+Packages in the tables "Section 4"_Section_packages.html with an "ext"
-you will need to edit or add one.  Note that all the Makefiles have a
+in the last column link to exernal libraries whose source code is not
-setting for EXTRAMAKE at the top that specifies a Makefile.lammps.*
+included with LAMMPS.  You must first download and install the library
-file.
+before building LAMMPS with that package installed.  E.g. the voronoi
 package links to the freely available "Voro++ library"_voro_home2.  You
 can often do the download/build in one step by typing "make lib-name
 args=..." from the src dir, with appropriate arguments.  You can leave
 off the args to see a help message.  See "Section
 4"_Section_packages.html for details for each package.
-If the library build is successful, it will produce 2 files in the lib
+:link(voro_home2,http://math.lbl.gov/voro++)
 directory:
-libpackage.a
+[Possible errors:]
 Makefile.lammps :pre
-The Makefile.lammps file will typically be a copy of one of the
+There are various common errors which can occur when building extra
-Makefile.lammps.* files in the library directory.
+libraries or when building LAMMPS with packages that require the extra
 libraries.
-Note that you must insure that the settings in Makefile.lammps are
+If you cannot build the extra library itself successfully, you may
-appropriate for your system.  If they are not, the LAMMPS build may
+need to edit or create an appropriate Makefile for your machine, e.g.
-fail.  To fix this, you can edit or create a new Makefile.lammps.*
+with appropriate compiler or system settings.  Provided makefiles are
-file for your system, and copy it to Makefile.lammps.
+typically in the lib/name directory.  E.g. see the Makefile.* files in
 lib/gpu.
-As explained in the lib/package/README files, the settings in
+The LAMMPS build often uses settings in a lib/name/Makefile.lammps
-Makefile.lammps are used to specify additional system libraries and
+file which either exists in the LAMMPS distribution or is created or
-their locations so that LAMMPS can build with the auxiliary library.
+copied from a lib/name/Makefile.lammps.* file when the library is
-For example, if the MEAM package is used, the auxiliary library
+built.  If those settings are not correct for your machine you will
-consists of F90 code, built with a Fortran complier.  To link that
+need to edit or create an appropriate Makefile.lammps file.
 library with LAMMPS (a C++ code) via whatever C++ compiler LAMMPS is
 built with, typically requires additional Fortran-to-C libraries be
 included in the link.  Another example are the BLAS and LAPACK
 libraries needed to use the USER-ATC or USER-AWPMD packages.
-For libraries without provided code, the sub-directory README file has
+Package-specific details for these steps are given in "Section
-information on where to download the library and how to build it,
+4"_Section_packages.html an in README files in the lib/name
-e.g. lib/voronoi/README and lib/smd/README.  The README files also
+directories.
 describe how you must either (a) create soft links, via the "ln"
 command, in those directories to point to where you built or installed
 the packages, or (b) check or edit the Makefile.lammps file in the
 same directory to provide that information.
-Some of the sub-directories, e.g. lib/voronoi, also have an install.py
+[Compiler options needed for accelerator packages:]
 script which can be used to automate the process of
 downloading/building/installing the auxiliary library, and setting the
 needed soft links.  Type "python install.py" for further instructions.
-As with the sub-directories containing library code, if the soft links
+Several packages contain code that is optimized for specific hardware,
-or settings in the lib/package/Makefile.lammps files are not correct,
+e.g. CPU, KNL, or GPU.  These are the OPT, GPU, KOKKOS, USER-INTEL,
-the LAMMPS build will typically fail.
+and USER-OMP packages.  Compiling and linking the source files in
 these accelerator packages for optimal performance requires specific
 settings in the Makefile.machine file you use.
-:line
+A summary of the Makefile.machine settings needed for each of these
-
+packages is given in "Section 4"_Section_packages.html.  More info is
-Packages that require Makefile.machine settings :h5,link(start_3_4)
+given on the doc pages that describe each package in detail:
 A few packages require specific settings in Makefile.machine, to
 either build or use the package effectively.  These are the
 USER-INTEL, KOKKOS, USER-OMP, and OPT packages, used for accelerating
 code performance on CPUs or other hardware, as discussed in "Section
 5.3"_Section_accelerate.html#acc_3.
 A summary of what Makefile.machine changes are needed for each of
 these packages is given in "Section 4"_Section_packages.html.
 The details are given on the doc pages that describe each of these
 accelerator packages in detail:
 5.3.1 "USER-INTEL package"_accelerate_intel.html
 5.3.2 "GPU package"_accelerate_intel.html
 5.3.3 "KOKKOS package"_accelerate_kokkos.html
 5.3.4 "USER-OMP package"_accelerate_omp.html
 5.3.5 "OPT package"_accelerate_opt.html :all(b)
-You can also look at the following machine Makefiles in
+You can also use or examine the following machine Makefiles in
-src/MAKE/OPTIONS, which include the changes.  Note that the USER-INTEL
+src/MAKE/OPTIONS, which include the settings.  Note that the
-and KOKKOS packages allow for settings that build LAMMPS for different
+USER-INTEL and KOKKOS packages can use settings that build LAMMPS for
-hardware.  The USER-INTEL package builds for CPU and the Xeon Phi, the
+different hardware.  The USER-INTEL package can be compiled for Intel
-KOKKOS package builds for OpenMP, GPUs (Cuda), and the Xeon Phi.
+CPUs and KNLs; the KOKKOS package builds for CPUs (OpenMP), GPUs
 (Cuda), and Intel KNLs.
 Makefile.intel_cpu
 Makefile.intel_phi
@ -907,127 +890,9 @@ Makefile.kokkos_phi
 Makefile.omp
 Makefile.opt :ul
 Also note that the Make.py tool, described in the next "Section
 2.4"_#start_4 can automatically add the needed info to an existing
 machine Makefile, using simple command-line arguments.
 :line
-2.4 Building LAMMPS via the Make.py tool :h4,link(start_4)
+2.4 Building LAMMPS as a library :h4,link(start_4)
 The src directory includes a Make.py script, written in Python, which
 can be used to automate various steps of the build process.  It is
 particularly useful for working with the accelerator packages, as well
 as other packages which require auxiliary libraries to be built.
 The goal of the Make.py tool is to allow any complex multi-step LAMMPS
 build to be performed as a single Make.py command.  And you can
 archive the commands, so they can be re-invoked later via the -r
 (redo) switch.  If you find some LAMMPS build procedure that can't be
 done in a single Make.py command, let the developers know, and we'll
 see if we can augment the tool.
 You can run Make.py from the src directory by typing either:
 Make.py -h
 python Make.py -h :pre
 which will give you help info about the tool.  For the former to work,
 you may need to edit the first line of Make.py to point to your local
 Python.  And you may need to insure the script is executable:
 chmod +x Make.py :pre
 Here are examples of build tasks you can perform with Make.py:
 Install/uninstall packages: Make.py -p no-lib kokkos omp intel
 Build specific auxiliary libs: Make.py -a lib-atc lib-meam
 Build libs for all installed packages: Make.py -p cuda gpu -gpu mode=double arch=31 -a lib-all
 Create a Makefile from scratch with compiler and MPI settings: Make.py -m none -cc g++ -mpi mpich -a file
 Augment Makefile.serial with settings for installed packages: Make.py -p intel -intel cpu -m serial -a file
 Add JPG and FFTW support to Makefile.mpi: Make.py -m mpi -jpg -fft fftw -a file
 Build LAMMPS with a parallel make using Makefile.mpi: Make.py -j 16 -m mpi -a exe
 Build LAMMPS and libs it needs using Makefile.serial with accelerator settings: Make.py -p gpu intel -intel cpu -a lib-all file serial :tb(s=:)
 The bench and examples directories give Make.py commands that can be
 used to build LAMMPS with the various packages and options needed to
 run all the benchmark and example input scripts.  See these files for
 more details:
 bench/README
 bench/FERMI/README
 bench/KEPLER/README
 bench/PHI/README
 examples/README
 examples/accelerate/README
 examples/accelerate/make.list :ul
 All of the Make.py options and syntax help can be accessed by using
 the "-h" switch.
 E.g. typing "Make.py -h" gives
 Syntax: Make.py switch args ...
  switches can be listed in any order
  help switch:
    -h prints help and syntax for all other specified switches
  switch for actions:
    -a lib-all, lib-dir, clean, file, exe or machine
    list one or more actions, in any order
    machine is a Makefile.machine suffix, must be last if used
  one-letter switches:
    -d (dir), -j (jmake), -m (makefile), -o (output),
    -p (packages), -r (redo), -s (settings), -v (verbose)
  switches for libs:
    -atc, -awpmd, -colvars, -cuda
    -gpu, -meam, -poems, -qmmm, -reax
  switches for build and makefile options:
    -intel, -kokkos, -cc, -mpi, -fft, -jpg, -png :pre
 Using the "-h" switch with other switches and actions gives additional
 info on all the other specified switches or actions.  The "-h" can be
 anywhere in the command-line and the other switches do not need their
 arguments.  E.g. type "Make.py -h -d -atc -intel" will print:
 -d dir
  dir = LAMMPS home dir
  if -d not specified, working dir must be lammps/src :pre
 -atc make=suffix lammps=suffix2
  all args are optional and can be in any order
  make = use Makefile.suffix (def = g++)
  lammps = use Makefile.lammps.suffix2 (def = EXTRAMAKE in makefile) :pre
 -intel mode
  mode = cpu or phi (def = cpu)
    build Intel package for CPU or Xeon Phi :pre
 Note that Make.py never overwrites an existing Makefile.machine.
 Instead, it creates src/MAKE/MINE/Makefile.auto, which you can save or
 rename if desired.  Likewise it creates an executable named
 src/lmp_auto, which you can rename using the -o switch if desired.
 The most recently executed Make.py command is saved in
 src/Make.py.last.  You can use the "-r" switch (for redo) to re-invoke
 the last command, or you can save a sequence of one or more Make.py
 commands to a file and invoke the file of commands using "-r".  You
 can also label the commands in the file and invoke one or more of them
 by name.
 A typical use of Make.py is to start with a valid Makefile.machine for
 your system, that works for a vanilla LAMMPS build, i.e. when optional
 packages are not installed.  You can then use Make.py to add various
 settings (FFT, JPG, PNG) to the Makefile.machine as well as change its
 compiler and MPI options.  You can also add additional packages to the
 build, as well as build the needed supporting libraries.
 You can also use Make.py to create a new Makefile.machine from
 scratch, using the "-m none" switch, if you also specify what compiler
 and MPI options to use, via the "-cc" and "-mpi" switches.
 :line
 2.5 Building LAMMPS as a library :h4,link(start_5)
 LAMMPS can be built as either a static or shared library, which can
 then be called from another application or a scripting language.  See
@ -1063,7 +928,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 dynamically.  It will also create a soft link liblammps.so,
+can link to dyamically.  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.
@ -1149,7 +1014,7 @@ interface and how to extend it for your needs.
 :line
-2.6 Running LAMMPS :h4,link(start_6)
+2.5 Running LAMMPS :h4,link(start_5)
 By default, LAMMPS runs by reading commands from standard input.  Thus
 if you run the LAMMPS executable by itself, e.g.
@ -1281,7 +1146,7 @@ more processors or setup a smaller problem.
 :line
-2.7 Command-line options :h4,link(start_7)
+2.6 Command-line options :h4,link(start_6)
 At run time, LAMMPS recognizes several optional command-line switches
 which may be used in any order.  Either the full word or a one-or-two
@ -1415,8 +1280,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 (typically sockets)
+In this case Nm defines the number of NUMA regions (typicaly sockets)
-on a node which will be utilized by a single MPI rank.  By default Nm
+on a node which will be utilizied 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
@ -1480,7 +1345,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 simulations from one input script, using
+To run multiple independent simulatoins 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.
@ -1711,7 +1576,7 @@ negative numeric value.  It is OK if the first value1 starts with a
 :line
-2.8 LAMMPS screen output :h4,link(start_8)
+2.7 LAMMPS screen output :h4,link(start_7)
 As LAMMPS reads an input script, it prints information to both the
 screen and a log file about significant actions it takes to setup a
@ -1759,7 +1624,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 utilization per
+similar MD codes.  The {CPU use} line provides the CPU utilzation 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.
@ -1867,7 +1732,7 @@ communication, roughly 75% in the example above.
 :line
-2.9 Tips for users of previous LAMMPS versions :h4,link(start_9)
+2.8 Tips for users of previous LAMMPS versions :h4,link(start_8)
 The current C++ began with a complete rewrite of LAMMPS 2001, which
 was written in F90.  Features of earlier versions of LAMMPS are listed
--- a/doc/src/Section_tools.txt
+++ b/doc/src/Section_tools.txt
@ -369,15 +369,18 @@ supports it.  It has its own WWW page at
 msi2lmp tool :h4,link(msi)
-The msi2lmp sub-directory contains a tool for creating LAMMPS input
+The msi2lmp sub-directory contains a tool for creating LAMMPS template
-data files from BIOVIA's Materias Studio files (formerly Accelrys'
+input and data files from BIOVIA's Materias Studio files (formerly Accelrys'
 Insight MD code, formerly MSI/Biosym and its Discover MD code).
 This tool was written by John Carpenter (Cray), Michael Peachey
 (Cray), and Steve Lustig (Dupont). Several people contributed changes
 to remove bugs and adapt its output to changes in LAMMPS.
-See the README file for more information.
+This tool has several known limitations and is no longer under active
 development, so there are no changes except for the occasional bugfix.
 See the README file in the tools/msi2lmp folder for more information.
 :line
--- a/doc/src/accelerate_intel.txt
+++ b/doc/src/accelerate_intel.txt
@ -30,8 +30,8 @@ Dihedral Styles: charmm, harmonic, opls :l
 Fixes: nve, npt, nvt, nvt/sllod :l
 Improper Styles: cvff, harmonic :l
 Pair Styles: buck/coul/cut, buck/coul/long, buck, eam, gayberne,
-charmm/coul/long, lj/cut, lj/cut/coul/long, sw, tersoff :l
+charmm/coul/long, lj/cut, lj/cut/coul/long, lj/long/coul/long, sw, tersoff :l
-K-Space Styles: pppm :l
+K-Space Styles: pppm, pppm/disp :l
 :ule
 [Speed-ups to expect:]
@ -42,61 +42,88 @@ precision mode. Performance improvements are shown compared to
 LAMMPS {without using other acceleration packages} as these are
 under active development (and subject to performance changes). The
 measurements were performed using the input files available in
-the src/USER-INTEL/TEST directory. These are scalable in size; the
+the src/USER-INTEL/TEST directory with the provided run script. 
-results given are with 512K particles (524K for Liquid Crystal).
+These are scalable in size; the results given are with 512K 
-Most of the simulations are standard LAMMPS benchmarks (indicated
+particles (524K for Liquid Crystal). Most of the simulations are 
-by the filename extension in parenthesis) with modifications to the
+standard LAMMPS benchmarks (indicated by the filename extension in
-run length and to add a warmup run (for use with offload
+parenthesis) with modifications to the run length and to add a 
-benchmarks).
+warmup run (for use with offload benchmarks).
 :c,image(JPG/user_intel.png)
 Results are speedups obtained on Intel Xeon E5-2697v4 processors
 (code-named Broadwell) and Intel Xeon Phi 7250 processors
-(code-named Knights Landing) with "18 Jun 2016" LAMMPS built with
+(code-named Knights Landing) with "June 2017" LAMMPS built with
-Intel Parallel Studio 2016 update 3. Results are with 1 MPI task
+Intel Parallel Studio 2017 update 2. Results are with 1 MPI task
 per physical core. See {src/USER-INTEL/TEST/README} for the raw
 simulation rates and instructions to reproduce.
 :line
 [Accuracy and order of operations:]
 In most molecular dynamics software, parallelization parameters
 (# of MPI, OpenMP, and vectorization) can change the results due
 to changing the order of operations with finite-precision 
 calculations. The USER-INTEL package is deterministic. This means
 that the results should be reproducible from run to run with the
 {same} parallel configurations and when using determinstic 
 libraries or library settings (MPI, OpenMP, FFT). However, there
 are differences in the USER-INTEL package that can change the
 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 
 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
 :ule
 The precision mode (described below) used with the USER-INTEL 
 package can change the {accuracy} of the calculations. For the 
 default {mixed} precision option, calculations between pairs or 
 triplets of atoms are performed in single precision, intended to 
 be within the inherent error of MD simulations. All accumulation
 is performed in double precision to prevent the error from growing 
 with the number of atoms in the simulation. {Single} precision
 mode should not be used without appropriate validation.
 :line
 [Quick Start for Experienced Users:]
 LAMMPS should be built with the USER-INTEL package installed.
 Simulations should be run with 1 MPI task per physical {core},
 not {hardware thread}.
 For Intel Xeon CPUs:
 Edit src/MAKE/OPTIONS/Makefile.intel_cpu_intelmpi as necessary. :ulb,l
-If using {kspace_style pppm} in the input script, add "neigh_modify binsize 3" and "kspace_modify diff ad" to the input script for better
+Set the environment variable KMP_BLOCKTIME=0 :l
-performance. :l
+"-pk intel 0 omp $t -sf intel" added to LAMMPS command-line :l
-"-pk intel 0 omp 2 -sf intel" added to LAMMPS command-line :l
+$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
 If using {kspace_style pppm} in the input script, add 
 "kspace_modify diff ad" for better performance :l
 :ule
-For Intel Xeon Phi CPUs for simulations without {kspace_style
+For Intel Xeon Phi CPUs:
 pppm} in the input script :
-Edit src/MAKE/OPTIONS/Makefile.knl as necessary. :ulb,l
+Runs should be performed using MCDRAM. :ulb,l
 Runs should be performed using MCDRAM. :l
 "-pk intel 0 omp 2 -sf intel" {or} "-pk intel 0 omp 4 -sf intel"
 should be added to the LAMMPS command-line. Choice for best
 performance will depend on the simulation. :l
 :ule
-For Intel Xeon Phi CPUs for simulations with {kspace_style
+For simulations using {kspace_style pppm} on Intel CPUs 
-pppm} in the input script:
+supporting AVX-512:
-Edit src/MAKE/OPTIONS/Makefile.knl as necessary. :ulb,l
+Add "kspace_modify diff ad" to the input script :ulb,l
-Runs should be performed using MCDRAM. :l
+The command-line option should be changed to 
-Add "neigh_modify binsize 3" to the input script for better
+"-pk intel 0 omp $r lrt yes -sf intel" where $r is the number of 
-performance. :l
+threads minus 1. :l
-Add "kspace_modify diff ad" to the input script for better
+Do not use thread affinity (set KMP_AFFINITY=none) :l
-performance. :l
+The "newton off" setting may provide better scalability :l
 export KMP_AFFINITY=none :l
 "-pk intel 0 omp 3 lrt yes -sf intel" or "-pk intel 0 omp 1 lrt yes
 -sf intel" added to LAMMPS command-line. Choice for best performance
 will depend on the simulation. :l
 :ule
 For Intel Xeon Phi coprocessors (Offload):
@ -168,6 +195,10 @@ cat /proc/cpuinfo :pre
 [Building LAMMPS with the USER-INTEL package:]
 NOTE: See the src/USER-INTEL/README file for additional flags that
 might be needed for best performance on Intel server processors
 code-named "Skylake".
 The USER-INTEL package must be installed into the source directory:
 make yes-user-intel :pre
@ -321,8 +352,8 @@ follow in the input script.
 NOTE: The USER-INTEL package will perform better with modifications
 to the input script when "PPPM"_kspace_style.html is used:
-"kspace_modify diff ad"_kspace_modify.html and "neigh_modify binsize
+"kspace_modify diff ad"_kspace_modify.html should be added to the 
-3"_neigh_modify.html should be added to the input script.
+input script.
 Long-Range Thread (LRT) mode is an option to the "package
 intel"_package.html command that can improve performance when using
@ -341,6 +372,10 @@ would normally perform best with "-pk intel 0 omp 4", instead use
 environment variable "KMP_AFFINITY=none". LRT mode is not supported
 when using offload.
 NOTE: Changing the "newton"_newton.html setting to off can improve
 performance and/or scalability for simple 2-body potentials such as
 lj/cut or when using LRT mode on processors supporting AVX-512.
 Not all styles are supported in the USER-INTEL package. You can mix
 the USER-INTEL package with styles from the "OPT"_accelerate_opt.html
 package or the "USER-OMP package"_accelerate_omp.html. Of course,
@ -466,7 +501,7 @@ supported.
 Brown, W.M., Carrillo, J.-M.Y., Mishra, B., Gavhane, N., Thakker, F.M., De Kraker, A.R., Yamada, M., Ang, J.A., Plimpton, S.J., "Optimizing Classical Molecular Dynamics in LAMMPS," in Intel Xeon Phi Processor High Performance Programming: Knights Landing Edition, J. Jeffers, J. Reinders, A. Sodani, Eds. Morgan Kaufmann. :ulb,l
-Brown, W. M., Semin, A., Hebenstreit, M., Khvostov, S., Raman, K., Plimpton, S.J. Increasing Molecular Dynamics Simulation Rates with an 8-Fold Increase in Electrical Power Efficiency. 2016 International Conference for High Performance Computing. In press. :l
+Brown, W. M., Semin, A., Hebenstreit, M., Khvostov, S., Raman, K., Plimpton, S.J. "Increasing Molecular Dynamics Simulation Rates with an 8-Fold Increase in Electrical Power Efficiency."_http://dl.acm.org/citation.cfm?id=3014915 2016 High Performance Computing, Networking, Storage and Analysis, SC16: International Conference (pp. 82-95). :l
 Brown, W.M., Carrillo, J.-M.Y., Gavhane, N., Thakkar, F.M., Plimpton, S.J. Optimizing Legacy Molecular Dynamics Software with Directive-Based Offload. Computer Physics Communications. 2015. 195: p. 95-101. :l
 :ule
--- a/doc/src/accelerate_kokkos.txt
+++ b/doc/src/accelerate_kokkos.txt
@ -415,15 +415,15 @@ 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, as
+KOKKOS pthreads option, compile LAMMPS the KOKKOS HWLOC=yes option
-discussed in "Section 2.3.4"_Sections_start.html#start_3_4 of the
+(see "this section"_Section_packages.html#KOKKOS of the manual for
-manual.
+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
+e.g. src/MAKE/Makefile.cuda, is correct for your GPU hardware/software.
-(see "this section"_Section_start.html#start_3_4 of the manual for
+(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
--- a/doc/src/angle_sdk.txt
+++ b/doc/src/angle_sdk.txt
@ -46,7 +46,7 @@ from the pair_style.
 [Restrictions:]
 This angle style can only be used if LAMMPS was built with the
-USER-CG-CMM package.  See the "Making
+USER-CGSDK package.  See the "Making
 LAMMPS"_Section_start.html#start_3 section for more info on packages.
 [Related commands:]
--- a/doc/src/bonds.txt
+++ b/doc/src/bonds.txt
@ -16,7 +16,6 @@ Bond Styles :h1
   bond_none
   bond_nonlinear
   bond_oxdna
   bond_oxdna2
   bond_quartic
   bond_table
   bond_zero
--- a/doc/src/commands.txt
+++ b/doc/src/commands.txt
@ -32,12 +32,12 @@ Commands :h1
   dimension
   displace_atoms
   dump
   dump_custom_vtk
   dump_h5md
   dump_image
   dump_modify
   dump_molfile
-   dump_nc
+   dump_netcdf
   dump_vtk
   echo
   fix
   fix_modify
--- a/doc/src/compute_cna_atom.txt
+++ b/doc/src/compute_cna_atom.txt
@ -26,7 +26,7 @@ Define a computation that calculates the CNA (Common Neighbor
 Analysis) pattern for each atom in the group.  In solid-state systems
 the CNA pattern is a useful measure of the local crystal structure
 around an atom.  The CNA methodology is described in "(Faken)"_#Faken
-and "(Tsuzuki)"_#Tsuzuki.
+and "(Tsuzuki)"_#Tsuzuki1.
 Currently, there are five kinds of CNA patterns LAMMPS recognizes:
@ -93,5 +93,5 @@ above.
 :link(Faken)
 [(Faken)] Faken, Jonsson, Comput Mater Sci, 2, 279 (1994).
-:link(Tsuzuki)
+:link(Tsuzuki1)
 [(Tsuzuki)] Tsuzuki, Branicio, Rino, Comput Phys Comm, 177, 518 (2007).
--- a/doc/src/compute_cnp_atom.txt
+++ b/doc/src/compute_cnp_atom.txt
@ -0,0 +1,111 @@
 "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
 :link(lc,Section_commands.html#comm)
 :line
 compute cnp/atom command :h3
 [Syntax:]
 compute ID group-ID cnp/atom cutoff :pre
 ID, group-ID are documented in "compute"_compute.html command
 cnp/atom = style name of this compute command
 cutoff = cutoff distance for nearest neighbors (distance units) :ul
 [Examples:]
 compute 1 all cnp/atom 3.08 :pre
 [Description:]
 Define a computation that calculates the Common Neighborhood
 Parameter (CNP) for each atom in the group.  In solid-state systems
 the CNP is a useful measure of the local crystal structure
 around an atom and can be used to characterize whether the
 atom is part of a perfect lattice, a local defect (e.g. a dislocation
 or stacking fault), or at a surface.
 The value of the CNP parameter will be 0.0 for atoms not in the
 specified compute group.  Note that normally a CNP calculation should
 only be performed on single component systems.
 This parameter is computed using the following formula from
 "(Tsuzuki)"_#Tsuzuki2
 :c,image(Eqs/cnp_eq.jpg)
 where the index {j} goes over the {n}i nearest neighbors of atom
 {i}, and the index {k} goes over the {n}ij common nearest neighbors
 between atom {i} and atom {j}. Rik and Rjk are the vectors connecting atom
 {k} to atoms {i} and {j}.  The quantity in the double sum is computed
 for each atom. 
 The CNP calculation is sensitive to the specified cutoff value.
 You should ensure that the appropriate nearest neighbors of an atom are
 found within the cutoff distance for the presumed crystal structure.
 E.g. 12 nearest neighbor for perfect FCC and HCP crystals, 14 nearest
 neighbors for perfect BCC crystals.  These formulas can be used to
 obtain a good cutoff distance:
 :c,image(Eqs/cnp_cutoff.jpg)
 where a is the lattice constant for the crystal structure concerned
 and in the HCP case, x = (c/a) / 1.633, where 1.633 is the ideal c/a
 for HCP crystals.
 Also note that since the CNP calculation in LAMMPS uses the neighbors
 of an owned atom to find the nearest neighbors of a ghost atom, the
 following relation should also be satisfied:
 :c,image(Eqs/cnp_cutoff2.jpg)
 where Rc is the cutoff distance of the potential, Rs is the skin
 distance as specified by the "neighbor"_neighbor.html command, and
 cutoff is the argument used with the compute cnp/atom command.  LAMMPS
 will issue a warning if this is not the case.
 The neighbor list needed to compute this quantity is constructed each
 time the calculation is performed (e.g. each time a snapshot of atoms
 is dumped).  Thus it can be inefficient to compute/dump this quantity
 too frequently or to have multiple compute/dump commands, each with a
 {cnp/atom} style.
 [Output info:]
 This compute calculates a per-atom vector, which can be accessed by
 any command that uses per-atom values from a compute as input.  See
 "Section 6.15"_Section_howto.html#howto_15 for an overview of
 LAMMPS output options.
 The per-atom vector values will be real positive numbers. Some typical CNP
 values:
 FCC lattice = 0.0
 BCC lattice = 0.0
 HCP lattice = 4.4 :pre
 FCC (111) surface ~ 13.0
 FCC (100) surface ~ 26.5
 FCC dislocation core ~ 11 :pre
 [Restrictions:]
 This compute is part of the USER-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:]
 "compute cna/atom"_compute_cna_atom.html
 "compute centro/atom"_compute_centro_atom.html
 [Default:] none
 :line
 :link(Tsuzuki2)
 [(Tsuzuki)] Tsuzuki, Branicio, Rino, Comput Phys Comm, 177, 518 (2007).
--- a/doc/src/compute_saed.txt
+++ b/doc/src/compute_saed.txt
@ -111,26 +111,26 @@ Coefficients parameterized by "(Fox)"_#Fox are assigned for each
 atom type designating the chemical symbol and charge of each atom
 type. Valid chemical symbols for compute saed are:
-         H:      He:      Li:      Be:       B:
+H:       He:      Li:      Be:       B:
-         C:       N:       O:       F:      Ne:
+C:        N:       O:       F:      Ne:
-        Na:      Mg:      Al:      Si:       P:
+Na:      Mg:      Al:      Si:       P:
-         S:      Cl:      Ar:       K:      Ca:
+S:       Cl:      Ar:       K:      Ca:
-        Sc:      Ti:       V:      Cr:      Mn:
+Sc:      Ti:       V:      Cr:      Mn:
-        Fe:      Co:      Ni:      Cu:      Zn:
+Fe:      Co:      Ni:      Cu:      Zn:
-        Ga:      Ge:      As:      Se:      Br:
+Ga:      Ge:      As:      Se:      Br:
-        Kr:      Rb:      Sr:       Y:      Zr:
+Kr:      Rb:      Sr:       Y:      Zr:
-        Nb:      Mo:      Tc:      Ru:      Rh:
+Nb:      Mo:      Tc:      Ru:      Rh:
-        Pd:      Ag:      Cd:      In:      Sn:
+Pd:      Ag:      Cd:      In:      Sn:
-        Sb:      Te:       I:      Xe:      Cs:
+Sb:      Te:       I:      Xe:      Cs:
-        Ba:      La:      Ce:      Pr:      Nd:
+Ba:      La:      Ce:      Pr:      Nd:
-        Pm:      Sm:      Eu:      Gd:      Tb:
+Pm:      Sm:      Eu:      Gd:      Tb:
-        Dy:      Ho:      Er:      Tm:      Yb:
+Dy:      Ho:      Er:      Tm:      Yb:
-        Lu:      Hf:      Ta:       W:      Re:
+Lu:      Hf:      Ta:       W:      Re:
-        Os:      Ir:      Pt:      Au:      Hg:
+Os:      Ir:      Pt:      Au:      Hg:
-        Tl:      Pb:      Bi:      Po:      At:
+Tl:      Pb:      Bi:      Po:      At:
-        Rn:      Fr:      Ra:      Ac:      Th:
+Rn:      Fr:      Ra:      Ac:      Th:
-        Pa:       U:      Np:      Pu:      Am:
+Pa:       U:      Np:      Pu:      Am:
-        Cm:      Bk:      Cf:tb(c=5,s=:)
+Cm:      Bk:      Cf:tb(c=5,s=:)
 If the {echo} keyword is specified, compute saed will provide extra
--- a/doc/src/compute_sna_atom.txt
+++ b/doc/src/compute_sna_atom.txt
@ -24,7 +24,7 @@ twojmax = band limit for bispectrum components (non-negative integer) :l
 R_1, R_2,... = list of cutoff radii, one for each type (distance units) :l
 w_1, w_2,... = list of neighbor weights, one for each type  :l
 zero or more keyword/value pairs may be appended :l
-keyword = {diagonal} or {rmin0} or {switchflag} or {bzeroflag} :l
+keyword = {diagonal} or {rmin0} or {switchflag} or {bzeroflag} or {quadraticflag}:l
  {diagonal} value = {0} or {1} or {2} or {3}
     {0} = all j1, j2, j <= twojmax, j2 <= j1
     {1} = subset satisfying j1 == j2
@ -36,7 +36,10 @@ keyword = {diagonal} or {rmin0} or {switchflag} or {bzeroflag} :l
     {1} = use switching function
  {bzeroflag} value = {0} or {1}
     {0} = do not subtract B0
-     {1} = subtract B0 :pre
+     {1} = subtract B0
  {quadraticflag} value = {0} or {1}
     {0} = do not generate quadratic terms
     {1} = generate quadratic terms :pre
 :ule
 [Examples:]
@ -151,7 +154,7 @@ linear mapping from radial distance to polar angle {theta0} on the
 The argument {twojmax} and the keyword {diagonal} define which
 bispectrum components are generated. See section below on output for a
 detailed explanation of the number of bispectrum components and the
-ordered in which they are listed
+ordered in which they are listed.
 The keyword {switchflag} can be used to turn off the switching
 function.
@ -162,6 +165,14 @@ the calculated bispectrum components. This optional keyword is only
 available for compute {sna/atom}, as {snad/atom} and {snav/atom}
 are unaffected by the removal of constant terms.
 The keyword {quadraticflag} determines whether or not the
 quadratic analogs to the bispectrum quantities are generated.
 These are formed by taking the outer product of the vector
 of bispectrum components with itself.
 See section below on output for a
 detailed explanation of the number of quadratic terms and the
 ordered in which they are listed.
 NOTE: If you have a bonded system, then the settings of
 "special_bonds"_special_bonds.html command can remove pairwise
 interactions between atoms in the same bond, angle, or dihedral.  This
@ -180,7 +191,7 @@ command that includes all pairs in the neighbor list.
 Compute {sna/atom} calculates a per-atom array, each column
 corresponding to a particular bispectrum component.  The total number
-of columns and the identities of the bispectrum component contained in
+of columns and the identity of the bispectrum component contained in
 each column depend on the values of {twojmax} and {diagonal}, as
 described by the following piece of python code:
@ -213,6 +224,20 @@ 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
 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.
 If the {quadratic} keyword value is set to 1, then additional
 columns are appended to each per-atom array, corresponding to
 the products of all distinct pairs of  bispectrum components. If the
 number of bispectrum components is {K}, then the number of distinct pairs
 is  {K}({K}+1)/2. These are output in subblocks of  {K}({K}+1)/2 columns, using the same
 ordering of sub-blocks as was used for the bispectrum
 components. Within each sub-block, the ordering is upper-triangular,
 (1,1),(1,2)...(1,{K}),(2,1)...({K}-1,{K}-1),({K}-1,{K}),({K},{K})
 These values can be accessed by any command that uses per-atom values
 from a compute as input.  See "Section
 6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
@ -231,7 +256,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.
 [Default:]
 The optional keyword defaults are {diagonal} = 0, {rmin0} = 0,
-{switchflag} = 1, {bzeroflag} = 0.
+{switchflag} = 1, {bzeroflag} = 1, {quadraticflag} = 0,
 :line
--- a/doc/src/computes.txt
+++ b/doc/src/computes.txt
@ -17,6 +17,7 @@ Computes :h1
   compute_chunk_atom
   compute_cluster_atom
   compute_cna_atom
   compute_cnp_atom
   compute_com
   compute_com_chunk
   compute_contact_atom
--- a/doc/src/dihedral_spherical.txt
+++ b/doc/src/dihedral_spherical.txt
@ -14,10 +14,11 @@ dihedral_style spherical :pre
 [Examples:]
-dihedral_coeff 1 1  286.1  1 124 1   1 90.0 0   1 90.0 0
+dihedral_coeff 1 1  286.1  1 124  1    1 90.0 0    1 90.0 0
-dihedral_coeff 1 3  286.1  1 114 1   1 90  0    1 90.0  0  &
+dihedral_coeff 1 3  69.3   1 93.9 1    1 90   0    1 90   0  &
-                    17.3   0 0.0 0   1 158 1    0 0.0   0  &
+                    49.1   0 0.00 0    1 74.4 1    0 0.00 0  &
-                    15.1   0 0.0 0   0 0.0 0    1 167.3 1   :pre
+                    25.2   0 0.00 0    0 0.00 0    1 48.1 1
 :pre
 [Description:]
@ -35,13 +36,14 @@ the dihedral interaction even if it requires adding additional terms to
 the expansion (as was done in the second example).  A careful choice of
 parameters can prevent singularities that occur with traditional
 force-fields whenever theta1 or theta2 approach 0 or 180 degrees.
 The last example above corresponds to an interaction with a single energy
-minima located at phi=114, theta1=158, theta2=167.3 degrees, and it remains
+minima located near phi=93.9, theta1=74.4, theta2=48.1 degrees, and it remains
 numerically stable at all angles (phi, theta1, theta2). In this example,
-the coefficients 17.3, and 15.1 can be physically interpreted as the
+the coefficients 49.1, and 25.2 can be physically interpreted as the
 harmonic spring constants for theta1 and theta2 around their minima.
-The coefficient 286.1 is the harmonic spring constant for phi after
+The coefficient 69.3 is the harmonic spring constant for phi after
-division by sin(158)*sin(167.3) (the minima positions for theta1 and theta2).
+division by sin(74.4)*sin(48.1) (the minima positions for theta1 and theta2).
 The following coefficients must be defined for each dihedral type via the
 "dihedral_coeff"_dihedral_coeff.html command as in the example above, or in
--- a/doc/src/dump.txt
+++ b/doc/src/dump.txt
@ -7,12 +7,12 @@
 :line
 dump command :h3
-"dump custom/vtk"_dump_custom_vtk.html command :h3
+"dump vtk"_dump_vtk.html command :h3
 "dump h5md"_dump_h5md.html command :h3
 "dump molfile"_dump_molfile.html command :h3
 "dump netcdf"_dump_netcdf.html command :h3
 "dump image"_dump_image.html command :h3
 "dump movie"_dump_image.html command :h3
 "dump molfile"_dump_molfile.html command :h3
 "dump nc"_dump_nc.html command :h3
 [Syntax:]
@ -20,7 +20,7 @@ dump ID group-ID style N file args :pre
 ID = user-assigned name for the dump :ulb,l
 group-ID = ID of the group of atoms to be dumped :l
-style = {atom} or {atom/gz} or {atom/mpiio} or {cfg} or {cfg/gz} or {cfg/mpiio} or {dcd} or {xtc} or {xyz} or {xyz/gz} or {xyz/mpiio} or {h5md} or {image} or {movie} or {molfile} or {local} or {custom} or {custom/gz} or {custom/mpiio} :l
+style = {atom} or {atom/gz} or {atom/mpiio} or {cfg} or {cfg/gz} or {cfg/mpiio} or {custom} or {custom/gz} or {custom/mpiio} or {dcd} or {h5md} or {image} or or {local} or {molfile} or {movie} or {netcdf} or {netcdf/mpiio} or {vtk} or {xtc} or {xyz} or {xyz/gz} or {xyz/mpiio} :l
 N = dump every this many timesteps :l
 file = name of file to write dump info to :l
 args = list of arguments for a particular style :l
@ -30,33 +30,22 @@ args = list of arguments for a particular style :l
  {cfg} args = same as {custom} args, see below
  {cfg/gz} args = same as {custom} args, see below
  {cfg/mpiio} args = same as {custom} args, see below
  {custom}, {custom/gz}, {custom/mpiio} args = see below
  {dcd} args = none
  {h5md} args = discussed on "dump h5md"_dump_h5md.html doc page
  {image} args = discussed on "dump image"_dump_image.html doc page
  {local} args = see below
  {molfile} args = discussed on "dump molfile"_dump_molfile.html doc page
  {movie} args = discussed on "dump image"_dump_image.html doc page
  {netcdf} args = discussed on "dump netcdf"_dump_netcdf.html doc page
  {netcdf/mpiio} args = discussed on "dump netcdf"_dump_netcdf.html doc page
  {vtk} args = same as {custom} args, see below, also "dump vtk"_dump_vtk.html doc page
  {xtc} args = none
-  {xyz} args = none :pre
+  {xyz} args = none
-  {xyz/gz} args = none :pre
+  {xyz/gz} args = none
  {xyz/mpiio} args = none :pre
-  {custom/vtk} args = similar to custom args below, discussed on "dump custom/vtk"_dump_custom_vtk.html doc page :pre
+{custom} or {custom/gz} or {custom/mpiio} args = list of atom attributes :l
  {h5md} args = discussed on "dump h5md"_dump_h5md.html doc page :pre
  {image} args = discussed on "dump image"_dump_image.html doc page :pre
  {movie} args = discussed on "dump image"_dump_image.html doc page :pre
  {molfile} args = discussed on "dump molfile"_dump_molfile.html doc page
  {nc} args = discussed on "dump nc"_dump_nc.html doc page :pre
  {local} args = list of local attributes
    possible attributes = index, c_ID, c_ID\[I\], f_ID, f_ID\[I\]
      index = enumeration of local values
      c_ID = local vector calculated by a compute with ID
      c_ID\[I\] = Ith column of local array calculated by a compute with ID, I can include wildcard (see below)
      f_ID = local vector calculated by a fix with ID
      f_ID\[I\] = Ith column of local array calculated by a fix with ID, I can include wildcard (see below) :pre
  {custom} or {custom/gz} or {custom/mpiio} args = list of atom attributes
    possible attributes = id, mol, proc, procp1, type, element, mass,
                          x, y, z, xs, ys, zs, xu, yu, zu,
                          xsu, ysu, zsu, ix, iy, iz,
@ -94,6 +83,15 @@ args = list of arguments for a particular style :l
      v_name = per-atom vector calculated by an atom-style variable with name
      d_name = per-atom floating point vector with name, managed by fix property/atom
      i_name = per-atom integer vector with name, managed by fix property/atom :pre
 {local} args = list of local attributes :l
    possible attributes = index, c_ID, c_ID\[I\], f_ID, f_ID\[I\]
      index = enumeration of local values
      c_ID = local vector calculated by a compute with ID
      c_ID\[I\] = Ith column of local array calculated by a compute with ID, I can include wildcard (see below)
      f_ID = local vector calculated by a fix with ID
      f_ID\[I\] = Ith column of local array calculated by a fix with ID, I can include wildcard (see below) :pre
 :ule
 [Examples:]
--- a/doc/src/dump_custom_vtk.txt
+++ b/doc/src/dump_custom_vtk.txt
@ -1,347 +0,0 @@
 "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
 :link(lc,Section_commands.html#comm)
 :line
 dump custom/vtk command :h3
 [Syntax:]
 dump ID group-ID style N file args :pre
 ID = user-assigned name for the dump :ulb,l
 group-ID = ID of the group of atoms to be dumped :l
 style = {custom/vtk} :l
 N = dump every this many timesteps :l
 file = name of file to write dump info to :l
 args = list of arguments for a particular style :l
  {custom/vtk} args = list of atom attributes
    possible attributes = id, mol, proc, procp1, type, element, mass,
                          x, y, z, xs, ys, zs, xu, yu, zu,
                          xsu, ysu, zsu, ix, iy, iz,
                          vx, vy, vz, fx, fy, fz,
                          q, mux, muy, muz, mu,
                          radius, diameter, omegax, omegay, omegaz,
                          angmomx, angmomy, angmomz, tqx, tqy, tqz,
                          c_ID, c_ID\[N\], f_ID, f_ID\[N\], v_name :pre
      id = atom ID
      mol = molecule ID
      proc = ID of processor that owns atom
      procp1 = ID+1 of processor that owns atom
      type = atom type
      element = name of atom element, as defined by "dump_modify"_dump_modify.html command
      mass = atom mass
      x,y,z = unscaled atom coordinates
      xs,ys,zs = scaled atom coordinates
      xu,yu,zu = unwrapped atom coordinates
      xsu,ysu,zsu = scaled unwrapped atom coordinates
      ix,iy,iz = box image that the atom is in
      vx,vy,vz = atom velocities
      fx,fy,fz = forces on atoms
      q = atom charge
      mux,muy,muz = orientation of dipole moment of atom
      mu = magnitude of dipole moment of atom
      radius,diameter = radius,diameter of spherical particle
      omegax,omegay,omegaz = angular velocity of spherical particle
      angmomx,angmomy,angmomz = angular momentum of aspherical particle
      tqx,tqy,tqz = torque on finite-size particles
      c_ID = per-atom vector calculated by a compute with ID
      c_ID\[I\] = Ith column of per-atom array calculated by a compute with ID, I can include wildcard (see below)
      f_ID = per-atom vector calculated by a fix with ID
      f_ID\[I\] = Ith column of per-atom array calculated by a fix with ID, I can include wildcard (see below)
      v_name = per-atom vector calculated by an atom-style variable with name
      d_name = per-atom floating point vector with name, managed by fix property/atom
      i_name = per-atom integer vector with name, managed by fix property/atom :pre
 :ule
 [Examples:]
 dump dmpvtk all custom/vtk 100 dump*.myforce.vtk id type vx fx
 dump dmpvtp flow custom/vtk 100 dump*.%.displace.vtp id type c_myD\[1\] c_myD\[2\] c_myD\[3\] v_ke :pre
 The style {custom/vtk} is similar to the "custom"_dump.html style but
 uses the VTK library to write data to VTK simple legacy or XML format
 depending on the filename extension specified. This can be either
 {*.vtk} for the legacy format or {*.vtp} and {*.vtu}, respectively,
 for the XML format; see the "VTK
 homepage"_http://www.vtk.org/VTK/img/file-formats.pdf for a detailed
 description of these formats.  Since this naming convention conflicts
 with the way binary output is usually specified (see below),
 "dump_modify binary"_dump_modify.html allows to set the binary
 flag for this dump style explicitly.
 [Description:]
 Dump a snapshot of atom quantities to one or more files every N
 timesteps in a format readable by the "VTK visualization
 toolkit"_http://www.vtk.org or other visualization tools that use it,
 e.g. "ParaView"_http://www.paraview.org.  The timesteps on which dump
 output is written can also be controlled by a variable; see the
 "dump_modify every"_dump_modify.html command for details.
 Only information for atoms in the specified group is dumped.  The
 "dump_modify thresh and region"_dump_modify.html commands can also
 alter what atoms are included; see details below.
 As described below, special characters ("*", "%") in the filename
 determine the kind of output.
 IMPORTANT NOTE: Because periodic boundary conditions are enforced only
 on timesteps when neighbor lists are rebuilt, the coordinates of an
 atom written to a dump file may be slightly outside the simulation
 box.
 IMPORTANT NOTE: Unless the "dump_modify sort"_dump_modify.html
 option is invoked, the lines of atom information written to dump files
 will be in an indeterminate order for each snapshot.  This is even
 true when running on a single processor, if the "atom_modify
 sort"_atom_modify.html option is on, which it is by default.  In this
 case atoms are re-ordered periodically during a simulation, due to
 spatial sorting.  It is also true when running in parallel, because
 data for a single snapshot is collected from multiple processors, each
 of which owns a subset of the atoms.
 For the {custom/vtk} style, sorting is off by default. See the
 "dump_modify"_dump_modify.html doc page for details.
 :line
 The dimensions of the simulation box are written to a separate file
 for each snapshot (either in legacy VTK or XML format depending on
 the format of the main dump file) with the suffix {_boundingBox}
 appended to the given dump filename.
 For an orthogonal simulation box this information is saved as a
 rectilinear grid (legacy .vtk or .vtr XML format).
 Triclinic simulation boxes (non-orthogonal) are saved as
 hexahedrons in either legacy .vtk or .vtu XML format.
 Style {custom/vtk} allows you to specify a list of atom attributes
 to be written to the dump file for each atom.  Possible attributes
 are listed above.  In contrast to the {custom} style, the attributes
 are rearranged to ensure correct ordering of vector components
 (except for computes and fixes - these have to be given in the right
 order) and duplicate entries are removed.
 You cannot specify a quantity that is not defined for a particular
 simulation - such as {q} for atom style {bond}, since that atom style
 doesn't assign charges.  Dumps occur at the very end of a timestep,
 so atom attributes will include effects due to fixes that are applied
 during the timestep.  An explanation of the possible dump custom/vtk attributes
 is given below. Since position data is required to write VTK files "x y z"
 do not have to be specified explicitly.
 The VTK format uses a single snapshot of the system per file, thus
 a wildcard "*" must be included in the filename, as discussed below.
 Otherwise the dump files will get overwritten with the new snapshot
 each time.
 :line
 Dumps are performed on timesteps that are a multiple of N (including
 timestep 0) and on the last timestep of a minimization if the
 minimization converges.  Note that this means a dump will not be
 performed on the initial timestep after the dump command is invoked,
 if the current timestep is not a multiple of N.  This behavior can be
 changed via the "dump_modify first"_dump_modify.html command, which
 can also be useful if the dump command is invoked after a minimization
 ended on an arbitrary timestep.  N can be changed between runs by
 using the "dump_modify every"_dump_modify.html command.
 The "dump_modify every"_dump_modify.html command
 also allows a variable to be used to determine the sequence of
 timesteps on which dump files are written.  In this mode a dump on the
 first timestep of a run will also not be written unless the
 "dump_modify first"_dump_modify.html command is used.
 Dump filenames can contain two wildcard characters.  If a "*"
 character appears in the filename, then one file per snapshot is
 written and the "*" character is replaced with the timestep value.
 For example, tmp.dump*.vtk becomes tmp.dump0.vtk, tmp.dump10000.vtk,
 tmp.dump20000.vtk, etc.  Note that the "dump_modify pad"_dump_modify.html
 command can be used to insure all timestep numbers are the same length
 (e.g. 00010), which can make it easier to read a series of dump files
 in order with some post-processing tools.
 If a "%" character appears in the filename, then each of P processors
 writes a portion of the dump file, and the "%" character is replaced
 with the processor ID from 0 to P-1 preceded by an underscore character.
 For example, tmp.dump%.vtp becomes tmp.dump_0.vtp, tmp.dump_1.vtp, ...
 tmp.dump_P-1.vtp, etc.  This creates smaller files and can be a fast
 mode of output on parallel machines that support parallel I/O for output.
 By default, P = the number of processors meaning one file per
 processor, but P can be set to a smaller value via the {nfile} or
 {fileper} keywords of the "dump_modify"_dump_modify.html command.
 These options can be the most efficient way of writing out dump files
 when running on large numbers of processors.
 For the legacy VTK format "%" is ignored and P = 1, i.e., only
 processor 0 does write files.
 Note that using the "*" and "%" characters together can produce a
 large number of small dump files!
 If {dump_modify binary} is used, the dump file (or files, if "*" or
 "%" is also used) is written in binary format.  A binary dump file
 will be about the same size as a text version, but will typically
 write out much faster.
 :line
 This section explains the atom attributes that can be specified as
 part of the {custom/vtk} style.
 The {id}, {mol}, {proc}, {procp1}, {type}, {element}, {mass}, {vx},
 {vy}, {vz}, {fx}, {fy}, {fz}, {q} attributes are self-explanatory.
 {Id} is the atom ID.  {Mol} is the molecule ID, included in the data
 file for molecular systems.  {Proc} is the ID of the processor (0 to
 Nprocs-1) that currently owns the atom.  {Procp1} is the proc ID+1,
 which can be convenient in place of a {type} attribute (1 to Ntypes)
 for coloring atoms in a visualization program.  {Type} is the atom
 type (1 to Ntypes).  {Element} is typically the chemical name of an
 element, which you must assign to each type via the "dump_modify
 element"_dump_modify.html command.  More generally, it can be any
 string you wish to associated with an atom type.  {Mass} is the atom
 mass.  {Vx}, {vy}, {vz}, {fx}, {fy}, {fz}, and {q} are components of
 atom velocity and force and atomic charge.
 There are several options for outputting atom coordinates.  The {x},
 {y}, {z} attributes write atom coordinates "unscaled", in the
 appropriate distance "units"_units.html (Angstroms, sigma, etc).  Use
 {xs}, {ys}, {zs} if you want the coordinates "scaled" to the box size,
 so that each value is 0.0 to 1.0.  If the simulation box is triclinic
 (tilted), then all atom coords will still be between 0.0 and 1.0.
 I.e. actual unscaled (x,y,z) = xs*A + ys*B + zs*C, where (A,B,C) are
 the non-orthogonal vectors of the simulation box edges, as discussed
 in "Section 6.12"_Section_howto.html#howto_12.
 Use {xu}, {yu}, {zu} if you want the coordinates "unwrapped" by the
 image flags for each atom.  Unwrapped means that if the atom has
 passed thru a periodic boundary one or more times, the value is
 printed for what the coordinate would be if it had not been wrapped
 back into the periodic box.  Note that using {xu}, {yu}, {zu} means
 that the coordinate values may be far outside the box bounds printed
 with the snapshot.  Using {xsu}, {ysu}, {zsu} is similar to using
 {xu}, {yu}, {zu}, except that the unwrapped coordinates are scaled by
 the box size. Atoms that have passed through a periodic boundary will
 have the corresponding coordinate increased or decreased by 1.0.
 The image flags can be printed directly using the {ix}, {iy}, {iz}
 attributes.  For periodic dimensions, they specify which image of the
 simulation box the atom is considered to be in.  An image of 0 means
 it is inside the box as defined.  A value of 2 means add 2 box lengths
 to get the true value.  A value of -1 means subtract 1 box length to
 get the true value.  LAMMPS updates these flags as atoms cross
 periodic boundaries during the simulation.
 The {mux}, {muy}, {muz} attributes are specific to dipolar systems
 defined with an atom style of {dipole}.  They give the orientation of
 the atom's point dipole moment.  The {mu} attribute gives the
 magnitude of the atom's dipole moment.
 The {radius} and {diameter} attributes are specific to spherical
 particles that have a finite size, such as those defined with an atom
 style of {sphere}.
 The {omegax}, {omegay}, and {omegaz} attributes are specific to
 finite-size spherical particles that have an angular velocity.  Only
 certain atom styles, such as {sphere} define this quantity.
 The {angmomx}, {angmomy}, and {angmomz} attributes are specific to
 finite-size aspherical particles that have an angular momentum.  Only
 the {ellipsoid} atom style defines this quantity.
 The {tqx}, {tqy}, {tqz} attributes are for finite-size particles that
 can sustain a rotational torque due to interactions with other
 particles.
 The {c_ID} and {c_ID\[I\]} attributes allow per-atom vectors or arrays
 calculated by a "compute"_compute.html to be output.  The ID in the
 attribute should be replaced by the actual ID of the compute that has
 been defined previously in the input script.  See the
 "compute"_compute.html command for details.  There are computes for
 calculating the per-atom energy, stress, centro-symmetry parameter,
 and coordination number of individual atoms.
 Note that computes which calculate global or local quantities, as
 opposed to per-atom quantities, cannot be output in a dump custom/vtk
 command.  Instead, global quantities can be output by the
 "thermo_style custom"_thermo_style.html command, and local quantities
 can be output by the dump local command.
 If {c_ID} is used as a attribute, then the per-atom vector calculated
 by the compute is printed.  If {c_ID\[I\]} is used, then I must be in
 the range from 1-M, which will print the Ith column of the per-atom
 array with M columns calculated by the compute.  See the discussion
 above for how I can be specified with a wildcard asterisk to
 effectively specify multiple values.
 The {f_ID} and {f_ID\[I\]} attributes allow vector or array per-atom
 quantities calculated by a "fix"_fix.html to be output.  The ID in the
 attribute should be replaced by the actual ID of the fix that has been
 defined previously in the input script.  The "fix
 ave/atom"_fix_ave_atom.html command is one that calculates per-atom
 quantities.  Since it can time-average per-atom quantities produced by
 any "compute"_compute.html, "fix"_fix.html, or atom-style
 "variable"_variable.html, this allows those time-averaged results to
 be written to a dump file.
 If {f_ID} is used as a attribute, then the per-atom vector calculated
 by the fix is printed.  If {f_ID\[I\]} is used, then I must be in the
 range from 1-M, which will print the Ith column of the per-atom array
 with M columns calculated by the fix.  See the discussion above for
 how I can be specified with a wildcard asterisk to effectively specify
 multiple values.
 The {v_name} attribute allows per-atom vectors calculated by a
 "variable"_variable.html to be output.  The name in the attribute
 should be replaced by the actual name of the variable that has been
 defined previously in the input script.  Only an atom-style variable
 can be referenced, since it is the only style that generates per-atom
 values.  Variables of style {atom} can reference individual atom
 attributes, per-atom atom attributes, thermodynamic keywords, or
 invoke other computes, fixes, or variables when they are evaluated, so
 this is a very general means of creating quantities to output to a
 dump file.
 The {d_name} and {i_name} attributes allow to output custom per atom
 floating point or integer properties that are managed by
 "fix property/atom"_fix_property_atom.html.
 See "Section 10"_Section_modify.html of the manual for information
 on how to add new compute and fix styles to LAMMPS to calculate
 per-atom quantities which could then be output into dump files.
 :line
 [Restrictions:]
 The {custom/vtk} style does not support writing of gzipped dump files.
 The {custom/vtk} dump style is part of the USER-VTK 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.
 To use this dump style, you also must link to the VTK library.  See
 the info in lib/vtk/README and insure the Makefile.lammps file in that
 directory is appropriate for your machine.
 The {custom/vtk} dump style neither supports buffering nor custom
 format strings.
 [Related commands:]
 "dump"_dump.html, "dump image"_dump_image.html,
 "dump_modify"_dump_modify.html, "undump"_undump.html
 [Default:]
 By default, files are written in ASCII format. If the file extension
 is not one of .vtk, .vtp or .vtu, the legacy VTK file format is used.
--- a/doc/src/dump_h5md.txt
+++ b/doc/src/dump_h5md.txt
@ -17,9 +17,7 @@ group-ID = ID of the group of atoms to be imaged :l
 h5md = style of dump command (other styles {atom} or {cfg} or {dcd} or {xtc} or {xyz} or {local} or {custom} are discussed on the "dump"_dump.html doc page) :l
 N = dump every this many timesteps :l
 file.h5 = name of file to write to :l
-args = list of data elements to dump, with their dump "subintervals".
+args = list of data elements to dump, with their dump "subintervals"
 At least one element must be given and image may only be present if
 position is specified first. :l
  position options
  image
  velocity options
@ -29,15 +27,17 @@ position is specified first. :l
  box value = {yes} or {no}
  create_group value = {yes} or {no}
  author value = quoted string :pre
 :ule
-For the elements {position}, {velocity}, {force} and {species}, one
+Note that at least one element must be specified and image may only be
-may specify a sub-interval to write the data only every N_element
+present if position is specified first.
 For the elements {position}, {velocity}, {force} and {species}, a
 sub-interval may be specified to write the data only every N_element
 iterations of the dump (i.e. every N*N_element time steps). This is
-specified by the option
+specified by this option directly following the element declaration:
-  every N_element :pre
+every N_element :pre
 that follows directly the element declaration.
 :ule
--- a/doc/src/dump_modify.txt
+++ b/doc/src/dump_modify.txt
@ -16,7 +16,8 @@ dump-ID = ID of dump to modify :ulb,l
 one or more keyword/value pairs may be appended :l
 these keywords apply to various dump styles :l
 keyword = {append} or {buffer} or {element} or {every} or {fileper} or {first} or {flush} or {format} or {image} or {label} or {nfile} or {pad} or {precision} or {region} or {scale} or {sort} or {thresh} or {unwrap} :l
-  {append} arg = {yes} or {no}
+  {append} arg = {yes} or {no} or {at} N
    N = index of frame written upon first dump
  {buffer} arg = {yes} or {no}
  {element} args = E1 E2 ... EN, where N = # of atom types
    E1,...,EN = element name, e.g. C or Fe or Ga
@ -41,6 +42,7 @@ keyword = {append} or {buffer} or {element} or {every} or {fileper} or {first} o
  {region} arg = region-ID or "none"
  {scale} arg = {yes} or {no}
  {sfactor} arg = coordinate scaling factor (> 0.0)
  {thermo} arg = {yes} or {no}
  {tfactor} arg = time scaling factor (> 0.0)
  {sort} arg = {off} or {id} or N or -N
     off = no sorting of per-atom lines within a snapshot
@ -139,12 +141,13 @@ 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.  This keyword can only
+overwrite an existing file with the same name.  If the {at} option is present
-take effect if the dump_modify command is used after the
+({netcdf} only), then the frame to append to can be specified.  Negative values
-"dump"_dump.html command, but before the first command that causes
+are counted from the end of the file.  This keyword can only take effect if the
-dump snapshots to be output, e.g. a "run"_run.html or
+dump_modify command is used after the "dump"_dump.html command, but before the
-"minimize"_minimize.html command.  Once the dump file has been opened,
+first command that causes dump snapshots to be output, e.g. a "run"_run.html or
-this keyword has no further effect.
+"minimize"_minimize.html command.  Once the dump file has been opened, this
 keyword has no further effect.
 :line
@ -413,6 +416,13 @@ most effective when the typical magnitude of position data is between
 :line
 The {thermo} keyword ({netcdf} only) triggers writing of "thermo"_thermo.html
 information to the dump file alongside per-atom data. The data included in the
 dump file is identical to the data specified by
 "thermo_style"_thermo_style.html.
 :line
 The {region} keyword only applies to the dump {custom}, {cfg},
 {image}, and {movie} styles.  If specified, only atoms in the region
 will be written to the dump file or included in the image/movie.  Only
--- a/doc/src/dump_nc.txt
+++ b/doc/src/dump_nc.txt
@ -1,66 +0,0 @@
 "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
 :link(lc,Section_commands.html#comm)
 :line
 dump nc command :h3
 dump nc/mpiio command :h3
 [Syntax:]
 dump ID group-ID nc N file.nc args
 dump ID group-ID nc/mpiio N file.nc args :pre
 ID = user-assigned name for the dump :ulb,l
 group-ID = ID of the group of atoms to be imaged :l
 {nc} or {nc/mpiio}  = style of dump command (other styles {atom} or {cfg} or {dcd} or {xtc} or {xyz} or {local} or {custom} are discussed on the "dump"_dump.html doc page) :l
 N = dump every this many timesteps :l
 file.nc = name of file to write to :l
 args = list of per atom data elements to dump, same as for the 'custom' dump style. :l,ule
 [Examples:]
 dump 1 all nc 100 traj.nc type x y z vx vy vz
 dump_modify 1 append yes at -1 global c_thermo_pe c_thermo_temp c_thermo_press :pre
 dump 1 all nc/mpiio 1000 traj.nc id type x y z :pre
 [Description:]
 Dump a snapshot of atom coordinates every N timesteps in Amber-style
 NetCDF file format. NetCDF files are binary, portable and
 self-describing.  This dump style will write only one file on the root
 node.  The dump style {nc} uses the "standard NetCDF
 library"_netcdf-home all data is collected on one processor and then
 written to the dump file. Dump style {nc/mpiio} used the "parallel
 NetCDF library"_pnetcdf-home and MPI-IO; it has better performance on
 a larger number of processors. Note that 'nc' outputs all atoms sorted
 by atom tag while 'nc/mpiio' outputs in order of the MPI rank.
 In addition to per-atom data, also global (i.e. not per atom, but per
 frame) quantities can be included in the dump file. This can be
 variables, output from computes or fixes data prefixed with v_, c_ and
 f_, respectively.  These properties are included via
 "dump_modify"_dump_modify.html {global}.
 :link(netcdf-home,http://www.unidata.ucar.edu/software/netcdf/)
 :link(pnetcdf-home,http://trac.mcs.anl.gov/projects/parallel-netcdf/)
 :line
 [Restrictions:]
 The {nc} and {nc/mpiio} dump styles are part of the USER-NC-DUMP
 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.
 :line
 [Related commands:]
 "dump"_dump.html, "dump_modify"_dump_modify.html, "undump"_undump.html
--- a/doc/src/dump_netcdf.txt
+++ b/doc/src/dump_netcdf.txt
@ -0,0 +1,76 @@
 "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 netcdf command :h3
 dump netcdf/mpiio command :h3
 [Syntax:]
 dump ID group-ID netcdf N file args
 dump ID group-ID netcdf/mpiio N file args :pre
 ID = user-assigned name for the dump :ulb,l
 group-ID = ID of the group of atoms to be imaged :l
 {netcdf} or {netcdf/mpiio}  = style of dump command (other styles {atom} or {cfg} or {dcd} or {xtc} or {xyz} or {local} or {custom} are discussed on the "dump"_dump.html doc page) :l
 N = dump every this many timesteps :l
 file = name of file to write dump info to :l
 args = list of atom attributes, same as for "dump_style custom"_dump.html :l,ule
 [Examples:]
 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
 [Description:]
 Dump a snapshot of atom coordinates every N timesteps in Amber-style
 NetCDF file format.  NetCDF files are binary, portable and
 self-describing.  This dump style will write only one file on the root
 node.  The dump style {netcdf} uses the "standard NetCDF
 library"_netcdf-home.  All data is collected on one processor and then
 written to the dump file.  Dump style {netcdf/mpiio} uses the
 "parallel NetCDF library"_pnetcdf-home and MPI-IO to write to the dump
 file in parallel; it has better performance on a larger number of
 processors.  Note that style {netcdf} outputs all atoms sorted by atom
 tag while style {netcdf/mpiio} outputs atoms in order of their MPI
 rank.
 NetCDF files can be directly visualized via the following tools:
 Ovito (http://www.ovito.org/). Ovito supports the AMBER convention and
 all extensions of this dump style. :ule,b
 VMD (http://www.ks.uiuc.edu/Research/vmd/). :l
 AtomEye (http://www.libatoms.org/). The libAtoms version of AtomEye
 contains a NetCDF reader that is not present in the standard
 distribution of AtomEye. :l,ule
 In addition to per-atom data, "thermo"_thermo.html data can be included in the
 dump file. The data included in the dump file is identical to the data specified
 by "thermo_style"_thermo_style.html.
 :link(netcdf-home,http://www.unidata.ucar.edu/software/netcdf/)
 :link(pnetcdf-home,http://trac.mcs.anl.gov/projects/parallel-netcdf/)
 :line
 [Restrictions:]
 The {netcdf} and {netcdf/mpiio} dump styles are part of the
 USER-NETCDF 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.
 :line
 [Related commands:]
 "dump"_dump.html, "dump_modify"_dump_modify.html, "undump"_undump.html
--- a/doc/src/dump_vtk.txt
+++ b/doc/src/dump_vtk.txt
@ -0,0 +1,179 @@
 "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 vtk command :h3
 [Syntax:]
 dump ID group-ID vtk N file args :pre
 ID = user-assigned name for the dump
 group-ID = ID of the group of atoms to be dumped
 vtk = style of dump command (other styles {atom} or {cfg} or {dcd} or {xtc} or {xyz} or {local} or {custom} are discussed on the "dump"_dump.html doc page)
 N = dump every this many timesteps
 file = name of file to write dump info to 
 args = same as arguments for "dump_style custom"_dump.html :ul
 [Examples:]
 dump dmpvtk all vtk 100 dump*.myforce.vtk id type vx fx
 dump dmpvtp flow vtk 100 dump*.%.displace.vtp id type c_myD\[1\] c_myD\[2\] c_myD\[3\] v_ke :pre
 [Description:]
 Dump a snapshot of atom quantities to one or more files every N
 timesteps in a format readable by the "VTK visualization
 toolkit"_http://www.vtk.org or other visualization tools that use it,
 e.g. "ParaView"_http://www.paraview.org.  The timesteps on which dump
 output is written can also be controlled by a variable; see the
 "dump_modify every"_dump_modify.html command for details.
 This dump style is similar to "dump_style custom"_dump.html but uses
 the VTK library to write data to VTK simple legacy or XML format
 depending on the filename extension specified for the dump file.  This
 can be either {*.vtk} for the legacy format or {*.vtp} and {*.vtu},
 respectively, for XML format; see the "VTK
 homepage"_http://www.vtk.org/VTK/img/file-formats.pdf for a detailed
 description of these formats.  Since this naming convention conflicts
 with the way binary output is usually specified (see below), the
 "dump_modify binary"_dump_modify.html command allows setting of a
 binary option for this dump style explicitly.
 Only information for atoms in the specified group is dumped.  The
 "dump_modify thresh and region"_dump_modify.html commands can also
 alter what atoms are included; see details below.
 As described below, special characters ("*", "%") in the filename
 determine the kind of output.
 IMPORTANT NOTE: Because periodic boundary conditions are enforced only
 on timesteps when neighbor lists are rebuilt, the coordinates of an
 atom written to a dump file may be slightly outside the simulation
 box.
 IMPORTANT NOTE: Unless the "dump_modify sort"_dump_modify.html option
 is invoked, the lines of atom information written to dump files will
 be in an indeterminate order for each snapshot.  This is even true
 when running on a single processor, if the "atom_modify
 sort"_atom_modify.html option is on, which it is by default.  In this
 case atoms are re-ordered periodically during a simulation, due to
 spatial sorting.  It is also true when running in parallel, because
 data for a single snapshot is collected from multiple processors, each
 of which owns a subset of the atoms.
 For the {vtk} style, sorting is off by default. See the
 "dump_modify"_dump_modify.html doc page for details.
 :line
 The dimensions of the simulation box are written to a separate file
 for each snapshot (either in legacy VTK or XML format depending on the
 format of the main dump file) with the suffix {_boundingBox} appended
 to the given dump filename.
 For an orthogonal simulation box this information is saved as a
 rectilinear grid (legacy .vtk or .vtr XML format).
 Triclinic simulation boxes (non-orthogonal) are saved as
 hexahedrons in either legacy .vtk or .vtu XML format.
 Style {vtk} allows you to specify a list of atom attributes to be
 written to the dump file for each atom.  The list of possible attributes 
 is the same as for the "dump_style custom"_dump.html command; see
 its doc page for a listing and an explanation of each attribute.
 NOTE: Since position data is required to write VTK files the atom
 attributes "x y z" do not have to be specified explicitly; they will
 be included in the dump file regardless.  Also, in contrast to the
 {custom} style, the specified {vtk} attributes are rearranged to
 ensure correct ordering of vector components (except for computes and
 fixes - these have to be given in the right order) and duplicate
 entries are removed.
 The VTK format uses a single snapshot of the system per file, thus
 a wildcard "*" must be included in the filename, as discussed below.
 Otherwise the dump files will get overwritten with the new snapshot
 each time.
 :line
 Dumps are performed on timesteps that are a multiple of N (including
 timestep 0) and on the last timestep of a minimization if the
 minimization converges.  Note that this means a dump will not be
 performed on the initial timestep after the dump command is invoked,
 if the current timestep is not a multiple of N.  This behavior can be
 changed via the "dump_modify first"_dump_modify.html command, which
 can also be useful if the dump command is invoked after a minimization
 ended on an arbitrary timestep.  N can be changed between runs by
 using the "dump_modify every"_dump_modify.html command.
 The "dump_modify every"_dump_modify.html command
 also allows a variable to be used to determine the sequence of
 timesteps on which dump files are written.  In this mode a dump on the
 first timestep of a run will also not be written unless the
 "dump_modify first"_dump_modify.html command is used.
 Dump filenames can contain two wildcard characters.  If a "*"
 character appears in the filename, then one file per snapshot is
 written and the "*" character is replaced with the timestep value.
 For example, tmp.dump*.vtk becomes tmp.dump0.vtk, tmp.dump10000.vtk,
 tmp.dump20000.vtk, etc.  Note that the "dump_modify pad"_dump_modify.html
 command can be used to insure all timestep numbers are the same length
 (e.g. 00010), which can make it easier to read a series of dump files
 in order with some post-processing tools.
 If a "%" character appears in the filename, then each of P processors
 writes a portion of the dump file, and the "%" character is replaced
 with the processor ID from 0 to P-1 preceded by an underscore character.
 For example, tmp.dump%.vtp becomes tmp.dump_0.vtp, tmp.dump_1.vtp, ...
 tmp.dump_P-1.vtp, etc.  This creates smaller files and can be a fast
 mode of output on parallel machines that support parallel I/O for output.
 By default, P = the number of processors meaning one file per
 processor, but P can be set to a smaller value via the {nfile} or
 {fileper} keywords of the "dump_modify"_dump_modify.html command.
 These options can be the most efficient way of writing out dump files
 when running on large numbers of processors.
 For the legacy VTK format "%" is ignored and P = 1, i.e., only
 processor 0 does write files.
 Note that using the "*" and "%" characters together can produce a
 large number of small dump files!
 If {dump_modify binary} is used, the dump file (or files, if "*" or
 "%" is also used) is written in binary format.  A binary dump file
 will be about the same size as a text version, but will typically
 write out much faster.
 :line
 [Restrictions:]
 The {vtk} style does not support writing of gzipped dump files.
 The {vtk} dump style is part of the USER-VTK 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.
 To use this dump style, you also must link to the VTK library.  See
 the info in lib/vtk/README and insure the Makefile.lammps file in that
 directory is appropriate for your machine.
 The {vtk} dump style supports neither buffering or custom format
 strings.
 [Related commands:]
 "dump"_dump.html, "dump image"_dump_image.html,
 "dump_modify"_dump_modify.html, "undump"_undump.html
 [Default:]
 By default, files are written in ASCII format. If the file extension
 is not one of .vtk, .vtp or .vtu, the legacy VTK file format is used.
--- a/doc/src/fix_adapt.txt
+++ b/doc/src/fix_adapt.txt
@ -47,7 +47,7 @@ keyword = {scale} or {reset} :l
 fix 1 all adapt 1 pair soft a 1 1 v_prefactor
 fix 1 all adapt 1 pair soft a 2* 3 v_prefactor
 fix 1 all adapt 1 pair lj/cut epsilon * * v_scale1 coul/cut scale 3 3 v_scale2 scale yes reset yes
-fix 1 all adapt 10 atom diameter v_size
+fix 1 all adapt 10 atom diameter v_size :pre
 variable ramp_up equal "ramp(0.01,0.5)"
 fix stretch all adapt 1 bond harmonic r0 1 v_ramp_up :pre
--- a/doc/src/fix_box_relax.txt
+++ b/doc/src/fix_box_relax.txt
@ -245,8 +245,8 @@ appear the system is converging to your specified pressure.  The
 solution for this is to either (a) zero the velocities of all atoms
 before performing the minimization, or (b) make sure you are
 monitoring the pressure without its kinetic component.  The latter can
-be done by outputting the pressure from the fix this command creates
+be done by outputting the pressure from the pressure compute this 
-(see below) or a pressure fix you define yourself.
+command creates (see below) or a pressure compute you define yourself.
 NOTE: Because pressure is often a very sensitive function of volume,
 it can be difficult for the minimizer to equilibrate the system the
@ -308,7 +308,7 @@ thermo_modify command (or in two separate commands), then the order in
 which the keywords are specified is important.  Note that a "pressure
 compute"_compute_pressure.html defines its own temperature compute as
 an argument when it is specified.  The {temp} keyword will override
-this (for the pressure compute being used by fix npt), but only if the
+this (for the pressure compute being used by fix box/relax), but only if the
 {temp} keyword comes after the {press} keyword.  If the {temp} keyword
 comes before the {press} keyword, then the new pressure compute
 specified by the {press} keyword will be unaffected by the {temp}
@ -316,18 +316,16 @@ setting.
 This fix computes a global scalar which can be accessed by various
 "output commands"_Section_howto.html#howto_15. The scalar is the
-pressure-volume energy, plus the strain energy, if it exists.
+pressure-volume energy, plus the strain energy, if it exists,
-
+as described above.
-This fix computes a global scalar which can be accessed by various
+The energy values reported at the
-"output commands"_Section_howto.html#howto_15. The scalar is given
+end of a minimization run under "Minimization stats" include this
-by the energy expression shown above. The energy values reported
+energy, and so differ from what LAMMPS normally reports as potential
-at the end of a minimization run under "Minimization stats" include
+energy. This fix does not support the "fix_modify"_fix_modify.html
-this energy, and so differ from what LAMMPS normally reports as
+{energy} option, because that would result in double-counting of the
-potential energy. This fix does not support the
+fix energy in the minimization energy. Instead, the fix energy can be
-"fix_modify"_fix_modify.html {energy} option,
+explicitly added to the potential energy using one of these two
-because that would result in double-counting of the fix energy in the
+variants:
 minimization energy. Instead, the fix energy can be explicitly
 added to the potential energy using one of these two variants:
 variable emin equal pe+f_1  :pre
--- a/doc/src/fix_cmap.txt
+++ b/doc/src/fix_cmap.txt
@ -87,8 +87,11 @@ the note below about how to include the CMAP energy when performing an
 [Restart, fix_modify, output, run start/stop, minimize info:]
-No information about this fix is written to "binary restart
+This fix writes the list of CMAP crossterms to "binary restart
-files"_restart.html.
+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.
 The "fix_modify"_fix_modify.html {energy} option is supported by this
 fix to add the potential "energy" of the CMAP interactions system's
--- a/doc/src/fix_deform.txt
+++ b/doc/src/fix_deform.txt
@ -565,8 +565,10 @@ more instructions on how to use the accelerated styles effectively.
 [Restart, fix_modify, output, run start/stop, minimize info:]
-No information about this fix is written to "binary restart
+This fix will restore the initial box settings from "binary restart
-files"_restart.html.  None of the "fix_modify"_fix_modify.html options
+files"_restart.html, which allows the fix to be properly continue
 deformation, when using the start/stop options of the "run"_run.html
 command.  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.
--- a/doc/src/fix_gcmc.txt
+++ b/doc/src/fix_gcmc.txt
@ -317,7 +317,7 @@ solution is to start a new simulation after the equilibrium density
 has been reached.
 With some pair_styles, such as "Buckingham"_pair_buck.html,
-"Born-Mayer-Huggins"_pair_born.html and "ReaxFF"_pair_reax_c.html, two
+"Born-Mayer-Huggins"_pair_born.html and "ReaxFF"_pair_reaxc.html, two
 atoms placed close to each other may have an arbitrary large, negative
 potential energy due to the functional form of the potential.  While
 these unphysical configurations are inaccessible to typical dynamical
--- a/doc/src/fix_gle.txt
+++ b/doc/src/fix_gle.txt
@ -67,9 +67,10 @@ target value as the {Tstart} and {Tstop} arguments, so that the diffusion
 matrix that gives canonical sampling for a given A is computed automatically.
 However, the GLE framework also allow for non-equilibrium sampling, that
 can be used for instance to model inexpensively zero-point energy
-effects "(Ceriotti2)"_#Ceriotti2. This is achieved specifying the
+effects "(Ceriotti2)"_#Ceriotti2. This is achieved specifying the {noneq}
-{noneq} keyword followed by the name of the file that contains the
+keyword followed by the name of the file that contains the static covariance
-static covariance matrix for the non-equilibrium dynamics.
+matrix for the non-equilibrium dynamics.  Please note, that the covariance
 matrix is expected to be given in [temperature units].
 Since integrating GLE dynamics can be costly when used together with
 simple potentials, one can use the {every} optional keyword to
@ -148,7 +149,7 @@ dpd/tstat"_pair_dpd.html, "fix gld"_fix_gld.html
 1170-80 (2010)
 :link(GLE4MD)
-[(GLE4MD)] "http://epfl-cosmo.github.io/gle4md/"_http://epfl-cosmo.github.io/gle4md/
+[(GLE4MD)] "http://gle4md.org/"_http://gle4md.org/
 :link(Ceriotti2)
 [(Ceriotti2)] Ceriotti, Bussi and Parrinello, Phys Rev Lett 103,
--- a/doc/src/fix_langevin_drude.txt
+++ b/doc/src/fix_langevin_drude.txt
@ -67,11 +67,11 @@ The Langevin forces are computed as
 \(F_r'\) is a random force proportional to
 \(\sqrt \{ \frac \{2\, k_B \mathtt\{Tcom\}\, m'\}
                 \{\mathrm dt\, \mathtt\{damp\_com\} \}
-        \} \). :b
+        \} \).
 \(f_r'\) is a random force proportional to
 \(\sqrt \{ \frac \{2\, k_B \mathtt\{Tdrude\}\, m'\}
                 \{\mathrm dt\, \mathtt\{damp\_drude\} \}
-        \} \). :b
+        \} \).
 Then the real forces acting on the particles are computed from the inverse
 transform:
 \begin\{equation\} F = \frac M \{M'\}\, F' - f' \end\{equation\}
--- a/doc/src/fix_neb.txt
+++ b/doc/src/fix_neb.txt
@ -10,68 +10,183 @@ fix neb command :h3
 [Syntax:]
-fix ID group-ID neb Kspring :pre
+fix ID group-ID neb Kspring keyword value :pre
-ID, group-ID are documented in "fix"_fix.html command
+ID, group-ID are documented in "fix"_fix.html command :ulb,l
-neb = style name of this fix command
+neb = style name of this fix command :l
-Kspring = inter-replica spring constant (force/distance units) :ul
+Kspring = spring constant for parallel nudging force (force/distance units or force units, see parallel keyword) :l
 zero or more keyword/value pairs may be appended :l
 keyword = {parallel} or {perp} or {end} :l
  {parallel} value = {neigh} or {ideal}
    {neigh} = parallel nudging force based on distance to neighbor replicas (Kspring = force/distance units)
    {ideal} = parallel nudging force based on interpolated ideal position (Kspring = force units)
  {perp} value = {Kspring2}
    {Kspring2} = spring constant for perpendicular nudging force (force/distance units)
  {end} values = estyle Kspring3
    {estyle} = {first} or {last} or {last/efirst} or {last/efirst/middle}
      {first} = apply force to first replica
      {last} = apply force to last replica
      {last/efirst} = apply force to last replica and set its target energy to that of first replica
      {last/efirst/middle} = same as {last/efirst} plus prevent middle replicas having lower energy than first replica
    {Kspring3} = spring constant for target energy term (1/distance units) :pre,ule
 [Examples:]
-fix 1 active neb 10.0 :pre
+fix 1 active neb 10.0
 fix 2 all neb 1.0 perp 1.0 end last
 fix 2 all neb 1.0 perp 1.0 end first 1.0 end last 1.0
 fix 1 all neb 1.0 nudge ideal end last/efirst 1 :pre
 [Description:]
-Add inter-replica forces to atoms in the group for a multi-replica
+Add nudging forces to atoms in the group for a multi-replica
 simulation run via the "neb"_neb.html command to perform a nudged
-elastic band (NEB) calculation for transition state finding.  Hi-level
+elastic band (NEB) calculation for finding the transition state.
-explanations of NEB are given with the "neb"_neb.html command and in
+Hi-level explanations of NEB are given with the "neb"_neb.html command
-"Section 6.5"_Section_howto.html#howto_5 of the manual.  The fix
+and in "Section_howto 5"_Section_howto.html#howto_5 of the manual.
-neb command must be used with the "neb" command to define how
+The fix neb command must be used with the "neb" command and defines
-inter-replica forces are computed.
+how inter-replica nudging forces are computed.  A NEB calculation is
 divided in two stages. In the first stage n replicas are relaxed
 toward a MEP until convergence.  In the second stage, the climbing
 image scheme (see "(Henkelman2)"_#Henkelman2) is enabled, so that the
 replica having the highest energy relaxes toward the saddle point
 (i.e. the point of highest energy along the MEP), and a second
 relaxation is performed.
-Only the N atoms in the fix group experience inter-replica forces.
+A key purpose of the nudging forces is to keep the replicas equally
-Atoms in the two end-point replicas do not experience these forces,
+spaced.  During the NEB calculation, the 3N-length vector of
-but those in intermediate replicas do.  During the initial stage of
+interatomic force Fi = -Grad(V) for each replica I is altered.  For
-NEB, the 3N-length vector of interatomic forces Fi = -Grad(V) acting
+all intermediate replicas (i.e. for 1 < I < N, except the climbing
-on the atoms of each intermediate replica I is altered, as described
+replica) the force vector becomes:
 in the "(Henkelman1)"_#Henkelman1 paper, to become:
-Fi = -Grad(V) + (Grad(V) dot That) That + Kspring (| Ri+i - Ri | - | Ri - Ri-1 |) That :pre
+Fi = -Grad(V) + (Grad(V) dot T') T' + Fnudge_parallel + Fnudge_perp :pre
-Ri are the atomic coordinates of replica I; Ri-1 and Ri+1 are the
+T' is the unit "tangent" vector for replica I and is a function of Ri,
 coordinates of its neighbor replicas.  That (t with a hat over it) is
 the unit "tangent" vector for replica I which is a function of Ri,
 Ri-1, Ri+1, and the potential energy of the 3 replicas; it points
 roughly in the direction of (Ri+i - Ri-1); see the
-"(Henkelman1)"_#Henkelman1 paper for details.
+"(Henkelman1)"_#Henkelman1 paper for details.  Ri are the atomic
 coordinates of replica I; Ri-1 and Ri+1 are the coordinates of its
 neighbor replicas.  The term (Grad(V) dot T') is used to remove the
 component of the gradient parallel to the path which would tend to
 distribute the replica unevenly along the path.  Fnudge_parallel is an
 artificial nudging force which is applied only in the tangent
 direction and which maintains the equal spacing between replicas (see
 below for more information).  Fnudge_perp is an optional artificial
 spring which is applied in a direction perpendicular to the tangent
 direction and which prevent the paths from forming acute kinks (see
 below for more information).
-The first two terms in the above equation are the component of the
+In the second stage of the NEB calculation, the interatomic force Fi
-interatomic forces perpendicular to the tangent vector.  The last term
+for the climbing replica (the replica of highest energy after the
-is a spring force between replica I and its neighbors, parallel to the
+first stage) is changed to:
 tangent vector direction with the specified spring constant {Kspring}.
-The effect of the first two terms is to push the atoms of each replica
+Fi = -Grad(V) + 2 (Grad(V) dot T') T' :pre
 toward the minimum energy path (MEP) of conformational states that
 transition over the energy barrier.  The MEP for an energy barrier is
 defined as a sequence of 3N-dimensional states which cross the barrier
 at its saddle point, each of which has a potential energy gradient
 parallel to the MEP itself.
-The effect of the last term is to push each replica away from its two
+and the relaxation procedure is continued to a new converged MEP.
 neighbors in a direction along the MEP, so that the final set of
 states are equidistant from each other.
-During the second stage of NEB, the forces on the N atoms in the
+:line
 replica nearest the top of the energy barrier are altered so that it
 climbs to the top of the barrier and finds the saddle point.  The
 forces on atoms in this replica are described in the
 "(Henkelman2)"_#Henkelman2 paper, and become:
-Fi = -Grad(V) + 2 (Grad(V) dot That) That :pre
+The keyword {parallel} specifies how the parallel nudging force is
 computed.  With a value of {neigh}, the parallel nudging force is
 computed as in "(Henkelman1)"_#Henkelman1 by connecting each
 intermediate replica with the previous and the next image:
-The inter-replica forces for the other replicas are unchanged from the
+Fnudge_parallel = {Kspring} * (|Ri+1 - Ri| - |Ri - Ri-1|) :pre
-first equation.
+
 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
 "(WeinenE)"_#WeinenE :
 Fnudge_parallel = -{Kspring} * (RD-RDideal) / (2 * meanDist) :pre
 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
 in force units.
 Note that the {ideal} form of nudging can often be more effective at
 keeping the replicas equally spaced.
 :line
 The keyword {perp} specifies if and how a perpendicual 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
 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.
 The perpendicular spring force is given by
 Fnudge_perp = {Kspring2} * F(Ri-1,Ri,Ri+1) (Ri+1 + Ri-1 - 2 Ri) :pre
 where {Kspring2} is the specified value.  F(Ri-1 Ri R+1) is a smooth
 scalar function of the angle Ri-1 Ri Ri+1.  It is equal to 0.0 when
 the path is straight and is equal to 1 when the angle Ri-1 Ri Ri+1 is
 acute.  F(Ri-1 Ri R+1) is defined in "(Jonsson)"_#Jonsson.
 If {Kspring2} is set to 0.0 (the default) then no perpendicular spring
 force is added.
 :line
 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.
 The interatomic force Fi for the specified replica becomes:
 Fi = -Grad(V) + (Grad(V) dot T' + (E-ETarget)*Kspring3) T',  {when} Grad(V) dot T' < 0
 Fi = -Grad(V) + (Grad(V) dot T' + (ETarget- E)*Kspring3) T', {when} Grad(V) dot T' > 0
 :pre
 where E is the current energy of the replica and ETarget is the target
 energy.  The "spring" constant on the difference in energies is the
 specified {Kspring3} value.
 When {estyle} is specified as {first}, the force is applied to the
 first replica.  When {estyle} is specified as {last}, the force is
 applied to the last replica.  Note that the {end} keyword can be used
 twice to add forces to both the first and last replicas.
 For both these {estyle} settings, the target energy {ETarget} is set
 to the initial energy of the replica (at the start of the NEB
 calculation).
 If the {estyle} is specified as {last/efirst} or {last/efirst/middle},
 force is applied to the last replica, but the target energy {ETarget}
 is continuously set to the energy of the first replica, as it evolves
 during the NEB relaxation.
 The difference between these two {estyle} options is as follows.  When
 {estyle} is specified as {last/efirst}, no change is made to the
 inter-replica force applied to the intermediate replicas (neither
 first or last).  If the initial path is too far from the MEP, an
 intermediate repilica may relax "faster" and reach a lower energy than
 the last replica.  In this case the intermediate replica will be
 relaxing toward its own local minima.  This behavior can be prevented
 by specifying {estyle} as {last/efirst/middle} which will alter the
 inter-replica force applied to intermediate replicas by removing the
 contribution of the gradient to the inter-replica force.  This will
 only be done if a particular intermediate replica has a lower energy
 than the first replica.  This should effectively prevent the
 intermediate replicas from over-relaxing.
 After converging a NEB calculation using an {estyle} of
 {last/efirst/middle}, you should check that all intermediate replicas
 have a larger energy than the first replica. If this is not the case,
 the path is probably not a MEP.
 Finally, note that if the last replica converges toward a local
 minimum which has a larger energy than the energy of the first
 replica, a NEB calculation using an {estyle} of {last/efirst} or
 {last/efirst/middle} cannot reach final convergence.
 [Restart, fix_modify, output, run start/stop, minimize info:]
@ -96,7 +211,12 @@ for more info on packages.
 "neb"_neb.html
-[Default:] none
+[Default:]
 The option defaults are nudge = neigh, perp = 0.0, ends is not
 specified (no inter-replica force on the end replicas).
 :line
 :link(Henkelman1)
 [(Henkelman1)] Henkelman and Jonsson, J Chem Phys, 113, 9978-9985 (2000).
@ -104,3 +224,15 @@ for more info on packages.
 :link(Henkelman2)
 [(Henkelman2)] Henkelman, Uberuaga, Jonsson, J Chem Phys, 113,
 9901-9904 (2000).
 :link(WeinenE)
 [(WeinenE)] E, Ren, Vanden-Eijnden, Phys Rev B, 66, 052301 (2002).
 :link(Jonsson)
 [(Jonsson)] Jonsson, Mills and Jacobsen, in Classical and Quantum
 Dynamics in Condensed Phase Simulations, edited by Berne, Ciccotti,
 and Coker World Scientific, Singapore, 1998, p 385.
 :link(Maras1)
 [(Maras)] Maras, Trushin, Stukowski, Ala-Nissila, Jonsson,
 Comp Phys Comm, 205, 13-21 (2016).
--- a/doc/src/fix_python.txt
+++ b/doc/src/fix_python.txt
@ -0,0 +1,76 @@
 "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 command :h3
 [Syntax:]
 fix ID group-ID python N callback function_name :pre
 ID, group-ID are ignored by this fix :ulb,l
 python = 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
  {end_of_step} = callback after every N time steps :pre
 :ule
 [Examples:]
 python post_force_callback here """
 from lammps import lammps :pre
 def post_force_callback(lammps_ptr, vflag):
    lmp = lammps(ptr=lammps_ptr)
    # access LAMMPS state using Python interface
 """ :pre
 python end_of_step_callback here """
 def end_of_step_callback(lammps_ptr):
    lmp = lammps(ptr=lammps_ptr)
    # access LAMMPS state using Python interface
 """ :pre
 fix pf  all python 50 post_force post_force_callback
 fix eos all python 50 end_of_step end_of_step_callback :pre
 [Description:]
 This fix allows you to call a Python function during a simulation run.
 The callback is either executed after forces have been applied to atoms
 or at the end of every N time steps.
 Callback functions must be declared in the global scope of the
 active Python interpreter. This can either be done by defining it
 inline using the python command or by importing functions from other
 Python modules. If LAMMPS is driven using the library interface from
 Python, functions defined in the driving Python interpreter can also
 be executed.
 Each callback is given a pointer object as first argument. This can be
 used to initialize an instance of the lammps Python interface, which
 gives access to the LAMMPS state from Python.
 IMPORTANT NOTE: While you can access the state of LAMMPS via library functions
 from these callbacks, trying to execute input script commands will in the best
 case not work or in the worst case result in undefined behavior.
 [Restrictions:]
 This fix 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.
 Building LAMMPS with the PYTHON package will link LAMMPS with the
 Python library on your system.  Settings to enable this are in the
 lib/python/Makefile.lammps file.  See the lib/python/README file for
 information on those settings.
 [Related commands:]
 "python command"_python.html
--- a/doc/src/fix_qeq.txt
+++ b/doc/src/fix_qeq.txt
@ -74,7 +74,7 @@ NOTE: The "fix qeq/comb"_fix_qeq_comb.html command must still be used
 to perform charge equilibration with the "COMB
 potential"_pair_comb.html.  The "fix qeq/reax"_fix_qeq_reax.html
 command can be used to perform charge equilibration with the "ReaxFF
-force field"_pair_reax_c.html, although fix qeq/shielded yields the
+force field"_pair_reaxc.html, although fix qeq/shielded yields the
 same results as fix qeq/reax if {Nevery}, {cutoff}, and {tolerance}
 are the same.  Eventually the fix qeq/reax command will be deprecated.
@ -116,7 +116,7 @@ the shielded Coulomb is given by equation (13) of the "ReaxFF force
 field"_#vanDuin paper.  The shielding accounts for charge overlap
 between charged particles at small separation.  This style is the same
 as "fix qeq/reax"_fix_qeq_reax.html, and can be used with "pair_style
-reax/c"_pair_reax_c.html.  Only the {chi}, {eta}, and {gamma}
+reax/c"_pair_reaxc.html.  Only the {chi}, {eta}, and {gamma}
 parameters from the {qfile} file are used.  This style solves partial
 charges on atoms via the matrix inversion method.  A tolerance of
 1.0e-6 is usually a good number.
--- a/doc/src/fix_qeq_reax.txt
+++ b/doc/src/fix_qeq_reax.txt
@ -8,17 +8,19 @@
 fix qeq/reax command :h3
 fix qeq/reax/kk command :h3
 fix qeq/reax/omp command :h3
 [Syntax:]
-fix ID group-ID qeq/reax Nevery cutlo cuthi tolerance params :pre
+fix ID group-ID qeq/reax Nevery cutlo cuthi tolerance params args :pre
 ID, group-ID are documented in "fix"_fix.html command
 qeq/reax = style name of this fix command
 Nevery = perform QEq every this many steps
 cutlo,cuthi = lo and hi cutoff for Taper radius
 tolerance = precision to which charges will be equilibrated
-params = reax/c or a filename :ul
+params = reax/c or a filename
 args   = {dual} (optional) :ul
 [Examples:]
@ -30,7 +32,7 @@ fix 1 all qeq/reax 1 0.0 10.0 1.0e-6 param.qeq :pre
 Perform the charge equilibration (QEq) method as described in "(Rappe
 and Goddard)"_#Rappe2 and formulated in "(Nakano)"_#Nakano2.  It is
 typically used in conjunction with the ReaxFF force field model as
-implemented in the "pair_style reax/c"_pair_reax_c.html command, but
+implemented in the "pair_style reax/c"_pair_reaxc.html command, but
 it can be used with any potential in LAMMPS, so long as it defines and
 uses charges on each atom.  The "fix qeq/comb"_fix_qeq_comb.html
 command should be used to perform charge equilibration with the "COMB
@ -42,7 +44,7 @@ The QEq method minimizes the electrostatic energy of the system by
 adjusting the partial charge on individual atoms based on interactions
 with their neighbors.  It requires some parameters for each atom type.
 If the {params} setting above is the word "reax/c", then these are
-extracted from the "pair_style reax/c"_pair_reax_c.html command and
+extracted from the "pair_style reax/c"_pair_reaxc.html command and
 the ReaxFF force field file it reads in.  If a file name is specified
 for {params}, then the parameters are taken from the specified file
 and the file must contain one line for each atom type.  The latter
@ -59,6 +61,10 @@ potential file, except that eta is defined here as twice the eta value
 in the ReaxFF file. Note that unlike the rest of LAMMPS, the units
 of this fix are hard-coded to be A, eV, and electronic charge.
 The optional {dual} keyword allows to perform the optimization
 of the S and T matrices in parallel. This is only supported for
 the {qeq/reax/omp} style. Otherwise they are processed separately.
 [Restart, fix_modify, output, run start/stop, minimize info:]
 No information about this fix is written to "binary restart
@ -106,7 +112,7 @@ be used for periodic cell dimensions less than 10 angstroms.
 [Related commands:]
-"pair_style reax/c"_pair_reax_c.html
+"pair_style reax/c"_pair_reaxc.html
 [Default:] none
--- a/doc/src/fix_reax_bonds.txt
+++ b/doc/src/fix_reax_bonds.txt
@ -28,13 +28,30 @@ fix 1 all reax/c/bonds 100 bonds.reaxc :pre
 Write out the bond information computed by the ReaxFF potential
 specified by "pair_style reax"_pair_reax.html or "pair_style
-reax/c"_pair_reax_c.html in the exact same format as the original
+reax/c"_pair_reaxc.html in the exact same format as the original
 stand-alone ReaxFF code of Adri van Duin.  The bond information is
 written to {filename} on timesteps that are multiples of {Nevery},
 including timestep 0.  For time-averaged chemical species analysis,
 please see the "fix reaxc/c/species"_fix_reaxc_species.html command.
-The format of the output file should be self-explanatory.
+The format of the output file should be reasonably self-explanatory.
 The meaning of the column header abbreviations is as follows:
 id = atom id
 type = atom type
 nb = number of bonds
 id_1 = atom id of first bond
 id_nb = atom id of Nth bond
 mol = molecule id
 bo_1 = bond order of first bond
 bo_nb = bond order of Nth bond
 abo = atom bond order (sum of all bonds)
 nlp = number of lone pairs
 q = atomic charge :ul
 If the filename ends with ".gz", the output file is written in gzipped
 format.  A gzipped dump file will be about 3x smaller than the text
 version, but will also take longer to write.
 :line
@ -80,14 +97,17 @@ reax"_pair_reax.html be invoked.  This fix is part of the REAX
 package.  It is only enabled if LAMMPS was built with that package,
 which also requires the REAX library be built and linked with LAMMPS.
 The fix reax/c/bonds command requires that the "pair_style
-reax/c"_pair_reax_c.html be invoked.  This fix is part of the
+reax/c"_pair_reaxc.html be invoked.  This fix is part of the
 USER-REAXC 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.
 To write gzipped bond files, you must compile LAMMPS with the
 -DLAMMPS_GZIP option.
 [Related commands:]
 "pair_style reax"_pair_reax.html, "pair_style
-reax/c"_pair_reax_c.html, "fix reax/c/species"_fix_reaxc_species.html
+reax/c"_pair_reaxc.html, "fix reax/c/species"_fix_reaxc_species.html
 [Default:] none
--- a/doc/src/fix_reaxc_species.txt
+++ b/doc/src/fix_reaxc_species.txt
@ -41,7 +41,7 @@ fix 1 all reax/c/species 1 100 100 species.out element Au O H position 1000 AuOH
 [Description:]
 Write out the chemical species information computed by the ReaxFF
-potential specified by "pair_style reax/c"_pair_reax_c.html.
+potential specified by "pair_style reax/c"_pair_reaxc.html.
 Bond-order values (either averaged or instantaneous, depending on
 value of {Nrepeat}) are used to determine chemical bonds.  Every
 {Nfreq} timesteps, chemical species information is written to
@ -52,6 +52,10 @@ number of molecules of each species.  In this context, "species" means
 a unique molecule.  The chemical formula of each species is given in
 the first line.
 If the filename ends with ".gz", the output file is written in gzipped
 format.  A gzipped dump file will be about 3x smaller than the text version,
 but will also take longer to write.
 Optional keyword {cutoff} can be assigned to change the minimum
 bond-order values used in identifying chemical bonds between pairs of
 atoms.  Bond-order cutoffs should be carefully chosen, as bond-order
@ -65,7 +69,7 @@ symbol printed for each LAMMPS atom type. The number of symbols must
 match the number of LAMMPS atom types and each symbol must consist of
 1 or 2 alphanumeric characters. Normally, these symbols should be
 chosen to match the chemical identity of each LAMMPS atom type, as
-specified using the "reax/c pair_coeff"_pair_reax_c.html command and
+specified using the "reax/c pair_coeff"_pair_reaxc.html command and
 the ReaxFF force field file.
 The optional keyword {position} writes center-of-mass positions of
@ -158,19 +162,22 @@ more instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 The fix species currently only works with
-"pair_style reax/c"_pair_reax_c.html and it requires that the "pair_style
+"pair_style reax/c"_pair_reaxc.html and it requires that the "pair_style
-reax/c"_pair_reax_c.html be invoked.  This fix is part of the
+reax/c"_pair_reaxc.html be invoked.  This fix is part of the
 USER-REAXC 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.
 To write gzipped species files, you must compile LAMMPS with the
 -DLAMMPS_GZIP option.
 It should be possible to extend it to other reactive pair_styles (such as
 "rebo"_pair_airebo.html, "airebo"_pair_airebo.html,
 "comb"_pair_comb.html, and "bop"_pair_bop.html), but this has not yet been done.
 [Related commands:]
-"pair_style reax/c"_pair_reax_c.html, "fix
+"pair_style reax/c"_pair_reaxc.html, "fix
 reax/bonds"_fix_reax_bonds.html
 [Default:]
--- a/doc/src/fix_rigid.txt
+++ b/doc/src/fix_rigid.txt
@ -31,11 +31,12 @@ bodystyle = {single} or {molecule} or {group} :l
    groupID1, groupID2, ... = list of N group IDs :pre
 zero or more keyword/value pairs may be appended :l
-keyword = {langevin} or {temp} or {iso} or {aniso} or {x} or {y} or {z} or {couple} or {tparam} or {pchain} or {dilate} or {force} or {torque} or {infile} :l
+keyword = {langevin} or {reinit} or {temp} or {iso} or {aniso} or {x} or {y} or {z} or {couple} or {tparam} or {pchain} or {dilate} or {force} or {torque} or {infile} :l
  {langevin} values = Tstart Tstop Tperiod seed
    Tstart,Tstop = desired temperature at start/stop of run (temperature units)
    Tdamp = temperature damping parameter (time units)
    seed = random number seed to use for white noise (positive integer)
  {reinit} = {yes} or {no}
  {temp} values = Tstart Tstop Tdamp
    Tstart,Tstop = desired temperature at start/stop of run (temperature units)
    Tdamp = temperature damping parameter (time units)
@ -68,10 +69,10 @@ keyword = {langevin} or {temp} or {iso} or {aniso} or {x} or {y} or {z} or {coup
 [Examples:]
-fix 1 clump rigid single
+fix 1 clump rigid single reinit yes
 fix 1 clump rigid/small molecule
 fix 1 clump rigid single force 1 off off on langevin 1.0 1.0 1.0 428984
-fix 1 polychains rigid/nvt molecule temp 1.0 1.0 5.0
+fix 1 polychains rigid/nvt molecule temp 1.0 1.0 5.0 reinit no
 fix 1 polychains rigid molecule force 1*5 off off off force 6*10 off off on
 fix 1 polychains rigid/small molecule langevin 1.0 1.0 1.0 428984
 fix 2 fluid rigid group 3 clump1 clump2 clump3 torque * off off off
@ -87,7 +88,12 @@ means that each timestep the total force and torque on each rigid body
 is computed as the sum of the forces and torques on its constituent
 particles.  The coordinates, velocities, and orientations of the atoms
 in each body are then updated so that the body moves and rotates as a
-single entity.
+single entity.  This is implemented by creating internal data structures
 for each rigid body and performing time integration on these data
 structures.  Positions, velocities, and orientations of the constituent
 particles are regenerated from the rigid body data structures in every
 time step. This restricts which operations and fixes can be applied to
 rigid bodies. See below for a detailed discussion.
 Examples of large rigid bodies are a colloidal particle, or portions
 of a biomolecule such as a protein.
@ -148,8 +154,9 @@ differences may accumulate to produce divergent trajectories.
 NOTE: You should not update the atoms in rigid bodies via other
 time-integration fixes (e.g. "fix nve"_fix_nve.html, "fix
-nvt"_fix_nh.html, "fix npt"_fix_nh.html), or you will be integrating
+nvt"_fix_nh.html, "fix npt"_fix_nh.html, "fix move"_fix_move.html),
-their motion more than once each timestep.  When performing a hybrid
+or you will have conflicting updates to positions and velocities
 resulting in unphysical behavior in most cases. When performing a hybrid
 simulation with some atoms in rigid bodies, and some not, a separate
 time integration fix like "fix nve"_fix_nve.html or "fix
 nvt"_fix_nh.html should be used for the non-rigid particles.
@ -165,23 +172,29 @@ setting the force on them to 0.0 (via the "fix
 setforce"_fix_setforce.html command), and integrating them as usual
 (e.g. via the "fix nve"_fix_nve.html command).
-NOTE: The aggregate properties of each rigid body are calculated one
+IMPORTANT NOTE: The aggregate properties of each rigid body are
-time at the start of the first simulation run after these fixes are
+calculated at the start of a simulation run and are maintained in
-specified.  The properties include the position and velocity of the
+internal data structures. The properties include the position and
-center-of-mass of the body, its moments of inertia, and its angular
+velocity of the center-of-mass of the body, its moments of inertia, and
-momentum.  This is done using the properties of the constituent atoms
+its angular momentum.  This is done using the properties of the
-of the body at that point in time (or see the {infile} keyword
+constituent atoms of the body at that point in time (or see the {infile}
-option).  Thereafter, changing properties of individual atoms in the
+keyword option).  Thereafter, changing these properties of individual
-body will have no effect on a rigid body's dynamics, unless they
+atoms in the body will have no effect on a rigid body's dynamics, unless
-affect the "pair_style"_pair_style.html interactions that individual
+they effect any computation of per-atom forces or torques. If the
-particles are part of.  For example, you might think you could
+keyword {reinit} is set to {yes} (the default), the rigid body data
-displace the atoms in a body or add a large velocity to each atom in a
+structures will be recreated at the beginning of each {run} command;
-body to make it move in a desired direction before a 2nd run is
+if the keyword {reinit} is set to {no}, the rigid body data structures
 will be built only at the very first {run} command and maintained for
 as long as the rigid fix is defined. For example, you might think you
 could displace the atoms in a body or add a large velocity to each atom
 in a body to make it move in a desired direction before a 2nd run is
 performed, using the "set"_set.html or
 "displace_atoms"_displace_atoms.html or "velocity"_velocity.html
-command.  But these commands will not affect the internal attributes
+commands.  But these commands will not affect the internal attributes
-of the body, and the position and velocity of individual atoms in the
+of the body unless {reinit} is set to {yes}. With {reinit} set to {no}
-body will be reset when time integration starts.
+(or using the {infile} option, which implies {reinit} {no}) the position
 and velocity of individual atoms in the body will be reset when time
 integration starts again.
 :line
@ -401,6 +414,14 @@ couple none :pre
 The keyword/value option pairs are used in the following ways.
 The {reinit} keyword determines, whether the rigid body properties
 are reinitialized between run commands. With the option {yes} (the
 default) this is done, with the option {no} this is not done. Turning
 off the reinitialization can be helpful to protect rigid bodies against
 unphysical manipulations between runs or when properties cannot be
 easily recomputed (e.g. when read from a file). When using the {infile}
 keyword, the {reinit} option is automatically set to {no}.
 The {langevin} and {temp} and {tparam} keywords perform thermostatting
 of the rigid bodies, altering both their translational and rotational
 degrees of freedom.  What is meant by "temperature" of a collection of
@ -778,7 +799,7 @@ exclude, "fix shake"_fix_shake.html
 The option defaults are force * on on on and torque * on on on,
 meaning all rigid bodies are acted on by center-of-mass force and
-torque.  Also Tchain = Pchain = 10, Titer = 1, Torder = 3.
+torque.  Also Tchain = Pchain = 10, Titer = 1, Torder = 3, reinit = yes.
 :line
--- a/doc/src/fixes.txt
+++ b/doc/src/fixes.txt
@ -111,6 +111,7 @@ Fixes :h1
   fix_press_berendsen
   fix_print
   fix_property_atom
   fix_python
   fix_qbmsst
   fix_qeq
   fix_qeq_comb
--- a/doc/src/improper_cossq.txt
+++ b/doc/src/improper_cossq.txt
@ -45,12 +45,9 @@ 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/radian^2)
+K (energy)
 X0 (degrees) :ul
 X0 is specified in degrees, but LAMMPS converts it to radians
 internally; hence the units of K are in energy/radian^2.
 :line
 Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
--- a/doc/src/improper_ring.txt
+++ b/doc/src/improper_ring.txt
@ -49,12 +49,9 @@ 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/radian^2)
+K (energy)
 theta0 (degrees) :ul
 theta0 is specified in degrees, but LAMMPS converts it to radians
 internally; hence the units of K are in energy/radian^2.
 :line
 Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
--- a/doc/src/kspace_modify.txt
+++ b/doc/src/kspace_modify.txt
@ -308,7 +308,8 @@ The option defaults are mesh = mesh/disp = 0 0 0, order = order/disp =
 gewald = gewald/disp = 0.0, slab = 1.0, compute = yes, cutoff/adjust =
 yes (MSM), pressure/scalar = yes (MSM), fftbench = yes (PPPM), diff = ik
 (PPPM), mix/disp = pair, force/disp/real = -1.0, force/disp/kspace = -1.0,
-split = 0, tol = 1.0e-6, and disp/auto = no.
+split = 0, tol = 1.0e-6, and disp/auto = no. For pppm/intel, order =
 order/disp = 7.
 :line
--- a/doc/src/kspace_style.txt
+++ b/doc/src/kspace_style.txt
@ -33,12 +33,16 @@ style = {none} or {ewald} or {ewald/disp} or {ewald/omp} or {pppm} or {pppm/cg}
    accuracy = desired relative error in forces
  {pppm/gpu} value = accuracy
    accuracy = desired relative error in forces
  {pppm/intel} value = accuracy
    accuracy = desired relative error in forces
  {pppm/kk} value = accuracy
    accuracy = desired relative error in forces
  {pppm/omp} value = accuracy
    accuracy = desired relative error in forces
  {pppm/cg/omp} value = accuracy
    accuracy = desired relative error in forces
  {pppm/disp/intel} value = accuracy
    accuracy = desired relative error in forces
  {pppm/tip4p/omp} value = accuracy
    accuracy = desired relative error in forces
  {pppm/stagger} value = accuracy
--- a/doc/src/lammps.book
+++ b/doc/src/lammps.book
@ -55,12 +55,12 @@ dihedral_style.html
 dimension.html
 displace_atoms.html
 dump.html
 dump_custom_vtk.html
 dump_h5md.html
 dump_image.html
 dump_modify.html
 dump_molfile.html
-dump_nc.html
+dump_netcdf.html
 dump_vtk.html
 echo.html
 fix.html
 fix_modify.html
@ -237,6 +237,7 @@ fix_pour.html
 fix_press_berendsen.html
 fix_print.html
 fix_property_atom.html
 fix_python.html
 fix_qbmsst.html
 fix_qeq.html
 fix_qeq_comb.html
@ -300,6 +301,7 @@ compute_centro_atom.html
 compute_chunk_atom.html
 compute_cluster_atom.html
 compute_cna_atom.html
 compute_cnp_atom.html
 compute_com.html
 compute_com_chunk.html
 compute_contact_atom.html
@ -432,6 +434,7 @@ pair_gauss.html
 pair_gayberne.html
 pair_gran.html
 pair_gromacs.html
 pair_gw.html
 pair_hbond_dreiding.html
 pair_hybrid.html
 pair_kim.html
@ -444,7 +447,6 @@ pair_lj96.html
 pair_lj_cubic.html
 pair_lj_expand.html
 pair_lj_long.html
 pair_lj_sf.html
 pair_lj_smooth.html
 pair_lj_smooth_linear.html
 pair_lj_soft.html
@ -467,9 +469,10 @@ pair_oxdna.html
 pair_oxdna2.html
 pair_peri.html
 pair_polymorphic.html
 pair_python.html
 pair_quip.html
 pair_reax.html
-pair_reax_c.html
+pair_reaxc.html
 pair_resquared.html
 pair_sdk.html
 pair_smd_hertz.html
--- a/doc/src/manifolds.txt
+++ b/doc/src/manifolds.txt
@ -24,14 +24,15 @@ to the relevant fixes.
 {manifold} @ {parameters} @ {equation} @ {description}
 cylinder @ R @ x^2 + y^2 - R^2 = 0 @ Cylinder along z-axis, axis going through (0,0,0)
 cylinder_dent @ R l a @ x^2 + y^2 - r(z)^2 = 0, r(x) = R if | z | > l, r(z) = R - a*(1 + cos(z/l))/2 otherwise @ A cylinder with a dent around z = 0
-dumbbell @ a A B c @ -( x^2 + y^2 ) * (a^2 - z^2/c^2) * ( 1 + (A*sin(B*z^2))^4) = 0 @ A dumbbell @
+dumbbell @ a A B c @ -( x^2 + y^2 ) + (a^2 - z^2/c^2) * ( 1 + (A*sin(B*z^2))^4) = 0 @ A dumbbell
 ellipsoid @ a  b c @ (x/a)^2 + (y/b)^2 + (z/c)^2 = 0 @ An ellipsoid
 gaussian_bump @ A l rc1 rc2 @ if( x < rc1) -z + A * exp( -x^2 / (2 l^2) ); else if( x < rc2 ) -z + a + b*x + c*x^2 + d*x^3; else z @ A Gaussian bump at x = y = 0, smoothly tapered to a flat plane z = 0.
 plane @ a b c x0 y0 z0 @ a*(x-x0) + b*(y-y0) + c*(z-z0) = 0 @ A plane with normal (a,b,c) going through point (x0,y0,z0)
 plane_wiggle @ a w @ z - a*sin(w*x) = 0 @ A plane with a sinusoidal modulation on z along x.
 sphere @ R @ x^2 + y^2 + z^2 - R^2 = 0 @ A sphere of radius R
 supersphere @ R q @ | x |^q + | y |^q + | z |^q - R^q = 0 @ A supersphere of hyperradius R
-spine @ a, A, B, B2, c @ -(x^2 + y^2)*(a^2 - z^2/f(z)^2)*(1 + (A*sin(g(z)*z^2))^4), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise  @ An approximation to a dendtritic spine
+spine @ a, A, B, B2, c @ -(x^2 + y^2) + (a^2 - z^2/f(z)^2)*(1 + (A*sin(g(z)*z^2))^4), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise  @ An approximation to a dendtritic spine
-spine_two @ a, A, B, B2, c @ -(x^2 + y^2)*(a^2 - z^2/f(z)^2)*(1 + (A*sin(g(z)*z^2))^2), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise  @ Another approximation to a dendtritic spine
+spine_two @ a, A, B, B2, c @ -(x^2 + y^2) + (a^2 - z^2/f(z)^2)*(1 + (A*sin(g(z)*z^2))^2), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise  @ Another approximation to a dendtritic spine
 thylakoid @ wB LB lB @ Various, see "(Paquay)"_#Paquay1 @ A model grana thylakoid consisting of two block-like compartments connected by a bridge of width wB, length LB and taper length lB
 torus @ R r  @  (R - sqrt( x^2 + y^2 ) )^2 + z^2 - r^2  @ A torus with large radius R and small radius r, centered on (0,0,0) :tb(s=@)
--- a/doc/src/neb.txt
+++ b/doc/src/neb.txt
@ -10,28 +10,31 @@ neb command :h3
 [Syntax:]
-neb etol ftol N1 N2 Nevery file-style arg :pre
+neb etol ftol N1 N2 Nevery file-style arg keyword :pre
 etol = stopping tolerance for energy (energy units) :ulb,l
 ftol = stopping tolerance for force (force units) :l
 N1 = max # of iterations (timesteps) to run initial NEB :l
 N2 = max # of iterations (timesteps) to run barrier-climbing NEB :l
 Nevery = print replica energies and reaction coordinates every this many timesteps :l
-file-style= {final} or {each} or {none} :l
+file-style = {final} or {each} or {none} :l
  {final} arg = filename
    filename = file with initial coords for final replica
-      coords for intermediate replicas are linearly interpolated between first and last replica
+      coords for intermediate replicas are linearly interpolated
      between first and last replica
  {each} arg = filename
-    filename = unique filename for each replica (except first) with its initial coords
+    filename = unique filename for each replica (except first)
-  {none} arg = no argument
+      with its initial coords
-    all replicas assumed to already have their initial coords :pre
+  {none} arg = no argument all replicas assumed to already have
      their initial coords :pre
 keyword = {verbose}
 :ule
 [Examples:]
 neb 0.1 0.0 1000 500 50 final coords.final
 neb 0.0 0.001 1000 500 50 each coords.initial.$i
-neb 0.0 0.001 1000 500 50 none :pre
+neb 0.0 0.001 1000 500 50 none verbose :pre
 [Description:]
@ -43,8 +46,8 @@ NEB is a method for finding both the atomic configurations and height
 of the energy barrier associated with a transition state, e.g. for an
 atom to perform a diffusive hop from one energy basin to another in a
 coordinated fashion with its neighbors.  The implementation in LAMMPS
-follows the discussion in these 3 papers: "(HenkelmanA)"_#HenkelmanA,
+follows the discussion in these 4 papers: "(HenkelmanA)"_#HenkelmanA,
-"(HenkelmanB)"_#HenkelmanB, and "(Nakano)"_#Nakano3.
+"(HenkelmanB)"_#HenkelmanB, "(Nakano)"_#Nakano3 and "(Maras)"_#Maras2.
 Each replica runs on a partition of one or more processors.  Processor
 partitions are defined at run-time using the -partition command-line
@ -70,18 +73,17 @@ I.e. the simulation domain, the number of atoms, the interaction
 potentials, and the starting configuration when the neb command is
 issued should be the same for every replica.
-In a NEB calculation each atom in a replica is connected to the same
+In a NEB calculation each replica is connected to other replicas by
-atom in adjacent replicas by springs, which induce inter-replica
+inter-replica nudging forces.  These forces are imposed by the "fix
-forces.  These forces are imposed by the "fix neb"_fix_neb.html
+neb"_fix_neb.html command, which must be used in conjunction with the
-command, which must be used in conjunction with the neb command.  The
+neb command.  The group used to define the fix neb command defines the
-group used to define the fix neb command defines the NEB atoms which
+NEB atoms which are the only ones that inter-replica springs are
-are the only ones that inter-replica springs are applied to.  If the
+applied to.  If the group does not include all atoms, then non-NEB
-group does not include all atoms, then non-NEB atoms have no
+atoms have no inter-replica springs and the forces they feel and their
-inter-replica springs and the forces they feel and their motion is
+motion is computed in the usual way due only to other atoms within
-computed in the usual way due only to other atoms within their
+their replica.  Conceptually, the non-NEB atoms provide a background
-replica.  Conceptually, the non-NEB atoms provide a background force
+force field for the NEB atoms.  They can be allowed to move during the
-field for the NEB atoms.  They can be allowed to move during the NEB
+NEB minimization procedure (which will typically induce different
 minimization procedure (which will typically induce different
 coordinates for non-NEB atoms in different replicas), or held fixed
 using other LAMMPS commands such as "fix setforce"_fix_setforce.html.
 Note that the "partition"_partition.html command can be used to invoke
@ -93,33 +95,18 @@ specified in different manners via the {file-style} setting, as
 discussed below.  Only atoms whose initial coordinates should differ
 from the current configuration need be specified.
-Conceptually, the initial configuration for the first replica should
+Conceptually, the initial and final configurations for the first
-be a state with all the atoms (NEB and non-NEB) having coordinates on
+replica should be states on either side of an energy barrier.
 one side of the energy barrier.  A perfect energy minimum is not
 required, since atoms in the first replica experience no spring forces
 from the 2nd replica.  Thus the damped dynamics minimization will
 drive the first replica to an energy minimum if it is not already
 there.  However, you will typically get better convergence if the
 initial state is already at a minimum.  For example, for a system with
 a free surface, the surface should be fully relaxed before attempting
 a NEB calculation.
 Likewise, the initial configuration of the final replica should be a
 state with all the atoms (NEB and non-NEB) on the other side of the
 energy barrier.  Again, a perfect energy minimum is not required,
 since the atoms in the last replica also experience no spring forces
 from the next-to-last replica, and thus the damped dynamics
 minimization will drive it to an energy minimum.
 As explained below, the initial configurations of intermediate
 replicas can be atomic coordinates interpolated in a linear fashion
-between the first and last replicas.  This is often adequate state for
+between the first and last replicas.  This is often adequate for
 simple transitions.  For more complex transitions, it may lead to slow
 convergence or even bad results if the minimum energy path (MEP, see
 below) of states over the barrier cannot be correctly converged to
-from such an initial configuration.  In this case, you will want to
+from such an initial path.  In this case, you will want to generate
-generate initial states for the intermediate replicas that are
+initial states for the intermediate replicas that are geometrically
-geometrically closer to the MEP and read them in.
+closer to the MEP and read them in.
 :line
@ -135,10 +122,11 @@ is assigned to be a fraction of the distance.  E.g. if there are 10
 replicas, the 2nd replica will assign a position that is 10% of the
 distance along a line between the starting and final point, and the
 9th replica will assign a position that is 90% of the distance along
-the line.  Note that this procedure to produce consistent coordinates
+the line.  Note that for this procedure to produce consistent
-across all the replicas, the current coordinates need to be the same
+coordinates across all the replicas, the current coordinates need to
-in all replicas.  LAMMPS does not check for this, but invalid initial
+be the same in all replicas.  LAMMPS does not check for this, but
-configurations will likely result if it is not the case.
+invalid initial configurations will likely result if it is not the
 case.
 NOTE: The "distance" between the starting and final point is
 calculated in a minimum-image sense for a periodic simulation box.
@ -150,8 +138,8 @@ interpolation is outside the periodic box, the atom will be wrapped
 back into the box when the NEB calculation begins.
 For a {file-style} setting of {each}, a filename is specified which is
-assumed to be unique to each replica.  This can be done by
+assumed to be unique to each replica.  This can be done by using a
-using a variable in the filename, e.g.
+variable in the filename, e.g.
 variable i equal part
 neb 0.0 0.001 1000 500 50 each coords.initial.$i :pre
@ -198,11 +186,10 @@ The minimizer tolerances for energy and force are set by {etol} and
 A non-zero {etol} means that the NEB calculation will terminate if the
 energy criterion is met by every replica.  The energies being compared
 to {etol} do not include any contribution from the inter-replica
-forces, since these are non-conservative.  A non-zero {ftol} means
+nudging forces, since these are non-conservative.  A non-zero {ftol}
-that the NEB calculation will terminate if the force criterion is met
+means that the NEB calculation will terminate if the force criterion
-by every replica.  The forces being compared to {ftol} include the
+is met by every replica.  The forces being compared to {ftol} include
-inter-replica forces between an atom and its images in adjacent
+the inter-replica nudging forces.
 replicas.
 The maximum number of iterations in each stage is set by {N1} and
 {N2}.  These are effectively timestep counts since each iteration of
@ -220,27 +207,27 @@ finding a good energy barrier.  {N1} and {N2} must both be multiples
 of {Nevery}.
 In the first stage of NEB, the set of replicas should converge toward
-the minimum energy path (MEP) of conformational states that transition
+a minimum energy path (MEP) of conformational states that transition
-over the barrier.  The MEP for a barrier is defined as a sequence of
+over a barrier.  The MEP for a transition is defined as a sequence of
-3N-dimensional states that cross the barrier at its saddle point, each
+3N-dimensional states, each of which has a potential energy gradient
-of which has a potential energy gradient parallel to the MEP itself.
+parallel to the MEP itself.  The configuration of highest energy along
-The replica states will also be roughly equally spaced along the MEP
+a MEP corresponds to a saddle point.  The replica states will also be
-due to the inter-replica spring force added by the "fix
+roughly equally spaced along the MEP due to the inter-replica nugding
-neb"_fix_neb.html command.
+force added by the "fix neb"_fix_neb.html command.
-In the second stage of NEB, the replica with the highest energy
+In the second stage of NEB, the replica with the highest energy is
-is selected and the inter-replica forces on it are converted to a
+selected and the inter-replica forces on it are converted to a force
-force that drives its atom coordinates to the top or saddle point of
+that drives its atom coordinates to the top or saddle point of the
-the barrier, via the barrier-climbing calculation described in
+barrier, via the barrier-climbing calculation described in
 "(HenkelmanB)"_#HenkelmanB.  As before, the other replicas rearrange
 themselves along the MEP so as to be roughly equally spaced.
 When both stages are complete, if the NEB calculation was successful,
-one of the replicas should be an atomic configuration at the top or
+the configurations of the replicas should be along (close to) the MEP
-saddle point of the barrier, the potential energies for the set of
+and the replica with the highest energy should be an atomic
-replicas should represent the energy profile of the barrier along the
+configuration at (close to) the saddle point of the transition. The
-MEP, and the configurations of the replicas should be a sequence of
+potential energies for the set of replicas represents the energy
-configurations along the MEP.
+profile of the transition along the MEP.
 :line
@ -284,9 +271,9 @@ ID2 x2 y2 z2
 ...
 IDN xN yN zN :pre
-The fields are the atom ID, followed by the x,y,z coordinates.
+The fields are the atom ID, followed by the x,y,z coordinates.  The
-The lines can be listed in any order.  Additional trailing information
+lines can be listed in any order.  Additional trailing information on
-on the line is OK, such as a comment.
+the line is OK, such as a comment.
 Note that for a typical NEB calculation you do not need to specify
 initial coordinates for very many atoms to produce differing starting
@ -310,38 +297,54 @@ this case), the print-out to the screen and master log.lammps file
 contains a line of output, printed once every {Nevery} timesteps.  It
 contains the timestep, the maximum force per replica, the maximum
 force per atom (in any replica), potential gradients in the initial,
-final, and climbing replicas, the forward and backward energy barriers,
+final, and climbing replicas, the forward and backward energy
-the total reaction coordinate (RDT), and the normalized reaction
+barriers, the total reaction coordinate (RDT), and the normalized
-coordinate and potential energy of each replica.
+reaction coordinate and potential energy of each replica.
-The "maximum force per replica" is
+The "maximum force per replica" is the two-norm of the 3N-length force
-the two-norm of the 3N-length force vector for the atoms in each
+vector for the atoms in each replica, maximized across replicas, which
-replica, maximized across replicas, which is what the {ftol} setting
+is what the {ftol} setting is checking against.  In this case, N is
-is checking against.  In this case, N is all the atoms in each
+all the atoms in each replica.  The "maximum force per atom" is the
-replica.  The "maximum force per atom" is the maximum force component
+maximum force component of any atom in any replica.  The potential
-of any atom in any replica.  The potential gradients are the two-norm
+gradients are the two-norm of the 3N-length force vector solely due to
-of the 3N-length force vector solely due to the interaction potential i.e.
+the interaction potential i.e.  without adding in inter-replica
-without adding in inter-replica forces. Note that inter-replica forces
+forces.
 are zero in the initial and final replicas, and only affect
 the direction in the climbing replica. For this reason, the "maximum
 force per replica" is often equal to the potential gradient in the
 climbing replica. In the first stage of NEB, there is no climbing
 replica, and so the potential gradient in the highest energy replica
 is reported, since this replica will become the climbing replica
 in the second stage of NEB.
-The "reaction coordinate" (RD) for each
+The "reaction coordinate" (RD) for each replica is the two-norm of the
-replica is the two-norm of the 3N-length vector of distances between
+3N-length vector of distances between its atoms and the preceding
-its atoms and the preceding replica's atoms, added to the RD of the
+replica's atoms, added to the RD of the preceding replica. The RD of
-preceding replica. The RD of the first replica RD1 = 0.0;
+the first replica RD1 = 0.0; the RD of the final replica RDN = RDT,
-the RD of the final replica RDN = RDT, the total reaction coordinate.
+the total reaction coordinate.  The normalized RDs are divided by RDT,
-The normalized RDs are divided by RDT,
+so that they form a monotonically increasing sequence from zero to
-so that they form a monotonically increasing sequence
+one. When computing RD, N only includes the atoms being operated on by
-from zero to one. When computing RD, N only includes the atoms
+the fix neb command.
 being operated on by the fix neb command.
-The forward (reverse) energy barrier is the potential energy of the highest
+The forward (reverse) energy barrier is the potential energy of the
-replica minus the energy of the first (last) replica.
+highest replica minus the energy of the first (last) replica.
 Supplementary informations for all replicas can be printed out to the
 screen and master log.lammps file by adding the verbose keyword. These
 informations include the following.  The "path angle" (pathangle) for
 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
 aligned.  "angletangrad" is the angle between the 3N-length tangent
 vector and the 3N-length force vector at image i. The tangent vector
 is calculated as in "(HenkelmanA)"_#HenkelmanA for all intermediate
 replicas and at R2 - R1 and RM - RM-1 for the first and last replica,
 respectively.  "anglegrad" is the angle between the 3N-length energy
 gradient vector of replica i and that of replica i+1. It is not
 defined for the final replica and reads nan.  gradV is the norm of the
 energy gradient of image i.  ReplicaForce is the two-norm of the
 3N-length force vector (including nudging forces) for replica i.
 MaxAtomForce is the maximum force component of any atom in replica i.
 When a NEB calculation does not converge properly, these suplementary
 informations can help understanding what is going wrong. For instance
 when the path angle becomes accute the definition of tangent used in
 the NEB calculation is questionable and the NEB cannot may diverge
 "(Maras)"_#Maras2.
 When running on multiple partitions, LAMMPS produces additional log
 files for each partition, e.g. log.lammps.0, log.lammps.1, etc.  For a
@ -396,12 +399,16 @@ This command can only be used if LAMMPS was built with the REPLICA
 package.  See the "Making LAMMPS"_Section_start.html#start_3 section
 for more info on packages.
 :line
 [Related commands:]
-"prd"_prd.html, "temper"_temper.html, "fix
+"prd"_prd.html, "temper"_temper.html, "fix langevin"_fix_langevin.html,
-langevin"_fix_langevin.html, "fix viscous"_fix_viscous.html
+"fix viscous"_fix_viscous.html
-[Default:] none
+[Default:]
 none
 :line
@ -414,3 +421,7 @@ langevin"_fix_langevin.html, "fix viscous"_fix_viscous.html
 :link(Nakano3)
 [(Nakano)] Nakano, Comp Phys Comm, 178, 280-289 (2008).
 :link(Maras2)
 [(Maras)] Maras, Trushin, Stukowski, Ala-Nissila, Jonsson,
 Comp Phys Comm, 205, 13-21 (2016)
--- a/doc/src/package.txt
+++ b/doc/src/package.txt
@ -574,9 +574,9 @@ is used.  If it is not used, you must invoke the package intel
 command in your input script or or via the "-pk intel" "command-line
 switch"_Section_start.html#start_7.
-For the KOKKOS package, the option defaults neigh = full, neigh/qeq
+For the KOKKOS package, the option defaults neigh = full,
- = full, newton = off, binsize = 0.0, and comm = device.  These settings
+neigh/qeq = full, newton = off, binsize = 0.0, and comm = device.
- are made automatically by the required "-k on" "command-line
+These settings are made automatically by the required "-k on" "command-line
 switch"_Section_start.html#start_7.  You can change them bu using the
 package kokkos command in your input script or via the "-pk kokkos"
 "command-line switch"_Section_start.html#start_7.
--- a/doc/src/pair_edip.txt
+++ b/doc/src/pair_edip.txt
@ -7,11 +7,13 @@
 :line
 pair_style edip command :h3
 pair_style edip/multi command :h3
 [Syntax:]
-pair_style edip :pre
+pair_style style :pre
-pair_style edip/omp :pre
+
 style = {edip} or {edip/multi} :ul
 [Examples:]
@ -20,11 +22,14 @@ pair_coeff * * Si.edip Si
 [Description:]
-The {edip} style computes a 3-body "EDIP"_#EDIP potential which is
+The {edip} and {edip/multi} styles compute a 3-body "EDIP"_#EDIP
-popular for modeling silicon materials where it can have advantages
+potential which is popular for modeling silicon materials where
-over other models such as the "Stillinger-Weber"_pair_sw.html or
+it can have advantages over other models such as the
-"Tersoff"_pair_tersoff.html potentials.  In EDIP, the energy E of a
+"Stillinger-Weber"_pair_sw.html or "Tersoff"_pair_tersoff.html
-system of atoms is
+potentials. The {edip} style has been programmed for single element
 potentials, while {edip/multi} supports multi-element EDIP runs.
 In EDIP, the energy E of a system of atoms is
 :c,image(Eqs/pair_edip.jpg)
@ -142,7 +147,7 @@ This pair style can only be used via the {pair} keyword of the
 [Restrictions:]
-This angle style can only be used if LAMMPS was built with the
+This pair style can only be used if LAMMPS was built with the
 USER-MISC package.  See the "Making LAMMPS"_Section_start.html#start_3
 section for more info on packages.
@ -151,7 +156,7 @@ for pair interactions.
 The EDIP potential files provided with LAMMPS (see the potentials directory)
 are parameterized for metal "units"_units.html.
-You can use the SW potential with any LAMMPS units, but you would need
+You can use the EDIP potential with any LAMMPS units, but you would need
 to create your own EDIP potential file with coefficients listed in the
 appropriate units if your simulation doesn't use "metal" units.
@ -164,4 +169,4 @@ appropriate units if your simulation doesn't use "metal" units.
 :line
 :link(EDIP)
-[(EDIP)] J. F. Justo et al., Phys. Rev. B 58, 2539 (1998).
+[(EDIP)] J F Justo et al, Phys Rev B 58, 2539 (1998).
--- a/doc/src/pair_gauss.txt
+++ b/doc/src/pair_gauss.txt
@ -128,7 +128,7 @@ The B parameter is converted to a distance (sigma), before mixing
 afterwards (using B=sigma^2).
 Negative A values are converted to positive A values (using abs(A))
 before mixing, and converted back after mixing
-(by multiplying by sign(Ai)*sign(Aj)).
+(by multiplying by min(sign(Ai),sign(Aj))).
 This way, if either particle is repulsive (if Ai<0 or Aj<0),
 then the default interaction between both particles will be repulsive.
--- a/doc/src/pair_gw.txt
+++ b/doc/src/pair_gw.txt
@ -0,0 +1,120 @@
 "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 gw command :h3
 pair_style gw/zbl command :h3
 [Syntax:]
 pair_style style :pre
 style = {gw} or {gw/zbl} :ul
 [Examples:]
 pair_style gw
 pair_coeff * * SiC.gw Si C C
 pair_style gw/zbl
 pair_coeff * * SiC.gw.zbl C Si :pre
 [Description:]
 The {gw} style computes a 3-body "Gao-Weber"_#Gao potential;
 similarly {gw/zbl} combines this potential with a modified
 repulsive ZBL core function in a similar fashion as implemented
 in the "tersoff/zbl"_pair_tersoff_zbl.html pair style.
 Unfortunately the author of this contributed code has not been
 able to submit a suitable documentation explaining the details
 of the potentials. The LAMMPS developers thus have finally decided
 to release the code anyway with only the technical explanations.
 For details of the model and the parameters, please refer to the
 linked publication.
 Only a single pair_coeff command is used with the {gw} and {gw/zbl}
 styles which specifies a Gao-Weber potential file with parameters
 for all needed elements.  These are mapped to LAMMPS atom types by
 specifying N additional arguments after the filename in the pair_coeff
 command, where N is the number of LAMMPS atom types:
 filename
 N element names = mapping of GW elements to atom types :ul
 See the "pair_coeff"_pair_coeff.html doc page for alternate ways
 to specify the path for the potential file.
 As an example, imagine a file SiC.gw has Gao-Weber values for Si and C.
 If your LAMMPS simulation has 4 atoms types and you want the first 3 to
 be Si, and the 4th to be C, you would use the following pair_coeff command:
 pair_coeff * * SiC.gw Si Si Si C :pre
 The first 2 arguments must be * * so as to span all LAMMPS atom types.
 The first three Si arguments map LAMMPS atom types 1,2,3 to the Si
 element in the GW file.  The final C argument maps LAMMPS atom type 4
 to the C element in the GW file.  If a mapping value is specified as
 NULL, the mapping is not performed.  This can be used when a {gw}
 potential is used as part of the {hybrid} pair style.  The NULL values
 are placeholders for atom types that will be used with other
 potentials.
 Gao-Weber files in the {potentials} directory of the LAMMPS
 distribution have a ".gw" suffix.  Gao-Weber with ZBL files
 have a ".gz.zbl" suffix. The structure of the potential files
 is similar to other many-body potentials supported by LAMMPS.
 You have to refer to the comments in the files and the literature
 to learn more details.
 :line
 [Mixing, shift, table, tail correction, restart, rRESPA info]:
 For atom type pairs I,J and I != J, where types I and J correspond to
 two different element types, mixing is performed by LAMMPS as
 described above from values in the potential file.
 This pair style does not support the "pair_modify"_pair_modify.html
 shift, table, and tail options.
 This pair style does not write its information to "binary restart
 files"_restart.html, since it is stored in potential files.  Thus, you
 need to re-specify the pair_style and pair_coeff commands in an input
 script that reads a restart file.
 This pair style 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:]
 This pair style is part of the USER-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 pair style requires the "newton"_newton.html setting to be "on"
 for pair interactions.
 The Gao-Weber potential files provided with LAMMPS (see the
 potentials directory) are parameterized for metal "units"_units.html.
 You can use the GW potential with any LAMMPS units, but you would need
 to create your own GW potential file with coefficients listed in the
 appropriate units if your simulation doesn't use "metal" units.
 [Related commands:]
 "pair_coeff"_pair_coeff.html
 [Default:] none
 :line
 :link(Gao)
 [(Gao)] Gao and Weber, Nuclear Instruments and Methods in Physics Research B 191 (2012) 504.
--- a/doc/src/pair_hybrid.txt
+++ b/doc/src/pair_hybrid.txt
@ -73,7 +73,7 @@ pair_coeff command to assign parameters for the different type pairs.
 NOTE: There are two exceptions to this option to list an individual
 pair style multiple times.  The first is for pair styles implemented
 as Fortran libraries: "pair_style meam"_pair_meam.html and "pair_style
-reax"_pair_reax.html ("pair_style reax/c"_pair_reax_c.html is OK).
+reax"_pair_reax.html ("pair_style reax/c"_pair_reaxc.html is OK).
 This is because unlike a C++ class, they can not be instantiated
 multiple times, due to the manner in which they were coded in Fortran.
 The second is for GPU-enabled pair styles in the GPU package.  This is
@ -225,6 +225,12 @@ special_bonds lj/coul 1e-20 1e-20 0.5
 pair_hybrid tersoff lj/cut/coul/long 12.0
 pair_modify pair tersoff special lj/coul 1.0 1.0 1.0 :pre
 For use with the various "compute */tally"_compute_tally.html
 computes, the "pair_modify compute/tally"_pair_modify.html
 command can be used to selectively turn off processing of
 the compute tally styles, for example, if those pair styles
 (e.g. manybody styles) do not support this feature.
 See the "pair_modify"_pair_modify.html doc page for details on
 the specific syntax, requirements and restrictions.
--- a/doc/src/pair_lj_long.txt
+++ b/doc/src/pair_lj_long.txt
@ -7,6 +7,7 @@
 :line
 pair_style lj/long/coul/long command :h3
 pair_style lj/long/coul/long/intel command :h3
 pair_style lj/long/coul/long/omp command :h3
 pair_style lj/long/coul/long/opt command :h3
 pair_style lj/long/tip4p/long command :h3
--- a/doc/src/pair_lj_sf.txt
+++ b/doc/src/pair_lj_sf.txt
@ -1,114 +0,0 @@
 "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
 :link(lc,Section_commands.html#comm)
 :line
 pair_style lj/sf command :h3
 pair_style lj/sf/omp command :h3
 [Syntax:]
 pair_style lj/sf cutoff :pre
 cutoff = global cutoff for Lennard-Jones interactions (distance units) :ul
 [Examples:]
 pair_style lj/sf 2.5
 pair_coeff * * 1.0 1.0
 pair_coeff 1 1 1.0 1.0 3.0 :pre
 [Description:]
 Style {lj/sf} computes a truncated and force-shifted LJ interaction
 (Shifted Force Lennard-Jones), so that both the potential and the
 force go continuously to zero at the cutoff "(Toxvaerd)"_#Toxvaerd:
 :c,image(Eqs/pair_lj_sf.jpg)
 The following coefficients must be defined for each pair of atoms
 types via the "pair_coeff"_pair_coeff.html command as in the examples
 above, or in the data file or restart files read by the
 "read_data"_read_data.html or "read_restart"_read_restart.html
 commands, or by mixing as described below:
 epsilon (energy units)
 sigma (distance units)
 cutoff (distance units) :ul
 The last coefficient is optional. If not specified, the global
 LJ cutoff specified in the pair_style command is used.
 :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_7 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 epsilon and sigma
 coefficients and cutoff distance for this pair style can be mixed.
 Rin is a cutoff value and is mixed like the cutoff. The
 default mix value is {geometric}.  See the "pair_modify" command for
 details.
 The "pair_modify"_pair_modify.html shift option is not relevant for
 this pair style, since the pair interaction goes to 0.0 at the cutoff.
 The "pair_modify"_pair_modify.html table option is 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, since the energy of the pair interaction is smoothed to 0.0
 at the cutoff.
 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:]
 This pair style is part of the USER-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:]
 "pair_coeff"_pair_coeff.html
 [Default:] none
 :line
 :link(Toxvaerd)
 [(Toxvaerd)] Toxvaerd, Dyre, J Chem Phys, 134, 081102 (2011).
--- a/doc/src/pair_lj_smooth_linear.txt
+++ b/doc/src/pair_lj_smooth_linear.txt
@ -11,26 +11,26 @@ pair_style lj/smooth/linear/omp command :h3
 [Syntax:]
-pair_style lj/smooth/linear Rc :pre
+pair_style lj/smooth/linear cutoff :pre
-Rc = cutoff for lj/smooth/linear interactions (distance units) :ul
+cutoff = global cutoff for Lennard-Jones interactions (distance units) :ul
 [Examples:]
-pair_style lj/smooth/linear 5.456108274435118
+pair_style lj/smooth/linear 2.5
-pair_coeff * * 0.7242785984051078 2.598146797350056
+pair_coeff * * 1.0 1.0
-pair_coeff 1 1 20.0 1.3 9.0 :pre
+pair_coeff 1 1 0.3 3.0 9.0 :pre
 [Description:]
-Style {lj/smooth/linear} computes a LJ interaction that combines the
+Style {lj/smooth/linear} computes a truncated and force-shifted LJ
-standard 12/6 Lennard-Jones function and subtracts a linear term that
+interaction (aka Shifted Force Lennard-Jones) that combines the
-includes the cutoff distance Rc, as in this formula:
+standard 12/6 Lennard-Jones function and subtracts a linear term based
 on the cutoff distance, so that both, the potential and the force, go
 continuously to zero at the cutoff Rc "(Toxvaerd)"_#Toxvaerd:
 :c,image(Eqs/pair_lj_smooth_linear.jpg)
 At the cutoff Rc, the energy and force (its 1st derivative) will be 0.0.
 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
@ -41,8 +41,8 @@ epsilon (energy units)
 sigma (distance units)
 cutoff (distance units) :ul
-The last coefficient is optional.  If not specified, the global value
+The last coefficient is optional. If not specified, the global
-for Rc is used.
+LJ cutoff specified in the pair_style command is used.
 :line
@ -76,10 +76,11 @@ and cutoff distance can be mixed. The default mix value is geometric.
 See the "pair_modify" command for details.
 This pair style does not support the "pair_modify"_pair_modify.html
-shift option for the energy of the pair interaction.
+shift option for the energy of the pair interaction, since it goes
 to 0.0 at the cutoff by construction.
-The "pair_modify"_pair_modify.html table option is not relevant for
+The "pair_modify"_pair_modify.html table option is not relevant
-this pair style.
+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
@ -103,3 +104,8 @@ This pair style can only be used via the {pair} keyword of the
 "pair_coeff"_pair_coeff.html, "pair lj/smooth"_pair_lj_smooth.html
 [Default:] none
 :line
 :link(Toxvaerd)
 [(Toxvaerd)] Toxvaerd, Dyre, J Chem Phys, 134, 081102 (2011).
--- a/doc/src/pair_meam_spline.txt
+++ b/doc/src/pair_meam_spline.txt
@ -23,7 +23,8 @@ pair_coeff * * Ti.meam.spline Ti Ti Ti :pre
 The {meam/spline} style computes pairwise interactions for metals
 using a variant of modified embedded-atom method (MEAM) potentials
-"(Lenosky)"_#Lenosky1.  The total energy E is given by
+"(Lenosky)"_#Lenosky1.  For a single species ("old-style") MEAM,
 the total energy E is given by
 :c,image(Eqs/pair_meam_spline.jpg)
@ -31,6 +32,20 @@ where rho_i is the density at atom I, theta_jik is the angle between
 atoms J, I, and K centered on atom I. The five functions Phi, U, rho,
 f, and g are represented by cubic splines.
 The {meam/spline} style also supports a new style multicomponent
 modified embedded-atom method (MEAM) potential "(Zhang)"_#Zhang4, where
 the total energy E is given by
 :c,image(Eqs/pair_meam_spline_multicomponent.jpg)
 where the five functions Phi, U, rho, f, and g depend on the chemistry
 of the atoms in the interaction.  In particular, if there are N different
 chemistries, there are N different U, rho, and f functions, while there
 are N(N+1)/2 different Phi and g functions.  The new style multicomponent
 MEAM potential files are indicated by the second line in the file starts
 with "meam/spline" followed by the number of elements and the name of each
 element.
 The cutoffs and the coefficients for these spline functions are listed
 in a parameter file which is specified by the
 "pair_coeff"_pair_coeff.html command.  Parameter files for different
@ -59,7 +74,7 @@ N element names = mapping of spline-based MEAM elements to atom types :ul
 See the "pair_coeff"_pair_coeff.html doc page for alternate ways
 to specify the path for the potential file.
-As an example, imagine the Ti.meam.spline file has values for Ti.  If
+As an example, imagine the Ti.meam.spline file has values for Ti (old style).  If
 your LAMMPS simulation has 3 atoms types and they are all to be
 treated with this potentials, you would use the following pair_coeff
 command:
@ -72,10 +87,19 @@ in the potential file.  If a mapping value is specified as NULL, the
 mapping is not performed.  This can be used when a {meam/spline}
 potential is used as part of the {hybrid} pair style.  The NULL values
 are placeholders for atom types that will be used with other
-potentials.
+potentials. The old-style potential maps any non-NULL species named
 on the command line to that single type.
-NOTE: The {meam/spline} style currently supports only single-element
+An example with a two component spline (new style) is TiO.meam.spline, where
-MEAM potentials.  It may be extended for alloy systems in the future.
+the command
 pair_coeff * * TiO.meam.spline Ti O :pre
 will map the 1st atom type to Ti and the second atom type to O. Note
 in this case that the species names need to match exactly with the
 names of the elements in the TiO.meam.spline file; otherwise an
 error will be raised. This behavior is different than the old style
 MEAM files.
 :line
@ -104,9 +128,6 @@ more instructions on how to use the accelerated styles effectively.
 [Mixing, shift, table, tail correction, restart, rRESPA info]:
 The current version of this pair style does not support multiple
 element types or mixing.  It has been designed for pure elements only.
 This pair style does not support the "pair_modify"_pair_modify.html
 shift, table, and tail options.
@ -142,3 +163,6 @@ for more info.
 [(Lenosky)] Lenosky, Sadigh, Alonso, Bulatov, de la Rubia, Kim, Voter,
 Kress, Modelling Simulation Materials Science Engineering, 8, 825
 (2000).
 :link(Zhang4)
 [(Zhang)] Zhang and Trinkle, Computational Materials Science, 124, 204-210 (2016).
--- a/doc/src/pair_modify.txt
+++ b/doc/src/pair_modify.txt
@ -15,11 +15,13 @@ pair_modify keyword values ... :pre
 one or more keyword/value pairs may be listed :ulb,l
 keyword = {pair} or {shift} or {mix} or {table} or {table/disp} or {tabinner} or {tabinner/disp} or {tail} or {compute} :l
  {pair} values = sub-style N {special} which wt1 wt2 wt3
               or sub-style N {compute/tally} flag
    sub-style = sub-style of "pair hybrid"_pair_hybrid.html
    N = which instance of sub-style (only if sub-style is used multiple times)
-    {special} which wt1 wt2 wt3 = override {special_bonds} settings (optional)
+      {special} which wt1 wt2 wt3 = override {special_bonds} settings (optional)
-    which = {lj/coul} or {lj} or {coul}
+        which = {lj/coul} or {lj} or {coul}
-    w1,w2,w3 = 1-2, 1-3, and 1-4 weights from 0.0 to 1.0 inclusive
+        w1,w2,w3 = 1-2, 1-3, and 1-4 weights from 0.0 to 1.0 inclusive
      {compute/tally} flag = {yes} or {no}
  {mix} value = {geometric} or {arithmetic} or {sixthpower}
  {shift} value = {yes} or {no}
  {table} value = N
@ -40,6 +42,7 @@ pair_modify shift yes mix geometric
 pair_modify tail yes
 pair_modify table 12
 pair_modify pair lj/cut compute no
 pair_modify pair tersoff compute/tally no
 pair_modify pair lj/cut/coul/long 1 special lj/coul 0.0 0.0 0.0 :pre
 [Description:]
@ -60,9 +63,12 @@ keywords will be applied to.  Note that if the {pair} keyword is not
 used, and the pair style is {hybrid} or {hybrid/overlay}, then all the
 specified keywords will be applied to all sub-styles.
-The {special} keyword can only be used in conjunction with the {pair}
+The {special} and {compute/tally} keywords can [only] be used in
-keyword and must directly follow it. It allows to override the
+conjunction with the {pair} keyword and must directly follow it.
 {special} allows to override the
 "special_bonds"_special_bonds.html settings for the specified sub-style.
 {compute/tally} allows to disable or enable registering
 "compute */tally"_compute_tally.html computes for a given sub-style.
 More details are given below.
 The {mix} keyword affects pair coefficients for interactions between
@ -231,6 +237,14 @@ setting. Substituting 1.0e-10 for 0.0 and 0.9999999999 for 1.0 is
 usually a sufficient workaround in this case without causing a
 significant error.
 The {compute/tally} keyword takes exactly 1 argument ({no} or {yes}),
 and allows to selectively disable or enable processing of the various
 "compute */tally"_compute_tally.html styles for a given
 "pair hybrid or hybrid/overlay"_pair_hybrid.html sub-style.
 NOTE: Any "pair_modify pair compute/tally" command must be issued
 [before] the corresponding compute style is defined.
 :line
 [Restrictions:] none
@ -240,8 +254,9 @@ conflicting options.  You cannot use {tail} yes with 2d simulations.
 [Related commands:]
-"pair_style"_pair_style.html, "pair_coeff"_pair_coeff.html,
+"pair_style"_pair_style.html, "pair_style hybrid"_pair_hybrid.html,
-"thermo_style"_thermo_style.html
+pair_coeff"_pair_coeff.html, "thermo_style"_thermo_style.html,
 "compute */tally"_compute_tally.html
 [Default:]
--- a/doc/src/pair_morse.txt
+++ b/doc/src/pair_morse.txt
@ -26,7 +26,7 @@ args = list of arguments for a particular style :ul
 {morse/smooth/linear} args = cutoff
   cutoff = global cutoff for Morse interactions (distance units)
 {morse/soft} args = n lf cutoff
-   n = soft-core parameter
+   n       = soft-core parameter
   lf      = transformation range is lf < lambda < 1
   cutoff  = global cutoff for Morse interactions (distance units)
 :pre
@ -36,7 +36,7 @@ args = list of arguments for a particular style :ul
 pair_style morse 2.5
 pair_style morse/smooth/linear 2.5
 pair_coeff * * 100.0 2.0 1.5
-pair_coeff 1 1 100.0 2.0 1.5 3.0
+pair_coeff 1 1 100.0 2.0 1.5 3.0 :pre
 pair_style morse/soft 4 0.9 10.0
 pair_coeff * * 100.0 2.0 1.5 1.0
--- a/doc/src/pair_python.txt
+++ b/doc/src/pair_python.txt
@ -0,0 +1,217 @@
 "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 python command :h3
 [Syntax:]
 pair_style python cutoff :pre
 cutoff = global cutoff for interactions in python potential classes
 [Examples:]
 pair_style python 2.5
 pair_coeff * * py_pot.LJCutMelt lj :pre
 pair_style hybrid/overlay coul/long 12.0 python 12.0
 pair_coeff * * coul/long
 pair_coeff * * python py_pot.LJCutSPCE OW NULL :pre
 [Description:]
 The {python} pair style provides a way to define pairwise additive
 potential functions as python script code that is loaded into LAMMPS
 from a python file which must contain specific python class definitions.
 This allows to rapidly evaluate different potential functions without
 having to modify and recompile LAMMPS. Due to python being an
 interpreted language, however, the performance of this pair style is
 going to be significantly slower (often between 20x and 100x) than
 corresponding compiled code. This penalty can be significantly reduced
 through generating tabulations from the python code through the
 "pair_write"_pair_write.html command, which is supported by this style.
 Only a single pair_coeff command is used with the {python} pair style
 which specifies a python class inside a python module or file that
 LAMMPS will look up in the current directory, the folder pointed to by
 the LAMMPS_POTENTIALS environment variable or somewhere in your python
 path.  A single python module can hold multiple python pair class
 definitions. The class definitions itself have to follow specific
 rules that are explained below.
 Atom types in the python class are specified through symbolic
 constants, typically strings. These are mapped to LAMMPS atom types by
 specifying N additional arguments after the class name in the
 pair_coeff command, where N must be the number of currently defined
 atom types:
 As an example, imagine a file {py_pot.py} has a python potential class
 names {LJCutMelt} with parameters and potential functions for a two
 Lennard-Jones atom types labeled as 'LJ1' and 'LJ2'. In your LAMMPS
 input and you would have defined 3 atom types, out of which the first
 two are supposed to be using the 'LJ1' parameters and the third the
 'LJ2' parameters, then you would use the following pair_coeff command:
 pair_coeff * * py_pot.LJCutMelt LJ1 LJ1 LJ2 :pre
 The first two arguments [must] be * * so as to span all LAMMPS atom
 types.  The first two LJ1 arguments map LAMMPS atom types 1 and 2 to
 the LJ1 atom type in the LJCutMelt class of the py_pot.py file.  The
 final LJ2 argument maps LAMMPS atom type 3 to the LJ2 atom type the
 python file.  If a mapping value is specified as NULL, the mapping is
 not performed, any pair interaction with this atom type will be
 skipped. This can be used when a {python} potential is used as part of
 the {hybrid} or {hybrid/overlay} pair style. The NULL values are then
 placeholders for atom types that will be used with other potentials.
 :line
 The python potential file has to start with the following code:
 from __future__ import print_function
 #
 class LAMMPSPairPotential(object):
    def __init__(self):
        self.pmap=dict()
        self.units='lj'
    def map_coeff(self,name,ltype):
        self.pmap\[ltype\]=name
    def check_units(self,units):
        if (units != self.units):
           raise Exception("Conflicting units: %s vs. %s" % (self.units,units))
 :pre
 Any classes with definitions of specific potentials have to be derived
 from this class and should be initialize in a similar fashion to the
 example given below.
 NOTE: The class constructor has to set up a data structure containing
 the potential parameters supported by this class.  It should also
 define a variable {self.units} containing a string matching one of the
 options of LAMMPS' "units"_units.html command, which is used to
 verify, that the potential definition in the python class and in the
 LAMMPS input match.
 Here is an example for a single type Lennard-Jones potential class
 {LJCutMelt} in reducted units, which defines an atom type {lj} for
 which the parameters epsilon and sigma are both 1.0:
 class LJCutMelt(LAMMPSPairPotential):
    def __init__(self):
        super(LJCutMelt,self).__init__()
        # set coeffs: 48*eps*sig**12, 24*eps*sig**6,
        #              4*eps*sig**12,  4*eps*sig**6
        self.units = 'lj'
        self.coeff = \{'lj'  : \{'lj'  : (48.0,24.0,4.0,4.0)\}\}
 :pre
 The class also has to provide two methods for the computation of the
 potential energy and forces, which have be named {compute_force},
 and {compute_energy}, which both take 3 numerical arguments:
  rsq   = the square of the distance between a pair of atoms (float) :l
  itype = the (numerical) type of the first atom :l
  jtype = the (numerical) type of the second atom :ul
 This functions need to compute the force and the energy, respectively,
 and use the result as return value. The functions need to use the
 {pmap} dictionary to convert the LAMMPS atom type number to the symbolic
 value of the internal potential parameter data structure. Following
 the {LJCutMelt} example, here are the two functions:
   def compute_force(self,rsq,itype,jtype):
        coeff = self.coeff\[self.pmap\[itype\]\]\[self.pmap\[jtype\]\]
        r2inv  = 1.0/rsq
        r6inv  = r2inv*r2inv*r2inv
        lj1 = coeff\[0\]
        lj2 = coeff\[1\]
        return (r6inv * (lj1*r6inv - lj2))*r2inv :pre
    def compute_energy(self,rsq,itype,jtype):
        coeff = self.coeff\[self.pmap\[itype\]\]\[self.pmap\[jtype\]\]
        r2inv  = 1.0/rsq
        r6inv  = r2inv*r2inv*r2inv
        lj3 = coeff\[2\]
        lj4 = coeff\[3\]
        return (r6inv * (lj3*r6inv - lj4)) :pre
 NOTE: for consistency with the C++ pair styles in LAMMPS, the
 {compute_force} function follows the conventions of the Pair::single()
 methods and does not return the full force, but the force scaled by
 the distance between the two atoms, so this value only needs to be
 multiplied by delta x, delta y, and delta z to conveniently obtain the
 three components of the force vector between these two atoms.
 :line
 NOTE: The evaluation of scripted python code will slow down the
 computation pair-wise interactions quite significantly. However, this
 can be largely worked around through using the python pair style not
 for the actual simulation, but to generate tabulated potentials on the
 fly using the "pair_write"_pair_write.html command. Please see below
 for an example LAMMPS input of how to build a table file:
 pair_style python 2.5
 pair_coeff * * py_pot.LJCutMelt lj
 shell rm -f melt.table
 pair_write  1 1 2000 rsq 0.01 2.5 lj1_lj2.table lj :pre
 Note that it is strongly recommended to try to [delete] the potential
 table file before generating it. Since the {pair_write} command will
 always [append] to a table file, while pair style table will use the
 [first match]. Thus when changing the potential function in the python
 class, the table pair style will still read the old variant unless the
 table file is first deleted.
 After switching the pair style to {table}, the potential tables need
 to be assigned to the LAMMPS atom types like this:
 pair_style      table linear 2000
 pair_coeff      1  1  melt.table lj :pre
 This can also be done for more complex systems.  Please see the
 {examples/python} folders for a few more examples.
 :line
 [Mixing, shift, table, tail correction, restart, rRESPA info]:
 Mixing of potential parameters has to be handled inside the provided
 python module. The python pair style simply assumes that force and
 energy computation can be correctly performed for all pairs of atom
 types as they are mapped to the atom type labels inside the python
 potential class.
 This pair style does not support the "pair_modify"_pair_modify.html
 shift, table, and tail options.
 This pair style does not write its information to "binary restart
 files"_restart.html, since it is stored in potential files.  Thus, you
 need to re-specify the pair_style and pair_coeff commands in an input
 script that reads a restart file.
 This pair style 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:]
 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:]
 "pair_coeff"_pair_coeff.html, "pair_write"_pair_write.html,
 "pair style table"_pair_table.html
 [Default:] none
--- a/doc/src/pair_reax.txt
+++ b/doc/src/pair_reax.txt
@ -36,7 +36,7 @@ supplemental information of the following paper:
 the most up-to-date version of ReaxFF as of summer 2010.
 WARNING: pair style reax is now deprecated and will soon be retired. Users
-should switch to "pair_style reax/c"_pair_reax_c.html. The {reax} style
+should switch to "pair_style reax/c"_pair_reaxc.html. The {reax} style
 differs from the {reax/c} style in the lo-level implementation details.
 The {reax} style is a
 Fortran library, linked to LAMMPS.  The {reax/c} style was initially
@ -82,7 +82,7 @@ be specified.
 Two examples using {pair_style reax} are provided in the examples/reax
 sub-directory, along with corresponding examples for
-"pair_style reax/c"_pair_reax_c.html. Note that while the energy and force
+"pair_style reax/c"_pair_reaxc.html. Note that while the energy and force
 calculated by both of these pair styles match very closely, the
 contributions due to the valence angles differ slightly due to
 the fact that with {pair_style reax/c} the default value of {thb_cutoff_sq}
@ -201,7 +201,7 @@ appropriate units if your simulation doesn't use "real" units.
 [Related commands:]
-"pair_coeff"_pair_coeff.html, "pair_style reax/c"_pair_reax_c.html,
+"pair_coeff"_pair_coeff.html, "pair_style reax/c"_pair_reaxc.html,
 "fix_reax_bonds"_fix_reax_bonds.html
 [Default:]
--- a/doc/src/pair_reax_c.txt
+++ b/doc/src/pair_reax_c.txt
@ -8,6 +8,7 @@
 pair_style reax/c command :h3
 pair_style reax/c/kk command :h3
 pair_style reax/c/omp command :h3
 [Syntax:]
@ -17,6 +18,7 @@ cfile = NULL or name of a control file :ulb,l
 zero or more keyword/value pairs may be appended :l
 keyword = {checkqeq} or {lgvdw} or {safezone} or {mincap}
  {checkqeq} value = {yes} or {no} = whether or not to require qeq/reax fix
  {enobonds} value = {yes} or {no} = whether or not to tally energy of atoms with no bonds
  {lgvdw} value = {yes} or {no} = whether or not to use a low gradient vdW correction
  {safezone} = factor used for array allocation
  {mincap} = minimum size for array allocation :pre
@ -127,6 +129,13 @@ recommended value for parameter {thb} is 0.01, which can be set in the
 control file.  Note: Force field files are different for the original
 or lg corrected pair styles, using wrong ffield file generates an error message.
 Using the optional keyword {enobonds} with the value {yes}, the energy
 of atoms with no bonds (i.e. isolated atoms) is included in the total
 potential energy and the per-atom energy of that atom.  If the value
 {no} is specified then the energy of atoms with no bonds is set to zero.
 The latter behavior is usual not desired, as it causes discontinuities
 in the potential energy when the bonding of an atom drops to zero.
 Optional keywords {safezone} and {mincap} are used for allocating
 reax/c arrays.  Increasing these values can avoid memory problems, such
 as segmentation faults and bondchk failed errors, that could occur under
@ -331,7 +340,7 @@ reax"_pair_reax.html
 [Default:]
-The keyword defaults are checkqeq = yes, lgvdw = no, safezone = 1.2,
+The keyword defaults are checkqeq = yes, enobonds = yes, lgvdw = no, safezone = 1.2,
 mincap = 50.
 :line
--- a/doc/src/pair_sdk.txt
+++ b/doc/src/pair_sdk.txt
@ -134,7 +134,7 @@ respa"_run_style.html command.
 [Restrictions:]
-All of the lj/sdk pair styles are part of the USER-CG-CMM package.
+All of the lj/sdk pair styles are part of the USER-CGSDK package.
 The {lj/sdk/coul/long} style also requires the KSPACE package to be
 built (which is enabled by default).  They are only enabled if LAMMPS
 was built with that package.  See the "Making
--- a/doc/src/pair_snap.txt
+++ b/doc/src/pair_snap.txt
@ -10,7 +10,8 @@ pair_style snap command :h3
 [Syntax:]
-pair_style snap :pre
+pair_style snap
 :pre
 [Examples:]
@ -19,11 +20,11 @@ pair_coeff * * InP.snapcoeff In P InP.snapparam In In P P :pre
 [Description:]
-Style {snap} computes interactions
+Pair style {snap} computes interactions
 using the spectral neighbor analysis potential (SNAP)
 "(Thompson)"_#Thompson20142. Like the GAP framework of Bartok et al.
 "(Bartok2010)"_#Bartok20102, "(Bartok2013)"_#Bartok2013
-it uses bispectrum components
+which uses bispectrum components
 to characterize the local neighborhood of each atom
 in a very general way. The mathematical definition of the
 bispectrum calculation used by SNAP is identical
@ -139,10 +140,15 @@ The default values for these keywords are
 {rmin0} = 0.0
 {diagonalstyle} = 3
 {switchflag} = 0
-{bzeroflag} = 1 :ul
+{bzeroflag} = 1
 {quadraticflag} = 1 :ul
-Detailed definitions of these keywords are given on the "compute
+Detailed definitions for all the keywords are given on the "compute
 sna/atom"_compute_sna_atom.html doc page.
 If {quadraticflag} is set to 1, then the SNAP energy expression includes the quadratic term,
 0.5*B^t.alpha.B, where alpha is a symmetric {K} by {K} matrix.
 The SNAP element file should contain {K}({K}+1)/2 additional coefficients
 for each element, the upper-triangular elements of alpha.
 :line
--- a/doc/src/pair_srp.txt
+++ b/doc/src/pair_srp.txt
@ -150,6 +150,8 @@ hybrid"_pair_hybrid.html.
 This pair style requires the "newton"_newton.html command to be {on}
 for non-bonded interactions.
 This pair style is not compatible with "rigid body integrators"_fix_rigid.html
 [Related commands:]
 "pair_style hybrid"_pair_hybrid.html, "pair_coeff"_pair_coeff.html,
--- a/doc/src/pair_tersoff.txt
+++ b/doc/src/pair_tersoff.txt
@ -18,7 +18,7 @@ pair_style tersoff/table/omp command :h3
 pair_style style :pre
-style = {tersoff} or {tersoff/table} or {tersoff/gpu} or {tersoff/omp} or {tersoff/table/omp}
+style = {tersoff} or {tersoff/table} or {tersoff/gpu} or {tersoff/omp} or {tersoff/table/omp} :ul
 [Examples:]
--- a/doc/src/pair_vashishta.txt
+++ b/doc/src/pair_vashishta.txt
@ -7,6 +7,7 @@
 :line
 pair_style vashishta command :h3
 pair_style vashishta/gpu command :h3
 pair_style vashishta/omp command :h3
 pair_style vashishta/kk command :h3
 pair_style vashishta/table command :h3
--- a/doc/src/pair_yukawa_colloid.txt
+++ b/doc/src/pair_yukawa_colloid.txt
@ -35,7 +35,7 @@ cutoff.
 In contrast to "pair_style yukawa"_pair_yukawa.html, this functional
 form arises from the Coulombic interaction between two colloid
 particles, screened due to the presence of an electrolyte, see the
-book by "Safran"_#Safran for a derivation in the context of DVLO
+book by "Safran"_#Safran for a derivation in the context of DLVO
 theory.  "Pair_style yukawa"_pair_yukawa.html is a screened Coulombic
 potential between two point-charges and uses no such approximation.
--- a/doc/src/pair_zero.txt
+++ b/doc/src/pair_zero.txt
@ -14,7 +14,7 @@ pair_style zero cutoff {nocoeff} :pre
 zero = style name of this pair style
 cutoff = global cutoff (distance units)
-nocoeff = ignore all pair_coeff parameters (optional) :l
+nocoeff = ignore all pair_coeff parameters (optional) :ul
 [Examples:]
--- a/doc/src/pairs.txt
+++ b/doc/src/pairs.txt
@ -36,6 +36,7 @@ Pair Styles :h1
   pair_gayberne
   pair_gran
   pair_gromacs
   pair_gw
   pair_hbond_dreiding
   pair_hybrid
   pair_kim
@ -48,7 +49,6 @@ Pair Styles :h1
   pair_lj_cubic
   pair_lj_expand
   pair_lj_long
   pair_lj_sf
   pair_lj_smooth
   pair_lj_smooth_linear
   pair_lj_soft
@ -71,9 +71,10 @@ Pair Styles :h1
   pair_oxdna2
   pair_peri
   pair_polymorphic
   pair_python
   pair_quip
   pair_reax
-   pair_reax_c
+   pair_reaxc
   pair_resquared
   pair_sdk
   pair_smd_hertz
--- a/doc/src/python.txt
+++ b/doc/src/python.txt
@ -14,7 +14,7 @@ python func keyword args ... :pre
 func = name of Python function :ulb,l
 one or more keyword/args pairs must be appended :l
-keyword = {invoke} or {input} or {return} or {format} or {length} or {file} or {here} or {exists}
+keyword = {invoke} or {input} or {return} or {format} or {length} or {file} or {here} or {exists} or {source}
  {invoke} arg = none = invoke the previously defined Python function
  {input} args = N i1 i2 ... iN
    N = # of inputs to function
@ -36,7 +36,12 @@ keyword = {invoke} or {input} or {return} or {format} or {length} or {file} or {
  {here} arg = inline
    inline = one or more lines of Python code which defines func
             must be a single argument, typically enclosed between triple quotes
-  {exists} arg = none = Python code has been loaded by previous python command :pre
+  {exists} arg = none = Python code has been loaded by previous python command
  {source} arg = {filename} or {inline}
    filename = file of Python code which will be executed immediately
    inline = one or more lines of Python code which will be executed immediately
             must be a single argument, typically enclosed between triple quotes
 :pre
 :ule
 [Examples:]
@ -50,7 +55,7 @@ def factorial(n):
  return n * factorial(n-1)
 """ :pre
-python loop input 1 SELF return v_value format -f here """
+python loop input 1 SELF return v_value format pf here """
 def loop(lmpptr,N,cut0):
  from lammps import lammps
  lmp = lammps(ptr=lmpptr) :pre
@ -59,7 +64,7 @@ def loop(lmpptr,N,cut0):
  for i in range(N):
    cut = cut0 + i*0.1
-    lmp.set_variable("cut",cut)               # set a variable in LAMMPS
+    lmp.set_variable("cut",cut)                 # set a variable in LAMMPS
    lmp.command("pair_style lj/cut $\{cut\}")   # LAMMPS commands
    lmp.command("pair_coeff * * 1.0 1.0")
    lmp.command("run 100")
@ -67,12 +72,8 @@ def loop(lmpptr,N,cut0):
 [Description:]
-NOTE: It is not currently possible to use the "python"_python.html
+Define a Python function or execute a previously defined function or
-command described in this section with Python 3, only with Python 2.
+execute some arbitrary python code.
 The C API changed from Python 2 to 3 and the LAMMPS code is not
 compatible with both.
 Define a Python function or execute a previously defined function.
 Arguments, including LAMMPS variables, can be passed to the function
 from the LAMMPS input script and a value returned by the Python
 function to a LAMMPS variable.  The Python code for the function can
@ -107,7 +108,8 @@ command.
 The {func} setting specifies the name of the Python function.  The
 code for the function is defined using the {file} or {here} keywords
-as explained below.
+as explained below. In case of the {source} keyword, the name of
 the function is ignored.
 If the {invoke} keyword is used, no other keywords can be used, and a
 previous python command must have defined the Python function
@ -116,6 +118,13 @@ previously defined arguments and return value processed as explained
 below.  You can invoke the function as many times as you wish in your
 input script.
 If the {source} keyword is used, no other keywords can be used.
 The argument can be a filename or a string with python commands,
 either on a single line enclosed in quotes, or as multiple lines
 enclosed in triple quotes. These python commands will be passed
 to the python interpreter and executed immediately without registering
 a python function for future execution.
 The {input} keyword defines how many arguments {N} the Python function
 expects.  If it takes no arguments, then the {input} keyword should
 not be used.  Each argument can be specified directly as a value,
@ -310,7 +319,7 @@ which corresponds to SELF in the python command.  The first line of
 the function imports the Python module lammps.py in the python dir of
 the distribution.  The second line creates a Python object "lmp" which
 wraps the instance of LAMMPS that called the function.  The
-"ptr=lmpptr" argument is what makes that happen.  The thrid line
+"ptr=lmpptr" argument is what makes that happen.  The third line
 invokes the command() function in the LAMMPS library interface.  It
 takes a single string argument which is a LAMMPS input script command
 for LAMMPS to execute, the same as if it appeared in your input
@ -396,6 +405,9 @@ or other variables may have hidden side effects as well.  In these
 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.
 :line
 If you run Python code directly on your workstation, either
@ -477,19 +489,10 @@ python"_Section_python.html.  Note that it is important that the
 stand-alone LAMMPS executable and the LAMMPS shared library be
 consistent (built from the same source code files) in order for this
 to work.  If the two have been built at different times using
-different source files, problems may occur.
+different source files, problems may occur. 
 As described above, you can use the python command to invoke a Python
 function which calls back to LAMMPS through its Python-wrapped library
 interface.  However you cannot do the opposite.  I.e. you cannot call
 LAMMPS from Python and invoke the python command to "callback" to
 Python and execute a Python function.  LAMMPS will generate an error
 if you try to do that.  Note that we think there actually should be a
 way to do that, but haven't yet been able to figure out how to do it
 successfully.
 [Related commands:]
-"shell"_shell.html, "variable"_variable.html
+"shell"_shell.html, "variable"_variable.html, "fix python"_fix_python.html
 [Default:] none
--- a/doc/src/rerun.txt
+++ b/doc/src/rerun.txt
@ -15,7 +15,7 @@ rerun file1 file2 ... keyword args ... :pre
 file1,file2,... = dump file(s) to read :ulb,l
 one or more keywords may be appended, keyword {dump} must appear and be last :l
 keyword = {first} or {last} or {every} or {skip} or {start} or {stop} or {dump}
- {first} args = Nfirts
+ {first} args = Nfirst
   Nfirst = dump timestep to start on
 {last} args = Nlast
   Nlast = dumptimestep to stop on
--- a/doc/src/set.txt
+++ b/doc/src/set.txt
@ -80,6 +80,7 @@ keyword = {type} or {type/fraction} or {mol} or {x} or {y} or {z} or \
    value can be an atom-style variable (see below)
  {image} nx ny nz
    nx,ny,nz = which periodic image of the simulation box the atom is in
    any of nx,ny,nz can be an atom-style variable (see below)
  {bond} value = bond type for all bonds between selected atoms
  {angle} value = angle type for all angles between selected atoms
  {dihedral} value = dihedral type for all dihedrals between selected atoms
@ -363,9 +364,8 @@ A value of -1 means subtract 1 box length to get the true value.
 LAMMPS updates these flags as atoms cross periodic boundaries during
 the simulation.  The flags can be output with atom snapshots via the
 "dump"_dump.html command.  If a value of NULL is specified for any of
-nx,ny,nz, then the current image value for that dimension is
+nx,ny,nz, then the current image value for that dimension is unchanged.
-unchanged.  For non-periodic dimensions only a value of 0 can be
+For non-periodic dimensions only a value of 0 can be specified.
 specified.  This keyword does not allow use of atom-style variables.
 This command can be useful after a system has been equilibrated and
 atoms have diffused one or more box lengths in various directions.
 This command can then reset the image values for atoms so that they
--- a/doc/src/special_bonds.txt
+++ b/doc/src/special_bonds.txt
@ -65,7 +65,13 @@ sense to define permanent bonds between atoms that interact via these
 potentials, though such bonds may exist elsewhere in your system,
 e.g. when using the "pair_style hybrid"_pair_hybrid.html command.
 Thus LAMMPS ignores special_bonds settings when manybody potentials
-are calculated.
+are calculated.  Please note, that the existence of explicit bonds
 for atoms that are described by a manybody potential will alter the
 neigborlist and thus can render the computation of those interactions
 invalid, since those pairs are not only used to determine direct
 pairwise interactions but also neighbors of neighbors and more.
 The recommended course of action is to remove such bonds, or - if
 that is not possible - use a special bonds setting of 1.0 1.0 1.0.
 NOTE: Unlike some commands in LAMMPS, you cannot use this command
 multiple times in an incremental fashion: e.g. to first set the LJ
--- a/doc/src/tutorial_pylammps.txt
+++ b/doc/src/tutorial_pylammps.txt
@ -10,6 +10,7 @@ PyLammps Tutorial :h1
 <!-- RST
 .. contents::
 END_RST -->
 Overview :h2
@ -55,7 +56,7 @@ using the generated {auto} Makefile.
 cd $LAMMPS_DIR/src :pre
 # generate custom Makefile
-python2 Make.py -jpg -png -s ffmpeg exceptions -m mpi -a file :pre
+python Make.py -jpg -png -s ffmpeg exceptions -m mpi -a file :pre
 # add packages if necessary
 make yes-MOLECULE :pre
--- a/doc/src/velocity.txt
+++ b/doc/src/velocity.txt
@ -61,7 +61,7 @@ keyword/value parameters.  Not all options are used by each style.
 Each option has a default as listed below.
 The {create} style generates an ensemble of velocities using a random
-number generator with the specified seed as the specified temperature.
+number generator with the specified seed at the specified temperature.
 The {set} style sets the velocities of all atoms in the group to the
 specified values.  If any component is specified as NULL, then it is
--- a/examples/ASPHERE/poly/in.poly
+++ b/examples/ASPHERE/poly/in.poly
@ -62,6 +62,7 @@ pair_coeff	3 3 1.0 1.5
 pair_coeff	1 4 0.0 1.0 0.5
 pair_coeff	2 4 0.0 1.0 1.0
 pair_coeff	3 4 0.0 1.0 0.75
 pair_coeff	4 4 0.0 1.0 0.0
 delete_atoms	overlap 1.0 small big
--- a/examples/ASPHERE/poly/in.poly.mp
+++ b/examples/ASPHERE/poly/in.poly.mp
@ -62,6 +62,7 @@ pair_coeff	3 3 1.0 1.5
 pair_coeff	1 4 0.0 1.0 0.5
 pair_coeff	2 4 0.0 1.0 1.0
 pair_coeff	3 4 0.0 1.0 0.75
 pair_coeff	4 4 0.0 1.0 0.0
 delete_atoms	overlap 1.0 small big
--- a/examples/COUPLE/simple/simple.cpp
+++ b/examples/COUPLE/simple/simple.cpp
@ -153,7 +153,7 @@ int main(int narg, char **arg)
    for (int i = 0; i < natoms; i++) type[i] = 1;
    lmp->input->one("delete_atoms group all");
-    lammps_create_atoms(lmp,natoms,NULL,type,x,v);
+    lammps_create_atoms(lmp,natoms,NULL,type,x,v,NULL,0);
    lmp->input->one("run 10");
  }
--- a/examples/USER/cgdna/util/generate.py
+++ b/examples/USER/cgdna/util/generate.py
@ -14,7 +14,7 @@
 ------------------------------------------------------------------------- */
 /* ----------------------------------------------------------------------
-   Contributing author: Oliver Henrich (EPCC, University of Edinburgh)
+   Contributing author: Oliver Henrich (University of Strathclyde, Glasgow)
 ------------------------------------------------------------------------- */
 """
--- a/examples/USER/cg-cmm/README
+++ b/examples/USER/cg-cmm/README
@ -1,4 +1,4 @@
-LAMMPS USER-CMM-CG example problems
+LAMMPS USER-CGSDK example problems
 Each of these sub-directories contains a sample problem for the SDK
 coarse grained MD potentials that you can run with LAMMPS.
--- a/examples/USER/cg-cmm/peg-verlet/data.pegc12e8.gz
+++ b/examples/USER/cg-cmm/peg-verlet/data.pegc12e8.gz
--- a/examples/USER/cg-cmm/peg-verlet/in.pegc12e8
+++ b/examples/USER/cg-cmm/peg-verlet/in.pegc12e8
--- a/examples/USER/cg-cmm/peg-verlet/in.pegc12e8-angle
+++ b/examples/USER/cg-cmm/peg-verlet/in.pegc12e8-angle
--- a/examples/USER/cg-cmm/peg-verlet/log.pegc12e8
+++ b/examples/USER/cg-cmm/peg-verlet/log.pegc12e8
--- a/examples/USER/cg-cmm/peg-verlet/log.pegc12e8-angle
+++ b/examples/USER/cg-cmm/peg-verlet/log.pegc12e8-angle
--- a/Show More
+++ b/Show More