git-svn-id: svn://svn.icms.temple.edu/lammps-ro/trunk@16053 f3b2605a-c512-4ea7-a41b-209d697bcdaa

git-svn-id: svn://svn.icms.temple.edu/lammps-ro/trunk@16052 f3b2605a-c512-4ea7-a41b-209d697bcdaa
sync with latest GHub bug fixes
2017-01-26 21:05:57 +00:00 · 2017-01-26 21:05:55 +00:00 · 2017-01-26 20:54:58 +00:00 · 2017-01-26 02:07:37 +00:00 · 2017-01-23 23:04:40 +00:00 · 2017-01-23 22:40:21 +00:00
1016 changed files with 63817 additions and 33038 deletions
--- a/.gitignore
+++ b/.gitignore
@ -1,34 +0,0 @@
-*~
-*.o
-*.so
-*.cu_o
-*.ptx
-*_ptx.h
-*.a
-*.d
-*.x
-*.exe
-*.dll
-*.pyc
-__pycache__
-
-Obj_*
-log.lammps
-log.cite
-*.bz2
-*.gz
-*.tar
-.*.swp
-*.orig
-*.rej
-.vagrant
-\#*#
-.#*
-
-.DS_Store
-.DS_Store?
-._*
-.Spotlight-V100
-.Trashes
-ehthumbs.db
-Thumbs.db
--- a/doc/.gitignore
+++ b/doc/.gitignore
@ -1,5 +0,0 @@
-/html
-/LAMMPS.epub
-/LAMMPS.mobi
-/Manual.pdf
-/Developer.pdf
--- a/doc/src/Eqs/bond_oxdna_fene.jpg
+++ b/doc/src/Eqs/bond_oxdna_fene.jpg
--- a/doc/src/Eqs/bond_oxdna_fene.tex
+++ b/doc/src/Eqs/bond_oxdna_fene.tex
@ -0,0 +1,10 @@
+\documentclass[12pt]{article}
+\pagestyle{empty}
+
+\begin{document}
+
+$$ 
+  E = - \frac{\epsilon}{2} \ln \left[ 1 - \left(\frac{r-r0}{\Delta}\right)^2\right]
+$$
+
+\end{document}
--- a/doc/src/JPG/tutorial_additional_changes.png
+++ b/doc/src/JPG/tutorial_additional_changes.png
--- a/doc/src/JPG/tutorial_automated_checks.png
+++ b/doc/src/JPG/tutorial_automated_checks.png
--- a/doc/src/JPG/tutorial_automated_checks_passed.png
+++ b/doc/src/JPG/tutorial_automated_checks_passed.png
--- a/doc/src/JPG/tutorial_branch.png
+++ b/doc/src/JPG/tutorial_branch.png
--- a/doc/src/JPG/tutorial_changes_others.png
+++ b/doc/src/JPG/tutorial_changes_others.png
--- a/doc/src/JPG/tutorial_create_new_pull_request1.png
+++ b/doc/src/JPG/tutorial_create_new_pull_request1.png
--- a/doc/src/JPG/tutorial_create_new_pull_request2.png
+++ b/doc/src/JPG/tutorial_create_new_pull_request2.png
--- a/doc/src/JPG/tutorial_edits_maintainers.png
+++ b/doc/src/JPG/tutorial_edits_maintainers.png
--- a/doc/src/JPG/tutorial_fork.png
+++ b/doc/src/JPG/tutorial_fork.png
--- a/doc/src/JPG/tutorial_https_block.png
+++ b/doc/src/JPG/tutorial_https_block.png
--- a/doc/src/JPG/tutorial_merged.png
+++ b/doc/src/JPG/tutorial_merged.png
--- a/doc/src/JPG/tutorial_new_pull_request.png
+++ b/doc/src/JPG/tutorial_new_pull_request.png
--- a/doc/src/JPG/tutorial_reverse_pull_request.png
+++ b/doc/src/JPG/tutorial_reverse_pull_request.png
--- a/doc/src/JPG/tutorial_reverse_pull_request2.png
+++ b/doc/src/JPG/tutorial_reverse_pull_request2.png
--- a/doc/src/JPG/tutorial_reverse_pull_request3.png
+++ b/doc/src/JPG/tutorial_reverse_pull_request3.png
--- a/doc/src/JPG/tutorial_reverse_pull_request4.png
+++ b/doc/src/JPG/tutorial_reverse_pull_request4.png
--- a/doc/src/JPG/tutorial_reverse_pull_request5.png
+++ b/doc/src/JPG/tutorial_reverse_pull_request5.png
--- a/doc/src/JPG/tutorial_reverse_pull_request6.png
+++ b/doc/src/JPG/tutorial_reverse_pull_request6.png
--- a/doc/src/JPG/tutorial_reverse_pull_request7.png
+++ b/doc/src/JPG/tutorial_reverse_pull_request7.png
--- a/doc/src/JPG/tutorial_steve_assignee.png
+++ b/doc/src/JPG/tutorial_steve_assignee.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="17 Dec 2016 version">
+<META NAME="docnumber" CONTENT="26 Jan 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
-17 Dec 2016 version :c,h4
+26 Jan 2017 version :c,h4

 Version info: :h4

--- a/doc/src/PDF/USER-CGDNA-overview.pdf
+++ b/doc/src/PDF/USER-CGDNA-overview.pdf
--- a/doc/src/PDF/colvars-refman-lammps.pdf
+++ b/doc/src/PDF/colvars-refman-lammps.pdf
--- a/doc/src/Section_commands.txt
+++ b/doc/src/Section_commands.txt
@ -581,8 +581,9 @@ USER-INTEL, k = KOKKOS, o = USER-OMP, t = OPT.
 "indent"_fix_indent.html,
 "langevin (k)"_fix_langevin.html,
 "lineforce"_fix_lineforce.html,
-"momentum"_fix_momentum.html,
+"momentum (k)"_fix_momentum.html,
 "move"_fix_move.html,
+"mscg"_fix_mscg.html,
 "msst"_fix_msst.html,
 "neb"_fix_neb.html,
 "nph (ko)"_fix_nh.html,
@ -701,7 +702,10 @@ package"_Section_start.html#start_3.
 "meso"_fix_meso.html,
 "manifoldforce"_fix_manifoldforce.html,
 "meso/stationary"_fix_meso_stationary.html,
+"nve/dot"_fix_nve_dot.html,
+"nve/dotc/langevin"_fix_nve_dotc_langevin.html,
 "nve/manifold/rattle"_fix_nve_manifold_rattle.html,
+"nvk"_fix_nvk.html,
 "nvt/manifold/rattle"_fix_nvt_manifold_rattle.html,
 "nph/eff"_fix_nh_eff.html,
 "npt/eff"_fix_nh_eff.html,
@ -917,7 +921,7 @@ KOKKOS, o = USER-OMP, t = OPT.
 "dpd (go)"_pair_dpd.html,
 "dpd/tstat (go)"_pair_dpd.html,
 "dsmc"_pair_dsmc.html,
-"eam (gkot)"_pair_eam.html,
+"eam (gkiot)"_pair_eam.html,
 "eam/alloy (gkot)"_pair_eam.html,
 "eam/fs (gkot)"_pair_eam.html,
 "eim (o)"_pair_eim.html,
@ -1033,6 +1037,11 @@ package"_Section_start.html#start_3.
 "morse/soft"_pair_morse.html,
 "multi/lucy"_pair_multi_lucy.html,
 "multi/lucy/rx"_pair_multi_lucy_rx.html,
+"oxdna/coaxstk"_pair_oxdna.html,
+"oxdna/excv"_pair_oxdna.html,
+"oxdna/hbond"_pair_oxdna.html,
+"oxdna/stk"_pair_oxdna.html,
+"oxdna/xstk"_pair_oxdna.html,
 "quip"_pair_quip.html,
 "reax/c (k)"_pair_reax_c.html,
 "smd/hertz"_pair_smd_hertz.html,
@ -1081,7 +1090,8 @@ if "LAMMPS is built with the appropriate
 package"_Section_start.html#start_3.

 "harmonic/shift (o)"_bond_harmonic_shift.html,
-"harmonic/shift/cut (o)"_bond_harmonic_shift_cut.html :tb(c=4,ea=c)
+"harmonic/shift/cut (o)"_bond_harmonic_shift_cut.html,
+"oxdna/fene"_bond_oxdna_fene.html :tb(c=4,ea=c)

 :line

--- a/doc/src/Section_errors.txt
+++ b/doc/src/Section_errors.txt
@ -55,12 +55,13 @@ LAMMPS errors are detected at setup time; others like a bond
 stretching too far may not occur until the middle of a run.

 LAMMPS tries to flag errors and print informative error messages so
-you can fix the problem.  Of course, LAMMPS cannot figure out your
-physics or numerical mistakes, like choosing too big a timestep,
-specifying erroneous force field coefficients, or putting 2 atoms on
-top of each other!  If you run into errors that LAMMPS doesn't catch
-that you think it should flag, please send an email to the
-"developers"_http://lammps.sandia.gov/authors.html.
+you can fix the problem.  For most errors it will also print the last
+input script command that it was processing.  Of course, LAMMPS cannot
+figure out your physics or numerical mistakes, like choosing too big a
+timestep, specifying erroneous force field coefficients, or putting 2
+atoms on top of each other!  If you run into errors that LAMMPS
+doesn't catch that you think it should flag, please send an email to
+the "developers"_http://lammps.sandia.gov/authors.html.

 If you get an error message about an invalid command in your input
 script, you can determine what command is causing the problem by
--- a/doc/src/Section_packages.txt
+++ b/doc/src/Section_packages.txt
@ -84,7 +84,7 @@ Package, Description, Author(s), Doc page, Example, Library
 "PERI"_#PERI, Peridynamics models, Mike Parks (Sandia), "pair_style peri"_pair_peri.html, peri, -
 "POEMS"_#POEMS, coupled rigid body motion, Rudra Mukherjee (JPL), "fix poems"_fix_poems.html, rigid, lib/poems
 "PYTHON"_#PYTHON, embed Python code in an input script, -, "python"_python.html, python, lib/python
-"REAX"_#REAX, ReaxFF potential, Aidan Thompson (Sandia), "pair_style reax"_pair_reax.html, reax,  lib/reax
+"REAX"_#REAX, ReaxFF potential, Aidan Thompson (Sandia), "pair_style reax"_pair_reax.html, reax, lib/reax
 "REPLICA"_#REPLICA, multi-replica methods, -, "Section 6.6.5"_Section_howto.html#howto_5, tad, -
 "RIGID"_#RIGID, rigid bodies, -, "fix rigid"_fix_rigid.html, rigid, -
 "SHOCK"_#SHOCK, shock loading methods, -, "fix msst"_fix_msst.html, -, -
@ -1140,6 +1140,7 @@ Package, Description, Author(s), Doc page, Example, Pic/movie, Library
 "USER-ATC"_#USER-ATC, atom-to-continuum coupling, Jones & Templeton & Zimmerman (1), "fix atc"_fix_atc.html, USER/atc, "atc"_atc, lib/atc
 "USER-AWPMD"_#USER-AWPMD, wave-packet MD, Ilya Valuev (JIHT), "pair_style awpmd/cut"_pair_awpmd.html, USER/awpmd, -, lib/awpmd
 "USER-CG-CMM"_#USER-CG-CMM, coarse-graining model, Axel Kohlmeyer (Temple U), "pair_style lj/sdk"_pair_sdk.html, USER/cg-cmm, "cg"_cg, -
+"USER-CGDNA"_#USER-CGDNA, coarse-grained DNA force fields, Oliver Henrich (U Edinburgh), src/USER-CGDNA/README, USER/cgdna, -, -
 "USER-COLVARS"_#USER-COLVARS, collective variables, Fiorin & Henin & Kohlmeyer (2), "fix colvars"_fix_colvars.html, USER/colvars, "colvars"_colvars, lib/colvars
 "USER-DIFFRACTION"_#USER-DIFFRACTION, virutal x-ray and electron diffraction, Shawn Coleman (ARL),"compute xrd"_compute_xrd.html, USER/diffraction, -, -
 "USER-DPD"_#USER-DPD, reactive dissipative particle dynamics (DPD), Larentzos & Mattox & Brennan (5), src/USER-DPD/README, USER/dpd, -, -
@ -1153,7 +1154,7 @@ Package, Description, Author(s), Doc page, Example, Pic/movie, Library
 "USER-MISC"_#USER-MISC, single-file contributions, USER-MISC/README, USER-MISC/README, -, -, -
 "USER-MANIFOLD"_#USER-MANIFOLD, motion on 2d surface, Stefan Paquay (Eindhoven U of Technology), "fix manifoldforce"_fix_manifoldforce.html, USER/manifold, "manifold"_manifold, -
 "USER-MOLFILE"_#USER-MOLFILE, "VMD"_VMD molfile plug-ins, Axel Kohlmeyer (Temple U), "dump molfile"_dump_molfile.html, -, -, VMD-MOLFILE
-"USER-NC-DUMP"_#USER-NC-DUMP, dump output via NetCDF, Lars Pastewka (Karlsruhe Institute of Technology, KIT), "dump nc, dump nc/mpiio"_dump_nc.html, -, -, lib/netcdf
+"USER-NC-DUMP"_#USER-NC-DUMP, dump output via NetCDF, Lars Pastewka (Karlsruhe Institute of Technology, KIT), "dump nc / dump nc/mpiio"_dump_nc.html, -, -, lib/netcdf
 "USER-OMP"_#USER-OMP, OpenMP threaded styles, Axel Kohlmeyer (Temple U), "Section 5.3.4"_accelerate_omp.html, -, -, -
 "USER-PHONON"_#USER-PHONON, phonon dynamical matrix, Ling-Ti Kong (Shanghai Jiao Tong U), "fix phonon"_fix_phonon.html, USER/phonon, -, -
 "USER-QMMM"_#USER-QMMM, QM/MM coupling, Axel Kohlmeyer (Temple U), "fix qmmm"_fix_qmmm.html, USER/qmmm, -, lib/qmmm
