Stan bug fixes for fix reaxc/bonds/kk

pair styles born/coul/dsf and born/coul/dsf/cs added

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
+Performance: 106050.541 tau/day, 102.286 timesteps/s
-100.0% CPU use with 1 MPI tasks x no OpenMP threads
+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
+Pair    | 0.19421    | 0.19421    | 0.19421    |   0.0 | 19.86
-Bond    | 0.087475   | 0.087475   | 0.087475   |   0.0 |  8.94
+Bond    | 0.08741    | 0.08741    | 0.08741    |   0.0 |  8.94
-Neigh   | 0.44861    | 0.44861    | 0.44861    |   0.0 | 45.84
+Neigh   | 0.45791    | 0.45791    | 0.45791    |   0.0 | 46.84
-Comm    | 0.032932   | 0.032932   | 0.032932   |   0.0 |  3.37
+Comm    | 0.032649   | 0.032649   | 0.032649   |   0.0 |  3.34
-Output  | 0.00010395 | 0.00010395 | 0.00010395 |   0.0 |  0.01
+Output  | 0.00012207 | 0.00012207 | 0.00012207 |   0.0 |  0.01
-Modify  | 0.19413    | 0.19413    | 0.19413    |   0.0 | 19.84
+Modify  | 0.18071    | 0.18071    | 0.18071    |   0.0 | 18.48
-Other   |            | 0.01972    |            |       |  2.02
+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
+Performance: 385133.446 tau/day, 371.464 timesteps/s
-99.6% CPU use with 4 MPI tasks x no OpenMP threads
+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
+Pair    | 0.049383   | 0.049756   | 0.049988   |   0.1 | 18.48
-Bond    | 0.022254   | 0.022942   | 0.023567   |   0.3 |  8.46
+Bond    | 0.022701   | 0.022813   | 0.022872   |   0.0 |  8.47
-Neigh   | 0.11873    | 0.11881    | 0.11887    |   0.0 | 43.81
+Neigh   | 0.11982    | 0.12002    | 0.12018    |   0.0 | 44.58
-Comm    | 0.019066   | 0.021357   | 0.024297   |   1.3 |  7.88
+Comm    | 0.020274   | 0.021077   | 0.022348   |   0.5 |  7.83
-Output  | 5.0068e-05 | 5.5015e-05 | 6.1035e-05 |   0.1 |  0.02
+Output  | 5.3167e-05 | 5.6148e-05 | 6.3181e-05 |   0.1 |  0.02
-Modify  | 0.048737   | 0.050198   | 0.051231   |   0.4 | 18.51
+Modify  | 0.046276   | 0.046809   | 0.047016   |   0.1 | 17.39
-Other   |            | 0.007751   |            |       |  2.86
+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
+Performance: 90277.919 tau/day, 87.074 timesteps/s
-99.8% CPU use with 4 MPI tasks x no OpenMP threads
+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
+Pair    | 0.2203     | 0.22207    | 0.22386    |   0.3 | 19.34
-Bond    | 0.094536   | 0.10196    | 0.10534    |   1.4 |  8.43
+Bond    | 0.094861   | 0.095302   | 0.095988   |   0.1 |  8.30
-Neigh   | 0.52311    | 0.52392    | 0.52519    |   0.1 | 43.34
+Neigh   | 0.52127    | 0.5216     | 0.52189    |   0.0 | 45.42
-Comm    | 0.090161   | 0.10022    | 0.12557    |   4.7 |  8.29
+Comm    | 0.079585   | 0.082159   | 0.084366   |   0.7 |  7.15
-Output  | 0.00012207 | 0.00017327 | 0.00019598 |   0.2 |  0.01
+Output  | 0.00013304 | 0.00015306 | 0.00018501 |   0.2 |  0.01
-Modify  | 0.19662    | 0.20262    | 0.20672    |   0.8 | 16.76
+Modify  | 0.18351    | 0.18419    | 0.1856     |   0.2 | 16.04
-Other   |            | 0.04694    |            |       |  3.88
+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
+Memory usage per processor = 16.0904 Mbytes
-Step Atoms KinEng 1 Volume 
+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
+Performance: 1617.451 tau/day, 187.205 timesteps/s
-100.1% CPU use with 1 MPI tasks x no OpenMP threads
+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
+Pair    | 0.33346    | 0.33346    | 0.33346    |   0.0 | 62.43
-Neigh   | 0.040353   | 0.040353   | 0.040353   |   0.0 |  7.33
+Neigh   | 0.043902   | 0.043902   | 0.043902   |   0.0 |  8.22
-Comm    | 0.018023   | 0.018023   | 0.018023   |   0.0 |  3.27
+Comm    | 0.018391   | 0.018391   | 0.018391   |   0.0 |  3.44
-Output  | 0.00020385 | 0.00020385 | 0.00020385 |   0.0 |  0.04
+Output  | 0.00022411 | 0.00022411 | 0.00022411 |   0.0 |  0.04
-Modify  | 0.13155    | 0.13155    | 0.13155    |   0.0 | 23.90
+Modify  | 0.11666    | 0.11666    | 0.11666    |   0.0 | 21.84
-Other   |            | 0.02186    |            |       |  3.97
+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
+Memory usage per processor = 7.04927 Mbytes
-Step Atoms KinEng 1 Volume 
+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
+Performance: 5028.653 tau/day, 582.020 timesteps/s
-99.3% CPU use with 4 MPI tasks x no OpenMP threads
+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
+Pair    | 0.093691   | 0.096898   | 0.10005    |   0.8 | 56.40
-Neigh   | 0.010041   | 0.0101     | 0.010178   |   0.1 |  7.69
+Neigh   | 0.011976   | 0.012059   | 0.012146   |   0.1 |  7.02
-Comm    | 0.012347   | 0.012895   | 0.013444   |   0.5 |  9.81
+Comm    | 0.016384   | 0.017418   | 0.018465   |   0.8 | 10.14
-Output  | 6.3896e-05 | 0.00010294 | 0.00014091 |   0.3 |  0.08
+Output  | 7.7963e-05 | 0.00010747 | 0.00013304 |   0.2 |  0.06
-Modify  | 0.031802   | 0.032348   | 0.032897   |   0.3 | 24.62
+Modify  | 0.031744   | 0.031943   | 0.032167   |   0.1 | 18.59
-Other   |            | 0.008965   |            |       |  6.82
+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
+Memory usage per processor = 16.1265 Mbytes
-Step Atoms KinEng 1 Volume 
+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
+Performance: 1038.006 tau/day, 120.140 timesteps/s
-99.7% CPU use with 4 MPI tasks x no OpenMP threads
+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
+Pair    | 0.5178     | 0.52208    | 0.52793    |   0.5 | 62.72
-Neigh   | 0.042597   | 0.043726   | 0.045801   |   0.6 |  4.82
+Neigh   | 0.047003   | 0.047113   | 0.047224   |   0.0 |  5.66
-Comm    | 0.063027   | 0.064657   | 0.067367   |   0.7 |  7.13
+Comm    | 0.05233    | 0.052988   | 0.053722   |   0.2 |  6.37
-Output  | 0.00024891 | 0.00059718 | 0.00086498 |   1.0 |  0.07
+Output  | 0.00024986 | 0.00032717 | 0.00036693 |   0.3 |  0.04
-Modify  | 0.16508    | 0.17656    | 0.1925     |   2.6 | 19.47
+Modify  | 0.15517    | 0.15627    | 0.15808    |   0.3 | 18.77
-Other   |            | 0.09043    |            |       |  9.97
+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
+Pair    | 5.2743     | 5.2743     | 5.2743     |   0.0 | 88.42
-Neigh   | 0.58212    | 0.58212    | 0.58212    |   0.0 |  9.86
+Neigh   | 0.59212    | 0.59212    | 0.59212    |   0.0 |  9.93
-Comm    | 0.030392   | 0.030392   | 0.030392   |   0.0 |  0.52
+Comm    | 0.030399   | 0.030399   | 0.030399   |   0.0 |  0.51
-Output  | 0.00023389 | 0.00023389 | 0.00023389 |   0.0 |  0.00
+Output  | 0.00026202 | 0.00026202 | 0.00026202 |   0.0 |  0.00
-Modify  | 0.060871   | 0.060871   | 0.060871   |   0.0 |  1.03
+Modify  | 0.050487   | 0.050487   | 0.050487   |   0.0 |  0.85
-Other   |            | 0.01527    |            |       |  0.26
+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
+Pair    | 1.408      | 1.4175     | 1.4341     |   0.9 | 86.14
-Neigh   | 0.15123    | 0.15232    | 0.15374    |   0.2 |  9.64
+Neigh   | 0.15512    | 0.15722    | 0.16112    |   0.6 |  9.55
-Comm    | 0.033429   | 0.041275   | 0.047066   |   2.7 |  2.61
+Comm    | 0.029105   | 0.049986   | 0.061822   |   5.8 |  3.04
-Output  | 0.00011301 | 0.0001573  | 0.000211   |   0.3 |  0.01
+Output  | 0.00010991 | 0.00011539 | 0.00012302 |   0.0 |  0.01
-Modify  | 0.014694   | 0.015085   | 0.015421   |   0.2 |  0.95
+Modify  | 0.013383   | 0.013573   | 0.013883   |   0.2 |  0.82
-Other   |            | 0.005342   |            |       |  0.34
+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
+Pair    | 5.6676     | 5.7011     | 5.7469     |   1.3 | 86.36
-Neigh   | 0.65287    | 0.658      | 0.66374    |   0.5 | 10.17
+Neigh   | 0.66423    | 0.67119    | 0.68082    |   0.7 | 10.17
-Comm    | 0.075706   | 0.11015    | 0.13655    |   7.2 |  1.70
+Comm    | 0.079367   | 0.13668    | 0.1791     |  10.5 |  2.07
-Output  | 0.00026488 | 0.00028312 | 0.00029302 |   0.1 |  0.00
+Output  | 0.00026989 | 0.00028622 | 0.00031209 |   0.1 |  0.00
-Modify  | 0.069607   | 0.072407   | 0.074555   |   0.7 |  1.12
+Modify  | 0.060046   | 0.062203   | 0.065009   |   0.9 |  0.94
-Other   |            | 0.02794    |            |       |  0.43
+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
+Pair    | 1.9328     | 1.9328     | 1.9328     |   0.0 | 85.45
-Neigh   | 0.2442     | 0.2442     | 0.2442     |   0.0 | 10.79
+Neigh   | 0.2558     | 0.2558     | 0.2558     |   0.0 | 11.31
-Comm    | 0.024158   | 0.024158   | 0.024158   |   0.0 |  1.07
+Comm    | 0.024061   | 0.024061   | 0.024061   |   0.0 |  1.06
-Output  | 0.00011611 | 0.00011611 | 0.00011611 |   0.0 |  0.01
+Output  | 0.00012612 | 0.00012612 | 0.00012612 |   0.0 |  0.01
-Modify  | 0.053222   | 0.053222   | 0.053222   |   0.0 |  2.35
+Modify  | 0.040887   | 0.040887   | 0.040887   |   0.0 |  1.81
-Other   |            | 0.007258   |            |       |  0.32
+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
+Performance: 67929.172 tau/day, 157.243 timesteps/s
-99.7% CPU use with 4 MPI tasks x no OpenMP threads
+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
+Pair    | 0.51335    | 0.51822    | 0.52569    |   0.7 | 81.49
-Neigh   | 0.061131   | 0.063685   | 0.065433   |   0.6 |  9.94
+Neigh   | 0.063695   | 0.064309   | 0.065397   |   0.3 | 10.11
-Comm    | 0.02457    | 0.042349   | 0.069598   |   8.1 |  6.61
+Comm    | 0.027525   | 0.03629    | 0.041959   |   3.1 |  5.71
-Output  | 5.9843e-05 | 6.3181e-05 | 6.6996e-05 |   0.0 |  0.01
+Output  | 6.3896e-05 | 6.6698e-05 | 7.081e-05  |   0.0 |  0.01
-Modify  | 0.012961   | 0.013863   | 0.014491   |   0.5 |  2.16
+Modify  | 0.012472   | 0.01254    | 0.012618   |   0.1 |  1.97
-Other   |            | 0.003448   |            |       |  0.54
+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
+Pair    | 2.0583     | 2.0988     | 2.1594     |   2.6 | 82.06
-Neigh   | 0.23982    | 0.24551    | 0.25233    |   1.0 |  9.52
+Neigh   | 0.24411    | 0.24838    | 0.25585    |   0.9 |  9.71
-Comm    | 0.067088   | 0.13887    | 0.22681    |  15.7 |  5.38
+Comm    | 0.066397   | 0.13872    | 0.1863     |  11.9 |  5.42
-Output  | 0.00013185 | 0.00021666 | 0.00027108 |   0.4 |  0.01
+Output  | 0.00012994 | 0.00021023 | 0.00025702 |   0.3 |  0.01
-Modify  | 0.060348   | 0.071269   | 0.077063   |   2.5 |  2.76
+Modify  | 0.055533   | 0.058343   | 0.061791   |   1.2 |  2.28
-Other   |            | 0.01403    |            |       |  0.54
+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) ----------------
+---------------- Step       50 ----- CPU =     17.2007 (sec) ----------------
-TotEng   =    -25330.0828 KinEng   =     21501.0029 Temp     =       299.8230 
+TotEng   =    -25330.0321 KinEng   =     21501.0036 Temp     =       299.8230 
-PotEng   =    -46831.0857 E_bond   =      2471.7004 E_angle  =     10836.4975 
+PotEng   =    -46831.0357 E_bond   =      2471.7033 E_angle  =     10836.5108 
-E_dihed  =      5239.6299 E_impro  =       227.1218 E_vdwl   =     -1993.2754 
+E_dihed  =      5239.6316 E_impro  =       227.1219 E_vdwl   =     -1993.2763 
-E_coul   =    206797.6331 E_long   =   -270410.3930 Press    =       237.6701 
+E_coul   =    206797.6655 E_long   =   -270410.3927 Press    =       237.6866 
-Volume   =    308031.5639 
+Volume   =    308031.5640 
----------------- Step      100 ----- CPU =     35.9089 (sec) ----------------
+---------------- Step      100 ----- CPU =     35.0315 (sec) ----------------
-TotEng   =    -25290.7593 KinEng   =     21592.0117 Temp     =       301.0920 
+TotEng   =    -25290.7387 KinEng   =     21591.9096 Temp     =       301.0906 
-PotEng   =    -46882.7709 E_bond   =      2567.9807 E_angle  =     10781.9408 
+PotEng   =    -46882.6484 E_bond   =      2567.9789 E_angle  =     10781.9556 
-E_dihed  =      5198.7432 E_impro  =       216.7834 E_vdwl   =     -1902.4783 
+E_dihed  =      5198.7493 E_impro  =       216.7863 E_vdwl   =     -1902.6458 
-E_coul   =    206659.2326 E_long   =   -270404.9733 Press    =         6.9960 
+E_coul   =    206659.5006 E_long   =   -270404.9733 Press    =         6.7898 
-Volume   =    308133.9888 
+Volume   =    308133.9933 
-Loop time of 35.9089 on 1 procs for 100 steps with 32000 atoms
+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
+Pair    | 25.021     | 25.021     | 25.021     |   0.0 | 71.42
-Bond    | 1.2771     | 1.2771     | 1.2771     |   0.0 |  3.56
+Bond    | 1.2834     | 1.2834     | 1.2834     |   0.0 |  3.66
-Kspace  | 3.2094     | 3.2094     | 3.2094     |   0.0 |  8.94
+Kspace  | 3.2116     | 3.2116     | 3.2116     |   0.0 |  9.17
-Neigh   | 4.4538     | 4.4538     | 4.4538     |   0.0 | 12.40
+Neigh   | 4.2767     | 4.2767     | 4.2767     |   0.0 | 12.21
-Comm    | 0.068507   | 0.068507   | 0.068507   |   0.0 |  0.19
+Comm    | 0.069283   | 0.069283   | 0.069283   |   0.0 |  0.20
-Output  | 0.00025916 | 0.00025916 | 0.00025916 |   0.0 |  0.00
+Output  | 0.00028205 | 0.00028205 | 0.00028205 |   0.0 |  0.00
-Modify  | 1.1417     | 1.1417     | 1.1417     |   0.0 |  3.18
+Modify  | 1.14       | 1.14       | 1.14       |   0.0 |  3.25
-Other   |            | 0.027      |            |       |  0.08
+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) ----------------
+---------------- Step       50 ----- CPU =      4.6056 (sec) ----------------
-TotEng   =    -25330.0828 KinEng   =     21501.0029 Temp     =       299.8230 
+TotEng   =    -25330.0321 KinEng   =     21501.0036 Temp     =       299.8230 
-PotEng   =    -46831.0857 E_bond   =      2471.7004 E_angle  =     10836.4975 
+PotEng   =    -46831.0357 E_bond   =      2471.7033 E_angle  =     10836.5108 
-E_dihed  =      5239.6299 E_impro  =       227.1218 E_vdwl   =     -1993.2754 
+E_dihed  =      5239.6316 E_impro  =       227.1219 E_vdwl   =     -1993.2763 
-E_coul   =    206797.6331 E_long   =   -270410.3930 Press    =       237.6701 
+E_coul   =    206797.6655 E_long   =   -270410.3927 Press    =       237.6866 
-Volume   =    308031.5639 
+Volume   =    308031.5640 
----------------- Step      100 ----- CPU =      9.6332 (sec) ----------------
+---------------- Step      100 ----- CPU =      9.3910 (sec) ----------------
-TotEng   =    -25290.7591 KinEng   =     21592.0117 Temp     =       301.0920 
+TotEng   =    -25290.7386 KinEng   =     21591.9096 Temp     =       301.0906 
-PotEng   =    -46882.7708 E_bond   =      2567.9807 E_angle  =     10781.9408 
+PotEng   =    -46882.6482 E_bond   =      2567.9789 E_angle  =     10781.9556 
-E_dihed  =      5198.7432 E_impro  =       216.7834 E_vdwl   =     -1902.4783 
+E_dihed  =      5198.7493 E_impro  =       216.7863 E_vdwl   =     -1902.6458 
-E_coul   =    206659.2327 E_long   =   -270404.9733 Press    =         6.9960 
+E_coul   =    206659.5007 E_long   =   -270404.9733 Press    =         6.7898 
-Volume   =    308133.9888 
+Volume   =    308133.9933 
-Loop time of 9.63322 on 4 procs for 100 steps with 32000 atoms
+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
+Performance: 1.840 ns/day, 13.043 hours/ns, 10.648 timesteps/s
-99.9% CPU use with 4 MPI tasks x no OpenMP threads
+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
+Pair    | 6.2189     | 6.3266     | 6.6072     |   6.5 | 67.37
-Bond    | 0.30755    | 0.32435    | 0.35704    |   3.4 |  3.37
+Bond    | 0.30793    | 0.32122    | 0.3414     |   2.4 |  3.42
-Kspace  | 0.92248    | 1.0782     | 1.2597     |  13.0 | 11.19
+Kspace  | 0.87994    | 1.1644     | 1.2855     |  15.3 | 12.40
-Neigh   | 1.1669     | 1.1672     | 1.1675     |   0.0 | 12.12
+Neigh   | 1.1358     | 1.136      | 1.1362     |   0.0 | 12.10
-Comm    | 0.094674   | 0.098065   | 0.10543    |   1.4 |  1.02
+Comm    | 0.08292    | 0.084935   | 0.087077   |   0.5 |  0.90
-Output  | 0.00015521 | 0.00016224 | 0.00018215 |   0.1 |  0.00
+Output  | 0.00015712 | 0.00016558 | 0.00018501 |   0.1 |  0.00
-Modify  | 0.32982    | 0.34654    | 0.35365    |   1.6 |  3.60
+Modify  | 0.33717    | 0.34246    | 0.34794    |   0.7 |  3.65
-Other   |            | 0.01943    |            |       |  0.20
+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) ----------------
+---------------- Step       50 ----- CPU =     18.1689 (sec) ----------------
-TotEng   =   -101320.2677 KinEng   =     86003.4837 Temp     =       299.8118 
+TotEng   =   -101320.0211 KinEng   =     86003.4933 Temp     =       299.8118 
-PotEng   =   -187323.7514 E_bond   =      9887.1072 E_angle  =     43346.7922 
+PotEng   =   -187323.5144 E_bond   =      9887.1189 E_angle  =     43346.8448 
-E_dihed  =     20958.7032 E_impro  =       908.4715 E_vdwl   =     -7973.4457 
+E_dihed  =     20958.7108 E_impro  =       908.4721 E_vdwl   =     -7973.4486 
-E_coul   =    826141.3831 E_long   =  -1080592.7629 Press    =       238.0161 
+E_coul   =    826141.5493 E_long   =  -1080592.7617 Press    =       238.0404 
-Volume   =   1232126.1855 
+Volume   =   1232126.1814 
----------------- Step      100 ----- CPU =     38.3684 (sec) ----------------
+---------------- Step      100 ----- CPU =     37.2027 (sec) ----------------
-TotEng   =   -101158.1849 KinEng   =     86355.6149 Temp     =       301.0393 
+TotEng   =   -101157.9546 KinEng   =     86355.7413 Temp     =       301.0398 
-PotEng   =   -187513.7998 E_bond   =     10272.0693 E_angle  =     43128.6454 
+PotEng   =   -187513.6959 E_bond   =     10272.0456 E_angle  =     43128.7018 
-E_dihed  =     20793.9759 E_impro  =       867.0826 E_vdwl   =     -7586.7186 
+E_dihed  =     20794.0107 E_impro  =       867.0928 E_vdwl   =     -7587.2409 
-E_coul   =    825583.7122 E_long   =  -1080572.5667 Press    =        15.2151 
+E_coul   =    825584.2416 E_long   =  -1080572.5474 Press    =        15.1729 
-Volume   =   1232535.8423 
+Volume   =   1232535.8440 
-Loop time of 38.3684 on 4 procs for 100 steps with 128000 atoms
+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
+Pair    | 25.431     | 25.738     | 25.984     |   4.0 | 69.18
-Bond    | 1.298      | 1.3125     | 1.3277     |   1.0 |  3.42
+Bond    | 1.2966     | 1.3131     | 1.3226     |   0.9 |  3.53
-Kspace  | 3.7099     | 4.0992     | 4.4422     |  13.3 | 10.68
+Kspace  | 3.7563     | 4.0123     | 4.3127     |  10.0 | 10.79
-Neigh   | 4.6137     | 4.6144     | 4.615      |   0.0 | 12.03
+Neigh   | 4.3778     | 4.378      | 4.3782     |   0.0 | 11.77
-Comm    | 0.21398    | 0.21992    | 0.22886    |   1.2 |  0.57
+Comm    | 0.1903     | 0.19549    | 0.20485    |   1.3 |  0.53
-Output  | 0.00030518 | 0.00031543 | 0.00033307 |   0.1 |  0.00
+Output  | 0.00031805 | 0.00037521 | 0.00039601 |   0.2 |  0.00
-Modify  | 1.5066     | 1.5232     | 1.5388     |   1.0 |  3.97
+Modify  | 1.4861     | 1.5051     | 1.5122     |   0.9 |  4.05
-Other   |            | 0.06051    |            |       |  0.16
+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)
+ifeq ($(shell which python3 >/dev/null 2>&1; echo $$?), 0)
-$(error Python3 was not found! Please check README.md for further instructions)
+HAS_PYTHON3 = YES
 endif
 
