final prep for 22Nov patch

update bundled version of moltemplate to v1.40

bench/log.6Oct16.chain.fixed.icc.1

@@ -1,4 +1,4 @@
-LAMMPS (15 Feb 2016)
+LAMMPS (6 Oct 2016)
 # FENE beadspring benchmark
 
 units		lj
@@ -43,25 +43,25 @@ Neighbor list info ...
   master list distance cutoff = 1.52
   ghost atom cutoff = 1.52
   binsize = 0.76 -> bins = 45 45 45
-Memory usage per processor = 11.5189 Mbytes
+Memory usage per processor = 12.0423 Mbytes
 Step Temp E_pair E_mol TotEng Press 
        0   0.97029772   0.44484087    20.494523    22.394765    4.6721833 
      100    0.9729966    0.4361122    20.507698     22.40326    4.6548819 
-Loop time of 0.978585 on 1 procs for 100 steps with 32000 atoms
+Loop time of 0.977647 on 1 procs for 100 steps with 32000 atoms
 
-Performance: 105948.895 tau/day, 102.188 timesteps/s
-100.0% CPU use with 1 MPI tasks x no OpenMP threads
+Performance: 106050.541 tau/day, 102.286 timesteps/s
+99.9% CPU use with 1 MPI tasks x no OpenMP threads
 
 MPI task timing breakdown:
 Section |  min time  |  avg time  |  max time  |%varavg| %total
 ---------------------------------------------------------------
-Pair    | 0.19562    | 0.19562    | 0.19562    |   0.0 | 19.99
-Bond    | 0.087475   | 0.087475   | 0.087475   |   0.0 |  8.94
-Neigh   | 0.44861    | 0.44861    | 0.44861    |   0.0 | 45.84
-Comm    | 0.032932   | 0.032932   | 0.032932   |   0.0 |  3.37
-Output  | 0.00010395 | 0.00010395 | 0.00010395 |   0.0 |  0.01
-Modify  | 0.19413    | 0.19413    | 0.19413    |   0.0 | 19.84
-Other   |            | 0.01972    |            |       |  2.02
+Pair    | 0.19421    | 0.19421    | 0.19421    |   0.0 | 19.86
+Bond    | 0.08741    | 0.08741    | 0.08741    |   0.0 |  8.94
+Neigh   | 0.45791    | 0.45791    | 0.45791    |   0.0 | 46.84
+Comm    | 0.032649   | 0.032649   | 0.032649   |   0.0 |  3.34
+Output  | 0.00012207 | 0.00012207 | 0.00012207 |   0.0 |  0.01
+Modify  | 0.18071    | 0.18071    | 0.18071    |   0.0 | 18.48
+Other   |            | 0.02464    |            |       |  2.52
 
 Nlocal:    32000 ave 32000 max 32000 min
 Histogram: 1 0 0 0 0 0 0 0 0 0

bench/log.6Oct16.chain.fixed.icc.4

@@ -1,4 +1,4 @@
-LAMMPS (15 Feb 2016)
+LAMMPS (6 Oct 2016)
 # FENE beadspring benchmark
 
 units		lj
@@ -43,25 +43,25 @@ Neighbor list info ...
   master list distance cutoff = 1.52
   ghost atom cutoff = 1.52
   binsize = 0.76 -> bins = 45 45 45
-Memory usage per processor = 3.91518 Mbytes
+Memory usage per processor = 4.14663 Mbytes
 Step Temp E_pair E_mol TotEng Press 
        0   0.97029772   0.44484087    20.494523    22.394765    4.6721833 
      100   0.97145835   0.43803883    20.502691    22.397872     4.626988 
-Loop time of 0.271187 on 4 procs for 100 steps with 32000 atoms
+Loop time of 0.269205 on 4 procs for 100 steps with 32000 atoms
 
-Performance: 382319.453 tau/day, 368.749 timesteps/s
-99.6% CPU use with 4 MPI tasks x no OpenMP threads
+Performance: 385133.446 tau/day, 371.464 timesteps/s
+99.8% CPU use with 4 MPI tasks x no OpenMP threads
 
 MPI task timing breakdown:
 Section |  min time  |  avg time  |  max time  |%varavg| %total
 ---------------------------------------------------------------
-Pair    | 0.048621   | 0.050076   | 0.051229   |   0.4 | 18.47
-Bond    | 0.022254   | 0.022942   | 0.023567   |   0.3 |  8.46
-Neigh   | 0.11873    | 0.11881    | 0.11887    |   0.0 | 43.81
-Comm    | 0.019066   | 0.021357   | 0.024297   |   1.3 |  7.88
-Output  | 5.0068e-05 | 5.5015e-05 | 6.1035e-05 |   0.1 |  0.02
-Modify  | 0.048737   | 0.050198   | 0.051231   |   0.4 | 18.51
-Other   |            | 0.007751   |            |       |  2.86
+Pair    | 0.049383   | 0.049756   | 0.049988   |   0.1 | 18.48
+Bond    | 0.022701   | 0.022813   | 0.022872   |   0.0 |  8.47
+Neigh   | 0.11982    | 0.12002    | 0.12018    |   0.0 | 44.58
+Comm    | 0.020274   | 0.021077   | 0.022348   |   0.5 |  7.83
+Output  | 5.3167e-05 | 5.6148e-05 | 6.3181e-05 |   0.1 |  0.02
+Modify  | 0.046276   | 0.046809   | 0.047016   |   0.1 | 17.39
+Other   |            | 0.008669   |            |       |  3.22
 
 Nlocal:    8000 ave 8030 max 7974 min
 Histogram: 1 0 0 1 0 1 0 0 0 1

bench/log.6Oct16.chain.scaled.icc.4

@@ -1,4 +1,4 @@
-LAMMPS (15 Feb 2016)
+LAMMPS (6 Oct 2016)
 # FENE beadspring benchmark
 
 variable	x index 1
@@ -59,25 +59,25 @@ Neighbor list info ...
   master list distance cutoff = 1.52
   ghost atom cutoff = 1.52
   binsize = 0.76 -> bins = 89 89 45
-Memory usage per processor = 12.8735 Mbytes
+Memory usage per processor = 13.2993 Mbytes
 Step Temp E_pair E_mol TotEng Press 
        0   0.97027498   0.44484087    20.494523    22.394765    4.6721833 
      100   0.97682955   0.44239968    20.500229    22.407862    4.6527025 
-Loop time of 1.20889 on 4 procs for 100 steps with 128000 atoms
+Loop time of 1.14845 on 4 procs for 100 steps with 128000 atoms
 
-Performance: 85764.410 tau/day, 82.720 timesteps/s
-99.8% CPU use with 4 MPI tasks x no OpenMP threads
+Performance: 90277.919 tau/day, 87.074 timesteps/s
+99.9% CPU use with 4 MPI tasks x no OpenMP threads
 
 MPI task timing breakdown:
 Section |  min time  |  avg time  |  max time  |%varavg| %total
 ---------------------------------------------------------------
-Pair    | 0.21738    | 0.23306    | 0.23926    |   1.9 | 19.28
-Bond    | 0.094536   | 0.10196    | 0.10534    |   1.4 |  8.43
-Neigh   | 0.52311    | 0.52392    | 0.52519    |   0.1 | 43.34
-Comm    | 0.090161   | 0.10022    | 0.12557    |   4.7 |  8.29
-Output  | 0.00012207 | 0.00017327 | 0.00019598 |   0.2 |  0.01
-Modify  | 0.19662    | 0.20262    | 0.20672    |   0.8 | 16.76
-Other   |            | 0.04694    |            |       |  3.88
+Pair    | 0.2203     | 0.22207    | 0.22386    |   0.3 | 19.34
+Bond    | 0.094861   | 0.095302   | 0.095988   |   0.1 |  8.30
+Neigh   | 0.52127    | 0.5216     | 0.52189    |   0.0 | 45.42
+Comm    | 0.079585   | 0.082159   | 0.084366   |   0.7 |  7.15
+Output  | 0.00013304 | 0.00015306 | 0.00018501 |   0.2 |  0.01
+Modify  | 0.18351    | 0.18419    | 0.1856     |   0.2 | 16.04
+Other   |            | 0.04298    |            |       |  3.74
 
 Nlocal:    32000 ave 32015 max 31983 min
 Histogram: 1 0 1 0 0 0 0 0 1 1

bench/log.6Oct16.chute.fixed.icc.1

@@ -1,4 +1,4 @@
-LAMMPS (15 Feb 2016)
+LAMMPS (6 Oct 2016)
 # LAMMPS benchmark of granular flow
 # chute flow of 32000 atoms with frozen base at 26 degrees
 
@@ -47,24 +47,24 @@ Neighbor list info ...
   master list distance cutoff = 1.1
   ghost atom cutoff = 1.1
   binsize = 0.55 -> bins = 73 37 68
-Memory usage per processor = 15.567 Mbytes
-Step Atoms KinEng 1 Volume 
+Memory usage per processor = 16.0904 Mbytes
+Step Atoms KinEng c_1 Volume 
        0    32000    784139.13    1601.1263    29833.783 
      100    32000    784292.08    1571.0968    29834.707 
-Loop time of 0.550482 on 1 procs for 100 steps with 32000 atoms
+Loop time of 0.534174 on 1 procs for 100 steps with 32000 atoms
 
-Performance: 1569.534 tau/day, 181.659 timesteps/s
-100.1% CPU use with 1 MPI tasks x no OpenMP threads
+Performance: 1617.451 tau/day, 187.205 timesteps/s
+99.8% CPU use with 1 MPI tasks x no OpenMP threads
 
 MPI task timing breakdown:
 Section |  min time  |  avg time  |  max time  |%varavg| %total
 ---------------------------------------------------------------
-Pair    | 0.33849    | 0.33849    | 0.33849    |   0.0 | 61.49
-Neigh   | 0.040353   | 0.040353   | 0.040353   |   0.0 |  7.33
-Comm    | 0.018023   | 0.018023   | 0.018023   |   0.0 |  3.27
-Output  | 0.00020385 | 0.00020385 | 0.00020385 |   0.0 |  0.04
-Modify  | 0.13155    | 0.13155    | 0.13155    |   0.0 | 23.90
-Other   |            | 0.02186    |            |       |  3.97
+Pair    | 0.33346    | 0.33346    | 0.33346    |   0.0 | 62.43
+Neigh   | 0.043902   | 0.043902   | 0.043902   |   0.0 |  8.22
+Comm    | 0.018391   | 0.018391   | 0.018391   |   0.0 |  3.44
+Output  | 0.00022411 | 0.00022411 | 0.00022411 |   0.0 |  0.04
+Modify  | 0.11666    | 0.11666    | 0.11666    |   0.0 | 21.84
+Other   |            | 0.02153    |            |       |  4.03
 
 Nlocal:    32000 ave 32000 max 32000 min
 Histogram: 1 0 0 0 0 0 0 0 0 0

bench/log.6Oct16.chute.fixed.icc.4

@@ -1,4 +1,4 @@
-LAMMPS (15 Feb 2016)
+LAMMPS (6 Oct 2016)
 # LAMMPS benchmark of granular flow
 # chute flow of 32000 atoms with frozen base at 26 degrees
 
@@ -47,24 +47,24 @@ Neighbor list info ...
   master list distance cutoff = 1.1
   ghost atom cutoff = 1.1
   binsize = 0.55 -> bins = 73 37 68
-Memory usage per processor = 6.81783 Mbytes
-Step Atoms KinEng 1 Volume 
+Memory usage per processor = 7.04927 Mbytes
+Step Atoms KinEng c_1 Volume 
        0    32000    784139.13    1601.1263    29833.783 
      100    32000    784292.08    1571.0968    29834.707 
-Loop time of 0.13141 on 4 procs for 100 steps with 32000 atoms
+Loop time of 0.171815 on 4 procs for 100 steps with 32000 atoms
 
-Performance: 6574.833 tau/day, 760.976 timesteps/s
-99.3% CPU use with 4 MPI tasks x no OpenMP threads
+Performance: 5028.653 tau/day, 582.020 timesteps/s
+99.7% CPU use with 4 MPI tasks x no OpenMP threads
 
 MPI task timing breakdown:
 Section |  min time  |  avg time  |  max time  |%varavg| %total
 ---------------------------------------------------------------
-Pair    | 0.062505   | 0.067      | 0.07152    |   1.5 | 50.99
-Neigh   | 0.010041   | 0.0101     | 0.010178   |   0.1 |  7.69
-Comm    | 0.012347   | 0.012895   | 0.013444   |   0.5 |  9.81
-Output  | 6.3896e-05 | 0.00010294 | 0.00014091 |   0.3 |  0.08
-Modify  | 0.031802   | 0.032348   | 0.032897   |   0.3 | 24.62
-Other   |            | 0.008965   |            |       |  6.82
+Pair    | 0.093691   | 0.096898   | 0.10005    |   0.8 | 56.40
+Neigh   | 0.011976   | 0.012059   | 0.012146   |   0.1 |  7.02
+Comm    | 0.016384   | 0.017418   | 0.018465   |   0.8 | 10.14
+Output  | 7.7963e-05 | 0.00010747 | 0.00013304 |   0.2 |  0.06
+Modify  | 0.031744   | 0.031943   | 0.032167   |   0.1 | 18.59
+Other   |            | 0.01339    |            |       |  7.79
 
 Nlocal:    8000 ave 8008 max 7992 min
 Histogram: 2 0 0 0 0 0 0 0 0 2

bench/log.6Oct16.chute.scaled.icc.4

@@ -1,4 +1,4 @@
-LAMMPS (15 Feb 2016)
+LAMMPS (6 Oct 2016)
 # LAMMPS benchmark of granular flow
 # chute flow of 32000 atoms with frozen base at 26 degrees
 
@@ -57,24 +57,24 @@ Neighbor list info ...
   master list distance cutoff = 1.1
   ghost atom cutoff = 1.1
   binsize = 0.55 -> bins = 146 73 68
-Memory usage per processor = 15.7007 Mbytes
-Step Atoms KinEng 1 Volume 
+Memory usage per processor = 16.1265 Mbytes
+Step Atoms KinEng c_1 Volume 
        0   128000    3136556.5    6404.5051    119335.13 
      100   128000    3137168.3    6284.3873    119338.83 
-Loop time of 0.906913 on 4 procs for 100 steps with 128000 atoms
+Loop time of 0.832365 on 4 procs for 100 steps with 128000 atoms
 
-Performance: 952.683 tau/day, 110.264 timesteps/s
-99.7% CPU use with 4 MPI tasks x no OpenMP threads
+Performance: 1038.006 tau/day, 120.140 timesteps/s
+99.8% CPU use with 4 MPI tasks x no OpenMP threads
 
 MPI task timing breakdown:
 Section |  min time  |  avg time  |  max time  |%varavg| %total
 ---------------------------------------------------------------
-Pair    | 0.51454    | 0.53094    | 0.55381    |   2.0 | 58.54
-Neigh   | 0.042597   | 0.043726   | 0.045801   |   0.6 |  4.82
-Comm    | 0.063027   | 0.064657   | 0.067367   |   0.7 |  7.13
-Output  | 0.00024891 | 0.00059718 | 0.00086498 |   1.0 |  0.07
-Modify  | 0.16508    | 0.17656    | 0.1925     |   2.6 | 19.47
-Other   |            | 0.09043    |            |       |  9.97
+Pair    | 0.5178     | 0.52208    | 0.52793    |   0.5 | 62.72
+Neigh   | 0.047003   | 0.047113   | 0.047224   |   0.0 |  5.66
+Comm    | 0.05233    | 0.052988   | 0.053722   |   0.2 |  6.37
+Output  | 0.00024986 | 0.00032717 | 0.00036693 |   0.3 |  0.04
+Modify  | 0.15517    | 0.15627    | 0.15808    |   0.3 | 18.77
+Other   |            | 0.0536     |            |       |  6.44
 
 Nlocal:    32000 ave 32000 max 32000 min
 Histogram: 4 0 0 0 0 0 0 0 0 0
@@ -87,4 +87,4 @@ Total # of neighbors = 460532
 Ave neighs/atom = 3.59791
 Neighbor list builds = 2
 Dangerous builds = 0
-Total wall time: 0:00:01
+Total wall time: 0:00:00

bench/log.6Oct16.eam.fixed.icc.1

@@ -1,4 +1,4 @@
-LAMMPS (15 Feb 2016)
+LAMMPS (6 Oct 2016)
 # bulk Cu lattice
 
 variable	x index 1
@@ -49,25 +49,25 @@ Neighbor list info ...
   master list distance cutoff = 5.95
   ghost atom cutoff = 5.95
   binsize = 2.975 -> bins = 25 25 25
-Memory usage per processor = 10.2238 Mbytes
+Memory usage per processor = 11.2238 Mbytes
 Step Temp E_pair E_mol TotEng Press 
        0         1600      -113280            0   -106662.09    18703.573 
       50    781.69049   -109873.35            0   -106640.13    52273.088 
      100      801.832    -109957.3            0   -106640.77    51322.821 
-Loop time of 5.90097 on 1 procs for 100 steps with 32000 atoms
+Loop time of 5.96529 on 1 procs for 100 steps with 32000 atoms
 
-Performance: 7.321 ns/day, 3.278 hours/ns, 16.946 timesteps/s
+Performance: 7.242 ns/day, 3.314 hours/ns, 16.764 timesteps/s
 99.9% CPU use with 1 MPI tasks x no OpenMP threads
 
 MPI task timing breakdown:
 Section |  min time  |  avg time  |  max time  |%varavg| %total
 ---------------------------------------------------------------
-Pair    | 5.2121     | 5.2121     | 5.2121     |   0.0 | 88.33
-Neigh   | 0.58212    | 0.58212    | 0.58212    |   0.0 |  9.86
-Comm    | 0.030392   | 0.030392   | 0.030392   |   0.0 |  0.52
-Output  | 0.00023389 | 0.00023389 | 0.00023389 |   0.0 |  0.00
-Modify  | 0.060871   | 0.060871   | 0.060871   |   0.0 |  1.03
-Other   |            | 0.01527    |            |       |  0.26
+Pair    | 5.2743     | 5.2743     | 5.2743     |   0.0 | 88.42
+Neigh   | 0.59212    | 0.59212    | 0.59212    |   0.0 |  9.93
+Comm    | 0.030399   | 0.030399   | 0.030399   |   0.0 |  0.51
+Output  | 0.00026202 | 0.00026202 | 0.00026202 |   0.0 |  0.00
+Modify  | 0.050487   | 0.050487   | 0.050487   |   0.0 |  0.85
+Other   |            | 0.01776    |            |       |  0.30
 
 Nlocal:    32000 ave 32000 max 32000 min
 Histogram: 1 0 0 0 0 0 0 0 0 0

bench/log.6Oct16.eam.fixed.icc.4

@@ -1,4 +1,4 @@
-LAMMPS (15 Feb 2016)
+LAMMPS (6 Oct 2016)
 # bulk Cu lattice
 
 variable	x index 1
@@ -49,25 +49,25 @@ Neighbor list info ...
   master list distance cutoff = 5.95
   ghost atom cutoff = 5.95
   binsize = 2.975 -> bins = 25 25 25
-Memory usage per processor = 5.09629 Mbytes
+Memory usage per processor = 5.59629 Mbytes
 Step Temp E_pair E_mol TotEng Press 
        0         1600      -113280            0   -106662.09    18703.573 
       50    781.69049   -109873.35            0   -106640.13    52273.088 
      100      801.832    -109957.3            0   -106640.77    51322.821 
-Loop time of 1.58019 on 4 procs for 100 steps with 32000 atoms
+Loop time of 1.64562 on 4 procs for 100 steps with 32000 atoms
 
-Performance: 27.338 ns/day, 0.878 hours/ns, 63.284 timesteps/s
+Performance: 26.252 ns/day, 0.914 hours/ns, 60.767 timesteps/s
 99.8% CPU use with 4 MPI tasks x no OpenMP threads
 
 MPI task timing breakdown:
 Section |  min time  |  avg time  |  max time  |%varavg| %total
 ---------------------------------------------------------------
-Pair    | 1.3617     | 1.366      | 1.3723     |   0.4 | 86.45
-Neigh   | 0.15123    | 0.15232    | 0.15374    |   0.2 |  9.64
-Comm    | 0.033429   | 0.041275   | 0.047066   |   2.7 |  2.61
-Output  | 0.00011301 | 0.0001573  | 0.000211   |   0.3 |  0.01
-Modify  | 0.014694   | 0.015085   | 0.015421   |   0.2 |  0.95
-Other   |            | 0.005342   |            |       |  0.34
+Pair    | 1.408      | 1.4175     | 1.4341     |   0.9 | 86.14
+Neigh   | 0.15512    | 0.15722    | 0.16112    |   0.6 |  9.55
+Comm    | 0.029105   | 0.049986   | 0.061822   |   5.8 |  3.04
+Output  | 0.00010991 | 0.00011539 | 0.00012302 |   0.0 |  0.01
+Modify  | 0.013383   | 0.013573   | 0.013883   |   0.2 |  0.82
+Other   |            | 0.007264   |            |       |  0.44
 
 Nlocal:    8000 ave 8008 max 7993 min
 Histogram: 2 0 0 0 0 0 0 0 1 1

bench/log.6Oct16.eam.scaled.icc.4

@@ -1,4 +1,4 @@
-LAMMPS (15 Feb 2016)
+LAMMPS (6 Oct 2016)
 # bulk Cu lattice
 
 variable	x index 1
@@ -49,25 +49,25 @@ Neighbor list info ...
   master list distance cutoff = 5.95
   ghost atom cutoff = 5.95
   binsize = 2.975 -> bins = 49 49 25
-Memory usage per processor = 10.1402 Mbytes
+Memory usage per processor = 11.1402 Mbytes
 Step Temp E_pair E_mol TotEng Press 
        0         1600      -453120            0   -426647.73    18704.012 
       50    779.50001   -439457.02            0   -426560.06    52355.276 
      100    797.97828   -439764.76            0   -426562.07     51474.74 
-Loop time of 6.46849 on 4 procs for 100 steps with 128000 atoms
+Loop time of 6.60121 on 4 procs for 100 steps with 128000 atoms
 
-Performance: 6.679 ns/day, 3.594 hours/ns, 15.460 timesteps/s
+Performance: 6.544 ns/day, 3.667 hours/ns, 15.149 timesteps/s
 99.9% CPU use with 4 MPI tasks x no OpenMP threads
 
 MPI task timing breakdown:
 Section |  min time  |  avg time  |  max time  |%varavg| %total
 ---------------------------------------------------------------
-Pair    | 5.581      | 5.5997     | 5.6265     |   0.8 | 86.57
-Neigh   | 0.65287    | 0.658      | 0.66374    |   0.5 | 10.17
-Comm    | 0.075706   | 0.11015    | 0.13655    |   7.2 |  1.70
-Output  | 0.00026488 | 0.00028312 | 0.00029302 |   0.1 |  0.00
-Modify  | 0.069607   | 0.072407   | 0.074555   |   0.7 |  1.12
-Other   |            | 0.02794    |            |       |  0.43
+Pair    | 5.6676     | 5.7011     | 5.7469     |   1.3 | 86.36
+Neigh   | 0.66423    | 0.67119    | 0.68082    |   0.7 | 10.17
+Comm    | 0.079367   | 0.13668    | 0.1791     |  10.5 |  2.07
+Output  | 0.00026989 | 0.00028622 | 0.00031209 |   0.1 |  0.00
+Modify  | 0.060046   | 0.062203   | 0.065009   |   0.9 |  0.94
+Other   |            | 0.02974    |            |       |  0.45
 
 Nlocal:    32000 ave 32092 max 31914 min
 Histogram: 1 0 0 1 0 1 0 0 0 1

bench/log.6Oct16.lj.fixed.icc.1

@@ -1,4 +1,4 @@
-LAMMPS (15 Feb 2016)
+LAMMPS (6 Oct 2016)
 # 3d Lennard-Jones melt
 
 variable	x index 1
@@ -50,20 +50,20 @@ Memory usage per processor = 8.21387 Mbytes
 Step Temp E_pair E_mol TotEng Press 
        0         1.44   -6.7733681            0   -4.6134356   -5.0197073 
      100    0.7574531   -5.7585055            0   -4.6223613   0.20726105 
-Loop time of 2.26309 on 1 procs for 100 steps with 32000 atoms
+Loop time of 2.26185 on 1 procs for 100 steps with 32000 atoms
 
-Performance: 19088.920 tau/day, 44.187 timesteps/s
+Performance: 19099.377 tau/day, 44.212 timesteps/s
 99.9% CPU use with 1 MPI tasks x no OpenMP threads
 
 MPI task timing breakdown:
 Section |  min time  |  avg time  |  max time  |%varavg| %total
 ---------------------------------------------------------------
-Pair    | 1.9341     | 1.9341     | 1.9341     |   0.0 | 85.46
-Neigh   | 0.2442     | 0.2442     | 0.2442     |   0.0 | 10.79
-Comm    | 0.024158   | 0.024158   | 0.024158   |   0.0 |  1.07
-Output  | 0.00011611 | 0.00011611 | 0.00011611 |   0.0 |  0.01
-Modify  | 0.053222   | 0.053222   | 0.053222   |   0.0 |  2.35
-Other   |            | 0.007258   |            |       |  0.32
+Pair    | 1.9328     | 1.9328     | 1.9328     |   0.0 | 85.45
+Neigh   | 0.2558     | 0.2558     | 0.2558     |   0.0 | 11.31
+Comm    | 0.024061   | 0.024061   | 0.024061   |   0.0 |  1.06
+Output  | 0.00012612 | 0.00012612 | 0.00012612 |   0.0 |  0.01
+Modify  | 0.040887   | 0.040887   | 0.040887   |   0.0 |  1.81
+Other   |            | 0.008214   |            |       |  0.36
 
 Nlocal:    32000 ave 32000 max 32000 min
 Histogram: 1 0 0 0 0 0 0 0 0 0

bench/log.6Oct16.lj.fixed.icc.4

@@ -1,4 +1,4 @@
-LAMMPS (15 Feb 2016)
+LAMMPS (6 Oct 2016)
 # 3d Lennard-Jones melt
 
 variable	x index 1
@@ -50,20 +50,20 @@ Memory usage per processor = 4.09506 Mbytes
 Step Temp E_pair E_mol TotEng Press 
        0         1.44   -6.7733681            0   -4.6134356   -5.0197073 
      100    0.7574531   -5.7585055            0   -4.6223613   0.20726105 
-Loop time of 0.640733 on 4 procs for 100 steps with 32000 atoms
+Loop time of 0.635957 on 4 procs for 100 steps with 32000 atoms
 
-Performance: 67422.779 tau/day, 156.071 timesteps/s
-99.7% CPU use with 4 MPI tasks x no OpenMP threads
+Performance: 67929.172 tau/day, 157.243 timesteps/s
+99.9% CPU use with 4 MPI tasks x no OpenMP threads
 
 MPI task timing breakdown:
 Section |  min time  |  avg time  |  max time  |%varavg| %total
 ---------------------------------------------------------------
-Pair    | 0.49487    | 0.51733    | 0.5322     |   1.9 | 80.74
-Neigh   | 0.061131   | 0.063685   | 0.065433   |   0.6 |  9.94
-Comm    | 0.02457    | 0.042349   | 0.069598   |   8.1 |  6.61
-Output  | 5.9843e-05 | 6.3181e-05 | 6.6996e-05 |   0.0 |  0.01
-Modify  | 0.012961   | 0.013863   | 0.014491   |   0.5 |  2.16
-Other   |            | 0.003448   |            |       |  0.54
+Pair    | 0.51335    | 0.51822    | 0.52569    |   0.7 | 81.49
+Neigh   | 0.063695   | 0.064309   | 0.065397   |   0.3 | 10.11
+Comm    | 0.027525   | 0.03629    | 0.041959   |   3.1 |  5.71
+Output  | 6.3896e-05 | 6.6698e-05 | 7.081e-05  |   0.0 |  0.01
+Modify  | 0.012472   | 0.01254    | 0.012618   |   0.1 |  1.97
+Other   |            | 0.004529   |            |       |  0.71
 
 Nlocal:    8000 ave 8037 max 7964 min
 Histogram: 2 0 0 0 0 0 0 0 1 1

bench/log.6Oct16.lj.scaled.icc.4

@@ -1,4 +1,4 @@
-LAMMPS (15 Feb 2016)
+LAMMPS (6 Oct 2016)
 # 3d Lennard-Jones melt
 
 variable	x index 1
@@ -50,20 +50,20 @@ Memory usage per processor = 8.13678 Mbytes
 Step Temp E_pair E_mol TotEng Press 
        0         1.44   -6.7733681            0   -4.6133849   -5.0196788 
      100   0.75841891    -5.759957            0   -4.6223375   0.20008866 
-Loop time of 2.57914 on 4 procs for 100 steps with 128000 atoms
+Loop time of 2.55762 on 4 procs for 100 steps with 128000 atoms
 
-Performance: 16749.768 tau/day, 38.773 timesteps/s
+Performance: 16890.677 tau/day, 39.099 timesteps/s
 99.8% CPU use with 4 MPI tasks x no OpenMP threads
 
 MPI task timing breakdown:
 Section |  min time  |  avg time  |  max time  |%varavg| %total
 ---------------------------------------------------------------