@ -1284,6 +1285,31 @@ him directly if you have questions.

 :line

+USER-CGDNA package :link(USER-CGDNA),h5
+
+Contents: The CGDNA package implements coarse-grained force fields for
+single- and double-stranded DNA. This is at the moment mainly the
+oxDNA model, developed by Doye, Louis and Ouldridge at the University
+of Oxford.  The package also contains Langevin-type rigid-body
+integrators with improved stability.
+
+See these doc pages to get started:
+
+"bond_style oxdna_fene"_bond_oxdna_fene.html
+"pair_style oxdna_excv"_pair_oxdna_excv.html
+"fix nve/dotc/langevin"_fix_nve_dotc_langevin.html :ul
+
+Supporting info: /src/USER-CGDNA/README, "bond_style
+oxdna_fene"_bond_oxdna_fene.html, "pair_style
+oxdna_excv"_pair_oxdna_excv.html, "fix
+nve/dotc/langevin"_fix_nve_dotc_langevin.html
+
+Author: Oliver Henrich at the University of Edinburgh, UK (o.henrich
+at epcc.ed.ac.uk or ohenrich at ph.ed.ac.uk).  Contact him directly if
+you have any questions.
+
+:line
+
 USER-COLVARS package :link(USER-COLVARS),h5

 Contents: COLVARS stands for collective variables which can be used to
@ -1610,11 +1636,12 @@ and a "dump nc/mpiio"_dump_nc.html command to output LAMMPS snapshots
 in this format.  See src/USER-NC-DUMP/README for more details.

 NetCDF files can be directly visualized with the following tools:
+
 Ovito (http://www.ovito.org/). Ovito supports the AMBER convention
-  and all of the above extensions. :ulb,l
+and all of the above extensions. :ulb,l
 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
+a NetCDF reader that is not present in the standard distribution of AtomEye :l,ule

 The person who created these files is Lars Pastewka at
 Karlsruhe Institute of Technology (lars.pastewka at kit.edu).
--- a/doc/src/Section_start.txt
+++ b/doc/src/Section_start.txt
@ -1727,7 +1727,7 @@ thermodynamic state and a total run time for the simulation.  It then
 appends statistics about the CPU time and storage requirements for the
 simulation.  An example set of statistics is shown here:

-Loop time of 2.81192 on 4 procs for 300 steps with 2004 atoms
+Loop time of 2.81192 on 4 procs for 300 steps with 2004 atoms :pre

 Performance: 18.436 ns/day  1.302 hours/ns  106.689 timesteps/s
 97.0% CPU use with 4 MPI tasks x no OpenMP threads :pre
@ -1757,14 +1757,14 @@ Ave special neighs/atom = 2.34032
 Neighbor list builds = 26
 Dangerous builds = 0 :pre

-The first section provides a global loop timing summary. The loop time
+The first section provides a global loop timing summary. The {loop time}
 is the total wall time for the section.  The {Performance} line is
 provided for convenience to help predicting the number of loop
-continuations required and for comparing performance with other
-similar MD codes.  The CPU use line provides the CPU utilzation per
+continuations required and for comparing performance with other,
+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). Lower numbers correspond to delays due to file I/O or
-insufficient thread utilization.
+threads (or 1 of no OpenMP). Lower numbers correspond to delays due
+to file I/O or insufficient thread utilization.

 The MPI task section gives the breakdown of the CPU run time (in
 seconds) into major categories:
@ -1791,7 +1791,7 @@ is present that also prints the CPU utilization in percent. In
 addition, when using {timer full} and the "package omp"_package.html
 command are active, a similar timing summary of time spent in threaded
 regions to monitor thread utilization and load balance is provided. A
-new entry is the {Reduce} section, which lists the time spend in
+new entry is the {Reduce} section, which lists the time spent in
 reducing the per-thread data elements to the storage for non-threaded
 computation. These thread timings are taking from the first MPI rank
 only and and thus, as the breakdown for MPI tasks can change from MPI
--- a/doc/src/accelerate_intel.txt
+++ b/doc/src/accelerate_intel.txt
@ -29,7 +29,7 @@ Bond Styles: fene, harmonic :l
 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, gayberne,
+Pair Styles: buck/coul/cut, buck/coul/long, buck, eam, gayberne,
 charmm/coul/long, lj/cut, lj/cut/coul/long, sw, tersoff :l
 K-Space Styles: pppm :l
 :ule
--- a/doc/src/accelerate_kokkos.txt
+++ b/doc/src/accelerate_kokkos.txt
@ -110,14 +110,14 @@ mpirun -np 96 -ppn 12 lmp_g++ -k on t 20 -sf kk -in in.lj   # ditto on 8 Phis :p
 [Required hardware/software:]

 Kokkos support within LAMMPS must be built with a C++11 compatible
-compiler.  If using gcc, version 4.8.1 or later is required.
+compiler.  If using gcc, version 4.7.2 or later is required.

 To build with Kokkos support for CPUs, your compiler must support the
 OpenMP interface.  You should have one or more multi-core CPUs so that
 multiple threads can be launched by each MPI task running on a CPU.

 To build with Kokkos support for NVIDIA GPUs, NVIDIA Cuda software
-version 6.5 or later must be installed on your system.  See the
+version 7.5 or later must be installed on your system.  See the
 discussion for the "GPU"_accelerate_gpu.html package for details of
 how to check and do this.

--- a/doc/src/bond_oxdna_fene.txt
+++ b/doc/src/bond_oxdna_fene.txt
@ -0,0 +1,70 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+bond_style oxdna_fene command :h3
+
+[Syntax:]
+
+bond_style oxdna_fene :pre
+
+[Examples:]
+
+bond_style oxdna_fene
+bond_coeff * 2.0 0.25 0.7525 :pre
+
+[Description:]
+
+The {oxdna_fene} bond style uses the potential
+
+:c,image(Eqs/bond_oxdna_fene.jpg)
+
+to define a modified finite extensible nonlinear elastic (FENE) potential
+"(Ouldridge)"_#oxdna_fene to model the connectivity of the phosphate backbone
+in the oxDNA force field for coarse-grained modelling of DNA. 
+
+The following coefficients must be defined for the bond type via the
+"bond_coeff"_bond_coeff.html command as given in the above example, or in
+the data file or restart files read by the "read_data"_read_data.html
+or "read_restart"_read_restart.html commands:
+
+epsilon (energy)
+Delta (distance)
+r0 (distance) :ul
+
+NOTE: This bond style has to be used together with the corresponding oxDNA pair styles
+for excluded volume interaction {oxdna_excv}, stacking {oxdna_stk}, cross-stacking {oxdna_xstk}
+and coaxial stacking interaction {oxdna_coaxstk} as well as hydrogen-bonding interaction {oxdna_hbond} (see also documentation of 
+"pair_style oxdna_excv"_pair_oxdna_excv.html). The coefficients 
+in the above example have to be kept fixed and cannot be changed without reparametrizing the entire model.
+
+Example input and data files can be found in /examples/USER/cgdna/examples/duplex1/ and /duplex2/.
+A simple python setup tool which creates single straight or helical DNA strands,
+DNA duplexes or arrays of DNA duplexes can be found in /examples/USER/cgdna/util/.
+A technical report with more information on the model, the structure of the input file,
+the setup tool and the performance of the LAMMPS-implementation of oxDNA
+can be found "here"_PDF/USER-CGDNA-overview.pdf.
+
+:line
+
+[Restrictions:]
+
+This bond style can only be used if LAMMPS was built with the
+USER-CGDNA package and the MOLECULE and ASPHERE package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
+
+
+[Related commands:]
+
+"pair_style oxdna_excv"_pair_oxdna_excv.html, "fix nve/dotc/langevin"_fix_nve_dotc_langevin.html, "bond_coeff"_bond_coeff.html 
+
+[Default:] none
+
+:line
+
+:link(oxdna_fene)
+[(Ouldridge)] T.E. Ouldridge, A.A. Louis, J.P.K. Doye, J. Chem. Phys. 134, 085101 (2011).
--- a/doc/src/bonds.txt
+++ b/doc/src/bonds.txt
@ -15,6 +15,7 @@ Bond Styles :h1
   bond_morse
   bond_none
   bond_nonlinear
+   bond_oxdna_fene
   bond_quartic
   bond_table
   bond_zero
--- a/doc/src/commands.txt
+++ b/doc/src/commands.txt
@ -91,6 +91,7 @@ Commands :h1
   suffix
   tad
   temper
+   temper_grem
   thermo
   thermo_modify
   thermo_style
--- a/doc/src/compute_coord_atom.txt
+++ b/doc/src/compute_coord_atom.txt
@ -10,34 +10,43 @@ compute coord/atom command :h3

 [Syntax:]

-compute ID group-ID coord/atom cutoff type1 type2 ... :pre
+compute ID group-ID coord/atom cstyle args ... :pre

-ID, group-ID are documented in "compute"_compute.html command
-coord/atom = style name of this compute command
-cutoff = distance within which to count coordination neighbors (distance units)
-typeN = atom type for Nth coordination count (see asterisk form below) :ul
+ID, group-ID are documented in "compute"_compute.html command :ulb,l
+coord/atom = style name of this compute command :l
+cstyle = {cutoff} or {orientorder} :l
+  {cutoff} args = cutoff typeN
+    cutoff = distance within which to count coordination neighbors (distance units)
+    typeN = atom type for Nth coordination count (see asterisk form below)
+  {orientorder} args = orientorderID threshold
+    orientorderID = ID of an orientorder/atom compute
+    threshold = minimum value of the product of two "connected" atoms :pre
+:ule

 [Examples:]

-compute 1 all coord/atom 2.0
-compute 1 all coord/atom 6.0 1 2
-compute 1 all coord/atom 6.0 2*4 5*8 * :pre
+compute 1 all coord/atom cutoff 2.0
+compute 1 all coord/atom cutoff 6.0 1 2
+compute 1 all coord/atom cutoff 6.0 2*4 5*8 *
+compute 1 all coord/atom orientorder 2 0.5 :pre

 [Description:]

-Define a computation that calculates one or more coordination numbers
-for each atom in a group.
+This compute performs calculations between neighboring atoms to
+determine a coordination value.  The specific calculation and the
+meaning of the resulting value depend on the {cstyle} keyword used.

-A coordination number is defined as the number of neighbor atoms with
-specified atom type(s) that are within the specified cutoff distance
-from the central atom.  Atoms not in the group are included in a
-coordination number of atoms in the group.
+The {cutoff} cstyle calculates one or more traditional coordination
+numbers for each atom.  A coordination number is defined as the number
+of neighbor atoms with specified atom type(s) that are within the
+specified cutoff distance from the central atom.  Atoms not in the
+specified group are included in the coordination number tally.

-The {typeN} keywords allow you to specify which atom types contribute
-to each coordination number.  One coordination number is computed for
-each of the {typeN} keywords listed.  If no {typeN} keywords are
-listed, a single coordination number is calculated, which includes
-atoms of all types (same as the "*" format, see below).
+The {typeN} keywords allow specification of which atom types
+contribute to each coordination number.  One coordination number is
+computed for each of the {typeN} keywords listed.  If no {typeN}
+keywords are listed, a single coordination number is calculated, which
+includes atoms of all types (same as the "*" format, see below).

 The {typeN} keywords can be specified in one of two ways.  An explicit
 numeric value can be used, as in the 2nd example above.  Or a
@ -49,8 +58,27 @@ from 1 to N.  A leading asterisk means all types from 1 to n
 (inclusive).  A middle asterisk means all types from m to n
 (inclusive).

