added LAST option to dump_modify thresh, more restart info printed out to screen

txt2rst external link fix

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

doc/.gitignore

@@ -1 +1 @@
-
+/html

doc/README

@@ -1,10 +1,46 @@
-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:
+
+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
+
+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
@@ -51,3 +87,10 @@ 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
+
+
+

doc/src/Manual.txt

@@ -1,7 +1,7 @@
 <!-- HTML_ONLY -->
 <HEAD>
 <TITLE>LAMMPS Users Manual</TITLE>
-<META NAME="docnumber" CONTENT="22 Sep 2016 version">
+<META NAME="docnumber" CONTENT="11 Oct 2016 version">
 <META NAME="author" CONTENT="http://lammps.sandia.gov - Sandia National Laboratories">
 <META NAME="copyright" CONTENT="Copyright (2003) Sandia Corporation.  This software and manual is distributed under the GNU General Public License.">
 </HEAD>
@@ -21,7 +21,7 @@
 <H1></H1>
 
 LAMMPS Documentation :c,h3
-22 Sep 2016 version :c,h4
+11 Oct 2016 version :c,h4
 
 Version info: :h4
 

doc/src/Section_commands.txt

@@ -501,6 +501,7 @@ USER-INTEL, k = KOKKOS, o = USER-OMP, t = OPT.
 "bond/create"_fix_bond_create.html,
 "bond/swap"_fix_bond_swap.html,
 "box/relax"_fix_box_relax.html,
+"cmap"_fix_cmap.html,
 "controller"_fix_controller.html,
 "deform (k)"_fix_deform.html,
 "deposit"_fix_deposit.html,
@@ -598,6 +599,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,
@@ -895,7 +897,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,
@@ -955,7 +957,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_example.txt

@@ -105,8 +105,8 @@ web site.
 
 If you uncomment the "dump image"_dump_image.html line(s) in the input
 script a series of JPG images will be produced by the run (assuming
-you built LAMMPS with JPG support; see "Section start
-2.2"_Section_start.html for details).  These can be viewed
+you built LAMMPS with JPG support; see "Section
+2.2"_Section_start.html#start_2 for details).  These can be viewed
 individually or turned into a movie or animated by tools like
 ImageMagick or QuickTime or various Windows-based tools.  See the
 "dump image"_dump_image.html doc page for more details.  E.g. this
@@ -136,5 +136,5 @@ The USER directory has a large number of sub-directories which
 correspond by name to a USER package.  They contain scripts that
 illustrate how to use the command(s) provided in that package.  Many
 of the sub-directories have their own README files which give further
-instructions.  See the "Section packages"_Section_packages.html doc
+instructions.  See the "Section 4"_Section_packages.html doc
 page for more info on specific USER packages.

doc/src/Section_history.txt

@@ -37,7 +37,7 @@ pitfalls or alternatives.
 
 Please see some of the closed issues for examples of how to
 suggest code enhancements, submit proposed changes, or report
-elated issues and how they are resoved. 
+possible bugs and how they are resoved.
 
 As an alternative to using GitHub, you may e-mail the
 "core developers"_http://lammps.sandia.gov/authors.html or send

doc/src/Section_howto.txt

@@ -2123,7 +2123,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

doc/src/Section_packages.txt

@@ -71,16 +71,16 @@ Package, Description, Author(s), Doc page, Example, Library
 "COMPRESS"_#COMPRESS, I/O compression, Axel Kohlmeyer (Temple U), "dump */gz"_dump.html, -, -
 "CORESHELL"_#CORESHELL, adiabatic core/shell model, Hendrik Heenen (Technical U of Munich), "Section 6.6.25"_Section_howto.html#howto_25, coreshell, -
 "DIPOLE"_#DIPOLE, point dipole particles, -, "pair_style dipole/cut"_pair_dipole.html, dipole, -
-"GPU"_#GPU, GPU-enabled styles, Mike Brown (ORNL), "Section accelerate"_accelerate_gpu.html, gpu, lib/gpu
+"GPU"_#GPU, GPU-enabled styles, Mike Brown (ORNL), "Section 5.3.1"_accelerate_gpu.html, gpu, lib/gpu
 "GRANULAR"_#GRANULAR, granular systems, -, "Section 6.6.6"_Section_howto.html#howto_6, pour, -
 "KIM"_#KIM, openKIM potentials, Smirichinski & Elliot & Tadmor (3), "pair_style kim"_pair_kim.html, kim, KIM
-"KOKKOS"_#KOKKOS, Kokkos-enabled styles, Trott & Moore (4), "Section 5"_accelerate_kokkos.html, kokkos, lib/kokkos
+"KOKKOS"_#KOKKOS, Kokkos-enabled styles, Trott & Moore (4), "Section 5.3.3"_accelerate_kokkos.html, kokkos, lib/kokkos
 "KSPACE"_#KSPACE, long-range Coulombic solvers, -, "kspace_style"_kspace_style.html, peptide, -
 "MANYBODY"_#MANYBODY, many-body potentials, -, "pair_style tersoff"_pair_tersoff.html, shear, -
 "MEAM"_#MEAM, modified EAM potential, Greg Wagner (Sandia), "pair_style meam"_pair_meam.html, meam, lib/meam
 "MC"_#MC, Monte Carlo options, -, "fix gcmc"_fix_gcmc.html, -, -
 "MOLECULE"_#MOLECULE, molecular system force fields, -, "Section 6.6.3"_Section_howto.html#howto_3, peptide, -
-"OPT"_#OPT, optimized pair styles, Fischer & Richie & Natoli (2), "Section accelerate"_accelerate_opt.html, -, -
+"OPT"_#OPT, optimized pair styles, Fischer & Richie & Natoli (2), "Section 5.3.5"_accelerate_opt.html, -, -
 "PERI"_#PERI, Peridynamics models, Mike Parks (Sandia), "pair_style peri"_pair_peri.html, peri, -
 "POEMS"_#POEMS, coupled rigid body motion, Rudra Mukherjee (JPL), "fix poems"_fix_poems.html, rigid, lib/poems
 "PYTHON"_#PYTHON, embed Python code in an input script, -, "python"_python.html, python, lib/python
@@ -127,7 +127,6 @@ of the LAMMPS distribution.  See the lib/package/README file for info
 on how to build the library.  If it is not listed as lib/package, then
 it is a third-party library not included in the LAMMPS distribution.
 See details on all of this below for individual packages.
-p.s.: are we ever going to get commit messages from you? ;-)
 
 :line
 
@@ -150,7 +149,7 @@ make machine :pre
 
 Make.py -p ^asphere -a machine :pre
 
-Supporting info: "Section howto 6.14"_Section_howto.html#howto_14,
+Supporting info: "Section 6.14"_Section_howto.html#howto_14,
 "pair_style gayberne"_pair_gayberne.html, "pair_style
 resquared"_pair_resquared.html,
 "doc/PDF/pair_gayberne_extra.pdf"_PDF/pair_gayberne_extra.pdf,
@@ -279,9 +278,8 @@ Contents: Compute and pair styles that implement the adiabatic
 core/shell model for polarizability.  The compute temp/cs command
 measures the temperature of a system with core/shell particles.  The
 pair styles augment Born, Buckingham, and Lennard-Jones styles with
-core/shell capabilities.  See "Section howto
-6.26"_Section_howto.html#howto_26 for an overview of how to use the
-package.
+core/shell capabilities.  See "Section 6.26"_Section_howto.html#howto_26
+for an overview of how to use the package.
 
 To install via make or Make.py:
 
@@ -297,8 +295,8 @@ make machine :pre
 
 Make.py -p ^coreshell -a machine :pre
 
-Supporting info: "Section howto
-6.26"_Section_howto.html#howto_26, "compute temp/cs"_compute_temp_cs.html,
+Supporting info: "Section 6.26"_Section_howto.html#howto_26,
+"compute temp/cs"_compute_temp_cs.html,
 "pair_style born/coul/long/cs"_pair_cs.html, "pair_style
 buck/coul/long/cs"_pair_cs.html, pair_style
 lj/cut/coul/long/cs"_pair_lj.html, examples/coreshell
@@ -335,7 +333,7 @@ GPU package :link(GPU),h5
 
 Contents: Dozens of pair styles and a version of the PPPM long-range
 Coulombic solver for NVIDIA GPUs.  All of them have a "gpu" in their
-style name.  "Section accelerate gpu"_accelerate_gpu.html gives
+style name.  "Section 5.3.1"_accelerate_gpu.html gives
 details of what hardware and Cuda software is required on your system,
 and how to build and use this package.  See the KOKKOS package, which
 also has GPU-enabled styles.
@@ -380,10 +378,11 @@ make machine :pre
 
 Make.py -p ^gpu -a machine :pre
 
-Supporting info: src/GPU/README, lib/gpu/README, "Section
-acclerate"_Section_accelerate.html, "Section accelerate
-gpu"_accelerate_gpu.html, Pair Styles section of "Section commands
-3.5"_Section_commands.html#cmd_5 for any pair style listed with a (g),
+Supporting info: src/GPU/README, lib/gpu/README,
+"Section 5.3"_Section_accelerate.html#acc_3,
+"Section 5.3.1"_accelerate_gpu.html,
+Pair Styles section of "Section 3.5"_Section_commands.html#cmd_5
+for any pair style listed with a (g),
 "kspace_style"_kspace_style.html, "package gpu"_package.html,
 examples/accelerate, bench/FERMI, bench/KEPLER
 
@@ -409,7 +408,7 @@ make machine :pre
 
 Make.py -p ^granular -a machine :pre
 
-Supporting info: "Section howto 6.6"_Section_howto.html#howto_6, "fix
+Supporting info: "Section 6.6"_Section_howto.html#howto_6, "fix
 pour"_fix_pour.html, "fix wall/gran"_fix_wall_gran.html, "pair_style
 gran/hooke"_pair_gran.html, "pair_style
 gran/hertz/history"_pair_gran.html, examples/pour, bench/in.chute
@@ -453,7 +452,7 @@ Contents: Dozens of atom, pair, bond, angle, dihedral, improper styles
 which run with the Kokkos library to provide optimization for
 multicore CPUs (via OpenMP), NVIDIA GPUs, or the Intel Xeon Phi (in
 native mode).  All of them have a "kk" in their style name.  "Section
-accelerate kokkos"_accelerate_kokkos.html gives details of what
+5.3.3"_accelerate_kokkos.html gives details of what
 hardware and software is required on your system, and how to build and
 use this package.  See the GPU, OPT, USER-INTEL, USER-OMP packages,
 which also provide optimizations for the same range of hardware.
@@ -473,9 +472,8 @@ the KOKKOS_ARCH setting in Makefile.kokkos_cuda), Or, as illustrated
 below, you can use the Make.py script with its "-kokkos" option to
 choose which hardware to build for.  Type "python src/Make.py -h
 -kokkos" to see the details.  If these methods do not work on your
-system, you will need to read the "Section accelerate
-kokkos"_accelerate_kokkos.html doc page for details of what
-Makefile.machine settings are needed.
+system, you will need to read the "Section 5.3.3"_accelerate_kokkos.html
+doc page for details of what Makefile.machine settings are needed.
 
 To install via make or Make.py for each of 3 hardware options:
 
@@ -495,11 +493,11 @@ make machine :pre
 
 Make.py -p ^kokkos -a machine :pre
 