-ifeq ($(shell which virtualenv >/dev/null 2>&1; echo $$?), 1)
+ifeq ($(shell which virtualenv >/dev/null 2>&1; echo $$?), 0)
-$(error virtualenv was not found! Please check README.md for further instructions)
+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"
@@ -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/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/Manual.txt

@@ -1,7 +1,7 @@
 <!-- HTML_ONLY -->
 <HEAD>
 <TITLE>LAMMPS Users Manual</TITLE>
-<META NAME="docnumber" CONTENT="26 Sep 2016 version">
+<META NAME="docnumber" CONTENT="9 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
-26 Sep 2016 version :c,h4
+9 Nov 2016 version :c,h4
 
 Version info: :h4
 

doc/src/Section_commands.txt

@@ -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
@@ -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
+"next section"_#cmd_5 lists the same commands alphabetically.  The
-that some style options for some commands are part of specific LAMMPS
+next section also includes (long) lists of style options for entries
-packages, which means they cannot be used unless the package was
+that appear in the following categories as a single command (fix,
-included when LAMMPS was built.  Not all packages are included in a
+compute, pair, etc).  Commands that are added by user packages are not
-default LAMMPS build.  These dependencies are listed as Restrictions
+included in these categories, but they are in the next section.
-in the command's documentation.
 
 Initialization:
 