-Pair    | 2.042      | 2.1092     | 2.1668     |   3.1 | 81.78
-Neigh   | 0.23982    | 0.24551    | 0.25233    |   1.0 |  9.52
-Comm    | 0.067088   | 0.13887    | 0.22681    |  15.7 |  5.38
-Output  | 0.00013185 | 0.00021666 | 0.00027108 |   0.4 |  0.01
-Modify  | 0.060348   | 0.071269   | 0.077063   |   2.5 |  2.76
-Other   |            | 0.01403    |            |       |  0.54
+Pair    | 2.0583     | 2.0988     | 2.1594     |   2.6 | 82.06
+Neigh   | 0.24411    | 0.24838    | 0.25585    |   0.9 |  9.71
+Comm    | 0.066397   | 0.13872    | 0.1863     |  11.9 |  5.42
+Output  | 0.00012994 | 0.00021023 | 0.00025702 |   0.3 |  0.01
+Modify  | 0.055533   | 0.058343   | 0.061791   |   1.2 |  2.28
+Other   |            | 0.0132     |            |       |  0.52
 
 Nlocal:    32000 ave 32060 max 31939 min
 Histogram: 1 0 1 0 0 0 0 1 0 1

bench/log.6Oct16.rhodo.fixed.icc.1

@@ -1,4 +1,4 @@
-LAMMPS (15 Feb 2016)
+LAMMPS (6 Oct 2016)
 # Rhodopsin model
 
 units           real
@@ -56,6 +56,7 @@ timestep        2.0
 
 run		100
 PPPM initialization ...
+WARNING: Using 12-bit tables for long-range coulomb (../kspace.cpp:316)
   G vector (1/distance) = 0.248835
   grid = 25 32 32
   stencil order = 5
@@ -70,41 +71,41 @@ Neighbor list info ...
   master list distance cutoff = 12
   ghost atom cutoff = 12
   binsize = 6 -> bins = 10 13 13
-Memory usage per processor = 91.7487 Mbytes
+Memory usage per processor = 93.2721 Mbytes
 ---------------- Step        0 ----- CPU =      0.0000 (sec) ----------------
 TotEng   =    -25356.2064 KinEng   =     21444.8313 Temp     =       299.0397 
 PotEng   =    -46801.0377 E_bond   =      2537.9940 E_angle  =     10921.3742 
 E_dihed  =      5211.7865 E_impro  =       213.5116 E_vdwl   =     -2307.8634 
-E_coul   =    207025.8927 E_long   =   -270403.7333 Press    =      -142.6035 
+E_coul   =    207025.8927 E_long   =   -270403.7333 Press    =      -149.3301 
 Volume   =    307995.0335 
----------------- Step       50 ----- CPU =     17.6362 (sec) ----------------
-TotEng   =    -25330.0828 KinEng   =     21501.0029 Temp     =       299.8230 
-PotEng   =    -46831.0857 E_bond   =      2471.7004 E_angle  =     10836.4975 
-E_dihed  =      5239.6299 E_impro  =       227.1218 E_vdwl   =     -1993.2754 
-E_coul   =    206797.6331 E_long   =   -270410.3930 Press    =       237.6701 
-Volume   =    308031.5639 
----------------- Step      100 ----- CPU =     35.9089 (sec) ----------------
-TotEng   =    -25290.7593 KinEng   =     21592.0117 Temp     =       301.0920 
-PotEng   =    -46882.7709 E_bond   =      2567.9807 E_angle  =     10781.9408 
-E_dihed  =      5198.7432 E_impro  =       216.7834 E_vdwl   =     -1902.4783 
-E_coul   =    206659.2326 E_long   =   -270404.9733 Press    =         6.9960 
-Volume   =    308133.9888 
-Loop time of 35.9089 on 1 procs for 100 steps with 32000 atoms
+---------------- Step       50 ----- CPU =     17.2007 (sec) ----------------
+TotEng   =    -25330.0321 KinEng   =     21501.0036 Temp     =       299.8230 
+PotEng   =    -46831.0357 E_bond   =      2471.7033 E_angle  =     10836.5108 
+E_dihed  =      5239.6316 E_impro  =       227.1219 E_vdwl   =     -1993.2763 
+E_coul   =    206797.6655 E_long   =   -270410.3927 Press    =       237.6866 
+Volume   =    308031.5640 
+---------------- Step      100 ----- CPU =     35.0315 (sec) ----------------
+TotEng   =    -25290.7387 KinEng   =     21591.9096 Temp     =       301.0906 
+PotEng   =    -46882.6484 E_bond   =      2567.9789 E_angle  =     10781.9556 
+E_dihed  =      5198.7493 E_impro  =       216.7863 E_vdwl   =     -1902.6458 
+E_coul   =    206659.5006 E_long   =   -270404.9733 Press    =         6.7898 
+Volume   =    308133.9933 
+Loop time of 35.0316 on 1 procs for 100 steps with 32000 atoms
 
-Performance: 0.481 ns/day, 49.874 hours/ns, 2.785 timesteps/s
+Performance: 0.493 ns/day, 48.655 hours/ns, 2.855 timesteps/s
 99.9% CPU use with 1 MPI tasks x no OpenMP threads
 
 MPI task timing breakdown:
 Section |  min time  |  avg time  |  max time  |%varavg| %total
 ---------------------------------------------------------------
-Pair    | 25.731     | 25.731     | 25.731     |   0.0 | 71.66
-Bond    | 1.2771     | 1.2771     | 1.2771     |   0.0 |  3.56
-Kspace  | 3.2094     | 3.2094     | 3.2094     |   0.0 |  8.94
-Neigh   | 4.4538     | 4.4538     | 4.4538     |   0.0 | 12.40
-Comm    | 0.068507   | 0.068507   | 0.068507   |   0.0 |  0.19
-Output  | 0.00025916 | 0.00025916 | 0.00025916 |   0.0 |  0.00
-Modify  | 1.1417     | 1.1417     | 1.1417     |   0.0 |  3.18
-Other   |            | 0.027      |            |       |  0.08
+Pair    | 25.021     | 25.021     | 25.021     |   0.0 | 71.42
+Bond    | 1.2834     | 1.2834     | 1.2834     |   0.0 |  3.66
+Kspace  | 3.2116     | 3.2116     | 3.2116     |   0.0 |  9.17
+Neigh   | 4.2767     | 4.2767     | 4.2767     |   0.0 | 12.21
+Comm    | 0.069283   | 0.069283   | 0.069283   |   0.0 |  0.20
+Output  | 0.00028205 | 0.00028205 | 0.00028205 |   0.0 |  0.00
+Modify  | 1.14       | 1.14       | 1.14       |   0.0 |  3.25
+Other   |            | 0.02938    |            |       |  0.08
 
 Nlocal:    32000 ave 32000 max 32000 min
 Histogram: 1 0 0 0 0 0 0 0 0 0
@@ -113,9 +114,9 @@ Histogram: 1 0 0 0 0 0 0 0 0 0
 Neighs:    1.20281e+07 ave 1.20281e+07 max 1.20281e+07 min
 Histogram: 1 0 0 0 0 0 0 0 0 0
 
-Total # of neighbors = 12028107
+Total # of neighbors = 12028098
 Ave neighs/atom = 375.878
 Ave special neighs/atom = 7.43187
 Neighbor list builds = 11
 Dangerous builds = 0
-Total wall time: 0:00:37
+Total wall time: 0:00:36

bench/log.6Oct16.rhodo.fixed.icc.4

@@ -1,4 +1,4 @@
-LAMMPS (15 Feb 2016)
+LAMMPS (6 Oct 2016)
 # Rhodopsin model
 
 units           real
@@ -56,6 +56,7 @@ timestep        2.0
 
 run		100
 PPPM initialization ...
+WARNING: Using 12-bit tables for long-range coulomb (../kspace.cpp:316)
   G vector (1/distance) = 0.248835
   grid = 25 32 32
   stencil order = 5
@@ -70,52 +71,52 @@ Neighbor list info ...
   master list distance cutoff = 12
   ghost atom cutoff = 12
   binsize = 6 -> bins = 10 13 13
-Memory usage per processor = 36.629 Mbytes
+Memory usage per processor = 37.3604 Mbytes
 ---------------- Step        0 ----- CPU =      0.0000 (sec) ----------------
 TotEng   =    -25356.2064 KinEng   =     21444.8313 Temp     =       299.0397 
 PotEng   =    -46801.0377 E_bond   =      2537.9940 E_angle  =     10921.3742 
 E_dihed  =      5211.7865 E_impro  =       213.5116 E_vdwl   =     -2307.8634 
-E_coul   =    207025.8927 E_long   =   -270403.7333 Press    =      -142.6035 
+E_coul   =    207025.8927 E_long   =   -270403.7333 Press    =      -149.3301 
 Volume   =    307995.0335 
----------------- Step       50 ----- CPU =      4.7461 (sec) ----------------
-TotEng   =    -25330.0828 KinEng   =     21501.0029 Temp     =       299.8230 
-PotEng   =    -46831.0857 E_bond   =      2471.7004 E_angle  =     10836.4975 
-E_dihed  =      5239.6299 E_impro  =       227.1218 E_vdwl   =     -1993.2754 
-E_coul   =    206797.6331 E_long   =   -270410.3930 Press    =       237.6701 
-Volume   =    308031.5639 
----------------- Step      100 ----- CPU =      9.6332 (sec) ----------------
-TotEng   =    -25290.7591 KinEng   =     21592.0117 Temp     =       301.0920 
-PotEng   =    -46882.7708 E_bond   =      2567.9807 E_angle  =     10781.9408 
-E_dihed  =      5198.7432 E_impro  =       216.7834 E_vdwl   =     -1902.4783 
-E_coul   =    206659.2327 E_long   =   -270404.9733 Press    =         6.9960 
-Volume   =    308133.9888 
-Loop time of 9.63322 on 4 procs for 100 steps with 32000 atoms
+---------------- Step       50 ----- CPU =      4.6056 (sec) ----------------
+TotEng   =    -25330.0321 KinEng   =     21501.0036 Temp     =       299.8230 
+PotEng   =    -46831.0357 E_bond   =      2471.7033 E_angle  =     10836.5108 
+E_dihed  =      5239.6316 E_impro  =       227.1219 E_vdwl   =     -1993.2763 
+E_coul   =    206797.6655 E_long   =   -270410.3927 Press    =       237.6866 
+Volume   =    308031.5640 
+---------------- Step      100 ----- CPU =      9.3910 (sec) ----------------
+TotEng   =    -25290.7386 KinEng   =     21591.9096 Temp     =       301.0906 
+PotEng   =    -46882.6482 E_bond   =      2567.9789 E_angle  =     10781.9556 
+E_dihed  =      5198.7493 E_impro  =       216.7863 E_vdwl   =     -1902.6458 
+E_coul   =    206659.5007 E_long   =   -270404.9733 Press    =         6.7898 
+Volume   =    308133.9933 
+Loop time of 9.39107 on 4 procs for 100 steps with 32000 atoms
 
-Performance: 1.794 ns/day, 13.379 hours/ns, 10.381 timesteps/s
-99.9% CPU use with 4 MPI tasks x no OpenMP threads
+Performance: 1.840 ns/day, 13.043 hours/ns, 10.648 timesteps/s
+99.8% CPU use with 4 MPI tasks x no OpenMP threads
 
 MPI task timing breakdown:
 Section |  min time  |  avg time  |  max time  |%varavg| %total
 ---------------------------------------------------------------
-Pair    | 6.4364     | 6.5993     | 6.7208     |   4.7 | 68.51
-Bond    | 0.30755    | 0.32435    | 0.35704    |   3.4 |  3.37
-Kspace  | 0.92248    | 1.0782     | 1.2597     |  13.0 | 11.19
-Neigh   | 1.1669     | 1.1672     | 1.1675     |   0.0 | 12.12
-Comm    | 0.094674   | 0.098065   | 0.10543    |   1.4 |  1.02
-Output  | 0.00015521 | 0.00016224 | 0.00018215 |   0.1 |  0.00
-Modify  | 0.32982    | 0.34654    | 0.35365    |   1.6 |  3.60
-Other   |            | 0.01943    |            |       |  0.20
+Pair    | 6.2189     | 6.3266     | 6.6072     |   6.5 | 67.37
+Bond    | 0.30793    | 0.32122    | 0.3414     |   2.4 |  3.42
+Kspace  | 0.87994    | 1.1644     | 1.2855     |  15.3 | 12.40
+Neigh   | 1.1358     | 1.136      | 1.1362     |   0.0 | 12.10
+Comm    | 0.08292    | 0.084935   | 0.087077   |   0.5 |  0.90
+Output  | 0.00015712 | 0.00016558 | 0.00018501 |   0.1 |  0.00
+Modify  | 0.33717    | 0.34246    | 0.34794    |   0.7 |  3.65
+Other   |            | 0.01526    |            |       |  0.16
 
 Nlocal:    8000 ave 8143 max 7933 min
 Histogram: 1 2 0 0 0 0 0 0 0 1
 Nghost:    22733.5 ave 22769 max 22693 min
 Histogram: 1 0 0 0 0 2 0 0 0 1
-Neighs:    3.00703e+06 ave 3.0975e+06 max 2.96493e+06 min
+Neighs:    3.00702e+06 ave 3.0975e+06 max 2.96492e+06 min
 Histogram: 1 2 0 0 0 0 0 0 0 1
 
-Total # of neighbors = 12028107
+Total # of neighbors = 12028098
 Ave neighs/atom = 375.878
 Ave special neighs/atom = 7.43187
 Neighbor list builds = 11
 Dangerous builds = 0
-Total wall time: 0:00:10
+Total wall time: 0:00:09

bench/log.6Oct16.rhodo.scaled.icc.4

@@ -1,4 +1,4 @@
-LAMMPS (15 Feb 2016)
+LAMMPS (6 Oct 2016)
 # Rhodopsin model
 
 variable	x index 1
@@ -77,6 +77,7 @@ timestep        2.0
 
 run		100
 PPPM initialization ...
+WARNING: Using 12-bit tables for long-range coulomb (../kspace.cpp:316)
   G vector (1/distance) = 0.248593
   grid = 48 60 36
   stencil order = 5
@@ -91,52 +92,52 @@ Neighbor list info ...
   master list distance cutoff = 12
   ghost atom cutoff = 12
   binsize = 6 -> bins = 19 26 13
-Memory usage per processor = 95.5339 Mbytes
+Memory usage per processor = 96.9597 Mbytes
 ---------------- Step        0 ----- CPU =      0.0000 (sec) ----------------
 TotEng   =   -101425.4887 KinEng   =     85779.3251 Temp     =       299.0304 
 PotEng   =   -187204.8138 E_bond   =     10151.9760 E_angle  =     43685.4968 
 E_dihed  =     20847.1460 E_impro  =       854.0463 E_vdwl   =     -9231.4537 
-E_coul   =    827053.5824 E_long   =  -1080565.6077 Press    =      -142.3092 
+E_coul   =    827053.5824 E_long   =  -1080565.6077 Press    =      -149.0358 
 Volume   =   1231980.1340 
----------------- Step       50 ----- CPU =     18.7806 (sec) ----------------
-TotEng   =   -101320.2677 KinEng   =     86003.4837 Temp     =       299.8118 
-PotEng   =   -187323.7514 E_bond   =      9887.1072 E_angle  =     43346.7922 
-E_dihed  =     20958.7032 E_impro  =       908.4715 E_vdwl   =     -7973.4457 
-E_coul   =    826141.3831 E_long   =  -1080592.7629 Press    =       238.0161 
-Volume   =   1232126.1855 
----------------- Step      100 ----- CPU =     38.3684 (sec) ----------------
-TotEng   =   -101158.1849 KinEng   =     86355.6149 Temp     =       301.0393 
-PotEng   =   -187513.7998 E_bond   =     10272.0693 E_angle  =     43128.6454 
-E_dihed  =     20793.9759 E_impro  =       867.0826 E_vdwl   =     -7586.7186 
-E_coul   =    825583.7122 E_long   =  -1080572.5667 Press    =        15.2151 
-Volume   =   1232535.8423 
-Loop time of 38.3684 on 4 procs for 100 steps with 128000 atoms
+---------------- Step       50 ----- CPU =     18.1689 (sec) ----------------
+TotEng   =   -101320.0211 KinEng   =     86003.4933 Temp     =       299.8118 
+PotEng   =   -187323.5144 E_bond   =      9887.1189 E_angle  =     43346.8448 
+E_dihed  =     20958.7108 E_impro  =       908.4721 E_vdwl   =     -7973.4486 
+E_coul   =    826141.5493 E_long   =  -1080592.7617 Press    =       238.0404 
+Volume   =   1232126.1814 
+---------------- Step      100 ----- CPU =     37.2027 (sec) ----------------
+TotEng   =   -101157.9546 KinEng   =     86355.7413 Temp     =       301.0398 
+PotEng   =   -187513.6959 E_bond   =     10272.0456 E_angle  =     43128.7018 
+E_dihed  =     20794.0107 E_impro  =       867.0928 E_vdwl   =     -7587.2409 
+E_coul   =    825584.2416 E_long   =  -1080572.5474 Press    =        15.1729 
+Volume   =   1232535.8440 
+Loop time of 37.2028 on 4 procs for 100 steps with 128000 atoms
 
-Performance: 0.450 ns/day, 53.289 hours/ns, 2.606 timesteps/s
+Performance: 0.464 ns/day, 51.671 hours/ns, 2.688 timesteps/s
 99.9% CPU use with 4 MPI tasks x no OpenMP threads
 
 MPI task timing breakdown:
 Section |  min time  |  avg time  |  max time  |%varavg| %total
 ---------------------------------------------------------------
-Pair    | 26.205     | 26.538     | 26.911     |   5.0 | 69.17
-Bond    | 1.298      | 1.3125     | 1.3277     |   1.0 |  3.42
-Kspace  | 3.7099     | 4.0992     | 4.4422     |  13.3 | 10.68
-Neigh   | 4.6137     | 4.6144     | 4.615      |   0.0 | 12.03
-Comm    | 0.21398    | 0.21992    | 0.22886    |   1.2 |  0.57
-Output  | 0.00030518 | 0.00031543 | 0.00033307 |   0.1 |  0.00
-Modify  | 1.5066     | 1.5232     | 1.5388     |   1.0 |  3.97
-Other   |            | 0.06051    |            |       |  0.16
+Pair    | 25.431     | 25.738     | 25.984     |   4.0 | 69.18
+Bond    | 1.2966     | 1.3131     | 1.3226     |   0.9 |  3.53
+Kspace  | 3.7563     | 4.0123     | 4.3127     |  10.0 | 10.79
+Neigh   | 4.3778     | 4.378      | 4.3782     |   0.0 | 11.77
+Comm    | 0.1903     | 0.19549    | 0.20485    |   1.3 |  0.53
+Output  | 0.00031805 | 0.00037521 | 0.00039601 |   0.2 |  0.00
+Modify  | 1.4861     | 1.5051     | 1.5122     |   0.9 |  4.05
+Other   |            | 0.05992    |            |       |  0.16
 
 Nlocal:    32000 ave 32000 max 32000 min
 Histogram: 4 0 0 0 0 0 0 0 0 0
 Nghost:    47957 ave 47957 max 47957 min
 Histogram: 4 0 0 0 0 0 0 0 0 0
-Neighs:    1.20281e+07 ave 1.20572e+07 max 1.1999e+07 min
+Neighs:    1.20281e+07 ave 1.20572e+07 max 1.19991e+07 min
 Histogram: 2 0 0 0 0 0 0 0 0 2
 
-Total # of neighbors = 48112472
+Total # of neighbors = 48112540
 Ave neighs/atom = 375.879
 Ave special neighs/atom = 7.43187
 Neighbor list builds = 11
 Dangerous builds = 0
-Total wall time: 0:00:39
+Total wall time: 0:00:38

doc/.gitignore

@@ -1 +1,5 @@
-
+/html
+/LAMMPS.epub
+/LAMMPS.mobi
+/Manual.pdf
+/Developer.pdf

doc/Makefile

@@ -8,19 +8,21 @@ VENV          = $(BUILDDIR)/docenv
 TXT2RST       = $(VENV)/bin/txt2rst
 
 PYTHON        = $(shell which python3)
+HAS_PYTHON3    = NO
+HAS_VIRTUALENV = NO
 
-ifeq ($(shell which python3 >/dev/null 2>&1; echo $$?), 1)
-$(error Python3 was not found! Please check README.md for further instructions)
+ifeq ($(shell which python3 >/dev/null 2>&1; echo $$?), 0)
+HAS_PYTHON3 = YES
 endif
 