-Supporting info: src/KOKKOS/README, lib/kokkos/README, "Section
-acclerate"_Section_accelerate.html, "Section accelerate
-kokkos"_accelerate_kokkos.html, Pair Styles section of "Section
-commands 3.5"_Section_commands.html#cmd_5 for any pair style listed
-with a (k), "package kokkos"_package.html,
+Supporting info: src/KOKKOS/README, lib/kokkos/README,
+"Section 5.3"_Section_accelerate.html#acc_3,
+"Section 5.3.3"_accelerate_kokkos.html,
+Pair Styles section of "Section 3.5"_Section_commands.html#cmd_5
+for any pair style listed with a (k), "package kokkos"_package.html,
 examples/accelerate, bench/FERMI, bench/KEPLER
 
 :line
@@ -514,7 +512,7 @@ particle-mesh (PPPM), and multilevel summation method (MSM) solvers.
 Building with the KSPACE package requires a 1d FFT library be present
 on your system for use by the PPPM solvers.  This can be the KISS FFT
 library provided with LAMMPS, or 3rd party libraries like FFTW or a
-vendor-supplied FFT library.  See step 6 of "Section start
+vendor-supplied FFT library.  See step 6 of "Section
 2.2.2"_Section_start.html#start_2_2 of the manual for details of how
 to select different FFT options in your machine Makefile.  The Make.py
 tool has an "-fft" option which can insert these settings into your
@@ -536,12 +534,13 @@ make machine :pre
 Make.py -p ^kspace -a machine :pre
 
 Supporting info: "kspace_style"_kspace_style.html,
-"doc/PDF/kspace.pdf"_PDF/kspace.pdf, "Section howto
-6.7"_Section_howto.html#howto_7, "Section howto
-6.8"_Section_howto.html#howto_8, "Section howto
-6.9"_Section_howto.html#howto_9, "pair_style coul"_pair_coul.html,
-other pair style command doc pages which have "long" or "msm" in their
-style name, examples/peptide, bench/in.rhodo
+"doc/PDF/kspace.pdf"_PDF/kspace.pdf,
+"Section 6.7"_Section_howto.html#howto_7,
+"Section 6.8"_Section_howto.html#howto_8,
+"Section 6.9"_Section_howto.html#howto_9,
+"pair_style coul"_pair_coul.html, other pair style command doc pages
+which have "long" or "msm" in their style name,
+examples/peptide, bench/in.rhodo
 
 :line
 
@@ -568,7 +567,7 @@ Make.py -p ^manybody -a machine :pre
 
 Supporting info:
 
-Examples: Pair Styles section of "Section commands
+Examples: Pair Styles section of "Section
 3.5"_Section_commands.html#cmd_5, examples/comb, examples/eim,
 examples/nb3d, examples/vashishta
 
@@ -700,9 +699,9 @@ Supporting info:"atom_style"_atom_style.html,
 "dihedral_style"_dihedral_style.html,
 "improper_style"_improper_style.html, "pair_style
 hbond/dreiding/lj"_pair_hbond_dreiding.html, "pair_style
-lj/charmm/coul/charmm"_pair_charmm.html, "Section howto
-6.3"_Section_howto.html#howto_3, examples/micelle, examples/peptide,
-bench/in.chain, bench/in.rhodo
+lj/charmm/coul/charmm"_pair_charmm.html,
+"Section 6.3"_Section_howto.html#howto_3,
+examples/micelle, examples/peptide, bench/in.chain, bench/in.rhodo
 
 :line
 
@@ -738,7 +737,7 @@ OPT package :link(OPT),h5
 Contents: A handful of pair styles with an "opt" in their style name
 which are optimized for improved CPU performance on single or multiple
 cores.  These include EAM, LJ, CHARMM, and Morse potentials.  "Section
-accelerate opt"_accelerate_opt.html gives details of how to build and
+5.3.5"_accelerate_opt.html gives details of how to build and
 use this package.  See the KOKKOS, USER-INTEL, and USER-OMP packages,
 which also have styles optimized for CPU performance.
 
@@ -763,10 +762,10 @@ make machine :pre
 
 Make.py -p ^opt -a machine :pre
 
-Supporting info: "Section acclerate"_Section_accelerate.html, "Section
-accelerate opt"_accelerate_opt.html, Pair Styles section of "Section
-commands 3.5"_Section_commands.html#cmd_5 for any pair style listed
-with an (o), examples/accelerate, bench/KEPLER
+Supporting info: "Section 5.3"_Section_accelerate.html#acc_3,
+"Section 5.3.5"_accelerate_opt.html, Pair Styles section of
+"Section 3.5"_Section_commands.html#cmd_5 for any pair style
+listed with an (t), examples/accelerate, bench/KEPLER
 
 :line
 
@@ -845,14 +844,14 @@ PYTHON package :link(PYTHON),h5
 
 Contents: A "python"_python.html command which allow you to execute
 Python code from a LAMMPS input script.  The code can be in a separate
-file or embedded in the input script itself.  See "Section python
-11.2"_Section_python.html" for an overview of using Python from
+file or embedded in the input script itself.  See "Section
+11.2"_Section_python.html#py_2 for an overview of using Python from
 LAMMPS and for other ways to use LAMMPS and Python together.
 
 Building with the PYTHON package assumes you have a Python shared
 library available on your system, which needs to be a Python 2
-version, 2.6 or later.  Python 3 is not supported.  The build uses the
-contents of the lib/python/Makefile.lammps file to find all the Python
+version, 2.6 or later.  Python 3 is not yet supported.  The build uses
+the contents of the lib/python/Makefile.lammps file to find all the Python
 files required in the build/link process.  See the lib/python/README
 file if the settings in that file do not work on your system.  Note
 that the Make.py script has a "-python" option to allow an alternate
@@ -950,7 +949,7 @@ REPLICA package :link(REPLICA),h5
 Contents: A collection of multi-replica methods that are used by
 invoking multiple instances (replicas) of LAMMPS
 simulations. Communication between individual replicas is performed in
-different ways by the different methods.  See "Section howto
+different ways by the different methods.  See "Section
 6.5"_Section_howto.html#howto_5 for an overview of how to run
 multi-replica simulations in LAMMPS.  Multi-replica methods included
 in the package are nudged elastic band (NEB), parallel replica
@@ -973,7 +972,7 @@ make machine :pre
 
 Make.py -p ^replica -a machine :pre
 
-Supporting info: "Section howto 6.5"_Section_howto.html#howto_5,
+Supporting info: "Section 6.5"_Section_howto.html#howto_5,
 "neb"_neb.html, "prd"_prd.html, "tad"_tad.html, "temper"_temper.html,
 "run_style verlet/split"_run_style.html, examples/neb, examples/prd,
 examples/tad
@@ -1148,13 +1147,13 @@ Package, Description, Author(s), Doc page, Example, Pic/movie, Library
 "USER-EFF"_#USER-EFF, electron force field, Andres Jaramillo-Botero (Caltech), "pair_style eff/cut"_pair_eff.html, USER/eff, "eff"_eff, -
 "USER-FEP"_#USER-FEP, free energy perturbation, Agilio Padua (U Blaise Pascal Clermont-Ferrand), "compute fep"_compute_fep.html, USER/fep, -, -
 "USER-H5MD"_#USER-H5MD, dump output via HDF5, Pierre de Buyl (KU Leuven), "dump h5md"_dump_h5md.html, -, -, lib/h5md
-"USER-INTEL"_#USER-INTEL, Vectorized CPU and Intel(R) coprocessor styles, W. Michael Brown (Intel), "Section accelerate"_accelerate_intel.html, examples/intel, -, -
+"USER-INTEL"_#USER-INTEL, Vectorized CPU and Intel(R) coprocessor styles, W. Michael Brown (Intel), "Section 5.3.2"_accelerate_intel.html, examples/intel, -, -
 "USER-LB"_#USER-LB, Lattice Boltzmann fluid, Colin Denniston (U Western Ontario), "fix lb/fluid"_fix_lb_fluid.html, USER/lb, -, -
 "USER-MGPT"_#USER-MGPT, fast MGPT multi-ion potentials, Tomas Oppelstrup & John Moriarty (LLNL), "pair_style mgpt"_pair_mgpt.html, USER/mgpt, -, -
 "USER-MISC"_#USER-MISC, single-file contributions, USER-MISC/README, USER-MISC/README, -, -, -
 "USER-MANIFOLD"_#USER-MANIFOLD, motion on 2d surface, Stefan Paquay (Eindhoven U of Technology), "fix manifoldforce"_fix_manifoldforce.html, USER/manifold, "manifold"_manifold, -
 "USER-MOLFILE"_#USER-MOLFILE, "VMD"_VMD molfile plug-ins, Axel Kohlmeyer (Temple U), "dump molfile"_dump_molfile.html, -, -, VMD-MOLFILE
-"USER-OMP"_#USER-OMP, OpenMP threaded styles, Axel Kohlmeyer (Temple U), "Section accelerate"_accelerate_omp.html, -, -, -
+"USER-OMP"_#USER-OMP, OpenMP threaded styles, Axel Kohlmeyer (Temple U), "Section 5.3.4"_accelerate_omp.html, -, -, -
 "USER-PHONON"_#USER-PHONON, phonon dynamical matrix, Ling-Ti Kong (Shanghai Jiao Tong U), "fix phonon"_fix_phonon.html, USER/phonon, -, -
 "USER-QMMM"_#USER-QMMM, QM/MM coupling, Axel Kohlmeyer (Temple U), "fix qmmm"_fix_qmmm.html, USER/qmmm, -, lib/qmmm
 "USER-QTB"_#USER-QTB, quantum nuclear effects, Yuan Shen (Stanford), "fix qtb"_fix_qtb.html "fix qbmsst"_fix_qbmsst.html, qtb, -, -
@@ -1353,12 +1352,12 @@ USER-DRUDE package :link(USER-DRUDE),h5
 
 Contents: This package contains methods for simulating polarizable
 systems using thermalized Drude oscillators.  It has computes, fixes,
-and pair styles for this purpose.  See "Section howto
+and pair styles for this purpose.  See "Section
 6.27"_Section_howto.html#howto_27 for an overview of how to use the
 package.  See src/USER-DRUDE/README for additional details.  There are
 auxiliary tools for using this package in tools/drude.
 