-The value of all coordination numbers will be 0.0 for atoms not in the
-specified compute group.
+The {orientorder} cstyle calculates the number of "connected" neighbor
+atoms J around each central atom I.  For this {cstyle}, connected is
+defined by the orientational order parameter calculated by the
+"compute orientorder/atom"_compute_orientorder_atom.html command.
+This {cstyle} thus allows one to apply the ten Wolde's criterion to
+identify crystal-like atoms in a system, as discussed in "ten
+Wolde"_#tenWolde.
+
+The ID of the previously specified "compute
+orientorder/atom"_compute_orientorder/atom command is specified as
+{orientorderID}.  The compute must invoke its {components} option to
+calculate components of the {Ybar_lm} vector for each atoms, as
+described in its documenation.  Note that orientorder/atom compute
+defines its own criteria for identifying neighboring atoms.  If the
+scalar product ({Ybar_lm(i)},{Ybar_lm(j)}), calculated by the
+orientorder/atom compute is larger than the specified {threshold},
+then I and J are connected, and the coordination value of I is
+incremented by one.
+
+For all {cstyle} settings, all coordination values will be 0.0 for
+atoms not in the specified compute group.

 The neighbor list needed to compute this quantity is constructed each
 time the calculation is performed (i.e. each time a snapshot of atoms
@ -72,11 +100,16 @@ the neighbor list.

 [Output info:]

-If single {type1} keyword is specified (or if none are specified),
-this compute calculates a per-atom vector.  If multiple {typeN}
-keywords are specified, this compute calculates a per-atom array, with
-N columns.  These values can be accessed by any command that uses
-per-atom values from a compute as input.  See "Section
+For {cstyle} cutoff, this compute can calculate a per-atom vector or
+array.  If single {type1} keyword is specified (or if none are
+specified), this compute calculates a per-atom vector.  If multiple
+{typeN} keywords are specified, this compute calculates a per-atom
+array, with N columns.
+
+For {cstyle} orientorder, this compute calculates a per-atom vector.
+
+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
 options.

@ -88,5 +121,12 @@ explained above.
 [Related commands:]

 "compute cluster/atom"_compute_cluster_atom.html
+"compute orientorder/atom"_compute_orientorder_atom.html

 [Default:] none
+
+:line
+
+:link(tenWolde)
+[(tenWolde)] P. R. ten Wolde, M. J. Ruiz-Montero, D. Frenkel,
+J. Chem. Phys. 104, 9932 (1996).
--- a/doc/src/compute_orientorder_atom.txt
+++ b/doc/src/compute_orientorder_atom.txt
@ -15,17 +15,19 @@ compute ID group-ID orientorder/atom keyword values ... :pre
 ID, group-ID are documented in "compute"_compute.html command :ulb,l
 orientorder/atom = style name of this compute command :l
 one or more keyword/value pairs may be appended :l
-keyword = {cutoff} or {nnn} or {degrees}
+keyword = {cutoff} or {nnn} or {degrees} or {components}
  {cutoff} value = distance cutoff
  {nnn} value = number of nearest neighbors
-  {degrees} values = nlvalues, l1, l2,...  :pre
+  {degrees} values = nlvalues, l1, l2,...
+  {components} value = ldegree  :pre

 :ule

 [Examples:]

 compute 1 all orientorder/atom
-compute 1 all orientorder/atom degrees 5 4 6 8 10 12 nnn NULL cutoff 1.5 :pre
+compute 1 all orientorder/atom degrees 5 4 6 8 10 12 nnn NULL cutoff 1.5
+compute 1 all orientorder/atom degrees 4 6 components 6 nnn NULL cutoff 3.0 :pre

 [Description:]

@ -62,14 +64,21 @@ specified distance cutoff are used.
 The optional keyword {degrees} defines the list of order parameters to
 be computed.  The first argument {nlvalues} is the number of order
 parameters. This is followed by that number of integers giving the
-degree of each order parameter. Because {Q}2 and all odd-degree
-order parameters are zero for atoms in cubic crystals
-(see "Steinhardt"_#Steinhardt), the default order parameters
-are {Q}4, {Q}6, {Q}8, {Q}10, and {Q}12. For the
-FCC crystal with {nnn}=12, {Q}4 = sqrt(7/3)/8 = 0.19094....
-The numerical values of all order parameters up to {Q}12
-for a range of commonly encountered high-symmetry structures are given
-in Table I of "Mickel et al."_#Mickel.
+degree of each order parameter. Because {Q}2 and all odd-degree order
+parameters are zero for atoms in cubic crystals (see
+"Steinhardt"_#Steinhardt), the default order parameters are {Q}4,
+{Q}6, {Q}8, {Q}10, and {Q}12. For the FCC crystal with {nnn}=12, {Q}4
+= sqrt(7/3)/8 = 0.19094....  The numerical values of all order
+parameters up to {Q}12 for a range of commonly encountered
+high-symmetry structures are given in Table I of "Mickel et
+al."_#Mickel.
+
+The optional keyword {components} will output the components of the
+normalized complex vector {Ybar_lm} of degree {ldegree}, which must be
+explicitly included in the keyword {degrees}. This option can be used
+in conjunction with "compute coord_atom"_compute_coord_atom.html to
+calculate the ten Wolde's criterion to identify crystal-like
+particles, as discussed in "ten Wolde"_#tenWolde.

 The value of {Ql} is set to zero for atoms not in the
 specified compute group, as well as for atoms that have less than
@ -95,8 +104,16 @@ the neighbor list.

 [Output info:]

-This compute calculates a per-atom array with {nlvalues} columns, giving the
-{Ql} values for each atom, which are real numbers on the range 0 <= {Ql} <= 1.
+This compute calculates a per-atom array with {nlvalues} columns,
+giving the {Ql} values for each atom, which are real numbers on the
+range 0 <= {Ql} <= 1.
+
+If the keyword {components} is set, then the real and imaginary parts
+of each component of (normalized) {Ybar_lm} will be added to the
+output array in the following order: Re({Ybar_-m}) Im({Ybar_-m})
+Re({Ybar_-m+1}) Im({Ybar_-m+1}) ... Re({Ybar_m}) Im({Ybar_m}).  This
+way, the per-atom array will have a total of {nlvalues}+2*(2{l}+1)
+columns.

 These values can be accessed by any command that uses
 per-atom values from a compute as input.  See "Section
@ -107,15 +124,25 @@ options.

 [Related commands:]

-"compute coord/atom"_compute_coord_atom.html, "compute centro/atom"_compute_centro_atom.html, "compute hexorder/atom"_compute_hexorder_atom.html
+"compute coord/atom"_compute_coord_atom.html, "compute
+centro/atom"_compute_centro_atom.html, "compute
+hexorder/atom"_compute_hexorder_atom.html

 [Default:]

-The option defaults are {cutoff} = pair style cutoff, {nnn} = 12, {degrees} = 5 4 6 8 10 12 i.e. {Q}4, {Q}6, {Q}8, {Q}10, and {Q}12.
+The option defaults are {cutoff} = pair style cutoff, {nnn} = 12,
+{degrees} = 5 4 6 8 10 12 i.e. {Q}4, {Q}6, {Q}8, {Q}10, and {Q}12.

 :line

 :link(Steinhardt)
-[(Steinhardt)] P. Steinhardt, D. Nelson, and M. Ronchetti, Phys. Rev. B 28, 784 (1983).
+[(Steinhardt)] P. Steinhardt, D. Nelson, and M. Ronchetti,
+Phys. Rev. B 28, 784 (1983).
+
 :link(Mickel)
-[(Mickel)] W. Mickel, S. C. Kapfer, G. E. Schroeder-Turkand, K. Mecke, J. Chem. Phys. 138, 044501 (2013).
+[(Mickel)] W. Mickel, S. C. Kapfer, G. E. Schroeder-Turkand, K. Mecke,
+J. Chem. Phys. 138, 044501 (2013).
+
+:link(tenWolde)
+[(tenWolde)] P. R. ten Wolde, M. J. Ruiz-Montero, D. Frenkel,
+J. Chem. Phys. 104, 9932 (1996).
--- a/doc/src/compute_temp_asphere.txt
+++ b/doc/src/compute_temp_asphere.txt
--- a/doc/src/compute_temp_body.txt
+++ b/doc/src/compute_temp_body.txt
--- a/doc/src/compute_temp_sphere.txt
+++ b/doc/src/compute_temp_sphere.txt
--- a/doc/src/computes.txt
+++ b/doc/src/computes.txt
@ -35,6 +35,7 @@ Computes :h1
   compute_erotate_sphere_atom
   compute_event_displace
   compute_fep
+   compute_global_atom
   compute_group_group
   compute_gyration
   compute_gyration_chunk
--- a/doc/src/fix_bond_break.txt
+++ b/doc/src/fix_bond_break.txt
--- a/doc/src/fix_bond_create.txt
+++ b/doc/src/fix_bond_create.txt
--- a/doc/src/fix_bond_swap.txt
+++ b/doc/src/fix_bond_swap.txt
--- a/doc/src/fix_colvars.txt
+++ b/doc/src/fix_colvars.txt
@ -31,21 +31,19 @@ fix abf all colvars colvars.inp tstat 1 :pre

 [Description:]

-This fix interfaces LAMMPS to a "collective variables" or "colvars"
-module library which allows to calculate potentials of mean force
+This fix interfaces LAMMPS to the collective variables "Colvars"
+library, which allows to calculate potentials of mean force
 (PMFs) for any set of colvars, using different sampling methods:
 currently implemented are the Adaptive Biasing Force (ABF) method,
 metadynamics, Steered Molecular Dynamics (SMD) and Umbrella Sampling
-(US) via a flexible harmonic restraint bias. The colvars library is
-hosted at "http://colvars.github.io/"_http://colvars.github.io/
+(US) via a flexible harmonic restraint bias.

 This documentation describes only the fix colvars command itself and
 LAMMPS specific parts of the code.  The full documentation of the
 colvars library is available as "this supplementary PDF document"_PDF/colvars-refman-lammps.pdf

-A detailed discussion of the implementation of the portable collective
-variable library is in "(Fiorin)"_#Fiorin. Additional information can
-be found in "(Henin)"_#Henin.
+The Colvars library is developed at "https://github.com/colvars/colvars"_https://github.com/colvars/colvars
+A detailed discussion of its implementation is in "(Fiorin)"_#Fiorin.

 There are some example scripts for using this package with LAMMPS in the
 examples/USER/colvars directory.
@ -129,8 +127,3 @@ and tstat = NULL.

 :link(Fiorin)
 [(Fiorin)] Fiorin , Klein, Henin, Mol. Phys., DOI:10.1080/00268976.2013.813594
-
-:link(Henin)
-[(Henin)] Henin, Fiorin, Chipot, Klein, J. Chem. Theory Comput., 6,
-35-47 (2010)
-
--- a/doc/src/fix_eos_table_rx.txt
+++ b/doc/src/fix_eos_table_rx.txt
@ -10,7 +10,7 @@ fix eos/table/rx command :h3

 [Syntax:]

-fix ID group-ID eos/table/rx style file1 N keyword file2 :pre
+fix ID group-ID eos/table/rx style file1 N keyword ... :pre

 ID, group-ID are documented in "fix"_fix.html command
 eos/table/rx = style name of this fix command
@ -18,11 +18,16 @@ style = {linear} = method of interpolation
 file1 = filename containing the tabulated equation of state
 N = use N values in {linear} tables
 keyword = name of table keyword correponding to table file
-file2 = filename containing the heats of formation of each species :ul
+file2 = filename containing the heats of formation of each species (optional)
+deltaHf = heat of formation for a single species in energy units (optional)
+energyCorr = energy correction in energy units (optional)
+tempCorrCoeff = temperature correction coefficient (optional) :ul

 [Examples:]

-fix 1 all eos/table/rx linear eos.table 10000 KEYWORD thermo.table :pre
+fix 1 all eos/table/rx linear eos.table 10000 KEYWORD thermo.table
+fix 1 all eos/table/rx linear eos.table 10000 KEYWORD 1.5
+fix 1 all eos/table/rx linear eos.table 10000 KEYWORD 1.5 0.025 0.0 :pre

 [Description:]

@ -39,7 +44,15 @@ where {m} is the number of species, {c_i,j} is the concentration of
 species {j} in particle {i}, {u_j} is the internal energy of species j,
 {DeltaH_f,j} is the heat of formation of species {j}, N is the number of
 molecules represented by the coarse-grained particle, kb is the
-Boltzmann constant, and T is the temperature of the system.
+Boltzmann constant, and T is the temperature of the system.  Additionally,
+it is possible to modify the concentration-dependent particle internal 
+energy relation by adding an energy correction, temperature-dependent 
+correction, and/or a molecule-dependent correction.  An energy correction can
+be specified as a constant (in energy units).  A temperature correction can be 
+specified by multiplying a temperature correction coefficient by the 
+internal temperature.  A molecular correction can be specified by 
+by multiplying a molecule correction coefficient by the average number of 
+product gas particles in the coarse-grain particle. 

 Fix {eos/table/rx} creates interpolation tables of length {N} from {m}
 internal energy values of each species {u_j} listed in a file as a
@ -58,6 +71,14 @@ file is described below.
 The second filename specifies a file containing heat of formation
 {DeltaH_f,j} for each species.

+In cases where the coarse-grain particle represents a single molecular
+species (i.e., no reactions occur and fix {rx} is not present in the input file), 
+fix {eos/table/rx} can be applied in a similar manner to fix {eos/table} 
+within a non-reactive DPD simulation.  In this case, the heat of formation 
+filename is replaced with the heat of formation value for the single species.
+Additionally, the energy correction and temperature correction coefficients may 
+also be specified as fix arguments.  
+
 :line

 The format of a tabulated file is as follows (without the
@ -116,6 +137,19 @@ Note that the species can be listed in any order.  The tag that is
 used as the species name must correspond with the tags used to define
 the reactions with the "fix rx"_fix_rx.html command.

+Alternatively, corrections to the EOS can be included by specifying
+three additional columns that correspond to the energy correction, 
+the temperature correction coefficient and molecule correction 
+coefficient.  In this case, the format of the file is as follows:
+
+# HEAT OF FORMATION TABLE     (one or more comment or blank lines) :pre
+                              (blank)
+h2      0.00 1.23 0.025  0.0  (species name, heat of formation, energy correction, temperature correction coefficient, molecule correction coefficient)
+no2     0.34 0.00 0.000 -1.76
+n2      0.00 0.00 0.000 -1.76
+...
+no      0.93 0.00 0.000 -1.76 :pre
+
 :line

 [Restrictions:]
--- a/doc/src/fix_flow_gauss.txt
+++ b/doc/src/fix_flow_gauss.txt
@ -151,7 +151,7 @@ The option default for the {energy} keyword is energy = no.
 :line

 :link(Strong)
-[(Strong)] Strong and Eaves, J. Phys. Chem. Lett. 7, 1907 (2016).
+[(Strong)] Strong and Eaves, J. Phys. Chem. B 121, 189 (2017).

 :link(Evans)
 [(Evans)] Evans and Morriss, Phys. Rev. Lett. 56, 2172 (1986).
--- a/doc/src/fix_grem.txt
+++ b/doc/src/fix_grem.txt
@ -29,7 +29,7 @@ fix             fxgREM all grem 502 -0.15 -80000 fxnvt :pre
 [Description:]

 This fix implements the molecular dynamics version of the generalized
-replica exchange method (gREM) originally developed by "(Kim)"_#Kim,
+replica exchange method (gREM) originally developed by "(Kim)"_#Kim2010,
 which uses non-Boltzmann ensembles to sample over first order phase
 transitions. The is done by defining replicas with an enthalpy
 dependent effective temperature
@ -103,7 +103,7 @@ npt"_fix_nh.html, "thermo_modify"_thermo_modify.html

 :line

-:link(Kim)
+:link(Kim2010)
 [(Kim)] Kim, Keyes, Straub, J Chem. Phys, 132, 224107 (2010).

 :link(Malolepsza)
--- a/doc/src/fix_lb_fluid.txt
+++ b/doc/src/fix_lb_fluid.txt
--- a/doc/src/fix_lb_momentum.txt
+++ b/doc/src/fix_lb_momentum.txt
--- a/doc/src/fix_lb_pc.txt
+++ b/doc/src/fix_lb_pc.txt
--- a/doc/src/fix_lb_rigid_pc_sphere.txt
+++ b/doc/src/fix_lb_rigid_pc_sphere.txt
--- a/doc/src/fix_lb_viscous.txt
+++ b/doc/src/fix_lb_viscous.txt
--- a/doc/src/fix_momentum.txt
+++ b/doc/src/fix_momentum.txt
@ -7,6 +7,7 @@
 :line

 fix momentum command :h3
+fix momentum/kk command :h3

 [Syntax:]

@ -55,6 +56,29 @@ of atoms by rescaling the velocities after the momentum was removed.
 Note that the "velocity"_velocity.html command can be used to create
 initial velocities with zero aggregate linear and/or angular momentum.

+: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.
+
 [Restart, fix_modify, output, run start/stop, minimize info:]

 No information about this fix is written to "binary restart
--- a/doc/src/fix_mscg.txt
+++ b/doc/src/fix_mscg.txt
@ -0,0 +1,130 @@
+"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 mscg command :h3
+
+[Syntax:]
+
+fix ID group-ID mscg N keyword args ... :pre
+
+ID, group-ID are documented in "fix"_fix.html command :ulb,l
+mscg = style name of this fix command :l
+N = envoke this fix every this many timesteps :l
+zero or more keyword/value pairs may be appended :l
+keyword = {range} or {name} or {max} :l
+  {range} arg = {on} or {off}
+    {on} = range finding functionality is performed
+    {off} = force matching functionality is performed
+  {name} args = name1 ... nameN
+    name1,...,nameN = string names for each atom type (1-Ntype)
+  {max} args = maxb maxa maxd
+    maxb,maxa,maxd = maximum bonds/angles/dihedrals per atom :pre
+:ule
+
+[Examples:]
+
+fix 1 all mscg 1
+fix 1 all mscg 1 range name A B
+fix 1 all mscg 1 max 4 8 20 :pre
+
+[Description:]
+
+This fix applies the Multi-Scale Coarse-Graining (MSCG) method to
+snapshots from a dump file to generate potentials for coarse-grained
+simulations from all-atom simulations, using a force-matching
+technique ("Izvekov"_#Izvekov, "Noid"_#Noid).
+
+It makes use of the MS-CG library, written and maintained by Greg
+Voth's group at the University of Chicago, which is freely available
+on their "MS-CG GitHub
+site"_https://github.com/uchicago-voth/MSCG-release.  See instructions
+on obtaining and installing the MS-CG library in the src/MSCG/README
+file, which must be done before you build LAMMPS with this fix command
+and use the command in a LAMMPS input script.
+
+An example script using this fix is provided the examples/mscg
+directory.
+
+The general workflow for using LAMMPS in conjunction with the MS-CG
+library to create a coarse-grained model and run coarse-grained
+simulations is as follows:
+
+Perform all-atom simulations on the system to be coarse grained.
+Generate a trajectory mapped to the coarse-grained model.
+Create input files for the MS-CG library.
+Run the range finder functionality of the MS-CG library.  
+Run the force matching functionality of the MS-CG library.
+Check the results of the force matching.
+Run coarse-grained simulations using the new coarse-grained potentials. :ol
+
+This fix can perform the range finding and force matching steps 4 and
+5 of the above workflow when used in conjunction with the
+"rerun"_rerun.html command.  It does not perform steps 1-3 and 6-7.
+
+Step 2 can be performed using a Python script (what is the name?)
+provided with the MS-CG library which defines the coarse-grained model
+and converts a standard LAMMPS dump file for an all-atom simulation
+(step 1) into a LAMMPS dump file which has the positions of and forces
+on the coarse-grained beads.  
+
+In step 3, an input file named "control.in" is needed by the MS-CG
+library which sets parameters for the range finding and force matching
+functionalities.  See the examples/mscg/control.in file as an example.
+And see the documentation provided with the MS-CG library for more
+info on this file.
+
+When this fix is used to perform steps 4 and 5, the MS-CG library also
+produces additional output files.  The range finder functionality
+(step 4) outputs files defining pair and bonded interaction ranges.
+The force matching functionality (step 5) outputs tabulated force
+files for every interaction in the system. Other diagnostic files can
+also be output depending on the paramters in the MS-CG library input
+script.  Again, see the documentation provided with the MS-CG library
+for more info.
+
+:line
+
+The {range} keyword specifies which MS-CG library functionality should
+be invoked. If {on}, the step 4 range finder functionality is invoked.
+{off}, the step 5 force matching functionality is invoked.
+
+If the {name} keyword is used, string names are defined to associate
+with the integer atom types in LAMMPS.  {Ntype} names must be
+provided, one for each atom type (1-Ntype).
+
+The {max} keyword specifies the maximum number of bonds, angles, and
+dihedrals a bead can have in the coarse-grained model.
+
+[Restrictions:]
+
+This fix is part of the MSCG 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.
+
+The MS-CG library uses C++11, which may not be supported by older
+compilers. The MS-CG library also has some additional numeric library
+dependencies, which are describd in its documentation.
+
+Currently, the MS-CG library is not setup to run in parallel with MPI,
+so this fix can only be used in a serial LAMMPS build and run
+on a single processor.
+
+[Related commands:] none
+
+[Default:]
+
+The default keyword settings are range off, max 4 12 36.
+
+:line
+
+:link(Izvekov)
+[(Izvekov)] Izvekov, Voth, J Chem Phys 123, 134105 (2005).
+
+:link(Noid)
+[(Noid)] Noid, Chu, Ayton, Krishna, Izvekov, Voth, Das, Andersen, J
+Chem Phys 128, 134105 (2008).
--- a/doc/src/fix_nph_asphere.txt
+++ b/doc/src/fix_nph_asphere.txt
--- a/doc/src/fix_nph_body.txt
+++ b/doc/src/fix_nph_body.txt
--- a/doc/src/fix_nph_sphere.txt
+++ b/doc/src/fix_nph_sphere.txt
--- a/doc/src/fix_npt_asphere.txt
+++ b/doc/src/fix_npt_asphere.txt
--- a/doc/src/fix_npt_body.txt
+++ b/doc/src/fix_npt_body.txt
--- a/doc/src/fix_npt_sphere.txt
+++ b/doc/src/fix_npt_sphere.txt
--- a/doc/src/fix_nve_asphere.txt
+++ b/doc/src/fix_nve_asphere.txt
--- a/doc/src/fix_nve_asphere_noforce.txt
+++ b/doc/src/fix_nve_asphere_noforce.txt
--- a/doc/src/fix_nve_body.txt
+++ b/doc/src/fix_nve_body.txt
--- a/doc/src/fix_nve_dot.txt
+++ b/doc/src/fix_nve_dot.txt
@ -0,0 +1,61 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+fix nve/dot command :h3
+
+[Syntax:]
+
+fix ID group-ID nve/dot :pre
+
+ID, group-ID are documented in "fix"_fix.html command :ulb,l
+nve/dot = style name of this fix command :l
+:ule
+
+[Examples:]
+
+fix 1 all nve/dot :pre
+
+[Description:]
+
+Apply a rigid-body integrator as described in "(Davidchack)"_#Davidchack
+to a group of atoms, but without Langevin dynamics. 
+This command performs Molecular dynamics (MD)
+via a velocity-Verlet algorithm and an evolution operator that rotates 
+the quaternion degrees of freedom, similar to the scheme outlined in "(Miller)"_#Miller. 
+
+This command is the equivalent of the "fix nve/dotc/langevin"_fix_nve_dotc_langevin.html
+without damping and noise and can be used to determine the stability range 
+in a NVE ensemble prior to using the Langevin-type DOTC-integrator
+(see also "fix nve/dotc/langevin"_fix_nve_dotc_langevin.html).
+The command is equivalent to the "fix nve"_fix_nve.html.
+The particles are always considered to have a finite size.
+
+An example input file can be found in /examples/USER/cgdna/examples/duplex1/.
+A technical report with more information on this integrator can be found
+"here"_PDF/USER-CGDNA-overview.pdf.
+
+:line
+
+[Restrictions:]
+
+These pair styles can only be used if LAMMPS was built with the
+USER-CGDNA package and the MOLECULE and ASPHERE package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
+
+[Related commands:]
+
+"fix nve/dotc/langevin"_fix_nve_dotc_langevin.html, "fix nve"_fix_nve.html
+
+[Default:] none
+
+:line
+
+:link(Davidchack)
+[(Davidchack)] R.L Davidchack, T.E. Ouldridge, and M.V. Tretyakov. J. Chem. Phys. 142, 144114 (2015).
+:link(Miller)
+[(Miller)] T. F. Miller III, M. Eleftheriou, P. Pattnaik, A. Ndirango, G. J. Martyna, J. Chem. Phys., 116, 8649-8659 (2002).
--- a/doc/src/fix_nve_dotc_langevin.txt
+++ b/doc/src/fix_nve_dotc_langevin.txt
@ -0,0 +1,134 @@
+"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 nve/dotc/langevin command :h3
+
+[Syntax:]
+
+fix ID group-ID nve/dotc/langevin Tstart Tstop damp seed keyword value :pre
+
+ID, group-ID are documented in "fix"_fix.html command :ulb,l
+nve/dotc/langevin = style name of this fix command :l
+Tstart,Tstop = desired temperature at start/end of run (temperature units) :l
+damp = damping parameter (time units) :l
+seed = random number seed to use for white noise (positive integer) :l
+keyword = {angmom} :l
+  {angmom} value = factor
+    factor = do thermostat rotational degrees of freedom via the angular momentum and apply numeric scale factor as discussed below :pre
+:ule
+
+[Examples:]
+
+fix 1 all nve/dotc/langevin 1.0 1.0 0.03 457145 angmom 10 :pre
+
+[Description:]
+
+Apply a rigid-body Langevin-type integrator of the kind "Langevin C" 
+as described in "(Davidchack)"_#Davidchack
+to a group of atoms, which models an interaction with an implicit background
+solvent.  This command performs Brownian dynamics (BD)
+via a technique that splits the integration into a deterministic Hamiltonian 
+part and the Ornstein-Uhlenbeck process for noise and damping. 
+The quaternion degrees of freedom are updated though an evolution
+operator which performs a rotation in quaternion space, preserves
+the quaternion norm and is akin to "(Miller)"_#Miller.
+
+In terms of syntax this command has been closely modelled on the 
+"fix langevin"_fix_langevin.html and its {angmom} option. But it combines 
+the "fix nve"_fix_nve.html and the "fix langevin"_fix_langevin.html in 
+one single command. The main feature is improved stability 
+over the standard integrator, permitting slightly larger timestep sizes.
+
+NOTE: Unlike the "fix langevin"_fix_langevin.html this command performs
+also time integration of the translational and quaternion degrees of freedom.
+
+The total force on each atom will have the form:
+
+F = Fc + Ff + Fr
+Ff = - (m / damp) v
+Fr is proportional to sqrt(Kb T m / (dt damp)) :pre
+
+Fc is the conservative force computed via the usual inter-particle
+interactions ("pair_style"_pair_style.html,
+"bond_style"_bond_style.html, etc).
+
+The Ff and Fr terms are implicitly taken into account by this fix 
+on a per-particle basis.
+
+Ff is a frictional drag or viscous damping term proportional to the
+particle's velocity.  The proportionality constant for each atom is
+computed as m/damp, where m is the mass of the particle and damp is
+the damping factor specified by the user.
+
+Fr is a force due to solvent atoms at a temperature T randomly bumping
+into the particle.  As derived from the fluctuation/dissipation
+theorem, its magnitude as shown above is proportional to sqrt(Kb T m /
+dt damp), where Kb is the Boltzmann constant, T is the desired
+temperature, m is the mass of the particle, dt is the timestep size,
+and damp is the damping factor.  Random numbers are used to randomize
+the direction and magnitude of this force as described in
+"(Dunweg)"_#Dunweg, where a uniform random number is used (instead of
+a Gaussian random number) for speed.
+
+:line
+
+{Tstart} and {Tstop} have to be constant values, i.e. they cannot 
+be variables.
+
+The {damp} parameter is specified in time units and determines how
+rapidly the temperature is relaxed.  For example, a value of 0.03
+means to relax the temperature in a timespan of (roughly) 0.03 time
+units tau (see the "units"_units.html command).
+The damp factor can be thought of as inversely related to the
+viscosity of the solvent, i.e. a small relaxation time implies a
+hi-viscosity solvent and vice versa.  See the discussion about gamma
+and viscosity in the documentation for the "fix
+viscous"_fix_viscous.html command for more details.
+
+The random # {seed} must be a positive integer. A Marsaglia random
+number generator is used.  Each processor uses the input seed to
+generate its own unique seed and its own stream of random numbers.
+Thus the dynamics of the system will not be identical on two runs on
+different numbers of processors.
+
+The keyword/value option has to be used in the following way:
+
+This fix has to be used together with the {angmom} keyword. The 
+particles are always considered to have a finite size. 
+The keyword {angmom} enables thermostatting of the rotational degrees of 
+freedom in addition to the usual translational degrees of freedom. 
+
+The scale factor after the {angmom} keyword gives the ratio of the rotational to 
+the translational friction coefficient.
+
+An example input file can be found in /examples/USER/cgdna/examples/duplex2/.
+A technical report with more information on this integrator can be found 
+"here"_PDF/USER-CGDNA-overview.pdf.
+
+:line
+
+[Restrictions:]
+
+These pair styles can only be used if LAMMPS was built with the
+USER-CGDNA package and the MOLECULE and ASPHERE package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
+
+[Related commands:]
+
+"fix nve"_fix_nve.html, "fix langevin"_fix_langevin.html, "fix nve/dot"_fix_nve_dot.html,  
+
+[Default:] none
+
+:line
+
+:link(Davidchack)
+[(Davidchack)] R.L Davidchack, T.E. Ouldridge, M.V. Tretyakov. J. Chem. Phys. 142, 144114 (2015).
+:link(Miller)
+[(Miller)] T. F. Miller III, M. Eleftheriou, P. Pattnaik, A. Ndirango, G. J. Martyna, J. Chem. Phys., 116, 8649-8659 (2002).
+:link(Dunweg)
+[(Dunweg)] B. Dunweg, W. Paul, Int. J. Mod. Phys. C, 2, 817-27 (1991).
--- a/doc/src/fix_nve_line.txt
+++ b/doc/src/fix_nve_line.txt
--- a/doc/src/fix_nve_sphere.txt
+++ b/doc/src/fix_nve_sphere.txt
--- a/doc/src/fix_nve_tri.txt
+++ b/doc/src/fix_nve_tri.txt
--- a/doc/src/fix_nvk.txt
+++ b/doc/src/fix_nvk.txt
@ -0,0 +1,71 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+fix nvk command :h3
+
+[Syntax:]
+
+fix ID group-ID nvk :pre
+
+ID, group-ID are documented in "fix"_fix.html command
+nvk = style name of this fix command :ul
+
+[Examples:]
+
+fix 1 all nvk :pre
+
+[Description:]
+
+Perform constant kinetic energy integration using the Gaussian
+thermostat to update position and velocity for atoms in the group each
+timestep.  V is volume; K is kinetic energy. This creates a system
+trajectory consistent with the isokinetic ensemble.
+
+The equations of motion used are those of Minary et al in
+"(Minary)"_#nvk-Minary, a variant of those initially given by Zhang in 
+"(Zhang)"_#nvk-Zhang.
+
+The kinetic energy will be held constant at its value given when fix
+nvk is initiated. If a different kinetic energy is desired, the
+"velocity"_velocity.html command should be used to change the kinetic
+energy prior to this fix.
+
+:line
+
+[Restart, fix_modify, output, run start/stop, minimize info:]
+
+No information about this fix is written to "binary restart
+files"_restart.html.  None of the "fix_modify"_fix_modify.html options
+are relevant to this fix.  No global or per-atom quantities are stored
+by this fix for access by various "output
+commands"_Section_howto.html#howto_15.  No parameter of this fix can
+be used with the {start/stop} keywords of the "run"_run.html command.
+This fix is not invoked during "energy minimization"_minimize.html.
+
+[Restrictions:]
+
+The Gaussian thermostat only works when it is applied to all atoms in
+the simulation box. Therefore, the group must be set to all.
+
+This fix has not yet been implemented to work with the RESPA integrator.
+
+This fix 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:] none
+
+[Default:] none
+
+:line
+
+:link(nvk-Minary)
+[(Minary)] Minary, Martyna, and Tuckerman, J Chem Phys, 18, 2510 (2003).
+
+:link(nvk-Zhang)
+[(Zhang)] Zhang, J Chem Phys, 106, 6102 (1997).
--- a/doc/src/fix_nvt_asphere.txt
+++ b/doc/src/fix_nvt_asphere.txt
--- a/doc/src/fix_nvt_body.txt
+++ b/doc/src/fix_nvt_body.txt
--- a/doc/src/fix_nvt_sphere.txt
+++ b/doc/src/fix_nvt_sphere.txt
--- a/doc/src/fix_spring.txt
+++ b/doc/src/fix_spring.txt
@ -89,11 +89,7 @@ NOTE: The center of mass of a group of atoms is calculated in
 group can straddle a periodic boundary.  See the "dump"_dump.html doc
 page for a discussion of unwrapped coordinates.  It also means that a
 spring connecting two groups or a group and the tether point can cross
-a periodic boundary and its length be calculated correctly.  One
-exception is for rigid bodies, which should not be used with the fix
-spring command, if the rigid body will cross a periodic boundary.
-This is because image flags for rigid bodies are used in a different
-way, as explained on the "fix rigid"_fix_rigid.html doc page.
+a periodic boundary and its length be calculated correctly.  

 [Restart, fix_modify, output, run start/stop, minimize info:]

--- a/doc/src/fix_ti_spring.txt
+++ b/doc/src/fix_ti_spring.txt
--- a/doc/src/fixes.txt
+++ b/doc/src/fixes.txt
@ -68,6 +68,7 @@ Fixes :h1
   fix_meso_stationary
   fix_momentum
   fix_move
+   fix_mscg
   fix_msst
   fix_neb
   fix_nh
@ -83,6 +84,8 @@ Fixes :h1
   fix_nve_asphere
   fix_nve_asphere_noforce
   fix_nve_body
+   fix_nve_dot
+   fix_nve_dotc_langevin
   fix_nve_eff
   fix_nve_limit
   fix_nve_line
@ -90,6 +93,7 @@ Fixes :h1
   fix_nve_noforce
   fix_nve_sphere
   fix_nve_tri
+   fix_nvk
   fix_nvt_asphere
   fix_nvt_body
   fix_nvt_manifold_rattle
--- a/doc/src/kspace_style.txt
+++ b/doc/src/kspace_style.txt
@ -229,11 +229,16 @@ dramatically in z.  For example, for a triclinic system with all three
 tilt factors set to the maximum limit, the PPPM grid should be
 increased roughly by a factor of 1.5 in the y direction and 2.0 in the
 z direction as compared to the same system using a cubic orthogonal
-simulation cell. One way to ensure the accuracy requirement is being
-met is to run a short simulation at the maximum expected tilt or
-length, note the required grid size, and then use the
+simulation cell.  One way to handle this issue if you have a long
+simulation where the box size changes dramatically, is to break it
+into shorter simulations (multiple "run"_run.html commands).  This
+works because the grid size is re-computed at the beginning of each
+run.  Another way to ensure the descired accuracy requirement is met
+is to run a short simulation at the maximum expected tilt or length,
+note the required grid size, and then use the
 "kspace_modify"_kspace_modify.html {mesh} command to manually set the
-PPPM grid size to this value.
+PPPM grid size to this value for the long run.  The simulation then
+will be "too accurate" for some portion of the run.

 RMS force errors in real space for {ewald} and {pppm} are estimated
 using equation 18 of "(Kolafa)"_#Kolafa, which is also referenced as
@ -285,6 +290,8 @@ LAMMPS"_Section_start.html#start_3 section for more info.
 See "Section 5"_Section_accelerate.html of the manual for
 more instructions on how to use the accelerated styles effectively.

+:line
+
 [Restrictions:]

 Note that the long-range electrostatic solvers in LAMMPS assume conducting
--- a/doc/src/lammps.book
+++ b/doc/src/lammps.book
@ -23,6 +23,7 @@ Section_history.html

 tutorial_drude.html
 tutorial_github.html
+tutorial_pylammps.html

 body.html
 manifolds.html
@ -113,6 +114,7 @@ special_bonds.html
 suffix.html
 tad.html
 temper.html
+temper_grem.html
 thermo.html
 thermo_modify.html
 thermo_style.html
@ -207,6 +209,8 @@ fix_nve.html
 fix_nve_asphere.html
 fix_nve_asphere_noforce.html
 fix_nve_body.html
+fix_nve_dot.html
+fix_nve_dotc_langevin.html
 fix_nve_eff.html
 fix_nve_limit.html
 fix_nve_line.html
@ -454,6 +458,7 @@ pair_multi_lucy_rx.html
 pair_nb3b_harmonic.html
 pair_nm.html
 pair_none.html
+pair_oxdna_excv.html
 pair_peri.html
 pair_polymorphic.html
 pair_quip.html
@ -492,6 +497,7 @@ pair_zero.html
 bond_class2.html
 bond_fene.html
 bond_fene_expand.html
+bond_oxdna_fene.html
 bond_harmonic.html
 bond_harmonic_shift.html
 bond_harmonic_shift_cut.html
--- a/doc/src/min_style.txt
+++ b/doc/src/min_style.txt
--- a/doc/src/pair_dipole.txt
+++ b/doc/src/pair_dipole.txt
--- a/doc/src/pair_eam.txt
+++ b/doc/src/pair_eam.txt
@ -8,6 +8,7 @@

 pair_style eam command :h3
 pair_style eam/gpu command :h3
+pair_style eam/intel command :h3
 pair_style eam/kk command :h3
 pair_style eam/omp command :h3
 pair_style eam/opt command :h3
--- a/doc/src/pair_exp6_rx.txt
+++ b/doc/src/pair_exp6_rx.txt
@ -10,16 +10,21 @@ pair_style exp6/rx command :h3

 [Syntax:]

-pair_style exp6/rx cutoff :pre
+pair_style exp6/rx cutoff ... :pre

-cutoff = global cutoff for DPD interactions (distance units) :ul
+cutoff = global cutoff for DPD interactions (distance units)
+weighting = fractional or molecular (optional) :ul

 [Examples:]

 pair_style exp6/rx 10.0
-pair_coeff * * exp6.params h2o h2o 1.0 1.0 10.0
-pair_coeff * * exp6.params h2o 1fluid 1.0 1.0 10.0
-pair_coeff * * exp6.params 1fluid 1fluid 1.0 1.0 10.0 :pre
+pair_style exp6/rx 10.0 fractional
+pair_style exp6/rx 10.0 molecular
+pair_coeff * * exp6.params h2o h2o exponent 1.0 1.0 10.0
+pair_coeff * * exp6.params h2o 1fluid exponent 1.0 1.0 10.0
+pair_coeff * * exp6.params 1fluid 1fluid exponent 1.0 1.0 10.0
+pair_coeff * * exp6.params 1fluid 1fluid none 10.0
+pair_coeff * * exp6.params 1fluid 1fluid polynomial filename 10.0 :pre

 [Description:]

@ -50,14 +55,36 @@ defined in the reaction kinetics files specified with the "fix
 rx"_fix_rx.html command or they must correspond to the tag "1fluid",
 signifying interaction with a product species mixture determined
 through a one-fluid approximation.  The interaction potential is
-weighted by the geometric average of the concentrations of the two
-species.  The coarse-grained potential is stored before and after the
+weighted by the geometric average of either the mole fraction concentrations 
+or the number of molecules associated with the interacting coarse-grained 
+particles (see the {fractional} or {molecular} weighting pair style options). 
+The coarse-grained potential is stored before and after the
 reaction kinetics solver is applied, where the difference is defined
 to be the internal chemical energy (uChem).

-The fourth and fifth arguments specify the {Rm} and {epsilon} scaling exponents.
+The fourth argument specifies the type of scaling that will be used 
+to scale the EXP-6 paramters as reactions occur.  Currently, there
+are three scaling options:  {exponent}, {polynomial} and {none}.

-The final argument specifies the interaction cutoff.
+Exponent scaling requires two additional arguments for scaling 
+the {Rm} and {epsilon} parameters, respectively.  The scaling factor
+is computed by phi^exponent, where phi is the number of molecules  
+represented by the coarse-grain particle and exponent is specified 
+as a pair coefficient argument for {Rm} and {epsilon}, respectively.
+The {Rm} and {epsilon} parameters are multiplied by the scaling 
+factor to give the scaled interaction paramters for the CG particle.
+
+Polynomial scaling requires a filename to be specified as a pair 
+coeff argument.  The file contains the coefficients to a fifth order
+polynomial for the {alpha}, {epsilon} and {Rm} parameters that depend 
+upon phi (the number of molecules represented by the CG particle). 
+The format of a polynomial file is provided below.
+
+The {none} option to the scaling does not have any additional pair coeff
+arguments.  This is equivalent to specifying the {exponent} option with 
+{Rm} and {epsilon} exponents of 0.0 and 0.0, respectively.
+
+The final argument specifies the interaction cutoff (optional).

 :line

@ -70,6 +97,19 @@ no2  exp6  13.60 0.01 3.70
 ...
 co2  exp6  13.00 0.03 3.20 :pre

+The format of the polynomial scaling file as follows (without the
+parenthesized comments):
+
+# POLYNOMIAL FILE          (one or more comment or blank lines) :pre
+#  General Functional Form:
+#  A*phi^5 + B*phi^4 + C*phi^3 + D*phi^2 + E*phi + F 
+#
+#  Parameter  A        B         C        D         E        F
+                           (blank)
+alpha        0.0000   0.00000   0.00008  0.04955  -0.73804  13.63201
+epsilon      0.0000   0.00478  -0.06283  0.24486  -0.33737   2.60097
+rm           0.0001  -0.00118  -0.00253  0.05812  -0.00509   1.50106 :pre
+
 A section begins with a non-blank line whose 1st character is not a
 "#"; blank lines or lines starting with "#" can be used as comments
 between sections.
@ -117,4 +157,4 @@ LAMMPS"_Section_start.html#start_3 section for more info.

 "pair_coeff"_pair_coeff.html

-[Default:] none
+[Default:] fractional weighting
--- a/doc/src/pair_gayberne.txt
+++ b/doc/src/pair_gayberne.txt
--- a/doc/src/pair_multi_lucy_rx.txt
+++ b/doc/src/pair_multi_lucy_rx.txt
@ -13,11 +13,14 @@ pair_style multi/lucy/rx command :h3
 pair_style multi/lucy/rx style N keyword ... :pre

 style = {lookup} or {linear} = method of interpolation
-N = use N values in {lookup}, {linear} tables :ul
+N = use N values in {lookup}, {linear} tables
+weighting = fractional or molecular (optional) :ul

 [Examples:]

 pair_style multi/lucy/rx linear 1000
+pair_style multi/lucy/rx linear 1000 fractional
+pair_style multi/lucy/rx linear 1000 molecular
 pair_coeff * * multibody.table ENTRY1 h2o h2o 7.0
 pair_coeff * * multibody.table ENTRY1 h2o 1fluid 7.0 :pre

@ -94,8 +97,10 @@ tags must either correspond to the species defined in the reaction
 kinetics files specified with the "fix rx"_fix_rx.html command or they
 must correspond to the tag "1fluid", signifying interaction with a
 product species mixture determined through a one-fluid approximation.
-The interaction potential is weighted by the geometric average of the
-concentrations of the two species.  The coarse-grained potential is
+The interaction potential is weighted by the geometric average of 
+either the mole fraction concentrations or the number of molecules 
+associated with the interacting coarse-grained particles (see the 
+{fractional} or {molecular} weighting pair style options). The coarse-grained potential is
 stored before and after the reaction kinetics solver is applied, where
 the difference is defined to be the internal chemical energy (uChem).

@ -205,7 +210,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.

 "pair_coeff"_pair_coeff.html

-[Default:] none
+[Default:] fractional weighting

 :line

--- a/doc/src/pair_oxdna_excv.txt
+++ b/doc/src/pair_oxdna_excv.txt
@ -0,0 +1,80 @@
+"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 oxdna_excv command :h3
+pair_style oxdna_stk command :h3
+pair_style oxdna_hbond command :h3
+pair_style oxdna_xstk command :h3
+pair_style oxdna_coaxstk command :h3
+
+[Syntax:]
+
+pair_style style :pre
+
+style = {hybrid/overlay oxdna_excv oxdna_stk oxdna_hbond oxdna_xstk oxdna_coaxstk} :ul
+
+[Examples:]
+
+pair_style hybrid/overlay oxdna_excv oxdna_stk oxdna_hbond oxdna_xstk oxdna_coaxstk
+pair_coeff * * oxdna_excv    2.0 0.7 0.675 2.0 0.515 0.5 2.0 0.33 0.32
+pair_coeff * * oxdna_stk     1.61048 6.0 0.4 0.9 0.32 0.6 1.3 0 0.8 0.9 0 0.95 0.9 0 0.95 2.0 0.65 2.0 0.65
+pair_coeff * * oxdna_hbond   0.0   8.0 0.4 0.75 0.34 0.7 1.5 0 0.7 1.5 0 0.7 1.5 0 0.7 0.46 3.141592653589793 0.7 4.0 1.5707963267948966 0.45 4.0 1.5707963267948966 0.45
+pair_coeff 1 4 oxdna_hbond   1.077 8.0 0.4 0.75 0.34 0.7 1.5 0 0.7 1.5 0 0.7 1.5 0 0.7 0.46 3.141592653589793 0.7 4.0 1.5707963267948966 0.45 4.0 1.5707963267948966 0.45
+pair_coeff 2 3 oxdna_hbond   1.077 8.0 0.4 0.75 0.34 0.7 1.5 0 0.7 1.5 0 0.7 1.5 0 0.7 0.46 3.141592653589793 0.7 4.0 1.5707963267948966 0.45 4.0 1.5707963267948966 0.45
+pair_coeff * * oxdna_xstk    47.5 0.575 0.675 0.495 0.655 2.25 0.791592653589793 0.58 1.7 1.0 0.68 1.7 1.0 0.68 1.5 0 0.65 1.7 0.875 0.68 1.7 0.875 0.68
+pair_coeff * * oxdna_coaxstk 46.0 0.4 0.6 0.22 0.58 2.0 2.541592653589793 0.65 1.3 0 0.8 0.9 0 0.95 0.9 0 0.95 2.0 -0.65 2.0 -0.65 :pre
+
+[Description:]
+
+The {oxdna} pair styles compute the pairwise-additive parts of the oxDNA force field 
+for coarse-grained modelling of DNA. The effective interaction between the nucleotides consists of potentials for the 
+excluded volume interaction {oxdna_excv}, the stacking {oxdna_stk}, cross-stacking {oxdna_xstk}
+and coaxial stacking interaction {oxdna_coaxstk} as well
+as the hydrogen-bonding interaction {oxdna_hbond} between complementary pairs of nucleotides on
+opposite strands.
+
+The exact functional form of the pair styles is rather complex, which manifests itself in the 144 coefficients 
+in the above example. The individual potentials consist of products of modulation factors, 
+which themselves are constructed from a number of more basic potentials 
+(Morse, Lennard-Jones, harmonic angle and distance) as well as quadratic smoothing and modulation terms. 
+We refer to "(Ouldridge-DPhil)"_#Ouldridge-DPhil and "(Ouldridge)"_#Ouldridge
+for a detailed description of the oxDNA force field.
+
+NOTE: These pair styles have to be used together with the related oxDNA bond style
+{oxdna_fene} for the connectivity of the phosphate backbone (see also documentation of
+"bond_style oxdna_fene"_bond_oxdna_fene.html). The coefficients
+in the above example have to be kept fixed and cannot be changed without reparametrizing the entire model.
+
+Example input and data files can be found in /examples/USER/cgdna/examples/duplex1/ and /duplex2/.
+A simple python setup tool which creates single straight or helical DNA strands, 
+DNA duplexes or arrays of DNA duplexes can be found in /examples/USER/cgdna/util/.
+A technical report with more information on the model, the structure of the input file,
+the setup tool and the performance of the LAMMPS-implementation of oxDNA 
+can be found "here"_PDF/USER-CGDNA-overview.pdf.
+
+:line
+
+[Restrictions:]
+
+These pair styles can only be used if LAMMPS was built with the
+USER-CGDNA package and the MOLECULE and ASPHERE package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
+
+[Related commands:]
+
+"bond_style oxdna_fene"_bond_oxdna_fene.html, "fix nve/dotc/langevin"_fix_nve_dotc_langevin.html, "pair_coeff"_pair_coeff.html 
+
+[Default:] none
+
+:line
+
+:link(Ouldridge-DPhil)
+[(Ouldrigde-DPhil)] T.E. Ouldridge, Coarse-grained modelling of DNA and DNA self-assembly, DPhil. University of Oxford (2011).
+
+:link(Ouldridge)
+[(Ouldridge)] T.E. Ouldridge, A.A. Louis, J.P.K. Doye, J. Chem. Phys. 134, 085101 (2011).
--- a/doc/src/pair_resquared.txt
+++ b/doc/src/pair_resquared.txt
--- a/doc/src/pair_smtbq.txt
+++ b/doc/src/pair_smtbq.txt
--- a/doc/src/pair_table_rx.txt
+++ b/doc/src/pair_table_rx.txt
@ -10,16 +10,17 @@ pair_style table/rx command :h3

 [Syntax:]

-pair_style table style N :pre
+pair_style table style N ... :pre

 style = {lookup} or {linear} or {spline} or {bitmap} = method of interpolation
 N = use N values in {lookup}, {linear}, {spline} tables
-N = use 2^N values in {bitmap} tables
+weighting = fractional or molecular (optional) :ul

 [Examples:]

 pair_style table/rx linear 1000
-pair_style table/rx bitmap 12
+pair_style table/rx linear 1000 fractional
+pair_style table/rx linear 1000 molecular
 pair_coeff * * rxn.table ENTRY1 h2o h2o 10.0
 pair_coeff * * rxn.table ENTRY1 1fluid 1fluid 10.0
 pair_coeff * 3 rxn.table ENTRY1 h2o no2 10.0 :pre
@ -84,8 +85,10 @@ tags must either correspond to the species defined in the reaction
 kinetics files specified with the "fix rx"_fix_rx.html command or they
 must correspond to the tag "1fluid", signifying interaction with a
 product species mixture determined through a one-fluid approximation.
-The interaction potential is weighted by the geometric average of the
-concentrations of the two species.  The coarse-grained potential is
+The interaction potential is weighted by the geometric average of 
+either the mole fraction concentrations or the number of molecules 
+associated with the interacting coarse-grained particles (see the 
+{fractional} or {molecular} weighting pair style options). The coarse-grained potential is
 stored before and after the reaction kinetics solver is applied, where
 the difference is defined to be the internal chemical energy (uChem).

@ -230,7 +233,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.

 "pair_coeff"_pair_coeff.html

-[Default:] none
+[Default:] fractional weighting

 :line

--- a/doc/src/pairs.txt
+++ b/doc/src/pairs.txt
@ -65,6 +65,7 @@ Pair Styles :h1
   pair_nb3b_harmonic
   pair_nm
   pair_none
+   pair_oxdna_excv
   pair_peri
   pair_polymorphic
   pair_quip
--- a/doc/src/read_dump.txt
+++ b/doc/src/read_dump.txt
@ -15,11 +15,12 @@ read_dump file Nstep field1 field2 ... keyword values ... :pre
 file = name of dump file to read :ulb,l
 Nstep = snapshot timestep to read from file :l
 one or more fields may be appended :l
-field = {x} or {y} or {z} or {vx} or {vy} or {vz} or {q} or {ix} or {iy} or {iz}
+field = {x} or {y} or {z} or {vx} or {vy} or {vz} or {q} or {ix} or {iy} or {iz} or {fx} or {fy} or {fz}
  {x},{y},{z} = atom coordinates
  {vx},{vy},{vz} = velocity components
  {q} = charge
-  {ix},{iy},{iz} = image flags in each dimension :pre
+  {ix},{iy},{iz} = image flags in each dimension
+  {fx},{fy},{fz} = force components :pre
 zero or more keyword/value pairs may be appended :l
 keyword = {box} or {replace} or {purge} or {trim} or {add} or {label} or {scaled} or {wrapped} or {format} :l
  {box} value = {yes} or {no} = replace simulation box with dump box
--- a/doc/src/temper_grem.txt
+++ b/doc/src/temper_grem.txt
@ -32,7 +32,7 @@ Run a parallel tempering or replica exchange simulation in LAMMPS
 partition mode using multiple generalized replicas (ensembles) of a
 system defined by "fix grem"_fix_grem.html, which stands for the
 generalized replica exchange method (gREM) originally developed by
-"(Kim)"_#Kim.  It uses non-Boltzmann ensembles to sample over first
+"(Kim)"_#KimStraub.  It uses non-Boltzmann ensembles to sample over first
 order phase transitions. The is done by defining replicas with an
 enthalpy dependent effective temperature

@ -105,5 +105,5 @@ This command must be used with "fix grem"_fix_grem.html.

 [Default:] none

-:link(Kim)
+:link(KimStraub)
 [(Kim)] Kim, Keyes, Straub, J Chem Phys, 132, 224107 (2010).
--- a/doc/src/timer.txt
+++ b/doc/src/timer.txt
@ -33,14 +33,14 @@ timer loop :pre
 Select the level of detail at which LAMMPS performs its CPU timings.
 Multiple keywords can be specified with the {timer} command.  For
 keywords that are mutually exclusive, the last one specified takes
-effect.
+precedence.

 During a simulation run LAMMPS collects information about how much
 time is spent in different sections of the code and thus can provide
 information for determining performance and load imbalance problems.
 This can be done at different levels of detail and accuracy.  For more
 information about the timing output, see this "discussion of screen
-output"_Section_start.html#start_8.
+output in Section 2.8"_Section_start.html#start_8.

 The {off} setting will turn all time measurements off. The {loop}
 setting will only measure the total time for a run and not collect any
@ -52,20 +52,22 @@ procsessors.  The {full} setting adds information about CPU
 utilization and thread utilization, when multi-threading is enabled.

 With the {sync} setting, all MPI tasks are synchronized at each timer
-call which meaures load imbalance more accuractly, though it can also
-slow down the simulation.  Using the {nosync} setting (which is the
-default) turns off this synchronization.
+call which measures load imbalance for each section more accuractly,
+though it can also slow down the simulation by prohibiting overlapping
+independent computations on different MPI ranks  Using the {nosync}
+setting (which is the default) turns this synchronization off.

-With the {timeout} keyword a walltime limit can be imposed that
+With the {timeout} keyword a walltime limit can be imposed, that
 affects the "run"_run.html and "minimize"_minimize.html commands.
-This can be convenient when runs have to confirm to time limits,
-e.g. when running under a batch system and you want to maximize
-the utilization of the batch time slot, especially when the time
-per timestep varies and is thus difficult to predict how many
-steps a simulation can perform, or for difficult to converge
-minimizations. The timeout {elapse} value should be somewhat smaller
-than the time requested from the batch system, as there is usually
-some overhead to launch jobs, and it may be advisable to write
+This can be convenient when calculations have to comply with execution
+time limits, e.g. when running under a batch system when you want to
+maximize the utilization of the batch time slot, especially for runs
+where the time per timestep varies much and thus it becomes difficult
+to predict how many steps a simulation can perform for a given walltime
+limit. This also applies for difficult to converge minimizations.
+The timeout {elapse} value should be somewhat smaller than the maximum
+wall time requested from the batch system, as there is usually
+some overhead to launch jobs, and it is advisable to write
 out a restart after terminating a run due to a timeout.

 The timeout timer starts when the command is issued. When the time
--- a/doc/src/tutorial_github.txt
+++ b/doc/src/tutorial_github.txt
@ -11,10 +11,22 @@ LAMMPS GitHub tutorial :h3

 :line

-This document briefly describes how to use GitHub to merge changes you
-make into LAMMPS, using GitHub. It assumes that you are familiar with
-git. You may want to have a look at the "Git
-book"_http://git-scm.com/book/ to reacquaint yourself.
+This document describes the process of how to use GitHub to integrate
+changes or additions you have made to LAMMPS into the official LAMMPS
+distribution.  It uses the process of updating this very tutorial as
+an example to describe the individual steps and options.  You need to
+be familiar with git and you may want to have a look at the
+"Git book"_http://git-scm.com/book/ to reacquaint yourself with some
+of the more advanced git features used below.
+
+As of fall 2016, submitting contributions to LAMMPS via pull requests
+on GitHub is the preferred option for integrating contributed features
+or improvements to LAMMPS, as it significantly reduces the amount of
+work required by the LAMMPS developers. Consequently, creating a pull
+request will increase your chances to have your contribution included
+and will reduce the time until the integration is complete. For more
+information on the requirements to have your code included into LAMMPS
+please see "Section 10.15"_Section_modify.html#mod_15

 :line

@ -30,106 +42,121 @@ username or e-mail address and password.

 [Forking the repository]

-To get changes into LAMMPS, you need to first fork the repository. At
-the time of writing, LAMMPS-ICMS is the preferred fork. Go to "LAMMPS
-on GitHub"_https://github.com/lammps/lammps and make sure branch is
-set to "lammps-icms", see the figure below.
+To get changes into LAMMPS, you need to first fork the `lammps/lammps`
+repository on GitHub. At the time of writing, {master} is the preferred
+target branch. Thus go to "LAMMPS on GitHub"_https://github.com/lammps/lammps
+and make sure branch is set to "master", as shown in the figure below.

 :c,image(JPG/tutorial_branch.png)

-Now, click on fork in the top right corner:
+If it is not, use the button to change it to {master}. Once it is, use the
+fork button to create a fork.

 :c,image(JPG/tutorial_fork.png)

-This will create your own fork of the LAMMPS repository. You can make
-changes in this fork and later file {pull requests} to allow the
-upstream repository to merge changes from your own fork into the one
-we just forked from. At the same time, you can set things up, so you
-can include changes from upstream into your repository.
+
+This will create a fork (which is essentially a copy, but uses less
+resources) of the LAMMPS repository under your own GitHub account. You
+can make changes in this fork and later file {pull requests} to allow
+the upstream repository to merge changes from your own fork into the one
+we just forked from (or others that were forked from the same repository).
+At the same time, you can set things up, so you can include changes from
+upstream into your repository and thus keep it in sync with the ongoing
+LAMMPS development.

 :line

 [Adding changes to your own fork]

-Before adding changes, it is better to first create a new branch that
-will contain these changes, a so-called feature branch.
+Additions to the upstream version of LAMMPS are handled using {feature
+branches}.  For every new feature, a so-called feature branch is
+created, which contains only those modification relevant to one specific
+feature. For example, adding a single fix would consist of creating a
+branch with only the fix header and source file and nothing else.  It is
+explained in more detail here: "feature branch
+workflow"_https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow.

 [Feature branches]

-Since LAMMPS is such a big project and most user contributions come in
-small portions, the most ideal workflow for LAMMPS is the so-called
-"Feature branch" workflow. It is explained in great detail here:
-"feature branch
-workflow"_https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow.
+First of all, create a clone of your version on github on your local
+machine via HTTPS:

-The idea is that every new feature for LAMMPS gets its own
-branch. This way, it is fairly painless to incorporate new features
-into the upstream repository. I will explain briefly here how to do
-it. In this feature branch, I will add a USER-package.
+  $ git clone https://github.com/<your user name>/lammps.git <some name> :pre

-I assume that git is installed on the local machine and you know how
-to use a command line.
+or, if you have set up your GitHub account for using SSH keys, via SSH:

-First of all, you need to clone your own fork of LAMMPS:
-
-  $ git clone https://github.com/<your user name>/lammps.git :pre
-
-You can find the proper url to the right of the "HTTPS" block, see figure.
+  $ git clone git@github.com:<your user name>/lammps.git :pre
+  
+You can find the proper URL by clicking the "Clone or download"-button:

 :c,image(JPG/tutorial_https_block.png)

 The above command copies ("clones") the git repository to your local
-machine. You can use this local clone to make changes and test them
-without interfering with the repository on github. First, however, it
-is recommended to make a new branch for a particular feature you would
-like added to LAMMPS. In this example, I will try adding a new
-USER-package called USER-MANIFOLD.
+machine to a directory with the name you chose. If none is given, it will
+default to "lammps". Typical names are "mylammps" or something similar.

-To create a new branch, run the following git command in your repository:
+You can use this local clone to make changes and
+test them without interfering with the repository on Github.

-$ git checkout -b add-user-manifold :pre
+To pull changes from upstream into this copy, you can go to the directory
+and use git pull:

-The name of this new branch is "add-user-manifold" in my case. Just
-name it after something that resembles the feature you want added to
-LAMMPS.
+  $ cd mylammps
+  $ git checkout master
+  $ git pull https://github.com/lammps/lammps :pre

-Now that you've changed branches, you can edit the files as you see
-fit, add new files, and commit as much as you would like. Just
-remember that if halfway you decide to add another, unrelated feature,
-you should switch branches!
+You can also add this URL as a remote:
+
+  $ git remote add lammps_upstream https://www.github.com/lammps/lammps :pre
+
+At this point, you typically make a feature branch from the updated master
+branch for the feature you want to work on. This tutorial contains the
+workflow that updated this tutorial, and hence we will call the branch
+"github-tutorial-update":
+
+ $ git checkout -b github-tutorial-update master :pre
+
+Now that we have changed branches, we can make our changes to our local
+repository. Just remember that if you want to start working on another,
+unrelated feature, you should switch branches!
+
+[After changes are made]

 After everything is done, add the files to the branch and commit them:

-  $ git add src/USER-MANIFOLD examples/USER/manifold/
-  $ git add doc/fix_nv\{t,e\}_manifold_rattle.txt
-  $ git add doc/fix_manifoldforce.txt doc/user_manifolds.txt :pre
+ $ git add doc/src/tutorial_github.txt
+ $ git add doc/src/JPG/tutorial*.png :pre

-After the files are added, the change should be comitted:
+IMPORTANT NOTE: Do not use {git commit -a} (or {git add -A}).  The -a
+flag (or -A flag) will automatically include _all_ modified or new files
+and that is rarely the behavior you want.  It can easily lead to
+accidentally adding unrelated and unwanted changes into the repository.
+Instead it is preferable to explicitly use {git add}, {git rm}, {git mv}
+for adding, removing, renaming individual files, respectively, and then
+{git commit} to finalize the commit.  Carefully check all pending
+changes with {git status} before committing them.  If you find doing
+this on the command line too tedious, consider using a GUI, for example
+the one included in git distributions written in Tk, i.e. use {git gui}
+(on some Linux distributions it may be required to install an additional
+package to use it).

-  $ git commit -m 'Added user-manifold package' :pre
+After adding all files, the change set can be committed with some
+useful message that explains the change.

-The "-m" switch is used to add a message to the commit. Use this to
-indicate what type of change was commited.
-
-[Wisdom by Axel]
-
-{"Do not use "git commit -a".  the -a flag will automatically include
-*all* modified or new files.  mercurial does that and it find it
-hugely annoying and often leading to accidental commits of files you
-don't want.  use git add, git rm, git mv for adding, removing,
-renaming and then git commit to finalize the commit.  personally, i
-find it very convenient to use the bundled gui for commits, i.e. git
-gui.  typically, i will do git add and other operations, but then
-verify and review them with git gui.  git gui also allows to do
-line-by-line unstaging and other convenient operations."}
+  $ git commit -m 'Finally updated the github tutorial' :pre

 After the commit, the changes can be pushed to the same branch on GitHub:

 $ git push :pre

 Git will ask you for your user name and password on GitHub if you have
-not configured anything. If you correctly type your user name and
-password, the change should be added to your fork on GitHub.
+not configured anything. If your local branch is not present on Github yet,
+it will ask you to add it by running
+
+  $ git push --set-upstream origin github-tutorial-update :pre
+
+If you correctly type your user name and
+password, the feature branch should be added to your fork on GitHub.

 If you want to make really sure you push to the right repository
 (which is good practice), you can provide it explicitly:
@ -140,16 +167,20 @@ or using an explicit URL:

 $ git push git@github.com:Pakketeretet2/lammps.git :pre

-After that, you can file a new pull request based on this
-branch. GitHub will now look like this:
+:line

-:c,image(JPG/tutorial_pull_request_feature_branch1.png)
+[Filing a pull request]
+
+Up to this point in the tutorial, all changes were to {your} clones of
+LAMMPS.  Eventually, however, you want this feature to be included into
+the official LAMMPS version.  To do this, you will want to file a pull
+request by clicking on the "New pull request" button:
+
+:c,image(JPG/tutorial_new_pull_request.png)

 Make sure that the current branch is set to the correct one, which, in
-this case, is "add-user-manifold". Now click "New pull request". If
-done correctly, the only changes you will see are those that were made
-on this branch, so in my case, I will see nothing related to
-$\mathrm{pair\_dzugatov}.$
+this case, is "github-tutorial-update". If done correctly, the only
+changes you will see are those that were made on this branch.

 This will open up a new window that lists changes made to the
 repository. If you are just adding new files, there is not much to do,
@ -158,36 +189,162 @@ changes in existing files. If all changes can automatically be merged,
 green text at the top will say so and you can click the "Create pull
 request" button, see image.

-:c,image(JPG/tutorial_pull_request2.png)
+:c,image(JPG/tutorial_create_new_pull_request1.png)

-After this you have to specify a short title and a comment with
-details about your pull request. I guess here you write what your
-modifications do and why they should be incorporated upstream. After
-that, click the "Create pull request" button, see image below.
+Before creating the pull request, make sure the short title is accurate
+and add a comment with details about your pull request.  Here you write
+what your modifications do and why they should be incorporated upstream.

-:c,image(JPG/tutorial_pull_request3.png)
+Note the checkbox that says "Allow edits from maintainers".
+This is checked by default checkbox (although in my version of Firefox, only the checkmark is visible):

-Now just write some nice comments, click "Comment", and that is it. It
-is now up to the maintainer(s) of the upstream repository to
-incorporate the changes into the repository and to close the pull
-request.
+:c,image(JPG/tutorial_edits_maintainers.png)

-:c,image(JPG/tutorial_pull_request4.png)
+If it is checked, maintainers can immediately add their own edits to the
+pull request.  This helps the inclusion of your branch significantly, as
+simple/trivial changes can be added directly to your pull request branch
+by the LAMMPS maintainers.  The alternative would be that they make
+changes on their own version of the branch and file a reverse pull
+request to you.  Just leave this box checked unless you have a very good
+reason not to.
+
+Now just write some nice comments and click on "Create pull request".
+
+:c,image(JPG/tutorial_create_new_pull_request2.png)

 :line

+[After filing a pull request]
+
+NOTE: When you submit a pull request (or ask for a pull request) for the
+first time, you will receive an invitation to become a LAMMPS project
+collaborator. Please accept this invite as being a collaborator will
+simplify certain administrative tasks and will probably speed up the
+merging of your feature, too.
+
+You will notice that after filing the pull request, some checks are
+performed automatically:
+
+:c,image(JPG/tutorial_automated_checks.png)
+
+If all is fine, you will see this:
+
+:c,image(JPG/tutorial_automated_checks_passed.png)
+
+If any of the checks are failing, your pull request will not be
+processed, as your changes may break compilation for certain
+configurations or may not merge cleanly. It is your responsibility
+to remove the reason(s) for the failed test(s). If you need help
+with this, please contact the LAMMPS developers by adding a comment
+explaining your problems with resolving the failed tests.
+
+A few further interesting things (can) happen to pull requests before
+they are included.
+
 [Additional changes]

-Before the pull request is accepted, any additional changes you push
-into your repository will automatically become part of the pull
-request.
+First of all, any additional changes you push into your branch in your
+repository will automatically become part of the pull request:
+
+:c,image(JPG/tutorial_additional_changes.png)
+
+This means you can add changes that should be part of the feature after
+filing the pull request, which is useful in case you have forgotten
+them, or if a developer has requested that something needs to be changed
+before the feature can be accepted into the official LAMMPS version.
+After each push, the automated checks are run again.
+
+[Assignees]
+
+There is an assignee label for pull requests. If the request has not
+been reviewed by any developer yet, it is not assigned to anyone. After
+revision, a developer can choose to assign it to either a) you, b) a
+LAMMPS developer (including him/herself) or c) Steve Plimpton (sjplimp).
+
+Case a) happens if changes are required on your part :ulb,l
+Case b) means that at the moment, it is being tested and reviewed by a
+LAMMPS developer with the expectation that some changes would be required.
+After the review, the developer can choose to implement changes directly
+or suggest them to you. :l
+Case c) means that the pull request has been assigned to the lead
+developer Steve Plimpton and means it is considered ready for merging. :ule,l
+
+In this case, Axel assigned the tutorial to Steve:
+
+:c,image(JPG/tutorial_steve_assignee.png)
+
+[Edits from LAMMPS maintainers]
+
+If you allowed edits from maintainers (the default), any LAMMPS
+maintainer can add changes to your pull request.  In this case, both
+Axel and Richard made changes to the tutorial:
+
+:c,image(JPG/tutorial_changes_others.png)
+
+[Reverse pull requests]
+
+Sometimes, however, you might not feel comfortable having other people
+push changes into your own branch, or maybe the maintainers are not sure
+their idea was the right one.  In such a case, they can make changes,
+reassign you as the assignee, and file a "reverse pull request", i.e.
+file a pull request in your GitHub repository to include changes in the
+branch, that you have submitted as a pull request yourself.  In that
+case, you can choose to merge their changes back into your branch,
+possibly make additional changes or corrections and proceed from there.
+It looks something like this:
+
+:c,image(JPG/tutorial_reverse_pull_request.png)
+
+For some reason, the highlighted button didn't work in my case, but I
+can go to my own repository and merge the pull request from there:
+
+:c,image(JPG/tutorial_reverse_pull_request2.png)
+
+Be sure to check the changes to see if you agree with them by clicking
+on the tab button:
+
+:c,image(JPG/tutorial_reverse_pull_request3.png)
+
+In this case, most of it is changes in the markup and a short rewrite of
+Axel's explanation of the "git gui" and "git add" commands.
+
+:c,image(JPG/tutorial_reverse_pull_request4.png)
+
+Because the changes are OK with us, we are going to merge by clicking on
+"Merge pull request".  After a merge it looks like this:
+
+:c,image(JPG/tutorial_reverse_pull_request5.png)
+
+Now, since in the meantime our local text for the tutorial also changed,
+we need to pull Axel's change back into our branch, and merge them:
+
+ $ git add tutorial_github.txt
+ $ git add JPG/tutorial_reverse_pull_request*.png
+ $ git commit -m "Updated text and images on reverse pull requests"
+ $ git pull :pre
+
+In this case, the merge was painless because git could auto-merge:
+
+:c,image(JPG/tutorial_reverse_pull_request6.png)
+
+With Axel's changes merged in and some final text updates, our feature
+branch is now perfect as far as we are concerned, so we are going to
+commit and push again:
+
+ $ git add tutorial_github.txt
+ $ git add JPG/tutorial_reverse_pull_request6.png
+ $ git commit -m "Merged Axel's suggestions and updated text"
+ $ git push git@github.com:Pakketeretet2/lammps :pre
+
+This merge also shows up on the lammps Github page:
+
+:c,image(JPG/tutorial_reverse_pull_request7.png)

 :line

 [After a merge]