-ifeq ($(shell which virtualenv >/dev/null 2>&1; echo $$?), 1)
-$(error virtualenv was not found! Please check README.md for further instructions)
+ifeq ($(shell which virtualenv >/dev/null 2>&1; echo $$?), 0)
+HAS_VIRTUALENV = YES
 endif
 
 SOURCES=$(wildcard src/*.txt)
 OBJECTS=$(SOURCES:src/%.txt=$(RSTDIR)/%.rst)
 
-.PHONY: help clean-all clean html pdf old venv
+.PHONY: help clean-all clean epub html pdf old venv
 
 # ------------------------------------------
 
@@ -30,6 +32,7 @@ help:
 	@echo "  pdf        create Manual.pdf and Developer.pdf in this dir"
 	@echo "  old        create old-style HTML doc pages in old dir"
 	@echo "  fetch      fetch HTML and PDF files from LAMMPS web site"
+	@echo "  epub       create ePUB format manual for e-book readers"
 	@echo "  clean      remove all intermediate RST files"
 	@echo "  clean-all  reset the entire build environment"
 	@echo "  txt2html   build txt2html tool"
@@ -40,7 +43,7 @@ clean-all:
 	rm -rf $(BUILDDIR)/* utils/txt2html/txt2html.exe
 
 clean:
-	rm -rf $(RSTDIR)
+	rm -rf $(RSTDIR) html
 
 html: $(OBJECTS)
 	@(\
@@ -61,6 +64,20 @@ html: $(OBJECTS)
 	@rm -rf html/USER/*/*.[sg]*
 	@echo "Build finished. The HTML pages are in doc/html."
 
+epub: $(OBJECTS)
+	@mkdir -p epub
+	@rm -f LAMMPS.epub
+	@cp src/JPG/lammps-logo.png epub/
+	@(\
+		. $(VENV)/bin/activate ;\
+		cp -r src/* $(RSTDIR)/ ;\
+		sphinx-build -j 8 -b epub -c utils/sphinx-config -d $(BUILDDIR)/doctrees $(RSTDIR) epub ;\
+		deactivate ;\
+	)
+	@mv  epub/LAMMPS.epub .
+	@rm -rf epub
+	@echo "Build finished. The ePUB manual file is created."
+
 pdf: utils/txt2html/txt2html.exe
 	@(\
 		cd src; \
@@ -109,6 +126,8 @@ $(RSTDIR)/%.rst : src/%.txt $(TXT2RST)
 	)
 
 $(VENV):
+	@if [ "$(HAS_PYTHON3)" == "NO" ] ; then echo "Python3 was not found! Please check README.md for further instructions" 1>&2; exit 1; fi
+	@if [ "$(HAS_VIRTUALENV)" == "NO" ] ; then echo "virtualenv was not found! Please check README.md for further instructions" 1>&2; exit 1; fi
 	@( \
 		virtualenv -p $(PYTHON) $(VENV); \
 		. $(VENV)/bin/activate; \

doc/README

@@ -1,10 +1,47 @@
-Generation of LAMMPS Documentation
+LAMMPS Documentation
+
+Depending on how you obtained LAMMPS, this directory has 2 or 3
+sub-directories and optionally 2 PDF files and an ePUB file:
+
+src             content files for LAMMPS documentation
+html            HTML version of the LAMMPS manual (see html/Manual.html)
+tools           tools and settings for building the documentation
+Manual.pdf      large PDF version of entire manual
+Developer.pdf   small PDF with info about how LAMMPS is structured
+LAMMPS.epub     Manual in ePUB format
+
+If you downloaded LAMMPS as a tarball from the web site, all these
+directories and files should be included.
+
+If you downloaded LAMMPS from the public SVN or Git repositories, then
+the HTML and PDF files are not included.  Instead you need to create
+them, in one of three ways:
+
+(a) You can "fetch" the current HTML and PDF files from the LAMMPS web
+site.  Just type "make fetch".  This should create a html_www dir and
+Manual_www.pdf/Developer_www.pdf files.  Note that if new LAMMPS
+features have been added more recently than the date of your version,
+the fetched documentation will include those changes (but your source
+code will not, unless you update your local repository).
+
+(b) You can build the HTML and PDF files yourself, by typing "make
+html" followed by "make pdf".  Note that the PDF make requires the
+HTML files already exist.  This requires various tools including
+Sphinx, which the build process will attempt to download and install
+on your system, if not already available.  See more details below.
+
+(c) You can genererate an older, simpler, less-fancy style of HTML
+documentation by typing "make old".  This will create an "old"
+directory.  This can be useful if (b) does not work on your box for
+some reason, or you want to quickly view the HTML version of a doc
+page you have created or edited yourself within the src directory.
+E.g. if you are planning to submit a new feature to LAMMPS.
+
+----------------
 
 The generation of all documentation is managed by the Makefile in this
 dir.
 
-----------------
-
 Options:
 
 make html         # generate HTML in html dir using Sphinx
@@ -13,6 +50,7 @@ make pdf          # generate 2 PDF files (Manual.pdf,Developer.pdf)
 make old          # generate old-style HTML pages in old dir via txt2html
 make fetch        # fetch HTML doc pages and 2 PDF files from web site
                   #   as a tarball and unpack into html dir and 2 PDFs
+make epub         # generate LAMMPS.epub in ePUB format using Sphinx 
 make clean        # remove intermediate RST files created by HTML build
 make clean-all    # remove entire build folder and any cached data
 
@@ -51,3 +89,27 @@ Once Python 3 is installed, open a Terminal and type
 pip3 install virtualenv
 
 This will install virtualenv from the Python Package Index.
+
+----------------
+
+Installing prerequisites for PDF build
+
+[TBA]
+
+----------------
+
+Installing prerequisites for epub build
+
+## ePUB
+
+Same as for HTML. This uses the same tools and configuration
+files as the HTML tree.
+
+For converting the generated ePUB file to a mobi format file
+(for e-book readers like Kindle, that cannot read ePUB), you
+also need to have the 'ebook-convert' tool from the "calibre"
+software installed. http://calibre-ebook.com/
+You first create the ePUB file with 'make epub' and then do:
+
+ebook-convert LAMMPS.epub LAMMPS.mobi
+

doc/src/Eqs/fix_grem.tex

@@ -0,0 +1,9 @@
+\documentclass[12pt]{article}
+
+\begin{document}
+
+$$
+  T_{eff} = \lambda + \eta (H - H_0)
+$$
+
+\end{document}

doc/src/Eqs/pair_dpd_conservative.tex

@@ -1,9 +0,0 @@
-\documentclass[12pt]{article}
-\pagestyle{empty}
-\begin{document}
-
-$$
-F^C = A \omega_{ij} \qquad \qquad r_{ij} < r_c
-$$
-
-\end{document}

doc/src/Eqs/pair_dpd_energy.tex

@@ -0,0 +1,12 @@
+\documentclass[12pt]{article}
+\pagestyle{empty}
+\begin{document}
+
+\begin{eqnarray*}
+  du_{i}^{cond} & = & \kappa_{ij}(\frac{1}{\theta_{i}}-\frac{1}{\theta_{j}})\omega_{ij}^{2} + \alpha_{ij}\omega_{ij}\zeta_{ij}^{q}(\Delta{t})^{-1/2} \\
+  du_{i}^{mech} & = & -\frac{1}{2}\gamma_{ij}\omega_{ij}^{2}(\frac{\vec{r_{ij}}}{r_{ij}}\bullet\vec{v_{ij}})^{2} - 
+  \frac{\sigma^{2}_{ij}}{4}(\frac{1}{m_{i}}+\frac{1}{m_{j}})\omega_{ij}^{2} - 
+  \frac{1}{2}\sigma_{ij}\omega_{ij}(\frac{\vec{r_{ij}}}{r_{ij}}\bullet\vec{v_{ij}})\zeta_{ij}(\Delta{t})^{-1/2} \\
+\end{eqnarray*}                           
+
+\end{document}

doc/src/Eqs/pair_dpd_energy_terms.tex

@@ -0,0 +1,11 @@
+\documentclass[12pt]{article}
+\pagestyle{empty}
+\begin{document}
+
+\begin{eqnarray*}
+  \alpha_{ij}^{2} & = & 2k_{B}\kappa_{ij} \\
+  \sigma^{2}_{ij} & = & 2\gamma_{ij}k_{B}\Theta_{ij} \\
+  \Theta_{ij}^{-1} & = & \frac{1}{2}(\frac{1}{\theta_{i}}+\frac{1}{\theta_{j}}) \\
+\end{eqnarray*}                           
+
+\end{document}

doc/src/Eqs/pair_tersoff_mod_c.tex

@@ -0,0 +1,10 @@
+\documentclass[12pt]{article}
+\pagestyle{empty}
+
+\begin{document}
+
+\begin{eqnarray*}
+  V_{ij}  & =  & f_C(r_{ij}) \left[ f_R(r_{ij}) + b_{ij} f_A(r_{ij}) + c_0 \right]
+\end{eqnarray*}
+
+\end{document}

doc/src/Eqs/pressure.tex

@@ -3,7 +3,7 @@
 \begin{document}
 
 $$
-   P = \frac{N k_B T}{V} + \frac{\sum_{i}^{N} r_i \bullet f_i}{dV}
+   P = \frac{N k_B T}{V} + \frac{\sum_{i}^{N'} r_i \bullet f_i}{dV}
 $$
 
 \end{document}

doc/src/Eqs/pressure_tensor.tex

@@ -4,7 +4,7 @@
 
 $$
    P_{IJ} = \frac{\sum_{k}^{N} m_k v_{k_I} v_{k_J}}{V} + 
-   \frac{\sum_{k}^{N} r_{k_I} f_{k_J}}{V}
+   \frac{\sum_{k}^{N'} r_{k_I} f_{k_J}}{V}
 $$
 
 \end{document}

doc/src/Manual.txt

@@ -1,7 +1,7 @@
 <!-- HTML_ONLY -->
 <HEAD>
 <TITLE>LAMMPS Users Manual</TITLE>
-<META NAME="docnumber" CONTENT="22 Sep 2016 version">
+<META NAME="docnumber" CONTENT="22 Nov 2016 version">
 <META NAME="author" CONTENT="http://lammps.sandia.gov - Sandia National Laboratories">
 <META NAME="copyright" CONTENT="Copyright (2003) Sandia Corporation.  This software and manual is distributed under the GNU General Public License.">
 </HEAD>
@@ -21,7 +21,7 @@
 <H1></H1>
 
 LAMMPS Documentation :c,h3
-22 Sep 2016 version :c,h4
+22 Nov 2016 version :c,h4
 
 Version info: :h4
 
@@ -109,7 +109,7 @@ it gives quick access to documentation for all LAMMPS commands.
    :caption: User Documentation
    :name: userdoc
    :includehidden:
-   
+
    Section_intro
    Section_start
    Section_commands
@@ -144,7 +144,7 @@ Indices and tables
 
 * :ref:`genindex`
 * :ref:`search`
-   
+
 END_RST -->
 
 <!-- HTML_ONLY -->

doc/src/Section_accelerate.txt

@@ -117,7 +117,7 @@ PPPM. However, 2-FFT PPPM also requires a slightly larger mesh size to
 achieve the same accuracy as 4-FFT PPPM. For problems where the FFT
 cost is the performance bottleneck (typically large problems running
 on many processors), 2-FFT PPPM may be faster than 4-FFT PPPM.
-  
+
 Staggered PPPM performs calculations using two different meshes, one
 shifted slightly with respect to the other.  This can reduce force
 aliasing errors and increase the accuracy of the method, but also

doc/src/Section_commands.txt

@@ -37,14 +37,14 @@ simulation with all the settings.  Rather, the input script is read
 one line at a time and each command takes effect when it is read.
 Thus this sequence of commands:
 
-timestep 0.5 
-run      100 
+timestep 0.5
+run      100
 run      100 :pre
 
 does something different than this sequence:
 
-run      100 
-timestep 0.5 
+run      100
+timestep 0.5
 run      100 :pre
 
 In the first case, the specified timestep (0.5 fmsec) is used for two
@@ -97,7 +97,7 @@ single leading "#" will comment out the entire command.
 
 (3) The line is searched repeatedly for $ characters, which indicate
 variables that are replaced with a text string.  See an exception in
-(6).  
+(6).
 
 If the $ is followed by curly brackets, then the variable name is the
 text inside the curly brackets.  If no curly brackets follow the $,
@@ -106,7 +106,7 @@ the $.  Thus $\{myTemp\} and $x refer to variable names "myTemp" and
 "x".
 
 How the variable is converted to a text string depends on what style
-of variable it is; see the "variable"_variable doc page for details.
+of variable it is; see the "variable"_variable.html doc page for details.
 It can be a variable that stores multiple text strings, and return one
 of them.  The returned text string can be multiple "words" (space
 separated) which will then be interpreted as multiple arguments in the
@@ -123,7 +123,7 @@ variable X equal (xlo+xhi)/2+sqrt(v_area)
 region 1 block $X 2 INF INF EDGE EDGE
 variable X delete :pre
 
-can be replaced by 
+can be replaced by
 
 region 1 block $((xlo+xhi)/2+sqrt(v_area)) 2 INF INF EDGE EDGE :pre
 
@@ -282,78 +282,135 @@ the "minimize"_minimize.html command.  A parallel tempering
 3.4 Commands listed by category :link(cmd_4),h4
 
 This section lists all LAMMPS commands, grouped by category.  The
-"next section"_#cmd_5 lists the same commands alphabetically.  Note
-that some style options for some commands are part of specific LAMMPS
-packages, which means they cannot be used unless the package was
-included when LAMMPS was built.  Not all packages are included in a
-default LAMMPS build.  These dependencies are listed as Restrictions
-in the command's documentation.
+"next section"_#cmd_5 lists the same commands alphabetically.  The
+next section also includes (long) lists of style options for entries
+that appear in the following categories as a single command (fix,
+compute, pair, etc).  Commands that are added by user packages are not
+included in these categories, but they are in the next section.
 
 Initialization:
 
-"atom_modify"_atom_modify.html, "atom_style"_atom_style.html,
-"boundary"_boundary.html, "dimension"_dimension.html,
-"newton"_newton.html, "processors"_processors.html, "units"_units.html
+"newton"_newton.html,
+"package"_package.html,
+"processors"_processors.html,
+"suffix"_suffix.html,
+"units"_units.html
 
-Atom definition:
+Setup simulation box:
 
-"create_atoms"_create_atoms.html, "create_box"_create_box.html,
-"lattice"_lattice.html, "read_data"_read_data.html,
-"read_dump"_read_dump.html, "read_restart"_read_restart.html,
-"region"_region.html, "replicate"_replicate.html
+"boundary"_boundary.html,
+"box"_box.html,
+"change_box"_change_box.html,
+"create_box"_create_box.html,
+"dimension"_dimension.html,
+"lattice"_lattice.html,
+"region"_region.html
+
+Setup atoms:
+
+"atom_modify"_atom_modify.html,
+"atom_style"_atom_style.html,
+"balance"_balance.html,
+"create_atoms"_create_atoms.html,
+"create_bonds"_create_bonds.html,
+"delete_atoms"_delete_atoms.html,
+"delete_bonds"_delete_bonds.html,
+"displace_atoms"_displace_atoms.html,
+"group"_group.html,
+"mass"_mass.html,
+"molecule"_molecule.html,
+"read_data"_read_data.html,
+"read_dump"_read_dump.html,
+"read_restart"_read_restart.html,
+"replicate"_replicate.html,
+"set"_set.html,
+"velocity"_velocity.html
 
 Force fields:
 
-"angle_coeff"_angle_coeff.html, "angle_style"_angle_style.html,
-"bond_coeff"_bond_coeff.html, "bond_style"_bond_style.html,
-"dielectric"_dielectric.html, "dihedral_coeff"_dihedral_coeff.html,
+"angle_coeff"_angle_coeff.html,
+"angle_style"_angle_style.html,
+"bond_coeff"_bond_coeff.html,
+"bond_style"_bond_style.html,
+"bond_write"_bond_write.html,
+"dielectric"_dielectric.html,
+"dihedral_coeff"_dihedral_coeff.html,
 "dihedral_style"_dihedral_style.html,
 "improper_coeff"_improper_coeff.html,
 "improper_style"_improper_style.html,
-"kspace_modify"_kspace_modify.html, "kspace_style"_kspace_style.html,
-"pair_coeff"_pair_coeff.html, "pair_modify"_pair_modify.html,
-"pair_style"_pair_style.html, "pair_write"_pair_write.html,
+"kspace_modify"_kspace_modify.html,
+"kspace_style"_kspace_style.html,
+"pair_coeff"_pair_coeff.html,
+"pair_modify"_pair_modify.html,
+"pair_style"_pair_style.html,
+"pair_write"_pair_write.html,
 "special_bonds"_special_bonds.html
 
 Settings:
 
-"comm_style"_comm_style.html, "group"_group.html, "mass"_mass.html,
-"min_modify"_min_modify.html, "min_style"_min_style.html,
-"neigh_modify"_neigh_modify.html, "neighbor"_neighbor.html,
-"reset_timestep"_reset_timestep.html, "run_style"_run_style.html,
-"set"_set.html, "timestep"_timestep.html, "velocity"_velocity.html
+"comm_modify"_comm_modify.html,
+"comm_style"_comm_style.html,
+"info"_info.html,
+"min_modify"_min_modify.html,
+"min_style"_min_style.html,
+"neigh_modify"_neigh_modify.html,
+"neighbor"_neighbor.html,
+"partition"_partition.html,
+"reset_timestep"_reset_timestep.html,
+"run_style"_run_style.html,
+"timer"_timer.html,
+"timestep"_timestep.html
 
-Fixes:
+Operations within timestepping (fixes) and diagnositics (computes):
 
-"fix"_fix.html, "fix_modify"_fix_modify.html, "unfix"_unfix.html
-
-Computes:
-
-"compute"_compute.html, "compute_modify"_compute_modify.html,
-"uncompute"_uncompute.html
+"compute"_compute.html,
+"compute_modify"_compute_modify.html,
+"fix"_fix.html,
+"fix_modify"_fix_modify.html,
+"uncompute"_uncompute.html,
+"unfix"_unfix.html
 
 Output:
 
-"dump"_dump.html, "dump image"_dump_image.html,
-"dump_modify"_dump_modify.html, "dump movie"_dump_image.html,
-"restart"_restart.html, "thermo"_thermo.html,
-"thermo_modify"_thermo_modify.html, "thermo_style"_thermo_style.html,
-"undump"_undump.html, "write_data"_write_data.html,
-"write_dump"_write_dump.html, "write_restart"_write_restart.html
+"dump image"_dump_image.html,
+"dump movie"_dump_image.html,
+"dump"_dump.html,
+"dump_modify"_dump_modify.html,
+"restart"_restart.html,
+"thermo"_thermo.html,
+"thermo_modify"_thermo_modify.html,
+"thermo_style"_thermo_style.html,
+"undump"_undump.html,
+"write_coeff"_write_coeff.html,
+"write_data"_write_data.html,
+"write_dump"_write_dump.html,
+"write_restart"_write_restart.html
 
 Actions:
 
-"delete_atoms"_delete_atoms.html, "delete_bonds"_delete_bonds.html,
-"displace_atoms"_displace_atoms.html, "change_box"_change_box.html,
-"minimize"_minimize.html, "neb"_neb.html "prd"_prd.html,
-"rerun"_rerun.html, "run"_run.html, "temper"_temper.html
+"minimize"_minimize.html,
+"neb"_neb.html,
+"prd"_prd.html,
+"rerun"_rerun.html,
+"run"_run.html,
+"tad"_tad.html,
+"temper"_temper.html
 
-Miscellaneous:
+Input script control:
 
-"clear"_clear.html, "echo"_echo.html, "if"_if.html,
-"include"_include.html, "jump"_jump.html, "label"_label.html,
-"log"_log.html, "next"_next.html, "print"_print.html,
-"shell"_shell.html, "variable"_variable.html
+"clear"_clear.html,
+"echo"_echo.html,
+"if"_if.html,
+"include"_include.html,
+"jump"_jump.html,
+"label"_label.html,
+"log"_log.html,
+"next"_next.html,
+"print"_print.html,
+"python"_python.html,
+"quit"_quit.html,
+"shell"_shell.html,
+"variable"_variable.html
 
 :line
 
@@ -471,8 +528,11 @@ These are additional commands in USER packages, which can be used if
 package"_Section_start.html#start_3.
 
 "dump custom/vtk"_dump_custom_vtk.html,
+"dump nc"_dump_nc.html,
+"dump nc/mpiio"_dump_nc.html,
 "group2ndx"_group2ndx.html,
-"ndx2group"_group2ndx.html :tb(c=3,ea=c)
+"ndx2group"_group2ndx.html,
+"temper/grem"_temper_grem.html :tb(c=3,ea=c)
 
 :line
 
@@ -501,6 +561,7 @@ USER-INTEL, k = KOKKOS, o = USER-OMP, t = OPT.
 "bond/create"_fix_bond_create.html,
 "bond/swap"_fix_bond_swap.html,
 "box/relax"_fix_box_relax.html,
+"cmap"_fix_cmap.html,
 "controller"_fix_controller.html,
 "deform (k)"_fix_deform.html,
 "deposit"_fix_deposit.html,
@@ -515,6 +576,7 @@ USER-INTEL, k = KOKKOS, o = USER-OMP, t = OPT.
 "gcmc"_fix_gcmc.html,
 "gld"_fix_gld.html,
 "gravity (o)"_fix_gravity.html,
+"halt"_fix_halt.html,
 "heat"_fix_heat.html,
 "indent"_fix_indent.html,
 "langevin (k)"_fix_langevin.html,
@@ -570,7 +632,7 @@ USER-INTEL, k = KOKKOS, o = USER-OMP, t = OPT.
 "rigid/npt (o)"_fix_rigid.html,
 "rigid/nve (o)"_fix_rigid.html,
 "rigid/nvt (o)"_fix_rigid.html,
-"rigid/small (o)"_fix_rigid.html,
+<"rigid/small (o)"_fix_rigid.html,
 "rigid/small/nph"_fix_rigid.html,
 "rigid/small/npt"_fix_rigid.html,
 "rigid/small/nve"_fix_rigid.html,
@@ -598,6 +660,7 @@ USER-INTEL, k = KOKKOS, o = USER-OMP, t = OPT.
 "viscous"_fix_viscous.html,
 "wall/colloid"_fix_wall.html,
 "wall/gran"_fix_wall_gran.html,
+"wall/gran/region"_fix_wall_gran_region.html,
 "wall/harmonic"_fix_wall.html,
 "wall/lj1043"_fix_wall.html,
 "wall/lj126"_fix_wall.html,
@@ -616,6 +679,7 @@ package"_Section_start.html#start_3.
 "atc"_fix_atc.html,
 "ave/correlate/long"_fix_ave_correlate_long.html,
 "colvars"_fix_colvars.html,
+"dpd/energy"_fix_dpd_energy.html,
 "drude"_fix_drude.html,
 "drude/transform/direct"_fix_drude_transform.html,
 "drude/transform/reverse"_fix_drude_transform.html,
@@ -624,6 +688,7 @@ package"_Section_start.html#start_3.
 "eos/table/rx"_fix_eos_table_rx.html,
 "flow/gauss"_fix_flow_gauss.html,
 "gle"_fix_gle.html,
+"grem"_fix_grem.html,
 "imd"_fix_imd.html,
 "ipi"_fix_ipi.html,
 "langevin/drude"_fix_langevin_drude.html,
@@ -823,6 +888,8 @@ KOKKOS, o = USER-OMP, t = OPT.
 "body"_pair_body.html,
 "bop"_pair_bop.html,
 "born (go)"_pair_born.html,
+"born/coul/dsf"_pair_born.html,
+"born/coul/dsf/cs"_pair_born.html,
 "born/coul/long (go)"_pair_born.html,
 "born/coul/long/cs"_pair_born.html,
 "born/coul/msm (o)"_pair_born.html,
@@ -846,8 +913,8 @@ KOKKOS, o = USER-OMP, t = OPT.
 "coul/msm"_pair_coul.html,
 "coul/streitz"_pair_coul.html,
 "coul/wolf (ko)"_pair_coul.html,
-"dpd (o)"_pair_dpd.html,
-"dpd/tstat (o)"_pair_dpd.html,
+"dpd (go)"_pair_dpd.html,
+"dpd/tstat (go)"_pair_dpd.html,
 "dsmc"_pair_dsmc.html,
 "eam (gkot)"_pair_eam.html,
 "eam/alloy (gkot)"_pair_eam.html,
@@ -895,7 +962,7 @@ KOKKOS, o = USER-OMP, t = OPT.
 "lubricate/poly (o)"_pair_lubricate.html,
 "lubricateU"_pair_lubricateU.html,
 "lubricateU/poly"_pair_lubricateU.html,
-"meam (o)"_pair_meam.html,
+"meam"_pair_meam.html,
 "mie/cut (o)"_pair_mie.html,
 "morse (got)"_pair_morse.html,
 "nb3b/harmonic (o)"_pair_nb3b_harmonic.html,
@@ -916,11 +983,13 @@ KOKKOS, o = USER-OMP, t = OPT.
 "table (gko)"_pair_table.html,
 "tersoff (gkio)"_pair_tersoff.html,
 "tersoff/mod (gko)"_pair_tersoff_mod.html,
+"tersoff/mod/c (o)"_pair_tersoff_mod.html,
 "tersoff/zbl (gko)"_pair_tersoff_zbl.html,
 "tip4p/cut (o)"_pair_coul.html,
 "tip4p/long (o)"_pair_coul.html,
 "tri/lj"_pair_tri_lj.html,
-"vashishta (o)"_pair_vashishta.html,
+"vashishta (ko)"_pair_vashishta.html,
+"vashishta/table (o)"_pair_vashishta.html,
 "yukawa (go)"_pair_yukawa.html,
 "yukawa/colloid (go)"_pair_yukawa_colloid.html,
 "zbl (go)"_pair_zbl.html :tb(c=4,ea=c)
@@ -929,6 +998,7 @@ These are additional pair styles in USER packages, which can be used
 if "LAMMPS is built with the appropriate
 package"_Section_start.html#start_3.
 
+"agni (o)"_pair_agni.html,
 "awpmd/cut"_pair_awpmd.html,
 "buck/mdf"_pair_mdf.html,
 "coul/cut/soft (o)"_pair_lj_soft.html,
@@ -955,7 +1025,7 @@ package"_Section_start.html#start_3.
 "lj/sdk/coul/long (go)"_pair_sdk.html,
 "lj/sdk/coul/msm (o)"_pair_sdk.html,
 "lj/sf (o)"_pair_lj_sf.html,
-"meam/spline"_pair_meam_spline.html,
+"meam/spline (o)"_pair_meam_spline.html,
 "meam/sw/spline"_pair_meam_sw_spline.html,
 "mgpt"_pair_mgpt.html,
 "morse/smooth/linear"_pair_morse.html,

doc/src/Section_errors.txt

@@ -159,7 +159,7 @@ As a last resort, you can send an email directly to the
 These are two alphabetic lists of the "ERROR"_#error and
 "WARNING"_#warn messages LAMMPS prints out and the reason why.  If the
 explanation here is not sufficient, the documentation for the
-offending command may help.  
+offending command may help.
 Error and warning messages also list the source file and line number
 where the error was generated.  For example, this message
 
@@ -8116,11 +8116,11 @@ boundary of a processor's sub-domain has moved more than 1/2 the
 rebuilt and atoms being migrated to new processors.  This also means
 you may be missing pairwise interactions that need to be computed.
 The solution is to change the re-neighboring criteria via the
-"neigh_modify"_neigh_modify command.  The safest settings are "delay 0
-every 1 check yes".  Second, it may mean that an atom has moved far
-outside a processor's sub-domain or even the entire simulation box.
-This indicates bad physics, e.g. due to highly overlapping atoms, too
-large a timestep, etc. :dd
+"neigh_modify"_neigh_modify.html command.  The safest settings are
+"delay 0 every 1 check yes".  Second, it may mean that an atom has
+moved far outside a processor's sub-domain or even the entire
+simulation box. This indicates bad physics, e.g. due to highly
+overlapping atoms, too large a timestep, etc. :dd
 
 {Out of range atoms - cannot compute PPPM} :dt
 
@@ -8132,11 +8132,11 @@ boundary of a processor's sub-domain has moved more than 1/2 the
 rebuilt and atoms being migrated to new processors.  This also means
 you may be missing pairwise interactions that need to be computed.
 The solution is to change the re-neighboring criteria via the
-"neigh_modify"_neigh_modify command.  The safest settings are "delay 0
-every 1 check yes".  Second, it may mean that an atom has moved far
-outside a processor's sub-domain or even the entire simulation box.
-This indicates bad physics, e.g. due to highly overlapping atoms, too
-large a timestep, etc. :dd
+"neigh_modify"_neigh_modify.html command.  The safest settings are
+"delay 0 every 1 check yes".  Second, it may mean that an atom has
+moved far outside a processor's sub-domain or even the entire
+simulation box. This indicates bad physics, e.g. due to highly
+overlapping atoms, too large a timestep, etc. :dd
 
 {Out of range atoms - cannot compute PPPMDisp} :dt
 
@@ -8148,11 +8148,11 @@ boundary of a processor's sub-domain has moved more than 1/2 the
 rebuilt and atoms being migrated to new processors.  This also means
 you may be missing pairwise interactions that need to be computed.
 The solution is to change the re-neighboring criteria via the
-"neigh_modify"_neigh_modify command.  The safest settings are "delay 0
-every 1 check yes".  Second, it may mean that an atom has moved far
-outside a processor's sub-domain or even the entire simulation box.
-This indicates bad physics, e.g. due to highly overlapping atoms, too
-large a timestep, etc. :dd
+"neigh_modify"_neigh_modify.html command.  The safest settings are
+"delay 0 every 1 check yes".  Second, it may mean that an atom has
+moved far outside a processor's sub-domain or even the entire
+simulation box. This indicates bad physics, e.g. due to highly
+overlapping atoms, too large a timestep, etc. :dd
 
 {Overflow of allocated fix vector storage} :dt
 

doc/src/Section_example.txt

@@ -54,30 +54,30 @@ accelerate: run with various acceleration options (OpenMP, GPU, Phi)
 balance:  dynamic load balancing, 2d system
 body:     body particles, 2d system
 colloid:  big colloid particles in a small particle solvent, 2d system
-comb:	  models using the COMB potential
+comb:     models using the COMB potential
 coreshell: core/shell model using CORESHELL package
-crack:	  crack propagation in a 2d solid
+crack:    crack propagation in a 2d solid
 deposit:  deposit atoms and molecules on a surface
 dipole:   point dipolar particles, 2d system
 dreiding: methanol via Dreiding FF
 eim:      NaCl using the EIM potential
 ellipse:  ellipsoidal particles in spherical solvent, 2d system
-flow:	  Couette and Poiseuille flow in a 2d channel
+flow:     Couette and Poiseuille flow in a 2d channel
 friction: frictional contact of spherical asperities between 2d surfaces
 hugoniostat: Hugoniostat shock dynamics
-indent:	  spherical indenter into a 2d solid
+indent:   spherical indenter into a 2d solid
 kim:      use of potentials in Knowledge Base for Interatomic Models (KIM)
-meam:	  MEAM test for SiC and shear (same as shear examples)
-melt:	  rapid melt of 3d LJ system
+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
-msst:	  MSST shock dynamics
+min:      energy minimization of 2d LJ melt
+msst:     MSST shock dynamics
 nb3b:     use of nonbonded 3-body harmonic pair style
-neb:	  nudged elastic band (NEB) calculation for barrier finding
-nemd:	  non-equilibrium MD of 2d sheared system
+neb:      nudged elastic band (NEB) calculation for barrier finding
+nemd:     non-equilibrium MD of 2d sheared system
 obstacle: flow around two voids in a 2d channel
 peptide:  dynamics of a small solvated peptide chain (5-mer)
-peri:	  Peridynamic model of cylinder impacted by indenter
+peri:     Peridynamic model of cylinder impacted by indenter
 pour:     pouring of granular particles into a 3d box, then chute flow
 prd:      parallel replica dynamics of vacancy diffusion in bulk Si
 python:   using embedded Python in a LAMMPS input script
@@ -105,8 +105,8 @@ web site.
 
 If you uncomment the "dump image"_dump_image.html line(s) in the input
 script a series of JPG images will be produced by the run (assuming
-you built LAMMPS with JPG support; see "Section start
-2.2"_Section_start.html for details).  These can be viewed
+you built LAMMPS with JPG support; see "Section
+2.2"_Section_start.html#start_2 for details).  These can be viewed
 individually or turned into a movie or animated by tools like
 ImageMagick or QuickTime or various Windows-based tools.  See the
 "dump image"_dump_image.html doc page for more details.  E.g. this
@@ -120,7 +120,7 @@ browser.
 Uppercase directories :h4
 
 ASPHERE: various aspherical particle models, using ellipsoids, rigid bodies, line/triangle particles, etc
-COUPLE: examples of how to use LAMMPS as a library 
+COUPLE: examples of how to use LAMMPS as a library
 DIFFUSE: compute diffusion coefficients via several methods
 ELASTIC: compute elastic constants at zero temperature
 ELASTIC_T: compute elastic constants at finite temperature
@@ -136,5 +136,5 @@ The USER directory has a large number of sub-directories which
 correspond by name to a USER package.  They contain scripts that
 illustrate how to use the command(s) provided in that package.  Many
 of the sub-directories have their own README files which give further
-instructions.  See the "Section packages"_Section_packages.html doc
+instructions.  See the "Section 4"_Section_packages.html doc
 page for more info on specific USER packages.

doc/src/Section_history.txt

@@ -37,7 +37,7 @@ pitfalls or alternatives.
 
 Please see some of the closed issues for examples of how to
 suggest code enhancements, submit proposed changes, or report
-elated issues and how they are resoved. 
+possible bugs and how they are resoved.
 
 As an alternative to using GitHub, you may e-mail the
 "core developers"_http://lammps.sandia.gov/authors.html or send
@@ -71,7 +71,7 @@ a parallel framework similar to LAMMPS. Most notably, these have
 included many-body potentials - Stillinger-Weber, Tersoff, ReaxFF -
 and the associated charge-equilibration routines needed for ReaxFF.
 
-The "History link"_http://lammps.sandia.gov/history.html on the 
+The "History link"_http://lammps.sandia.gov/history.html on the
 LAMMPS WWW page gives a timeline of features added to the
 C++ open-source version of LAMMPS over the last several years.
 
@@ -80,7 +80,7 @@ site"_lws, except for Warp & GranFlow which were primarily used
 internally.  A brief listing of their features is given here.
 
 LAMMPS 2001
-    
+
     F90 + MPI
     dynamic memory
     spatial-decomposition parallelism
@@ -96,7 +96,7 @@ LAMMPS 2001
     user-defined diagnostics :ul
 
 LAMMPS 99
-    
+
     F77 + MPI
     static memory allocation
     spatial-decomposition parallelism

doc/src/Section_howto.txt

@@ -4,7 +4,7 @@
 :link(ld,Manual.html)
 :link(lc,Section_commands.html#comm)
 
-:line 
+:line
 
 6. How-to discussions :h3
 
@@ -68,7 +68,7 @@ Look at the {in.chain} input script provided in the {bench} directory
 of the LAMMPS distribution to see the original script that these 2
 scripts are based on.  If that script had the line
 
-restart	        50 tmp.restart :pre
+restart         50 tmp.restart :pre
 
 added to it, it would produce 2 binary restart files (tmp.restart.50
 and tmp.restart.100) as it ran.
@@ -76,17 +76,17 @@ and tmp.restart.100) as it ran.
 This script could be used to read the 1st restart file and re-run the
 last 50 timesteps:
 
-read_restart	tmp.restart.50 :pre
+read_restart    tmp.restart.50 :pre
 
-neighbor	0.4 bin
-neigh_modify	every 1 delay 1 :pre
+neighbor        0.4 bin
+neigh_modify    every 1 delay 1 :pre
 
-fix		1 all nve
-fix		2 all langevin 1.0 1.0 10.0 904297 :pre
+fix             1 all nve
+fix             2 all langevin 1.0 1.0 10.0 904297 :pre
 
-timestep	0.012 :pre
+timestep        0.012 :pre
 
-run		50 :pre
+run             50 :pre
 
 Note that the following commands do not need to be repeated because
 their settings are included in the restart file: {units, atom_style,
@@ -107,25 +107,25 @@ lmp_g++ -r tmp.restart.50 tmp.restart.data :pre
 
 Then, this script could be used to re-run the last 50 steps:
 
-units		lj
-atom_style	bond
-pair_style	lj/cut 1.12
-pair_modify	shift yes
-bond_style	fene
+units           lj
+atom_style      bond
+pair_style      lj/cut 1.12
+pair_modify     shift yes
+bond_style      fene
 special_bonds   0.0 1.0 1.0 :pre
 
-read_data	tmp.restart.data :pre
+read_data       tmp.restart.data :pre
 
-neighbor	0.4 bin
-neigh_modify	every 1 delay 1 :pre
+neighbor        0.4 bin
+neigh_modify    every 1 delay 1 :pre
 
-fix		1 all nve
-fix		2 all langevin 1.0 1.0 10.0 904297 :pre
+fix             1 all nve
+fix             2 all langevin 1.0 1.0 10.0 904297 :pre
 
-timestep	0.012 :pre
+timestep        0.012 :pre
 
-reset_timestep	50
-run		50 :pre
+reset_timestep  50
+run             50 :pre
 
 Note that nearly all the settings specified in the original {in.chain}
 script must be repeated, except the {pair_coeff} and {bond_coeff}
@@ -522,7 +522,7 @@ H mass = 1.008
 O charge = -1.040
 H charge = 0.520
 r0 of OH bond = 0.9572
-theta of HOH angle = 104.52 
+theta of HOH angle = 104.52
 OM distance = 0.15
 LJ epsilon of O-O = 0.1550
 LJ sigma of O-O = 3.1536
@@ -629,7 +629,7 @@ the SPC and SPC/E models.
 Wikipedia also has a nice article on "water
 models"_http://en.wikipedia.org/wiki/Water_model.
 
-:line 
+:line
 
 6.10 Coupling LAMMPS to other codes :link(howto_10),h4
 
@@ -729,7 +729,7 @@ LAMMPS and half to the other code and run both codes simultaneously
 before syncing them up periodically.  Or it might instantiate multiple
 instances of LAMMPS to perform different calculations.
 
-:line 
+:line
 
 6.11 Visualizing LAMMPS snapshots :link(howto_11),h4
 
@@ -832,7 +832,7 @@ rotation of [A], [B], and [C] and can be computed as follows:
 
 where A = | [A] | indicates the scalar length of [A]. The hat symbol (^)
 indicates the corresponding unit vector. {beta} and {gamma} are angles
-between the vectors described below. Note that by construction, 
+between the vectors described below. Note that by construction,
 [a], [b], and [c] have strictly positive x, y, and z components, respectively.
 If it should happen that
 [A], [B], and [C] form a left-handed basis, then the above equations
@@ -841,17 +841,17 @@ to first apply an inversion. This can be achieved
 by interchanging two basis vectors or by changing the sign of one of them.
 
 For consistency, the same rotation/inversion applied to the basis vectors
-must also be applied to atom positions, velocities, 
+must also be applied to atom positions, velocities,
 and any other vector quantities.
-This can be conveniently achieved by first converting to 
+This can be conveniently achieved by first converting to
 fractional coordinates in the
 old basis and then converting to distance coordinates in the new basis.
 The transformation is given by the following equation:
 
 :c,image(Eqs/rotate.jpg)
 
-where {V} is the volume of the box, [X] is the original vector quantity and 
-[x] is the vector in the LAMMPS basis. 
+where {V} is the volume of the box, [X] is the original vector quantity and
+[x] is the vector in the LAMMPS basis.
 
 There is no requirement that a triclinic box be periodic in any
 dimension, though it typically should be in at least the 2nd dimension
@@ -938,17 +938,17 @@ defined above.  The relationship between these 6 quantities
 (a,b,c,alpha,beta,gamma) and the LAMMPS box sizes (lx,ly,lz) =
 (xhi-xlo,yhi-ylo,zhi-zlo) and tilt factors (xy,xz,yz) is as follows:
 
-:c,image(Eqs/box.jpg) 
+:c,image(Eqs/box.jpg)
 
 The inverse relationship can be written as follows:
 
-:c,image(Eqs/box_inverse.jpg) 
+:c,image(Eqs/box_inverse.jpg)
 
-The values of {a}, {b}, {c} , {alpha}, {beta} , and {gamma} can be printed 
-out or accessed by computes using the 
-"thermo_style custom"_thermo_style.html keywords 
+The values of {a}, {b}, {c} , {alpha}, {beta} , and {gamma} can be printed
+out or accessed by computes using the
+"thermo_style custom"_thermo_style.html keywords
 {cella}, {cellb}, {cellc}, {cellalpha}, {cellbeta}, {cellgamma},
-respectively. 
+respectively.
 
 As discussed on the "dump"_dump.html command doc page, when the BOX
 BOUNDS for a snapshot is written to a dump file for a triclinic box,
@@ -1854,13 +1854,19 @@ internal LAMMPS operations.  Note that LAMMPS classes are defined
 within a LAMMPS namespace (LAMMPS_NS) if you use them from another C++
 application.
 
-Library.cpp contains these 5 basic functions:
+Library.cpp contains these functions for creating and destroying an
+instance of LAMMPS and sending it commands to execute.  See the
+documentation in the src/library.cpp file for details:
 
 void lammps_open(int, char **, MPI_Comm, void **)
+void lammps_open_no_mpi(int, char **, void **)
 void lammps_close(void *)
 int lammps_version(void *)
 void lammps_file(void *, char *)
-char *lammps_command(void *, char *) :pre
+char *lammps_command(void *, char *)
+void lammps_commands_list(void *, int, char **)
+void lammps_commands_string(void *, char *)
+void lammps_free(void *) :pre
 
 The lammps_open() function is used to initialize LAMMPS, passing in a
 list of strings as if they were "command-line
@@ -1880,6 +1886,10 @@ half to the other code and run both codes simultaneously before
 syncing them up periodically.  Or it might instantiate multiple
 instances of LAMMPS to perform different calculations.
 
+The lammps_open_no_mpi() function is similar except that no MPI
+communicator is passed from the caller.  Instead, MPI_COMM_WORLD is
+used to instantiate LAMMPS, and MPI is initialzed if necessary.
+
 The lammps_close() function is used to shut down an instance of LAMMPS
 and free all its memory.
 
@@ -1891,44 +1901,93 @@ changes to the LAMMPS command syntax between versions. The returned
 LAMMPS version code is an integer (e.g. 2 Sep 2015 results in
 20150902) that grows with every new LAMMPS version.
 
-The lammps_file() and lammps_command() functions are used to pass a
-file or string to LAMMPS as if it were an input script or single
-command in an input script.  Thus the calling code can read or
-generate a series of LAMMPS commands one line at a time and pass it
-thru the library interface to setup a problem and then run it,
-interleaving the lammps_command() calls with other calls to extract
-information from LAMMPS, perform its own operations, or call another
-code's library.
+The lammps_file(), lammps_command(), lammps_commands_list(), and
+lammps_commands_string() functions are used to pass one or more
+commands to LAMMPS to execute, the same as if they were coming from an
+input script.
 
-Other useful functions are also included in library.cpp.  For example:
+Via these functions, the calling code can read or generate a series of
+LAMMPS commands one or multiple at a time and pass it thru the library
+interface to setup a problem and then run it in stages.  The caller
+can interleave the command function calls with operations it performs,
+calls to extract information from or set information within LAMMPS, or
+calls to another code's library.
+
+The lammps_file() function passes the filename of an input script.
+The lammps_command() function passes a single command as a string.
+The lammps_commands_list() function passes multiple commands in a
+char** list.  In both lammps_command() and lammps_commands_list(),
+individual commands may or may not have a trailing newline.  The
+lammps_commands_string() function passes multiple commands
+concatenated into one long string, separated by newline characters.
+In both lammps_commands_list() and lammps_commands_string(), a single
+command can be spread across multiple lines, if the last printable
+character of all but the last line is "&", the same as if the lines
+appeared in an input script.
+
+The lammps_free() function is a clean-up function to free memory that
+the library allocated previously via other function calls.  See
+comments in src/library.cpp file for which other functions need this
+clean-up.
+
+Library.cpp also contains these functions for extracting information
+from LAMMPS and setting value within LAMMPS.  Again, see the
+documentation in the src/library.cpp file for details, including
+which quantities can be queried by name:
 
 void *lammps_extract_global(void *, char *)
 void *lammps_extract_atom(void *, char *)
 void *lammps_extract_compute(void *, char *, int, int)
 void *lammps_extract_fix(void *, char *, int, int, int, int)
-void *lammps_extract_variable(void *, char *, char *)
+void *lammps_extract_variable(void *, char *, char *) :pre
+
 int lammps_set_variable(void *, char *, char *)
+double lammps_get_thermo(void *, char *) :pre
+
 int lammps_get_natoms(void *)
-void lammps_get_coords(void *, double *)
-void lammps_put_coords(void *, double *) :pre
+void lammps_gather_atoms(void *, double *)
+void lammps_scatter_atoms(void *, double *) :pre
+void lammps_create_atoms(void *, int, tagint *, int *, double *, double *) :pre
 
-These can extract various global or per-atom quantities from LAMMPS as
-well as values calculated by a compute, fix, or variable.  The
-"set_variable" function can set an existing string-style variable to a
-new value, so that subsequent LAMMPS commands can access the variable.
-The "get" and "put" operations can retrieve and reset atom
-coordinates.  See the library.cpp file and its associated header file
-library.h for details.
+The extract functions return a pointer to various global or per-atom
+quantities stored in LAMMPS or to values calculated by a compute, fix,
+or variable.  The pointer returned by the extract_global() function
+can be used as a permanent reference to a value which may change.  For
+the other extract functions, the underlying storage may be reallocated
+as LAMMPS runs, so you need to re-call the function to assure a
+current pointer or returned value(s).
 
-The key idea of the library interface is that you can write any
-functions you wish to define how your code talks to LAMMPS and add
-them to src/library.cpp and src/library.h, as well as to the "Python
-interface"_Section_python.html.  The routines you add can access or
-change any LAMMPS data you wish.  The examples/COUPLE and python
-directories have example C++ and C and Python codes which show how a
-driver code can link to LAMMPS as a library, run LAMMPS on a subset of
-processors, grab data from LAMMPS, change it, and put it back into
-LAMMPS.
+The lammps_set_variable() function can set an existing string-style
+variable to a new string value, so that subsequent LAMMPS commands can
+access the variable.  The lammps_get_thermo() function returns the
+current value of a thermo keyword as a double.
+
+The lammps_get_natoms() function returns the total number of atoms in
+the system and can be used by the caller to allocate space for the
+lammps_gather_atoms() and lammps_scatter_atoms() functions.  The
+gather function collects atom info of the requested type (atom coords,
+types, forces, etc) from all procsesors, orders them by atom ID, and
+returns a full list to each calling processor.  The scatter function
+does the inverse.  It distributes the same kinds of values, 
+passed by the caller, to each atom owned by individual processors.
+
+The lammps_create_atoms() function takes a list of N atoms as input
+with atom types and coords (required), an optionally atom IDs and
+velocities.  It uses the coords of each atom to assign it as a new
+atom to the processor that owns it.  Additional properties for the new
+atoms can be assigned via the lammps_scatter_atoms() or
+lammps_extract_atom() functions.
+
+The examples/COUPLE and python directories have example C++ and C and
+Python codes which show how a driver code can link to LAMMPS as a
+library, run LAMMPS on a subset of processors, grab data from LAMMPS,
+change it, and put it back into LAMMPS.
+
+NOTE: You can write code for additional functions as needed to define
+how your code talks to LAMMPS and add them to src/library.cpp and
+src/library.h, as well as to the "Python
+interface"_Section_python.html.  The added functions can access or
+change any LAMMPS data you wish.
 
 :line
 
@@ -2092,11 +2151,11 @@ lattice      fcc 5.376 orient x 1 0 0 orient y 0 1 0 orient z 0 0 1
 region       box block 0 4 0 4 0 4
 create_box   1 box
 create_atoms 1 box
-mass	     1 39.948
+mass         1 39.948
 pair_style   lj/cut 13.0
 pair_coeff   * * 0.2381 3.405
 timestep     $\{dt\}
-thermo	     $d :pre
+thermo       $d :pre
 
 # equilibration and thermalization :pre
 
@@ -2123,14 +2182,14 @@ thermo_style custom step temp press v_pxy v_pxz v_pyz v_v11 v_v22 v_v33
 run          100000
 variable     v equal (v_v11+v_v22+v_v33)/3.0
 variable     ndens equal count(all)/vol
-print        "average viscosity: $v \[Pa.s/] @ $T K, $\{ndens\} /A^3" :pre
+print        "average viscosity: $v \[Pa.s\] @ $T K, $\{ndens\} /A^3" :pre
 
 The fifth method is related to the above Green-Kubo method,
 but uses the Einstein formulation, analogous to the Einstein
 mean-square-displacement formulation for self-diffusivity. The
 time-integrated momentum fluxes play the role of Cartesian
 coordinates, whose mean-square displacement increases linearly
-with time at sufficiently long times. 
+with time at sufficiently long times.
 
 :line
 
@@ -2510,8 +2569,8 @@ the electrostatic environment inducing polarizability.
 Technically, shells are attached to the cores by a spring force f =
 k*r where k is a parametrized spring constant and r is the distance
 between the core and the shell. The charges of the core and the shell
-add up to the ion charge, thus q(ion) = q(core) + q(shell). This 
-setup introduces the ion polarizability (alpha) given by 
+add up to the ion charge, thus q(ion) = q(core) + q(shell). This
+setup introduces the ion polarizability (alpha) given by
 alpha = q(shell)^2 / k. In a
 similar fashion the mass of the ion is distributed on the core and the
 shell with the core having the larger mass.
@@ -2526,7 +2585,7 @@ for NaCl, as found in examples/coreshell, has this format:
 432   atoms  # core and shell atoms
 216   bonds  # number of core/shell springs :pre
 
-4     atom types  # 2 cores and 2 shells for Na and Cl 
+4     atom types  # 2 cores and 2 shells for Na and Cl
 2     bond types :pre
 
 0.0 24.09597 xlo xhi
@@ -2545,19 +2604,19 @@ Atoms :pre
 1    1    2   1.5005    0.00000000   0.00000000   0.00000000 # core of core/shell pair 1
 2    1    4  -2.5005    0.00000000   0.00000000   0.00000000 # shell of core/shell pair 1
 3    2    1   1.5056    4.01599500   4.01599500   4.01599500 # core of core/shell pair 2
-4    2    3  -0.5056    4.01599500   4.01599500   4.01599500 # shell of core/shell pair 2 
+4    2    3  -0.5056    4.01599500   4.01599500   4.01599500 # shell of core/shell pair 2
 (...) :pre
 
 Bonds   # Bond topology for spring forces :pre
 
 1     2     1     2   # spring for core/shell pair 1
-2     2     3     4   # spring for core/shell pair 2 
+2     2     3     4   # spring for core/shell pair 2
 (...) :pre
 
 Non-Coulombic (e.g. Lennard-Jones) pairwise interactions are only
 defined between the shells.  Coulombic interactions are defined
 between all cores and shells.  If desired, additional bonds can be
-specified between cores.  
+specified between cores.
 
 The "special_bonds"_special_bonds.html command should be used to
 turn-off the Coulombic interaction within core/shell pairs, since that
@@ -2620,7 +2679,7 @@ Note that to perform thermostatting using this definition of
 temperature, the "fix modify temp"_fix_modify.html command should be
 used to assign the compute to the thermostat fix.  Likewise the
 "thermo_modify temp"_thermo_modify.html command can be used to make
-this temperature be output for the overall system. 
+this temperature be output for the overall system.
 
 For the NaCl example, this can be done as follows:
 
@@ -2632,13 +2691,13 @@ fix thermostatequ all nve                               # integrator as needed f
 fix_modify thermoberendsen temp CSequ
 thermo_modify temp CSequ                                # output of center-of-mass derived temperature :pre
 
-If "compute temp/cs"_compute_temp_cs.html is used, the decoupled 
-relative motion of the core and the shell should in theory be 
+If "compute temp/cs"_compute_temp_cs.html is used, the decoupled
+relative motion of the core and the shell should in theory be
 stable.  However numerical fluctuation can introduce a small
 momentum to the system, which is noticable over long trajectories.
-Therefore it is recomendable to use the "fix 
-momentum"_fix_momentum.html command in combination with "compute 
-temp/cs"_compute_temp_cs.html when equilibrating the system to 
+Therefore it is recomendable to use the "fix
+momentum"_fix_momentum.html command in combination with "compute
+temp/cs"_compute_temp_cs.html when equilibrating the system to
 prevent any drift.
 
 When intializing the velocities of a system with core/shell pairs, it
@@ -2661,17 +2720,17 @@ to the electrostatic environment.  This fast movement also limits the
 timestep size that can be used.
 
 The primary literature of the adiabatic core/shell model suggests that
-the fast relative motion of the core/shell pairs only allows negligible 
+the fast relative motion of the core/shell pairs only allows negligible
 energy transfer to the environment. Therefore it is not intended to
 decouple the core/shell degree of freedom from the physical system
 during production runs. In other words, the "compute
 temp/cs"_compute_temp_cs.html command should not be used during
-production runs and is only required during equilibration. This way one 
-is consistent with literature (based on the code packages DL_POLY or 
+production runs and is only required during equilibration. This way one
+is consistent with literature (based on the code packages DL_POLY or
 GULP for instance).
 
-The mentioned energy transfer will typically lead to a a small drift 
-in total energy over time.  This internal energy can be monitored 
+The mentioned energy transfer will typically lead to a small drift
+in total energy over time.  This internal energy can be monitored
 using the "compute chunk/atom"_compute_chunk_atom.html and "compute
 temp/chunk"_compute_temp_chunk.html commands.  The internal kinetic
 energies of each core/shell pair can then be summed using the sum()
@@ -2702,14 +2761,14 @@ The additional section in the date file would be formatted like this:
 
 CS-Info         # header of additional section :pre
 
-1   1           # column 1 = atom ID, column 2 = core/shell ID 
-2   1   
-3   2   
-4   2   
-5   3   
-6   3   
-7   4   
-8   4   
+1   1           # column 1 = atom ID, column 2 = core/shell ID
+2   1
+3   2
+4   2
+5   3
+6   3
+7   4
+8   4
 (...) :pre
 
 :line
@@ -2771,7 +2830,7 @@ temp/drude"_compute_temp_drude.html. This requires also to use the
 command {comm_modify vel yes}.
 
 Short-range damping of the induced dipole interactions can be achieved
-using Thole functions through the the "pair style
+using Thole functions through the "pair style
 thole"_pair_thole.html in "pair_style hybrid/overlay"_pair_hybrid.html
 with a Coulomb pair style. It may be useful to use {coul/long/cs} or
 similar from the CORESHELL package if the core and Drude particle come

doc/src/Section_intro.txt

@@ -181,7 +181,7 @@ Atom creation :h5
   displace atoms :ul
 
 Ensembles, constraints, and boundary conditions :h5
-("fix"_fix.html command) 
+("fix"_fix.html command)
 
   2d or 3d systems
   orthogonal or non-orthogonal (triclinic symmetry) simulation domains
@@ -199,7 +199,7 @@ Ensembles, constraints, and boundary conditions :h5
   variety of additional boundary conditions and constraints :ul
 
 Integrators :h5
-("run"_run.html, "run_style"_run_style.html, "minimize"_minimize.html commands) 
+("run"_run.html, "run_style"_run_style.html, "minimize"_minimize.html commands)
 
   velocity-Verlet integrator
   Brownian dynamics
@@ -213,7 +213,7 @@ Diagnostics :h5
   see the various flavors of the "fix"_fix.html and "compute"_compute.html commands :ul
 
 Output :h5
-("dump"_dump.html, "restart"_restart.html commands) 
+("dump"_dump.html, "restart"_restart.html commands)
 
   log file of thermodynamic info
   text dump files of atom coords, velocities, other per-atom quantities
@@ -366,11 +366,11 @@ complementary modeling tasks.
 "DL_POLY"_dlpoly
 "Tinker"_tinker :ul
 
-:link(charmm,http://www.scripps.edu/brooks)
-:link(amber,http://amber.scripps.edu)
+:link(charmm,http://www.charmm.org)
+:link(amber,http://ambermd.org)
 :link(namd,http://www.ks.uiuc.edu/Research/namd/)
 :link(nwchem,http://www.emsl.pnl.gov/docs/nwchem/nwchem.html)
-:link(dlpoly,http://www.cse.clrc.ac.uk/msi/software/DL_POLY)
+:link(dlpoly,http://www.ccp5.ac.uk/DL_POLY_CLASSIC)
 :link(tinker,http://dasher.wustl.edu/tinker)
 
 CHARMM, AMBER, NAMD, NWCHEM, and Tinker are designed primarily for

doc/src/Section_packages.txt

@@ -71,16 +71,16 @@ Package, Description, Author(s), Doc page, Example, Library
 "COMPRESS"_#COMPRESS, I/O compression, Axel Kohlmeyer (Temple U), "dump */gz"_dump.html, -, -
 "CORESHELL"_#CORESHELL, adiabatic core/shell model, Hendrik Heenen (Technical U of Munich), "Section 6.6.25"_Section_howto.html#howto_25, coreshell, -
 "DIPOLE"_#DIPOLE, point dipole particles, -, "pair_style dipole/cut"_pair_dipole.html, dipole, -
-"GPU"_#GPU, GPU-enabled styles, Mike Brown (ORNL), "Section accelerate"_accelerate_gpu.html, gpu, lib/gpu
+"GPU"_#GPU, GPU-enabled styles, Mike Brown (ORNL), "Section 5.3.1"_accelerate_gpu.html, gpu, lib/gpu
 "GRANULAR"_#GRANULAR, granular systems, -, "Section 6.6.6"_Section_howto.html#howto_6, pour, -
 "KIM"_#KIM, openKIM potentials, Smirichinski & Elliot & Tadmor (3), "pair_style kim"_pair_kim.html, kim, KIM
-"KOKKOS"_#KOKKOS, Kokkos-enabled styles, Trott & Moore (4), "Section 5"_accelerate_kokkos.html, kokkos, lib/kokkos
+"KOKKOS"_#KOKKOS, Kokkos-enabled styles, Trott & Moore (4), "Section 5.3.3"_accelerate_kokkos.html, kokkos, lib/kokkos
 "KSPACE"_#KSPACE, long-range Coulombic solvers, -, "kspace_style"_kspace_style.html, peptide, -
 "MANYBODY"_#MANYBODY, many-body potentials, -, "pair_style tersoff"_pair_tersoff.html, shear, -
 "MEAM"_#MEAM, modified EAM potential, Greg Wagner (Sandia), "pair_style meam"_pair_meam.html, meam, lib/meam
 "MC"_#MC, Monte Carlo options, -, "fix gcmc"_fix_gcmc.html, -, -
 "MOLECULE"_#MOLECULE, molecular system force fields, -, "Section 6.6.3"_Section_howto.html#howto_3, peptide, -
-"OPT"_#OPT, optimized pair styles, Fischer & Richie & Natoli (2), "Section accelerate"_accelerate_opt.html, -, -
+"OPT"_#OPT, optimized pair styles, Fischer & Richie & Natoli (2), "Section 5.3.5"_accelerate_opt.html, -, -
 "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
@@ -127,7 +127,6 @@ of the LAMMPS distribution.  See the lib/package/README file for info
 on how to build the library.  If it is not listed as lib/package, then
 it is a third-party library not included in the LAMMPS distribution.
 See details on all of this below for individual packages.
-p.s.: are we ever going to get commit messages from you? ;-)
 
 :line
 
@@ -150,7 +149,7 @@ make machine :pre
 
 Make.py -p ^asphere -a machine :pre
 
-Supporting info: "Section howto 6.14"_Section_howto.html#howto_14,
+Supporting info: "Section 6.14"_Section_howto.html#howto_14,
 "pair_style gayberne"_pair_gayberne.html, "pair_style
 resquared"_pair_resquared.html,
 "doc/PDF/pair_gayberne_extra.pdf"_PDF/pair_gayberne_extra.pdf,
@@ -183,7 +182,7 @@ Supporting info: "atom_style body"_atom_style.html, "body"_body.html,
 "pair_style body"_pair_body.html, examples/body
 
 :line
- 
+
 CLASS2 package :link(CLASS2),h5
 
 Contents: Bond, angle, dihedral, improper, and pair styles for the
@@ -207,9 +206,9 @@ Supporting info: "bond_style class2"_bond_class2.html, "angle_style
 class2"_angle_class2.html, "dihedral_style
 class2"_dihedral_class2.html, "improper_style
 class2"_improper_class2.html, "pair_style lj/class2"_pair_class2.html
- 
+
 :line
- 
+
 COLLOID package :link(COLLOID),h5
 
 Contents: Support for coarse-grained colloidal particles.  Wall fix
@@ -240,9 +239,9 @@ lubricate"_pair_lubricate.html, "pair_style
 lubricateU"_pair_lubricateU.html, examples/colloid, examples/srd
 
 :line
- 
+
 COMPRESS package :link(COMPRESS),h5
- 
+
 Contents: Support for compressed output of dump files via the zlib
 compression library, using dump styles with a "gz" in their style
 name.
@@ -272,16 +271,15 @@ atom/gz"_dump.html, "dump cfg/gz"_dump.html, "dump
 custom/gz"_dump.html, "dump xyz/gz"_dump.html
 
 :line
- 
+
 CORESHELL package :link(CORESHELL),h5
 
 Contents: Compute and pair styles that implement the adiabatic
 core/shell model for polarizability.  The compute temp/cs command
 measures the temperature of a system with core/shell particles.  The
 pair styles augment Born, Buckingham, and Lennard-Jones styles with
-core/shell capabilities.  See "Section howto
-6.26"_Section_howto.html#howto_26 for an overview of how to use the
-package.
+core/shell capabilities.  See "Section 6.26"_Section_howto.html#howto_26
+for an overview of how to use the package.
 
 To install via make or Make.py:
 
@@ -297,14 +295,14 @@ make machine :pre
 
 Make.py -p ^coreshell -a machine :pre
 
-Supporting info: "Section howto
-6.26"_Section_howto.html#howto_26, "compute temp/cs"_compute_temp_cs.html,
+Supporting info: "Section 6.26"_Section_howto.html#howto_26,
+"compute temp/cs"_compute_temp_cs.html,
 "pair_style born/coul/long/cs"_pair_cs.html, "pair_style
 buck/coul/long/cs"_pair_cs.html, pair_style
 lj/cut/coul/long/cs"_pair_lj.html, examples/coreshell
 
 :line
- 
+
 DIPOLE package :link(DIPOLE),h5
 
 Contents: An atom style and several pair styles to support point
@@ -328,14 +326,14 @@ Supporting info: "atom_style dipole"_atom_style.html, "pair_style
 lj/cut/dipole/cut"_pair_dipole.html, "pair_style
 lj/cut/dipole/long"_pair_dipole.html, "pair_style
 lj/long/dipole/long"_pair_dipole.html, examples/dipole
- 
+
 :line
- 
+
 GPU package :link(GPU),h5
 
 Contents: Dozens of pair styles and a version of the PPPM long-range
 Coulombic solver for NVIDIA GPUs.  All of them have a "gpu" in their
-style name.  "Section accelerate gpu"_accelerate_gpu.html gives
+style name.  "Section 5.3.1"_accelerate_gpu.html gives
 details of what hardware and Cuda software is required on your system,
 and how to build and use this package.  See the KOKKOS package, which
 also has GPU-enabled styles.
@@ -380,15 +378,16 @@ make machine :pre
 
 Make.py -p ^gpu -a machine :pre
 
-Supporting info: src/GPU/README, lib/gpu/README, "Section
-acclerate"_Section_accelerate.html, "Section accelerate
-gpu"_accelerate_gpu.html, Pair Styles section of "Section commands
-3.5"_Section_commands.html#cmd_5 for any pair style listed with a (g),
+Supporting info: src/GPU/README, lib/gpu/README,
+"Section 5.3"_Section_accelerate.html#acc_3,
+"Section 5.3.1"_accelerate_gpu.html,
+Pair Styles section of "Section 3.5"_Section_commands.html#cmd_5
+for any pair style listed with a (g),
 "kspace_style"_kspace_style.html, "package gpu"_package.html,
 examples/accelerate, bench/FERMI, bench/KEPLER
- 
+
 :line
- 
+
 GRANULAR package :link(GRANULAR),h5
 
 Contents: Fixes and pair styles that support models of finite-size
@@ -409,13 +408,13 @@ make machine :pre
 
 Make.py -p ^granular -a machine :pre
 
-Supporting info: "Section howto 6.6"_Section_howto.html#howto_6, "fix
+Supporting info: "Section 6.6"_Section_howto.html#howto_6, "fix
 pour"_fix_pour.html, "fix wall/gran"_fix_wall_gran.html, "pair_style
 gran/hooke"_pair_gran.html, "pair_style
 gran/hertz/history"_pair_gran.html, examples/pour, bench/in.chute
- 
+
 :line
- 
+
 KIM package :link(KIM),h5
 
 Contents: A pair style that interfaces to the Knowledge Base for
@@ -444,16 +443,16 @@ Make.py -p ^kim -a machine :pre
 
 Supporting info: src/KIM/README, lib/kim/README, "pair_style
 kim"_pair_kim.html, examples/kim
- 
+
 :line
- 
+
 KOKKOS package :link(KOKKOS),h5
 
 Contents: Dozens of atom, pair, bond, angle, dihedral, improper styles
 which run with the Kokkos library to provide optimization for
 multicore CPUs (via OpenMP), NVIDIA GPUs, or the Intel Xeon Phi (in
 native mode).  All of them have a "kk" in their style name.  "Section
-accelerate kokkos"_accelerate_kokkos.html gives details of what
+5.3.3"_accelerate_kokkos.html gives details of what
 hardware and software is required on your system, and how to build and
 use this package.  See the GPU, OPT, USER-INTEL, USER-OMP packages,
 which also provide optimizations for the same range of hardware.
@@ -473,9 +472,8 @@ the KOKKOS_ARCH setting in Makefile.kokkos_cuda), Or, as illustrated
 below, you can use the Make.py script with its "-kokkos" option to
 choose which hardware to build for.  Type "python src/Make.py -h
 -kokkos" to see the details.  If these methods do not work on your