-"atom_modify"_atom_modify.html, "atom_style"_atom_style.html,
+"newton"_newton.html,
-"boundary"_boundary.html, "dimension"_dimension.html,
+"package"_package.html,
-"newton"_newton.html, "processors"_processors.html, "units"_units.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,
+"boundary"_boundary.html,
-"lattice"_lattice.html, "read_data"_read_data.html,
+"box"_box.html,
-"read_dump"_read_dump.html, "read_restart"_read_restart.html,
+"change_box"_change_box.html,
-"region"_region.html, "replicate"_replicate.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,
+"angle_coeff"_angle_coeff.html,
-"bond_coeff"_bond_coeff.html, "bond_style"_bond_style.html,
+"angle_style"_angle_style.html,
-"dielectric"_dielectric.html, "dihedral_coeff"_dihedral_coeff.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,
+"kspace_modify"_kspace_modify.html,
-"pair_coeff"_pair_coeff.html, "pair_modify"_pair_modify.html,
+"kspace_style"_kspace_style.html,
-"pair_style"_pair_style.html, "pair_write"_pair_write.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,
+"comm_modify"_comm_modify.html,
-"min_modify"_min_modify.html, "min_style"_min_style.html,
+"comm_style"_comm_style.html,
-"neigh_modify"_neigh_modify.html, "neighbor"_neighbor.html,
+"info"_info.html,
-"reset_timestep"_reset_timestep.html, "run_style"_run_style.html,
+"min_modify"_min_modify.html,
-"set"_set.html, "timestep"_timestep.html, "velocity"_velocity.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
+"compute"_compute.html,
-
+"compute_modify"_compute_modify.html,
-Computes:
+"fix"_fix.html,
-
+"fix_modify"_fix_modify.html,
-"compute"_compute.html, "compute_modify"_compute_modify.html,
+"uncompute"_uncompute.html,
-"uncompute"_uncompute.html
+"unfix"_unfix.html
 
 Output:
 
-"dump"_dump.html, "dump image"_dump_image.html,
+"dump image"_dump_image.html,
-"dump_modify"_dump_modify.html, "dump movie"_dump_image.html,
+"dump movie"_dump_image.html,
-"restart"_restart.html, "thermo"_thermo.html,
+"dump"_dump.html,
-"thermo_modify"_thermo_modify.html, "thermo_style"_thermo_style.html,
+"dump_modify"_dump_modify.html,
-"undump"_undump.html, "write_data"_write_data.html,
+"restart"_restart.html,
-"write_dump"_write_dump.html, "write_restart"_write_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,
+"minimize"_minimize.html,
-"displace_atoms"_displace_atoms.html, "change_box"_change_box.html,
+"neb"_neb.html,
-"minimize"_minimize.html, "neb"_neb.html "prd"_prd.html,
+"prd"_prd.html,
-"rerun"_rerun.html, "run"_run.html, "temper"_temper.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,
+"clear"_clear.html,
-"include"_include.html, "jump"_jump.html, "label"_label.html,
+"echo"_echo.html,
-"log"_log.html, "next"_next.html, "print"_print.html,
+"if"_if.html,
-"shell"_shell.html, "variable"_variable.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,6 +528,8 @@ 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)
 
@@ -516,6 +575,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,
@@ -599,6 +659,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,
@@ -617,6 +678,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,
@@ -824,6 +886,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,
@@ -896,7 +960,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,
@@ -922,6 +986,7 @@ KOKKOS, o = USER-OMP, t = OPT.
 "tip4p/long (o)"_pair_coul.html,
 "tri/lj"_pair_tri_lj.html,
 "vashishta (o)"_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)
@@ -956,7 +1021,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

@@ -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
+"neigh_modify"_neigh_modify.html command.  The safest settings are
-every 1 check yes".  Second, it may mean that an atom has moved far
+"delay 0 every 1 check yes".  Second, it may mean that an atom has
-outside a processor's sub-domain or even the entire simulation box.
+moved far outside a processor's sub-domain or even the entire
-This indicates bad physics, e.g. due to highly overlapping atoms, too
+simulation box. This indicates bad physics, e.g. due to highly
-large a timestep, etc. :dd
+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
+"neigh_modify"_neigh_modify.html command.  The safest settings are
-every 1 check yes".  Second, it may mean that an atom has moved far
+"delay 0 every 1 check yes".  Second, it may mean that an atom has
-outside a processor's sub-domain or even the entire simulation box.
+moved far outside a processor's sub-domain or even the entire
-This indicates bad physics, e.g. due to highly overlapping atoms, too
+simulation box. This indicates bad physics, e.g. due to highly
-large a timestep, etc. :dd
+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
+"neigh_modify"_neigh_modify.html command.  The safest settings are
-every 1 check yes".  Second, it may mean that an atom has moved far
+"delay 0 every 1 check yes".  Second, it may mean that an atom has
-outside a processor's sub-domain or even the entire simulation box.
+moved far outside a processor's sub-domain or even the entire
-This indicates bad physics, e.g. due to highly overlapping atoms, too
+simulation box. This indicates bad physics, e.g. due to highly
-large a timestep, etc. :dd
+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)
+meam:     MEAM test for SiC and shear (same as shear examples)
-melt:	  rapid melt of 3d LJ system
+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
+min:      energy minimization of 2d LJ melt
-msst:	  MSST shock dynamics
+msst:     MSST shock dynamics
 nb3b:     use of nonbonded 3-body harmonic pair style
-neb:	  nudged elastic band (NEB) calculation for barrier finding
+neb:      nudged elastic band (NEB) calculation for barrier finding
-nemd:	  non-equilibrium MD of 2d sheared system
+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

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

doc/src/Section_howto.txt

@@ -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
+neighbor        0.4 bin
-neigh_modify	every 1 delay 1 :pre
+neigh_modify    every 1 delay 1 :pre
 
-fix		1 all nve
+fix             1 all nve
-fix		2 all langevin 1.0 1.0 10.0 904297 :pre
+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
+units           lj
-atom_style	bond
+atom_style      bond
-pair_style	lj/cut 1.12
+pair_style      lj/cut 1.12
-pair_modify	shift yes
+pair_modify     shift yes
-bond_style	fene
+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
+neighbor        0.4 bin
-neigh_modify	every 1 delay 1 :pre
+neigh_modify    every 1 delay 1 :pre
 
-fix		1 all nve
+fix             1 all nve
-fix		2 all langevin 1.0 1.0 10.0 904297 :pre
+fix             2 all langevin 1.0 1.0 10.0 904297 :pre
 
-timestep	0.012 :pre
+timestep        0.012 :pre
 
-reset_timestep	50
+reset_timestep  50
-run		50 :pre
+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}
@@ -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
+The lammps_file(), lammps_command(), lammps_commands_list(), and
-file or string to LAMMPS as if it were an input script or single
+lammps_commands_string() functions are used to pass one or more
-command in an input script.  Thus the calling code can read or
+commands to LAMMPS to execute, the same as if they were coming from an
-generate a series of LAMMPS commands one line at a time and pass it
+input script.
-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.
 