-When everything is fine the feature branch is merged into the LAMMPS
-repositories:
+When everything is fine, the feature branch is merged into the master branch:

 :c,image(JPG/tutorial_merged.png)

@ -198,17 +355,29 @@ It is in principle safe to delete them from your own fork. This helps
 keep it a bit more tidy. Note that you first have to switch to another
 branch!

-$ git checkout lammps-icms
-$ git pull lammps-icms
-$ git branch -d add-user-manifold :pre
+$ git checkout master
+$ git pull master
+$ git branch -d github-tutorial-update :pre

 If you do not pull first, it is not really a problem but git will warn
 you at the next statement that you are deleting a local branch that
 was not yet fully merged into HEAD. This is because git does not yet
-know your branch just got merged into lammps-icms upstream. If you
+know your branch just got merged into LAMMPS upstream. If you
 first delete and then pull, everything should still be fine.

 Finally, if you delete the branch locally, you might want to push this
 to your remote(s) as well:

-$ git push origin :add-user-manifold :pre
+$ git push origin :github-tutorial-update :pre
+
+[Recent changes in the workflow]
+
+Some changes to the workflow are not captured in this tutorial.  For
+example, in addition to the master branch, to which all new features
+should be submitted, there is now also an "unstable" and a "stable"
+branch; these have the same content as "master", but are only updated
+after a patch release or stable release was made.
+Furthermore, the naming of the patches now follow the pattern
+"patch_<Day><Month><Year>" to simplify comparisons between releases.
+Finally, all patches and submissions are subject to automatic testing
+and code checks to make sure they at the very least compile.
--- a/doc/utils/converters/.gitignore
+++ b/doc/utils/converters/.gitignore
@ -1 +1,2 @@
+__pycache__
 *.egg-info