-system, you will need to read the "Section accelerate
-kokkos"_accelerate_kokkos.html doc page for details of what
-Makefile.machine settings are needed.
+system, you will need to read the "Section 5.3.3"_accelerate_kokkos.html
+doc page for details of what Makefile.machine settings are needed.
 
 To install via make or Make.py for each of 3 hardware options:
 
@@ -495,15 +493,15 @@ make machine :pre
 
 Make.py -p ^kokkos -a machine :pre
 
-Supporting info: src/KOKKOS/README, lib/kokkos/README, "Section
-acclerate"_Section_accelerate.html, "Section accelerate
-kokkos"_accelerate_kokkos.html, Pair Styles section of "Section
-commands 3.5"_Section_commands.html#cmd_5 for any pair style listed
-with a (k), "package kokkos"_package.html,
+Supporting info: src/KOKKOS/README, lib/kokkos/README,
+"Section 5.3"_Section_accelerate.html#acc_3,
+"Section 5.3.3"_accelerate_kokkos.html,
+Pair Styles section of "Section 3.5"_Section_commands.html#cmd_5
+for any pair style listed with a (k), "package kokkos"_package.html,
 examples/accelerate, bench/FERMI, bench/KEPLER
 
 :line
- 
+
 KSPACE package :link(KSPACE),h5
 
 Contents: A variety of long-range Coulombic solvers, and pair styles
@@ -514,7 +512,7 @@ particle-mesh (PPPM), and multilevel summation method (MSM) solvers.
 Building with the KSPACE package requires a 1d FFT library be present
 on your system for use by the PPPM solvers.  This can be the KISS FFT
 library provided with LAMMPS, or 3rd party libraries like FFTW or a
-vendor-supplied FFT library.  See step 6 of "Section start
+vendor-supplied FFT library.  See step 6 of "Section
 2.2.2"_Section_start.html#start_2_2 of the manual for details of how
 to select different FFT options in your machine Makefile.  The Make.py
 tool has an "-fft" option which can insert these settings into your