-Supporting info: "Section howto 6.27"_Section_howto.html#howto_27,
+Supporting info: "Section 6.27"_Section_howto.html#howto_27,
 src/USER-DRUDE/README, "fix drude"_fix_drude.html, "fix
 drude/transform/*"_fix_drude_transform.html, "compute
 temp/drude"_compute_temp_drude.html, "pair thole"_pair_thole.html,
@@ -1432,7 +1431,7 @@ USER-INTEL package :link(USER-INTEL),h5
 Contents: Dozens of pair, bond, angle, dihedral, and improper styles
 that are optimized for Intel CPUs and the Intel Xeon Phi (in offload
 mode).  All of them have an "intel" in their style name.  "Section
-accelerate intel"_accelerate_intel.html gives details of what hardware
+5.3.2"_accelerate_intel.html gives details of what hardware
 and compilers are required on your system, and how to build and use
 this package.  Also see src/USER-INTEL/README for more details. See
 the KOKKOS, OPT, and USER-OMP packages, which also have CPU and
@@ -1440,7 +1439,7 @@ Phi-enabled styles.
 
 Supporting info: examples/accelerate, src/USER-INTEL/TEST
 
-"Section 5"_Section_accelerate.html#acc_3
+"Section 5.3"_Section_accelerate.html#acc_3
 
 Author: Mike Brown at Intel (michael.w.brown at intel.com).  Contact
 him directly if you have questions.
@@ -1532,7 +1531,7 @@ More information about each feature can be found by reading its doc
 page in the LAMMPS doc directory.  The doc page which lists all LAMMPS
 input script commands is as follows:
 
-"Section 3"_Section_commands.html#cmd_5
+"Section 3.5"_Section_commands.html#cmd_5
 
 User-contributed features are listed at the bottom of the fix,
 compute, pair, etc sections.
@@ -1609,7 +1608,7 @@ styles, and fix styles.
 
 See this section of the manual to get started:
 
-"Section 5"_Section_accelerate.html#acc_3
+"Section 5.3"_Section_accelerate.html#acc_3
 
 The person who created this package is Axel Kohlmeyer at Temple U
 (akohlmey at gmail.com).  Contact him directly if you have questions.

doc/src/Section_perf.txt

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

doc/src/Section_start.txt

@@ -21,7 +21,6 @@ experienced users.
 2.8 "Screen output"_#start_8
 2.9 "Tips for users of previous versions"_#start_9 :all(b)
 
-:line
 :line
 
 2.1 What's in the LAMMPS distribution :h4,link(start_1)
@@ -70,12 +69,12 @@ launch a LAMMPS Windows executable on a Windows box.
 
 This section has the following sub-sections:
 
-"Read this first"_#start_2_1
-"Steps to build a LAMMPS executable"_#start_2_2
-"Common errors that can occur when making LAMMPS"_#start_2_3
-"Additional build tips"_#start_2_4
-"Building for a Mac"_#start_2_5
-"Building for Windows"_#start_2_6 :ul
+2.2.1 "Read this first"_#start_2_1
+2.2.1 "Steps to build a LAMMPS executable"_#start_2_2
+2.2.3 "Common errors that can occur when making LAMMPS"_#start_2_3
+2.2.4 "Additional build tips"_#start_2_4
+2.2.5 "Building for a Mac"_#start_2_5
+2.2.6 "Building for Windows"_#start_2_6 :all(b)
 
 :line
 
@@ -559,8 +558,7 @@ Typing "make clean-all" or "make clean-machine" will delete *.o object
 files created when LAMMPS is built, for either all builds or for a
 particular machine.
 
- Changing the LAMMPS size limits via -DLAMMPS_SMALLBIG or
--DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL :h6
+Changing the LAMMPS size limits via -DLAMMPS_SMALLBIG or -DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL :h6
 
 As explained above, any of these 3 settings can be specified on the
 LMP_INC line in your low-level src/MAKE/Makefile.foo.
@@ -612,7 +610,7 @@ neighbor lists and would run very slowly in terms of CPU secs/timestep.
 
 Building for a Mac :h5,link(start_2_5)
 
-OS X is BSD Unix, so it should just work.  See the
+OS X is a derivative of BSD Unix, so it should just work.  See the
 src/MAKE/MACHINES/Makefile.mac and Makefile.mac_mpi files.
 
 :line
@@ -637,9 +635,9 @@ happy to distribute contributed instructions and modifications, but
 we cannot provide support for those.
 
 With the so-called "Anniversary Update" to Windows 10, there is a
-Ubuntu subsystem available for Windows, that can be installed and
-then it can be used to compile/install LAMMPS as if you are running
-on a Ubuntu Linux system.
+Ubuntu Linux subsystem available for Windows, that can be installed
+and then used to compile/install LAMMPS as if you are running on a
+Ubuntu Linux system instead of Windows.
 
 As an alternative, you can download "daily builds" (and some older
 versions) of the installer packages from
@@ -654,10 +652,10 @@ many examples, but no source code.
 
 This section has the following sub-sections:
 
-"Package basics"_#start_3_1
-"Including/excluding packages"_#start_3_2
-"Packages that require extra libraries"_#start_3_3
-"Packages that require Makefile.machine settings"_#start_3_4 :ul
+2.3.1 "Package basics"_#start_3_1
+2.3.2 "Including/excluding packages"_#start_3_2
+2.3.3 "Packages that require extra libraries"_#start_3_3
+2.3.4 "Packages that require Makefile.machine settings"_#start_3_4 :all(b)
 
 Note that the following "Section 2.4"_#start_4 describes the Make.py
 tool which can be used to install/un-install packages and build the
@@ -673,7 +671,7 @@ are always included, plus optional packages.  Packages are groups of
 files that enable a specific set of features.  For example, force
 fields for molecular systems or granular systems are in packages.
 
-"Section packages"_Section_packages.html in the manual has details
+"Section 4"_Section_packages.html in the manual has details
 about all the packages, including specific instructions for building
 LAMMPS with each package, which are covered in a more general manner
 below.
@@ -727,15 +725,15 @@ before building LAMMPS.  From the src directory, this is typically as
 simple as:
 
 make yes-colloid
-make g++ :pre
+make mpi :pre
 
 or
 
 make no-manybody
-make g++ :pre
+make mpi :pre
 
 NOTE: You should NOT include/exclude packages and build LAMMPS in a
-single make command using multiple targets, e.g. make yes-colloid g++.
+single make command using multiple targets, e.g. make yes-colloid mpi.
 This is because the make procedure creates a list of source files that
 will be out-of-date for the build if the package configuration changes
 within the same command.
@@ -826,7 +824,7 @@ where to find them.
 For libraries with provided code, the sub-directory README file
 (e.g. lib/atc/README) has instructions on how to build that library.
 This information is also summarized in "Section
-packages"_Section_packages.html.  Typically this is done by typing
+4"_Section_packages.html.  Typically this is done by typing
 something like:
 
 make -f Makefile.g++ :pre
@@ -885,17 +883,17 @@ A few packages require specific settings in Makefile.machine, to
 either build or use the package effectively.  These are the
 USER-INTEL, KOKKOS, USER-OMP, and OPT packages, used for accelerating
 code performance on CPUs or other hardware, as discussed in "Section
-acclerate"_Section_accelerate.html. 
+5.3"_Section_accelerate.html#acc_3.
 
 A summary of what Makefile.machine changes are needed for each of
-these packages is given in "Section packages"_Section_packages.html.
+these packages is given in "Section 4"_Section_packages.html.
 The details are given on the doc pages that describe each of these
 accelerator packages in detail:
 
-"USER-INTEL package"_accelerate_intel.html
-"KOKKOS package"_accelerate_kokkos.html
-"USER-OMP package"_accelerate_omp.html
-"OPT package"_accelerate_opt.html :ul
+5.3.1 "USER-INTEL package"_accelerate_intel.html
+5.3.3 "KOKKOS package"_accelerate_kokkos.html
+5.3.4 "USER-OMP package"_accelerate_omp.html
+5.3.5 "OPT package"_accelerate_opt.html :all(b)
 
 You can also look at the following machine Makefiles in
 src/MAKE/OPTIONS, which include the changes.  Note that the USER-INTEL
@@ -1367,7 +1365,7 @@ Note that the keywords do not use a leading minus sign.  I.e. the
 keyword is "t", not "-t".  Also note that each of the keywords has a
 default setting.  Example of when to use these options and what
 settings to use on different platforms is given in "Section
-5.8"_Section_accelerate.html#acc_3.
+5.3"_Section_accelerate.html#acc_3.
 
 d or device
 g or gpus

doc/src/Section_tools.txt

@@ -107,9 +107,10 @@ The ch2lmp sub-directory contains tools for converting files
 back-and-forth between the CHARMM MD code and LAMMPS.
 
 They are intended to make it easy to use CHARMM as a builder and as a
-post-processor for LAMMPS. Using charmm2lammps.pl, you can convert an
-ensemble built in CHARMM into its LAMMPS equivalent.  Using
-lammps2pdb.pl you can convert LAMMPS atom dumps into pdb files.
+post-processor for LAMMPS. Using charmm2lammps.pl, you can convert a
+PDB file with associated CHARMM info, including CHARMM force field
+data, into its LAMMPS equivalent.  Using lammps2pdb.pl you can convert
+LAMMPS atom dumps into PDB files.
 
 See the README file in the ch2lmp sub-directory for more information.
 

doc/src/accelerate_kokkos.txt

@@ -156,19 +156,25 @@ CPU-only (run all-MPI or with OpenMP threading):
 
 cd lammps/src
 make yes-kokkos
-make g++ KOKKOS_DEVICES=OpenMP :pre
+make kokkos_omp :pre
 
-Intel Xeon Phi:
+CPU-only (only MPI, no threading):
 
 cd lammps/src
 make yes-kokkos
-make g++ KOKKOS_DEVICES=OpenMP KOKKOS_ARCH=KNC :pre
+make kokkos_mpi :pre
 
-CPUs and GPUs:
+Intel Xeon Phi (Intel Compiler, Intel MPI):
 
 cd lammps/src
 make yes-kokkos
-make cuda KOKKOS_DEVICES=Cuda :pre
+make kokkos_phi :pre
+
+CPUs and GPUs (with MPICH):
+
+cd lammps/src
+make yes-kokkos
+make kokkos_cuda_mpich :pre
 
 These examples set the KOKKOS-specific OMP, MIC, CUDA variables on the
 make command line which requires a GNU-compatible make command.  Try
@@ -180,26 +186,6 @@ first two examples above, then you *must* perform a "make clean-all"
 or "make clean-machine" before each build.  This is to force all the
 KOKKOS-dependent files to be re-compiled with the new options.
 
-You can also hardwire these make variables in the specified machine
-makefile, e.g. src/MAKE/Makefile.g++ in the first two examples above,
-with a line like:
-
-KOKKOS_ARCH = KNC :pre
-
-Note that if you build LAMMPS multiple times in this manner, using
-different KOKKOS options (defined in different machine makefiles), you
-do not have to worry about doing a "clean" in between.  This is
-because the targets will be different.
-
-NOTE: The 3rd example above for a GPU, uses a different machine
-makefile, in this case src/MAKE/Makefile.cuda, which is included in
-the LAMMPS distribution.  To build the KOKKOS package for a GPU, this
-makefile must use the NVIDA "nvcc" compiler.  And it must have a
-KOKKOS_ARCH setting that is appropriate for your NVIDIA hardware and
-installed software.  Typical values for KOKKOS_ARCH are given below,
-as well as other settings that must be included in the machine
-makefile, if you create your own.
-
 NOTE: Currently, there are no precision options with the KOKKOS
 package.  All compilation and computation is performed in double
 precision.
@@ -246,7 +232,7 @@ used if running with KOKKOS_DEVICES=Pthreads for pthreads.  It is not
 necessary for KOKKOS_DEVICES=OpenMP for OpenMP, because OpenMP
 provides alternative methods via environment variables for binding
 threads to hardware cores.  More info on binding threads to cores is
-given in "this section"_Section_accelerate.html#acc_3.
+given in "Section 5.3"_Section_accelerate.html#acc_3.
 
 KOKKOS_ARCH=KNC enables compiler switches needed when compling for an
 Intel Phi processor.

doc/src/accelerate_omp.txt

@@ -7,7 +7,7 @@
 
 :line
 
-"Return to Section accelerate overview"_Section_accelerate.html
+"Return to Section 5 overview"_Section_accelerate.html
 
 5.3.4 USER-OMP package :h5
 
@@ -103,8 +103,8 @@ USER-OMP style (in serial or parallel) with a single thread per MPI
 task, versus running standard LAMMPS with its standard un-accelerated
 styles (in serial or all-MPI parallelization with 1 task/core).  This
 is because many of the USER-OMP styles contain similar optimizations
-to those used in the OPT package, described in "Section accelerate
-5.3.6"_accelerate_opt.html.
+to those used in the OPT package, described in "Section
+5.3.5"_accelerate_opt.html.
 
 With multiple threads/task, the optimal choice of number of MPI
 tasks/node and OpenMP threads/task can vary a lot and should always be

doc/src/balance.txt

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

doc/src/compute_property_local.txt

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

@@ -35,7 +35,12 @@ group/group"_compute_group_group.html only that the data is
 accumulated directly during the non-bonded force computation. The
 computes {force/tally}, {pe/tally}, {stress/tally}, and
 {heat/flux/tally} are primarily provided as example how to program
-additional, more sophisticated computes using the tally mechanism.
+additional, more sophisticated computes using the tally callback
+mechanism. Compute {pe/mol/tally} is one such style, that can
+- through using this mechanism - separately tally intermolecular
+and intramolecular energies. Something that would otherwise be
+impossible without integrating this as a core functionality into
+the based classes of LAMMPS.
 
 :line
 
@@ -56,7 +61,7 @@ atom scalar (the contributions of the single atom to the global
 scalar). Compute {pe/mol/tally} calculates a global 4-element vector
 containing (in this order): {evdwl} and {ecoul} for intramolecular pairs
 and {evdwl} and {ecoul} for intermolecular pairs. Since molecules are
-identified my their molecule IDs, the partitioning does not have to be
+identified by their molecule IDs, the partitioning does not have to be
 related to molecules, but the energies are tallied into the respective
 slots depending on whether the molecule IDs of a pair are the same or
 different. Compute {force/tally} calculates a global scalar (the force

doc/src/dump.txt

@@ -328,8 +328,8 @@ bonds and colors.
 
 Note that {atom}, {custom}, {dcd}, {xtc}, and {xyz} style dump files
 can be read directly by "VMD"_http://www.ks.uiuc.edu/Research/vmd, a
-popular molecular viewing program.  See "Section
-tools"_Section_tools.html#vmd of the manual and the
+popular molecular viewing program.  See
+"Section 9"_Section_tools.html#vmd of the manual and the
 tools/lmp2vmd/README.txt file for more information about support in
 VMD for reading and visualizing LAMMPS dump files.
 
@@ -390,7 +390,7 @@ Using MPI-IO requires two steps.  First, build LAMMPS with its MPIIO
 package installed, e.g.
 
 make yes-mpiio    # installs the MPIIO package
-make g++          # build LAMMPS for your platform :pre
+make mpi          # build LAMMPS for your platform :pre
 
 Second, use a dump filename which contains ".mpiio".  Note that it
 does not have to end in ".mpiio", just contain those characters.
@@ -531,7 +531,7 @@ so that each value is 0.0 to 1.0.  If the simulation box is triclinic
 (tilted), then all atom coords will still be between 0.0 and 1.0.
 I.e. actual unscaled (x,y,z) = xs*A + ys*B + zs*C, where (A,B,C) are
 the non-orthogonal vectors of the simulation box edges, as discussed
-in "Section howto 6.12"_Section_howto.html#howto_12.
+in "Section 6.12"_Section_howto.html#howto_12.
 
 Use {xu}, {yu}, {zu} if you want the coordinates "unwrapped" by the
 image flags for each atom.  Unwrapped means that if the atom has

doc/src/dump_modify.txt

@@ -49,8 +49,8 @@ keyword = {append} or {buffer} or {element} or {every} or {fileper} or {first} o
      -N = sort per-atom lines in descending order by the Nth column
   {thresh} args = attribute operation value
     attribute = same attributes (x,fy,etotal,sxx,etc) used by dump custom style
-    operation = "<" or "<=" or ">" or ">=" or "==" or "!="
-    value = numeric value to compare to
+    operation = "<" or "<=" or ">" or ">=" or "==" or "!=" or "|^"
+    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
@@ -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
-than are used as threshold criteria by the dump_modify command.
-E.g. you can output the coordinates and stress of atoms whose energy
-is above some threshold.
+that a different attributes can be used than those output by the "dump
+custom"_dump.html command.  E.g. you can output the coordinates and
+stress of atoms whose energy 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 operation.  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 operations 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
 

doc/src/dump_molfile.txt

@@ -34,7 +34,7 @@ to one or more files every N timesteps in one of several formats.
 Only information for atoms in the specified group is dumped.  This
 specific dump style uses molfile plugins that are bundled with the
 "VMD"_http://www.ks.uiuc.edu/Research/vmd molecular visualization and
-analysis program.  See "Section tools"_Section_tools.html#vmd of the
+analysis program.  See "Section 9"_Section_tools.html#vmd of the
 manual and the tools/lmp2vmd/README.txt file for more information
 about support in VMD for reading and visualizing native LAMMPS dump
 files.

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
-zero or more keyword/value pairs may be appended :l
-keyword = {out} :l
-  {out} value = filename
+  {rcb} args = none :pre
+zero or more keyword/arg pairs may be appended :l
+keyword = {weight} or {out} :l
+  {weight} style args = use weighted particle counts for the balancing
+    {style} = {group} or {neigh} or {time} or {var} or {store}
+      {group} args = Ngroup group1 weight1 group2 weight2 ...
+        Ngroup = number of groups with assigned weights
+        group1, group2, ... = group IDs
+        weight1, weight2, ...   = corresponding weight factors
+      {neigh} factor = compute weight based on number of neighbors
+        factor = scaling factor (> 0)
+      {time} factor = compute weight based on time spend computing
+        factor = scaling factor (> 0)
+      {var} name = take weight from atom-style variable
+        name = name of the atom-style variable
+      {store} name = store weight in custom atom property defined by "fix property/atom"_fix_property_atom.html command
+        name = atom property name (without d_ prefix)
+  {out} arg = filename
     filename = write each processor's sub-domain to a file, 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
-simulation box have a spatially-varying density distribution.  E.g. a
-model of a vapor/liquid interface, or a solid with an irregular-shaped
-geometry containing void regions.  In this case, the LAMMPS default of
-dividing the simulation box volume into a regular-spaced grid of 3d
-bricks, with one equal-volume sub-domain per processor, may assign
-very different numbers of particles per processor.  This can lead to
-poor performance when the simulation is run in parallel.
+Load-balancing is typically most useful if the particles in the
+simulation box have a spatially-varying density distribution or
+where the computational cost varies signficantly between different
+atoms. 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 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,
-divided by the average number of particles per processor.  Thus an
-imbalance factor of 1.0 is perfect balance.
+defined as the maximum number of particles (or weight) owned by any
+processor, divided by the average number of particles (or weight) per
+processor.  Thus an imbalance factor of 1.0 is perfect balance.
 
 As an example, for 10000 particles running on 10 processors, if the
 most heavily loaded processor has 1200 particles, then the factor is
@@ -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
-in the rightmost diagram above.
+fashion so as to have equal numbers of particles (or weight) in each
+sub-box, as in the rightmost diagram above.
 
 The "grid" methods can be used with either of the
 "comm_style"_comm_style.html command options, {brick} or {tiled}.  The
@@ -139,12 +174,9 @@ from scratch.
 
 :line
 
-The {group-ID} is currently ignored.  In the future it may be used to
-determine what particles are considered for balancing.  Normally it
-would only makes sense to use the {all} group.  But in some cases it
-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 {group-ID} is ignored.  However the impact of balancing on
+different groups of atoms can be affected by using the {group} weight
+style as described below.
 
 The {Nfreq} setting determines how often a rebalance is performed.  If
 {Nfreq} > 0, then rebalancing will occur every {Nfreq} steps.  Each
@@ -250,10 +282,10 @@ in that sub-box.
 
 :line
 
-The {out} keyword writes a text file to the specified {filename} with
-the results of each rebalancing operation.  The file contains the
-bounds of the sub-domain for each processor after the balancing
-operation completes.  The format of the file is compatible with the
+The {out} keyword writes text to the specified {filename} with the
+results of each rebalancing operation.  The file contains the bounds
+of the sub-domain for each processor after the balancing operation
+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
-particles per processor.
+number of particles (or total weight) on any processor to the average
+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}
-style.
+For 2d simulations, the {z} style cannot be used.  Nor can a "z"
+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

@@ -0,0 +1,132 @@
+"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 cmap command :h3
+
+[Syntax:]
+
+fix ID group-ID cmap filename :pre
+
+ID, group-ID are documented in "fix"_fix.html command
+cmap = style name of this fix command
+filename = force-field file with CMAP coefficients :ul
+
+[Examples:]
+
+fix            myCMAP all cmap ../potentials/cmap36.data
+read_data      proteinX.data fix myCMAP crossterm CMAP
+fix_modify     myCMAP energy yes :pre
+
+[Description:]
+
+This command enables CMAP crossterms to be added to simulations which
+use the CHARMM force field.  These are relevant for any CHARMM model
+of a peptide or protein sequences that is 3 or more amino-acid
+residues long; see "(Buck)"_#Buck and "(Brooks)"_#Brooks for details,
+including the analytic energy expressions for CMAP interactions.  The
+CMAP crossterms add additional potential energy contributions to pairs
+of overlapping phi-psi dihedrals of amino-acids, which are important
+to properly represent their conformational behavior.
+
+The examples/cmap directory has a sample input script and data file
+for a small peptide, that illustrates use of the fix cmap command.
+
+As in the example above, this fix should be used before reading a data
+file that contains a listing of CMAP interactions.  The {filename}
+specified should contain the CMAP parameters for a particular version
+of the CHARMM force field.  Two such files are including in the
+lammps/potentials directory: charmm22.cmap and charmm36.cmap.
+
+The data file read by the "read_data" must contain the topology of all
+the CMAP interactions, similar to the topology data for bonds, angles,
+dihedrals, etc.  Specically it should have a line like this
+in its header section:
+
+N crossterms :pre
+
+where N is the number of CMAP crossterms.  It should also have a section
+in the body of the data file like this with N lines:
+
+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;
+it is ignored by LAMMPS.  The 2nd column is the "type" of the
+interaction; it is an index into the CMAP force field file.  The
+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"_read_data.html doc page for
+more details.
+
+A data file containing CMAP crossterms can be generated from a PDB
+file using the charmm2lammps.pl script in the tools/ch2lmp directory
+of the LAMMPS distribution.  The script must be invoked with the
+optional "-cmap" flag to do this; see the tools/ch2lmp/README file for
+more information.
+
+The potential energy associated with CMAP interactions can be output
+as described below.  It can also be included in the total potential
+energy of the system, as output by the
+"thermo_style"_thermo_style.html command, if the "fix_modify
+energy"_fix_modify.html command is used, as in the example above.  See
+the note below about how to include the CMAP energy when performing an
+"energy minimization"_minimize.html.
+
+:line
+
+[Restart, fix_modify, output, run start/stop, minimize info:]
+
+No information about this fix is written to "binary restart
+files"_restart.html.
+
+The "fix_modify"_fix_modify.html {energy} option is supported by this
+fix to add the potential "energy" of the CMAP interactions system's
+potential energy as part of "thermodynamic output"_thermo_style.html.
+
+This fix computes a global scalar which can be accessed by various
+"output commands"_Section_howto.html#howto_15.  The scalar is the
+potential energy discussed above.  The scalar value calculated by this
+fix is "extensive".
+
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command.
+
+The forces due to this fix are imposed during an energy minimization,
+invoked by the "minimize"_minimize.html command.
+
+NOTE: If you want the potential energy associated with the CMAP terms
+forces to be included in the total potential energy of the system (the
+quantity being minimized), you MUST enable the
+"fix_modify"_fix_modify.html {energy} option for this fix.
+
+[Restrictions:]
+
+This fix can only be used if LAMMPS was built with the MOLECULE
+package (which it is by default).  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
+
+[Related commands:]
+
+"fix_modify"_fix_modify.html, "read_data"_read_data.html
+
+[Default:] none
+
+:line
+
+:link(Buck)
+[(Buck)] Buck, Bouguet-Bonnet, Pastor, MacKerell Jr., Biophys J, 90, L36
+(2006).
+
+:link(Brooks)
+[(Brooks)] Brooks, Brooks, MacKerell Jr., J Comput Chem, 30, 1545 (2009).

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_phonon.txt

@@ -43,10 +43,11 @@ fix 1 all phonon 10 5000 500000 GAMMA EAM0D nasr 100 :pre
 Calculate the dynamical matrix from molecular dynamics simulations
 based on fluctuation-dissipation theory for a group of atoms.
 
-Consider a crystal with \(N\) unit cells in three dimensions labelled \(l = (l_1, l_2, l_3)\) where \(l_i\)
-are integers.  Each unit cell is defined by three linearly independent
-vectors \(\mathbf\{a\}_1\), \(\mathbf\{a\}_2\), \(\mathbf\{a\}_3\) forming a
-parallelipiped, containing \(K\) basis atoms labeled \(k\).
+Consider a crystal with \(N\) unit cells in three dimensions labelled
+\(l = (l_1, l_2, l_3)\) where \(l_i\) are integers.  Each unit cell is
+defined by three linearly independent vectors \(\mathbf\{a\}_1\),
+\(\mathbf\{a\}_2\), \(\mathbf\{a\}_3\) forming a parallelipiped,
+containing \(K\) basis atoms labeled \(k\).
 
 Based on fluctuation-dissipation theory, the force constant
 coefficients of the system in reciprocal space are given by
@@ -62,18 +63,16 @@ where \(\mathbf\{G\}\) is the Green's functions coefficients given by
 \mathbf\{G\}_\{k\alpha,k^\prime \beta\}(\mathbf\{q\}) = \left< \mathbf\{u\}_\{k\alpha\}(\mathbf\{q\}) \bullet \mathbf\{u\}_\{k^\prime \beta\}^*(\mathbf\{q\}) \right>
 \end\{equation\}
 
-
 where \(\left< \ldots \right>\) denotes the ensemble average, and
 
 \begin\{equation\}
 \mathbf\{u\}_\{k\alpha\}(\mathbf\{q\}) = \sum_l \mathbf\{u\}_\{l k \alpha\} \exp\{(i\mathbf\{qr\}_l)\}
 \end\{equation\}
 
-
-is the \(\alpha\) component of the atomic displacement for the \(k\) th atom
-in the unit cell in reciprocal space at \(\mathbf\{q\}\). In practice, the Green's
-functions coefficients can also be measured according to the following
-formula,
+is the \(\alpha\) component of the atomic displacement for the \(k\)
+th atom in the unit cell in reciprocal space at \(\mathbf\{q\}\). In
+practice, the Green's functions coefficients can also be measured
+according to the following formula,
 
 \begin\{equation\}
 \mathbf\{G\}_\{k\alpha,k^\prime \beta\}(\mathbf\{q\}) =
@@ -81,12 +80,13 @@ formula,
 - \left<\mathbf\{R\}\right>_\{k \alpha\}(\mathbf\{q\}) \bullet \left<\mathbf\{R\}\right>^*_\{k^\prime \beta\}(\mathbf\{q\})
 \end\{equation\}
 
-where \(\mathbf\{R\}\) is the instantaneous positions of atoms, and \(\left<\mathbf\{R\}\right>\) is the
-averaged atomic positions. It gives essentially the same results as
-the displacement method and is easier to implement in an MD code.
+where \(\mathbf\{R\}\) is the instantaneous positions of atoms, and
+\(\left<\mathbf\{R\}\right>\) is the averaged atomic positions. It
+gives essentially the same results as the displacement method and is
+easier to implement in an MD code.
 
-Once the force constant matrix is known, the dynamical matrix \(\mathbf\{D\}\) can
-then be obtained by
+Once the force constant matrix is known, the dynamical matrix
+\(\mathbf\{D\}\) can then be obtained by
 
 \begin\{equation\}
 \mathbf\{D\}_\{k\alpha, k^\prime\beta\}(\mathbf\{q\}) =
@@ -100,10 +100,11 @@ two-point correlations.  To achieve this. the positions of the atoms
 are examined every {Nevery} steps and are Fourier-transformed into
 reciprocal space, where the averaging process and correlation
 computation is then done.  After every {Noutput} measurements, the
-matrix \(\mathbf\{G\}(\mathbf\{q\})\) is calculated and inverted to obtain the elastic
-stiffness coefficients.  The dynamical matrices are then constructed
-and written to {prefix}.bin.timestep files in binary format and to the
-file {prefix}.log for each wavevector \(\mathbf\{q\}\).
+matrix \(\mathbf\{G\}(\mathbf\{q\})\) is calculated and inverted to
+obtain the elastic stiffness coefficients.  The dynamical matrices are
+then constructed and written to {prefix}.bin.timestep files in binary
+format and to the file {prefix}.log for each wavevector
+\(\mathbf\{q\}\).
 
 A detailed description of this method can be found in
 ("Kong2011"_#Kong2011).
@@ -126,12 +127,13 @@ which lattice point; the lattice indices start from 0. An auxiliary
 code, "latgen"_http://code.google.com/p/latgen, can be employed to
 generate the compatible map file for various crystals.
 
-In case one simulates an aperiodic system, where the whole simulation box
-is treated as a unit cell, one can set {map_file} as {GAMMA}, so that the mapping
-info will be generated internally and a file is not needed. In this case, the
-dynamical matrix at only the gamma-point will/can be evaluated. Please keep in
-mind that fix-phonon is designed for cyrstals, it will be inefficient and
-even degrade the performance of lammps in case the unit cell is too large.
+In case one simulates an aperiodic system, where the whole simulation
+box is treated as a unit cell, one can set {map_file} as {GAMMA}, so
+that the mapping info will be generated internally and a file is not
+needed. In this case, the dynamical matrix at only the gamma-point
+will/can be evaluated. Please keep in mind that fix-phonon is designed
+for cyrstals, it will be inefficient and even degrade the performance
+of lammps in case the unit cell is too large.
 
 The calculated dynamical matrix elements are written out in
 "energy/distance^2/mass"_units.html units.  The coordinates for {q}

doc/src/fix_ti_spring.txt

@@ -99,8 +99,8 @@ center-of-mass fixed during the thermodynamic integration. A nonzero
 total velocity will result in divergences during the integration due
 to the fact that the atoms are 'attached' to their equilibrium
 positions by the Einstein crystal. Check the option {zero} of "fix
-langevin"_fix_langevin_html and "velocity"_velocity.html. The use of
-the Nose-Hoover thermostat ("fix nvt"_fix_nvt.html) is {NOT}
+langevin"_fix_langevin.html and "velocity"_velocity.html. The use of
+the Nose-Hoover thermostat ("fix nvt"_fix_nh.html) is {NOT}
 recommended due to its well documented issues with the canonical
 sampling of harmonic degrees of freedom (notice that the {chain}
 option will {NOT} solve this problem). The Langevin thermostat ("fix

doc/src/fix_wall_gran.txt

@@ -163,6 +163,8 @@ Any dimension (xyz) that has a granular wall must be non-periodic.
 
 [Related commands:]
 
-"fix move"_fix_move.html, "pair_style granular"_pair_gran.html
+"fix move"_fix_move.html, 
+"fix wall/gran/region"_fix_wall_gran_region.html, 
+"pair_style granular"_pair_gran.html
 
 [Default:] none

doc/src/fix_wall_gran_region.txt

@@ -0,0 +1,199 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+fix wall/gran/region command :h3
+
+[Syntax:]
+
+fix ID group-ID wall/gran/region fstyle Kn Kt gamma_n gamma_t xmu dampflag wallstyle regionID :pre
+
+ID, group-ID are documented in "fix"_fix.html command :ulb,l
+wall/region = style name of this fix command :l
+fstyle = style of force interactions between particles and wall :l
+  possible choices: hooke, hooke/history, hertz/history :pre
+Kn = elastic constant for normal particle repulsion (force/distance units or pressure units - see discussion below) :l
+Kt = elastic constant for tangential contact (force/distance units or pressure units - see discussion below) :l
+gamma_n = damping coefficient for collisions in normal direction (1/time units or 1/time-distance units - see discussion below) :l
+gamma_t = damping coefficient for collisions in tangential direction (1/time units or 1/time-distance units - see discussion below) :l
+xmu = static yield criterion (unitless value between 0.0 and 1.0e4) :l
+dampflag = 0 or 1 if tangential damping force is excluded or included :l
+wallstyle = region (see "fix wall/gran"_fix_wall_gran.html for options for other kinds of walls) :l
+region-ID = region whose boundary will act as wall :l,ule
+
+[Examples:]
+
+fix wall all wall/gran/region hooke/history 1000.0 200.0 200.0 100.0 0.5 1 region myCone :pre
+
+[Description:]
+
+Treat the surface of the geometric region defined by the {region-ID}
+as a bounding frictional wall which interacts with nearby finite-size
+granular particles when they are close enough to touch the wall.  See
+the "fix wall/region"_fix_wall_region.html and "fix
+wall/gran"_fix_wall_gran.html commands for related kinds of walls for
+non-granular particles and simpler wall geometries, respectively.
+
+Here are snapshots of example models using this command.
+Corresponding input scripts can be found in examples/granregion.
+Click on the images to see a bigger picture.  Movies of these
+simulations are "here on the Movies
+page"_http://lammps.sandia.gov/movies.html#granregion of the
+LAMMPS web site.
+
+:image(JPG/gran_funnel_small.jpg,JPG/gran_funnel.png)
+:image(JPG/gran_mixer_small.jpg,JPG/gran_mixer.png)
+
+:line
+
+The distance between a particle and the region boundary is the
+distance to the nearest point on the region surface.  The force the
+wall exerts on the particle is along the direction between that point
+and the particle center, which is the direction normal to the surface
+at that point.  Note that if the region surface is comprised of
+multiple "faces", then each face can exert a force on the particle if
+it is close enough.  E.g. for "region_style block"_region.html, a
+particle in the interior, near a corner of the block, could feel wall
+forces from 1, 2, or 3 faces of the block.
+
+Regions are defined using the "region"_region.html command.  Note that
+the region volume can be interior or exterior to the bounding surface,
+which will determine in which direction the surface interacts with
+particles, i.e. the direction of the surface normal. The exception to
+this is if one or more {open} options are specified for the region
+command, in which case particles interact with both the interior and
+exterior surfaces of regions.
+
+Regions can either be primitive shapes (block, sphere, cylinder, etc)
+or combinations of primitive shapes specified via the {union} or
+{intersect} region styles.  These latter styles can be used to
+construct particle containers with complex shapes.  Regions can also
+move dynamically via the "region"_region.html command keywords (move)
+and {rotate}, or change their shape by use of variables as inputs to
+the "region"_region.html command.  If such a region is used with this
+fix, then the region surface will move in time in the corresponding
+manner.
+
+NOTE: As discussed on the "region"_region.html command doc page,
+regions in LAMMPS do not get wrapped across periodic boundaries.  It
+is up to you to ensure that the region location with respect to
+periodic or non-periodic boundaries is specified appropriately via the
+"region"_region.html and "boundary"_boundary.html commands when using
+a region as a wall that bounds particle motion.
+ 
+NOTE: For primitive regions with sharp corners and/or edges (e.g. a
+block or cylinder), wall/particle forces are computed accurately for
+both interior and exterior regions.  For {union} and {intersect}
+regions, additional sharp corners and edges may be present due to the
+intersection of the surfaces of 2 or more primitive volumes.  These
+corners and edges can be of two types: concave or convex.  Concave
+points/edges are like the corners of a cube as seen by particles in
+the interior of a cube.  Wall/particle forces around these features
+are computed correctly.  Convex points/edges are like the corners of a
+cube as seen by particles exterior to the cube, i.e. the points jut
+into the volume where particles are present.  LAMMPS does NOT compute
+the location of these convex points directly, and hence wall/particle
+forces in the cutoff volume around these points suffer from
+inaccuracies.  The basic problem is that the outward normal of the
+surface is not continuous at these points.  This can cause particles
+to feel no force (they don't "see" the wall) when in one location,
+then move a distance epsilon, and suddenly feel a large force because
+they now "see" the wall.  In a worst-case scenario, this can blow
+particles out of the simulation box.  Thus, as a general rule you
+should not use the fix wall/gran/region command with {union} or
+{interesect} regions that have convex points or edges resulting from
+the union/intersection (convex points/edges in the union/intersection
+due to a single sub-region are still OK).
+
+NOTE: Similarly, you should not define {union} or {intersert} regions
+for use with this command that share an overlapping common face that
+is part of the overall outer boundary (interior boundary is OK), even
+if the face is smooth.  E.g. two regions of style block in a {union}
+region, where the two blocks overlap on one or more of their faces.
+This is because LAMMPS discards points that are part of multiple
+sub-regions when calculating wall/particle interactions, to avoid
+double-counting the interaction.  Having two coincident faces could
+cause the face to become invisible to the particles.  The solution is
+to make the two faces differ by epsilon in their position.
+
+The nature of the wall/particle interactions are determined by the
+{fstyle} setting.  It can be any of the styles defined by the
+"pair_style granular"_pair_gran.html commands.  Currently this is
+{hooke}, {hooke/history}, or {hertz/history}.  The equation for the
+force between the wall and particles touching it is the same as the
+corresponding equation on the "pair_style granular"_pair_gran.html doc
+page, but the effective radius is calculated using the radius of the
+particle and the radius of curvature of the wall at the contact point.
+
+Specifically, delta = radius - r = overlap of particle with wall,
+m_eff = mass of particle, and RiRj/Ri+Rj is the effective radius, with
+Rj replaced by the radius of curvature of the wall at the contact
+point.  The radius of curvature can be negative for a concave wall
+section, e.g. the interior of cylinder.  For a flat wall, delta =
+radius - r = overlap of particle with wall, m_eff = mass of particle,
+and the effective radius of contact is just the radius of the
+particle.
+
+The parameters {Kn}, {Kt}, {gamma_n}, {gamma_t}, {xmu} and {dampflag}
+have the same meaning and units as those specified with the
+"pair_style granular"_pair_gran.html commands.  This means a NULL can
+be used for either {Kt} or {gamma_t} as described on that page.  If a
+NULL is used for {Kt}, then a default value is used where {Kt} = 2/7
+{Kn}.  If a NULL is used for {gamma_t}, then a default value is used
+where {gamma_t} = 1/2 {gamma_n}.
+
+Note that you can choose a different force styles and/or different
+values for the 6 wall/particle coefficients than for particle/particle
+interactions.  E.g. if you wish to model the wall as a different
+material.
+
+[Restart, fix_modify, output, run start/stop, minimize info:]
+
+Similiar to "fix wall/gran"_fix_wall_gran.html command, this fix
+writes the shear friction state of atoms interacting with the wall to
+"binary restart files"_restart.html, so that a simulation can continue
+correctly if granular potentials with shear "history" effects are
+being used.  This fix also includes info about a moving region in the
+restart file.  See the "read_restart"_read_restart.html command for
+info on how to re-specify a fix in an input script that reads a
+restart file, so that the operation of the fix continues in an
+uninterrupted fashion.
+
+Note that info about region definitions is NOT included in restart
+files.  So you must re-define your region and if it is a moving
+region, define its motion attributes in a way that is consistent with
+the simulation that wrote the restart file.  In particular, if you
+want to change its motion attributes (e.g. its velocity), then you
+should insure the postition/orientation of the region at the initial
+restart timestep is the same as it was on the timestep the restart
+file was written.  If this is not possible, then you may need to
+ignore info in the restart file by defining a new fix wall/gran/region
+command in your restart script (e.g. with a different fix ID).
+
+None of the "fix_modify"_fix_modify.html options are relevant to this
+fix.  No global or per-atom quantities are stored by this fix for
+access by various "output commands"_Section_howto.html#howto_15.  No
+parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command.  This fix is not invoked during "energy
+minimization"_minimize.html.
+
+[Restrictions:]
+
+This fix is part of the GRANULAR package.  It is only enabled if
+LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+[Related commands:]
+
+"fix_move"_fix_move.html,
+"fix wall/gran"_fix_wall_gran.html, 
+"fix wall/region"_fix_wall_region.html,
+"pair_style granular"_pair_gran.html,
+"region"_region.html
+
+[Default:] none
+

doc/src/fix_wall_region.txt

@@ -85,8 +85,10 @@ to feel no force (they don't "see" the wall) when in one location,
 then move a distance epsilon, and suddenly feel a large force because
 they now "see" the wall.  In a worst-case scenario, this can blow
 particles out of the simulation box.  Thus, as a general rule you
-should not use the fix wall/region command with {union} or
-{interesect} regions that have convex points or edges.
+should not use the fix wall/gran/region command with {union} or
+{interesect} regions that have convex points or edges resulting from
+the union/intersection (convex points/edges in the union/intersection
+due to a single sub-region are still OK).
 
 NOTE: Similarly, you should not define {union} or {intersert} regions
 for use with this command that share an overlapping common face that

doc/src/fixes.txt

@@ -24,6 +24,7 @@ Fixes :h1
    fix_bond_create
    fix_bond_swap
    fix_box_relax
+   fix_cmap
    fix_colvars
    fix_controller
    fix_deform
@@ -138,7 +139,6 @@ Fixes :h1
    fix_temp_rescale_eff
    fix_tfmc
    fix_thermal_conductivity
-   fix_ti_rs
    fix_ti_spring
    fix_tmd
    fix_ttm

doc/src/if.txt

@@ -139,7 +139,7 @@ InP, myString, a123, ab_23_cd, etc :pre
 
 and Boolean operators:
 
-A == B, A != B, A < B, A <= B, A > B, A >= B, A && B, A || B, !A :pre
+A == B, A != B, A < B, A <= B, A > B, A >= B, A && B, A || B, A |^ B, !A :pre
 
 Each A and B is a number or string or a variable reference like $a or
 $\{abc\}, or A or B can be another Boolean expression.
@@ -155,9 +155,10 @@ precedence: the unary logical NOT operator "!" has the highest
 precedence, the 4 relational operators "<", "<=", ">", and ">=" are
 next; the two remaining relational operators "==" and "!=" are next;
 then the logical AND operator "&&"; and finally the logical OR
-operator "||" has the lowest precedence.  Parenthesis can be used to
-group one or more portions of an expression and/or enforce a different
-order of evaluation than what would occur with the default precedence.
+operator "||" and logical XOR (exclusive or) operator "|^" have the
+lowest precedence.  Parenthesis can be used to group one or more
+portions of an expression and/or enforce a different order of
+evaluation than what would occur with the default precedence.
 
 When the 6 relational operators (first 6 in list above) compare 2
 numbers, they return either a 1.0 or 0.0 depending on whether the
@@ -171,9 +172,11 @@ relationship between A and B is TRUE or FALSE (or just A).  The
 logical AND operator will return 1.0 if both its arguments are
 non-zero, else it returns 0.0.  The logical OR operator will return
 1.0 if either of its arguments is non-zero, else it returns 0.0.  The
-logical NOT operator returns 1.0 if its argument is 0.0, else it
-returns 0.0.  The 3 logical operators can only be used to operate on
-numbers, not on strings.
+logical XOR operator will return 1.0 if one of its arguments is zero
+and the other non-zero, else it returns 0.0.  The logical NOT operator
+returns 1.0 if its argument is 0.0, else it returns 0.0.  The 3
+logical operators can only be used to operate on numbers, not on
+strings.
 
 The overall Boolean expression produces a TRUE result if the result is
 non-zero.  If the result is zero, the expression result is FALSE.

doc/src/lammps.book

@@ -147,6 +147,7 @@ fix_bond_break.html
 fix_bond_create.html
 fix_bond_swap.html
 fix_box_relax.html
+fix_cmap.html
 fix_colvars.html
 fix_controller.html
 fix_deform.html

doc/src/neb.txt

@@ -48,17 +48,14 @@ follows the discussion in these 3 papers: "(HenkelmanA)"_#HenkelmanA,
 
 Each replica runs on a partition of one or more processors.  Processor
 partitions are defined at run-time using the -partition command-line
-switch; see "Section 2.7"_Section_start.html#start_7 of the
-manual.  Note that if you have MPI installed, you can run a
-multi-replica simulation with more replicas (partitions) than you have
-physical processors, e.g you can run a 10-replica simulation on just
-one or two processors.  You will simply not get the performance
-speed-up you would see with one or more physical processors per
-replica.  See "this section"_Section_howto.html#howto_5 of the manual
-for further discussion.
-
-NOTE: The current NEB implementation in LAMMPS only allows there to be
-one processor per replica.
+switch; see "Section 2.7"_Section_start.html#start_7 of the manual.
+Note that if you have MPI installed, you can run a multi-replica
+simulation with more replicas (partitions) than you have physical
+processors, e.g you can run a 10-replica simulation on just one or two
+processors.  You will simply not get the performance speed-up you
+would see with one or more physical processors per replica.  See
+"Section 6.5"_Section_howto.html#howto_5 of the manual for further
+discussion.
 
 NOTE: As explained below, a NEB calculation perfoms a damped dynamics
 minimization across all the replicas.  The mimimizer uses whatever
@@ -255,12 +252,6 @@ An atom map must be defined which it is not by default for "atom_style
 atomic"_atom_style.html problems.  The "atom_modify
 map"_atom_modify.html command can be used to do this.
 
-The "atom_modify sort 0 0.0" command should be used to turn off atom
-sorting.
-
-NOTE: This sorting restriction will be removed in a future version of
-NEB in LAMMPS.
-
 The minimizers in LAMMPS operate on all atoms in your system, even
 non-NEB atoms, as defined above.  To prevent non-NEB atoms from moving
 during the minimization, you should use the "fix

doc/src/package.txt

@@ -142,7 +142,7 @@ the style options are set, either to default values or to specified
 settings.  I.e. settings from previous invocations do not persist
 across multiple invocations.
 
-See the "Section Accelerate"_Section_accelerate.html section of the
+See the "Section 5.3"_Section_accelerate.html#acc_3 section of the
 manual for more details about using the various accelerator packages
 for speeding up LAMMPS simulations.
 

doc/src/pair_gauss.txt

@@ -63,7 +63,7 @@ solvent simulations of salt ions "(Lenart)"_#Lenart and of surfactants
 "(Jusufi)"_#Jusufi.  In these instances the Gaussian potential mimics
 the hydration barrier between a pair of particles. The hydration
 barrier is located at r_mh and has a width of sigma_h. The prefactor
-determines the hight of the potential barrier.
+determines the height of the potential barrier.
 
 The following coefficients must be defined for each pair of atom types
 via the "pair_coeff"_pair_coeff.html command as in the example above,
@@ -73,9 +73,11 @@ commands:
 
 H (energy * distance units)
 r_mh (distance units)
-sigma_h (distance units) :ul
+sigma_h (distance units)
+cutoff (distance units) :ul
 
-The global cutoff (r_c) specified in the pair_style command is used.
+The last coefficient is optional. If not specified, the global cutoff
+is used.
 
 :line
 

doc/src/pair_reax_c.txt

@@ -41,7 +41,9 @@ supplemental information of the following paper: "(Chenoweth et al.,
 2008)"_#Chenoweth_2008.  The version integrated into LAMMPS matches
 the most up-to-date version of ReaxFF as of summer 2010.  For more
 technical details about the pair reax/c implementation of ReaxFF, see
-the "(Aktulga)"_#Aktulga paper.
+the "(Aktulga)"_#Aktulga paper. The {reax/c} style was initially
+implemented as a stand-alone C code and is now integrated into LAMMPS
+as a package.
 
 The {reax/c/kk} style is a Kokkos version of the ReaxFF potential that is
 derived from the {reax/c} style. The Kokkos version can run on GPUs and
@@ -167,7 +169,7 @@ variable eb  	 equal c_reax\[1\]
 variable ea      equal c_reax\[2\]
 \[...\]
 variable eqeq    equal c_reax\[14\]
-thermo_style custom step temp epair v_eb v_ea ... v_eqeq :pre
+thermo_style custom step temp epair v_eb v_ea \[...\] v_eqeq :pre
 
 Only a single pair_coeff command is used with the {reax/c} style which
 specifies a ReaxFF potential file with parameters for all needed
@@ -237,7 +239,7 @@ nbrhood_cutoff: Denotes the near neighbors cutoff (in Angstroms)
 regarding the bonded interactions. (default value = 5.0)
 
 hbond_cutoff: Denotes the cutoff distance (in Angstroms) for hydrogen
-bond interactions.(default value = 7.5. Value of 0.0 turns off
+bond interactions.(default value = 7.5. A value of 0.0 turns off
 hydrogen bonds)
 
 bond_graph_cutoff: is the threshold used in determining what is a

doc/src/prd.txt

@@ -63,14 +63,14 @@ event to occur.
 
 Each replica runs on a partition of one or more processors.  Processor
 partitions are defined at run-time using the -partition command-line
-switch; see "Section 2.7"_Section_start.html#start_7 of the
-manual.  Note that if you have MPI installed, you can run a
-multi-replica simulation with more replicas (partitions) than you have
-physical processors, e.g you can run a 10-replica simulation on one or
-two processors.  For PRD, this makes little sense, since this offers
-no effective parallel speed-up in searching for infrequent events. See
-"Section 6.5"_Section_howto.html#howto_5 of the manual for further
-discussion.
+switch; see "Section 2.7"_Section_start.html#start_7 of the manual.
+Note that if you have MPI installed, you can run a multi-replica
+simulation with more replicas (partitions) than you have physical
+processors, e.g you can run a 10-replica simulation on one or two
+processors.  However for PRD, this makes little sense, since running a
+replica on virtual instead of physical processors,offers no effective
+parallel speed-up in searching for infrequent events.  See "Section
+6.5"_Section_howto.html#howto_5 of the manual for further discussion.
 
 When a PRD simulation is performed, it is assumed that each replica is
 running the same model, though LAMMPS does not check for this.
@@ -163,7 +163,7 @@ runs for {N} timesteps.  If the {time} value is {clock}, then the
 simulation runs until {N} aggregate timesteps across all replicas have
 elapsed.  This aggregate time is the "clock" time defined below, which
 typically advances nearly M times faster than the timestepping on a
-single replica.
+single replica, where M is the number of replicas.
 
 :line
 
@@ -183,25 +183,26 @@ coincident events, and the replica number of the chosen event.
 
 The timestep is the usual LAMMPS timestep, except that time does not
 advance during dephasing or quenches, but only during dynamics.  Note
-that are two kinds of dynamics in the PRD loop listed above.  The
-first is when all replicas are performing independent dynamics,
-waiting for an event to occur.  The second is when correlated events
-are being searched for and only one replica is running dynamics.
+that are two kinds of dynamics in the PRD loop listed above that
+contribute to this timestepping.  The first is when all replicas are
+performing independent dynamics, waiting for an event to occur.  The
+second is when correlated events are being searched for, but only one
+replica is running dynamics.
 
-The CPU time is the total processor time since the start of the PRD
-run. 
+The CPU time is the total elapsed time on each processor, since the
+start of the PRD run.
 
 The clock is the same as the timestep except that it advances by M
-steps every timestep during the first kind of dynamics when the M
+steps per timestep during the first kind of dynamics when the M
 replicas are running independently.  The clock advances by only 1 step
-per timestep during the second kind of dynamics, since only a single
+per timestep during the second kind of dynamics, when only a single
 replica is checking for a correlated event.  Thus "clock" time
-represents the aggregate time (in steps) that effectively elapses
+represents the aggregate time (in steps) that has effectively elapsed
 during a PRD simulation on M replicas.  If most of the PRD run is
 spent in the second stage of the loop above, searching for infrequent
 events, then the clock will advance nearly M times faster than it
 would if a single replica was running.  Note the clock time between
-events will be drawn from p(t).
+successive events should be drawn from p(t).
 
 The event number is a counter that increments with each event, whether
 it is uncorrelated or correlated.
@@ -212,14 +213,15 @@ replicas are running independently.  The correlation flag will be 1
 when a correlated event occurs during the third stage of the loop
 listed above, i.e. when only one replica is running dynamics.
 
-When more than one replica detects an event at the end of the second
-stage, then one of them is chosen at random. The number of coincident 
-events is the number of replicas that detected an event. Normally, we
-expect this value to be 1. If it is often greater than 1, then either
-the number of replicas is too large, or {t_event} is too large.
+When more than one replica detects an event at the end of the same
+event check (every {t_event} steps) during the the second stage, then
+one of them is chosen at random.  The number of coincident events is
+the number of replicas that detected an event.  Normally, this value
+should be 1.  If it is often greater than 1, then either the number of
+replicas is too large, or {t_event} is too large.
 
-The replica number is the ID of the replica (from 0 to M-1) that
-found the event.
+The replica number is the ID of the replica (from 0 to M-1) in which
+the event occurred.
 
 :line
 
@@ -286,7 +288,7 @@ This command can only be used if LAMMPS was built with the REPLICA
 package.  See the "Making LAMMPS"_Section_start.html#start_3 section
 for more info on packages.
 
-{N} and {t_correlate} settings must be integer multiples of
+The {N} and {t_correlate} settings must be integer multiples of
 {t_event}.
 
 Runs restarted from restart file written during a PRD run will not

doc/src/python.txt

@@ -97,7 +97,7 @@ be passed to various commands as arguments, so that the variable is
 evaluated during a simulation run.
 
 A broader overview of how Python can be used with LAMMPS is
-given in "Section python"_Section_python.html.  There is an
+given in "Section 11"_Section_python.html.  There is an
 examples/python directory which illustrates use of the python
 command.
 

doc/src/read_restart.txt

@@ -124,7 +124,7 @@ MPI-IO requires two steps.  First, build LAMMPS with its MPIIO package
 installed, e.g.
 
 make yes-mpiio    # installs the MPIIO package
-make g++          # build LAMMPS for your platform :pre
+make mpi          # build LAMMPS for your platform :pre
 
 Second, use a restart filename which contains ".mpiio".  Note that it
 does not have to end in ".mpiio", just contain those characters.
@@ -191,13 +191,18 @@ input script should specify all fixes it will use.  However, note that
 some fixes store an internal "state" which is written to the restart
 file.  This allows the fix to continue on with its calculations in a
 restarted simulation.  To re-enable such a fix, the fix command in the
-new input script must use the same fix-ID and group-ID as was used in
-the input script that wrote the restart file.  If a match is found,
-LAMMPS prints a message indicating that the fix is being re-enabled.
-If no match is found before the first run or minimization is performed
-by the new script, the "state" information for the saved fix is
-discarded.  See the doc pages for individual fixes for info on which
-ones can be restarted in this manner.
+new input script must be of the same style and use the same fix-ID as
+was used in the input script that wrote the restart file.
+
+If a match is found, LAMMPS prints a message indicating that the fix
+is being re-enabled.  If no match is found before the first run or
+minimization is performed by the new script, the "state" information
+for the saved fix is discarded.  LAMMPS will also print a list of
+fixes for which the information is being discarded.  See the doc pages
+for individual fixes for info on which ones can be restarted in this
+manner.  Note that fixes which are created internally by other LAMMPS
+commands (computes, fixes, etc) will have style names which are
+all-capitalized, and IDs which are generated internally.
 
 Likewise, the "computes"_fix.html used for a simulation are not stored
 in the restart file.  This means the new input script should specify
@@ -213,6 +218,14 @@ re-created fix will be re-enabled with the stored state information as
 described in the previous paragraph, so that the compute can continue
 its calculations in a consistent manner.
 
+NOTE: There are a handful of commands which can be used before or
+between runs which require a system initialization.  Examples include
+the "balance", "displace_atoms", and "delete_atoms" commands.  This is
+because they may migrate atoms to new processors.  Thus they will also
+discard unused "state" information from fixes.  This means that, if
+desired, you must re-specify the relevant fixes and computes (which
+create fixes) before those commands are used.
+
 Some pair styles, like the "granular pair styles"_pair_gran.html, also
 use a fix to store "state" information that persists from timestep to
 timestep.  In the case of granular potentials, it is contact

doc/src/region.txt

@@ -186,7 +186,7 @@ functions, and include "thermo_style"_thermo_style.html command
 keywords for the simulation box parameters and timestep and elapsed
 time.  Thus it is easy to specify a time-dependent radius.
 
-See "Section_howto 12"_Section_howto.html#howto_12 of the doc pages
+See "Section 6.12"_Section_howto.html#howto_12 of the doc pages
 for a geometric description of triclinic boxes, as defined by LAMMPS,
 and how to transform these parameters to and from other commonly used
 triclinic representations.
@@ -361,7 +361,7 @@ sub-regions can be defined with the {open} keyword.
 Styles with a {kk} suffix are functionally the same as the
 corresponding style without the suffix.  They have been optimized to
 run faster, depending on your available hardware, as discussed in
-"Section_accelerate"_Section_accelerate.html of the manual.  The
+"Section 5"_Section_accelerate.html of the manual.  The
 accelerated styles take the same arguments and should produce the same
 results, except for round-off and precision issues.
 
@@ -378,7 +378,7 @@ by including their suffix, or you can use the "-suffix command-line
 switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
 use the "suffix"_suffix.html command in your input script.
 
-See "Section_accelerate"_Section_accelerate.html of the manual for
+See "Section 5"_Section_accelerate.html of the manual for
 more instructions on how to use the accelerated styles effectively.
 
 :line

doc/src/replicate.txt

@@ -74,11 +74,14 @@ larger version of your molecule as a pre-processing step and input a
 new data file to LAMMPS.
 
 If the current simulation was read in from a restart file (before a
-run is performed), there can have been no fix information stored in
+run is performed), there must not be any fix information stored in
 the file for individual atoms.  Similarly, no fixes can be defined at
 the time the replicate command is used that require vectors of atom
 information to be stored.  This is because the replicate command does
 not know how to replicate that information for new atoms it creates.
+To work around this restriction, restart files may be converted into
+data files and fixes may be undefined via the "unfix"_unfix.html
+command before and redefined after the replicate command.
 
 [Related commands:] none
 

doc/src/restart.txt

@@ -82,7 +82,7 @@ versions 2.0 and above.  Using MPI-IO requires two steps.  First,
 build LAMMPS with its MPIIO package installed, e.g.
 
 make yes-mpiio    # installs the MPIIO package
-make g++          # build LAMMPS for your platform :pre
+make mpi          # build LAMMPS for your platform :pre
 
 Second, use a restart filename which contains ".mpiio".  Note that it
 does not have to end in ".mpiio", just contain those characters.

doc/src/variable.txt

@@ -47,7 +47,7 @@ style = {delete} or {index} or {loop} or {world} or {universe} or {uloop} or {st
     constants = PI, version, on, off, true, false, yes, no
     thermo keywords = vol, ke, press, etc from "thermo_style"_thermo_style.html
     math operators = (), -x, x+y, x-y, x*y, x/y, x^y, x%y,
-                     x == y, x != y, x < y, x <= y, x > y, x >= y, x && y, x || y, !x
+                     x == y, x != y, x < y, x <= y, x > y, x >= y, x && y, x || y, x |^ y, !x
     math functions = sqrt(x), exp(x), ln(x), log(x), abs(x),
                      sin(x), cos(x), tan(x), asin(x), acos(x), atan(x), atan2(y,x),
                      random(x,y,z), normal(x,y,z), ceil(x), floor(x), round(x)
@@ -450,7 +450,7 @@ Number: 0.2, 100, 1.0e20, -15.4, etc
 Constant: PI, version, on, off, true, false, yes, no
 Thermo keywords: vol, pe, ebond, etc
 Math operators: (), -x, x+y, x-y, x*y, x/y, x^y, x%y, \
-     x == y, x != y, x < y, x <= y, x > y, x >= y, x && y, x || y, !x
+     x == y, x != y, x < y, x <= y, x > y, x >= y, x && y, x || y, x |^ y, !x
 Math functions: sqrt(x), exp(x), ln(x), log(x), abs(x), \
      sin(x), cos(x), tan(x), asin(x), acos(x), atan(x), atan2(y,x), \
      random(x,y,z), normal(x,y,z), ceil(x), floor(x), round(x), \
@@ -551,9 +551,10 @@ division and the modulo operator "%" are next; addition and
 subtraction are next; the 4 relational operators "<", "<=", ">", and
 ">=" are next; the two remaining relational operators "==" and "!="
 are next; then the logical AND operator "&&"; and finally the logical
-OR operator "||" has the lowest precedence.  Parenthesis can be used
-to group one or more portions of a formula and/or enforce a different
-order of evaluation than what would occur with the default precedence.
+OR operator "||" and logical XOR (exclusive or) operator "|^" have the
+lowest precedence.  Parenthesis can be used to group one or more
+portions of a formula and/or enforce a different order of evaluation
+than what would occur with the default precedence.
 
 NOTE: Because a unary minus is higher precedence than exponentiation,
 the formula "-2^2" will evaluate to 4, not -4.  This convention is
@@ -568,8 +569,10 @@ return 1.0 for all atoms whose x-coordinate is less than 10.0, and 0.0
 for the others.  The logical AND operator will return 1.0 if both its
 arguments are non-zero, else it returns 0.0.  The logical OR operator
 will return 1.0 if either of its arguments is non-zero, else it
-returns 0.0.  The logical NOT operator returns 1.0 if its argument is
-0.0, else it returns 0.0.
+returns 0.0.  The logical XOR operator will return 1.0 if one of its
+arguments is zero and the other non-zero, else it returns 0.0.  The
+logical NOT operator returns 1.0 if its argument is 0.0, else it
+returns 0.0.
 
 These relational and logical operators can be used as a masking or
 selection operation in a formula.  For example, the number of atoms
@@ -1121,7 +1124,7 @@ with a leading $ sign (e.g. $x or $\{abc\}) versus with a leading "v_"
 (e.g. v_x or v_abc).  The former can be used in any input script
 command, including a variable command.  The input script parser
 evaluates the reference variable immediately and substitutes its value
-into the command.  As explained in "Section commands
+into the command.  As explained in "Section
 3.2"_Section_commands.html#cmd_2 for "Parsing rules", you can also use
 un-named "immediate" variables for this purpose.  For example, a
 string like this $((xlo+xhi)/2+sqrt(v_area)) in an input script

doc/src/velocity.txt

@@ -139,7 +139,7 @@ if rot = yes, the angular momentum is zeroed.
 If specified, the {temp} keyword is used by {create} and {scale} to
 specify a "compute"_compute.html that calculates temperature in a
 desired way, e.g. by first subtracting out a velocity bias, as
-discussed in "Section howto 16"_Section_howto.html#howto_15 of the doc
+discussed in "Section 6.16"_Section_howto.html#howto_16 of the doc
 pages.  If this keyword is not specified, {create} and {scale}
 calculate temperature using a compute that is defined internally as
 follows:
@@ -161,8 +161,8 @@ The {bias} keyword with a {yes} setting is used by {create} and
 If the temperature compute also calculates a velocity bias, the the
 bias is subtracted from atom velocities before the {create} and
 {scale} operations are performed.  After the operations, the bias is
-added back to the atom velocities.  See "Section howto
-16"_Section_howto.html#howto_15 of the doc pages for more discussion
+added back to the atom velocities.  See "Section
+6.16"_Section_howto.html#howto_16 of the doc pages for more discussion
 of temperature computes with biases.  Note that the velocity bias is
 only applied to atoms in the temperature compute specified with the
 {temp} keyword.

doc/src/write_restart.txt

@@ -55,7 +55,7 @@ versions 2.0 and above.  Using MPI-IO requires two steps.  First,
 build LAMMPS with its MPIIO package installed, e.g.
 
 make yes-mpiio    # installs the MPIIO package
-make g++          # build LAMMPS for your platform :pre
+make mpi          # build LAMMPS for your platform :pre
 
 Second, use a restart filename which contains ".mpiio".  Note that it
 does not have to end in ".mpiio", just contain those characters.

doc/utils/converters/lammpsdoc/lammps_filters.py

@@ -90,3 +90,24 @@ def promote_doc_keywords(content):
 
 def filter_multiple_horizontal_rules(content):
     return re.sub(r"----------[\s\n]+----------", '', content)
+
+
+def merge_preformatted_sections(content):
+    mergable_section_pattern = re.compile(r"\.\. parsed-literal::\n"
+                                          r"\n"
+                                          r"(?P<listingA>((   [^\n]+\n)|(^\n))+)\n\s*"
+                                          r"^\.\. parsed-literal::\n"
+                                          r"\n"
+                                          r"(?P<listingB>((   [^\n]+\n)|(^\n))+)\n", re.MULTILINE | re.DOTALL)
+
+    m = mergable_section_pattern.search(content)
+
+    while m:
+        content = mergable_section_pattern.sub(r".. parsed-literal::\n"
+                                            r"\n"
+                                            r"\g<listingA>"
+                                            r"\g<listingB>"
+                                            r"\n", content)
+        m = mergable_section_pattern.search(content)
+
+    return content

doc/utils/converters/lammpsdoc/txt2rst.py

@@ -73,10 +73,13 @@ class RSTMarkup(Markup):
     def unescape_rst_chars(self, text):
         text = text.replace('\\*', '*')
         text = text.replace('\\^', '^')
-        text = text.replace('\\_', '_')
+        text = self.unescape_underscore(text)
         text = text.replace('\\|', '|')
         return text
 
+    def unescape_underscore(self, text):
+        return text.replace('\\_', '_')
+
     def inline_math(self, text):
         start_pos = text.find("\\(")
         end_pos = text.find("\\)")
@@ -101,7 +104,7 @@ class RSTMarkup(Markup):
 
         anchor_pos = href.find('#')
 
-        if anchor_pos >= 0:
+        if anchor_pos >= 0 and not href.startswith('http'):
             href = href[anchor_pos+1:]
             return ":ref:`%s <%s>`" % (content, href)
 
@@ -136,6 +139,7 @@ class RSTFormatting(Formatting):
         return content.strip()
 
     def preformat(self, content):
+        content = self.markup.unescape_underscore(content)
         if self.indent_level > 0:
             return self.list_indent("\n.. parsed-literal::\n\n" + self.indent(content.rstrip()), self.indent_level)
         return "\n.. parsed-literal::\n\n" + self.indent(content.rstrip())
@@ -355,6 +359,7 @@ class Txt2Rst(TxtParser):
         self.document_filters.append(lammps_filters.detect_and_add_command_to_index)
         self.document_filters.append(lammps_filters.filter_multiple_horizontal_rules)
         self.document_filters.append(lammps_filters.promote_doc_keywords)
+        self.document_filters.append(lammps_filters.merge_preformatted_sections)
 
     def is_ignored_textblock_begin(self, line):
         return line.startswith('<!-- HTML_ONLY -->')

doc/utils/converters/tests/test_txt2rst.py

@@ -169,6 +169,13 @@ class TestFormatting(unittest.TestCase):
                          "       Hello\n"
                          "       World\n\n", s)
 
+    def test_preformat_formatting_with_underscore(self):
+        s = self.txt2rst.convert("if MPI.COMM_WORLD.rank == 0:\n"
+                                 "    print(\"Potential energy: \", L.eval(\"pe\")) :pre\n")
+        self.assertEqual("\n.. parsed-literal::\n\n"
+                         "   if MPI.COMM_WORLD.rank == 0:\n"
+                         "       print(\"Potential energy: \", L.eval(\"pe\"))\n\n", s)
+
     def test_header_formatting(self):
         s = self.txt2rst.convert("Level 1 :h1\n"
                                  "Level 2 :h2\n"
@@ -417,6 +424,11 @@ class TestSpecialCommands(unittest.TestCase):
                          "one \n\n"
                          "a :ref:`link <name>` to above\n\n", s)
 
+    def test_external_anchor_link(self):
+        s = self.txt2rst.convert('some text "containing a\n'
+                                 'link"_http://lammps.sandia.gov/movies.html#granregion with an anchor')
+        self.assertEqual('some text `containing a link <http://lammps.sandia.gov/movies.html#granregion>`_ with an anchor\n\n', s)
+
     def test_define_link_alias(self):
         s = self.txt2rst.convert("one :link(alias,value)\n"
                                  "\"test\"_alias\n")