-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_gather_atoms(void *, double *)
-void lammps_put_coords(void *, double *) :pre
+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
+The extract functions return a pointer to various global or per-atom
-well as values calculated by a compute, fix, or variable.  The
+quantities stored in LAMMPS or to values calculated by a compute, fix,
-"set_variable" function can set an existing string-style variable to a
+or variable.  The pointer returned by the extract_global() function
-new value, so that subsequent LAMMPS commands can access the variable.
+can be used as a permanent reference to a value which may change.  For
-The "get" and "put" operations can retrieve and reset atom
+the other extract functions, the underlying storage may be reallocated
-coordinates.  See the library.cpp file and its associated header file
+as LAMMPS runs, so you need to re-call the function to assure a
-library.h for details.
+current pointer or returned value(s).
 
-The key idea of the library interface is that you can write any
+The lammps_set_variable() function can set an existing string-style
-functions you wish to define how your code talks to LAMMPS and add
+variable to a new string value, so that subsequent LAMMPS commands can
-them to src/library.cpp and src/library.h, as well as to the "Python
+access the variable.  The lammps_get_thermo() function returns the
-interface"_Section_python.html.  The routines you add can access or
+current value of a thermo keyword as a double.
-change any LAMMPS data you wish.  The examples/COUPLE and python
+
-directories have example C++ and C and Python codes which show how a
+The lammps_get_natoms() function returns the total number of atoms in
-driver code can link to LAMMPS as a library, run LAMMPS on a subset of
+the system and can be used by the caller to allocate space for the
-processors, grab data from LAMMPS, change it, and put it back into
+lammps_gather_atoms() and lammps_scatter_atoms() functions.  The
-LAMMPS.
+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,7 +2182,7 @@ 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
@@ -2670,7 +2729,7 @@ 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 
+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
@@ -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

@@ -366,11 +366,11 @@ complementary modeling tasks.
 "DL_POLY"_dlpoly
 "Tinker"_tinker :ul
 