@@ -536,15 +534,16 @@ make machine :pre
 Make.py -p ^kspace -a machine :pre
 
 Supporting info: "kspace_style"_kspace_style.html,
-"doc/PDF/kspace.pdf"_PDF/kspace.pdf, "Section howto
-6.7"_Section_howto.html#howto_7, "Section howto
-6.8"_Section_howto.html#howto_8, "Section howto
-6.9"_Section_howto.html#howto_9, "pair_style coul"_pair_coul.html,
-other pair style command doc pages which have "long" or "msm" in their
-style name, examples/peptide, bench/in.rhodo
+"doc/PDF/kspace.pdf"_PDF/kspace.pdf,
+"Section 6.7"_Section_howto.html#howto_7,
+"Section 6.8"_Section_howto.html#howto_8,
+"Section 6.9"_Section_howto.html#howto_9,
+"pair_style coul"_pair_coul.html, other pair style command doc pages
+which have "long" or "msm" in their style name,
+examples/peptide, bench/in.rhodo
 
 :line
- 
+
 MANYBODY package :link(MANYBODY),h5
 
 Contents: A variety of many-body and bond-order potentials.  These
@@ -566,14 +565,14 @@ make machine :pre
 
 Make.py -p ^manybody -a machine :pre
 
-Supporting info: 
- 
-Examples: Pair Styles section of "Section commands
+Supporting info:
+
+Examples: Pair Styles section of "Section
 3.5"_Section_commands.html#cmd_5, examples/comb, examples/eim,
 examples/nb3d, examples/vashishta
 
 :line
- 
+
 MC package :link(MC),h5
 
 Contents: Several fixes and a pair style that have Monte Carlo (MC) or
@@ -599,9 +598,9 @@ Supporting info: "fix atom/swap"_fix_atom_swap.html, "fix
 bond/break"_fix_bond_break.html, "fix
 bond/create"_fix_bond_create.html, "fix bond/swap"_fix_bond_swap.html,
 "fix gcmc"_fix_gcmc.html, "pair_style dsmc"_pair_dsmc.html
- 
+
 :line
- 
+
 MEAM package :link(MEAM),h5
 
 Contents: A pair style for the modified embedded atom (MEAM)
@@ -645,9 +644,9 @@ Make.py -p ^meam -a machine :pre
 
 Supporting info: lib/meam/README, "pair_style meam"_pair_meam.html,
 examples/meam
- 
+
 :line
- 
+
 MISC package :link(MISC),h5
 
 Contents: A variety of computes, fixes, and pair styles that are not
@@ -671,9 +670,9 @@ Make.py -p ^misc -a machine :pre
 Supporting info: "compute ti"_compute_ti.html, "fix
 evaporate"_fix_evaporate.html, "fix tmm"_fix_ttm.html, "fix
 viscosity"_fix_viscosity.html, examples/misc
- 
+
 :line
- 
+
 MOLECULE package :link(MOLECULE),h5
 
 Contents: A large number of atom, pair, bond, angle, dihedral,
@@ -700,12 +699,12 @@ Supporting info:"atom_style"_atom_style.html,
 "dihedral_style"_dihedral_style.html,
 "improper_style"_improper_style.html, "pair_style
 hbond/dreiding/lj"_pair_hbond_dreiding.html, "pair_style
-lj/charmm/coul/charmm"_pair_charmm.html, "Section howto
-6.3"_Section_howto.html#howto_3, examples/micelle, examples/peptide,
-bench/in.chain, bench/in.rhodo
+lj/charmm/coul/charmm"_pair_charmm.html,
+"Section 6.3"_Section_howto.html#howto_3,
+examples/micelle, examples/peptide, bench/in.chain, bench/in.rhodo
 
 :line
- 
+
 MPIIO package :link(MPIIO),h5
 
 Contents: Support for parallel output/input of dump and restart files
@@ -730,15 +729,15 @@ Make.py -p ^mpiio -a machine :pre
 
 Supporting info: "dump"_dump.html, "restart"_restart.html,
 "write_restart"_write_restart.html, "read_restart"_read_restart.html
- 
+
 :line
- 
+
 OPT package :link(OPT),h5
 
 Contents: A handful of pair styles with an "opt" in their style name
 which are optimized for improved CPU performance on single or multiple
 cores.  These include EAM, LJ, CHARMM, and Morse potentials.  "Section
-accelerate opt"_accelerate_opt.html gives details of how to build and
+5.3.5"_accelerate_opt.html gives details of how to build and
 use this package.  See the KOKKOS, USER-INTEL, and USER-OMP packages,
 which also have styles optimized for CPU performance.
 
@@ -763,13 +762,13 @@ make machine :pre
 
 Make.py -p ^opt -a machine :pre
 
-Supporting info: "Section acclerate"_Section_accelerate.html, "Section
-accelerate opt"_accelerate_opt.html, Pair Styles section of "Section
-commands 3.5"_Section_commands.html#cmd_5 for any pair style listed
-with an (o), examples/accelerate, bench/KEPLER
+Supporting info: "Section 5.3"_Section_accelerate.html#acc_3,
+"Section 5.3.5"_accelerate_opt.html, Pair Styles section of
+"Section 3.5"_Section_commands.html#cmd_5 for any pair style
+listed with an (t), examples/accelerate, bench/KEPLER
 
 :line
- 
+
 PERI package :link(PERI),h5
 
 Contents: Support for the Peridynamics method, a particle-based
@@ -797,9 +796,9 @@ Supporting info:
 "doc/PDF/PDLammps_VES.pdf"_PDF/PDLammps_VES.pdf, "atom_style
 peri"_atom_style.html, "compute damage/atom"_compute_damage_atom.html,
 "pair_style peri/pmb"_pair_peri.html, examples/peri
- 
+
 :line
- 
+
 POEMS package :link(POEMS),h5
 
 Contents: A fix that wraps the Parallelizable Open source Efficient
@@ -840,19 +839,19 @@ Supporting info: src/POEMS/README, lib/poems/README,
 "fix poems"_fix_poems.html, examples/rigid
 
 :line
- 
+
 PYTHON package :link(PYTHON),h5
 
 Contents: A "python"_python.html command which allow you to execute
 Python code from a LAMMPS input script.  The code can be in a separate
-file or embedded in the input script itself.  See "Section python
-11.2"_Section_python.html" for an overview of using Python from
+file or embedded in the input script itself.  See "Section
+11.2"_Section_python.html#py_2 for an overview of using Python from
 LAMMPS and for other ways to use LAMMPS and Python together.
 
 Building with the PYTHON package assumes you have a Python shared
 library available on your system, which needs to be a Python 2
-version, 2.6 or later.  Python 3 is not supported.  The build uses the
-contents of the lib/python/Makefile.lammps file to find all the Python
+version, 2.6 or later.  Python 3 is not yet supported.  The build uses
+the contents of the lib/python/Makefile.lammps file to find all the Python
 files required in the build/link process.  See the lib/python/README
 file if the settings in that file do not work on your system.  Note
 that the Make.py script has a "-python" option to allow an alternate
@@ -874,9 +873,9 @@ make machine :pre
 Make.py -p ^python -a machine :pre
 
 Supporting info: examples/python
- 
+
 :line
- 
+
 QEQ package :link(QEQ),h5
 
 Contents: Several fixes for performing charge equilibration (QEq) via
@@ -898,9 +897,9 @@ make machine :pre
 Make.py -p ^qeq -a machine :pre
 
 Supporting info: "fix qeq/*"_fix_qeq.html, examples/qeq
- 
+
 :line
- 
+
 REAX package :link(REAX),h5
 
 Contents: A pair style for the ReaxFF potential, a universal reactive
@@ -942,15 +941,15 @@ Make.py -p ^reax -a machine :pre
 
 Supporting info: lib/reax/README, "pair_style reax"_pair_reax.html,
 "fix reax/bonds"_fix_reax_bonds.html, examples/reax
- 
+
 :line
- 
+
 REPLICA package :link(REPLICA),h5
 
 Contents: A collection of multi-replica methods that are used by
 invoking multiple instances (replicas) of LAMMPS
 simulations. Communication between individual replicas is performed in
-different ways by the different methods.  See "Section howto
+different ways by the different methods.  See "Section
 6.5"_Section_howto.html#howto_5 for an overview of how to run
 multi-replica simulations in LAMMPS.  Multi-replica methods included
 in the package are nudged elastic band (NEB), parallel replica
@@ -973,13 +972,13 @@ make machine :pre
 
 Make.py -p ^replica -a machine :pre
 
-Supporting info: "Section howto 6.5"_Section_howto.html#howto_5,
+Supporting info: "Section 6.5"_Section_howto.html#howto_5,
 "neb"_neb.html, "prd"_prd.html, "tad"_tad.html, "temper"_temper.html,
 "run_style verlet/split"_run_style.html, examples/neb, examples/prd,
 examples/tad
 
 :line
- 
+
 RIGID package :link(RIGID),h5
 
 Contents: A collection of computes and fixes which enforce rigid
