diff --git a/README b/README index 7cda5f2b3e..a258a335e9 100644 --- a/README +++ b/README @@ -39,3 +39,4 @@ Point your browser at any of these files to get started: doc/Manual.html the LAMMPS manual doc/Section_intro.html hi-level introduction to LAMMPS doc/Section_start.html how to build and use LAMMPS +doc/Developer.pdf LAMMPS developer guide diff --git a/bench/in.chute b/bench/in.chute index 985f4140e2..cf43fd7ff8 100644 --- a/bench/in.chute +++ b/bench/in.chute @@ -2,7 +2,7 @@ # chute flow of 32000 atoms with frozen base at 26 degrees units lj -atom_style granular +atom_style sphere boundary p p fs newton off communicate single vel yes diff --git a/bench/in.chute.scaled b/bench/in.chute.scaled index 583fd70d67..cda2445620 100644 --- a/bench/in.chute.scaled +++ b/bench/in.chute.scaled @@ -5,7 +5,7 @@ variable x index 1 variable y index 1 units lj -atom_style granular +atom_style sphere boundary p p fs newton off communicate single vel yes diff --git a/bench/log.10Sep10.chain.fixed.linux.1 b/bench/log.28Mar11.chain.fixed.linux.1 similarity index 76% rename from bench/log.10Sep10.chain.fixed.linux.1 rename to bench/log.28Mar11.chain.fixed.linux.1 index ed865c516d..a656eb9e7f 100644 --- a/bench/log.10Sep10.chain.fixed.linux.1 +++ b/bench/log.28Mar11.chain.fixed.linux.1 @@ -1,4 +1,4 @@ -LAMMPS (10 Sep 2010) +LAMMPS (27 Mar 2011) # FENE beadspring benchmark units lj @@ -32,18 +32,18 @@ thermo 100 timestep 0.012 run 100 -Memory usage per processor = 8.37288 Mbytes +Memory usage per processor = 11.3536 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 1.88908 on 1 procs for 100 steps with 32000 atoms +Loop time of 1.87328 on 1 procs for 100 steps with 32000 atoms -Pair time (%) = 0.444468 (23.5283) -Bond time (%) = 0.293589 (15.5413) -Neigh time (%) = 0.685171 (36.27) -Comm time (%) = 0.0576162 (3.04996) -Outpt time (%) = 0.000181913 (0.00962972) -Other time (%) = 0.408057 (21.6008) +Pair time (%) = 0.438668 (23.4171) +Bond time (%) = 0.289005 (15.4277) +Neigh time (%) = 0.679554 (36.2761) +Comm time (%) = 0.0552287 (2.94823) +Outpt time (%) = 0.00018096 (0.00966003) +Other time (%) = 0.410646 (21.9212) Nlocal: 32000 ave 32000 max 32000 min Histogram: 1 0 0 0 0 0 0 0 0 0 diff --git a/bench/log.10Sep10.chain.fixed.linux.4 b/bench/log.28Mar11.chain.fixed.linux.4 similarity index 76% rename from bench/log.10Sep10.chain.fixed.linux.4 rename to bench/log.28Mar11.chain.fixed.linux.4 index b63f778ae9..0d9a9854f7 100644 --- a/bench/log.10Sep10.chain.fixed.linux.4 +++ b/bench/log.28Mar11.chain.fixed.linux.4 @@ -1,4 +1,4 @@ -LAMMPS (10 Sep 2010) +LAMMPS (27 Mar 2011) # FENE beadspring benchmark units lj @@ -32,18 +32,18 @@ thermo 100 timestep 0.012 run 100 -Memory usage per processor = 3.56846 Mbytes +Memory usage per processor = 4.80505 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.437537 on 4 procs for 100 steps with 32000 atoms +Loop time of 0.436674 on 4 procs for 100 steps with 32000 atoms -Pair time (%) = 0.0835259 (19.09) -Bond time (%) = 0.0587637 (13.4306) -Neigh time (%) = 0.158699 (36.2711) -Comm time (%) = 0.0484382 (11.0707) -Outpt time (%) = 0.000112474 (0.0257062) -Other time (%) = 0.0879969 (20.1119) +Pair time (%) = 0.0835696 (19.1378) +Bond time (%) = 0.0588097 (13.4677) +Neigh time (%) = 0.157872 (36.1532) +Comm time (%) = 0.047663 (10.915) +Outpt time (%) = 9.69768e-05 (0.0222081) +Other time (%) = 0.0886627 (20.3041) Nlocal: 8000 ave 8030 max 7974 min Histogram: 1 0 0 1 0 1 0 0 0 1 diff --git a/bench/log.10Sep10.chain.scaled.linux.4 b/bench/log.28Mar11.chain.scaled.linux.4 similarity index 81% rename from bench/log.10Sep10.chain.scaled.linux.4 rename to bench/log.28Mar11.chain.scaled.linux.4 index 386d2d40c2..fcef103203 100644 --- a/bench/log.10Sep10.chain.scaled.linux.4 +++ b/bench/log.28Mar11.chain.scaled.linux.4 @@ -1,4 +1,4 @@ -LAMMPS (10 Sep 2010) +LAMMPS (27 Mar 2011) # FENE beadspring benchmark variable x index 1 @@ -48,18 +48,18 @@ thermo 100 timestep 0.012 run 100 -Memory usage per processor = 10.0339 Mbytes +Memory usage per processor = 13.3552 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 2.44443 on 4 procs for 100 steps with 128000 atoms +Loop time of 2.4188 on 4 procs for 100 steps with 128000 atoms -Pair time (%) = 0.512437 (20.9635) -Bond time (%) = 0.34535 (14.128) -Neigh time (%) = 0.750835 (30.7162) -Comm time (%) = 0.225137 (9.2102) -Outpt time (%) = 0.000238776 (0.00976818) -Other time (%) = 0.61043 (24.9723) +Pair time (%) = 0.507936 (20.9995) +Bond time (%) = 0.340843 (14.0914) +Neigh time (%) = 0.735922 (30.425) +Comm time (%) = 0.228828 (9.46038) +Outpt time (%) = 0.000289202 (0.0119564) +Other time (%) = 0.604987 (25.0118) Nlocal: 32000 ave 32015 max 31983 min Histogram: 1 0 1 0 0 0 0 0 1 1 diff --git a/bench/log.10Sep10.chute.fixed.linux.1 b/bench/log.28Mar11.chute.fixed.linux.1 similarity index 80% rename from bench/log.10Sep10.chute.fixed.linux.1 rename to bench/log.28Mar11.chute.fixed.linux.1 index 21c9721dff..e16830ffd4 100644 --- a/bench/log.10Sep10.chute.fixed.linux.1 +++ b/bench/log.28Mar11.chute.fixed.linux.1 @@ -1,4 +1,4 @@ -LAMMPS (10 Sep 2010) +LAMMPS (27 Mar 2011) # LAMMPS benchmark of granular flow # chute flow of 32000 atoms with frozen base at 26 degrees @@ -38,17 +38,17 @@ thermo_modify norm no thermo 100 run 100 -Memory usage per processor = 33.1524 Mbytes +Memory usage per processor = 35.2505 Mbytes Step Atoms KinEng 1 Volume 0 32000 784139.13 1601.1263 29830.88 100 32000 784289.99 1571.0137 29831.804 -Loop time of 1.60559 on 1 procs for 100 steps with 32000 atoms +Loop time of 1.58777 on 1 procs for 100 steps with 32000 atoms -Pair time (%) = 0.895255 (55.7587) -Neigh time (%) = 0.0694721 (4.32689) -Comm time (%) = 0.0682392 (4.25011) -Outpt time (%) = 0.000529051 (0.0329506) -Other time (%) = 0.572093 (35.6314) +Pair time (%) = 0.887784 (55.9139) +Neigh time (%) = 0.070847 (4.46205) +Comm time (%) = 0.0669501 (4.21661) +Outpt time (%) = 0.000550032 (0.0346418) +Other time (%) = 0.561639 (35.3728) Nlocal: 32000 ave 32000 max 32000 min Histogram: 1 0 0 0 0 0 0 0 0 0 diff --git a/bench/log.10Sep10.chute.fixed.linux.4 b/bench/log.28Mar11.chute.fixed.linux.4 similarity index 79% rename from bench/log.10Sep10.chute.fixed.linux.4 rename to bench/log.28Mar11.chute.fixed.linux.4 index f87d82aa36..59efa4a12a 100644 --- a/bench/log.10Sep10.chute.fixed.linux.4 +++ b/bench/log.28Mar11.chute.fixed.linux.4 @@ -1,4 +1,4 @@ -LAMMPS (10 Sep 2010) +LAMMPS (27 Mar 2011) # LAMMPS benchmark of granular flow # chute flow of 32000 atoms with frozen base at 26 degrees @@ -38,17 +38,17 @@ thermo_modify norm no thermo 100 run 100 -Memory usage per processor = 14.5608 Mbytes +Memory usage per processor = 15.4199 Mbytes Step Atoms KinEng 1 Volume 0 32000 784139.13 1601.1263 29830.88 100 32000 784289.99 1571.0137 29831.804 -Loop time of 0.277719 on 4 procs for 100 steps with 32000 atoms +Loop time of 0.270323 on 4 procs for 100 steps with 32000 atoms -Pair time (%) = 0.137333 (49.4503) -Neigh time (%) = 0.0172272 (6.20312) -Comm time (%) = 0.0410517 (14.7818) -Outpt time (%) = 0.000243425 (0.0876517) -Other time (%) = 0.0818638 (29.4772) +Pair time (%) = 0.135713 (50.2038) +Neigh time (%) = 0.0173983 (6.43611) +Comm time (%) = 0.0378563 (14.0041) +Outpt time (%) = 0.000246227 (0.091086) +Other time (%) = 0.0791097 (29.2649) Nlocal: 8000 ave 8010 max 7990 min Histogram: 2 0 0 0 0 0 0 0 0 2 diff --git a/bench/log.10Sep10.chute.scaled.linux.4 b/bench/log.28Mar11.chute.scaled.linux.4 similarity index 82% rename from bench/log.10Sep10.chute.scaled.linux.4 rename to bench/log.28Mar11.chute.scaled.linux.4 index d4df666879..3185110022 100644 --- a/bench/log.10Sep10.chute.scaled.linux.4 +++ b/bench/log.28Mar11.chute.scaled.linux.4 @@ -1,4 +1,4 @@ -LAMMPS (10 Sep 2010) +LAMMPS (27 Mar 2011) # LAMMPS benchmark of granular flow # chute flow of 32000 atoms with frozen base at 26 degrees @@ -48,17 +48,17 @@ thermo_modify norm no thermo 100 run 100 -Memory usage per processor = 35.1222 Mbytes +Memory usage per processor = 37.3912 Mbytes Step Atoms KinEng 1 Volume 0 128000 3136556.5 6404.5051 119323.52 100 128000 3137160 6284.0549 119327.22 -Loop time of 2.81255 on 4 procs for 100 steps with 128000 atoms +Loop time of 2.79202 on 4 procs for 100 steps with 128000 atoms -Pair time (%) = 1.14575 (40.7373) -Neigh time (%) = 0.070235 (2.4972) -Comm time (%) = 0.247361 (8.79492) -Outpt time (%) = 0.00147456 (0.0524279) -Other time (%) = 1.34772 (47.9182) +Pair time (%) = 1.13366 (40.6034) +Neigh time (%) = 0.0699974 (2.50705) +Comm time (%) = 0.24415 (8.74457) +Outpt time (%) = 0.00162953 (0.0583639) +Other time (%) = 1.34259 (48.0866) Nlocal: 32000 ave 32000 max 32000 min Histogram: 4 0 0 0 0 0 0 0 0 0 diff --git a/bench/log.10Sep10.eam.fixed.linux.1 b/bench/log.28Mar11.eam.fixed.linux.1 similarity index 81% rename from bench/log.10Sep10.eam.fixed.linux.1 rename to bench/log.28Mar11.eam.fixed.linux.1 index a2278b7622..4303ebf435 100644 --- a/bench/log.10Sep10.eam.fixed.linux.1 +++ b/bench/log.28Mar11.eam.fixed.linux.1 @@ -1,4 +1,4 @@ -LAMMPS (10 Sep 2010) +LAMMPS (27 Mar 2011) # bulk Cu lattice variable x index 1 @@ -41,18 +41,18 @@ timestep 0.005 thermo 50 run 100 -Memory usage per processor = 13.3815 Mbytes +Memory usage per processor = 15.3728 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 11.4134 on 1 procs for 100 steps with 32000 atoms +Loop time of 11.4086 on 1 procs for 100 steps with 32000 atoms -Pair time (%) = 10.2719 (89.9988) -Neigh time (%) = 0.870639 (7.62822) -Comm time (%) = 0.071027 (0.622312) -Outpt time (%) = 0.000430107 (0.00376844) -Other time (%) = 0.19938 (1.74689) +Pair time (%) = 10.2465 (89.814) +Neigh time (%) = 0.893404 (7.83096) +Comm time (%) = 0.0694258 (0.608539) +Outpt time (%) = 0.000409126 (0.00358612) +Other time (%) = 0.198848 (1.74296) Nlocal: 32000 ave 32000 max 32000 min Histogram: 1 0 0 0 0 0 0 0 0 0 diff --git a/bench/log.10Sep10.eam.fixed.linux.4 b/bench/log.28Mar11.eam.fixed.linux.4 similarity index 81% rename from bench/log.10Sep10.eam.fixed.linux.4 rename to bench/log.28Mar11.eam.fixed.linux.4 index 19242fc552..22fb1cf05d 100644 --- a/bench/log.10Sep10.eam.fixed.linux.4 +++ b/bench/log.28Mar11.eam.fixed.linux.4 @@ -1,4 +1,4 @@ -LAMMPS (10 Sep 2010) +LAMMPS (27 Mar 2011) # bulk Cu lattice variable x index 1 @@ -41,18 +41,18 @@ timestep 0.005 thermo 50 run 100 -Memory usage per processor = 4.30641 Mbytes +Memory usage per processor = 4.92442 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 2.83686 on 4 procs for 100 steps with 32000 atoms +Loop time of 2.84421 on 4 procs for 100 steps with 32000 atoms -Pair time (%) = 2.47209 (87.1416) -Neigh time (%) = 0.216486 (7.63117) -Comm time (%) = 0.102601 (3.61672) -Outpt time (%) = 0.000239313 (0.00843582) -Other time (%) = 0.0454471 (1.60202) +Pair time (%) = 2.47554 (87.0379) +Neigh time (%) = 0.216563 (7.61418) +Comm time (%) = 0.104262 (3.66577) +Outpt time (%) = 0.000251591 (0.00884573) +Other time (%) = 0.0475937 (1.67335) Nlocal: 8000 ave 8008 max 7993 min Histogram: 2 0 0 0 0 0 0 0 1 1 diff --git a/bench/log.10Sep10.eam.scaled.linux.4 b/bench/log.28Mar11.eam.scaled.linux.4 similarity index 81% rename from bench/log.10Sep10.eam.scaled.linux.4 rename to bench/log.28Mar11.eam.scaled.linux.4 index e9f7e96373..08f93dca86 100644 --- a/bench/log.10Sep10.eam.scaled.linux.4 +++ b/bench/log.28Mar11.eam.scaled.linux.4 @@ -1,4 +1,4 @@ -LAMMPS (10 Sep 2010) +LAMMPS (27 Mar 2011) # bulk Cu lattice variable x index 1 @@ -41,18 +41,18 @@ timestep 0.005 thermo 50 run 100 -Memory usage per processor = 13.2978 Mbytes +Memory usage per processor = 15.2892 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 12.1219 on 4 procs for 100 steps with 128000 atoms +Loop time of 12.0882 on 4 procs for 100 steps with 128000 atoms -Pair time (%) = 10.388 (85.696) -Neigh time (%) = 0.970104 (8.00291) -Comm time (%) = 0.309309 (2.55166) -Outpt time (%) = 0.00056392 (0.00465208) -Other time (%) = 0.453939 (3.74479) +Pair time (%) = 10.3589 (85.6942) +Neigh time (%) = 0.963713 (7.97234) +Comm time (%) = 0.316817 (2.62088) +Outpt time (%) = 0.000717819 (0.00593818) +Other time (%) = 0.448062 (3.70661) Nlocal: 32000 ave 32092 max 31914 min Histogram: 1 0 0 1 0 1 0 0 0 1 diff --git a/bench/log.10Sep10.lj.fixed.linux.1 b/bench/log.28Mar11.lj.fixed.linux.1 similarity index 80% rename from bench/log.10Sep10.lj.fixed.linux.1 rename to bench/log.28Mar11.lj.fixed.linux.1 index 8a440f6ad4..1daa53dd36 100644 --- a/bench/log.10Sep10.lj.fixed.linux.1 +++ b/bench/log.28Mar11.lj.fixed.linux.1 @@ -1,4 +1,4 @@ -LAMMPS (10 Sep 2010) +LAMMPS (27 Mar 2011) # 3d Lennard-Jones melt variable x index 1 @@ -39,17 +39,17 @@ neigh_modify delay 0 every 20 check no fix 1 all nve run 100 -Memory usage per processor = 11.5405 Mbytes +Memory usage per processor = 13.2267 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 4.23911 on 1 procs for 100 steps with 32000 atoms +Loop time of 4.24155 on 1 procs for 100 steps with 32000 atoms -Pair time (%) = 3.65005 (86.1043) -Neigh time (%) = 0.358313 (8.45255) -Comm time (%) = 0.0616844 (1.45513) -Outpt time (%) = 0.000219822 (0.00518557) -Other time (%) = 0.168838 (3.98286) +Pair time (%) = 3.6555 (86.1832) +Neigh time (%) = 0.359136 (8.4671) +Comm time (%) = 0.0590658 (1.39255) +Outpt time (%) = 0.000212193 (0.00500272) +Other time (%) = 0.167634 (3.95218) Nlocal: 32000 ave 32000 max 32000 min Histogram: 1 0 0 0 0 0 0 0 0 0 diff --git a/bench/log.10Sep10.lj.fixed.linux.4 b/bench/log.28Mar11.lj.fixed.linux.4 similarity index 80% rename from bench/log.10Sep10.lj.fixed.linux.4 rename to bench/log.28Mar11.lj.fixed.linux.4 index 065a8c275e..1886e20603 100644 --- a/bench/log.10Sep10.lj.fixed.linux.4 +++ b/bench/log.28Mar11.lj.fixed.linux.4 @@ -1,4 +1,4 @@ -LAMMPS (10 Sep 2010) +LAMMPS (27 Mar 2011) # 3d Lennard-Jones melt variable x index 1 @@ -39,17 +39,17 @@ neigh_modify delay 0 every 20 check no fix 1 all nve run 100 -Memory usage per processor = 3.77112 Mbytes +Memory usage per processor = 4.31284 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 1.08693 on 4 procs for 100 steps with 32000 atoms +Loop time of 1.08102 on 4 procs for 100 steps with 32000 atoms -Pair time (%) = 0.862853 (79.3841) -Neigh time (%) = 0.0901618 (8.29506) -Comm time (%) = 0.104805 (9.64223) -Outpt time (%) = 0.00012809 (0.0117846) -Other time (%) = 0.0289862 (2.66678) +Pair time (%) = 0.86205 (79.7443) +Neigh time (%) = 0.0897413 (8.30156) +Comm time (%) = 0.0998399 (9.23573) +Outpt time (%) = 0.000194311 (0.0179748) +Other time (%) = 0.0291918 (2.7004) Nlocal: 8000 ave 8037 max 7964 min Histogram: 2 0 0 0 0 0 0 0 1 1 diff --git a/bench/log.10Sep10.lj.scaled.linux.4 b/bench/log.28Mar11.lj.scaled.linux.4 similarity index 80% rename from bench/log.10Sep10.lj.scaled.linux.4 rename to bench/log.28Mar11.lj.scaled.linux.4 index 8bb7b74168..c74c764038 100644 --- a/bench/log.10Sep10.lj.scaled.linux.4 +++ b/bench/log.28Mar11.lj.scaled.linux.4 @@ -1,4 +1,4 @@ -LAMMPS (10 Sep 2010) +LAMMPS (27 Mar 2011) # 3d Lennard-Jones melt variable x index 1 @@ -39,17 +39,17 @@ neigh_modify delay 0 every 20 check no fix 1 all nve run 100 -Memory usage per processor = 11.4634 Mbytes +Memory usage per processor = 13.1495 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 4.71979 on 4 procs for 100 steps with 128000 atoms +Loop time of 4.71885 on 4 procs for 100 steps with 128000 atoms -Pair time (%) = 3.69683 (78.3262) -Neigh time (%) = 0.352295 (7.46421) -Comm time (%) = 0.27812 (5.89264) -Outpt time (%) = 0.000311732 (0.00660479) -Other time (%) = 0.392233 (8.31039) +Pair time (%) = 3.70177 (78.4464) +Neigh time (%) = 0.350671 (7.43129) +Comm time (%) = 0.278878 (5.90987) +Outpt time (%) = 0.000279307 (0.00591897) +Other time (%) = 0.387254 (8.20654) Nlocal: 32000 ave 32060 max 31939 min Histogram: 1 0 1 0 0 0 0 1 0 1 diff --git a/bench/log.10Sep10.rhodo.fixed.linux.1 b/bench/log.28Mar11.rhodo.fixed.linux.1 similarity index 82% rename from bench/log.10Sep10.rhodo.fixed.linux.1 rename to bench/log.28Mar11.rhodo.fixed.linux.1 index 37d4acc7b6..eb669ae71c 100644 --- a/bench/log.10Sep10.rhodo.fixed.linux.1 +++ b/bench/log.28Mar11.rhodo.fixed.linux.1 @@ -1,4 +1,4 @@ -LAMMPS (10 Sep 2010) +LAMMPS (27 Mar 2011) # Rhodopsin model units real @@ -51,37 +51,37 @@ PPPM initialization ... stencil order = 5 RMS precision = 7.57143e-05 brick FFT buffer size/proc = 41070 25600 12321 -Memory usage per processor = 124.369 Mbytes +Memory usage per processor = 138.965 Mbytes ---------------- Step 0 ----- CPU = 0.0000 (sec) ---------------- TotEng = -25356.2055 KinEng = 21444.8313 Temp = 299.0397 PotEng = -46801.0368 E_bond = 2537.9940 E_angle = 10921.3742 E_dihed = 5211.7865 E_impro = 213.5116 E_vdwl = -2307.8634 E_coul = 207021.6603 E_long = -270399.5000 Press = -142.6030 Volume = 307995.0335 ----------------- Step 50 ----- CPU = 31.7800 (sec) ---------------- +---------------- Step 50 ----- CPU = 32.2123 (sec) ---------------- TotEng = -25330.0783 KinEng = 21501.0023 Temp = 299.8230 PotEng = -46831.0806 E_bond = 2471.7004 E_angle = 10836.4977 E_dihed = 5239.6299 E_impro = 227.1218 E_vdwl = -1993.2753 E_coul = 206793.4044 E_long = -270406.1594 Press = 237.6744 Volume = 308031.5641 ----------------- Step 100 ----- CPU = 64.5301 (sec) ---------------- +---------------- Step 100 ----- CPU = 65.3867 (sec) ---------------- TotEng = -25290.7642 KinEng = 21592.0080 Temp = 301.0920 PotEng = -46882.7722 E_bond = 2567.9806 E_angle = 10781.9408 E_dihed = 5198.7431 E_impro = 216.7832 E_vdwl = -1902.4804 E_coul = 206654.9995 E_long = -270400.7389 Press = 6.9875 Volume = 308133.9900 -Loop time of 64.5302 on 1 procs for 100 steps with 32000 atoms +Loop time of 65.3868 on 1 procs for 100 steps with 32000 atoms -Pair time (%) = 46.3691 (71.8564) -Bond time (%) = 2.88541 (4.4714) -Kspce time (%) = 6.09222 (9.44088) -Neigh time (%) = 6.59142 (10.2145) -Comm time (%) = 0.18323 (0.283944) -Outpt time (%) = 0.000371933 (0.000576371) -Other time (%) = 2.40847 (3.73231) +Pair time (%) = 46.2231 (70.6918) +Bond time (%) = 2.88711 (4.41543) +Kspce time (%) = 7.06667 (10.8075) +Neigh time (%) = 6.61535 (10.1173) +Comm time (%) = 0.185745 (0.28407) +Outpt time (%) = 0.000392199 (0.000599813) +Other time (%) = 2.4084 (3.68331) -FFT time (% of Kspce) = 0.434537 (7.13265) -FFT Gflps 3d (1d only) = 1.19598 1.70446 +FFT time (% of Kspce) = 0.430403 (6.0906) +FFT Gflps 3d (1d only) = 1.20747 1.74267 Nlocal: 32000 ave 32000 max 32000 min Histogram: 1 0 0 0 0 0 0 0 0 0 diff --git a/bench/log.10Sep10.rhodo.fixed.linux.4 b/bench/log.28Mar11.rhodo.fixed.linux.4 similarity index 82% rename from bench/log.10Sep10.rhodo.fixed.linux.4 rename to bench/log.28Mar11.rhodo.fixed.linux.4 index 9382b141da..f78c4872a3 100644 --- a/bench/log.10Sep10.rhodo.fixed.linux.4 +++ b/bench/log.28Mar11.rhodo.fixed.linux.4 @@ -1,4 +1,4 @@ -LAMMPS (10 Sep 2010) +LAMMPS (27 Mar 2011) # Rhodopsin model units real @@ -51,37 +51,37 @@ PPPM initialization ... stencil order = 5 RMS precision = 7.57143e-05 brick FFT buffer size/proc = 13230 6400 5670 -Memory usage per processor = 47.7552 Mbytes +Memory usage per processor = 54.4744 Mbytes ---------------- Step 0 ----- CPU = 0.0000 (sec) ---------------- TotEng = -25356.2055 KinEng = 21444.8313 Temp = 299.0397 PotEng = -46801.0368 E_bond = 2537.9940 E_angle = 10921.3742 E_dihed = 5211.7865 E_impro = 213.5116 E_vdwl = -2307.8634 E_coul = 207021.6603 E_long = -270399.5000 Press = -142.6030 Volume = 307995.0335 ----------------- Step 50 ----- CPU = 8.2303 (sec) ---------------- +---------------- Step 50 ----- CPU = 8.2683 (sec) ---------------- TotEng = -25330.0783 KinEng = 21501.0023 Temp = 299.8230 PotEng = -46831.0806 E_bond = 2471.7004 E_angle = 10836.4977 E_dihed = 5239.6299 E_impro = 227.1218 E_vdwl = -1993.2753 E_coul = 206793.4044 E_long = -270406.1594 Press = 237.6744 Volume = 308031.5641 ----------------- Step 100 ----- CPU = 16.7709 (sec) ---------------- +---------------- Step 100 ----- CPU = 16.8728 (sec) ---------------- TotEng = -25290.7642 KinEng = 21592.0080 Temp = 301.0920 PotEng = -46882.7722 E_bond = 2567.9806 E_angle = 10781.9408 E_dihed = 5198.7431 E_impro = 216.7832 E_vdwl = -1902.4804 E_coul = 206654.9995 E_long = -270400.7389 Press = 6.9875 Volume = 308133.9900 -Loop time of 16.771 on 4 procs for 100 steps with 32000 atoms +Loop time of 16.8729 on 4 procs for 100 steps with 32000 atoms -Pair time (%) = 11.2592 (67.1347) -Bond time (%) = 0.685832 (4.08939) -Kspce time (%) = 2.03664 (12.1438) -Neigh time (%) = 1.60447 (9.56693) -Comm time (%) = 0.334371 (1.99374) -Outpt time (%) = 0.00025332 (0.00151046) -Other time (%) = 0.850284 (5.06997) +Pair time (%) = 11.2248 (66.5258) +Bond time (%) = 0.687313 (4.07347) +Kspce time (%) = 2.07329 (12.2877) +Neigh time (%) = 1.59928 (9.47838) +Comm time (%) = 0.410708 (2.43412) +Outpt time (%) = 0.000243425 (0.0014427) +Other time (%) = 0.877245 (5.19914) -FFT time (% of Kspce) = 0.194679 (9.55886) -FFT Gflps 3d (1d only) = 2.6695 6.75898 +FFT time (% of Kspce) = 0.223284 (10.7696) +FFT Gflps 3d (1d only) = 2.32752 6.8543 Nlocal: 8000 ave 8143 max 7933 min Histogram: 1 2 0 0 0 0 0 0 0 1 diff --git a/bench/log.10Sep10.rhodo.scaled.linux.4 b/bench/log.28Mar11.rhodo.scaled.linux.4 similarity index 84% rename from bench/log.10Sep10.rhodo.scaled.linux.4 rename to bench/log.28Mar11.rhodo.scaled.linux.4 index 01409c9756..55e3d66495 100644 --- a/bench/log.10Sep10.rhodo.scaled.linux.4 +++ b/bench/log.28Mar11.rhodo.scaled.linux.4 @@ -1,4 +1,4 @@ -LAMMPS (10 Sep 2010) +LAMMPS (27 Mar 2011) # Rhodopsin model variable x index 1 @@ -72,37 +72,37 @@ PPPM initialization ... stencil order = 5 RMS precision = 7.66425e-05 brick FFT buffer size/proc = 41615 25920 12915 -Memory usage per processor = 130.497 Mbytes +Memory usage per processor = 146.135 Mbytes ---------------- Step 0 ----- CPU = 0.0000 (sec) ---------------- TotEng = -101425.4825 KinEng = 85779.3251 Temp = 299.0304 PotEng = -187204.8077 E_bond = 10151.9760 E_angle = 43685.4968 E_dihed = 20847.1460 E_impro = 854.0463 E_vdwl = -9231.4537 E_coul = 827025.3556 E_long = -1080537.3748 Press = -142.3084 Volume = 1231980.1340 ----------------- Step 50 ----- CPU = 32.9583 (sec) ---------------- +---------------- Step 50 ----- CPU = 32.8194 (sec) ---------------- TotEng = -101320.2611 KinEng = 86003.4849 Temp = 299.8118 PotEng = -187323.7460 E_bond = 9887.1072 E_angle = 43346.7920 E_dihed = 20958.7034 E_impro = 908.4715 E_vdwl = -7973.4456 E_coul = 826113.1533 E_long = -1080564.5278 Press = 238.0165 Volume = 1232126.1854 ----------------- Step 100 ----- CPU = 67.2708 (sec) ---------------- +---------------- Step 100 ----- CPU = 66.9547 (sec) ---------------- TotEng = -101158.1519 KinEng = 86355.6231 Temp = 301.0394 PotEng = -187513.7749 E_bond = 10272.0700 E_angle = 43128.6453 E_dihed = 20793.9768 E_impro = 867.0826 E_vdwl = -7586.7196 E_coul = 825555.5006 E_long = -1080544.3306 Press = 15.2192 Volume = 1232535.8453 -Loop time of 67.2712 on 4 procs for 100 steps with 128000 atoms +Loop time of 66.9548 on 4 procs for 100 steps with 128000 atoms -Pair time (%) = 45.8103 (68.0979) -Bond time (%) = 2.8855 (4.28936) -Kspce time (%) = 7.55695 (11.2335) -Neigh time (%) = 6.5594 (9.75068) -Comm time (%) = 0.880104 (1.30829) -Outpt time (%) = 0.000582039 (0.000865213) -Other time (%) = 3.57839 (5.31935) +Pair time (%) = 45.779 (68.373) +Bond time (%) = 2.87439 (4.29303) +Kspce time (%) = 7.5089 (11.2149) +Neigh time (%) = 6.52016 (9.73816) +Comm time (%) = 0.765243 (1.14293) +Outpt time (%) = 0.000411808 (0.000615055) +Other time (%) = 3.50669 (5.2374) -FFT time (% of Kspce) = 1.19838 (15.858) -FFT Gflps 3d (1d only) = 1.99837 6.14282 +FFT time (% of Kspce) = 1.17001 (15.5816) +FFT Gflps 3d (1d only) = 2.04683 6.15771 Nlocal: 32000 ave 32000 max 32000 min Histogram: 4 0 0 0 0 0 0 0 0 0 diff --git a/doc/Developer.pdf b/doc/Developer.pdf new file mode 100644 index 0000000000..55b5015e49 Binary files /dev/null and b/doc/Developer.pdf differ diff --git a/doc/Eqs/angle_cosine_shift.jpg b/doc/Eqs/angle_cosine_shift.jpg new file mode 100644 index 0000000000..1f0bb56850 Binary files /dev/null and b/doc/Eqs/angle_cosine_shift.jpg differ diff --git a/doc/Eqs/angle_cosine_shift.tex b/doc/Eqs/angle_cosine_shift.tex new file mode 100644 index 0000000000..e795d6beff --- /dev/null +++ b/doc/Eqs/angle_cosine_shift.tex @@ -0,0 +1,9 @@ +\documentstyle[12pt]{article} + +\begin{document} + +$$ +E=-\frac{Umin}{2} \left[ 1+Cos(\theta-\theta_0) \right] +$$ + +\end{document} diff --git a/doc/Eqs/angle_cosine_shift_exp.jpg b/doc/Eqs/angle_cosine_shift_exp.jpg new file mode 100644 index 0000000000..1a3cc05bd2 Binary files /dev/null and b/doc/Eqs/angle_cosine_shift_exp.jpg differ diff --git a/doc/Eqs/angle_cosine_shift_exp.tex b/doc/Eqs/angle_cosine_shift_exp.tex new file mode 100644 index 0000000000..4afa01356c --- /dev/null +++ b/doc/Eqs/angle_cosine_shift_exp.tex @@ -0,0 +1,13 @@ +\documentstyle[12pt]{article} + +\begin{document} + +$$ +E=-U_{min} +\frac{e^{-a U(\theta,\theta_0)}-1}{e^a-1} +\quad\mbox{with}\quad +U(\theta,\theta_0) +=-0.5 \left(1+\cos(\theta-\theta_0) \right) +$$ + +\end{document} diff --git a/doc/Eqs/bond_harmonic_shift.jpg b/doc/Eqs/bond_harmonic_shift.jpg new file mode 100644 index 0000000000..cac7bcdbbf Binary files /dev/null and b/doc/Eqs/bond_harmonic_shift.jpg differ diff --git a/doc/Eqs/bond_harmonic_shift.tex b/doc/Eqs/bond_harmonic_shift.tex new file mode 100644 index 0000000000..3daa16724f --- /dev/null +++ b/doc/Eqs/bond_harmonic_shift.tex @@ -0,0 +1,9 @@ +\documentclass[12pt]{article} + +\begin{document} + +$$ + E = \frac{Umin}{(r_0-r_c)^2} \left[ (r-r_0)^2-(r_c-r_0)^2 \right] +$$ + +\end{document} \ No newline at end of file diff --git a/doc/Eqs/bond_harmonic_shift_cut.jpg b/doc/Eqs/bond_harmonic_shift_cut.jpg new file mode 100644 index 0000000000..821db256df Binary files /dev/null and b/doc/Eqs/bond_harmonic_shift_cut.jpg differ diff --git a/doc/Eqs/bond_harmonic_shift_cut.tex b/doc/Eqs/bond_harmonic_shift_cut.tex new file mode 100644 index 0000000000..3daa16724f --- /dev/null +++ b/doc/Eqs/bond_harmonic_shift_cut.tex @@ -0,0 +1,9 @@ +\documentclass[12pt]{article} + +\begin{document} + +$$ + E = \frac{Umin}{(r_0-r_c)^2} \left[ (r-r_0)^2-(r_c-r_0)^2 \right] +$$ + +\end{document} \ No newline at end of file diff --git a/doc/Eqs/box.jpg b/doc/Eqs/box.jpg index 712d49cdd3..df1c2bfce5 100644 Binary files a/doc/Eqs/box.jpg and b/doc/Eqs/box.jpg differ diff --git a/doc/Eqs/box_inverse.jpg b/doc/Eqs/box_inverse.jpg new file mode 100644 index 0000000000..1815bba239 Binary files /dev/null and b/doc/Eqs/box_inverse.jpg differ diff --git a/doc/Eqs/box_inverse.tex b/doc/Eqs/box_inverse.tex new file mode 100644 index 0000000000..68994f2868 --- /dev/null +++ b/doc/Eqs/box_inverse.tex @@ -0,0 +1,14 @@ +\documentclass[12pt]{article} + +\begin{document} + +\begin{eqnarray*} +{\rm lx} &=& a \\ +{\rm xy} &=& b \cos{\gamma} \\ +{\rm xz} &=& c \cos{\beta}\\ +{\rm ly}^2 &=& b^2 - {\rm xy}^2 \\ +{\rm yz} &=& \frac{b*c \cos{\alpha} - {\rm xy}*{\rm xz}}{\rm ly} \\ +{\rm lz}^2 &=& c^2 - {\rm xz}^2 - {\rm yz}^2 \\ +\end{eqnarray*} + +\end{document} diff --git a/doc/Eqs/dihedral_cosine_shift_exp.jpg b/doc/Eqs/dihedral_cosine_shift_exp.jpg new file mode 100644 index 0000000000..646bb52a6b Binary files /dev/null and b/doc/Eqs/dihedral_cosine_shift_exp.jpg differ diff --git a/doc/Eqs/dihedral_cosine_shift_exp.tex b/doc/Eqs/dihedral_cosine_shift_exp.tex new file mode 100644 index 0000000000..4afa01356c --- /dev/null +++ b/doc/Eqs/dihedral_cosine_shift_exp.tex @@ -0,0 +1,13 @@ +\documentstyle[12pt]{article} + +\begin{document} + +$$ +E=-U_{min} +\frac{e^{-a U(\theta,\theta_0)}-1}{e^a-1} +\quad\mbox{with}\quad +U(\theta,\theta_0) +=-0.5 \left(1+\cos(\theta-\theta_0) \right) +$$ + +\end{document} diff --git a/doc/Eqs/fix_nphug.jpg b/doc/Eqs/fix_nphug.jpg new file mode 100644 index 0000000000..beed5ed5c9 Binary files /dev/null and b/doc/Eqs/fix_nphug.jpg differ diff --git a/doc/Eqs/fix_nphug.tex b/doc/Eqs/fix_nphug.tex new file mode 100644 index 0000000000..4e162b69b7 --- /dev/null +++ b/doc/Eqs/fix_nphug.tex @@ -0,0 +1,9 @@ +\documentstyle[12pt]{article} + +\begin{document} + +$$ +T_t - T = \frac{\left(\frac{1}{2}\left(P + P_0\right)\left(V_0 - V\right) + E_0 - E\right)}{N_{dof} k_B } = Delta +$$ + +\end{document} diff --git a/doc/Eqs/fld.jpg b/doc/Eqs/fld.jpg new file mode 100644 index 0000000000..6ae18718d7 Binary files /dev/null and b/doc/Eqs/fld.jpg differ diff --git a/doc/Eqs/fld.tex b/doc/Eqs/fld.tex new file mode 100644 index 0000000000..7c75cfbe60 --- /dev/null +++ b/doc/Eqs/fld.tex @@ -0,0 +1,9 @@ +\documentstyle[12pt]{article} + +\begin{document} + +$$ +F^{H} = -R_{FU}(U-U^{\infty}) + R_{FE}E^{\infty} +$$ + +\end{document} diff --git a/doc/Eqs/fld2.jpg b/doc/Eqs/fld2.jpg new file mode 100644 index 0000000000..ff88680b7d Binary files /dev/null and b/doc/Eqs/fld2.jpg differ diff --git a/doc/Eqs/fld2.tex b/doc/Eqs/fld2.tex new file mode 100644 index 0000000000..43adae11db --- /dev/null +++ b/doc/Eqs/fld2.tex @@ -0,0 +1,9 @@ +\documentstyle[12pt]{article} + +\begin{document} + +$$ +-R_{FU}(U-U^{\infty}) = -R_{FE}E^{\infty} - F^{rest} +$$ + +\end{document} diff --git a/doc/Eqs/pair_adp.jpg b/doc/Eqs/pair_adp.jpg new file mode 100644 index 0000000000..c2ad8deb2a Binary files /dev/null and b/doc/Eqs/pair_adp.jpg differ diff --git a/doc/Eqs/pair_adp.tex b/doc/Eqs/pair_adp.tex new file mode 100644 index 0000000000..4ba8ad76ee --- /dev/null +++ b/doc/Eqs/pair_adp.tex @@ -0,0 +1,26 @@ +\documentclass[12pt]{article} + +\begin{document} + +\begin{eqnarray*} +E_{i} & = & F_{\alpha} \left( \sum_{j \ne i} \rho(r_{ij}) \right) + +\frac{1}{2} \sum_{j \ne i} \phi_{\alpha \beta} (r_{ij}) + +\frac{1}{2} \sum_{i,s} \left( \mu_{i}^{s} \right)^2 + +\sum_{i,s,t} \left( \lambda_{i}^{st} \right)^2 - \frac{1}{6} \nu_{i} \\ +\mu_{i}^{s} & = & \sum_{i \ne j} u(r_{ij}) r_{ij}^{s} \\ +\lambda_{i}^{st} & = & \sum_{i \ne j} w(r_{ij}) r_{ij}^{s} r_{ij}^{t} \\ +\nu_{i} & = & \sum_{s} \lambda_{i}^{ss} +\end{eqnarray*} + +\begin{eqnarray*} +E_i & = & F_\alpha \left( \sum_{j\neq i} \rho_\beta (r_{ij}) \right) + \frac{1}{2} \sum_{j\neq i}\phi_{\alpha\beta}(r_{ij})+ \frac{1}{2} \sum_s (\mu_i^s)^2 + \frac{1}{2} \sum_{s,t} (\lambda_i^{st})^2 - \frac{1}{6} \nu_i^2 \\ +% +\mu_i^s & = & \sum_{j\neq i}u_{\alpha\beta}(r_{ij})r_{ij}^s\\ +% +\lambda_i^{st} & = & \sum_{j\neq i}w_{\alpha\beta}(r_{ij})r_{ij}^sr_{ij}^t\\ +% +\nu_i & = & \sum_s\lambda_i^{ss} +\end{eqnarray*} + +\end{document} + diff --git a/doc/Eqs/pair_dipole_sf.jpg b/doc/Eqs/pair_dipole_sf.jpg new file mode 100644 index 0000000000..536ea7f2c8 Binary files /dev/null and b/doc/Eqs/pair_dipole_sf.jpg differ diff --git a/doc/Eqs/pair_dipole_sf.tex b/doc/Eqs/pair_dipole_sf.tex new file mode 100644 index 0000000000..c653a37740 --- /dev/null +++ b/doc/Eqs/pair_dipole_sf.tex @@ -0,0 +1,51 @@ +\documentclass[12pt]{article} + +\begin{document} + +\begin{eqnarray*} +E_{LJ} & = & 4\epsilon \left\{ \left[ \left( \frac{\sigma}{r} \right)^{\!12} - + \left( \frac{\sigma}{r} \right)^{\!6} \right] + + \left[ 6\left( \frac{\sigma}{r_c} \right)^{\!12} - + 3\left(\frac{\sigma}{r_c}\right)^{\!6}\right]\left(\frac{r}{r_c}\right)^{\!2} + - 7\left( \frac{\sigma}{r_c} \right)^{\!12} + + 4\left( \frac{\sigma}{r_c} \right)^{\!6}\right\} \\ +E_{qq} & = & \frac{q_i q_j}{r}\left(1-\frac{r}{r_c}\right)^{\!2} \\ +E_{pq} & = & E_{ji} = -\frac{q}{r^3} \left[ 1 - + 3\left(\frac{r}{r_c}\right)^{\!2} + + 2\left(\frac{r}{r_c}\right)^{\!3}\right] (\vec{p}\bullet\vec{r}) \\ +E_{qp} & = & E_{ij} = \frac{q}{r^3} \left[ 1 - + 3\left(\frac{r}{r_c}\right)^{\!2} + + 2\left(\frac{r}{r_c}\right)^{\!3}\right] (\vec{p}\bullet\vec{r}) \\ +E_{pp} & = & \left[1-4\left(\frac{r}{r_c}\right)^{\!3} + + 3\left(\frac{r}{r_c}\right)^{\!4}\right]\left[\frac{1}{r^3} + (\vec{p_i} \bullet \vec{p_j}) - \frac{3}{r^5} + (\vec{p_i} \bullet \vec{r}) (\vec{p_j} \bullet \vec{r})\right] \\ +\end{eqnarray*} + +\begin{eqnarray*} +F_{LJ} & = & \left\{\left[48\epsilon \left(\frac{\sigma}{r}\right)^{\!12} - + 24\epsilon \left(\frac{\sigma}{r}\right)^{\!6} \right]\frac{1}{r^2} - + \left[48\epsilon \left(\frac{\sigma}{r_c}\right)^{\!12} - 24\epsilon + \left(\frac{\sigma}{r_c}\right)^{\!6} \right]\frac{1}{r_c^2}\right\}\vec{r}\\ +F_{qq} & = & \frac{q_i q_j}{r}\left(\frac{1}{r^2} - + \frac{1}{r_c^2}\right)\vec{r} \\ +F_{pq} &=& F_{ij } = -\frac{3q}{r^5} \left[ 1 - + \left(\frac{r}{r_c}\right)^{\!2}\right](\vec{p}\bullet\vec{r})\vec{r} + + \frac{q}{r^3}\left[1-3\left(\frac{r}{r_c}\right)^{\!2} + + 2\left(\frac{r}{r_c}\right)^{\!3}\right] \vec{p} \\ +F_{qp} &=& F_{ij} = \frac{3q}{r^5} \left[ 1 - + \left(\frac{r}{r_c}\right)^{\!2}\right] (\vec{p}\bullet\vec{r})\vec{r} - + \frac{q}{r^3}\left[1-3\left(\frac{r}{r_c}\right)^{\!2} + + 2\left(\frac{r}{r_c}\right)^{\!3}\right] \vec{p} \\ +F_{pp} & = &\frac{3}{r^5}\Bigg\{\left[1-\left(\frac{r}{r_c}\right)^{\!4}\right] + \left[(\vec{p_i}\bullet\vec{p_j}) - \frac{3}{r^2} (\vec{p_i}\bullet\vec{r}) + (\vec{p_j} \bullet \vec{r})\right] \vec{r} + \\ + & & \left[1 - + 4\left(\frac{r}{r_c}\right)^{\!3}+3\left(\frac{r}{r_c}\right)^{\!4}\right] + \left[ (\vec{p_j} \bullet \vec{r}) \vec{p_i} + (\vec{p_i} \bullet \vec{r}) + \vec{p_j} -\frac{2}{r^2} (\vec{p_i} \bullet \vec{r}) + (\vec{p_j} \bullet \vec{r})\vec{r}\right] \Bigg\} \\ +\end{eqnarray*} + +\end{document} + diff --git a/doc/Eqs/pair_dipole_sf2.jpg b/doc/Eqs/pair_dipole_sf2.jpg new file mode 100644 index 0000000000..f45f583732 Binary files /dev/null and b/doc/Eqs/pair_dipole_sf2.jpg differ diff --git a/doc/Eqs/pair_dipole_sf2.tex b/doc/Eqs/pair_dipole_sf2.tex new file mode 100644 index 0000000000..74758ba230 --- /dev/null +++ b/doc/Eqs/pair_dipole_sf2.tex @@ -0,0 +1,24 @@ +\documentclass[12pt]{article} + +\begin{document} + +\begin{eqnarray*} +T_{pq} = T_{ij} & = & \frac{q_j}{r^3} \left[ 1 - + 3\left(\frac{r}{r_c}\right)^{\!2} + + 2\left(\frac{r}{r_c}\right)^{\!3}\right] (\vec{p_i}\times\vec{r}) \\ +T_{qp} = T_{ji} & = & - \frac{q_i}{r^3} \left[ 1 - + 3\left(\frac{r}{r_c}\right)^{\!2} + + 2\left(\frac{r}{r_c}\right)^{\!3} \right] (\vec{p_j}\times\vec{r}) \\ +T_{pp} = T_{ij} & = & -\frac{1}{r^3}\left[1-4\left(\frac{r}{r_c}\right)^{\!3} + + e3\left(\frac{r}{r_c}\right)^{\!4}\right] (\vec{p_i} \times \vec{p_j}) + \\ + & & \frac{3}{r^5}\left[1-4\left(\frac{r}{r_c}\right)^{\!3} + + 3\left(\frac{r}{r_c}\right)^{\!4}\right] (\vec{p_j}\bullet\vec{r}) + (\vec{p_i} \times \vec{r}) \\ +T_{pp} = T_{ji} & = & -\frac{1}{r^3}\left[1-4\left(\frac{r}{r_c}\right)^{\!3} + + 3\left(\frac{r}{r_c}\right)^{\!4}\right](\vec{p_j} \times \vec{p_i}) + \\ + & & \frac{3}{r^5}\left[1-4\left(\frac{r}{r_c}\right)^{\!3} + + 3\left(\frac{r}{r_c}\right)^{\!4}\right] (\vec{p_i} \bullet \vec{r}) + (\vec{p_j} \times \vec{r}) \\ +\end{eqnarray*} + +\end{document} diff --git a/doc/Eqs/pair_eam.jpg b/doc/Eqs/pair_eam.jpg index 50e991d8c6..e82f6dd4a7 100644 Binary files a/doc/Eqs/pair_eam.jpg and b/doc/Eqs/pair_eam.jpg differ diff --git a/doc/Eqs/pair_eam.tex b/doc/Eqs/pair_eam.tex index 05c2085d4d..2ea20b2198 100644 --- a/doc/Eqs/pair_eam.tex +++ b/doc/Eqs/pair_eam.tex @@ -3,8 +3,8 @@ \begin{document} $$ - E_i = F_\alpha \left(\sum_{j \neq i}\ \rho_\alpha (r_{ij})\right) + + E_i = F_\alpha \left(\sum_{j \neq i}\ \rho_\beta (r_{ij})\right) + \frac{1}{2} \sum_{j \neq i} \phi_{\alpha\beta} (r_{ij}) $$ -\end{document} \ No newline at end of file +\end{document} diff --git a/doc/Eqs/pair_edip.jpg b/doc/Eqs/pair_edip.jpg new file mode 100644 index 0000000000..9e7a8d77d3 Binary files /dev/null and b/doc/Eqs/pair_edip.jpg differ diff --git a/doc/Eqs/pair_edip.tex b/doc/Eqs/pair_edip.tex new file mode 100644 index 0000000000..27f5dd9eec --- /dev/null +++ b/doc/Eqs/pair_edip.tex @@ -0,0 +1,22 @@ +\documentclass[12pt]{article} + +\usepackage{amssymb,amsmath} + +\begin{document} + +\begin{eqnarray*} +E & = & \sum_{j \ne i} \phi_{2}(R_{ij}, Z_{i}) + \sum_{j \ne i} \sum_{k \ne i,k > j} \phi_{3}(R_{ij}, R_{ik}, Z_{i}) \\ +\phi_{2}(r, Z) & = & A\left[\left(\frac{B}{r}\right)^{\rho} - e^{-\beta Z^2}\right]exp{\left(\frac{\sigma}{r-a}\right)} \\ +\phi_{3}(R_{ij}, R_{ik}, Z_i) & = & exp{\left(\frac{\gamma}{R_{ij}-a}\right)}exp{\left(\frac{\gamma}{R_{ik}-a}\right)}h(cos\theta_{ijk},Z_i) \\ +Z_i & = & \sum_{m \ne i} f(R_{im}) \qquad + f(r) = \begin{cases} + 1 & \quad ra + \end{cases} \\ +h(l,Z) & = & \lambda [(1-e^{-Q(Z)(l+\tau(Z))^2}) + \eta Q(Z)(l+\tau(Z))^2 ] \\ +Q(Z) & = & Q_0 e^{-\mu Z} \qquad \tau(Z) = u_1 + u_2 (u_3 e^{-u_4 Z} - e^{-2u_4 Z}) +\end{eqnarray*} + +\end{document} + diff --git a/doc/Eqs/pair_gauss_cut.jpg b/doc/Eqs/pair_gauss_cut.jpg new file mode 100644 index 0000000000..a2cd680e52 Binary files /dev/null and b/doc/Eqs/pair_gauss_cut.jpg differ diff --git a/doc/Eqs/pair_gauss_cut.tex b/doc/Eqs/pair_gauss_cut.tex new file mode 100644 index 0000000000..5d0bb430f3 --- /dev/null +++ b/doc/Eqs/pair_gauss_cut.tex @@ -0,0 +1,8 @@ +\documentclass[12pt]{article} +\pagestyle{empty} +\begin{document} + +\begin{eqnarray*} + E = & \frac{H}{\sigma_h\sqrt{2\pi}} \exp\left[-\frac{(r-r_{mh})^2}{2\sigma_h^2}\right] +\end{eqnarray*} +\end{document} diff --git a/doc/Eqs/pair_gromacs.jpg b/doc/Eqs/pair_gromacs.jpg index 1f7c065511..4902fe0164 100644 Binary files a/doc/Eqs/pair_gromacs.jpg and b/doc/Eqs/pair_gromacs.jpg differ diff --git a/doc/Eqs/pair_gromacs.tex b/doc/Eqs/pair_gromacs.tex index c08ad59bdf..e51ca09578 100644 --- a/doc/Eqs/pair_gromacs.tex +++ b/doc/Eqs/pair_gromacs.tex @@ -7,8 +7,8 @@ E_{LJ} & = & 4 \epsilon \left[ \left(\frac{\sigma}{r}\right)^{12} - \left(\frac{\sigma}{r}\right)^6 \right] + S_{LJ}(r) \qquad r < r_c \\ E_C & = & \frac{C q_i q_j}{\epsilon r} + S_C(r) \qquad r < r_c \\ -S(r) & = & 0 \qquad r < r_1 \\ -S(r) & = & A (r - r_1)^2 + B (r - r_1)^3 \qquad r_1 < r < r_c +S(r) & = & C \qquad r < r_1 \\ +S(r) & = & \frac{A}{3} (r - r_1)^3 + \frac{B}{4} (r - r_1)^4 + C \qquad r_1 < r < r_c \end{eqnarray*} \end{document} diff --git a/doc/Eqs/pair_hbond_dreiding.jpg b/doc/Eqs/pair_hbond_dreiding.jpg index a8f0a30c0e..cb1e38ba42 100644 Binary files a/doc/Eqs/pair_hbond_dreiding.jpg and b/doc/Eqs/pair_hbond_dreiding.jpg differ diff --git a/doc/Eqs/pair_hbond_dreiding.tex b/doc/Eqs/pair_hbond_dreiding.tex index 9a479dc157..9663ee5608 100644 --- a/doc/Eqs/pair_hbond_dreiding.tex +++ b/doc/Eqs/pair_hbond_dreiding.tex @@ -1,16 +1,18 @@ \documentstyle[12pt]{article} \begin{document} - -$$ -E^{hb}_{LJ}(r)=AR^{-12}-BR^{-10}cos^n\theta=4\epsilon\left\lbrace 5\left[ \frac{\sigma}{r}\right]^{12}-6\left[ \frac{\sigma}{r}\right]^{10} \right\rbrace cos^n\theta -$$ - -$$ -E^{hb}_{MORSE}(r)=D_0\left\lbrace \chi^2 - 2\chi\right\rbrace cos^n\theta=D_{0}\left\lbrace e^{- 2 \alpha (r - r_0)} - 2 e^{- \alpha (r - r_0)} \right\rbrace cos^n\theta -$$ - -$$ -where \qquad r < r_c, \qquad cos^2\left( \theta\right) > cos^2\left( \theta_c\right) -$$ +\begin{eqnarray*} + E & = & \left[LJ(r) | Morse(r) \right] \qquad \qquad \qquad r < r_{\rm in} \\ + & = & S(r) * \left[LJ(r) | Morse(r) \right] \qquad \qquad r_{\rm in} < r < r_{\rm out} \\ + & = & 0 \qquad \qquad \qquad \qquad \qquad \qquad \qquad r > r_{\rm out} \\ + LJ(r) & = & AR^{-12}-BR^{-10}cos^n\theta= + \epsilon\left\lbrace 5\left[ \frac{\sigma}{r}\right]^{12}- + 6\left[ \frac{\sigma}{r}\right]^{10} \right\rbrace cos^n\theta\\ + Morse(r) & = & D_0\left\lbrace \chi^2 - 2\chi\right\rbrace cos^n\theta= + D_{0}\left\lbrace e^{- 2 \alpha (r - r_0)} - 2 e^{- \alpha (r - r_0)} + \right\rbrace cos^n\theta \\ + S(r) & = & \frac{ \left[r_{\rm out}^2 - r^2\right]^2 + \left[r_{\rm out}^2 + 2r^2 - 3{r_{\rm in}^2}\right]} + { \left[r_{\rm out}^2 - {r_{\rm in}}^2\right]^3 } +\end{eqnarray*} \end{document} diff --git a/doc/Eqs/pair_lj_cubic.jpg b/doc/Eqs/pair_lj_cubic.jpg new file mode 100644 index 0000000000..25ffe2cbf8 Binary files /dev/null and b/doc/Eqs/pair_lj_cubic.jpg differ diff --git a/doc/Eqs/pair_lj_cubic.tex b/doc/Eqs/pair_lj_cubic.tex new file mode 100644 index 0000000000..e2e1b67dd7 --- /dev/null +++ b/doc/Eqs/pair_lj_cubic.tex @@ -0,0 +1,12 @@ +\documentstyle[12pt]{article} + +\begin{document} + +\begin{eqnarray*} + E &=& u_{LJ}(r) \qquad r \leq r_s \\ + &=& u_{LJ}(r_s) + (r-r_s) u'_{LJ}(r_s) - \frac{1}{6} A_3 (r-r_s)^3 \qquad r_s < r \leq r_c \\ + &=& 0 \qquad r > r_c +\end{eqnarray*} + + +\end{document} diff --git a/doc/Eqs/pair_lj_sf.jpg b/doc/Eqs/pair_lj_sf.jpg new file mode 100644 index 0000000000..620331667c Binary files /dev/null and b/doc/Eqs/pair_lj_sf.jpg differ diff --git a/doc/Eqs/pair_lj_sf.tex b/doc/Eqs/pair_lj_sf.tex new file mode 100644 index 0000000000..e78e2ca75f --- /dev/null +++ b/doc/Eqs/pair_lj_sf.tex @@ -0,0 +1,11 @@ +\documentclass[12pt]{article} + +\begin{document} + +\begin{eqnarray*} + F & = & F_{\mathrm{LJ}}(r) - F_{\mathrm{LJ}}(r_{\mathrm{c}}) \qquad r < r_{\mathrm{c}} \\ + E & = & E_{\mathrm{LJ}}(r) - E_{\mathrm{LJ}}(r_{\mathrm{c}}) + (r - r_{\mathrm{c}}) F_{\mathrm{LJ}}(r_{\mathrm{c}}) \qquad r < r_{\mathrm{c}} \\ + \mathrm{with} \qquad E_{\mathrm{LJ}}(r) & = & 4 \epsilon \left[ \left(\frac{\sigma}{r}\right)^{12} - \left(\frac{\sigma}{r}\right)^6 \right] \qquad \mathrm{and} \qquad F_{\mathrm{LJ}}(r) = - E^\prime_{\mathrm{LJ}}(r) +\end{eqnarray*} + +\end{document} diff --git a/doc/Eqs/pair_sph_ideal.jpg b/doc/Eqs/pair_sph_ideal.jpg new file mode 100644 index 0000000000..ad9760d5ec Binary files /dev/null and b/doc/Eqs/pair_sph_ideal.jpg differ diff --git a/doc/Eqs/pair_sph_ideal.tex b/doc/Eqs/pair_sph_ideal.tex new file mode 100644 index 0000000000..91c64f00bc --- /dev/null +++ b/doc/Eqs/pair_sph_ideal.tex @@ -0,0 +1,9 @@ +\documentclass[12pt]{article} + +\begin{document} + +$$ + p = (\gamma - 1) \rho e +$$ + +\end{document} diff --git a/doc/Eqs/pair_sph_tait.jpg b/doc/Eqs/pair_sph_tait.jpg new file mode 100644 index 0000000000..96adab38e0 Binary files /dev/null and b/doc/Eqs/pair_sph_tait.jpg differ diff --git a/doc/Eqs/pair_sph_tait.tex b/doc/Eqs/pair_sph_tait.tex new file mode 100644 index 0000000000..4e1fa9cfed --- /dev/null +++ b/doc/Eqs/pair_sph_tait.tex @@ -0,0 +1,9 @@ +\documentclass[12pt]{article} + +\begin{document} + +$$ + p = B [(\frac{\rho}{\rho_0})^{\gamma} - 1] +$$ + +\end{document} diff --git a/doc/JPG/dump1.jpg b/doc/JPG/dump1.jpg new file mode 100644 index 0000000000..6068ba017c Binary files /dev/null and b/doc/JPG/dump1.jpg differ diff --git a/doc/JPG/dump1_small.jpg b/doc/JPG/dump1_small.jpg new file mode 100644 index 0000000000..2ac2015d21 Binary files /dev/null and b/doc/JPG/dump1_small.jpg differ diff --git a/doc/JPG/dump2.jpg b/doc/JPG/dump2.jpg new file mode 100644 index 0000000000..bd0d573e1a Binary files /dev/null and b/doc/JPG/dump2.jpg differ diff --git a/doc/JPG/dump2_small.jpg b/doc/JPG/dump2_small.jpg new file mode 100644 index 0000000000..9393ba613f Binary files /dev/null and b/doc/JPG/dump2_small.jpg differ diff --git a/doc/Manual.html b/doc/Manual.html index 8160d57aa9..afd2d10ff4 100644 --- a/doc/Manual.html +++ b/doc/Manual.html @@ -40,8 +40,12 @@ describe the most current version of LAMMPS. describe the version you have.
  • The PDF file on the WWW site or in the tarball is updated -about once per month. This is because it is large, and we don't want +about once per month. This is because it is large, and we don't want it to be part of very patch. + +
  • There is also a Developer.pdf file in the doc +directory, which describes the internal structure and algorithms of +LAMMPS.

    LAMMPS stands for Large-scale Atomic/Molecular Massively Parallel Simulator. @@ -78,91 +82,107 @@ it gives quick access to documentation for all LAMMPS commands.

    1. Introduction -
    @@ -287,6 +335,46 @@ it gives quick access to documentation for all LAMMPS commands. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/doc/Manual.pdf b/doc/Manual.pdf index 0f74628fa2..fba5069280 100644 Binary files a/doc/Manual.pdf and b/doc/Manual.pdf differ diff --git a/doc/Manual.txt b/doc/Manual.txt index d28dbf7f6e..62e27cc4a7 100644 --- a/doc/Manual.txt +++ b/doc/Manual.txt @@ -37,8 +37,12 @@ If you browse the HTML doc pages included in your tarball, they describe the version you have. :l The "PDF file"_Manual.pdf on the WWW site or in the tarball is updated -about once per month. This is because it is large, and we don't want -it to be part of very patch. :ule,l +about once per month. This is because it is large, and we don't want +it to be part of very patch. :l + +There is also a "Developer.pdf"_Developer.pdf file in the doc +directory, which describes the internal structure and algorithms of +LAMMPS. :ule,l LAMMPS stands for Large-scale Atomic/Molecular Massively Parallel Simulator. @@ -73,127 +77,172 @@ it gives quick access to documentation for all LAMMPS commands. "htmldoc"_http://www.easysw.com/htmldoc "Introduction"_Section_intro.html :olb,l - 1.1 "What is LAMMPS"_1_1 :ulb,b - 1.2 "LAMMPS features"_1_2 :b - 1.3 "LAMMPS non-features"_1_3 :b - 1.4 "Open source distribution"_1_4 :b - 1.5 "Acknowledgments and citations"_1_5 :ule,b + 1.1 "What is LAMMPS"_intro_1 :ulb,b + 1.2 "LAMMPS features"_intro_2 :b + 1.3 "LAMMPS non-features"_intro_3 :b + 1.4 "Open source distribution"_intro_4 :b + 1.5 "Acknowledgments and citations"_intro_5 :ule,b "Getting started"_Section_start.html :l - 2.1 "What's in the LAMMPS distribution"_2_1 :ulb,b - 2.2 "Making LAMMPS"_2_2 :b - 2.3 "Making LAMMPS with optional packages"_2_3 :b - 2.4 "Building LAMMPS as a library"_2_4 :b - 2.5 "Running LAMMPS"_2_5 :b - 2.6 "Command-line options"_2_6 :b - 2.7 "Screen output"_2_7 :b - 2.8 "Running on GPUs"_2_8 :b - 2.9 "Tips for users of previous versions"_2_9 :ule,b + 2.1 "What's in the LAMMPS distribution"_start_1 :ulb,b + 2.2 "Making LAMMPS"_start_2 :b + 2.3 "Making LAMMPS with optional packages"_start_3 :b + 2.4 "Building LAMMPS as a library"_start_4 :b + 2.5 "Running LAMMPS"_start_5 :b + 2.6 "Command-line options"_start_6 :b + 2.7 "Screen output"_start_7 :b + 2.8 "Tips for users of previous versions"_2_8 :ule,b "Commands"_Section_commands.html :l - 3.1 "LAMMPS input script"_3_1 :ulb,b - 3.2 "Parsing rules"_3_2 :b - 3.3 "Input script structure"_3_3 :b - 3.4 "Commands listed by category"_3_4 :b - 3.5 "Commands listed alphabetically"_3_5 :ule,b + 3.1 "LAMMPS input script"_cmd_1 :ulb,b + 3.2 "Parsing rules"_cmd_2 :b + 3.3 "Input script structure"_cmd_3 :b + 3.4 "Commands listed by category"_cmd_4 :b + 3.5 "Commands listed alphabetically"_cmd_5 :ule,b +"Packages"_Section_packages.html :l + 4.1 "Standard packages"_pkg_1 :ulb,b + 4.2 "User packages"_pkg_2 :ule,b +"Accelerating LAMMPS performance"_Section_accelerate.html :l + 5.1 "OPT package"_acc_1 :ulb,b + 5.2 "USER-OMP package"_acc_2 :b + 5.3 "GPU package"_acc_3 :b + 5.4 "USER-CUDA package"_acc_4 :b + 5.5 "Comparison of GPU and USER-CUDA packages"_acc_5 :ule,b "How-to discussions"_Section_howto.html :l - 4.1 "Restarting a simulation"_4_1 :ulb,b - 4.2 "2d simulations"_4_2 :b - 4.3 "CHARMM and AMBER force fields"_4_3 :b - 4.4 "Running multiple simulations from one input script"_4_4 :b - 4.5 "Multi-replica simulations"_4_5 :b - 4.6 "Granular models"_4_6 :b - 4.7 "TIP3P water model"_4_7 :b - 4.8 "TIP4P water model"_4_8 :b - 4.9 "SPC water model"_4_9 :b - 4.10 "Coupling LAMMPS to other codes"_4_10 :b - 4.11 "Visualizing LAMMPS snapshots"_4_11 :b - 4.12 "Triclinic (non-orthogonal) simulation boxes"_4_12 :b - 4.13 "NEMD simulations"_4_13 :b - 4.14 "Extended spherical and aspherical particles"_4_14 :b - 4.15 "Output from LAMMPS (thermo, dumps, computes, fixes, variables)"_4_15 :b - 4.16 "Thermostatting, barostatting, and compute temperature"_4_16 :b - 4.17 "Walls"_4_17 :b - 4.18 "Elastic constants"_4_18 :b - 4.19 "Library interface to LAMMPS"_4_19 :b - 4.20 "Calculating thermal conductivity"_4_20 :b - 4.21 "Calculating viscosity"_4_21 :ule,b + 6.1 "Restarting a simulation"_howto_1 :ulb,b + 6.2 "2d simulations"_howto_2 :b + 6.3 "CHARMM and AMBER force fields"_howto_3 :b + 6.4 "Running multiple simulations from one input script"_howto_4 :b + 6.5 "Multi-replica simulations"_howto_5 :b + 6.6 "Granular models"_howto_6 :b + 6.7 "TIP3P water model"_howto_7 :b + 6.8 "TIP4P water model"_howto_8 :b + 6.9 "SPC water model"_howto_9 :b + 6.10 "Coupling LAMMPS to other codes"_howto_10 :b + 6.11 "Visualizing LAMMPS snapshots"_howto_11 :b + 6.12 "Triclinic (non-orthogonal) simulation boxes"_howto_12 :b + 6.13 "NEMD simulations"_howto_13 :b + 6.14 "Extended spherical and aspherical particles"_howto_14 :b + 6.15 "Output from LAMMPS (thermo, dumps, computes, fixes, variables)"_howto_15 :b + 6.16 "Thermostatting, barostatting, and compute temperature"_howto_16 :b + 6.17 "Walls"_howto_17 :b + 6.18 "Elastic constants"_howto_18 :b + 6.19 "Library interface to LAMMPS"_howto_19 :b + 6.20 "Calculating thermal conductivity"_howto_20 :b + 6.21 "Calculating viscosity"_howto_21 :ule,b "Example problems"_Section_example.html :l "Performance & scalability"_Section_perf.html :l "Additional tools"_Section_tools.html :l -"Modifying & Extending LAMMPS"_Section_modify.html :l +"Modifying & extending LAMMPS"_Section_modify.html :l + 10.1 "Atom styles"_mod_1 :ulb,b + 10.2 "Bond, angle, dihedral, improper potentials"_mod_2 :b + 10.3 "Compute styles"_mod_3 :b + 10.4 "Dump styles"_mod_4 :b + 10.5 "Dump custom output options"_mod_5 :b + 10.6 "Fix styles"_mod_6 :b + 10.7 "Input script commands"_mod_7 :b + 10.8 "Kspace computations"_mod_8 :b + 10.9 "Minimization styles"_mod_9 :b + 10.10 "Pairwise potentials"_mod_10 :b + 10.11 "Region styles"_mod_11 :b + 10.12 "Thermodynamic output options"_mod_12 :b + 10.13 "Variable options"_mod_13 :b + 10.14 "Submitting new features for inclusion in LAMMPS"_mod_14 :ule,b "Python interface"_Section_python.html :l - 9.1 "Extending Python with a serial version of LAMMPS"_9_1 :ulb,b - 9.2 "Creating a shared MPI library"_9_2 :b - 9.3 "Extending Python with a parallel version of LAMMPS"_9_3 :b - 9.4 "Extending Python with MPI"_9_4 :b - 9.5 "Testing the Python-LAMMPS interface"_9_5 :b - 9.6 "Using LAMMPS from Python"_9_6 :b - 9.7 "Example Python scripts that use LAMMPS"_9_7 :ule,b + 11.1 "Extending Python with a serial version of LAMMPS"_py_1 :ulb,b + 11.2 "Creating a shared MPI library"_py_2 :b + 11.3 "Extending Python with a parallel version of LAMMPS"_py_3 :b + 11.4 "Extending Python with MPI"_py_4 :b + 11.5 "Testing the Python-LAMMPS interface"_py_5 :b + 11.6 "Using LAMMPS from Python"_py_6 :b + 11.7 "Example Python scripts that use LAMMPS"_py_7 :ule,b "Errors"_Section_errors.html :l - 10.1 "Common problems"_10_1 :ulb,b - 10.2 "Reporting bugs"_10_2 :b - 10.3 "Error & warning messages"_10_3 :ule,b + 12.1 "Common problems"_err_1 :ulb,b + 12.2 "Reporting bugs"_err_2 :b + 12.3 "Error & warning messages"_err_3 :ule,b "Future and history"_Section_history.html :l - 11.1 "Coming attractions"_11_1 :ulb,b - 11.2 "Past versions"_11_2 :ule,b + 13.1 "Coming attractions"_hist_1 :ulb,b + 13.2 "Past versions"_hist_2 :ule,b :ole -:link(1_1,Section_intro.html#1_1) -:link(1_2,Section_intro.html#1_2) -:link(1_3,Section_intro.html#1_3) -:link(1_4,Section_intro.html#1_4) -:link(1_5,Section_intro.html#1_5) +:link(intro_1,Section_intro.html#intro_1) +:link(intro_2,Section_intro.html#intro_2) +:link(intro_3,Section_intro.html#intro_3) +:link(intro_4,Section_intro.html#intro_4) +:link(intro_5,Section_intro.html#intro_5) -:link(2_1,Section_start.html#2_1) -:link(2_2,Section_start.html#2_2) -:link(2_3,Section_start.html#2_3) -:link(2_4,Section_start.html#2_4) -:link(2_5,Section_start.html#2_5) -:link(2_6,Section_start.html#2_6) -:link(2_7,Section_start.html#2_7) -:link(2_8,Section_start.html#2_8) -:link(2_9,Section_start.html#2_9) +:link(start_1,Section_start.html#start_1) +:link(start_2,Section_start.html#start_2) +:link(start_3,Section_start.html#start_3) +:link(start_4,Section_start.html#start_4) +:link(start_5,Section_start.html#start_5) +:link(start_6,Section_start.html#start_6) +:link(start_7,Section_start.html#start_7) +:link(start_8,Section_start.html#start_8) -:link(3_1,Section_commands.html#3_1) -:link(3_2,Section_commands.html#3_2) -:link(3_3,Section_commands.html#3_3) -:link(3_4,Section_commands.html#3_4) -:link(3_5,Section_commands.html#3_5) +:link(cmd_1,Section_commands.html#cmd_1) +:link(cmd_2,Section_commands.html#cmd_2) +:link(cmd_3,Section_commands.html#cmd_3) +:link(cmd_4,Section_commands.html#cmd_4) +:link(cmd_5,Section_commands.html#cmd_5) -:link(4_1,Section_howto.html#4_1) -:link(4_2,Section_howto.html#4_2) -:link(4_3,Section_howto.html#4_3) -:link(4_4,Section_howto.html#4_4) -:link(4_5,Section_howto.html#4_5) -:link(4_6,Section_howto.html#4_6) -:link(4_7,Section_howto.html#4_7) -:link(4_8,Section_howto.html#4_8) -:link(4_9,Section_howto.html#4_9) -:link(4_10,Section_howto.html#4_10) -:link(4_11,Section_howto.html#4_11) -:link(4_12,Section_howto.html#4_12) -:link(4_13,Section_howto.html#4_13) -:link(4_14,Section_howto.html#4_14) -:link(4_15,Section_howto.html#4_15) -:link(4_16,Section_howto.html#4_16) -:link(4_17,Section_howto.html#4_17) -:link(4_18,Section_howto.html#4_18) -:link(4_19,Section_howto.html#4_19) -:link(4_20,Section_howto.html#4_20) -:link(4_21,Section_howto.html#4_21) +:link(pkg_1,Section_packages.html#pkg_1) +:link(pkg_2,Section_packages.html#pkg_2) -:link(9_1,Section_python.html#9_1) -:link(9_2,Section_python.html#9_2) -:link(9_3,Section_python.html#9_3) -:link(9_4,Section_python.html#9_4) -:link(9_5,Section_python.html#9_5) -:link(9_6,Section_python.html#9_6) -:link(9_7,Section_python.html#9_7) +:link(acc_1,Section_accelerate.html#acc_1) +:link(acc_2,Section_accelerate.html#acc_2) +:link(acc_3,Section_accelerate.html#acc_3) +:link(acc_4,Section_accelerate.html#acc_4) +:link(acc_5,Section_accelerate.html#acc_5) -:link(10_1,Section_errors.html#10_1) -:link(10_2,Section_errors.html#10_2) -:link(10_3,Section_errors.html#10_3) +:link(howto_1,Section_howto.html#howto_1) +:link(howto_2,Section_howto.html#howto_2) +:link(howto_3,Section_howto.html#howto_3) +:link(howto_4,Section_howto.html#howto_4) +:link(howto_5,Section_howto.html#howto_5) +:link(howto_6,Section_howto.html#howto_6) +:link(howto_7,Section_howto.html#howto_7) +:link(howto_8,Section_howto.html#howto_8) +:link(howto_9,Section_howto.html#howto_9) +:link(howto_10,Section_howto.html#howto_10) +:link(howto_11,Section_howto.html#howto_11) +:link(howto_12,Section_howto.html#howto_12) +:link(howto_13,Section_howto.html#howto_13) +:link(howto_14,Section_howto.html#howto_14) +:link(howto_15,Section_howto.html#howto_15) +:link(howto_16,Section_howto.html#howto_16) +:link(howto_17,Section_howto.html#howto_17) +:link(howto_18,Section_howto.html#howto_18) +:link(howto_19,Section_howto.html#howto_19) +:link(howto_20,Section_howto.html#howto_20) +:link(howto_21,Section_howto.html#howto_21) -:link(11_1,Section_history.html#11_1) -:link(11_2,Section_history.html#11_2) +:link(mod_1,Section_modify.html#mod_1) +:link(mod_2,Section_modify.html#mod_2) +:link(mod_3,Section_modify.html#mod_3) +:link(mod_4,Section_modify.html#mod_4) +:link(mod_5,Section_modify.html#mod_5) +:link(mod_6,Section_modify.html#mod_6) +:link(mod_7,Section_modify.html#mod_7) +:link(mod_8,Section_modify.html#mod_8) +:link(mod_9,Section_modify.html#mod_9) +:link(mod_10,Section_modify.html#mod_10) +:link(mod_11,Section_modify.html#mod_11) +:link(mod_12,Section_modify.html#mod_12) +:link(mod_13,Section_modify.html#mod_13) +:link(mod_14,Section_modify.html#mod_14) + +:link(py_1,Section_python.html#py_1) +:link(py_2,Section_python.html#py_2) +:link(py_3,Section_python.html#py_3) +:link(py_4,Section_python.html#py_4) +:link(py_5,Section_python.html#py_5) +:link(py_6,Section_python.html#py_6) +:link(py_7,Section_python.html#py_7) + +:link(err_1,Section_errors.html#err_1) +:link(err_2,Section_errors.html#err_2) +:link(err_3,Section_errors.html#err_3) + +:link(hist_1,Section_history.html#hist_1) +:link(hist_2,Section_history.html#hist_2) diff --git a/doc/Section_accelerate.html b/doc/Section_accelerate.html new file mode 100644 index 0000000000..838c1713df --- /dev/null +++ b/doc/Section_accelerate.html @@ -0,0 +1,654 @@ + +
    Previous Section - LAMMPS WWW Site - +LAMMPS Documentation - LAMMPS Commands - Next +Section +
    + + + + + + +
    + +

    5. Accelerating LAMMPS performance +

    +

    This section describes various methods for improving LAMMPS +performance for different classes of problems running +on different kinds of machines. +

    +5.1 OPT package
    +5.2 USER-OMP package
    +5.3 GPU package
    +5.4 USER-CUDA package
    +5.5 Comparison of GPU and USER-CUDA packages
    + +

    Accelerated versions of various pair_style, +fixes, computes, and other commands have +been added to LAMMPS, which will typically run faster than the +standard non-accelerated versions, if you have the appropriate +hardware on your system. +

    +

    The accelerated styles have the same name as the standard styles, +except that a suffix is appended. Otherwise, the syntax for the +command is identical, their functionality is the same, and the +numerical results it produces should also be identical, except for +precision and round-off issues. +

    +

    For example, all of these variants of the basic Lennard-Jones pair +style exist in LAMMPS: +

    + +

    Assuming you have built LAMMPS with the appropriate package, these +styles can be invoked by specifying them explicitly in your input +script. Or you can use the -suffix command-line +switch to invoke the accelerated versions +automatically, without changing your input script. The +suffix command allows you to set a suffix explicitly and +to turn off/on the comand-line switch setting, both from within your +input script. +

    +

    Styles with an "opt" suffix are part of the OPT package and typically +speed-up the pairwise calculations of your simulation by 5-25%. +

    +

    Styles with an "omp" suffix are part of the USER-OMP package and allow +a pair-style to be run in multi-threaded mode using OpenMP. This can +be useful on nodes with high-core counts when using less MPI processes +than cores is advantageous, e.g. when running with PPPM so that FFTs +are run on fewer MPI processors or when the many MPI tasks would +overload the available bandwidth for communication. +

    +

    Styles with a "gpu" or "cuda" suffix are part of the GPU or USER-CUDA +packages, and can be run on NVIDIA GPUs associated with your CPUs. +The speed-up due to GPU usage depends on a variety of factors, as +discussed below. +

    +

    To see what styles are currently available in each of the accelerated +packages, see this section of the +manual. A list of accelerated styles is included in the pair, fix, +compute, and kspace sections. +

    +

    The following sections explain: +

    + +

    The final section compares and contrasts the GPU and USER-CUDA +packages, since they are both designed to use NVIDIA GPU hardware. +

    +
    + +
    + +

    5.1 OPT package +

    +

    The OPT package was developed by James Fischer (High Performance +Technologies), David Richie, and Vincent Natoli (Stone Ridge +Technologies). It contains a handful of pair styles whose compute() +methods were rewritten in C++ templated form to reduce the overhead +due to if tests and other conditional code. +

    +

    The procedure for building LAMMPS with the OPT package is simple. It +is the same as for any other package which has no additional library +dependencies: +

    +
    make yes-opt
+make machine 
+
    +

    If your input script uses one of the OPT pair styles, +you can run it as follows: +

    +
    lmp_machine -sf opt < in.script
+mpirun -np 4 lmp_machine -sf opt < in.script 
+
    +

    You should see a reduction in the "Pair time" printed out at the end +of the run. On most machines and problems, this will typically be a 5 +to 20% savings. +

    +
    + +
    + +

    5.2 USER-OMP package +

    +

    The USER-OMP package was developed by Axel Kohlmeyer at Temple University. +It provides multi-threaded versions of most pair styles, all dihedral +styles and a few fixes in LAMMPS. The package currently uses the OpenMP +interface which requires using a specific compiler flag in the makefile +to enable multiple threads; without this flag the corresponding pair +styles will still be compiled and work, but do not support multi-threading. +

    +

    Building LAMMPS with the USER-OMP package: +

    +

    The procedure for building LAMMPS with the USER-OMP package is simple. +You have to edit your machine specific makefile to add the flag to +enable OpenMP support to the CCFLAGS and LINKFLAGS variables. For the +GNU compilers for example this flag is called -fopenmp. Check your +compiler documentation to find out which flag you need to add. +The rest of the compilation is the same as for any other package which +has no additional library dependencies: +

    +
    make yes-user-omp
+make machine 
+
    +

    Please note that this will only install accelerated versions +of styles that are already installed, so you want to install +this package as the last package, or else you may be missing +some accelerated styles. If you plan to uninstall some package, +you should first uninstall the USER-OMP package then the other +package and then re-install USER-OMP, to make sure that there +are no orphaned omp style files present, which would lead to +compilation errors. +

    +

    If your input script uses one of regular styles that are also +exist as an OpenMP version in the USER-OMP package you can run +it as follows: +

    +
    env OMP_NUM_THREADS=4 lmp_serial -sf omp -in in.script
+env OMP_NUM_THREADS=2 mpirun -np 2 lmp_machine -sf omp -in in.script
+mpirun -x OMP_NUM_THREADS=2 -np 2 lmp_machine -sf omp -in in.script 
+
    +

    The value of the environment variable OMP_NUM_THREADS determines how +many threads per MPI task are launched. All three examples above use +a total of 4 CPU cores. For different MPI implementations the method +to pass the OMP_NUM_THREADS environment variable to all processes is +different. Two different variants, one for MPICH and OpenMPI, respectively +are shown above. Please check the documentation of your MPI installation +for additional details. Alternatively, the value provided by OMP_NUM_THREADS +can be overridded with the package omp command. +Depending on which styles are accelerated in your input, you should +see a reduction in the "Pair time" and/or "Bond time" and "Loop time" +printed out at the end of the run. The optimal ratio of MPI to OpenMP +can vary a lot and should always be confirmed through some benchmark +runs for the current system and on the current machine. +

    +

    Restrictions: +

    +

    None of the pair styles in the USER-OMP package support the "inner", +"middle", "outer" options for r-RESPA integration, only the "pair" +option is supported. +

    +

    Parallel efficiency and performance tips: +

    +

    In most simple cases the MPI parallelization in LAMMPS is more +efficient than multi-threading implemented in the USER-OMP package. +Also the parallel efficiency varies between individual styles. +On the other hand, in many cases you still want to use the omp version +- even when compiling or running without OpenMP support - since they +all contain optimizations similar to those in the OPT package, which +can result in serial speedup. +

    +

    Using multi-threading is most effective under the following circumstances: +

    + +

    The best parallel efficiency from omp styles is typically +achieved when there is at least one MPI task per physical +processor, i.e. socket or die. +

    +

    Using threads on hyper-threading enabled cores is usually +counterproductive, as the cost in additional memory bandwidth +requirements is not offset by the gain in CPU utilization +through hyper-threading. +

    +

    A description of the multi-threading strategy and some performance +examples are presented here +

    +
    + +
    + +

    5.3 GPU package +

    +

    The GPU package was developed by Mike Brown at ORNL. It provides GPU +versions of several pair styles and for long-range Coulombics via the +PPPM command. It has the following features: +

    + +

    Hardware and software requirements: +

    +

    To use this package, you currently need to have specific NVIDIA +hardware and install specific NVIDIA CUDA software on your system: +

    + +

    Building LAMMPS with the GPU package: +

    +

    As with other packages that include a separately compiled library, you +need to first build the GPU library, before building LAMMPS itself. +General instructions for doing this are in this +section of the manual. For this +package, do the following, using a Makefile in lib/gpu appropriate for +your system: +

    +
    cd lammps/lib/gpu
+make -f Makefile.linux
+(see further instructions in lammps/lib/gpu/README) 
+
    +

    If you are successful, you will produce the file lib/libgpu.a. +

    +

    Now you are ready to build LAMMPS with the GPU package installed: +

    +
    cd lammps/src
+make yes-gpu
+make machine 
+
    +

    Note that the lo-level Makefile (e.g. src/MAKE/Makefile.linux) has +these settings: gpu_SYSINC, gpu_SYSLIB, gpu_SYSPATH. These need to be +set appropriately to include the paths and settings for the CUDA +system software on your machine. See src/MAKE/Makefile.g++ for an +example. +

    +

    GPU configuration +

    +

    When using GPUs, you are restricted to one physical GPU per LAMMPS +process, which is an MPI process running on a single core or +processor. Multiple MPI processes (CPU cores) can share a single GPU, +and in many cases it will be more efficient to run this way. +

    +

    Input script requirements: +

    +

    Additional input script requirements to run pair or PPPM styles with a +gpu suffix are as follows: +

    + +

    As an example, if you have two GPUs per node and 8 CPU cores per node, +and would like to run on 4 nodes (32 cores) with dynamic balancing of +force calculation across CPU and GPU cores, you could specify +

    +
    package gpu force/neigh 0 1 -1 
+
    +

    In this case, all CPU cores and GPU devices on the nodes would be +utilized. Each GPU device would be shared by 4 CPU cores. The CPU +cores would perform force calculations for some fraction of the +particles at the same time the GPUs performed force calculation for +the other particles. +

    +

    Timing output: +

    +

    As described by the package gpu command, GPU +accelerated pair styles can perform computations asynchronously with +CPU computations. The "Pair" time reported by LAMMPS will be the +maximum of the time required to complete the CPU pair style +computations and the time required to complete the GPU pair style +computations. Any time spent for GPU-enabled pair styles for +computations that run simultaneously with bond, +angle, dihedral, +improper, and long-range +calculations will not be included in the "Pair" time. +

    +

    When the mode setting for the package gpu command is force/neigh, +the time for neighbor list calculations on the GPU will be added into +the "Pair" time, not the "Neigh" time. An additional breakdown of the +times required for various tasks on the GPU (data copy, neighbor +calculations, force computations, etc) are output only with the LAMMPS +screen output (not in the log file) at the end of each run. These +timings represent total time spent on the GPU for each routine, +regardless of asynchronous CPU calculations. +

    +

    Performance tips: +

    +

    Generally speaking, for best performance, you should use multiple CPUs +per GPU, as provided my most multi-core CPU/GPU configurations. +

    +

    Because of the large number of cores within each GPU device, it may be +more efficient to run on fewer processes per GPU when the number of +particles per MPI process is small (100's of particles); this can be +necessary to keep the GPU cores busy. +

    +

    See the lammps/lib/gpu/README file for instructions on how to build +the GPU library for single, mixed, or double precision. The latter +requires that your GPU card support double precision. +

    +
    + +
    + +

    5.4 USER-CUDA package +

    +

    The USER-CUDA package was developed by Christian Trott at U Technology +Ilmenau in Germany. It provides NVIDIA GPU versions of many pair +styles, many fixes, a few computes, and for long-range Coulombics via +the PPPM command. It has the following features: +

    + +

    Hardware and software requirements: +

    +

    To use this package, you need to have specific NVIDIA hardware and +install specific NVIDIA CUDA software on your system. +

    +

    Your NVIDIA GPU needs to support Compute Capability 1.3. This list may +help you to find out the Compute Capability of your card: +

    +

    http://en.wikipedia.org/wiki/Comparison_of_Nvidia_graphics_processing_units +

    +

    Install the Nvidia Cuda Toolkit in version 3.2 or higher and the +corresponding GPU drivers. The Nvidia Cuda SDK is not required for +LAMMPSCUDA but we recommend it be installed. You can then make sure +that its sample projects can be compiled without problems. +

    +

    Building LAMMPS with the USER-CUDA package: +

    +

    As with other packages that include a separately compiled library, you +need to first build the USER-CUDA library, before building LAMMPS +itself. General instructions for doing this are in this +section of the manual. For this +package, do the following, using settings in the lib/cuda Makefiles +appropriate for your system: +

    + +

    Now you are ready to build LAMMPS with the USER-CUDA package installed: +

    +
    cd lammps/src
+make yes-user-cuda
+make machine 
+
    +

    Note that the LAMMPS build references the lib/cuda/Makefile.common +file to extract setting specific CUDA settings. So it is important +that you have first built the cuda library (in lib/cuda) using +settings appropriate to your system. +

    +

    Input script requirements: +

    +

    Additional input script requirements to run styles with a cuda +suffix are as follows: +

    + +

    Performance tips: +

    +

    The USER-CUDA package offers more speed-up relative to CPU performance +when the number of atoms per GPU is large, e.g. on the order of tens +or hundreds of 1000s. +

    +

    As noted above, this package will continue to run a simulation +entirely on the GPU(s) (except for inter-processor MPI communication), +for multiple timesteps, until a CPU calculation is required, either by +a fix or compute that is non-GPU-ized, or until output is performed +(thermo or dump snapshot or restart file). The less often this +occurs, the faster your simulation will run. +

    +
    + +
    + +

    5.5 Comparison of GPU and USER-CUDA packages +

    +

    Both the GPU and USER-CUDA packages accelerate a LAMMPS calculation +using NVIDIA hardware, but they do it in different ways. +

    +

    As a consequence, for a particular simulation on specific hardware, +one package may be faster than the other. We give guidelines below, +but the best way to determine which package is faster for your input +script is to try both of them on your machine. See the benchmarking +section below for examples where this has been done. +

    +

    Guidelines for using each package optimally: +

    + +

    Differences between the two packages: +

    + +

    Examples: +

    +

    The LAMMPS distribution has two directories with sample input scripts +for the GPU and USER-CUDA packages. +

    + +

    These contain input scripts for identical systems, so they can be used +to benchmark the performance of both packages on your system. +

    +
    + +

    Benchmark data: +

    +

    NOTE: We plan to add some benchmark results and plots here for the +examples described in the previous section. +

    +

    Simulations: +

    +

    1. Lennard Jones +

    + +

    2. Lennard Jones +

    + +

    3. Rhodopsin model +

    + +

    4. Lihtium-Phosphate +

    + +

    Hardware: +

    +

    Workstation: +

    + +

    eStella: +

    + +

    Keeneland: +

    + + diff --git a/doc/Section_accelerate.txt b/doc/Section_accelerate.txt new file mode 100644 index 0000000000..081e6279dd --- /dev/null +++ b/doc/Section_accelerate.txt @@ -0,0 +1,644 @@ +"Previous Section"_Section_packages.html - "LAMMPS WWW Site"_lws - +"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next +Section"_Section_howto.html :c + +:link(lws,http://lammps.sandia.gov) +:link(ld,Manual.html) +:link(lc,Section_commands.html#comm) + +:line + +5. Accelerating LAMMPS performance :h3 + +This section describes various methods for improving LAMMPS +performance for different classes of problems running +on different kinds of machines. + +5.1 "OPT package"_#acc_1 +5.2 "USER-OMP package"_#acc_2 +5.3 "GPU package"_#acc_3 +5.4 "USER-CUDA package"_#acc_4 +5.5 "Comparison of GPU and USER-CUDA packages"_#acc_5 :all(b) + +Accelerated versions of various "pair_style"_pair_style.html, +"fixes"_fix.html, "computes"_compute.html, and other commands have +been added to LAMMPS, which will typically run faster than the +standard non-accelerated versions, if you have the appropriate +hardware on your system. + +The accelerated styles have the same name as the standard styles, +except that a suffix is appended. Otherwise, the syntax for the +command is identical, their functionality is the same, and the +numerical results it produces should also be identical, except for +precision and round-off issues. + +For example, all of these variants of the basic Lennard-Jones pair +style exist in LAMMPS: + +"pair_style lj/cut"_pair_lj.html +"pair_style lj/cut/opt"_pair_lj.html +"pair_style lj/cut/omp"_pair_lj.html +"pair_style lj/cut/gpu"_pair_lj.html +"pair_style lj/cut/cuda"_pair_lj.html :ul + +Assuming you have built LAMMPS with the appropriate package, these +styles can be invoked by specifying them explicitly in your input +script. Or you can use the "-suffix command-line +switch"_Section_start.html#start_6 to invoke the accelerated versions +automatically, without changing your input script. The +"suffix"_suffix.html command allows you to set a suffix explicitly and +to turn off/on the comand-line switch setting, both from within your +input script. + +Styles with an "opt" suffix are part of the OPT package and typically +speed-up the pairwise calculations of your simulation by 5-25%. + +Styles with an "omp" suffix are part of the USER-OMP package and allow +a pair-style to be run in multi-threaded mode using OpenMP. This can +be useful on nodes with high-core counts when using less MPI processes +than cores is advantageous, e.g. when running with PPPM so that FFTs +are run on fewer MPI processors or when the many MPI tasks would +overload the available bandwidth for communication. + +Styles with a "gpu" or "cuda" suffix are part of the GPU or USER-CUDA +packages, and can be run on NVIDIA GPUs associated with your CPUs. +The speed-up due to GPU usage depends on a variety of factors, as +discussed below. + +To see what styles are currently available in each of the accelerated +packages, see "this section"_Section_commands.html#cmd_5 of the +manual. A list of accelerated styles is included in the pair, fix, +compute, and kspace sections. + +The following sections explain: + +what hardware and software the accelerated styles require +how to build LAMMPS with the accelerated packages in place +what changes (if any) are needed in your input scripts +guidelines for best performance +speed-ups you can expect :ul + +The final section compares and contrasts the GPU and USER-CUDA +packages, since they are both designed to use NVIDIA GPU hardware. + +:line +:line + +5.1 OPT package :h4,link(acc_1) + +The OPT package was developed by James Fischer (High Performance +Technologies), David Richie, and Vincent Natoli (Stone Ridge +Technologies). It contains a handful of pair styles whose compute() +methods were rewritten in C++ templated form to reduce the overhead +due to if tests and other conditional code. + +The procedure for building LAMMPS with the OPT package is simple. It +is the same as for any other package which has no additional library +dependencies: + +make yes-opt +make machine :pre + +If your input script uses one of the OPT pair styles, +you can run it as follows: + +lmp_machine -sf opt < in.script +mpirun -np 4 lmp_machine -sf opt < in.script :pre + +You should see a reduction in the "Pair time" printed out at the end +of the run. On most machines and problems, this will typically be a 5 +to 20% savings. + +:line +:line + +5.2 USER-OMP package :h4,link(acc_2) + +The USER-OMP package was developed by Axel Kohlmeyer at Temple University. +It provides multi-threaded versions of most pair styles, all dihedral +styles and a few fixes in LAMMPS. The package currently uses the OpenMP +interface which requires using a specific compiler flag in the makefile +to enable multiple threads; without this flag the corresponding pair +styles will still be compiled and work, but do not support multi-threading. + +[Building LAMMPS with the USER-OMP package:] + +The procedure for building LAMMPS with the USER-OMP package is simple. +You have to edit your machine specific makefile to add the flag to +enable OpenMP support to the CCFLAGS and LINKFLAGS variables. For the +GNU compilers for example this flag is called {-fopenmp}. Check your +compiler documentation to find out which flag you need to add. +The rest of the compilation is the same as for any other package which +has no additional library dependencies: + +make yes-user-omp +make machine :pre + +Please note that this will only install accelerated versions +of styles that are already installed, so you want to install +this package as the last package, or else you may be missing +some accelerated styles. If you plan to uninstall some package, +you should first uninstall the USER-OMP package then the other +package and then re-install USER-OMP, to make sure that there +are no orphaned {omp} style files present, which would lead to +compilation errors. + +If your input script uses one of regular styles that are also +exist as an OpenMP version in the USER-OMP package you can run +it as follows: + +env OMP_NUM_THREADS=4 lmp_serial -sf omp -in in.script +env OMP_NUM_THREADS=2 mpirun -np 2 lmp_machine -sf omp -in in.script +mpirun -x OMP_NUM_THREADS=2 -np 2 lmp_machine -sf omp -in in.script :pre + +The value of the environment variable OMP_NUM_THREADS determines how +many threads per MPI task are launched. All three examples above use +a total of 4 CPU cores. For different MPI implementations the method +to pass the OMP_NUM_THREADS environment variable to all processes is +different. Two different variants, one for MPICH and OpenMPI, respectively +are shown above. Please check the documentation of your MPI installation +for additional details. Alternatively, the value provided by OMP_NUM_THREADS +can be overridded with the "package omp"_package.html command. +Depending on which styles are accelerated in your input, you should +see a reduction in the "Pair time" and/or "Bond time" and "Loop time" +printed out at the end of the run. The optimal ratio of MPI to OpenMP +can vary a lot and should always be confirmed through some benchmark +runs for the current system and on the current machine. + +[Restrictions:] + +None of the pair styles in the USER-OMP package support the "inner", +"middle", "outer" options for r-RESPA integration, only the "pair" +option is supported. + +[Parallel efficiency and performance tips:] + +In most simple cases the MPI parallelization in LAMMPS is more +efficient than multi-threading implemented in the USER-OMP package. +Also the parallel efficiency varies between individual styles. +On the other hand, in many cases you still want to use the {omp} version +- even when compiling or running without OpenMP support - since they +all contain optimizations similar to those in the OPT package, which +can result in serial speedup. + +Using multi-threading is most effective under the following circumstances: + +Individual compute nodes have a significant number of CPU cores +but the CPU itself has limited memory bandwidth, e.g. Intel Xeon 53xx +(Clovertown) and 54xx (Harpertown) quad core processors. Running +one MPI task per CPU core will result in significant performance +degradation, so that running with 4 or even only 2 MPI tasks per +nodes is faster. Running in hybrid MPI+OpenMP mode will reduce the +inter-node communication bandwidth contention in the same way, +but offers and additional speedup from utilizing the otherwise +idle CPU cores. :ulb,l + +The interconnect used for MPI communication is not able to provide +sufficient bandwidth for a large number of MPI tasks per node. +This applies for example to running over gigabit ethernet or +on Cray XT4 or XT5 series supercomputers. Same as in the aforementioned +case this effect worsens with using an increasing number of nodes. :l + +The input is a system that has an inhomogeneous particle density +which cannot be mapped well to the domain decomposition scheme +that LAMMPS employs. While this can be to some degree alleviated +through using the "processors"_processors.html keyword, multi-threading +provides a parallelism that parallelizes over the number of particles +not their distribution in space. :l + +Finally, multi-threaded styles can improve performance when running +LAMMPS in "capability mode", i.e. near the point where the MPI +parallelism scales out. This can happen in particular when using +as kspace style for long-range electrostatics. Here the scaling +of the kspace style is the performance limiting factor and using +multi-threaded styles allows to operate the kspace style at the +limit of scaling and then increase performance parallelizing +the real space calculations with hybrid MPI+OpenMP. Sometimes +additional speedup can be achived by increasing the real-space +coulomb cutoff and thus reducing the work in the kspace part. :l,ule + +The best parallel efficiency from {omp} styles is typically +achieved when there is at least one MPI task per physical +processor, i.e. socket or die. + +Using threads on hyper-threading enabled cores is usually +counterproductive, as the cost in additional memory bandwidth +requirements is not offset by the gain in CPU utilization +through hyper-threading. + +A description of the multi-threading strategy and some performance +examples are "presented here"_http://sites.google.com/site/akohlmey/software/lammps-icms/lammps-icms-tms2011-talk.pdf?attredirects=0&d=1 + +:line +:line + +5.3 GPU package :h4,link(acc_3) + +The GPU package was developed by Mike Brown at ORNL. It provides GPU +versions of several pair styles and for long-range Coulombics via the +PPPM command. It has the following features: + +The package is designed to exploit common GPU hardware configurations +where one or more GPUs are coupled with many cores of a multi-core +CPUs, e.g. within a node of a parallel machine. :ulb,l + +Atom-based data (e.g. coordinates, forces) moves back-and-forth +between the CPU(s) and GPU every timestep. :l + +Neighbor lists can be constructed on the CPU or on the GPU :l + +The charge assignement and force interpolation portions of PPPM can be +run on the GPU. The FFT portion, which requires MPI communication +between processors, runs on the CPU. :l + +Asynchronous force computations can be performed simultaneously on the +CPU(s) and GPU. :l + +LAMMPS-specific code is in the GPU package. It makes calls to a +generic GPU library in the lib/gpu directory. This library provides +NVIDIA support as well as more general OpenCL support, so that the +same functionality can eventually be supported on a variety of GPU +hardware. :l,ule + +[Hardware and software requirements:] + +To use this package, you currently need to have specific NVIDIA +hardware and install specific NVIDIA CUDA software on your system: + +Check if you have an NVIDIA card: cat /proc/driver/nvidia/cards/0 +Go to http://www.nvidia.com/object/cuda_get.html +Install a driver and toolkit appropriate for your system (SDK is not necessary) +Follow the instructions in lammps/lib/gpu/README to build the library (see below) +Run lammps/lib/gpu/nvc_get_devices to list supported devices and properties :ul + +[Building LAMMPS with the GPU package:] + +As with other packages that include a separately compiled library, you +need to first build the GPU library, before building LAMMPS itself. +General instructions for doing this are in "this +section"_doc/Section_start.html#start_3 of the manual. For this +package, do the following, using a Makefile in lib/gpu appropriate for +your system: + +cd lammps/lib/gpu +make -f Makefile.linux +(see further instructions in lammps/lib/gpu/README) :pre + +If you are successful, you will produce the file lib/libgpu.a. + +Now you are ready to build LAMMPS with the GPU package installed: + +cd lammps/src +make yes-gpu +make machine :pre + +Note that the lo-level Makefile (e.g. src/MAKE/Makefile.linux) has +these settings: gpu_SYSINC, gpu_SYSLIB, gpu_SYSPATH. These need to be +set appropriately to include the paths and settings for the CUDA +system software on your machine. See src/MAKE/Makefile.g++ for an +example. + +[GPU configuration] + +When using GPUs, you are restricted to one physical GPU per LAMMPS +process, which is an MPI process running on a single core or +processor. Multiple MPI processes (CPU cores) can share a single GPU, +and in many cases it will be more efficient to run this way. + +[Input script requirements:] + +Additional input script requirements to run pair or PPPM styles with a +{gpu} suffix are as follows: + +To invoke specific styles from the GPU package, you can either append +"gpu" to the style name (e.g. pair_style lj/cut/gpu), or use the +"-suffix command-line switch"_Section_start.html#start_6, or use the +"suffix"_suffix.html command. :ulb,l + +The "newton pair"_newton.html setting must be {off}. :l + +The "package gpu"_package.html command must be used near the beginning +of your script to control the GPU selection and initialization +settings. It also has an option to enable asynchronous splitting of +force computations between the CPUs and GPUs. :l,ule + +As an example, if you have two GPUs per node and 8 CPU cores per node, +and would like to run on 4 nodes (32 cores) with dynamic balancing of +force calculation across CPU and GPU cores, you could specify + +package gpu force/neigh 0 1 -1 :pre + +In this case, all CPU cores and GPU devices on the nodes would be +utilized. Each GPU device would be shared by 4 CPU cores. The CPU +cores would perform force calculations for some fraction of the +particles at the same time the GPUs performed force calculation for +the other particles. + +[Timing output:] + +As described by the "package gpu"_package.html command, GPU +accelerated pair styles can perform computations asynchronously with +CPU computations. The "Pair" time reported by LAMMPS will be the +maximum of the time required to complete the CPU pair style +computations and the time required to complete the GPU pair style +computations. Any time spent for GPU-enabled pair styles for +computations that run simultaneously with "bond"_bond_style.html, +"angle"_angle_style.html, "dihedral"_dihedral_style.html, +"improper"_improper_style.html, and "long-range"_kspace_style.html +calculations will not be included in the "Pair" time. + +When the {mode} setting for the package gpu command is force/neigh, +the time for neighbor list calculations on the GPU will be added into +the "Pair" time, not the "Neigh" time. An additional breakdown of the +times required for various tasks on the GPU (data copy, neighbor +calculations, force computations, etc) are output only with the LAMMPS +screen output (not in the log file) at the end of each run. These +timings represent total time spent on the GPU for each routine, +regardless of asynchronous CPU calculations. + +[Performance tips:] + +Generally speaking, for best performance, you should use multiple CPUs +per GPU, as provided my most multi-core CPU/GPU configurations. + +Because of the large number of cores within each GPU device, it may be +more efficient to run on fewer processes per GPU when the number of +particles per MPI process is small (100's of particles); this can be +necessary to keep the GPU cores busy. + +See the lammps/lib/gpu/README file for instructions on how to build +the GPU library for single, mixed, or double precision. The latter +requires that your GPU card support double precision. + +:line +:line + +5.4 USER-CUDA package :h4,link(acc_4) + +The USER-CUDA package was developed by Christian Trott at U Technology +Ilmenau in Germany. It provides NVIDIA GPU versions of many pair +styles, many fixes, a few computes, and for long-range Coulombics via +the PPPM command. It has the following features: + +The package is designed to allow an entire LAMMPS calculation, for +many timesteps, to run entirely on the GPU (except for inter-processor +MPI communication), so that atom-based data (e.g. coordinates, forces) +do not have to move back-and-forth between the CPU and GPU. :ulb,l + +The speed-up advantage of this approach is typically better when the +number of atoms per GPU is large :l + +Data will stay on the GPU until a timestep where a non-GPU-ized fix or +compute is invoked. Whenever a non-GPU operation occurs (fix, +compute, output), data automatically moves back to the CPU as needed. +This may incur a performance penalty, but should otherwise work +transparently. :l + +Neighbor lists for GPU-ized pair styles are constructed on the +GPU. :l + +The package only supports use of a single CPU (core) with each +GPU. :l,ule + +[Hardware and software requirements:] + +To use this package, you need to have specific NVIDIA hardware and +install specific NVIDIA CUDA software on your system. + +Your NVIDIA GPU needs to support Compute Capability 1.3. This list may +help you to find out the Compute Capability of your card: + +http://en.wikipedia.org/wiki/Comparison_of_Nvidia_graphics_processing_units + +Install the Nvidia Cuda Toolkit in version 3.2 or higher and the +corresponding GPU drivers. The Nvidia Cuda SDK is not required for +LAMMPSCUDA but we recommend it be installed. You can then make sure +that its sample projects can be compiled without problems. + +[Building LAMMPS with the USER-CUDA package:] + +As with other packages that include a separately compiled library, you +need to first build the USER-CUDA library, before building LAMMPS +itself. General instructions for doing this are in "this +section"_doc/Section_start.html#start_3 of the manual. For this +package, do the following, using settings in the lib/cuda Makefiles +appropriate for your system: + +Go to the lammps/lib/cuda directory :ulb,l + +If your {CUDA} toolkit is not installed in the default system directoy +{/usr/local/cuda} edit the file {lib/cuda/Makefile.common} +accordingly. :l + +Type "make OPTIONS", where {OPTIONS} are one or more of the following +options. The settings will be written to the +{lib/cuda/Makefile.defaults} and used in the next step. :l + +{precision=N} to set the precision level + N = 1 for single precision (default) + N = 2 for double precision + N = 3 for positions in double precision + N = 4 for positions and velocities in double precision +{arch=M} to set GPU compute capability + M = 20 for CC2.0 (GF100/110, e.g. C2050,GTX580,GTX470) (default) + M = 21 for CC2.1 (GF104/114, e.g. GTX560, GTX460, GTX450) + M = 13 for CC1.3 (GF200, e.g. C1060, GTX285) +{prec_timer=0/1} to use hi-precision timers + 0 = do not use them (default) + 1 = use these timers + this is usually only useful for Mac machines +{dbg=0/1} to activate debug mode + 0 = no debug mode (default) + 1 = yes debug mode + this is only useful for developers +{cufft=1} to determine usage of CUDA FFT library + 0 = no CUFFT support (default) + in the future other CUDA-enabled FFT libraries might be supported :pre + +Type "make" to build the library. If you are successful, you will +produce the file lib/libcuda.a. :l,ule + +Now you are ready to build LAMMPS with the USER-CUDA package installed: + +cd lammps/src +make yes-user-cuda +make machine :pre + +Note that the LAMMPS build references the lib/cuda/Makefile.common +file to extract setting specific CUDA settings. So it is important +that you have first built the cuda library (in lib/cuda) using +settings appropriate to your system. + +[Input script requirements:] + +Additional input script requirements to run styles with a {cuda} +suffix are as follows: + +To invoke specific styles from the USER-CUDA package, you can either +append "cuda" to the style name (e.g. pair_style lj/cut/cuda), or use +the "-suffix command-line switch"_Section_start.html#start_6, or use +the "suffix"_suffix.html command. One exception is that the +"kspace_style pppm/cuda"_kspace_style.html command has to be requested +explicitly. :ulb,l + +To use the USER-CUDA package with its default settings, no additional +command is needed in your input script. This is because when LAMMPS +starts up, it detects if it has been built with the USER-CUDA package. +See the "-cuda command-line switch"_Section_start.html#start_6 for +more details. :l + +To change settings for the USER-CUDA package at run-time, the "package +cuda"_package.html command can be used near the beginning of your +input script. See the "package"_package.html command doc page for +details. :l,ule + +[Performance tips:] + +The USER-CUDA package offers more speed-up relative to CPU performance +when the number of atoms per GPU is large, e.g. on the order of tens +or hundreds of 1000s. + +As noted above, this package will continue to run a simulation +entirely on the GPU(s) (except for inter-processor MPI communication), +for multiple timesteps, until a CPU calculation is required, either by +a fix or compute that is non-GPU-ized, or until output is performed +(thermo or dump snapshot or restart file). The less often this +occurs, the faster your simulation will run. + +:line +:line + +5.5 Comparison of GPU and USER-CUDA packages :h4,link(acc_5) + +Both the GPU and USER-CUDA packages accelerate a LAMMPS calculation +using NVIDIA hardware, but they do it in different ways. + +As a consequence, for a particular simulation on specific hardware, +one package may be faster than the other. We give guidelines below, +but the best way to determine which package is faster for your input +script is to try both of them on your machine. See the benchmarking +section below for examples where this has been done. + +[Guidelines for using each package optimally:] + +The GPU package allows you to assign multiple CPUs (cores) to a single +GPU (a common configuration for "hybrid" nodes that contain multicore +CPU(s) and GPU(s)) and works effectively in this mode. The USER-CUDA +package does not allow this; you can only use one CPU per GPU. :ulb,l + +The GPU package moves per-atom data (coordinates, forces) +back-and-forth between the CPU and GPU every timestep. The USER-CUDA +package only does this on timesteps when a CPU calculation is required +(e.g. to invoke a fix or compute that is non-GPU-ized). Hence, if you +can formulate your input script to only use GPU-ized fixes and +computes, and avoid doing I/O too often (thermo output, dump file +snapshots, restart files), then the data transfer cost of the +USER-CUDA package can be very low, causing it to run faster than the +GPU package. :l + +The GPU package is often faster than the USER-CUDA package, if the +number of atoms per GPU is "small". The crossover point, in terms of +atoms/GPU at which the USER-CUDA package becomes faster depends +strongly on the pair style. For example, for a simple Lennard Jones +system the crossover (in single precision) is often about 50K-100K +atoms per GPU. When performing double precision calculations the +crossover point can be significantly smaller. :l + +Both packages compute bonded interactions (bonds, angles, etc) on the +CPU. This means a model with bonds will force the USER-CUDA package +to transfer per-atom data back-and-forth between the CPU and GPU every +timestep. If the GPU package is running with several MPI processes +assigned to one GPU, the cost of computing the bonded interactions is +spread across more CPUs and hence the GPU package can run faster. :l + +When using the GPU package with multiple CPUs assigned to one GPU, its +performance depends to some extent on high bandwidth between the CPUs +and the GPU. Hence its performance is affected if full 16 PCIe lanes +are not available for each GPU. In HPC environments this can be the +case if S2050/70 servers are used, where two devices generally share +one PCIe 2.0 16x slot. Also many multi-GPU mainboards do not provide +full 16 lanes to each of the PCIe 2.0 16x slots. :l,ule + +[Differences between the two packages:] + +The GPU package accelerates only pair force, neighbor list, and PPPM +calculations. The USER-CUDA package currently supports a wider range +of pair styles and can also accelerate many fix styles and some +compute styles, as well as neighbor list and PPPM calculations. :ulb,l + +The GPU package uses more GPU memory than the USER-CUDA package. This +is generally not a problem since typical runs are computation-limited +rather than memory-limited. :l,ule + +[Examples:] + +The LAMMPS distribution has two directories with sample input scripts +for the GPU and USER-CUDA packages. + +lammps/examples/gpu = GPU package files +lammps/examples/USER/cuda = USER-CUDA package files :ul + +These contain input scripts for identical systems, so they can be used +to benchmark the performance of both packages on your system. + +:line + +[Benchmark data:] + +NOTE: We plan to add some benchmark results and plots here for the +examples described in the previous section. + +Simulations: + +1. Lennard Jones + +256,000 atoms +2.5 A cutoff +0.844 density :ul + +2. Lennard Jones + +256,000 atoms +5.0 A cutoff +0.844 density :ul + +3. Rhodopsin model + +256,000 atoms +10A cutoff +Coulomb via PPPM :ul + +4. Lihtium-Phosphate + +295650 atoms +15A cutoff +Coulomb via PPPM :ul + +Hardware: + +Workstation: + +2x GTX470 +i7 950@3GHz +24Gb DDR3 @ 1066Mhz +CentOS 5.5 +CUDA 3.2 +Driver 260.19.12 :ul + +eStella: + +6 Nodes +2xC2050 +2xQDR Infiniband interconnect(aggregate bandwidth 80GBps) +Intel X5650 HexCore @ 2.67GHz +SL 5.5 +CUDA 3.2 +Driver 260.19.26 :ul + +Keeneland: + +HP SL-390 (Ariston) cluster +120 nodes +2x Intel Westmere hex-core CPUs +3xC2070s +QDR InfiniBand interconnect :ul diff --git a/doc/Section_commands.html b/doc/Section_commands.html index 16fb2f9efe..3596074035 100644 --- a/doc/Section_commands.html +++ b/doc/Section_commands.html @@ -1,5 +1,5 @@ -
    Previous Section - LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands - Next Section +
    Previous Section - LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands - Next Section
    @@ -11,18 +11,20 @@

    3. Commands

    -

    This section describes how a LAMMPS input script is formatted and what -commands are used to define a LAMMPS simulation. +

    This section describes how a LAMMPS input script is formatted and the +input script commands used to define a LAMMPS simulation.

    -3.1 LAMMPS input script
    -3.2 Parsing rules
    -3.3 Input script structure
    -3.4 Commands listed by category
    -3.5 Commands listed alphabetically
    +3.1 LAMMPS input script
    +3.2 Parsing rules
    +3.3 Input script structure
    +3.4 Commands listed by category
    +3.5 Commands listed alphabetically
    -

    3.1 LAMMPS input script +
    + +

    3.1 LAMMPS input script

    LAMMPS executes by reading commands from a input script (text file), one line at a time. When the input script ends, LAMMPS exits. Each @@ -76,7 +78,7 @@ command lists restrictions on how the command can be used.

    -

    3.2 Parsing rules +

    3.2 Parsing rules

    Each non-blank line in the input script is treated as a command. LAMMPS commands are case sensitive. Command names are lower-case, as @@ -135,7 +137,7 @@ allowed, but that should be sufficient for most use cases.

    -

    3.3 Input script structure +

    3.3 Input script structure

    This section describes the structure of a typical LAMMPS input script. The "examples" directory in the LAMMPS distribution contains many @@ -225,11 +227,11 @@ the minimize command. A parallel tempering

    -

    3.4 Commands listed by category +

    3.4 Commands listed by category

    This section lists all LAMMPS commands, grouped by category. The -next section lists the same commands alphabetically. Note that -some style options for some commands are part of specific LAMMPS +next section lists the same commands alphabetically. Note +that some style options for some commands are part of specific LAMMPS packages, which means they cannot be used unless the package was included when LAMMPS was built. Not all packages are included in a default LAMMPS build. These dependencies are listed as Restrictions @@ -264,12 +266,11 @@ in the command's documentation.

    Settings:

    -

    communicate, dipole, -group, mass, min_modify, -min_style, neigh_modify, -neighbor, reset_timestep, -run_style, set, shape, -timestep, velocity +

    communicate, group, mass, +min_modify, min_style, +neigh_modify, neighbor, +reset_timestep, run_style, +set, timestep, velocity

    Fixes:

    @@ -282,10 +283,11 @@ in the command's documentation.

    Output:

    -

    dump, dump_modify, -restart, thermo, -thermo_modify, thermo_style, -undump, write_restart +

    dump, dump image, +dump_modify, restart, +thermo, thermo_modify, +thermo_style, undump, +write_restart

    Actions:

    @@ -303,12 +305,12 @@ in the command's documentation.

    -

    3.5 Individual commands +

    3.5 Individual commands

    This section lists all LAMMPS commands alphabetically, with a separate -listing below of styles within certain commands. The previous -section lists the same commands, grouped by category. Note that -some style options for some commands are part of specific LAMMPS +listing below of styles within certain commands. The previous +section lists the same commands, grouped by category. Note +that some style options for some commands are part of specific LAMMPS packages, which means they cannot be used unless the package was included when LAMMPS was built. Not all packages are included in a default LAMMPS build. These dependencies are listed as Restrictions @@ -318,17 +320,17 @@ in the command's documentation. angle_coeffangle_styleatom_modifyatom_stylebond_coeffbond_style boundarychange_boxclearcommunicatecomputecompute_modify create_atomscreate_boxdelete_atomsdelete_bondsdielectricdihedral_coeff -dihedral_styledimensiondipoledisplace_atomsdisplace_boxdump +dihedral_styledimensiondisplace_atomsdisplace_boxdumpdump image dump_modifyechofixfix_modifygroupif improper_coeffimproper_styleincludejumpkspace_modifykspace_style labellatticelogmassminimizemin_modify min_stylenebneigh_modifyneighbornewtonnext -nthreadspair_coeffpair_modifypair_stylepair_writeprd -printprocessorsread_dataread_restartregionreplicate -reset_timesteprestartrunrun_stylesetshape -shellspecial_bondstadtemperthermothermo_modify -thermo_styletimestepuncomputeundumpunfixunits -variablevelocitywrite_restart +packagepair_coeffpair_modifypair_stylepair_writepartition +prdprintprocessorsread_dataread_restartregion +replicatereset_timesteprestartrunrun_styleset +shellspecial_bondssuffixtadtemperthermo +thermo_modifythermo_styletimestepuncomputeundumpunfix +unitsvariablevelocitywrite_restart

    @@ -341,22 +343,35 @@ of each style or click on the style itself for a full description:
    - - - - - - - - + + + + + + + +
    adaptaddforceaveforceave/atomave/correlateave/histoave/spatialave/time
    bond/breakbond/createbond/swapbox/relaxdeformdepositdragdt/reset
    efieldenforce2devaporateexternalfreezegravityheatindent
    langevinlineforcemomentummovemsstnebnphnph/asphere
    nph/spherenptnpt/aspherenpt/spherenvenve/aspherenve/limitnve/noforce
    nve/spherenvtnvt/aspherenvt/sllodnvt/sphereorient/fccplaneforcepoems
    pourpress/berendsenprintqeq/combreax/bondsrecenterrigidrigid/nve
    rigid/nvtsetforceshakespringspring/rgspring/selfsrdstore/force
    store/statetemp/berendsentemp/rescalethermal/conductivitytmdttmviscosityviscous
    wall/colloidwall/granwall/harmonicwall/lj126wall/lj93wall/reflectwall/regionwall/srd +
    efieldenforce2devaporateexternalfreezegcmcgravityheat
    indentlangevinlineforcemomentummovemsstnebnph
    nphugnph/aspherenph/spherenptnpt/aspherenpt/spherenvenve/asphere
    nve/asphere/noforcenve/limitnve/linenve/noforcenve/spherenve/trinvtnvt/asphere
    nvt/sllodnvt/sphereorient/fccplaneforcepoemspourpress/berendsenprint
    qeq/combreax/bondsrecenterrestrainrigidrigid/nverigid/nvtsetforce
    shakespringspring/rgspring/selfsrdstore/forcestore/statetemp/berendsen
    temp/rescalethermal/conductivitytmdttmviscosityviscouswall/colloidwall/gran
    wall/harmonicwall/lj126wall/lj93wall/reflectwall/regionwall/srd

    These are fix styles contributed by users, which can be used if -LAMMPS is built with the appropriate package. +LAMMPS is built with the appropriate +package.

    - - + +
    atcimdlangevin/effnph/effnpt/effnve/eff
    nvt/effnvt/sllod/effqeq/reaxsmdtemp/rescale/eff +
    addtorqueatcimdlangevin/effmesomeso/stationary
    nph/effnpt/effnve/effnvt/effnvt/sllod/effqeq/reax
    smdtemp/rescale/eff +
    + +

    These are accelerated fix styles, which can be used if LAMMPS is +built with the appropriate accelerated +package. +

    +
    + + +
    freeze/cudaaddforce/cudaaveforce/cudaenforce2d/cudagravity/cudagravity/omp
    npt/cudanve/cudanve/sphere/ompnvt/cudaqeq/comb/ompsetforce/cuda
    shake/cudatemp/berendsen/cudatemp/rescale/cudatemp/rescale/limit/cudaviscous/cuda
    @@ -372,16 +387,26 @@ each style or click on the style itself for a full description: erotate/asphereerotate/sphereevent/displacegroup/groupgyrationgyration/molecule heat/fluximproper/localkeke/atommsdmsd/molecule pairpair/localpepe/atompressureproperty/atom -property/localproperty/moleculerdfreducereduce/regionstress/atom -temptemp/aspheretemp/comtemp/deformtemp/partialtemp/profile -temp/ramptemp/regiontemp/sphereti +property/localproperty/moleculerdfreducereduce/regionslice +stress/atomtemptemp/aspheretemp/comtemp/deformtemp/partial +temp/profiletemp/ramptemp/regiontemp/sphereti

    These are compute styles contributed by users, which can be used if -LAMMPS is built with the appropriate package. +LAMMPS is built with the appropriate +package.

    - +
    ackland/atomke/effke/atom/efftemp/efftemp/deform/efftemp/region/eff +
    ackland/atomke/effke/atom/effmeso_e/atommeso_rho/atommeso_t/atom
    temp/efftemp/deform/efftemp/region/efftemp/rotate +
    + +

    These are accelerated compute styles, which can be used if LAMMPS is +built with the appropriate accelerated +package. +

    +
    +
    pe/cudapressure/cudatemp/cudatemp/partial/cuda
    @@ -392,33 +417,72 @@ each style or click on the style itself for a full description: potentials. Click on the style itself for a full description:

    - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + -
    nonehybridhybrid/overlayairebo
    bornborn/coul/longbuckbuck/coul/cut
    buck/coul/longcolloidcombcoul/cut
    coul/debyecoul/longdipole/cutdpd
    dpd/tstatdsmceameam/opt
    eam/alloyeam/alloy/opteam/fseam/fs/opt
    eimgaussgaybernegayberne/gpu
    gran/hertz/historygran/hookegran/hooke/historyhbond/dreiding/lj
    hbond/dreiding/morselj/charmm/coul/charmmlj/charmm/coul/charmm/implicitlj/charmm/coul/long
    lj/charmm/coul/long/gpulj/charmm/coul/long/optlj/class2lj/class2/coul/cut
    lj/class2/coul/longlj/cutlj/cut/gpulj/cut/opt
    lj/cut/coul/cutlj/cut/coul/cut/gpulj/cut/coul/debyelj/cut/coul/long
    lj/cut/coul/long/gpulj/cut/coul/long/tip4plj/expandlj/gromacs
    lj/gromacs/coul/gromacslj/smoothlj96/cutlj96/cut/gpu
    lubricatemeammorsemorse/opt
    peri/lpsperi/pmbreaxresquared
    nonehybridhybrid/overlayadp
    airebobornborn/coul/longbrownian
    brownian/polybuckbuck/coul/cutbuck/coul/long
    colloidcombcoul/cutcoul/debye
    coul/longdipole/cutdpddpd/tstat
    dsmceameam/alloyeam/fs
    eimgaussgaybernegran/hertz/history
    gran/hookegran/hooke/historyhbond/dreiding/ljhbond/dreiding/morse
    line/ljlj/charmm/coul/charmmlj/charmm/coul/charmm/implicitlj/charmm/coul/long
    lj/class2lj/class2/coul/cutlj/class2/coul/longlj/cut
    lj/cut/coul/cutlj/cut/coul/debyelj/cut/coul/longlj/cut/coul/long/tip4p
    lj/expandlj/gromacslj/gromacs/coul/gromacslj/smooth
    lj96/cutlubricatelubricate/polylubricateU
    lubricateU/polymeammorseperi/lps
    peri/pmbreaxreboresquared
    softswtabletersoff
    tersoff/zblyukawayukawa/colloid +
    tersoff/zbltri/ljyukawayukawa/colloid

    These are pair styles contributed by users, which can be used if -LAMMPS is built with the appropriate package. +LAMMPS is built with the appropriate +package.

    - - - + + + +
    buck/coulcg/cmmcg/cmm/gpucg/cmm/coul/cut
    cg/cmm/coul/longcoul/dielcg/cmm/coul/long/gpueam/cd
    eff/cutgauss/cutlj/coulreax/c +
    awpmd/cutbuck/coulcoul/diellj/sdk
    lj/sdk/coul/longdipole/sfeam/cdedip
    eff/cutgauss/cutlj/coullj/sf
    reax/csph/heatconductionsph/idealgassph/lj
    sph/rhosumsph/taitwatersph/taitwater/morristersoff/table +
    + +

    These are accelerated pair styles, which can be used if LAMMPS is +built with the appropriate accelerated +package. +

    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    adp/ompairebo/ompborn/coul/long/cudaborn/coul/long/omp
    born/ompbuck/coul/cut/cudabuck/coul/cut/ompbuck/coul/long/cuda
    buck/coul/long/ompbuck/coul/ompbuck/cudabuck/omp
    lj/sdk/gpulj/sdk/omplj/sdk/coul/long/gpulj/sdk/coul/long/omp
    colloid/ompcomb/ompcoul/cut/ompcoul/debye/omp
    coul/long/gpucoul/long/ompdipole/cut/ompdipole/sf/omp
    dpd/ompdpd/tstat/ompeam/alloy/cudaeam/alloy/omp
    eam/alloy/opteam/cd/ompeam/cudaeam/fs/cuda
    eam/fs/ompeam/fs/opteam/ompeam/opt
    edip/ompeim/ompgauss/ompgayberne/gpu
    gayberne/ompgran/hertz/history/ompgran/hooke/cudagran/hooke/history/omp
    gran/hooke/omphbond/dreiding/lj/omphbond/dreiding/morse/ompline/lj/omp
    lj/charmm/coul/charmm/cudalj/charmm/coul/charmm/omplj/charmm/coul/charmm/implicit/cudalj/charmm/coul/charmm/implicit/omp
    lj/charmm/coul/long/cudalj/charmm/coul/long/gpulj/charmm/coul/long/omplj/charmm/coul/long/opt
    lj/charmm/coul/pppm/omplj/class2/coul/cut/cudalj/class2/coul/cut/omplj/class2/coul/long/cuda
    lj/class2/coul/long/gpulj/class2/coul/long/omplj/class2/cudalj/class2/gpu
    lj/class2/omplj/coul/omplj/cut/coul/cut/cudalj/cut/coul/cut/gpu
    lj/cut/coul/cut/omplj/cut/coul/debye/cudalj/cut/coul/debye/omplj/cut/coul/long/cuda
    lj/cut/coul/long/gpulj/cut/coul/long/omplj/cut/coul/long/optlj/cut/coul/long/tip4p/omp
    lj/cut/coul/long/tip4p/optlj/cut/coul/pppm/omplj/cut/coul/pppm/tip4p/omplj/cut/cuda
    lj/cut/experimental/cudalj/cut/gpulj/cut/omplj/cut/opt
    lj/expand/cudalj/expand/gpulj/expand/omplj/gromacs/coul/gromacs/cuda
    lj/gromacs/coul/gromacs/omplj/gromacs/cudalj/gromacs/omplj/sf/omp
    lj/smooth/cudalj/smooth/omplj96/cut/cudalj96/cut/gpu
    lj96/cut/ompmorse/cudamorse/gpumorse/omp
    morse/optperi/lps/ompperi/pmb/omprebo/omp
    resquared/gpuresquared/ompsoft/ompsw/cuda
    sw/omptable/omptersoff/cudatersoff/omp
    tersoff/table/omptersoff/zbl/omptri/lj/ompyukawa/omp
    yukawa/colloid/omp
    @@ -434,6 +498,24 @@ potentials. Click on the style itself for a full description: quartictable +

    These are bond styles contributed by users, which can be used if +LAMMPS is built with the appropriate +package. +

    +
    +
    harmonic/shiftharmonic/shift/cut +
    + +

    These are accelerated bond styles, which can be used if LAMMPS is +built with the appropriate accelerated +package. +

    +
    + + +
    class2/ompfene/ompfene/expand/ompharmonic/omp
    harmonic/shift/ompharmonic/shift/cut/ompmorse/ompnonlinear/omp
    quartic/omptable/omp +
    +

    Angle_style potentials @@ -448,10 +530,21 @@ angle potentials. Click on the style itself for a full description:

    These are angle styles contributed by users, which can be used if -LAMMPS is built with the appropriate package. +LAMMPS is built with the appropriate +package.

    -
    cg/cmm +
    sdkcosine/shiftcosine/shift/exp +
    + +

    These are accelerated angle styles, which can be used if LAMMPS is +built with the appropriate accelerated +package. +

    +
    + + +
    charmm/ompclass2/ompcosine/ompcosine/delta/omp
    cosine/periodic/ompcosine/shift/ompcosine/shift/exp/ompcosine/squared/omp
    harmonic/omptable/omp
    @@ -467,6 +560,23 @@ description: harmonichelixmulti/harmonicopls +

    These are dihedral styles contributed by users, which can be used if +LAMMPS is built with the appropriate +package. +

    +
    +
    cosine/shift/exp +
    + +

    These are accelerated dihedral styles, which can be used if LAMMPS is +built with the appropriate accelerated +package. +

    +
    + +
    charmm/ompclass2/ompcosine/shift/exp/ompharmonic/omp
    helix/ompmulti/harmonic/ompopls/omp +
    +

    Improper_style potentials @@ -480,6 +590,14 @@ description: harmonicumbrella +

    These are accelerated improper styles, which can be used if LAMMPS is +built with the appropriate accelerated +package. +

    +
    +
    class2/ompcvff/ompharmonic/ompumbrella/omp +
    +

    Kspace solvers @@ -488,14 +606,24 @@ description: Kspace solvers. Click on the style itself for a full description:

    -
    ewaldpppmpppm/tip4p +
    ewaldpppmpppm/cgpppm/tip4p

    These are Kspace solvers contributed by users, which can be used if -LAMMPS is built with the appropriate package. +LAMMPS is built with the appropriate +package.

    ewald/n
    +

    These are accelerated Kspace solvers, which can be used if LAMMPS is +built with the appropriate accelerated +package. +

    +
    + +
    ewald/omppppm/cudapppm/gpupppm/omp
    pppm/proxy +
    + diff --git a/doc/Section_commands.txt b/doc/Section_commands.txt index 04010c293a..f7b71877d2 100644 --- a/doc/Section_commands.txt +++ b/doc/Section_commands.txt @@ -1,4 +1,4 @@ -"Previous Section"_Section_start.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_howto.html :c +"Previous Section"_Section_start.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_packages.html :c :link(lws,http://lammps.sandia.gov) :link(ld,Manual.html) @@ -8,18 +8,19 @@ 3. Commands :h3 -This section describes how a LAMMPS input script is formatted and what -commands are used to define a LAMMPS simulation. +This section describes how a LAMMPS input script is formatted and the +input script commands used to define a LAMMPS simulation. -3.1 "LAMMPS input script"_#3_1 -3.2 "Parsing rules"_#3_2 -3.3 "Input script structure"_#3_3 -3.4 "Commands listed by category"_#3_4 -3.5 "Commands listed alphabetically"_#3_5 :all(b) +3.1 "LAMMPS input script"_#cmd_1 +3.2 "Parsing rules"_#cmd_2 +3.3 "Input script structure"_#cmd_3 +3.4 "Commands listed by category"_#cmd_4 +3.5 "Commands listed alphabetically"_#cmd_5 :all(b) +:line :line -3.1 LAMMPS input script :link(3_1),h4 +3.1 LAMMPS input script :link(cmd_1),h4 LAMMPS executes by reading commands from a input script (text file), one line at a time. When the input script ends, LAMMPS exits. Each @@ -73,7 +74,7 @@ command lists restrictions on how the command can be used. :line -3.2 Parsing rules :link(3_2),h4 +3.2 Parsing rules :link(cmd_2),h4 Each non-blank line in the input script is treated as a command. LAMMPS commands are case sensitive. Command names are lower-case, as @@ -132,7 +133,7 @@ allowed, but that should be sufficient for most use cases. :line -3.3 Input script structure :h4,link(3_3) +3.3 Input script structure :h4,link(cmd_3) This section describes the structure of a typical LAMMPS input script. The "examples" directory in the LAMMPS distribution contains many @@ -222,11 +223,11 @@ the "minimize"_minimize.html command. A parallel tempering :line -3.4 Commands listed by category :link(3_4),h4 +3.4 Commands listed by category :link(cmd_4),h4 This section lists all LAMMPS commands, grouped by category. The -"next section"_#3_5 lists the same commands alphabetically. Note that -some style options for some commands are part of specific LAMMPS +"next section"_#cmd_5 lists the same commands alphabetically. Note +that some style options for some commands are part of specific LAMMPS packages, which means they cannot be used unless the package was included when LAMMPS was built. Not all packages are included in a default LAMMPS build. These dependencies are listed as Restrictions @@ -261,12 +262,11 @@ Force fields: Settings: -"communicate"_communicate.html, "dipole"_dipole.html, -"group"_group.html, "mass"_mass.html, "min_modify"_min_modify.html, -"min_style"_min_style.html, "neigh_modify"_neigh_modify.html, -"neighbor"_neighbor.html, "reset_timestep"_reset_timestep.html, -"run_style"_run_style.html, "set"_set.html, "shape"_shape.html, -"timestep"_timestep.html, "velocity"_velocity.html +"communicate"_communicate.html, "group"_group.html, "mass"_mass.html, +"min_modify"_min_modify.html, "min_style"_min_style.html, +"neigh_modify"_neigh_modify.html, "neighbor"_neighbor.html, +"reset_timestep"_reset_timestep.html, "run_style"_run_style.html, +"set"_set.html, "timestep"_timestep.html, "velocity"_velocity.html Fixes: @@ -279,10 +279,11 @@ Computes: Output: -"dump"_dump.html, "dump_modify"_dump_modify.html, -"restart"_restart.html, "thermo"_thermo.html, -"thermo_modify"_thermo_modify.html, "thermo_style"_thermo_style.html, -"undump"_undump.html, "write_restart"_write_restart.html +"dump"_dump.html, "dump image"_dump_image.html, +"dump_modify"_dump_modify.html, "restart"_restart.html, +"thermo"_thermo.html, "thermo_modify"_thermo_modify.html, +"thermo_style"_thermo_style.html, "undump"_undump.html, +"write_restart"_write_restart.html Actions: @@ -300,12 +301,12 @@ Miscellaneous: :line -3.5 Individual commands :h4,link(3_5),link(comm) +3.5 Individual commands :h4,link(cmd_5),link(comm) This section lists all LAMMPS commands alphabetically, with a separate listing below of styles within certain commands. The "previous -section"_#3_4 lists the same commands, grouped by category. Note that -some style options for some commands are part of specific LAMMPS +section"_#cmd_4 lists the same commands, grouped by category. Note +that some style options for some commands are part of specific LAMMPS packages, which means they cannot be used unless the package was included when LAMMPS was built. Not all packages are included in a default LAMMPS build. These dependencies are listed as Restrictions @@ -331,10 +332,10 @@ in the command's documentation. "dihedral_coeff"_dihedral_coeff.html, "dihedral_style"_dihedral_style.html, "dimension"_dimension.html, -"dipole"_dipole.html, "displace_atoms"_displace_atoms.html, "displace_box"_displace_box.html, "dump"_dump.html, +"dump image"_dump_image.html, "dump_modify"_dump_modify.html, "echo"_echo.html, "fix"_fix.html, @@ -359,11 +360,12 @@ in the command's documentation. "neighbor"_neighbor.html, "newton"_newton.html, "next"_next.html, -"nthreads"_nthreads.html, +"package"_package.html, "pair_coeff"_pair_coeff.html, "pair_modify"_pair_modify.html, "pair_style"_pair_style.html, "pair_write"_pair_write.html, +"partition"_partition.html, "prd"_prd.html, "print"_print.html, "processors"_processors.html, @@ -376,9 +378,9 @@ in the command's documentation. "run"_run.html, "run_style"_run_style.html, "set"_set.html, -"shape"_shape.html, "shell"_shell.html, "special_bonds"_special_bonds.html, +"suffix"_suffix.html, "tad"_tad.html, "temper"_temper.html, "thermo"_thermo.html, @@ -421,6 +423,7 @@ of each style or click on the style itself for a full description: "evaporate"_fix_evaporate.html, "external"_fix_external.html, "freeze"_fix_freeze.html, +"gcmc"_fix_gcmc.html, "gravity"_fix_gravity.html, "heat"_fix_heat.html, "indent"_fix_indent.html, @@ -431,6 +434,7 @@ of each style or click on the style itself for a full description: "msst"_fix_msst.html, "neb"_fix_neb.html, "nph"_fix_nh.html, +"nphug"_fix_nphug.html, "nph/asphere"_fix_nph_asphere.html, "nph/sphere"_fix_nph_sphere.html, "npt"_fix_nh.html, @@ -438,9 +442,12 @@ of each style or click on the style itself for a full description: "npt/sphere"_fix_npt_sphere.html, "nve"_fix_nve.html, "nve/asphere"_fix_nve_asphere.html, +"nve/asphere/noforce"_fix_nve_asphere_noforce.html, "nve/limit"_fix_nve_limit.html, +"nve/line"_fix_nve_line.html, "nve/noforce"_fix_nve_noforce.html, "nve/sphere"_fix_nve_sphere.html, +"nve/tri"_fix_nve_tri.html, "nvt"_fix_nh.html, "nvt/asphere"_fix_nvt_asphere.html, "nvt/sllod"_fix_nvt_sllod.html, @@ -454,6 +461,7 @@ of each style or click on the style itself for a full description: "qeq/comb"_fix_qeq_comb.html, "reax/bonds"_fix_reax_bonds.html, "recenter"_fix_recenter.html, +"restrain"_fix_restrain.html, "rigid"_fix_rigid.html, "rigid/nve"_fix_rigid.html, "rigid/nvt"_fix_rigid.html, @@ -482,11 +490,15 @@ of each style or click on the style itself for a full description: "wall/srd"_fix_wall_srd.html :tb(c=8,ea=c) These are fix styles contributed by users, which can be used if -"LAMMPS is built with the appropriate package"_Section_start.html#2_3. +"LAMMPS is built with the appropriate +package"_Section_start.html#start_3. +"addtorque"_fix_addtorque.html, "atc"_fix_atc.html, "imd"_fix_imd.html, "langevin/eff"_fix_langevin_eff.html, +"meso"_fix_meso.html, +"meso/stationary"_fix_meso_stationary.html, "nph/eff"_fix_nh_eff.html, "npt/eff"_fix_nh_eff.html, "nve/eff"_fix_nve_eff.html, @@ -496,6 +508,28 @@ These are fix styles contributed by users, which can be used if "smd"_fix_smd.html, "temp/rescale/eff"_fix_temp_rescale_eff.html :tb(c=6,ea=c) +These are accelerated fix styles, which can be used if LAMMPS is +built with the "appropriate accelerated +package"_Section_accelerate.html. + +"freeze/cuda"_fix_freeze.html, +"addforce/cuda"_fix_addforce.html, +"aveforce/cuda"_fix_aveforce.html, +"enforce2d/cuda"_fix_enforce2d.html, +"gravity/cuda"_fix_gravity.html, +"gravity/omp"_fix_gravity.html, +"npt/cuda"_fix_nh.html, +"nve/cuda"_fix_nh.html, +"nve/sphere/omp"_fix_nve_sphere.html, +"nvt/cuda"_fix_nh.html, +"qeq/comb/omp"_fix_qeq_comb.html, +"setforce/cuda"_fix_setforce.html, +"shake/cuda"_fix_shake.html, +"temp/berendsen/cuda"_fix_temp_berendsen.html, +"temp/rescale/cuda"_fix_temp_rescale.html, +"temp/rescale/limit/cuda"_fix_temp_rescale.html, +"viscous/cuda"_fix_viscous.html :tb(c=6,ea=c) + :line Compute styles :h4 @@ -538,6 +572,7 @@ each style or click on the style itself for a full description: "rdf"_compute_rdf.html, "reduce"_compute_reduce.html, "reduce/region"_compute_reduce.html, +"slice"_compute_slice.html, "stress/atom"_compute_stress_atom.html, "temp"_compute_temp.html, "temp/asphere"_compute_temp_asphere.html, @@ -551,14 +586,28 @@ each style or click on the style itself for a full description: "ti"_compute_ti.html :tb(c=6,ea=c) These are compute styles contributed by users, which can be used if -"LAMMPS is built with the appropriate package"_Section_start.html#2_3. +"LAMMPS is built with the appropriate +package"_Section_start.html#start_3. "ackland/atom"_compute_ackland_atom.html, "ke/eff"_compute_ke_eff.html, "ke/atom/eff"_compute_ke_atom_eff.html, +"meso_e/atom"_compute_meso_e_atom.html, +"meso_rho/atom"_compute_meso_rho_atom.html, +"meso_t/atom"_compute_meso_t_atom.html, "temp/eff"_compute_temp_eff.html, "temp/deform/eff"_compute_temp_deform_eff.html, -"temp/region/eff"_compute_temp_region_eff.html :tb(c=6,ea=c) +"temp/region/eff"_compute_temp_region_eff.html, +"temp/rotate"_compute_temp_rotate.html :tb(c=6,ea=c) + +These are accelerated compute styles, which can be used if LAMMPS is +built with the "appropriate accelerated +package"_Section_accelerate.html. + +"pe/cuda"_compute_pe.html, +"pressure/cuda"_compute_pressure.html, +"temp/cuda"_compute_temp.html, +"temp/partial/cuda"_compute_temp_partial.html :tb(c=6,ea=c) :line @@ -570,9 +619,12 @@ potentials. Click on the style itself for a full description: "none"_pair_none.html, "hybrid"_pair_hybrid.html, "hybrid/overlay"_pair_hybrid.html, +"adp"_pair_adp.html, "airebo"_pair_airebo.html, "born"_pair_born.html, "born/coul/long"_pair_born.html, +"brownian"_pair_brownian.html, +"brownian/poly"_pair_brownian.html, "buck"_pair_buck.html, "buck/coul/cut"_pair_buck.html, "buck/coul/long"_pair_buck.html, @@ -586,74 +638,199 @@ potentials. Click on the style itself for a full description: "dpd/tstat"_pair_dpd.html, "dsmc"_pair_dsmc.html, "eam"_pair_eam.html, -"eam/opt"_pair_eam.html, "eam/alloy"_pair_eam.html, -"eam/alloy/opt"_pair_eam.html, "eam/fs"_pair_eam.html, -"eam/fs/opt"_pair_eam.html, "eim"_pair_eim.html, "gauss"_pair_gauss.html, "gayberne"_pair_gayberne.html, -"gayberne/gpu"_pair_gayberne.html, "gran/hertz/history"_pair_gran.html, "gran/hooke"_pair_gran.html, "gran/hooke/history"_pair_gran.html, "hbond/dreiding/lj"_pair_hbond_dreiding.html, "hbond/dreiding/morse"_pair_hbond_dreiding.html, +"line/lj"_pair_line_lj.html, "lj/charmm/coul/charmm"_pair_charmm.html, "lj/charmm/coul/charmm/implicit"_pair_charmm.html, "lj/charmm/coul/long"_pair_charmm.html, -"lj/charmm/coul/long/gpu"_pair_charmm.html, -"lj/charmm/coul/long/opt"_pair_charmm.html, "lj/class2"_pair_class2.html, "lj/class2/coul/cut"_pair_class2.html, "lj/class2/coul/long"_pair_class2.html, "lj/cut"_pair_lj.html, -"lj/cut/gpu"_pair_lj.html, -"lj/cut/opt"_pair_lj.html, "lj/cut/coul/cut"_pair_lj.html, -"lj/cut/coul/cut/gpu"_pair_lj.html, "lj/cut/coul/debye"_pair_lj.html, "lj/cut/coul/long"_pair_lj.html, -"lj/cut/coul/long/gpu"_pair_lj.html, "lj/cut/coul/long/tip4p"_pair_lj.html, "lj/expand"_pair_lj_expand.html, "lj/gromacs"_pair_gromacs.html, "lj/gromacs/coul/gromacs"_pair_gromacs.html, "lj/smooth"_pair_lj_smooth.html, -"lj96/cut"_pair_lj96_cut.html, -"lj96/cut/gpu"_pair_lj96_cut.html, +"lj96/cut"_pair_lj96.html, "lubricate"_pair_lubricate.html, +"lubricate/poly"_pair_lubricate.html, +"lubricateU"_pair_lubricateU.html, +"lubricateU/poly"_pair_lubricateU.html, "meam"_pair_meam.html, "morse"_pair_morse.html, -"morse/opt"_pair_morse.html, "peri/lps"_pair_peri.html, "peri/pmb"_pair_peri.html, "reax"_pair_reax.html, +"rebo"_pair_airebo.html, "resquared"_pair_resquared.html, "soft"_pair_soft.html, "sw"_pair_sw.html, "table"_pair_table.html, "tersoff"_pair_tersoff.html, "tersoff/zbl"_pair_tersoff_zbl.html, +"tri/lj"_pair_tri_lj.html, "yukawa"_pair_yukawa.html, "yukawa/colloid"_pair_yukawa_colloid.html :tb(c=4,ea=c) These are pair styles contributed by users, which can be used if -"LAMMPS is built with the appropriate package"_Section_start.html#2_3. +"LAMMPS is built with the appropriate +package"_Section_start.html#start_3. +"awpmd/cut"_pair_awpmd.html, "buck/coul"_pair_buck_coul.html, -"cg/cmm"_pair_cmm.html, -"cg/cmm/gpu"_pair_cmm.html, -"cg/cmm/coul/cut"_pair_cmm.html, -"cg/cmm/coul/long"_pair_cmm.html, "coul/diel"_pair_coul_diel.html, -"cg/cmm/coul/long/gpu"_pair_cmm.html, +"lj/sdk"_pair_sdk.html, +"lj/sdk/coul/long"_pair_sdk.html, +"dipole/sf"_pair_dipole.html, "eam/cd"_pair_eam.html, +"edip"_pair_edip.html, "eff/cut"_pair_eff.html, "gauss/cut"_pair_gauss.html, "lj/coul"_pair_lj_coul.html, -"reax/c"_pair_reax_c.html :tb(c=4,ea=c) +"lj/sf"_pair_lj_sf.html, +"reax/c"_pair_reax_c.html, +"sph/heatconduction"_pair_heatconduction.html, +"sph/idealgas"_pair_idealgas.html, +"sph/lj"_pair_lj.html, +"sph/rhosum"_pair_rhosum.html, +"sph/taitwater"_pair_taitwater.html, +"sph/taitwater/morris"_pair_taitwater_morris.html, +"tersoff/table"_pair_tersoff.html :tb(c=4,ea=c) + +These are accelerated pair styles, which can be used if LAMMPS is +built with the "appropriate accelerated +package"_Section_accelerate.html. + +"adp/omp"_pair_adp.html, +"airebo/omp"_pair_airebo.html, +"born/coul/long/cuda"_pair_born.html, +"born/coul/long/omp"_pair_born.html, +"born/omp"_pair_born.html, +"buck/coul/cut/cuda"_pair_buck.html, +"buck/coul/cut/omp"_pair_buck.html, +"buck/coul/long/cuda"_pair_buck.html, +"buck/coul/long/omp"_pair_buck.html, +"buck/coul/omp"_pair_buck_coul.html, +"buck/cuda"_pair_buck.html, +"buck/omp"_pair_buck.html, +"lj/sdk/gpu"_pair_sdk.html, +"lj/sdk/omp"_pair_sdk.html, +"lj/sdk/coul/long/gpu"_pair_sdk.html, +"lj/sdk/coul/long/omp"_pair_sdk.html, +"colloid/omp"_pair_colloid.html, +"comb/omp"_pair_comb.html, +"coul/cut/omp"_pair_coul.html, +"coul/debye/omp"_pair_coul.html, +"coul/long/gpu"_pair_coul.html, +"coul/long/omp"_pair_coul.html, +"dipole/cut/omp"_pair_dipole.html, +"dipole/sf/omp"_pair_dipole.html, +"dpd/omp"_pair_dpd.html, +"dpd/tstat/omp"_pair_dpd.html, +"eam/alloy/cuda"_pair_eam.html, +"eam/alloy/omp"_pair_eam.html, +"eam/alloy/opt"_pair_eam.html, +"eam/cd/omp"_pair_eam.html, +"eam/cuda"_pair_eam.html, +"eam/fs/cuda"_pair_eam.html, +"eam/fs/omp"_pair_eam.html, +"eam/fs/opt"_pair_eam.html, +"eam/omp"_pair_eam.html, +"eam/opt"_pair_eam.html, +"edip/omp"_pair_edip.html, +"eim/omp"_pair_eim.html, +"gauss/omp"_pair_gauss.html, +"gayberne/gpu"_pair_gayberne.html, +"gayberne/omp"_pair_gayberne.html, +"gran/hertz/history/omp"_pair_gran.html, +"gran/hooke/cuda"_pair_gran.html, +"gran/hooke/history/omp"_pair_gran.html, +"gran/hooke/omp"_pair_gran.html, +"hbond/dreiding/lj/omp"_pair_hbond_dreiding.html, +"hbond/dreiding/morse/omp"_pair_hbond_dreiding.html, +"line/lj/omp"_pair_line_lj.html, +"lj/charmm/coul/charmm/cuda"_pair_charmm.html, +"lj/charmm/coul/charmm/omp"_pair_charmm.html, +"lj/charmm/coul/charmm/implicit/cuda"_pair_charmm.html, +"lj/charmm/coul/charmm/implicit/omp"_pair_charmm.html, +"lj/charmm/coul/long/cuda"_pair_charmm.html, +"lj/charmm/coul/long/gpu"_pair_charmm.html, +"lj/charmm/coul/long/omp"_pair_charmm.html, +"lj/charmm/coul/long/opt"_pair_charmm.html, +"lj/charmm/coul/pppm/omp"_pair_charmm.html, +"lj/class2/coul/cut/cuda"_pair_class2.html, +"lj/class2/coul/cut/omp"_pair_class2.html, +"lj/class2/coul/long/cuda"_pair_class2.html, +"lj/class2/coul/long/gpu"_pair_class2.html, +"lj/class2/coul/long/omp"_pair_class2.html, +"lj/class2/cuda"_pair_class2.html, +"lj/class2/gpu"_pair_class2.html, +"lj/class2/omp"_pair_class2.html, +"lj/coul/omp"_pair_lj_coul.html, +"lj/cut/coul/cut/cuda"_pair_lj.html, +"lj/cut/coul/cut/gpu"_pair_lj.html, +"lj/cut/coul/cut/omp"_pair_lj.html, +"lj/cut/coul/debye/cuda"_pair_lj.html, +"lj/cut/coul/debye/omp"_pair_lj.html, +"lj/cut/coul/long/cuda"_pair_lj.html, +"lj/cut/coul/long/gpu"_pair_lj.html, +"lj/cut/coul/long/omp"_pair_lj.html, +"lj/cut/coul/long/opt"_pair_lj.html, +"lj/cut/coul/long/tip4p/omp"_pair_lj.html, +"lj/cut/coul/long/tip4p/opt"_pair_lj.html, +"lj/cut/coul/pppm/omp"_pair_lj.html, +"lj/cut/coul/pppm/tip4p/omp"_pair_lj.html, +"lj/cut/cuda"_pair_lj.html, +"lj/cut/experimental/cuda"_pair_lj.html, +"lj/cut/gpu"_pair_lj.html, +"lj/cut/omp"_pair_lj.html, +"lj/cut/opt"_pair_lj.html, +"lj/expand/cuda"_pair_lj_expand.html, +"lj/expand/gpu"_pair_lj_expand.html, +"lj/expand/omp"_pair_lj_expand.html, +"lj/gromacs/coul/gromacs/cuda"_pair_gromacs.html, +"lj/gromacs/coul/gromacs/omp"_pair_gromacs.html, +"lj/gromacs/cuda"_pair_gromacs.html, +"lj/gromacs/omp"_pair_gromacs.html, +"lj/sf/omp"_pair_lj_sf.html, +"lj/smooth/cuda"_pair_lj_smooth.html, +"lj/smooth/omp"_pair_lj_smooth.html, +"lj96/cut/cuda"_pair_lj96.html, +"lj96/cut/gpu"_pair_lj96.html, +"lj96/cut/omp"_pair_lj96.html, +"morse/cuda"_pair_morse.html, +"morse/gpu"_pair_morse.html, +"morse/omp"_pair_morse.html, +"morse/opt"_pair_morse.html, +"peri/lps/omp"_pair_peri.html, +"peri/pmb/omp"_pair_peri.html, +"rebo/omp"_pair_airebo.html, +"resquared/gpu"_pair_resquared.html, +"resquared/omp"_pair_resquared.html, +"soft/omp"_pair_soft.html, +"sw/cuda"_pair_sw.html, +"sw/omp"_pair_sw.html, +"table/omp"_pair_table.html, +"tersoff/cuda"_pair_tersoff.html, +"tersoff/omp"_pair_tersoff.html, +"tersoff/table/omp"_pair_tersoff.html, +"tersoff/zbl/omp"_pair_tersoff_zbl.html, +"tri/lj/omp"_pair_tri_lj.html, +"yukawa/omp"_pair_yukawa.html, +"yukawa/colloid/omp"_pair_yukawa_colloid.html :tb(c=4,ea=c) :line @@ -673,6 +850,28 @@ potentials. Click on the style itself for a full description: "quartic"_bond_quartic.html, "table"_bond_table.html :tb(c=4,ea=c,w=100) +These are bond styles contributed by users, which can be used if +"LAMMPS is built with the appropriate +package"_Section_start.html#start_3. + +"harmonic/shift"_bond_harmonic_shift.html, +"harmonic/shift/cut"_bond_harmonic_shift_cut.html :tb(c=4,ea=c) + +These are accelerated bond styles, which can be used if LAMMPS is +built with the "appropriate accelerated +package"_Section_accelerate.html. + +"class2/omp"_bond_class2.html, +"fene/omp"_bond_fene.html, +"fene/expand/omp"_bond_fene_expand.html, +"harmonic/omp"_bond_harmonic.html, +"harmonic/shift/omp"_bond_harmonic_shift.html, +"harmonic/shift/cut/omp"_bond_harmonic_shift_cut.html, +"morse/omp"_bond_morse.html, +"nonlinear/omp"_bond_nonlinear.html, +"quartic/omp"_bond_quartic.html, +"table/omp"_bond_table.html :tb(c=4,ea=c,w=100) + :line Angle_style potentials :h4 @@ -692,9 +891,27 @@ angle potentials. Click on the style itself for a full description: "table"_angle_table.html :tb(c=4,ea=c,w=100) These are angle styles contributed by users, which can be used if -"LAMMPS is built with the appropriate package"_Section_start.html#2_3. +"LAMMPS is built with the appropriate +package"_Section_start.html#start_3. -"cg/cmm"_angle_cmm.html :tb(c=4,ea=c) +"sdk"_angle_sdk.html, +"cosine/shift"_angle_cosine_shift.html, +"cosine/shift/exp"_angle_cosine_shift_exp.html :tb(c=4,ea=c) + +These are accelerated angle styles, which can be used if LAMMPS is +built with the "appropriate accelerated +package"_Section_accelerate.html. + +"charmm/omp"_angle_charmm.html, +"class2/omp"_angle_class2.html, +"cosine/omp"_angle_cosine.html, +"cosine/delta/omp"_angle_cosine_delta.html, +"cosine/periodic/omp"_angle_cosine_periodic.html, +"cosine/shift/omp"_angle_cosine_shift.html, +"cosine/shift/exp/omp"_angle_cosine_shift_exp.html, +"cosine/squared/omp"_angle_cosine_squared.html, +"harmonic/omp"_angle_harmonic.html, +"table/omp"_angle_table.html :tb(c=4,ea=c,w=100) :line @@ -713,6 +930,24 @@ description: "multi/harmonic"_dihedral_multi_harmonic.html, "opls"_dihedral_opls.html :tb(c=4,ea=c,w=100) +These are dihedral styles contributed by users, which can be used if +"LAMMPS is built with the appropriate +package"_Section_start.html#start_3. + +"cosine/shift/exp"_dihedral_cosine_shift_exp.html :tb(c=4,ea=c) + +These are accelerated dihedral styles, which can be used if LAMMPS is +built with the "appropriate accelerated +package"_Section_accelerate.html. + +"charmm/omp"_dihedral_charmm.html, +"class2/omp"_dihedral_class2.html, +"cosine/shift/exp/omp"_dihedral_cosine_shift_exp.html, +"harmonic/omp"_dihedral_harmonic.html, +"helix/omp"_dihedral_helix.html, +"multi/harmonic/omp"_dihedral_multi_harmonic.html, +"opls/omp"_dihedral_opls.html :tb(c=4,ea=c,w=100) + :line Improper_style potentials :h4 @@ -728,6 +963,15 @@ description: "harmonic"_improper_harmonic.html, "umbrella"_improper_umbrella.html :tb(c=4,ea=c,w=100) +These are accelerated improper styles, which can be used if LAMMPS is +built with the "appropriate accelerated +package"_Section_accelerate.html. + +"class2/omp"_improper_class2.html, +"cvff/omp"_improper_cvff.html, +"harmonic/omp"_improper_harmonic.html, +"umbrella/omp"_improper_umbrella.html :tb(c=4,ea=c,w=100) + :line Kspace solvers :h4 @@ -737,9 +981,21 @@ Kspace solvers. Click on the style itself for a full description: "ewald"_kspace_style.html, "pppm"_kspace_style.html, +"pppm/cg"_kspace_style.html, "pppm/tip4p"_kspace_style.html :tb(c=4,ea=c,w=100) These are Kspace solvers contributed by users, which can be used if -"LAMMPS is built with the appropriate package"_Section_start.html#2_3. +"LAMMPS is built with the appropriate +package"_Section_start.html#start_3. "ewald/n"_kspace_style.html :tb(c=4,ea=c,w=100) + +These are accelerated Kspace solvers, which can be used if LAMMPS is +built with the "appropriate accelerated +package"_Section_accelerate.html. + +"ewald/omp"_kspace_style.html, +"pppm/cuda"_kspace_style.html, +"pppm/gpu"_kspace_style.html, +"pppm/omp"_kspace_style.html, +"pppm/proxy"_kspace_style.html :tb(c=4,ea=c) diff --git a/doc/Section_errors.html b/doc/Section_errors.html index ebf3222a71..b7fbbbba7a 100644 --- a/doc/Section_errors.html +++ b/doc/Section_errors.html @@ -11,18 +11,20 @@ Section
    -

    10. Errors +

    12. Errors

    -

    This section describes the various kinds of errors you can encounter -when using LAMMPS. +

    This section describes the errors you can encounter when using LAMMPS, +either conceptually, or as printed out by the program.

    -10.1 Common problems
    -10.2 Reporting bugs
    -10.3 Error & warning messages
    +12.1 Common problems
    +12.2 Reporting bugs
    +12.3 Error & warning messages
    -

    10.1 Common problems +
    + +

    12.1 Common problems

    If two LAMMPS runs do not produce the same answer on different machines or different numbers of processors, this is typically not a @@ -81,7 +83,7 @@ decide if the WARNING is important or not. A WARNING message that is generated in the middle of a run is only printed to the screen, not to the logfile, to avoid cluttering up thermodynamic output. If LAMMPS crashes or hangs without spitting out an error message first then it -could be a bug (see this section) or one of the following +could be a bug (see this section) or one of the following cases:

    LAMMPS runs in the available memory a processor allows to be @@ -112,7 +114,7 @@ buffering or boost the sizes of messages that can be buffered.

    -

    10.2 Reporting bugs +

    12.2 Reporting bugs

    If you are confident that you have found a bug in LAMMPS, follow these steps. @@ -142,18 +144,22 @@ causing the problem.

    -

    10.3 Error & warning messages +

    12.3 Error & warning messages

    These are two alphabetic lists of the ERROR and WARNING messages LAMMPS prints out and the reason why. If the explanation here is not sufficient, the documentation for the -offending command may help. Grepping the source files for the text of -the error message and staring at the source code and comments is also -not a bad idea! Note that sometimes the same message can be printed -from multiple places in the code. +offending command may help. +Error and warning messages also list the source file and line number +where the error was generated. For example, this message

    -

    Also note that error messages from user-contributed -packages are not listed here. Is such an +

    ERROR: Illegal velocity command (velocity.cpp:78) +

    +

    means that line #78 in the file src/velocity.cpp generated the error. +Looking in the source code may help you figure out what went wrong. +

    +

    Note that error messages from user-contributed +packages are not listed here. If such an error occurs and is not self-explanatory, you'll need to look in the source code or contact the author of the package.

    @@ -173,6 +179,16 @@ the bond topologies you have defined. neighbors for each atom. This likely means something is wrong with the bond topologies you have defined. +
    Accelerated style in input script but no fix gpu + +
    GPU acceleration requires fix gpu in the input script. + +
    Accelerator sharing is not currently supported on system. + +
    You cannot use more MPI processes than accelerators on the +system as currently configured. For NVIDIA GPUs, the compute +mode must be changed using nvidia-smi to support sharing. +
    All angle coeffs are not set
    All angle coefficients must be set in the data file or by the @@ -236,7 +252,7 @@ the atoms are too far apart to make a valid angle. a particular processor. The pairwise cutoff is too short or the atoms are too far apart to make a valid angle. -
    Angle atoms %d %d %d missing on proc %d at step %d +
    Angle atoms %d %d %d missing on proc %d at step
    One or more of 3 atoms needed to compute a particular angle are missing on this processor. Typically this is because the pairwise @@ -319,14 +335,6 @@ still being processed.
    Argument of arcsin() must be between -1 and 1. -
    At least 1 proc could not allocate a CUDA gpu or memory - -
    You are not setup correctly to use a GPU from your CPU. - -
    At least one process could not allocate a CUDA-enabled gpu - -
    Self-explanatory. -
    Atom IDs must be consecutive for velocity create loop all
    Self-explanatory. @@ -406,6 +414,14 @@ read_restart, or create_box command.
    Two atoms in a FENE bond have become so far apart that the bond cannot be computed. +
    Bad TIP4P angle type for PPPM/TIP4P + +
    Specified angle type is not valid. + +
    Bad TIP4P bond type for PPPM/TIP4P + +
    Specified bond type is not valid. +
    Bad grid of processors
    The 3d grid of processors defined by the processors command does not @@ -437,6 +453,15 @@ compute.
    Big particles must be extended spheriods or ellipsoids. +
    Bigint setting in lmptype.h is invalid + +
    Size of bigint is less than size of tagint. + +
    Bigint setting in lmptype.h is not compatible + +
    Bigint stored in restart file is not consistent with LAMMPS version +you are running. +
    Bitmapped lookup tables require int/float be same size
    Cannot use pair tables on this machine, because of word sizes. Use @@ -468,7 +493,7 @@ the atoms are too far apart to make a valid bond. a particular processor. The pairwise cutoff is too short or the atoms are too far apart to make a valid bond. -
    Bond atoms %d %d missing on proc %d at step %d +
    Bond atoms %d %d missing on proc %d at step
    One or both of 2 atoms needed to compute a particular bond are missing on this processor. Typically this is because the pairwise @@ -575,10 +600,18 @@ See the region prism command for details.
    This is current restriction for NEB as implemented in LAMMPS. +
    Can only use TAD with 1-processor replicas for NEB + +
    This is current restriction for NEB as implemented in LAMMPS. +
    Cannot (yet) use PPPM with triclinic box
    This feature is not yet supported. +
    Cannot add atoms to fix move variable + +
    Atoms can not be added afterwards to this fix option. +
    Cannot change box to orthogonal when tilt is non-zero
    Self-explanatory @@ -625,6 +658,11 @@ but the atoms that have been defined have no IDs.
    Must use the lattice command before using the create_atoms command. +
    Cannot create/grow a vector/array of pointers for %s + +
    LAMMPS code is making an illegal call to the templated memory +allocaters, to create a vector or array of pointers. +
    Cannot create_atoms after reading restart file with per-atom info
    The per-atom info was stored to be used when by a fix that you @@ -636,6 +674,10 @@ there will not be a correct amount of per-atom info.
    The create_box command cannot be used after a read_data, read_restart, or create_box command. +
    Cannot currently use pair reax with pair hybrid + +
    This is not yet supported. +
    Cannot delete group all
    Self-explanatory. @@ -904,10 +946,6 @@ run a 2d simulation. all together (pair), or in pieces (inner/middle/outer). You can't do both. -
    Cannot set both vel and wiggle in fix wall command - -
    Self-explantory. -
    Cannot set dipole for this atom style
    This atom style does not support dipole settings for each atom type. @@ -921,6 +959,14 @@ both.
    This atom style does not support mass settings for each atom type. Instead they are defined on a per-atom basis in the data file. +
    Cannot set non-zero image flag for non-periodic dimension + +
    Self-explanatory. + +
    Cannot set non-zero z velocity for 2d simulation + +
    Self-explanatory. +
    Cannot set respa middle without inner/outer
    In the rRESPA integrator, you must define both a inner and outer @@ -934,6 +980,10 @@ setting in order to use a middle setting.
    The attribute being set does not exist for the defined atom style. +
    Cannot set variable z velocity for 2d simulation + +
    Self-explanatory. +
    Cannot skew triclinic box in z for 2d simulation
    Self-explanatory. @@ -981,6 +1031,18 @@ which is enabled by default, via the atom_modify command.
    Use the atom_modify command to create an atom map. +
    Cannot use TAD unless atom map exists for NEB + +
    See atom_modify map command to set this. + +
    Cannot use TAD with a single replica for NEB + +
    NEB requires multiple replicas. + +
    Cannot use TAD with atom_modify sort enabled for NEB + +
    This is a current restriction of NEB. +
    Cannot use a damped dynamics min style with fix box/relax
    This is a current restriction in LAMMPS. Use another minimizer @@ -991,6 +1053,14 @@ style.
    This is a current restriction in LAMMPS. Use another minimizer style. +
    Cannot use compute cluster/atom unless atoms have IDs + +
    Atom IDs are used to identify clusters. + +
    Cannot use cwiggle in variable formula between runs + +
    This is a function of elapsed time. +
    Cannot use delete_atoms unless atoms have IDs
    Your atoms do not have IDs, so the delete_atoms command cannot be @@ -1007,6 +1077,10 @@ provided by an atom map. An atom map does not exist (by default) for non-molecular problems. Using the atom_modify map command will force an atom map to be created. +
    Cannot use fix ave/spatial z for 2 dimensional model + +
    Self-explanatory. +
    Cannot use fix bond/break with non-molecular systems
    Self-explanatory. @@ -1105,23 +1179,71 @@ together.
    Self-explanatory. +
    Cannot use fix wall/reflect in periodic dimension + +
    Self-explanatory. + +
    Cannot use fix wall/reflect zlo/zhi for a 2d simulation + +
    Self-explanatory. + +
    Cannot use fix wall/srd in periodic dimension + +
    Self-explanatory. + +
    Cannot use fix wall/srd more than once + +
    Nor is their a need to since multiple walls can be specified +in one command. + +
    Cannot use fix wall/srd without fix srd + +
    Self-explanatory. + +
    Cannot use fix wall/srd zlo/zhi for a 2d simulation + +
    Self-explanatory. + +
    Cannot use force/neigh with triclinic box + +
    This is a current limitation of the GPU implementation +in LAMMPS. +
    Cannot use kspace solver on system with no charge
    No atoms in system have a non-zero charge. +
    Cannot use neigh_modify exclude with GPU neighbor builds + +
    This is a current limitation of the GPU implementation +in LAMMPS. +
    Cannot use neighbor bins - box size << cutoff
    Too many neighbor bins will be created. This typically happens when the simulation box is very small in some dimension, compared to the neighbor cutoff. Use the "nsq" style instead of "bin" style. -
    Cannot use newton pair with GPU GayBerne pair style +
    Cannot use newton pair with GPU CHARMM pair style -
    Self-explanatory. +
    See the newton command to change the setting. -
    Cannot use newton pair with GPU lj/cut pair style +
    Cannot use newton pair with GPU Gay-Berne pair style -
    Self-explanatory. +
    See the newton command to change the setting. + +
    Cannot use newton pair with GPU LJ pair style + +
    See the newton command to change the setting. + +
    Cannot use newton pair with GPU LJ96 pair style + +
    See the newton command to change the setting. + +
    Cannot use non-zero forces in an energy minimization + +
    Fix setforce cannot be used in this manner. Use fix addforce +instead.
    Cannot use nonperiodic boundares with fix ttm @@ -1139,9 +1261,9 @@ non-periodic z dimension. unless you use the kspace_modify command to define a 2d slab with a non-periodic z dimension. -
    Cannot use pair hybrid with multiple GPU pair styles +
    Cannot use pair hybrid with GPU neighbor builds -
    Self-explanatory. +
    See documentation for fix gpu.
    Cannot use pair tail corrections with 2d simulations @@ -1160,6 +1282,10 @@ create_box command has been used.
    Atom IDs are not defined, so they cannot be used to identify an atom. +
    Cannot use swiggle in variable formula between runs + +
    This is a function of elapsed time. +
    Cannot use variable energy with constant force in fix addforce
    This is because for constant force, LAMMPS can compute the change @@ -1170,6 +1296,14 @@ in energy directly.
    The format of DCD dump files requires snapshots be output at a constant frequency. +
    Cannot use variable every setting for dump xtc + +
    The format of this file requires snapshots at regular intervals. + +
    Cannot use vdisplace in variable formula between runs + +
    This is a function of elapsed time. +
    Cannot use velocity create loop all unless atoms have IDs
    Atoms in the simulation to do not have IDs, so this style @@ -1201,6 +1335,10 @@ triclinic.
    Self-explanatory. +
    Compute ID for compute atom/molecule does not exist + +
    Self-explanatory. +
    Compute ID for compute reduce does not exist
    Self-explanatory. @@ -1237,6 +1375,46 @@ triclinic.
    The atom style does not support angles. +
    Compute atom/molecule compute array is accessed out-of-range + +
    Self-explanatory. + +
    Compute atom/molecule compute does not calculate a per-atom array + +
    Self-explanatory. + +
    Compute atom/molecule compute does not calculate a per-atom vector + +
    Self-explanatory. + +
    Compute atom/molecule compute does not calculate per-atom values + +
    Self-explanatory. + +
    Compute atom/molecule fix array is accessed out-of-range + +
    Self-explanatory. + +
    Compute atom/molecule fix does not calculate a per-atom array + +
    Self-explanatory. + +
    Compute atom/molecule fix does not calculate a per-atom vector + +
    Self-explanatory. + +
    Compute atom/molecule fix does not calculate per-atom values + +
    Self-explanatory. + +
    Compute atom/molecule requires molecular atom style + +
    Self-explanatory. + +
    Compute atom/molecule variable is not atom-style variable + +
    Self-explanatory. +
    Compute bond/local used when bonds are not allowed
    The atom style does not support bonds. @@ -1246,6 +1424,15 @@ triclinic.
    This is because the computation of the centro-symmetry values uses a pairwise neighbor list. +
    Compute cluster/atom cutoff is longer than pairwise cutoff + +
    Cannot identify clusters beyond cutoff. + +
    Compute cluster/atom requires a pair style be defined + +
    This is so that the pair style defines a cutoff distance which +is used to find clusters. +
    Compute cna/atom cutoff is longer than pairwise cutoff
    Self-explantory. @@ -1339,6 +1526,10 @@ developers.
    Self-explanatory. +
    Compute pair must use group all + +
    Pair styles accumlate energy on all atoms. +
    Compute pe must use group all
    Energies computed by potentials (pair, bond, etc) are computed on all @@ -1468,6 +1659,18 @@ used.
    Self-explanatory. +
    Compute ti kspace style does not exist + +
    Self-explanatory. + +
    Compute ti pair style does not exist + +
    Self-explanatory. + +
    Compute ti tail when pair style does not compute tail corrections + +
    Self-explanatory. +
    Compute used in variable between runs is not current
    Computes cannot be invoked by a variable in between runs. Thus they @@ -1512,6 +1715,10 @@ temperature is 0.0.
    Self-explanatory. +
    Could not find compute ID for TAD + +
    Self-explanatory. +
    Could not find compute ID for temperature bias
    Self-explanatory. @@ -1657,6 +1864,10 @@ does not exist.
    Self-explanatory. +
    Could not find/initialize a specified accelerator device + +
    Your GPU setup is invalid. +
    Could not find set group ID
    Group ID specified in set command does not exist. @@ -1827,7 +2038,7 @@ or the atoms are too far apart to make a valid dihedral. on a particular processor. The pairwise cutoff is too short or the atoms are too far apart to make a valid dihedral. -
    Dihedral atoms %d %d %d %d missing on proc %d at step %d +
    Dihedral atoms %d %d %d %d missing on proc %d at step
    One or more of 4 atoms needed to compute a particular dihedral are missing on this processor. Typically this is because the pairwise @@ -1933,6 +2144,10 @@ model. used. Most likely, one or more atoms have been blown out of the simulation box to a great distance. +
    Double precision is not supported on this accelerator. + +
    In this case, you must compile the GPU library for single precision. +
    Dump cfg and fix not computed at compatible times
    The fix must produce per-atom quantities on timesteps that dump cfg @@ -1942,6 +2157,10 @@ needs them.
    This is a requirement of the CFG output format. +
    Dump cfg requires one snapshot per file + +
    Use the wildcard "*" character in the filename. +
    Dump custom and fix not computed at compatible times
    The fix must produce per-atom quantities on timesteps that dump custom @@ -1996,10 +2215,6 @@ dump output.
    The variable must return a timestep greater than the current timestep. -
    Dump in CFG format requires one snapshot per file - -
    Self-explanatory. -
    Dump local and fix not computed at compatible times
    The fix must produce per-atom quantities on timesteps that dump local @@ -2111,6 +2326,11 @@ dumped.
    Only per-atom quantities that are defined for the atom style being used are allowed. +
    Duplicate particle in PeriDynamic bond - simulation box is too small + +
    This is likely because your box length is shorter than 2 times +the bond length. +
    Electronic temperature dropped below zero
    Something has gone wrong with the fix ttm electron temperature model. @@ -2160,6 +2380,14 @@ smaller simulation or on more processors.
    Self-explanatory. +
    Fix gpu split must be positive for hybrid pair styles. + +
    See documentation for fix gpu. + +
    Fix ID for compute atom/molecule does not exist + +
    Self-explanatory. +
    Fix ID for compute reduce does not exist
    Self-explanatory. @@ -2232,27 +2460,30 @@ conservative settings.
    Reset the ATOMPERBIN parameter at the top of fix_srd.cpp to a larger value, and re-compile the code. -
    Fix adapt atom attribute is not recognized +
    Fix SRD: too many walls in bin -
    Self-explanatory +
    This should not happen unless your system has been setup incorrectly. -
    Fix adapt pair parameter is not recognized +
    Fix adapt kspace style does not exist -
    Self-explanatory +
    Self-explanatory.
    Fix adapt pair style does not exist
    Self-explanatory -
    Fix adapt pair types are not valid +
    Fix adapt pair style param not supported -
    The specified types must be between 1 and Ntypes and be -used by the pair style. +
    The pair style does not know about the parameter you specified.
    Fix adapt requires atom attribute diameter
    The atom style being used does not specify an atom diameter. +
    Fix adapt type pair range is not valid for pair hybrid sub-style + +
    Self-explanatory. +
    Fix ave/atom compute array is accessed out-of-range
    Self-explanatory. @@ -2466,10 +2697,6 @@ all intensive/extensive when turned into an array by fix ave/time.
    Self-explanatory. -
    Fix ave/time compute does not calculate a array - -
    Self-explanatory. -
    Fix ave/time compute does not calculate a scalar
    Only computes that calculate a scalar or vector quantity (not a @@ -2480,6 +2707,10 @@ per-atom quantity) can be used with fix ave/time.
    Only computes that calculate a scalar or vector quantity (not a per-atom quantity) can be used with fix ave/time. +
    Fix ave/time compute does not calculate an array + +
    Self-explanatory. +
    Fix ave/time compute vector is accessed out-of-range
    The index for the vector is out of bounds. @@ -2488,10 +2719,6 @@ per-atom quantity) can be used with fix ave/time.
    Self-explanatory. -
    Fix ave/time fix does not calculate a array - -
    Self-explanatory. -
    Fix ave/time fix does not calculate a scalar
    A fix used by fix ave/time must generate global values. @@ -2500,6 +2727,10 @@ per-atom quantity) can be used with fix ave/time.
    A fix used by fix ave/time must generate global values. +
    Fix ave/time fix does not calculate an array + +
    Self-explanatory. +
    Fix ave/time fix vector is accessed out-of-range
    The index for the vector is out of bounds. @@ -2571,6 +2802,10 @@ is a triclinic (non-orthogonal) box.
    Not all regions represent bounded volumes. You cannot use such a region with the fix deposit command. +
    Fix efield requires atom attribute q + +
    Self-explanatory. +
    Fix evaporate molecule requires atom attribute molecule
    The atom style being used does not define a molecule ID. @@ -2804,6 +3039,14 @@ was exceeded.
    Self-explanatory. +
    Fix rigid atom has non-zero image flag in a non-periodic dimension + +
    You cannot set image flags for non-periodic dimensions. + +
    Fix rigid molecule requires atom attribute molecule + +
    Self-explanatory. +
    Fix rigid/nvt period must be > 0.0
    Self-explanatory @@ -2838,10 +3081,6 @@ it turns off bonds that should contribute to the energy.
    Self-explanatory. -
    Fix srd simulation box must be periodic - -
    Self-explanatory. -
    Fix store/state compute array is accessed out-of-range
    Self-explanatory. @@ -2930,6 +3169,11 @@ details.
    Self-explanatory. +
    Fix used in compute atom/molecule not computed at compatible time + +
    The fix must produce per-atom quantities on timesteps that the compute +needs them. +
    Fix used in compute reduce not computed at compatible time
    Fixes generate their values on specific timesteps. Compute sum is @@ -3008,6 +3252,19 @@ this fix.
    When using a "*" in the restart file name, no matching file was found. +
    GPU is not the first fix for this run + +
    This is the way the fix must be defined in your input script. + +
    GPU library not compiled for this accelerator + +
    The GPU library was not built for your accelerator. Check the arch flag in +lib/gpu. + +
    Gmask function in equal-style variable formula + +
    Gmask is per-atom operation. +
    Gravity changed since fix pour was created
    Gravity must be static and not dynamic for use with fix pour. @@ -3020,6 +3277,10 @@ this fix.
    Gravity must be pointing "down" in a 3d box, i.e. theta = 180.0. +
    Grmask function in equal-style variable formula + +
    Grmask is per-atom operation. +
    Group ID does not exist
    A group ID used in the group command does not exist. @@ -3062,6 +3323,10 @@ invalid.
    The name is too long to be a chemical element. +
    Illegal fix gpu command + +
    Self-explanatory. +
    Illegal number of angle table entries
    There must be at least 2 table entries. @@ -3090,7 +3355,7 @@ or the atoms are too far apart to make a valid improper. on a particular processor. The pairwise cutoff is too short or the atoms are too far apart to make a valid improper. -
    Improper atoms %d %d %d %d missing on proc %d at step %d +
    Improper atoms %d %d %d %d missing on proc %d at step
    One or more of 4 atoms needed to compute a particular improper are missing on this processor. Typically this is because the pairwise @@ -3278,6 +3543,14 @@ simulation box.
    Eigensolve for rigid body was not sufficiently accurate. +
    Insufficient memory on accelerator. + +
    Self-explanatory. + +
    Invalid Boolean syntax in if command + +
    Self-explanatory. +
    Invalid REAX atom type
    There is a mis-match between LAMMPS atom types and the elements @@ -3403,18 +3676,10 @@ types.
    Self-explanatory. Check the fix shake command in the input script. -
    Invalid coeffs for this angle style - -
    Cannot set class 2 coeffs in data file for this angle style. -
    Invalid coeffs for this dihedral style
    Cannot set class 2 coeffs in data file for this dihedral style. -
    Invalid coeffs for this improper style - -
    Cannot set class 2 coeffs in data file for this improper style. -
    Invalid command-line argument
    One or more command-line arguments is invalid. Check the syntax of @@ -3504,6 +3769,10 @@ the command you are using to launch LAMMPS.
    Atom style does not allow dihedrals. +
    Invalid delta_conf in tad command + +
    The value must be between 0 and 1 inclusive. +
    Invalid density in Atoms section of data file
    Density value cannot be <= 0.0. @@ -3707,15 +3976,6 @@ improper types.
    Self-explanatory. -
    Invalid natoms for dump dcd - -
    Natoms is initially 0 which is not valid for the dump dcd style. -Natoms must be constant for the duration of the simulation. - -
    Invalid natoms for dump xtc - -
    Natoms is initially 0 which is not valid for the dump xtc style. -
    Invalid option in lattice command for non-custom style
    Certain lattice keywords are not supported unless the @@ -3752,10 +4012,6 @@ kspace, etc.
    Random number seed must be > 0. -
    Invalid region in group function in variable formula - -
    Self-explanatory. -
    Invalid region style
    The choice of region style is unknown. @@ -3764,6 +4020,19 @@ kspace, etc.
    Self-explanatory. +
    Invalid run command N value + +
    The number of timesteps must fit in a 32-bit integer. If you want to +run for more steps than this, perform multiple shorter runs. + +
    Invalid run command start/stop value + +
    Self-explanatory. + +
    Invalid run command upto value + +
    Self-explanatory. +
    Invalid seed for Marsaglia random # generator
    The initial seed for this random number generator must be a positive @@ -3806,10 +4075,18 @@ integer.
    Self-explanatory. +
    Invalid t_event in tad command + +
    The value must be greater than 0. +
    Invalid thermo keyword in variable formula
    The keyword is not recognized. +
    Invalid tmax in tad command + +
    The value must be greater than 0.0. +
    Invalid type for dipole set
    Dipole command must set a type from 1-N where N is the number of atom @@ -3930,22 +4207,18 @@ sc, bcc, or fcc lattice.
    Self-explanatory. -
    Lost atoms via displace_atoms: original %.15g current %.15g - -
    The displace_atoms command lost one or more atoms. - -
    Lost atoms via displace_box: original %.15g current %.15g - -
    The displace_box command lost one or more atoms. - -
    Lost atoms: original %.15g current %.15g - -
    A thermodynamic computation has detected lost atoms. -
    MEAM library error %d
    A call to the MEAM Fortran library returned an error. +
    MPI_LMP_BIGINT and bigint in lmptype.h are not compatible + +
    The size of the MPI datatype does not match the size of a bigint. + +
    MPI_LMP_TAGINT and tagint in lmptype.h are not compatible + +
    The size of the MPI datatype does not match the size of a tagint. +
    Mass command before simulation box is defined
    The mass command cannot be used before a read_data, read_restart, or @@ -3986,6 +4259,15 @@ values is used in an equal-style variable formula. produces per-atom values is used in an equal-style variable formula. +
    Molecular data file has too many atoms + +
    These kids of data files are currently limited to a number +of atoms that fits in a 32-bit integer. + +
    Molecule count changed in compute atom/molecule + +
    Number of molecules must remain constant over time. +
    Molecule count changed in compute com/molecule
    Number of molecules must remain constant over time. @@ -4142,10 +4424,6 @@ by a fix shake command.
    Self-explanatory. -
    Must use a molecular atom style with fix rigid molecule - -
    Self-explanatory. -
    Must use a z-axis cylinder with fix pour
    The axis of the cylinder region used with the fix pour command must @@ -4160,17 +4438,6 @@ command.
    Self-explanatory. -
    Must use charged atom style with fix efield - -
    The atom style being used does not allow atoms to have assigned -charges. Hence it will not work with this fix which generates a force -due to an E-field acting on charge. - -
    Must use molecular atom style with neigh_modify exclude molecule - -
    The atom style must define a molecule ID to use the exclude -option. -
    Must use pair_style comb with fix qeq/comb
    Self-explanatory. @@ -4197,6 +4464,10 @@ force during minimization.
    The header of the data file indicated that bonds or angles or dihedrals or impropers would be included, but they were not present. +
    Neigh_modify exclude molecule requires atom attribute molecule + +
    Self-explanatory. +
    Neigh_modify include group != atom_modify first group
    Self-explanatory. @@ -4207,12 +4478,20 @@ dihedrals or impropers would be included, but they were not present. inconsistent. If the delay setting is non-zero, then it must be a multiple of the every setting. +
    Neighbor include group not allowed with ghost neighbors + +
    This is a current restriction within LAMMPS. +
    Neighbor list overflow, boost neigh_modify one or page
    There are too many neighbors of a single atom. Use the neigh_modify command to increase the neighbor page size and the max number of neighbors allowed for one atom. +
    Neighbor multi not yet enabled for ghost neighbors + +
    This is a current restriction within LAMMPS. +
    Neighbor multi not yet enabled for granular
    Self-explanatory. @@ -4225,6 +4504,10 @@ neighbors allowed for one atom.
    This is required to prevent wasting too much memory. +
    Neighbors of ghost atoms only allowed for full neighbor lists + +
    This is a current restriction within LAMMPS. +
    New bond exceeded bonds per atom in fix bond/create
    See the read_data command for info on setting the "extra bond per @@ -4299,6 +4582,10 @@ output to dump file.
    The EAM potential file does not contain elements that match the requested elements. +
    No pair hbond/dreiding coefficients set + +
    Self-explanatory. +
    No pair style defined for compute group/group
    Cannot calculate group interactions without a pair style defined. @@ -4334,10 +4621,6 @@ contain the same atom.
    Any rigid body defined by the fix rigid command must contain 2 or more atoms. -
    Out of memory on GPGPU - -
    You are attempting to run with too many atoms on the GPU. -
    Out of range atoms - cannot compute PPPM
    One or more atoms are attempting to map their charge to a PPPM grid @@ -4623,6 +4906,22 @@ does not support them.
    Atoms in the simulation do not have IDs, so history effects cannot be tracked by the granular pair potential. +
    Pair style hbond/dreiding requires an atom map, see atom_modify + +
    Self-explanatory. + +
    Pair style hbond/dreiding requires atom IDs + +
    Self-explanatory. + +
    Pair style hbond/dreiding requires molecular system + +
    Self-explanatory. + +
    Pair style hbond/dreiding requires newton pair on + +
    See the newton command for details. +
    Pair style hybrid cannot have hybrid as an argument
    Self-explanatory. @@ -4749,7 +5048,7 @@ read_restart, or create_box command.
    Particles must be "exterior" to the wall in order for energy/force to be calculated. -
    Particle on or inside fix wall/region surface +
    Particle on or inside surface of region used in fix wall/region
    Particles must be "exterior" to the region surface in order for energy/force to be calculated. @@ -4768,16 +5067,17 @@ variable doc page for ideas on how to make this work.
    Equal-style variables cannot use per-atom quantities. -
    Per-atom virial not available with GPU Gay-Berne - -
    Self-explanatory. -
    Per-atom virial was not tallied on needed timestep
    You are using a thermo keyword that requires potentials to have tallied the virial, but they didn't on this timestep. See the variable doc page for ideas on how to make this work. +
    Per-processor system is too big + +
    The number of owned atoms plus ghost atoms on a single +processor must fit in 32-bit integer. +
    Potential energy ID for fix neb does not exist
    Self-explanatory. @@ -4896,10 +5196,6 @@ library and re-build LAMMPS.
    Self-explanatory. -
    Region ID for compute temp reduce/region does not exist - -
    Self-explanatory. -
    Region ID for compute temp/region does not exist
    Self-explanatory. @@ -4916,6 +5212,10 @@ library and re-build LAMMPS.
    Self-explanatory. +
    Region ID for fix ave/spatial does not exist + +
    Self-explanatory. +
    Region ID for fix aveforce does not exist
    Self-explanatory. @@ -4940,6 +5240,10 @@ library and re-build LAMMPS.
    Self-explanatory. +
    Region ID in variable formula does not exist + +
    Self-explanatory. +
    Region cannot have 0 length rotation vector
    Self-explanatory. @@ -4975,6 +5279,19 @@ or create_box command. to processors. This is likely due to some atom coordinates being outside a non-periodic simulation box. +
    Replicated molecular system atom IDs are too big + +
    See the setting for the allowed atom ID size in the src/lmptype.h +file. + +
    Replicated system is too big + +
    See the setting for bigint in the src/lmptype.h file. + +
    Resetting timestep is not allowed with fix move + +
    This is because fix move is moving atoms based on elapsed time. +
    Respa inner cutoffs are invalid
    The first cutoff must be <= the second cutoff. @@ -5011,6 +5328,10 @@ more non-collinear atoms, even with joint atoms removed. else the rigid fix contribution to the pressure virial is incorrect. +
    Rmask function in equal-style variable formula + +
    Rmask is per-atom operation. +
    Run command before simulation box is defined
    The run command cannot be used before a read_data, read_restart, or @@ -5024,10 +5345,6 @@ create_box command.
    Self-explanatory. -
    Run command upto value is before current timestep - -
    Self-explanatory. -
    Run_style command before simulation box is defined
    The run_style command cannot be used before a read_data, @@ -5041,10 +5358,9 @@ read_restart, or create_box command.
    The bin shape is not within tolerance of cubic. -
    SRD particle %d started inside big particle %d on step %d bounce %d +
    Same dimension twice in fix ave/spatial -
    This may not be a problem, but indicates one or more SRD particles are -being left inside solute particles. +
    Self-explanatory.
    Set command before simulation box is defined @@ -5065,19 +5381,19 @@ or create_box command. command that are the same angle type, must also have the same bond types for the 2 bonds in the angle. -
    Shake atoms %d %d %d %d missing on proc %d at step %d +
    Shake atoms %d %d %d %d missing on proc %d at step
    The 4 atoms in a single shake cluster specified by the fix shake command are not all accessible to a processor. This probably means an atom has moved too far. -
    Shake atoms %d %d %d missing on proc %d at step %d +
    Shake atoms %d %d %d missing on proc %d at step
    The 3 atoms in a single shake cluster specified by the fix shake command are not all accessible to a processor. This probably means an atom has moved too far. -
    Shake atoms %d %d missing on proc %d at step %d +
    Shake atoms %d %d missing on proc %d at step
    The 2 atoms in a single shake cluster specified by the fix shake command are not all accessible to a processor. This probably means @@ -5107,6 +5423,15 @@ SHAKE fix contribution to the pressure virial is incorrect.
    Self-explanatory. +
    Smallint setting in lmptype.h is invalid + +
    It has to be the size of an integer. + +
    Smallint setting in lmptype.h is not compatible + +
    Smallint stored in restart file is not consistent with LAMMPS version +you are running. +
    Sqrt of negative value in variable formula
    Self-explanatory. @@ -5116,6 +5441,14 @@ SHAKE fix contribution to the pressure virial is incorrect.
    Input script line contained a variable that could not be substituted for. +
    System in data file is too big + +
    See the setting for bigint in the src/lmptype.h file. + +
    TAD nsteps must be multiple of t_event + +
    Self-explanatory. +
    TIP4P hydrogen has incorrect atom type
    The TIP4P pairwise computation found an H atom whose type does not @@ -5131,6 +5464,19 @@ within a water molecule.
    The target file for the fix tmd command did not list all atoms in the fix group. +
    Tad command before simulation box is defined + +
    Self-explanatory. + +
    Tagint setting in lmptype.h is invalid + +
    Tagint must be as large or larger than smallint. + +
    Tagint setting in lmptype.h is not compatible + +
    Smallint stored in restart file is not consistent with LAMMPS version +you are running. +
    Target temperature for fix nvt/npt/nph cannot be 0.0
    Self-explanatory. @@ -5320,6 +5666,10 @@ is not computing this quantity.
    Cannot use thermo_modify to set this parameter since the thermo_style is not computing this quantity. +
    Thermo_modify int format does not contain d character + +
    Self-explanatory. +
    Thermo_modify pressure ID does not compute pressure
    The specified compute ID does not compute pressure. @@ -5347,11 +5697,17 @@ not defined by the atom style used in this simulation.
    Specified timestep size is invalid. -
    Too big a problem to replicate with molecular atom style +
    Too big a problem to use velocity create loop all -
    Molecular problems cannot become bigger than 2^31 atoms (or bonds, -etc) when replicated, else the atom IDs and other quantities cannot be -stored in 32-bit quantities. +
    The system size must fit in a 32-bit integer to use this option. + +
    Too big a timestep for dump dcd + +
    The timestep must fit in a 32-bit integer to use this dump style. + +
    Too big a timestep for dump xtc + +
    The timestep must fit in a 32-bit integer to use this dump style.
    Too few bits for lookup table @@ -5363,6 +5719,16 @@ machine's floating point representation.
    This is likely due to an immense simulation box that has blown up to a large size. +
    Too many atoms for dump dcd + +
    The system size must fit in a 32-bit integer to use this dump +style. + +
    Too many atoms for dump xtc + +
    The system size must fit in a 32-bit integer to use this dump +style. +
    Too many atoms to dump sort
    Cannot sort when running with more than 2^31 atoms. @@ -5377,6 +5743,11 @@ machine's floating point representation.
    The maximum number of atom groups (including the "all" group) is given by MAX_GROUP in group.cpp and is 32. +
    Too many iterations + +
    You must use a number of iterations that fit in a 32-bit integer +for minimization. +
    Too many mantissa bits for lookup table
    Table size specified via pair_modify command does not work with your @@ -5392,6 +5763,15 @@ types.
    This is likely due to an immense simulation box that has blown up to a large size. +
    Too many timesteps for NEB + +
    You must use a number of timesteps that fit in a 32-bit integer +for NEB. + +
    Too many total atoms + +
    See the setting for bigint in the src/lmptype.h file. +
    Too many total bits for bitmapped lookup table
    Table size specified via pair_modify command is too large. Note that @@ -5403,6 +5783,11 @@ a value of N generates a 2^N size table. MAXTOUCH parameter in fix_shear_history.cpp must be set larger and LAMMPS must be re-built. +
    Too much per-proc info for dump + +
    Number of local atoms times number of columns must fit in a 32-bit +integer for dump. +
    Tree structure in joint connections
    Fix poems cannot (yet) work with coupled bodies whose joints connect @@ -5427,6 +5812,12 @@ length in that dimension. E.g. the xy tilt must be between -half and
    Self-explanatory. +
    Unable to initialize accelerator for use + +
    One or more specified accelerator(s) cannot currently be used by LAMMPS. +This can happen if the accelerator is already in use by another +process. +
    Unbalanced quotes in input line
    No matching end double quote was found following a leading double @@ -5477,6 +5868,10 @@ valid.
    The lattice type in an entry of the MEAM parameter file is not valid. +
    Unrecognized pair style in compute pair command + +
    Self-explanatory. +
    Use of compute temp/ramp with undefined lattice
    Must use lattice command with compute temp/ramp command if units @@ -5530,11 +5925,6 @@ set to lattice.
    Must use lattice command with fix wall command if units option is set to lattice. -
    Use of fix wall/reflect with undefined lattice - -
    If scale = lattice (the default) for the fix wall/reflect command, -then a lattice must first be defined via the lattice command. -
    Use of region with undefined lattice
    If scale = lattice (the default) for the region command, then a @@ -5564,6 +5954,10 @@ deform needs to be used.
    Cannot evaluate a compute or fix or atom-based value in a variable before the simulation has been setup. +
    Variable for compute ti is invalid style + +
    Self-explanatory. +
    Variable for dump every is invalid style
    Only equal-style variables can be used. @@ -5572,6 +5966,10 @@ before the simulation has been setup.
    Only equal-style variables can be used. +
    Variable for fix addforce is invalid style + +
    Self-explanatory. +
    Variable for fix aveforce is invalid style
    Only equal-style variables can be used. @@ -5596,14 +5994,34 @@ before the simulation has been setup.
    Only equal-style variables can be used. +
    Variable for fix wall is invalid style + +
    Only equal-style variables can be used. +
    Variable for fix wall/reflect is invalid style
    Only equal-style variables can be used. +
    Variable for fix wall/srd is invalid style + +
    Only equal-style variables can be used. + +
    Variable for region is invalid style + +
    Only equal-style variables can be used. + +
    Variable for region is not equal style + +
    Self-explanatory. +
    Variable for thermo every is invalid style
    Only equal-style variables can be used. +
    Variable for velocity set is invalid style + +
    Only atom-style variables can be used. +
    Variable formula compute array is accessed out-of-range
    Self-explanatory. @@ -5620,10 +6038,18 @@ before the simulation has been setup.
    Self-explanatory. +
    Variable name for compute atom/molecule does not exist + +
    Self-explanatory. +
    Variable name for compute reduce does not exist
    Self-explanatory. +
    Variable name for compute ti does not exist + +
    Self-explanatory. +
    Variable name for dump every does not exist
    Self-explanatory. @@ -5680,7 +6106,19 @@ before the simulation has been setup.
    Self-explanatory. -
    Variable name for fix wall/relect does not exist +
    Variable name for fix wall does not exist + +
    Self-explanatory. + +
    Variable name for fix wall/reflect does not exist + +
    Self-explanatory. + +
    Variable name for fix wall/srd does not exist + +
    Self-explanatory. + +
    Variable name for region does not exist
    Self-explanatory. @@ -5688,6 +6126,10 @@ before the simulation has been setup.
    Self-explanatory. +
    Variable name for velocity set does not exist + +
    Self-explanatory. +
    Variable name must be alphanumeric or underscore characters
    Self-explanatory. @@ -5716,6 +6158,23 @@ temperature. have tallied the virial, but they didn't on this timestep. See the variable doc page for ideas on how to make this work. +
    Wall defined twice in fix wall command + +
    Self-explanatory. + +
    Wall defined twice in fix wall/reflect command + +
    Self-explanatory. + +
    Wall defined twice in fix wall/srd command + +
    Self-explanatory. + +
    Weighted neighbor list values are too big + +
    You must have less atoms per processor to use this +style neighbor list. +
    World variable count doesn't match # of partitions
    A world-style variable must specify a number of values equal to the @@ -5751,6 +6210,12 @@ want.
    See the doc page for fix bond/break for more info on this restriction. +
    Building an occasional neighobr list when atoms may have moved too far + +
    This can cause LAMMPS to crash when the neighbor list is built. +The solution is to check for building the regular neighbor lists +more frequently. +
    Compute cna/atom cutoff may be too large to find ghost atom neighbors
    The neighbor cutoff used may not encompass enough ghost atoms @@ -5788,6 +6253,10 @@ will be truncated to attempt to prevent the bond from blowing up.
    A FENE bond has stretched dangerously far. It's interaction strength will be truncated to attempt to prevent the bond from blowing up. +
    Fix SRD walls overlap but fix srd overlap not set + +
    You likely want to set this in your input script. +
    Fix bond/swap will ignore defined angles
    See the doc page for fix bond/swap for more info on this @@ -5814,6 +6283,10 @@ fix recenter should come last.
    This may cause accuracy problems. +
    Fix srd no-slip wall collisions with bin shifting + +
    This is an inconsistent setting in your input script. +
    Fix srd particle moved outside valid domain
    This may indicate a problem with your simulation parameters. @@ -5879,6 +6352,10 @@ on the same group of atoms that velocities are being set for.
    It is not efficient to use compute centro/atom more than once. +
    More than one compute cluster/atom + +
    It is not efficient to use compute cluster/atom more than once. +
    More than one compute cna/atom defined
    It is not efficient to use compute cna/atom more than once. @@ -5988,6 +6465,13 @@ every = 1, check = yes. Since these settings were not in place, LAMMPS changed them and will restore them to their original values after the PRD simulation. +
    Resetting reneighboring criteria during TAD + +
    A TAD simulation requires that neigh_modify settings be delay = 0, +every = 1, check = yes. Since these settings were not in place, +LAMMPS changed them and will restore them to their original values +after the PRD simulation. +
    Resetting reneighboring criteria during minimization
    Minimization requires that neigh_modify settings be delay = 0, every = diff --git a/doc/Section_errors.txt b/doc/Section_errors.txt index 8706782413..9c44470ab6 100644 --- a/doc/Section_errors.txt +++ b/doc/Section_errors.txt @@ -8,18 +8,19 @@ Section"_Section_history.html :c :line -10. Errors :h3 +12. Errors :h3 -This section describes the various kinds of errors you can encounter -when using LAMMPS. +This section describes the errors you can encounter when using LAMMPS, +either conceptually, or as printed out by the program. -10.1 "Common problems"_#10_1 -10.2 "Reporting bugs"_#10_2 -10.3 "Error & warning messages"_#10_3 :all(b) +12.1 "Common problems"_#err_1 +12.2 "Reporting bugs"_#err_2 +12.3 "Error & warning messages"_#err_3 :all(b) +:line :line -10.1 Common problems :link(10_1),h4 +12.1 Common problems :link(err_1),h4 If two LAMMPS runs do not produce the same answer on different machines or different numbers of processors, this is typically not a @@ -78,7 +79,7 @@ decide if the WARNING is important or not. A WARNING message that is generated in the middle of a run is only printed to the screen, not to the logfile, to avoid cluttering up thermodynamic output. If LAMMPS crashes or hangs without spitting out an error message first then it -could be a bug (see "this section"_#10_2) or one of the following +could be a bug (see "this section"_#err_2) or one of the following cases: LAMMPS runs in the available memory a processor allows to be @@ -109,7 +110,7 @@ buffering or boost the sizes of messages that can be buffered. :line -10.2 Reporting bugs :link(10_2),h4 +12.2 Reporting bugs :link(err_2),h4 If you are confident that you have found a bug in LAMMPS, follow these steps. @@ -139,18 +140,22 @@ As a last resort, you can send an email directly to the :line -10.3 Error & warning messages :h4,link(10_3) +12.3 Error & warning messages :h4,link(err_3) These are two alphabetic lists of the "ERROR"_#error and "WARNING"_#warn messages LAMMPS prints out and the reason why. If the explanation here is not sufficient, the documentation for the -offending command may help. Grepping the source files for the text of -the error message and staring at the source code and comments is also -not a bad idea! Note that sometimes the same message can be printed -from multiple places in the code. +offending command may help. +Error and warning messages also list the source file and line number +where the error was generated. For example, this message -Also note that error messages from "user-contributed -packages"_Section_start.html#2_3 are not listed here. Is such an +ERROR: Illegal velocity command (velocity.cpp:78) + +means that line #78 in the file src/velocity.cpp generated the error. +Looking in the source code may help you figure out what went wrong. + +Note that error messages from "user-contributed +packages"_Section_start.html#start_3 are not listed here. If such an error occurs and is not self-explanatory, you'll need to look in the source code or contact the author of the package. @@ -170,6 +175,16 @@ An inconsistency was detected when computing the number of 1-4 neighbors for each atom. This likely means something is wrong with the bond topologies you have defined. :dd +{Accelerated style in input script but no fix gpu} :dt + +GPU acceleration requires fix gpu in the input script. :dd + +{Accelerator sharing is not currently supported on system.} :dt + +You cannot use more MPI processes than accelerators on the +system as currently configured. For NVIDIA GPUs, the compute +mode must be changed using nvidia-smi to support sharing. :dd + {All angle coeffs are not set} :dt All angle coefficients must be set in the data file or by the @@ -233,7 +248,7 @@ The set command cannot find one or more atoms in a particular angle on a particular processor. The pairwise cutoff is too short or the atoms are too far apart to make a valid angle. :dd -{Angle atoms %d %d %d missing on proc %d at step %d} :dt +{Angle atoms %d %d %d missing on proc %d at step} :dt One or more of 3 atoms needed to compute a particular angle are missing on this processor. Typically this is because the pairwise @@ -316,14 +331,6 @@ Argument of arccos() must be between -1 and 1. :dd Argument of arcsin() must be between -1 and 1. :dd -{At least 1 proc could not allocate a CUDA gpu or memory} :dt - -You are not setup correctly to use a GPU from your CPU. :dd - -{At least one process could not allocate a CUDA-enabled gpu} :dt - -Self-explanatory. :dd - {Atom IDs must be consecutive for velocity create loop all} :dt Self-explanatory. :dd @@ -403,6 +410,14 @@ Cannot rescale a temperature that is already 0.0. :dd Two atoms in a FENE bond have become so far apart that the bond cannot be computed. :dd +{Bad TIP4P angle type for PPPM/TIP4P} :dt + +Specified angle type is not valid. :dd + +{Bad TIP4P bond type for PPPM/TIP4P} :dt + +Specified bond type is not valid. :dd + {Bad grid of processors} :dt The 3d grid of processors defined by the processors command does not @@ -434,6 +449,15 @@ compute. :dd Big particles must be extended spheriods or ellipsoids. :dd +{Bigint setting in lmptype.h is invalid} :dt + +Size of bigint is less than size of tagint. :dd + +{Bigint setting in lmptype.h is not compatible} :dt + +Bigint stored in restart file is not consistent with LAMMPS version +you are running. :dd + {Bitmapped lookup tables require int/float be same size} :dt Cannot use pair tables on this machine, because of word sizes. Use @@ -465,7 +489,7 @@ The set command cannot find one or more atoms in a particular bond on a particular processor. The pairwise cutoff is too short or the atoms are too far apart to make a valid bond. :dd -{Bond atoms %d %d missing on proc %d at step %d} :dt +{Bond atoms %d %d missing on proc %d at step} :dt One or both of 2 atoms needed to compute a particular bond are missing on this processor. Typically this is because the pairwise @@ -572,10 +596,18 @@ See the region prism command for details. :dd This is current restriction for NEB as implemented in LAMMPS. :dd +{Can only use TAD with 1-processor replicas for NEB} :dt + +This is current restriction for NEB as implemented in LAMMPS. :dd + {Cannot (yet) use PPPM with triclinic box} :dt This feature is not yet supported. :dd +{Cannot add atoms to fix move variable} :dt + +Atoms can not be added afterwards to this fix option. :dd + {Cannot change box to orthogonal when tilt is non-zero} :dt Self-explanatory :dd @@ -622,6 +654,11 @@ but the atoms that have been defined have no IDs. :dd Must use the lattice command before using the create_atoms command. :dd +{Cannot create/grow a vector/array of pointers for %s} :dt + +LAMMPS code is making an illegal call to the templated memory +allocaters, to create a vector or array of pointers. :dd + {Cannot create_atoms after reading restart file with per-atom info} :dt The per-atom info was stored to be used when by a fix that you @@ -633,6 +670,10 @@ there will not be a correct amount of per-atom info. :dd The create_box command cannot be used after a read_data, read_restart, or create_box command. :dd +{Cannot currently use pair reax with pair hybrid} :dt + +This is not yet supported. :dd + {Cannot delete group all} :dt Self-explanatory. :dd @@ -901,10 +942,6 @@ In the rRESPA integrator, you must compute pairwise potentials either all together (pair), or in pieces (inner/middle/outer). You can't do both. :dd -{Cannot set both vel and wiggle in fix wall command} :dt - -Self-explantory. :dd - {Cannot set dipole for this atom style} :dt This atom style does not support dipole settings for each atom type. :dd @@ -918,6 +955,14 @@ Self-explanatory. :dd This atom style does not support mass settings for each atom type. Instead they are defined on a per-atom basis in the data file. :dd +{Cannot set non-zero image flag for non-periodic dimension} :dt + +Self-explanatory. :dd + +{Cannot set non-zero z velocity for 2d simulation} :dt + +Self-explanatory. :dd + {Cannot set respa middle without inner/outer} :dt In the rRESPA integrator, you must define both a inner and outer @@ -931,6 +976,10 @@ The atom style does not support this setting. :dd The attribute being set does not exist for the defined atom style. :dd +{Cannot set variable z velocity for 2d simulation} :dt + +Self-explanatory. :dd + {Cannot skew triclinic box in z for 2d simulation} :dt Self-explanatory. :dd @@ -978,6 +1027,18 @@ which is enabled by default, via the atom_modify command. :dd Use the atom_modify command to create an atom map. :dd +{Cannot use TAD unless atom map exists for NEB} :dt + +See atom_modify map command to set this. :dd + +{Cannot use TAD with a single replica for NEB} :dt + +NEB requires multiple replicas. :dd + +{Cannot use TAD with atom_modify sort enabled for NEB} :dt + +This is a current restriction of NEB. :dd + {Cannot use a damped dynamics min style with fix box/relax} :dt This is a current restriction in LAMMPS. Use another minimizer @@ -988,6 +1049,14 @@ style. :dd This is a current restriction in LAMMPS. Use another minimizer style. :dd +{Cannot use compute cluster/atom unless atoms have IDs} :dt + +Atom IDs are used to identify clusters. :dd + +{Cannot use cwiggle in variable formula between runs} :dt + +This is a function of elapsed time. :dd + {Cannot use delete_atoms unless atoms have IDs} :dt Your atoms do not have IDs, so the delete_atoms command cannot be @@ -1004,6 +1073,10 @@ provided by an atom map. An atom map does not exist (by default) for non-molecular problems. Using the atom_modify map command will force an atom map to be created. :dd +{Cannot use fix ave/spatial z for 2 dimensional model} :dt + +Self-explanatory. :dd + {Cannot use fix bond/break with non-molecular systems} :dt Self-explanatory. :dd @@ -1102,23 +1175,71 @@ Self-explanatory. :dd Self-explanatory. :dd +{Cannot use fix wall/reflect in periodic dimension} :dt + +Self-explanatory. :dd + +{Cannot use fix wall/reflect zlo/zhi for a 2d simulation} :dt + +Self-explanatory. :dd + +{Cannot use fix wall/srd in periodic dimension} :dt + +Self-explanatory. :dd + +{Cannot use fix wall/srd more than once} :dt + +Nor is their a need to since multiple walls can be specified +in one command. :dd + +{Cannot use fix wall/srd without fix srd} :dt + +Self-explanatory. :dd + +{Cannot use fix wall/srd zlo/zhi for a 2d simulation} :dt + +Self-explanatory. :dd + +{Cannot use force/neigh with triclinic box} :dt + +This is a current limitation of the GPU implementation +in LAMMPS. :dd + {Cannot use kspace solver on system with no charge} :dt No atoms in system have a non-zero charge. :dd +{Cannot use neigh_modify exclude with GPU neighbor builds} :dt + +This is a current limitation of the GPU implementation +in LAMMPS. :dd + {Cannot use neighbor bins - box size << cutoff} :dt Too many neighbor bins will be created. This typically happens when the simulation box is very small in some dimension, compared to the neighbor cutoff. Use the "nsq" style instead of "bin" style. :dd -{Cannot use newton pair with GPU GayBerne pair style} :dt +{Cannot use newton pair with GPU CHARMM pair style} :dt -Self-explanatory. :dd +See the newton command to change the setting. :dd -{Cannot use newton pair with GPU lj/cut pair style} :dt +{Cannot use newton pair with GPU Gay-Berne pair style} :dt -Self-explanatory. :dd +See the newton command to change the setting. :dd + +{Cannot use newton pair with GPU LJ pair style} :dt + +See the newton command to change the setting. :dd + +{Cannot use newton pair with GPU LJ96 pair style} :dt + +See the newton command to change the setting. :dd + +{Cannot use non-zero forces in an energy minimization} :dt + +Fix setforce cannot be used in this manner. Use fix addforce +instead. :dd {Cannot use nonperiodic boundares with fix ttm} :dt @@ -1136,9 +1257,9 @@ For kspace style pppm, all 3 dimensions must have periodic boundaries unless you use the kspace_modify command to define a 2d slab with a non-periodic z dimension. :dd -{Cannot use pair hybrid with multiple GPU pair styles} :dt +{Cannot use pair hybrid with GPU neighbor builds} :dt -Self-explanatory. :dd +See documentation for fix gpu. :dd {Cannot use pair tail corrections with 2d simulations} :dt @@ -1157,6 +1278,10 @@ create_box command has been used. :dd Atom IDs are not defined, so they cannot be used to identify an atom. :dd +{Cannot use swiggle in variable formula between runs} :dt + +This is a function of elapsed time. :dd + {Cannot use variable energy with constant force in fix addforce} :dt This is because for constant force, LAMMPS can compute the change @@ -1167,6 +1292,14 @@ in energy directly. :dd The format of DCD dump files requires snapshots be output at a constant frequency. :dd +{Cannot use variable every setting for dump xtc} :dt + +The format of this file requires snapshots at regular intervals. :dd + +{Cannot use vdisplace in variable formula between runs} :dt + +This is a function of elapsed time. :dd + {Cannot use velocity create loop all unless atoms have IDs} :dt Atoms in the simulation to do not have IDs, so this style @@ -1198,6 +1331,10 @@ triclinic. :dd Self-explanatory. :dd +{Compute ID for compute atom/molecule does not exist} :dt + +Self-explanatory. :dd + {Compute ID for compute reduce does not exist} :dt Self-explanatory. :dd @@ -1234,6 +1371,46 @@ Self-explanatory. :dd The atom style does not support angles. :dd +{Compute atom/molecule compute array is accessed out-of-range} :dt + +Self-explanatory. :dd + +{Compute atom/molecule compute does not calculate a per-atom array} :dt + +Self-explanatory. :dd + +{Compute atom/molecule compute does not calculate a per-atom vector} :dt + +Self-explanatory. :dd + +{Compute atom/molecule compute does not calculate per-atom values} :dt + +Self-explanatory. :dd + +{Compute atom/molecule fix array is accessed out-of-range} :dt + +Self-explanatory. :dd + +{Compute atom/molecule fix does not calculate a per-atom array} :dt + +Self-explanatory. :dd + +{Compute atom/molecule fix does not calculate a per-atom vector} :dt + +Self-explanatory. :dd + +{Compute atom/molecule fix does not calculate per-atom values} :dt + +Self-explanatory. :dd + +{Compute atom/molecule requires molecular atom style} :dt + +Self-explanatory. :dd + +{Compute atom/molecule variable is not atom-style variable} :dt + +Self-explanatory. :dd + {Compute bond/local used when bonds are not allowed} :dt The atom style does not support bonds. :dd @@ -1243,6 +1420,15 @@ The atom style does not support bonds. :dd This is because the computation of the centro-symmetry values uses a pairwise neighbor list. :dd +{Compute cluster/atom cutoff is longer than pairwise cutoff} :dt + +Cannot identify clusters beyond cutoff. :dd + +{Compute cluster/atom requires a pair style be defined} :dt + +This is so that the pair style defines a cutoff distance which +is used to find clusters. :dd + {Compute cna/atom cutoff is longer than pairwise cutoff} :dt Self-explantory. :dd @@ -1336,6 +1522,10 @@ The atom style does not support impropers. :dd Self-explanatory. :dd +{Compute pair must use group all} :dt + +Pair styles accumlate energy on all atoms. :dd + {Compute pe must use group all} :dt Energies computed by potentials (pair, bond, etc) are computed on all @@ -1465,6 +1655,18 @@ An atom style that defines these attributes must be used. :dd Self-explanatory. :dd +{Compute ti kspace style does not exist} :dt + +Self-explanatory. :dd + +{Compute ti pair style does not exist} :dt + +Self-explanatory. :dd + +{Compute ti tail when pair style does not compute tail corrections} :dt + +Self-explanatory. :dd + {Compute used in variable between runs is not current} :dt Computes cannot be invoked by a variable in between runs. Thus they @@ -1509,6 +1711,10 @@ Self-explanatory. :dd Self-explanatory. :dd +{Could not find compute ID for TAD} :dt + +Self-explanatory. :dd + {Could not find compute ID for temperature bias} :dt Self-explanatory. :dd @@ -1654,6 +1860,10 @@ The compute ID for computing temperature does not exist. :dd Self-explanatory. :dd +{Could not find/initialize a specified accelerator device} :dt + +Your GPU setup is invalid. :dd + {Could not find set group ID} :dt Group ID specified in set command does not exist. :dd @@ -1824,7 +2034,7 @@ The set command cannot find one or more atoms in a particular dihedral on a particular processor. The pairwise cutoff is too short or the atoms are too far apart to make a valid dihedral. :dd -{Dihedral atoms %d %d %d %d missing on proc %d at step %d} :dt +{Dihedral atoms %d %d %d %d missing on proc %d at step} :dt One or more of 4 atoms needed to compute a particular dihedral are missing on this processor. Typically this is because the pairwise @@ -1930,6 +2140,10 @@ The domain has become extremely large so that neighbor bins cannot be used. Most likely, one or more atoms have been blown out of the simulation box to a great distance. :dd +{Double precision is not supported on this accelerator.} :dt + +In this case, you must compile the GPU library for single precision. :dd + {Dump cfg and fix not computed at compatible times} :dt The fix must produce per-atom quantities on timesteps that dump cfg @@ -1939,6 +2153,10 @@ needs them. :dd This is a requirement of the CFG output format. :dd +{Dump cfg requires one snapshot per file} :dt + +Use the wildcard "*" character in the filename. :dd + {Dump custom and fix not computed at compatible times} :dt The fix must produce per-atom quantities on timesteps that dump custom @@ -1993,10 +2211,6 @@ Use the dump_modify sort command to enable this. :dd The variable must return a timestep greater than the current timestep. :dd -{Dump in CFG format requires one snapshot per file} :dt - -Self-explanatory. :dd - {Dump local and fix not computed at compatible times} :dt The fix must produce per-atom quantities on timesteps that dump local @@ -2108,6 +2322,11 @@ dumped. :dd Only per-atom quantities that are defined for the atom style being used are allowed. :dd +{Duplicate particle in PeriDynamic bond - simulation box is too small} :dt + +This is likely because your box length is shorter than 2 times +the bond length. :dd + {Electronic temperature dropped below zero} :dt Something has gone wrong with the fix ttm electron temperature model. :dd @@ -2157,6 +2376,14 @@ This is not allowed. Make your SRD bin size smaller. :dd Self-explanatory. :dd +{Fix gpu split must be positive for hybrid pair styles.} :dt + +See documentation for fix gpu. :dd + +{Fix ID for compute atom/molecule does not exist} :dt + +Self-explanatory. :dd + {Fix ID for compute reduce does not exist} :dt Self-explanatory. :dd @@ -2229,27 +2456,30 @@ conservative settings. :dd Reset the ATOMPERBIN parameter at the top of fix_srd.cpp to a larger value, and re-compile the code. :dd -{Fix adapt atom attribute is not recognized} :dt +{Fix SRD: too many walls in bin} :dt -Self-explanatory :dd +This should not happen unless your system has been setup incorrectly. :dd -{Fix adapt pair parameter is not recognized} :dt +{Fix adapt kspace style does not exist} :dt -Self-explanatory :dd +Self-explanatory. :dd {Fix adapt pair style does not exist} :dt Self-explanatory :dd -{Fix adapt pair types are not valid} :dt +{Fix adapt pair style param not supported} :dt -The specified types must be between 1 and Ntypes and be -used by the pair style. :dd +The pair style does not know about the parameter you specified. :dd {Fix adapt requires atom attribute diameter} :dt The atom style being used does not specify an atom diameter. :dd +{Fix adapt type pair range is not valid for pair hybrid sub-style} :dt + +Self-explanatory. :dd + {Fix ave/atom compute array is accessed out-of-range} :dt Self-explanatory. :dd @@ -2463,10 +2693,6 @@ Self-explanatory. :dd Self-explanatory. :dd -{Fix ave/time compute does not calculate a array} :dt - -Self-explanatory. :dd - {Fix ave/time compute does not calculate a scalar} :dt Only computes that calculate a scalar or vector quantity (not a @@ -2477,6 +2703,10 @@ per-atom quantity) can be used with fix ave/time. :dd Only computes that calculate a scalar or vector quantity (not a per-atom quantity) can be used with fix ave/time. :dd +{Fix ave/time compute does not calculate an array} :dt + +Self-explanatory. :dd + {Fix ave/time compute vector is accessed out-of-range} :dt The index for the vector is out of bounds. :dd @@ -2485,10 +2715,6 @@ The index for the vector is out of bounds. :dd Self-explanatory. :dd -{Fix ave/time fix does not calculate a array} :dt - -Self-explanatory. :dd - {Fix ave/time fix does not calculate a scalar} :dt A fix used by fix ave/time must generate global values. :dd @@ -2497,6 +2723,10 @@ A fix used by fix ave/time must generate global values. :dd A fix used by fix ave/time must generate global values. :dd +{Fix ave/time fix does not calculate an array} :dt + +Self-explanatory. :dd + {Fix ave/time fix vector is accessed out-of-range} :dt The index for the vector is out of bounds. :dd @@ -2568,6 +2798,10 @@ Only static regions can be used with fix deposit. :dd Not all regions represent bounded volumes. You cannot use such a region with the fix deposit command. :dd +{Fix efield requires atom attribute q} :dt + +Self-explanatory. :dd + {Fix evaporate molecule requires atom attribute molecule} :dt The atom style being used does not define a molecule ID. :dd @@ -2801,6 +3035,14 @@ was exceeded. :dd Self-explanatory. :dd +{Fix rigid atom has non-zero image flag in a non-periodic dimension} :dt + +You cannot set image flags for non-periodic dimensions. :dd + +{Fix rigid molecule requires atom attribute molecule} :dt + +Self-explanatory. :dd + {Fix rigid/nvt period must be > 0.0} :dt Self-explanatory :dd @@ -2835,10 +3077,6 @@ Use the communicate vel yes command to enable this. :dd Self-explanatory. :dd -{Fix srd simulation box must be periodic} :dt - -Self-explanatory. :dd - {Fix store/state compute array is accessed out-of-range} :dt Self-explanatory. :dd @@ -2927,6 +3165,11 @@ Self-explanatory. :dd Self-explanatory. :dd +{Fix used in compute atom/molecule not computed at compatible time} :dt + +The fix must produce per-atom quantities on timesteps that the compute +needs them. :dd + {Fix used in compute reduce not computed at compatible time} :dt Fixes generate their values on specific timesteps. Compute sum is @@ -3005,6 +3248,19 @@ The compute ID assigned to the fix must compute temperature. :dd When using a "*" in the restart file name, no matching file was found. :dd +{GPU is not the first fix for this run} :dt + +This is the way the fix must be defined in your input script. :dd + +{GPU library not compiled for this accelerator} :dt + +The GPU library was not built for your accelerator. Check the arch flag in +lib/gpu. :dd + +{Gmask function in equal-style variable formula} :dt + +Gmask is per-atom operation. :dd + {Gravity changed since fix pour was created} :dt Gravity must be static and not dynamic for use with fix pour. :dd @@ -3017,6 +3273,10 @@ Gravity must be pointing "down" in a 2d box. :dd Gravity must be pointing "down" in a 3d box, i.e. theta = 180.0. :dd +{Grmask function in equal-style variable formula} :dt + +Grmask is per-atom operation. :dd + {Group ID does not exist} :dt A group ID used in the group command does not exist. :dd @@ -3059,6 +3319,10 @@ invalid. :dd The name is too long to be a chemical element. :dd +{Illegal fix gpu command} :dt + +Self-explanatory. :dd + {Illegal number of angle table entries} :dt There must be at least 2 table entries. :dd @@ -3087,7 +3351,7 @@ The set command cannot find one or more atoms in a particular improper on a particular processor. The pairwise cutoff is too short or the atoms are too far apart to make a valid improper. :dd -{Improper atoms %d %d %d %d missing on proc %d at step %d} :dt +{Improper atoms %d %d %d %d missing on proc %d at step} :dt One or more of 4 atoms needed to compute a particular improper are missing on this processor. Typically this is because the pairwise @@ -3275,6 +3539,14 @@ Eigensolve for rigid body was not sufficiently accurate. :dd Eigensolve for rigid body was not sufficiently accurate. :dd +{Insufficient memory on accelerator. } :dt + +Self-explanatory. :dd + +{Invalid Boolean syntax in if command} :dt + +Self-explanatory. :dd + {Invalid REAX atom type} :dt There is a mis-match between LAMMPS atom types and the elements @@ -3400,18 +3672,10 @@ Self-explanatory. :dd Self-explanatory. Check the fix shake command in the input script. :dd -{Invalid coeffs for this angle style} :dt - -Cannot set class 2 coeffs in data file for this angle style. :dd - {Invalid coeffs for this dihedral style} :dt Cannot set class 2 coeffs in data file for this dihedral style. :dd -{Invalid coeffs for this improper style} :dt - -Cannot set class 2 coeffs in data file for this improper style. :dd - {Invalid command-line argument} :dt One or more command-line arguments is invalid. Check the syntax of @@ -3501,6 +3765,10 @@ Atom style does not allow impropers. :dd Atom style does not allow dihedrals. :dd +{Invalid delta_conf in tad command} :dt + +The value must be between 0 and 1 inclusive. :dd + {Invalid density in Atoms section of data file} :dt Density value cannot be <= 0.0. :dd @@ -3704,15 +3972,6 @@ Self-explanatory. :dd Self-explanatory. :dd -{Invalid natoms for dump dcd} :dt - -Natoms is initially 0 which is not valid for the dump dcd style. -Natoms must be constant for the duration of the simulation. :dd - -{Invalid natoms for dump xtc} :dt - -Natoms is initially 0 which is not valid for the dump xtc style. :dd - {Invalid option in lattice command for non-custom style} :dt Certain lattice keywords are not supported unless the @@ -3749,10 +4008,6 @@ Random number seed must be > 0. :dd Random number seed must be > 0. :dd -{Invalid region in group function in variable formula} :dt - -Self-explanatory. :dd - {Invalid region style} :dt The choice of region style is unknown. :dd @@ -3761,6 +4016,19 @@ The choice of region style is unknown. :dd Self-explanatory. :dd +{Invalid run command N value} :dt + +The number of timesteps must fit in a 32-bit integer. If you want to +run for more steps than this, perform multiple shorter runs. :dd + +{Invalid run command start/stop value} :dt + +Self-explanatory. :dd + +{Invalid run command upto value} :dt + +Self-explanatory. :dd + {Invalid seed for Marsaglia random # generator} :dt The initial seed for this random number generator must be a positive @@ -3803,10 +4071,18 @@ Self-explanatory. :dd Self-explanatory. :dd +{Invalid t_event in tad command} :dt + +The value must be greater than 0. :dd + {Invalid thermo keyword in variable formula} :dt The keyword is not recognized. :dd +{Invalid tmax in tad command} :dt + +The value must be greater than 0.0. :dd + {Invalid type for dipole set} :dt Dipole command must set a type from 1-N where N is the number of atom @@ -3927,22 +4203,18 @@ sc, bcc, or fcc lattice. :dd Self-explanatory. :dd -{Lost atoms via displace_atoms: original %.15g current %.15g} :dt - -The displace_atoms command lost one or more atoms. :dd - -{Lost atoms via displace_box: original %.15g current %.15g} :dt - -The displace_box command lost one or more atoms. :dd - -{Lost atoms: original %.15g current %.15g} :dt - -A thermodynamic computation has detected lost atoms. :dd - {MEAM library error %d} :dt A call to the MEAM Fortran library returned an error. :dd +{MPI_LMP_BIGINT and bigint in lmptype.h are not compatible} :dt + +The size of the MPI datatype does not match the size of a bigint. :dd + +{MPI_LMP_TAGINT and tagint in lmptype.h are not compatible} :dt + +The size of the MPI datatype does not match the size of a tagint. :dd + {Mass command before simulation box is defined} :dt The mass command cannot be used before a read_data, read_restart, or @@ -3983,6 +4255,15 @@ A variable is referenced incorrectly or an atom-style variable that produces per-atom values is used in an equal-style variable formula. :dd +{Molecular data file has too many atoms} :dt + +These kids of data files are currently limited to a number +of atoms that fits in a 32-bit integer. :dd + +{Molecule count changed in compute atom/molecule} :dt + +Number of molecules must remain constant over time. :dd + {Molecule count changed in compute com/molecule} :dt Number of molecules must remain constant over time. :dd @@ -4139,10 +4420,6 @@ by a fix shake command. :dd Self-explanatory. :dd -{Must use a molecular atom style with fix rigid molecule} :dt - -Self-explanatory. :dd - {Must use a z-axis cylinder with fix pour} :dt The axis of the cylinder region used with the fix pour command must @@ -4157,17 +4434,6 @@ command. :dd Self-explanatory. :dd -{Must use charged atom style with fix efield} :dt - -The atom style being used does not allow atoms to have assigned -charges. Hence it will not work with this fix which generates a force -due to an E-field acting on charge. :dd - -{Must use molecular atom style with neigh_modify exclude molecule} :dt - -The atom style must define a molecule ID to use the exclude -option. :dd - {Must use pair_style comb with fix qeq/comb} :dt Self-explanatory. :dd @@ -4194,6 +4460,10 @@ Self-explanatory. :dd The header of the data file indicated that bonds or angles or dihedrals or impropers would be included, but they were not present. :dd +{Neigh_modify exclude molecule requires atom attribute molecule} :dt + +Self-explanatory. :dd + {Neigh_modify include group != atom_modify first group} :dt Self-explanatory. :dd @@ -4204,12 +4474,20 @@ The delay and every parameters set via the neigh_modify command are inconsistent. If the delay setting is non-zero, then it must be a multiple of the every setting. :dd +{Neighbor include group not allowed with ghost neighbors} :dt + +This is a current restriction within LAMMPS. :dd + {Neighbor list overflow, boost neigh_modify one or page} :dt There are too many neighbors of a single atom. Use the neigh_modify command to increase the neighbor page size and the max number of neighbors allowed for one atom. :dd +{Neighbor multi not yet enabled for ghost neighbors} :dt + +This is a current restriction within LAMMPS. :dd + {Neighbor multi not yet enabled for granular} :dt Self-explanatory. :dd @@ -4222,6 +4500,10 @@ Self-explanatory. :dd This is required to prevent wasting too much memory. :dd +{Neighbors of ghost atoms only allowed for full neighbor lists} :dt + +This is a current restriction within LAMMPS. :dd + {New bond exceeded bonds per atom in fix bond/create} :dt See the read_data command for info on setting the "extra bond per @@ -4296,6 +4578,10 @@ Self-explanatory. Check data file. :dd The EAM potential file does not contain elements that match the requested elements. :dd +{No pair hbond/dreiding coefficients set} :dt + +Self-explanatory. :dd + {No pair style defined for compute group/group} :dt Cannot calculate group interactions without a pair style defined. :dd @@ -4331,10 +4617,6 @@ contain the same atom. :dd Any rigid body defined by the fix rigid command must contain 2 or more atoms. :dd -{Out of memory on GPGPU} :dt - -You are attempting to run with too many atoms on the GPU. :dd - {Out of range atoms - cannot compute PPPM} :dt One or more atoms are attempting to map their charge to a PPPM grid @@ -4620,6 +4902,22 @@ does not support them. :dd Atoms in the simulation do not have IDs, so history effects cannot be tracked by the granular pair potential. :dd +{Pair style hbond/dreiding requires an atom map, see atom_modify} :dt + +Self-explanatory. :dd + +{Pair style hbond/dreiding requires atom IDs} :dt + +Self-explanatory. :dd + +{Pair style hbond/dreiding requires molecular system} :dt + +Self-explanatory. :dd + +{Pair style hbond/dreiding requires newton pair on} :dt + +See the newton command for details. :dd + {Pair style hybrid cannot have hybrid as an argument} :dt Self-explanatory. :dd @@ -4746,7 +5044,7 @@ Self-explanatory. :dd Particles must be "exterior" to the wall in order for energy/force to be calculated. :dd -{Particle on or inside fix wall/region surface} :dt +{Particle on or inside surface of region used in fix wall/region} :dt Particles must be "exterior" to the region surface in order for energy/force to be calculated. :dd @@ -4765,16 +5063,17 @@ variable doc page for ideas on how to make this work. :dd Equal-style variables cannot use per-atom quantities. :dd -{Per-atom virial not available with GPU Gay-Berne} :dt - -Self-explanatory. :dd - {Per-atom virial was not tallied on needed timestep} :dt You are using a thermo keyword that requires potentials to have tallied the virial, but they didn't on this timestep. See the variable doc page for ideas on how to make this work. :dd +{Per-processor system is too big} :dt + +The number of owned atoms plus ghost atoms on a single +processor must fit in 32-bit integer. :dd + {Potential energy ID for fix neb does not exist} :dt Self-explanatory. :dd @@ -4893,10 +5192,6 @@ library and re-build LAMMPS. :dd Self-explanatory. :dd -{Region ID for compute temp reduce/region does not exist} :dt - -Self-explanatory. :dd - {Region ID for compute temp/region does not exist} :dt Self-explanatory. :dd @@ -4913,6 +5208,10 @@ Self-explanatory. :dd Self-explanatory. :dd +{Region ID for fix ave/spatial does not exist} :dt + +Self-explanatory. :dd + {Region ID for fix aveforce does not exist} :dt Self-explanatory. :dd @@ -4937,6 +5236,10 @@ Self-explanatory. :dd Self-explanatory. :dd +{Region ID in variable formula does not exist} :dt + +Self-explanatory. :dd + {Region cannot have 0 length rotation vector} :dt Self-explanatory. :dd @@ -4972,6 +5275,19 @@ Atoms replicated by the replicate command were not assigned correctly to processors. This is likely due to some atom coordinates being outside a non-periodic simulation box. :dd +{Replicated molecular system atom IDs are too big} :dt + +See the setting for the allowed atom ID size in the src/lmptype.h +file. :dd + +{Replicated system is too big} :dt + +See the setting for bigint in the src/lmptype.h file. :dd + +{Resetting timestep is not allowed with fix move} :dt + +This is because fix move is moving atoms based on elapsed time. :dd + {Respa inner cutoffs are invalid} :dt The first cutoff must be <= the second cutoff. :dd @@ -5008,6 +5324,10 @@ NPT/NPH fix must be defined in input script after all rigid fixes, else the rigid fix contribution to the pressure virial is incorrect. :dd +{Rmask function in equal-style variable formula} :dt + +Rmask is per-atom operation. :dd + {Run command before simulation box is defined} :dt The run command cannot be used before a read_data, read_restart, or @@ -5021,10 +5341,6 @@ Self-explanatory. :dd Self-explanatory. :dd -{Run command upto value is before current timestep} :dt - -Self-explanatory. :dd - {Run_style command before simulation box is defined} :dt The run_style command cannot be used before a read_data, @@ -5038,10 +5354,9 @@ Fix SRD had to adjust the bin size to fit the simulation box. :dd The bin shape is not within tolerance of cubic. :dd -{SRD particle %d started inside big particle %d on step %d bounce %d} :dt +{Same dimension twice in fix ave/spatial} :dt -This may not be a problem, but indicates one or more SRD particles are -being left inside solute particles. :dd +Self-explanatory. :dd {Set command before simulation box is defined} :dt @@ -5062,19 +5377,19 @@ All 3-atom angle-constrained SHAKE clusters specified by the fix shake command that are the same angle type, must also have the same bond types for the 2 bonds in the angle. :dd -{Shake atoms %d %d %d %d missing on proc %d at step %d} :dt +{Shake atoms %d %d %d %d missing on proc %d at step} :dt The 4 atoms in a single shake cluster specified by the fix shake command are not all accessible to a processor. This probably means an atom has moved too far. :dd -{Shake atoms %d %d %d missing on proc %d at step %d} :dt +{Shake atoms %d %d %d missing on proc %d at step} :dt The 3 atoms in a single shake cluster specified by the fix shake command are not all accessible to a processor. This probably means an atom has moved too far. :dd -{Shake atoms %d %d missing on proc %d at step %d} :dt +{Shake atoms %d %d missing on proc %d at step} :dt The 2 atoms in a single shake cluster specified by the fix shake command are not all accessible to a processor. This probably means @@ -5104,6 +5419,15 @@ SHAKE fix contribution to the pressure virial is incorrect. :dd Self-explanatory. :dd +{Smallint setting in lmptype.h is invalid} :dt + +It has to be the size of an integer. :dd + +{Smallint setting in lmptype.h is not compatible} :dt + +Smallint stored in restart file is not consistent with LAMMPS version +you are running. :dd + {Sqrt of negative value in variable formula} :dt Self-explanatory. :dd @@ -5113,6 +5437,14 @@ Self-explanatory. :dd Input script line contained a variable that could not be substituted for. :dd +{System in data file is too big} :dt + +See the setting for bigint in the src/lmptype.h file. :dd + +{TAD nsteps must be multiple of t_event} :dt + +Self-explanatory. :dd + {TIP4P hydrogen has incorrect atom type} :dt The TIP4P pairwise computation found an H atom whose type does not @@ -5128,6 +5460,19 @@ within a water molecule. :dd The target file for the fix tmd command did not list all atoms in the fix group. :dd +{Tad command before simulation box is defined} :dt + +Self-explanatory. :dd + +{Tagint setting in lmptype.h is invalid} :dt + +Tagint must be as large or larger than smallint. :dd + +{Tagint setting in lmptype.h is not compatible} :dt + +Smallint stored in restart file is not consistent with LAMMPS version +you are running. :dd + {Target temperature for fix nvt/npt/nph cannot be 0.0} :dt Self-explanatory. :dd @@ -5317,6 +5662,10 @@ is not computing this quantity. :dd Cannot use thermo_modify to set this parameter since the thermo_style is not computing this quantity. :dd +{Thermo_modify int format does not contain d character} :dt + +Self-explanatory. :dd + {Thermo_modify pressure ID does not compute pressure} :dt The specified compute ID does not compute pressure. :dd @@ -5344,11 +5693,17 @@ not defined by the atom style used in this simulation. :dd Specified timestep size is invalid. :dd -{Too big a problem to replicate with molecular atom style} :dt +{Too big a problem to use velocity create loop all} :dt -Molecular problems cannot become bigger than 2^31 atoms (or bonds, -etc) when replicated, else the atom IDs and other quantities cannot be -stored in 32-bit quantities. :dd +The system size must fit in a 32-bit integer to use this option. :dd + +{Too big a timestep for dump dcd} :dt + +The timestep must fit in a 32-bit integer to use this dump style. :dd + +{Too big a timestep for dump xtc} :dt + +The timestep must fit in a 32-bit integer to use this dump style. :dd {Too few bits for lookup table} :dt @@ -5360,6 +5715,16 @@ machine's floating point representation. :dd This is likely due to an immense simulation box that has blown up to a large size. :dd +{Too many atoms for dump dcd} :dt + +The system size must fit in a 32-bit integer to use this dump +style. :dd + +{Too many atoms for dump xtc} :dt + +The system size must fit in a 32-bit integer to use this dump +style. :dd + {Too many atoms to dump sort} :dt Cannot sort when running with more than 2^31 atoms. :dd @@ -5374,6 +5739,11 @@ machine's floating point representation. :dd The maximum number of atom groups (including the "all" group) is given by MAX_GROUP in group.cpp and is 32. :dd +{Too many iterations} :dt + +You must use a number of iterations that fit in a 32-bit integer +for minimization. :dd + {Too many mantissa bits for lookup table} :dt Table size specified via pair_modify command does not work with your @@ -5389,6 +5759,15 @@ types. :dd This is likely due to an immense simulation box that has blown up to a large size. :dd +{Too many timesteps for NEB} :dt + +You must use a number of timesteps that fit in a 32-bit integer +for NEB. :dd + +{Too many total atoms} :dt + +See the setting for bigint in the src/lmptype.h file. :dd + {Too many total bits for bitmapped lookup table} :dt Table size specified via pair_modify command is too large. Note that @@ -5400,6 +5779,11 @@ A granular simulation has too many neighbors touching one atom. The MAXTOUCH parameter in fix_shear_history.cpp must be set larger and LAMMPS must be re-built. :dd +{Too much per-proc info for dump} :dt + +Number of local atoms times number of columns must fit in a 32-bit +integer for dump. :dd + {Tree structure in joint connections} :dt Fix poems cannot (yet) work with coupled bodies whose joints connect @@ -5424,6 +5808,12 @@ Self-explanatory. :dd Self-explanatory. :dd +{Unable to initialize accelerator for use} :dt + +One or more specified accelerator(s) cannot currently be used by LAMMPS. +This can happen if the accelerator is already in use by another +process. :dd + {Unbalanced quotes in input line} :dt No matching end double quote was found following a leading double @@ -5474,6 +5864,10 @@ valid. :dd The lattice type in an entry of the MEAM parameter file is not valid. :dd +{Unrecognized pair style in compute pair command} :dt + +Self-explanatory. :dd + {Use of compute temp/ramp with undefined lattice} :dt Must use lattice command with compute temp/ramp command if units @@ -5527,11 +5921,6 @@ set to lattice. :dd Must use lattice command with fix wall command if units option is set to lattice. :dd -{Use of fix wall/reflect with undefined lattice} :dt - -If scale = lattice (the default) for the fix wall/reflect command, -then a lattice must first be defined via the lattice command. :dd - {Use of region with undefined lattice} :dt If scale = lattice (the default) for the region command, then a @@ -5561,6 +5950,10 @@ deform needs to be used. :dd Cannot evaluate a compute or fix or atom-based value in a variable before the simulation has been setup. :dd +{Variable for compute ti is invalid style} :dt + +Self-explanatory. :dd + {Variable for dump every is invalid style} :dt Only equal-style variables can be used. :dd @@ -5569,6 +5962,10 @@ Only equal-style variables can be used. :dd Only equal-style variables can be used. :dd +{Variable for fix addforce is invalid style} :dt + +Self-explanatory. :dd + {Variable for fix aveforce is invalid style} :dt Only equal-style variables can be used. :dd @@ -5593,14 +5990,34 @@ Only equal-style variables can be used. :dd Only equal-style variables can be used. :dd +{Variable for fix wall is invalid style} :dt + +Only equal-style variables can be used. :dd + {Variable for fix wall/reflect is invalid style} :dt Only equal-style variables can be used. :dd +{Variable for fix wall/srd is invalid style} :dt + +Only equal-style variables can be used. :dd + +{Variable for region is invalid style} :dt + +Only equal-style variables can be used. :dd + +{Variable for region is not equal style} :dt + +Self-explanatory. :dd + {Variable for thermo every is invalid style} :dt Only equal-style variables can be used. :dd +{Variable for velocity set is invalid style} :dt + +Only atom-style variables can be used. :dd + {Variable formula compute array is accessed out-of-range} :dt Self-explanatory. :dd @@ -5617,10 +6034,18 @@ Self-explanatory. :dd Self-explanatory. :dd +{Variable name for compute atom/molecule does not exist} :dt + +Self-explanatory. :dd + {Variable name for compute reduce does not exist} :dt Self-explanatory. :dd +{Variable name for compute ti does not exist} :dt + +Self-explanatory. :dd + {Variable name for dump every does not exist} :dt Self-explanatory. :dd @@ -5677,7 +6102,19 @@ Self-explanatory. :dd Self-explanatory. :dd -{Variable name for fix wall/relect does not exist} :dt +{Variable name for fix wall does not exist} :dt + +Self-explanatory. :dd + +{Variable name for fix wall/reflect does not exist} :dt + +Self-explanatory. :dd + +{Variable name for fix wall/srd does not exist} :dt + +Self-explanatory. :dd + +{Variable name for region does not exist} :dt Self-explanatory. :dd @@ -5685,6 +6122,10 @@ Self-explanatory. :dd Self-explanatory. :dd +{Variable name for velocity set does not exist} :dt + +Self-explanatory. :dd + {Variable name must be alphanumeric or underscore characters} :dt Self-explanatory. :dd @@ -5713,6 +6154,23 @@ You are using a thermo keyword that requires potentials to have tallied the virial, but they didn't on this timestep. See the variable doc page for ideas on how to make this work. :dd +{Wall defined twice in fix wall command} :dt + +Self-explanatory. :dd + +{Wall defined twice in fix wall/reflect command} :dt + +Self-explanatory. :dd + +{Wall defined twice in fix wall/srd command} :dt + +Self-explanatory. :dd + +{Weighted neighbor list values are too big} :dt + +You must have less atoms per processor to use this +style neighbor list. :dd + {World variable count doesn't match # of partitions} :dt A world-style variable must specify a number of values equal to the @@ -5748,6 +6206,12 @@ want. :dd See the doc page for fix bond/break for more info on this restriction. :dd +{Building an occasional neighobr list when atoms may have moved too far} :dt + +This can cause LAMMPS to crash when the neighbor list is built. +The solution is to check for building the regular neighbor lists +more frequently. :dd + {Compute cna/atom cutoff may be too large to find ghost atom neighbors} :dt The neighbor cutoff used may not encompass enough ghost atoms @@ -5785,6 +6249,10 @@ will be truncated to attempt to prevent the bond from blowing up. :dd A FENE bond has stretched dangerously far. It's interaction strength will be truncated to attempt to prevent the bond from blowing up. :dd +{Fix SRD walls overlap but fix srd overlap not set} :dt + +You likely want to set this in your input script. :dd + {Fix bond/swap will ignore defined angles} :dt See the doc page for fix bond/swap for more info on this @@ -5811,6 +6279,10 @@ This is because the SRD particles may move long distances. :dd This may cause accuracy problems. :dd +{Fix srd no-slip wall collisions with bin shifting} :dt + +This is an inconsistent setting in your input script. :dd + {Fix srd particle moved outside valid domain} :dt This may indicate a problem with your simulation parameters. :dd @@ -5876,6 +6348,10 @@ on the same group of atoms that velocities are being set for. :dd It is not efficient to use compute centro/atom more than once. :dd +{More than one compute cluster/atom} :dt + +It is not efficient to use compute cluster/atom more than once. :dd + {More than one compute cna/atom defined} :dt It is not efficient to use compute cna/atom more than once. :dd @@ -5985,6 +6461,13 @@ every = 1, check = yes. Since these settings were not in place, LAMMPS changed them and will restore them to their original values after the PRD simulation. :dd +{Resetting reneighboring criteria during TAD} :dt + +A TAD simulation requires that neigh_modify settings be delay = 0, +every = 1, check = yes. Since these settings were not in place, +LAMMPS changed them and will restore them to their original values +after the PRD simulation. :dd + {Resetting reneighboring criteria during minimization} :dt Minimization requires that neigh_modify settings be delay = 0, every = diff --git a/doc/Section_example.html b/doc/Section_example.html index 5e32f0ca3c..94e2d95d64 100644 --- a/doc/Section_example.html +++ b/doc/Section_example.html @@ -9,7 +9,7 @@
    -

    5. Example problems +

    7. Example problems

    The LAMMPS distribution includes an examples sub-directory with several sample problems. Each problem is in a sub-directory of its diff --git a/doc/Section_example.txt b/doc/Section_example.txt index 241f01f70b..947c7957c7 100644 --- a/doc/Section_example.txt +++ b/doc/Section_example.txt @@ -6,7 +6,7 @@ :line -5. Example problems :h3 +7. Example problems :h3 The LAMMPS distribution includes an examples sub-directory with several sample problems. Each problem is in a sub-directory of its diff --git a/doc/Section_history.html b/doc/Section_history.html index 8a414e4a47..d827db95e7 100644 --- a/doc/Section_history.html +++ b/doc/Section_history.html @@ -1,5 +1,7 @@ -

    Previous Section - LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands - Next Section +
    Previous Section - LAMMPS WWW Site - +LAMMPS Documentation - LAMMPS Commands - Next +Section
    @@ -9,69 +11,61 @@
    -

    11. Future and history +

    13. Future and history

    -

    This section lists features we are planning to add to LAMMPS, features -of previous versions of LAMMPS, and features of other parallel -molecular dynamics codes I've distributed. +

    This section lists features we plan to add to LAMMPS, features of +previous versions of LAMMPS, and features of other parallel molecular +dynamics codes our group has distributed.

    -11.1 Coming attractions
    -11.2 Past versions
    +13.1 Coming attractions
    +13.2 Past versions
    -

    11.1 Coming attractions +
    + +

    13.1 Coming attractions

    -

    The current version of LAMMPS incorporates nearly all the features -from previous parallel MD codes developed at Sandia. These include -earlier versions of LAMMPS itself, Warp and ParaDyn for metals, and -GranFlow for granular materials. +

    The Wish list link on the +LAMMPS WWW page gives a list of features we are hoping to add to +LAMMPS in the future, including contact names of individuals you can +email if you are interested in contributing to the developement or +would be a future user of that feature.

    -

    These are new features we'd like to eventually add to LAMMPS. Some -are being worked on; some haven't been implemented because of lack of -time or interest; others are just a lot of work! See this -page on the LAMMPS WWW site for more details. +

    You can also send email to the +developers if you want to add +your wish to the list.

    - - -
    • Coupling to finite elements for streess-strain -
    • New ReaxFF implementation -
    • Nudged elastic band -
    • Temperature accelerated dynamics -
    • Triangulated particles -
    • Stochastic rotation dynamics -
    • Stokesian dynamics via fast lubrication dynamics -
    • Long-range point-dipole solver -
    • Per-atom energy and stress for long-range Coulombics -
    • Long-range Coulombics via Ewald and PPPM for triclinic boxes -
    • Metadynamics -
    • Direct Simulation Monte Carlo - DSMC -
    -

    11.2 Past versions +

    13.2 Past versions

    LAMMPS development began in the mid 1990s under a cooperative research & development agreement (CRADA) between two DOE labs (Sandia and LLNL) -and 3 companies (Cray, Bristol Myers Squibb, and Dupont). Soon after -the CRADA ended, a final F77 version of the code, LAMMPS 99, was -released. As development of LAMMPS continued at Sandia, the memory -management in the code was converted to F90; a final F90 version was -released as LAMMPS 2001. +and 3 companies (Cray, Bristol Myers Squibb, and Dupont). The goal was +to develop a large-scale parallel classical MD code; the coding effort +was led by Steve Plimpton at Sandia. +

    +

    After the CRADA ended, a final F77 version, LAMMPS 99, was +released. As development of LAMMPS continued at Sandia, its memory +management was converted to F90; a final F90 version was released as +LAMMPS 2001.

    The current LAMMPS is a rewrite in C++ and was first publicly released -in 2004. It includes many new features, including features from other -parallel molecular dynamics codes written at Sandia, namely ParaDyn, -Warp, and GranFlow. ParaDyn is a parallel implementation of the -popular serial DYNAMO code developed by Stephen Foiles and Murray Daw -for their embedded atom method (EAM) metal potentials. ParaDyn uses -atom- and force-decomposition algorithms to run in parallel. Warp is -also a parallel implementation of the EAM potentials designed for -large problems, with boundary conditions specific to shearing solids -in varying geometries. GranFlow is a granular materials code with -potentials and boundary conditions peculiar to granular systems. All -of these codes (except ParaDyn) use spatial-decomposition techniques -for their parallelism. +as an open source code in 2004. It includes many new features beyond +those in LAMMPS 99 or 2001. It also includes features from older +parallel MD codes written at Sandia, namely ParaDyn, Warp, and +GranFlow (see below). +

    +

    In late 2006 we began merging new capabilities into LAMMPS that were +developed by Aidan Thompson at Sandia for his MD code GRASP, which has +a parallel framework similar to LAMMPS. Most notably, these have +included many-body potentials - Stillinger-Weber, Tersoff, ReaxFF - +and the associated charge-equilibration routines needed for ReaxFF. +

    +

    The History link on the +LAMMPS WWW page gives a timeline of features added to the +C++ open-source version of LAMMPS over the last several years.

    These older codes are available for download from the LAMMPS WWW site, except for Warp & GranFlow which were primarily used diff --git a/doc/Section_history.txt b/doc/Section_history.txt index 93922ebd45..2c65825370 100644 --- a/doc/Section_history.txt +++ b/doc/Section_history.txt @@ -1,4 +1,6 @@ -"Previous Section"_Section_errors.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Manual.html :c +"Previous Section"_Section_errors.html - "LAMMPS WWW Site"_lws - +"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next +Section"_Manual.html :c :link(lws,http://lammps.sandia.gov) :link(ld,Manual.html) @@ -6,69 +8,60 @@ :line -11. Future and history :h3 +13. Future and history :h3 -This section lists features we are planning to add to LAMMPS, features -of previous versions of LAMMPS, and features of other parallel -molecular dynamics codes I've distributed. +This section lists features we plan to add to LAMMPS, features of +previous versions of LAMMPS, and features of other parallel molecular +dynamics codes our group has distributed. -11.1 "Coming attractions"_#11_1 -11.2 "Past versions"_#11_2 :all(b) +13.1 "Coming attractions"_#hist_1 +13.2 "Past versions"_#hist_2 :all(b) + +:line +:line + +13.1 Coming attractions :h4,link(hist_1) + +The "Wish list link"_http://lammps.sandia.gov/future.html on the +LAMMPS WWW page gives a list of features we are hoping to add to +LAMMPS in the future, including contact names of individuals you can +email if you are interested in contributing to the developement or +would be a future user of that feature. + +You can also send "email to the +developers"_http://lammps.sandia.gov/authors.html if you want to add +your wish to the list. :line -11.1 Coming attractions :h4,link(11_1) - -The current version of LAMMPS incorporates nearly all the features -from previous parallel MD codes developed at Sandia. These include -earlier versions of LAMMPS itself, Warp and ParaDyn for metals, and -GranFlow for granular materials. - -These are new features we'd like to eventually add to LAMMPS. Some -are being worked on; some haven't been implemented because of lack of -time or interest; others are just a lot of work! See "this -page"_lwsfuture on the LAMMPS WWW site for more details. - -:link(lwsfuture,http://lammps.sandia.gov/future.html) - -Coupling to finite elements for streess-strain -New ReaxFF implementation -Nudged elastic band -Temperature accelerated dynamics -Triangulated particles -Stochastic rotation dynamics -Stokesian dynamics via fast lubrication dynamics -Long-range point-dipole solver -Per-atom energy and stress for long-range Coulombics -Long-range Coulombics via Ewald and PPPM for triclinic boxes -Metadynamics -Direct Simulation Monte Carlo - DSMC :ul - -:line - -11.2 Past versions :h4,link(11_2) +13.2 Past versions :h4,link(hist_2) LAMMPS development began in the mid 1990s under a cooperative research & development agreement (CRADA) between two DOE labs (Sandia and LLNL) -and 3 companies (Cray, Bristol Myers Squibb, and Dupont). Soon after -the CRADA ended, a final F77 version of the code, LAMMPS 99, was -released. As development of LAMMPS continued at Sandia, the memory -management in the code was converted to F90; a final F90 version was -released as LAMMPS 2001. +and 3 companies (Cray, Bristol Myers Squibb, and Dupont). The goal was +to develop a large-scale parallel classical MD code; the coding effort +was led by Steve Plimpton at Sandia. + +After the CRADA ended, a final F77 version, LAMMPS 99, was +released. As development of LAMMPS continued at Sandia, its memory +management was converted to F90; a final F90 version was released as +LAMMPS 2001. The current LAMMPS is a rewrite in C++ and was first publicly released -in 2004. It includes many new features, including features from other -parallel molecular dynamics codes written at Sandia, namely ParaDyn, -Warp, and GranFlow. ParaDyn is a parallel implementation of the -popular serial DYNAMO code developed by Stephen Foiles and Murray Daw -for their embedded atom method (EAM) metal potentials. ParaDyn uses -atom- and force-decomposition algorithms to run in parallel. Warp is -also a parallel implementation of the EAM potentials designed for -large problems, with boundary conditions specific to shearing solids -in varying geometries. GranFlow is a granular materials code with -potentials and boundary conditions peculiar to granular systems. All -of these codes (except ParaDyn) use spatial-decomposition techniques -for their parallelism. +as an open source code in 2004. It includes many new features beyond +those in LAMMPS 99 or 2001. It also includes features from older +parallel MD codes written at Sandia, namely ParaDyn, Warp, and +GranFlow (see below). + +In late 2006 we began merging new capabilities into LAMMPS that were +developed by Aidan Thompson at Sandia for his MD code GRASP, which has +a parallel framework similar to LAMMPS. Most notably, these have +included many-body potentials - Stillinger-Weber, Tersoff, ReaxFF - +and the associated charge-equilibration routines needed for ReaxFF. + +The "History link"_http://lammps.sandia.gov/history.html on the +LAMMPS WWW page gives a timeline of features added to the +C++ open-source version of LAMMPS over the last several years. These older codes are available for download from the "LAMMPS WWW site"_lws, except for Warp & GranFlow which were primarily used diff --git a/doc/Section_howto.html b/doc/Section_howto.html index 4bc3da2a86..ada3d46ade 100644 --- a/doc/Section_howto.html +++ b/doc/Section_howto.html @@ -1,5 +1,5 @@ -

    Previous Section - LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands - Next Section +
    Previous Section - LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands - Next Section
    @@ -9,32 +9,31 @@
    -

    4. How-to discussions +

    6. How-to discussions

    -

    The following sections describe how to use various options within -LAMMPS. +

    This section describes how to perform common tasks using LAMMPS.

    -4.1 Restarting a simulation
    -4.2 2d simulations
    -4.3 CHARMM, AMBER, and DREIDING force fields
    -4.4 Running multiple simulations from one input script
    -4.5 Multi-replica simulations
    -4.6 Granular models
    -4.7 TIP3P water model
    -4.8 TIP4P water model
    -4.9 SPC water model
    -4.10 Coupling LAMMPS to other codes
    -4.11 Visualizing LAMMPS snapshots
    -4.12 Triclinic (non-orthogonal) simulation boxes
    -4.13 NEMD simulations
    -4.14 Extended spherical and aspherical particles
    -4.15 Output from LAMMPS (thermo, dumps, computes, fixes, variables)
    -4.16 Thermostatting, barostatting and computing temperature
    -4.17 Walls
    -4.18 Elastic constants
    -4.19 Library interface to LAMMPS
    -4.20 Calculating thermal conductivity
    -4.21 Calculating viscosity
    +6.1 Restarting a simulation
    +6.2 2d simulations
    +6.3 CHARMM, AMBER, and DREIDING force fields
    +6.4 Running multiple simulations from one input script
    +6.5 Multi-replica simulations
    +6.6 Granular models
    +6.7 TIP3P water model
    +6.8 TIP4P water model
    +6.9 SPC water model
    +6.10 Coupling LAMMPS to other codes
    +6.11 Visualizing LAMMPS snapshots
    +6.12 Triclinic (non-orthogonal) simulation boxes
    +6.13 NEMD simulations
    +6.14 Extended spherical and aspherical particles
    +6.15 Output from LAMMPS (thermo, dumps, computes, fixes, variables)
    +6.16 Thermostatting, barostatting and computing temperature
    +6.17 Walls
    +6.18 Elastic constants
    +6.19 Library interface to LAMMPS
    +6.20 Calculating thermal conductivity
    +6.21 Calculating viscosity

    The example input scripts included in the LAMMPS distribution and highlighted in this section also show how to @@ -42,7 +41,9 @@ setup and run various kinds of simulations.

    -

    4.1 Restarting a simulation +
    + +

    6.1 Restarting a simulation

    There are 3 ways to continue a long LAMMPS simulation. Multiple run commands can be used in the same input script. Each @@ -134,7 +135,7 @@ but not in data files.

    -

    4.2 2d simulations +

    6.2 2d simulations

    Use the dimension command to specify a 2d simulation.

    @@ -169,7 +170,7 @@ the same as in 3d.

    -

    4.3 CHARMM, AMBER, and DREIDING force fields +

    6.3 CHARMM, AMBER, and DREIDING force fields

    A force field has 2 parts: the formulas that define it and the coefficients used for a particular system. Here we only discuss @@ -246,7 +247,7 @@ documentation for the formula it computes.

    -

    4.4 Running multiple simulations from one input script +

    6.4 Running multiple simulations from one input script

    This can be done in several ways. See the documentation for individual commands for more details on how these examples work. @@ -318,7 +319,7 @@ jump in.polymer

    All of the above examples work whether you are running on 1 or multiple processors, but assumed you are running LAMMPS on a single partition of processors. LAMMPS can be run on multiple partitions via -the "-partition" command-line switch as described in this +the "-partition" command-line switch as described in this section of the manual.

    In the last 2 examples, if LAMMPS were run on 3 partitions, the same @@ -334,7 +335,7 @@ the 4th simulation, and so forth, until all 8 were completed.

    -

    4.5 Multi-replica simulations +

    6.5 Multi-replica simulations

    Several commands in LAMMPS run mutli-replica simulations, meaning that multiple instances (replicas) of your simulation are run @@ -355,12 +356,12 @@ runs different replicas at a series of temperature to facilitate rare-event sampling.

    These command can only be used if LAMMPS was built with the "replica" -package. See the Making LAMMPS section for -more info on packages. +package. See the Making LAMMPS section +for more info on packages.

    In all these cases, you must run with one or more processors per replica. The processors assigned to each replica are determined at -run-time by using the -partition command-line +run-time by using the -partition command-line switch to launch LAMMPS on multiple partitions, which in this context are the same as replicas. E.g. these commands: @@ -369,8 +370,8 @@ these commands: mpirun -np 8 lmp_linux -partition 8x1 -in in.neb

    would each run 8 replicas, on either 16 or 8 processors. Note the use -of the -in command-line switch to specify the -input script which is required when running in multi-replica mode. +of the -in command-line switch to specify +the input script which is required when running in multi-replica mode.

    Also note that with MPI installed on a machine (e.g. your desktop), you can run on more (virtual) processors than you have physical @@ -381,7 +382,7 @@ physical processors.

    -

    4.6 Granular models +

    6.6 Granular models

    Granular system are composed of spherical particles with a diameter, as opposed to point particles. This means they have an angular @@ -390,7 +391,7 @@ velocity and torque can be imparted to them to cause them to rotate.

    To run a simulation of a granular model, you will want to use the following commands:

    -
    -

    4.7 TIP3P water model +

    6.7 TIP3P water model

    The TIP3P water model as implemented in CHARMM (MacKerell) specifies a 3-site rigid water molecule with @@ -486,7 +487,7 @@ models.

    -

    4.8 TIP4P water model +

    6.8 TIP4P water model

    The four-point TIP4P rigid water model extends the traditional three-point TIP3P model by adding an additional site, usually @@ -545,7 +546,7 @@ models.

    -

    4.9 SPC water model +

    6.9 SPC water model

    The SPC water model specifies a 3-site rigid water molecule with charges and Lennard-Jones parameters assigned to each of the 3 atoms. @@ -590,7 +591,7 @@ models.

    -

    4.10 Coupling LAMMPS to other codes +

    6.10 Coupling LAMMPS to other codes

    LAMMPS is designed to allow it to be coupled to other codes. For example, a quantum mechanics code might compute forces on a subset of @@ -660,10 +661,10 @@ strain induced across grain boundaries -

    This section of the documentation describes -how to build LAMMPS as a library. Once this is done, you can -interface with LAMMPS either via C++, C, Fortran, or Python (or any -other language that supports a vanilla C-like interface). For +

    This section of the documentation +describes how to build LAMMPS as a library. Once this is done, you +can interface with LAMMPS either via C++, C, Fortran, or Python (or +any other language that supports a vanilla C-like interface). For example, from C++ you could create one (or more) "instances" of LAMMPS, pass it an input script to process, or execute individual commands, all by invoking the correct class methods in LAMMPS. From C @@ -673,7 +674,7 @@ the Python wrapper provided with LAMMPS that operates through the LAMMPS library interface.

    The files src/library.cpp and library.h contain the C-style interface -to LAMMPS. See this section of the manual +to LAMMPS. See this section of the manual for a description of the interface and how to extend it for your needs.

    @@ -690,7 +691,7 @@ instances of LAMMPS to perform different calculations.

    -

    4.11 Visualizing LAMMPS snapshots +

    6.11 Visualizing LAMMPS snapshots

    LAMMPS itself does not do visualization, but snapshots from LAMMPS simulations can be visualized (and analyzed) in a variety of ways. @@ -749,14 +750,14 @@ See the dump command for more information on XTC files

    -

    4.12 Triclinic (non-orthogonal) simulation boxes +

    6.12 Triclinic (non-orthogonal) simulation boxes

    By default, LAMMPS uses an orthogonal simulation box to encompass the particles. The boundary command sets the boundary conditions of the box (periodic, non-periodic, etc). The orthogonal box has its "origin" at (xlo,ylo,zlo) and is defined by 3 edge vectors -starting from the origin given by A = (xhi-xlo,0,0); B = -(0,yhi-ylo,0); C = (0,0,zhi-zlo). The 6 parameters +starting from the origin given by a = (xhi-xlo,0,0); b = +(0,yhi-ylo,0); c = (0,0,zhi-zlo). The 6 parameters (xlo,xhi,ylo,yhi,zlo,zhi) are defined at the time the simluation box is created, e.g. by the create_box or read_data or read_restart @@ -768,14 +769,14 @@ custom command.

    LAMMPS also allows simulations to be perfored in non-orthogonal simulation boxes shaped as a parallelepiped with triclinic symmetry. The parallelepiped has its "origin" at (xlo,ylo,zlo) and is defined by -3 edge vectors starting from the origin given by A = (xhi-xlo,0,0); B -= (xy,yhi-ylo,0); C = (xz,yz,zhi-zlo). Xy,xz,yz can be 0.0 or +3 edge vectors starting from the origin given by a = (xhi-xlo,0,0); b += (xy,yhi-ylo,0); c = (xz,yz,zhi-zlo). Xy,xz,yz can be 0.0 or positive or negative values and are called "tilt factors" because they are the amount of displacement applied to faces of an originally orthogonal box to transform it into the parallelepiped. Note that in -LAMMPS the triclinic simulation box edge vectors A,B,C cannot be -arbitrary vectors. As indicated, A must be aligned with the x axis, B -must be in the xy plane, and C is arbitrary. However, this is not a +LAMMPS the triclinic simulation box edge vectors a, b, and c cannot be +arbitrary vectors. As indicated, a must be aligned with the x axis, b +must be in the xy plane, and c is arbitrary. However, this is not a restriction since it is possible to rotate any set of 3 crystal basis vectors so that they meet this restriction.

    @@ -817,14 +818,25 @@ equivalent.

    Triclinic crystal structures are often defined using three lattice constants a, b, and c, and three angles alpha, beta and -gamma. Note that in this nomenclature, the a,b,c lattice constants -are the scalar lengths of the 3 A,B,C edge vectors defined above. The +gamma. Note that in this nomenclature, the a, b, and c lattice constants +are the scalar lengths of the edge vectors a, b, and c defined +above. The relationship between these 6 quantities (a,b,c,alpha,beta,gamma) and the LAMMPS box sizes (lx,ly,lz) = (xhi-xlo,yhi-ylo,zhi-zlo) and tilt factors (xy,xz,yz) is as follows:

    +

    The inverse relationship can be written as follows: +

    +
    +
    +

    The values of a, b, c , alpha, beta , and gamma can be printed +out or accessed by computes using the +thermo_style custom keywords +cella, cellb, cellc, cellalpha, cellbeta, cellgamma, +respectively. +

    As discussed on the dump command doc page, when the BOX BOUNDS for a snapshot is written to a dump file for a triclinic box, an orthogonal bounding box which encloses the triclinic simulation box @@ -871,7 +883,7 @@ on non-equilibrium MD (NEMD) simulations.

    -

    4.13 NEMD simulations +

    6.13 NEMD simulations

    Non-equilibrium molecular dynamics or NEMD simulations are typically used to measure a fluid's rheological properties such as viscosity. @@ -909,13 +921,13 @@ profile consistent with the applied shear strain rate.

    -

    4.14 Extended spherical and aspherical particles +

    6.14 Extended spherical and aspherical particles

    Typical MD models treat atoms or particles as point masses. Sometimes, however, it is desirable to have a model with finite-size -particles such as spherioids or aspherical ellipsoids. The difference -is that such particles have a moment of inertia, rotational energy, -and angular momentum. Rotation is induced by torque from interactions +particles such as spheres or aspherical ellipsoids. The difference is +that such particles have a moment of inertia, rotational energy, and +angular momentum. Rotation is induced by torque from interactions with other particles.

    LAMMPS has several options for running simulations with these kinds of @@ -929,53 +941,61 @@ particles. The following aspects are discussed in turn:

    Atom styles
    -

    There are 3 atom styles that allow for definition of -finite-size particles: granular, dipole, ellipsoid. +

    There are 2 atom styles that allow for definition of +finite-size particles: sphere and ellipsoid. The peri atom style also +treats particles as having a volume, but that is internal to the +pair_style peri potentials. The dipole atom style is +most often used in conjunction with finite-size particles.

    -

    Granular particles are spheriods and each particle can have a unique -diameter and mass (or density). These particles store an angular -velocity (omega) and can be acted upon by torque. +

    The sphere style defines particles that are spheriods and each +particle can have a unique diameter and mass (or density). These +particles store an angular velocity (omega) and can be acted upon by +torque. The "set" command can be used to modify the diameter and mass +of individual particles, after then are created.

    -

    Dipolar particles are typically spheriods with a point dipole and each -particle type has a diamater and mass, set by the shape -and mass commands. These particles store an angular -velocity (omega) and can be acted upon by torque. They also store an -orientation for the point dipole (mu) which has a length set by the -dipole command. The set command can be used -to initialize the orientation of dipole moments. +

    The ellipsoid style defines particles that are ellipsoids and thus can +be aspherical. Each particle has a shape, specified by 3 diameters, +and mass (or density). These particles store an angular momentum and +their orientation (quaternion), and can be acted upon by torque. They +do not store an angular velocity (omega), which can be in a different +direction than angular momentum, rather they compute it as needed. +The "set" command can be used to modify the diameter, orientation, and +mass of individual particles, after then are created. It also has a +brief explanation of what quaternions are.

    -

    Ellipsoid particles are aspherical. Each particle type has an -ellipsoidal shape and mass, defined by the shape and -mass commands. These particles store an angular momentum -and their orientation (quaternion), and can be acted upon by torque. -They do not store an angular velocity (omega), which can be in a -different direction than angular momentum, rather they compute it as -needed. Ellipsoidal particles can also store a dipole moment if an -atom_style hybrid ellipsoid dipole is used. The -set command can be used to initialize the orientation of -ellipsoidal particles and has a brief explanation of quaternions. +

    The dipole style does not define extended particles, but is often +used in conjunction with spherical particles, via a command like +

    +
    atom_style hybrid sphere dipole 
+
    +

    This is because when dipoles interact with each other, they induce +torques, and a particle must be extended (i.e. have a moment of +inertia) in order to respond and rotate. See the atom_style +dipole command for details. The "set" command can be +used to modify the orientation and length of the dipole moment of +individual particles, after then are created.

    Note that if one of these atom styles is used (or multiple styles via the atom_style hybrid command), not all particles in the system are required to be finite-size or aspherical. For example, if the 3 shape parameters are set to the same value, the particle will -be a spheroid rather than an ellipsoid. If the 3 shape parameters are +be a sphere rather than an ellipsoid. If the 3 shape parameters are all set to 0.0 or if the diameter is set to 0.0, it will be a point -particle. If the dipole moment is set to zero, the particle will not -have a point dipole associated with it. The pair styles used to -compute pairwise interactions will typically compute the correct -interaction in these simplified (cheaper) cases. Pair_style -hybrid can be used to insure the correct +particle. If the length of the dipole moment is set to zero, the +particle will not have a point dipole associated with it. The pair +styles used to compute pairwise interactions will typically compute +the correct interaction in these simplified (cheaper) cases. +Pair_style hybrid can be used to insure the correct interactions are computed for the appropriate style of interactions. -Likewise, using groups to partition particles (ellipsoid versus -spheroid versus point particles) will allow you to use the appropriate +Likewise, using groups to partition particles (ellipsoids versus +spheres versus point particles) will allow you to use the appropriate time integrators and temperature computations for each class of particles. See the doc pages for various commands for details.

    Also note that for 2d simulations, finite-size -spheroids and ellipsoids are still treated as 3d particles, rather -than as disks or ellipses. This means they have the same moment of -inertia for a 3d extended object. When their temperature is +spheres and ellipsoids are still treated as 3d particles, rather than +as circular disks or ellipses. This means they have the same moment +of inertia for a 3d extended object. When their temperature is coomputed, the correct degrees of freedom are used for rotation in a 2d versus 3d system.

    @@ -994,15 +1014,14 @@ that generate torque:
  • pair_style resquared
  • pair_style lubricate -

    The granular pair styles are used with atom_style -granular. The dipole pair style -is used with atom_style dipole. The -GayBerne and REsquared -potentials require particles have a shape and are -designed for ellipsoidal particles. The -lubrication potential requires that particles -have a shape. It can currently only be used with -extended spherical particles. +

    The granular pair styles are used with spherical +particles. The dipole pair style is used with +atom_style dipole, which could be applied to +spherical or ellipsoidal particles. The GayBerne +and REsquared potentials require ellipsoidal +particles, though they will also work if the 3 shape parameters are +the same (a sphere). The lubrication potential +works with spherical particles.

    Time integration
    @@ -1014,8 +1033,8 @@ and angular velocity or angular momentum of the particles:
  • fix nvt/sphere
  • fix npt/sphere -

    Likewise, there are 3 fixes that perform time integration on extended -aspherical particles: +

    Likewise, there are 3 fixes that perform time integration on +ellipsoids as extended aspherical particles:

    • fix nve/asphere
    • fix nvt/asphere @@ -1035,7 +1054,7 @@ extended particles.
      Computes, thermodynamics, and dump output

      There are 4 computes that calculate the temperature or rotational energy -of extended spherical or aspherical particles: +of extended spherical or aspherical particles (ellipsoids):

      • compute temp/sphere
      • compute temp/asphere @@ -1063,11 +1082,8 @@ particles as a rigid body, computes its inertia tensor, sums the total force and torque on the rigid body each timestep due to forces on its constituent particles, and integrates the motion of the rigid body.

        -

        (NOTE: the feature described in the following paragraph has not yet -been released. It will be soon.) -

        If any of the constituent particles of a rigid body are extended -particles (spheroids or ellipsoids), then their contribution to the +particles (spheres or ellipsoids), then their contribution to the inertia tensor of the body is different than if they were point particles. This means the rotational dynamics of the rigid body will be different. Thus a model of a dimer is different if the dimer @@ -1085,7 +1101,7 @@ particles are point masses.

        -

        4.15 Output from LAMMPS (thermo, dumps, computes, fixes, variables) +

        6.15 Output from LAMMPS (thermo, dumps, computes, fixes, variables)

        There are four basic kinds of LAMMPS output:

        @@ -1266,6 +1282,11 @@ or local vector quantities as inputs and "reduce" them (sum, min, max, ave) to scalar quantities. These are produced as output values which can be used as input to other output commands.

        +

        The compute slice command take one or more global +vector or array quantities as inputs and extracts a subset of their +values to create a new vector or array. These are produced as output +values which can be used as input to other output commands. +

        The compute property/atom command takes a list of one or more pre-defined atom attributes (id, x, fx, etc) and stores the values in a per-atom vector or array. These are produced @@ -1359,6 +1380,7 @@ vector input could be a column of an array. fixes N/A global/per-atom/local scalar/vector/array variables global scalars, per-atom vectors global scalar, per-atom vector compute reduce per-atom/local vectors global scalar/vector +compute slice global vectors/arrays global vector/array compute property/atom per-atom vectors per-atom vector/array compute property/local local vectors local vector/array compute atom/molecule per-atom vectors global vector/array @@ -1373,7 +1395,7 @@ vector input could be a column of an array.

        -

        4.16 Thermostatting, barostatting, and computing temperature +

        6.16 Thermostatting, barostatting, and computing temperature

        Thermostatting means controlling the temperature of particles in an MD simulation. Barostatting means controlling the pressure. Since the @@ -1434,7 +1456,7 @@ thermostatting can be invoked via the dpd/tstat pair style:

        Fix nvt only thermostats the translational velocity of particles. Fix nvt/sllod also does this, except that it subtracts out a velocity bias due to a deforming box and -integrates the SLLOD equations of motion. See the NEMD +integrates the SLLOD equations of motion. See the NEMD simulations section of this page for further details. Fix nvt/sphere and fix nvt/asphere thermostat not only translation @@ -1524,7 +1546,7 @@ thermodynamic output.

        -

        4.17 Walls +

        6.17 Walls

        Walls in an MD simulation are typically used to bound particle motion, i.e. to serve as a boundary condition. @@ -1598,7 +1620,7 @@ frictional walls, as well as triangulated surfaces.

        -

        4.18 Elastic constants +

        6.18 Elastic constants

        Elastic constants characterize the stiffness of a material. The formal definition is provided by the linear relation that holds between the @@ -1634,12 +1656,12 @@ converge and requires careful post-processing (Shinoda)

        -

        4.19 Library interface to LAMMPS +

        6.19 Library interface to LAMMPS

        -

        As described in this section, LAMMPS can be -built as a library, so that it can be called by another code, used in -a coupled manner with other codes, or driven -through a Python interface. +

        As described in this section, LAMMPS can +be built as a library, so that it can be called by another code, used +in a coupled manner with other codes, or +driven through a Python interface.

        All of these methodologies use a C-style interface to LAMMPS that is provided in the files src/library.cpp and src/library.h. The @@ -1658,11 +1680,12 @@ void lammps_file(void *, char *); char *lammps_command(void *, char *);

        The lammps_open() function is used to initialize LAMMPS, passing in a -list of strings as if they were command-line arguments when -LAMMPS is run in stand-alone mode from the command line, and a MPI -communicator for LAMMPS to run under. It returns a ptr to the LAMMPS -object that is created, and which is used in subsequent library calls. -The lammps_open() function can be called multiple times, to create +list of strings as if they were command-line +arguments when LAMMPS is run in +stand-alone mode from the command line, and a MPI communicator for +LAMMPS to run under. It returns a ptr to the LAMMPS object that is +created, and which is used in subsequent library calls. The +lammps_open() function can be called multiple times, to create multiple instances of LAMMPS.

        LAMMPS will run on the set of processors in the communicator. This @@ -1714,10 +1737,10 @@ grab data from LAMMPS, change it, and put it back into LAMMPS.

        -

        4.20 Calculating thermal conductivity +

        6.20 Calculating thermal conductivity

        The thermal conductivity kappa of a material can be measured in at -least 3 ways using various options in LAMMPS. (See this +least 3 ways using various options in LAMMPS. (See this section of the manual for an analogous discussion for viscosity). The thermal conducitivity tensor kappa is a measure of the propensity of a material to transmit heat energy in a @@ -1734,7 +1757,7 @@ scalar.

        The first method is to setup two thermostatted regions at opposite ends of a simulation box, or one in the middle and one at the end of a periodic box. By holding the two regions at different temperatures -with a thermostatting fix, the energy added +with a thermostatting fix, the energy added to the hot region should equal the energy subtracted from the cold region and be proportional to the heat flux moving between the regions. See the paper by Ikeshoji and Hafskjold for @@ -1779,10 +1802,10 @@ formalism.

        -

        4.21 Calculating viscosity +

        6.21 Calculating viscosity

        The shear viscosity eta of a fluid can be measured in at least 3 ways -using various options in LAMMPS. (See this +using various options in LAMMPS. (See this section of the manual for an analogous discussion for thermal conductivity). Eta is a measure of the propensity of a fluid to transmit momentum in a direction @@ -1808,7 +1831,7 @@ y-direction of the Vx component of fluid motion or grad(Vstream) = dVx/dy. In this case, the Pxy off-diagonal component of the pressure or stress tensor, as calculated by the compute pressure command, can also be monitored, which -is the J term in the equation above. See this +is the J term in the equation above. See this section of the manual for details on NEMD simulations.

        diff --git a/doc/Section_howto.txt b/doc/Section_howto.txt index 8bbd1c7b8f..00da9985a4 100644 --- a/doc/Section_howto.txt +++ b/doc/Section_howto.txt @@ -1,4 +1,4 @@ -"Previous Section"_Section_commands.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_example.html :c +"Previous Section"_Section_accelerate.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_example.html :c :link(lws,http://lammps.sandia.gov) :link(ld,Manual.html) @@ -6,40 +6,40 @@ :line -4. How-to discussions :h3 +6. How-to discussions :h3 -The following sections describe how to use various options within -LAMMPS. +This section describes how to perform common tasks using LAMMPS. -4.1 "Restarting a simulation"_#4_1 -4.2 "2d simulations"_#4_2 -4.3 "CHARMM, AMBER, and DREIDING force fields"_#4_3 -4.4 "Running multiple simulations from one input script"_#4_4 -4.5 "Multi-replica simulations"_#4_5 -4.6 "Granular models"_#4_6 -4.7 "TIP3P water model"_#4_7 -4.8 "TIP4P water model"_#4_8 -4.9 "SPC water model"_#4_9 -4.10 "Coupling LAMMPS to other codes"_#4_10 -4.11 "Visualizing LAMMPS snapshots"_#4_11 -4.12 "Triclinic (non-orthogonal) simulation boxes"_#4_12 -4.13 "NEMD simulations"_#4_13 -4.14 "Extended spherical and aspherical particles"_#4_14 -4.15 "Output from LAMMPS (thermo, dumps, computes, fixes, variables)"_#4_15 -4.16 "Thermostatting, barostatting and computing temperature"_#4_16 -4.17 "Walls"_#4_17 -4.18 "Elastic constants"_#4_18 -4.19 "Library interface to LAMMPS"_#4_19 -4.20 "Calculating thermal conductivity"_#4_20 -4.21 "Calculating viscosity"_#4_21 :all(b) +6.1 "Restarting a simulation"_#howto_1 +6.2 "2d simulations"_#howto_2 +6.3 "CHARMM, AMBER, and DREIDING force fields"_#howto_3 +6.4 "Running multiple simulations from one input script"_#howto_4 +6.5 "Multi-replica simulations"_#howto_5 +6.6 "Granular models"_#howto_6 +6.7 "TIP3P water model"_#howto_7 +6.8 "TIP4P water model"_#howto_8 +6.9 "SPC water model"_#howto_9 +6.10 "Coupling LAMMPS to other codes"_#howto_10 +6.11 "Visualizing LAMMPS snapshots"_#howto_11 +6.12 "Triclinic (non-orthogonal) simulation boxes"_#howto_12 +6.13 "NEMD simulations"_#howto_13 +6.14 "Extended spherical and aspherical particles"_#howto_14 +6.15 "Output from LAMMPS (thermo, dumps, computes, fixes, variables)"_#howto_15 +6.16 "Thermostatting, barostatting and computing temperature"_#howto_16 +6.17 "Walls"_#howto_17 +6.18 "Elastic constants"_#howto_18 +6.19 "Library interface to LAMMPS"_#howto_19 +6.20 "Calculating thermal conductivity"_#howto_20 +6.21 "Calculating viscosity"_#howto_21 :all(b) The example input scripts included in the LAMMPS distribution and highlighted in "this section"_Section_example.html also show how to setup and run various kinds of simulations. +:line :line -4.1 Restarting a simulation :link(4_1),h4 +6.1 Restarting a simulation :link(howto_1),h4 There are 3 ways to continue a long LAMMPS simulation. Multiple "run"_run.html commands can be used in the same input script. Each @@ -131,7 +131,7 @@ but not in data files. :line -4.2 2d simulations :link(4_2),h4 +6.2 2d simulations :link(howto_2),h4 Use the "dimension"_dimension.html command to specify a 2d simulation. @@ -166,7 +166,7 @@ the same as in 3d. :line -4.3 CHARMM, AMBER, and DREIDING force fields :link(4_3),h4 +6.3 CHARMM, AMBER, and DREIDING force fields :link(howto_3),h4 A force field has 2 parts: the formulas that define it and the coefficients used for a particular system. Here we only discuss @@ -242,7 +242,7 @@ documentation for the formula it computes. :line -4.4 Running multiple simulations from one input script :link(4_4),h4 +6.4 Running multiple simulations from one input script :link(howto_4),h4 This can be done in several ways. See the documentation for individual commands for more details on how these examples work. @@ -315,7 +315,7 @@ All of the above examples work whether you are running on 1 or multiple processors, but assumed you are running LAMMPS on a single partition of processors. LAMMPS can be run on multiple partitions via the "-partition" command-line switch as described in "this -section"_Section_start.html#2_6 of the manual. +section"_Section_start.html#start_6 of the manual. In the last 2 examples, if LAMMPS were run on 3 partitions, the same scripts could be used if the "index" and "loop" variables were @@ -330,7 +330,7 @@ the 4th simulation, and so forth, until all 8 were completed. :line -4.5 Multi-replica simulations :link(4_5),h4 +6.5 Multi-replica simulations :link(howto_5),h4 Several commands in LAMMPS run mutli-replica simulations, meaning that multiple instances (replicas) of your simulation are run @@ -351,13 +351,13 @@ runs different replicas at a series of temperature to facilitate rare-event sampling. These command can only be used if LAMMPS was built with the "replica" -package. See the "Making LAMMPS"_Section_start.html#2_3 section for -more info on packages. +package. See the "Making LAMMPS"_Section_start.html#start_3 section +for more info on packages. In all these cases, you must run with one or more processors per replica. The processors assigned to each replica are determined at run-time by using the "-partition command-line -switch"_Section_start.html#2_6 to launch LAMMPS on multiple +switch"_Section_start.html#start_6 to launch LAMMPS on multiple partitions, which in this context are the same as replicas. E.g. these commands: @@ -365,8 +365,8 @@ mpirun -np 16 lmp_linux -partition 8x2 -in in.temper mpirun -np 8 lmp_linux -partition 8x1 -in in.neb :pre would each run 8 replicas, on either 16 or 8 processors. Note the use -of the "-in command-line switch"_Section_start.html#2_6 to specify the -input script which is required when running in multi-replica mode. +of the "-in command-line switch"_Section_start.html#start_6 to specify +the input script which is required when running in multi-replica mode. Also note that with MPI installed on a machine (e.g. your desktop), you can run on more (virtual) processors than you have physical @@ -377,7 +377,7 @@ physical processors. :line -4.6 Granular models :link(4_6),h4 +6.6 Granular models :link(howto_6),h4 Granular system are composed of spherical particles with a diameter, as opposed to point particles. This means they have an angular @@ -386,7 +386,7 @@ velocity and torque can be imparted to them to cause them to rotate. To run a simulation of a granular model, you will want to use the following commands: -"atom_style"_atom_style.html granular +"atom_style sphere"_atom_style.html "fix nve/sphere"_fix_nve_sphere.html "fix gravity"_fix_gravity.html :ul @@ -395,7 +395,7 @@ This compute "compute erotate/sphere"_compute_erotate_sphere.html :ul calculates rotational kinetic energy which can be "output with -thermodynamic info"_Section_howto.html#4_15. +thermodynamic info"_Section_howto.html#howto_15. Use one of these 3 pair potentials, which compute forces and torques between interacting pairs of particles: @@ -422,7 +422,7 @@ computations between frozen atoms by using this command: :line -4.7 TIP3P water model :link(4_7),h4 +6.7 TIP3P water model :link(howto_7),h4 The TIP3P water model as implemented in CHARMM "(MacKerell)"_#MacKerell specifies a 3-site rigid water molecule with @@ -482,7 +482,7 @@ models"_http://en.wikipedia.org/wiki/Water_model. :line -4.8 TIP4P water model :link(4_8),h4 +6.8 TIP4P water model :link(howto_8),h4 The four-point TIP4P rigid water model extends the traditional three-point TIP3P model by adding an additional site, usually @@ -541,7 +541,7 @@ models"_http://en.wikipedia.org/wiki/Water_model. :line -4.9 SPC water model :link(4_9),h4 +6.9 SPC water model :link(howto_9),h4 The SPC water model specifies a 3-site rigid water molecule with charges and Lennard-Jones parameters assigned to each of the 3 atoms. @@ -586,7 +586,7 @@ models"_http://en.wikipedia.org/wiki/Water_model. :line -4.10 Coupling LAMMPS to other codes :link(4_10),h4 +6.10 Coupling LAMMPS to other codes :link(howto_10),h4 LAMMPS is designed to allow it to be coupled to other codes. For example, a quantum mechanics code might compute forces on a subset of @@ -655,10 +655,10 @@ strain induced across grain boundaries :l,ule :link(quest,http://dft.sandia.gov/Quest) :link(spparks,http://www.sandia.gov/~sjplimp/spparks.html) -"This section"_Section_start.html#2_4 of the documentation describes -how to build LAMMPS as a library. Once this is done, you can -interface with LAMMPS either via C++, C, Fortran, or Python (or any -other language that supports a vanilla C-like interface). For +"This section"_Section_start.html#start_4 of the documentation +describes how to build LAMMPS as a library. Once this is done, you +can interface with LAMMPS either via C++, C, Fortran, or Python (or +any other language that supports a vanilla C-like interface). For example, from C++ you could create one (or more) "instances" of LAMMPS, pass it an input script to process, or execute individual commands, all by invoking the correct class methods in LAMMPS. From C @@ -668,7 +668,7 @@ the Python wrapper provided with LAMMPS that operates through the LAMMPS library interface. The files src/library.cpp and library.h contain the C-style interface -to LAMMPS. See "this section"_Section_howto.html#4_19 of the manual +to LAMMPS. See "this section"_Section_howto.html#howto_19 of the manual for a description of the interface and how to extend it for your needs. @@ -685,7 +685,7 @@ instances of LAMMPS to perform different calculations. :line -4.11 Visualizing LAMMPS snapshots :link(4_11),h4 +6.11 Visualizing LAMMPS snapshots :link(howto_11),h4 LAMMPS itself does not do visualization, but snapshots from LAMMPS simulations can be visualized (and analyzed) in a variety of ways. @@ -741,14 +741,14 @@ See the "dump"_dump.html command for more information on XTC files. :line -4.12 Triclinic (non-orthogonal) simulation boxes :link(4_12),h4 +6.12 Triclinic (non-orthogonal) simulation boxes :link(howto_12),h4 By default, LAMMPS uses an orthogonal simulation box to encompass the particles. The "boundary"_boundary.html command sets the boundary conditions of the box (periodic, non-periodic, etc). The orthogonal box has its "origin" at (xlo,ylo,zlo) and is defined by 3 edge vectors -starting from the origin given by A = (xhi-xlo,0,0); B = -(0,yhi-ylo,0); C = (0,0,zhi-zlo). The 6 parameters +starting from the origin given by [a] = (xhi-xlo,0,0); [b] = +(0,yhi-ylo,0); [c] = (0,0,zhi-zlo). The 6 parameters (xlo,xhi,ylo,yhi,zlo,zhi) are defined at the time the simluation box is created, e.g. by the "create_box"_create_box.html or "read_data"_read_data.html or "read_restart"_read_restart.html @@ -760,14 +760,14 @@ custom"_thermo_style.html command. LAMMPS also allows simulations to be perfored in non-orthogonal simulation boxes shaped as a parallelepiped with triclinic symmetry. The parallelepiped has its "origin" at (xlo,ylo,zlo) and is defined by -3 edge vectors starting from the origin given by A = (xhi-xlo,0,0); B -= (xy,yhi-ylo,0); C = (xz,yz,zhi-zlo). {Xy,xz,yz} can be 0.0 or +3 edge vectors starting from the origin given by [a] = (xhi-xlo,0,0); [b] += (xy,yhi-ylo,0); [c] = (xz,yz,zhi-zlo). {Xy,xz,yz} can be 0.0 or positive or negative values and are called "tilt factors" because they are the amount of displacement applied to faces of an originally orthogonal box to transform it into the parallelepiped. Note that in -LAMMPS the triclinic simulation box edge vectors A,B,C cannot be -arbitrary vectors. As indicated, A must be aligned with the x axis, B -must be in the xy plane, and C is arbitrary. However, this is not a +LAMMPS the triclinic simulation box edge vectors [a], [b], and [c] cannot be +arbitrary vectors. As indicated, [a] must be aligned with the x axis, [b] +must be in the xy plane, and [c] is arbitrary. However, this is not a restriction since it is possible to rotate any set of 3 crystal basis vectors so that they meet this restriction. @@ -809,14 +809,25 @@ equivalent. Triclinic crystal structures are often defined using three lattice constants {a}, {b}, and {c}, and three angles {alpha}, {beta} and -{gamma}. Note that in this nomenclature, the a,b,c lattice constants -are the scalar lengths of the 3 A,B,C edge vectors defined above. The +{gamma}. Note that in this nomenclature, the a, b, and c lattice constants +are the scalar lengths of the edge vectors [a], [b], and [c] defined +above. The relationship between these 6 quantities (a,b,c,alpha,beta,gamma) and the LAMMPS box sizes (lx,ly,lz) = (xhi-xlo,yhi-ylo,zhi-zlo) and tilt factors (xy,xz,yz) is as follows: :c,image(Eqs/box.jpg) +The inverse relationship can be written as follows: + +:c,image(Eqs/box_inverse.jpg) + +The values of {a}, {b}, {c} , {alpha}, {beta} , and {gamma} can be printed +out or accessed by computes using the +"thermo_style custom"_thermo_style.html keywords +{cella}, {cellb}, {cellc}, {cellalpha}, {cellbeta}, {cellgamma}, +respectively. + As discussed on the "dump"_dump.html command doc page, when the BOX BOUNDS for a snapshot is written to a dump file for a triclinic box, an orthogonal bounding box which encloses the triclinic simulation box @@ -863,7 +874,7 @@ on non-equilibrium MD (NEMD) simulations. :line -4.13 NEMD simulations :link(4_13),h4 +6.13 NEMD simulations :link(howto_13),h4 Non-equilibrium molecular dynamics or NEMD simulations are typically used to measure a fluid's rheological properties such as viscosity. @@ -901,13 +912,13 @@ An alternative method for calculating viscosities is provided via the :line -4.14 Extended spherical and aspherical particles :link(4_14),h4 +6.14 Extended spherical and aspherical particles :link(howto_14),h4 Typical MD models treat atoms or particles as point masses. Sometimes, however, it is desirable to have a model with finite-size -particles such as spherioids or aspherical ellipsoids. The difference -is that such particles have a moment of inertia, rotational energy, -and angular momentum. Rotation is induced by torque from interactions +particles such as spheres or aspherical ellipsoids. The difference is +that such particles have a moment of inertia, rotational energy, and +angular momentum. Rotation is induced by torque from interactions with other particles. LAMMPS has several options for running simulations with these kinds of @@ -921,53 +932,61 @@ rigid bodies composed of extended particles :ul Atom styles :h5 -There are 3 "atom styles"_atom_style.html that allow for definition of -finite-size particles: granular, dipole, ellipsoid. +There are 2 "atom styles"_atom_style.html that allow for definition of +finite-size particles: sphere and ellipsoid. The peri atom style also +treats particles as having a volume, but that is internal to the +"pair_style peri"_pair_peri.html potentials. The dipole atom style is +most often used in conjunction with finite-size particles. -Granular particles are spheriods and each particle can have a unique -diameter and mass (or density). These particles store an angular -velocity (omega) and can be acted upon by torque. +The sphere style defines particles that are spheriods and each +particle can have a unique diameter and mass (or density). These +particles store an angular velocity (omega) and can be acted upon by +torque. The "set" command can be used to modify the diameter and mass +of individual particles, after then are created. -Dipolar particles are typically spheriods with a point dipole and each -particle type has a diamater and mass, set by the "shape"_shape.html -and "mass"_mass.html commands. These particles store an angular -velocity (omega) and can be acted upon by torque. They also store an -orientation for the point dipole (mu) which has a length set by the -"dipole"_dipole.html command. The "set"_set.html command can be used -to initialize the orientation of dipole moments. +The ellipsoid style defines particles that are ellipsoids and thus can +be aspherical. Each particle has a shape, specified by 3 diameters, +and mass (or density). These particles store an angular momentum and +their orientation (quaternion), and can be acted upon by torque. They +do not store an angular velocity (omega), which can be in a different +direction than angular momentum, rather they compute it as needed. +The "set" command can be used to modify the diameter, orientation, and +mass of individual particles, after then are created. It also has a +brief explanation of what quaternions are. -Ellipsoid particles are aspherical. Each particle type has an -ellipsoidal shape and mass, defined by the "shape"_shape.html and -"mass"_mass.html commands. These particles store an angular momentum -and their orientation (quaternion), and can be acted upon by torque. -They do not store an angular velocity (omega), which can be in a -different direction than angular momentum, rather they compute it as -needed. Ellipsoidal particles can also store a dipole moment if an -"atom_style hybrid ellipsoid dipole"_atom_style.html is used. The -"set"_set.html command can be used to initialize the orientation of -ellipsoidal particles and has a brief explanation of quaternions. +The dipole style does not define extended particles, but is often +used in conjunction with spherical particles, via a command like + +atom_style hybrid sphere dipole :pre + +This is because when dipoles interact with each other, they induce +torques, and a particle must be extended (i.e. have a moment of +inertia) in order to respond and rotate. See the "atom_style +dipole"_atom_style.html command for details. The "set" command can be +used to modify the orientation and length of the dipole moment of +individual particles, after then are created. Note that if one of these atom styles is used (or multiple styles via the "atom_style hybrid"_atom_style.html command), not all particles in the system are required to be finite-size or aspherical. For example, if the 3 shape parameters are set to the same value, the particle will -be a spheroid rather than an ellipsoid. If the 3 shape parameters are +be a sphere rather than an ellipsoid. If the 3 shape parameters are all set to 0.0 or if the diameter is set to 0.0, it will be a point -particle. If the dipole moment is set to zero, the particle will not -have a point dipole associated with it. The pair styles used to -compute pairwise interactions will typically compute the correct -interaction in these simplified (cheaper) cases. "Pair_style -hybrid"_pair_hybrid.html can be used to insure the correct +particle. If the length of the dipole moment is set to zero, the +particle will not have a point dipole associated with it. The pair +styles used to compute pairwise interactions will typically compute +the correct interaction in these simplified (cheaper) cases. +"Pair_style hybrid"_pair_hybrid.html can be used to insure the correct interactions are computed for the appropriate style of interactions. -Likewise, using groups to partition particles (ellipsoid versus -spheroid versus point particles) will allow you to use the appropriate +Likewise, using groups to partition particles (ellipsoids versus +spheres versus point particles) will allow you to use the appropriate time integrators and temperature computations for each class of particles. See the doc pages for various commands for details. Also note that for "2d simulations"_dimension.html, finite-size -spheroids and ellipsoids are still treated as 3d particles, rather -than as disks or ellipses. This means they have the same moment of -inertia for a 3d extended object. When their temperature is +spheres and ellipsoids are still treated as 3d particles, rather than +as circular disks or ellipses. This means they have the same moment +of inertia for a 3d extended object. When their temperature is coomputed, the correct degrees of freedom are used for rotation in a 2d versus 3d system. @@ -986,15 +1005,14 @@ that generate torque: "pair_style resquared"_pair_resquared.html "pair_style lubricate"_pair_lubricate.html :ul -The "granular pair styles"_pair_gran.html are used with "atom_style -granular"_atom_style.html. The "dipole pair style"_pair_dipole.html -is used with "atom_style dipole"_atom_style.html. The -"GayBerne"_pair_gayberne.html and "REsquared"_pair_resquared.html -potentials require particles have a "shape"_shape.html and are -designed for "ellipsoidal particles"_atom_style.html. The -"lubrication potential"_pair_lubricate.html requires that particles -have a "shape"_shape.html. It can currently only be used with -extended spherical particles. +The "granular pair styles"_pair_gran.html are used with spherical +particles. The "dipole pair style"_pair_dipole.html is used with +"atom_style dipole"_atom_style.html, which could be applied to +spherical or ellipsoidal particles. The "GayBerne"_pair_gayberne.html +and "REsquared"_pair_resquared.html potentials require ellipsoidal +particles, though they will also work if the 3 shape parameters are +the same (a sphere). The "lubrication potential"_pair_lubricate.html +works with spherical particles. Time integration :h5 @@ -1006,8 +1024,8 @@ and angular velocity or angular momentum of the particles: "fix nvt/sphere"_fix_nvt_sphere.html "fix npt/sphere"_fix_npt_sphere.html :ul -Likewise, there are 3 fixes that perform time integration on extended -aspherical particles: +Likewise, there are 3 fixes that perform time integration on +ellipsoids as extended aspherical particles: "fix nve/asphere"_fix_nve_asphere.html "fix nvt/asphere"_fix_nvt_asphere.html @@ -1027,7 +1045,7 @@ extended particles. Computes, thermodynamics, and dump output :h5 There are 4 computes that calculate the temperature or rotational energy -of extended spherical or aspherical particles: +of extended spherical or aspherical particles (ellipsoids): "compute temp/sphere"_compute_temp_sphere.html "compute temp/asphere"_compute_temp_asphere.html @@ -1055,11 +1073,8 @@ particles as a rigid body, computes its inertia tensor, sums the total force and torque on the rigid body each timestep due to forces on its constituent particles, and integrates the motion of the rigid body. -(NOTE: the feature described in the following paragraph has not yet -been released. It will be soon.) - If any of the constituent particles of a rigid body are extended -particles (spheroids or ellipsoids), then their contribution to the +particles (spheres or ellipsoids), then their contribution to the inertia tensor of the body is different than if they were point particles. This means the rotational dynamics of the rigid body will be different. Thus a model of a dimer is different if the dimer @@ -1077,7 +1092,7 @@ particles are point masses. :line -4.15 Output from LAMMPS (thermo, dumps, computes, fixes, variables) :link(4_15),h4 +6.15 Output from LAMMPS (thermo, dumps, computes, fixes, variables) :link(howto_15),h4 There are four basic kinds of LAMMPS output: @@ -1256,6 +1271,11 @@ or local vector quantities as inputs and "reduce" them (sum, min, max, ave) to scalar quantities. These are produced as output values which can be used as input to other output commands. +The "compute slice"_compute_slice.html command take one or more global +vector or array quantities as inputs and extracts a subset of their +values to create a new vector or array. These are produced as output +values which can be used as input to other output commands. + The "compute property/atom"_compute_property_atom.html command takes a list of one or more pre-defined atom attributes (id, x, fx, etc) and stores the values in a per-atom vector or array. These are produced @@ -1348,6 +1368,7 @@ Command: Input: Output: "fixes"_fix.html: N/A: global/per-atom/local scalar/vector/array: "variables"_variable.html: global scalars, per-atom vectors: global scalar, per-atom vector: "compute reduce"_compute_reduce.html: per-atom/local vectors: global scalar/vector: +"compute slice"_compute_slice.html: global vectors/arrays: global vector/array: "compute property/atom"_compute_property_atom.html: per-atom vectors: per-atom vector/array: "compute property/local"_compute_property_local.html: local vectors: local vector/array: "compute atom/molecule"_compute_atom_molecule.html: per-atom vectors: global vector/array: @@ -1361,7 +1382,7 @@ Command: Input: Output: :line -4.16 Thermostatting, barostatting, and computing temperature :link(4_16),h4 +6.16 Thermostatting, barostatting, and computing temperature :link(howto_16),h4 Thermostatting means controlling the temperature of particles in an MD simulation. Barostatting means controlling the pressure. Since the @@ -1423,7 +1444,7 @@ thermostatting can be invoked via the {dpd/tstat} pair style: particles. "Fix nvt/sllod"_fix_nvt_sllod.html also does this, except that it subtracts out a velocity bias due to a deforming box and integrates the SLLOD equations of motion. See the "NEMD -simulations"_#4_13 section of this page for further details. "Fix +simulations"_#howto_13 section of this page for further details. "Fix nvt/sphere"_fix_nvt_sphere.html and "fix nvt/asphere"_fix_nvt_asphere.html thermostat not only translation velocities but also rotational velocities for spherical and aspherical @@ -1512,7 +1533,7 @@ thermodynamic output. :line -4.17 Walls :link(4_17),h4 +6.17 Walls :link(howto_17),h4 Walls in an MD simulation are typically used to bound particle motion, i.e. to serve as a boundary condition. @@ -1586,7 +1607,7 @@ frictional walls, as well as triangulated surfaces. :line -4.18 Elastic constants :link(4_18),h4 +6.18 Elastic constants :link(howto_18),h4 Elastic constants characterize the stiffness of a material. The formal definition is provided by the linear relation that holds between the @@ -1622,12 +1643,12 @@ converge and requires careful post-processing "(Shinoda)"_#Shinoda :line -4.19 Library interface to LAMMPS :link(4_19),h4 +6.19 Library interface to LAMMPS :link(howto_19),h4 -As described in "this section"_Section_start.html#2_4, LAMMPS can be -built as a library, so that it can be called by another code, used in -a "coupled manner"_Section_howto.html#4_10 with other codes, or driven -through a "Python interface"_Section_python.html. +As described in "this section"_Section_start.html#start_4, LAMMPS can +be built as a library, so that it can be called by another code, used +in a "coupled manner"_Section_howto.html#howto_10 with other codes, or +driven through a "Python interface"_Section_python.html. All of these methodologies use a C-style interface to LAMMPS that is provided in the files src/library.cpp and src/library.h. The @@ -1646,11 +1667,12 @@ void lammps_file(void *, char *); char *lammps_command(void *, char *); :pre The lammps_open() function is used to initialize LAMMPS, passing in a -list of strings as if they were "command-line arguments"_#2_6 when -LAMMPS is run in stand-alone mode from the command line, and a MPI -communicator for LAMMPS to run under. It returns a ptr to the LAMMPS -object that is created, and which is used in subsequent library calls. -The lammps_open() function can be called multiple times, to create +list of strings as if they were "command-line +arguments"_Section_start.html#start_6 when LAMMPS is run in +stand-alone mode from the command line, and a MPI communicator for +LAMMPS to run under. It returns a ptr to the LAMMPS object that is +created, and which is used in subsequent library calls. The +lammps_open() function can be called multiple times, to create multiple instances of LAMMPS. LAMMPS will run on the set of processors in the communicator. This @@ -1702,11 +1724,11 @@ grab data from LAMMPS, change it, and put it back into LAMMPS. :line -4.20 Calculating thermal conductivity :link(4_20),h4 +6.20 Calculating thermal conductivity :link(howto_20),h4 The thermal conductivity kappa of a material can be measured in at least 3 ways using various options in LAMMPS. (See "this -section"_Section_howto.html#4_21 of the manual for an analogous +section"_Section_howto.html#howto_21 of the manual for an analogous discussion for viscosity). The thermal conducitivity tensor kappa is a measure of the propensity of a material to transmit heat energy in a diffusive manner as given by Fourier's law @@ -1722,7 +1744,7 @@ scalar. The first method is to setup two thermostatted regions at opposite ends of a simulation box, or one in the middle and one at the end of a periodic box. By holding the two regions at different temperatures -with a "thermostatting fix"_Section_howto.html#4_13, the energy added +with a "thermostatting fix"_Section_howto.html#howto_13, the energy added to the hot region should equal the energy subtracted from the cold region and be proportional to the heat flux moving between the regions. See the paper by "Ikeshoji and Hafskjold"_#Ikeshoji for @@ -1767,11 +1789,11 @@ formalism. :line -4.21 Calculating viscosity :link(4_21),h4 +6.21 Calculating viscosity :link(howto_21),h4 The shear viscosity eta of a fluid can be measured in at least 3 ways using various options in LAMMPS. (See "this -section"_Section_howto.html#4_20 of the manual for an analogous +section"_Section_howto.html#howto_20 of the manual for an analogous discussion for thermal conductivity). Eta is a measure of the propensity of a fluid to transmit momentum in a direction perpendicular to the direction of velocity or momentum flow. @@ -1797,7 +1819,7 @@ dVx/dy. In this case, the Pxy off-diagonal component of the pressure or stress tensor, as calculated by the "compute pressure"_compute_pressure.html command, can also be monitored, which is the J term in the equation above. See "this -section"_Section_howto.html#4_13 of the manual for details on NEMD +section"_Section_howto.html#howto_13 of the manual for details on NEMD simulations. The second method is to perform a reverse non-equilibrium MD diff --git a/doc/Section_intro.html b/doc/Section_intro.html index f9b00bb689..815541a4b2 100644 --- a/doc/Section_intro.html +++ b/doc/Section_intro.html @@ -11,20 +11,22 @@

        1. Introduction

        -

        These sections provide an overview of what LAMMPS can and can't do, -describe what it means for LAMMPS to be an open-source code, and -acknowledge the funding and people who have contributed to LAMMPS over -the years. +

        This section provides an overview of what LAMMPS can and can't do, +describes what it means for LAMMPS to be an open-source code, and +acknowledges the funding and people who have contributed to LAMMPS +over the years.

        -1.1 What is LAMMPS
        -1.2 LAMMPS features
        -1.3 LAMMPS non-features
        -1.4 Open source distribution
        -1.5 Acknowledgments and citations
        +1.1 What is LAMMPS
        +1.2 LAMMPS features
        +1.3 LAMMPS non-features
        +1.4 Open source distribution
        +1.5 Acknowledgments and citations
        -

        1.1 What is LAMMPS +
        + +

        1.1 What is LAMMPS

        LAMMPS is a classical molecular dynamics code that models an ensemble of particles in a liquid, solid, or gaseous state. It can model @@ -49,7 +51,7 @@ WWW Site.

        LAMMPS is a freely-available open-source code, distributed under the terms of the GNU Public License, which means you can use or -modify the code however you wish. See this section for a brief +modify the code however you wish. See this section for a brief discussion of the open-source philosophy.

        @@ -67,7 +69,7 @@ downloaded from the LAMMPS WWW Site.

        LAMMPS was originally developed under a US Department of Energy CRADA (Cooperative Research and Development Agreement) between two DOE labs and 3 companies. It is distributed by Sandia National Labs. -See this section for more information on LAMMPS funding and +See this section for more information on LAMMPS funding and individuals who have contributed to LAMMPS.

        @@ -86,11 +88,11 @@ communicate and store "ghost" atom information for atoms that border their sub-domain. LAMMPS is most efficient (in a parallel sense) for systems whose particles fill a 3d rectangular box with roughly uniform density. Papers with technical details of the algorithms used in -LAMMPS are listed in this section. +LAMMPS are listed in this section.

        -

        1.2 LAMMPS features +

        1.2 LAMMPS features

        This section highlights LAMMPS features, with pointers to specific commands which give more details. If LAMMPS doesn't have your @@ -125,7 +127,8 @@ LAMMPS.

      • metals
      • granular materials
      • coarse-grained mesoscale models -
      • extended spherical and ellipsoidal particles +
      • finite-size spherical and ellipsoidal particles +
      • finite-size line segment (2d) and triangle (3d) particles
      • point dipolar particles
      • rigid collections of particles
      • hybrid combinations of these @@ -139,10 +142,10 @@ commands)

        • pairwise potentials: Lennard-Jones, Buckingham, Morse, Born-Mayer-Huggins, Yukawa, soft, class 2 (COMPASS), hydrogen bond, tabulated
        • charged pairwise potentials: Coulombic, point-dipole -
        • manybody potentials: EAM, Finnis/Sinclair EAM, modified EAM (MEAM), embedded ion method (EIM), Stillinger-Weber, Tersoff, AI-REBO, ReaxFF, COMB -
        • electron force field (eFF) +
        • manybody potentials: EAM, Finnis/Sinclair EAM, modified EAM (MEAM), embedded ion method (EIM), EDIP, ADP, Stillinger-Weber, Tersoff, REBO, AIREBO, ReaxFF, COMB +
        • electron force field (eFF, AWPMD)
        • coarse-grained potentials: DPD, GayBerne, REsquared, colloidal, DLVO -
        • mesoscopic potentials: granular, Peridynamics +
        • mesoscopic potentials: granular, Peridynamics, SPH
        • bond potentials: harmonic, FENE, Morse, nonlinear, class 2, quartic (breakable)
        • angle potentials: harmonic, CHARMM, cosine, cosine/squared, cosine/periodic, class 2 (COMPASS)
        • dihedral potentials: harmonic, CHARMM, multi-harmonic, helix, class 2 (COMPASS), OPLS @@ -246,6 +249,7 @@ molecular dynamics options:
        • real-time visualization and interactive MD
        • atom-to-continuum coupling with finite elements
        • coupled rigid body integration via the POEMS library +
        • grand canonical Monte Carlo insertions/deletions
        • Direct Simulation Monte Carlo for low-density fluids
        • Peridynamics mesoscale modeling
        • targeted and steered molecular dynamics @@ -253,7 +257,7 @@ molecular dynamics options:
        -

        1.3 LAMMPS non-features +

        1.3 LAMMPS non-features

        LAMMPS is designed to efficiently compute Newton's equations of motion for a system of interacting particles. Many of the tools needed to @@ -371,7 +375,7 @@ spatial-decomposition version exist.

        -

        1.4 Open source distribution +

        1.4 Open source distribution

        LAMMPS comes with no warranty of any kind. As each source file states in its header, it is a copyrighted code that is distributed free-of- @@ -416,7 +420,7 @@ Site, or have a suggestion for something to clarify or include, send an email to the developers. -

      • If you find a bug, this section describes +
      • If you find a bug, this section describes how to report it.
      • If you publish a paper using LAMMPS results, send the citation (and @@ -454,7 +458,7 @@ encouraged.
      -

      1.5 Acknowledgments and citations +

      1.5 Acknowledgments and citations

      LAMMPS development has been funded by the US Department of Energy (DOE), through its CRADA, LDRD, ASCI, and Genomes-to-Life @@ -476,146 +480,58 @@ Hierarchical Modeling". -

      The following papers describe the parallel algorithms used in LAMMPS. +

      The following paper describe the basic parallel algorithms used in +LAMMPS. If you use LAMMPS results in your published work, please cite +this paper and include a pointer to the LAMMPS WWW Site +(http://lammps.sandia.gov):

      S. J. Plimpton, Fast Parallel Algorithms for Short-Range Molecular Dynamics, J Comp Phys, 117, 1-19 (1995).

      -

      S. J. Plimpton, R. Pollock, M. Stevens, Particle-Mesh Ewald and -rRESPA for Parallel Molecular Dynamics Simulations, in Proc of the -Eighth SIAM Conference on Parallel Processing for Scientific -Computing, Minneapolis, MN (March 1997). +

      Other papers describing specific algorithms used in LAMMPS are listed +under the Citing LAMMPS link of +the LAMMPS WWW page.

      -

      If you use LAMMPS results in your published work, please cite the J -Comp Phys reference and include a pointer to the LAMMPS WWW Site -(http://lammps.sandia.gov). +

      The Publications link on the +LAMMPS WWW page lists papers that have cited LAMMPS. If your paper is +not listed there for some reason, feel free to send us the info. If +the simulations in your paper produced cool pictures or animations, +we'll be pleased to add them to the +Pictures or +Movies pages of the LAMMPS WWW +site.

      -

      If you send is information about your publication, we'll be pleased to -add it to the Publications page of the LAMMPS WWW Site. Ditto -for a picture or movie for the Pictures or Movies pages. +

      The core group of LAMMPS developers is at Sandia National Labs:

      -

      The core group of LAMMPS developers is at Sandia National Labs. They -include Steve Plimpton, Paul Crozier, and Aidan Thompson and can -be contacted via email: sjplimp, pscrozi, athomps at sandia.gov. +

      • Steve Plimpton, sjplimp at sandia.gov +
      • Aidan Thompson, athomps at sandia.gov +
      • Paul Crozier, pscrozi at sandia.gov +
      +

      The following folks are responsible for significant contributions to +the code, or other aspects of the LAMMPS development effort. Many of +the packages they have written are somewhat unique to LAMMPS and the +code would not be as general-purpose as it is without their expertise +and efforts.

      -

      Here are various folks who have made significant contributions to -features in LAMMPS. The most recent contributions are at the top of -the list. -

      - - -
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      ipp Perl script tool Reese Jones (Sandia)
      eam_database and createatoms tools Xiaowang Zhou (Sandia)
      electron force field (eFF) Andres Jaramillo-Botero and Julius Su (Caltech)
      embedded ion method (EIM) potential Xiaowang Zhou (Sandia)
      COMB potential with charge equilibration Tzu-Ray Shan (U Florida)
      fix ave/correlate Benoit Leblanc, Dave Rigby, Paul Saxe (Materials Design) and Reese Jones (Sandia)
      pair_style peri/lps Mike Parks (Sandia)
      fix msst Lawrence Fried (LLNL), Evan Reed (LLNL, Stanford)
      thermo_style custom tpcpu & spcpu keywords Axel Kohlmeyer (Temple U)
      fix rigid/nve, fix rigid/nvt Tony Sheh and Trung Dac Nguyen (U Michigan)
      public SVN & Git repositories for LAMMPS Axel Kohlmeyer (Temple U) and Bill Goldman (Sandia)
      fix nvt, fix nph, fix npt, Parinello/Rahman dynamics, fix box/relax Aidan Thompson (Sandia)
      compute heat/flux German Samolyuk (ORNL) and Mario Pinto (Computational Research Lab, Pune, India)
      pair yukawa/colloid Randy Schunk (Sandia)
      fix wall/colloid Jeremy Lechman (Sandia)
      pair_style dsmc for Direct Simulation Monte Carlo (DSMC) modeling Paul Crozier (Sandia)
      fix imd for real-time viz and interactive MD Axel Kohlmeyer (Temple Univ)
      concentration-dependent EAM potential Alexander Stukowski (Technical University of Darmstadt)
      parallel replica dymamics (PRD) Mike Brown (Sandia)
      min_style hftn Todd Plantenga (Sandia)
      fix atc Reese Jones, Jon Zimmerman, Jeremy Templeton (Sandia)
      dump cfg Liang Wan (Chinese Academy of Sciences)
      fix nvt with Nose/Hoover chains Andy Ballard (U Maryland)
      pair_style lj/cut/gpu, pair_style gayberne/gpu Mike Brown (Sandia)
      pair_style lj96/cut, bond_style table, angle_style table Chuanfu Luo
      fix langevin tally Carolyn Phillips (U Michigan)
      compute heat/flux for Green-Kubo Reese Jones (Sandia), Philip Howell (Siemens), Vikas Varsney (AFRL)
      region cone Pim Schravendijk
      fix reax/bonds Aidan Thompson (Sandia)
      pair born/coul/long Ahmed Ismail (Sandia)
      fix ttm Paul Crozier (Sandia) and Carolyn Phillips (U Michigan)
      fix box/relax Aidan Thompson and David Olmsted (Sandia)
      ReaxFF potential Aidan Thompson (Sandia) and Hansohl Cho (MIT)
      compute cna/atom Wan Liang (Chinese Academy of Sciences)
      Tersoff/ZBL potential Dave Farrell (Northwestern U)
      peridynamics Mike Parks (Sandia)
      fix smd for steered MD Axel Kohlmeyer (U Penn)
      GROMACS pair potentials Mark Stevens (Sandia)
      lmp2vmd tool Axel Kohlmeyer (U Penn)
      compute group/group Naveen Michaud-Agrawal (Johns Hopkins U)
      CG-CMM user package for coarse-graining Axel Kohlmeyer (U Penn)
      cosine/delta angle potential Axel Kohlmeyer (U Penn)
      VIM editor add-ons for LAMMPS input scripts Gerolf Ziegenhain
      pair lubricate Randy Schunk (Sandia)
      compute ackland/atom Gerolf Zeigenhain
      kspace_style ewald/n, pair_style lj/coul, pair_style buck/coul Pieter in 't Veld (Sandia)
      AI-REBO bond-order potential Ase Henry (MIT)
      making LAMMPS a true "object" that can be instantiated multiple times, e.g. as a library Ben FrantzDale (RPI)
      pymol_asphere viz tool Mike Brown (Sandia)
      NEMD SLLOD integration Pieter in 't Veld (Sandia)
      tensile and shear deformations Pieter in 't Veld (Sandia)
      GayBerne potential Mike Brown (Sandia)
      ellipsoidal particles Mike Brown (Sandia)
      colloid potentials Pieter in 't Veld (Sandia)
      fix heat Paul Crozier and Ed Webb (Sandia)
      neighbor multi and communicate multi Pieter in 't Veld (Sandia)
      MATLAB post-processing scripts Arun Subramaniyan (Purdue)
      triclinic (non-orthogonal) simulation domains Pieter in 't Veld (Sandia)
      thermo_extract tool Vikas Varshney (Wright Patterson AFB)
      fix ave/time and fix ave/spatial Pieter in 't Veld (Sandia)
      MEAM potential Greg Wagner (Sandia)
      optimized pair potentials for lj/cut, charmm/long, eam, morse James Fischer (High Performance Technologies), David Richie and Vincent Natoli (Stone Ridge Technologies)
      fix wall/lj126 Mark Stevens (Sandia)
      Stillinger-Weber and Tersoff potentials Aidan Thompson and Xiaowang Zhou (Sandia)
      region prism Pieter in 't Veld (Sandia)
      LJ tail corrections for energy/pressure Paul Crozier (Sandia)
      fix momentum and recenter Naveen Michaud-Agrawal (Johns Hopkins U)
      multi-letter variable names Naveen Michaud-Agrawal (Johns Hopkins U)
      OPLS dihedral potential Mark Stevens (Sandia)
      POEMS coupled rigid body integrator Rudranarayan Mukherjee (RPI)
      faster pair hybrid potential James Fischer (High Performance Technologies, Inc), Vincent Natoli and David Richie (Stone Ridge Technology)
      breakable bond quartic potential Chris Lorenz and Mark Stevens (Sandia)
      DCD and XTC dump styles Naveen Michaud-Agrawal (Johns Hopkins U)
      grain boundary orientation fix Koenraad Janssens and David Olmsted (Sandia)
      lj/smooth pair potential Craig Maloney (UCSB)
      radius-of-gyration spring fix Naveen Michaud-Agrawal (Johns Hopkins U) and Paul Crozier (Sandia)
      self spring fix Naveen Michaud-Agrawal (Johns Hopkins U)
      EAM CoAl and AlCu potentials Kwang-Reoul Lee (KIST, Korea)
      cosine/squared angle potential Naveen Michaud-Agrawal (Johns Hopkins U)
      helix dihedral potential Naveen Michaud-Agrawal (Johns Hopkins U) and Mark Stevens (Sandia)
      Finnis/Sinclair EAM Tim Lau (MIT)
      dissipative particle dynamics (DPD) potentials Kurt Smith (U Pitt) and Frank van Swol (Sandia)
      TIP4P potential (4-site water) Ahmed Ismail and Amalie Frischknecht (Sandia)
      uniaxial strain fix Carsten Svaneborg (Max Planck Institute)
      thermodynamics enhanced by fix quantities Aidan Thompson (Sandia)
      compressed dump files Erik Luijten (U Illinois)
      cylindrical indenter fix Ravi Agrawal (Northwestern U)
      electric field fix Christina Payne (Vanderbilt U)
      AMBER <-> LAMMPS tool Keir Novik (Univ College London) and Vikas Varshney (U Akron)
      CHARMM <-> LAMMPS tool Pieter in 't Veld and Paul Crozier (Sandia)
      Morse bond potential Jeff Greathouse (Sandia)
      radial distribution functions Paul Crozier & Jeff Greathouse (Sandia)
      force tables for long-range Coulombics Paul Crozier (Sandia)
      targeted molecular dynamics (TMD) Paul Crozier (Sandia) and Christian Burisch (Bochum University, Germany)
      FFT support for SGI SCSL (Altix) Jim Shepherd (Ga Tech)
      lmp2cfg and lmp2traj tools Ara Kooser, Jeff Greathouse, Andrey Kalinichev (Sandia)
      parallel tempering Mark Sears (Sandia)
      embedded atom method (EAM) potential Stephen Foiles (Sandia)
      multi-harmonic dihedral potential Mathias Puetz (Sandia)
      granular force fields and BC Leo Silbert & Gary Grest (Sandia)
      2d Ewald/PPPM Paul Crozier (Sandia)
      CHARMM force fields Paul Crozier (Sandia)
      msi2lmp tool Steve Lustig (Dupont), Mike Peachey & John Carpenter (Cray)
      HTFN energy minimizer Todd Plantenga (Sandia)
      class 2 force fields Eric Simon (Cray)
      NVT/NPT integrators Mark Stevens (Sandia)
      rRESPA Mark Stevens & Paul Crozier (Sandia)
      Ewald and PPPM solvers Roy Pollock (LLNL) -
      - -

      Other CRADA partners involved in the design and testing of LAMMPS were +

      • Axel Kohlmeyer (Temple U), akohlmey at gmail.com, SVN and Git repositories, indefatigable mail list responder, USER-CG-CMM and USER-OMP packages +
      • Roy Pollock (LLNL), Ewald and PPPM solvers +
      • Mike Brown (ORNL), brownw at ornl.gov, GPU package +
      • Greg Wagner (Sandia), gjwagne at sandia.gov, MEAM package for MEAM potential +
      • Mike Parks (Sandia), mlparks at sandia.gov, PERI package for Peridynamics +
      • Rudra Mukherjee (JPL), Rudranarayan.M.Mukherjee at jpl.nasa.gov, POEMS package for articulated rigid body motion +
      • Reese Jones (Sandia) and collaborators, rjones at sandia.gov, USER-ATC package for atom/continuum coupling +
      • Ilya Valuev (JIHT), valuev at physik.hu-berlin.de, USER-AWPMD package for wave-packet MD +
      • Christian Trott (U Tech Ilmenau), christian.trott at tu-ilmenau.de, USER-CUDA package +
      • Andres Jaramillo-Botero (Caltech), ajaramil at wag.caltech.edu, USER-EFF package for electron force field +
      • Pieter in' t Veld (BASF), pieter.intveld at basf.com, USER-EWALDN package for 1/r^N long-range solvers +
      • Christoph Kloss (JKU), Christoph.Kloss at jku.at, USER-LIGGGHTS package for granular models and granular/fluid coupling +
      • Metin Aktulga (LBL), hmaktulga at lbl.gov, USER-REAXC package for C version of ReaxFF +
      • Georg Gunzenmuller (EMI), georg.ganzenmueller at emi.fhg.de, USER-SPH package +
      +

      As discussed in this section, LAMMPS originated +as a cooperative project between DOE labs and industrial +partners. Folks involved in the design and testing of the original +version of LAMMPS were the following:

      • John Carpenter (Mayo Clinic, formerly at Cray Research)
      • Terry Stouch (Lexicon Pharmaceuticals, formerly at Bristol Myers Squibb) diff --git a/doc/Section_intro.txt b/doc/Section_intro.txt index e4c26c8aab..53158cc399 100644 --- a/doc/Section_intro.txt +++ b/doc/Section_intro.txt @@ -8,20 +8,21 @@ 1. Introduction :h3 -These sections provide an overview of what LAMMPS can and can't do, -describe what it means for LAMMPS to be an open-source code, and -acknowledge the funding and people who have contributed to LAMMPS over -the years. +This section provides an overview of what LAMMPS can and can't do, +describes what it means for LAMMPS to be an open-source code, and +acknowledges the funding and people who have contributed to LAMMPS +over the years. -1.1 "What is LAMMPS"_#1_1 -1.2 "LAMMPS features"_#1_2 -1.3 "LAMMPS non-features"_#1_3 -1.4 "Open source distribution"_#1_4 -1.5 "Acknowledgments and citations"_#1_5 :all(b) +1.1 "What is LAMMPS"_#intro_1 +1.2 "LAMMPS features"_#intro_2 +1.3 "LAMMPS non-features"_#intro_3 +1.4 "Open source distribution"_#intro_4 +1.5 "Acknowledgments and citations"_#intro_5 :all(b) +:line :line -1.1 What is LAMMPS :link(1_1),h4 +1.1 What is LAMMPS :link(intro_1),h4 LAMMPS is a classical molecular dynamics code that models an ensemble of particles in a liquid, solid, or gaseous state. It can model @@ -46,7 +47,7 @@ WWW Site"_lws. LAMMPS is a freely-available open-source code, distributed under the terms of the "GNU Public License"_gnu, which means you can use or -modify the code however you wish. See "this section"_#1_4 for a brief +modify the code however you wish. See "this section"_#intro_4 for a brief discussion of the open-source philosophy. :link(gnu,http://www.gnu.org/copyleft/gpl.html) @@ -64,7 +65,7 @@ downloaded from the "LAMMPS WWW Site"_lws. LAMMPS was originally developed under a US Department of Energy CRADA (Cooperative Research and Development Agreement) between two DOE labs and 3 companies. It is distributed by "Sandia National Labs"_snl. -See "this section"_#1_5 for more information on LAMMPS funding and +See "this section"_#intro_5 for more information on LAMMPS funding and individuals who have contributed to LAMMPS. :link(snl,http://www.sandia.gov) @@ -83,11 +84,11 @@ communicate and store "ghost" atom information for atoms that border their sub-domain. LAMMPS is most efficient (in a parallel sense) for systems whose particles fill a 3d rectangular box with roughly uniform density. Papers with technical details of the algorithms used in -LAMMPS are listed in "this section"_#1_5. +LAMMPS are listed in "this section"_#intro_5. :line -1.2 LAMMPS features :link(1_2),h4 +1.2 LAMMPS features :link(intro_2),h4 This section highlights LAMMPS features, with pointers to specific commands which give more details. If LAMMPS doesn't have your @@ -121,7 +122,8 @@ Particle and model types :h4 metals granular materials coarse-grained mesoscale models - extended spherical and ellipsoidal particles + finite-size spherical and ellipsoidal particles + finite-size line segment (2d) and triangle (3d) particles point dipolar particles rigid collections of particles hybrid combinations of these :ul @@ -136,10 +138,10 @@ commands) Yukawa, soft, class 2 (COMPASS), hydrogen bond, tabulated charged pairwise potentials: Coulombic, point-dipole manybody potentials: EAM, Finnis/Sinclair EAM, modified EAM (MEAM), \ - embedded ion method (EIM), Stillinger-Weber, Tersoff, AI-REBO, ReaxFF, COMB - electron force field (eFF) + embedded ion method (EIM), EDIP, ADP, Stillinger-Weber, Tersoff, REBO, AIREBO, ReaxFF, COMB + electron force field (eFF, AWPMD) coarse-grained potentials: DPD, GayBerne, REsquared, colloidal, DLVO - mesoscopic potentials: granular, Peridynamics + mesoscopic potentials: granular, Peridynamics, SPH bond potentials: harmonic, FENE, Morse, nonlinear, class 2, \ quartic (breakable) angle potentials: harmonic, CHARMM, cosine, cosine/squared, cosine/periodic, \ @@ -242,6 +244,7 @@ molecular dynamics options: "real-time visualization and interactive MD"_fix_imd.html "atom-to-continuum coupling"_fix_atc.html with finite elements coupled rigid body integration via the "POEMS"_fix_poems.html library +"grand canonical Monte Carlo"_doc/fix_gcmc.html insertions/deletions "Direct Simulation Monte Carlo"_pair_dsmc.html for low-density fluids "Peridynamics mesoscale modeling"_pair_peri.html "targeted"_fix_tmd.html and "steered"_fix_smd.html molecular dynamics @@ -249,7 +252,7 @@ coupled rigid body integration via the "POEMS"_fix_poems.html library :line -1.3 LAMMPS non-features :link(1_3),h4 +1.3 LAMMPS non-features :link(intro_3),h4 LAMMPS is designed to efficiently compute Newton's equations of motion for a system of interacting particles. Many of the tools needed to @@ -362,7 +365,7 @@ spatial-decomposition version exist. :line -1.4 Open source distribution :link(1_4),h4 +1.4 Open source distribution :link(intro_4),h4 LAMMPS comes with no warranty of any kind. As each source file states in its header, it is a copyrighted code that is distributed free-of- @@ -406,7 +409,7 @@ Site"_lws, or have a suggestion for something to clarify or include, send an email to the "developers"_http://lammps.sandia.gov/authors.html. :l -If you find a bug, "this section"_Section_errors.html#10_2 describes +If you find a bug, "this section"_Section_errors.html#err_2 describes how to report it. :l If you publish a paper using LAMMPS results, send the citation (and @@ -444,7 +447,7 @@ encouraged. :ule,l :line -1.5 Acknowledgments and citations :h4,link(1_5) +1.5 Acknowledgments and citations :h4,link(intro_5) LAMMPS development has been funded by the "US Department of Energy"_doe (DOE), through its CRADA, LDRD, ASCI, and Genomes-to-Life @@ -462,157 +465,59 @@ Hierarchical Modeling". :link(oascr,http://www.sc.doe.gov/ascr/home.html) :link(ober,http://www.er.doe.gov/production/ober/ober_top.html) -The following papers describe the parallel algorithms used in LAMMPS. +The following paper describe the basic parallel algorithms used in +LAMMPS. If you use LAMMPS results in your published work, please cite +this paper and include a pointer to the "LAMMPS WWW Site"_lws +(http://lammps.sandia.gov): S. J. Plimpton, [Fast Parallel Algorithms for Short-Range Molecular Dynamics], J Comp Phys, 117, 1-19 (1995). -S. J. Plimpton, R. Pollock, M. Stevens, [Particle-Mesh Ewald and -rRESPA for Parallel Molecular Dynamics Simulations], in Proc of the -Eighth SIAM Conference on Parallel Processing for Scientific -Computing, Minneapolis, MN (March 1997). +Other papers describing specific algorithms used in LAMMPS are listed +under the "Citing LAMMPS link"_http://lammps.sandia.gov/cite.html of +the LAMMPS WWW page. -If you use LAMMPS results in your published work, please cite the J -Comp Phys reference and include a pointer to the "LAMMPS WWW Site"_lws -(http://lammps.sandia.gov). +The "Publications link"_http://lammps.sandia.gov/papers.html on the +LAMMPS WWW page lists papers that have cited LAMMPS. If your paper is +not listed there for some reason, feel free to send us the info. If +the simulations in your paper produced cool pictures or animations, +we'll be pleased to add them to the +"Pictures"_http://lammps.sandia.gov/pictures.html or +"Movies"_http://lammps.sandia.gov/movies.html pages of the LAMMPS WWW +site. -If you send is information about your publication, we'll be pleased to -add it to the Publications page of the "LAMMPS WWW Site"_lws. Ditto -for a picture or movie for the Pictures or Movies pages. +The core group of LAMMPS developers is at Sandia National Labs: -The core group of LAMMPS developers is at Sandia National Labs. They -include "Steve Plimpton"_sjp, Paul Crozier, and Aidan Thompson and can -be contacted via email: sjplimp, pscrozi, athomps at sandia.gov. +Steve Plimpton, sjplimp at sandia.gov +Aidan Thompson, athomps at sandia.gov +Paul Crozier, pscrozi at sandia.gov :ul -Here are various folks who have made significant contributions to -features in LAMMPS. The most recent contributions are at the top of -the list. +The following folks are responsible for significant contributions to +the code, or other aspects of the LAMMPS development effort. Many of +the packages they have written are somewhat unique to LAMMPS and the +code would not be as general-purpose as it is without their expertise +and efforts. -:link(sjp,http://www.sandia.gov/~sjplimp) +Axel Kohlmeyer (Temple U), akohlmey at gmail.com, SVN and Git repositories, indefatigable mail list responder, USER-CG-CMM and USER-OMP packages +Roy Pollock (LLNL), Ewald and PPPM solvers +Mike Brown (ORNL), brownw at ornl.gov, GPU package +Greg Wagner (Sandia), gjwagne at sandia.gov, MEAM package for MEAM potential +Mike Parks (Sandia), mlparks at sandia.gov, PERI package for Peridynamics +Rudra Mukherjee (JPL), Rudranarayan.M.Mukherjee at jpl.nasa.gov, POEMS package for articulated rigid body motion +Reese Jones (Sandia) and collaborators, rjones at sandia.gov, USER-ATC package for atom/continuum coupling +Ilya Valuev (JIHT), valuev at physik.hu-berlin.de, USER-AWPMD package for wave-packet MD +Christian Trott (U Tech Ilmenau), christian.trott at tu-ilmenau.de, USER-CUDA package +Andres Jaramillo-Botero (Caltech), ajaramil at wag.caltech.edu, USER-EFF package for electron force field +Pieter in' t Veld (BASF), pieter.intveld at basf.com, USER-EWALDN package for 1/r^N long-range solvers +Christoph Kloss (JKU), Christoph.Kloss at jku.at, USER-LIGGGHTS package for granular models and granular/fluid coupling +Metin Aktulga (LBL), hmaktulga at lbl.gov, USER-REAXC package for C version of ReaxFF +Georg Gunzenmuller (EMI), georg.ganzenmueller at emi.fhg.de, USER-SPH package :ul -ipp Perl script tool : Reese Jones (Sandia) -eam_database and createatoms tools : Xiaowang Zhou (Sandia) -electron force field (eFF) : Andres Jaramillo-Botero and Julius Su (Caltech) -embedded ion method (EIM) potential : Xiaowang Zhou (Sandia) -COMB potential with charge equilibration : Tzu-Ray Shan (U Florida) -fix ave/correlate : Benoit Leblanc, Dave Rigby, Paul Saxe (Materials Design) and Reese Jones (Sandia) -pair_style peri/lps : Mike Parks (Sandia) -fix msst : Lawrence Fried (LLNL), Evan Reed (LLNL, Stanford) -thermo_style custom tpcpu & spcpu keywords : Axel Kohlmeyer (Temple U) -fix rigid/nve, fix rigid/nvt : Tony Sheh and Trung Dac Nguyen (U Michigan) -public SVN & Git repositories for LAMMPS : Axel Kohlmeyer (Temple U) and Bill Goldman (Sandia) -fix nvt, fix nph, fix npt, Parinello/Rahman dynamics, fix box/relax : Aidan Thompson (Sandia) -compute heat/flux : German Samolyuk (ORNL) and Mario Pinto (Computational Research Lab, Pune, India) -pair yukawa/colloid : Randy Schunk (Sandia) -fix wall/colloid : Jeremy Lechman (Sandia) -pair_style dsmc for Direct Simulation Monte Carlo (DSMC) modeling : Paul Crozier (Sandia) -fix imd for real-time viz and interactive MD : Axel Kohlmeyer (Temple Univ) -concentration-dependent EAM potential : Alexander Stukowski (Technical University of Darmstadt) -parallel replica dymamics (PRD) : Mike Brown (Sandia) -min_style hftn : Todd Plantenga (Sandia) -fix atc : Reese Jones, Jon Zimmerman, Jeremy Templeton (Sandia) -dump cfg : Liang Wan (Chinese Academy of Sciences) -fix nvt with Nose/Hoover chains : Andy Ballard (U Maryland) -pair_style lj/cut/gpu, pair_style gayberne/gpu : Mike Brown (Sandia) -pair_style lj96/cut, bond_style table, angle_style table : Chuanfu Luo -fix langevin tally : Carolyn Phillips (U Michigan) -compute heat/flux for Green-Kubo : Reese Jones (Sandia), Philip Howell (Siemens), Vikas Varsney (AFRL) -region cone : Pim Schravendijk -fix reax/bonds : Aidan Thompson (Sandia) -pair born/coul/long : Ahmed Ismail (Sandia) -fix ttm : Paul Crozier (Sandia) and Carolyn Phillips (U Michigan) -fix box/relax : Aidan Thompson and David Olmsted (Sandia) -ReaxFF potential : Aidan Thompson (Sandia) and Hansohl Cho (MIT) -compute cna/atom : Wan Liang (Chinese Academy of Sciences) -Tersoff/ZBL potential : Dave Farrell (Northwestern U) -peridynamics : Mike Parks (Sandia) -fix smd for steered MD : Axel Kohlmeyer (U Penn) -GROMACS pair potentials : Mark Stevens (Sandia) -lmp2vmd tool : Axel Kohlmeyer (U Penn) -compute group/group : Naveen Michaud-Agrawal (Johns Hopkins U) -CG-CMM user package for coarse-graining : Axel Kohlmeyer (U Penn) -cosine/delta angle potential : Axel Kohlmeyer (U Penn) -VIM editor add-ons for LAMMPS input scripts : Gerolf Ziegenhain -pair lubricate : Randy Schunk (Sandia) -compute ackland/atom : Gerolf Zeigenhain -kspace_style ewald/n, pair_style lj/coul, pair_style buck/coul : \ - Pieter in 't Veld (Sandia) -AI-REBO bond-order potential : Ase Henry (MIT) -making LAMMPS a true "object" that can be instantiated multiple times, \ - e.g. as a library : Ben FrantzDale (RPI) -pymol_asphere viz tool : Mike Brown (Sandia) -NEMD SLLOD integration : Pieter in 't Veld (Sandia) -tensile and shear deformations : Pieter in 't Veld (Sandia) -GayBerne potential : Mike Brown (Sandia) -ellipsoidal particles : Mike Brown (Sandia) -colloid potentials : Pieter in 't Veld (Sandia) -fix heat : Paul Crozier and Ed Webb (Sandia) -neighbor multi and communicate multi : Pieter in 't Veld (Sandia) -MATLAB post-processing scripts : Arun Subramaniyan (Purdue) -triclinic (non-orthogonal) simulation domains : Pieter in 't Veld (Sandia) -thermo_extract tool: Vikas Varshney (Wright Patterson AFB) -fix ave/time and fix ave/spatial : Pieter in 't Veld (Sandia) -MEAM potential : Greg Wagner (Sandia) -optimized pair potentials for lj/cut, charmm/long, eam, morse : \ - James Fischer (High Performance Technologies), \ - David Richie and Vincent Natoli (Stone Ridge Technologies) -fix wall/lj126 : Mark Stevens (Sandia) -Stillinger-Weber and Tersoff potentials : Aidan Thompson and Xiaowang Zhou (Sandia) -region prism : Pieter in 't Veld (Sandia) -LJ tail corrections for energy/pressure : Paul Crozier (Sandia) -fix momentum and recenter : Naveen Michaud-Agrawal (Johns Hopkins U) -multi-letter variable names : Naveen Michaud-Agrawal (Johns Hopkins U) -OPLS dihedral potential: Mark Stevens (Sandia) -POEMS coupled rigid body integrator: Rudranarayan Mukherjee (RPI) -faster pair hybrid potential: James Fischer \ - (High Performance Technologies, Inc), Vincent Natoli and \ - David Richie (Stone Ridge Technology) -breakable bond quartic potential: Chris Lorenz and Mark Stevens (Sandia) -DCD and XTC dump styles: Naveen Michaud-Agrawal (Johns Hopkins U) -grain boundary orientation fix : Koenraad Janssens and David Olmsted (Sandia) -lj/smooth pair potential : Craig Maloney (UCSB) -radius-of-gyration spring fix : Naveen Michaud-Agrawal (Johns Hopkins U) and \ - Paul Crozier (Sandia) -self spring fix : Naveen Michaud-Agrawal (Johns Hopkins U) -EAM CoAl and AlCu potentials : Kwang-Reoul Lee (KIST, Korea) -cosine/squared angle potential : Naveen Michaud-Agrawal (Johns Hopkins U) -helix dihedral potential : Naveen Michaud-Agrawal (Johns Hopkins U) and \ - Mark Stevens (Sandia) -Finnis/Sinclair EAM: Tim Lau (MIT) -dissipative particle dynamics (DPD) potentials: Kurt Smith (U Pitt) and \ - Frank van Swol (Sandia) -TIP4P potential (4-site water): Ahmed Ismail and Amalie Frischknecht (Sandia) -uniaxial strain fix: Carsten Svaneborg (Max Planck Institute) -thermodynamics enhanced by fix quantities: Aidan Thompson (Sandia) -compressed dump files: Erik Luijten (U Illinois) -cylindrical indenter fix: Ravi Agrawal (Northwestern U) -electric field fix: Christina Payne (Vanderbilt U) -AMBER <-> LAMMPS tool: Keir Novik (Univ College London) and \ - Vikas Varshney (U Akron) -CHARMM <-> LAMMPS tool: Pieter in 't Veld and Paul Crozier (Sandia) -Morse bond potential: Jeff Greathouse (Sandia) -radial distribution functions: Paul Crozier & Jeff Greathouse (Sandia) -force tables for long-range Coulombics: Paul Crozier (Sandia) -targeted molecular dynamics (TMD): Paul Crozier (Sandia) and \ - Christian Burisch (Bochum University, Germany) -FFT support for SGI SCSL (Altix): Jim Shepherd (Ga Tech) -lmp2cfg and lmp2traj tools: Ara Kooser, Jeff Greathouse, \ - Andrey Kalinichev (Sandia) -parallel tempering: Mark Sears (Sandia) -embedded atom method (EAM) potential: Stephen Foiles (Sandia) -multi-harmonic dihedral potential: Mathias Puetz (Sandia) -granular force fields and BC: Leo Silbert & Gary Grest (Sandia) -2d Ewald/PPPM: Paul Crozier (Sandia) -CHARMM force fields: Paul Crozier (Sandia) -msi2lmp tool: Steve Lustig (Dupont), Mike Peachey & John Carpenter (Cray) -HTFN energy minimizer: Todd Plantenga (Sandia) -class 2 force fields: Eric Simon (Cray) -NVT/NPT integrators: Mark Stevens (Sandia) -rRESPA: Mark Stevens & Paul Crozier (Sandia) -Ewald and PPPM solvers: Roy Pollock (LLNL) : :tb(s=:) +As discussed in "this section"_Section_history.html, LAMMPS originated +as a cooperative project between DOE labs and industrial +partners. Folks involved in the design and testing of the original +version of LAMMPS were the following: -Other CRADA partners involved in the design and testing of LAMMPS were - John Carpenter (Mayo Clinic, formerly at Cray Research) Terry Stouch (Lexicon Pharmaceuticals, formerly at Bristol Myers Squibb) Steve Lustig (Dupont) diff --git a/doc/Section_modify.html b/doc/Section_modify.html index 5b05b3e50f..8a5604d169 100644 --- a/doc/Section_modify.html +++ b/doc/Section_modify.html @@ -11,8 +11,26 @@ Section
        -

        8. Modifying & extending LAMMPS +

        10. Modifying & extending LAMMPS

        +

        This section describes how to customize LAMMPS by modifying +and extending its source code. +

        +10.1 Atom styles
        +10.2 Bond, angle, dihedral, improper potentials
        +10.3 Compute styles
        +10.4 Dump styles
        +10.5 Dump custom output options
        +10.6 Fix styles which include integrators, temperature and pressure control, force constraints, boundary conditions, diagnostic output, etc
        +10.7 Input script commands
        +10.8 Kspace computations
        +10.9 Minimization styles
        +10.10 Pairwise potentials
        +10.11 Region styles
        +10.12 Thermodynamic output options
        +10.13 Variable options
        +10.14 Submitting new features for inclusion in LAMMPS
        +

        LAMMPS is designed in a modular fashion so as to be easy to modify and extend with new functionality. In fact, about 75% of its source code is files added in this fashion. @@ -22,7 +40,7 @@ with minimal instructions. If you add a new feature to LAMMPS and think it will be of interest to general users, we encourage you to submit it to the developers for inclusion in the released version of LAMMPS. Information about how to do this is provided -below. +below.

        The best way to add a new feature is to find a similar feature in LAMMPS and look at the corresponding source and header files to figure @@ -75,28 +93,9 @@ the executable and can be invoked with a pair_style command like the example above. Arguments like 0.1 and 3.5 can be defined and processed by your new class.

        -

        Here is a list of the new features that can be added in this way, -along with information about how to submit your features for inclusion -in the LAMMPS distribution. -

        - - -

        As illustrated by the pairwise example, these options are referred to -in the LAMMPS documentation as the "style" of a particular command. +

        As illustrated by this pairwise example, many kinds of options are +referred to in the LAMMPS documentation as the "style" of a particular +command.

        The instructions below give the header file for the base class that these styles are derived from. Public variables in that file are ones @@ -108,15 +107,9 @@ LAMMPS expects. Virtual functions that are not set to 0 are functions you can optionally define.

        Additionally, new output options can be added directly to the -thermo.cpp, dump_custom.cpp, and variable.cpp files as explained in -these sections: +thermo.cpp, dump_custom.cpp, and variable.cpp files as explained +below.

        - -
        -

        Here are additional guidelines for modifying LAMMPS and adding new functionality:

        @@ -136,52 +129,58 @@ command.
      • If you add something you think is truly useful and doesn't impact LAMMPS performance when it isn't used, send an email to the developers. We might be -interested in adding it to the LAMMPS distribution. +interested in adding it to the LAMMPS distribution. See further +details on this at the bottom of this page.
      -

      Atom styles +

      10.1 Atom styles

      -

      Classes that define an atom style are derived from the Atom class. -The atom style determines what quantities are associated with an atom. -A new atom style can be created if one of the existing atom styles -does not define all the arrays you need to store and communicate with -atoms. +

      Classes that define an atom style are derived from the AtomVec class +and managed by the Atom class. The atom style determines what +quantities are associated with an atom. A new atom style can be +created if one of the existing atom styles does not define all +the arrays you need to store and communicate with atoms.

      Atom_vec_atomic.cpp is a simple example of an atom style.

      Here is a brief description of methods you define in your new derived -class. See atom.h for details. +class. See atom_vec.h for details.

      - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      grow re-allocate atom arrays to longer lengths
      copy copy info for one atom to another atom's array locations
      pack_comm store an atom's info in a buffer communicated every timestep
      pack_comm_vel add velocity info to buffer
      pack_comm_one store extra info unique to this atom style
      unpack_comm retrieve an atom's info from the buffer
      unpack_comm_vel also retrieve velocity info
      unpack_comm_one retreive extra info unique to this atom style
      pack_reverse store an atom's info in a buffer communicating partial forces
      pack_reverse_one store extra info unique to this atom style
      unpack_reverse retrieve an atom's info from the buffer
      unpack_reverse_one retreive extra info unique to this atom style
      pack_border store an atom's info in a buffer communicated on neighbor re-builds
      pack_border_vel add velocity info to buffer
      pack_border_one store extra info unique to this atom style
      unpack_border retrieve an atom's info from the buffer
      unpack_border_vel also retrieve velocity info
      unpack_border_one retreive extra info unique to this atom style
      pack_exchange store all an atom's info to migrate to another processor
      unpack_exchange retrieve an atom's info from the buffer
      size_restart number of restart quantities associated with proc's atoms
      pack_restart pack atom quantities into a buffer
      unpack_restart unpack atom quantities from a buffer
      create_atom create an individual atom of this style
      data_atom parse an atom line from the data file
      memory_usage tally memory allocated by atom arrays +
      init one time setup (optional)
      grow re-allocate atom arrays to longer lengths (required)
      grow_reset make array pointers in Atom and AtomVec classes consistent (required)
      copy copy info for one atom to another atom's array locations (required)
      pack_comm store an atom's info in a buffer communicated every timestep (required)
      pack_comm_vel add velocity info to communication buffer (required)
      pack_comm_hybrid store extra info unique to this atom style (optional)
      unpack_comm retrieve an atom's info from the buffer (required)
      unpack_comm_vel also retrieve velocity info (required)
      unpack_comm_hybrid retreive extra info unique to this atom style (optional)
      pack_reverse store an atom's info in a buffer communicating partial forces (required)
      pack_reverse_hybrid store extra info unique to this atom style (optional)
      unpack_reverse retrieve an atom's info from the buffer (required)
      unpack_reverse_hybrid retreive extra info unique to this atom style (optional)
      pack_border store an atom's info in a buffer communicated on neighbor re-builds (required)
      pack_border_vel add velocity info to buffer (required)
      pack_border_hybrid store extra info unique to this atom style (optional)
      unpack_border retrieve an atom's info from the buffer (required)
      unpack_border_vel also retrieve velocity info (required)
      unpack_border_hybrid retreive extra info unique to this atom style (optional)
      pack_exchange store all an atom's info to migrate to another processor (required)
      unpack_exchange retrieve an atom's info from the buffer (required)
      size_restart number of restart quantities associated with proc's atoms (required)
      pack_restart pack atom quantities into a buffer (required)
      unpack_restart unpack atom quantities from a buffer (required)
      create_atom create an individual atom of this style (required)
      data_atom parse an atom line from the data file (required)
      data_atom_hybrid parse additional atom info unique to this atom style (optional)
      data_vel parse one line of velocity information from data file (optional)
      data_vel_hybrid parse additional velocity data unique to this atom style (optional)
      memory_usage tally memory allocated by atom arrays (required)

      The constructor of the derived class sets values for several variables @@ -192,7 +191,7 @@ modify.

      -

      Bond, angle, dihedral, improper potentials +

      10.2 Bond, angle, dihedral, improper potentials

      Classes that compute molecular interactions are derived from the Bond, Angle, Dihedral, and Improper classes. New styles can be created to @@ -202,21 +201,26 @@ add new potentials to LAMMPS. the harmonic forms of the angle, dihedral, and improper style commands.

      -

      Here is a brief description of methods you define in your new derived -bond class. See bond.h, angle.h, dihedral.h, and improper.h for -details. +

      Here is a brief description of common methods you define in your +new derived class. See bond.h, angle.h, dihedral.h, and improper.h +for details and specific additional methods.

      - - - - - + + + + + + + + +
      compute compute the molecular interactions
      coeff set coefficients for one bond type
      equilibrium_distance length of bond, used by SHAKE
      write & read_restart writes/reads coeffs to restart files
      single force and energy of a single bond +
      init check if all coefficients are set, calls init_style (optional)
      init_style check if style specific conditions are met (optional)
      compute compute the molecular interactions (required)
      settings apply global settings for all types (optional)
      coeff set coefficients for one type (required)
      equilibrium_distance length of bond, used by SHAKE (required, bond only)
      equilibrium_angle opening of angle, used by SHAKE (required, angle only)
      write & read_restart writes/reads coeffs to restart files (required)
      single force and energy of a single bond or angle (required, bond or angle only)
      memory_usage tally memory allocated by the style (optional)
      -

      Compute styles +

      10.3 Compute styles

      Classes that compute scalar and vector quantities like temperature and the pressure tensor, as well as classes that compute per-atom @@ -232,21 +236,28 @@ per-atom kinetic energy. class. See compute.h for details.

      - - - - - - - - + + + + + + + + + + + + + +
      compute_scalar compute a scalar quantity
      compute_vector compute a vector of quantities
      compute_peratom compute one or more quantities per atom
      pack_comm pack a buffer with items to communicate
      unpack_comm unpack the buffer
      pack_reverse pack a buffer with items to reverse communicate
      unpack_reverse unpack the buffer
      memory_usage tally memory usage +
      init perform one time setup (required)
      init_list neighbor list setup, if needed (optional)
      compute_scalar compute a scalar quantity (optional)
      compute_vector compute a vector of quantities (optional)
      compute_peratom compute one or more quantities per atom (optional)
      compute_local compute one or more quantities per processor (optional)
      pack_comm pack a buffer with items to communicate (optional)
      unpack_comm unpack the buffer (optional)
      pack_reverse pack a buffer with items to reverse communicate (optional)
      unpack_reverse unpack the buffer (optional)
      remove_bias remove velocity bias from one atom (optional)
      remove_bias_all remove velocity bias from all atoms in group (optional)
      restore_bias restore velocity bias for one atom after remove_bias (optional)
      restore_bias_all same as before, but for all atoms in group (optional)
      memory_usage tally memory usage (optional)
      -

      Dump styles +

      10.4 Dump styles

      -

      Dump custom output options +

      10.5 Dump custom output options

      Classes that dump per-atom info to files are derived from the Dump class. To dump new quantities or in a new format, a new derived dump @@ -277,7 +288,7 @@ half-dozen or so locations where code will need to be added.

      -

      Fix styles +

      10.6 Fix styles

      In LAMMPS, a "fix" is any operation that is computed during timestepping that alters some property of the system. Essentially @@ -297,34 +308,59 @@ implement. derived class. See fix.h for details.

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      setmask determines when the fix is called during the timestep
      init initialization before a run
      setup called immediately before the 1st timestep
      initial_integrate called at very beginning of each timestep
      pre_exchange called before atom exchange on re-neighboring steps
      pre_neighbor called before neighbor list build
      post_force called after pair & molecular forces are computed
      final_integrate called at end of each timestep
      end_of_step called at very end of timestep
      write_restart dumps fix info to restart file
      restart uses info from restart file to re-initialize the fix
      grow_arrays allocate memory for atom-based arrays used by fix
      copy_arrays copy atom info when an atom migrates to a new processor
      memory_usage report memory used by fix
      pack_exchange store atom's data in a buffer
      unpack_exchange retrieve atom's data from a buffer
      pack_restart store atom's data for writing to restart file
      unpack_restart retrieve atom's data from a restart file buffer
      size_restart size of atom's data
      maxsize_restart max size of atom's data
      initial_integrate_respa same as initial_integrate, but for rRESPA
      post_force_respa same as post_force, but for rRESPA
      final_integrate_respa same as final_integrate, but for rRESPA
      pack_comm pack a buffer to communicate a per-atom quantity
      unpack_comm unpack a buffer to communicate a per-atom quantity
      pack_reverse_comm pack a buffer to reverse communicate a per-atom quantity
      unpack_reverse_comm unpack a buffer to reverse communicate a per-atom quantity
      thermo compute quantities for thermodynamic output +
      setmask determines when the fix is called during the timestep (required)
      init initialization before a run (optional)
      setup_pre_exchange called before atom exchange in setup (optional)
      setup_pre_force called before force computation in setup (optional)
      setup called immediately before the 1st timestep and after forces are computed (optional)
      min_setup_pre_force like setup_pre_force, but for minimizations instead of MD runs (optional)
      min_setup like setup, but for minimizations instead of MD runs (optional)
      initial_integrate called at very beginning of each timestep (optional)
      pre_exchange called before atom exchange on re-neighboring steps (optional)
      pre_neighbor called before neighbor list build (optional)
      pre_force called after pair & molecular forces are computed (optional)
      post_force called after pair & molecular forces are computed and communicated (optional)
      final_integrate called at end of each timestep (optional)
      end_of_step called at very end of timestep (optional)
      write_restart dumps fix info to restart file (optional)
      restart uses info from restart file to re-initialize the fix (optional)
      grow_arrays allocate memory for atom-based arrays used by fix (optional)
      copy_arrays copy atom info when an atom migrates to a new processor (optional)
      pack_exchange store atom's data in a buffer (optional)
      unpack_exchange retrieve atom's data from a buffer (optional)
      pack_restart store atom's data for writing to restart file (optional)
      unpack_restart retrieve atom's data from a restart file buffer (optional)
      size_restart size of atom's data (optional)
      maxsize_restart max size of atom's data (optional)
      setup_pre_force_respa same as setup_pre_force, but for rRESPA (optional)
      initial_integrate_respa same as initial_integrate, but for rRESPA (optional)
      post_integrate_respa called after the first half integration step is done in rRESPA (optional)
      pre_force_respa same as pre_force, but for rRESPA (optional)
      post_force_respa same as post_force, but for rRESPA (optional)
      final_integrate_respa same as final_integrate, but for rRESPA (optional)
      min_pre_force called after pair & molecular forces are computed in minimizer (optional)
      min_post_force called after pair & molecular forces are computed and communicated in minmizer (optional)
      min_store store extra data for linesearch based minimization on a LIFO stack (optional)
      min_pushstore push the minimization LIFO stack one element down (optional)
      min_popstore pop the minimization LIFO stack one element up (optional)
      min_clearstore clear minimization LIFO stack (optional)
      min_step reset or move forward on line search minimization (optional)
      min_dof report number of degrees of freedom added by this fix in minimization (optional)
      max_alpha report maximum allowed step size during linesearch minimization (optional)
      pack_comm pack a buffer to communicate a per-atom quantity (optional)
      unpack_comm unpack a buffer to communicate a per-atom quantity (optional)
      pack_reverse_comm pack a buffer to reverse communicate a per-atom quantity (optional)
      unpack_reverse_comm unpack a buffer to reverse communicate a per-atom quantity (optional)
      dof report number of degrees of freedom removed by this fix during MD (optional)
      compute_scalar return a global scalar property that the fix computes (optional)
      compute_vector return a component of a vector property that the fix computes (optional)
      compute_array return a component of an array property that the fix computes (optional)
      deform called when the box size is changed (optional)
      reset_target called when a change of the target temperature is requested during a run (optional)
      reset_dt is called when a change of the time step is requested during a run (optional)
      modify_param called when a fix_modify request is executed (optional)
      memory_usage report memory used by fix (optional)
      thermo compute quantities for thermodynamic output (optional)

      Typically, only a small fraction of these methods are defined for a @@ -355,7 +391,7 @@ quantities and/or to be summed to the potential energy of the system.

      -

      Input script commands +

      10.7 Input script commands

      New commands can be added to LAMMPS input scripts by adding new classes that have a "command" method. For example, the create_atoms, @@ -377,7 +413,7 @@ needed.

      -

      Kspace computations +

      10.8 Kspace computations

      Classes that compute long-range Coulombic interactions via K-space representations (Ewald, PPPM) are derived from the KSpace class. New @@ -397,7 +433,7 @@ class. See kspace.h for details.

      -

      Minimization solvers +

      10.9 Minimization styles

      Classes that perform energy minimization derived from the Min class. New styles can be created to add new minimization algorithms to @@ -416,7 +452,7 @@ class. See min.h for details.

      -

      Pairwise potentials +

      10.10 Pairwise potentials

      Classes that compute pairwise interactions are derived from the Pair class. In LAMMPS, pairwise calculation include manybody potentials @@ -445,7 +481,7 @@ includes some optional methods to enable its use with rRESPA.

      -

      Region styles +

      10.11 Region styles

      Classes that define geometric regions are derived from the Region class. Regions are used elsewhere in LAMMPS to group atoms, delete @@ -463,17 +499,16 @@ class. See region.h for details.

      -

      Thermodynamic output options +

      10.12 Thermodynamic output options

      There is one class that computes and prints thermodynamic information to the screen and log file; see the file thermo.cpp.

      -

      There are several styles defined in thermo.cpp: "one", "multi", -"granular", etc. There is also a flexible "custom" style which allows -the user to explicitly list keywords for quantities to print when -thermodynamic info is output. See the -thermo_style command for a list of defined -quantities. +

      There are two styles defined in thermo.cpp: "one" and "multi". There +is also a flexible "custom" style which allows the user to explicitly +list keywords for quantities to print when thermodynamic info is +output. See the thermo_style command for a list +of defined quantities.

      The thermo styles (one, multi, etc) are simply lists of keywords. Adding a new style thus only requires defining a new list of keywords. @@ -493,7 +528,7 @@ by adding a new keyword to the thermo command.

      -

      Variable options +

      10.13 Variable options

      There is one class that computes and stores variable information in LAMMPS; see the file variable.cpp. The value @@ -533,25 +568,29 @@ then be accessed by variables) was discussed

      -

      Submitting new features to the developers to include in LAMMPS +
      + +

      10.14 Submitting new features for inclusion in LAMMPS

      We encourage users to submit new features that they add to LAMMPS to the developers, especially if -you think they will be useful to other users. If they are broadly -useful we may add them as core files to LAMMPS or as part of a -standard package. Else we will add them as a -user-contributed package. Examples of user packages are in src -sub-directories that start with USER. You can see a list of the both -standard and user packages by typing "make package" in the LAMMPS src -directory. +you think the features will be of interest to other users. If they +are broadly useful we may add them as core files to LAMMPS or as part +of a standard package. Else we will add +them as a user-contributed package or file. Examples of user packages +are in src sub-directories that start with USER. The USER-MISC +package is simply a collection of (mostly) unrelated single files, +which is the simplest way to have your contribution quickly added to +the LAMMPS distribution. You can see a list of the both standard and +user packages by typing "make package" in the LAMMPS src directory.

      -

      With user packages, all we are really providing (aside from the fame -and fortune that accompanies having your name in the source code and -on the Authors page of the -LAMMPS WWW site), is a means for you to distribute your work to -the LAMMPS user community and a mechanism for others to easily try out -your new feature. This may help you find bugs or make contact with -new collaborators. Note that you're also implicitly agreeing to +

      With user packages and files, all we are really providing (aside from +the fame and fortune that accompanies having your name in the source +code and on the Authors page +of the LAMMPS WWW site), is a means for you to distribute your +work to the LAMMPS user community and a mechanism for others to easily +try out your new feature. This may help you find bugs or make contact +with new collaborators. Note that you're also implicitly agreeing to support your code which means answer questions, fix bugs, and maintain it if LAMMPS changes.

      @@ -560,42 +599,56 @@ features of various kinds to LAMMPS. Packages are simply collections of one or more new class files which are invoked as a new "style" within a LAMMPS input script. If designed correctly, these additions do not require changes to the main core of LAMMPS; they are simply -add-on files. If you think your new feature does requires changes in -other LAMMPS files, you'll need to communicate with the +add-on files. If you think your new feature requires non-trivial +changes in core LAMMPS files, you'll need to communicate with the developers, since we may or may -not want to make those changes. +not want to make those changes. An example of a trivial change is +making a parent-class method "virtual" when you derive a new child +class from it.

      -

      Here is what you need to do to submit a user package for our -consideration. Following these steps will save time for both you and -us. See existing package files for examples. +

      Here is what you need to do to submit a user package or single file +for our consideration. Following these steps will save time for both +you and us. See existing package files for examples.

      -

      Your user package will be a directory with a name like USER-FOO. In +

      • All source files you provide must compile with the most current +version of LAMMPS. + +
      • If your contribution is a single file (actually a *.cpp and *.h file) +it can most rapidly be added to the USER-MISC directory. Send us the +one-line entry to add to the USER-MISC/README file in that dir, along +with the 2 source files. You can do this multiple times if you wish +to contribute several individual features. + +
      • If your contribution is several related featues, it is probably best +to make it a user package directory with a name like USER-FOO. In addition to your new files, the directory should contain a README, and -Install.csh file. Send us a tarball of this USER-FOO directory. -

        -

        The README text file should contain your name and contact information -and a brief description of what your new package does. -

        -

        The Install.csh file enables LAMMPS to include and exclude your -package. -

        -

        Your new source files need to have the LAMMPS copyright, GPL notice, -and your name at the top. They need to create a class that is inside -the LAMMPS namespace. Other than that, your files can do whatever is -necessary to implement the new features. They don't have to be -written in the same style and syntax as other LAMMPS files, thought -that would be nice. -

        -

        Finally, in addition to the USER-FOO tarball, you also need to send us -a documentation file for each new command or style you are adding to -LAMMPS. These are text files which we will convert to HTML. Use one -of the *.txt files in the doc dir as a starting point for the new file -you create, since it should look similar to the doc files for existing -commands and styles. The "Restrictions" section of the doc page -should indicate that your feature is only available if LAMMPS is built -with the "user-foo" package. See other user package files for an -example of how to do this. -

        +Install.csh file. The README text file should contain your name and +contact information and a brief description of what your new package +does. The Install.csh file enables LAMMPS to include and exclude your +package. See other README and Install.sh files in other USER +directories as examples. Send us a tarball of this USER-FOO +directory. + +
      • Your new source files need to have the LAMMPS copyright, GPL notice, +and your name at the top, like other LAMMPS source files. They need +to create a class that is inside the LAMMPS namespace. Other than +that, your files can do whatever is necessary to implement the new +features. They don't have to be written in the same stylistic format +and syntax as other LAMMPS files, though that would be nice. + +
      • Finally, you must also send a documentation file for each new command +or style you are adding to LAMMPS. This will be one file for a +single-file feature. For a package, it might be several files. These +are simple text files which we will convert to HTML. They must be in +the same format as other *.txt files in the lammps/doc directory for +similar commands and styles. The "Restrictions" section of the doc +page should indicate that your command is only available if LAMMPS is +built with the appropriate USER-MISC or USER-FOO package. See other +user package doc files for an example of how to do this. The txt2html +tool we use to do the conversion can be downloaded from this +site, so you can perform +the HTML conversion yourself to proofread your doc page. +

      Note that the more clear and self-explanatory you make your doc and README files, the more likely it is that users will try out your new feature. diff --git a/doc/Section_modify.txt b/doc/Section_modify.txt index 5309b38c81..a38bd219a7 100644 --- a/doc/Section_modify.txt +++ b/doc/Section_modify.txt @@ -8,7 +8,27 @@ Section"_Section_python.html :c :line -8. Modifying & extending LAMMPS :h3 +10. Modifying & extending LAMMPS :h3 + +This section describes how to customize LAMMPS by modifying +and extending its source code. + +10.1 "Atom styles"_#mod_1 +10.2 "Bond, angle, dihedral, improper potentials"_#mod_2 +10.3 "Compute styles"_#mod_3 +10.4 "Dump styles"_#mod_4 +10.5 "Dump custom output options"_#mod_5 +10.6 "Fix styles"_#mod_6 which include integrators, \ + temperature and pressure control, force constraints, \ + boundary conditions, diagnostic output, etc +10.7 "Input script commands"_mod_7 +10.8 "Kspace computations"_#mod_8 +10.9 "Minimization styles"_#mod_9 +10.10 "Pairwise potentials"_#mod_10 +10.11 "Region styles"_#mod_11 +10.12 "Thermodynamic output options"_#mod_12 +10.13 "Variable options"_#mod_13 +10.14 "Submitting new features for inclusion in LAMMPS"_#mod_14 :all(b) LAMMPS is designed in a modular fashion so as to be easy to modify and extend with new functionality. In fact, about 75% of its source code @@ -19,7 +39,7 @@ with minimal instructions. If you add a new feature to LAMMPS and think it will be of interest to general users, we encourage you to submit it to the developers for inclusion in the released version of LAMMPS. Information about how to do this is provided -"below"_#package. +"below"_#mod_14. The best way to add a new feature is to find a similar feature in LAMMPS and look at the corresponding source and header files to figure @@ -72,30 +92,9 @@ the executable and can be invoked with a pair_style command like the example above. Arguments like 0.1 and 3.5 can be defined and processed by your new class. -Here is a list of the new features that can be added in this way, -along with information about how to submit your features for inclusion -in the LAMMPS distribution. - -"Atom styles"_#atom -"Bond, angle, dihedral, improper potentials"_#bond -"Compute styles"_#compute -"Dump styles"_#dump -"Dump custom output options"_#dump -"Fix styles"_#fix which include integrators, \ - temperature and pressure control, force constraints, \ - boundary conditions, diagnostic output, etc -"Input script commands"_#command -"Kspace computations"_#kspace -"Minimization solvers"_#min -"Pairwise potentials"_#pair -"Region styles"_#region -"Thermodynamic output options"_#thermo -"Variable options"_#variable :ul - -"Submitting new features to the developers to include in LAMMPS"_#package :ul - -As illustrated by the pairwise example, these options are referred to -in the LAMMPS documentation as the "style" of a particular command. +As illustrated by this pairwise example, many kinds of options are +referred to in the LAMMPS documentation as the "style" of a particular +command. The instructions below give the header file for the base class that these styles are derived from. Public variables in that file are ones @@ -107,14 +106,8 @@ LAMMPS expects. Virtual functions that are not set to 0 are functions you can optionally define. Additionally, new output options can be added directly to the -thermo.cpp, dump_custom.cpp, and variable.cpp files as explained in -these sections: - -"Dump custom output options"_#dump_custom -"Thermodynamic output options"_#thermo -"Variable options"_#variable :ul - -:line +thermo.cpp, dump_custom.cpp, and variable.cpp files as explained +below. Here are additional guidelines for modifying LAMMPS and adding new functionality: @@ -135,50 +128,56 @@ command. :l If you add something you think is truly useful and doesn't impact LAMMPS performance when it isn't used, send an email to the "developers"_http://lammps.sandia.gov/authors.html. We might be -interested in adding it to the LAMMPS distribution. :l,ule +interested in adding it to the LAMMPS distribution. See further +details on this at the bottom of this page. :l,ule :line :line -Atom styles :link(atom),h4 +10.1 Atom styles :link(mod_1),h4 -Classes that define an atom style are derived from the Atom class. -The atom style determines what quantities are associated with an atom. -A new atom style can be created if one of the existing atom styles -does not define all the arrays you need to store and communicate with -atoms. +Classes that define an atom style are derived from the AtomVec class +and managed by the Atom class. The atom style determines what +quantities are associated with an atom. A new atom style can be +created if one of the existing atom styles does not define all +the arrays you need to store and communicate with atoms. Atom_vec_atomic.cpp is a simple example of an atom style. Here is a brief description of methods you define in your new derived -class. See atom.h for details. +class. See atom_vec.h for details. -grow: re-allocate atom arrays to longer lengths -copy: copy info for one atom to another atom's array locations -pack_comm: store an atom's info in a buffer communicated every timestep -pack_comm_vel: add velocity info to buffer -pack_comm_one: store extra info unique to this atom style -unpack_comm: retrieve an atom's info from the buffer -unpack_comm_vel: also retrieve velocity info -unpack_comm_one: retreive extra info unique to this atom style -pack_reverse: store an atom's info in a buffer communicating partial forces -pack_reverse_one: store extra info unique to this atom style -unpack_reverse: retrieve an atom's info from the buffer -unpack_reverse_one: retreive extra info unique to this atom style -pack_border: store an atom's info in a buffer communicated on neighbor re-builds -pack_border_vel: add velocity info to buffer -pack_border_one: store extra info unique to this atom style -unpack_border: retrieve an atom's info from the buffer -unpack_border_vel: also retrieve velocity info -unpack_border_one: retreive extra info unique to this atom style -pack_exchange: store all an atom's info to migrate to another processor -unpack_exchange: retrieve an atom's info from the buffer -size_restart: number of restart quantities associated with proc's atoms -pack_restart: pack atom quantities into a buffer -unpack_restart: unpack atom quantities from a buffer -create_atom: create an individual atom of this style -data_atom: parse an atom line from the data file -memory_usage: tally memory allocated by atom arrays :tb(s=:) +init: one time setup (optional) +grow: re-allocate atom arrays to longer lengths (required) +grow_reset: make array pointers in Atom and AtomVec classes consistent (required) +copy: copy info for one atom to another atom's array locations (required) +pack_comm: store an atom's info in a buffer communicated every timestep (required) +pack_comm_vel: add velocity info to communication buffer (required) +pack_comm_hybrid: store extra info unique to this atom style (optional) +unpack_comm: retrieve an atom's info from the buffer (required) +unpack_comm_vel: also retrieve velocity info (required) +unpack_comm_hybrid: retreive extra info unique to this atom style (optional) +pack_reverse: store an atom's info in a buffer communicating partial forces (required) +pack_reverse_hybrid: store extra info unique to this atom style (optional) +unpack_reverse: retrieve an atom's info from the buffer (required) +unpack_reverse_hybrid: retreive extra info unique to this atom style (optional) +pack_border: store an atom's info in a buffer communicated on neighbor re-builds (required) +pack_border_vel: add velocity info to buffer (required) +pack_border_hybrid: store extra info unique to this atom style (optional) +unpack_border: retrieve an atom's info from the buffer (required) +unpack_border_vel: also retrieve velocity info (required) +unpack_border_hybrid: retreive extra info unique to this atom style (optional) +pack_exchange: store all an atom's info to migrate to another processor (required) +unpack_exchange: retrieve an atom's info from the buffer (required) +size_restart: number of restart quantities associated with proc's atoms (required) +pack_restart: pack atom quantities into a buffer (required) +unpack_restart: unpack atom quantities from a buffer (required) +create_atom: create an individual atom of this style (required) +data_atom: parse an atom line from the data file (required) +data_atom_hybrid: parse additional atom info unique to this atom style (optional) +data_vel: parse one line of velocity information from data file (optional) +data_vel_hybrid: parse additional velocity data unique to this atom style (optional) +memory_usage: tally memory allocated by atom arrays (required) :tb(s=:) The constructor of the derived class sets values for several variables that you must set when defining a new atom style, which are documented @@ -188,7 +187,7 @@ modify. :line -Bond, angle, dihedral, improper potentials :link(bond),h4 +10.2 Bond, angle, dihedral, improper potentials :link(mod_2),h4 Classes that compute molecular interactions are derived from the Bond, Angle, Dihedral, and Improper classes. New styles can be created to @@ -198,19 +197,24 @@ Bond_harmonic.cpp is the simplest example of a bond style. Ditto for the harmonic forms of the angle, dihedral, and improper style commands. -Here is a brief description of methods you define in your new derived -bond class. See bond.h, angle.h, dihedral.h, and improper.h for -details. +Here is a brief description of common methods you define in your +new derived class. See bond.h, angle.h, dihedral.h, and improper.h +for details and specific additional methods. -compute: compute the molecular interactions -coeff: set coefficients for one bond type -equilibrium_distance: length of bond, used by SHAKE -write & read_restart: writes/reads coeffs to restart files -single: force and energy of a single bond :tb(s=:) +init: check if all coefficients are set, calls {init_style} (optional) +init_style: check if style specific conditions are met (optional) +compute: compute the molecular interactions (required) +settings: apply global settings for all types (optional) +coeff: set coefficients for one type (required) +equilibrium_distance: length of bond, used by SHAKE (required, bond only) +equilibrium_angle: opening of angle, used by SHAKE (required, angle only) +write & read_restart: writes/reads coeffs to restart files (required) +single: force and energy of a single bond or angle (required, bond or angle only) +memory_usage: tally memory allocated by the style (optional) :tb(s=:) :line -Compute styles :link(compute),h4 +10.3 Compute styles :link(mod_3),h4 Classes that compute scalar and vector quantities like temperature and the pressure tensor, as well as classes that compute per-atom @@ -225,19 +229,26 @@ per-atom kinetic energy. Here is a brief description of methods you define in your new derived class. See compute.h for details. -compute_scalar: compute a scalar quantity -compute_vector: compute a vector of quantities -compute_peratom: compute one or more quantities per atom -pack_comm: pack a buffer with items to communicate -unpack_comm: unpack the buffer -pack_reverse: pack a buffer with items to reverse communicate -unpack_reverse: unpack the buffer -memory_usage: tally memory usage :tb(s=:) +init: perform one time setup (required) +init_list: neighbor list setup, if needed (optional) +compute_scalar: compute a scalar quantity (optional) +compute_vector: compute a vector of quantities (optional) +compute_peratom: compute one or more quantities per atom (optional) +compute_local: compute one or more quantities per processor (optional) +pack_comm: pack a buffer with items to communicate (optional) +unpack_comm: unpack the buffer (optional) +pack_reverse: pack a buffer with items to reverse communicate (optional) +unpack_reverse: unpack the buffer (optional) +remove_bias: remove velocity bias from one atom (optional) +remove_bias_all: remove velocity bias from all atoms in group (optional) +restore_bias: restore velocity bias for one atom after remove_bias (optional) +restore_bias_all: same as before, but for all atoms in group (optional) +memory_usage: tally memory usage (optional) :tb(s=:) :line -Dump styles :link(dump),h4 -Dump custom output options :link(dump_custom),h4 +10.4 Dump styles :link(mod_4),h4 +10.5 Dump custom output options :link(mod_5),h4 Classes that dump per-atom info to files are derived from the Dump class. To dump new quantities or in a new format, a new derived dump @@ -266,7 +277,7 @@ half-dozen or so locations where code will need to be added. :line -Fix styles :link(fix),h4 +10.6 Fix styles :link(mod_6),h4 In LAMMPS, a "fix" is any operation that is computed during timestepping that alters some property of the system. Essentially @@ -285,34 +296,59 @@ implement. Here is a brief description of methods you can define in your new derived class. See fix.h for details. -setmask: determines when the fix is called during the timestep -init: initialization before a run -setup: called immediately before the 1st timestep -initial_integrate: called at very beginning of each timestep -pre_exchange: called before atom exchange on re-neighboring steps -pre_neighbor: called before neighbor list build -post_force: called after pair & molecular forces are computed -final_integrate: called at end of each timestep -end_of_step: called at very end of timestep -write_restart: dumps fix info to restart file -restart: uses info from restart file to re-initialize the fix -grow_arrays: allocate memory for atom-based arrays used by fix -copy_arrays: copy atom info when an atom migrates to a new processor -memory_usage: report memory used by fix -pack_exchange: store atom's data in a buffer -unpack_exchange: retrieve atom's data from a buffer -pack_restart: store atom's data for writing to restart file -unpack_restart: retrieve atom's data from a restart file buffer -size_restart: size of atom's data -maxsize_restart: max size of atom's data -initial_integrate_respa: same as initial_integrate, but for rRESPA -post_force_respa: same as post_force, but for rRESPA -final_integrate_respa: same as final_integrate, but for rRESPA -pack_comm: pack a buffer to communicate a per-atom quantity -unpack_comm: unpack a buffer to communicate a per-atom quantity -pack_reverse_comm: pack a buffer to reverse communicate a per-atom quantity -unpack_reverse_comm: unpack a buffer to reverse communicate a per-atom quantity -thermo: compute quantities for thermodynamic output :tb(s=:) +setmask: determines when the fix is called during the timestep (required) +init: initialization before a run (optional) +setup_pre_exchange: called before atom exchange in setup (optional) +setup_pre_force: called before force computation in setup (optional) +setup: called immediately before the 1st timestep and after forces are computed (optional) +min_setup_pre_force: like setup_pre_force, but for minimizations instead of MD runs (optional) +min_setup: like setup, but for minimizations instead of MD runs (optional) +initial_integrate: called at very beginning of each timestep (optional) +pre_exchange: called before atom exchange on re-neighboring steps (optional) +pre_neighbor: called before neighbor list build (optional) +pre_force: called after pair & molecular forces are computed (optional) +post_force: called after pair & molecular forces are computed and communicated (optional) +final_integrate: called at end of each timestep (optional) +end_of_step: called at very end of timestep (optional) +write_restart: dumps fix info to restart file (optional) +restart: uses info from restart file to re-initialize the fix (optional) +grow_arrays: allocate memory for atom-based arrays used by fix (optional) +copy_arrays: copy atom info when an atom migrates to a new processor (optional) +pack_exchange: store atom's data in a buffer (optional) +unpack_exchange: retrieve atom's data from a buffer (optional) +pack_restart: store atom's data for writing to restart file (optional) +unpack_restart: retrieve atom's data from a restart file buffer (optional) +size_restart: size of atom's data (optional) +maxsize_restart: max size of atom's data (optional) +setup_pre_force_respa: same as setup_pre_force, but for rRESPA (optional) +initial_integrate_respa: same as initial_integrate, but for rRESPA (optional) +post_integrate_respa: called after the first half integration step is done in rRESPA (optional) +pre_force_respa: same as pre_force, but for rRESPA (optional) +post_force_respa: same as post_force, but for rRESPA (optional) +final_integrate_respa: same as final_integrate, but for rRESPA (optional) +min_pre_force: called after pair & molecular forces are computed in minimizer (optional) +min_post_force: called after pair & molecular forces are computed and communicated in minmizer (optional) +min_store: store extra data for linesearch based minimization on a LIFO stack (optional) +min_pushstore: push the minimization LIFO stack one element down (optional) +min_popstore: pop the minimization LIFO stack one element up (optional) +min_clearstore: clear minimization LIFO stack (optional) +min_step: reset or move forward on line search minimization (optional) +min_dof: report number of degrees of freedom {added} by this fix in minimization (optional) +max_alpha: report maximum allowed step size during linesearch minimization (optional) +pack_comm: pack a buffer to communicate a per-atom quantity (optional) +unpack_comm: unpack a buffer to communicate a per-atom quantity (optional) +pack_reverse_comm: pack a buffer to reverse communicate a per-atom quantity (optional) +unpack_reverse_comm: unpack a buffer to reverse communicate a per-atom quantity (optional) +dof: report number of degrees of freedom {removed} by this fix during MD (optional) +compute_scalar: return a global scalar property that the fix computes (optional) +compute_vector: return a component of a vector property that the fix computes (optional) +compute_array: return a component of an array property that the fix computes (optional) +deform: called when the box size is changed (optional) +reset_target: called when a change of the target temperature is requested during a run (optional) +reset_dt: is called when a change of the time step is requested during a run (optional) +modify_param: called when a fix_modify request is executed (optional) +memory_usage: report memory used by fix (optional) +thermo: compute quantities for thermodynamic output (optional) :tb(s=:) Typically, only a small fraction of these methods are defined for a particular fix. Setmask is mandatory, as it determines when the fix @@ -342,7 +378,7 @@ quantities and/or to be summed to the potential energy of the system. :line -Input script commands :link(command),h4 +10.7 Input script commands :link(mod_7),h4 New commands can be added to LAMMPS input scripts by adding new classes that have a "command" method. For example, the create_atoms, @@ -362,7 +398,7 @@ needed. :line -Kspace computations :link(kspace),h4 +10.8 Kspace computations :link(mod_8),h4 Classes that compute long-range Coulombic interactions via K-space representations (Ewald, PPPM) are derived from the KSpace class. New @@ -380,7 +416,7 @@ memory_usage: tally of memory usage :tb(s=:) :line -Minimization solvers :link(min),h4 +10.9 Minimization styles :link(mod_9),h4 Classes that perform energy minimization derived from the Min class. New styles can be created to add new minimization algorithms to @@ -397,7 +433,7 @@ memory_usage: tally of memory usage :tb(s=:) :line -Pairwise potentials :link(pair),h4 +10.10 Pairwise potentials :link(mod_10),h4 Classes that compute pairwise interactions are derived from the Pair class. In LAMMPS, pairwise calculation include manybody potentials @@ -424,7 +460,7 @@ The inner/middle/outer routines are optional. :line -Region styles :link(region),h4 +10.11 Region styles :link(mod_11),h4 Classes that define geometric regions are derived from the Region class. Regions are used elsewhere in LAMMPS to group atoms, delete @@ -440,17 +476,16 @@ match: determine whether a point is in the region :tb(s=:) :line -Thermodynamic output options :link(thermo),h4 +10.12 Thermodynamic output options :link(mod_12),h4 There is one class that computes and prints thermodynamic information to the screen and log file; see the file thermo.cpp. -There are several styles defined in thermo.cpp: "one", "multi", -"granular", etc. There is also a flexible "custom" style which allows -the user to explicitly list keywords for quantities to print when -thermodynamic info is output. See the -"thermo_style"_thermo_style.html command for a list of defined -quantities. +There are two styles defined in thermo.cpp: "one" and "multi". There +is also a flexible "custom" style which allows the user to explicitly +list keywords for quantities to print when thermodynamic info is +output. See the "thermo_style"_thermo_style.html command for a list +of defined quantities. The thermo styles (one, multi, etc) are simply lists of keywords. Adding a new style thus only requires defining a new list of keywords. @@ -470,7 +505,7 @@ by adding a new keyword to the thermo command. :line -Variable options :link(variable),h4 +10.13 Variable options :link(mod_13),h4 There is one class that computes and stores "variable"_variable.html information in LAMMPS; see the file variable.cpp. The value @@ -508,27 +543,30 @@ Adding new "compute styles"_compute.html (whose calculated values can then be accessed by variables) was discussed "here"_Section_modify.html#compute on this page. +:line :line -Submitting new features to the developers to include in LAMMPS :link(package),h4 +10.14 Submitting new features for inclusion in LAMMPS :link(mod_14),h4 We encourage users to submit new features that they add to LAMMPS to "the developers"_http://lammps.sandia.gov/authors.html, especially if -you think they will be useful to other users. If they are broadly -useful we may add them as core files to LAMMPS or as part of a -"standard package"_Section_start.html#2_3. Else we will add them as a -user-contributed package. Examples of user packages are in src -sub-directories that start with USER. You can see a list of the both -standard and user packages by typing "make package" in the LAMMPS src -directory. +you think the features will be of interest to other users. If they +are broadly useful we may add them as core files to LAMMPS or as part +of a "standard package"_Section_start.html#start_3. Else we will add +them as a user-contributed package or file. Examples of user packages +are in src sub-directories that start with USER. The USER-MISC +package is simply a collection of (mostly) unrelated single files, +which is the simplest way to have your contribution quickly added to +the LAMMPS distribution. You can see a list of the both standard and +user packages by typing "make package" in the LAMMPS src directory. -With user packages, all we are really providing (aside from the fame -and fortune that accompanies having your name in the source code and -on the "Authors page"_http://lammps.sandia.gov/authors.html of the -"LAMMPS WWW site"_lws), is a means for you to distribute your work to -the LAMMPS user community and a mechanism for others to easily try out -your new feature. This may help you find bugs or make contact with -new collaborators. Note that you're also implicitly agreeing to +With user packages and files, all we are really providing (aside from +the fame and fortune that accompanies having your name in the source +code and on the "Authors page"_http://lammps.sandia.gov/authors.html +of the "LAMMPS WWW site"_lws), is a means for you to distribute your +work to the LAMMPS user community and a mechanism for others to easily +try out your new feature. This may help you find bugs or make contact +with new collaborators. Note that you're also implicitly agreeing to support your code which means answer questions, fix bugs, and maintain it if LAMMPS changes. @@ -537,41 +575,55 @@ features of various kinds to LAMMPS. Packages are simply collections of one or more new class files which are invoked as a new "style" within a LAMMPS input script. If designed correctly, these additions do not require changes to the main core of LAMMPS; they are simply -add-on files. If you think your new feature does requires changes in -other LAMMPS files, you'll need to "communicate with the +add-on files. If you think your new feature requires non-trivial +changes in core LAMMPS files, you'll need to "communicate with the developers"_http://lammps.sandia.gov/authors.html, since we may or may -not want to make those changes. +not want to make those changes. An example of a trivial change is +making a parent-class method "virtual" when you derive a new child +class from it. -Here is what you need to do to submit a user package for our -consideration. Following these steps will save time for both you and -us. See existing package files for examples. +Here is what you need to do to submit a user package or single file +for our consideration. Following these steps will save time for both +you and us. See existing package files for examples. -Your user package will be a directory with a name like USER-FOO. In +All source files you provide must compile with the most current +version of LAMMPS. :ulb,l + +If your contribution is a single file (actually a *.cpp and *.h file) +it can most rapidly be added to the USER-MISC directory. Send us the +one-line entry to add to the USER-MISC/README file in that dir, along +with the 2 source files. You can do this multiple times if you wish +to contribute several individual features. :l + +If your contribution is several related featues, it is probably best +to make it a user package directory with a name like USER-FOO. In addition to your new files, the directory should contain a README, and -Install.csh file. Send us a tarball of this USER-FOO directory. - -The README text file should contain your name and contact information -and a brief description of what your new package does. - -The Install.csh file enables LAMMPS to include and exclude your -package. +Install.csh file. The README text file should contain your name and +contact information and a brief description of what your new package +does. The Install.csh file enables LAMMPS to include and exclude your +package. See other README and Install.sh files in other USER +directories as examples. Send us a tarball of this USER-FOO +directory. :l Your new source files need to have the LAMMPS copyright, GPL notice, -and your name at the top. They need to create a class that is inside -the LAMMPS namespace. Other than that, your files can do whatever is -necessary to implement the new features. They don't have to be -written in the same style and syntax as other LAMMPS files, thought -that would be nice. +and your name at the top, like other LAMMPS source files. They need +to create a class that is inside the LAMMPS namespace. Other than +that, your files can do whatever is necessary to implement the new +features. They don't have to be written in the same stylistic format +and syntax as other LAMMPS files, though that would be nice. :l -Finally, in addition to the USER-FOO tarball, you also need to send us -a documentation file for each new command or style you are adding to -LAMMPS. These are text files which we will convert to HTML. Use one -of the *.txt files in the doc dir as a starting point for the new file -you create, since it should look similar to the doc files for existing -commands and styles. The "Restrictions" section of the doc page -should indicate that your feature is only available if LAMMPS is built -with the "user-foo" package. See other user package files for an -example of how to do this. +Finally, you must also send a documentation file for each new command +or style you are adding to LAMMPS. This will be one file for a +single-file feature. For a package, it might be several files. These +are simple text files which we will convert to HTML. They must be in +the same format as other *.txt files in the lammps/doc directory for +similar commands and styles. The "Restrictions" section of the doc +page should indicate that your command is only available if LAMMPS is +built with the appropriate USER-MISC or USER-FOO package. See other +user package doc files for an example of how to do this. The txt2html +tool we use to do the conversion can be downloaded from "this +site"_http://www.sandia.gov/~sjplimp/download.html, so you can perform +the HTML conversion yourself to proofread your doc page. :l,ule Note that the more clear and self-explanatory you make your doc and README files, the more likely it is that users will try out your new diff --git a/doc/Section_packages.html b/doc/Section_packages.html new file mode 100644 index 0000000000..600f034d3b --- /dev/null +++ b/doc/Section_packages.html @@ -0,0 +1,422 @@ + +

      Previous Section - LAMMPS WWW Site - +LAMMPS Documentation - LAMMPS Commands - Next +Section +
      + + + + + + +
      + +

      4. Packages +

      +

      This section gives a quick overview of the add-on packages that extend +LAMMPS functionality. +

      +4.1 Standard packages
      +4.2 User packages
      + +

      LAMMPS includes many optional packages, which are groups of files that +enable a specific set of features. For example, force fields for +molecular systems or granular systems are in packages. You can see +the list of all packages by typing "make package" from within the src +directory of the LAMMPS distribution. +

      +

      See this section of the manual for +details on how to include/exclude specific packages as part of the +LAMMPS build process, and for more details about the differences +between standard packages and user packages in LAMMPS. +

      +

      Below, the packages currently availabe in LAMMPS are listed. For +standard packages, just a one-line description is given. For user +packages, more details are provided. +

      +
      + +
      + +

      4.1 Standard packages +

      +

      The current list of standard packages is as follows: +

      +
      + + + + + + + + + + + + + + + + + + + + + +
      Package Description Author(s) Doc page Example Library
      ASPHERE aspherical particles - howto ellipse -
      CLASS2 class 2 force fields - pair_style lj/class2 - -
      COLLOID colloidal particles - atom_style colloid colloid -
      DIPOLE point dipole particles - pair_style dipole/cut dipole -
      FLD Fast Lubrication Dynamics Kumar & Bybee & Higdon (1) pair_style lubricateU - -
      GPU GPU-enabled potentials Mike Brown (ORNL) accelerate gpu lib/gpu
      GRANULAR granular systems - howto pour -
      KSPACE long-range Coulombic solvers - kspace_style peptide -
      MANYBODY many-body potentials - pair_style tersoff shear -
      MEAM modified EAM potential Greg Wagner (Sandia) pair_style meam meam lib/meam
      MC Monte Carlo options - fix gcmc - -
      MOLECULE molecular system force fields - howto peptide -
      OPT optimized pair potentials Fischer & Richie & Natoli (2) howto - -
      PERI Peridynamics models Mike Parks (Sandia) pair_style peri peri -
      POEMS coupled rigid body motion Rudra Mukherjee (JPL) fix poems rigid lib/poems
      REAX ReaxFF potential Aidan Thompson (Sandia) pair_style reax reax lib/reax
      REPLICA multi-replica methods - howto tad -
      SHOCK shock loading methods - fix msst - -
      SRD stochastic rotation dynamics - fix srd srd -
      XTC dumps in XTC format - dump - -
      +
      + +

      The "Authors" column lists a name(s) if a specific person is +responible for creating and maintaining the package. +

      +

      (1) The FLD package was created by Amit Kumar and Michael Bybee from +Jonathan Higdon's group at UIUC. +

      +

      (2) The OPT package was created by James Fischer (High Performance +Technologies), David Richie, and Vincent Natoli (Stone Ridge +Technolgy). +

      +

      The "Doc page" column links to either a portion of the +Section_howto of the manual, or an input script +command implemented as part of the package. +

      +

      The "Example" column is a sub-directory in the examples directory of +the distribution which has an input script that uses the package. +E.g. "peptide" refers to the examples/peptide directory. +

      +

      The "Library" column lists an external library which must be built first and which LAMMPS links to when it is built. These are in the lib directory of the distribution. This section of the manual gives details on the 2-step build process with external libraries. +

      +
      + +
      + +

      4.2 User packages +

      +

      The current list of user-contributed packages is as follows: +

      +
      + + + + + + + + + + + +
      Package Description Author(s) Doc page Example Pic/movie Library
      USER-MISC single-file contributions USER-MISC/README - - - -
      USER-ATC atom-to-continuum coupling Jones & Templeton & Zimmerman (2) fix atc USER/atc atc lib/atc
      USER-AWPMD wave-packet MD Ilya Valuev (JIHT) pair_style awpmd/cut USER/awpmd - lib/awpmd
      USER-CG-CMM coarse-graining model Axel Kohlmeyer (Temple U) pair_style lj/sdk USER/cg-cmm cg -
      USER-CUDA NVIDIA GPU styles Christian Trott (U Tech Ilmenau) accelerate USER/cuda - lib/cuda
      USER-EFF electron force field Andres Jaramillo-Botero (Caltech) pair_style eff/cut USER/eff eff -
      USER-EWALDN Ewald for 1/R^n Pieter in' t Veld (BASF) kspace_style - - -
      USER-OMP OpenMP threaded styles Axel Kohlmeyer (Temple U) accelerate - - -
      USER-REAXC C version of ReaxFF Metin Aktulga (LBNL) pair_style reaxc reax - -
      USER-SPH smoothed particle hydrodynamics Georg Ganzenmuller (EMI) SPH_LAMMPS_userguide.pdf USER/sph sph -
      +
      + + + + + + + + + +

      The "Authors" column lists a name(s) if a specific person is +responible for creating and maintaining the package. +

      +

      (2) The ATC package was created by Reese Jones, Jeremy Templeton, and Jon Zimmerman (Sandia). +

      +

      The "Doc page" column links to either a portion of the +Section_howto of the manual, or an input script +command implemented as part of the package, or to additional +documentation provided witht he package. +

      +

      The "Example" column is a sub-directory in the examples directory of +the distribution which has an input script that uses the package. +E.g. "peptide" refers to the examples/peptide directory. USER/cuda +refers to the examples/USER/cuda directory. +

      +

      The "Library" column lists an external library which must be built +first and which LAMMPS links to when it is built. These are in the +lib directory of the distribution. This +section of the manual gives details on +the 2-step build process with external libraries. +

      +

      More details on each package, from the USER-blah/README file +is given below. +

      +
      + +

      USER-MISC package +

      +

      The files in this package are a potpourri of (mostly) unrelated +features contributed to LAMMPS by users. Each feature is a single +pair of files (*.cpp and *.h). +

      +

      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_commands +

      +

      User-contributed features are listed at the bottom of the fix, +compute, pair, etc sections. +

      +

      The list of features and author of each is given in the +src/USER-MISC/README file. +

      +

      You should contact the author directly if you have specific questions +about the feature or its coding. +

      +
      + +

      USER-ATC package +

      +

      This package implements a "fix atc" command which can be used in a +LAMMPS input script. This fix can be employed to either do concurrent +coupling of MD with FE-based physics surrogates or on-the-fly +post-processing of atomic information to continuum fields. +

      +

      See the doc page for the fix atc command to get started. At the +bottom of the doc page are many links to additional documentation +contained in the doc/USER/atc directory. +

      +

      There are example scripts for using this package in examples/USER/atc. +

      +

      This package uses an external library in lib/atc which must be +compiled before making LAMMPS. See the lib/atc/README file and the +LAMMPS manual for information on building LAMMPS with external +libraries. +

      +

      The primary people who created this package are Reese Jones (rjones at +sandia.gov), Jeremy Templeton (jatempl at sandia.gov) and Jon +Zimmerman (jzimmer at sandia.gov) at Sandia. Contact them directly if +you have questions. +

      +
      + +

      USER-AWPMD package +

      +

      This package contains a LAMMPS implementation of the Antisymmetrized +Wave Packet Molecular Dynamics (AWPMD) method. +

      +

      See the doc page for the pair_style awpmd/cut command to get started. +

      +

      There are example scripts for using this package in examples/USER/awpmd. +

      +

      This package uses an external library in lib/awpmd which must be +compiled before making LAMMPS. See the lib/awpmd/README file and the +LAMMPS manual for information on building LAMMPS with external +libraries. +

      +

      The person who created this package is Ilya Valuev at the JIHT in +Russia (valuev at physik.hu-berlin.de). Contact him directly if you +have questions. +

      +
      + +

      USER-CG-CMM package +

      +

      This package implements 3 commands which can be used in a LAMMPS input +script: +

      +
      • pair_style lj/sdk +
      • pair_style lj/sdk/coul/long +
      • angle_style sdk +
      +

      These styles allow coarse grained MD simulations with the +parametrization of Shinoda, DeVane, Klein, Mol Sim, 33, 27 (2007) +(SDK), with extensions to simulate ionic liquids, electrolytes, lipids +and charged amino acids. +

      +

      See the doc pages for these commands for details. +

      +

      There are example scripts for using this package in +examples/USER/cg-cmm. +

      +

      This is the second generation implementation reducing the the clutter +of the previous version. For many systems with electrostatics, it will +be faster to use pair_style hybrid/overlay with lj/sdk and coul/long +instead of the combined lj/sdk/coul/long style. since the number of +charged atom types is usually small. For any other coulomb +interactions this is now required. To exploit this property, the use +of the kspace_style pppm/cg is recommended over regular pppm. For all +new styles, input file backward compatibility is provided. The old +implementation is still available through appending the /old +suffix. These will be discontinued and removed after the new +implementation has been fully validated. +

      +

      The current version of this package should be considered beta +quality. The CG potentials work correctly for "normal" situations, but +have not been testing with all kinds of potential parameters and +simulation systems. +

      +

      The person who created this package is Axel Kohlmeyer at Temple U +(akohlmey at gmail.com). Contact him directly if you have questions. +

      +
      + +

      USER-CUDA package +

      +

      This package provides acceleration of various LAMMPS pair styles, fix +styles, compute styles, and long-range Coulombics via PPPM for NVIDIA +GPUs. +

      +

      See this section of the manual to get started: +

      +

      Section_accelerate +

      +

      There are example scripts for using this package in +examples/USER/cuda. +

      +

      This package uses an external library in lib/cuda which must be +compiled before making LAMMPS. See the lib/cuda/README file and the +LAMMPS manual for information on building LAMMPS with external +libraries. +

      +

      The person who created this package is Christian Trott at the +University of Technology Ilmenau, Germany (christian.trott at +tu-ilmenau.de). Contact him directly if you have questions. +

      +
      + +

      USER-EFF package +

      +

      This package contains a LAMMPS implementation of the electron Force +Field (eFF) currently under development at Caltech, as described in +A. Jaramillo-Botero, J. Su, Q. An, and W.A. Goddard III, JCC, +2010. The eFF potential was first introduced by Su and Goddard, in +2007. +

      +

      eFF can be viewed as an approximation to QM wave packet dynamics and +Fermionic molecular dynamics, combining the ability of electronic +structure methods to describe atomic structure, bonding, and chemistry +in materials, and of plasma methods to describe nonequilibrium +dynamics of large systems with a large number of highly excited +electrons. We classify it as a mixed QM-classical approach rather than +a conventional force field method, which introduces QM-based terms (a +spin-dependent repulsion term to account for the Pauli exclusion +principle and the electron wavefunction kinetic energy associated with +the Heisenberg principle) that reduce, along with classical +electrostatic terms between nuclei and electrons, to the sum of a set +of effective pairwise potentials. This makes eFF uniquely suited to +simulate materials over a wide range of temperatures and pressures +where electronically excited and ionized states of matter can occur +and coexist. +

      +

      The necessary customizations to the LAMMPS core are in place to +enable the correct handling of explicit electron properties during +minimization and dynamics. +

      +

      See the doc page for the pair_style eff/cut command to get started. +

      +

      There are example scripts for using this package in +examples/USER/eff. +

      +

      There are auxiliary tools for using this package in tools/eff. +

      +

      The person who created this package is Andres Jaramillo-Botero at +CalTech (ajaramil at wag.caltech.edu). Contact him directly if you +have questions. +

      +
      + +

      USER-EWALDN package +

      +

      This package implements 3 commands which can be used in a LAMMPS input +script: pair_style lj/coul, pair_style buck/coul, and kspace_style +ewald/n. +

      +

      The "kspace_style ewald/n" command is similar to standard Ewald for +charges, but also enables the Lennard-Jones interaction, or any 1/r^N +interaction to be of infinite extent, instead of being cutoff. LAMMPS +pair potentials for long-range Coulombic interactions, such as +lj/cut/coul/long can be used with ewald/n. The two new pair_style +commands provide the modifications for the short-range LJ and +Buckingham interactions that can also be used with ewald/n. +

      +

      Another advantage of kspace_style ewald/n is that it can be used with +non-orthogonal (triclinic symmetry) simulation boxes, either for just +long-range Coulombic interactions, or for both Coulombic and 1/r^N LJ +or Buckingham, which is not currently possible for other kspace styles +such as PPPM and ewald. +

      +

      See the doc pages for these commands for details. +

      +

      The person who created these files is Pieter in' t Veld while at +Sandia. He is now at BASF (pieter.intveld at basf.com). Contact him +directly if you have questions. +

      +
      + +

      USER-OMP package +

      +

      This package provides OpenMP multi-threading support and +other optimizations of various LAMMPS pair styles, dihedral +styles, and fix styles. +

      +

      See this section of the manual to get started: +

      +

      Section_accelerate +

      +

      The person who created this package is Axel Kohlmeyer at Temple U +(akohlmey at gmail.com). Contact him directly if you have questions. +

      +
      + +

      USER-REAXC package +

      +

      This package contains a implementation for LAMMPS of the ReaxFF force +field. ReaxFF uses distance-dependent bond-order functions to +represent the contributions of chemical bonding to the potential +energy. It was originally developed by Adri van Duin and the Goddard +group at CalTech. +

      +

      The USER-REAXC version of ReaxFF (pair_style reax/c), implemented in +C, should give identical or very similar results to pair_style reax, +which is a ReaxFF implementation on top of a Fortran library, a +version of which library was originally authored by Adri van Duin. +

      +

      The reax/c version should be somewhat faster and more scalable, +particularly with respect to the charge equilibration calculation. It +should also be easier to build and use since there are no complicating +issues with Fortran memory allocation or linking to a Fortran library. +

      +

      For technical details about this implemention of ReaxFF, see +this paper: +

      +

      Parallel and Scalable Reactive Molecular Dynamics: Numerical Methods +and Algorithmic Techniques, H. M. Aktulga, J. C. Fogarty, +S. A. Pandit, A. Y. Grama, Parallel Computing, in press (2011). +

      +

      See the doc page for the pair_style reax/c command for details +of how to use it in LAMMPS. +

      +

      The person who created this package is Hasan Metin Aktulga (hmaktulga +at lbl.gov), while at Purdue University. Contact him directly, or +Aidan Thompson at Sandia (athomps at sandia.gov), if you have +questions. +

      +
      + +

      USER-SPH package +

      +

      This package implements smoothed particle hydrodynamics (SPH) in +LAMMPS. Currently, the package has the following features: +

      +

      * Tait, ideal gas, Lennard-Jones equation of states, full support for + complete (i.e. internal-energy dependent) equations of state +* plain or Monaghans XSPH integration of the equations of motion +* density continuity or density summation to propagate the density field +* commands to set internal energy and density of particles from the + input script +* output commands to access internal energy and density for dumping and + thermo output +

      +

      See the file doc/USER/sph/SPH_LAMMPS_userguide.pdf to get started. +

      +

      There are example scripts for using this package in examples/USER/sph. +

      +

      The person who created this package is Georg Ganzenmuller at the +Fraunhofer-Institute for High-Speed Dynamics, Ernst Mach Institute in +Germany (georg.ganzenmueller at emi.fhg.de). Contact him directly if +you have questions. +

      + diff --git a/doc/Section_packages.txt b/doc/Section_packages.txt new file mode 100644 index 0000000000..20b016cbcb --- /dev/null +++ b/doc/Section_packages.txt @@ -0,0 +1,408 @@ +"Previous Section"_Section_commands.html - "LAMMPS WWW Site"_lws - +"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next +Section"_Section_accelerate.html :c + +:link(lws,http://lammps.sandia.gov) +:link(ld,Manual.html) +:link(lc,Section_commands.html#comm) + +:line + +4. Packages :h3 + +This section gives a quick overview of the add-on packages that extend +LAMMPS functionality. + +4.1 "Standard packages"_#pkg_1 +4.2 "User packages"_#pkg_2 :all(b) + +LAMMPS includes many optional packages, which are groups of files that +enable a specific set of features. For example, force fields for +molecular systems or granular systems are in packages. You can see +the list of all packages by typing "make package" from within the src +directory of the LAMMPS distribution. + +See "this section"_Section_start.html#start_3 of the manual for +details on how to include/exclude specific packages as part of the +LAMMPS build process, and for more details about the differences +between standard packages and user packages in LAMMPS. + +Below, the packages currently availabe in LAMMPS are listed. For +standard packages, just a one-line description is given. For user +packages, more details are provided. + +:line +:line + +4.1 Standard packages :h4,link(pkg_1) + +The current list of standard packages is as follows: + +Package, Description, Author(s), Doc page, Example, Library +ASPHERE, aspherical particles, -, "howto"_Section_howto.html#howto_14, ellipse, - +CLASS2, class 2 force fields, -, "pair_style lj/class2"_pair_class2.html, -, - +COLLOID, colloidal particles, -, "atom_style colloid"_atom_style.html, colloid, - +DIPOLE, point dipole particles, -, "pair_style dipole/cut"_pair_dipole.html, dipole, - +FLD, Fast Lubrication Dynamics, Kumar & Bybee & Higdon (1), "pair_style lubricateU"_pair_lubricateU.html, -, - +GPU, GPU-enabled potentials, Mike Brown (ORNL), "accelerate"_Section_accelerate.html#acc_3, gpu, lib/gpu +GRANULAR, granular systems, -, "howto"_Section_howto.html#howto_6, pour, - +KSPACE, long-range Coulombic solvers, -, "kspace_style"_kspace_style.html, peptide, - +MANYBODY, many-body potentials, -, "pair_style tersoff"_pair_tersoff.html, shear, - +MEAM, modified EAM potential, Greg Wagner (Sandia), "pair_style meam"_pair_meam.html, meam, lib/meam +MC, Monte Carlo options, -, "fix gcmc"_fix_gcmc.html, -, - +MOLECULE, molecular system force fields, -, "howto"_Section_howto.html#howto_3, peptide, - +OPT, optimized pair potentials, Fischer & Richie & Natoli (2), "howto"_Section_accelerate.html#acc_1, -, - +PERI, Peridynamics models, Mike Parks (Sandia), "pair_style peri"_pair_peri.html, peri, - +POEMS, coupled rigid body motion, Rudra Mukherjee (JPL), "fix poems"_fix_poems.html, rigid, lib/poems +REAX, ReaxFF potential, Aidan Thompson (Sandia), "pair_style reax"_pair_reax.html, reax, lib/reax +REPLICA, multi-replica methods, -, "howto"_Section_howto.html#howto_5, tad, - +SHOCK, shock loading methods, -, "fix msst"_fix_msst.html, -, - +SRD, stochastic rotation dynamics, -, "fix srd"_fix_srd.html, srd, - +XTC, dumps in XTC format, -, "dump"_dump.html, -, - +:tb(ea=c) + +The "Authors" column lists a name(s) if a specific person is +responible for creating and maintaining the package. + +(1) The FLD package was created by Amit Kumar and Michael Bybee from +Jonathan Higdon's group at UIUC. + +(2) The OPT package was created by James Fischer (High Performance +Technologies), David Richie, and Vincent Natoli (Stone Ridge +Technolgy). + +The "Doc page" column links to either a portion of the +"Section_howto"_Section_howto.html of the manual, or an input script +command implemented as part of the package. + +The "Example" column is a sub-directory in the examples directory of +the distribution which has an input script that uses the package. +E.g. "peptide" refers to the examples/peptide directory. + +The "Library" column lists an external library which must be built first and which LAMMPS links to when it is built. These are in the lib directory of the distribution. "This section"_Section_start.html#start_3_3 of the manual gives details on the 2-step build process with external libraries. + +:line +:line + +4.2 User packages :h4,link(pkg_2) + +The current list of user-contributed packages is as follows: + +Package, Description, Author(s), Doc page, Example, Pic/movie, Library +USER-MISC, single-file contributions, USER-MISC/README, -, -, -, - +USER-ATC, atom-to-continuum coupling, Jones & Templeton & Zimmerman (2), "fix atc"_fix_atc.html, USER/atc, "atc"_atc, lib/atc +USER-AWPMD, wave-packet MD, Ilya Valuev (JIHT), "pair_style awpmd/cut"_pair_awpmd.html, USER/awpmd, -, lib/awpmd +USER-CG-CMM, coarse-graining model, Axel Kohlmeyer (Temple U), "pair_style lj/sdk"_pair_sdk.html, USER/cg-cmm, "cg"_cg, - +USER-CUDA, NVIDIA GPU styles, Christian Trott (U Tech Ilmenau), "accelerate"_Section_accelerate.html#acc_4, USER/cuda, -, lib/cuda +USER-EFF, electron force field, Andres Jaramillo-Botero (Caltech), "pair_style eff/cut"_pair_eff.html, USER/eff, "eff"_eff, - +USER-EWALDN, Ewald for 1/R^n, Pieter in' t Veld (BASF), "kspace_style"_kspace_style.html, -, -, - +USER-OMP, OpenMP threaded styles, Axel Kohlmeyer (Temple U), "accelerate"_Section_accelerate.html#acc_2, -, -, - +USER-REAXC, C version of ReaxFF, Metin Aktulga (LBNL), "pair_style reaxc"_pair_reax_c.html, reax, -, - +USER-SPH, smoothed particle hydrodynamics, Georg Ganzenmuller (EMI), "SPH_LAMMPS_userguide.pdf"_USER/sph/SPH_LAMMPS_userguide.pdf, USER/sph, "sph"_sph, - +:tb(ea=c) + +:link(atc,http://lammps.sandia.gov/pictures.html#atc) +:link(cg,http://lammps.sandia.gov/pictures.html#cg) +:link(eff,http://lammps.sandia.gov/movies.html#eff) +:link(sph,http://lammps.sandia.gov/movies.html#sph) + +The "Authors" column lists a name(s) if a specific person is +responible for creating and maintaining the package. + +(2) The ATC package was created by Reese Jones, Jeremy Templeton, and Jon Zimmerman (Sandia). + +The "Doc page" column links to either a portion of the +"Section_howto"_Section_howto.html of the manual, or an input script +command implemented as part of the package, or to additional +documentation provided witht he package. + +The "Example" column is a sub-directory in the examples directory of +the distribution which has an input script that uses the package. +E.g. "peptide" refers to the examples/peptide directory. USER/cuda +refers to the examples/USER/cuda directory. + +The "Library" column lists an external library which must be built +first and which LAMMPS links to when it is built. These are in the +lib directory of the distribution. "This +section"_Section_start.html#start_3_3 of the manual gives details on +the 2-step build process with external libraries. + +More details on each package, from the USER-blah/README file +is given below. + +:line + +USER-MISC package :h4 + +The files in this package are a potpourri of (mostly) unrelated +features contributed to LAMMPS by users. Each feature is a single +pair of files (*.cpp and *.h). + +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_commands"_Section_commands.html#cmd_5 + +User-contributed features are listed at the bottom of the fix, +compute, pair, etc sections. + +The list of features and author of each is given in the +src/USER-MISC/README file. + +You should contact the author directly if you have specific questions +about the feature or its coding. + +:line + +USER-ATC package :h4 + +This package implements a "fix atc" command which can be used in a +LAMMPS input script. This fix can be employed to either do concurrent +coupling of MD with FE-based physics surrogates or on-the-fly +post-processing of atomic information to continuum fields. + +See the doc page for the fix atc command to get started. At the +bottom of the doc page are many links to additional documentation +contained in the doc/USER/atc directory. + +There are example scripts for using this package in examples/USER/atc. + +This package uses an external library in lib/atc which must be +compiled before making LAMMPS. See the lib/atc/README file and the +LAMMPS manual for information on building LAMMPS with external +libraries. + +The primary people who created this package are Reese Jones (rjones at +sandia.gov), Jeremy Templeton (jatempl at sandia.gov) and Jon +Zimmerman (jzimmer at sandia.gov) at Sandia. Contact them directly if +you have questions. + +:line + +USER-AWPMD package :h4 + +This package contains a LAMMPS implementation of the Antisymmetrized +Wave Packet Molecular Dynamics (AWPMD) method. + +See the doc page for the pair_style awpmd/cut command to get started. + +There are example scripts for using this package in examples/USER/awpmd. + +This package uses an external library in lib/awpmd which must be +compiled before making LAMMPS. See the lib/awpmd/README file and the +LAMMPS manual for information on building LAMMPS with external +libraries. + +The person who created this package is Ilya Valuev at the JIHT in +Russia (valuev at physik.hu-berlin.de). Contact him directly if you +have questions. + +:line + +USER-CG-CMM package :h4 + +This package implements 3 commands which can be used in a LAMMPS input +script: + +pair_style lj/sdk +pair_style lj/sdk/coul/long +angle_style sdk :ul + +These styles allow coarse grained MD simulations with the +parametrization of Shinoda, DeVane, Klein, Mol Sim, 33, 27 (2007) +(SDK), with extensions to simulate ionic liquids, electrolytes, lipids +and charged amino acids. + +See the doc pages for these commands for details. + +There are example scripts for using this package in +examples/USER/cg-cmm. + +This is the second generation implementation reducing the the clutter +of the previous version. For many systems with electrostatics, it will +be faster to use pair_style hybrid/overlay with lj/sdk and coul/long +instead of the combined lj/sdk/coul/long style. since the number of +charged atom types is usually small. For any other coulomb +interactions this is now required. To exploit this property, the use +of the kspace_style pppm/cg is recommended over regular pppm. For all +new styles, input file backward compatibility is provided. The old +implementation is still available through appending the /old +suffix. These will be discontinued and removed after the new +implementation has been fully validated. + +The current version of this package should be considered beta +quality. The CG potentials work correctly for "normal" situations, but +have not been testing with all kinds of potential parameters and +simulation systems. + +The person who created this package is Axel Kohlmeyer at Temple U +(akohlmey at gmail.com). Contact him directly if you have questions. + +:line + +USER-CUDA package :h4 + +This package provides acceleration of various LAMMPS pair styles, fix +styles, compute styles, and long-range Coulombics via PPPM for NVIDIA +GPUs. + +See this section of the manual to get started: + +"Section_accelerate"_Section_accelerate.html#acc_4 + +There are example scripts for using this package in +examples/USER/cuda. + +This package uses an external library in lib/cuda which must be +compiled before making LAMMPS. See the lib/cuda/README file and the +LAMMPS manual for information on building LAMMPS with external +libraries. + +The person who created this package is Christian Trott at the +University of Technology Ilmenau, Germany (christian.trott at +tu-ilmenau.de). Contact him directly if you have questions. + +:line + +USER-EFF package :h4 + +This package contains a LAMMPS implementation of the electron Force +Field (eFF) currently under development at Caltech, as described in +A. Jaramillo-Botero, J. Su, Q. An, and W.A. Goddard III, JCC, +2010. The eFF potential was first introduced by Su and Goddard, in +2007. + +eFF can be viewed as an approximation to QM wave packet dynamics and +Fermionic molecular dynamics, combining the ability of electronic +structure methods to describe atomic structure, bonding, and chemistry +in materials, and of plasma methods to describe nonequilibrium +dynamics of large systems with a large number of highly excited +electrons. We classify it as a mixed QM-classical approach rather than +a conventional force field method, which introduces QM-based terms (a +spin-dependent repulsion term to account for the Pauli exclusion +principle and the electron wavefunction kinetic energy associated with +the Heisenberg principle) that reduce, along with classical +electrostatic terms between nuclei and electrons, to the sum of a set +of effective pairwise potentials. This makes eFF uniquely suited to +simulate materials over a wide range of temperatures and pressures +where electronically excited and ionized states of matter can occur +and coexist. + +The necessary customizations to the LAMMPS core are in place to +enable the correct handling of explicit electron properties during +minimization and dynamics. + +See the doc page for the pair_style eff/cut command to get started. + +There are example scripts for using this package in +examples/USER/eff. + +There are auxiliary tools for using this package in tools/eff. + +The person who created this package is Andres Jaramillo-Botero at +CalTech (ajaramil at wag.caltech.edu). Contact him directly if you +have questions. + +:line + +USER-EWALDN package :h4 + +This package implements 3 commands which can be used in a LAMMPS input +script: pair_style lj/coul, pair_style buck/coul, and kspace_style +ewald/n. + +The "kspace_style ewald/n" command is similar to standard Ewald for +charges, but also enables the Lennard-Jones interaction, or any 1/r^N +interaction to be of infinite extent, instead of being cutoff. LAMMPS +pair potentials for long-range Coulombic interactions, such as +lj/cut/coul/long can be used with ewald/n. The two new pair_style +commands provide the modifications for the short-range LJ and +Buckingham interactions that can also be used with ewald/n. + +Another advantage of kspace_style ewald/n is that it can be used with +non-orthogonal (triclinic symmetry) simulation boxes, either for just +long-range Coulombic interactions, or for both Coulombic and 1/r^N LJ +or Buckingham, which is not currently possible for other kspace styles +such as PPPM and ewald. + +See the doc pages for these commands for details. + +The person who created these files is Pieter in' t Veld while at +Sandia. He is now at BASF (pieter.intveld at basf.com). Contact him +directly if you have questions. + +:line + +USER-OMP package :h4 + +This package provides OpenMP multi-threading support and +other optimizations of various LAMMPS pair styles, dihedral +styles, and fix styles. + +See this section of the manual to get started: + +"Section_accelerate"_Section_accelerate.html#acc_2 + +The person who created this package is Axel Kohlmeyer at Temple U +(akohlmey at gmail.com). Contact him directly if you have questions. + +:line + +USER-REAXC package :h4 + +This package contains a implementation for LAMMPS of the ReaxFF force +field. ReaxFF uses distance-dependent bond-order functions to +represent the contributions of chemical bonding to the potential +energy. It was originally developed by Adri van Duin and the Goddard +group at CalTech. + +The USER-REAXC version of ReaxFF (pair_style reax/c), implemented in +C, should give identical or very similar results to pair_style reax, +which is a ReaxFF implementation on top of a Fortran library, a +version of which library was originally authored by Adri van Duin. + +The reax/c version should be somewhat faster and more scalable, +particularly with respect to the charge equilibration calculation. It +should also be easier to build and use since there are no complicating +issues with Fortran memory allocation or linking to a Fortran library. + +For technical details about this implemention of ReaxFF, see +this paper: + +Parallel and Scalable Reactive Molecular Dynamics: Numerical Methods +and Algorithmic Techniques, H. M. Aktulga, J. C. Fogarty, +S. A. Pandit, A. Y. Grama, Parallel Computing, in press (2011). + +See the doc page for the pair_style reax/c command for details +of how to use it in LAMMPS. + +The person who created this package is Hasan Metin Aktulga (hmaktulga +at lbl.gov), while at Purdue University. Contact him directly, or +Aidan Thompson at Sandia (athomps at sandia.gov), if you have +questions. + +:line + +USER-SPH package :h4 + +This package implements smoothed particle hydrodynamics (SPH) in +LAMMPS. Currently, the package has the following features: + +* Tait, ideal gas, Lennard-Jones equation of states, full support for + complete (i.e. internal-energy dependent) equations of state +* plain or Monaghans XSPH integration of the equations of motion +* density continuity or density summation to propagate the density field +* commands to set internal energy and density of particles from the + input script +* output commands to access internal energy and density for dumping and + thermo output + +See the file doc/USER/sph/SPH_LAMMPS_userguide.pdf to get started. + +There are example scripts for using this package in examples/USER/sph. + +The person who created this package is Georg Ganzenmuller at the +Fraunhofer-Institute for High-Speed Dynamics, Ernst Mach Institute in +Germany (georg.ganzenmueller at emi.fhg.de). Contact him directly if +you have questions. diff --git a/doc/Section_perf.html b/doc/Section_perf.html index bf95445aa0..330d99407a 100644 --- a/doc/Section_perf.html +++ b/doc/Section_perf.html @@ -9,7 +9,7 @@
      -

      6. Performance & scalability +

      8. Performance & scalability

      LAMMPS performance on several prototypical benchmarks and machines is discussed on the Benchmarks page of the LAMMPS WWW Site where diff --git a/doc/Section_perf.txt b/doc/Section_perf.txt index 8a20a8209b..896d522cac 100644 --- a/doc/Section_perf.txt +++ b/doc/Section_perf.txt @@ -6,7 +6,7 @@ :line -6. Performance & scalability :h3 +8. Performance & scalability :h3 LAMMPS performance on several prototypical benchmarks and machines is discussed on the Benchmarks page of the "LAMMPS WWW Site"_lws where diff --git a/doc/Section_python.html b/doc/Section_python.html index 9a561cb74c..a9eb0d34ab 100644 --- a/doc/Section_python.html +++ b/doc/Section_python.html @@ -9,8 +9,19 @@

      -

      9. Python interface to LAMMPS +

      11. Python interface to LAMMPS

      +

      This section describes how to build and use LAMMPS via a Python +interface. +

      +

      The LAMMPS distribution includes some Python code in its python directory which wraps the library interface to LAMMPS. This makes it is possible to run LAMMPS, invoke LAMMPS commands or give it an input @@ -20,16 +31,17 @@ either from a Python script or interactively from a Python prompt.

      Python is a powerful scripting and programming language which can be used to wrap software like LAMMPS and other packages. It can be used to glue multiple pieces of software -together, e.g. to run a coupled or multiscale model. See this +together, e.g. to run a coupled or multiscale model. See this section of the manual and the couple directory of the distribution for more ideas about coupling LAMMPS to -other codes. See this section about how to -build LAMMPS as a library, and this section -for a description of the library interface provided in src/library.cpp -and src/library.h and how to extend it for your needs. As described -below, that interface is what is exposed to Python. It is designed to -be easy to add functions to. This has the effect of extending the -Python inteface as well. See details below. +other codes. See this section about how +to build LAMMPS as a library, and this +section for a description of the library +interface provided in src/library.cpp and src/library.h and how to +extend it for your needs. As described below, that interface is what +is exposed to Python. It is designed to be easy to add functions to. +This has the effect of extending the Python inteface as well. See +details below.

      By using the Python interface LAMMPS can also be coupled with a GUI or visualization tools that display graphs or animations in real time as @@ -88,14 +100,6 @@ setup discussion. The next to last sub-section describes the Python syntax used to invoke LAMMPS. The last sub-section describes example Python scripts included in the python directory.

      -

      Before proceeding, there are 2 items to note.

      (1) The provided Python wrapper for LAMMPS uses the amazing and @@ -116,7 +120,7 @@ code, you are not building shared versions of these libraries.

      The discussion below describes how to create a shared MPI library. I suggest you start by configuing LAMMPS without packages installed that -require any libraries besides MPI. See this +require any libraries besides MPI. See this section of the manual for a discussion of LAMMPS pacakges. E.g. do not use the KSPACE, GPU, MEAM, POEMS, or REAX packages. @@ -134,7 +138,7 @@ LAMMPS wrapper.

      -

      Extending Python with a serial version of LAMMPS +

      11.1 Extending Python with a serial version of LAMMPS

      From the python directory in the LAMMPS distribution, type

      @@ -164,7 +168,7 @@ this, where you should replace "foo" with your directory of choice.

      -

      Creating a shared MPI library +

      11.2 Creating a shared MPI library

      A shared library is one that is dynamically loadable, which is what Python requires. On Linux this is a library file that ends in ".so", @@ -175,7 +179,7 @@ by Argonne National Labs. From within the mpich directory, type

      -
      ./configure --enable-sharedlib=gcc
+
      ./configure --enable-shared
 make
 make install 
 
      
@@ -188,14 +192,14 @@ static and shared MPI library.  This will be fine for running LAMMPS
 from Python since it only uses the shared library.  But if you now try
 to build LAMMPS by itself as a stand-alone program (cd lammps/src;
 make foo) or build other codes that expect to link against libmpich.a,
-then those builds will typically fail if the linker uses libmpich.so
-instead.  This means you will need to remove the file
+then those builds may fail if the linker uses libmpich.so instead.  If
+this happens, it means you will need to remove the file
 /usr/local/lib/libmich.so before building LAMMPS again as a
 stand-alone code.
 
      
 
      
 
-
      Extending Python with a parallel version of LAMMPS 
+
      11.3 Extending Python with a parallel version of LAMMPS 
 
      
 
      From the python directory, type
 
      
@@ -233,7 +237,7 @@ will be put in the appropriate directory.
 
      
 
      
 
-
      Extending Python with MPI 
+
      11.4 Extending Python with MPI 
 
      
 
      There are several Python packages available that purport to wrap MPI
 as a library and allow MPI functions to be called from Python.
@@ -308,7 +312,7 @@ print "Proc %d out of %d procs" % (pypar.rank(),pypar.size())
 
      
 
      
 
-
      Testing the Python-LAMMPS interface 
+
      11.5 Testing the Python-LAMMPS interface 
 
      
 
      Before using LAMMPS in a Python program, one more step is needed.  The
 interface to LAMMPS is via the Python ctypes package, which loads the
@@ -402,7 +406,7 @@ Python on a single processor, not in parallel.
 
 
      
 
-
      Using LAMMPS from Python 
+
      11.6 Using LAMMPS from Python 
 
      
 
      The Python interface to LAMMPS consists of a Python "lammps" module,
 the source code for which is in python/lammps.py, which creates a
@@ -498,7 +502,7 @@ subscripting.  The one exception is that for a fix that calculates a
 global vector or array, a single double value from the vector or array
 is returned, indexed by I (vector) or I and J (array).  I,J are
 zero-based indices.  The I,J arguments can be left out if not needed.
-See this section of the manual for a
+See this section of the manual for a
 discussion of global, per-atom, and local data, and of scalar, vector,
 and array data types.  See the doc pages for individual
 computes and fixes for a description of what
@@ -578,7 +582,7 @@ following steps:
 src/library.h. 
 
 
    • Verify the new function is syntactically correct by building LAMMPS as
-a library - see this section of the
+a library - see this section of the
 manual. 
 
 
    • Add a wrapper method in the Python LAMMPS module to python/lammps.py
@@ -594,7 +598,7 @@ Python script.  Isn't ctypes amazing?
 
 
      
 
-
      Example Python scripts that use LAMMPS 
+
      11.7 Example Python scripts that use LAMMPS 
 
      
 
      These are the Python scripts included as demos in the python/examples
 directory of the LAMMPS distribution, to illustrate the kinds of
diff --git a/doc/Section_python.txt b/doc/Section_python.txt
index edb3141370..6a80a827b3 100644
--- a/doc/Section_python.txt
+++ b/doc/Section_python.txt
@@ -6,7 +6,18 @@
 
 :line
 
-9. Python interface to LAMMPS :h3
+11. Python interface to LAMMPS :h3
+
+This section describes how to build and use LAMMPS via a Python
+interface.
+
+11.1 "Extending Python with a serial version of LAMMPS"_#py_1
+11.2 "Creating a shared MPI library"_#py_2
+11.3 "Extending Python with a parallel version of LAMMPS"_#py_3
+11.4 "Extending Python with MPI"_#py_4
+11.5 "Testing the Python-LAMMPS interface"_#py_5
+11.6 "Using LAMMPS from Python"_#py_6
+11.7 "Example Python scripts that use LAMMPS"_#py_7 :ul
 
 The LAMMPS distribution includes some Python code in its python
 directory which wraps the library interface to LAMMPS.  This makes it
@@ -18,15 +29,16 @@ either from a Python script or interactively from a Python prompt.
 language which can be used to wrap software like LAMMPS and other
 packages.  It can be used to glue multiple pieces of software
 together, e.g. to run a coupled or multiscale model.  See "this
-section"_Section_howto.html#4_10 of the manual and the couple
+section"_Section_howto.html#howto_10 of the manual and the couple
 directory of the distribution for more ideas about coupling LAMMPS to
-other codes.  See "this section"_Section_start.html#2_4 about how to
-build LAMMPS as a library, and "this section"_Section_howto.html#4_19
-for a description of the library interface provided in src/library.cpp
-and src/library.h and how to extend it for your needs.  As described
-below, that interface is what is exposed to Python.  It is designed to
-be easy to add functions to.  This has the effect of extending the
-Python inteface as well.  See details below.
+other codes.  See "this section"_Section_start.html#start_4 about how
+to build LAMMPS as a library, and "this
+section"_Section_howto.html#howto_19 for a description of the library
+interface provided in src/library.cpp and src/library.h and how to
+extend it for your needs.  As described below, that interface is what
+is exposed to Python.  It is designed to be easy to add functions to.
+This has the effect of extending the Python inteface as well.  See
+details below.
 
 By using the Python interface LAMMPS can also be coupled with a GUI or
 visualization tools that display graphs or animations in real time as
@@ -85,14 +97,6 @@ setup discussion.  The next to last sub-section describes the Python
 syntax used to invoke LAMMPS.  The last sub-section describes example
 Python scripts included in the python directory.
 
-"Extending Python with a serial version of LAMMPS"_#9_1
-"Creating a shared MPI library"_#9_2
-"Extending Python with a parallel version of LAMMPS"_#9_3
-"Extending Python with MPI"_#9_4
-"Testing the Python-LAMMPS interface"_#9_5
-"Using LAMMPS from Python"_#9_6
-"Example Python scripts that use LAMMPS"_#9_7 :ul
-
 Before proceeding, there are 2 items to note.
 
 (1) The provided Python wrapper for LAMMPS uses the amazing and
@@ -114,7 +118,7 @@ code, you are not building shared versions of these libraries.
 The discussion below describes how to create a shared MPI library.  I
 suggest you start by configuing LAMMPS without packages installed that
 require any libraries besides MPI.  See "this
-section"_Section_start.html#2_3 of the manual for a discussion of
+section"_Section_start.html#start_3 of the manual for a discussion of
 LAMMPS pacakges.  E.g. do not use the KSPACE, GPU, MEAM, POEMS, or
 REAX packages.
 
@@ -130,7 +134,7 @@ LAMMPS wrapper.
 :line
 :line
 
-Extending Python with a serial version of LAMMPS :link(9_1),h4
+11.1 Extending Python with a serial version of LAMMPS :link(py_1),h4
 
 From the python directory in the LAMMPS distribution, type
 
@@ -160,7 +164,7 @@ If these commands are successful, a {lammps.py} and
 
 :line
 
-Creating a shared MPI library :link(9_2),h4
+11.2 Creating a shared MPI library :link(py_2),h4
 
 A shared library is one that is dynamically loadable, which is what
 Python requires.  On Linux this is a library file that ends in ".so",
@@ -171,7 +175,7 @@ by Argonne National Labs.  From within the mpich directory, type
 
 :link(mpich,http://www-unix.mcs.anl.gov/mpi)
 
-./configure --enable-sharedlib=gcc
+./configure --enable-shared
 make
 make install :pre
 
@@ -184,14 +188,14 @@ static and shared MPI library.  This will be fine for running LAMMPS
 from Python since it only uses the shared library.  But if you now try
 to build LAMMPS by itself as a stand-alone program (cd lammps/src;
 make foo) or build other codes that expect to link against libmpich.a,
-then those builds will typically fail if the linker uses libmpich.so
-instead.  This means you will need to remove the file
+then those builds may fail if the linker uses libmpich.so instead.  If
+this happens, it means you will need to remove the file
 /usr/local/lib/libmich.so before building LAMMPS again as a
 stand-alone code.
 
 :line
 
-Extending Python with a parallel version of LAMMPS :link(9_3),h4
+11.3 Extending Python with a parallel version of LAMMPS :link(py_3),h4
 
 From the python directory, type
 
@@ -229,7 +233,7 @@ will be put in the appropriate directory.
 
 :line
 
-Extending Python with MPI :link(9_4),h4
+11.4 Extending Python with MPI :link(py_4),h4
 
 There are several Python packages available that purport to wrap MPI
 as a library and allow MPI functions to be called from Python.
@@ -304,7 +308,7 @@ and see one line of output for each processor you ran on.
 
 :line
 
-Testing the Python-LAMMPS interface :link(9_5),h4
+11.5 Testing the Python-LAMMPS interface :link(py_5),h4
 
 Before using LAMMPS in a Python program, one more step is needed.  The
 interface to LAMMPS is via the Python ctypes package, which loads the
@@ -397,7 +401,7 @@ Python on a single processor, not in parallel.
 :line
 :line
 
-Using LAMMPS from Python :link(9_6),h4
+11.6 Using LAMMPS from Python :link(py_6),h4
 
 The Python interface to LAMMPS consists of a Python "lammps" module,
 the source code for which is in python/lammps.py, which creates a
@@ -493,7 +497,7 @@ subscripting.  The one exception is that for a fix that calculates a
 global vector or array, a single double value from the vector or array
 is returned, indexed by I (vector) or I and J (array).  I,J are
 zero-based indices.  The I,J arguments can be left out if not needed.
-See "this section"_Section_howto.html#4_15 of the manual for a
+See "this section"_Section_howto.html#howto_15 of the manual for a
 discussion of global, per-atom, and local data, and of scalar, vector,
 and array data types.  See the doc pages for individual
 "computes"_compute.html and "fixes"_fix.html for a description of what
@@ -573,7 +577,7 @@ Add a new interface function to src/library.cpp and
 src/library.h. :ulb,l
 
 Verify the new function is syntactically correct by building LAMMPS as
-a library - see "this section"_Section_start.html#2_4 of the
+a library - see "this section"_Section_start.html#start_4 of the
 manual. :l
 
 Add a wrapper method in the Python LAMMPS module to python/lammps.py
@@ -588,7 +592,7 @@ Python script.  Isn't ctypes amazing? :l,ule
 :line
 :line
 
-Example Python scripts that use LAMMPS :link(9_7),h4
+11.7 Example Python scripts that use LAMMPS :link(py_7),h4
 
 These are the Python scripts included as demos in the python/examples
 directory of the LAMMPS distribution, to illustrate the kinds of
diff --git a/doc/Section_start.html b/doc/Section_start.html
index d157bf079f..4d64107295 100644
--- a/doc/Section_start.html
+++ b/doc/Section_start.html
@@ -14,19 +14,20 @@
 
      This section describes how to build and run LAMMPS, for both new and
 experienced users.
 
      
-2.1 What's in the LAMMPS distribution
      
-2.2 Making LAMMPS
      
-2.3 Making LAMMPS with optional packages
      
-2.4 Building LAMMPS as a library
      
-2.5 Running LAMMPS
      
-2.6 Command-line options
      
-2.7 Screen output
      
-2.8 Running on GPUs
      
-2.9 Tips for users of previous versions 
      
+2.1 What's in the LAMMPS distribution
      
+2.2 Making LAMMPS
      
+2.3 Making LAMMPS with optional packages
      
+2.4 Building LAMMPS as a library
      
+2.5 Running LAMMPS
      
+2.6 Command-line options
      
+2.7 Screen output
      
+2.8 Tips for users of previous versions 
      
 
 
      
 
-
      2.1 What's in the LAMMPS distribution 
+
      
+
+
      2.1 What's in the LAMMPS distribution 
 
      
 
      When you download LAMMPS you will need to unzip and untar the
 downloaded file with the following commands, after placing the file in
@@ -50,46 +51,51 @@ sub-directories:
 tools pre- and post-processing tools 
 
 
-
      If you download the Windows executable from the download page,
+
      If you download one of the Windows executables from the download page,
 then you just get a single file:
 
      
 
      lmp_windows.exe 
 
      
-
      Skip to the Running LAMMPS section, to learn how to launch this
-executable on a Windows box.
+
      Skip to the Running LAMMPS sections for info on how to
+launch these executables on a Windows box.
 
      
-
      The Windows executable also only includes certain packages and
-bug-fixes/upgrades listed on this
+
      The Windows executables for serial or parallel only include certain
+packages and bug-fixes/upgrades listed on this
 page up to a certain date, as
 stated on the download page.  If you want something with more packages
 or that is more current, you'll have to download the source tarball
-and build it yourself, as described in the next section.
+and build it yourself from source code using Microsoft Visual Studio,
+as described in the next section.
 
      
 
      
 
-
      2.2 Making LAMMPS 
+
      2.2 Making LAMMPS 
 
      
 
      This section has the following sub-sections:
 
      
-
      • Read this first
-
      • Building a LAMMPS executable
-
      • Common errors that can occur when making LAMMPS
-
      • Editing a new low-level Makefile
-
      • Additional build tips 
+
 
        
 
-Read this first: 
+Read this first: 
 
-
        Building LAMMPS can be non-trivial.  You will likely need to edit a
-makefile, there are compiler options, additional libraries can be used
-(MPI, FFT), etc.  Please read this section carefully.  If you are not
-comfortable with makefiles, or building codes on a Unix platform, or
-running an MPI job on your machine, please find a local expert to help
-you.  Many compiling, linking, and run problems that users are not
-really LAMMPS issues - they are peculiar to the user's system,
-compilers, libraries, etc.  Such questions are better answered by a
-local expert.
+
        Building LAMMPS can be non-trivial.  You may need to edit a makefile,
+there are compiler options to consider, additional libraries can be
+used (MPI, FFT, JPEG), LAMMPS packages may be included or excluded,
+some of these packages use auxiliary libraries which need to be
+pre-built, etc.
+
        
+
        Please read this section carefully.  If you are not comfortable with
+makefiles, or building codes on a Unix platform, or running an MPI job
+on your machine, please find a local expert to help you.  Many
+compiling, linking, and run problems that users have are not really
+LAMMPS issues - they are peculiar to the user's system, compilers,
+libraries, etc.  Such questions are better answered by a local expert.
 
        
 
        If you have a build problem that you are convinced is a LAMMPS issue
 (e.g. the compiler complains about a line of LAMMPS source code), then
@@ -102,16 +108,19 @@ to the developers and we'll include it in future LAMMPS releases.
 
        
 
        
 
-Building a LAMMPS executable: 
+Steps to build a LAMMPS executable: 
 
+
        Step 0
+
        
 
        The src directory contains the C++ source and header files for LAMMPS.
 It also contains a top-level Makefile and a MAKE sub-directory with
-low-level Makefile.* files for several machines.  From within the src
+low-level Makefile.* files for many machines.  From within the src
 directory, type "make" or "gmake".  You should see a list of available
 choices.  If one of those is the machine and options you want, you can
 type a command like:
 
        
 
        make linux
+or
 gmake mac 
 
        
 
        Note that on a multi-processor or multi-core platform you can launch a
@@ -121,63 +130,34 @@ will build LAMMPS more quickly.
 
        If you get no errors and an executable like lmp_linux or lmp_mac is
 produced, you're done; it's your lucky day.
 
        
-
        
-
-Common errors that can occur when making LAMMPS: 
-
-
        (1) If the make command breaks immediately with errors that indicate
-it can't find files with a "*" in their names, this can be because
-your machine's make doesn't support wildcard expansion in a makefile.
-Try gmake instead of make.  If that doesn't work, try using a -f
-switch with your make command to use Makefile.list which explicitly
-lists all the needed files, e.g.
+
        Note that by default only a few of LAMMPS optional pacakges are
+installed.  To build LAMMPS with optional packages, see this
+section below.
 
        
-
        make makelist
-make -f Makefile.list linux
-gmake -f Makefile.list mac 
-
        
-
        The first "make" command will create a current Makefile.list with all
-the file names in your src dir.  The 2nd "make" command (make or
-gmake) will use it to build LAMMPS.
+
        Step 1
 
        
-
        (2) Other errors typically occur because the low-level Makefile isn't
-setup correctly for your machine.  If your platform is named "foo",
-you will need to create a Makefile.foo in the MAKE sub-directory.  Use
-whatever existing file is closest to your platform as a starting
-point.  See the next section for more instructions.
+
        If Step 0 did not work, you will need to create a low-level Makefile
+for your machine, like Makefile.foo.  You should make a copy of an
+existing src/MAKE/Makefile.* as a starting point.  The only portions
+of the file you need to edit are the first line, the "compiler/linker
+settings" section, and the "LAMMPS-specific settings" section.
 
        
-
        (3) If you get a link-time error about missing libraries or missing
-dependencies, then it can be because:
+
        Step 2
 
        
-
        • you are including a package that needs an extra library, but have not pre-built the necessary package library
-
        • you are linking to a library that doesn't exist on your system
-
        • you are not linking to the necessary system library 
-
        
-
        The first issue is discussed below.  The other two issue mean you need
-to edit your low-level Makefile.foo, as discussed in the next
-sub-section.
+
        Change the first line of src/MAKE/Makefile.foo to list the word "foo"
+after the "#", and whatever other options it will set.  This is the
+line you will see if you just type "make".
 
        
-
        
-
-Editing a new low-level Makefile.foo: 
-
-
        These are the issues you need to address when editing a low-level
-Makefile for your machine.  The portions of the file you typically
-need to edit are the first line, the "compiler/linker settings"
-section, and the "system-specific settings" section.
+
        Step 3
 
        
-
        (1) Change the first line of Makefile.foo to list the word "foo" after
-the "#", and whatever other options you set.  This is the line you
-will see if you just type "make".
-
        
-
        (3) The "compiler/linker settings" section lists compiler and linker
+
        The "compiler/linker settings" section lists compiler and linker
 settings for your C++ compiler, including optimization flags.  You can
 use g++, the open-source GNU compiler, which is available on all Unix
 systems.  You can also use mpicc which will typically be available if
 MPI is installed on your system, though you should check which actual
 compiler it wraps.  Vendor compilers often produce faster code.  On
-boxes with Intel CPUs, we suggest using the free Intel icc compiler,
-which you can download from Intel's compiler site.
+boxes with Intel CPUs, we suggest using the commercial Intel icc
+compiler, which can be downloaded from Intel's compiler site.
 
        
 
 
@@ -189,111 +169,257 @@ dependency list for a source file.  This speeds re-compilation when
 source (*.cpp) or header (*.h) files are edited.  Some compilers do
 not support dependency file creation, or may use a different switch
 than -D.  GNU g++ works with -D.  If your compiler can't create
-dependency files (a long list of errors involving *.d files), then
-you'll need to create a Makefile.foo patterned after Makefile.storm,
-which uses different rules that do not involve dependency files.
+dependency files, then you'll need to create a Makefile.foo patterned
+after Makefile.storm, which uses different rules that do not involve
+dependency files.  Note that when you build LAMMPS for the first time
+on a new platform, a long list of *.d files will be printed out
+rapidly.  This is not an error; it is the Makefile doing its normal
+creation of dependencies.
 
        
-
        (3) The "system-specific settings" section has 4 parts.
+
        Step 4
 
        
-
        (3.a) The LMP_INC variable is used to include options that turn on
-system-dependent ifdefs within the LAMMPS code.
+
        The "system-specific settings" section has several parts.  Note that
+if you change any -D setting in this section, you should do a full
+re-compile, after typing "make clean" (which will describe different
+clean options).
 
        
+
        The LMP_INC variable is used to include options that turn on ifdefs
+within the LAMMPS code.  The options that are currently recogized are:
+
        
+
        • -DLAMMPS_GZIP
+
        • -DLAMMPS_JPEG
+
        • -DLAMMPS_MEMALIGN
+
        • -DLAMMPS_XDR
+
        • -DLAMMPS_SMALLBIG
+
        • -DLAMMPS_BIGBIG
+
        • -DLAMMPS_SMALLSMALL
+
        • -DLAMMPS_LONGLONG_TO_LONG
+
        • -DPACK_ARRAY
+
        • -DPACK_POINTER
+
        • -DPACK_MEMCPY 
+
        
 
        The read_data and dump commands will read/write gzipped files if you
 compile with -DLAMMPS_GZIP.  It requires that your Unix support the
-"popen" command.  Using one of the -DPACK_ARRAY, -DPACK_POINTER, and
--DPACK_MEMCPY options can make for faster parallel FFTs (in the PPPM
-solver) on some platforms.  The -DPACK_ARRAY setting is the default.
-If you use -DLAMMPS_XDR, the build will include XDR compatibility
+"popen" command.
+
        
+
        If you use -DLAMMPS_JPEG, the dump image command will be
+able to write out JPEG image files.  If not, it will only be able to
+write out text-based PPM image files.  For JPEG files, you must also
+link LAMMPS with a JPEG library, as described below.
+
        
+
        Using -DLAMMPS_MEMALIGN= enables the use of the
+posix_memalign() call instead of malloc() when large chunks or memory
+are allocated by LAMMPS.  This can help to make more efficient use of
+vector instructions of modern CPUS, since dynamically allocated memory
+has to be aligned on larger than default byte boundaries (e.g. 16
+bytes instead of 8 bytes on x86 type platforms) for optimal
+performance.
+
        
+
        If you use -DLAMMPS_XDR, the build will include XDR compatibility
 files for doing particle dumps in XTC format.  This is only necessary
 if your platform does have its own XDR files available.  See the
 Restrictions section of the dump command for details.
 
        
-
        (3.b) The 3 MPI variables are used to specify an MPI library to build
-LAMMPS with.
+
        Use at most one of the -DLAMMPS_SMALLBIG, -DLAMMPS_BIGBIG,
+-D-DLAMMPS_SMALLSMALL settings.  The default is -DLAMMPS_SMALLBIG.
+These refer to use of 4-byte (small) vs 8-byte (big) integers within
+LAMMPS, as described in src/lmptype.h.  The only reason to use the
+BIGBIG setting is to enable simulation of huge molecular systems with
+more than 2 billion atoms.  The only reason to use the SMALLSMALL
+setting is if your machine does not support 64-bit integers.
+
        
+
        The -DLAMMPS_LONGLONG_TO_LONG setting may be needed if your system or
+MPI version does not recognize "long long" data types.  In this case a
+"long" data type is likely already 64-bits, in which case this setting
+will convert to that data type.
+
        
+
        Using one of the -DPACK_ARRAY, -DPACK_POINTER, and -DPACK_MEMCPY
+options can make for faster parallel FFTs (in the PPPM solver) on some
+platforms.  The -DPACK_ARRAY setting is the default.  See the
+kspace_style command for info about PPPM.  See
+Step 6 below for info about building LAMMPS with an FFT library.
+
        
+
        Step 5
+
        
+
        The 3 MPI variables are used to specify an MPI library to build LAMMPS
+with. 
 
        
 
        If you want LAMMPS to run in parallel, you must have an MPI library
 installed on your platform.  If you use an MPI-wrapped compiler, such
-as "mpicc" to build LAMMPS, you can probably leave these 3 variables
-blank.  If you do not use "mpicc" as your compiler/linker, then you
-need to specify where the mpi.h file (MPI_INC) and the MPI library
-(MPI_PATH) is found and its name (MPI_LIB).
+as "mpicc" to build LAMMPS, you should be able to leave these 3
+variables blank; the MPI wrapper knows where to find the needed files.
+If not, and MPI is installed on your system in the usual place (under
+/usr/local), you also may not need to specify these 3 variables.  On
+some large parallel machines which use "modules" for their
+compile/link environements, you may simply need to include the correct
+module in your build environment.  Or the parallel machine may have a
+vendor-provided MPI which the compiler has no trouble finding.
 
        
-
        If you are installing MPI yourself, we recommend Argonne's MPICH 1.2
-or 2.0 which can be downloaded from the Argonne MPI
-site.  LAM MPI should also work.  If
-you are running on a big parallel platform, your system people or the
-vendor should have already installed a version of MPI, which will be
-faster than MPICH or LAM, so find out how to build and link with it.
-If you use MPICH or LAM, you will have to configure and build it for
-your platform.  The MPI configure script should have compiler options
-to enable you to use the same compiler you are using for the LAMMPS
-build, which can avoid problems that can arise when linking LAMMPS to
-the MPI library.
+
        Failing this, with these 3 variables you can specify where the mpi.h
+file (MPI_INC) and the MPI library file (MPI_PATH) are found and the
+name of the library file (MPI_LIB).
 
        
-
        If you just want LAMMPS to run on a single processor, you can use the
-STUBS library in place of MPI, since you don't need an MPI library
-installed on your system.  See the Makefile.serial file for how to
-specify the 3 MPI variables.  You will also need to build the STUBS
-library for your platform before making LAMMPS itself.  From the STUBS
-dir, type "make" and it will hopefully create a libmpi.a suitable for
-linking to LAMMPS.  If this build fails, you will need to edit the
-STUBS/Makefile for your platform.
+
        If you are installing MPI yourself, we recommend Argonne's MPICH2
+or OpenMPI.  MPICH can be downloaded from the Argonne MPI
+site.  OpenMPI can
+be downloaded from the OpenMPI site.
+Other MPI packages should also work. If you are running on a big
+parallel platform, your system people or the vendor should have
+already installed a version of MPI, which is likely to be faster
+than a self-installed MPICH or OpenMPI, so find out how to build
+and link with it.  If you use MPICH or OpenMPI, you will have to
+configure and build it for your platform.  The MPI configure script
+should have compiler options to enable you to use the same compiler
+you are using for the LAMMPS build, which can avoid problems that can
+arise when linking LAMMPS to the MPI library.
 
        
-
        The file STUBS/mpi.cpp has a CPU timer function MPI_Wtime() that calls
-gettimeofday() .  If your system doesn't support gettimeofday() ,
-you'll need to insert code to call another timer.  Note that the
-ANSI-standard function clock() rolls over after an hour or so, and is
-therefore insufficient for timing long LAMMPS simulations.
+
        If you just want to run LAMMPS on a single processor, you can use the
+dummy MPI library provided in src/STUBS, since you don't need a true
+MPI library installed on your system.  See the
+src/MAKE/Makefile.serial file for how to specify the 3 MPI variables
+in this case.  You will also need to build the STUBS library for your
+platform before making LAMMPS itself.  From the src directory, type
+"make stubs", or from the STUBS dir, type "make" and it should create
+a libmpi.a suitable for linking to LAMMPS.  If this build fails, you
+will need to edit the STUBS/Makefile for your platform.
 
        
-
        (3.c) The 3 FFT variables are used to specify an FFT library which
-LAMMPS uses when using the particle-particle particle-mesh (PPPM)
-option in LAMMPS for long-range Coulombics via the
+
        The file STUBS/mpi.cpp provides a CPU timer function called
+MPI_Wtime() that calls gettimeofday() .  If your system doesn't
+support gettimeofday() , you'll need to insert code to call another
+timer.  Note that the ANSI-standard function clock() rolls over after
+an hour or so, and is therefore insufficient for timing long LAMMPS
+simulations.
+
        
+
        Step 6
+
        
+
        The 3 FFT variables allow you to specify an FFT library which LAMMPS
+uses (for performing 1d FFTs) when running the particle-particle
+particle-mesh (PPPM) option for long-range Coulombics via the
 kspace_style command.
 
        
-
        To use this option, you must have a 1d FFT library installed on your
-platform.  This is specified by a switch of the form -DFFT_XXX where
-XXX = INTEL, DEC, SGI, SCSL, or FFTW.  All but the last one are native
-vendor-provided libraries.  FFTW is a fast, portable library that
-should work on any platform.  You can download it from
-www.fftw.org.  Use version 2.1.X, not the newer
-3.0.X.  Building FFTW for your box should be as simple as ./configure;
-make.  Whichever FFT library you have on your platform, you'll need to
-set the appropriate FFT_INC, FFT_PATH, and FFT_LIB variables in
-Makefile.foo.
+
        LAMMPS supports various open-source or vendor-supplied FFT libraries
+for this purpose.  If you leave these 3 variables blank, LAMMPS will
+use the open-source KISS FFT library, which is
+included in the LAMMPS distribution.  This library is portable to all
+platforms and for typical LAMMPS simulations is almost as fast as FFTW
+or vendor optimized libraries.  If you are not including the KSPACE
+package in your build, you can also leave the 3 variables blank.
 
        
-
        If you examine src/fft3d.c and src.fft3d.h you'll see it's possible to
-add other vendor FFT libraries via #ifdef statements in the
-appropriate places.  If you successfully add a new FFT option, like
--DFFT_IBM, please send the LAMMPS developers an email; we'd like to
-add it to LAMMPS.
+
        Otherwise, select which kinds of FFTs to use as part of the FFT_INC
+setting by a switch of the form -DFFT_XXX.  Recommended values for XXX
+are: MKL, SCSL, FFTW2, and FFTW3.  Legacy options are: INTEL, SGI,
+ACML, and T3E.  For backward compatability, using -DFFT_FFTW will use
+the FFTW2 library.  Using -DFFT_NONE will use the KISS library
+described above.
 
        
-
        If you don't plan to use PPPM, you don't need an FFT library.  In this
-case you can set FFT_INC to -DFFT_NONE and leave the other 2 FFT
-variables blank.  Or you can exclude the KSPACE package when you build
-LAMMPS (see below).
+
        You may also need to set the FFT_INC, FFT_PATH, and FFT_LIB variables,
+so the compiler and linker can find the needed FFT header and library
+files.  Note that on some large parallel machines which use "modules"
+for their compile/link environements, you may simply need to include
+the correct module in your build environment.  Or the parallel machine
+may have a vendor-provided FFT library which the compiler has no
+trouble finding.
 
        
-
        (3.d) The several SYSLIB and SYSPATH variables can be ignored unless
-you are building LAMMPS with one or more of the LAMMPS packages that
-require these extra system libraries.  The names of these packages are
-the prefixes on the SYSLIB and SYSPATH variables.  See the section
-below for more details.  The SYSLIB variables list the system
-libraries.  The SYSPATH variables are where they are located on your
-machine, which is typically only needed if they are in some
-non-standard place, that is not in your library search path.
+
        FFTW is a fast, portable library that should also work on any
+platform.  You can download it from
+www.fftw.org.  Both the legacy version 2.1.X and
+the newer 3.X versions are supported as -DFFT_FFTW2 or -DFFT_FFTW3.
+Building FFTW for your box should be as simple as ./configure; make.
+Note that on some platforms FFTW2 has been pre-installed, and uses
+renamed files indicating the precision it was compiled with,
+e.g. sfftw.h, or dfftw.h instead of fftw.h.  In this case, you can
+specify an additional define variable for FFT_INC called -DFFTW2_SIZE,
+which will select the correct include file.  In this case, for FFT_LIB
+you must also manually specify the correct library, namely -lsfftw or
+-ldfftw.
 
        
-
        That's it.  Once you have a correct Makefile.foo and you have
-pre-built any other libraries it will use (e.g. MPI, FFT, package
-libraries), all you need to do from the src directory is type one of
-these 2 commands:
+
        The FFT_INC variable also allows for a -DFFT_SINGLE setting that will
+use single-precision FFTs with PPPM, which can speed-up long-range
+calulations, particularly in parallel or on GPUs.  Fourier transform
+and related PPPM operations are somewhat insensitive to floating point
+truncation errors and thus do not always need to be performed in
+double precision.  Using the -DFFT_SINGLE setting trades off a little
+accuracy for reduced memory use and parallel communication costs for
+transposing 3d FFT data.  Note that single precision FFTs have only
+been tested with the FFTW3, FFTW2, MKL, and KISS FFT options.
+
        
+
        Step 7
+
        
+
        The 3 JPG variables allow you to specify a JPEG library which LAMMPS
+uses when writing out JPEG files via the dump image
+command.  These can be left blank if you do not use the -DLAMMPS_JPEG
+switch discussed above in Step 4, since in that case JPEG output will
+be disabled.
+
        
+
        A standard JPEG library usually goes by the name libjpeg.a and has an
+associated header file jpeglib.h.  Whichever JPEG library you have on
+your platform, you'll need to set the appropriate JPG_INC, JPG_PATH,
+and JPG_LIB variables, so that the compiler and linker can find it.
+
        
+
        As before, if these header and library files are in the usual place on
+your machine, you may not need to set these variables.
+
        
+
        Step 8
+
        
+
        Note that by default only a few of LAMMPS optional pacakges are
+installed.  To build LAMMPS with optional packages, see this
+section below, before proceeding to Step 9.
+
        
+
        Step 9
+
        
+
        That's it.  Once you have a correct Makefile.foo, you have installed
+the optional LAMMPS packages you want to include in your build, and
+you have pre-built any other needed libraries (e.g. MPI, FFT, package
+libraries), all you need to do from the src directory is type
+something like this:
 
        
 
        make foo
+or
 gmake foo 
 
        
 
        You should get the executable lmp_foo when the build is complete.
 
        
 
        
 
-Additional build tips: 
+Errors that can occur when making LAMMPS: 
+
+
        IMPORTANT NOTE: If an error occurs when building LAMMPS, the compiler
+or linker will state very explicitly what the problem is.  The error
+message should give you a hint as to which of the steps above has
+failed, and what you need to do in order to fix it.  Building a code
+with a Makefile is a very logical process.  The compiler and linker
+need to find the appropriate files and those files need to be
+compatible with LAMMPS source files.  When a make fails, there is
+usually a very simple reason, which you or a local expert will need to
+fix.
+
        
+
        Here are two non-obvious errors that can occur:
+
        
+
        (1) If the make command breaks immediately with errors that indicate
+it can't find files with a "*" in their names, this can be because
+your machine's native make doesn't support wildcard expansion in a
+makefile.  Try gmake instead of make.  If that doesn't work, try using
+a -f switch with your make command to use a pre-generated
+Makefile.list which explicitly lists all the needed files, e.g.
+
        
+
        make makelist
+make -f Makefile.list linux
+gmake -f Makefile.list mac 
+
        
+
        The first "make" command will create a current Makefile.list with all
+the file names in your src dir.  The 2nd "make" command (make or
+gmake) will use it to build LAMMPS.  Note that you should
+include/exclude any desired optional packages before using the "make
+makelist" command.
+
        
+
        (2) If you get an error that says something like 'identifier "atoll"
+is undefined', then your machine does not support "long long"
+integers.  Try using the -DLAMMPS_LONGLONG_TO_LONG setting described
+above in Step 4.
+
        
+
        
+
+Additional build tips: 
 
 
        (1) Building LAMMPS for multiple platforms.
 
        
@@ -307,27 +433,7 @@ Obj_name where it stores the system-specific *.o files.
 files created when LAMMPS is built, for either all builds or for a
 particular machine.
 
        
-
        (3) Building for a Mac.
-
        
-
        OS X is BSD Unix, so it should just work.  See the Makefile.mac file.
-
        
-
        (4) Building for MicroSoft Windows.
-
        
-
        The LAMMPS download page has an option to download a pre-built Windows
-exeutable.  See below for instructions for running this executable on
-a Windows box.
-
        
-
        If the pre-built executable doesn't have the options you want, then
-you should be able to build LAMMPS from source files on a Windows box.
-I've never done this, but LAMMPS is just standard C++ with MPI and FFT
-calls.  You can use cygwin to build LAMMPS with a Unix make; see
-Makefile.cygwin.  Or you should be able to pull all the source files
-into Visual C++ (ugh) or some similar development environment and
-build it.  In the src/MAKE/Windows directory are some notes from users
-on how they built LAMMPS under Windows, so you can look at their
-instructions for tips.  Good luck - we can't help you on this one.
-
        
-
        (5) Changing the size limits in src/lmptype.h
+
        (3) Changing the size limits in src/lmptype.h
 
        
 
        If you are running a very large problem (billions of atoms or more)
 and get a run-time error about the system being too big, either on a
@@ -349,10 +455,10 @@ are effectively unlimited in size (2^63).
 
        
 
        The default for total system size quantities (like the number of atoms
 or timesteps) is 8-byte integers by default which is effectively
-unlimited in size (2^63).  If your system does not support 8-byte
-integers, an error will be generated, and you will need to set
-"bigint" to 4-byte integers.  This restricts your total system size to
-about 2 billion atoms or timesteps (2^31).
+unlimited in size (2^63).  If your system or MPI implementation does
+not support 8-byte integers, an error will be generated, and you will
+need to set "bigint" to 4-byte integers.  This restricts your total
+system size to about 2 billion atoms or timesteps (2^31).
 
        
 
        Note that in src/lmptype.h there are also settings for the MPI data
 types associated with the integers that store atom IDs and total
@@ -368,250 +474,236 @@ secs/timestep.
 
        
 
        
 
-
        2.3 Making LAMMPS with optional packages 
+Building for a Mac: 
+
+
        OS X is BSD Unix, so it should just work.  See the Makefile.mac file.
+
        
+
        
+
+Building for Windows: 
+
+
        The LAMMPS download page has an option to download both a serial and
+parallel pre-built Windows exeutable.  See the Running
+LAMMPS section for instructions for running these
+executables on a Windows box.
+
        
+
        If the pre-built executable doesn't have the options you want, then
+you can build LAMMPS from its source files on a Windows box.  One way
+to do this is install and use cygwin to build LAMMPS with a standard
+Linus make, just as you would on any Linux box; see
+src/MAKE/Makefile.cygwin.
+
        
+
        There is a also a src/WINDOWS directory that contains project files
+for Microsoft Visual Studio 2005, which should also work with later
+versions of VS.  That directory contains a README.txt file which
+provides instructions for building LAMMPS from source code using
+Visual Studio that are hopefully easy to follow for Windows and VS
+users.
+
        
+
        Four VS project options are provided.  The first includes the default
+packages (MANYBODY, MOLECULE, and KSPACE).  The second includes all
+standard packages (except GPU, MEAM, and REAX which are not yet
+included because they require NVIDIA or Fortran compilation).  The
+third includes all standard packages (with the exceptions) and some
+user packages.  The included user packages are USER-EFF, USER-CG-CMM,
+and USER-REAXC.  The fourth project includes the USER-AWPMD package.
+
        
+
        
+
+
        2.3 Making LAMMPS with optional packages 
 
        
 
        This section has the following sub-sections:
 
        
-
        • Package basics
-
        • Including/excluding packages
-
        • Packages that require extra LAMMPS libraries
-
        • Additional Makefile settings for extra libraries 
+
 
          
 
-Package basics: 
+Package basics: 
 
-
          The source code for LAMMPS is structured as a large set of core files
-which 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.  You can see the list of all packages by typing "make
-package".
+
          The source code for LAMMPS is structured as a set of core files which
+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.  You
+can see the list of all packages by typing "make package" from within
+the src directory of the LAMMPS distribution.
 
          
-
          The current list of standard packages is as follows:
+
          If you use a command in a LAMMPS input script that is specific to a
+particular package, you must have built LAMMPS with that package, else
+you will get an error that the style is invalid or the command is
+unknown.  Every command's doc page specfies if it is part of a
+package.  You can also type
 
          
-
          
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
          asphere  aspherical particles and force fields
          class2  class 2 force fields
          colloid  colloidal particle force fields
          dipole  point dipole particles and force fields
          dsmc  Direct Simulation Monte Carlo (DMSC) pair style
          gpu  GPU-enabled force field styles
          granular  force fields and boundary conditions for granular systems
          kspace  long-range Ewald and particle-mesh (PPPM) solvers
          manybody  metal, 3-body, bond-order potentials
          meam  modified embedded atom method (MEAM) potential
          molecule  force fields for molecular systems
          opt  optimized versions of a few pair potentials
          peri  Peridynamics model and potential
          poems  coupled rigid body motion
          reax  ReaxFF potential
          replica  multi-replica methods
          shock  methods for MD simulations of shock loading
          srd  stochastic rotation dynamics (SRD)
          xtc  dump atom snapshots in XTC format 
-
          
-
-
          There are also user-contributed packages which may be as simple as a
-single additional file or many files grouped together which add a
-specific functionality to the code.
+
          lmp_machine -h 
+
          
+
          to run your executable with the optional -h command-line
+switch for "help", which will list the styles and commands
+known to your executable.
 
          
-
          The difference between a standard package versus a user package is
-as follows.
+
          There are two kinds of packages in LAMMPS, standard and user packages.
+More information about the contents of standard and user packages is
+given in this section of the manual.  The
+difference between standard and user packages is as follows:
 
          
 
          Standard packages are supported by the LAMMPS developers and are
 written in a syntax and style consistent with the rest of LAMMPS.
 This means we will answer questions about them, debug and fix them if
 necessary, and keep them compatible with future changes to LAMMPS.
 
          
-
          User packages don't necessarily meet these requirements.  If you have
-problems using a feature provided in a user package, you will likely
-need to contact the contributor directly to get help.  Information on
-how to submit additions you make to LAMMPS as a user-contributed
-package is given in this section of the
-documentation.
+
          User packages have been contributed by users, and always begin with
+the user prefix.  If they are a single command (single file), they are
+typically in the user-misc package.  Otherwise, they are a a set of
+files grouped together which add a specific functionality to the code.
+
          
+
          User packages don't necessarily meet the requirements of the standard
+packages.  If you have problems using a feature provided in a user
+package, you will likely need to contact the contributor directly to
+get help.  Information on how to submit additions you make to LAMMPS
+as a user-contributed package is given in this
+section of the documentation.
 
          
 
          
 
-Including/excluding packages: 
+Including/excluding packages: 
 
-
          Any or all packages can be included or excluded independently BEFORE
-LAMMPS is built.
+
          To use or not use a package you must include or exclude it before
+building LAMMPS.  From the src directory, this is typically as simple
+as:
 
          
-
          The two exceptions to this are the "gpu" and "opt" packages.  Some of
-the files in these packages require other packages to also be
-included.  If this is not the case, then those subsidiary files in
-"gpu" and "opt" will not be installed either.  To install all the
-files in package "gpu", the "asphere" and "kspace" packages must also be 
-installed. To install all the files in package "opt", the "kspace" and 
-"manybody" packages must also be installed.
+
          make yes-colloid
+make g++ 
+
          
+
          or
 
          
-
          You may wish to exclude certain packages if you will never run certain
-kinds of simulations.  This will keep you from having to build
-auxiliary libraries (see below) and will produce a smaller executable
-which may run a bit faster.
+
          make no-manybody
+make g++ 
+
          
+
          Some packages have individual files that depend on other packages
+being included.  LAMMPS checks for this and does the right thing.
+I.e. individual files are only included if their dependencies are
+already included.  Likewise, if a package is excluded, other files
+dependent on that package are also excluded.
 
          
-
          By default, LAMMPS includes only the "kspace", "manybody", and
-"molecule" packages.
+
          The reason to exclude packages is if you will never run certain kinds
+of simulations.  For some packages, this will keep you from having to
+build auxiliary libraries (see below), and will also produce a smaller
+executable which may run a bit faster.
+
          
+
          When you download a LAMMPS tarball, these packages are pre-installed
+in the src directory: KSPACE, MANYBODY,MOLECULE.  When you download
+LAMMPS source files from the SVN or Git repositories, no packages are
+pre-installed.
 
          
 
          Packages are included or excluded by typing "make yes-name" or "make
-no-name", where "name" is the name of the package.  You can also type
-"make yes-standard", "make no-standard", "make yes-user", "make
-no-user", "make yes-all" or "make no-all" to include/exclude various
-sets of packages.  Type "make package" to see the various options.
+no-name", where "name" is the name of the package in lower-case, e.g.
+name = kspace for the KSPACE package or name = user-atc for the
+USER-ATC package.  You can also type "make yes-standard", "make
+no-standard", "make yes-user", "make no-user", "make yes-all" or "make
+no-all" to include/exclude various sets of packages.  Type "make
+package" to see the all of the package-related make options.
 
          
-
          IMPORTANT NOTE: These make commands work by simply moving files back
-and forth between the main src directory and sub-directories with the
-package name, so that the files are seen or not seen when LAMMPS is
-built.  After you have included or excluded a package, you must
-re-build LAMMPS.
+
          IMPORTANT NOTE: Inclusion/exclusion of a package works by simply
+moving files back and forth between the main src directory and
+sub-directories with the package name (e.g. src/KSPACE, src/USER-ATC),
+so that the files are seen or not seen when LAMMPS is built.  After
+you have included or excluded a package, you must re-build LAMMPS.
 
          
-
          Additional make options exist to help manage LAMMPS files that exist
-in both the src directory and in package sub-directories.  You do not
-normally need to use these commands unless you are editing LAMMPS
-files or have downloaded a patch from the LAMMPS WWW site.
+
          Additional package-related make options exist to help manage LAMMPS
+files that exist in both the src directory and in package
+sub-directories.  You do not normally need to use these commands
+unless you are editing LAMMPS files or have downloaded a patch from
+the LAMMPS WWW site.
 
          
 
          Typing "make package-update" will overwrite src files with files from
-the package directories if the package has been included.  It should
-be used after a patch is installed, since patches only update the
-master package version of a file.  Typing "make package-overwrite"
-will overwrite files in the package directories with src files.
-Typing "make package-check" will list differences between src and
-package versions of the same files.  Again, type "make package" to see
-the various options.
+the package sub-directories if the package has been included.  It
+should be used after a patch is installed, since patches only update
+the files in the package sub-directory, but not the src files.  Typing
+"make package-overwrite" will overwrite files in the package
+sub-directories with src files.
+
          
+
          Typing "make package-status" will show which packages are currently
+included. Of those that are included, it will list files that are
+different in the src directory and package sub-directory.  Typing
+"make package-diff" lists all differences between these files.  Again,
+type "make package" to see all of the package-related make options.
 
          
 
          
 
-Packages that require extra LAMMPS libraries: 
+Packages that require extra libraries: 
 
-
          A few packages (standard or user) require that additional libraries be
-compiled first, which LAMMPS will link to when it builds.  The source
-code for these libraries are included in the LAMMPS distribution under
-the "lib" directory.  Look at the README files in the lib directories
-(e.g. lib/reax/README) for instructions on how to build each library.
+
          A few of the standard and user packages require additional auxiliary
+libraries to be compiled first.  If you get a LAMMPS build error about
+a missing library, this is likely the reason.  The source code for
+these libraries is included in the LAMMPS distribution under the "lib"
+directory.  Look at the lib/README file for a list of these or see
+this section of the doc pages.
 
          
-
          IMPORTANT NOTE: If you are including a package in your LAMMPS build
-that uses one of these libraries, then you must build the library
-BEFORE building LAMMPS itself, since the LAMMPS build will attempt to
-link with the library file.
-
          
-
          Here is a bit of information about each library:
-
          
-
          The "atc" library in lib/atc is used by the user-atc package.  It
-provides continuum field estimation and molecular dynamics-finite
-element coupling methods.  It was written primarily by Reese Jones,
-Jeremy Templeton and Jonathan Zimmerman at Sandia.
-
          
-
          The "gpu" library in lib/gpu is used by the gpu package.  It
-contains code to enable portions of LAMMPS to run on a GPU chip
-associated with your CPU.  Currently, only NVIDIA GPUs are supported.
-Building this library requires NVIDIA Cuda tools to be installed on
-your system.  See the Running on GPUs section below for more
-info about installing and using Cuda.
-
          
-
          The "meam" library in lib/meam is used by the meam package.
-computes the modified embedded atom method potential, which is a
-generalization of EAM potentials that can be used to model a wider
-variety of materials.  This MEAM implementation was written by Greg
-Wagner at Sandia.  It requires a F90 compiler to build.  The C++ to
-FORTRAN function calls in pair_meam.cpp assumes that FORTRAN object
-names are converted to C object names by appending an underscore
-character. This is generally the case, but on machines that do not
-conform to this convention, you will need to modify either the C++
-code or your compiler settings.
-
          
-
          The "poems" library in lib/poems is used by the poems package.
-computes the constrained rigid-body motion of articulated (jointed)
-multibody systems.  POEMS was written and is distributed by Prof Kurt
-Anderson's group at Rensselaer Polytechnic Institute (RPI).
-
          
-
          The "reax" library in lib/reax is used by the reax package.  It
-computes the Reactive Force Field (ReaxFF) potential, developed by
-Adri van Duin in Bill Goddard's group at CalTech.  This implementation
-in LAMMPS uses many of Adri's files and was developed by Aidan
-Thompson at Sandia and Hansohl Cho at MIT.  It requires a F77 or F90
-compiler to build.  The C++ to FORTRAN function calls in pair_reax.cpp
-assume that FORTRAN object names are converted to C object names by
-appending an underscore character. This is generally the case, but on
-machines that do not conform to this convention, you will need to
-modify either the C++ code or your compiler settings. The name
-conversion is handled by the preprocessor macro called FORTRAN in
-pair_reax_fortran.h.  Different definitions of this macro can be
-obtained by adding a machine-specific macro definition to the CCFLAGS
-variable in your Makefile e.g. -D_IBM. See pair_reax_fortran.h for
-more info.
-
          
-
          As described in its README file, each library is built by typing
-something like
+
          Each lib directory has a README file (e.g. lib/reax/README) with
+instructions on how to build that library.  Typically this is done 
+in this manner:
 
          
 
          make -f Makefile.g++ 
 
          
-
          in the appropriate directory, e.g. in lib/reax.
+
          in the appropriate directory, e.g. in lib/reax.  Some of the libraries
+do not build this way.  Again, see the libary README file for details.
 
          
-
          You must use a Makefile that is a match for your system.  If one of
-the provided Makefiles is not appropriate for your system you will
-need to edit or add one.  For example, in the case of Fotran-based
-libraries, your system must have a Fortran compiler, the settings for
-which will be in the Makefile.
+
          In any event, you will need to use a Makefile that is a match for your
+system.  If one of the provided Makefiles is not appropriate for your
+system you will need to edit or add one.  For example, in the case of
+Fortran-based libraries, your system must have a Fortran compiler, the
+settings for which will need to be listed in the Makefile.
+
          
+
          When you have built one of these libraries, there are 2 things to
+check:
+
          
+
          (1) The file libname.a should now exist in lib/name.
+E.g. lib/reax/libreax.a.  This is the library file LAMMPS will link
+against.  One exception is the lib/cuda library which produces the
+file liblammpscuda.a, because there is already a system library
+libcuda.a.
+
          
+
          (2) The file Makefile.lammps should exist in lib/name.  E.g.
+lib/cuda/Makefile.lammps.  This file may be auto-generated by the
+build of the library, or you may need to make a copy of the
+appropriate provided file (e.g. lib/meam/Makefile.lammps.gfortran).
+Either way you should insure that the settings in this file are
+appropriate for your system.
+
          
+
          There are typically 3 settings in the Makefile.lammps file (unless
+some are blank or not needed): a SYSINC, SYSPATH, and SYSLIB setting,
+specific to this package.  These are settings the LAMMPS build will
+import when compiling the LAMMPS package files (not the library
+files), and linking to the auxiliary library.  They typically list any
+other system libraries needed to support the package and where to find
+them.  An example is the BLAS and LAPACK libraries needed by the
+USER-ATC package.  Or the system libraries that support calling
+Fortran from C++, as the MEAM and REAX packages do.
+
          
+
          Note that if these settings are not correct for your box, the LAMMPS
+build will likely fail.
 
          
 
          
 
-Additional Makefile settings for extra libraries: 
-
-
          After the desired library or libraries are built, and the package has
-been included, you can build LAMMPS itself.  For example, from the
-lammps/src directory you would type this, to build LAMMPS with ReaxFF.
-Note that as discussed in the preceding section, the package library
-itself, namely lib/reax/libreax.a, must already have been built, for
-the LAMMPS build to be successful.
-
          
-
          make yes-reax
-make g++ 
-
          
-
          Also note that simply building the library is not sufficient to use it
-from LAMMPS.  As in this example, you must also include the package
-that uses and wraps the library before you build LAMMPS itself.
-
          
-
          As discussed in point (2.4) of this section above, there are
-settings in the low-level Makefile that specify additional system
-libraries needed by individual LAMMPS add-on libraries.  These are the
-settings you must specify correctly in your low-level Makefile in
-lammps/src/MAKE, such as Makefile.foo:
-
          
-
          To use the gpu package and library, the settings for gpu_SYSLIB and
-gpu_SYSPATH must be correct.  These are specific to the NVIDIA CUDA
-software which must be installed on your system.
-
          
-
          To use the meam or reax packages and their libraries which are Fortran
-based, the settings for meam_SYSLIB, reax_SYSLIB, meam_SYSPATH, and
-reax_SYSPATH must be correct.  This is so that the C++ compiler can
-perform a cross-language link using the appropriate system Fortran
-libraries.
-
          
-
          To use the user-atc package and library, the settings for
-user-atc_SYSLIB and user-atc_SYSPATH must be correct.  This is so that
-the appropriate BLAS and LAPACK libs, used by the user-atc library,
-can be found.
-
          
-
          
-
-
          2.4 Building LAMMPS as a library 
+
          2.4 Building LAMMPS as a library 
 
          
-
          LAMMPS can be built as a library, which can then be called from
-another application or a scripting language.  See this
-section for more info on coupling LAMMPS to
-other codes.  Building LAMMPS as a library is done by typing
+
          LAMMPS itself can be built as a library, which can then be called from
+another application or a scripting language.  See this
+section for more info on coupling LAMMPS
+to other codes.  Building LAMMPS as a library is done by typing
 
          
 
          make makelib
 make -f Makefile.lib foo 
 
          
-
          where foo is the machine name.  The first "make" command will create a
-current Makefile.lib with all the file names in your src dir.  The 2nd
-"make" command will use it to build LAMMPS as a library.  This
-requires that Makefile.foo have a library target (lib) and
-system-specific settings for ARCHIVE and ARFLAGS.  See Makefile.linux
-for an example.  The build will create the file liblmp_foo.a which
-another application can link to.
+
          where foo is the machine name.  Note that inclusion or exclusion of
+any desired optional packages should be done before typing "make
+makelib".  The first "make" command will create a current Makefile.lib
+with all the file names in your src dir.  The 2nd "make" command will
+use it to build LAMMPS as a library.  This requires that Makefile.foo
+have a library target (lib) and system-specific settings for ARCHIVE
+and ARFLAGS.  See Makefile.linux for an example.  The build will
+create the file liblmp_foo.a which another application can link to.
 
          
 
          When used from a C++ program, the library allows one or more LAMMPS
 objects to be instantiated.  All of LAMMPS is wrapped in a LAMMPS_NS
@@ -625,19 +717,19 @@ src/library.cpp and src/library.h.
 
          See the sample codes couple/simple/simple.cpp and simple.c as examples
 of C++ and C codes that invoke LAMMPS thru its library interface.
 There are other examples as well in the couple directory which are
-discussed in this section of the manual.
+discussed in this section of the manual.
 See this section of the manual for a description
 of the Python wrapper provided with LAMMPS that operates through the
 LAMMPS library interface.
 
          
 
          The files src/library.cpp and library.h contain the C-style interface
-to LAMMPS.  See this section of the manual
-for a description of the interface and how to extend it for your
-needs.
+to LAMMPS.  See this section of the
+manual for a description of the interface and how to extend it for
+your needs.
 
          
 
          
 
-
          2.5 Running LAMMPS 
+
          2.5 Running LAMMPS 
 
          
 
          By default, LAMMPS runs by reading commands from stdin; e.g. lmp_linux
 < in.file.  This means you first create an input script (e.g. in.file)
@@ -666,16 +758,14 @@ on various platforms.
 
 
          
 
-
          On a Windows machine, you can skip making LAMMPS and simply download
-an executable. But note that not all packages are available.
-The following packages are available: asphere, class2, colloid, dipole,
-dsmc, granular, kspace, manybody, molecule, peri, poems, replica, shock,
-user-ackland, user-cd-eam, user-cg-cmm, user-ewaldn, user-smd. But these 
-packages are not available: gpu, meam, opt, reax, xtc, user-atc, user-imd.
+
          On a Windows box, you can skip making LAMMPS and simply download an
+executable, as described above, though the pre-packaged executables
+include only certain packages.
 
          
-
          To run the LAMMPS executable on a Windows machine, first decide whether 
-you want to download the non-MPI (serial) or the MPI (parallel) version 
-of the executable. Download and save the version you have chosen.
+
          To run a LAMMPS executable on a Windows machine, first decide whether
+you want to download the non-MPI (serial) or the MPI (parallel)
+version of the executable. Download and save the version you have
+chosen.
 
          
 
          For the non-MPI version, follow these steps:
 
          
@@ -749,25 +839,43 @@ more processors or setup a smaller problem.
 
          
 
          
 
-
          2.6 Command-line options 
+
          2.6 Command-line options 
 
          
 
          At run time, LAMMPS recognizes several optional command-line switches
-which may be used in any order.  Either the full word or the
-one-letter abbreviation can be used:
+which may be used in any order.  Either the full word or a one-or-two
+letter abbreviation can be used:
 
          
-
          • -echo or -e
-
          • -partition or -p
-
          • -in or -i
-
          • -log or -l
-
          • -screen or -s
-
          • -var or -v 
+
            • -c or -cuda
+
            • -e or -echo
+
            • -i or -in
+
            • -h or -help
+
            • -l or -log
+
            • -p or -partition
+
            • -pl or -plog
+
            • -ps or -pscreen
+
            • -sc or -screen
+
            • -sf or -suffix
+
            • -v or -var 
 
            
 
            For example, lmp_ibm might be launched as follows:
 
            
-
            mpirun -np 16 lmp_ibm -var f tmp.out -log my.log -screen none < in.alloy 
+
            mpirun -np 16 lmp_ibm -v f tmp.out -l my.log -sc none < in.alloy
+mpirun -np 16 lmp_ibm -var f tmp.out -log my.log -screen none < in.alloy 
 
            
 
            Here are the details on the options:
 
            
+
            -cuda on/off 
+
            
+
            Explicitly enable or disable CUDA support, as provided by the
+USER-CUDA package.  If LAMMPS is built with this package, as described
+above in Section 2.3, then by default LAMMPS will run in
+CUDA mode.  If this switch is set to "off", then it will not, even if
+it was built with the USER-CUDA package, which means you can run
+standard LAMMPS or with the GPU package for testing or benchmarking
+purposes.  The only reason to set the switch to "on", is to check if
+LAMMPS was built with the USER-CUDA package, since an error will be
+generated if it was not.
+
            
 
            -echo style 
 
            
 
            Set the style of command echoing.  The style can be none or screen
@@ -777,6 +885,37 @@ can be useful to figure out which line of your script is causing an
 input error.  The default value is log.  The echo style can also be
 set by using the echo command in the input script itself.
 
            
+
            -in file 
+
            
+
            Specify a file to use as an input script.  This is an optional switch
+when running LAMMPS in one-partition mode.  If it is not specified,
+LAMMPS reads its input script from stdin - e.g. lmp_linux < in.run.
+This is a required switch when running LAMMPS in multi-partition mode,
+since multiple processors cannot all read from stdin.
+
            
+
            -help 
+
            
+
            Print a list of options compiled into this executable for each LAMMPS
+style (atom_style, fix, compute, pair_style, bond_style, etc).  This
+can help you know if the command you want to use was included via the
+appropriate package.  LAMMPS will print the info and immediately exit
+if this switch is used.
+
            
+
            -log file 
+
            
+
            Specify a log file for LAMMPS to write status information to.  In
+one-partition mode, if the switch is not used, LAMMPS writes to the
+file log.lammps.  If this switch is used, LAMMPS writes to the
+specified file.  In multi-partition mode, if the switch is not used, a
+log.lammps file is created with hi-level status information.  Each
+partition also writes to a log.lammps.N file where N is the partition
+ID.  If the switch is specified in multi-partition mode, the hi-level
+logfile is named "file" and each partition also logs information to a
+file.N.  For both one-partition and multi-partition mode, if the
+specified file is "none", then no log files are created.  Using a
+log command in the input script will override this setting.
+Option -plog will override the name of the partition log files file.N.
+
            
 
            -partition 8x2 4 5 ... 
 
            
 
            Invoke LAMMPS in multi-partition mode.  When LAMMPS is run on P
@@ -791,39 +930,40 @@ processors in all partitions must equal P.  Thus the command
 "-partition 8x2 4 5" has 10 partitions and runs on a total of 25
 processors.
 
            
-
            Note that with MPI installed on a machine (e.g. your desktop), you can
-run on more (virtual) processors than you have physical processors.
-This can be useful for running multi-replica
-simulations, on one or a few processors.
+
            Running with multiple partitions can e useful for running
+multi-replica simulations, where each
+replica runs on on one or a few processors.  Note that with MPI
+installed on a machine (e.g. your desktop), you can run on more
+(virtual) processors than you have physical processors.
 
            
-
            The input script specifies what simulation is run on which partition;
-see the variable and next commands.  This
-howto section gives examples of how to use
-these commands in this way.  Simulations running on different
-partitions can also communicate with each other; see the
-temper command.
+
            To run multiple independent simulatoins from one input script, using
+multiple partitions, see this section of
+the manual.  World- and universe-style variables are
+useful in this context.
 
            
-
            -in file 
+
            -plog file 
 
            
-
            Specify a file to use as an input script.  This is an optional switch
-when running LAMMPS in one-partition mode.  If it is not specified,
-LAMMPS reads its input script from stdin - e.g. lmp_linux < in.run.
-This is a required switch when running LAMMPS in multi-partition mode,
-since multiple processors cannot all read from stdin.
+
            Specify the base name for the partition log files, so partition N
+writes log information to file.N. If file is none, then no partition
+log files are created.  This overrides the filename specified in the
+-log command-line option.  This option is useful when working with
+large numbers of partitions, allowing the partition log files to be
+suppressed (-plog none) or placed in a sub-directory (-plog
+replica_files/log.lammps) If this option is not used the log file for
+partition N is log.lammps.N or whatever is specified by the -log
+command-line option.
 
            
-
            -log file 
+
            -pscreen file 
 
            
-
            Specify a log file for LAMMPS to write status information to.  In
-one-partition mode, if the switch is not used, LAMMPS writes to the
-file log.lammps.  If this switch is used, LAMMPS writes to the
-specified file.  In multi-partition mode, if the switch is not used, a
-log.lammps file is created with hi-level status information.  Each
-partition also writes to a log.lammps.N file where N is the partition
-ID.  If the switch is specified in multi-partition mode, the hi-level
-logfile is named "file" and each partition also logs information to a
-file.N.  For both one-partition and multi-partition mode, if the
-specified file is "none", then no log files are created.  Using a
-log command in the input script will override this setting.
+
            Specify the base name for the partition screen file, so partition N
+writes screen information to file.N. If file is none, then no
+partition screen files are created.  This overrides the filename
+specified in the -screen command-line option.  This option is useful
+when working with large numbers of partitions, allowing the partition
+screen files to be suppressed (-pscreen none) or placed in a
+sub-directory (-pscreen replica_files/screen) If this option is not
+used the screen file for partition N is screen.N or whatever is
+specified by the -screen command-line option.
 
            
 
            -screen file 
 
            
@@ -837,7 +977,42 @@ the partition ID.  If the switch is specified in multi-partition mode,
 the hi-level screen dump is named "file" and each partition also
 writes screen information to a file.N.  For both one-partition and
 multi-partition mode, if the specified file is "none", then no screen
-output is performed.
+output is performed. Option -pscreen will override the name of the
+partition screen files file.N.
+
            
+
            -suffix style 
+
            
+
            Use variants of various styles if they exist.  The specified style can
+be opt, omp, gpu, or cuda.  These refer to optional packages that
+LAMMPS can be built with, as described above in Section
+2.3.  The "opt" style corrsponds to the OPT package, the
+"omp" style to the USER-OMP package, the "gpu" style to the GPU 
+package, and the "cuda" style to the USER-CUDA package.
+
            
+
            As an example, all of the packages provide a pair_style
+lj/cut variant, with style names lj/cut/opt, lj/cut/omp,
+lj/cut/gpu, or lj/cut/cuda.  A variant styles can be specified
+explicitly in your input script, e.g. pair_style lj/cut/gpu.  If the
+-suffix switch is used, you do not need to modify your input script.
+The specified suffix (opt,omp,gpu,cuda) is automatically appended
+whenever your input script command creates a new
+atom, pair, fix,
+compute, or run style.  If the variant
+version does not exist, the standard version is created.
+
            
+
            For the GPU package, using this command-line switch also invokes the
+default GPU settings, as if the command "package gpu force/neigh 0 0
+1" were used at the top of your input script.  These settings can be
+changed by using the package gpu command in your script
+if desired.
+
            
+
            For the OMP package, using this command-line switch also invokes the
+default OMP settings, as if the command "package omp *" were used at
+the top of your input script.  These settings can be changed by using
+the package omp command in your script if desired.
+
            
+
            The suffix command can also set a suffix and it can also
+turn off/on any suffix setting made via the command line.
 
            
 
            -var name value1 value2 ... 
 
            
@@ -852,13 +1027,19 @@ value2 ..."  at the beginning of the input script.  Defining an index
 variable as a command-line argument overrides any setting for the same
 index variable in the input script, since index variables cannot be
 re-defined.  See the variable command for more info on
-defining index and other kinds of variables and this
-section for more info on using variables in
-input scripts.
+defining index and other kinds of variables and this
+section for more info on using variables
+in input scripts.
+
            
+
            NOTE: Currently, the command-line parser looks for arguments that
+start with "-" to indicate new switches.  Thus you cannot specify
+multiple variable values if any of they start with a "-", e.g. a
+negative numeric value.  It is OK if the first value1 starts with a
+"-", since it is automatically skipped.
 
            
 
            
 
-
            2.7 LAMMPS screen output 
+
            2.7 LAMMPS screen output 
 
            
 
            As LAMMPS reads an input script, it prints information to both the
 screen and a log file about significant actions it takes to setup a
@@ -955,154 +1136,7 @@ communication, roughly 75% in the example above.
 
            
 
            
 
-
            2.8 Running on GPUs 
-
            
-
            A few LAMMPS pair styles can be run on graphical
-processing units (GPUs).  We plan to add more over time.  Currently,
-they only support NVIDIA GPU cards.  To use them you need to install
-certain NVIDIA CUDA software on your system:
-
            
-
            • Check if you have an NVIDIA card: cat /proc/driver/nvidia/cards/0
-
            • Go to http://www.nvidia.com/object/cuda_get.html
-
            • Install a driver and toolkit appropriate for your system (SDK is not necessary)
-
            • Follow the instructions in README in lammps/lib/gpu to build the library.
-
            • Run lammps/lib/gpu/nvc_get_devices to list supported devices and properties 
-
            
-
            GPU configuration 
-
            
-
            When using GPUs, you are restricted to one physical GPU per LAMMPS
-process. Multiple processes can share a single GPU and in many cases it
-will be more efficient to run with multiple processes per GPU. Any GPU
-accelerated style requires that fix gpu be used in the
-input script to select and initialize the GPUs. The format for the fix
-is:
-
            
-
            fix name all gpu mode first last split 
-
            
-
            where name is the name for the fix. The gpu fix must be the first
-fix specified for a given run, otherwise the program will exit
-with an error. The gpu fix will not have any effect on runs 
-that do not use GPU acceleration; there should be no problem
-with specifying the fix first in any input script.
-
            
-
            mode can be either "force" or "force/neigh". In the former,
-neighbor list calculation is performed on the CPU using the
-standard LAMMPS routines. In the latter, the neighbor list
-calculation is performed on the GPU. The GPU neighbor list
-can be used for better performance, however, it 
-should not be used with a triclinic box.
-
            
-
            There are cases when it might be more efficient to select the CPU for neighbor
-list builds. If a non-GPU enabled style requires a neighbor list, it will also
-be built using CPU routines. Redundant CPU and GPU neighbor list calculations
-will typically be less efficient. For hybrid pair
-styles, GPU calculated neighbor lists might be less efficient because
-no particles will be skipped in a given neighbor list.
-
            
-
            first is the ID (as reported by lammps/lib/gpu/nvc_get_devices)
-of the first GPU that will be used on each node. last is the
-ID of the last GPU that will be used on each node. If you have
-only one GPU per node, first and last will typically both be
-0. Selecting a non-sequential set of GPU IDs (e.g. 0,1,3)
-is not currently supported.
-
            
-
            split is the fraction of particles whose forces, torques,
-energies, and/or virials will be calculated on the GPU. This
-can be used to perform CPU and GPU force calculations
-simultaneously. If split is negative, the software will
-attempt to calculate the optimal fraction automatically 
-every 25 timesteps based on CPU and GPU timings. Because the GPU speedups
-are dependent on the number of particles, automatic calculation of the
-split can be less efficient, but typically results in loop times
-within 20% of an optimal fixed split.
-
            
-
            If you have two GPUs per node, 8 CPU cores per node, and
-would like to run on 4 nodes with dynamic balancing of
-force calculation across CPU and GPU cores, the fix
-might be
-
            
-
            fix 0 all gpu force/neigh 0 1 -1 
-
            
-
            with LAMMPS run on 32 processes. In this case, all
-CPU cores and GPU devices on the nodes would be utilized.
-Each GPU device would be shared by 4 CPU cores. The
-CPU cores would perform force calculations for some
-fraction of the particles at the same time the GPUs
-performed force calculation for the other particles.
-
            
-
            Because of the large number of cores on each GPU
-device, it might be more efficient to run on fewer
-processes per GPU when the number of particles per process
-is small (100's of particles); this can be necessary
-to keep the GPU cores busy.
-
            
-
            GPU input script 
-
            
-
            In order to use GPU acceleration in LAMMPS, 
-fix_gpu
-should be used in order to initialize and configure the
-GPUs for use. Additionally, GPU enabled styles must be
-selected in the input script. Currently,
-this is limited to a few pair styles.
-Some GPU-enabled styles have additional restrictions
-listed in their documentation.
-
            
-
            GPU asynchronous pair computation 
-
            
-
            The GPU accelerated pair styles can be used to perform
-pair style force calculation on the GPU while other 
-calculations are
-performed on the CPU. One method to do this is to specify
-a split in the gpu fix as described above. In this case,
-force calculation for the pair style will also be performed
-on the CPU. 
-
            
-
            When the CPU work in a GPU pair style has finished,
-the next force computation will begin, possibly before the
-GPU has finished. If split is 1.0 in the gpu fix, the next
-force computation will begin almost immediately. This can
-be used to run a hybrid GPU pair style at 
-the same time as a hybrid CPU pair style. In this case, the 
-GPU pair style should be first in the hybrid command in order to
-perform simultaneous calculations. This also
-allows bond, angle, 
-dihedral, improper, 
-and long-range force
-computations to be run simultaneously with the GPU pair style.
-Once all CPU force computations have completed, the gpu fix
-will block until the GPU has finished all work before continuing
-the run.
-
            
-
            GPU timing 
-
            
-
            GPU accelerated pair styles can perform computations asynchronously
-with CPU computations. The "Pair" time reported by LAMMPS
-will be the maximum of the time required to complete the CPU
-pair style computations and the time required to complete the GPU
-pair style computations. Any time spent for GPU-enabled pair styles
-for computations that run simultaneously with bond, 
-angle, dihedral, 
-improper, and long-range calculations
-will not be included in the "Pair" time.
-
            
-
            When mode for the gpu fix is force/neigh,
-the time for neighbor list calculations on the GPU will be added
-into the "Pair" time, not the "Neigh" time. A breakdown of the
-times required for various tasks on the GPU (data copy, neighbor
-calculations, force computations, etc.) are output only
-with the LAMMPS screen output at the end of each run. These timings represent
-total time spent on the GPU for each routine, regardless of asynchronous
-CPU calculations.
-
            
-
            GPU single vs double precision 
-
            
-
            See the lammps/lib/gpu/README file for instructions on how to build 
-the LAMMPS gpu library for single, mixed, and double precision.  The latter
-requires that your GPU card supports double precision. 
-
            
-
            
-
-
            2.9 Tips for users of previous LAMMPS versions 
+
            2.8 Tips for users of previous LAMMPS versions 
 
            
 
            The current C++ began with a complete rewrite of LAMMPS 2001, which
 was written in F90.  Features of earlier versions of LAMMPS are listed
diff --git a/doc/Section_start.txt b/doc/Section_start.txt
index 10a5a3ba84..c6c82e1eba 100644
--- a/doc/Section_start.txt
+++ b/doc/Section_start.txt
@@ -11,19 +11,19 @@
 This section describes how to build and run LAMMPS, for both new and
 experienced users.
 
-2.1 "What's in the LAMMPS distribution"_#2_1
-2.2 "Making LAMMPS"_#2_2
-2.3 "Making LAMMPS with optional packages"_#2_3
-2.4 "Building LAMMPS as a library"_#2_4
-2.5 "Running LAMMPS"_#2_5
-2.6 "Command-line options"_#2_6
-2.7 "Screen output"_#2_7
-2.8 "Running on GPUs"_#2_8
-2.9 "Tips for users of previous versions"_#2_9 :all(b)
+2.1 "What's in the LAMMPS distribution"_#start_1
+2.2 "Making LAMMPS"_#start_2
+2.3 "Making LAMMPS with optional packages"_#start_3
+2.4 "Building LAMMPS as a library"_#start_4
+2.5 "Running LAMMPS"_#start_5
+2.6 "Command-line options"_#start_6
+2.7 "Screen output"_#start_7
+2.8 "Tips for users of previous versions"_#start_8 :all(b)
 
+:line
 :line
 
-2.1 What's in the LAMMPS distribution :h4,link(2_1)
+2.1 What's in the LAMMPS distribution :h4,link(start_1)
 
 When you download LAMMPS you will need to unzip and untar the
 downloaded file with the following commands, after placing the file in
@@ -45,46 +45,51 @@ potentials: embedded atom method (EAM) potential files
 src: source files
 tools: pre- and post-processing tools :tb(s=:)
 
-If you download the Windows executable from the download page,
+If you download one of the Windows executables from the download page,
 then you just get a single file:
 
 lmp_windows.exe :pre
 
-Skip to the "Running LAMMPS"_#2_5 section, to learn how to launch this
-executable on a Windows box.
+Skip to the "Running LAMMPS"_#start_5 sections for info on how to
+launch these executables on a Windows box.
 
-The Windows executable also only includes certain packages and
-bug-fixes/upgrades listed on "this
+The Windows executables for serial or parallel only include certain
+packages and bug-fixes/upgrades listed on "this
 page"_http://lammps.sandia.gov/bug.html up to a certain date, as
 stated on the download page.  If you want something with more packages
 or that is more current, you'll have to download the source tarball
-and build it yourself, as described in the next section.
+and build it yourself from source code using Microsoft Visual Studio,
+as described in the next section.
 
 :line
 
-2.2 Making LAMMPS :h4,link(2_2)
+2.2 Making LAMMPS :h4,link(start_2)
 
 This section has the following sub-sections:
 
-"Read this first"_#2_2_1
-"Building a LAMMPS executable"_#2_2_2
-"Common errors that can occur when making LAMMPS"_#2_2_3
-"Editing a new low-level Makefile"_#2_2_4
-"Additional build tips"_#2_2_5 :ul
+"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
 
 :line
 
-[{Read this first:}] :link(2_2_1)
+[{Read this first:}] :link(start_2_1)
 
-Building LAMMPS can be non-trivial.  You will likely need to edit a
-makefile, there are compiler options, additional libraries can be used
-(MPI, FFT), etc.  Please read this section carefully.  If you are not
-comfortable with makefiles, or building codes on a Unix platform, or
-running an MPI job on your machine, please find a local expert to help
-you.  Many compiling, linking, and run problems that users are not
-really LAMMPS issues - they are peculiar to the user's system,
-compilers, libraries, etc.  Such questions are better answered by a
-local expert.
+Building LAMMPS can be non-trivial.  You may need to edit a makefile,
+there are compiler options to consider, additional libraries can be
+used (MPI, FFT, JPEG), LAMMPS packages may be included or excluded,
+some of these packages use auxiliary libraries which need to be
+pre-built, etc.
+
+Please read this section carefully.  If you are not comfortable with
+makefiles, or building codes on a Unix platform, or running an MPI job
+on your machine, please find a local expert to help you.  Many
+compiling, linking, and run problems that users have are not really
+LAMMPS issues - they are peculiar to the user's system, compilers,
+libraries, etc.  Such questions are better answered by a local expert.
 
 If you have a build problem that you are convinced is a LAMMPS issue
 (e.g. the compiler complains about a line of LAMMPS source code), then
@@ -97,16 +102,19 @@ to the developers and we'll include it in future LAMMPS releases.
 
 :line
 
-[{Building a LAMMPS executable:}] :link(2_2_2)
+[{Steps to build a LAMMPS executable:}] :link(start_2_2)
+
+[Step 0]
 
 The src directory contains the C++ source and header files for LAMMPS.
 It also contains a top-level Makefile and a MAKE sub-directory with
-low-level Makefile.* files for several machines.  From within the src
+low-level Makefile.* files for many machines.  From within the src
 directory, type "make" or "gmake".  You should see a list of available
 choices.  If one of those is the machine and options you want, you can
 type a command like:
 
 make linux
+or
 gmake mac :pre
 
 Note that on a multi-processor or multi-core platform you can launch a
@@ -116,63 +124,34 @@ will build LAMMPS more quickly.
 If you get no errors and an executable like lmp_linux or lmp_mac is
 produced, you're done; it's your lucky day.
 
-:line
+Note that by default only a few of LAMMPS optional pacakges are
+installed.  To build LAMMPS with optional packages, see "this
+section"_#start_3 below.
 
-[{Common errors that can occur when making LAMMPS:}] :link(2_2_3)
+[Step 1]
 
-(1) If the make command breaks immediately with errors that indicate
-it can't find files with a "*" in their names, this can be because
-your machine's make doesn't support wildcard expansion in a makefile.
-Try gmake instead of make.  If that doesn't work, try using a -f
-switch with your make command to use Makefile.list which explicitly
-lists all the needed files, e.g.
+If Step 0 did not work, you will need to create a low-level Makefile
+for your machine, like Makefile.foo.  You should make a copy of an
+existing src/MAKE/Makefile.* as a starting point.  The only portions
+of the file you need to edit are the first line, the "compiler/linker
+settings" section, and the "LAMMPS-specific settings" section.
 
-make makelist
-make -f Makefile.list linux
-gmake -f Makefile.list mac :pre
+[Step 2]
 
-The first "make" command will create a current Makefile.list with all
-the file names in your src dir.  The 2nd "make" command (make or
-gmake) will use it to build LAMMPS.
+Change the first line of src/MAKE/Makefile.foo to list the word "foo"
+after the "#", and whatever other options it will set.  This is the
+line you will see if you just type "make".
 
-(2) Other errors typically occur because the low-level Makefile isn't
-setup correctly for your machine.  If your platform is named "foo",
-you will need to create a Makefile.foo in the MAKE sub-directory.  Use
-whatever existing file is closest to your platform as a starting
-point.  See the next section for more instructions.
+[Step 3]
 
-(3) If you get a link-time error about missing libraries or missing
-dependencies, then it can be because:
-
-you are including a package that needs an extra library, but have not pre-built the necessary "package library"_#2_3_3
-you are linking to a library that doesn't exist on your system
-you are not linking to the necessary system library :ul
-
-The first issue is discussed below.  The other two issue mean you need
-to edit your low-level Makefile.foo, as discussed in the next
-sub-section.
-
-:line
-
-[{Editing a new low-level Makefile.foo:}] :link(2_2_4)
-
-These are the issues you need to address when editing a low-level
-Makefile for your machine.  The portions of the file you typically
-need to edit are the first line, the "compiler/linker settings"
-section, and the "system-specific settings" section.
-
-(1) Change the first line of Makefile.foo to list the word "foo" after
-the "#", and whatever other options you set.  This is the line you
-will see if you just type "make".
-
-(3) The "compiler/linker settings" section lists compiler and linker
+The "compiler/linker settings" section lists compiler and linker
 settings for your C++ compiler, including optimization flags.  You can
 use g++, the open-source GNU compiler, which is available on all Unix
 systems.  You can also use mpicc which will typically be available if
 MPI is installed on your system, though you should check which actual
 compiler it wraps.  Vendor compilers often produce faster code.  On
-boxes with Intel CPUs, we suggest using the free Intel icc compiler,
-which you can download from "Intel's compiler site"_intel.
+boxes with Intel CPUs, we suggest using the commercial Intel icc
+compiler, which can be downloaded from "Intel's compiler site"_intel.
 
 :link(intel,http://www.intel.com/software/products/noncom)
 
@@ -184,111 +163,257 @@ dependency list for a source file.  This speeds re-compilation when
 source (*.cpp) or header (*.h) files are edited.  Some compilers do
 not support dependency file creation, or may use a different switch
 than -D.  GNU g++ works with -D.  If your compiler can't create
-dependency files (a long list of errors involving *.d files), then
-you'll need to create a Makefile.foo patterned after Makefile.storm,
-which uses different rules that do not involve dependency files.
+dependency files, then you'll need to create a Makefile.foo patterned
+after Makefile.storm, which uses different rules that do not involve
+dependency files.  Note that when you build LAMMPS for the first time
+on a new platform, a long list of *.d files will be printed out
+rapidly.  This is not an error; it is the Makefile doing its normal
+creation of dependencies.
 
-(3) The "system-specific settings" section has 4 parts.
+[Step 4]
 
-(3.a) The LMP_INC variable is used to include options that turn on
-system-dependent ifdefs within the LAMMPS code.
+The "system-specific settings" section has several parts.  Note that
+if you change any -D setting in this section, you should do a full
+re-compile, after typing "make clean" (which will describe different
+clean options).
+
+The LMP_INC variable is used to include options that turn on ifdefs
+within the LAMMPS code.  The options that are currently recogized are:
+
+-DLAMMPS_GZIP
+-DLAMMPS_JPEG
+-DLAMMPS_MEMALIGN
+-DLAMMPS_XDR
+-DLAMMPS_SMALLBIG
+-DLAMMPS_BIGBIG
+-DLAMMPS_SMALLSMALL
+-DLAMMPS_LONGLONG_TO_LONG
+-DPACK_ARRAY
+-DPACK_POINTER
+-DPACK_MEMCPY :ul
 
 The read_data and dump commands will read/write gzipped files if you
 compile with -DLAMMPS_GZIP.  It requires that your Unix support the
-"popen" command.  Using one of the -DPACK_ARRAY, -DPACK_POINTER, and
--DPACK_MEMCPY options can make for faster parallel FFTs (in the PPPM
-solver) on some platforms.  The -DPACK_ARRAY setting is the default.
+"popen" command.
+
+If you use -DLAMMPS_JPEG, the "dump image"_dump.html command will be
+able to write out JPEG image files.  If not, it will only be able to
+write out text-based PPM image files.  For JPEG files, you must also
+link LAMMPS with a JPEG library, as described below.
+
+Using -DLAMMPS_MEMALIGN= enables the use of the
+posix_memalign() call instead of malloc() when large chunks or memory
+are allocated by LAMMPS.  This can help to make more efficient use of
+vector instructions of modern CPUS, since dynamically allocated memory
+has to be aligned on larger than default byte boundaries (e.g. 16
+bytes instead of 8 bytes on x86 type platforms) for optimal
+performance.
+
 If you use -DLAMMPS_XDR, the build will include XDR compatibility
 files for doing particle dumps in XTC format.  This is only necessary
 if your platform does have its own XDR files available.  See the
 Restrictions section of the "dump"_dump.html command for details.
 
-(3.b) The 3 MPI variables are used to specify an MPI library to build
-LAMMPS with.
+Use at most one of the -DLAMMPS_SMALLBIG, -DLAMMPS_BIGBIG,
+-D-DLAMMPS_SMALLSMALL settings.  The default is -DLAMMPS_SMALLBIG.
+These refer to use of 4-byte (small) vs 8-byte (big) integers within
+LAMMPS, as described in src/lmptype.h.  The only reason to use the
+BIGBIG setting is to enable simulation of huge molecular systems with
+more than 2 billion atoms.  The only reason to use the SMALLSMALL
+setting is if your machine does not support 64-bit integers.
+
+The -DLAMMPS_LONGLONG_TO_LONG setting may be needed if your system or
+MPI version does not recognize "long long" data types.  In this case a
+"long" data type is likely already 64-bits, in which case this setting
+will convert to that data type.
+
+Using one of the -DPACK_ARRAY, -DPACK_POINTER, and -DPACK_MEMCPY
+options can make for faster parallel FFTs (in the PPPM solver) on some
+platforms.  The -DPACK_ARRAY setting is the default.  See the
+"kspace_style"_kspace_style.html command for info about PPPM.  See
+Step 6 below for info about building LAMMPS with an FFT library.
+
+[Step 5]
+
+The 3 MPI variables are used to specify an MPI library to build LAMMPS
+with. 
 
 If you want LAMMPS to run in parallel, you must have an MPI library
 installed on your platform.  If you use an MPI-wrapped compiler, such
-as "mpicc" to build LAMMPS, you can probably leave these 3 variables
-blank.  If you do not use "mpicc" as your compiler/linker, then you
-need to specify where the mpi.h file (MPI_INC) and the MPI library
-(MPI_PATH) is found and its name (MPI_LIB).
+as "mpicc" to build LAMMPS, you should be able to leave these 3
+variables blank; the MPI wrapper knows where to find the needed files.
+If not, and MPI is installed on your system in the usual place (under
+/usr/local), you also may not need to specify these 3 variables.  On
+some large parallel machines which use "modules" for their
+compile/link environements, you may simply need to include the correct
+module in your build environment.  Or the parallel machine may have a
+vendor-provided MPI which the compiler has no trouble finding.
 
-If you are installing MPI yourself, we recommend Argonne's MPICH 1.2
-or 2.0 which can be downloaded from the "Argonne MPI
-site"_http://www-unix.mcs.anl.gov/mpi.  LAM MPI should also work.  If
-you are running on a big parallel platform, your system people or the
-vendor should have already installed a version of MPI, which will be
-faster than MPICH or LAM, so find out how to build and link with it.
-If you use MPICH or LAM, you will have to configure and build it for
-your platform.  The MPI configure script should have compiler options
-to enable you to use the same compiler you are using for the LAMMPS
-build, which can avoid problems that can arise when linking LAMMPS to
-the MPI library.
+Failing this, with these 3 variables you can specify where the mpi.h
+file (MPI_INC) and the MPI library file (MPI_PATH) are found and the
+name of the library file (MPI_LIB).
 
-If you just want LAMMPS to run on a single processor, you can use the
-STUBS library in place of MPI, since you don't need an MPI library
-installed on your system.  See the Makefile.serial file for how to
-specify the 3 MPI variables.  You will also need to build the STUBS
-library for your platform before making LAMMPS itself.  From the STUBS
-dir, type "make" and it will hopefully create a libmpi.a suitable for
-linking to LAMMPS.  If this build fails, you will need to edit the
-STUBS/Makefile for your platform.
+If you are installing MPI yourself, we recommend Argonne's MPICH2
+or OpenMPI.  MPICH can be downloaded from the "Argonne MPI
+site"_http://www.mcs.anl.gov/research/projects/mpich2/.  OpenMPI can
+be downloaded from the "OpenMPI site"_http://www.open-mpi.org.
+Other MPI packages should also work. If you are running on a big
+parallel platform, your system people or the vendor should have
+already installed a version of MPI, which is likely to be faster
+than a self-installed MPICH or OpenMPI, so find out how to build
+and link with it.  If you use MPICH or OpenMPI, you will have to
+configure and build it for your platform.  The MPI configure script
+should have compiler options to enable you to use the same compiler
+you are using for the LAMMPS build, which can avoid problems that can
+arise when linking LAMMPS to the MPI library.
 
-The file STUBS/mpi.cpp has a CPU timer function MPI_Wtime() that calls
-gettimeofday() .  If your system doesn't support gettimeofday() ,
-you'll need to insert code to call another timer.  Note that the
-ANSI-standard function clock() rolls over after an hour or so, and is
-therefore insufficient for timing long LAMMPS simulations.
+If you just want to run LAMMPS on a single processor, you can use the
+dummy MPI library provided in src/STUBS, since you don't need a true
+MPI library installed on your system.  See the
+src/MAKE/Makefile.serial file for how to specify the 3 MPI variables
+in this case.  You will also need to build the STUBS library for your
+platform before making LAMMPS itself.  From the src directory, type
+"make stubs", or from the STUBS dir, type "make" and it should create
+a libmpi.a suitable for linking to LAMMPS.  If this build fails, you
+will need to edit the STUBS/Makefile for your platform.
 
-(3.c) The 3 FFT variables are used to specify an FFT library which
-LAMMPS uses when using the particle-particle particle-mesh (PPPM)
-option in LAMMPS for long-range Coulombics via the
+The file STUBS/mpi.cpp provides a CPU timer function called
+MPI_Wtime() that calls gettimeofday() .  If your system doesn't
+support gettimeofday() , you'll need to insert code to call another
+timer.  Note that the ANSI-standard function clock() rolls over after
+an hour or so, and is therefore insufficient for timing long LAMMPS
+simulations.
+
+[Step 6]
+
+The 3 FFT variables allow you to specify an FFT library which LAMMPS
+uses (for performing 1d FFTs) when running the particle-particle
+particle-mesh (PPPM) option for long-range Coulombics via the
 "kspace_style"_kspace_style.html command.
 
-To use this option, you must have a 1d FFT library installed on your
-platform.  This is specified by a switch of the form -DFFT_XXX where
-XXX = INTEL, DEC, SGI, SCSL, or FFTW.  All but the last one are native
-vendor-provided libraries.  FFTW is a fast, portable library that
-should work on any platform.  You can download it from
-"www.fftw.org"_http://www.fftw.org.  Use version 2.1.X, not the newer
-3.0.X.  Building FFTW for your box should be as simple as ./configure;
-make.  Whichever FFT library you have on your platform, you'll need to
-set the appropriate FFT_INC, FFT_PATH, and FFT_LIB variables in
-Makefile.foo.
+LAMMPS supports various open-source or vendor-supplied FFT libraries
+for this purpose.  If you leave these 3 variables blank, LAMMPS will
+use the open-source "KISS FFT library"_http://kissfft.sf.net, which is
+included in the LAMMPS distribution.  This library is portable to all
+platforms and for typical LAMMPS simulations is almost as fast as FFTW
+or vendor optimized libraries.  If you are not including the KSPACE
+package in your build, you can also leave the 3 variables blank.
 
-If you examine src/fft3d.c and src.fft3d.h you'll see it's possible to
-add other vendor FFT libraries via #ifdef statements in the
-appropriate places.  If you successfully add a new FFT option, like
--DFFT_IBM, please send the LAMMPS developers an email; we'd like to
-add it to LAMMPS.
+Otherwise, select which kinds of FFTs to use as part of the FFT_INC
+setting by a switch of the form -DFFT_XXX.  Recommended values for XXX
+are: MKL, SCSL, FFTW2, and FFTW3.  Legacy options are: INTEL, SGI,
+ACML, and T3E.  For backward compatability, using -DFFT_FFTW will use
+the FFTW2 library.  Using -DFFT_NONE will use the KISS library
+described above.
 
-If you don't plan to use PPPM, you don't need an FFT library.  In this
-case you can set FFT_INC to -DFFT_NONE and leave the other 2 FFT
-variables blank.  Or you can exclude the KSPACE package when you build
-LAMMPS (see below).
+You may also need to set the FFT_INC, FFT_PATH, and FFT_LIB variables,
+so the compiler and linker can find the needed FFT header and library
+files.  Note that on some large parallel machines which use "modules"
+for their compile/link environements, you may simply need to include
+the correct module in your build environment.  Or the parallel machine
+may have a vendor-provided FFT library which the compiler has no
+trouble finding.
 
-(3.d) The several SYSLIB and SYSPATH variables can be ignored unless
-you are building LAMMPS with one or more of the LAMMPS packages that
-require these extra system libraries.  The names of these packages are
-the prefixes on the SYSLIB and SYSPATH variables.  See the "section
-below"_#2_3_4 for more details.  The SYSLIB variables list the system
-libraries.  The SYSPATH variables are where they are located on your
-machine, which is typically only needed if they are in some
-non-standard place, that is not in your library search path.
+FFTW is a fast, portable library that should also work on any
+platform.  You can download it from
+"www.fftw.org"_http://www.fftw.org.  Both the legacy version 2.1.X and
+the newer 3.X versions are supported as -DFFT_FFTW2 or -DFFT_FFTW3.
+Building FFTW for your box should be as simple as ./configure; make.
+Note that on some platforms FFTW2 has been pre-installed, and uses
+renamed files indicating the precision it was compiled with,
+e.g. sfftw.h, or dfftw.h instead of fftw.h.  In this case, you can
+specify an additional define variable for FFT_INC called -DFFTW2_SIZE,
+which will select the correct include file.  In this case, for FFT_LIB
+you must also manually specify the correct library, namely -lsfftw or
+-ldfftw.
 
-That's it.  Once you have a correct Makefile.foo and you have
-pre-built any other libraries it will use (e.g. MPI, FFT, package
-libraries), all you need to do from the src directory is type one of
-these 2 commands:
+The FFT_INC variable also allows for a -DFFT_SINGLE setting that will
+use single-precision FFTs with PPPM, which can speed-up long-range
+calulations, particularly in parallel or on GPUs.  Fourier transform
+and related PPPM operations are somewhat insensitive to floating point
+truncation errors and thus do not always need to be performed in
+double precision.  Using the -DFFT_SINGLE setting trades off a little
+accuracy for reduced memory use and parallel communication costs for
+transposing 3d FFT data.  Note that single precision FFTs have only
+been tested with the FFTW3, FFTW2, MKL, and KISS FFT options.
+
+[Step 7]
+
+The 3 JPG variables allow you to specify a JPEG library which LAMMPS
+uses when writing out JPEG files via the "dump image"_dump_image.html
+command.  These can be left blank if you do not use the -DLAMMPS_JPEG
+switch discussed above in Step 4, since in that case JPEG output will
+be disabled.
+
+A standard JPEG library usually goes by the name libjpeg.a and has an
+associated header file jpeglib.h.  Whichever JPEG library you have on
+your platform, you'll need to set the appropriate JPG_INC, JPG_PATH,
+and JPG_LIB variables, so that the compiler and linker can find it.
+
+As before, if these header and library files are in the usual place on
+your machine, you may not need to set these variables.
+
+[Step 8]
+
+Note that by default only a few of LAMMPS optional pacakges are
+installed.  To build LAMMPS with optional packages, see "this
+section"_#start_3 below, before proceeding to Step 9.
+
+[Step 9]
+
+That's it.  Once you have a correct Makefile.foo, you have installed
+the optional LAMMPS packages you want to include in your build, and
+you have pre-built any other needed libraries (e.g. MPI, FFT, package
+libraries), all you need to do from the src directory is type
+something like this:
 
 make foo
+or
 gmake foo :pre
 
 You should get the executable lmp_foo when the build is complete.
 
 :line
 
-[{Additional build tips:}] :link(2_2_5)
+[{Errors that can occur when making LAMMPS:}] :link(start_2_3)
+
+IMPORTANT NOTE: If an error occurs when building LAMMPS, the compiler
+or linker will state very explicitly what the problem is.  The error
+message should give you a hint as to which of the steps above has
+failed, and what you need to do in order to fix it.  Building a code
+with a Makefile is a very logical process.  The compiler and linker
+need to find the appropriate files and those files need to be
+compatible with LAMMPS source files.  When a make fails, there is
+usually a very simple reason, which you or a local expert will need to
+fix.
+
+Here are two non-obvious errors that can occur:
+
+(1) If the make command breaks immediately with errors that indicate
+it can't find files with a "*" in their names, this can be because
+your machine's native make doesn't support wildcard expansion in a
+makefile.  Try gmake instead of make.  If that doesn't work, try using
+a -f switch with your make command to use a pre-generated
+Makefile.list which explicitly lists all the needed files, e.g.
+
+make makelist
+make -f Makefile.list linux
+gmake -f Makefile.list mac :pre
+
+The first "make" command will create a current Makefile.list with all
+the file names in your src dir.  The 2nd "make" command (make or
+gmake) will use it to build LAMMPS.  Note that you should
+include/exclude any desired optional packages before using the "make
+makelist" command.
+
+(2) If you get an error that says something like 'identifier "atoll"
+is undefined', then your machine does not support "long long"
+integers.  Try using the -DLAMMPS_LONGLONG_TO_LONG setting described
+above in Step 4.
+
+:line
+
+[{Additional build tips:}] :link(start_2_4)
 
 (1) Building LAMMPS for multiple platforms.
 
@@ -302,27 +427,7 @@ Typing "make clean-all" or "make clean-foo" will delete *.o object
 files created when LAMMPS is built, for either all builds or for a
 particular machine.
 
-(3) Building for a Mac.
-
-OS X is BSD Unix, so it should just work.  See the Makefile.mac file.
-
-(4) Building for MicroSoft Windows.
-
-The LAMMPS download page has an option to download a pre-built Windows
-exeutable.  See below for instructions for running this executable on
-a Windows box.
-
-If the pre-built executable doesn't have the options you want, then
-you should be able to build LAMMPS from source files on a Windows box.
-I've never done this, but LAMMPS is just standard C++ with MPI and FFT
-calls.  You can use cygwin to build LAMMPS with a Unix make; see
-Makefile.cygwin.  Or you should be able to pull all the source files
-into Visual C++ (ugh) or some similar development environment and
-build it.  In the src/MAKE/Windows directory are some notes from users
-on how they built LAMMPS under Windows, so you can look at their
-instructions for tips.  Good luck - we can't help you on this one.
-
-(5) Changing the size limits in src/lmptype.h
+(3) Changing the size limits in src/lmptype.h
 
 If you are running a very large problem (billions of atoms or more)
 and get a run-time error about the system being too big, either on a
@@ -344,10 +449,10 @@ are effectively unlimited in size (2^63).
 
 The default for total system size quantities (like the number of atoms
 or timesteps) is 8-byte integers by default which is effectively
-unlimited in size (2^63).  If your system does not support 8-byte
-integers, an error will be generated, and you will need to set
-"bigint" to 4-byte integers.  This restricts your total system size to
-about 2 billion atoms or timesteps (2^31).
+unlimited in size (2^63).  If your system or MPI implementation does
+not support 8-byte integers, an error will be generated, and you will
+need to set "bigint" to 4-byte integers.  This restricts your total
+system size to about 2 billion atoms or timesteps (2^31).
 
 Note that in src/lmptype.h there are also settings for the MPI data
 types associated with the integers that store atom IDs and total
@@ -363,248 +468,236 @@ secs/timestep.
 
 :line
 
-2.3 Making LAMMPS with optional packages :h4,link(2_3)
+[{Building for a Mac:}] :link(start_2_5)
 
-This section has the following sub-sections:
-
-"Package basics"_#2_3_1
-"Including/excluding packages"_#2_3_2
-"Packages that require extra LAMMPS libraries"_#2_3_3
-"Additional Makefile settings for extra libraries"_#2_3_4 :ul
+OS X is BSD Unix, so it should just work.  See the Makefile.mac file.
 
 :line
 
-[{Package basics:}] :link(2_3_1)
+[{Building for Windows:}] :link(start_2_6)
 
-The source code for LAMMPS is structured as a large set of core files
-which 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.  You can see the list of all packages by typing "make
-package".
+The LAMMPS download page has an option to download both a serial and
+parallel pre-built Windows exeutable.  See the "Running
+LAMMPS"_#start_5 section for instructions for running these
+executables on a Windows box.
 
-The current list of standard packages is as follows:
+If the pre-built executable doesn't have the options you want, then
+you can build LAMMPS from its source files on a Windows box.  One way
+to do this is install and use cygwin to build LAMMPS with a standard
+Linus make, just as you would on any Linux box; see
+src/MAKE/Makefile.cygwin.
 
-asphere : aspherical particles and force fields
-class2 : class 2 force fields
-colloid : colloidal particle force fields
-dipole : point dipole particles and force fields
-dsmc : Direct Simulation Monte Carlo (DMSC) pair style
-gpu : GPU-enabled force field styles
-granular : force fields and boundary conditions for granular systems
-kspace : long-range Ewald and particle-mesh (PPPM) solvers
-manybody : metal, 3-body, bond-order potentials
-meam : modified embedded atom method (MEAM) potential
-molecule : force fields for molecular systems
-opt : optimized versions of a few pair potentials
-peri : Peridynamics model and potential
-poems : coupled rigid body motion
-reax : ReaxFF potential
-replica : multi-replica methods
-shock : methods for MD simulations of shock loading
-srd : stochastic rotation dynamics (SRD)
-xtc : dump atom snapshots in XTC format :tb(s=:)
+There is a also a src/WINDOWS directory that contains project files
+for Microsoft Visual Studio 2005, which should also work with later
+versions of VS.  That directory contains a README.txt file which
+provides instructions for building LAMMPS from source code using
+Visual Studio that are hopefully easy to follow for Windows and VS
+users.
 
-There are also user-contributed packages which may be as simple as a
-single additional file or many files grouped together which add a
-specific functionality to the code.
+Four VS project options are provided.  The first includes the default
+packages (MANYBODY, MOLECULE, and KSPACE).  The second includes all
+standard packages (except GPU, MEAM, and REAX which are not yet
+included because they require NVIDIA or Fortran compilation).  The
+third includes all standard packages (with the exceptions) and some
+user packages.  The included user packages are USER-EFF, USER-CG-CMM,
+and USER-REAXC.  The fourth project includes the USER-AWPMD package.
 
-The difference between a {standard} package versus a {user} package is
-as follows.
+:line
+
+2.3 Making LAMMPS with optional packages :h4,link(start_3)
+
+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
+"Additional Makefile settings for extra libraries"_#start_3_4 :ul
+
+:line
+
+[{Package basics:}] :link(start_3_1)
+
+The source code for LAMMPS is structured as a set of core files which
+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.  You
+can see the list of all packages by typing "make package" from within
+the src directory of the LAMMPS distribution.
+
+If you use a command in a LAMMPS input script that is specific to a
+particular package, you must have built LAMMPS with that package, else
+you will get an error that the style is invalid or the command is
+unknown.  Every command's doc page specfies if it is part of a
+package.  You can also type
+
+lmp_machine -h :pre
+
+to run your executable with the optional "-h command-line
+switch"_#start_6 for "help", which will list the styles and commands
+known to your executable.
+
+There are two kinds of packages in LAMMPS, standard and user packages.
+More information about the contents of standard and user packages is
+given in "this section"_Section_packages.html of the manual.  The
+difference between standard and user packages is as follows:
 
 Standard packages are supported by the LAMMPS developers and are
 written in a syntax and style consistent with the rest of LAMMPS.
 This means we will answer questions about them, debug and fix them if
 necessary, and keep them compatible with future changes to LAMMPS.
 
-User packages don't necessarily meet these requirements.  If you have
-problems using a feature provided in a user package, you will likely
-need to contact the contributor directly to get help.  Information on
-how to submit additions you make to LAMMPS as a user-contributed
-package is given in "this section"_Section_modify.html#package of the
-documentation.
+User packages have been contributed by users, and always begin with
+the user prefix.  If they are a single command (single file), they are
+typically in the user-misc package.  Otherwise, they are a a set of
+files grouped together which add a specific functionality to the code.
+
+User packages don't necessarily meet the requirements of the standard
+packages.  If you have problems using a feature provided in a user
+package, you will likely need to contact the contributor directly to
+get help.  Information on how to submit additions you make to LAMMPS
+as a user-contributed package is given in "this
+section"_Section_modify.html#mod_14 of the documentation.
 
 :line
 
-[{Including/excluding packages:}] :link(2_3_2)
+[{Including/excluding packages:}] :link(start_3_2)
 
-Any or all packages can be included or excluded independently BEFORE
-LAMMPS is built.
+To use or not use a package you must include or exclude it before
+building LAMMPS.  From the src directory, this is typically as simple
+as:
 
-The two exceptions to this are the "gpu" and "opt" packages.  Some of
-the files in these packages require other packages to also be
-included.  If this is not the case, then those subsidiary files in
-"gpu" and "opt" will not be installed either.  To install all the
-files in package "gpu", the "asphere" and "kspace" packages must also be 
-installed. To install all the files in package "opt", the "kspace" and 
-"manybody" packages must also be installed.
+make yes-colloid
+make g++ :pre
 
-You may wish to exclude certain packages if you will never run certain
-kinds of simulations.  This will keep you from having to build
-auxiliary libraries (see below) and will produce a smaller executable
-which may run a bit faster.
+or
 
-By default, LAMMPS includes only the "kspace", "manybody", and
-"molecule" packages.
+make no-manybody
+make g++ :pre
+
+Some packages have individual files that depend on other packages
+being included.  LAMMPS checks for this and does the right thing.
+I.e. individual files are only included if their dependencies are
+already included.  Likewise, if a package is excluded, other files
+dependent on that package are also excluded.
+
+The reason to exclude packages is if you will never run certain kinds
+of simulations.  For some packages, this will keep you from having to
+build auxiliary libraries (see below), and will also produce a smaller
+executable which may run a bit faster.
+
+When you download a LAMMPS tarball, these packages are pre-installed
+in the src directory: KSPACE, MANYBODY,MOLECULE.  When you download
+LAMMPS source files from the SVN or Git repositories, no packages are
+pre-installed.
 
 Packages are included or excluded by typing "make yes-name" or "make
-no-name", where "name" is the name of the package.  You can also type
-"make yes-standard", "make no-standard", "make yes-user", "make
-no-user", "make yes-all" or "make no-all" to include/exclude various
-sets of packages.  Type "make package" to see the various options.
+no-name", where "name" is the name of the package in lower-case, e.g.
+name = kspace for the KSPACE package or name = user-atc for the
+USER-ATC package.  You can also type "make yes-standard", "make
+no-standard", "make yes-user", "make no-user", "make yes-all" or "make
+no-all" to include/exclude various sets of packages.  Type "make
+package" to see the all of the package-related make options.
 
-IMPORTANT NOTE: These make commands work by simply moving files back
-and forth between the main src directory and sub-directories with the
-package name, so that the files are seen or not seen when LAMMPS is
-built.  After you have included or excluded a package, you must
-re-build LAMMPS.
+IMPORTANT NOTE: Inclusion/exclusion of a package works by simply
+moving files back and forth between the main src directory and
+sub-directories with the package name (e.g. src/KSPACE, src/USER-ATC),
+so that the files are seen or not seen when LAMMPS is built.  After
+you have included or excluded a package, you must re-build LAMMPS.
 
-Additional make options exist to help manage LAMMPS files that exist
-in both the src directory and in package sub-directories.  You do not
-normally need to use these commands unless you are editing LAMMPS
-files or have downloaded a patch from the LAMMPS WWW site.
+Additional package-related make options exist to help manage LAMMPS
+files that exist in both the src directory and in package
+sub-directories.  You do not normally need to use these commands
+unless you are editing LAMMPS files or have downloaded a patch from
+the LAMMPS WWW site.
 
 Typing "make package-update" will overwrite src files with files from
-the package directories if the package has been included.  It should
-be used after a patch is installed, since patches only update the
-master package version of a file.  Typing "make package-overwrite"
-will overwrite files in the package directories with src files.
-Typing "make package-check" will list differences between src and
-package versions of the same files.  Again, type "make package" to see
-the various options.
+the package sub-directories if the package has been included.  It
+should be used after a patch is installed, since patches only update
+the files in the package sub-directory, but not the src files.  Typing
+"make package-overwrite" will overwrite files in the package
+sub-directories with src files.
+
+Typing "make package-status" will show which packages are currently
+included. Of those that are included, it will list files that are
+different in the src directory and package sub-directory.  Typing
+"make package-diff" lists all differences between these files.  Again,
+type "make package" to see all of the package-related make options.
 
 :line
 
-[{Packages that require extra LAMMPS libraries:}] :link(2_3_3)
+[{Packages that require extra libraries:}] :link(start_3_3)
 
-A few packages (standard or user) require that additional libraries be
-compiled first, which LAMMPS will link to when it builds.  The source
-code for these libraries are included in the LAMMPS distribution under
-the "lib" directory.  Look at the README files in the lib directories
-(e.g. lib/reax/README) for instructions on how to build each library.
+A few of the standard and user packages require additional auxiliary
+libraries to be compiled first.  If you get a LAMMPS build error about
+a missing library, this is likely the reason.  The source code for
+these libraries is included in the LAMMPS distribution under the "lib"
+directory.  Look at the lib/README file for a list of these or see
+"this section"_Section_packages.html of the doc pages.
 
-IMPORTANT NOTE: If you are including a package in your LAMMPS build
-that uses one of these libraries, then you must build the library
-BEFORE building LAMMPS itself, since the LAMMPS build will attempt to
-link with the library file.
-
-Here is a bit of information about each library:
-
-The "atc" library in lib/atc is used by the user-atc package.  It
-provides continuum field estimation and molecular dynamics-finite
-element coupling methods.  It was written primarily by Reese Jones,
-Jeremy Templeton and Jonathan Zimmerman at Sandia.
-
-The "gpu" library in lib/gpu is used by the gpu package.  It
-contains code to enable portions of LAMMPS to run on a GPU chip
-associated with your CPU.  Currently, only NVIDIA GPUs are supported.
-Building this library requires NVIDIA Cuda tools to be installed on
-your system.  See the "Running on GPUs"_#2_8 section below for more
-info about installing and using Cuda.
-
-The "meam" library in lib/meam is used by the meam package.
-computes the modified embedded atom method potential, which is a
-generalization of EAM potentials that can be used to model a wider
-variety of materials.  This MEAM implementation was written by Greg
-Wagner at Sandia.  It requires a F90 compiler to build.  The C++ to
-FORTRAN function calls in pair_meam.cpp assumes that FORTRAN object
-names are converted to C object names by appending an underscore
-character. This is generally the case, but on machines that do not
-conform to this convention, you will need to modify either the C++
-code or your compiler settings.
-
-The "poems" library in lib/poems is used by the poems package.
-computes the constrained rigid-body motion of articulated (jointed)
-multibody systems.  POEMS was written and is distributed by Prof Kurt
-Anderson's group at Rensselaer Polytechnic Institute (RPI).
-
-The "reax" library in lib/reax is used by the reax package.  It
-computes the Reactive Force Field (ReaxFF) potential, developed by
-Adri van Duin in Bill Goddard's group at CalTech.  This implementation
-in LAMMPS uses many of Adri's files and was developed by Aidan
-Thompson at Sandia and Hansohl Cho at MIT.  It requires a F77 or F90
-compiler to build.  The C++ to FORTRAN function calls in pair_reax.cpp
-assume that FORTRAN object names are converted to C object names by
-appending an underscore character. This is generally the case, but on
-machines that do not conform to this convention, you will need to
-modify either the C++ code or your compiler settings. The name
-conversion is handled by the preprocessor macro called FORTRAN in
-pair_reax_fortran.h.  Different definitions of this macro can be
-obtained by adding a machine-specific macro definition to the CCFLAGS
-variable in your Makefile e.g. -D_IBM. See pair_reax_fortran.h for
-more info.
-
-As described in its README file, each library is built by typing
-something like
+Each lib directory has a README file (e.g. lib/reax/README) with
+instructions on how to build that library.  Typically this is done 
+in this manner:
 
 make -f Makefile.g++ :pre
 
-in the appropriate directory, e.g. in lib/reax.
+in the appropriate directory, e.g. in lib/reax.  Some of the libraries
+do not build this way.  Again, see the libary README file for details.
 
-You must use a Makefile that is a match for your system.  If one of
-the provided Makefiles is not appropriate for your system you will
-need to edit or add one.  For example, in the case of Fotran-based
-libraries, your system must have a Fortran compiler, the settings for
-which will be in the Makefile.
+In any event, you will need to use a Makefile that is a match for your
+system.  If one of the provided Makefiles is not appropriate for your
+system you will need to edit or add one.  For example, in the case of
+Fortran-based libraries, your system must have a Fortran compiler, the
+settings for which will need to be listed in the Makefile.
+
+When you have built one of these libraries, there are 2 things to
+check:
+
+(1) The file libname.a should now exist in lib/name.
+E.g. lib/reax/libreax.a.  This is the library file LAMMPS will link
+against.  One exception is the lib/cuda library which produces the
+file liblammpscuda.a, because there is already a system library
+libcuda.a.
+
+(2) The file Makefile.lammps should exist in lib/name.  E.g.
+lib/cuda/Makefile.lammps.  This file may be auto-generated by the
+build of the library, or you may need to make a copy of the
+appropriate provided file (e.g. lib/meam/Makefile.lammps.gfortran).
+Either way you should insure that the settings in this file are
+appropriate for your system.
+
+There are typically 3 settings in the Makefile.lammps file (unless
+some are blank or not needed): a SYSINC, SYSPATH, and SYSLIB setting,
+specific to this package.  These are settings the LAMMPS build will
+import when compiling the LAMMPS package files (not the library
+files), and linking to the auxiliary library.  They typically list any
+other system libraries needed to support the package and where to find
+them.  An example is the BLAS and LAPACK libraries needed by the
+USER-ATC package.  Or the system libraries that support calling
+Fortran from C++, as the MEAM and REAX packages do.
+
+Note that if these settings are not correct for your box, the LAMMPS
+build will likely fail.
 
 :line
 
-[{Additional Makefile settings for extra libraries:}] :link(2_3_4)
+2.4 Building LAMMPS as a library :h4,link(start_4)
 
-After the desired library or libraries are built, and the package has
-been included, you can build LAMMPS itself.  For example, from the
-lammps/src directory you would type this, to build LAMMPS with ReaxFF.
-Note that as discussed in the preceding section, the package library
-itself, namely lib/reax/libreax.a, must already have been built, for
-the LAMMPS build to be successful.
-
-make yes-reax
-make g++ :pre
-
-Also note that simply building the library is not sufficient to use it
-from LAMMPS.  As in this example, you must also include the package
-that uses and wraps the library before you build LAMMPS itself.
-
-As discussed in point (2.4) of "this section"_#2_2_4 above, there are
-settings in the low-level Makefile that specify additional system
-libraries needed by individual LAMMPS add-on libraries.  These are the
-settings you must specify correctly in your low-level Makefile in
-lammps/src/MAKE, such as Makefile.foo:
-
-To use the gpu package and library, the settings for gpu_SYSLIB and
-gpu_SYSPATH must be correct.  These are specific to the NVIDIA CUDA
-software which must be installed on your system.
-
-To use the meam or reax packages and their libraries which are Fortran
-based, the settings for meam_SYSLIB, reax_SYSLIB, meam_SYSPATH, and
-reax_SYSPATH must be correct.  This is so that the C++ compiler can
-perform a cross-language link using the appropriate system Fortran
-libraries.
-
-To use the user-atc package and library, the settings for
-user-atc_SYSLIB and user-atc_SYSPATH must be correct.  This is so that
-the appropriate BLAS and LAPACK libs, used by the user-atc library,
-can be found.
-
-:line
-
-2.4 Building LAMMPS as a library :h4,link(2_4)
-
-LAMMPS can be built as a library, which can then be called from
+LAMMPS itself can be built as a library, which can then be called from
 another application or a scripting language.  See "this
-section"_Section_howto.html#4_10 for more info on coupling LAMMPS to
-other codes.  Building LAMMPS as a library is done by typing
+section"_Section_howto.html#howto_10 for more info on coupling LAMMPS
+to other codes.  Building LAMMPS as a library is done by typing
 
 make makelib
 make -f Makefile.lib foo :pre
 
-where foo is the machine name.  The first "make" command will create a
-current Makefile.lib with all the file names in your src dir.  The 2nd
-"make" command will use it to build LAMMPS as a library.  This
-requires that Makefile.foo have a library target (lib) and
-system-specific settings for ARCHIVE and ARFLAGS.  See Makefile.linux
-for an example.  The build will create the file liblmp_foo.a which
-another application can link to.
+where foo is the machine name.  Note that inclusion or exclusion of
+any desired optional packages should be done before typing "make
+makelib".  The first "make" command will create a current Makefile.lib
+with all the file names in your src dir.  The 2nd "make" command will
+use it to build LAMMPS as a library.  This requires that Makefile.foo
+have a library target (lib) and system-specific settings for ARCHIVE
+and ARFLAGS.  See Makefile.linux for an example.  The build will
+create the file liblmp_foo.a which another application can link to.
 
 When used from a C++ program, the library allows one or more LAMMPS
 objects to be instantiated.  All of LAMMPS is wrapped in a LAMMPS_NS
@@ -618,19 +711,19 @@ src/library.cpp and src/library.h.
 See the sample codes couple/simple/simple.cpp and simple.c as examples
 of C++ and C codes that invoke LAMMPS thru its library interface.
 There are other examples as well in the couple directory which are
-discussed in "this section"_Section_howto.html#4_10 of the manual.
+discussed in "this section"_Section_howto.html#howto_10 of the manual.
 See "this section"_Section_python.html of the manual for a description
 of the Python wrapper provided with LAMMPS that operates through the
 LAMMPS library interface.
 
 The files src/library.cpp and library.h contain the C-style interface
-to LAMMPS.  See "this section"_Section_howto.html#4_19 of the manual
-for a description of the interface and how to extend it for your
-needs.
+to LAMMPS.  See "this section"_Section_howto.html#howto_19 of the
+manual for a description of the interface and how to extend it for
+your needs.
 
 :line
 
-2.5 Running LAMMPS :h4,link(2_5)
+2.5 Running LAMMPS :h4,link(start_5)
 
 By default, LAMMPS runs by reading commands from stdin; e.g. lmp_linux
 < in.file.  This means you first create an input script (e.g. in.file)
@@ -659,16 +752,14 @@ on various platforms.
 
 :line
 
-On a Windows machine, you can skip making LAMMPS and simply download
-an executable. But note that not all packages are available.
-The following packages are available: asphere, class2, colloid, dipole,
-dsmc, granular, kspace, manybody, molecule, peri, poems, replica, shock,
-user-ackland, user-cd-eam, user-cg-cmm, user-ewaldn, user-smd. But these 
-packages are not available: gpu, meam, opt, reax, xtc, user-atc, user-imd.
+On a Windows box, you can skip making LAMMPS and simply download an
+executable, as described above, though the pre-packaged executables
+include only certain packages.
 
-To run the LAMMPS executable on a Windows machine, first decide whether 
-you want to download the non-MPI (serial) or the MPI (parallel) version 
-of the executable. Download and save the version you have chosen.
+To run a LAMMPS executable on a Windows machine, first decide whether
+you want to download the non-MPI (serial) or the MPI (parallel)
+version of the executable. Download and save the version you have
+chosen.
 
 For the non-MPI version, follow these steps:
 
@@ -739,25 +830,43 @@ more processors or setup a smaller problem.
 
 :line
 
-2.6 Command-line options :h4,link(2_6)
+2.6 Command-line options :h4,link(start_6)
 
 At run time, LAMMPS recognizes several optional command-line switches
-which may be used in any order.  Either the full word or the
-one-letter abbreviation can be used:
+which may be used in any order.  Either the full word or a one-or-two
+letter abbreviation can be used:
 
--echo or -e
--partition or -p
--in or -i
--log or -l
--screen or -s
--var or -v :ul
+-c or -cuda
+-e or -echo
+-i or -in
+-h or -help
+-l or -log
+-p or -partition
+-pl or -plog
+-ps or -pscreen
+-sc or -screen
+-sf or -suffix
+-v or -var :ul
 
 For example, lmp_ibm might be launched as follows:
 
+mpirun -np 16 lmp_ibm -v f tmp.out -l my.log -sc none < in.alloy
 mpirun -np 16 lmp_ibm -var f tmp.out -log my.log -screen none < in.alloy :pre
 
 Here are the details on the options:
 
+-cuda on/off :pre
+
+Explicitly enable or disable CUDA support, as provided by the
+USER-CUDA package.  If LAMMPS is built with this package, as described
+above in "Section 2.3"_#start_3, then by default LAMMPS will run in
+CUDA mode.  If this switch is set to "off", then it will not, even if
+it was built with the USER-CUDA package, which means you can run
+standard LAMMPS or with the GPU package for testing or benchmarking
+purposes.  The only reason to set the switch to "on", is to check if
+LAMMPS was built with the USER-CUDA package, since an error will be
+generated if it was not.
+
 -echo style :pre
 
 Set the style of command echoing.  The style can be {none} or {screen}
@@ -767,6 +876,37 @@ can be useful to figure out which line of your script is causing an
 input error.  The default value is {log}.  The echo style can also be
 set by using the "echo"_echo.html command in the input script itself.
 
+-in file :pre
+
+Specify a file to use as an input script.  This is an optional switch
+when running LAMMPS in one-partition mode.  If it is not specified,
+LAMMPS reads its input script from stdin - e.g. lmp_linux < in.run.
+This is a required switch when running LAMMPS in multi-partition mode,
+since multiple processors cannot all read from stdin.
+
+-help :pre
+
+Print a list of options compiled into this executable for each LAMMPS
+style (atom_style, fix, compute, pair_style, bond_style, etc).  This
+can help you know if the command you want to use was included via the
+appropriate package.  LAMMPS will print the info and immediately exit
+if this switch is used.
+
+-log file :pre
+
+Specify a log file for LAMMPS to write status information to.  In
+one-partition mode, if the switch is not used, LAMMPS writes to the
+file log.lammps.  If this switch is used, LAMMPS writes to the
+specified file.  In multi-partition mode, if the switch is not used, a
+log.lammps file is created with hi-level status information.  Each
+partition also writes to a log.lammps.N file where N is the partition
+ID.  If the switch is specified in multi-partition mode, the hi-level
+logfile is named "file" and each partition also logs information to a
+file.N.  For both one-partition and multi-partition mode, if the
+specified file is "none", then no log files are created.  Using a
+"log"_log.html command in the input script will override this setting.
+Option -plog will override the name of the partition log files file.N.
+
 -partition 8x2 4 5 ... :pre
 
 Invoke LAMMPS in multi-partition mode.  When LAMMPS is run on P
@@ -781,39 +921,40 @@ processors in all partitions must equal P.  Thus the command
 "-partition 8x2 4 5" has 10 partitions and runs on a total of 25
 processors.
 
-Note that with MPI installed on a machine (e.g. your desktop), you can
-run on more (virtual) processors than you have physical processors.
-This can be useful for running "multi-replica
-simulations"_Section_howto.html#4_5, on one or a few processors.
+Running with multiple partitions can e useful for running
+"multi-replica simulations"_Section_howto.html#howto_5, where each
+replica runs on on one or a few processors.  Note that with MPI
+installed on a machine (e.g. your desktop), you can run on more
+(virtual) processors than you have physical processors.
 
-The input script specifies what simulation is run on which partition;
-see the "variable"_variable.html and "next"_next.html commands.  This
-"howto section"_Section_howto.html#4_4 gives examples of how to use
-these commands in this way.  Simulations running on different
-partitions can also communicate with each other; see the
-"temper"_temper.html command.
+To run multiple independent simulatoins from one input script, using
+multiple partitions, see "this section"_Section_howto.html#howto_4 of
+the manual.  World- and universe-style "variables"_variable.html are
+useful in this context.
 
--in file :pre
+-plog file :pre
+ 
+Specify the base name for the partition log files, so partition N
+writes log information to file.N. If file is none, then no partition
+log files are created.  This overrides the filename specified in the
+-log command-line option.  This option is useful when working with
+large numbers of partitions, allowing the partition log files to be
+suppressed (-plog none) or placed in a sub-directory (-plog
+replica_files/log.lammps) If this option is not used the log file for
+partition N is log.lammps.N or whatever is specified by the -log
+command-line option.
 
-Specify a file to use as an input script.  This is an optional switch
-when running LAMMPS in one-partition mode.  If it is not specified,
-LAMMPS reads its input script from stdin - e.g. lmp_linux < in.run.
-This is a required switch when running LAMMPS in multi-partition mode,
-since multiple processors cannot all read from stdin.
+-pscreen file :pre 
 
--log file :pre
-
-Specify a log file for LAMMPS to write status information to.  In
-one-partition mode, if the switch is not used, LAMMPS writes to the
-file log.lammps.  If this switch is used, LAMMPS writes to the
-specified file.  In multi-partition mode, if the switch is not used, a
-log.lammps file is created with hi-level status information.  Each
-partition also writes to a log.lammps.N file where N is the partition
-ID.  If the switch is specified in multi-partition mode, the hi-level
-logfile is named "file" and each partition also logs information to a
-file.N.  For both one-partition and multi-partition mode, if the
-specified file is "none", then no log files are created.  Using a
-"log"_log.html command in the input script will override this setting.
+Specify the base name for the partition screen file, so partition N
+writes screen information to file.N. If file is none, then no
+partition screen files are created.  This overrides the filename
+specified in the -screen command-line option.  This option is useful
+when working with large numbers of partitions, allowing the partition
+screen files to be suppressed (-pscreen none) or placed in a
+sub-directory (-pscreen replica_files/screen) If this option is not
+used the screen file for partition N is screen.N or whatever is
+specified by the -screen command-line option.
 
 -screen file :pre
 
@@ -827,7 +968,42 @@ the partition ID.  If the switch is specified in multi-partition mode,
 the hi-level screen dump is named "file" and each partition also
 writes screen information to a file.N.  For both one-partition and
 multi-partition mode, if the specified file is "none", then no screen
-output is performed.
+output is performed. Option -pscreen will override the name of the
+partition screen files file.N.
+
+-suffix style :pre
+
+Use variants of various styles if they exist.  The specified style can
+be {opt}, {omp}, {gpu}, or {cuda}.  These refer to optional packages that
+LAMMPS can be built with, as described above in "Section
+2.3"_#start_3.  The "opt" style corrsponds to the OPT package, the
+"omp" style to the USER-OMP package, the "gpu" style to the GPU 
+package, and the "cuda" style to the USER-CUDA package.
+
+As an example, all of the packages provide a "pair_style
+lj/cut"_pair_lj.html variant, with style names lj/cut/opt, lj/cut/omp,
+lj/cut/gpu, or lj/cut/cuda.  A variant styles can be specified
+explicitly in your input script, e.g. pair_style lj/cut/gpu.  If the
+-suffix switch is used, you do not need to modify your input script.
+The specified suffix (opt,omp,gpu,cuda) is automatically appended
+whenever your input script command creates a new
+"atom"_atom_style.html, "pair"_pair_style.html, "fix"_fix.html,
+"compute"_compute.html, or "run"_run_style.html style.  If the variant
+version does not exist, the standard version is created.
+
+For the GPU package, using this command-line switch also invokes the
+default GPU settings, as if the command "package gpu force/neigh 0 0
+1" were used at the top of your input script.  These settings can be
+changed by using the "package gpu"_pacakge.html command in your script
+if desired.
+
+For the OMP package, using this command-line switch also invokes the
+default OMP settings, as if the command "package omp *" were used at
+the top of your input script.  These settings can be changed by using
+the "package omp"_pacakge.html command in your script if desired.
+
+The "suffix"_suffix.html command can also set a suffix and it can also
+turn off/on any suffix setting made via the command line.
 
 -var name value1 value2 ... :pre
 
@@ -843,12 +1019,18 @@ variable as a command-line argument overrides any setting for the same
 index variable in the input script, since index variables cannot be
 re-defined.  See the "variable"_variable.html command for more info on
 defining index and other kinds of variables and "this
-section"_Section_commands.html#3_2 for more info on using variables in
-input scripts.
+section"_Section_commands.html#cmd_2 for more info on using variables
+in input scripts.
+
+NOTE: Currently, the command-line parser looks for arguments that
+start with "-" to indicate new switches.  Thus you cannot specify
+multiple variable values if any of they start with a "-", e.g. a
+negative numeric value.  It is OK if the first value1 starts with a
+"-", since it is automatically skipped.
 
 :line
 
-2.7 LAMMPS screen output :h4,link(2_7)
+2.7 LAMMPS screen output :h4,link(start_7)
 
 As LAMMPS reads an input script, it prints information to both the
 screen and a log file about significant actions it takes to setup a
@@ -945,154 +1127,7 @@ communication, roughly 75% in the example above.
 
 :line
 
-2.8 Running on GPUs :h4,link(2_8)
-
-A few LAMMPS "pair styles"_pair_style.html can be run on graphical
-processing units (GPUs).  We plan to add more over time.  Currently,
-they only support NVIDIA GPU cards.  To use them you need to install
-certain NVIDIA CUDA software on your system:
-
-Check if you have an NVIDIA card: cat /proc/driver/nvidia/cards/0
-Go to http://www.nvidia.com/object/cuda_get.html
-Install a driver and toolkit appropriate for your system (SDK is not necessary)
-Follow the instructions in README in lammps/lib/gpu to build the library.
-Run lammps/lib/gpu/nvc_get_devices to list supported devices and properties :ul
-
-GPU configuration :h4
-
-When using GPUs, you are restricted to one physical GPU per LAMMPS
-process. Multiple processes can share a single GPU and in many cases it
-will be more efficient to run with multiple processes per GPU. Any GPU
-accelerated style requires that "fix gpu"_fix_gpu.html be used in the
-input script to select and initialize the GPUs. The format for the fix
-is:
-
-fix {name} all gpu {mode} {first} {last} {split} :pre
-
-where {name} is the name for the fix. The gpu fix must be the first
-fix specified for a given run, otherwise the program will exit
-with an error. The gpu fix will not have any effect on runs 
-that do not use GPU acceleration; there should be no problem
-with specifying the fix first in any input script.
-
-{mode} can be either "force" or "force/neigh". In the former,
-neighbor list calculation is performed on the CPU using the
-standard LAMMPS routines. In the latter, the neighbor list
-calculation is performed on the GPU. The GPU neighbor list
-can be used for better performance, however, it 
-should not be used with a triclinic box.
-
-There are cases when it might be more efficient to select the CPU for neighbor
-list builds. If a non-GPU enabled style requires a neighbor list, it will also
-be built using CPU routines. Redundant CPU and GPU neighbor list calculations
-will typically be less efficient. For "hybrid"_pair_hybrid.html pair
-styles, GPU calculated neighbor lists might be less efficient because
-no particles will be skipped in a given neighbor list.
-
-{first} is the ID (as reported by lammps/lib/gpu/nvc_get_devices)
-of the first GPU that will be used on each node. {last} is the
-ID of the last GPU that will be used on each node. If you have
-only one GPU per node, {first} and {last} will typically both be
-0. Selecting a non-sequential set of GPU IDs (e.g. 0,1,3)
-is not currently supported.
-
-{split} is the fraction of particles whose forces, torques,
-energies, and/or virials will be calculated on the GPU. This
-can be used to perform CPU and GPU force calculations
-simultaneously. If {split} is negative, the software will
-attempt to calculate the optimal fraction automatically 
-every 25 timesteps based on CPU and GPU timings. Because the GPU speedups
-are dependent on the number of particles, automatic calculation of the
-split can be less efficient, but typically results in loop times
-within 20% of an optimal fixed split.
-
-If you have two GPUs per node, 8 CPU cores per node, and
-would like to run on 4 nodes with dynamic balancing of
-force calculation across CPU and GPU cores, the fix
-might be
-
-fix 0 all gpu force/neigh 0 1 -1 :pre
-
-with LAMMPS run on 32 processes. In this case, all
-CPU cores and GPU devices on the nodes would be utilized.
-Each GPU device would be shared by 4 CPU cores. The
-CPU cores would perform force calculations for some
-fraction of the particles at the same time the GPUs
-performed force calculation for the other particles.
-
-Because of the large number of cores on each GPU
-device, it might be more efficient to run on fewer
-processes per GPU when the number of particles per process
-is small (100's of particles); this can be necessary
-to keep the GPU cores busy.
-
-GPU input script :h4
-
-In order to use GPU acceleration in LAMMPS, 
-"fix_gpu"_fix_gpu.html
-should be used in order to initialize and configure the
-GPUs for use. Additionally, GPU enabled styles must be
-selected in the input script. Currently,
-this is limited to a few "pair styles"_pair_style.html.
-Some GPU-enabled styles have additional restrictions
-listed in their documentation.
-
-GPU asynchronous pair computation :h4
-
-The GPU accelerated pair styles can be used to perform
-pair style force calculation on the GPU while other 
-calculations are
-performed on the CPU. One method to do this is to specify
-a {split} in the gpu fix as described above. In this case,
-force calculation for the pair style will also be performed
-on the CPU. 
-
-When the CPU work in a GPU pair style has finished,
-the next force computation will begin, possibly before the
-GPU has finished. If {split} is 1.0 in the gpu fix, the next
-force computation will begin almost immediately. This can
-be used to run a "hybrid"_pair_hybrid.html GPU pair style at 
-the same time as a hybrid CPU pair style. In this case, the 
-GPU pair style should be first in the hybrid command in order to
-perform simultaneous calculations. This also
-allows "bond"_bond_style.html, "angle"_angle_style.html, 
-"dihedral"_dihedral_style.html, "improper"_improper_style.html, 
-and "long-range"_kspace_style.html force
-computations to be run simultaneously with the GPU pair style.
-Once all CPU force computations have completed, the gpu fix
-will block until the GPU has finished all work before continuing
-the run.
-
-GPU timing :h4
-
-GPU accelerated pair styles can perform computations asynchronously
-with CPU computations. The "Pair" time reported by LAMMPS
-will be the maximum of the time required to complete the CPU
-pair style computations and the time required to complete the GPU
-pair style computations. Any time spent for GPU-enabled pair styles
-for computations that run simultaneously with "bond"_bond_style.html, 
-"angle"_angle_style.html, "dihedral"_dihedral_style.html, 
-"improper"_improper_style.html, and "long-range"_kspace_style.html calculations
-will not be included in the "Pair" time.
-
-When {mode} for the gpu fix is force/neigh,
-the time for neighbor list calculations on the GPU will be added
-into the "Pair" time, not the "Neigh" time. A breakdown of the
-times required for various tasks on the GPU (data copy, neighbor
-calculations, force computations, etc.) are output only
-with the LAMMPS screen output at the end of each run. These timings represent
-total time spent on the GPU for each routine, regardless of asynchronous
-CPU calculations.
-
-GPU single vs double precision :h4
-
-See the lammps/lib/gpu/README file for instructions on how to build 
-the LAMMPS gpu library for single, mixed, and double precision.  The latter
-requires that your GPU card supports double precision. 
-
-:line
-
-2.9 Tips for users of previous LAMMPS versions :h4,link(2_9)
+2.8 Tips for users of previous LAMMPS versions :h4,link(start_8)
 
 The current C++ began with a complete rewrite of LAMMPS 2001, which
 was written in F90.  Features of earlier versions of LAMMPS are listed
diff --git a/doc/Section_tools.html b/doc/Section_tools.html
index c9468af1d7..3f9efb0c7e 100644
--- a/doc/Section_tools.html
+++ b/doc/Section_tools.html
@@ -11,7 +11,7 @@ Section
 
 
            
 
-
            7. Additional tools 
+
            9. Additional tools 
 
            
 
            LAMMPS is designed to be a computational kernel for performing
 molecular dynamics computations.  Additional pre- and post-processing
@@ -56,7 +56,6 @@ own sub-directories with their own Makefiles.
 
          • ipp
 
          • lmp2arc
 
          • lmp2cfg
-
          • lmp2traj
 
          • lmp2vmd
 
          • matlab
 
          • micelle2d
@@ -251,18 +250,6 @@ the README file for more information.
 
            
 
            
 
-
            lmp2traj tool 
-
            
-
            The lmp2traj sub-directory contains a tool for converting LAMMPS output
-files into 3 analysis files.  One file can be used to create contour
-maps of the atom positions over the course of the simulation. The
-other two files provide density profiles and dipole moments.  See the
-README file for more information.
-
            
-
            This tool was written by Ara Kooser at Sandia (askoose at sandia.gov).
-
            
-
            
-
 
            lmp2vmd tool 
 
            
 
            The lmp2vmd sub-directory contains a README.txt file that describes
diff --git a/doc/Section_tools.txt b/doc/Section_tools.txt
index b1aff56261..05a4fe65c0 100644
--- a/doc/Section_tools.txt
+++ b/doc/Section_tools.txt
@@ -8,7 +8,7 @@ Section"_Section_modify.html :c
 
 :line
 
-7. Additional tools :h3
+9. Additional tools :h3
 
 LAMMPS is designed to be a computational kernel for performing
 molecular dynamics computations.  Additional pre- and post-processing
@@ -52,7 +52,6 @@ own sub-directories with their own Makefiles.
 "ipp"_#ipp
 "lmp2arc"_#arc
 "lmp2cfg"_#cfg
-"lmp2traj"_#traj
 "lmp2vmd"_#vmd
 "matlab"_#matlab
 "micelle2d"_#micelle
@@ -247,18 +246,6 @@ This tool was written by Ara Kooser at Sandia (askoose at sandia.gov).
 
 :line
 
-lmp2traj tool :h4,link(traj)
-
-The lmp2traj sub-directory contains a tool for converting LAMMPS output
-files into 3 analysis files.  One file can be used to create contour
-maps of the atom positions over the course of the simulation. The
-other two files provide density profiles and dipole moments.  See the
-README file for more information.
-
-This tool was written by Ara Kooser at Sandia (askoose at sandia.gov).
-
-:line
-
 lmp2vmd tool :h4,link(vmd)
 
 The lmp2vmd sub-directory contains a README.txt file that describes
diff --git a/doc/USER/sph/SPH_LAMMPS_userguide.pdf b/doc/USER/sph/SPH_LAMMPS_userguide.pdf
new file mode 100755
index 0000000000..7ca4a72910
Binary files /dev/null and b/doc/USER/sph/SPH_LAMMPS_userguide.pdf differ
diff --git a/doc/angle_charmm.html b/doc/angle_charmm.html
index 116098fa52..3109127730 100644
--- a/doc/angle_charmm.html
+++ b/doc/angle_charmm.html
@@ -11,6 +11,8 @@
 
 
            angle_style charmm command 
 
            
+
            angle_style charmm/omp command 
+
            
 
            Syntax:
 
            
 
            angle_style charmm 
@@ -46,10 +48,34 @@ or read_restart commands:
 
            Theta0 is specified in degrees, but LAMMPS converts it to radians
 internally; hence the units of K are in energy/radian^2.
 
            
+
            
+
+
            Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
            
+
            These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
            
+
            You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
            
+
            See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
            
+
            
+
 
            Restrictions:
 
            
 
            This angle style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the Making
+MOLECULAR package (which it is by default).  See the Making
 LAMMPS section for more info on packages.
 
            
 
            Related commands:
diff --git a/doc/angle_charmm.txt b/doc/angle_charmm.txt
index e1356cb061..f980d516e0 100644
--- a/doc/angle_charmm.txt
+++ b/doc/angle_charmm.txt
@@ -7,6 +7,7 @@
 :line
 
 angle_style charmm command :h3
+angle_style charmm/omp command :h3
 
 [Syntax:]
 
@@ -43,11 +44,35 @@ r_ub (distance) :ul
 Theta0 is specified in degrees, but LAMMPS converts it to radians
 internally; hence the units of K are in energy/radian^2.
 
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restrictions:]
 
 This angle style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info on packages.
+MOLECULAR package (which it is by default).  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]
 
diff --git a/doc/angle_class2.html b/doc/angle_class2.html
index b96f490e6d..e80f4d733c 100644
--- a/doc/angle_class2.html
+++ b/doc/angle_class2.html
@@ -11,6 +11,8 @@
 
 
            angle_style class2 command 
 
            
+
            angle_style class2/omp command 
+
            
 
            Syntax:
 
            
 
            angle_style class2 
@@ -78,11 +80,35 @@ the angle type.
 
            The theta0 value in the Eba formula is not specified, since it is the
 same value from the Ea formula.
 
            
+
            
+
+
            Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
            
+
            These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
            
+
            You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
            
+
            See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
            
+
            
+
 
            Restrictions:
 
            
-
            This angle style can only be used if LAMMPS was built with the
-"class2" package.  See the Making LAMMPS
-section for more info on packages.
+
            This angle style can only be used if LAMMPS was built with the CLASS2
+package.  See the Making LAMMPS section
+for more info on packages.
 
            
 
            Related commands:
 
            
diff --git a/doc/angle_class2.txt b/doc/angle_class2.txt
index 25719ceff4..f9d48f4efd 100644
--- a/doc/angle_class2.txt
+++ b/doc/angle_class2.txt
@@ -7,6 +7,7 @@
 :line
 
 angle_style class2 command :h3
+angle_style class2/omp command :h3
 
 [Syntax:]
 
@@ -75,11 +76,35 @@ r2 (distance) :ul
 The theta0 value in the Eba formula is not specified, since it is the
 same value from the Ea formula.
 
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restrictions:]
 
-This angle style can only be used if LAMMPS was built with the
-"class2" package.  See the "Making LAMMPS"_Section_start.html#2_3
-section for more info on packages.
+This angle style can only be used if LAMMPS was built with the CLASS2
+package.  See the "Making LAMMPS"_Section_start.html#start_3 section
+for more info on packages.
 
 [Related commands:]
 
diff --git a/doc/angle_coeff.html b/doc/angle_coeff.html
index 942ba500a6..a49967155d 100644
--- a/doc/angle_coeff.html
+++ b/doc/angle_coeff.html
@@ -81,7 +81,7 @@ specified by the associated angle_coeff command
 
          
 
          There are also additional angle styles submitted by users which are
 included in the LAMMPS distribution.  The list of these with links to
-the individual styles are given in the angle section of this
+the individual styles are given in the angle section of this
 page.
 
          
 
          
diff --git a/doc/angle_coeff.txt b/doc/angle_coeff.txt
index 08ed66db24..091ebb4e4e 100644
--- a/doc/angle_coeff.txt
+++ b/doc/angle_coeff.txt
@@ -79,7 +79,7 @@ specified by the associated "angle_coeff"_angle_coeff.html command:
 There are also additional angle styles submitted by users which are
 included in the LAMMPS distribution.  The list of these with links to
 the individual styles are given in the angle section of "this
-page"_Section_commands.html#3_5.
+page"_Section_commands.html#cmd_5.
 
 :line
 
diff --git a/doc/angle_cosine.html b/doc/angle_cosine.html
index ebd6df2234..cb3c29304d 100644
--- a/doc/angle_cosine.html
+++ b/doc/angle_cosine.html
@@ -11,6 +11,8 @@
 
 
          angle_style cosine command 
 
          
+
          angle_style cosine/omp command 
+
          
 
          Syntax:
 
          
 
          angle_style cosine 
@@ -35,10 +37,34 @@ or read_restart commands:
 
          
 
          • K (energy) 
 
          
+
          
+
+
          Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
          
+
          These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
          
+
          You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
          
+
          See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
          
+
          
+
 
          Restrictions:
 
          
 
          This angle style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the Making
+MOLECULAR package (which it is by default).  See the Making
 LAMMPS section for more info on packages.
 
          
 
          Related commands:
diff --git a/doc/angle_cosine.txt b/doc/angle_cosine.txt
index 4c6cef912f..80a380d502 100644
--- a/doc/angle_cosine.txt
+++ b/doc/angle_cosine.txt
@@ -7,6 +7,7 @@
 :line
 
 angle_style cosine command :h3
+angle_style cosine/omp command :h3
 
 [Syntax:]
 
@@ -32,11 +33,35 @@ or "read_restart"_read_restart.html commands:
 
 K (energy) :ul
 
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restrictions:]
 
 This angle style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info on packages.
+MOLECULAR package (which it is by default).  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]
 
diff --git a/doc/angle_cosine_delta.html b/doc/angle_cosine_delta.html
index 354c684fce..1b034e85e8 100644
--- a/doc/angle_cosine_delta.html
+++ b/doc/angle_cosine_delta.html
@@ -11,6 +11,8 @@
 
 
          angle_style cosine/delta command 
 
          
+
          angle_style cosine/delta/omp command 
+
          
 
          Syntax:
 
          
 
          angle_style cosine/delta 
@@ -40,10 +42,34 @@ or read_restart commands:
 
          Theta0 is specified in degrees, but LAMMPS converts it to radians
 internally.
 
          
+
          
+
+
          Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
          
+
          These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
          
+
          You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
          
+
          See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
          
+
          
+
 
          Restrictions:
 
          
 
          This angle style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the Making
+MOLECULAR package (which it is by default).  See the Making
 LAMMPS section for more info on packages.
 
          
 
          Related commands:
diff --git a/doc/angle_cosine_delta.txt b/doc/angle_cosine_delta.txt
index afa431690d..38128b9dab 100644
--- a/doc/angle_cosine_delta.txt
+++ b/doc/angle_cosine_delta.txt
@@ -7,6 +7,7 @@
 :line
 
 angle_style cosine/delta command :h3
+angle_style cosine/delta/omp command :h3
 
 [Syntax:]
 
@@ -37,11 +38,35 @@ theta0 (degrees) :ul
 Theta0 is specified in degrees, but LAMMPS converts it to radians
 internally.
 
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restrictions:]
 
 This angle style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info on packages.
+MOLECULAR package (which it is by default).  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]
 
diff --git a/doc/angle_cosine_periodic.html b/doc/angle_cosine_periodic.html
index e8b3d464bf..1078488fcc 100644
--- a/doc/angle_cosine_periodic.html
+++ b/doc/angle_cosine_periodic.html
@@ -11,6 +11,8 @@
 
 
          angle_style cosine/periodic command 
 
          
+
          angle_style cosine/periodic/omp command 
+
          
 
          Syntax:
 
          
 
          angle_style cosine/periodic 
@@ -23,10 +25,10 @@ angle_coeff * 75.0 1 6
 
          Description:
 
          
 
          The cosine/periodic angle style uses the following potential, which
-is commonly used in the DREIDING force field,
-particularly for organometallic systems where n = 4 might be used
-for an octahedral complex and n = 3 might be used for a trigonal
-center:
+is commonly used in the DREIDING force
+field, particularly for organometallic systems where n = 4 might be
+used for an octahedral complex and n = 3 might be used for a
+trigonal center:
 
          
 
          
 
          
@@ -48,10 +50,34 @@ constant K = C / n^2.  When B = 1, it leads to a minimum for the
 linear geometry.  When B = -1, it leads to a maximum for the linear
 geometry.
 
          
+
          
+
+
          Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
          
+
          These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
          
+
          You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
          
+
          See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
          
+
          
+
 
          Restrictions:
 
          
 
          This angle style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the Making
+MOLECULAR package (which it is by default).  See the Making
 LAMMPS section for more info on packages.
 
          
 
          Related commands:
diff --git a/doc/angle_cosine_periodic.txt b/doc/angle_cosine_periodic.txt
index 63a8fc52cd..8c3ac1bb3d 100644
--- a/doc/angle_cosine_periodic.txt
+++ b/doc/angle_cosine_periodic.txt
@@ -7,6 +7,7 @@
 :line
 
 angle_style cosine/periodic command :h3
+angle_style cosine/periodic/omp command :h3
 
 [Syntax:]
 
@@ -20,10 +21,10 @@ angle_coeff * 75.0 1 6 :pre
 [Description:]
 
 The {cosine/periodic} angle style uses the following potential, which
-is commonly used in the "DREIDING"_Section_howto.html#4_4 force field,
-particularly for organometallic systems where {n} = 4 might be used
-for an octahedral complex and {n} = 3 might be used for a trigonal
-center:
+is commonly used in the "DREIDING"_Section_howto.html#howto_4 force
+field, particularly for organometallic systems where {n} = 4 might be
+used for an octahedral complex and {n} = 3 might be used for a
+trigonal center:
 
 :c,image(Eqs/angle_cosine_periodic.jpg)
 
@@ -45,11 +46,35 @@ constant K = C / n^2.  When B = 1, it leads to a minimum for the
 linear geometry.  When B = -1, it leads to a maximum for the linear
 geometry.
 
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restrictions:]
 
 This angle style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info on packages.
+MOLECULAR package (which it is by default).  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]
 
diff --git a/doc/angle_cosine_shift.html b/doc/angle_cosine_shift.html
new file mode 100644
index 0000000000..b20940c567
--- /dev/null
+++ b/doc/angle_cosine_shift.html
@@ -0,0 +1,80 @@
+
+
          LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
          
+
+
+
+
+
+
+
          
+
+
          angle_style cosine/shift command 
+
          
+
          angle_style cosine/shift/omp command 
+
          
+
          Syntax:
+
          
+
          angle_style cosine/shift 
+
          
+
          Examples:
+
          
+
          angle_style cosine/shift
+angle_coeff * 10.0 45.0 
+
          
+
          Description:
+
          
+
          The cosine/shift angle style uses the potential
+
          
+
          
+
          
+
          where theta0 is the equilibrium angle. The potential is bounded
+between -Umin and zero. In the neighborhood of the minimum E=- Umin +
+Umin/4(theta-theta0)^2 hence the spring constant is umin/2.
+
          
+
          The following coefficients must be defined for each angle type via the
+angle_coeff command as in the example above, or in
+the data file or restart files read by the read_data
+or read_restart commands:
+
          
+
          • umin (energy)
+
          • theta (angle) 
+
          
+
          
+
+
          Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
          
+
          These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
          
+
          You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
          
+
          See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
          
+
          
+
+
          Restrictions:
+
          
+
          This angle style can only be used if LAMMPS was built with the
+USER-MISC package.  See the Making LAMMPS
+section for more info on packages.
+
          
+
          Related commands:
+
          
+
          angle_coeff,
+angle_cosineshiftexp
+
          
+
          Default: none
+
          
+
diff --git a/doc/angle_cosine_shift.txt b/doc/angle_cosine_shift.txt
new file mode 100644
index 0000000000..40fa449470
--- /dev/null
+++ b/doc/angle_cosine_shift.txt
@@ -0,0 +1,74 @@
+"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
+
+angle_style cosine/shift command :h3
+angle_style cosine/shift/omp command :h3
+
+[Syntax:]
+
+angle_style cosine/shift :pre
+
+[Examples:]
+
+angle_style cosine/shift
+angle_coeff * 10.0 45.0 :pre
+
+[Description:]
+
+The {cosine/shift} angle style uses the potential
+
+:c,image(Eqs/angle_cosine_shift.jpg)
+
+where theta0 is the equilibrium angle. The potential is bounded
+between -Umin and zero. In the neighborhood of the minimum E=- Umin +
+Umin/4(theta-theta0)^2 hence the spring constant is umin/2.
+
+The following coefficients must be defined for each angle type via the
+"angle_coeff"_angle_coeff.html command as in the example above, or in
+the data file or restart files read by the "read_data"_read_data.html
+or "read_restart"_read_restart.html commands:
+
+umin (energy)
+theta (angle) :ul
+
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
+[Restrictions:]
+
+This angle style can only be used if LAMMPS was built with the
+USER-MISC package.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info on packages.
+
+[Related commands:]
+
+"angle_coeff"_angle_coeff.html,
+"angle_cosineshiftexp"_angle_cosineshiftexp.html
+
+[Default:] none
diff --git a/doc/angle_cosine_shift_exp.html b/doc/angle_cosine_shift_exp.html
new file mode 100644
index 0000000000..8540a8e84d
--- /dev/null
+++ b/doc/angle_cosine_shift_exp.html
@@ -0,0 +1,93 @@
+
+
          LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
          
+
+
+
+
+
+
+
          
+
+
          angle_style cosine/shift/exp command 
+
          
+
          angle_style cosine/shift/exp/omp command 
+
          
+
          Syntax:
+
          
+
          angle_style cosine/shift/exp 
+
          
+
          Examples:
+
          
+
          angle_style cosine/shift/exp
+angle_coeff * 10.0 45.0 2.0 
+
          
+
          Description:
+
          
+
          The cosine/shift/exp angle style uses the potential
+
          
+
          
+
          
+
          where Umin, theta, and a are defined for each angle type.
+
          
+
          The potential is bounded between [-Umin:0] and the minimum is
+located at the angle theta0. The a parameter can be both positive or
+negative and is used to control the spring constant at the
+equilibrium.
+
          
+
          The spring constant is given by k = A exp(A) Umin / [2 (Exp(a)-1)].
+For a > 3, k/Umin = a/2 to better than 5% relative error. For negative
+values of the a parameter, the spring constant is essentially zero,
+and anharmonic terms takes over. The potential is furthermore well
+behaved in the limit a -> 0, where it has been implemented to linear
+order in a for a < 0.001. In this limit the potential reduces to the
+cosineshifted potential.
+
          
+
          The following coefficients must be defined for each angle type via the
+angle_coeff command as in the example above, or in
+the data file or restart files read by the read_data
+or read_restart commands:
+
          
+
          • umin (energy)
+
          • theta (angle)
+
          • A (real number) 
+
          
+
          
+
+
          Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
          
+
          These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
          
+
          You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
          
+
          See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
          
+
          
+
+
          Restrictions:
+
          
+
          This angle style can only be used if LAMMPS was built with the
+USER-MISC package.  See the Making LAMMPS
+section for more info on packages.
+
          
+
          Related commands:
+
          
+
          angle_coeff,
+angle_cosineshift,
+dihedral_cosineshift
+
          
+
          Default: none
+
          
+
diff --git a/doc/angle_cosine_shift_exp.txt b/doc/angle_cosine_shift_exp.txt
new file mode 100644
index 0000000000..46f4758955
--- /dev/null
+++ b/doc/angle_cosine_shift_exp.txt
@@ -0,0 +1,87 @@
+"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
+
+angle_style cosine/shift/exp command :h3
+angle_style cosine/shift/exp/omp command :h3
+
+[Syntax:]
+
+angle_style cosine/shift/exp :pre
+
+[Examples:]
+
+angle_style cosine/shift/exp
+angle_coeff * 10.0 45.0 2.0 :pre
+
+[Description:]
+
+The {cosine/shift/exp} angle style uses the potential
+
+:c,image(Eqs/angle_cosine_shift_exp.jpg)
+
+where Umin, theta, and a are defined for each angle type.
+
+The potential is bounded between \[-Umin:0\] and the minimum is
+located at the angle theta0. The a parameter can be both positive or
+negative and is used to control the spring constant at the
+equilibrium.
+
+The spring constant is given by k = A exp(A) Umin / \[2 (Exp(a)-1)\].
+For a > 3, k/Umin = a/2 to better than 5% relative error. For negative
+values of the a parameter, the spring constant is essentially zero,
+and anharmonic terms takes over. The potential is furthermore well
+behaved in the limit a -> 0, where it has been implemented to linear
+order in a for a < 0.001. In this limit the potential reduces to the
+cosineshifted potential.
+
+The following coefficients must be defined for each angle type via the
+"angle_coeff"_angle_coeff.html command as in the example above, or in
+the data file or restart files read by the "read_data"_read_data.html
+or "read_restart"_read_restart.html commands:
+
+umin (energy)
+theta (angle)
+A (real number) :ul
+
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
+[Restrictions:]
+
+This angle style can only be used if LAMMPS was built with the
+USER-MISC package.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info on packages.
+
+[Related commands:]
+
+"angle_coeff"_angle_coeff.html,
+"angle_cosineshift"_angle_cosineshift.html,
+"dihedral_cosineshift"_dihedral_cosineshift.html
+
+[Default:] none
diff --git a/doc/angle_cosine_squared.html b/doc/angle_cosine_squared.html
index 333b6469cb..d2440aeee9 100644
--- a/doc/angle_cosine_squared.html
+++ b/doc/angle_cosine_squared.html
@@ -11,6 +11,8 @@
 
 
          angle_style cosine/squared command 
 
          
+
          angle_style cosine/squared/omp command 
+
          
 
          Syntax:
 
          
 
          angle_style cosine/squared 
@@ -40,10 +42,34 @@ or read_restart commands:
 
          Theta0 is specified in degrees, but LAMMPS converts it to radians
 internally.
 
          
+
          
+
+
          Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
          
+
          These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
          
+
          You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
          
+
          See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
          
+
          
+
 
          Restrictions:
 
          
 
          This angle style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the Making
+MOLECULAR package (which it is by default).  See the Making
 LAMMPS section for more info on packages.
 
          
 
          Related commands:
diff --git a/doc/angle_cosine_squared.txt b/doc/angle_cosine_squared.txt
index d39623ed31..d313a1b340 100644
--- a/doc/angle_cosine_squared.txt
+++ b/doc/angle_cosine_squared.txt
@@ -7,6 +7,7 @@
 :line
 
 angle_style cosine/squared command :h3
+angle_style cosine/squared/omp command :h3
 
 [Syntax:]
 
@@ -37,11 +38,35 @@ theta0 (degrees) :ul
 Theta0 is specified in degrees, but LAMMPS converts it to radians
 internally.
 
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restrictions:]
 
 This angle style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info on packages.
+MOLECULAR package (which it is by default).  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]
 
diff --git a/doc/angle_harmonic.html b/doc/angle_harmonic.html
index d8691f63de..ca1c1662f0 100644
--- a/doc/angle_harmonic.html
+++ b/doc/angle_harmonic.html
@@ -11,6 +11,8 @@
 
 
          angle_style harmonic command 
 
          
+
          angle_style harmonic/omp command 
+
          
 
          Syntax:
 
          
 
          angle_style harmonic 
@@ -40,10 +42,34 @@ or read_restart commands:
 
          Theta0 is specified in degrees, but LAMMPS converts it to radians
 internally; hence the units of K are in energy/radian^2.
 
          
+
          
+
+
          Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
          
+
          These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
          
+
          You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
          
+
          See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
          
+
          
+
 
          Restrictions: none
 
          
 
          This angle style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the Making
+MOLECULAR package (which it is by default).  See the Making
 LAMMPS section for more info on packages.
 
          
 
          Related commands:
diff --git a/doc/angle_harmonic.txt b/doc/angle_harmonic.txt
index dc98882ee9..45deb90e4f 100644
--- a/doc/angle_harmonic.txt
+++ b/doc/angle_harmonic.txt
@@ -7,6 +7,7 @@
 :line
 
 angle_style harmonic command :h3
+angle_style harmonic/omp command :h3
 
 [Syntax:]
 
@@ -37,11 +38,35 @@ theta0 (degrees) :ul
 Theta0 is specified in degrees, but LAMMPS converts it to radians
 internally; hence the units of K are in energy/radian^2.
 
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restrictions:] none
 
 This angle style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info on packages.
+MOLECULAR package (which it is by default).  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]
 
diff --git a/doc/angle_hybrid.html b/doc/angle_hybrid.html
index 97e9163539..9a4571a11e 100644
--- a/doc/angle_hybrid.html
+++ b/doc/angle_hybrid.html
@@ -20,7 +20,7 @@
 
          Examples:
 
          
 
          angle_style hybrid harmonic cosine
-angle_coeff 1 harmonic 80.0 1.2
+angle_coeff 1 harmonic 80.0 30.0
 angle_coeff 2* cosine 50.0  
 
          
 
          Description:
@@ -33,28 +33,53 @@ type 2) could be computed with a cosine potential.  The assignment
 of angle type to style is made via the angle_coeff
 command or in the data file.
 
          
-
          In the angle_coeff command, the first coefficient sets the angle style
-and the remaining coefficients are those appropriate to that style.
-In the example above, the 2 angle_coeff commands would set angles of
-angle type 1 to be computed with a harmonic potential with
-coefficients 80.0, 1.2 for K, r0.  All other angle types (2-N) would
-be computed with a cosine potential with coefficient 50.0 for K.
+
          In the angle_coeff commands, the name of an angle style must be added
+after the angle type, with the remaining coefficients being those
+appropriate to that style.  In the example above, the 2 angle_coeff
+commands set angles of angle type 1 to be computed with a harmonic
+potential with coefficients 80.0, 30.0 for K, theta0.  All other angle
+types (2-N) are computed with a cosine potential with coefficient
+50.0 for K.
 
          
-
          If the angle class2 potential is one of the hybrid styles, it
-requires additional BondBond and BondAngle coefficients be specified
-in the data file.  These lines must also have an additional "class2"
-argument added after the angle type.  For angle types which are
-assigned to other hybrid styles, use the style name (e.g. "harmonic")
-appropriate to that style.  The BondBond and BondAngle coeffs for that
-angle type will then be ignored.
+
          If angle coefficients are specified in the data file read via the
+read_data command, then the same rule applies.
+E.g. "harmonic" or "cosine", must be added after the angle type, for each
+line in the "Angle Coeffs" section, e.g.
 
          
-
          An angle style of none can be specified as the 2nd argument to the
-angle_coeff command, if you desire to turn off certain angle types.
+
          Angle Coeffs 
+
          
+
          1 harmonic 80.0 30.0
+2 cosine 50.0
+... 
+
          
+
          If class2 is one of the angle hybrid styles, the same rule holds for
+specifying additional BondBond (and BondAngle) coefficients either via
+the input script or in the data file.  I.e. class2 must be added to
+each line after the angle type.  For lines in the BondBond (or
+BondAngle) section of the data file for angle types that are not
+class2, you must use an angle style of skip as a placeholder, e.g.
 
          
+
          BondBond Coeffs 
+
          
+
          1 skip
+2 class2 3.6512 1.0119 1.0119
+... 
+
          
+
          Note that it is not necessary to use the angle style skip in the
+input script, since BondBond (or BondAngle) coefficients need not be
+specified at all for angle types that are not class2.
+
          
+
          An angle style of none with no additional coefficients can be used
+in place of an angle style, either in a input script angle_coeff
+command or in the data file, if you desire to turn off interactions
+for specific angle types.
+
          
+
          
+
 
          Restrictions:
 
          
 
          This angle style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the Making
+MOLECULAR package (which it is by default).  See the Making
 LAMMPS section for more info on packages.
 
          
 
          Unlike other angle styles, the hybrid angle style does not store angle
diff --git a/doc/angle_hybrid.txt b/doc/angle_hybrid.txt
index 7e6a2f27e6..4f500a0700 100644
--- a/doc/angle_hybrid.txt
+++ b/doc/angle_hybrid.txt
@@ -17,7 +17,7 @@ style1,style2 = list of one or more angle styles :ul
 [Examples:]
 
 angle_style hybrid harmonic cosine
-angle_coeff 1 harmonic 80.0 1.2
+angle_coeff 1 harmonic 80.0 30.0
 angle_coeff 2* cosine 50.0  :pre
 
 [Description:]
@@ -30,29 +30,54 @@ type 2) could be computed with a {cosine} potential.  The assignment
 of angle type to style is made via the "angle_coeff"_angle_coeff.html
 command or in the data file.
 
-In the angle_coeff command, the first coefficient sets the angle style
-and the remaining coefficients are those appropriate to that style.
-In the example above, the 2 angle_coeff commands would set angles of
-angle type 1 to be computed with a {harmonic} potential with
-coefficients 80.0, 1.2 for K, r0.  All other angle types (2-N) would
-be computed with a {cosine} potential with coefficient 50.0 for K.
+In the angle_coeff commands, the name of an angle style must be added
+after the angle type, with the remaining coefficients being those
+appropriate to that style.  In the example above, the 2 angle_coeff
+commands set angles of angle type 1 to be computed with a {harmonic}
+potential with coefficients 80.0, 30.0 for K, theta0.  All other angle
+types (2-N) are computed with a {cosine} potential with coefficient
+50.0 for K.
 
-If the angle {class2} potential is one of the hybrid styles, it
-requires additional BondBond and BondAngle coefficients be specified
-in the data file.  These lines must also have an additional "class2"
-argument added after the angle type.  For angle types which are
-assigned to other hybrid styles, use the style name (e.g. "harmonic")
-appropriate to that style.  The BondBond and BondAngle coeffs for that
-angle type will then be ignored.
+If angle coefficients are specified in the data file read via the
+"read_data"_read_data.html command, then the same rule applies.
+E.g. "harmonic" or "cosine", must be added after the angle type, for each
+line in the "Angle Coeffs" section, e.g.
 
-An angle style of {none} can be specified as the 2nd argument to the
-angle_coeff command, if you desire to turn off certain angle types.
+Angle Coeffs :pre
+
+1 harmonic 80.0 30.0
+2 cosine 50.0
+... :pre
+
+If {class2} is one of the angle hybrid styles, the same rule holds for
+specifying additional BondBond (and BondAngle) coefficients either via
+the input script or in the data file.  I.e. {class2} must be added to
+each line after the angle type.  For lines in the BondBond (or
+BondAngle) section of the data file for angle types that are not
+{class2}, you must use an angle style of {skip} as a placeholder, e.g.
+
+BondBond Coeffs :pre
+
+1 skip
+2 class2 3.6512 1.0119 1.0119
+... :pre
+
+Note that it is not necessary to use the angle style {skip} in the
+input script, since BondBond (or BondAngle) coefficients need not be
+specified at all for angle types that are not {class2}.
+
+An angle style of {none} with no additional coefficients can be used
+in place of an angle style, either in a input script angle_coeff
+command or in the data file, if you desire to turn off interactions
+for specific angle types.
+
+:line
 
 [Restrictions:]
 
 This angle style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info on packages.
+MOLECULAR package (which it is by default).  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 Unlike other angle styles, the hybrid angle style does not store angle
 coefficient info for individual sub-styles in a "binary restart
diff --git a/doc/angle_cmm.html b/doc/angle_sdk.html
similarity index 57%
rename from doc/angle_cmm.html
rename to doc/angle_sdk.html
index d994d98a6d..fa1b5f37dc 100644
--- a/doc/angle_cmm.html
+++ b/doc/angle_sdk.html
@@ -9,56 +9,55 @@
 
 
          
 
-
          angle_style cg/cmm command 
+
          angle_style sdk command 
 
          
 
          Syntax:
 
          
-
          angle_style cg/cmm 
+
          angle_style sdk 
+
          
+
          angle_style sdk/omp 
 
          
 
          Examples:
 
          
-
          angle_style cg/cmm
-angle_coeff 1 300.0 107.0 lj9_6 0.4491 3.7130 
+
          angle_style sdk
+angle_coeff 1 300.0 107.0 
 
          
 
          Description:
 
          
-
          The cg/cmm angle style is a combination of the harmonic angle potential,
+
          The sdk angle style is a combination of the harmonic angle potential,
 
          
 
          
 
          
 
          where theta0 is the equilibrium value of the angle and K a prefactor,
-with the repulsive part of the non-bonded cg/cmm pair style
+with the repulsive part of the non-bonded lj/sdk pair style
 between the atoms 1 and 3.  This angle potential is intended for
 coarse grained MD simulations with the CMM parametrization using the
-pair_style cg/cmm.  Relative to the pair_style
-cg/cmm, however, the energy is shifted by epsilon, to avoid sudden
+pair_style lj/sdk.  Relative to the pair_style
+lj/sdk, however, the energy is shifted by epsilon, to avoid sudden
 jumps.  Note that the usual 1/2 factor is included in K.
 
          
 
          The following coefficients must be defined for each angle type via the
-angle_coeff command as in the example above. As
-with other CMM coarse grained parameters, they cannot be set in the
-data file, but can be restored from restarts via the
-read_restart command:
+angle_coeff command as in the example above:
 
          
 
          • K (energy/radian^2)
-
          • theta0 (degrees)
-
          • cg_type (string, one of lj9_6, lj12_4, lj12_6)
-
          • epsilon (energy units)
-
          • sigma (distance units) 
+
          • theta0 (degrees) 
 
          
 
          Theta0 is specified in degrees, but LAMMPS converts it to radians
 internally; hence the units of K are in energy/radian^2.
+The also required lj/sdk parameters will be extracted automatically
+from the pair_style.
 
          
 
          Restrictions: 
 
          
 
          This angle style can only be used if LAMMPS was built with the
-"user-cg-cmm" package.  See the Making LAMMPS section 
-for more info on packages.
+USER-CG-CMM package.  See the Making
+LAMMPS section for more info on packages.
 
          
 
          Related commands:
 
          
 
          angle_coeff, angle_style
-harmonic, pair_style cg/cmm
+harmonic, pair_style lj/sdk,
+pair_style lj/sdk/coul/long
 
          
 
          Default: none
 
          
diff --git a/doc/angle_cmm.txt b/doc/angle_sdk.txt
similarity index 50%
rename from doc/angle_cmm.txt
rename to doc/angle_sdk.txt
index 69eaa1dbe7..3c70d42236 100644
--- a/doc/angle_cmm.txt
+++ b/doc/angle_sdk.txt
@@ -6,55 +6,53 @@
 
 :line
 
-angle_style cg/cmm command :h3
+angle_style sdk command :h3
 
 [Syntax:]
 
-angle_style cg/cmm :pre
+angle_style sdk :pre
+angle_style sdk/omp :pre
 
 [Examples:]
 
-angle_style cg/cmm
-angle_coeff 1 300.0 107.0 lj9_6 0.4491 3.7130 :pre
+angle_style sdk
+angle_coeff 1 300.0 107.0 :pre
 
 [Description:]
 
-The {cg/cmm} angle style is a combination of the harmonic angle potential,
+The {sdk} angle style is a combination of the harmonic angle potential,
 
 :c,image(Eqs/angle_harmonic.jpg)
 
 where theta0 is the equilibrium value of the angle and K a prefactor,
-with the {repulsive} part of the non-bonded {cg/cmm} pair style
+with the {repulsive} part of the non-bonded {lj/sdk} pair style
 between the atoms 1 and 3.  This angle potential is intended for
 coarse grained MD simulations with the CMM parametrization using the
-"pair_style cg/cmm"_pair_cmm.html.  Relative to the pair_style
-{cg/cmm}, however, the energy is shifted by {epsilon}, to avoid sudden
+"pair_style lj/sdk"_pair_sdk.html.  Relative to the pair_style
+{lj/sdk}, however, the energy is shifted by {epsilon}, to avoid sudden
 jumps.  Note that the usual 1/2 factor is included in K.
 
 The following coefficients must be defined for each angle type via the
-"angle_coeff"_angle_coeff.html command as in the example above. As
-with other CMM coarse grained parameters, they cannot be set in the
-data file, but can be restored from restarts via the
-"read_restart"_read_restart.html command:
+"angle_coeff"_angle_coeff.html command as in the example above:
 
 K (energy/radian^2)
-theta0 (degrees)
-cg_type (string, one of lj9_6, lj12_4, lj12_6)
-epsilon (energy units)
-sigma (distance units) :ul
+theta0 (degrees) :ul
 
 Theta0 is specified in degrees, but LAMMPS converts it to radians
 internally; hence the units of K are in energy/radian^2.
+The also required {lj/sdk} parameters will be extracted automatically
+from the pair_style.
 
 [Restrictions:] 
 
 This angle style can only be used if LAMMPS was built with the
-"user-cg-cmm" package.  See the "Making LAMMPS"_Section_start.html#2_3 section 
-for more info on packages.
+USER-CG-CMM package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]
 
 "angle_coeff"_angle_coeff.html, "angle_style
-harmonic"_angle_harmonic.html, "pair_style cg/cmm"_pair_cmm.html
+harmonic"_angle_harmonic.html, "pair_style lj/sdk"_pair_sdk.html,
+"pair_style lj/sdk/coul/long"_pair_sdk.html
 
 [Default:] none
diff --git a/doc/angle_style.html b/doc/angle_style.html
index 7ec349b11a..73e016b001 100644
--- a/doc/angle_style.html
+++ b/doc/angle_style.html
@@ -73,7 +73,7 @@ specified by the associated angle_coeff command
 
        
 
        There are also additional angle styles submitted by users which are
 included in the LAMMPS distribution.  The list of these with links to
-the individual styles are given in the angle section of this
+the individual styles are given in the angle section of this
 page.
 
        
 
        
@@ -83,10 +83,10 @@ page.
 
        Angle styles can only be set for atom_styles that allow angles to be
 defined.
 
        
-
        Most angle styles are part of the "molecular" package.  They are only
-enabled if LAMMPS was built with that package.  See the Making
-LAMMPS section for more info on packages.  The
-doc pages for individual bond potentials tell if it is part of a
+
        Most angle styles are part of the MOLECULAR package.  They are only
+enabled if LAMMPS was built with that package.  See the Making
+LAMMPS section for more info on packages.
+The doc pages for individual bond potentials tell if it is part of a
 package.
 
        
 
        Related commands:
diff --git a/doc/angle_style.txt b/doc/angle_style.txt
index aca79433e7..ec4f923079 100644
--- a/doc/angle_style.txt
+++ b/doc/angle_style.txt
@@ -72,7 +72,7 @@ specified by the associated "angle_coeff"_angle_coeff.html command:
 There are also additional angle styles submitted by users which are
 included in the LAMMPS distribution.  The list of these with links to
 the individual styles are given in the angle section of "this
-page"_Section_commands.html#3_5.
+page"_Section_commands.html#cmd_5.
 
 :line
 
@@ -81,10 +81,10 @@ page"_Section_commands.html#3_5.
 Angle styles can only be set for atom_styles that allow angles to be
 defined.
 
-Most angle styles are part of the "molecular" package.  They are only
+Most angle styles are part of the MOLECULAR package.  They are only
 enabled if LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info on packages.  The
-doc pages for individual bond potentials tell if it is part of a
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
+The doc pages for individual bond potentials tell if it is part of a
 package.
 
 [Related commands:]
diff --git a/doc/angle_table.html b/doc/angle_table.html
index 7248683509..f9cc6701a5 100644
--- a/doc/angle_table.html
+++ b/doc/angle_table.html
@@ -11,6 +11,8 @@
 
 
        angle_style table command 
 
        
+
        angle_style table/omp command 
+
        
 
        Syntax:
 
        
 
        angle_style table style N 
@@ -121,10 +123,34 @@ with 180.0, i.e. span the full range of possible angles.
 potential.  LAMMPS reads the file section by section until it finds
 one that matches the specified keyword.
 
        
+
        
+
+
        Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
        
+
        These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
        
+
        You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
        
+
        See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
        
+
        
+
 
        Restrictions:
 
        
 
        This angle style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the Making
+MOLECULAR package (which it is by default).  See the Making
 LAMMPS section for more info on packages.
 
        
 
        Related commands:
diff --git a/doc/angle_table.txt b/doc/angle_table.txt
index 3a0494dbba..21ef6b2451 100644
--- a/doc/angle_table.txt
+++ b/doc/angle_table.txt
@@ -7,6 +7,7 @@
 :line
 
 angle_style table command :h3
+angle_style table/omp command :h3
 
 [Syntax:]
 
@@ -118,11 +119,35 @@ Note that one file can contain many sections, each with a tabulated
 potential.  LAMMPS reads the file section by section until it finds
 one that matches the specified keyword.
 
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restrictions:]
 
 This angle style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info on packages.
+MOLECULAR package (which it is by default).  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]
 
diff --git a/doc/atom_style.html b/doc/atom_style.html
index 6f421609ba..77ca19b72f 100644
--- a/doc/atom_style.html
+++ b/doc/atom_style.html
@@ -15,7 +15,7 @@
 
        
 
        atom_style style args 
 
        
-
        • style = angle or atomic or bond or charge or colloid or dipole or         electron or ellipsoid or full or granular or molecular or 	peri or hybrid 
+
          • style = angle or atomic or bond or charge or dipole or         electron or ellipsoid or full or line or meso or 	molecular or peri or sphere or tri or hybrid 
 
          
 
            args = none for any style except hybrid
   hybrid args = list of one or more sub-styles 
@@ -57,36 +57,62 @@ quantities.
 atomic  only the default values  coarse-grain liquids, solids, metals 
 bond  bonds  bead-spring polymers 
 charge  charge  atomic system with charges 
-colloid  angular velocity  extended spherical particles 
-dipole  charge and dipole moment  atomic system with dipoles 
+dipole  charge and dipole moment  system with dipolar particles 
 electron  charge and spin and eradius  electronic force field 
-ellipsoid  quaternion for particle orientation, angular momentum  extended aspherical particles 
+ellipsoid  shape, quaternion for particle orientation, angular momentum  extended aspherical particles 
 full  molecular + charge  bio-molecules 
-granular  diameter, density, angular velocity  granular models 
+line  end points, angular velocity  rigid bodies 
+meso  rho, e, cv  SPH particles 
 molecular  bonds, angles, dihedrals, impropers  uncharged molecules 
-peri  density, volume  mesocopic Peridynamic models 
+peri  mass, volume  mesocopic Peridynamic models 
+sphere  diameter, mass, angular velocity  granular models 
+tri  corner points, angular momentum  rigid bodies 
+wavepacket  charge, spin, eradius, etag, cs_re, cs_im  AWPMD 
 
 
-
          All of the styles define point particles, except the colloid,
-dipole, electron, ellipsoid, granular, and peri styles,
-which define finite-size particles.  For colloid, dipole, and
-ellipsoid systems, the shape command is used to specify
-the size and shape of particles on a per-type basis, which is
-spherical for colloid and dipole particles and spherical or
-aspherical for ellipsoid particles.  For granular systems, the
-particles are spherical and each has a per-particle specified
-diameter.  For peri systems, the particles are spherical and each
-has a per-particle specified volume.  For electron systems, the
-particles representing electrons are three dimensional Gaussians with
-a specified position and bandwidth or uncertainty in position, which
-is represented by the eradius = electron size.
-
          
 
          All of the styles assign mass to particles on a per-type basis, using
-the mass command, except the granular and peri styles
-which assign mass on a per-particle basis.  For granular systems,
-the specified diameter and density are used to calculate each
-particle's mass.  For peri systems, the speficied volume and density
-are used to calculate each particle's mass.
+the mass command, except for the finite-size particle
+styles discussed below.  They assign mass on a per-atom basis.
+
          
+
          All of the styles define point particles, except the sphere,
+ellipsoid, electron, peri, wavepacket, line, and tri
+styles, which define finite-size particles.
+
          
+
          For the sphere style, the particles are spheres and each stores a
+per-particle diameter and mass.  If the diameter > 0.0, the particle
+is a finite-size sphere.  If the diameter = 0.0, it is a point
+particle.
+
          
+
          For the ellipsoid style, the particles are ellipsoids and each
+stores a flag which indicates whether it is a finite-size ellipsoid or
+a point particle.  If it is an ellipsoid, it also stores a shape
+vector with the 3 diamters of the ellipsoid and a quaternion 4-vector
+with its orientation.
+
          
+
          For the electron style, the particles representing electrons are 3d
+Gaussians with a specified position and bandwidth or uncertainty in
+position, which is represented by the eradius = electron size.
+
          
+
          For the peri style, the particles are spherical and each stores a
+per-particle mass and volume.
+
          
+
          The meso style is for smoothed particle hydrodynamics (SPH)
+particles which store a density (rho), energy (e), and heat capacity
+(cv).
+
          
+
          The wavepacket style is similar to electron, but the electrons may
+consist of several Gaussian wave packets, summed up with coefficients
+cs= (cs_re,cs_im).  Each of the wave packets is treated as a separate
+particle in LAMMPS, wave packets belonging to the same electron must
+have identical etag values.
+
          
+
          For the line style, the particles are idealized line segments and
+each stores a per-particle mass and length and orientation (i.e. the
+end points of the line segment).
+
          
+
          For the tri style, the particles are planar triangles and each
+stores a per-particle mass and size and orientation (i.e. the corner
+points of the triangle).
 
          
 
          
 
@@ -99,10 +125,10 @@ If some atoms have bonds, but others do not, use the bond style.
 
          
 
          The only scenario where the hybrid style is needed is if there is no
 single style which defines all needed properties of all atoms.  For
-example, if you want colloidal particles with charge, you would need
-to use "atom_style hybrid colloid charge".  When a hybrid style is
-used, atoms store and communicate the union of all quantities implied
-by the individual styles.
+example, if you want dipolar particles which will be torqued and
+rotate, you would need to use "atom_style hybrid sphere dipole".  When
+a hybrid style is used, atoms store and communicate the union of all
+quantities implied by the individual styles.
 
          
 
          LAMMPS can be extended with new atom styles; see this
 section.
@@ -113,14 +139,16 @@ section.
 read_data or create_box command.
 
          
 
          The angle, bond, full, and molecular styles are part of the
-"molecular" package.  The granular style is part of the "granular"
-package.  The colloid style is part of the "colloid" package.  The
-dipole style is part of the "dipole" package.  The ellipsoid style
-is part of the "asphere" package.  The peri style is part of the
-"peri" package for Peridynamics.  The electron style is part of the
-"user-eff" package for electronic force fields.  They
-are only enabled if LAMMPS was built with that package.  See the
-Making LAMMPS section for more info.
+MOLECULAR package.  The dipole style is part of the "dipole"
+package.  The peri style is part of the PERI package for
+Peridynamics.  The electron style is part of the USER-EFF package
+for electronic force fields.  The meso style is part
+of the USER-SPH package for smoothed particle hydrodyanmics (SPH).
+See this PDF guide to using SPH in
+LAMMPS.  The wavepacket style is part of the USER-AWPMD package for
+the antisymmetrized wave packet MD method.  They are
+only enabled if LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
 
          
 
          Related commands:
 
          
diff --git a/doc/atom_style.txt b/doc/atom_style.txt
index b6987e9ffe..ee0375927f 100644
--- a/doc/atom_style.txt
+++ b/doc/atom_style.txt
@@ -12,9 +12,9 @@ atom_style command :h3
 
 atom_style style args :pre
 
-style = {angle} or {atomic} or {bond} or {charge} or {colloid} or {dipole} or \
-        {electron} or {ellipsoid} or {full} or {granular} or {molecular} or \
-	{peri} or {hybrid} :ul
+style = {angle} or {atomic} or {bond} or {charge} or {dipole} or \
+        {electron} or {ellipsoid} or {full} or {line} or {meso} or \
+	{molecular} or {peri} or {sphere} or {tri} or {hybrid} :ul
   args = none for any style except {hybrid}
   {hybrid} args = list of one or more sub-styles :pre
 
@@ -54,35 +54,61 @@ quantities.
 {atomic} | only the default values | coarse-grain liquids, solids, metals |
 {bond} | bonds | bead-spring polymers |
 {charge} | charge | atomic system with charges |
-{colloid} | angular velocity | extended spherical particles |
-{dipole} | charge and dipole moment | atomic system with dipoles |
+{dipole} | charge and dipole moment | system with dipolar particles |
 {electron} | charge and spin and eradius | electronic force field |
-{ellipsoid} | quaternion for particle orientation, angular momentum | extended aspherical particles |
+{ellipsoid} | shape, quaternion for particle orientation, angular momentum | extended aspherical particles |
 {full} | molecular + charge | bio-molecules |
-{granular} | diameter, density, angular velocity | granular models |
+{line} | end points, angular velocity | rigid bodies |
+{meso} | rho, e, cv | SPH particles |
 {molecular} | bonds, angles, dihedrals, impropers | uncharged molecules |
-{peri} | density, volume | mesocopic Peridynamic models :tb(c=3,s=|)
-
-All of the styles define point particles, except the {colloid},
-{dipole}, {electron}, {ellipsoid}, {granular}, and {peri} styles,
-which define finite-size particles.  For {colloid}, {dipole}, and
-{ellipsoid} systems, the "shape"_shape.html command is used to specify
-the size and shape of particles on a per-type basis, which is
-spherical for {colloid} and {dipole} particles and spherical or
-aspherical for {ellipsoid} particles.  For {granular} systems, the
-particles are spherical and each has a per-particle specified
-diameter.  For {peri} systems, the particles are spherical and each
-has a per-particle specified volume.  For {electron} systems, the
-particles representing electrons are three dimensional Gaussians with
-a specified position and bandwidth or uncertainty in position, which
-is represented by the eradius = electron size.
+{peri} | mass, volume | mesocopic Peridynamic models |
+{sphere} | diameter, mass, angular velocity | granular models |
+{tri} | corner points, angular momentum | rigid bodies |
+{wavepacket} | charge, spin, eradius, etag, cs_re, cs_im | AWPMD :tb(c=3,s=|)
 
 All of the styles assign mass to particles on a per-type basis, using
-the "mass"_mass.html command, except the {granular} and {peri} styles
-which assign mass on a per-particle basis.  For {granular} systems,
-the specified diameter and density are used to calculate each
-particle's mass.  For {peri} systems, the speficied volume and density
-are used to calculate each particle's mass.
+the "mass"_mass.html command, except for the finite-size particle
+styles discussed below.  They assign mass on a per-atom basis.
+
+All of the styles define point particles, except the {sphere},
+{ellipsoid}, {electron}, {peri}, {wavepacket}, {line}, and {tri}
+styles, which define finite-size particles.
+
+For the {sphere} style, the particles are spheres and each stores a
+per-particle diameter and mass.  If the diameter > 0.0, the particle
+is a finite-size sphere.  If the diameter = 0.0, it is a point
+particle.
+
+For the {ellipsoid} style, the particles are ellipsoids and each
+stores a flag which indicates whether it is a finite-size ellipsoid or
+a point particle.  If it is an ellipsoid, it also stores a shape
+vector with the 3 diamters of the ellipsoid and a quaternion 4-vector
+with its orientation.
+
+For the {electron} style, the particles representing electrons are 3d
+Gaussians with a specified position and bandwidth or uncertainty in
+position, which is represented by the eradius = electron size.
+
+For the {peri} style, the particles are spherical and each stores a
+per-particle mass and volume.
+
+The {meso} style is for smoothed particle hydrodynamics (SPH)
+particles which store a density (rho), energy (e), and heat capacity
+(cv).
+
+The {wavepacket} style is similar to {electron}, but the electrons may
+consist of several Gaussian wave packets, summed up with coefficients
+cs= (cs_re,cs_im).  Each of the wave packets is treated as a separate
+particle in LAMMPS, wave packets belonging to the same electron must
+have identical {etag} values.
+
+For the {line} style, the particles are idealized line segments and
+each stores a per-particle mass and length and orientation (i.e. the
+end points of the line segment).
+
+For the {tri} style, the particles are planar triangles and each
+stores a per-particle mass and size and orientation (i.e. the corner
+points of the triangle).
 
 :line
 
@@ -95,10 +121,10 @@ If some atoms have bonds, but others do not, use the {bond} style.
 
 The only scenario where the {hybrid} style is needed is if there is no
 single style which defines all needed properties of all atoms.  For
-example, if you want colloidal particles with charge, you would need
-to use "atom_style hybrid colloid charge".  When a hybrid style is
-used, atoms store and communicate the union of all quantities implied
-by the individual styles.
+example, if you want dipolar particles which will be torqued and
+rotate, you would need to use "atom_style hybrid sphere dipole".  When
+a hybrid style is used, atoms store and communicate the union of all
+quantities implied by the individual styles.
 
 LAMMPS can be extended with new atom styles; see "this
 section"_Section_modify.html.
@@ -109,14 +135,16 @@ This command cannot be used after the simulation box is defined by a
 "read_data"_read_data.html or "create_box"_create_box.html command.
 
 The {angle}, {bond}, {full}, and {molecular} styles are part of the
-"molecular" package.  The {granular} style is part of the "granular"
-package.  The {colloid} style is part of the "colloid" package.  The
-{dipole} style is part of the "dipole" package.  The {ellipsoid} style
-is part of the "asphere" package.  The {peri} style is part of the
-"peri" package for Peridynamics.  The {electron} style is part of the
-"user-eff" package for "electronic force fields"_pair_eff.html.  They
-are only enabled if LAMMPS was built with that package.  See the
-"Making LAMMPS"_Section_start.html#2_3 section for more info.
+MOLECULAR package.  The {dipole} style is part of the "dipole"
+package.  The {peri} style is part of the PERI package for
+Peridynamics.  The {electron} style is part of the USER-EFF package
+for "electronic force fields"_pair_eff.html.  The {meso} style is part
+of the USER-SPH package for smoothed particle hydrodyanmics (SPH).
+See "this PDF guide"_USER/sph/SPH_LAMMPS_userguide.pdf to using SPH in
+LAMMPS.  The {wavepacket} style is part of the USER-AWPMD package for
+the "antisymmetrized wave packet MD method"_pair_awpmd.html.  They are
+only enabled if LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
 
 [Related commands:]
 
diff --git a/doc/bond_class2.html b/doc/bond_class2.html
index cb3ff9f5ac..b9178e7678 100644
--- a/doc/bond_class2.html
+++ b/doc/bond_class2.html
@@ -11,6 +11,8 @@
 
 
          bond_style class2 command 
 
          
+
          bond_style class2/omp command 
+
          
 
          Syntax:
 
          
 
          bond_style class2 
@@ -40,11 +42,35 @@ or read_restart commands:
 
        • K3 (energy/distance^3)
 
        • K4 (energy/distance^4) 
 
        
+
        
+
+
        Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
        
+
        These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
        
+
        You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
        
+
        See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
        
+
        
+
 
        Restrictions:
 
        
-
        This bond style can only be used if LAMMPS was built with the "class2"
-package.  See the Making LAMMPS section for
-more info on packages.
+
        This bond style can only be used if LAMMPS was built with the CLASS2
+package.  See the Making LAMMPS section
+for more info on packages.
 
        
 
        Related commands:
 
        
diff --git a/doc/bond_class2.txt b/doc/bond_class2.txt
index fa70494819..fa9c6bb25c 100644
--- a/doc/bond_class2.txt
+++ b/doc/bond_class2.txt
@@ -7,6 +7,7 @@
 :line
 
 bond_style class2 command :h3
+bond_style class2/omp command :h3
 
 [Syntax:]
 
@@ -37,11 +38,35 @@ K2 (energy/distance^2)
 K3 (energy/distance^3)
 K4 (energy/distance^4) :ul
 
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restrictions:]
 
-This bond style can only be used if LAMMPS was built with the "class2"
-package.  See the "Making LAMMPS"_Section_start.html#2_3 section for
-more info on packages.
+This bond style can only be used if LAMMPS was built with the CLASS2
+package.  See the "Making LAMMPS"_Section_start.html#start_3 section
+for more info on packages.
 
 [Related commands:]
 
diff --git a/doc/bond_coeff.html b/doc/bond_coeff.html
index 434f0fb3d4..58ce6406a0 100644
--- a/doc/bond_coeff.html
+++ b/doc/bond_coeff.html
@@ -77,7 +77,7 @@ specified by the associated bond_coeff command:
 
      
 
      There are also additional bond styles submitted by users which are
 included in the LAMMPS distribution.  The list of these with links to
-the individual styles are given in the bond section of this
+the individual styles are given in the bond section of this
 page.
 
      
 
      
diff --git a/doc/bond_coeff.txt b/doc/bond_coeff.txt
index 737d5e2abe..25110e9166 100644
--- a/doc/bond_coeff.txt
+++ b/doc/bond_coeff.txt
@@ -75,7 +75,7 @@ specified by the associated "bond_coeff"_bond_coeff.html command:
 There are also additional bond styles submitted by users which are
 included in the LAMMPS distribution.  The list of these with links to
 the individual styles are given in the bond section of "this
-page"_Section_commands.html#3_5.
+page"_Section_commands.html#cmd_5.
 
 :line
 
diff --git a/doc/bond_fene.html b/doc/bond_fene.html
index 4dcc2447f8..8d837185f2 100644
--- a/doc/bond_fene.html
+++ b/doc/bond_fene.html
@@ -11,6 +11,8 @@
 
 
      bond_style fene command 
 
      
+
      bond_style fene/omp command 
+
      
 
      Syntax:
 
      
 
      bond_style fene 
@@ -42,10 +44,34 @@ or read_restart commands:
 
    • epsilon (energy)
 
    • sigma (distance)
    +
    + +

    Styles with a cuda, gpu, omp, or opt suffix are functionally +the same as the corresponding style without the suffix. They have +been optimized to run faster, depending on your available hardware, +as discussed in this section of the manual. +The accelerated styles take the same arguments and should produce the +same results, except for round-off and precision issues. +

    +

    These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT +packages, respectively. They are only enabled if LAMMPS was built with +those packages. See the Making LAMMPS +section for more info. +

    +

    You can specify the accelerated styles explicitly in your input script +by including their suffix, or you can use the -suffix command-line +switch when you invoke LAMMPS, or you can +use the suffix command in your input script. +

    +

    See this section of the manual for more +instructions on how to use the accelerated styles effectively. +

    +
    +

    Restrictions:

    This bond style can only be used if LAMMPS was built with the -"molecular" package (which it is by default). See the Making +MOLECULAR package (which it is by default). See the Making LAMMPS section for more info on packages.

    You typically should specify special_bonds fene diff --git a/doc/bond_fene.txt b/doc/bond_fene.txt index 8d0ab6c254..0ed8bb737e 100644 --- a/doc/bond_fene.txt +++ b/doc/bond_fene.txt @@ -7,6 +7,7 @@ :line bond_style fene command :h3 +bond_style fene/omp command :h3 [Syntax:] @@ -39,11 +40,35 @@ R0 (distance) epsilon (energy) sigma (distance) :ul +:line + +Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally +the same as the corresponding style without the suffix. They have +been optimized to run faster, depending on your available hardware, +as discussed in "this section"_Section_accelerate.html of the manual. +The accelerated styles take the same arguments and should produce the +same results, except for round-off and precision issues. + +These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT +packages, respectively. They are only enabled if LAMMPS was built with +those packages. See the "Making LAMMPS"_Section_start.html#start_3 +section for more info. + +You can specify the accelerated styles explicitly in your input script +by including their suffix, or you can use the "-suffix command-line +switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can +use the "suffix"_suffix.html command in your input script. + +See "this section"_Section_accelerate.html of the manual for more +instructions on how to use the accelerated styles effectively. + +:line + [Restrictions:] This bond style can only be used if LAMMPS was built with the -"molecular" package (which it is by default). See the "Making -LAMMPS"_Section_start.html#2_3 section for more info on packages. +MOLECULAR package (which it is by default). See the "Making +LAMMPS"_Section_start.html#start_3 section for more info on packages. You typically should specify "special_bonds fene"_special_bonds.html" or "special_bonds lj/coul 0 1 1"_special_bonds.html to use this bond diff --git a/doc/bond_fene_expand.html b/doc/bond_fene_expand.html index 190e14ca31..0d8856914b 100644 --- a/doc/bond_fene_expand.html +++ b/doc/bond_fene_expand.html @@ -11,6 +11,8 @@

    bond_style fene/expand command

    +

    bond_style fene/expand/omp command +

    Syntax: 

    bond_style fene/expand 
@@ -47,10 +49,34 @@ or read_restart commands:
 
  • sigma (distance)
 
  • delta (distance) 
 
+
    
+
+
    Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
 
    Restrictions:
 
    
 
    This bond style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the Making
+MOLECULAR package (which it is by default).  See the Making
 LAMMPS section for more info on packages.
 
    
 
    You typically should specify special_bonds fene
diff --git a/doc/bond_fene_expand.txt b/doc/bond_fene_expand.txt
index b12bb6de07..8738f2b6a6 100644
--- a/doc/bond_fene_expand.txt
+++ b/doc/bond_fene_expand.txt
@@ -7,6 +7,7 @@
 :line
 
 bond_style fene/expand command :h3
+bond_style fene/expand/omp command :h3
 
 [Syntax:]
 
@@ -44,11 +45,35 @@ epsilon (energy)
 sigma (distance)
 delta (distance) :ul
 
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restrictions:]
 
 This bond style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info on packages.
+MOLECULAR package (which it is by default).  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 You typically should specify "special_bonds fene"_special_bonds.html"
 or "special_bonds lj/coul 0 1 1"_special_bonds.html to use this bond
diff --git a/doc/bond_harmonic.html b/doc/bond_harmonic.html
index 37fd7f8cdb..34d1dce346 100644
--- a/doc/bond_harmonic.html
+++ b/doc/bond_harmonic.html
@@ -11,6 +11,8 @@
 
 
    bond_style harmonic command 
 
    
+
    bond_style harmonic/omp command 
+
    
 
    Syntax:
 
    
 
    bond_style harmonic 
@@ -37,10 +39,34 @@ or read_restart commands:
 
    • K (energy/distance^2)
 
    • r0 (distance) 
 
    
+
    
+
+
    Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
 
    Restrictions:
 
    
 
    This bond style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the Making
+MOLECULAR package (which it is by default).  See the Making
 LAMMPS section for more info on packages.
 
    
 
    Related commands:
diff --git a/doc/bond_harmonic.txt b/doc/bond_harmonic.txt
index 1ccbbd4f45..fa60049054 100644
--- a/doc/bond_harmonic.txt
+++ b/doc/bond_harmonic.txt
@@ -7,6 +7,7 @@
 :line
 
 bond_style harmonic command :h3
+bond_style harmonic/omp command :h3
 
 [Syntax:]
 
@@ -34,11 +35,35 @@ or "read_restart"_read_restart.html commands:
 K (energy/distance^2)
 r0 (distance) :ul
 
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restrictions:]
 
 This bond style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info on packages.
+MOLECULAR package (which it is by default).  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]
 
diff --git a/doc/bond_harmonic_shift.html b/doc/bond_harmonic_shift.html
new file mode 100644
index 0000000000..6c2647b189
--- /dev/null
+++ b/doc/bond_harmonic_shift.html
@@ -0,0 +1,84 @@
+
+
    LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
    
+
+
+
+
+
+
+
    
+
+
    bond_style harmonic/shift command 
+
    
+
    bond_style harmonic/shift/omp command 
+
    
+
    Syntax:
+
    
+
    bond_style harmonic/shift 
+
    
+
    Examples:
+
    
+
    bond_style harmonic/shift
+bond_coeff 5 10.0 0.5 1.0 
+
    
+
    Description:
+
    
+
    The harmonic/shift bond style is a shifted harmonic bond that uses
+the potential
+
    
+
    
+
    
+
    where r0 is the equilibrium bond distance, and rc the critical distance.
+The potential is -Umin at r0 and zero at rc. The spring constant is
+k = Umin / [ 2 (r0-rc)^2].
+
    
+
    The following coefficients must be defined for each bond type via the
+bond_coeff command as in the example above, or in
+the data file or restart files read by the read_data
+or read_restart commands:
+
    
+
    • Umin (energy) 
+
    
+
    • r0 (distance) 
+
    
+
    • rc (distance) 
+
    
+
    
+
+
    Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
+
    Restrictions:
+
    
+
    This bond style can only be used if LAMMPS was built with the
+USER-MISC package.  See the Making LAMMPS
+section for more info on packages.
+
    
+
    Related commands:
+
    
+
    bond_coeff, delete_bonds,
+bond_harmonic
+
    
+
    Default: none
+
    
+
diff --git a/doc/bond_harmonic_shift.txt b/doc/bond_harmonic_shift.txt
new file mode 100644
index 0000000000..1a72a6c74c
--- /dev/null
+++ b/doc/bond_harmonic_shift.txt
@@ -0,0 +1,76 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+bond_style harmonic/shift command :h3
+bond_style harmonic/shift/omp command :h3
+
+[Syntax:]
+
+bond_style harmonic/shift :pre
+
+[Examples:]
+
+bond_style harmonic/shift
+bond_coeff 5 10.0 0.5 1.0 :pre
+
+[Description:]
+
+The {harmonic/shift} bond style is a shifted harmonic bond that uses
+the potential
+
+:c,image(Eqs/bond_harmonic_shift.jpg)
+
+where r0 is the equilibrium bond distance, and rc the critical distance.
+The potential is -Umin at r0 and zero at rc. The spring constant is
+k = Umin / \[ 2 (r0-rc)^2\].
+
+The following coefficients must be defined for each bond type via the
+"bond_coeff"_bond_coeff.html command as in the example above, or in
+the data file or restart files read by the "read_data"_read_data.html
+or "read_restart"_read_restart.html commands:
+
+Umin (energy) :ul
+r0 (distance) :ul
+rc (distance) :ul
+
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
+[Restrictions:]
+
+This bond style can only be used if LAMMPS was built with the
+USER-MISC package.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info on packages.
+
+[Related commands:]
+
+"bond_coeff"_bond_coeff.html, "delete_bonds"_delete_bonds.html,
+"bond_harmonic"_bond_harmonic.html
+
+[Default:] none
diff --git a/doc/bond_harmonic_shift_cut.html b/doc/bond_harmonic_shift_cut.html
new file mode 100644
index 0000000000..7af0c24101
--- /dev/null
+++ b/doc/bond_harmonic_shift_cut.html
@@ -0,0 +1,83 @@
+
+
    LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
    
+
+
+
+
+
+
+
    
+
+
    bond_style harmonic/shift/cut command 
+
    
+
    bond_style harmonic/shift/cut/omp command 
+
    
+
    Syntax:
+
    
+
    bond_style harmonic/shift/cut 
+
    
+
    Examples:
+
    
+
    bond_style harmonic/shift/cut
+bond_coeff 5 10.0 0.5 1.0 
+
    
+
    Description:
+
    
+
    The harmonic/shift/cut bond style is a shifted harmonic bond that
+uses the potential
+
    
+
    
+
    
+
    where r0 is the equilibrium bond distance, and rc the critical distance.
+The bond potential is zero for distances r > rc. The potential is -Umin
+at r0 and zero at rc. The spring constant is k = Umin / [ 2 (r0-rc)^2].
+
    
+
    The following coefficients must be defined for each bond type via the
+bond_coeff command as in the example above, or in
+the data file or restart files read by the read_data
+or read_restart commands:
+
    
+
    • Umin (energy)
+
    • r0 (distance)
+
    • rc (distance) 
+
    
+
    
+
+
    Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
+
    Restrictions:
+
    
+
    This bond style can only be used if LAMMPS was built with the
+USER-MISC package.  See the Making LAMMPS
+section for more info on packages.
+
    
+
    Related commands:
+
    
+
    bond_coeff, delete_bonds,
+bond_harmonic,
+bond_harmonicshift
+
    
+
    Default: none
+
    
+
diff --git a/doc/bond_harmonic_shift_cut.txt b/doc/bond_harmonic_shift_cut.txt
new file mode 100644
index 0000000000..cce6033343
--- /dev/null
+++ b/doc/bond_harmonic_shift_cut.txt
@@ -0,0 +1,77 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+bond_style harmonic/shift/cut command :h3
+bond_style harmonic/shift/cut/omp command :h3
+
+[Syntax:]
+
+bond_style harmonic/shift/cut :pre
+
+[Examples:]
+
+bond_style harmonic/shift/cut
+bond_coeff 5 10.0 0.5 1.0 :pre
+
+[Description:]
+
+The {harmonic/shift/cut} bond style is a shifted harmonic bond that
+uses the potential
+
+:c,image(Eqs/bond_harmonic_shift_cut.jpg)
+
+where r0 is the equilibrium bond distance, and rc the critical distance.
+The bond potential is zero for distances r > rc. The potential is -Umin
+at r0 and zero at rc. The spring constant is k = Umin / \[ 2 (r0-rc)^2\].
+
+The following coefficients must be defined for each bond type via the
+"bond_coeff"_bond_coeff.html command as in the example above, or in
+the data file or restart files read by the "read_data"_read_data.html
+or "read_restart"_read_restart.html commands:
+
+Umin (energy)
+r0 (distance)
+rc (distance) :ul
+
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
+[Restrictions:]
+
+This bond style can only be used if LAMMPS was built with the
+USER-MISC package.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info on packages.
+
+[Related commands:]
+
+"bond_coeff"_bond_coeff.html, "delete_bonds"_delete_bonds.html,
+"bond_harmonic"_bond_harmonic.html,
+"bond_harmonicshift"_bond_harmonicshift.html
+
+[Default:] none
diff --git a/doc/bond_hybrid.html b/doc/bond_hybrid.html
index bdf750b8f5..1d1926434f 100644
--- a/doc/bond_hybrid.html
+++ b/doc/bond_hybrid.html
@@ -33,21 +33,36 @@ be computed with a harmonic potential.  The assignment of bond type
 to style is made via the bond_coeff command or in
 the data file.
 
    
-
    In the bond_coeff command, the first coefficient sets the bond style
-and the remaining coefficients are those appropriate to that style.
-In the example above, the 2 bond_coeff commands would set bonds of
-bond type 1 to be computed with a harmonic potential with
-coefficients 80.0, 1.2 for K, r0.  All other bond types (2-N) would be
-computed with a fene potential with coefficients 30.0, 1.5, 1.0, 1.0
-for K, R0, epsilon, sigma.
+
    In the bond_coeff commands, the name of a bond style must be added
+after the bond type, with the remaining coefficients being those
+appropriate to that style.  In the example above, the 2 bond_coeff
+commands set bonds of bond type 1 to be computed with a harmonic
+potential with coefficients 80.0, 1.2 for K, r0.  All other bond types
+(2-N) are computed with a fene potential with coefficients 30.0,
+1.5, 1.0, 1.0 for K, R0, epsilon, sigma.
 
    
-
    A bond style of none can be specified as the 2nd argument to the
-bond_coeff command, if you desire to turn off certain bond types.
+
    If bond coefficients are specified in the data file read via the
+read_data command, then the same rule applies.
+E.g. "harmonic" or "fene" must be added after the bond type, for each
+line in the "Bond Coeffs" section, e.g.
 
    
+
    Bond Coeffs 
+
    
+
    1 harmonic 80.0 1.2
+2 fene 30.0 1.5 1.0 1.0
+... 
+
    
+
    A bond style of none with no additional coefficients can be used in
+place of a bond style, either in a input script bond_coeff command or
+in the data file, if you desire to turn off interactions for specific
+bond types.
+
    
+
    
+
 
    Restrictions:
 
    
 
    This bond style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the Making
+MOLECULAR package (which it is by default).  See the Making
 LAMMPS section for more info on packages.
 
    
 
    Unlike other bond styles, the hybrid bond style does not store bond
diff --git a/doc/bond_hybrid.txt b/doc/bond_hybrid.txt
index 9fb42206f2..ec3053a83f 100644
--- a/doc/bond_hybrid.txt
+++ b/doc/bond_hybrid.txt
@@ -30,22 +30,37 @@ be computed with a {harmonic} potential.  The assignment of bond type
 to style is made via the "bond_coeff"_bond_coeff.html command or in
 the data file.
 
-In the bond_coeff command, the first coefficient sets the bond style
-and the remaining coefficients are those appropriate to that style.
-In the example above, the 2 bond_coeff commands would set bonds of
-bond type 1 to be computed with a {harmonic} potential with
-coefficients 80.0, 1.2 for K, r0.  All other bond types (2-N) would be
-computed with a {fene} potential with coefficients 30.0, 1.5, 1.0, 1.0
-for K, R0, epsilon, sigma.
+In the bond_coeff commands, the name of a bond style must be added
+after the bond type, with the remaining coefficients being those
+appropriate to that style.  In the example above, the 2 bond_coeff
+commands set bonds of bond type 1 to be computed with a {harmonic}
+potential with coefficients 80.0, 1.2 for K, r0.  All other bond types
+(2-N) are computed with a {fene} potential with coefficients 30.0,
+1.5, 1.0, 1.0 for K, R0, epsilon, sigma.
 
-A bond style of {none} can be specified as the 2nd argument to the
-bond_coeff command, if you desire to turn off certain bond types.
+If bond coefficients are specified in the data file read via the
+"read_data"_read_data.html command, then the same rule applies.
+E.g. "harmonic" or "fene" must be added after the bond type, for each
+line in the "Bond Coeffs" section, e.g.
+
+Bond Coeffs :pre
+
+1 harmonic 80.0 1.2
+2 fene 30.0 1.5 1.0 1.0
+... :pre
+
+A bond style of {none} with no additional coefficients can be used in
+place of a bond style, either in a input script bond_coeff command or
+in the data file, if you desire to turn off interactions for specific
+bond types.
+
+:line
 
 [Restrictions:]
 
 This bond style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info on packages.
+MOLECULAR package (which it is by default).  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 Unlike other bond styles, the hybrid bond style does not store bond
 coefficient info for individual sub-styles in a "binary restart
diff --git a/doc/bond_morse.html b/doc/bond_morse.html
index 0d69aedc5b..bc436c26d0 100644
--- a/doc/bond_morse.html
+++ b/doc/bond_morse.html
@@ -11,6 +11,8 @@
 
 
    bond_style morse command 
 
    
+
    bond_style morse/omp command 
+
    
 
    Syntax:
 
    
 
    bond_style morse 
@@ -38,10 +40,34 @@ or read_restart commands:
 
  • alpha (inverse distance)
 
  • r0 (distance) 
 
+
    
+
+
    Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
 
    Restrictions:
 
    
 
    This bond style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the Making
+MOLECULAR package (which it is by default).  See the Making
 LAMMPS section for more info on packages.
 
    
 
    Related commands:
diff --git a/doc/bond_morse.txt b/doc/bond_morse.txt
index fd67478ef4..fdecd281fe 100644
--- a/doc/bond_morse.txt
+++ b/doc/bond_morse.txt
@@ -7,6 +7,7 @@
 :line
 
 bond_style morse command :h3
+bond_style morse/omp command :h3
 
 [Syntax:]
 
@@ -35,11 +36,35 @@ D (energy)
 alpha (inverse distance)
 r0 (distance) :ul
 
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restrictions:]
 
 This bond style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info on packages.
+MOLECULAR package (which it is by default).  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]
 
diff --git a/doc/bond_nonlinear.html b/doc/bond_nonlinear.html
index 6bbc5aedf8..bbe7778a7c 100644
--- a/doc/bond_nonlinear.html
+++ b/doc/bond_nonlinear.html
@@ -11,6 +11,8 @@
 
 
    bond_style nonlinear command 
 
    
+
    bond_style nonlinear/omp command 
+
    
 
    Syntax:
 
    
 
    bond_style nonlinear 
@@ -38,10 +40,34 @@ or read_restart commands:
 
  • r0 (distance)
 
  • lamda (distance) 
 
+
    
+
+
    Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
 
    Restrictions:
 
    
 
    This bond style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the Making
+MOLECULAR package (which it is by default).  See the Making
 LAMMPS section for more info on packages.
 
    
 
    Related commands:
diff --git a/doc/bond_nonlinear.txt b/doc/bond_nonlinear.txt
index 480109ff48..ef5f87b2b1 100644
--- a/doc/bond_nonlinear.txt
+++ b/doc/bond_nonlinear.txt
@@ -7,6 +7,7 @@
 :line
 
 bond_style nonlinear command :h3
+bond_style nonlinear/omp command :h3
 
 [Syntax:]
 
@@ -35,11 +36,35 @@ epsilon (energy)
 r0 (distance)
 lamda (distance) :ul
 
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restrictions:]
 
 This bond style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info on packages.
+MOLECULAR package (which it is by default).  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]
 
diff --git a/doc/bond_quartic.html b/doc/bond_quartic.html
index 10313c0021..fddb40acaf 100644
--- a/doc/bond_quartic.html
+++ b/doc/bond_quartic.html
@@ -11,6 +11,8 @@
 
 
    bond_style quartic command 
 
    
+
    bond_style quartic/omp command 
+
    
 
    Syntax:
 
    
 
    bond_style quartic 
@@ -73,10 +75,34 @@ status of broken bonds or permanently delete them, e.g.:
 
    delete_bonds all stats
 delete_bonds all bond 0 remove 
 
    
+
    
+
+
    Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
 
    Restrictions:
 
    
 
    This bond style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the Making
+MOLECULAR package (which it is by default).  See the Making
 LAMMPS section for more info on packages.
 
    
 
    The quartic style requires that special_bonds
diff --git a/doc/bond_quartic.txt b/doc/bond_quartic.txt
index b734d7997f..d4304f2929 100644
--- a/doc/bond_quartic.txt
+++ b/doc/bond_quartic.txt
@@ -7,6 +7,7 @@
 :line
 
 bond_style quartic command :h3
+bond_style quartic/omp command :h3
 
 [Syntax:]
 
@@ -70,11 +71,35 @@ status of broken bonds or permanently delete them, e.g.:
 delete_bonds all stats
 delete_bonds all bond 0 remove :pre
 
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restrictions:]
 
 This bond style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info on packages.
+MOLECULAR package (which it is by default).  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 The {quartic} style requires that "special_bonds"_special_bonds.html
 parameters be set to 1,1,1.  Three- and four-body interactions (angle,
diff --git a/doc/bond_style.html b/doc/bond_style.html
index 7eea795dbc..22021efc56 100644
--- a/doc/bond_style.html
+++ b/doc/bond_style.html
@@ -82,7 +82,7 @@ specified by the associated bond_coeff command:
 
 
    There are also additional bond styles submitted by users which are
 included in the LAMMPS distribution.  The list of these with links to
-the individual styles are given in the bond section of this
+the individual styles are given in the bond section of this
 page.
 
    
 
    
@@ -92,10 +92,10 @@ page.
 
    Bond styles can only be set for atom styles that allow bonds to be
 defined.
 
    
-
    Most bond styles are part of the "molecular" package.  They are only
-enabled if LAMMPS was built with that package.  See the Making
-LAMMPS section for more info on packages.  The
-doc pages for individual bond potentials tell if it is part of a
+
    Most bond styles are part of the MOLECULAR package.  They are only
+enabled if LAMMPS was built with that package.  See the Making
+LAMMPS section for more info on packages.
+The doc pages for individual bond potentials tell if it is part of a
 package.
 
    
 
    Related commands:
diff --git a/doc/bond_style.txt b/doc/bond_style.txt
index 048c64b589..f89edc2963 100644
--- a/doc/bond_style.txt
+++ b/doc/bond_style.txt
@@ -80,7 +80,7 @@ specified by the associated "bond_coeff"_bond_coeff.html command:
 There are also additional bond styles submitted by users which are
 included in the LAMMPS distribution.  The list of these with links to
 the individual styles are given in the bond section of "this
-page"_Section_commands.html#3_5.
+page"_Section_commands.html#cmd_5.
 
 :line
 
@@ -89,10 +89,10 @@ page"_Section_commands.html#3_5.
 Bond styles can only be set for atom styles that allow bonds to be
 defined.
 
-Most bond styles are part of the "molecular" package.  They are only
+Most bond styles are part of the MOLECULAR package.  They are only
 enabled if LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info on packages.  The
-doc pages for individual bond potentials tell if it is part of a
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
+The doc pages for individual bond potentials tell if it is part of a
 package.
 
 [Related commands:]
diff --git a/doc/bond_table.html b/doc/bond_table.html
index 5e36198db7..13ed4a9295 100644
--- a/doc/bond_table.html
+++ b/doc/bond_table.html
@@ -11,6 +11,8 @@
 
 
    bond_style table command 
 
    
+
    bond_style table/omp command 
+
    
 
    Syntax:
 
    
 
    bond_style table style N 
@@ -118,10 +120,34 @@ force is evaluated as if the bond were the LO or HI length.
 potential.  LAMMPS reads the file section by section until it finds
 one that matches the specified keyword.
 
    
+
    
+
+
    Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
 
    Restrictions:
 
    
 
    This bond style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the Making
+MOLECULAR package (which it is by default).  See the Making
 LAMMPS section for more info on packages.
 
    
 
    Related commands:
diff --git a/doc/bond_table.txt b/doc/bond_table.txt
index 11fbd738bf..cc70596bc3 100644
--- a/doc/bond_table.txt
+++ b/doc/bond_table.txt
@@ -7,6 +7,7 @@
 :line
 
 bond_style table command :h3
+bond_style table/omp command :h3
 
 [Syntax:]
 
@@ -115,11 +116,35 @@ Note that one file can contain many sections, each with a tabulated
 potential.  LAMMPS reads the file section by section until it finds
 one that matches the specified keyword.
 
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restrictions:]
 
 This bond style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info on packages.
+MOLECULAR package (which it is by default).  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]
 
diff --git a/doc/change_box.html b/doc/change_box.html
index 0cc459a9f4..e258ec2337 100644
--- a/doc/change_box.html
+++ b/doc/change_box.html
@@ -28,7 +28,7 @@ change_box triclinic
 
    Description:
 
    
 
    By default LAMMPS runs a simulation in an orthogonal, axis-aligned
-simulation box.  LAMMPS can also run simulations in non-orthogonal
+simulation box.  LAMMPS can also run simulations in non-orthogonal
 (triclinic) simulation boxes.  A box is
 defined as either orthogonal or non-orthogonal when it is created via
 the create_box, read_data, or
@@ -37,9 +37,9 @@ the create_box, read_
 
    This command allows you to toggle the existing simulation box from
 orthogonal to non-orthogonal and vice versa.  For example, an initial
 equilibration simulation can be run in an orthogonal box, the box can
-be toggled to non-orthogonal, and then a non-equilibrium MD (NEMD)
-simulation can be run with deformation via
-the fix deform command.
+be toggled to non-orthogonal, and then a non-equilibrium MD (NEMD)
+simulation can be run with deformation
+via the fix deform command.
 
    
 
    Note that if the simulation box is currently non-orthogonal and has
 non-zero tilt in xy, yz, or xz, then it cannot be converted to an
diff --git a/doc/change_box.txt b/doc/change_box.txt
index fc0ff37b2c..78c2c757d9 100644
--- a/doc/change_box.txt
+++ b/doc/change_box.txt
@@ -25,7 +25,7 @@ change_box triclinic :pre
 
 By default LAMMPS runs a simulation in an orthogonal, axis-aligned
 simulation box.  LAMMPS can also run simulations in "non-orthogonal
-(triclinic) simulation boxes"_Section_howto.html#4_12.  A box is
+(triclinic) simulation boxes"_Section_howto.html#howto_12.  A box is
 defined as either orthogonal or non-orthogonal when it is created via
 the "create_box"_create_box.html, "read_data"_read_data.html, or
 "read_restart"_read_restart.html commands.
@@ -34,8 +34,8 @@ This command allows you to toggle the existing simulation box from
 orthogonal to non-orthogonal and vice versa.  For example, an initial
 equilibration simulation can be run in an orthogonal box, the box can
 be toggled to non-orthogonal, and then a "non-equilibrium MD (NEMD)
-simulation"_Section_howto.html#4_13 can be run with deformation via
-the "fix deform"_fix_deform.html command.
+simulation"_Section_howto.html#howto_13 can be run with deformation
+via the "fix deform"_fix_deform.html command.
 
 Note that if the simulation box is currently non-orthogonal and has
 non-zero tilt in xy, yz, or xz, then it cannot be converted to an
diff --git a/doc/compute.html b/doc/compute.html
index 4961976758..4e3d6ffee0 100644
--- a/doc/compute.html
+++ b/doc/compute.html
@@ -36,7 +36,7 @@ information about a previous state of the system.  Defining a compute
 does not perform a computation.  Instead computes are invoked by other
 LAMMPS commands as needed, e.g. to calculate a temperature needed for
 a thermostat fix or to generate thermodynamic or dump file output.
-See this howto section for a summary of
+See this howto section for a summary of
 various LAMMPS output options, many of which involve computes.
 
    
 
    The ID of a compute can only contain alphanumeric characters and
@@ -202,6 +202,7 @@ available in LAMMPS:
 
  • rdf - radial distribution function g(r) histogram of group of atoms
 
  • reduce - combine per-atom quantities into a single global value
 
  • reduce/region - same as compute reduce, within a region
+
  • slice - extract values from global vector or array
 
  • stress/atom - stress tensor for each atom
 
  • temp - temperature of group of atoms
 
  • temp/asphere - temperature of aspherical particles
@@ -216,9 +217,14 @@ available in LAMMPS:
 
 
    There are also additional compute styles submitted by users which are
 included in the LAMMPS distribution.  The list of these with links to
-the individual styles are given in the compute section of this
+the individual styles are given in the compute section of this
 page.
 
    
+
    There are also additional accelerated compute styles included in the
+LAMMPS distribution for faster performance on CPUs and GPUs.  The list
+of these with links to the individual styles are given in the pair
+section of this page.
+
    
 
    Restrictions: none
 
    
 
    Related commands:
diff --git a/doc/compute.txt b/doc/compute.txt
index c3f435e747..2c53f5f4e6 100644
--- a/doc/compute.txt
+++ b/doc/compute.txt
@@ -33,7 +33,7 @@ information about a previous state of the system.  Defining a compute
 does not perform a computation.  Instead computes are invoked by other
 LAMMPS commands as needed, e.g. to calculate a temperature needed for
 a thermostat fix or to generate thermodynamic or dump file output.
-See this "howto section"_Section_howto.html#4_15 for a summary of
+See this "howto section"_Section_howto.html#howto_15 for a summary of
 various LAMMPS output options, many of which involve computes.
 
 The ID of a compute can only contain alphanumeric characters and
@@ -197,6 +197,7 @@ available in LAMMPS:
 "rdf"_compute_rdf.html - radial distribution function g(r) histogram of group of atoms
 "reduce"_compute_reduce.html - combine per-atom quantities into a single global value
 "reduce/region"_compute_reduce.html - same as compute reduce, within a region
+"slice"_compute_slice.html - extract values from global vector or array
 "stress/atom"_compute_stress_atom.html - stress tensor for each atom
 "temp"_compute_temp.html - temperature of group of atoms
 "temp/asphere"_compute_temp_asphere.html - temperature of aspherical particles
@@ -212,7 +213,12 @@ available in LAMMPS:
 There are also additional compute styles submitted by users which are
 included in the LAMMPS distribution.  The list of these with links to
 the individual styles are given in the compute section of "this
-page"_Section_commands.html#3_5.
+page"_Section_commands.html#cmd_5.
+
+There are also additional accelerated compute styles included in the
+LAMMPS distribution for faster performance on CPUs and GPUs.  The list
+of these with links to the individual styles are given in the pair
+section of "this page"_Section_commands.html#cmd_5.
 
 [Restrictions:] none
 
diff --git a/doc/compute_ackland_atom.html b/doc/compute_ackland_atom.html
index f9f0340169..16ad975e88 100644
--- a/doc/compute_ackland_atom.html
+++ b/doc/compute_ackland_atom.html
@@ -51,17 +51,20 @@ which computes this quantity.-
 
    
 
    Output info:
 
    
-
    This compute calculates a scalar quantity for each atom, which can be
-accessed by any command that uses per-atom values from a compute as
-input.  See this section for an overview of
-LAMMPS output options.
+
    This compute calculates a per-atom vector, which can be accessed by
+any command that uses per-atom values from a compute as input.  See
+this section for an overview of LAMMPS
+output options.
 
    
 
    Restrictions:
 
    
-
    This compute is part of the "user-ackland" package.  It is only
-enabled if LAMMPS was built with that package.  See the Making
+
    This compute is part of the USER-MISC package.  It is only enabled if
+LAMMPS was built with that package.  See the Making
 LAMMPS section for more info.
 
    
+
    The per-atom vector values will be unitless since they are the
+integers defined above.
+
    
 
    Related commands:
 
    
 
    compute centro/atom
diff --git a/doc/compute_ackland_atom.txt b/doc/compute_ackland_atom.txt
index c2fd054da1..5a9dcebbad 100644
--- a/doc/compute_ackland_atom.txt
+++ b/doc/compute_ackland_atom.txt
@@ -48,16 +48,19 @@ which computes this quantity.-
 
 [Output info:]
 
-This compute calculates a scalar quantity for each atom, which can be
-accessed by any command that uses per-atom values from a compute as
-input.  See "this section"_Section_howto.html#4_15 for an overview of
-LAMMPS output options.
+This compute calculates a per-atom vector, which can be accessed by
+any command that uses per-atom values from a compute as input.  See
+"this section"_Section_howto.html#howto_15 for an overview of LAMMPS
+output options.
 
 [Restrictions:]
 
-This compute is part of the "user-ackland" package.  It is only
-enabled if LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+This compute is part of the USER-MISC package.  It is only enabled if
+LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+The per-atom vector values will be unitless since they are the
+integers defined above.
 
 [Related commands:]
 
diff --git a/doc/compute_angle_local.html b/doc/compute_angle_local.html
index 547bc7b862..772388db4c 100644
--- a/doc/compute_angle_local.html
+++ b/doc/compute_angle_local.html
@@ -67,7 +67,7 @@ array is the number of angles.  If a single keyword is specified, a
 local vector is produced.  If two or more keywords are specified, a
 local array is produced where the number of columns = the number of
 keywords.  The vector or array can be accessed by any command that
-uses local values from a compute as input.  See this
+uses local values from a compute as input.  See this
 section for an overview of LAMMPS output
 options.
 
    
diff --git a/doc/compute_angle_local.txt b/doc/compute_angle_local.txt
index 91cf1dcdf8..253a78e8fc 100644
--- a/doc/compute_angle_local.txt
+++ b/doc/compute_angle_local.txt
@@ -60,7 +60,7 @@ local vector is produced.  If two or more keywords are specified, a
 local array is produced where the number of columns = the number of
 keywords.  The vector or array can be accessed by any command that
 uses local values from a compute as input.  See "this
-section"_Section_howto.html#4_15 for an overview of LAMMPS output
+section"_Section_howto.html#howto_15 for an overview of LAMMPS output
 options.
 
 The output for {theta} will be in degrees.  The output for {eng} will
diff --git a/doc/compute_atom_molecule.html b/doc/compute_atom_molecule.html
index 322679449d..d185c1e995 100644
--- a/doc/compute_atom_molecule.html
+++ b/doc/compute_atom_molecule.html
@@ -97,7 +97,7 @@ rows in the array is the number of molecules.  If a single input is
 specified, a global vector is produced.  If two or more inputs are
 specified, a global array is produced where the number of columns =
 the number of inputs.  The vector or array can be accessed by any
-command that uses global values from a compute as input.  See this
+command that uses global values from a compute as input.  See this
 section for an overview of LAMMPS output
 options.
 
    
diff --git a/doc/compute_atom_molecule.txt b/doc/compute_atom_molecule.txt
index d348b82563..53d4d38890 100644
--- a/doc/compute_atom_molecule.txt
+++ b/doc/compute_atom_molecule.txt
@@ -90,7 +90,7 @@ specified, a global vector is produced.  If two or more inputs are
 specified, a global array is produced where the number of columns =
 the number of inputs.  The vector or array can be accessed by any
 command that uses global values from a compute as input.  See "this
-section"_Section_howto.html#4_15 for an overview of LAMMPS output
+section"_Section_howto.html#howto_15 for an overview of LAMMPS output
 options.
 
 All the vector or array values calculated by this compute are
diff --git a/doc/compute_bond_local.html b/doc/compute_bond_local.html
index 59e647cf35..67bb43353b 100644
--- a/doc/compute_bond_local.html
+++ b/doc/compute_bond_local.html
@@ -66,7 +66,7 @@ array is the number of bonds.  If a single keyword is specified, a
 local vector is produced.  If two or more keywords are specified, a
 local array is produced where the number of columns = the number of
 keywords.  The vector or array can be accessed by any command that
-uses local values from a compute as input.  See this
+uses local values from a compute as input.  See this
 section for an overview of LAMMPS output
 options.
 
    
diff --git a/doc/compute_bond_local.txt b/doc/compute_bond_local.txt
index a7801a66fb..92768b6a5d 100644
--- a/doc/compute_bond_local.txt
+++ b/doc/compute_bond_local.txt
@@ -59,7 +59,7 @@ local vector is produced.  If two or more keywords are specified, a
 local array is produced where the number of columns = the number of
 keywords.  The vector or array can be accessed by any command that
 uses local values from a compute as input.  See "this
-section"_Section_howto.html#4_15 for an overview of LAMMPS output
+section"_Section_howto.html#howto_15 for an overview of LAMMPS output
 options.
 
 The output for {dist} will be in distance "units"_units.html.  The
diff --git a/doc/compute_centro_atom.html b/doc/compute_centro_atom.html
index caac6e53fb..63c0c2b95f 100644
--- a/doc/compute_centro_atom.html
+++ b/doc/compute_centro_atom.html
@@ -79,7 +79,7 @@ too frequently or to have multiple compute/dump commands, each with a
 
    
 
    This compute calculates a per-atom vector, which can be accessed by
 any command that uses per-atom values from a compute as input.  See
-this section for an overview of LAMMPS
+this section for an overview of LAMMPS
 output options.
 
    
 
    The per-atom vector values are unitless values >= 0.0.  Their
diff --git a/doc/compute_centro_atom.txt b/doc/compute_centro_atom.txt
index ec9dc2060d..a5a83a0c32 100644
--- a/doc/compute_centro_atom.txt
+++ b/doc/compute_centro_atom.txt
@@ -75,7 +75,7 @@ too frequently or to have multiple compute/dump commands, each with a
 
 This compute calculates a per-atom vector, which can be accessed by
 any command that uses per-atom values from a compute as input.  See
-"this section"_Section_howto.html#4_15 for an overview of LAMMPS
+"this section"_Section_howto.html#howto_15 for an overview of LAMMPS
 output options.
 
 The per-atom vector values are unitless values >= 0.0.  Their
diff --git a/doc/compute_cluster_atom.html b/doc/compute_cluster_atom.html
index 1cb85dad15..b2f7b49fdd 100644
--- a/doc/compute_cluster_atom.html
+++ b/doc/compute_cluster_atom.html
@@ -46,7 +46,7 @@ too frequently or to have multiple compute/dump commands, each of a
 
    
 
    This compute calculates a per-atom vector, which can be accessed by
 any command that uses per-atom values from a compute as input.  See
-this section for an overview of LAMMPS
+this section for an overview of LAMMPS
 output options.
 
    
 
    The per-atom vector values will be an ID > 0, as explained above.
diff --git a/doc/compute_cluster_atom.txt b/doc/compute_cluster_atom.txt
index 497417b4cd..3193331f91 100644
--- a/doc/compute_cluster_atom.txt
+++ b/doc/compute_cluster_atom.txt
@@ -43,7 +43,7 @@ too frequently or to have multiple compute/dump commands, each of a
 
 This compute calculates a per-atom vector, which can be accessed by
 any command that uses per-atom values from a compute as input.  See
-"this section"_Section_howto.html#4_15 for an overview of LAMMPS
+"this section"_Section_howto.html#howto_15 for an overview of LAMMPS
 output options.
 
 The per-atom vector values will be an ID > 0, as explained above.
diff --git a/doc/compute_cna_atom.html b/doc/compute_cna_atom.html
index 958c039127..7549fa7c6c 100644
--- a/doc/compute_cna_atom.html
+++ b/doc/compute_cna_atom.html
@@ -77,7 +77,7 @@ too frequently or to have multiple compute/dump commands, each with a
 
    
 
    This compute calculates a per-atom vector, which can be accessed by
 any command that uses per-atom values from a compute as input.  See
-this section for an overview of LAMMPS
+this section for an overview of LAMMPS
 output options.
 
    
 
    The per-atom vector values will be a number from 0 to 5, as explained
diff --git a/doc/compute_cna_atom.txt b/doc/compute_cna_atom.txt
index 8184597817..63afcf9a82 100644
--- a/doc/compute_cna_atom.txt
+++ b/doc/compute_cna_atom.txt
@@ -74,7 +74,7 @@ too frequently or to have multiple compute/dump commands, each with a
 
 This compute calculates a per-atom vector, which can be accessed by
 any command that uses per-atom values from a compute as input.  See
-"this section"_Section_howto.html#4_15 for an overview of LAMMPS
+"this section"_Section_howto.html#howto_15 for an overview of LAMMPS
 output options.
 
 The per-atom vector values will be a number from 0 to 5, as explained
diff --git a/doc/compute_com.html b/doc/compute_com.html
index 10b02794fc..b8bdb05531 100644
--- a/doc/compute_com.html
+++ b/doc/compute_com.html
@@ -52,8 +52,9 @@ file containing coordinates of the atoms in the bodies.
 
    
 
    This compute calculates a global vector of length 3, which can be
 accessed by indices 1-3 by any command that uses global vector values
-from a compute as input.  See this section
-for an overview of LAMMPS output options.
+from a compute as input.  See this
+section for an overview of LAMMPS output
+options.
 
    
 
    The vector values are "intensive".  The vector values will be in
 distance units.
diff --git a/doc/compute_com.txt b/doc/compute_com.txt
index 4b678ae011..43844dfd25 100644
--- a/doc/compute_com.txt
+++ b/doc/compute_com.txt
@@ -49,8 +49,9 @@ file"_dump.html containing coordinates of the atoms in the bodies.
 
 This compute calculates a global vector of length 3, which can be
 accessed by indices 1-3 by any command that uses global vector values
-from a compute as input.  See "this section"_Section_howto.html#4_15
-for an overview of LAMMPS output options.
+from a compute as input.  See "this
+section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+options.
 
 The vector values are "intensive".  The vector values will be in
 distance "units"_units.html.
diff --git a/doc/compute_com_molecule.html b/doc/compute_com_molecule.html
index 3f6ac13cb8..957b3feca8 100644
--- a/doc/compute_com_molecule.html
+++ b/doc/compute_com_molecule.html
@@ -64,7 +64,7 @@ file containing coordinates of the atoms in the bodies.
 Nmolecules and the number of columns = 3 for the x,y,z center-of-mass
 coordinates of each molecule.  These values can be accessed by any
 command that uses global array values from a compute as input.  See
-this section for an overview of LAMMPS
+this section for an overview of LAMMPS
 output options.
 
    
 
    The array values are "intensive".  The array values will be in
diff --git a/doc/compute_com_molecule.txt b/doc/compute_com_molecule.txt
index 670c9117a8..accfd389cf 100644
--- a/doc/compute_com_molecule.txt
+++ b/doc/compute_com_molecule.txt
@@ -61,7 +61,7 @@ This compute calculates a global array where the number of rows =
 Nmolecules and the number of columns = 3 for the x,y,z center-of-mass
 coordinates of each molecule.  These values can be accessed by any
 command that uses global array values from a compute as input.  See
-"this section"_Section_howto.html#4_15 for an overview of LAMMPS
+"this section"_Section_howto.html#howto_15 for an overview of LAMMPS
 output options.
 
 The array values are "intensive".  The array values will be in
diff --git a/doc/compute_coord_atom.html b/doc/compute_coord_atom.html
index 6ab22c03b3..57738b4f3d 100644
--- a/doc/compute_coord_atom.html
+++ b/doc/compute_coord_atom.html
@@ -46,7 +46,7 @@ too frequently or to have multiple compute/dump commands, each of a
 
    
 
    This compute calculates a per-atom vector, which can be accessed by
 any command that uses per-atom values from a compute as input.  See
-this section for an overview of LAMMPS
+this section for an overview of LAMMPS
 output options.
 
    
 
    The per-atom vector values will be a number >= 0.0, as explained
diff --git a/doc/compute_coord_atom.txt b/doc/compute_coord_atom.txt
index bd9c471a78..fc5f2c9000 100644
--- a/doc/compute_coord_atom.txt
+++ b/doc/compute_coord_atom.txt
@@ -43,7 +43,7 @@ too frequently or to have multiple compute/dump commands, each of a
 
 This compute calculates a per-atom vector, which can be accessed by
 any command that uses per-atom values from a compute as input.  See
-"this section"_Section_howto.html#4_15 for an overview of LAMMPS
+"this section"_Section_howto.html#howto_15 for an overview of LAMMPS
 output options.
 
 The per-atom vector values will be a number >= 0.0, as explained
diff --git a/doc/compute_damage_atom.html b/doc/compute_damage_atom.html
index f943fe06de..b5e0d03d89 100644
--- a/doc/compute_damage_atom.html
+++ b/doc/compute_damage_atom.html
@@ -37,7 +37,7 @@ compute group.
 
    
 
    This compute calculates a per-atom vector, which can be accessed by
 any command that uses per-atom values from a compute as input.  See
-this section for an overview of LAMMPS
+this section for an overview of LAMMPS
 output options.
 
    
 
    The per-atom vector values will be a number >= 0.0, as explained
@@ -45,8 +45,8 @@ above.
 
    
 
    Restrictions:
 
    
-
    This compute is part of the "peri" package.  It is only enabled if
-LAMMPS was built with that package.  See the Making
+
    This compute is part of the PERI package.  It is only enabled if
+LAMMPS was built with that package.  See the Making
 LAMMPS section for more info.
 
    
 
    Related commands:
diff --git a/doc/compute_damage_atom.txt b/doc/compute_damage_atom.txt
index 4a4b951cea..104cf22b54 100644
--- a/doc/compute_damage_atom.txt
+++ b/doc/compute_damage_atom.txt
@@ -34,7 +34,7 @@ compute group.
 
 This compute calculates a per-atom vector, which can be accessed by
 any command that uses per-atom values from a compute as input.  See
-"this section"_Section_howto.html#4_15 for an overview of LAMMPS
+"this section"_Section_howto.html#howto_15 for an overview of LAMMPS
 output options.
 
 The per-atom vector values will be a number >= 0.0, as explained
@@ -42,9 +42,9 @@ above.
 
 [Restrictions:]
 
-This compute is part of the "peri" package.  It is only enabled if
+This compute is part of the PERI package.  It is only enabled if
 LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+LAMMPS"_Section_start.html#start_3 section for more info.
 
 [Related commands:]
 
diff --git a/doc/compute_dihedral_local.html b/doc/compute_dihedral_local.html
index a5a122cb7f..e1f9cf13b7 100644
--- a/doc/compute_dihedral_local.html
+++ b/doc/compute_dihedral_local.html
@@ -60,7 +60,7 @@ array is the number of dihedrals.  If a single keyword is specified, a
 local vector is produced.  If two or more keywords are specified, a
 local array is produced where the number of columns = the number of
 keywords.  The vector or array can be accessed by any command that
-uses local values from a compute as input.  See this
+uses local values from a compute as input.  See this
 section for an overview of LAMMPS output
 options.
 
    
diff --git a/doc/compute_dihedral_local.txt b/doc/compute_dihedral_local.txt
index 405465a0e3..0bc32936f9 100644
--- a/doc/compute_dihedral_local.txt
+++ b/doc/compute_dihedral_local.txt
@@ -53,7 +53,7 @@ local vector is produced.  If two or more keywords are specified, a
 local array is produced where the number of columns = the number of
 keywords.  The vector or array can be accessed by any command that
 uses local values from a compute as input.  See "this
-section"_Section_howto.html#4_15 for an overview of LAMMPS output
+section"_Section_howto.html#howto_15 for an overview of LAMMPS output
 options.
 
 The output for {phi} will be in degrees.
diff --git a/doc/compute_displace_atom.html b/doc/compute_displace_atom.html
index e21919b5ee..79dae15622 100644
--- a/doc/compute_displace_atom.html
+++ b/doc/compute_displace_atom.html
@@ -76,8 +76,8 @@ file.
 
    
 
    This compute calculates a per-atom array with 4 columns, which can be
 accessed by indices 1-4 by any command that uses per-atom values from
-a compute as input.  See this section for an
-overview of LAMMPS output options.
+a compute as input.  See this section
+for an overview of LAMMPS output options.
 
    
 
    The per-atom array values will be in distance units.
 
    
diff --git a/doc/compute_displace_atom.txt b/doc/compute_displace_atom.txt
index 9cd35c4a23..ecbdf22b38 100644
--- a/doc/compute_displace_atom.txt
+++ b/doc/compute_displace_atom.txt
@@ -73,8 +73,8 @@ file.
 
 This compute calculates a per-atom array with 4 columns, which can be
 accessed by indices 1-4 by any command that uses per-atom values from
-a compute as input.  See "this section"_Section_howto.html#4_15 for an
-overview of LAMMPS output options.
+a compute as input.  See "this section"_Section_howto.html#howto_15
+for an overview of LAMMPS output options.
 
 The per-atom array values will be in distance "units"_units.html.
 
diff --git a/doc/compute_erotate_asphere.html b/doc/compute_erotate_asphere.html
index 05cd1c7b03..161aef27c2 100644
--- a/doc/compute_erotate_asphere.html
+++ b/doc/compute_erotate_asphere.html
@@ -25,41 +25,46 @@
 
    Description:
 
    
 
    Define a computation that calculates the rotational kinetic energy of
-a group of aspherical particles.
+a group of aspherical particles.  The aspherical particles can be
+ellipsoids, or line segments, or triangles.  See the
+atom_style and read_data commands
+for descriptions of these options.
 
    
-
    The rotational kinetic energy is computed as 1/2 I w^2, where I is the
-inertia tensor for the aspherical particle and w is its angular
-velocity, which is computed from its angular momentum.
+
    For all 3 types of particles, the rotational kinetic energy is
+computed as 1/2 I w^2, where I is the inertia tensor for the
+aspherical particle and w is its angular velocity, which is computed
+from its angular momentum if needed.
 
    
-
    IMPORTANT NOTE: For 2d models, particles are treated
-as ellipsoids, not ellipses, meaning their moments of inertia will be
-the same as in 3d.
+
    IMPORTANT NOTE: For 2d models, ellipsoidal particles
+are treated as ellipsoids, not ellipses, meaning their moments of
+inertia will be the same as in 3d.
 
    
 
    Output info:
 
    
 
    This compute calculates a global scalar (the KE).  This value can be
 used by any command that uses a global scalar value from a compute as
-input.  See this section for an overview of
-LAMMPS output options.
+input.  See this section for an overview
+of LAMMPS output options.
 
    
 
    The scalar value calculated by this compute is "extensive".  The
 scalar value will be in energy units.
 
    
 
    Restrictions:
 
    
-
    This compute requires that particles be represented as extended
-ellipsoids and not point particles.  This means they will have an
-angular momentum and a shape which is determined by the
-shape command.
+
    This compute requires that ellipsoidal particles atoms store a shape
+and quaternion orientation and angular momentum as defined by the
+atom_style ellipsoid command.
 
    
-
    This compute requires that atoms store angular momentum and a
-quaternion to represent their orientation, as defined by the
-atom_style.  It also require they store a per-type
-shape.  The particles cannot store a per-particle
-diameter or per-particle mass.
+
    This compute requires that line segment particles atoms store a length
+and orientation and angular velocity as defined by the atom_style
+line command.
+
    
+
    This compute requires that triangular particles atoms store a size and
+shape and quaternion orientation and angular momentum as defined by
+the atom_style tri command.
 
    
 
    All particles in the group must be finite-size.  They cannot be point
-particles, but they can be aspherical or spherical.
+particles.
 
    
 
    Related commands: none
 
    
diff --git a/doc/compute_erotate_asphere.txt b/doc/compute_erotate_asphere.txt
index 92f03596de..39aded0ed7 100644
--- a/doc/compute_erotate_asphere.txt
+++ b/doc/compute_erotate_asphere.txt
@@ -22,41 +22,46 @@ compute 1 all erotate/asphere :pre
 [Description:]
 
 Define a computation that calculates the rotational kinetic energy of
-a group of aspherical particles.
+a group of aspherical particles.  The aspherical particles can be
+ellipsoids, or line segments, or triangles.  See the
+"atom_style"_atom_style.html and "read_data"_read_data.html commands
+for descriptions of these options.
 
-The rotational kinetic energy is computed as 1/2 I w^2, where I is the
-inertia tensor for the aspherical particle and w is its angular
-velocity, which is computed from its angular momentum.
+For all 3 types of particles, the rotational kinetic energy is
+computed as 1/2 I w^2, where I is the inertia tensor for the
+aspherical particle and w is its angular velocity, which is computed
+from its angular momentum if needed.
 
-IMPORTANT NOTE: For "2d models"_dimension.html, particles are treated
-as ellipsoids, not ellipses, meaning their moments of inertia will be
-the same as in 3d.
+IMPORTANT NOTE: For "2d models"_dimension.html, ellipsoidal particles
+are treated as ellipsoids, not ellipses, meaning their moments of
+inertia will be the same as in 3d.
 
 [Output info:]
 
 This compute calculates a global scalar (the KE).  This value can be
 used by any command that uses a global scalar value from a compute as
-input.  See "this section"_Section_howto.html#4_15 for an overview of
-LAMMPS output options.
+input.  See "this section"_Section_howto.html#howto_15 for an overview
+of LAMMPS output options.
 
 The scalar value calculated by this compute is "extensive".  The
 scalar value will be in energy "units"_units.html.
 
 [Restrictions:]
 
-This compute requires that particles be represented as extended
-ellipsoids and not point particles.  This means they will have an
-angular momentum and a shape which is determined by the
-"shape"_shape.html command.
+This compute requires that ellipsoidal particles atoms store a shape
+and quaternion orientation and angular momentum as defined by the
+"atom_style ellipsoid"_atom_style.html command.
 
-This compute requires that atoms store angular momentum and a
-quaternion to represent their orientation, as defined by the
-"atom_style"_atom_style.html.  It also require they store a per-type
-"shape"_shape.html.  The particles cannot store a per-particle
-diameter or per-particle mass.
+This compute requires that line segment particles atoms store a length
+and orientation and angular velocity as defined by the "atom_style
+line"_atom_style.html command.
+
+This compute requires that triangular particles atoms store a size and
+shape and quaternion orientation and angular momentum as defined by
+the "atom_style tri"_atom_style.html command.
 
 All particles in the group must be finite-size.  They cannot be point
-particles, but they can be aspherical or spherical.
+particles.
 
 [Related commands:] none
 
diff --git a/doc/compute_erotate_sphere.html b/doc/compute_erotate_sphere.html
index 58c65d3838..d9e328364c 100644
--- a/doc/compute_erotate_sphere.html
+++ b/doc/compute_erotate_sphere.html
@@ -38,17 +38,16 @@ same as in 3d.
 
    
 
    This compute calculates a global scalar (the KE).  This value can be
 used by any command that uses a global scalar value from a compute as
-input.  See this section for an overview of
-LAMMPS output options.
+input.  See this section for an overview
+of LAMMPS output options.
 
    
 
    The scalar value calculated by this compute is "extensive".  The
 scalar value will be in energy units.
 
    
 
    Restrictions:
 
    
-
    This compute requires that atoms store angular velocity (omega) as
-defined by the atom_style.  It also require they
-store either a per-particle diameter or per-type shape.
+
    This compute requires that atoms store a radius and angular velocity
+(omega) as defined by the atom_style sphere command.
 
    
 
    All particles in the group must be finite-size spheres or point
 particles.  They cannot be aspherical.  Point particles will not
diff --git a/doc/compute_erotate_sphere.txt b/doc/compute_erotate_sphere.txt
index f7bf941e26..7e480a2812 100644
--- a/doc/compute_erotate_sphere.txt
+++ b/doc/compute_erotate_sphere.txt
@@ -35,17 +35,16 @@ same as in 3d.
 
 This compute calculates a global scalar (the KE).  This value can be
 used by any command that uses a global scalar value from a compute as
-input.  See "this section"_Section_howto.html#4_15 for an overview of
-LAMMPS output options.
+input.  See "this section"_Section_howto.html#howto_15 for an overview
+of LAMMPS output options.
 
 The scalar value calculated by this compute is "extensive".  The
 scalar value will be in energy "units"_units.html.
 
 [Restrictions:]
 
-This compute requires that atoms store angular velocity (omega) as
-defined by the "atom_style"_atom_style.html.  It also require they
-store either a per-particle diameter or per-type "shape"_shape.html.
+This compute requires that atoms store a radius and angular velocity
+(omega) as defined by the "atom_style sphere"_atom_style.html command.
 
 All particles in the group must be finite-size spheres or point
 particles.  They cannot be aspherical.  Point particles will not
diff --git a/doc/compute_event_displace.html b/doc/compute_event_displace.html
index 221f8506a0..ae63a96bb9 100644
--- a/doc/compute_event_displace.html
+++ b/doc/compute_event_displace.html
@@ -41,21 +41,22 @@ further than the threshold distance.
 due to thermal motion, an external force, or an initial net momentum, 
 then this compute will not be able to distinguish that motion from
 local atom displacements and may generate "false postives."
-Output info:
+
    
+
    Output info:
 
    
 
    This compute calculates a global scalar (the flag).  This value can be
 used by any command that uses a global scalar value from a compute as
-input.  See this section for an overview of
-LAMMPS output options.
+input.  See this section for an overview
+of LAMMPS output options.
 
    
 
    The scalar value calculated by this compute is "intensive".  The
 scalar value will be a 0 or 1 as explained above.
 
    
 
    Restrictions:
 
    
-
    This command can only be used if LAMMPS was built with the "replica"
-package.  See the Making LAMMPS section for
-more info on packages.
+
    This command can only be used if LAMMPS was built with the REPLICA
+package.  See the Making LAMMPS section
+for more info on packages.
 
    
 
    Related commands:
 
    
diff --git a/doc/compute_event_displace.txt b/doc/compute_event_displace.txt
index 34149c95c6..7b26d3120e 100644
--- a/doc/compute_event_displace.txt
+++ b/doc/compute_event_displace.txt
@@ -38,21 +38,22 @@ NOTE: If the system is undergoing significant center-of-mass motion,
 due to thermal motion, an external force, or an initial net momentum, 
 then this compute will not be able to distinguish that motion from
 local atom displacements and may generate "false postives."
+
 [Output info:]
 
 This compute calculates a global scalar (the flag).  This value can be
 used by any command that uses a global scalar value from a compute as
-input.  See "this section"_Section_howto.html#4_15 for an overview of
-LAMMPS output options.
+input.  See "this section"_Section_howto.html#howto_15 for an overview
+of LAMMPS output options.
 
 The scalar value calculated by this compute is "intensive".  The
 scalar value will be a 0 or 1 as explained above.
 
 [Restrictions:]
 
-This command can only be used if LAMMPS was built with the "replica"
-package.  See the "Making LAMMPS"_Section_start.html#2_3 section for
-more info on packages.
+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.
 
 [Related commands:]
 
diff --git a/doc/compute_group_group.html b/doc/compute_group_group.html
index 57e867136a..bd1aacc412 100644
--- a/doc/compute_group_group.html
+++ b/doc/compute_group_group.html
@@ -44,12 +44,12 @@ quantity too frequently.
 
    This compute calculates a global scalar (the energy) and a global
 vector of length 3 (force), which can be accessed by indices 1-3.
 These values can be used by any command that uses global scalar or
-vector values from a compute as input.  See this
+vector values from a compute as input.  See this
 section for an overview of LAMMPS output
 options.
 
    
 
    Both the scalar and vector values calculated by this compute are
-"extensive"., The scalar value will be in energy units.
+"extensive".  The scalar value will be in energy units.
 The vector values will be in force units.
 
    
 
    Restrictions:
diff --git a/doc/compute_group_group.txt b/doc/compute_group_group.txt
index 71bfcf6450..cb49e7558b 100644
--- a/doc/compute_group_group.txt
+++ b/doc/compute_group_group.txt
@@ -42,11 +42,11 @@ This compute calculates a global scalar (the energy) and a global
 vector of length 3 (force), which can be accessed by indices 1-3.
 These values can be used by any command that uses global scalar or
 vector values from a compute as input.  See "this
-section"_Section_howto.html#4_15 for an overview of LAMMPS output
+section"_Section_howto.html#howto_15 for an overview of LAMMPS output
 options.
 
 Both the scalar and vector values calculated by this compute are
-"extensive"., The scalar value will be in energy "units"_units.html.
+"extensive".  The scalar value will be in energy "units"_units.html.
 The vector values will be in force "units"_units.html.
 
 [Restrictions:]
diff --git a/doc/compute_gyration.html b/doc/compute_gyration.html
index 65fb731169..1d8b8389cd 100644
--- a/doc/compute_gyration.html
+++ b/doc/compute_gyration.html
@@ -49,8 +49,8 @@ image command.
 
    
 
    This compute calculates a global scalar (Rg).  This value can be used
 by any command that uses a global scalar value from a compute as
-input.  See this section for an overview of
-LAMMPS output options.
+input.  See this section for an overview
+of LAMMPS output options.
 
    
 
    The scalar value calculated by this compute is "intensive".  The
 scalar value will be in distance units.
diff --git a/doc/compute_gyration.txt b/doc/compute_gyration.txt
index c3390ba5ac..867669d0a7 100644
--- a/doc/compute_gyration.txt
+++ b/doc/compute_gyration.txt
@@ -46,8 +46,8 @@ image"_set.html command.
 
 This compute calculates a global scalar (Rg).  This value can be used
 by any command that uses a global scalar value from a compute as
-input.  See "this section"_Section_howto.html#4_15 for an overview of
-LAMMPS output options.
+input.  See "this section"_Section_howto.html#howto_15 for an overview
+of LAMMPS output options.
 
 The scalar value calculated by this compute is "intensive".  The
 scalar value will be in distance "units"_units.html.
diff --git a/doc/compute_gyration_molecule.html b/doc/compute_gyration_molecule.html
index b8ad07e64c..f74218009f 100644
--- a/doc/compute_gyration_molecule.html
+++ b/doc/compute_gyration_molecule.html
@@ -62,7 +62,7 @@ image command.
 
    
 
    This compute calculates a global vector of Rg values where the length
 of the vector = Nmolecules.  These values can be used by any command
-that uses global vector values from a compute as input.  See this
+that uses global vector values from a compute as input.  See this
 section for an overview of LAMMPS output
 options.
 
    
diff --git a/doc/compute_gyration_molecule.txt b/doc/compute_gyration_molecule.txt
index 52abb883c5..375e109326 100644
--- a/doc/compute_gyration_molecule.txt
+++ b/doc/compute_gyration_molecule.txt
@@ -60,7 +60,7 @@ image"_set.html command.
 This compute calculates a global vector of Rg values where the length
 of the vector = Nmolecules.  These values can be used by any command
 that uses global vector values from a compute as input.  See "this
-section"_Section_howto.html#4_15 for an overview of LAMMPS output
+section"_Section_howto.html#howto_15 for an overview of LAMMPS output
 options.
 
 The vector values calculated by this compute are "intensive".  The
diff --git a/doc/compute_heat_flux.html b/doc/compute_heat_flux.html
index 84f8b28351..b56ce96f33 100644
--- a/doc/compute_heat_flux.html
+++ b/doc/compute_heat_flux.html
@@ -99,7 +99,7 @@ result should be: average conductivity ~0.29 in W/mK.
 
    This compute calculates a global vector of length 6 (total heat flux
 vector, followed by conductive heat flux vector), which can be
 accessed by indices 1-6.  These values can be used by any command that
-uses global vector values from a compute as input.  See this
+uses global vector values from a compute as input.  See this
 section for an overview of LAMMPS output
 options.
 
    
diff --git a/doc/compute_heat_flux.txt b/doc/compute_heat_flux.txt
index ef4907cdd3..2d9816a066 100644
--- a/doc/compute_heat_flux.txt
+++ b/doc/compute_heat_flux.txt
@@ -97,7 +97,7 @@ This compute calculates a global vector of length 6 (total heat flux
 vector, followed by conductive heat flux vector), which can be
 accessed by indices 1-6.  These values can be used by any command that
 uses global vector values from a compute as input.  See "this
-section"_Section_howto.html#4_15 for an overview of LAMMPS output
+section"_Section_howto.html#howto_15 for an overview of LAMMPS output
 options.
 
 The vector values calculated by this compute are "extensive", meaning
diff --git a/doc/compute_improper_local.html b/doc/compute_improper_local.html
index ceb67530a4..cf529f222d 100644
--- a/doc/compute_improper_local.html
+++ b/doc/compute_improper_local.html
@@ -60,7 +60,7 @@ array is the number of impropers.  If a single keyword is specified, a
 local vector is produced.  If two or more keywords are specified, a
 local array is produced where the number of columns = the number of
 keywords.  The vector or array can be accessed by any command that
-uses local values from a compute as input.  See this
+uses local values from a compute as input.  See this
 section for an overview of LAMMPS output
 options.
 
    
diff --git a/doc/compute_improper_local.txt b/doc/compute_improper_local.txt
index 401e3b509d..c227cb2b85 100644
--- a/doc/compute_improper_local.txt
+++ b/doc/compute_improper_local.txt
@@ -53,7 +53,7 @@ local vector is produced.  If two or more keywords are specified, a
 local array is produced where the number of columns = the number of
 keywords.  The vector or array can be accessed by any command that
 uses local values from a compute as input.  See "this
-section"_Section_howto.html#4_15 for an overview of LAMMPS output
+section"_Section_howto.html#howto_15 for an overview of LAMMPS output
 options.
 
 The output for {chi} will be in degrees.
diff --git a/doc/compute_ke.html b/doc/compute_ke.html
index c974ab79bb..12769e0f55 100644
--- a/doc/compute_ke.html
+++ b/doc/compute_ke.html
@@ -47,8 +47,8 @@ include different degrees of freedom (translational, rotational, etc).
 
    
 
    This compute calculates a global scalar (the KE).  This value can be
 used by any command that uses a global scalar value from a compute as
-input.  See this section for an overview of
-LAMMPS output options.
+input.  See this section for an overview
+of LAMMPS output options.
 
    
 
    The scalar value calculated by this compute is "extensive".  The
 scalar value will be in energy units.
diff --git a/doc/compute_ke.txt b/doc/compute_ke.txt
index d9847cb506..003332c073 100644
--- a/doc/compute_ke.txt
+++ b/doc/compute_ke.txt
@@ -44,8 +44,8 @@ include different degrees of freedom (translational, rotational, etc).
 
 This compute calculates a global scalar (the KE).  This value can be
 used by any command that uses a global scalar value from a compute as
-input.  See "this section"_Section_howto.html#4_15 for an overview of
-LAMMPS output options.
+input.  See "this section"_Section_howto.html#howto_15 for an overview
+of LAMMPS output options.
 
 The scalar value calculated by this compute is "extensive".  The
 scalar value will be in energy "units"_units.html.
diff --git a/doc/compute_ke_atom.html b/doc/compute_ke_atom.html
index 6ad15d64da..434718e6a6 100644
--- a/doc/compute_ke_atom.html
+++ b/doc/compute_ke_atom.html
@@ -37,7 +37,7 @@ specified compute group.
 
    
 
    This compute calculates a per-atom vector, which can be accessed by
 any command that uses per-atom values from a compute as input.  See
-this section for an overview of LAMMPS
+this section for an overview of LAMMPS
 output options.
 
    
 
    The per-atom vector values will be in energy units.
diff --git a/doc/compute_ke_atom.txt b/doc/compute_ke_atom.txt
index 590ee3fae6..fd42651300 100644
--- a/doc/compute_ke_atom.txt
+++ b/doc/compute_ke_atom.txt
@@ -34,7 +34,7 @@ specified compute group.
 
 This compute calculates a per-atom vector, which can be accessed by
 any command that uses per-atom values from a compute as input.  See
-"this section"_Section_howto.html#4_15 for an overview of LAMMPS
+"this section"_Section_howto.html#howto_15 for an overview of LAMMPS
 output options.
 
 The per-atom vector values will be in energy "units"_units.html.
diff --git a/doc/compute_ke_atom_eff.html b/doc/compute_ke_atom_eff.html
index d665e62f39..19ffb3f77c 100644
--- a/doc/compute_ke_atom_eff.html
+++ b/doc/compute_ke_atom_eff.html
@@ -62,15 +62,15 @@ electrons) not in the specified compute group.
 
    
 
    This compute calculates a scalar quantity for each atom, which can be
 accessed by any command that uses per-atom computes as input.  See
-this section for an overview of LAMMPS
+this section for an overview of LAMMPS
 output options.
 
    
 
    The per-atom vector values will be in energy units.
 
    
 
    Restrictions:
 
    
-
    This compute is part of the "user-eff" package.  It is only enabled if
-LAMMPS was built with that package.  See the Making
+
    This compute is part of the USER-EFF package.  It is only enabled if
+LAMMPS was built with that package.  See the Making
 LAMMPS section for more info.
 
    
 
    Related commands:
diff --git a/doc/compute_ke_atom_eff.txt b/doc/compute_ke_atom_eff.txt
index 3dd67d8b6d..00c32be622 100644
--- a/doc/compute_ke_atom_eff.txt
+++ b/doc/compute_ke_atom_eff.txt
@@ -59,16 +59,16 @@ electrons) not in the specified compute group.
 
 This compute calculates a scalar quantity for each atom, which can be
 accessed by any command that uses per-atom computes as input.  See
-"this section"_Section_howto.html#4_15 for an overview of LAMMPS
+"this section"_Section_howto.html#howto_15 for an overview of LAMMPS
 output options.
 
 The per-atom vector values will be in energy "units"_units.html.
 
 [Restrictions:]
 
-This compute is part of the "user-eff" package.  It is only enabled if
+This compute is part of the USER-EFF package.  It is only enabled if
 LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+LAMMPS"_Section_start.html#start_3 section for more info.
 
 [Related commands:]
 
diff --git a/doc/compute_ke_eff.html b/doc/compute_ke_eff.html
index 5e12f747ac..2fa318f8a6 100644
--- a/doc/compute_ke_eff.html
+++ b/doc/compute_ke_eff.html
@@ -64,16 +64,16 @@ thermo_modify   temp effTemp
 
    
 
    This compute calculates a global scalar (the KE).  This value can be
 used by any command that uses a global scalar value from a compute as
-input.  See this section for an overview of
-LAMMPS output options.
+input.  See this section for an overview
+of LAMMPS output options.
 
    
 
    The scalar value calculated by this compute is "extensive".  The
 scalar value will be in energy units.
 
    
 
    Restrictions:
 
    
-
    This compute is part of the "user-eff" package.  It is only enabled if
-LAMMPS was built with that package.  See the Making
+
    This compute is part of the USER-EFF package.  It is only enabled if
+LAMMPS was built with that package.  See the Making
 LAMMPS section for more info.
 
    
 
    Related commands: none
diff --git a/doc/compute_ke_eff.txt b/doc/compute_ke_eff.txt
index 09001228ed..2ebe435dff 100644
--- a/doc/compute_ke_eff.txt
+++ b/doc/compute_ke_eff.txt
@@ -61,17 +61,17 @@ See "compute temp/eff"_compute_temp_eff.html.
 
 This compute calculates a global scalar (the KE).  This value can be
 used by any command that uses a global scalar value from a compute as
-input.  See "this section"_Section_howto.html#4_15 for an overview of
-LAMMPS output options.
+input.  See "this section"_Section_howto.html#howto_15 for an overview
+of LAMMPS output options.
 
 The scalar value calculated by this compute is "extensive".  The
 scalar value will be in energy "units"_units.html.
 
 [Restrictions:]
 
-This compute is part of the "user-eff" package.  It is only enabled if
+This compute is part of the USER-EFF package.  It is only enabled if
 LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+LAMMPS"_Section_start.html#start_3 section for more info.
 
 [Related commands:] none
 
diff --git a/doc/compute_meso_e_atom.html b/doc/compute_meso_e_atom.html
new file mode 100644
index 0000000000..69d903799b
--- /dev/null
+++ b/doc/compute_meso_e_atom.html
@@ -0,0 +1,61 @@
+
+
    LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
    
+
+
+
+
+
+
+
    
+
+
    compute meso_e/atom command 
+
    
+
    Syntax:
+
    
+
    compute ID group-ID meso_e/atom 
+
    
+
    • ID, group-ID are documented in compute command
+
    • meso_e/atom = style name of this compute command 
+
    
+
    Examples:
+
    
+
    compute 1 all meso_e/atom 
+
    
+
    Description:
+
    
+
    Define a computation that calculates the per-atom internal energy
+for each atom in a group.
+
    
+
    The internal energy is the energy associated with the internal degrees
+of freedom of a mesoscopic particles, e.g. a Smooth-Particle
+Hydrodynamics particle.
+
    
+
    See this PDF guide to using SPH in
+LAMMPS.
+
    
+
    The value of the internal energy will be 0.0 for atoms not in the
+specified compute group.
+
    
+
    Output info:
+
    
+
    This compute calculates a per-atom vector, which can be accessed by
+any command that uses per-atom values from a compute as input.  See
+this section for an overview of LAMMPS
+output options.
+
    
+
    The per-atom vector values will be in energy units.
+
    
+
    Restrictions:
+
    
+
    This compute is part of the USER-SPH package.  It is only enabled if
+LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
    
+
    Related commands:
+
    
+
    dump custom
+
    
+
    Default: none
+
    
+
diff --git a/doc/compute_meso_e_atom.txt b/doc/compute_meso_e_atom.txt
new file mode 100644
index 0000000000..b85115da49
--- /dev/null
+++ b/doc/compute_meso_e_atom.txt
@@ -0,0 +1,56 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+compute meso_e/atom command :h3
+
+[Syntax:]
+
+compute ID group-ID meso_e/atom :pre
+
+ID, group-ID are documented in "compute"_compute.html command
+meso_e/atom = style name of this compute command :ul
+
+[Examples:]
+
+compute 1 all meso_e/atom :pre
+
+[Description:]
+
+Define a computation that calculates the per-atom internal energy
+for each atom in a group.
+
+The internal energy is the energy associated with the internal degrees
+of freedom of a mesoscopic particles, e.g. a Smooth-Particle
+Hydrodynamics particle.
+
+See "this PDF guide"_USER/sph/SPH_LAMMPS_userguide.pdf to using SPH in
+LAMMPS.
+
+The value of the internal energy will be 0.0 for atoms not in the
+specified compute group.
+
+[Output info:]
+
+This compute calculates a per-atom vector, which can be accessed by
+any command that uses per-atom values from a compute as input.  See
+"this section"_Section_howto.html#4_15 for an overview of LAMMPS
+output options.
+
+The per-atom vector values will be in energy "units"_units.html.
+
+[Restrictions:]
+
+This compute is part of the USER-SPH 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:]
+
+"dump custom"_dump.html
+
+[Default:] none
diff --git a/doc/compute_meso_rho_atom.html b/doc/compute_meso_rho_atom.html
new file mode 100644
index 0000000000..202be3573c
--- /dev/null
+++ b/doc/compute_meso_rho_atom.html
@@ -0,0 +1,61 @@
+
+
    LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
    
+
+
+
+
+
+
+
    
+
+
    compute meso_rho/atom command 
+
    
+
    Syntax:
+
    
+
    compute ID group-ID meso_rho/atom 
+
    
+
    • ID, group-ID are documented in compute command
+
    • meso_rho/atom = style name of this compute command 
+
    
+
    Examples:
+
    
+
    compute 1 all meso_rho/atom 
+
    
+
    Description:
+
    
+
    Define a computation that calculates the per-atom mesoscopic density
+for each atom in a group.
+
    
+
    The mesoscopic density is the mass density of a mesoscopic particle,
+calculated by kernel function interpolation using "pair style
+sph/rhosum".
+
    
+
    See this PDF guide to using SPH in
+LAMMPS.
+
    
+
    The value of the mesoscopic density will be 0.0 for atoms not in the
+specified compute group.
+
    
+
    Output info:
+
    
+
    This compute calculates a per-atom vector, which can be accessed by
+any command that uses per-atom values from a compute as input.  See
+this section for an overview of LAMMPS
+output options.
+
    
+
    The per-atom vector values will be in mass/volume units.
+
    
+
    Restrictions:
+
    
+
    This compute is part of the USER-SPH package.  It is only enabled if
+LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
    
+
    Related commands:
+
    
+
    dump custom
+
    
+
    Default: none
+
    
+
diff --git a/doc/compute_meso_rho_atom.txt b/doc/compute_meso_rho_atom.txt
new file mode 100644
index 0000000000..c09581864d
--- /dev/null
+++ b/doc/compute_meso_rho_atom.txt
@@ -0,0 +1,56 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+compute meso_rho/atom command :h3
+
+[Syntax:]
+
+compute ID group-ID meso_rho/atom :pre
+
+ID, group-ID are documented in "compute"_compute.html command
+meso_rho/atom = style name of this compute command :ul
+
+[Examples:]
+
+compute 1 all meso_rho/atom :pre
+
+[Description:]
+
+Define a computation that calculates the per-atom mesoscopic density
+for each atom in a group.
+
+The mesoscopic density is the mass density of a mesoscopic particle,
+calculated by kernel function interpolation using "pair style
+sph/rhosum".
+
+See "this PDF guide"_USER/sph/SPH_LAMMPS_userguide.pdf to using SPH in
+LAMMPS.
+
+The value of the mesoscopic density will be 0.0 for atoms not in the
+specified compute group.
+
+[Output info:]
+
+This compute calculates a per-atom vector, which can be accessed by
+any command that uses per-atom values from a compute as input.  See
+"this section"_Section_howto.html#4_15 for an overview of LAMMPS
+output options.
+
+The per-atom vector values will be in mass/volume "units"_units.html.
+
+[Restrictions:]
+
+This compute is part of the USER-SPH 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:]
+
+"dump custom"_dump.html
+
+[Default:] none
diff --git a/doc/compute_meso_t_atom.html b/doc/compute_meso_t_atom.html
new file mode 100644
index 0000000000..dc41ea8d3b
--- /dev/null
+++ b/doc/compute_meso_t_atom.html
@@ -0,0 +1,63 @@
+
+
    LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
    
+
+
+
+
+
+
+
    
+
+
    compute meso_t/atom command 
+
    
+
    Syntax:
+
    
+
    compute ID group-ID meso_t/atom 
+
    
+
    • ID, group-ID are documented in compute command
+
    • meso_t/atom = style name of this compute command 
+
    
+
    Examples:
+
    
+
    compute 1 all meso_t/atom 
+
    
+
    Description:
+
    
+
    Define a computation that calculates the per-atom internal temperature
+for each atom in a group.
+
    
+
    The internal temperature is the ratio of internal energy over the heat
+capacity associated with the internal degrees of freedom of a mesoscopic
+particles, e.g. a Smooth-Particle Hydrodynamics particle.
+
    
+
    T_int = E_int / C_V, int
+
    
+
    See this PDF guide to using SPH in
+LAMMPS.
+
    
+
    The value of the internal energy will be 0.0 for atoms not in the
+specified compute group.
+
    
+
    Output info:
+
    
+
    This compute calculates a per-atom vector, which can be accessed by
+any command that uses per-atom values from a compute as input.  See
+this section for an overview of LAMMPS
+output options.
+
    
+
    The per-atom vector values will be in temperature units.
+
    
+
    Restrictions:
+
    
+
    This compute is part of the USER-SPH package.  It is only enabled if
+LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
    
+
    Related commands:
+
    
+
    dump custom
+
    
+
    Default: none
+
    
+
diff --git a/doc/compute_meso_t_atom.txt b/doc/compute_meso_t_atom.txt
new file mode 100644
index 0000000000..1d1a3a12ae
--- /dev/null
+++ b/doc/compute_meso_t_atom.txt
@@ -0,0 +1,58 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+compute meso_t/atom command :h3
+
+[Syntax:]
+
+compute ID group-ID meso_t/atom :pre
+
+ID, group-ID are documented in "compute"_compute.html command
+meso_t/atom = style name of this compute command :ul
+
+[Examples:]
+
+compute 1 all meso_t/atom :pre
+
+[Description:]
+
+Define a computation that calculates the per-atom internal temperature
+for each atom in a group.
+
+The internal temperature is the ratio of internal energy over the heat
+capacity associated with the internal degrees of freedom of a mesoscopic
+particles, e.g. a Smooth-Particle Hydrodynamics particle.
+
+T_{int} = E_{int} / C_{V, int}
+
+See "this PDF guide"_USER/sph/SPH_LAMMPS_userguide.pdf to using SPH in
+LAMMPS.
+
+The value of the internal energy will be 0.0 for atoms not in the
+specified compute group.
+
+[Output info:]
+
+This compute calculates a per-atom vector, which can be accessed by
+any command that uses per-atom values from a compute as input.  See
+"this section"_Section_howto.html#4_15 for an overview of LAMMPS
+output options.
+
+The per-atom vector values will be in temperature "units"_units.html.
+
+[Restrictions:]
+
+This compute is part of the USER-SPH 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:]
+
+"dump custom"_dump.html
+
+[Default:] none
diff --git a/doc/compute_msd.html b/doc/compute_msd.html
index fde408b9e4..7814701ffd 100644
--- a/doc/compute_msd.html
+++ b/doc/compute_msd.html
@@ -92,8 +92,9 @@ file.
 
    
 
    This compute calculates a global vector of length 4, which can be
 accessed by indices 1-4 by any command that uses global vector values
-from a compute as input.  See this section
-for an overview of LAMMPS output options.
+from a compute as input.  See this
+section for an overview of LAMMPS output
+options.
 
    
 
    The vector values are "intensive".  The vector values will be in
 distance^2 units.
diff --git a/doc/compute_msd.txt b/doc/compute_msd.txt
index 10bd9fecdc..e40a18b22f 100644
--- a/doc/compute_msd.txt
+++ b/doc/compute_msd.txt
@@ -84,8 +84,9 @@ file.
 
 This compute calculates a global vector of length 4, which can be
 accessed by indices 1-4 by any command that uses global vector values
-from a compute as input.  See "this section"_Section_howto.html#4_15
-for an overview of LAMMPS output options.
+from a compute as input.  See "this
+section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+options.
 
 The vector values are "intensive".  The vector values will be in
 distance^2 "units"_units.html.
diff --git a/doc/compute_msd_molecule.html b/doc/compute_msd_molecule.html
index f00536e0d1..2f30e14385 100644
--- a/doc/compute_msd_molecule.html
+++ b/doc/compute_msd_molecule.html
@@ -81,7 +81,7 @@ file.
 
    This compute calculates a global array where the number of rows =
 Nmolecules and the number of columns = 4 for dx,dy,dz and the total
 displacement.  These values can be accessed by any command that uses
-global array values from a compute as input.  See this
+global array values from a compute as input.  See this
 section for an overview of LAMMPS output
 options.
 
    
diff --git a/doc/compute_msd_molecule.txt b/doc/compute_msd_molecule.txt
index d411a49d06..2b8bd93cf2 100644
--- a/doc/compute_msd_molecule.txt
+++ b/doc/compute_msd_molecule.txt
@@ -79,7 +79,7 @@ This compute calculates a global array where the number of rows =
 Nmolecules and the number of columns = 4 for dx,dy,dz and the total
 displacement.  These values can be accessed by any command that uses
 global array values from a compute as input.  See "this
-section"_Section_howto.html#4_15 for an overview of LAMMPS output
+section"_Section_howto.html#howto_15 for an overview of LAMMPS output
 options.
 
 The array values are "intensive".  The array values will be in
diff --git a/doc/compute_pair.html b/doc/compute_pair.html
index b59204428f..b456d96ba6 100644
--- a/doc/compute_pair.html
+++ b/doc/compute_pair.html
@@ -62,8 +62,9 @@ are stored as a global vector by this compute.  See the doc page for
 ecoul.  If the pair style supports it, it also calculates a global
 vector of length >= 1, as determined by the pair style.  These values
 can be used by any command that uses global scalar or vector values
-from a compute as input.  See this section
-for an overview of LAMMPS output options.
+from a compute as input.  See this
+section for an overview of LAMMPS output
+options.
 
    
 
    The scalar and vector values calculated by this compute are
 "extensive".
diff --git a/doc/compute_pair.txt b/doc/compute_pair.txt
index c1144013da..d1662acfa5 100644
--- a/doc/compute_pair.txt
+++ b/doc/compute_pair.txt
@@ -59,8 +59,9 @@ This compute calculates a global scalar which is {epair} or {evdwl} or
 {ecoul}.  If the pair style supports it, it also calculates a global
 vector of length >= 1, as determined by the pair style.  These values
 can be used by any command that uses global scalar or vector values
-from a compute as input.  See "this section"_Section_howto.html#4_15
-for an overview of LAMMPS output options.
+from a compute as input.  See "this
+section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+options.
 
 The scalar and vector values calculated by this compute are
 "extensive".
diff --git a/doc/compute_pair_local.html b/doc/compute_pair_local.html
index 0fe54e113d..41cf2f92e9 100644
--- a/doc/compute_pair_local.html
+++ b/doc/compute_pair_local.html
@@ -21,18 +21,22 @@
 
 
  • zero or more keywords may be appended 
 
-
  • keyword = dist or eng or force 
+
  • keyword = dist or eng or force or fx or fy or fz or fN 
 
-
      dist = tabulate pairwise distances
-  eng = tablutate pairwise energies
-  force = tablutate pairwise forces 
+
      dist = pairwise distance
+  eng = pairwise energy
+  force = pairwise force
+  fx,fy,fz = components of pairwise force
+  pN = pair style specific quantities for allowed N values 
 
    
 
 
 
    Examples:
 
    
 
    compute 1 all pair/local eng
-compute 1 all pair/local dist eng force 
+compute 1 all pair/local dist eng force
+compute 1 all pair/local dist eng fx fy fz
+compute 1 all pair/local dist fx fy fz p1 p2 p3 
 
    
 
    Description:
 
    
@@ -48,9 +52,27 @@ force cutoff distance for that interaction, as defined by the
 pair_style and pair_coeff
 commands.
 
    
+
    The output dist is the distance bewteen the pair of atoms.
+
    
+
    The output eng is the interaction energy for the pair of atoms.
+
    
+
    The output force is the force acting between the pair of atoms,
+which is positive for a repulsive force and negative for an attractive
+force.  The outputs fx, fy, and fz are the xyz components of
+force on atom I.
+
    
+
    A pair style may define additional pairwise quantities which can be
+accessed as p1 to pN, where N is defined by the pair style.  Most
+pair styles do not define any additional quantities, so N = 0.  An
+example of ones that do are the granular pair styles
+which calculate the tangential force between two particles and return
+its components and magnitude acting on atom I for N = 1,2,3,4.  See
+individual pair styles for detils.
+
    
 
    The output dist will be in distance units.  The output
-eng will be in energy units.  The output force will
-be in force units.
+eng will be in energy units.  The outputs force,
+fx, fy, and fz will be in force units.  The output
+pN will be in whatever units the pair style defines.
 
    
 
    Note that as atoms migrate from processor to processor, there will be
 no consistent ordering of the entries within the local vector or array
@@ -62,6 +84,16 @@ property/local command can be combined
 with data from this command and output by the dump local
 command in a consistent way.
 
    
+
    IMPORTANT NOTE: For pairs, if two atoms I,J are involved in 1-2, 1-3,
+1-4 interactions within the molecular topology, their pairwise
+interaction may be turned off, and thus they may not appear in the
+neighbor list, and will not be part of the local data created by this
+command.  More specifically, this may be true of I,J pairs with a
+weighting factor of 0.0; pairs with a non-zero weighting factor are
+included.  The weighting factors for 1-2, 1-3, and 1-4 pairwise
+interactions are set by the special_bonds
+command.
+
    
 
    Output info:
 
    
 
    This compute calculates a local vector or local array depending on the
@@ -70,7 +102,7 @@ array is the number of pairs.  If a single keyword is specified, a
 local vector is produced.  If two or more keywords are specified, a
 local array is produced where the number of columns = the number of
 keywords.  The vector or array can be accessed by any command that
-uses local values from a compute as input.  See this
+uses local values from a compute as input.  See this
 section for an overview of LAMMPS output
 options.
 
    
diff --git a/doc/compute_pair_local.txt b/doc/compute_pair_local.txt
index 9caefb5e18..e7b5520aca 100644
--- a/doc/compute_pair_local.txt
+++ b/doc/compute_pair_local.txt
@@ -15,16 +15,20 @@ compute ID group-ID pair/local input1 input2 ... :pre
 ID, group-ID are documented in "compute"_compute.html command :ulb,l
 pair/local = style name of this compute command :l
 zero or more keywords may be appended :l
-keyword = {dist} or {eng} or {force} :l
-  {dist} = tabulate pairwise distances
-  {eng} = tablutate pairwise energies
-  {force} = tablutate pairwise forces :pre
+keyword = {dist} or {eng} or {force} or {fx} or {fy} or {fz} or {fN} :l
+  {dist} = pairwise distance
+  {eng} = pairwise energy
+  {force} = pairwise force
+  {fx},{fy},{fz} = components of pairwise force
+  {pN} = pair style specific quantities for allowed N values :pre
 :ule
 
 [Examples:]
 
 compute 1 all pair/local eng
-compute 1 all pair/local dist eng force :pre
+compute 1 all pair/local dist eng force
+compute 1 all pair/local dist eng fx fy fz
+compute 1 all pair/local dist fx fy fz p1 p2 p3 :pre
 
 [Description:]
 
@@ -40,9 +44,27 @@ force cutoff distance for that interaction, as defined by the
 "pair_style"_pair_style.html and "pair_coeff"_pair_coeff.html
 commands.
 
+The output {dist} is the distance bewteen the pair of atoms.
+
+The output {eng} is the interaction energy for the pair of atoms.
+
+The output {force} is the force acting between the pair of atoms,
+which is positive for a repulsive force and negative for an attractive
+force.  The outputs {fx}, {fy}, and {fz} are the xyz components of
+{force} on atom I.
+
+A pair style may define additional pairwise quantities which can be
+accessed as {p1} to {pN}, where N is defined by the pair style.  Most
+pair styles do not define any additional quantities, so N = 0.  An
+example of ones that do are the "granular pair styles"_pair_gran.html
+which calculate the tangential force between two particles and return
+its components and magnitude acting on atom I for N = 1,2,3,4.  See
+individual pair styles for detils.
+
 The output {dist} will be in distance "units"_units.html.  The output
-{eng} will be in energy "units"_units.html.  The output {force} will
-be in force "units"_units.html.
+{eng} will be in energy "units"_units.html.  The outputs {force},
+{fx}, {fy}, and {fz} will be in force "units"_units.html.  The output
+{pN} will be in whatever units the pair style defines.
 
 Note that as atoms migrate from processor to processor, there will be
 no consistent ordering of the entries within the local vector or array
@@ -54,6 +76,16 @@ property/local"_compute_property_local.html command can be combined
 with data from this command and output by the "dump local"_dump.html
 command in a consistent way.
 
+IMPORTANT NOTE: For pairs, if two atoms I,J are involved in 1-2, 1-3,
+1-4 interactions within the molecular topology, their pairwise
+interaction may be turned off, and thus they may not appear in the
+neighbor list, and will not be part of the local data created by this
+command.  More specifically, this may be true of I,J pairs with a
+weighting factor of 0.0; pairs with a non-zero weighting factor are
+included.  The weighting factors for 1-2, 1-3, and 1-4 pairwise
+interactions are set by the "special_bonds"_special_bonds.html
+command.
+
 [Output info:]
 
 This compute calculates a local vector or local array depending on the
@@ -63,7 +95,7 @@ local vector is produced.  If two or more keywords are specified, a
 local array is produced where the number of columns = the number of
 keywords.  The vector or array can be accessed by any command that
 uses local values from a compute as input.  See "this
-section"_Section_howto.html#4_15 for an overview of LAMMPS output
+section"_Section_howto.html#howto_15 for an overview of LAMMPS output
 options.
 
 The output for {dist} will be in distance "units"_units.html.  The
diff --git a/doc/compute_pe.html b/doc/compute_pe.html
index b7ed4a3d2c..96a25eb42a 100644
--- a/doc/compute_pe.html
+++ b/doc/compute_pe.html
@@ -11,6 +11,8 @@
 
 
    compute pe command 
 
    
+
    compute pe/cuda command 
+
    
 
    Syntax:
 
    
 
    compute ID group-ID pe keyword ... 
@@ -54,12 +56,35 @@ LAMMPS starts up, as if this command were in the input script:
 
    
 
    See the "thermo_style" command for more details.
 
    
+
    
+
+
    Styles with a cuda 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
+this section of the manual.  The accelerated
+styles take the same arguments and should produce the same results,
+except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA package.  They are
+only enabled if LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
 
    Output info:
 
    
 
    This compute calculates a global scalar (the potential energy).  This
 value can be used by any command that uses a global scalar value from
-a compute as input.  See this section for an
-overview of LAMMPS output options.
+a compute as input.  See this section
+for an overview of LAMMPS output options.
 
    
 
    The scalar value calculated by this compute is "extensive".  The
 scalar value will be in energy units.
diff --git a/doc/compute_pe.txt b/doc/compute_pe.txt
index c5f38b019c..46d54268e1 100644
--- a/doc/compute_pe.txt
+++ b/doc/compute_pe.txt
@@ -7,6 +7,7 @@
 :line
 
 compute pe command :h3
+compute pe/cuda command :h3
 
 [Syntax:]
 
@@ -51,12 +52,35 @@ compute thermo_pe all pe :pre
 
 See the "thermo_style" command for more details.
 
+:line
+
+Styles with a {cuda} 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
+"this section"_Section_accelerate.html of the manual.  The accelerated
+styles take the same arguments and should produce the same results,
+except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA package.  They are
+only enabled if LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Output info:]
 
 This compute calculates a global scalar (the potential energy).  This
 value can be used by any command that uses a global scalar value from
-a compute as input.  See "this section"_Section_howto.html#4_15 for an
-overview of LAMMPS output options.
+a compute as input.  See "this section"_Section_howto.html#howto_15
+for an overview of LAMMPS output options.
 
 The scalar value calculated by this compute is "extensive".  The
 scalar value will be in energy "units"_units.html.
diff --git a/doc/compute_pe_atom.html b/doc/compute_pe_atom.html
index 2153229a10..af5f158fc7 100644
--- a/doc/compute_pe_atom.html
+++ b/doc/compute_pe_atom.html
@@ -61,13 +61,16 @@ thermo_style	custom step temp etotal press pe c_pe
 
    IMPORTANT NOTE: The per-atom energy does NOT include contributions due
 to long-range Coulombic interactions (via the
 kspace_style command).  It's not clear this
-contribution can easily be computed.
+contribution can easily be computed.  It also does not include any
+Lennard-Jones tail corrections invoked by the pair_modify tail
+yes command, since those are global contributions to
+the system energy.
 
    
 
    Output info:
 
    
 
    This compute calculates a per-atom vector, which can be accessed by
 any command that uses per-atom values from a compute as input.  See
-this section for an overview of LAMMPS
+this section for an overview of LAMMPS
 output options.
 
    
 
    The per-atom vector values will be in energy units.
diff --git a/doc/compute_pe_atom.txt b/doc/compute_pe_atom.txt
index 8db9b2c4d0..c71dceec48 100644
--- a/doc/compute_pe_atom.txt
+++ b/doc/compute_pe_atom.txt
@@ -58,13 +58,16 @@ thermo_style	custom step temp etotal press pe c_pe :pre
 IMPORTANT NOTE: The per-atom energy does NOT include contributions due
 to long-range Coulombic interactions (via the
 "kspace_style"_kspace_style.html command).  It's not clear this
-contribution can easily be computed.
+contribution can easily be computed.  It also does not include any
+Lennard-Jones tail corrections invoked by the "pair_modify tail
+yes"_pair_modify.html command, since those are global contributions to
+the system energy.
 
 [Output info:]
 
 This compute calculates a per-atom vector, which can be accessed by
 any command that uses per-atom values from a compute as input.  See
-"this section"_Section_howto.html#4_15 for an overview of LAMMPS
+"this section"_Section_howto.html#howto_15 for an overview of LAMMPS
 output options.
 
 The per-atom vector values will be in energy "units"_units.html.
diff --git a/doc/compute_pressure.html b/doc/compute_pressure.html
index 0f7da7ccc8..53cc3132cb 100644
--- a/doc/compute_pressure.html
+++ b/doc/compute_pressure.html
@@ -11,6 +11,8 @@
 
 
    compute pressure command 
 
    
+
    compute pressure/cuda command 
+
    
 
    Syntax:
 
    
 
    compute ID group-ID pressure temp-ID keyword ... 
@@ -84,12 +86,35 @@ LAMMPS starts up, as if this command were in the input script:
 
    where "thermo_temp" is the ID of a similarly defined compute of style
 "temp".  See the "thermo_style" command for more details.
 
    
+
    
+
+
    Styles with a cuda 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
+this section of the manual.  The accelerated
+styles take the same arguments and should produce the same results,
+except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA package.  They are
+only enabled if LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
 
    Output info:
 
    
 
    This compute calculates a global scalar (the pressure) and a global
 vector of length 6 (pressure tensor), which can be accessed by indices
 1-6.  These values can be used by any command that uses global scalar
-or vector values from a compute as input.  See this
+or vector values from a compute as input.  See this
 section for an overview of LAMMPS output
 options.
 
    
diff --git a/doc/compute_pressure.txt b/doc/compute_pressure.txt
index ba6a60cfe7..28d77dd17d 100644
--- a/doc/compute_pressure.txt
+++ b/doc/compute_pressure.txt
@@ -7,6 +7,7 @@
 :line
 
 compute pressure command :h3
+compute pressure/cuda command :h3
 
 [Syntax:]
 
@@ -81,13 +82,36 @@ compute thermo_press all pressure thermo_temp :pre
 where "thermo_temp" is the ID of a similarly defined compute of style
 "temp".  See the "thermo_style" command for more details.
 
+:line
+
+Styles with a {cuda} 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
+"this section"_Section_accelerate.html of the manual.  The accelerated
+styles take the same arguments and should produce the same results,
+except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA package.  They are
+only enabled if LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Output info:]
 
 This compute calculates a global scalar (the pressure) and a global
 vector of length 6 (pressure tensor), which can be accessed by indices
 1-6.  These values can be used by any command that uses global scalar
 or vector values from a compute as input.  See "this
-section"_Section_howto.html#4_15 for an overview of LAMMPS output
+section"_Section_howto.html#howto_15 for an overview of LAMMPS output
 options.
 
 The scalar and vector values calculated by this compute are
diff --git a/doc/compute_property_atom.html b/doc/compute_property_atom.html
index c42669d375..3adf2535dc 100644
--- a/doc/compute_property_atom.html
+++ b/doc/compute_property_atom.html
@@ -24,11 +24,16 @@
 
      possible attributes = id, mol, type, mass,
  	                x, y, z, xs, ys, zs, xu, yu, zu, ix, iy, iz,
 		        vx, vy, vz, fx, fy, fz,
-                        q, mux, muy, muz,
-                        radius, omegax, omegay, omegaz,
-                        angmomx, angmomy, angmomz,
+                        q, mux, muy, muz, mu,
+                        radius, diameter, omegax, omegay, omegaz,
+			angmomx, angmomy, angmomz,
+			shapex,shapey, shapez,
 		        quatw, quati, quatj, quatk, tqx, tqy, tqz,
-			spin, eradius, ervel, erforce 
+			spin, eradius, ervel, erforce
+			end1x, end1y, end1z, end2x, end2y, end2z,
+			corner1x, corner1y, corner1z,
+			corner2x, corner2y, corner2z,
+			corner3x, corner3y, corner3z 
 
    
 
          id = atom ID
       mol = molecule ID
@@ -41,16 +46,20 @@
       vx,vy,vz = atom velocities
       fx,fy,fz = forces on atoms
       q = atom charge
-      mux,muy,muz = orientation of dipolar atom
-      radius = radius of extended spherical particle
+      mux,muy,muz = orientation of dipole moment of atom
+      mu = magnitude of dipole moment of atom
+      radius,diameter = radius,diameter of spherical particle
       omegax,omegay,omegaz = angular velocity of extended particle
       angmomx,angmomy,angmomz = angular momentum of extended particle
+      shapex,shapey,shapez = 3 diameters of aspherical particle
       quatw,quati,quatj,quatk = quaternion components for aspherical particles
       tqx,tqy,tqz = torque on extended particles
       spin = electron spin
       eradius = electron radius
       ervel = electron radial velocity
-      erforce = electron radial force 
+      erforce = electron radial force
+      end12x, end12y, end12z = end points of line segment
+      coner123x, corner123y, corner123z = corner points of triangle 
 
    
 
 
@@ -64,20 +73,39 @@ compute 1 all property/atom ix iy iz
 
    
 
    Define a computation that simply stores atom attributes for each atom
 in the group.  This is useful so that the values can be used by other
-output commands that take computes as
+output commands that take computes as
 inputs.  See for example, the compute reduce,
 fix ave/atom, fix ave/histo,
 fix ave/spatial, and atom-style
 variable commands.
 
    
 
    The list of possible attributes is the same as that used by the dump
-custom command, which describes their meaning.  Basically,
-this list gives your input script access to any per-atom quantity
-stored by LAMMPS.
+custom command, which describes their meaning, with some
+additional quantities that are only defined for certain atom
+styles.  Basically, this list gives your input script
+access to any per-atom quantity stored by LAMMPS.
 
    
-
    The values are stored in a per-atom vector or array as
-discussed below.  Zeroes are stored for atoms not in the specified
-group.
+
    The values are stored in a per-atom vector or array as discussed
+below.  Zeroes are stored for atoms not in the specified group or for
+quantities that are not defined for a particular particle in the group
+(e.g. shapex if the particle is not an ellipsoid).
+
    
+
    The additional quantities only accessible via this command, and not
+directly via the dump custom command, are as follows.
+
    
+
    Shapex, shapey, and shapez are defined for ellipsoidal particles
+and define the 3d shape of each particle.  Quatw, quati, quatj,
+and quatk are also defined for ellipsoidal particles and store the
+4-vector quaternion representing the orientation of each particle.
+See the set command for an explanation of the quaternion
+vector.
+
    
+
    End1x, end1y, end1z, end2x, end2y, end2z, are defined for
+line segment particles and define the end points of each line segment.
+
    
+
    Corner1x, corner1y, corner1z, corner2x, corner2y,
+corner2z, corner3x, corner3y, corner3z, are defined for
+triangular particles and define the corner points of each triangle.
 
    
 
    Output info:
 
    
@@ -86,7 +114,7 @@ on the number of input values.  If a single input is specified, a
 per-atom vector is produced.  If two or more inputs are specified, a
 per-atom array is produced where the number of columns = the number of
 inputs.  The vector or array can be accessed by any command that uses
-per-atom values from a compute as input.  See this
+per-atom values from a compute as input.  See this
 section for an overview of LAMMPS output
 options.
 
    
diff --git a/doc/compute_property_atom.txt b/doc/compute_property_atom.txt
index e66e570cdf..500ca25df4 100644
--- a/doc/compute_property_atom.txt
+++ b/doc/compute_property_atom.txt
@@ -18,12 +18,16 @@ input = one or more atom attributes :l
   possible attributes = id, mol, type, mass,
  	                x, y, z, xs, ys, zs, xu, yu, zu, ix, iy, iz,
 		        vx, vy, vz, fx, fy, fz,
-                        q, mux, muy, muz,
-                        radius, omegax, omegay, omegaz,
-                        angmomx, angmomy, angmomz,
+                        q, mux, muy, muz, mu,
+                        radius, diameter, omegax, omegay, omegaz,
+			angmomx, angmomy, angmomz,
+			shapex,shapey, shapez,
 		        quatw, quati, quatj, quatk, tqx, tqy, tqz,
-			spin, eradius, ervel, erforce :pre
-
+			spin, eradius, ervel, erforce
+			end1x, end1y, end1z, end2x, end2y, end2z,
+			corner1x, corner1y, corner1z,
+			corner2x, corner2y, corner2z,
+			corner3x, corner3y, corner3z :pre
       id = atom ID
       mol = molecule ID
       type = atom type
@@ -35,16 +39,20 @@ input = one or more atom attributes :l
       vx,vy,vz = atom velocities
       fx,fy,fz = forces on atoms
       q = atom charge
-      mux,muy,muz = orientation of dipolar atom
-      radius = radius of extended spherical particle
+      mux,muy,muz = orientation of dipole moment of atom
+      mu = magnitude of dipole moment of atom
+      radius,diameter = radius,diameter of spherical particle
       omegax,omegay,omegaz = angular velocity of extended particle
       angmomx,angmomy,angmomz = angular momentum of extended particle
+      shapex,shapey,shapez = 3 diameters of aspherical particle
       quatw,quati,quatj,quatk = quaternion components for aspherical particles
       tqx,tqy,tqz = torque on extended particles
       spin = electron spin
       eradius = electron radius
       ervel = electron radial velocity
-      erforce = electron radial force :pre
+      erforce = electron radial force
+      end12x, end12y, end12z = end points of line segment
+      coner123x, corner123y, corner123z = corner points of triangle :pre
 :ule
 
 [Examples:]
@@ -57,20 +65,39 @@ compute 1 all property/atom ix iy iz :pre
 
 Define a computation that simply stores atom attributes for each atom
 in the group.  This is useful so that the values can be used by other
-"output commands"_Section_howto.html#4_15 that take computes as
+"output commands"_Section_howto.html#howto_15 that take computes as
 inputs.  See for example, the "compute reduce"_compute_reduce.html,
 "fix ave/atom"_fix_ave_atom.html, "fix ave/histo"_fix_ave_histo.html,
 "fix ave/spatial"_fix_ave_spatial.html, and "atom-style
 variable"_variable.html commands.
 
 The list of possible attributes is the same as that used by the "dump
-custom"_dump.html command, which describes their meaning.  Basically,
-this list gives your input script access to any per-atom quantity
-stored by LAMMPS.
+custom"_dump.html command, which describes their meaning, with some
+additional quantities that are only defined for certain "atom
+styles"_atom_style.html.  Basically, this list gives your input script
+access to any per-atom quantity stored by LAMMPS.
 
-The values are stored in a per-atom vector or array as
-discussed below.  Zeroes are stored for atoms not in the specified
-group.
+The values are stored in a per-atom vector or array as discussed
+below.  Zeroes are stored for atoms not in the specified group or for
+quantities that are not defined for a particular particle in the group
+(e.g. {shapex} if the particle is not an ellipsoid).
+
+The additional quantities only accessible via this command, and not
+directly via the "dump custom"_dump.html command, are as follows.
+
+{Shapex}, {shapey}, and {shapez} are defined for ellipsoidal particles
+and define the 3d shape of each particle.  {Quatw}, {quati}, {quatj},
+and {quatk} are also defined for ellipsoidal particles and store the
+4-vector quaternion representing the orientation of each particle.
+See the "set"_set.html command for an explanation of the quaternion
+vector.
+
+{End1x}, {end1y}, {end1z}, {end2x}, {end2y}, {end2z}, are defined for
+line segment particles and define the end points of each line segment.
+
+{Corner1x}, {corner1y}, {corner1z}, {corner2x}, {corner2y},
+{corner2z}, {corner3x}, {corner3y}, {corner3z}, are defined for
+triangular particles and define the corner points of each triangle.
 
 [Output info:]
 
@@ -80,7 +107,7 @@ per-atom vector is produced.  If two or more inputs are specified, a
 per-atom array is produced where the number of columns = the number of
 inputs.  The vector or array can be accessed by any command that uses
 per-atom values from a compute as input.  See "this
-section"_Section_howto.html#4_15 for an overview of LAMMPS output
+section"_Section_howto.html#howto_15 for an overview of LAMMPS output
 options.
 
 The vector or array values will be in whatever "units"_units.html the
diff --git a/doc/compute_property_local.html b/doc/compute_property_local.html
index 9583f4749d..f7c1a32b1c 100644
--- a/doc/compute_property_local.html
+++ b/doc/compute_property_local.html
@@ -49,9 +49,9 @@ compute 1 all property/local atype aatom2
 
    Description:
 
    
 
    Define a computation that stores the specified attributes as local
-data so it can be accessed by other output
-commands.  If the input attributes refer to
-bond information, then the number of datums generated, aggregated
+data so it can be accessed by other output
+commands.  If the input attributes refer
+to bond information, then the number of datums generated, aggregated
 across all processors, equals the number of bonds in the system.
 Ditto for pairs, angles, etc.
 
    
@@ -95,9 +95,9 @@ by the pair_style command.
 
    
 
    IMPORTANT NOTE: For pairs, if two atoms I,J are involved in 1-2, 1-3,
 1-4 interactions within the molecular topology, their pairwise
-interaction may be turned off, and thus they will not appear in the
+interaction may be turned off, and thus they may not appear in the
 neighbor list, and will not be part of the local data created by this
-command.  More specifically, this is true of I,J pairs with a
+command.  More specifically, this may be true of I,J pairs with a
 weighting factor of 0.0; pairs with a non-zero weighting factor are
 included.  The weighting factors for 1-2, 1-3, and 1-4 pairwise
 interactions are set by the special_bonds
@@ -119,7 +119,7 @@ the array is the number of bonds, angles, etc.  If a single input is
 specified, a local vector is produced.  If two or more inputs are
 specified, a local array is produced where the number of columns = the
 number of inputs.  The vector or array can be accessed by any command
-that uses local values from a compute as input.  See this
+that uses local values from a compute as input.  See this
 section for an overview of LAMMPS output
 options.
 
    
diff --git a/doc/compute_property_local.txt b/doc/compute_property_local.txt
index 1baaedd069..33da51c08e 100644
--- a/doc/compute_property_local.txt
+++ b/doc/compute_property_local.txt
@@ -43,8 +43,8 @@ compute 1 all property/local atype aatom2 :pre
 
 Define a computation that stores the specified attributes as local
 data so it can be accessed by other "output
-commands"_Section_howto.html#4_15.  If the input attributes refer to
-bond information, then the number of datums generated, aggregated
+commands"_Section_howto.html#howto_15.  If the input attributes refer
+to bond information, then the number of datums generated, aggregated
 across all processors, equals the number of bonds in the system.
 Ditto for pairs, angles, etc.
 
@@ -88,9 +88,9 @@ by the "pair_style"_pair_style.html command.
 
 IMPORTANT NOTE: For pairs, if two atoms I,J are involved in 1-2, 1-3,
 1-4 interactions within the molecular topology, their pairwise
-interaction may be turned off, and thus they will not appear in the
+interaction may be turned off, and thus they may not appear in the
 neighbor list, and will not be part of the local data created by this
-command.  More specifically, this is true of I,J pairs with a
+command.  More specifically, this may be true of I,J pairs with a
 weighting factor of 0.0; pairs with a non-zero weighting factor are
 included.  The weighting factors for 1-2, 1-3, and 1-4 pairwise
 interactions are set by the "special_bonds"_special_bonds.html
@@ -113,7 +113,7 @@ specified, a local vector is produced.  If two or more inputs are
 specified, a local array is produced where the number of columns = the
 number of inputs.  The vector or array can be accessed by any command
 that uses local values from a compute as input.  See "this
-section"_Section_howto.html#4_15 for an overview of LAMMPS output
+section"_Section_howto.html#howto_15 for an overview of LAMMPS output
 options.
 
 The vector or array values will be integers that correspond to the
diff --git a/doc/compute_property_molecule.html b/doc/compute_property_molecule.html
index fdb07af960..55cc4955a3 100644
--- a/doc/compute_property_molecule.html
+++ b/doc/compute_property_molecule.html
@@ -34,9 +34,9 @@
 
    Description:
 
    
 
    Define a computation that stores the specified attributes as global
-data so it can be accessed by other output
-commands and used in conjunction with other
-commands that generate per-molecule data, such as compute
+data so it can be accessed by other output
+commands and used in conjunction with
+other commands that generate per-molecule data, such as compute
 com/molecule and compute
 msd/molecule.
 
    
@@ -61,7 +61,7 @@ rows in the array is the number of molecules.  If a single input is
 specified, a global vector is produced.  If two or more inputs are
 specified, a global array is produced where the number of columns =
 the number of inputs.  The vector or array can be accessed by any
-command that uses global values from a compute as input.  See this
+command that uses global values from a compute as input.  See this
 section for an overview of LAMMPS output
 options.
 
    
diff --git a/doc/compute_property_molecule.txt b/doc/compute_property_molecule.txt
index 540dab079c..c2a4cb0d8e 100644
--- a/doc/compute_property_molecule.txt
+++ b/doc/compute_property_molecule.txt
@@ -28,8 +28,8 @@ compute 1 all property/molecule mol :pre
 
 Define a computation that stores the specified attributes as global
 data so it can be accessed by other "output
-commands"_Section_howto.html#4_15 and used in conjunction with other
-commands that generate per-molecule data, such as "compute
+commands"_Section_howto.html#howto_15 and used in conjunction with
+other commands that generate per-molecule data, such as "compute
 com/molecule"_compute_com_molecule.html and "compute
 msd/molecule"_compute_msd_molecule.html.
 
@@ -55,7 +55,7 @@ specified, a global vector is produced.  If two or more inputs are
 specified, a global array is produced where the number of columns =
 the number of inputs.  The vector or array can be accessed by any
 command that uses global values from a compute as input.  See "this
-section"_Section_howto.html#4_15 for an overview of LAMMPS output
+section"_Section_howto.html#howto_15 for an overview of LAMMPS output
 options.
 
 The vector or array values will be integers that correspond to the
diff --git a/doc/compute_rdf.html b/doc/compute_rdf.html
index a6ded207ca..ae66e375bc 100644
--- a/doc/compute_rdf.html
+++ b/doc/compute_rdf.html
@@ -72,19 +72,8 @@ a specific histogram if the following criteria are met:
 
    • atoms I,J are both in the specified compute group
 
    • the distance between atoms I,J is less than the maximum force cutoff
 
    • the type of the I atom matches itypeN (one or a range of types)
-
    • the type of the J atom matches jtypeN (one or a range of types)
-
    • the I,J interaction is included in the neighbor list 
+
    • the type of the J atom matches jtypeN (one or a range of types) 
 
    
-
    IMPORTANT NOTE: The last point is relevant for molecular systems with
-bonds, because if two atoms I,J are involved in 1-2, 1-3, 1-4
-interactions within the molecular topology, their pairwise interaction
-may be turned off, and thus they will not appear in the neighbor list,
-and will not contribute to g(r).  More specifically, this is true of
-I,J pairs with a weighting factor of 0.0; pairs with a non-zero
-weighting factor are included.  The weighting factors for 1-2, 1-3,
-and 1-4 pairwise interactions are set by the
-special_bonds command.
-
    
 
    It is OK if a particular pairwise distance is included in more than
 one individual histogram, due to the way the itypeN and jtypeN
 arguments are specified.
@@ -115,7 +104,7 @@ coordinate (center of the bin), Each successive set of 2 columns has
 the g(r) and coord(r) values for a specific set of itypeN versus
 jtypeN interactions, as described above.  These values can be used
 by any command that uses a global values from a compute as input.  See
-this section for an overview of LAMMPS
+this section for an overview of LAMMPS
 output options.
 
    
 
    The array values calculated by this compute are all "intensive".
diff --git a/doc/compute_rdf.txt b/doc/compute_rdf.txt
index 595087af04..83e835ff3c 100644
--- a/doc/compute_rdf.txt
+++ b/doc/compute_rdf.txt
@@ -69,18 +69,7 @@ a specific histogram if the following criteria are met:
 atoms I,J are both in the specified compute group
 the distance between atoms I,J is less than the maximum force cutoff
 the type of the I atom matches itypeN (one or a range of types)
-the type of the J atom matches jtypeN (one or a range of types)
-the I,J interaction is included in the neighbor list :ul
-
-IMPORTANT NOTE: The last point is relevant for molecular systems with
-bonds, because if two atoms I,J are involved in 1-2, 1-3, 1-4
-interactions within the molecular topology, their pairwise interaction
-may be turned off, and thus they will not appear in the neighbor list,
-and will not contribute to g(r).  More specifically, this is true of
-I,J pairs with a weighting factor of 0.0; pairs with a non-zero
-weighting factor are included.  The weighting factors for 1-2, 1-3,
-and 1-4 pairwise interactions are set by the
-"special_bonds"_special_bonds.html command.
+the type of the J atom matches jtypeN (one or a range of types) :ul
 
 It is OK if a particular pairwise distance is included in more than
 one individual histogram, due to the way the {itypeN} and {jtypeN}
@@ -112,7 +101,7 @@ coordinate (center of the bin), Each successive set of 2 columns has
 the g(r) and coord(r) values for a specific set of {itypeN} versus
 {jtypeN} interactions, as described above.  These values can be used
 by any command that uses a global values from a compute as input.  See
-"this section"_Section_howto.html#4_15 for an overview of LAMMPS
+"this section"_Section_howto.html#howto_15 for an overview of LAMMPS
 output options.
 
 The array values calculated by this compute are all "intensive".
diff --git a/doc/compute_reduce.html b/doc/compute_reduce.html
index d0f6b2505b..f5533307e5 100644
--- a/doc/compute_reduce.html
+++ b/doc/compute_reduce.html
@@ -173,8 +173,8 @@ divides by the appropriate atom count.
 specified or a global vector of length N where N is the number of
 inputs, and which can be accessed by indices 1 to N.  These values can
 be used by any command that uses global scalar or vector values from a
-compute as input.  See this section for an
-overview of LAMMPS output options.
+compute as input.  See this section for
+an overview of LAMMPS output options.
 
    
 
    All the scalar or vector values calculated by this compute are
 "intensive", except when the sum mode is used on per-atom or local
diff --git a/doc/compute_reduce.txt b/doc/compute_reduce.txt
index 043e79fd59..135f83eefe 100644
--- a/doc/compute_reduce.txt
+++ b/doc/compute_reduce.txt
@@ -160,8 +160,8 @@ This compute calculates a global scalar if a single input value is
 specified or a global vector of length N where N is the number of
 inputs, and which can be accessed by indices 1 to N.  These values can
 be used by any command that uses global scalar or vector values from a
-compute as input.  See "this section"_Section_howto.html#4_15 for an
-overview of LAMMPS output options.
+compute as input.  See "this section"_Section_howto.html#howto_15 for
+an overview of LAMMPS output options.
 
 All the scalar or vector values calculated by this compute are
 "intensive", except when the {sum} mode is used on per-atom or local
diff --git a/doc/compute_slice.html b/doc/compute_slice.html
new file mode 100644
index 0000000000..a48710c249
--- /dev/null
+++ b/doc/compute_slice.html
@@ -0,0 +1,124 @@
+
+
    LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
    
+
+
+
+
+
+
+
    
+
+
    compute slice command 
+
    
+
    Syntax:
+
    
+
    compute ID group-ID slice Nstart Nstop Nskip input1 input2 ... 
+
    
+
    • ID, group-ID are documented in compute command 
+
+
    • slice = style name of this compute command 
+
+
    • Nstart = starting index within input vector(s) 
+
+
    • Nstop = stopping index within input vector(s) 
+
+
    • Nskip = extract every Nskip elements from input vector(s) 
+
+
    • input = c_ID, c_ID[N], f_ID, f_ID[N] 
+
+
        c_ID = global vector calculated by a compute with ID
+  c_ID[I] = Ith column of global array calculated by a compute with ID
+  f_ID = global vector calculated by a fix with ID
+  f_ID[I] = Ith column of global array calculated by a fix with ID 
+
      
+
+
    
+
    Examples:
+
    
+
    compute 1 all slice 1 100 10 c_msdmol[4]
+compute 1 all slice 301 400 1 c_msdmol[4] 
+
    
+
    Description:
+
    
+
    Define a calculation that "slices" one or more vector inputs into
+smaller vectors, one per listed input.  The inputs can be global
+quantities; they cannot be per-atom or local quantities.
+Computes and fixes may generate any of the
+three kinds of quantities.  Variables do not generate
+global vectors.  The group specified with this command is ignored.
+
    
+
    The values extracted from the input vector(s) are determined by the
+Nstart, Nstop, and Nskip parameters.  The elements of an input
+vector of length N are indexed from 1 to N.  Starting at element
+Nstart, every Mth element is extracted, where M = Nskip, until
+element Nstop is reached.  The extracted quantities are stored as a
+vector, which is typically shorter than the input vector.
+
    
+
    Each listed input is operated on independently to produce one output
+vector.  Each listed input must be a global vector or column of a
+global array calculated by another compute or
+fix.
+
    
+
    If an input value begins with "c_", a compute ID must follow which has
+been previously defined in the input script and which generates a
+global vector or array.  See the individual compute doc
+page for details.  If no bracketed integer is appended, the vector
+calculated by the compute is used.  If a bracketed interger is
+appended, the Ith column of the array calculated by the compute is
+used.  Users can also write code for their own compute styles and add
+them to LAMMPS.
+
    
+
    If a value begins with "f_", a fix ID must follow which has been
+previously defined in the input script and which generates a global
+vector or array.  See the individual fix doc page for
+details.  Note that some fixes only produce their values on certain
+timesteps, which must be compatible with when compute slice references
+the values, else an error results.  If no bracketed integer is
+appended, the vector calculated by the fix is used.  If a bracketed
+integer is appended, the Ith column of the array calculated by the fix
+is used.  Users can also write code for their own fix style and add
+them to LAMMPS.
+
    
+
    If a single input is specified this compute produces a global vector,
+even if the length of the vector is 1.  If multiple inputs are
+specified, then a global array of values is produced, with the number
+of columns equal to the number of inputs specified.
+
    
+
    
+
+
    Output info:
+
    
+
    This compute calculates a global vector if a single input value is
+specified or a global array with N columns where N is the number of
+inputs.  The length of the vector or the number of rows in the array
+is equal to the number of values extracted from each input vector.
+These values can be used by any command that uses global vector or
+array values from a compute as input.  See this
+section for an overview of LAMMPS output
+options.
+
    
+
    The vector or array values calculated by this compute are simply
+copies of values generated by computes or fixes that are input vectors
+to this compute.  If there is a single input vector of intensive
+and/or extensive values, then each value in the vector of values
+calculated by this compute will be "intensive" or "extensive",
+depending on the corresponding input value.  If there are multiple
+input vectors, and all the values in them are intensive, then the
+array values calculated by this compute are "intensive".  If there are
+multiple input vectors, and any value in them is extensive, then the
+array values calculated by this compute are "extensive".
+
    
+
    The vector or array values will be in whatever units the
+input quantities are in.
+
    
+
    Restrictions: none
+
    
+
    Related commands:
+
    
+
    compute, fix, compute
+reduce
+
    
+
    Default: none
+
    
+
diff --git a/doc/compute_slice.txt b/doc/compute_slice.txt
new file mode 100644
index 0000000000..fea181dd2d
--- /dev/null
+++ b/doc/compute_slice.txt
@@ -0,0 +1,112 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+compute slice command :h3
+
+[Syntax:]
+
+compute ID group-ID slice Nstart Nstop Nskip input1 input2 ... :pre
+
+ID, group-ID are documented in "compute"_compute.html command :ulb,l
+slice = style name of this compute command :l
+Nstart = starting index within input vector(s) :l
+Nstop = stopping index within input vector(s) :l
+Nskip = extract every Nskip elements from input vector(s) :l
+input = c_ID, c_ID\[N\], f_ID, f_ID\[N\] :l
+  c_ID = global vector calculated by a compute with ID
+  c_ID\[I\] = Ith column of global array calculated by a compute with ID
+  f_ID = global vector calculated by a fix with ID
+  f_ID\[I\] = Ith column of global array calculated by a fix with ID :pre
+:ule
+
+[Examples:]
+
+compute 1 all slice 1 100 10 c_msdmol\[4\]
+compute 1 all slice 301 400 1 c_msdmol\[4\] :pre
+
+[Description:]
+
+Define a calculation that "slices" one or more vector inputs into
+smaller vectors, one per listed input.  The inputs can be global
+quantities; they cannot be per-atom or local quantities.
+"Computes"_compute.html and "fixes"_fix.html may generate any of the
+three kinds of quantities.  "Variables"_variable.html do not generate
+global vectors.  The group specified with this command is ignored.
+
+The values extracted from the input vector(s) are determined by the
+{Nstart}, {Nstop}, and {Nskip} parameters.  The elements of an input
+vector of length N are indexed from 1 to N.  Starting at element
+{Nstart}, every Mth element is extracted, where M = {Nskip}, until
+element {Nstop} is reached.  The extracted quantities are stored as a
+vector, which is typically shorter than the input vector.
+
+Each listed input is operated on independently to produce one output
+vector.  Each listed input must be a global vector or column of a
+global array calculated by another "compute"_compute.html or
+"fix"_fix.html.
+
+If an input value begins with "c_", a compute ID must follow which has
+been previously defined in the input script and which generates a
+global vector or array.  See the individual "compute"_compute.html doc
+page for details.  If no bracketed integer is appended, the vector
+calculated by the compute is used.  If a bracketed interger is
+appended, the Ith column of the array calculated by the compute is
+used.  Users can also write code for their own compute styles and "add
+them to LAMMPS"_Section_modify.html.
+
+If a value begins with "f_", a fix ID must follow which has been
+previously defined in the input script and which generates a global
+vector or array.  See the individual "fix"_fix.html doc page for
+details.  Note that some fixes only produce their values on certain
+timesteps, which must be compatible with when compute slice references
+the values, else an error results.  If no bracketed integer is
+appended, the vector calculated by the fix is used.  If a bracketed
+integer is appended, the Ith column of the array calculated by the fix
+is used.  Users can also write code for their own fix style and "add
+them to LAMMPS"_Section_modify.html.
+
+If a single input is specified this compute produces a global vector,
+even if the length of the vector is 1.  If multiple inputs are
+specified, then a global array of values is produced, with the number
+of columns equal to the number of inputs specified.
+
+:line
+
+[Output info:]
+
+This compute calculates a global vector if a single input value is
+specified or a global array with N columns where N is the number of
+inputs.  The length of the vector or the number of rows in the array
+is equal to the number of values extracted from each input vector.
+These values can be used by any command that uses global vector or
+array values from a compute as input.  See "this
+section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+options.
+
+The vector or array values calculated by this compute are simply
+copies of values generated by computes or fixes that are input vectors
+to this compute.  If there is a single input vector of intensive
+and/or extensive values, then each value in the vector of values
+calculated by this compute will be "intensive" or "extensive",
+depending on the corresponding input value.  If there are multiple
+input vectors, and all the values in them are intensive, then the
+array values calculated by this compute are "intensive".  If there are
+multiple input vectors, and any value in them is extensive, then the
+array values calculated by this compute are "extensive".
+
+The vector or array values will be in whatever "units"_units.html the
+input quantities are in.
+
+[Restrictions:] none
+
+[Related commands:]
+
+"compute"_compute.html, "fix"_fix.html, "compute
+reduce"_compute_reduce.html
+
+[Default:] none
diff --git a/doc/compute_stress_atom.html b/doc/compute_stress_atom.html
index c85d572fce..f39d75300f 100644
--- a/doc/compute_stress_atom.html
+++ b/doc/compute_stress_atom.html
@@ -102,8 +102,8 @@ contribution can easily be computed.
 
    
 
    This compute calculates a per-atom array with 6 columns, which can be
 accessed by indices 1-6 by any command that uses per-atom values from
-a compute as input.  See this section for an
-overview of LAMMPS output options.
+a compute as input.  See this section
+for an overview of LAMMPS output options.
 
    
 
    The per-atom array values will be in pressure*volume
 units as discussed above.
diff --git a/doc/compute_stress_atom.txt b/doc/compute_stress_atom.txt
index d055334842..f8d073397f 100644
--- a/doc/compute_stress_atom.txt
+++ b/doc/compute_stress_atom.txt
@@ -99,8 +99,8 @@ contribution can easily be computed.
 
 This compute calculates a per-atom array with 6 columns, which can be
 accessed by indices 1-6 by any command that uses per-atom values from
-a compute as input.  See "this section"_Section_howto.html#4_15 for an
-overview of LAMMPS output options.
+a compute as input.  See "this section"_Section_howto.html#howto_15
+for an overview of LAMMPS output options.
 
 The per-atom array values will be in pressure*volume
 "units"_units.html as discussed above.
diff --git a/doc/compute_temp.html b/doc/compute_temp.html
index 9c7209c9ec..6005da58da 100644
--- a/doc/compute_temp.html
+++ b/doc/compute_temp.html
@@ -11,6 +11,8 @@
 
 
    compute temp command 
 
    
+
    compute temp/cuda command 
+
    
 
    Syntax:
 
    
 
    compute ID group-ID temp 
@@ -60,16 +62,39 @@ LAMMPS starts up, as if this command were in the input script:
 
    
 
    See the "thermo_style" command for more details.
 
    
-
    See this howto section of the manual for a
-discussion of different ways to compute temperature and perform
+
    See this howto section of the manual for
+a discussion of different ways to compute temperature and perform
 thermostatting.
 
    
+
    
+
+
    Styles with a cuda 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
+this section of the manual.  The accelerated
+styles take the same arguments and should produce the same results,
+except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA package.  They are
+only enabled if LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
 
    Output info:
 
    
 
    This compute calculates a global scalar (the temperature) and a global
 vector of length 6 (KE tensor), which can be accessed by indices 1-6.
 These values can be used by any command that uses global scalar or
-vector values from a compute as input.  See this
+vector values from a compute as input.  See this
 section for an overview of LAMMPS output
 options.
 
    
diff --git a/doc/compute_temp.txt b/doc/compute_temp.txt
index 32bb3658a9..7915e86835 100644
--- a/doc/compute_temp.txt
+++ b/doc/compute_temp.txt
@@ -7,6 +7,7 @@
 :line
 
 compute temp command :h3
+compute temp/cuda command :h3
 
 [Syntax:]
 
@@ -57,17 +58,40 @@ compute thermo_temp all temp :pre
 
 See the "thermo_style" command for more details.
 
-See "this howto section"_Section_howto.html#4_16 of the manual for a
-discussion of different ways to compute temperature and perform
+See "this howto section"_Section_howto.html#howto_16 of the manual for
+a discussion of different ways to compute temperature and perform
 thermostatting.
 
+:line
+
+Styles with a {cuda} 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
+"this section"_Section_accelerate.html of the manual.  The accelerated
+styles take the same arguments and should produce the same results,
+except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA package.  They are
+only enabled if LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Output info:]
 
 This compute calculates a global scalar (the temperature) and a global
 vector of length 6 (KE tensor), which can be accessed by indices 1-6.
 These values can be used by any command that uses global scalar or
 vector values from a compute as input.  See "this
-section"_Section_howto.html#4_15 for an overview of LAMMPS output
+section"_Section_howto.html#howto_15 for an overview of LAMMPS output
 options.
 
 The scalar value calculated by this compute is "intensive".  The
diff --git a/doc/compute_temp_asphere.html b/doc/compute_temp_asphere.html
index c4d63513e2..59b32f6951 100644
--- a/doc/compute_temp_asphere.html
+++ b/doc/compute_temp_asphere.html
@@ -13,16 +13,29 @@
 
 
    Syntax:
 
    
-
    compute ID group-ID temp/asphere bias-ID 
+
    compute ID group-ID temp/asphere keyword value ... 
 
    
-
    • ID, group-ID are documented in compute command
-
    • temp/asphere = style name of this compute command
-
    • bias-ID = ID of a temperature compute that removes a velocity bias (optional) 
+
      • ID, group-ID are documented in compute command 
+
+
      • temp/asphere = style name of this compute command 
+
+
      • zero or more keyword/value pairs may be appended 
+
+
      • keyword = bias or dof 
+
+
          bias value = bias-IDuniform or gaussian
+    bias-ID = ID of a temperature compute that removes a velocity bias
+  dof value = all or rotate
+    all = compute temperature of translational and rotational degrees of freedom
+    rotate = compute temperature of just rotational degrees of freedom 
+
        
+
 
      
 
      Examples:
 
      
 
      compute 1 all temp/asphere
-compute myTemp mobile temp/asphere tempCOM 
+compute myTemp mobile temp/asphere bias tempCOM
+compute myTemp mobile temp/asphere dof rotate 
 
      
 
      Description:
 
      
@@ -47,13 +60,12 @@ this is not the case.  Then there are less dof and you should use the
 compute_modify extra command to adjust the dof
 accordingly.
 
      
-
      For example, an aspherical particle with all three of its
-shape parameters the same is a sphere.  If it does not
-rotate, then it should have 3 dof instead of 6 in 3d (or 2 instead of
-3 in 2d).  A uniaxial aspherical particle has two of its three shape
-parameters the same.  If it does not rotate around the axis
-perpendicular to its circular cross section, then it should have 5 dof
-instead of 6 in 3d.
+
      For example, an aspherical particle with all three of its shape
+parameters the same is a sphere.  If it does not rotate, then it
+should have 3 dof instead of 6 in 3d (or 2 instead of 3 in 2d).  A
+uniaxial aspherical particle has two of its three shape parameters the
+same.  If it does not rotate around the axis perpendicular to its
+circular cross section, then it should have 5 dof instead of 6 in 3d.
 
      
 
      The translational kinetic energy is computed the same as is described
 by the compute temp command.  The rotational
@@ -76,15 +88,6 @@ vector are ordered xx, yy, zz, xy, xz, yz.
 constant for the duration of the run; use the dynamic option of the
 compute_modify command if this is not the case.
 
      
-
      If a bias-ID is specified it must be the ID of a temperature compute
-that removes a "bias" velocity from each atom.  This allows compute
-temp/sphere to compute its thermal temperature after the translational
-kinetic energy components have been altered in a prescribed way,
-e.g. to remove a velocity profile.  Thermostats that use this compute
-will work with this bias term.  See the doc pages for individual
-computes that calculate a temperature and the doc pages for fixes that
-perform thermostatting for more details.
-
      
 
      This compute subtracts out translational degrees-of-freedom due to
 fixes that constrain molecular motion, such as fix
 shake and fix rigid.  This means the
@@ -93,16 +96,36 @@ computed correctly.  If needed, the subtracted degrees-of-freedom can
 be altered using the extra option of the
 compute_modify command.
 
      
-
      See this howto section of the manual for a
-discussion of different ways to compute temperature and perform
+
      See this howto section of the manual for
+a discussion of different ways to compute temperature and perform
 thermostatting.
 
      
+
      
+
+
      The keyword/value option pairs are used in the following ways.
+
      
+
      For the bias keyword, bias-ID refers to the ID of a temperature
+compute that removes a "bias" velocity from each atom.  This allows
+compute temp/sphere to compute its thermal temperature after the
+translational kinetic energy components have been altered in a
+prescribed way, e.g. to remove a velocity profile.  Thermostats that
+use this compute will work with this bias term.  See the doc pages for
+individual computes that calculate a temperature and the doc pages for
+fixes that perform thermostatting for more details.
+
      
+
      For the dof keyword, a setting of all calculates a temperature
+that includes both translational and rotational degrees of freedom.  A
+setting of rotate calculates a temperature that includes only
+rotational degrees of freedom.
+
      
+
      
+
 
      Output info:
 
      
 
      This compute calculates a global scalar (the temperature) and a global
 vector of length 6 (KE tensor), which can be accessed by indices 1-6.
 These values can be used by any command that uses global scalar or
-vector values from a compute as input.  See this
+vector values from a compute as input.  See this
 section for an overview of LAMMPS output
 options.
 
      
@@ -114,10 +137,17 @@ vector values will be in energy units.
 
      
 
      Restrictions:
 
      
-
      This compute requires that particles be represented as extended
-ellipsoids and not point particles.  This means they will have an
-angular momentum and a shape which is determined by the
-shape command.
+
      This compute is part of the ASPHERE package.  It is only enabled if
+LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
      
+
      This compute requires that atoms store angular momementum and a
+quaternion as defined by the atom_style ellipsoid
+command.
+
      
+
      All particles in the group must be finite-size.  They cannot be point
+particles, but they can be aspherical or spherical as defined by their
+shape attribute.
 
      
 
      Related commands:
 
      
diff --git a/doc/compute_temp_asphere.txt b/doc/compute_temp_asphere.txt
index 5dc003b27d..019c1f72c7 100755
--- a/doc/compute_temp_asphere.txt
+++ b/doc/compute_temp_asphere.txt
@@ -10,16 +10,24 @@ compute temp/asphere command :h3
 
 [Syntax:]
 
-compute ID group-ID temp/asphere bias-ID :pre
+compute ID group-ID temp/asphere keyword value ... :pre
 
-ID, group-ID are documented in "compute"_compute.html command
-temp/asphere = style name of this compute command
-bias-ID = ID of a temperature compute that removes a velocity bias (optional) :ul
+ID, group-ID are documented in "compute"_compute.html command :ulb,l
+temp/asphere = style name of this compute command :l
+zero or more keyword/value pairs may be appended :l
+keyword = {bias} or {dof} :l
+  {bias} value = bias-ID{uniform} or {gaussian}
+    bias-ID = ID of a temperature compute that removes a velocity bias
+  {dof} value = {all} or {rotate}
+    all = compute temperature of translational and rotational degrees of freedom
+    rotate = compute temperature of just rotational degrees of freedom :pre
+:ule
 
 [Examples:]
 
 compute 1 all temp/asphere
-compute myTemp mobile temp/asphere tempCOM :pre
+compute myTemp mobile temp/asphere bias tempCOM
+compute myTemp mobile temp/asphere dof rotate :pre
 
 [Description:]
 
@@ -44,13 +52,12 @@ this is not the case.  Then there are less dof and you should use the
 "compute_modify extra"_compute_modify.html command to adjust the dof
 accordingly.
 
-For example, an aspherical particle with all three of its
-"shape"_shape.html parameters the same is a sphere.  If it does not
-rotate, then it should have 3 dof instead of 6 in 3d (or 2 instead of
-3 in 2d).  A uniaxial aspherical particle has two of its three shape
-parameters the same.  If it does not rotate around the axis
-perpendicular to its circular cross section, then it should have 5 dof
-instead of 6 in 3d.
+For example, an aspherical particle with all three of its shape
+parameters the same is a sphere.  If it does not rotate, then it
+should have 3 dof instead of 6 in 3d (or 2 instead of 3 in 2d).  A
+uniaxial aspherical particle has two of its three shape parameters the
+same.  If it does not rotate around the axis perpendicular to its
+circular cross section, then it should have 5 dof instead of 6 in 3d.
 
 The translational kinetic energy is computed the same as is described
 by the "compute temp"_compute_temp.html command.  The rotational
@@ -73,15 +80,6 @@ The number of atoms contributing to the temperature is assumed to be
 constant for the duration of the run; use the {dynamic} option of the
 "compute_modify"_compute_modify.html command if this is not the case.
 
-If a {bias-ID} is specified it must be the ID of a temperature compute
-that removes a "bias" velocity from each atom.  This allows compute
-temp/sphere to compute its thermal temperature after the translational
-kinetic energy components have been altered in a prescribed way,
-e.g. to remove a velocity profile.  Thermostats that use this compute
-will work with this bias term.  See the doc pages for individual
-computes that calculate a temperature and the doc pages for fixes that
-perform thermostatting for more details.
-
 This compute subtracts out translational degrees-of-freedom due to
 fixes that constrain molecular motion, such as "fix
 shake"_fix_shake.html and "fix rigid"_fix_rigid.html.  This means the
@@ -90,17 +88,37 @@ computed correctly.  If needed, the subtracted degrees-of-freedom can
 be altered using the {extra} option of the
 "compute_modify"_compute_modify.html command.
 
-See "this howto section"_Section_howto.html#4_16 of the manual for a
-discussion of different ways to compute temperature and perform
+See "this howto section"_Section_howto.html#howto_16 of the manual for
+a discussion of different ways to compute temperature and perform
 thermostatting.
 
+:line
+
+The keyword/value option pairs are used in the following ways.
+
+For the {bias} keyword, {bias-ID} refers to the ID of a temperature
+compute that removes a "bias" velocity from each atom.  This allows
+compute temp/sphere to compute its thermal temperature after the
+translational kinetic energy components have been altered in a
+prescribed way, e.g. to remove a velocity profile.  Thermostats that
+use this compute will work with this bias term.  See the doc pages for
+individual computes that calculate a temperature and the doc pages for
+fixes that perform thermostatting for more details.
+
+For the {dof} keyword, a setting of {all} calculates a temperature
+that includes both translational and rotational degrees of freedom.  A
+setting of {rotate} calculates a temperature that includes only
+rotational degrees of freedom.
+
+:line
+
 [Output info:]
 
 This compute calculates a global scalar (the temperature) and a global
 vector of length 6 (KE tensor), which can be accessed by indices 1-6.
 These values can be used by any command that uses global scalar or
 vector values from a compute as input.  See "this
-section"_Section_howto.html#4_15 for an overview of LAMMPS output
+section"_Section_howto.html#howto_15 for an overview of LAMMPS output
 options.
 
 The scalar value calculated by this compute is "intensive".  The
@@ -111,10 +129,17 @@ vector values will be in energy "units"_units.html.
 
 [Restrictions:]
 
-This compute requires that particles be represented as extended
-ellipsoids and not point particles.  This means they will have an
-angular momentum and a shape which is determined by the
-"shape"_shape.html command.
+This compute is part of the ASPHERE package.  It is only enabled if
+LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+This compute requires that atoms store angular momementum and a
+quaternion as defined by the "atom_style ellipsoid"_atom_style.html
+command.
+
+All particles in the group must be finite-size.  They cannot be point
+particles, but they can be aspherical or spherical as defined by their
+shape attribute.
 
 [Related commands:]
 
diff --git a/doc/compute_temp_com.html b/doc/compute_temp_com.html
index d55c85a074..5635c606d3 100644
--- a/doc/compute_temp_com.html
+++ b/doc/compute_temp_com.html
@@ -68,8 +68,8 @@ atoms that include these constraints will be computed correctly.  If
 needed, the subtracted degrees-of-freedom can be altered using the
 extra option of the compute_modify command.
 
      
-
      See this howto section of the manual for a
-discussion of different ways to compute temperature and perform
+
      See this howto section of the manual for
+a discussion of different ways to compute temperature and perform
 thermostatting.
 
      
 
      Output info:
@@ -77,7 +77,7 @@ thermostatting.
 
      This compute calculates a global scalar (the temperature) and a global
 vector of length 6 (KE tensor), which can be accessed by indices 1-6.
 These values can be used by any command that uses global scalar or
-vector values from a compute as input.  See this
+vector values from a compute as input.  See this
 section for an overview of LAMMPS output
 options.
 
      
diff --git a/doc/compute_temp_com.txt b/doc/compute_temp_com.txt
index 80cc4ea737..c7cc5ec4e2 100644
--- a/doc/compute_temp_com.txt
+++ b/doc/compute_temp_com.txt
@@ -65,8 +65,8 @@ atoms that include these constraints will be computed correctly.  If
 needed, the subtracted degrees-of-freedom can be altered using the
 {extra} option of the "compute_modify"_compute_modify.html command.
 
-See "this howto section"_Section_howto.html#4_16 of the manual for a
-discussion of different ways to compute temperature and perform
+See "this howto section"_Section_howto.html#howto_16 of the manual for
+a discussion of different ways to compute temperature and perform
 thermostatting.
 
 [Output info:]
@@ -75,7 +75,7 @@ This compute calculates a global scalar (the temperature) and a global
 vector of length 6 (KE tensor), which can be accessed by indices 1-6.
 These values can be used by any command that uses global scalar or
 vector values from a compute as input.  See "this
-section"_Section_howto.html#4_15 for an overview of LAMMPS output
+section"_Section_howto.html#howto_15 for an overview of LAMMPS output
 options.
 
 The scalar value calculated by this compute is "intensive".  The
diff --git a/doc/compute_temp_deform.html b/doc/compute_temp_deform.html
index 31ba8d6776..def9a12187 100644
--- a/doc/compute_temp_deform.html
+++ b/doc/compute_temp_deform.html
@@ -92,8 +92,8 @@ atoms that include these constraints will be computed correctly.  If
 needed, the subtracted degrees-of-freedom can be altered using the
 extra option of the compute_modify command.
 
      
-
      See this howto section of the manual for a
-discussion of different ways to compute temperature and perform
+
      See this howto section of the manual for
+a discussion of different ways to compute temperature and perform
 thermostatting.
 
      
 
      Output info:
@@ -101,7 +101,7 @@ thermostatting.
 
      This compute calculates a global scalar (the temperature) and a global
 vector of length 6 (KE tensor), which can be accessed by indices 1-6.
 These values can be used by any command that uses global scalar or
-vector values from a compute as input.  See this
+vector values from a compute as input.  See this
 section for an overview of LAMMPS output
 options.
 
      
diff --git a/doc/compute_temp_deform.txt b/doc/compute_temp_deform.txt
index 26703f1d02..02b7ca3c22 100644
--- a/doc/compute_temp_deform.txt
+++ b/doc/compute_temp_deform.txt
@@ -89,8 +89,8 @@ atoms that include these constraints will be computed correctly.  If
 needed, the subtracted degrees-of-freedom can be altered using the
 {extra} option of the "compute_modify"_compute_modify.html command.
 
-See "this howto section"_Section_howto.html#4_16 of the manual for a
-discussion of different ways to compute temperature and perform
+See "this howto section"_Section_howto.html#howto_16 of the manual for
+a discussion of different ways to compute temperature and perform
 thermostatting.
 
 [Output info:]
@@ -99,7 +99,7 @@ This compute calculates a global scalar (the temperature) and a global
 vector of length 6 (KE tensor), which can be accessed by indices 1-6.
 These values can be used by any command that uses global scalar or
 vector values from a compute as input.  See "this
-section"_Section_howto.html#4_15 for an overview of LAMMPS output
+section"_Section_howto.html#howto_15 for an overview of LAMMPS output
 options.
 
 The scalar value calculated by this compute is "intensive".  The
diff --git a/doc/compute_temp_deform_eff.html b/doc/compute_temp_deform_eff.html
index 90dcd7c767..6331c8e915 100644
--- a/doc/compute_temp_deform_eff.html
+++ b/doc/compute_temp_deform_eff.html
@@ -51,7 +51,7 @@ component of the electrons is not affected.
 
      This compute calculates a global scalar (the temperature) and a global
 vector of length 6 (KE tensor), which can be accessed by indices 1-6.
 These values can be used by any command that uses global scalar or
-vector values from a compute as input.  See this
+vector values from a compute as input.  See this
 section for an overview of LAMMPS output
 options.
 
      
@@ -63,8 +63,8 @@ vector values will be in energy units.
 
      
 
      Restrictions:
 
      
-
      This compute is part of the "user-eff" package.  It is only enabled if
-LAMMPS was built with that package.  See the Making
+
      This compute is part of the USER-EFF package.  It is only enabled if
+LAMMPS was built with that package.  See the Making
 LAMMPS section for more info.
 
      
 
      Related commands:
diff --git a/doc/compute_temp_deform_eff.txt b/doc/compute_temp_deform_eff.txt
index 4ae48a79f2..199fa5fdc4 100644
--- a/doc/compute_temp_deform_eff.txt
+++ b/doc/compute_temp_deform_eff.txt
@@ -49,7 +49,7 @@ This compute calculates a global scalar (the temperature) and a global
 vector of length 6 (KE tensor), which can be accessed by indices 1-6.
 These values can be used by any command that uses global scalar or
 vector values from a compute as input.  See "this
-section"_Section_howto.html#4_15 for an overview of LAMMPS output
+section"_Section_howto.html#howto_15 for an overview of LAMMPS output
 options.
 
 The scalar value calculated by this compute is "intensive".  The
@@ -60,9 +60,9 @@ vector values will be in energy "units"_units.html.
 
 [Restrictions:]
 
-This compute is part of the "user-eff" package.  It is only enabled if
+This compute is part of the USER-EFF package.  It is only enabled if
 LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+LAMMPS"_Section_start.html#start_3 section for more info.
 
 [Related commands:]
 
diff --git a/doc/compute_temp_eff.html b/doc/compute_temp_eff.html
index 466ed3bd4b..3cc20e9db7 100644
--- a/doc/compute_temp_eff.html
+++ b/doc/compute_temp_eff.html
@@ -72,8 +72,8 @@ atoms that include these constraints will be computed correctly.  If
 needed, the subtracted degrees-of-freedom can be altered using the
 extra option of the compute_modify command.
 
      
-
      See this howto section of the manual for a
-discussion of different ways to compute temperature and perform
+
      See this howto section of the manual for
+a discussion of different ways to compute temperature and perform
 thermostatting.
 
      
 
      Output info:
@@ -85,8 +85,8 @@ the simulation.
 
      
 
      Restrictions: 
 
      
-
      This compute is part of the "user-eff" package.  It is only enabled if
-LAMMPS was built with that package.  See the Making
+
      This compute is part of the USER-EFF package.  It is only enabled if
+LAMMPS was built with that package.  See the Making
 LAMMPS section for more info.
 
      
 
      Related commands:
diff --git a/doc/compute_temp_eff.txt b/doc/compute_temp_eff.txt
index cb9b274dfa..194aaa3c7b 100644
--- a/doc/compute_temp_eff.txt
+++ b/doc/compute_temp_eff.txt
@@ -69,8 +69,8 @@ atoms that include these constraints will be computed correctly.  If
 needed, the subtracted degrees-of-freedom can be altered using the
 {extra} option of the "compute_modify"_compute_modify.html command.
 
-See "this howto section"_Section_howto.html#4_16 of the manual for a
-discussion of different ways to compute temperature and perform
+See "this howto section"_Section_howto.html#howto_16 of the manual for
+a discussion of different ways to compute temperature and perform
 thermostatting.
 
 [Output info:]
@@ -82,9 +82,9 @@ the simulation.
 
 [Restrictions:] 
 
-This compute is part of the "user-eff" package.  It is only enabled if
+This compute is part of the USER-EFF package.  It is only enabled if
 LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+LAMMPS"_Section_start.html#start_3 section for more info.
 
 [Related commands:]
 
diff --git a/doc/compute_temp_partial.html b/doc/compute_temp_partial.html
index 9ea238c850..c076a2be52 100644
--- a/doc/compute_temp_partial.html
+++ b/doc/compute_temp_partial.html
@@ -11,6 +11,8 @@
 
 
      compute temp/partial command 
 
      
+
      compute temp/partial/cuda command 
+
      
 
      Syntax:
 
      
 
      compute ID group-ID temp/partial xflag yflag zflag 
@@ -68,16 +70,39 @@ atoms that include these constraints will be computed correctly.  If
 needed, the subtracted degrees-of-freedom can be altered using the
 extra option of the compute_modify command.
 
      
-
      See this howto section of the manual for a
-discussion of different ways to compute temperature and perform
+
      See this howto section of the manual for
+a discussion of different ways to compute temperature and perform
 thermostatting.
 
      
+
      
+
+
      Styles with a cuda 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
+this section of the manual.  The accelerated
+styles take the same arguments and should produce the same results,
+except for round-off and precision issues.
+
      
+
      These accelerated styles are part of the USER-CUDA package.  They are
+only enabled if LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
      
+
      You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
      
+
      See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
      
+
      
+
 
      Output info:
 
      
 
      This compute calculates a global scalar (the temperature) and a global
 vector of length 6 (KE tensor), which can be accessed by indices 1-6.
 These values can be used by any command that uses global scalar or
-vector values from a compute as input.  See this
+vector values from a compute as input.  See this
 section for an overview of LAMMPS output
 options.
 
      
diff --git a/doc/compute_temp_partial.txt b/doc/compute_temp_partial.txt
index 7b999f69c3..ab5d42f9d0 100644
--- a/doc/compute_temp_partial.txt
+++ b/doc/compute_temp_partial.txt
@@ -7,6 +7,7 @@
 :line
 
 compute temp/partial command :h3
+compute temp/partial/cuda command :h3
 
 [Syntax:]
 
@@ -65,17 +66,40 @@ atoms that include these constraints will be computed correctly.  If
 needed, the subtracted degrees-of-freedom can be altered using the
 {extra} option of the "compute_modify"_compute_modify.html command.
 
-See "this howto section"_Section_howto.html#4_16 of the manual for a
-discussion of different ways to compute temperature and perform
+See "this howto section"_Section_howto.html#howto_16 of the manual for
+a discussion of different ways to compute temperature and perform
 thermostatting.
 
+:line
+
+Styles with a {cuda} 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
+"this section"_Section_accelerate.html of the manual.  The accelerated
+styles take the same arguments and should produce the same results,
+except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA package.  They are
+only enabled if LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Output info:]
 
 This compute calculates a global scalar (the temperature) and a global
 vector of length 6 (KE tensor), which can be accessed by indices 1-6.
 These values can be used by any command that uses global scalar or
 vector values from a compute as input.  See "this
-section"_Section_howto.html#4_15 for an overview of LAMMPS output
+section"_Section_howto.html#howto_15 for an overview of LAMMPS output
 options.
 
 The scalar value calculated by this compute is "intensive".  The
diff --git a/doc/compute_temp_profile.html b/doc/compute_temp_profile.html
index 242674a005..52a9f67dfd 100644
--- a/doc/compute_temp_profile.html
+++ b/doc/compute_temp_profile.html
@@ -106,8 +106,8 @@ atoms that include these constraints will be computed correctly.  If
 needed, the subtracted degrees-of-freedom can be altered using the
 extra option of the compute_modify command.
 
      
-
      See this howto section of the manual for a
-discussion of different ways to compute temperature and perform
+
      See this howto section of the manual for
+a discussion of different ways to compute temperature and perform
 thermostatting.  Using this compute in conjunction with a
 thermostatting fix, as explained there, will effectively implement a
 profile-unbiased thermostat (PUT), as described in (Evans).
@@ -117,7 +117,7 @@ profile-unbiased thermostat (PUT), as described in (Evans)This compute calculates a global scalar (the temperature) and a global
 vector of length 6 (KE tensor), which can be accessed by indices 1-6.
 These values can be used by any command that uses global scalar or
-vector values from a compute as input.  See this
+vector values from a compute as input.  See this
 section for an overview of LAMMPS output
 options.
 
      
diff --git a/doc/compute_temp_profile.txt b/doc/compute_temp_profile.txt
index bf2d921287..8eaae69483 100644
--- a/doc/compute_temp_profile.txt
+++ b/doc/compute_temp_profile.txt
@@ -98,8 +98,8 @@ atoms that include these constraints will be computed correctly.  If
 needed, the subtracted degrees-of-freedom can be altered using the
 {extra} option of the "compute_modify"_compute_modify.html command.
 
-See "this howto section"_Section_howto.html#4_16 of the manual for a
-discussion of different ways to compute temperature and perform
+See "this howto section"_Section_howto.html#howto_16 of the manual for
+a discussion of different ways to compute temperature and perform
 thermostatting.  Using this compute in conjunction with a
 thermostatting fix, as explained there, will effectively implement a
 profile-unbiased thermostat (PUT), as described in "(Evans)"_#Evans.
@@ -110,7 +110,7 @@ This compute calculates a global scalar (the temperature) and a global
 vector of length 6 (KE tensor), which can be accessed by indices 1-6.
 These values can be used by any command that uses global scalar or
 vector values from a compute as input.  See "this
-section"_Section_howto.html#4_15 for an overview of LAMMPS output
+section"_Section_howto.html#howto_15 for an overview of LAMMPS output
 options.
 
 The scalar value calculated by this compute is "intensive".  The
diff --git a/doc/compute_temp_ramp.html b/doc/compute_temp_ramp.html
index fa8b6b0ecf..686ad9cd61 100644
--- a/doc/compute_temp_ramp.html
+++ b/doc/compute_temp_ramp.html
@@ -87,8 +87,8 @@ atoms that include these constraints will be computed correctly.  If
 needed, the subtracted degrees-of-freedom can be altered using the
 extra option of the compute_modify command.
 
      
-
      See this howto section of the manual for a
-discussion of different ways to compute temperature and perform
+
      See this howto section of the manual for
+a discussion of different ways to compute temperature and perform
 thermostatting.
 
      
 
      Output info:
@@ -96,7 +96,7 @@ thermostatting.
 
      This compute calculates a global scalar (the temperature) and a global
 vector of length 6 (KE tensor), which can be accessed by indices 1-6.
 These values can be used by any command that uses global scalar or
-vector values from a compute as input.  See this
+vector values from a compute as input.  See this
 section for an overview of LAMMPS output
 options.
 
      
diff --git a/doc/compute_temp_ramp.txt b/doc/compute_temp_ramp.txt
index 4f1ccc5963..bc9283469c 100644
--- a/doc/compute_temp_ramp.txt
+++ b/doc/compute_temp_ramp.txt
@@ -83,8 +83,8 @@ atoms that include these constraints will be computed correctly.  If
 needed, the subtracted degrees-of-freedom can be altered using the
 {extra} option of the "compute_modify"_compute_modify.html command.
 
-See "this howto section"_Section_howto.html#4_16 of the manual for a
-discussion of different ways to compute temperature and perform
+See "this howto section"_Section_howto.html#howto_16 of the manual for
+a discussion of different ways to compute temperature and perform
 thermostatting.
 
 [Output info:]
@@ -93,7 +93,7 @@ This compute calculates a global scalar (the temperature) and a global
 vector of length 6 (KE tensor), which can be accessed by indices 1-6.
 These values can be used by any command that uses global scalar or
 vector values from a compute as input.  See "this
-section"_Section_howto.html#4_15 for an overview of LAMMPS output
+section"_Section_howto.html#howto_15 for an overview of LAMMPS output
 options.
 
 The scalar value calculated by this compute is "intensive".  The
diff --git a/doc/compute_temp_region.html b/doc/compute_temp_region.html
index 260dd408b4..62f57cacac 100644
--- a/doc/compute_temp_region.html
+++ b/doc/compute_temp_region.html
@@ -79,8 +79,8 @@ constrain molecular motion, such as fix shake and
 degrees-of-freedom can be altered using the extra option of the
 compute_modify command.
 
      
-
      See this howto section of the manual for a
-discussion of different ways to compute temperature and perform
+
      See this howto section of the manual for
+a discussion of different ways to compute temperature and perform
 thermostatting.
 
      
 
      Output info:
@@ -88,7 +88,7 @@ thermostatting.
 
      This compute calculates a global scalar (the temperature) and a global
 vector of length 6 (KE tensor), which can be accessed by indices 1-6.
 These values can be used by any command that uses global scalar or
-vector values from a compute as input.  See this
+vector values from a compute as input.  See this
 section for an overview of LAMMPS output
 options.
 
      
diff --git a/doc/compute_temp_region.txt b/doc/compute_temp_region.txt
index 0733eb7a41..c617eeb7a6 100644
--- a/doc/compute_temp_region.txt
+++ b/doc/compute_temp_region.txt
@@ -76,8 +76,8 @@ constrain molecular motion, such as "fix shake"_fix_shake.html and
 degrees-of-freedom can be altered using the {extra} option of the
 "compute_modify"_compute_modify.html command.
 
-See "this howto section"_Section_howto.html#4_16 of the manual for a
-discussion of different ways to compute temperature and perform
+See "this howto section"_Section_howto.html#howto_16 of the manual for
+a discussion of different ways to compute temperature and perform
 thermostatting.
 
 [Output info:]
@@ -86,7 +86,7 @@ This compute calculates a global scalar (the temperature) and a global
 vector of length 6 (KE tensor), which can be accessed by indices 1-6.
 These values can be used by any command that uses global scalar or
 vector values from a compute as input.  See "this
-section"_Section_howto.html#4_15 for an overview of LAMMPS output
+section"_Section_howto.html#howto_15 for an overview of LAMMPS output
 options.
 
 The scalar value calculated by this compute is "intensive".  The
diff --git a/doc/compute_temp_region_eff.html b/doc/compute_temp_region_eff.html
index a4d7d37b3a..e4e84b9e8c 100644
--- a/doc/compute_temp_region_eff.html
+++ b/doc/compute_temp_region_eff.html
@@ -42,7 +42,7 @@ temp/eff command.
 
      This compute calculates a global scalar (the temperature) and a global
 vector of length 6 (KE tensor), which can be accessed by indices 1-6.
 These values can be used by any command that uses global scalar or
-vector values from a compute as input.  See this
+vector values from a compute as input.  See this
 section for an overview of LAMMPS output
 options.
 
      
@@ -54,8 +54,8 @@ vector values will be in energy units.
 
      
 
      Restrictions:
 
      
-
      This compute is part of the "user-eff" package.  It is only enabled if
-LAMMPS was built with that package.  See the Making
+
      This compute is part of the USER-EFF package.  It is only enabled if
+LAMMPS was built with that package.  See the Making
 LAMMPS section for more info.
 
      
 
      Related commands:
diff --git a/doc/compute_temp_region_eff.txt b/doc/compute_temp_region_eff.txt
index 72585eb694..8baf2dd46c 100644
--- a/doc/compute_temp_region_eff.txt
+++ b/doc/compute_temp_region_eff.txt
@@ -40,7 +40,7 @@ This compute calculates a global scalar (the temperature) and a global
 vector of length 6 (KE tensor), which can be accessed by indices 1-6.
 These values can be used by any command that uses global scalar or
 vector values from a compute as input.  See "this
-section"_Section_howto.html#4_15 for an overview of LAMMPS output
+section"_Section_howto.html#howto_15 for an overview of LAMMPS output
 options.
 
 The scalar value calculated by this compute is "intensive".  The
@@ -51,9 +51,9 @@ vector values will be in energy "units"_units.html.
 
 [Restrictions:]
 
-This compute is part of the "user-eff" package.  It is only enabled if
+This compute is part of the USER-EFF package.  It is only enabled if
 LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+LAMMPS"_Section_start.html#start_3 section for more info.
 
 [Related commands:]
 
diff --git a/doc/compute_temp_rotate.html b/doc/compute_temp_rotate.html
new file mode 100644
index 0000000000..cbd3a31042
--- /dev/null
+++ b/doc/compute_temp_rotate.html
@@ -0,0 +1,101 @@
+
+
      LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
      
+
+
+
+
+
+
+
      
+
+
      compute temp/rotate command 
+
      
+
      Syntax:
+
      
+
      compute ID group-ID temp/rotate 
+
      
+
      • ID, group-ID are documented in compute command
+
      • temp/rotate = style name of this compute command 
+
      
+
      Examples:
+
      
+
      compute Tbead bead temp/rotate 
+
      
+
      Description:
+
      
+
      Define a computation that calculates the temperature of a group of
+atoms, after subtracting out the center-of-mass velocity and angular velocity of the group.
+This is useful if the group is expected to have a non-zero net
+velocity and/or global rotation motion for some reason.  A compute of this style can be used by any
+command that computes a temperature,
+e.g. thermo_modify, fix
+temp/rescale, fix npt, etc.
+
      
+
      After the center-of-mass velocity and angular velocity has been subtracted from each atom,
+the temperature is calculated by the formula KE = dim/2 N k T, where
+KE = total kinetic energy of the group of atoms (sum of 1/2 m v^2),
+dim = 2 or 3 = dimensionality of the simulation, N = number of atoms
+in the group, k = Boltzmann constant, and T = temperature.
+
      
+
      A kinetic energy tensor, stored as a 6-element vector, is also
+calculated by this compute for use in the computation of a pressure
+tensor.  The formula for the components of the tensor is the same as
+the above formula, except that v^2 is replaced by vx*vy for the xy
+component, etc.  The 6 components of the vector are ordered xx, yy,
+zz, xy, xz, yz.
+
      
+
      The number of atoms contributing to the temperature is assumed to be
+constant for the duration of the run; use the dynamic option of the
+compute_modify command if this is not the case.
+
      
+
      The removal of the center-of-mass velocity and angular velocity by this fix is essentially
+computing the temperature after a "bias" has been removed from the
+velocity of the atoms.  If this compute is used with a fix command
+that performs thermostatting then this bias will be subtracted from
+each atom, thermostatting of the remaining thermal velocity will be
+performed, and the bias will be added back in.  Thermostatting fixes
+that work in this way include fix nvt, fix
+temp/rescale, fix
+temp/berendsen, and fix
+langevin.
+
      
+
      This compute subtracts out degrees-of-freedom due to fixes that
+constrain molecular motion, such as fix shake and
+fix rigid.  This means the temperature of groups of
+atoms that include these constraints will be computed correctly.  If
+needed, the subtracted degrees-of-freedom can be altered using the
+extra option of the compute_modify command.
+
      
+
      See this howto section of the manual for
+a discussion of different ways to compute temperature and perform
+thermostatting.
+
      
+
      Output info:
+
      
+
      This compute calculates a global scalar (the temperature) and a global
+vector of length 6 (KE tensor), which can be accessed by indices 1-6.
+These values can be used by any command that uses global scalar or
+vector values from a compute as input.  See this
+section for an overview of LAMMPS output
+options.
+
      
+
      The scalar value calculated by this compute is "intensive".  The
+vector values are "extensive".
+
      
+
      The scalar value will be in temperature units.  The
+vector values will be in energy units.
+
      
+
      Restrictions:
+
      
+
      This compute is part of the USER-MISC package.  It is only enabled if
+LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
      
+
      Related commands:
+
      
+
      compute temp
+
      
+
      Default: none
+
      
+
diff --git a/doc/compute_temp_rotate.txt b/doc/compute_temp_rotate.txt
new file mode 100644
index 0000000000..34feca7b6f
--- /dev/null
+++ b/doc/compute_temp_rotate.txt
@@ -0,0 +1,96 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+compute temp/rotate command :h3
+
+[Syntax:]
+
+compute ID group-ID temp/rotate :pre
+
+ID, group-ID are documented in "compute"_compute.html command
+temp/rotate = style name of this compute command :ul
+
+[Examples:]
+
+compute Tbead bead temp/rotate :pre
+
+[Description:]
+
+Define a computation that calculates the temperature of a group of
+atoms, after subtracting out the center-of-mass velocity and angular velocity of the group.
+This is useful if the group is expected to have a non-zero net
+velocity and/or global rotation motion for some reason.  A compute of this style can be used by any
+command that computes a temperature,
+e.g. "thermo_modify"_thermo_modify.html, "fix
+temp/rescale"_fix_temp_rescale.html, "fix npt"_fix_nh.html, etc.
+
+After the center-of-mass velocity and angular velocity has been subtracted from each atom,
+the temperature is calculated by the formula KE = dim/2 N k T, where
+KE = total kinetic energy of the group of atoms (sum of 1/2 m v^2),
+dim = 2 or 3 = dimensionality of the simulation, N = number of atoms
+in the group, k = Boltzmann constant, and T = temperature.
+
+A kinetic energy tensor, stored as a 6-element vector, is also
+calculated by this compute for use in the computation of a pressure
+tensor.  The formula for the components of the tensor is the same as
+the above formula, except that v^2 is replaced by vx*vy for the xy
+component, etc.  The 6 components of the vector are ordered xx, yy,
+zz, xy, xz, yz.
+
+The number of atoms contributing to the temperature is assumed to be
+constant for the duration of the run; use the {dynamic} option of the
+"compute_modify"_compute_modify.html command if this is not the case.
+
+The removal of the center-of-mass velocity and angular velocity by this fix is essentially
+computing the temperature after a "bias" has been removed from the
+velocity of the atoms.  If this compute is used with a fix command
+that performs thermostatting then this bias will be subtracted from
+each atom, thermostatting of the remaining thermal velocity will be
+performed, and the bias will be added back in.  Thermostatting fixes
+that work in this way include "fix nvt"_fix_nh.html, "fix
+temp/rescale"_fix_temp_rescale.html, "fix
+temp/berendsen"_fix_temp_berendsen.html, and "fix
+langevin"_fix_langevin.html.
+
+This compute subtracts out degrees-of-freedom due to fixes that
+constrain molecular motion, such as "fix shake"_fix_shake.html and
+"fix rigid"_fix_rigid.html.  This means the temperature of groups of
+atoms that include these constraints will be computed correctly.  If
+needed, the subtracted degrees-of-freedom can be altered using the
+{extra} option of the "compute_modify"_compute_modify.html command.
+
+See "this howto section"_Section_howto.html#howto_16 of the manual for
+a discussion of different ways to compute temperature and perform
+thermostatting.
+
+[Output info:]
+
+This compute calculates a global scalar (the temperature) and a global
+vector of length 6 (KE tensor), which can be accessed by indices 1-6.
+These values can be used by any command that uses global scalar or
+vector values from a compute as input.  See "this
+section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+options.
+
+The scalar value calculated by this compute is "intensive".  The
+vector values are "extensive".
+
+The scalar value will be in temperature "units"_units.html.  The
+vector values will be in energy "units"_units.html.
+
+[Restrictions:]
+
+This compute is part of the USER-MISC package.  It is only enabled if
+LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+[Related commands:]
+
+"compute temp"_compute_temp.html
+
+[Default:] none
diff --git a/doc/compute_temp_sphere.html b/doc/compute_temp_sphere.html
index 020a9757bf..923dab5045 100644
--- a/doc/compute_temp_sphere.html
+++ b/doc/compute_temp_sphere.html
@@ -13,16 +13,29 @@
 
 
      Syntax:
 
      
-
      compute ID group-ID temp/sphere bias-ID 
+
      compute ID group-ID temp/sphere keyword value ... 
 
      
-
      • ID, group-ID are documented in compute command
-
      • temp/sphere = style name of this compute command
-
      • bias-ID = ID of a temperature compute that removes a velocity bias (optional) 
+
        • ID, group-ID are documented in compute command 
+
+
        • temp/sphere = style name of this compute command 
+
+
        • zero or more keyword/value pairs may be appended 
+
+
        • keyword = bias or dof 
+
+
            bias value = bias-IDuniform or gaussian
+    bias-ID = ID of a temperature compute that removes a velocity bias
+  dof value = all or rotate
+    all = compute temperature of translational and rotational degrees of freedom
+    rotate = compute temperature of just rotational degrees of freedom 
+
          
+
 
        
 
        Examples:
 
        
 
        compute 1 all temp/sphere
-compute myTemp mobile temp/sphere tempCOM 
+compute myTemp mobile temp/sphere bias tempCOM
+compute myTemp mobile temp/sphere dof rotate 
 
        
 
        Description:
 
        
@@ -33,10 +46,10 @@ usual compute temp command, which assumes poin
 particles with only translational kinetic energy.
 
        
 
        Both point and finite-size particles can be included in the group.
-Point particles do not rotate, so they have only translational degrees
-of freedom.  For 3d spherical particles, each has 6 degrees of freedom
-(3 translational, 3 rotational).  For 2d spherical particles, each has
-3 degrees of freedom (2 translational, 1 rotational).
+Point particles do not rotate, so they have only 3 translational
+degrees of freedom.  For 3d spherical particles, each has 6 degrees of
+freedom (3 translational, 3 rotational).  For 2d spherical particles,
+each has 3 degrees of freedom (2 translational, 1 rotational).
 
        
 
        IMPORTANT NOTE: This choice for degrees of freedom (dof) assumes that
 all finite-size spherical particles in your model will freely rotate,
@@ -66,15 +79,6 @@ the vector are ordered xx, yy, zz, xy, xz, yz.
 constant for the duration of the run; use the dynamic option of the
 compute_modify command if this is not the case.
 
        
-
        If a bias-ID is specified it must be the ID of a temperature compute
-that removes a "bias" velocity from each atom.  This allows compute
-temp/sphere to compute its thermal temperature after the translational
-kinetic energy components have been altered in a prescribed way,
-e.g. to remove a velocity profile.  Thermostats that use this compute
-will work with this bias term.  See the doc pages for individual
-computes that calculate a temperature and the doc pages for fixes that
-perform thermostatting for more details.
-
        
 
        This compute subtracts out translational degrees-of-freedom due to
 fixes that constrain molecular motion, such as fix
 shake and fix rigid.  This means the
@@ -83,16 +87,36 @@ computed correctly.  If needed, the subtracted degrees-of-freedom can
 be altered using the extra option of the
 compute_modify command.
 
        
-
        See this howto section of the manual for a
-discussion of different ways to compute temperature and perform
+
        See this howto section of the manual for
+a discussion of different ways to compute temperature and perform
 thermostatting.
 
        
+
        
+
+
        The keyword/value option pairs are used in the following ways.
+
        
+
        For the bias keyword, bias-ID refers to the ID of a temperature
+compute that removes a "bias" velocity from each atom.  This allows
+compute temp/sphere to compute its thermal temperature after the
+translational kinetic energy components have been altered in a
+prescribed way, e.g. to remove a velocity profile.  Thermostats that
+use this compute will work with this bias term.  See the doc pages for
+individual computes that calculate a temperature and the doc pages for
+fixes that perform thermostatting for more details.
+
        
+
        For the dof keyword, a setting of all calculates a temperature
+that includes both translational and rotational degrees of freedom.  A
+setting of rotate calculates a temperature that includes only
+rotational degrees of freedom.
+
        
+
        
+
 
        Output info:
 
        
 
        This compute calculates a global scalar (the temperature) and a global
 vector of length 6 (KE tensor), which can be accessed by indices 1-6.
 These values can be used by any command that uses global scalar or
-vector values from a compute as input.  See this
+vector values from a compute as input.  See this
 section for an overview of LAMMPS output
 options.
 
        
@@ -104,17 +128,20 @@ vector values will be in energy units.
 
        
 
        Restrictions:
 
        
-
        This compute requires that particles be represented as extended
-spheres and not point particles.  This means they will have an angular
-velocity and a diameter which is determined either by the
-shape command or by each particle being assigned an
-individual radius, e.g. for atom_style granular.
+
        This fix requires that atoms store torque and angular velocity (omega)
+and a radius as defined by the atom_style sphere
+command.  
+
        
+
        All particles in the group must be finite-size spheres, or point
+particles with radius = 0.0.
 
        
 
        Related commands:
 
        
 
        compute temp, compute
 temp/asphere
 
        
-
        Default: none
+
        Default:
+
        
+
        The option defaults are no bias and dof = all.
 
        
 
diff --git a/doc/compute_temp_sphere.txt b/doc/compute_temp_sphere.txt
index 5ba53641d1..24885e2378 100755
--- a/doc/compute_temp_sphere.txt
+++ b/doc/compute_temp_sphere.txt
@@ -10,16 +10,24 @@ compute temp/sphere command :h3
 
 [Syntax:]
 
-compute ID group-ID temp/sphere bias-ID :pre
+compute ID group-ID temp/sphere keyword value ... :pre
 
-ID, group-ID are documented in "compute"_compute.html command
-temp/sphere = style name of this compute command
-bias-ID = ID of a temperature compute that removes a velocity bias (optional) :ul
+ID, group-ID are documented in "compute"_compute.html command :ulb,l
+temp/sphere = style name of this compute command :l
+zero or more keyword/value pairs may be appended :l
+keyword = {bias} or {dof} :l
+  {bias} value = bias-ID{uniform} or {gaussian}
+    bias-ID = ID of a temperature compute that removes a velocity bias
+  {dof} value = {all} or {rotate}
+    all = compute temperature of translational and rotational degrees of freedom
+    rotate = compute temperature of just rotational degrees of freedom :pre
+:ule
 
 [Examples:]
 
 compute 1 all temp/sphere
-compute myTemp mobile temp/sphere tempCOM :pre
+compute myTemp mobile temp/sphere bias tempCOM
+compute myTemp mobile temp/sphere dof rotate :pre
 
 [Description:]
 
@@ -30,10 +38,10 @@ usual "compute temp"_compute_temp.html command, which assumes point
 particles with only translational kinetic energy.
 
 Both point and finite-size particles can be included in the group.
-Point particles do not rotate, so they have only translational degrees
-of freedom.  For 3d spherical particles, each has 6 degrees of freedom
-(3 translational, 3 rotational).  For 2d spherical particles, each has
-3 degrees of freedom (2 translational, 1 rotational).
+Point particles do not rotate, so they have only 3 translational
+degrees of freedom.  For 3d spherical particles, each has 6 degrees of
+freedom (3 translational, 3 rotational).  For 2d spherical particles,
+each has 3 degrees of freedom (2 translational, 1 rotational).
 
 IMPORTANT NOTE: This choice for degrees of freedom (dof) assumes that
 all finite-size spherical particles in your model will freely rotate,
@@ -63,15 +71,6 @@ The number of atoms contributing to the temperature is assumed to be
 constant for the duration of the run; use the {dynamic} option of the
 "compute_modify"_compute_modify.html command if this is not the case.
 
-If a {bias-ID} is specified it must be the ID of a temperature compute
-that removes a "bias" velocity from each atom.  This allows compute
-temp/sphere to compute its thermal temperature after the translational
-kinetic energy components have been altered in a prescribed way,
-e.g. to remove a velocity profile.  Thermostats that use this compute
-will work with this bias term.  See the doc pages for individual
-computes that calculate a temperature and the doc pages for fixes that
-perform thermostatting for more details.
-
 This compute subtracts out translational degrees-of-freedom due to
 fixes that constrain molecular motion, such as "fix
 shake"_fix_shake.html and "fix rigid"_fix_rigid.html.  This means the
@@ -80,17 +79,37 @@ computed correctly.  If needed, the subtracted degrees-of-freedom can
 be altered using the {extra} option of the
 "compute_modify"_compute_modify.html command.
 
-See "this howto section"_Section_howto.html#4_16 of the manual for a
-discussion of different ways to compute temperature and perform
+See "this howto section"_Section_howto.html#howto_16 of the manual for
+a discussion of different ways to compute temperature and perform
 thermostatting.
 
+:line
+
+The keyword/value option pairs are used in the following ways.
+
+For the {bias} keyword, {bias-ID} refers to the ID of a temperature
+compute that removes a "bias" velocity from each atom.  This allows
+compute temp/sphere to compute its thermal temperature after the
+translational kinetic energy components have been altered in a
+prescribed way, e.g. to remove a velocity profile.  Thermostats that
+use this compute will work with this bias term.  See the doc pages for
+individual computes that calculate a temperature and the doc pages for
+fixes that perform thermostatting for more details.
+
+For the {dof} keyword, a setting of {all} calculates a temperature
+that includes both translational and rotational degrees of freedom.  A
+setting of {rotate} calculates a temperature that includes only
+rotational degrees of freedom.
+
+:line
+
 [Output info:]
 
 This compute calculates a global scalar (the temperature) and a global
 vector of length 6 (KE tensor), which can be accessed by indices 1-6.
 These values can be used by any command that uses global scalar or
 vector values from a compute as input.  See "this
-section"_Section_howto.html#4_15 for an overview of LAMMPS output
+section"_Section_howto.html#howto_15 for an overview of LAMMPS output
 options.
 
 The scalar value calculated by this compute is "intensive".  The
@@ -101,15 +120,18 @@ vector values will be in energy "units"_units.html.
 
 [Restrictions:]
 
-This compute requires that particles be represented as extended
-spheres and not point particles.  This means they will have an angular
-velocity and a diameter which is determined either by the
-"shape"_shape.html command or by each particle being assigned an
-individual radius, e.g. for "atom_style granular"_atom_style.html.
+This fix requires that atoms store torque and angular velocity (omega)
+and a radius as defined by the "atom_style sphere"_atom_style.html
+command.  
+
+All particles in the group must be finite-size spheres, or point
+particles with radius = 0.0.
 
 [Related commands:]
 
 "compute temp"_compute_temp.html, "compute
 temp/asphere"_compute_temp.html
 
-[Default:] none
+[Default:]
+
+The option defaults are no bias and dof = all.
diff --git a/doc/compute_ti.html b/doc/compute_ti.html
index 404f33e821..4e997fb1c5 100644
--- a/doc/compute_ti.html
+++ b/doc/compute_ti.html
@@ -102,8 +102,8 @@ du/dl can be found in the paper by Eike.
 
        
 
        This compute calculates a global scalar, namely dUs/dlambda.  This
 value can be used by any command that uses a global scalar value from
-a compute as input.  See this section for an
-overview of LAMMPS output options.
+a compute as input.  See this section
+for an overview of LAMMPS output options.
 
        
 
        The scalar value calculated by this compute is "extensive".
 
        
diff --git a/doc/compute_ti.txt b/doc/compute_ti.txt
index 39078cbd28..1d8041ae97 100644
--- a/doc/compute_ti.txt
+++ b/doc/compute_ti.txt
@@ -94,8 +94,8 @@ du/dl can be found in the paper by "Eike"_#Eike.
 
 This compute calculates a global scalar, namely dUs/dlambda.  This
 value can be used by any command that uses a global scalar value from
-a compute as input.  See "this section"_Section_howto.html#4_15 for an
-overview of LAMMPS output options.
+a compute as input.  See "this section"_Section_howto.html#howto_15
+for an overview of LAMMPS output options.
 
 The scalar value calculated by this compute is "extensive".
 
diff --git a/doc/create_atoms.html b/doc/create_atoms.html
index 89bd0a535f..30ae86cb05 100644
--- a/doc/create_atoms.html
+++ b/doc/create_atoms.html
@@ -146,20 +146,30 @@ style command for more details.  See the
 to change these values.
 
        
 
        • charge = 0.0
-
        • dipole moment = 0.0
+
        • dipole moment magnitude = 0.0
 
        • diameter = 1.0
-
        • volume = 1.0
+
        • shape = 0.0 0.0 0.0
 
        • density = 1.0
-
        • velocity = 0.0
-
        • angular velocity = 0.0
-
        • angular momentum = 0.0
+
        • volume = 1.0
+
        • velocity = 0.0 0.0 0.0
+
        • angular velocity = 0.0 0.0 0.0
+
        • angular momentum = 0.0 0.0 0.0
 
        • quaternion = (1,0,0,0)
 
        • bonds, angles, dihedrals, impropers = none 
 
        
-
        The granular style sets the diameter and density to 1.0 and
-calculates a mass for the particle, which is PI/6 * diameter^3 =
-0.5236.  The peri style sets the volume and density to 1.0 and
-calculates a mass for the particle, which is also 1.0.
+
        Note that the sphere atom style sets the default particle diameter
+to 1.0 as well as the density.  This means the mass for the particle
+is not 1.0, but is PI/6 * diameter^3 = 0.5236.
+
        
+
        Note that the ellipsoid atom style sets the default particle shape
+to (0.0 0.0 0.0) and the density to 1.0 which means it is a point
+particle, not an ellipsoid, and has a mass of 1.0.
+
        
+
        Note that the peri style sets the default volume and density to 1.0
+and thus also set the mass for the particle to 1.0.
+
        
+
        The set command can be used to override many of these
+default settings.
 
        
 
        Restrictions:
 
        
diff --git a/doc/create_atoms.txt b/doc/create_atoms.txt
index ab39e8ca26..e96081d041 100644
--- a/doc/create_atoms.txt
+++ b/doc/create_atoms.txt
@@ -137,20 +137,30 @@ style"_atom_style.html command for more details.  See the
 to change these values.
 
 charge = 0.0
-dipole moment = 0.0
+dipole moment magnitude = 0.0
 diameter = 1.0
-volume = 1.0
+shape = 0.0 0.0 0.0
 density = 1.0
-velocity = 0.0
-angular velocity = 0.0
-angular momentum = 0.0
+volume = 1.0
+velocity = 0.0 0.0 0.0
+angular velocity = 0.0 0.0 0.0
+angular momentum = 0.0 0.0 0.0
 quaternion = (1,0,0,0)
 bonds, angles, dihedrals, impropers = none :ul
 
-The {granular} style sets the diameter and density to 1.0 and
-calculates a mass for the particle, which is PI/6 * diameter^3 =
-0.5236.  The {peri} style sets the volume and density to 1.0 and
-calculates a mass for the particle, which is also 1.0.
+Note that the {sphere} atom style sets the default particle diameter
+to 1.0 as well as the density.  This means the mass for the particle
+is not 1.0, but is PI/6 * diameter^3 = 0.5236.
+
+Note that the {ellipsoid} atom style sets the default particle shape
+to (0.0 0.0 0.0) and the density to 1.0 which means it is a point
+particle, not an ellipsoid, and has a mass of 1.0.
+
+Note that the {peri} style sets the default volume and density to 1.0
+and thus also set the mass for the particle to 1.0.
+
+The "set"_set.html command can be used to override many of these
+default settings.
 
 [Restrictions:]
 
diff --git a/doc/create_box.html b/doc/create_box.html
index a4c2a918b0..974af9ee35 100644
--- a/doc/create_box.html
+++ b/doc/create_box.html
@@ -55,7 +55,7 @@ since if the maximum tilt factor is 5 (as in this example), then
 configurations with tilt = ..., -15, -5, 5, 15, 25, ... are all
 geometrically equivalent.
 
        
-
        See this section of the doc pages for a
+
        See this section 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.
diff --git a/doc/create_box.txt b/doc/create_box.txt
index 3576b815fc..247486503a 100644
--- a/doc/create_box.txt
+++ b/doc/create_box.txt
@@ -52,7 +52,7 @@ since if the maximum tilt factor is 5 (as in this example), then
 configurations with tilt = ..., -15, -5, 5, 15, 25, ... are all
 geometrically equivalent.
 
-See "this section"_Section_howto.html#4_12 of the doc pages for a
+See "this section"_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.
diff --git a/doc/delete_atoms.html b/doc/delete_atoms.html
index bb780a84cf..02cc1e2726 100644
--- a/doc/delete_atoms.html
+++ b/doc/delete_atoms.html
@@ -42,7 +42,7 @@
 delete_atoms region sphere compress no
 delete_atoms overlap 0.3 all all
 delete_atoms overlap 0.5 solvent colloid
-delete_atoms porosity cube 0.1 
+delete_atoms porosity cube 0.1 482793 
 
      
 
      Description:
 
      
diff --git a/doc/delete_atoms.txt b/doc/delete_atoms.txt
index f8c6b58044..5a613a352b 100644
--- a/doc/delete_atoms.txt
+++ b/doc/delete_atoms.txt
@@ -34,7 +34,7 @@ delete_atoms group edge
 delete_atoms region sphere compress no
 delete_atoms overlap 0.3 all all
 delete_atoms overlap 0.5 solvent colloid
-delete_atoms porosity cube 0.1 :pre
+delete_atoms porosity cube 0.1 482793 :pre
 
 [Description:]
 
diff --git a/doc/dihedral_charmm.html b/doc/dihedral_charmm.html
index 8030eab9ea..6c3104c6e3 100644
--- a/doc/dihedral_charmm.html
+++ b/doc/dihedral_charmm.html
@@ -11,6 +11,8 @@
 
 
      dihedral_style charmm command 
 
      
+
      dihedral_style charmm/omp command 
+
      
 
      Syntax:
 
      
 
      dihedral_style charmm 
@@ -67,10 +69,34 @@ weighting factors (4th coeff above) should be set to 0.0.  In this
 case, you can use any pair style you wish, since the dihedral does not
 need any 1-4 information.
 
      
+
      
+
+
      Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
      
+
      These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
      
+
      You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
      
+
      See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
      
+
      
+
 
      Restrictions:
 
      
 
      This dihedral style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the Making
+MOLECULAR package (which it is by default).  See the Making
 LAMMPS section for more info on packages.
 
      
 
      Related commands:
diff --git a/doc/dihedral_charmm.txt b/doc/dihedral_charmm.txt
index d164f369ca..c0b959ffb5 100644
--- a/doc/dihedral_charmm.txt
+++ b/doc/dihedral_charmm.txt
@@ -7,6 +7,7 @@
 :line
 
 dihedral_style charmm command :h3
+dihedral_style charmm/omp command :h3
 
 [Syntax:]
 
@@ -64,11 +65,35 @@ weighting factors (4th coeff above) should be set to 0.0.  In this
 case, you can use any pair style you wish, since the dihedral does not
 need any 1-4 information.
 
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restrictions:]
 
 This dihedral style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info on packages.
+MOLECULAR package (which it is by default).  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]
 
diff --git a/doc/dihedral_class2.html b/doc/dihedral_class2.html
index 6da37c9a2a..79e7b47d92 100644
--- a/doc/dihedral_class2.html
+++ b/doc/dihedral_class2.html
@@ -11,6 +11,8 @@
 
 
      dihedral_style class2 command 
 
      
+
      dihedral_style class2/omp command 
+
      
 
      Syntax:
 
      
 
      dihedral_style class2 
@@ -137,10 +139,34 @@ listed under a "BondBond13 Coeffs" heading and you must leave out the
 
    • r1 (distance)
 
    • r3 (distance) 
 
    
+
    
+
+
    Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
 
    Restrictions:
 
    
 
    This dihedral style can only be used if LAMMPS was built with the
-"class2" package.  See the Making LAMMPS
+CLASS2 package.  See the Making LAMMPS
 section for more info on packages.
 
    
 
    Related commands:
diff --git a/doc/dihedral_class2.txt b/doc/dihedral_class2.txt
index 141112823a..ab60aa3812 100644
--- a/doc/dihedral_class2.txt
+++ b/doc/dihedral_class2.txt
@@ -7,6 +7,7 @@
 :line
 
 dihedral_style class2 command :h3
+dihedral_style class2/omp command :h3
 
 [Syntax:]
 
@@ -134,10 +135,34 @@ N (energy/distance^2)
 r1 (distance)
 r3 (distance) :ul
 
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restrictions:]
 
 This dihedral style can only be used if LAMMPS was built with the
-"class2" package.  See the "Making LAMMPS"_Section_start.html#2_3
+CLASS2 package.  See the "Making LAMMPS"_Section_start.html#start_3
 section for more info on packages.
 
 [Related commands:]
diff --git a/doc/dihedral_coeff.html b/doc/dihedral_coeff.html
index 26021e3a64..9159ee5b21 100644
--- a/doc/dihedral_coeff.html
+++ b/doc/dihedral_coeff.html
@@ -81,7 +81,7 @@ specified by the associated dihedral_coeff c
 
 
    There are also additional dihedral styles submitted by users which are
 included in the LAMMPS distribution.  The list of these with links to
-the individual styles are given in the dihedral section of this
+the individual styles are given in the dihedral section of this
 page.
 
    
 
    
diff --git a/doc/dihedral_coeff.txt b/doc/dihedral_coeff.txt
index e66ac90b75..21228218f2 100644
--- a/doc/dihedral_coeff.txt
+++ b/doc/dihedral_coeff.txt
@@ -79,7 +79,7 @@ specified by the associated "dihedral_coeff"_dihedral_coeff.html command:
 There are also additional dihedral styles submitted by users which are
 included in the LAMMPS distribution.  The list of these with links to
 the individual styles are given in the dihedral section of "this
-page"_Section_commands.html#3_5.
+page"_Section_commands.html#cmd_5.
 
 :line
 
diff --git a/doc/dihedral_cosine_shift_exp.html b/doc/dihedral_cosine_shift_exp.html
new file mode 100644
index 0000000000..c6ab2cae79
--- /dev/null
+++ b/doc/dihedral_cosine_shift_exp.html
@@ -0,0 +1,91 @@
+
+
    LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
    
+
+
+
+
+
+
+
    
+
+
    dihedral_style cosine/shift/exp command 
+
    
+
    dihedral_style cosine/shift/exp/omp command 
+
    
+
    Syntax:
+
    
+
    dihedral_style cosine/shift/exp 
+
    
+
    Examples:
+
    
+
    dihedral_style cosine/shift/exp
+dihedral_coeff 1 10.0 45.0 2.0 
+
    
+
    Description:
+
    
+
    The cosine/shift/exp dihedral style uses the potential
+
    
+
    
+
    
+
    where Umin, theta, and a are defined for each dihedral type.
+
    
+
    The potential is bounded between [-Umin:0] and the minimum is located
+at the angle theta0. The a parameter can be both positive or negative
+and is used to control the spring constant at the equilibrium.
+
    
+
    The spring constant is given by k=a exp(a) Umin/ [2 (Exp(a)-1)].
+For a>3 k/Umin = a/2 to better than 5% relative error. For negative
+values of the a parameter, the spring constant is essentially zero,
+and anharmonic terms takes over. The potential is furthermore well
+behaved in the limit a->0, where it has been implemented to linear
+order in a for a < 0.001.
+
    
+
    The following coefficients must be defined for each dihedral type via
+the dihedral_coeff command as in the example
+above, or in the data file or restart files read by the
+read_data or read_restart
+commands:
+
    
+
    • umin (energy)
+
    • theta (angle)
+
    • A (real number) 
+
    
+
    
+
+
    Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
+
    Restrictions:
+
    
+
    This dihedral style can only be used if LAMMPS was built with the
+USER-MISC package.  See the Making LAMMPS
+section for more info on packages.
+
    
+
    Related commands:
+
    
+
    dihedral_coeff,
+angle_cosineshiftexp
+
    
+
    Default: none
+
    
+
diff --git a/doc/dihedral_cosine_shift_exp.txt b/doc/dihedral_cosine_shift_exp.txt
new file mode 100644
index 0000000000..d1e1c8223b
--- /dev/null
+++ b/doc/dihedral_cosine_shift_exp.txt
@@ -0,0 +1,85 @@
+"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
+
+dihedral_style cosine/shift/exp command :h3
+dihedral_style cosine/shift/exp/omp command :h3
+
+[Syntax:]
+
+dihedral_style cosine/shift/exp :pre
+
+[Examples:]
+
+dihedral_style cosine/shift/exp
+dihedral_coeff 1 10.0 45.0 2.0 :pre
+
+[Description:]
+
+The {cosine/shift/exp} dihedral style uses the potential
+
+:c,image(Eqs/dihedral_cosine_shift_exp.jpg)
+
+where Umin, theta, and a are defined for each dihedral type.
+
+The potential is bounded between \[-Umin:0\] and the minimum is located
+at the angle theta0. The a parameter can be both positive or negative
+and is used to control the spring constant at the equilibrium.
+
+The spring constant is given by k=a exp(a) Umin/ \[2 (Exp(a)-1)\].
+For a>3 k/Umin = a/2 to better than 5% relative error. For negative
+values of the a parameter, the spring constant is essentially zero,
+and anharmonic terms takes over. The potential is furthermore well
+behaved in the limit a->0, where it has been implemented to linear
+order in a for a < 0.001.
+
+The following coefficients must be defined for each dihedral type via
+the "dihedral_coeff"_dihedral_coeff.html command as in the example
+above, or in the data file or restart files read by the
+"read_data"_read_data.html or "read_restart"_read_restart.html
+commands:
+
+umin (energy)
+theta (angle)
+A (real number) :ul
+
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
+[Restrictions:]
+
+This dihedral style can only be used if LAMMPS was built with the
+USER-MISC package.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info on packages.
+
+[Related commands:]
+
+"dihedral_coeff"_dihedral_coeff.html,
+"angle_cosineshiftexp"_angle_cosineshiftexp.html
+
+[Default:] none
diff --git a/doc/dihedral_harmonic.html b/doc/dihedral_harmonic.html
index b7313e9709..d8c3a73f69 100644
--- a/doc/dihedral_harmonic.html
+++ b/doc/dihedral_harmonic.html
@@ -11,6 +11,8 @@
 
 
    dihedral_style harmonic command 
 
    
+
    dihedral_style harmonic/omp command 
+
    
 
    Syntax:
 
    
 
    dihedral_style harmonic 
@@ -35,10 +37,34 @@ or read_restart commands:
 
  • d (+1 or -1)
 
  • n (integer >= 0) 
 
+
    
+
+
    Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
 
    Restrictions:
 
    
 
    This dihedral style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the Making
+MOLECULAR package (which it is by default).  See the Making
 LAMMPS section for more info on packages.
 
    
 
    Related commands:
diff --git a/doc/dihedral_harmonic.txt b/doc/dihedral_harmonic.txt
index 6e9c5dee06..a076931a0a 100644
--- a/doc/dihedral_harmonic.txt
+++ b/doc/dihedral_harmonic.txt
@@ -7,6 +7,7 @@
 :line
 
 dihedral_style harmonic command :h3
+dihedral_style harmonic/omp command :h3
 
 [Syntax:]
 
@@ -32,11 +33,35 @@ K (energy)
 d (+1 or -1)
 n (integer >= 0) :ul
 
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restrictions:]
 
 This dihedral style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info on packages.
+MOLECULAR package (which it is by default).  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]
 
diff --git a/doc/dihedral_helix.html b/doc/dihedral_helix.html
index 0a0e9c7668..86b3728339 100644
--- a/doc/dihedral_helix.html
+++ b/doc/dihedral_helix.html
@@ -11,6 +11,8 @@
 
 
    dihedral_style helix command 
 
    
+
    dihedral_style helix/omp command 
+
    
 
    Syntax:
 
    
 
    dihedral_style helix 
@@ -43,10 +45,34 @@ or read_restart commands:
 
  • B (energy)
 
  • C (energy) 
 
+
    
+
+
    Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
 
    Restrictions:
 
    
 
    This dihedral style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the Making
+MOLECULAR package (which it is by default).  See the Making
 LAMMPS section for more info on packages.
 
    
 
    Related commands:
diff --git a/doc/dihedral_helix.txt b/doc/dihedral_helix.txt
index f68d66e6f8..8792c10767 100644
--- a/doc/dihedral_helix.txt
+++ b/doc/dihedral_helix.txt
@@ -7,6 +7,7 @@
 :line
 
 dihedral_style helix command :h3
+dihedral_style helix/omp command :h3
 
 [Syntax:]
 
@@ -40,11 +41,35 @@ A (energy)
 B (energy)
 C (energy) :ul
 
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restrictions:]
 
 This dihedral style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info on packages.
+MOLECULAR package (which it is by default).  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]
 
diff --git a/doc/dihedral_hybrid.html b/doc/dihedral_hybrid.html
index 63ce89a220..69bbe932df 100644
--- a/doc/dihedral_hybrid.html
+++ b/doc/dihedral_hybrid.html
@@ -21,7 +21,7 @@
 
    
 
    dihedral_style hybrid harmonic helix
 dihedral_coeff 1 harmonic 6.0 1 3
-dihedral_coeff 2 helix 10 10 10 
+dihedral_coeff 2* helix 10 10 10 
 
    
 
    Description:
 
    
@@ -33,31 +33,54 @@ boundary (of dihedral type 2) could be computed with a helix
 potential.  The assignment of dihedral type to style is made via the
 dihedral_coeff command or in the data file.
 
    
-
    In the dihedral_coeff command, the first coefficient sets the dihedral
-style and the remaining coefficients are those appropriate to that
-style.  In the example above, the 2 dihedral_coeff commands would set
-dihedrals of dihedral type 1 to be computed with a harmonic
-potential with coefficients 80.0, 1.2 for K, d, n.  Dihedral type 2
-would be computed with a helix potential with coefficients 10.0,
-10.0, 10.0 for A, B, C.
+
    In the dihedral_coeff commands, the name of a dihedral style must be
+added after the dihedral type, with the remaining coefficients being
+those appropriate to that style.  In the example above, the 2
+dihedral_coeff commands set dihedrals of dihedral type 1 to be
+computed with a harmonic potential with coefficients 6.0, 1, 3 for
+K, d, n.  All other dihedral types (2-N) are computed with a helix
+potential with coefficients 10, 10, 10 for A, B, C.
 
    
-
    If the dihedral class2 potential is one of the hybrid styles, it
-requires additional MiddleBondTorsion, EndBondTorsion, AngleTorsion,
-AngleAngleTorsion, and BondBond13 coefficients be specified in the
-data file.  These lines must also have an additional "class2" argument
-added after the dihedral type.  For dihedral types which are assigned
-to other hybrid styles, use the style name (e.g. "harmonic")
-appropriate to that style.  The MiddleBondTorsion, etc coeffs for that
-dihedral type will then be ignored.
+
    If dihedral coefficients are specified in the data file read via the
+read_data command, then the same rule applies.
+E.g. "harmonic" or "helix", must be added after the dihedral type, for
+each line in the "Dihedral Coeffs" section, e.g.
 
    
-
    A dihedral style of none can be specified as the 2nd argument to the
-dihedral_coeff command, if you desire to turn off certain dihedral
-types.
+
    Dihedral Coeffs 
+
    
+
    1 harmonic 6.0 1 3
+2 helix 10 10 10
+... 
+
    
+
    If class2 is one of the dihedral hybrid styles, the same rule holds
+for specifying additional AngleTorsion (and EndBondTorsion, etc)
+coefficients either via the input script or in the data file.
+I.e. class2 must be added to each line after the dihedral type.  For
+lines in the AngleTorsion (or EndBondTorsion, etc) section of the data
+file for dihedral types that are not class2, you must use an
+dihedral style of skip as a placeholder, e.g.
 
    
+
    AngleTorsion Coeffs 
+
    
+
    1 skip
+2 class2 1.0 1.0 1.0 3.0 3.0 3.0 30.0 50.0
+... 
+
    
+
    Note that it is not necessary to use the dihedral style skip in the
+input script, since AngleTorsion (or EndBondTorsion, etc) coefficients
+need not be specified at all for dihedral types that are not class2.
+
    
+
    A dihedral style of none with no additional coefficients can be used
+in place of a dihedral style, either in a input script dihedral_coeff
+command or in the data file, if you desire to turn off interactions
+for specific dihedral types.
+
    
+
    
+
 
    Restrictions:
 
    
 
    This dihedral style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the Making
+MOLECULAR package (which it is by default).  See the Making
 LAMMPS section for more info on packages.
 
    
 
    Unlike other dihedral styles, the hybrid dihedral style does not store
diff --git a/doc/dihedral_hybrid.txt b/doc/dihedral_hybrid.txt
index f92fc490d6..6b00a2f025 100644
--- a/doc/dihedral_hybrid.txt
+++ b/doc/dihedral_hybrid.txt
@@ -18,7 +18,7 @@ style1,style2 = list of one or more dihedral styles :ul
 
 dihedral_style hybrid harmonic helix
 dihedral_coeff 1 harmonic 6.0 1 3
-dihedral_coeff 2 helix 10 10 10 :pre
+dihedral_coeff 2* helix 10 10 10 :pre
 
 [Description:]
 
@@ -30,32 +30,55 @@ boundary (of dihedral type 2) could be computed with a {helix}
 potential.  The assignment of dihedral type to style is made via the
 "dihedral_coeff"_dihedral_coeff.html command or in the data file.
 
-In the dihedral_coeff command, the first coefficient sets the dihedral
-style and the remaining coefficients are those appropriate to that
-style.  In the example above, the 2 dihedral_coeff commands would set
-dihedrals of dihedral type 1 to be computed with a {harmonic}
-potential with coefficients 80.0, 1.2 for K, d, n.  Dihedral type 2
-would be computed with a {helix} potential with coefficients 10.0,
-10.0, 10.0 for A, B, C.
+In the dihedral_coeff commands, the name of a dihedral style must be
+added after the dihedral type, with the remaining coefficients being
+those appropriate to that style.  In the example above, the 2
+dihedral_coeff commands set dihedrals of dihedral type 1 to be
+computed with a {harmonic} potential with coefficients 6.0, 1, 3 for
+K, d, n.  All other dihedral types (2-N) are computed with a {helix}
+potential with coefficients 10, 10, 10 for A, B, C.
 
-If the dihedral {class2} potential is one of the hybrid styles, it
-requires additional MiddleBondTorsion, EndBondTorsion, AngleTorsion,
-AngleAngleTorsion, and BondBond13 coefficients be specified in the
-data file.  These lines must also have an additional "class2" argument
-added after the dihedral type.  For dihedral types which are assigned
-to other hybrid styles, use the style name (e.g. "harmonic")
-appropriate to that style.  The MiddleBondTorsion, etc coeffs for that
-dihedral type will then be ignored.
+If dihedral coefficients are specified in the data file read via the
+"read_data"_read_data.html command, then the same rule applies.
+E.g. "harmonic" or "helix", must be added after the dihedral type, for
+each line in the "Dihedral Coeffs" section, e.g.
 
-A dihedral style of {none} can be specified as the 2nd argument to the
-dihedral_coeff command, if you desire to turn off certain dihedral
-types.
+Dihedral Coeffs :pre
+
+1 harmonic 6.0 1 3
+2 helix 10 10 10
+... :pre
+
+If {class2} is one of the dihedral hybrid styles, the same rule holds
+for specifying additional AngleTorsion (and EndBondTorsion, etc)
+coefficients either via the input script or in the data file.
+I.e. {class2} must be added to each line after the dihedral type.  For
+lines in the AngleTorsion (or EndBondTorsion, etc) section of the data
+file for dihedral types that are not {class2}, you must use an
+dihedral style of {skip} as a placeholder, e.g.
+
+AngleTorsion Coeffs :pre
+
+1 skip
+2 class2 1.0 1.0 1.0 3.0 3.0 3.0 30.0 50.0
+... :pre
+
+Note that it is not necessary to use the dihedral style {skip} in the
+input script, since AngleTorsion (or EndBondTorsion, etc) coefficients
+need not be specified at all for dihedral types that are not {class2}.
+
+A dihedral style of {none} with no additional coefficients can be used
+in place of a dihedral style, either in a input script dihedral_coeff
+command or in the data file, if you desire to turn off interactions
+for specific dihedral types.
+
+:line
 
 [Restrictions:]
 
 This dihedral style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info on packages.
+MOLECULAR package (which it is by default).  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 Unlike other dihedral styles, the hybrid dihedral style does not store
 dihedral coefficient info for individual sub-styles in a "binary
diff --git a/doc/dihedral_multi_harmonic.html b/doc/dihedral_multi_harmonic.html
index 03dcd350b8..10601f3362 100644
--- a/doc/dihedral_multi_harmonic.html
+++ b/doc/dihedral_multi_harmonic.html
@@ -11,6 +11,8 @@
 
 
    dihedral_style multi/harmonic command 
 
    
+
    dihedral_style multi/harmonic/omp command 
+
    
 
    Syntax:
 
    
 
    dihedral_style multi/harmonic 
@@ -37,10 +39,34 @@ or read_restart commands:
 
  • A4 (energy)
 
  • A5 (energy) 
 
+
    
+
+
    Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
 
    Restrictions:
 
    
 
    This dihedral style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the Making
+MOLECULAR package (which it is by default).  See the Making
 LAMMPS section for more info on packages.
 
    
 
    Related commands:
diff --git a/doc/dihedral_multi_harmonic.txt b/doc/dihedral_multi_harmonic.txt
index 4c71dbc3ca..505857fe81 100644
--- a/doc/dihedral_multi_harmonic.txt
+++ b/doc/dihedral_multi_harmonic.txt
@@ -7,6 +7,7 @@
 :line
 
 dihedral_style multi/harmonic command :h3
+dihedral_style multi/harmonic/omp command :h3
 
 [Syntax:]
 
@@ -34,11 +35,35 @@ A3 (energy)
 A4 (energy)
 A5 (energy) :ul
 
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restrictions:]
 
 This dihedral style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info on packages.
+MOLECULAR package (which it is by default).  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]
 
diff --git a/doc/dihedral_opls.html b/doc/dihedral_opls.html
index 6861fb6000..e0656dd837 100644
--- a/doc/dihedral_opls.html
+++ b/doc/dihedral_opls.html
@@ -11,6 +11,8 @@
 
 
    dihedral_style opls command 
 
    
+
    dihedral_style opls/omp command 
+
    
 
    Syntax:
 
    
 
    dihedral_style opls 
@@ -41,10 +43,34 @@ or read_restart commands:
 
  • K3 (energy)
 
  • K4 (energy) 
 
+
    
+
+
    Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
 
    Restrictions:
 
    
 
    This dihedral style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the Making
+MOLECULAR package (which it is by default).  See the Making
 LAMMPS section for more info on packages.
 
    
 
    Related commands:
diff --git a/doc/dihedral_opls.txt b/doc/dihedral_opls.txt
index 67c08e6543..c43e7a279e 100644
--- a/doc/dihedral_opls.txt
+++ b/doc/dihedral_opls.txt
@@ -7,6 +7,7 @@
 :line
 
 dihedral_style opls command :h3
+dihedral_style opls/omp command :h3
 
 [Syntax:]
 
@@ -38,11 +39,35 @@ K2 (energy)
 K3 (energy)
 K4 (energy) :ul
 
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restrictions:]
 
 This dihedral style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info on packages.
+MOLECULAR package (which it is by default).  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]
 
diff --git a/doc/dihedral_style.html b/doc/dihedral_style.html
index f13b8d2ab8..e2f6ea5322 100644
--- a/doc/dihedral_style.html
+++ b/doc/dihedral_style.html
@@ -88,7 +88,7 @@ specified by the associated dihedral_coeff c
 
 
    There are also additional dihedral styles submitted by users which are
 included in the LAMMPS distribution.  The list of these with links to
-the individual styles are given in the dihedral section of this
+the individual styles are given in the dihedral section of this
 page.
 
    
 
    
@@ -98,11 +98,11 @@ page.
 
    Dihedral styles can only be set for atom styles that allow dihedrals
 to be defined.
 
    
-
    Most dihedral styles are part of the "molecular" package.  They are
-only enabled if LAMMPS was built with that package.  See the Making
-LAMMPS section for more info on packages.  The
-doc pages for individual dihedral potentials tell if it is part of a
-package.
+
    Most dihedral styles are part of the MOLECULAR package.  They are only
+enabled if LAMMPS was built with that package.  See the Making
+LAMMPS section for more info on packages.
+The doc pages for individual dihedral potentials tell if it is part of
+a package.
 
    
 
    Related commands:
 
    
diff --git a/doc/dihedral_style.txt b/doc/dihedral_style.txt
index a4b9896bbf..788215a6ed 100644
--- a/doc/dihedral_style.txt
+++ b/doc/dihedral_style.txt
@@ -87,7 +87,7 @@ specified by the associated "dihedral_coeff"_dihedral_coeff.html command:
 There are also additional dihedral styles submitted by users which are
 included in the LAMMPS distribution.  The list of these with links to
 the individual styles are given in the dihedral section of "this
-page"_Section_commands.html#3_5.
+page"_Section_commands.html#cmd_5.
 
 :line
 
@@ -96,11 +96,11 @@ page"_Section_commands.html#3_5.
 Dihedral styles can only be set for atom styles that allow dihedrals
 to be defined.
 
-Most dihedral styles are part of the "molecular" package.  They are
-only enabled if LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info on packages.  The
-doc pages for individual dihedral potentials tell if it is part of a
-package.
+Most dihedral styles are part of the MOLECULAR package.  They are only
+enabled if LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
+The doc pages for individual dihedral potentials tell if it is part of
+a package.
 
 [Related commands:]
 
diff --git a/doc/dipole.html b/doc/dipole.html
deleted file mode 100644
index 57b2330bfb..0000000000
--- a/doc/dipole.html
+++ /dev/null
@@ -1,71 +0,0 @@
-
-
    LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
-
    
-
-
-
-
-
-
-
    
-
-
    dipole command 
-
    
-
    Syntax:
-
    
-
    dipole I value 
-
    
-
    • I = atom type (see asterisk form below)
-
    • value = dipole moment (dipole units) 
-
    
-
    Examples:
-
    
-
    dipole 1 1.0
-dipole 3 2.0
-dipole 3*5 0.0 
-
    
-
    Description:
-
    
-
    Set the dipole moment for all atoms of one or more atom types.  This
-command is only used for atom styles that require dipole moments
-(atom_style dipole).  A value of 0.0 should be used
-if the atom type has no dipole moment.  Dipole values can also be set
-in the read_data data file.  See the
-units command for a discussion of dipole units.
-
    
-
    Currently, only atom_style dipole requires dipole
-moments be set.
-
    
-
    I can be specified in one of two ways.  An explicit numeric value can
-be used, as in the 1st example above.  Or a wild-card asterisk can be
-used to set the dipole moment for multiple atom types.  This takes the
-form "*" or "*n" or "n*" or "m*n".  If N = the number of atom types,
-then an asterisk with no numeric values means all types from 1 to N.  A
-leading asterisk means all types from 1 to n (inclusive).  A trailing
-asterisk means all types from n to N (inclusive).  A middle asterisk
-means all types from m to n (inclusive).
-
    
-
    A line in a data file that specifies a dipole moment uses the same
-format as the arguments of the dipole command in an input script,
-except that no wild-card asterisk can be used.  For example, under the
-"Dipoles" section of a data file, the line that corresponds to the 1st
-example above would be listed as
-
    
-
    1 1.0 
-
    
-
    Restrictions:
-
    
-
    This command must come after the simulation box is defined by a
-read_data, read_restart, or
-create_box command.
-
    
-
    All dipoles moments must be defined before a simulation is run (if the
-atom style requires dipoles be set).  They must also all be defined
-before a set dipole or set dipole/random command
-is used.
-
    
-
    Related commands: none
-
    
-
    Default: none
-
    
-
diff --git a/doc/dipole.txt b/doc/dipole.txt
deleted file mode 100644
index a9dd7a8893..0000000000
--- a/doc/dipole.txt
+++ /dev/null
@@ -1,66 +0,0 @@
-"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
-
-:link(lws,http://lammps.sandia.gov)
-:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
-
-:line
-
-dipole command :h3
-
-[Syntax:]
-
-dipole I value :pre
-
-I = atom type (see asterisk form below)
-value = dipole moment (dipole units) :ul
-
-[Examples:]
-
-dipole 1 1.0
-dipole 3 2.0
-dipole 3*5 0.0 :pre
-
-[Description:]
-
-Set the dipole moment for all atoms of one or more atom types.  This
-command is only used for atom styles that require dipole moments
-("atom_style"_atom_style.html dipole).  A value of 0.0 should be used
-if the atom type has no dipole moment.  Dipole values can also be set
-in the "read_data"_read_data.html data file.  See the
-"units"_units.html command for a discussion of dipole units.
-
-Currently, only "atom_style dipole"_atom_style.html requires dipole
-moments be set.
-
-I can be specified in one of two ways.  An explicit numeric value can
-be used, as in the 1st example above.  Or a wild-card asterisk can be
-used to set the dipole moment for multiple atom types.  This takes the
-form "*" or "*n" or "n*" or "m*n".  If N = the number of atom types,
-then an asterisk with no numeric values means all types from 1 to N.  A
-leading asterisk means all types from 1 to n (inclusive).  A trailing
-asterisk means all types from n to N (inclusive).  A middle asterisk
-means all types from m to n (inclusive).
-
-A line in a data file that specifies a dipole moment uses the same
-format as the arguments of the dipole command in an input script,
-except that no wild-card asterisk can be used.  For example, under the
-"Dipoles" section of a data file, the line that corresponds to the 1st
-example above would be listed as
-
-1 1.0 :pre
-
-[Restrictions:]
-
-This command must come after the simulation box is defined by a
-"read_data"_read_data.html, "read_restart"_read_restart.html, or
-"create_box"_create_box.html command.
-
-All dipoles moments must be defined before a simulation is run (if the
-atom style requires dipoles be set).  They must also all be defined
-before a "set dipole"_set.html or "set dipole/random"_set.html command
-is used.
-
-[Related commands:] none
-
-[Default:] none
diff --git a/doc/dump.html b/doc/dump.html
index fad0888e9a..23bd26c179 100644
--- a/doc/dump.html
+++ b/doc/dump.html
@@ -11,6 +11,8 @@
 
 
    dump command 
 
    
+
    dump image command 
+
    
 
    Syntax:
 
    
 
    dump ID group-ID style N file args 
@@ -19,7 +21,7 @@
 
 
  • group-ID = ID of the group of atoms to be dumped 
 
-
  • style = atom or cfg or dcd or xtc or xyz or local or custom 
+
  • style = atom or cfg or dcd or xtc or xyz or image or local or custom 
 
 
  • N = dump every this many timesteps 
 
@@ -33,6 +35,8 @@
   xtc args = none
   xyz args = none 
 
    • 
+
      image args = discussed on dump image doc page 
+
    
 
      local args = list of local attributes
     possible attributes = index, c_ID, c_ID[N], f_ID, f_ID[N]
       index = enumeration of local values
@@ -42,32 +46,34 @@
       f_ID[N] = Nth column of local array calculated by a fix with ID 
 
    
 
      custom args = list of atom attributes
-    possible attributes = id, mol, type, mass,
-			  x, y, z, xs, ys, zs, xu, yu, zu, ix, iy, iz,
+    possible attributes = id, mol, type, element, mass,
+			  x, y, z, xs, ys, zs, xu, yu, zu, 
+			  xsu, ysu, zsu, ix, iy, iz,
 			  vx, vy, vz, fx, fy, fz,
-                          q, mux, muy, muz,
-                          radius, omegax, omegay, omegaz,
-                          angmomx, angmomy, angmomz,
-			  quatw, quati, quatj, quatk, tqx, tqy, tqz,
+                          q, mux, muy, muz, mu,
+                          radius, diameter, omegax, omegay, omegaz,
+			  angmomx, angmomy, angmomz, tqx, tqy, tqz,
 			  spin, eradius, ervel, erforce,
 			  c_ID, c_ID[N], f_ID, f_ID[N], v_name 
 
    
 
          id = atom ID
       mol = molecule ID
       type = atom type
+      element = name of atom element, as defined by dump_modify command
       mass = atom mass
       x,y,z = unscaled atom coordinates
       xs,ys,zs = scaled atom coordinates
       xu,yu,zu = unwrapped atom coordinates
+      xsu,ysu,zsu = scaled unwrapped atom coordinates
       ix,iy,iz = box image that the atom is in
       vx,vy,vz = atom velocities
       fx,fy,fz = forces on atoms
       q = atom charge
-      mux,muy,muz = orientation of dipolar atom
-      radius = radius of extended spherical particle
+      mux,muy,muz = orientation of dipole moment of atom
+      mu = magnitude of dipole moment of atom
+      radius,diameter = radius,diameter of spherical particle
       omegax,omegay,omegaz = angular velocity of extended particle
       angmomx,angmomy,angmomz = angular momentum of extended particle
-      quatw,quati,quatj,quatk = quaternion components for aspherical particles
       tqx,tqy,tqz = torque on extended particles
       spin = electron spin
       eradius = electron radius
@@ -95,13 +101,19 @@ dump e_data all custom 100 dump.eff id type x y z spin eradius fx fy fz eforce
 
    Description:
 
    
 
    Dump a snapshot of atom quantities to one or more files every N
-timesteps in one of several styles.  As described below, the filename
-determines the kind of output (text or binary or gzipped, one big file
-or one per timestep, one big file or one per processor).  Only
-information for atoms in the specified group is dumped.  The
-dump_modify command can also alter what atoms are
-included.  Not all styles support all these options; see details
-below.
+timesteps in one of several styles.  The image style is the
+exception; it creates a JPG or PPM image file of the atom
+configuration every N timesteps, as discussed on the dump
+image doc page.
+
    
+
    Only information for atoms in the specified group is dumped.  The
+dump_modify thresh and region commands can also
+alter what atoms are included.  Not all styles support all these
+options; see details below.
+
    
+
    As described below, the filename determines the kind of output (text
+or binary or gzipped, one big file or one per timestep, one big file
+or one per processor).
 
    
 
    IMPORTANT NOTE: Because periodic boundary conditions are enforced only
 on timesteps when neighbor lists are rebuilt, the coordinates of an
@@ -142,32 +154,41 @@ self-describing in the following sense.
 
    The dimensions of the simulation box are included in each snapshot.
 For an orthogonal simulation box this information is is formatted as:
 
    
-
    ITEM: BOX BOUNDS
+
    ITEM: BOX BOUNDS xx yy zz
 xlo xhi
 ylo yhi
 zlo zhi 
 
    
 
    where xlo,xhi are the maximum extents of the simulation box in the
-x-dimension, and similarly for y and z.
+x-dimension, and similarly for y and z.  The "xx yy zz" represent 6
+characters that encode the style of boundary for each of the 6
+simulation box boundaries (xlo,xhi and ylo,yhi and zlo,zhi).  Each of
+the 6 characters is either p = periodic, f = fixed, s = shrink wrap,
+or m = shrink wrapped with a minimum value.  See the
+boundary command for details.
 
    
 
    For triclinic simulation boxes (non-orthogonal), an orthogonal
 bounding box which encloses the triclinic simulation box is output,
 along with the 3 tilt factors (xy, xz, yz) of the triclinic box,
 formatted as follows:
 
    
-
    ITEM: BOX BOUNDS xy xz yz
+
    ITEM: BOX BOUNDS xy xz yz xx yy zz 
 xlo_bound xhi_bound xy
 ylo_bound yhi_bound xz
 zlo_bound zhi_bound yz 
 
    
-
    This bounding box is convenient for many visualization programs.
+
    The presence of the text "xy xz yz" in the ITEM line indicates that
+the 3 tilt factors will be included on each of the 3 following lines.
+This bounding box is convenient for many visualization programs.  The
+meaning of the 6 character flags for "xx yy zz" is the same as above.
 
    
-
    See this section of the doc pages for a
-geometric description of triclinic boxes, as defined by LAMMPS, simple
-formulas for how the 6 bounding box extents (xlo_bound,xhi_bound,etc)
-are calculated from the triclinic parameters, and how to transform
-those parameters to and from other commonly used triclinic
-representations.
+
    Note that the first two numbers on each line are now xlo_bound instead
+of xlo, etc, since they repesent a bounding box.  See this
+section of the doc pages for a geometric
+description of triclinic boxes, as defined by LAMMPS, simple formulas
+for how the 6 bounding box extents (xlo_bound,xhi_bound,etc) are
+calculated from the triclinic parameters, and how to transform those
+parameters to and from other commonly used triclinic representations.
 
    
 
    The "ITEM: ATOMS" line in each snapshot lists column descriptors for
 the per-atom lines that follow.  For example, the descriptors would be
@@ -210,14 +231,23 @@ extended CFG format files, as used by the
 package.  Since the extended CFG format uses a single snapshot of the
 system per file, a wildcard "*" must be included in the filename, as
 discussed below.  The list of atom attributes for style cfg must
-begin with "id type xs ys zs", since these quantities are needed to
+begin with either "id type xs ys zs" or "id type xsu ysu zsu" or 
+since these quantities are needed to
 write the CFG files in the appropriate format (though the "id" and
 "type" fields do not appear explicitly in the file).  Any remaining
 attributes will be stored as "auxiliary properties" in the CFG files.
 Note that you will typically want to use the dump_modify
 element command with CFG-formatted files, to
 associate element names with atom types, so that AtomEye can render
-atoms appropriately.
+atoms appropriately. When unwrapped coordinates xsu, ysu, and zsu
+are requested, the nominal AtomEye periodic cell dimensions are expanded 
+by a large factor UNWRAPEXPAND = 10.0, which ensures atoms that are 
+displayed correctly for up to UNWRAPEXPAND/2 periodic boundary crossings 
+in any direction. 
+Beyond this, AtomEye will rewrap the unwrapped coordinates. 
+The expansion causes the atoms to be drawn farther
+away from the viewer, but it is easy to zoom the atoms closer, and
+the interatomic distances are unaffected.   
 
    
 
    The dcd style writes DCD files, a standard atomic trajectory format
 used by the CHARMM, NAMD, and XPlor molecular dynamics packages.  DCD
@@ -281,7 +311,10 @@ character appears in the filename, then one file per snapshot is
 written and the "*" character is replaced with the timestep value.
 For example, tmp.dump.* becomes tmp.dump.0, tmp.dump.10000,
 tmp.dump.20000, etc.  This option is not available for the dcd and
-xtc styles.
+xtc styles.  Note that the dump_modify pad
+command can be used to insure all timestep numbers are the same length
+(e.g. 00010), which can make it easier to read a series of dump files
+in order by some post-processing tools.
 
    
 
    If a "%" character appears in the filename, then one file is written
 for each processor and the "%" character is replaced with the
@@ -358,19 +391,23 @@ array calculated by the fix.
 
    This section explains the atom attributes that can be specified as
 part of the custom and cfg styles.
 
    
-
    The id, mol, type, mass, vx, vy, vz, fx, fy,
+
    The id, mol, type, element, mass, vx, vy, vz, fx, fy,
 fz, q attributes are self-explanatory.
 
    
 
    Id is the atom ID.  Mol is the molecule ID, included in the data
-file for molecular systems.  Type is the atom type.  Mass is the
-atom mass.  Vx, vy, vz, fx, fy, fz, and q are components
-of atom velocity and force and atomic charge.
+file for molecular systems.  Type is the atom type.  Element is
+typically the chemical name of an element, which you must assign to
+each type via the dump_modify element command.
+More generally, it can be any string you wish to associated with an
+atom type.  Mass is the atom mass.  Vx, vy, vz, fx, fy,
+fz, and q are components of atom velocity and force and atomic
+charge.
 
    
 
    There are several options for outputting atom coordinates.  The x,
 y, z attributes write atom coordinates "unscaled", in the
 appropriate distance units (Angstroms, sigma, etc).  Use
 xs, ys, zs if you want the coordinates "scaled" to the box size,
-so that each value is 0.0 to 1.0.  If the simluation box is triclinic
+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.  Use
 xu, yu, zu if you want the coordinates "unwrapped" by the image
 flags for each atom.  Unwrapped means that if the atom has passed thru
@@ -378,33 +415,34 @@ a periodic boundary one or more times, the value is printed for what
 the coordinate would be if it had not been wrapped back into the
 periodic box.  Note that using xu, yu, zu means that the
 coordinate values may be far outside the box bounds printed with the
-snapshot.  The image flags can be printed directly using the ix,
+snapshot.  Using xsu, ysu, zsu is similar to using xu, yu, zu,
+except that the unwrapped coordinates are scaled by the box size. Atoms
+that have passed through a periodic boundary will have the corresponding
+cooordinate increased or decreased by 1.0.
+
    
+
    The image flags can be printed directly using the ix,
 iy, iz attributes. The dump_modify command
 describes in more detail what is meant by scaled vs unscaled
 coordinates and the image flags.
 
    
 
    The mux, muy, muz attributes are specific to dipolar systems
 defined with an atom style of dipole.  They give the orientation of
-the atom's point dipole moment.
+the atom's point dipole moment.  The mu attribute gives the
+magnitude of the atom's dipole moment.
 
    
-
    The radius attribute is specific to extended spherical particles
-that have a finite size, such as granular particles defined with
-an atom style of granular.
+
    The radius and diameter attributes are specific to extended
+spherical particles that have a finite size, such as those defined
+with an atom style of sphere.
 
    
-
    The omegax, omegay, and omegaz attributes are specific to extended
-spherical or aspherical particles that have an angular velocity.  Only
-certain atom styles, such as granular or dipole define this
+
    The omegax, omegay, and omegaz attributes are specific to
+extended spherical or aspherical particles that have an angular
+velocity.  Only certain atom styles, such as sphere define this
 quantity.
 
    
 
    The angmomx, angmomy, and angmomz attributes are specific to
 extended aspherical particles that have an angular momentum.  Only
 the ellipsoid atom style defines this quantity.
 
    
-
    The quatw, quati, quatj, quatk attributes are for aspherical
-particles defined with an atom style of ellipsoid.  They are the
-components of the quaternion that defines the orientation of the
-particle.
-
    
 
    The tqx, tqy, tqz attributes are for extended spherical or
 aspherical particles that can sustain a rotational torque due
 to interactions with other particles.
@@ -469,29 +507,34 @@ per-atom quantities which could then be output into dump files.
 
    Restrictions:
 
    
 
    To write gzipped dump files, you must compile LAMMPS with the
--DLAMMPS_GZIP option - see the Making LAMMPS
-section of the documentation.
+-DLAMMPS_GZIP option - see the Making
+LAMMPS section of the documentation.
 
    
-
    The xtc style is part of the "xtc" package.  It is only enabled if
-LAMMPS was built with that package.  See the Making
-LAMMPS section for more info.  This is because
-some machines may not support the low-level XDR data format that XTC
-files are written with, which will result in a compile-time error when
-a low-level include file is not found.  Putting this style in a package
-makes it easy to exclude from a LAMMPS build for those machines.
-However, the XTC package also includes two compatibility header files
-and associated functions, which should be a suitable substitute on
-machines that do not have the appropriate native header files.  This
-option can be invoked at build time by adding -DLAMMPS_XDR to the
-CCFLAGS variable in the appropriate low-level Makefile,
-e.g. src/MAKE/Makefile.foo.  This compatibility mode has been tested
-successfully on Cray XT3/XT4/XT5 and IBM BlueGene/L machines and 
-should also work on IBM BG/P, and Windows XP/Vista/7 machines.
+
    The xtc style is part of the XTC package.  It is only enabled if
+LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.  This is
+because some machines may not support the low-level XDR data format
+that XTC files are written with, which will result in a compile-time
+error when a low-level include file is not found.  Putting this style
+in a package makes it easy to exclude from a LAMMPS build for those
+machines.  However, the XTC package also includes two compatibility
+header files and associated functions, which should be a suitable
+substitute on machines that do not have the appropriate native header
+files.  This option can be invoked at build time by adding
+-DLAMMPS_XDR to the CCFLAGS variable in the appropriate low-level
+Makefile, e.g. src/MAKE/Makefile.foo.  This compatibility mode has
+been tested successfully on Cray XT3/XT4/XT5 and IBM BlueGene/L
+machines and should also work on IBM BG/P, and Windows XP/Vista/7
+machines.
 
    
 
    Related commands:
 
    
-
    dump_modify, undump
+
    dump image, dump_modify,
+undump
 
    
-
    Default: none
+
    Default:
+
    
+
    The defaults for the image style are listed on the dump
+image doc page.
 
    
 
diff --git a/doc/dump.txt b/doc/dump.txt
index 1c86bc6d9f..56df5f44a1 100644
--- a/doc/dump.txt
+++ b/doc/dump.txt
@@ -7,6 +7,7 @@
 :line
    
 dump command :h3
+"dump image"_dump_image.html command :h3
 
 [Syntax:]
 
@@ -14,7 +15,7 @@ dump ID group-ID style N file args :pre
 
 ID = user-assigned name for the dump :ulb,l
 group-ID = ID of the group of atoms to be dumped :l
-style = {atom} or {cfg} or {dcd} or {xtc} or {xyz} or {local} or {custom} :l
+style = {atom} or {cfg} or {dcd} or {xtc} or {xyz} or {image} or {local} or {custom} :l
 N = dump every this many timesteps :l
 file = name of file to write dump info to :l
 args = list of arguments for a particular style :l
@@ -24,6 +25,8 @@ args = list of arguments for a particular style :l
   {xtc} args = none
   {xyz} args = none :pre
 
+  {image} args = discussed on "dump image"_dump_image.html doc page :pre
+
   {local} args = list of local attributes
     possible attributes = index, c_ID, c_ID\[N\], f_ID, f_ID\[N\]
       index = enumeration of local values
@@ -31,34 +34,36 @@ args = list of arguments for a particular style :l
       c_ID\[N\] = Nth column of local array calculated by a compute with ID
       f_ID = local vector calculated by a fix with ID
       f_ID\[N\] = Nth column of local array calculated by a fix with ID :pre
-      
+
   {custom} args = list of atom attributes
-    possible attributes = id, mol, type, mass,
-			  x, y, z, xs, ys, zs, xu, yu, zu, ix, iy, iz,
+    possible attributes = id, mol, type, element, mass,
+			  x, y, z, xs, ys, zs, xu, yu, zu, 
+			  xsu, ysu, zsu, ix, iy, iz,
 			  vx, vy, vz, fx, fy, fz,
-                          q, mux, muy, muz,
-                          radius, omegax, omegay, omegaz,
-                          angmomx, angmomy, angmomz,
-			  quatw, quati, quatj, quatk, tqx, tqy, tqz,
+                          q, mux, muy, muz, mu,
+                          radius, diameter, omegax, omegay, omegaz,
+			  angmomx, angmomy, angmomz, tqx, tqy, tqz,
 			  spin, eradius, ervel, erforce,
 			  c_ID, c_ID\[N\], f_ID, f_ID\[N\], v_name :pre
 
       id = atom ID
       mol = molecule ID
       type = atom type
+      element = name of atom element, as defined by "dump_modify"_dump_modify.html command
       mass = atom mass
       x,y,z = unscaled atom coordinates
       xs,ys,zs = scaled atom coordinates
       xu,yu,zu = unwrapped atom coordinates
+      xsu,ysu,zsu = scaled unwrapped atom coordinates
       ix,iy,iz = box image that the atom is in
       vx,vy,vz = atom velocities
       fx,fy,fz = forces on atoms
       q = atom charge
-      mux,muy,muz = orientation of dipolar atom
-      radius = radius of extended spherical particle
+      mux,muy,muz = orientation of dipole moment of atom
+      mu = magnitude of dipole moment of atom
+      radius,diameter = radius,diameter of spherical particle
       omegax,omegay,omegaz = angular velocity of extended particle
       angmomx,angmomy,angmomz = angular momentum of extended particle
-      quatw,quati,quatj,quatk = quaternion components for aspherical particles
       tqx,tqy,tqz = torque on extended particles
       spin = electron spin
       eradius = electron radius
@@ -85,13 +90,19 @@ dump e_data all custom 100 dump.eff id type x y z spin eradius fx fy fz eforce :
 [Description:]
 
 Dump a snapshot of atom quantities to one or more files every N
-timesteps in one of several styles.  As described below, the filename
-determines the kind of output (text or binary or gzipped, one big file
-or one per timestep, one big file or one per processor).  Only
-information for atoms in the specified group is dumped.  The
-"dump_modify"_dump_modify.html command can also alter what atoms are
-included.  Not all styles support all these options; see details
-below.
+timesteps in one of several styles.  The {image} style is the
+exception; it creates a JPG or PPM image file of the atom
+configuration every N timesteps, as discussed on the "dump
+image"_dump_image.html doc page.
+
+Only information for atoms in the specified group is dumped.  The
+"dump_modify thresh and region"_dump_modify.html commands can also
+alter what atoms are included.  Not all styles support all these
+options; see details below.
+
+As described below, the filename determines the kind of output (text
+or binary or gzipped, one big file or one per timestep, one big file
+or one per processor).
 
 IMPORTANT NOTE: Because periodic boundary conditions are enforced only
 on timesteps when neighbor lists are rebuilt, the coordinates of an
@@ -132,32 +143,41 @@ self-describing in the following sense.
 The dimensions of the simulation box are included in each snapshot.
 For an orthogonal simulation box this information is is formatted as:
 
-ITEM: BOX BOUNDS
+ITEM: BOX BOUNDS xx yy zz
 xlo xhi
 ylo yhi
 zlo zhi :pre
 
 where xlo,xhi are the maximum extents of the simulation box in the
-x-dimension, and similarly for y and z.
+x-dimension, and similarly for y and z.  The "xx yy zz" represent 6
+characters that encode the style of boundary for each of the 6
+simulation box boundaries (xlo,xhi and ylo,yhi and zlo,zhi).  Each of
+the 6 characters is either p = periodic, f = fixed, s = shrink wrap,
+or m = shrink wrapped with a minimum value.  See the
+"boundary"_doc/boundary.html command for details.
 
 For triclinic simulation boxes (non-orthogonal), an orthogonal
 bounding box which encloses the triclinic simulation box is output,
 along with the 3 tilt factors (xy, xz, yz) of the triclinic box,
 formatted as follows:
 
-ITEM: BOX BOUNDS xy xz yz
+ITEM: BOX BOUNDS xy xz yz xx yy zz 
 xlo_bound xhi_bound xy
 ylo_bound yhi_bound xz
 zlo_bound zhi_bound yz :pre
 
-This bounding box is convenient for many visualization programs.
+The presence of the text "xy xz yz" in the ITEM line indicates that
+the 3 tilt factors will be included on each of the 3 following lines.
+This bounding box is convenient for many visualization programs.  The
+meaning of the 6 character flags for "xx yy zz" is the same as above.
 
-See "this section"_Section_howto.html#4_12 of the doc pages for a
-geometric description of triclinic boxes, as defined by LAMMPS, simple
-formulas for how the 6 bounding box extents (xlo_bound,xhi_bound,etc)
-are calculated from the triclinic parameters, and how to transform
-those parameters to and from other commonly used triclinic
-representations.
+Note that the first two numbers on each line are now xlo_bound instead
+of xlo, etc, since they repesent a bounding box.  See "this
+section"_Section_howto.html#howto_12 of the doc pages for a geometric
+description of triclinic boxes, as defined by LAMMPS, simple formulas
+for how the 6 bounding box extents (xlo_bound,xhi_bound,etc) are
+calculated from the triclinic parameters, and how to transform those
+parameters to and from other commonly used triclinic representations.
 
 The "ITEM: ATOMS" line in each snapshot lists column descriptors for
 the per-atom lines that follow.  For example, the descriptors would be
@@ -200,14 +220,23 @@ extended CFG format files, as used by the
 package.  Since the extended CFG format uses a single snapshot of the
 system per file, a wildcard "*" must be included in the filename, as
 discussed below.  The list of atom attributes for style {cfg} must
-begin with "id type xs ys zs", since these quantities are needed to
+begin with either "id type xs ys zs" or "id type xsu ysu zsu" or 
+since these quantities are needed to
 write the CFG files in the appropriate format (though the "id" and
 "type" fields do not appear explicitly in the file).  Any remaining
 attributes will be stored as "auxiliary properties" in the CFG files.
 Note that you will typically want to use the "dump_modify
 element"_dump_modify.html command with CFG-formatted files, to
 associate element names with atom types, so that AtomEye can render
-atoms appropriately.
+atoms appropriately. When unwrapped coordinates {xsu}, {ysu}, and {zsu}
+are requested, the nominal AtomEye periodic cell dimensions are expanded 
+by a large factor UNWRAPEXPAND = 10.0, which ensures atoms that are 
+displayed correctly for up to UNWRAPEXPAND/2 periodic boundary crossings 
+in any direction. 
+Beyond this, AtomEye will rewrap the unwrapped coordinates. 
+The expansion causes the atoms to be drawn farther
+away from the viewer, but it is easy to zoom the atoms closer, and
+the interatomic distances are unaffected.   
 
 The {dcd} style writes DCD files, a standard atomic trajectory format
 used by the CHARMM, NAMD, and XPlor molecular dynamics packages.  DCD
@@ -271,7 +300,10 @@ character appears in the filename, then one file per snapshot is
 written and the "*" character is replaced with the timestep value.
 For example, tmp.dump.* becomes tmp.dump.0, tmp.dump.10000,
 tmp.dump.20000, etc.  This option is not available for the {dcd} and
-{xtc} styles.
+{xtc} styles.  Note that the "dump_modify pad"_dump_modify.html
+command can be used to insure all timestep numbers are the same length
+(e.g. 00010), which can make it easier to read a series of dump files
+in order by some post-processing tools.
 
 If a "%" character appears in the filename, then one file is written
 for each processor and the "%" character is replaced with the
@@ -348,19 +380,23 @@ array calculated by the fix.
 This section explains the atom attributes that can be specified as
 part of the {custom} and {cfg} styles.
 
-The {id}, {mol}, {type}, {mass}, {vx}, {vy}, {vz}, {fx}, {fy},
+The {id}, {mol}, {type}, {element}, {mass}, {vx}, {vy}, {vz}, {fx}, {fy},
 {fz}, {q} attributes are self-explanatory.
 
 {Id} is the atom ID.  {Mol} is the molecule ID, included in the data
-file for molecular systems.  {Type} is the atom type.  {Mass} is the
-atom mass.  {Vx}, {vy}, {vz}, {fx}, {fy}, {fz}, and {q} are components
-of atom velocity and force and atomic charge.
+file for molecular systems.  {Type} is the atom type.  {Element} is
+typically the chemical name of an element, which you must assign to
+each type via the "dump_modify element"_dump_modify.html command.
+More generally, it can be any string you wish to associated with an
+atom type.  {Mass} is the atom mass.  {Vx}, {vy}, {vz}, {fx}, {fy},
+{fz}, and {q} are components of atom velocity and force and atomic
+charge.
 
 There are several options for outputting atom coordinates.  The {x},
 {y}, {z} attributes write atom coordinates "unscaled", in the
 appropriate distance "units"_units.html (Angstroms, sigma, etc).  Use
 {xs}, {ys}, {zs} if you want the coordinates "scaled" to the box size,
-so that each value is 0.0 to 1.0.  If the simluation box is triclinic
+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.  Use
 {xu}, {yu}, {zu} if you want the coordinates "unwrapped" by the image
 flags for each atom.  Unwrapped means that if the atom has passed thru
@@ -368,33 +404,34 @@ a periodic boundary one or more times, the value is printed for what
 the coordinate would be if it had not been wrapped back into the
 periodic box.  Note that using {xu}, {yu}, {zu} means that the
 coordinate values may be far outside the box bounds printed with the
-snapshot.  The image flags can be printed directly using the {ix},
+snapshot.  Using {xsu}, {ysu}, {zsu} is similar to using {xu}, {yu}, {zu},
+except that the unwrapped coordinates are scaled by the box size. Atoms
+that have passed through a periodic boundary will have the corresponding
+cooordinate increased or decreased by 1.0.
+
+The image flags can be printed directly using the {ix},
 {iy}, {iz} attributes. The "dump_modify"_dump_modify.html command
 describes in more detail what is meant by scaled vs unscaled
 coordinates and the image flags.
 
 The {mux}, {muy}, {muz} attributes are specific to dipolar systems
 defined with an atom style of {dipole}.  They give the orientation of
-the atom's point dipole moment.
+the atom's point dipole moment.  The {mu} attribute gives the
+magnitude of the atom's dipole moment.
 
-The {radius} attribute is specific to extended spherical particles
-that have a finite size, such as granular particles defined with
-an atom style of {granular}.
+The {radius} and {diameter} attributes are specific to extended
+spherical particles that have a finite size, such as those defined
+with an atom style of {sphere}.
 
-The {omegax}, {omegay}, and {omegaz} attributes are specific to extended
-spherical or aspherical particles that have an angular velocity.  Only
-certain atom styles, such as {granular} or {dipole} define this
+The {omegax}, {omegay}, and {omegaz} attributes are specific to
+extended spherical or aspherical particles that have an angular
+velocity.  Only certain atom styles, such as {sphere} define this
 quantity.
 
 The {angmomx}, {angmomy}, and {angmomz} attributes are specific to
 extended aspherical particles that have an angular momentum.  Only
 the {ellipsoid} atom style defines this quantity.
 
-The {quatw}, {quati}, {quatj}, {quatk} attributes are for aspherical
-particles defined with an atom style of {ellipsoid}.  They are the
-components of the quaternion that defines the orientation of the
-particle.
-
 The {tqx}, {tqy}, {tqz} attributes are for extended spherical or
 aspherical particles that can sustain a rotational torque due
 to interactions with other particles.
@@ -459,27 +496,32 @@ per-atom quantities which could then be output into dump files.
 [Restrictions:]
 
 To write gzipped dump files, you must compile LAMMPS with the
--DLAMMPS_GZIP option - see the "Making LAMMPS"_Section_start.html#2_2
-section of the documentation.
+-DLAMMPS_GZIP option - see the "Making
+LAMMPS"_Section_start.html#start_2 section of the documentation.
 
-The {xtc} style is part of the "xtc" package.  It is only enabled if
+The {xtc} style is part of the XTC package.  It is only enabled if
 LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.  This is because
-some machines may not support the low-level XDR data format that XTC
-files are written with, which will result in a compile-time error when
-a low-level include file is not found.  Putting this style in a package
-makes it easy to exclude from a LAMMPS build for those machines.
-However, the XTC package also includes two compatibility header files
-and associated functions, which should be a suitable substitute on
-machines that do not have the appropriate native header files.  This
-option can be invoked at build time by adding -DLAMMPS_XDR to the
-CCFLAGS variable in the appropriate low-level Makefile,
-e.g. src/MAKE/Makefile.foo.  This compatibility mode has been tested
-successfully on Cray XT3/XT4/XT5 and IBM BlueGene/L machines and 
-should also work on IBM BG/P, and Windows XP/Vista/7 machines.
+LAMMPS"_Section_start.html#start_3 section for more info.  This is
+because some machines may not support the low-level XDR data format
+that XTC files are written with, which will result in a compile-time
+error when a low-level include file is not found.  Putting this style
+in a package makes it easy to exclude from a LAMMPS build for those
+machines.  However, the XTC package also includes two compatibility
+header files and associated functions, which should be a suitable
+substitute on machines that do not have the appropriate native header
+files.  This option can be invoked at build time by adding
+-DLAMMPS_XDR to the CCFLAGS variable in the appropriate low-level
+Makefile, e.g. src/MAKE/Makefile.foo.  This compatibility mode has
+been tested successfully on Cray XT3/XT4/XT5 and IBM BlueGene/L
+machines and should also work on IBM BG/P, and Windows XP/Vista/7
+machines.
 
 [Related commands:]
 
-"dump_modify"_dump_modify.html, "undump"_undump.html
+"dump image"_dump_image.html, "dump_modify"_dump_modify.html,
+"undump"_undump.html
 
-[Default:] none
+[Default:]
+
+The defaults for the image style are listed on the "dump
+image"_dump_image.html doc page.
diff --git a/doc/dump_image.html b/doc/dump_image.html
new file mode 100644
index 0000000000..65eda7079d
--- /dev/null
+++ b/doc/dump_image.html
@@ -0,0 +1,455 @@
+
+
    LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
    
+
+
+
+
+
+
+
    
+
+
    dump image command 
+
    
+
    Syntax:
+
    
+
    dump ID group-ID image N file color diameter keyword value ... 
+
    
+
    • ID = user-assigned name for the dump 
+
+
    • group-ID = ID of the group of atoms to be imaged 
+
+
    • image = style of dump command (other styles atom or cfg or dcd or xtc or xyz or local or custom are discussed on the dump doc page) 
+
+
    • N = dump every this many timesteps 
+
+
    • file = name of file to write image to 
+
+
    • color = atom attribute that determines color of each atom 
+
+
    • diameter = atom attribute that determines size of each atom 
+
+
    • zero or more keyword/value pairs may be appended 
+
+
    • keyword = adiam or atom or bond or size or view or center or up or zoom or persp or box or axes or shiny or ssao 
+
+
        adiam value = number = numeric value for atom diameter (distance units)
+  atom = yes/no = do or do not draw atoms
+  bond values = color width = color and width of bonds
+    color = atom or type or none
+    width = number or atom or type or none
+      number = numeric value for bond width (distance units)
+  size values = width height = size of images
+    width = width of image in # of pixels
+    height = height of image in # of pixels
+  view values = theta phi = view of simulation box
+    theta = view angle from +z axis (degrees)
+    phi = azimuthal view angle (degrees)
+    theta or phi can be a variable (see below)
+  center values = flag Cx Cy Cz = center point of image
+    flag = "s" for static, "d" for dynamic
+    Cx,Cy,Cz = center point of image as fraction of box dimension (0.5 = center of box)
+    Cx,Cy,Cz can be variables (see below)
+  up values = Ux Uy Uz = direction that is "up" in image
+    Ux,Uy,Uz = components of up vector
+    Ux,Uy,Uz can be variables (see below)
+  zoom value = zfactor = size that simulation box appears in image
+    zfactor = scale image size by factor > 1 to enlarge, factor < 1 to shrink
+    zfactor can be a variable (see below)
+  persp value = pfactor = amount of "perspective" in image
+    pfactor = amount of perspective (0 = none, < 1 = some, > 1 = highly skewed)
+    pfactor can be a variable (see below)
+  box values = yes/no diam = draw outline of simulation box
+    yes/no = do or do not draw simulation box lines
+    diam = diameter of box lines as fraction of shortest box length
+  axes values = yes/no length diam = draw xyz axes
+    yes/no = do or do not draw xyz axes lines next to simulation box
+    length = length of axes lines as fraction of respective box lengths
+    diam = diameter of axes lines as fraction of shortest box length
+  shiny value = sfactor = shinyness of spheres and cylinders
+    sfactor = shinyness of spheres and cylinders from 0.0 to 1.0
+  ssao value = yes/no seed dfactor = SSAO depth shading
+    yes/no = turn depth shading on/off
+    seed = random # seed (positive integer)
+    dfactor = strength of shading from 0.0 to 1.0 
+
      
+
+
    
+
    Examples:
+
    
+
    dump myDump all image 100 dump.*.jpg type type 
+
    
+
    Description:
+
    
+
    Dump a high-quality ray-traced image of the atom configuration every N
+timesteps as either a JPG or PPM file.  A series of such images can
+easily be converted into an animated movie of your simulation; see
+further details below.  Other dump styles store snapshots of numerical
+data asociated with atoms in various formats, as discussed on the
+dump doc page.
+
    
+
    Here are two sample images, rendered as 1024x1024 JPG files.  Click to
+see the full-size images:
+
    
+
    
+
+
+
+
+
+
    
+
+
    Only atoms in the specified group are rendered in the image.  The
+dump_modify region and thresh commands can also
+alter what atoms are included in the image.
+
    
+
    The filename suffix determines whether a JPG or PPM file is created.
+If the suffix is ".jpg" or ".jpeg", then a JPG file is created, else a
+PPM file is created, which is a text-based format.  To write out JPG
+files, you must build LAMMPS with a JPEG library.  See this
+section of the manual for instructions
+on how to do this.
+
    
+
    IMPORTANT NOTE: Because periodic boundary conditions are enforced only
+on timesteps when neighbor lists are rebuilt, the coordinates of an
+atom in the image may be slightly outside the simulation box.
+
    
+
    
+
+
    Dumps are performed on timesteps that are a multiple of N (including
+timestep 0) and on the last timestep of a minimization if the
+minimization converges.  Note that this means a dump will not be
+performed on the initial timestep after the dump command is invoked,
+if the current timestep is not a multiple of N.  This behavior can be
+changed via the dump_modify first command, which
+can be useful if the dump command is invoked after a minimization
+ended on an arbitrary timestep.  N can be changed between runs by
+using the dump_modify every command.
+
    
+
    Dump image filenames must contain a wildcard character "*", so that
+one image file per snapshot is written.  The "*" character is replaced
+with the timestep value.  For example, tmp.dump.*.jpg becomes
+tmp.dump.0.jpg, tmp.dump.10000.jpg, tmp.dump.20000.jpg, etc.  Note
+that the dump_modify pad command can be used to
+insure all timestep numbers are the same length (e.g. 00010), which
+can make it easier to convert a series of images into a movie in the
+correct ordering.
+
    
+
    
+
+
    The color and diameter settings determine the color and size of
+atoms rendered in the image.  They can be any atom attribute defined
+for the dump custom command, including type and
+element.  This includes per-atom quantities calculated by a
+compute, fix, or variable,
+which are prefixed by "c_", "f_", or "v_" respectively.  Note that the
+diameter setting can be overridden with a numeric value by the
+optional adiam keyword, in which case you can specify the diameter
+setting with any valid atom attribute.
+
    
+
    If type is specified for the color setting, then the color of each
+atom is determined by its atom type.  By default the mapping of types
+to colors is as follows:
+
    
+
    • type 1 = red
+
    • type 2 = green
+
    • type 3 = blue
+
    • type 4 = yellow
+
    • type 5 = aqua
+
    • type 6 = cyan 
+
    
+
    and repeats itself for types > 6.  This mapping can be changed by the
+dump_modify acolor command.
+
    
+
    If type is specified for the diameter setting then the diameter of
+each atom is determined by its atom type.  By default all types have
+diameter 1.0.  This mapping can be changed by the dump_modify
+adiam command.
+
    
+
    If element is specified for the color and/or diameter setting,
+then the color and/or diameter of each atom is determined by which
+element it is, which in turn is specified by the element-to-type
+mapping specified by the "dump_modify element" command.  By default
+every atom type is C (carbon).  Every element has a color and diameter
+associated with it, which is the same as the colors and sizes used by
+the AtomEye visualization package.
+
    
+
+
+
    If other atom attributes are used for the color or diameter
+settings, they are interpreted in the following way.
+
    
+
    If "vx", for example, is used as the color setting, then the color
+of the atom will depend on the x-component of its velocity.  The
+association of a per-atom value with a specific color is determined by
+a "color map", which can be specified via the
+dump_modify command.  The basic idea is that the
+atom-attribute will be within a range of values, and every value
+within the range is mapped to a specific color.  Depending on how the
+color map is defined, that mapping can take place via interpolation so
+that a value of -3.2 is halfway between "red" and "blue", or
+discretely so that the value of -3.2 is "orange".
+
    
+
    If "vx", for example, is used as the diameter setting, then the atom
+will be rendered using the x-component of its velocity as the
+diameter.  If the per-atom value <= 0.0, them the atom will not be
+drawn.  Note that finite-size spherical particles, as defined by
+atom_style sphere define a per-particle radius or
+diameter, which can be used as the diameter setting.
+
    
+
    
+
+
    The various kewords listed above control how the image is rendered.
+As listed below, all of the keywords have defaults, most of which you
+will likely not need to change.  The dump modify
+also has options specific to the dump image style, particularly for
+assigning colors to atoms, bonds, and other image features.
+
    
+
    
+
+
    The adiam keyword allows you to override the diameter setting to a
+per-atom attribute with a specified numeric value.  All atoms will be
+drawn with that diameter, e.g. 1.5, which is in whatever distance
+units the input script defines, e.g. Angstroms.
+
    
+
    The atom keyword allow you to turn off the drawing of all atoms,
+if the specified value is no.
+
    
+
    The bond keyword allows to you to alter how bonds are drawn.  A bond
+is only drawn if both atoms in the bond are being drawn due to being
+in the specified group and due to other selection criteria
+(e.g. region, threshhold settings of the
+dump_modify command).  By default, bonds are drawn
+if they are defined in the input data file as read by the
+read_data command.  Using none for both the bond
+color and width value will turn off the drawing of all bonds.
+
    
+
    If atom is specified for the bond color value, then each bond is
+drawn in 2 halves, with the color of each half being the color of the
+atom at that end of the bond.
+
    
+
    If type is specified for the color value, then the color of each
+bond is determined by its bond type.  By default the mapping of bond
+types to colors is as follows:
+
    
+
    • type 1 = red
+
    • type 2 = green
+
    • type 3 = blue
+
    • type 4 = yellow
+
    • type 5 = aqua
+
    • type 6 = cyan 
+
    
+
    and repeats itself for bond types > 6.  This mapping can be changed by
+the dump_modify bcolor command.
+
    
+
    The bond width value can be a numeric value or atom or type (or
+none as indicated above).
+
    
+
    If a numeric value is specified, then all bonds will be drawn as
+cylinders with that diameter, e.g. 1.0, which is in whatever distance
+units the input script defines, e.g. Angstroms.
+
    
+
    If atom is specified for the width value, then each bond
+will be drawn with a width corresponding to the minimum diameter
+of the 2 atoms in the bond.
+
    
+
    If type is specified for the width value then the diameter of each
+bond is determined by its bond type.  By default all types have
+diameter 0.5.  This mapping can be changed by the dump_modify
+bdiam command.
+
    
+
    
+
+
    The size keyword sets the width and height of the created images,
+i.e. the number of pixels in each direction.
+
    
+
    
+
+
    The view, center, up, zoom, and persp values determine how
+3d simulation space is mapped to the 2d plane of the image.  Basically
+they control how the simulation box appears in the image.
+
    
+
    All of the view, center, up, zoom, and persp values can be
+specified as numeric quantities, whose meaning is explained below.
+Any of them can also be specified as an equal-style
+variable, by using v_name as the value, where "name" is
+the variable name.  In this case the variable will be evaluated on the
+timestep each image is created to create a new value.  If the
+equal-style variable is time-dependent, this is a means of changing
+the way the simulation box appears from image to image, effectively
+doing a pan or fly-by view of your simulation.
+
    
+
    The view keyword determines the viewpoint from which the simulation
+box is viewed, looking towards the center point.  The theta value
+is the vertical angle from the +z axis, and must be an angle from 0 to
+180 degrees.  The phi value is an azimuthal angle around the z axis
+and can be positive or negative.  A value of 0.0 is a view along the
++x axis, towards the center point.  If theta or phi are
+specified via variables, then the variable values should be in
+degrees.
+
    
+
    The center keyword determines the point in simulation space that
+will be at the center of the image.  Cx, Cy, and Cz are
+speficied as fractions of the box dimensions, so that (0.5,0.5,0.5) is
+the center of the simulation box.  These values do not have to be
+between 0.0 and 1.0, if you want the simulation box to be offset from
+the center of the image.  Note, however, that if you choose strange
+values for Cx, Cy, or Cz you may get a blank image.  Internally,
+Cx, Cy, and Cz are converted into a point in simulation space.
+If flag is set to "s" for static, then this conversion is done once,
+at the time the dump command is issued.  If flag is set to "d" for
+dynamic then the conversion is performed every time a new image is
+created.  If the box size or shape is changing, this will adjust the
+center point in simulation space.
+
    
+
    The up keyword determines what direction in simulation space will be
+"up" in the image.  Internally it is stored as a vector that is in the
+plane perpendicular to the view vector implied by the theta and
+pni values, and which is also in the plane defined by the view
+vector and user-specified up vector.  Thus this internal vector is
+computed from the user-specified up vector as
+
    
+
    up_internal = view cross (up cross view) 
+
    
+
    This means the only restriction on the specified up vector is that
+it cannot be parallel to the view vector, implied by the theta and
+phi values.
+
    
+
    The zoom keyword scales the size of the simulation box as it appears
+in the image.  The default zfactor value of 1 should display an
+image mostly filled by the atoms in the simulation box.  A zfactor >
+1 will make the simulation box larger; a zfactor < 1 will make it
+smaller.  Zfactor must be a value > 0.0.
+
    
+
    The persp keyword determines how much depth perspective is present
+in the image.  Depth perspective makes lines that are parallel in
+simulation space appear non-parallel in the image.  A pfactor value
+of 0.0 means that parallel lines will meet at infininty (1.0/pfactor),
+which is an orthographic rendering with no persepctive.  A pfactor
+value between 0.0 and 1.0 will introduce more perspective.  A pfactor
+value > 1 will create a highly skewed image with a large amount of
+perspective.
+
    
+
    IMPORTANT NOTE: The persp keyword is not yet supported as an option.
+
    
+
    
+
+
    The box keyword determines how the simulation box boundaries are
+rendered as thin cylinders in the image.  If no is set, then the box
+boundaries are not drawn and the diam setting is ignored.  If yes
+is set, the 12 edges of the box are drawn, with a diameter that is a
+fraction of the shortest box length in x,y,z (for 3d) or x,y (for 2d).
+The color of the box boundaries can be set with the dump_modify
+boxcolor command.
+
    
+
    The axes keyword determines how the coordinate axes are rendered as
+thin cylinders in the image.  If no is set, then the axes are not
+drawn and the length and diam settings are ignored.  If yes is
+set, 3 thin cylinders are drawn to represent the x,y,z axes in colors
+red,green,blue.  The origin of these cylinders will be offset from the
+lower left corner of the box by 10%.  The length setting determines
+how long the cylinders will be as a fraction of the respective box
+lengths.  The diam setting determines their thickness as a fraction
+of the shortest box length in x,y,z (for 3d) or x,y (for 2d).
+
    
+
    
+
+
    The shiny keyword determines how shiny the objects rendered in the
+image will appear.  The sfactor value must be a value 0.0 <=
+sfactor <= 1.0, where sfactor = 1 is a highly reflective surface
+and sfactor = 0 is a rough non-shiny surface.
+
    
+
    The ssao keyword turns on/off a screen space ambient occlusion
+(SSAO) model for depth shading.  If yes is set, then atoms further
+away from the viewer are darkened via a randomized process, which is
+perceived as depth.  The calculation of this effect can increase the
+cost of computing the image by roughly 2x.  The strength of the effect
+can be scaled by the dfactor parameter.  If no is set, no depth
+shading is performed.
+
    
+
    
+
+
    A series of JPG or PPM images can be converted into a movie file and
+then played as a movie using commonly available tools.
+
    
+
    Convert JPG or PPM files into an animated GIF or MPEG or other movie
+file:
+
    
+
    • a) Use the ImageMagick convert program. 
+
+
      % convert *.jpg foo.gif
+% convert *.ppm foo.mpg 
+
      
+
    • b) Use QuickTime. 
+
+
      Select "Open Image Sequence" under the File menu
+Load the images into QuickTime to animate them
+Select "Export" under the File menu
+Save the movie as a QuickTime movie (*.mov) or in another format
+
      
+
    • c) Windows-based tool. 
+
    
+
    If someone tells us how to do this via a common Windows-based tool,
+we'll post the instructions here.
+
    
+
    Play the movie:
+
    
+
    • a) Use your browser to view an animated GIF movie. 
+
+
      Select "Open File" under the File menu
+Load the animated GIF file
+
      
+
    • b) Use the freely available mplayer tool to view an MPEG movie. 
+
+
      % mplayer foo.mpg 
+
      
+
    • c) Use the Pizza.py
+animate tool,
+which works directly on a series of image files. 
+
+
      a = animate("foo*.jpg") 
+
      
+
    • d) QuickTime and other Windows-based media players can
+obviously play movie files directly. 
+
    
+
    
+
+
    See this section of the manual for information
+on how to add new compute and fix styles to LAMMPS to calculate
+per-atom quantities which could then be output into dump files.
+
    
+
    
+
+
    Restrictions:
+
    
+
    To write JPG images, you must use a -DLAMMPS_JPEG switch when building
+LAMMPS and link with a JPEG library.  See the Making
+LAMMPS section of the documentation for
+details.
+
    
+
    Related commands:
+
    
+
    dump, dump_modify, undump
+
    
+
    Default:
+
    
+
    The defaults for the keywords are as follows:
+
    
+
    • adiam = not specified (use diameter setting)
+
    • atom = yes
+
    • bond = none none (if no bonds in system)
+
    • bond = atom 0.5 (if bonds in system)
+
    • size = 512 512
+
    • view = 60 30 (for 3d)
+
    • view = 0 0 (for 2d)
+
    • center = s 0.5 0.5 0.5
+
    • up = 0 0 1 (for 3d)
+
    • up = 0 1 0 (for 2d)
+
    • zoom = 1.0
+
    • persp = 0.0
+
    • box = yes 0.02
+
    • axes = no 0.0 0.0
+
    • shiny = 1.0
+
    • ssao = no 
+
    
+
diff --git a/doc/dump_image.txt b/doc/dump_image.txt
new file mode 100644
index 0000000000..08a74c6de4
--- /dev/null
+++ b/doc/dump_image.txt
@@ -0,0 +1,439 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+dump image command :h3
+
+[Syntax:]
+
+dump ID group-ID image N file color diameter keyword value ... :pre
+
+ID = user-assigned name for the dump :ulb,l
+group-ID = ID of the group of atoms to be imaged :l
+image = style of dump command (other styles {atom} or {cfg} or {dcd} or {xtc} or {xyz} or {local} or {custom} are discussed on the "dump"_dump.html doc page) :l
+N = dump every this many timesteps :l
+file = name of file to write image to :l
+color = atom attribute that determines color of each atom :l
+diameter = atom attribute that determines size of each atom :l
+zero or more keyword/value pairs may be appended :l
+keyword = {adiam} or {atom} or {bond} or {size} or {view} or {center} or {up} or {zoom} or {persp} or {box} or {axes} or {shiny} or {ssao} :l
+  {adiam} value = number = numeric value for atom diameter (distance units)
+  {atom} = yes/no = do or do not draw atoms
+  {bond} values = color width = color and width of bonds
+    color = {atom} or {type} or {none}
+    width = number or {atom} or {type} or {none}
+      number = numeric value for bond width (distance units)
+  {size} values = width height = size of images
+    width = width of image in # of pixels
+    height = height of image in # of pixels
+  {view} values = theta phi = view of simulation box
+    theta = view angle from +z axis (degrees)
+    phi = azimuthal view angle (degrees)
+    theta or phi can be a variable (see below)
+  {center} values = flag Cx Cy Cz = center point of image
+    flag = "s" for static, "d" for dynamic
+    Cx,Cy,Cz = center point of image as fraction of box dimension (0.5 = center of box)
+    Cx,Cy,Cz can be variables (see below)
+  {up} values = Ux Uy Uz = direction that is "up" in image
+    Ux,Uy,Uz = components of up vector
+    Ux,Uy,Uz can be variables (see below)
+  {zoom} value = zfactor = size that simulation box appears in image
+    zfactor = scale image size by factor > 1 to enlarge, factor < 1 to shrink
+    zfactor can be a variable (see below)
+  {persp} value = pfactor = amount of "perspective" in image
+    pfactor = amount of perspective (0 = none, < 1 = some, > 1 = highly skewed)
+    pfactor can be a variable (see below)
+  {box} values = yes/no diam = draw outline of simulation box
+    yes/no = do or do not draw simulation box lines
+    diam = diameter of box lines as fraction of shortest box length
+  {axes} values = yes/no length diam = draw xyz axes
+    yes/no = do or do not draw xyz axes lines next to simulation box
+    length = length of axes lines as fraction of respective box lengths
+    diam = diameter of axes lines as fraction of shortest box length
+  {shiny} value = sfactor = shinyness of spheres and cylinders
+    sfactor = shinyness of spheres and cylinders from 0.0 to 1.0
+  {ssao} value = yes/no seed dfactor = SSAO depth shading
+    yes/no = turn depth shading on/off
+    seed = random # seed (positive integer)
+    dfactor = strength of shading from 0.0 to 1.0 :pre
+:ule
+
+[Examples:]
+
+dump myDump all image 100 dump.*.jpg type type :pre
+
+[Description:]
+
+Dump a high-quality ray-traced image of the atom configuration every N
+timesteps as either a JPG or PPM file.  A series of such images can
+easily be converted into an animated movie of your simulation; see
+further details below.  Other dump styles store snapshots of numerical
+data asociated with atoms in various formats, as discussed on the
+"dump"_dump.html doc page.
+
+Here are two sample images, rendered as 1024x1024 JPG files.  Click to
+see the full-size images:
+
+
    
+
+:image(JPG/dump1_small.jpg,JPG/dump1.jpg)
+:image(JPG/dump2_small.jpg,JPG/dump2.jpg)
+
+
    
+
+Only atoms in the specified group are rendered in the image.  The
+"dump_modify region and thresh"_dump_modify.html commands can also
+alter what atoms are included in the image.
+
+The filename suffix determines whether a JPG or PPM file is created.
+If the suffix is ".jpg" or ".jpeg", then a JPG file is created, else a
+PPM file is created, which is a text-based format.  To write out JPG
+files, you must build LAMMPS with a JPEG library.  See "this
+section"_Section_start.html#start_2_4 of the manual for instructions
+on how to do this.
+
+IMPORTANT NOTE: Because periodic boundary conditions are enforced only
+on timesteps when neighbor lists are rebuilt, the coordinates of an
+atom in the image may be slightly outside the simulation box.
+
+:line
+
+Dumps are performed on timesteps that are a multiple of N (including
+timestep 0) and on the last timestep of a minimization if the
+minimization converges.  Note that this means a dump will not be
+performed on the initial timestep after the dump command is invoked,
+if the current timestep is not a multiple of N.  This behavior can be
+changed via the "dump_modify first"_dump_modify.html command, which
+can be useful if the dump command is invoked after a minimization
+ended on an arbitrary timestep.  N can be changed between runs by
+using the "dump_modify every"_dump_modify.html command.
+
+Dump image filenames must contain a wildcard character "*", so that
+one image file per snapshot is written.  The "*" character is replaced
+with the timestep value.  For example, tmp.dump.*.jpg becomes
+tmp.dump.0.jpg, tmp.dump.10000.jpg, tmp.dump.20000.jpg, etc.  Note
+that the "dump_modify pad"_dump_modify.html command can be used to
+insure all timestep numbers are the same length (e.g. 00010), which
+can make it easier to convert a series of images into a movie in the
+correct ordering.
+
+:line
+
+The {color} and {diameter} settings determine the color and size of
+atoms rendered in the image.  They can be any atom attribute defined
+for the "dump custom"_dump.html command, including {type} and
+{element}.  This includes per-atom quantities calculated by a
+"compute"_compute.html, "fix"_fix.html, or "variable"_variable.html,
+which are prefixed by "c_", "f_", or "v_" respectively.  Note that the
+{diameter} setting can be overridden with a numeric value by the
+optional {adiam} keyword, in which case you can specify the {diameter}
+setting with any valid atom attribute.
+
+If {type} is specified for the {color} setting, then the color of each
+atom is determined by its atom type.  By default the mapping of types
+to colors is as follows:
+
+type 1 = red
+type 2 = green
+type 3 = blue
+type 4 = yellow
+type 5 = aqua
+type 6 = cyan :ul
+
+and repeats itself for types > 6.  This mapping can be changed by the
+"dump_modify acolor"_dump_modify.html command.
+
+If {type} is specified for the {diameter} setting then the diameter of
+each atom is determined by its atom type.  By default all types have
+diameter 1.0.  This mapping can be changed by the "dump_modify
+adiam"_dump_modify.html command.
+
+If {element} is specified for the {color} and/or {diameter} setting,
+then the color and/or diameter of each atom is determined by which
+element it is, which in turn is specified by the element-to-type
+mapping specified by the "dump_modify element" command.  By default
+every atom type is C (carbon).  Every element has a color and diameter
+associated with it, which is the same as the colors and sizes used by
+the "AtomEye"_atomeye visualization package.
+
+:link(atomeye,http://mt.seas.upenn.edu/Archive/Graphics/A)
+
+If other atom attributes are used for the {color} or {diameter}
+settings, they are interpreted in the following way.
+
+If "vx", for example, is used as the {color} setting, then the color
+of the atom will depend on the x-component of its velocity.  The
+association of a per-atom value with a specific color is determined by
+a "color map", which can be specified via the
+"dump_modify"_dump_modify.html command.  The basic idea is that the
+atom-attribute will be within a range of values, and every value
+within the range is mapped to a specific color.  Depending on how the
+color map is defined, that mapping can take place via interpolation so
+that a value of -3.2 is halfway between "red" and "blue", or
+discretely so that the value of -3.2 is "orange".
+
+If "vx", for example, is used as the {diameter} setting, then the atom
+will be rendered using the x-component of its velocity as the
+diameter.  If the per-atom value <= 0.0, them the atom will not be
+drawn.  Note that finite-size spherical particles, as defined by
+"atom_style sphere"_atom_style.html define a per-particle radius or
+diameter, which can be used as the {diameter} setting.
+
+:line
+
+The various kewords listed above control how the image is rendered.
+As listed below, all of the keywords have defaults, most of which you
+will likely not need to change.  The "dump modify"_dump_modify.html
+also has options specific to the dump image style, particularly for
+assigning colors to atoms, bonds, and other image features.
+
+:line
+
+The {adiam} keyword allows you to override the {diameter} setting to a
+per-atom attribute with a specified numeric value.  All atoms will be
+drawn with that diameter, e.g. 1.5, which is in whatever distance
+"units"_units.html the input script defines, e.g. Angstroms.
+
+The {atom} keyword allow you to turn off the drawing of all atoms,
+if the specified value is {no}.
+
+The {bond} keyword allows to you to alter how bonds are drawn.  A bond
+is only drawn if both atoms in the bond are being drawn due to being
+in the specified group and due to other selection criteria
+(e.g. region, threshhold settings of the
+"dump_modify"_dump_modify.html command).  By default, bonds are drawn
+if they are defined in the input data file as read by the
+"read_data"_read_data.html command.  Using {none} for both the bond
+{color} and {width} value will turn off the drawing of all bonds.
+
+If {atom} is specified for the bond {color} value, then each bond is
+drawn in 2 halves, with the color of each half being the color of the
+atom at that end of the bond.
+
+If {type} is specified for the {color} value, then the color of each
+bond is determined by its bond type.  By default the mapping of bond
+types to colors is as follows:
+
+type 1 = red
+type 2 = green
+type 3 = blue
+type 4 = yellow
+type 5 = aqua
+type 6 = cyan :ul
+
+and repeats itself for bond types > 6.  This mapping can be changed by
+the "dump_modify bcolor"_dump_modify.html command.
+
+The bond {width} value can be a numeric value or {atom} or {type} (or
+{none} as indicated above).
+
+If a numeric value is specified, then all bonds will be drawn as
+cylinders with that diameter, e.g. 1.0, which is in whatever distance
+"units"_units.html the input script defines, e.g. Angstroms.
+
+If {atom} is specified for the {width} value, then each bond
+will be drawn with a width corresponding to the minimum diameter
+of the 2 atoms in the bond.
+
+If {type} is specified for the {width} value then the diameter of each
+bond is determined by its bond type.  By default all types have
+diameter 0.5.  This mapping can be changed by the "dump_modify
+bdiam"_dump_modify.html command.
+
+:line
+
+The {size} keyword sets the width and height of the created images,
+i.e. the number of pixels in each direction.
+
+:line
+
+The {view}, {center}, {up}, {zoom}, and {persp} values determine how
+3d simulation space is mapped to the 2d plane of the image.  Basically
+they control how the simulation box appears in the image.
+
+All of the {view}, {center}, {up}, {zoom}, and {persp} values can be
+specified as numeric quantities, whose meaning is explained below.
+Any of them can also be specified as an "equal-style
+variable"_variable.html, by using v_name as the value, where "name" is
+the variable name.  In this case the variable will be evaluated on the
+timestep each image is created to create a new value.  If the
+equal-style variable is time-dependent, this is a means of changing
+the way the simulation box appears from image to image, effectively
+doing a pan or fly-by view of your simulation.
+
+The {view} keyword determines the viewpoint from which the simulation
+box is viewed, looking towards the {center} point.  The {theta} value
+is the vertical angle from the +z axis, and must be an angle from 0 to
+180 degrees.  The {phi} value is an azimuthal angle around the z axis
+and can be positive or negative.  A value of 0.0 is a view along the
++x axis, towards the {center} point.  If {theta} or {phi} are
+specified via variables, then the variable values should be in
+degrees.
+
+The {center} keyword determines the point in simulation space that
+will be at the center of the image.  {Cx}, {Cy}, and {Cz} are
+speficied as fractions of the box dimensions, so that (0.5,0.5,0.5) is
+the center of the simulation box.  These values do not have to be
+between 0.0 and 1.0, if you want the simulation box to be offset from
+the center of the image.  Note, however, that if you choose strange
+values for {Cx}, {Cy}, or {Cz} you may get a blank image.  Internally,
+{Cx}, {Cy}, and {Cz} are converted into a point in simulation space.
+If {flag} is set to "s" for static, then this conversion is done once,
+at the time the dump command is issued.  If {flag} is set to "d" for
+dynamic then the conversion is performed every time a new image is
+created.  If the box size or shape is changing, this will adjust the
+center point in simulation space.
+
+The {up} keyword determines what direction in simulation space will be
+"up" in the image.  Internally it is stored as a vector that is in the
+plane perpendicular to the view vector implied by the {theta} and
+{pni} values, and which is also in the plane defined by the view
+vector and user-specified up vector.  Thus this internal vector is
+computed from the user-specified {up} vector as
+
+up_internal = view cross (up cross view) :pre
+
+This means the only restriction on the specified {up} vector is that
+it cannot be parallel to the {view} vector, implied by the {theta} and
+{phi} values.
+
+The {zoom} keyword scales the size of the simulation box as it appears
+in the image.  The default {zfactor} value of 1 should display an
+image mostly filled by the atoms in the simulation box.  A {zfactor} >
+1 will make the simulation box larger; a {zfactor} < 1 will make it
+smaller.  {Zfactor} must be a value > 0.0.
+
+The {persp} keyword determines how much depth perspective is present
+in the image.  Depth perspective makes lines that are parallel in
+simulation space appear non-parallel in the image.  A {pfactor} value
+of 0.0 means that parallel lines will meet at infininty (1.0/pfactor),
+which is an orthographic rendering with no persepctive.  A {pfactor}
+value between 0.0 and 1.0 will introduce more perspective.  A {pfactor}
+value > 1 will create a highly skewed image with a large amount of
+perspective.
+
+IMPORTANT NOTE: The {persp} keyword is not yet supported as an option.
+
+:line
+
+The {box} keyword determines how the simulation box boundaries are
+rendered as thin cylinders in the image.  If {no} is set, then the box
+boundaries are not drawn and the {diam} setting is ignored.  If {yes}
+is set, the 12 edges of the box are drawn, with a diameter that is a
+fraction of the shortest box length in x,y,z (for 3d) or x,y (for 2d).
+The color of the box boundaries can be set with the "dump_modify
+boxcolor"_dump_modify.html command.
+
+The {axes} keyword determines how the coordinate axes are rendered as
+thin cylinders in the image.  If {no} is set, then the axes are not
+drawn and the {length} and {diam} settings are ignored.  If {yes} is
+set, 3 thin cylinders are drawn to represent the x,y,z axes in colors
+red,green,blue.  The origin of these cylinders will be offset from the
+lower left corner of the box by 10%.  The {length} setting determines
+how long the cylinders will be as a fraction of the respective box
+lengths.  The {diam} setting determines their thickness as a fraction
+of the shortest box length in x,y,z (for 3d) or x,y (for 2d).
+
+:line
+
+The {shiny} keyword determines how shiny the objects rendered in the
+image will appear.  The {sfactor} value must be a value 0.0 <=
+{sfactor} <= 1.0, where {sfactor} = 1 is a highly reflective surface
+and {sfactor} = 0 is a rough non-shiny surface.
+
+The {ssao} keyword turns on/off a screen space ambient occlusion
+(SSAO) model for depth shading.  If {yes} is set, then atoms further
+away from the viewer are darkened via a randomized process, which is
+perceived as depth.  The calculation of this effect can increase the
+cost of computing the image by roughly 2x.  The strength of the effect
+can be scaled by the {dfactor} parameter.  If {no} is set, no depth
+shading is performed.
+
+:line
+
+A series of JPG or PPM images can be converted into a movie file and
+then played as a movie using commonly available tools.
+
+Convert JPG or PPM files into an animated GIF or MPEG or other movie
+file:
+
+a) Use the ImageMagick convert program. :ulb,l
+
+% convert *.jpg foo.gif
+% convert *.ppm foo.mpg :pre
+
+b) Use QuickTime. :l
+
+Select "Open Image Sequence" under the File menu
+Load the images into QuickTime to animate them
+Select "Export" under the File menu
+Save the movie as a QuickTime movie (*.mov) or in another format
+
+c) Windows-based tool. :ule,l
+
+If someone tells us how to do this via a common Windows-based tool,
+we'll post the instructions here.
+
+Play the movie:
+
+a) Use your browser to view an animated GIF movie. :ulb,l
+
+Select "Open File" under the File menu
+Load the animated GIF file
+
+b) Use the freely available mplayer tool to view an MPEG movie. :l
+
+% mplayer foo.mpg :pre
+
+c) Use the "Pizza.py"_http://www.sandia.gov/~sjplimp/pizza.html
+"animate tool"_http://www.sandia.gov/~sjplimp/pizza/doc/animate.html,
+which works directly on a series of image files. :l
+
+a = animate("foo*.jpg") :pre
+
+d) QuickTime and other Windows-based media players can
+obviously play movie files directly. :ule,l
+
+:line
+
+See "this section"_Section_modify.html of the manual for information
+on how to add new compute and fix styles to LAMMPS to calculate
+per-atom quantities which could then be output into dump files.
+
+:line
+
+[Restrictions:]
+
+To write JPG images, you must use a -DLAMMPS_JPEG switch when building
+LAMMPS and link with a JPEG library.  See the "Making
+LAMMPS"_Section_start.html#start_2_4 section of the documentation for
+details.
+
+[Related commands:]
+
+"dump"_dump.html, "dump_modify"_dump_modify.html, "undump"_undump.html
+
+[Default:]
+
+The defaults for the keywords are as follows:
+
+adiam = not specified (use diameter setting)
+atom = yes
+bond = none none (if no bonds in system)
+bond = atom 0.5 (if bonds in system)
+size = 512 512
+view = 60 30 (for 3d)
+view = 0 0 (for 2d)
+center = s 0.5 0.5 0.5
+up = 0 0 1 (for 3d)
+up = 0 1 0 (for 2d)
+zoom = 1.0
+persp = 0.0
+box = yes 0.02
+axes = no 0.0 0.0
+shiny = 1.0
+ssao = no :ul
diff --git a/doc/dump_modify.html b/doc/dump_modify.html
index 21f0943757..b15a322db0 100644
--- a/doc/dump_modify.html
+++ b/doc/dump_modify.html
@@ -19,9 +19,48 @@
 
 
  • one or more keyword/value pairs may be appended 
 
-
  • keyword = append or every or flush or format or image or label or precision or region or scale or sort or thresh or unwrap 
+
  • keyword = acolor or adiam or amap or append or bcolor or bdiam or backcolor or boxcolor or color or every or flush or format or image or label or precision or region or scale or sort or thresh or unwrap 
 
-
      append arg = yes or no
+
      acolor args = type color
+    type = atom type or range of types (see below)
+    color = name of color or color1/color2/...
+  adiam args = type diam
+    type = atom type or range of types (see below)
+    diam = diameter of atoms of that type (distance units)
+  amap args = lo hi style N delta entry1 entry2 ... entryN
+    lo = number or min = lower bound of range of color map
+    hi = number or max = upper bound of range of color map
+    style = 2 letters = "c" or "d" or "s" plus "a" or "f"
+      "c" for continuous
+      "d" for discrete
+      "s" for sequential
+      "a" for absolute
+      "f" for fractional
+    delta = binsize (only used for style "s", otherwise ignored)
+      binsize = range is divided into bins of this width
+    N = # of subsequent entries
+    entry = value color (for continuous style)
+      value = number or min or max = single value within range
+      color = name of color used for that value
+    entry = lo hi color (for discrete style)
+      lo/hi = number or min or max = lower/upper bound of subset of range
+      color = name of color used for that subset of values
+    entry = color (for sequential style)
+      color = name of color used for a bin of values
+  append arg = yes or no
+  bcolor args = type color
+    type = bond type or range of types (see below)
+    color = name of color or color1/color2/...
+  bdiam args = type diam
+    type = bond type or range of types (see below)
+    diam = diameter of bonds of that type (distance units)
+  backcolor arg = color
+    color = name of color for background
+  boxcolor arg = color
+    color = name of color for box lines
+  color args = name R G B
+    name = name of color
+    R,G,B = red/green/blue numeric values from 0.0 to 1.0
   element args = E1 E2 ... EN, where N = # of atom types
     E1,...,EN = element name, e.g. C or Fe or Ga
   every arg = N
@@ -60,11 +99,162 @@ dump_modify xtcdump precision 10000
 dump_modify 1 every 1000
 dump_modify 1 every v_myVar 
 
    
+
    dump_modify 1 amap min max cf 0.0 3 min green 0.5 yellow max blue boxcolor red 
+
    
 
    Description:
 
    
 
    Modify the parameters of a previously defined dump command.  Not all
 parameters are relevant to all dump styles.
 
    
+
    
+
+
    The acolor keyword applies only to the dump image style.  It can
+be used with the dump image command, when its atom
+color setting is type, to set the color that atoms of each type will
+be drawn in the image.
+
    
+
    The specified type should be an integer from 1 to Ntypes = the
+number of atom types.  A wildcard asterisk can be used in place of or
+in conjunction with the type argument to specify a range of atom
+types.  This takes the form "*" or "*n" or "n*" or "m*n".  If N = the
+number of atom types, then an asterisk with no numeric values means
+all types from 1 to N.  A leading asterisk means all types from 1 to n
+(inclusive).  A trailing asterisk means all types from n to N
+(inclusive).  A middle asterisk means all types from m to n
+(inclusive).
+
    
+
    The specified color can be a single color which is any of the 140
+pre-defined colors (see below) or a color name defined by the
+dump_modify color option.  Or it can be two or more colors separated
+by a "/" character, e.g. red/green/blue.  In the former case, that
+color is assigned to all the specified atom types.  In the latter
+case, the list of colors are assigned in a round-robin fashion to each
+of the specified atom types.
+
    
+
    
+
+
    The adiam keyword applies only to the dump image style.  It can be
+used with the dump image command, when its atom
+diameter setting is type, to set the size that atoms of each type
+will be drawn in the image.  The specified type should be an integer
+from 1 to Ntypes.  As with the acolor keyword, a wildcard asterisk
+can be used as part of the type argument to specify a range of atomt
+types.  The specified diam is the size in whatever distance
+units the input script is using, e.g. Angstroms.
+
    
+
    
+
+
    The amap keyword applies only to the dump image style.  It can be
+used with the dump image command, with its atom
+keyword, when its atom setting is an atom-attribute, to setup a color
+map.  The color map is used to assign a specific RGB (red/green/blue)
+color value to an individual atom when it is drawn, based on the
+atom's attribute, which is a numeric value, e.g. its x-component of
+velocity if the atom-attribute "vx" was specified.
+
    
+
    The basic idea of a color map is that the atom-attribute will be
+within a range of values, and that range is associated with a a series
+of colors (e.g. red, blue, green).  An atom's specific value (vx =
+-3.2) can then mapped to the series of colors (e.g. halfway between
+red and blue), and a specific color is determined via an interpolation
+procedure.
+
    
+
    There are many possible options for the color map, enabled by the
+amap keyword.  Here are the details.
+
    
+
    The lo and hi settings determine the range of values allowed for
+the atom attribute.  If numeric values are used for lo and/or hi,
+then values that are lower/higher than that value are set to the
+value.  I.e. the range is static.  If lo is specified as min or
+hi as max then the range is dynamic, and the lower and/or
+upper bound will be calculated each time an image is drawn, based
+on the set of atoms being visualized.
+
    
+
    The style setting is two letters, such as "ca".  The first letter is
+either "c" for continuous, "d" for discrete, or "s" for sequential.
+The second letter is either "a" for absolute, or "f" for fractional.
+
    
+
    A continuous color map is one in which the color changes continuously
+from value to value within the range.  A discrete color map is one in
+which discrete colors are assigned to sub-ranges of values within the
+range.  A sequential color map is one in which discrete colors are
+assigned to a sequence of sub-ranges of values covering the entire
+range.
+
    
+
    An absolute color map is one in which the values to which colors are
+assigned are specified explicitly as values within the range.  A
+fractional color map is one in which the values to which colors are
+assigned are specified as a fractional portion of the range.  For
+example if the range is from -10.0 to 10.0, and the color red is to be
+assigned to atoms with a value of 5.0, then for an absolute color map
+the number 5.0 would be used.  But for a fractional map, the number
+0.75 would be used since 5.0 is 3/4 of the way from -10.0 to 10.0.
+
    
+
    The delta setting is only specified if the style is sequential.  It
+specifies the bin size to use within the range for assigning
+consecutive colors to.  For example, if the range is from -10.0 to
+10.0 and a delta of 1.0 is used, then 20 colors will be assigned to
+the range.  The first will be from -10.0 <= color1 < -9.0, then 2nd
+from -9.0 <= color2 < -8.0, etc.
+
    
+
    The N setting is how many entries follow.  The format of the entries
+depends on whether the color map style is continuous, discrete or
+sequential.  In all cases the color setting can be any of the 140
+pre-defined colors (see below) or a color name defined by the
+dump_modify color option.
+
    
+
    For continuous color maps, each entry has a value and a color.
+The value is either a number within the range of values or min or
+max.  The value of the first entry must be min and the value
+of the last entry must be max.  Any entries in between must have
+increasing values.  Note that numeric values can be specified either
+as absolute numbers or as fractions (0.0 to 1.0) of the range,
+depending on the "a" or "f" in the style setting for the color map.
+
    
+
    Here is how the entries are used to determine the color of an
+individual atom, given the value X of its atom attribute.  X will fall
+between 2 of the entry values.  The color of the atom is linearly
+interpolated (in each of the RGB values) between the 2 colors
+associated with those entries.  For example, if X = -5.0 and the 2
+surrounding entries are "red" at -10.0 and "blue" at 0.0, then the
+atom's color will be halfway between "red" and "blue", which happens
+to be "purple".
+
    
+
    For discrete color maps, each entry has a lo and hi value and a
+color.  The lo and hi settings are either numbers within the
+range of values or lo can be min or hi can be max.  The lo
+and hi settings of the last entry must be min and max.  Other
+entries can have any lo and hi values and the sub-ranges of
+different values can overlap.  Note that numeric lo and hi values
+can be specified either as absolute numbers or as fractions (0.0 to
+1.0) of the range, depending on the "a" or "f" in the style setting
+for the color map.
+
    
+
    Here is how the entries are used to determine the color of an
+individual atom, given the value X of its atom attribute.  The entries
+are scanned from first to last.  The first time that lo <= X <=
+hi, X is assigned the color associated with that entry.  You can
+think of the last entry as assigning a default color (since it will
+always be matched by X), and the earlier entries as colors that
+override the default.  Also note that no interpolation of a color RGB
+is done.  All atoms will be drawn with one of the colors in the list
+of entries.
+
    
+
    For sequential color maps, each entry has only a color.  Here is how
+the entries are used to determine the color of an individual atom,
+given the value X of its atom attribute.  The range is partitioned
+into N bins of width binsize.  Thus X will fall in a specific bin
+from 1 to N, say the Mth bin.  If it falls on a boundary between 2
+bins, it is considered to be in the higher of the 2 bins.  Each bin is
+assigned a color from the E entries.  If E < N, then the colors are
+repeated.  For example if 2 entries with colors red and green are
+specified, then the odd numbered bins will be red and the even bins
+green.  The color of the atom is the color of its bin.  Note that the
+sequential color map is really a shorthand way of defining a discrete
+color map without having to specify where all the bin boundaries are.
+
    
+
    
+
 
    The append keyword applies to all dump styles except cfg and xtc
 and dcd.  It also applies only to text output files, not to binary
 or gzipped files.  If specified as yes, then dump snapshots are
@@ -76,14 +266,88 @@ before the first command that causes dump snapshots to be output,
 e.g. a run or minimize command.  Once the
 dump file has been opened, this keyword has no further effect.
 
    
-
    The element keyword applies only to the the dump cfg style.  It
-associates element names (e.g. H, C, Fe) with LAMMPS atom types, so
-that the AtomEye
-visualization package can render atoms with the appropriate size and
-color.  An element name is specified for each atom type (1 to Ntype)
-in the simulation.  The same element name can be given to multiple
-atom types.
+
    
+
+
    The bcolor keyword applies only to the dump image style.  It can
+be used with the dump image command, with its bond
+keyword, when its color setting is type, to set the color that bonds
+of each type will be drawn in the image.
 
    
+
    The specified type should be an integer from 1 to Nbondtypes = the
+number of bond types.  A wildcard asterisk can be used in place of or
+in conjunction with the type argument to specify a range of bond
+types.  This takes the form "*" or "*n" or "n*" or "m*n".  If N = the
+number of bond types, then an asterisk with no numeric values means
+all types from 1 to N.  A leading asterisk means all types from 1 to n
+(inclusive).  A trailing asterisk means all types from n to N
+(inclusive).  A middle asterisk means all types from m to n
+(inclusive).
+
    
+
    The specified color can be a single color which is any of the 140
+pre-defined colors (see below) or a color name defined by the
+dump_modify color option.  Or it can be two or more colors separated
+by a "/" character, e.g. red/green/blue.  In the former case, that
+color is assigned to all the specified bond types.  In the latter
+case, the list of colors are assigned in a round-robin fashion to each
+of the specified bond types.
+
    
+
    
+
+
    The bdiam keyword applies only to the dump image style.  It can be
+used with the dump image command, with its bond
+keyword, when its diam setting is type, to set the diameter that
+bonds of each type will be drawn in the image.  The specified type
+should be an integer from 1 to Nbondtypes.  As with the bcolor
+keyword, a wildcard asterisk can be used as part of the type
+argument to specify a range of bond types.  The specified diam is
+the size in whatever distance units you are using,
+e.g. Angstroms.
+
    
+
    
+
+
    The backcolor keyword applies only to the dump image style.  It
+sets the background color of the images.  The color name can be any of
+the 140 pre-defined colors (see below) or a color name defined by the
+dump_modify color option.
+
    
+
    
+
+
    The boxcolor keyword applies only to the dump image style.  It
+sets the color of the simulation box drawn around the atoms in each
+image.  See the "dump image box" command for how to specify that a box
+be drawn.  The color name can be any of the 140 pre-defined colors
+(see below) or a color name defined by the dump_modify color option.
+
    
+
    
+
+
    The color keyword applies only to the dump image style.  It allows
+definition of a new color name, in addition to the 140-predefined
+colors (see below), and associates 3 red/green/blue RGB values with
+that color name.  The color name can then be used with any other
+dump_modify keyword that takes a color name as a value.  The RGB
+values should each be floating point values between 0.0 and 1.0
+inclusive.
+
    
+
    When a color name is converted to RGB values, the user-defined color
+names are searched first, then the 140 pre-defined color names.  This
+means you can also use the color keyword to overwrite one of the
+pre-defined color names with new RBG values.
+
    
+
    
+
+
    The element keyword applies only to the the dump cfg and image
+styles.  It associates element names (e.g. H, C, Fe) with LAMMPS atom
+types.  In the case of dump cfg, it allows the AtomEye
+visualization package to read the dump file and render atoms with the
+appropriate size and color.  In the case of dump image, the output
+images will follow the same AtomEye convention.  An element
+name is specified for each atom type (1 to Ntype) in the simulation.
+The same element name can be given to multiple atom types.
+
    
+
+
+
    
+
 
    The every keyword changes the dump frequency originally specified by
 the dump command to a new value.  The every keyword can be
 specified in one of two ways.  It can be a numeric value in which case
@@ -109,6 +373,8 @@ write snapshots at timesteps 0,10,20,30,100,200,300,1000,2000,etc:
 dump		1 all atom 100 tmp.dump
 dump_modify	1 every v_s first yes 
 
    
+
    
+
 
    The first keyword determines whether a dump snapshot is written on
 the very first timestep after the dump command is invoked.  This will
 always occur if the current timestep is a multiple of N, the frequency
@@ -117,6 +383,8 @@ if this is not the case, a dump snapshot will only be written if the
 setting of this keyword is yes.  If it is no, which is the
 default, then it will not be written.
 
    
+
    
+
 
    The flush keyword determines whether a flush operation is invoked
 after a dump snapshot is written to the dump file.  A flush insures
 the output in that file is current (no buffering by the OS), even if
@@ -133,6 +401,8 @@ the first two fields (atom id and type) are not actually written into
 the CFG file, though you must include formats for them in the format
 string.
 
    
+
    
+
 
    The image keyword applies only to the dump atom style.  If the
 image value is yes, 3 flags are appended to each atom's coords which
 are the absolute box image of the atom in each dimension.  For
@@ -143,6 +413,8 @@ current coordinate.  Note that for dump style custom these various
 values can be printed in the dump file by using the appropriate atom
 attributes in the dump command itself.
 
    
+
    
+
 
    The label keyword applies only to the dump local style.  When
 it writes local informatoin, such as bond or angle topology
 to a dump file, it will use the specified label to format
@@ -154,6 +426,8 @@ ITEM: ENTRIES ...
 
    The word "ENTRIES" will be replaced with the string specified,
 e.g. BONDS or ANGLES.
 
    
+
    
+
 
    The pad keyword only applies when the dump filename is specified
 with a wildcard "*" character which becomes the timestep.  If pad is
 0, which is the default, the timestep is converted into a string of
@@ -164,19 +438,25 @@ yield 0000100, 0012000, 2000000.  This can be useful so that
 post-processing programs can easily read the files in ascending
 timestep order.
 
    
+
    
+
 
    The precision keyword only applies to the dump xtc style.  A
 specified value of N means that coordinates are stored to 1/N
 nanometer accuracy, e.g. for N = 1000, the coordinates are written to
 1/1000 nanometer accuracy.
 
    
-
    The region keyword only applies to the dump custom and cfg
-styles.  If specified, only atoms in the region will be written to the
-dump file.  Only one region can be applied as a filter (the last one
-specified).  See the region command for more details.
-Note that a region can be defined as the "inside" or "outside" of a
-geometric shape, and it can be the "union" or "intersection" of a
-series of simpler regions.
+
    
+
+
    The region keyword only applies to the dump custom and cfg and
+image styles.  If specified, only atoms in the region will be
+written to the dump file or included in the image.  Only one region
+can be applied as a filter (the last one specified).  See the
+region command for more details.  Note that a region can
+be defined as the "inside" or "outside" of a geometric shape, and it
+can be the "union" or "intersection" of a series of simpler regions.
 
    
+
    
+
 
    The scale keyword applies only to the dump atom style.  A scale
 value of yes means atom coords are written in normalized units from
 0.0 to 1.0 in each box dimension.  If the simluation box is triclinic
@@ -184,6 +464,8 @@ value of yes means atom coords are written in normalized units from
 value of no means they are written in absolute distance units
 (e.g. Angstroms or sigma).
 
    
+
    
+
 
    The sort keyword determines whether lines of per-atom output in a
 snapshot are sorted or not.  A sort value of off means they will
 typically be written in indeterminate order, either in serial or
@@ -201,17 +483,23 @@ the output file correctly.
 file output requires extra overhead in terms of CPU and communication
 cost, as well as memory, versus unsorted output.
 
    
-
    The thresh keyword only applies to the dump custom and cfg
-styles.  Multiple thresholds can be specified.  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.  The possible attributes that can be tested for are the
-same as those that can be specified in the dump custom
-command.  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.
+
    
+
+
    The thresh keyword only applies to the dump custom and cfg and
+image styles.  Multiple thresholds can be specified.  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 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.
 
    
+
    
+
 
    The unwrap keyword only applies to the dump dcd and xtc styles.
 If set to yes, coordinates will be written "unwrapped" by the image
 flags for each atom.  Unwrapped means that if the atom has passed thru
@@ -220,21 +508,31 @@ the coordinate would be if it had not been wrapped back into the
 periodic box.  Note that these coordinates may thus be far outside the
 box size stored with the snapshot.
 
    
+
    
+
 
    Restrictions: none
 
    
 
    Related commands:
 
    
-
    dump, undump
+
    dump, dump image, undump
 
    
 
    Default:
 
    
 
    The option defaults are
 
    
-
    • append = no
+
      • acolor = * red/green/blue/yellow/aqua/cyan
+
      • adiam = * 1.0
+
      • amap = min max cf 2 min blue max red
+
      • append = no
+
      • bcolor = * red/green/blue/yellow/aqua/cyan
+
      • bdiam = * 0.5
+
      • backcolor = black
+
      • boxcolor = yellow
+
      • color = 140 color names are pre-defined as listed below
 
      • element = "C" for every atom type
 
      • every = whatever it was set to via the dump command
 
      • first = no
-
      • flush = yes (except for the dump xtc style)
+
      • flush = yes
 
      • format = %d and %g for each integer or floating point value
 
      • image = no
 
      • label = ENTRIES
@@ -247,4 +545,43 @@ box size stored with the snapshot.
 
      • thresh = none
 
      • unwrap = no 
 
      
+
      
+
+
      These are the 140 colors that LAMMPS pre-defines for use with the
+dump image and dump_modify commands.  Additional
+colors can be defined with the dump_modify color command.  The 3
+numbers listed for each name are the RGB (red/green/blue) values.
+Divide each value by 255 to get the equivalent 0.0 to 1.0 value.
+
      
+
      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
      aliceblue = 240, 248, 255 antiquewhite = 250, 235, 215 aqua = 0, 255, 255 aquamarine = 127, 255, 212 azure = 240, 255, 255 
      beige = 245, 245, 220 bisque = 255, 228, 196 black = 0, 0, 0 blanchedalmond = 255, 255, 205 blue = 0, 0, 255 
      blueviolet = 138, 43, 226 brown = 165, 42, 42 burlywood = 222, 184, 135 cadetblue = 95, 158, 160 chartreuse = 127, 255, 0 
      chocolate = 210, 105, 30 coral = 255, 127, 80 cornflowerblue = 100, 149, 237 cornsilk = 255, 248, 220 crimson = 220, 20, 60 
      cyan = 0, 255, 255 darkblue = 0, 0, 139 darkcyan = 0, 139, 139 darkgoldenrod = 184, 134, 11 darkgray = 169, 169, 169 
      darkgreen = 0, 100, 0 darkkhaki = 189, 183, 107 darkmagenta = 139, 0, 139 darkolivegreen = 85, 107, 47 darkorange = 255, 140, 0 
      darkorchid = 153, 50, 204 darkred = 139, 0, 0 darksalmon = 233, 150, 122 darkseagreen = 143, 188, 143 darkslateblue = 72, 61, 139 
      darkslategray = 47, 79, 79 darkturquoise = 0, 206, 209 darkviolet = 148, 0, 211 deeppink = 255, 20, 147 deepskyblue = 0, 191, 255 
      dimgray = 105, 105, 105 dodgerblue = 30, 144, 255 firebrick = 178, 34, 34 floralwhite = 255, 250, 240 forestgreen = 34, 139, 34 
      fuchsia = 255, 0, 255 gainsboro = 220, 220, 220 ghostwhite = 248, 248, 255 gold = 255, 215, 0 goldenrod = 218, 165, 32 
      gray = 128, 128, 128 green = 0, 128, 0 greenyellow = 173, 255, 47 honeydew = 240, 255, 240 hotpink = 255, 105, 180 
      indianred = 205, 92, 92 indigo = 75, 0, 130 ivory = 255, 240, 240 khaki = 240, 230, 140 lavender = 230, 230, 250 
      lavenderblush = 255, 240, 245 lawngreen = 124, 252, 0 lemonchiffon = 255, 250, 205 lightblue = 173, 216, 230 lightcoral = 240, 128, 128 
      lightcyan = 224, 255, 255 lightgoldenrodyellow = 250, 250, 210 lightgreen = 144, 238, 144 lightgrey = 211, 211, 211 lightpink = 255, 182, 193 
      lightsalmon = 255, 160, 122 lightseagreen = 32, 178, 170 lightskyblue = 135, 206, 250 lightslategray = 119, 136, 153 lightsteelblue = 176, 196, 222 
      lightyellow = 255, 255, 224 lime = 0, 255, 0 limegreen = 50, 205, 50 linen = 250, 240, 230 magenta = 255, 0, 255 
      maroon = 128, 0, 0 mediumaquamarine = 102, 205, 170 mediumblue = 0, 0, 205 mediumorchid = 186, 85, 211 mediumpurple = 147, 112, 219 
      mediumseagreen = 60, 179, 113 mediumslateblue = 123, 104, 238 mediumspringgreen = 0, 250, 154 mediumturquoise = 72, 209, 204 mediumvioletred = 199, 21, 133 
      midnightblue = 25, 25, 112 mintcream = 245, 255, 250 mistyrose = 255, 228, 225 moccasin = 255, 228, 181 navajowhite = 255, 222, 173 
      navy = 0, 0, 128 oldlace = 253, 245, 230 olive = 128, 128, 0 olivedrab = 107, 142, 35 orange = 255, 165, 0 
      orangered = 255, 69, 0 orchid = 218, 112, 214 palegoldenrod = 238, 232, 170 palegreen = 152, 251, 152 paleturquoise = 175, 238, 238 
      palevioletred = 219, 112, 147 papayawhip = 255, 239, 213 peachpuff = 255, 239, 213 peru = 205, 133, 63 pink = 255, 192, 203 
      plum = 221, 160, 221 powderblue = 176, 224, 230 purple = 128, 0, 128 red = 255, 0, 0 rosybrown = 188, 143, 143 
      royalblue = 65, 105, 225 saddlebrown = 139, 69, 19 salmon = 250, 128, 114 sandybrown = 244, 164, 96 seagreen = 46, 139, 87 
      seashell = 255, 245, 238 sienna = 160, 82, 45 silver = 192, 192, 192 skyblue = 135, 206, 235 slateblue = 106, 90, 205 
      slategray = 112, 128, 144 snow = 255, 250, 250 springgreen = 0, 255, 127 steelblue = 70, 130, 180 tan = 210, 180, 140 
      teal = 0, 128, 128 thistle = 216, 191, 216 tomato = 253, 99, 71 turquoise = 64, 224, 208 violet = 238, 130, 238 
      wheat = 245, 222, 179 white = 255, 255, 255 whitesmoke = 245, 245, 245 yellow = 255, 255, 0 yellowgreen = 154, 205, 50 
+
      
+
 
diff --git a/doc/dump_modify.txt b/doc/dump_modify.txt
index 0f2613b77f..93a87e3298 100644
--- a/doc/dump_modify.txt
+++ b/doc/dump_modify.txt
@@ -14,8 +14,47 @@ dump_modify dump-ID keyword values ... :pre
 
 dump-ID = ID of dump to modify :ulb,l
 one or more keyword/value pairs may be appended :l
-keyword = {append} or {every} or {flush} or {format} or {image} or {label} or {precision} or {region} or {scale} or {sort} or {thresh} or {unwrap} :l
+keyword = {acolor} or {adiam} or {amap} or {append} or {bcolor} or {bdiam} or {backcolor} or {boxcolor} or {color} or {every} or {flush} or {format} or {image} or {label} or {precision} or {region} or {scale} or {sort} or {thresh} or {unwrap} :l
+  {acolor} args = type color
+    type = atom type or range of types (see below)
+    color = name of color or color1/color2/...
+  {adiam} args = type diam
+    type = atom type or range of types (see below)
+    diam = diameter of atoms of that type (distance units)
+  {amap} args = lo hi style N delta entry1 entry2 ... entryN
+    lo = number or {min} = lower bound of range of color map
+    hi = number or {max} = upper bound of range of color map
+    style = 2 letters = "c" or "d" or "s" plus "a" or "f"
+      "c" for continuous
+      "d" for discrete
+      "s" for sequential
+      "a" for absolute
+      "f" for fractional
+    delta = binsize (only used for style "s", otherwise ignored)
+      binsize = range is divided into bins of this width
+    N = # of subsequent entries
+    entry = value color (for continuous style)
+      value = number or {min} or {max} = single value within range
+      color = name of color used for that value
+    entry = lo hi color (for discrete style)
+      lo/hi = number or {min} or {max} = lower/upper bound of subset of range
+      color = name of color used for that subset of values
+    entry = color (for sequential style)
+      color = name of color used for a bin of values
   {append} arg = {yes} or {no}
+  {bcolor} args = type color
+    type = bond type or range of types (see below)
+    color = name of color or color1/color2/...
+  {bdiam} args = type diam
+    type = bond type or range of types (see below)
+    diam = diameter of bonds of that type (distance units)
+  {backcolor} arg = color
+    color = name of color for background
+  {boxcolor} arg = color
+    color = name of color for box lines
+  {color} args = name R G B
+    name = name of color
+    R,G,B = red/green/blue numeric values from 0.0 to 1.0
   {element} args = E1 E2 ... EN, where N = # of atom types
     E1,...,EN = element name, e.g. C or Fe or Ga
   {every} arg = N
@@ -52,12 +91,162 @@ dump_modify 1 region mySphere thresh x < 0.0 thresh epair >= 3.2
 dump_modify xtcdump precision 10000
 dump_modify 1 every 1000
 dump_modify 1 every v_myVar :pre
+dump_modify 1 amap min max cf 0.0 3 min green 0.5 yellow max blue boxcolor red :pre
 
 [Description:]
 
 Modify the parameters of a previously defined dump command.  Not all
 parameters are relevant to all dump styles.
 
+:line
+
+The {acolor} keyword applies only to the dump {image} style.  It can
+be used with the "dump image"_dump_image.html command, when its atom
+color setting is {type}, to set the color that atoms of each type will
+be drawn in the image.
+
+The specified {type} should be an integer from 1 to Ntypes = the
+number of atom types.  A wildcard asterisk can be used in place of or
+in conjunction with the {type} argument to specify a range of atom
+types.  This takes the form "*" or "*n" or "n*" or "m*n".  If N = the
+number of atom types, then an asterisk with no numeric values means
+all types from 1 to N.  A leading asterisk means all types from 1 to n
+(inclusive).  A trailing asterisk means all types from n to N
+(inclusive).  A middle asterisk means all types from m to n
+(inclusive).
+
+The specified {color} can be a single color which is any of the 140
+pre-defined colors (see below) or a color name defined by the
+dump_modify color option.  Or it can be two or more colors separated
+by a "/" character, e.g. red/green/blue.  In the former case, that
+color is assigned to all the specified atom types.  In the latter
+case, the list of colors are assigned in a round-robin fashion to each
+of the specified atom types.
+
+:line
+
+The {adiam} keyword applies only to the dump {image} style.  It can be
+used with the "dump image"_dump_image.html command, when its atom
+diameter setting is {type}, to set the size that atoms of each type
+will be drawn in the image.  The specified {type} should be an integer
+from 1 to Ntypes.  As with the {acolor} keyword, a wildcard asterisk
+can be used as part of the {type} argument to specify a range of atomt
+types.  The specified {diam} is the size in whatever distance
+"units"_units.html the input script is using, e.g. Angstroms.
+
+:line
+
+The {amap} keyword applies only to the dump {image} style.  It can be
+used with the "dump image"_dump_image.html command, with its {atom}
+keyword, when its atom setting is an atom-attribute, to setup a color
+map.  The color map is used to assign a specific RGB (red/green/blue)
+color value to an individual atom when it is drawn, based on the
+atom's attribute, which is a numeric value, e.g. its x-component of
+velocity if the atom-attribute "vx" was specified.
+
+The basic idea of a color map is that the atom-attribute will be
+within a range of values, and that range is associated with a a series
+of colors (e.g. red, blue, green).  An atom's specific value (vx =
+-3.2) can then mapped to the series of colors (e.g. halfway between
+red and blue), and a specific color is determined via an interpolation
+procedure.
+
+There are many possible options for the color map, enabled by the
+{amap} keyword.  Here are the details.
+
+The {lo} and {hi} settings determine the range of values allowed for
+the atom attribute.  If numeric values are used for {lo} and/or {hi},
+then values that are lower/higher than that value are set to the
+value.  I.e. the range is static.  If {lo} is specified as {min} or
+{hi} as {max} then the range is dynamic, and the lower and/or
+upper bound will be calculated each time an image is drawn, based
+on the set of atoms being visualized.
+
+The {style} setting is two letters, such as "ca".  The first letter is
+either "c" for continuous, "d" for discrete, or "s" for sequential.
+The second letter is either "a" for absolute, or "f" for fractional.
+
+A continuous color map is one in which the color changes continuously
+from value to value within the range.  A discrete color map is one in
+which discrete colors are assigned to sub-ranges of values within the
+range.  A sequential color map is one in which discrete colors are
+assigned to a sequence of sub-ranges of values covering the entire
+range.
+
+An absolute color map is one in which the values to which colors are
+assigned are specified explicitly as values within the range.  A
+fractional color map is one in which the values to which colors are
+assigned are specified as a fractional portion of the range.  For
+example if the range is from -10.0 to 10.0, and the color red is to be
+assigned to atoms with a value of 5.0, then for an absolute color map
+the number 5.0 would be used.  But for a fractional map, the number
+0.75 would be used since 5.0 is 3/4 of the way from -10.0 to 10.0.
+
+The {delta} setting is only specified if the style is sequential.  It
+specifies the bin size to use within the range for assigning
+consecutive colors to.  For example, if the range is from -10.0 to
+10.0 and a {delta} of 1.0 is used, then 20 colors will be assigned to
+the range.  The first will be from -10.0 <= color1 < -9.0, then 2nd
+from -9.0 <= color2 < -8.0, etc.
+
+The {N} setting is how many entries follow.  The format of the entries
+depends on whether the color map style is continuous, discrete or
+sequential.  In all cases the {color} setting can be any of the 140
+pre-defined colors (see below) or a color name defined by the
+dump_modify color option.
+
+For continuous color maps, each entry has a {value} and a {color}.
+The {value} is either a number within the range of values or {min} or
+{max}.  The {value} of the first entry must be {min} and the {value}
+of the last entry must be {max}.  Any entries in between must have
+increasing values.  Note that numeric values can be specified either
+as absolute numbers or as fractions (0.0 to 1.0) of the range,
+depending on the "a" or "f" in the style setting for the color map.
+
+Here is how the entries are used to determine the color of an
+individual atom, given the value X of its atom attribute.  X will fall
+between 2 of the entry values.  The color of the atom is linearly
+interpolated (in each of the RGB values) between the 2 colors
+associated with those entries.  For example, if X = -5.0 and the 2
+surrounding entries are "red" at -10.0 and "blue" at 0.0, then the
+atom's color will be halfway between "red" and "blue", which happens
+to be "purple".
+
+For discrete color maps, each entry has a {lo} and {hi} value and a
+{color}.  The {lo} and {hi} settings are either numbers within the
+range of values or {lo} can be {min} or {hi} can be {max}.  The {lo}
+and {hi} settings of the last entry must be {min} and {max}.  Other
+entries can have any {lo} and {hi} values and the sub-ranges of
+different values can overlap.  Note that numeric {lo} and {hi} values
+can be specified either as absolute numbers or as fractions (0.0 to
+1.0) of the range, depending on the "a" or "f" in the style setting
+for the color map.
+
+Here is how the entries are used to determine the color of an
+individual atom, given the value X of its atom attribute.  The entries
+are scanned from first to last.  The first time that {lo} <= X <=
+{hi}, X is assigned the color associated with that entry.  You can
+think of the last entry as assigning a default color (since it will
+always be matched by X), and the earlier entries as colors that
+override the default.  Also note that no interpolation of a color RGB
+is done.  All atoms will be drawn with one of the colors in the list
+of entries.
+
+For sequential color maps, each entry has only a {color}.  Here is how
+the entries are used to determine the color of an individual atom,
+given the value X of its atom attribute.  The range is partitioned
+into N bins of width {binsize}.  Thus X will fall in a specific bin
+from 1 to N, say the Mth bin.  If it falls on a boundary between 2
+bins, it is considered to be in the higher of the 2 bins.  Each bin is
+assigned a color from the E entries.  If E < N, then the colors are
+repeated.  For example if 2 entries with colors red and green are
+specified, then the odd numbered bins will be red and the even bins
+green.  The color of the atom is the color of its bin.  Note that the
+sequential color map is really a shorthand way of defining a discrete
+color map without having to specify where all the bin boundaries are.
+
+:line
+
 The {append} keyword applies to all dump styles except {cfg} and {xtc}
 and {dcd}.  It also applies only to text output files, not to binary
 or gzipped files.  If specified as {yes}, then dump snapshots are
@@ -69,13 +258,87 @@ before the first command that causes dump snapshots to be output,
 e.g. a "run"_run.html or "minimize"_minimize.html command.  Once the
 dump file has been opened, this keyword has no further effect.
 
-The {element} keyword applies only to the the dump {cfg} style.  It
-associates element names (e.g. H, C, Fe) with LAMMPS atom types, so
-that the "AtomEye"_http://mt.seas.upenn.edu/Archive/Graphics/A
-visualization package can render atoms with the appropriate size and
-color.  An element name is specified for each atom type (1 to Ntype)
-in the simulation.  The same element name can be given to multiple
-atom types.
+:line
+
+The {bcolor} keyword applies only to the dump {image} style.  It can
+be used with the "dump image"_dump_image.html command, with its {bond}
+keyword, when its color setting is {type}, to set the color that bonds
+of each type will be drawn in the image.
+
+The specified {type} should be an integer from 1 to Nbondtypes = the
+number of bond types.  A wildcard asterisk can be used in place of or
+in conjunction with the {type} argument to specify a range of bond
+types.  This takes the form "*" or "*n" or "n*" or "m*n".  If N = the
+number of bond types, then an asterisk with no numeric values means
+all types from 1 to N.  A leading asterisk means all types from 1 to n
+(inclusive).  A trailing asterisk means all types from n to N
+(inclusive).  A middle asterisk means all types from m to n
+(inclusive).
+
+The specified {color} can be a single color which is any of the 140
+pre-defined colors (see below) or a color name defined by the
+dump_modify color option.  Or it can be two or more colors separated
+by a "/" character, e.g. red/green/blue.  In the former case, that
+color is assigned to all the specified bond types.  In the latter
+case, the list of colors are assigned in a round-robin fashion to each
+of the specified bond types.
+
+:line
+
+The {bdiam} keyword applies only to the dump {image} style.  It can be
+used with the "dump image"_dump_image.html command, with its {bond}
+keyword, when its diam setting is {type}, to set the diameter that
+bonds of each type will be drawn in the image.  The specified {type}
+should be an integer from 1 to Nbondtypes.  As with the {bcolor}
+keyword, a wildcard asterisk can be used as part of the {type}
+argument to specify a range of bond types.  The specified {diam} is
+the size in whatever distance "units"_units.html you are using,
+e.g. Angstroms.
+
+:line
+
+The {backcolor} keyword applies only to the dump {image} style.  It
+sets the background color of the images.  The color name can be any of
+the 140 pre-defined colors (see below) or a color name defined by the
+dump_modify color option.
+
+:line
+
+The {boxcolor} keyword applies only to the dump {image} style.  It
+sets the color of the simulation box drawn around the atoms in each
+image.  See the "dump image box" command for how to specify that a box
+be drawn.  The color name can be any of the 140 pre-defined colors
+(see below) or a color name defined by the dump_modify color option.
+
+:line
+
+The {color} keyword applies only to the dump {image} style.  It allows
+definition of a new color name, in addition to the 140-predefined
+colors (see below), and associates 3 red/green/blue RGB values with
+that color name.  The color name can then be used with any other
+dump_modify keyword that takes a color name as a value.  The RGB
+values should each be floating point values between 0.0 and 1.0
+inclusive.
+
+When a color name is converted to RGB values, the user-defined color
+names are searched first, then the 140 pre-defined color names.  This
+means you can also use the {color} keyword to overwrite one of the
+pre-defined color names with new RBG values.
+
+:line
+
+The {element} keyword applies only to the the dump {cfg} and {image}
+styles.  It associates element names (e.g. H, C, Fe) with LAMMPS atom
+types.  In the case of dump {cfg}, it allows the "AtomEye"_atomeye
+visualization package to read the dump file and render atoms with the
+appropriate size and color.  In the case of dump {image}, the output
+images will follow the same "AtomEye"_atomeye convention.  An element
+name is specified for each atom type (1 to Ntype) in the simulation.
+The same element name can be given to multiple atom types.
+
+:link(atomeye,http://mt.seas.upenn.edu/Archive/Graphics/A)
+
+:line
 
 The {every} keyword changes the dump frequency originally specified by
 the "dump"_dump.html command to a new value.  The every keyword can be
@@ -102,6 +365,8 @@ variable	s equal logfreq(10,3,10)
 dump		1 all atom 100 tmp.dump
 dump_modify	1 every v_s first yes :pre
 
+:line
+
 The {first} keyword determines whether a dump snapshot is written on
 the very first timestep after the dump command is invoked.  This will
 always occur if the current timestep is a multiple of N, the frequency
@@ -110,6 +375,8 @@ if this is not the case, a dump snapshot will only be written if the
 setting of this keyword is {yes}.  If it is {no}, which is the
 default, then it will not be written.
 
+:line
+
 The {flush} keyword determines whether a flush operation is invoked
 after a dump snapshot is written to the dump file.  A flush insures
 the output in that file is current (no buffering by the OS), even if
@@ -126,6 +393,8 @@ the first two fields (atom id and type) are not actually written into
 the CFG file, though you must include formats for them in the format
 string.
 
+:line
+
 The {image} keyword applies only to the dump {atom} style.  If the
 image value is {yes}, 3 flags are appended to each atom's coords which
 are the absolute box image of the atom in each dimension.  For
@@ -136,6 +405,8 @@ current coordinate.  Note that for dump style {custom} these various
 values can be printed in the dump file by using the appropriate atom
 attributes in the dump command itself.
 
+:line
+
 The {label} keyword applies only to the dump {local} style.  When
 it writes local informatoin, such as bond or angle topology
 to a dump file, it will use the specified {label} to format
@@ -147,6 +418,8 @@ ITEM: ENTRIES ... :pre
 The word "ENTRIES" will be replaced with the string specified,
 e.g. BONDS or ANGLES.
 
+:line
+
 The {pad} keyword only applies when the dump filename is specified
 with a wildcard "*" character which becomes the timestep.  If {pad} is
 0, which is the default, the timestep is converted into a string of
@@ -157,18 +430,24 @@ yield 0000100, 0012000, 2000000.  This can be useful so that
 post-processing programs can easily read the files in ascending
 timestep order.
 
+:line
+
 The {precision} keyword only applies to the dump {xtc} style.  A
 specified value of N means that coordinates are stored to 1/N
 nanometer accuracy, e.g. for N = 1000, the coordinates are written to
 1/1000 nanometer accuracy.
 
-The {region} keyword only applies to the dump {custom} and {cfg}
-styles.  If specified, only atoms in the region will be written to the
-dump file.  Only one region can be applied as a filter (the last one
-specified).  See the "region"_region.html command for more details.
-Note that a region can be defined as the "inside" or "outside" of a
-geometric shape, and it can be the "union" or "intersection" of a
-series of simpler regions.
+:line
+
+The {region} keyword only applies to the dump {custom} and {cfg} and
+{image} styles.  If specified, only atoms in the region will be
+written to the dump file or included in the image.  Only one region
+can be applied as a filter (the last one specified).  See the
+"region"_region.html command for more details.  Note that a region can
+be defined as the "inside" or "outside" of a geometric shape, and it
+can be the "union" or "intersection" of a series of simpler regions.
+
+:line
 
 The {scale} keyword applies only to the dump {atom} style.  A scale
 value of {yes} means atom coords are written in normalized units from
@@ -177,6 +456,8 @@ value of {yes} means atom coords are written in normalized units from
 value of {no} means they are written in absolute distance units
 (e.g. Angstroms or sigma).
 
+:line
+
 The {sort} keyword determines whether lines of per-atom output in a
 snapshot are sorted or not.  A sort value of {off} means they will
 typically be written in indeterminate order, either in serial or
@@ -194,16 +475,22 @@ IMPORTANT NOTE: Unless it is required by the dump style, sorting dump
 file output requires extra overhead in terms of CPU and communication
 cost, as well as memory, versus unsorted output.
 
-The {thresh} keyword only applies to the dump {custom} and {cfg}
-styles.  Multiple thresholds can be specified.  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.  The possible attributes that can be tested for are the
-same as those that can be specified in the "dump custom"_dump.html
-command.  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.
+:line
+
+The {thresh} keyword only applies to the dump {custom} and {cfg} and
+{image} styles.  Multiple thresholds can be specified.  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.
+
+:line
 
 The {unwrap} keyword only applies to the dump {dcd} and {xtc} styles.
 If set to {yes}, coordinates will be written "unwrapped" by the image
@@ -213,21 +500,31 @@ the coordinate would be if it had not been wrapped back into the
 periodic box.  Note that these coordinates may thus be far outside the
 box size stored with the snapshot.
 
+:line
+
 [Restrictions:] none
 
 [Related commands:]
 
-"dump"_dump.html, "undump"_undump.html
+"dump"_dump.html, "dump image"_dump_image.html, "undump"_undump.html
 
 [Default:]
 
 The option defaults are
 
+acolor = * red/green/blue/yellow/aqua/cyan
+adiam = * 1.0
+amap = min max cf 2 min blue max red
 append = no
+bcolor = * red/green/blue/yellow/aqua/cyan
+bdiam = * 0.5
+backcolor = black
+boxcolor = yellow
+color = 140 color names are pre-defined as listed below
 element = "C" for every atom type
 every = whatever it was set to via the "dump"_dump.html command
 first = no
-flush = yes (except for the dump {xtc} style)
+flush = yes
 format = %d and %g for each integer or floating point value
 image = no
 label = ENTRIES
@@ -239,3 +536,152 @@ sort = off for dump styles {atom}, {custom}, {cfg}, and {local}
 sort = id for dump styles {dcd}, {xtc}, and {xyz}
 thresh = none
 unwrap = no :ul
+
+:line
+
+These are the 140 colors that LAMMPS pre-defines for use with the
+"dump image"_dump_image.html and dump_modify commands.  Additional
+colors can be defined with the dump_modify color command.  The 3
+numbers listed for each name are the RGB (red/green/blue) values.
+Divide each value by 255 to get the equivalent 0.0 to 1.0 value.
+
+aliceblue = 240, 248, 255 |
+antiquewhite = 250, 235, 215 |
+aqua = 0, 255, 255 |
+aquamarine = 127, 255, 212 |
+azure = 240, 255, 255 |
+beige = 245, 245, 220 |
+bisque = 255, 228, 196 |
+black = 0, 0, 0 |
+blanchedalmond = 255, 255, 205 |
+blue = 0, 0, 255 |
+blueviolet = 138, 43, 226 |
+brown = 165, 42, 42 |
+burlywood = 222, 184, 135 |
+cadetblue = 95, 158, 160 |
+chartreuse = 127, 255, 0 |
+chocolate = 210, 105, 30 |
+coral = 255, 127, 80 |
+cornflowerblue = 100, 149, 237 |
+cornsilk = 255, 248, 220 |
+crimson = 220, 20, 60 |
+cyan = 0, 255, 255 |
+darkblue = 0, 0, 139 |
+darkcyan = 0, 139, 139 |
+darkgoldenrod = 184, 134, 11 |
+darkgray = 169, 169, 169 |
+darkgreen = 0, 100, 0 |
+darkkhaki = 189, 183, 107 |
+darkmagenta = 139, 0, 139 |
+darkolivegreen = 85, 107, 47 |
+darkorange = 255, 140, 0 |
+darkorchid = 153, 50, 204 |
+darkred = 139, 0, 0 |
+darksalmon = 233, 150, 122 |
+darkseagreen = 143, 188, 143 |
+darkslateblue = 72, 61, 139 |
+darkslategray = 47, 79, 79 |
+darkturquoise = 0, 206, 209 |
+darkviolet = 148, 0, 211 |
+deeppink = 255, 20, 147 |
+deepskyblue = 0, 191, 255 |
+dimgray = 105, 105, 105 |
+dodgerblue = 30, 144, 255 |
+firebrick = 178, 34, 34 |
+floralwhite = 255, 250, 240 |
+forestgreen = 34, 139, 34 |
+fuchsia = 255, 0, 255 |
+gainsboro = 220, 220, 220 |
+ghostwhite = 248, 248, 255 |
+gold = 255, 215, 0 |
+goldenrod = 218, 165, 32 |
+gray = 128, 128, 128 |
+green = 0, 128, 0 |
+greenyellow = 173, 255, 47 |
+honeydew = 240, 255, 240 |
+hotpink = 255, 105, 180 |
+indianred = 205, 92, 92 |
+indigo = 75, 0, 130 |
+ivory = 255, 240, 240 |
+khaki = 240, 230, 140 |
+lavender = 230, 230, 250 |
+lavenderblush = 255, 240, 245 |
+lawngreen = 124, 252, 0 |
+lemonchiffon = 255, 250, 205 |
+lightblue = 173, 216, 230 |
+lightcoral = 240, 128, 128 |
+lightcyan = 224, 255, 255 |
+lightgoldenrodyellow = 250, 250, 210 |
+lightgreen = 144, 238, 144 |
+lightgrey = 211, 211, 211 |
+lightpink = 255, 182, 193 |
+lightsalmon = 255, 160, 122 |
+lightseagreen = 32, 178, 170 |
+lightskyblue = 135, 206, 250 |
+lightslategray = 119, 136, 153 |
+lightsteelblue = 176, 196, 222 |
+lightyellow = 255, 255, 224 |
+lime = 0, 255, 0 |
+limegreen = 50, 205, 50 |
+linen = 250, 240, 230 |
+magenta = 255, 0, 255 |
+maroon = 128, 0, 0 |
+mediumaquamarine = 102, 205, 170 |
+mediumblue = 0, 0, 205 |
+mediumorchid = 186, 85, 211 |
+mediumpurple = 147, 112, 219 |
+mediumseagreen = 60, 179, 113 |
+mediumslateblue = 123, 104, 238 |
+mediumspringgreen = 0, 250, 154 |
+mediumturquoise = 72, 209, 204 |
+mediumvioletred = 199, 21, 133 |
+midnightblue = 25, 25, 112 |
+mintcream = 245, 255, 250 |
+mistyrose = 255, 228, 225 |
+moccasin = 255, 228, 181 |
+navajowhite = 255, 222, 173 |
+navy = 0, 0, 128 |
+oldlace = 253, 245, 230 |
+olive = 128, 128, 0 |
+olivedrab = 107, 142, 35 |
+orange = 255, 165, 0 |
+orangered = 255, 69, 0 |
+orchid = 218, 112, 214 |
+palegoldenrod = 238, 232, 170 |
+palegreen = 152, 251, 152 |
+paleturquoise = 175, 238, 238 |
+palevioletred = 219, 112, 147 |
+papayawhip = 255, 239, 213 |
+peachpuff = 255, 239, 213 |
+peru = 205, 133, 63 |
+pink = 255, 192, 203 |
+plum = 221, 160, 221 |
+powderblue = 176, 224, 230 |
+purple = 128, 0, 128 |
+red = 255, 0, 0 |
+rosybrown = 188, 143, 143 |
+royalblue = 65, 105, 225 |
+saddlebrown = 139, 69, 19 |
+salmon = 250, 128, 114 |
+sandybrown = 244, 164, 96 |
+seagreen = 46, 139, 87 |
+seashell = 255, 245, 238 |
+sienna = 160, 82, 45 |
+silver = 192, 192, 192 |
+skyblue = 135, 206, 235 |
+slateblue = 106, 90, 205 |
+slategray = 112, 128, 144 |
+snow = 255, 250, 250 |
+springgreen = 0, 255, 127 |
+steelblue = 70, 130, 180 |
+tan = 210, 180, 140 |
+teal = 0, 128, 128 |
+thistle = 216, 191, 216 |
+tomato = 253, 99, 71 |
+turquoise = 64, 224, 208 |
+violet = 238, 130, 238 |
+wheat = 245, 222, 179 |
+white = 255, 255, 255 |
+whitesmoke = 245, 245, 245 |
+yellow = 255, 255, 0 |
+yellowgreen = 154, 205, 50 :tb(c=5,s=|)
diff --git a/doc/echo.html b/doc/echo.html
index fa79009676..46068aa832 100644
--- a/doc/echo.html
+++ b/doc/echo.html
@@ -29,8 +29,8 @@ command to the screen and/or log file as it is read and processed.  If
 an input script has errors, it can be useful to look at echoed output
 to see the last command processed.
 
      
-
      The command-line switch -echo can be used in
-place of this command.
+
      The command-line switch -echo can be used
+in place of this command.
 
      
 
      Restrictions: none
 
      
diff --git a/doc/echo.txt b/doc/echo.txt
index 17fca167e0..eeac802ae0 100644
--- a/doc/echo.txt
+++ b/doc/echo.txt
@@ -26,8 +26,8 @@ command to the screen and/or log file as it is read and processed.  If
 an input script has errors, it can be useful to look at echoed output
 to see the last command processed.
 
-The "command-line switch"_Section_start.html#2_4 -echo can be used in
-place of this command.
+The "command-line switch"_Section_start.html#start_4 -echo can be used
+in place of this command.
 
 [Restrictions:] none
 
diff --git a/doc/fix.html b/doc/fix.html
index 9327030430..b2cac319d7 100644
--- a/doc/fix.html
+++ b/doc/fix.html
@@ -138,7 +138,7 @@ variable.
 reduce command, or histogrammed by the fix
 ave/histo command. 
 
    
-
    See this howto section for a summary of
+
    See this howto section for a summary of
 various LAMMPS output options, many of which involve fixes.
 
    
 
    The results of fixes that calculate global quantities can be either
@@ -164,7 +164,7 @@ list of fix styles available in LAMMPS:
 
  • addforce - add a force to each atom
 
  • aveforce - add an averaged force to each atom
 
  • ave/atom - compute per-atom time-averaged quantities
-
  • ave/histo - compute/output time-averaged histograms
+
  • ave/histo - compute/output time-averaged histograms
 
  • ave/spatial - compute/output time-averaged per-atom quantities by layer
 
  • ave/time - compute/output global time-averaged quantities
 
  • bond/break - break bonds on the fly
@@ -181,6 +181,7 @@ list of fix styles available in LAMMPS:
 
  • external - callback to an external driver program
 
  • freeze - freeze atoms in a granular simulation
 
  • gravity - add gravity to atoms in a granular simulation
+
  • gcmc - grand canonical insertions/deletions
 
  • heat - add/subtract momentum-conserving heat
 
  • indent - impose force due to an indenter
 
  • langevin - Langevin temperature control
@@ -192,14 +193,18 @@ list of fix styles available in LAMMPS:
 
  • nph - constant NPH time integration via Nose/Hoover
 
  • nph/asphere - NPH for aspherical particles
 
  • nph/sphere - NPH for spherical particles
+
  • nphug - constant-stress Hugoniostat integration
 
  • npt - constant NPT time integration via Nose/Hoover
 
  • npt/asphere - NPT for aspherical particles
 
  • npt/sphere - NPT for spherical particles
 
  • nve - constant NVE time integration
-
  • nve/asphere - NVT for aspherical particles
-
  • nve/limit - NVE with limited step length
+
  • nve/asphere - NVE for aspherical particles
+
  • nve/asphere/noforce - NVE for aspherical particles without forces
+
  • nve/limit - NVE with limited step length
+
  • nve/line - NVE for line segments
 
  • nve/noforce - NVE without forces (v only)
-
  • nve/sphere - NVT for spherical particles
+
  • nve/sphere - NVE for spherical particles
+
  • nve/tri - NVE for triangles
 
  • nvt - constant NVT time integration via Nose/Hoover
 
  • nvt/asphere - NVT for aspherical particles
 
  • nvt/sllod - NVT for NEMD with SLLOD equations
@@ -211,6 +216,7 @@ list of fix styles available in LAMMPS:
 
  • press/berendsen - pressure control by      Berendsen barostat
 
  • print - print text and variables during a simulation
 
  • reax/bonds - write out ReaxFF bond information recenter - constrain the center-of-mass position   of a group of atoms
+
  • restrain - constrain a bond, angle, dihedral
 
  • rigid - constrain one or more clusters of atoms to      move as a rigid body with NVE integration
 
  • rigid/nve - constrain one or more clusters of atoms to      move as a rigid body with alternate NVE integration
 
  • rigid/nvt - constrain one or more clusters of atoms to      move as a rigid body with NVT integration
@@ -240,15 +246,20 @@ list of fix styles available in LAMMPS:
 
 
    There are also additional fix styles submitted by users which are
 included in the LAMMPS distribution.  The list of these with links to
-the individual styles are given in the fix section of this
+the individual styles are given in the fix section of this
 page.
 
    
+
    There are also additional accelerated fix styles included in the
+LAMMPS distribution for faster performance on CPUs and GPUs.  The list
+of these with links to the individual styles are given in the pair
+section of this page.
+
    
 
    Restrictions:
 
    
 
    Some fix styles are part of specific packages.  They are only enabled
-if LAMMPS was built with that package.  See the Making
-LAMMPS section for more info on packages.  The
-doc pages for individual fixes tell if it is part of a package.
+if LAMMPS was built with that package.  See the Making
+LAMMPS section for more info on packages.
+The doc pages for individual fixes tell if it is part of a package.
 
    
 
    Related commands:
 
    
diff --git a/doc/fix.txt b/doc/fix.txt
index 38fd1ff167..4c0df45d11 100644
--- a/doc/fix.txt
+++ b/doc/fix.txt
@@ -133,7 +133,7 @@ Local values can be reduced by the "compute
 reduce"_compute_reduce.html command, or histogrammed by the "fix
 ave/histo"_fix_ave_histo.html command. :l,ule
 
-See this "howto section"_Section_howto.html#4_15 for a summary of
+See this "howto section"_Section_howto.html#howto_15 for a summary of
 various LAMMPS output options, many of which involve fixes.
 
 The results of fixes that calculate global quantities can be either
@@ -159,7 +159,7 @@ list of fix styles available in LAMMPS:
 "addforce"_fix_addforce.html - add a force to each atom
 "aveforce"_fix_aveforce.html - add an averaged force to each atom
 "ave/atom"_fix_ave_atom.html - compute per-atom time-averaged quantities
-"ave/histo"_fix_ave_atom.html - compute/output time-averaged histograms
+"ave/histo"_fix_ave_histo.html - compute/output time-averaged histograms
 "ave/spatial"_fix_ave_spatial.html - compute/output time-averaged per-atom quantities by layer
 "ave/time"_fix_ave_time.html - compute/output global time-averaged quantities
 "bond/break"_fix_bond_break.html - break bonds on the fly
@@ -176,6 +176,7 @@ list of fix styles available in LAMMPS:
 "external"_fix_external.html - callback to an external driver program
 "freeze"_fix_freeze.html - freeze atoms in a granular simulation
 "gravity"_fix_gravity.html - add gravity to atoms in a granular simulation
+"gcmc"_fix_gcmc.html - grand canonical insertions/deletions
 "heat"_fix_heat.html - add/subtract momentum-conserving heat
 "indent"_fix_indent.html - impose force due to an indenter
 "langevin"_fix_langevin.html - Langevin temperature control
@@ -187,14 +188,18 @@ list of fix styles available in LAMMPS:
 "nph"_fix_nh.html - constant NPH time integration via Nose/Hoover
 "nph/asphere"_fix_nph_asphere.html - NPH for aspherical particles
 "nph/sphere"_fix_nph_sphere.html - NPH for spherical particles
+"nphug"_fix_nphug.html - constant-stress Hugoniostat integration
 "npt"_fix_nh.html - constant NPT time integration via Nose/Hoover
 "npt/asphere"_fix_npt_asphere.html - NPT for aspherical particles
 "npt/sphere"_fix_npt_sphere.html - NPT for spherical particles
 "nve"_fix_nve.html - constant NVE time integration
-"nve/asphere"_fix_nve_asphere.html - NVT for aspherical particles
-"nve/limit"_fix_nve_limit.html - NVE with limited step length
+"nve/asphere"_fix_nve_asphere.html - NVE for aspherical particles
+"nve/asphere/noforce"_fix_nve_asphere_noforce.html - NVE for aspherical particles without forces"
+nve/limit"_fix_nve_limit.html - NVE with limited step length
+"nve/line"_fix_nve_line.html - NVE for line segments
 "nve/noforce"_fix_nve_noforce.html - NVE without forces (v only)
-"nve/sphere"_fix_nve_sphere.html - NVT for spherical particles
+"nve/sphere"_fix_nve_sphere.html - NVE for spherical particles
+"nve/tri"_fix_nve_tri.html - NVE for triangles
 "nvt"_fix_nh.html - constant NVT time integration via Nose/Hoover
 "nvt/asphere"_fix_nvt_asphere.html - NVT for aspherical particles
 "nvt/sllod"_fix_nvt_sllod.html - NVT for NEMD with SLLOD equations
@@ -210,6 +215,7 @@ list of fix styles available in LAMMPS:
 "reax/bonds"_fix_reax_bonds.html - write out ReaxFF bond information \
 "recenter"_fix_recenter.html - constrain the center-of-mass position \
   of a group of atoms
+"restrain"_fix_restrain.html - constrain a bond, angle, dihedral
 "rigid"_fix_rigid.html - constrain one or more clusters of atoms to \
      move as a rigid body with NVE integration
 "rigid/nve"_fix_rigid.html - constrain one or more clusters of atoms to \
@@ -248,14 +254,19 @@ list of fix styles available in LAMMPS:
 There are also additional fix styles submitted by users which are
 included in the LAMMPS distribution.  The list of these with links to
 the individual styles are given in the fix section of "this
-page"_Section_commands.html#3_5.
+page"_Section_commands.html#cmd_5.
+
+There are also additional accelerated fix styles included in the
+LAMMPS distribution for faster performance on CPUs and GPUs.  The list
+of these with links to the individual styles are given in the pair
+section of "this page"_Section_commands.html#cmd_5.
 
 [Restrictions:]
 
 Some fix styles are part of specific packages.  They are only enabled
 if LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info on packages.  The
-doc pages for individual fixes tell if it is part of a package.
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
+The doc pages for individual fixes tell if it is part of a package.
 
 [Related commands:]
 
diff --git a/doc/fix_adapt.html b/doc/fix_adapt.html
index 837f898199..3d6c1a3430 100644
--- a/doc/fix_adapt.html
+++ b/doc/fix_adapt.html
@@ -54,7 +54,7 @@
 
    
 
    fix 1 all adapt 1 pair soft a 1 1 v_prefactor
 fix 1 all adapt 1 pair soft a 2* 3 v_prefactor
-fix 1 all adapt 1 pair lj/cut epsilon * * v_scale1 coul/cut pre 3 3 v_scale2 scale yes reset yes
+fix 1 all adapt 1 pair lj/cut epsilon * * v_scale1 coul/cut scale 3 3 v_scale2 scale yes reset yes
 fix 1 all adapt 10 atom diameter v_size 
 
    
 
    Description:
@@ -111,8 +111,16 @@ can be varied by this fix.  See the doc pages for individual pair
 styles and their energy formulas for the meaning of these parameters:
 
    
 
    
-
-
+
+
+
+
+
+
+
+
+
    born: abc: type pairs:buck: a
    c: type pairs:coul/cut: scale: type pairs:coul/debye: scale: type pairs:coul/long: scale: type pairs:lj/cut: epsilon: type pairs:lj/cut/opt: epsilon: type pairs:lubricate: mu: global:gauss: a: type pairs:soft: a: type pairs 
+
    born a,b,c type pairs
    buck a,c type pairs
    coul/cut scale type pairs
    coul/debye scale type pairs
    coul/long scale type pairs
    lj/cut epsilon type pairs
    lj/cut/opt epsilon type pairs
    lubricate mu global
    gauss a type pairs
    soft a type pairs 
 
    
 
 
    IMPORTANT NOTE: It is easy to add new potentials and their parameters
@@ -225,9 +233,9 @@ fix 1 center adapt 10 atom diameter v_size
 
    No information about this fix is written to binary restart
 files.  None of the fix_modify options
 are relevant to this fix.  No global or per-atom quantities are stored
-by this fix for access by various output
-commands.  No parameter of this fix can be
-used with the start/stop keywords of the run command.
+by this fix for access by various output
+commands.  No parameter of this fix can
+be used with the start/stop keywords of the run command.
 This fix is not invoked during energy minimization.
 
    
 
    Restrictions: none
diff --git a/doc/fix_adapt.txt b/doc/fix_adapt.txt
index f281c2cf01..04e383f2cf 100644
--- a/doc/fix_adapt.txt
+++ b/doc/fix_adapt.txt
@@ -41,7 +41,7 @@ keyword = {scale} or {reset} :l
 
 fix 1 all adapt 1 pair soft a 1 1 v_prefactor
 fix 1 all adapt 1 pair soft a 2* 3 v_prefactor
-fix 1 all adapt 1 pair lj/cut epsilon * * v_scale1 coul/cut pre 3 3 v_scale2 scale yes reset yes
+fix 1 all adapt 1 pair lj/cut epsilon * * v_scale1 coul/cut scale 3 3 v_scale2 scale yes reset yes
 fix 1 all adapt 10 atom diameter v_size :pre
 
 [Description:]
@@ -106,7 +106,7 @@ styles and their energy formulas for the meaning of these parameters:
 "lj/cut/opt"_pair_lj.html: epsilon: type pairs:
 "lubricate"_pair_lubricate.html: mu: global:
 "gauss"_pair_gauss.html: a: type pairs:
-"soft"_pair_soft.html: a: type pairs :tb(c=3)
+"soft"_pair_soft.html: a: type pairs :tb(c=3,s=:)
 
 IMPORTANT NOTE: It is easy to add new potentials and their parameters
 to this list.  All it typically takes is adding an extract() method to
@@ -219,8 +219,8 @@ No information about this fix is written to "binary restart
 files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.  No global or per-atom quantities are stored
 by this fix for access by various "output
-commands"_Section_howto.html#4_15.  No parameter of this fix can be
-used with the {start/stop} keywords of the "run"_run.html command.
+commands"_Section_howto.html#howto_15.  No parameter of this fix can
+be used with the {start/stop} keywords of the "run"_run.html command.
 This fix is not invoked during "energy minimization"_minimize.html.
 
 [Restrictions:] none
diff --git a/doc/fix_addforce.html b/doc/fix_addforce.html
index ad75e1facb..05b679d66b 100644
--- a/doc/fix_addforce.html
+++ b/doc/fix_addforce.html
@@ -11,6 +11,8 @@
 
 
    fix addforce command 
 
    
+
    fix addforce/cuda command 
+
    
 
    Syntax:
 
    
 
    fix ID group-ID addforce fx fy fz keyword value ... 
@@ -21,8 +23,8 @@
 
 
  • fx,fy,fz = force component values (force units) 
 
-
  • any of fx,fy,fz can be a variable (see below) 
-
+
      any of fx,fy,fz can be a variable (see below) 
+
    
 
  • zero or more keyword/value pairs may be appended to args 
 
 
  • keyword = region or energy 
@@ -105,6 +107,29 @@ were a spring-like F = kx, then the energy formula should be E =
 -0.5kx^2.  If you don't do this correctly, the minimization will not
 converge properly.
 
    
+
    
+
+
    Styles with a cuda 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
+this section of the manual.  The accelerated
+styles take the same arguments and should produce the same results,
+except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA package.  They are
+only enabled if LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
 
    Restart, fix_modify, output, run start/stop, minimize info:
 
    
 
    No information about this fix is written to binary restart
@@ -120,11 +145,11 @@ decrease in potential energy when atoms move in the direction of the
 added force.
 
    
 
    This fix computes a global scalar and a global 3-vector of forces,
-which can be accessed by various output
-commands.  The scalar is the potential energy
-discussed above.  The vector is the total force on the group of atoms
-before the forces on individual atoms are changed by the fix.  The
-scalar and vector values calculated by this fix are "extensive".
+which can be accessed by various output
+commands.  The scalar is the potential
+energy discussed above.  The vector is the total force on the group of
+atoms before the forces on individual atoms are changed by the fix.
+The scalar and vector values calculated by this fix are "extensive".
 
    
 
    No parameter of this fix can be used with the start/stop keywords of
 the run command.
diff --git a/doc/fix_addforce.txt b/doc/fix_addforce.txt
index ca8bb88269..b20a696071 100644
--- a/doc/fix_addforce.txt
+++ b/doc/fix_addforce.txt
@@ -7,6 +7,7 @@
 :line
 
 fix addforce command :h3
+fix addforce/cuda command :h3
 
 [Syntax:]
 
@@ -15,7 +16,7 @@ fix ID group-ID addforce fx fy fz keyword value ... :pre
 ID, group-ID are documented in "fix"_fix.html command :ulb,l
 addforce = style name of this fix command :l
 fx,fy,fz = force component values (force units) :l
-any of fx,fy,fz can be a variable (see below) :l
+  any of fx,fy,fz can be a variable (see below) :pre
 zero or more keyword/value pairs may be appended to args :l
 keyword = {region} or {energy} :l
   {region} value = region-ID
@@ -95,6 +96,29 @@ were a spring-like F = kx, then the energy formula should be E =
 -0.5kx^2.  If you don't do this correctly, the minimization will not
 converge properly.
 
+:line
+
+Styles with a {cuda} 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
+"this section"_Section_accelerate.html of the manual.  The accelerated
+styles take the same arguments and should produce the same results,
+except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA package.  They are
+only enabled if LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restart, fix_modify, output, run start/stop, minimize info:]
 
 No information about this fix is written to "binary restart
@@ -111,10 +135,10 @@ added force.
 
 This fix computes a global scalar and a global 3-vector of forces,
 which can be accessed by various "output
-commands"_Section_howto.html#4_15.  The scalar is the potential energy
-discussed above.  The vector is the total force on the group of atoms
-before the forces on individual atoms are changed by the fix.  The
-scalar and vector values calculated by this fix are "extensive".
+commands"_Section_howto.html#howto_15.  The scalar is the potential
+energy discussed above.  The vector is the total force on the group of
+atoms before the forces on individual atoms are changed by the fix.
+The scalar and vector values calculated by this fix are "extensive".
 
 No parameter of this fix can be used with the {start/stop} keywords of
 the "run"_run.html command.
diff --git a/doc/fix_addtorque.html b/doc/fix_addtorque.html
new file mode 100644
index 0000000000..a9a521e3b7
--- /dev/null
+++ b/doc/fix_addtorque.html
@@ -0,0 +1,102 @@
+
+
    LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
    
+
+
+
+
+
+
+
    
+
+
    fix addtorque command 
+
    
+
    Syntax:
+
    
+
    fix ID group-ID addtorque Tx Ty Tz 
+
    
+
    • ID, group-ID are documented in fix command 
+
+
    • addtorque = style name of this fix command 
+
+
    • Tx,Ty,Tz = torque component values (torque units) 
+
+
    • any of Tx,Ty,Tz can be a variable (see below) 
+
+
+
    
+
    Examples:
+
    
+
    fix kick bead addtorque 2.0 3.0 5.0
+fix kick bead addtorque 0.0 0.0 v_oscillate 
+
    
+
    Description:
+
    
+
    Add a set of forces to each atom in
+the group such that:
+
    
+
    • the components of the total torque applied on the group (around its
+center of mass) are Tx,Ty,Tz 
+
+
    • the group would move as a rigid body in the absence of other
+forces. 
+
    
+
    This command can be used to drive a group of atoms into rotation.
+
    
+
    Any of the 3 quantities defining the torque components can be specified
+as an equal-style variable, namely Tx,
+Ty, Tz.  If the value is a variable, it should be specified as
+v_name, where name is the variable name.  In this case, the variable
+will be evaluated each timestep, and its value used to determine the
+torque component.
+
    
+
    Equal-style variables can specify formulas with various mathematical
+functions, and include thermo_style command
+keywords for the simulation box parameters and timestep and elapsed
+time.  Thus it is easy to specify a time-dependent torque.
+
    
+
    
+
+
    Restart, fix_modify, output, run start/stop, minimize info:
+
    
+
    No information about this fix is written to binary restart
+files.
+
    
+
    The fix_modify energy option is supported by this
+fix to add the potential "energy" inferred by the added forces to the
+system's potential energy as part of thermodynamic
+output.  This is a fictitious quantity but is
+needed so that the minimize command can include the
+forces added by this fix in a consistent manner.  I.e. there is a
+decrease in potential energy when atoms move in the direction of the
+added forces.
+
    
+
    This fix computes a global scalar and a global 3-vector, which can be
+accessed by various output commands.
+The scalar is the potential energy discussed above.  The vector is the
+total torque on the group of atoms before the forces on individual
+atoms are changed by the fix.  The scalar and vector values calculated
+by this fix are "extensive".
+
    
+
    No parameter of this fix can be used with the start/stop keywords of
+the run command.
+
    
+
    The forces due to this fix are imposed during an energy minimization,
+invoked by the minimize command.  You should not
+specify force components with a variable that has time-dependence for
+use with a minimizer, since the minimizer increments the timestep as
+the iteration count during the minimization.
+
    
+
    Restrictions:
+
    
+
    This fix is part of the USER-MISC package.  It is only enabled if
+LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
    
+
    Related commands:
+
    
+
    fix addforce
+
    
+
    Default: none
+
    
+
diff --git a/doc/fix_addtorque.txt b/doc/fix_addtorque.txt
new file mode 100644
index 0000000000..3cda16af67
--- /dev/null
+++ b/doc/fix_addtorque.txt
@@ -0,0 +1,93 @@
+"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 addtorque command :h3
+
+[Syntax:]
+
+fix ID group-ID addtorque Tx Ty Tz :pre
+
+ID, group-ID are documented in "fix"_fix.html command :ulb,l
+addtorque = style name of this fix command :l
+Tx,Ty,Tz = torque component values (torque units) :l
+any of Tx,Ty,Tz can be a variable (see below) :l
+:ule
+
+[Examples:]
+
+fix kick bead addtorque 2.0 3.0 5.0
+fix kick bead addtorque 0.0 0.0 v_oscillate :pre
+
+[Description:]
+
+Add a set of forces to each atom in
+the group such that:
+
+the components of the total torque applied on the group (around its
+center of mass) are Tx,Ty,Tz :ulb,l
+
+the group would move as a rigid body in the absence of other
+forces. :l,ule
+
+This command can be used to drive a group of atoms into rotation.
+
+Any of the 3 quantities defining the torque components can be specified
+as an equal-style "variable"_variable.html, namely {Tx},
+{Ty}, {Tz}.  If the value is a variable, it should be specified as
+v_name, where name is the variable name.  In this case, the variable
+will be evaluated each timestep, and its value used to determine the
+torque component.
+
+Equal-style variables can specify formulas with various mathematical
+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 torque.
+
+: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" inferred by the added forces to the
+system's potential energy as part of "thermodynamic
+output"_thermo_style.html.  This is a fictitious quantity but is
+needed so that the "minimize"_minimize.html command can include the
+forces added by this fix in a consistent manner.  I.e. there is a
+decrease in potential energy when atoms move in the direction of the
+added forces.
+
+This fix computes a global scalar and a global 3-vector, which can be
+accessed by various "output commands"_Section_howto.html#howto_15.
+The scalar is the potential energy discussed above.  The vector is the
+total torque on the group of atoms before the forces on individual
+atoms are changed by the fix.  The scalar and vector values calculated
+by this fix are "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.  You should not
+specify force components with a variable that has time-dependence for
+use with a minimizer, since the minimizer increments the timestep as
+the iteration count during the minimization.
+
+[Restrictions:]
+
+This fix is part of the USER-MISC package.  It is only enabled if
+LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+[Related commands:]
+
+"fix addforce"_fix_addforce.html
+
+[Default:] none
diff --git a/doc/fix_append_atoms.html b/doc/fix_append_atoms.html
new file mode 100644
index 0000000000..1523661ced
--- /dev/null
+++ b/doc/fix_append_atoms.html
@@ -0,0 +1,112 @@
+
+
    LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
    
+
+
+
+
+
+
+
    
+
+
    fix append_atoms command 
+
    
+
    Syntax:
+
    
+
    fix ID group-ID append_atoms face arg ... keyword value ... 
+
    
+
    • ID, group-ID are documented in fix command 
+
+
    • append_atoms = style name of this fix command 
+
+
    • one face/arg pairs must be appended 
+
+
    • face = zhi 
+
+
    • zero or more keyword/value pairs may be appended 
+
+
    • keyword = size or freq or temp or random or units  
+
+
        size args = Lz
+    Lz = z size of lattice region appended in a single event(distance units)
+  freq args = freq
+    freq = the number of timesteps between append events
+  temp args = target damp seed extent
+    target = target velocity for region immediately ahead of the piston
+    damp = damping parameter (time units)
+    seed = random number seed for langevin kicks
+    extent = extent of thermostated region (distance units)
+  random args = xmax ymax zmax seed
+    xmax, ymax, zmax = maximum displacement in particular direction (distance units)
+    seed = random number seed for random displacement
+  units value = lattice or box
+    lattice = the wall position is defined in lattice units
+    box = the wall position is defined in simulation box units 
+
      
+
+
    
+
    Examples:
+
    
+
    fix 1 all append_atoms zhi size 5.0 freq 295 units lattice
+fix 4 all append_atoms zhi size 15.0 freq 5 units box
+fix A all append_atoms zhi size 1.0 freq 1000 units lattice 
+
    
+
    Description:
+
    
+
    This fix creates atoms on a lattice, appended on the zhi edge of the system box.
+This can be useful when a shock or wave is propagating from zlo.  This allows
+the system to grow with time to accommodate an expanding wave.   A simulation 
+box must already exist, which is typically created via the 
+create_box command.  Before using this command, a
+lattice must also be defined using the lattice command.
+
    
+
    This fix will automatically freeze atoms on the zhi edge of the system, so that
+overlaps are avoided when new atoms are appended.  
+
    
+
    The size keyword defines the size in z of the chunk of material to be added.
+
    
+
    The random keyword will give the atoms random displacements around their
+lattice points to simulate some initial temperature.
+
    
+
    The temp keyword will cause a region to be thermostated with a Langevin
+thermostat on the zhi boundary.  The size of the region is measured from zhi and
+is set with the extent argument.
+
    
+
    The units keyword determines the meaning of the distance units used
+to define a wall position, but only when a numeric constant is used.
+A box value selects standard distance units as defined by the
+units command, e.g. Angstroms for units = real or metal.
+A lattice value means the distance units are in lattice spacings.
+The lattice command must have been previously used to
+define the lattice spacings.
+
    
+
    
+
+
    Restart, fix_modify, output, run start/stop, minimize info:
+
    
+
    No information about this fix is written to binary restart
+files.  None of the fix_modify options
+are relevant to this fix.  No global or per-atom quantities are stored
+by this fix for access by various output
+commands.  No parameter of this fix can be
+used with the start/stop keywords of the run command.
+This fix is not invoked during energy minimization.
+
    
+
    Restrictions:
+
    
+
    This fix style is part of the SHOCK package.  It is only enabled if
+LAMMPS was built with that package. See the Making
+LAMMPS section for more info.
+
    
+
    The zhi boundary on which atoms are added with append_atoms must be shrink-wrapped.
+The zlo boundary may be any boundary type other than periodic.
+
    
+
    Related commands:
+
    
+
    fix wall/piston command
+
    
+
    Default: size = 0.0, freq = 0, units = lattice.
+
    
+
    
+
+
diff --git a/doc/fix_append_atoms.txt b/doc/fix_append_atoms.txt
new file mode 100644
index 0000000000..a98c9734d6
--- /dev/null
+++ b/doc/fix_append_atoms.txt
@@ -0,0 +1,100 @@
+"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 append_atoms command :h3
+
+[Syntax:]
+
+fix ID group-ID append_atoms face arg ... keyword value ... :pre
+
+ID, group-ID are documented in "fix"_fix.html command :ulb,l
+append_atoms = style name of this fix command :l
+one face/arg pairs must be appended :l
+face = {zhi} :l
+zero or more keyword/value pairs may be appended :l
+keyword = {size} or {freq} or {temp} or {random} or {units}  :l
+  {size} args = Lz
+    Lz = z size of lattice region appended in a single event(distance units)
+  {freq} args = freq
+    freq = the number of timesteps between append events
+  {temp} args = target damp seed extent
+    target = target velocity for region immediately ahead of the piston
+    damp = damping parameter (time units)
+    seed = random number seed for langevin kicks
+    extent = extent of thermostated region (distance units)
+  {random} args = xmax ymax zmax seed
+    {xmax}, {ymax}, {zmax} = maximum displacement in particular direction (distance units)
+    {seed} = random number seed for random displacement
+  {units} value = {lattice} or {box}
+    {lattice} = the wall position is defined in lattice units
+    {box} = the wall position is defined in simulation box units :pre
+:ule
+
+[Examples:]
+
+fix 1 all append_atoms zhi size 5.0 freq 295 units lattice
+fix 4 all append_atoms zhi size 15.0 freq 5 units box
+fix A all append_atoms zhi size 1.0 freq 1000 units lattice :pre
+
+[Description:]
+
+This fix creates atoms on a lattice, appended on the zhi edge of the system box.
+This can be useful when a shock or wave is propagating from zlo.  This allows
+the system to grow with time to accommodate an expanding wave.   A simulation 
+box must already exist, which is typically created via the 
+"create_box"_create_box.html command.  Before using this command, a
+lattice must also be defined using the "lattice"_lattice.html command.
+
+This fix will automatically freeze atoms on the zhi edge of the system, so that
+overlaps are avoided when new atoms are appended.  
+
+The {size} keyword defines the size in z of the chunk of material to be added.
+
+The {random} keyword will give the atoms random displacements around their
+lattice points to simulate some initial temperature.
+
+The {temp} keyword will cause a region to be thermostated with a Langevin
+thermostat on the zhi boundary.  The size of the region is measured from zhi and
+is set with the {extent} argument.
+
+The {units} keyword determines the meaning of the distance units used
+to define a wall position, but only when a numeric constant is used.
+A {box} value selects standard distance units as defined by the
+"units"_units.html command, e.g. Angstroms for units = real or metal.
+A {lattice} value means the distance units are in lattice spacings.
+The "lattice"_lattice.html command must have been previously used to
+define the lattice spacings.
+
+:line
+
+[Restart, fix_modify, output, run start/stop, minimize info:]
+
+No information about this fix is written to "binary restart
+files"_restart.html.  None of the "fix_modify"_fix_modify.html options
+are relevant to this fix.  No global or per-atom quantities are stored
+by this fix for access by various "output
+commands"_Section_howto.html#4_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 style is part of the SHOCK package.  It is only enabled if
+LAMMPS was built with that package. See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+The zhi boundary on which atoms are added with append_atoms must be shrink-wrapped.
+The zlo boundary may be any boundary type other than periodic.
+
+[Related commands:]
+
+"fix wall/piston"_fix_wall_piston.html command
+
+[Default:] {size} = 0.0, {freq} = 0, {units} = lattice.
+
+:line
diff --git a/doc/fix_atc.html b/doc/fix_atc.html
index 83c3207406..18063dd103 100644
--- a/doc/fix_atc.html
+++ b/doc/fix_atc.html
@@ -144,16 +144,16 @@ distribution.  Individual doc pages are listed and linked to below.
 files.  The fix_modify options
 relevant to this fix are listed below.  No global scalar or vector or
 per-atom quantities are stored by this fix for access by various
-output commands.  No parameter of this fix
-can be used with the start/stop keywords of the run
+output commands.  No parameter of this
+fix can be used with the start/stop keywords of the run
 command.  This fix is not invoked during energy
 minimization.
 
    
 
    Restrictions:
 
    
-
    This fix is part of the "user-atc" package.  It is only enabled if
+
    This fix is part of the USER-ATC package.  It is only enabled if
 LAMMPS was built with that package, which also requires the ATC
-library be built and linked with LAMMPS.  See the Making
+library be built and linked with LAMMPS.  See the Making
 LAMMPS section for more info.
 
    
 
    Related commands:
diff --git a/doc/fix_atc.txt b/doc/fix_atc.txt
index 48a1c34c25..551265b9e0 100644
--- a/doc/fix_atc.txt
+++ b/doc/fix_atc.txt
@@ -137,17 +137,17 @@ No information about this fix is written to "binary restart
 files"_restart.html.  The "fix_modify"_fix_modify.html options
 relevant to this fix are listed below.  No global scalar or vector or
 per-atom quantities are stored by this fix for access by various
-"output commands"_Section_howto.html#4_15.  No parameter of this fix
-can be used with the {start/stop} keywords of the "run"_run.html
+"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 "user-atc" package.  It is only enabled if
+This fix is part of the USER-ATC package.  It is only enabled if
 LAMMPS was built with that package, which also requires the ATC
 library be built and linked with LAMMPS.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+LAMMPS"_Section_start.html#start_3 section for more info.
 
 [Related commands:]
 
diff --git a/doc/fix_ave_atom.html b/doc/fix_ave_atom.html
index d8a0cbc748..b93578e38b 100644
--- a/doc/fix_ave_atom.html
+++ b/doc/fix_ave_atom.html
@@ -40,13 +40,13 @@ one or more input values can be listed
 
    Examples:
 
    
 
    fix 1 all ave/atom 1 100 100 vx vy vz
-fix 1 all ave/atom 10 20 1000 c_my_stress1 
+fix 1 all ave/atom 10 20 1000 c_my_stress[1] 
 
    
 
    Description:
 
    
 
    Use one or more per-atom vectors as inputs every few timesteps, and
 average them atom by atom over longer timescales.  The resulting
-per-atom averages can be used by other output
+per-atom averages can be used by other output
 commands such as the fix
 ave/spatial or dump custom commands.
 
    
@@ -129,11 +129,11 @@ per-atom quantities to time average.
 
    No information about this fix is written to binary restart
 files.  None of the fix_modify options
 are relevant to this fix.  No global scalar or vector quantities are
-stored by this fix for access by various output
+stored by this fix for access by various output
 commands.
 
    
 
    This fix produces a per-atom vector or array which can be accessed by
-various output commands.  A vector is
+various output commands.  A vector is
 produced if only a single quantity is averaged by this fix.  If two or
 more quantities are averaged, then an array of values is produced.
 The per-atom values can only be accessed on timesteps that are
diff --git a/doc/fix_ave_atom.txt b/doc/fix_ave_atom.txt
index 095a8b4c19..bbfab6a25b 100644
--- a/doc/fix_ave_atom.txt
+++ b/doc/fix_ave_atom.txt
@@ -30,14 +30,14 @@ value = x, y, z, vx, vy, vz, fx, fy, fz, c_ID, c_ID\[i\], f_ID, f_ID\[i\], v_nam
 [Examples:]
 
 fix 1 all ave/atom 1 100 100 vx vy vz
-fix 1 all ave/atom 10 20 1000 c_my_stress[1] :pre
+fix 1 all ave/atom 10 20 1000 c_my_stress\[1\] :pre
 
 [Description:]
 
 Use one or more per-atom vectors as inputs every few timesteps, and
 average them atom by atom over longer timescales.  The resulting
 per-atom averages can be used by other "output
-commands"_Section_howto.html#4_15 such as the "fix
+commands"_Section_howto.html#howto_15 such as the "fix
 ave/spatial"_fix_ave_spatial.html or "dump custom"_dump.html commands.
 
 The group specified with the command means only atoms within the group
@@ -120,10 +120,10 @@ No information about this fix is written to "binary restart
 files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.  No global scalar or vector quantities are
 stored by this fix for access by various "output
-commands"_Section_howto.html#4_15.
+commands"_Section_howto.html#howto_15.
 
 This fix produces a per-atom vector or array which can be accessed by
-various "output commands"_Section_howto.html#4_15.  A vector is
+various "output commands"_Section_howto.html#howto_15.  A vector is
 produced if only a single quantity is averaged by this fix.  If two or
 more quantities are averaged, then an array of values is produced.
 The per-atom values can only be accessed on timesteps that are
diff --git a/doc/fix_ave_correlate.html b/doc/fix_ave_correlate.html
index 40e2fb8916..76e1c2edde 100644
--- a/doc/fix_ave_correlate.html
+++ b/doc/fix_ave_correlate.html
@@ -77,7 +77,7 @@ fix 1 all ave/correlate 1 50 10000 &
 calculate time correlations bewteen them at varying time intervals,
 and average the correlation data over longer timescales.  The
 resulting correlation values can be time integrated by
-variables or used by other output
+variables or used by other output
 commands such as thermo_style
 custom, and can also be written to a file.
 
    
@@ -287,7 +287,7 @@ files.  None of the fix_modify options
 are relevant to this fix.
 
    
 
    This fix computes a global array of values which can be accessed by
-various output commands.  The values can
+various output commands.  The values can
 only be accessed on timesteps that are multiples of Nfreq since that
 is when averaging is performed.  The global array has # of rows =
 Nrepeat and # of columns = Npair+2.  The first column has the time
diff --git a/doc/fix_ave_correlate.txt b/doc/fix_ave_correlate.txt
index ce20deead6..cf792ee112 100644
--- a/doc/fix_ave_correlate.txt
+++ b/doc/fix_ave_correlate.txt
@@ -65,7 +65,7 @@ calculate time correlations bewteen them at varying time intervals,
 and average the correlation data over longer timescales.  The
 resulting correlation values can be time integrated by
 "variables"_variable.html or used by other "output
-commands"_Section_howto.html#4_15 such as "thermo_style
+commands"_Section_howto.html#howto_15 such as "thermo_style
 custom"_thermo_style.html, and can also be written to a file.
 
 The group specified with this command is ignored.  However, note that
@@ -274,7 +274,7 @@ files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.
 
 This fix computes a global array of values which can be accessed by
-various "output commands"_Section_howto.html#4_15.  The values can
+various "output commands"_Section_howto.html#howto_15.  The values can
 only be accessed on timesteps that are multiples of {Nfreq} since that
 is when averaging is performed.  The global array has # of rows =
 {Nrepeat} and # of columns = Npair+2.  The first column has the time
diff --git a/doc/fix_ave_histo.html b/doc/fix_ave_histo.html
index 6330a34e66..ee99ee5236 100644
--- a/doc/fix_ave_histo.html
+++ b/doc/fix_ave_histo.html
@@ -78,8 +78,9 @@ fix 1 all ave/histo 1 100 1000 -2.0 2.0 18 vx vy vz mode vector ave running beyo
 
    
 
    Use one or more values as inputs every few timesteps, histogram them,
 and average the histogram over longer timescales.  The resulting
-histogram can be used by other output
-commands, and can also be written to a file.
+histogram can be used by other output
+commands, and can also be written to a
+file.
 
    
 
    The group specified with this command is ignored for global and local
 input values.  For per-atom input values, only atoms in the group
@@ -290,10 +291,10 @@ files.  None of the fix_modify options
 are relevant to this fix.
 
    
 
    This fix produces a global vector and global array which can be
-accessed by various output commands.  The
-values can only be accessed on timesteps that are multiples of Nfreq
-since that is when a histogram is generated.
-The global vector has 4 values:
+accessed by various output commands.
+The values can only be accessed on timesteps that are multiples of
+Nfreq since that is when a histogram is generated.  The global
+vector has 4 values:
 
    
 
    • 1 = total counts in the histogram
 
    • 2 = values that were not histogrammed (see beyond keyword)
diff --git a/doc/fix_ave_histo.txt b/doc/fix_ave_histo.txt
index aa0b046c92..7f009eba04 100644
--- a/doc/fix_ave_histo.txt
+++ b/doc/fix_ave_histo.txt
@@ -64,7 +64,8 @@ fix 1 all ave/histo 1 100 1000 -2.0 2.0 18 vx vy vz mode vector ave running beyo
 Use one or more values as inputs every few timesteps, histogram them,
 and average the histogram over longer timescales.  The resulting
 histogram can be used by other "output
-commands"_Section_howto.html#4_15, and can also be written to a file.
+commands"_Section_howto.html#howto_15, and can also be written to a
+file.
 
 The group specified with this command is ignored for global and local
 input values.  For per-atom input values, only atoms in the group
@@ -275,10 +276,10 @@ files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.
 
 This fix produces a global vector and global array which can be
-accessed by various "output commands"_Section_howto.html#4_15.  The
-values can only be accessed on timesteps that are multiples of {Nfreq}
-since that is when a histogram is generated.
-The global vector has 4 values:
+accessed by various "output commands"_Section_howto.html#howto_15.
+The values can only be accessed on timesteps that are multiples of
+{Nfreq} since that is when a histogram is generated.  The global
+vector has 4 values:
 
 1 = total counts in the histogram
 2 = values that were not histogrammed (see {beyond} keyword)
diff --git a/doc/fix_ave_spatial.html b/doc/fix_ave_spatial.html
index d1046fb7fe..e61b3d6bb9 100644
--- a/doc/fix_ave_spatial.html
+++ b/doc/fix_ave_spatial.html
@@ -78,7 +78,7 @@ fix 1 flow ave/spatial 100 5 1000 z lower 1.0 y 0.0 2.5 density/mass ave running
 
      Use one or more per-atom vectors as inputs every few timesteps, bin
 their values spatially into 1d, 2d, or 3d bins based on current atom
 coordinates, and average the bin values over longer timescales.  The
-resulting bin averages can be used by other output
+resulting bin averages can be used by other output
 commands such as thermo_style
 custom, and can also be written to a file.
 
      
@@ -163,11 +163,11 @@ counted in the first/last bin in that dimension.
 
      For orthogonal simulation boxes, the bins are also layers, pencils, or
 boxes aligned with the xyz coordinate axes.  For triclinic
 (non-orthogonal) simulation boxes, the bins are so that they are
-parallel to the tilted faces of the simulation box.  See this
-section of the manual for a discussion of the
-geometry of triclinic boxes in LAMMPS.  As described there, a tilted
-simulation box has edge vectors a,b,c.  In that nomenclature, bins in
-the x dimension have faces with normals in the "b" cross "c"
+parallel to the tilted faces of the simulation box.  See this
+section of the manual for a discussion of
+the geometry of triclinic boxes in LAMMPS.  As described there, a
+tilted simulation box has edge vectors a,b,c.  In that nomenclature,
+bins in the x dimension have faces with normals in the "b" cross "c"
 direction.  Bins in y have faces normal to the "a" cross "c"
 direction.  And bins in z have faces normal to the "a" cross "b"
 direction.  Note that in order to define the size and position of
@@ -321,7 +321,7 @@ files.  None of the fix_modify options
 are relevant to this fix.
 
      
 
      This fix computes a global array of values which can be accessed by
-various output commands.  The values can
+various output commands.  The values can
 only be accessed on timesteps that are multiples of Nfreq since that
 is when averaging is performed.  The global array has # of rows =
 Nbins and # of columns = Ndim+1+Nvalues, where Ndim = 1,2,3 for
diff --git a/doc/fix_ave_spatial.txt b/doc/fix_ave_spatial.txt
index ed3b95f328..f6ce44d8f9 100644
--- a/doc/fix_ave_spatial.txt
+++ b/doc/fix_ave_spatial.txt
@@ -64,7 +64,7 @@ Use one or more per-atom vectors as inputs every few timesteps, bin
 their values spatially into 1d, 2d, or 3d bins based on current atom
 coordinates, and average the bin values over longer timescales.  The
 resulting bin averages can be used by other "output
-commands"_Section_howto.html#4_15 such as "thermo_style
+commands"_Section_howto.html#howto_15 such as "thermo_style
 custom"_thermo_style.html, and can also be written to a file.
 
 The group specified with the command means only atoms within the group
@@ -149,10 +149,10 @@ For orthogonal simulation boxes, the bins are also layers, pencils, or
 boxes aligned with the xyz coordinate axes.  For triclinic
 (non-orthogonal) simulation boxes, the bins are so that they are
 parallel to the tilted faces of the simulation box.  See "this
-section"_Section_howto.html#4_12 of the manual for a discussion of the
-geometry of triclinic boxes in LAMMPS.  As described there, a tilted
-simulation box has edge vectors a,b,c.  In that nomenclature, bins in
-the x dimension have faces with normals in the "b" cross "c"
+section"_Section_howto.html#howto_12 of the manual for a discussion of
+the geometry of triclinic boxes in LAMMPS.  As described there, a
+tilted simulation box has edge vectors a,b,c.  In that nomenclature,
+bins in the x dimension have faces with normals in the "b" cross "c"
 direction.  Bins in y have faces normal to the "a" cross "c"
 direction.  And bins in z have faces normal to the "a" cross "b"
 direction.  Note that in order to define the size and position of
@@ -306,7 +306,7 @@ files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.
 
 This fix computes a global array of values which can be accessed by
-various "output commands"_Section_howto.html#4_15.  The values can
+various "output commands"_Section_howto.html#howto_15.  The values can
 only be accessed on timesteps that are multiples of {Nfreq} since that
 is when averaging is performed.  The global array has # of rows =
 Nbins and # of columns = Ndim+1+Nvalues, where Ndim = 1,2,3 for
diff --git a/doc/fix_ave_time.html b/doc/fix_ave_time.html
index 1ca9dd4ff0..78446a1d45 100644
--- a/doc/fix_ave_time.html
+++ b/doc/fix_ave_time.html
@@ -72,7 +72,7 @@ fix 1 all ave/time 1 100 1000 f_indent f_indent[1] file temp.indent off 1
 
      
 
      Use one or more global values as inputs every few timesteps, and
 average them over longer timescales.  The resulting averages can be
-used by other output commands such as
+used by other output commands such as
 thermo_style custom, and can also be written to a
 file.  Note that if no time averaging is done, this command can be
 used as a convenient way to simply output one or more global values to
@@ -283,10 +283,10 @@ files.  None of the fix_modify options
 are relevant to this fix.
 
      
 
      This fix produces a global scalar or global vector or global array
-which can be accessed by various output
-commands.  The values can only be accessed on
-timesteps that are multiples of Nfreq since that is when averaging
-is performed.
+which can be accessed by various output
+commands.  The values can only be
+accessed on timesteps that are multiples of Nfreq since that is when
+averaging is performed.
 
      
 
      A scalar is produced if only a single input value is averaged and
 mode = scalar.  A vector is produced if multiple input values are
diff --git a/doc/fix_ave_time.txt b/doc/fix_ave_time.txt
index aa8a8ffdce..18a224a7e4 100644
--- a/doc/fix_ave_time.txt
+++ b/doc/fix_ave_time.txt
@@ -59,7 +59,7 @@ fix 1 all ave/time 1 100 1000 f_indent f_indent\[1\] file temp.indent off 1 :pre
 
 Use one or more global values as inputs every few timesteps, and
 average them over longer timescales.  The resulting averages can be
-used by other "output commands"_Section_howto.html#4_15 such as
+used by other "output commands"_Section_howto.html#howto_15 such as
 "thermo_style custom"_thermo_style.html, and can also be written to a
 file.  Note that if no time averaging is done, this command can be
 used as a convenient way to simply output one or more global values to
@@ -271,9 +271,9 @@ are relevant to this fix.
 
 This fix produces a global scalar or global vector or global array
 which can be accessed by various "output
-commands"_Section_howto.html#4_15.  The values can only be accessed on
-timesteps that are multiples of {Nfreq} since that is when averaging
-is performed.
+commands"_Section_howto.html#howto_15.  The values can only be
+accessed on timesteps that are multiples of {Nfreq} since that is when
+averaging is performed.
 
 A scalar is produced if only a single input value is averaged and
 {mode} = scalar.  A vector is produced if multiple input values are
diff --git a/doc/fix_aveforce.html b/doc/fix_aveforce.html
index 2a0e6fe28d..3aae86bb54 100644
--- a/doc/fix_aveforce.html
+++ b/doc/fix_aveforce.html
@@ -11,6 +11,8 @@
 
 
      fix aveforce command 
 
      
+
      fix aveforce/cuda command 
+
      
 
      Syntax:
 
      
 
      fix ID group-ID aveforce fx fy fz keyword value ... 
@@ -21,8 +23,8 @@
 
 
    • fx,fy,fz = force component values (force units) 
 
-
    • any of fx,fy,fz can be a variable (see below) 
-
+
        any of fx,fy,fz can be a variable (see below) 
+
      
 
    • zero or more keyword/value pairs may be appended to args 
 
 
    • keyword = region  
@@ -71,6 +73,29 @@ time.  Thus it is easy to specify a time-dependent average force.
 specified geometric region in order to have force added
 to it.
 
      
+
      
+
+
      Styles with a cuda 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
+this section of the manual.  The accelerated
+styles take the same arguments and should produce the same results,
+except for round-off and precision issues.
+
      
+
      These accelerated styles are part of the USER-CUDA package.  They are
+only enabled if LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
      
+
      You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
      
+
      See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
      
+
      
+
 
      Restart, fix_modify, output, run start/stop, minimize info:
 
      
 
      No information about this fix is written to binary restart
@@ -78,7 +103,7 @@ files.  None of the fix_modify options
 are relevant to this fix.
 
      
 
      This fix computes a global 3-vector of forces, which can be accessed
-by various output commands.  This is the
+by various output commands.  This is the
 total force on the group of atoms before the forces on individual
 atoms are changed by the fix.  The vector values calculated by this
 fix are "extensive".
diff --git a/doc/fix_aveforce.txt b/doc/fix_aveforce.txt
index b6a5399df1..bae11d47d4 100644
--- a/doc/fix_aveforce.txt
+++ b/doc/fix_aveforce.txt
@@ -7,6 +7,7 @@
 :line
 
 fix aveforce command :h3
+fix aveforce/cuda command :h3
 
 [Syntax:]
 
@@ -15,7 +16,7 @@ fix ID group-ID aveforce fx fy fz keyword value ... :pre
 ID, group-ID are documented in "fix"_fix.html command :ulb,l
 aveforce = style name of this fix command :l
 fx,fy,fz = force component values (force units) :l
-any of fx,fy,fz can be a variable (see below) :l
+  any of fx,fy,fz can be a variable (see below) :pre
 zero or more keyword/value pairs may be appended to args :l
 keyword = {region}  :l
   {region} value = region-ID
@@ -61,6 +62,29 @@ If the {region} keyword is used, the atom must also be in the
 specified geometric "region"_region.html in order to have force added
 to it.
 
+:line
+
+Styles with a {cuda} 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
+"this section"_Section_accelerate.html of the manual.  The accelerated
+styles take the same arguments and should produce the same results,
+except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA package.  They are
+only enabled if LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restart, fix_modify, output, run start/stop, minimize info:]
 
 No information about this fix is written to "binary restart
@@ -68,7 +92,7 @@ files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.
 
 This fix computes a global 3-vector of forces, which can be accessed
-by various "output commands"_Section_howto.html#4_15.  This is the
+by various "output commands"_Section_howto.html#howto_15.  This is the
 total force on the group of atoms before the forces on individual
 atoms are changed by the fix.  The vector values calculated by this
 fix are "extensive".
diff --git a/doc/fix_bond_break.html b/doc/fix_bond_break.html
index 182874d073..55e786263b 100644
--- a/doc/fix_bond_break.html
+++ b/doc/fix_bond_break.html
@@ -113,9 +113,9 @@ files.  None of the fix_modify options
 are relevant to this fix. 
 
      
 
      This fix computes two statistics which it stores in a global vector of
-length 2, which can be accessed by various output
-commands.  The vector values calculated by
-this fix are "intensive".
+length 2, which can be accessed by various output
+commands.  The vector values calculated
+by this fix are "intensive".
 
      
 
      These are the 2 quantities:
 
      
@@ -128,6 +128,10 @@ minimization.
 
      
 
      Restrictions:
 
      
+
      This fix is part of the MC package.  It is only enabled if LAMMPS was
+built with that package.  See the Making
+LAMMPS section for more info.
+
      
 
      Currently, there are 2 restrictions for using this fix.  We may relax
 these in the future if there are new models that would be enabled by
 it.
diff --git a/doc/fix_bond_break.txt b/doc/fix_bond_break.txt
index f63c3c3718..d6ee6bec0e 100755
--- a/doc/fix_bond_break.txt
+++ b/doc/fix_bond_break.txt
@@ -103,8 +103,8 @@ are relevant to this fix.
 
 This fix computes two statistics which it stores in a global vector of
 length 2, which can be accessed by various "output
-commands"_Section_howto.html#4_15.  The vector values calculated by
-this fix are "intensive".
+commands"_Section_howto.html#howto_15.  The vector values calculated
+by this fix are "intensive".
 
 These are the 2 quantities:
 
@@ -117,6 +117,10 @@ minimization"_minimize.html.
 
 [Restrictions:]
 
+This fix is part of the MC 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.
+
 Currently, there are 2 restrictions for using this fix.  We may relax
 these in the future if there are new models that would be enabled by
 it.
diff --git a/doc/fix_bond_create.html b/doc/fix_bond_create.html
index 1c7eb027d3..a521d01914 100644
--- a/doc/fix_bond_create.html
+++ b/doc/fix_bond_create.html
@@ -170,9 +170,9 @@ files.  None of the fix_modify options
 are relevant to this fix. 
 
      
 
      This fix computes two statistics which it stores in a global vector of
-length 2, which can be accessed by various output
-commands.  The vector values calculated by
-this fix are "intensive".
+length 2, which can be accessed by various output
+commands.  The vector values calculated
+by this fix are "intensive".
 
      
 
      These are the 2 quantities:
 
      
@@ -185,6 +185,10 @@ minimization.
 
      
 
      Restrictions:
 
      
+
      This fix is part of the MC package.  It is only enabled if LAMMPS was
+built with that package.  See the Making
+LAMMPS section for more info.
+
      
 
      Currently, there are 2 restrictions for using this fix.  We may relax
 these in the future if there are new models that would be enabled by
 it.
diff --git a/doc/fix_bond_create.txt b/doc/fix_bond_create.txt
index 580f888dfc..17fbb77ede 100755
--- a/doc/fix_bond_create.txt
+++ b/doc/fix_bond_create.txt
@@ -159,8 +159,8 @@ are relevant to this fix.
 
 This fix computes two statistics which it stores in a global vector of
 length 2, which can be accessed by various "output
-commands"_Section_howto.html#4_15.  The vector values calculated by
-this fix are "intensive".
+commands"_Section_howto.html#howto_15.  The vector values calculated
+by this fix are "intensive".
 
 These are the 2 quantities:
 
@@ -173,6 +173,10 @@ minimization"_minimize.html.
 
 [Restrictions:]
 
+This fix is part of the MC 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.
+
 Currently, there are 2 restrictions for using this fix.  We may relax
 these in the future if there are new models that would be enabled by
 it.
diff --git a/doc/fix_bond_swap.html b/doc/fix_bond_swap.html
index a4ced35353..4a6e5b7366 100644
--- a/doc/fix_bond_swap.html
+++ b/doc/fix_bond_swap.html
@@ -145,10 +145,10 @@ defined to this fix which will be used to compute the temperature for
 the Boltzmann criterion.
 
      
 
      This fix computes two statistical quantities as a global 2-vector of
-output, which can be accessed by various output
-commands.  The first component of the vector
-is the cummulative number of swaps performed by all processors.  The
-second component of the vector is the cummulative number of swaps
+output, which can be accessed by various output
+commands.  The first component of the
+vector is the cummulative number of swaps performed by all processors.
+The second component of the vector is the cummulative number of swaps
 attempted (whether accepted or rejected).  Note that a swap "attempt"
 only occurs when swap partners meeting the criteria described above
 are found on a particular timestep.  The vector values calculated by
@@ -160,6 +160,10 @@ minimization.
 
      
 
      Restrictions:
 
      
+
      This fix is part of the MC package.  It is only enabled if LAMMPS was
+built with that package.  See the Making
+LAMMPS section for more info.
+
      
 
      The setings of the "special_bond" command must be 0,1,1 in order to
 use this fix, which is typical of bead-spring chains with FENE or
 harmonic bonds.  This means that pairwise interactions between bonded
diff --git a/doc/fix_bond_swap.txt b/doc/fix_bond_swap.txt
index eba291c8c7..e1e1aeba5a 100755
--- a/doc/fix_bond_swap.txt
+++ b/doc/fix_bond_swap.txt
@@ -143,9 +143,9 @@ the Boltzmann criterion.
 
 This fix computes two statistical quantities as a global 2-vector of
 output, which can be accessed by various "output
-commands"_Section_howto.html#4_15.  The first component of the vector
-is the cummulative number of swaps performed by all processors.  The
-second component of the vector is the cummulative number of swaps
+commands"_Section_howto.html#howto_15.  The first component of the
+vector is the cummulative number of swaps performed by all processors.
+The second component of the vector is the cummulative number of swaps
 attempted (whether accepted or rejected).  Note that a swap "attempt"
 only occurs when swap partners meeting the criteria described above
 are found on a particular timestep.  The vector values calculated by
@@ -157,6 +157,10 @@ minimization"_minimize.html.
 
 [Restrictions:]
 
+This fix is part of the MC package.  It is only enabled if LAMMPS was
+built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
 The setings of the "special_bond" command must be 0,1,1 in order to
 use this fix, which is typical of bead-spring chains with FENE or
 harmonic bonds.  This means that pairwise interactions between bonded
diff --git a/doc/fix_box_relax.html b/doc/fix_box_relax.html
index cf8bee4f74..917e29a9f8 100644
--- a/doc/fix_box_relax.html
+++ b/doc/fix_box_relax.html
@@ -82,6 +82,19 @@ re-scaled.  This can be useful for leaving the coordinates of atoms in
 a solid substrate unchanged and controlling the pressure of a
 surrounding fluid.
 
      
+
      IMPORTANT NOTE: Appling an external pressure to tilt dimensions xy,
+xz, yz can sometimes result in arbitrarily large values of the
+tilt dimensions, i.e. a dramatically deformed simulation box.  This
+typically indicates that there is something badly wrong with how the
+simulation was constructed.  The two most common sources of this error
+are applying a shear stress to a liquid system or specifying an
+external shear stress tensor that exceeds the yield stress of the
+solid.  In either case the minimization is either not going to
+converge at all, or converge to a bogus conformation.  Note that
+LAMMPS will not throw an error when the tilt value becomes extreme,
+but the final box may be unsuitable for running dynamics on, unless
+fix deform is used first to remap the box to a valid tilt value.
+
      
 
      
 
 
      The couple keyword allows two or three of the diagonal components of
@@ -267,7 +280,7 @@ compute specified by the press keyword will be unaffected by the
 temp setting.
 
      
 
      This fix computes a global scalar which can be accessed by various
-output commands.  The scalar is the
+output commands.  The scalar is the
 pressure-volume energy, plus the strain energy, if it exists.
 
      
 
      No parameter of this fix can be used with the start/stop keywords of
diff --git a/doc/fix_box_relax.txt b/doc/fix_box_relax.txt
index 606cb3edab..d1b924d0f9 100644
--- a/doc/fix_box_relax.txt
+++ b/doc/fix_box_relax.txt
@@ -76,6 +76,19 @@ re-scaled.  This can be useful for leaving the coordinates of atoms in
 a solid substrate unchanged and controlling the pressure of a
 surrounding fluid.
 
+IMPORTANT NOTE: Appling an external pressure to tilt dimensions {xy},
+{xz}, {yz} can sometimes result in arbitrarily large values of the
+tilt dimensions, i.e. a dramatically deformed simulation box.  This
+typically indicates that there is something badly wrong with how the
+simulation was constructed.  The two most common sources of this error
+are applying a shear stress to a liquid system or specifying an
+external shear stress tensor that exceeds the yield stress of the
+solid.  In either case the minimization is either not going to
+converge at all, or converge to a bogus conformation.  Note that
+LAMMPS will not throw an error when the tilt value becomes extreme,
+but the final box may be unsuitable for running dynamics on, unless
+fix deform is used first to remap the box to a valid tilt value.
+
 :line
 
 The {couple} keyword allows two or three of the diagonal components of
@@ -261,7 +274,7 @@ compute specified by the {press} keyword will be unaffected by the
 {temp} setting.
 
 This fix computes a global scalar which can be accessed by various
-"output commands"_Section_howto.html#4_15.  The scalar is the
+"output commands"_Section_howto.html#howto_15.  The scalar is the
 pressure-volume energy, plus the strain energy, if it exists.
 
 No parameter of this fix can be used with the {start/stop} keywords of
diff --git a/doc/fix_deform.html b/doc/fix_deform.html
index 2cb1805bac..3a090578bd 100644
--- a/doc/fix_deform.html
+++ b/doc/fix_deform.html
@@ -436,7 +436,7 @@ defined in terms of distance/time.
 
      No information about this fix is written to binary restart
 files.  None of the fix_modify options
 are relevant to this fix.  No global or per-atom quantities are stored
-by this fix for access by various output
+by this fix for access by various output
 commands.
 
      
 
      This fix can perform deformation over multiple runs, using the start
diff --git a/doc/fix_deform.txt b/doc/fix_deform.txt
index 3cda5dbd7a..e1f81e3300 100644
--- a/doc/fix_deform.txt
+++ b/doc/fix_deform.txt
@@ -427,7 +427,7 @@ No information about this fix is written to "binary restart
 files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.  No global or per-atom quantities are stored
 by this fix for access by various "output
-commands"_Section_howto.html#4_15.
+commands"_Section_howto.html#howto_15.
 
 This fix can perform deformation over multiple runs, using the {start}
 and {stop} keywords of the "run"_run.html command.  See the
diff --git a/doc/fix_deposit.html b/doc/fix_deposit.html
index a94e4b69a3..ad60c72a93 100644
--- a/doc/fix_deposit.html
+++ b/doc/fix_deposit.html
@@ -155,7 +155,7 @@ operation of the fix continues in an uninterrupted fashion.
 
      
 
      None of the fix_modify options are relevant to this
 fix.  No global or per-atom quantities are stored by this fix for
-access by various output commands.  No
+access by various output commands.  No
 parameter of this fix can be used with the start/stop keywords of
 the run command.  This fix is not invoked during energy
 minimization.
diff --git a/doc/fix_deposit.txt b/doc/fix_deposit.txt
index b22e9ca730..60e13cdddd 100644
--- a/doc/fix_deposit.txt
+++ b/doc/fix_deposit.txt
@@ -142,7 +142,7 @@ operation of the fix continues in an uninterrupted fashion.
 
 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#4_15.  No
+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.
diff --git a/doc/fix_drag.html b/doc/fix_drag.html
index 5cdd866d18..adef7e6576 100644
--- a/doc/fix_drag.html
+++ b/doc/fix_drag.html
@@ -46,7 +46,7 @@ files.  None of the fix_modify options
 are relevant to this fix.
 
      
 
      This fix computes a global 3-vector of forces, which can be accessed
-by various output commands.  This is the
+by various output commands.  This is the
 total force on the group of atoms by the drag force.  The vector
 values calculated by this fix are "extensive".
 
      
diff --git a/doc/fix_drag.txt b/doc/fix_drag.txt
index 3fdf26bcb8..503563d975 100644
--- a/doc/fix_drag.txt
+++ b/doc/fix_drag.txt
@@ -44,7 +44,7 @@ files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.
 
 This fix computes a global 3-vector of forces, which can be accessed
-by various "output commands"_Section_howto.html#4_15.  This is the
+by various "output commands"_Section_howto.html#howto_15.  This is the
 total force on the group of atoms by the drag force.  The vector
 values calculated by this fix are "extensive".
 
diff --git a/doc/fix_dt_reset.html b/doc/fix_dt_reset.html
index e146adfa9d..6ba8481ed1 100644
--- a/doc/fix_dt_reset.html
+++ b/doc/fix_dt_reset.html
@@ -18,8 +18,8 @@
 
      • ID, group-ID are documented in fix command
 
      • dt/reset = style name of this fix command
 
      • N = recompute dt every N timesteps
-
      • Tmin = minimum dt allowed (can be NULL) (time units)
-
      • Tmax = maximum dt allowed (can be NULL) (time units)
+
      • Tmin = minimum dt allowed which can be NULL (time units)
+
      • Tmax = maximum dt allowed which can be NULL (time units)
 
      • Xmax = maximum distance for an atom to move in one timestep (distance units)
 
      • zero or more keyword/value pairs may be appended
 
      • keyword = units 
@@ -69,12 +69,14 @@ outer loop (largest) timestep, which is the same timestep that the
 files.  None of the fix_modify options
 are relevant to this fix.
 
        
-
        This fix computes a global scalar and a global vector of length 1,
-which can be accessed by various output
-commands.  The scalar is the current timestep
-size.  The cumulative simulation time (in time units) is stored as the
-first element of the vector.  The scalar and vector values calculated
-by this fix are "intensive".
+
        This fix computes a global scalar and a global vector of length 2,
+which can be accessed by various output
+commands.  The scalar is the current
+timestep size.  The first element of the vector stores the cumulative
+simulation time (in time units).  The second element of the vector
+stores the last timestep on which the timestep was reset to a new
+value.  The scalar and vector values calculated by this fix are
+"intensive".
 
        
 
        No parameter of this fix can be used with the start/stop keywords of
 the run command.  This fix is not invoked during energy
@@ -82,10 +84,9 @@ minimization.
 
        
 
        Restrictions:
 
        
-
        The cumulative time is zeroed when the fix is created and
-continuously accrues thereafter.  Using the
-reset_timestep command while this fix is defined
-will mess up the time accumulation.
+
        The cumulative time is zeroed when the fix is created and continuously
+accrues thereafter.  Using the reset_timestep
+command while this fix is defined will mess up the time accumulation.
 
        
 
        Related commands:
 
        
diff --git a/doc/fix_dt_reset.txt b/doc/fix_dt_reset.txt
index c0100bd7fa..ce15fd3437 100644
--- a/doc/fix_dt_reset.txt
+++ b/doc/fix_dt_reset.txt
@@ -15,8 +15,8 @@ fix ID group-ID dt/reset N Tmin Tmax Xmax keyword values ... :pre
 ID, group-ID are documented in "fix"_fix.html command
 dt/reset = style name of this fix command
 N = recompute dt every N timesteps
-Tmin = minimum dt allowed (can be NULL) (time units)
-Tmax = maximum dt allowed (can be NULL) (time units)
+Tmin = minimum dt allowed which can be NULL (time units)
+Tmax = maximum dt allowed which can be NULL (time units)
 Xmax = maximum distance for an atom to move in one timestep (distance units)
 zero or more keyword/value pairs may be appended
 keyword = {units} :ul
@@ -65,12 +65,14 @@ No information about this fix is written to "binary restart
 files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.
 
-This fix computes a global scalar and a global vector of length 1,
+This fix computes a global scalar and a global vector of length 2,
 which can be accessed by various "output
-commands"_Section_howto.html#4_15.  The scalar is the current timestep
-size.  The cumulative simulation time (in time units) is stored as the
-first element of the vector.  The scalar and vector values calculated
-by this fix are "intensive".
+commands"_Section_howto.html#howto_15.  The scalar is the current
+timestep size.  The first element of the vector stores the cumulative
+simulation time (in time units).  The second element of the vector
+stores the last timestep on which the timestep was reset to a new
+value.  The scalar and vector values calculated by this fix are
+"intensive".
 
 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
@@ -78,10 +80,9 @@ minimization"_minimize.html.
 
 [Restrictions:]
 
-The cumulative time is zeroed when the fix is created and
-continuously accrues thereafter.  Using the
-"reset_timestep"_reset_timestep.html command while this fix is defined
-will mess up the time accumulation.
+The cumulative time is zeroed when the fix is created and continuously
+accrues thereafter.  Using the "reset_timestep"_reset_timestep.html
+command while this fix is defined will mess up the time accumulation.
 
 [Related commands:]
 
diff --git a/doc/fix_efield.html b/doc/fix_efield.html
index 894caeb94e..7b3daba5a9 100644
--- a/doc/fix_efield.html
+++ b/doc/fix_efield.html
@@ -52,9 +52,9 @@ with optional time-dependence as well.
 
        No information about this fix is written to binary restart
 files.  None of the fix_modify options
 are relevant to this fix.  No global or per-atom quantities are stored
-by this fix for access by various output
-commands.  No parameter of this fix can be
-used with the start/stop keywords of the run command.
+by this fix for access by various output
+commands.  No parameter of this fix can
+be used with the start/stop keywords of the run command.
 This fix is not invoked during energy minimization.
 
        
 
        Restrictions: none
diff --git a/doc/fix_efield.txt b/doc/fix_efield.txt
index 70562d5cde..6bc7ba4a6d 100644
--- a/doc/fix_efield.txt
+++ b/doc/fix_efield.txt
@@ -50,8 +50,8 @@ No information about this fix is written to "binary restart
 files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.  No global or per-atom quantities are stored
 by this fix for access by various "output
-commands"_Section_howto.html#4_15.  No parameter of this fix can be
-used with the {start/stop} keywords of the "run"_run.html command.
+commands"_Section_howto.html#howto_15.  No parameter of this fix can
+be used with the {start/stop} keywords of the "run"_run.html command.
 This fix is not invoked during "energy minimization"_minimize.html.
 
 [Restrictions:] none
diff --git a/doc/fix_enforce2d.html b/doc/fix_enforce2d.html
index 778d80d60a..cad153683e 100644
--- a/doc/fix_enforce2d.html
+++ b/doc/fix_enforce2d.html
@@ -11,6 +11,8 @@
 
 
        fix enforce2d command 
 
        
+
        fix enforce2d/cuda command 
+
        
 
        Syntax:
 
        
 
        fix ID group-ID enforce2d 
@@ -28,14 +30,37 @@
 This is useful when running a 2d simulation to insure that atoms do
 not move from their initial z coordinate.
 
        
+
        
+
+
        Styles with a cuda 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
+this section of the manual.  The accelerated
+styles take the same arguments and should produce the same results,
+except for round-off and precision issues.
+
        
+
        These accelerated styles are part of the USER-CUDA package.  They are
+only enabled if LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
        
+
        You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
        
+
        See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
        
+
        
+
 
        Restart, fix_modify, output, run start/stop, minimize info:
 
        
 
        No information about this fix is written to binary restart
 files.  None of the fix_modify options
 are relevant to this fix.  No global or per-atom quantities are stored
-by this fix for access by various output
-commands.  No parameter of this fix can be
-used with the start/stop keywords of the run command.
+by this fix for access by various output
+commands.  No parameter of this fix can
+be used with the start/stop keywords of the run command.
 
        
 
        The forces due to this fix are imposed during an energy minimization,
 invoked by the minimize command.
diff --git a/doc/fix_enforce2d.txt b/doc/fix_enforce2d.txt
index 12fc0948a0..20bcf8f3c7 100644
--- a/doc/fix_enforce2d.txt
+++ b/doc/fix_enforce2d.txt
@@ -7,6 +7,7 @@
 :line
 
 fix enforce2d command :h3
+fix enforce2d/cuda command :h3
 
 [Syntax:]
 
@@ -25,14 +26,37 @@ Zero out the z-dimension velocity and force on each atom in the group.
 This is useful when running a 2d simulation to insure that atoms do
 not move from their initial z coordinate.
 
+:line
+
+Styles with a {cuda} 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
+"this section"_Section_accelerate.html of the manual.  The accelerated
+styles take the same arguments and should produce the same results,
+except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA package.  They are
+only enabled if LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restart, fix_modify, output, run start/stop, minimize info:]
 
 No information about this fix is written to "binary restart
 files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.  No global or per-atom quantities are stored
 by this fix for access by various "output
-commands"_Section_howto.html#4_15.  No parameter of this fix can be
-used with the {start/stop} keywords of the "run"_run.html command.
+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.
 
 The forces due to this fix are imposed during an energy minimization,
 invoked by the "minimize"_minimize.html command.
diff --git a/doc/fix_evaporate.html b/doc/fix_evaporate.html
index e533c51948..8ef4b2fab5 100644
--- a/doc/fix_evaporate.html
+++ b/doc/fix_evaporate.html
@@ -79,7 +79,7 @@ files.  None of the fix_modify options
 are relevant to this fix.
 
        
 
        This fix computes a global scalar, which can be accessed by various
-output commands.  The scalar is the
+output commands.  The scalar is the
 cummulative number of deleted atoms.  The scalar value calculated by
 this fix is "intensive".
 
        
diff --git a/doc/fix_evaporate.txt b/doc/fix_evaporate.txt
index 147fc14457..331accb887 100644
--- a/doc/fix_evaporate.txt
+++ b/doc/fix_evaporate.txt
@@ -68,7 +68,7 @@ files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.
 
 This fix computes a global scalar, which can be accessed by various
-"output commands"_Section_howto.html#4_15.  The scalar is the
+"output commands"_Section_howto.html#howto_15.  The scalar is the
 cummulative number of deleted atoms.  The scalar value calculated by
 this fix is "intensive".
 
diff --git a/doc/fix_external.html b/doc/fix_external.html
index fe57859db8..d08bffc4e6 100644
--- a/doc/fix_external.html
+++ b/doc/fix_external.html
@@ -64,9 +64,9 @@ quantum forces computed by a density functional code binary restart
 files.  None of the fix_modify options
 are relevant to this fix.  No global or per-atom quantities are stored
-by this fix for access by various output
-commands.  No parameter of this fix can be
-used with the start/stop keywords of the run command.
+by this fix for access by various output
+commands.  No parameter of this fix can
+be used with the start/stop keywords of the run command.
 
        
 
        The forces due to this fix are imposed during an energy minimization,
 invoked by the minimize command.  However, LAMMPS
diff --git a/doc/fix_external.txt b/doc/fix_external.txt
index 74c0b0b881..f8e12ded3a 100644
--- a/doc/fix_external.txt
+++ b/doc/fix_external.txt
@@ -62,8 +62,8 @@ No information about this fix is written to "binary restart
 files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.  No global or per-atom quantities are stored
 by this fix for access by various "output
-commands"_Section_howto.html#4_15.  No parameter of this fix can be
-used with the {start/stop} keywords of the "run"_run.html command.
+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.
 
 The forces due to this fix are imposed during an energy minimization,
 invoked by the "minimize"_minimize.html command.  However, LAMMPS
diff --git a/doc/fix_freeze.html b/doc/fix_freeze.html
index 55486a8268..762460f39d 100644
--- a/doc/fix_freeze.html
+++ b/doc/fix_freeze.html
@@ -11,6 +11,8 @@
 
 
        fix freeze command 
 
        
+
        fix freeze/cuda command 
+
        
 
        Syntax:
 
        
 
        fix ID group-ID freeze 
@@ -30,6 +32,29 @@ for preventing certain particles from moving in a simulation.  The
 defined and compute interactions between frozen and non-frozen
 particles appropriately, as if the frozen particle has infinite mass.
 
        
+
        
+
+
        Styles with a cuda 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
+this section of the manual.  The accelerated
+styles take the same arguments and should produce the same results,
+except for round-off and precision issues.
+
        
+
        These accelerated styles are part of the USER-CUDA package.  They are
+only enabled if LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
        
+
        You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
        
+
        See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
        
+
        
+
 
        Restart, fix_modify, output, run start/stop, minimize info:
 
        
 
        No information about this fix is written to binary restart
@@ -37,7 +62,7 @@ files.  None of the fix_modify options
 are relevant to this fix.
 
        
 
        This fix computes a global 3-vector of forces, which can be accessed
-by various output commands.  This is the
+by various output commands.  This is the
 total force on the group of atoms before the forces on individual
 atoms are changed by the fix.  The vector values calculated by this
 fix are "extensive".
@@ -48,8 +73,8 @@ minimization.
 
        
 
        Restrictions:
 
        
-
        This fix is part of the "granular" package.  It is only enabled if
-LAMMPS was built with that package.  See the Making
+
        This fix is part of the GRANULAR package.  It is only enabled if
+LAMMPS was built with that package.  See the Making
 LAMMPS section for more info.
 
        
 
        There can only be a single freeze fix defined.  This is because other
@@ -59,7 +84,7 @@ this fix is applied.
 
        
 
        Related commands: none
 
        
-
        atom_style granular
+
        atom_style sphere
 
        
 
        Default: none
 
        
diff --git a/doc/fix_freeze.txt b/doc/fix_freeze.txt
index 5f24eabd88..ac89b18190 100644
--- a/doc/fix_freeze.txt
+++ b/doc/fix_freeze.txt
@@ -7,6 +7,7 @@
 :line
 
 fix freeze command :h3
+fix freeze/cuda command :h3
 
 [Syntax:]
 
@@ -27,6 +28,29 @@ for preventing certain particles from moving in a simulation.  The
 defined and compute interactions between frozen and non-frozen
 particles appropriately, as if the frozen particle has infinite mass.
 
+:line
+
+Styles with a {cuda} 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
+"this section"_Section_accelerate.html of the manual.  The accelerated
+styles take the same arguments and should produce the same results,
+except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA package.  They are
+only enabled if LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restart, fix_modify, output, run start/stop, minimize info:]
 
 No information about this fix is written to "binary restart
@@ -34,7 +58,7 @@ files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.
 
 This fix computes a global 3-vector of forces, which can be accessed
-by various "output commands"_Section_howto.html#4_15.  This is the
+by various "output commands"_Section_howto.html#howto_15.  This is the
 total force on the group of atoms before the forces on individual
 atoms are changed by the fix.  The vector values calculated by this
 fix are "extensive".
@@ -45,9 +69,9 @@ minimization"_minimize.html.
 
 [Restrictions:]
 
-This fix is part of the "granular" package.  It is only enabled if
+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#2_3 section for more info.
+LAMMPS"_Section_start.html#start_3 section for more info.
 
 There can only be a single freeze fix defined.  This is because other
 the "granular pair styles"_pair_gran.html treat frozen particles
@@ -56,6 +80,6 @@ this fix is applied.
 
 [Related commands:] none
 
-"atom_style granular"_atom_style.html
+"atom_style sphere"_atom_style.html
 
 [Default:] none
diff --git a/doc/fix_gcmc.html b/doc/fix_gcmc.html
new file mode 100644
index 0000000000..2832f4f127
--- /dev/null
+++ b/doc/fix_gcmc.html
@@ -0,0 +1,187 @@
+
+
        LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
        
+
+
+
+
+
+
+
        
+
+
        fix gcmc command 
+
        
+
        Syntax:
+
        
+
        fix ID group-ID gcmc N X M type seed T mu displace keyword values ... 
+
        
+
        • ID, group-ID are documented in fix command 
+
+
        • gcmc = style name of this fix command 
+
+
        • N = invoke this fix every N steps 
+
+
        • X = number of exchanges to attempt every N steps 
+
+
        • M = number of MC displacements to attempt every N steps 
+
+
        • type = atom type of exchanged particles 
+
+
        • seed = random # seed (positive integer) 
+
+
        • T = temperature of the ideal gas reservoir (temperature units) 
+
+
        • mu = chemical potential of the ideal gas reservoir (energy units) 
+
+
        • displace = maximum Monte Carlo displacement distance (length units) 
+
+
        • zero or more keyword/value pairs may be appended to args 
+
+
          keyword = molecule
+  molecule value = no or yes 
+
          
+
+
        
+
        Examples:
+
        
+
        fix 2 all gcmc 10 1000 1000 2 29494 298.0 -0.5 0.01
+fix 3 all gcmc 10 100 100 1 3456543 3.0 -2.5 0.1 molecule yes 
+
        
+
        Description:
+
        
+
        This fix performs grand canonical Monte Carlo (GCMC) exchanges of
+particles of the given type with an imaginary ideal gas reservoir at
+the specified T and chemical potential (mu) as discussed in
+(Frenkel). If used with the fix nvt command,
+simulations in the grand canonical enemble (muVT, constant chemical
+potential, constant volume, and constant temperature) can be
+performed.  Specific uses include computing isotherms in microporous
+materials, or computing vapor-liquid coexistence curves.
+
        
+
        Perform up to X exchanges of particles of the given type between the
+simulation domain and the imaginary reservoir every N timesteps. Also
+perform M Monte Carlo displacements of particles of the given type
+within the simulation domain. M should typically be chosen to be
+approximately equal to the expected number of particles of the given
+type within the domain, which will result in roughly one MC
+translation per particle per MC cycle.
+
        
+
        This fix cannot be used to perform MC displacements of particles other
+than the exchanged type. All particles in the simulation domain can be
+moved using regular time integration displacements, e.g. via
+fix_nvt, resulting in a hybrid GCMC+MD simulation.
+
        
+
        If used with fix_nvt, the temperature of the imaginary
+reservoir, T, should be set to be equivalent to the target temperature
+used in fix_nvt. Otherwise, the imaginary reservoir
+will not be in thermal equilibrium with the simulation domain.
+
        
+
        Note that neighbor lists are re-built every timestep that this fix is
+invoked, so you should not set N to be too small.  However, periodic
+rebuilds are necessary in order to avoid dangerous rebuilds and missed
+interactions. Specifically, avoid performing so many MC displacements
+per timestep that a particle can move beyond the neighbor list skin
+distance. See the neighbor command for details.
+
        
+
        When a particle is to be inserted, its coordinates are chosen as a
+random position within the current simulation domain, and its velocity
+is randomly chosen from the specified temperature distribution given
+by T.
+
        
+
        Exchanged particles have the specified atom type and are assigned to
+two groups: the default group "all" and the group specified in the fix
+gcmc command (which can also be "all").
+
        
+
        If the setting for the molecule keyword is no, then only single
+atoms are exchanged.  In this case, you should ensure you do not
+delete only a portion of a molecule (only some of its atoms), or
+LAMMPS will soon generate an error when it tries to find those atoms.
+LAMMPS will warn you if any of the atoms eligible for deletion have a
+non-zero molecule ID, but does not check for this at the time of
+deletion.
+
        
+
        If the setting for the molecule keyword is yes, entire molecules
+are exchanged. This feature is not yet supported.
+
        
+
        Use of this fix typically will cause the number of atoms to fluctuate,
+therefore, you will want to use the
+compute_modify command to insure that the
+current number of atoms is used as a normalizing factor each time
+temperature is computed.  Here is the necessary command:
+
        
+
        compute_modify thermo_temp dynamic yes 
+
        
+
        If LJ units are used, note that a value of 0.18292026 is used by this
+fix as the reduced value for Planck's constant.  This value was
+derived from LJ paramters for argon, where h* = h/sqrt(sigma^2 *
+epsilon * mass), sigma = 3.429 angstroms, epsilon/k = 121.85 K, and
+mass = 39.948 amu.
+
        
+
        Restart, fix_modify, output, run start/stop, minimize info:
+
        
+
        This fix writes the state of the deposition to binary restart
+files.  This includes information about the random
+number generator seed, the next timestep for MC exchanges, etc.  See
+the read_restart 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.
+
        
+
        None of the fix_modify options are relevant to this
+fix.
+
        
+
        This fix computes a global vector of length 6, which can be accessed
+by various output commands.  The vector
+values are the following global cummulative quantities:
+
        
+
        • 1 = displacement attempts
+
        • 2 = displacement successes
+
        • 3 = deletion attempts
+
        • 4 = deletion successes
+
        • 5 = insertion attempts
+
        • 6 = insertion successes 
+
        
+
        The vector values calculated by this fix are "extensive".
+
        
+
        No parameter of this fix can be used with the start/stop keywords of
+the run command.  This fix is not invoked during energy
+minimization.
+
        
+
        Restrictions:
+
        
+
        This fix is part of the MC package.  It is only enabled if LAMMPS was
+built with that package.  See the Making
+LAMMPS section for more info.
+
        
+
        Do not set "neigh_modify once yes" or else this fix will never be
+called.  Reneighboring is required.
+
        
+
        You cannot currently exchange charged particles or molecules with a
+net charge.
+
        
+
        Only pairwise interactions, as defined by the
+pair_style command, are included in this
+calculation.  Long-range interactions due to a
+kspace_style command are not included.  Not all
+pair potentials can be evaluated in a pairwise mode as required by
+this fix.  For example, 3-body potentials, such as
+Tersoff and Stillinger-Weber cannot
+be used.  EAM potentials for metals only include the
+pair potential portion of the EAM interaction, not the embedding term.
+
        
+
        Related commands:
+
        
+
        fix_nvt, neighbor, 
+fix_deposit, fix_evaporate
+
        
+
        Default:
+
        
+
        The option defaults are molecule = no.
+
        
+
        
+
+
+
+
        (Frenkel) Frenkel and Smit, Understanding Molecular Simulation, 
+Academic Press, London, 2002.
+
        
+
diff --git a/doc/fix_gcmc.txt b/doc/fix_gcmc.txt
new file mode 100644
index 0000000000..e428e5c6aa
--- /dev/null
+++ b/doc/fix_gcmc.txt
@@ -0,0 +1,169 @@
+"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 gcmc command :h3
+
+[Syntax:]
+
+fix ID group-ID gcmc N X M type seed T mu displace keyword values ... :pre
+
+ID, group-ID are documented in "fix"_fix.html command :ulb,l
+gcmc = style name of this fix command :l
+N = invoke this fix every N steps :l
+X = number of exchanges to attempt every N steps :l
+M = number of MC displacements to attempt every N steps :l
+type = atom type of exchanged particles :l
+seed = random # seed (positive integer) :l
+T = temperature of the ideal gas reservoir (temperature units) :l
+mu = chemical potential of the ideal gas reservoir (energy units) :l
+displace = maximum Monte Carlo displacement distance (length units) :l
+zero or more keyword/value pairs may be appended to args :l
+keyword = {molecule}
+  {molecule} value = {no} or {yes} :pre
+:ule
+
+[Examples:]
+
+fix 2 all gcmc 10 1000 1000 2 29494 298.0 -0.5 0.01
+fix 3 all gcmc 10 100 100 1 3456543 3.0 -2.5 0.1 molecule yes :pre
+
+[Description:]
+
+This fix performs grand canonical Monte Carlo (GCMC) exchanges of
+particles of the given type with an imaginary ideal gas reservoir at
+the specified T and chemical potential (mu) as discussed in
+"(Frenkel)"_#Frenkel. If used with the "fix nvt"_fix_nh.html command,
+simulations in the grand canonical enemble (muVT, constant chemical
+potential, constant volume, and constant temperature) can be
+performed.  Specific uses include computing isotherms in microporous
+materials, or computing vapor-liquid coexistence curves.
+
+Perform up to X exchanges of particles of the given type between the
+simulation domain and the imaginary reservoir every N timesteps. Also
+perform M Monte Carlo displacements of particles of the given type
+within the simulation domain. M should typically be chosen to be
+approximately equal to the expected number of particles of the given
+type within the domain, which will result in roughly one MC
+translation per particle per MC cycle.
+
+This fix cannot be used to perform MC displacements of particles other
+than the exchanged type. All particles in the simulation domain can be
+moved using regular time integration displacements, e.g. via
+"fix_nvt"_fix_nvt.html, resulting in a hybrid GCMC+MD simulation.
+
+If used with "fix_nvt"_fix_nvt.html, the temperature of the imaginary
+reservoir, T, should be set to be equivalent to the target temperature
+used in "fix_nvt"_fix_nvt.html. Otherwise, the imaginary reservoir
+will not be in thermal equilibrium with the simulation domain.
+
+Note that neighbor lists are re-built every timestep that this fix is
+invoked, so you should not set N to be too small.  However, periodic
+rebuilds are necessary in order to avoid dangerous rebuilds and missed
+interactions. Specifically, avoid performing so many MC displacements
+per timestep that a particle can move beyond the neighbor list skin
+distance. See the "neighbor"_neighbor.html command for details.
+
+When a particle is to be inserted, its coordinates are chosen as a
+random position within the current simulation domain, and its velocity
+is randomly chosen from the specified temperature distribution given
+by T.
+
+Exchanged particles have the specified atom type and are assigned to
+two groups: the default group "all" and the group specified in the fix
+gcmc command (which can also be "all").
+
+If the setting for the {molecule} keyword is {no}, then only single
+atoms are exchanged.  In this case, you should ensure you do not
+delete only a portion of a molecule (only some of its atoms), or
+LAMMPS will soon generate an error when it tries to find those atoms.
+LAMMPS will warn you if any of the atoms eligible for deletion have a
+non-zero molecule ID, but does not check for this at the time of
+deletion.
+
+If the setting for the {molecule} keyword is {yes}, entire molecules
+are exchanged. This feature is not yet supported.
+
+Use of this fix typically will cause the number of atoms to fluctuate,
+therefore, you will want to use the
+"compute_modify"_compute_modify.html command to insure that the
+current number of atoms is used as a normalizing factor each time
+temperature is computed.  Here is the necessary command:
+
+compute_modify thermo_temp dynamic yes :pre
+
+If LJ units are used, note that a value of 0.18292026 is used by this
+fix as the reduced value for Planck's constant.  This value was
+derived from LJ paramters for argon, where h* = h/sqrt(sigma^2 *
+epsilon * mass), sigma = 3.429 angstroms, epsilon/k = 121.85 K, and
+mass = 39.948 amu.
+
+[Restart, fix_modify, output, run start/stop, minimize info:]
+
+This fix writes the state of the deposition to "binary restart
+files"_restart.html.  This includes information about the random
+number generator seed, the next timestep for MC exchanges, etc.  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.
+
+None of the "fix_modify"_fix_modify.html options are relevant to this
+fix.
+
+This fix computes a global vector of length 6, which can be accessed
+by various "output commands"_Section_howto.html#howto_15.  The vector
+values are the following global cummulative quantities:
+
+1 = displacement attempts
+2 = displacement successes
+3 = deletion attempts
+4 = deletion successes
+5 = insertion attempts
+6 = insertion successes :ul
+
+The vector values calculated by this fix are "extensive".
+
+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 MC 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.
+
+Do not set "neigh_modify once yes" or else this fix will never be
+called.  Reneighboring is required.
+
+You cannot currently exchange charged particles or molecules with a
+net charge.
+
+Only pairwise interactions, as defined by the
+"pair_style"_pair_style.html command, are included in this
+calculation.  Long-range interactions due to a
+"kspace_style"_kspace_style.html command are not included.  Not all
+pair potentials can be evaluated in a pairwise mode as required by
+this fix.  For example, 3-body potentials, such as
+"Tersoff"_pair_tersoff.html and "Stillinger-Weber"_pair_sw.html cannot
+be used.  "EAM"_pair_eam.html potentials for metals only include the
+pair potential portion of the EAM interaction, not the embedding term.
+
+[Related commands:]
+
+"fix_nvt"_fix_nvt.html, "neighbor"_neighbor.html, 
+"fix_deposit"_fix_deposit.html, "fix_evaporate"_fix_evaporate.html
+
+[Default:]
+
+The option defaults are molecule = no.
+
+:line
+
+:link(Frenkel)
+[(Frenkel)] Frenkel and Smit, Understanding Molecular Simulation, 
+Academic Press, London, 2002.
diff --git a/doc/fix_gpu.html b/doc/fix_gpu.html
deleted file mode 100644
index 72839bc0d1..0000000000
--- a/doc/fix_gpu.html
+++ /dev/null
@@ -1,107 +0,0 @@
-
-
        LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
-
        
-
-
-
-
-
-
-
        
-
-
        fix gpu command 
-
        
-
        Syntax:
-
        
-
        fix ID group-ID gpu mode first last split 
-
        
-
        • ID, group-ID are documented in fix command 
-
-
        • gpu = style name of this fix command 
-
-
        • mode = force or force/neigh 
-
-
        • first = ID of first GPU to be used on each node 
-
-
        • last = ID of last GPU to be used on each node 
-
-
        • split = fraction of particles assigned to the GPU 
-
-
-
        
-
        Examples:
-
        
-
        fix 0 all gpu force 0 0 1.0
-fix 0 all gpu force 0 0 0.75
-fix 0 all gpu force/neigh 0 0 1.0
-fix 0 all gpu force/neigh 0 1 -1.0 
-
        
-
        Description:
-
        
-
        Select and initialize GPUs to be used for acceleration and configure
-GPU acceleration in LAMMPS. This fix is required in order to use
-any style with GPU acceleration. The fix must be the first fix
-specified for a run or an error will be generated. The fix will not have an 
-effect on any LAMMPS computations that do not use GPU acceleration, so there 
-should not be any problems with specifying this fix first in input scripts.
-
        
-
        mode specifies where neighbor list calculations will be performed.
-If mode is force, neighbor list calculation is performed on the
-CPU. If mode is force/neigh, neighbor list calculation is 
-performed on the GPU. GPU neighbor
-list calculation currently cannot be used with a triclinic box.
-GPU neighbor lists are not compatible with styles that are not GPU-enabled.
-When a non-GPU enabled style requires a neighbor list, it will also be
-built using CPU routines. In these cases, it will typically be more efficient
-to only use CPU neighbor list builds. For hybrid pair
-styles, GPU calculated neighbor lists might be less efficient because
-no particles will be skipped in a given neighbor list.
-
        
-
        first and last specify the GPUs that will be used for simulation.
-On each node, the GPU IDs in the inclusive range from first to last will
-be used.
-
        
-
        split can be used for load balancing force calculation work between
-CPU and GPU cores in GPU-enabled pair styles. If 0<split<1.0, 
-a fixed fraction of particles is offloaded to the GPU while force calculation
-for the other particles occurs simulataneously on the CPU. If split<0,
-the optimal fraction (based on CPU and GPU timings) is calculated
-every 25 timesteps. If split=1.0, all force calculations for 
-GPU accelerated pair styles are performed
-on the GPU. In this case, hybrid, 
-bond, angle, 
-dihedral, improper, 
-and long-range calculations can be performed on the CPU 
-while the GPU is performing force calculations for the GPU-enabled pair
-style.
-
        
-
        In order to use GPU acceleration, a GPU enabled style must be
-selected in the input script in addition to this fix. Currently,
-this is limited to a few pair styles.
-
        
-
        More details about these settings and various possible hardware
-configuration are in this section of the
-manual.
-
        
-
        Restart, fix_modify, output, run start/stop, minimize info:
-
        
-
        No information about this fix is written to binary restart
-files.  None of the fix_modify options
-are relevant to this fix.
-
        
-
        No parameter of this fix can be used with the start/stop keywords of
-the run command.
-
        
-
        Restrictions: 
-
        
-
        The fix must be the first fix specified for a given run. The force/neigh
-mode should not be used with a triclinic box or GPU-enabled pair styles
-that need special_bonds settings.
-
        
-
        Currently, group-ID must be all.
-
        
-
        Related commands: none
-
        
-
        Default: none
-
        
-
diff --git a/doc/fix_gpu.txt b/doc/fix_gpu.txt
deleted file mode 100644
index 88fa6f5414..0000000000
--- a/doc/fix_gpu.txt
+++ /dev/null
@@ -1,97 +0,0 @@
-"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
-
-:link(lws,http://lammps.sandia.gov)
-:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
-
-:line
-
-fix gpu command :h3
-
-[Syntax:]
-
-fix ID group-ID gpu mode first last split :pre
-
-ID, group-ID are documented in "fix"_fix.html command :ulb,l
-gpu = style name of this fix command :l
-mode = force or force/neigh :l
-first = ID of first GPU to be used on each node :l
-last = ID of last GPU to be used on each node :l
-split = fraction of particles assigned to the GPU :l
-:ule
-
-[Examples:]
-
-fix 0 all gpu force 0 0 1.0
-fix 0 all gpu force 0 0 0.75
-fix 0 all gpu force/neigh 0 0 1.0
-fix 0 all gpu force/neigh 0 1 -1.0 :pre
-
-[Description:]
-
-Select and initialize GPUs to be used for acceleration and configure
-GPU acceleration in LAMMPS. This fix is required in order to use
-any style with GPU acceleration. The fix must be the first fix
-specified for a run or an error will be generated. The fix will not have an 
-effect on any LAMMPS computations that do not use GPU acceleration, so there 
-should not be any problems with specifying this fix first in input scripts.
-
-{mode} specifies where neighbor list calculations will be performed.
-If {mode} is force, neighbor list calculation is performed on the
-CPU. If {mode} is force/neigh, neighbor list calculation is 
-performed on the GPU. GPU neighbor
-list calculation currently cannot be used with a triclinic box.
-GPU neighbor lists are not compatible with styles that are not GPU-enabled.
-When a non-GPU enabled style requires a neighbor list, it will also be
-built using CPU routines. In these cases, it will typically be more efficient
-to only use CPU neighbor list builds. For "hybrid"_pair_hybrid.html pair
-styles, GPU calculated neighbor lists might be less efficient because
-no particles will be skipped in a given neighbor list.
-
-{first} and {last} specify the GPUs that will be used for simulation.
-On each node, the GPU IDs in the inclusive range from {first} to {last} will
-be used.
-
-{split} can be used for load balancing force calculation work between
-CPU and GPU cores in GPU-enabled pair styles. If 0<{split}<1.0, 
-a fixed fraction of particles is offloaded to the GPU while force calculation
-for the other particles occurs simulataneously on the CPU. If {split}<0,
-the optimal fraction (based on CPU and GPU timings) is calculated
-every 25 timesteps. If {split}=1.0, all force calculations for 
-GPU accelerated pair styles are performed
-on the GPU. In this case, "hybrid"_pair_hybrid.html, 
-"bond"_bond_style.html, "angle"_angle_style.html, 
-"dihedral"_dihedral_style.html, "improper"_improper_style.html, 
-and "long-range"_kspace_style.html calculations can be performed on the CPU 
-while the GPU is performing force calculations for the GPU-enabled pair
-style.
-
-In order to use GPU acceleration, a GPU enabled style must be
-selected in the input script in addition to this fix. Currently,
-this is limited to a few "pair styles"_pair_style.html.
-
-More details about these settings and various possible hardware
-configuration are in "this section"_Section_start.html#2_8 of the
-manual.
-
-[Restart, fix_modify, output, run start/stop, minimize info:]
-
-No information about this fix is written to "binary restart
-files"_restart.html.  None of the "fix_modify"_fix_modify.html options
-are relevant to this fix.
-
-No parameter of this fix can be used with the {start/stop} keywords of
-the "run"_run.html command.
-
-[Restrictions:] 
-
-The fix must be the first fix specified for a given run. The force/neigh
-{mode} should not be used with a triclinic box or GPU-enabled pair styles
-that need "special_bonds"_special_bonds.html settings.
-
-Currently, group-ID must be all.
-
-[Related commands:] none
-
-[Default:] none
-
diff --git a/doc/fix_gravity.html b/doc/fix_gravity.html
index 0a823a51df..fbc2fce7f3 100644
--- a/doc/fix_gravity.html
+++ b/doc/fix_gravity.html
@@ -11,6 +11,10 @@
 
 
        fix gravity command 
 
        
+
        fix gravity/cuda command 
+
        
+
        fix gravity/omp command 
+
        
 
        Syntax:
 
        
 
        fix ID group gravity style magnitude args 
@@ -85,21 +89,56 @@ For 2d systems, phi and phi_grad are ignored.
 
        Style vector imposes an acceleration in the vector direction given
 by (x,y,z).  For 2d systems, the z component is ignored.
 
        
+
        
+
+
        Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
        
+
        These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
        
+
        You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
        
+
        See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
        
+
        
+
 
        Restart, fix_modify, output, run start/stop, minimize info:
 
        
 
        No information about this fix is written to binary restart
-files.  None of the fix_modify options
-are relevant to this fix.  No global or per-atom quantities are stored
-by this fix for access by various output
-commands.  No parameter of this fix can be
-used with the start/stop keywords of the run command.
-This fix is not invoked during energy minimization.
+files.  
+
        
+
        The fix_modify energy option is supported by this
+fix to add the gravitational potential energy of the system to the
+system's potential energy as part of thermodynamic
+output.
+
        
+
        This fix computes a global scalar which can be accessed by various
+output commands.  This scalar is the
+gravitational potential energy of the particles in the defined field,
+namely mass * (g dot x) for each particles, where x and mass are the
+particles position and mass, and g is the gravitational field.  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 command.  This fix is not invoked during energy
+minimization.
 
        
 
        Restrictions: none
 
        
 
        Related commands:
 
        
-
        atom_style granular, fix addforce
+
        atom_style sphere, fix addforce
 
        
 
        Default: none
 
        
diff --git a/doc/fix_gravity.txt b/doc/fix_gravity.txt
index 86184a4d01..bad5edc997 100644
--- a/doc/fix_gravity.txt
+++ b/doc/fix_gravity.txt
@@ -7,6 +7,8 @@
 :line
 
 fix gravity command :h3
+fix gravity/cuda command :h3
+fix gravity/omp command :h3
 
 [Syntax:]
 
@@ -77,20 +79,55 @@ For 2d systems, {phi} and {phi_grad} are ignored.
 Style {vector} imposes an acceleration in the vector direction given
 by (x,y,z).  For 2d systems, the z component is ignored.
 
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restart, fix_modify, output, run start/stop, minimize info:]
 
 No information about this fix is written to "binary restart
-files"_restart.html.  None of the "fix_modify"_fix_modify.html options
-are relevant to this fix.  No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#4_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.
+files"_restart.html.  
+
+The "fix_modify"_fix_modify.html {energy} option is supported by this
+fix to add the gravitational potential energy of the system to the
+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.  This scalar is the
+gravitational potential energy of the particles in the defined field,
+namely mass * (g dot x) for each particles, where x and mass are the
+particles position and mass, and g is the gravitational field.  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.  This fix is not invoked during "energy
+minimization"_minimize.html.
 
 [Restrictions:] none
 
 [Related commands:]
 
-"atom_style granular"_atom_style.html, "fix addforce"_fix_addforce.html
+"atom_style sphere"_atom_style.html, "fix addforce"_fix_addforce.html
 
 [Default:] none
diff --git a/doc/fix_heat.html b/doc/fix_heat.html
index 293e131e73..e871f5f484 100644
--- a/doc/fix_heat.html
+++ b/doc/fix_heat.html
@@ -84,8 +84,8 @@ files.  None of the fix_modify options
 are relevant to this fix.
 
        
 
        This fix computes a global scalar which can be accessed by various
-output commands.  This scalar is the most
-recent value by which velocites were scaled.  The scalar value
+output commands.  This scalar is the
+most recent value by which velocites were scaled.  The scalar value
 calculated by this fix is "intensive".
 
        
 
        No parameter of this fix can be used with the start/stop keywords of
diff --git a/doc/fix_heat.txt b/doc/fix_heat.txt
index 9848ccb54e..b6c3ee3560 100644
--- a/doc/fix_heat.txt
+++ b/doc/fix_heat.txt
@@ -74,8 +74,8 @@ files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.
 
 This fix computes a global scalar which can be accessed by various
-"output commands"_Section_howto.html#4_15.  This scalar is the most
-recent value by which velocites were scaled.  The scalar value
+"output commands"_Section_howto.html#howto_15.  This scalar is the
+most recent value by which velocites were scaled.  The scalar value
 calculated by this fix is "intensive".
 
 No parameter of this fix can be used with the {start/stop} keywords of
diff --git a/doc/fix_imd.html b/doc/fix_imd.html
index 454e24bc50..1d89148879 100644
--- a/doc/fix_imd.html
+++ b/doc/fix_imd.html
@@ -43,9 +43,23 @@ fix comm all imd 8888 trate 5 unwrap on fscale 10.0
 
        Description:
 
        
 
        This fix implements the "Interactive MD" (IMD) protocol which allows
-to connect an IMD client, for example the VMD visualization
-program, to a running LAMMPS simulation and monitor the progress
-of the simulation and interactively apply forces to selected atoms.
+realtime visualization and manipulation of MD simulations through the
+IMD protocol, as initially implemented in VMD and NAMD.  Specifically
+it allows LAMMPS to connect an IMD client, for example the VMD
+visualization program, so that it can monitor the progress of the
+simulation and interactively apply forces to selected atoms.
+
        
+
        If LAMMPS is compiled with the preprocessor flag -DLAMMPS_ASYNC_IMD
+then fix imd will use POSIX threads to spawn a IMD communication
+thread on MPI rank 0 in order to offload data reading and writing
+from the main execution thread and potentially lower the inferred
+latencies for slow communication links. This feature has only been
+tested under linux.
+
        
+
        There are example scripts for using this package with LAMMPS in
+examples/USER/imd. Additional examples and a driver for use with the
+Novint Falcon game controller as haptic device can be found at:
+http://sites.google.com/site/akohlmey/software/vrpn-icms.
 
        
 
        The source code for this fix includes code developed by the
 Theoretical and Computational Biophysics Group in the Beckman
@@ -109,10 +123,12 @@ forces to whole residues or fragments. Your mouse can now be used to
 apply forces to your simulation. Click on an atom, residue, or
 fragment and drag to apply a force. Click quickly without moving the
 mouse to turn the force off. You can also use a variety of 3D position
-trackers to apply forces to your simulation. Trackers with
-force-feedback such as the Sensable PHANTOM allow you to feel the
-forces you are applying to your molecules, as if they were real
-objects. See the VMD IMD Homepage for more details.
+trackers to apply forces to your simulation. Game controllers or haptic
+devices with force-feedback such as the Novint Falcon or Sensable 
+PHANTOM allow you to feel the resistance due to inertia or interactions
+with neighbors that the atoms experience you are trying to move, as if 
+they were real objects. See the VMD IMD Homepage and the 
+VRPN-ICMS Homepage for more details.
 
        
 
        If IMD control messages are received, a line of text describing the
 message and its effect will be printed to the LAMMPS output screen, if
@@ -122,20 +138,22 @@ screen output is active.
 
 
 
+
+
 
        Restart, fix_modify, output, run start/stop, minimize info:
 
        
 
        No information about this fix is written to binary restart
 files.  None of the fix_modify options
 are relevant to this fix.  No global scalar or vector or per-atom
-quantities are stored by this fix for access by various output
-commands.  No parameter of this fix can be
-used with the start/stop keywords of the run command.
+quantities are stored by this fix for access by various output
+commands.  No parameter of this fix can
+be used with the start/stop keywords of the run command.
 This fix is not invoked during energy minimization.
 
        
 
        Restrictions:
 
        
-
        This fix is part of the "user-imd" package.  It is only enabled if
-LAMMPS was built with that package.  See the Making
+
        This fix is part of the USER-MISC package.  It is only enabled if
+LAMMPS was built with that package.  See the Making
 LAMMPS section for more info.
 
        
 
        When used in combination with VMD, a topology or coordinate file has
diff --git a/doc/fix_imd.txt b/doc/fix_imd.txt
index b1125cbd19..283755a796 100644
--- a/doc/fix_imd.txt
+++ b/doc/fix_imd.txt
@@ -35,9 +35,23 @@ fix comm all imd 8888 trate 5 unwrap on fscale 10.0 :pre
 [Description:]
 
 This fix implements the "Interactive MD" (IMD) protocol which allows
-to connect an IMD client, for example the "VMD visualization
-program"_VMD, to a running LAMMPS simulation and monitor the progress
-of the simulation and interactively apply forces to selected atoms.
+realtime visualization and manipulation of MD simulations through the
+IMD protocol, as initially implemented in VMD and NAMD.  Specifically
+it allows LAMMPS to connect an IMD client, for example the "VMD
+visualization program"_VMD, so that it can monitor the progress of the
+simulation and interactively apply forces to selected atoms.
+
+If LAMMPS is compiled with the preprocessor flag -DLAMMPS_ASYNC_IMD
+then fix imd will use POSIX threads to spawn a IMD communication
+thread on MPI rank 0 in order to offload data reading and writing
+from the main execution thread and potentially lower the inferred
+latencies for slow communication links. This feature has only been
+tested under linux.
+
+There are example scripts for using this package with LAMMPS in
+examples/USER/imd. Additional examples and a driver for use with the
+Novint Falcon game controller as haptic device can be found at:
+http://sites.google.com/site/akohlmey/software/vrpn-icms.
 
 The source code for this fix includes code developed by the
 Theoretical and Computational Biophysics Group in the Beckman
@@ -101,17 +115,20 @@ forces to whole residues or fragments. Your mouse can now be used to
 apply forces to your simulation. Click on an atom, residue, or
 fragment and drag to apply a force. Click quickly without moving the
 mouse to turn the force off. You can also use a variety of 3D position
-trackers to apply forces to your simulation. Trackers with
-force-feedback such as the Sensable PHANTOM allow you to feel the
-forces you are applying to your molecules, as if they were real
-objects. See the "VMD IMD Homepage"_imdvmd for more details.
+trackers to apply forces to your simulation. Game controllers or haptic
+devices with force-feedback such as the Novint Falcon or Sensable 
+PHANTOM allow you to feel the resistance due to inertia or interactions
+with neighbors that the atoms experience you are trying to move, as if 
+they were real objects. See the "VMD IMD Homepage"_imdvmd and the 
+"VRPN-ICMS Homepage"_vrpnicms for more details.
 
 If IMD control messages are received, a line of text describing the
 message and its effect will be printed to the LAMMPS output screen, if
 screen output is active.
 
-:link(VMD,http://www.ks.uiuc.edu/Research/vmd)x
+:link(VMD,http://www.ks.uiuc.edu/Research/vmd)
 :link(imdvmd,http://www.ks.uiuc.edu/Research/vmd/imd/) 
+:link(vrpnicms,http://sites.google.com/site/akohlmey/software/vrpn-icms) 
 
 [Restart, fix_modify, output, run start/stop, minimize info:]
 
@@ -119,15 +136,15 @@ No information about this fix is written to "binary restart
 files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.  No global scalar or vector or per-atom
 quantities are stored by this fix for access by various "output
-commands"_Section_howto.html#4_15.  No parameter of this fix can be
-used with the {start/stop} keywords of the "run"_run.html command.
+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 "user-imd" package.  It is only enabled if
+This fix is part of the USER-MISC package.  It is only enabled if
 LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+LAMMPS"_Section_start.html#start_3 section for more info.
 
 When used in combination with VMD, a topology or coordinate file has
 to be loaded, which matches (in number and ordering of atoms) the
diff --git a/doc/fix_indent.html b/doc/fix_indent.html
index b23d54a11f..4e77d2e948 100644
--- a/doc/fix_indent.html
+++ b/doc/fix_indent.html
@@ -183,7 +183,7 @@ output.  The energy of each particle interacting
 with the indenter is K/3 (r - R)^3.
 
        
 
        This fix computes a global scalar energy and a global 3-vector of
-forces (on the indenter), which can be accessed by various output
+forces (on the indenter), which can be accessed by various output
 commands.  The scalar and vector values
 calculated by this fix are "extensive".
 
        
diff --git a/doc/fix_indent.txt b/doc/fix_indent.txt
index 3f4983f264..27f33125d2 100644
--- a/doc/fix_indent.txt
+++ b/doc/fix_indent.txt
@@ -175,7 +175,7 @@ with the indenter is K/3 (r - R)^3.
 
 This fix computes a global scalar energy and a global 3-vector of
 forces (on the indenter), which can be accessed by various "output
-commands"_Section_howto.html#4_15.  The scalar and vector values
+commands"_Section_howto.html#howto_15.  The scalar and vector values
 calculated by this fix are "extensive".
 
 The forces due to this fix are imposed during an energy minimization,
diff --git a/doc/fix_langevin.html b/doc/fix_langevin.html
index 8d54104a71..d19ae2ff44 100644
--- a/doc/fix_langevin.html
+++ b/doc/fix_langevin.html
@@ -21,19 +21,31 @@
 
 
      • Tstart,Tstop = desired temperature at start/end of run (temperature units) 
 
+
          Tstart can be a variable (see below) 
+
        
 
      • damp = damping parameter (time units) 
 
 
      • seed = random number seed to use for white noise (positive integer) 
 
 
      • zero or more keyword/value pairs may be appended 
 
-
        keyword = scale or tally
+
      • keyword = angmom or omega or scale or tally or zero 
+
+
          angmom value = no or yes
+    no = do not thermostat rotational degrees of freedom via the angular momentum
+    yes = do thermostat rotational degrees of freedom via the angular momentum
+  omega value = no or yes
+    no = do not thermostat rotational degrees of freedom via the angular velocity
+    yes = do thermostat rotational degrees of freedom via the angular velocity
   scale values = type ratio
     type = atom type (1-N)
     ratio = factor by which to scale the damping coefficient
-  tally values = no or yes
+  tally value = no or yes
     no = do not tally the energy added/subtracted to atoms
-    yes = do tally the energy added/subtracted to atoms 
+    yes = do tally the energy added/subtracted to atoms
+  zero value = no or yes
+    no = do not set total random force to zero
+    yes = set total random force to zero 
 
        
 
 
      
@@ -96,13 +108,30 @@ should not normally be used on atoms that also have their temperature
 controlled by another fix - e.g. by fix nvt or fix
 temp/rescale commands.
 
      
-
      See this howto section of the manual for a
-discussion of different ways to compute temperature and perform
+
      See this howto section of the manual for
+a discussion of different ways to compute temperature and perform
 thermostatting.
 
      
 
      The desired temperature at each timestep is a ramped value during the
 run from Tstart to Tstop.
 
      
+
      Tstart can be specified as an equal-style or atom-style
+variable.  In this case, the Tstop setting is
+ignored.  If the value is a variable, it should be specified as
+v_name, where name is the variable name.  In this case, the variable
+will be evaluated each timestep, and its value used to determine the
+target temperature.
+
      
+
      Equal-style variables can specify formulas with various mathematical
+functions, and include thermo_style command
+keywords for the simulation box parameters and timestep and elapsed
+time.  Thus it is easy to specify a time-dependent temperature.
+
      
+
      Atom-style variables can specify the same formulas as equal-style
+variables but can also include per-atom values, such as atom
+coordinates.  Thus it is easy to specify a spatially-dependent
+temperature with optional time-dependence as well.
+
      
 
      Like other fixes that perform thermostatting, this fix can be used
 with compute commands that remove a "bias" from the
 atom velocities.  E.g. removing the center-of-mass velocity from a
@@ -132,6 +161,25 @@ generate its own unique seed and its own stream of random numbers.
 Thus the dynamics of the system will not be identical on two runs on
 different numbers of processors.
 
      
+
      
+
+
      The keyword/value option pairs are used in the following ways.
+
      
+
      The keyword angmom and omega keywords enable thermostatting of
+rotational degrees of freedom in addition to the usual translational
+degrees of freedom.  This can only be done for finite-size particles.
+A simulation using atom_style sphere defines an omega for finite-size
+spheres.  A simulation using atom_style ellipsoid defines a finite
+size and shape for aspherical particles and an angular momentum.  The
+Langevin formulas for thermostatting the rotational degrees of freedom
+are the same as those above, where force is replaced by torque, m is
+replaced by the moment of inertia I, and v is replaced by omega (which
+is derived from the angular momentum in the case of aspherical
+particles).  The rotational temperature of the particles can be
+monitored by the compute temp/sphere and
+compute temp/asphere commands with their
+rotate options.
+
      
 
      The keyword scale allows the damp factor to be scaled up or down by
 the specified factor for atoms of that type.  This can be useful when
 different atom types have different sizes or masses.  It can be used
@@ -146,13 +194,25 @@ particle mass in Ff, unlike fix viscous.  Thus the mass and size of
 different atom types should be accounted for in the choice of ratio
 values.
 
      
-
      The keyword tally enables the calculation of the cummulative energy
+
      The keyword tally enables the calculation of the cumulative energy
 added/subtracted to the atoms as they are thermostatted.  Effectively
 it is the energy exchanged between the infinite thermal reservoir and
 the particles.  As described below, this energy can then be printed
 out or added to the potential energy of the system to monitor energy
 conservation.
 
      
+
      The keyword zero can be used to eliminate drift due to the
+thermostat. Because the random forces on different atoms are
+independent, they do not sum exactly to zero.  As a result, this fix
+applies a small random force to the entire system, and the
+center-of-mass of the system undergoes a slow random walk.  If the
+keyword zero is set to yes, the total random force is set exactly
+to zero by subtracting off an equal part of it from each atom in the
+group.  As a result, the center-of-mass of a system with zero initial
+momentum will not drift over time.
+
      
+
      
+
 
      Restart, fix_modify, output, run start/stop, minimize info:
 
      
 
      No information about this fix is written to binary restart
@@ -175,7 +235,7 @@ output.  Note that use of this option requires
 setting the tally keyword to yes.
 
      
 
      This fix computes a global scalar which can be accessed by various
-output commands.  The scalar is the
+output commands.  The scalar is the
 cummulative energy change due to this fix.  The scalar value
 calculated by this fix is "extensive".  Note that calculation of this
 quantity requires setting the tally keyword to yes.
@@ -196,7 +256,8 @@ dpd/tstat
 
      
 
      Default:
 
      
-
      The option defaults are scale = 1.0 for all types and tally = no.
+
      The option defaults are angmom = no, omega = no, scale = 1.0 for all
+types, tally = no, zero = no.
 
      
 
      
 
diff --git a/doc/fix_langevin.txt b/doc/fix_langevin.txt
index f693f7fbc2..085bcdccd6 100644
--- a/doc/fix_langevin.txt
+++ b/doc/fix_langevin.txt
@@ -15,16 +15,26 @@ fix ID group-ID langevin Tstart Tstop damp seed keyword values ... :pre
 ID, group-ID are documented in "fix"_fix.html command :ulb,l
 langevin = style name of this fix command :l
 Tstart,Tstop = desired temperature at start/end of run (temperature units) :l
+  Tstart can be a variable (see below) :pre
 damp = damping parameter (time units) :l
 seed = random number seed to use for white noise (positive integer) :l
 zero or more keyword/value pairs may be appended :l
-keyword = {scale} or {tally}
+keyword = {angmom} or {omega} or {scale} or {tally} or {zero} :l
+  {angmom} value = {no} or {yes}
+    {no} = do not thermostat rotational degrees of freedom via the angular momentum
+    {yes} = do thermostat rotational degrees of freedom via the angular momentum
+  {omega} value = {no} or {yes}
+    {no} = do not thermostat rotational degrees of freedom via the angular velocity
+    {yes} = do thermostat rotational degrees of freedom via the angular velocity
   {scale} values = type ratio
     type = atom type (1-N)
     ratio = factor by which to scale the damping coefficient
-  {tally} values = {no} or {yes}
+  {tally} value = {no} or {yes}
     {no} = do not tally the energy added/subtracted to atoms
-    {yes} = do tally the energy added/subtracted to atoms :pre
+    {yes} = do tally the energy added/subtracted to atoms
+  {zero} value = {no} or {yes}
+    {no} = do not set total random force to zero
+    {yes} = set total random force to zero :pre
 :ule
 
 [Examples:]
@@ -86,13 +96,30 @@ should not normally be used on atoms that also have their temperature
 controlled by another fix - e.g. by "fix nvt"_fix_nh.html or "fix
 temp/rescale"_fix_temp_rescale.html commands.
 
-See "this howto section"_Section_howto.html#4_16 of the manual for a
-discussion of different ways to compute temperature and perform
+See "this howto section"_Section_howto.html#howto_16 of the manual for
+a discussion of different ways to compute temperature and perform
 thermostatting.
 
 The desired temperature at each timestep is a ramped value during the
 run from {Tstart} to {Tstop}.
 
+{Tstart} can be specified as an equal-style or atom-style
+"variable"_variable.html.  In this case, the {Tstop} setting is
+ignored.  If the value is a variable, it should be specified as
+v_name, where name is the variable name.  In this case, the variable
+will be evaluated each timestep, and its value used to determine the
+target temperature.
+
+Equal-style variables can specify formulas with various mathematical
+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 temperature.
+
+Atom-style variables can specify the same formulas as equal-style
+variables but can also include per-atom values, such as atom
+coordinates.  Thus it is easy to specify a spatially-dependent
+temperature with optional time-dependence as well.
+
 Like other fixes that perform thermostatting, this fix can be used
 with "compute commands"_compute.html that remove a "bias" from the
 atom velocities.  E.g. removing the center-of-mass velocity from a
@@ -122,6 +149,25 @@ generate its own unique seed and its own stream of random numbers.
 Thus the dynamics of the system will not be identical on two runs on
 different numbers of processors.
 
+:line
+
+The keyword/value option pairs are used in the following ways.
+
+The keyword {angmom} and {omega} keywords enable thermostatting of
+rotational degrees of freedom in addition to the usual translational
+degrees of freedom.  This can only be done for finite-size particles.
+A simulation using atom_style sphere defines an omega for finite-size
+spheres.  A simulation using atom_style ellipsoid defines a finite
+size and shape for aspherical particles and an angular momentum.  The
+Langevin formulas for thermostatting the rotational degrees of freedom
+are the same as those above, where force is replaced by torque, m is
+replaced by the moment of inertia I, and v is replaced by omega (which
+is derived from the angular momentum in the case of aspherical
+particles).  The rotational temperature of the particles can be
+monitored by the "compute temp/sphere"_compute_temp_sphere.html and
+"compute temp/asphere"_compute_temp_asphere.html commands with their
+rotate options.
+
 The keyword {scale} allows the damp factor to be scaled up or down by
 the specified factor for atoms of that type.  This can be useful when
 different atom types have different sizes or masses.  It can be used
@@ -136,13 +182,25 @@ particle mass in Ff, unlike fix {viscous}.  Thus the mass and size of
 different atom types should be accounted for in the choice of ratio
 values.
 
-The keyword {tally} enables the calculation of the cummulative energy
+The keyword {tally} enables the calculation of the cumulative energy
 added/subtracted to the atoms as they are thermostatted.  Effectively
 it is the energy exchanged between the infinite thermal reservoir and
 the particles.  As described below, this energy can then be printed
 out or added to the potential energy of the system to monitor energy
 conservation.
 
+The keyword {zero} can be used to eliminate drift due to the
+thermostat. Because the random forces on different atoms are
+independent, they do not sum exactly to zero.  As a result, this fix
+applies a small random force to the entire system, and the
+center-of-mass of the system undergoes a slow random walk.  If the
+keyword {zero} is set to {yes}, the total random force is set exactly
+to zero by subtracting off an equal part of it from each atom in the
+group.  As a result, the center-of-mass of a system with zero initial
+momentum will not drift over time.
+
+:line
+
 [Restart, fix_modify, output, run start/stop, minimize info:]
 
 No information about this fix is written to "binary restart
@@ -165,7 +223,7 @@ output"_thermo_style.html.  Note that use of this option requires
 setting the {tally} keyword to {yes}.
 
 This fix computes a global scalar which can be accessed by various
-"output commands"_Section_howto.html#4_15.  The scalar is the
+"output commands"_Section_howto.html#howto_15.  The scalar is the
 cummulative energy change due to this fix.  The scalar value
 calculated by this fix is "extensive".  Note that calculation of this
 quantity requires setting the {tally} keyword to {yes}.
@@ -186,7 +244,8 @@ dpd/tstat"_pair_dpd.html
 
 [Default:]
 
-The option defaults are scale = 1.0 for all types and tally = no.
+The option defaults are angmom = no, omega = no, scale = 1.0 for all
+types, tally = no, zero = no.
 
 :line
 
diff --git a/doc/fix_langevin_eff.html b/doc/fix_langevin_eff.html
index 895c8c47e9..db86010923 100644
--- a/doc/fix_langevin_eff.html
+++ b/doc/fix_langevin_eff.html
@@ -86,7 +86,7 @@ output.  Note that use of this option requires
 setting the tally keyword to yes.
 
      
 
      This fix computes a global scalar which can be accessed by various
-output commands.  The scalar is the
+output commands.  The scalar is the
 cummulative energy change due to this fix.  The scalar value
 calculated by this fix is "extensive".  Note that calculation of this
 quantity requires setting the tally keyword to yes.
@@ -99,8 +99,8 @@ quantity requires setting the tally keyword to yes.
 
      
 
      Restrictions: none
 
      
-
      This fix is part of the "user-eff" package.  It is only enabled if
-LAMMPS was built with that package.  See the Making
+
      This fix is part of the USER-EFF package.  It is only enabled if
+LAMMPS was built with that package.  See the Making
 LAMMPS section for more info.
 
      
 
      Related commands:
diff --git a/doc/fix_langevin_eff.txt b/doc/fix_langevin_eff.txt
index b48bb84772..a6806a39cd 100644
--- a/doc/fix_langevin_eff.txt
+++ b/doc/fix_langevin_eff.txt
@@ -76,7 +76,7 @@ output"_thermo_style.html.  Note that use of this option requires
 setting the {tally} keyword to {yes}.
 
 This fix computes a global scalar which can be accessed by various
-"output commands"_Section_howto.html#4_15.  The scalar is the
+"output commands"_Section_howto.html#howto_15.  The scalar is the
 cummulative energy change due to this fix.  The scalar value
 calculated by this fix is "extensive".  Note that calculation of this
 quantity requires setting the {tally} keyword to {yes}.
@@ -89,9 +89,9 @@ This fix is not invoked during "energy minimization"_minimize.html.
 
 [Restrictions:] none
 
-This fix is part of the "user-eff" package.  It is only enabled if
+This fix is part of the USER-EFF package.  It is only enabled if
 LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+LAMMPS"_Section_start.html#start_3 section for more info.
 
 [Related commands:]
 
diff --git a/doc/fix_lineforce.html b/doc/fix_lineforce.html
index 7de7b3ac03..9c87f094e2 100644
--- a/doc/fix_lineforce.html
+++ b/doc/fix_lineforce.html
@@ -38,9 +38,9 @@ it should continue to move along the line thereafter.
 
      No information about this fix is written to binary restart
 files.  None of the fix_modify options
 are relevant to this fix.  No global or per-atom quantities are stored
-by this fix for access by various output
-commands.  No parameter of this fix can be
-used with the start/stop keywords of the run command.
+by this fix for access by various output
+commands.  No parameter of this fix can
+be used with the start/stop keywords of the run command.
 
      
 
      The forces due to this fix are imposed during an energy minimization,
 invoked by the minimize command.
diff --git a/doc/fix_lineforce.txt b/doc/fix_lineforce.txt
index f5e069ada0..8b589632b6 100644
--- a/doc/fix_lineforce.txt
+++ b/doc/fix_lineforce.txt
@@ -36,8 +36,8 @@ No information about this fix is written to "binary restart
 files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.  No global or per-atom quantities are stored
 by this fix for access by various "output
-commands"_Section_howto.html#4_15.  No parameter of this fix can be
-used with the {start/stop} keywords of the "run"_run.html command.
+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.
 
 The forces due to this fix are imposed during an energy minimization,
 invoked by the "minimize"_minimize.html command.
diff --git a/doc/fix_meso.html b/doc/fix_meso.html
new file mode 100644
index 0000000000..b3684d8720
--- /dev/null
+++ b/doc/fix_meso.html
@@ -0,0 +1,57 @@
+
+
      LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
      
+
+
+
+
+
+
+
      
+
+
      fix meso command 
+
      
+
      Syntax:
+
      
+
      fix ID group-ID meso 
+
      
+
      • ID, group-ID are documented in fix command
+
      • meso = style name of this fix command 
+
      
+
      Examples:
+
      
+
      fix 1 all meso 
+
      
+
      Description:
+
      
+
      Perform time integration to update position, velocity, internal energy
+and local density for atoms in the group each timestep. This fix is
+needed to time-integrate mesoscopic systems where particles carry
+internal variables such as SPH or DPDE.
+
      
+
      See this PDF guide to using SPH in
+LAMMPS.
+
      
+
      Restart, fix_modify, output, run start/stop, minimize info:
+
      
+
      No information about this fix is written to binary restart
+files.  None of the fix_modify options
+are relevant to this fix.  No global or per-atom quantities are stored
+by this fix for access by various output
+commands.  No parameter of this fix can be
+used with the start/stop keywords of the run command.
+This fix is not invoked during energy minimization.
+
      
+
      Restrictions:
+
      
+
      This fix is part of the USER-SPH package.  It is only enabled if
+LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
      
+
      Related commands:
+
      
+
      "fix meso/stationary"
+
      
+
      Default: none
+
      
+
diff --git a/doc/fix_meso.txt b/doc/fix_meso.txt
new file mode 100644
index 0000000000..7c6a5cfc43
--- /dev/null
+++ b/doc/fix_meso.txt
@@ -0,0 +1,52 @@
+"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 meso command :h3
+
+[Syntax:]
+
+fix ID group-ID meso :pre
+
+ID, group-ID are documented in "fix"_fix.html command
+meso = style name of this fix command :ul
+
+[Examples:]
+
+fix 1 all meso :pre
+
+[Description:]
+
+Perform time integration to update position, velocity, internal energy
+and local density for atoms in the group each timestep. This fix is
+needed to time-integrate mesoscopic systems where particles carry
+internal variables such as SPH or DPDE.
+
+See "this PDF guide"_USER/sph/SPH_LAMMPS_userguide.pdf to using SPH in
+LAMMPS.
+
+[Restart, fix_modify, output, run start/stop, minimize info:]
+
+No information about this fix is written to "binary restart
+files"_restart.html.  None of the "fix_modify"_fix_modify.html options
+are relevant to this fix.  No global or per-atom quantities are stored
+by this fix for access by various "output
+commands"_Section_howto.html#4_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 USER-SPH 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 meso/stationary"
+
+[Default:] none
diff --git a/doc/fix_meso_stationary.html b/doc/fix_meso_stationary.html
new file mode 100644
index 0000000000..67a9a6a207
--- /dev/null
+++ b/doc/fix_meso_stationary.html
@@ -0,0 +1,58 @@
+
+
      LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
      
+
+
+
+
+
+
+
      
+
+
      fix meso/stationary command 
+
      
+
      Syntax:
+
      
+
      fix ID group-ID meso/stationary 
+
      
+
      • ID, group-ID are documented in fix command
+
      • meso = style name of this fix command 
+
      
+
      Examples:
+
      
+
      fix 1 boundary meso/stationary 
+
      
+
      Description:
+
      
+
      Perform time integration to update internal energy and local density,
+but not position or velocity for atoms in the group each timestep.
+This fix is needed for SPH simulations to correctly time-integrate
+fixed boundary particles which constrain a fluid to a given region in
+space.
+
      
+
      See this PDF guide to using SPH in
+LAMMPS.
+
      
+
      Restart, fix_modify, output, run start/stop, minimize info:
+
      
+
      No information about this fix is written to binary restart
+files.  None of the fix_modify options
+are relevant to this fix.  No global or per-atom quantities are stored
+by this fix for access by various output
+commands.  No parameter of this fix can be
+used with the start/stop keywords of the run command.
+This fix is not invoked during energy minimization.
+
      
+
      Restrictions:
+
      
+
      This fix is part of the USER-SPH package.  It is only enabled if
+LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
      
+
      Related commands:
+
      
+
      "fix meso"
+
      
+
      Default: none
+
      
+
diff --git a/doc/fix_meso_stationary.txt b/doc/fix_meso_stationary.txt
new file mode 100644
index 0000000000..31bdb4b1f3
--- /dev/null
+++ b/doc/fix_meso_stationary.txt
@@ -0,0 +1,53 @@
+"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 meso/stationary command :h3
+
+[Syntax:]
+
+fix ID group-ID meso/stationary :pre
+
+ID, group-ID are documented in "fix"_fix.html command
+meso = style name of this fix command :ul
+
+[Examples:]
+
+fix 1 boundary meso/stationary :pre
+
+[Description:]
+
+Perform time integration to update internal energy and local density,
+but not position or velocity for atoms in the group each timestep.
+This fix is needed for SPH simulations to correctly time-integrate
+fixed boundary particles which constrain a fluid to a given region in
+space.
+
+See "this PDF guide"_USER/sph/SPH_LAMMPS_userguide.pdf to using SPH in
+LAMMPS.
+
+[Restart, fix_modify, output, run start/stop, minimize info:]
+
+No information about this fix is written to "binary restart
+files"_restart.html.  None of the "fix_modify"_fix_modify.html options
+are relevant to this fix.  No global or per-atom quantities are stored
+by this fix for access by various "output
+commands"_Section_howto.html#4_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 USER-SPH 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 meso"
+
+[Default:] none
diff --git a/doc/fix_momentum.html b/doc/fix_momentum.html
index ab91b7d3a7..73e1a7a6f9 100644
--- a/doc/fix_momentum.html
+++ b/doc/fix_momentum.html
@@ -63,9 +63,9 @@ initial velocities with zero aggregate linear and/or angular momentum.
 
      No information about this fix is written to binary restart
 files.  None of the fix_modify options
 are relevant to this fix.  No global or per-atom quantities are stored
-by this fix for access by various output
-commands.  No parameter of this fix can be
-used with the start/stop keywords of the run command.
+by this fix for access by various output
+commands.  No parameter of this fix can
+be used with the start/stop keywords of the run command.
 This fix is not invoked during energy minimization.
 
      
 
      Restrictions: none
diff --git a/doc/fix_momentum.txt b/doc/fix_momentum.txt
index f2ed114b63..6fab08f1cb 100644
--- a/doc/fix_momentum.txt
+++ b/doc/fix_momentum.txt
@@ -56,8 +56,8 @@ No information about this fix is written to "binary restart
 files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.  No global or per-atom quantities are stored
 by this fix for access by various "output
-commands"_Section_howto.html#4_15.  No parameter of this fix can be
-used with the {start/stop} keywords of the "run"_run.html command.
+commands"_Section_howto.html#howto_15.  No parameter of this fix can
+be used with the {start/stop} keywords of the "run"_run.html command.
 This fix is not invoked during "energy minimization"_minimize.html.
 
 [Restrictions:] none
diff --git a/doc/fix_move.html b/doc/fix_move.html
index c56dac4f4c..c41d323798 100644
--- a/doc/fix_move.html
+++ b/doc/fix_move.html
@@ -188,8 +188,8 @@ uninterrupted fashion.
 fix.  
 
      
 
      This fix produces a per-atom array which can be accessed by various
-output commands.  The number of columns for
-each atom is 3, and the columns store the original unwrapped x,y,z
+output commands.  The number of columns
+for each atom is 3, and the columns store the original unwrapped x,y,z
 coords of each atom.  The per-atom values can be accessed on any
 timestep.
 
      
diff --git a/doc/fix_move.txt b/doc/fix_move.txt
index f46724f808..a07bd3307a 100644
--- a/doc/fix_move.txt
+++ b/doc/fix_move.txt
@@ -179,8 +179,8 @@ None of the "fix_modify"_fix_modify.html options are relevant to this
 fix.  
 
 This fix produces a per-atom array which can be accessed by various
-"output commands"_Section_howto.html#4_15.  The number of columns for
-each atom is 3, and the columns store the original unwrapped x,y,z
+"output commands"_Section_howto.html#howto_15.  The number of columns
+for each atom is 3, and the columns store the original unwrapped x,y,z
 coords of each atom.  The per-atom values can be accessed on any
 timestep.
 
diff --git a/doc/fix_msst.html b/doc/fix_msst.html
index 99294e06dc..60f2daffe7 100644
--- a/doc/fix_msst.html
+++ b/doc/fix_msst.html
@@ -139,14 +139,14 @@ variable lgr_pos equal f_msst[4]
 thermo_style     custom step temp ke pe lz pzz etotal v_dhug v_dray v_lgr_vel v_lgr_pos f_msst 
 
      • 
 
      These fixes compute a global scalar and a global vector of 4
-quantities, which can be accessed by various output
-commands.  The scalar values calculated by
-this fix are "extensive"; the vector values are "intensive".
+quantities, which can be accessed by various output
+commands.  The scalar values calculated
+by this fix are "extensive"; the vector values are "intensive".
 
      
 
      Restrictions:
 
      
-
      This fix style is part of the "shock" package.  It is only enabled if
-LAMMPS was built with that package. See the Making
+
      This fix style is part of the SHOCK package.  It is only enabled if
+LAMMPS was built with that package. See the Making
 LAMMPS section for more info.
 
      
 
      All cell dimensions must be periodic. This fix can not be used with a
@@ -155,7 +155,7 @@ all.
 
      
 
      Related commands:
 
      
-
      fix deform
+
      fix nphug, fix deform
 
      
 
      Default:
 
      
diff --git a/doc/fix_msst.txt b/doc/fix_msst.txt
index 95612079bc..60dbc1f20d 100644
--- a/doc/fix_msst.txt
+++ b/doc/fix_msst.txt
@@ -130,14 +130,14 @@ thermo_style     custom step temp ke pe lz pzz etotal v_dhug v_dray v_lgr_vel v_
 
 These fixes compute a global scalar and a global vector of 4
 quantities, which can be accessed by various "output
-commands"_Section_howto.html#4_15.  The scalar values calculated by
-this fix are "extensive"; the vector values are "intensive".
+commands"_Section_howto.html#howto_15.  The scalar values calculated
+by this fix are "extensive"; the vector values are "intensive".
 
 [Restrictions:]
 
-This fix style is part of the "shock" package.  It is only enabled if
+This fix style is part of the SHOCK package.  It is only enabled if
 LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+LAMMPS"_Section_start.html#start_3 section for more info.
 
 All cell dimensions must be periodic. This fix can not be used with a
 triclinic cell.  The MSST fix has been tested only for the group-ID
@@ -145,7 +145,7 @@ all.
   
 [Related commands:]
 
-"fix deform"_fix_deform.html
+"fix nphug"_fix_nphug.html, "fix deform"_fix_deform.html
 
 [Default:]
 
diff --git a/doc/fix_neb.html b/doc/fix_neb.html
index 69837ca052..79390f9b38 100644
--- a/doc/fix_neb.html
+++ b/doc/fix_neb.html
@@ -29,7 +29,7 @@
 simulation run via the neb command to perform a nudged
 elastic band (NEB) calculation for transition state finding.  Hi-level
 explanations of NEB are given with the neb command and in
-this section of the manual.  The fix neb
+this section of the manual.  The fix neb
 command must be used with the "neb" command to define how
 inter-replica forces are computed.
 
      
@@ -81,9 +81,9 @@ first equation.
 
      No information about this fix is written to binary restart
 files.  None of the fix_modify options
 are relevant to this fix.  No global or per-atom quantities are stored
-by this fix for access by various output
-commands.  No parameter of this fix can be
-used with the start/stop keywords of the run command.
+by this fix for access by various output
+commands.  No parameter of this fix can
+be used with the start/stop keywords of the run command.
 
      
 
      The forces due to this fix are imposed during an energy minimization,
 as invoked by the minimize command via the
@@ -91,9 +91,9 @@ as invoked by the minimize command via the
 
      
 
      Restrictions:
 
      
-
      This command can only be used if LAMMPS was built with the "replica"
-package.  See the Making LAMMPS section for
-more info on packages.
+
      This command can only be used if LAMMPS was built with the REPLICA
+package.  See the Making LAMMPS section
+for more info on packages.
 
      
 
      Related commands:
 
      
diff --git a/doc/fix_neb.txt b/doc/fix_neb.txt
index 353bde8bfd..397a259c4f 100644
--- a/doc/fix_neb.txt
+++ b/doc/fix_neb.txt
@@ -26,7 +26,7 @@ Add inter-replica forces to atoms in the group for a multi-replica
 simulation run via the "neb"_neb.html command to perform a nudged
 elastic band (NEB) calculation for transition state finding.  Hi-level
 explanations of NEB are given with the "neb"_neb.html command and in
-"this section"_Section_howto.html#4_5 of the manual.  The fix neb
+"this section"_Section_howto.html#howto_5 of the manual.  The fix neb
 command must be used with the "neb" command to define how
 inter-replica forces are computed.
 
@@ -79,8 +79,8 @@ No information about this fix is written to "binary restart
 files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.  No global or per-atom quantities are stored
 by this fix for access by various "output
-commands"_Section_howto.html#4_15.  No parameter of this fix can be
-used with the {start/stop} keywords of the "run"_run.html command.
+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.
 
 The forces due to this fix are imposed during an energy minimization,
 as invoked by the "minimize"_minimize.html command via the
@@ -88,9 +88,9 @@ as invoked by the "minimize"_minimize.html command via the
 
 [Restrictions:]
 
-This command can only be used if LAMMPS was built with the "replica"
-package.  See the "Making LAMMPS"_Section_start.html#2_3 section for
-more info on packages.
+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.
 
 [Related commands:]
 
diff --git a/doc/fix_nh.html b/doc/fix_nh.html
index b477cea8dd..6bf376ba76 100644
--- a/doc/fix_nh.html
+++ b/doc/fix_nh.html
@@ -11,8 +11,12 @@
 
 
      fix nvt command 
 
      
+
      fix nvt/cuda command 
+
      
 
      fix npt command 
 
      
+
      fix npt/cuda command 
+
      
 
      fix nph command 
 
      
 
      Syntax:
@@ -24,7 +28,7 @@
 
    • style_name = nvt or npt or nph 
 
 
      one or more keyword value pairs may be appended
-keyword = temp or iso or aniso or tri or x or y or z or xy or yz or xz or couple or tchain or pchain or mtk or tloop or ploop or nreset or drag or dilate
+keyword = temp or iso or aniso or tri or x or y or z or xy or yz or xz or couple or tchain or pchain or mtk or tloop or ploop or nreset or drag or dilate or scaleyz or scalexz or scalexy
   temp values = Tstart Tstop Tdamp
     Tstart,Tstop = external temperature at start/end of run
     Tdamp = temperature damping parameter (time units)
@@ -42,7 +46,10 @@ keyword = temp or iso or aniso or tri or x or
   ploop value = number of sub-cycles to perform on barostat thermostat
   nreset value = reset reference cell every this many timesteps
   drag value = drag factor added to barostat/thermostat (0.0 = no drag)
-  dilate value = all or partial 
+  dilate value = all or partial
+  scaleyz value = yes or no = scale yz with lz
+  scalexz value = yes or no = scale xz with lz
+  scalexy value = yes or no = scale xy with ly 
 
      
 
 
    
@@ -268,21 +275,41 @@ specified values of the external stress tensor.  A value of nstep
 means that every nstep timesteps, the reference dimensions are set
 to those of the current simulation domain.
 
    
+
    The scaleyz, scalexz, and scalexy keywords control whether or 
+not the corresponding tilt factors are scaled with the
+associated box dimensions
+when barostatting triclinic periodic cells.
+The default values yes will turn on scaling, which corresponds to
+adjusting the linear dimensions of the cell while preserving its shape.
+Choosing no ensures that the tilt factors are not scaled with the
+box dimensions. See below for restrictions and default values in different
+situations. In older versions of LAMMPS, scaling of tilt factors was not
+performed. The old behavior can be recovered by setting all three 
+scale keywords to no.
+
    
 
    
 
 
    IMPORTANT NOTE: Using a barostat coupled to tilt dimensions xy,
 xz, yz can sometimes result in arbitrarily large values of the
 tilt dimensions, i.e. a dramatically deformed simulation box.  LAMMPS
-imposes reasonable limits on how large the tilt values can be, and
-exits with an error if these are exceeded.  This error typically
+allows the tilt factors to grow a little beyond the normal limit
+of half the box length (0.6 times the box length), and then performs
+flipping or re-shaping to an equivalent periodic cell. The re-shaping
+operation is described in more detail in the doc page for 
+fix deform. Both the barostat dynamics and
+the atom trajectories are unaffected by this operation. However,
+if a tilt factor is incremented by a large amount (1.5 times the 
+box length) on a single timestep, LAMMPS can not accomodate 
+this event and will terminate the simulation
+with an error. This error typically
 indicates that there is something badly wrong with how the simulation
-was constructed.  The three most common sources of this error are
-using keyword tri on a liquid system, specifying an external shear
-stress tensor that exceeds the yield stress of the solid, and
-specifying values of Pstart that are too far from the current stress
-value. In other words, triclinic barostatting should be used with
-care.  This also is true for other barostat styles, although they tend
-to be more forgiving of insults.
+was constructed, such as specifying values of Pstart that are 
+too far from the current stress value, or specifying a timestep that
+is too large. Triclinic barostatting should be used with
+care. This also is true for other barostat styles, although they tend
+to be more forgiving of insults. In particular, it is important to
+recognize that equilibrium liquids can not support a shear stress and 
+that equilibrium solids can not support shear stresses that exceed the yield stress.
 
    
 
    IMPORTANT NOTE: Unlike the fix
 temp/berendsen command which performs
@@ -295,8 +322,8 @@ have their temperature controlled by another fix - e.g. by fix temp/rescale
 commands.
 
    
-
    See this howto section of the manual for a
-discussion of different ways to compute temperature and perform
+
    See this howto section of the manual for
+a discussion of different ways to compute temperature and perform
 thermostatting and barostatting.
 
    
 
    
@@ -344,6 +371,29 @@ temperature is calculated taking the bias into account, bias is
 removed from each atom, thermostatting is performed on the remaining
 thermal degrees of freedom, and the bias is added back in.
 
    
+
    
+
+
    Styles with a cuda 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
+this section of the manual.  The accelerated
+styles take the same arguments and should produce the same results,
+except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA package.  They are
+only enabled if LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
 
    Restart, fix_modify, output, run start/stop, minimize info:
 
    
 
    These fixes writes the state of all the thermostat and barostat
@@ -378,7 +428,7 @@ and barostatting to the system's potential energy as part of
 thermodynamic output.
 
    
 
    These fixes compute a global scalar and a global vector of quantities,
-which can be accessed by various output
+which can be accessed by various output
 commands.  The scalar value calculated by
 these fixes is "extensive"; the vector values are "intensive".
 
    
@@ -400,19 +450,19 @@ simulation, otherwise its value is 3.
 follows.  The notation means there are tchain values for eta, followed
 by tchain for eta_dot, followed by ndof for omega, etc:
 
    
-
    • eta[tchain] = particle thermostat displacements
-
    • eta_dot[tchain] = particle thermostat velocities
-
    • omega[ndof] = barostat displacements
-
    • omega_dot[ndof] = barostat velocities
-
    • etap[pchain] = barostat thermostat displacements
-
    • etap_dot[pchain] = barostat thermostat velocities
-
    • PE_eta[tchain] = potential energy of each particle thermostat displacement
-
    • KE_eta_dot[tchain] = kinetic energy of each particle thermostat velocity
-
    • PE_omega[ndof] = potential energy of each barostat displacement
-
    • KE_omega_dot[ndof] = kinetic energy of each barostat velocity
-
    • PE_etap[pchain] = potential energy of each barostat thermostat displacement
-
    • KE_etap_dot[pchain] = kinetic energy of each barostat thermostat velocity
-
    • PE_strain[1] = scalar strain energy 
+
      • eta[tchain] = particle thermostat displacements (unitless)
+
      • eta_dot[tchain] = particle thermostat velocities (1/time units)
+
      • omega[ndof] = barostat displacements (unitless)
+
      • omega_dot[ndof] = barostat velocities (1/time units)
+
      • etap[pchain] = barostat thermostat displacements (unitless)
+
      • etap_dot[pchain] = barostat thermostat velocities (1/time units)
+
      • PE_eta[tchain] = potential energy of each particle thermostat displacement (energy units)
+
      • KE_eta_dot[tchain] = kinetic energy of each particle thermostat velocity (energy units)
+
      • PE_omega[ndof] = potential energy of each barostat displacement (energy units)
+
      • KE_omega_dot[ndof] = kinetic energy of each barostat velocity (energy units)
+
      • PE_etap[pchain] = potential energy of each barostat thermostat displacement (energy units)
+
      • KE_etap_dot[pchain] = kinetic energy of each barostat thermostat velocity (energy units)
+
      • PE_strain[1] = scalar strain energy (energy units) 
 
      
 
      These fixes can ramp their external temperature and pressure over
 multiple runs, using the start and stop keywords of the
@@ -456,6 +506,12 @@ the meaning of the xy,xz,yz tilt factors.
 make the external T = 0.0 at some timestep during the simulation which
 is not allowed in the Nose/Hoover formulation.
 
      
+
      The scaleyz yes and scalexz yes keyword/value pairs can not be used
+for 2D simulations. scaleyz yes, scalexz yes, and scalexy yes options
+can only be used if the 2nd dimension in the keyword is periodic,
+and if the tilt factor is not coupled to the barostat via keywords
+tri, yz, xz, and xy.
+
      
 
      Related commands:
 
      
 
      fix nve, fix_modify, run_style
@@ -463,7 +519,9 @@ is not allowed in the Nose/Hoover formulation.
 
      Default:
 
      
 
      The keyword defaults are tchain = 3, pchain = 3, mtk = yes, tloop =
-ploop = 1, nreset = 0, drag = 0.0, dilate = all, and couple = none.
+ploop = 1, nreset = 0, drag = 0.0, dilate = all, couple = none,
+scaleyz = scalexz = scalexy = yes if periodic in 2nd dimension and 
+not coupled to barostat, otherwise no.
 
      
 
      
 
diff --git a/doc/fix_nh.txt b/doc/fix_nh.txt
index 026caa8348..f7dd7f2561 100644
--- a/doc/fix_nh.txt
+++ b/doc/fix_nh.txt
@@ -7,7 +7,9 @@
 :line
 
 fix nvt command :h3
+fix nvt/cuda command :h3
 fix npt command :h3
+fix npt/cuda command :h3
 fix nph command :h3
 
 [Syntax:]
@@ -17,7 +19,7 @@ fix ID group-ID style_name keyword value ... :pre
 ID, group-ID are documented in "fix"_fix.html command :ulb,l
 style_name = {nvt} or {npt} or {nph} :l
 one or more keyword value pairs may be appended
-keyword = {temp} or {iso} or {aniso} or {tri} or {x} or {y} or {z} or {xy} or {yz} or {xz} or {couple} or {tchain} or {pchain} or {mtk} or {tloop} or {ploop} or {nreset} or {drag} or {dilate}
+keyword = {temp} or {iso} or {aniso} or {tri} or {x} or {y} or {z} or {xy} or {yz} or {xz} or {couple} or {tchain} or {pchain} or {mtk} or {tloop} or {ploop} or {nreset} or {drag} or {dilate} or {scaleyz} or {scalexz} or {scalexy}
   {temp} values = Tstart Tstop Tdamp
     Tstart,Tstop = external temperature at start/end of run
     Tdamp = temperature damping parameter (time units)
@@ -35,7 +37,10 @@ keyword = {temp} or {iso} or {aniso} or {tri} or {x} or {y} or {z} or {xy} or {y
   {ploop} value = number of sub-cycles to perform on barostat thermostat
   {nreset} value = reset reference cell every this many timesteps
   {drag} value = drag factor added to barostat/thermostat (0.0 = no drag)
-  {dilate} value = {all} or {partial} :pre
+  {dilate} value = {all} or {partial}
+  {scaleyz} value = {yes} or {no} = scale yz with lz
+  {scalexz} value = {yes} or {no} = scale xz with lz
+  {scalexy} value = {yes} or {no} = scale xy with ly :pre
 :ule
 
 [Examples:]
@@ -260,21 +265,41 @@ specified values of the external stress tensor.  A value of {nstep}
 means that every {nstep} timesteps, the reference dimensions are set
 to those of the current simulation domain.
 
+The {scaleyz}, {scalexz}, and {scalexy} keywords control whether or 
+not the corresponding tilt factors are scaled with the
+associated box dimensions
+when barostatting triclinic periodic cells.
+The default values {yes} will turn on scaling, which corresponds to
+adjusting the linear dimensions of the cell while preserving its shape.
+Choosing {no} ensures that the tilt factors are not scaled with the
+box dimensions. See below for restrictions and default values in different
+situations. In older versions of LAMMPS, scaling of tilt factors was not
+performed. The old behavior can be recovered by setting all three 
+scale keywords to {no}.
+
 :line
 
 IMPORTANT NOTE: Using a barostat coupled to tilt dimensions {xy},
 {xz}, {yz} can sometimes result in arbitrarily large values of the
 tilt dimensions, i.e. a dramatically deformed simulation box.  LAMMPS
-imposes reasonable limits on how large the tilt values can be, and
-exits with an error if these are exceeded.  This error typically
+allows the tilt factors to grow a little beyond the normal limit
+of half the box length (0.6 times the box length), and then performs
+flipping or re-shaping to an equivalent periodic cell. The re-shaping
+operation is described in more detail in the doc page for 
+"fix deform"_fix_deform.html. Both the barostat dynamics and
+the atom trajectories are unaffected by this operation. However,
+if a tilt factor is incremented by a large amount (1.5 times the 
+box length) on a single timestep, LAMMPS can not accomodate 
+this event and will terminate the simulation
+with an error. This error typically
 indicates that there is something badly wrong with how the simulation
-was constructed.  The three most common sources of this error are
-using keyword {tri} on a liquid system, specifying an external shear
-stress tensor that exceeds the yield stress of the solid, and
-specifying values of {Pstart} that are too far from the current stress
-value. In other words, triclinic barostatting should be used with
-care.  This also is true for other barostat styles, although they tend
-to be more forgiving of insults.
+was constructed, such as specifying values of {Pstart} that are 
+too far from the current stress value, or specifying a timestep that
+is too large. Triclinic barostatting should be used with
+care. This also is true for other barostat styles, although they tend
+to be more forgiving of insults. In particular, it is important to
+recognize that equilibrium liquids can not support a shear stress and 
+that equilibrium solids can not support shear stresses that exceed the yield stress.
 
 IMPORTANT NOTE: Unlike the "fix
 temp/berendsen"_fix_temp_berendsen.html command which performs
@@ -287,8 +312,8 @@ have their temperature controlled by another fix - e.g. by "fix
 langevin"_fix_nh.html or "fix temp/rescale"_fix_temp_rescale.html
 commands.
 
-See "this howto section"_Section_howto.html#4_16 of the manual for a
-discussion of different ways to compute temperature and perform
+See "this howto section"_Section_howto.html#howto_16 of the manual for
+a discussion of different ways to compute temperature and perform
 thermostatting and barostatting.
 
 :line
@@ -336,6 +361,29 @@ temperature is calculated taking the bias into account, bias is
 removed from each atom, thermostatting is performed on the remaining
 thermal degrees of freedom, and the bias is added back in.
 
+:line
+
+Styles with a {cuda} 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
+"this section"_Section_accelerate.html of the manual.  The accelerated
+styles take the same arguments and should produce the same results,
+except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA package.  They are
+only enabled if LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restart, fix_modify, output, run start/stop, minimize info:]
 
 These fixes writes the state of all the thermostat and barostat
@@ -371,7 +419,7 @@ and barostatting to the system's potential energy as part of
 
 These fixes compute a global scalar and a global vector of quantities,
 which can be accessed by various "output
-commands"_Section_howto.html#4_15.  The scalar value calculated by
+commands"_Section_howto.html#howto_15.  The scalar value calculated by
 these fixes is "extensive"; the vector values are "intensive".
 
 The scalar is the cumulative energy change due to the fix.
@@ -392,19 +440,19 @@ The order of values in the global vector and their meaning is as
 follows.  The notation means there are tchain values for eta, followed
 by tchain for eta_dot, followed by ndof for omega, etc:
 
-eta\[tchain\] = particle thermostat displacements
-eta_dot\[tchain\] = particle thermostat velocities
-omega\[ndof\] = barostat displacements
-omega_dot\[ndof\] = barostat velocities
-etap\[pchain\] = barostat thermostat displacements
-etap_dot\[pchain\] = barostat thermostat velocities
-PE_eta\[tchain\] = potential energy of each particle thermostat displacement
-KE_eta_dot\[tchain\] = kinetic energy of each particle thermostat velocity
-PE_omega\[ndof\] = potential energy of each barostat displacement
-KE_omega_dot\[ndof\] = kinetic energy of each barostat velocity
-PE_etap\[pchain\] = potential energy of each barostat thermostat displacement
-KE_etap_dot\[pchain\] = kinetic energy of each barostat thermostat velocity
-PE_strain\[1\] = scalar strain energy :ul
+eta\[tchain\] = particle thermostat displacements (unitless)
+eta_dot\[tchain\] = particle thermostat velocities (1/time units)
+omega\[ndof\] = barostat displacements (unitless)
+omega_dot\[ndof\] = barostat velocities (1/time units)
+etap\[pchain\] = barostat thermostat displacements (unitless)
+etap_dot\[pchain\] = barostat thermostat velocities (1/time units)
+PE_eta\[tchain\] = potential energy of each particle thermostat displacement (energy units)
+KE_eta_dot\[tchain\] = kinetic energy of each particle thermostat velocity (energy units)
+PE_omega\[ndof\] = potential energy of each barostat displacement (energy units)
+KE_omega_dot\[ndof\] = kinetic energy of each barostat velocity (energy units)
+PE_etap\[pchain\] = potential energy of each barostat thermostat displacement (energy units)
+KE_etap_dot\[pchain\] = kinetic energy of each barostat thermostat velocity (energy units)
+PE_strain\[1\] = scalar strain energy (energy units) :ul
 
 These fixes can ramp their external temperature and pressure over
 multiple runs, using the {start} and {stop} keywords of the
@@ -448,6 +496,12 @@ For the {temp} keyword, the final Tstop cannot be 0.0 since it would
 make the external T = 0.0 at some timestep during the simulation which
 is not allowed in the Nose/Hoover formulation.
 
+The {scaleyz yes} and {scalexz yes} keyword/value pairs can not be used
+for 2D simulations. {scaleyz yes}, {scalexz yes}, and {scalexy yes} options
+can only be used if the 2nd dimension in the keyword is periodic,
+and if the tilt factor is not coupled to the barostat via keywords
+{tri}, {yz}, {xz}, and {xy}.
+  
 [Related commands:]
 
 "fix nve"_fix_nve.html, "fix_modify"_fix_modify.html, "run_style"_run_style.html
@@ -455,7 +509,9 @@ is not allowed in the Nose/Hoover formulation.
 [Default:]
 
 The keyword defaults are tchain = 3, pchain = 3, mtk = yes, tloop =
-ploop = 1, nreset = 0, drag = 0.0, dilate = all, and couple = none.
+ploop = 1, nreset = 0, drag = 0.0, dilate = all, couple = none,
+scaleyz = scalexz = scalexy = yes if periodic in 2nd dimension and 
+not coupled to barostat, otherwise no.
 
 :line
 
diff --git a/doc/fix_nh_eff.html b/doc/fix_nh_eff.html
index 5677e960c8..7d159b4bd6 100644
--- a/doc/fix_nh_eff.html
+++ b/doc/fix_nh_eff.html
@@ -110,8 +110,8 @@ for details.
 
      
 
      Restrictions:
 
      
-
      This fix is part of the "user-eff" package.  It is only enabled if
-LAMMPS was built with that package.  See the Making
+
      This fix is part of the USER-EFF package.  It is only enabled if
+LAMMPS was built with that package.  See the Making
 LAMMPS section for more info.
 
      
 
      Other restriction discussed on the doc page for the fix nvt, npt, and
diff --git a/doc/fix_nh_eff.txt b/doc/fix_nh_eff.txt
index 3d7a261e77..84ef87d6f7 100644
--- a/doc/fix_nh_eff.txt
+++ b/doc/fix_nh_eff.txt
@@ -102,9 +102,9 @@ for details.
 
 [Restrictions:]
 
-This fix is part of the "user-eff" package.  It is only enabled if
+This fix is part of the USER-EFF package.  It is only enabled if
 LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+LAMMPS"_Section_start.html#start_3 section for more info.
 
 Other restriction discussed on the doc page for the "fix nvt, npt, and
 nph"_fix_nh.html commands also apply.
diff --git a/doc/fix_nph_asphere.html b/doc/fix_nph_asphere.html
index cb7bdbff1a..43e2383abc 100644
--- a/doc/fix_nph_asphere.html
+++ b/doc/fix_nph_asphere.html
@@ -111,18 +111,23 @@ quantities as does the fix nph command.
 
      
 
      Restrictions:
 
      
-
      This fix requires that atoms store torque and angular velocity (omega)
-as defined by the atom_style.  It also require they
-store either a per-particle diameter or per-type shape.
+
      This fix is part of the ASPHERE package.  It is only enabled if LAMMPS
+was built with that package.  See the Making
+LAMMPS section for more info.
+
      
+
      This fix requires that atoms store torque and angular momementum and a
+quaternion as defined by the atom_style ellipsoid
+command.
 
      
 
      All particles in the group must be finite-size.  They cannot be point
-particles, but they can be aspherical or spherical.
+particles, but they can be aspherical or spherical as defined by their
+shape attribute.
 
      
 
      Related commands:
 
      
 
      fix nph, fix nve_asphere, fix
-nvt_asphere, fix npt_asphere,
-fix_modify
+nvt_asphere, fix
+npt_asphere, fix_modify
 
      
 
      Default: none
 
      
diff --git a/doc/fix_nph_asphere.txt b/doc/fix_nph_asphere.txt
index 5f8661df97..857ff9fd8a 100755
--- a/doc/fix_nph_asphere.txt
+++ b/doc/fix_nph_asphere.txt
@@ -108,17 +108,22 @@ This fix is not invoked during "energy minimization"_minimize.html.
 
 [Restrictions:]
 
-This fix requires that atoms store torque and angular velocity (omega)
-as defined by the "atom_style"_atom_style.html.  It also require they
-store either a per-particle diameter or per-type "shape"_shape.html.
+This fix is part of the ASPHERE package.  It is only enabled if LAMMPS
+was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+This fix requires that atoms store torque and angular momementum and a
+quaternion as defined by the "atom_style ellipsoid"_atom_style.html
+command.
 
 All particles in the group must be finite-size.  They cannot be point
-particles, but they can be aspherical or spherical.
+particles, but they can be aspherical or spherical as defined by their
+shape attribute.
 
 [Related commands:]
 
 "fix nph"_fix_nh.html, "fix nve_asphere"_fix_nve_asphere.html, "fix
-nvt_asphere"_fix_nvt_asphere.html, "fix npt_asphere"_fix_npt_asphere.html,
-"fix_modify"_fix_modify.html
+nvt_asphere"_fix_nvt_asphere.html, "fix
+npt_asphere"_fix_npt_asphere.html, "fix_modify"_fix_modify.html
 
 [Default:] none
diff --git a/doc/fix_nph_sphere.html b/doc/fix_nph_sphere.html
index d58b965f26..c2cb52a285 100644
--- a/doc/fix_nph_sphere.html
+++ b/doc/fix_nph_sphere.html
@@ -112,11 +112,11 @@ quantities as does the fix nph command.
 
      Restrictions:
 
      
 
      This fix requires that atoms store torque and angular velocity (omega)
-as defined by the atom_style.  It also require they
-store either a per-particle diameter or per-type shape.
+and a radius as defined by the atom_style sphere
+command.
 
      
 
      All particles in the group must be finite-size spheres.  They cannot
-be point particles, nor can they be aspherical.
+be point particles.
 
      
 
      Related commands:
 
      
diff --git a/doc/fix_nph_sphere.txt b/doc/fix_nph_sphere.txt
index 5e9d315772..153a5cf535 100755
--- a/doc/fix_nph_sphere.txt
+++ b/doc/fix_nph_sphere.txt
@@ -109,11 +109,11 @@ This fix is not invoked during "energy minimization"_minimize.html.
 [Restrictions:]
 
 This fix requires that atoms store torque and angular velocity (omega)
-as defined by the "atom_style"_atom_style.html.  It also require they
-store either a per-particle diameter or per-type "shape"_shape.html.
+and a radius as defined by the "atom_style sphere"_atom_style.html
+command.
 
 All particles in the group must be finite-size spheres.  They cannot
-be point particles, nor can they be aspherical.
+be point particles.
 
 [Related commands:]
 
diff --git a/doc/fix_nphug.html b/doc/fix_nphug.html
new file mode 100644
index 0000000000..7a85d2da99
--- /dev/null
+++ b/doc/fix_nphug.html
@@ -0,0 +1,214 @@
+
+
      LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
      
+
+
+
+
+
+
+
      
+
+
      fix nphug command 
+
      
+
      Syntax:
+
      
+
      fix ID group-ID nphug keyword value ... 
+
      
+
      • ID, group-ID are documented in fix command 
+
+
        one or more keyword value pairs may be appended
+keyword = temp or iso or aniso or tri or x or y or z or couple or tchain or pchain or mtk or tloop or ploop or nreset or drag or dilate or scaleyz or scalexz or scalexy
+  temp values = Value1 Value2 Tdamp
+    Value1, Value2 = Nose-Hoover target temperatures, ignored by Hugoniostat
+    Tdamp = temperature damping parameter (time units)
+  iso or aniso or tri values = Pstart Pstop Pdamp
+    Pstart,Pstop = scalar external pressures, must be equal (pressure units)
+    Pdamp = pressure damping parameter (time units)
+  x or y or z or xy or yz or xz values = Pstart Pstop Pdamp
+    Pstart,Pstop = external stress tensor components, must be equal (pressure units)
+    Pdamp = stress damping parameter (time units)
+  couple = none or xyz or xy or yz or xz
+  tchain value = length of thermostat chain (1 = single thermostat)
+  pchain values = length of thermostat chain on barostat (0 = no thermostat)
+  mtk value = yes or no = add in MTK adjustment term or not
+  tloop value = number of sub-cycles to perform on thermostat
+  ploop value = number of sub-cycles to perform on barostat thermostat
+  nreset value = reset reference cell every this many timesteps
+  drag value = drag factor added to barostat/thermostat (0.0 = no drag)
+  dilate value = all or partial
+  scaleyz value = yes or no = scale yz with lz
+  scalexz value = yes or no = scale xz with lz
+  scalexy value = yes or no = scale xy with ly 
+
        
+
+
      
+
      Examples:
+
      
+
      fix myhug all nphug temp 1.0 1.0 10.0 z 40.0 40.0 70.0
+fix myhug all nphug temp 1.0 1.0 10.0 iso 40.0 40.0 70.0 drag 200.0 tchain 1 pchain 0 
+
      
+
      Description:
+
      
+
      This command is a variant of the Nose-Hoover
+fix npt fix style.
+It performs time integration of the Hugoniostat equations
+of motion developed by Ravelo et al. (Ravelo).
+These equations compress the system to a state with average
+axial stress or pressure equal to the specified target value 
+and that satisfies the Rankine-Hugoniot (RH)
+jump conditions for steady shocks.
+
      
+
      The compression can be performed 
+either
+hydrostatically (using keyword iso, aniso, or tri) or uniaxially
+(using keywords x, y, or z).  In the hydrostatic case,
+the cell dimensions change dynamically so that the average axial stress
+in all three directions converges towards the specified target value. 
+In the uniaxial case, the chosen cell dimension changes dynamically 
+so that the average
+axial stress in that direction converges towards the target value. The
+other two cell dimensions are kept fixed (zero lateral strain).
+
      
+
      This leads to the following additional restrictions on the keywords:
+
      
+
      • One and only one of the following keywords should be used: iso, aniso, tri, x, y, z 
+
      • The specified initial and final target pressures must be the same.
+
      • The keywords xy, xz, yz may not be used.
+
      • The only admissible value for the couple keyword is xyz, which has the same effect as keyword iso 
+
      • The temp keyword must be used to specify the time constant for kinetic energy relaxation, but initial and final target temperature values are ignored.  
+
      
+
      Essentially, a Hugoniostat simulation is an NPT simulation in which the
+user-specified target temperature is replaced with a time-dependent 
+target temperature Tt obtained from the following equation:
+
      
+
      
+
      
+
      where T and Tt are the instantaneous and target temperatures,
+P and P0 are the instantaneous and reference pressures or axial stresses,
+depending on whether hydrostatic or uniaxial compression is being 
+performed, V and V0 are the instantaneous and reference volumes,
+E and E0 are the instantaneous and reference internal energy (potential
+plus kinetic), Ndof is the number of degrees of freedom used in the
+definition of temperature, and kB is the Boltzmann constant. Delta is the 
+negative deviation of the instantaneous temperature from the target temperature.
+When the system reaches a stable equilibrium, the value of Delta should 
+fluctuate about zero.
+
      
+
      The values of E0, V0, and P0 are the instantaneous values at the start of
+the simulation. These can be overridden using the fix_modify keywords e0,
+v0, and p0 described below.
+
      
+
      
+
+
      IMPORTANT NOTE: Unlike the fix
+temp/berendsen command which performs
+thermostatting but NO time integration, this fix performs
+thermostatting/barostatting AND time integration.  Thus you should not
+use any other time integration fix, such as fix nve on
+atoms to which this fix is applied.  Likewise, this fix should not be 
+used on atoms that have their temperature controlled by another fix 
+- e.g. by fix langevin or fix temp/rescale
+commands.
+
      
+
      
+
+
      This fix computes a temperature and pressure at each timestep.  To do
+this, the fix creates its own computes of style "temp" and "pressure",
+as if one of these two sets of commands had been issued:
+
      
+
      compute fix-ID_temp group-ID temp
+compute fix-ID_press group-ID pressure fix-ID_temp 
+
      
+
      compute fix-ID_temp all temp
+compute fix-ID_press all pressure fix-ID_temp 
+
      
+
      See the compute temp and compute
+pressure commands for details.  Note that the
+IDs of the new computes are the fix-ID + underscore + "temp" or fix_ID
++ underscore + "press".  The group for
+the new computes is "all" since pressure is computed for the entire
+system.
+
      
+
      Note that these are NOT the computes used by thermodynamic output (see
+the thermo_style command) with ID = thermo_temp
+and thermo_press.  This means you can change the attributes of this
+fix's temperature or pressure via the
+compute_modify command or print this temperature
+or pressure during thermodynamic output via the thermo_style
+custom command using the appropriate compute-ID.
+It also means that changing attributes of thermo_temp or
+thermo_press will have no effect on this fix.
+
      
+
      
+
+
      Restart, fix_modify, output, run start/stop, minimize info:
+
      
+
      This fix writes the values of E0, V0, and P0, as well as the 
+state of all the thermostat and barostat
+variables to binary restart files.  See the
+read_restart command for info on how to re-specify
+a fix in an input script that reads a restart file, so that the
+operation of the fix continues in an uninterrupted fashion.
+
      
+
      The fix_modify e0, v0 and p0 keywords
+can be used to define the values of E0, V0, and P0. Note the
+the values for e0 and v0 are extensive, and so must correspond
+to the total energy and volume of the entire system, not energy and 
+volume per atom. If any of these quantities are not specified, then the
+instantaneous value in the system at the start of the simulation is used.
+
      
+
      The fix_modify temp and press options are
+supported by these fixes.  You can use them to assign a
+compute you have defined to this fix which will be used
+in its thermostatting or barostatting procedure, as described above.
+If you do this, note that the kinetic energy derived from the compute
+temperature should be consistent with the virial term computed using
+all atoms for the pressure.  LAMMPS will warn you if you choose to
+compute temperature on a subset of atoms.
+
      
+
      The fix_modify energy option is supported by these
+fixes to add the energy change induced by Nose/Hoover thermostatting
+and barostatting to the system's potential energy as part of
+thermodynamic output. Either way, this energy is *not*
+included in the definition of internal energy E when calculating the value
+of Delta in the above equation.
+
      
+
      These fixes compute a global scalar and a global vector of quantities,
+which can be accessed by various output
+commands.  The scalar value calculated by
+these fixes is "extensive"; the vector values are "intensive".
+
      
+
      The scalar is the cumulative energy change due to the fix.
+
      
+
      The vector stores three quantities unique to this fix (Delta, Us, and up),
+followed by all the internal Nose/Hoover thermostat and barostat
+variables defined for fix_style npt. Delta is the deviation
+of the temperature from the target temperature, given by the above equation.
+Us and up are the shock and particle velocity corresponding to a steady
+shock calculated from the RH conditions. They have units of distance/time.
+
      
+
      Restrictions:
+
      
+
      This fix style is part of the SHOCK package.  It is only enabled if
+LAMMPS was built with that package. See the Making
+LAMMPS section for more info.
+
      
+
      All the usual restrictions for fix_style npt apply,
+plus the additional ones mentioned above.
+
      
+
      Related commands:
+
      
+
      fix msst, fix npt, fix_modify
+
      
+
      Default:
+
      
+
      The keyword defaults are the same as those for fix npt
+
      
+
      
+
+
+
+
      (Ravelo) Ravelo, Holian, Germann and Lomdahl, Phys Rev B, 70, 014103 (2004).
+
      
+
diff --git a/doc/fix_nphug.txt b/doc/fix_nphug.txt
new file mode 100644
index 0000000000..aa880ac01d
--- /dev/null
+++ b/doc/fix_nphug.txt
@@ -0,0 +1,206 @@
+"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 nphug command :h3
+
+[Syntax:]
+
+fix ID group-ID nphug keyword value ... :pre
+
+ID, group-ID are documented in "fix"_fix.html command :ulb,l
+one or more keyword value pairs may be appended
+keyword = {temp} or {iso} or {aniso} or {tri} or {x} or {y} or {z} or {couple} or {tchain} or {pchain} or {mtk} or {tloop} or {ploop} or {nreset} or {drag} or {dilate} or {scaleyz} or {scalexz} or {scalexy}
+  {temp} values = Value1 Value2 Tdamp
+    Value1, Value2 = Nose-Hoover target temperatures, ignored by Hugoniostat
+    Tdamp = temperature damping parameter (time units)
+  {iso} or {aniso} or {tri} values = Pstart Pstop Pdamp
+    Pstart,Pstop = scalar external pressures, must be equal (pressure units)
+    Pdamp = pressure damping parameter (time units)
+  {x} or {y} or {z} or {xy} or {yz} or {xz} values = Pstart Pstop Pdamp
+    Pstart,Pstop = external stress tensor components, must be equal (pressure units)
+    Pdamp = stress damping parameter (time units)
+  {couple} = {none} or {xyz} or {xy} or {yz} or {xz}
+  {tchain} value = length of thermostat chain (1 = single thermostat)
+  {pchain} values = length of thermostat chain on barostat (0 = no thermostat)
+  {mtk} value = {yes} or {no} = add in MTK adjustment term or not
+  {tloop} value = number of sub-cycles to perform on thermostat
+  {ploop} value = number of sub-cycles to perform on barostat thermostat
+  {nreset} value = reset reference cell every this many timesteps
+  {drag} value = drag factor added to barostat/thermostat (0.0 = no drag)
+  {dilate} value = {all} or {partial}
+  {scaleyz} value = {yes} or {no} = scale yz with lz
+  {scalexz} value = {yes} or {no} = scale xz with lz
+  {scalexy} value = {yes} or {no} = scale xy with ly :pre
+:ule
+
+[Examples:]
+
+fix myhug all nphug temp 1.0 1.0 10.0 z 40.0 40.0 70.0
+fix myhug all nphug temp 1.0 1.0 10.0 iso 40.0 40.0 70.0 drag 200.0 tchain 1 pchain 0 :pre
+
+[Description:]
+
+This command is a variant of the Nose-Hoover
+"fix npt"_fix_nh.html fix style.
+It performs time integration of the Hugoniostat equations
+of motion developed by Ravelo et al. "(Ravelo)"_#Ravelo.
+These equations compress the system to a state with average
+axial stress or pressure equal to the specified target value 
+and that satisfies the Rankine-Hugoniot (RH)
+jump conditions for steady shocks.
+
+The compression can be performed 
+either
+hydrostatically (using keyword {iso}, {aniso}, or {tri}) or uniaxially
+(using keywords {x}, {y}, or {z}).  In the hydrostatic case,
+the cell dimensions change dynamically so that the average axial stress
+in all three directions converges towards the specified target value. 
+In the uniaxial case, the chosen cell dimension changes dynamically 
+so that the average
+axial stress in that direction converges towards the target value. The
+other two cell dimensions are kept fixed (zero lateral strain).
+
+This leads to the following additional restrictions on the keywords:
+
+One and only one of the following keywords should be used: {iso}, {aniso}, {tri}, {x}, {y}, {z} 
+The specified initial and final target pressures must be the same.
+The keywords {xy}, {xz}, {yz} may not be used.
+The only admissible value for the couple keyword is {xyz}, which has the same effect as keyword {iso} 
+The {temp} keyword must be used to specify the time constant for kinetic energy relaxation, but initial and final target temperature values are ignored.  :ul
+
+Essentially, a Hugoniostat simulation is an NPT simulation in which the
+user-specified target temperature is replaced with a time-dependent 
+target temperature Tt obtained from the following equation:
+
+:c,image(Eqs/fix_nphug.jpg) 
+
+where T and Tt are the instantaneous and target temperatures,
+P and P0 are the instantaneous and reference pressures or axial stresses,
+depending on whether hydrostatic or uniaxial compression is being 
+performed, V and V0 are the instantaneous and reference volumes,
+E and E0 are the instantaneous and reference internal energy (potential
+plus kinetic), Ndof is the number of degrees of freedom used in the
+definition of temperature, and kB is the Boltzmann constant. Delta is the 
+negative deviation of the instantaneous temperature from the target temperature.
+When the system reaches a stable equilibrium, the value of Delta should 
+fluctuate about zero.
+
+The values of E0, V0, and P0 are the instantaneous values at the start of
+the simulation. These can be overridden using the fix_modify keywords {e0},
+{v0}, and {p0} described below.
+
+:line
+
+IMPORTANT NOTE: Unlike the "fix
+temp/berendsen"_fix_temp_berendsen.html command which performs
+thermostatting but NO time integration, this fix performs
+thermostatting/barostatting AND time integration.  Thus you should not
+use any other time integration fix, such as "fix nve"_fix_nve.html on
+atoms to which this fix is applied.  Likewise, this fix should not be 
+used on atoms that have their temperature controlled by another fix 
+- e.g. by "fix langevin"_fix_nh.html or "fix temp/rescale"_fix_temp_rescale.html
+commands.
+
+:line
+
+This fix computes a temperature and pressure at each timestep.  To do
+this, the fix creates its own computes of style "temp" and "pressure",
+as if one of these two sets of commands had been issued:
+
+compute fix-ID_temp group-ID temp
+compute fix-ID_press group-ID pressure fix-ID_temp :pre
+
+compute fix-ID_temp all temp
+compute fix-ID_press all pressure fix-ID_temp :pre
+
+See the "compute temp"_compute_temp.html and "compute
+pressure"_compute_pressure.html commands for details.  Note that the
+IDs of the new computes are the fix-ID + underscore + "temp" or fix_ID
++ underscore + "press".  The group for
+the new computes is "all" since pressure is computed for the entire
+system.
+
+Note that these are NOT the computes used by thermodynamic output (see
+the "thermo_style"_thermo_style.html command) with ID = {thermo_temp}
+and {thermo_press}.  This means you can change the attributes of this
+fix's temperature or pressure via the
+"compute_modify"_compute_modify.html command or print this temperature
+or pressure during thermodynamic output via the "thermo_style
+custom"_thermo_style.html command using the appropriate compute-ID.
+It also means that changing attributes of {thermo_temp} or
+{thermo_press} will have no effect on this fix.
+
+:line
+
+[Restart, fix_modify, output, run start/stop, minimize info:]
+
+This fix writes the values of E0, V0, and P0, as well as the 
+state of all the thermostat and barostat
+variables to "binary restart files"_restart.html.  See the
+"read_restart"_read_restart.html command for info on how to re-specify
+a fix in an input script that reads a restart file, so that the
+operation of the fix continues in an uninterrupted fashion.
+
+The "fix_modify"_fix_modify.html {e0}, {v0} and {p0} keywords
+can be used to define the values of E0, V0, and P0. Note the
+the values for {e0} and {v0} are extensive, and so must correspond
+to the total energy and volume of the entire system, not energy and 
+volume per atom. If any of these quantities are not specified, then the
+instantaneous value in the system at the start of the simulation is used.
+
+The "fix_modify"_fix_modify.html {temp} and {press} options are
+supported by these fixes.  You can use them to assign a
+"compute"_compute.html you have defined to this fix which will be used
+in its thermostatting or barostatting procedure, as described above.
+If you do this, note that the kinetic energy derived from the compute
+temperature should be consistent with the virial term computed using
+all atoms for the pressure.  LAMMPS will warn you if you choose to
+compute temperature on a subset of atoms.
+
+The "fix_modify"_fix_modify.html {energy} option is supported by these
+fixes to add the energy change induced by Nose/Hoover thermostatting
+and barostatting to the system's potential energy as part of
+"thermodynamic output"_thermo_style.html. Either way, this energy is *not*
+included in the definition of internal energy E when calculating the value
+of Delta in the above equation.
+
+These fixes compute a global scalar and a global vector of quantities,
+which can be accessed by various "output
+commands"_Section_howto.html#howto_15.  The scalar value calculated by
+these fixes is "extensive"; the vector values are "intensive".
+
+The scalar is the cumulative energy change due to the fix.
+
+The vector stores three quantities unique to this fix (Delta, Us, and up),
+followed by all the internal Nose/Hoover thermostat and barostat
+variables defined for "fix_style npt"_fix_nh.html. Delta is the deviation
+of the temperature from the target temperature, given by the above equation.
+Us and up are the shock and particle velocity corresponding to a steady
+shock calculated from the RH conditions. They have units of distance/time.
+
+[Restrictions:]
+
+This fix style is part of the SHOCK 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.
+
+All the usual restrictions for "fix_style npt"_fix_nh.html apply,
+plus the additional ones mentioned above.
+
+[Related commands:]
+
+"fix msst"_fix_msst.html, "fix npt"_fix_nh.html, "fix_modify"_fix_modify.html
+
+[Default:]
+
+The keyword defaults are the same as those for "fix npt"_fix_nh.html
+
+:line
+
+:link(Ravelo)
+[(Ravelo)] Ravelo, Holian, Germann and Lomdahl, Phys Rev B, 70, 014103 (2004).
diff --git a/doc/fix_npt_asphere.html b/doc/fix_npt_asphere.html
index b591f626ad..7eb9df9abc 100644
--- a/doc/fix_npt_asphere.html
+++ b/doc/fix_npt_asphere.html
@@ -136,18 +136,17 @@ this.
 
      
 
      Restrictions:
 
      
-
      This fix is part of the "asphere" package.  It is only enabled if
-LAMMPS was built with that package.  See the Making
+
      This fix is part of the ASPHERE package.  It is only enabled if LAMMPS
+was built with that package.  See the Making
 LAMMPS section for more info.
 
      
-
      This fix requires that atoms store torque and angular momentum and a
-quaternion to represent their orientation, as defined by the
-atom_style.  It also require they store a per-type
-shape.  The particles cannot store a per-particle
-diameter or per-particle mass.
+
      This fix requires that atoms store torque and angular momementum and a
+quaternion as defined by the atom_style ellipsoid
+command.
 
      
 
      All particles in the group must be finite-size.  They cannot be point
-particles, but they can be aspherical or spherical.
+particles, but they can be aspherical or spherical as defined by their
+shape attribute.
 
      
 
      Related commands:
 
      
diff --git a/doc/fix_npt_asphere.txt b/doc/fix_npt_asphere.txt
index d6dc39461c..e11ef0eb7d 100755
--- a/doc/fix_npt_asphere.txt
+++ b/doc/fix_npt_asphere.txt
@@ -133,18 +133,17 @@ This fix is not invoked during "energy minimization"_minimize.html.
 
 [Restrictions:]
 
-This fix is part of the "asphere" package.  It is only enabled if
-LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+This fix is part of the ASPHERE package.  It is only enabled if LAMMPS
+was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
 
-This fix requires that atoms store torque and angular momentum and a
-quaternion to represent their orientation, as defined by the
-"atom_style"_atom_style.html.  It also require they store a per-type
-"shape"_shape.html.  The particles cannot store a per-particle
-diameter or per-particle mass.
+This fix requires that atoms store torque and angular momementum and a
+quaternion as defined by the "atom_style ellipsoid"_atom_style.html
+command.
 
 All particles in the group must be finite-size.  They cannot be point
-particles, but they can be aspherical or spherical.
+particles, but they can be aspherical or spherical as defined by their
+shape attribute.
 
 [Related commands:]
 
diff --git a/doc/fix_npt_sphere.html b/doc/fix_npt_sphere.html
index bf96296aa9..03948a35ff 100644
--- a/doc/fix_npt_sphere.html
+++ b/doc/fix_npt_sphere.html
@@ -136,11 +136,11 @@ this.
 
      Restrictions:
 
      
 
      This fix requires that atoms store torque and angular velocity (omega)
-as defined by the atom_style.  It also require they
-store either a per-particle diameter or per-type shape.
+and a radius as defined by the atom_style sphere
+command.
 
      
 
      All particles in the group must be finite-size spheres.  They cannot
-be point particles, nor can they be aspherical.
+be point particles.
 
      
 
      Related commands:
 
      
diff --git a/doc/fix_npt_sphere.txt b/doc/fix_npt_sphere.txt
index 91b9f49450..945af23ef4 100755
--- a/doc/fix_npt_sphere.txt
+++ b/doc/fix_npt_sphere.txt
@@ -133,11 +133,11 @@ This fix is not invoked during "energy minimization"_minimize.html.
 [Restrictions:]
 
 This fix requires that atoms store torque and angular velocity (omega)
-as defined by the "atom_style"_atom_style.html.  It also require they
-store either a per-particle diameter or per-type "shape"_shape.html.
+and a radius as defined by the "atom_style sphere"_atom_style.html
+command.
 
 All particles in the group must be finite-size spheres.  They cannot
-be point particles, nor can they be aspherical.
+be point particles.
 
 [Related commands:]
 
diff --git a/doc/fix_nve.html b/doc/fix_nve.html
index 179718d2b7..e08b86dcde 100644
--- a/doc/fix_nve.html
+++ b/doc/fix_nve.html
@@ -11,6 +11,8 @@
 
 
      fix nve command 
 
      
+
      fix nve/cuda command 
+
      
 
      Syntax:
 
      
 
      fix ID group-ID nve 
@@ -29,14 +31,37 @@ atoms in the group each timestep.  V is volume; E is energy.  This
 creates a system trajectory consistent with the microcanonical
 ensemble.
 
      
+
      
+
+
      Styles with a cuda 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
+this section of the manual.  The accelerated
+styles take the same arguments and should produce the same results,
+except for round-off and precision issues.
+
      
+
      These accelerated styles are part of the USER-CUDA package.  They are
+only enabled if LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
      
+
      You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
      
+
      See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
      
+
      
+
 
      Restart, fix_modify, output, run start/stop, minimize info:
 
      
 
      No information about this fix is written to binary restart
 files.  None of the fix_modify options
 are relevant to this fix.  No global or per-atom quantities are stored
-by this fix for access by various output
-commands.  No parameter of this fix can be
-used with the start/stop keywords of the run command.
+by this fix for access by various output
+commands.  No parameter of this fix can
+be used with the start/stop keywords of the run command.
 This fix is not invoked during energy minimization.
 
      
 
      Restrictions: none
diff --git a/doc/fix_nve.txt b/doc/fix_nve.txt
index 6c153cf492..fbc23c25e4 100644
--- a/doc/fix_nve.txt
+++ b/doc/fix_nve.txt
@@ -7,6 +7,7 @@
 :line
 
 fix nve command :h3
+fix nve/cuda command :h3
 
 [Syntax:]
 
@@ -26,14 +27,37 @@ atoms in the group each timestep.  V is volume; E is energy.  This
 creates a system trajectory consistent with the microcanonical
 ensemble.
 
+:line
+
+Styles with a {cuda} 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
+"this section"_Section_accelerate.html of the manual.  The accelerated
+styles take the same arguments and should produce the same results,
+except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA package.  They are
+only enabled if LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restart, fix_modify, output, run start/stop, minimize info:]
 
 No information about this fix is written to "binary restart
 files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.  No global or per-atom quantities are stored
 by this fix for access by various "output
-commands"_Section_howto.html#4_15.  No parameter of this fix can be
-used with the {start/stop} keywords of the "run"_run.html command.
+commands"_Section_howto.html#howto_15.  No parameter of this fix can
+be used with the {start/stop} keywords of the "run"_run.html command.
 This fix is not invoked during "energy minimization"_minimize.html.
 
 [Restrictions:] none
diff --git a/doc/fix_nve_asphere.html b/doc/fix_nve_asphere.html
index 7d553b584c..8b5ea4a3f5 100644
--- a/doc/fix_nve_asphere.html
+++ b/doc/fix_nve_asphere.html
@@ -37,25 +37,24 @@ assumes point particles and only updates their position and velocity.
 
      No information about this fix is written to binary restart
 files.  None of the fix_modify options
 are relevant to this fix.  No global or per-atom quantities are stored
-by this fix for access by various output
-commands.  No parameter of this fix can be
-used with the start/stop keywords of the run command.
+by this fix for access by various output
+commands.  No parameter of this fix can
+be used with the start/stop keywords of the run command.
 This fix is not invoked during energy minimization.
 
      
 
      Restrictions: 
 
      
-
      This fix is part of the "asphere" package.  It is only enabled if
-LAMMPS was built with that package.  See the Making
+
      This fix is part of the ASPHERE package.  It is only enabled if LAMMPS
+was built with that package.  See the Making
 LAMMPS section for more info.
 
      
-
      This fix requires that atoms store torque and angular momentum and a
-quaternion to represent their orientation, as defined by the
-atom_style.  It also require they store a per-type
-shape.  The particles cannot store a per-particle
-diameter or per-particle mass.
+
      This fix requires that atoms store torque and angular momementum and a
+quaternion as defined by the atom_style ellipsoid
+command.
 
      
 
      All particles in the group must be finite-size.  They cannot be point
-particles, but they can be aspherical or spherical.
+particles, but they can be aspherical or spherical as defined by their
+shape attribute.
 
      
 
      Related commands:
 
      
diff --git a/doc/fix_nve_asphere.txt b/doc/fix_nve_asphere.txt
index a0b055a294..d7b70f41ec 100755
--- a/doc/fix_nve_asphere.txt
+++ b/doc/fix_nve_asphere.txt
@@ -35,24 +35,23 @@ No information about this fix is written to "binary restart
 files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.  No global or per-atom quantities are stored
 by this fix for access by various "output
-commands"_Section_howto.html#4_15.  No parameter of this fix can be
-used with the {start/stop} keywords of the "run"_run.html command.
+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 "asphere" package.  It is only enabled if
-LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+This fix is part of the ASPHERE package.  It is only enabled if LAMMPS
+was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
 
-This fix requires that atoms store torque and angular momentum and a
-quaternion to represent their orientation, as defined by the
-"atom_style"_atom_style.html.  It also require they store a per-type
-"shape"_shape.html.  The particles cannot store a per-particle
-diameter or per-particle mass.
+This fix requires that atoms store torque and angular momementum and a
+quaternion as defined by the "atom_style ellipsoid"_atom_style.html
+command.
 
 All particles in the group must be finite-size.  They cannot be point
-particles, but they can be aspherical or spherical.
+particles, but they can be aspherical or spherical as defined by their
+shape attribute.
 
 [Related commands:]
 
diff --git a/doc/fix_nve_asphere_noforce.html b/doc/fix_nve_asphere_noforce.html
new file mode 100644
index 0000000000..4dd6f31ad6
--- /dev/null
+++ b/doc/fix_nve_asphere_noforce.html
@@ -0,0 +1,70 @@
+
+
      LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
      
+
+
+
+
+
+
+
      
+
+
      fix nve/asphere/noforce command 
+
      
+
      Syntax:
+
      
+
      fix ID group-ID nve/asphere/noforce 
+
      
+
      • ID, group-ID are documented in fix command
+
      • nve/asphere/noforce = style name of this fix command 
+
      
+
      Examples:
+
      
+
      fix 1 all nve/asphere/noforce
+
      
+
      Description:
+
      
+
      Perform updates of position and orientation, but not velocity or
+angular momentum for atoms in the group each timestep.  In other
+words, the force and torque on the atoms is ignored and their velocity
+and angular momentum are not updated.  The atom velocities and
+angularm momenta are used to update their positions and orientation.
+
      
+
      This is useful as an implicit time integrator for Fast Lubrication
+Dynamics, since the velocity and angular momentum are updated by the
+pair_style lubricuteU command.
+
      
+
      
+
+
      Restart, fix_modify, output, run start/stop, minimize info:
+
      
+
      No information about this fix is written to binary restart
+files.  None of the fix_modify options
+are relevant to this fix.  No global or per-atom quantities are stored
+by this fix for access by various output
+commands.  No parameter of this fix can
+be used with the start/stop keywords of the run command.
+This fix is not invoked during energy minimization.
+
      
+
      Restrictions: 
+
      
+
      This fix is part of the ASPHERE package.  It is only enabled if LAMMPS
+was built with that package.  See the Making
+LAMMPS section for more info.
+
      
+
      This fix requires that atoms store torque and angular momementum and a
+quaternion as defined by the atom_style ellipsoid
+command.
+
      
+
      All particles in the group must be finite-size.  They cannot be point
+particles, but they can be aspherical or spherical as defined by their
+shape attribute.
+
      
+
      Related commands:
+
      
+
      fix nve/noforce, fix
+nve/asphere
+
      
+
      Default: none
+
      
+
diff --git a/doc/fix_nve_asphere_noforce.txt b/doc/fix_nve_asphere_noforce.txt
new file mode 100755
index 0000000000..bc7bc698d2
--- /dev/null
+++ b/doc/fix_nve_asphere_noforce.txt
@@ -0,0 +1,65 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+fix nve/asphere/noforce command :h3
+
+[Syntax:]
+
+fix ID group-ID nve/asphere/noforce :pre
+
+ID, group-ID are documented in "fix"_fix.html command
+nve/asphere/noforce = style name of this fix command :ul
+
+[Examples:]
+
+fix 1 all nve/asphere/noforce
+
+[Description:]
+
+Perform updates of position and orientation, but not velocity or
+angular momentum for atoms in the group each timestep.  In other
+words, the force and torque on the atoms is ignored and their velocity
+and angular momentum are not updated.  The atom velocities and
+angularm momenta are used to update their positions and orientation.
+
+This is useful as an implicit time integrator for Fast Lubrication
+Dynamics, since the velocity and angular momentum are updated by the
+"pair_style lubricuteU"_pair_lubricateU.txt command.
+
+:line
+
+[Restart, fix_modify, output, run start/stop, minimize info:]
+
+No information about this fix is written to "binary restart
+files"_restart.html.  None of the "fix_modify"_fix_modify.html options
+are relevant to this fix.  No global or per-atom quantities are stored
+by this fix for access by various "output
+commands"_Section_howto.html#howto_15.  No parameter of this fix can
+be used with the {start/stop} keywords of the "run"_run.html command.
+This fix is not invoked during "energy minimization"_minimize.html.
+
+[Restrictions:] 
+
+This fix is part of the ASPHERE package.  It is only enabled if LAMMPS
+was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+This fix requires that atoms store torque and angular momementum and a
+quaternion as defined by the "atom_style ellipsoid"_atom_style.html
+command.
+
+All particles in the group must be finite-size.  They cannot be point
+particles, but they can be aspherical or spherical as defined by their
+shape attribute.
+
+[Related commands:]
+
+"fix nve/noforce"_fix_nve_noforce.html, "fix
+nve/asphere"_fix_nve_asphere.html
+
+[Default:] none
diff --git a/doc/fix_nve_eff.html b/doc/fix_nve_eff.html
index 28a9a32018..80b1509242 100644
--- a/doc/fix_nve_eff.html
+++ b/doc/fix_nve_eff.html
@@ -38,15 +38,15 @@ of electrons are also updated.
 
      No information about this fix is written to binary restart
 files.  None of the fix_modify options
 are relevant to this fix.  No global or per-atom quantities are stored
-by this fix for access by various output
-commands.  No parameter of this fix can be
-used with the start/stop keywords of the run command.
+by this fix for access by various output
+commands.  No parameter of this fix can
+be used with the start/stop keywords of the run command.
 This fix is not invoked during energy minimization.
 
      
 
      Restrictions:
 
      
-
      This fix is part of the "user-eff" package.  It is only enabled if
-LAMMPS was built with that package.  See the Making
+
      This fix is part of the USER-EFF package.  It is only enabled if
+LAMMPS was built with that package.  See the Making
 LAMMPS section for more info.
 
      
 
      Related commands:
diff --git a/doc/fix_nve_eff.txt b/doc/fix_nve_eff.txt
index 33f257c985..156f184dac 100644
--- a/doc/fix_nve_eff.txt
+++ b/doc/fix_nve_eff.txt
@@ -36,15 +36,15 @@ No information about this fix is written to "binary restart
 files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.  No global or per-atom quantities are stored
 by this fix for access by various "output
-commands"_Section_howto.html#4_15.  No parameter of this fix can be
-used with the {start/stop} keywords of the "run"_run.html command.
+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 "user-eff" package.  It is only enabled if
+This fix is part of the USER-EFF package.  It is only enabled if
 LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+LAMMPS"_Section_start.html#start_3 section for more info.
 
 [Related commands:]
 
diff --git a/doc/fix_nve_limit.html b/doc/fix_nve_limit.html
index 2713bb1e71..ae9d726d2c 100644
--- a/doc/fix_nve_limit.html
+++ b/doc/fix_nve_limit.html
@@ -57,9 +57,9 @@ files.  None of the fix_modify options
 are relevant to this fix.
 
      
 
      This fix computes a global scalar which can be accessed by various
-output commands.  The scalar is the count of
-how many updates of atom's velocity/position were limited by the
-maximum distance criterion.  This should be roughly the number of
+output commands.  The scalar is the
+count of how many updates of atom's velocity/position were limited by
+the maximum distance criterion.  This should be roughly the number of
 atoms so affected, except that updates occur at both the beginning and
 end of a timestep in a velocity Verlet timestepping algorithm.  This
 is a cumulative quantity for the current run, but is re-initialized to
diff --git a/doc/fix_nve_limit.txt b/doc/fix_nve_limit.txt
index 3d3a36d9c9..79cb7c30f6 100644
--- a/doc/fix_nve_limit.txt
+++ b/doc/fix_nve_limit.txt
@@ -54,9 +54,9 @@ files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.
 
 This fix computes a global scalar which can be accessed by various
-"output commands"_Section_howto.html#4_15.  The scalar is the count of
-how many updates of atom's velocity/position were limited by the
-maximum distance criterion.  This should be roughly the number of
+"output commands"_Section_howto.html#howto_15.  The scalar is the
+count of how many updates of atom's velocity/position were limited by
+the maximum distance criterion.  This should be roughly the number of
 atoms so affected, except that updates occur at both the beginning and
 end of a timestep in a velocity Verlet timestepping algorithm.  This
 is a cumulative quantity for the current run, but is re-initialized to
diff --git a/doc/fix_nve_line.html b/doc/fix_nve_line.html
new file mode 100644
index 0000000000..2a39e7b177
--- /dev/null
+++ b/doc/fix_nve_line.html
@@ -0,0 +1,60 @@
+
+
      LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
      
+
+
+
+
+
+
+
      
+
+
      fix nve/line command 
+
      
+
      Syntax:
+
      
+
      fix ID group-ID nve/line 
+
      
+
      • ID, group-ID are documented in fix command
+
      • nve/line = style name of this fix command 
+
      
+
      Examples:
+
      
+
      fix 1 all nve/line 
+
      
+
      Description:
+
      
+
      Perform constant NVE integration to update position, velocity,
+orientation, and angular velocity for line segment particles in the
+group each timestep.  V is volume; E is energy.  This creates a system
+trajectory consistent with the microcanonical ensemble.
+
      
+
      This fix differs from the fix nve command, which
+assumes point particles and only updates their position and velocity.
+
      
+
      Restart, fix_modify, output, run start/stop, minimize info:
+
      
+
      No information about this fix is written to binary restart
+files.  None of the fix_modify options
+are relevant to this fix.  No global or per-atom quantities are stored
+by this fix for access by various output
+commands.  No parameter of this fix can
+be used with the start/stop keywords of the run command.
+This fix is not invoked during energy minimization.
+
      
+
      Restrictions: 
+
      
+
      This fix is part of the ASPHERE package.  It is only enabled if LAMMPS
+was built with that package.  See the Making
+LAMMPS section for more info.
+
      
+
      This fix requires that particles be line segments as defined by the
+atom_style line command.
+
      
+
      Related commands:
+
      
+
      fix nve, fix nve/asphere
+
      
+
      Default: none
+
      
+
diff --git a/doc/fix_nve_line.txt b/doc/fix_nve_line.txt
new file mode 100755
index 0000000000..da93f30dbb
--- /dev/null
+++ b/doc/fix_nve_line.txt
@@ -0,0 +1,55 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+fix nve/line command :h3
+
+[Syntax:]
+
+fix ID group-ID nve/line :pre
+
+ID, group-ID are documented in "fix"_fix.html command
+nve/line = style name of this fix command :ul
+
+[Examples:]
+
+fix 1 all nve/line :pre
+
+[Description:]
+
+Perform constant NVE integration to update position, velocity,
+orientation, and angular velocity for line segment particles in the
+group each timestep.  V is volume; E is energy.  This creates a system
+trajectory consistent with the microcanonical ensemble.
+
+This fix differs from the "fix nve"_fix_nve.html command, which
+assumes point particles and only updates their position and velocity.
+
+[Restart, fix_modify, output, run start/stop, minimize info:]
+
+No information about this fix is written to "binary restart
+files"_restart.html.  None of the "fix_modify"_fix_modify.html options
+are relevant to this fix.  No global or per-atom quantities are stored
+by this fix for access by various "output
+commands"_Section_howto.html#howto_15.  No parameter of this fix can
+be used with the {start/stop} keywords of the "run"_run.html command.
+This fix is not invoked during "energy minimization"_minimize.html.
+
+[Restrictions:] 
+
+This fix is part of the ASPHERE package.  It is only enabled if LAMMPS
+was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+This fix requires that particles be line segments as defined by the
+"atom_style line"_atom_style.html command.
+
+[Related commands:]
+
+"fix nve"_fix_nve.html, "fix nve/asphere"_fix_nve_asphere.html
+
+[Default:] none
diff --git a/doc/fix_nve_noforce.html b/doc/fix_nve_noforce.html
index 01c32cb80f..8150e5668a 100644
--- a/doc/fix_nve_noforce.html
+++ b/doc/fix_nve_noforce.html
@@ -43,9 +43,9 @@ fcm() group function to compute the total force on the group of atoms.
 
      No information about this fix is written to binary restart
 files.  None of the fix_modify options
 are relevant to this fix.  No global or per-atom quantities are stored
-by this fix for access by various output
-commands.  No parameter of this fix can be
-used with the start/stop keywords of the run command.
+by this fix for access by various output
+commands.  No parameter of this fix can
+be used with the start/stop keywords of the run command.
 This fix is not invoked during energy minimization.
 
      
 
      Restrictions: none
diff --git a/doc/fix_nve_noforce.txt b/doc/fix_nve_noforce.txt
index 61abe4e16a..a0dbcc80f1 100644
--- a/doc/fix_nve_noforce.txt
+++ b/doc/fix_nve_noforce.txt
@@ -41,8 +41,8 @@ No information about this fix is written to "binary restart
 files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.  No global or per-atom quantities are stored
 by this fix for access by various "output
-commands"_Section_howto.html#4_15.  No parameter of this fix can be
-used with the {start/stop} keywords of the "run"_run.html command.
+commands"_Section_howto.html#howto_15.  No parameter of this fix can
+be used with the {start/stop} keywords of the "run"_run.html command.
 This fix is not invoked during "energy minimization"_minimize.html.
 
 [Restrictions:] none
diff --git a/doc/fix_nve_sphere.html b/doc/fix_nve_sphere.html
index 6b18a50188..f2f5678cd7 100644
--- a/doc/fix_nve_sphere.html
+++ b/doc/fix_nve_sphere.html
@@ -11,6 +11,8 @@
 
 
      fix nve/sphere command 
 
      
+
      fix nve/sphere/omp command 
+
      
 
      Syntax:
 
      
 
      fix ID group-ID nve/sphere 
@@ -46,28 +48,53 @@ assumes point particles and only updates their position and velocity.
 
      If the update keyword is used with the dipole value, then the
 orientation of the dipole moment of each particle is also updated
 during the time integration.  This option should be used for models
-where a dipole moment is assigned to particles via the
-dipole command.
+where a dipole moment is assigned to particles via use of the
+atom_style dipole command.
 
      
+
      
+
+
      Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
      
+
      These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
      
+
      You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
      
+
      See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
      
+
      
+
 
      Restart, fix_modify, output, run start/stop, minimize info:
 
      
 
      No information about this fix is written to binary restart
 files.  None of the fix_modify options
 are relevant to this fix.  No global or per-atom quantities are stored
-by this fix for access by various output
-commands.  No parameter of this fix can be
-used with the start/stop keywords of the run command.
+by this fix for access by various output
+commands.  No parameter of this fix can
+be used with the start/stop keywords of the run command.
 This fix is not invoked during energy minimization.
 
      
 
      Restrictions: 
 
      
 
      This fix requires that atoms store torque and angular velocity (omega)
-as defined by the atom_style.  It also require they
-store either a per-particle diameter or per-type shape.  If
-the dipole keyword is used, then they must store a dipole moment.
+and a radius as defined by the atom_style sphere
+command.  If the dipole keyword is used, then they must also store a
+dipole moment as defined by the atom_style dipole
+command.
 
      
 
      All particles in the group must be finite-size spheres.  They cannot
-be point particles, nor can they be aspherical.
+be point particles.
 
      
 
      Related commands:
 
      
diff --git a/doc/fix_nve_sphere.txt b/doc/fix_nve_sphere.txt
index 6796d55f9e..3c5864d3f4 100755
--- a/doc/fix_nve_sphere.txt
+++ b/doc/fix_nve_sphere.txt
@@ -7,6 +7,7 @@
 :line
 
 fix nve/sphere command :h3
+fix nve/sphere/omp command :h3
 
 [Syntax:]
 
@@ -38,8 +39,32 @@ assumes point particles and only updates their position and velocity.
 If the {update} keyword is used with the {dipole} value, then the
 orientation of the dipole moment of each particle is also updated
 during the time integration.  This option should be used for models
-where a dipole moment is assigned to particles via the
-"dipole"_dipole.html command.
+where a dipole moment is assigned to particles via use of the
+"atom_style dipole"_atom_style.html command.
+
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
 
 [Restart, fix_modify, output, run start/stop, minimize info:]
 
@@ -47,19 +72,20 @@ No information about this fix is written to "binary restart
 files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.  No global or per-atom quantities are stored
 by this fix for access by various "output
-commands"_Section_howto.html#4_15.  No parameter of this fix can be
-used with the {start/stop} keywords of the "run"_run.html command.
+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 requires that atoms store torque and angular velocity (omega)
-as defined by the "atom_style"_atom_style.html.  It also require they
-store either a per-particle diameter or per-type "shape"_shape.html.  If
-the {dipole} keyword is used, then they must store a dipole moment.
+and a radius as defined by the "atom_style sphere"_atom_style.html
+command.  If the {dipole} keyword is used, then they must also store a
+dipole moment as defined by the "atom_style dipole"_atom_style.html
+command.
 
 All particles in the group must be finite-size spheres.  They cannot
-be point particles, nor can they be aspherical.
+be point particles.
 
 [Related commands:]
 
diff --git a/doc/fix_nve_tri.html b/doc/fix_nve_tri.html
new file mode 100644
index 0000000000..cddb90aba3
--- /dev/null
+++ b/doc/fix_nve_tri.html
@@ -0,0 +1,60 @@
+
+
      LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
      
+
+
+
+
+
+
+
      
+
+
      fix nve/tri command 
+
      
+
      Syntax:
+
      
+
      fix ID group-ID nve/tri 
+
      
+
      • ID, group-ID are documented in fix command
+
      • nve/tri = style name of this fix command 
+
      
+
      Examples:
+
      
+
      fix 1 all nve/tri 
+
      
+
      Description:
+
      
+
      Perform constant NVE integration to update position, velocity,
+orientation, and angular momentum for triangular particles in the
+group each timestep.  V is volume; E is energy.  This creates a system
+trajectory consistent with the microcanonical ensemble.
+
      
+
      This fix differs from the fix nve command, which
+assumes point particles and only updates their position and velocity.
+
      
+
      Restart, fix_modify, output, run start/stop, minimize info:
+
      
+
      No information about this fix is written to binary restart
+files.  None of the fix_modify options
+are relevant to this fix.  No global or per-atom quantities are stored
+by this fix for access by various output
+commands.  No parameter of this fix can
+be used with the start/stop keywords of the run command.
+This fix is not invoked during energy minimization.
+
      
+
      Restrictions: 
+
      
+
      This fix is part of the ASPHERE package.  It is only enabled if LAMMPS
+was built with that package.  See the Making
+LAMMPS section for more info.
+
      
+
      This fix requires that particles be triangles as defined by the
+atom_style tri command.
+
      
+
      Related commands:
+
      
+
      fix nve, fix nve/asphere
+
      
+
      Default: none
+
      
+
diff --git a/doc/fix_nve_tri.txt b/doc/fix_nve_tri.txt
new file mode 100755
index 0000000000..6ea568b4ea
--- /dev/null
+++ b/doc/fix_nve_tri.txt
@@ -0,0 +1,55 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+fix nve/tri command :h3
+
+[Syntax:]
+
+fix ID group-ID nve/tri :pre
+
+ID, group-ID are documented in "fix"_fix.html command
+nve/tri = style name of this fix command :ul
+
+[Examples:]
+
+fix 1 all nve/tri :pre
+
+[Description:]
+
+Perform constant NVE integration to update position, velocity,
+orientation, and angular momentum for triangular particles in the
+group each timestep.  V is volume; E is energy.  This creates a system
+trajectory consistent with the microcanonical ensemble.
+
+This fix differs from the "fix nve"_fix_nve.html command, which
+assumes point particles and only updates their position and velocity.
+
+[Restart, fix_modify, output, run start/stop, minimize info:]
+
+No information about this fix is written to "binary restart
+files"_restart.html.  None of the "fix_modify"_fix_modify.html options
+are relevant to this fix.  No global or per-atom quantities are stored
+by this fix for access by various "output
+commands"_Section_howto.html#howto_15.  No parameter of this fix can
+be used with the {start/stop} keywords of the "run"_run.html command.
+This fix is not invoked during "energy minimization"_minimize.html.
+
+[Restrictions:] 
+
+This fix is part of the ASPHERE package.  It is only enabled if LAMMPS
+was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+This fix requires that particles be triangles as defined by the
+"atom_style tri"_atom_style.html command.
+
+[Related commands:]
+
+"fix nve"_fix_nve.html, "fix nve/asphere"_fix_nve_asphere.html
+
+[Default:] none
diff --git a/doc/fix_nvt_asphere.html b/doc/fix_nvt_asphere.html
index 09c292126c..903d3bccb7 100644
--- a/doc/fix_nvt_asphere.html
+++ b/doc/fix_nvt_asphere.html
@@ -112,18 +112,17 @@ quantities as does the fix nvt command.
 
      
 
      Restrictions:
 
      
-
      This fix is part of the "asphere" package.  It is only enabled if
-LAMMPS was built with that package.  See the Making
+
      This fix is part of the ASPHERE package.  It is only enabled if LAMMPS
+was built with that package.  See the Making
 LAMMPS section for more info.
 
      
-
      This fix requires that atoms store torque and angular momentum and a
-quaternion to represent their orientation, as defined by the
-atom_style.  It also require they store a per-type
-shape.  The particles cannot store a per-particle
-diameter or per-particle mass.
+
      This fix requires that atoms store torque and angular momementum and a
+quaternion as defined by the atom_style ellipsoid
+command.
 
      
 
      All particles in the group must be finite-size.  They cannot be point
-particles, but they can be aspherical or spherical.
+particles, but they can be aspherical or spherical as defined by their
+shape attribute.
 
      
 
      Related commands:
 
      
diff --git a/doc/fix_nvt_asphere.txt b/doc/fix_nvt_asphere.txt
index 8e32fdeaf8..8af5be1288 100755
--- a/doc/fix_nvt_asphere.txt
+++ b/doc/fix_nvt_asphere.txt
@@ -109,18 +109,17 @@ This fix is not invoked during "energy minimization"_minimize.html.
 
 [Restrictions:]
 
-This fix is part of the "asphere" package.  It is only enabled if
-LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+This fix is part of the ASPHERE package.  It is only enabled if LAMMPS
+was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
 
-This fix requires that atoms store torque and angular momentum and a
-quaternion to represent their orientation, as defined by the
-"atom_style"_atom_style.html.  It also require they store a per-type
-"shape"_shape.html.  The particles cannot store a per-particle
-diameter or per-particle mass.
+This fix requires that atoms store torque and angular momementum and a
+quaternion as defined by the "atom_style ellipsoid"_atom_style.html
+command.
 
 All particles in the group must be finite-size.  They cannot be point
-particles, but they can be aspherical or spherical.
+particles, but they can be aspherical or spherical as defined by their
+shape attribute.
 
 [Related commands:]
 
diff --git a/doc/fix_nvt_sllod_eff.html b/doc/fix_nvt_sllod_eff.html
index e1fdf0c048..072b124356 100644
--- a/doc/fix_nvt_sllod_eff.html
+++ b/doc/fix_nvt_sllod_eff.html
@@ -71,8 +71,8 @@ quantities as does the fix nvt/eff command.
 
      
 
      Restrictions: 
 
      
-
      This fix is part of the "user-eff" package.  It is only enabled if
-LAMMPS was built with that package.  See the Making
+
      This fix is part of the USER-EFF package.  It is only enabled if
+LAMMPS was built with that package.  See the Making
 LAMMPS section for more info.
 
      
 
      This fix works best without Nose-Hoover chain thermostats, i.e. using
diff --git a/doc/fix_nvt_sllod_eff.txt b/doc/fix_nvt_sllod_eff.txt
index 697640a5be..c2d397097c 100644
--- a/doc/fix_nvt_sllod_eff.txt
+++ b/doc/fix_nvt_sllod_eff.txt
@@ -68,9 +68,9 @@ This fix is not invoked during "energy minimization"_minimize.html.
 
 [Restrictions:] 
 
-This fix is part of the "user-eff" package.  It is only enabled if
+This fix is part of the USER-EFF package.  It is only enabled if
 LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+LAMMPS"_Section_start.html#start_3 section for more info.
 
 This fix works best without Nose-Hoover chain thermostats, i.e. using
 tchain = 1.  Setting tchain to larger values can result in poor
diff --git a/doc/fix_nvt_sphere.html b/doc/fix_nvt_sphere.html
index 31bf453926..e1c2fa1ce2 100644
--- a/doc/fix_nvt_sphere.html
+++ b/doc/fix_nvt_sphere.html
@@ -113,11 +113,11 @@ quantities as does the fix nvt command.
 
      Restrictions:
 
      
 
      This fix requires that atoms store torque and angular velocity (omega)
-as defined by the atom_style.  It also require they
-store either a per-particle radius or per-type shape.
+and a radius as defined by the atom_style sphere
+command.
 
      
 
      All particles in the group must be finite-size spheres.  They cannot
-be point particles, nor can they be aspherical.
+be point particles.
 
      
 
      Related commands:
 
      
diff --git a/doc/fix_nvt_sphere.txt b/doc/fix_nvt_sphere.txt
index ef7865489e..7c9ddc99a7 100755
--- a/doc/fix_nvt_sphere.txt
+++ b/doc/fix_nvt_sphere.txt
@@ -110,11 +110,11 @@ This fix is not invoked during "energy minimization"_minimize.html.
 [Restrictions:]
 
 This fix requires that atoms store torque and angular velocity (omega)
-as defined by the "atom_style"_atom_style.html.  It also require they
-store either a per-particle radius or per-type "shape"_shape.html.
+and a radius as defined by the "atom_style sphere"_atom_style.html
+command.
 
 All particles in the group must be finite-size spheres.  They cannot
-be point particles, nor can they be aspherical.
+be point particles.
 
 [Related commands:]
 
diff --git a/doc/fix_orient_fcc.html b/doc/fix_orient_fcc.html
index 99ab333eca..65be97ec45 100644
--- a/doc/fix_orient_fcc.html
+++ b/doc/fix_orient_fcc.html
@@ -127,14 +127,14 @@ boundary driving force to the system's potential energy as part of
 thermodynamic output.
 
      
 
      This fix calculates a global scalar which can be accessed by various
-output commands.  The scalar is the
+output commands.  The scalar is the
 potential energy change due to this fix.  The scalar value calculated
 by this fix is "extensive".
 
      
 
      This fix also calculates a per-atom array which can be accessed by
-various output commands.  The array stores
-the order parameter Xi and normalized order parameter (0 to 1) for
-each atom.  The per-atom values can be accessed on any timestep.
+various output commands.  The array
+stores the order parameter Xi and normalized order parameter (0 to 1)
+for each atom.  The per-atom values can be accessed on any timestep.
 
      
 
      No parameter of this fix can be used with the start/stop keywords of
 the run command.  This fix is not invoked during energy
diff --git a/doc/fix_orient_fcc.txt b/doc/fix_orient_fcc.txt
index 4b634e8d5c..bde9f08ddf 100644
--- a/doc/fix_orient_fcc.txt
+++ b/doc/fix_orient_fcc.txt
@@ -124,14 +124,14 @@ boundary driving force to the system's potential energy as part of
 "thermodynamic output"_thermo_style.html.
 
 This fix calculates a global scalar which can be accessed by various
-"output commands"_Section_howto.html#4_15.  The scalar is the
+"output commands"_Section_howto.html#howto_15.  The scalar is the
 potential energy change due to this fix.  The scalar value calculated
 by this fix is "extensive".
 
 This fix also calculates a per-atom array which can be accessed by
-various "output commands"_Section_howto.html#4_15.  The array stores
-the order parameter Xi and normalized order parameter (0 to 1) for
-each atom.  The per-atom values can be accessed on any timestep.
+various "output commands"_Section_howto.html#howto_15.  The array
+stores the order parameter Xi and normalized order parameter (0 to 1)
+for each atom.  The per-atom values can be accessed on any timestep.
 
 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
diff --git a/doc/fix_planeforce.html b/doc/fix_planeforce.html
index aefcd57f82..d2e465c612 100644
--- a/doc/fix_planeforce.html
+++ b/doc/fix_planeforce.html
@@ -38,9 +38,9 @@ should continue to move in the plane thereafter.
 
      No information about this fix is written to binary restart
 files.  None of the fix_modify options
 are relevant to this fix.  No global or per-atom quantities are stored
-by this fix for access by various output
-commands.  No parameter of this fix can be
-used with the start/stop keywords of the run command.
+by this fix for access by various output
+commands.  No parameter of this fix can
+be used with the start/stop keywords of the run command.
 
      
 
      The forces due to this fix are imposed during an energy minimization,
 invoked by the minimize command.
diff --git a/doc/fix_planeforce.txt b/doc/fix_planeforce.txt
index a36c0f8896..133ed61bde 100644
--- a/doc/fix_planeforce.txt
+++ b/doc/fix_planeforce.txt
@@ -36,8 +36,8 @@ No information about this fix is written to "binary restart
 files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.  No global or per-atom quantities are stored
 by this fix for access by various "output
-commands"_Section_howto.html#4_15.  No parameter of this fix can be
-used with the {start/stop} keywords of the "run"_run.html command.
+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.
 
 The forces due to this fix are imposed during an energy minimization,
 invoked by the "minimize"_minimize.html command.
diff --git a/doc/fix_poems.html b/doc/fix_poems.html
index 11806aa60a..0bc381f4e6 100644
--- a/doc/fix_poems.html
+++ b/doc/fix_poems.html
@@ -115,16 +115,16 @@ off, and there is only a single fix poems defined.
 
      No information about this fix is written to binary restart
 files.  None of the fix_modify options
 are relevant to this fix.  No global or per-atom quantities are stored
-by this fix for access by various output
-commands.  No parameter of this fix can be
-used with the start/stop keywords of the run command.
+by this fix for access by various output
+commands.  No parameter of this fix can
+be used with the start/stop keywords of the run command.
 This fix is not invoked during energy minimization.
 
      
 
      Restrictions:
 
      
-
      This fix is part of the "poems" package.  It is only enabled if LAMMPS
+
      This fix is part of the POEMS package.  It is only enabled if LAMMPS
 was built with that package, which also requires the POEMS library be
-built and linked with LAMMPS.  See the Making
+built and linked with LAMMPS.  See the Making
 LAMMPS section for more info.
 
      
 
      Related commands:
diff --git a/doc/fix_poems.txt b/doc/fix_poems.txt
index f37f1dd89a..d90d832cb8 100644
--- a/doc/fix_poems.txt
+++ b/doc/fix_poems.txt
@@ -109,16 +109,16 @@ No information about this fix is written to "binary restart
 files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.  No global or per-atom quantities are stored
 by this fix for access by various "output
-commands"_Section_howto.html#4_15.  No parameter of this fix can be
-used with the {start/stop} keywords of the "run"_run.html command.
+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 "poems" package.  It is only enabled if LAMMPS
+This fix is part of the POEMS package.  It is only enabled if LAMMPS
 was built with that package, which also requires the POEMS library be
 built and linked with LAMMPS.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+LAMMPS"_Section_start.html#start_3 section for more info.
 
 [Related commands:]
 
diff --git a/doc/fix_pour.html b/doc/fix_pour.html
index 8970402686..8ef12fa784 100644
--- a/doc/fix_pour.html
+++ b/doc/fix_pour.html
@@ -120,15 +120,15 @@ appropriately.
 
      
 
      None of the fix_modify options are relevant to this
 fix.  No global or per-atom quantities are stored by this fix for
-access by various output commands.  No
+access by various output commands.  No
 parameter of this fix can be used with the start/stop keywords of
 the run command.  This fix is not invoked during energy
 minimization.
 
      
 
      Restrictions:
 
      
-
      This fix is part of the "granular" package.  It is only enabled if
-LAMMPS was built with that package.  See the Making
+
      This fix is part of the GRANULAR package.  It is only enabled if
+LAMMPS was built with that package.  See the Making
 LAMMPS section for more info.
 
      
 
      For 3d simulations, a gravity fix in the -z direction must be defined
diff --git a/doc/fix_pour.txt b/doc/fix_pour.txt
index 54e22b66cd..e1521809cf 100644
--- a/doc/fix_pour.txt
+++ b/doc/fix_pour.txt
@@ -109,16 +109,16 @@ appropriately.
 
 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#4_15.  No
+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
+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#2_3 section for more info.
+LAMMPS"_Section_start.html#start_3 section for more info.
 
 For 3d simulations, a gravity fix in the -z direction must be defined
 for use in conjunction with this fix.  For 2d simulations, gravity
diff --git a/doc/fix_press_berendsen.html b/doc/fix_press_berendsen.html
index e86d9be9af..673c1b3436 100644
--- a/doc/fix_press_berendsen.html
+++ b/doc/fix_press_berendsen.html
@@ -64,8 +64,8 @@ conjunction with thermostatting fixes to control the temperature, such
 as fix nvt or fix langevin or fix
 temp/berendsen.
 
      
-
      See this howto section of the manual for a
-discussion of different ways to compute temperature and perform
+
      See this howto section of the manual for
+a discussion of different ways to compute temperature and perform
 thermostatting and barostatting.
 
      
 
      
@@ -194,7 +194,7 @@ pressure.  LAMMPS will warn you if you choose to compute temperature
 on a subset of atoms.
 
      
 
      No global or per-atom quantities are stored by this fix for access by
-various output commands.
+various output commands.
 
      
 
      This fix can ramp its target pressure over multiple runs, using the
 start and stop keywords of the run command.  See the
diff --git a/doc/fix_press_berendsen.txt b/doc/fix_press_berendsen.txt
index b3dbf3ea7e..eda073703c 100644
--- a/doc/fix_press_berendsen.txt
+++ b/doc/fix_press_berendsen.txt
@@ -58,8 +58,8 @@ conjunction with thermostatting fixes to control the temperature, such
 as "fix nvt"_fix_nh.html or "fix langevin"_fix_langevin.html or "fix
 temp/berendsen"_fix_temp_berendsen.html.
 
-See "this howto section"_Section_howto.html#4_16 of the manual for a
-discussion of different ways to compute temperature and perform
+See "this howto section"_Section_howto.html#howto_16 of the manual for
+a discussion of different ways to compute temperature and perform
 thermostatting and barostatting.
 
 :line
@@ -188,7 +188,7 @@ pressure.  LAMMPS will warn you if you choose to compute temperature
 on a subset of atoms.
 
 No global or per-atom quantities are stored by this fix for access by
-various "output commands"_Section_howto.html#4_15.
+various "output commands"_Section_howto.html#howto_15.
 
 This fix can ramp its target pressure over multiple runs, using the
 {start} and {stop} keywords of the "run"_run.html command.  See the
diff --git a/doc/fix_print.html b/doc/fix_print.html
index 5a4282a777..98b233769b 100644
--- a/doc/fix_print.html
+++ b/doc/fix_print.html
@@ -81,9 +81,9 @@ keyword was used.  By default, the title line is as follows:
 
      No information about this fix is written to binary restart
 files.  None of the fix_modify options
 are relevant to this fix.  No global or per-atom quantities are stored
-by this fix for access by various output
-commands.  No parameter of this fix can be
-used with the start/stop keywords of the run command.
+by this fix for access by various output
+commands.  No parameter of this fix can
+be used with the start/stop keywords of the run command.
 This fix is not invoked during energy minimization.
 
      
 
      Restrictions: none
diff --git a/doc/fix_print.txt b/doc/fix_print.txt
index 7827bc6aef..0ac44ef9b6 100644
--- a/doc/fix_print.txt
+++ b/doc/fix_print.txt
@@ -72,8 +72,8 @@ No information about this fix is written to "binary restart
 files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.  No global or per-atom quantities are stored
 by this fix for access by various "output
-commands"_Section_howto.html#4_15.  No parameter of this fix can be
-used with the {start/stop} keywords of the "run"_run.html command.
+commands"_Section_howto.html#howto_15.  No parameter of this fix can
+be used with the {start/stop} keywords of the "run"_run.html command.
 This fix is not invoked during "energy minimization"_minimize.html.
 
 [Restrictions:] none
diff --git a/doc/fix_qeq_comb.html b/doc/fix_qeq_comb.html
index e9c854f163..c66b49dc4d 100644
--- a/doc/fix_qeq_comb.html
+++ b/doc/fix_qeq_comb.html
@@ -11,6 +11,8 @@
 
 
      fix qeq/comb command 
 
      
+
      fix qeq/comb/omp command 
+
      
 
      Syntax:
 
      
 
      fix ID group-ID qeq/comb Nevery precision keyword value ... 
@@ -38,12 +40,14 @@
 
      
 
      Description:
 
      
-
      This fix is designed for use with the pair_style comb command which
-implements the COMB COMB (Charge-Optimized Many-Body) potential as
-described in (COMB_1) and (COMB_2).  It performs
-the charge equilibration portion of the calculation using the
-so-called QEq method, whereby the charge on each atom is adjusted to
-minimize the energy of the system.
+
      Perform charge equilibration (QeQ) in conjunction with the COMB
+(Charge-Optimized Many-Body) potential as described in
+(COMB_1) and (COMB_2).  It performs the charge
+equilibration portion of the calculation using the so-called QEq
+method, whereby the charge on each atom is adjusted to minimize the
+energy of the system.  This fix can only be used with the COMB
+potential; see the fix qeq/reax command for a QeQ
+calculation that can be used with any potential.
 
      
 
      Only charges on the atoms in the specified group are equilibrated.
 The fix relies on the pair style (COMB in this case) to calculate the
@@ -64,6 +68,30 @@ performing charge equilibration (more iterations) and accuracy.
 
      If the file keyword is used, then information about each
 equilibration calculation is written to the specifed file.
 
      
+
      
+
+
      Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
      
+
      These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
      
+
      You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
      
+
      See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
      
+
      
+
 
      Restart, fix_modify, output, run start/stop, minimize info:
 
      
 
      No information about this fix is written to binary restart
@@ -71,7 +99,7 @@ files.  None of the fix_modify options
 are relevant to this fix.
 
      
 
      This fix produces a per-atom vector which can be accessed by various
-output commands.  The vector stores the
+output commands.  The vector stores the
 gradient of the charge on each atom.  The per-atom values be accessed
 on any timestep.
 
      
diff --git a/doc/fix_qeq_comb.txt b/doc/fix_qeq_comb.txt
index ee787f0774..3fbb9dc7b9 100644
--- a/doc/fix_qeq_comb.txt
+++ b/doc/fix_qeq_comb.txt
@@ -7,6 +7,7 @@
 :line
 
 fix qeq/comb command :h3
+fix qeq/comb/omp command :h3
 
 [Syntax:]
 
@@ -28,12 +29,14 @@ fix 1 surface qeq/comb 10 0.0001 :pre
 
 [Description:]
 
-This fix is designed for use with the pair_style comb command which
-implements the COMB COMB (Charge-Optimized Many-Body) potential as
-described in "(COMB_1)"_#COMB_1 and "(COMB_2)"_#COMB_2.  It performs
-the charge equilibration portion of the calculation using the
-so-called QEq method, whereby the charge on each atom is adjusted to
-minimize the energy of the system.
+Perform charge equilibration (QeQ) in conjunction with the COMB
+(Charge-Optimized Many-Body) potential as described in
+"(COMB_1)"_#COMB_1 and "(COMB_2)"_#COMB_2.  It performs the charge
+equilibration portion of the calculation using the so-called QEq
+method, whereby the charge on each atom is adjusted to minimize the
+energy of the system.  This fix can only be used with the COMB
+potential; see the "fix qeq/reax"_fix_qeq_reqx.html command for a QeQ
+calculation that can be used with any potential.
 
 Only charges on the atoms in the specified group are equilibrated.
 The fix relies on the pair style (COMB in this case) to calculate the
@@ -54,6 +57,30 @@ performing charge equilibration (more iterations) and accuracy.
 If the {file} keyword is used, then information about each
 equilibration calculation is written to the specifed file.
 
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restart, fix_modify, output, run start/stop, minimize info:]
 
 No information about this fix is written to "binary restart
@@ -61,7 +88,7 @@ files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.
 
 This fix produces a per-atom vector which can be accessed by various
-"output commands"_Section_howto.html#4_15.  The vector stores the
+"output commands"_Section_howto.html#howto_15.  The vector stores the
 gradient of the charge on each atom.  The per-atom values be accessed
 on any timestep.
 
diff --git a/doc/fix_qeq_reax.html b/doc/fix_qeq_reax.html
index 590a22b1ba..f2b47635e7 100644
--- a/doc/fix_qeq_reax.html
+++ b/doc/fix_qeq_reax.html
@@ -33,7 +33,12 @@ fix 1 all qeq/reax 1 0.0 10.0 1.0e-6 param.qeq
 and Goddard, 1991) and formulated in (Nakano,
 1997).  It is typically used in conjunction with the
 ReaxFF force field model as implemented in the pair_style
-reax/c command.
+reax/c command, but it can be used with any
+potential in LAMMPS, so long as it defines and uses charges on each
+atom.  The fix qeq/comb command should be used to
+perform charge equliibration with the COMB potential.
+For more technical details about the charge equilibration performed by
+fix qeq/reax, see the "(Aktulga)" paper.
 
      
 
      The QEq method minimizes the electrostatic energy of the system by
 adjusting the partial charge on individual atoms based on interactions
@@ -42,8 +47,9 @@ If the params setting above is the word "reax/c", then these are
 extracted from the pair_style reax/c command and
 the ReaxFF force field file it reads in.  If a file name is specified
 for params, then the parameters are taken from the specified file
-and the file must contain one line for each atom type.  Each line
-should be formatted as follows:
+and the file must contain one line for each atom type.  The latter
+form must be used when performing QeQ with a non-ReaxFF potential.
+Each line should be formatted as follows:
 
      
 
      itype chi eta gamma 
 
      
@@ -59,18 +65,22 @@ of this fix are hard-coded to be A, eV, and electronic charge.
 
      
 
      No information about this fix is written to binary restart
 files.  No global scalar or vector or per-atom
-quantities are stored by this fix for access by various output
-commands.  No parameter of this fix can be
-used with the start/stop keywords of the run command.
+quantities are stored by this fix for access by various output
+commands.  No parameter of this fix can
+be used with the start/stop keywords of the run command.
 
      
 
      This fix is invoked during energy minimization.
 
      
 
      Restrictions:
 
      
-
      This fix is part of the "user-reaxc" package.  It is only enabled if
-LAMMPS was built with that package.  See the Making
+
      This fix is part of the USER-REAXC package.  It is only enabled if
+LAMMPS was built with that package.  See the Making
 LAMMPS section for more info.
 
      
+
      This fix does not correctly handle interactions
+involving multiple periodic images of the same atom. Hence, it should not
+be used for periodic cell dimensions less than 10 angstroms. 
+
      
 
      Related commands:
 
      
 
      pair_style reax/c
@@ -88,4 +98,7 @@ LAMMPS section for more info.
 
 
      (Nakano) Nakano, Computer Physics Communications, 104, 59-69 (1997).
 
      
+
      :link(Aktulga) (Aktulga) Aktulga, Fogarty, Pandit, Grama, Parallel
+Computing, to appear (2011).
+
      
 
diff --git a/doc/fix_qeq_reax.txt b/doc/fix_qeq_reax.txt
index fd18e5a553..4f45ecefd2 100644
--- a/doc/fix_qeq_reax.txt
+++ b/doc/fix_qeq_reax.txt
@@ -30,7 +30,12 @@ Perform the charge equilibration (QEq) method as described in "(Rappe
 and Goddard, 1991)"_#Rappe_1991 and formulated in "(Nakano,
 1997)"_#Nakano_1997.  It is typically used in conjunction with the
 ReaxFF force field model as implemented in the "pair_style
-reax/c"_pair_reax_c.html command.
+reax/c"_pair_reax_c.html command, but it can be used with any
+potential in LAMMPS, so long as it defines and uses charges on each
+atom.  The "fix qeq/comb"_fix_qeq_comb.html command should be used to
+perform charge equliibration with the "COMB potential"_pair_comb.html.
+For more technical details about the charge equilibration performed by
+fix qeq/reax, see the "(Aktulga)" paper.
 
 The QEq method minimizes the electrostatic energy of the system by
 adjusting the partial charge on individual atoms based on interactions
@@ -39,8 +44,9 @@ If the {params} setting above is the word "reax/c", then these are
 extracted from the "pair_style reax/c"_pair_reax_c.html command and
 the ReaxFF force field file it reads in.  If a file name is specified
 for {params}, then the parameters are taken from the specified file
-and the file must contain one line for each atom type.  Each line
-should be formatted as follows:
+and the file must contain one line for each atom type.  The latter
+form must be used when performing QeQ with a non-ReaxFF potential.
+Each line should be formatted as follows:
 
 itype chi eta gamma :pre
 
@@ -57,16 +63,20 @@ of this fix are hard-coded to be A, eV, and electronic charge.
 No information about this fix is written to "binary restart
 files"_restart.html.  No global scalar or vector or per-atom
 quantities are stored by this fix for access by various "output
-commands"_Section_howto.html#4_15.  No parameter of this fix can be
-used with the {start/stop} keywords of the "run"_run.html command.
+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 invoked during "energy minimization"_minimize.html.
 
 [Restrictions:]
 
-This fix is part of the "user-reaxc" package.  It is only enabled if
+This fix is part of the USER-REAXC package.  It is only enabled if
 LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+This fix does not correctly handle interactions
+involving multiple periodic images of the same atom. Hence, it should not
+be used for periodic cell dimensions less than 10 angstroms. 
 
 [Related commands:]
 
@@ -82,3 +92,6 @@ LAMMPS"_Section_start.html#2_3 section for more info.
 
 :link(Nakano_1997)
 [(Nakano)] Nakano, Computer Physics Communications, 104, 59-69 (1997).
+
+:link(Aktulga) [(Aktulga)] Aktulga, Fogarty, Pandit, Grama, Parallel
+Computing, to appear (2011).
diff --git a/doc/fix_reax_bonds.html b/doc/fix_reax_bonds.html
index 113b2c9827..09f23c1f19 100644
--- a/doc/fix_reax_bonds.html
+++ b/doc/fix_reax_bonds.html
@@ -40,17 +40,17 @@ including timestep 0.
 
      No information about this fix is written to binary restart
 files.  None of the fix_modify options
 are relevant to this fix.  No global or per-atom quantities are stored
-by this fix for access by various output
-commands.  No parameter of this fix can be
-used with the start/stop keywords of the run command.
+by this fix for access by various output
+commands.  No parameter of this fix can
+be used with the start/stop keywords of the run command.
 This fix is not invoked during energy minimization.
 
      
 
      Restrictions:
 
      
 
      This fix requires that the pair_style reax be
-invoked.  This fix is part of the "reax" package.  It is only enabled
-if LAMMPS was built with that package, which also requires the REAX
-library be built and linked with LAMMPS.  See the Making
+invoked.  This fix is part of the REAX package.  It is only enabled if
+LAMMPS was built with that package, which also requires the REAX
+library be built and linked with LAMMPS.  See the Making
 LAMMPS section for more info.
 
      
 
      Related commands:
diff --git a/doc/fix_reax_bonds.txt b/doc/fix_reax_bonds.txt
index 7414083e04..5ebb2a5265 100644
--- a/doc/fix_reax_bonds.txt
+++ b/doc/fix_reax_bonds.txt
@@ -38,17 +38,17 @@ No information about this fix is written to "binary restart
 files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.  No global or per-atom quantities are stored
 by this fix for access by various "output
-commands"_Section_howto.html#4_15.  No parameter of this fix can be
-used with the {start/stop} keywords of the "run"_run.html command.
+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 requires that the "pair_style reax"_pair_reax.html be
-invoked.  This fix is part of the "reax" package.  It is only enabled
-if LAMMPS was built with that package, which also requires the REAX
+invoked.  This fix is part of the REAX package.  It is only enabled if
+LAMMPS was built with that package, which also requires the REAX
 library be built and linked with LAMMPS.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+LAMMPS"_Section_start.html#start_3 section for more info.
 
 [Related commands:]
 
diff --git a/doc/fix_recenter.html b/doc/fix_recenter.html
index d4a08370d8..f62b289062 100644
--- a/doc/fix_recenter.html
+++ b/doc/fix_recenter.html
@@ -100,9 +100,9 @@ to tether the molecule in place.
 
      No information about this fix is written to binary restart
 files.  None of the fix_modify options
 are relevant to this fix.  No global or per-atom quantities are stored
-by this fix for access by various output
-commands.  No parameter of this fix can be
-used with the start/stop keywords of the run command.
+by this fix for access by various output
+commands.  No parameter of this fix can
+be used with the start/stop keywords of the run command.
 This fix is not invoked during energy minimization.
 
      
 
      Restrictions:
diff --git a/doc/fix_recenter.txt b/doc/fix_recenter.txt
index 6040f51780..5242c0fa47 100644
--- a/doc/fix_recenter.txt
+++ b/doc/fix_recenter.txt
@@ -93,8 +93,8 @@ No information about this fix is written to "binary restart
 files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.  No global or per-atom quantities are stored
 by this fix for access by various "output
-commands"_Section_howto.html#4_15.  No parameter of this fix can be
-used with the {start/stop} keywords of the "run"_run.html command.
+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:]
diff --git a/doc/fix_restrain.html b/doc/fix_restrain.html
new file mode 100644
index 0000000000..d42f07cc09
--- /dev/null
+++ b/doc/fix_restrain.html
@@ -0,0 +1,150 @@
+
+
      LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
      
+
+
+
+
+
+
+
      
+
+
      fix restrain command 
+
      
+
      Syntax:
+
      
+
      fix ID group-ID restrain Kstart Kstop keyword value(s) 
+
      
+
      • ID, group-ID are documented in fix command 
+
+
      • restrain = style name of this fix command 
+
+
      • Kstart, Kstop = restraint coefficient at start/end of run (energy
+units) 
+
+
      • one keyword with one or more sets of parameter values may be appended to args 
+
+
      • keyword = dihedral  
+
+
          dihedral value = atom1 atom2 atom3 atom4 target
+    atom1,atom2,atom3,atom4 = IDs of 4 atoms in restrained dihedral
+    target = target value for specified dihedral angle (degrees) 
+
        
+
+
      
+
      Examples:
+
      
+
      fix holdem all restrain 2000.0 2000.0 dihedral 1 2 3 4 120.0
+fix texas_holdem all restrain 0.0 2000.0 dihedral 1 2 3 4 120.0 1 2 3 5 -120.0 1 2 3 6 0.0 
+
      
+
      Description:
+
      
+
      Restrain the motion of the specified atoms by making them part of a
+bond or angle or dihedral interaction whose strength can vary over
+time during a simulation.  This is functionally equivalent to creating
+a bond or angle or dihedral for the atoms in a data file, as specified
+by the read_data command, albeit with a time-varying
+pre-factor coefficient.  For the purpose of forcefield
+parameter-fitting or mapping a molecular potential energy surface,
+this fix reduces the hassle and risk associated with modifying data
+files.  In other words, use this fix to temporarily force a molecule
+to adopt a particular conformation. To form a permanent bond or angle
+or dihedral, modify the data file.
+
      
+
      The first example above applies a restraint to hold the dihedral angle
+formed by atoms 1, 2, 3, and 4 near 120 degrees using a constant
+restraint coefficient.  The second example applies similar restraints
+to multiple dihedral angles using a restraint coefficient that
+increases from 0.0 to 2000.0 over the course of the run.
+
      
+
      IMPORTANT NOTE: Adding a force to atoms implies a change in their
+potential energy as they move due to the applied force field.  For
+dynamics via the run command, this energy can be added to
+the system's potential energy for thermodynamic output (see below).
+For energy minimization via the minimize command, this
+energy must be added to the system's potential energy to formulate a
+self-consistent minimization problem (see below).
+
      
+
      In order for a restraint to be effective, the restraint force must
+typically be significantly larger than the forces associated with
+conventional forcefield terms. If the restraint is applied during a
+dynamics run (as opposed to during an energy minimization), a large
+restraint coefficient can significantly reduce the stable timestep
+size, especially if the atoms are initially far from the preferred
+conformation.  You may need to experiment to determine what value of K
+works best for a given application.
+
      
+
      For the case of finding a minimum energy structure for a single
+molecule with particular restratins (e.g. for fitting forcefield
+parameters or constructing a potential energy surface), commands such
+as the following might be useful:
+
      
+
      # minimize molecule energy with restraints
+velocity all create 600.0 8675309 mom yes rot yes dist gaussian
+fix NVE all nve
+fix TFIX all langevin 600.0 0.0 100 24601
+fix REST all restrain 0.0 5000.0 dihedral 2 1 3 8 $angle1 3 1 2 9 $angle2
+fix_modify REST energy yes
+run 10000
+fix TFIX all langevin 0.0 0.0 100 24601
+fix REST all restrain 5000.0 5000.0 dihedral 2 1 3 8 $angle1 3 1 2 9 $angle2
+fix_modify REST energy yes
+run 10000
+# sanity check for convergence
+minimize 1e-6 1e-9 1000 100000
+# report unrestrained energies
+unfix REST
+run 0 
+
      
+
      
+
+
      The dihedral keyword applies a dihedral restraint to the specified
+atoms using a simplified form of the function used in dihedral_style
+charmm. Specifically, the potential associated
+with the restraint is
+
      
+
      
+
      
+
      with the following coefficients:
+
      
+
      • K (energy) = K (specified above)
+
      • n = 1
+
      • d (degrees) = 180.0 + target (specified above) 
+
      
+
      
+
+
      Restart, fix_modify, output, run start/stop, minimize info:
+
      
+
      No information about this fix is written to binary restart
+files.
+
      
+
      The fix_modify energy option is supported by this
+fix to add the potential energy associated with this fix to the
+system's potential energy as part of thermodynamic
+output.
+
      
+
      IMPORTANT NOTE: If you want the fictitious potential energy associated
+with the added forces to be included in the total potential energy of
+the system (the quantity being minimized), you MUST enable the
+fix_modify energy option for this fix.
+
      
+
      This fix computes a global scalar, which can be accessed by various
+output commands.  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 command.
+
      
+
      Restrictions:
+
      
+
      The group-ID specified by this fix is ignored.
+
      
+
      Currently, only dihedral restraints are allowed, but modification of
+the code to allow angle and bond restraints would be straightforward.
+
      
+
      Related commands: none
+
      
+
      Default: none
+
      
+
diff --git a/doc/fix_restrain.txt b/doc/fix_restrain.txt
new file mode 100644
index 0000000000..f70eded736
--- /dev/null
+++ b/doc/fix_restrain.txt
@@ -0,0 +1,139 @@
+"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 restrain command :h3
+
+[Syntax:]
+
+fix ID group-ID restrain Kstart Kstop keyword value(s) :pre
+
+ID, group-ID are documented in "fix"_fix.html command :ulb,l
+restrain = style name of this fix command :l
+Kstart, Kstop = restraint coefficient at start/end of run (energy
+units) :l
+one keyword with one or more sets of parameter values may be appended to args :l
+keyword = {dihedral}  :l
+  {dihedral} value = atom1 atom2 atom3 atom4 target
+    atom1,atom2,atom3,atom4 = IDs of 4 atoms in restrained dihedral
+    target = target value for specified dihedral angle (degrees) :pre
+:ule
+
+[Examples:]
+
+fix holdem all restrain 2000.0 2000.0 dihedral 1 2 3 4 120.0
+fix texas_holdem all restrain 0.0 2000.0 dihedral 1 2 3 4 120.0 1 2 3 5 -120.0 1 2 3 6 0.0 :pre
+
+[Description:]
+
+Restrain the motion of the specified atoms by making them part of a
+bond or angle or dihedral interaction whose strength can vary over
+time during a simulation.  This is functionally equivalent to creating
+a bond or angle or dihedral for the atoms in a data file, as specified
+by the "read_data"_read_data.html command, albeit with a time-varying
+pre-factor coefficient.  For the purpose of forcefield
+parameter-fitting or mapping a molecular potential energy surface,
+this fix reduces the hassle and risk associated with modifying data
+files.  In other words, use this fix to temporarily force a molecule
+to adopt a particular conformation. To form a permanent bond or angle
+or dihedral, modify the data file.
+
+The first example above applies a restraint to hold the dihedral angle
+formed by atoms 1, 2, 3, and 4 near 120 degrees using a constant
+restraint coefficient.  The second example applies similar restraints
+to multiple dihedral angles using a restraint coefficient that
+increases from 0.0 to 2000.0 over the course of the run.
+
+IMPORTANT NOTE: Adding a force to atoms implies a change in their
+potential energy as they move due to the applied force field.  For
+dynamics via the "run"_run.html command, this energy can be added to
+the system's potential energy for thermodynamic output (see below).
+For energy minimization via the "minimize"_minimize.html command, this
+energy must be added to the system's potential energy to formulate a
+self-consistent minimization problem (see below).
+
+In order for a restraint to be effective, the restraint force must
+typically be significantly larger than the forces associated with
+conventional forcefield terms. If the restraint is applied during a
+dynamics run (as opposed to during an energy minimization), a large
+restraint coefficient can significantly reduce the stable timestep
+size, especially if the atoms are initially far from the preferred
+conformation.  You may need to experiment to determine what value of K
+works best for a given application.
+
+For the case of finding a minimum energy structure for a single
+molecule with particular restratins (e.g. for fitting forcefield
+parameters or constructing a potential energy surface), commands such
+as the following might be useful:
+
+# minimize molecule energy with restraints
+velocity all create 600.0 8675309 mom yes rot yes dist gaussian
+fix NVE all nve
+fix TFIX all langevin 600.0 0.0 100 24601
+fix REST all restrain 0.0 5000.0 dihedral 2 1 3 8 ${angle1} 3 1 2 9 ${angle2}
+fix_modify REST energy yes
+run 10000
+fix TFIX all langevin 0.0 0.0 100 24601
+fix REST all restrain 5000.0 5000.0 dihedral 2 1 3 8 ${angle1} 3 1 2 9 ${angle2}
+fix_modify REST energy yes
+run 10000
+# sanity check for convergence
+minimize 1e-6 1e-9 1000 100000
+# report unrestrained energies
+unfix REST
+run 0 :pre
+
+:line
+
+The {dihedral} keyword applies a dihedral restraint to the specified
+atoms using a simplified form of the function used in "dihedral_style
+charmm"_dihedral_charmm.html. Specifically, the potential associated
+with the restraint is
+
+:c,image(Eqs/dihedral_charmm.jpg)
+
+with the following coefficients:
+
+K (energy) = K (specified above)
+n = 1
+d (degrees) = 180.0 + target (specified above) :ul
+
+: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 associated with this fix to the
+system's potential energy as part of "thermodynamic
+output"_thermo_style.html.
+
+IMPORTANT NOTE: If you want the fictitious potential energy associated
+with the added 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.
+
+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.
+
+[Restrictions:]
+
+The group-ID specified by this fix is ignored.
+
+Currently, only dihedral restraints are allowed, but modification of
+the code to allow angle and bond restraints would be straightforward.
+
+[Related commands:] none
+
+[Default:] none
diff --git a/doc/fix_rigid.html b/doc/fix_rigid.html
index 30b76c1867..c15ed3ecfe 100644
--- a/doc/fix_rigid.html
+++ b/doc/fix_rigid.html
@@ -33,9 +33,13 @@
 
      
 
    • zero or more keyword/value pairs may be appended 
 
-
    • keyword = temp or press or tparam or pparam or force or torque 
+
    • keyword = langevin or temp or tparam or force or torque 
 
-
        temp values = Tstart Tstop Tperiod
+
        langevin values = Tstart Tstop Tperiod seed
+    Tstart,Tstop = desired temperature at start/stop of run (temperature units)
+    Tdamp = temperature damping parameter (time units)
+    seed = random number seed to use for white noise (positive integer)
+  temp values = Tstart Tstop Tdamp
     Tstart,Tstop = desired temperature at start/stop of run (temperature units)
     Tdamp = temperature damping parameter (time units)
   tparam values = Tchain Titer Torder
@@ -54,7 +58,7 @@
 
      Examples:
 
      
 
      fix 1 clump rigid single
-fix 1 clump rigid single force 1 off off on
+fix 1 clump rigid single force 1 off off on langevin 1.0 1.0 1.0 428984
 fix 1 polychains rigid/nvt molecule temp 1.0 1.0 5.0
 fix 1 polychains rigid molecule force 1*5 off off off force 6*10 off off on
 fix 2 fluid rigid group 3 clump1 clump2 clump3 torque * off off off 
@@ -74,12 +78,13 @@ portions of a large biomolecule such as a protein.
 
      Example of small rigid bodies are patchy nanoparticles, such as those
 modeled in this paper by Sharon Glotzer's group, clumps of
 granular particles, lipid molecules consiting of one or more point
-dipoles connected to other spheroids or ellipsoids, and coarse-grain
-models of nano or colloidal particles consisting of a small number of
-constituent particles.  Note that the fix shake
-command can also be used to rigidify small molecules of 2, 3, or 4
-atoms, e.g. water molecules.  That fix treats the constituent atoms as
-point masses.
+dipoles connected to other spheroids or ellipsoids, irregular
+particles built from line segments (2d) or triangles (3d), and
+coarse-grain models of nano or colloidal particles consisting of a
+small number of constituent particles.  Note that the fix
+shake command can also be used to rigidify small
+molecules of 2, 3, or 4 atoms, e.g. water molecules.  That fix treats
+the constituent atoms as point masses.
 
      
 
      These fixes also update the positions and velocities of the atoms in
 each rigid body via time integration.  The rigid and rigid/nve
@@ -114,14 +119,14 @@ setforce command), and integrating them as usual
 
      
 
 
      The constituent particles within a rigid body can be point particles
-(the default in LAMMPS) or finite-size particles, such as spheroids
-and ellipsoids.  See the shape command and atom_style
-granular for more details on these kinds of
-particles.  Finite-size particles contribute differently to the moment
-of inertia of a rigid body than do point particles.  Finite-size
-particles can also experience torque (e.g. due to frictional granular
-interactions) and have an orientation.  These
-contributions are accounted for by these fixes.
+(the default in LAMMPS) or finite-size particles, such as spheres or
+ellipsoids or line segments or triangles.  See the atom_style sphere
+and ellipsoid and line and tri commands for more
+details on these kinds of particles.  Finite-size particles contribute
+differently to the moment of inertia of a rigid body than do point
+particles.  Finite-size particles can also experience torque (e.g. due
+to frictional granular interactions) and have an
+orientation.  These contributions are accounted for by these fixes.
 
      
 
      Forces between particles within a body do not contribute to the
 external force or torque on the body.  Thus for computational
@@ -200,19 +205,35 @@ multiple rigid fixes to be defined, but it is more expensive.
 
      
 
      
 
-
      As stated above, the rigid and rigid/nve styles perform constant
-NVE time integration.  Thus the temp, press, and tparam keywords
-cannot be used with these styles.
+
      The keyword/value option pairs are used in the following ways.
 
      
-
      The rigid/nvt style performs constant NVT time integration, using a
-temperature it computes for the rigid bodies which includes their
-translational and rotational motion.  The temp keyword must be used
-with this style.  The desired temperature at each timestep is a ramped
-value during the run from Tstart to Tstop.  The Tdamp parameter
-is specified in time units and determines how rapidly the temperature
-is relaxed.  For example, a value of 100.0 means to relax the
-temperature in a timespan of (roughly) 100 time units (tau or fmsec or
-psec - see the units command).
+
      The langevin and temp and tparam keywords perform thermostatting
+of the rigid bodies, altering both their translational and rotational
+degrees of freedom.  What is meant by "temperature" of a collection of
+rigid bodies and how it can be monitored via the fix output is
+discussed below.
+
      
+
      The langevin keyword applies a Langevin thermostat to the constant
+NVE time integration performed by either the rigid or rigid/nve
+styles.  It cannot be used with the rigid/nvt style.  The desired
+temperature at each timestep is a ramped value during the run from
+Tstart to Tstop.  The Tdamp parameter is specified in time units
+and determines how rapidly the temperature is relaxed.  For example, a
+value of 100.0 means to relax the temperature in a timespan of
+(roughly) 100 time units (tau or fmsec or psec - see the
+units command).  The random # seed must be a positive
+integer.  The way the Langevin thermostatting operates is explained on
+the fix langevin doc page.
+
      
+
      The temp and tparam keywords apply a Nose/Hoover thermostat to the
+NVT time integration performed by the rigid/nvt style.  They cannot
+be used with the rigid or rigid/nve styles.  The desired
+temperature at each timestep is a ramped value during the run from
+Tstart to Tstop.  The Tdamp parameter is specified in time units
+and determines how rapidly the temperature is relaxed.  For example, a
+value of 100.0 means to relax the temperature in a timespan of
+(roughly) 100 time units (tau or fmsec or psec - see the
+units command).
 
      
 
      Nose/Hoover chains are used in conjunction with this thermostat.  The
 tparam keyword can optionally be used to change the chain settings
@@ -222,18 +243,22 @@ oscillations in temperature that can occur in a simulation.  As a rule
 of thumb, increasing the chain length should lead to smaller
 oscillations.
 
      
-
      There are alternate ways to thermostat a system of rigid bodies.  You
-can use fix langevin to treat the system as
-effectively immersed in an implicit solvent, e.g. a Brownian dynamics
-model.  For hybrid systems with both rigid bodies and solvent
-particles, you can thermostat only the solvent particles that surround
-one or more rigid bodies by appropriate choice of groups in the
-compute and fix commands for temperature and thermostatting.  The
-solvent interactions with the rigid bodies should then effectively
-thermostat the rigid body temperature as well.
+
      IMPORTANT NOTE: There are alternate ways to thermostat a system of
+rigid bodies.  You can use fix langevin to treat
+the individual particles in the rigid bodies as effectively immersed
+in an implicit solvent, e.g. a Brownian dynamics model.  For hybrid
+systems with both rigid bodies and solvent particles, you can
+thermostat only the solvent particles that surround one or more rigid
+bodies by appropriate choice of groups in the compute and fix commands
+for temperature and thermostatting.  The solvent interactions with the
+rigid bodies should then effectively thermostat the rigid body
+temperature as well without use of the Langevin or Nose/Hoover options
+associated with the fix rigid commands.
 
      
 
      
 
+
      The keyword/value option pairs are used in the following ways.
+
      
 
      If you use a temperature compute with a group that
 includes particles in rigid bodies, the degrees-of-freedom removed by
 each rigid body are accounted for in the temperature (and pressure)
@@ -289,23 +314,36 @@ rigid/nvt fix to add the energy change induced by the thermostatting
 to the system's potential energy as part of thermodynamic
 output.
 
      
+
      The rigid and rigid/nve fixes computes a global scalar which can be
+accessed by various output commands.
+The scalar value calculated by these fixes is "intensive".  The scalar
+is the current temperature of the collection of rigid bodies.  This is
+averaged over all rigid bodies and their translational and rotational
+degrees of freedom.  The translational energy of a rigid body is 1/2 m
+v^2, where m = total mass of the body and v = the velocity of its
+center of mass.  The rotational energy of a rigid body is 1/2 I w^2,
+where I = the moment of inertia tensor of the body and w = its angular
+velocity.  Degrees of freedom constrained by the force and torque
+keywords are removed from this calculation.
+
      
 
      The rigid/nvt fix computes a global scalar which can be accessed by
-various output commands.  The scalar value
-calculated by the rigid/nvt fix is "extensive".  The scalar is the
-cumulative energy change due to the thermostatting the fix performs.
+various output commands.  The scalar
+value calculated by the rigid/nvt fix is "extensive".  The scalar is
+the cumulative energy change due to the thermostatting the fix
+performs.
 
      
 
      All of these fixes compute a global array of values which can be
-accessed by various output commands.  The
-number of rows in the array is equal to the number of rigid bodies.
-The number of columns is 15.  Thus for each rigid body, 15 values are
-stored: the xyz coords of the center of mass (COM), the xyz components
-of the COM velocity, the xyz components of the force acting on the
-COM, the xyz components of the torque acting on the COM, and the xyz
-image flags of the COM, which have the same meaning as image flags for
-atom positions (see the "dump" command).  The force and torque values
-in the array are not affected by the force and torque keywords in
-the fix rigid command; they reflect values before any changes are made
-by those keywords.
+accessed by various output commands.
+The number of rows in the array is equal to the number of rigid
+bodies.  The number of columns is 15.  Thus for each rigid body, 15
+values are stored: the xyz coords of the center of mass (COM), the xyz
+components of the COM velocity, the xyz components of the force acting
+on the COM, the xyz components of the torque acting on the COM, and
+the xyz image flags of the COM, which have the same meaning as image
+flags for atom positions (see the "dump" command).  The force and
+torque values in the array are not affected by the force and
+torque keywords in the fix rigid command; they reflect values before
+any changes are made by those keywords.
 
      
 
      The ordering of the rigid bodies (by row in the array) is as follows.
 For the single keyword there is just one rigid body.  For the
diff --git a/doc/fix_rigid.txt b/doc/fix_rigid.txt
index f304e6083c..3d49aedd6d 100644
--- a/doc/fix_rigid.txt
+++ b/doc/fix_rigid.txt
@@ -24,8 +24,12 @@ bodystyle = {single} or {molecule} or {group} :l
     groupID1, groupID2, ... = list of N group IDs :pre
 
 zero or more keyword/value pairs may be appended :l
-keyword = {temp} or {press} or {tparam} or {pparam} or {force} or {torque} :l
-  {temp} values = Tstart Tstop Tperiod
+keyword = {langevin} or {temp} or {tparam} or {force} or {torque} :l
+  {langevin} values = Tstart Tstop Tperiod seed
+    Tstart,Tstop = desired temperature at start/stop of run (temperature units)
+    Tdamp = temperature damping parameter (time units)
+    seed = random number seed to use for white noise (positive integer)
+  {temp} values = Tstart Tstop Tdamp
     Tstart,Tstop = desired temperature at start/stop of run (temperature units)
     Tdamp = temperature damping parameter (time units)
   {tparam} values = Tchain Titer Torder
@@ -43,7 +47,7 @@ keyword = {temp} or {press} or {tparam} or {pparam} or {force} or {torque} :l
 [Examples:]
 
 fix 1 clump rigid single
-fix 1 clump rigid single force 1 off off on
+fix 1 clump rigid single force 1 off off on langevin 1.0 1.0 1.0 428984
 fix 1 polychains rigid/nvt molecule temp 1.0 1.0 5.0
 fix 1 polychains rigid molecule force 1*5 off off off force 6*10 off off on
 fix 2 fluid rigid group 3 clump1 clump2 clump3 torque * off off off :pre
@@ -63,12 +67,13 @@ portions of a large biomolecule such as a protein.
 Example of small rigid bodies are patchy nanoparticles, such as those
 modeled in "this paper"_#Zhang by Sharon Glotzer's group, clumps of
 granular particles, lipid molecules consiting of one or more point
-dipoles connected to other spheroids or ellipsoids, and coarse-grain
-models of nano or colloidal particles consisting of a small number of
-constituent particles.  Note that the "fix shake"_fix_shake.html
-command can also be used to rigidify small molecules of 2, 3, or 4
-atoms, e.g. water molecules.  That fix treats the constituent atoms as
-point masses.
+dipoles connected to other spheroids or ellipsoids, irregular
+particles built from line segments (2d) or triangles (3d), and
+coarse-grain models of nano or colloidal particles consisting of a
+small number of constituent particles.  Note that the "fix
+shake"_fix_shake.html command can also be used to rigidify small
+molecules of 2, 3, or 4 atoms, e.g. water molecules.  That fix treats
+the constituent atoms as point masses.
 
 These fixes also update the positions and velocities of the atoms in
 each rigid body via time integration.  The {rigid} and {rigid/nve}
@@ -103,14 +108,14 @@ setforce"_fix_setforce.html command), and integrating them as usual
 :line
 
 The constituent particles within a rigid body can be point particles
-(the default in LAMMPS) or finite-size particles, such as spheroids
-and ellipsoids.  See the "shape"_shape.html command and "atom_style
-granular"_atom_style.html for more details on these kinds of
-particles.  Finite-size particles contribute differently to the moment
-of inertia of a rigid body than do point particles.  Finite-size
-particles can also experience torque (e.g. due to "frictional granular
-interactions"_pair_gran.html) and have an orientation.  These
-contributions are accounted for by these fixes.
+(the default in LAMMPS) or finite-size particles, such as spheres or
+ellipsoids or line segments or triangles.  See the "atom_style sphere
+and ellipsoid and line and tri"_atom_style.html commands for more
+details on these kinds of particles.  Finite-size particles contribute
+differently to the moment of inertia of a rigid body than do point
+particles.  Finite-size particles can also experience torque (e.g. due
+to "frictional granular interactions"_pair_gran.html) and have an
+orientation.  These contributions are accounted for by these fixes.
 
 Forces between particles within a body do not contribute to the
 external force or torque on the body.  Thus for computational
@@ -189,19 +194,35 @@ multiple rigid fixes to be defined, but it is more expensive.
 
 :line
 
-As stated above, the {rigid} and {rigid/nve} styles perform constant
-NVE time integration.  Thus the {temp}, {press}, and {tparam} keywords
-cannot be used with these styles.
+The keyword/value option pairs are used in the following ways.
 
-The {rigid/nvt} style performs constant NVT time integration, using a
-temperature it computes for the rigid bodies which includes their
-translational and rotational motion.  The {temp} keyword must be used
-with this style.  The desired temperature at each timestep is a ramped
-value during the run from {Tstart} to {Tstop}.  The {Tdamp} parameter
-is specified in time units and determines how rapidly the temperature
-is relaxed.  For example, a value of 100.0 means to relax the
-temperature in a timespan of (roughly) 100 time units (tau or fmsec or
-psec - see the "units"_units.html command).
+The {langevin} and {temp} and {tparam} keywords perform thermostatting
+of the rigid bodies, altering both their translational and rotational
+degrees of freedom.  What is meant by "temperature" of a collection of
+rigid bodies and how it can be monitored via the fix output is
+discussed below.
+
+The {langevin} keyword applies a Langevin thermostat to the constant
+NVE time integration performed by either the {rigid} or {rigid/nve}
+styles.  It cannot be used with the {rigid/nvt} style.  The desired
+temperature at each timestep is a ramped value during the run from
+{Tstart} to {Tstop}.  The {Tdamp} parameter is specified in time units
+and determines how rapidly the temperature is relaxed.  For example, a
+value of 100.0 means to relax the temperature in a timespan of
+(roughly) 100 time units (tau or fmsec or psec - see the
+"units"_units.html command).  The random # {seed} must be a positive
+integer.  The way the Langevin thermostatting operates is explained on
+the "fix langevin"_fix_langevin.html doc page.
+
+The {temp} and {tparam} keywords apply a Nose/Hoover thermostat to the
+NVT time integration performed by the {rigid/nvt} style.  They cannot
+be used with the {rigid} or {rigid/nve} styles.  The desired
+temperature at each timestep is a ramped value during the run from
+{Tstart} to {Tstop}.  The {Tdamp} parameter is specified in time units
+and determines how rapidly the temperature is relaxed.  For example, a
+value of 100.0 means to relax the temperature in a timespan of
+(roughly) 100 time units (tau or fmsec or psec - see the
+"units"_units.html command).
 
 Nose/Hoover chains are used in conjunction with this thermostat.  The
 {tparam} keyword can optionally be used to change the chain settings
@@ -211,18 +232,22 @@ oscillations in temperature that can occur in a simulation.  As a rule
 of thumb, increasing the chain length should lead to smaller
 oscillations.
 
-There are alternate ways to thermostat a system of rigid bodies.  You
-can use "fix langevin"_fix_langevin.html to treat the system as
-effectively immersed in an implicit solvent, e.g. a Brownian dynamics
-model.  For hybrid systems with both rigid bodies and solvent
-particles, you can thermostat only the solvent particles that surround
-one or more rigid bodies by appropriate choice of groups in the
-compute and fix commands for temperature and thermostatting.  The
-solvent interactions with the rigid bodies should then effectively
-thermostat the rigid body temperature as well.
+IMPORTANT NOTE: There are alternate ways to thermostat a system of
+rigid bodies.  You can use "fix langevin"_fix_langevin.html to treat
+the individual particles in the rigid bodies as effectively immersed
+in an implicit solvent, e.g. a Brownian dynamics model.  For hybrid
+systems with both rigid bodies and solvent particles, you can
+thermostat only the solvent particles that surround one or more rigid
+bodies by appropriate choice of groups in the compute and fix commands
+for temperature and thermostatting.  The solvent interactions with the
+rigid bodies should then effectively thermostat the rigid body
+temperature as well without use of the Langevin or Nose/Hoover options
+associated with the fix rigid commands.
 
 :line
 
+The keyword/value option pairs are used in the following ways.
+
 If you use a "temperature compute"_compute.html with a group that
 includes particles in rigid bodies, the degrees-of-freedom removed by
 each rigid body are accounted for in the temperature (and pressure)
@@ -278,23 +303,36 @@ rigid/nvt fix to add the energy change induced by the thermostatting
 to the system's potential energy as part of "thermodynamic
 output"_thermo_style.html.
 
+The rigid and rigid/nve fixes computes a global scalar which can be
+accessed by various "output commands"_Section_howto.html#howto_15.
+The scalar value calculated by these fixes is "intensive".  The scalar
+is the current temperature of the collection of rigid bodies.  This is
+averaged over all rigid bodies and their translational and rotational
+degrees of freedom.  The translational energy of a rigid body is 1/2 m
+v^2, where m = total mass of the body and v = the velocity of its
+center of mass.  The rotational energy of a rigid body is 1/2 I w^2,
+where I = the moment of inertia tensor of the body and w = its angular
+velocity.  Degrees of freedom constrained by the {force} and {torque}
+keywords are removed from this calculation.
+
 The rigid/nvt fix computes a global scalar which can be accessed by
-various "output commands"_Section_howto.html#4_15.  The scalar value
-calculated by the rigid/nvt fix is "extensive".  The scalar is the
-cumulative energy change due to the thermostatting the fix performs.
+various "output commands"_Section_howto.html#howto_15.  The scalar
+value calculated by the rigid/nvt fix is "extensive".  The scalar is
+the cumulative energy change due to the thermostatting the fix
+performs.
 
 All of these fixes compute a global array of values which can be
-accessed by various "output commands"_Section_howto.html#4_15.  The
-number of rows in the array is equal to the number of rigid bodies.
-The number of columns is 15.  Thus for each rigid body, 15 values are
-stored: the xyz coords of the center of mass (COM), the xyz components
-of the COM velocity, the xyz components of the force acting on the
-COM, the xyz components of the torque acting on the COM, and the xyz
-image flags of the COM, which have the same meaning as image flags for
-atom positions (see the "dump" command).  The force and torque values
-in the array are not affected by the {force} and {torque} keywords in
-the fix rigid command; they reflect values before any changes are made
-by those keywords.
+accessed by various "output commands"_Section_howto.html#howto_15.
+The number of rows in the array is equal to the number of rigid
+bodies.  The number of columns is 15.  Thus for each rigid body, 15
+values are stored: the xyz coords of the center of mass (COM), the xyz
+components of the COM velocity, the xyz components of the force acting
+on the COM, the xyz components of the torque acting on the COM, and
+the xyz image flags of the COM, which have the same meaning as image
+flags for atom positions (see the "dump" command).  The force and
+torque values in the array are not affected by the {force} and
+{torque} keywords in the fix rigid command; they reflect values before
+any changes are made by those keywords.
 
 The ordering of the rigid bodies (by row in the array) is as follows.
 For the {single} keyword there is just one rigid body.  For the
diff --git a/doc/fix_setforce.html b/doc/fix_setforce.html
index 747678ae10..6e713254d4 100644
--- a/doc/fix_setforce.html
+++ b/doc/fix_setforce.html
@@ -11,6 +11,8 @@
 
 
      fix setforce command 
 
      
+
      fix setforce/cuda command 
+
      
 
      Syntax:
 
      
 
      fix ID group-ID setforce fx fy fz keyword value ... 
@@ -72,6 +74,29 @@ field with optional time-dependence as well.
 specified geometric region in order to have force added
 to it.
 
      
+
      
+
+
      Styles with a cuda 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
+this section of the manual.  The accelerated
+styles take the same arguments and should produce the same results,
+except for round-off and precision issues.
+
      
+
      These accelerated styles are part of the USER-CUDA package.  They are
+only enabled if LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
      
+
      You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
      
+
      See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
      
+
      
+
 
      Restart, fix_modify, output, run start/stop, minimize info:
 
      
 
      No information about this fix is written to binary restart
@@ -79,7 +104,7 @@ files.  None of the fix_modify options
 are relevant to this fix.
 
      
 
      This fix computes a global 3-vector of forces, which can be accessed
-by various output commands.  This is the
+by various output commands.  This is the
 total force on the group of atoms before the forces on individual
 atoms are changed by the fix.  The vector values calculated by this
 fix are "extensive".
diff --git a/doc/fix_setforce.txt b/doc/fix_setforce.txt
index a1c28b24de..90404f0324 100644
--- a/doc/fix_setforce.txt
+++ b/doc/fix_setforce.txt
@@ -7,6 +7,7 @@
 :line
 
 fix setforce command :h3
+fix setforce/cuda command :h3
 
 [Syntax:]
 
@@ -62,6 +63,29 @@ If the {region} keyword is used, the atom must also be in the
 specified geometric "region"_region.html in order to have force added
 to it.
 
+:line
+
+Styles with a {cuda} 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
+"this section"_Section_accelerate.html of the manual.  The accelerated
+styles take the same arguments and should produce the same results,
+except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA package.  They are
+only enabled if LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restart, fix_modify, output, run start/stop, minimize info:]
 
 No information about this fix is written to "binary restart
@@ -69,7 +93,7 @@ files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.
 
 This fix computes a global 3-vector of forces, which can be accessed
-by various "output commands"_Section_howto.html#4_15.  This is the
+by various "output commands"_Section_howto.html#howto_15.  This is the
 total force on the group of atoms before the forces on individual
 atoms are changed by the fix.  The vector values calculated by this
 fix are "extensive".
diff --git a/doc/fix_shake.html b/doc/fix_shake.html
index 60889344b4..a5aad277aa 100644
--- a/doc/fix_shake.html
+++ b/doc/fix_shake.html
@@ -11,6 +11,8 @@
 
 
      fix shake command 
 
      
+
      fix shake/cuda command 
+
      
 
      Syntax:
 
      
 
      fix ID group-ID shake tol iter N keyword values ... 
@@ -86,14 +88,37 @@ for in temperature and pressure computations.  Similarly, the SHAKE
 contribution to the pressure of the system (virial) is also accounted
 for.
 
      
+
      
+
+
      Styles with a cuda 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
+this section of the manual.  The accelerated
+styles take the same arguments and should produce the same results,
+except for round-off and precision issues.
+
      
+
      These accelerated styles are part of the USER-CUDA package.  They are
+only enabled if LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
      
+
      You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
      
+
      See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
      
+
      
+
 
      Restart, fix_modify, output, run start/stop, minimize info:
 
      
 
      No information about this fix is written to binary restart
 files.  None of the fix_modify options
 are relevant to this fix.  No global or per-atom quantities are stored
-by this fix for access by various output
-commands.  No parameter of this fix can be
-used with the start/stop keywords of the run command.
+by this fix for access by various output
+commands.  No parameter of this fix can
+be used with the start/stop keywords of the run command.
 This fix is not invoked during energy minimization.
 
      
 
      Restrictions:
diff --git a/doc/fix_shake.txt b/doc/fix_shake.txt
index 82a5361aca..dee3239bd8 100644
--- a/doc/fix_shake.txt
+++ b/doc/fix_shake.txt
@@ -7,6 +7,7 @@
 :line
 
 fix shake command :h3
+fix shake/cuda command :h3
 
 [Syntax:]
 
@@ -75,14 +76,37 @@ for in temperature and pressure computations.  Similarly, the SHAKE
 contribution to the pressure of the system (virial) is also accounted
 for.
 
+:line
+
+Styles with a {cuda} 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
+"this section"_Section_accelerate.html of the manual.  The accelerated
+styles take the same arguments and should produce the same results,
+except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA package.  They are
+only enabled if LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restart, fix_modify, output, run start/stop, minimize info:]
 
 No information about this fix is written to "binary restart
 files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.  No global or per-atom quantities are stored
 by this fix for access by various "output
-commands"_Section_howto.html#4_15.  No parameter of this fix can be
-used with the {start/stop} keywords of the "run"_run.html command.
+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:]
diff --git a/doc/fix_smd.html b/doc/fix_smd.html
index d7788a0600..ececffdc41 100644
--- a/doc/fix_smd.html
+++ b/doc/fix_smd.html
@@ -114,12 +114,12 @@ the operation of the fix continues in an uninterrupted fashion.
 fix.
 
      
 
      This fix computes a vector list of 7 quantities, which can be accessed
-by various output commands.  The quantities
-in the vector are in this order: the x-, y-, and z-component of the
-pulling force, the total force in direction of the pull, the
-equilibrium distance of the spring, the distance between the two
-reference points, and finally the accumulated PMF (the sum of pulling
-forces times displacement).
+by various output commands.  The
+quantities in the vector are in this order: the x-, y-, and
+z-component of the pulling force, the total force in direction of the
+pull, the equilibrium distance of the spring, the distance between the
+two reference points, and finally the accumulated PMF (the sum of
+pulling forces times displacement).
 
      
 
      The force is the total force on the group of atoms by the spring.  In
 the case of the couple style, it is the force on the fix group
@@ -132,8 +132,8 @@ minimization.
 
      
 
      Restrictions:
 
      
-
      This fix is part of the "user-smd" package.  It is only enabled if
-LAMMPS was built with that package.  See the Making
+
      This fix is part of the USER-MISC package.  It is only enabled if
+LAMMPS was built with that package.  See the Making
 LAMMPS section for more info.
 
      
 
      Related commands:
diff --git a/doc/fix_smd.txt b/doc/fix_smd.txt
index f3ec2a727f..d58a24eb13 100644
--- a/doc/fix_smd.txt
+++ b/doc/fix_smd.txt
@@ -105,12 +105,12 @@ None of the "fix_modify"_fix_modify.html options are relevant to this
 fix.
 
 This fix computes a vector list of 7 quantities, which can be accessed
-by various "output commands"_Section_howto.html#4_15.  The quantities
-in the vector are in this order: the x-, y-, and z-component of the
-pulling force, the total force in direction of the pull, the
-equilibrium distance of the spring, the distance between the two
-reference points, and finally the accumulated PMF (the sum of pulling
-forces times displacement).
+by various "output commands"_Section_howto.html#howto_15.  The
+quantities in the vector are in this order: the x-, y-, and
+z-component of the pulling force, the total force in direction of the
+pull, the equilibrium distance of the spring, the distance between the
+two reference points, and finally the accumulated PMF (the sum of
+pulling forces times displacement).
 
 The force is the total force on the group of atoms by the spring.  In
 the case of the {couple} style, it is the force on the fix group
@@ -123,9 +123,9 @@ minimization"_minimize.html.
 
 [Restrictions:]
 
-This fix is part of the "user-smd" package.  It is only enabled if
+This fix is part of the USER-MISC package.  It is only enabled if
 LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+LAMMPS"_Section_start.html#start_3 section for more info.
 
 [Related commands:]
 
diff --git a/doc/fix_spring.html b/doc/fix_spring.html
index d8f83fa3fb..8830056177 100644
--- a/doc/fix_spring.html
+++ b/doc/fix_spring.html
@@ -91,6 +91,17 @@ below the z = 0 center plane of the pore (umbrella sampling).  The
 last example holds the ion a distance 5 away from the pore axis
 (assuming the center-of-mass of the pore in x,y is the pore axis).
 
      
+
      IMPORTANT NOTE: The center of mass of a group of atoms is calculated
+in "unwrapped" coordinates using atom image flags, which means that
+the group can straddle a periodic boundary.  See the dump
+doc page for a discussion of unwrapped coordinates.  It also means
+that a spring connecting two groups or a group and the tether point
+can cross a periodic boundary and its length be calculated correctly.
+One exception is for rigid bodies, which should not be used with the
+fix spring command, if the rigid body will cross a periodic boundary.
+This is because image flags for rigid bodies are used in a different
+way, as explained on the fix rigid doc page.
+
      
 
      Restart, fix_modify, output, run start/stop, minimize info:
 
      
 
      No information about this fix is written to binary restart
@@ -101,11 +112,11 @@ fix to add the energy stored in the spring to the system's potential
 energy as part of thermodynamic output.
 
      
 
      This fix computes a global scalar which can be accessed by various
-output commands.  The scalar is the spring
-energy = 0.5 * K * r^2.
+output commands.  The scalar is the
+spring energy = 0.5 * K * r^2.
 
      
 
      This fix also computes global 4-vector which can be accessed by
-various output commands.  The first 3
+various output commands.  The first 3
 quantities in the vector are xyz components of the total force added
 to the group of atoms by the spring.  In the case of the couple
 style, it is the force on the fix group (group-ID) or the negative of
diff --git a/doc/fix_spring.txt b/doc/fix_spring.txt
index cf8478b327..9b65065714 100644
--- a/doc/fix_spring.txt
+++ b/doc/fix_spring.txt
@@ -84,6 +84,17 @@ below the z = 0 center plane of the pore (umbrella sampling).  The
 last example holds the ion a distance 5 away from the pore axis
 (assuming the center-of-mass of the pore in x,y is the pore axis).
 
+IMPORTANT NOTE: The center of mass of a group of atoms is calculated
+in "unwrapped" coordinates using atom image flags, which means that
+the group can straddle a periodic boundary.  See the "dump"_dump.html
+doc page for a discussion of unwrapped coordinates.  It also means
+that a spring connecting two groups or a group and the tether point
+can cross a periodic boundary and its length be calculated correctly.
+One exception is for rigid bodies, which should not be used with the
+fix spring command, if the rigid body will cross a periodic boundary.
+This is because image flags for rigid bodies are used in a different
+way, as explained on the "fix rigid"_doc/fix_rigid.html doc page.
+
 [Restart, fix_modify, output, run start/stop, minimize info:]
 
 No information about this fix is written to "binary restart
@@ -94,11 +105,11 @@ fix to add the energy stored in the spring to the 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#4_15.  The scalar is the spring
-energy = 0.5 * K * r^2.
+"output commands"_Section_howto.html#howto_15.  The scalar is the
+spring energy = 0.5 * K * r^2.
 
 This fix also computes global 4-vector which can be accessed by
-various "output commands"_Section_howto.html#4_15.  The first 3
+various "output commands"_Section_howto.html#howto_15.  The first 3
 quantities in the vector are xyz components of the total force added
 to the group of atoms by the spring.  In the case of the {couple}
 style, it is the force on the fix group (group-ID) or the negative of
diff --git a/doc/fix_spring_rg.html b/doc/fix_spring_rg.html
index e2ceba3dee..535e088be6 100644
--- a/doc/fix_spring_rg.html
+++ b/doc/fix_spring_rg.html
@@ -55,9 +55,9 @@ the time the fix is specified, and that value is used as the target.
 
      No information about this fix is written to binary restart
 files.  None of the fix_modify options
 are relevant to this fix.  No global or per-atom quantities are stored
-by this fix for access by various output
-commands.  No parameter of this fix can be
-used with the start/stop keywords of the run command.
+by this fix for access by various output
+commands.  No parameter of this fix can
+be used with the start/stop keywords of the run command.
 This fix is not invoked during energy minimization.
 
      
 
      Restrictions: none
diff --git a/doc/fix_spring_rg.txt b/doc/fix_spring_rg.txt
index c87fd486ff..768ed0cc4a 100644
--- a/doc/fix_spring_rg.txt
+++ b/doc/fix_spring_rg.txt
@@ -52,8 +52,8 @@ No information about this fix is written to "binary restart
 files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.  No global or per-atom quantities are stored
 by this fix for access by various "output
-commands"_Section_howto.html#4_15.  No parameter of this fix can be
-used with the {start/stop} keywords of the "run"_run.html command.
+commands"_Section_howto.html#howto_15.  No parameter of this fix can
+be used with the {start/stop} keywords of the "run"_run.html command.
 This fix is not invoked during "energy minimization"_minimize.html.
 
 [Restrictions:] none
diff --git a/doc/fix_spring_self.html b/doc/fix_spring_self.html
index 70e6e1afd5..22c18bc171 100644
--- a/doc/fix_spring_self.html
+++ b/doc/fix_spring_self.html
@@ -54,8 +54,8 @@ fix to add the energy stored in the per-atom springs to the system's
 potential energy as part of thermodynamic output.
 
      
 
      This fix computes a global scalar which can be accessed by various
-output commands.  The scalar is an energy
-which is the sum of the spring energy for each atom, where the
+output commands.  The scalar is an
+energy which is the sum of the spring energy for each atom, where the
 per-atom energy is 0.5 * K * r^2.  The scalar value calculated by this
 fix is "extensive".
 
      
diff --git a/doc/fix_spring_self.txt b/doc/fix_spring_self.txt
index 3e5f82a55e..bf3ff399b2 100644
--- a/doc/fix_spring_self.txt
+++ b/doc/fix_spring_self.txt
@@ -51,8 +51,8 @@ fix to add the energy stored in the per-atom springs to the 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#4_15.  The scalar is an energy
-which is the sum of the spring energy for each atom, where the
+"output commands"_Section_howto.html#howto_15.  The scalar is an
+energy which is the sum of the spring energy for each atom, where the
 per-atom energy is 0.5 * K * r^2.  The scalar value calculated by this
 fix is "extensive".
 
diff --git a/doc/fix_srd.html b/doc/fix_srd.html
index 803d3c59ef..8746be8e54 100644
--- a/doc/fix_srd.html
+++ b/doc/fix_srd.html
@@ -38,10 +38,7 @@
   cubic values = style tolerance
     style = error or warn
     tolerance = fractional difference allowed (0 <= tol <= 1)
-  shift values = style seed
-    style = no or yes or possible
-    seed = random # seed (positive integer)
-  stream value = yes or no = whether or not streaming velocity is added for shear deformation 
+  tstat value = yes or no = thermostat SRD particles or not 
 
      
 
 
    
@@ -58,13 +55,14 @@ particles that serve as a background solvent when interacting with big
 in (Hecht).  The key idea behind using SRD particles as a
 cheap coarse-grained solvent is that SRD particles do not interact
 with each other, but only with the solute particles, which in LAMMPS
-can be spheroids, ellipsoids, or rigid bodies containing multiples
-spherioids and ellipsoids.  The collision and rotation properties of
-the model imbue the SRD particles with fluid-like properties,
-including an effective viscosity.  Thus simulations with large solute
-particles can be run more quickly, to measure solute propoerties like
-diffusivity and viscosity in a background fluid.  The usual LAMMPS
-fixes for such simulations, such as fix deform, fix
+can be spheroids, ellipsoids, or line segments, or triangles, or rigid
+bodies containing multiple spherioids or ellipsoids or line segments
+or triangles.  The collision and rotation properties of the model
+imbue the SRD particles with fluid-like properties, including an
+effective viscosity.  Thus simulations with large solute particles can
+be run more quickly, to measure solute propoerties like diffusivity
+and viscosity in a background fluid.  The usual LAMMPS fixes for such
+simulations, such as fix deform, fix
 viscosity, and fix nvt/sllod,
 can be used in conjunction with the SRD model.
 
    
@@ -109,12 +107,13 @@ velocities.  Normally hgrid is set to be 1/4 of the big particle
 diameter or smaller, to adequately resolve fluid properties around the
 big particles.
 
    
-
    Lamda cannot be smaller than 0.6 * hgrid, else an error is generated.
-The velocities of SRD particles are bounded by Vmax, which is set so
-that an SRD particle will not advect further than Dmax = 4*lamda in
-dt_SRD.  This means that roughly speaking, Dmax should not be larger
-than a big particle diameter, else SRDs may pass thru big particles
-without colliding.  A warning is generated if this is the case.
+
    Lamda cannot be smaller than 0.6 * hgrid, else an error is generated
+(unless the shift keyword is used, see below).  The velocities of
+SRD particles are bounded by Vmax, which is set so that an SRD
+particle will not advect further than Dmax = 4*lamda in dt_SRD.  This
+means that roughly speaking, Dmax should not be larger than a big
+particle diameter, else SRDs may pass thru big particles without
+colliding.  A warning is generated if this is the case.
 
    
 
    Collisions between SRD particles and big particles or walls are
 modeled as a lightweight SRD point particle hitting a heavy big
@@ -271,15 +270,19 @@ must still be specified.
 
    Note that shifting of SRD coordinates requires extra communication,
 hence it should not normally be enabled unless required.
 
    
-
    The stream keyword should be used when SRD particles are used with
-the fix deform command to perform a simulation
-undergoing shear, e.g. to measure a viscosity.  If the stream style
-is set to yes, then the mean velocity of each bin of SRD particles
-is set to the streaming velocity of the deforming box, each time SRD
-velocities are reset, every N timesteps.  If the stream style is set
-to no, then the mean velocity is unchanged, which may mean that it
-takes a long time for the SRD fluid to come to equilibrium with a
-velocity profile that matches the simulation box deformation.
+
    The tstat keyword will thermostat the SRD particles to the specified
+Tsrd.  This is done every N timesteps, during the velocity rotation
+operation, by rescaling the thermal velocity of particles in each SRD
+bin to the desired temperature.  If there is a streaming velocity
+associated with the system, e.g. due to use of the fix
+deform command to perform a simulation undergoing
+shear, then that is also accounted for.  The mean velocity of each bin
+of SRD particles is set to the position-dependent streaming velocity,
+based on the coordinates of the center of the SRD bin.  Note that for
+streaming simulations, if no thermostatting is performed (the
+default), then it may take a long time for the SRD fluid to come to
+equilibrium with a velocity profile that matches the simulation box
+deformation.
 
    
 
    
 
@@ -315,10 +318,10 @@ files.  None of the fix_modify options
 are relevant to this fix.
 
    
 
    This fix tabulates several SRD statistics which are stored in a vector
-of length 12, which can be accessed by various output
-commands.  The vector values calculated by
-this fix are "intensive", meaning they do not scale with the size of
-the simulation.  Technically, the first 8 do scale with the size of
+of length 12, which can be accessed by various output
+commands.  The vector values calculated
+by this fix are "intensive", meaning they do not scale with the size
+of the simulation.  Technically, the first 8 do scale with the size of
 the simulation, but treating them as intensive means they are not
 scaled when printed as part of thermodyanmic output.
 
    
@@ -343,11 +346,11 @@ beginning of the run.
 the run command.  This fix is not invoked during energy
 minimization.
 
    
-
    Restrictions: none
+
    Restrictions:
 
    
-
    This command can only be used if LAMMPS was built with the "srd"
-package.  See the Making LAMMPS section for
-more info on packages.
+
    This command can only be used if LAMMPS was built with the SRD
+package.  See the Making LAMMPS section
+for more info on packages.
 
    
 
    Related commands:
 
    
@@ -357,7 +360,7 @@ more info on packages.
 
    
 
    The option defaults are lamda inferred from Tsrd, collision = noslip,
 overlap = no, inside = error, exact = yes, radius = 1.0, bounce = 0,
-search = hgrid, cubic = error 0.01, shift = no, stream = yes.
+search = hgrid, cubic = error 0.01, shift = no, tstat = no.
 
    
 
    
 
@@ -370,6 +373,8 @@ search = hgrid, cubic = error 0.01, shift = no, stream = yes.
 
    (Petersen) Petersen, Lechman, Plimpton, Grest, in' t Veld, Schunk, J
 Chem Phys, 132, 174106 (2010).
 
    
-
    :link(Lechman) (Lechman) Lechman, et al, in preparation (2010).
+
+
+
    (Lechman) Lechman, et al, in preparation (2010).
 
    
 
diff --git a/doc/fix_srd.txt b/doc/fix_srd.txt
index 1819101dbf..07dd49b861 100644
--- a/doc/fix_srd.txt
+++ b/doc/fix_srd.txt
@@ -33,10 +33,7 @@ keyword = {lamda} or {collision} or {overlap} or {inside} or {exact} or {radius}
   {cubic} values = style tolerance
     style = {error} or {warn}
     tolerance = fractional difference allowed (0 <= tol <= 1)
-  {shift} values = style seed
-    style = {no} or {yes} or {possible}
-    seed = random # seed (positive integer)
-  {stream} value = {yes} or {no} = whether or not streaming velocity is added for shear deformation :pre
+  {tstat} value = {yes} or {no} = thermostat SRD particles or not :pre
 :ule
 
 [Examples:]
@@ -52,13 +49,14 @@ particles that serve as a background solvent when interacting with big
 in "(Hecht)"_#Hecht.  The key idea behind using SRD particles as a
 cheap coarse-grained solvent is that SRD particles do not interact
 with each other, but only with the solute particles, which in LAMMPS
-can be spheroids, ellipsoids, or rigid bodies containing multiples
-spherioids and ellipsoids.  The collision and rotation properties of
-the model imbue the SRD particles with fluid-like properties,
-including an effective viscosity.  Thus simulations with large solute
-particles can be run more quickly, to measure solute propoerties like
-diffusivity and viscosity in a background fluid.  The usual LAMMPS
-fixes for such simulations, such as "fix deform"_fix_deform.html, "fix
+can be spheroids, ellipsoids, or line segments, or triangles, or rigid
+bodies containing multiple spherioids or ellipsoids or line segments
+or triangles.  The collision and rotation properties of the model
+imbue the SRD particles with fluid-like properties, including an
+effective viscosity.  Thus simulations with large solute particles can
+be run more quickly, to measure solute propoerties like diffusivity
+and viscosity in a background fluid.  The usual LAMMPS fixes for such
+simulations, such as "fix deform"_fix_deform.html, "fix
 viscosity"_fix_viscosity.html, and "fix nvt/sllod"_fix_nvt_sllod.html,
 can be used in conjunction with the SRD model.
 
@@ -103,12 +101,13 @@ velocities.  Normally hgrid is set to be 1/4 of the big particle
 diameter or smaller, to adequately resolve fluid properties around the
 big particles.
 
-Lamda cannot be smaller than 0.6 * hgrid, else an error is generated.
-The velocities of SRD particles are bounded by Vmax, which is set so
-that an SRD particle will not advect further than Dmax = 4*lamda in
-dt_SRD.  This means that roughly speaking, Dmax should not be larger
-than a big particle diameter, else SRDs may pass thru big particles
-without colliding.  A warning is generated if this is the case.
+Lamda cannot be smaller than 0.6 * hgrid, else an error is generated
+(unless the {shift} keyword is used, see below).  The velocities of
+SRD particles are bounded by Vmax, which is set so that an SRD
+particle will not advect further than Dmax = 4*lamda in dt_SRD.  This
+means that roughly speaking, Dmax should not be larger than a big
+particle diameter, else SRDs may pass thru big particles without
+colliding.  A warning is generated if this is the case.
 
 Collisions between SRD particles and big particles or walls are
 modeled as a lightweight SRD point particle hitting a heavy big
@@ -265,15 +264,19 @@ must still be specified.
 Note that shifting of SRD coordinates requires extra communication,
 hence it should not normally be enabled unless required.
 
-The {stream} keyword should be used when SRD particles are used with
-the "fix deform"_fix_deform.html command to perform a simulation
-undergoing shear, e.g. to measure a viscosity.  If the {stream} style
-is set to {yes}, then the mean velocity of each bin of SRD particles
-is set to the streaming velocity of the deforming box, each time SRD
-velocities are reset, every N timesteps.  If the {stream} style is set
-to {no}, then the mean velocity is unchanged, which may mean that it
-takes a long time for the SRD fluid to come to equilibrium with a
-velocity profile that matches the simulation box deformation.
+The {tstat} keyword will thermostat the SRD particles to the specified
+{Tsrd}.  This is done every N timesteps, during the velocity rotation
+operation, by rescaling the thermal velocity of particles in each SRD
+bin to the desired temperature.  If there is a streaming velocity
+associated with the system, e.g. due to use of the "fix
+deform"_fix_deform.html command to perform a simulation undergoing
+shear, then that is also accounted for.  The mean velocity of each bin
+of SRD particles is set to the position-dependent streaming velocity,
+based on the coordinates of the center of the SRD bin.  Note that for
+streaming simulations, if no thermostatting is performed (the
+default), then it may take a long time for the SRD fluid to come to
+equilibrium with a velocity profile that matches the simulation box
+deformation.
 
 :line
 
@@ -310,9 +313,9 @@ are relevant to this fix.
 
 This fix tabulates several SRD statistics which are stored in a vector
 of length 12, which can be accessed by various "output
-commands"_Section_howto.html#4_15.  The vector values calculated by
-this fix are "intensive", meaning they do not scale with the size of
-the simulation.  Technically, the first 8 do scale with the size of
+commands"_Section_howto.html#howto_15.  The vector values calculated
+by this fix are "intensive", meaning they do not scale with the size
+of the simulation.  Technically, the first 8 do scale with the size of
 the simulation, but treating them as intensive means they are not
 scaled when printed as part of thermodyanmic output.
 
@@ -337,11 +340,11 @@ No parameter of this fix can be used with the {start/stop} keywords of
 the "run"_run.html command.  This fix is not invoked during "energy
 minimization"_minimize.html.
 
-[Restrictions:] none
+[Restrictions:]
 
-This command can only be used if LAMMPS was built with the "srd"
-package.  See the "Making LAMMPS"_Section_start.html#2_3 section for
-more info on packages.
+This command can only be used if LAMMPS was built with the SRD
+package.  See the "Making LAMMPS"_Section_start.html#start_3 section
+for more info on packages.
 
 [Related commands:]
 
@@ -351,7 +354,7 @@ more info on packages.
 
 The option defaults are lamda inferred from Tsrd, collision = noslip,
 overlap = no, inside = error, exact = yes, radius = 1.0, bounce = 0,
-search = hgrid, cubic = error 0.01, shift = no, stream = yes.
+search = hgrid, cubic = error 0.01, shift = no, tstat = no.
 
 :line
 
@@ -362,4 +365,5 @@ search = hgrid, cubic = error 0.01, shift = no, stream = yes.
 [(Petersen)] Petersen, Lechman, Plimpton, Grest, in' t Veld, Schunk, J
 Chem Phys, 132, 174106 (2010).
 
-:link(Lechman) [(Lechman)] Lechman, et al, in preparation (2010).
+:link(Lechman)
+[(Lechman)] Lechman, et al, in preparation (2010).
diff --git a/doc/fix_store_force.html b/doc/fix_store_force.html
index 8fcd4f8cd1..f73bdf65b9 100644
--- a/doc/fix_store_force.html
+++ b/doc/fix_store_force.html
@@ -28,7 +28,7 @@
 timestep when the fix is invoked, as described below.  This is useful
 for storing forces before constraints or other boundary conditions are
 computed which modify the forces, so that unmodified forces can be
-written to a dump file or accessed by other output
+written to a dump file or accessed by other output
 commands that use per-atom quantities.
 
    
 
    This fix is invoked at the point in the velocity-Verlet timestepping
@@ -58,9 +58,9 @@ files.  None of the fix_modify options
 are relevant to this fix.
 
    
 
    This fix produces a per-atom array which can be accessed by various
-output commands.  The number of columns for
-each atom is 3, and the columns store the x,y,z forces on each atom.
-The per-atom values be accessed on any timestep.
+output commands.  The number of columns
+for each atom is 3, and the columns store the x,y,z forces on each
+atom.  The per-atom values be accessed on any timestep.
 
    
 
    No parameter of this fix can be used with the start/stop keywords of
 the run command.  This fix is not invoked during energy
diff --git a/doc/fix_store_force.txt b/doc/fix_store_force.txt
index 12a810db61..e77a60cf2c 100644
--- a/doc/fix_store_force.txt
+++ b/doc/fix_store_force.txt
@@ -26,7 +26,7 @@ timestep when the fix is invoked, as described below.  This is useful
 for storing forces before constraints or other boundary conditions are
 computed which modify the forces, so that unmodified forces can be
 "written to a dump file"_dump.html or accessed by other "output
-commands"_Section_howto.html#4_15 that use per-atom quantities.
+commands"_Section_howto.html#howto_15 that use per-atom quantities.
 
 This fix is invoked at the point in the velocity-Verlet timestepping
 immediately after "pair"_pair_style.html, "bond"_bond_style.html,
@@ -55,9 +55,9 @@ files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.
 
 This fix produces a per-atom array which can be accessed by various
-"output commands"_Section_howto.html#4_15.  The number of columns for
-each atom is 3, and the columns store the x,y,z forces on each atom.
-The per-atom values be accessed on any timestep.
+"output commands"_Section_howto.html#howto_15.  The number of columns
+for each atom is 3, and the columns store the x,y,z forces on each
+atom.  The per-atom values be accessed on any timestep.
 
 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
diff --git a/doc/fix_store_state.html b/doc/fix_store_state.html
index 0d1ad87faf..067ad38aea 100644
--- a/doc/fix_store_state.html
+++ b/doc/fix_store_state.html
@@ -28,8 +28,7 @@
 		        vx, vy, vz, fx, fy, fz,
                         q, mux, muy, muz,
                         radius, omegax, omegay, omegaz,
-                        angmomx, angmomy, angmomz,
-		        quatw, quati, quatj, quatk, tqx, tqy, tqz
+                        angmomx, angmomy, angmomz, tqx, tqy, tqz
 			c_ID, c_ID[N], f_ID, f_ID[N], v_name 
 
    • 
 
          id = atom ID
@@ -47,7 +46,6 @@
       radius = radius of extended spherical particle
       omegax,omegay,omegaz = angular velocity of extended particle
       angmomx,angmomy,angmomz = angular momentum of extended particle
-      quatw,quati,quatj,quatk = quaternion components for aspherical particles
       tqx,tqy,tqz = torque on extended particles
       c_ID = per-atom vector calculated by a compute with ID
       c_ID[I] = Ith column of per-atom array calculated by a compute with ID
@@ -75,11 +73,11 @@ fix 2 all store/state 1000 vx vy vz
 time the fix is defined.  If N is 0, then the values are never
 updated, so this is a way of archiving an atom attribute at a given
 time for future use in a calculation or output.  See the discussion of
-output commands that take fixes as inputs.
-And see for example, the compute reduce, fix
-ave/atom, fix ave/histo, fix
-ave/spatial, and atom-style
-variable commands.
+output commands that take fixes as
+inputs.  And see for example, the compute
+reduce, fix ave/atom, fix
+ave/histo, fix ave/spatial,
+and atom-style variable commands.
 
    
 
    If N is not zero, then the attributes will be updated every N
 steps.
@@ -119,8 +117,9 @@ fix.
 
    If a single input is specified, this fix produces a per-atom vector.
 If multiple inputs are specified, a per-atom array is produced where
 the number of columns for each atom is the number of inputs.  These
-can be accessed by various output commands.
-The per-atom values be accessed on any timestep.
+can be accessed by various output
+commands.  The per-atom values be
+accessed on any timestep.
 
    
 
    No parameter of this fix can be used with the start/stop keywords of
 the run command.  This fix is not invoked during energy
diff --git a/doc/fix_store_state.txt b/doc/fix_store_state.txt
index ea98d36fd9..05b6d8878b 100644
--- a/doc/fix_store_state.txt
+++ b/doc/fix_store_state.txt
@@ -21,8 +21,7 @@ input = one or more atom attributes :l
 		        vx, vy, vz, fx, fy, fz,
                         q, mux, muy, muz,
                         radius, omegax, omegay, omegaz,
-                        angmomx, angmomy, angmomz,
-		        quatw, quati, quatj, quatk, tqx, tqy, tqz
+                        angmomx, angmomy, angmomz, tqx, tqy, tqz
 			c_ID, c_ID\[N\], f_ID, f_ID\[N\], v_name :pre
 
       id = atom ID
@@ -40,7 +39,6 @@ input = one or more atom attributes :l
       radius = radius of extended spherical particle
       omegax,omegay,omegaz = angular velocity of extended particle
       angmomx,angmomy,angmomz = angular momentum of extended particle
-      quatw,quati,quatj,quatk = quaternion components for aspherical particles
       tqx,tqy,tqz = torque on extended particles
       c_ID = per-atom vector calculated by a compute with ID
       c_ID\[I\] = Ith column of per-atom array calculated by a compute with ID
@@ -65,11 +63,11 @@ Define a fix that stores attributes for each atom in the group at the
 time the fix is defined.  If {N} is 0, then the values are never
 updated, so this is a way of archiving an atom attribute at a given
 time for future use in a calculation or output.  See the discussion of
-"output commands"_Section_howto.html#4_15 that take fixes as inputs.
-And see for example, the "compute reduce"_compute_reduce.html, "fix
-ave/atom"_fix_ave_atom.html, "fix ave/histo"_fix_ave_histo.html, "fix
-ave/spatial"_fix_ave_spatial.html, and "atom-style
-variable"_variable.html commands.
+"output commands"_Section_howto.html#howto_15 that take fixes as
+inputs.  And see for example, the "compute
+reduce"_compute_reduce.html, "fix ave/atom"_fix_ave_atom.html, "fix
+ave/histo"_fix_ave_histo.html, "fix ave/spatial"_fix_ave_spatial.html,
+and "atom-style variable"_variable.html commands.
 
 If {N} is not zero, then the attributes will be updated every {N}
 steps.
@@ -109,8 +107,9 @@ fix.
 If a single input is specified, this fix produces a per-atom vector.
 If multiple inputs are specified, a per-atom array is produced where
 the number of columns for each atom is the number of inputs.  These
-can be accessed by various "output commands"_Section_howto.html#4_15.
-The per-atom values be accessed on any timestep.
+can be accessed by various "output
+commands"_Section_howto.html#howto_15.  The per-atom values be
+accessed on any timestep.
 
 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
diff --git a/doc/fix_temp_berendsen.html b/doc/fix_temp_berendsen.html
index 5c3d174d97..0762f66eea 100644
--- a/doc/fix_temp_berendsen.html
+++ b/doc/fix_temp_berendsen.html
@@ -11,6 +11,8 @@
 
 
    fix temp/berendsen command 
 
    
+
    fix temp/berendsen/cuda command 
+
    
 
    Syntax:
 
    
 
    fix ID group-ID temp/berendsen Tstart Tstop Tdamp 
@@ -54,8 +56,8 @@ normally be used on atoms that also have their temperature controlled
 by another fix - e.g. by fix nvt or fix
 langevin commands.
 
    
-
    See this howto section of the manual for a
-discussion of different ways to compute temperature and perform
+
    See this howto section of the manual for
+a discussion of different ways to compute temperature and perform
 thermostatting.
 
    
 
    This fix computes a temperature each timestep.  To do this, the fix
@@ -93,6 +95,29 @@ temperature is calculated taking the bias into account, bias is
 removed from each atom, thermostatting is performed on the remaining
 thermal degrees of freedom, and the bias is added back in.
 
    
+
    
+
+
    Styles with a cuda 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
+this section of the manual.  The accelerated
+styles take the same arguments and should produce the same results,
+except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA package.  They are
+only enabled if LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
 
    Restart, fix_modify, output, run start/stop, minimize info:
 
    
 
    No information about this fix is written to binary restart
@@ -110,7 +135,7 @@ system's potential energy as part of thermodynamic
 output.
 
    
 
    This fix computes a global scalar which can be accessed by various
-output commands.  The scalar is the
+output commands.  The scalar is the
 cummulative energy change due to this fix.  The scalar value
 calculated by this fix is "extensive".
 
    
diff --git a/doc/fix_temp_berendsen.txt b/doc/fix_temp_berendsen.txt
index f1a12f7041..8dd9620418 100644
--- a/doc/fix_temp_berendsen.txt
+++ b/doc/fix_temp_berendsen.txt
@@ -7,6 +7,7 @@
 :line
 
 fix temp/berendsen command :h3
+fix temp/berendsen/cuda command :h3
 
 [Syntax:]
 
@@ -51,8 +52,8 @@ normally be used on atoms that also have their temperature controlled
 by another fix - e.g. by "fix nvt"_fix_nh.html or "fix
 langevin"_fix_langevin.html commands.
 
-See "this howto section"_Section_howto.html#4_16 of the manual for a
-discussion of different ways to compute temperature and perform
+See "this howto section"_Section_howto.html#howto_16 of the manual for
+a discussion of different ways to compute temperature and perform
 thermostatting.
 
 This fix computes a temperature each timestep.  To do this, the fix
@@ -90,6 +91,29 @@ temperature is calculated taking the bias into account, bias is
 removed from each atom, thermostatting is performed on the remaining
 thermal degrees of freedom, and the bias is added back in.
 
+:line
+
+Styles with a {cuda} 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
+"this section"_Section_accelerate.html of the manual.  The accelerated
+styles take the same arguments and should produce the same results,
+except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA package.  They are
+only enabled if LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restart, fix_modify, output, run start/stop, minimize info:]
 
 No information about this fix is written to "binary restart
@@ -107,7 +131,7 @@ 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#4_15.  The scalar is the
+"output commands"_Section_howto.html#howto_15.  The scalar is the
 cummulative energy change due to this fix.  The scalar value
 calculated by this fix is "extensive".
 
diff --git a/doc/fix_temp_rescale.html b/doc/fix_temp_rescale.html
index 05896d6c36..81273ed4e3 100644
--- a/doc/fix_temp_rescale.html
+++ b/doc/fix_temp_rescale.html
@@ -11,6 +11,10 @@
 
 
    fix temp/rescale command 
 
    
+
    fix temp/rescale/cuda command 
+
    
+
    fix temp/rescale/limit/cuda command 
+
    
 
    Syntax:
 
    
 
    fix ID group-ID temp/rescale N Tstart Tstop window fraction 
@@ -61,8 +65,8 @@ normally be used on atoms that also have their temperature controlled
 by another fix - e.g. by fix nvt or fix
 langevin commands.
 
    
-
    See this howto section of the manual for a
-discussion of different ways to compute temperature and perform
+
    See this howto section of the manual for
+a discussion of different ways to compute temperature and perform
 thermostatting.
 
    
 
    This fix computes a temperature each timestep.  To do this, the fix
@@ -100,6 +104,29 @@ temperature is calculated taking the bias into account, bias is
 removed from each atom, thermostatting is performed on the remaining
 thermal degrees of freedom, and the bias is added back in.
 
    
+
    
+
+
    Styles with a cuda 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
+this section of the manual.  The accelerated
+styles take the same arguments and should produce the same results,
+except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA package.  They are
+only enabled if LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
 
    Restart, fix_modify, output, run start/stop, minimize info:
 
    
 
    No information about this fix is written to binary restart
@@ -117,7 +144,7 @@ system's potential energy as part of thermodynamic
 output.
 
    
 
    This fix computes a global scalar which can be accessed by various
-output commands.  The scalar is the
+output commands.  The scalar is the
 cummulative energy change due to this fix.  The scalar value
 calculated by this fix is "extensive".
 
    
diff --git a/doc/fix_temp_rescale.txt b/doc/fix_temp_rescale.txt
index f972ce7413..5fbe99e5b3 100644
--- a/doc/fix_temp_rescale.txt
+++ b/doc/fix_temp_rescale.txt
@@ -7,6 +7,8 @@
 :line
 
 fix temp/rescale command :h3
+fix temp/rescale/cuda command :h3
+fix temp/rescale/limit/cuda command :h3
 
 [Syntax:]
 
@@ -58,8 +60,8 @@ normally be used on atoms that also have their temperature controlled
 by another fix - e.g. by "fix nvt"_fix_nh.html or "fix
 langevin"_fix_langevin.html commands.
 
-See "this howto section"_Section_howto.html#4_16 of the manual for a
-discussion of different ways to compute temperature and perform
+See "this howto section"_Section_howto.html#howto_16 of the manual for
+a discussion of different ways to compute temperature and perform
 thermostatting.
 
 This fix computes a temperature each timestep.  To do this, the fix
@@ -97,6 +99,29 @@ temperature is calculated taking the bias into account, bias is
 removed from each atom, thermostatting is performed on the remaining
 thermal degrees of freedom, and the bias is added back in.
 
+:line
+
+Styles with a {cuda} 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
+"this section"_Section_accelerate.html of the manual.  The accelerated
+styles take the same arguments and should produce the same results,
+except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA package.  They are
+only enabled if LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restart, fix_modify, output, run start/stop, minimize info:]
 
 No information about this fix is written to "binary restart
@@ -114,7 +139,7 @@ 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#4_15.  The scalar is the
+"output commands"_Section_howto.html#howto_15.  The scalar is the
 cummulative energy change due to this fix.  The scalar value
 calculated by this fix is "extensive".
 
diff --git a/doc/fix_temp_rescale_eff.html b/doc/fix_temp_rescale_eff.html
index 2eefe238f1..038e181938 100644
--- a/doc/fix_temp_rescale_eff.html
+++ b/doc/fix_temp_rescale_eff.html
@@ -54,7 +54,7 @@ system's potential energy as part of thermodynamic
 output.
 
    
 
    This fix computes a global scalar which can be accessed by various
-output commands.  The scalar is the
+output commands.  The scalar is the
 cummulative energy change due to this fix.  The scalar value
 calculated by this fix is "extensive".
 
    
@@ -66,8 +66,8 @@ calculated by this fix is "extensive".
 
    
 
    Restrictions:
 
    
-
    This fix is part of the "user-eff" package.  It is only enabled if
-LAMMPS was built with that package.  See the Making
+
    This fix is part of the USER-EFF package.  It is only enabled if
+LAMMPS was built with that package.  See the Making
 LAMMPS section for more info.
 
    
 
    Related commands:
diff --git a/doc/fix_temp_rescale_eff.txt b/doc/fix_temp_rescale_eff.txt
index eef42ce239..f96b40962a 100644
--- a/doc/fix_temp_rescale_eff.txt
+++ b/doc/fix_temp_rescale_eff.txt
@@ -51,7 +51,7 @@ 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#4_15.  The scalar is the
+"output commands"_Section_howto.html#howto_15.  The scalar is the
 cummulative energy change due to this fix.  The scalar value
 calculated by this fix is "extensive".
 
@@ -63,9 +63,9 @@ This fix is not invoked during "energy minimization"_minimize.html.
 
 [Restrictions:]
 
-This fix is part of the "user-eff" package.  It is only enabled if
+This fix is part of the USER-EFF package.  It is only enabled if
 LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+LAMMPS"_Section_start.html#start_3 section for more info.
 
 [Related commands:]
 
diff --git a/doc/fix_thermal_conductivity.html b/doc/fix_thermal_conductivity.html
index 72e5508a6b..d89d6b9fa4 100644
--- a/doc/fix_thermal_conductivity.html
+++ b/doc/fix_thermal_conductivity.html
@@ -108,7 +108,7 @@ files.  None of the fix_modify options
 are relevant to this fix.
 
    
 
    This fix computes a global scalar which can be accessed by various
-output commands.  The scalar is the
+output commands.  The scalar is the
 cummulative kinetic energy transferred between the bottom and middle
 of the simulation box (in the edim direction) is stored as a scalar
 quantity by this fix.  This quantity is zeroed when the fix is defined
diff --git a/doc/fix_thermal_conductivity.txt b/doc/fix_thermal_conductivity.txt
index da0d0c8073..19fa15be33 100644
--- a/doc/fix_thermal_conductivity.txt
+++ b/doc/fix_thermal_conductivity.txt
@@ -98,7 +98,7 @@ files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.
 
 This fix computes a global scalar which can be accessed by various
-"output commands"_Section_howto.html#4_15.  The scalar is the
+"output commands"_Section_howto.html#howto_15.  The scalar is the
 cummulative kinetic energy transferred between the bottom and middle
 of the simulation box (in the {edim} direction) is stored as a scalar
 quantity by this fix.  This quantity is zeroed when the fix is defined
diff --git a/doc/fix_tmd.html b/doc/fix_tmd.html
index bf9c8f5d6b..c365365f4b 100644
--- a/doc/fix_tmd.html
+++ b/doc/fix_tmd.html
@@ -93,7 +93,7 @@ to prevent it being overwritten.
 
    No information about this fix is written to binary restart
 files.  None of the fix_modify options
 are relevant to this fix.  No global or per-atom quantities are stored
-by this fix for access by various output
+by this fix for access by various output
 commands.
 
    
 
    This fix can ramp its rho parameter over multiple runs, using the
@@ -114,8 +114,8 @@ are not multiple competing holonomic constraints applied to the same
 atoms.
 
    
 
    To read gzipped target files, you must compile LAMMPS with the
--DLAMMPS_GZIP option - see the Making LAMMPS
-section of the documentation.
+-DLAMMPS_GZIP option - see the Making
+LAMMPS section of the documentation.
 
    
 
    Related commands: none
 
    
diff --git a/doc/fix_tmd.txt b/doc/fix_tmd.txt
index 7ff51ce50c..71d8d2c767 100644
--- a/doc/fix_tmd.txt
+++ b/doc/fix_tmd.txt
@@ -91,7 +91,7 @@ No information about this fix is written to "binary restart
 files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.  No global or per-atom quantities are stored
 by this fix for access by various "output
-commands"_Section_howto.html#4_15.
+commands"_Section_howto.html#howto_15.
 
 This fix can ramp its rho parameter over multiple runs, using the
 {start} and {stop} keywords of the "run"_run.html command.  See the
@@ -111,8 +111,8 @@ are not multiple competing holonomic constraints applied to the same
 atoms.
 
 To read gzipped target files, you must compile LAMMPS with the
--DLAMMPS_GZIP option - see the "Making LAMMPS"_Section_start.html#2_2
-section of the documentation.
+-DLAMMPS_GZIP option - see the "Making
+LAMMPS"_Section_start.html#start_2 section of the documentation.
 
 [Related commands:] none
 
diff --git a/doc/fix_ttm.html b/doc/fix_ttm.html
index 2c5eb9e006..906e67db1d 100644
--- a/doc/fix_ttm.html
+++ b/doc/fix_ttm.html
@@ -145,19 +145,19 @@ atoms.  This fix should not normally be used on atoms that have their
 temperature controlled by another fix - e.g. fix nvt or
 fix langevin.
 
    
-
    This fix computes 2 output quantities stored in a vector of
-length 2, which can be accessed by various output
-commands.  The first quantity is
-the total energy of the electronic subsystem. The second quantity
-is the energy transferred from the electronic to the atomic subsystem
-on that timestep. Note that the velocity verlet integrator applies the
-fix ttm forces to the atomic subsystem as two half-step velocity 
-updates: one on the current timestep and one on the subsequent timestep.
+
    This fix computes 2 output quantities stored in a vector of length 2,
+which can be accessed by various output
+commands.  The first quantity is the
+total energy of the electronic subsystem. The second quantity is the
+energy transferred from the electronic to the atomic subsystem on that
+timestep. Note that the velocity verlet integrator applies the fix ttm
+forces to the atomic subsystem as two half-step velocity updates: one
+on the current timestep and one on the subsequent timestep.
 Consequently, the change in the atomic subsystem energy is lagged by
-half a timestep relative to the change in the electronic subsystem 
+half a timestep relative to the change in the electronic subsystem
 energy. As a result of this, users may notice slight fluctuations in
-the sum of the atomic and electronic subsystem energies reported at 
-the end of the timestep. 
+the sum of the atomic and electronic subsystem energies reported at
+the end of the timestep.
 
    
 
    The vector values calculated by this fix are "extensive".
 
    
@@ -184,7 +184,7 @@ should produce the same behavior.
 
    
 
    None of the fix_modify options are relevant to this
 fix.  No global or per-atom quantities are stored by this fix for
-access by various output commands.  No
+access by various output commands.  No
 parameter of this fix can be used with the start/stop keywords of
 the run command.  This fix is not invoked during energy
 minimization.
diff --git a/doc/fix_ttm.txt b/doc/fix_ttm.txt
index ddd76c7792..a8fa96f910 100644
--- a/doc/fix_ttm.txt
+++ b/doc/fix_ttm.txt
@@ -142,19 +142,19 @@ atoms.  This fix should not normally be used on atoms that have their
 temperature controlled by another fix - e.g. "fix nvt"_fix_nh.html or
 "fix langevin"_fix_langevin.html.
 
-This fix computes 2 output quantities stored in a vector of
-length 2, which can be accessed by various "output
-commands"_Section_howto.html#4_15.  The first quantity is
-the total energy of the electronic subsystem. The second quantity
-is the energy transferred from the electronic to the atomic subsystem
-on that timestep. Note that the velocity verlet integrator applies the
-fix ttm forces to the atomic subsystem as two half-step velocity 
-updates: one on the current timestep and one on the subsequent timestep.
+This fix computes 2 output quantities stored in a vector of length 2,
+which can be accessed by various "output
+commands"_Section_howto.html#howto_15.  The first quantity is the
+total energy of the electronic subsystem. The second quantity is the
+energy transferred from the electronic to the atomic subsystem on that
+timestep. Note that the velocity verlet integrator applies the fix ttm
+forces to the atomic subsystem as two half-step velocity updates: one
+on the current timestep and one on the subsequent timestep.
 Consequently, the change in the atomic subsystem energy is lagged by
-half a timestep relative to the change in the electronic subsystem 
+half a timestep relative to the change in the electronic subsystem
 energy. As a result of this, users may notice slight fluctuations in
-the sum of the atomic and electronic subsystem energies reported at 
-the end of the timestep. 
+the sum of the atomic and electronic subsystem energies reported at
+the end of the timestep.
 
 The vector values calculated by this fix are "extensive".
 
@@ -181,7 +181,7 @@ should produce the same behavior.
 
 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#4_15.  No
+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.
diff --git a/doc/fix_viscosity.html b/doc/fix_viscosity.html
index a864ba390f..51eee268f6 100644
--- a/doc/fix_viscosity.html
+++ b/doc/fix_viscosity.html
@@ -103,12 +103,12 @@ you cannot accurately infer a viscosity and should try increasing
 the Nevery parameter.
 
    
 
    An alternative method for calculating a viscosity is to run a NEMD
-simulation, as described in this section of
-the manual.  NEMD simulations deform the simmulation box via the fix
-deform command.  Thus they cannot be run on a charged
-system using a PPPM solver since PPPM does not
-currently support non-orthogonal boxes.  Using fix viscosity keeps the
-box orthogonal; thus it does not suffer from this limitation.
+simulation, as described in this section
+of the manual.  NEMD simulations deform the simmulation box via the
+fix deform command.  Thus they cannot be run on a
+charged system using a PPPM solver since PPPM does
+not currently support non-orthogonal boxes.  Using fix viscosity keeps
+the box orthogonal; thus it does not suffer from this limitation.
 
    
 
    Restart, fix_modify, output, run start/stop, minimize info:
 
    
@@ -117,7 +117,7 @@ files.  None of the fix_modify options
 are relevant to this fix.
 
    
 
    This fix computes a global scalar which can be accessed by various
-output commands.  The scalar is the
+output commands.  The scalar is the
 cummulative momentum transferred between the bottom and middle of the
 simulation box (in the pdim direction) is stored as a scalar
 quantity by this fix.  This quantity is zeroed when the fix is defined
diff --git a/doc/fix_viscosity.txt b/doc/fix_viscosity.txt
index f1cc3ccbf1..3e39526876 100644
--- a/doc/fix_viscosity.txt
+++ b/doc/fix_viscosity.txt
@@ -92,12 +92,12 @@ you cannot accurately infer a viscosity and should try increasing
 the Nevery parameter.
 
 An alternative method for calculating a viscosity is to run a NEMD
-simulation, as described in "this section"_Section_howto.html#4_13 of
-the manual.  NEMD simulations deform the simmulation box via the "fix
-deform"_fix_deform.html command.  Thus they cannot be run on a charged
-system using a "PPPM solver"_kspace_style.html since PPPM does not
-currently support non-orthogonal boxes.  Using fix viscosity keeps the
-box orthogonal; thus it does not suffer from this limitation.
+simulation, as described in "this section"_Section_howto.html#howto_13
+of the manual.  NEMD simulations deform the simmulation box via the
+"fix deform"_fix_deform.html command.  Thus they cannot be run on a
+charged system using a "PPPM solver"_kspace_style.html since PPPM does
+not currently support non-orthogonal boxes.  Using fix viscosity keeps
+the box orthogonal; thus it does not suffer from this limitation.
 
 [Restart, fix_modify, output, run start/stop, minimize info:]
 
@@ -106,7 +106,7 @@ files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.
 
 This fix computes a global scalar which can be accessed by various
-"output commands"_Section_howto.html#4_15.  The scalar is the
+"output commands"_Section_howto.html#howto_15.  The scalar is the
 cummulative momentum transferred between the bottom and middle of the
 simulation box (in the {pdim} direction) is stored as a scalar
 quantity by this fix.  This quantity is zeroed when the fix is defined
diff --git a/doc/fix_viscous.html b/doc/fix_viscous.html
index 89fb55177d..fe03b98672 100644
--- a/doc/fix_viscous.html
+++ b/doc/fix_viscous.html
@@ -11,6 +11,8 @@
 
 
    fix viscous command 
 
    
+
    fix viscous/cuda command 
+
    
 
    Syntax:
 
    
 
    fix ID group-ID viscous gamma keyword values ... 
@@ -80,14 +82,37 @@ the damping parameter of fix langevin, except
 the units of gamma are force/velocity and the units of damp are time,
 so that it can more easily be used as a thermostat.
 
    
+
    
+
+
    Styles with a cuda 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
+this section of the manual.  The accelerated
+styles take the same arguments and should produce the same results,
+except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA package.  They are
+only enabled if LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
 
    Restart, fix_modify, output, run start/stop, minimize info:
 
    
 
    No information about this fix is written to binary restart
 files.  None of the fix_modify options
 are relevant to this fix.  No global or per-atom quantities are stored
-by this fix for access by various output
-commands.  No parameter of this fix can be
-used with the start/stop keywords of the run command.
+by this fix for access by various output
+commands.  No parameter of this fix can
+be used with the start/stop keywords of the run command.
 
    
 
    The forces due to this fix are imposed during an energy minimization,
 invoked by the minimize command.  This fix should only
diff --git a/doc/fix_viscous.txt b/doc/fix_viscous.txt
index 1793eea8e7..bfd26b726b 100644
--- a/doc/fix_viscous.txt
+++ b/doc/fix_viscous.txt
@@ -7,6 +7,7 @@
 :line
 
 fix viscous command :h3
+fix viscous/cuda command :h3
 
 [Syntax:]
 
@@ -72,14 +73,37 @@ the damping parameter of "fix langevin"_fix_langevin.html, except that
 the units of gamma are force/velocity and the units of damp are time,
 so that it can more easily be used as a thermostat.
 
+:line
+
+Styles with a {cuda} 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
+"this section"_Section_accelerate.html of the manual.  The accelerated
+styles take the same arguments and should produce the same results,
+except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA package.  They are
+only enabled if LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restart, fix_modify, output, run start/stop, minimize info:]
 
 No information about this fix is written to "binary restart
 files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.  No global or per-atom quantities are stored
 by this fix for access by various "output
-commands"_Section_howto.html#4_15.  No parameter of this fix can be
-used with the {start/stop} keywords of the "run"_run.html command.
+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.
 
 The forces due to this fix are imposed during an energy minimization,
 invoked by the "minimize"_minimize.html command.  This fix should only
diff --git a/doc/fix_wall.html b/doc/fix_wall.html
index f776418915..75906f4163 100644
--- a/doc/fix_wall.html
+++ b/doc/fix_wall.html
@@ -40,11 +40,14 @@
 
    
 
  • zero or more keyword/value pairs may be appended 
 
-
  • keyword = units 
+
  • keyword = units or fld 
 
 
      units value = lattice or box
     lattice = the wall position is defined in lattice units
-    box = the wall position is defined in simulation box units 
+    box = the wall position is defined in simulation box units
+  fld value = yes or no
+    yes = invoke the wall constraint to be compatible with implicit FLD
+    yes = invoke the wall constraint in the normal way 
 
    
 
 
@@ -152,9 +155,10 @@ enough epsilon that particles always reamin on the correct side of
 the wall (r > 0).
 
    
 
    The units keyword determines the meaning of the distance units used
-to define a wall position, but only when a numeric constant is used.
-It is not relevant when EDGE or a variable is used to specify a face
-position.
+to define a wall position, but only when a numeric constant or
+variable is used.  It is not relevant when EDGE is used to specify a
+face position.  In the variable case, the variable is assumed to
+produce a value compatible with the units setting you specify.
 
    
 
    A box value selects standard distance units as defined by the
 units command, e.g. Angstroms for units = real or metal.
@@ -162,6 +166,13 @@ A lattice value means the distance units are in lattice spacings.
 The lattice command must have been previously used to
 define the lattice spacings.
 
    
+
    The fld keyword can be used with a yes setting to invoke the wall
+constraint before pairwise interactions are computed.  This allows an
+implicit FLD model using pair_style lubricateU
+to include the wall force in its calculations.  If the setting is
+no, wall forces are imposed after pairwise interactions, in the
+usual manner.
+
    
 
    
 
 
    Here are examples of variable definitions that move the wall position
@@ -211,15 +222,15 @@ the system's potential energy as part of thermodyn
 output.
 
    
 
    This fix computes a global scalar energy and a global vector of
-forces, which can be accessed by various output
-commands.  Note that the scalar energy is the
-sum of interactions with all defined walls.  If you want the energy on
-a per-wall basis, you need to use multiple fix wall commands.  The
-length of the vector is equal to the number of walls defined by the
-fix.  Each vector value is the normal force on a specific wall.  Note
-that an outward force on a wall will be a negative value for lo
-walls and a positive value for hi walls.  The scalar and vector
-values calculated by this fix are "extensive".
+forces, which can be accessed by various output
+commands.  Note that the scalar energy is
+the sum of interactions with all defined walls.  If you want the
+energy on a per-wall basis, you need to use multiple fix wall
+commands.  The length of the vector is equal to the number of walls
+defined by the fix.  Each vector value is the normal force on a
+specific wall.  Note that an outward force on a wall will be a
+negative value for lo walls and a positive value for hi walls.
+The scalar and vector values calculated by this fix are "extensive".
 
    
 
    No parameter of this fix can be used with the start/stop keywords of
 the run command.
diff --git a/doc/fix_wall.txt b/doc/fix_wall.txt
index c9a25f106a..2f8e42514f 100644
--- a/doc/fix_wall.txt
+++ b/doc/fix_wall.txt
@@ -28,10 +28,13 @@ face = {xlo} or {xhi} or {ylo} or {yhi} or {zlo} or {zhi} :l
     sigma = size factor for wall-particle interaction (distance units)
     cutoff = distance from wall at which wall-particle interaction is cut off (distance units) :pre
 zero or more keyword/value pairs may be appended :l
-keyword = {units} :l
+keyword = {units} or {fld} :l
   {units} value = {lattice} or {box}
     {lattice} = the wall position is defined in lattice units
-    {box} = the wall position is defined in simulation box units :pre
+    {box} = the wall position is defined in simulation box units
+  {fld} value = {yes} or {no}
+    {yes} = invoke the wall constraint to be compatible with implicit FLD
+    {yes} = invoke the wall constraint in the normal way :pre
 :ule
 
 [Examples:]
@@ -138,9 +141,10 @@ enough {epsilon} that particles always reamin on the correct side of
 the wall (r > 0).
 
 The {units} keyword determines the meaning of the distance units used
-to define a wall position, but only when a numeric constant is used.
-It is not relevant when EDGE or a variable is used to specify a face
-position.
+to define a wall position, but only when a numeric constant or
+variable is used.  It is not relevant when EDGE is used to specify a
+face position.  In the variable case, the variable is assumed to
+produce a value compatible with the {units} setting you specify.
 
 A {box} value selects standard distance units as defined by the
 "units"_units.html command, e.g. Angstroms for units = real or metal.
@@ -148,6 +152,13 @@ A {lattice} value means the distance units are in lattice spacings.
 The "lattice"_lattice.html command must have been previously used to
 define the lattice spacings.
 
+The {fld} keyword can be used with a {yes} setting to invoke the wall
+constraint before pairwise interactions are computed.  This allows an
+implicit FLD model using "pair_style lubricateU"_pair_lubricateU.html
+to include the wall force in its calculations.  If the setting is
+{no}, wall forces are imposed after pairwise interactions, in the
+usual manner.
+
 :line
 
 Here are examples of variable definitions that move the wall position
@@ -198,14 +209,14 @@ output"_thermo_style.html.
 
 This fix computes a global scalar energy and a global vector of
 forces, which can be accessed by various "output
-commands"_Section_howto.html#4_15.  Note that the scalar energy is the
-sum of interactions with all defined walls.  If you want the energy on
-a per-wall basis, you need to use multiple fix wall commands.  The
-length of the vector is equal to the number of walls defined by the
-fix.  Each vector value is the normal force on a specific wall.  Note
-that an outward force on a wall will be a negative value for {lo}
-walls and a positive value for {hi} walls.  The scalar and vector
-values calculated by this fix are "extensive".
+commands"_Section_howto.html#howto_15.  Note that the scalar energy is
+the sum of interactions with all defined walls.  If you want the
+energy on a per-wall basis, you need to use multiple fix wall
+commands.  The length of the vector is equal to the number of walls
+defined by the fix.  Each vector value is the normal force on a
+specific wall.  Note that an outward force on a wall will be a
+negative value for {lo} walls and a positive value for {hi} walls.
+The scalar and vector values calculated by this fix are "extensive".
 
 No parameter of this fix can be used with the {start/stop} keywords of
 the "run"_run.html command.
diff --git a/doc/fix_wall_gran.html b/doc/fix_wall_gran.html
index 12e1f24066..cc8473392c 100644
--- a/doc/fix_wall_gran.html
+++ b/doc/fix_wall_gran.html
@@ -154,15 +154,15 @@ uninterrupted fashion.
 
    
 
    None of the fix_modify options are relevant to this
 fix.  No global or per-atom quantities are stored by this fix for
-access by various output commands.  No
+access by various output commands.  No
 parameter of this fix can be used with the start/stop keywords of
 the run command.  This fix is not invoked during energy
 minimization.
 
    
 
    Restrictions:
 
    
-
    This fix is part of the "granular" package.  It is only enabled if
-LAMMPS was built with that package.  See the Making
+
    This fix is part of the GRANULAR package.  It is only enabled if
+LAMMPS was built with that package.  See the Making
 LAMMPS section for more info.
 
    
 
    Any dimension (xyz) that has a granular wall must be non-periodic.
diff --git a/doc/fix_wall_gran.txt b/doc/fix_wall_gran.txt
index 990b96a43a..f758a83647 100644
--- a/doc/fix_wall_gran.txt
+++ b/doc/fix_wall_gran.txt
@@ -137,16 +137,16 @@ uninterrupted fashion.
 
 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#4_15.  No
+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
+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#2_3 section for more info.
+LAMMPS"_Section_start.html#start_3 section for more info.
 
 Any dimension (xyz) that has a granular wall must be non-periodic.
 
diff --git a/doc/fix_wall_piston.html b/doc/fix_wall_piston.html
new file mode 100644
index 0000000000..17b3262da2
--- /dev/null
+++ b/doc/fix_wall_piston.html
@@ -0,0 +1,133 @@
+
+
    LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
    
+
+
+
+
+
+
+
    
+
+
    fix wall/piston command 
+
    
+
    Syntax:
+
    
+
    fix ID group-ID wall/piston face arg ... keyword value ... 
+
    
+
    • ID, group-ID are documented in fix command 
+
+
    • wall/piston = style name of this fix command 
+
+
    • one face/arg pair must be appended 
+
+
    • face = zlo 
+
+
    • zero or more keyword/value pairs may be appended 
+
+
    • keyword = pos or vel or ramp or units  
+
+
        pos args = z
+    z = z coordinate at which the piston begins (distance units)
+  vel args = vz
+    vz = final velocity of the piston (velocity units)
+  ramp = use a linear velocity ramp from 0 to vz
+  temp args = target damp seed extent
+    target = target velocity for region immediately ahead of the piston
+    damp = damping paramter (time units)
+    seed = random number seed for langevin kicks
+    extent = extent of thermostated region (distance units)
+  units value = lattice or box
+    lattice = the wall position is defined in lattice units
+    box = the wall position is defined in simulation box units 
+
      
+
+
    
+
    Examples:
+
    
+
    fix xwalls all wall/piston zlo
+fix walls all wall/piston zlo pos 1.0 0.0 0.0 vel 0.0 0.0 10.0 units box
+fix top all wall/piston zlo vel 0.0 0.0 10.0 ramp 
+
    
+
    Description:
+
    
+
    Bound the simulation with a moving wall which reflect particles
+in the specified group and drive the system with an effective infinite-mass
+piston capable of driving shock waves. 
+
    
+
    A momentum mirror technique is used, which means that if an atom (or the wall)
+moves such that an atom is outside the wall on a timestep
+by a distance delta (e.g. due to fix nve), then it is
+put back inside the face by the same delta, and the velocity relative to 
+the moving wall is flipped in z.  For instance, a stationary particle hit with a
+piston wall with velocity vz, will end the timestep with a velocity of 2*vz.
+
    
+
    Currently only face zlo may be specified.
+This creates a piston moving in the positive z direction.
+Particles with z coordinate less than the wall position
+are reflected to a z coordinate
+greater than the wall position.
+If the piston velocity is vpz and the particle velocity 
+before reflection is vzi, the particle velocity after
+reflection is -vzi + 2*vpz. 
+
    
+
    The initial position of the wall can be specified by the pos keyword.
+
    
+
    The final velocity of the wall can be specified by the vel keyword
+
    
+
    The ramp keyword will cause the wall/piston to adjust the velocity linearly
+from zero velocity to vel over the course of the run. If the ramp keyword is omitted
+then the wall/piston moves at a constant velocity defined by vel.
+
    
+
    The temp keyword will cause the region immediately in front of the wall/piston
+to be thermostated with a Langevin thermostat.  This region moves with the piston.
+The damping and kicking are measured in the reference frame of the piston.
+So, a temperature of zero would mean all particles were moving at exactly the speed
+of the wall/piston.
+
    
+
    The units keyword determines the meaning of the distance units used
+to define a wall position, but only when a numeric constant is used.
+
    
+
    A box value selects standard distance units as defined by the
+units command, e.g. Angstroms for units = real or metal.
+A lattice value means the distance units are in lattice spacings.
+The lattice command must have been previously used to
+define the lattice spacings.
+
    
+
    
+
+
    Restart, fix_modify, output, run start/stop, minimize info:
+
    
+
    No information about this fix is written to binary restart
+files.  None of the fix_modify options
+are relevant to this fix.  No global or per-atom quantities are stored
+by this fix for access by various output
+commands.  No parameter of this fix can be
+used with the start/stop keywords of the run command.
+This fix is not invoked during energy minimization.
+
    
+
    Restrictions:
+
    
+
    This fix style is part of the SHOCK package.  It is only enabled if
+LAMMPS was built with that package. See the Making
+LAMMPS section for more info.
+
    
+
    The face that has the wall/piston must be boundary type 'm' (shrink-wrapped 
+with minimum a minimum value). The opposing face can be 
+any boundary type other than periodic.
+
    
+
    A wall/piston should not be used with rigid bodies such as those
+defined by a "fix rigid" command.  This is because the wall/piston
+displaces atoms directly rather than exerting a force on them.
+
    
+
    Related commands:
+
    
+
    fix wall/reflect command
+
    
+
    fix append/atoms command
+
    
+
    Default: pos = 0, vel = 0, units = lattice.
+
    
+
    
+
+
diff --git a/doc/fix_wall_piston.txt b/doc/fix_wall_piston.txt
new file mode 100644
index 0000000000..5194733c75
--- /dev/null
+++ b/doc/fix_wall_piston.txt
@@ -0,0 +1,121 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+fix wall/piston command :h3
+
+[Syntax:]
+
+fix ID group-ID wall/piston face arg ... keyword value ... :pre
+
+ID, group-ID are documented in "fix"_fix.html command :ulb,l
+wall/piston = style name of this fix command :l
+one face/arg pair must be appended :l
+face = {zlo} :l
+zero or more keyword/value pairs may be appended :l
+keyword = {pos} or {vel} or {ramp} or {units}  :l
+  {pos} args = z
+    z = z coordinate at which the piston begins (distance units)
+  {vel} args = vz
+    vz = final velocity of the piston (velocity units)
+  {ramp} = use a linear velocity ramp from 0 to vz
+  {temp} args = target damp seed extent
+    target = target velocity for region immediately ahead of the piston
+    damp = damping paramter (time units)
+    seed = random number seed for langevin kicks
+    extent = extent of thermostated region (distance units)
+  {units} value = {lattice} or {box}
+    {lattice} = the wall position is defined in lattice units
+    {box} = the wall position is defined in simulation box units :pre
+:ule
+
+[Examples:]
+
+fix xwalls all wall/piston zlo
+fix walls all wall/piston zlo pos 1.0 0.0 0.0 vel 0.0 0.0 10.0 units box
+fix top all wall/piston zlo vel 0.0 0.0 10.0 ramp :pre
+
+[Description:]
+
+Bound the simulation with a moving wall which reflect particles
+in the specified group and drive the system with an effective infinite-mass
+piston capable of driving shock waves. 
+
+A momentum mirror technique is used, which means that if an atom (or the wall)
+moves such that an atom is outside the wall on a timestep
+by a distance delta (e.g. due to "fix nve"_fix_nve.html), then it is
+put back inside the face by the same delta, and the velocity relative to 
+the moving wall is flipped in z.  For instance, a stationary particle hit with a
+piston wall with velocity vz, will end the timestep with a velocity of 2*vz.
+
+Currently only face {zlo} may be specified.
+This creates a piston moving in the positive z direction.
+Particles with z coordinate less than the wall position
+are reflected to a z coordinate
+greater than the wall position.
+If the piston velocity is vpz and the particle velocity 
+before reflection is vzi, the particle velocity after
+reflection is -vzi + 2*vpz. 
+
+The initial position of the wall can be specified by the {pos} keyword.
+
+The final velocity of the wall can be specified by the {vel} keyword
+
+The {ramp} keyword will cause the wall/piston to adjust the velocity linearly
+from zero velocity to {vel} over the course of the run. If the {ramp} keyword is omitted
+then the wall/piston moves at a constant velocity defined by {vel}.
+
+The {temp} keyword will cause the region immediately in front of the wall/piston
+to be thermostated with a Langevin thermostat.  This region moves with the piston.
+The damping and kicking are measured in the reference frame of the piston.
+So, a temperature of zero would mean all particles were moving at exactly the speed
+of the wall/piston.
+
+The {units} keyword determines the meaning of the distance units used
+to define a wall position, but only when a numeric constant is used.
+
+A {box} value selects standard distance units as defined by the
+"units"_units.html command, e.g. Angstroms for units = real or metal.
+A {lattice} value means the distance units are in lattice spacings.
+The "lattice"_lattice.html command must have been previously used to
+define the lattice spacings.
+
+:line
+
+[Restart, fix_modify, output, run start/stop, minimize info:]
+
+No information about this fix is written to "binary restart
+files"_restart.html.  None of the "fix_modify"_fix_modify.html options
+are relevant to this fix.  No global or per-atom quantities are stored
+by this fix for access by various "output
+commands"_Section_howto.html#4_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 style is part of the SHOCK package.  It is only enabled if
+LAMMPS was built with that package. See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+The face that has the wall/piston must be boundary type 'm' (shrink-wrapped 
+with minimum a minimum value). The opposing face can be 
+any boundary type other than periodic.
+
+A wall/piston should not be used with rigid bodies such as those
+defined by a "fix rigid" command.  This is because the wall/piston
+displaces atoms directly rather than exerting a force on them.
+
+[Related commands:]
+
+"fix wall/reflect"_fix_wall.html command
+
+"fix append/atoms"_fix_append_atoms.html command
+
+[Default:] {pos} = 0, {vel} = 0, {units} = lattice.
+
+:line
diff --git a/doc/fix_wall_reflect.html b/doc/fix_wall_reflect.html
index 2f22de0db6..558f1c0ecb 100644
--- a/doc/fix_wall_reflect.html
+++ b/doc/fix_wall_reflect.html
@@ -88,9 +88,10 @@ box parameters and timestep and elapsed time.  Thus it is easy to
 specify a time-dependent wall position.
 
    
 
    The units keyword determines the meaning of the distance units used
-to define a wall position, but only when a numeric constant is used.
-It is not relevant when EDGE or a variable is used to specify a face
-position.
+to define a wall position, but only when a numeric constant or
+variable is used.  It is not relevant when EDGE is used to specify a
+face position.  In the variable case, the variable is assumed to
+produce a value compatible with the units setting you specify.
 
    
 
    A box value selects standard distance units as defined by the
 units command, e.g. Angstroms for units = real or metal.
@@ -105,16 +106,16 @@ in a time-dependent fashion using equal-style
 variables.
 
    
 
    variable ramp equal ramp(0,10)
-fix 1 all wall xlo v_ramp 1.0 1.0 2.5 
+fix 1 all wall/reflect xlo v_ramp 
 
    
 
    variable linear equal vlinear(0,20)
-fix 1 all wall xlo v_linear 1.0 1.0 2.5 
+fix 1 all wall/reflect xlo v_linear 
 
    
 
    variable wiggle equal swiggle(0.0,5.0,3.0)
-fix 1 all wall xlo v_wiggle 1.0 1.0 2.5 
+fix 1 all wall/reflect xlo v_wiggle  
 
    
 
    variable wiggle equal cwiggle(0.0,5.0,3.0)
-fix 1 all wall xlo v_wiggle 1.0 1.0 2.5 
+fix 1 all wall/reflect xlo v_wiggle 
 
    
 
    The ramp(lo,hi) function adjusts the wall position linearly from lo to
 hi over the course of a run.  The linear(c0,velocity) function does
@@ -141,9 +142,9 @@ perturbation on the particles:
 
    No information about this fix is written to binary restart
 files.  None of the fix_modify options
 are relevant to this fix.  No global or per-atom quantities are stored
-by this fix for access by various output
-commands.  No parameter of this fix can be
-used with the start/stop keywords of the run command.
+by this fix for access by various output
+commands.  No parameter of this fix can
+be used with the start/stop keywords of the run command.
 This fix is not invoked during energy minimization.
 
    
 
    Restrictions:
diff --git a/doc/fix_wall_reflect.txt b/doc/fix_wall_reflect.txt
index 00cea46b2e..4615eadf89 100644
--- a/doc/fix_wall_reflect.txt
+++ b/doc/fix_wall_reflect.txt
@@ -77,9 +77,10 @@ box parameters and timestep and elapsed time.  Thus it is easy to
 specify a time-dependent wall position.
 
 The {units} keyword determines the meaning of the distance units used
-to define a wall position, but only when a numeric constant is used.
-It is not relevant when EDGE or a variable is used to specify a face
-position.
+to define a wall position, but only when a numeric constant or
+variable is used.  It is not relevant when EDGE is used to specify a
+face position.  In the variable case, the variable is assumed to
+produce a value compatible with the {units} setting you specify.
 
 A {box} value selects standard distance units as defined by the
 "units"_units.html command, e.g. Angstroms for units = real or metal.
@@ -94,16 +95,16 @@ in a time-dependent fashion using equal-style
 "variables"_variable.html.
 
 variable ramp equal ramp(0,10)
-fix 1 all wall xlo v_ramp 1.0 1.0 2.5 :pre
+fix 1 all wall/reflect xlo v_ramp :pre
 
 variable linear equal vlinear(0,20)
-fix 1 all wall xlo v_linear 1.0 1.0 2.5 :pre
+fix 1 all wall/reflect xlo v_linear :pre
 
 variable wiggle equal swiggle(0.0,5.0,3.0)
-fix 1 all wall xlo v_wiggle 1.0 1.0 2.5 :pre
+fix 1 all wall/reflect xlo v_wiggle  :pre
 
 variable wiggle equal cwiggle(0.0,5.0,3.0)
-fix 1 all wall xlo v_wiggle 1.0 1.0 2.5 :pre
+fix 1 all wall/reflect xlo v_wiggle :pre
 
 The ramp(lo,hi) function adjusts the wall position linearly from lo to
 hi over the course of a run.  The linear(c0,velocity) function does
@@ -131,8 +132,8 @@ No information about this fix is written to "binary restart
 files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.  No global or per-atom quantities are stored
 by this fix for access by various "output
-commands"_Section_howto.html#4_15.  No parameter of this fix can be
-used with the {start/stop} keywords of the "run"_run.html command.
+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:]
diff --git a/doc/fix_wall_region.html b/doc/fix_wall_region.html
index 5234bb5bf5..bd393f655a 100644
--- a/doc/fix_wall_region.html
+++ b/doc/fix_wall_region.html
@@ -163,9 +163,9 @@ system's potential energy as part of thermodynamic
 output.
 
    
 
    This fix computes a global scalar energy and a global 3-length vector
-of forces, which can be accessed by various output
-commands.  The scalar energy is the sum of
-energy interactions for all particles interacting with the wall
+of forces, which can be accessed by various output
+commands.  The scalar energy is the sum
+of energy interactions for all particles interacting with the wall
 represented by the region surface.  The 3 vector quantities are the
 x,y,z components of the total force acting on the wall due to the
 particles.  The scalar and vector values calculated by this fix are
diff --git a/doc/fix_wall_region.txt b/doc/fix_wall_region.txt
index a2651cb0cd..e84ad09641 100644
--- a/doc/fix_wall_region.txt
+++ b/doc/fix_wall_region.txt
@@ -161,8 +161,8 @@ output"_thermo_style.html.
 
 This fix computes a global scalar energy and a global 3-length vector
 of forces, which can be accessed by various "output
-commands"_Section_howto.html#4_15.  The scalar energy is the sum of
-energy interactions for all particles interacting with the wall
+commands"_Section_howto.html#howto_15.  The scalar energy is the sum
+of energy interactions for all particles interacting with the wall
 represented by the region surface.  The 3 vector quantities are the
 x,y,z components of the total force acting on the wall due to the
 particles.  The scalar and vector values calculated by this fix are
diff --git a/doc/fix_wall_srd.html b/doc/fix_wall_srd.html
index 8a26803400..cdb808f73c 100644
--- a/doc/fix_wall_srd.html
+++ b/doc/fix_wall_srd.html
@@ -139,16 +139,16 @@ in a time-dependent fashion using equal-style
 variables.
 
    
 
    variable ramp equal ramp(0,10)
-fix 1 all wall xlo v_ramp 1.0 1.0 2.5 
+fix 1 all wall/srd xlo v_ramp 
 
    
 
    variable linear equal vlinear(0,20)
-fix 1 all wall xlo v_linear 1.0 1.0 2.5 
+fix 1 all wall/srd xlo v_linear 
 
    
 
    variable wiggle equal swiggle(0.0,5.0,3.0)
-fix 1 all wall xlo v_wiggle 1.0 1.0 2.5 
+fix 1 all wall/srd xlo v_wiggle  
 
    
 
    variable wiggle equal cwiggle(0.0,5.0,3.0)
-fix 1 all wall xlo v_wiggle 1.0 1.0 2.5 
+fix 1 all wall/srd xlo v_wiggle 
 
    
 
    The ramp(lo,hi) function adjusts the wall position linearly from lo to
 hi over the course of a run.  The linear(c0,velocity) function does
@@ -177,9 +177,9 @@ files.  None of the fix_modify options
 are relevant to this fix.
 
    
 
    This fix computes a global array of values which can be accessed by
-various output commands.  The number of rows
-in the array is equal to the number of walls defined by the fix.  The
-number of columns is 3, for the x,y,z components of force on each
+various output commands.  The number of
+rows in the array is equal to the number of walls defined by the fix.
+The number of columns is 3, for the x,y,z components of force on each
 wall.
 
    
 
    Note that an outward normal force on a wall will be a negative value
diff --git a/doc/fix_wall_srd.txt b/doc/fix_wall_srd.txt
index 4d098cfb29..596ebe40b8 100644
--- a/doc/fix_wall_srd.txt
+++ b/doc/fix_wall_srd.txt
@@ -127,17 +127,18 @@ Here are examples of variable definitions that move the wall position
 in a time-dependent fashion using equal-style
 "variables"_variable.html.
 
+
 variable ramp equal ramp(0,10)
-fix 1 all wall xlo v_ramp 1.0 1.0 2.5 :pre
+fix 1 all wall/srd xlo v_ramp :pre
 
 variable linear equal vlinear(0,20)
-fix 1 all wall xlo v_linear 1.0 1.0 2.5 :pre
+fix 1 all wall/srd xlo v_linear :pre
 
 variable wiggle equal swiggle(0.0,5.0,3.0)
-fix 1 all wall xlo v_wiggle 1.0 1.0 2.5 :pre
+fix 1 all wall/srd xlo v_wiggle  :pre
 
 variable wiggle equal cwiggle(0.0,5.0,3.0)
-fix 1 all wall xlo v_wiggle 1.0 1.0 2.5 :pre
+fix 1 all wall/srd xlo v_wiggle :pre
 
 The ramp(lo,hi) function adjusts the wall position linearly from lo to
 hi over the course of a run.  The linear(c0,velocity) function does
@@ -166,9 +167,9 @@ files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.
 
 This fix computes a global array of values which can be accessed by
-various "output commands"_Section_howto.html#4_15.  The number of rows
-in the array is equal to the number of walls defined by the fix.  The
-number of columns is 3, for the x,y,z components of force on each
+various "output commands"_Section_howto.html#howto_15.  The number of
+rows in the array is equal to the number of walls defined by the fix.
+The number of columns is 3, for the x,y,z components of force on each
 wall.
 
 Note that an outward normal force on a wall will be a negative value
diff --git a/doc/if.html b/doc/if.html
index bbbbfb5f24..3baffda0fc 100644
--- a/doc/if.html
+++ b/doc/if.html
@@ -66,7 +66,7 @@ above.
 
    IMPORTANT NOTE: If a command itself requires a quoted argument (e.g. a
 print command), then double and single quotes can be used
 and nested in the usual manner, as in the examples above and below.
-See this section of the manual for more
+See this section of the manual for more
 details on using quotes in arguments.  Only one of level of nesting is
 allowed, but that should be sufficient for most use cases.
 
    
@@ -149,6 +149,8 @@ returns 0.0.
 
    The overall Boolean expression produces a TRUE result if the result is
 non-zero.  If the result is zero, the expression result is FALSE.
 
    
+
    
+
 
    Restrictions: none
 
    
 
    Related commands:
diff --git a/doc/if.txt b/doc/if.txt
index 7ecf6eb401..a92b9213b9 100644
--- a/doc/if.txt
+++ b/doc/if.txt
@@ -63,7 +63,7 @@ above.
 IMPORTANT NOTE: If a command itself requires a quoted argument (e.g. a
 "print"_print.html command), then double and single quotes can be used
 and nested in the usual manner, as in the examples above and below.
-See "this section"_Section_commands.html#3_2 of the manual for more
+See "this section"_Section_commands.html#cmd_2 of the manual for more
 details on using quotes in arguments.  Only one of level of nesting is
 allowed, but that should be sufficient for most use cases.
 
@@ -145,6 +145,8 @@ returns 0.0.
 The overall Boolean expression produces a TRUE result if the result is
 non-zero.  If the result is zero, the expression result is FALSE.
 
+:line
+
 [Restrictions:] none
 
 [Related commands:]
diff --git a/doc/improper_class2.html b/doc/improper_class2.html
index 6fa33fdb2b..437bedf9e8 100644
--- a/doc/improper_class2.html
+++ b/doc/improper_class2.html
@@ -11,6 +11,8 @@
 
 
    improper_style class2 command 
 
    
+
    improper_style class2/omp command 
+
    
 
    Syntax:
 
    
 
    improper_style class2 
@@ -83,10 +85,34 @@ listed under a "AngleAngle Coeffs" heading and you must leave out the
 
    The theta values are specified in degrees, but LAMMPS converts them to
 radians internally; hence the units of M are in energy/radian^2.
 
    
+
    
+
+
    Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
 
    Restrictions:
 
    
 
    This improper style can only be used if LAMMPS was built with the
-"class2" package.  See the Making LAMMPS
+CLASS2 package.  See the Making LAMMPS
 section for more info on packages.
 
    
 
    Related commands:
diff --git a/doc/improper_class2.txt b/doc/improper_class2.txt
index c2c2419a6e..52f93f924d 100644
--- a/doc/improper_class2.txt
+++ b/doc/improper_class2.txt
@@ -7,6 +7,7 @@
 :line
 
 improper_style class2 command :h3
+improper_style class2/omp command :h3
 
 [Syntax:]
 
@@ -80,10 +81,34 @@ theta3 (degrees) :ul
 The theta values are specified in degrees, but LAMMPS converts them to
 radians internally; hence the units of M are in energy/radian^2.
 
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restrictions:]
 
 This improper style can only be used if LAMMPS was built with the
-"class2" package.  See the "Making LAMMPS"_Section_start.html#2_3
+CLASS2 package.  See the "Making LAMMPS"_Section_start.html#start_3
 section for more info on packages.
 
 [Related commands:]
diff --git a/doc/improper_coeff.html b/doc/improper_coeff.html
index 6361337896..1808e9be3a 100644
--- a/doc/improper_coeff.html
+++ b/doc/improper_coeff.html
@@ -79,7 +79,7 @@ specified by the associated improper_coeff c
 
 
    There are also additional improper styles submitted by users which are
 included in the LAMMPS distribution.  The list of these with links to
-the individual styles are given in the improper section of this
+the individual styles are given in the improper section of this
 page.
 
    
 
    
diff --git a/doc/improper_coeff.txt b/doc/improper_coeff.txt
index 642b881ea1..a3defc2741 100644
--- a/doc/improper_coeff.txt
+++ b/doc/improper_coeff.txt
@@ -77,7 +77,7 @@ specified by the associated "improper_coeff"_improper_coeff.html command:
 There are also additional improper styles submitted by users which are
 included in the LAMMPS distribution.  The list of these with links to
 the individual styles are given in the improper section of "this
-page"_Section_commands.html#3_5.
+page"_Section_commands.html#cmd_5.
 
 :line
 
diff --git a/doc/improper_cvff.html b/doc/improper_cvff.html
index dedef21f2e..894c2979ef 100644
--- a/doc/improper_cvff.html
+++ b/doc/improper_cvff.html
@@ -11,6 +11,8 @@
 
 
    improper_style cvff command 
 
    
+
    improper_style cvff/omp command 
+
    
 
    Syntax:
 
    
 
    improper_style cvff 
@@ -53,10 +55,34 @@ commands:
 
  • d (+1 or -1)
 
  • n (0,1,2,3,4,6) 
 
+
    
+
+
    Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
 
    Restrictions:
 
    
 
    This improper style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the Making
+MOLECULAR package (which it is by default).  See the Making
 LAMMPS section for more info on packages.
 
    
 
    Related commands:
diff --git a/doc/improper_cvff.txt b/doc/improper_cvff.txt
index b58dd83382..7bff075847 100644
--- a/doc/improper_cvff.txt
+++ b/doc/improper_cvff.txt
@@ -7,6 +7,7 @@
 :line
 
 improper_style cvff command :h3
+improper_style cvff/omp command :h3
 
 [Syntax:]
 
@@ -50,11 +51,35 @@ K (energy)
 d (+1 or -1)
 n (0,1,2,3,4,6) :ul
 
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restrictions:]
 
 This improper style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info on packages.
+MOLECULAR package (which it is by default).  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]
 
diff --git a/doc/improper_harmonic.html b/doc/improper_harmonic.html
index 5d3604c10d..d62ca4a8a7 100644
--- a/doc/improper_harmonic.html
+++ b/doc/improper_harmonic.html
@@ -11,6 +11,8 @@
 
 
    improper_style harmonic command 
 
    
+
    improper_style harmonic/omp command 
+
    
 
    Syntax:
 
    
 
    improper_style harmonic 
@@ -53,10 +55,34 @@ commands:
 
    X0 is specified in degrees, but LAMMPS converts it to radians
 internally; hence the units of K are in energy/radian^2.
 
    
+
    
+
+
    Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
 
    Restrictions:
 
    
 
    This improper style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the Making
+MOLECULAR package (which it is by default).  See the Making
 LAMMPS section for more info on packages.
 
    
 
    Related commands:
diff --git a/doc/improper_harmonic.txt b/doc/improper_harmonic.txt
index c1170edb27..0d4317130c 100644
--- a/doc/improper_harmonic.txt
+++ b/doc/improper_harmonic.txt
@@ -7,6 +7,7 @@
 :line
 
 improper_style harmonic command :h3
+improper_style harmonic/omp command :h3
 
 [Syntax:]
 
@@ -50,11 +51,35 @@ X0 (degrees) :ul
 X0 is specified in degrees, but LAMMPS converts it to radians
 internally; hence the units of K are in energy/radian^2.
 
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restrictions:]
 
 This improper style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info on packages.
+MOLECULAR package (which it is by default).  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]
 
diff --git a/doc/improper_hybrid.html b/doc/improper_hybrid.html
index 981fc7945a..3bbdf3710d 100644
--- a/doc/improper_hybrid.html
+++ b/doc/improper_hybrid.html
@@ -53,10 +53,12 @@ type will then be ignored.
 the improper_coeff command, if you desire to turn off certain improper
 types.
 
    
+
    
+
 
    Restrictions:
 
    
 
    This improper style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the Making
+MOLECULAR package (which it is by default).  See the Making
 LAMMPS section for more info on packages.
 
    
 
    Unlike other improper styles, the hybrid improper style does not store
diff --git a/doc/improper_hybrid.txt b/doc/improper_hybrid.txt
index 6a17b82ee4..620b381717 100644
--- a/doc/improper_hybrid.txt
+++ b/doc/improper_hybrid.txt
@@ -50,11 +50,13 @@ An improper style of {none} can be specified as the 2nd argument to
 the improper_coeff command, if you desire to turn off certain improper
 types.
 
+:line
+
 [Restrictions:]
 
 This improper style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info on packages.
+MOLECULAR package (which it is by default).  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 Unlike other improper styles, the hybrid improper style does not store
 improper coefficient info for individual sub-styles in a "binary
diff --git a/doc/improper_style.html b/doc/improper_style.html
index 189f6e2e07..db288b7a80 100644
--- a/doc/improper_style.html
+++ b/doc/improper_style.html
@@ -71,7 +71,7 @@ specified by the associated improper_coeff c
 
 
    There are also additional improper styles submitted by users which are
 included in the LAMMPS distribution.  The list of these with links to
-the individual styles are given in the improper section of this
+the individual styles are given in the improper section of this
 page.
 
    
 
    
@@ -81,11 +81,11 @@ page.
 
    Improper styles can only be set for atom_style choices that allow
 impropers to be defined.
 
    
-
    Most improper styles are part of the "molecular" package.  They are
-only enabled if LAMMPS was built with that package.  See the Making
-LAMMPS section for more info on packages.  The
-doc pages for individual improper potentials tell if it is part of a
-package.
+
    Most improper styles are part of the MOLECULAR package.  They are only
+enabled if LAMMPS was built with that package.  See the Making
+LAMMPS section for more info on packages.
+The doc pages for individual improper potentials tell if it is part of
+a package.
 
    
 
    Related commands:
 
    
diff --git a/doc/improper_style.txt b/doc/improper_style.txt
index c7e1c08b7c..d636311719 100644
--- a/doc/improper_style.txt
+++ b/doc/improper_style.txt
@@ -69,7 +69,7 @@ specified by the associated "improper_coeff"_improper_coeff.html command:
 There are also additional improper styles submitted by users which are
 included in the LAMMPS distribution.  The list of these with links to
 the individual styles are given in the improper section of "this
-page"_Section_commands.html#3_5.
+page"_Section_commands.html#cmd_5.
 
 :line
 
@@ -78,11 +78,11 @@ page"_Section_commands.html#3_5.
 Improper styles can only be set for atom_style choices that allow
 impropers to be defined.
 
-Most improper styles are part of the "molecular" package.  They are
-only enabled if LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info on packages.  The
-doc pages for individual improper potentials tell if it is part of a
-package.
+Most improper styles are part of the MOLECULAR package.  They are only
+enabled if LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
+The doc pages for individual improper potentials tell if it is part of
+a package.
 
 [Related commands:]
 
diff --git a/doc/improper_umbrella.html b/doc/improper_umbrella.html
index b3d66ac165..84cdbc8439 100644
--- a/doc/improper_umbrella.html
+++ b/doc/improper_umbrella.html
@@ -11,6 +11,8 @@
 
 
    improper_style umbrella command 
 
    
+
    improper_style umbrella/omp command 
+
    
 
    Syntax:
 
    
 
    improper_style umbrella 
@@ -24,7 +26,7 @@ improper_coeff 1 100.0 180.0
 
    
 
    The umbrella improper style uses the following potential, which is
 commonly referred to as a classic inversion and used in the
-DREIDING force field:
+DREIDING force field:
 
    
 
    
 
    
@@ -48,10 +50,34 @@ commands:
 
    • K (energy)
 
    • omega0 (degrees) 
 
    
+
    
+
+
    Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
 
    Restrictions:
 
    
 
    This improper style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the Making
+MOLECULAR package (which it is by default).  See the Making
 LAMMPS section for more info on packages.
 
    
 
    Related commands:
diff --git a/doc/improper_umbrella.txt b/doc/improper_umbrella.txt
index d0d43ab122..7ec8cfb1e0 100644
--- a/doc/improper_umbrella.txt
+++ b/doc/improper_umbrella.txt
@@ -7,6 +7,7 @@
 :line
 
 improper_style umbrella command :h3
+improper_style umbrella/omp command :h3
 
 [Syntax:]
 
@@ -21,7 +22,7 @@ improper_coeff 1 100.0 180.0 :pre
 
 The {umbrella} improper style uses the following potential, which is
 commonly referred to as a classic inversion and used in the
-"DREIDING"_Section_howto.html#4_4 force field:
+"DREIDING"_Section_howto.html#howto_4 force field:
 
 :c,image(Eqs/improper_umbrella.jpg)
 
@@ -45,11 +46,35 @@ commands:
 K (energy)
 omega0 (degrees) :ul
 
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restrictions:]
 
 This improper style can only be used if LAMMPS was built with the
-"molecular" package (which it is by default).  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info on packages.
+MOLECULAR package (which it is by default).  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]
 
diff --git a/doc/jump.html b/doc/jump.html
index ac8129a3b6..2d175a6a79 100644
--- a/doc/jump.html
+++ b/doc/jump.html
@@ -43,10 +43,11 @@ e.g.
 
    
 
    since the SELF option invokes the C-library rewind() call, which may
 not be supported for stdin on some systems.  This can be worked around
-by using the -in command-line argument or the
--var command-line argument to pass the script
-name as a variable to the input script In the latter case, the "fname"
-variable could be used in place of SELF.  E.g.
+by using the -in command-line argument or
+the -var command-line argument to pass
+the script name as a variable to the input script In the latter case,
+the "fname" variable could be used in place of SELF.
+E.g.
 
    
 
    lmp_g++ -in in.script 
 
    
diff --git a/doc/jump.txt b/doc/jump.txt
index 277e17e1bc..83f40af7e9 100644
--- a/doc/jump.txt
+++ b/doc/jump.txt
@@ -40,10 +40,11 @@ lmp_g++ < in.script :pre
 
 since the SELF option invokes the C-library rewind() call, which may
 not be supported for stdin on some systems.  This can be worked around
-by using the "-in command-line argument"_Section_start.html#2_6 or the
-"-var command-line argument"_Section_start.html#2_6 to pass the script
-name as a variable to the input script In the latter case, the "fname"
-"variable"_variable.html could be used in place of SELF.  E.g.
+by using the "-in command-line argument"_Section_start.html#start_6 or
+the "-var command-line argument"_Section_start.html#start_6 to pass
+the script name as a variable to the input script In the latter case,
+the "fname" "variable"_variable.html could be used in place of SELF.
+E.g.
 
 lmp_g++ -in in.script :pre
 lmp_g++ -var fname n.script < in.script :pre
diff --git a/doc/kspace_style.html b/doc/kspace_style.html
index 57c035f570..7e54d18de6 100644
--- a/doc/kspace_style.html
+++ b/doc/kspace_style.html
@@ -15,16 +15,27 @@
 
    
 
    kspace_style style value 
 
    
-
    • style = none or ewald or pppm or pppm/tip4p or ewald/n 
+
      • style = none or ewald or pppm or pppm/cg or pppm/tip4p or ewald/n or pppm/gpu or ewald/omp or pppm/omp or pppm/proxy 
 
 
          none value = none
   ewald value = precision
     precision = desired accuracy
   pppm value = precision
     precision = desired accuracy
+  pppm/cg value = precision (smallq)
+    precision = desired accuracy
+    smallq = cutoff for charges to be considered (optional) (charge units)
   pppm/tip4p value = precision
     precision = desired accuracy
   ewald/n value = precision
+    precision = desired accuracy
+  pppm/gpu value = precision
+    precision = desired accuracy
+  ewald/omp value = precision
+    precision = desired accuracy
+  pppm/omp value = precision
+    precision = desired accuracy
+  pppm/proxy value = precision
     precision = desired accuracy 
 
        
 
@@ -32,6 +43,7 @@
 
        Examples:
 
        
 
        kspace_style pppm 1.0e-4
+kspace_style pppm/cg 1.0e-5 1.0e-6
 kspace_style none 
 
        
 
        Description:
@@ -56,6 +68,12 @@ N^(3/2) where N is the number of atoms in the system.  The PPPM solver
 scales as Nlog(N) due to the FFTs, so it is almost always a faster
 choice (Pollock).
 
        
+
        The pppm/cg style is identical to the pppm style except that it
+has an optimization for systems where most particles are uncharged.
+The optional smallq argument defines the cutoff for the absolute
+charge value which determines whether a particle is considered charged
+or not.  Its default value is 1.0e-5.
+
        
 
        The pppm/tip4p style is identical to the pppm style except that it
 adds a charge at the massless 4th site in each TIP4P water molecule.
 It should be used with pair styles with a
@@ -72,6 +90,27 @@ long-range potentials.
 
        Currently, only the ewald/n style can be used with non-orthogonal
 (triclinic symmetry) simulation boxes.
 
        
+
        The pppm/proxy style is a special variant for calculations 
+in hybrid OpenMP/MPI parallel mode. It is functionally equivalent
+with pppm, but it its force computation is being executed 
+as a single thread concurrently with a multi-threaded non-bonded
+calculation for a pair style with pppm/omp suffix. For calcuations
+across many multi-core nodes, this can have a performance benefit
+over performing the real and reciprocal space part separately,
+specifically when otherwise the time spent on the pair style
+would slightly less than in pppm without threading.
+
        
+
        Note that the PPPM styles can be used with single-precision FFTs by
+using the compiler switch -DFFT_SINGLE for the FFT_INC setting in your
+lo-level Makefile.  This setting also changes some of the PPPM
+operations (e.g. mapping charge to mesh and interpolating electric
+fields to particles) to be performed in single precision.  This option
+can speed-up long-range calulations, particularly in parallel or on
+GPUs.  The use of the -DFFT_SINGLE flag is discussed in this
+section of the manual.
+
        
+
        
+
 
        When a kspace style is used, a pair style that includes the
 short-range correction to the pairwise Coulombic or other 1/r^N forces
 must also be selected.  For Coulombic interactions, these styles are
@@ -88,6 +127,33 @@ of K-space vectors for style ewald or the FFT grid size for style
 
        See the kspace_modify command for additional
 options of the K-space solvers that can be set.
 
        
+
        
+
+
        Styles with a cuda, gpu, omp, or opt suffix are
+functionally the same as the corresponding style without the suffix.
+They have been optimized to run faster, depending on your available
+hardware, as discussed in this section of
+the manual.  The accelerated styles take the same arguments and should
+produce the same results, except for round-off and precision issues.
+
        
+
        More specifically, the pppm/gpu style performs charge assignment and
+force interpolation calculations on the GPU.  These processes are
+performed either in single or double precision, depending on whether
+the -DFFT_SINGLE setting was specified in your lo-level Makefile, as
+discussed above.  The FFTs themselves are still calculated on the CPU.
+If pppm/gpu is used with a GPU-enabled pair style, part of the PPPM
+calculation can be performed concurrently on the GPU while other
+calculations for non-bonded and bonded force calculation are performed
+on the CPU.
+
        
+
        These accelerated styles are part of the USER-CUDA, GPU, USER-OMP, and
+OPT packages respectively.  They are only enabled if LAMMPS was built
+with those packages.  See the Making LAMMPS
+section for more info.
+
        
+
        See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
        
 
        Restrictions:
 
        
 
        A simulation must be 3d and periodic in all dimensions to use an Ewald
@@ -95,12 +161,12 @@ or PPPM solver.  The only exception is if the slab option is set with
 kspace_modify, in which case the xy dimensions
 must be periodic and the z dimension must be non-periodic.
 
        
-
        Kspace styles are part of the "kspace" package.  They are only enabled
-if LAMMPS was built with that package.  See the Making
+
        Kspace styles are part of the KSPACE package.  They are only enabled
+if LAMMPS was built with that package.  See the Making
 LAMMPS section for more info.
 
        
-
        The ewald/n style is part of the "user-ewaldn" package.  It is only
-enabled if LAMMPS was built with that package.  See the Making
+
        The ewald/n style is part of the USER-EWALDN package.  It is only
+enabled if LAMMPS was built with that package.  See the Making
 LAMMPS section for more info.
 
        
 
        When using a long-range pairwise TIP4P potential, you must use kspace
diff --git a/doc/kspace_style.txt b/doc/kspace_style.txt
index b6b12696d2..b6d70f66d4 100644
--- a/doc/kspace_style.txt
+++ b/doc/kspace_style.txt
@@ -12,21 +12,33 @@ kspace_style command :h3
 
 kspace_style style value :pre
 
-style = {none} or {ewald} or {pppm} or {pppm/tip4p} or {ewald/n} :ulb,l
+style = {none} or {ewald} or {pppm} or {pppm/cg} or {pppm/tip4p} or {ewald/n} or {pppm/gpu} or {ewald/omp} or {pppm/omp} or {pppm/proxy} :ulb,l
   {none} value = none
   {ewald} value = precision
     precision = desired accuracy
   {pppm} value = precision
     precision = desired accuracy
+  {pppm/cg} value = precision (smallq)
+    precision = desired accuracy
+    smallq = cutoff for charges to be considered (optional) (charge units)
   {pppm/tip4p} value = precision
     precision = desired accuracy
   {ewald/n} value = precision
+    precision = desired accuracy
+  {pppm/gpu} value = precision
+    precision = desired accuracy
+  {ewald/omp} value = precision
+    precision = desired accuracy
+  {pppm/omp} value = precision
+    precision = desired accuracy
+  {pppm/proxy} value = precision
     precision = desired accuracy :pre
 :ule
 
 [Examples:]
 
 kspace_style pppm 1.0e-4
+kspace_style pppm/cg 1.0e-5 1.0e-6
 kspace_style none :pre
 
 [Description:]
@@ -51,6 +63,12 @@ N^(3/2) where N is the number of atoms in the system.  The PPPM solver
 scales as Nlog(N) due to the FFTs, so it is almost always a faster
 choice "(Pollock)"_#Pollock.
 
+The {pppm/cg} style is identical to the {pppm} style except that it
+has an optimization for systems where most particles are uncharged.
+The optional {smallq} argument defines the cutoff for the absolute
+charge value which determines whether a particle is considered charged
+or not.  Its default value is 1.0e-5.
+
 The {pppm/tip4p} style is identical to the {pppm} style except that it
 adds a charge at the massless 4th site in each TIP4P water molecule.
 It should be used with "pair styles"_pair_style.html with a
@@ -67,6 +85,27 @@ long-range potentials.
 Currently, only the {ewald/n} style can be used with non-orthogonal
 (triclinic symmetry) simulation boxes.
 
+The {pppm/proxy} style is a special variant for calculations 
+in hybrid OpenMP/MPI parallel mode. It is functionally equivalent
+with {pppm}, but it its force computation is being executed 
+as a single thread concurrently with a multi-threaded non-bonded
+calculation for a pair style with {pppm/omp} suffix. For calcuations
+across many multi-core nodes, this can have a performance benefit
+over performing the real and reciprocal space part separately,
+specifically when otherwise the time spent on the pair style
+would slightly less than in {pppm} without threading.
+
+Note that the PPPM styles can be used with single-precision FFTs by
+using the compiler switch -DFFT_SINGLE for the FFT_INC setting in your
+lo-level Makefile.  This setting also changes some of the PPPM
+operations (e.g. mapping charge to mesh and interpolating electric
+fields to particles) to be performed in single precision.  This option
+can speed-up long-range calulations, particularly in parallel or on
+GPUs.  The use of the -DFFT_SINGLE flag is discussed in "this
+section"_Section_start.html#start_2_4 of the manual.
+
+:line
+
 When a kspace style is used, a pair style that includes the
 short-range correction to the pairwise Coulombic or other 1/r^N forces
 must also be selected.  For Coulombic interactions, these styles are
@@ -83,6 +122,33 @@ of K-space vectors for style {ewald} or the FFT grid size for style
 See the "kspace_modify"_kspace_modify.html command for additional
 options of the K-space solvers that can be set.
 
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are
+functionally the same as the corresponding style without the suffix.
+They have been optimized to run faster, depending on your available
+hardware, as discussed in "this section"_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.
+
+More specifically, the {pppm/gpu} style performs charge assignment and
+force interpolation calculations on the GPU.  These processes are
+performed either in single or double precision, depending on whether
+the -DFFT_SINGLE setting was specified in your lo-level Makefile, as
+discussed above.  The FFTs themselves are still calculated on the CPU.
+If {pppm/gpu} is used with a GPU-enabled pair style, part of the PPPM
+calculation can be performed concurrently on the GPU while other
+calculations for non-bonded and bonded force calculation are performed
+on the CPU.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP, and
+OPT packages respectively.  They are only enabled if LAMMPS was built
+with those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
 [Restrictions:]
 
 A simulation must be 3d and periodic in all dimensions to use an Ewald
@@ -90,13 +156,13 @@ or PPPM solver.  The only exception is if the slab option is set with
 "kspace_modify"_kspace_modify.html, in which case the xy dimensions
 must be periodic and the z dimension must be non-periodic.
 
-Kspace styles are part of the "kspace" package.  They are only enabled
+Kspace styles are part of the KSPACE package.  They are only enabled
 if LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+LAMMPS"_Section_start.html#start_3 section for more info.
 
-The {ewald/n} style is part of the "user-ewaldn" package.  It is only
+The {ewald/n} style is part of the USER-EWALDN package.  It is only
 enabled if LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+LAMMPS"_Section_start.html#start_3 section for more info.
 
 When using a long-range pairwise TIP4P potential, you must use kspace
 style {pppm/tip4p} and vice versa.
diff --git a/doc/log.html b/doc/log.html
index baf805ee69..2edfe3fcd6 100644
--- a/doc/log.html
+++ b/doc/log.html
@@ -33,7 +33,8 @@ the same log file.
 
        
 
        The file "log.lammps" is the default log file for a LAMMPS run.  The
 name of the initial log file can also be set by the command-line
-switch -log.  See this section for details.
+switch -log.  See this section for
+details.
 
        
 
        Restrictions: none
 
        
diff --git a/doc/log.txt b/doc/log.txt
index 76a5729c3a..dc56bfcb60 100644
--- a/doc/log.txt
+++ b/doc/log.txt
@@ -30,7 +30,8 @@ the same log file.
 
 The file "log.lammps" is the default log file for a LAMMPS run.  The
 name of the initial log file can also be set by the command-line
-switch -log.  See "this section"_Section_start.html#2_6 for details.
+switch -log.  See "this section"_Section_start.html#start_6 for
+details.
 
 [Restrictions:] none
 
diff --git a/doc/mass.html b/doc/mass.html
index ee18fb6898..afdc4c6cc9 100644
--- a/doc/mass.html
+++ b/doc/mass.html
@@ -51,13 +51,13 @@ line that corresponds to the 1st example above would be listed as
 
    
 
    Note that the mass command can only be used if the atom
 style requires per-type atom mass to be set.
-Currently, all but the granular and peri styles do.  They require
-mass to be set for individual particles, not types.  Per-atom masses
-are defined in the data file read by the read_data
-command, or set to default values by the
+Currently, all but the sphere and ellipsoid and peri styles do.
+They require mass to be set for individual particles, not types.
+Per-atom masses are defined in the data file read by the
+read_data command, or set to default values by the
 create_atoms command.  Per-atom masses can also be
-set to new values by the set diameter or set
-density command.
+set to new values by the set mass or set density
+commands.
 
    
 
    Also note that pair_style eam defines the masses of
 atom types in the EAM potential file, in which case the mass command
diff --git a/doc/mass.txt b/doc/mass.txt
index bb7d5ffb96..c024da20a9 100644
--- a/doc/mass.txt
+++ b/doc/mass.txt
@@ -48,13 +48,13 @@ line that corresponds to the 1st example above would be listed as
 
 Note that the mass command can only be used if the "atom
 style"_atom_style.html requires per-type atom mass to be set.
-Currently, all but the {granular} and {peri} styles do.  They require
-mass to be set for individual particles, not types.  Per-atom masses
-are defined in the data file read by the "read_data"_read_data.html
-command, or set to default values by the
+Currently, all but the {sphere} and {ellipsoid} and {peri} styles do.
+They require mass to be set for individual particles, not types.
+Per-atom masses are defined in the data file read by the
+"read_data"_read_data.html command, or set to default values by the
 "create_atoms"_create_atoms.html command.  Per-atom masses can also be
-set to new values by the "set diameter"_set.html or "set
-density"_set.html command.
+set to new values by the "set mass"_set.html or "set density"_set.html
+commands.
 
 Also note that "pair_style eam"_pair_eam.html defines the masses of
 atom types in the EAM potential file, in which case the mass command
diff --git a/doc/neb.html b/doc/neb.html
index 67a4ed5961..25cc68b644 100644
--- a/doc/neb.html
+++ b/doc/neb.html
@@ -42,13 +42,14 @@ follows the discussion in these 3 papers: (Henkelman1)
 
    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 this section 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.  You
-will simply not get the performance speed-up you would see with one or
-more physical processors per replica.  See this
-section of the manual for further discussion.
+switch; see this section 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.  You will simply not get the performance speed-up you
+would see with one or more physical processors per replica.  See this
+section of the manual for further
+discussion.
 
    
 
    NOTE: The current NEB implementation in LAMMPS restricts you to having
 exactly one processor per replica.
@@ -303,9 +304,9 @@ image.
 
 
    Restrictions:
 
    
-
    This command can only be used if LAMMPS was built with the "replica"
-package.  See the Making LAMMPS section for
-more info on packages.
+
    This command can only be used if LAMMPS was built with the REPLICA
+package.  See the Making LAMMPS section
+for more info on packages.
 
    
 
    Related commands:
 
    
diff --git a/doc/neb.txt b/doc/neb.txt
index 1e9cb0e20f..1965f23348 100644
--- a/doc/neb.txt
+++ b/doc/neb.txt
@@ -39,13 +39,14 @@ follows the discussion in these 3 papers: "(Henkelman1)"_#Henkelman1,
 
 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 "this section"_Section_start.html#2_6 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.  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#4_5 of the manual for further discussion.
+switch; see "this section"_Section_start.html#start_6 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.  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 restricts you to having
 exactly one processor per replica.
@@ -299,9 +300,9 @@ image.
 
 [Restrictions:]
 
-This command can only be used if LAMMPS was built with the "replica"
-package.  See the "Making LAMMPS"_Section_start.html#2_3 section for
-more info on packages.
+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.
 
 [Related commands:]
 
diff --git a/doc/neighbor.html b/doc/neighbor.html
index 5746c00ac3..0a69e18d7e 100644
--- a/doc/neighbor.html
+++ b/doc/neighbor.html
@@ -68,7 +68,7 @@ stored in the list.
 
    
 
    When a run is finished, counts of the number of neighbors stored in
 the pairwise list and the number of times neighbor lists were built
-are printed to the screen and log file.  See this
+are printed to the screen and log file.  See this
 section for details.
 
    
 
    Restrictions: none
diff --git a/doc/neighbor.txt b/doc/neighbor.txt
index 160ec935cb..199bd91430 100644
--- a/doc/neighbor.txt
+++ b/doc/neighbor.txt
@@ -66,7 +66,7 @@ stored in the list.
 When a run is finished, counts of the number of neighbors stored in
 the pairwise list and the number of times neighbor lists were built
 are printed to the screen and log file.  See "this
-section"_Section_start.html#2_7 for details.
+section"_Section_start.html#start_7 for details.
 
 [Restrictions:] none
 
diff --git a/doc/next.html b/doc/next.html
index ebd68fb1fb..14647c66fc 100644
--- a/doc/next.html
+++ b/doc/next.html
@@ -60,7 +60,7 @@ the next command is used with universe- or uloop-style variables,
 the next value is assigned to whichever processor partition executes
 the command first.  All processors in the partition are assigned the
 same value.  Running LAMMPS on multiple partitions of processors via
-the "-partition" command-line switch is described in this
+the "-partition" command-line switch is described in this
 section of the manual.  Universe- and
 uloop-style variables are incremented using the files
 "tmp.lammps.variable" and "tmp.lammps.variable.lock" which you will
diff --git a/doc/next.txt b/doc/next.txt
index 49156a414d..fd509e1b0b 100644
--- a/doc/next.txt
+++ b/doc/next.txt
@@ -58,7 +58,7 @@ the next value is assigned to whichever processor partition executes
 the command first.  All processors in the partition are assigned the
 same value.  Running LAMMPS on multiple partitions of processors via
 the "-partition" command-line switch is described in "this
-section"_Section_start.html#2_6 of the manual.  {Universe}- and
+section"_Section_start.html#start_6 of the manual.  {Universe}- and
 {uloop}-style variables are incremented using the files
 "tmp.lammps.variable" and "tmp.lammps.variable.lock" which you will
 see in your directory during such a LAMMPS run.
diff --git a/doc/package.html b/doc/package.html
new file mode 100644
index 0000000000..1d7254e15b
--- /dev/null
+++ b/doc/package.html
@@ -0,0 +1,269 @@
+
+
    LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
    
+
+
+
+
+
+
+
    
+
+
    package command 
+
    
+
    Syntax:
+
    
+
    package style args 
+
    
+
    • style = gpu or cuda or omp 
+
+
    • args = arguments specific to the style 
+
+
        gpu args = mode first last split keyword value ...
+    mode = force or force/neigh
+    first = ID of first GPU to be used on each node
+    last = ID of last GPU to be used on each node
+    split = fraction of particles assigned to the GPU
+    zero or more keyword/value pairs may be appended
+    keywords = threads_per_atom
+    threads_per_atom value = Nthreads
+      Nthreads = # of GPU threads used per atom
+  cuda args = keyword value ...
+    one or more keyword/value pairs may be appended
+    keywords = gpu/node or gpu/node/special or timing or test or override/bpa
+    gpu/node value = N
+      N = number of GPUs to be used per node
+    gpu/node/special values = N gpu1 .. gpuN
+      N = number of GPUs to be used per node
+      gpu1 .. gpuN = N IDs of the GPUs to use
+    timing values = none
+    test values = id
+      id = atom-ID of a test particle
+    override/bpa values = flag
+      flag = 0 for TpA algorithm, 1 for BpA algorithm 
+  omp args = Nthreads mode
+    Nthreads = # of OpenMP threads to associate with each MPI process
+    mode = force or force/neigh (optional) 
+
      
+
+
    
+
    Examples:
+
    
+
    package gpu force 0 0 1.0
+package gpu force 0 0 0.75
+package gpu force/neigh 0 0 1.0
+package gpu force/neigh 0 1 -1.0
+package cuda gpu/node/special 2 0 2
+package cuda test 3948
+package omp * force/neigh
+package omp 4 force 
+
    
+
    Description:
+
    
+
    This command invokes package-specific settings.  Currently the
+following packages use it: GPU, USER-CUDA, and USER-OMP.
+
    
+
    To use the accelerated GPU and USER-OMP styles, the use of the package
+command is required.  However, as described in the "Defaults" section
+below, if you use the "-sf gpu" or "-sf omp" command-line
+options to enable use of these styles,
+then default package settings are enabled.  In that case you only need
+to use the package command if you want to change the defaults.
+
    
+
    To use the accelerate USER-CUDA styles, the package command is not
+required as defaults are assigned internally.  You only need to use
+the package command if you want to change the defaults.
+
    
+
    See this section of the manual for more
+details about using these various packages for accelerating LAMMPS
+calculations.
+
    
+
    
+
+
    The gpu style invokes options associated with the use of the GPU
+package. 
+
    
+
    The mode setting specifies where neighbor list calculations will be
+performed.  If mode is force, neighbor list calculation is performed
+on the CPU. If mode is force/neigh, neighbor list calculation is
+performed on the GPU. GPU neighbor list calculation currently cannot
+be used with a triclinic box. GPU neighbor list calculation currently
+cannot be used with hybrid pair styles.  GPU
+neighbor lists are not compatible with styles that are not
+GPU-enabled.  When a non-GPU enabled style requires a neighbor list,
+it will also be built using CPU routines. In these cases, it will
+typically be more efficient to only use CPU neighbor list builds.
+
    
+
    The first and last settings specify the GPUs that will be used for
+simulation.  On each node, the GPU IDs in the inclusive range from
+first to last will be used.
+
    
+
    The split setting can be used for load balancing force calculation
+work between CPU and GPU cores in GPU-enabled pair styles. If 0 <
+split < 1.0, a fixed fraction of particles is offloaded to the GPU
+while force calculation for the other particles occurs simulataneously
+on the CPU. If split<0, the optimal fraction (based on CPU and GPU
+timings) is calculated every 25 timesteps. If split = 1.0, all force
+calculations for GPU accelerated pair styles are performed on the
+GPU. In this case, hybrid, bond,
+angle, dihedral,
+improper, and long-range
+calculations can be performed on the CPU while the GPU is performing
+force calculations for the GPU-enabled pair style.  If all CPU force
+computations complete before the GPU, LAMMPS will block until the GPU
+has finished before continuing the timestep.
+
    
+
    As an example, if you have two GPUs per node and 8 CPU cores per node,
+and would like to run on 4 nodes (32 cores) with dynamic balancing of
+force calculation across CPU and GPU cores, you could specify
+
    
+
    package gpu force/neigh 0 1 -1 
+
    
+
    In this case, all CPU cores and GPU devices on the nodes would be
+utilized.  Each GPU device would be shared by 4 CPU cores. The CPU
+cores would perform force calculations for some fraction of the
+particles at the same time the GPUs performed force calculation for
+the other particles.
+
    
+
    The threads_per_atom keyword allows control of the number of GPU
+threads used per-atom to perform the short range force calculation.
+By default, the value will be chosen based on the pair style, however,
+the value can be set with this keyword to fine-tune performance.  For
+large cutoffs or with a small number of particles per GPU, increasing
+the value can improve performance. The number of threads per atom must
+be a power of 2 and currently cannot be greater than 32.
+
    
+
    
+
+
    The cuda style invokes options associated with the use of the
+USER-CUDA package.  
+
    
+
    The gpu/node keyword specifies the number N of GPUs to be used on
+each node.  An MPI process with rank K will use the GPU (K mod N).
+This implies that processes should be assigned with successive ranks
+on each node, which is the default with most (or even all) MPI
+implementations. The default value for N is 2.
+
    
+
    The gpu/node/special keyword also specifies the number (N) of GPUs
+to be used on each node, but allows more control over their
+specification.  An MPI process with rank K will use the GPU gpuI
+with l = (K mod N) + 1. This implies that processes should be assigned
+with successive ranks on each node, which is the default with most (or
+even all) MPI implementations.  For example if you have three GPUs on
+a machine, one of which is used for the X-Server (the GPU with the ID
+1) while the others (with IDs 0 and 2) are used for computations you
+would specify:
+
    
+
    package cuda gpu/node/special 2 0 2 
+
    
+
    A main purpose of the gpu/node/special optoin is to allow two (or
+more) simulations to be run on one workstation.  In that case one
+would set the first simulation to use GPU 0 and the second to use GPU
+1. This is not necessary though, if the GPUs are in what is called
+compute exclusive mode.  Using that setting, every process will get
+its own GPU automatically.  This compute exclusive mode can be set
+as root using the nvidia-smi tool which is part of the CUDA
+installation.
+
    
+
    Note that if the gpu/node/special keyword is not used, the USER-CUDA
+package sorts existing GPUs on each node according to their number of
+multiprocessors.  This way, compute GPUs will be priorized over
+X-Server GPUs.
+
    
+
    Use of the timing keyword will output detailed timing information
+for various subroutines.
+
    
+
    The test keyword will output info for the the specified atom at
+several points during each time step.  This is mainly usefull for
+debugging purposes.  Note that the simulation will be severly slowed
+down if this option is used.
+
    
+
    The override/bpa keyword can be used to specify which mode is used
+for pair-force evaluation.  TpA = one thread per atom; BpA = one block
+per atom.  If this keyword is not used, a short test at the begin of
+each run will determine which method is more effective (the result of
+this test is part of the LAMMPS output).  Therefore it is usually not
+necessary to use this keyword.
+
    
+
    
+
+
    The omp style invokes options associated with the use of the
+USER-OMP package.
+
    
+
    The first argument allows to explicitly set the number of OpenMP
+threads to be allocated for each MPI process.  For example, if your
+system has nodes with dual quad-core processors, it has a total of 8
+cores per node.  You could run MPI on 2 cores on each node (e.g. using
+options for the mpirun command), and set the Nthreads setting to 4.
+This would effectively use all 8 cores on each node.  Since each MPI
+process would spawn 4 threads (one of which runs as part of the MPI
+process itself).
+
    
+
    For performance reasons, you should not set Nthreads to more threads
+than there are physical cores (per MPI task), but LAMMPS cannot check
+for this.
+
    
+
    An Nthreads value of '*' instructs LAMMPS to use whatever is the
+default for the given OpenMP environment. This is usually determined
+via the OMP_NUM_THREADS environment variable or the compiler
+runtime.  Please note that in most cases the default for OpenMP
+capable compilers is to use one thread for each available CPU core
+when OMP_NUM_THREADS is not set, which can lead to extremely bad
+performance.
+
    
+
    Which combination of threads and MPI tasks gives the best performance
+is difficult to predict and can depend on many components of your input.
+Not all features of LAMMPS support OpenMP and the parallel efficiency
+can be very different, too.
+
    
+
    The mode setting specifies where neighbor list calculations will be
+multi-threaded as well.  If mode is force, neighbor list calculation
+is performed in serial. If mode is force/neigh, a multi-threaded
+neighbor list build is used. Using the force/neigh setting is almost
+always faster and should produce idential neighbor lists at the
+expense of using some more memory (neighbor list pages are always
+allocated for all threads at the same time and each thread works on
+its own pages).
+
    
+
    
+
+
    Restrictions:
+
    
+
    This command cannot be used after the simulation box is defined by a
+read_data or create_box command.
+
    
+
    The cuda style of this command can only be invoked if LAMMPS was built
+with the USER-CUDA package.  See the Making
+LAMMPS section for more info.
+
    
+
    The gpu style of this command can only be invoked if LAMMPS was built
+with the GPU package.  See the Making
+LAMMPS section for more info.
+
    
+
    The omp style of this command can only be invoked if LAMMPS was built
+with the USER-OMP package.  See the Making
+LAMMPS section for more info.
+
    
+
    Related commands:
+
    
+
    suffix
+
    
+
    Default:
+
    
+
    If the "-sf gpu" command-line switch is
+used then it is as if the command "package gpu force/neigh 0 0 1" were
+invoked, to specify default settings for the GPU package.  If the
+command-line switch is not used, then no defaults are set, and you
+must specify the appropriate package command in your input script.
+
    
+
    The default settings for the USER CUDA package are "package cuda gpu
+2".  This is the case whether the "-sf cuda" command-line
+switch is used or not.
+
    
+
    If the "-sf omp" command-line switch is
+used then it is as if the command "package omp *" were invoked, to
+specify default settings for the USER-OMP package.  If the
+command-line switch is not used, then no defaults are set, and you
+must specify the appropriate package command in your input script.
+
    
+
diff --git a/doc/package.txt b/doc/package.txt
new file mode 100644
index 0000000000..e561100a30
--- /dev/null
+++ b/doc/package.txt
@@ -0,0 +1,262 @@
+"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
+
+package command :h3
+
+[Syntax:]
+
+package style args :pre
+
+style = {gpu} or {cuda} or {omp} :ulb,l
+args = arguments specific to the style :l
+  {gpu} args = mode first last split keyword value ...
+    mode = force or force/neigh
+    first = ID of first GPU to be used on each node
+    last = ID of last GPU to be used on each node
+    split = fraction of particles assigned to the GPU
+    zero or more keyword/value pairs may be appended
+    keywords = {threads_per_atom}
+    {threads_per_atom} value = Nthreads
+      Nthreads = # of GPU threads used per atom
+  {cuda} args = keyword value ...
+    one or more keyword/value pairs may be appended
+    keywords = {gpu/node} or {gpu/node/special} or {timing} or {test} or {override/bpa}
+    {gpu/node} value = N
+      N = number of GPUs to be used per node
+    {gpu/node/special} values = N gpu1 .. gpuN
+      N = number of GPUs to be used per node
+      gpu1 .. gpuN = N IDs of the GPUs to use
+    {timing} values = none
+    {test} values = id
+      id = atom-ID of a test particle
+    {override/bpa} values = flag
+      flag = 0 for TpA algorithm, 1 for BpA algorithm 
+  {omp} args = Nthreads mode
+    Nthreads = # of OpenMP threads to associate with each MPI process
+    mode = force or force/neigh (optional) :pre
+:ule
+
+[Examples:]
+
+package gpu force 0 0 1.0
+package gpu force 0 0 0.75
+package gpu force/neigh 0 0 1.0
+package gpu force/neigh 0 1 -1.0
+package cuda gpu/node/special 2 0 2
+package cuda test 3948
+package omp * force/neigh
+package omp 4 force :pre
+
+[Description:]
+
+This command invokes package-specific settings.  Currently the
+following packages use it: GPU, USER-CUDA, and USER-OMP.
+
+To use the accelerated GPU and USER-OMP styles, the use of the package
+command is required.  However, as described in the "Defaults" section
+below, if you use the "-sf gpu" or "-sf omp" "command-line
+options"_Section_start.html#start_6 to enable use of these styles,
+then default package settings are enabled.  In that case you only need
+to use the package command if you want to change the defaults.
+
+To use the accelerate USER-CUDA styles, the package command is not
+required as defaults are assigned internally.  You only need to use
+the package command if you want to change the defaults.
+
+See "this section"_Section_accelerate.html of the manual for more
+details about using these various packages for accelerating LAMMPS
+calculations.
+
+:line
+
+The {gpu} style invokes options associated with the use of the GPU
+package. 
+
+The {mode} setting specifies where neighbor list calculations will be
+performed.  If {mode} is force, neighbor list calculation is performed
+on the CPU. If {mode} is force/neigh, neighbor list calculation is
+performed on the GPU. GPU neighbor list calculation currently cannot
+be used with a triclinic box. GPU neighbor list calculation currently
+cannot be used with "hybrid"_pair_hybrid.html pair styles.  GPU
+neighbor lists are not compatible with styles that are not
+GPU-enabled.  When a non-GPU enabled style requires a neighbor list,
+it will also be built using CPU routines. In these cases, it will
+typically be more efficient to only use CPU neighbor list builds.
+
+The {first} and {last} settings specify the GPUs that will be used for
+simulation.  On each node, the GPU IDs in the inclusive range from
+{first} to {last} will be used.
+
+The {split} setting can be used for load balancing force calculation
+work between CPU and GPU cores in GPU-enabled pair styles. If 0 <
+{split} < 1.0, a fixed fraction of particles is offloaded to the GPU
+while force calculation for the other particles occurs simulataneously
+on the CPU. If {split}<0, the optimal fraction (based on CPU and GPU
+timings) is calculated every 25 timesteps. If {split} = 1.0, all force
+calculations for GPU accelerated pair styles are performed on the
+GPU. In this case, "hybrid"_pair_hybrid.html, "bond"_bond_style.html,
+"angle"_angle_style.html, "dihedral"_dihedral_style.html,
+"improper"_improper_style.html, and "long-range"_kspace_style.html
+calculations can be performed on the CPU while the GPU is performing
+force calculations for the GPU-enabled pair style.  If all CPU force
+computations complete before the GPU, LAMMPS will block until the GPU
+has finished before continuing the timestep.
+
+As an example, if you have two GPUs per node and 8 CPU cores per node,
+and would like to run on 4 nodes (32 cores) with dynamic balancing of
+force calculation across CPU and GPU cores, you could specify
+
+package gpu force/neigh 0 1 -1 :pre
+
+In this case, all CPU cores and GPU devices on the nodes would be
+utilized.  Each GPU device would be shared by 4 CPU cores. The CPU
+cores would perform force calculations for some fraction of the
+particles at the same time the GPUs performed force calculation for
+the other particles.
+
+The {threads_per_atom} keyword allows control of the number of GPU
+threads used per-atom to perform the short range force calculation.
+By default, the value will be chosen based on the pair style, however,
+the value can be set with this keyword to fine-tune performance.  For
+large cutoffs or with a small number of particles per GPU, increasing
+the value can improve performance. The number of threads per atom must
+be a power of 2 and currently cannot be greater than 32.
+
+:line
+
+The {cuda} style invokes options associated with the use of the
+USER-CUDA package.  
+
+The {gpu/node} keyword specifies the number {N} of GPUs to be used on
+each node.  An MPI process with rank {K} will use the GPU (K mod N).
+This implies that processes should be assigned with successive ranks
+on each node, which is the default with most (or even all) MPI
+implementations. The default value for {N} is 2.
+
+The {gpu/node/special} keyword also specifies the number (N) of GPUs
+to be used on each node, but allows more control over their
+specification.  An MPI process with rank {K} will use the GPU {gpuI}
+with l = (K mod N) + 1. This implies that processes should be assigned
+with successive ranks on each node, which is the default with most (or
+even all) MPI implementations.  For example if you have three GPUs on
+a machine, one of which is used for the X-Server (the GPU with the ID
+1) while the others (with IDs 0 and 2) are used for computations you
+would specify:
+
+package cuda gpu/node/special 2 0 2 :pre
+
+A main purpose of the {gpu/node/special} optoin is to allow two (or
+more) simulations to be run on one workstation.  In that case one
+would set the first simulation to use GPU 0 and the second to use GPU
+1. This is not necessary though, if the GPUs are in what is called
+{compute exclusive} mode.  Using that setting, every process will get
+its own GPU automatically.  This {compute exclusive} mode can be set
+as root using the {nvidia-smi} tool which is part of the CUDA
+installation.
+
+Note that if the {gpu/node/special} keyword is not used, the USER-CUDA
+package sorts existing GPUs on each node according to their number of
+multiprocessors.  This way, compute GPUs will be priorized over
+X-Server GPUs.
+ 
+Use of the {timing} keyword will output detailed timing information
+for various subroutines.
+
+The {test} keyword will output info for the the specified atom at
+several points during each time step.  This is mainly usefull for
+debugging purposes.  Note that the simulation will be severly slowed
+down if this option is used.
+
+The {override/bpa} keyword can be used to specify which mode is used
+for pair-force evaluation.  TpA = one thread per atom; BpA = one block
+per atom.  If this keyword is not used, a short test at the begin of
+each run will determine which method is more effective (the result of
+this test is part of the LAMMPS output).  Therefore it is usually not
+necessary to use this keyword.
+
+:line
+
+The {omp} style invokes options associated with the use of the
+USER-OMP package.
+
+The first argument allows to explicitly set the number of OpenMP
+threads to be allocated for each MPI process.  For example, if your
+system has nodes with dual quad-core processors, it has a total of 8
+cores per node.  You could run MPI on 2 cores on each node (e.g. using
+options for the mpirun command), and set the {Nthreads} setting to 4.
+This would effectively use all 8 cores on each node.  Since each MPI
+process would spawn 4 threads (one of which runs as part of the MPI
+process itself).
+
+For performance reasons, you should not set {Nthreads} to more threads
+than there are physical cores (per MPI task), but LAMMPS cannot check
+for this.
+
+An {Nthreads} value of '*' instructs LAMMPS to use whatever is the
+default for the given OpenMP environment. This is usually determined
+via the {OMP_NUM_THREADS} environment variable or the compiler
+runtime.  Please note that in most cases the default for OpenMP
+capable compilers is to use one thread for each available CPU core
+when {OMP_NUM_THREADS} is not set, which can lead to extremely bad
+performance.
+
+Which combination of threads and MPI tasks gives the best performance
+is difficult to predict and can depend on many components of your input.
+Not all features of LAMMPS support OpenMP and the parallel efficiency
+can be very different, too.
+
+The {mode} setting specifies where neighbor list calculations will be
+multi-threaded as well.  If {mode} is force, neighbor list calculation
+is performed in serial. If {mode} is force/neigh, a multi-threaded
+neighbor list build is used. Using the force/neigh setting is almost
+always faster and should produce idential neighbor lists at the
+expense of using some more memory (neighbor list pages are always
+allocated for all threads at the same time and each thread works on
+its own pages).
+
+:line
+
+[Restrictions:]
+
+This command cannot be used after the simulation box is defined by a
+"read_data"_read_data.html or "create_box"_create_box.html command.
+
+The cuda style of this command can only be invoked if LAMMPS was built
+with the USER-CUDA package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+The gpu style of this command can only be invoked if LAMMPS was built
+with the GPU package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+The omp style of this command can only be invoked if LAMMPS was built
+with the USER-OMP package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+[Related commands:]
+
+"suffix"_suffix.html
+
+[Default:]
+
+If the "-sf gpu" "command-line switch"_Section_start.html#start_6 is
+used then it is as if the command "package gpu force/neigh 0 0 1" were
+invoked, to specify default settings for the GPU package.  If the
+command-line switch is not used, then no defaults are set, and you
+must specify the appropriate package command in your input script.
+
+The default settings for the USER CUDA package are "package cuda gpu
+2".  This is the case whether the "-sf cuda" "command-line
+switch"_Section_start.html#start_6 is used or not.
+
+If the "-sf omp" "command-line switch"_Section_start.html#start_6 is
+used then it is as if the command "package omp *" were invoked, to
+specify default settings for the USER-OMP package.  If the
+command-line switch is not used, then no defaults are set, and you
+must specify the appropriate package command in your input script.
+
diff --git a/doc/pair_adp.html b/doc/pair_adp.html
new file mode 100644
index 0000000000..34bf494229
--- /dev/null
+++ b/doc/pair_adp.html
@@ -0,0 +1,187 @@
+
+
    LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
    
+
+
+
+
+
+
+
    
+
+
    pair_style adp command 
+
    
+
    pair_style adp/omp command 
+
    
+
    Syntax:
+
    
+
    pair_style adp 
+
    
+
    Examples:
+
    
+
    pair_style adp
+pair_coeff * * Ta.adp Ta
+pair_coeff * * ../potentials/AlCu.adp Al Al Cu 
+
    
+
    Description:
+
    
+
    Style adp computes pairwise interactions for metals and metal alloys
+using the angular dependent potential (ADP) of (Mishin),
+which is a generalization of the embedded atom method (EAM)
+potential.  The LAMMPS implementation is discussed in
+(Singh).  The total energy Ei of an atom I is given by
+
    
+
    
+
    
+
    where F is the embedding energy which is a function of the atomic
+electron density rho, phi is a pair potential interaction, alpha and
+beta are the element types of atoms I and J, and s and t = 1,2,3 and
+refer to the cartesian coordinates.  The mu and lambda terms represent
+the dipole and quadruple distortions of the local atomic environment
+which extend the original EAM framework by introducing angular forces.
+
    
+
    Note that unlike for other potentials, cutoffs for ADP potentials are
+not set in the pair_style or pair_coeff command; they are specified in
+the ADP potential files themselves.  Likewise, the ADP potential files
+list atomic masses; thus you do not need to use the mass
+command to specify them.
+
    
+
    The NIST WWW site distributes and documents ADP potentials:
+
    
+
    http://www.ctcms.nist.gov/potentials 
+
    
+
    Note that these must be converted into the extended DYNAMO setfl
+format discussed below.
+
    
+
    The NIST site is maintained by Chandler Becker (cbecker at nist.gov)
+who is good resource for info on interatomic potentials and file
+formats.
+
    
+
    
+
+
    Only a single pair_coeff command is used with the adp style which
+specifies an extended DYNAMO setfl file, which contains information
+for M elements.  These are mapped to LAMMPS atom types by specifying N
+additional arguments after the filename in the pair_coeff command,
+where N is the number of LAMMPS atom types:
+
    
+
    • filename
+
    • N element names = mapping of extended setfl elements to atom types 
+
    
+
    As an example, the potentials/AlCu.adp file, included in the
+potentials directory of the LAMMPS distrbution, is an extended setfl
+file which has tabulated ADP values for w elements and their alloy
+interactions: Cu and Al.  If your LAMMPS simulation has 4 atoms types
+and you want the 1st 3 to be Al, and the 4th to be Cu, you would use
+the following pair_coeff command:
+
    
+
    pair_coeff * * AlCu.adp Al Al Al Cu 
+
    
+
    The 1st 2 arguments must be * * so as to span all LAMMPS atom types.
+The first three Al arguments map LAMMPS atom types 1,2,3 to the Al
+element in the extended setfl file.  The final Cu argument maps
+LAMMPS atom type 4 to the Al element in the extended setfl file.
+Note that there is no requirement that your simulation use all the
+elements specified by the extended setfl file.
+
    
+
    If a mapping value is specified as NULL, the mapping is not performed.
+This can be used when an adp potential is used as part of the
+hybrid pair style.  The NULL values are placeholders for atom types
+that will be used with other potentials.
+
    
+
    Adp files in the potentials directory of the LAMMPS distribution
+have an ".adp" suffix.  A DYNAMO setfl file extended for ADP is
+formatted as follows.  Basically it is the standard setfl format
+with additional tabulated functions u and w added to the file after
+the tabulated pair potentials.  See the pair_eam
+command for further details on the setfl format.
+
    
+
    • lines 1,2,3 = comments (ignored)
+
    • line 4: Nelements Element1 Element2 ... ElementN
+
    • line 5: Nrho, drho, Nr, dr, cutoff 
+
    
+
    Following the 5 header lines are Nelements sections, one for each
+element, each with the following format:
+
    
+
    • line 1 = atomic number, mass, lattice constant, lattice type (e.g. FCC)
+
    • embedding function F(rho) (Nrho values)
+
    • density function rho(r) (Nr values) 
+
    
+
    Following the Nelements sections, Nr values for each pair potential
+phi(r) array are listed for all i,j element pairs in the same format
+as other arrays.  Since these interactions are symmetric (i,j = j,i)
+only phi arrays with i >= j are listed, in the following order: i,j =
+(1,1), (2,1), (2,2), (3,1), (3,2), (3,3), (4,1), ..., (Nelements,
+Nelements).
+
    
+
    After the phi(r) arrays, each of the u(r) arrays are listed in the
+same order with the same assumptions of symmetry.  Directly following
+the u(r), the w(r) arrays are listed.
+
    
+
    
+
+
    Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
+
    Mixing, shift, table, tail correction, restart, rRESPA info:
+
    
+
    For atom type pairs I,J and I != J, where types I and J correspond to
+two different element types, no special mixing rules are needed, since
+the ADP potential files specify alloy interactions explicitly.
+
    
+
    This pair style does not support the pair_modify
+shift, table, and tail options.
+
    
+
    This pair style does not write its information to binary restart
+files, since it is stored in tabulated potential files.
+Thus, you need to re-specify the pair_style and pair_coeff commands in
+an input script that reads a restart file.
+
    
+
    This pair style can only be used via the pair keyword of the
+run_style respa command.  It does not support the
+inner, middle, outer keywords.
+
    
+
    
+
+
    Restrictions:
+
    
+
    This pair style is part of the MANYBODY package.  It is only enabled
+if LAMMPS was built with that package (which it is by default).
+
    
+
    Related commands:
+
    
+
    pair_coeff, pair_eam
+
    
+
    Default: none
+
    
+
    
+
+
+
+
    (Mishin) Mishin, Mehl, and Papaconstantopoulos, Acta Mater, 53, 4029
+(2005).
+
    
+
+
+
    (Singh) Singh and Warner, Acta Mater, 58, 5797-5805 (2010),
+
    
+
diff --git a/doc/pair_adp.txt b/doc/pair_adp.txt
new file mode 100644
index 0000000000..4eef1d675e
--- /dev/null
+++ b/doc/pair_adp.txt
@@ -0,0 +1,179 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+pair_style adp command :h3
+pair_style adp/omp command :h3
+
+[Syntax:]
+
+pair_style adp :pre
+
+[Examples:]
+
+pair_style adp
+pair_coeff * * Ta.adp Ta
+pair_coeff * * ../potentials/AlCu.adp Al Al Cu :pre
+
+[Description:]
+
+Style {adp} computes pairwise interactions for metals and metal alloys
+using the angular dependent potential (ADP) of "(Mishin)"_#Mishin,
+which is a generalization of the "embedded atom method (EAM)
+potential"_pair_eam.html.  The LAMMPS implementation is discussed in
+"(Singh)"_#Singh.  The total energy Ei of an atom I is given by
+
+:c,image(Eqs/pair_adp.jpg)
+
+where F is the embedding energy which is a function of the atomic
+electron density rho, phi is a pair potential interaction, alpha and
+beta are the element types of atoms I and J, and s and t = 1,2,3 and
+refer to the cartesian coordinates.  The mu and lambda terms represent
+the dipole and quadruple distortions of the local atomic environment
+which extend the original EAM framework by introducing angular forces.
+
+Note that unlike for other potentials, cutoffs for ADP potentials are
+not set in the pair_style or pair_coeff command; they are specified in
+the ADP potential files themselves.  Likewise, the ADP potential files
+list atomic masses; thus you do not need to use the "mass"_mass.html
+command to specify them.
+
+The NIST WWW site distributes and documents ADP potentials:
+
+http://www.ctcms.nist.gov/potentials :pre
+
+Note that these must be converted into the extended DYNAMO {setfl}
+format discussed below.
+
+The NIST site is maintained by Chandler Becker (cbecker at nist.gov)
+who is good resource for info on interatomic potentials and file
+formats.
+
+:line
+
+Only a single pair_coeff command is used with the {adp} style which
+specifies an extended DYNAMO {setfl} file, which contains information
+for M elements.  These are mapped to LAMMPS atom types by specifying N
+additional arguments after the filename in the pair_coeff command,
+where N is the number of LAMMPS atom types:
+
+filename
+N element names = mapping of extended {setfl} elements to atom types :ul
+
+As an example, the potentials/AlCu.adp file, included in the
+potentials directory of the LAMMPS distrbution, is an extended {setfl}
+file which has tabulated ADP values for w elements and their alloy
+interactions: Cu and Al.  If your LAMMPS simulation has 4 atoms types
+and you want the 1st 3 to be Al, and the 4th to be Cu, you would use
+the following pair_coeff command:
+
+pair_coeff * * AlCu.adp Al Al Al Cu :pre
+
+The 1st 2 arguments must be * * so as to span all LAMMPS atom types.
+The first three Al arguments map LAMMPS atom types 1,2,3 to the Al
+element in the extended {setfl} file.  The final Cu argument maps
+LAMMPS atom type 4 to the Al element in the extended {setfl} file.
+Note that there is no requirement that your simulation use all the
+elements specified by the extended {setfl} file.
+
+If a mapping value is specified as NULL, the mapping is not performed.
+This can be used when an {adp} potential is used as part of the
+{hybrid} pair style.  The NULL values are placeholders for atom types
+that will be used with other potentials.
+
+{Adp} files in the {potentials} directory of the LAMMPS distribution
+have an ".adp" suffix.  A DYNAMO {setfl} file extended for ADP is
+formatted as follows.  Basically it is the standard {setfl} format
+with additional tabulated functions u and w added to the file after
+the tabulated pair potentials.  See the "pair_eam"_pair_eam.html
+command for further details on the {setfl} format.
+
+lines 1,2,3 = comments (ignored)
+line 4: Nelements Element1 Element2 ... ElementN
+line 5: Nrho, drho, Nr, dr, cutoff :ul
+
+Following the 5 header lines are Nelements sections, one for each
+element, each with the following format:
+
+line 1 = atomic number, mass, lattice constant, lattice type (e.g. FCC)
+embedding function F(rho) (Nrho values)
+density function rho(r) (Nr values) :ul
+
+Following the Nelements sections, Nr values for each pair potential
+phi(r) array are listed for all i,j element pairs in the same format
+as other arrays.  Since these interactions are symmetric (i,j = j,i)
+only phi arrays with i >= j are listed, in the following order: i,j =
+(1,1), (2,1), (2,2), (3,1), (3,2), (3,3), (4,1), ..., (Nelements,
+Nelements).
+
+After the phi(r) arrays, each of the u(r) arrays are listed in the
+same order with the same assumptions of symmetry.  Directly following
+the u(r), the w(r) arrays are listed.
+
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
+[Mixing, shift, table, tail correction, restart, rRESPA info]:
+
+For atom type pairs I,J and I != J, where types I and J correspond to
+two different element types, no special mixing rules are needed, since
+the ADP potential files specify alloy interactions explicitly.
+
+This pair style does not support the "pair_modify"_pair_modify.html
+shift, table, and tail options.
+
+This pair style does not write its information to "binary restart
+files"_restart.html, since it is stored in tabulated potential files.
+Thus, you need to re-specify the pair_style and pair_coeff commands in
+an input script that reads a restart file.
+
+This pair style can only be used via the {pair} keyword of the
+"run_style respa"_run_style.html command.  It does not support the
+{inner}, {middle}, {outer} keywords.
+
+:line
+
+[Restrictions:]
+
+This pair style is part of the MANYBODY package.  It is only enabled
+if LAMMPS was built with that package (which it is by default).
+
+[Related commands:]
+
+"pair_coeff"_pair_coeff.html, "pair_eam"_pair_eam.html
+
+[Default:] none
+
+:line
+
+:link(Mishin)
+[(Mishin)] Mishin, Mehl, and Papaconstantopoulos, Acta Mater, 53, 4029
+(2005).
+
+:link(Singh)
+[(Singh)] Singh and Warner, Acta Mater, 58, 5797-5805 (2010),
diff --git a/doc/pair_airebo.html b/doc/pair_airebo.html
index d89d11ea8b..282e1affbf 100644
--- a/doc/pair_airebo.html
+++ b/doc/pair_airebo.html
@@ -11,13 +11,20 @@
 
 
    pair_style airebo command 
 
    
+
    pair_style airebo/omp command 
+
    
+
    pair_style rebo command 
+
    
+
    pair_style rebo/omp command 
+
    
 
    Syntax:
 
    
-
    pair_style airebo cutoff LJ_flag TORSION_flag 
+
    pair_style style cutoff LJ_flag TORSION_flag 
 
    
-
    • cutoff = LJ cutoff (sigma scale factor)
-
    • LJ_flag = 0/1 to turn off/on the LJ term in AIREBO (optional)
-
    • TORSION_flag = 0/1 to turn off/on the torsion term in AIREBO (optional) 
+
      • style = airebo or rebo
+
      • cutoff = LJ cutoff (sigma scale factor) (AIREBO only)
+
      • LJ_flag = 0/1 to turn off/on the LJ term (AIREBO only, optional)
+
      • TORSION_flag = 0/1 to turn off/on the torsion term (AIREBO only, optional) 
 
      
 
      Examples:
 
      
@@ -25,19 +32,33 @@
 pair_style airebo 2.5 1 0
 pair_coeff * * ../potentials/CH.airebo H C 
 
    
+
    pair_style rebo
+pair_coeff * * ../potentials/CH.airebo H C 
+
    
 
    Description:
 
    
 
    The airebo pair style computes the Adaptive Intermolecular Reactive
 Empirical Bond Order (AIREBO) Potential of (Stuart) for a
-system of carbon and/or hydrogen atoms.  The potential
-consists of three terms:
+system of carbon and/or hydrogen atoms.  Note that this is the initial
+formulation of AIREBO from 2000, not the later formulation.  The
+rebo pair style computes the Reactive Empirical Bond Order (REBO)
+Potential of (Brenner).  Note that this is the so-called
+2nd generation REBO from 2002, not the original REBO from 1990.  As
+discussed below, 2nd generation REBO is closely related to the intial
+AIREBO; it is just a subset of the potential energy terms.
+
    
+
    The AIREBO potential consists of three terms:
 
    
 
    
 
    
-
    By default, all three terms are included.  If the two optional flag
-arguments to the pair_style command are included, the LJ and torsional
-terms can be turned off.  Note that both or neither of the flags must
-be included.
+
    By default, all three terms are included.  For the airebo style, if
+the two optional flag arguments to the pair_style command are
+included, the LJ and torsional terms can be turned off.  Note that
+both or neither of the flags must be included.  If both of the LJ an
+torsional terms are turned off, it becomes the 2nd-generation REBO
+potential, with a small caveat on the spline fitting procedure
+mentioned below.  This can be specified directly as pair_style rebo
+with no additional arguments.
 
    
 
    The detailed formulas for this potential are given in
 (Stuart); here we provide only a brief description.
@@ -71,11 +92,12 @@ would be 10.2 Angstroms.
 
    The E_TORSION term is an explicit 4-body potential that describes
 various dihedral angle preferences in hydrocarbon configurations.
 
    
-
    Only a single pair_coeff command is used with the airebo style which
-specifies an AIREBO potential file with parameters for C and H.  These
-are mapped to LAMMPS atom types by specifying N additional arguments
-after the filename in the pair_coeff command, where N is the number of
-LAMMPS atom types:
+
    Only a single pair_coeff command is used with the airebo or rebo
+style which specifies an AIREBO potential file with parameters for C
+and H.  Note that the rebo style in LAMMPS uses the same
+AIREBO-formatted potential file.  These are mapped to LAMMPS atom
+types by specifying N additional arguments after the filename in the
+pair_coeff command, where N is the number of LAMMPS atom types:
 
    
 
    • filename
 
    • N element names = mapping of AIREBO elements to atom types 
@@ -98,42 +120,61 @@ other potentials.
 
      The parameters/coefficients for the AIREBO potentials are listed in
 the CH.airebo file to agree with the original (Stuart)
 paper.  Thus the parameters are specific to this potential and the way
-it was fit, so modifying the file should be done cautiously.  Also
-note that the E_LJ and E_TORSION terms in AIREBO are intended to be
-used with the E_REBO term and not as stand-alone potentials.  Thus we
-don't suggest you use pair_style airebo with the E_REBO term turned
-off.
+it was fit, so modifying the file should be done cautiously.
+
      
+
      
+
+
      Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
      
+
      These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
      
+
      You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
      
+
      See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
 
      
 
      
 
 
      Mixing, shift, table, tail correction, restart, rRESPA info:
 
      
-
      This pair style does not support the pair_modify
+
      These pair styles do not support the pair_modify
 mix, shift, table, and tail options.
 
      
-
      This pair style does not write its information to binary restart
+
      These pair styles do not write their information to binary restart
 files, since it is stored in potential files.  Thus, you
 need to re-specify the pair_style and pair_coeff commands in an input
 script that reads a restart file.
 
      
-
      This pair style can only be used via the pair keyword of the
-run_style respa command.  It does not support the
+
      These pair styles can only be used via the pair keyword of the
+run_style respa command.  They do not support the
 inner, middle, outer keywords.
 
      
 
      Restrictions:
 
      
-
      This pair style is part of the "manybody" package.  It is only enabled
-if LAMMPS was built with that package (which it is by default).  See
-the Making LAMMPS section for more info.
+
      These pair styles are part of the MANYBODY package.  They are only
+enabled if LAMMPS was built with that package (which it is by
+default).  See the Making LAMMPS section
+for more info.
 
      
-
      This pair potential requires the newton setting to be
+
      These pair potentials require the newton setting to be
 "on" for pair interactions.
 
      
 
      The CH.airebo potential file provided with LAMMPS (see the potentials
 directory) is parameterized for metal units.  You can use
-the AIREBO potential with any LAMMPS units, but you would need to
-create your own AIREBO potential file with coefficients listed in the
-appropriate units if your simulation doesn't use "metal" units.
+the AIREBO or REBO potential with any LAMMPS units, but you would need
+to create your own AIREBO potential file with coefficients listed in
+the appropriate units if your simulation doesn't use "metal" units.
 
      
 
      Related commands:
 
      
diff --git a/doc/pair_airebo.txt b/doc/pair_airebo.txt
index e4e42b8603..71c7ea071a 100644
--- a/doc/pair_airebo.txt
+++ b/doc/pair_airebo.txt
@@ -7,14 +7,18 @@
 :line
 
 pair_style airebo command :h3
+pair_style airebo/omp command :h3
+pair_style rebo command :h3
+pair_style rebo/omp command :h3
 
 [Syntax:]
 
-pair_style airebo cutoff LJ_flag TORSION_flag :pre
+pair_style style cutoff LJ_flag TORSION_flag :pre
 
-cutoff = LJ cutoff (sigma scale factor)
-LJ_flag = 0/1 to turn off/on the LJ term in AIREBO (optional)
-TORSION_flag = 0/1 to turn off/on the torsion term in AIREBO (optional) :ul
+style = {airebo} or {rebo}
+cutoff = LJ cutoff (sigma scale factor) (AIREBO only)
+LJ_flag = 0/1 to turn off/on the LJ term (AIREBO only, optional)
+TORSION_flag = 0/1 to turn off/on the torsion term (AIREBO only, optional) :ul
 
 [Examples:]
 
@@ -22,19 +26,33 @@ pair_style airebo 3.0
 pair_style airebo 2.5 1 0
 pair_coeff * * ../potentials/CH.airebo H C :pre
 
+pair_style rebo
+pair_coeff * * ../potentials/CH.airebo H C :pre
+
 [Description:]
 
 The {airebo} pair style computes the Adaptive Intermolecular Reactive
 Empirical Bond Order (AIREBO) Potential of "(Stuart)"_#Stuart for a
-system of carbon and/or hydrogen atoms.  The potential
-consists of three terms:
+system of carbon and/or hydrogen atoms.  Note that this is the initial
+formulation of AIREBO from 2000, not the later formulation.  The
+{rebo} pair style computes the Reactive Empirical Bond Order (REBO)
+Potential of "(Brenner)"_#Brenner.  Note that this is the so-called
+2nd generation REBO from 2002, not the original REBO from 1990.  As
+discussed below, 2nd generation REBO is closely related to the intial
+AIREBO; it is just a subset of the potential energy terms.
+
+The AIREBO potential consists of three terms:
 
 :c,image(Eqs/pair_airebo.jpg)
 
-By default, all three terms are included.  If the two optional flag
-arguments to the pair_style command are included, the LJ and torsional
-terms can be turned off.  Note that both or neither of the flags must
-be included.
+By default, all three terms are included.  For the {airebo} style, if
+the two optional flag arguments to the pair_style command are
+included, the LJ and torsional terms can be turned off.  Note that
+both or neither of the flags must be included.  If both of the LJ an
+torsional terms are turned off, it becomes the 2nd-generation REBO
+potential, with a small caveat on the spline fitting procedure
+mentioned below.  This can be specified directly as pair_style rebo
+with no additional arguments.
 
 The detailed formulas for this potential are given in
 "(Stuart)"_#Stuart; here we provide only a brief description.
@@ -68,11 +86,12 @@ would be 10.2 Angstroms.
 The E_TORSION term is an explicit 4-body potential that describes
 various dihedral angle preferences in hydrocarbon configurations.
 
-Only a single pair_coeff command is used with the {airebo} style which
-specifies an AIREBO potential file with parameters for C and H.  These
-are mapped to LAMMPS atom types by specifying N additional arguments
-after the filename in the pair_coeff command, where N is the number of
-LAMMPS atom types:
+Only a single pair_coeff command is used with the {airebo} or {rebo}
+style which specifies an AIREBO potential file with parameters for C
+and H.  Note that the {rebo} style in LAMMPS uses the same
+AIREBO-formatted potential file.  These are mapped to LAMMPS atom
+types by specifying N additional arguments after the filename in the
+pair_coeff command, where N is the number of LAMMPS atom types:
 
 filename
 N element names = mapping of AIREBO elements to atom types :ul
@@ -95,42 +114,61 @@ other potentials.
 The parameters/coefficients for the AIREBO potentials are listed in
 the CH.airebo file to agree with the original "(Stuart)"_#Stuart
 paper.  Thus the parameters are specific to this potential and the way
-it was fit, so modifying the file should be done cautiously.  Also
-note that the E_LJ and E_TORSION terms in AIREBO are intended to be
-used with the E_REBO term and not as stand-alone potentials.  Thus we
-don't suggest you use pair_style airebo with the E_REBO term turned
-off.
+it was fit, so modifying the file should be done cautiously.
+
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
 
 :line
 
 [Mixing, shift, table, tail correction, restart, rRESPA info]:
 
-This pair style does not support the "pair_modify"_pair_modify.html
+These pair styles do not support the "pair_modify"_pair_modify.html
 mix, shift, table, and tail options.
 
-This pair style does not write its information to "binary restart
+These pair styles do not write their information to "binary restart
 files"_restart.html, since it is stored in potential files.  Thus, you
 need to re-specify the pair_style and pair_coeff commands in an input
 script that reads a restart file.
 
-This pair style can only be used via the {pair} keyword of the
-"run_style respa"_run_style.html command.  It does not support the
+These pair styles can only be used via the {pair} keyword of the
+"run_style respa"_run_style.html command.  They do not support the
 {inner}, {middle}, {outer} keywords.
 
 [Restrictions:]
 
-This pair style is part of the "manybody" package.  It is only enabled
-if LAMMPS was built with that package (which it is by default).  See
-the "Making LAMMPS"_Section_start.html#2_3 section for more info.
+These pair styles are part of the MANYBODY package.  They are only
+enabled if LAMMPS was built with that package (which it is by
+default).  See the "Making LAMMPS"_Section_start.html#start_3 section
+for more info.
 
-This pair potential requires the "newton"_newton.html setting to be
+These pair potentials require the "newton"_newton.html setting to be
 "on" for pair interactions.
 
 The CH.airebo potential file provided with LAMMPS (see the potentials
 directory) is parameterized for metal "units"_units.html.  You can use
-the AIREBO potential with any LAMMPS units, but you would need to
-create your own AIREBO potential file with coefficients listed in the
-appropriate units if your simulation doesn't use "metal" units.
+the AIREBO or REBO potential with any LAMMPS units, but you would need
+to create your own AIREBO potential file with coefficients listed in
+the appropriate units if your simulation doesn't use "metal" units.
 
 [Related commands:]
 
diff --git a/doc/pair_awpmd.html b/doc/pair_awpmd.html
new file mode 100644
index 0000000000..7ab6be8670
--- /dev/null
+++ b/doc/pair_awpmd.html
@@ -0,0 +1,130 @@
+
+
      LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
      
+
+
+
+
+
+
+
      
+
+
      pair_style awpmd/cut command 
+
      
+
      Syntax:
+
      
+
      pair_style awpmd/cut Rc keyword value ... 
+
      
+
      • Rc = global cutoff, -1 means cutoff of half the shortest box length 
+
+
      • zero or more keyword/value pairs may be appended 
+
+
      • keyword = hartree or dproduct or uhf or free or pbc or fix or harm or ermscale or flex_press 
+
+
          hartree value = none
+  dproduct value = none
+  uhf value = none
+  free value = none
+  pbc value = Plen
+    Plen = periodic width of electron = -1 or positive value (distance units)
+  fix value = Flen
+    Flen = fixed width of electron = -1 or positive value (distance units)
+  harm value = width
+    width = harmonic width constraint
+  ermscale value = factor
+    factor = scaling between electron mass and width variable mass
+  flex_press value = none 
+
        
+
+
      
+
      Examples:
+
      
+
      pair_style awpmd/cut -1
+pair_style awpmd/cut 40.0 uhf free
+pair_coeff * *
+pair_coeff 2 2 20.0 
+
      
+
      Description:
+
      
+
      This pair style contains an implementation of the Antisymmetrized Wave
+Packet Molecular Dynamics (AWPMD) method.  Need citation here.  Need
+basic formulas here.  Could be links to other documents.
+
      
+
      Rc is the cutoff.
+
      
+
      The pair_style command allows for several optional keywords
+to be specified.
+
      
+
      The hartree, dproduct, and uhf keywords specify the form of the
+initial trial wave function for the system.  If the hartree keyword
+is used, then a Hartree multielectron trial wave function is used.  If
+the dproduct keyword is used, then a trial function which is a
+product of two determinants for each spin type is used.  If the uhf
+keyword is used, then an unrestricted Hartree-Fock trial wave function
+is used.
+
      
+
      The free, pbc, and fix keywords specify a width constraint on
+the electron wavepackets.  If the free keyword is specified, then there is no
+constraint.  If the pbc keyword is used and Plen is specified as
+-1, then the maximum width is half the shortest box length.  If Plen
+is a positive value, then the value is the maximum width.  If the
+fix keyword is used and Flen is specified as -1, then electrons
+have a constant width that is read from the data file.  If Flen is a
+positive value, then the constant width for all electrons is set to
+Flen.
+
      
+
      The harm keyword allow oscillations in the width of the
+electron wavepackets.  More details are needed.
+
      
+
      The ermscale keyword specifies a unitless scaling factor
+between the electron masses and the width variable mass.  More
+details needed.
+
      
+
      If the flex_press keyword is used, then a contribution from the
+electrons is added to the total virial and pressure of the system.
+
      
+
      This potential is designed to be used with atom_style
+wavepacket definitions, in order to handle the
+description of systems with interacting nuclei and explicit electrons.
+
      
+
      The following coefficients must be defined for each pair of atoms
+types via the pair_coeff command as in the examples
+above, or in the data file or restart files read by the
+read_data or read_restart
+commands, or by mixing as described below:
+
      
+
      • cutoff (distance units) 
+
      
+
      For awpmd/cut, the cutoff coefficient is optional.  If it is not
+used (as in some of the examples above), the default global value
+specified in the pair_style command is used.
+
      
+
      
+
+
      Mixing, shift, table, tail correction, restart, rRESPA info:
+
      
+
      The pair_modify mix, shift, table, and tail options
+are not relevant for this pair style.
+
      
+
      This pair style writes its information to binary restart
+files, so pair_style and pair_coeff commands do not need
+to be specified in an input script that reads a restart file.
+
      
+
      This pair style can only be used via the pair keyword of the
+run_style respa command.  It does not support the
+inner, middle, outer keywords.
+
      
+
      
+
+
      Restrictions: none
+
      
+
      Related commands:
+
      
+
      pair_coeff
+
      
+
      Default:
+
      
+
      These are the defaults for the pair_style keywords: hartree for the
+initial wavefunction, free for the wavepacket width.
+
      
+
diff --git a/doc/pair_awpmd.txt b/doc/pair_awpmd.txt
new file mode 100644
index 0000000000..fe0e3c952a
--- /dev/null
+++ b/doc/pair_awpmd.txt
@@ -0,0 +1,123 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+pair_style awpmd/cut command :h3
+
+[Syntax:]
+
+pair_style awpmd/cut Rc keyword value ... :pre
+
+Rc = global cutoff, -1 means cutoff of half the shortest box length :ulb,l
+zero or more keyword/value pairs may be appended :l
+keyword = {hartree} or {dproduct} or {uhf} or {free} or {pbc} or {fix} or {harm} or {ermscale} or {flex_press} :l
+  {hartree} value = none
+  {dproduct} value = none
+  {uhf} value = none
+  {free} value = none
+  {pbc} value = Plen
+    Plen = periodic width of electron = -1 or positive value (distance units)
+  {fix} value = Flen
+    Flen = fixed width of electron = -1 or positive value (distance units)
+  {harm} value = width
+    width = harmonic width constraint
+  {ermscale} value = factor
+    factor = scaling between electron mass and width variable mass
+  {flex_press} value = none :pre
+:ule
+
+
+[Examples:]
+
+pair_style awpmd/cut -1
+pair_style awpmd/cut 40.0 uhf free
+pair_coeff * *
+pair_coeff 2 2 20.0 :pre
+
+[Description:]
+
+This pair style contains an implementation of the Antisymmetrized Wave
+Packet Molecular Dynamics (AWPMD) method.  Need citation here.  Need
+basic formulas here.  Could be links to other documents.
+
+Rc is the cutoff.
+
+The pair_style command allows for several optional keywords
+to be specified.
+
+The {hartree}, {dproduct}, and {uhf} keywords specify the form of the
+initial trial wave function for the system.  If the {hartree} keyword
+is used, then a Hartree multielectron trial wave function is used.  If
+the {dproduct} keyword is used, then a trial function which is a
+product of two determinants for each spin type is used.  If the {uhf}
+keyword is used, then an unrestricted Hartree-Fock trial wave function
+is used.
+
+The {free}, {pbc}, and {fix} keywords specify a width constraint on
+the electron wavepackets.  If the {free} keyword is specified, then there is no
+constraint.  If the {pbc} keyword is used and {Plen} is specified as
+-1, then the maximum width is half the shortest box length.  If {Plen}
+is a positive value, then the value is the maximum width.  If the
+{fix} keyword is used and {Flen} is specified as -1, then electrons
+have a constant width that is read from the data file.  If {Flen} is a
+positive value, then the constant width for all electrons is set to
+{Flen}.
+
+The {harm} keyword allow oscillations in the width of the
+electron wavepackets.  More details are needed.
+
+The {ermscale} keyword specifies a unitless scaling factor
+between the electron masses and the width variable mass.  More
+details needed.
+
+If the {flex_press} keyword is used, then a contribution from the
+electrons is added to the total virial and pressure of the system.
+
+This potential is designed to be used with "atom_style
+wavepacket"_atom_style.html definitions, in order to handle the
+description of systems with interacting nuclei and explicit electrons.
+
+The following coefficients must be defined for each pair of atoms
+types via the "pair_coeff"_pair_coeff.html command as in the examples
+above, or in the data file or restart files read by the
+"read_data"_read_data.html or "read_restart"_read_restart.html
+commands, or by mixing as described below:
+
+cutoff (distance units) :ul
+
+For {awpmd/cut}, the cutoff coefficient is optional.  If it is not
+used (as in some of the examples above), the default global value
+specified in the pair_style command is used.
+
+:line
+
+[Mixing, shift, table, tail correction, restart, rRESPA info]:
+
+The "pair_modify"_pair_modify.html mix, shift, table, and tail options
+are not relevant for this pair style.
+
+This pair style writes its information to "binary restart
+files"_restart.html, so pair_style and pair_coeff commands do not need
+to be specified in an input script that reads a restart file.
+
+This pair style can only be used via the {pair} keyword of the
+"run_style respa"_run_style.html command.  It does not support the
+{inner}, {middle}, {outer} keywords.
+
+:line
+
+[Restrictions:] none
+
+[Related commands:]
+
+"pair_coeff"_pair_coeff.html
+
+[Default:]
+
+These are the defaults for the pair_style keywords: {hartree} for the
+initial wavefunction, {free} for the wavepacket width.
+
diff --git a/doc/pair_born.html b/doc/pair_born.html
index a478fcf3b2..e5d4038a78 100644
--- a/doc/pair_born.html
+++ b/doc/pair_born.html
@@ -11,8 +11,14 @@
 
 
      pair_style born command 
 
      
+
      pair_style born/omp command 
+
      
 
      pair_style born/coul/long command 
 
      
+
      pair_style born/coul/long/cuda command 
+
      
+
      pair_style born/coul/long/omp command 
+
      
 
      Syntax:
 
      
 
      pair_style style args 
@@ -87,6 +93,28 @@ Coulombic cutoff specified in the pair_style command.
 
      
 
      
 
+
      Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
      
+
      These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
      
+
      You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
      
+
      See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
      
+
      
+
 
      Mixing, shift, table, tail correction, restart, rRESPA info:
 
      
 
      These pair styles do not support mixing.  Thus, coefficients for all
@@ -115,10 +143,10 @@ respa command.  They do not support the inner,
 
 
      Restrictions:
 
      
-
      The born/coul/long style is part of the "kspace" package.  It is
-only enabled if LAMMPS was built with that package (which it is by
-default).  See the Making LAMMPS section for
-more info.
+
      The born/coul/long style is part of the KSPACE package.  It is only
+enabled if LAMMPS was built with that package (which it is by
+default).  See the Making LAMMPS section
+for more info.
 
      
 
      Related commands:
 
      
diff --git a/doc/pair_born.txt b/doc/pair_born.txt
index 5c737b3dcb..652e7b4dda 100644
--- a/doc/pair_born.txt
+++ b/doc/pair_born.txt
@@ -8,7 +8,10 @@
 :line
 
 pair_style born command :h3
+pair_style born/omp command :h3
 pair_style born/coul/long command :h3
+pair_style born/coul/long/cuda command :h3
+pair_style born/coul/long/omp command :h3
 
 [Syntax:]
 
@@ -83,6 +86,28 @@ Coulombic cutoff specified in the pair_style command.
 
 :line
 
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Mixing, shift, table, tail correction, restart, rRESPA info]:
 
 These pair styles do not support mixing.  Thus, coefficients for all
@@ -111,10 +136,10 @@ respa"_run_style.html command.  They do not support the {inner},
 
 [Restrictions:]
 
-The {born/coul/long} style is part of the "kspace" package.  It is
-only enabled if LAMMPS was built with that package (which it is by
-default).  See the "Making LAMMPS"_Section_start.html#2_3 section for
-more info.
+The {born/coul/long} style is part of the KSPACE package.  It is only
+enabled if LAMMPS was built with that package (which it is by
+default).  See the "Making LAMMPS"_Section_start.html#start_3 section
+for more info.
 
 [Related commands:]
 
diff --git a/doc/pair_brownian.html b/doc/pair_brownian.html
new file mode 100644
index 0000000000..223b51243f
--- /dev/null
+++ b/doc/pair_brownian.html
@@ -0,0 +1,114 @@
+
+
      LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
      
+
+
+
+
+
+
+
      
+
+
      pair_style brownian command 
+
      
+
      pair_style brownian/poly command 
+
      
+
      Syntax:
+
      
+
      pair_style style mu flaglog flagfld cutinner cutoff t_target seed 
+
      
+
      • style = brownian or brownian/poly
+
      • mu = dynamic viscosity (dynamic viscosity units)
+
      • flaglog = 0/1 log terms in the lubrication approximation on/off
+
      • flagfld = 0/1 to include/exclude Fast Lubrication Dynamics effects
+
      • cutinner = inner cutoff distance (distance units)
+
      • cutoff = outer cutoff for interactions (distance units)
+
      • t_target = target temp of the system (temperature units)
+
      • seed = seed for the random number generator (positive integer) 
+
      
+
      Examples:
+
      
+
      pair_style brownian 1.5 1 1 2.01 2.5 2.0 5878567 (assuming radius=1)
+pair_coeff 1 1 2.05 2.8
+pair_coeff * * 
+
      
+
      Description:
+
      
+
      Styles brownian and brownain/poly compute Brownian forces and
+torques on finite-size particles.  The former requires monodisperse
+spherical particles; the latter allows for polydisperse spherical
+particles.
+
      
+
      These pair styles are designed to be used with either the pair_style
+lubricate or pair_style
+lubricateU commands to provide thermostatting
+when dissipative lubrication forces are acting.  Thus the parameters
+mu, flaglog, flagfld, cutinner, and cutoff should be
+specified consistent with the settings in the lubrication pair styles.
+For details, refer to either of the lubrication pair styles.
+
      
+
      The t_target setting is used to specify the target temperature of
+the system.  The random number seed is used to generate random
+numbers for the thermostatting procedure.
+
      
+
      The following coefficients must be defined for each pair of atoms
+types via the pair_coeff command as in the examples
+above, or in the data file or restart files read by the
+read_data or read_restart
+commands, or by mixing as described below:
+
      
+
      • cutinner (distance units)
+
      • cutoff (distance units) 
+
      
+
      The two coefficients are optional.  If neither is specified, the two
+cutoffs specified in the pair_style command are used.  Otherwise both
+must be specified.
+
      
+
      
+
+
      Mixing, shift, table, tail correction, restart, rRESPA info:
+
      
+
      For atom type pairs I,J and I != J, the two cutoff distances for this
+pair style can be mixed.  The default mix value is geometric.  See
+the "pair_modify" command for details.
+
      
+
      This pair style does not support the pair_modify
+shift option for the energy of the pair interaction.
+
      
+
      The pair_modify table option is not relevant
+for this pair style.
+
      
+
      This pair style does not support the pair_modify
+tail option for adding long-range tail corrections to energy and
+pressure.
+
      
+
      This pair style writes its information to binary restart
+files, so pair_style and pair_coeff commands do not need
+to be specified in an input script that reads a restart file.
+
      
+
      This pair style can only be used via the pair keyword of the
+run_style respa command.  It does not support the
+inner, middle, outer keywords.
+
      
+
      
+
+
      Restrictions:
+
      
+
      These styles are part of the FLD package.  They are only enabled if
+LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
      
+
      Only spherical monodisperse particles are allowed for pair_style
+brownian.
+
      
+
      Only spherical particles are allowed for pair_style brownian/poly.
+
      
+
      Related commands:
+
      
+
      pair_coeff, pair_style
+lubricate, pair_style
+lubricateU
+
      
+
      Default: none
+
      
+
diff --git a/doc/pair_brownian.txt b/doc/pair_brownian.txt
new file mode 100644
index 0000000000..665118db7c
--- /dev/null
+++ b/doc/pair_brownian.txt
@@ -0,0 +1,108 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+pair_style brownian command :h3
+pair_style brownian/poly command :h3
+
+[Syntax:]
+
+pair_style style mu flaglog flagfld cutinner cutoff t_target seed :pre
+
+style = {brownian} or {brownian/poly}
+mu = dynamic viscosity (dynamic viscosity units)
+flaglog = 0/1 log terms in the lubrication approximation on/off
+flagfld = 0/1 to include/exclude Fast Lubrication Dynamics effects
+cutinner = inner cutoff distance (distance units)
+cutoff = outer cutoff for interactions (distance units)
+t_target = target temp of the system (temperature units)
+seed = seed for the random number generator (positive integer) :ul 
+
+[Examples:]
+
+pair_style brownian 1.5 1 1 2.01 2.5 2.0 5878567 (assuming radius=1)
+pair_coeff 1 1 2.05 2.8
+pair_coeff * * :pre
+
+[Description:]
+
+Styles {brownian} and {brownain/poly} compute Brownian forces and
+torques on finite-size particles.  The former requires monodisperse
+spherical particles; the latter allows for polydisperse spherical
+particles.
+
+These pair styles are designed to be used with either the "pair_style
+lubricate"_pair_lubricate.html or "pair_style
+lubricateU"_pair_lubricateU.html commands to provide thermostatting
+when dissipative lubrication forces are acting.  Thus the parameters
+{mu}, {flaglog}, {flagfld}, {cutinner}, and {cutoff} should be
+specified consistent with the settings in the lubrication pair styles.
+For details, refer to either of the lubrication pair styles.
+
+The {t_target} setting is used to specify the target temperature of
+the system.  The random number {seed} is used to generate random
+numbers for the thermostatting procedure.
+
+The following coefficients must be defined for each pair of atoms
+types via the "pair_coeff"_pair_coeff.html command as in the examples
+above, or in the data file or restart files read by the
+"read_data"_read_data.html or "read_restart"_read_restart.html
+commands, or by mixing as described below:
+
+cutinner (distance units)
+cutoff (distance units) :ul
+
+The two coefficients are optional.  If neither is specified, the two
+cutoffs specified in the pair_style command are used.  Otherwise both
+must be specified.
+
+:line
+
+[Mixing, shift, table, tail correction, restart, rRESPA info]:
+
+For atom type pairs I,J and I != J, the two cutoff distances for this
+pair style can be mixed.  The default mix value is {geometric}.  See
+the "pair_modify" command for details.
+
+This pair style does not support the "pair_modify"_pair_modify.html
+shift option for the energy of the pair interaction.
+
+The "pair_modify"_pair_modify.html table option is not relevant
+for this pair style.
+
+This pair style does not support the "pair_modify"_pair_modify.html
+tail option for adding long-range tail corrections to energy and
+pressure.
+
+This pair style writes its information to "binary restart
+files"_restart.html, so pair_style and pair_coeff commands do not need
+to be specified in an input script that reads a restart file.
+
+This pair style can only be used via the {pair} keyword of the
+"run_style respa"_run_style.html command.  It does not support the
+{inner}, {middle}, {outer} keywords.
+
+:line
+
+[Restrictions:]
+
+These styles are part of the FLD package.  They are only enabled if
+LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#2_3 section for more info.
+
+Only spherical monodisperse particles are allowed for pair_style
+brownian.
+
+Only spherical particles are allowed for pair_style brownian/poly.
+
+[Related commands:]
+
+"pair_coeff"_pair_coeff.html, "pair_style
+lubricate"_pair_lubricate.html, "pair_style
+lubricateU"_pair_lubricateU.html
+
+[Default:] none
diff --git a/doc/pair_buck.html b/doc/pair_buck.html
index 3b0c670af2..a7b8c76aac 100644
--- a/doc/pair_buck.html
+++ b/doc/pair_buck.html
@@ -11,10 +11,22 @@
 
 
      pair_style buck command 
 
      
+
      pair_style buck/cuda command 
+
      
+
      pair_style buck/omp command 
+
      
 
      pair_style buck/coul/cut command 
 
      
+
      pair_style buck/coul/cut/cuda command 
+
      
+
      pair_style buck/coul/cut/omp command 
+
      
 
      pair_style buck/coul/long command 
 
      
+
      pair_style buck/coul/long/cuda command 
+
      
+
      pair_style buck/coul/long/omp command 
+
      
 
      Syntax:
 
      
 
      pair_style style args 
@@ -104,6 +116,28 @@ pair_style command.
 
      
 
      
 
+
      Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
      
+
      These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
      
+
      You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
      
+
      See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
      
+
      
+
 
      Mixing, shift, table, tail correction, restart, rRESPA info:
 
      
 
      These pair styles do not support mixing.  Thus, coefficients for all
@@ -130,10 +164,10 @@ respa command.  They do not support the inner,
 
      
 
      Restrictions:
 
      
-
      The buck/coul/long style is part of the "kspace" package.  It is
-only enabled if LAMMPS was built with that package (which it is by
-default).  See the Making LAMMPS section for
-more info.
+
      The buck/coul/long style is part of the KSPACE package.  It is only
+enabled if LAMMPS was built with that package (which it is by
+default).  See the Making LAMMPS section
+for more info.
 
      
 
      Related commands:
 
      
diff --git a/doc/pair_buck.txt b/doc/pair_buck.txt
index e9ba8e4670..1f875f9ac4 100644
--- a/doc/pair_buck.txt
+++ b/doc/pair_buck.txt
@@ -7,8 +7,14 @@
 :line
 
 pair_style buck command :h3
+pair_style buck/cuda command :h3
+pair_style buck/omp command :h3
 pair_style buck/coul/cut command :h3
+pair_style buck/coul/cut/cuda command :h3
+pair_style buck/coul/cut/omp command :h3
 pair_style buck/coul/long command :h3
+pair_style buck/coul/long/cuda command :h3
+pair_style buck/coul/long/omp command :h3
 
 [Syntax:]
 
@@ -98,6 +104,28 @@ pair_style command.
 
 :line
 
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Mixing, shift, table, tail correction, restart, rRESPA info]:
 
 These pair styles do not support mixing.  Thus, coefficients for all
@@ -124,10 +152,10 @@ respa"_run_style.html command.  They do not support the {inner},
 
 [Restrictions:]
 
-The {buck/coul/long} style is part of the "kspace" package.  It is
-only enabled if LAMMPS was built with that package (which it is by
-default).  See the "Making LAMMPS"_Section_start.html#2_3 section for
-more info.
+The {buck/coul/long} style is part of the KSPACE package.  It is only
+enabled if LAMMPS was built with that package (which it is by
+default).  See the "Making LAMMPS"_Section_start.html#start_3 section
+for more info.
 
 [Related commands:]
 
diff --git a/doc/pair_buck_coul.html b/doc/pair_buck_coul.html
index cc685e6604..149fe36e3d 100644
--- a/doc/pair_buck_coul.html
+++ b/doc/pair_buck_coul.html
@@ -11,6 +11,8 @@
 
 
      pair_style buck/coul command 
 
      
+
      pair_style buck/coul/omp command 
+
      
 
      Syntax:
 
      
 
      pair_style buck/coul flag_buck flag_coul cutoff (cutoff2) 
@@ -103,6 +105,28 @@ global Coulombic cutoff is allowed.
 
      
 
      
 
+
      Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
      
+
      These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
      
+
      You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
      
+
      See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
      
+
      
+
 
      Mixing, shift, table, tail correction, restart, rRESPA info:
 
      
 
      This pair styles does not support mixing.  Thus, coefficients for all
@@ -134,8 +158,8 @@ details.
 
 
      Restrictions:
 
      
-
      This style is part of the "user-ewaldn" package.  It is only enabled
-if LAMMPS was built with that package.  See the Making
+
      This style is part of the USER-EWALDN package.  It is only enabled if
+LAMMPS was built with that package.  See the Making
 LAMMPS section for more info.
 
      
 
      Related commands:
diff --git a/doc/pair_buck_coul.txt b/doc/pair_buck_coul.txt
index 1a6d42d86f..4db2117094 100644
--- a/doc/pair_buck_coul.txt
+++ b/doc/pair_buck_coul.txt
@@ -7,6 +7,7 @@
 :line
 
 pair_style buck/coul command :h3
+pair_style buck/coul/omp command :h3
 
 [Syntax:]
 
@@ -95,6 +96,28 @@ global Coulombic cutoff is allowed.
 
 :line
 
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Mixing, shift, table, tail correction, restart, rRESPA info]:
 
 This pair styles does not support mixing.  Thus, coefficients for all
@@ -126,9 +149,9 @@ details.
 
 [Restrictions:]
 
-This style is part of the "user-ewaldn" package.  It is only enabled
-if LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+This style is part of the USER-EWALDN 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:]
 
diff --git a/doc/pair_charmm.html b/doc/pair_charmm.html
index c23f49da3c..40ba0d5402 100644
--- a/doc/pair_charmm.html
+++ b/doc/pair_charmm.html
@@ -11,19 +11,33 @@
 
 
      pair_style lj/charmm/coul/charmm command 
 
      
+
      pair_style lj/charmm/coul/charmm/cuda command 
+
      
+
      pair_style lj/charmm/coul/charmm/omp command 
+
      
 
      pair_style lj/charmm/coul/charmm/implicit command 
 
      
+
      pair_style lj/charmm/coul/charmm/implicit/cuda command 
+
      
+
      pair_style lj/charmm/coul/charmm/implicit/omp command 
+
      
 
      pair_style lj/charmm/coul/long command 
 
      
+
      pair_style lj/charmm/coul/long/cuda command 
+
      
 
      pair_style lj/charmm/coul/long/gpu command 
 
      
 
      pair_style lj/charmm/coul/long/opt command 
 
      
+
      pair_style lj/charmm/coul/long/omp command 
+
      
+
      pair_style lj/charmm/coul/pppm/omp command 
+
      
 
      Syntax:
 
      
 
      pair_style style args 
 
      
-
      • style = lj/charmm/coul/charmm or lj/charmm/coul/charmm/implicit or lj/charmm/coul/long or lj/charmm/coul/long/gpu or lj/charmm/coul/long/opt
+
        • style = lj/charmm/coul/charmm or lj/charmm/coul/charmm/implicit or lj/charmm/coul/long
 
        • args = list of arguments for a particular style 
 
        
 
          lj/charmm/coul/charmm args = inner outer (inner2) (outer2)
@@ -33,9 +47,6 @@
     inner, outer = global switching cutoffs for LJ (and Coulombic if only 2 args)
     inner2, outer2 = global switching cutoffs for Coulombic (optional)
   lj/charmm/coul/long args = inner outer (cutoff)
-    inner, outer = global switching cutoffs for LJ (and Coulombic if only 2 args)
-    cutoff = global cutoff for Coulombic (optional, outer is Coulombic cutoff if only 2 args)
-  lj/charmm/coul/long/gpu args = inner outer (cutoff)
     inner, outer = global switching cutoffs for LJ (and Coulombic if only 2 args)
     cutoff = global cutoff for Coulombic (optional, outer is Coulombic cutoff if only 2 args) 
 
        
@@ -52,7 +63,6 @@ pair_coeff * * 100.0 2.0
 pair_coeff 1 1 100.0 2.0 150.0 3.5 
 
      
 
      pair_style lj/charmm/coul/long 8.0 10.0
-pair_style lj/charmm/coul/long/opt 8.0 10.0
 pair_style lj/charmm/coul/long 8.0 10.0 9.0
 pair_coeff * * 100.0 2.0
 pair_coeff 1 1 100.0 2.0 150.0 3.5 
@@ -83,21 +93,19 @@ which is a simple model for an implicit solvent with additional
 screening.  It is designed for use in a simulation of an unsolvated
 biomolecule (no explicit water molecules).
 
      
-
      Style lj/charmm/coul/long computes the same formulas as style
-lj/charmm/coul/charmm except that an additional damping factor is
-applied to the Coulombic term, as in the discussion for pair style
-lj/cut/coul/long.  Only one Coulombic cutoff is specified for
-lj/charmm/coul/long; if only 2 arguments are used in the pair_style
-command, then the outer LJ cutoff is used as the single Coulombic
-cutoff.
-
      
-
      Style lj/charmm/coul/long/gpu is a GPU-enabled version of style lj/charmm/coul/long.
-See more details below.
-
      
-
      Style lj/charmm/coul/long/opt is an optimized version of style
-lj/charmm/coul/long that should give identical answers.  Depending
-on system size and the processor you are running on, it may be 5-25%
-faster (for the pairwise portion of the run time).
+
      Styles lj/charmm/coul/long and lj/charmm/coul/pppm/omp compute
+the same formulas as style lj/charmm/coul/charmm except that an
+additional damping factor is applied to the Coulombic term, as in
+the discussion for pair style lj/cut/coul/long.  Only one Coulombic
+cutoff is specified for lj/charmm/coul/long; if only 2 arguments
+are used in the pair_style command, then the outer LJ cutoff is
+used as the single Coulombic cutoff. Style lj/charmm/coul/pppm/omp
+is a variant for use with K-space style pppm/proxy
+and OpenMP multi-threading and will perform the corresponding
+reciprocal space calculation concurrently with the pair calculation
+in a separate thread. For certain parallel setups, this may have
+a performance benefit over performing k-space style and pair style
+separately and one after the other.
 
      
 
      The following coefficients must be defined for each pair of atoms
 types via the pair_coeff command as in the examples
@@ -123,23 +131,25 @@ the pair_style command.
 
      
 
      
 
-
      The lj/charmm/coul/long/gpu style is identical to the lj/charmm/coul/long
-style, except that each processor off-loads its pairwise calculations to 
-a GPU chip. Depending on the hardware available on your system this can 
-provide a significant speed-up.  See the Running on
-GPUs section of the manual for more details
-about hardware and software requirements for using GPUs.
+
      Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
 
      
-
      More details about these settings and various possible hardware
-configuration are in this section of the
-manual.
+
      These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
 
      
-
      Additional requirements in your input script to run with style
-lj/charmm/coul/long/gpu are as follows:
+
      You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
 
      
-
      The newton pair setting must be off and
-fix gpu must be used. The fix controls the
-essential GPU selection and initialization steps.
+
      See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
 
      
 
      
 
@@ -155,10 +165,9 @@ command for details.
 pair_modify shift option, since the Lennard-Jones
 portion of the pair interaction is smoothed to 0.0 at the cutoff.
 
      
-
      The lj/charmm/coul/long and lj/charmm/coul/long/opt pair styles
-support the pair_modify table option since they can
-tabulate the short-range portion of the long-range Coulombic
-interaction.
+
      The lj/charmm/coul/long style supports the
+pair_modify table option since it can tabulate the
+short-range portion of the long-range Coulombic interaction.
 
      
 
      None of the lj/charmm pair styles support the
 pair_modify tail option for adding long-range tail
@@ -181,19 +190,11 @@ support the pair keyword of run_style respa.  See the
 
      Restrictions:
 
      
 
      The lj/charmm/coul/charmm and lj/charmm/coul/charmm/implicit
-styles are part of the "molecule" package.  The lj/charmm/coul/long
-style is part of the "kspace" package.  The lj/charmm/coul/long/gpu
-style is part of the "gpu" package and also requires the "kspace"
-package. The lj/charmm/coul/long/opt
-style is part of the "opt" package and also requires the "kspace"
-package.  They are only enabled if LAMMPS was built with those
-package(s) (molecule and kspace are by default).  See the Making
-LAMMPS section for more info.
-
      
-
      On some 64-bit machines, compiling with -O3 appears to break the
-Coulombic tabling option used by the lj/charmm/coul/long style.  See
-the "Additional build tips" section of the Making LAMMPS documentation
-pages for workarounds on this issue.
+styles are part of the MOLECULE package.  The lj/charmm/coul/long
+style is part of the KSPACE package.  They are only enabled if LAMMPS
+was built with those packages.  See the Making
+LAMMPS section for more info.  Note that
+the MOLECULE and KSPACE packages are installed by default.
 
      
 
      Related commands:
 
      
diff --git a/doc/pair_charmm.txt b/doc/pair_charmm.txt
index d6a22a6399..e7cf050548 100644
--- a/doc/pair_charmm.txt
+++ b/doc/pair_charmm.txt
@@ -7,16 +7,23 @@
 :line
 
 pair_style lj/charmm/coul/charmm command :h3
+pair_style lj/charmm/coul/charmm/cuda command :h3
+pair_style lj/charmm/coul/charmm/omp command :h3
 pair_style lj/charmm/coul/charmm/implicit command :h3
+pair_style lj/charmm/coul/charmm/implicit/cuda command :h3
+pair_style lj/charmm/coul/charmm/implicit/omp command :h3
 pair_style lj/charmm/coul/long command :h3
+pair_style lj/charmm/coul/long/cuda command :h3
 pair_style lj/charmm/coul/long/gpu command :h3
 pair_style lj/charmm/coul/long/opt command :h3
+pair_style lj/charmm/coul/long/omp command :h3
+pair_style lj/charmm/coul/pppm/omp command :h3
 
 [Syntax:]
 
 pair_style style args :pre
 
-style = {lj/charmm/coul/charmm} or {lj/charmm/coul/charmm/implicit} or {lj/charmm/coul/long} or {lj/charmm/coul/long/gpu} or {lj/charmm/coul/long/opt}
+style = {lj/charmm/coul/charmm} or {lj/charmm/coul/charmm/implicit} or {lj/charmm/coul/long}
 args = list of arguments for a particular style :ul
   {lj/charmm/coul/charmm} args = inner outer (inner2) (outer2)
     inner, outer = global switching cutoffs for Lennard Jones (and Coulombic if only 2 args)
@@ -25,9 +32,6 @@ args = list of arguments for a particular style :ul
     inner, outer = global switching cutoffs for LJ (and Coulombic if only 2 args)
     inner2, outer2 = global switching cutoffs for Coulombic (optional)
   {lj/charmm/coul/long} args = inner outer (cutoff)
-    inner, outer = global switching cutoffs for LJ (and Coulombic if only 2 args)
-    cutoff = global cutoff for Coulombic (optional, outer is Coulombic cutoff if only 2 args)
-  {lj/charmm/coul/long/gpu} args = inner outer (cutoff)
     inner, outer = global switching cutoffs for LJ (and Coulombic if only 2 args)
     cutoff = global cutoff for Coulombic (optional, outer is Coulombic cutoff if only 2 args) :pre
 
@@ -44,7 +48,6 @@ pair_coeff * * 100.0 2.0
 pair_coeff 1 1 100.0 2.0 150.0 3.5 :pre
 
 pair_style lj/charmm/coul/long 8.0 10.0
-pair_style lj/charmm/coul/long/opt 8.0 10.0
 pair_style lj/charmm/coul/long 8.0 10.0 9.0
 pair_coeff * * 100.0 2.0
 pair_coeff 1 1 100.0 2.0 150.0 3.5 :pre
@@ -75,21 +78,19 @@ which is a simple model for an implicit solvent with additional
 screening.  It is designed for use in a simulation of an unsolvated
 biomolecule (no explicit water molecules).
 
-Style {lj/charmm/coul/long} computes the same formulas as style
-{lj/charmm/coul/charmm} except that an additional damping factor is
-applied to the Coulombic term, as in the discussion for pair style
-{lj/cut/coul/long}.  Only one Coulombic cutoff is specified for
-{lj/charmm/coul/long}; if only 2 arguments are used in the pair_style
-command, then the outer LJ cutoff is used as the single Coulombic
-cutoff.
-
-Style {lj/charmm/coul/long/gpu} is a GPU-enabled version of style {lj/charmm/coul/long}.
-See more details below.
-
-Style {lj/charmm/coul/long/opt} is an optimized version of style
-{lj/charmm/coul/long} that should give identical answers.  Depending
-on system size and the processor you are running on, it may be 5-25%
-faster (for the pairwise portion of the run time).
+Styles {lj/charmm/coul/long} and {lj/charmm/coul/pppm/omp} compute
+the same formulas as style {lj/charmm/coul/charmm} except that an
+additional damping factor is applied to the Coulombic term, as in
+the discussion for pair style {lj/cut/coul/long}.  Only one Coulombic
+cutoff is specified for {lj/charmm/coul/long}; if only 2 arguments
+are used in the pair_style command, then the outer LJ cutoff is
+used as the single Coulombic cutoff. Style {lj/charmm/coul/pppm/omp}
+is a variant for use with K-space style "{pppm/proxy}"_kspace_style.html
+and OpenMP multi-threading and will perform the corresponding
+reciprocal space calculation concurrently with the pair calculation
+in a separate thread. For certain parallel setups, this may have
+a performance benefit over performing k-space style and pair style
+separately and one after the other.
 
 The following coefficients must be defined for each pair of atoms
 types via the "pair_coeff"_pair_coeff.html command as in the examples
@@ -115,23 +116,25 @@ the pair_style command.
 
 :line
 
-The {lj/charmm/coul/long/gpu} style is identical to the {lj/charmm/coul/long}
-style, except that each processor off-loads its pairwise calculations to 
-a GPU chip. Depending on the hardware available on your system this can 
-provide a significant speed-up.  See the "Running on
-GPUs"_Section_start.html#2_8 section of the manual for more details
-about hardware and software requirements for using GPUs.
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_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.
 
-More details about these settings and various possible hardware
-configuration are in "this section"_Section_start.html#2_8 of the
-manual.
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
 
-Additional requirements in your input script to run with style
-{lj/charmm/coul/long/gpu} are as follows:
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
 
-The "newton pair"_newton.html setting must be {off} and
-"fix gpu"_fix_gpu.html must be used. The fix controls the
-essential GPU selection and initialization steps.
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
 
 :line
 
@@ -147,10 +150,9 @@ None of the lj/charmm pair styles support the
 "pair_modify"_pair_modify.html shift option, since the Lennard-Jones
 portion of the pair interaction is smoothed to 0.0 at the cutoff.
 
-The {lj/charmm/coul/long} and {lj/charmm/coul/long/opt} pair styles
-support the "pair_modify"_pair_modify.html table option since they can
-tabulate the short-range portion of the long-range Coulombic
-interaction.
+The {lj/charmm/coul/long} style supports the
+"pair_modify"_pair_modify.html table option since it can tabulate the
+short-range portion of the long-range Coulombic interaction.
 
 None of the lj/charmm pair styles support the
 "pair_modify"_pair_modify.html tail option for adding long-range tail
@@ -173,19 +175,11 @@ support the {pair} keyword of run_style respa.  See the
 [Restrictions:]
 
 The {lj/charmm/coul/charmm} and {lj/charmm/coul/charmm/implicit}
-styles are part of the "molecule" package.  The {lj/charmm/coul/long}
-style is part of the "kspace" package.  The {lj/charmm/coul/long/gpu}
-style is part of the "gpu" package and also requires the "kspace"
-package. The {lj/charmm/coul/long/opt}
-style is part of the "opt" package and also requires the "kspace"
-package.  They are only enabled if LAMMPS was built with those
-package(s) (molecule and kspace are by default).  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
-
-On some 64-bit machines, compiling with -O3 appears to break the
-Coulombic tabling option used by the {lj/charmm/coul/long} style.  See
-the "Additional build tips" section of the Making LAMMPS documentation
-pages for workarounds on this issue.
+styles are part of the MOLECULE package.  The {lj/charmm/coul/long}
+style is part of the KSPACE package.  They are only enabled if LAMMPS
+was built with those packages.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.  Note that
+the MOLECULE and KSPACE packages are installed by default.
 
 [Related commands:]
 
diff --git a/doc/pair_class2.html b/doc/pair_class2.html
index f7247de5bd..b4fc597158 100644
--- a/doc/pair_class2.html
+++ b/doc/pair_class2.html
@@ -11,10 +11,26 @@
 
 
      pair_style lj/class2 command 
 
      
+
      pair_style lj/class2/cuda command 
+
      
+
      pair_style lj/class2/gpu command 
+
      
+
      pair_style lj/class2/omp command 
+
      
 
      pair_style lj/class2/coul/cut command 
 
      
+
      pair_style lj/class2/coul/cut/cuda command 
+
      
+
      pair_style lj/class2/coul/cut/omp command 
+
      
 
      pair_style lj/class2/coul/long command 
 
      
+
      pair_style lj/class2/coul/long/cuda command 
+
      
+
      pair_style lj/class2/coul/long/gpu command 
+
      
+
      pair_style lj/class2/coul/long/omp command 
+
      
 
      Syntax:
 
      
 
      pair_style style args 
@@ -86,8 +102,8 @@ since a Coulombic cutoff cannot be specified for an individual I,J
 type pair.  All type pairs use the same global Coulombic cutoff
 specified in the pair_style command.
 
      
-
      : line
-
      
+
      
+
 
      If the pair_coeff command is not used to define coefficients for a
 particular I != J type pair, the mixing rule for epsilon and sigma for
 all class2 potentials is to use the sixthpower formulas documented
@@ -96,6 +112,30 @@ mix setting is thus ignored for class2 potentials
 for epsilon and sigma.  However it is still followed for mixing the
 cutoff distance.
 
      
+
      
+
+
      Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
      
+
      These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
      
+
      You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
      
+
      See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
      
+
      
+
 
      Mixing, shift, table, tail correction, restart, rRESPA info:
 
      
 
      For atom type pairs I,J and I != J, the epsilon and sigma coefficients
@@ -128,8 +168,8 @@ support the inner, middle, outer keywords.
 
      
 
      Restrictions:
 
      
-
      All of these pair styles are part of the "class2" package.  They are
-only enabled if LAMMPS was built with that package.  See the Making
+
      These styles are part of the CLASS2 package.  They are only enabled if
+LAMMPS was built with that package.  See the Making
 LAMMPS section for more info.
 
      
 
      Related commands:
diff --git a/doc/pair_class2.txt b/doc/pair_class2.txt
index 43feb6a8f1..3013727493 100644
--- a/doc/pair_class2.txt
+++ b/doc/pair_class2.txt
@@ -7,8 +7,16 @@
 :line
 
 pair_style lj/class2 command :h3
+pair_style lj/class2/cuda command :h3
+pair_style lj/class2/gpu command :h3
+pair_style lj/class2/omp command :h3
 pair_style lj/class2/coul/cut command :h3
+pair_style lj/class2/coul/cut/cuda command :h3
+pair_style lj/class2/coul/cut/omp command :h3
 pair_style lj/class2/coul/long command :h3
+pair_style lj/class2/coul/long/cuda command :h3
+pair_style lj/class2/coul/long/gpu command :h3
+pair_style lj/class2/coul/long/omp command :h3
 
 [Syntax:]
 
@@ -80,7 +88,7 @@ since a Coulombic cutoff cannot be specified for an individual I,J
 type pair.  All type pairs use the same global Coulombic cutoff
 specified in the pair_style command.
 
-: line
+:line
 
 If the pair_coeff command is not used to define coefficients for a
 particular I != J type pair, the mixing rule for epsilon and sigma for
@@ -90,6 +98,30 @@ mix"_pair_modify.html setting is thus ignored for class2 potentials
 for epsilon and sigma.  However it is still followed for mixing the
 cutoff distance.
 
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Mixing, shift, table, tail correction, restart, rRESPA info]:
 
 For atom type pairs I,J and I != J, the epsilon and sigma coefficients
@@ -122,9 +154,9 @@ support the {inner}, {middle}, {outer} keywords.
 
 [Restrictions:]
 
-All of these pair styles are part of the "class2" package.  They are
-only enabled if LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+These styles are part of the CLASS2 package.  They are only enabled if
+LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
 
 [Related commands:]
 
diff --git a/doc/pair_cmm.html b/doc/pair_cmm.html
deleted file mode 100644
index 5f43b6ef63..0000000000
--- a/doc/pair_cmm.html
+++ /dev/null
@@ -1,211 +0,0 @@
-
-
      LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
-
      
-
-
-
-
-
-
-
      
-
-
      pair_style cg/cmm command 
-
      
-
      pair_style cg/cmm/gpu command 
-
      
-
      pair_style cg/cmm/coul/cut command 
-
      
-
      pair_style cg/cmm/coul/long command 
-
      
-
      pair_style cg/cmm/coul/long/gpu command 
-
      
-
      Syntax:
-
      
-
      pair_style style args 
-
      
-
      • style = cg/cmm or cg/cmm/gpu or cg/cmm/coul/cut or cg/cmm/coul/long or cg/cmm/coul/long/gpu
-
      • args = list of arguments for a particular style 
-
      
-
        cg/cmm args = cutoff
-    cutoff = global cutoff for Lennard Jones interactions (distance units)
-  cg/cmm/gpu args = cutoff
-    cutoff = global cutoff for Lennard Jones interactions (distance units)
-  cg/cmm/coul/cut args = cutoff (cutoff2) (kappa)
-    cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
-    cutoff2 = global cutoff for Coulombic (optional) (distance units)
-    kappa = Debye length (optional, defaults to 0.0 = disabled) (inverse distance units)
-  cg/cmm/coul/long args = cutoff (cutoff2)
-    cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
-    cutoff2 = global cutoff for Coulombic (optional) (distance units) 
-
      
-
        cg/cmm/coul/long/gpu args = cutoff (cutoff2)
-    cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
-    cutoff2 = global cutoff for Coulombic (optional) (distance units) 
-
      
-
      Examples:
-
      
-
      pair_style cg/cmm 2.5
-pair_coeff 1 1 lj12_6 1 1.1 2.8 
-
      
-
      pair_style cg/cmm/coul/cut 10.0 12.0
-pair_coeff 1 1 lj9_6  100.0 3.5 9.0
-pair_coeff 1 1 lj12_4 100.0 3.5 9.0 9.0 
-
      
-
      pair_style cg/cmm/coul/long 10.0
-pair_style cg/cmm/coul/long 10.0 8.0
-pair_coeff 1 1 lj9_6 100.0 3.5 9.0 
-
      
-
      Description:
-
      
-
      The cg/cmm styles compute a 9/6, 12/4, or 12/6 Lennard-Jones potential,
-given by
-
      
-
      
-
      
-
      as required for the CMM Coarse-grained MD parametrization discussed in
-(Shinoda) and (DeVane).  Rc is the cutoff.
-
      
-
      Style cg/cmm/gpu is a GPU-enabled version of style cg/cmm.
-See more details below.
-
      
-
      Style cg/cmm/coul/cut adds a Coulombic pairwise interaction given by
-
      
-
      
-
      
-
      where C is an energy-conversion constant, Qi and Qj are the charges on
-the 2 atoms, and epsilon is the dielectric constant which can be set
-by the dielectric command.  If one cutoff is
-specified in the pair_style command, it is used for both the LJ and
-Coulombic terms.  If two cutoffs are specified, they are used as
-cutoffs for the LJ and Coulombic terms respectively.
-
      
-
      This style also contains an additional exp() damping factor
-to the Coulombic term, given by
-
      
-
      
-
      
-
      where kappa is the Debye length (kappa=0.0 is the unscreened coulomb).
-This potential is another way to mimic the screening effect of a polar
-solvent.
-
      
-
      Style cg/cmm/coul/long computes the same Coulombic interactions as
-style cg/cmm/coul/cut except that an additional damping factor is
-applied to the Coulombic term so it can be used in conjunction with
-the kspace_style command and its ewald or pppm
-option.  The Coulombic cutoff specified for this style means that
-pairwise interactions within this distance are computed directly;
-interactions outside that distance are computed in reciprocal space.
-
      
-
      Style cg/cmm/coul/long/gpu is a GPU-enabled version of style cg/cmm/coul/long.
-See more details below.
-
      
-
      The following coefficients must be defined for each pair of atoms
-types via the pair_coeff command as in the examples
-above, or in the data file or restart files read by the
-read_data or read_restart
-commands, or by mixing as described below:
-
      
-
      • cg_type (lj9_6, lj12_4, or lj12_6)
-
      • epsilon (energy units)
-
      • sigma (distance units)
-
      • cutoff1 (distance units)
-
      • cutoff2 (distance units) 
-
      
-
      Note that sigma is defined in the LJ formula as the zero-crossing
-distance for the potential, not as the energy minimum. The prefactors
-are chosen so that the potential minimum is at -epsilon.
-
      
-
      The latter 2 coefficients are optional.  If not specified, the global
-LJ and Coulombic cutoffs specified in the pair_style command are used.
-If only one cutoff is specified, it is used as the cutoff for both LJ
-and Coulombic interactions for this type pair.  If both coefficients
-are specified, they are used as the LJ and Coulombic cutoffs for this
-type pair.
-
      
-
      For cg/cmm/coul/long only the LJ cutoff can be specified since a
-Coulombic cutoff cannot be specified for an individual I,J type pair.
-All type pairs use the same global Coulombic cutoff specified in the
-pair_style command.
-
      
-
      
-
-
      The cg/cmm/gpu and cg/cmm/coul/long/gpu styles 
-are identical to the cg/cmm and cg/cmm/coul/long
-styles, except that each processor off-loads its pairwise calculations to a 
-GPU chip. Depending on the hardware available on your system this can provide a
-speed-up.  See the Running on GPUs section of
-the manual for more details about hardware and software requirements
-for using GPUs.
-
      
-
      More details about these settings and various possible hardware
-configuration are in this section of the
-manual.
-
      
-
      Additional requirements in your input script to run with GPU-enabled styles
-are as follows:
-
      
-
      The newton pair setting must be off and
-fix gpu must be used. The fix controls the
-essential GPU selection and initialization steps.
-
      
-
      
-
-
      Mixing, shift, table, tail correction, restart, and rRESPA info:
-
      
-
      For atom type pairs I,J and I != J, the epsilon and sigma coefficients
-and cutoff distance for all of the cg/cmm pair styles cannot be mixed,
-since different pairs may have different exponents. So all parameters
-for all pairs have to be specified explicitly through the "pair_coeff"
-command. Defining then in a data file is also not supported, due to
-limitations of that file format.
-
      
-
      All of the cg/cmm pair styles support the
-pair_modify shift option for the energy of the
-Lennard-Jones portion of the pair interaction.
-
      
-
      The cg/cmm/coul/long pair styles support the
-pair_modify table option since they can tabulate
-the short-range portion of the long-range Coulombic interaction.
-
      
-
      All of the cg/cmm pair styles write their information to binary
-restart files, so pair_style and pair_coeff commands do
-not need to be specified in an input script that reads a restart file.
-
      
-
      The cg/cmm, cg/cmm/coul/cut and lj/cut/coul/long pair styles support 
-the use of the inner, middle, and outer keywords of the run_style
-respa command, meaning the pairwise forces can be
-partitioned by distance at different levels of the rRESPA hierarchy.
-See the run_style command for details.
-
      
-
      
-
-
      Restrictions:
-
      
-
      All of the cg/cmm pair styles are part of the "user-cg-cmm"
-package. They are only enabled if LAMMPS was built with that
-package. The cg/cmm/coul/long style also requires the "kspace"
-package to be built (which is enabled by default).  See the Making
-LAMMPS section for more info.
-
      
-
      On some 64-bit machines, compiling with -O3 appears to break the
-Coulombic tabling option used by the cg/cmm/coul/long style.  See
-the "Additional build tips" section of the Making LAMMPS documentation
-pages for workarounds on this issue.
-
      
-
      Related commands:
-
      
-
      pair_coeff, angle_style cg/cmm
-
      
-
      Default: none
-
      
-
      
-
-
-
-
      (Shinoda) Shinoda, DeVane, Klein, Mol Sim, 33, 27 (2007).
-
      
-
-
-
      (DeVane)  Shinoda, DeVane, Klein, Soft Matter, 4, 2453-2462 (2008).
-
      
-
diff --git a/doc/pair_cmm.txt b/doc/pair_cmm.txt
deleted file mode 100644
index ec5884c9a5..0000000000
--- a/doc/pair_cmm.txt
+++ /dev/null
@@ -1,199 +0,0 @@
-"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
-
-:link(lws,http://lammps.sandia.gov)
-:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
-
-:line
-
-pair_style cg/cmm command :h3
-pair_style cg/cmm/gpu command :h3
-pair_style cg/cmm/coul/cut command :h3
-pair_style cg/cmm/coul/long command :h3
-pair_style cg/cmm/coul/long/gpu command :h3
-
-[Syntax:]
-
-pair_style style args :pre
-
-style = {cg/cmm} or {cg/cmm/gpu} or {cg/cmm/coul/cut} or {cg/cmm/coul/long} or {cg/cmm/coul/long/gpu}
-args = list of arguments for a particular style :ul
-  {cg/cmm} args = cutoff
-    cutoff = global cutoff for Lennard Jones interactions (distance units)
-  {cg/cmm/gpu} args = cutoff
-    cutoff = global cutoff for Lennard Jones interactions (distance units)
-  {cg/cmm/coul/cut} args = cutoff (cutoff2) (kappa)
-    cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
-    cutoff2 = global cutoff for Coulombic (optional) (distance units)
-    kappa = Debye length (optional, defaults to 0.0 = disabled) (inverse distance units)
-  {cg/cmm/coul/long} args = cutoff (cutoff2)
-    cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
-    cutoff2 = global cutoff for Coulombic (optional) (distance units) :pre
-  {cg/cmm/coul/long/gpu} args = cutoff (cutoff2)
-    cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
-    cutoff2 = global cutoff for Coulombic (optional) (distance units) :pre
-
-[Examples:]
-
-pair_style cg/cmm 2.5
-pair_coeff 1 1 lj12_6 1 1.1 2.8 :pre
-
-pair_style cg/cmm/coul/cut 10.0 12.0
-pair_coeff 1 1 lj9_6  100.0 3.5 9.0
-pair_coeff 1 1 lj12_4 100.0 3.5 9.0 9.0 :pre
-
-pair_style cg/cmm/coul/long 10.0
-pair_style cg/cmm/coul/long 10.0 8.0
-pair_coeff 1 1 lj9_6 100.0 3.5 9.0 :pre
-
-[Description:]
-
-The {cg/cmm} styles compute a 9/6, 12/4, or 12/6 Lennard-Jones potential,
-given by
-
-:c,image(Eqs/pair_cmm.jpg)
-
-as required for the CMM Coarse-grained MD parametrization discussed in
-"(Shinoda)"_#Shinoda and "(DeVane)"_#DeVane.  Rc is the cutoff.
-
-Style {cg/cmm/gpu} is a GPU-enabled version of style {cg/cmm}.
-See more details below.
-
-Style {cg/cmm/coul/cut} adds a Coulombic pairwise interaction given by
-
-:c,image(Eqs/pair_coulomb.jpg)
-
-where C is an energy-conversion constant, Qi and Qj are the charges on
-the 2 atoms, and epsilon is the dielectric constant which can be set
-by the "dielectric"_dielectric.html command.  If one cutoff is
-specified in the pair_style command, it is used for both the LJ and
-Coulombic terms.  If two cutoffs are specified, they are used as
-cutoffs for the LJ and Coulombic terms respectively.
-
-This style also contains an additional exp() damping factor
-to the Coulombic term, given by
-
-:c,image(Eqs/pair_debye.jpg)
-
-where kappa is the Debye length (kappa=0.0 is the unscreened coulomb).
-This potential is another way to mimic the screening effect of a polar
-solvent.
-
-Style {cg/cmm/coul/long} computes the same Coulombic interactions as
-style {cg/cmm/coul/cut} except that an additional damping factor is
-applied to the Coulombic term so it can be used in conjunction with
-the "kspace_style"_kspace_style.html command and its {ewald} or {pppm}
-option.  The Coulombic cutoff specified for this style means that
-pairwise interactions within this distance are computed directly;
-interactions outside that distance are computed in reciprocal space.
-
-Style {cg/cmm/coul/long/gpu} is a GPU-enabled version of style {cg/cmm/coul/long}.
-See more details below.
-
-The following coefficients must be defined for each pair of atoms
-types via the "pair_coeff"_pair_coeff.html command as in the examples
-above, or in the data file or restart files read by the
-"read_data"_read_data.html or "read_restart"_read_restart.html
-commands, or by mixing as described below:
-
-cg_type (lj9_6, lj12_4, or lj12_6)
-epsilon (energy units)
-sigma (distance units)
-cutoff1 (distance units)
-cutoff2 (distance units) :ul
-
-Note that sigma is defined in the LJ formula as the zero-crossing
-distance for the potential, not as the energy minimum. The prefactors
-are chosen so that the potential minimum is at -epsilon.
-
-The latter 2 coefficients are optional.  If not specified, the global
-LJ and Coulombic cutoffs specified in the pair_style command are used.
-If only one cutoff is specified, it is used as the cutoff for both LJ
-and Coulombic interactions for this type pair.  If both coefficients
-are specified, they are used as the LJ and Coulombic cutoffs for this
-type pair.
-
-For {cg/cmm/coul/long} only the LJ cutoff can be specified since a
-Coulombic cutoff cannot be specified for an individual I,J type pair.
-All type pairs use the same global Coulombic cutoff specified in the
-pair_style command.
-
-:line
-
-The {cg/cmm/gpu} and {cg/cmm/coul/long/gpu} styles 
-are identical to the {cg/cmm} and {cg/cmm/coul/long}
-styles, except that each processor off-loads its pairwise calculations to a 
-GPU chip. Depending on the hardware available on your system this can provide a
-speed-up.  See the "Running on GPUs"_Section_start.html#2_8 section of
-the manual for more details about hardware and software requirements
-for using GPUs.
-
-More details about these settings and various possible hardware
-configuration are in "this section"_Section_start.html#2_8 of the
-manual.
-
-Additional requirements in your input script to run with GPU-enabled styles
-are as follows:
-
-The "newton pair"_newton.html setting must be {off} and
-"fix gpu"_fix_gpu.html must be used. The fix controls the
-essential GPU selection and initialization steps.
-
-:line
-
-[Mixing, shift, table, tail correction, restart, and rRESPA info]:
-
-For atom type pairs I,J and I != J, the epsilon and sigma coefficients
-and cutoff distance for all of the cg/cmm pair styles {cannot} be mixed,
-since different pairs may have different exponents. So all parameters
-for all pairs have to be specified explicitly through the "pair_coeff"
-command. Defining then in a data file is also not supported, due to
-limitations of that file format.
-
-All of the cg/cmm pair styles support the
-"pair_modify"_pair_modify.html shift option for the energy of the
-Lennard-Jones portion of the pair interaction.
-
-The {cg/cmm/coul/long} pair styles support the
-"pair_modify"_pair_modify.html table option since they can tabulate
-the short-range portion of the long-range Coulombic interaction.
-
-All of the cg/cmm pair styles write their information to "binary
-restart files"_restart.html, so pair_style and pair_coeff commands do
-not need to be specified in an input script that reads a restart file.
-
-The cg/cmm, cg/cmm/coul/cut and lj/cut/coul/long pair styles support 
-the use of the {inner}, {middle}, and {outer} keywords of the "run_style
-respa"_run_style.html command, meaning the pairwise forces can be
-partitioned by distance at different levels of the rRESPA hierarchy.
-See the "run_style"_run_style.html command for details.
-
-:line
-
-[Restrictions:]
-
-All of the cg/cmm pair styles are part of the "user-cg-cmm"
-package. They are only enabled if LAMMPS was built with that
-package. The {cg/cmm/coul/long} style also requires the "kspace"
-package to be built (which is enabled by default).  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
-
-On some 64-bit machines, compiling with -O3 appears to break the
-Coulombic tabling option used by the {cg/cmm/coul/long} style.  See
-the "Additional build tips" section of the Making LAMMPS documentation
-pages for workarounds on this issue.
-
-[Related commands:]
-
-"pair_coeff"_pair_coeff.html, "angle_style cg/cmm"_angle_cmm.html
-
-[Default:] none
-
-:line
-
-:link(Shinoda)
-[(Shinoda)] Shinoda, DeVane, Klein, Mol Sim, 33, 27 (2007).
-
-:link(DeVane)
-[(DeVane)]  Shinoda, DeVane, Klein, Soft Matter, 4, 2453-2462 (2008).
-
diff --git a/doc/pair_coeff.html b/doc/pair_coeff.html
index 36f8c74033..1c9c6777ec 100644
--- a/doc/pair_coeff.html
+++ b/doc/pair_coeff.html
@@ -40,7 +40,7 @@ can be used for each, as in the 1st example above.  I <= J is
 required.  LAMMPS sets the coefficients for the symmetric J,I
 interaction to the same values.
 
      
-
      A wild-card asterisk can be used in place of or in conjunction with the
+
      A wildcard asterisk can be used in place of or in conjunction with the
 I,J arguments to set the coefficients for multiple pairs of atom
 types.  This takes the form "*" or "*n" or "n*" or "m*n".  If N = the
 number of atom types, then an asterisk with no numeric values means all
@@ -87,13 +87,17 @@ the pair_style command, and coefficients specified by the associated
 
      
-
      • pair_style airebo - AI-REBO potential
+
 
        There are also additional pair styles submitted by users which are
 included in the LAMMPS distribution.  The list of these with links to
-the individual styles are given in the pair section of this
+the individual styles are given in the pair section of this
 page.
 
        
+
        There are also additional accelerated pair styles included in the
+LAMMPS distribution for faster performance on CPUs and GPUs.  The list
+of these with links to the individual styles are given in the pair
+section of this page.
+
        
 
        
 
 
        Restrictions:
diff --git a/doc/pair_coeff.txt b/doc/pair_coeff.txt
index 09c2dc401a..4c8ca53f58 100644
--- a/doc/pair_coeff.txt
+++ b/doc/pair_coeff.txt
@@ -37,7 +37,7 @@ can be used for each, as in the 1st example above.  I <= J is
 required.  LAMMPS sets the coefficients for the symmetric J,I
 interaction to the same values.
 
-A wild-card asterisk can be used in place of or in conjunction with the
+A wildcard asterisk can be used in place of or in conjunction with the
 I,J arguments to set the coefficients for multiple pairs of atom
 types.  This takes the form "*" or "*n" or "n*" or "m*n".  If N = the
 number of atom types, then an asterisk with no numeric values means all
@@ -84,13 +84,17 @@ the pair_style command, and coefficients specified by the associated
 "pair_style hybrid"_pair_hybrid.html - multiple styles of pairwise interactions
 "pair_style hybrid/overlay"_pair_hybrid.html - multiple styles of superposed pairwise interactions :ul
 
-"pair_style airebo"_pair_airebo.html - AI-REBO potential
+"pair_style adp"_pair_adp.html - angular dependent potential (ADP) of Mishin
+"pair_style airebo"_pair_airebo.html - AIREBO potential of Stuart
 "pair_style born"_pair_born.html - Born-Mayer-Huggins potential
 "pair_style born/coul/long"_pair_born.html - Born-Mayer-Huggins with long-range Coulomb
+"pair_style brownian"_pair_brownian.html - Brownian potential for Fast Lubrication Dynamics
+"pair_style brownian/poly"_pair_brownian.html - Brownian potential for Fast Lubrication Dynamics with polydispersity
 "pair_style buck"_pair_buck.html - Buckingham potential
 "pair_style buck/coul/cut"_pair_buck.html - Buckingham with cutoff Coulomb
 "pair_style buck/coul/long"_pair_buck.html - Buckingham with long-range Coulomb
 "pair_style colloid"_pair_colloid.html - integrated colloidal potential
+"pair_style comb"_pair_comb.html - charge-optimized many-body (COMB) potential
 "pair_style coul/cut"_pair_coul.html - cutoff Coulombic potential
 "pair_style coul/debye"_pair_coul.html - cutoff Coulombic potential with Debye screening
 "pair_style coul/long"_pair_coul.html - long-range Coulombic potential
@@ -99,63 +103,62 @@ the pair_style command, and coefficients specified by the associated
 "pair_style dpd/tstat"_pair_dpd.html - DPD thermostatting
 "pair_style dsmc"_pair_dsmc.html - Direct Simulation Monte Carlo (DSMC)
 "pair_style eam"_pair_eam.html - embedded atom method (EAM)
-"pair_style eam/opt"_pair_eam.html - optimized version of EAM
 "pair_style eam/alloy"_pair_eam.html - alloy EAM
-"pair_style eam/alloy/opt"_pair_eam.html - optimized version of alloy EAM
 "pair_style eam/fs"_pair_eam.html - Finnis-Sinclair EAM
-"pair_style eam/fs/opt"_pair_eam.html - optimized version of Finnis-Sinclair EAM
 "pair_style eim"_pair_eim.html - embedded ion method (EIM)
 "pair_style gauss"_pair_gauss.html - Gaussian potential
 "pair_style gayberne"_pair_gayberne.html - Gay-Berne ellipsoidal potential
-"pair_style gayberne/gpu"_pair_gayberne.html - GPU-enabled Gay-Berne ellipsoidal potential
 "pair_style gran/hertz/history"_pair_gran.html - granular potential with Hertzian interactions
 "pair_style gran/hooke"_pair_gran.html - granular potential with history effects
 "pair_style gran/hooke/history"_pair_gran.html - granular potential without history effects
 "pair_style hbond/dreiding/lj"_pair_hbond_dreiding.html - DREIDING hydrogen bonding LJ potential
 "pair_style hbond/dreiding/morse"_pair_hbond_dreiding.html - DREIDING hydrogen bonding Morse potential
+"pair_style line/lj"_pair_line_lj.html - LJ potential between line segments
 "pair_style lj/charmm/coul/charmm"_pair_charmm.html - CHARMM potential with cutoff Coulomb
 "pair_style lj/charmm/coul/charmm/implicit"_pair_charmm.html - CHARMM for implicit solvent
 "pair_style lj/charmm/coul/long"_pair_charmm.html - CHARMM with long-range Coulomb
-"pair_style lj/charmm/coul/long/gpu"_pair_charmm.html - GPU-enabled version of CHARMM with long-range Coulomb
-"pair_style lj/charmm/coul/long/opt"_pair_charmm.html - optimized version of CHARMM with long-range Coulomb
 "pair_style lj/class2"_pair_class2.html - COMPASS (class 2) force field with no Coulomb
 "pair_style lj/class2/coul/cut"_pair_class2.html - COMPASS with cutoff Coulomb
 "pair_style lj/class2/coul/long"_pair_class2.html - COMPASS with long-range Coulomb
 "pair_style lj/cut"_pair_lj.html - cutoff Lennard-Jones potential with no Coulomb
-"pair_style lj/cut/gpu"_pair_lj.html - GPU-enabled version of cutoff LJ
-"pair_style lj/cut/opt"_pair_lj.html - optimized version of cutoff LJ
 "pair_style lj/cut/coul/cut"_pair_lj.html - LJ with cutoff Coulomb
-"pair_style lj/cut/coul/cut/gpu"_pair_lj.html - GPU-enabled version of LJ with cutoff Coulomb
 "pair_style lj/cut/coul/debye"_pair_lj.html - LJ with Debye screening added to Coulomb
 "pair_style lj/cut/coul/long"_pair_lj.html - LJ with long-range Coulomb
-"pair_style lj/cut/coul/long/gpu"_pair_lj.html - GPU-enabled version of LJ with long-range Coulomb
 "pair_style lj/cut/coul/long/tip4p"_pair_lj.html - LJ with long-range Coulomb for TIP4P water
 "pair_style lj/expand"_pair_lj_expand.html - Lennard-Jones for variable size particles
 "pair_style lj/gromacs"_pair_gromacs.html - GROMACS-style Lennard-Jones potential
 "pair_style lj/gromacs/coul/gromacs"_pair_gromacs.html - GROMACS-style LJ and Coulombic potential
 "pair_style lj/smooth"_pair_lj_smooth.html - smoothed Lennard-Jones potential
-"pair_style lj96/cut"_pair_lj96_cut.html - Lennard-Jones 9/6 potential
-"pair_style lj96/cut/gpu"_pair_lj96_cut.html - GPU-enabled version of Lennard-Jones 9/6
+"pair_style lj96/cut"_pair_lj96.html - Lennard-Jones 9/6 potential
 "pair_style lubricate"_pair_lubricate.html - hydrodynamic lubrication forces
+"pair_style lubricate/poly"_pair_lubricate.html - hydrodynamic lubrication forces with polydispersity
+"pair_style lubricateU"_pair_lubricateU.html - hydrodynamic lubrication forces for Fast Lubrication Dynamics
+"pair_style lubricateU/poly"_pair_lubricateU.html - hydrodynamic lubrication forces for Fast Lubrication Dynamics with polydispersity
 "pair_style meam"_pair_meam.html - modified embedded atom method (MEAM)
 "pair_style morse"_pair_morse.html - Morse potential
-"pair_style morse/opt"_pair_morse.html - optimized version of Morse potential
 "pair_style peri/lps"_pair_peri.html - peridynamic LPS potential
 "pair_style peri/pmb"_pair_peri.html - peridynamic PMB potential
 "pair_style reax"_pair_reax.html - ReaxFF potential
+"pair_style rebo"_pair_airebo.html - 2nd-generation REBO potential of Brenner
 "pair_style resquared"_pair_resquared.html - Everaers RE-Squared ellipsoidal potential
 "pair_style soft"_pair_soft.html - Soft (cosine) potential
 "pair_style sw"_pair_sw.html - Stillinger-Weber 3-body potential
 "pair_style table"_pair_table.html - tabulated pair potential
 "pair_style tersoff"_pair_tersoff.html - Tersoff 3-body potential
 "pair_style tersoff/zbl"_pair_tersoff_zbl.html - Tersoff/ZBL 3-body potential
+"pair_style tri/lj"_pair_tri_lj.html - LJ potential between triangles
 "pair_style yukawa"_pair_yukawa.html - Yukawa potential
 "pair_style yukawa/colloid"_pair_yukawa_colloid.html - screened Yukawa potential for finite-size particles :ul
 
 There are also additional pair styles submitted by users which are
 included in the LAMMPS distribution.  The list of these with links to
 the individual styles are given in the pair section of "this
-page"_Section_commands.html#3_5.
+page"_Section_commands.html#cmd_5.
+
+There are also additional accelerated pair styles included in the
+LAMMPS distribution for faster performance on CPUs and GPUs.  The list
+of these with links to the individual styles are given in the pair
+section of "this page"_Section_commands.html#cmd_5.
 
 :line
 
diff --git a/doc/pair_colloid.html b/doc/pair_colloid.html
index 0e273b6a20..a1754fd5df 100644
--- a/doc/pair_colloid.html
+++ b/doc/pair_colloid.html
@@ -11,6 +11,8 @@
 
 
        pair_style colloid command 
 
        
+
        pair_style colloid/omp command 
+
        
 
        Syntax:
 
        
 
        pair_style colloid cutoff 
@@ -125,6 +127,28 @@ commands for efficiency: neighbor multi and
 
        
 
        
 
+
        Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
        
+
        These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
        
+
        You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
        
+
        See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
        
+
        
+
 
        Mixing, shift, table, tail correction, restart, rRESPA info:
 
        
 
        For atom type pairs I,J and I != J, the A, sigma, d1, and d2
@@ -155,10 +179,22 @@ to be specified in an input script that reads a restart file.
 
 
        Restrictions:
 
        
-
        This style is part of the "colloid" package.  It is only enabled if
-LAMMPS was built with that package.  See the Making
+
        This style is part of the COLLOID package.  It is only enabled if
+LAMMPS was built with that package.  See the Making
 LAMMPS section for more info.
 
        
+
        Normally, this pair style should be used with finite-size particles
+which have a diameter, e.g. see the atom_style
+sphere command.  However, this is not a requirement,
+since the only definition of particle size is via the pair_coeff
+parameters for each type.  In other words, the physical radius of the
+particle is ignored.  Thus you should insure that the d1,d2 parameters
+you specify are consistent with the physical size of the particles of
+that type.
+
        
+
        Per-particle polydispersity is not yet supported by this pair style;
+only per-type polydispersity is enabled via the pair_coeff parameters.
+
        
 
        Related commands:
 
        
 
        pair_coeff
diff --git a/doc/pair_colloid.txt b/doc/pair_colloid.txt
index 4c9fc3e029..8a442ea078 100644
--- a/doc/pair_colloid.txt
+++ b/doc/pair_colloid.txt
@@ -7,6 +7,7 @@
 :line
 
 pair_style colloid command :h3
+pair_style colloid/omp command :h3
 
 [Syntax:]
 
@@ -122,6 +123,28 @@ commands for efficiency: "neighbor multi"_neighbor.html and
 
 :line
 
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Mixing, shift, table, tail correction, restart, rRESPA info]:
 
 For atom type pairs I,J and I != J, the A, sigma, d1, and d2
@@ -152,9 +175,21 @@ This pair style can only be used via the {pair} keyword of the
 
 [Restrictions:]
 
-This style is part of the "colloid" package.  It is only enabled if
+This style is part of the COLLOID package.  It is only enabled if
 LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+Normally, this pair style should be used with finite-size particles
+which have a diameter, e.g. see the "atom_style
+sphere"_atom_style.html command.  However, this is not a requirement,
+since the only definition of particle size is via the pair_coeff
+parameters for each type.  In other words, the physical radius of the
+particle is ignored.  Thus you should insure that the d1,d2 parameters
+you specify are consistent with the physical size of the particles of
+that type.
+
+Per-particle polydispersity is not yet supported by this pair style;
+only per-type polydispersity is enabled via the pair_coeff parameters.
 
 [Related commands:]
 
diff --git a/doc/pair_comb.html b/doc/pair_comb.html
index d131c23f04..55ec1beb1e 100644
--- a/doc/pair_comb.html
+++ b/doc/pair_comb.html
@@ -11,6 +11,8 @@
 
 
        pair_style comb command 
 
        
+
        pair_style comb/omp command 
+
        
 
        Syntax:
 
        
 
        pair_style comb 
@@ -167,6 +169,28 @@ complex systems.  Note that alloys and complex systems require all
 
        
 
        
 
+
        Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
        
+
        These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
        
+
        You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
        
+
        See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
        
+
        
+
 
        Mixing, shift, table, tail correction, restart, rRESPA info:
 
        
 
        For atom type pairs I,J and I != J, where types I and J correspond to
@@ -190,9 +214,9 @@ restart file.
 
 
        Restrictions:
 
        
-
        This pair style is part of the "manybody" package.  It is only enabled
+
        This pair style is part of the MANYBODY package.  It is only enabled
 if LAMMPS was built with that package (which it is by default).  See
-the Making LAMMPS section for more info.
+the Making LAMMPS section for more info.
 
        
 
        This pair style requires the newton setting to be "on"
 for pair interactions.
@@ -228,7 +252,7 @@ Phillpot, Phys Rev B, 81, 125328 (2010).
 
        
 
 
-
        (Rick) S. W. Rick, S. J. Stuart, B. J. Berne, J Chem Phys 101, 16141
+
        (Rick) S. W. Rick, S. J. Stuart, B. J. Berne, J Chem Phys 101, 6141
 (1994).
 
        
 
diff --git a/doc/pair_comb.txt b/doc/pair_comb.txt
index 20c4f473c7..9ec7ede788 100644
--- a/doc/pair_comb.txt
+++ b/doc/pair_comb.txt
@@ -7,6 +7,7 @@
 :line
 
 pair_style comb command :h3
+pair_style comb/omp command :h3
 
 [Syntax:]
 
@@ -164,6 +165,28 @@ complex systems.  Note that alloys and complex systems require all
 
 :line
 
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Mixing, shift, table, tail correction, restart, rRESPA info]:
 
 For atom type pairs I,J and I != J, where types I and J correspond to
@@ -187,9 +210,9 @@ This pair style can only be used via the {pair} keyword of the
 
 [Restrictions:]
 
-This pair style is part of the "manybody" package.  It is only enabled
+This pair style is part of the MANYBODY package.  It is only enabled
 if LAMMPS was built with that package (which it is by default).  See
-the "Making LAMMPS"_Section_start.html#2_3 section for more info.
+the "Making LAMMPS"_Section_start.html#start_3 section for more info.
 
 This pair style requires the "newton"_newton.html setting to be "on"
 for pair interactions.
@@ -221,7 +244,7 @@ Phillpot, Phys Rev B, 81, 125328 (2010).
 [(Tersoff)] J. Tersoff, Phys Rev B, 37, 6991 (1988).
 
 :link(Rick)
-[(Rick)] S. W. Rick, S. J. Stuart, B. J. Berne, J Chem Phys 101, 16141
+[(Rick)] S. W. Rick, S. J. Stuart, B. J. Berne, J Chem Phys 101, 6141
 (1994).
 
 :link(Wolf)
diff --git a/doc/pair_coul.html b/doc/pair_coul.html
index c88c1564c2..9e09518801 100644
--- a/doc/pair_coul.html
+++ b/doc/pair_coul.html
@@ -11,15 +11,24 @@
 
 
        pair_style coul/cut command 
 
        
+
        pair_style coul/cut/omp command 
+
        
 
        pair_style coul/debye command 
 
        
+
        pair_style coul/debye/omp command 
+
        
 
        pair_style coul/long command 
 
        
+
        pair_style coul/long/omp command 
+
        
+
        pair_style coul/long/gpu command 
+
        
 
        Syntax:
 
        
 
        pair_style coul/cut cutoff
 pair_style coul/debye kappa cutoff
-pair_style coul/long cutoff 
+pair_style coul/long cutoff
+pair_style coul/long/gpu cutoff 
 
        
 
        • cutoff = global cutoff for Coulombic interactions
 
        • kappa = Debye length (inverse distance units) 
@@ -89,6 +98,28 @@ Coulombic cutoff specified in the pair_style command.
 
          
 
          
 
+
          Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
          
+
          These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
          
+
          You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
          
+
          See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
          
+
          
+
 
          Mixing, shift, table, tail correction, restart, rRESPA info:
 
          
 
          For atom type pairs I,J and I != J, the cutoff distance for the
@@ -118,15 +149,10 @@ to be specified in an input script that reads a restart file.
 
 
          Restrictions:
 
          
-
          The coul/long style is part of the "kspace" package.  It is only
+
          The coul/long style is part of the KSPACE package.  It is only
 enabled if LAMMPS was built with that package (which it is by
-default).  See the Making LAMMPS section for
-more info.
-
          
-
          On some 64-bit machines, compiling with -O3 appears to break the
-Coulombic tabling option used by the coul/long style.  See the
-"Additional build tips" section of the Making LAMMPS documentation
-pages for workarounds on this issue.
+default).  See the Making LAMMPS section
+for more info.
 
          
 
          Related commands:
 
          
diff --git a/doc/pair_coul.txt b/doc/pair_coul.txt
index 9c0de4176c..44168cd1c5 100644
--- a/doc/pair_coul.txt
+++ b/doc/pair_coul.txt
@@ -7,14 +7,19 @@
 :line
 
 pair_style coul/cut command :h3
+pair_style coul/cut/omp command :h3
 pair_style coul/debye command :h3
+pair_style coul/debye/omp command :h3
 pair_style coul/long command :h3
+pair_style coul/long/omp command :h3
+pair_style coul/long/gpu command :h3
 
 [Syntax:]
 
 pair_style coul/cut cutoff
 pair_style coul/debye kappa cutoff
-pair_style coul/long cutoff :pre
+pair_style coul/long cutoff
+pair_style coul/long/gpu cutoff :pre
 
 cutoff = global cutoff for Coulombic interactions
 kappa = Debye length (inverse distance units) :ul
@@ -84,6 +89,28 @@ Coulombic cutoff specified in the pair_style command.
 
 :line
 
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Mixing, shift, table, tail correction, restart, rRESPA info]:
 
 For atom type pairs I,J and I != J, the cutoff distance for the
@@ -113,15 +140,10 @@ This pair style can only be used via the {pair} keyword of the
 
 [Restrictions:]
 
-The {coul/long} style is part of the "kspace" package.  It is only
+The {coul/long} style is part of the KSPACE package.  It is only
 enabled if LAMMPS was built with that package (which it is by
-default).  See the "Making LAMMPS"_Section_start.html#2_3 section for
-more info.
-
-On some 64-bit machines, compiling with -O3 appears to break the
-Coulombic tabling option used by the {coul/long} style.  See the
-"Additional build tips" section of the Making LAMMPS documentation
-pages for workarounds on this issue.
+default).  See the "Making LAMMPS"_Section_start.html#start_3 section
+for more info.
 
 [Related commands:]
 
diff --git a/doc/pair_coul_diel.html b/doc/pair_coul_diel.html
index 405d3956d2..c7ce1de683 100644
--- a/doc/pair_coul_diel.html
+++ b/doc/pair_coul_diel.html
@@ -87,7 +87,7 @@ pressure.
 
          
 
          Restrictions:
 
          
-
          This style is part of the "user-gauss" package.  It is only enabled
+
          This style is part of the "user-misc" package.  It is only enabled
 if LAMMPS was built with that package.  See the Making
 LAMMPS section for more info.
 
          
diff --git a/doc/pair_coul_diel.txt b/doc/pair_coul_diel.txt
index e6ba96f64b..21cac35bf5 100644
--- a/doc/pair_coul_diel.txt
+++ b/doc/pair_coul_diel.txt
@@ -85,7 +85,7 @@ This pair style can only be used via the {pair} keyword of the
 
 [Restrictions:]
 
-This style is part of the "user-gauss" package.  It is only enabled
+This style is part of the "user-misc" package.  It is only enabled
 if LAMMPS was built with that package.  See the "Making
 LAMMPS"_Section_start.html#2_3 section for more info.
 
diff --git a/doc/pair_dipole.html b/doc/pair_dipole.html
index 0f8fb486ea..0c259887b2 100644
--- a/doc/pair_dipole.html
+++ b/doc/pair_dipole.html
@@ -11,10 +11,18 @@
 
 
          pair_style dipole/cut command 
 
          
+
          pair_style dipole/cut/omp command 
+
          
+
          pair_style dipole/sf command 
+
          
+
          pair_style dipole/sf/omp command 
+
          
 
          Syntax:
 
          
 
          pair_style dipole/cut cutoff (cutoff2) 
 
          
+
          pair_style dipole/sf cutoff (cutoff2) 
+
          
 
          • cutoff = global cutoff LJ (and Coulombic if only 1 arg) (distance units)
 
          • cutoff2 = global cutoff for Coulombic (optional) (distance units) 
 
          
@@ -24,6 +32,10 @@
 pair_coeff * * 1.0 1.0 
 pair_coeff 2 3 1.0 1.0 2.5 4.0 
 
        
+
        pair_style dipole/sf 9.0
+pair_coeff * * 1.0 1.0 
+pair_coeff 2 3 1.0 1.0 2.5 4.0 
+
        
 
        Description:
 
        
 
        Style dipole/cut computes interactions between pairs of particles
@@ -43,6 +55,37 @@ and force, Fij = -Fji as symmetric forces, and Tij != -Tji since the
 torques do not act symmetrically.  These formulas are discussed in
 (Allen) and in (Toukmaji).
 
        
+
        Style dipole/sf computes "shifted-force" interactions between pairs
+of particles that each have a charge and/or a point dipole moment. In
+general, a shifted-force potential is a (sligthly) modified potential
+containing extra terms that make both the energy and its derivative go
+to zero at the cutoff distance; this removes (cutoff-related) problems
+in energy conservation and any numerical instability in the equations
+of motion (Allen). Shifted-force interactions for the
+Lennard-Jones (E_LJ), charge-charge (Eqq), charge-dipole (Eqp),
+dipole-charge (Epq) and dipole-dipole (Epp) potentials are computed by
+these formulas for the energy (E), force (F), and torque (T) between
+particles I and J:
+
        
+
        
+
        
+
        
+
        
+
        where epsilon and sigma are the standard LJ parameters, r_c is the
+cutoff, qi and qj are the charges on the two particles, pi and pj are
+the dipole moment vectors of the two particles, r is their separation
+distance, and the vector r = Ri - Rj is the separation vector between
+the two particles.  Note that Eqq and Fqq are simply Coulombic energy
+and force, Fij = -Fji as symmetric forces, and Tij != -Tji since the
+torques do not act symmetrically.  The shifted-force formula for the
+Lennard-Jones potential is reported in (Stoddard).  The
+original (unshifted) formulas for the electrostatic potentials, forces
+and torques can be found in (Price).  The shifted-force
+electrostatic potentials have been obtained by applying equation 5.13
+of (Allen). The formulas for the corresponding forces and
+torques have been obtained by applying the 'chain rule' as in appendix
+C.3 of (Allen).
+
        
 
        If one cutoff is specified in the pair_style command, it is used for
 both the LJ and Coulombic (q,p) terms.  If two cutoffs are specified,
 they are used as cutoffs for the LJ and Coulombic (q,p) terms
@@ -81,6 +124,28 @@ type pair.
 
        
 
        
 
+
        Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
        
+
        These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
        
+
        You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
        
+
        See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
        
+
        
+
 
        Mixing, shift, table, tail correction, restart, rRESPA info:
 
        
 
        For atom type pairs I,J and I != J, the epsilon and sigma coefficients
@@ -93,9 +158,9 @@ is an energy value mixed like a LJ epsilon.  D1 and d2 are distance
 values and are mixed like sigma.  The default mix value is
 geometric.  See the "pair_modify" command for details.
 
        
-
        This pair style supports the pair_modify shift
-option for the energy of the Lennard-Jones portion of the pair
-interaction.
+
        This pair style does not support the pair_modify 
+shift option for the energy of the Lennard-Jones portion of the pair
+interaction; such energy goes to zero at the cutoff by construction.
 
        
 
        The pair_modify table option is not relevant
 for this pair style.
@@ -114,8 +179,12 @@ to be specified in an input script that reads a restart file.
 
        
 
        Restrictions:
 
        
-
        This style is part of the "dipole" package.  It is only enabled if
-LAMMPS was built with that package.  See the Making
+
        The dipole/cut style is part of the DIPOLE package.  It is only
+enabled if LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
        
+
        The dipole/sf style is part of the USER-MISC package.  It is only
+enabled if LAMMPS was built with that package.  See the Making
 LAMMPS section for more info.
 
        
 
        Related commands:
@@ -136,4 +205,12 @@ Clarendon Press, Oxford, 1987.
 
        (Toukmaji) Toukmaji, Sagui, Board, and Darden, J Chem Phys, 113,
 10913 (2000).
 
        
+
+
+
        (Stoddard) Stoddard and Ford, Phys Rev A, 8, 1504 (1973).
+
        
+
+
+
        (Price) Price, Stone and Alderton, Mol Phys, 52, 987 (1984).
+
        
 
diff --git a/doc/pair_dipole.txt b/doc/pair_dipole.txt
index ca1b843c6d..d71ffef2e0 100755
--- a/doc/pair_dipole.txt
+++ b/doc/pair_dipole.txt
@@ -7,10 +7,14 @@
 :line
 
 pair_style dipole/cut command :h3
+pair_style dipole/cut/omp command :h3
+pair_style dipole/sf command :h3
+pair_style dipole/sf/omp command :h3
 
 [Syntax:]
 
 pair_style dipole/cut cutoff (cutoff2) :pre
+pair_style dipole/sf cutoff (cutoff2) :pre
 
 cutoff = global cutoff LJ (and Coulombic if only 1 arg) (distance units)
 cutoff2 = global cutoff for Coulombic (optional) (distance units) :ul
@@ -21,6 +25,10 @@ pair_style dipole/cut 10.0
 pair_coeff * * 1.0 1.0 
 pair_coeff 2 3 1.0 1.0 2.5 4.0 :pre
 
+pair_style dipole/sf 9.0
+pair_coeff * * 1.0 1.0 
+pair_coeff 2 3 1.0 1.0 2.5 4.0 :pre
+
 [Description:]
 
 Style {dipole/cut} computes interactions between pairs of particles
@@ -40,6 +48,36 @@ and force, Fij = -Fji as symmetric forces, and Tij != -Tji since the
 torques do not act symmetrically.  These formulas are discussed in
 "(Allen)"_#Allen and in "(Toukmaji)"_#Toukmaji.
 
+Style {dipole/sf} computes "shifted-force" interactions between pairs
+of particles that each have a charge and/or a point dipole moment. In
+general, a shifted-force potential is a (sligthly) modified potential
+containing extra terms that make both the energy and its derivative go
+to zero at the cutoff distance; this removes (cutoff-related) problems
+in energy conservation and any numerical instability in the equations
+of motion "(Allen)"_#Allen. Shifted-force interactions for the
+Lennard-Jones (E_LJ), charge-charge (Eqq), charge-dipole (Eqp),
+dipole-charge (Epq) and dipole-dipole (Epp) potentials are computed by
+these formulas for the energy (E), force (F), and torque (T) between
+particles I and J:
+
+:c,image(Eqs/pair_dipole_sf.jpg)
+:c,image(Eqs/pair_dipole_sf2.jpg)
+
+where epsilon and sigma are the standard LJ parameters, r_c is the
+cutoff, qi and qj are the charges on the two particles, pi and pj are
+the dipole moment vectors of the two particles, r is their separation
+distance, and the vector r = Ri - Rj is the separation vector between
+the two particles.  Note that Eqq and Fqq are simply Coulombic energy
+and force, Fij = -Fji as symmetric forces, and Tij != -Tji since the
+torques do not act symmetrically.  The shifted-force formula for the
+Lennard-Jones potential is reported in "(Stoddard)"_#Stoddard.  The
+original (unshifted) formulas for the electrostatic potentials, forces
+and torques can be found in "(Price)"_#Price.  The shifted-force
+electrostatic potentials have been obtained by applying equation 5.13
+of "(Allen)"_#Allen. The formulas for the corresponding forces and
+torques have been obtained by applying the 'chain rule' as in appendix
+C.3 of "(Allen)"_#Allen.
+
 If one cutoff is specified in the pair_style command, it is used for
 both the LJ and Coulombic (q,p) terms.  If two cutoffs are specified,
 they are used as cutoffs for the LJ and Coulombic (q,p) terms
@@ -78,6 +116,28 @@ type pair.
 
 :line
 
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Mixing, shift, table, tail correction, restart, rRESPA info]:
 
 For atom type pairs I,J and I != J, the epsilon and sigma coefficients
@@ -90,9 +150,9 @@ is an energy value mixed like a LJ epsilon.  D1 and d2 are distance
 values and are mixed like sigma.  The default mix value is
 {geometric}.  See the "pair_modify" command for details.
 
-This pair style supports the "pair_modify"_pair_modify.html shift
-option for the energy of the Lennard-Jones portion of the pair
-interaction.
+This pair style does not support the "pair_modify"_pair_modify.html 
+shift option for the energy of the Lennard-Jones portion of the pair
+interaction; such energy goes to zero at the cutoff by construction.
 
 The "pair_modify"_pair_modify.html table option is not relevant
 for this pair style.
@@ -111,9 +171,13 @@ This pair style can only be used via the {pair} keyword of the
 
 [Restrictions:]
 
-This style is part of the "dipole" package.  It is only enabled if
-LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+The {dipole/cut} style is part of the DIPOLE package.  It is only
+enabled if LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+The {dipole/sf} style is part of the USER-MISC package.  It is only
+enabled if LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
 
 [Related commands:]
 
@@ -130,3 +194,9 @@ Clarendon Press, Oxford, 1987.
 :link(Toukmaji)
 [(Toukmaji)] Toukmaji, Sagui, Board, and Darden, J Chem Phys, 113,
 10913 (2000).
+
+:link(Stoddard)
+[(Stoddard)] Stoddard and Ford, Phys Rev A, 8, 1504 (1973).
+
+:link(Price)
+[(Price)] Price, Stone and Alderton, Mol Phys, 52, 987 (1984).
diff --git a/doc/pair_dpd.html b/doc/pair_dpd.html
index 065b8c73d3..40d1dae1f0 100644
--- a/doc/pair_dpd.html
+++ b/doc/pair_dpd.html
@@ -11,8 +11,12 @@
 
 
        pair_style dpd command 
 
        
+
        pair_style dpd/omp command 
+
        
 
        pair_style dpd/tstat command 
 
        
+
        pair_style dpd/tstat/omp command 
+
        
 
        Syntax:
 
        
 
        pair_style dpd T cutoff seed
@@ -94,6 +98,28 @@ except that A is not included.
 
        
 
        
 
+
        Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
        
+
        These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
        
+
        You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
        
+
        See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
        
+
        
+
 
        Mixing, shift, table, tail correction, restart, rRESPA info:
 
        
 
        These pair styles do not support mixing.  Thus, coefficients for all
diff --git a/doc/pair_dpd.txt b/doc/pair_dpd.txt
index 4b2d1081d6..2b60a59375 100644
--- a/doc/pair_dpd.txt
+++ b/doc/pair_dpd.txt
@@ -7,7 +7,9 @@
 :line
 
 pair_style dpd command :h3
+pair_style dpd/omp command :h3
 pair_style dpd/tstat command :h3
+pair_style dpd/tstat/omp command :h3
 
 [Syntax:]
 
@@ -90,6 +92,28 @@ except that A is not included.
 
 :line
 
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Mixing, shift, table, tail correction, restart, rRESPA info]:
 
 These pair styles do not support mixing.  Thus, coefficients for all
diff --git a/doc/pair_dsmc.html b/doc/pair_dsmc.html
index 573d85f49b..11d1481d5d 100644
--- a/doc/pair_dsmc.html
+++ b/doc/pair_dsmc.html
@@ -122,8 +122,8 @@ continued past the restart time.
 
 
        Restrictions:
 
        
-
        This style is part of the "dsmc" package.  It is only enabled if
-LAMMPS was built with that package.  See the Making
+
        This style is part of the MC package.  It is only enabled if LAMMPS
+was built with that package.  See the Making
 LAMMPS section for more info.
 
        
 
        Related commands:
diff --git a/doc/pair_dsmc.txt b/doc/pair_dsmc.txt
index 00988a0264..0f430d394a 100644
--- a/doc/pair_dsmc.txt
+++ b/doc/pair_dsmc.txt
@@ -119,9 +119,9 @@ This pair style can only be used via the {pair} keyword of the
 
 [Restrictions:]
 
-This style is part of the "dsmc" package.  It is only enabled if
-LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+This style is part of the MC 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:]
 
diff --git a/doc/pair_eam.html b/doc/pair_eam.html
index 1700bb37c6..4f695c52e0 100644
--- a/doc/pair_eam.html
+++ b/doc/pair_eam.html
@@ -11,41 +11,52 @@
 
 
        pair_style eam command 
 
        
+
        pair_style eam/cuda command 
+
        
+
        pair_style eam/omp command 
+
        
 
        pair_style eam/opt command 
 
        
 
        pair_style eam/alloy command 
 
        
+
        pair_style eam/alloy/cuda command 
+
        
+
        pair_style eam/alloy/omp command 
+
        
 
        pair_style eam/alloy/opt command 
 
        
 
        pair_style eam/cd command 
 
        
+
        pair_style eam/cd/omp command 
+
        
 
        pair_style eam/fs command 
 
        
+
        pair_style eam/fs/cuda command 
+
        
+
        pair_style eam/fs/omp command 
+
        
 
        pair_style eam/fs/opt command 
 
        
 
        Syntax:
 
        
 
        pair_style style 
 
        
-
        • style = eam or eam/alloy or eam/cd or eam/fs or eam/opt or eam/alloy/opt or eam/fs/opt 
+
          • style = eam or eam/alloy or eam/cd or eam/fs 
 
          
 
          Examples:
 
          
 
          pair_style eam
-pair_style eam/opt
 pair_coeff * * cuu3
 pair_coeff 1*3 1*3 niu3.eam 
 
          
 
          pair_style eam/alloy
-pair_style eam/alloy/opt
-pair_coeff * * ../potentials/nialhjea.eam.alloy Ni Al Ni Ni 
+pair_coeff * * ../potentials/NiAlH_jea.eam.alloy Ni Al Ni Ni 
 
          
 
          pair_style eam/cd
 pair_coeff * * ../potentials/FeCr.cdeam Fe Cr 
 
          
 
          pair_style eam/fs
-pair_style eam/fs/opt
-pair_coeff * * nialhjea.eam.fs Ni Al Ni Ni 
+pair_coeff * * NiAlH_jea.eam.fs Ni Al Ni Ni 
 
          
 
          Description:
 
          
@@ -62,11 +73,6 @@ nature of the EAM potential is a result of the embedding energy term.
 Both summations in the formula are over all neighbors J of atom I
 within the cutoff distance.
 
          
-
          Style eam/opt is an optimized version of style eam that should
-give identical answers.  Depending on system size and the processor
-you are running on, it may be 5-25% faster (for the pairwise portion
-of the run time).
-
          
 
          The cutoff distance and the tabulated values of the functionals F,
 rho, and phi are listed in one or more files which are specified by
 the pair_coeff command.  These are ASCII text files
@@ -185,11 +191,6 @@ above, setfl files contain explicit tabulated values for alloy
 interactions.  Thus they allow more generality than funcfl files for
 modeling alloys.
 
          
-
          Style eam/alloy/opt is an optimized version of style eam/alloy
-that should give identical answers.  Depending on system size and the
-processor you are running on, it may be 5-25% faster (for the pairwise
-portion of the run time).
-
          
 
          For style eam/alloy, potential values are read from a file that is
 in the DYNAMO multi-element setfl format, except that element names
 (Ni, Cu, etc) are added to one of the lines in the file.  If the
@@ -206,13 +207,13 @@ where N is the number of LAMMPS atom types:
 
          • filename
 
          • N element names = mapping of setfl elements to atom types 
 
          
-
          As an example, the potentials/nialhjea setfl file has tabulated EAM
-values for 3 elements and their alloy interactions: Ni, Al, and H.  If
-your LAMMPS simulation has 4 atoms types and you want the 1st 3 to be
-Ni, and the 4th to be Al, you would use the following pair_coeff
-command:
+
          As an example, the potentials/NiAlH_jea.eam.alloy file is a setfl
+file which has tabulated EAM values for 3 elements and their alloy
+interactions: Ni, Al, and H.  If your LAMMPS simulation has 4 atoms
+types and you want the 1st 3 to be Ni, and the 4th to be Al, you would
+use the following pair_coeff command:
 
          
-
          pair_coeff * * nialhjea.eam.alloy Ni Ni Ni Al 
+
          pair_coeff * * NiAlH_jea.eam.alloy Ni Ni Ni Al 
 
          
 
          The 1st 2 arguments must be * * so as to span all LAMMPS atom types.
 The first three Ni arguments map LAMMPS atom types 1,2,3 to the Ni
@@ -310,11 +311,6 @@ so that different elements can contribute differently to the total
 electron density at an atomic site depending on the identity of the
 element at that atomic site.
 
          
-
          Style eam/fs/opt is an optimized version of style eam/fs that
-should give identical answers.  Depending on system size and the
-processor you are running on, it may be 5-25% faster (for the pairwise
-portion of the run time).
-
          
 
          The associated pair_coeff command for style eam/fs
 reads a DYNAMO setfl file that has been extended to include
 additional rho_alpha_beta arrays of tabulated values.  A discussion of
@@ -329,7 +325,7 @@ FS potential files.
 
          For style eam/fs, the form of the pair_coeff command is exactly the
 same as for style eam/alloy, e.g.
 
          
-
          pair_coeff * * nialhjea.eam.fs Ni Ni Ni Al 
+
          pair_coeff * * NiAlH_jea.eam.fs Ni Ni Ni Al 
 
          
 
          where there are N additional arguments after the filename, where N is
 the number of LAMMPS atom types.  The N values determine the mapping
@@ -377,6 +373,28 @@ are listed.
 
          
 
          
 
+
          Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
          
+
          These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
          
+
          You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
          
+
          See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
          
+
          
+
 
          Mixing, shift, table, tail correction, restart, rRESPA info:
 
          
 
          For atom type pairs I,J and I != J, where types I and J correspond to
@@ -400,19 +418,15 @@ an input script that reads a restart file.
 
 
          Restrictions:
 
          
-
          All of these styles except those ending in opt and the eam/cd
-style are part of the "manybody" package.  They are only enabled if
-LAMMPS was built with that package (which it is by default).
-
          
-
          The styles ending in opt are part of the "opt" package and also
-require the "manybody" package.  They are only enabled if LAMMPS was
-built with those packages.  See the Making
+
          All of these styles except the eam/cd style are part of the MANYBODY
+package.  They are only enabled if LAMMPS was built with that package
+(which it is by default).  See the Making
 LAMMPS section for more info.
 
          
-
          The eam/cd style is part of the "user-cd-eam" package and also
-requires the "manybody" package.  It is only enabled if LAMMPS was
-built with those packages.  See the Making
-LAMMPS section for more info.
+
          The eam/cd style is part of the USER-MISC package and also requires
+the MANYBODY package.  It is only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
 
          
 
          Related commands:
 
          
diff --git a/doc/pair_eam.txt b/doc/pair_eam.txt
index 35e0114cb7..d0b06bf07b 100644
--- a/doc/pair_eam.txt
+++ b/doc/pair_eam.txt
@@ -7,36 +7,40 @@
 :line
 
 pair_style eam command :h3
+pair_style eam/cuda command :h3
+pair_style eam/omp command :h3
 pair_style eam/opt command :h3
 pair_style eam/alloy command :h3
+pair_style eam/alloy/cuda command :h3
+pair_style eam/alloy/omp command :h3
 pair_style eam/alloy/opt command :h3
 pair_style eam/cd command :h3
+pair_style eam/cd/omp command :h3
 pair_style eam/fs command :h3
+pair_style eam/fs/cuda command :h3
+pair_style eam/fs/omp command :h3
 pair_style eam/fs/opt command :h3
 
 [Syntax:]
 
 pair_style style :pre
 
-style = {eam} or {eam/alloy} or {eam/cd} or {eam/fs} or {eam/opt} or {eam/alloy/opt} or {eam/fs/opt} :ul
+style = {eam} or {eam/alloy} or {eam/cd} or {eam/fs} :ul
 
 [Examples:]
 
 pair_style eam
-pair_style eam/opt
 pair_coeff * * cuu3
 pair_coeff 1*3 1*3 niu3.eam :pre
 
 pair_style eam/alloy
-pair_style eam/alloy/opt
-pair_coeff * * ../potentials/nialhjea.eam.alloy Ni Al Ni Ni :pre
+pair_coeff * * ../potentials/NiAlH_jea.eam.alloy Ni Al Ni Ni :pre
 
 pair_style eam/cd
 pair_coeff * * ../potentials/FeCr.cdeam Fe Cr :pre
 
 pair_style eam/fs
-pair_style eam/fs/opt
-pair_coeff * * nialhjea.eam.fs Ni Al Ni Ni :pre
+pair_coeff * * NiAlH_jea.eam.fs Ni Al Ni Ni :pre
 
 [Description:]
 
@@ -53,11 +57,6 @@ nature of the EAM potential is a result of the embedding energy term.
 Both summations in the formula are over all neighbors J of atom I
 within the cutoff distance.
 
-Style {eam/opt} is an optimized version of style {eam} that should
-give identical answers.  Depending on system size and the processor
-you are running on, it may be 5-25% faster (for the pairwise portion
-of the run time).
-
 The cutoff distance and the tabulated values of the functionals F,
 rho, and phi are listed in one or more files which are specified by
 the "pair_coeff"_pair_coeff.html command.  These are ASCII text files
@@ -176,11 +175,6 @@ above, {setfl} files contain explicit tabulated values for alloy
 interactions.  Thus they allow more generality than {funcfl} files for
 modeling alloys.
 
-Style {eam/alloy/opt} is an optimized version of style {eam/alloy}
-that should give identical answers.  Depending on system size and the
-processor you are running on, it may be 5-25% faster (for the pairwise
-portion of the run time).
-
 For style {eam/alloy}, potential values are read from a file that is
 in the DYNAMO multi-element {setfl} format, except that element names
 (Ni, Cu, etc) are added to one of the lines in the file.  If the
@@ -197,13 +191,13 @@ where N is the number of LAMMPS atom types:
 filename
 N element names = mapping of {setfl} elements to atom types :ul
 
-As an example, the potentials/nialhjea {setfl} file has tabulated EAM
-values for 3 elements and their alloy interactions: Ni, Al, and H.  If
-your LAMMPS simulation has 4 atoms types and you want the 1st 3 to be
-Ni, and the 4th to be Al, you would use the following pair_coeff
-command:
+As an example, the potentials/NiAlH_jea.eam.alloy file is a {setfl}
+file which has tabulated EAM values for 3 elements and their alloy
+interactions: Ni, Al, and H.  If your LAMMPS simulation has 4 atoms
+types and you want the 1st 3 to be Ni, and the 4th to be Al, you would
+use the following pair_coeff command:
 
-pair_coeff * * nialhjea.eam.alloy Ni Ni Ni Al :pre
+pair_coeff * * NiAlH_jea.eam.alloy Ni Ni Ni Al :pre
 
 The 1st 2 arguments must be * * so as to span all LAMMPS atom types.
 The first three Ni arguments map LAMMPS atom types 1,2,3 to the Ni
@@ -301,11 +295,6 @@ so that different elements can contribute differently to the total
 electron density at an atomic site depending on the identity of the
 element at that atomic site.
 
-Style {eam/fs/opt} is an optimized version of style {eam/fs} that
-should give identical answers.  Depending on system size and the
-processor you are running on, it may be 5-25% faster (for the pairwise
-portion of the run time).
-
 The associated "pair_coeff"_pair_coeff.html command for style {eam/fs}
 reads a DYNAMO {setfl} file that has been extended to include
 additional rho_alpha_beta arrays of tabulated values.  A discussion of
@@ -320,7 +309,7 @@ FS potential files.
 For style {eam/fs}, the form of the pair_coeff command is exactly the
 same as for style {eam/alloy}, e.g.
 
-pair_coeff * * nialhjea.eam.fs Ni Ni Ni Al :pre
+pair_coeff * * NiAlH_jea.eam.fs Ni Ni Ni Al :pre
 
 where there are N additional arguments after the filename, where N is
 the number of LAMMPS atom types.  The N values determine the mapping
@@ -368,6 +357,29 @@ are listed.
 
 :line
 
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Mixing, shift, table, tail correction, restart, rRESPA info]:
 
 For atom type pairs I,J and I != J, where types I and J correspond to
@@ -391,19 +403,15 @@ The eam pair styles can only be used via the {pair} keyword of the
 
 [Restrictions:]
 
-All of these styles except those ending in {opt} and the {eam/cd}
-style are part of the "manybody" package.  They are only enabled if
-LAMMPS was built with that package (which it is by default).
+All of these styles except the {eam/cd} style are part of the MANYBODY
+package.  They are only enabled if LAMMPS was built with that package
+(which it is by default).  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
 
-The styles ending in {opt} are part of the "opt" package and also
-require the "manybody" package.  They are only enabled if LAMMPS was
-built with those packages.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
-
-The {eam/cd} style is part of the "user-cd-eam" package and also
-requires the "manybody" package.  It is only enabled if LAMMPS was
-built with those packages.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+The {eam/cd} style is part of the USER-MISC package and also requires
+the MANYBODY package.  It is only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
 
 [Related commands:]
 
diff --git a/doc/pair_edip.html b/doc/pair_edip.html
new file mode 100644
index 0000000000..1c09c8ed49
--- /dev/null
+++ b/doc/pair_edip.html
@@ -0,0 +1,170 @@
+
+
          LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
          
+
+
+
+
+
+
+
          
+
+
          pair_style edip command 
+
          
+
          Syntax:
+
          
+
          pair_style edip 
+
          
+
          pair_style edip/omp 
+
          
+
          Examples:
+
          
+
          pair_style edip
+pair_coeff * * Si.edip Si
+
          
+
          Description:
+
          
+
          The edip style computes a 3-body EDIP potential which is
+popular for modeling silicon materials where it can have advantages
+over other models such as the Stillinger-Weber or
+Tersoff potentials.  In EDIP, the energy E of a
+system of atoms is
+
          
+
          
+
          
+
          where phi2 is a two-body term and phi3 is a three-body term.  The
+summations in the formula are over all neighbors J and K of atom I
+within a cutoff distance = a.
+Both terms depend on the local environment of atom I through its
+effective coordination number defined by Z, which is unity for a
+cutoff distance < c and gently goes to 0 at distance = a.
+
          
+
          Only a single pair_coeff command is used with the edip style which
+specifies a EDIP potential file with parameters for all
+needed elements.  These are mapped to LAMMPS atom types by specifying
+N additional arguments after the filename in the pair_coeff command,
+where N is the number of LAMMPS atom types:
+
          
+
          • filename
+
          • N element names = mapping of EDIP elements to atom types 
+
          
+
          As an example, imagine a file Si.edip has EDIP values for Si.
+
          
+
          EDIP files in the potentials directory of the LAMMPS
+distribution have a ".edip" suffix.  Lines that are not blank or
+comments (starting with #) define parameters for a triplet of
+elements.  The parameters in a single entry correspond to the two-body
+and three-body coefficients in the formula above:
+
          
+
          • element 1 (the center atom in a 3-body interaction)
+
          • element 2
+
          • element 3
+
          • A (energy units)
+
          • B (distance units)
+
          • cutoffA (distance units)
+
          • cutoffC (distance units)
+
          • alpha
+
          • beta
+
          • eta
+
          • gamma (distance units)
+
          • lambda (energy units)
+
          • mu
+
          • tho
+
          • sigma (distance units)
+
          • Q0
+
          • u1
+
          • u2
+
          • u3
+
          • u4 
+
          
+
          The A, B, beta, sigma parameters are used only for two-body interactions.
+The eta, gamma, lambda, mu, Q0 and all u1 to u4 parameters are used only 
+for three-body interactions. The alpha and cutoffC parameters are used
+for the coordination environment function only.
+
          
+
          The EDIP potential file must contain entries for all the
+elements listed in the pair_coeff command.  It can also contain
+entries for additional elements not being used in a particular
+simulation; LAMMPS ignores those entries.
+
          
+
          For a single-element simulation, only a single entry is required
+(e.g. SiSiSi).  For a two-element simulation, the file must contain 8
+entries (for SiSiSi, SiSiC, SiCSi, SiCC, CSiSi, CSiC, CCSi, CCC), that
+specify EDIP parameters for all permutations of the two elements
+interacting in three-body configurations.  Thus for 3 elements, 27
+entries would be required, etc.
+
          
+
          At the moment, only a single element parametrization is 
+implemented. However, the author is not aware of other 
+multi-element EDIP parametrizations. If you know any and 
+you are interest in that, please contact the author of
+the EDIP package.
+
          
+
          
+
+
          Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
          
+
          These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
          
+
          You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
          
+
          See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
          
+
          
+
+
          Mixing, shift, table, tail correction, restart, rRESPA info:
+
          
+
          This pair style does not support the pair_modify
+shift, table, and tail options.
+
          
+
          This pair style does not write its information to binary restart
+files, since it is stored in potential files.  Thus, you
+need to re-specify the pair_style and pair_coeff commands in an input
+script that reads a restart file.
+
          
+
          This pair style can only be used via the pair keyword of the
+run_style respa command.  It does not support the
+inner, middle, outer keywords.
+
          
+
          
+
+
          Restrictions:
+
          
+
          This angle style can only be used if LAMMPS was built with the
+USER-MISC package.  See the Making LAMMPS
+section for more info on packages.
+
          
+
          This pair style requires the newton setting to be "on"
+for pair interactions.
+
          
+
          The EDIP potential files provided with LAMMPS (see the potentials directory) 
+are parameterized for metal units.
+You can use the SW potential with any LAMMPS units, but you would need
+to create your own EDIP potential file with coefficients listed in the
+appropriate units if your simulation doesn't use "metal" units.
+
          
+
          Related commands:
+
          
+
          pair_coeff
+
          
+
          Default: none
+
          
+
          
+
+
+
+
          (EDIP) J. F. Justo et al., Phys. Rev. B 58, 2539 (1998).
+
          
+
diff --git a/doc/pair_edip.txt b/doc/pair_edip.txt
new file mode 100644
index 0000000000..3494ce68f8
--- /dev/null
+++ b/doc/pair_edip.txt
@@ -0,0 +1,163 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+pair_style edip command :h3
+
+[Syntax:]
+
+pair_style edip :pre
+pair_style edip/omp :pre
+
+[Examples:]
+
+pair_style edip
+pair_coeff * * Si.edip Si
+
+[Description:]
+
+The {edip} style computes a 3-body "EDIP"_#EDIP potential which is
+popular for modeling silicon materials where it can have advantages
+over other models such as the "Stillinger-Weber"_pair_sw.html or
+"Tersoff"_pair_tersoff.html potentials.  In EDIP, the energy E of a
+system of atoms is
+
+:c,image(Eqs/pair_edip.jpg)
+
+where phi2 is a two-body term and phi3 is a three-body term.  The
+summations in the formula are over all neighbors J and K of atom I
+within a cutoff distance = a.
+Both terms depend on the local environment of atom I through its
+effective coordination number defined by Z, which is unity for a
+cutoff distance < c and gently goes to 0 at distance = a.
+
+Only a single pair_coeff command is used with the {edip} style which
+specifies a EDIP potential file with parameters for all
+needed elements.  These are mapped to LAMMPS atom types by specifying
+N additional arguments after the filename in the pair_coeff command,
+where N is the number of LAMMPS atom types:
+
+filename
+N element names = mapping of EDIP elements to atom types :ul
+
+As an example, imagine a file Si.edip has EDIP values for Si.
+
+EDIP files in the {potentials} directory of the LAMMPS
+distribution have a ".edip" suffix.  Lines that are not blank or
+comments (starting with #) define parameters for a triplet of
+elements.  The parameters in a single entry correspond to the two-body
+and three-body coefficients in the formula above:
+
+element 1 (the center atom in a 3-body interaction)
+element 2
+element 3
+A (energy units)
+B (distance units)
+cutoffA (distance units)
+cutoffC (distance units)
+alpha
+beta
+eta
+gamma (distance units)
+lambda (energy units)
+mu
+tho
+sigma (distance units)
+Q0
+u1
+u2
+u3
+u4 :ul
+
+The A, B, beta, sigma parameters are used only for two-body interactions.
+The eta, gamma, lambda, mu, Q0 and all u1 to u4 parameters are used only 
+for three-body interactions. The alpha and cutoffC parameters are used
+for the coordination environment function only.
+
+The EDIP potential file must contain entries for all the
+elements listed in the pair_coeff command.  It can also contain
+entries for additional elements not being used in a particular
+simulation; LAMMPS ignores those entries.
+
+For a single-element simulation, only a single entry is required
+(e.g. SiSiSi).  For a two-element simulation, the file must contain 8
+entries (for SiSiSi, SiSiC, SiCSi, SiCC, CSiSi, CSiC, CCSi, CCC), that
+specify EDIP parameters for all permutations of the two elements
+interacting in three-body configurations.  Thus for 3 elements, 27
+entries would be required, etc.
+
+At the moment, only a single element parametrization is 
+implemented. However, the author is not aware of other 
+multi-element EDIP parametrizations. If you know any and 
+you are interest in that, please contact the author of
+the EDIP package.
+
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
+[Mixing, shift, table, tail correction, restart, rRESPA info]:
+
+This pair style does not support the "pair_modify"_pair_modify.html
+shift, table, and tail options.
+
+This pair style does not write its information to "binary restart
+files"_restart.html, since it is stored in potential files.  Thus, you
+need to re-specify the pair_style and pair_coeff commands in an input
+script that reads a restart file.
+
+This pair style can only be used via the {pair} keyword of the
+"run_style respa"_run_style.html command.  It does not support the
+{inner}, {middle}, {outer} keywords.
+
+:line
+
+[Restrictions:]
+
+This angle style can only be used if LAMMPS was built with the
+USER-MISC package.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info on packages.
+
+This pair style requires the "newton"_newton.html setting to be "on"
+for pair interactions.
+
+The EDIP potential files provided with LAMMPS (see the potentials directory) 
+are parameterized for metal "units"_units.html.
+You can use the SW potential with any LAMMPS units, but you would need
+to create your own EDIP potential file with coefficients listed in the
+appropriate units if your simulation doesn't use "metal" units.
+
+[Related commands:]
+
+"pair_coeff"_pair_coeff.html
+
+[Default:] none
+
+:line
+
+:link(EDIP)
+[(EDIP)] J. F. Justo et al., Phys. Rev. B 58, 2539 (1998).
diff --git a/doc/pair_eff.html b/doc/pair_eff.html
index ecf925d135..a2aaa1a882 100644
--- a/doc/pair_eff.html
+++ b/doc/pair_eff.html
@@ -28,10 +28,10 @@ pair_coeff 2 2 20.0
 
          
 
          Description:
 
          
-
          Contains a LAMMPS implementation of the electron Force Field (eFF)
-potential currently under development at Caltech, as described in
-(Jaramillo-Botero).  The eFF was first introduced
-by (Su) in 2007.
+
          This pair style contains a LAMMPS implementation of the electron Force
+Field (eFF) potential currently under development at Caltech, as
+described in (Jaramillo-Botero).  The eFF was
+first introduced by (Su) in 2007.
 
          
 
          eFF can be viewed as an approximation to QM wave packet dynamics and
 Fermionic molecular dynamics, combining the ability of electronic
@@ -117,7 +117,7 @@ option.  The Coulombic cutoff specified for this style means that
 pairwise interactions within this distance are computed directly;
 interactions outside that distance are computed in reciprocal space.
 
          
-
          These potentials are designed to be used with atom_style
+
          This potential is designed to be used with atom_style
 electron definitions, in order to handle the
 description of systems with interacting nuclei and explicit electrons.
 
          
@@ -252,9 +252,9 @@ to be specified in an input script that reads a restart file.
 
          Restrictions:
 
          
 
          These pair styles will only be enabled if LAMMPS is built with the
-"user-eff" package.  It will only be enabled if LAMMPS was built with
-that package.  See the Making LAMMPS section
-for more info.
+USER-EFF package.  It will only be enabled if LAMMPS was built with
+that package.  See the Making LAMMPS
+section for more info.
 
          
 
          These pair styles require that particles store electron attributes
 such as radius, radial velocity, and radital force, as defined by the
diff --git a/doc/pair_eff.txt b/doc/pair_eff.txt
index ac2a5f30ba..7e38770102 100644
--- a/doc/pair_eff.txt
+++ b/doc/pair_eff.txt
@@ -25,10 +25,10 @@ pair_coeff 2 2 20.0 :pre
 
 [Description:]
 
-Contains a LAMMPS implementation of the electron Force Field (eFF)
-potential currently under development at Caltech, as described in
-"(Jaramillo-Botero)"_#Jaramillo-Botero.  The eFF was first introduced
-by "(Su)"_#Su in 2007.
+This pair style contains a LAMMPS implementation of the electron Force
+Field (eFF) potential currently under development at Caltech, as
+described in "(Jaramillo-Botero)"_#Jaramillo-Botero.  The eFF was
+first introduced by "(Su)"_#Su in 2007.
 
 eFF can be viewed as an approximation to QM wave packet dynamics and
 Fermionic molecular dynamics, combining the ability of electronic
@@ -114,8 +114,8 @@ option.  The Coulombic cutoff specified for this style means that
 pairwise interactions within this distance are computed directly;
 interactions outside that distance are computed in reciprocal space.
 
-These potentials are designed to be used with "atom_style
-electron"_atom_electron.html definitions, in order to handle the
+This potential is designed to be used with "atom_style
+electron"_atom_style.html definitions, in order to handle the
 description of systems with interacting nuclei and explicit electrons.
 
 The following coefficients must be defined for each pair of atoms
@@ -249,9 +249,9 @@ These pair styles can only be used via the {pair} keyword of the
 [Restrictions:]
 
 These pair styles will only be enabled if LAMMPS is built with the
-"user-eff" package.  It will only be enabled if LAMMPS was built with
-that package.  See the "Making LAMMPS"_Section_start.html#2_3 section
-for more info.
+USER-EFF package.  It will only be enabled if LAMMPS was built with
+that package.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
 
 These pair styles require that particles store electron attributes
 such as radius, radial velocity, and radital force, as defined by the
diff --git a/doc/pair_eim.html b/doc/pair_eim.html
index cfeead5d92..484cb2505c 100644
--- a/doc/pair_eim.html
+++ b/doc/pair_eim.html
@@ -11,6 +11,8 @@
 
 
          pair_style eim command 
 
          
+
          pair_style eim/omp command 
+
          
 
          Syntax:
 
          
 
          pair_style style 
@@ -132,9 +134,31 @@ needs.
 
          
 
          
 
+
          Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
          
+
          These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
          
+
          You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
          
+
          See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
          
+
          
+
 
          Restrictions:
 
          
-
          This style is part of the "manybody" package.  It is only enabled if
+
          This style is part of the MANYBODY package.  It is only enabled if
 LAMMPS was built with that package (which it is by default).
 
          
 
          Related commands:
diff --git a/doc/pair_eim.txt b/doc/pair_eim.txt
index 411f64c254..21c0540058 100644
--- a/doc/pair_eim.txt
+++ b/doc/pair_eim.txt
@@ -7,6 +7,7 @@
 :line
 
 pair_style eim command :h3
+pair_style eim/omp command :h3
 
 [Syntax:]
 
@@ -129,9 +130,31 @@ needs.
 
 :line
 
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Restrictions:]
 
-This style is part of the "manybody" package.  It is only enabled if
+This style is part of the MANYBODY package.  It is only enabled if
 LAMMPS was built with that package (which it is by default).
 
 [Related commands:]
diff --git a/doc/pair_gauss.html b/doc/pair_gauss.html
index c6ceaae2ae..64ecda5fb5 100644
--- a/doc/pair_gauss.html
+++ b/doc/pair_gauss.html
@@ -11,9 +11,16 @@
 
 
          pair_style gauss command 
 
          
+
          pair_style gauss/omp command 
+
          
+
          pair_style gauss/cut command 
+
          
+
          pair_style gauss/cut/omp command 
+
          
 
          Syntax: 
 
          
-
          pair_style gauss cutoff 
+
          pair_style gauss cutoff
+pair_style gauss/cut cutoff 
 
          
 
          • cutoff = global cutoff for Gauss interactions (distance units) 
 
          
@@ -23,6 +30,9 @@
 pair_coeff * * 1.0 0.9
 pair_coeff 1 4 1.0 0.9 10.0 
 
          
+
          pair_style gauss/cut 3.5
+pair_coeff 1 4 0.2805 1.45 0.112 
+
          
 
          Description: 
 
          
 
          Style gauss computes a tethering potential of the form
@@ -45,17 +55,69 @@ commands:
 
          The last coefficient is optional. If not specified, the global cutoff
 is used.
 
          
+
          Style gauss/cut computes a generalized Gaussian interaction potential 
+between pairs of particles:
+
          
+
          
+
          
+
          where H determines together with the standard deviation sigma_h the
+peak height of the Gaussian function, and r_mh the peak position.
+Examples of the use of the Gaussian potentials include implicit
+solvent simulations of salt ions (Lenart) and of surfactants
+(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.
+
          
+
          The following coefficients must be defined for each pair of atom types
+via the pair_coeff command as in the example above,
+or in the data file or restart files read by the
+read_data or read_restart
+commands:
+
          
+
          • H (energy * distance units)
+
          • r_mh (distance units)
+
          • sigma_h (distance units) 
+
          
+
          The global cutoff (r_c) specified in the pair_style command is used.
+
          
+
          
+
+
          Styles with a cuda, gpu, omp, or opt suffix are functionally
+the same as the corresponding style without the suffix.  They have
+been optimized to run faster, depending on your available hardware, as
+discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
          
+
          These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
          
+
          You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
          
+
          See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
          
 
          
 
 
          Mixing, shift, table, tail correction, restart, rRESPA info:
 
          
-
          This pair style does not support mixing.  Thus, coefficients for all
+
          These pair style do not support mixing.  Thus, coefficients for all
 I,J pairs must be specified explicitly.
 
          
-
          This pair style does not support the pair_modify
+
          The gauss style does not support the pair_modify
 shift option. There is no effect due to the Gaussian well beyond the
 cutoff; hence reasonable cutoffs need to be specified.
 
          
+
          The gauss/cut style supports the pair_modify shift
+option for the energy of the Gauss-potential portion of the pair
+interaction.
+
          
 
          The pair_modify table and tail options are not
 relevant for this pair style.
 
          
@@ -71,7 +133,7 @@ to be specified in an input script that reads a restart file.
 run_style respa command.  It does not support the
 inner, middle, outer keywords.
 
          
-
          This pair style tallies an "occupancy" count of how many Gaussian-well
+
          Thes gauss pair style tallies an "occupancy" count of how many Gaussian-well
 sites have an atom within the distance at which the force is a maximum
 = sqrt(0.5/b).  This quantity can be accessed via the compute
 pair command as a vector of values of length 1.
@@ -85,11 +147,16 @@ thermo_style custom step temp epair v_occ
 
          
 
          
 
-
          Restrictions: none
+
          Restrictions:
+
          
+
          The gauss/cut style is part of the "user-misc" package. It is only enabled
+if LAMMPS is build with that package. See the Making of LAMMPS
+section for more info.
 
          
 
          Related commands:
 
          
-
          pair_coeff
+
          pair_coeff, 
+pair_style coul/diel
 
          
 
          Default: none
 
          
diff --git a/doc/pair_gauss.txt b/doc/pair_gauss.txt
index 85fa1feea5..63462f918a 100644
--- a/doc/pair_gauss.txt
+++ b/doc/pair_gauss.txt
@@ -7,10 +7,14 @@
 :line
 
 pair_style gauss command :h3
+pair_style gauss/omp command :h3
+pair_style gauss/cut command :h3
+pair_style gauss/cut/omp command :h3
 
 [Syntax:] 
 
-pair_style gauss cutoff :pre
+pair_style gauss cutoff
+pair_style gauss/cut cutoff :pre
 
 cutoff = global cutoff for Gauss interactions (distance units) :ul
 
@@ -20,6 +24,10 @@ pair_style gauss 12.0
 pair_coeff * * 1.0 0.9
 pair_coeff 1 4 1.0 0.9 10.0 :pre
 
+pair_style gauss/cut 3.5
+pair_coeff 1 4 0.2805 1.45 0.112 :pre
+
+
 [Description:] 
 
 Style {gauss} computes a tethering potential of the form
@@ -42,17 +50,69 @@ cutoff (distance units) :ul
 The last coefficient is optional. If not specified, the global cutoff
 is used.
 
+Style {gauss/cut} computes a generalized Gaussian interaction potential 
+between pairs of particles:
+
+:c,image(Eqs/pair_gauss_cut.jpg)
+
+where H determines together with the standard deviation sigma_h the
+peak height of the Gaussian function, and r_mh the peak position.
+Examples of the use of the Gaussian potentials include implicit
+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.
+
+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,
+or in the data file or restart files read by the
+"read_data"_read_data.html or "read_restart"_read_restart.html
+commands:
+
+H (energy * distance units)
+r_mh (distance units)
+sigma_h (distance units) :ul
+
+The global cutoff (r_c) specified in the pair_style command is used.
+
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally
+the same as the corresponding style without the suffix.  They have
+been optimized to run faster, depending on your available hardware, as
+discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
 :line
 
 [Mixing, shift, table, tail correction, restart, rRESPA info]:
 
-This pair style does not support mixing.  Thus, coefficients for all
+These pair style do not support mixing.  Thus, coefficients for all
 I,J pairs must be specified explicitly.
 
-This pair style does not support the "pair_modify"_pair_modify.html
+The {gauss} style does not support the "pair_modify"_pair_modify.html
 shift option. There is no effect due to the Gaussian well beyond the
 cutoff; hence reasonable cutoffs need to be specified.
 
+The {gauss/cut} style supports the "pair_modify"_pair_modify.html shift
+option for the energy of the Gauss-potential portion of the pair
+interaction.
+
 The "pair_modify"_pair_modify.html table and tail options are not
 relevant for this pair style.
 
@@ -68,7 +128,7 @@ This pair style can only be used via the {pair} keyword of the
 "run_style respa"_run_style.html command.  It does not support the
 {inner}, {middle}, {outer} keywords.
 
-This pair style tallies an "occupancy" count of how many Gaussian-well
+Thes {gauss} pair style tallies an "occupancy" count of how many Gaussian-well
 sites have an atom within the distance at which the force is a maximum
 = sqrt(0.5/b).  This quantity can be accessed via the "compute
 pair"_compute_pair.html command as a vector of values of length 1.
@@ -82,10 +142,15 @@ thermo_style custom step temp epair v_occ :pre
 
 :line
 
-[Restrictions:] none
+[Restrictions:]
+
+The {gauss/cut} style is part of the "user-misc" package. It is only enabled
+if LAMMPS is build with that package. See the "Making of LAMMPS"_Section_start.html#3
+section for more info.
 
 [Related commands:]
 
-"pair_coeff"_pair_coeff.html
+"pair_coeff"_pair_coeff.html, 
+"pair_style coul/diel"_pair_coul_diel.html
 
 [Default:] none
diff --git a/doc/pair_gayberne.html b/doc/pair_gayberne.html
index a7533a42ca..ff4e001ced 100644
--- a/doc/pair_gayberne.html
+++ b/doc/pair_gayberne.html
@@ -13,14 +13,13 @@
 
 
          pair_style gayberne/gpu command 
 
          
+
          pair_style gayberne/omp command 
+
          
 
          Syntax:
 
          
 
          pair_style gayberne gamma upsilon mu cutoff 
 
          
-
          pair_style gayberne/gpu gamma upsilon mu cutoff 
-
          
-
          • style = gayberne or gayberne/gpu
-
          • gamma = shift for potential minimum (typically 1)
+
            • gamma = shift for potential minimum (typically 1)
 
            • upsilon = exponent for eta orientation-dependent energy function
 
            • mu = exponent for chi orientation-dependent energy function
 
            • cutoff = global cutoff for interactions (distance units) 
@@ -28,7 +27,6 @@
 
              Examples:
 
              
 
              pair_style gayberne 1.0 1.0 1.0 10.0
-pair_style gayberne/gpu 1.0 1.0 1.0 10.0
 pair_coeff * * 1.0 1.7 1.7 3.4 3.4 1.0 1.0 1.0 
 
              
 
              Description:
@@ -48,9 +46,6 @@ both particles are spherical, the formula reduces to the usual
 Lennard-Jones interaction (see details below for when Gay-Berne treats
 a particle as "spherical").
 
              
-
              Style gayberne/gpu is a GPU-enabled version of style gayberne.
-See more details below.
-
              
 
              For large uniform molecules it has been shown that the energy
 parameters are approximately representable in terms of local contact
 curvatures (Everaers):
@@ -71,9 +66,7 @@ document.
 asphere extension (e.g. fix nve/asphere) in
 order to integrate particle rotation.  Additionally, atom_style
 ellipsoid should be used since it defines the
-rotational state of the ellipsoidal particles.  The size and shape of
-the ellipsoidal particles are defined by the shape
-command.
+rotational state and the size and shape of each ellipsoidal particle.
 
              
 
              The following coefficients must be defined for each pair of atoms
 types via the pair_coeff command as in the examples
@@ -94,10 +87,11 @@ commands, or by mixing as described below:
 
              The last coefficient is optional.  If not specified, the global
 cutoff specified in the pair_style command is used.
 
              
-
              It is typical for the Gay-Berne potential to define sigma as the
-minimum of the 3 "shape" diameters for a I,I interaction, though this
-is not required.  Note that this is a different meaning for sigma
-than the pair_style resquared potential uses.
+
              It is typical with the Gay-Berne potential to define sigma as the
+minimum of the 3 shape diameters of the particles involved in an I,I
+interaction, though this is not required.  Note that this is a
+different meaning for sigma than the pair_style
+resquared potential uses.
 
              
 
              The epsilon_i and epsilon_j coefficients are actually defined for atom
 types, not for pairs of atom types.  Thus, in a series of pair_coeff
@@ -121,37 +115,44 @@ interactions are computed by another hybrid pair potential), then you
 still need to insure the epsilon a,b,c coefficients are assigned to
 that type in a "pair_coeff I J" command.
 
              
-
              IMPORTANT NOTE: If the epsilon a,b,c for an atom type are all 1.0, and
-if the shape of the particle is spherical (see the shape
-command), meaning the 3 diameters are all the same, then the particle
-is treated as "spherical" by the Gay-Berne potential.  This is
-significant because if two "spherical" particles interact, then the
-simple Lennard-Jones formula is used to compute their interaction
-energy/force using epsilon and sigma, which is much cheaper to compute
-than the full Gay-Berne formula.  Thus you should insure epsilon a,b,c
-are set to 1.0 for spherical particle types and use epsilon and sigma
-to specify its interaction with other spherical particles.
+
              IMPORTANT NOTE: If the epsilon a = b = c for an atom type, and if the
+shape of the particle itself is spherical, meaning its 3 shape
+parameters are all the same, then the particle is treated as an LJ
+sphere by the Gay-Berne potential.  This is significant because if two
+LJ spheres interact, then the simple Lennard-Jones formula is used to
+compute their interaction energy/force using the specified epsilon and
+sigma as the standard LJ parameters.  This is much cheaper to compute
+than the full Gay-Berne formula.  To treat the particle as a LJ sphere
+with sigma = D, you should normally set epsilon a = b = c = 1.0, set
+the pair_coeff sigma = D, and also set the 3 shape parameters for the
+particle to D.  The one exception is that if the 3 shape parameters
+are set to 0.0, which is a valid way in LAMMPS to specify a point
+particle, then the Gay-Berne potential will treat that as shape
+parameters of 1.0 (i.e. a LJ particle with sigma = 1), since it
+requires finite-size particles.  In this case you should still set the
+pair_coeff sigma to 1.0 as well.
 
              
 
              
 
-
              The gayberne/gpu style is identical to the gayberne style, except
-that each processor off-loads its pairwise calculations to a GPU chip.
-Depending on the hardware available on your system this can provide a
-significant speed-up, especially for the relatively expensive
-computations inherent in Gay-Berne interactions.  See the Running on
-GPUs section of the manual for more details
-about hardware and software requirements for using GPUs.
+
              Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
 
              
-
              More details about these settings and various possible hardware
-configuration are in this section of the
-manual.
+
              These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
 
              
-
              Additional requirements in your input script to run with style
-gayberne/gpu are as follows:
+
              You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
 
              
-
              The newton pair setting must be off and
-fix gpu must be used. The fix controls the
-essential GPU selection and initialization steps.
+
              See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
 
              
 
              
 
@@ -186,19 +187,23 @@ to be specified in an input script that reads a restart file.
 
 
              Restrictions:
 
              
-
              The gayberne style is part of the "asphere" package.  The
-gayberne/gpu style is part of the "gpu" package.  They are only
-enabled if LAMMPS was built with the those packages.  See the Making
+
              The gayberne style is part of the ASPHERE package.  It is only
+enabled if LAMMPS was built with that package.  See the Making
 LAMMPS section for more info.
 
              
-
              This pair style requires that atoms store torque and a quaternion to
+
              These pair style require that atoms store torque and a quaternion to
 represent their orientation, as defined by the
 atom_style.  It also require they store a per-type
 shape.  The particles cannot store a per-particle
 diameter.
 
              
+
              This pair style requires that atoms be ellipsoids as defined by the
+atom_style ellipsoid command.
+
              
 
              Particles acted on by the potential can be extended aspherical or
-spherical particles, or point particles.
+spherical particles, or point particles.  Spherical particles have all
+3 of their shape parameters equal to each other.  Point particles have
+all 3 of their shape parameters equal to 0.0.
 
              
 
              The Gay-Berne potential does not become isotropic as r increases
 (Everaers).  The distance-of-closest-approach
diff --git a/doc/pair_gayberne.txt b/doc/pair_gayberne.txt
index d2eedd4dc2..9b3363c000 100755
--- a/doc/pair_gayberne.txt
+++ b/doc/pair_gayberne.txt
@@ -8,13 +8,12 @@
 
 pair_style gayberne command :h3
 pair_style gayberne/gpu command :h3
+pair_style gayberne/omp command :h3
 
 [Syntax:]
 
 pair_style gayberne gamma upsilon mu cutoff :pre
-pair_style gayberne/gpu gamma upsilon mu cutoff :pre
 
-style = {gayberne} or {gayberne/gpu}
 gamma = shift for potential minimum (typically 1)
 upsilon = exponent for eta orientation-dependent energy function
 mu = exponent for chi orientation-dependent energy function
@@ -23,7 +22,6 @@ cutoff = global cutoff for interactions (distance units) :ul
 [Examples:]
 
 pair_style gayberne 1.0 1.0 1.0 10.0
-pair_style gayberne/gpu 1.0 1.0 1.0 10.0
 pair_coeff * * 1.0 1.7 1.7 3.4 3.4 1.0 1.0 1.0 :pre
 
 [Description:]
@@ -43,9 +41,6 @@ both particles are spherical, the formula reduces to the usual
 Lennard-Jones interaction (see details below for when Gay-Berne treats
 a particle as "spherical").
 
-Style {gayberne/gpu} is a GPU-enabled version of style {gayberne}.
-See more details below.
-
 For large uniform molecules it has been shown that the energy
 parameters are approximately representable in terms of local contact
 curvatures "(Everaers)"_#Everaers:
@@ -66,9 +61,7 @@ Use of this pair style requires the NVE, NVT, or NPT fixes with the
 {asphere} extension (e.g. "fix nve/asphere"_fix_nve_asphere.html) in
 order to integrate particle rotation.  Additionally, "atom_style
 ellipsoid"_atom_style.html should be used since it defines the
-rotational state of the ellipsoidal particles.  The size and shape of
-the ellipsoidal particles are defined by the "shape"_shape.html
-command.
+rotational state and the size and shape of each ellipsoidal particle.
 
 The following coefficients must be defined for each pair of atoms
 types via the "pair_coeff"_pair_coeff.html command as in the examples
@@ -89,10 +82,11 @@ cutoff (distance units) :ul
 The last coefficient is optional.  If not specified, the global
 cutoff specified in the pair_style command is used.
 
-It is typical for the Gay-Berne potential to define {sigma} as the
-minimum of the 3 "shape" diameters for a I,I interaction, though this
-is not required.  Note that this is a different meaning for {sigma}
-than the "pair_style resquared"_pair_resquared.html potential uses.
+It is typical with the Gay-Berne potential to define {sigma} as the
+minimum of the 3 shape diameters of the particles involved in an I,I
+interaction, though this is not required.  Note that this is a
+different meaning for {sigma} than the "pair_style
+resquared"_pair_resquared.html potential uses.
  
 The epsilon_i and epsilon_j coefficients are actually defined for atom
 types, not for pairs of atom types.  Thus, in a series of pair_coeff
@@ -116,37 +110,44 @@ interactions are computed by another hybrid pair potential), then you
 still need to insure the epsilon a,b,c coefficients are assigned to
 that type in a "pair_coeff I J" command.
 
-IMPORTANT NOTE: If the epsilon a,b,c for an atom type are all 1.0, and
-if the shape of the particle is spherical (see the "shape"_shape.html
-command), meaning the 3 diameters are all the same, then the particle
-is treated as "spherical" by the Gay-Berne potential.  This is
-significant because if two "spherical" particles interact, then the
-simple Lennard-Jones formula is used to compute their interaction
-energy/force using epsilon and sigma, which is much cheaper to compute
-than the full Gay-Berne formula.  Thus you should insure epsilon a,b,c
-are set to 1.0 for spherical particle types and use epsilon and sigma
-to specify its interaction with other spherical particles.
+IMPORTANT NOTE: If the epsilon a = b = c for an atom type, and if the
+shape of the particle itself is spherical, meaning its 3 shape
+parameters are all the same, then the particle is treated as an LJ
+sphere by the Gay-Berne potential.  This is significant because if two
+LJ spheres interact, then the simple Lennard-Jones formula is used to
+compute their interaction energy/force using the specified epsilon and
+sigma as the standard LJ parameters.  This is much cheaper to compute
+than the full Gay-Berne formula.  To treat the particle as a LJ sphere
+with sigma = D, you should normally set epsilon a = b = c = 1.0, set
+the pair_coeff sigma = D, and also set the 3 shape parameters for the
+particle to D.  The one exception is that if the 3 shape parameters
+are set to 0.0, which is a valid way in LAMMPS to specify a point
+particle, then the Gay-Berne potential will treat that as shape
+parameters of 1.0 (i.e. a LJ particle with sigma = 1), since it
+requires finite-size particles.  In this case you should still set the
+pair_coeff sigma to 1.0 as well.
 
 :line
 
-The {gayberne/gpu} style is identical to the {gayberne} style, except
-that each processor off-loads its pairwise calculations to a GPU chip.
-Depending on the hardware available on your system this can provide a
-significant speed-up, especially for the relatively expensive
-computations inherent in Gay-Berne interactions.  See the "Running on
-GPUs"_Section_start.html#2_8 section of the manual for more details
-about hardware and software requirements for using GPUs.
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_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.
 
-More details about these settings and various possible hardware
-configuration are in "this section"_Section_start.html#2_8 of the
-manual.
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
 
-Additional requirements in your input script to run with style
-{gayberne/gpu} are as follows:
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
 
-The "newton pair"_newton.html setting must be {off} and
-"fix gpu"_fix_gpu.html must be used. The fix controls the
-essential GPU selection and initialization steps.
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
 
 :line
 
@@ -181,19 +182,23 @@ This pair style can only be used via the {pair} keyword of the
 
 [Restrictions:]
 
-The {gayberne} style is part of the "asphere" package.  The
-{gayberne/gpu} style is part of the "gpu" package.  They are only
-enabled if LAMMPS was built with the those packages.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+The {gayberne} style is part of the ASPHERE package.  It is only
+enabled if LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
 
-This pair style requires that atoms store torque and a quaternion to
+These pair style require that atoms store torque and a quaternion to
 represent their orientation, as defined by the
 "atom_style"_atom_style.html.  It also require they store a per-type
 "shape"_shape.html.  The particles cannot store a per-particle
 diameter.
 
+This pair style requires that atoms be ellipsoids as defined by the
+"atom_style ellipsoid"_atom_style.html command.
+
 Particles acted on by the potential can be extended aspherical or
-spherical particles, or point particles.
+spherical particles, or point particles.  Spherical particles have all
+3 of their shape parameters equal to each other.  Point particles have
+all 3 of their shape parameters equal to 0.0.
 
 The Gay-Berne potential does not become isotropic as r increases
 "(Everaers)"_#Everaers.  The distance-of-closest-approach
diff --git a/doc/pair_gran.html b/doc/pair_gran.html
index a39614aae5..f175e8f2ce 100644
--- a/doc/pair_gran.html
+++ b/doc/pair_gran.html
@@ -11,10 +11,18 @@
 
 
              pair_style gran/hooke command 
 
              
+
              pair_style gran/cuda command 
+
              
+
              pair_style gran/omp command 
+
              
 
              pair_style gran/hooke/history command 
 
              
+
              pair_style gran/hooke/history/omp command 
+
              
 
              pair_style gran/hertz/history command 
 
              
+
              pair_style gran/hertz/history/omp command 
+
              
 
              Syntax:
 
              
 
              pair_style style Kn Kt gamma_n gamma_t xmu dampflag 
@@ -168,6 +176,28 @@ potential.
 
              
 
              
 
+
              Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
              
+
              These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
              
+
              You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
              
+
              See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
              
+
              
+
 
              Mixing, shift, table, tail correction, restart, rRESPA info:
 
              
 
              The pair_modify mix, shift, table, and tail options
@@ -181,18 +211,29 @@ specified in an input script that reads a restart file.
 run_style respa command.  They do not support the
 inner, middle, outer keywords.
 
              
+
              The single() function of these pair styles returns 0.0 for the energy
+of a pairwise interaction, since energy is not conserved in these
+dissipative potentials.  It also returns only the normal component of
+the pairwise interaction force.  However, the single() function also
+calculates 4 extra pairwise quantities.  The first 3 are the
+components of the tangential force between particles I and J, acting
+on particle I.  P4 is the magnitude of this tangential force.  These
+extra quantites can be accessed by the compute
+pair/local command, as p1, p2, p3,
+p4.
+
              
 
              
 
 
              Restrictions: none
 
              
-
              All the granular pair styles are part of the "granular" package.  It
-is only enabled if LAMMPS was built with that package.  See the
-Making LAMMPS section for more info.
+
              All the granular pair styles are part of the GRANULAR package.  It is
+only enabled if LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
 
              
 
              These pair styles require that atoms store torque and angular velocity
 (omega) as defined by the atom_style.  They also
-require a per-particle radius is stored.  The granular atom style
-does all of this.
+require a per-particle radius is stored.  The sphere atom style does
+all of this.
 
              
 
              This pair style requires you to use the communicate vel
 yes option so that velocites are stored by ghost
diff --git a/doc/pair_gran.txt b/doc/pair_gran.txt
index 275fc9e0e8..3dfa8b3a96 100644
--- a/doc/pair_gran.txt
+++ b/doc/pair_gran.txt
@@ -7,8 +7,12 @@
 :line
 
 pair_style gran/hooke command :h3
+pair_style gran/cuda command :h3
+pair_style gran/omp command :h3
 pair_style gran/hooke/history command :h3
+pair_style gran/hooke/history/omp command :h3
 pair_style gran/hertz/history command :h3
+pair_style gran/hertz/history/omp command :h3
 
 [Syntax:]
 
@@ -158,6 +162,28 @@ potential.
 
 :line
 
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Mixing, shift, table, tail correction, restart, rRESPA info]:
 
 The "pair_modify"_pair_modify.html mix, shift, table, and tail options
@@ -171,18 +197,29 @@ These pair styles can only be used via the {pair} keyword of the
 "run_style respa"_run_style.html command.  They do not support the
 {inner}, {middle}, {outer} keywords.
 
+The single() function of these pair styles returns 0.0 for the energy
+of a pairwise interaction, since energy is not conserved in these
+dissipative potentials.  It also returns only the normal component of
+the pairwise interaction force.  However, the single() function also
+calculates 4 extra pairwise quantities.  The first 3 are the
+components of the tangential force between particles I and J, acting
+on particle I.  {P4} is the magnitude of this tangential force.  These
+extra quantites can be accessed by the "compute
+pair/local"_compute_pair_local.html command, as {p1}, {p2}, {p3},
+{p4}.
+
 :line
 
 [Restrictions:] none
 
-All the granular pair styles are part of the "granular" package.  It
-is only enabled if LAMMPS was built with that package.  See the
-"Making LAMMPS"_Section_start.html#2_3 section for more info.
+All the granular pair styles are 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.
 
 These pair styles require that atoms store torque and angular velocity
 (omega) as defined by the "atom_style"_atom_style.html.  They also
-require a per-particle radius is stored.  The {granular} atom style
-does all of this.
+require a per-particle radius is stored.  The {sphere} atom style does
+all of this.
 
 This pair style requires you to use the "communicate vel
 yes"_communicate.html option so that velocites are stored by ghost
diff --git a/doc/pair_gromacs.html b/doc/pair_gromacs.html
index f9ea7b3f9c..aa8051d5c0 100644
--- a/doc/pair_gromacs.html
+++ b/doc/pair_gromacs.html
@@ -11,8 +11,16 @@
 
 
              pair_style lj/gromacs command 
 
              
+
              pair_style lj/gromacs/cuda command 
+
              
+
              pair_style lj/gromacs/omp command 
+
              
 
              pair_style lj/gromacs/coul/gromacs command 
 
              
+
              pair_style lj/gromacs/coul/gromacs/cuda command 
+
              
+
              pair_style lj/gromacs/coul/gromacs/omp command 
+
              
 
              Syntax:
 
              
 
              pair_style style args 
@@ -38,23 +46,24 @@ pair_coeff * * 100.0 2.0
 
              
 
              Description:
 
              
-
              The lj/gromacs styles compute LJ and Coulombic interactions with an
-additional switching function S(r) that ramps the energy and force
+
              The lj/gromacs styles compute shifted LJ and Coulombic interactions 
+with an additional switching function S(r) that ramps the energy and force
 smoothly to zero between an inner and outer cutoff.  It is a commonly
 used potential in the GROMACS MD code and for
 the coarse-grained models of (Marrink).
 
              
 
              
 
              
-
              R1 is the inner cutoff; Rc is the outer cutoff.  The coefficients A
-and B are computed by LAMMPS to perform the smoothing.  The function
+
              R1 is the inner cutoff; Rc is the outer cutoff.  The coefficients A, B, 
+and C are computed by LAMMPS to perform the shifting and smoothing.  
+The function
 S(r) is actually applied once to each term of the LJ formula and once
-to the Coulombic formula, so there are 2 or 3 sets of A,B coefficients
+to the Coulombic formula, so there are 2 or 3 sets of A,B,C coefficients
 depending on which pair_style is used.  The boundary conditions
 applied to the smoothing function are as follows: S(r1) = S'(r1) = 0,
-S(rc) = -F(rc), S'(rc) = -F'(rc), where F(r) is the correpsonding term
-in the LJ or Coulombic function and a single quote represents a
-derivative with respect to r.
+S(rc) = -F(rc), S'(rc) = -F'(rc), where F(r) is the corresponding term
+in the LJ or Coulombic potential energy function and a 
+single quote represents a derivative with respect to r.
 
              
 
              The inner and outer cutoff for the LJ and Coulombic terms can be the
 same or different depending on whether 2 or 4 arguments are used in
@@ -87,6 +96,28 @@ cutoff(s) specified in the pair_style command.
 
              
 
              
 
+
              Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
              
+
              These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
              
+
              You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
              
+
              See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
              
+
              
+
 
              Mixing, shift, table, tail correction, restart, rRESPA info:
 
              
 
              For atom type pairs I,J and I != J, the epsilon and sigma coefficients
diff --git a/doc/pair_gromacs.txt b/doc/pair_gromacs.txt
index b544f61dbd..5fc8ef3c4b 100644
--- a/doc/pair_gromacs.txt
+++ b/doc/pair_gromacs.txt
@@ -7,7 +7,11 @@
 :line
 
 pair_style lj/gromacs command :h3
+pair_style lj/gromacs/cuda command :h3
+pair_style lj/gromacs/omp command :h3
 pair_style lj/gromacs/coul/gromacs command :h3
+pair_style lj/gromacs/coul/gromacs/cuda command :h3
+pair_style lj/gromacs/coul/gromacs/omp command :h3
 
 [Syntax:]
 
@@ -33,23 +37,24 @@ pair_coeff * * 100.0 2.0 :pre
 
 [Description:]
 
-The {lj/gromacs} styles compute LJ and Coulombic interactions with an
-additional switching function S(r) that ramps the energy and force
+The {lj/gromacs} styles compute shifted LJ and Coulombic interactions 
+with an additional switching function S(r) that ramps the energy and force
 smoothly to zero between an inner and outer cutoff.  It is a commonly
 used potential in the "GROMACS"_http://www.gromacs.org MD code and for
 the coarse-grained models of "(Marrink)"_#Marrink.
 
 :c,image(Eqs/pair_gromacs.jpg)
 
-R1 is the inner cutoff; Rc is the outer cutoff.  The coefficients A
-and B are computed by LAMMPS to perform the smoothing.  The function
+R1 is the inner cutoff; Rc is the outer cutoff.  The coefficients A, B, 
+and C are computed by LAMMPS to perform the shifting and smoothing.  
+The function
 S(r) is actually applied once to each term of the LJ formula and once
-to the Coulombic formula, so there are 2 or 3 sets of A,B coefficients
+to the Coulombic formula, so there are 2 or 3 sets of A,B,C coefficients
 depending on which pair_style is used.  The boundary conditions
 applied to the smoothing function are as follows: S(r1) = S'(r1) = 0,
-S(rc) = -F(rc), S'(rc) = -F'(rc), where F(r) is the correpsonding term
-in the LJ or Coulombic function and a single quote represents a
-derivative with respect to r.
+S(rc) = -F(rc), S'(rc) = -F'(rc), where F(r) is the corresponding term
+in the LJ or Coulombic potential energy function and a 
+single quote represents a derivative with respect to r.
 
 The inner and outer cutoff for the LJ and Coulombic terms can be the
 same or different depending on whether 2 or 4 arguments are used in
@@ -82,6 +87,28 @@ cutoff(s) specified in the pair_style command.
 
 :line
 
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Mixing, shift, table, tail correction, restart, rRESPA info]:
 
 For atom type pairs I,J and I != J, the epsilon and sigma coefficients
diff --git a/doc/pair_hbond_dreiding.html b/doc/pair_hbond_dreiding.html
index 06689575d9..d412af1ef6 100644
--- a/doc/pair_hbond_dreiding.html
+++ b/doc/pair_hbond_dreiding.html
@@ -11,38 +11,44 @@
 
 
              pair_style hbond/dreiding/lj command 
 
              
+
              pair_style hbond/dreiding/lj/omp command 
+
              
 
              pair_style hbond/dreiding/morse command 
 
              
+
              pair_style hbond/dreiding/morse/omp command 
+
              
 
              Syntax:
 
              
-
              pair_style style distance_cutoff angle_cutof N 
+
              pair_style style N inner_distance_cutoff outer_distance_cutoff angle_cutof 
 
              
 
              • style = hbond/dreiding/lj or hbond/dreiding/morse 
 
              • n = cosine angle periodicity
-
              • distance_cutoff = global cutoff for Donor-Acceptor interactions (distance units)
+
              • inner_distance_cutoff = global inner spline cutoff for Donor-Acceptor interactions (distance units)
+
              • outer_distance_cutoff = global cutoff for Donor-Acceptor interactions (distance units)
 
              • angle_cutoff = global angle cutoff for Acceptor-Hydrogen-Donor
 
              • interactions (degrees) 
 
              
 
              Examples:
 
              
-
              pair_style hbond/dreiding/lj 4 5.0 90
+
              pair_style hbond/dreiding/lj 4 4.5 5.0 90
 pair_coeff * * 3 i 100.0 3.1
-pair_coeff * * 2*5 i 100.0 3.1 2 200.0 
+pair_coeff * * 2*5 i 100.0 3.1 2 15.0 20.0 135.0 
 
              
-
              pair_style hbond/dreiding/morse 2 4.6 75.0 
+
              pair_style hbond/dreiding/morse 2 3.0 4.6 75.0 
 pair_coeff * * 3 j 100.0 1.0 2.0
-pair_coeff * * 2*5 j 100.0 1.0 2.0 4 
+pair_coeff * * 2*5 j 100.0 1.0 2.0 4.0 6.0 
 
              
 
              Description:
 
              
 
              The hbond/dreiding styles compute the Acceptor-Hydrogen-Donor (AHD)
 3-body hydrogen bond interaction for the
-DREIDING force field, given by:
+DREIDING force field, given by:
 
              
 
              
 
              
-
              where Rc is the distance cutoff, theta_c is the angle cutoff, and n is
-the cosine periodicity.
+
              where Rin is the inner spline distance cutoff, Rout is the outer
+distance cutoff, theta_c is the angle cutoff, and n is the cosine
+periodicity.
 
              
 
              Here, r is the radial distance between the donor (D) and acceptor
 (A) atoms and theta is the bond angle between the acceptor, the
@@ -67,8 +73,8 @@ potential for the Donor-Acceptor interactions. (Liu) showed
 that the Morse form gives improved results for Dendrimer simulations,
 when n = 2.
 
              
-
              See this howto section of the manual for more
-information on the DREIDING forcefield.
+
              See this howto section of the manual for
+more information on the DREIDING forcefield.
 
              
 
              Because the Dreiding hydrogen bond potential is only one portion of
 an overall force field which typically includes other pairwise
@@ -146,6 +152,28 @@ optional parameters.
 
              
 
              
 
+
              Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
              
+
              These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
              
+
              You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
              
+
              See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
              
+
              
+
 
              Mixing, shift, table, tail correction, restart, rRESPA info:
 
              
 
              These pair styles do not support mixing. You must explicitly identify
@@ -169,17 +197,18 @@ re-specified in an input script that reads a restart file.
 run_style respa command.  They do not support the
 inner, middle, outer keywords.
 
              
-
              These pair style tally a count of how many hydrogen bonding
-interactions they calculate each timestep.  This quantity can be
-accessed via the compute pair command as a vector
-of values of length 1.
+
              These pair styles tally a count of how many hydrogen bonding
+interactions they calculate each timestep and the hbond energy.  These
+quantities can be accessed via the compute pair
+command as a vector of values of length 2.
 
              
-
              To print this quantity to the log file (with a descriptive column
+
              To print these quantities to the log file (with a descriptive column
 heading) the following commands could be included in an input script:
 
              
 
              compute hb all pair hbond/dreiding/lj
-variable hb equal c_hb[1]
-thermo_style custom step temp epair v_hb 
+variable n_hbond equal c_hb[1] #number hbonds
+variable E_hbond equal c_hb[2] #hbond energy
+thermo_style custom step temp epair v_E_hbond 
 
              
 
              
 
diff --git a/doc/pair_hbond_dreiding.txt b/doc/pair_hbond_dreiding.txt
index 77b92ae73a..afc469a4a3 100644
--- a/doc/pair_hbond_dreiding.txt
+++ b/doc/pair_hbond_dreiding.txt
@@ -7,38 +7,42 @@
 :line
 
 pair_style hbond/dreiding/lj command :h3
+pair_style hbond/dreiding/lj/omp command :h3
 pair_style hbond/dreiding/morse command :h3
+pair_style hbond/dreiding/morse/omp command :h3
 
 [Syntax:]
 
-pair_style style distance_cutoff angle_cutof N :pre
+pair_style style N inner_distance_cutoff outer_distance_cutoff angle_cutof :pre
 
 style = {hbond/dreiding/lj} or {hbond/dreiding/morse} 
 n = cosine angle periodicity
-distance_cutoff = global cutoff for Donor-Acceptor interactions (distance units)
+inner_distance_cutoff = global inner spline cutoff for Donor-Acceptor interactions (distance units)
+outer_distance_cutoff = global cutoff for Donor-Acceptor interactions (distance units)
 angle_cutoff = global angle cutoff for Acceptor-Hydrogen-Donor
 interactions (degrees) :ul
 
 [Examples:]
 
-pair_style hbond/dreiding/lj 4 5.0 90
+pair_style hbond/dreiding/lj 4 4.5 5.0 90
 pair_coeff * * 3 i 100.0 3.1
-pair_coeff * * 2*5 i 100.0 3.1 2 200.0 :pre
+pair_coeff * * 2*5 i 100.0 3.1 2 15.0 20.0 135.0 :pre
 
-pair_style hbond/dreiding/morse 2 4.6 75.0 
+pair_style hbond/dreiding/morse 2 3.0 4.6 75.0 
 pair_coeff * * 3 j 100.0 1.0 2.0
-pair_coeff * * 2*5 j 100.0 1.0 2.0 4 :pre
+pair_coeff * * 2*5 j 100.0 1.0 2.0 4.0 6.0 :pre
 
 [Description:]
 
 The {hbond/dreiding} styles compute the Acceptor-Hydrogen-Donor (AHD)
 3-body hydrogen bond interaction for the
-"DREIDING"_Section_howto.html#4_4 force field, given by:
+"DREIDING"_Section_howto.html#howto_4 force field, given by:
 
 :c,image(Eqs/pair_hbond_dreiding.jpg)
 
-where Rc is the distance cutoff, theta_c is the angle cutoff, and n is
-the cosine periodicity.
+where Rin is the inner spline distance cutoff, Rout is the outer
+distance cutoff, theta_c is the angle cutoff, and n is the cosine
+periodicity.
 
 Here, {r} is the radial distance between the donor (D) and acceptor
 (A) atoms and {theta} is the bond angle between the acceptor, the
@@ -63,8 +67,8 @@ potential for the Donor-Acceptor interactions. "(Liu)"_#Liu showed
 that the Morse form gives improved results for Dendrimer simulations,
 when n = 2.
 
-See this "howto section"_Section_howto.html#4_4 of the manual for more
-information on the DREIDING forcefield.
+See this "howto section"_Section_howto.html#howto_4 of the manual for
+more information on the DREIDING forcefield.
 
 Because the Dreiding hydrogen bond potential is only one portion of
 an overall force field which typically includes other pairwise
@@ -142,6 +146,28 @@ optional parameters.
 
 :line
 
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Mixing, shift, table, tail correction, restart, rRESPA info]:
 
 These pair styles do not support mixing. You must explicitly identify
@@ -165,17 +191,18 @@ These pair styles can only be used via the {pair} keyword of the
 "run_style respa"_run_style.html command.  They do not support the
 {inner}, {middle}, {outer} keywords.
 
-These pair style tally a count of how many hydrogen bonding
-interactions they calculate each timestep.  This quantity can be
-accessed via the "compute pair"_compute_pair.html command as a vector
-of values of length 1.
+These pair styles tally a count of how many hydrogen bonding
+interactions they calculate each timestep and the hbond energy.  These
+quantities can be accessed via the "compute pair"_compute_pair.html
+command as a vector of values of length 2.
 
-To print this quantity to the log file (with a descriptive column
+To print these quantities to the log file (with a descriptive column
 heading) the following commands could be included in an input script:
 
 compute hb all pair hbond/dreiding/lj
-variable hb equal c_hb\[1\]
-thermo_style custom step temp epair v_hb :pre
+variable n_hbond equal c_hb\[1\] #number hbonds
+variable E_hbond equal c_hb\[2\] #hbond energy
+thermo_style custom step temp epair v_E_hbond :pre
 
 :line
 
diff --git a/doc/pair_hybrid.html b/doc/pair_hybrid.html
index 30b3c2466d..7fcba348da 100644
--- a/doc/pair_hybrid.html
+++ b/doc/pair_hybrid.html
@@ -11,8 +11,12 @@
 
 
              pair_style hybrid command 
 
              
+
              pair_style hybrid/omp command 
+
              
 
              pair_style hybrid/overlay command 
 
              
+
              pair_style hybrid/overlay/omp command 
+
              
 
              Syntax:
 
              
 
              pair_style hybrid style1 args style2 args ...
@@ -61,24 +65,35 @@ sub-style's name is followed by its usual arguments, as illustrated in
 the example above.  See the doc pages of individual pair styles for a
 listing and explanation of the appropriate arguments.
 
              
-
              The pair_coeff commands are also specified exactly as they would be
-for a simulation using only one pair style, with one additional
-argument.  Following the I,J type specification, the first argument
-sets the pair sub-style.  The remaining arguments are the coefficients
-appropriate to that style.  For example, consider a simulation with 3
-atom types: types 1 and 2 are Ni atoms, type 3 are LJ atoms with
-charges.  The following commands would set up a hybrid simulation:
+
              In the pair_coeff commands, the name of a pair style must be added
+after the I,J type specification, with the remaining coefficients
+being those appropriate to that style.  For example, consider a
+simulation with 3 atom types: types 1 and 2 are Ni atoms, type 3 are
+LJ atoms with charges.  The following commands would set up a hybrid
+simulation:
 
              
 
              pair_style hybrid eam/alloy lj/cut/coul/cut 10.0 lj/cut 8.0
 pair_coeff * * eam/alloy nialhjea Ni Ni NULL
 pair_coeff 3 3 lj/cut/coul/cut 1.0 1.0
 pair_coeff 1*2 3 lj/cut 0.8 1.3 
 
              
-
              Note that the pair_coeff command for eam/alloy includes a mapping
-specification of elements to all atom types, even those not assigned
-to the eam/alloy potential.  The NULL keyword is used by many such
-potentials (eam/alloy, Tersoff, AIREBO, etc), to denote an atom type
-that will be assigned to a different sub-style.
+
              If pair coefficients are specified in the data file read via the
+read_data command, then the same rule applies.
+E.g. "eam/alloy" or "lj/cut" must be added after the atom type, for
+each line in the "Pair Coeffs" section, e.g.
+
              
+
              Pair Coeffs 
+
              
+
              1 lj/cut/coul/cut 1.0 1.0
+... 
+
              
+
              Note that the pair_coeff command for some potentials such as
+pair_style eam/alloy includes a mapping specification
+of elements to all atom types, which in the hybrid case, can include
+atom types not assigned to the eam/alloy potential.  The NULL
+keyword is used by many such potentials (eam/alloy, Tersoff, AIREBO,
+etc), to denote an atom type that will be assigned to a different
+sub-style.
 
              
 
              For the hybrid style, each atom type pair I,J is assigned to exactly
 one sub-style.  Just as with a simulation using a single pair style,
@@ -122,10 +137,14 @@ sub-style and use the neigh_modify exclude typehybrid and hybrid/overlay simulations, you
-can use this form of the pair_coeff command:
+can use this form of the pair_coeff command in your input script:
 
              
 
              pair_coeff	2 3 none 
 
              
+
              or this form in the "Pair Coeffs" section of the data file:
+
              
+
              3 none 
+
              
 
              If an assignment to none is made in a simulation with the
 hybrid/overlay pair style, it wipes out all previous assignments of
 that atom type pair to sub-styles.
@@ -197,6 +216,32 @@ passed to the Tersoff potential, which means it would compute no
 
              
 
              
 
+
              Styles with a cuda, gpu, omp, or opt suffix are functionally
+the same as the corresponding style without the suffix.  They have
+been optimized to run faster, depending on your available hardware,
+as discussed in this section of the manual.
+
              
+
              Since the hybrid and hybrid/overlay styles delegate computation
+to the individual sub-styles, the suffix versions of the hybrid
+and hybrid/overlay styles are used to propagate the corresponding
+suffix to all sub-styles, if those versions exist. Otherwise the
+non-accelerated version will be used.
+
              
+
              The individual accelerated sub-styles are part of the USER-CUDA, GPU,
+USER-OMP and OPT packages, respectively.  They are only enabled if
+LAMMPS was built with those packages.  See the
+Making LAMMPS section for more info.
+
              
+
              You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
              
+
              See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
              
+
              
+
 
              Mixing, shift, table, tail correction, restart, rRESPA info:
 
              
 
              Any pair potential settings made via the
diff --git a/doc/pair_hybrid.txt b/doc/pair_hybrid.txt
index 538bf8d144..b93fe360d8 100644
--- a/doc/pair_hybrid.txt
+++ b/doc/pair_hybrid.txt
@@ -7,7 +7,9 @@
 :line
 
 pair_style hybrid command :h3
+pair_style hybrid/omp command :h3
 pair_style hybrid/overlay command :h3
+pair_style hybrid/overlay/omp command :h3
 
 [Syntax:]
 
@@ -57,24 +59,35 @@ sub-style's name is followed by its usual arguments, as illustrated in
 the example above.  See the doc pages of individual pair styles for a
 listing and explanation of the appropriate arguments.
 
-The pair_coeff commands are also specified exactly as they would be
-for a simulation using only one pair style, with one additional
-argument.  Following the I,J type specification, the first argument
-sets the pair sub-style.  The remaining arguments are the coefficients
-appropriate to that style.  For example, consider a simulation with 3
-atom types: types 1 and 2 are Ni atoms, type 3 are LJ atoms with
-charges.  The following commands would set up a hybrid simulation:
+In the pair_coeff commands, the name of a pair style must be added
+after the I,J type specification, with the remaining coefficients
+being those appropriate to that style.  For example, consider a
+simulation with 3 atom types: types 1 and 2 are Ni atoms, type 3 are
+LJ atoms with charges.  The following commands would set up a hybrid
+simulation:
 
 pair_style hybrid eam/alloy lj/cut/coul/cut 10.0 lj/cut 8.0
 pair_coeff * * eam/alloy nialhjea Ni Ni NULL
 pair_coeff 3 3 lj/cut/coul/cut 1.0 1.0
 pair_coeff 1*2 3 lj/cut 0.8 1.3 :pre
 
-Note that the pair_coeff command for {eam/alloy} includes a mapping
-specification of elements to all atom types, even those not assigned
-to the {eam/alloy} potential.  The NULL keyword is used by many such
-potentials (eam/alloy, Tersoff, AIREBO, etc), to denote an atom type
-that will be assigned to a different sub-style.
+If pair coefficients are specified in the data file read via the
+"read_data"_read_data.html command, then the same rule applies.
+E.g. "eam/alloy" or "lj/cut" must be added after the atom type, for
+each line in the "Pair Coeffs" section, e.g.
+
+Pair Coeffs :pre
+
+1 lj/cut/coul/cut 1.0 1.0
+... :pre
+
+Note that the pair_coeff command for some potentials such as
+"pair_style eam/alloy"_pair_eam.html includes a mapping specification
+of elements to all atom types, which in the hybrid case, can include
+atom types not assigned to the {eam/alloy} potential.  The NULL
+keyword is used by many such potentials (eam/alloy, Tersoff, AIREBO,
+etc), to denote an atom type that will be assigned to a different
+sub-style.
 
 For the {hybrid} style, each atom type pair I,J is assigned to exactly
 one sub-style.  Just as with a simulation using a single pair style,
@@ -118,10 +131,14 @@ sub-style and use the "neigh_modify exclude type"_neigh_modify.html
 command.  You can assign it to some sub-style and set the coefficients
 so that there is effectively no interaction (e.g. epsilon = 0.0 in a
 LJ potential).  Or, for {hybrid} and {hybrid/overlay} simulations, you
-can use this form of the pair_coeff command:
+can use this form of the pair_coeff command in your input script:
 
 pair_coeff	2 3 none :pre
 
+or this form in the "Pair Coeffs" section of the data file:
+
+3 none :pre
+
 If an assignment to {none} is made in a simulation with the
 {hybrid/overlay} pair style, it wipes out all previous assignments of
 that atom type pair to sub-styles.
@@ -193,6 +210,32 @@ passed to the Tersoff potential, which means it would compute no
 
 :line
 
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally
+the same as the corresponding style without the suffix.  They have
+been optimized to run faster, depending on your available hardware,
+as discussed in "this section"_Section_accelerate.html of the manual.
+
+Since the {hybrid} and {hybrid/overlay} styles delegate computation
+to the individual sub-styles, the suffix versions of the {hybrid}
+and {hybrid/overlay} styles are used to propagate the corresponding
+suffix to all sub-styles, if those versions exist. Otherwise the
+non-accelerated version will be used.
+
+The individual accelerated sub-styles are part of the USER-CUDA, GPU,
+USER-OMP and OPT packages, respectively.  They are only enabled if
+LAMMPS was built with those packages.  See the
+"Making LAMMPS"_Section_start.html#start_3 section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Mixing, shift, table, tail correction, restart, rRESPA info]:
 
 Any pair potential settings made via the
diff --git a/doc/pair_line_lj.html b/doc/pair_line_lj.html
new file mode 100644
index 0000000000..26e28931b5
--- /dev/null
+++ b/doc/pair_line_lj.html
@@ -0,0 +1,141 @@
+
+
              LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
              
+
+
+
+
+
+
+
              
+
+
              pair_style line/lj command 
+
              
+
              pair_style line/lj/omp command 
+
              
+
              Syntax:
+
              
+
              pair_style line/lj cutoff 
+
              
+
              cutoff = global cutoff for interactions (distance units)
+
              
+
              Examples:
+
              
+
              pair_style line/lj 3.0
+pair_coeff * * 1.0 1.0
+pair_coeff 1 1 1.0 1.5 2.5 
+
              
+
              Description:
+
              
+
              Style line/lj treats particles which are line segments as a set of
+small spherical particles that tile the line segment length as
+explained below.  Interactions between two line segments, each with N1
+and N2 spherical particles, are calculated as the pairwise sum of
+N1*N2 Lennard-Jones interactions.  Interactions between a line segment
+with N spherical particles and a point particle are treated as the
+pairwise sum of N Lennard-Jones interactions.  See the pair_style
+lj/cut doc page for the definition of Lennard-Jones
+interactions.
+
              
+
              The cutoff distance for an interaction between 2 line segments, or
+between a line segment and a point particle, is calculated from the
+position of the line segment (its center), not between pairs of
+individual spheres comprising the line segment.  Thus an interaction
+is either calculated in its entirety or not at all.
+
              
+
              The set of non-overlapping spherical particles that represent a line
+segment, for purposes of this pair style, are generated in the
+following manner.  Their size is a function of the line segment length
+and the specified sigma for that particle type.  If a line segment has
+a length L and is of type I, then the number of spheres N that
+represent the segment is calculated as N = L/sigma_II, rounded up to
+an integer value.  Thus if L is not evenly divisibly by sigam_II, N is
+incremented to include one extra sphere.  In this case, the spheres
+must be slightly smaller than sigma_II so as not to overlap, so a new
+sigma-prime is chosen as the sphere diameter, such that L/N =
+sigma-prime.  Thus the line segment interacts with other segments or
+point particles as a collection of N spheres of diameter sigma-prime,
+evenly spaced along the line segment, so as to exactly cover its
+length.
+
              
+
              The LJ interaction between 2 spheres on different line segments of
+types I,J is computed with an arithmetic mixing of the sigma values of
+the 2 spheres and using the specified epsilon value for I,J atom
+types.  Note that because the sigma values for line segment spheres is
+computed using only sigma_II values, specific to the line segment's
+type, this means that any specified sigma_IJ values (for I != J) are
+effectively ignored.
+
              
+
              For style line/lj, the following coefficients must be defined for
+each pair of atoms types via the pair_coeff command
+as in the examples above, or in the data file or restart files read by
+the read_data or read_restart
+commands:
+
              
+
              • epsilon (energy units)
+
              • sigma (distance units)
+
              • cutoff (distance units) 
+
              
+
              The last coefficient is optional.  If not specified, the global cutoff
+is used.
+
              
+
              
+
+
              Styles with a cuda, gpu, omp, or opt suffix are functionally
+the same as the corresponding style without the suffix.  They have
+been optimized to run faster, depending on your available hardware,
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
              
+
              These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
              
+
              You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
              
+
              See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
              
+
              
+
+
              Mixing, shift, table, tail correction, restart, rRESPA info:
+
              
+
              For atom type pairs I,J and I != J, the epsilon and sigma coefficients
+and cutoff distance for all of this pair style can be mixed.  The
+default mix value is geometric.  See the "pair_modify" command for
+details.
+
              
+
              This pair style does not support the pair_modify
+shift, table, and tail options.
+
              
+
              This pair style does not write its information to binary restart
+files.
+
              
+
              This pair style can only be used via the pair keyword of the
+run_style respa command.  It does not support the
+inner, middle, outer keywords.
+
              
+
              
+
+
              Restrictions:
+
              
+
              This style is part of the ASPHERE package.  It is only enabled if
+LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
              
+
              Defining particles to be line segments so they participate in
+line/line or line/particle interactions requires the use the
+atom_style line command.
+
              
+
              Related commands:
+
              
+
              pair_coeff, pair_style tri/lj
+
              
+
              Default: none
+
              
+
diff --git a/doc/pair_line_lj.txt b/doc/pair_line_lj.txt
new file mode 100644
index 0000000000..7fc679eb46
--- /dev/null
+++ b/doc/pair_line_lj.txt
@@ -0,0 +1,135 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+pair_style line/lj command :h3
+pair_style line/lj/omp command :h3
+
+[Syntax:]
+
+pair_style line/lj cutoff :pre
+
+cutoff = global cutoff for interactions (distance units)
+
+[Examples:]
+
+pair_style line/lj 3.0
+pair_coeff * * 1.0 1.0
+pair_coeff 1 1 1.0 1.5 2.5 :pre
+
+[Description:]
+
+Style {line/lj} treats particles which are line segments as a set of
+small spherical particles that tile the line segment length as
+explained below.  Interactions between two line segments, each with N1
+and N2 spherical particles, are calculated as the pairwise sum of
+N1*N2 Lennard-Jones interactions.  Interactions between a line segment
+with N spherical particles and a point particle are treated as the
+pairwise sum of N Lennard-Jones interactions.  See the "pair_style
+lj/cut"_pair_lj.html doc page for the definition of Lennard-Jones
+interactions.
+
+The cutoff distance for an interaction between 2 line segments, or
+between a line segment and a point particle, is calculated from the
+position of the line segment (its center), not between pairs of
+individual spheres comprising the line segment.  Thus an interaction
+is either calculated in its entirety or not at all.
+
+The set of non-overlapping spherical particles that represent a line
+segment, for purposes of this pair style, are generated in the
+following manner.  Their size is a function of the line segment length
+and the specified sigma for that particle type.  If a line segment has
+a length L and is of type I, then the number of spheres N that
+represent the segment is calculated as N = L/sigma_II, rounded up to
+an integer value.  Thus if L is not evenly divisibly by sigam_II, N is
+incremented to include one extra sphere.  In this case, the spheres
+must be slightly smaller than sigma_II so as not to overlap, so a new
+sigma-prime is chosen as the sphere diameter, such that L/N =
+sigma-prime.  Thus the line segment interacts with other segments or
+point particles as a collection of N spheres of diameter sigma-prime,
+evenly spaced along the line segment, so as to exactly cover its
+length.
+
+The LJ interaction between 2 spheres on different line segments of
+types I,J is computed with an arithmetic mixing of the sigma values of
+the 2 spheres and using the specified epsilon value for I,J atom
+types.  Note that because the sigma values for line segment spheres is
+computed using only sigma_II values, specific to the line segment's
+type, this means that any specified sigma_IJ values (for I != J) are
+effectively ignored.
+
+For style {line/lj}, the following coefficients must be defined for
+each pair of atoms types via the "pair_coeff"_pair_coeff.html command
+as in the examples above, or in the data file or restart files read by
+the "read_data"_read_data.html or "read_restart"_read_restart.html
+commands:
+
+epsilon (energy units)
+sigma (distance units)
+cutoff (distance units) :ul
+
+The last coefficient is optional.  If not specified, the global cutoff
+is used.
+
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally
+the same as the corresponding style without the suffix.  They have
+been optimized to run faster, depending on your available hardware,
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
+[Mixing, shift, table, tail correction, restart, rRESPA info]:
+
+For atom type pairs I,J and I != J, the epsilon and sigma coefficients
+and cutoff distance for all of this pair style can be mixed.  The
+default mix value is {geometric}.  See the "pair_modify" command for
+details.
+
+This pair style does not support the "pair_modify"_pair_modify.html
+shift, table, and tail options.
+
+This pair style does not write its information to "binary restart
+files"_restart.html.
+
+This pair style can only be used via the {pair} keyword of the
+"run_style respa"_run_style.html command.  It does not support the
+{inner}, {middle}, {outer} keywords.
+
+:line
+
+[Restrictions:]
+
+This style is part of the ASPHERE package.  It is only enabled if
+LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#2_3 section for more info.
+
+Defining particles to be line segments so they participate in
+line/line or line/particle interactions requires the use the
+"atom_style line"_atom_style.html command.
+
+[Related commands:]
+
+"pair_coeff"_pair_coeff.html, "pair_style tri/lj"_pair_tri_lj.html
+
+[Default:] none
diff --git a/doc/pair_lj.html b/doc/pair_lj.html
index 9e5c9fc6c0..91fba09a41 100644
--- a/doc/pair_lj.html
+++ b/doc/pair_lj.html
@@ -11,43 +11,60 @@
 
 
              pair_style lj/cut command 
 
              
+
              pair_style lj/cut/cuda command 
+
              
+
              pair_style lj/cut/experimental/cuda command 
+
              
 
              pair_style lj/cut/gpu command 
 
              
 
              pair_style lj/cut/omp command 
 
              
 
              pair_style lj/cut/opt command 
 
              
+
              pair_style lj/cut/omp command 
+
              
 
              pair_style lj/cut/coul/cut command 
 
              
+
              pair_style lj/cut/coul/cut/cuda command 
+
              
 
              pair_style lj/cut/coul/cut/gpu command 
 
              
+
              pair_style lj/cut/coul/cut/omp command 
+
              
 
              pair_style lj/cut/coul/debye command 
 
              
+
              pair_style lj/cut/coul/debye/cuda command 
+
              
+
              pair_style lj/cut/coul/debye/omp command 
+
              
 
              pair_style lj/cut/coul/long command 
 
              
+
              pair_style lj/cut/coul/long/cuda command 
+
              
 
              pair_style lj/cut/coul/long/gpu command 
 
              
+
              pair_style lj/cut/coul/long/opt command 
+
              
+
              pair_style lj/cut/coul/long/omp command 
+
              
 
              pair_style lj/cut/coul/long/tip4p command 
 
              
+
              pair_style lj/cut/coul/long/tip4p/omp command 
+
              
+
              pair_style lj/cut/coul/long/tip4p/opt command 
+
              
 
              Syntax:
 
              
 
              pair_style style args 
 
              
-
              • style = lj/cut or lj/cut/gpu or lj/cut/opt or lj/cut/coul/cut         or lj/cut/coul/debye or lj/cut/coul/long or lj/cut/coul/long/tip4p
+
                • style = lj/cut or lj/cut/coul/cut or lj/cut/coul/debye or lj/cut/coul/long or lj/cut/coul/long/tip4p
 
                • args = list of arguments for a particular style 
 
                
 
                  lj/cut args = cutoff
     cutoff = global cutoff for Lennard Jones interactions (distance units)
-  lj/cut/gpu args = cutoff
-    cutoff = global cutoff for Lennard Jones interactions (distance units)
-  lj/cut/opt args = cutoff
-    cutoff = global cutoff for Lennard Jones interactions (distance units)
   lj/cut/coul/cut args = cutoff (cutoff2)
     cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
     cutoff2 = global cutoff for Coulombic (optional) (distance units)
-  lj/cut/coul/cut/gpu args = cutoff (cutoff2)
-    cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
-    cutoff2 = global cutoff for Coulombic (optional) (distance units)
   lj/cut/coul/debye args = kappa cutoff (cutoff2)
     kappa = Debye length (inverse distance units)
     cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
@@ -55,9 +72,6 @@
   lj/cut/coul/long args = cutoff (cutoff2)
     cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
     cutoff2 = global cutoff for Coulombic (optional) (distance units)
-  lj/cut/coul/long/gpu args = cutoff (cutoff2)
-    cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
-    cutoff2 = global cutoff for Coulombic (optional) (distance units)
   lj/cut/coul/long/tip4p args = otype htype btype atype qdist cutoff (cutoff2)
     otype,htype = atom types for TIP4P O and H
     btype,atype = bond and angle types for TIP4P waters
@@ -68,13 +82,10 @@
 
                Examples:
 
                
 
                pair_style lj/cut 2.5
-pair_style lj/cut/gpu 2.5
-pair_style lj/cut/opt 2.5
 pair_coeff * * 1 1
 pair_coeff 1 1 1 1.1 2.8 
 
                
 
                pair_style lj/cut/coul/cut 10.0
-pair_style lj/cut/coul/cut/gpu 10.0
 pair_style lj/cut/coul/cut 10.0 8.0
 pair_coeff * * 100.0 3.0
 pair_coeff 1 1 100.0 3.5 9.0
@@ -87,7 +98,6 @@ pair_coeff 1 1 1.0 1.5 2.5
 pair_coeff 1 1 1.0 1.5 2.5 5.0 
 
                
 
                pair_style lj/cut/coul/long 10.0
-pair_style lj/cut/coul/long/gpu 10.0
 pair_style lj/cut/coul/long 10.0 8.0
 pair_coeff * * 100.0 3.0
 pair_coeff 1 1 100.0 3.5 9.0 
@@ -106,14 +116,6 @@ given by

    • Rc is the cutoff.

    -

    Style lj/cut/gpu is a GPU-enabled version of style lj/cut. -See more details below. -

    -

    Style lj/cut/opt is an optimized version of style lj/cut that -should give identical answers. Depending on system size and the -processor you are running on, it may be 5-25% faster (for the pairwise -portion of the run time). -

    Style lj/cut/coul/cut adds a Coulombic pairwise interaction given by

    @@ -125,9 +127,6 @@ specified in the pair_style command, it is used for both the LJ and Coulombic terms. If two cutoffs are specified, they are used as cutoffs for the LJ and Coulombic terms respectively.

    -

    Style lj/cut/coul/cut/gpu is a GPU-enabled version of style lj/cut/coul/cut. -See more details below. -

    Style lj/cut/coul/debye adds an additional exp() damping factor to the Coulombic term, given by

    @@ -144,9 +143,6 @@ option. The Coulombic cutoff specified for this style means that pairwise interactions within this distance are computed directly; interactions outside that distance are computed in reciprocal space.

    -

    Style lj/cut/coul/long/gpu is a GPU-enabled version of style lj/cut/coul/long. -See more details below. -

    Style lj/cut/coul/long/tip4p implements the TIP4P water model of (Jorgensen), which introduces a massless site located a short distance away from the oxygen atom along the bisector of the HOH @@ -160,8 +156,8 @@ first. This is to enable LAMMPS to "find" the 2 H atoms associated with each O atom. For example, if the atom ID of an O atom in a TIP4P water molecule is 500, then its 2 H atoms must have IDs 501 and 502.

    -

    See the howto section for more information on -how to use the TIP4P pair style. +

    See the howto section for more +information on how to use the TIP4P pair style.

    The following coefficients must be defined for each pair of atoms types via the pair_coeff command as in the examples @@ -191,26 +187,37 @@ can be specified since a Coulombic cutoff cannot be specified for an individual I,J type pair. All type pairs use the same global Coulombic cutoff specified in the pair_style command.

    +

    Styles lj/cut/coul/pppm/omp and lj/cut/coul/pppm/tip4p/omp +are variants of lj/cut/coul/long/omp and lj/cut/coul/long/tip4p/omp +for use with k-space styles pppm/proxy and +pppm/tip4p/proxy, respectively and OpenMP +multi-threading and will perform the corresponding reciprocal +space calculation concurrently with the pair calculation +in a separate thread. For certain parallel setups, this may have +a performance benefit over performing k-space style and pair style +separately and one after the other. +

    -

    The lj/cut/gpu, lj/cut/coul/cut/gpu, and lj/cut/coul/long/gpu styles -are identical to the lj/cut, lj/cut/coul/cut, and lj/cut/coul/long -styles, except that each processor off-loads its pairwise calculations to a -GPU chip. Depending on the hardware available on your system this can provide a -speed-up. See the Running on GPUs section of -the manual for more details about hardware and software requirements -for using GPUs. +

    Styles with a cuda, gpu, omp, or opt suffix are functionally +the same as the corresponding style without the suffix. They have +been optimized to run faster, depending on your available hardware, +as discussed in this section of the manual. +The accelerated styles take the same arguments and should produce the +same results, except for round-off and precision issues.

    -

    More details about these settings and various possible hardware -configuration are in this section of the -manual. +

    These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT +packages, respectively. They are only enabled if LAMMPS was built with +those packages. See the Making LAMMPS +section for more info.

    -

    Additional requirements in your input script to run with GPU-enabled styles -are as follows: +

    You can specify the accelerated styles explicitly in your input script +by including their suffix, or you can use the -suffix command-line +switch when you invoke LAMMPS, or you can +use the suffix command in your input script.

    -

    The newton pair setting must be off and -fix gpu must be used. The fix controls -the essential GPU selection and initialization steps. +

    See this section of the manual for more +instructions on how to use the accelerated styles effectively.

    @@ -251,17 +258,10 @@ See the run_style command for details.

    Restrictions:

    The lj/cut/coul/long and lj/cut/coul/long/tip4p styles are part of -the "kspace" package. The lj/cut/gpu, lj/cut/coul/cut/gpu, and -lj/cut/coul/long/gpu styles are part of the "gpu" -package. The lj/cut/opt style is part of the "opt" package. They -are only enabled if LAMMPS was built with those packages. See the -Making LAMMPS section for more info. Note -that the "kspace" package is installed by default. -

    -

    On some 64-bit machines, compiling with -O3 appears to break the -Coulombic tabling option used by the lj/cut/coul/long style. See -the "Additional build tips" section of the Making LAMMPS documentation -pages for workarounds on this issue. +the KSPACE package. They are only enabled if LAMMPS was built with +those packages. See the Making LAMMPS +section for more info. Note that the KSPACE package is installed by +default.

    Related commands:

    diff --git a/doc/pair_lj.txt b/doc/pair_lj.txt index fa90322b37..13e4584e50 100644 --- a/doc/pair_lj.txt +++ b/doc/pair_lj.txt @@ -7,35 +7,39 @@ :line pair_style lj/cut command :h3 +pair_style lj/cut/cuda command :h3 +pair_style lj/cut/experimental/cuda command :h3 pair_style lj/cut/gpu command :h3 pair_style lj/cut/omp command :h3 pair_style lj/cut/opt command :h3 +pair_style lj/cut/omp command :h3 pair_style lj/cut/coul/cut command :h3 +pair_style lj/cut/coul/cut/cuda command :h3 pair_style lj/cut/coul/cut/gpu command :h3 +pair_style lj/cut/coul/cut/omp command :h3 pair_style lj/cut/coul/debye command :h3 +pair_style lj/cut/coul/debye/cuda command :h3 +pair_style lj/cut/coul/debye/omp command :h3 pair_style lj/cut/coul/long command :h3 +pair_style lj/cut/coul/long/cuda command :h3 pair_style lj/cut/coul/long/gpu command :h3 +pair_style lj/cut/coul/long/opt command :h3 +pair_style lj/cut/coul/long/omp command :h3 pair_style lj/cut/coul/long/tip4p command :h3 +pair_style lj/cut/coul/long/tip4p/omp command :h3 +pair_style lj/cut/coul/long/tip4p/opt command :h3 [Syntax:] pair_style style args :pre -style = {lj/cut} or {lj/cut/gpu} or {lj/cut/opt} or {lj/cut/coul/cut} \ - or {lj/cut/coul/debye} or {lj/cut/coul/long} or {lj/cut/coul/long/tip4p} +style = {lj/cut} or {lj/cut/coul/cut} or {lj/cut/coul/debye} or {lj/cut/coul/long} or {lj/cut/coul/long/tip4p} args = list of arguments for a particular style :ul {lj/cut} args = cutoff cutoff = global cutoff for Lennard Jones interactions (distance units) - {lj/cut/gpu} args = cutoff - cutoff = global cutoff for Lennard Jones interactions (distance units) - {lj/cut/opt} args = cutoff - cutoff = global cutoff for Lennard Jones interactions (distance units) {lj/cut/coul/cut} args = cutoff (cutoff2) cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units) cutoff2 = global cutoff for Coulombic (optional) (distance units) - {lj/cut/coul/cut/gpu} args = cutoff (cutoff2) - cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units) - cutoff2 = global cutoff for Coulombic (optional) (distance units) {lj/cut/coul/debye} args = kappa cutoff (cutoff2) kappa = Debye length (inverse distance units) cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units) @@ -43,9 +47,6 @@ args = list of arguments for a particular style :ul {lj/cut/coul/long} args = cutoff (cutoff2) cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units) cutoff2 = global cutoff for Coulombic (optional) (distance units) - {lj/cut/coul/long/gpu} args = cutoff (cutoff2) - cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units) - cutoff2 = global cutoff for Coulombic (optional) (distance units) {lj/cut/coul/long/tip4p} args = otype htype btype atype qdist cutoff (cutoff2) otype,htype = atom types for TIP4P O and H btype,atype = bond and angle types for TIP4P waters @@ -56,13 +57,10 @@ args = list of arguments for a particular style :ul [Examples:] pair_style lj/cut 2.5 -pair_style lj/cut/gpu 2.5 -pair_style lj/cut/opt 2.5 pair_coeff * * 1 1 pair_coeff 1 1 1 1.1 2.8 :pre pair_style lj/cut/coul/cut 10.0 -pair_style lj/cut/coul/cut/gpu 10.0 pair_style lj/cut/coul/cut 10.0 8.0 pair_coeff * * 100.0 3.0 pair_coeff 1 1 100.0 3.5 9.0 @@ -75,7 +73,6 @@ pair_coeff 1 1 1.0 1.5 2.5 pair_coeff 1 1 1.0 1.5 2.5 5.0 :pre pair_style lj/cut/coul/long 10.0 -pair_style lj/cut/coul/long/gpu 10.0 pair_style lj/cut/coul/long 10.0 8.0 pair_coeff * * 100.0 3.0 pair_coeff 1 1 100.0 3.5 9.0 :pre @@ -94,14 +91,6 @@ given by Rc is the cutoff. -Style {lj/cut/gpu} is a GPU-enabled version of style {lj/cut}. -See more details below. - -Style {lj/cut/opt} is an optimized version of style {lj/cut} that -should give identical answers. Depending on system size and the -processor you are running on, it may be 5-25% faster (for the pairwise -portion of the run time). - Style {lj/cut/coul/cut} adds a Coulombic pairwise interaction given by :c,image(Eqs/pair_coulomb.jpg) @@ -113,9 +102,6 @@ specified in the pair_style command, it is used for both the LJ and Coulombic terms. If two cutoffs are specified, they are used as cutoffs for the LJ and Coulombic terms respectively. -Style {lj/cut/coul/cut/gpu} is a GPU-enabled version of style {lj/cut/coul/cut}. -See more details below. - Style {lj/cut/coul/debye} adds an additional exp() damping factor to the Coulombic term, given by @@ -132,9 +118,6 @@ option. The Coulombic cutoff specified for this style means that pairwise interactions within this distance are computed directly; interactions outside that distance are computed in reciprocal space. -Style {lj/cut/coul/long/gpu} is a GPU-enabled version of style {lj/cut/coul/long}. -See more details below. - Style {lj/cut/coul/long/tip4p} implements the TIP4P water model of "(Jorgensen)"_#Jorgensen, which introduces a massless site located a short distance away from the oxygen atom along the bisector of the HOH @@ -148,8 +131,8 @@ first. This is to enable LAMMPS to "find" the 2 H atoms associated with each O atom. For example, if the atom ID of an O atom in a TIP4P water molecule is 500, then its 2 H atoms must have IDs 501 and 502. -See the "howto section"_Section_howto.html#4_8 for more information on -how to use the TIP4P pair style. +See the "howto section"_Section_howto.html#howto_8 for more +information on how to use the TIP4P pair style. The following coefficients must be defined for each pair of atoms types via the "pair_coeff"_pair_coeff.html command as in the examples @@ -179,26 +162,37 @@ can be specified since a Coulombic cutoff cannot be specified for an individual I,J type pair. All type pairs use the same global Coulombic cutoff specified in the pair_style command. +Styles {lj/cut/coul/pppm/omp} and {lj/cut/coul/pppm/tip4p/omp} +are variants of {lj/cut/coul/long/omp} and {lj/cut/coul/long/tip4p/omp} +for use with k-space styles "{pppm/proxy}"_kspace_style.html and +"{pppm/tip4p/proxy}"_kspace_style.html, respectively and OpenMP +multi-threading and will perform the corresponding reciprocal +space calculation concurrently with the pair calculation +in a separate thread. For certain parallel setups, this may have +a performance benefit over performing k-space style and pair style +separately and one after the other. + :line -The {lj/cut/gpu}, {lj/cut/coul/cut/gpu}, and {lj/cut/coul/long/gpu} styles -are identical to the {lj/cut}, {lj/cut/coul/cut}, and {lj/cut/coul/long} -styles, except that each processor off-loads its pairwise calculations to a -GPU chip. Depending on the hardware available on your system this can provide a -speed-up. See the "Running on GPUs"_Section_start.html#2_8 section of -the manual for more details about hardware and software requirements -for using GPUs. +Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally +the same as the corresponding style without the suffix. They have +been optimized to run faster, depending on your available hardware, +as discussed in "this section"_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. -More details about these settings and various possible hardware -configuration are in "this section"_Section_start.html#2_8 of the -manual. +These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT +packages, respectively. They are only enabled if LAMMPS was built with +those packages. See the "Making LAMMPS"_Section_start.html#start_3 +section for more info. -Additional requirements in your input script to run with GPU-enabled styles -are as follows: +You can specify the accelerated styles explicitly in your input script +by including their suffix, or you can use the "-suffix command-line +switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can +use the "suffix"_suffix.html command in your input script. -The "newton pair"_newton.html setting must be {off} and -"fix gpu"_fix_gpu.html must be used. The fix controls -the essential GPU selection and initialization steps. +See "this section"_Section_accelerate.html of the manual for more +instructions on how to use the accelerated styles effectively. :line @@ -239,17 +233,10 @@ See the "run_style"_run_style.html command for details. [Restrictions:] The {lj/cut/coul/long} and {lj/cut/coul/long/tip4p} styles are part of -the "kspace" package. The {lj/cut/gpu}, {lj/cut/coul/cut/gpu}, and -{lj/cut/coul/long/gpu} styles are part of the "gpu" -package. The {lj/cut/opt} style is part of the "opt" package. They -are only enabled if LAMMPS was built with those packages. See the -"Making LAMMPS"_Section_start.html#2_3 section for more info. Note -that the "kspace" package is installed by default. - -On some 64-bit machines, compiling with -O3 appears to break the -Coulombic tabling option used by the {lj/cut/coul/long} style. See -the "Additional build tips" section of the Making LAMMPS documentation -pages for workarounds on this issue. +the KSPACE package. They are only enabled if LAMMPS was built with +those packages. See the "Making LAMMPS"_Section_start.html#start_3 +section for more info. Note that the KSPACE package is installed by +default. [Related commands:] diff --git a/doc/pair_lj96_cut.html b/doc/pair_lj96.html similarity index 66% rename from doc/pair_lj96_cut.html rename to doc/pair_lj96.html index 997ba0983c..97d794d73e 100644 --- a/doc/pair_lj96_cut.html +++ b/doc/pair_lj96.html @@ -11,19 +11,21 @@

    pair_style lj96/cut command

    +

    pair_style lj96/cut/cuda command +

    pair_style lj96/cut/gpu command

    +

    pair_style lj96/cut/omp command +

    Syntax:

    -
    pair_style style cutoff 
+
    pair_style lj96/cut cutoff 
 
    
-
    • style = lj96/cut or lj96/cut/gpu
-
    • cutoff = global cutoff for lj96/cut interactions (distance units) 
+
      • cutoff = global cutoff for lj96/cut interactions (distance units) 
 
      
 
      Examples:
 
      
 
      pair_style lj96/cut 2.5
-pair_style lj96/cut/gpu 2.5
 pair_coeff * * 1.0 1.0 4.0
 pair_coeff 1 1 1.0 1.0 
 
      
@@ -36,9 +38,6 @@ of the standard 12/6 potential, given by

    Rc is the cutoff.

    -

    Style lj96/cut/gpu is a GPU-enabled version of style lj96/cut. -See more details below. -

    The following coefficients must be defined for each pair of atoms types via the pair_coeff command as in the examples above, or in the data file or restart files read by the @@ -54,23 +53,25 @@ cutoff specified in the pair_style command is used.

    -

    The lj96/cut/gpu style is identical to the lj96/cut style, except that -each processor off-loads its pairwise calculations to a -GPU chip. Depending on the hardware available on your system this can provide a -speed-up. See the Running on GPUs section of -the manual for more details about hardware and software requirements -for using GPUs. +

    Styles with a cuda, gpu, omp, or opt suffix are functionally +the same as the corresponding style without the suffix. They have +been optimized to run faster, depending on your available hardware, +as discussed in this section of the manual. +The accelerated styles take the same arguments and should produce the +same results, except for round-off and precision issues.

    -

    More details about these settings and various possible hardware -configuration are in this section of the -manual. +

    These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT +packages, respectively. They are only enabled if LAMMPS was built with +those packages. See the Making LAMMPS +section for more info.

    -

    Additional requirements in your input script to run with the lj96/cut/gpu -style are as follows: +

    You can specify the accelerated styles explicitly in your input script +by including their suffix, or you can use the -suffix command-line +switch when you invoke LAMMPS, or you can +use the suffix command in your input script.

    -

    The newton pair setting must be off and -fix gpu must be used. The fix controls the -essential GPU selection and initialization steps +

    See this section of the manual for more +instructions on how to use the accelerated styles effectively.

    @@ -103,11 +104,7 @@ details.

    -

    Restrictions: -

    -

    The lj96/cut/gpu style is part of the "gpu" package. It -is only enabled if LAMMPS is built with this packages. See the -Making LAMMPS section for more info. +

    Restrictions: none

    Related commands:

    diff --git a/doc/pair_lj96_cut.txt b/doc/pair_lj96.txt similarity index 66% rename from doc/pair_lj96_cut.txt rename to doc/pair_lj96.txt index 892fc6fa8a..dcdb3632c5 100644 --- a/doc/pair_lj96_cut.txt +++ b/doc/pair_lj96.txt @@ -7,19 +7,19 @@ :line pair_style lj96/cut command :h3 +pair_style lj96/cut/cuda command :h3 pair_style lj96/cut/gpu command :h3 +pair_style lj96/cut/omp command :h3 [Syntax:] -pair_style style cutoff :pre +pair_style lj96/cut cutoff :pre -style = {lj96/cut} or {lj96/cut/gpu} cutoff = global cutoff for lj96/cut interactions (distance units) :ul [Examples:] pair_style lj96/cut 2.5 -pair_style lj96/cut/gpu 2.5 pair_coeff * * 1.0 1.0 4.0 pair_coeff 1 1 1.0 1.0 :pre @@ -32,9 +32,6 @@ of the standard 12/6 potential, given by Rc is the cutoff. -Style {lj96/cut/gpu} is a GPU-enabled version of style {lj96/cut}. -See more details below. - The following coefficients must be defined for each pair of atoms types via the "pair_coeff"_pair_coeff.html command as in the examples above, or in the data file or restart files read by the @@ -50,23 +47,25 @@ cutoff specified in the pair_style command is used. :line -The {lj96/cut/gpu} style is identical to the {lj96/cut} style, except that -each processor off-loads its pairwise calculations to a -GPU chip. Depending on the hardware available on your system this can provide a -speed-up. See the "Running on GPUs"_Section_start.html#2_8 section of -the manual for more details about hardware and software requirements -for using GPUs. +Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally +the same as the corresponding style without the suffix. They have +been optimized to run faster, depending on your available hardware, +as discussed in "this section"_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. -More details about these settings and various possible hardware -configuration are in "this section"_Section_start.html#2_8 of the -manual. +These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT +packages, respectively. They are only enabled if LAMMPS was built with +those packages. See the "Making LAMMPS"_Section_start.html#start_3 +section for more info. -Additional requirements in your input script to run with the {lj96/cut/gpu} -style are as follows: +You can specify the accelerated styles explicitly in your input script +by including their suffix, or you can use the "-suffix command-line +switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can +use the "suffix"_suffix.html command in your input script. -The "newton pair"_newton.html setting must be {off} and -"fix gpu"_fix_gpu.html must be used. The fix controls the -essential GPU selection and initialization steps +See "this section"_Section_accelerate.html of the manual for more +instructions on how to use the accelerated styles effectively. :line @@ -99,11 +98,7 @@ details. :line -[Restrictions:] - -The {lj96/cut/gpu} style is part of the "gpu" package. It -is only enabled if LAMMPS is built with this packages. See the -"Making LAMMPS"_Section_start.html#2_3 section for more info. +[Restrictions:] none [Related commands:] diff --git a/doc/pair_lj_coul.html b/doc/pair_lj_coul.html index 4aac46fe7b..9faaba8715 100644 --- a/doc/pair_lj_coul.html +++ b/doc/pair_lj_coul.html @@ -11,6 +11,8 @@

    pair_style lj/coul command

    +

    pair_style lj/coul/omp command +

    Syntax: 

    pair_style lj/coul flag_lj flag_coul cutoff (cutoff2) 
@@ -105,6 +107,28 @@ pair, since only one global Coulombic cutoff is allowed.
 
    
 
    
 
+
    Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
 
    Mixing, shift, table, tail correction, restart, rRESPA info:
 
    
 
    For atom type pairs I,J and I != J, the epsilon and sigma coefficients
@@ -138,15 +162,10 @@ details.
 
 
    Restrictions:
 
    
-
    This style is part of the "user-ewaldn" package.  It is only enabled
-if LAMMPS was built with that package.  See the Making
+
    This style is part of the USER-EWALDN package.  It is only enabled if
+LAMMPS was built with that package.  See the Making
 LAMMPS section for more info.
 
    
-
    On some 64-bit machines, compiling with -O3 appears to break the
-Coulombic tabling option used by the lj/coul style.  See the
-"Additional build tips" section of the Making LAMMPS documentation
-pages for workarounds on this issue.
-
    
 
    Related commands:
 
    
 
    pair_coeff
diff --git a/doc/pair_lj_coul.txt b/doc/pair_lj_coul.txt
index 7663c48d1d..1593ca4170 100644
--- a/doc/pair_lj_coul.txt
+++ b/doc/pair_lj_coul.txt
@@ -7,6 +7,7 @@
 :line
 
 pair_style lj/coul command :h3
+pair_style lj/coul/omp command :h3
 
 [Syntax:]
 
@@ -97,6 +98,28 @@ pair, since only one global Coulombic cutoff is allowed.
 
 :line
 
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Mixing, shift, table, tail correction, restart, rRESPA info]:
 
 For atom type pairs I,J and I != J, the epsilon and sigma coefficients
@@ -130,14 +153,9 @@ details.
 
 [Restrictions:]
 
-This style is part of the "user-ewaldn" package.  It is only enabled
-if LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
-
-On some 64-bit machines, compiling with -O3 appears to break the
-Coulombic tabling option used by the {lj/coul} style.  See the
-"Additional build tips" section of the Making LAMMPS documentation
-pages for workarounds on this issue.
+This style is part of the USER-EWALDN 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:]
 
diff --git a/doc/pair_lj_cubic.html b/doc/pair_lj_cubic.html
new file mode 100644
index 0000000000..b5d72b8452
--- /dev/null
+++ b/doc/pair_lj_cubic.html
@@ -0,0 +1,136 @@
+
+
    LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
    
+
+
+
+
+
+
+
    
+
+
    pair_style lj/cubic command 
+
    
+
    pair_style lj/cubic/omp command 
+
    
+
    Syntax:
+
    
+
    pair_style lj/cubic 
+
    
+
    Examples:
+
    
+
    pair_style lj/cubic
+pair_coeff * * 1.0 0.8908987 
+
    
+
    Description:
+
    
+
    The lj/cubic style computes a truncated LJ interaction potential whose
+energy and force are continuous everywhere. 
+Inside the inflection point the interaction is identical to the 
+standard 12/6 Lennard-Jones potential.
+The LJ function outside the inflection point is replaced 
+with a cubic function of distance. The energy, force, and second
+derivative are continuous at the inflection point. 
+The cubic coefficient A3 is chosen so
+that both energy and force go to zero at the cutoff distance. 
+Outside the cutoff distance the energy and force are zero.
+
    
+
    
+
    
+
    The location of the inflection point rs is defined
+by the LJ diameter, rs/sigma = (26/7)^1/6. The cutoff distance 
+is defined by rc/rs = 67/48 or rc/sigma = 1.737.... 
+The analytic expression for the 
+the cubic coefficient 
+A3*rmin^3/epsilon = 27.93... is given in the paper by
+Holian and Ravelo (Holian).
+
    
+
    This potential is commonly used to study the shock mechanics
+of FCC solids, as in Ravelo et al. (Ravelo).
+
    
+
    The following coefficients must be defined for each pair of atom
+types via the pair_coeff command as in the example
+above, or in the data file or restart files read by the
+read_data or read_restart
+commands, or by mixing as described below:
+
    
+
    • epsilon (energy units)
+
    • sigma (distance units) 
+
    
+
    Note that sigma is defined in the LJ formula as the zero-crossing
+distance for the potential, not as the energy minimum, which
+is located at rmin = 2^(1/6)*sigma. In the above example, sigma = 0.8908987,
+so rmin = 1.
+
    
+
    
+
+
    Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
+
    Mixing, shift, table, tail correction, restart, rRESPA info:
+
    
+
    For atom type pairs I,J and I != J, the epsilon and sigma coefficients
+and cutoff distance for all of the lj/cut pair styles can be mixed.
+The default mix value is geometric.  See the "pair_modify" command
+for details.
+
    
+
    The lj/cubic pair style does not support the
+pair_modify shift option, 
+since pair interaction is already smoothed to 0.0 at the
+cutoff.
+
    
+
    The pair_modify table option is not relevant
+for this pair style.
+
    
+
    The lj/cubic pair style does not support the
+pair_modify tail option for adding long-range tail
+corrections to energy and pressure, since there are no corrections for
+a potential that goes to 0.0 at the cutoff.
+
    
+
    The lj/cubic pair style writes its information to binary
+restart files, so pair_style and pair_coeff commands do
+not need to be specified in an input script that reads a restart file.
+
    
+
    The lj/cubic pair style can only be used via the pair
+keyword of the run_style respa command.  It does not
+support the inner, middle, outer keywords.
+
    
+
    
+
+
    Restrictions: none
+
    
+
    Related commands:
+
    
+
    pair_coeff
+
    
+
    Default: none
+
    
+
    
+
+
+
+(Holian) Holian and Ravelo, Phys Rev B, 51, 11275 (1995).
+
+
+
    (Ravelo) Ravelo, Holian, Germann and Lomdahl, Phys Rev B, 70, 014103 (2004).
+
    
+
diff --git a/doc/pair_lj_cubic.txt b/doc/pair_lj_cubic.txt
new file mode 100644
index 0000000000..5d60cb12b4
--- /dev/null
+++ b/doc/pair_lj_cubic.txt
@@ -0,0 +1,128 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+pair_style lj/cubic command :h3
+pair_style lj/cubic/omp command :h3
+
+[Syntax:]
+
+pair_style lj/cubic :pre
+
+[Examples:]
+
+pair_style lj/cubic
+pair_coeff * * 1.0 0.8908987 :pre
+
+[Description:]
+
+The {lj/cubic} style computes a truncated LJ interaction potential whose
+energy and force are continuous everywhere. 
+Inside the inflection point the interaction is identical to the 
+standard 12/6 "Lennard-Jones"_pair_lj.html potential.
+The LJ function outside the inflection point is replaced 
+with a cubic function of distance. The energy, force, and second
+derivative are continuous at the inflection point. 
+The cubic coefficient A3 is chosen so
+that both energy and force go to zero at the cutoff distance. 
+Outside the cutoff distance the energy and force are zero.
+
+:c,image(Eqs/pair_lj_cubic.jpg)
+ 
+The location of the inflection point rs is defined
+by the LJ diameter, rs/sigma = (26/7)^1/6. The cutoff distance 
+is defined by rc/rs = 67/48 or rc/sigma = 1.737.... 
+The analytic expression for the 
+the cubic coefficient 
+A3*rmin^3/epsilon = 27.93... is given in the paper by
+Holian and Ravelo "(Holian)"_#Holian.
+
+This potential is commonly used to study the shock mechanics
+of FCC solids, as in Ravelo et al. "(Ravelo)"_#Ravelo.
+
+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, or in the data file or restart files read by the
+"read_data"_read_data.html or "read_restart"_read_restart.html
+commands, or by mixing as described below:
+
+epsilon (energy units)
+sigma (distance units) :ul
+
+Note that sigma is defined in the LJ formula as the zero-crossing
+distance for the potential, not as the energy minimum, which
+is located at rmin = 2^(1/6)*sigma. In the above example, sigma = 0.8908987,
+so rmin = 1.
+
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
+[Mixing, shift, table, tail correction, restart, rRESPA info]:
+
+For atom type pairs I,J and I != J, the epsilon and sigma coefficients
+and cutoff distance for all of the lj/cut pair styles can be mixed.
+The default mix value is {geometric}.  See the "pair_modify" command
+for details.
+
+The lj/cubic pair style does not support the
+"pair_modify"_pair_modify.html shift option, 
+since pair interaction is already smoothed to 0.0 at the
+cutoff.
+
+The "pair_modify"_pair_modify.html table option is not relevant
+for this pair style.
+
+The lj/cubic pair style does not support the
+"pair_modify"_pair_modify.html tail option for adding long-range tail
+corrections to energy and pressure, since there are no corrections for
+a potential that goes to 0.0 at the cutoff.
+
+The lj/cubic pair style writes its information to "binary
+restart files"_restart.html, so pair_style and pair_coeff commands do
+not need to be specified in an input script that reads a restart file.
+
+The lj/cubic pair style can only be used via the {pair}
+keyword of the "run_style respa"_run_style.html command.  It does not
+support the {inner}, {middle}, {outer} keywords.
+
+:line
+
+[Restrictions:] none
+
+[Related commands:]
+
+"pair_coeff"_pair_coeff.html
+
+[Default:] none
+
+:line
+
+:link(Holian)
+[(Holian)] Holian and Ravelo, Phys Rev B, 51, 11275 (1995).
+:link(Ravelo)
+[(Ravelo)] Ravelo, Holian, Germann and Lomdahl, Phys Rev B, 70, 014103 (2004).
diff --git a/doc/pair_lj_expand.html b/doc/pair_lj_expand.html
index 8dfb3d2068..9173bc7d5b 100644
--- a/doc/pair_lj_expand.html
+++ b/doc/pair_lj_expand.html
@@ -11,6 +11,12 @@
 
 
    pair_style lj/expand command 
 
    
+
    pair_style lj/expand/cuda command 
+
    
+
    pair_style lj/expand/gpu command 
+
    
+
    pair_style lj/expand/omp command 
+
    
 
    Syntax:
 
    
 
    pair_style lj/expand cutoff 
@@ -51,6 +57,28 @@ optional.  If not specified, the global LJ cutoff is used.
 
    
 
    
 
+
    Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
 
    Mixing, shift, table, tail correction, restart, rRESPA info:
 
    
 
    For atom type pairs I,J and I != J, the epsilon, sigma, and shift
diff --git a/doc/pair_lj_expand.txt b/doc/pair_lj_expand.txt
index 3c82f5b944..fc9fd047e0 100644
--- a/doc/pair_lj_expand.txt
+++ b/doc/pair_lj_expand.txt
@@ -7,6 +7,9 @@
 :line
 
 pair_style lj/expand command :h3
+pair_style lj/expand/cuda command :h3
+pair_style lj/expand/gpu command :h3
+pair_style lj/expand/omp command :h3
 
 [Syntax:]
 
@@ -48,6 +51,28 @@ optional.  If not specified, the global LJ cutoff is used.
 
 :line
 
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Mixing, shift, table, tail correction, restart, rRESPA info]:
 
 For atom type pairs I,J and I != J, the epsilon, sigma, and shift
diff --git a/doc/pair_lj_sf.html b/doc/pair_lj_sf.html
new file mode 100644
index 0000000000..7ff9011052
--- /dev/null
+++ b/doc/pair_lj_sf.html
@@ -0,0 +1,120 @@
+
+
    LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
    
+
+
+
+
+
+
+
    
+
+
    pair_style lj/sf command 
+
    
+
    pair_style lj/sf/omp command 
+
    
+
    Syntax:
+
    
+
    pair_style lj/sf cutoff 
+
    
+
    • cutoff = global cutoff for Lennard-Jones interactions (distance units) 
+
    
+
    Examples:
+
    
+
    pair_style lj/sf 2.5
+pair_coeff * * 1.0 1.0
+pair_coeff 1 1 1.0 1.0 3.0 
+
    
+
    Description:
+
    
+
    Style lj/sf computes a truncated and force-shifted LJ interaction
+(Shifted Force Lennard-Jones), so that both the potential and the
+force go continuously to zero at the cutoff (Toxvaerd):
+
    
+
    
+
    
+
    The following coefficients must be defined for each pair of atoms
+types via the pair_coeff command as in the examples
+above, or in the data file or restart files read by the
+read_data or read_restart
+commands, or by mixing as described below:
+
    
+
    • epsilon (energy units)
+
    • sigma (distance units)
+
    • cutoff (distance units) 
+
    
+
    The last coefficient is optional. If not specified, the global
+LJ cutoff specified in the pair_style command is used.
+
    
+
    
+
+
    Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
+
    Mixing, shift, table, tail correction, restart, rRESPA info:
+
    
+
    For atom type pairs I,J and I != J, the epsilon and sigma
+coefficients and cutoff distance for this pair style can be mixed.
+Rin is a cutoff value and is mixed like the cutoff. The
+default mix value is geometric.  See the "pair_modify" command for
+details.
+
    
+
    The pair_modify shift option is not relevant for
+this pair style, since the pair interaction goes to 0.0 at the cutoff.
+
    
+
    The pair_modify table option is not relevant
+for this pair style.
+
    
+
    This pair style does not support the pair_modify
+tail option for adding long-range tail corrections to energy and
+pressure, since the energy of the pair interaction is smoothed to 0.0
+at the cutoff.
+
    
+
    This pair style writes its information to binary restart
+files, so pair_style and pair_coeff commands do not need
+to be specified in an input script that reads a restart file.
+
    
+
    This pair style can only be used via the pair keyword of the
+run_style respa command.  It does not support the
+inner, middle, outer keywords.
+
    
+
    
+
+
    Restrictions:
+
    
+
    This pair style is part of the USER-MISC package.  It is only enabled
+if LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
    
+
    Related commands:
+
    
+
    pair_coeff
+
    
+
    Default: none
+
    
+
    
+
+
+
+
    (Toxvaerd) Toxvaerd, Dyre, J Chem Phys, 134, 081102 (2011).
+
    
+
diff --git a/doc/pair_lj_sf.txt b/doc/pair_lj_sf.txt
new file mode 100644
index 0000000000..a56cf7485a
--- /dev/null
+++ b/doc/pair_lj_sf.txt
@@ -0,0 +1,113 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+pair_style lj/sf command :h3
+pair_style lj/sf/omp command :h3
+
+[Syntax:]
+
+pair_style lj/sf cutoff :pre
+
+cutoff = global cutoff for Lennard-Jones interactions (distance units) :ul
+
+[Examples:]
+
+pair_style lj/sf 2.5
+pair_coeff * * 1.0 1.0
+pair_coeff 1 1 1.0 1.0 3.0 :pre
+
+[Description:]
+
+Style {lj/sf} computes a truncated and force-shifted LJ interaction
+(Shifted Force Lennard-Jones), so that both the potential and the
+force go continuously to zero at the cutoff "(Toxvaerd)"_#Toxvaerd:
+
+:c,image(Eqs/pair_lj_sf.jpg)
+
+The following coefficients must be defined for each pair of atoms
+types via the "pair_coeff"_pair_coeff.html command as in the examples
+above, or in the data file or restart files read by the
+"read_data"_read_data.html or "read_restart"_read_restart.html
+commands, or by mixing as described below:
+
+epsilon (energy units)
+sigma (distance units)
+cutoff (distance units) :ul
+
+The last coefficient is optional. If not specified, the global
+LJ cutoff specified in the pair_style command is used.
+
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
+[Mixing, shift, table, tail correction, restart, rRESPA info]:
+
+For atom type pairs I,J and I != J, the epsilon and sigma
+coefficients and cutoff distance for this pair style can be mixed.
+Rin is a cutoff value and is mixed like the cutoff. The
+default mix value is {geometric}.  See the "pair_modify" command for
+details.
+
+The "pair_modify"_pair_modify.html shift option is not relevant for
+this pair style, since the pair interaction goes to 0.0 at the cutoff.
+
+The "pair_modify"_pair_modify.html table option is not relevant
+for this pair style.
+
+This pair style does not support the "pair_modify"_pair_modify.html
+tail option for adding long-range tail corrections to energy and
+pressure, since the energy of the pair interaction is smoothed to 0.0
+at the cutoff.
+
+This pair style writes its information to "binary restart
+files"_restart.html, so pair_style and pair_coeff commands do not need
+to be specified in an input script that reads a restart file.
+
+This pair style can only be used via the {pair} keyword of the
+"run_style respa"_run_style.html command.  It does not support the
+{inner}, {middle}, {outer} keywords.
+
+:line
+
+[Restrictions:]
+
+This pair style is part of the USER-MISC package.  It is only enabled
+if LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+[Related commands:]
+
+"pair_coeff"_pair_coeff.html
+
+[Default:] none
+
+:line
+
+:link(Toxvaerd)
+[(Toxvaerd)] Toxvaerd, Dyre, J Chem Phys, 134, 081102 (2011).
diff --git a/doc/pair_lj_smooth.html b/doc/pair_lj_smooth.html
index 4f185145ac..0805dd5f05 100644
--- a/doc/pair_lj_smooth.html
+++ b/doc/pair_lj_smooth.html
@@ -11,6 +11,10 @@
 
 
    pair_style lj/smooth command 
 
    
+
    pair_style lj/smooth/cuda command 
+
    
+
    pair_style lj/smooth/omp command 
+
    
 
    Syntax:
 
    
 
    pair_style lj/smooth Rin Rc 
@@ -61,6 +65,28 @@ specified, the global values for Rin and Rc are used.
 
    
 
    
 
+
    Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
 
    Mixing, shift, table, tail correction, restart, rRESPA info:
 
    
 
    For atom type pairs I,J and I != J, the epsilon, sigma, Rin
diff --git a/doc/pair_lj_smooth.txt b/doc/pair_lj_smooth.txt
index 49243a982b..b08bb47431 100644
--- a/doc/pair_lj_smooth.txt
+++ b/doc/pair_lj_smooth.txt
@@ -7,6 +7,8 @@
 :line
 
 pair_style lj/smooth command :h3
+pair_style lj/smooth/cuda command :h3
+pair_style lj/smooth/omp command :h3
 
 [Syntax:]
 
@@ -58,6 +60,28 @@ specified, the global values for Rin and Rc are used.
 
 :line
 
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Mixing, shift, table, tail correction, restart, rRESPA info]:
 
 For atom type pairs I,J and I != J, the epsilon, sigma, Rin
diff --git a/doc/pair_lubricate.html b/doc/pair_lubricate.html
index 5cbcb2e9d3..a79e0b6483 100644
--- a/doc/pair_lubricate.html
+++ b/doc/pair_lubricate.html
@@ -11,35 +11,37 @@
 
 
    pair_style lubricate command 
 
    
+
    pair_style lubricate/poly command 
+
    
 
    Syntax:
 
    
-
    pair_style lubricate mu squeeze shear pump twist cutinner cutoff T_target seed 
+
    pair_style style mu flaglog flagfld cutinner cutoff 
 
    
-
    • mu = dynamic viscosity (dynamic viscosity units)
-
    • squeeze = 0/1 for squeeze force off/on
-
    • shear = 0/1 for shear force off/on
-
    • pump = 0/1 for pump force off/on
-
    • twist = 0/1 for twist force off/on
-
    • cutinner = (distance units)
-
    • cutoff = outer cutoff for interactions (distance units)
-
    • T_target = desired temperature (temperature units)
-
    • seed = random number seed (positive integer) 
+
      • style = lubricate or lubricate/poly
+
      • mu = dynamic viscosity (dynamic viscosity units)
+
      • flaglog = 0/1 log terms in the lubrication approximation off/on
+
      • flagfld = 0/1 to include/exclude Fast Lubrication Dynamics effects
+
      • cutinner = inner cutoff distance (distance units)
+
      • cutoff = outer cutoff for interactions (distance units) 
 
      
-
      Examples:
+
      Examples: (all assume radius = 1)
 
      
-
      pair_style lubricate 1.5 1 1 1 0 2.3 2.4 1.3 5878598
-pair_coeff 1 1 1.8 2.0
+
      pair_style lubricate 1.5 1 1 2.01 2.5
+pair_coeff 1 1 2.05 2.8
 pair_coeff * * 
 
      
-
      pair_style lubricate 1.0 1 1 1 0 2.3 2.4 1.3 5878598
+
      pair_style lubricate 1.5 1 1 2.01 2.5
 pair_coeff * *
 variable mu equal ramp(1,2)
 fix 1 all adapt 1 pair lubricate mu * * v_mu 
 
      
 
      Description:
 
      
-
      Style lubricate computes pairwise interactions between mono-disperse
-spherical particles via this formula from (Ball and Melrose)
+
      Styles lubricate and lubricate/poly compute hydrodynamic
+interactions between mono-disperse spherical particles in a pairwise
+fashion.  The interactions have 2 components.  The first is
+Ball-Melrose lubrication terms via the formulas in (Ball and
+Melrose)
 
      
 
      
 
      
@@ -48,39 +50,62 @@ their relative velocities in the presence of a background solvent with
 viscosity mu.  Note that this is dynamic viscosity which has units of
 mass/distance/time, not kinematic viscosity.
 
      
+
      The Asq (squeeze) term is the strongest and is always included.  It
+scales as 1/gap where gap is the separation between the surfaces of
+the 2 particles.  The Ash (shear) and Apu (pump) terms are only
+include if flaglog is set to 1.  Thy are the next strongest
+interactions, and the only other singular interaction, and scale as
+log(gap).  The Atw (twist) term is currently not included.  It is
+typically a very small contribution to the lubrication forces.
+
      
+
      Cutinner sets the minimum center-to-center separation that will be
+used in calculations irrespective of the actual separation.  Cutoff
+is the maximum center-to-center separation at which an interaction is
+computed.  Using a cutoff less than 3 radii is recommended if
+flaglog is set to 1.
+
      
+
      The other component is due to the Fast Lubrication Dynamics (FLD)
+approximation, described in (Kumar), which can be
+represented by the following equation
+
      
+
      
+
      
+
      where U represents the velocities and angular velocities of the
+particles, U^infty represents the velocity and the angular velocity
+of the undisturbed fluid, and E^infty represents the rate of strain
+tensor of the undisturbed fluid with viscosity mu.  Again, note that
+this is dynamic viscosity which has units of mass/distance/time, not
+kinematic viscosity.
+
      
+
      IMPORTANT NOTE: When using the FLD terms, these pair styles are
+designed to be used with explicit time integration and a
+correspondingly small timestep.  Thus either fix
+nve/sphere or fix
+nve/asphere should be used for time integration.
+To perform implicit FLD, see the pair_style
+lubricateU command.
+
      
+
      Style lubricate requires monodisperse spherical particles; style
+lubricate/poly allows for polydisperse spherical particles.
+
      
 
      The viscosity mu can be varied in a time-dependent manner over the
 course of a simluation, in which case in which case the pair_style
 setting for mu will be overridden.  See the fix adapt
 command for details.
 
      
-
      Rc is the outer cutoff specified in the pair_style command, the
-translational velocities of the 2 particles are v1 and v2, the angular
-velocities are w1 and w2, and n is the unit vector in the direction
-from particle 1 to 2.  The 4 terms represent four modes of pairwise
-interaction: squeezing, shearing, pumping, and twisting.  The 4 flags
-in the pair_style command turn on or off each of these modes by
-including or excluding each term.  The 4 coefficients on each term are
-functions of the separation distance of the particles and the
-viscosity.  Details are given in (Ball and Melrose), including
-the forces and torques that result from taking derivatives of this
-equation with respect to velocity (see Appendix A).
+
      If the suspension is sheared via the fix deform
+command then the pair style uses the shear rate to adjust the
+hydrodynamic interactions accordingly.
 
      
-
      Unlike most pair potentials, the two specified cutoffs (cutinner and
-cutoff) refer to the surface-to-surface separation between two
-particles, not center-to-center distance.  Currently, this pair style
-can only be used for mono-disperse extended spheres (same radii), so
-that separation is r_ij - 2*radius, where r_ij is the center-to-center
-distance between the particles.  Within the inner cutoff cutinner,
-the forces and torques are evaluated at a separation of cutinner.  The
-outer cutoff is the separation distance beyond which the pair-wise
-forces are zero.
-
      
-
      A Langevin thermostatting term is also added to the pairwise force,
-similar to that provided by the fix langevin or
-pair_style dpd commands.  The target temperature for
-the thermostat is the specified T_target.  The seed is used for
-the random numbers generated for the thermostat.
+
      Since lubrication forces are dissipative, it is usually desirable to
+thermostat the system at a constant temperature.  If Brownian motion
+(at a constant temperature) is desired, it can be set using the
+pair_style brownian command.  These pair styles
+and the brownian style should use consistent parameters for mu,
+flaglog, flagfld, cutinner, and cutoff.
 
      
+
      
+
 
      The following coefficients must be defined for each pair of atoms
 types via the pair_coeff command as in the examples
 above, or in the data file or restart files read by the
@@ -124,28 +149,19 @@ to be specified in an input script that reads a restart file.
 
 
      Restrictions:
 
      
-
      This style is part of the "colloid" package.  It is only enabled if
+
      These styles are part of the FLD package.  They are only enabled if
 LAMMPS was built with that package.  See the Making
 LAMMPS section for more info.
 
      
-
      This pair style requires that atoms store torque and a quaternion to
-represent their orientation, as defined by the
-atom_style.  It also require they store a per-type
-shape.  The particles cannot store a per-particle
-diameter or per-particle mass.
+
      Only spherical monodisperse particles are allowed for pair_style
+lubricate.
 
      
-
      All the shape settings must be for finite-size spheres.  They cannot
-be point particles, nor can they be aspherical.  Additionally all the
-shape types must specify particles of the same size, i.e. a
-monodisperse system.
-
      
-
      This pair style requires you to use the communicate vel
-yes option so that velocites are stored by ghost
-atoms.
+
      Only spherical particles are allowed for pair_style lubricate/poly.
 
      
 
      Related commands:
 
      
-
      pair_coeff
+
      pair_coeff, pair_style
+lubricateU
 
      
 
      Default: none
 
      
@@ -155,4 +171,8 @@ atoms.
 
 
      (Ball) Ball and Melrose, Physica A, 247, 444-472 (1997).
 
      
+
+
+
      (Kumar) Kumar and Higdon, Phys Rev E, 82, 051401 (2010).
+
      
 
diff --git a/doc/pair_lubricate.txt b/doc/pair_lubricate.txt
index 940e3c99a9..e2d28b4db1 100644
--- a/doc/pair_lubricate.txt
+++ b/doc/pair_lubricate.txt
@@ -7,36 +7,37 @@
 :line
 
 pair_style lubricate command :h3
+pair_style lubricate/poly command :h3
 
 [Syntax:]
 
-pair_style lubricate mu squeeze shear pump twist cutinner cutoff T_target seed :pre
+pair_style style mu flaglog flagfld cutinner cutoff :pre
 
+style = {lubricate} or {lubricate/poly}
 mu = dynamic viscosity (dynamic viscosity units)
-squeeze = 0/1 for squeeze force off/on
-shear = 0/1 for shear force off/on
-pump = 0/1 for pump force off/on
-twist = 0/1 for twist force off/on
-cutinner = (distance units)
-cutoff = outer cutoff for interactions (distance units)
-T_target = desired temperature (temperature units)
-seed = random number seed (positive integer) :ul
+flaglog = 0/1 log terms in the lubrication approximation off/on
+flagfld = 0/1 to include/exclude Fast Lubrication Dynamics effects
+cutinner = inner cutoff distance (distance units)
+cutoff = outer cutoff for interactions (distance units) :ul
 
-[Examples:]
+[Examples:] (all assume radius = 1)
 
-pair_style lubricate 1.5 1 1 1 0 2.3 2.4 1.3 5878598
-pair_coeff 1 1 1.8 2.0
+pair_style lubricate 1.5 1 1 2.01 2.5
+pair_coeff 1 1 2.05 2.8
 pair_coeff * * :pre
 
-pair_style lubricate 1.0 1 1 1 0 2.3 2.4 1.3 5878598
+pair_style lubricate 1.5 1 1 2.01 2.5
 pair_coeff * *
 variable mu equal ramp(1,2)
 fix 1 all adapt 1 pair lubricate mu * * v_mu :pre
 
 [Description:]
 
-Style {lubricate} computes pairwise interactions between mono-disperse
-spherical particles via this formula from "(Ball and Melrose)"_#Ball
+Styles {lubricate} and {lubricate/poly} compute hydrodynamic
+interactions between mono-disperse spherical particles in a pairwise
+fashion.  The interactions have 2 components.  The first is
+Ball-Melrose lubrication terms via the formulas in "(Ball and
+Melrose)"_#Ball
 
 :c,image(Eqs/pair_lubricate.jpg)
 
@@ -45,38 +46,61 @@ their relative velocities in the presence of a background solvent with
 viscosity mu.  Note that this is dynamic viscosity which has units of
 mass/distance/time, not kinematic viscosity.
 
+The Asq (squeeze) term is the strongest and is always included.  It
+scales as 1/gap where gap is the separation between the surfaces of
+the 2 particles.  The Ash (shear) and Apu (pump) terms are only
+include if {flaglog} is set to 1.  Thy are the next strongest
+interactions, and the only other singular interaction, and scale as
+log(gap).  The Atw (twist) term is currently not included.  It is
+typically a very small contribution to the lubrication forces.
+
+{Cutinner} sets the minimum center-to-center separation that will be
+used in calculations irrespective of the actual separation.  {Cutoff}
+is the maximum center-to-center separation at which an interaction is
+computed.  Using a {cutoff} less than 3 radii is recommended if
+{flaglog} is set to 1.
+
+The other component is due to the Fast Lubrication Dynamics (FLD)
+approximation, described in "(Kumar)"_#Kumar, which can be
+represented by the following equation
+
+:c,image(Eqs/fld.jpg)
+
+where U represents the velocities and angular velocities of the
+particles, U^{infty} represents the velocity and the angular velocity
+of the undisturbed fluid, and E^{infty} represents the rate of strain
+tensor of the undisturbed fluid with viscosity mu.  Again, note that
+this is dynamic viscosity which has units of mass/distance/time, not
+kinematic viscosity.
+
+IMPORTANT NOTE: When using the FLD terms, these pair styles are
+designed to be used with explicit time integration and a
+correspondingly small timestep.  Thus either "fix
+nve/sphere"_fix_nve_sphere.html or "fix
+nve/asphere"_fix_nve_asphere.html should be used for time integration.
+To perform implicit FLD, see the "pair_style
+lubricateU"_pair_lubricateU.html command.
+
+Style {lubricate} requires monodisperse spherical particles; style
+{lubricate/poly} allows for polydisperse spherical particles.
+
 The viscosity mu can be varied in a time-dependent manner over the
 course of a simluation, in which case in which case the pair_style
 setting for mu will be overridden.  See the "fix adapt"_fix_adapt.html
 command for details.
 
-Rc is the outer cutoff specified in the pair_style command, the
-translational velocities of the 2 particles are v1 and v2, the angular
-velocities are w1 and w2, and n is the unit vector in the direction
-from particle 1 to 2.  The 4 terms represent four modes of pairwise
-interaction: squeezing, shearing, pumping, and twisting.  The 4 flags
-in the pair_style command turn on or off each of these modes by
-including or excluding each term.  The 4 coefficients on each term are
-functions of the separation distance of the particles and the
-viscosity.  Details are given in "(Ball and Melrose)"_#Ball, including
-the forces and torques that result from taking derivatives of this
-equation with respect to velocity (see Appendix A).
+If the suspension is sheared via the "fix deform"_fix_deform.html
+command then the pair style uses the shear rate to adjust the
+hydrodynamic interactions accordingly.
 
-Unlike most pair potentials, the two specified cutoffs (cutinner and
-cutoff) refer to the surface-to-surface separation between two
-particles, not center-to-center distance.  Currently, this pair style
-can only be used for mono-disperse extended spheres (same radii), so
-that separation is r_ij - 2*radius, where r_ij is the center-to-center
-distance between the particles.  Within the inner cutoff {cutinner},
-the forces and torques are evaluated at a separation of cutinner.  The
-outer {cutoff} is the separation distance beyond which the pair-wise
-forces are zero.
+Since lubrication forces are dissipative, it is usually desirable to
+thermostat the system at a constant temperature.  If Brownian motion
+(at a constant temperature) is desired, it can be set using the
+"pair_style brownian"_pair_brownian.html command.  These pair styles
+and the {brownian} style should use consistent parameters for {mu},
+{flaglog}, {flagfld}, {cutinner}, and {cutoff}.
 
-A Langevin thermostatting term is also added to the pairwise force,
-similar to that provided by the "fix langevin"_fix_langevin.html or
-"pair_style dpd"_pair_dpd.html commands.  The target temperature for
-the thermostat is the specified {T_target}.  The {seed} is used for
-the random numbers generated for the thermostat.
+:line
 
 The following coefficients must be defined for each pair of atoms
 types via the "pair_coeff"_pair_coeff.html command as in the examples
@@ -121,28 +145,19 @@ This pair style can only be used via the {pair} keyword of the
 
 [Restrictions:]
 
-This style is part of the "colloid" package.  It is only enabled if
+These styles are part of the FLD package.  They are only enabled if
 LAMMPS was built with that package.  See the "Making
 LAMMPS"_Section_start.html#2_3 section for more info.
 
-This pair style requires that atoms store torque and a quaternion to
-represent their orientation, as defined by the
-"atom_style"_atom_style.html.  It also require they store a per-type
-"shape"_shape.html.  The particles cannot store a per-particle
-diameter or per-particle mass.
+Only spherical monodisperse particles are allowed for pair_style
+lubricate.
 
-All the shape settings must be for finite-size spheres.  They cannot
-be point particles, nor can they be aspherical.  Additionally all the
-shape types must specify particles of the same size, i.e. a
-monodisperse system.
-
-This pair style requires you to use the "communicate vel
-yes"_communicate.html option so that velocites are stored by ghost
-atoms.
+Only spherical particles are allowed for pair_style lubricate/poly.
 
 [Related commands:]
 
-"pair_coeff"_pair_coeff.html
+"pair_coeff"_pair_coeff.html, "pair_style
+lubricateU"_pair_lubricateU.html
 
 [Default:] none
 
@@ -150,3 +165,6 @@ atoms.
 
 :link(Ball)
 [(Ball)] Ball and Melrose, Physica A, 247, 444-472 (1997).
+
+:link(Kumar)
+[(Kumar)] Kumar and Higdon, Phys Rev E, 82, 051401 (2010).
diff --git a/doc/pair_lubricateU.html b/doc/pair_lubricateU.html
new file mode 100644
index 0000000000..c96cd00e35
--- /dev/null
+++ b/doc/pair_lubricateU.html
@@ -0,0 +1,199 @@
+
+
      LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
      
+
+
+
+
+
+
+
      
+
+
      pair_style lubricateU command 
+
      
+
      pair_style lubricateU/poly command 
+
      
+
      Syntax:
+
      
+
      pair_style style mu flaglog cutinner cutoff gdot 
+
      
+
      • style = lubricateU or lubricateU/poly
+
      • mu = dynamic viscosity (dynamic viscosity units)
+
      • flaglog = 0/1 log terms in the lubrication approximation on/off
+
      • cutinner = inner cut off distance (distance units)
+
      • cutoff = outer cutoff for interactions (distance units)
+
      • gdot = shear rate (1/time units) 
+
      
+
      Examples: (all assume radius = 1)
+
      
+
      pair_style lubricateU 1.5 1 2.01 2.5 0.01
+pair_coeff 1 1 2.05 2.8
+pair_coeff * * 
+
      
+
      Description:
+
      
+
      Styles lubricateU and lubricateU/poly compute velocities and
+angular velocities such that the hydrodynamic interaction balances the
+force and torque due to all other types of interactions.
+
      
+
      The interactions have 2 components.  The first is
+Ball-Melrose lubrication terms via the formulas in (Ball and
+Melrose)
+
      
+
      
+
      
+
      which represents the dissipation W between two nearby particles due to
+their relative velocities in the presence of a background solvent with
+viscosity mu.  Note that this is dynamic viscosity which has units of
+mass/distance/time, not kinematic viscosity.
+
      
+
      The Asq (squeeze) term is the strongest and is always included.  It
+scales as 1/gap where gap is the separation between the surfaces of
+the 2 particles.  The Ash (shear) and Apu (pump) terms are only
+include if flaglog is set to 1.  Thy are the next strongest
+interactions, and the only other singular interaction, and scale as
+log(gap).  The Atw (twist) term is currently not included.  It is
+typically a very small contribution to the lubrication forces.
+
      
+
      Cutinner sets the minimum center-to-center separation that will be
+used in calculations irrespective of the actual separation.  Cutoff
+is the maximum center-to-center separation at which an interaction is
+computed.  Using a cutoff less than 3 radii is recommended if
+flaglog is set to 1.
+
      
+
      The other component is due to the Fast Lubrication Dynamics (FLD)
+approximation, described in (Kumar).  The equation being
+solved to balance the forces and torques is
+
      
+
      
+
      
+
      where U represents the velocities and angular velocities of the
+particles, Uinfty represents the velocities and the angular
+velocities of the undisturbed fluid, and Einfty represents the rate
+of strain tensor of the undisturbed fluid flow with viscosity mu.
+Again, note that this is dynamic viscosity which has units of
+mass/distance/time, not kinematic viscosity.
+
      
+
      Frest represents the forces and torques due to all other types of
+interactions, e.g. Brownian, electrostatic etc.  Note that this
+algorithm neglects the inertial terms, thereby removing the
+restriction of resolving the small interial time scale, which may not
+be of interest for colloidal particles.  This pair style solves for
+the velocity such that the hydrodynamic force balances all other types
+of forces, thereby resulting in a net zero force (zero inertia limit).
+When defining this pair style, it must be defined last so that when
+this style is invoked all other types of forces have already been
+computed.  For the same reason, it won't work if additional non-pair
+styles are defined (such as bond or Kspace forces) as they are
+calculated in LAMMPS after the pairwise interactions have been
+computed.
+
      
+
      IMPORTANT NOTE: When using these styles, the these pair styles are
+designed to be used with implicit time integration and a
+correspondingly larger timestep.  Thus either fix
+nve/noforce should be used for spherical
+particles defined via atom_style sphere or fix
+nve/asphere/noforce should be used for
+spherical particles defined via atom_style
+ellipsoid.  This is because the velocity and angular
+momentum of each particle is set by the pair style, and should not be
+reset by the time integration fix.
+
      
+
      Style lubricateU requires monodisperse spherical particles; style
+lubricateU/poly allows for polydisperse spherical particles.
+
      
+
      If the suspension is sheared via the fix deform
+command then the pair style uses the shear rate to adjust the
+hydrodynamic interactions accordingly.
+
      
+
      Since lubrication forces are dissipative, it is usually desirable to
+thermostat the system at a constant temperature.  If Brownian motion
+(at a constant temperature) is desired, it can be set using the
+pair_style brownian command.  These pair styles
+and the brownian style should use consistent parameters for mu,
+flaglog, flagfld = 1, cutinner, and cutoff.
+
      
+
      
+
+
      The following coefficients must be defined for each pair of atoms
+types via the pair_coeff command as in the examples
+above, or in the data file or restart files read by the
+read_data or read_restart
+commands, or by mixing as described below:
+
      
+
      • cutinner (distance units)
+
      • cutoff (distance units) 
+
      
+
      The two coefficients are optional.  If neither is specified, the two
+cutoffs specified in the pair_style command are used.  Otherwise both
+must be specified.
+
      
+
      
+
+
      Mixing, shift, table, tail correction, restart, rRESPA info:
+
      
+
      For atom type pairs I,J and I != J, the two cutoff distances for this
+pair style can be mixed.  The default mix value is geometric.  See
+the "pair_modify" command for details.
+
      
+
      This pair style does not support the pair_modify
+shift option for the energy of the pair interaction.
+
      
+
      The pair_modify table option is not relevant
+for this pair style.
+
      
+
      This pair style does not support the pair_modify
+tail option for adding long-range tail corrections to energy and
+pressure.
+
      
+
      This pair style writes its information to binary restart
+files, so pair_style and pair_coeff commands do not need
+to be specified in an input script that reads a restart file.
+
      
+
      This pair style can only be used via the pair keyword of the
+run_style respa command.  It does not support the
+inner, middle, outer keywords.
+
      
+
      
+
+
      Restrictions:
+
      
+
      These styles are part of the FLD package.  They are only enabled if
+LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
      
+
      Currently, these pair styles assume that all other types of
+forces/torques on the particles have been already been computed when
+it is invoked.  This requires this style to be defined as the last of
+the pair styles, and that no fixes apply additional constraint forces.
+One exception is the fix wall/colloid command, which
+has an "fld" option to apply its wall forces correctly.
+
      
+
      Only spherical monodisperse particles are allowed for pair_style
+lubricateU.
+
      
+
      Only spherical particles are allowed for pair_style lubricateU/poly.
+
      
+
      For sheared suspensions, it is assumed that the shearing is done in
+the xy plane, with x being the velocity direction and y being the
+velocity-gradient direction. In this case, one must use fix
+deform with the same rate of shear (erate).
+
      
+
      Related commands:
+
      
+
      pair_coeff, pair_style
+lubricate
+
      
+
      Default: none
+
      
+
      
+
+
+
+
      (Ball) Ball and Melrose, Physica A, 247, 444-472 (1997).
+
      
+
+
+
      (Kumar) Kumar and Higdon, Phys Rev E, 82, 051401 (2010).
+
      
+
diff --git a/doc/pair_lubricateU.txt b/doc/pair_lubricateU.txt
new file mode 100644
index 0000000000..2cac5cbd82
--- /dev/null
+++ b/doc/pair_lubricateU.txt
@@ -0,0 +1,191 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+pair_style lubricateU command :h3
+pair_style lubricateU/poly command :h3
+
+[Syntax:]
+
+pair_style style mu flaglog cutinner cutoff gdot :pre
+
+style = {lubricateU} or {lubricateU/poly}
+mu = dynamic viscosity (dynamic viscosity units)
+flaglog = 0/1 log terms in the lubrication approximation on/off
+cutinner = inner cut off distance (distance units)
+cutoff = outer cutoff for interactions (distance units)
+gdot = shear rate (1/time units) :ul
+
+[Examples:] (all assume radius = 1)
+
+pair_style lubricateU 1.5 1 2.01 2.5 0.01
+pair_coeff 1 1 2.05 2.8
+pair_coeff * * :pre
+
+[Description:]
+
+Styles {lubricateU} and {lubricateU/poly} compute velocities and
+angular velocities such that the hydrodynamic interaction balances the
+force and torque due to all other types of interactions.
+
+The interactions have 2 components.  The first is
+Ball-Melrose lubrication terms via the formulas in "(Ball and
+Melrose)"_#Ball
+
+:c,image(Eqs/pair_lubricate.jpg)
+
+which represents the dissipation W between two nearby particles due to
+their relative velocities in the presence of a background solvent with
+viscosity mu.  Note that this is dynamic viscosity which has units of
+mass/distance/time, not kinematic viscosity.
+
+The Asq (squeeze) term is the strongest and is always included.  It
+scales as 1/gap where gap is the separation between the surfaces of
+the 2 particles.  The Ash (shear) and Apu (pump) terms are only
+include if {flaglog} is set to 1.  Thy are the next strongest
+interactions, and the only other singular interaction, and scale as
+log(gap).  The Atw (twist) term is currently not included.  It is
+typically a very small contribution to the lubrication forces.
+
+{Cutinner} sets the minimum center-to-center separation that will be
+used in calculations irrespective of the actual separation.  {Cutoff}
+is the maximum center-to-center separation at which an interaction is
+computed.  Using a {cutoff} less than 3 radii is recommended if
+{flaglog} is set to 1.
+
+The other component is due to the Fast Lubrication Dynamics (FLD)
+approximation, described in "(Kumar)"_#Kumar.  The equation being
+solved to balance the forces and torques is
+
+:c,image(Eqs/fld2.jpg)
+ 
+where U represents the velocities and angular velocities of the
+particles, U{infty} represents the velocities and the angular
+velocities of the undisturbed fluid, and E{infty} represents the rate
+of strain tensor of the undisturbed fluid flow with viscosity mu.
+Again, note that this is dynamic viscosity which has units of
+mass/distance/time, not kinematic viscosity.
+
+F{rest} represents the forces and torques due to all other types of
+interactions, e.g. Brownian, electrostatic etc.  Note that this
+algorithm neglects the inertial terms, thereby removing the
+restriction of resolving the small interial time scale, which may not
+be of interest for colloidal particles.  This pair style solves for
+the velocity such that the hydrodynamic force balances all other types
+of forces, thereby resulting in a net zero force (zero inertia limit).
+When defining this pair style, it must be defined last so that when
+this style is invoked all other types of forces have already been
+computed.  For the same reason, it won't work if additional non-pair
+styles are defined (such as bond or Kspace forces) as they are
+calculated in LAMMPS after the pairwise interactions have been
+computed.
+
+IMPORTANT NOTE: When using these styles, the these pair styles are
+designed to be used with implicit time integration and a
+correspondingly larger timestep.  Thus either "fix
+nve/noforce"_fix_nve_noforce.html should be used for spherical
+particles defined via "atom_style sphere"_atom_style.html or "fix
+nve/asphere/noforce"_fix_nve_asphere_noforce.html should be used for
+spherical particles defined via "atom_style
+ellipsoid"_atom_style.html.  This is because the velocity and angular
+momentum of each particle is set by the pair style, and should not be
+reset by the time integration fix.
+
+Style {lubricateU} requires monodisperse spherical particles; style
+{lubricateU/poly} allows for polydisperse spherical particles.
+
+If the suspension is sheared via the "fix deform"_fix_deform.html
+command then the pair style uses the shear rate to adjust the
+hydrodynamic interactions accordingly.
+
+Since lubrication forces are dissipative, it is usually desirable to
+thermostat the system at a constant temperature.  If Brownian motion
+(at a constant temperature) is desired, it can be set using the
+"pair_style brownian"_pair_brownian.html command.  These pair styles
+and the {brownian} style should use consistent parameters for {mu},
+{flaglog}, {flagfld = 1}, {cutinner}, and {cutoff}.
+
+:line
+
+The following coefficients must be defined for each pair of atoms
+types via the "pair_coeff"_pair_coeff.html command as in the examples
+above, or in the data file or restart files read by the
+"read_data"_read_data.html or "read_restart"_read_restart.html
+commands, or by mixing as described below:
+
+cutinner (distance units)
+cutoff (distance units) :ul
+
+The two coefficients are optional.  If neither is specified, the two
+cutoffs specified in the pair_style command are used.  Otherwise both
+must be specified.
+
+:line
+
+[Mixing, shift, table, tail correction, restart, rRESPA info]:
+
+For atom type pairs I,J and I != J, the two cutoff distances for this
+pair style can be mixed.  The default mix value is {geometric}.  See
+the "pair_modify" command for details.
+
+This pair style does not support the "pair_modify"_pair_modify.html
+shift option for the energy of the pair interaction.
+
+The "pair_modify"_pair_modify.html table option is not relevant
+for this pair style.
+
+This pair style does not support the "pair_modify"_pair_modify.html
+tail option for adding long-range tail corrections to energy and
+pressure.
+
+This pair style writes its information to "binary restart
+files"_restart.html, so pair_style and pair_coeff commands do not need
+to be specified in an input script that reads a restart file.
+
+This pair style can only be used via the {pair} keyword of the
+"run_style respa"_run_style.html command.  It does not support the
+{inner}, {middle}, {outer} keywords.
+
+:line
+
+[Restrictions:]
+
+These styles are part of the FLD package.  They are only enabled if
+LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#2_3 section for more info.
+
+Currently, these pair styles assume that all other types of
+forces/torques on the particles have been already been computed when
+it is invoked.  This requires this style to be defined as the last of
+the pair styles, and that no fixes apply additional constraint forces.
+One exception is the "fix wall/colloid"_fix_wall.html command, which
+has an "fld" option to apply its wall forces correctly.
+
+Only spherical monodisperse particles are allowed for pair_style
+lubricateU.
+
+Only spherical particles are allowed for pair_style lubricateU/poly.
+ 
+For sheared suspensions, it is assumed that the shearing is done in
+the xy plane, with x being the velocity direction and y being the
+velocity-gradient direction. In this case, one must use "fix
+deform"_fix_deform.html with the same rate of shear (erate).
+
+[Related commands:]
+
+"pair_coeff"_pair_coeff.html, "pair_style
+lubricate"_pair_lubricate.html
+
+[Default:] none
+
+:line
+
+:link(Ball)
+[(Ball)] Ball and Melrose, Physica A, 247, 444-472 (1997).
+
+:link(Kumar)
+[(Kumar)] Kumar and Higdon, Phys Rev E, 82, 051401 (2010).
diff --git a/doc/pair_meam.html b/doc/pair_meam.html
index bad3abf6c0..8d5868201c 100644
--- a/doc/pair_meam.html
+++ b/doc/pair_meam.html
@@ -144,7 +144,8 @@ density; options are
    1 => G = exp(Gamma/2)
    2 => not implemented 
    3 => G = 2/(1+exp(-Gamma))
-   4 => G = sqrt(1+Gamma) 
+   4 => G = sqrt(1+Gamma)
+  -5 => G = +-sqrt(abs(1+Gamma)) 
 
      
 
      If used, the MEAM parameter file contains settings that override or
 complement the library file settings.  Examples of such parameter
@@ -227,6 +228,14 @@ mixture_ref_t   = integer flag to use mixture average of t to compute the backgr
                     default = 0 
 erose_form      = integer value to select the form of the Rose energy function 
                   (see description below).
+                    default = 0
+emb_lin_neg     = integer value to select embedding function for negative densities
+                    0 = F(rho)=0
+                    1 = F(rho) = -asub*esub*rho (linear in rho, matches DYNAMO)
+                    default = 0
+bkgd_dyn        = integer value to select background density formula
+                    0 = rho_bkgd = rho_ref_meam(a) (as in the reference structure)
+                    1 = rho_bkgd = rho0_meam(a)*Z_meam(a) (matches DYNAMO)
                     default = 0 
 
      
 
      Rc, delr, re are in distance units (Angstroms in the case of metal
@@ -322,9 +331,9 @@ script that reads a restart file.
 
 
      Restrictions:
 
      
-
      This style is part of the "meam" package.  It is only enabled if
-LAMMPS was built with that package, which also requires the MEAM
-library be built and linked with LAMMPS.  See the Making
+
      This style is part of the MEAM package.  It is only enabled if LAMMPS
+was built with that package, which also requires the MEAM library be
+built and linked with LAMMPS.  See the Making
 LAMMPS section for more info.
 
      
 
      Related commands:
@@ -364,7 +373,7 @@ This report may be accessed on-line via 
 
-
      (ZBL) J.F. Ziegler, J.P. Biersack, U. Littmark, 'Stopping and Ranges
-of Ions in Matter' Vol 1, 1985, Pergamon Press.
+
      (ZBL) J.F. Ziegler, J.P. Biersack, U. Littmark, "Stopping and Ranges
+of Ions in Matter", Vol 1, 1985, Pergamon Press.
 
      
 
diff --git a/doc/pair_meam.txt b/doc/pair_meam.txt
index db3c4ca8de..b787345ae5 100644
--- a/doc/pair_meam.txt
+++ b/doc/pair_meam.txt
@@ -141,7 +141,8 @@ density; options are
    1 => G = exp(Gamma/2)
    2 => not implemented 
    3 => G = 2/(1+exp(-Gamma))
-   4 => G = sqrt(1+Gamma) :pre
+   4 => G = sqrt(1+Gamma)
+  -5 => G = +-sqrt(abs(1+Gamma)) :pre
 
 If used, the MEAM parameter file contains settings that override or
 complement the library file settings.  Examples of such parameter
@@ -224,6 +225,14 @@ mixture_ref_t   = integer flag to use mixture average of t to compute the backgr
                     default = 0 
 erose_form      = integer value to select the form of the Rose energy function 
                   (see description below).
+                    default = 0
+emb_lin_neg     = integer value to select embedding function for negative densities
+                    0 = F(rho)=0
+                    1 = F(rho) = -asub*esub*rho (linear in rho, matches DYNAMO)
+                    default = 0
+bkgd_dyn        = integer value to select background density formula
+                    0 = rho_bkgd = rho_ref_meam(a) (as in the reference structure)
+                    1 = rho_bkgd = rho0_meam(a)*Z_meam(a) (matches DYNAMO)
                     default = 0 :pre
 
 Rc, delr, re are in distance units (Angstroms in the case of metal
@@ -319,10 +328,10 @@ This pair style can only be used via the {pair} keyword of the
 
 [Restrictions:]
 
-This style is part of the "meam" package.  It is only enabled if
-LAMMPS was built with that package, which also requires the MEAM
-library be built and linked with LAMMPS.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+This style is part of the MEAM package.  It is only enabled if LAMMPS
+was built with that package, which also requires the MEAM library be
+built and linked with LAMMPS.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
 
 [Related commands:]
 
@@ -354,6 +363,5 @@ This report may be accessed on-line via "this link"_sandreport.
 [(Wang)] Wang, Van Hove, Ross, Baskes, J. Chem. Phys., 121, 5410 (2004).
 
 :link(ZBL)
-[(ZBL)] J.F. Ziegler, J.P. Biersack, U. Littmark, 'Stopping and Ranges
-of Ions in Matter' Vol 1, 1985, Pergamon Press.
-
+[(ZBL)] J.F. Ziegler, J.P. Biersack, U. Littmark, "Stopping and Ranges
+of Ions in Matter", Vol 1, 1985, Pergamon Press.
diff --git a/doc/pair_morse.html b/doc/pair_morse.html
index e5183ef53e..eaf5f16085 100644
--- a/doc/pair_morse.html
+++ b/doc/pair_morse.html
@@ -11,6 +11,12 @@
 
 
      pair_style morse command 
 
      
+
      pair_style morse/cuda command 
+
      
+
      pair_style morse/gpu command 
+
      
+
      pair_style morse/omp command 
+
      
 
      pair_style morse/opt command 
 
      
 
      Syntax:
@@ -22,7 +28,6 @@
 
      Examples:
 
      
 
      pair_style morse 2.5
-pair_style morse/opt 2.5
 pair_coeff * * 100.0 2.0 1.5
 pair_coeff 1 1 100.0 2.0 1.5 3.0 
 
      
@@ -48,10 +53,27 @@ commands:
 
      The last coefficient is optional.  If not specified, the global morse
 cutoff is used.
 
      
-
      Style morse/opt is an optimized version of style morse that should
-give identical answers.  Depending on system size and the processor
-you are running on, it may be 5-25% faster (for the pairwise portion
-of the run time).
+
      
+
+
      Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
      
+
      These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
      
+
      You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
      
+
      See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
 
      
 
      
 
@@ -80,11 +102,7 @@ to be specified in an input script that reads a restart file.
 
      
 
      
 
-
      Restrictions:
-
      
-
      The morse/opt style is part of the "opt" package.  It is only
-enabled if LAMMPS was built with that package.  See the Making
-LAMMPS section for more info.
+
      Restrictions: none
 
      
 
      Related commands:
 
      
diff --git a/doc/pair_morse.txt b/doc/pair_morse.txt
index 1c1799c242..b31acbb5ac 100644
--- a/doc/pair_morse.txt
+++ b/doc/pair_morse.txt
@@ -7,6 +7,9 @@
 :line
 
 pair_style morse command :h3
+pair_style morse/cuda command :h3
+pair_style morse/gpu command :h3
+pair_style morse/omp command :h3
 pair_style morse/opt command :h3
 
 [Syntax:]
@@ -18,7 +21,6 @@ cutoff = global cutoff for Morse interactions (distance units) :ul
 [Examples:]
 
 pair_style morse 2.5
-pair_style morse/opt 2.5
 pair_coeff * * 100.0 2.0 1.5
 pair_coeff 1 1 100.0 2.0 1.5 3.0 :pre
 
@@ -44,10 +46,27 @@ cutoff (distance units) :ul
 The last coefficient is optional.  If not specified, the global morse
 cutoff is used.
 
-Style {morse/opt} is an optimized version of style {morse} that should
-give identical answers.  Depending on system size and the processor
-you are running on, it may be 5-25% faster (for the pairwise portion
-of the run time).
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
 
 :line
 
@@ -76,11 +95,7 @@ These pair styles can only be used via the {pair} keyword of the
 
 :line
 
-[Restrictions:]
-
-The {morse/opt} style is part of the "opt" package.  It is only
-enabled if LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+[Restrictions:] none
 
 [Related commands:]
 
diff --git a/doc/pair_peri.html b/doc/pair_peri.html
index f29a7d094b..33bcbd17c1 100644
--- a/doc/pair_peri.html
+++ b/doc/pair_peri.html
@@ -11,8 +11,12 @@
 
 
      pair_style peri/pmb command 
 
      
+
      pair_style peri/pmb/omp command 
+
      
 
      pair_style peri/lps command 
 
      
+
      pair_style peri/lps/omp command 
+
      
 
      Syntax:
 
      
 
      pair_style style 
@@ -79,6 +83,28 @@ details.
 
      
 
      
 
+
      Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
      
+
      These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
      
+
      You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
      
+
      See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
      
+
      
+
 
      Mixing, shift, table, tail correction, restart, rRESPA info:
 
      
 
      These pair styles do not support mixing.  Thus, coefficients for all
@@ -102,9 +128,10 @@ to be specified in an input script that reads a restart file.
 
 
      Restrictions:
 
      
-
      The peri/pmb and peri/lps styles are part of the "peri"
+
      The peri/pmb and peri/lps styles are part of the PERI
 package. They are only enabled if LAMMPS was built with that package.
-See the Making LAMMPS section for more info.
+See the Making LAMMPS section for more
+info.
 
      
 
      Related commands:
 
      
diff --git a/doc/pair_peri.txt b/doc/pair_peri.txt
index 5dd59a2af7..00f6636493 100644
--- a/doc/pair_peri.txt
+++ b/doc/pair_peri.txt
@@ -7,7 +7,9 @@
 :line
 
 pair_style peri/pmb command :h3
+pair_style peri/pmb/omp command :h3
 pair_style peri/lps command :h3
+pair_style peri/lps/omp command :h3
 
 [Syntax:]
 
@@ -75,6 +77,28 @@ details.
 
 :line
 
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Mixing, shift, table, tail correction, restart, rRESPA info]:
 
 These pair styles do not support mixing.  Thus, coefficients for all
@@ -98,9 +122,10 @@ These pair styles can only be used via the {pair} keyword of the
 
 [Restrictions:]
 
-The {peri/pmb} and {peri/lps} styles are part of the "peri"
+The {peri/pmb} and {peri/lps} styles are part of the PERI
 package. They are only enabled if LAMMPS was built with that package.
-See the "Making LAMMPS"_Section_start.html#2_3 section for more info.
+See the "Making LAMMPS"_Section_start.html#start_3 section for more
+info.
 
 [Related commands:]
 
diff --git a/doc/pair_reax_c.html b/doc/pair_reax_c.html
index 8d4fabb386..7e5fa3ca3b 100644
--- a/doc/pair_reax_c.html
+++ b/doc/pair_reax_c.html
@@ -38,7 +38,9 @@ energy. There is more than one version of ReaxFF.  The version
 implemented in LAMMPS uses the functional forms documented in the
 supplemental information of the following paper: (Chenoweth et al.,
 2008).  The version integrated into LAMMPS matches
-the most up-to-date version of ReaxFF as of summer 2010.
+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)" paper.
 
      
 
      The reax/c style differs from the pair_style reax
 command in the lo-level implementation details.  The reax style is a
@@ -241,8 +243,8 @@ script that reads a restart file.
 
      
 
      Restrictions:
 
      
-
      This pair style is part of the "user-reaxc" package.  It is only
-enabled if LAMMPS was built with that package.  See the Making
+
      This pair style is part of the USER-REAXC package.  It is only enabled
+if LAMMPS was built with that package.  See the Making
 LAMMPS section for more info.
 
      
 
      The ReaxFF potential files provided with LAMMPS in the potentials
@@ -251,11 +253,6 @@ the ReaxFF potential with any LAMMPS units, but you would need to
 create your own potential file with coefficients listed in the
 appropriate units if your simulation doesn't use "real" units.
 
      
-
      This pair style cannot yet compute per-atom energy or stress.  If you
-use another command that tries to calculate these quantities using
-this pair style, a warning message will be printed and the quantities
-will be 0.0.
-
      
 
      Related commands:
 
      
 
      pair_coeff, fix_qeq_reax,
@@ -272,4 +269,9 @@ will be 0.0.
 
      (Chenoweth_2008) Chenoweth, van Duin and Goddard, 
 Journal of Physical Chemistry A, 112, 1040-1053 (2008).
 
      
+
+
+
      (Aktulga) Aktulga, Fogarty, Pandit, Grama, Parallel Computing, to
+appear (2011).
+
      
 
diff --git a/doc/pair_reax_c.txt b/doc/pair_reax_c.txt
index 4fde669ed8..60ef519410 100644
--- a/doc/pair_reax_c.txt
+++ b/doc/pair_reax_c.txt
@@ -34,7 +34,9 @@ energy. There is more than one version of ReaxFF.  The version
 implemented in LAMMPS uses the functional forms documented in the
 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.
+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)" paper.
 
 The {reax/c} style differs from the "pair_style reax"_pair_reax.html
 command in the lo-level implementation details.  The {reax} style is a
@@ -237,9 +239,9 @@ This pair style can only be used via the {pair} keyword of the
 
 [Restrictions:]
 
-This pair style is part of the "user-reaxc" package.  It is only
-enabled if LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+This pair style is part of the USER-REAXC package.  It is only enabled
+if LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
 
 The ReaxFF potential files provided with LAMMPS in the potentials
 directory are parameterized for real "units"_units.html.  You can use
@@ -247,11 +249,6 @@ the ReaxFF potential with any LAMMPS units, but you would need to
 create your own potential file with coefficients listed in the
 appropriate units if your simulation doesn't use "real" units.
 
-This pair style cannot yet compute per-atom energy or stress.  If you
-use another command that tries to calculate these quantities using
-this pair style, a warning message will be printed and the quantities
-will be 0.0.
-
 [Related commands:]
 
 "pair_coeff"_pair_coeff.html, "fix_qeq_reax"_fix_qeq_reax.html,
@@ -266,3 +263,7 @@ The keyword default is checkqeq = yes.
 :link(Chenoweth_2008) 
 [(Chenoweth_2008)] Chenoweth, van Duin and Goddard, 
 Journal of Physical Chemistry A, 112, 1040-1053 (2008).
+
+:link(Aktulga)
+[(Aktulga)] Aktulga, Fogarty, Pandit, Grama, Parallel Computing, to
+appear (2011).
diff --git a/doc/pair_resquared.html b/doc/pair_resquared.html
index 0a12a140f4..63e274fb52 100644
--- a/doc/pair_resquared.html
+++ b/doc/pair_resquared.html
@@ -11,6 +11,10 @@
 
 
      pair_style resquared command 
 
      
+
      pair_style resquared/gpu command 
+
      
+
      pair_style resquared/omp command 
+
      
 
      Syntax:
 
      
 
      pair_style resquared cutoff 
@@ -39,9 +43,7 @@ in this supplementary document.
 asphere extension (e.g. fix nve/asphere) in
 order to integrate particle rotation.  Additionally, atom_style
 ellipsoid should be used since it defines the
-rotational state of the ellipsoidal particles.  The size and shape of
-the ellipsoidal particles are defined by the shape
-command.
+rotational state and the size and shape of each ellipsoidal particle.
 
      
 
      The following coefficients must be defined for each pair of atoms
 types via the pair_coeff command as in the examples
@@ -59,30 +61,19 @@ commands:
 
    • epsilon_j_c = relative well depth of type J for end-to-end interactions
 
    • cutoff (distance units) 
 
    
-
    The last coefficient is optional.  If not specified, the global
-cutoff specified in the pair_style command is used.
-
    
-
    As described above, sigma is the size of the small spheres which are
-integrated over to create the potential.  Note that this is a
-different meaning for sigma than the pair_style
-gayberne potential uses.
-
    
 
    The parameters used depend on the type of the interacting particles,
-i.e. ellipsoid or LJ sphere.  The type of particle is determined by
-the diameters specified with the shape command.  LJ
-spheres have diameters equal to zero and thus represent a single
-particle with size sigma.  The epsilon_i_* or epsilon_j_* parameters
-are ignored for LJ sphere interactions.  The interactions between two
-LJ sphere particles are computed using the standard Lennard-Jones
-formula.
+i.e. ellipsoids or LJ spheres.  The type of a particle is determined
+by the diameters specified for its 3 shape paramters.  If all 3 shape
+parameters = 0.0, then the particle is treated as an LJ sphere.  The
+epsilon_i_* or epsilon_j_* parameters are ignored for LJ spheres.  If
+the 3 shape paraemters are > 0.0, then the particle is treated as an
+ellipsoid (even if the 3 parameters are equal to each other).
 
    
-
    For ellipsoid-LJ sphere interactions, a correction to the distance-
-of-closest approach equation has been implemented to reduce the error
-from disparate sizes; see this supplementary
-document.
+
    A12 specifies the energy prefactor which depends on the types of the
+two interacting particles.
 
    
-
    A12 specifies the energy prefactor which depends on the type of
-particles interacting.  For ellipsoid-ellipsoid interactions, A12 is
+
    For ellipsoid/ellipsoid interactions, the interaction is computed by
+the formulas in the supplementary docuement referenced above.  A12 is
 the Hamaker constant as described in (Everaers). In LJ
 units:
 
    
@@ -92,33 +83,37 @@ units:
 composing the ellipsoids and epsilon_LJ determines the interaction
 strength of the spherical particles.
 
    
-
    For ellipsoid-LJ sphere interactions, A12 gives the energy prefactor
-(see here for details:
+
    For ellipsoid/LJ sphere interactions, the interaction is also computed
+by the formulas in the supplementary docuement referenced above.  A12
+has a modifed form (see here for
+details):
 
    
 
    
 
    
-
    For LJ sphere-LJ sphere interactions, A12 is the standard epsilon used
-in Lennard-Jones pair styles:
+
    For ellipsoid/LJ sphere interactions, a correction to the distance-
+of-closest approach equation has been implemented to reduce the error
+from two particles of disparate sizes; see this supplementary
+document.
+
    
+
    For LJ sphere/LJ sphere interactions, the interaction is computed
+using the standard Lennard-Jones formula, which is much cheaper to
+compute than the ellipsoidal formulas.  A12 is used as epsilon in the
+standard LJ formula:
 
    
 
    
 
    
-
    sigma specifies the diameter of the continuous distribution of
+
    and the specified sigma is used as the sigma in the standard LJ
+formula.
+
    
+
    When one of both of the interacting particles are ellipsoids, then
+sigma specifies the diameter of the continuous distribution of
 constituent particles within each ellipsoid used to model the
-RE-squared potential. 
+RE-squared potential.  Note that this is a different meaning for
+sigma than the pair_style gayberne potential
+uses.
 
    
-
    For large uniform molecules it has been shown that the epsilon_*_*
-energy parameters are approximately representable in terms of local
-contact curvatures (Everaers):
-
    
-
    
-
    
-
    where a, b, and c give the particle diameters.
-
    
-
    The last coefficient is optional.  If not specified, the global cutoff
-specified in the pair_style command is used.
-
    
-
    The epsilon_i and epsilon_j coefficients are actually defined for atom
-types, not for pairs of atom types.  Thus, in a series of pair_coeff
+
    The epsilon_i and epsilon_j coefficients are defined for atom types,
+not for pairs of atom types.  Thus, in a series of pair_coeff
 commands, they only need to be specified once for each atom type.
 
    
 
    Specifically, if any of epsilon_i_a, epsilon_i_b, epsilon_i_c are
@@ -139,18 +134,51 @@ interactions are computed by another hybrid pair potential), then you
 still need to insure the epsilon a,b,c coefficients are assigned to
 that type in a "pair_coeff I J" command.
 
    
+
    For large uniform molecules it has been shown that the epsilon_*_*
+energy parameters are approximately representable in terms of local
+contact curvatures (Everaers):
+
    
+
    
+
    
+
    where a, b, and c give the particle diameters.
+
    
+
    The last coefficient is optional.  If not specified, the global cutoff
+specified in the pair_style command is used.
+
    
+
    
+
+
    Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
 
    
 
 
    Mixing, shift, table, tail correction, restart, rRESPA info:
 
    
 
    For atom type pairs I,J and I != J, the epsilon and sigma coefficients
-and cutoff distance can be mixed, but only for LJ sphere pairs.  The
+and cutoff distance can be mixed, but only for sphere pairs.  The
 default mix value is geometric.  See the "pair_modify" command for
 details.  Other type pairs cannot be mixed, due to the different
 meanings of the energy prefactors used to calculate the interactions
-and the implicit dependence of the ellipsoid-LJ sphere interaction on
-the equation for the Hamaker constant presented here.  Mixing of sigma
-and epsilon followed by calculation of the energy prefactors using the
+and the implicit dependence of the ellipsoid-sphere interaction on the
+equation for the Hamaker constant presented here.  Mixing of sigma and
+epsilon followed by calculation of the energy prefactors using the
 equations above is recommended.
 
    
 
    This pair styles supports the pair_modify shift
@@ -179,18 +207,17 @@ command.
 
 
    Restrictions:
 
    
-
    This style is part of the "asphere" package.  It is only enabled if
-LAMMPS was built with that package.  See the Making
+
    This style is part of the ASPHERE package.  It is only enabled if
+LAMMPS was built with that package.  See the Making
 LAMMPS section for more info.
 
    
-
    This pair style requires that atoms store torque and a quaternion to
-represent their orientation, as defined by the
-atom_style.  It also require they store a per-type
-shape.  The particles cannot store a per-particle
-diameter.
+
    This pair style requires that atoms be ellipsoids as defined by the
+atom_style ellipsoid command.
 
    
 
    Particles acted on by the potential can be extended aspherical or
-spherical particles, or point particles.
+spherical particles, or point particles.  Spherical particles have all
+3 of their shape parameters equal to each other.  Point particles have
+all 3 of their shape parameters equal to 0.0.
 
    
 
    The distance-of-closest-approach approximation used by LAMMPS becomes 
 less accurate when high-aspect ratio ellipsoids are used.
diff --git a/doc/pair_resquared.txt b/doc/pair_resquared.txt
index ad8dab5dc4..0762b05224 100755
--- a/doc/pair_resquared.txt
+++ b/doc/pair_resquared.txt
@@ -7,6 +7,8 @@
 :line
 
 pair_style resquared command :h3
+pair_style resquared/gpu command :h3
+pair_style resquared/omp command :h3
 
 [Syntax:]
 
@@ -36,9 +38,7 @@ Use of this pair style requires the NVE, NVT, or NPT fixes with the
 {asphere} extension (e.g. "fix nve/asphere"_fix_nve_asphere.html) in
 order to integrate particle rotation.  Additionally, "atom_style
 ellipsoid"_atom_style.html should be used since it defines the
-rotational state of the ellipsoidal particles.  The size and shape of
-the ellipsoidal particles are defined by the "shape"_shape.html
-command.
+rotational state and the size and shape of each ellipsoidal particle.
 
 The following coefficients must be defined for each pair of atoms
 types via the "pair_coeff"_pair_coeff.html command as in the examples
@@ -56,30 +56,19 @@ epsilon_j_b = relative well depth of type J for face-to-face interactions
 epsilon_j_c = relative well depth of type J for end-to-end interactions
 cutoff (distance units) :ul
 
-The last coefficient is optional.  If not specified, the global
-cutoff specified in the pair_style command is used.
-
-As described above, {sigma} is the size of the small spheres which are
-integrated over to create the potential.  Note that this is a
-different meaning for {sigma} than the "pair_style
-gayberne"_pair_gayberne.html potential uses.
-
 The parameters used depend on the type of the interacting particles,
-i.e. ellipsoid or LJ sphere.  The type of particle is determined by
-the diameters specified with the "shape"_shape.html command.  LJ
-spheres have diameters equal to zero and thus represent a single
-particle with size sigma.  The epsilon_i_* or epsilon_j_* parameters
-are ignored for LJ sphere interactions.  The interactions between two
-LJ sphere particles are computed using the standard Lennard-Jones
-formula.
+i.e. ellipsoids or LJ spheres.  The type of a particle is determined
+by the diameters specified for its 3 shape paramters.  If all 3 shape
+parameters = 0.0, then the particle is treated as an LJ sphere.  The
+epsilon_i_* or epsilon_j_* parameters are ignored for LJ spheres.  If
+the 3 shape paraemters are > 0.0, then the particle is treated as an
+ellipsoid (even if the 3 parameters are equal to each other).
 
-For ellipsoid-LJ sphere interactions, a correction to the distance-
-of-closest approach equation has been implemented to reduce the error
-from disparate sizes; see "this supplementary
-document"_PDF/pair_resquared_extra.pdf.
+A12 specifies the energy prefactor which depends on the types of the
+two interacting particles.
 
-A12 specifies the energy prefactor which depends on the type of
-particles interacting.  For ellipsoid-ellipsoid interactions, A12 is
+For ellipsoid/ellipsoid interactions, the interaction is computed by
+the formulas in the supplementary docuement referenced above.  A12 is
 the Hamaker constant as described in "(Everaers)"_#Everaers. In LJ
 units:
 
@@ -89,33 +78,37 @@ where rho gives the number density of the spherical particles
 composing the ellipsoids and epsilon_LJ determines the interaction
 strength of the spherical particles.
 
-For ellipsoid-LJ sphere interactions, A12 gives the energy prefactor
-(see "here"_PDF/pair_resquared_extra.pdf for details:
+For ellipsoid/LJ sphere interactions, the interaction is also computed
+by the formulas in the supplementary docuement referenced above.  A12
+has a modifed form (see "here"_PDF/pair_resquared_extra.pdf for
+details):
 
 :c,image(Eqs/pair_resquared2.jpg)
 
-For LJ sphere-LJ sphere interactions, A12 is the standard epsilon used
-in Lennard-Jones pair styles:
+For ellipsoid/LJ sphere interactions, a correction to the distance-
+of-closest approach equation has been implemented to reduce the error
+from two particles of disparate sizes; see "this supplementary
+document"_PDF/pair_resquared_extra.pdf.
+
+For LJ sphere/LJ sphere interactions, the interaction is computed
+using the standard Lennard-Jones formula, which is much cheaper to
+compute than the ellipsoidal formulas.  A12 is used as epsilon in the
+standard LJ formula:
 
 :c,image(Eqs/pair_resquared3.jpg)
 
-sigma specifies the diameter of the continuous distribution of
+and the specified {sigma} is used as the sigma in the standard LJ
+formula.
+
+When one of both of the interacting particles are ellipsoids, then
+{sigma} specifies the diameter of the continuous distribution of
 constituent particles within each ellipsoid used to model the
-RE-squared potential. 
+RE-squared potential.  Note that this is a different meaning for
+{sigma} than the "pair_style gayberne"_pair_gayberne.html potential
+uses.
 
-For large uniform molecules it has been shown that the epsilon_*_*
-energy parameters are approximately representable in terms of local
-contact curvatures "(Everaers)"_#Everaers:
-
-:c,image(Eqs/pair_resquared4.jpg)
-
-where a, b, and c give the particle diameters.
-
-The last coefficient is optional.  If not specified, the global cutoff
-specified in the pair_style command is used.
-
-The epsilon_i and epsilon_j coefficients are actually defined for atom
-types, not for pairs of atom types.  Thus, in a series of pair_coeff
+The epsilon_i and epsilon_j coefficients are defined for atom types,
+not for pairs of atom types.  Thus, in a series of pair_coeff
 commands, they only need to be specified once for each atom type.
 
 Specifically, if any of epsilon_i_a, epsilon_i_b, epsilon_i_c are
@@ -136,18 +129,51 @@ interactions are computed by another hybrid pair potential), then you
 still need to insure the epsilon a,b,c coefficients are assigned to
 that type in a "pair_coeff I J" command.
 
+For large uniform molecules it has been shown that the epsilon_*_*
+energy parameters are approximately representable in terms of local
+contact curvatures "(Everaers)"_#Everaers:
+
+:c,image(Eqs/pair_resquared4.jpg)
+
+where a, b, and c give the particle diameters.
+
+The last coefficient is optional.  If not specified, the global cutoff
+specified in the pair_style command is used.
+
+:line
+
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
 :line
 
 [Mixing, shift, table, tail correction, restart, rRESPA info]:
 
 For atom type pairs I,J and I != J, the epsilon and sigma coefficients
-and cutoff distance can be mixed, but only for LJ sphere pairs.  The
+and cutoff distance can be mixed, but only for sphere pairs.  The
 default mix value is {geometric}.  See the "pair_modify" command for
 details.  Other type pairs cannot be mixed, due to the different
 meanings of the energy prefactors used to calculate the interactions
-and the implicit dependence of the ellipsoid-LJ sphere interaction on
-the equation for the Hamaker constant presented here.  Mixing of sigma
-and epsilon followed by calculation of the energy prefactors using the
+and the implicit dependence of the ellipsoid-sphere interaction on the
+equation for the Hamaker constant presented here.  Mixing of sigma and
+epsilon followed by calculation of the energy prefactors using the
 equations above is recommended.
 
 This pair styles supports the "pair_modify"_pair_modify.html shift
@@ -176,18 +202,17 @@ command"_run_style.html.
 
 [Restrictions:]
 
-This style is part of the "asphere" package.  It is only enabled if
+This style is part of the ASPHERE package.  It is only enabled if
 LAMMPS was built with that package.  See the "Making
-LAMMPS"_Section_start.html#2_3 section for more info.
+LAMMPS"_Section_start.html#start_3 section for more info.
 
-This pair style requires that atoms store torque and a quaternion to
-represent their orientation, as defined by the
-"atom_style"_atom_style.html.  It also require they store a per-type
-"shape"_shape.html.  The particles cannot store a per-particle
-diameter.
+This pair style requires that atoms be ellipsoids as defined by the
+"atom_style ellipsoid"_atom_style.html command.
 
 Particles acted on by the potential can be extended aspherical or
-spherical particles, or point particles.
+spherical particles, or point particles.  Spherical particles have all
+3 of their shape parameters equal to each other.  Point particles have
+all 3 of their shape parameters equal to 0.0.
 
 The distance-of-closest-approach approximation used by LAMMPS becomes 
 less accurate when high-aspect ratio ellipsoids are used.
diff --git a/doc/pair_sdk.html b/doc/pair_sdk.html
new file mode 100644
index 0000000000..d382c03a9c
--- /dev/null
+++ b/doc/pair_sdk.html
@@ -0,0 +1,166 @@
+
+
    LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
    
+
+
+
+
+
+
+
    
+
+
    pair_style lj/sdk command 
+
    
+
    pair_style lj/sdk/gpu command 
+
    
+
    pair_style lj/sdk/omp command 
+
    
+
    pair_style lj/sdk/coul/long command 
+
    
+
    pair_style lj/sdk/coul/long/gpu command 
+
    
+
    pair_style lj/sdk/coul/long/omp command 
+
    
+
    Syntax:
+
    
+
    pair_style style args 
+
    
+
    • style = lj/sdk or lj/sdk/coul/long
+
    • args = list of arguments for a particular style 
+
    
+
      lj/sdk args = cutoff
+    cutoff = global cutoff for Lennard Jones interactions (distance units)
+  lj/sdk/coul/long args = cutoff (cutoff2)
+    cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
+    cutoff2 = global cutoff for Coulombic (optional) (distance units) 
+
    
+
    Examples:
+
    
+
    pair_style lj/sdk 2.5
+pair_coeff 1 1 lj12_6 1 1.1 2.8 
+
    
+
    pair_style lj/sdk/coul/long 10.0
+pair_style lj/sdk/coul/long 10.0 12.0
+pair_coeff 1 1 lj9_6 100.0 3.5 12.0 
+
    
+
    Description:
+
    
+
    The lj/sdk styles compute a 9/6, 12/4, or 12/6 Lennard-Jones potential,
+given by
+
    
+
    
+
    
+
    as required for the SDK Coarse-grained MD parametrization discussed in
+(Shinoda) and (DeVane).  Rc is the cutoff.
+
    
+
    Style lj/sdk/coul/long computes the adds Coulombic interactions 
+with an additional damping factor applied so it can be used in 
+conjunction with the kspace_style command and
+its ewald or pppm or pppm/cg option.  The Coulombic cutoff
+specified for this style means that pairwise interactions within
+this distance are computed directly; interactions outside that
+distance are computed in reciprocal space.
+
    
+
    The following coefficients must be defined for each pair of atoms
+types via the pair_coeff command as in the examples
+above, or in the data file or restart files read by the
+read_data or read_restart
+commands, or by mixing as described below:
+
    
+
    • cg_type (lj9_6, lj12_4, or lj12_6)
+
    • epsilon (energy units)
+
    • sigma (distance units)
+
    • cutoff1 (distance units) 
+
    
+
    Note that sigma is defined in the LJ formula as the zero-crossing
+distance for the potential, not as the energy minimum. The prefactors
+are chosen so that the potential minimum is at -epsilon.
+
    
+
    The latter 2 coefficients are optional.  If not specified, the global
+LJ and Coulombic cutoffs specified in the pair_style command are used.
+If only one cutoff is specified, it is used as the cutoff for both LJ
+and Coulombic interactions for this type pair.  If both coefficients
+are specified, they are used as the LJ and Coulombic cutoffs for this
+type pair.
+
    
+
    For lj/sdk/coul/long only the LJ cutoff can be specified since a
+Coulombic cutoff cannot be specified for an individual I,J type pair.
+All type pairs use the same global Coulombic cutoff specified in the
+pair_style command.
+
    
+
    
+
+
    Styles with a cuda, gpu, omp or opt suffix are functionally
+the same as the corresponding style without the suffix.  They have been
+optimized to run faster, depending on your available hardware, as
+discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA, GPU, USER-OMP, and
+OPT packages respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
+
    Mixing, shift, table, tail correction, restart, and rRESPA info:
+
    
+
    For atom type pairs I,J and I != J, the epsilon and sigma coefficients
+and cutoff distance for all of the lj/sdk pair styles cannot be mixed,
+since different pairs may have different exponents. So all parameters
+for all pairs have to be specified explicitly through the "pair_coeff"
+command. Defining then in a data file is also not supported, due to
+limitations of that file format.
+
    
+
    All of the lj/sdk pair styles support the
+pair_modify shift option for the energy of the
+Lennard-Jones portion of the pair interaction.
+
    
+
    The lj/sdk/coul/long pair styles support the
+pair_modify table option since they can tabulate
+the short-range portion of the long-range Coulombic interaction.
+
    
+
    All of the lj/sdk pair styles write their information to binary
+restart files, so pair_style and pair_coeff commands do
+not need to be specified in an input script that reads a restart file.
+
    
+
    The lj/sdk and lj/cut/coul/long pair styles do not support 
+the use of the inner, middle, and outer keywords of the run_style
+respa command.
+
    
+
    
+
+
    Restrictions:
+
    
+
    All of the lj/sdk pair styles are part of the USER-CG-CMM package.
+The lj/sdk/coul/long style also requires the KSPACE package to be
+built (which is enabled by default).  They are only enabled if LAMMPS
+was built with that package.  See the Making
+LAMMPS section for more info.
+
    
+
    Related commands:
+
    
+
    pair_coeff, angle_style sdk
+
    
+
    Default: none
+
    
+
    
+
+
+
+
    (Shinoda) Shinoda, DeVane, Klein, Mol Sim, 33, 27 (2007).
+
    
+
+
+
    (DeVane)  Shinoda, DeVane, Klein, Soft Matter, 4, 2453-2462 (2008).
+
    
+
diff --git a/doc/pair_sdk.txt b/doc/pair_sdk.txt
new file mode 100644
index 0000000000..476fd06fef
--- /dev/null
+++ b/doc/pair_sdk.txt
@@ -0,0 +1,154 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+pair_style lj/sdk command :h3
+pair_style lj/sdk/gpu command :h3
+pair_style lj/sdk/omp command :h3
+pair_style lj/sdk/coul/long command :h3
+pair_style lj/sdk/coul/long/gpu command :h3
+pair_style lj/sdk/coul/long/omp command :h3
+
+[Syntax:]
+
+pair_style style args :pre
+
+style = {lj/sdk} or {lj/sdk/coul/long}
+args = list of arguments for a particular style :ul
+  {lj/sdk} args = cutoff
+    cutoff = global cutoff for Lennard Jones interactions (distance units)
+  {lj/sdk/coul/long} args = cutoff (cutoff2)
+    cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
+    cutoff2 = global cutoff for Coulombic (optional) (distance units) :pre
+
+[Examples:]
+
+pair_style lj/sdk 2.5
+pair_coeff 1 1 lj12_6 1 1.1 2.8 :pre
+
+pair_style lj/sdk/coul/long 10.0
+pair_style lj/sdk/coul/long 10.0 12.0
+pair_coeff 1 1 lj9_6 100.0 3.5 12.0 :pre
+
+[Description:]
+
+The {lj/sdk} styles compute a 9/6, 12/4, or 12/6 Lennard-Jones potential,
+given by
+
+:c,image(Eqs/pair_cmm.jpg)
+
+as required for the SDK Coarse-grained MD parametrization discussed in
+"(Shinoda)"_#Shinoda and "(DeVane)"_#DeVane.  Rc is the cutoff.
+
+Style {lj/sdk/coul/long} computes the adds Coulombic interactions 
+with an additional damping factor applied so it can be used in 
+conjunction with the "kspace_style"_kspace_style.html command and
+its {ewald} or {pppm} or {pppm/cg} option.  The Coulombic cutoff
+specified for this style means that pairwise interactions within
+this distance are computed directly; interactions outside that
+distance are computed in reciprocal space.
+
+The following coefficients must be defined for each pair of atoms
+types via the "pair_coeff"_pair_coeff.html command as in the examples
+above, or in the data file or restart files read by the
+"read_data"_read_data.html or "read_restart"_read_restart.html
+commands, or by mixing as described below:
+
+cg_type (lj9_6, lj12_4, or lj12_6)
+epsilon (energy units)
+sigma (distance units)
+cutoff1 (distance units) :ul
+
+Note that sigma is defined in the LJ formula as the zero-crossing
+distance for the potential, not as the energy minimum. The prefactors
+are chosen so that the potential minimum is at -epsilon.
+
+The latter 2 coefficients are optional.  If not specified, the global
+LJ and Coulombic cutoffs specified in the pair_style command are used.
+If only one cutoff is specified, it is used as the cutoff for both LJ
+and Coulombic interactions for this type pair.  If both coefficients
+are specified, they are used as the LJ and Coulombic cutoffs for this
+type pair.
+
+For {lj/sdk/coul/long} only the LJ cutoff can be specified since a
+Coulombic cutoff cannot be specified for an individual I,J type pair.
+All type pairs use the same global Coulombic cutoff specified in the
+pair_style command.
+
+:line
+
+Styles with a {cuda}, {gpu}, {omp} or {opt} suffix are functionally
+the same as the corresponding style without the suffix.  They have been
+optimized to run faster, depending on your available hardware, as
+discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP, and
+OPT packages respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
+[Mixing, shift, table, tail correction, restart, and rRESPA info]:
+
+For atom type pairs I,J and I != J, the epsilon and sigma coefficients
+and cutoff distance for all of the lj/sdk pair styles {cannot} be mixed,
+since different pairs may have different exponents. So all parameters
+for all pairs have to be specified explicitly through the "pair_coeff"
+command. Defining then in a data file is also not supported, due to
+limitations of that file format.
+
+All of the lj/sdk pair styles support the
+"pair_modify"_pair_modify.html shift option for the energy of the
+Lennard-Jones portion of the pair interaction.
+
+The {lj/sdk/coul/long} pair styles support the
+"pair_modify"_pair_modify.html table option since they can tabulate
+the short-range portion of the long-range Coulombic interaction.
+
+All of the lj/sdk pair styles write their information to "binary
+restart files"_restart.html, so pair_style and pair_coeff commands do
+not need to be specified in an input script that reads a restart file.
+
+The lj/sdk and lj/cut/coul/long pair styles do not support 
+the use of the {inner}, {middle}, and {outer} keywords of the "run_style
+respa"_run_style.html command.
+
+:line
+
+[Restrictions:]
+
+All of the lj/sdk pair styles are part of the USER-CG-CMM package.
+The {lj/sdk/coul/long} style also requires the KSPACE package to be
+built (which is enabled by default).  They are only enabled if LAMMPS
+was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+[Related commands:]
+
+"pair_coeff"_pair_coeff.html, "angle_style sdk"_angle_sdk.html
+
+[Default:] none
+
+:line
+
+:link(Shinoda)
+[(Shinoda)] Shinoda, DeVane, Klein, Mol Sim, 33, 27 (2007).
+
+:link(DeVane)
+[(DeVane)]  Shinoda, DeVane, Klein, Soft Matter, 4, 2453-2462 (2008).
+
diff --git a/doc/pair_soft.html b/doc/pair_soft.html
index a444b544ff..145056ece1 100644
--- a/doc/pair_soft.html
+++ b/doc/pair_soft.html
@@ -11,6 +11,8 @@
 
 
    pair_style soft command 
 
    
+
    pair_style soft/omp command 
+
    
 
    Syntax:
 
    
 
    pair_style soft cutoff 
@@ -80,6 +82,28 @@ variables.
 
    
 
    
 
+
    Styles with a cuda, gpu, omp, or opt suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in this section of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
    
+
    These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the Making LAMMPS
+section for more info.
+
    
+
    You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the -suffix command-line
+switch when you invoke LAMMPS, or you can
+use the suffix command in your input script.
+
    
+
    See this section of the manual for more
+instructions on how to use the accelerated styles effectively.
+
    
+
    
+
 
    Mixing, shift, table, tail correction, restart, rRESPA info:
 
    
 
    For atom type pairs I,J and I != J, the A coefficient and cutoff
diff --git a/doc/pair_soft.txt b/doc/pair_soft.txt
index d1ca823fe5..14f68d7c45 100644
--- a/doc/pair_soft.txt
+++ b/doc/pair_soft.txt
@@ -7,6 +7,7 @@
 :line
 
 pair_style soft command :h3
+pair_style soft/omp command :h3
 
 [Syntax:]
 
@@ -77,6 +78,28 @@ variables.
 
 :line
 
+Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally 
+the same as the corresponding style without the suffix.  They have 
+been optimized to run faster, depending on your available hardware, 
+as discussed in "this section"_Section_accelerate.html of the manual.
+The accelerated styles take the same arguments and should produce the
+same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
+packages, respectively.  They are only enabled if LAMMPS was built with
+those packages.  See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the "-suffix command-line
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+use the "suffix"_suffix.html command in your input script.
+
+See "this section"_Section_accelerate.html of the manual for more
+instructions on how to use the accelerated styles effectively.
+
+:line
+
 [Mixing, shift, table, tail correction, restart, rRESPA info]:
 
 For atom type pairs I,J and I != J, the A coefficient and cutoff
diff --git a/doc/pair_sph_heatconduction.html b/doc/pair_sph_heatconduction.html
new file mode 100644
index 0000000000..570a324b87
--- /dev/null
+++ b/doc/pair_sph_heatconduction.html
@@ -0,0 +1,68 @@
+
+
    LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
    
+
+
+
+
+
+
+
    
+
+
    pair_style sph/heatconduction command 
+
    
+
    Syntax:
+
    
+
    pair_style sph/heatconduction 
+
    
+
    Examples:
+
    
+
    pair_style sph/heatconduction
+pair_coeff * * 1.0 2.4 
+
    
+
    Description:
+
    
+
    The sph/heatconduction style computes heat transport between SPH particles.
+The transport model is the diffusion euqation for the internal energy.
+
    
+
    See this PDF guide to using SPH in
+LAMMPS.
+
    
+
    The following coefficients must be defined for each pair of atoms
+types via the pair_coeff command as in the examples
+above.
+
    
+
    • D diffusion coefficient (length^2/time units)
+
    • h kernel function cutoff (distance units) 
+
    
+
    
+
+
    Mixing, shift, table, tail correction, restart, rRESPA info:
+
    
+
    This style does not support mixing.  Thus, coefficients for all
+I,J pairs must be specified explicitly.
+
    
+
    This style does not support the pair_modify
+shift, table, and tail options.
+
    
+
    This style does not write information to binary restart
+files.  Thus, you need to re-specify the pair_style and
+pair_coeff commands in an input script that reads a restart file.
+
    
+
    This style can only be used via the pair keyword of the run_style
+respa command.  It does not support the inner,
+middle, outer keywords.
+
    
+
    Restrictions:
+
    
+
    This pair style is part of the USER-SPH package.  It is only enabled
+if LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
    
+
    Related commands:
+
    
+
    pair_coeff, pair_sph/rhosum
+
    
+
    Default: none
+
    
+
diff --git a/doc/pair_sph_heatconduction.txt b/doc/pair_sph_heatconduction.txt
new file mode 100644
index 0000000000..d25debe91b
--- /dev/null
+++ b/doc/pair_sph_heatconduction.txt
@@ -0,0 +1,63 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+pair_style sph/heatconduction command :h3
+
+[Syntax:]
+
+pair_style sph/heatconduction :pre
+
+[Examples:]
+
+pair_style sph/heatconduction
+pair_coeff * * 1.0 2.4 :pre
+
+[Description:]
+
+The sph/heatconduction style computes heat transport between SPH particles.
+The transport model is the diffusion euqation for the internal energy.
+
+See "this PDF guide"_USER/sph/SPH_LAMMPS_userguide.pdf to using SPH in
+LAMMPS.
+
+The following coefficients must be defined for each pair of atoms
+types via the "pair_coeff"_pair_coeff.html command as in the examples
+above.
+
+D diffusion coefficient (length^2/time units)
+h kernel function cutoff (distance units) :ul
+
+:line
+
+[Mixing, shift, table, tail correction, restart, rRESPA info]:
+
+This style does not support mixing.  Thus, coefficients for all
+I,J pairs must be specified explicitly.
+
+This style does not support the "pair_modify"_pair_modify.html
+shift, table, and tail options.
+
+This style does not write information to "binary restart
+files"_restart.html.  Thus, you need to re-specify the pair_style and
+pair_coeff commands in an input script that reads a restart file.
+
+This style can only be used via the {pair} keyword of the "run_style
+respa"_run_style.html command.  It does not support the {inner},
+{middle}, {outer} keywords.
+
+[Restrictions:]
+
+This pair style is part of the USER-SPH package.  It is only enabled
+if LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+[Related commands:]
+
+"pair_coeff"_pair_coeff.html, pair_sph/rhosum
+
+[Default:] none
diff --git a/doc/pair_sph_idealgas.html b/doc/pair_sph_idealgas.html
new file mode 100644
index 0000000000..4d45b2959c
--- /dev/null
+++ b/doc/pair_sph_idealgas.html
@@ -0,0 +1,82 @@
+
+
    LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
    
+
+
+
+
+
+
+
    
+
+
    pair_style sph/idealgas command 
+
    
+
    Syntax:
+
    
+
    pair_style sph/idealgas 
+
    
+
    Examples:
+
    
+
    pair_style sph/idealgas
+pair_coeff * * 1.0 2.4 
+
    
+
    Description:
+
    
+
    The sph/idealgas style computes pressure forces between particles
+according to the ideal gas equation of state:
+
    
+
    
+
    
+
    where gamma = 1.4 is the heat capacity ratio, rho is the local
+density, and e is the internal energy per unit mass.  This pair style
+also computes Monaghan's artificial viscosity to prevent particles
+from interpentrating (Monaghan).
+
    
+
    See this PDF guide to using SPH in
+LAMMPS.
+
    
+
    The following coefficients must be defined for each pair of atoms
+types via the pair_coeff command as in the examples
+above.
+
    
+
    • nu artificial viscosity (no units)
+
    • h kernel function cutoff (distance units) 
+
    
+
    
+
+
    Mixing, shift, table, tail correction, restart, rRESPA info:
+
    
+
    This style does not support mixing.  Thus, coefficients for all
+I,J pairs must be specified explicitly.
+
    
+
    This style does not support the pair_modify
+shift, table, and tail options.
+
    
+
    This style does not write information to binary restart
+files.  Thus, you need to re-specify the pair_style and
+pair_coeff commands in an input script that reads a restart file.
+
    
+
    This style can only be used via the pair keyword of the run_style
+respa command.  It does not support the inner,
+middle, outer keywords.
+
    
+
    Restrictions:
+
    
+
    This pair style is part of the USER-SPH package.  It is only enabled
+if LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
    
+
    Related commands:
+
    
+
    pair_coeff, pair_sph/rhosum
+
    
+
    Default: none
+
    
+
    
+
+
+
+
    (Monaghan) Monaghan and Gingold, Journal of Computational Physics,
+52, 374-389 (1983).
+
    
+
diff --git a/doc/pair_sph_idealgas.txt b/doc/pair_sph_idealgas.txt
new file mode 100644
index 0000000000..f28d26265e
--- /dev/null
+++ b/doc/pair_sph_idealgas.txt
@@ -0,0 +1,77 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+pair_style sph/idealgas command :h3
+
+[Syntax:]
+
+pair_style sph/idealgas :pre
+
+[Examples:]
+
+pair_style sph/idealgas
+pair_coeff * * 1.0 2.4 :pre
+
+[Description:]
+
+The sph/idealgas style computes pressure forces between particles
+according to the ideal gas equation of state:
+
+:c,image(Eqs/pair_sph_ideal.jpg)
+
+where gamma = 1.4 is the heat capacity ratio, rho is the local
+density, and e is the internal energy per unit mass.  This pair style
+also computes Monaghan's artificial viscosity to prevent particles
+from interpentrating "(Monaghan)"_#Monoghan.
+
+See "this PDF guide"_USER/sph/SPH_LAMMPS_userguide.pdf to using SPH in
+LAMMPS.
+
+The following coefficients must be defined for each pair of atoms
+types via the "pair_coeff"_pair_coeff.html command as in the examples
+above.
+
+nu artificial viscosity (no units)
+h kernel function cutoff (distance units) :ul
+
+:line
+
+[Mixing, shift, table, tail correction, restart, rRESPA info]:
+
+This style does not support mixing.  Thus, coefficients for all
+I,J pairs must be specified explicitly.
+
+This style does not support the "pair_modify"_pair_modify.html
+shift, table, and tail options.
+
+This style does not write information to "binary restart
+files"_restart.html.  Thus, you need to re-specify the pair_style and
+pair_coeff commands in an input script that reads a restart file.
+
+This style can only be used via the {pair} keyword of the "run_style
+respa"_run_style.html command.  It does not support the {inner},
+{middle}, {outer} keywords.
+
+[Restrictions:]
+
+This pair style is part of the USER-SPH package.  It is only enabled
+if LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+[Related commands:]
+
+"pair_coeff"_pair_coeff.html, pair_sph/rhosum
+
+[Default:] none
+
+:line
+
+:link(Monoghan)
+[(Monaghan)] Monaghan and Gingold, Journal of Computational Physics,
+52, 374-389 (1983).
+
diff --git a/doc/pair_sph_lj.html b/doc/pair_sph_lj.html
new file mode 100644
index 0000000000..60cbdc67c8
--- /dev/null
+++ b/doc/pair_sph_lj.html
@@ -0,0 +1,86 @@
+
+
    LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
    
+
+
+
+
+
+
+
    
+
+
    pair_style sph/lj command 
+
    
+
    Syntax:
+
    
+
    pair_style sph/lj 
+
    
+
    Examples:
+
    
+
    pair_style sph/lj
+pair_coeff * * 1.0 2.4 
+
    
+
    Description:
+
    
+
    The sph/lj style computes pressure forces between particles according
+to the Lennard-Jones equation of state, which is computed according to
+Ree's 1980 polynomial fit (Ree). The Lennard-Jones parameters
+epsilon and sigma are set to unity.  This pair style also computes
+Monaghan's artificial viscosity to prevent particles from
+interpentrating (Monaghan).
+
    
+
    See this PDF guide to using SPH in
+LAMMPS.
+
    
+
    The following coefficients must be defined for each pair of atoms
+types via the pair_coeff command as in the examples
+above.
+
    
+
    • nu artificial viscosity (no units)
+
    • h kernel function cutoff (distance units) 
+
    
+
    
+
+
    Mixing, shift, table, tail correction, restart, rRESPA info:
+
    
+
    This style does not support mixing.  Thus, coefficients for all
+I,J pairs must be specified explicitly.
+
    
+
    This style does not support the pair_modify
+shift, table, and tail options.
+
    
+
    This style does not write information to binary restart
+files.  Thus, you need to re-specify the pair_style and
+pair_coeff commands in an input script that reads a restart file.
+
    
+
    This style can only be used via the pair keyword of the run_style
+respa command.  It does not support the inner,
+middle, outer keywords.
+
    
+
    Restrictions:
+
    
+
    As noted above, the Lennard-Jones parameters epsilon and sigma are set
+to unity.
+
    
+
    This pair style is part of the USER-SPH package.  It is only enabled
+if LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
    
+
    Related commands:
+
    
+
    pair_coeff, pair_sph/rhosum
+
    
+
    Default: none
+
    
+
    
+
+
+
+
    (Ree) Ree, Journal of Chemical Physics, 73, 5401 (1980).
+
    
+
+
+
    (Monaghan) Monaghan and Gingold, Journal of Computational Physics,
+52, 374-389 (1983).
+
    
+
diff --git a/doc/pair_sph_lj.txt b/doc/pair_sph_lj.txt
new file mode 100644
index 0000000000..8498841131
--- /dev/null
+++ b/doc/pair_sph_lj.txt
@@ -0,0 +1,79 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+pair_style sph/lj command :h3
+
+[Syntax:]
+
+pair_style sph/lj :pre
+
+[Examples:]
+
+pair_style sph/lj
+pair_coeff * * 1.0 2.4 :pre
+
+[Description:]
+
+The sph/lj style computes pressure forces between particles according
+to the Lennard-Jones equation of state, which is computed according to
+Ree's 1980 polynomial fit "(Ree)"_#Ree. The Lennard-Jones parameters
+epsilon and sigma are set to unity.  This pair style also computes
+Monaghan's artificial viscosity to prevent particles from
+interpentrating "(Monaghan)"_#Monoghan.
+
+See "this PDF guide"_USER/sph/SPH_LAMMPS_userguide.pdf to using SPH in
+LAMMPS.
+
+The following coefficients must be defined for each pair of atoms
+types via the "pair_coeff"_pair_coeff.html command as in the examples
+above.
+
+nu artificial viscosity (no units)
+h kernel function cutoff (distance units) :ul
+
+:line
+
+[Mixing, shift, table, tail correction, restart, rRESPA info]:
+
+This style does not support mixing.  Thus, coefficients for all
+I,J pairs must be specified explicitly.
+
+This style does not support the "pair_modify"_pair_modify.html
+shift, table, and tail options.
+
+This style does not write information to "binary restart
+files"_restart.html.  Thus, you need to re-specify the pair_style and
+pair_coeff commands in an input script that reads a restart file.
+
+This style can only be used via the {pair} keyword of the "run_style
+respa"_run_style.html command.  It does not support the {inner},
+{middle}, {outer} keywords.
+
+[Restrictions:]
+
+As noted above, the Lennard-Jones parameters epsilon and sigma are set
+to unity.
+
+This pair style is part of the USER-SPH package.  It is only enabled
+if LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+[Related commands:]
+
+"pair_coeff"_pair_coeff.html, pair_sph/rhosum
+
+[Default:] none
+
+:line
+
+:link(Ree)
+[(Ree)] Ree, Journal of Chemical Physics, 73, 5401 (1980).
+
+:link(Monoghan)
+[(Monaghan)] Monaghan and Gingold, Journal of Computational Physics,
+52, 374-389 (1983).
diff --git a/doc/pair_sph_rhosum.html b/doc/pair_sph_rhosum.html
new file mode 100644
index 0000000000..7e3f38a91a
--- /dev/null
+++ b/doc/pair_sph_rhosum.html
@@ -0,0 +1,69 @@
+
+
    LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
    
+
+
+
+
+
+
+
    
+
+
    pair_style sph/rhosum command 
+
    
+
    Syntax:
+
    
+
    pair_style sph/rhosum Nstep 
+
    
+
    • Nstep = timestep interval 
+
    
+
    Examples:
+
    
+
    pair_style sph/rhosum 10
+pair_coeff * * 2.4 
+
    
+
    Description:
+
    
+
    The sph/rhosum style computes the local particle mass density rho for
+SPH particles by kernel function interpolation, every Nstep timesteps.
+
    
+
    See this PDF guide to using SPH in
+LAMMPS.
+
    
+
    The following coefficients must be defined for each pair of atoms
+types via the pair_coeff command as in the examples
+above.
+
    
+
    • h (distance units) 
+
    
+
    
+
+
    Mixing, shift, table, tail correction, restart, rRESPA info:
+
    
+
    This style does not support mixing.  Thus, coefficients for all
+I,J pairs must be specified explicitly.
+
    
+
    This style does not support the pair_modify
+shift, table, and tail options.
+
    
+
    This style does not write information to binary restart
+files.  Thus, you need to re-specify the pair_style and
+pair_coeff commands in an input script that reads a restart file.
+
    
+
    This style can only be used via the pair keyword of the run_style
+respa command.  It does not support the inner,
+middle, outer keywords.
+
    
+
    Restrictions:
+
    
+
    This pair style is part of the USER-SPH package.  It is only enabled
+if LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
    
+
    Related commands:
+
    
+
    pair_coeff, pair_sph/taitwater
+
    
+
    Default: none
+
    
+
diff --git a/doc/pair_sph_rhosum.txt b/doc/pair_sph_rhosum.txt
new file mode 100644
index 0000000000..352e717f76
--- /dev/null
+++ b/doc/pair_sph_rhosum.txt
@@ -0,0 +1,64 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+pair_style sph/rhosum command :h3
+
+[Syntax:]
+
+pair_style sph/rhosum Nstep :pre
+
+Nstep = timestep interval :ul
+
+[Examples:]
+
+pair_style sph/rhosum 10
+pair_coeff * * 2.4 :pre
+
+[Description:]
+
+The sph/rhosum style computes the local particle mass density rho for
+SPH particles by kernel function interpolation, every Nstep timesteps.
+
+See "this PDF guide"_USER/sph/SPH_LAMMPS_userguide.pdf to using SPH in
+LAMMPS.
+
+The following coefficients must be defined for each pair of atoms
+types via the "pair_coeff"_pair_coeff.html command as in the examples
+above.
+
+h (distance units) :ul
+
+:line
+
+[Mixing, shift, table, tail correction, restart, rRESPA info]:
+
+This style does not support mixing.  Thus, coefficients for all
+I,J pairs must be specified explicitly.
+
+This style does not support the "pair_modify"_pair_modify.html
+shift, table, and tail options.
+
+This style does not write information to "binary restart
+files"_restart.html.  Thus, you need to re-specify the pair_style and
+pair_coeff commands in an input script that reads a restart file.
+
+This style can only be used via the {pair} keyword of the "run_style
+respa"_run_style.html command.  It does not support the {inner},
+{middle}, {outer} keywords.
+
+[Restrictions:]
+
+This pair style is part of the USER-SPH package.  It is only enabled
+if LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+[Related commands:]
+
+"pair_coeff"_pair_coeff.html, pair_sph/taitwater
+
+[Default:] none
diff --git a/doc/pair_sph_taitwater.html b/doc/pair_sph_taitwater.html
new file mode 100644
index 0000000000..7c350f2f37
--- /dev/null
+++ b/doc/pair_sph_taitwater.html
@@ -0,0 +1,85 @@
+
+
    LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
    
+
+
+
+
+
+
+
    
+
+
    pair_style sph/taitwater command 
+
    
+
    Syntax:
+
    
+
    pair_style sph/taitwater 
+
    
+
    Examples:
+
    
+
    pair_style sph/taitwater
+pair_coeff * * 1000.0 1430.0 1.0 2.4 
+
    
+
    Description:
+
    
+
    The sph/taitwater style computes pressure forces between SPH particles
+according to Tait's equation of state:
+
    
+
    
+
    
+
    where gamma = 7 and B = c_0^2 rho_0 / gamma, with rho_0 being the
+reference density and c_0 the reference speed of sound.
+
    
+
    This pair style also computes Monaghan's artificial viscosity to
+prevent particles from interpentrating (Monaghan).
+
    
+
    See this PDF guide to using SPH in
+LAMMPS.
+
    
+
    The following coefficients must be defined for each pair of atoms
+types via the pair_coeff command as in the examples
+above.
+
    
+
    • rho0 reference density (mass/volume units)
+
    • c0 reference soundspeed (distance/time units)
+
    • nu artificial viscosity (no units)
+
    • h kernel function cutoff (distance units) 
+
    
+
    
+
+
    Mixing, shift, table, tail correction, restart, rRESPA info:
+
    
+
    This style does not support mixing.  Thus, coefficients for all
+I,J pairs must be specified explicitly.
+
    
+
    This style does not support the pair_modify
+shift, table, and tail options.
+
    
+
    This style does not write information to binary restart
+files.  Thus, you need to re-specify the pair_style and
+pair_coeff commands in an input script that reads a restart file.
+
    
+
    This style can only be used via the pair keyword of the run_style
+respa command.  It does not support the inner,
+middle, outer keywords.
+
    
+
    Restrictions:
+
    
+
    This pair style is part of the USER-SPH package.  It is only enabled
+if LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
    
+
    Related commands:
+
    
+
    pair_coeff, pair_sph/rhosum
+
    
+
    Default: none
+
    
+
    
+
+
+
+
    (Monaghan) Monaghan and Gingold, Journal of Computational Physics,
+52, 374-389 (1983).
+
    
+
diff --git a/doc/pair_sph_taitwater.txt b/doc/pair_sph_taitwater.txt
new file mode 100644
index 0000000000..5f6fbeb5b4
--- /dev/null
+++ b/doc/pair_sph_taitwater.txt
@@ -0,0 +1,79 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+pair_style sph/taitwater command :h3
+
+[Syntax:]
+
+pair_style sph/taitwater :pre
+
+[Examples:]
+
+pair_style sph/taitwater
+pair_coeff * * 1000.0 1430.0 1.0 2.4 :pre
+
+[Description:]
+
+The sph/taitwater style computes pressure forces between SPH particles
+according to Tait's equation of state:
+
+:c,image(Eqs/pair_sph_tait.jpg)
+
+where gamma = 7 and B = c_0^2 rho_0 / gamma, with rho_0 being the
+reference density and c_0 the reference speed of sound.
+
+This pair style also computes Monaghan's artificial viscosity to
+prevent particles from interpentrating "(Monaghan)"_#Monaghan.
+
+See "this PDF guide"_USER/sph/SPH_LAMMPS_userguide.pdf to using SPH in
+LAMMPS.
+
+The following coefficients must be defined for each pair of atoms
+types via the "pair_coeff"_pair_coeff.html command as in the examples
+above.
+
+rho0 reference density (mass/volume units)
+c0 reference soundspeed (distance/time units)
+nu artificial viscosity (no units)
+h kernel function cutoff (distance units) :ul
+
+:line
+
+[Mixing, shift, table, tail correction, restart, rRESPA info]:
+
+This style does not support mixing.  Thus, coefficients for all
+I,J pairs must be specified explicitly.
+
+This style does not support the "pair_modify"_pair_modify.html
+shift, table, and tail options.
+
+This style does not write information to "binary restart
+files"_restart.html.  Thus, you need to re-specify the pair_style and
+pair_coeff commands in an input script that reads a restart file.
+
+This style can only be used via the {pair} keyword of the "run_style
+respa"_run_style.html command.  It does not support the {inner},
+{middle}, {outer} keywords.
+
+[Restrictions:]
+
+This pair style is part of the USER-SPH package.  It is only enabled
+if LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+[Related commands:]
+
+"pair_coeff"_pair_coeff.html, pair_sph/rhosum
+
+[Default:] none
+
+:line
+
+:link(Monoghan)
+[(Monaghan)] Monaghan and Gingold, Journal of Computational Physics,
+52, 374-389 (1983).
diff --git a/doc/pair_sph_taitwater_morris.html b/doc/pair_sph_taitwater_morris.html
new file mode 100644
index 0000000000..4abffb4c53
--- /dev/null
+++ b/doc/pair_sph_taitwater_morris.html
@@ -0,0 +1,83 @@
+
+
    LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands 
+
    
+
+
+
+
+
+
+
    
+
+
    pair_style sph/taitwater/morris command 
+
    
+
    Syntax:
+
    
+
    pair_style sph/taitwater/morris 
+
    
+
    Examples:
+
    
+
    pair_style sph/taitwater/morris
+pair_coeff * * 1000.0 1430.0 1.0 2.4 
+
    
+
    Description:
+
    
+
    The sph/taitwater/morris style computes pressure forces between SPH
+particles according to Tait's equation of state:
+
    
+
    
+
    
+
    where gamma = 7 and B = c_0^2 rho_0 / gamma, with rho_0 being the
+reference density and c_0 the reference speed of sound.
+
    
+
    This pair style also computes laminar viscosity (Morris).
+
    
+
    See this PDF guide to using SPH in
+LAMMPS.
+
    
+
    The following coefficients must be defined for each pair of atoms
+types via the pair_coeff command as in the examples
+above.
+
    
+
    • rho0 reference density (mass/volume units)
+
    • c0 reference soundspeed (distance/time units)
+
    • nu dynamic viscosity (mass*distance/time units)
+
    • h kernel function cutoff (distance units) 
+
    
+
    
+
+
    Mixing, shift, table, tail correction, restart, rRESPA info:
+
    
+
    This style does not support mixing.  Thus, coefficients for all
+I,J pairs must be specified explicitly.
+
    
+
    This style does not support the pair_modify
+shift, table, and tail options.
+
    
+
    This style does not write information to binary restart
+files.  Thus, you need to re-specify the pair_style and
+pair_coeff commands in an input script that reads a restart file.
+
    
+
    This style can only be used via the pair keyword of the run_style
+respa command.  It does not support the inner,
+middle, outer keywords.
+
    
+
    Restrictions:
+
    
+
    This pair style is part of the USER-SPH package.  It is only enabled
+if LAMMPS was built with that package.  See the Making
+LAMMPS section for more info.
+
    
+
    Related commands:
+
    
+
    pair_coeff, pair_sph/rhosum
+
    
+
    Default: none
+
    
+
    
+
+
+
+
    (Morris) Morris, Fox, Zhu, J Comp Physics, 136, 214–226 (1997).
+
    
+
diff --git a/doc/pair_sph_taitwater_morris.txt b/doc/pair_sph_taitwater_morris.txt
new file mode 100644
index 0000000000..8bedfd4991
--- /dev/null
+++ b/doc/pair_sph_taitwater_morris.txt
@@ -0,0 +1,79 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+pair_style sph/taitwater/morris command :h3
+
+[Syntax:]
+
+pair_style sph/taitwater/morris :pre
+
+[Examples:]
+
+pair_style sph/taitwater/morris
+pair_coeff * * 1000.0 1430.0 1.0 2.4 :pre
+
+[Description:]
+
+The sph/taitwater/morris style computes pressure forces between SPH
+particles according to Tait's equation of state:
+
+:c,image(Eqs/pair_sph_tait.jpg)
+
+where gamma = 7 and B = c_0^2 rho_0 / gamma, with rho_0 being the
+reference density and c_0 the reference speed of sound.
+
+This pair style also computes laminar viscosity "(Morris)"_#Morris.
+
+See "this PDF guide"_USER/sph/SPH_LAMMPS_userguide.pdf to using SPH in
+LAMMPS.
+
+The following coefficients must be defined for each pair of atoms
+types via the "pair_coeff"_pair_coeff.html command as in the examples
+above.
+
+rho0 reference density (mass/volume units)
+c0 reference soundspeed (distance/time units)
+nu dynamic viscosity (mass*distance/time units)
+h kernel function cutoff (distance units) :ul
+
+:line
+
+[Mixing, shift, table, tail correction, restart, rRESPA info]:
+
+This style does not support mixing.  Thus, coefficients for all
+I,J pairs must be specified explicitly.
+
+This style does not support the "pair_modify"_pair_modify.html
+shift, table, and tail options.
+
+This style does not write information to "binary restart
+files"_restart.html.  Thus, you need to re-specify the pair_style and
+pair_coeff commands in an input script that reads a restart file.
+
+This style can only be used via the {pair} keyword of the "run_style
+respa"_run_style.html command.  It does not support the {inner},
+{middle}, {outer} keywords.
+
+[Restrictions:]
+
+This pair style is part of the USER-SPH package.  It is only enabled
+if LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+[Related commands:]
+
+"pair_coeff"_pair_coeff.html, pair_sph/rhosum
+
+[Default:] none
+
+:line
+
+:link(Morris)
+[(Morris)] Morris, Fox, Zhu, J Comp Physics, 136, 214–226 (1997).
+
+
diff --git a/doc/pair_style.html b/doc/pair_style.html
index 450428a7bc..c192fce8aa 100644
--- a/doc/pair_style.html
+++ b/doc/pair_style.html
@@ -89,13 +89,17 @@ the pair_style command, and coefficients specified by the associated
 
  • pair_style hybrid - multiple styles of pairwise interactions
 
  • pair_style hybrid/overlay - multiple styles of superposed pairwise interactions 
 
-