-:link(charmm,http://www.scripps.edu/brooks)
+:link(charmm,http://www.charmm.org)
-:link(amber,http://amber.scripps.edu)
+: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

@@ -845,7 +845,7 @@ 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
-11.2"_Section_python.html#py-2 for an overview of using Python from
+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
@@ -1153,6 +1153,7 @@ Package, Description, Author(s), Doc page, Example, Pic/movie, Library
 "USER-MISC"_#USER-MISC, single-file contributions, USER-MISC/README, USER-MISC/README, -, -, -
 "USER-MANIFOLD"_#USER-MANIFOLD, motion on 2d surface, Stefan Paquay (Eindhoven U of Technology), "fix manifoldforce"_fix_manifoldforce.html, USER/manifold, "manifold"_manifold, -
 "USER-MOLFILE"_#USER-MOLFILE, "VMD"_VMD molfile plug-ins, Axel Kohlmeyer (Temple U), "dump molfile"_dump_molfile.html, -, -, VMD-MOLFILE
+"USER-NC-DUMP"_#USER-NC-DUMP, dump output via NetCDF, Lars Pastewka (Karlsruhe Institute of Technology, KIT), "dump nc, dump nc/mpiio"_dump_nc.html, -, -, lib/netcdf
 "USER-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
@@ -1598,6 +1599,29 @@ 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:

doc/src/Section_python.txt

@@ -534,10 +534,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 +550,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
+                                     # type = 0 = int
-				     #        1 = double :pre
+                                     #        1 = double :pre
 
 coords = lmp.extract_atom(name,type)      # extract a per-atom quantity
                                           # name = "x", "type", etc
-				          # type = 0 = vector of ints
+                                          # type = 0 = vector of ints
-				          #        1 = array of ints
+                                          #        1 = array of ints
-				          #        2 = vector of doubles
+                                          #        2 = vector of doubles
-				          #        3 = array of doubles :pre
+                                          #        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
+                                          # style = 0 = global data
-					  #	    1 = per-atom data
+                                          #         1 = per-atom data
-					  #         2 = local data
+                                          #         2 = local data
-					  # type = 0 = scalar
+                                          # type = 0 = scalar
-					  #	   1 = vector
+                                          #        1 = vector
-					  #        2 = array
+                                          #        2 = array
-					  # i,j = indices of value in global vector or array :pre
+                                          # 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
+                                             # name = name of variable
-					     # group = group ID (ignored for equal-style variables)
+                                             # group = group ID (ignored for equal-style variables)
-					     # flag = 0 = equal-style variable
+                                             # flag = 0 = equal-style variable
-					     #        1 = atom-style variable :pre
+                                             #        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 +604,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
+Additional arguments to lammps() can be used to tell Python the name
-library to load or to pass arguments to the LAMMPS instance, the same
+of the shared library to load or to pass arguments to the LAMMPS
-as if LAMMPS were launched from a command-line prompt.
+instance, the same as if LAMMPS were launched from a command-line
+prompt.
 
 If the ptr argument is set like this:
 
@@ -626,8 +632,9 @@ lmp2 = lammps()
 lmp1.file("in.file1")
 lmp2.file("in.file2") :pre
 
-The file() and command() methods allow an input script or single
+The file(), command(), commands_list(), commands_string() methods
-commands to be invoked.
+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

doc/src/Section_start.txt

@@ -706,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
@@ -1601,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
+itself.  See the "processors out"_processors.html command for how
-info on the final assignment of physical processors to the LAMMPS
+to output info on the final assignment of physical processors to
-simulation domain.
+the LAMMPS simulation domain.
 
 -screen file :pre
 

doc/src/accelerate_intel.txt

@@ -151,7 +151,7 @@ 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
+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%
@@ -343,7 +343,7 @@ 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, 
+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"

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_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
+MOLECULE package.  See the "Making LAMMPS"_Section_start.html#start_3
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+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_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_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

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
+zero or more keyword/arg pairs may be appended :l
-keyword = {out} :l
+keyword = {weight} or {out} :l
-  {out} value = filename
+  {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
+within the simulation box, to attempt to balance the number of atoms
-particles and thus the computational cost (load) evenly across
+or particles and thus indirectly the computational cost (load) more
-processors.  The load balancing is "static" in the sense that this
+evenly across processors.  The load balancing is "static" in the sense
-command performs the balancing once, before or between simulations.
+that this command performs the balancing once, before or between
-The processor sub-domains will then remain static during the
+simulations.  The processor sub-domains will then remain static during
-subsequent run.  To perform "dynamic" balancing, see the "fix
+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
+Load-balancing is typically most useful if the particles in the
-simulation box have a spatially-varying density distribution.  E.g. a
+simulation box have a spatially-varying density distribution or when
-model of a vapor/liquid interface, or a solid with an irregular-shaped
+the computational cost varies signficantly between different
-geometry containing void regions.  In this case, the LAMMPS default of
+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
+bricks, with one equal-volume sub-domain per procesor, may assign
-different numbers of particles per processor.  This can lead to poor
+numbers of particles per processor in a way that the computational
-performance when the simulation is run in parallel.
+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,
+defined as the maximum number of particles (or weight) owned by any
-divided by the average number of particles per processor.  Thus an
+processor, divided by the average number of particles (or weight) per
-imbalance factor of 1.0 is perfect balance.
+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
+diagram where processor sub-domains are shown and particles are
-the processor that owns them.  The leftmost diagram is the default
+colored by the processor that owns them.  The leftmost diagram is the
-partitioning of the simulation box across processors (one sub-box for
+default partitioning of the simulation box across processors (one
-each of 16 processors); the middle diagram is after a "grid" method
+sub-box for each of 16 processors); the middle diagram is after a
-has been applied.
+"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
+fashion so as to have equal numbers of particles (or weight) in each
-in the rightmost diagram above.
+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
+processor.)  The cut is positioned so that the number of particles in
-lower box is exactly the number that the processors assigned to that
+the lower box is exactly the number that the processors assigned to
-box should own for load balance to be perfect.  This also makes load
+that box should own for load balance to be perfect.  This also makes
-balance for the upper box perfect.  The positioning is done
+load balance for the upper box perfect.  The positioning is done
-iteratively, by a bisectioning method.  Note that counting atoms on
+iteratively, by a bisectioning method.  Note that counting particles
-either side of the cut requires communication between all processors
+on either side of the cut requires communication between all
-at each iteration.
+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
+box, splitting the box, the subset of processsors, and the particles
-the box in two.  The recursion continues until every processor is
+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
+assigned a sub-box of the entire simulation domain, and owns the
-in that sub-box.
+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
 
@@ -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/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/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_fep.txt

@@ -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_heat_flux.txt

@@ -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_orientorder_atom.txt

@@ -15,7 +15,7 @@ compute ID group-ID orientorder/atom keyword values ... :pre
 ID, group-ID are documented in "compute"_compute.html command :ulb,l
 orientorder/atom = style name of this compute command :l
 one or more keyword/value pairs may be appended :l
-keyword = {cutoff} or {nnn} or {ql} 
+keyword = {cutoff} or {nnn} or {degrees}
   {cutoff} value = distance cutoff
   {nnn} value = number of nearest neighbors
   {degrees} values = nlvalues, l1, l2,...  :pre
@@ -111,7 +111,7 @@ options.
 
 [Default:]
 
-The option defaults are {cutoff} = pair style cutoff, {nnn} = 12, {degrees} = 5 4 6 8 9 10 12 i.e. {Q}4, {Q}6, {Q}8, {Q}10, and {Q}12. 
+The option defaults are {cutoff} = pair style cutoff, {nnn} = 12, {degrees} = 5 4 6 8 10 12 i.e. {Q}4, {Q}6, {Q}8, {Q}10, and {Q}12.
 
 :line
 

doc/src/compute_pe_atom.txt

@@ -52,7 +52,7 @@ The KSpace contribution is calculated using the method in
 "(Heyes)"_#Heyes for the Ewald method and a related method for PPPM,
 as specified by the "kspace_style pppm"_kspace_style.html command.
 For PPPM, the calcluation requires 1 extra FFT each timestep that
-per-atom energy is calculated.  Thie "document"_PDF/kspace.pdf
+per-atom energy is calculated.  This "document"_PDF/kspace.pdf
 describes how the long-range per-atom energy calculation is performed.
 
 Various fixes can contribute to the per-atom potential energy of the
@@ -68,13 +68,14 @@ As an example of per-atom potential energy compared to total potential
 energy, these lines in an input script should yield the same result
 in the last 2 columns of thermo output:
 
-compute		peratom all pe/atom
+compute        peratom all pe/atom
-compute		pe all reduce sum c_peratom
+compute        pe all reduce sum c_peratom
-thermo_style	custom step temp etotal press pe c_pe :pre
+thermo_style   custom step temp etotal press pe c_pe :pre
 
-NOTE: The per-atom energy does not any Lennard-Jones tail corrections
+NOTE: The per-atom energy does not include any Lennard-Jones tail
-invoked by the "pair_modify tail yes"_pair_modify.html command, since
+corrections to the energy added by the "pair_modify tail
-those are global contributions to the system energy.
+yes"_pair_modify.html command, since those are contributions to the
+global system energy.
 
 [Output info:]
 

doc/src/compute_property_atom.txt

@@ -16,20 +16,20 @@ ID, group-ID are documented in "compute"_compute.html command :ulb,l
 property/atom = style name of this compute command :l
 input = one or more atom attributes :l
   possible attributes = id, mol, proc, type, mass,
- 	                x, y, z, xs, ys, zs, xu, yu, zu, ix, iy, iz,
+                        x, y, z, xs, ys, zs, xu, yu, zu, ix, iy, iz,
-		        vx, vy, vz, fx, fy, fz,
+                        vx, vy, vz, fx, fy, fz,
                         q, mux, muy, muz, mu,
                         radius, diameter, omegax, omegay, omegaz,
-			angmomx, angmomy, angmomz,
+                        angmomx, angmomy, angmomz,
-			shapex,shapey, shapez,
+                        shapex,shapey, shapez,
-		        quatw, quati, quatj, quatk, tqx, tqy, tqz,
+                        quatw, quati, quatj, quatk, tqx, tqy, tqz,
-			end1x, end1y, end1z, end2x, end2y, end2z,
+                        end1x, end1y, end1z, end2x, end2y, end2z,
-			corner1x, corner1y, corner1z,
+                        corner1x, corner1y, corner1z,
-			corner2x, corner2y, corner2z,
+                        corner2x, corner2y, corner2z,
-			corner3x, corner3y, corner3z,
+                        corner3x, corner3y, corner3z,
-			nbonds,
+                        nbonds,
                         vfrac, s0,
-			spin, eradius, ervel, erforce,
+                        spin, eradius, ervel, erforce,
                         rho, drho, e, de, cv,
                         i_name, d_name :pre
       id = atom ID

doc/src/compute_property_local.txt

@@ -15,12 +15,12 @@ compute ID group-ID property/local attribute1 attribute2 ... keyword args ... :p
 ID, group-ID are documented in "compute"_compute.html command :ulb,l
 property/local = style name of this compute command :l
 one or more attributes may be appended :l
-  possible attributes =  natom1 natom2 ntype1 ntype2
+  possible attributes = natom1 natom2 ntype1 ntype2
-		         patom1 patom2 ptype1 ptype2
+                        patom1 patom2 ptype1 ptype2
-                         batom1 batom2 btype
+                        batom1 batom2 btype
-                         aatom1 aatom2 aatom3 atype
+                        aatom1 aatom2 aatom3 atype
-                         datom1 datom2 datom3 dtype
+                        datom1 datom2 datom3 dtype
-                         iatom1 iatom2 iatom3 itype :pre
+                        iatom1 iatom2 iatom3 itype :pre
 
      natom1, natom2 = IDs of 2 atoms in each pair (within neighbor cutoff)
      ntype1, ntype2 = type of 2 atoms in each pair (within neighbor cutoff)
@@ -78,7 +78,7 @@ defined by the "pair_style"_pair_style.html command for the types of
 the two atoms is used.  For the {radius} setting, the sum of the radii
 of the two particles is used as a cutoff.  For example, this is
 appropriate for granular particles which only interact when they are
-overlapping, as computed by "granular pair styles"_pair_gran.txt.
+overlapping, as computed by "granular pair styles"_pair_gran.html.
 
 If the inputs are bond, angle, etc attributes, the local data is
 generated by looping over all the atoms owned on a processor and
@@ -129,8 +129,6 @@ The attributes that start with "a", "d", "i", refer to similar values
 for "angles"_angle_style.html, "dihedrals"_dihedral_style.html, and
 "impropers"_improper_style.html.
 
-The optional {cutoff} keyword
-
 [Output info:]
 
 This compute calculates a local vector or local array depending on the

doc/src/compute_reduce.txt

@@ -155,8 +155,8 @@ Thus, for example, if you wish to use this compute to find the bond
 with maximum stretch, you can do it as follows:
 
 compute 1 all property/local batom1 batom2
-compute	2 all bond/local dist
+compute 2 all bond/local dist
-compute	3 all reduce max c_1\[1\] c_1\[2\] c_2 replace 1 3 replace 2 3
+compute 3 all reduce max c_1\[1\] c_1\[2\] c_2 replace 1 3 replace 2 3
 thermo_style custom step temp c_3\[1\] c_3\[2\] c_3\[3\] :pre
 
 The first two input values in the compute reduce command are vectors

doc/src/compute_rigid_local.txt

@@ -17,11 +17,11 @@ rigid/local = style name of this compute command :l
 rigidID = ID of fix rigid/small command or one of its variants :l
 input = one or more rigid body attributes :l
   possible attributes = id, mol, mass,
- 	                x, y, z, xu, yu, zu, ix, iy, iz
+                        x, y, z, xu, yu, zu, ix, iy, iz
-		        vx, vy, vz, fx, fy, fz, 
+                        vx, vy, vz, fx, fy, fz,
                         omegax, omegay, omegaz,
-			angmomx, angmomy, angmomz,
+                        angmomx, angmomy, angmomz,
-		        quatw, quati, quatj, quatk, 
+                        quatw, quati, quatj, quatk,
                         tqx, tqy, tqz,
                         inertiax, inertiay, inertiaz
       id = atom ID of atom within body which owns body properties

doc/src/compute_stress_atom.txt

@@ -60,7 +60,7 @@ produced by a small set of atoms (e.g. 4 atoms in a dihedral or 3
 atoms in a Tersoff 3-body interaction) is assigned in equal portions
 to each atom in the set.  E.g. 1/4 of the dihedral virial to each of
 the 4 atoms, or 1/3 of the fix virial due to SHAKE constraints applied
-to atoms in a a water molecule via the "fix shake"_fix_shake.html
+to atoms in a water molecule via the "fix shake"_fix_shake.html
 command.
 
 If no extra keywords are listed, all of the terms in this formula are
@@ -128,10 +128,15 @@ d = dimension and V is the volume of the system, the result should be
 These lines in an input script for a 3d system should yield that
 result.  I.e. the last 2 columns of thermo output will be the same:
 
-compute		peratom all stress/atom NULL
+compute        peratom all stress/atom NULL
-compute		p all reduce sum c_peratom\[1\] c_peratom\[2\] c_peratom\[3\]
+compute        p all reduce sum c_peratom\[1\] c_peratom\[2\] c_peratom\[3\]
-variable	press equal -(c_p\[1\]+c_p\[2\]+c_p\[3\])/(3*vol)
+variable       press equal -(c_p\[1\]+c_p\[2\]+c_p\[3\])/(3*vol)
-thermo_style	custom step temp etotal press v_press :pre
+thermo_style   custom step temp etotal press v_press :pre
+
+NOTE: The per-atom stress does not include any Lennard-Jones tail
+corrections to the pressure added by the "pair_modify tail
+yes"_pair_modify.html command, since those are contributions to the
+global system pressure.
 
 [Output info:]
 

doc/src/compute_temp_profile.txt

@@ -69,8 +69,8 @@ velocity for each atom.  Note that if there is only one atom in the
 bin, its thermal velocity will thus be 0.0.
 
 After the spatially-averaged velocity field has been subtracted from
-each atom, the temperature is calculated by the formula KE = (dim/2 N
+each atom, the temperature is calculated by the formula KE = (dim*N
-- dim*Nx*Ny*Nz) k T, where KE = total kinetic energy of the group of
+- dim*Nx*Ny*Nz) k T/2, where KE = total kinetic energy of the group of
 atoms (sum of 1/2 m v^2), dim = 2 or 3 = dimensionality of the
 simulation, N = number of atoms in the group, k = Boltzmann constant,
 and T = temperature.  The dim*Nx*Ny*Nz term are degrees of freedom

doc/src/create_atoms.txt

@@ -218,14 +218,14 @@ larger version.
 
 variable        x equal 100
 variable        y equal 25
-lattice		hex 0.8442
+lattice         hex 0.8442
-region		box block 0 $x 0 $y -0.5 0.5
+region          box block 0 $x 0 $y -0.5 0.5
-create_box	1 box :pre
+create_box      1 box :pre
 
 variable        xx equal 0.0
 variable        yy equal 0.0
 variable        v equal "(0.2*v_y*ylat * cos(v_xx/xlat * 2.0*PI*4.0/v_x) + 0.5*v_y*ylat - v_yy) > 0.0"
-create_atoms	1 box var v set x xx set y yy :pre
+create_atoms    1 box var v set x xx set y yy :pre
 
 :c,image(JPG/sinusoid_small.jpg,JPG/sinusoid.jpg)
 

doc/src/dihedral_charmm.txt

@@ -109,7 +109,7 @@ more instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 
 This dihedral 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/dihedral_harmonic.txt

@@ -76,7 +76,7 @@ more instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 
 This dihedral 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/dihedral_helix.txt

@@ -69,7 +69,7 @@ more instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 
 This dihedral 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/dihedral_hybrid.txt

@@ -77,7 +77,7 @@ for specific dihedral types.
 [Restrictions:]
 
 This dihedral 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 dihedral styles, the hybrid dihedral style does not store

doc/src/dihedral_multi_harmonic.txt

@@ -63,7 +63,7 @@ more instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 
 This dihedral 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/dihedral_opls.txt

@@ -71,7 +71,7 @@ more instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 
 This dihedral 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/dihedral_table.txt

@@ -154,7 +154,7 @@ radians instead of degrees.  (Note: This changes the way the forces
 are scaled in the 4th column of the data file.)
 
 The optional "CHECKU" keyword is followed by a filename.  This allows
-the user to save all of the the {Ntable} different entries in the
+the user to save all of the {Ntable} different entries in the
 interpolated energy table to a file to make sure that the interpolated
 function agrees with the user's expectations.  (Note: You can
 temporarily increase the {Ntable} parameter to a high value for this

doc/src/dump.txt

@@ -12,6 +12,7 @@ dump command :h3
 "dump image"_dump_image.html command :h3
 "dump movie"_dump_image.html command :h3
 "dump molfile"_dump_molfile.html command :h3
+"dump nc"_dump_nc.html command :h3
 
 [Syntax:]
 
@@ -43,7 +44,9 @@ args = list of arguments for a particular style :l
 
   {movie} args = discussed on "dump image"_dump_image.html doc page :pre
 
-  {molfile} args = discussed on "dump molfile"_dump_molfile.html doc page :pre
+  {molfile} args = discussed on "dump molfile"_dump_molfile.html doc page
+
+  {nc} args = discussed on "dump nc"_dump_nc.html doc page :pre
 
   {local} args = list of local attributes
     possible attributes = index, c_ID, c_ID\[I\], f_ID, f_ID\[I\]
@@ -55,13 +58,13 @@ args = list of arguments for a particular style :l
 
   {custom} or {custom/gz} or {custom/mpiio} args = list of atom attributes
     possible attributes = id, mol, proc, procp1, type, element, mass,
-			  x, y, z, xs, ys, zs, xu, yu, zu, 
+                          x, y, z, xs, ys, zs, xu, yu, zu,
-			  xsu, ysu, zsu, ix, iy, iz,
+                          xsu, ysu, zsu, ix, iy, iz,
-			  vx, vy, vz, fx, fy, fz,
+                          vx, vy, vz, fx, fy, fz,
                           q, mux, muy, muz, mu,
                           radius, diameter, omegax, omegay, omegaz,
-			  angmomx, angmomy, angmomz, tqx, tqy, tqz,
+                          angmomx, angmomy, angmomz, tqx, tqy, tqz,
-			  c_ID, c_ID\[N\], f_ID, f_ID\[N\], v_name :pre
+                          c_ID, c_ID\[N\], f_ID, f_ID\[N\], v_name :pre
 
       id = atom ID
       mol = molecule ID

doc/src/dump_custom_vtk.txt

@@ -20,14 +20,14 @@ file = name of file to write dump info to :l
 args = list of arguments for a particular style :l
   {custom/vtk} args = list of atom attributes
     possible attributes = id, mol, proc, procp1, type, element, mass,
-			  x, y, z, xs, ys, zs, xu, yu, zu, 
+                          x, y, z, xs, ys, zs, xu, yu, zu,
-			  xsu, ysu, zsu, ix, iy, iz,
+                          xsu, ysu, zsu, ix, iy, iz,
-			  vx, vy, vz, fx, fy, fz,
+                          vx, vy, vz, fx, fy, fz,
                           q, mux, muy, muz, mu,
                           radius, diameter, omegax, omegay, omegaz,
-			  angmomx, angmomy, angmomz, tqx, tqy, tqz,
+                          angmomx, angmomy, angmomz, tqx, tqy, tqz,
-			  spin, eradius, ervel, erforce,
+                          spin, eradius, ervel, erforce,
-			  c_ID, c_ID\[N\], f_ID, f_ID\[N\], v_name :pre
+                          c_ID, c_ID\[N\], f_ID, f_ID\[N\], v_name :pre
 
       id = atom ID
       mol = molecule ID

doc/src/dump_modify.txt

@@ -47,10 +47,10 @@ keyword = {append} or {buffer} or {element} or {every} or {fileper} or {first} o
      id = sort per-atom lines by atom ID
      N = sort per-atom lines in ascending order by the Nth column
      -N = sort per-atom lines in descending order by the Nth column
-  {thresh} args = attribute operation value
+  {thresh} args = attribute operator value
     attribute = same attributes (x,fy,etotal,sxx,etc) used by dump custom style
-    operation = "<" or "<=" or ">" or ">=" or "==" or "!="
+    operator = "<" or "<=" or ">" or ">=" or "==" or "!=" or "|^"
-    value = numeric value to compare to
+    value = numeric value to compare to, or LAST
     these 3 args can be replaced by the word "none" to turn off thresholding
   {unwrap} arg = {yes} or {no} :pre
 these keywords apply only to the {image} and {movie} "styles"_dump_image.html :l
@@ -165,7 +165,7 @@ extra buffering.
 
 :line
 
-The {element} keyword applies only to the the dump {cfg}, {xyz}, and
+The {element} keyword applies only to the dump {cfg}, {xyz}, and
 {image} styles.  It associates element names (e.g. H, C, Fe) with
 LAMMPS atom types.  See the list of element names at the bottom of
 this page.
@@ -215,17 +215,17 @@ to the dump file.  The {every} keyword cannot be used with the dump
 For example, the following commands will
 write snapshots at timesteps 0,10,20,30,100,200,300,1000,2000,etc:
 
-variable	s equal logfreq(10,3,10)
+variable        s equal logfreq(10,3,10)
-dump		1 all atom 100 tmp.dump
+dump            1 all atom 100 tmp.dump
-dump_modify	1 every v_s first yes :pre
+dump_modify     1 every v_s first yes :pre
 
 The following commands would write snapshots at the timesteps listed
 in file tmp.times:
 
 variable        f file tmp.times
-variable	s equal next(f)
+variable        s equal next(f)
-dump		1 all atom 100 tmp.dump
+dump            1 all atom 100 tmp.dump
-dump_modify	1 every v_s :pre
+dump_modify     1 every v_s :pre
 
 NOTE: When using a file-style variable with the {every} keyword, the
 file of timesteps must list a first timestep that is beyond the
@@ -458,16 +458,56 @@ as well as memory, versus unsorted output.
 
 The {thresh} keyword only applies to the dump {custom}, {cfg},
 {image}, and {movie} styles.  Multiple thresholds can be specified.
-Specifying "none" turns off all threshold criteria.  If thresholds are
+Specifying {none} turns off all threshold criteria.  If thresholds are
 specified, only atoms whose attributes meet all the threshold criteria
 are written to the dump file or included in the image.  The possible
 attributes that can be tested for are the same as those that can be
 specified in the "dump custom"_dump.html command, with the exception
 of the {element} attribute, since it is not a numeric value.  Note
-that different attributes can be output by the dump custom command
+that a different attributes can be used than those output by the "dump
-than are used as threshold criteria by the dump_modify command.
+custom"_dump.html command.  E.g. you can output the coordinates and
-E.g. you can output the coordinates and stress of atoms whose energy
+stress of atoms whose energy is above some threshold.
-is above some threshold.
+
+If an atom-style variable is used as the attribute, then it can
+produce continuous numeric values or effective Boolean 0/1 values
+which may be useful for the comparision operator.  Boolean values can
+be generated by variable formulas that use comparison or Boolean math
+operators or special functions like gmask() and rmask() and grmask().
+See the "variable"_variable.html command doc page for details.
+
+The specified value must be a simple numeric value or the word LAST.
+If LAST is used, it refers to the value of the attribute the last time
+the dump command was invoked to produce a snapshot.  This is a way to
+only dump atoms whose attribute has changed (or not changed).
+Three examples follow.
+
+dump_modify ... thresh ix != LAST :pre
+
+This will dump atoms which have crossed the periodic x boundary of the
+simulation box since the last dump.  (Note that atoms that crossed
+once and then crossed back between the two dump timesteps would not be
+included.)
+
+region foo sphere 10 20 10 15
+variable inregion atom rmask(foo)
+dump_modify ... thresh v_inregion |^ LAST
+
+This will dump atoms which crossed the boundary of the spherical
+region since the last dump.
+
+variable charge atom "(q > 0.5) || (q < -0.5)"
+dump_modify ... thresh v_charge |^ LAST
+
+This will dump atoms whose charge has changed from an absolute value
+less than 1/2 to greater than 1/2 (or vice versa) since the last dump.
+E.g. due to reactions and subsequent charge equilibration in a
+reactive force field.
+
+The choice of operators listed above are the usual comparison
+operators.  The XOR operation (exclusive or) is also included as "|^".
+In this context, XOR means that if either the attribute or value is
+0.0 and the other is non-zero, then the result is "true" and the
+threshold criterion is met.  Otherwise it is not met.
 
 :line
 
@@ -534,7 +574,7 @@ e.g. its x-component of velocity if the atom-attribute "vx" was
 specified.
 
 The basic idea of a color map is that the atom-attribute will be
-within a range of values, and that range is associated with a a series
+within a range of values, and that range is associated with a series
 of colors (e.g. red, blue, green).  An atom's specific value (vx =
 -3.2) can then mapped to the series of colors (e.g. halfway between
 red and blue), and a specific color is determined via an interpolation
@@ -643,10 +683,10 @@ this is used.
 variable        colors string &
                 "red green blue yellow white &
                 purple pink orange lime gray"
-variable	mol atom mol%10
+variable        mol atom mol%10
-dump		1 all image 250 image.*.jpg v_mol type &
+dump            1 all image 250 image.*.jpg v_mol type &
-		zoom 1.6 adiam 1.5
+                zoom 1.6 adiam 1.5
-dump_modify	1 pad 5 amap 0 10 sa 1 10 $\{colors\} :pre
+dump_modify     1 pad 5 amap 0 10 sa 1 10 $\{colors\} :pre
 
 In this case, 10 colors are defined, and molecule IDs are
 mapped to one of the colors, even if there are 1000s of molecules.

doc/src/dump_nc.txt

@@ -0,0 +1,66 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+dump nc command :h3
+dump nc/mpiio command :h3
+
+[Syntax:]
+
+dump ID group-ID nc N file.nc args
+dump ID group-ID nc/mpiio N file.nc args :pre
+
+ID = user-assigned name for the dump :ulb,l
+group-ID = ID of the group of atoms to be imaged :l
+{nc} or {nc/mpiio}  = style of dump command (other styles {atom} or {cfg} or {dcd} or {xtc} or {xyz} or {local} or {custom} are discussed on the "dump"_dump.html doc page) :l
+N = dump every this many timesteps :l
+file.nc = name of file to write to :l
+args = list of per atom data elements to dump, same as for the 'custom' dump style. :l,ule
+
+[Examples:]
+
+dump 1 all nc 100 traj.nc type x y z vx vy vz
+dump_modify 1 append yes at -1 global c_thermo_pe c_thermo_temp c_thermo_press :pre
+
+dump 1 all nc/mpiio 1000 traj.nc id type x y z :pre
+
+[Description:]
+
+Dump a snapshot of atom coordinates every N timesteps in Amber-style
+NetCDF file format. NetCDF files are binary, portable and
+self-describing.  This dump style will write only one file on the root
+node.  The dump style {nc} uses the "standard NetCDF
+library"_netcdf-home all data is collected on one processor and then
+written to the dump file. Dump style {nc/mpiio} used the "parallel
+NetCDF library"_pnetcdf-home and MPI-IO; it has better performance on
+a larger number of processors. Note that 'nc' outputs all atoms sorted
+by atom tag while 'nc/mpiio' outputs in order of the MPI rank.
+
+In addition to per-atom data, also global (i.e. not per atom, but per
+frame) quantities can be included in the dump file. This can be
+variables, output from computes or fixes data prefixed with v_, c_ and
+f_, respectively.  These properties are included via
+"dump_modify"_dump_modify.html {global}.
+
+:link(netcdf-home,http://www.unidata.ucar.edu/software/netcdf/)
+:link(pnetcdf-home,http://trac.mcs.anl.gov/projects/parallel-netcdf/)
+
+:line
+
+[Restrictions:]
+
+The {nc} and {nc/mpiio} dump styles are part of the USER-NC-DUMP
+package.  It is only enabled if LAMMPS was built with that
+package. See the "Making LAMMPS"_Section_start.html#start_3 section
+for more info.
+
+:line
+
+[Related commands:]
+
+"dump"_dump.html, "dump_modify"_dump_modify.html, "undump"_undump.html
+

doc/src/fix.txt

@@ -190,6 +190,7 @@ of "this page"_Section_commands.html#cmd_5.
 "gcmc"_fix_gcmc.html - grand canonical insertions/deletions
 "gld"_fix_gcmc.html - generalized Langevin dynamics integrator
 "gravity"_fix_gravity.html - add gravity to atoms in a granular simulation
+"halt"_fix_halt.html - terminate a dynamics run or minimization
 "heat"_fix_heat.html - add/subtract momentum-conserving heat
 "indent"_fix_indent.html - impose force due to an indenter
 "langevin"_fix_langevin.html - Langevin temperature control

doc/src/fix_ave_correlate.txt

@@ -58,7 +58,7 @@ keyword = {type} or {ave} or {start} or {prefactor} or {file} or {overwrite} or
 fix 1 all ave/correlate 5 100 1000 c_myTemp file temp.correlate
 fix 1 all ave/correlate 1 50 10000 &
           c_thermo_press\[1\] c_thermo_press\[2\] c_thermo_press\[3\] &
-	  type upper ave running title1 "My correlation data" :pre
+          type upper ave running title1 "My correlation data" :pre
 fix 1 all ave/correlate 1 50 10000 c_thermo_press\[*\]
 
 [Description:]

doc/src/fix_ave_correlate_long.txt

@@ -55,7 +55,7 @@ keyword = {type} or {start} or {file} or {overwrite} or {title1} or {title2} or
 fix 1 all ave/correlate/long 5 1000 c_myTemp file temp.correlate
 fix 1 all ave/correlate/long 1 10000 &
           c_thermo_press\[1\] c_thermo_press\[2\] c_thermo_press\[3\] &
-	  type upper title1 "My correlation data" nlen 15 ncount 3 :pre
+          type upper title1 "My correlation data" nlen 15 ncount 3 :pre
 
 [Description:]
 

doc/src/fix_balance.txt

@@ -10,7 +10,7 @@ fix balance command :h3
 
 [Syntax:]
 
-fix ID group-ID balance Nfreq thresh style args keyword value ... :pre
+fix ID group-ID balance Nfreq thresh style args keyword args ... :pre
 
 ID, group-ID are documented in "fix"_fix.html command :ulb,l
 balance = style name of this fix command :l
@@ -21,10 +21,24 @@ style = {shift} or {rcb} :l
     dimstr = sequence of letters containing "x" or "y" or "z", each not more than once
     Niter = # of times to iterate within each dimension of dimstr sequence
     stopthresh = stop balancing when this imbalance threshhold is reached
-  rcb args = none :pre
+  {rcb} args = none :pre
-zero or more keyword/value pairs may be appended :l
+zero or more keyword/arg pairs may be appended :l
-keyword = {out} :l
+keyword = {weight} or {out} :l
-  {out} value = filename
+  {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, at each re-balancing :pre
 :ule
 
@@ -32,6 +46,9 @@ keyword = {out} :l
 
 fix 2 all balance 1000 1.05 shift x 10 1.05
 fix 2 all balance 100 0.9 shift xy 20 1.1 out tmp.balance
+fix 2 all balance 100 0.9 shift xy 20 1.1 weight group 3 substrate 3.0 solvent 1.0 solute 0.8 out tmp.balance
+fix 2 all balance 100 1.0 shift x 10 1.1 weight time 0.8
+fix 2 all balance 100 1.0 shift xy 5 1.1 weight var myweight weight neigh 0.6 weight store allweight
 fix 2 all balance 1000 1.1 rcb :pre
 
 [Description:]
@@ -44,14 +61,32 @@ rebalancing is performed periodically during the simulation.  To
 perform "static" balancing, before or between runs, see the
 "balance"_balance.html command.
 
-Load-balancing is typically only useful if the particles in the
+Load-balancing is typically most useful if the particles in the
-simulation box have a spatially-varying density distribution.  E.g. a
+simulation box have a spatially-varying density distribution or
-model of a vapor/liquid interface, or a solid with an irregular-shaped
+where the computational cost varies signficantly between different
-geometry containing void regions.  In this case, the LAMMPS default of
+atoms. E.g. a model of a vapor/liquid interface, or a solid with
-dividing the simulation box volume into a regular-spaced grid of 3d
+an irregular-shaped geometry containing void regions, or
-bricks, with one equal-volume sub-domain per processor, may assign
+"hybrid pair style simulations"_pair_hybrid.html which combine
-very different numbers of particles per processor.  This can lead to
+pair styles with different computational cost.  In these cases, the
-poor performance when the simulation is run in parallel.
+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 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.
+
+NOTE: The weighting options listed above are documented with the
+"balance"_balance.html command in "this section of the balance
+command"_balance.html#weighted_balance doc page.  That section
+describes the various weighting options and gives a few examples of
+how they can be used.  The weighting options are the same for both the
+fix balance and "balance"_balance.html commands.
 
 Note that the "processors"_processors.html command allows some control
 over how the box volume is split across processors.  Specifically, for
@@ -64,9 +99,9 @@ sub-domains will still have the same shape and same volume.
 On a particular timestep, a 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,
+defined as the maximum number of particles (or weight) owned by any
-divided by the average number of particles per processor.  Thus an
+processor, divided by the average number of particles (or weight) per
-imbalance factor of 1.0 is perfect balance.
+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
@@ -117,8 +152,8 @@ 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
+fashion so as to have equal numbers of particles (or weight) in each
-in the rightmost diagram above.
+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
@@ -139,12 +174,9 @@ from scratch.
 
 :line
 
-The {group-ID} is currently ignored.  In the future it may be used to
+The {group-ID} is ignored.  However the impact of balancing on
-determine what particles are considered for balancing.  Normally it
+different groups of atoms can be affected by using the {group} weight
-would only makes sense to use the {all} group.  But in some cases it
+style as described below.
-may be useful to balance on a subset of the particles, e.g. when
-modeling large nanoparticles in a background of small solvent
-particles.
 
 The {Nfreq} setting determines how often a rebalance is performed.  If
 {Nfreq} > 0, then rebalancing will occur every {Nfreq} steps.  Each
@@ -225,7 +257,7 @@ than {Niter} and exit early.
 
 The {rcb} style invokes a "tiled" method for balancing, as described
 above.  It performs a recursive coordinate bisectioning (RCB) of the
-simulation domain.  The basic idea is as follows.
+simulation domain. The basic idea is as follows.
 
 The simulation domain is cut into 2 boxes by an axis-aligned cut in
 the longest dimension, leaving one new box on either side of the cut.
@@ -250,10 +282,10 @@ in that sub-box.
 
 :line
 
-The {out} keyword writes a text file to the specified {filename} with
+The {out} keyword writes text to the specified {filename} with the
-the results of each rebalancing operation.  The file contains the
+results of each rebalancing operation.  The file contains the bounds
-bounds of the sub-domain for each processor after the balancing
+of the sub-domain for each processor after the balancing operation
-operation completes.  The format of the file is compatible with the
+completes.  The format of the file is compatible with the
 "Pizza.py"_pizza {mdump} tool which has support for manipulating and
 visualizing mesh files.  An example is shown here for a balancing by 4
 processors for a 2d problem:
@@ -321,8 +353,8 @@ values in the vector are as follows:
 3 = imbalance factor right before the last rebalance was performed :ul
 
 As explained above, the imbalance factor is the ratio of the maximum
-number of particles on any processor to the average number of
+number of particles (or total weight) on any processor to the average
-particles per processor.
+number of particles (or total weight) per processor.
 
 These quantities can be accessed by various "output
 commands"_Section_howto.html#howto_15.  The scalar and vector values
@@ -336,11 +368,11 @@ minimization"_minimize.html.
 
 [Restrictions:]
 
-For 2d simulations, a "z" cannot appear in {dimstr} for the {shift}
+For 2d simulations, the {z} style cannot be used.  Nor can a "z"
-style.
+appear in {dimstr} for the {shift} style.
 
 [Related commands:]
 
-"processors"_processors.html, "balance"_balance.html
+"group"_group.html, "processors"_processors.html, "balance"_balance.html
 
 [Default:] none

doc/src/fix_cmap.txt

@@ -56,7 +56,7 @@ CMAP :pre
 
        1       1       8      10      12      18      20
        2       5      18      20      22      25      27
-       ... 
+       \[...\]
        N       3     314     315     317      318    330 :pre
 
 The first column is an index from 1 to N to enumerate the CMAP terms;
@@ -66,7 +66,7 @@ remaining 5 columns are the atom IDs of the atoms in the two 4-atom
 dihedrals that overlap to create the CMAP 5-body interaction.  Note
 that the "crossterm" and "CMAP" keywords for the header and body
 sections match those specified in the read_data command following the
-data file name; see the "read_data"_doc/read_data.html doc page for
+data file name; see the "read_data"_read_data.html doc page for
 more details.
 
 A data file containing CMAP crossterms can be generated from a PDB
@@ -113,7 +113,7 @@ quantity being minimized), you MUST enable the
 [Restrictions:]
 
 This fix can only be used if LAMMPS was built with the MOLECULE
-package (which it is by default).  See the "Making
+package.  See the "Making
 LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]
@@ -124,9 +124,9 @@ LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 :line
 
-(Buck) 
+:link(Buck)
-Buck, Bouguet-Bonnet, Pastor, MacKerell Jr., Biophys J, 90, L36
+[(Buck)] Buck, Bouguet-Bonnet, Pastor, MacKerell Jr., Biophys J, 90, L36
 (2006).
 
-(Brooks) 
+:link(Brooks)
-Brooks, Brooks, MacKerell Jr., J Comput Chem, 30, 1545 (2009).
+[(Brooks)] Brooks, Brooks, MacKerell Jr., J Comput Chem, 30, 1545 (2009).

doc/src/fix_deform.txt

@@ -28,7 +28,7 @@ parameter = {x} or {y} or {z} or {xy} or {xz} or {yz}
         factor = multiplicative factor for change in box length at end of run
       {vel} value = V
         V = change box length at this velocity (distance/time units),
-	    effectively an engineering strain rate
+            effectively an engineering strain rate
       {erate} value = R
         R = engineering strain rate (1/time units)
       {trate} value = R
@@ -36,10 +36,10 @@ parameter = {x} or {y} or {z} or {xy} or {xz} or {yz}
       {volume} value = none = adjust this dim to preserve volume of system
       {wiggle} values = A Tp
         A = amplitude of oscillation (distance units)
-	Tp = period of oscillation (time units)
+        Tp = period of oscillation (time units)
       {variable} values = v_name1 v_name2
         v_name1 = variable with name1 for box length change as function of time
-	v_name2 = variable with name2 for change rate as function of time
+        v_name2 = variable with name2 for change rate as function of time
   {xy}, {xz}, {yz} args = style value
     style = {final} or {delta} or {vel} or {erate} or {trate} or {wiggle}
       {final} value = tilt
@@ -48,17 +48,17 @@ parameter = {x} or {y} or {z} or {xy} or {xz} or {yz}
         dtilt = change in tilt factor at end of run (distance units)
       {vel} value = V
         V = change tilt factor at this velocity (distance/time units),
-	    effectively an engineering shear strain rate
+            effectively an engineering shear strain rate
       {erate} value = R
         R = engineering shear strain rate (1/time units)
       {trate} value = R
         R = true shear strain rate (1/time units)
       {wiggle} values = A Tp
         A = amplitude of oscillation (distance units)
-	Tp = period of oscillation (time units)
+        Tp = period of oscillation (time units)
       {variable} values = v_name1 v_name2
         v_name1 = variable with name1 for tilt change as function of time
-	v_name2 = variable with name2 for change rate as function of time :pre
+        v_name2 = variable with name2 for change rate as function of time :pre
 
 zero or more keyword/value pairs may be appended :l
 keyword = {remap} or {flip} or {units} :l
@@ -150,7 +150,7 @@ initial box length is 100 Angstroms, and V is 10 Angstroms/psec, then
 after 10 psec, the box length will have doubled.  After 20 psec, it
 will have tripled.
 
-The {erate} style changes a dimension of the the box at a "constant
+The {erate} style changes a dimension of the box at a "constant
 engineering strain rate".  The units of the specified strain rate are
 1/time.  See the "units"_units.html command for the time units
 associated with different choices of simulation units,

doc/src/fix_dpd_energy.txt

@@ -0,0 +1,83 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+fix dpd/energy command :h3
+
+[Syntax:]
+
+fix ID group-ID dpd/energy :pre
+
+ID, group-ID are documented in "fix"_fix.html command
+dpd/energy = style name of this fix command :ul
+
+[Examples:]
+
+fix 1 all dpd/energy :pre
+
+[Description:]
+
+Perform constant energy dissipative particle dynamics (DPD-E)
+integration.  This fix updates the internal energies for particles in
+the group at each timestep.  It must be used in conjunction with a
+deterministic integrator (e.g. "fix nve"_fix_nve.html) that updates
+the particle positions and velocities.
+
+For fix {dpd/energy}, the particle internal temperature is related to
+the particle internal energy through a mesoparticle equation of state.
+An additional fix must be specified that defines the equation of state
+for each particle, e.g. "fix eos/cv"_fix_eos_cv.html.
+
+This fix must be used with the "pair_style
+dpd/fdt/energy"_pair_style.html command.
+
+Note that numerous variants of DPD can be specified by choosing an
+appropriate combination of the integrator and "pair_style
+dpd/fdt/energy"_pair_style.html command.  DPD under isoenergetic conditions
+can be specified by using fix {dpd/energy}, fix {nve} and pair_style
+{dpd/fdt/energy}.  DPD under isoenthalpic conditions can
+be specified by using fix {dpd/energy}, fix {nph} and pair_style
+{dpd/fdt/energy}.  Examples of each DPD variant are provided in the
+examples/USER/dpd directory.
+
+:line
+
+[Restrictions:]
+
+This command is part of the USER-DPD package.  It is only enabled if
+LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+This fix must be used with an additional fix that specifies time
+integration, e.g. "fix nve"_fix_nve.html.
+
+The fix {dpd/energy} requires the {dpd} "atom_style"_atom_style.html
+to be used in order to properly account for the particle internal
+energies and temperature.
+
+The fix {dpd/energy} must be used with an additional fix that specifies the
+mesoparticle equation of state for each particle.
+
+[Related commands:]
+
+"fix nve"_fix_nve.html "fix eos/cv"_fix_eos_cv.html
+
+[Default:] none
+
+:line
+
+:link(Lisal)
+[(Lisal)] M. Lisal, J.K. Brennan, J. Bonet Avalos, "Dissipative
+particle dynamics at isothermal, isobaric, isoenergetic, and
+isoenthalpic conditions using Shardlow-like splitting algorithms.",
+J. Chem. Phys., 135, 204105 (2011).
+
+: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
+Laboratory, Aberdeen Proving Ground, MD (2014).

doc/src/fix_flow_gauss.txt

@@ -63,7 +63,7 @@ applied by GD before computing a pressure drop or comparing it to
 other methods, such as the pump method "(Zhu)"_#Zhu. The pressure
 correction is discussed and described in "(Strong)"_#Strong.
 
-NOTE: For a complete example including the considerations discussed
+For a complete example including the considerations discussed
 above, see the examples/USER/flow_gauss directory.
 
 NOTE: Only the flux of the atoms in group-ID will be conserved. If the
@@ -93,6 +93,19 @@ work on the system must have {fix_modify energy yes} set as well. This
 includes thermostat fixes and any constraints that hold the positions
 of wall atoms fixed, such as "fix spring/self"_fix_spring_self.html.
 
+If this fix is used in a simulation with the "rRESPA"_run_style.html
+integrator, the applied acceleration must be computed and applied at the same
+rRESPA level as the interactions between the flowing fluid and the obstacle.
+The rRESPA level at which the acceleration is applied can be changed using
+the "fix_modify"_fix_modify.html {respa} option discussed below. If the
+flowing fluid and the obstacle interact through multiple interactions that are
+computed at different rRESPA levels, then there must be a separate flow/gauss
+fix for each level. For example, if the flowing fluid and obstacle interact
+through pairwise and long-range Coulomb interactions, which are computed at
+rRESPA levels 3 and 4, respectively, then there must be two separate
+flow/gauss fixes, one that specifies {fix_modify respa 3} and one with
+{fix_modify respa 4}.
+
 :line
 
 [Restart, fix_modify, output, run start/stop, minimize info:]
@@ -109,6 +122,11 @@ fix to subtract the work done from the
 system's potential energy as part of "thermodynamic
 output"_thermo_style.html.
 
+The "fix_modify"_fix_modify.html {respa} option is supported by this
+fix. This allows the user to set at which level of the "rRESPA"_run_style.html
+integrator the fix computes and adds the external acceleration. Default is the
+outermost level.
+
 This fix computes a global scalar and a global 3-vector of forces,
 which can be accessed by various "output
 commands"_Section_howto.html#howto_15.  The scalar is the negative of the

doc/src/fix_halt.txt

@@ -0,0 +1,121 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+fix halt command :h3
+
+[Syntax:]
+
+fix ID group-ID halt N attribute operator avalue keyword value ... :pre
+
+ID, group-ID are documented in "fix"_fix.html command :ulb,l
+halt = style name of this fix command :l
+N = check halt condition every N steps :l
+attribute = hstyle or v_name :l
+  hstyle = {bondmax}
+  v_name = name of "equal-style variable"_variable.html :pre
+operator = "<" or "<=" or ">" or ">=" or "==" or "!=" or "|^" :l
+avalue = numeric value to compare attribute to :l
+string = text string to print with optional variable names :l
+zero or more keyword/value pairs may be appended :l
+keyword = {error} :l
+  {error} value = {hard} or {soft} or {continue} :pre
+:ule
+
+[Examples:]
+
+fix 10 all halt 1 bondmax > 1.5
+fix 10 all print 10 v_myCheck != 0 error soft :pre
+
+[Description:]
+
+Check a condition every N steps during a simulation run.  N must be >=
+1.  If the condition is met, exit the run immediately.  In this
+context a "run" can be dynamics or minimization iterations, as
+specified by the "run"_run.html or "minimize"_minimize.html command.
+
+The specified group-ID is ignored by this fix.
+
+The specified {attribute} can be one of the {hstyle} options listed
+above, or an "equal-style variable"_variable.html referenced as
+{v_name}, where "name" is the name of a variable that has been defined
+previously in the input script.
+
+The only {hstyle} option currently implemented is {bondmax}.  This
+will loop over all bonds in the system, compute their current
+lengths, and set {attribute} to the longest bond distance.
+
+Equal-style variables evaluate to a numeric value.  See the
+"variable"_variable.html command for a description.  They calculate
+formulas which can involve mathematical operations, atom properties,
+group properties, thermodynamic properties, global values calculated
+by a "compute"_compute.html or "fix"_fix.html, or references to other
+"variables"_variable.html.  Thus they are a very general means of
+computing some attribute of the current system.  For example, the
+following "bondmax" variable will calculate the same quantity as the
+hstyle = bondmax option.
+
+compute         bdist all bond/local dist
+compute         bmax all reduce max c_bdist
+variable        bondmax equal c_bmax :pre
+
+Thus these two versions of a fix halt command will do the same thing:
+
+fix 10 all halt 1 bondmax > 1.5
+fix 10 all halt 1 v_bondmax > 1.5 :pre
+
+The version with "bondmax" will just run somewhat faster, due to less
+overhead in computing bond lengths and not storing them in a separate
+compute.
+
+The choice of operators listed above are the usual comparison
+operators.  The XOR operation (exclusive or) is also included as "|^".
+In this context, XOR means that if either the attribute or avalue is
+0.0 and the other is non-zero, then the result is "true".  Otherwise
+it is "false".
+
+The specified {avalue} must be a numeric value.
+
+:line
+
+The optional {error} keyword determines how the current run is halted.
+If its value is {hard}, then LAMMPS will stop with an error message.
+
+If its value is {soft}, LAMMPS will exit the current run, but continue
+to execute subsequent commands in the input script.  However,
+additional "run"_run.html or "minimize"_minimize.html commands will be
+skipped.  For example, this allows a script to output the current
+state of the system, e.g. via a "write_dump"_write_dump.html or
+"write_restart"_write_restart.html command.
+
+If its value is {continue}, the behavior is the same as for {soft},
+except subsequent subsequent "run"_run.html or
+"minimize"_minimize.html commands are executed.  This allows your
+script to remedy the condition that triggered the halt, if necessary.
+Note that you may wish use the "unfix"_unfix.html command on the fix
+halt ID, so that the same condition is not immediately triggered in a
+subsequent run.
+
+[Restart, fix_modify, output, run start/stop, minimize info:]
+
+No information about this fix is written to "binary restart
+files"_restart.html.  None of the "fix_modify"_fix_modify.html options
+are relevant to this fix.  No global or per-atom quantities are stored
+by this fix for access by various "output
+commands"_Section_howto.html#howto_15.  No parameter of this fix can
+be used with the {start/stop} keywords of the "run"_run.html command.
+This fix is not invoked during "energy minimization"_minimize.html.
+
+[Restrictions:] none
+
+[Related commands:]
+
+"variable"_variable.html
+
+[Default:]
+
+The option defaults are error = hard.