@@ -1006,7 +1005,7 @@ Supporting info: "compute erotate/rigid"_compute_erotate_rigid.html,
 rigid/*"_fix_rigid.html, examples/ASPHERE, examples/rigid
 
 :line
- 
+
 SHOCK package :link(SHOCK),h5
 
 Contents: A small number of fixes useful for running impact
@@ -1029,15 +1028,15 @@ Make.py -p ^shock -a machine :pre
 Supporting info: "fix append/atoms"_fix_append_atoms.html, "fix
 msst"_fix_msst.html, "fix nphug"_fix_nphug.html, "fix
 wall/piston"_fix_wall_piston.html, examples/hugoniostat, examples/msst
- 
+
 :line
- 
+
 SNAP package :link(SNAP),h5
 
 Contents: A pair style for the spectral neighbor analysis potential
 (SNAP), which is an empirical potential which can be quantum accurate
-when fit to an archive of DFT data.  Computes useful for analyzing 
-properties of the potential are also included. 
+when fit to an archive of DFT data.  Computes useful for analyzing
+properties of the potential are also included.
 
 To install via make or Make.py:
 
@@ -1056,9 +1055,9 @@ Make.py -p ^snap -a machine :pre
 Supporting info: "pair snap"_pair_snap.html, "compute
 sna/atom"_compute_sna_atom.html, "compute snad/atom"_compute_sna_atom.html,
 "compute snav/atom"_compute_sna_atom.html, examples/snap
- 
+
 :line
- 
+
 SRD package :link(SRD),h5
 
 Contents: Two fixes which implement the Stochastic Rotation Dynamics
@@ -1081,9 +1080,9 @@ Make.py -p ^srd -a machine :pre
 
 Supporting info: "fix srd"_fix_srd.html, "fix
 wall/srd"_fix_wall_srd.html, examples/srd, examples/ASPHERE
- 
+
 :line
- 
+
 VORONOI package :link(VORONOI),h5
 
 Contents: A "compute voronoi/atom"_compute_voronoi_atom.html command
@@ -1130,9 +1129,9 @@ Make.py -p ^voronoi -a machine :pre
 
 Supporting info: src/VORONOI/README, lib/voronoi/README, "compute
 voronoi/atom"_compute_voronoi_atom.html, examples/voronoi
- 
+
 :line
- 
+
 4.2 User packages :h4,link(pkg_2)
 
 The current list of user-contributed packages is as follows:
@@ -1148,13 +1147,14 @@ Package, Description, Author(s), Doc page, Example, Pic/movie, Library
 "USER-EFF"_#USER-EFF, electron force field, Andres Jaramillo-Botero (Caltech), "pair_style eff/cut"_pair_eff.html, USER/eff, "eff"_eff, -
 "USER-FEP"_#USER-FEP, free energy perturbation, Agilio Padua (U Blaise Pascal Clermont-Ferrand), "compute fep"_compute_fep.html, USER/fep, -, -
 "USER-H5MD"_#USER-H5MD, dump output via HDF5, Pierre de Buyl (KU Leuven), "dump h5md"_dump_h5md.html, -, -, lib/h5md
-"USER-INTEL"_#USER-INTEL, Vectorized CPU and Intel(R) coprocessor styles, W. Michael Brown (Intel), "Section accelerate"_accelerate_intel.html, examples/intel, -, -
+"USER-INTEL"_#USER-INTEL, Vectorized CPU and Intel(R) coprocessor styles, W. Michael Brown (Intel), "Section 5.3.2"_accelerate_intel.html, examples/intel, -, -
 "USER-LB"_#USER-LB, Lattice Boltzmann fluid, Colin Denniston (U Western Ontario), "fix lb/fluid"_fix_lb_fluid.html, USER/lb, -, -
 "USER-MGPT"_#USER-MGPT, fast MGPT multi-ion potentials, Tomas Oppelstrup & John Moriarty (LLNL), "pair_style mgpt"_pair_mgpt.html, USER/mgpt, -, -
 "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-OMP"_#USER-OMP, OpenMP threaded styles, Axel Kohlmeyer (Temple U), "Section accelerate"_accelerate_omp.html, -, -, -
+"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
 "USER-QTB"_#USER-QTB, quantum nuclear effects, Yuan Shen (Stanford), "fix qtb"_fix_qtb.html "fix qbmsst"_fix_qbmsst.html, qtb, -, -
@@ -1303,7 +1303,7 @@ fix.  The COLVARS library itself is written and maintained by Giacomo
 Fiorin (ICMS, Temple University, Philadelphia, PA, USA) and Jerome
 Henin (LISM, CNRS, Marseille, France).  Contact them directly if you
 have questions.
- 
+
 :line
 
 USER-DIFFRACTION package :link(USER-DIFFRACTION),h5
@@ -1353,12 +1353,12 @@ USER-DRUDE package :link(USER-DRUDE),h5
 
 Contents: This package contains methods for simulating polarizable
 systems using thermalized Drude oscillators.  It has computes, fixes,
-and pair styles for this purpose.  See "Section howto
+and pair styles for this purpose.  See "Section
 6.27"_Section_howto.html#howto_27 for an overview of how to use the
 package.  See src/USER-DRUDE/README for additional details.  There are
 auxiliary tools for using this package in tools/drude.
 
-Supporting info: "Section howto 6.27"_Section_howto.html#howto_27,
+Supporting info: "Section 6.27"_Section_howto.html#howto_27,
 src/USER-DRUDE/README, "fix drude"_fix_drude.html, "fix
 drude/transform/*"_fix_drude_transform.html, "compute
 temp/drude"_compute_temp_drude.html, "pair thole"_pair_thole.html,
@@ -1381,7 +1381,7 @@ in 2007.  See src/USER-EFF/README for more details.  There are
 auxiliary tools for using this package in tools/eff; see its README
 file.
 
-Supporting info: 
+Supporting info:
 
 Author: Andres Jaramillo-Botero at CalTech (ajaramil at
 wag.caltech.edu).  Contact him directly if you have questions.
@@ -1432,7 +1432,7 @@ USER-INTEL package :link(USER-INTEL),h5
 Contents: Dozens of pair, bond, angle, dihedral, and improper styles
 that are optimized for Intel CPUs and the Intel Xeon Phi (in offload
 mode).  All of them have an "intel" in their style name.  "Section
-accelerate intel"_accelerate_intel.html gives details of what hardware
+5.3.2"_accelerate_intel.html gives details of what hardware
 and compilers are required on your system, and how to build and use
 this package.  Also see src/USER-INTEL/README for more details. See
 the KOKKOS, OPT, and USER-OMP packages, which also have CPU and
@@ -1440,7 +1440,7 @@ Phi-enabled styles.
 
 Supporting info: examples/accelerate, src/USER-INTEL/TEST
 
-"Section 5"_Section_accelerate.html#acc_3
+"Section 5.3"_Section_accelerate.html#acc_3
 
 Author: Mike Brown at Intel (michael.w.brown at intel.com).  Contact
 him directly if you have questions.
@@ -1457,21 +1457,21 @@ LINKFLAGS: add -fopenmp :ul
 
 For Phi mode add the following in addition to the CPU mode flags:
 
-CCFLAGS: add -DLMP_INTEL_OFFLOAD and 
+CCFLAGS: add -DLMP_INTEL_OFFLOAD and
 LINKFLAGS: add -offload :ul
 
 And also add this to CCFLAGS:
 
 -offload-option,mic,compiler,"-fp-model fast=2 -mGLOB_default_function_attrs=\"gather_scatter_loop_unroll=4\"" :pre
 
-Examples: 
+Examples:
 
 :line
 
 USER-LB package :link(USER-LB),h5
 
-Supporting info: 
- 
+Supporting info:
+
 This package contains a LAMMPS implementation of a background
 Lattice-Boltzmann fluid, which can be used to model MD particles
 influenced by hydrodynamic forces.
@@ -1490,8 +1490,8 @@ Examples: examples/USER/lb
 
 USER-MGPT package :link(USER-MGPT),h5
 
-Supporting info: 
- 
+Supporting info:
+
 This package contains a fast implementation for LAMMPS of
 quantum-based MGPT multi-ion potentials.  The MGPT or model GPT method
 derives from first-principles DFT-based generalized pseudopotential
@@ -1522,8 +1522,8 @@ Examples: examples/USER/mgpt
 
 USER-MISC package :link(USER-MISC),h5
 
-Supporting info: 
- 
+Supporting info:
+
 The files in this package are a potpourri of (mostly) unrelated
 features contributed to LAMMPS by users.  Each feature is a single
 pair of files (*.cpp and *.h).
@@ -1532,7 +1532,7 @@ More information about each feature can be found by reading its doc
 page in the LAMMPS doc directory.  The doc page which lists all LAMMPS
 input script commands is as follows:
 
-"Section 3"_Section_commands.html#cmd_5
+"Section 3.5"_Section_commands.html#cmd_5
 
 User-contributed features are listed at the bottom of the fix,
 compute, pair, etc sections.
@@ -1549,8 +1549,8 @@ Examples: examples/USER/misc
 
 USER-MANIFOLD package :link(USER-MANIFOLD),h5
 
-Supporting info: 
- 
+Supporting info:
+
 This package contains a dump molfile command which uses molfile
 plugins that are bundled with the
 "VMD"_http://www.ks.uiuc.edu/Research/vmd molecular visualization and
@@ -1575,8 +1575,8 @@ Contact him directly if you have questions.
 
 USER-MOLFILE package :link(USER-MOLFILE),h5
 
-Supporting info: 
- 
+Supporting info:
+
 This package contains a dump molfile command which uses molfile
 plugins that are bundled with the
 "VMD"_http://www.ks.uiuc.edu/Research/vmd molecular visualization and
@@ -1599,17 +1599,40 @@ The person who created this package is Axel Kohlmeyer at Temple U
 
 :line
 
+USER-NC-DUMP package :link(USER-NC-DUMP),h5
+
+Contents: Dump styles for writing NetCDF format files.  NetCDF is a binary,
+portable, self-describing file format on top of HDF5. The file format
+contents follow the AMBER NetCDF trajectory conventions
+(http://ambermd.org/netcdf/nctraj.xhtml), but include extensions to this
+convention. This package implements a "dump nc"_dump_nc.html command
+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
+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
+
+The person who created these files is Lars Pastewka at
+Karlsruhe Institute of Technology (lars.pastewka at kit.edu).
+Contact him directly if you have questions.
+
+:line
+
 USER-OMP package :link(USER-OMP),h5
 
-Supporting info: 
- 
+Supporting info:
+
 This package provides OpenMP multi-threading support and
 other optimizations of various LAMMPS pair styles, dihedral
 styles, and fix styles.
- 
+
 See this section of the manual to get started:
 
-"Section 5"_Section_accelerate.html#acc_3
+"Section 5.3"_Section_accelerate.html#acc_3
 
 The person who created this package is Axel Kohlmeyer at Temple U
 (akohlmey at gmail.com).  Contact him directly if you have questions.
@@ -1644,8 +1667,8 @@ Examples: examples/USER/phonon
 
 USER-QMMM package :link(USER-QMMM),h5
 
-Supporting info: 
- 
+Supporting info:
+
 This package provides a fix qmmm command which allows LAMMPS to be
 used in a QM/MM simulation, currently only in combination with pw.x
 code from the "Quantum ESPRESSO"_espresso package.
@@ -1668,11 +1691,11 @@ The person who created this package is Axel Kohlmeyer at Temple U
 (akohlmey at gmail.com).  Contact him directly if you have questions.
 
 :line
- 
+
 USER-QTB package :link(USER-QTB),h5
 
-Supporting info: 
- 
+Supporting info:
+
 This package provides a self-consistent quantum treatment of the
 vibrational modes in a classical molecular dynamics simulation.  By
 coupling the MD simulation to a colored thermostat, it introduces zero
@@ -1702,16 +1725,16 @@ Examples: examples/USER/qtb
 
 USER-QUIP package :link(USER-QUIP),h5
 
-Supporting info: 
- 
+Supporting info:
+
 Examples: examples/USER/quip
 
 :line
 
 USER-REAXC package :link(USER-REAXC),h5
 
-Supporting info: 
- 
+Supporting info:
+
 This package contains a implementation for LAMMPS of the ReaxFF force
 field.  ReaxFF uses distance-dependent bond-order functions to
 represent the contributions of chemical bonding to the potential
@@ -1749,24 +1772,24 @@ Examples: examples/reax
 
 USER-SMD package :link(USER-SMD),h5
 
-Supporting info: 
- 
+Supporting info:
+
 This package implements smoothed Mach dynamics (SMD) in
 LAMMPS.  Currently, the package has the following features:
 
 * Does liquids via traditional Smooth Particle Hydrodynamics (SPH)
 
-* Also solves solids mechanics problems via a state of the art 
+* Also solves solids mechanics problems via a state of the art
   stabilized meshless method with hourglass control.
 
-* Can specify hydrostatic interactions independently from material 
+* Can specify hydrostatic interactions independently from material
   strength models, i.e. pressure and deviatoric stresses are separated.
 
-* Many material models available (Johnson-Cook, plasticity with 
-  hardening, Mie-Grueneisen, Polynomial EOS).  Easy to add new 
+* Many material models available (Johnson-Cook, plasticity with
+  hardening, Mie-Grueneisen, Polynomial EOS).  Easy to add new
   material models.
 
-* Rigid boundary conditions (walls) can be loaded as surface geometries 
+* Rigid boundary conditions (walls) can be loaded as surface geometries
   from *.STL files.
 
 See the file doc/PDF/SMD_LAMMPS_userguide.pdf to get started.
@@ -1784,8 +1807,8 @@ Examples: examples/USER/smd
 
 USER-SMTBQ package :link(USER-SMTBQ),h5
 
-Supporting info: 
- 
+Supporting info:
+
 This package implements the Second Moment Tight Binding - QEq (SMTB-Q)
 potential for the description of ionocovalent bonds in oxides.
 
@@ -1807,22 +1830,22 @@ Examples: examples/USER/smtbq
 
 USER-SPH package :link(USER-SPH),h5
 
-Supporting info: 
+Supporting info:
 
 This package implements smoothed particle hydrodynamics (SPH) in
 LAMMPS.  Currently, the package has the following features:
 
-* Tait, ideal gas, Lennard-Jones equation of states, full support for 
+* Tait, ideal gas, Lennard-Jones equation of states, full support for
   complete (i.e. internal-energy dependent) equations of state
 
 * Plain or Monaghans XSPH integration of the equations of motion
 
 * Density continuity or density summation to propagate the density field
 
-* Commands to set internal energy and density of particles from the 
+* Commands to set internal energy and density of particles from the
   input script
 
-* Output commands to access internal energy and density for dumping and 
+* Output commands to access internal energy and density for dumping and
   thermo output
 
 See the file doc/PDF/SPH_LAMMPS_userguide.pdf to get started.
@@ -1840,7 +1863,7 @@ Examples: examples/USER/sph
 
 USER-TALLY package :link(USER-TALLY),h5
 
-Supporting info: 
+Supporting info:
 
 Examples: examples/USER/tally
 

doc/src/Section_perf.txt

@@ -51,7 +51,7 @@ of these 5 problems on 1 or 4 cores of Linux desktop.  The bench/FERMI
 and bench/KEPLER dirs have input files and scripts and instructions
 for running the same (or similar) problems using OpenMP or GPU or Xeon
 Phi acceleration options.  See the README files in those dirs and the
-"Section accelerate"_Section_accelerate.html doc pages for
+"Section 5.3"_Section_accelerate.html#acc_3 doc pages for
 instructions on how to build LAMMPS and run on that kind of hardware.
 
 The bench/POTENTIALS directory has input files which correspond to the

doc/src/Section_python.txt

@@ -8,28 +8,36 @@
 
 11. Python interface to LAMMPS :h3
 
-LAMMPS can work together with Python in two ways.  First, Python can
+LAMMPS can work together with Python in three ways.  First, Python can
 wrap LAMMPS through the "LAMMPS library
 interface"_Section_howto.html#howto_19, so that a Python script can
 create one or more instances of LAMMPS and launch one or more
 simulations.  In Python lingo, this is "extending" Python with LAMMPS.
 
-Second, LAMMPS can use the Python interpreter, so that a LAMMPS input
+Second, the low-level Python interface can be used indirectly through the
+PyLammps and IPyLammps wrapper classes in Python. These wrappers try to
+simplify the usage of LAMMPS in Python by providing an object-based interface
+to common LAMMPS functionality. It also reduces the amount of code necessary to
+parameterize LAMMPS scripts through Python and makes variables and computes
+directly accessible. See "PyLammps interface"_#py_9 for more details.
+
+Third, LAMMPS can use the Python interpreter, so that a LAMMPS input
 script can invoke Python code, and pass information back-and-forth
 between the input script and Python functions you write.  The Python
 code can also callback to LAMMPS to query or change its attributes.
 In Python lingo, this is "embedding" Python in LAMMPS.
 
-This section describes how to do both.
+This section describes how to use these three approaches.
 
 11.1 "Overview of running LAMMPS from Python"_#py_1
-11.2 "Overview of using Python from a LAMMPS script"_#py_2 
+11.2 "Overview of using Python from a LAMMPS script"_#py_2
 11.3 "Building LAMMPS as a shared library"_#py_3
 11.4 "Installing the Python wrapper into Python"_#py_4
 11.5 "Extending Python with MPI to run in parallel"_#py_5
 11.6 "Testing the Python-LAMMPS interface"_#py_6
 11.7 "Using LAMMPS from Python"_#py_7
-11.8 "Example Python scripts that use LAMMPS"_#py_8 :ul
+11.8 "Example Python scripts that use LAMMPS"_#py_8
+11.9 "PyLammps interface"_#py_9 :ul
 
 If you are not familiar with it, "Python"_http://www.python.org is a
 powerful scripting and programming language which can essentially do
@@ -503,7 +511,7 @@ one of several ways:
 The last command requires that the first line of the script be
 something like this:
 
-#!/usr/local/bin/python 
+#!/usr/local/bin/python
 #!/usr/local/bin/python -i :pre
 
 where the path points to where you have Python installed, and that you
@@ -534,10 +542,11 @@ from lammps import lammps :pre
 These are the methods defined by the lammps module.  If you look at
 the files src/library.cpp and src/library.h you will see that they
 correspond one-to-one with calls you can make to the LAMMPS library
-from a C++ or C or Fortran program.
+from a C++ or C or Fortran program, and which are described in
+"Section 6.19"_Section_howto.html#howto_19 of the manual.
 
 lmp = lammps()           # create a LAMMPS object using the default liblammps.so library
-                         4 optional args are allowed: name, cmdargs, ptr, comm
+                         # 4 optional args are allowed: name, cmdargs, ptr, comm
 lmp = lammps(ptr=lmpptr) # use lmpptr as previously created LAMMPS object
 lmp = lammps(comm=split) # create a LAMMPS object with a custom communicator, requires mpi4py 2.0.0 or later
 lmp = lammps(name="g++")   # create a LAMMPS object using the liblammps_g++.so library
@@ -549,37 +558,41 @@ version = lmp.version()  # return the numerical version id, e.g. LAMMPS 2 Sep 20
 
 lmp.file(file)           # run an entire input script, file = "in.lj"
 lmp.command(cmd)         # invoke a single LAMMPS command, cmd = "run 100" :pre
+lmp.commands_list(cmdlist)     # invoke commands in cmdlist = ["run 10", "run 20"]
+lmp.commands_string(multicmd)  # invoke commands in multicmd = "run 10\nrun 20"
 
 xlo = lmp.extract_global(name,type)  # extract a global quantity
                                      # name = "boxxlo", "nlocal", etc
-				     # type = 0 = int
-				     #        1 = double :pre
+                                     # type = 0 = int
+                                     #        1 = double :pre
 
 coords = lmp.extract_atom(name,type)      # extract a per-atom quantity
                                           # name = "x", "type", etc
-				          # type = 0 = vector of ints
-				          #        1 = array of ints
-				          #        2 = vector of doubles
-				          #        3 = array of doubles :pre
+                                          # type = 0 = vector of ints
+                                          #        1 = array of ints
+                                          #        2 = vector of doubles
+                                          #        3 = array of doubles :pre
 
 eng = lmp.extract_compute(id,style,type)  # extract value(s) from a compute
 v3 = lmp.extract_fix(id,style,type,i,j)   # extract value(s) from a fix
                                           # id = ID of compute or fix
-					  # style = 0 = global data
-					  #	    1 = per-atom data
-					  #         2 = local data
-					  # type = 0 = scalar
-					  #	   1 = vector
-					  #        2 = array
-					  # i,j = indices of value in global vector or array :pre
+                                          # style = 0 = global data
+                                          #         1 = per-atom data
+                                          #         2 = local data
+                                          # type = 0 = scalar
+                                          #        1 = vector
+                                          #        2 = array
+                                          # i,j = indices of value in global vector or array :pre
 
 var = lmp.extract_variable(name,group,flag)  # extract value(s) from a variable
-	                                     # name = name of variable
-					     # group = group ID (ignored for equal-style variables)
-					     # flag = 0 = equal-style variable
-					     #        1 = atom-style variable :pre
+                                             # name = name of variable
+                                             # group = group ID (ignored for equal-style variables)
+                                             # flag = 0 = equal-style variable
+                                             #        1 = atom-style variable :pre
 
 flag = lmp.set_variable(name,value)       # set existing named string-style variable to value, flag = 0 if successful
+value = lmp.get_thermo(name)              # return current value of a thermo keyword
+
 natoms = lmp.get_natoms()                 # total # of atoms as int
 data = lmp.gather_atoms(name,type,count)  # return atom attribute of all atoms gathered into data, ordered by atom ID
                                           # name = "x", "charge", "type", etc
@@ -599,9 +612,10 @@ create an instance of LAMMPS, wrapped in a Python class by the lammps
 Python module, and return an instance of the Python class as lmp.  It
 is used to make all subequent calls to the LAMMPS library.
 
-Additional arguments can be used to tell Python the name of the shared
-library to load or to pass arguments to the LAMMPS instance, the same
-as if LAMMPS were launched from a command-line prompt.
+Additional arguments to lammps() can be used to tell Python the name
+of the shared library to load or to pass arguments to the LAMMPS
+instance, the same as if LAMMPS were launched from a command-line
+prompt.
 
 If the ptr argument is set like this:
 
@@ -626,8 +640,9 @@ lmp2 = lammps()
 lmp1.file("in.file1")
 lmp2.file("in.file2") :pre
 
-The file() and command() methods allow an input script or single
-commands to be invoked.
+The file(), command(), commands_list(), commands_string() methods
+allow an input script, a single command, or multiple commands to be
+invoked.
 
 The extract_global(), extract_atom(), extract_compute(),
 extract_fix(), and extract_variable() methods return values or
@@ -724,7 +739,7 @@ lmp.scatter_coords("x",1,3,x) :pre
 Alternatively, you can just change values in the vector returned by
 gather_atoms("x",1,3), since it is a ctypes vector of doubles.
 
-:line 
+:line
 
 As noted above, these Python class methods correspond one-to-one with
 the functions in the LAMMPS library interface in src/library.cpp and
@@ -767,7 +782,7 @@ vizplotgui_tool.py, combination of viz_tool.py and plot.py and gui.py :tb(c=2)
 
 For the viz_tool.py and vizplotgui_tool.py commands, replace "tool"
 with "gl" or "atomeye" or "pymol" or "vmd", depending on what
-visualization package you have installed. 
+visualization package you have installed.
 
 Note that for GL, you need to be able to run the Pizza.py GL tool,
 which is included in the pizza sub-directory.  See the "Pizza.py doc
@@ -817,3 +832,7 @@ different visualization package options.  Click to see larger images:
 :image(JPG/screenshot_atomeye_small.jpg,JPG/screenshot_atomeye.jpg)
 :image(JPG/screenshot_pymol_small.jpg,JPG/screenshot_pymol.jpg)
 :image(JPG/screenshot_vmd_small.jpg,JPG/screenshot_vmd.jpg)
+
+11.9 PyLammps interface :link(py_9),h4
+
+Please see the "PyLammps Tutorial"_tutorial_pylammps.html.

doc/src/Section_start.txt

@@ -21,7 +21,6 @@ experienced users.
 2.8 "Screen output"_#start_8
 2.9 "Tips for users of previous versions"_#start_9 :all(b)
 
-:line
 :line
 
 2.1 What's in the LAMMPS distribution :h4,link(start_1)
@@ -34,7 +33,7 @@ tar -xzvf lammps*.tar.gz :pre
 
 This will create a LAMMPS directory containing two files and several
 sub-directories:
-    
+
 README: text file
 LICENSE: the GNU General Public License (GPL)
 bench: benchmark problems
@@ -70,12 +69,12 @@ launch a LAMMPS Windows executable on a Windows box.
 
 This section has the following sub-sections:
 
-"Read this first"_#start_2_1
-"Steps to build a LAMMPS executable"_#start_2_2
-"Common errors that can occur when making LAMMPS"_#start_2_3
-"Additional build tips"_#start_2_4
-"Building for a Mac"_#start_2_5
-"Building for Windows"_#start_2_6 :ul
+2.2.1 "Read this first"_#start_2_1
+2.2.1 "Steps to build a LAMMPS executable"_#start_2_2
+2.2.3 "Common errors that can occur when making LAMMPS"_#start_2_3
+2.2.4 "Additional build tips"_#start_2_4
+2.2.5 "Building for a Mac"_#start_2_5
+2.2.6 "Building for Windows"_#start_2_6 :all(b)
 
 :line
 
@@ -559,8 +558,7 @@ Typing "make clean-all" or "make clean-machine" will delete *.o object
 files created when LAMMPS is built, for either all builds or for a
 particular machine.
 
- Changing the LAMMPS size limits via -DLAMMPS_SMALLBIG or
--DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL :h6
+Changing the LAMMPS size limits via -DLAMMPS_SMALLBIG or -DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL :h6
 
 As explained above, any of these 3 settings can be specified on the
 LMP_INC line in your low-level src/MAKE/Makefile.foo.
@@ -602,17 +600,17 @@ LAMMPS will generate a run-time error.  As far as we know, the
 settings defined in src/lmptype.h are portable and work on every
 current system.
 
-In all cases, the size of problem that can be run on a per-processor  
-basis is limited by 4-byte integer storage to 2^31 atoms per processor  
-(about 2 billion). This should not normally be a limitation since such  
-a problem would have a huge per-processor memory footprint due to  
+In all cases, the size of problem that can be run on a per-processor
+basis is limited by 4-byte integer storage to 2^31 atoms per processor
+(about 2 billion). This should not normally be a limitation since such
+a problem would have a huge per-processor memory footprint due to
 neighbor lists and would run very slowly in terms of CPU secs/timestep.
 
 :line
 
 Building for a Mac :h5,link(start_2_5)
 
-OS X is BSD Unix, so it should just work.  See the
+OS X is a derivative of BSD Unix, so it should just work.  See the
 src/MAKE/MACHINES/Makefile.mac and Makefile.mac_mpi files.
 
 :line
@@ -637,9 +635,9 @@ happy to distribute contributed instructions and modifications, but
 we cannot provide support for those.
 
 With the so-called "Anniversary Update" to Windows 10, there is a
-Ubuntu subsystem available for Windows, that can be installed and
-then it can be used to compile/install LAMMPS as if you are running
-on a Ubuntu Linux system.
+Ubuntu Linux subsystem available for Windows, that can be installed
+and then used to compile/install LAMMPS as if you are running on a
+Ubuntu Linux system instead of Windows.
 
 As an alternative, you can download "daily builds" (and some older
 versions) of the installer packages from
@@ -654,10 +652,10 @@ many examples, but no source code.
 
 This section has the following sub-sections:
 
-"Package basics"_#start_3_1
-"Including/excluding packages"_#start_3_2
-"Packages that require extra libraries"_#start_3_3
-"Packages that require Makefile.machine settings"_#start_3_4 :ul
+2.3.1 "Package basics"_#start_3_1
+2.3.2 "Including/excluding packages"_#start_3_2
+2.3.3 "Packages that require extra libraries"_#start_3_3
+2.3.4 "Packages that require Makefile.machine settings"_#start_3_4 :all(b)
 
 Note that the following "Section 2.4"_#start_4 describes the Make.py
 tool which can be used to install/un-install packages and build the
@@ -673,7 +671,7 @@ are always included, plus optional packages.  Packages are groups of
 files that enable a specific set of features.  For example, force
 fields for molecular systems or granular systems are in packages.
 
-"Section packages"_Section_packages.html in the manual has details
+"Section 4"_Section_packages.html in the manual has details
 about all the packages, including specific instructions for building
 LAMMPS with each package, which are covered in a more general manner
 below.
@@ -708,7 +706,7 @@ future changes to LAMMPS.
 User packages, such as user-atc or user-omp, have been contributed by
 users, and always begin with the user prefix.  If they are a single
 command (single file), they are typically in the user-misc package.
-Otherwise, they are a a set of files grouped together which add a
+Otherwise, they are a set of files grouped together which add a
 specific functionality to the code.
 
 User packages don't necessarily meet the requirements of the standard
@@ -727,15 +725,15 @@ before building LAMMPS.  From the src directory, this is typically as
 simple as:
 
 make yes-colloid
-make g++ :pre
+make mpi :pre
 
 or
 
 make no-manybody
-make g++ :pre
+make mpi :pre
 
 NOTE: You should NOT include/exclude packages and build LAMMPS in a
-single make command using multiple targets, e.g. make yes-colloid g++.
+single make command using multiple targets, e.g. make yes-colloid mpi.
 This is because the make procedure creates a list of source files that
 will be out-of-date for the build if the package configuration changes
 within the same command.
@@ -826,7 +824,7 @@ where to find them.
 For libraries with provided code, the sub-directory README file
 (e.g. lib/atc/README) has instructions on how to build that library.
 This information is also summarized in "Section
-packages"_Section_packages.html.  Typically this is done by typing
+4"_Section_packages.html.  Typically this is done by typing
 something like:
 
 make -f Makefile.g++ :pre
@@ -843,7 +841,7 @@ libpackage.a
 Makefile.lammps :pre
 
 The Makefile.lammps file will typically be a copy of one of the
-Makefile.lammps.* files in the library directory.  
+Makefile.lammps.* files in the library directory.
 
 Note that you must insure that the settings in Makefile.lammps are
 appropriate for your system.  If they are not, the LAMMPS build may
@@ -885,17 +883,17 @@ A few packages require specific settings in Makefile.machine, to
 either build or use the package effectively.  These are the
 USER-INTEL, KOKKOS, USER-OMP, and OPT packages, used for accelerating
 code performance on CPUs or other hardware, as discussed in "Section
-acclerate"_Section_accelerate.html. 
+5.3"_Section_accelerate.html#acc_3.
 
 A summary of what Makefile.machine changes are needed for each of
-these packages is given in "Section packages"_Section_packages.html.
+these packages is given in "Section 4"_Section_packages.html.
 The details are given on the doc pages that describe each of these
 accelerator packages in detail:
 
-"USER-INTEL package"_accelerate_intel.html
-"KOKKOS package"_accelerate_kokkos.html
-"USER-OMP package"_accelerate_omp.html
-"OPT package"_accelerate_opt.html :ul
+5.3.1 "USER-INTEL package"_accelerate_intel.html
+5.3.3 "KOKKOS package"_accelerate_kokkos.html
+5.3.4 "USER-OMP package"_accelerate_omp.html
+5.3.5 "OPT package"_accelerate_opt.html :all(b)
 
 You can also look at the following machine Makefiles in
 src/MAKE/OPTIONS, which include the changes.  Note that the USER-INTEL
@@ -1201,7 +1199,7 @@ installer package from "here"_http://rpm.lammps.org/windows.html
 
 For running the non-MPI executable, follow these steps:
 
-Get a command prompt by going to Start->Run... , 
+Get a command prompt by going to Start->Run... ,
 then typing "cmd". :ulb,l
 
 Move to the directory where you have your input, e.g. a copy of
@@ -1211,7 +1209,7 @@ At the command prompt, type "lmp_serial -in in.lj", replacing [in.lj]
 with the name of your LAMMPS input script. :l
 :ule
 
-For the MPI version, which allows you to run LAMMPS under Windows on 
+For the MPI version, which allows you to run LAMMPS under Windows on
 multiple processors, follow these steps:
 
 Download and install
@@ -1226,7 +1224,7 @@ For this you need to start a Command Prompt in {Administrator Mode}
 installation directory, then into the subdirectory [bin] and execute
 [smpd.exe -install]. Exit the command window.
 
-Get a new, regular command prompt by going to Start->Run... , 
+Get a new, regular command prompt by going to Start->Run... ,
 then typing "cmd". :l
 
 Move to the directory where you have your input file
@@ -1367,7 +1365,7 @@ Note that the keywords do not use a leading minus sign.  I.e. the
 keyword is "t", not "-t".  Also note that each of the keywords has a
 default setting.  Example of when to use these options and what
 settings to use on different platforms is given in "Section
-5.8"_Section_accelerate.html#acc_3.
+5.3"_Section_accelerate.html#acc_3.
 
 d or device
 g or gpus
@@ -1490,7 +1488,7 @@ of the manual.  World- and universe-style "variables"_variable.html
 are useful in this context.
 
 -plog file :pre
- 
+
 Specify the base name for the partition log files, so partition N
 writes log information to file.N. If file is none, then no partition
 log files are created.  This overrides the filename specified in the
@@ -1501,7 +1499,7 @@ replica_files/log.lammps) If this option is not used the log file for
 partition N is log.lammps.N or whatever is specified by the -log
 command-line option.
 
--pscreen file :pre 
+-pscreen file :pre
 
 Specify the base name for the partition screen file, so partition N
 writes screen information to file.N. If file is none, then no
@@ -1513,7 +1511,7 @@ sub-directory (-pscreen replica_files/screen).  If this option is not
 used the screen file for partition N is screen.N or whatever is
 specified by the -screen command-line option.
 
--restart restartfile {remap} datafile keyword value ... :pre 
+-restart restartfile {remap} datafile keyword value ... :pre
 
 Convert the restart file into a data file and immediately exit.  This
 is the same operation as if the following 2-line input script were
@@ -1574,7 +1572,7 @@ to
 
 so that the processors in each partition will be
 
-0 1 2 4 5 6 8 9 10 
+0 1 2 4 5 6 8 9 10
 3 7 11 :pre
 
 See the "processors" command for how to insure processors from each
@@ -1603,9 +1601,9 @@ implementations, either by environment variables that specify how to
 order physical processors, or by config files that specify what
 physical processors to assign to each MPI rank.  The -reorder switch
 simply gives you a portable way to do this without relying on MPI
-itself.  See the "processors out"_processors command for how to output
-info on the final assignment of physical processors to the LAMMPS
-simulation domain.
+itself.  See the "processors out"_processors.html command for how
+to output info on the final assignment of physical processors to
+the LAMMPS simulation domain.
 
 -screen file :pre
 
@@ -1665,12 +1663,12 @@ invokes the default USER-INTEL settings, as if the command "package
 intel 1" were used at the top of your input script.  These settings
 can be changed by using the "-package intel" command-line switch or
 the "package intel"_package.html command in your script. If the
-USER-OMP package is also installed, the hybrid style with "intel omp" 
-arguments can be used to make the omp suffix a second choice, if a 
-requested style is not available in the USER-INTEL package.  It will 
-also invoke the default USER-OMP settings, as if the command "package 
-omp 0" were used at the top of your input script.  These settings can 
-be changed by using the "-package omp" command-line switch or the 
+USER-OMP package is also installed, the hybrid style with "intel omp"
+arguments can be used to make the omp suffix a second choice, if a
+requested style is not available in the USER-INTEL package.  It will
+also invoke the default USER-OMP settings, as if the command "package
+omp 0" were used at the top of your input script.  These settings can
+be changed by using the "-package omp" command-line switch or the
 "package omp"_package.html command in your script.
 
 For the KOKKOS package, using this command-line switch also invokes
@@ -1835,7 +1833,7 @@ e.g.
 
 Minimization stats:
   Stopping criterion = linesearch alpha is zero
-  Energy initial, next-to-last, final = 
+  Energy initial, next-to-last, final =
          -6372.3765206     -8328.46998942     -8328.46998942
   Force two-norm initial, final = 1059.36 5.36874
   Force max component initial, final = 58.6026 1.46872

doc/src/Section_tools.txt

@@ -104,12 +104,13 @@ since binary files are not compatible across all platforms.
 ch2lmp tool :h4,link(charmm)
 
 The ch2lmp sub-directory contains tools for converting files
-back-and-forth between the CHARMM MD code and LAMMPS. 
+back-and-forth between the CHARMM MD code and LAMMPS.
 
 They are intended to make it easy to use CHARMM as a builder and as a
-post-processor for LAMMPS. Using charmm2lammps.pl, you can convert an
-ensemble built in CHARMM into its LAMMPS equivalent.  Using
-lammps2pdb.pl you can convert LAMMPS atom dumps into pdb files.
+post-processor for LAMMPS. Using charmm2lammps.pl, you can convert a
+PDB file with associated CHARMM info, including CHARMM force field
+data, into its LAMMPS equivalent.  Using lammps2pdb.pl you can convert
+LAMMPS atom dumps into PDB files.
 
 See the README file in the ch2lmp sub-directory for more information.
 

doc/src/accelerate_intel.txt

@@ -29,80 +29,80 @@ 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, gayberne,
 charmm/coul/long, lj/cut, lj/cut/coul/long, sw, tersoff :l
 K-Space Styles: pppm :l
 :ule
 
 [Speed-ups to expect:]
 
-The speedups will depend on your simulation, the hardware, which 
-styles are used, the number of atoms, and the floating-point 
-precision mode. Performance improvements are shown compared to 
-LAMMPS {without using other acceleration packages} as these are 
-under active development (and subject to performance changes). The 
+The speedups will depend on your simulation, the hardware, which
+styles are used, the number of atoms, and the floating-point
+precision mode. Performance improvements are shown compared to
+LAMMPS {without using other acceleration packages} as these are
+under active development (and subject to performance changes). The
 measurements were performed using the input files available in
-the src/USER-INTEL/TEST directory. These are scalable in size; the 
-results given are with 512K particles (524K for Liquid Crystal). 
+the src/USER-INTEL/TEST directory. These are scalable in size; the
+results given are with 512K particles (524K for Liquid Crystal).
 Most of the simulations are standard LAMMPS benchmarks (indicated
-by the filename extension in parenthesis) with modifications to the 
-run length and to add a warmup run (for use with offload 
-benchmarks). 
+by the filename extension in parenthesis) with modifications to the
+run length and to add a warmup run (for use with offload
+benchmarks).
 
 :c,image(JPG/user_intel.png)
 
-Results are speedups obtained on Intel Xeon E5-2697v4 processors 
-(code-named Broadwell) and Intel Xeon Phi 7250 processors 
+Results are speedups obtained on Intel Xeon E5-2697v4 processors
+(code-named Broadwell) and Intel Xeon Phi 7250 processors
 (code-named Knights Landing) with "18 Jun 2016" LAMMPS built with
-Intel Parallel Studio 2016 update 3. Results are with 1 MPI task 
-per physical core. See {src/USER-INTEL/TEST/README} for the raw 
+Intel Parallel Studio 2016 update 3. Results are with 1 MPI task
+per physical core. See {src/USER-INTEL/TEST/README} for the raw
 simulation rates and instructions to reproduce.
 
 :line
 
 [Quick Start for Experienced Users:]
 
-LAMMPS should be built with the USER-INTEL package installed. 
+LAMMPS should be built with the USER-INTEL package installed.
 Simulations should be run with 1 MPI task per physical {core},
 not {hardware thread}.
 
 For Intel Xeon CPUs:
 
 Edit src/MAKE/OPTIONS/Makefile.intel_cpu_intelmpi as necessary. :ulb,l
-If using {kspace_style pppm} in the input script, add "neigh_modify binsize 3" and "kspace_modify diff ad" to the input script for better 
+If using {kspace_style pppm} in the input script, add "neigh_modify binsize 3" and "kspace_modify diff ad" to the input script for better
 performance. :l
 "-pk intel 0 omp 2 -sf intel" added to LAMMPS command-line :l
 :ule
 
-For Intel Xeon Phi CPUs for simulations without {kspace_style 
+For Intel Xeon Phi CPUs for simulations without {kspace_style
 pppm} in the input script :
 
 Edit src/MAKE/OPTIONS/Makefile.knl as necessary. :ulb,l
 Runs should be performed using MCDRAM. :l
-"-pk intel 0 omp 2 -sf intel" {or} "-pk intel 0 omp 4 -sf intel" 
-should be added to the LAMMPS command-line. Choice for best 
+"-pk intel 0 omp 2 -sf intel" {or} "-pk intel 0 omp 4 -sf intel"
+should be added to the LAMMPS command-line. Choice for best
 performance will depend on the simulation. :l
 :ule
 
-For Intel Xeon Phi CPUs for simulations with {kspace_style 
+For Intel Xeon Phi CPUs for simulations with {kspace_style
 pppm} in the input script:
 
 Edit src/MAKE/OPTIONS/Makefile.knl as necessary. :ulb,l
 Runs should be performed using MCDRAM. :l
-Add "neigh_modify binsize 3" to the input script for better 
+Add "neigh_modify binsize 3" to the input script for better
 performance. :l
-Add "kspace_modify diff ad" to the input script for better 
+Add "kspace_modify diff ad" to the input script for better
 performance. :l
 export KMP_AFFINITY=none :l
 "-pk intel 0 omp 3 lrt yes -sf intel" or "-pk intel 0 omp 1 lrt yes
--sf intel" added to LAMMPS command-line. Choice for best performance 
+-sf intel" added to LAMMPS command-line. Choice for best performance
 will depend on the simulation. :l
 :ule
 
-For Intel Xeon Phi coprocessors (Offload): 
+For Intel Xeon Phi coprocessors (Offload):
 
 Edit src/MAKE/OPTIONS/Makefile.intel_coprocessor as necessary :ulb,l
-"-pk intel N omp 1" added to command-line where N is the number of 
+"-pk intel N omp 1" added to command-line where N is the number of
 coprocessors per node. :l
 :ule
 
@@ -111,7 +111,7 @@ coprocessors per node. :l
 [Required hardware/software:]
 
 In order to use offload to coprocessors, an Intel Xeon Phi
-coprocessor and an Intel compiler are required. For this, the 
+coprocessor and an Intel compiler are required. For this, the
 recommended version of the Intel compiler is 14.0.1.106 or
 versions 15.0.2.044 and higher.
 
@@ -133,7 +133,7 @@ slightly lower.
 
 [Notes about Simultaneous Multithreading:]
 
-Modern CPUs often support Simultaneous Multithreading (SMT). On 
+Modern CPUs often support Simultaneous Multithreading (SMT). On
 Intel processors, this is called Hyper-Threading (HT) technology.
 SMT is hardware support for running multiple threads efficiently on
 a single core. {Hardware threads} or {logical cores} are often used
@@ -141,8 +141,8 @@ to refer to the number of threads that are supported in hardware.
 For example, the Intel Xeon E5-2697v4 processor is described
 as having 36 cores and 72 threads. This means that 36 MPI processes
 or OpenMP threads can run simultaneously on separate cores, but that
-up to 72 MPI processes or OpenMP threads can be running on the CPU 
-without costly operating system context switches. 
+up to 72 MPI processes or OpenMP threads can be running on the CPU
+without costly operating system context switches.
 
 Molecular dynamics simulations will often run faster when making use
 of SMT. If a thread becomes stalled, for example because it is
@@ -150,18 +150,18 @@ waiting on data that has not yet arrived from memory, another thread
 can start running so that the CPU pipeline is still being used
 efficiently. Although benefits can be seen by launching a MPI task
 for every hardware thread, for multinode simulations, we recommend
-that OpenMP threads are used for SMT instead, either with the 
-USER-INTEL package, "USER-OMP package"_accelerate_omp.html", or
+that OpenMP threads are used for SMT instead, either with the
+USER-INTEL package, "USER-OMP package"_accelerate_omp.html, or
 "KOKKOS package"_accelerate_kokkos.html. In the example above, up
 to 36X speedups can be observed by using all 36 physical cores with
 LAMMPS. By using all 72 hardware threads, an additional 10-30%
 performance gain can be achieved.
 
 The BIOS on many platforms allows SMT to be disabled, however, we do
-not recommend this on modern processors as there is little to no 
+not recommend this on modern processors as there is little to no
 benefit for any software package in most cases. The operating system
-will report every hardware thread as a separate core allowing one to 
-determine the number of hardware threads available. On Linux systems, 
+will report every hardware thread as a separate core allowing one to
+determine the number of hardware threads available. On Linux systems,
 this information can normally be obtained with:
 
 cat /proc/cpuinfo :pre
@@ -182,21 +182,21 @@ Makefile.intel_cpu_openpmi  # Intel Compiler, OpenMPI, No Offload
 Makefile.intel_coprocessor  # Intel Compiler, Intel MPI, Offload :pre
 
 Makefile.knl is identical to Makefile.intel_cpu_intelmpi except that
-it explicitly specifies that vectorization should be for Intel 
-Xeon Phi x200 processors making it easier to cross-compile. For 
-users with recent installations of Intel Parallel Studio, the 
+it explicitly specifies that vectorization should be for Intel
+Xeon Phi x200 processors making it easier to cross-compile. For
+users with recent installations of Intel Parallel Studio, the
 process can be as simple as:
 
 make yes-user-intel
-source /opt/intel/parallel_studio_xe_2016.3.067/psxevars.sh 
+source /opt/intel/parallel_studio_xe_2016.3.067/psxevars.sh
 # or psxevars.csh for C-shell
 make intel_cpu_intelmpi :pre
 
-Alternatively, the build can be accomplished with the src/Make.py 
-script, described in "Section 2.4"_Section_start.html#start_4 of the 
+Alternatively, the build can be accomplished with the src/Make.py
+script, described in "Section 2.4"_Section_start.html#start_4 of the
 manual. Type "Make.py -h" for help. For an example:
 
-Make.py -v -p intel omp -intel cpu -a file intel_cpu_intelmpi :pre 
+Make.py -v -p intel omp -intel cpu -a file intel_cpu_intelmpi :pre
 
 Note that if you build with support for a Phi coprocessor, the same
 binary can be used on nodes with or without coprocessors installed.
@@ -205,26 +205,26 @@ without offload support will produce a smaller binary.
 
 The general requirements for Makefiles with the USER-INTEL package
 are as follows. "-DLAMMPS_MEMALIGN=64" is required for CCFLAGS. When
-using Intel compilers, "-restrict" is required and "-qopenmp" is 
-highly recommended for CCFLAGS and LINKFLAGS. LIB should include 
+using Intel compilers, "-restrict" is required and "-qopenmp" is
+highly recommended for CCFLAGS and LINKFLAGS. LIB should include
 "-ltbbmalloc". For builds supporting offload, "-DLMP_INTEL_OFFLOAD"
 is required for CCFLAGS and "-qoffload" is required for LINKFLAGS.
-Other recommended CCFLAG options for best performance are 
-"-O2 -fno-alias -ansi-alias -qoverride-limits fp-model fast=2 
--no-prec-div". The Make.py command will add all of these 
+Other recommended CCFLAG options for best performance are
+"-O2 -fno-alias -ansi-alias -qoverride-limits fp-model fast=2
+-no-prec-div". The Make.py command will add all of these
 automatically.
 
 NOTE: The vectorization and math capabilities can differ depending on
 the CPU. For Intel compilers, the "-x" flag specifies the type of
 processor for which to optimize. "-xHost" specifies that the compiler
-should build for the processor used for compiling. For Intel Xeon Phi 
+should build for the processor used for compiling. For Intel Xeon Phi
 x200 series processors, this option is "-xMIC-AVX512". For fourth
-generation Intel Xeon (v4/Broadwell) processors, "-xCORE-AVX2" should 
+generation Intel Xeon (v4/Broadwell) processors, "-xCORE-AVX2" should
 be used. For older Intel Xeon processors, "-xAVX" will perform best
 in general for the different simulations in LAMMPS. The default
 in most of the example Makefiles is to use "-xHost", however this
 should not be used when cross-compiling.
- 
+
 [Running LAMMPS with the USER-INTEL package:]
 
 Running LAMMPS with the USER-INTEL package is similar to normal use
@@ -232,7 +232,7 @@ with the exceptions that one should 1) specify that LAMMPS should use
 the USER-INTEL package, 2) specify the number of OpenMP threads, and
 3) optionally specify the specific LAMMPS styles that should use the
 USER-INTEL package. 1) and 2) can be performed from the command-line
-or by editing the input script. 3) requires editing the input script. 
+or by editing the input script. 3) requires editing the input script.
 Advanced performance tuning options are also described below to get
 the best performance.
 
@@ -241,14 +241,14 @@ coprocessor), best performance is normally obtained by using 1 MPI
 task per physical core and additional OpenMP threads with SMT. For
 Intel Xeon processors, 2 OpenMP threads should be used for SMT.
 For Intel Xeon Phi CPUs, 2 or 4 OpenMP threads should be used
-(best choice depends on the simulation). In cases where the user 
-specifies that LRT mode is used (described below), 1 or 3 OpenMP 
+(best choice depends on the simulation). In cases where the user
+specifies that LRT mode is used (described below), 1 or 3 OpenMP
 threads should be used. For multi-node runs, using 1 MPI task per
 physical core will often perform best, however, depending on the
 machine and scale, users might get better performance by decreasing
-the number of MPI tasks and using more OpenMP threads. For 
-performance, the product of the number of MPI tasks and OpenMP 
-threads should not exceed the number of available hardware threads in 
+the number of MPI tasks and using more OpenMP threads. For
+performance, the product of the number of MPI tasks and OpenMP
+threads should not exceed the number of available hardware threads in
 almost all cases.
 
 NOTE: Setting core affinity is often used to pin MPI tasks and OpenMP
@@ -257,21 +257,21 @@ uniform. Unless disabled at build time, affinity for MPI tasks and
 OpenMP threads on the host (CPU) will be set by default on the host
 {when using offload to a coprocessor}. In this case, it is unnecessary
 to use other methods to control affinity (e.g. taskset, numactl,
-I_MPI_PIN_DOMAIN, etc.). This can be disabled with the {no_affinity} 
-option to the "package intel"_package.html command or by disabling the 
-option at build time (by adding -DINTEL_OFFLOAD_NOAFFINITY to the 
-CCFLAGS line of your Makefile). Disabling this option is not 
-recommended, especially when running on a machine with Intel 
+I_MPI_PIN_DOMAIN, etc.). This can be disabled with the {no_affinity}
+option to the "package intel"_package.html command or by disabling the
+option at build time (by adding -DINTEL_OFFLOAD_NOAFFINITY to the
+CCFLAGS line of your Makefile). Disabling this option is not
+recommended, especially when running on a machine with Intel
 Hyper-Threading technology disabled.
 
 [Run with the USER-INTEL package from the command line:]
 
-To enable USER-INTEL optimizations for all available styles used in 
-the input script, the "-sf intel" 
+To enable USER-INTEL optimizations for all available styles used in
+the input script, the "-sf intel"
 "command-line switch"_Section_start.html#start_7 can be used without
 any requirement for editing the input script. This switch will
-automatically append "intel" to styles that support it. It also 
-invokes a default command: "package intel 1"_package.html. This 
+automatically append "intel" to styles that support it. It also
+invokes a default command: "package intel 1"_package.html. This
 package command is used to set options for the USER-INTEL package.
 The default package command will specify that USER-INTEL calculations
 are performed in mixed precision, that the number of OpenMP threads
@@ -281,16 +281,16 @@ support, that 1 coprocessor per node will be used with automatic
 balancing of work between the CPU and the coprocessor.
 
 You can specify different options for the USER-INTEL package by using
-the "-pk intel Nphi" "command-line switch"_Section_start.html#start_7 
+the "-pk intel Nphi" "command-line switch"_Section_start.html#start_7
 with keyword/value pairs as specified in the documentation. Here,
 Nphi = # of Xeon Phi coprocessors/node (ignored without offload
 support). Common options to the USER-INTEL package include {omp} to
 override any OMP_NUM_THREADS setting and specify the number of OpenMP
 threads, {mode} to set the floating-point precision mode, and
-{lrt} to enable Long-Range Thread mode as described below. See the 
-"package intel"_package.html command for details, including the 
-default values used for all its options if not specified, and how to 
-set the number of OpenMP threads via the OMP_NUM_THREADS environment 
+{lrt} to enable Long-Range Thread mode as described below. See the
+"package intel"_package.html command for details, including the
+default values used for all its options if not specified, and how to
+set the number of OpenMP threads via the OMP_NUM_THREADS environment
 variable if desired.
 
 Examples (see documentation for your MPI/Machine for differences in
@@ -303,7 +303,7 @@ mpirun -np 72 -ppn 36 lmp_machine -sf intel -in in.script -pk intel 0 omp 2 mode
 
 As an alternative to adding command-line arguments, the input script
 can be edited to enable the USER-INTEL package. This requires adding
-the "package intel"_package.html command to the top of the input 
+the "package intel"_package.html command to the top of the input
 script. For the second example above, this would be:
 
 package intel 0 omp 2 mode double :pre
@@ -314,46 +314,46 @@ add an "intel" suffix to the individual style, e.g.:
 pair_style lj/cut/intel 2.5 :pre
 
 Alternatively, the "suffix intel"_suffix.html command can be added to
-the input script to enable USER-INTEL styles for the commands that 
+the input script to enable USER-INTEL styles for the commands that
 follow in the input script.
 
 [Tuning for Performance:]
 
-NOTE: The USER-INTEL package will perform better with modifications 
-to the input script when "PPPM"_kspace_style.html is used: 
-"kspace_modify diff ad"_kspace_modify.html and "neigh_modify binsize 
+NOTE: The USER-INTEL package will perform better with modifications
+to the input script when "PPPM"_kspace_style.html is used:
+"kspace_modify diff ad"_kspace_modify.html and "neigh_modify binsize
 3"_neigh_modify.html should be added to the input script.
 
-Long-Range Thread (LRT) mode is an option to the "package 
+Long-Range Thread (LRT) mode is an option to the "package
 intel"_package.html command that can improve performance when using
 "PPPM"_kspace_style.html for long-range electrostatics on processors
-with SMT. It generates an extra pthread for each MPI task. The thread 
-is dedicated to performing some of the PPPM calculations and MPI 
+with SMT. It generates an extra pthread for each MPI task. The thread
+is dedicated to performing some of the PPPM calculations and MPI
 communications. On Intel Xeon Phi x200 series CPUs, this will likely
 always improve performance, even on a single node. On Intel Xeon
 processors, using this mode might result in better performance when
 using multiple nodes, depending on the machine. To use this mode,
-specify that the number of OpenMP threads is one less than would 
+specify that the number of OpenMP threads is one less than would
 normally be used for the run and add the "lrt yes" option to the "-pk"
 command-line suffix or "package intel" command. For example, if a run
 would normally perform best with "-pk intel 0 omp 4", instead use
-"-pk intel 0 omp 3 lrt yes". When using LRT, you should set the 
-environment variable "KMP_AFFINITY=none". LRT mode is not supported 
+"-pk intel 0 omp 3 lrt yes". When using LRT, you should set the
+environment variable "KMP_AFFINITY=none". LRT mode is not supported
 when using offload.
 
 Not all styles are supported in the USER-INTEL package. You can mix
-the USER-INTEL package with styles from the "OPT"_accelerate_opt.html 
-package or the "USER-OMP package"_accelerate_omp.html". Of course, 
+the USER-INTEL package with styles from the "OPT"_accelerate_opt.html
+package or the "USER-OMP package"_accelerate_omp.html. Of course,
 this requires that these packages were installed at build time. This
 can performed automatically by using "-sf hybrid intel opt" or
 "-sf hybrid intel omp" command-line options. Alternatively, the "opt"
 and "omp" suffixes can be appended manually in the input script. For
 the latter, the "package omp"_package.html command must be in the
-input script or the "-pk omp Nt" "command-line 
-switch"_Section_start.html#start_7 must be used where Nt is the 
+input script or the "-pk omp Nt" "command-line
+switch"_Section_start.html#start_7 must be used where Nt is the
 number of OpenMP threads. The number of OpenMP threads should not be
-set differently for the different packages. Note that the "suffix 
-hybrid intel omp"_suffix.html command can also be used within the 
+set differently for the different packages. Note that the "suffix
+hybrid intel omp"_suffix.html command can also be used within the
 input script to automatically append the "omp" suffix to styles when
 USER-INTEL styles are not available.
 
@@ -374,33 +374,33 @@ that MPI runs are performed in MCDRAM.
 
 [Tuning for Offload Performance:]
 
-The default settings for offload should give good performance. 
+The default settings for offload should give good performance.
 
 When using LAMMPS with offload to Intel coprocessors, best performance
 will typically be achieved with concurrent calculations performed on
 both the CPU and the coprocessor. This is achieved by offloading only
 a fraction of the neighbor and pair computations to the coprocessor or
 using "hybrid"_pair_hybrid.html pair styles where only one style uses
-the "intel" suffix. For simulations with long-range electrostatics or 
-bond, angle, dihedral, improper calculations, computation and data 
-transfer to the coprocessor will run concurrently with computations 
+the "intel" suffix. For simulations with long-range electrostatics or
+bond, angle, dihedral, improper calculations, computation and data
+transfer to the coprocessor will run concurrently with computations
 and MPI communications for these calculations on the host CPU. This
 is illustrated in the figure below for the rhodopsin protein benchmark
-running on E5-2697v2 processors with a Intel Xeon Phi 7120p 
+running on E5-2697v2 processors with a Intel Xeon Phi 7120p
 coprocessor. In this plot, the vertical access is time and routines
 running at the same time are running concurrently on both the host and
 the coprocessor.
 
 :c,image(JPG/offload_knc.png)
 
-The fraction of the offloaded work is controlled by the {balance} 
-keyword in the "package intel"_package.html command. A balance of 0 
-runs all calculations on the CPU.  A balance of 1 runs all 
-supported calculations on the coprocessor.  A balance of 0.5 runs half 
-of the calculations on the coprocessor.  Setting the balance to -1 
-(the default) will enable dynamic load balancing that continously 
-adjusts the fraction of offloaded work throughout the simulation. 
-Because data transfer cannot be timed, this option typically produces 
+The fraction of the offloaded work is controlled by the {balance}
+keyword in the "package intel"_package.html command. A balance of 0
+runs all calculations on the CPU.  A balance of 1 runs all
+supported calculations on the coprocessor.  A balance of 0.5 runs half
+of the calculations on the coprocessor.  Setting the balance to -1
+(the default) will enable dynamic load balancing that continously
+adjusts the fraction of offloaded work throughout the simulation.
+Because data transfer cannot be timed, this option typically produces
 results within 5 to 10 percent of the optimal fixed balance.
 
 If running short benchmark runs with dynamic load balancing, adding a
@@ -418,15 +418,15 @@ with 60 cores available for offload and 4 hardware threads per core
 each MPI task to use a subset of 10 threads on the coprocessor.  Fine
 tuning of the number of threads to use per MPI task or the number of
 threads to use per core can be accomplished with keyword settings of
-the "package intel"_package.html command. 
+the "package intel"_package.html command.
 
-The USER-INTEL package has two modes for deciding which atoms will be 
-handled by the coprocessor.  This choice is controlled with the {ghost} 
-keyword of the "package intel"_package.html command.  When set to 0, 
-ghost atoms (atoms at the borders between MPI tasks) are not offloaded 
-to the card.  This allows for overlap of MPI communication of forces 
-with computation on the coprocessor when the "newton"_newton.html 
-setting is "on".  The default is dependent on the style being used, 
+The USER-INTEL package has two modes for deciding which atoms will be
+handled by the coprocessor.  This choice is controlled with the {ghost}
+keyword of the "package intel"_package.html command.  When set to 0,
+ghost atoms (atoms at the borders between MPI tasks) are not offloaded
+to the card.  This allows for overlap of MPI communication of forces
+with computation on the coprocessor when the "newton"_newton.html
+setting is "on".  The default is dependent on the style being used,
 however, better performance may be achieved by setting this option
 explictly.
 
@@ -442,10 +442,10 @@ mode is being used and indicating the number of coprocessor threads
 per MPI task.  Additionally, an offload timing summary is printed at
 the end of each run.  When offloading, the frequency for "atom
 sorting"_atom_modify.html is changed to 1 so that the per-atom data is
-effectively sorted at every rebuild of the neighbor lists. All the 
-available coprocessor threads on each Phi will be divided among MPI 
-tasks, unless the {tptask} option of the "-pk intel" "command-line 
-switch"_Section_start.html#start_7 is used to limit the coprocessor 
+effectively sorted at every rebuild of the neighbor lists. All the
+available coprocessor threads on each Phi will be divided among MPI
+tasks, unless the {tptask} option of the "-pk intel" "command-line
+switch"_Section_start.html#start_7 is used to limit the coprocessor
 threads per MPI task.
 
 [Restrictions:]

doc/src/accelerate_kokkos.txt

@@ -65,7 +65,7 @@ Make.py -v -p kokkos -kokkos omp -o mpi -a file mpi   # or one-line build via Ma
 
 mpirun -np 16 lmp_mpi -k on -sf kk -in in.lj              # 1 node, 16 MPI tasks/node, no threads
 mpirun -np 2 -ppn 1 lmp_mpi -k on t 16 -sf kk -in in.lj   # 2 nodes, 1 MPI task/node, 16 threads/task
-mpirun -np 2 lmp_mpi -k on t 8 -sf kk -in in.lj           # 1 node, 2 MPI tasks/node, 8 threads/task 
+mpirun -np 2 lmp_mpi -k on t 8 -sf kk -in in.lj           # 1 node, 2 MPI tasks/node, 8 threads/task
 mpirun -np 32 -ppn 4 lmp_mpi -k on t 4 -sf kk -in in.lj   # 8 nodes, 4 MPI tasks/node, 4 threads/task :pre
 
 specify variables and settings in your Makefile.machine that enable OpenMP, GPU, or Phi support
@@ -156,23 +156,29 @@ CPU-only (run all-MPI or with OpenMP threading):
 
 cd lammps/src
 make yes-kokkos
-make g++ KOKKOS_DEVICES=OpenMP :pre
+make kokkos_omp :pre
 
-Intel Xeon Phi:
+CPU-only (only MPI, no threading):
 
 cd lammps/src
 make yes-kokkos
-make g++ KOKKOS_DEVICES=OpenMP KOKKOS_ARCH=KNC :pre
+make kokkos_mpi :pre
 
-CPUs and GPUs:
+Intel Xeon Phi (Intel Compiler, Intel MPI):
 
 cd lammps/src
 make yes-kokkos
-make cuda KOKKOS_DEVICES=Cuda :pre
+make kokkos_phi :pre
+
+CPUs and GPUs (with MPICH):
+
+cd lammps/src
+make yes-kokkos
+make kokkos_cuda_mpich :pre
 
 These examples set the KOKKOS-specific OMP, MIC, CUDA variables on the
 make command line which requires a GNU-compatible make command.  Try
-"gmake" if your system's standard make complains.  
+"gmake" if your system's standard make complains.
 
 NOTE: If you build using make line variables and re-build LAMMPS twice
 with different KOKKOS options and the *same* target, e.g. g++ in the
@@ -180,26 +186,6 @@ first two examples above, then you *must* perform a "make clean-all"
 or "make clean-machine" before each build.  This is to force all the
 KOKKOS-dependent files to be re-compiled with the new options.
 
-You can also hardwire these make variables in the specified machine
-makefile, e.g. src/MAKE/Makefile.g++ in the first two examples above,
-with a line like:
-
-KOKKOS_ARCH = KNC :pre
-
-Note that if you build LAMMPS multiple times in this manner, using
-different KOKKOS options (defined in different machine makefiles), you
-do not have to worry about doing a "clean" in between.  This is
-because the targets will be different.
-
-NOTE: The 3rd example above for a GPU, uses a different machine
-makefile, in this case src/MAKE/Makefile.cuda, which is included in
-the LAMMPS distribution.  To build the KOKKOS package for a GPU, this
-makefile must use the NVIDA "nvcc" compiler.  And it must have a
-KOKKOS_ARCH setting that is appropriate for your NVIDIA hardware and
-installed software.  Typical values for KOKKOS_ARCH are given below,
-as well as other settings that must be included in the machine
-makefile, if you create your own.
-
 NOTE: Currently, there are no precision options with the KOKKOS
 package.  All compilation and computation is performed in double
 precision.
@@ -246,7 +232,7 @@ used if running with KOKKOS_DEVICES=Pthreads for pthreads.  It is not
 necessary for KOKKOS_DEVICES=OpenMP for OpenMP, because OpenMP
 provides alternative methods via environment variables for binding
 threads to hardware cores.  More info on binding threads to cores is
-given in "this section"_Section_accelerate.html#acc_3.
+given in "Section 5.3"_Section_accelerate.html#acc_3.
 
 KOKKOS_ARCH=KNC enables compiler switches needed when compling for an
 Intel Phi processor.
@@ -408,7 +394,7 @@ additional parallelism (beyond MPI) will be invoked on the host
 CPU(s).
 
 You can compare the performance running in different modes:
-  
+
 run with 1 MPI task/node and N threads/task
 run with N MPI tasks/node and 1 thread/task
 run with settings in between these extremes :ul
@@ -441,7 +427,7 @@ e.g. src/MAKE/Makefile.cuda, is correct for your GPU hardware/software
 details).
 
 The -np setting of the mpirun command should set the number of MPI
-tasks/node to be equal to the # of physical GPUs on the node. 
+tasks/node to be equal to the # of physical GPUs on the node.
 
 Use the "-k" "command-line switch"_Section_commands.html#start_7 to
 specify the number of GPUs per node, and the number of threads per MPI

doc/src/accelerate_omp.txt

@@ -7,7 +7,7 @@
 
 :line
 
-"Return to Section accelerate overview"_Section_accelerate.html
+"Return to Section 5 overview"_Section_accelerate.html
 
 5.3.4 USER-OMP package :h5
 
@@ -96,15 +96,15 @@ variable.
 
 Depending on which styles are accelerated, you should look for a
 reduction in the "Pair time", "Bond time", "KSpace time", and "Loop
-time" values printed at the end of a run.  
+time" values printed at the end of a run.
 
 You may see a small performance advantage (5 to 20%) when running a
 USER-OMP style (in serial or parallel) with a single thread per MPI
 task, versus running standard LAMMPS with its standard un-accelerated
 styles (in serial or all-MPI parallelization with 1 task/core).  This
 is because many of the USER-OMP styles contain similar optimizations
-to those used in the OPT package, described in "Section accelerate
-5.3.6"_accelerate_opt.html.
+to those used in the OPT package, described in "Section
+5.3.5"_accelerate_opt.html.
 
 With multiple threads/task, the optimal choice of number of MPI
 tasks/node and OpenMP threads/task can vary a lot and should always be

doc/src/angle_charmm.txt

@@ -74,7 +74,7 @@ more instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 
 This angle style can only be used if LAMMPS was built with the
-MOLECULE package (which it is by default).  See the "Making
+MOLECULE package.  See the "Making
 LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]

doc/src/angle_cosine.txt

@@ -61,7 +61,7 @@ more instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 
 This angle style can only be used if LAMMPS was built with the
-MOLECULE package (which it is by default).  See the "Making
+MOLECULE package.  See the "Making
 LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]

doc/src/angle_cosine_delta.txt

@@ -66,7 +66,7 @@ more instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 
 This angle style can only be used if LAMMPS was built with the
-MOLECULE package (which it is by default).  See the "Making
+MOLECULE package.  See the "Making
 LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]

doc/src/angle_cosine_periodic.txt

@@ -74,7 +74,7 @@ more instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 
 This angle style can only be used if LAMMPS was built with the
-MOLECULE package (which it is by default).  See the "Making
+MOLECULE package.  See the "Making
 LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]

doc/src/angle_cosine_squared.txt

@@ -66,7 +66,7 @@ more instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 
 This angle style can only be used if LAMMPS was built with the
-MOLECULE package (which it is by default).  See the "Making
+MOLECULE package.  See the "Making
 LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]

doc/src/angle_dipole.txt

@@ -21,11 +21,11 @@ angle_coeff 6 2.1 180.0 :pre
 [Description:]
 
 The {dipole} angle style is used to control the orientation of a dipolar
-atom within a molecule "(Orsi)"_#Orsi. Specifically, the {dipole} angle 
-style restrains the orientation of a point dipole mu_j (embedded in atom 
-'j') with respect to a reference (bond) vector r_ij = r_i - r_j, where 'i' 
-is another atom of the same molecule (typically, 'i' and 'j' are also 
-covalently bonded). 
+atom within a molecule "(Orsi)"_#Orsi. Specifically, the {dipole} angle
+style restrains the orientation of a point dipole mu_j (embedded in atom
+'j') with respect to a reference (bond) vector r_ij = r_i - r_j, where 'i'
+is another atom of the same molecule (typically, 'i' and 'j' are also
+covalently bonded).
 
 It is convenient to define an angle gamma between the 'free' vector mu_j
 and the reference (bond) vector r_ij:
@@ -37,21 +37,21 @@ The {dipole} angle style uses the potential:
 :c,image(Eqs/angle_dipole_potential.jpg)
 
 where K is a rigidity constant and gamma0 is an equilibrium (reference)
-angle. 
+angle.
 
-The torque on the dipole can be obtained by differentiating the 
-potential using the 'chain rule' as in appendix C.3 of 
+The torque on the dipole can be obtained by differentiating the
+potential using the 'chain rule' as in appendix C.3 of
 "(Allen)"_#Allen:
 
 :c,image(Eqs/angle_dipole_torque.jpg)
 
 Example: if gamma0 is set to 0 degrees, the torque generated by
-the potential will tend to align the dipole along the reference 
+the potential will tend to align the dipole along the reference
 direction defined by the (bond) vector r_ij (in other words, mu_j is
 restrained to point towards atom 'i').
 
-The dipolar torque T_j must be counterbalanced in order to conserve 
-the local angular momentum. This is achieved via an additional force 
+The dipolar torque T_j must be counterbalanced in order to conserve
+the local angular momentum. This is achieved via an additional force
 couple generating a torque equivalent to the opposite of T_j:
 
 :c,image(Eqs/angle_dipole_couple.jpg)
@@ -118,7 +118,7 @@ This angle style should not be used with SHAKE.
 :line
 
 :link(Orsi)
-[(Orsi)] Orsi & Essex, The ELBA force field for coarse-grain modeling of 
+[(Orsi)] Orsi & Essex, The ELBA force field for coarse-grain modeling of
 lipid membranes, PloS ONE 6(12): e28637, 2011.
 
 :link(Allen)

doc/src/angle_fourier.txt

@@ -62,7 +62,7 @@ more instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 
 This angle style can only be used if LAMMPS was built with the
-USER_MISC package.  See the "Making LAMMPS"_Section_start.html#start_3 
+USER_MISC package.  See the "Making LAMMPS"_Section_start.html#start_3
 section for more info on packages.
 
 [Related commands:]

doc/src/angle_fourier_simple.txt

@@ -61,7 +61,7 @@ more instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 
 This angle style can only be used if LAMMPS was built with the
-USER_MISC package.  See the "Making LAMMPS"_Section_start.html#start_3 
+USER_MISC package.  See the "Making LAMMPS"_Section_start.html#start_3
 section for more info on packages.
 
 [Related commands:]

doc/src/angle_harmonic.txt

@@ -65,11 +65,11 @@ more instructions on how to use the accelerated styles effectively.
 
 :line
 
-[Restrictions:] none
+[Restrictions:]
 
 This angle style can only be used if LAMMPS was built with the
-MOLECULE package (which it is by default).  See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+MOLECULE package.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info on packages.
 
 [Related commands:]
 

doc/src/angle_hybrid.txt

@@ -76,7 +76,7 @@ for specific angle types.
 [Restrictions:]
 
 This angle style can only be used if LAMMPS was built with the
-MOLECULE package (which it is by default).  See the "Making
+MOLECULE package.  See the "Making
 LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 Unlike other angle styles, the hybrid angle style does not store angle

doc/src/angle_quartic.txt

@@ -68,7 +68,7 @@ more instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 
 This angle style can only be used if LAMMPS was built with the
-USER_MISC package.  See the "Making LAMMPS"_Section_start.html#start_3 
+USER_MISC package.  See the "Making LAMMPS"_Section_start.html#start_3
 section for more info on packages.
 
 [Related commands:]

doc/src/angle_sdk.txt

@@ -43,7 +43,7 @@ internally; hence the units of K are in energy/radian^2.
 The also required {lj/sdk} parameters will be extracted automatically
 from the pair_style.
 
-[Restrictions:] 
+[Restrictions:]
 
 This angle style can only be used if LAMMPS was built with the
 USER-CG-CMM package.  See the "Making

doc/src/angle_table.txt

@@ -147,7 +147,7 @@ more instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 
 This angle style can only be used if LAMMPS was built with the
-MOLECULE package (which it is by default).  See the "Making
+MOLECULE package.  See the "Making
 LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]

doc/src/atom_modify.txt

@@ -1,4 +1,4 @@
-"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS  
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS
 Commands"_lc :c
 
 :link(lws,http://lammps.sandia.gov)
@@ -156,12 +156,12 @@ used with a group-ID that is not "all".
 
 [Default:]
 
-By default, {id} is yes.  By default, atomic systems (no bond topology  
-info) do not use a map.  For molecular systems (with bond topology  
-info), a map is used.  The default map style is array if no atom ID is  
-larger than 1 million, otherwise the default is hash.  By default, a  
-"first" group is not defined.  By default, sorting is enabled with a  
-frequency of 1000 and a binsize of 0.0, which means the neighbor  
+By default, {id} is yes.  By default, atomic systems (no bond topology
+info) do not use a map.  For molecular systems (with bond topology
+info), a map is used.  The default map style is array if no atom ID is
+larger than 1 million, otherwise the default is hash.  By default, a
+"first" group is not defined.  By default, sorting is enabled with a
+frequency of 1000 and a binsize of 0.0, which means the neighbor
 cutoff will be used to set the bin size.
 
 :line

doc/src/atom_style.txt

@@ -14,7 +14,7 @@ atom_style style args :pre
 
 style = {angle} or {atomic} or {body} or {bond} or {charge} or {dipole} or \
         {dpd} or {electron} or {ellipsoid} or {full} or {line} or {meso} or \
-	{molecular} or {peri} or {smd} or {sphere} or {tri} or \
+        {molecular} or {peri} or {smd} or {sphere} or {tri} or \
         {template} or {hybrid} :ulb,l
   args = none for any style except the following
   {body} args = bstyle bstyle-args
@@ -166,7 +166,7 @@ stores a per-particle mass and size and orientation (i.e. the corner
 points of the triangle).
 
 The {template} style allows molecular topolgy (bonds,angles,etc) to be
-defined via a molecule template using the "molecule"_molecule.txt
+defined via a molecule template using the "molecule"_molecule.html
 command.  The template stores one or more molecules with a single copy
 of the topology info (bonds,angles,etc) of each.  Individual atoms
 only store a template index and template atom to identify which
@@ -193,7 +193,7 @@ For the {body} style, the particles are arbitrary bodies with internal
 attributes defined by the "style" of the bodies, which is specified by
 the {bstyle} argument.  Body particles can represent complex entities,
 such as surface meshes of discrete points, collections of
-sub-particles, deformable objects, etc.  
+sub-particles, deformable objects, etc.
 
 The "body"_body.html doc page descibes the body styles LAMMPS
 currently supports, and provides more details as to the kind of body
@@ -269,7 +269,7 @@ The {line} and {tri} styles are part of the ASPHERE package.
 
 The {body} style is part of the BODY package.
 
-The {dipole} style is part of the DIPOLE package.  
+The {dipole} style is part of the DIPOLE package.
 
 The {peri} style is part of the PERI package for Peridynamics.
 

doc/src/balance.txt

@@ -10,7 +10,7 @@ balance command :h3
 
 [Syntax:]
 
-balance thresh style args ... keyword value ... :pre
+balance thresh style args ... keyword args ... :pre
 
 thresh = imbalance threshhold that must be exceeded to perform a re-balance :ulb,l
 one style/arg pair can be used (or multiple for {x},{y},{z}) :l
@@ -32,9 +32,23 @@ style = {x} or {y} or {z} or {shift} or {rcb} :l
     Niter = # of times to iterate within each dimension of dimstr sequence
     stopthresh = stop balancing when this imbalance threshhold is reached
   {rcb} args = none :pre
-zero or more keyword/value pairs may be appended :l
-keyword = {out} :l
-  {out} value = filename
+zero or more keyword/arg pairs may be appended :l
+keyword = {weight} or {out} :l
+  {weight} style args = use weighted particle counts for the balancing
+    {style} = {group} or {neigh} or {time} or {var} or {store}
+      {group} args = Ngroup group1 weight1 group2 weight2 ...
+        Ngroup = number of groups with assigned weights
+        group1, group2, ... = group IDs
+        weight1, weight2, ...   = corresponding weight factors
+      {neigh} factor = compute weight based on number of neighbors
+        factor = scaling factor (> 0)
+      {time} factor = compute weight based on time spend computing
+        factor = scaling factor (> 0)
+      {var} name = take weight from atom-style variable
+        name = name of the atom-style variable
+      {store} name = store weight in custom atom property defined by "fix property/atom"_fix_property_atom.html command
+        name = atom property name (without d_ prefix)
+  {out} arg = filename
     filename = write each processor's sub-domain to a file :pre
 :ule
 
@@ -44,28 +58,42 @@ balance 0.9 x uniform y 0.4 0.5 0.6
 balance 1.2 shift xz 5 1.1
 balance 1.0 shift xz 5 1.1
 balance 1.1 rcb
+balance 1.0 shift x 10 1.1 weight group 2 fast 0.5 slow 2.0
+balance 1.0 shift x 10 1.1 weight time 0.8 weight neigh 0.5 weight store balance
 balance 1.0 shift x 20 1.0 out tmp.balance :pre
 
 [Description:]
 
 This command adjusts the size and shape of processor sub-domains
-within the simulation box, to attempt to balance the number of
-particles and thus the computational cost (load) evenly across
-processors.  The load balancing is "static" in the sense that this
-command performs the balancing once, before or between simulations.
-The processor sub-domains will then remain static during the
-subsequent run.  To perform "dynamic" balancing, see the "fix
+within the simulation box, to attempt to balance the number of atoms
+or particles and thus indirectly the computational cost (load) more
+evenly across processors.  The load balancing is "static" in the sense
+that this command performs the balancing once, before or between
+simulations.  The processor sub-domains will then remain static during
+the subsequent run.  To perform "dynamic" balancing, see the "fix
 balance"_fix_balance.html command, which can adjust processor
 sub-domain sizes and shapes on-the-fly during a "run"_run.html.
 
-Load-balancing is typically only useful if the particles in the
-simulation box have a spatially-varying density distribution.  E.g. a
-model of a vapor/liquid interface, or a solid with an irregular-shaped
-geometry containing void regions.  In this case, the LAMMPS default of
+Load-balancing is typically most useful if the particles in the
+simulation box have a spatially-varying density distribution or when
+the computational cost varies signficantly between different
+particles.  E.g. a model of a vapor/liquid interface, or a solid with
+an irregular-shaped geometry containing void regions, or "hybrid pair
+style simulations"_pair_hybrid.html which combine pair styles with
+different computational cost.  In these cases, the LAMMPS default of
 dividing the simulation box volume into a regular-spaced grid of 3d
-bricks, with one equal-volume sub-domain per procesor, may assign very
-different numbers of particles per processor.  This can lead to poor
-performance when the simulation is run in parallel.
+bricks, with one equal-volume sub-domain per procesor, may assign
+numbers of particles per processor in a way that the computational
+effort varies significantly.  This can lead to poor performance when
+the simulation is run in parallel.
+
+The balancing can be performed with or without per-particle weighting.
+With no weighting, the balancing attempts to assign an equal number of
+particles to each processor.  With weighting, the balancing attempts
+to assign an equal aggregate computational weight to each processor,
+which typically inducces a diffrent number of atoms assigned to each
+processor.  Details on the various weighting options and examples for
+how they can be used are "given below"_#weighted_balance.
 
 Note that the "processors"_processors.html command allows some control
 over how the box volume is split across processors.  Specifically, for
@@ -78,9 +106,9 @@ sub-domains will still have the same shape and same volume.
 The requested load-balancing operation is only performed if the
 current "imbalance factor" in particles owned by each processor
 exceeds the specified {thresh} parameter.  The imbalance factor is
-defined as the maximum number of particles owned by any processor,
-divided by the average number of particles per processor.  Thus an
-imbalance factor of 1.0 is perfect balance.
+defined as the maximum number of particles (or weight) owned by any
+processor, divided by the average number of particles (or weight) per
+processor.  Thus an imbalance factor of 1.0 is perfect balance.
 
 As an example, for 10000 particles running on 10 processors, if the
 most heavily loaded processor has 1200 particles, then the factor is
@@ -108,7 +136,7 @@ defined above.  But depending on the method a perfect balance (1.0)
 may not be achieved.  For example, "grid" methods (defined below) that
 create a logical 3d grid cannot achieve perfect balance for many
 irregular distributions of particles.  Likewise, if a portion of the
-system is a perfect lattice, e.g. the intiial system is generated by
+system is a perfect lattice, e.g. the initial system is generated by
 the "create_atoms"_create_atoms.html command, then "grid" methods may
 be unable to achieve exact balance.  This is because entire lattice
 planes will be owned or not owned by a single processor.
@@ -134,11 +162,11 @@ The {x}, {y}, {z}, and {shift} styles are "grid" methods which produce
 a logical 3d grid of processors.  They operate by changing the cutting
 planes (or lines) between processors in 3d (or 2d), to adjust the
 volume (area in 2d) assigned to each processor, as in the following 2d
-diagram where processor sub-domains are shown and atoms are colored by
-the processor that owns them.  The leftmost diagram is the default
-partitioning of the simulation box across processors (one sub-box for
-each of 16 processors); the middle diagram is after a "grid" method
-has been applied.
+diagram where processor sub-domains are shown and particles are
+colored by the processor that owns them.  The leftmost diagram is the
+default partitioning of the simulation box across processors (one
+sub-box for each of 16 processors); the middle diagram is after a
+"grid" method has been applied.
 
 :image(JPG/balance_uniform_small.jpg,JPG/balance_uniform.jpg),image(JPG/balance_nonuniform_small.jpg,JPG/balance_nonuniform.jpg),image(JPG/balance_rcb_small.jpg,JPG/balance_rcb.jpg)
 :c
@@ -146,8 +174,8 @@ has been applied.
 The {rcb} style is a "tiling" method which does not produce a logical
 3d grid of processors.  Rather it tiles the simulation domain with
 rectangular sub-boxes of varying size and shape in an irregular
-fashion so as to have equal numbers of particles in each sub-box, as
-in the rightmost diagram above.
+fashion so as to have equal numbers of particles (or weight) in each
+sub-box, as in the rightmost diagram above.
 
 The "grid" methods can be used with either of the
 "comm_style"_comm_style.html command options, {brick} or {tiled}.  The
@@ -230,7 +258,7 @@ counts do not match the target value for the plane, the position of
 the cut is adjusted to be halfway between a low and high bound.  The
 low and high bounds are adjusted on each iteration, using new count
 information, so that they become closer together over time.  Thus as
-the recustion progresses, the count of particles on either side of the
+the recursion progresses, the count of particles on either side of the
 plane gets closer to the target value.
 
 Once the rebalancing is complete and final processor sub-domains
@@ -262,21 +290,155 @@ the longest dimension, leaving one new box on either side of the cut.
 All the processors are also partitioned into 2 groups, half assigned
 to the box on the lower side of the cut, and half to the box on the
 upper side.  (If the processor count is odd, one side gets an extra
-processor.)  The cut is positioned so that the number of atoms in the
-lower box is exactly the number that the processors assigned to that
-box should own for load balance to be perfect.  This also makes load
-balance for the upper box perfect.  The positioning is done
-iteratively, by a bisectioning method.  Note that counting atoms on
-either side of the cut requires communication between all processors
-at each iteration.
+processor.)  The cut is positioned so that the number of particles in
+the lower box is exactly the number that the processors assigned to
+that box should own for load balance to be perfect.  This also makes
+load balance for the upper box perfect.  The positioning is done
+iteratively, by a bisectioning method.  Note that counting particles
+on either side of the cut requires communication between all
+processors at each iteration.
 
 That is the procedure for the first cut.  Subsequent cuts are made
 recursively, in exactly the same manner.  The subset of processors
 assigned to each box make a new cut in the longest dimension of that
-box, splitting the box, the subset of processsors, and the atoms in
-the box in two.  The recursion continues until every processor is
-assigned a sub-box of the entire simulation domain, and owns the atoms
-in that sub-box.
+box, splitting the box, the subset of processsors, and the particles
+in the box in two.  The recursion continues until every processor is
+assigned a sub-box of the entire simulation domain, and owns the
+particles in that sub-box.
+
+:line
+
+This sub-section describes how to perform weighted load balancing
+using the {weight} keyword. :link(weighted_balance)
+
+By default, all particles have a weight of 1.0, which means each
+particle is assumed to require the same amount of computation during a
+timestep.  There are, however, scenarios where this is not a good
+assumption.  Measuring the computational cost for each particle
+accurately would be impractical and slow down the computation.
+Instead the {weight} keyword implements several ways to influence the
+per-particle weights empirically by properties readily available or
+using the user's knowledge of the system.  Note that the absolute
+value of the weights are not important; only their relative ratios
+affect which particle is assigned to which processor.  A particle with
+a weight of 2.5 is assumed to require 5x more computational than a
+particle with a weight of 0.5.  For all the options below the weight
+assigned to a particle must be a positive value; an error will be be
+generated if a weight is <= 0.0.
+
+Below is a list of possible weight options with a short description of
+their usage and some example scenarios where they might be applicable.
+It is possible to apply multiple weight flags and the weightings they
+induce will be combined through multiplication.  Most of the time,
+however, it is sufficient to use just one method.
+
+The {group} weight style assigns weight factors to specified
+"groups"_group.html of particles.  The {group} style keyword is
+followed by the number of groups, then pairs of group IDs and the
+corresponding weight factor.  If a particle belongs to none of the
+specified groups, its weight is not changed.  If it belongs to
+multiple groups, its weight is the product of the weight factors.
+
+This weight style is useful in combination with pair style
+"hybrid"_pair_hybrid.html, e.g. when combining a more costly manybody
+potential with a fast pair-wise potential.  It is also useful when
+using "run_style respa"_run_style.html where some portions of the
+system have many bonded interactions and others none.  It assumes that
+the computational cost for each group remains constant over time.
+This is a purely empirical weighting, so a series test runs to tune
+the assigned weight factors for optimal performance is recommended.
+
+The {neigh} weight style assigns the same weight to each particle
+owned by a processor based on the total count of neighbors in the
+neighbor list owned by that processor.  The motivation is that more
+neighbors means a higher computational cost.  The style does not use
+neighbors per atom to assign a unique weight to each atom, because
+that value can vary depending on how the neighbor list is built.
+
+The {factor} setting is applied as an overall scale factor to the
+{neigh} weights which allows adjustment of their impact on the
+balancing operation.  The specified {factor} value must be positive.
+A value > 1.0 will increase the weights so that the ratio of max
+weight to min weight increases by {factor}.  A value < 1.0 will
+decrease the weights so that the ratio of max weight to min weight
+decreases by {factor}.  In both cases the intermediate weight values
+increase/decrease proportionally as well.  A value = 1.0 has no effect
+on the {neigh} weights.  As a rule of thumb, we have found a {factor}
+of about 0.8 often results in the best performance, since the number
+of neighbors is likely to overestimate the ideal weight.
+
+This weight style is useful for systems where there are different
+cutoffs used for different pairs of interations, or the density
+fluctuates, or a large number of particles are in the vicinity of a
+wall, or a combination of these effects.  If a simulation uses
+multiple neighbor lists, this weight style will use the first suitable
+neighbor list it finds.  It will not request or compute a new list.  A
+warning will be issued if there is no suitable neighbor list available
+or if it is not current, e.g. if the balance command is used before a
+"run"_run.html or "minimize"_minimize.html command is used, in which
+case the neighbor list may not yet have been built.  In this case no
+weights are computed.  Inserting a "run 0 post no"_run.html command
+before issuing the {balance} command, may be a workaround for this
+case, as it will induce the neighbor list to be built.
+
+The {time} weight style uses "timer data"_timer.html to estimate
+weights.  It assigns the same weight to each particle owned by a
+processor based on the total computational time spent by that
+processor.  See details below on what time window is used.  It uses
+the same timing information as is used for the "MPI task timing
+breakdown"_Section_start.html#start_8, namely, for sections {Pair},
+{Bond}, {Kspace}, and {Neigh}.  The time spent in those portions of
+the timestep are measured for each MPI rank, summed, then divided by
+the number of particles owned by that processor.  I.e. the weight is
+an effective CPU time/particle averaged over the particles on that
+processor.
+
+The {factor} setting is applied as an overall scale factor to the
+{time} weights which allows adjustment of their impact on the
+balancing operation.  The specified {factor} value must be positive.
+A value > 1.0 will increase the weights so that the ratio of max
+weight to min weight increases by {factor}.  A value < 1.0 will
+decrease the weights so that the ratio of max weight to min weight
+decreases by {factor}.  In both cases the intermediate weight values
+increase/decrease proportionally as well.  A value = 1.0 has no effect
+on the {time} weights.  As a rule of thumb, effective values to use
+are typicall between 0.5 and 1.2.  Note that the timer quantities
+mentioned above can be affected by communication which occurs in the
+middle of the operations, e.g. pair styles with intermediate exchange
+of data witin the force computation, and likewise for KSpace solves.
+
+When using the {time} weight style with the {balance} command, the
+timing data is taken from the preceding run command, i.e. the timings
+are for the entire previous run.  For the {fix balance} command the
+timing data is for only the timesteps since the last balancing
+operation was performed.  If timing information for the required
+sections is not available, e.g. at the beginning of a run, or when the
+"timer"_timer.html command is set to either {loop} or {off}, a warning
+is issued.  In this case no weights are computed.
+
+NOTE: The {time} weight style is the most generic option, and should
+be tried first, unless the {group} style is easily applicable.
+However, since the computed cost function is averaged over all
+particles on a processor, the weights may not be highly accurate.
+This style can also be effective as a secondary weight in combination
+with either {group} or {neigh} to offset some of inaccuracies in
+either of those heuristics.
+
+The {var} weight style assigns per-particle weights by evaluating an
+"atom-style variable"_variable.html specified by {name}.  This is
+provided as a more flexible alternative to the {group} weight style,
+allowing definition of a more complex heuristics based on information
+(global and per atom) available inside of LAMMPS.  For example,
+atom-style variables can reference the position of a particle, its
+velocity, the volume of its Voronoi cell, etc.
+
+The {store} weight style does not compute a weight factor.  Instead it
+stores the current accumulated weights in a custom per-atom property
+specified by {name}.  This must be a property defined as {d_name} via
+the "fix property/atom"_fix_property_atom.html command.  Note that
+these custom per-atom properties can be output in a "dump"_dump.html
+file, so this is a way to examine, debug, or visualize the
+per-particle weights computed during the load-balancing operation.
 
 :line
 
@@ -328,7 +490,7 @@ per processor.  Note that the 4 sub-domains share vertices, so there
 will be duplicate nodes in the list.
 
 The "SQUARES" section lists the node IDs of the 4 vertices in a
-rectangle for each processor (1 to 4).  
+rectangle for each processor (1 to 4).
 
 For a 3d problem, the syntax is similar with 8 vertices listed for
 each processor, instead of 4, and "SQUARES" replaced by "CUBES".
@@ -342,6 +504,7 @@ appear in {dimstr} for the {shift} style.
 
 [Related commands:]
 
-"processors"_processors.html, "fix balance"_fix_balance.html
+"group"_group.html, "processors"_processors.html,
+"fix balance"_fix_balance.html
 
 [Default:] none

doc/src/body.txt

@@ -125,7 +125,7 @@ in the {Bodies} section of the data file:
 
 atom-ID 1 M
 N
-ixx iyy izz ixy ixz iyz 
+ixx iyy izz ixy ixz iyz
 x1 y1 z1
 ...
 xN yN zN :pre
@@ -198,11 +198,11 @@ in the {Bodies} section of the data file:
 
 atom-ID 1 M
 N
-ixx iyy izz ixy ixz iyz 
+ixx iyy izz ixy ixz iyz
 x1 y1 z1
 ...
 xN yN zN
-i j j k k ... 
+i j j k k ...
 radius :pre
 
 N is the number of vertices in the body particle.  M = 6 + 3*N + 2*N +
@@ -230,11 +230,11 @@ particles whose edge length is sqrt(2):
 
 3 1 27
 4
-1 1 4 0 0 0 
--0.7071 -0.7071 0 
--0.7071 0.7071 0 
-0.7071 0.7071 0 
-0.7071 -0.7071 0 
+1 1 4 0 0 0
+-0.7071 -0.7071 0
+-0.7071 0.7071 0
+0.7071 0.7071 0
+0.7071 -0.7071 0
 0 1 1 2 2 3 3 0
 1.0 :pre
 

doc/src/bond_fene.txt

@@ -70,10 +70,10 @@ more instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 
 This bond style can only be used if LAMMPS was built with the
-MOLECULE package (which it is by default).  See the "Making
+MOLECULE package.  See the "Making
 LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
-You typically should specify "special_bonds fene"_special_bonds.html"
+You typically should specify "special_bonds fene"_special_bonds.html
 or "special_bonds lj/coul 0 1 1"_special_bonds.html to use this bond
 style.  LAMMPS will issue a warning it that's not the case.
 

doc/src/bond_fene_expand.txt

@@ -73,10 +73,10 @@ more instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 
 This bond style can only be used if LAMMPS was built with the
-MOLECULE package (which it is by default).  See the "Making
+MOLECULE package.  See the "Making
 LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
-You typically should specify "special_bonds fene"_special_bonds.html"
+You typically should specify "special_bonds fene"_special_bonds.html
 or "special_bonds lj/coul 0 1 1"_special_bonds.html to use this bond
 style.  LAMMPS will issue a warning it that's not the case.
 

doc/src/bond_harmonic.txt

@@ -65,7 +65,7 @@ more instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 
 This bond style can only be used if LAMMPS was built with the
-MOLECULE package (which it is by default).  See the "Making
+MOLECULE package.  See the "Making
 LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]

doc/src/bond_hybrid.txt

@@ -59,7 +59,7 @@ bond types.
 [Restrictions:]
 
 This bond style can only be used if LAMMPS was built with the
-MOLECULE package (which it is by default).  See the "Making
+MOLECULE package.  See the "Making
 LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 Unlike other bond styles, the hybrid bond style does not store bond

doc/src/bond_morse.txt

@@ -64,7 +64,7 @@ more instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 
 This bond style can only be used if LAMMPS was built with the
-MOLECULE package (which it is by default).  See the "Making
+MOLECULE package.  See the "Making
 LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]

doc/src/bond_nonlinear.txt

@@ -64,7 +64,7 @@ more instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 
 This bond style can only be used if LAMMPS was built with the
-MOLECULE package (which it is by default).  See the "Making
+MOLECULE package.  See the "Making
 LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]

doc/src/bond_quartic.txt

@@ -99,7 +99,7 @@ more instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 
 This bond style can only be used if LAMMPS was built with the
-MOLECULE package (which it is by default).  See the "Making
+MOLECULE package.  See the "Making
 LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 The {quartic} style requires that "special_bonds"_special_bonds.html

doc/src/bond_table.txt

@@ -144,7 +144,7 @@ more instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 
 This bond style can only be used if LAMMPS was built with the
-MOLECULE package (which it is by default).  See the "Making
+MOLECULE package.  See the "Making
 LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]

doc/src/change_box.txt

@@ -173,7 +173,7 @@ change_box all x scale 1.1 y volume z volume :pre
 
 The {volume} style changes the associated dimension so that the
 overall box volume is unchanged relative to its value before the
-preceding keyword was invoked. 
+preceding keyword was invoked.
 
 If the following command is used, then the z box length will shrink by
 the same 1.1 factor the x box length was increased by:

doc/src/comm_modify.txt

@@ -135,7 +135,7 @@ and angular momentum of a particle.  If the {vel} option is set to
 {yes}, then ghost atoms store these quantities; if {no} then they do
 not.  The {yes} setting is needed by some pair styles which require
 the velocity state of both the I and J particles to compute a pairwise
-I,J interaction.
+I,J interaction, as well as by some compute and fix commands.
 
 Note that if the "fix deform"_fix_deform.html command is being used
 with its "remap v" option enabled, then the velocities for ghost atoms

doc/src/commands.txt

@@ -37,6 +37,7 @@ Commands :h1
    dump_image
    dump_modify
    dump_molfile
+   dump_nc
    echo
    fix
    fix_modify

doc/src/compute_centro_atom.txt

@@ -114,7 +114,7 @@ local defects surrounding the central atom, as described above.  For
 the {axes yes} case, the vector components are also unitless, since
 they represent spatial directions.
 
-Here are typical centro-symmetry values, from a a nanoindentation
+Here are typical centro-symmetry values, from a nanoindentation
 simulation into gold (FCC).  These were provided by Jon Zimmerman
 (Sandia):
 

doc/src/compute_chunk_atom.txt

@@ -536,7 +536,7 @@ For the {bin/cylinder} style the details are as follows.  If {discard}
 is set to {yes}, an out-of-domain atom will have its chunk ID set to
 0.  If {discard} is set to {no}, the atom will have its chunk ID set
 to the first or last bin in both the radial and axis dimensions.  If
-{discard} is set to {mixed}, which is the default, the the radial
+{discard} is set to {mixed}, which is the default, the radial
 dimension is treated the same as for {discard} = no.  But for the axis
 dimensinon, it will only have its chunk ID set to the first or last
 bin if bins extend to the simulation box boundary in the axis

doc/src/compute_cna_atom.txt

@@ -13,7 +13,7 @@ compute cna/atom command :h3
 compute ID group-ID cna/atom cutoff :pre
 
 ID, group-ID are documented in "compute"_compute.html command
-cna/atom = style name of this compute command 
+cna/atom = style name of this compute command
 cutoff = cutoff distance for nearest neighbors (distance units) :ul
 
 [Examples:]

doc/src/compute_dilatation_atom.txt

@@ -63,4 +63,4 @@ LAMMPS"_Section_start.html#start_3 section for more info.
 "compute damage/atom"_compute_damage_atom.html,
 "compute plasticity/atom"_compute_plasticity_atom.html
 
-[Default:] none 
+[Default:] none

doc/src/compute_dipole_chunk.txt

@@ -19,7 +19,7 @@ charge-correction = {mass} or {geometry}, use COM or geometric center for charge
 
 [Examples:]
 
-compute 1 fluid dipole/chunk molchunk 
+compute 1 fluid dipole/chunk molchunk
 compute dw water dipole/chunk 1 geometry :pre
 
 [Description:]

doc/src/compute_dpd.txt

@@ -46,7 +46,7 @@ output options.
 
 The vector values will be in energy and temperature "units"_units.html.
 
-[Restrictions:] 
+[Restrictions:]
 
 This command is part of the USER-DPD package.  It is only enabled if
 LAMMPS was built with that package.  See the "Making
@@ -64,7 +64,7 @@ command.
 
 :line
 
-:link(Larentzos) 
+:link(Larentzos)
 [(Larentzos)] J.P. Larentzos, J.K. Brennan, J.D. Moore, and
 W.D. Mattson, "LAMMPS Implementation of Constant Energy Dissipative
 Particle Dynamics (DPD-E)", ARL-TR-6863, U.S. Army Research

doc/src/compute_dpd_atom.txt

@@ -22,7 +22,7 @@ compute 1 all dpd/atom
 [Description:]
 
 Define a computation that accesses the per-particle internal
-conductive energy (u_cond), internal mechanical energy (u_mech), 
+conductive energy (u_cond), internal mechanical energy (u_mech),
 internal chemical energy (u_chem) and
 internal temperatures (dpdTheta) for each particle in a group.  See
 the "compute dpd"_compute_dpd.html command if you want the total
@@ -39,10 +39,10 @@ that uses per-particle values from a compute as input.  See
 "Section 6.15"_Section_howto.html#howto_15 for an overview of
 LAMMPS output options.
 
-The per-particle array values will be in energy (u_cond, u_mech, u_chem) 
+The per-particle array values will be in energy (u_cond, u_mech, u_chem)
 and temperature (dpdTheta) "units"_units.html.
 
-[Restrictions:] 
+[Restrictions:]
 
 This command is part of the USER-DPD package.  It is only enabled if
 LAMMPS was built with that package.  See the "Making

doc/src/compute_event_displace.txt

@@ -26,7 +26,7 @@ Define a computation that flags an "event" if any particle in the
 group has moved a distance greater than the specified threshold
 distance when compared to a previously stored reference state
 (i.e. the previous event).  This compute is typically used in
-conjunction with the "prd"_prd.html and "tad"_tad.html commands, 
+conjunction with the "prd"_prd.html and "tad"_tad.html commands,
 to detect if a transition
 to a new minimum energy basin has occurred.
 
@@ -34,8 +34,8 @@ This value calculated by the compute is equal to 0 if no particle has
 moved far enough, and equal to 1 if one or more particles have moved
 further than the threshold distance.
 
-NOTE: If the system is undergoing significant center-of-mass motion, 
-due to thermal motion, an external force, or an initial net momentum, 
+NOTE: If the system is undergoing significant center-of-mass motion,
+due to thermal motion, an external force, or an initial net momentum,
 then this compute will not be able to distinguish that motion from
 local atom displacements and may generate "false postives."
 

doc/src/compute_fep.txt

@@ -64,7 +64,7 @@ these atoms:
 A coupling parameter \(\lambda\) varying from 0 to 1 connects the
 reference and perturbed systems:
 
-:c,image(Eqs/compute_fep_lambda.jpg) 
+:c,image(Eqs/compute_fep_lambda.jpg)
 
 It is possible but not necessary that the coupling parameter (or a
 function thereof) appears as a multiplication factor of the potential
@@ -236,7 +236,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.
 [Related commands:]
 
 "fix adapt/fep"_fix_adapt_fep.html, "fix ave/time"_fix_ave_time.html,
-"pair_lj_soft_coul_soft"_pair_lj_soft_coul_soft.txt
+"pair_style lj/soft/coul/soft"_pair_lj_soft.html
 
 [Default:]
 

doc/src/compute_gyration_chunk.txt

@@ -28,7 +28,7 @@ compute 2 molecule gyration/chunk molchunk tensor :pre
 [Description:]
 
 Define a computation that calculates the radius of gyration Rg for
-multiple chunks of atoms. 
+multiple chunks of atoms.
 
 In LAMMPS, chunks are collections of atoms defined by a "compute
 chunk/atom"_compute_chunk_atom.html command, which assigns each atom

doc/src/compute_heat_flux.txt

@@ -20,7 +20,7 @@ stress-ID = ID of a compute that calculates per-atom stress :ul
 
 [Examples:]
 
-compute myFlux all heat/flux myKE myPE myStress :pre 
+compute myFlux all heat/flux myKE myPE myStress :pre
 
 [Description:]
 
@@ -38,7 +38,7 @@ subtracted to a group of atoms.
 The compute takes three arguments which are IDs of other
 "computes"_compute.html.  One calculates per-atom kinetic energy
 ({ke-ID}), one calculates per-atom potential energy ({pe-ID)}, and the
-third calcualtes per-atom stress ({stress-ID}).  
+third calcualtes per-atom stress ({stress-ID}).
 
 NOTE: These other computes should provide values for all the atoms in
 the group this compute specifies.  That means the other computes could
@@ -152,11 +152,11 @@ lattice      fcc 5.376 orient x 1 0 0 orient y 0 1 0 orient z 0 0 1
 region       box block 0 4 0 4 0 4
 create_box   1 box
 create_atoms 1 box
-mass	     1 39.948
+mass         1 39.948
 pair_style   lj/cut 13.0
 pair_coeff   * * 0.2381 3.405
 timestep     $\{dt\}
-thermo	     $d :pre
+thermo       $d :pre
 
 # equilibration and thermalization :pre
 

doc/src/compute_hexorder_atom.txt

@@ -15,7 +15,7 @@ compute ID group-ID hexorder/atom keyword values ... :pre
 ID, group-ID are documented in "compute"_compute.html command :ulb,l
 hexorder/atom = style name of this compute command :l
 one or more keyword/value pairs may be appended :l
-keyword = {degree} or {nnn} or {cutoff} 
+keyword = {degree} or {nnn} or {cutoff}
   {cutoff} value = distance cutoff
   {nnn} value = number of nearest neighbors
   {degree} value = degree {n} of order parameter :pre
@@ -24,27 +24,27 @@ keyword = {degree} or {nnn} or {cutoff}
 
 [Examples:]
 
-compute 1 all hexorder/atom 
+compute 1 all hexorder/atom
 compute 1 all hexorder/atom degree 4 nnn 4 cutoff 1.2 :pre
 
 [Description:]
 
-Define a computation that calculates {qn} the bond-orientational 
-order parameter for each atom in a group. The hexatic ({n} = 6) order 
+Define a computation that calculates {qn} the bond-orientational
+order parameter for each atom in a group. The hexatic ({n} = 6) order
 parameter was introduced by "Nelson and Halperin"_#Nelson as a way to detect
-hexagonal symmetry in two-dimensional systems. For each atom, {qn} 
+hexagonal symmetry in two-dimensional systems. For each atom, {qn}
 is a complex number (stored as two real numbers) defined as follows:
 
 :c,image(Eqs/hexorder.jpg)
 
-where the sum is over the {nnn} nearest neighbors 
+where the sum is over the {nnn} nearest neighbors
 of the central atom. The angle theta
 is formed by the bond vector rij and the {x} axis. theta is calculated
 only using the {x} and {y} components, whereas the distance from the
-central atom is calculated using all three  
+central atom is calculated using all three
 {x}, {y}, and {z} components of the bond vector.
-Neighbor atoms not in the group 
-are included in the order parameter of atoms in the group. 
+Neighbor atoms not in the group
+are included in the order parameter of atoms in the group.
 
 The optional keyword {cutoff} defines the distance cutoff
 used when searching for neighbors. The default value, also
@@ -53,22 +53,22 @@ by the pair style.
 
 The optional keyword {nnn} defines the number of nearest
 neighbors used to calculate {qn}. The default value is 6.
-If the value is NULL, then all neighbors up to the 
+If the value is NULL, then all neighbors up to the
 distance cutoff are used.
 
-The optional keyword {degree} sets the degree {n} of the order parameter. 
-The default value is 6. For a perfect hexagonal lattice with 
+The optional keyword {degree} sets the degree {n} of the order parameter.
+The default value is 6. For a perfect hexagonal lattice with
 {nnn} = 6,
-{q}6 = exp(6 i phi) for all atoms, where the constant 0 < phi < pi/3 
-depends only on the orientation of the lattice relative to the {x} axis.  
-In an isotropic liquid, local neighborhoods may still exhibit 
+{q}6 = exp(6 i phi) for all atoms, where the constant 0 < phi < pi/3
+depends only on the orientation of the lattice relative to the {x} axis.
+In an isotropic liquid, local neighborhoods may still exhibit
 weak hexagonal symmetry, but because the orientational correlation
 decays quickly with distance, the value of phi will be different for
-different atoms, and so when {q}6 is averaged over all the atoms 
+different atoms, and so when {q}6 is averaged over all the atoms
 in the system, \|<{q}6>\| << 1.
 
 The value of {qn} is set to zero for atoms not in the
-specified compute group, as well as for atoms that have less than 
+specified compute group, as well as for atoms that have less than
 {nnn} neighbors within the distance cutoff.
 
 The neighbor list needed to compute this quantity is constructed each
@@ -92,7 +92,7 @@ the neighbor list.
 [Output info:]
 
 This compute calculates a per-atom array with 2 columns, giving the
-real and imaginary parts {qn}, a complex number restricted to the 
+real and imaginary parts {qn}, a complex number restricted to the
 unit disk of the complex plane i.e. Re({qn})^2 + Im({qn})^2 <= 1 .
 
 These values can be accessed by any command that uses
@@ -106,7 +106,7 @@ options.
 
 "compute orientorder/atom"_compute_orientorder_atom.html, "compute coord/atom"_compute_coord_atom.html, "compute centro/atom"_compute_centro_atom.html
 
-[Default:] 
+[Default:]
 
 The option defaults are {cutoff} = pair style cutoff, {nnn} = 6, {degree} = 6
 

doc/src/compute_inertia_chunk.txt

@@ -23,7 +23,7 @@ compute 1 fluid inertia/chunk molchunk :pre
 [Description:]
 
 Define a computation that calculates the inertia tensor for multiple
-chunks of atoms. 
+chunks of atoms.
 
 In LAMMPS, chunks are collections of atoms defined by a "compute
 chunk/atom"_compute_chunk_atom.html command, which assigns each atom