--- a/examples/COUPLE/fortran2/.gitignore
+++ b/examples/COUPLE/fortran2/.gitignore
@ -1 +0,0 @@
-*.mod
--- a/examples/README
+++ b/examples/README
@ -82,6 +82,7 @@ meam:	  MEAM test for SiC and shear (same as shear examples)
 melt:	  rapid melt of 3d LJ system
 micelle:  self-assembly of small lipid-like molecules into 2d bilayers
 min:	  energy minimization of 2d LJ melt
+mscg:     parameterize a multi-scale coarse-graining (MSCG) model
 msst:	  MSST shock dynamics
 nb3b:     use of nonbonded 3-body harmonic pair style
 neb:	  nudged elastic band (NEB) calculation for barrier finding
--- a/examples/USER/cgdna/README
+++ b/examples/USER/cgdna/README
@ -0,0 +1,28 @@
+This directory contains example data and input files 
+and utility scripts for the oxDNA coarse-grained model 
+for DNA.
+
+/examples/duplex1:
+Input, data and log files for a DNA duplex (double-stranded DNA) 
+consisiting of 5 base pairs. The duplex contains two strands with 
+complementary base pairs. The topology is
+
+A - A - A - A - A
+|   |   |   |   |
+T - T - T - T - T     
+
+/examples/duplex2:
+Input, data and log files for a nicked DNA duplex (double-stranded DNA) 
+consisiting of 8 base pairs. The duplex contains strands with 
+complementary base pairs, but the backbone on one side is not continuous: 
+two individual strands on one side form a duplex with a longer single 
+strand on the other side. The topology is
+
+A - A - A - A - A - A - A - A
+|   |   |   |   |   |   |   |
+T - T - T   T - T - T - T - T
+
+/util:
+This directory contains a simple python setup tool which creates 
+single straight or helical DNA strands, DNA duplexes or arrays of DNA 
+duplexes.
--- a/examples/USER/cgdna/examples/duplex1/data.duplex1
+++ b/examples/USER/cgdna/examples/duplex1/data.duplex1
@ -0,0 +1,74 @@
+# LAMMPS data file
+10 atoms
+10 ellipsoids
+8 bonds
+
+4 atom types
+1 bond types
+
+# System size
+-20.000000 20.000000 xlo xhi
+-20.000000 20.000000 ylo yhi
+-20.000000 20.000000 zlo zhi
+
+# Atom masses for each atom type
+Masses
+
+1 3.1575
+2 3.1575
+3 3.1575
+4 3.1575
+
+# Atom-ID, type, position, molecule-ID, ellipsoid flag, density
+Atoms
+
+1 1 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 1 1 1
+2 1 1.3274493266864451e-01 -4.2912827978022683e-01 3.7506163469402809e-01 1 1 1
+3 1 4.8460810659772807e-01 -7.0834970533509178e-01 7.5012326938805618e-01 1 1 1
+4 1 9.3267359196674593e-01 -7.4012419946742802e-01 1.1251849040820843e+00 1 1 1
+5 1 1.3204192238113461e+00 -5.1335201721887447e-01 1.5002465387761124e+00 1 1 1
+6 4 1.9958077618865377e-01 5.1335201721887447e-01 1.5002465387761124e+00 1 1 1
+7 4 5.8732640803325409e-01 7.4012419946742802e-01 1.1251849040820843e+00 1 1 1
+8 4 1.0353918934022719e+00 7.0834970533509178e-01 7.5012326938805618e-01 1 1 1
+9 4 1.3872550673313555e+00 4.2912827978022683e-01 3.7506163469402809e-01 1 1 1
+10 4 1.5200000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 1 1 1
+
+# Atom-ID, translational, rotational velocity
+Velocities
+
+1 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00
+2 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00
+3 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00
+4 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00
+5 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00
+6 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00
+7 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00
+8 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00
+9 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00
+10 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00
+
+# Atom-ID, shape, quaternion
+Ellipsoids
+
+1 1.1739845031423408e+00 1.1739845031423408e+00 1.1739845031423408e+00 1.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00
+2 1.1739845031423408e+00 1.1739845031423408e+00 1.1739845031423408e+00 9.5533648912560598e-01 0.0000000000000000e+00 0.0000000000000000e+00 2.9552020666133955e-01
+3 1.1739845031423408e+00 1.1739845031423408e+00 1.1739845031423408e+00 8.2533561490967822e-01 0.0000000000000000e+00 0.0000000000000000e+00 5.6464247339503526e-01
+4 1.1739845031423408e+00 1.1739845031423408e+00 1.1739845031423408e+00 6.2160996827066439e-01 0.0000000000000000e+00 0.0000000000000000e+00 7.8332690962748319e-01
+5 1.1739845031423408e+00 1.1739845031423408e+00 1.1739845031423408e+00 3.6235775447667351e-01 0.0000000000000000e+00 0.0000000000000000e+00 9.3203908596722607e-01
+6 1.1739845031423408e+00 1.1739845031423408e+00 1.1739845031423408e+00 0.0000000000000000e+00 9.3203908596722607e-01 -3.6235775447667351e-01 0.0000000000000000e+00
+7 1.1739845031423408e+00 1.1739845031423408e+00 1.1739845031423408e+00 0.0000000000000000e+00 7.8332690962748319e-01 -6.2160996827066439e-01 0.0000000000000000e+00
+8 1.1739845031423408e+00 1.1739845031423408e+00 1.1739845031423408e+00 0.0000000000000000e+00 5.6464247339503526e-01 -8.2533561490967822e-01 0.0000000000000000e+00
+9 1.1739845031423408e+00 1.1739845031423408e+00 1.1739845031423408e+00 0.0000000000000000e+00 2.9552020666133955e-01 -9.5533648912560598e-01 0.0000000000000000e+00
+10 1.1739845031423408e+00 1.1739845031423408e+00 1.1739845031423408e+00 0.0000000000000000e+00 0.0000000000000000e+00 -1.0000000000000000e+00 0.0000000000000000e+00
+
+# Bond topology
+Bonds
+
+1 1 1 2
+2 1 2 3
+3 1 3 4
+4 1 4 5
+5 1 6 7
+6 1 7 8
+7 1 8 9
+8 1 9 10
--- a/examples/USER/cgdna/examples/duplex1/input.duplex1
+++ b/examples/USER/cgdna/examples/duplex1/input.duplex1
@ -0,0 +1,75 @@
+variable number	equal 1
+variable ofreq	equal 1000
+variable efreq	equal 1000
+
+units lj
+
+dimension 3
+
+newton off
+
+boundary  p p p
+
+atom_style hybrid bond ellipsoid
+atom_modify sort 0 1.0
+
+# Pair interactions require lists of neighbours to be calculated
+neighbor 1.0 bin
+neigh_modify every 1 delay 0 check yes
+
+read_data data.duplex1
+
+set atom * mass 3.1575
+
+group all type 1 4
+
+# oxDNA bond interactions - FENE backbone
+bond_style oxdna_fene
+bond_coeff * 2.0 0.25 0.7525
+
+# oxDNA pair interactions
+pair_style hybrid/overlay oxdna_excv oxdna_stk oxdna_hbond oxdna_xstk oxdna_coaxstk
+pair_coeff * * oxdna_excv   2.0 0.7 0.675 2.0 0.515 0.5 2.0 0.33 0.32
+pair_coeff * * oxdna_stk    1.61048 6.0 0.4 0.9 0.32 0.6 1.3 0 0.8 0.9 0 0.95 0.9 0 0.95 2.0 0.65 2.0 0.65
+pair_coeff * * oxdna_hbond  0.0   8.0 0.4 0.75 0.34 0.7 1.5 0 0.7 1.5 0 0.7 1.5 0 0.7 0.46 3.141592653589793 0.7 4.0 1.5707963267948966 0.45 4.0 1.5707963267948966 0.45
+pair_coeff 1 4 oxdna_hbond  1.077 8.0 0.4 0.75 0.34 0.7 1.5 0 0.7 1.5 0 0.7 1.5 0 0.7 0.46 3.141592653589793 0.7 4.0 1.5707963267948966 0.45 4.0 1.5707963267948966 0.45
+pair_coeff 2 3 oxdna_hbond  1.077 8.0 0.4 0.75 0.34 0.7 1.5 0 0.7 1.5 0 0.7 1.5 0 0.7 0.46 3.141592653589793 0.7 4.0 1.5707963267948966 0.45 4.0 1.5707963267948966 0.45
+pair_coeff * * oxdna_xstk   47.5 0.575 0.675 0.495 0.655 2.25 0.791592653589793 0.58 1.7 1.0 0.68 1.7 1.0 0.68 1.5 0 0.65 1.7 0.875 0.68 1.7 0.875 0.68
+pair_coeff * * oxdna_coaxstk 46.0 0.4 0.6 0.22 0.58 2.0 2.541592653589793 0.65 1.3 0 0.8 0.9 0 0.95 0.9 0 0.95 2.0 -0.65 2.0 -0.65
+
+# NVE ensemble
+#fix 1 all   nve/dotc/langevin 0.1 0.1 0.03 457145 angmom 10
+fix 1 all   nve/dot
+
+timestep 1e-5
+
+#comm_style tiled
+#fix 3 all balance 10000 1.1 rcb
+
+#compute mol all chunk/atom molecule
+#compute mychunk all vcm/chunk mol
+#fix 4 all ave/time 10000 1 10000 c_mychunk[1] c_mychunk[2] c_mychunk[3] file vcm.txt mode vector
+
+dump pos all xyz ${ofreq} traj.${number}.xyz
+
+compute quat all property/atom quatw quati quatj quatk
+dump quat all custom ${ofreq} quat.${number}.txt id c_quat[1] c_quat[2] c_quat[3] c_quat[4]
+dump_modify quat sort id
+dump_modify quat format line "%d  %13.6le  %13.6le  %13.6le  %13.6le"
+
+compute erot all erotate/asphere
+compute ekin all ke
+compute epot all pe
+variable erot equal c_erot
+variable ekin equal c_ekin
+variable epot equal c_epot
+variable etot equal c_erot+c_ekin+c_epot
+fix 5 all print ${efreq} "$(step)  ekin = ${ekin} |  erot = ${erot} | epot = ${epot} | etot = ${etot}" screen yes
+
+dump out all custom ${ofreq} out.${number}.txt id x y z vx vy vz fx fy fz tqx tqy tqz
+dump_modify out sort id
+dump_modify out format line "%d   %13.6le %13.6le %13.6le  %13.6le %13.6le %13.6le  %13.6le %13.6le %13.6le  %13.6le %13.6le %13.6le"
+
+run 1000000
+
+#write_restart config.${number}.*
--- a/Show More
+++ b/Show More