patch 19May17

Merge pull request #493 from akohlmey/doc-and-example-fixes
Doc and example fixes
2017-05-19 07:35:36 -06:00 · 2017-05-18 16:40:46 -06:00 · 2017-05-18 18:34:27 -04:00 · 2017-05-18 18:34:03 -04:00 · 2017-05-18 13:44:34 -06:00 · 2017-05-18 13:14:47 -06:00
7443 changed files with 2094084 additions and 655608 deletions
--- a/.gitignore
+++ b/.gitignore
@ -0,0 +1,34 @@
+*~
+*.o
+*.so
+*.cu_o
+*.ptx
+*_ptx.h
+*.a
+*.d
+*.x
+*.exe
+*.dll
+*.pyc
+__pycache__
+
+Obj_*
+log.lammps
+log.cite
+*.bz2
+*.gz
+*.tar
+.*.swp
+*.orig
+*.rej
+.vagrant
+\#*#
+.#*
+
+.DS_Store
+.DS_Store?
+._*
+.Spotlight-V100
+.Trashes
+ehthumbs.db
+Thumbs.db
--- a/bench/Cu_u3.eam
+++ b/bench/Cu_u3.eam
@ -1,4 +1,4 @@
-Cu functions (universal 3)
+DATE: 2007-06-11 CONTRIBUTOR: Stephen Foiles, foiles@sandia.gov CITATION: Foiles et al, Phys Rev B, 33, 7983 (1986) COMMENT: Cu functions (universal 3), SM Foiles et al, PRB, 33, 7983 (1986)
   29     63.550         3.6150    FCC
  500  5.0100200400801306e-04  500  1.0000000000000009e-02  4.9499999999999886e+00
  0.                     -3.1561636903424350e-01 -5.2324876182494506e-01 -6.9740831416804383e-01 -8.5202525457518519e-01
--- a/bench/FERMI/README
+++ b/bench/FERMI/README
@ -14,7 +14,7 @@ lmp_linux_mixed
 lmp_linux_double

 The precision (single, mixed, double) refers to the GPU and USER-CUDA
-pacakge precision.  See the README files in the lib/gpu and lib/cuda
+package precision.  See the README files in the lib/gpu and lib/cuda
 directories for instructions on how to build the packages with
 different precisions.  The GPU and USER-CUDA sub-sections of the
 doc/Section_accelerate.html file also describes this process.
--- a/bench/POTENTIALS/in.dpd
+++ b/bench/POTENTIALS/in.dpd
@ -2,7 +2,7 @@

 units		lj
 atom_style	atomic
-communicate	single vel yes
+comm_modify     mode single vel yes

 lattice		fcc 3.0
 region		box block 0 20 0 20 0 20
--- a/bench/log.15May15.chain.fixed.icc.1
+++ b/bench/log.15May15.chain.fixed.icc.1
@ -1,67 +0,0 @@
-LAMMPS (30 Apr 2015)
-# FENE beadspring benchmark
-
-units		lj
-atom_style	bond
-special_bonds   fene
-
-read_data	data.chain
-  orthogonal box = (-16.796 -16.796 -16.796) to (16.796 16.796 16.796)
-  1 by 1 by 1 MPI processor grid
-  reading atoms ...
-  32000 atoms
-  reading velocities ...
-  32000 velocities
-  scanning bonds ...
-  1 = max bonds/atom
-  reading bonds ...
-  31680 bonds
-  2 = max # of 1-2 neighbors
-  2 = max # of special neighbors
-
-neighbor	0.4 bin
-neigh_modify	every 1 delay 1
-
-bond_style      fene
-bond_coeff	1 30.0 1.5 1.0 1.0
-
-pair_style	lj/cut 1.12
-pair_modify	shift yes
-pair_coeff	1 1 1.0 1.0 1.12
-
-fix		1 all nve
-fix		2 all langevin 1.0 1.0 10.0 904297
-
-thermo          100
-timestep	0.012
-
-run		100
-Neighbor list info ...
-  1 neighbor list requests
-  update every 1 steps, delay 1 steps, check yes
-  master list distance cutoff = 1.52
-Memory usage per processor = 11.5189 Mbytes
-Step Temp E_pair E_mol TotEng Press 
-       0   0.97029772   0.44484087    20.494523    22.394765    4.6721833 
-     100    0.9729966    0.4361122    20.507698     22.40326    4.6548819 
-Loop time of 0.978717 on 1 procs for 100 steps with 32000 atoms
-
-Pair  time (%) = 0.195673 (19.9928)
-Bond  time (%) = 0.0878832 (8.97943)
-Neigh time (%) = 0.448004 (45.7746)
-Comm  time (%) = 0.0329976 (3.37152)
-Outpt time (%) = 0.000105143 (0.0107429)
-Other time (%) = 0.214054 (21.8709)
-
-Nlocal:    32000 ave 32000 max 32000 min
-Histogram: 1 0 0 0 0 0 0 0 0 0
-Nghost:    9493 ave 9493 max 9493 min
-Histogram: 1 0 0 0 0 0 0 0 0 0
-Neighs:    155873 ave 155873 max 155873 min
-Histogram: 1 0 0 0 0 0 0 0 0 0
-
-Total # of neighbors = 155873
-Ave neighs/atom = 4.87103
-Ave special neighs/atom = 1.98
-Neighbor list builds = 25
-Dangerous builds = 0
--- a/bench/log.15May15.chain.fixed.icc.4
+++ b/bench/log.15May15.chain.fixed.icc.4
@ -1,67 +0,0 @@
-LAMMPS (30 Apr 2015)
-# FENE beadspring benchmark
-
-units		lj
-atom_style	bond
-special_bonds   fene
-
-read_data	data.chain
-  orthogonal box = (-16.796 -16.796 -16.796) to (16.796 16.796 16.796)
-  1 by 2 by 2 MPI processor grid
-  reading atoms ...
-  32000 atoms
-  reading velocities ...
-  32000 velocities
-  scanning bonds ...
-  1 = max bonds/atom
-  reading bonds ...
-  31680 bonds
-  2 = max # of 1-2 neighbors
-  2 = max # of special neighbors
-
-neighbor	0.4 bin
-neigh_modify	every 1 delay 1
-
-bond_style      fene
-bond_coeff	1 30.0 1.5 1.0 1.0
-
-pair_style	lj/cut 1.12
-pair_modify	shift yes
-pair_coeff	1 1 1.0 1.0 1.12
-
-fix		1 all nve
-fix		2 all langevin 1.0 1.0 10.0 904297
-
-thermo          100
-timestep	0.012
-
-run		100
-Neighbor list info ...
-  1 neighbor list requests
-  update every 1 steps, delay 1 steps, check yes
-  master list distance cutoff = 1.52
-Memory usage per processor = 3.91518 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.274371 on 4 procs for 100 steps with 32000 atoms
-
-Pair  time (%) = 0.0504887 (18.4016)
-Bond  time (%) = 0.0229129 (8.35106)
-Neigh time (%) = 0.119957 (43.7206)
-Comm  time (%) = 0.020835 (7.59373)
-Outpt time (%) = 5.74589e-05 (0.0209421)
-Other time (%) = 0.0601202 (21.912)
-
-Nlocal:    8000 ave 8030 max 7974 min
-Histogram: 1 0 0 1 0 1 0 0 0 1
-Nghost:    4177 ave 4191 max 4160 min
-Histogram: 1 0 0 0 1 0 0 1 0 1
-Neighs:    38995.8 ave 39169 max 38852 min
-Histogram: 1 0 0 1 1 0 0 0 0 1
-
-Total # of neighbors = 155983
-Ave neighs/atom = 4.87447
-Ave special neighs/atom = 1.98
-Neighbor list builds = 25
-Dangerous builds = 0
--- a/bench/log.15May15.chain.scaled.icc.4
+++ b/bench/log.15May15.chain.scaled.icc.4
@ -1,83 +0,0 @@
-LAMMPS (30 Apr 2015)
-# FENE beadspring benchmark
-
-variable	x index 1
-variable	y index 1
-variable	z index 1
-
-units		lj
-atom_style	bond
-atom_modify	map hash
-special_bonds   fene
-
-read_data	data.chain
-  orthogonal box = (-16.796 -16.796 -16.796) to (16.796 16.796 16.796)
-  1 by 2 by 2 MPI processor grid
-  reading atoms ...
-  32000 atoms
-  reading velocities ...
-  32000 velocities
-  scanning bonds ...
-  1 = max bonds/atom
-  reading bonds ...
-  31680 bonds
-  2 = max # of 1-2 neighbors
-  2 = max # of special neighbors
-
-replicate	$x $y $z
-replicate	2 $y $z
-replicate	2 2 $z
-replicate	2 2 1
-  orthogonal box = (-16.796 -16.796 -16.796) to (50.388 50.388 16.796)
-  2 by 2 by 1 MPI processor grid
-  128000 atoms
-  126720 bonds
-  2 = max # of 1-2 neighbors
-  2 = max # of special neighbors
-
-neighbor	0.4 bin
-neigh_modify	every 1 delay 1
-
-bond_style      fene
-bond_coeff	1 30.0 1.5 1.0 1.0
-
-pair_style	lj/cut 1.12
-pair_modify	shift yes
-pair_coeff	1 1 1.0 1.0 1.12
-
-fix		1 all nve
-fix		2 all langevin 1.0 1.0 10.0 904297
-
-thermo          100
-timestep	0.012
-
-run		100
-Neighbor list info ...
-  1 neighbor list requests
-  update every 1 steps, delay 1 steps, check yes
-  master list distance cutoff = 1.52
-Memory usage per processor = 12.8735 Mbytes
-Step Temp E_pair E_mol TotEng Press 
-       0   0.97027498   0.44484087    20.494523    22.394765    4.6721833 
-     100   0.97682955   0.44239968    20.500229    22.407862    4.6527025 
-Loop time of 1.19919 on 4 procs for 100 steps with 128000 atoms
-
-Pair  time (%) = 0.227794 (18.9957)
-Bond  time (%) = 0.0981662 (8.18606)
-Neigh time (%) = 0.527868 (44.0188)
-Comm  time (%) = 0.0980042 (8.17255)
-Outpt time (%) = 0.000200272 (0.0167006)
-Other time (%) = 0.247155 (20.6102)
-
-Nlocal:    32000 ave 32015 max 31983 min
-Histogram: 1 0 1 0 0 0 0 0 1 1
-Nghost:    9492 ave 9522 max 9432 min
-Histogram: 1 0 0 0 0 0 1 0 0 2
-Neighs:    155837 ave 156079 max 155506 min
-Histogram: 1 0 0 0 0 1 0 0 1 1
-
-Total # of neighbors = 623349
-Ave neighs/atom = 4.86991
-Ave special neighs/atom = 1.98
-Neighbor list builds = 25
-Dangerous builds = 0
--- a/bench/log.15May15.chute.fixed.icc.1
+++ b/bench/log.15May15.chute.fixed.icc.1
@ -1,69 +0,0 @@
-LAMMPS (30 Apr 2015)
-# LAMMPS benchmark of granular flow
-# chute flow of 32000 atoms with frozen base at 26 degrees
-
-units		lj
-atom_style	sphere
-boundary	p p fs
-newton		off
-comm_modify	vel yes
-
-read_data	data.chute
-  orthogonal box = (0 0 0) to (40 20 37.2886)
-  1 by 1 by 1 MPI processor grid
-  reading atoms ...
-  32000 atoms
-  reading velocities ...
-  32000 velocities
-
-pair_style	gran/hooke/history 200000.0 NULL 50.0 NULL 0.5 0
-pair_coeff	* *
-
-neighbor	0.1 bin
-neigh_modify	every 1 delay 0
-
-timestep	0.0001
-
-group		bottom type 2
-912 atoms in group bottom
-group		active subtract all bottom
-31088 atoms in group active
-neigh_modify	exclude group bottom bottom
-
-fix		1 all gravity 1.0 chute 26.0
-fix		2 bottom freeze
-fix		3 active nve/sphere
-
-compute		1 all erotate/sphere
-thermo_style	custom step atoms ke c_1 vol
-thermo_modify	norm no
-thermo		100
-
-run		100
-Neighbor list info ...
-  2 neighbor list requests
-  update every 1 steps, delay 0 steps, check yes
-  master list distance cutoff = 1.1
-Memory usage per processor = 15.567 Mbytes
-Step Atoms KinEng 1 Volume 
-       0    32000    784139.13    1601.1263    29833.783 
-     100    32000    784292.08    1571.0968    29834.707 
-Loop time of 0.539647 on 1 procs for 100 steps with 32000 atoms
-
-Pair  time (%) = 0.328789 (60.9267)
-Neigh time (%) = 0.0401711 (7.44397)
-Comm  time (%) = 0.0179052 (3.31795)
-Outpt time (%) = 0.00019908 (0.0368907)
-Other time (%) = 0.152582 (28.2745)
-
-Nlocal:    32000 ave 32000 max 32000 min
-Histogram: 1 0 0 0 0 0 0 0 0 0
-Nghost:    5463 ave 5463 max 5463 min
-Histogram: 1 0 0 0 0 0 0 0 0 0
-Neighs:    115133 ave 115133 max 115133 min
-Histogram: 1 0 0 0 0 0 0 0 0 0
-
-Total # of neighbors = 115133
-Ave neighs/atom = 3.59791
-Neighbor list builds = 2
-Dangerous builds = 0
--- a/bench/log.15May15.chute.fixed.icc.4
+++ b/bench/log.15May15.chute.fixed.icc.4
@ -1,69 +0,0 @@
-LAMMPS (30 Apr 2015)
-# LAMMPS benchmark of granular flow
-# chute flow of 32000 atoms with frozen base at 26 degrees
-
-units		lj
-atom_style	sphere
-boundary	p p fs
-newton		off
-comm_modify	vel yes
-
-read_data	data.chute
-  orthogonal box = (0 0 0) to (40 20 37.2886)
-  2 by 1 by 2 MPI processor grid
-  reading atoms ...
-  32000 atoms
-  reading velocities ...
-  32000 velocities
-
-pair_style	gran/hooke/history 200000.0 NULL 50.0 NULL 0.5 0
-pair_coeff	* *
-
-neighbor	0.1 bin
-neigh_modify	every 1 delay 0
-
-timestep	0.0001
-
-group		bottom type 2
-912 atoms in group bottom
-group		active subtract all bottom
-31088 atoms in group active
-neigh_modify	exclude group bottom bottom
-
-fix		1 all gravity 1.0 chute 26.0
-fix		2 bottom freeze
-fix		3 active nve/sphere
-
-compute		1 all erotate/sphere
-thermo_style	custom step atoms ke c_1 vol
-thermo_modify	norm no
-thermo		100
-
-run		100
-Neighbor list info ...
-  2 neighbor list requests
-  update every 1 steps, delay 0 steps, check yes
-  master list distance cutoff = 1.1
-Memory usage per processor = 6.81783 Mbytes
-Step Atoms KinEng 1 Volume 
-       0    32000    784139.13    1601.1263    29833.783 
-     100    32000    784292.08    1571.0968    29834.707 
-Loop time of 0.146584 on 4 procs for 100 steps with 32000 atoms
-
-Pair  time (%) = 0.0737562 (50.3167)
-Neigh time (%) = 0.0105147 (7.17314)
-Comm  time (%) = 0.0147474 (10.0607)
-Outpt time (%) = 0.000131965 (0.0900267)
-Other time (%) = 0.0474337 (32.3594)
-
-Nlocal:    8000 ave 8008 max 7992 min
-Histogram: 2 0 0 0 0 0 0 0 0 2
-Nghost:    2439 ave 2450 max 2428 min
-Histogram: 2 0 0 0 0 0 0 0 0 2
-Neighs:    29500.5 ave 30488 max 28513 min
-Histogram: 2 0 0 0 0 0 0 0 0 2
-
-Total # of neighbors = 118002
-Ave neighs/atom = 3.68756
-Neighbor list builds = 2
-Dangerous builds = 0
--- a/bench/log.15May15.chute.scaled.icc.4
+++ b/bench/log.15May15.chute.scaled.icc.4
@ -1,79 +0,0 @@
-LAMMPS (30 Apr 2015)
-# LAMMPS benchmark of granular flow
-# chute flow of 32000 atoms with frozen base at 26 degrees
-
-variable	x index 1
-variable	y index 1
-
-units		lj
-atom_style	sphere
-boundary	p p fs
-newton		off
-comm_modify	vel yes
-
-read_data	data.chute
-  orthogonal box = (0 0 0) to (40 20 37.2886)
-  2 by 1 by 2 MPI processor grid
-  reading atoms ...
-  32000 atoms
-  reading velocities ...
-  32000 velocities
-
-replicate	$x $y 1
-replicate	2 $y 1
-replicate	2 2 1
-  orthogonal box = (0 0 0) to (80 40 37.2922)
-  2 by 2 by 1 MPI processor grid
-  128000 atoms
-
-pair_style	gran/hooke/history 200000.0 NULL 50.0 NULL 0.5 0
-pair_coeff	* *
-
-neighbor	0.1 bin
-neigh_modify	every 1 delay 0
-
-timestep	0.0001
-
-group		bottom type 2
-3648 atoms in group bottom
-group		active subtract all bottom
-124352 atoms in group active
-neigh_modify	exclude group bottom bottom
-
-fix		1 all gravity 1.0 chute 26.0
-fix		2 bottom freeze
-fix		3 active nve/sphere
-
-compute		1 all erotate/sphere
-thermo_style	custom step atoms ke c_1 vol
-thermo_modify	norm no
-thermo		100
-
-run		100
-Neighbor list info ...
-  2 neighbor list requests
-  update every 1 steps, delay 0 steps, check yes
-  master list distance cutoff = 1.1
-Memory usage per processor = 15.7007 Mbytes
-Step Atoms KinEng 1 Volume 
-       0   128000    3136556.5    6404.5051    119335.13 
-     100   128000    3137168.3    6284.3873    119338.83 
-Loop time of 0.899154 on 4 procs for 100 steps with 128000 atoms
-
-Pair  time (%) = 0.523338 (58.2033)
-Neigh time (%) = 0.0433982 (4.82656)
-Comm  time (%) = 0.0642623 (7.14697)
-Outpt time (%) = 0.000541449 (0.0602175)
-Other time (%) = 0.267615 (29.7629)
-
-Nlocal:    32000 ave 32000 max 32000 min
-Histogram: 4 0 0 0 0 0 0 0 0 0
-Nghost:    5463 ave 5463 max 5463 min
-Histogram: 4 0 0 0 0 0 0 0 0 0
-Neighs:    115133 ave 115133 max 115133 min
-Histogram: 4 0 0 0 0 0 0 0 0 0
-
-Total # of neighbors = 460532
-Ave neighs/atom = 3.59791
-Neighbor list builds = 2
-Dangerous builds = 0
--- a/bench/log.15May15.eam.fixed.icc.1
+++ b/bench/log.15May15.eam.fixed.icc.1
@ -1,71 +0,0 @@
-LAMMPS (30 Apr 2015)
-# bulk Cu lattice
-
-variable	x index 1
-variable	y index 1
-variable	z index 1
-
-variable	xx equal 20*$x
-variable	xx equal 20*1
-variable	yy equal 20*$y
-variable	yy equal 20*1
-variable	zz equal 20*$z
-variable	zz equal 20*1
-
-units		metal
-atom_style	atomic
-
-lattice		fcc 3.615
-Lattice spacing in x,y,z = 3.615 3.615 3.615
-region		box block 0 ${xx} 0 ${yy} 0 ${zz}
-region		box block 0 20 0 ${yy} 0 ${zz}
-region		box block 0 20 0 20 0 ${zz}
-region		box block 0 20 0 20 0 20
-create_box	1 box
-Created orthogonal box = (0 0 0) to (72.3 72.3 72.3)
-  1 by 1 by 1 MPI processor grid
-create_atoms	1 box
-Created 32000 atoms
-
-pair_style	eam
-pair_coeff	1 1 Cu_u3.eam
-
-velocity	all create 1600.0 376847 loop geom
-
-neighbor	1.0 bin
-neigh_modify    every 1 delay 5 check yes
-
-fix		1 all nve
-
-timestep	0.005
-thermo		50
-
-run		100
-Neighbor list info ...
-  1 neighbor list requests
-  update every 1 steps, delay 5 steps, check yes
-  master list distance cutoff = 5.95
-Memory usage per processor = 10.2238 Mbytes
-Step Temp E_pair E_mol TotEng Press 
-       0         1600      -113280            0   -106662.09    18703.573 
-      50    781.69049   -109873.35            0   -106640.13    52273.088 
-     100      801.832    -109957.3            0   -106640.77    51322.821 
-Loop time of 5.89995 on 1 procs for 100 steps with 32000 atoms
-
-Pair  time (%) = 5.21525 (88.3948)
-Neigh time (%) = 0.579447 (9.82122)
-Comm  time (%) = 0.0302751 (0.513142)
-Outpt time (%) = 0.000234127 (0.00396829)
-Other time (%) = 0.0747423 (1.26683)
-
-Nlocal:    32000 ave 32000 max 32000 min
-Histogram: 1 0 0 0 0 0 0 0 0 0
-Nghost:    19909 ave 19909 max 19909 min
-Histogram: 1 0 0 0 0 0 0 0 0 0
-Neighs:    1.20778e+06 ave 1.20778e+06 max 1.20778e+06 min
-Histogram: 1 0 0 0 0 0 0 0 0 0
-
-Total # of neighbors = 1207784
-Ave neighs/atom = 37.7433
-Neighbor list builds = 13
-Dangerous builds = 0
--- a/bench/log.15May15.eam.fixed.icc.4
+++ b/bench/log.15May15.eam.fixed.icc.4
@ -1,71 +0,0 @@
-LAMMPS (30 Apr 2015)
-# bulk Cu lattice
-
-variable	x index 1
-variable	y index 1
-variable	z index 1
-
-variable	xx equal 20*$x
-variable	xx equal 20*1
-variable	yy equal 20*$y
-variable	yy equal 20*1
-variable	zz equal 20*$z
-variable	zz equal 20*1
-
-units		metal
-atom_style	atomic
-
-lattice		fcc 3.615
-Lattice spacing in x,y,z = 3.615 3.615 3.615
-region		box block 0 ${xx} 0 ${yy} 0 ${zz}
-region		box block 0 20 0 ${yy} 0 ${zz}
-region		box block 0 20 0 20 0 ${zz}
-region		box block 0 20 0 20 0 20
-create_box	1 box
-Created orthogonal box = (0 0 0) to (72.3 72.3 72.3)
-  1 by 2 by 2 MPI processor grid
-create_atoms	1 box
-Created 32000 atoms
-
-pair_style	eam
-pair_coeff	1 1 Cu_u3.eam
-
-velocity	all create 1600.0 376847 loop geom
-
-neighbor	1.0 bin
-neigh_modify    every 1 delay 5 check yes
-
-fix		1 all nve
-
-timestep	0.005
-thermo		50
-
-run		100
-Neighbor list info ...
-  1 neighbor list requests
-  update every 1 steps, delay 5 steps, check yes
-  master list distance cutoff = 5.95
-Memory usage per processor = 5.09629 Mbytes
-Step Temp E_pair E_mol TotEng Press 
-       0         1600      -113280            0   -106662.09    18703.573 
-      50    781.69049   -109873.35            0   -106640.13    52273.088 
-     100      801.832    -109957.3            0   -106640.77    51322.821 
-Loop time of 1.57597 on 4 procs for 100 steps with 32000 atoms
-
-Pair  time (%) = 1.36786 (86.7953)
-Neigh time (%) = 0.152391 (9.6697)
-Comm  time (%) = 0.0353726 (2.2445)
-Outpt time (%) = 0.000111699 (0.00708766)
-Other time (%) = 0.0202255 (1.28337)
-
-Nlocal:    8000 ave 8008 max 7993 min
-Histogram: 2 0 0 0 0 0 0 0 1 1
-Nghost:    9130.25 ave 9138 max 9122 min
-Histogram: 2 0 0 0 0 0 0 0 0 2
-Neighs:    301946 ave 302392 max 301360 min
-Histogram: 1 0 0 0 1 0 0 0 1 1
-
-Total # of neighbors = 1207784
-Ave neighs/atom = 37.7433
-Neighbor list builds = 13
-Dangerous builds = 0
--- a/bench/log.15May15.eam.scaled.icc.4
+++ b/bench/log.15May15.eam.scaled.icc.4
@ -1,71 +0,0 @@
-LAMMPS (30 Apr 2015)
-# bulk Cu lattice
-
-variable	x index 1
-variable	y index 1
-variable	z index 1
-
-variable	xx equal 20*$x
-variable	xx equal 20*2
-variable	yy equal 20*$y
-variable	yy equal 20*2
-variable	zz equal 20*$z
-variable	zz equal 20*1
-
-units		metal
-atom_style	atomic
-
-lattice		fcc 3.615
-Lattice spacing in x,y,z = 3.615 3.615 3.615
-region		box block 0 ${xx} 0 ${yy} 0 ${zz}
-region		box block 0 40 0 ${yy} 0 ${zz}
-region		box block 0 40 0 40 0 ${zz}
-region		box block 0 40 0 40 0 20
-create_box	1 box
-Created orthogonal box = (0 0 0) to (144.6 144.6 72.3)
-  2 by 2 by 1 MPI processor grid
-create_atoms	1 box
-Created 128000 atoms
-
-pair_style	eam
-pair_coeff	1 1 Cu_u3.eam
-
-velocity	all create 1600.0 376847 loop geom
-
-neighbor	1.0 bin
-neigh_modify    every 1 delay 5 check yes
-
-fix		1 all nve
-
-timestep	0.005
-thermo		50
-
-run		100
-Neighbor list info ...
-  1 neighbor list requests
-  update every 1 steps, delay 5 steps, check yes
-  master list distance cutoff = 5.95
-Memory usage per processor = 10.1402 Mbytes
-Step Temp E_pair E_mol TotEng Press 
-       0         1600      -453120            0   -426647.73    18704.012 
-      50    779.50001   -439457.02            0   -426560.06    52355.276 
-     100    797.97828   -439764.76            0   -426562.07     51474.74 
-Loop time of 6.4972 on 4 procs for 100 steps with 128000 atoms
-
-Pair  time (%) = 5.61297 (86.3906)
-Neigh time (%) = 0.655333 (10.0864)
-Comm  time (%) = 0.130434 (2.00755)
-Outpt time (%) = 0.000279069 (0.00429522)
-Other time (%) = 0.0981811 (1.51113)
-
-Nlocal:    32000 ave 32092 max 31914 min
-Histogram: 1 0 0 1 0 1 0 0 0 1
-Nghost:    19910 ave 19997 max 19818 min
-Histogram: 1 0 0 0 1 0 1 0 0 1
-Neighs:    1.20728e+06 ave 1.21142e+06 max 1.2036e+06 min
-Histogram: 1 0 0 1 1 0 0 0 0 1
-
-Total # of neighbors = 4829126
-Ave neighs/atom = 37.7275
-Neighbor list builds = 14
-Dangerous builds = 0
--- a/bench/log.15May15.lj.fixed.icc.1
+++ b/bench/log.15May15.lj.fixed.icc.1
@ -1,68 +0,0 @@
-LAMMPS (30 Apr 2015)
-# 3d Lennard-Jones melt
-
-variable	x index 1
-variable	y index 1
-variable	z index 1
-
-variable	xx equal 20*$x
-variable	xx equal 20*1
-variable	yy equal 20*$y
-variable	yy equal 20*1
-variable	zz equal 20*$z
-variable	zz equal 20*1
-
-units		lj
-atom_style	atomic
-
-lattice		fcc 0.8442
-Lattice spacing in x,y,z = 1.6796 1.6796 1.6796
-region		box block 0 ${xx} 0 ${yy} 0 ${zz}
-region		box block 0 20 0 ${yy} 0 ${zz}
-region		box block 0 20 0 20 0 ${zz}
-region		box block 0 20 0 20 0 20
-create_box	1 box
-Created orthogonal box = (0 0 0) to (33.5919 33.5919 33.5919)
-  1 by 1 by 1 MPI processor grid
-create_atoms	1 box
-Created 32000 atoms
-mass		1 1.0
-
-velocity	all create 1.44 87287 loop geom
-
-pair_style	lj/cut 2.5
-pair_coeff	1 1 1.0 1.0 2.5
-
-neighbor	0.3 bin
-neigh_modify	delay 0 every 20 check no
-
-fix		1 all nve
-
-run		100
-Neighbor list info ...
-  1 neighbor list requests
-  update every 20 steps, delay 0 steps, check no
-  master list distance cutoff = 2.8
-Memory usage per processor = 8.21387 Mbytes
-Step Temp E_pair E_mol TotEng Press 
-       0         1.44   -6.7733681            0   -4.6134356   -5.0197073 
-     100    0.7574531   -5.7585055            0   -4.6223613   0.20726105 
-Loop time of 2.25588 on 1 procs for 100 steps with 32000 atoms
-
-Pair  time (%) = 1.93512 (85.7815)
-Neigh time (%) = 0.236483 (10.483)
-Comm  time (%) = 0.0239627 (1.06224)
-Outpt time (%) = 0.000118017 (0.00523155)
-Other time (%) = 0.0601869 (2.66801)
-
-Nlocal:    32000 ave 32000 max 32000 min
-Histogram: 1 0 0 0 0 0 0 0 0 0
-Nghost:    19657 ave 19657 max 19657 min
-Histogram: 1 0 0 0 0 0 0 0 0 0
-Neighs:    1.20283e+06 ave 1.20283e+06 max 1.20283e+06 min
-Histogram: 1 0 0 0 0 0 0 0 0 0
-
-Total # of neighbors = 1202833
-Ave neighs/atom = 37.5885
-Neighbor list builds = 5
-Dangerous builds = 0
--- a/bench/log.15May15.lj.fixed.icc.4
+++ b/bench/log.15May15.lj.fixed.icc.4
@ -1,68 +0,0 @@
-LAMMPS (30 Apr 2015)
-# 3d Lennard-Jones melt
-
-variable	x index 1
-variable	y index 1
-variable	z index 1
-
-variable	xx equal 20*$x
-variable	xx equal 20*1
-variable	yy equal 20*$y
-variable	yy equal 20*1
-variable	zz equal 20*$z
-variable	zz equal 20*1
-
-units		lj
-atom_style	atomic
-
-lattice		fcc 0.8442
-Lattice spacing in x,y,z = 1.6796 1.6796 1.6796
-region		box block 0 ${xx} 0 ${yy} 0 ${zz}
-region		box block 0 20 0 ${yy} 0 ${zz}
-region		box block 0 20 0 20 0 ${zz}
-region		box block 0 20 0 20 0 20
-create_box	1 box
-Created orthogonal box = (0 0 0) to (33.5919 33.5919 33.5919)
-  1 by 2 by 2 MPI processor grid
-create_atoms	1 box
-Created 32000 atoms
-mass		1 1.0
-
-velocity	all create 1.44 87287 loop geom
-
-pair_style	lj/cut 2.5
-pair_coeff	1 1 1.0 1.0 2.5
-
-neighbor	0.3 bin
-neigh_modify	delay 0 every 20 check no
-
-fix		1 all nve
-
-run		100
-Neighbor list info ...
-  1 neighbor list requests
-  update every 20 steps, delay 0 steps, check no
-  master list distance cutoff = 2.8
-Memory usage per processor = 4.09506 Mbytes
-Step Temp E_pair E_mol TotEng Press 
-       0         1.44   -6.7733681            0   -4.6134356   -5.0197073 
-     100    0.7574531   -5.7585055            0   -4.6223613   0.20726105 
-Loop time of 0.623887 on 4 procs for 100 steps with 32000 atoms
-
-Pair  time (%) = 0.50691 (81.2504)
-Neigh time (%) = 0.0619052 (9.92251)
-Comm  time (%) = 0.0389298 (6.23989)
-Outpt time (%) = 5.85914e-05 (0.00939135)
-Other time (%) = 0.0160829 (2.57785)
-
-Nlocal:    8000 ave 8037 max 7964 min
-Histogram: 2 0 0 0 0 0 0 0 1 1
-Nghost:    9007.5 ave 9050 max 8968 min
-Histogram: 1 1 0 0 0 0 0 1 0 1
-Neighs:    300708 ave 305113 max 297203 min
-Histogram: 1 0 0 1 1 0 0 0 0 1
-
-Total # of neighbors = 1202833
-Ave neighs/atom = 37.5885
-Neighbor list builds = 5
-Dangerous builds = 0
--- a/bench/log.15May15.lj.scaled.icc.4
+++ b/bench/log.15May15.lj.scaled.icc.4
@ -1,68 +0,0 @@
-LAMMPS (30 Apr 2015)
-# 3d Lennard-Jones melt
-
-variable	x index 1
-variable	y index 1
-variable	z index 1
-
-variable	xx equal 20*$x
-variable	xx equal 20*2
-variable	yy equal 20*$y
-variable	yy equal 20*2
-variable	zz equal 20*$z
-variable	zz equal 20*1
-
-units		lj
-atom_style	atomic
-
-lattice		fcc 0.8442
-Lattice spacing in x,y,z = 1.6796 1.6796 1.6796
-region		box block 0 ${xx} 0 ${yy} 0 ${zz}
-region		box block 0 40 0 ${yy} 0 ${zz}
-region		box block 0 40 0 40 0 ${zz}
-region		box block 0 40 0 40 0 20
-create_box	1 box
-Created orthogonal box = (0 0 0) to (67.1838 67.1838 33.5919)
-  2 by 2 by 1 MPI processor grid
-create_atoms	1 box
-Created 128000 atoms
-mass		1 1.0
-
-velocity	all create 1.44 87287 loop geom
-
-pair_style	lj/cut 2.5
-pair_coeff	1 1 1.0 1.0 2.5
-
-neighbor	0.3 bin
-neigh_modify	delay 0 every 20 check no
-
-fix		1 all nve
-
-run		100
-Neighbor list info ...
-  1 neighbor list requests
-  update every 20 steps, delay 0 steps, check no
-  master list distance cutoff = 2.8
-Memory usage per processor = 8.13678 Mbytes
-Step Temp E_pair E_mol TotEng Press 
-       0         1.44   -6.7733681            0   -4.6133849   -5.0196788 
-     100   0.75841891    -5.759957            0   -4.6223375   0.20008866 
-Loop time of 2.53011 on 4 procs for 100 steps with 128000 atoms
-
-Pair  time (%) = 2.09024 (82.6146)
-Neigh time (%) = 0.24414 (9.64939)
-Comm  time (%) = 0.111739 (4.41638)
-Outpt time (%) = 0.000135601 (0.00535947)
-Other time (%) = 0.0838551 (3.31428)
-
-Nlocal:    32000 ave 32060 max 31939 min
-Histogram: 1 0 1 0 0 0 0 1 0 1
-Nghost:    19630.8 ave 19681 max 19562 min
-Histogram: 1 0 0 0 1 0 0 0 1 1
-Neighs:    1.20195e+06 ave 1.20354e+06 max 1.19931e+06 min
-Histogram: 1 0 0 0 0 0 0 2 0 1
-
-Total # of neighbors = 4807797
-Ave neighs/atom = 37.5609
-Neighbor list builds = 5
-Dangerous builds = 0
--- a/bench/log.15May15.rhodo.fixed.icc.1
+++ b/bench/log.15May15.rhodo.fixed.icc.1
@ -1,110 +0,0 @@
-LAMMPS (30 Apr 2015)
-# Rhodopsin model
-
-units           real
-neigh_modify    delay 5 every 1
-
-atom_style      full
-bond_style      harmonic
-angle_style     charmm
-dihedral_style  charmm
-improper_style  harmonic
-pair_style      lj/charmm/coul/long 8.0 10.0
-pair_modify     mix arithmetic
-kspace_style    pppm 1e-4
-
-read_data       data.rhodo
-  orthogonal box = (-27.5 -38.5 -36.3646) to (27.5 38.5 36.3615)
-  1 by 1 by 1 MPI processor grid
-  reading atoms ...
-  32000 atoms
-  reading velocities ...
-  32000 velocities
-  scanning bonds ...
-  4 = max bonds/atom
-  scanning angles ...
-  8 = max angles/atom
-  scanning dihedrals ...
-  18 = max dihedrals/atom
-  scanning impropers ...
-  2 = max impropers/atom
-  reading bonds ...
-  27723 bonds
-  reading angles ...
-  40467 angles
-  reading dihedrals ...
-  56829 dihedrals
-  reading impropers ...
-  1034 impropers
-  4 = max # of 1-2 neighbors
-  12 = max # of 1-3 neighbors
-  24 = max # of 1-4 neighbors
-  26 = max # of special neighbors
-
-fix             1 all shake 0.0001 5 0 m 1.0 a 232
-  1617 = # of size 2 clusters
-  3633 = # of size 3 clusters
-  747 = # of size 4 clusters
-  4233 = # of frozen angles
-fix             2 all npt temp 300.0 300.0 100.0 		z 0.0 0.0 1000.0 mtk no pchain 0 tchain 1
-
-special_bonds   charmm
-
-thermo          50
-thermo_style    multi
-timestep        2.0
-
-run		100
-PPPM initialization ...
-  G vector (1/distance) = 0.248835
-  grid = 25 32 32
-  stencil order = 5
-  estimated absolute RMS force accuracy = 0.0355478
-  estimated relative force accuracy = 0.000107051
-  using double precision FFTs
-  3d grid and FFT values/proc = 41070 25600
-Neighbor list info ...
-  1 neighbor list requests
-  update every 1 steps, delay 5 steps, check yes
-  master list distance cutoff = 12
-Memory usage per processor = 91.7487 Mbytes
---------------- Step        0 ----- CPU =      0.0000 (sec) ----------------
-TotEng   =    -25356.2064 KinEng   =     21444.8313 Temp     =       299.0397 
-PotEng   =    -46801.0377 E_bond   =      2537.9940 E_angle  =     10921.3742 
-E_dihed  =      5211.7865 E_impro  =       213.5116 E_vdwl   =     -2307.8634 
-E_coul   =    207025.8927 E_long   =   -270403.7333 Press    =      -142.6035 
-Volume   =    307995.0335 
---------------- Step       50 ----- CPU =     17.3751 (sec) ----------------
-TotEng   =    -25330.0828 KinEng   =     21501.0029 Temp     =       299.8230 
-PotEng   =    -46831.0857 E_bond   =      2471.7004 E_angle  =     10836.4975 
-E_dihed  =      5239.6299 E_impro  =       227.1218 E_vdwl   =     -1993.2754 
-E_coul   =    206797.6331 E_long   =   -270410.3930 Press    =       237.6701 
-Volume   =    308031.5639 
---------------- Step      100 ----- CPU =     35.3771 (sec) ----------------
-TotEng   =    -25290.7593 KinEng   =     21592.0117 Temp     =       301.0920 
-PotEng   =    -46882.7709 E_bond   =      2567.9807 E_angle  =     10781.9408 
-E_dihed  =      5198.7432 E_impro  =       216.7834 E_vdwl   =     -1902.4783 
-E_coul   =    206659.2326 E_long   =   -270404.9733 Press    =         6.9960 
-Volume   =    308133.9888 
-Loop time of 35.3771 on 1 procs for 100 steps with 32000 atoms
-
-Pair  time (%) = 25.4765 (72.0139)
-Bond  time (%) = 1.27905 (3.61547)
-Kspce time (%) = 3.22381 (9.11269)
-Neigh time (%) = 4.26655 (12.0602)
-Comm  time (%) = 0.0692198 (0.195663)
-Outpt time (%) = 0.000253916 (0.00071774)
-Other time (%) = 1.06179 (3.00134)
-
-Nlocal:    32000 ave 32000 max 32000 min
-Histogram: 1 0 0 0 0 0 0 0 0 0
-Nghost:    47958 ave 47958 max 47958 min
-Histogram: 1 0 0 0 0 0 0 0 0 0
-Neighs:    1.20281e+07 ave 1.20281e+07 max 1.20281e+07 min
-Histogram: 1 0 0 0 0 0 0 0 0 0
-
-Total # of neighbors = 12028107
-Ave neighs/atom = 375.878
-Ave special neighs/atom = 7.43187
-Neighbor list builds = 11
-Dangerous builds = 0
--- a/bench/log.15May15.rhodo.fixed.icc.4
+++ b/bench/log.15May15.rhodo.fixed.icc.4
@ -1,110 +0,0 @@
-LAMMPS (30 Apr 2015)
-# Rhodopsin model
-
-units           real
-neigh_modify    delay 5 every 1
-
-atom_style      full
-bond_style      harmonic
-angle_style     charmm
-dihedral_style  charmm
-improper_style  harmonic
-pair_style      lj/charmm/coul/long 8.0 10.0
-pair_modify     mix arithmetic
-kspace_style    pppm 1e-4
-
-read_data       data.rhodo
-  orthogonal box = (-27.5 -38.5 -36.3646) to (27.5 38.5 36.3615)
-  1 by 2 by 2 MPI processor grid
-  reading atoms ...
-  32000 atoms
-  reading velocities ...
-  32000 velocities
-  scanning bonds ...
-  4 = max bonds/atom
-  scanning angles ...
-  8 = max angles/atom
-  scanning dihedrals ...
-  18 = max dihedrals/atom
-  scanning impropers ...
-  2 = max impropers/atom
-  reading bonds ...
-  27723 bonds
-  reading angles ...
-  40467 angles
-  reading dihedrals ...
-  56829 dihedrals
-  reading impropers ...
-  1034 impropers
-  4 = max # of 1-2 neighbors
-  12 = max # of 1-3 neighbors
-  24 = max # of 1-4 neighbors
-  26 = max # of special neighbors
-
-fix             1 all shake 0.0001 5 0 m 1.0 a 232
-  1617 = # of size 2 clusters
-  3633 = # of size 3 clusters
-  747 = # of size 4 clusters
-  4233 = # of frozen angles
-fix             2 all npt temp 300.0 300.0 100.0 		z 0.0 0.0 1000.0 mtk no pchain 0 tchain 1
-
-special_bonds   charmm
-
-thermo          50
-thermo_style    multi
-timestep        2.0
-
-run		100
-PPPM initialization ...
-  G vector (1/distance) = 0.248835
-  grid = 25 32 32
-  stencil order = 5
-  estimated absolute RMS force accuracy = 0.0355478
-  estimated relative force accuracy = 0.000107051
-  using double precision FFTs
-  3d grid and FFT values/proc = 13230 6400
-Neighbor list info ...
-  1 neighbor list requests
-  update every 1 steps, delay 5 steps, check yes
-  master list distance cutoff = 12
-Memory usage per processor = 36.629 Mbytes
---------------- Step        0 ----- CPU =      0.0000 (sec) ----------------
-TotEng   =    -25356.2064 KinEng   =     21444.8313 Temp     =       299.0397 
-PotEng   =    -46801.0377 E_bond   =      2537.9940 E_angle  =     10921.3742 
-E_dihed  =      5211.7865 E_impro  =       213.5116 E_vdwl   =     -2307.8634 
-E_coul   =    207025.8927 E_long   =   -270403.7333 Press    =      -142.6035 
-Volume   =    307995.0335 
---------------- Step       50 ----- CPU =      4.6438 (sec) ----------------
-TotEng   =    -25330.0828 KinEng   =     21501.0029 Temp     =       299.8230 
-PotEng   =    -46831.0857 E_bond   =      2471.7004 E_angle  =     10836.4975 
-E_dihed  =      5239.6299 E_impro  =       227.1218 E_vdwl   =     -1993.2754 
-E_coul   =    206797.6331 E_long   =   -270410.3930 Press    =       237.6701 
-Volume   =    308031.5639 
---------------- Step      100 ----- CPU =      9.4301 (sec) ----------------
-TotEng   =    -25290.7591 KinEng   =     21592.0117 Temp     =       301.0920 
-PotEng   =    -46882.7708 E_bond   =      2567.9807 E_angle  =     10781.9408 
-E_dihed  =      5198.7432 E_impro  =       216.7834 E_vdwl   =     -1902.4783 
-E_coul   =    206659.2327 E_long   =   -270404.9733 Press    =         6.9960 
-Volume   =    308133.9888 
-Loop time of 9.43015 on 4 procs for 100 steps with 32000 atoms
-
-Pair  time (%) = 6.53815 (69.3324)
-Bond  time (%) = 0.323679 (3.43239)
-Kspce time (%) = 1.02664 (10.8868)
-Neigh time (%) = 1.11839 (11.8597)
-Comm  time (%) = 0.0812459 (0.861554)
-Outpt time (%) = 0.000150442 (0.00159533)
-Other time (%) = 0.341896 (3.62557)
-
-Nlocal:    8000 ave 8143 max 7933 min
-Histogram: 1 2 0 0 0 0 0 0 0 1
-Nghost:    22733.5 ave 22769 max 22693 min
-Histogram: 1 0 0 0 0 2 0 0 0 1
-Neighs:    3.00703e+06 ave 3.0975e+06 max 2.96493e+06 min
-Histogram: 1 2 0 0 0 0 0 0 0 1
-
-Total # of neighbors = 12028107
-Ave neighs/atom = 375.878
-Ave special neighs/atom = 7.43187
-Neighbor list builds = 11
-Dangerous builds = 0
--- a/bench/log.15May15.rhodo.scaled.icc.4
+++ b/bench/log.15May15.rhodo.scaled.icc.4
@ -1,131 +0,0 @@
-LAMMPS (30 Apr 2015)
-# Rhodopsin model
-
-variable	x index 1
-variable	y index 1
-variable	z index 1
-
-units           real
-neigh_modify    delay 5 every 1
-
-atom_style      full
-atom_modify	map hash
-bond_style      harmonic
-angle_style     charmm
-dihedral_style  charmm
-improper_style  harmonic
-pair_style      lj/charmm/coul/long 8.0 10.0
-pair_modify     mix arithmetic
-kspace_style    pppm 1e-4
-
-read_data       data.rhodo
-  orthogonal box = (-27.5 -38.5 -36.3646) to (27.5 38.5 36.3615)
-  1 by 2 by 2 MPI processor grid
-  reading atoms ...
-  32000 atoms
-  reading velocities ...
-  32000 velocities
-  scanning bonds ...
-  4 = max bonds/atom
-  scanning angles ...
-  8 = max angles/atom
-  scanning dihedrals ...
-  18 = max dihedrals/atom
-  scanning impropers ...
-  2 = max impropers/atom
-  reading bonds ...
-  27723 bonds
-  reading angles ...
-  40467 angles
-  reading dihedrals ...
-  56829 dihedrals
-  reading impropers ...
-  1034 impropers
-  4 = max # of 1-2 neighbors
-  12 = max # of 1-3 neighbors
-  24 = max # of 1-4 neighbors
-  26 = max # of special neighbors
-
-replicate	$x $y $z
-replicate	2 $y $z
-replicate	2 2 $z
-replicate	2 2 1
-  orthogonal box = (-27.5 -38.5 -36.3646) to (82.5 115.5 36.3615)
-  2 by 2 by 1 MPI processor grid
-  128000 atoms
-  110892 bonds
-  161868 angles
-  227316 dihedrals
-  4136 impropers
-  4 = max # of 1-2 neighbors
-  12 = max # of 1-3 neighbors
-  24 = max # of 1-4 neighbors
-  26 = max # of special neighbors
-
-fix             1 all shake 0.0001 5 0 m 1.0 a 232
-  6468 = # of size 2 clusters
-  14532 = # of size 3 clusters
-  2988 = # of size 4 clusters
-  16932 = # of frozen angles
-fix             2 all npt temp 300.0 300.0 100.0 		z 0.0 0.0 1000.0 mtk no pchain 0 tchain 1
-
-special_bonds   charmm
-
-thermo          50
-thermo_style    multi
-timestep        2.0
-
-run		100
-PPPM initialization ...
-  G vector (1/distance) = 0.248593
-  grid = 48 60 36
-  stencil order = 5
-  estimated absolute RMS force accuracy = 0.0359793
-  estimated relative force accuracy = 0.00010835
-  using double precision FFTs
-  3d grid and FFT values/proc = 41615 25920
-Neighbor list info ...
-  1 neighbor list requests
-  update every 1 steps, delay 5 steps, check yes
-  master list distance cutoff = 12
-Memory usage per processor = 95.5339 Mbytes
---------------- Step        0 ----- CPU =      0.0000 (sec) ----------------
-TotEng   =   -101425.4887 KinEng   =     85779.3251 Temp     =       299.0304 
-PotEng   =   -187204.8138 E_bond   =     10151.9760 E_angle  =     43685.4968 
-E_dihed  =     20847.1460 E_impro  =       854.0463 E_vdwl   =     -9231.4537 
-E_coul   =    827053.5824 E_long   =  -1080565.6077 Press    =      -142.3092 
-Volume   =   1231980.1340 
---------------- Step       50 ----- CPU =     18.5923 (sec) ----------------
-TotEng   =   -101320.2677 KinEng   =     86003.4837 Temp     =       299.8118 
-PotEng   =   -187323.7514 E_bond   =      9887.1072 E_angle  =     43346.7922 
-E_dihed  =     20958.7032 E_impro  =       908.4715 E_vdwl   =     -7973.4457 
-E_coul   =    826141.3831 E_long   =  -1080592.7629 Press    =       238.0161 
-Volume   =   1232126.1855 
---------------- Step      100 ----- CPU =     38.1551 (sec) ----------------
-TotEng   =   -101158.1849 KinEng   =     86355.6149 Temp     =       301.0393 
-PotEng   =   -187513.7998 E_bond   =     10272.0693 E_angle  =     43128.6454 
-E_dihed  =     20793.9759 E_impro  =       867.0826 E_vdwl   =     -7586.7186 
-E_coul   =    825583.7122 E_long   =  -1080572.5667 Press    =        15.2151 
-Volume   =   1232535.8423 
-Loop time of 38.1551 on 4 procs for 100 steps with 128000 atoms
-
-Pair  time (%) = 26.4472 (69.3149)
-Bond  time (%) = 1.31402 (3.44388)
-Kspce time (%) = 4.23553 (11.1008)
-Neigh time (%) = 4.45503 (11.6761)
-Comm  time (%) = 0.208946 (0.547622)
-Outpt time (%) = 0.000290096 (0.000760307)
-Other time (%) = 1.49411 (3.91587)
-
-Nlocal:    32000 ave 32000 max 32000 min
-Histogram: 4 0 0 0 0 0 0 0 0 0
-Nghost:    47957 ave 47957 max 47957 min
-Histogram: 4 0 0 0 0 0 0 0 0 0
-Neighs:    1.20281e+07 ave 1.20572e+07 max 1.1999e+07 min
-Histogram: 2 0 0 0 0 0 0 0 0 2
-
-Total # of neighbors = 48112472
-Ave neighs/atom = 375.879
-Ave special neighs/atom = 7.43187
-Neighbor list builds = 11
-Dangerous builds = 0
--- a/bench/log.6Oct16.chain.fixed.icc.1
+++ b/bench/log.6Oct16.chain.fixed.icc.1
@ -0,0 +1,78 @@
+LAMMPS (6 Oct 2016)
+# FENE beadspring benchmark
+
+units		lj
+atom_style	bond
+special_bonds   fene
+
+read_data	data.chain
+  orthogonal box = (-16.796 -16.796 -16.796) to (16.796 16.796 16.796)
+  1 by 1 by 1 MPI processor grid
+  reading atoms ...
+  32000 atoms
+  reading velocities ...
+  32000 velocities
+  scanning bonds ...
+  1 = max bonds/atom
+  reading bonds ...
+  31680 bonds
+  2 = max # of 1-2 neighbors
+  2 = max # of special neighbors
+
+neighbor	0.4 bin
+neigh_modify	every 1 delay 1
+
+bond_style      fene
+bond_coeff	1 30.0 1.5 1.0 1.0
+
+pair_style	lj/cut 1.12
+pair_modify	shift yes
+pair_coeff	1 1 1.0 1.0 1.12
+
+fix		1 all nve
+fix		2 all langevin 1.0 1.0 10.0 904297
+
+thermo          100
+timestep	0.012
+
+run		100
+Neighbor list info ...
+  1 neighbor list requests
+  update every 1 steps, delay 1 steps, check yes
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 1.52
+  ghost atom cutoff = 1.52
+  binsize = 0.76 -> bins = 45 45 45
+Memory usage per processor = 12.0423 Mbytes
+Step Temp E_pair E_mol TotEng Press 
+       0   0.97029772   0.44484087    20.494523    22.394765    4.6721833 
+     100    0.9729966    0.4361122    20.507698     22.40326    4.6548819 
+Loop time of 0.977647 on 1 procs for 100 steps with 32000 atoms
+
+Performance: 106050.541 tau/day, 102.286 timesteps/s
+99.9% CPU use with 1 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 0.19421    | 0.19421    | 0.19421    |   0.0 | 19.86
+Bond    | 0.08741    | 0.08741    | 0.08741    |   0.0 |  8.94
+Neigh   | 0.45791    | 0.45791    | 0.45791    |   0.0 | 46.84
+Comm    | 0.032649   | 0.032649   | 0.032649   |   0.0 |  3.34
+Output  | 0.00012207 | 0.00012207 | 0.00012207 |   0.0 |  0.01
+Modify  | 0.18071    | 0.18071    | 0.18071    |   0.0 | 18.48
+Other   |            | 0.02464    |            |       |  2.52
+
+Nlocal:    32000 ave 32000 max 32000 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Nghost:    9493 ave 9493 max 9493 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Neighs:    155873 ave 155873 max 155873 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+
+Total # of neighbors = 155873
+Ave neighs/atom = 4.87103
+Ave special neighs/atom = 1.98
+Neighbor list builds = 25
+Dangerous builds = 0
+Total wall time: 0:00:01
--- a/bench/log.6Oct16.chain.fixed.icc.4
+++ b/bench/log.6Oct16.chain.fixed.icc.4
@ -0,0 +1,78 @@
+LAMMPS (6 Oct 2016)
+# FENE beadspring benchmark
+
+units		lj
+atom_style	bond
+special_bonds   fene
+
+read_data	data.chain
+  orthogonal box = (-16.796 -16.796 -16.796) to (16.796 16.796 16.796)
+  1 by 2 by 2 MPI processor grid
+  reading atoms ...
+  32000 atoms
+  reading velocities ...
+  32000 velocities
+  scanning bonds ...
+  1 = max bonds/atom
+  reading bonds ...
+  31680 bonds
+  2 = max # of 1-2 neighbors
+  2 = max # of special neighbors
+
+neighbor	0.4 bin
+neigh_modify	every 1 delay 1
+
+bond_style      fene
+bond_coeff	1 30.0 1.5 1.0 1.0
+
+pair_style	lj/cut 1.12
+pair_modify	shift yes
+pair_coeff	1 1 1.0 1.0 1.12
+
+fix		1 all nve
+fix		2 all langevin 1.0 1.0 10.0 904297
+
+thermo          100
+timestep	0.012
+
+run		100
+Neighbor list info ...
+  1 neighbor list requests
+  update every 1 steps, delay 1 steps, check yes
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 1.52
+  ghost atom cutoff = 1.52
+  binsize = 0.76 -> bins = 45 45 45
+Memory usage per processor = 4.14663 Mbytes
+Step Temp E_pair E_mol TotEng Press 
+       0   0.97029772   0.44484087    20.494523    22.394765    4.6721833 
+     100   0.97145835   0.43803883    20.502691    22.397872     4.626988 
+Loop time of 0.269205 on 4 procs for 100 steps with 32000 atoms
+
+Performance: 385133.446 tau/day, 371.464 timesteps/s
+99.8% CPU use with 4 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 0.049383   | 0.049756   | 0.049988   |   0.1 | 18.48
+Bond    | 0.022701   | 0.022813   | 0.022872   |   0.0 |  8.47
+Neigh   | 0.11982    | 0.12002    | 0.12018    |   0.0 | 44.58
+Comm    | 0.020274   | 0.021077   | 0.022348   |   0.5 |  7.83
+Output  | 5.3167e-05 | 5.6148e-05 | 6.3181e-05 |   0.1 |  0.02
+Modify  | 0.046276   | 0.046809   | 0.047016   |   0.1 | 17.39
+Other   |            | 0.008669   |            |       |  3.22
+
+Nlocal:    8000 ave 8030 max 7974 min
+Histogram: 1 0 0 1 0 1 0 0 0 1
+Nghost:    4177 ave 4191 max 4160 min
+Histogram: 1 0 0 0 1 0 0 1 0 1
+Neighs:    38995.8 ave 39169 max 38852 min
+Histogram: 1 0 0 1 1 0 0 0 0 1
+
+Total # of neighbors = 155983
+Ave neighs/atom = 4.87447
+Ave special neighs/atom = 1.98
+Neighbor list builds = 25
+Dangerous builds = 0
+Total wall time: 0:00:00
--- a/bench/log.6Oct16.chain.scaled.icc.4
+++ b/bench/log.6Oct16.chain.scaled.icc.4
@ -0,0 +1,94 @@
+LAMMPS (6 Oct 2016)
+# FENE beadspring benchmark
+
+variable	x index 1
+variable	y index 1
+variable	z index 1
+
+units		lj
+atom_style	bond
+atom_modify	map hash
+special_bonds   fene
+
+read_data	data.chain
+  orthogonal box = (-16.796 -16.796 -16.796) to (16.796 16.796 16.796)
+  1 by 2 by 2 MPI processor grid
+  reading atoms ...
+  32000 atoms
+  reading velocities ...
+  32000 velocities
+  scanning bonds ...
+  1 = max bonds/atom
+  reading bonds ...
+  31680 bonds
+  2 = max # of 1-2 neighbors
+  2 = max # of special neighbors
+
+replicate	$x $y $z
+replicate	2 $y $z
+replicate	2 2 $z
+replicate	2 2 1
+  orthogonal box = (-16.796 -16.796 -16.796) to (50.388 50.388 16.796)
+  2 by 2 by 1 MPI processor grid
+  128000 atoms
+  126720 bonds
+  2 = max # of 1-2 neighbors
+  2 = max # of special neighbors
+
+neighbor	0.4 bin
+neigh_modify	every 1 delay 1
+
+bond_style      fene
+bond_coeff	1 30.0 1.5 1.0 1.0
+
+pair_style	lj/cut 1.12
+pair_modify	shift yes
+pair_coeff	1 1 1.0 1.0 1.12
+
+fix		1 all nve
+fix		2 all langevin 1.0 1.0 10.0 904297
+
+thermo          100
+timestep	0.012
+
+run		100
+Neighbor list info ...
+  1 neighbor list requests
+  update every 1 steps, delay 1 steps, check yes
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 1.52
+  ghost atom cutoff = 1.52
+  binsize = 0.76 -> bins = 89 89 45
+Memory usage per processor = 13.2993 Mbytes
+Step Temp E_pair E_mol TotEng Press 
+       0   0.97027498   0.44484087    20.494523    22.394765    4.6721833 
+     100   0.97682955   0.44239968    20.500229    22.407862    4.6527025 
+Loop time of 1.14845 on 4 procs for 100 steps with 128000 atoms
+
+Performance: 90277.919 tau/day, 87.074 timesteps/s
+99.9% CPU use with 4 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 0.2203     | 0.22207    | 0.22386    |   0.3 | 19.34
+Bond    | 0.094861   | 0.095302   | 0.095988   |   0.1 |  8.30
+Neigh   | 0.52127    | 0.5216     | 0.52189    |   0.0 | 45.42
+Comm    | 0.079585   | 0.082159   | 0.084366   |   0.7 |  7.15
+Output  | 0.00013304 | 0.00015306 | 0.00018501 |   0.2 |  0.01
+Modify  | 0.18351    | 0.18419    | 0.1856     |   0.2 | 16.04
+Other   |            | 0.04298    |            |       |  3.74
+
+Nlocal:    32000 ave 32015 max 31983 min
+Histogram: 1 0 1 0 0 0 0 0 1 1
+Nghost:    9492 ave 9522 max 9432 min
+Histogram: 1 0 0 0 0 0 1 0 0 2
+Neighs:    155837 ave 156079 max 155506 min
+Histogram: 1 0 0 0 0 1 0 0 1 1
+
+Total # of neighbors = 623349
+Ave neighs/atom = 4.86991
+Ave special neighs/atom = 1.98
+Neighbor list builds = 25
+Dangerous builds = 0
+Total wall time: 0:00:01
--- a/bench/log.6Oct16.chute.fixed.icc.1
+++ b/bench/log.6Oct16.chute.fixed.icc.1
@ -0,0 +1,80 @@
+LAMMPS (6 Oct 2016)
+# LAMMPS benchmark of granular flow
+# chute flow of 32000 atoms with frozen base at 26 degrees
+
+units		lj
+atom_style	sphere
+boundary	p p fs
+newton		off
+comm_modify	vel yes
+
+read_data	data.chute
+  orthogonal box = (0 0 0) to (40 20 37.2886)
+  1 by 1 by 1 MPI processor grid
+  reading atoms ...
+  32000 atoms
+  reading velocities ...
+  32000 velocities
+
+pair_style	gran/hooke/history 200000.0 NULL 50.0 NULL 0.5 0
+pair_coeff	* *
+
+neighbor	0.1 bin
+neigh_modify	every 1 delay 0
+
+timestep	0.0001
+
+group		bottom type 2
+912 atoms in group bottom
+group		active subtract all bottom
+31088 atoms in group active
+neigh_modify	exclude group bottom bottom
+
+fix		1 all gravity 1.0 chute 26.0
+fix		2 bottom freeze
+fix		3 active nve/sphere
+
+compute		1 all erotate/sphere
+thermo_style	custom step atoms ke c_1 vol
+thermo_modify	norm no
+thermo		100
+
+run		100
+Neighbor list info ...
+  2 neighbor list requests
+  update every 1 steps, delay 0 steps, check yes
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 1.1
+  ghost atom cutoff = 1.1
+  binsize = 0.55 -> bins = 73 37 68
+Memory usage per processor = 16.0904 Mbytes
+Step Atoms KinEng c_1 Volume 
+       0    32000    784139.13    1601.1263    29833.783 
+     100    32000    784292.08    1571.0968    29834.707 
+Loop time of 0.534174 on 1 procs for 100 steps with 32000 atoms
+
+Performance: 1617.451 tau/day, 187.205 timesteps/s
+99.8% CPU use with 1 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 0.33346    | 0.33346    | 0.33346    |   0.0 | 62.43
+Neigh   | 0.043902   | 0.043902   | 0.043902   |   0.0 |  8.22
+Comm    | 0.018391   | 0.018391   | 0.018391   |   0.0 |  3.44
+Output  | 0.00022411 | 0.00022411 | 0.00022411 |   0.0 |  0.04
+Modify  | 0.11666    | 0.11666    | 0.11666    |   0.0 | 21.84
+Other   |            | 0.02153    |            |       |  4.03
+
+Nlocal:    32000 ave 32000 max 32000 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Nghost:    5463 ave 5463 max 5463 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Neighs:    115133 ave 115133 max 115133 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+
+Total # of neighbors = 115133
+Ave neighs/atom = 3.59791
+Neighbor list builds = 2
+Dangerous builds = 0
+Total wall time: 0:00:00
--- a/bench/log.6Oct16.chute.fixed.icc.4
+++ b/bench/log.6Oct16.chute.fixed.icc.4
@ -0,0 +1,80 @@
+LAMMPS (6 Oct 2016)
+# LAMMPS benchmark of granular flow
+# chute flow of 32000 atoms with frozen base at 26 degrees
+
+units		lj
+atom_style	sphere
+boundary	p p fs
+newton		off
+comm_modify	vel yes
+
+read_data	data.chute
+  orthogonal box = (0 0 0) to (40 20 37.2886)
+  2 by 1 by 2 MPI processor grid
+  reading atoms ...
+  32000 atoms
+  reading velocities ...
+  32000 velocities
+
+pair_style	gran/hooke/history 200000.0 NULL 50.0 NULL 0.5 0
+pair_coeff	* *
+
+neighbor	0.1 bin
+neigh_modify	every 1 delay 0
+
+timestep	0.0001
+
+group		bottom type 2
+912 atoms in group bottom
+group		active subtract all bottom
+31088 atoms in group active
+neigh_modify	exclude group bottom bottom
+
+fix		1 all gravity 1.0 chute 26.0
+fix		2 bottom freeze
+fix		3 active nve/sphere
+
+compute		1 all erotate/sphere
+thermo_style	custom step atoms ke c_1 vol
+thermo_modify	norm no
+thermo		100
+
+run		100
+Neighbor list info ...
+  2 neighbor list requests
+  update every 1 steps, delay 0 steps, check yes
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 1.1
+  ghost atom cutoff = 1.1
+  binsize = 0.55 -> bins = 73 37 68
+Memory usage per processor = 7.04927 Mbytes
+Step Atoms KinEng c_1 Volume 
+       0    32000    784139.13    1601.1263    29833.783 
+     100    32000    784292.08    1571.0968    29834.707 
+Loop time of 0.171815 on 4 procs for 100 steps with 32000 atoms
+
+Performance: 5028.653 tau/day, 582.020 timesteps/s
+99.7% CPU use with 4 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 0.093691   | 0.096898   | 0.10005    |   0.8 | 56.40
+Neigh   | 0.011976   | 0.012059   | 0.012146   |   0.1 |  7.02
+Comm    | 0.016384   | 0.017418   | 0.018465   |   0.8 | 10.14
+Output  | 7.7963e-05 | 0.00010747 | 0.00013304 |   0.2 |  0.06
+Modify  | 0.031744   | 0.031943   | 0.032167   |   0.1 | 18.59
+Other   |            | 0.01339    |            |       |  7.79
+
+Nlocal:    8000 ave 8008 max 7992 min
+Histogram: 2 0 0 0 0 0 0 0 0 2
+Nghost:    2439 ave 2450 max 2428 min
+Histogram: 2 0 0 0 0 0 0 0 0 2
+Neighs:    29500.5 ave 30488 max 28513 min
+Histogram: 2 0 0 0 0 0 0 0 0 2
+
+Total # of neighbors = 118002
+Ave neighs/atom = 3.68756
+Neighbor list builds = 2
+Dangerous builds = 0
+Total wall time: 0:00:00
--- a/bench/log.6Oct16.chute.scaled.icc.4
+++ b/bench/log.6Oct16.chute.scaled.icc.4
@ -0,0 +1,90 @@
+LAMMPS (6 Oct 2016)
+# LAMMPS benchmark of granular flow
+# chute flow of 32000 atoms with frozen base at 26 degrees
+
+variable	x index 1
+variable	y index 1
+
+units		lj
+atom_style	sphere
+boundary	p p fs
+newton		off
+comm_modify	vel yes
+
+read_data	data.chute
+  orthogonal box = (0 0 0) to (40 20 37.2886)
+  2 by 1 by 2 MPI processor grid
+  reading atoms ...
+  32000 atoms
+  reading velocities ...
+  32000 velocities
+
+replicate	$x $y 1
+replicate	2 $y 1
+replicate	2 2 1
+  orthogonal box = (0 0 0) to (80 40 37.2922)
+  2 by 2 by 1 MPI processor grid
+  128000 atoms
+
+pair_style	gran/hooke/history 200000.0 NULL 50.0 NULL 0.5 0
+pair_coeff	* *
+
+neighbor	0.1 bin
+neigh_modify	every 1 delay 0
+
+timestep	0.0001
+
+group		bottom type 2
+3648 atoms in group bottom
+group		active subtract all bottom
+124352 atoms in group active
+neigh_modify	exclude group bottom bottom
+
+fix		1 all gravity 1.0 chute 26.0
+fix		2 bottom freeze
+fix		3 active nve/sphere
+
+compute		1 all erotate/sphere
+thermo_style	custom step atoms ke c_1 vol
+thermo_modify	norm no
+thermo		100
+
+run		100
+Neighbor list info ...
+  2 neighbor list requests
+  update every 1 steps, delay 0 steps, check yes
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 1.1
+  ghost atom cutoff = 1.1
+  binsize = 0.55 -> bins = 146 73 68
+Memory usage per processor = 16.1265 Mbytes
+Step Atoms KinEng c_1 Volume 
+       0   128000    3136556.5    6404.5051    119335.13 
+     100   128000    3137168.3    6284.3873    119338.83 
+Loop time of 0.832365 on 4 procs for 100 steps with 128000 atoms
+
+Performance: 1038.006 tau/day, 120.140 timesteps/s
+99.8% CPU use with 4 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 0.5178     | 0.52208    | 0.52793    |   0.5 | 62.72
+Neigh   | 0.047003   | 0.047113   | 0.047224   |   0.0 |  5.66
+Comm    | 0.05233    | 0.052988   | 0.053722   |   0.2 |  6.37
+Output  | 0.00024986 | 0.00032717 | 0.00036693 |   0.3 |  0.04
+Modify  | 0.15517    | 0.15627    | 0.15808    |   0.3 | 18.77
+Other   |            | 0.0536     |            |       |  6.44
+
+Nlocal:    32000 ave 32000 max 32000 min
+Histogram: 4 0 0 0 0 0 0 0 0 0
+Nghost:    5463 ave 5463 max 5463 min
+Histogram: 4 0 0 0 0 0 0 0 0 0
+Neighs:    115133 ave 115133 max 115133 min
+Histogram: 4 0 0 0 0 0 0 0 0 0
+
+Total # of neighbors = 460532
+Ave neighs/atom = 3.59791
+Neighbor list builds = 2
+Dangerous builds = 0
+Total wall time: 0:00:00
--- a/bench/log.6Oct16.eam.fixed.icc.1
+++ b/bench/log.6Oct16.eam.fixed.icc.1
@ -0,0 +1,83 @@
+LAMMPS (6 Oct 2016)
+# bulk Cu lattice
+
+variable	x index 1
+variable	y index 1
+variable	z index 1
+
+variable	xx equal 20*$x
+variable	xx equal 20*1
+variable	yy equal 20*$y
+variable	yy equal 20*1
+variable	zz equal 20*$z
+variable	zz equal 20*1
+
+units		metal
+atom_style	atomic
+
+lattice		fcc 3.615
+Lattice spacing in x,y,z = 3.615 3.615 3.615
+region		box block 0 ${xx} 0 ${yy} 0 ${zz}
+region		box block 0 20 0 ${yy} 0 ${zz}
+region		box block 0 20 0 20 0 ${zz}
+region		box block 0 20 0 20 0 20
+create_box	1 box
+Created orthogonal box = (0 0 0) to (72.3 72.3 72.3)
+  1 by 1 by 1 MPI processor grid
+create_atoms	1 box
+Created 32000 atoms
+
+pair_style	eam
+pair_coeff	1 1 Cu_u3.eam
+Reading potential file Cu_u3.eam with DATE: 2007-06-11
+
+velocity	all create 1600.0 376847 loop geom
+
+neighbor	1.0 bin
+neigh_modify    every 1 delay 5 check yes
+
+fix		1 all nve
+
+timestep	0.005
+thermo		50
+
+run		100
+Neighbor list info ...
+  1 neighbor list requests
+  update every 1 steps, delay 5 steps, check yes
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 5.95
+  ghost atom cutoff = 5.95
+  binsize = 2.975 -> bins = 25 25 25
+Memory usage per processor = 11.2238 Mbytes
+Step Temp E_pair E_mol TotEng Press 
+       0         1600      -113280            0   -106662.09    18703.573 
+      50    781.69049   -109873.35            0   -106640.13    52273.088 
+     100      801.832    -109957.3            0   -106640.77    51322.821 
+Loop time of 5.96529 on 1 procs for 100 steps with 32000 atoms
+
+Performance: 7.242 ns/day, 3.314 hours/ns, 16.764 timesteps/s
+99.9% CPU use with 1 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 5.2743     | 5.2743     | 5.2743     |   0.0 | 88.42
+Neigh   | 0.59212    | 0.59212    | 0.59212    |   0.0 |  9.93
+Comm    | 0.030399   | 0.030399   | 0.030399   |   0.0 |  0.51
+Output  | 0.00026202 | 0.00026202 | 0.00026202 |   0.0 |  0.00
+Modify  | 0.050487   | 0.050487   | 0.050487   |   0.0 |  0.85
+Other   |            | 0.01776    |            |       |  0.30
+
+Nlocal:    32000 ave 32000 max 32000 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Nghost:    19909 ave 19909 max 19909 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Neighs:    1.20778e+06 ave 1.20778e+06 max 1.20778e+06 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+
+Total # of neighbors = 1207784
+Ave neighs/atom = 37.7433
+Neighbor list builds = 13
+Dangerous builds = 0
+Total wall time: 0:00:06
--- a/bench/log.6Oct16.eam.fixed.icc.4
+++ b/bench/log.6Oct16.eam.fixed.icc.4
@ -0,0 +1,83 @@
+LAMMPS (6 Oct 2016)
+# bulk Cu lattice
+
+variable	x index 1
+variable	y index 1
+variable	z index 1
+
+variable	xx equal 20*$x
+variable	xx equal 20*1
+variable	yy equal 20*$y
+variable	yy equal 20*1
+variable	zz equal 20*$z
+variable	zz equal 20*1
+
+units		metal
+atom_style	atomic
+
+lattice		fcc 3.615
+Lattice spacing in x,y,z = 3.615 3.615 3.615
+region		box block 0 ${xx} 0 ${yy} 0 ${zz}
+region		box block 0 20 0 ${yy} 0 ${zz}
+region		box block 0 20 0 20 0 ${zz}
+region		box block 0 20 0 20 0 20
+create_box	1 box
+Created orthogonal box = (0 0 0) to (72.3 72.3 72.3)
+  1 by 2 by 2 MPI processor grid
+create_atoms	1 box
+Created 32000 atoms
+
+pair_style	eam
+pair_coeff	1 1 Cu_u3.eam
+Reading potential file Cu_u3.eam with DATE: 2007-06-11
+
+velocity	all create 1600.0 376847 loop geom
+
+neighbor	1.0 bin
+neigh_modify    every 1 delay 5 check yes
+
+fix		1 all nve
+
+timestep	0.005
+thermo		50
+
+run		100
+Neighbor list info ...
+  1 neighbor list requests
+  update every 1 steps, delay 5 steps, check yes
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 5.95
+  ghost atom cutoff = 5.95
+  binsize = 2.975 -> bins = 25 25 25
+Memory usage per processor = 5.59629 Mbytes
+Step Temp E_pair E_mol TotEng Press 
+       0         1600      -113280            0   -106662.09    18703.573 
+      50    781.69049   -109873.35            0   -106640.13    52273.088 
+     100      801.832    -109957.3            0   -106640.77    51322.821 
+Loop time of 1.64562 on 4 procs for 100 steps with 32000 atoms
+
+Performance: 26.252 ns/day, 0.914 hours/ns, 60.767 timesteps/s
+99.8% CPU use with 4 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 1.408      | 1.4175     | 1.4341     |   0.9 | 86.14
+Neigh   | 0.15512    | 0.15722    | 0.16112    |   0.6 |  9.55
+Comm    | 0.029105   | 0.049986   | 0.061822   |   5.8 |  3.04
+Output  | 0.00010991 | 0.00011539 | 0.00012302 |   0.0 |  0.01
+Modify  | 0.013383   | 0.013573   | 0.013883   |   0.2 |  0.82
+Other   |            | 0.007264   |            |       |  0.44
+
+Nlocal:    8000 ave 8008 max 7993 min
+Histogram: 2 0 0 0 0 0 0 0 1 1
+Nghost:    9130.25 ave 9138 max 9122 min
+Histogram: 2 0 0 0 0 0 0 0 0 2
+Neighs:    301946 ave 302392 max 301360 min
+Histogram: 1 0 0 0 1 0 0 0 1 1
+
+Total # of neighbors = 1207784
+Ave neighs/atom = 37.7433
+Neighbor list builds = 13
+Dangerous builds = 0
+Total wall time: 0:00:01
--- a/bench/log.6Oct16.eam.scaled.icc.4
+++ b/bench/log.6Oct16.eam.scaled.icc.4
@ -0,0 +1,83 @@
+LAMMPS (6 Oct 2016)
+# bulk Cu lattice
+
+variable	x index 1
+variable	y index 1
+variable	z index 1
+
+variable	xx equal 20*$x
+variable	xx equal 20*2
+variable	yy equal 20*$y
+variable	yy equal 20*2
+variable	zz equal 20*$z
+variable	zz equal 20*1
+
+units		metal
+atom_style	atomic
+
+lattice		fcc 3.615
+Lattice spacing in x,y,z = 3.615 3.615 3.615
+region		box block 0 ${xx} 0 ${yy} 0 ${zz}
+region		box block 0 40 0 ${yy} 0 ${zz}
+region		box block 0 40 0 40 0 ${zz}
+region		box block 0 40 0 40 0 20
+create_box	1 box
+Created orthogonal box = (0 0 0) to (144.6 144.6 72.3)
+  2 by 2 by 1 MPI processor grid
+create_atoms	1 box
+Created 128000 atoms
+
+pair_style	eam
+pair_coeff	1 1 Cu_u3.eam
+Reading potential file Cu_u3.eam with DATE: 2007-06-11
+
+velocity	all create 1600.0 376847 loop geom
+
+neighbor	1.0 bin
+neigh_modify    every 1 delay 5 check yes
+
+fix		1 all nve
+
+timestep	0.005
+thermo		50
+
+run		100
+Neighbor list info ...
+  1 neighbor list requests
+  update every 1 steps, delay 5 steps, check yes
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 5.95
+  ghost atom cutoff = 5.95
+  binsize = 2.975 -> bins = 49 49 25
+Memory usage per processor = 11.1402 Mbytes
+Step Temp E_pair E_mol TotEng Press 
+       0         1600      -453120            0   -426647.73    18704.012 
+      50    779.50001   -439457.02            0   -426560.06    52355.276 
+     100    797.97828   -439764.76            0   -426562.07     51474.74 
+Loop time of 6.60121 on 4 procs for 100 steps with 128000 atoms
+
+Performance: 6.544 ns/day, 3.667 hours/ns, 15.149 timesteps/s
+99.9% CPU use with 4 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 5.6676     | 5.7011     | 5.7469     |   1.3 | 86.36
+Neigh   | 0.66423    | 0.67119    | 0.68082    |   0.7 | 10.17
+Comm    | 0.079367   | 0.13668    | 0.1791     |  10.5 |  2.07
+Output  | 0.00026989 | 0.00028622 | 0.00031209 |   0.1 |  0.00
+Modify  | 0.060046   | 0.062203   | 0.065009   |   0.9 |  0.94
+Other   |            | 0.02974    |            |       |  0.45
+
+Nlocal:    32000 ave 32092 max 31914 min
+Histogram: 1 0 0 1 0 1 0 0 0 1
+Nghost:    19910 ave 19997 max 19818 min
+Histogram: 1 0 0 0 1 0 1 0 0 1
+Neighs:    1.20728e+06 ave 1.21142e+06 max 1.2036e+06 min
+Histogram: 1 0 0 1 1 0 0 0 0 1
+
+Total # of neighbors = 4829126
+Ave neighs/atom = 37.7275
+Neighbor list builds = 14
+Dangerous builds = 0
+Total wall time: 0:00:06
--- a/bench/log.6Oct16.lj.fixed.icc.1
+++ b/bench/log.6Oct16.lj.fixed.icc.1
@ -0,0 +1,79 @@
+LAMMPS (6 Oct 2016)
+# 3d Lennard-Jones melt
+
+variable	x index 1
+variable	y index 1
+variable	z index 1
+
+variable	xx equal 20*$x
+variable	xx equal 20*1
+variable	yy equal 20*$y
+variable	yy equal 20*1
+variable	zz equal 20*$z
+variable	zz equal 20*1
+
+units		lj
+atom_style	atomic
+
+lattice		fcc 0.8442
+Lattice spacing in x,y,z = 1.6796 1.6796 1.6796
+region		box block 0 ${xx} 0 ${yy} 0 ${zz}
+region		box block 0 20 0 ${yy} 0 ${zz}
+region		box block 0 20 0 20 0 ${zz}
+region		box block 0 20 0 20 0 20
+create_box	1 box
+Created orthogonal box = (0 0 0) to (33.5919 33.5919 33.5919)
+  1 by 1 by 1 MPI processor grid
+create_atoms	1 box
+Created 32000 atoms
+mass		1 1.0
+
+velocity	all create 1.44 87287 loop geom
+
+pair_style	lj/cut 2.5
+pair_coeff	1 1 1.0 1.0 2.5
+
+neighbor	0.3 bin
+neigh_modify	delay 0 every 20 check no
+
+fix		1 all nve
+
+run		100
+Neighbor list info ...
+  1 neighbor list requests
+  update every 20 steps, delay 0 steps, check no
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 2.8
+  ghost atom cutoff = 2.8
+  binsize = 1.4 -> bins = 24 24 24
+Memory usage per processor = 8.21387 Mbytes
+Step Temp E_pair E_mol TotEng Press 
+       0         1.44   -6.7733681            0   -4.6134356   -5.0197073 
+     100    0.7574531   -5.7585055            0   -4.6223613   0.20726105 
+Loop time of 2.26185 on 1 procs for 100 steps with 32000 atoms
+
+Performance: 19099.377 tau/day, 44.212 timesteps/s
+99.9% CPU use with 1 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 1.9328     | 1.9328     | 1.9328     |   0.0 | 85.45
+Neigh   | 0.2558     | 0.2558     | 0.2558     |   0.0 | 11.31
+Comm    | 0.024061   | 0.024061   | 0.024061   |   0.0 |  1.06
+Output  | 0.00012612 | 0.00012612 | 0.00012612 |   0.0 |  0.01
+Modify  | 0.040887   | 0.040887   | 0.040887   |   0.0 |  1.81
+Other   |            | 0.008214   |            |       |  0.36
+
+Nlocal:    32000 ave 32000 max 32000 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Nghost:    19657 ave 19657 max 19657 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Neighs:    1.20283e+06 ave 1.20283e+06 max 1.20283e+06 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+
+Total # of neighbors = 1202833
+Ave neighs/atom = 37.5885
+Neighbor list builds = 5
+Dangerous builds not checked
+Total wall time: 0:00:02
--- a/bench/log.6Oct16.lj.fixed.icc.4
+++ b/bench/log.6Oct16.lj.fixed.icc.4
@ -0,0 +1,79 @@
+LAMMPS (6 Oct 2016)
+# 3d Lennard-Jones melt
+
+variable	x index 1
+variable	y index 1
+variable	z index 1
+
+variable	xx equal 20*$x
+variable	xx equal 20*1
+variable	yy equal 20*$y
+variable	yy equal 20*1
+variable	zz equal 20*$z
+variable	zz equal 20*1
+
+units		lj
+atom_style	atomic
+
+lattice		fcc 0.8442
+Lattice spacing in x,y,z = 1.6796 1.6796 1.6796
+region		box block 0 ${xx} 0 ${yy} 0 ${zz}
+region		box block 0 20 0 ${yy} 0 ${zz}
+region		box block 0 20 0 20 0 ${zz}
+region		box block 0 20 0 20 0 20
+create_box	1 box
+Created orthogonal box = (0 0 0) to (33.5919 33.5919 33.5919)
+  1 by 2 by 2 MPI processor grid
+create_atoms	1 box
+Created 32000 atoms
+mass		1 1.0
+
+velocity	all create 1.44 87287 loop geom
+
+pair_style	lj/cut 2.5
+pair_coeff	1 1 1.0 1.0 2.5
+
+neighbor	0.3 bin
+neigh_modify	delay 0 every 20 check no
+
+fix		1 all nve
+
+run		100
+Neighbor list info ...
+  1 neighbor list requests
+  update every 20 steps, delay 0 steps, check no
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 2.8
+  ghost atom cutoff = 2.8
+  binsize = 1.4 -> bins = 24 24 24
+Memory usage per processor = 4.09506 Mbytes
+Step Temp E_pair E_mol TotEng Press 
+       0         1.44   -6.7733681            0   -4.6134356   -5.0197073 
+     100    0.7574531   -5.7585055            0   -4.6223613   0.20726105 
+Loop time of 0.635957 on 4 procs for 100 steps with 32000 atoms
+
+Performance: 67929.172 tau/day, 157.243 timesteps/s
+99.9% CPU use with 4 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 0.51335    | 0.51822    | 0.52569    |   0.7 | 81.49
+Neigh   | 0.063695   | 0.064309   | 0.065397   |   0.3 | 10.11
+Comm    | 0.027525   | 0.03629    | 0.041959   |   3.1 |  5.71
+Output  | 6.3896e-05 | 6.6698e-05 | 7.081e-05  |   0.0 |  0.01
+Modify  | 0.012472   | 0.01254    | 0.012618   |   0.1 |  1.97
+Other   |            | 0.004529   |            |       |  0.71
+
+Nlocal:    8000 ave 8037 max 7964 min
+Histogram: 2 0 0 0 0 0 0 0 1 1
+Nghost:    9007.5 ave 9050 max 8968 min
+Histogram: 1 1 0 0 0 0 0 1 0 1
+Neighs:    300708 ave 305113 max 297203 min
+Histogram: 1 0 0 1 1 0 0 0 0 1
+
+Total # of neighbors = 1202833
+Ave neighs/atom = 37.5885
+Neighbor list builds = 5
+Dangerous builds not checked
+Total wall time: 0:00:00
--- a/bench/log.6Oct16.lj.scaled.icc.4
+++ b/bench/log.6Oct16.lj.scaled.icc.4
@ -0,0 +1,79 @@
+LAMMPS (6 Oct 2016)
+# 3d Lennard-Jones melt
+
+variable	x index 1
+variable	y index 1
+variable	z index 1
+
+variable	xx equal 20*$x
+variable	xx equal 20*2
+variable	yy equal 20*$y
+variable	yy equal 20*2
+variable	zz equal 20*$z
+variable	zz equal 20*1
+
+units		lj
+atom_style	atomic
+
+lattice		fcc 0.8442
+Lattice spacing in x,y,z = 1.6796 1.6796 1.6796
+region		box block 0 ${xx} 0 ${yy} 0 ${zz}
+region		box block 0 40 0 ${yy} 0 ${zz}
+region		box block 0 40 0 40 0 ${zz}
+region		box block 0 40 0 40 0 20
+create_box	1 box
+Created orthogonal box = (0 0 0) to (67.1838 67.1838 33.5919)
+  2 by 2 by 1 MPI processor grid
+create_atoms	1 box
+Created 128000 atoms
+mass		1 1.0
+
+velocity	all create 1.44 87287 loop geom
+
+pair_style	lj/cut 2.5
+pair_coeff	1 1 1.0 1.0 2.5
+
+neighbor	0.3 bin
+neigh_modify	delay 0 every 20 check no
+
+fix		1 all nve
+
+run		100
+Neighbor list info ...
+  1 neighbor list requests
+  update every 20 steps, delay 0 steps, check no
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 2.8
+  ghost atom cutoff = 2.8
+  binsize = 1.4 -> bins = 48 48 24
+Memory usage per processor = 8.13678 Mbytes
+Step Temp E_pair E_mol TotEng Press 
+       0         1.44   -6.7733681            0   -4.6133849   -5.0196788 
+     100   0.75841891    -5.759957            0   -4.6223375   0.20008866 
+Loop time of 2.55762 on 4 procs for 100 steps with 128000 atoms
+
+Performance: 16890.677 tau/day, 39.099 timesteps/s
+99.8% CPU use with 4 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 2.0583     | 2.0988     | 2.1594     |   2.6 | 82.06
+Neigh   | 0.24411    | 0.24838    | 0.25585    |   0.9 |  9.71
+Comm    | 0.066397   | 0.13872    | 0.1863     |  11.9 |  5.42
+Output  | 0.00012994 | 0.00021023 | 0.00025702 |   0.3 |  0.01
+Modify  | 0.055533   | 0.058343   | 0.061791   |   1.2 |  2.28
+Other   |            | 0.0132     |            |       |  0.52
+
+Nlocal:    32000 ave 32060 max 31939 min
+Histogram: 1 0 1 0 0 0 0 1 0 1
+Nghost:    19630.8 ave 19681 max 19562 min
+Histogram: 1 0 0 0 1 0 0 0 1 1
+Neighs:    1.20195e+06 ave 1.20354e+06 max 1.19931e+06 min
+Histogram: 1 0 0 0 0 0 0 2 0 1
+
+Total # of neighbors = 4807797
+Ave neighs/atom = 37.5609
+Neighbor list builds = 5
+Dangerous builds not checked
+Total wall time: 0:00:02
--- a/bench/log.6Oct16.rhodo.fixed.icc.1
+++ b/bench/log.6Oct16.rhodo.fixed.icc.1
@ -0,0 +1,122 @@
+LAMMPS (6 Oct 2016)
+# Rhodopsin model
+
+units           real
+neigh_modify    delay 5 every 1
+
+atom_style      full
+bond_style      harmonic
+angle_style     charmm
+dihedral_style  charmm
+improper_style  harmonic
+pair_style      lj/charmm/coul/long 8.0 10.0
+pair_modify     mix arithmetic
+kspace_style    pppm 1e-4
+
+read_data       data.rhodo
+  orthogonal box = (-27.5 -38.5 -36.3646) to (27.5 38.5 36.3615)
+  1 by 1 by 1 MPI processor grid
+  reading atoms ...
+  32000 atoms
+  reading velocities ...
+  32000 velocities
+  scanning bonds ...
+  4 = max bonds/atom
+  scanning angles ...
+  8 = max angles/atom
+  scanning dihedrals ...
+  18 = max dihedrals/atom
+  scanning impropers ...
+  2 = max impropers/atom
+  reading bonds ...
+  27723 bonds
+  reading angles ...
+  40467 angles
+  reading dihedrals ...
+  56829 dihedrals
+  reading impropers ...
+  1034 impropers
+  4 = max # of 1-2 neighbors
+  12 = max # of 1-3 neighbors
+  24 = max # of 1-4 neighbors
+  26 = max # of special neighbors
+
+fix             1 all shake 0.0001 5 0 m 1.0 a 232
+  1617 = # of size 2 clusters
+  3633 = # of size 3 clusters
+  747 = # of size 4 clusters
+  4233 = # of frozen angles
+fix             2 all npt temp 300.0 300.0 100.0 		z 0.0 0.0 1000.0 mtk no pchain 0 tchain 1
+
+special_bonds   charmm
+
+thermo          50
+thermo_style    multi
+timestep        2.0
+
+run		100
+PPPM initialization ...
+WARNING: Using 12-bit tables for long-range coulomb (../kspace.cpp:316)
+  G vector (1/distance) = 0.248835
+  grid = 25 32 32
+  stencil order = 5
+  estimated absolute RMS force accuracy = 0.0355478
+  estimated relative force accuracy = 0.000107051
+  using double precision FFTs
+  3d grid and FFT values/proc = 41070 25600
+Neighbor list info ...
+  1 neighbor list requests
+  update every 1 steps, delay 5 steps, check yes
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 12
+  ghost atom cutoff = 12
+  binsize = 6 -> bins = 10 13 13
+Memory usage per processor = 93.2721 Mbytes
+---------------- Step        0 ----- CPU =      0.0000 (sec) ----------------
+TotEng   =    -25356.2064 KinEng   =     21444.8313 Temp     =       299.0397 
+PotEng   =    -46801.0377 E_bond   =      2537.9940 E_angle  =     10921.3742 
+E_dihed  =      5211.7865 E_impro  =       213.5116 E_vdwl   =     -2307.8634 
+E_coul   =    207025.8927 E_long   =   -270403.7333 Press    =      -149.3301 
+Volume   =    307995.0335 
+---------------- Step       50 ----- CPU =     17.2007 (sec) ----------------
+TotEng   =    -25330.0321 KinEng   =     21501.0036 Temp     =       299.8230 
+PotEng   =    -46831.0357 E_bond   =      2471.7033 E_angle  =     10836.5108 
+E_dihed  =      5239.6316 E_impro  =       227.1219 E_vdwl   =     -1993.2763 
+E_coul   =    206797.6655 E_long   =   -270410.3927 Press    =       237.6866 
+Volume   =    308031.5640 
+---------------- Step      100 ----- CPU =     35.0315 (sec) ----------------
+TotEng   =    -25290.7387 KinEng   =     21591.9096 Temp     =       301.0906 
+PotEng   =    -46882.6484 E_bond   =      2567.9789 E_angle  =     10781.9556 
+E_dihed  =      5198.7493 E_impro  =       216.7863 E_vdwl   =     -1902.6458 
+E_coul   =    206659.5006 E_long   =   -270404.9733 Press    =         6.7898 
+Volume   =    308133.9933 
+Loop time of 35.0316 on 1 procs for 100 steps with 32000 atoms
+
+Performance: 0.493 ns/day, 48.655 hours/ns, 2.855 timesteps/s
+99.9% CPU use with 1 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 25.021     | 25.021     | 25.021     |   0.0 | 71.42
+Bond    | 1.2834     | 1.2834     | 1.2834     |   0.0 |  3.66
+Kspace  | 3.2116     | 3.2116     | 3.2116     |   0.0 |  9.17
+Neigh   | 4.2767     | 4.2767     | 4.2767     |   0.0 | 12.21
+Comm    | 0.069283   | 0.069283   | 0.069283   |   0.0 |  0.20
+Output  | 0.00028205 | 0.00028205 | 0.00028205 |   0.0 |  0.00
+Modify  | 1.14       | 1.14       | 1.14       |   0.0 |  3.25
+Other   |            | 0.02938    |            |       |  0.08
+
+Nlocal:    32000 ave 32000 max 32000 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Nghost:    47958 ave 47958 max 47958 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Neighs:    1.20281e+07 ave 1.20281e+07 max 1.20281e+07 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+
+Total # of neighbors = 12028098
+Ave neighs/atom = 375.878
+Ave special neighs/atom = 7.43187
+Neighbor list builds = 11
+Dangerous builds = 0
+Total wall time: 0:00:36
--- a/bench/log.6Oct16.rhodo.fixed.icc.4
+++ b/bench/log.6Oct16.rhodo.fixed.icc.4
@ -0,0 +1,122 @@
+LAMMPS (6 Oct 2016)
+# Rhodopsin model
+
+units           real
+neigh_modify    delay 5 every 1
+
+atom_style      full
+bond_style      harmonic
+angle_style     charmm
+dihedral_style  charmm
+improper_style  harmonic
+pair_style      lj/charmm/coul/long 8.0 10.0
+pair_modify     mix arithmetic
+kspace_style    pppm 1e-4
+
+read_data       data.rhodo
+  orthogonal box = (-27.5 -38.5 -36.3646) to (27.5 38.5 36.3615)
+  1 by 2 by 2 MPI processor grid
+  reading atoms ...
+  32000 atoms
+  reading velocities ...
+  32000 velocities
+  scanning bonds ...
+  4 = max bonds/atom
+  scanning angles ...
+  8 = max angles/atom
+  scanning dihedrals ...
+  18 = max dihedrals/atom
+  scanning impropers ...
+  2 = max impropers/atom
+  reading bonds ...
+  27723 bonds
+  reading angles ...
+  40467 angles
+  reading dihedrals ...
+  56829 dihedrals
+  reading impropers ...
+  1034 impropers
+  4 = max # of 1-2 neighbors
+  12 = max # of 1-3 neighbors
+  24 = max # of 1-4 neighbors
+  26 = max # of special neighbors
+
+fix             1 all shake 0.0001 5 0 m 1.0 a 232
+  1617 = # of size 2 clusters
+  3633 = # of size 3 clusters
+  747 = # of size 4 clusters
+  4233 = # of frozen angles
+fix             2 all npt temp 300.0 300.0 100.0 		z 0.0 0.0 1000.0 mtk no pchain 0 tchain 1
+
+special_bonds   charmm
+
+thermo          50
+thermo_style    multi
+timestep        2.0
+
+run		100
+PPPM initialization ...
+WARNING: Using 12-bit tables for long-range coulomb (../kspace.cpp:316)
+  G vector (1/distance) = 0.248835
+  grid = 25 32 32
+  stencil order = 5
+  estimated absolute RMS force accuracy = 0.0355478
+  estimated relative force accuracy = 0.000107051
+  using double precision FFTs
+  3d grid and FFT values/proc = 13230 6400
+Neighbor list info ...
+  1 neighbor list requests
+  update every 1 steps, delay 5 steps, check yes
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 12
+  ghost atom cutoff = 12
+  binsize = 6 -> bins = 10 13 13
+Memory usage per processor = 37.3604 Mbytes
+---------------- Step        0 ----- CPU =      0.0000 (sec) ----------------
+TotEng   =    -25356.2064 KinEng   =     21444.8313 Temp     =       299.0397 
+PotEng   =    -46801.0377 E_bond   =      2537.9940 E_angle  =     10921.3742 
+E_dihed  =      5211.7865 E_impro  =       213.5116 E_vdwl   =     -2307.8634 
+E_coul   =    207025.8927 E_long   =   -270403.7333 Press    =      -149.3301 
+Volume   =    307995.0335 
+---------------- Step       50 ----- CPU =      4.6056 (sec) ----------------
+TotEng   =    -25330.0321 KinEng   =     21501.0036 Temp     =       299.8230 
+PotEng   =    -46831.0357 E_bond   =      2471.7033 E_angle  =     10836.5108 
+E_dihed  =      5239.6316 E_impro  =       227.1219 E_vdwl   =     -1993.2763 
+E_coul   =    206797.6655 E_long   =   -270410.3927 Press    =       237.6866 
+Volume   =    308031.5640 
+---------------- Step      100 ----- CPU =      9.3910 (sec) ----------------
+TotEng   =    -25290.7386 KinEng   =     21591.9096 Temp     =       301.0906 
+PotEng   =    -46882.6482 E_bond   =      2567.9789 E_angle  =     10781.9556 
+E_dihed  =      5198.7493 E_impro  =       216.7863 E_vdwl   =     -1902.6458 
+E_coul   =    206659.5007 E_long   =   -270404.9733 Press    =         6.7898 
+Volume   =    308133.9933 
+Loop time of 9.39107 on 4 procs for 100 steps with 32000 atoms
+
+Performance: 1.840 ns/day, 13.043 hours/ns, 10.648 timesteps/s
+99.8% CPU use with 4 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 6.2189     | 6.3266     | 6.6072     |   6.5 | 67.37
+Bond    | 0.30793    | 0.32122    | 0.3414     |   2.4 |  3.42
+Kspace  | 0.87994    | 1.1644     | 1.2855     |  15.3 | 12.40
+Neigh   | 1.1358     | 1.136      | 1.1362     |   0.0 | 12.10
+Comm    | 0.08292    | 0.084935   | 0.087077   |   0.5 |  0.90
+Output  | 0.00015712 | 0.00016558 | 0.00018501 |   0.1 |  0.00
+Modify  | 0.33717    | 0.34246    | 0.34794    |   0.7 |  3.65
+Other   |            | 0.01526    |            |       |  0.16
+
+Nlocal:    8000 ave 8143 max 7933 min
+Histogram: 1 2 0 0 0 0 0 0 0 1
+Nghost:    22733.5 ave 22769 max 22693 min
+Histogram: 1 0 0 0 0 2 0 0 0 1
+Neighs:    3.00702e+06 ave 3.0975e+06 max 2.96492e+06 min
+Histogram: 1 2 0 0 0 0 0 0 0 1
+
+Total # of neighbors = 12028098
+Ave neighs/atom = 375.878
+Ave special neighs/atom = 7.43187
+Neighbor list builds = 11
+Dangerous builds = 0
+Total wall time: 0:00:09
--- a/bench/log.6Oct16.rhodo.scaled.icc.4
+++ b/bench/log.6Oct16.rhodo.scaled.icc.4
@ -0,0 +1,143 @@
+LAMMPS (6 Oct 2016)
+# Rhodopsin model
+
+variable	x index 1
+variable	y index 1
+variable	z index 1
+
+units           real
+neigh_modify    delay 5 every 1
+
+atom_style      full
+atom_modify	map hash
+bond_style      harmonic
+angle_style     charmm
+dihedral_style  charmm
+improper_style  harmonic
+pair_style      lj/charmm/coul/long 8.0 10.0
+pair_modify     mix arithmetic
+kspace_style    pppm 1e-4
+
+read_data       data.rhodo
+  orthogonal box = (-27.5 -38.5 -36.3646) to (27.5 38.5 36.3615)
+  1 by 2 by 2 MPI processor grid
+  reading atoms ...
+  32000 atoms
+  reading velocities ...
+  32000 velocities
+  scanning bonds ...
+  4 = max bonds/atom
+  scanning angles ...
+  8 = max angles/atom
+  scanning dihedrals ...
+  18 = max dihedrals/atom
+  scanning impropers ...
+  2 = max impropers/atom
+  reading bonds ...
+  27723 bonds
+  reading angles ...
+  40467 angles
+  reading dihedrals ...
+  56829 dihedrals
+  reading impropers ...
+  1034 impropers
+  4 = max # of 1-2 neighbors
+  12 = max # of 1-3 neighbors
+  24 = max # of 1-4 neighbors
+  26 = max # of special neighbors
+
+replicate	$x $y $z
+replicate	2 $y $z
+replicate	2 2 $z
+replicate	2 2 1
+  orthogonal box = (-27.5 -38.5 -36.3646) to (82.5 115.5 36.3615)
+  2 by 2 by 1 MPI processor grid
+  128000 atoms
+  110892 bonds
+  161868 angles
+  227316 dihedrals
+  4136 impropers
+  4 = max # of 1-2 neighbors
+  12 = max # of 1-3 neighbors
+  24 = max # of 1-4 neighbors
+  26 = max # of special neighbors
+
+fix             1 all shake 0.0001 5 0 m 1.0 a 232
+  6468 = # of size 2 clusters
+  14532 = # of size 3 clusters
+  2988 = # of size 4 clusters
+  16932 = # of frozen angles
+fix             2 all npt temp 300.0 300.0 100.0 		z 0.0 0.0 1000.0 mtk no pchain 0 tchain 1
+
+special_bonds   charmm
+
+thermo          50
+thermo_style    multi
+timestep        2.0
+
+run		100
+PPPM initialization ...
+WARNING: Using 12-bit tables for long-range coulomb (../kspace.cpp:316)
+  G vector (1/distance) = 0.248593
+  grid = 48 60 36
+  stencil order = 5
+  estimated absolute RMS force accuracy = 0.0359793
+  estimated relative force accuracy = 0.00010835
+  using double precision FFTs
+  3d grid and FFT values/proc = 41615 25920
+Neighbor list info ...
+  1 neighbor list requests
+  update every 1 steps, delay 5 steps, check yes
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 12
+  ghost atom cutoff = 12
+  binsize = 6 -> bins = 19 26 13
+Memory usage per processor = 96.9597 Mbytes
+---------------- Step        0 ----- CPU =      0.0000 (sec) ----------------
+TotEng   =   -101425.4887 KinEng   =     85779.3251 Temp     =       299.0304 
+PotEng   =   -187204.8138 E_bond   =     10151.9760 E_angle  =     43685.4968 
+E_dihed  =     20847.1460 E_impro  =       854.0463 E_vdwl   =     -9231.4537 
+E_coul   =    827053.5824 E_long   =  -1080565.6077 Press    =      -149.0358 
+Volume   =   1231980.1340 
+---------------- Step       50 ----- CPU =     18.1689 (sec) ----------------
+TotEng   =   -101320.0211 KinEng   =     86003.4933 Temp     =       299.8118 
+PotEng   =   -187323.5144 E_bond   =      9887.1189 E_angle  =     43346.8448 
+E_dihed  =     20958.7108 E_impro  =       908.4721 E_vdwl   =     -7973.4486 
+E_coul   =    826141.5493 E_long   =  -1080592.7617 Press    =       238.0404 
+Volume   =   1232126.1814 
+---------------- Step      100 ----- CPU =     37.2027 (sec) ----------------
+TotEng   =   -101157.9546 KinEng   =     86355.7413 Temp     =       301.0398 
+PotEng   =   -187513.6959 E_bond   =     10272.0456 E_angle  =     43128.7018 
+E_dihed  =     20794.0107 E_impro  =       867.0928 E_vdwl   =     -7587.2409 
+E_coul   =    825584.2416 E_long   =  -1080572.5474 Press    =        15.1729 
+Volume   =   1232535.8440 
+Loop time of 37.2028 on 4 procs for 100 steps with 128000 atoms
+
+Performance: 0.464 ns/day, 51.671 hours/ns, 2.688 timesteps/s
+99.9% CPU use with 4 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 25.431     | 25.738     | 25.984     |   4.0 | 69.18
+Bond    | 1.2966     | 1.3131     | 1.3226     |   0.9 |  3.53
+Kspace  | 3.7563     | 4.0123     | 4.3127     |  10.0 | 10.79
+Neigh   | 4.3778     | 4.378      | 4.3782     |   0.0 | 11.77
+Comm    | 0.1903     | 0.19549    | 0.20485    |   1.3 |  0.53
+Output  | 0.00031805 | 0.00037521 | 0.00039601 |   0.2 |  0.00
+Modify  | 1.4861     | 1.5051     | 1.5122     |   0.9 |  4.05
+Other   |            | 0.05992    |            |       |  0.16
+
+Nlocal:    32000 ave 32000 max 32000 min
+Histogram: 4 0 0 0 0 0 0 0 0 0
+Nghost:    47957 ave 47957 max 47957 min
+Histogram: 4 0 0 0 0 0 0 0 0 0
+Neighs:    1.20281e+07 ave 1.20572e+07 max 1.19991e+07 min
+Histogram: 2 0 0 0 0 0 0 0 0 2
+
+Total # of neighbors = 48112540
+Ave neighs/atom = 375.879
+Ave special neighs/atom = 7.43187
+Neighbor list builds = 11
+Dangerous builds = 0
+Total wall time: 0:00:38
--- a/doc/.gitignore
+++ b/doc/.gitignore
@ -0,0 +1,6 @@
+/html
+/spelling
+/LAMMPS.epub
+/LAMMPS.mobi
+/Manual.pdf
+/Developer.pdf
--- a/doc/2001/input_commands.html
+++ b/doc/2001/input_commands.html
--- a/doc/99/input_commands.html
+++ b/doc/99/input_commands.html
--- a/doc/Developer.pdf
+++ b/doc/Developer.pdf
--- a/doc/Eqs/dihedral_sign.jpg
+++ b/doc/Eqs/dihedral_sign.jpg
--- a/doc/Eqs/fix_nh1.jpg
+++ b/doc/Eqs/fix_nh1.jpg
--- a/doc/Eqs/fix_ti_rs_force.jpg
+++ b/doc/Eqs/fix_ti_rs_force.jpg
--- a/doc/Eqs/fix_ti_rs_force.tex
+++ b/doc/Eqs/fix_ti_rs_force.tex
@ -1,11 +0,0 @@
-\documentclass[12pt]{article}
-
-\usepackage{amsmath}
-
-\begin{document}
-
-$$
-  F_{\text{total}} = \lambda F_{\text{int}}
-$$
-
-\end{document}
--- a/doc/Eqs/fix_ti_rs_function_1.jpg
+++ b/doc/Eqs/fix_ti_rs_function_1.jpg
--- a/doc/Eqs/fix_ti_rs_function_1.tex
+++ b/doc/Eqs/fix_ti_rs_function_1.tex
@ -1,9 +0,0 @@
-\documentclass[12pt]{article}
-
-\begin{document}
-
-$$
-  \lambda(\tau) = \lambda_i + \tau \left( \lambda_f - \lambda_i \right)
-$$
-
-\end{document}
--- a/doc/Eqs/fix_ti_rs_function_2.jpg
+++ b/doc/Eqs/fix_ti_rs_function_2.jpg
--- a/doc/Eqs/fix_ti_rs_function_2.tex
+++ b/doc/Eqs/fix_ti_rs_function_2.tex
@ -1,9 +0,0 @@
-\documentclass[12pt]{article}
-
-\begin{document}
-
-$$
-  \lambda(\tau) = \frac{\lambda_i}{1 + \tau \left( \frac{\lambda_i}{\lambda_f} - 1 \right)}
-$$
-
-\end{document}
--- a/doc/Eqs/fix_ti_rs_function_3.jpg
+++ b/doc/Eqs/fix_ti_rs_function_3.jpg
--- a/doc/Eqs/fix_ti_rs_function_3.tex
+++ b/doc/Eqs/fix_ti_rs_function_3.tex
@ -1,9 +0,0 @@
-\documentclass[12pt]{article}
-
-\begin{document}
-
-$$
-  \lambda(\tau) = \frac{\lambda_i}{ 1 + \log_2(1+\tau) \left( \frac{\lambda_i}{\lambda_f} - 1 \right)}
-$$
-
-\end{document}
--- a/doc/Eqs/fix_ti_spring_force.jpg
+++ b/doc/Eqs/fix_ti_spring_force.jpg
--- a/doc/Eqs/fix_ti_spring_force.tex
+++ b/doc/Eqs/fix_ti_spring_force.tex
@ -1,11 +0,0 @@
-\documentclass[12pt]{article}
-
-\usepackage{amsmath}
-
-\begin{document}
-
-$$
-  F_{\text{total}} = \left( 1-\lambda \right) F_{\text{solid}} + \lambda F_{\text{harm}}
-$$
-
-\end{document}
--- a/doc/Eqs/fix_ti_spring_function_1.jpg
+++ b/doc/Eqs/fix_ti_spring_function_1.jpg
--- a/doc/Eqs/fix_ti_spring_function_2.jpg
+++ b/doc/Eqs/fix_ti_spring_function_2.jpg
--- a/doc/Eqs/improper_umbrella.tex
+++ b/doc/Eqs/improper_umbrella.tex
@ -1,13 +0,0 @@
-\documentstyle[12pt]{article}
-
-\begin{document}
-
-$$
-E=\frac{1}{2}K\left( \frac{1+cos\omega_0}{sin\omega_0}\right) ^2 \left( cos\omega - cos\omega_0\right) \qquad \omega_0 \neq 0^o
-$$
-
-$$
-E=K\left( 1-cos\omega\right)  \qquad \omega_0 = 0^o
-$$
-
-\end{document}
--- a/doc/Eqs/pair_meam_spline.jpg
+++ b/doc/Eqs/pair_meam_spline.jpg
--- a/doc/Eqs/pair_meam_spline.tex
+++ b/doc/Eqs/pair_meam_spline.tex
@ -1,13 +0,0 @@
-\documentclass[12pt]{article}
-
-\begin{document}
-
-$$
-   E=\sum_{ij}\phi(r_{ij})+\sum_{i}U(\rho_{i}),
-$$
-
-$$
-   \rho_{i}=\sum_{j}\rho(r_{ij})+\sum_{jk}f(r_{ij})f(r_{ik})g[\cos(\theta_{jik})]
-$$
-
-\end{document}
--- a/doc/Eqs/pressure.jpg
+++ b/doc/Eqs/pressure.jpg
--- a/doc/Eqs/pressure.tex
+++ b/doc/Eqs/pressure.tex
@ -1,9 +0,0 @@
-\documentclass[12pt]{article}
-
-\begin{document}
-
-$$
-   P = \frac{N k_B T}{V} + \frac{\sum_{i}^{N} r_i \bullet f_i}{dV}
-$$
-
-\end{document}
--- a/doc/Eqs/pressure_tensor.jpg
+++ b/doc/Eqs/pressure_tensor.jpg
--- a/doc/Makefile
+++ b/doc/Makefile
@ -0,0 +1,172 @@
+# Makefile for LAMMPS documentation
+
+SHELL 	      = /bin/bash
+SHA1          = $(shell echo $USER-$PWD | python utils/sha1sum.py)
+BUILDDIR      = /tmp/lammps-docs-$(SHA1)
+RSTDIR        = $(BUILDDIR)/rst
+VENV          = $(BUILDDIR)/docenv
+TXT2RST       = $(VENV)/bin/txt2rst
+ANCHORCHECK   = $(VENV)/bin/doc_anchor_check
+
+PYTHON        = $(shell which python3)
+HAS_PYTHON3    = NO
+HAS_VIRTUALENV = NO
+
+ifeq ($(shell which python3 >/dev/null 2>&1; echo $$?), 0)
+HAS_PYTHON3 = YES
+endif
+
+ifeq ($(shell which virtualenv >/dev/null 2>&1; echo $$?), 0)
+HAS_VIRTUALENV = YES
+endif
+
+SOURCES=$(wildcard src/*.txt)
+OBJECTS=$(SOURCES:src/%.txt=$(RSTDIR)/%.rst)
+
+.PHONY: help clean-all clean epub html pdf old venv spelling anchor_check
+
+# ------------------------------------------
+
+help:
+	@echo "Please use \`make <target>' where <target> is one of"
+	@echo "  html       create HTML doc pages in html dir"
+	@echo "  pdf        create Manual.pdf and Developer.pdf in this dir"
+	@echo "  old        create old-style HTML doc pages in old dir"
+	@echo "  fetch      fetch HTML and PDF files from LAMMPS web site"
+	@echo "  epub       create ePUB format manual for e-book readers"
+	@echo "  clean      remove all intermediate RST files"
+	@echo "  clean-all  reset the entire build environment"
+	@echo "  txt2html   build txt2html tool"
+	@echo "  anchor_check  scan for duplicate anchor labels"
+
+# ------------------------------------------
+
+clean-all:
+	rm -rf $(BUILDDIR)/* utils/txt2html/txt2html.exe
+
+clean:
+	rm -rf $(RSTDIR) html
+	rm -rf spelling
+
+clean-spelling:
+	rm -rf spelling
+
+html: $(OBJECTS) $(ANCHORCHECK)
+	@(\
+		. $(VENV)/bin/activate ;\
+		cp -r src/* $(RSTDIR)/ ;\
+		sphinx-build -j 8 -b html -c utils/sphinx-config -d $(BUILDDIR)/doctrees $(RSTDIR) html ;\
+		echo "############################################" ;\
+		doc_anchor_check src/*.txt ;\
+		echo "############################################" ;\
+		deactivate ;\
+	)
+	-rm html/searchindex.js
+	@rm -rf html/_sources
+	@rm -rf html/PDF
+	@rm -rf html/USER
+	@cp -r src/PDF html/PDF
+	@cp -r src/USER html/USER
+	@rm -rf html/PDF/.[sg]*
+	@rm -rf html/USER/.[sg]*
+	@rm -rf html/USER/*/.[sg]*
+	@rm -rf html/USER/*/*.[sg]*
+	@echo "Build finished. The HTML pages are in doc/html."
+
+spelling: $(OBJECTS) utils/sphinx-config/false_positives.txt
+	@(\
+		. $(VENV)/bin/activate ;\
+		pip install sphinxcontrib-spelling ;\
+		cp -r src/* $(RSTDIR)/ ;\
+        cp utils/sphinx-config/false_positives.txt $(RSTDIR)/ ;\
+		sphinx-build -b spelling -c utils/sphinx-config -d $(BUILDDIR)/doctrees $(RSTDIR) spelling ;\
+		deactivate ;\
+	)
+	@echo "Spell check finished."
+
+epub: $(OBJECTS)
+	@mkdir -p epub
+	@rm -f LAMMPS.epub
+	@cp src/JPG/lammps-logo.png epub/
+	@(\
+		. $(VENV)/bin/activate ;\
+		cp -r src/* $(RSTDIR)/ ;\
+		sphinx-build -j 8 -b epub -c utils/sphinx-config -d $(BUILDDIR)/doctrees $(RSTDIR) epub ;\
+		deactivate ;\
+	)
+	@mv  epub/LAMMPS.epub .
+	@rm -rf epub
+	@echo "Build finished. The ePUB manual file is created."
+
+pdf: utils/txt2html/txt2html.exe
+	@(\
+		cd src; \
+		../utils/txt2html/txt2html.exe -b *.txt; \
+		htmldoc --batch lammps.book;          \
+		for s in `echo *.txt | sed -e 's,\.txt,\.html,g'` ; \
+			do grep -q $$s lammps.book || \
+			echo doc file $$s missing in src/lammps.book; done; \
+		rm *.html; \
+		cd Developer; \
+		pdflatex developer; \
+		pdflatex developer; \
+		mv developer.pdf ../../Developer.pdf; \
+	)
+
+old: utils/txt2html/txt2html.exe
+	@rm -rf old
+	@mkdir old; mkdir old/Eqs; mkdir old/JPG; mkdir old/PDF
+	@cd src; ../utils/txt2html/txt2html.exe -b *.txt; \
+	  mv *.html ../old; \
+	  cp Eqs/*.jpg ../old/Eqs; \
+	  cp JPG/* ../old/JPG; \
+	  cp PDF/* ../old/PDF;
+
+fetch:
+	@rm -rf html_www Manual_www.pdf Developer_www.pdf
+	@curl -s -o Manual_www.pdf http://lammps.sandia.gov/doc/Manual.pdf
+	@curl -s -o Developer_www.pdf http://lammps.sandia.gov/doc/Developer.pdf
+	@curl -s -o lammps-doc.tar.gz http://lammps.sandia.gov/tars/lammps-doc.tar.gz
+	@tar xzf lammps-doc.tar.gz
+	@rm -f lammps-doc.tar.gz
+
+txt2html: utils/txt2html/txt2html.exe
+
+anchor_check : $(ANCHORCHECK)
+	@(\
+		. $(VENV)/bin/activate ;\
+		doc_anchor_check src/*.txt ;\
+		deactivate ;\
+	)
+
+# ------------------------------------------
+
+utils/txt2html/txt2html.exe: utils/txt2html/txt2html.cpp
+	g++ -O -Wall -o $@ $<
+
+$(RSTDIR)/%.rst : src/%.txt $(TXT2RST)
+	@(\
+		mkdir -p $(RSTDIR) ; \
+		. $(VENV)/bin/activate ;\
+		txt2rst $< > $@ ;\
+		deactivate ;\
+	)
+
+$(VENV):
+	@if [ "$(HAS_PYTHON3)" == "NO" ] ; then echo "Python3 was not found! Please check README.md for further instructions" 1>&2; exit 1; fi
+	@if [ "$(HAS_VIRTUALENV)" == "NO" ] ; then echo "virtualenv was not found! Please check README.md for further instructions" 1>&2; exit 1; fi
+	@( \
+		virtualenv -p $(PYTHON) $(VENV); \
+		. $(VENV)/bin/activate; \
+		pip install Sphinx==1.5.6; \
+		pip install sphinxcontrib-images; \
+		deactivate;\
+	)
+
+$(TXT2RST) $(ANCHORCHECK): $(VENV)
+	@( \
+		. $(VENV)/bin/activate; \
+		(cd utils/converters;\
+		python setup.py develop);\
+		deactivate;\
+	)
--- a/doc/Manual.html
+++ b/doc/Manual.html
@ -1,426 +0,0 @@
-<HTML>
-<HEAD>
-<TITLE>LAMMPS Users Manual</TITLE>
-<META NAME="docnumber" CONTENT="15 May 2015 version">
-<META NAME="author" CONTENT="http://lammps.sandia.gov - Sandia National Laboratories">
-<META NAME="copyright" CONTENT="Copyright (2003) Sandia Corporation.  This software and manual is distributed under the GNU General Public License.">
-</HEAD>
-
-<BODY>
-
-<CENTER><A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> - <A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A> 
-</CENTER>
-
-
-
-
-
-
-<HR>
-
-<H1></H1>
-
-<CENTER><H3>LAMMPS Documentation 
-</H3></CENTER>
-<CENTER><H4>15 May 2015 version 
-</H4></CENTER>
-<H4>Version info: 
-</H4>
-<P>The LAMMPS "version" is the date when it was released, such as 1 May
-2010. LAMMPS is updated continuously.  Whenever we fix a bug or add a
-feature, we release it immediately, and post a notice on <A HREF = "http://lammps.sandia.gov/bug.html">this page of
-the WWW site</A>.  Each dated copy of LAMMPS contains all the
-features and bug-fixes up to and including that version date. The
-version date is printed to the screen and logfile every time you run
-LAMMPS. It is also in the file src/version.h and in the LAMMPS
-directory name created when you unpack a tarball, and at the top of
-the first page of the manual (this page).
-</P>
-<UL><LI>If you browse the HTML doc pages on the LAMMPS WWW site, they always
-describe the most current version of LAMMPS. 
-
-<LI>If you browse the HTML doc pages included in your tarball, they
-describe the version you have. 
-
-<LI>The <A HREF = "Manual.pdf">PDF file</A> 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 every patch. 
-
-<LI>There is also a <A HREF = "Developer.pdf">Developer.pdf</A> file in the doc
-directory, which describes the internal structure and algorithms of
-LAMMPS.  
-</UL>
-<P>LAMMPS stands for Large-scale Atomic/Molecular Massively Parallel
-Simulator.
-</P>
-<P>LAMMPS is a classical molecular dynamics simulation code designed to
-run efficiently on parallel computers.  It was developed at Sandia
-National Laboratories, a US Department of Energy facility, with
-funding from the DOE.  It is an open-source code, distributed freely
-under the terms of the GNU Public License (GPL).
-</P>
-<P>The primary developers of LAMMPS are <A HREF = "http://www.sandia.gov/~sjplimp">Steve Plimpton</A>, Aidan
-Thompson, and Paul Crozier who can be contacted at
-sjplimp,athomps,pscrozi at sandia.gov.  The <A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> at
-http://lammps.sandia.gov has more information about the code and its
-uses.
-</P>
-
-
-
-
-<HR>
-
-<P>The LAMMPS documentation is organized into the following sections.  If
-you find errors or omissions in this manual or have suggestions for
-useful information to add, please send an email to the developers so
-we can improve the LAMMPS documentation.
-</P>
-<P>Once you are familiar with LAMMPS, you may want to bookmark <A HREF = "Section_commands.html#comm">this
-page</A> at Section_commands.html#comm since
-it gives quick access to documentation for all LAMMPS commands.
-</P>
-<P><A HREF = "Manual.pdf">PDF file</A> of the entire manual, generated by
-<A HREF = "http://freecode.com/projects/htmldoc">htmldoc</A>
-</P>
-<OL><LI><A HREF = "Section_intro.html">Introduction</A> 
-
-<UL>  1.1 <A HREF = "Section_intro.html#intro_1">What is LAMMPS</A> 
-<BR>
-  1.2 <A HREF = "Section_intro.html#intro_2">LAMMPS features</A> 
-<BR>
-  1.3 <A HREF = "Section_intro.html#intro_3">LAMMPS non-features</A> 
-<BR>
-  1.4 <A HREF = "Section_intro.html#intro_4">Open source distribution</A> 
-<BR>
-  1.5 <A HREF = "Section_intro.html#intro_5">Acknowledgments and citations</A> 
-<BR></UL>
-<LI><A HREF = "Section_start.html">Getting started</A> 
-
-<UL>  2.1 <A HREF = "Section_start.html#start_1">What's in the LAMMPS distribution</A> 
-<BR>
-  2.2 <A HREF = "Section_start.html#start_2">Making LAMMPS</A> 
-<BR>
-  2.3 <A HREF = "Section_start.html#start_3">Making LAMMPS with optional packages</A> 
-<BR>
-  2.4 <A HREF = "Section_start.html#start_4">Building LAMMPS via the Make.py script</A> 
-<BR>
-  2.5 <A HREF = "Section_start.html#start_5">Building LAMMPS as a library</A> 
-<BR>
-  2.6 <A HREF = "Section_start.html#start_6">Running LAMMPS</A> 
-<BR>
-  2.7 <A HREF = "Section_start.html#start_7">Command-line options</A> 
-<BR>
-  2.8 <A HREF = "Section_start.html#start_8">Screen output</A> 
-<BR>
-  2.9 <A HREF = "Section_start.html#start_9">Tips for users of previous versions</A> 
-<BR></UL>
-<LI><A HREF = "Section_commands.html">Commands</A> 
-
-<UL>  3.1 <A HREF = "Section_commands.html#cmd_1">LAMMPS input script</A> 
-<BR>
-  3.2 <A HREF = "Section_commands.html#cmd_2">Parsing rules</A> 
-<BR>
-  3.3 <A HREF = "Section_commands.html#cmd_3">Input script structure</A> 
-<BR>
-  3.4 <A HREF = "Section_commands.html#cmd_4">Commands listed by category</A> 
-<BR>
-  3.5 <A HREF = "Section_commands.html#cmd_5">Commands listed alphabetically</A> 
-<BR></UL>
-<LI><A HREF = "Section_packages.html">Packages</A> 
-
-<UL>  4.1 <A HREF = "Section_packages.html#pkg_1">Standard packages</A> 
-<BR>
-  4.2 <A HREF = "Section_packages.html#pkg_2">User packages</A> 
-<BR></UL>
-<LI><A HREF = "Section_accelerate.html">Accelerating LAMMPS performance</A> 
-
-<UL>  5.1 <A HREF = "Section_accelerate.html#acc_1">Measuring performance</A> 
-<BR>
-  5.2 <A HREF = "Section_accelerate.html#acc_2">Algorithms and code options to boost performace</A> 
-<BR>
-  5.3 <A HREF = "Section_accelerate.html#acc_3">Accelerator packages with optimized styles</A> 
-<BR>
-<UL>    5.3.1 <A HREF = "accelerate_cuda.html">USER-CUDA package</A> 
-<BR>
-    5.3.2 <A HREF = "accelerate_gpu.html">GPU package</A> 
-<BR>
-    5.3.3 <A HREF = "accelerate_intel.html">USER-INTEL package</A> 
-<BR>
-    5.3.4 <A HREF = "accelerate_kokkos.html">KOKKOS package</A> 
-<BR>
-    5.3.5 <A HREF = "accelerate_omp.html">USER-OMP package</A> 
-<BR>
-    5.3.6 <A HREF = "accelerate_opt.html">OPT package</A> 
-<BR></UL>
-  5.4 <A HREF = "Section_accelerate.html#acc_4">Comparison of various accelerator packages</A> 
-<BR></UL>
-<LI><A HREF = "Section_howto.html">How-to discussions</A> 
-
-<UL>  6.1 <A HREF = "Section_howto.html#howto_1">Restarting a simulation</A> 
-<BR>
-  6.2 <A HREF = "Section_howto.html#howto_2">2d simulations</A> 
-<BR>
-  6.3 <A HREF = "Section_howto.html#howto_3">CHARMM and AMBER force fields</A> 
-<BR>
-  6.4 <A HREF = "Section_howto.html#howto_4">Running multiple simulations from one input script</A> 
-<BR>
-  6.5 <A HREF = "Section_howto.html#howto_5">Multi-replica simulations</A> 
-<BR>
-  6.6 <A HREF = "Section_howto.html#howto_6">Granular models</A> 
-<BR>
-  6.7 <A HREF = "Section_howto.html#howto_7">TIP3P water model</A> 
-<BR>
-  6.8 <A HREF = "Section_howto.html#howto_8">TIP4P water model</A> 
-<BR>
-  6.9 <A HREF = "Section_howto.html#howto_9">SPC water model</A> 
-<BR>
-  6.10 <A HREF = "Section_howto.html#howto_10">Coupling LAMMPS to other codes</A> 
-<BR>
-  6.11 <A HREF = "Section_howto.html#howto_11">Visualizing LAMMPS snapshots</A> 
-<BR>
-  6.12 <A HREF = "Section_howto.html#howto_12">Triclinic (non-orthogonal) simulation boxes</A> 
-<BR>
-  6.13 <A HREF = "Section_howto.html#howto_13">NEMD simulations</A> 
-<BR>
-  6.14 <A HREF = "Section_howto.html#howto_14">Finite-size spherical and aspherical particles</A> 
-<BR>
-  6.15 <A HREF = "Section_howto.html#howto_15">Output from LAMMPS (thermo, dumps, computes, fixes, variables)</A> 
-<BR>
-  6.16 <A HREF = "Section_howto.html#howto_16">Thermostatting, barostatting, and compute temperature</A> 
-<BR>
-  6.17 <A HREF = "Section_howto.html#howto_17">Walls</A> 
-<BR>
-  6.18 <A HREF = "Section_howto.html#howto_18">Elastic constants</A> 
-<BR>
-  6.19 <A HREF = "Section_howto.html#howto_19">Library interface to LAMMPS</A> 
-<BR>
-  6.20 <A HREF = "Section_howto.html#howto_20">Calculating thermal conductivity</A> 
-<BR>
-  6.21 <A HREF = "Section_howto.html#howto_21">Calculating viscosity</A> 
-<BR>
-  6.22 <A HREF = "howto_22">Calculating a diffusion coefficient</A> 
-<BR>
-  6.23 <A HREF = "howto_23">Using chunks to calculate system properties</A> 
-<BR>
-  6.24 <A HREF = "howto_24">Setting parameters for pppm/disp</A> 
-<BR></UL>
-<LI><A HREF = "Section_example.html">Example problems</A> 
-
-<LI><A HREF = "Section_perf.html">Performance & scalability</A> 
-
-<LI><A HREF = "Section_tools.html">Additional tools</A> 
-
-<LI><A HREF = "Section_modify.html">Modifying & extending LAMMPS</A> 
-
-<UL>  10.1 <A HREF = "Section_modify.html#mod_1">Atom styles</A> 
-<BR>
-  10.2 <A HREF = "Section_modify.html#mod_2">Bond, angle, dihedral, improper potentials</A> 
-<BR>
-  10.3 <A HREF = "Section_modify.html#mod_3">Compute styles</A> 
-<BR>
-  10.4 <A HREF = "Section_modify.html#mod_4">Dump styles</A> 
-<BR>
-  10.5 <A HREF = "Section_modify.html#mod_5">Dump custom output options</A> 
-<BR>
-  10.6 <A HREF = "Section_modify.html#mod_6">Fix styles</A> 
-<BR>
-  10.7 <A HREF = "Section_modify.html#mod_7">Input script commands</A> 
-<BR>
-  10.8 <A HREF = "Section_modify.html#mod_8">Kspace computations</A> 
-<BR>
-  10.9 <A HREF = "Section_modify.html#mod_9">Minimization styles</A> 
-<BR>
-  10.10 <A HREF = "Section_modify.html#mod_10">Pairwise potentials</A> 
-<BR>
-  10.11 <A HREF = "Section_modify.html#mod_11">Region styles</A> 
-<BR>
-  10.12 <A HREF = "Section_modify.html#mod_12">Body styles</A> 
-<BR>
-  10.13 <A HREF = "Section_modify.html#mod_13">Thermodynamic output options</A> 
-<BR>
-  10.14 <A HREF = "Section_modify.html#mod_14">Variable options</A> 
-<BR>
-  10.15 <A HREF = "Section_modify.html#mod_15">Submitting new features for inclusion in LAMMPS</A> 
-<BR></UL>
-<LI><A HREF = "Section_python.html">Python interface</A> 
-
-<UL>  11.1 <A HREF = "Section_python.html#py_1">Overview of running LAMMPS from Python</A> 
-<BR>
-  11.2 <A HREF = "Section_python.html#py_2">Overview of using Python from a LAMMPS script</A> 
-<BR>
-  11.3 <A HREF = "Section_python.html#py_3">Building LAMMPS as a shared library</A> 
-<BR>
-  11.4 <A HREF = "Section_python.html#py_4">Installing the Python wrapper into Python</A> 
-<BR>
-  11.5 <A HREF = "Section_python.html#py_5">Extending Python with MPI to run in parallel</A> 
-<BR>
-  11.6 <A HREF = "Section_python.html#py_6">Testing the Python-LAMMPS interface</A> 
-<BR>
-  11.7 <A HREF = "py_7">Using LAMMPS from Python</A> 
-<BR>
-  11.8 <A HREF = "py_8">Example Python scripts that use LAMMPS</A> 
-<BR></UL>
-<LI><A HREF = "Section_errors.html">Errors</A> 
-
-<UL>  12.1 <A HREF = "Section_errors.html#err_1">Common problems</A> 
-<BR>
-  12.2 <A HREF = "Section_errors.html#err_2">Reporting bugs</A> 
-<BR>
-  12.3 <A HREF = "Section_errors.html#err_3">Error & warning messages</A> 
-<BR></UL>
-<LI><A HREF = "Section_history.html">Future and history</A> 
-
-<UL>  13.1 <A HREF = "Section_history.html#hist_1">Coming attractions</A> 
-<BR>
-  13.2 <A HREF = "Section_history.html#hist_2">Past versions</A> 
-<BR></UL>
-
-</OL>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-</BODY>
-
-</HTML>
--- a/doc/Manual.pdf
+++ b/doc/Manual.pdf
--- a/doc/PDF/colvars-refman-lammps.pdf
+++ b/doc/PDF/colvars-refman-lammps.pdf
--- a/doc/README
+++ b/doc/README
@ -0,0 +1,115 @@
+LAMMPS Documentation
+
+Depending on how you obtained LAMMPS, this directory has 2 or 3
+sub-directories and optionally 2 PDF files and an ePUB file:
+
+src             content files for LAMMPS documentation
+html            HTML version of the LAMMPS manual (see html/Manual.html)
+tools           tools and settings for building the documentation
+Manual.pdf      large PDF version of entire manual
+Developer.pdf   small PDF with info about how LAMMPS is structured
+LAMMPS.epub     Manual in ePUB format
+
+If you downloaded LAMMPS as a tarball from the web site, all these
+directories and files should be included.
+
+If you downloaded LAMMPS from the public SVN or Git repositories, then
+the HTML and PDF files are not included.  Instead you need to create
+them, in one of three ways:
+
+(a) You can "fetch" the current HTML and PDF files from the LAMMPS web
+site.  Just type "make fetch".  This should create a html_www dir and
+Manual_www.pdf/Developer_www.pdf files.  Note that if new LAMMPS
+features have been added more recently than the date of your version,
+the fetched documentation will include those changes (but your source
+code will not, unless you update your local repository).
+
+(b) You can build the HTML and PDF files yourself, by typing "make
+html" followed by "make pdf".  Note that the PDF make requires the
+HTML files already exist.  This requires various tools including
+Sphinx, which the build process will attempt to download and install
+on your system, if not already available.  See more details below.
+
+(c) You can genererate an older, simpler, less-fancy style of HTML
+documentation by typing "make old".  This will create an "old"
+directory.  This can be useful if (b) does not work on your box for
+some reason, or you want to quickly view the HTML version of a doc
+page you have created or edited yourself within the src directory.
+E.g. if you are planning to submit a new feature to LAMMPS.
+
+----------------
+
+The generation of all documentation is managed by the Makefile in this
+dir.
+
+Options:
+
+make html         # generate HTML in html dir using Sphinx
+make pdf          # generate 2 PDF files (Manual.pdf,Developer.pdf)
+                  #   in this dir via htmldoc and pdflatex
+make old          # generate old-style HTML pages in old dir via txt2html
+make fetch        # fetch HTML doc pages and 2 PDF files from web site
+                  #   as a tarball and unpack into html dir and 2 PDFs
+make epub         # generate LAMMPS.epub in ePUB format using Sphinx 
+make clean        # remove intermediate RST files created by HTML build
+make clean-all    # remove entire build folder and any cached data
+
+----------------
+
+Installing prerequisites for HTML build
+
+To run the HTML documention build toolchain, Python 3 and virtualenv
+have to be installed.  Here are instructions for common setups:
+
+# Ubuntu
+
+sudo apt-get install python-virtualenv
+
+# Fedora (up to version 21)
+# Red Hat Enterprise Linux or CentOS (up to version 7.x)
+
+sudo yum install python3-virtualenv
+
+# Fedora (since version 22)
+
+sudo dnf install python3-virtualenv
+
+# MacOS X
+
+## Python 3
+
+Download the latest Python 3 MacOS X package from
+https://www.python.org and install it.  This will install both Python
+3 and pip3.
+
+## virtualenv
+
+Once Python 3 is installed, open a Terminal and type
+
+pip3 install virtualenv
+
+This will install virtualenv from the Python Package Index.
+
+----------------
+
+Installing prerequisites for PDF build
+
+[TBA]
+
+----------------
+
+Installing prerequisites for epub build
+
+## ePUB
+
+Same as for HTML. This uses the same tools and configuration
+files as the HTML tree.
+
+For converting the generated ePUB file to a mobi format file
+(for e-book readers like Kindle, that cannot read ePUB), you
+also need to have the 'ebook-convert' tool from the "calibre"
+software installed. http://calibre-ebook.com/
+You first create the ePUB file with 'make epub' and then do:
+
+ebook-convert LAMMPS.epub LAMMPS.mobi
+
--- a/doc/Scripts/correlate.py
+++ b/doc/Scripts/correlate.py
@ -1,89 +0,0 @@
-#!/usr/bin/env python
-"""
-  function: 
-    parse the block of thermo data in a lammps logfile and perform auto- and 
-    cross correlation of the specified column data.  The total sum of the 
-    correlation is also computed which can be converted to an integral by 
-    multiplying by the timestep. 
-  output:
-    standard output contains column data for the auto- & cross correlations 
-    plus the total sum of each. Note, only the upper triangle of the 
-    correlation matrix is computed.
-  usage: 
-    correlate.py [-c col] <-c col2> <-s max_correlation_time>  [logfile] 
-"""
-import sys
-import re
-import array
-
-# parse command line
-
-maxCorrelationTime = 0
-cols = array.array("I")
-nCols = 0
-args = sys.argv[1:]
-index = 0
-while index < len(args):
-  arg = args[index]
-  index += 1
-  if   (arg == "-c"):
-    cols.append(int(args[index])-1)
-    nCols += 1
-    index += 1
-  elif (arg == "-s"):
-    maxCorrelationTime = int(args[index])
-    index += 1
-  else :
-    filename = arg
-if (nCols < 1): raise RuntimeError, 'no data columns requested'
-data = [array.array("d")]
-for s in range(1,nCols)  : data.append( array.array("d") )
-
-# read data block from log file
-
-start = False
-input = open(filename)
-nSamples = 0
-pattern = re.compile('\d')
-line = input.readline()
-while line :
-  columns = line.split()
-  if (columns and pattern.match(columns[0])) :
-    for i in range(nCols): 
-      data[i].append( float(columns[cols[i]]) )
-    nSamples += 1
-    start = True
-  else :
-     if (start) : break
-  line = input.readline()
-print "# read :",nSamples," samples of ", nCols," data"
-if( maxCorrelationTime < 1): maxCorrelationTime = int(nSamples/2);
- 
-# correlate and integrate
-
-correlationPairs = []
-for i in range(0,nCols):
-  for j in range(i,nCols): # note only upper triangle of the correlation matrix
-    correlationPairs.append([i,j])
-header = "# "
-for k in range(len(correlationPairs)):
-  i = str(correlationPairs[k][0]+1)
-  j = str(correlationPairs[k][1]+1)
-  header += " C"+i+j+" sum_C"+i+j
-print header
-nCorrelationPairs = len(correlationPairs)
-sum = [0.0] * nCorrelationPairs
-for s in range(maxCorrelationTime)  :
-  correlation = [0.0] * nCorrelationPairs
-  nt = nSamples-s
-  for t in range(0,nt)  :
-    for p in range(nCorrelationPairs):
-      i = correlationPairs[p][0]
-      j = correlationPairs[p][1]
-      correlation[p] += data[i][t]*data[j][s+t]
-  output = ""
-  for p in range(0,nCorrelationPairs):
-    correlation[p] /= nt
-    sum[p] += correlation[p]
-    output += str(correlation[p]) + " " + str(sum[p]) + " "
-  print output
--- a/doc/Section_accelerate.html
+++ b/doc/Section_accelerate.html
@ -1,401 +0,0 @@
-<HTML>
-<CENTER><A HREF = "Section_packages.html">Previous Section</A> - <A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> -
-<A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A> - <A HREF = "Section_howto.html">Next
-Section</A> 
-</CENTER>
-
-
-
-
-
-
-<HR>
-
-<H3>5. Accelerating LAMMPS performance 
-</H3>
-<P>This section describes various methods for improving LAMMPS
-performance for different classes of problems running on different
-kinds of machines.
-</P>
-<P>There are two thrusts to the discussion that follows.  The
-first is using code options that implement alternate algorithms
-that can speed-up a simulation.  The second is to use one
-of the several accelerator packages provided with LAMMPS that
-contain code optimized for certain kinds of hardware, including
-multi-core CPUs, GPUs, and Intel Xeon Phi coprocessors.
-</P>
-<UL><LI>5.1 <A HREF = "#acc_1">Measuring performance</A> 
-
-<LI>5.2 <A HREF = "#acc_2">Algorithms and code options to boost performace</A> 
-
-<LI>5.3 <A HREF = "#acc_3">Accelerator packages with optimized styles</A> 
-
-<UL><LI>    5.3.1 <A HREF = "accelerate_cuda.html">USER-CUDA package</A> 
-
-<LI>    5.3.2 <A HREF = "accelerate_gpu.html">GPU package</A> 
-
-<LI>    5.3.3 <A HREF = "accelerate_intel.html">USER-INTEL package</A> 
-
-<LI>    5.3.4 <A HREF = "accelerate_kokkos.html">KOKKOS package</A> 
-
-<LI>    5.3.5 <A HREF = "accelerate_omp.html">USER-OMP package</A> 
-
-<LI>    5.3.6 <A HREF = "accelerate_opt.html">OPT package</A> 
-</UL>
-<LI>5.4 <A HREF = "#acc_4">Comparison of various accelerator packages</A> 
-</UL>
-<P>The <A HREF = "http://lammps.sandia.gov/bench.html">Benchmark page</A> of the LAMMPS
-web site gives performance results for the various accelerator
-packages discussed in Section 5.2, for several of the standard LAMMPS
-benchmark problems, as a function of problem size and number of
-compute nodes, on different hardware platforms.
-</P>
-<HR>
-
-<HR>
-
-<H4><A NAME = "acc_1"></A>5.1 Measuring performance 
-</H4>
-<P>Before trying to make your simulation run faster, you should
-understand how it currently performs and where the bottlenecks are.
-</P>
-<P>The best way to do this is run the your system (actual number of
-atoms) for a modest number of timesteps (say 100 steps) on several
-different processor counts, including a single processor if possible.
-Do this for an equilibrium version of your system, so that the
-100-step timings are representative of a much longer run.  There is
-typically no need to run for 1000s of timesteps to get accurate
-timings; you can simply extrapolate from short runs.
-</P>
-<P>For the set of runs, look at the timing data printed to the screen and
-log file at the end of each LAMMPS run.  <A HREF = "Section_start.html#start_8">This
-section</A> of the manual has an overview.
-</P>
-<P>Running on one (or a few processors) should give a good estimate of
-the serial performance and what portions of the timestep are taking
-the most time.  Running the same problem on a few different processor
-counts should give an estimate of parallel scalability.  I.e. if the
-simulation runs 16x faster on 16 processors, its 100% parallel
-efficient; if it runs 8x faster on 16 processors, it's 50% efficient.
-</P>
-<P>The most important data to look at in the timing info is the timing
-breakdown and relative percentages.  For example, trying different
-options for speeding up the long-range solvers will have little impact
-if they only consume 10% of the run time.  If the pairwise time is
-dominating, you may want to look at GPU or OMP versions of the pair
-style, as discussed below.  Comparing how the percentages change as
-you increase the processor count gives you a sense of how different
-operations within the timestep are scaling.  Note that if you are
-running with a Kspace solver, there is additional output on the
-breakdown of the Kspace time.  For PPPM, this includes the fraction
-spent on FFTs, which can be communication intensive.
-</P>
-<P>Another important detail in the timing info are the histograms of
-atoms counts and neighbor counts.  If these vary widely across
-processors, you have a load-imbalance issue.  This often results in
-inaccurate relative timing data, because processors have to wait when
-communication occurs for other processors to catch up.  Thus the
-reported times for "Communication" or "Other" may be higher than they
-really are, due to load-imbalance.  If this is an issue, you can
-uncomment the MPI_Barrier() lines in src/timer.cpp, and recompile
-LAMMPS, to obtain synchronized timings.
-</P>
-<HR>
-
-<H4><A NAME = "acc_2"></A>5.2 General strategies 
-</H4>
-<P>NOTE: this section 5.2 is still a work in progress
-</P>
-<P>Here is a list of general ideas for improving simulation performance.
-Most of them are only applicable to certain models and certain
-bottlenecks in the current performance, so let the timing data you
-generate be your guide.  It is hard, if not impossible, to predict how
-much difference these options will make, since it is a function of
-problem size, number of processors used, and your machine.  There is
-no substitute for identifying performance bottlenecks, and trying out
-various options.
-</P>
-<UL><LI>rRESPA
-<LI>2-FFT PPPM
-<LI>Staggered PPPM
-<LI>single vs double PPPM
-<LI>partial charge PPPM
-<LI>verlet/split run style
-<LI>processor command for proc layout and numa layout
-<LI>load-balancing: balance and fix balance 
-</UL>
-<P>2-FFT PPPM, also called <I>analytic differentiation</I> or <I>ad</I> PPPM, uses
-2 FFTs instead of the 4 FFTs used by the default <I>ik differentiation</I>
-PPPM. However, 2-FFT PPPM also requires a slightly larger mesh size to
-achieve the same accuracy as 4-FFT PPPM. For problems where the FFT
-cost is the performance bottleneck (typically large problems running
-on many processors), 2-FFT PPPM may be faster than 4-FFT PPPM.
-</P>
-<P>Staggered PPPM performs calculations using two different meshes, one
-shifted slightly with respect to the other.  This can reduce force
-aliasing errors and increase the accuracy of the method, but also
-doubles the amount of work required. For high relative accuracy, using
-staggered PPPM allows one to half the mesh size in each dimension as
-compared to regular PPPM, which can give around a 4x speedup in the
-kspace time. However, for low relative accuracy, using staggered PPPM
-gives little benefit and can be up to 2x slower in the kspace
-time. For example, the rhodopsin benchmark was run on a single
-processor, and results for kspace time vs. relative accuracy for the
-different methods are shown in the figure below.  For this system,
-staggered PPPM (using ik differentiation) becomes useful when using a
-relative accuracy of slightly greater than 1e-5 and above.
-</P>
-<CENTER><IMG SRC = "JPG/rhodo_staggered.jpg">
-</CENTER>
-<P>IMPORTANT NOTE: Using staggered PPPM may not give the same increase in
-accuracy of energy and pressure as it does in forces, so some caution
-must be used if energy and/or pressure are quantities of interest,
-such as when using a barostat.
-</P>
-<HR>
-
-<H4><A NAME = "acc_3"></A>5.3 Packages with optimized styles 
-</H4>
-<P>Accelerated versions of various <A HREF = "pair_style.html">pair_style</A>,
-<A HREF = "fix.html">fixes</A>, <A HREF = "compute.html">computes</A>, and other commands have
-been added to LAMMPS, which will typically run faster than the
-standard non-accelerated versions.  Some require appropriate hardware
-to be present on your system, e.g. GPUs or Intel Xeon Phi
-coprocessors.
-</P>
-<P>All of these commands are in packages provided with LAMMPS.  An
-overview of packages is give in <A HREF = "Section_packages.html">Section
-packages</A>.  These are the accelerator packages
-currently in LAMMPS, either as standard or user packages:
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR><TD ><A HREF = "accelerate_cuda.html">USER-CUDA</A> </TD><TD > for NVIDIA GPUs</TD></TR>
-<TR><TD ><A HREF = "accelerate_gpu.html">GPU</A> </TD><TD > for NVIDIA GPUs as well as OpenCL support</TD></TR>
-<TR><TD ><A HREF = "accelerate_intel.html">USER-INTEL</A> </TD><TD > for Intel CPUs and Intel Xeon Phi</TD></TR>
-<TR><TD ><A HREF = "accelerate_kokkos.html">KOKKOS</A> </TD><TD > for GPUs, Intel Xeon Phi, and OpenMP threading</TD></TR>
-<TR><TD ><A HREF = "accelerate_omp.html">USER-OMP</A> </TD><TD > for OpenMP threading</TD></TR>
-<TR><TD ><A HREF = "accelerate_opt.html">OPT</A> </TD><TD > generic CPU optimizations 
-</TD></TR></TABLE></DIV>
-
-<P>Any accelerated style has the same name as the corresponding standard
-style, except that a suffix is appended.  Otherwise, the syntax for
-the command that uses the style is identical, their functionality is
-the same, and the numerical results it produces should also be the
-same, except for precision and round-off effects.
-</P>
-<P>For example, all of these styles are accelerated variants of the
-Lennard-Jones <A HREF = "pair_lj.html">pair_style lj/cut</A>:
-</P>
-<UL><LI><A HREF = "pair_lj.html">pair_style lj/cut/cuda</A>
-<LI><A HREF = "pair_lj.html">pair_style lj/cut/gpu</A>
-<LI><A HREF = "pair_lj.html">pair_style lj/cut/intel</A>
-<LI><A HREF = "pair_lj.html">pair_style lj/cut/kk</A>
-<LI><A HREF = "pair_lj.html">pair_style lj/cut/omp</A>
-<LI><A HREF = "pair_lj.html">pair_style lj/cut/opt</A> 
-</UL>
-<P>To see what accelerate styles are currently available, see
-<A HREF = "Section_commands.html#cmd_5">Section_commands 5</A> of the manual.  The
-doc pages for individual commands (e.g. <A HREF = "pair_lj.html">pair lj/cut</A> or
-<A HREF = "fix_nve.html">fix nve</A>) also list any accelerated variants available
-for that style.
-</P>
-<P>To use an accelerator package in LAMMPS, and one or more of the styles
-it provides, follow these general steps.  Details vary from package to
-package and are explained in the individual accelerator doc pages,
-listed above:
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR><TD >build the accelerator library </TD><TD >  only for USER-CUDA and GPU packages </TD></TR>
-<TR><TD >install the accelerator package </TD><TD >  make yes-opt, make yes-user-intel, etc </TD></TR>
-<TR><TD >add compile/link flags to Makefile.machine </TD><TD >  in src/MAKE, <br>  only for USER-INTEL, KOKKOS, USER-OMP packages </TD></TR>
-<TR><TD >re-build LAMMPS </TD><TD >  make machine </TD></TR>
-<TR><TD >run a LAMMPS simulation </TD><TD >  lmp_machine < in.script </TD></TR>
-<TR><TD >enable the accelerator package </TD><TD >  via "-c on" and "-k on" <A HREF = "Section_start.html#start_7">command-line switches</A>, <br>  only for USER-CUDA and KOKKOS packages </TD></TR>
-<TR><TD >set any needed options for the package </TD><TD >  via "-pk" <A HREF = "Section_start.html#start_7">command-line switch</A> or  <A HREF = "package.html">package</A> command, <br>  only if defaults need to be changed </TD></TR>
-<TR><TD >use accelerated styles in your input script </TD><TD >  via "-sf" <A HREF = "Section_start.html#start_7">command-line switch</A> or  <A HREF = "suffix.html">suffix</A> command 
-</TD></TR></TABLE></DIV>
-
-<P>The first 4 steps can be done as a single command, using the
-src/Make.py tool.  The Make.py tool is discussed in <A HREF = "Section_start.html#start_4">Section
-2.4</A> of the manual, and its use is
-illustrated in the individual accelerator sections.  Typically these
-steps only need to be done once, to create an executable that uses one
-or more accelerator packages.
-</P>
-<P>The last 4 steps can all be done from the command-line when LAMMPS is
-launched, without changing your input script, as illustrated in the
-individual accelerator sections.  Or you can add
-<A HREF = "package.html">package</A> and <A HREF = "suffix.html">suffix</A> commands to your input
-script.
-</P>
-<P>IMPORTANT NOTE: With a few exceptions, you can build a single LAMMPS
-executable with all its accelerator packages installed.  Note that the
-USER-INTEL and KOKKOS packages require you to choose one of their
-options when building.  I.e. CPU or Phi for USER-INTEL.  OpenMP, Cuda,
-or Phi for KOKKOS.  Here are the exceptions; you cannot build a single
-executable with:
-</P>
-<UL><LI>both the USER-INTEL Phi and KOKKOS Phi options
-<LI>the USER-INTEL Phi or Kokkos Phi option, and either the USER-CUDA or GPU packages 
-</UL>
-<P>See the examples/accelerate/README and make.list files for sample
-Make.py commands that build LAMMPS with any or all of the accelerator
-packages.  As an example, here is a command that builds with all the
-GPU related packages installed (USER-CUDA, GPU, KOKKOS with Cuda),
-including settings to build the needed auxiliary USER-CUDA and GPU
-libraries for Kepler GPUs:
-</P>
-<PRE>Make.py -j 16 -p omp gpu cuda kokkos -cc nvcc wrap=mpi   -cuda mode=double arch=35 -gpu mode=double arch=35 \  -kokkos cuda arch=35 lib-all file mpi 
-</PRE>
-<P>The examples/accelerate directory also has input scripts that can be
-used with all of the accelerator packages.  See its README file for
-details.
-</P>
-<P>Likewise, the bench directory has FERMI and KEPLER and PHI
-sub-directories with Make.py commands and input scripts for using all
-the accelerator packages on various machines.  See the README files in
-those dirs.
-</P>
-<P>As mentioned above, the <A HREF = "http://lammps.sandia.gov/bench.html">Benchmark
-page</A> of the LAMMPS web site gives
-performance results for the various accelerator packages for several
-of the standard LAMMPS benchmark problems, as a function of problem
-size and number of compute nodes, on different hardware platforms.
-</P>
-<P>Here is a brief summary of what the various packages provide.  Details
-are in the individual accelerator sections.
-</P>
-<UL><LI>Styles with a "cuda" or "gpu" suffix are part of the USER-CUDA or GPU
-packages, and can be run on NVIDIA GPUs.  The speed-up on a GPU
-depends on a variety of factors, discussed in the accelerator
-sections. 
-
-<LI>Styles with an "intel" suffix are part of the USER-INTEL
-package. These styles support vectorized single and mixed precision
-calculations, in addition to full double precision.  In extreme cases,
-this can provide speedups over 3.5x on CPUs.  The package also
-supports acceleration in "offload" mode to Intel(R) Xeon Phi(TM)
-coprocessors.  This can result in additional speedup over 2x depending
-on the hardware configuration. 
-
-<LI>Styles with a "kk" suffix are part of the KOKKOS package, and can be
-run using OpenMP on multicore CPUs, on an NVIDIA GPU, or on an Intel
-Xeon Phi in "native" mode.  The speed-up depends on a variety of
-factors, as discussed on the KOKKOS accelerator page. 
-
-<LI>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. 
-
-<LI>Styles with an "opt" suffix are part of the OPT package and typically
-speed-up the pairwise calculations of your simulation by 5-25% on a
-CPU. 
-</UL>
-<P>The individual accelerator package doc pages explain:
-</P>
-<UL><LI>what hardware and software the accelerated package requires
-<LI>how to build LAMMPS with the accelerated package
-<LI>how to run with the accelerated package either via command-line switches or modifying the input script
-<LI>speed-ups to expect
-<LI>guidelines for best performance
-<LI>restrictions 
-</UL>
-<HR>
-
-<H4><A NAME = "acc_4"></A>5.4 Comparison of various accelerator packages 
-</H4>
-<P>NOTE: this section still needs to be re-worked with additional KOKKOS
-and USER-INTEL information.
-</P>
-<P>The next section compares and contrasts the various accelerator
-options, since there are multiple ways to perform OpenMP threading,
-run on GPUs, and run on Intel Xeon Phi coprocessors.
-</P>
-<P>All 3 of these packages accelerate a LAMMPS calculation using NVIDIA
-hardware, but they do it in different ways.
-</P>
-<P>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.
-</P>
-<P><B>Guidelines for using each package optimally:</B>
-</P>
-<UL><LI>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. 
-
-<LI>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. 
-
-<LI>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. 
-
-<LI>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. 
-
-<LI>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. 
-</UL>
-<P><B>Differences between the two packages:</B>
-</P>
-<UL><LI>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. 
-
-<LI>The USER-CUDA package does not support acceleration for minimization. 
-
-<LI>The USER-CUDA package does not support hybrid pair styles. 
-
-<LI>The USER-CUDA package can order atoms in the neighbor list differently
-from run to run resulting in a different order for force accumulation. 
-
-<LI>The USER-CUDA package has a limit on the number of atom types that can be
-used in a simulation. 
-
-<LI>The GPU package requires neighbor lists to be built on the CPU when using
-exclusion lists or a triclinic simulation box. 
-
-<LI>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. 
-</UL>
-<P><B>Examples:</B>
-</P>
-<P>The LAMMPS distribution has two directories with sample input scripts
-for the GPU and USER-CUDA packages.
-</P>
-<UL><LI>lammps/examples/gpu = GPU package files
-<LI>lammps/examples/USER/cuda = USER-CUDA package files 
-</UL>
-<P>These contain input scripts for identical systems, so they can be used
-to benchmark the performance of both packages on your system.
-</P>
-</HTML>
--- a/doc/Section_accelerate.txt
+++ b/doc/Section_accelerate.txt
@ -1,397 +0,0 @@
-"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.
-
-There are two thrusts to the discussion that follows.  The
-first is using code options that implement alternate algorithms
-that can speed-up a simulation.  The second is to use one
-of the several accelerator packages provided with LAMMPS that
-contain code optimized for certain kinds of hardware, including
-multi-core CPUs, GPUs, and Intel Xeon Phi coprocessors.
-
-5.1 "Measuring performance"_#acc_1 :ulb,l
-5.2 "Algorithms and code options to boost performace"_#acc_2 :l
-5.3 "Accelerator packages with optimized styles"_#acc_3 :l
-    5.3.1 "USER-CUDA package"_accelerate_cuda.html :ulb,l
-    5.3.2 "GPU package"_accelerate_gpu.html :l
-    5.3.3 "USER-INTEL package"_accelerate_intel.html :l
-    5.3.4 "KOKKOS package"_accelerate_kokkos.html :l
-    5.3.5 "USER-OMP package"_accelerate_omp.html :l
-    5.3.6 "OPT package"_accelerate_opt.html :l,ule
-5.4 "Comparison of various accelerator packages"_#acc_4 :l,ule
-
-The "Benchmark page"_http://lammps.sandia.gov/bench.html of the LAMMPS
-web site gives performance results for the various accelerator
-packages discussed in Section 5.2, for several of the standard LAMMPS
-benchmark problems, as a function of problem size and number of
-compute nodes, on different hardware platforms.
-
-:line
-:line
-
-5.1 Measuring performance :h4,link(acc_1)
-
-Before trying to make your simulation run faster, you should
-understand how it currently performs and where the bottlenecks are.
-
-The best way to do this is run the your system (actual number of
-atoms) for a modest number of timesteps (say 100 steps) on several
-different processor counts, including a single processor if possible.
-Do this for an equilibrium version of your system, so that the
-100-step timings are representative of a much longer run.  There is
-typically no need to run for 1000s of timesteps to get accurate
-timings; you can simply extrapolate from short runs.
-
-For the set of runs, look at the timing data printed to the screen and
-log file at the end of each LAMMPS run.  "This
-section"_Section_start.html#start_8 of the manual has an overview.
-
-Running on one (or a few processors) should give a good estimate of
-the serial performance and what portions of the timestep are taking
-the most time.  Running the same problem on a few different processor
-counts should give an estimate of parallel scalability.  I.e. if the
-simulation runs 16x faster on 16 processors, its 100% parallel
-efficient; if it runs 8x faster on 16 processors, it's 50% efficient.
-
-The most important data to look at in the timing info is the timing
-breakdown and relative percentages.  For example, trying different
-options for speeding up the long-range solvers will have little impact
-if they only consume 10% of the run time.  If the pairwise time is
-dominating, you may want to look at GPU or OMP versions of the pair
-style, as discussed below.  Comparing how the percentages change as
-you increase the processor count gives you a sense of how different
-operations within the timestep are scaling.  Note that if you are
-running with a Kspace solver, there is additional output on the
-breakdown of the Kspace time.  For PPPM, this includes the fraction
-spent on FFTs, which can be communication intensive.
-
-Another important detail in the timing info are the histograms of
-atoms counts and neighbor counts.  If these vary widely across
-processors, you have a load-imbalance issue.  This often results in
-inaccurate relative timing data, because processors have to wait when
-communication occurs for other processors to catch up.  Thus the
-reported times for "Communication" or "Other" may be higher than they
-really are, due to load-imbalance.  If this is an issue, you can
-uncomment the MPI_Barrier() lines in src/timer.cpp, and recompile
-LAMMPS, to obtain synchronized timings.
-
-:line
-
-5.2 General strategies :h4,link(acc_2)
-
-NOTE: this section 5.2 is still a work in progress
-
-Here is a list of general ideas for improving simulation performance.
-Most of them are only applicable to certain models and certain
-bottlenecks in the current performance, so let the timing data you
-generate be your guide.  It is hard, if not impossible, to predict how
-much difference these options will make, since it is a function of
-problem size, number of processors used, and your machine.  There is
-no substitute for identifying performance bottlenecks, and trying out
-various options.
-
-rRESPA
-2-FFT PPPM
-Staggered PPPM
-single vs double PPPM
-partial charge PPPM
-verlet/split run style
-processor command for proc layout and numa layout
-load-balancing: balance and fix balance :ul
-
-2-FFT PPPM, also called {analytic differentiation} or {ad} PPPM, uses
-2 FFTs instead of the 4 FFTs used by the default {ik differentiation}
-PPPM. However, 2-FFT PPPM also requires a slightly larger mesh size to
-achieve the same accuracy as 4-FFT PPPM. For problems where the FFT
-cost is the performance bottleneck (typically large problems running
-on many processors), 2-FFT PPPM may be faster than 4-FFT PPPM.
-  
-Staggered PPPM performs calculations using two different meshes, one
-shifted slightly with respect to the other.  This can reduce force
-aliasing errors and increase the accuracy of the method, but also
-doubles the amount of work required. For high relative accuracy, using
-staggered PPPM allows one to half the mesh size in each dimension as
-compared to regular PPPM, which can give around a 4x speedup in the
-kspace time. However, for low relative accuracy, using staggered PPPM
-gives little benefit and can be up to 2x slower in the kspace
-time. For example, the rhodopsin benchmark was run on a single
-processor, and results for kspace time vs. relative accuracy for the
-different methods are shown in the figure below.  For this system,
-staggered PPPM (using ik differentiation) becomes useful when using a
-relative accuracy of slightly greater than 1e-5 and above.
-
-:c,image(JPG/rhodo_staggered.jpg)
-
-IMPORTANT NOTE: Using staggered PPPM may not give the same increase in
-accuracy of energy and pressure as it does in forces, so some caution
-must be used if energy and/or pressure are quantities of interest,
-such as when using a barostat.
-
-:line
-
-5.3 Packages with optimized styles :h4,link(acc_3)
-
-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.  Some require appropriate hardware
-to be present on your system, e.g. GPUs or Intel Xeon Phi
-coprocessors.
-
-All of these commands are in packages provided with LAMMPS.  An
-overview of packages is give in "Section
-packages"_Section_packages.html.  These are the accelerator packages
-currently in LAMMPS, either as standard or user packages:
-
-"USER-CUDA"_accelerate_cuda.html : for NVIDIA GPUs
-"GPU"_accelerate_gpu.html : for NVIDIA GPUs as well as OpenCL support
-"USER-INTEL"_accelerate_intel.html : for Intel CPUs and Intel Xeon Phi
-"KOKKOS"_accelerate_kokkos.html : for GPUs, Intel Xeon Phi, and OpenMP threading
-"USER-OMP"_accelerate_omp.html : for OpenMP threading
-"OPT"_accelerate_opt.html : generic CPU optimizations :tb(s=:)
-
-Any accelerated style has the same name as the corresponding standard
-style, except that a suffix is appended.  Otherwise, the syntax for
-the command that uses the style is identical, their functionality is
-the same, and the numerical results it produces should also be the
-same, except for precision and round-off effects.
-
-For example, all of these styles are accelerated variants of the
-Lennard-Jones "pair_style lj/cut"_pair_lj.html:
-
-"pair_style lj/cut/cuda"_pair_lj.html
-"pair_style lj/cut/gpu"_pair_lj.html
-"pair_style lj/cut/intel"_pair_lj.html
-"pair_style lj/cut/kk"_pair_lj.html
-"pair_style lj/cut/omp"_pair_lj.html
-"pair_style lj/cut/opt"_pair_lj.html :ul
-
-To see what accelerate styles are currently available, see
-"Section_commands 5"_Section_commands.html#cmd_5 of the manual.  The
-doc pages for individual commands (e.g. "pair lj/cut"_pair_lj.html or
-"fix nve"_fix_nve.html) also list any accelerated variants available
-for that style.
-
-To use an accelerator package in LAMMPS, and one or more of the styles
-it provides, follow these general steps.  Details vary from package to
-package and are explained in the individual accelerator doc pages,
-listed above:
-
-build the accelerator library |
-  only for USER-CUDA and GPU packages |
-install the accelerator package |
-  make yes-opt, make yes-user-intel, etc |
-add compile/link flags to Makefile.machine |
-  in src/MAKE, <br>
-  only for USER-INTEL, KOKKOS, USER-OMP packages |
-re-build LAMMPS |
-  make machine |
-run a LAMMPS simulation |
-  lmp_machine < in.script |
-enable the accelerator package |
-  via "-c on" and "-k on" "command-line switches"_Section_start.html#start_7, <br>
-  only for USER-CUDA and KOKKOS packages |
-set any needed options for the package |
-  via "-pk" "command-line switch"_Section_start.html#start_7 or
-  "package"_package.html command, <br>
-  only if defaults need to be changed |
-use accelerated styles in your input script |
-  via "-sf" "command-line switch"_Section_start.html#start_7 or
-  "suffix"_suffix.html command :tb(c=2,s=|)
-
-The first 4 steps can be done as a single command, using the
-src/Make.py tool.  The Make.py tool is discussed in "Section
-2.4"_Section_start.html#start_4 of the manual, and its use is
-illustrated in the individual accelerator sections.  Typically these
-steps only need to be done once, to create an executable that uses one
-or more accelerator packages.
-
-The last 4 steps can all be done from the command-line when LAMMPS is
-launched, without changing your input script, as illustrated in the
-individual accelerator sections.  Or you can add
-"package"_package.html and "suffix"_suffix.html commands to your input
-script.
-
-IMPORTANT NOTE: With a few exceptions, you can build a single LAMMPS
-executable with all its accelerator packages installed.  Note that the
-USER-INTEL and KOKKOS packages require you to choose one of their
-options when building.  I.e. CPU or Phi for USER-INTEL.  OpenMP, Cuda,
-or Phi for KOKKOS.  Here are the exceptions; you cannot build a single
-executable with:
-
-both the USER-INTEL Phi and KOKKOS Phi options
-the USER-INTEL Phi or Kokkos Phi option, and either the USER-CUDA or GPU packages :ul
-
-See the examples/accelerate/README and make.list files for sample
-Make.py commands that build LAMMPS with any or all of the accelerator
-packages.  As an example, here is a command that builds with all the
-GPU related packages installed (USER-CUDA, GPU, KOKKOS with Cuda),
-including settings to build the needed auxiliary USER-CUDA and GPU
-libraries for Kepler GPUs:
-
-Make.py -j 16 -p omp gpu cuda kokkos -cc nvcc wrap=mpi \
-  -cuda mode=double arch=35 -gpu mode=double arch=35 \\
-  -kokkos cuda arch=35 lib-all file mpi :pre
-
-The examples/accelerate directory also has input scripts that can be
-used with all of the accelerator packages.  See its README file for
-details.
-
-Likewise, the bench directory has FERMI and KEPLER and PHI
-sub-directories with Make.py commands and input scripts for using all
-the accelerator packages on various machines.  See the README files in
-those dirs.
-
-As mentioned above, the "Benchmark
-page"_http://lammps.sandia.gov/bench.html of the LAMMPS web site gives
-performance results for the various accelerator packages for several
-of the standard LAMMPS benchmark problems, as a function of problem
-size and number of compute nodes, on different hardware platforms.
-
-Here is a brief summary of what the various packages provide.  Details
-are in the individual accelerator sections.
-
-Styles with a "cuda" or "gpu" suffix are part of the USER-CUDA or GPU
-packages, and can be run on NVIDIA GPUs.  The speed-up on a GPU
-depends on a variety of factors, discussed in the accelerator
-sections. :ulb,l
-
-Styles with an "intel" suffix are part of the USER-INTEL
-package. These styles support vectorized single and mixed precision
-calculations, in addition to full double precision.  In extreme cases,
-this can provide speedups over 3.5x on CPUs.  The package also
-supports acceleration in "offload" mode to Intel(R) Xeon Phi(TM)
-coprocessors.  This can result in additional speedup over 2x depending
-on the hardware configuration. :l
-
-Styles with a "kk" suffix are part of the KOKKOS package, and can be
-run using OpenMP on multicore CPUs, on an NVIDIA GPU, or on an Intel
-Xeon Phi in "native" mode.  The speed-up depends on a variety of
-factors, as discussed on the KOKKOS accelerator page. :l
-
-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. :l
-
-Styles with an "opt" suffix are part of the OPT package and typically
-speed-up the pairwise calculations of your simulation by 5-25% on a
-CPU. :l,ule
-
-The individual accelerator package doc pages explain:
-
-what hardware and software the accelerated package requires
-how to build LAMMPS with the accelerated package
-how to run with the accelerated package either via command-line switches or modifying the input script
-speed-ups to expect
-guidelines for best performance
-restrictions :ul
-
-:line
-
-5.4 Comparison of various accelerator packages :h4,link(acc_4)
-
-NOTE: this section still needs to be re-worked with additional KOKKOS
-and USER-INTEL information.
-
-The next section compares and contrasts the various accelerator
-options, since there are multiple ways to perform OpenMP threading,
-run on GPUs, and run on Intel Xeon Phi coprocessors.
-
-All 3 of these 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 USER-CUDA package does not support acceleration for minimization. :l
-
-The USER-CUDA package does not support hybrid pair styles. :l
-
-The USER-CUDA package can order atoms in the neighbor list differently
-from run to run resulting in a different order for force accumulation. :l
-
-The USER-CUDA package has a limit on the number of atom types that can be
-used in a simulation. :l
-
-The GPU package requires neighbor lists to be built on the CPU when using
-exclusion lists or a triclinic simulation box. :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.
--- a/doc/Section_commands.html
+++ b/doc/Section_commands.html
@ -1,656 +0,0 @@
-<HTML>
-<CENTER><A HREF = "Section_start.html">Previous Section</A> - <A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> - <A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A> - <A HREF = "Section_packages.html">Next Section</A> 
-</CENTER>
-
-
-
-
-
-
-<HR>
-
-<H3>3. Commands 
-</H3>
-<P>This section describes how a LAMMPS input script is formatted and the
-input script commands used to define a LAMMPS simulation.
-</P>
-3.1 <A HREF = "#cmd_1">LAMMPS input script</A><BR>
-3.2 <A HREF = "#cmd_2">Parsing rules</A><BR>
-3.3 <A HREF = "#cmd_3">Input script structure</A><BR>
-3.4 <A HREF = "#cmd_4">Commands listed by category</A><BR>
-3.5 <A HREF = "#cmd_5">Commands listed alphabetically</A> <BR>
-
-<HR>
-
-<HR>
-
-<A NAME = "cmd_1"></A><H4>3.1 LAMMPS input script 
-</H4>
-<P>LAMMPS executes by reading commands from a input script (text file),
-one line at a time.  When the input script ends, LAMMPS exits.  Each
-command causes LAMMPS to take some action.  It may set an internal
-variable, read in a file, or run a simulation.  Most commands have
-default settings, which means you only need to use the command if you
-wish to change the default.
-</P>
-<P>In many cases, the ordering of commands in an input script is not
-important.  However the following rules apply:
-</P>
-<P>(1) LAMMPS does not read your entire input script and then perform a
-simulation with all the settings.  Rather, the input script is read
-one line at a time and each command takes effect when it is read.
-Thus this sequence of commands:
-</P>
-<PRE>timestep 0.5 
-run      100 
-run      100 
-</PRE>
-<P>does something different than this sequence:
-</P>
-<PRE>run      100 
-timestep 0.5 
-run      100 
-</PRE>
-<P>In the first case, the specified timestep (0.5 fmsec) is used for two
-simulations of 100 timesteps each.  In the 2nd case, the default
-timestep (1.0 fmsec) is used for the 1st 100 step simulation and a 0.5
-fmsec timestep is used for the 2nd one.
-</P>
-<P>(2) Some commands are only valid when they follow other commands.  For
-example you cannot set the temperature of a group of atoms until atoms
-have been defined and a group command is used to define which atoms
-belong to the group.
-</P>
-<P>(3) Sometimes command B will use values that can be set by command A.
-This means command A must precede command B in the input script if it
-is to have the desired effect.  For example, the
-<A HREF = "read_data.html">read_data</A> command initializes the system by setting
-up the simulation box and assigning atoms to processors.  If default
-values are not desired, the <A HREF = "processors.html">processors</A> and
-<A HREF = "boundary.html">boundary</A> commands need to be used before read_data to
-tell LAMMPS how to map processors to the simulation box.
-</P>
-<P>Many input script errors are detected by LAMMPS and an ERROR or
-WARNING message is printed.  <A HREF = "Section_errors.html">This section</A> gives
-more information on what errors mean.  The documentation for each
-command lists restrictions on how the command can be used.
-</P>
-<HR>
-
-<A NAME = "cmd_2"></A><H4>3.2 Parsing rules 
-</H4>
-<P>Each non-blank line in the input script is treated as a command.
-LAMMPS commands are case sensitive.  Command names are lower-case, as
-are specified command arguments.  Upper case letters may be used in
-file names or user-chosen ID strings.
-</P>
-<P>Here is how each line in the input script is parsed by LAMMPS:
-</P>
-<P>(1) If the last printable character on the line is a "&" character,
-the command is assumed to continue on the next line.  The next line is
-concatenated to the previous line by removing the "&" character and
-line break.  This allows long commands to be continued across two or
-more lines.  See the discussion of triple quotes in (6) for how to
-continue a command across multiple line without using "&" characters.
-</P>
-<P>(2) All characters from the first "#" character onward are treated as
-comment and discarded.  See an exception in (6).  Note that a
-comment after a trailing "&" character will prevent the command from
-continuing on the next line.  Also note that for multi-line commands a
-single leading "#" will comment out the entire command.
-</P>
-<P>(3) The line is searched repeatedly for $ characters, which indicate
-variables that are replaced with a text string.  See an exception in
-(6).  
-</P>
-<P>If the $ is followed by curly brackets, then the variable name is the
-text inside the curly brackets.  If no curly brackets follow the $,
-then the variable name is the single character immediately following
-the $.  Thus ${myTemp} and $x refer to variable names "myTemp" and
-"x".
-</P>
-<P>How the variable is converted to a text string depends on what style
-of variable it is; see the <A HREF = "variable">variable</A> doc page for details.
-It can be a variable that stores multiple text strings, and return one
-of them.  The returned text string can be multiple "words" (space
-separated) which will then be interpreted as multiple arguments in the
-input command.  The variable can also store a numeric formula which
-will be evaluated and its numeric result returned as a string.
-</P>
-<P>As a special case, if the $ is followed by parenthesis, then the text
-inside the parenthesis is treated as an "immediate" variable and
-evaluated as an <A HREF = "variable.html">equal-style variable</A>.  This is a way
-to use numeric formulas in an input script without having to assign
-them to variable names.  For example, these 3 input script lines:
-</P>
-<PRE>variable X equal (xlo+xhi)/2+sqrt(v_area)
-region 1 block $X 2 INF INF EDGE EDGE
-variable X delete 
-</PRE>
-<P>can be replaced by 
-</P>
-<PRE>region 1 block $((xlo+xhi)/2+sqrt(v_area)) 2 INF INF EDGE EDGE 
-</PRE>
-<P>so that you do not have to define (or discard) a temporary variable X.
-</P>
-<P>Note that neither the curly-bracket or immediate form of variables can
-contain nested $ characters for other variables to substitute for.
-Thus you cannot do this:
-</P>
-<PRE>variable        a equal 2
-variable        b2 equal 4
-print           "B2 = ${b$a}" 
-</PRE>
-<P>Nor can you specify this $($x-1.0) for an immediate variable, but
-you could use $(v_x-1.0), since the latter is valid syntax for an
-<A HREF = "variable.html">equal-style variable</A>.
-</P>
-<P>See the <A HREF = "variable.html">variable</A> command for more details of how
-strings are assigned to variables and evaluated, and how they can be
-used in input script commands.
-</P>
-<P>(4) The line is broken into "words" separated by whitespace (tabs,
-spaces).  Note that words can thus contain letters, digits,
-underscores, or punctuation characters.
-</P>
-<P>(5) The first word is the command name.  All successive words in the
-line are arguments.
-</P>
-<P>(6) If you want text with spaces to be treated as a single argument,
-it can be enclosed in either single or double or triple quotes.  A
-long single argument enclosed in single or double quotes can span
-multiple lines if the "&" character is used, as described above.  When
-the lines are concatenated together (and the "&" characters and line
-breaks removed), the text will become a single line.  If you want
-multiple lines of an argument to retain their line breaks, the text
-can be enclosed in triple quotes, in which case "&" characters are not
-needed.  For example:
-</P>
-<PRE>print "Volume = $v"
-print 'Volume = $v'
-if "$<I>steps</I> > 1000" then quit
-variable a string "red green blue &
-                   purple orange cyan"
-print """
-System volume = $v
-System temperature = $t
-""" 
-</PRE>
-<P>In each case, the single, double, or triple quotes are removed when
-the single argument they enclose is stored internally.
-</P>
-<P>See the <A HREF = "dump_modify.html">dump modify format</A>, <A HREF = "print.html">print</A>,
-<A HREF = "if.html">if</A>, and <A HREF = "python.html">python</A> commands for examples.
-</P>
-<P>A "#" or "$" character that is between quotes will not be treated as a
-comment indicator in (2) or substituted for as a variable in (3).
-</P>
-<P>IMPORTANT NOTE: If the argument is itself a command that requires a
-quoted argument (e.g. using a <A HREF = "print.html">print</A> command as part of an
-<A HREF = "if.html">if</A> or <A HREF = "run.html">run every</A> command), then single, double, or
-triple quotes can be nested in the usual manner.  See the doc pages
-for those commands for examples.  Only one of level of nesting is
-allowed, but that should be sufficient for most use cases.
-</P>
-<HR>
-
-<H4><A NAME = "cmd_3"></A>3.3 Input script structure 
-</H4>
-<P>This section describes the structure of a typical LAMMPS input script.
-The "examples" directory in the LAMMPS distribution contains many
-sample input scripts; the corresponding problems are discussed in
-<A HREF = "Section_example.html">Section_example</A>, and animated on the <A HREF = "http://lammps.sandia.gov">LAMMPS
-WWW Site</A>.
-</P>
-<P>A LAMMPS input script typically has 4 parts:
-</P>
-<OL><LI>Initialization
-<LI>Atom definition
-<LI>Settings
-<LI>Run a simulation 
-</OL>
-<P>The last 2 parts can be repeated as many times as desired.  I.e. run a
-simulation, change some settings, run some more, etc.  Each of the 4
-parts is now described in more detail.  Remember that almost all the
-commands need only be used if a non-default value is desired.
-</P>
-<P>(1) Initialization
-</P>
-<P>Set parameters that need to be defined before atoms are created or
-read-in from a file.
-</P>
-<P>The relevant commands are <A HREF = "units.html">units</A>,
-<A HREF = "dimension.html">dimension</A>, <A HREF = "newton.html">newton</A>,
-<A HREF = "processors.html">processors</A>, <A HREF = "boundary.html">boundary</A>,
-<A HREF = "atom_style.html">atom_style</A>, <A HREF = "atom_modify.html">atom_modify</A>.
-</P>
-<P>If force-field parameters appear in the files that will be read, these
-commands tell LAMMPS what kinds of force fields are being used:
-<A HREF = "pair_style.html">pair_style</A>, <A HREF = "bond_style.html">bond_style</A>,
-<A HREF = "angle_style.html">angle_style</A>, <A HREF = "dihedral_style.html">dihedral_style</A>,
-<A HREF = "improper_style.html">improper_style</A>.
-</P>
-<P>(2) Atom definition
-</P>
-<P>There are 3 ways to define atoms in LAMMPS.  Read them in from a data
-or restart file via the <A HREF = "read_data.html">read_data</A> or
-<A HREF = "read_restart.html">read_restart</A> commands.  These files can contain
-molecular topology information.  Or create atoms on a lattice (with no
-molecular topology), using these commands: <A HREF = "lattice.html">lattice</A>,
-<A HREF = "region.html">region</A>, <A HREF = "create_box.html">create_box</A>,
-<A HREF = "create_atoms.html">create_atoms</A>.  The entire set of atoms can be
-duplicated to make a larger simulation using the
-<A HREF = "replicate.html">replicate</A> command.
-</P>
-<P>(3) Settings
-</P>
-<P>Once atoms and molecular topology are defined, a variety of settings
-can be specified: force field coefficients, simulation parameters,
-output options, etc.
-</P>
-<P>Force field coefficients are set by these commands (they can also be
-set in the read-in files): <A HREF = "pair_coeff.html">pair_coeff</A>,
-<A HREF = "bond_coeff.html">bond_coeff</A>, <A HREF = "angle_coeff.html">angle_coeff</A>,
-<A HREF = "dihedral_coeff.html">dihedral_coeff</A>,
-<A HREF = "improper_coeff.html">improper_coeff</A>,
-<A HREF = "kspace_style.html">kspace_style</A>, <A HREF = "dielectric.html">dielectric</A>,
-<A HREF = "special_bonds.html">special_bonds</A>.
-</P>
-<P>Various simulation parameters are set by these commands:
-<A HREF = "neighbor.html">neighbor</A>, <A HREF = "neigh_modify.html">neigh_modify</A>,
-<A HREF = "group.html">group</A>, <A HREF = "timestep.html">timestep</A>,
-<A HREF = "reset_timestep.html">reset_timestep</A>, <A HREF = "run_style.html">run_style</A>,
-<A HREF = "min_style.html">min_style</A>, <A HREF = "min_modify.html">min_modify</A>.
-</P>
-<P>Fixes impose a variety of boundary conditions, time integration, and
-diagnostic options.  The <A HREF = "fix.html">fix</A> command comes in many flavors.
-</P>
-<P>Various computations can be specified for execution during a
-simulation using the <A HREF = "compute.html">compute</A>,
-<A HREF = "compute_modify.html">compute_modify</A>, and <A HREF = "variable.html">variable</A>
-commands.
-</P>
-<P>Output options are set by the <A HREF = "thermo.html">thermo</A>, <A HREF = "dump.html">dump</A>,
-and <A HREF = "restart.html">restart</A> commands.
-</P>
-<P>(4) Run a simulation
-</P>
-<P>A molecular dynamics simulation is run using the <A HREF = "run.html">run</A>
-command.  Energy minimization (molecular statics) is performed using
-the <A HREF = "minimize.html">minimize</A> command.  A parallel tempering
-(replica-exchange) simulation can be run using the
-<A HREF = "temper.html">temper</A> command.
-</P>
-<HR>
-
-<A NAME = "cmd_4"></A><H4>3.4 Commands listed by category 
-</H4>
-<P>This section lists all LAMMPS commands, grouped by category.  The
-<A HREF = "#cmd_5">next section</A> lists the same commands alphabetically.  Note
-that some style options for some commands are part of specific LAMMPS
-packages, which means they cannot be used unless the package was
-included when LAMMPS was built.  Not all packages are included in a
-default LAMMPS build.  These dependencies are listed as Restrictions
-in the command's documentation.
-</P>
-<P>Initialization:
-</P>
-<P><A HREF = "atom_modify.html">atom_modify</A>, <A HREF = "atom_style.html">atom_style</A>,
-<A HREF = "boundary.html">boundary</A>, <A HREF = "dimension.html">dimension</A>,
-<A HREF = "newton.html">newton</A>, <A HREF = "processors.html">processors</A>, <A HREF = "units.html">units</A>
-</P>
-<P>Atom definition:
-</P>
-<P><A HREF = "create_atoms.html">create_atoms</A>, <A HREF = "create_box.html">create_box</A>,
-<A HREF = "lattice.html">lattice</A>, <A HREF = "read_data.html">read_data</A>,
-<A HREF = "read_dump.html">read_dump</A>, <A HREF = "read_restart.html">read_restart</A>,
-<A HREF = "region.html">region</A>, <A HREF = "replicate.html">replicate</A>
-</P>
-<P>Force fields:
-</P>
-<P><A HREF = "angle_coeff.html">angle_coeff</A>, <A HREF = "angle_style.html">angle_style</A>,
-<A HREF = "bond_coeff.html">bond_coeff</A>, <A HREF = "bond_style.html">bond_style</A>,
-<A HREF = "dielectric.html">dielectric</A>, <A HREF = "dihedral_coeff.html">dihedral_coeff</A>,
-<A HREF = "dihedral_style.html">dihedral_style</A>,
-<A HREF = "improper_coeff.html">improper_coeff</A>,
-<A HREF = "improper_style.html">improper_style</A>,
-<A HREF = "kspace_modify.html">kspace_modify</A>, <A HREF = "kspace_style.html">kspace_style</A>,
-<A HREF = "pair_coeff.html">pair_coeff</A>, <A HREF = "pair_modify.html">pair_modify</A>,
-<A HREF = "pair_style.html">pair_style</A>, <A HREF = "pair_write.html">pair_write</A>,
-<A HREF = "special_bonds.html">special_bonds</A>
-</P>
-<P>Settings:
-</P>
-<P><A HREF = "comm_style.html">comm_style</A>, <A HREF = "group.html">group</A>, <A HREF = "mass.html">mass</A>,
-<A HREF = "min_modify.html">min_modify</A>, <A HREF = "min_style.html">min_style</A>,
-<A HREF = "neigh_modify.html">neigh_modify</A>, <A HREF = "neighbor.html">neighbor</A>,
-<A HREF = "reset_timestep.html">reset_timestep</A>, <A HREF = "run_style.html">run_style</A>,
-<A HREF = "set.html">set</A>, <A HREF = "timestep.html">timestep</A>, <A HREF = "velocity.html">velocity</A>
-</P>
-<P>Fixes:
-</P>
-<P><A HREF = "fix.html">fix</A>, <A HREF = "fix_modify.html">fix_modify</A>, <A HREF = "unfix.html">unfix</A>
-</P>
-<P>Computes:
-</P>
-<P><A HREF = "compute.html">compute</A>, <A HREF = "compute_modify.html">compute_modify</A>,
-<A HREF = "uncompute.html">uncompute</A>
-</P>
-<P>Output:
-</P>
-<P><A HREF = "dump.html">dump</A>, <A HREF = "dump_image.html">dump image</A>,
-<A HREF = "dump_modify.html">dump_modify</A>, <A HREF = "dump_image.html">dump movie</A>,
-<A HREF = "restart.html">restart</A>, <A HREF = "thermo.html">thermo</A>,
-<A HREF = "thermo_modify.html">thermo_modify</A>, <A HREF = "thermo_style.html">thermo_style</A>,
-<A HREF = "undump.html">undump</A>, <A HREF = "write_data.html">write_data</A>,
-<A HREF = "write_dump.html">write_dump</A>, <A HREF = "write_restart.html">write_restart</A>
-</P>
-<P>Actions:
-</P>
-<P><A HREF = "delete_atoms.html">delete_atoms</A>, <A HREF = "delete_bonds.html">delete_bonds</A>,
-<A HREF = "displace_atoms.html">displace_atoms</A>, <A HREF = "change_box.html">change_box</A>,
-<A HREF = "minimize.html">minimize</A>, <A HREF = "neb.html">neb</A> <A HREF = "prd.html">prd</A>,
-<A HREF = "rerun.html">rerun</A>, <A HREF = "run.html">run</A>, <A HREF = "temper.html">temper</A>
-</P>
-<P>Miscellaneous:
-</P>
-<P><A HREF = "clear.html">clear</A>, <A HREF = "echo.html">echo</A>, <A HREF = "if.html">if</A>,
-<A HREF = "include.html">include</A>, <A HREF = "jump.html">jump</A>, <A HREF = "label.html">label</A>,
-<A HREF = "log.html">log</A>, <A HREF = "next.html">next</A>, <A HREF = "print.html">print</A>,
-<A HREF = "shell.html">shell</A>, <A HREF = "variable.html">variable</A>
-</P>
-<HR>
-
-<H4><A NAME = "cmd_5"></A><A NAME = "comm"></A>3.5 Individual commands 
-</H4>
-<P>This section lists all LAMMPS commands alphabetically, with a separate
-listing below of styles within certain commands.  The <A HREF = "#cmd_4">previous
-section</A> 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
-in the command's documentation.
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR ALIGN="center"><TD ><A HREF = "angle_coeff.html">angle_coeff</A></TD><TD ><A HREF = "angle_style.html">angle_style</A></TD><TD ><A HREF = "atom_modify.html">atom_modify</A></TD><TD ><A HREF = "atom_style.html">atom_style</A></TD><TD ><A HREF = "balance.html">balance</A></TD><TD ><A HREF = "bond_coeff.html">bond_coeff</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "bond_style.html">bond_style</A></TD><TD ><A HREF = "boundary.html">boundary</A></TD><TD ><A HREF = "box.html">box</A></TD><TD ><A HREF = "change_box.html">change_box</A></TD><TD ><A HREF = "clear.html">clear</A></TD><TD ><A HREF = "comm_modify.html">comm_modify</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "comm_style.html">comm_style</A></TD><TD ><A HREF = "compute.html">compute</A></TD><TD ><A HREF = "compute_modify.html">compute_modify</A></TD><TD ><A HREF = "create_atoms.html">create_atoms</A></TD><TD ><A HREF = "create_bonds.html">create_bonds</A></TD><TD ><A HREF = "create_box.html">create_box</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "delete_atoms.html">delete_atoms</A></TD><TD ><A HREF = "delete_bonds.html">delete_bonds</A></TD><TD ><A HREF = "dielectric.html">dielectric</A></TD><TD ><A HREF = "dihedral_coeff.html">dihedral_coeff</A></TD><TD ><A HREF = "dihedral_style.html">dihedral_style</A></TD><TD ><A HREF = "dimension.html">dimension</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "displace_atoms.html">displace_atoms</A></TD><TD ><A HREF = "dump.html">dump</A></TD><TD ><A HREF = "dump_image.html">dump image</A></TD><TD ><A HREF = "dump_modify.html">dump_modify</A></TD><TD ><A HREF = "dump_image.html">dump movie</A></TD><TD ><A HREF = "echo.html">echo</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "fix.html">fix</A></TD><TD ><A HREF = "fix_modify.html">fix_modify</A></TD><TD ><A HREF = "group.html">group</A></TD><TD ><A HREF = "if.html">if</A></TD><TD ><A HREF = "improper_coeff.html">improper_coeff</A></TD><TD ><A HREF = "improper_style.html">improper_style</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "include.html">include</A></TD><TD ><A HREF = "jump.html">jump</A></TD><TD ><A HREF = "kspace_modify.html">kspace_modify</A></TD><TD ><A HREF = "kspace_style.html">kspace_style</A></TD><TD ><A HREF = "label.html">label</A></TD><TD ><A HREF = "lattice.html">lattice</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "log.html">log</A></TD><TD ><A HREF = "mass.html">mass</A></TD><TD ><A HREF = "minimize.html">minimize</A></TD><TD ><A HREF = "min_modify.html">min_modify</A></TD><TD ><A HREF = "min_style.html">min_style</A></TD><TD ><A HREF = "molecule.html">molecule</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "neb.html">neb</A></TD><TD ><A HREF = "neigh_modify.html">neigh_modify</A></TD><TD ><A HREF = "neighbor.html">neighbor</A></TD><TD ><A HREF = "newton.html">newton</A></TD><TD ><A HREF = "next.html">next</A></TD><TD ><A HREF = "package.html">package</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "pair_coeff.html">pair_coeff</A></TD><TD ><A HREF = "pair_modify.html">pair_modify</A></TD><TD ><A HREF = "pair_style.html">pair_style</A></TD><TD ><A HREF = "pair_write.html">pair_write</A></TD><TD ><A HREF = "partition.html">partition</A></TD><TD ><A HREF = "prd.html">prd</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "print.html">print</A></TD><TD ><A HREF = "processors.html">processors</A></TD><TD ><A HREF = "python.html">python</A></TD><TD ><A HREF = "quit.html">quit</A></TD><TD ><A HREF = "read_data.html">read_data</A></TD><TD ><A HREF = "read_dump.html">read_dump</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "read_restart.html">read_restart</A></TD><TD ><A HREF = "region.html">region</A></TD><TD ><A HREF = "replicate.html">replicate</A></TD><TD ><A HREF = "rerun.html">rerun</A></TD><TD ><A HREF = "reset_timestep.html">reset_timestep</A></TD><TD ><A HREF = "restart.html">restart</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "run.html">run</A></TD><TD ><A HREF = "run_style.html">run_style</A></TD><TD ><A HREF = "set.html">set</A></TD><TD ><A HREF = "shell.html">shell</A></TD><TD ><A HREF = "special_bonds.html">special_bonds</A></TD><TD ><A HREF = "suffix.html">suffix</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "tad.html">tad</A></TD><TD ><A HREF = "temper.html">temper</A></TD><TD ><A HREF = "thermo.html">thermo</A></TD><TD ><A HREF = "thermo_modify.html">thermo_modify</A></TD><TD ><A HREF = "thermo_style.html">thermo_style</A></TD><TD ><A HREF = "timestep.html">timestep</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "uncompute.html">uncompute</A></TD><TD ><A HREF = "undump.html">undump</A></TD><TD ><A HREF = "unfix.html">unfix</A></TD><TD ><A HREF = "units.html">units</A></TD><TD ><A HREF = "variable.html">variable</A></TD><TD ><A HREF = "velocity.html">velocity</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "write_data.html">write_data</A></TD><TD ><A HREF = "write_dump.html">write_dump</A></TD><TD ><A HREF = "write_restart.html">write_restart</A> 
-</TD></TR></TABLE></DIV>
-
-<P>These are additional commands in USER packages, which can be used if
-<A HREF = "Section_start.html#start_3">LAMMPS is built with the appropriate
-package</A>.
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR ALIGN="center"><TD ><A HREF = "group2ndx.html">group2ndx</A> 
-</TD></TR></TABLE></DIV>
-
-<HR>
-
-<H4>Fix styles 
-</H4>
-<P>See the <A HREF = "fix.html">fix</A> command for one-line descriptions of each style
-or click on the style itself for a full description.  Some of the
-styles have accelerated versions, which can be used if LAMMPS is built
-with the <A HREF = "Section_accelerate.html">appropriate accelerated package</A>.
-This is indicated by additional letters in parenthesis: c = USER-CUDA,
-g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t = OPT.
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR ALIGN="center"><TD ><A HREF = "fix_adapt.html">adapt</A></TD><TD ><A HREF = "fix_addforce.html">addforce (c)</A></TD><TD ><A HREF = "fix_append_atoms.html">append/atoms</A></TD><TD ><A HREF = "fix_atom_swap.html">atom/swap</A></TD><TD ><A HREF = "fix_aveforce.html">aveforce (c)</A></TD><TD ><A HREF = "fix_ave_atom.html">ave/atom</A></TD><TD ><A HREF = "fix_ave_chunk.html">ave/chunk</A></TD><TD ><A HREF = "fix_ave_correlate.html">ave/correlate</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "fix_ave_histo.html">ave/histo</A></TD><TD ><A HREF = "fix_ave_spatial.html">ave/spatial</A></TD><TD ><A HREF = "fix_ave_time.html">ave/time</A></TD><TD ><A HREF = "fix_balance.html">balance</A></TD><TD ><A HREF = "fix_bond_break.html">bond/break</A></TD><TD ><A HREF = "fix_bond_create.html">bond/create</A></TD><TD ><A HREF = "fix_bond_swap.html">bond/swap</A></TD><TD ><A HREF = "fix_box_relax.html">box/relax</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "fix_deform.html">deform</A></TD><TD ><A HREF = "fix_deposit.html">deposit</A></TD><TD ><A HREF = "fix_drag.html">drag</A></TD><TD ><A HREF = "fix_dt_reset.html">dt/reset</A></TD><TD ><A HREF = "fix_efield.html">efield</A></TD><TD ><A HREF = "fix_enforce2d.html">enforce2d (c)</A></TD><TD ><A HREF = "fix_evaporate.html">evaporate</A></TD><TD ><A HREF = "fix_external.html">external</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "fix_freeze.html">freeze (c)</A></TD><TD ><A HREF = "fix_gcmc.html">gcmc</A></TD><TD ><A HREF = "fix_gld.html">gld</A></TD><TD ><A HREF = "fix_gravity.html">gravity (co)</A></TD><TD ><A HREF = "fix_heat.html">heat</A></TD><TD ><A HREF = "fix_indent.html">indent</A></TD><TD ><A HREF = "fix_langevin.html">langevin (k)</A></TD><TD ><A HREF = "fix_lineforce.html">lineforce</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "fix_momentum.html">momentum</A></TD><TD ><A HREF = "fix_move.html">move</A></TD><TD ><A HREF = "fix_msst.html">msst</A></TD><TD ><A HREF = "fix_neb.html">neb</A></TD><TD ><A HREF = "fix_nh.html">nph (o)</A></TD><TD ><A HREF = "fix_nphug.html">nphug (o)</A></TD><TD ><A HREF = "fix_nph_asphere.html">nph/asphere (o)</A></TD><TD ><A HREF = "fix_nph_sphere.html">nph/sphere (o)</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "fix_nh.html">npt (co)</A></TD><TD ><A HREF = "fix_npt_asphere.html">npt/asphere (o)</A></TD><TD ><A HREF = "fix_npt_sphere.html">npt/sphere (o)</A></TD><TD ><A HREF = "fix_nve.html">nve (cko)</A></TD><TD ><A HREF = "fix_nve_asphere.html">nve/asphere</A></TD><TD ><A HREF = "fix_nve_asphere_noforce.html">nve/asphere/noforce</A></TD><TD ><A HREF = "fix_nve_body.html">nve/body</A></TD><TD ><A HREF = "fix_nve_limit.html">nve/limit</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "fix_nve_line.html">nve/line</A></TD><TD ><A HREF = "fix_nve_noforce.html">nve/noforce</A></TD><TD ><A HREF = "fix_nve_sphere.html">nve/sphere (o)</A></TD><TD ><A HREF = "fix_nve_tri.html">nve/tri</A></TD><TD ><A HREF = "fix_nh.html">nvt (co)</A></TD><TD ><A HREF = "fix_nvt_asphere.html">nvt/asphere (o)</A></TD><TD ><A HREF = "fix_nvt_sllod.html">nvt/sllod (o)</A></TD><TD ><A HREF = "fix_nvt_sphere.html">nvt/sphere (o)</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "fix_oneway.html">oneway</A></TD><TD ><A HREF = "fix_orient_fcc.html">orient/fcc</A></TD><TD ><A HREF = "fix_planeforce.html">planeforce</A></TD><TD ><A HREF = "fix_poems.html">poems</A></TD><TD ><A HREF = "fix_pour.html">pour</A></TD><TD ><A HREF = "fix_press_berendsen.html">press/berendsen</A></TD><TD ><A HREF = "fix_print.html">print</A></TD><TD ><A HREF = "fix_property_atom.html">property/atom</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "fix_qeq_comb.html">qeq/comb (o)</A></TD><TD ><A HREF = "fix_qeq.html">qeq/dynamic</A></TD><TD ><A HREF = "fix_qeq.html">qeq/point</A></TD><TD ><A HREF = "fix_qeq.html">qeq/shielded</A></TD><TD ><A HREF = "fix_qeq.html">qeq/slater</A></TD><TD ><A HREF = "fix_reax_bonds.html">reax/bonds</A></TD><TD ><A HREF = "fix_recenter.html">recenter</A></TD><TD ><A HREF = "fix_restrain.html">restrain</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "fix_rigid.html">rigid (o)</A></TD><TD ><A HREF = "fix_rigid.html">rigid/nph (o)</A></TD><TD ><A HREF = "fix_rigid.html">rigid/npt (o)</A></TD><TD ><A HREF = "fix_rigid.html">rigid/nve (o)</A></TD><TD ><A HREF = "fix_rigid.html">rigid/nvt (o)</A></TD><TD ><A HREF = "fix_rigid.html">rigid/small (o)</A></TD><TD ><A HREF = "fix_rigid.html">rigid/small/nph</A></TD><TD ><A HREF = "fix_rigid.html">rigid/small/npt</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "fix_rigid.html">rigid/small/nve</A></TD><TD ><A HREF = "fix_rigid.html">rigid/small/nvt</A></TD><TD ><A HREF = "fix_setforce.html">setforce (c)</A></TD><TD ><A HREF = "fix_shake.html">shake (c)</A></TD><TD ><A HREF = "fix_spring.html">spring</A></TD><TD ><A HREF = "fix_spring_rg.html">spring/rg</A></TD><TD ><A HREF = "fix_spring_self.html">spring/self</A></TD><TD ><A HREF = "fix_srd.html">srd</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "fix_store_force.html">store/force</A></TD><TD ><A HREF = "fix_store_state.html">store/state</A></TD><TD ><A HREF = "fix_temp_berendsen.html">temp/berendsen (c)</A></TD><TD ><A HREF = "fix_temp_csvr.html">temp/csld</A></TD><TD ><A HREF = "fix_temp_csvr.html">temp/csvr</A></TD><TD ><A HREF = "fix_temp_rescale.html">temp/rescale (c)</A></TD><TD ><A HREF = "fix_tfmc.html">tfmc</A></TD><TD ><A HREF = "fix_thermal_conductivity.html">thermal/conductivity</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "fix_tmd.html">tmd</A></TD><TD ><A HREF = "fix_ttm.html">ttm</A></TD><TD ><A HREF = "fix_tune_kspace.html">tune/kspace</A></TD><TD ><A HREF = "fix_vector.html">vector</A></TD><TD ><A HREF = "fix_viscosity.html">viscosity</A></TD><TD ><A HREF = "fix_viscous.html">viscous (c)</A></TD><TD ><A HREF = "fix_wall.html">wall/colloid</A></TD><TD ><A HREF = "fix_wall_gran.html">wall/gran</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "fix_wall.html">wall/harmonic</A></TD><TD ><A HREF = "fix_wall.html">wall/lj1043</A></TD><TD ><A HREF = "fix_wall.html">wall/lj126</A></TD><TD ><A HREF = "fix_wall.html">wall/lj93</A></TD><TD ><A HREF = "fix_wall_piston.html">wall/piston</A></TD><TD ><A HREF = "fix_wall_reflect.html">wall/reflect</A></TD><TD ><A HREF = "fix_wall_region.html">wall/region</A></TD><TD ><A HREF = "fix_wall_srd.html">wall/srd</A> 
-</TD></TR></TABLE></DIV>
-
-<P>These are additional fix styles in USER packages, which can be used if
-<A HREF = "Section_start.html#start_3">LAMMPS is built with the appropriate
-package</A>.
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR ALIGN="center"><TD ><A HREF = "fix_adapt_fep.html">adapt/fep</A></TD><TD ><A HREF = "fix_addtorque.html">addtorque</A></TD><TD ><A HREF = "fix_atc.html">atc</A></TD><TD ><A HREF = "fix_ave_spatial_sphere.html">ave/spatial/sphere</A></TD><TD ><A HREF = "fix_colvars.html">colvars</A></TD><TD ><A HREF = "fix_gle.html">gle</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "fix_imd.html">imd</A></TD><TD ><A HREF = "fix_ipi.html">ipi</A></TD><TD ><A HREF = "fix_langevin_eff.html">langevin/eff</A></TD><TD ><A HREF = "fix_lb_fluid.html">lb/fluid</A></TD><TD ><A HREF = "fix_lb_momentum.html">lb/momentum</A></TD><TD ><A HREF = "fix_lb_pc.html">lb/pc</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "fix_lb_rigid_pc_sphere.html">lb/rigid/pc/sphere</A></TD><TD ><A HREF = "fix_lb_viscous.html">lb/viscous</A></TD><TD ><A HREF = "fix_meso.html">meso</A></TD><TD ><A HREF = "fix_meso_stationary.html">meso/stationary</A></TD><TD ><A HREF = "fix_nh_eff.html">nph/eff</A></TD><TD ><A HREF = "fix_nh_eff.html">npt/eff</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "fix_nve_eff.html">nve/eff</A></TD><TD ><A HREF = "fix_nh_eff.html">nvt/eff</A></TD><TD ><A HREF = "fix_nvt_sllod_eff.html">nvt/sllod/eff</A></TD><TD ><A HREF = "fix_phonon.html">phonon</A></TD><TD ><A HREF = "fix_pimd.html">pimd</A></TD><TD ><A HREF = "fix_qeq_reax.html">qeq/reax</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "fix_qmmm.html">qmmm</A></TD><TD ><A HREF = "fix_reax_bonds.html">reax/c/bonds</A></TD><TD ><A HREF = "fix_reaxc_species.html">reax/c/species</A></TD><TD ><A HREF = "fix_smd.html">smd</A></TD><TD ><A HREF = "fix_temp_rescale_eff.html">temp/rescale/eff</A></TD><TD ><A HREF = "fix_ti_rs.html">ti/rs</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "fix_ti_spring.html">ti/spring</A></TD><TD ><A HREF = "fix_ttm.html">ttm/mod</A> 
-</TD></TR></TABLE></DIV>
-
-<HR>
-
-<H4>Compute styles 
-</H4>
-<P>See the <A HREF = "compute.html">compute</A> command for one-line descriptions of
-each style or click on the style itself for a full description.  Some
-of the styles have accelerated versions, which can be used if LAMMPS
-is built with the <A HREF = "Section_accelerate.html">appropriate accelerated
-package</A>.  This is indicated by additional
-letters in parenthesis: c = USER-CUDA, g = GPU, i = USER-INTEL, k =
-KOKKOS, o = USER-OMP, t = OPT.
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR ALIGN="center"><TD ><A HREF = "compute_angle_local.html">angle/local</A></TD><TD ><A HREF = "compute_angmom_chunk.html">angmom/chunk</A></TD><TD ><A HREF = "compute_body_local.html">body/local</A></TD><TD ><A HREF = "compute_bond_local.html">bond/local</A></TD><TD ><A HREF = "compute_centro_atom.html">centro/atom</A></TD><TD ><A HREF = "compute_chunk_atom.html">chunk/atom</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "compute_cluster_atom.html">cluster/atom</A></TD><TD ><A HREF = "compute_cna_atom.html">cna/atom</A></TD><TD ><A HREF = "compute_com.html">com</A></TD><TD ><A HREF = "compute_com_chunk.html">com/chunk</A></TD><TD ><A HREF = "compute_contact_atom.html">contact/atom</A></TD><TD ><A HREF = "compute_coord_atom.html">coord/atom</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "compute_damage_atom.html">damage/atom</A></TD><TD ><A HREF = "compute_dihedral_local.html">dihedral/local</A></TD><TD ><A HREF = "compute_dilatation_atom.html">dilatation/atom</A></TD><TD ><A HREF = "compute_displace_atom.html">displace/atom</A></TD><TD ><A HREF = "compute_erotate_asphere.html">erotate/asphere</A></TD><TD ><A HREF = "compute_erotate_rigid.html">erotate/rigid</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "compute_erotate_sphere.html">erotate/sphere</A></TD><TD ><A HREF = "compute_erotate_sphere_atom.html">erotate/sphere/atom</A></TD><TD ><A HREF = "compute_event_displace.html">event/displace</A></TD><TD ><A HREF = "compute_group_group.html">group/group</A></TD><TD ><A HREF = "compute_gyration.html">gyration</A></TD><TD ><A HREF = "compute_gyration_chunk.html">gyration/chunk</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "compute_heat_flux.html">heat/flux</A></TD><TD ><A HREF = "compute_improper_local.html">improper/local</A></TD><TD ><A HREF = "compute_inertia_chunk.html">inertia/chunk</A></TD><TD ><A HREF = "compute_ke.html">ke</A></TD><TD ><A HREF = "compute_ke_atom.html">ke/atom</A></TD><TD ><A HREF = "compute_ke_rigid.html">ke/rigid</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "compute_msd.html">msd</A></TD><TD ><A HREF = "compute_msd_chunk.html">msd/chunk</A></TD><TD ><A HREF = "compute_msd_nongauss.html">msd/nongauss</A></TD><TD ><A HREF = "compute_omega_chunk.html">omega/chunk</A></TD><TD ><A HREF = "compute_pair.html">pair</A></TD><TD ><A HREF = "compute_pair_local.html">pair/local</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "compute_pe.html">pe (c)</A></TD><TD ><A HREF = "compute_pe_atom.html">pe/atom</A></TD><TD ><A HREF = "compute_plasticity_atom.html">plasticity/atom</A></TD><TD ><A HREF = "compute_pressure.html">pressure (c)</A></TD><TD ><A HREF = "compute_property_atom.html">property/atom</A></TD><TD ><A HREF = "compute_property_local.html">property/local</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "compute_property_chunk.html">property/chunk</A></TD><TD ><A HREF = "compute_rdf.html">rdf</A></TD><TD ><A HREF = "compute_reduce.html">reduce</A></TD><TD ><A HREF = "compute_reduce.html">reduce/region</A></TD><TD ><A HREF = "compute_slice.html">slice</A></TD><TD ><A HREF = "compute_sna.html">sna/atom</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "compute_sna.html">snad/atom</A></TD><TD ><A HREF = "compute_sna.html">snav/atom</A></TD><TD ><A HREF = "compute_stress_atom.html">stress/atom</A></TD><TD ><A HREF = "compute_temp.html">temp (c)</A></TD><TD ><A HREF = "compute_temp_asphere.html">temp/asphere</A></TD><TD ><A HREF = "compute_temp_com.html">temp/com</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "compute_temp_chunk.html">temp/chunk</A></TD><TD ><A HREF = "compute_temp_deform.html">temp/deform</A></TD><TD ><A HREF = "compute_temp_partial.html">temp/partial (c)</A></TD><TD ><A HREF = "compute_temp_profile.html">temp/profile</A></TD><TD ><A HREF = "compute_temp_ramp.html">temp/ramp</A></TD><TD ><A HREF = "compute_temp_region.html">temp/region</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "compute_temp_sphere.html">temp/sphere</A></TD><TD ><A HREF = "compute_ti.html">ti</A></TD><TD ><A HREF = "compute_torque_chunk.html">torque/chunk</A></TD><TD ><A HREF = "compute_vacf.html">vacf</A></TD><TD ><A HREF = "compute_vcm_chunk.html">vcm/chunk</A></TD><TD ><A HREF = "compute_voronoi_atom.html">voronoi/atom</A> 
-</TD></TR></TABLE></DIV>
-
-<P>These are additional compute styles in USER packages, which can be
-used if <A HREF = "Section_start.html#start_3">LAMMPS is built with the appropriate
-package</A>.
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR ALIGN="center"><TD ><A HREF = "compute_ackland_atom.html">ackland/atom</A></TD><TD ><A HREF = "compute_basal_atom.html">basal/atom</A></TD><TD ><A HREF = "compute_fep.html">fep</A></TD><TD ><A HREF = "compute_ke_eff.html">ke/eff</A></TD><TD ><A HREF = "compute_ke_atom_eff.html">ke/atom/eff</A></TD><TD ><A HREF = "compute_meso_e_atom.html">meso_e/atom</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "compute_meso_rho_atom.html">meso_rho/atom</A></TD><TD ><A HREF = "compute_meso_t_atom.html">meso_t/atom</A></TD><TD ><A HREF = "compute_temp_eff.html">temp/eff</A></TD><TD ><A HREF = "compute_temp_deform_eff.html">temp/deform/eff</A></TD><TD ><A HREF = "compute_temp_region_eff.html">temp/region/eff</A></TD><TD ><A HREF = "compute_temp_rotate.html">temp/rotate</A> 
-</TD></TR></TABLE></DIV>
-
-<HR>
-
-<H4>Pair_style potentials 
-</H4>
-<P>See the <A HREF = "pair_style.html">pair_style</A> command for an overview of pair
-potentials.  Click on the style itself for a full description.  Many
-of the styles have accelerated versions, which can be used if LAMMPS
-is built with the <A HREF = "Section_accelerate.html">appropriate accelerated
-package</A>.  This is indicated by additional
-letters in parenthesis: c = USER-CUDA, g = GPU, i = USER-INTEL, k =
-KOKKOS, o = USER-OMP, t = OPT.
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR ALIGN="center"><TD ><A HREF = "pair_none.html">none</A></TD><TD ><A HREF = "pair_hybrid.html">hybrid</A></TD><TD ><A HREF = "pair_hybrid.html">hybrid/overlay</A></TD><TD ><A HREF = "pair_adp.html">adp (o)</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "pair_airebo.html">airebo (o)</A></TD><TD ><A HREF = "pair_beck.html">beck (go)</A></TD><TD ><A HREF = "pair_body.html">body</A></TD><TD ><A HREF = "pair_bop.html">bop</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "pair_born.html">born (go)</A></TD><TD ><A HREF = "pair_born.html">born/coul/long (cgo)</A></TD><TD ><A HREF = "pair_born.html">born/coul/msm (o)</A></TD><TD ><A HREF = "pair_born.html">born/coul/wolf (go)</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "pair_brownian.html">brownian (o)</A></TD><TD ><A HREF = "pair_brownian.html">brownian/poly (o)</A></TD><TD ><A HREF = "pair_buck.html">buck (cgko)</A></TD><TD ><A HREF = "pair_buck.html">buck/coul/cut (cgko)</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "pair_buck.html">buck/coul/long (cgko)</A></TD><TD ><A HREF = "pair_buck.html">buck/coul/msm (o)</A></TD><TD ><A HREF = "pair_buck_long.html">buck/long/coul/long (o)</A></TD><TD ><A HREF = "pair_colloid.html">colloid (go)</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "pair_comb.html">comb (o)</A></TD><TD ><A HREF = "pair_comb.html">comb3</A></TD><TD ><A HREF = "pair_coul.html">coul/cut (gko)</A></TD><TD ><A HREF = "pair_coul.html">coul/debye (gko)</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "pair_coul.html">coul/dsf (gko)</A></TD><TD ><A HREF = "pair_coul.html">coul/long (gko)</A></TD><TD ><A HREF = "pair_coul.html">coul/msm</A></TD><TD ><A HREF = "pair_coul.html">coul/streitz</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "pair_coul.html">coul/wolf (ko)</A></TD><TD ><A HREF = "pair_dpd.html">dpd (o)</A></TD><TD ><A HREF = "pair_dpd.html">dpd/tstat (o)</A></TD><TD ><A HREF = "pair_dsmc.html">dsmc</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "pair_eam.html">eam (cgkot)</A></TD><TD ><A HREF = "pair_eam.html">eam/alloy (cgkot)</A></TD><TD ><A HREF = "pair_eam.html">eam/fs (cgkot)</A></TD><TD ><A HREF = "pair_eim.html">eim (o)</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "pair_gauss.html">gauss (go)</A></TD><TD ><A HREF = "pair_gayberne.html">gayberne (gio)</A></TD><TD ><A HREF = "pair_gran.html">gran/hertz/history (o)</A></TD><TD ><A HREF = "pair_gran.html">gran/hooke (co)</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "pair_gran.html">gran/hooke/history (o)</A></TD><TD ><A HREF = "pair_hbond_dreiding.html">hbond/dreiding/lj (o)</A></TD><TD ><A HREF = "pair_hbond_dreiding.html">hbond/dreiding/morse (o)</A></TD><TD ><A HREF = "pair_kim.html">kim</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "pair_lcbop.html">lcbop</A></TD><TD ><A HREF = "pair_line_lj.html">line/lj (o)</A></TD><TD ><A HREF = "pair_charmm.html">lj/charmm/coul/charmm (cko)</A></TD><TD ><A HREF = "pair_charmm.html">lj/charmm/coul/charmm/implicit (cko)</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "pair_charmm.html">lj/charmm/coul/long (cgiko)</A></TD><TD ><A HREF = "pair_charmm.html">lj/charmm/coul/msm</A></TD><TD ><A HREF = "pair_class2.html">lj/class2 (cgko)</A></TD><TD ><A HREF = "pair_class2.html">lj/class2/coul/cut (cko)</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "pair_class2.html">lj/class2/coul/long (cgko)</A></TD><TD ><A HREF = "pair_lj.html">lj/cut (cgikot)</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/coul/cut (cgko)</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/coul/debye (cgko)</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "pair_lj.html">lj/cut/coul/dsf (gko)</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/coul/long (cgikot)</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/coul/msm (go)</A></TD><TD ><A HREF = "pair_dipole.html">lj/cut/dipole/cut (go)</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "pair_dipole.html">lj/cut/dipole/long</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/tip4p/cut (o)</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/tip4p/long (ot)</A></TD><TD ><A HREF = "pair_lj_expand.html">lj/expand (cgko)</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "pair_gromacs.html">lj/gromacs (cgko)</A></TD><TD ><A HREF = "pair_gromacs.html">lj/gromacs/coul/gromacs (cko)</A></TD><TD ><A HREF = "pair_lj_long.html">lj/long/coul/long (o)</A></TD><TD ><A HREF = "pair_dipole.html">lj/long/dipole/long</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "pair_lj_long.html">lj/long/tip4p/long</A></TD><TD ><A HREF = "pair_lj_smooth.html">lj/smooth (co)</A></TD><TD ><A HREF = "pair_lj_smooth_linear.html">lj/smooth/linear (o)</A></TD><TD ><A HREF = "pair_lj96.html">lj96/cut (cgo)</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "pair_lubricate.html">lubricate (o)</A></TD><TD ><A HREF = "pair_lubricate.html">lubricate/poly (o)</A></TD><TD ><A HREF = "pair_lubricateU.html">lubricateU</A></TD><TD ><A HREF = "pair_lubricateU.html">lubricateU/poly</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "pair_meam.html">meam (o)</A></TD><TD ><A HREF = "pair_mie.html">mie/cut (o)</A></TD><TD ><A HREF = "pair_morse.html">morse (cgot)</A></TD><TD ><A HREF = "pair_nb3b_harmonic.html">nb3b/harmonic (o)</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "pair_nm.html">nm/cut (o)</A></TD><TD ><A HREF = "pair_nm.html">nm/cut/coul/cut (o)</A></TD><TD ><A HREF = "pair_nm.html">nm/cut/coul/long (o)</A></TD><TD ><A HREF = "pair_peri.html">peri/eps</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "pair_peri.html">peri/lps (o)</A></TD><TD ><A HREF = "pair_peri.html">peri/pmb (o)</A></TD><TD ><A HREF = "pair_peri.html">peri/ves</A></TD><TD ><A HREF = "pair_reax.html">reax</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "pair_airebo.html">rebo (o)</A></TD><TD ><A HREF = "pair_resquared.html">resquared (go)</A></TD><TD ><A HREF = "pair_snap.html">snap</A></TD><TD ><A HREF = "pair_soft.html">soft (go)</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "pair_sw.html">sw (cgkio)</A></TD><TD ><A HREF = "pair_table.html">table (gko)</A></TD><TD ><A HREF = "pair_tersoff.html">tersoff (cko)</A></TD><TD ><A HREF = "pair_tersoff_mod.html">tersoff/mod (ko)</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "pair_tersoff_zbl.html">tersoff/zbl (ko)</A></TD><TD ><A HREF = "pair_coul.html">tip4p/cut (o)</A></TD><TD ><A HREF = "pair_coul.html">tip4p/long (o)</A></TD><TD ><A HREF = "pair_tri_lj.html">tri/lj (o)</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "pair_yukawa.html">yukawa (go)</A></TD><TD ><A HREF = "pair_yukawa_colloid.html">yukawa/colloid (go)</A></TD><TD ><A HREF = "pair_zbl.html">zbl (o)</A> 
-</TD></TR></TABLE></DIV>
-
-<P>These are additional pair styles in USER packages, which can be used
-if <A HREF = "Section_start.html#start_3">LAMMPS is built with the appropriate
-package</A>.
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR ALIGN="center"><TD ><A HREF = "pair_awpmd.html">awpmd/cut</A></TD><TD ><A HREF = "pair_lj_soft.html">coul/cut/soft (o)</A></TD><TD ><A HREF = "pair_coul_diel.html">coul/diel (o)</A></TD><TD ><A HREF = "pair_lj_soft.html">coul/long/soft (o)</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "pair_eam.html">eam/cd (o)</A></TD><TD ><A HREF = "pair_edip.html">edip (o)</A></TD><TD ><A HREF = "pair_eff.html">eff/cut</A></TD><TD ><A HREF = "pair_gauss.html">gauss/cut</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "pair_list.html">list</A></TD><TD ><A HREF = "pair_charmm.html">lj/charmm/coul/long/soft (o)</A></TD><TD ><A HREF = "pair_lj_soft.html">lj/cut/coul/cut/soft (o)</A></TD><TD ><A HREF = "pair_lj_soft.html">lj/cut/coul/long/soft (o)</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "pair_dipole.html">lj/cut/dipole/sf (go)</A></TD><TD ><A HREF = "pair_lj_soft.html">lj/cut/soft (o)</A></TD><TD ><A HREF = "pair_lj_soft.html">lj/cut/tip4p/long/soft (o)</A></TD><TD ><A HREF = "pair_sdk.html">lj/sdk (gko)</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "pair_sdk.html">lj/sdk/coul/long (go)</A></TD><TD ><A HREF = "pair_sdk.html">lj/sdk/coul/msm (o)</A></TD><TD ><A HREF = "pair_lj_sf.html">lj/sf (o)</A></TD><TD ><A HREF = "pair_meam_spline.html">meam/spline</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "pair_meam_sw_spline.html">meam/sw/spline</A></TD><TD ><A HREF = "pair_quip.html">quip</A></TD><TD ><A HREF = "pair_reax_c.html">reax/c</A></TD><TD ><A HREF = "pair_sph_heatconduction.html">sph/heatconduction</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "pair_sph_idealgas.html">sph/idealgas</A></TD><TD ><A HREF = "pair_sph_lj.html">sph/lj</A></TD><TD ><A HREF = "pair_sph_rhosum.html">sph/rhosum</A></TD><TD ><A HREF = "pair_sph_taitwater.html">sph/taitwater</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "pair_sph_taitwater_morris.html">sph/taitwater/morris</A></TD><TD ><A HREF = "pair_srp.html">srp</A></TD><TD ><A HREF = "pair_tersoff.html">tersoff/table (o)</A></TD><TD ><A HREF = "pair_lj_soft.html">tip4p/long/soft (o)</A> 
-</TD></TR></TABLE></DIV>
-
-<HR>
-
-<H4>Bond_style potentials 
-</H4>
-<P>See the <A HREF = "bond_style.html">bond_style</A> command for an overview of bond
-potentials.  Click on the style itself for a full description.  Some
-of the styles have accelerated versions, which can be used if LAMMPS
-is built with the <A HREF = "Section_accelerate.html">appropriate accelerated
-package</A>.  This is indicated by additional
-letters in parenthesis: c = USER-CUDA, g = GPU, i = USER-INTEL, k =
-KOKKOS, o = USER-OMP, t = OPT.
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR ALIGN="center"><TD ><A HREF = "bond_none.html">none</A></TD><TD ><A HREF = "bond_hybrid.html">hybrid</A></TD><TD ><A HREF = "bond_class2.html">class2 (o)</A></TD><TD ><A HREF = "bond_fene.html">fene (ko)</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "bond_fene_expand.html">fene/expand (o)</A></TD><TD ><A HREF = "bond_harmonic.html">harmonic (ko)</A></TD><TD ><A HREF = "bond_morse.html">morse (o)</A></TD><TD ><A HREF = "bond_nonlinear.html">nonlinear (o)</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "bond_quartic.html">quartic (o)</A></TD><TD ><A HREF = "bond_table.html">table (o)</A> 
-</TD></TR></TABLE></DIV>
-
-<P>These are additional bond styles in USER packages, which can be used
-if <A HREF = "Section_start.html#start_3">LAMMPS is built with the appropriate
-package</A>.
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR ALIGN="center"><TD ><A HREF = "bond_harmonic_shift.html">harmonic/shift (o)</A></TD><TD ><A HREF = "bond_harmonic_shift_cut.html">harmonic/shift/cut (o)</A> 
-</TD></TR></TABLE></DIV>
-
-<HR>
-
-<H4>Angle_style potentials 
-</H4>
-<P>See the <A HREF = "angle_style.html">angle_style</A> command for an overview of
-angle potentials.  Click on the style itself for a full description.
-Some of the styles have accelerated versions, which can be used if
-LAMMPS is built with the <A HREF = "Section_accelerate.html">appropriate accelerated
-package</A>.  This is indicated by additional
-letters in parenthesis: c = USER-CUDA, g = GPU, i = USER-INTEL, k =
-KOKKOS, o = USER-OMP, t = OPT.
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR ALIGN="center"><TD ><A HREF = "angle_none.html">none</A></TD><TD ><A HREF = "angle_hybrid.html">hybrid</A></TD><TD ><A HREF = "angle_charmm.html">charmm (ko)</A></TD><TD ><A HREF = "angle_class2.html">class2 (o)</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "angle_cosine.html">cosine (o)</A></TD><TD ><A HREF = "angle_cosine_delta.html">cosine/delta (o)</A></TD><TD ><A HREF = "angle_cosine_periodic.html">cosine/periodic (o)</A></TD><TD ><A HREF = "angle_cosine_squared.html">cosine/squared (o)</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "angle_harmonic.html">harmonic (ko)</A></TD><TD ><A HREF = "angle_table.html">table (o)</A> 
-</TD></TR></TABLE></DIV>
-
-<P>These are additional angle styles in USER packages, which can be used
-if <A HREF = "Section_start.html#start_3">LAMMPS is built with the appropriate
-package</A>.
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR ALIGN="center"><TD ><A HREF = "angle_cosine_shift.html">cosine/shift (o)</A></TD><TD ><A HREF = "angle_cosine_shift_exp.html">cosine/shift/exp (o)</A></TD><TD ><A HREF = "angle_dipole.html">dipole (o)</A></TD><TD ><A HREF = "angle_fourier.html">fourier (o)</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "angle_fourier_simple.html">fourier/simple (o)</A></TD><TD ><A HREF = "angle_quartic.html">quartic (o)</A></TD><TD ><A HREF = "angle_sdk.html">sdk</A> 
-</TD></TR></TABLE></DIV>
-
-<HR>
-
-<H4>Dihedral_style potentials 
-</H4>
-<P>See the <A HREF = "dihedral_style.html">dihedral_style</A> command for an overview
-of dihedral potentials.  Click on the style itself for a full
-description.  Some of the styles have accelerated versions, which can
-be used if LAMMPS is built with the <A HREF = "Section_accelerate.html">appropriate accelerated
-package</A>.  This is indicated by additional
-letters in parenthesis: c = USER-CUDA, g = GPU, i = USER-INTEL, k =
-KOKKOS, o = USER-OMP, t = OPT.
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR ALIGN="center"><TD ><A HREF = "dihedral_none.html">none</A></TD><TD ><A HREF = "dihedral_hybrid.html">hybrid</A></TD><TD ><A HREF = "dihedral_charmm.html">charmm (ko)</A></TD><TD ><A HREF = "dihedral_class2.html">class2 (o)</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "dihedral_harmonic.html">harmonic (o)</A></TD><TD ><A HREF = "dihedral_helix.html">helix (o)</A></TD><TD ><A HREF = "dihedral_multi_harmonic.html">multi/harmonic (o)</A></TD><TD ><A HREF = "dihedral_opls.html">opls (ko)</A> 
-</TD></TR></TABLE></DIV>
-
-<P>These are additional dihedral styles in USER packages, which can be
-used if <A HREF = "Section_start.html#start_3">LAMMPS is built with the appropriate
-package</A>.
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR ALIGN="center"><TD ><A HREF = "dihedral_cosine_shift_exp.html">cosine/shift/exp (o)</A></TD><TD ><A HREF = "dihedral_fourier.html">fourier (o)</A></TD><TD ><A HREF = "dihedral_nharmonic.html">nharmonic (o)</A></TD><TD ><A HREF = "dihedral_quadratic.html">quadratic (o)</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "dihedral_table.html">table (o)</A> 
-</TD></TR></TABLE></DIV>
-
-<HR>
-
-<H4>Improper_style potentials 
-</H4>
-<P>See the <A HREF = "improper_style.html">improper_style</A> command for an overview
-of improper potentials.  Click on the style itself for a full
-description.  Some of the styles have accelerated versions, which can
-be used if LAMMPS is built with the <A HREF = "Section_accelerate.html">appropriate accelerated
-package</A>.  This is indicated by additional
-letters in parenthesis: c = USER-CUDA, g = GPU, i = USER-INTEL, k =
-KOKKOS, o = USER-OMP, t = OPT.
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR ALIGN="center"><TD ><A HREF = "improper_none.html">none</A></TD><TD ><A HREF = "improper_hybrid.html">hybrid</A></TD><TD ><A HREF = "improper_class2.html">class2 (o)</A></TD><TD ><A HREF = "improper_cvff.html">cvff (o)</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "improper_harmonic.html">harmonic (ko)</A></TD><TD ><A HREF = "improper_umbrella.html">umbrella (o)</A> 
-</TD></TR></TABLE></DIV>
-
-<P>These are additional improper styles in USER packages, which can be
-used if <A HREF = "Section_start.html#start_3">LAMMPS is built with the appropriate
-package</A>.
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR ALIGN="center"><TD ><A HREF = "improper_cossq.html">cossq (o)</A></TD><TD ><A HREF = "improper_fourier.html">fourier (o)</A></TD><TD ><A HREF = "improper_ring.html">ring (o)</A> 
-</TD></TR></TABLE></DIV>
-
-<HR>
-
-<H4>Kspace solvers 
-</H4>
-<P>See the <A HREF = "kspace_style.html">kspace_style</A> command for an overview of
-Kspace solvers.  Click on the style itself for a full description.
-Some of the styles have accelerated versions, which can be used if
-LAMMPS is built with the <A HREF = "Section_accelerate.html">appropriate accelerated
-package</A>.  This is indicated by additional
-letters in parenthesis: c = USER-CUDA, g = GPU, i = USER-INTEL, k =
-KOKKOS, o = USER-OMP, t = OPT.
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR ALIGN="center"><TD ><A HREF = "kspace_style.html">ewald (o)</A></TD><TD ><A HREF = "kspace_style.html">ewald/disp</A></TD><TD ><A HREF = "kspace_style.html">msm (o)</A></TD><TD ><A HREF = "kspace_style.html">msm/cg (o)</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "kspace_style.html">pppm (cgo)</A></TD><TD ><A HREF = "kspace_style.html">pppm/cg (o)</A></TD><TD ><A HREF = "kspace_style.html">pppm/disp</A></TD><TD ><A HREF = "kspace_style.html">pppm/disp/tip4p</A></TD></TR>
-<TR ALIGN="center"><TD ><A HREF = "kspace_style.html">pppm/tip4p (o)</A> 
-</TD></TR></TABLE></DIV>
-
-</HTML>
--- a/doc/Section_commands.txt
+++ b/doc/Section_commands.txt
--- a/doc/Section_errors.html
+++ b/doc/Section_errors.html
--- a/doc/Section_example.html
+++ b/doc/Section_example.html
@ -1,126 +0,0 @@
-<HTML>
-<CENTER><A HREF = "Section_howto.html">Previous Section</A> - <A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> - <A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A> - <A HREF = "Section_perf.html">Next Section</A> 
-</CENTER>
-
-
-
-
-
-
-<HR>
-
-<H3>7. Example problems 
-</H3>
-<P>The LAMMPS distribution includes an examples sub-directory with
-several sample problems.  Each problem is in a sub-directory of its
-own.  Most are 2d models so that they run quickly, requiring at most a
-couple of minutes to run on a desktop machine.  Each problem has an
-input script (in.*) and produces a log file (log.*) and dump file
-(dump.*) when it runs.  Some use a data file (data.*) of initial
-coordinates as additional input.  A few sample log file outputs on
-different machines and different numbers of processors are included in
-the directories to compare your answers to.  E.g. a log file like
-log.crack.foo.P means it ran on P processors of machine "foo".
-</P>
-<P>For examples that use input data files, many of them were produced by
-<A HREF = "http://pizza.sandia.gov">Pizza.py</A> or setup tools described in the
-<A HREF = "Section_tools.html">Additional Tools</A> section of the LAMMPS
-documentation and provided with the LAMMPS distribution.
-</P>
-<P>If you uncomment the <A HREF = "dump.html">dump</A> command in the input script, a
-text dump file will be produced, which can be animated by various
-<A HREF = "http://lammps.sandia.gov/viz.html">visualization programs</A>.  It can
-also be animated using the xmovie tool described in the <A HREF = "Section_tools.html">Additional
-Tools</A> section of the LAMMPS documentation.
-</P>
-<P>If you uncomment the <A HREF = "dump.html">dump image</A> command in the input
-script, and assuming you have built LAMMPS with a JPG library, JPG
-snapshot images will be produced when the simulation runs.  They can
-be quickly post-processed into a movie using commands described on the
-<A HREF = "dump_image.html">dump image</A> doc page.
-</P>
-<P>Animations of many of these examples can be viewed on the Movies
-section of the <A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A>.
-</P>
-<P>These are the sample problems in the examples sub-directories:
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR><TD >balance</TD><TD >  dynamic load balancing, 2d system</TD></TR>
-<TR><TD >body</TD><TD >     body particles, 2d system</TD></TR>
-<TR><TD >colloid</TD><TD >  big colloid particles in a small particle solvent, 2d system</TD></TR>
-<TR><TD >comb</TD><TD >	  models using the COMB potential</TD></TR>
-<TR><TD >crack</TD><TD >	  crack propagation in a 2d solid</TD></TR>
-<TR><TD >cuda</TD><TD >     use of the USER-CUDA package for GPU acceleration</TD></TR>
-<TR><TD >dipole</TD><TD >   point dipolar particles, 2d system</TD></TR>
-<TR><TD >dreiding</TD><TD > methanol via Dreiding FF</TD></TR>
-<TR><TD >eim</TD><TD >      NaCl using the EIM potential</TD></TR>
-<TR><TD >ellipse</TD><TD >  ellipsoidal particles in spherical solvent, 2d system</TD></TR>
-<TR><TD >flow</TD><TD >	  Couette and Poiseuille flow in a 2d channel</TD></TR>
-<TR><TD >friction</TD><TD > frictional contact of spherical asperities between 2d surfaces</TD></TR>
-<TR><TD >gpu</TD><TD >      use of the GPU package for GPU acceleration</TD></TR>
-<TR><TD >hugoniostat</TD><TD > Hugoniostat shock dynamics</TD></TR>
-<TR><TD >indent</TD><TD >	  spherical indenter into a 2d solid</TD></TR>
-<TR><TD >intel</TD><TD >    use of the USER-INTEL package for CPU or Intel(R) Xeon Phi(TM) coprocessor</TD></TR>
-<TR><TD >kim</TD><TD >      use of potentials in Knowledge Base for Interatomic Models (KIM)</TD></TR>
-<TR><TD >line</TD><TD >     line segment particles in 2d rigid bodies</TD></TR>
-<TR><TD >meam</TD><TD >	  MEAM test for SiC and shear (same as shear examples)</TD></TR>
-<TR><TD >melt</TD><TD >	  rapid melt of 3d LJ system</TD></TR>
-<TR><TD >micelle</TD><TD >  self-assembly of small lipid-like molecules into 2d bilayers</TD></TR>
-<TR><TD >min</TD><TD >	  energy minimization of 2d LJ melt</TD></TR>
-<TR><TD >msst</TD><TD >	  MSST shock dynamics</TD></TR>
-<TR><TD >nb3b</TD><TD >     use of nonbonded 3-body harmonic pair style</TD></TR>
-<TR><TD >neb</TD><TD >	  nudged elastic band (NEB) calculation for barrier finding</TD></TR>
-<TR><TD >nemd</TD><TD >	  non-equilibrium MD of 2d sheared system</TD></TR>
-<TR><TD >obstacle</TD><TD > flow around two voids in a 2d channel</TD></TR>
-<TR><TD >peptide</TD><TD >  dynamics of a small solvated peptide chain (5-mer)</TD></TR>
-<TR><TD >peri</TD><TD >	  Peridynamic model of cylinder impacted by indenter</TD></TR>
-<TR><TD >pour</TD><TD >     pouring of granular particles into a 3d box, then chute flow</TD></TR>
-<TR><TD >prd</TD><TD >      parallel replica dynamics of vacancy diffusion in bulk Si</TD></TR>
-<TR><TD >qeq</TD><TD >      use of the QEQ pacakge for charge equilibration</TD></TR>
-<TR><TD >reax</TD><TD >     RDX and TATB models using the ReaxFF</TD></TR>
-<TR><TD >rigid</TD><TD >    rigid bodies modeled as independent or coupled</TD></TR>
-<TR><TD >shear</TD><TD >    sideways shear applied to 2d solid, with and without a void</TD></TR>
-<TR><TD >snap</TD><TD >     NVE dynamics for BCC tantalum crystal using SNAP potential</TD></TR>
-<TR><TD >srd</TD><TD >      stochastic rotation dynamics (SRD) particles as solvent</TD></TR>
-<TR><TD >tad</TD><TD >      temperature-accelerated dynamics of vacancy diffusion in bulk Si</TD></TR>
-<TR><TD >tri</TD><TD >      triangular particles in rigid bodies 
-</TD></TR></TABLE></DIV>
-
-<P>Here is how you might run and visualize one of the sample problems:
-</P>
-<PRE>cd indent
-cp ../../src/lmp_linux .           # copy LAMMPS executable to this dir
-lmp_linux < in.indent              # run the problem 
-</PRE>
-<P>Running the simulation produces the files <I>dump.indent</I> and
-<I>log.lammps</I>.  You can visualize the dump file as follows:
-</P>
-<PRE>../../tools/xmovie/xmovie -scale dump.indent 
-</PRE>
-<P>If you uncomment the <A HREF = "dump_image.html">dump image</A> line(s) in the input
-script a series of JPG images will be produced by the run.  These can
-be viewed individually or turned into a movie or animated by tools
-like ImageMagick or QuickTime or various Windows-based tools.  See the
-<A HREF = "dump_image.html">dump image</A> doc page for more details.  E.g. this
-Imagemagick command would create a GIF file suitable for viewing in a
-browser.
-</P>
-<PRE>% convert -loop 1 *.jpg foo.gif 
-</PRE>
-<HR>
-
-<P>There is also a COUPLE directory with examples of how to use LAMMPS as
-a library, either by itself or in tandem with another code or library.
-See the COUPLE/README file to get started.
-</P>
-<P>There is also an ELASTIC directory with an example script for
-computing elastic constants, using a zero temperature Si example.  See
-the in.elastic file for more info.
-</P>
-<P>There is also a USER directory which contains subdirectories of
-user-provided examples for user packages.  See the README files in
-those directories for more info.  See the
-<A HREF = "Section_start.html">Section_start.html</A> file for more info about user
-packages.
-</P>
-</HTML>
--- a/doc/Section_example.txt
+++ b/doc/Section_example.txt
@ -1,119 +0,0 @@
-"Previous Section"_Section_howto.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_perf.html :c
-
-:link(lws,http://lammps.sandia.gov)
-:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
-
-:line
-
-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
-own.  Most are 2d models so that they run quickly, requiring at most a
-couple of minutes to run on a desktop machine.  Each problem has an
-input script (in.*) and produces a log file (log.*) and dump file
-(dump.*) when it runs.  Some use a data file (data.*) of initial
-coordinates as additional input.  A few sample log file outputs on
-different machines and different numbers of processors are included in
-the directories to compare your answers to.  E.g. a log file like
-log.crack.foo.P means it ran on P processors of machine "foo".
-
-For examples that use input data files, many of them were produced by
-"Pizza.py"_http://pizza.sandia.gov or setup tools described in the
-"Additional Tools"_Section_tools.html section of the LAMMPS
-documentation and provided with the LAMMPS distribution.
-
-If you uncomment the "dump"_dump.html command in the input script, a
-text dump file will be produced, which can be animated by various
-"visualization programs"_http://lammps.sandia.gov/viz.html.  It can
-also be animated using the xmovie tool described in the "Additional
-Tools"_Section_tools.html section of the LAMMPS documentation.
-
-If you uncomment the "dump image"_dump.html command in the input
-script, and assuming you have built LAMMPS with a JPG library, JPG
-snapshot images will be produced when the simulation runs.  They can
-be quickly post-processed into a movie using commands described on the
-"dump image"_dump_image.html doc page.
-
-Animations of many of these examples can be viewed on the Movies
-section of the "LAMMPS WWW Site"_lws.
-
-These are the sample problems in the examples sub-directories:
-
-balance:  dynamic load balancing, 2d system
-body:     body particles, 2d system
-colloid:  big colloid particles in a small particle solvent, 2d system
-comb:	  models using the COMB potential
-crack:	  crack propagation in a 2d solid
-cuda:     use of the USER-CUDA package for GPU acceleration
-dipole:   point dipolar particles, 2d system
-dreiding: methanol via Dreiding FF
-eim:      NaCl using the EIM potential
-ellipse:  ellipsoidal particles in spherical solvent, 2d system
-flow:	  Couette and Poiseuille flow in a 2d channel
-friction: frictional contact of spherical asperities between 2d surfaces
-gpu:      use of the GPU package for GPU acceleration
-hugoniostat: Hugoniostat shock dynamics
-indent:	  spherical indenter into a 2d solid
-intel:    use of the USER-INTEL package for CPU or Intel(R) Xeon Phi(TM) coprocessor
-kim:      use of potentials in Knowledge Base for Interatomic Models (KIM)
-line:     line segment particles in 2d rigid bodies
-meam:	  MEAM test for SiC and shear (same as shear examples)
-melt:	  rapid melt of 3d LJ system
-micelle:  self-assembly of small lipid-like molecules into 2d bilayers
-min:	  energy minimization of 2d LJ melt
-msst:	  MSST shock dynamics
-nb3b:     use of nonbonded 3-body harmonic pair style
-neb:	  nudged elastic band (NEB) calculation for barrier finding
-nemd:	  non-equilibrium MD of 2d sheared system
-obstacle: flow around two voids in a 2d channel
-peptide:  dynamics of a small solvated peptide chain (5-mer)
-peri:	  Peridynamic model of cylinder impacted by indenter
-pour:     pouring of granular particles into a 3d box, then chute flow
-prd:      parallel replica dynamics of vacancy diffusion in bulk Si
-qeq:      use of the QEQ pacakge for charge equilibration
-reax:     RDX and TATB models using the ReaxFF
-rigid:    rigid bodies modeled as independent or coupled
-shear:    sideways shear applied to 2d solid, with and without a void
-snap:     NVE dynamics for BCC tantalum crystal using SNAP potential
-srd:      stochastic rotation dynamics (SRD) particles as solvent
-tad:      temperature-accelerated dynamics of vacancy diffusion in bulk Si
-tri:      triangular particles in rigid bodies :tb(s=:)
-
-Here is how you might run and visualize one of the sample problems:
-
-cd indent
-cp ../../src/lmp_linux .           # copy LAMMPS executable to this dir
-lmp_linux < in.indent              # run the problem :pre
-
-Running the simulation produces the files {dump.indent} and
-{log.lammps}.  You can visualize the dump file as follows:
-
-../../tools/xmovie/xmovie -scale dump.indent :pre
-
-If you uncomment the "dump image"_dump_image.html line(s) in the input
-script a series of JPG images will be produced by the run.  These can
-be viewed individually or turned into a movie or animated by tools
-like ImageMagick or QuickTime or various Windows-based tools.  See the
-"dump image"_dump_image.html doc page for more details.  E.g. this
-Imagemagick command would create a GIF file suitable for viewing in a
-browser.
-
-% convert -loop 1 *.jpg foo.gif :pre
-
-:line
-
-There is also a COUPLE directory with examples of how to use LAMMPS as
-a library, either by itself or in tandem with another code or library.
-See the COUPLE/README file to get started.
-
-There is also an ELASTIC directory with an example script for
-computing elastic constants, using a zero temperature Si example.  See
-the in.elastic file for more info.
-
-There is also a USER directory which contains subdirectories of
-user-provided examples for user packages.  See the README files in
-those directories for more info.  See the
-"Section_start.html"_Section_start.html file for more info about user
-packages.
--- a/doc/Section_history.html
+++ b/doc/Section_history.html
@ -1,129 +0,0 @@
-<HTML>
-<CENTER><A HREF = "Section_errors.html">Previous Section</A> - <A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> -
-<A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A> - <A HREF = "Manual.html">Next
-Section</A> 
-</CENTER>
-
-
-
-
-
-
-<HR>
-
-<H3>13. Future and history 
-</H3>
-<P>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.
-</P>
-13.1 <A HREF = "#hist_1">Coming attractions</A><BR>
-13.2 <A HREF = "#hist_2">Past versions</A> <BR>
-
-<HR>
-
-<HR>
-
-<H4><A NAME = "hist_1"></A>13.1 Coming attractions 
-</H4>
-<P>The <A HREF = "http://lammps.sandia.gov/future.html">Wish list link</A> 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.
-</P>
-<P>You can also send <A HREF = "http://lammps.sandia.gov/authors.html">email to the
-developers</A> if you want to add
-your wish to the list.
-</P>
-<HR>
-
-<H4><A NAME = "hist_2"></A>13.2 Past versions 
-</H4>
-<P>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). The goal was
-to develop a large-scale parallel classical MD code; the coding effort
-was led by Steve Plimpton at Sandia.
-</P>
-<P>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.
-</P>
-<P>The current LAMMPS is a rewrite in C++ and was first publicly released
-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).
-</P>
-<P>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.
-</P>
-<P>The <A HREF = "http://lammps.sandia.gov/history.html">History link</A> on the 
-LAMMPS WWW page gives a timeline of features added to the
-C++ open-source version of LAMMPS over the last several years.
-</P>
-<P>These older codes are available for download from the <A HREF = "http://lammps.sandia.gov">LAMMPS WWW
-site</A>, except for Warp & GranFlow which were primarily used
-internally.  A brief listing of their features is given here.
-</P>
-<P>LAMMPS 2001
-</P>
-<UL><LI>    F90 + MPI
-<LI>    dynamic memory
-<LI>    spatial-decomposition parallelism
-<LI>    NVE, NVT, NPT, NPH, rRESPA integrators
-<LI>    LJ and Coulombic pairwise force fields
-<LI>    all-atom, united-atom, bead-spring polymer force fields
-<LI>    CHARMM-compatible force fields
-<LI>    class 2 force fields
-<LI>    3d/2d Ewald & PPPM
-<LI>    various force and temperature constraints
-<LI>    SHAKE
-<LI>    Hessian-free truncated-Newton minimizer
-<LI>    user-defined diagnostics 
-</UL>
-<P>LAMMPS 99
-</P>
-<UL><LI>    F77 + MPI
-<LI>    static memory allocation
-<LI>    spatial-decomposition parallelism
-<LI>    most of the LAMMPS 2001 features with a few exceptions
-<LI>    no 2d Ewald & PPPM
-<LI>    molecular force fields are missing a few CHARMM terms
-<LI>    no SHAKE 
-</UL>
-<P>Warp
-</P>
-<UL><LI>    F90 + MPI
-<LI>    spatial-decomposition parallelism
-<LI>    embedded atom method (EAM) metal potentials + LJ
-<LI>    lattice and grain-boundary atom creation
-<LI>    NVE, NVT integrators
-<LI>    boundary conditions for applying shear stresses
-<LI>    temperature controls for actively sheared systems
-<LI>    per-atom energy and centro-symmetry computation and output 
-</UL>
-<P>ParaDyn
-</P>
-<UL><LI>    F77 + MPI
-<LI>    atom- and force-decomposition parallelism
-<LI>    embedded atom method (EAM) metal potentials
-<LI>    lattice atom creation
-<LI>    NVE, NVT, NPT integrators
-<LI>    all serial DYNAMO features for controls and constraints 
-</UL>
-<P>GranFlow
-</P>
-<UL><LI>    F90 + MPI
-<LI>    spatial-decomposition parallelism
-<LI>    frictional granular potentials
-<LI>    NVE integrator
-<LI>    boundary conditions for granular flow and packing and walls
-<LI>    particle insertion 
-</UL>
-</HTML>
--- a/doc/Section_howto.html
+++ b/doc/Section_howto.html
--- a/doc/Section_intro.html
+++ b/doc/Section_intro.html
@ -1,550 +0,0 @@
-<HTML>
-<CENTER><A HREF = "Manual.html">Previous Section</A> - <A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> - <A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A> - <A HREF = "Section_start.html">Next Section</A> 
-</CENTER>
-
-
-
-
-
-
-<HR>
-
-<H3>1. Introduction 
-</H3>
-<P>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.
-</P>
-1.1 <A HREF = "#intro_1">What is LAMMPS</A><BR>
-1.2 <A HREF = "#intro_2">LAMMPS features</A><BR>
-1.3 <A HREF = "#intro_3">LAMMPS non-features</A><BR>
-1.4 <A HREF = "#intro_4">Open source distribution</A><BR>
-1.5 <A HREF = "#intro_5">Acknowledgments and citations</A> <BR>
-
-<HR>
-
-<HR>
-
-<A NAME = "intro_1"></A><H4>1.1 What is LAMMPS 
-</H4>
-<P>LAMMPS is a classical molecular dynamics code that models an ensemble
-of particles in a liquid, solid, or gaseous state.  It can model
-atomic, polymeric, biological, metallic, granular, and coarse-grained
-systems using a variety of force fields and boundary conditions.
-</P>
-<P>For examples of LAMMPS simulations, see the Publications page of the
-<A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A>.
-</P>
-<P>LAMMPS runs efficiently on single-processor desktop or laptop
-machines, but is designed for parallel computers.  It will run on any
-parallel machine that compiles C++ and supports the <A HREF = "http://www-unix.mcs.anl.gov/mpi">MPI</A>
-message-passing library.  This includes distributed- or shared-memory
-parallel machines and Beowulf-style clusters.
-</P>
-
-
-<P>LAMMPS can model systems with only a few particles up to millions or
-billions.  See <A HREF = "Section_perf.html">Section_perf</A> for information on
-LAMMPS performance and scalability, or the Benchmarks section of the
-<A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A>.
-</P>
-<P>LAMMPS is a freely-available open-source code, distributed under the
-terms of the <A HREF = "http://www.gnu.org/copyleft/gpl.html">GNU Public License</A>, which means you can use or
-modify the code however you wish.  See <A HREF = "#intro_4">this section</A> for a
-brief discussion of the open-source philosophy.
-</P>
-
-
-<P>LAMMPS is designed to be easy to modify or extend with new
-capabilities, such as new force fields, atom types, boundary
-conditions, or diagnostics.  See <A HREF = "Section_modify.html">Section_modify</A>
-for more details.
-</P>
-<P>The current version of LAMMPS is written in C++.  Earlier versions
-were written in F77 and F90.  See
-<A HREF = "Section_history.html">Section_history</A> for more information on
-different versions.  All versions can be downloaded from the <A HREF = "http://lammps.sandia.gov">LAMMPS
-WWW Site</A>.
-</P>
-<P>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 <A HREF = "http://www.sandia.gov">Sandia National Labs</A>.
-See <A HREF = "#intro_5">this section</A> for more information on LAMMPS funding and
-individuals who have contributed to LAMMPS.
-</P>
-
-
-<P>In the most general sense, LAMMPS integrates Newton's equations of
-motion for collections of atoms, molecules, or macroscopic particles
-that interact via short- or long-range forces with a variety of
-initial and/or boundary conditions.  For computational efficiency
-LAMMPS uses neighbor lists to keep track of nearby particles.  The
-lists are optimized for systems with particles that are repulsive at
-short distances, so that the local density of particles never becomes
-too large.  On parallel machines, LAMMPS uses spatial-decomposition
-techniques to partition the simulation domain into small 3d
-sub-domains, one of which is assigned to each processor.  Processors
-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 <A HREF = "#intro_5">this section</A>.
-</P>
-<HR>
-
-<A NAME = "intro_2"></A><H4>1.2 LAMMPS features 
-</H4>
-<P>This section highlights LAMMPS features, with pointers to specific
-commands which give more details.  If LAMMPS doesn't have your
-favorite interatomic potential, boundary condition, or atom type, see
-<A HREF = "Section_modify.html">Section_modify</A>, which describes how you can add
-it to LAMMPS.
-</P>
-<H4>General features 
-</H4>
-<UL><LI>  runs on a single processor or in parallel
-<LI>  distributed-memory message-passing parallelism (MPI)
-<LI>  spatial-decomposition of simulation domain for parallelism
-<LI>  open-source distribution
-<LI>  highly portable C++
-<LI>  optional libraries used: MPI and single-processor FFT
-<LI>  GPU (CUDA and OpenCL), Intel(R) Xeon Phi(TM) coprocessors, and OpenMP support for many code features
-<LI>  easy to extend with new features and functionality
-<LI>  runs from an input script
-<LI>  syntax for defining and using variables and formulas
-<LI>  syntax for looping over runs and breaking out of loops
-<LI>  run one or multiple simulations simultaneously (in parallel) from one script
-<LI>  build as library, invoke LAMMPS thru library interface or provided Python wrapper
-<LI>  couple with other codes: LAMMPS calls other code, other code calls LAMMPS, umbrella code calls both 
-</UL>
-<H4>Particle and model types 
-</H4>
-<P>(<A HREF = "atom_style.html">atom style</A> command)
-</P>
-<UL><LI>  atoms
-<LI>  coarse-grained particles (e.g. bead-spring polymers)
-<LI>  united-atom polymers or organic molecules
-<LI>  all-atom polymers, organic molecules, proteins, DNA
-<LI>  metals
-<LI>  granular materials
-<LI>  coarse-grained mesoscale models
-<LI>  finite-size spherical and ellipsoidal particles
-<LI>  finite-size  line segment (2d) and triangle (3d) particles
-<LI>  point dipole particles
-<LI>  rigid collections of particles
-<LI>  hybrid combinations of these 
-</UL>
-<H4>Force fields 
-</H4>
-<P>(<A HREF = "pair_style.html">pair style</A>, <A HREF = "bond_style.html">bond style</A>,
-<A HREF = "angle_style.html">angle style</A>, <A HREF = "dihedral_style.html">dihedral style</A>,
-<A HREF = "improper_style.html">improper style</A>, <A HREF = "kspace_style.html">kspace style</A>
-commands)
-</P>
-<UL><LI>  pairwise potentials: Lennard-Jones, Buckingham, Morse, Born-Mayer-Huggins,     Yukawa, soft, class 2 (COMPASS), hydrogen bond, tabulated
-<LI>  charged pairwise potentials: Coulombic, point-dipole
-<LI>  manybody potentials: EAM, Finnis/Sinclair EAM, modified EAM (MEAM),     embedded ion method (EIM), EDIP, ADP, Stillinger-Weber, Tersoff,     REBO, AIREBO, ReaxFF, COMB, SNAP, Streitz-Mintmire
-<LI>  charge equilibration (QEq via dynamic, point, shielded, Slater methods)
-<LI>  electron force field (eFF, AWPMD)
-<LI>  coarse-grained potentials: DPD, GayBerne, REsquared, colloidal, DLVO
-<LI>  mesoscopic potentials: granular, Peridynamics, SPH
-<LI>  bond potentials: harmonic, FENE, Morse, nonlinear, class 2,     quartic (breakable)
-<LI>  angle potentials: harmonic, CHARMM, cosine, cosine/squared, cosine/periodic,     class 2 (COMPASS)
-<LI>  dihedral potentials: harmonic, CHARMM, multi-harmonic, helix,     class 2 (COMPASS), OPLS
-<LI>  improper potentials: harmonic, cvff, umbrella, class 2 (COMPASS)
-<LI>  polymer potentials: all-atom, united-atom, bead-spring, breakable
-<LI>  water potentials: TIP3P, TIP4P, SPC
-<LI>  implicit solvent potentials: hydrodynamic lubrication, Debye
-<LI>  <A HREF = "http://openkim.org">KIM archive</A> of potentials
-<LI>  long-range interactions for charge, point-dipoles, and LJ dispersion:     Ewald, Wolf, PPPM (similar to particle-mesh Ewald)
-<LI>  force-field compatibility with common CHARMM, AMBER, DREIDING,     OPLS, GROMACS, COMPASS options
-<LI>  handful of GPU-enabled pair styles
-<LI>  hybrid potentials: multiple pair, bond, angle, dihedral, improper     potentials can be used in one simulation
-<LI>  overlaid potentials: superposition of multiple pair potentials 
-</UL>
-<H4>Atom creation 
-</H4>
-<P>(<A HREF = "read_data.html">read_data</A>, <A HREF = "lattice.html">lattice</A>,
-<A HREF = "create_atoms.html">create_atoms</A>, <A HREF = "delete_atoms.html">delete_atoms</A>,
-<A HREF = "displace_atoms.html">displace_atoms</A>, <A HREF = "replicate.html">replicate</A> commands)
-</P>
-<UL><LI>  read in atom coords from files
-<LI>  create atoms on one or more lattices (e.g. grain boundaries)
-<LI>  delete geometric or logical groups of atoms (e.g. voids)
-<LI>  replicate existing atoms multiple times
-<LI>  displace atoms 
-</UL>
-<H4>Ensembles, constraints, and boundary conditions 
-</H4>
-<P>(<A HREF = "fix.html">fix</A> command) 
-</P>
-<UL><LI>  2d or 3d systems
-<LI>  orthogonal or non-orthogonal (triclinic symmetry) simulation domains
-<LI>  constant NVE, NVT, NPT, NPH, Parinello/Rahman integrators
-<LI>  thermostatting options for groups and geometric regions of atoms
-<LI>  pressure control via Nose/Hoover or Berendsen barostatting in 1 to 3 dimensions
-<LI>  simulation box deformation (tensile and shear)
-<LI>  harmonic (umbrella) constraint forces
-<LI>  rigid body constraints
-<LI>  SHAKE bond and angle constraints
-<LI>  Monte Carlo bond breaking, formation, swapping
-<LI>  atom/molecule insertion and deletion
-<LI>  walls of various kinds
-<LI>  non-equilibrium molecular dynamics (NEMD)
-<LI>  variety of additional boundary conditions and constraints 
-</UL>
-<H4>Integrators 
-</H4>
-<P>(<A HREF = "run.html">run</A>, <A HREF = "run_style.html">run_style</A>, <A HREF = "minimize.html">minimize</A> commands) 
-</P>
-<UL><LI>  velocity-Verlet integrator
-<LI>  Brownian dynamics
-<LI>  rigid body integration
-<LI>  energy minimization via conjugate gradient or steepest descent relaxation
-<LI>  rRESPA hierarchical timestepping
-<LI>  rerun command for post-processing of dump files 
-</UL>
-<H4>Diagnostics 
-</H4>
-<UL><LI>  see the various flavors of the <A HREF = "fix.html">fix</A> and <A HREF = "compute.html">compute</A> commands 
-</UL>
-<H4>Output 
-</H4>
-<P>(<A HREF = "dump.html">dump</A>, <A HREF = "restart.html">restart</A> commands) 
-</P>
-<UL><LI>  log file of thermodynamic info
-<LI>  text dump files of atom coords, velocities, other per-atom quantities
-<LI>  binary restart files
-<LI>  parallel I/O of dump and restart files
-<LI>  per-atom quantities (energy, stress, centro-symmetry parameter, CNA, etc)
-<LI>  user-defined system-wide (log file) or per-atom (dump file) calculations
-<LI>  spatial and time averaging of per-atom quantities
-<LI>  time averaging of system-wide quantities
-<LI>  atom snapshots in native, XYZ, XTC, DCD, CFG formats 
-</UL>
-<H4>Multi-replica models 
-</H4>
-<P><A HREF = "neb.html">nudged elastic band</A>
-<A HREF = "prd.html">parallel replica dynamics</A>
-<A HREF = "tad.html">temperature accelerated dynamics</A>
-<A HREF = "temper.html">parallel tempering</A>
-</P>
-<H4>Pre- and post-processing 
-</H4>
-<UL><LI>Various pre- and post-processing serial tools are packaged
-with LAMMPS; see these <A HREF = "Section_tools.html">doc pages</A>. 
-
-<LI>Our group has also written and released a separate toolkit called
-<A HREF = "http://www.sandia.gov/~sjplimp/pizza.html">Pizza.py</A> which provides tools for doing setup, analysis,
-plotting, and visualization for LAMMPS simulations.  Pizza.py is
-written in <A HREF = "http://www.python.org">Python</A> and is available for download from <A HREF = "http://www.sandia.gov/~sjplimp/pizza.html">the
-Pizza.py WWW site</A>. 
-</UL>
-
-
-
-
-<H4>Specialized features 
-</H4>
-<P>These are LAMMPS capabilities which you may not think of as typical
-molecular dynamics options:
-</P>
-<UL><LI><A HREF = "balance.html">static</A> and <A HREF = "fix_balance.html">dynamic load-balancing</A>
-<LI><A HREF = "body.html">generalized aspherical particles</A>
-<LI><A HREF = "fix_srd.html">stochastic rotation dynamics (SRD)</A>
-<LI><A HREF = "fix_imd.html">real-time visualization and interactive MD</A>
-<LI><A HREF = "fix_atc.html">atom-to-continuum coupling</A> with finite elements
-<LI>coupled rigid body integration via the <A HREF = "fix_poems.html">POEMS</A> library
-<LI><A HREF = "fix_qmmm.html">QM/MM coupling</A>
-<LI><A HREF = "fix_ipi.html">path-integral molecular dynamics (PIMD)</A> and <A HREF = "fix_pimd.html">this as well</A>
-<LI>Monte Carlo via <A HREF = "fix_gcmc.html">GCMC</A> and <A HREF = "fix_tfmc.html">tfMC</A> and <A HREF = "fix_swap.html">atom swapping</A>
-<LI><A HREF = "pair_dsmc.html">Direct Simulation Monte Carlo</A> for low-density fluids
-<LI><A HREF = "pair_peri.html">Peridynamics mesoscale modeling</A>
-<LI><A HREF = "fix_lb_fluid.html">Lattice Boltzmann fluid</A>
-<LI><A HREF = "fix_tmd.html">targeted</A> and <A HREF = "fix_smd.html">steered</A> molecular dynamics
-<LI><A HREF = "fix_ttm.html">two-temperature electron model</A> 
-</UL>
-<HR>
-
-<A NAME = "intro_3"></A><H4>1.3 LAMMPS non-features 
-</H4>
-<P>LAMMPS is designed to efficiently compute Newton's equations of motion
-for a system of interacting particles.  Many of the tools needed to
-pre- and post-process the data for such simulations are not included
-in the LAMMPS kernel for several reasons:
-</P>
-<UL><LI>the desire to keep LAMMPS simple
-<LI>they are not parallel operations
-<LI>other codes already do them
-<LI>limited development resources 
-</UL>
-<P>Specifically, LAMMPS itself does not:
-</P>
-<UL><LI>run thru a GUI
-<LI>build molecular systems
-<LI>assign force-field coefficients automagically
-<LI>perform sophisticated analyses of your MD simulation
-<LI>visualize your MD simulation
-<LI>plot your output data 
-</UL>
-<P>A few tools for pre- and post-processing tasks are provided as part of
-the LAMMPS package; they are described in <A HREF = "Section_tools.html">this
-section</A>.  However, many people use other codes or
-write their own tools for these tasks.
-</P>
-<P>As noted above, our group has also written and released a separate
-toolkit called <A HREF = "http://www.sandia.gov/~sjplimp/pizza.html">Pizza.py</A> which addresses some of the listed
-bullets.  It provides tools for doing setup, analysis, plotting, and
-visualization for LAMMPS simulations.  Pizza.py is written in
-<A HREF = "http://www.python.org">Python</A> and is available for download from <A HREF = "http://www.sandia.gov/~sjplimp/pizza.html">the Pizza.py WWW
-site</A>.
-</P>
-<P>LAMMPS requires as input a list of initial atom coordinates and types,
-molecular topology information, and force-field coefficients assigned
-to all atoms and bonds.  LAMMPS will not build molecular systems and
-assign force-field parameters for you.
-</P>
-<P>For atomic systems LAMMPS provides a <A HREF = "create_atoms.html">create_atoms</A>
-command which places atoms on solid-state lattices (fcc, bcc,
-user-defined, etc).  Assigning small numbers of force field
-coefficients can be done via the <A HREF = "pair_coeff.html">pair coeff</A>, <A HREF = "bond_coeff.html">bond
-coeff</A>, <A HREF = "angle_coeff.html">angle coeff</A>, etc commands.
-For molecular systems or more complicated simulation geometries, users
-typically use another code as a builder and convert its output to
-LAMMPS input format, or write their own code to generate atom
-coordinate and molecular topology for LAMMPS to read in.
-</P>
-<P>For complicated molecular systems (e.g. a protein), a multitude of
-topology information and hundreds of force-field coefficients must
-typically be specified.  We suggest you use a program like
-<A HREF = "http://www.scripps.edu/brooks">CHARMM</A> or <A HREF = "http://amber.scripps.edu">AMBER</A> or other molecular builders to setup
-such problems and dump its information to a file.  You can then
-reformat the file as LAMMPS input.  Some of the tools in <A HREF = "Section_tools.html">this
-section</A> can assist in this process.
-</P>
-<P>Similarly, LAMMPS creates output files in a simple format.  Most users
-post-process these files with their own analysis tools or re-format
-them for input into other programs, including visualization packages.
-If you are convinced you need to compute something on-the-fly as
-LAMMPS runs, see <A HREF = "Section_modify.html">Section_modify</A> for a discussion
-of how you can use the <A HREF = "dump.html">dump</A> and <A HREF = "compute.html">compute</A> and
-<A HREF = "fix.html">fix</A> commands to print out data of your choosing.  Keep in
-mind that complicated computations can slow down the molecular
-dynamics timestepping, particularly if the computations are not
-parallel, so it is often better to leave such analysis to
-post-processing codes.
-</P>
-<P>A very simple (yet fast) visualizer is provided with the LAMMPS
-package - see the <A HREF = "Section_tools.html#xmovie">xmovie</A> tool in <A HREF = "Section_tools.html">this
-section</A>.  It creates xyz projection views of
-atomic coordinates and animates them.  We find it very useful for
-debugging purposes.  For high-quality visualization we recommend the
-following packages:
-</P>
-<UL><LI><A HREF = "http://www.ks.uiuc.edu/Research/vmd">VMD</A>
-<LI><A HREF = "http://mt.seas.upenn.edu/Archive/Graphics/A">AtomEye</A>
-<LI><A HREF = "http://pymol.sourceforge.net">PyMol</A>
-<LI><A HREF = "http://www.bmsc.washington.edu/raster3d/raster3d.html">Raster3d</A>
-<LI><A HREF = "http://www.openrasmol.org">RasMol</A> 
-</UL>
-<P>Other features that LAMMPS does not yet (and may never) support are
-discussed in <A HREF = "Section_history.html">Section_history</A>.
-</P>
-<P>Finally, these are freely-available molecular dynamics codes, most of
-them parallel, which may be well-suited to the problems you want to
-model.  They can also be used in conjunction with LAMMPS to perform
-complementary modeling tasks.
-</P>
-<UL><LI><A HREF = "http://www.scripps.edu/brooks">CHARMM</A>
-<LI><A HREF = "http://amber.scripps.edu">AMBER</A>
-<LI><A HREF = "http://www.ks.uiuc.edu/Research/namd/">NAMD</A>
-<LI><A HREF = "http://www.emsl.pnl.gov/docs/nwchem/nwchem.html">NWCHEM</A>
-<LI><A HREF = "http://www.cse.clrc.ac.uk/msi/software/DL_POLY">DL_POLY</A>
-<LI><A HREF = "http://dasher.wustl.edu/tinker">Tinker</A> 
-</UL>
-
-
-
-
-
-
-
-
-
-
-
-
-<P>CHARMM, AMBER, NAMD, NWCHEM, and Tinker are designed primarily for
-modeling biological molecules.  CHARMM and AMBER use
-atom-decomposition (replicated-data) strategies for parallelism; NAMD
-and NWCHEM use spatial-decomposition approaches, similar to LAMMPS.
-Tinker is a serial code.  DL_POLY includes potentials for a variety of
-biological and non-biological materials; both a replicated-data and
-spatial-decomposition version exist.
-</P>
-<HR>
-
-<A NAME = "intro_4"></A><H4>1.4 Open source distribution 
-</H4>
-<P>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-
-charge, under the terms of the <A HREF = "http://www.gnu.org/copyleft/gpl.html">GNU Public License</A> (GPL).  This
-is often referred to as open-source distribution - see
-<A HREF = "http://www.gnu.org">www.gnu.org</A> or <A HREF = "http://www.opensource.org">www.opensource.org</A> for more
-details.  The legal text of the GPL is in the LICENSE file that is
-included in the LAMMPS distribution.
-</P>
-
-
-
-
-<P>Here is a summary of what the GPL means for LAMMPS users:
-</P>
-<P>(1) Anyone is free to use, modify, or extend LAMMPS in any way they
-choose, including for commercial purposes.
-</P>
-<P>(2) If you distribute a modified version of LAMMPS, it must remain
-open-source, meaning you distribute it under the terms of the GPL.
-You should clearly annotate such a code as a derivative version of
-LAMMPS.
-</P>
-<P>(3) If you release any code that includes LAMMPS source code, then it
-must also be open-sourced, meaning you distribute it under the terms
-of the GPL.
-</P>
-<P>(4) If you give LAMMPS files to someone else, the GPL LICENSE file and
-source file headers (including the copyright and GPL notices) should
-remain part of the code.
-</P>
-<P>In the spirit of an open-source code, these are various ways you can
-contribute to making LAMMPS better.  You can send email to the
-<A HREF = "http://lammps.sandia.gov/authors.html">developers</A> on any of these
-items.
-</P>
-<UL><LI>Point prospective users to the <A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A>.  Mention it in
-talks or link to it from your WWW site. 
-
-<LI>If you find an error or omission in this manual or on the <A HREF = "http://lammps.sandia.gov">LAMMPS WWW
-Site</A>, or have a suggestion for something to clarify or include,
-send an email to the
-<A HREF = "http://lammps.sandia.gov/authors.html">developers</A>. 
-
-<LI>If you find a bug, <A HREF = "Section_errors.html#err_2">Section_errors 2</A>
-describes how to report it. 
-
-<LI>If you publish a paper using LAMMPS results, send the citation (and
-any cool pictures or movies if you like) to add to the Publications,
-Pictures, and Movies pages of the <A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A>, with links
-and attributions back to you. 
-
-<LI>Create a new Makefile.machine that can be added to the src/MAKE
-directory. 
-
-<LI>The tools sub-directory of the LAMMPS distribution has various
-stand-alone codes for pre- and post-processing of LAMMPS data.  More
-details are given in <A HREF = "Section_tools.html">Section_tools</A>.  If you write
-a new tool that users will find useful, it can be added to the LAMMPS
-distribution. 
-
-<LI>LAMMPS is designed to be easy to extend with new code for features
-like potentials, boundary conditions, diagnostic computations, etc.
-<A HREF = "Section_modify.html">This section</A> gives details.  If you add a
-feature of general interest, it can be added to the LAMMPS
-distribution. 
-
-<LI>The Benchmark page of the <A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> lists LAMMPS
-performance on various platforms.  The files needed to run the
-benchmarks are part of the LAMMPS distribution.  If your machine is
-sufficiently different from those listed, your timing data can be
-added to the page. 
-
-<LI>You can send feedback for the User Comments page of the <A HREF = "http://lammps.sandia.gov">LAMMPS WWW
-Site</A>.  It might be added to the page.  No promises. 
-
-<LI>Cash.  Small denominations, unmarked bills preferred.  Paper sack OK.
-Leave on desk.  VISA also accepted.  Chocolate chip cookies
-encouraged. 
-</UL>
-<HR>
-
-<H4><A NAME = "intro_5"></A>1.5 Acknowledgments and citations 
-</H4>
-<P>LAMMPS development has been funded by the <A HREF = "http://www.doe.gov">US Department of
-Energy</A> (DOE), through its CRADA, LDRD, ASCI, and Genomes-to-Life
-programs and its <A HREF = "http://www.sc.doe.gov/ascr/home.html">OASCR</A> and <A HREF = "http://www.er.doe.gov/production/ober/ober_top.html">OBER</A> offices.
-</P>
-<P>Specifically, work on the latest version was funded in part by the US
-Department of Energy's Genomics:GTL program
-(<A HREF = "http://www.doegenomestolife.org">www.doegenomestolife.org</A>) under the <A HREF = "http://www.genomes2life.org">project</A>, "Carbon
-Sequestration in Synechococcus Sp.: From Molecular Machines to
-Hierarchical Modeling".
-</P>
-
-
-
-
-
-
-
-
-
-
-<P>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 <A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A>
-(http://lammps.sandia.gov):
-</P>
-<P>S. J. Plimpton, <B>Fast Parallel Algorithms for Short-Range Molecular
-Dynamics</B>, J Comp Phys, 117, 1-19 (1995).
-</P>
-<P>Other papers describing specific algorithms used in LAMMPS are listed
-under the <A HREF = "http://lammps.sandia.gov/cite.html">Citing LAMMPS link</A> of
-the LAMMPS WWW page.
-</P>
-<P>The <A HREF = "http://lammps.sandia.gov/papers.html">Publications link</A> 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
-<A HREF = "http://lammps.sandia.gov/pictures.html">Pictures</A> or
-<A HREF = "http://lammps.sandia.gov/movies.html">Movies</A> pages of the LAMMPS WWW
-site.
-</P>
-<P>The core group of LAMMPS developers is at Sandia National Labs:
-</P>
-<UL><LI>Steve Plimpton, sjplimp at sandia.gov
-<LI>Aidan Thompson, athomps at sandia.gov
-<LI>Paul Crozier, pscrozi at sandia.gov 
-</UL>
-<P>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.
-</P>
-<UL><LI>Axel Kohlmeyer (Temple U), akohlmey at gmail.com, SVN and Git repositories, indefatigable mail list responder, USER-CG-CMM and USER-OMP packages
-<LI>Roy Pollock (LLNL), Ewald and PPPM solvers
-<LI>Mike Brown (ORNL), brownw at ornl.gov, GPU package
-<LI>Greg Wagner (Sandia), gjwagne at sandia.gov, MEAM package for MEAM potential
-<LI>Mike Parks (Sandia), mlparks at sandia.gov, PERI package for Peridynamics
-<LI>Rudra Mukherjee (JPL), Rudranarayan.M.Mukherjee at jpl.nasa.gov, POEMS package for articulated rigid body motion
-<LI>Reese Jones (Sandia) and collaborators, rjones at sandia.gov, USER-ATC package for atom/continuum coupling
-<LI>Ilya Valuev (JIHT), valuev at physik.hu-berlin.de, USER-AWPMD package for wave-packet MD
-<LI>Christian Trott (U Tech Ilmenau), christian.trott at tu-ilmenau.de, USER-CUDA package
-<LI>Andres Jaramillo-Botero (Caltech), ajaramil at wag.caltech.edu, USER-EFF package for electron force field
-<LI>Christoph Kloss (JKU), Christoph.Kloss at jku.at, USER-LIGGGHTS package for granular models and granular/fluid coupling
-<LI>Metin Aktulga (LBL), hmaktulga at lbl.gov, USER-REAXC package for C version of ReaxFF
-<LI>Georg Gunzenmuller (EMI), georg.ganzenmueller at emi.fhg.de, USER-SPH package 
-</UL>
-<P>As discussed in <A HREF = "Section_history.html">Section_history</A>, 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:
-</P>
-<UL><LI>John Carpenter (Mayo Clinic, formerly at Cray Research)
-<LI>Terry Stouch (Lexicon Pharmaceuticals, formerly at Bristol Myers Squibb)
-<LI>Steve Lustig (Dupont)
-<LI>Jim Belak (LLNL) 
-</UL>
-</HTML>
--- a/doc/Section_modify.html
+++ b/doc/Section_modify.html
@ -1,789 +0,0 @@
-<HTML>
-<CENTER> <A HREF = "Section_tools.html">Previous Section</A> - <A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> -
-<A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A> - <A HREF = "Section_python.html">Next
-Section</A> 
-</CENTER>
-
-
-
-
-
-
-<HR>
-
-<H3>10. Modifying & extending LAMMPS 
-</H3>
-<P>This section describes how to customize LAMMPS by modifying
-and extending its source code.
-</P>
-10.1 <A HREF = "#mod_1">Atom styles</A><BR>
-10.2 <A HREF = "#mod_2">Bond, angle, dihedral, improper potentials</A><BR>
-10.3 <A HREF = "#mod_3">Compute styles</A><BR>
-10.4 <A HREF = "#mod_4">Dump styles</A><BR>
-10.5 <A HREF = "#mod_5">Dump custom output options</A><BR>
-10.6 <A HREF = "#mod_6">Fix styles</A> which include integrators,      temperature and pressure control, force constraints,      boundary conditions, diagnostic output, etc<BR>
-10.7 <A HREF = "mod_7">Input script commands</A><BR>
-10.8 <A HREF = "#mod_8">Kspace computations</A><BR>
-10.9 <A HREF = "#mod_9">Minimization styles</A><BR>
-10.10 <A HREF = "#mod_10">Pairwise potentials</A><BR>
-10.11 <A HREF = "#mod_11">Region styles</A><BR>
-10.12 <A HREF = "#mod_12">Body styles</A><BR>
-10.13 <A HREF = "#mod_13">Thermodynamic output options</A><BR>
-10.14 <A HREF = "#mod_14">Variable options</A><BR>
-10.15 <A HREF = "#mod_15">Submitting new features for inclusion in LAMMPS</A> <BR>
-
-<P>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.
-</P>
-<P>In this section, changes and additions users can make are listed along
-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
-<A HREF = "#mod_14">below</A>.
-</P>
-<P>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
-out what it does.  You will need some knowledge of C++ to be able to
-understand the hi-level structure of LAMMPS and its class
-organization, but functions (class methods) that do actual
-computations are written in vanilla C-style code and operate on simple
-C-style data structures (vectors and arrays).
-</P>
-<P>Most of the new features described in this section require you to
-write a new C++ derived class (except for exceptions described below,
-where you can make small edits to existing files).  Creating a new
-class requires 2 files, a source code file (*.cpp) and a header file
-(*.h).  The derived class must provide certain methods to work as a
-new option.  Depending on how different your new feature is compared
-to existing features, you can either derive from the base class
-itself, or from a derived class that already exists.  Enabling LAMMPS
-to invoke the new class is as simple as putting the two source
-files in the src dir and re-building LAMMPS.
-</P>
-<P>The advantage of C++ and its object-orientation is that all the code
-and variables needed to define the new feature are in the 2 files you
-write, and thus shouldn't make the rest of LAMMPS more complex or
-cause side-effect bugs.
-</P>
-<P>Here is a concrete example.  Suppose you write 2 files pair_foo.cpp
-and pair_foo.h that define a new class PairFoo that computes pairwise
-potentials described in the classic 1997 <A HREF = "#Foo">paper</A> by Foo, et al.
-If you wish to invoke those potentials in a LAMMPS input script with a
-command like
-</P>
-<PRE>pair_style foo 0.1 3.5 
-</PRE>
-<P>then your pair_foo.h file should be structured as follows:
-</P>
-<PRE>#ifdef PAIR_CLASS
-PairStyle(foo,PairFoo)
-#else
-...
-(class definition for PairFoo)
-...
-#endif 
-</PRE>
-<P>where "foo" is the style keyword in the pair_style command, and
-PairFoo is the class name defined in your pair_foo.cpp and pair_foo.h
-files.
-</P>
-<P>When you re-build LAMMPS, your new pairwise potential becomes part of
-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.
-</P>
-<P>As illustrated by this pairwise example, many kinds of options are
-referred to in the LAMMPS documentation as the "style" of a particular
-command.
-</P>
-<P>The instructions below give the header file for the base class that
-these styles are derived from.  Public variables in that file are ones
-used and set by the derived classes which are also used by the base
-class.  Sometimes they are also used by the rest of LAMMPS.  Virtual
-functions in the base class header file which are set = 0 are ones you
-must define in your new derived class to give it the functionality
-LAMMPS expects.  Virtual functions that are not set to 0 are functions
-you can optionally define.
-</P>
-<P>Additionally, new output options can be added directly to the
-thermo.cpp, dump_custom.cpp, and variable.cpp files as explained
-below.
-</P>
-<P>Here are additional guidelines for modifying LAMMPS and adding new
-functionality:
-</P>
-<UL><LI>Think about whether what you want to do would be better as a pre- or
-post-processing step.  Many computations are more easily and more
-quickly done that way. 
-
-<LI>Don't do anything within the timestepping of a run that isn't
-parallel.  E.g. don't accumulate a bunch of data on a single processor
-and analyze it.  You run the risk of seriously degrading the parallel
-efficiency. 
-
-<LI>If your new feature reads arguments or writes output, make sure you
-follow the unit conventions discussed by the <A HREF = "units.html">units</A>
-command. 
-
-<LI>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
-<A HREF = "http://lammps.sandia.gov/authors.html">developers</A>.  We might be
-interested in adding it to the LAMMPS distribution.  See further
-details on this at the bottom of this page. 
-</UL>
-<HR>
-
-<HR>
-
-<A NAME = "mod_1"></A><H4>10.1 Atom styles 
-</H4>
-<P>Classes that define an <A HREF = "atom_style.html">atom style</A> are derived from
-the AtomVec class and managed by the Atom class.  The atom style
-determines what attributes are associated with an atom.  A new atom
-style can be created if one of the existing atom styles does not
-define all the attributes you need to store and communicate with
-atoms.
-</P>
-<P>Atom_vec_atomic.cpp is a simple example of an atom style.
-</P>
-<P>Here is a brief description of methods you define in your new derived
-class.  See atom_vec.h for details.
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR><TD >init</TD><TD > one time setup (optional)</TD></TR>
-<TR><TD >grow</TD><TD > re-allocate atom arrays to longer lengths (required)</TD></TR>
-<TR><TD >grow_reset</TD><TD > make array pointers in Atom and AtomVec classes consistent (required)</TD></TR>
-<TR><TD >copy</TD><TD > copy info for one atom to another atom's array locations (required)</TD></TR>
-<TR><TD >pack_comm</TD><TD > store an atom's info in a buffer communicated every timestep (required)</TD></TR>
-<TR><TD >pack_comm_vel</TD><TD > add velocity info to communication buffer (required)</TD></TR>
-<TR><TD >pack_comm_hybrid</TD><TD > store extra info unique to this atom style (optional)</TD></TR>
-<TR><TD >unpack_comm</TD><TD > retrieve an atom's info from the buffer (required)</TD></TR>
-<TR><TD >unpack_comm_vel</TD><TD > also retrieve velocity info (required)</TD></TR>
-<TR><TD >unpack_comm_hybrid</TD><TD > retreive extra info unique to this atom style (optional)</TD></TR>
-<TR><TD >pack_reverse</TD><TD > store an atom's info in a buffer communicating partial forces  (required)</TD></TR>
-<TR><TD >pack_reverse_hybrid</TD><TD > store extra info unique to this atom style (optional)</TD></TR>
-<TR><TD >unpack_reverse</TD><TD > retrieve an atom's info from the buffer (required)</TD></TR>
-<TR><TD >unpack_reverse_hybrid</TD><TD > retreive extra info unique to this atom style (optional)</TD></TR>
-<TR><TD >pack_border</TD><TD > store an atom's info in a buffer communicated on neighbor re-builds (required)</TD></TR>
-<TR><TD >pack_border_vel</TD><TD > add velocity info to buffer (required)</TD></TR>
-<TR><TD >pack_border_hybrid</TD><TD > store extra info unique to this atom style (optional)</TD></TR>
-<TR><TD >unpack_border</TD><TD > retrieve an atom's info from the buffer (required)</TD></TR>
-<TR><TD >unpack_border_vel</TD><TD > also retrieve velocity info (required)</TD></TR>
-<TR><TD >unpack_border_hybrid</TD><TD > retreive extra info unique to this atom style (optional)</TD></TR>
-<TR><TD >pack_exchange</TD><TD > store all an atom's info to migrate to another processor (required)</TD></TR>
-<TR><TD >unpack_exchange</TD><TD > retrieve an atom's info from the buffer (required)</TD></TR>
-<TR><TD >size_restart</TD><TD > number of restart quantities associated with proc's atoms (required)</TD></TR>
-<TR><TD >pack_restart</TD><TD > pack atom quantities into a buffer (required)</TD></TR>
-<TR><TD >unpack_restart</TD><TD > unpack atom quantities from a buffer (required)</TD></TR>
-<TR><TD >create_atom</TD><TD > create an individual atom of this style (required)</TD></TR>
-<TR><TD >data_atom</TD><TD > parse an atom line from the data file (required)</TD></TR>
-<TR><TD >data_atom_hybrid</TD><TD > parse additional atom info unique to this atom style (optional)</TD></TR>
-<TR><TD >data_vel</TD><TD > parse one line of velocity information from data file (optional)</TD></TR>
-<TR><TD >data_vel_hybrid</TD><TD > parse additional velocity data unique to this atom style (optional)</TD></TR>
-<TR><TD >memory_usage</TD><TD > tally memory allocated by atom arrays (required) 
-</TD></TR></TABLE></DIV>
-
-<P>The constructor of the derived class sets values for several variables
-that you must set when defining a new atom style, which are documented
-in atom_vec.h.  New atom arrays are defined in atom.cpp.  Search for
-the word "customize" and you will find locations you will need to
-modify.
-</P>
-<P>IMPORTANT NOTE: It is possible to add some attributes, such as a
-molecule ID, to atom styles that do not have them via the <A HREF = "fix_property_atom.html">fix
-property/atom</A> command.  This command also
-allows new custom attributes consisting of extra integer or
-floating-point values to be added to atoms.  See the <A HREF = "fix_property_atom.html">fix
-property/atom</A> doc page for examples of cases
-where this is useful and details on how to initialize, access, and
-output the custom values.
-</P>
-<P>New <A HREF = "pair_style.html">pair styles</A>, <A HREF = "fix.html">fixes</A>, or
-<A HREF = "compute.html">computes</A> can be added to LAMMPS, as discussed below.
-The code for these classes can use the per-atom properties defined by
-fix property/atom.  The Atom class has a find_custom() method that is
-useful in this context:
-</P>
-<PRE>int index = atom->find_custom(char *name, int &flag); 
-</PRE>
-<P>The "name" of a custom attribute, as specified in the <A HREF = "fix_property_atom.html">fix
-property/atom</A> command, is checked to verify
-that it exists and its index is returned.  The method also sets flag =
-0/1 depending on whether it is an integer or floating-point attribute.
-The vector of values associated with the attribute can then be
-accessed using the returned index as
-</P>
-<PRE>int *ivector = atom->ivector[index];
-double *dvector = atom->dvector[index]; 
-</PRE>
-<P>Ivector or dvector are vectors of length Nlocal = # of owned atoms,
-which store the attributes of individual atoms.
-</P>
-<HR>
-
-<A NAME = "mod_2"></A><H4>10.2 Bond, angle, dihedral, improper potentials 
-</H4>
-<P>Classes that compute molecular interactions are derived from the Bond,
-Angle, Dihedral, and Improper classes.  New styles can be created to
-add new potentials to LAMMPS.
-</P>
-<P>Bond_harmonic.cpp is the simplest example of a bond style.  Ditto for
-the harmonic forms of the angle, dihedral, and improper style
-commands.
-</P>
-<P>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.
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR><TD >init</TD><TD > check if all coefficients are set, calls <I>init_style</I> (optional)</TD></TR>
-<TR><TD >init_style</TD><TD > check if style specific conditions are met (optional)</TD></TR>
-<TR><TD >compute</TD><TD > compute the molecular interactions (required)</TD></TR>
-<TR><TD >settings</TD><TD > apply global settings for all types (optional)</TD></TR>
-<TR><TD >coeff</TD><TD > set coefficients for one type (required)</TD></TR>
-<TR><TD >equilibrium_distance</TD><TD > length of bond, used by SHAKE (required, bond only)</TD></TR>
-<TR><TD >equilibrium_angle</TD><TD > opening of angle, used by SHAKE (required, angle only)</TD></TR>
-<TR><TD >write & read_restart</TD><TD > writes/reads coeffs to restart files (required)</TD></TR>
-<TR><TD >single</TD><TD > force and energy of a single bond or angle (required, bond or angle only)</TD></TR>
-<TR><TD >memory_usage</TD><TD > tally memory allocated by the style (optional) 
-</TD></TR></TABLE></DIV>
-
-<HR>
-
-<A NAME = "mod_3"></A><H4>10.3 Compute styles 
-</H4>
-<P>Classes that compute scalar and vector quantities like temperature
-and the pressure tensor, as well as classes that compute per-atom
-quantities like kinetic energy and the centro-symmetry parameter
-are derived from the Compute class.  New styles can be created
-to add new calculations to LAMMPS.
-</P>
-<P>Compute_temp.cpp is a simple example of computing a scalar
-temperature.  Compute_ke_atom.cpp is a simple example of computing
-per-atom kinetic energy.
-</P>
-<P>Here is a brief description of methods you define in your new derived
-class.  See compute.h for details.
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR><TD >init</TD><TD > perform one time setup (required)</TD></TR>
-<TR><TD >init_list</TD><TD > neighbor list setup, if needed (optional)</TD></TR>
-<TR><TD >compute_scalar</TD><TD > compute a scalar quantity (optional)</TD></TR>
-<TR><TD >compute_vector</TD><TD > compute a vector of quantities (optional)</TD></TR>
-<TR><TD >compute_peratom</TD><TD > compute one or more quantities per atom (optional)</TD></TR>
-<TR><TD >compute_local</TD><TD > compute one or more quantities per processor (optional)</TD></TR>
-<TR><TD >pack_comm</TD><TD > pack a buffer with items to communicate (optional)</TD></TR>
-<TR><TD >unpack_comm</TD><TD > unpack the buffer (optional)</TD></TR>
-<TR><TD >pack_reverse</TD><TD > pack a buffer with items to reverse communicate (optional)</TD></TR>
-<TR><TD >unpack_reverse</TD><TD > unpack the buffer (optional)</TD></TR>
-<TR><TD >remove_bias</TD><TD > remove velocity bias from one atom (optional)</TD></TR>
-<TR><TD >remove_bias_all</TD><TD > remove velocity bias from all atoms in group (optional)</TD></TR>
-<TR><TD >restore_bias</TD><TD > restore velocity bias for one atom after remove_bias (optional)</TD></TR>
-<TR><TD >restore_bias_all</TD><TD > same as before, but for all atoms in group (optional)</TD></TR>
-<TR><TD >memory_usage</TD><TD > tally memory usage (optional) 
-</TD></TR></TABLE></DIV>
-
-<HR>
-
-<A NAME = "mod_4"></A><H4>10.4 Dump styles 
-</H4>
-<A NAME = "mod_5"></A><H4>10.5 Dump custom output options 
-</H4>
-<P>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
-class can be added, but it is typically simpler to modify the
-DumpCustom class contained in the dump_custom.cpp file.
-</P>
-<P>Dump_atom.cpp is a simple example of a derived dump class.
-</P>
-<P>Here is a brief description of methods you define in your new derived
-class.  See dump.h for details.
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR><TD >write_header</TD><TD > write the header section of a snapshot of atoms</TD></TR>
-<TR><TD >count</TD><TD > count the number of lines a processor will output</TD></TR>
-<TR><TD >pack</TD><TD > pack a proc's output data into a buffer</TD></TR>
-<TR><TD >write_data</TD><TD > write a proc's data to a file 
-</TD></TR></TABLE></DIV>
-
-<P>See the <A HREF = "dump.html">dump</A> command and its <I>custom</I> style for a list of
-keywords for atom information that can already be dumped by
-DumpCustom.  It includes options to dump per-atom info from Compute
-classes, so adding a new derived Compute class is one way to calculate
-new quantities to dump.
-</P>
-<P>Alternatively, you can add new keywords to the dump custom command.
-Search for the word "customize" in dump_custom.cpp to see the
-half-dozen or so locations where code will need to be added.
-</P>
-<HR>
-
-<A NAME = "mod_6"></A><H4>10.6 Fix styles 
-</H4>
-<P>In LAMMPS, a "fix" is any operation that is computed during
-timestepping that alters some property of the system.  Essentially
-everything that happens during a simulation besides force computation,
-neighbor list construction, and output, is a "fix".  This includes
-time integration (update of coordinates and velocities), force
-constraints or boundary conditions (SHAKE or walls), and diagnostics
-(compute a diffusion coefficient).  New styles can be created to add
-new options to LAMMPS.
-</P>
-<P>Fix_setforce.cpp is a simple example of setting forces on atoms to
-prescribed values.  There are dozens of fix options already in LAMMPS;
-choose one as a template that is similar to what you want to
-implement.
-</P>
-<P>Here is a brief description of methods you can define in your new
-derived class.  See fix.h for details.
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR><TD >setmask</TD><TD > determines when the fix is called during the timestep (required)</TD></TR>
-<TR><TD >init</TD><TD > initialization before a run (optional)</TD></TR>
-<TR><TD >setup_pre_exchange</TD><TD > called before atom exchange in setup (optional)</TD></TR>
-<TR><TD >setup_pre_force</TD><TD > called before force computation in setup (optional)</TD></TR>
-<TR><TD >setup</TD><TD > called immediately before the 1st timestep and after forces are computed (optional)</TD></TR>
-<TR><TD >min_setup_pre_force</TD><TD > like setup_pre_force, but for minimizations instead of MD runs (optional)</TD></TR>
-<TR><TD >min_setup</TD><TD > like setup, but for minimizations instead of MD runs (optional)</TD></TR>
-<TR><TD >initial_integrate</TD><TD > called at very beginning of each timestep (optional)</TD></TR>
-<TR><TD >pre_exchange</TD><TD > called before atom exchange on re-neighboring steps (optional)</TD></TR>
-<TR><TD >pre_neighbor</TD><TD > called before neighbor list build (optional)</TD></TR>
-<TR><TD >pre_force</TD><TD > called before pair & molecular forces are computed (optional)</TD></TR>
-<TR><TD >post_force</TD><TD > called after pair & molecular forces are computed and communicated (optional)</TD></TR>
-<TR><TD >final_integrate</TD><TD > called at end of each timestep (optional)</TD></TR>
-<TR><TD >end_of_step</TD><TD > called at very end of timestep (optional)</TD></TR>
-<TR><TD >write_restart</TD><TD > dumps fix info to restart file (optional)</TD></TR>
-<TR><TD >restart</TD><TD > uses info from restart file to re-initialize the fix (optional)</TD></TR>
-<TR><TD >grow_arrays</TD><TD > allocate memory for atom-based arrays used by fix (optional)</TD></TR>
-<TR><TD >copy_arrays</TD><TD > copy atom info when an atom migrates to a new processor (optional)</TD></TR>
-<TR><TD >pack_exchange</TD><TD > store atom's data in a buffer (optional)</TD></TR>
-<TR><TD >unpack_exchange</TD><TD > retrieve atom's data from a buffer (optional)</TD></TR>
-<TR><TD >pack_restart</TD><TD > store atom's data for writing to restart file (optional)</TD></TR>
-<TR><TD >unpack_restart</TD><TD > retrieve atom's data from a restart file buffer (optional)</TD></TR>
-<TR><TD >size_restart</TD><TD > size of atom's data (optional)</TD></TR>
-<TR><TD >maxsize_restart</TD><TD > max size of atom's data (optional)</TD></TR>
-<TR><TD >setup_pre_force_respa</TD><TD > same as setup_pre_force, but for rRESPA (optional)</TD></TR>
-<TR><TD >initial_integrate_respa</TD><TD > same as initial_integrate, but for rRESPA (optional)</TD></TR>
-<TR><TD >post_integrate_respa</TD><TD > called after the first half integration step is done in rRESPA (optional)</TD></TR>
-<TR><TD >pre_force_respa</TD><TD > same as pre_force, but for rRESPA (optional)</TD></TR>
-<TR><TD >post_force_respa</TD><TD > same as post_force, but for rRESPA (optional)</TD></TR>
-<TR><TD >final_integrate_respa</TD><TD > same as final_integrate, but for rRESPA (optional)</TD></TR>
-<TR><TD >min_pre_force</TD><TD > called after pair & molecular forces are computed in minimizer (optional)</TD></TR>
-<TR><TD >min_post_force</TD><TD > called after pair & molecular forces are computed and communicated in minmizer (optional)</TD></TR>
-<TR><TD >min_store</TD><TD > store extra data for linesearch based minimization on a LIFO stack (optional)</TD></TR>
-<TR><TD >min_pushstore</TD><TD > push the minimization LIFO stack one element down (optional)</TD></TR>
-<TR><TD >min_popstore</TD><TD > pop the minimization LIFO stack one element up (optional)</TD></TR>
-<TR><TD >min_clearstore</TD><TD > clear minimization LIFO stack (optional)</TD></TR>
-<TR><TD >min_step</TD><TD > reset or move forward on line search minimization (optional)</TD></TR>
-<TR><TD >min_dof</TD><TD > report number of degrees of freedom <I>added</I> by this fix in minimization (optional)</TD></TR>
-<TR><TD >max_alpha</TD><TD > report maximum allowed step size during linesearch minimization (optional)</TD></TR>
-<TR><TD >pack_comm</TD><TD > pack a buffer to communicate a per-atom quantity (optional)</TD></TR>
-<TR><TD >unpack_comm</TD><TD > unpack a buffer to communicate a per-atom quantity (optional)</TD></TR>
-<TR><TD >pack_reverse_comm</TD><TD > pack a buffer to reverse communicate a per-atom quantity (optional)</TD></TR>
-<TR><TD >unpack_reverse_comm</TD><TD > unpack a buffer to reverse communicate a per-atom quantity (optional)</TD></TR>
-<TR><TD >dof</TD><TD > report number of degrees of freedom <I>removed</I> by this fix during MD (optional)</TD></TR>
-<TR><TD >compute_scalar</TD><TD > return a global scalar property that the fix computes (optional)</TD></TR>
-<TR><TD >compute_vector</TD><TD > return a component of a vector property that the fix computes (optional)</TD></TR>
-<TR><TD >compute_array</TD><TD > return a component of an array property that the fix computes (optional)</TD></TR>
-<TR><TD >deform</TD><TD > called when the box size is changed (optional)</TD></TR>
-<TR><TD >reset_target</TD><TD > called when a change of the target temperature is requested during a run (optional)</TD></TR>
-<TR><TD >reset_dt</TD><TD > is called when a change of the time step is requested during a run (optional)</TD></TR>
-<TR><TD >modify_param</TD><TD > called when a fix_modify request is executed (optional)</TD></TR>
-<TR><TD >memory_usage</TD><TD > report memory used by fix (optional)</TD></TR>
-<TR><TD >thermo</TD><TD > compute quantities for thermodynamic output (optional) 
-</TD></TR></TABLE></DIV>
-
-<P>Typically, only a small fraction of these methods are defined for a
-particular fix.  Setmask is mandatory, as it determines when the fix
-will be invoked during the timestep.  Fixes that perform time
-integration (<I>nve</I>, <I>nvt</I>, <I>npt</I>) implement initial_integrate() and
-final_integrate() to perform velocity Verlet updates.  Fixes that
-constrain forces implement post_force().
-</P>
-<P>Fixes that perform diagnostics typically implement end_of_step().  For
-an end_of_step fix, one of your fix arguments must be the variable
-"nevery" which is used to determine when to call the fix and you must
-set this variable in the constructor of your fix.  By convention, this
-is the first argument the fix defines (after the ID, group-ID, style).
-</P>
-<P>If the fix needs to store information for each atom that persists from
-timestep to timestep, it can manage that memory and migrate the info
-with the atoms as they move from processors to processor by
-implementing the grow_arrays, copy_arrays, pack_exchange, and
-unpack_exchange methods.  Similarly, the pack_restart and
-unpack_restart methods can be implemented to store information about
-the fix in restart files.  If you wish an integrator or force
-constraint fix to work with rRESPA (see the <A HREF = "run_style.html">run_style</A>
-command), the initial_integrate, post_force_integrate, and
-final_integrate_respa methods can be implemented.  The thermo method
-enables a fix to contribute values to thermodynamic output, as printed
-quantities and/or to be summed to the potential energy of the system.
-</P>
-<HR>
-
-<A NAME = "mod_7"></A><H4>10.7 Input script commands 
-</H4>
-<P>New commands can be added to LAMMPS input scripts by adding new
-classes that have a "command" method.  For example, the create_atoms,
-read_data, velocity, and run commands are all implemented in this
-fashion.  When such a command is encountered in the LAMMPS input
-script, LAMMPS simply creates a class with the corresponding name,
-invokes the "command" method of the class, and passes it the arguments
-from the input script.  The command method can perform whatever
-operations it wishes on LAMMPS data structures.
-</P>
-<P>The single method your new class must define is as follows:
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR><TD >command</TD><TD > operations performed by the new command 
-</TD></TR></TABLE></DIV>
-
-<P>Of course, the new class can define other methods and variables as
-needed.
-</P>
-<HR>
-
-<A NAME = "mod_8"></A><H4>10.8 Kspace computations 
-</H4>
-<P>Classes that compute long-range Coulombic interactions via K-space
-representations (Ewald, PPPM) are derived from the KSpace class.  New
-styles can be created to add new K-space options to LAMMPS.
-</P>
-<P>Ewald.cpp is an example of computing K-space interactions.
-</P>
-<P>Here is a brief description of methods you define in your new derived
-class.  See kspace.h for details.
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR><TD >init</TD><TD > initialize the calculation before a run</TD></TR>
-<TR><TD >setup</TD><TD > computation before the 1st timestep of a run</TD></TR>
-<TR><TD >compute</TD><TD > every-timestep computation</TD></TR>
-<TR><TD >memory_usage</TD><TD > tally of memory usage 
-</TD></TR></TABLE></DIV>
-
-<HR>
-
-<A NAME = "mod_9"></A><H4>10.9 Minimization styles 
-</H4>
-<P>Classes that perform energy minimization derived from the Min class.
-New styles can be created to add new minimization algorithms to
-LAMMPS.
-</P>
-<P>Min_cg.cpp is an example of conjugate gradient minimization.
-</P>
-<P>Here is a brief description of methods you define in your new derived
-class.  See min.h for details.
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR><TD >init</TD><TD > initialize the minimization before a run</TD></TR>
-<TR><TD >run</TD><TD > perform the minimization</TD></TR>
-<TR><TD >memory_usage</TD><TD > tally of memory usage 
-</TD></TR></TABLE></DIV>
-
-<HR>
-
-<A NAME = "mod_10"></A><H4>10.10 Pairwise potentials 
-</H4>
-<P>Classes that compute pairwise interactions are derived from the Pair
-class.  In LAMMPS, pairwise calculation include manybody potentials
-such as EAM or Tersoff where particles interact without a static bond
-topology.  New styles can be created to add new pair potentials to
-LAMMPS.
-</P>
-<P>Pair_lj_cut.cpp is a simple example of a Pair class, though it
-includes some optional methods to enable its use with rRESPA.
-</P>
-<P>Here is a brief description of the class methods in pair.h:
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR><TD >compute</TD><TD > workhorse routine that computes pairwise interactions</TD></TR>
-<TR><TD >settings</TD><TD > reads the input script line with arguments you define</TD></TR>
-<TR><TD >coeff</TD><TD > set coefficients for one i,j type pair</TD></TR>
-<TR><TD >init_one</TD><TD > perform initialization for one i,j type pair</TD></TR>
-<TR><TD >init_style</TD><TD > initialization specific to this pair style</TD></TR>
-<TR><TD >write & read_restart</TD><TD > write/read i,j pair coeffs to restart files</TD></TR>
-<TR><TD >write & read_restart_settings</TD><TD > write/read global settings to restart files</TD></TR>
-<TR><TD >single</TD><TD > force and energy of a single pairwise interaction between 2 atoms</TD></TR>
-<TR><TD >compute_inner/middle/outer</TD><TD > versions of compute used by rRESPA 
-</TD></TR></TABLE></DIV>
-
-<P>The inner/middle/outer routines are optional.
-</P>
-<HR>
-
-<A NAME = "mod_11"></A><H4>10.11 Region styles 
-</H4>
-<P>Classes that define geometric regions are derived from the Region
-class.  Regions are used elsewhere in LAMMPS to group atoms, delete
-atoms to create a void, insert atoms in a specified region, etc.  New
-styles can be created to add new region shapes to LAMMPS.
-</P>
-<P>Region_sphere.cpp is an example of a spherical region.
-</P>
-<P>Here is a brief description of methods you define in your new derived
-class.  See region.h for details.
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR><TD >match</TD><TD > determine whether a point is in the region 
-</TD></TR></TABLE></DIV>
-
-<HR>
-
-<A NAME = "mod_12"></A><H4>10.11 Body styles 
-</H4>
-<P>Classes that define body particles are derived from the Body class.
-Body particles can represent complex entities, such as surface meshes
-of discrete points, collections of sub-particles, deformable objects,
-etc.
-</P>
-<P>See <A HREF = "Section_howto.html#howto_14">Section_howto 14</A> of the manual for
-an overview of using body particles and the <A HREF = "body.html">body</A> doc page
-for details on the various body styles LAMMPS supports.  New styles
-can be created to add new kinds of body particles to LAMMPS.
-</P>
-<P>Body_nparticle.cpp is an example of a body particle that is treated as
-a rigid body containing N sub-particles.
-</P>
-<P>Here is a brief description of methods you define in your new derived
-class.  See body.h for details.
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR><TD >data_body</TD><TD > process a line from the Bodies section of a data file</TD></TR>
-<TR><TD >noutrow</TD><TD > number of sub-particles output is generated for</TD></TR>
-<TR><TD >noutcol</TD><TD > number of values per-sub-particle output is generated for</TD></TR>
-<TR><TD >output</TD><TD > output values for the Mth sub-particle</TD></TR>
-<TR><TD >pack_comm_body</TD><TD > body attributes to communicate every timestep</TD></TR>
-<TR><TD >unpack_comm_body</TD><TD > unpacking of those attributes</TD></TR>
-<TR><TD >pack_border_body</TD><TD > body attributes to communicate when reneighboring is done</TD></TR>
-<TR><TD >unpack_border_body</TD><TD > unpacking of those attributes 
-</TD></TR></TABLE></DIV>
-
-<HR>
-
-<A NAME = "mod_13"></A><H4>10.13 Thermodynamic output options 
-</H4>
-<P>There is one class that computes and prints thermodynamic information
-to the screen and log file; see the file thermo.cpp.
-</P>
-<P>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 <A HREF = "thermo_style.html">thermo_style</A> command for a list
-of defined quantities.
-</P>
-<P>The thermo styles (one, multi, etc) are simply lists of keywords.
-Adding a new style thus only requires defining a new list of keywords.
-Search for the word "customize" with references to "thermo style" in
-thermo.cpp to see the two locations where code will need to be added.
-</P>
-<P>New keywords can also be added to thermo.cpp to compute new quantities
-for output.  Search for the word "customize" with references to
-"keyword" in thermo.cpp to see the several locations where code will
-need to be added.
-</P>
-<P>Note that the <A HREF = "thermo.html">thermo_style custom</A> command already allows
-for thermo output of quantities calculated by <A HREF = "fix.html">fixes</A>,
-<A HREF = "compute.html">computes</A>, and <A HREF = "variable.html">variables</A>.  Thus, it may
-be simpler to compute what you wish via one of those constructs, than
-by adding a new keyword to the thermo command.
-</P>
-<HR>
-
-<A NAME = "mod_14"></A><H4>10.14 Variable options 
-</H4>
-<P>There is one class that computes and stores <A HREF = "variable.html">variable</A>
-information in LAMMPS; see the file variable.cpp.  The value
-associated with a variable can be periodically printed to the screen
-via the <A HREF = "print.html">print</A>, <A HREF = "fix_print.html">fix print</A>, or
-<A HREF = "thermo_style.html">thermo_style custom</A> commands.  Variables of style
-"equal" can compute complex equations that involve the following types
-of arguments:
-</P>
-<PRE>thermo keywords = ke, vol, atoms, ...
-other variables = v_a, v_myvar, ...
-math functions = div(x,y), mult(x,y), add(x,y), ...
-group functions = mass(group), xcm(group,x), ...
-atom values = x[123], y[3], vx[34], ...
-compute values = c_mytemp[0], c_thermo_press[3], ... 
-</PRE>
-<P>Adding keywords for the <A HREF = "thermo_style.html">thermo_style custom</A> command
-(which can then be accessed by variables) was discussed
-<A HREF = "Section_modify.html#thermo">here</A> on this page.
-</P>
-<P>Adding a new math function of one or two arguments can be done by
-editing one section of the Variable::evaulate() method.  Search for
-the word "customize" to find the appropriate location.
-</P>
-<P>Adding a new group function can be done by editing one section of the
-Variable::evaulate() method.  Search for the word "customize" to find
-the appropriate location.  You may need to add a new method to the
-Group class as well (see the group.cpp file).
-</P>
-<P>Accessing a new atom-based vector can be done by editing one section
-of the Variable::evaulate() method.  Search for the word "customize"
-to find the appropriate location.
-</P>
-<P>Adding new <A HREF = "compute.html">compute styles</A> (whose calculated values can
-then be accessed by variables) was discussed
-<A HREF = "Section_modify.html#compute">here</A> on this page.
-</P>
-<HR>
-
-<HR>
-
-<A NAME = "mod_15"></A><H4>10.15 Submitting new features for inclusion in LAMMPS 
-</H4>
-<P>We encourage users to submit new features to <A HREF = "http://lammps.sandia.gov/authors.html">the
-developers</A> that they add to
-LAMMPS, especially if you think they 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 <A HREF = "Section_start.html#start_3">standard package</A>.
-Else we will add them as a user-contributed file or package.  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.
-</P>
-<P>Note that by providing us the files to release, you are agreeing to
-make them open-source, i.e. we can release them under the terms of the
-GPL, used as a license for the rest of LAMMPS.  See <A HREF = "Section_intro.html#intro_4">Section
-1.4</A> for details.
-</P>
-<P>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 <A HREF = "http://lammps.sandia.gov/authors.html">Authors page</A>
-of the <A HREF = "http://lammps.sandia.gov">LAMMPS WWW site</A>), 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 in some way that breaks it (an
-unusual event).
-</P>
-<P>NOTE: If you prefer to actively develop and support your add-on
-feature yourself, then you may wish to make it available for download
-from your own website, as a user package that LAMMPS users can add to
-their copy of LAMMPS.  See the <A HREF = "http://lammps.sandia.gov/offsite.html">Offsite LAMMPS packages and
-tools</A> page of the LAMMPS web
-site for examples of groups that do this.  We are happy to advertise
-your package and web site from that page.  Simply email the
-<A HREF = "http://lammps.sandia.gov/authors.html">developers</A> with info about
-your package and we will post it there.
-</P>
-<P>The previous sections of this doc page describe how to add new "style"
-files 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 typically
-do not require changes to the main core of LAMMPS; they are simply
-add-on files.  If you think your new feature requires non-trivial
-changes in core LAMMPS files, you'll need to <A HREF = "http://lammps.sandia.gov/authors.html">communicate with the
-developers</A>, since we may or may
-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.
-</P>
-<P>Here are the steps you need to follow to submit a single file or user
-package for our consideration.  Following these steps will save both
-you and us time.  See existing files in packages in the src dir for
-examples.
-</P>
-<UL><LI>All source files you provide must compile with the most current
-version of LAMMPS. 
-
-<LI>If you want your file(s) to be added to main LAMMPS or one of its
-standard packages, then it needs to be written in a style compatible
-with other LAMMPS source files.  This is so the developers can
-understand it and hopefully maintain it.  This basically means that
-the code accesses data structures, performs its operations, and is
-formatted similar to other LAMMPS source files, including the use of
-the error class for error and warning messages. 
-
-<LI>If you want your contribution to be added as a user-contributed
-feature, and it's a single file (actually a *.cpp and *.h file) it can
-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.  
-
-<LI>If you want your contribution to be added as a user-contribution and
-it 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 text file.  The README
-should contain your name and contact information and a brief
-description of what your new package does.  If your files depend on
-other LAMMPS style files also being installed (e.g. because your file
-is a derived class from the other LAMMPS class), then an Install.sh
-file is also needed to check for those dependencies.  See other README
-and Install.sh files in other USER directories as examples.  Send us a
-tarball of this USER-FOO directory. 
-
-<LI>Your new source files need to have the LAMMPS copyright, GPL notice,
-and your name and email address at the top, like other
-user-contributed LAMMPS source files.  They need to create a class
-that is inside the LAMMPS namespace.  If the file is for one of the
-USER packages, including USER-MISC, then we are not as picky about the
-coding style (see above).  I.e. the files do not need to be in the
-same stylistic format and syntax as other LAMMPS files, though that
-would be nice for developers as well as users who try to read your
-code. 
-
-<LI>You must also create 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 auto-convert to HTML.  Thus they must
-be in the same format as other *.txt files in the lammps/doc directory
-for similar commands and styles; use one or more of them as a starting
-point.  As appropriate, the text files can include links to equations
-(see doc/Eqs/*.tex for examples, we auto-create the associated JPG
-files), or figures (see doc/JPG for examples), or even additional PDF
-files with further details (see doc/PDF for examples).  The doc page
-should also include literature citations as appropriate; see the
-bottom of doc/fix_nh.txt for examples and the earlier part of the same
-file for how to format the cite itself.  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 examples of how to do this.  The
-txt2html tool we use to convert to HTML can be downloaded from <A HREF = "http://www.sandia.gov/~sjplimp/download.html">this
-site</A>, so you can perform
-the HTML conversion yourself to proofread your doc page. 
-
-<LI>For a new package (or even a single command) you can include one or
-more example scripts.  These should run in no more than 1 minute, even
-on a single processor, and not require large data files as input.  See
-directories under examples/USER for examples of input scripts other
-users provided for their packages. 
-
-<LI>If there is a paper of yours describing your feature (either the
-algorithm/science behind the feature itself, or its initial usage, or
-its implementation in LAMMPS), you can add the citation to the *.cpp
-source file.  See src/USER-EFF/atom_vec_electron.cpp for an example.
-A LaTeX citation is stored in a variable at the top of the file and a
-single line of code that references the variable is added to the
-constructor of the class.  Whenever a user invokes your feature from
-their input script, this will cause LAMMPS to output the citation to a
-log.cite file and prompt the user to examine the file.  Note that you
-should only use this for a paper you or your group authored.
-E.g. adding a cite in the code for a paper by Nose and Hoover if you
-write a fix that implements their integrator is not the intended
-usage.  That kind of citation should just be in the doc page you
-provide. 
-</UL>
-<P>Finally, as a general rule-of-thumb, the more clear and
-self-explanatory you make your doc and README files, and the easier
-you make it for people to get started, e.g. by providing example
-scripts, the more likely it is that users will try out your new
-feature.
-</P>
-<HR>
-
-<HR>
-
-<A NAME = "Foo"></A>
-
-<P><B>(Foo)</B> Foo, Morefoo, and Maxfoo, J of Classic Potentials, 75, 345 (1997).
-</P>
-</HTML>
--- a/doc/Section_packages.html
+++ b/doc/Section_packages.html
@ -1,590 +0,0 @@
-<HTML>
-<CENTER><A HREF = "Section_commands.html">Previous Section</A> - <A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> -
-<A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A> - <A HREF = "Section_accelerate.html">Next
-Section</A> 
-</CENTER>
-
-
-
-
-
-
-<HR>
-
-<H3>4. Packages 
-</H3>
-<P>This section gives a quick overview of the add-on packages that extend
-LAMMPS functionality.
-</P>
-4.1 <A HREF = "#pkg_1">Standard packages</A><BR>
-4.2 <A HREF = "#pkg_2">User packages</A> <BR>
-
-<P>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.
-</P>
-<P>See <A HREF = "Section_start.html#start_3">Section_start 3</A> 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.
-</P>
-<P>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.
-</P>
-<HR>
-
-<HR>
-
-<H4><A NAME = "pkg_1"></A>4.1 Standard packages 
-</H4>
-<P>The current list of standard packages is as follows:
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR ALIGN="center"><TD >Package</TD><TD > Description</TD><TD > Author(s)</TD><TD > Doc page</TD><TD > Example</TD><TD > Library</TD></TR>
-<TR ALIGN="center"><TD >ASPHERE</TD><TD > aspherical particles</TD><TD > -</TD><TD > <A HREF = "Section_howto.html#howto_14">Section_howto 6.14</A></TD><TD > ellipse</TD><TD > -</TD></TR>
-<TR ALIGN="center"><TD >BODY</TD><TD > body-style particles</TD><TD > -</TD><TD > <A HREF = "body.html">body</A></TD><TD > body</TD><TD > -</TD></TR>
-<TR ALIGN="center"><TD >CLASS2</TD><TD > class 2 force fields</TD><TD > -</TD><TD > <A HREF = "pair_class2.html">pair_style lj/class2</A></TD><TD > -</TD><TD > -</TD></TR>
-<TR ALIGN="center"><TD >COLLOID</TD><TD > colloidal particles</TD><TD > -</TD><TD > <A HREF = "atom_style.html">atom_style colloid</A></TD><TD > colloid</TD><TD > -</TD></TR>
-<TR ALIGN="center"><TD >CORESHELL</TD><TD > adiabatic core/shell model</TD><TD > Hendrik Heenen (Technical U of Munich)</TD><TD > <A HREF = "Section_howto.html#howto_25">Section_howto 6.25</A></TD><TD > coreshell</TD><TD > -</TD></TR>
-<TR ALIGN="center"><TD >DIPOLE</TD><TD > point dipole particles</TD><TD > -</TD><TD > <A HREF = "pair_dipole.html">pair_style dipole/cut</A></TD><TD > dipole</TD><TD > -</TD></TR>
-<TR ALIGN="center"><TD >FLD</TD><TD > Fast Lubrication Dynamics</TD><TD > Kumar & Bybee & Higdon (1)</TD><TD > <A HREF = "pair_lubricateU.html">pair_style lubricateU</A></TD><TD > -</TD><TD > -</TD></TR>
-<TR ALIGN="center"><TD >GPU</TD><TD > GPU-enabled styles</TD><TD > Mike Brown (ORNL)</TD><TD > <A HREF = "accelerate_gpu.html">Section accelerate</A></TD><TD > gpu</TD><TD > lib/gpu</TD></TR>
-<TR ALIGN="center"><TD >GRANULAR</TD><TD > granular systems</TD><TD > -</TD><TD > <A HREF = "Section_howto.html#howto_6">Section_howto 6.6</A></TD><TD > pour</TD><TD > -</TD></TR>
-<TR ALIGN="center"><TD >KIM</TD><TD > openKIM potentials</TD><TD > Smirichinski & Elliot & Tadmor (3)</TD><TD > <A HREF = "pair_kim.html">pair_style kim</A></TD><TD > kim</TD><TD > KIM</TD></TR>
-<TR ALIGN="center"><TD >KOKKOS</TD><TD > Kokkos-enabled styles</TD><TD > Trott & Edwards (4)</TD><TD > <A HREF = "accelerate_kokkos.html">Section_accelerate</A></TD><TD > kokkos</TD><TD > lib/kokkos</TD></TR>
-<TR ALIGN="center"><TD >KSPACE</TD><TD > long-range Coulombic solvers</TD><TD > -</TD><TD > <A HREF = "kspace_style.html">kspace_style</A></TD><TD > peptide</TD><TD > -</TD></TR>
-<TR ALIGN="center"><TD >MANYBODY</TD><TD > many-body potentials</TD><TD > -</TD><TD > <A HREF = "pair_tersoff.html">pair_style tersoff</A></TD><TD > shear</TD><TD > -</TD></TR>
-<TR ALIGN="center"><TD >MEAM</TD><TD > modified EAM potential</TD><TD > Greg Wagner (Sandia)</TD><TD > <A HREF = "pair_meam.html">pair_style meam</A></TD><TD > meam</TD><TD > lib/meam</TD></TR>
-<TR ALIGN="center"><TD >MC</TD><TD > Monte Carlo options</TD><TD > -</TD><TD > <A HREF = "fix_gcmc.html">fix gcmc</A></TD><TD > -</TD><TD > -</TD></TR>
-<TR ALIGN="center"><TD >MOLECULE</TD><TD > molecular system force fields</TD><TD > -</TD><TD > <A HREF = "Section_howto.html#howto_3">Section_howto 6.3</A></TD><TD > peptide</TD><TD > -</TD></TR>
-<TR ALIGN="center"><TD >OPT</TD><TD > optimized pair styles</TD><TD > Fischer & Richie & Natoli (2)</TD><TD > <A HREF = "accelerate_opt.html">Section accelerate</A></TD><TD > -</TD><TD > -</TD></TR>
-<TR ALIGN="center"><TD >PERI</TD><TD > Peridynamics models</TD><TD > Mike Parks (Sandia)</TD><TD > <A HREF = "pair_peri.html">pair_style peri</A></TD><TD > peri</TD><TD > -</TD></TR>
-<TR ALIGN="center"><TD >POEMS</TD><TD > coupled rigid body motion</TD><TD > Rudra Mukherjee (JPL)</TD><TD > <A HREF = "fix_poems.html">fix poems</A></TD><TD > rigid</TD><TD > lib/poems</TD></TR>
-<TR ALIGN="center"><TD >PYTHON</TD><TD > embed Python code in an input script</TD><TD > -</TD><TD > <A HREF = "python.html">python</A></TD><TD > python</TD><TD > lib/python</TD></TR>
-<TR ALIGN="center"><TD >REAX</TD><TD > ReaxFF potential</TD><TD > Aidan Thompson (Sandia)</TD><TD > <A HREF = "pair_reax.html">pair_style reax</A></TD><TD > reax</TD><TD >  lib/reax</TD></TR>
-<TR ALIGN="center"><TD >REPLICA</TD><TD > multi-replica methods</TD><TD > -</TD><TD > <A HREF = "Section_howto.html#howto_5">Section_howto 6.5</A></TD><TD > tad</TD><TD > -</TD></TR>
-<TR ALIGN="center"><TD >RIGID</TD><TD > rigid bodies</TD><TD > -</TD><TD > <A HREF = "fix_rigid.html">fix rigid</A></TD><TD > rigid</TD><TD > -</TD></TR>
-<TR ALIGN="center"><TD >SHOCK</TD><TD > shock loading methods</TD><TD > -</TD><TD > <A HREF = "fix_msst.html">fix msst</A></TD><TD > -</TD><TD > -</TD></TR>
-<TR ALIGN="center"><TD >SNAP</TD><TD > quantum-fit potential</TD><TD > Aidan Thompson (Sandia)</TD><TD > <A HREF = "pair_snap.html">pair snap</A></TD><TD > snap</TD><TD > -</TD></TR>
-<TR ALIGN="center"><TD >SRD</TD><TD > stochastic rotation dynamics</TD><TD > -</TD><TD > <A HREF = "fix_srd.html">fix srd</A></TD><TD > srd</TD><TD > -</TD></TR>
-<TR ALIGN="center"><TD >VORONOI</TD><TD > Voronoi tesselations</TD><TD > Daniel Schwen (LANL)</TD><TD > <A HREF = "compute_voronoi_atom.html">compute voronoi/atom</A></TD><TD > -</TD><TD > Voro++</TD></TR>
-<TR ALIGN="center"><TD >XTC</TD><TD > dumps in XTC format</TD><TD > -</TD><TD > <A HREF = "dump.html">dump</A></TD><TD > -</TD><TD > -</TD></TR>
-<TR ALIGN="center"><TD >
-</TD></TR></TABLE></DIV>
-
-<P>The "Authors" column lists a name(s) if a specific person is
-responible for creating and maintaining the package.
-</P>
-<P>(1) The FLD package was created by Amit Kumar and Michael Bybee from
-Jonathan Higdon's group at UIUC.
-</P>
-<P>(2) The OPT package was created by James Fischer (High Performance
-Technologies), David Richie, and Vincent Natoli (Stone Ridge
-Technolgy).
-</P>
-<P>(3) The KIM package was created by Valeriu Smirichinski, Ryan Elliott,
-and Ellad Tadmor (U Minn).
-</P>
-<P>(4) The KOKKOS package was created primarily by Christian Trott
-(Sandia).  It uses the Kokkos library which was developed by Carter
-Edwards, Christian, and collaborators at Sandia.
-</P>
-<P>The "Doc page" column links to either a portion of the
-<A HREF = "Section_howto.html">Section_howto</A> of the manual, or an input script
-command implemented as part of the package.
-</P>
-<P>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.
-</P>
-<P>The "Library" column lists an external library which must be built
-first and which LAMMPS links to when it is built.  If it is listed as
-lib/package, then the code for the library is under the lib directory
-of the LAMMPS distribution.  See the lib/package/README file for info
-on how to build the library.  If it is not listed as lib/package, then
-it is a third-party library not included in the LAMMPS distribution.
-See the src/package/README or src/package/Makefile.lammps file for
-info on where to download the library.  <A HREF = "Section_start.html#start_3_3">Section
-start</A> of the manual also gives details
-on how to build LAMMPS with both kinds of auxiliary libraries.
-</P>
-<HR>
-
-<HR>
-
-<H4><A NAME = "pkg_2"></A>4.2 User packages 
-</H4>
-<P>The current list of user-contributed packages is as follows:
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR ALIGN="center"><TD >Package</TD><TD > Description</TD><TD > Author(s)</TD><TD > Doc page</TD><TD > Example</TD><TD > Pic/movie</TD><TD > Library</TD></TR>
-<TR ALIGN="center"><TD >USER-ATC</TD><TD > atom-to-continuum coupling</TD><TD > Jones & Templeton & Zimmerman (2)</TD><TD > <A HREF = "fix_atc.html">fix atc</A></TD><TD > USER/atc</TD><TD > <A HREF = "http://lammps.sandia.gov/pictures.html#atc">atc</A></TD><TD > lib/atc</TD></TR>
-<TR ALIGN="center"><TD >USER-AWPMD</TD><TD > wave-packet MD</TD><TD > Ilya Valuev (JIHT)</TD><TD > <A HREF = "pair_awpmd.html">pair_style awpmd/cut</A></TD><TD > USER/awpmd</TD><TD > -</TD><TD > lib/awpmd</TD></TR>
-<TR ALIGN="center"><TD >USER-CG-CMM</TD><TD > coarse-graining model</TD><TD > Axel Kohlmeyer (Temple U)</TD><TD > <A HREF = "pair_sdk.html">pair_style lj/sdk</A></TD><TD > USER/cg-cmm</TD><TD > <A HREF = "http://lammps.sandia.gov/pictures.html#cg">cg</A></TD><TD > -</TD></TR>
-<TR ALIGN="center"><TD >USER-COLVARS</TD><TD > collective variables</TD><TD > Fiorin & Henin & Kohlmeyer (3)</TD><TD > <A HREF = "fix_colvars.html">fix colvars</A></TD><TD > USER/colvars</TD><TD > <A HREF = "colvars">colvars</A></TD><TD > lib/colvars</TD></TR>
-<TR ALIGN="center"><TD >USER-CUDA</TD><TD > NVIDIA GPU styles</TD><TD > Christian Trott (U Tech Ilmenau)</TD><TD > <A HREF = "accelerate_cuda.html">Section accelerate</A></TD><TD > USER/cuda</TD><TD > -</TD><TD > lib/cuda</TD></TR>
-<TR ALIGN="center"><TD >USER-EFF</TD><TD > electron force field</TD><TD > Andres Jaramillo-Botero (Caltech)</TD><TD > <A HREF = "pair_eff.html">pair_style eff/cut</A></TD><TD > USER/eff</TD><TD > <A HREF = "http://lammps.sandia.gov/movies.html#eff">eff</A></TD><TD > -</TD></TR>
-<TR ALIGN="center"><TD >USER-FEP</TD><TD > free energy perturbation</TD><TD > Agilio Padua (U Blaise Pascal Clermont-Ferrand)</TD><TD > <A HREF = "compute_fep.html">compute fep</A></TD><TD > USER/fep</TD><TD > -</TD><TD > -</TD></TR>
-<TR ALIGN="center"><TD >USER-INTEL</TD><TD > Vectorized CPU and Intel(R) coprocessor styles</TD><TD > W. Michael Brown (Intel)</TD><TD > <A HREF = "accelerate_intel.html">Section accelerate</A></TD><TD > examples/intel</TD><TD > -</TD><TD > -</TD></TR>
-<TR ALIGN="center"><TD >USER-LB</TD><TD > Lattice Boltzmann fluid</TD><TD > Colin Denniston (U Western Ontario)</TD><TD > <A HREF = "fix_lb_fluid.html">fix lb/fluid</A></TD><TD > USER/lb</TD><TD > -</TD><TD > -</TD></TR>
-<TR ALIGN="center"><TD >USER-MISC</TD><TD > single-file contributions</TD><TD > USER-MISC/README</TD><TD > USER-MISC/README</TD><TD > -</TD><TD > -</TD><TD > -</TD></TR>
-<TR ALIGN="center"><TD >USER-MOLFILE</TD><TD > <A HREF = "http://www.ks.uiuc.edu/Research/vmd">VMD</A> molfile plug-ins</TD><TD > Axel Kohlmeyer (Temple U)</TD><TD > <A HREF = "dump_molfile.html">dump molfile</A></TD><TD > -</TD><TD > -</TD><TD > VMD-MOLFILE</TD></TR>
-<TR ALIGN="center"><TD >USER-OMP</TD><TD > OpenMP threaded styles</TD><TD > Axel Kohlmeyer (Temple U)</TD><TD > <A HREF = "accelerate_omp.html">Section accelerate</A></TD><TD > -</TD><TD > -</TD><TD > -</TD></TR>
-<TR ALIGN="center"><TD >USER-PHONON</TD><TD > phonon dynamical matrix</TD><TD > Ling-Ti Kong (Shanghai Jiao Tong U)</TD><TD > <A HREF = "fix_phonon.html">fix phonon</A></TD><TD > USER/phonon</TD><TD > -</TD><TD > -</TD></TR>
-<TR ALIGN="center"><TD >USER-QMMM</TD><TD > QM/MM coupling</TD><TD > Axel Kohlmeyer (Temple U)</TD><TD > <A HREF = "fix_qmmm.html">fix qmmm</A></TD><TD > USER/qmmm</TD><TD > -</TD><TD > lib/qmmm</TD></TR>
-<TR ALIGN="center"><TD >USER-QUIP</TD><TD > QM/MM coupling</TD><TD > Albert Bartok-Partay (U Cambridge)</TD><TD > <A HREF = "fix_quip.html">fix quip</A></TD><TD > USER/quip</TD><TD > -</TD><TD > lib/quip</TD></TR>
-<TR ALIGN="center"><TD >USER-REAXC</TD><TD > C version of ReaxFF</TD><TD > Metin Aktulga (LBNL)</TD><TD > <A HREF = "pair_reax_c.html">pair_style reaxc</A></TD><TD > reax</TD><TD > -</TD><TD > -</TD></TR>
-<TR ALIGN="center"><TD >USER-SPH</TD><TD > smoothed particle hydrodynamics</TD><TD > Georg Ganzenmuller (EMI)</TD><TD > <A HREF = "USER/sph/SPH_LAMMPS_userguide.pdf">userguide.pdf</A></TD><TD > USER/sph</TD><TD > <A HREF = "http://lammps.sandia.gov/movies.html#sph">sph</A></TD><TD > -</TD></TR>
-<TR ALIGN="center"><TD >
-</TD></TR></TABLE></DIV>
-
-
-
-
-
-
-
-
-
-
-
-<P>The "Authors" column lists a name(s) if a specific person is
-responible for creating and maintaining the package.
-</P>
-<P>If the Library is not listed as lib/package, then it is a third-party
-library not included in the LAMMPS distribution.  See the
-src/package/Makefile.lammps file for info on where to download the
-library from.
-</P>
-<P>(2) The ATC package was created by Reese Jones, Jeremy Templeton, and
-Jon Zimmerman (Sandia).
-</P>
-<P>(3) The COLVARS package was created by Axel Kohlmeyer (Temple U) using
-the colvars module library written by Giacomo Fiorin (Temple U) and
-Jerome Henin (LISM, Marseille, France).
-</P>
-<P>The "Doc page" column links to either a portion of the
-<A HREF = "Section_howto.html">Section_howto</A> of the manual, or an input script
-command implemented as part of the package, or to additional
-documentation provided witht he package.
-</P>
-<P>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.
-</P>
-<P>The "Library" column lists an external library which must be built
-first and which LAMMPS links to when it is built.  If it is listed as
-lib/package, then the code for the library is under the lib directory
-of the LAMMPS distribution.  See the lib/package/README file for info
-on how to build the library.  If it is not listed as lib/package, then
-it is a third-party library not included in the LAMMPS distribution.
-See the src/package/Makefile.lammps file for info on where to download
-the library.  <A HREF = "Section_start.html#start_3_3">Section start</A> of the
-manual also gives details on how to build LAMMPS with both kinds of
-auxiliary libraries.
-</P>
-<P>More details on each package, from the USER-*/README file is given
-below.
-</P>
-<HR>
-
-<H4>USER-ATC package 
-</H4>
-<P>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.
-</P>
-<P>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.
-</P>
-<P>There are example scripts for using this package in examples/USER/atc.
-</P>
-<P>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.
-</P>
-<P>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.
-</P>
-<HR>
-
-<H4>USER-AWPMD package 
-</H4>
-<P>This package contains a LAMMPS implementation of the Antisymmetrized
-Wave Packet Molecular Dynamics (AWPMD) method.
-</P>
-<P>See the doc page for the pair_style awpmd/cut command to get started.
-</P>
-<P>There are example scripts for using this package in examples/USER/awpmd.
-</P>
-<P>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.
-</P>
-<P>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.
-</P>
-<HR>
-
-<H4>USER-CG-CMM package 
-</H4>
-<P>This package implements 3 commands which can be used in a LAMMPS input
-script:
-</P>
-<UL><LI>pair_style lj/sdk
-<LI>pair_style lj/sdk/coul/long
-<LI>angle_style sdk 
-</UL>
-<P>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.
-</P>
-<P>See the doc pages for these commands for details.
-</P>
-<P>There are example scripts for using this package in
-examples/USER/cg-cmm.
-</P>
-<P>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.
-</P>
-<P>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.
-</P>
-<P>The person who created this package is Axel Kohlmeyer at Temple U
-(akohlmey at gmail.com).  Contact him directly if you have questions.
-</P>
-<HR>
-
-<H4>USER-COLVARS package 
-</H4>
-<P>This package implements the "fix colvars" command which can be
-used in a LAMMPS input script.
-</P>
-<P>This fix allows to use "collective variables" to implement
-Adaptive Biasing Force, Metadynamics, Steered MD, Umbrella
-Sampling and Restraints. This code consists of two parts:
-</P>
-<UL><LI>A portable collective variable module library written and maintained
-<LI>by Giacomo Fiorin (ICMS, Temple University, Philadelphia, PA, USA) and
-<LI>Jerome Henin (LISM, CNRS, Marseille, France). This code is located in
-<LI>the directory lib/colvars and needs to be compiled first.  The colvars
-<LI>fix and an interface layer, exchanges information between LAMMPS and
-<LI>the collective variable module. 
-</UL>
-<P>See the doc page of <A HREF = "fix_colvars.html">fix colvars</A> for more details.
-</P>
-<P>There are example scripts for using this package in
-examples/USER/colvars
-</P>
-<P>This is a very new interface that does not yet support all
-features in the module and will see future optimizations
-and improvements. The colvars module library is also available
-in NAMD has been thoroughly used and tested there. Bugs and
-problems are likely due to the interface layers code.
-Thus the current version of this package should be considered
-beta quality.
-</P>
-<P>The person who created this package is Axel Kohlmeyer at Temple U
-(akohlmey at gmail.com).  Contact him directly if you have questions.
-</P>
-<HR>
-
-<H4>USER-CUDA package 
-</H4>
-<P>This package provides acceleration of various LAMMPS pair styles, fix
-styles, compute styles, and long-range Coulombics via PPPM for NVIDIA
-GPUs.
-</P>
-<P>See this section of the manual to get started:
-</P>
-<P><A HREF = "Section_accelerate.html#acc_7">Section_accelerate</A>
-</P>
-<P>There are example scripts for using this package in
-examples/USER/cuda.
-</P>
-<P>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.
-</P>
-<P>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.
-</P>
-<HR>
-
-<H4>USER-EFF package 
-</H4>
-<P>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.
-</P>
-<P>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.
-</P>
-<P>The necessary customizations to the LAMMPS core are in place to
-enable the correct handling of explicit electron properties during
-minimization and dynamics.
-</P>
-<P>See the doc page for the pair_style eff/cut command to get started.
-</P>
-<P>There are example scripts for using this package in
-examples/USER/eff.
-</P>
-<P>There are auxiliary tools for using this package in tools/eff.
-</P>
-<P>The person who created this package is Andres Jaramillo-Botero at
-CalTech (ajaramil at wag.caltech.edu).  Contact him directly if you
-have questions.
-</P>
-<HR>
-
-<H4>USER-FEP package 
-</H4>
-<P>This package provides methods for performing free energy perturbation
-simulations with soft-core pair potentials in LAMMPS.
-</P>
-<P>See these doc pages and their related commands to get started:
-</P>
-<UL><LI><A HREF = "fix_adapt_fep.html">fix adapt/fep</A>
-<LI><A HREF = "compute_fep.html">compute fep</A>
-<LI><A HREF = "pair_lj_soft.html">soft pair styles</A> 
-</UL>
-<P>The person who created this package is Agilio Padua at Universite
-Blaise Pascal Clermont-Ferrand (agilio.padua at univ-bpclermont.fr)
-Contact him directly if you have questions.
-</P>
-<HR>
-
-<H4>USER-INTEL package 
-</H4>
-<P>This package provides options for performing neighbor list and
-non-bonded force calculations in single, mixed, or double precision
-and also a capability for accelerating calculations with an
-Intel(R) Xeon Phi(TM) coprocessor.
-</P>
-<P>See this section of the manual to get started:
-</P>
-<P><A HREF = "Section_accelerate.html#acc_9">Section_accelerate</A>
-</P>
-<P>The person who created this package is W. Michael Brown at Intel
-(michael.w.brown at intel.com).  Contact him directly if you have questions.
-</P>
-<HR>
-
-<H4>USER-LB package 
-</H4>
-<P>This package contains a LAMMPS implementation of a background
-Lattice-Boltzmann fluid, which can be used to model MD particles
-influenced by hydrodynamic forces.
-</P>
-<P>See this doc page and its related commands to get started:
-</P>
-<P><A HREF = "fix_lb_fluid.html">fix lb/fluid</A>
-</P>
-<P>The people who created this package are Frances Mackay (fmackay at
-uwo.ca) and Colin (cdennist at uwo.ca) Denniston, University of
-Western Ontario.  Contact them directly if you have questions.
-</P>
-<HR>
-
-<H4>USER-MISC package 
-</H4>
-<P>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).
-</P>
-<P>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:
-</P>
-<P><A HREF = "Section_commands.html#cmd_5">Section_commands</A>
-</P>
-<P>User-contributed features are listed at the bottom of the fix,
-compute, pair, etc sections.
-</P>
-<P>The list of features and author of each is given in the
-src/USER-MISC/README file.
-</P>
-<P>You should contact the author directly if you have specific questions
-about the feature or its coding.
-</P>
-<HR>
-
-<H4>USER-MOLFILE package 
-</H4>
-<P>This package contains a dump molfile command which uses molfile
-plugins that are bundled with the
-<A HREF = "http://www.ks.uiuc.edu/Research/vmd">VMD</A> molecular visualization and
-analysis program, to enable LAMMPS to dump its information in formats
-compatible with various molecular simulation tools.
-</P>
-<P>The package only provides the interface code, not the plugins.  These
-can be obtained from a VMD installation which has to match the
-platform that you are using to compile LAMMPS for. By adding plugins
-to VMD, support for new file formats can be added to LAMMPS (or VMD or
-other programs that use them) without having to recompile the
-application itself.
-</P>
-<P>See this doc page to get started:
-</P>
-<P><A HREF = "dump_molfile.html#acc_5">dump molfile</A>
-</P>
-<P>The person who created this package is Axel Kohlmeyer at Temple U
-(akohlmey at gmail.com).  Contact him directly if you have questions.
-</P>
-<HR>
-
-<H4>USER-OMP package 
-</H4>
-<P>This package provides OpenMP multi-threading support and
-other optimizations of various LAMMPS pair styles, dihedral
-styles, and fix styles.
-</P>
-<P>See this section of the manual to get started:
-</P>
-<P><A HREF = "Section_accelerate.html#acc_5">Section_accelerate</A>
-</P>
-<P>The person who created this package is Axel Kohlmeyer at Temple U
-(akohlmey at gmail.com).  Contact him directly if you have questions.
-</P>
-<HR>
-
-<H4>USER-PHONON package 
-</H4>
-<P>This package contains a fix phonon command that calculates dynamical
-matrices, which can then be used to compute phonon dispersion
-relations, directly from molecular dynamics simulations.
-</P>
-<P>See this doc page to get started:
-</P>
-<P><A HREF = "fix_phonon.html">fix phonon</A>
-</P>
-<P>The person who created this package is Ling-Ti Kong (konglt at
-sjtu.edu.cn) at Shanghai Jiao Tong University.  Contact him directly
-if you have questions.
-</P>
-<HR>
-
-<H4>USER-QMMM package 
-</H4>
-<P>This package provides a fix qmmm command which allows LAMMPS to be
-used in a QM/MM simulation, currently only in combination with pw.x
-code from the <A HREF = "http://www.quantum-espresso.org">Quantum ESPRESSO</A> package.
-</P>
-
-
-<P>The current implementation only supports an ONIOM style mechanical
-coupling to the Quantum ESPRESSO plane wave DFT package.
-Electrostatic coupling is in preparation and the interface has been
-written in a manner that coupling to other QM codes should be possible
-without changes to LAMMPS itself.
-</P>
-<P>See this doc page to get started:
-</P>
-<P><A HREF = "fix_qmmm.html">fix qmmm</A>
-</P>
-<P>as well as the lib/qmmm/README file.
-</P>
-<P>The person who created this package is Axel Kohlmeyer at Temple U
-(akohlmey at gmail.com).  Contact him directly if you have questions.
-</P>
-<HR>
-
-<H4>USER-REAXC package 
-</H4>
-<P>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.
-</P>
-<P>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.
-</P>
-<P>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.
-</P>
-<P>For technical details about this implemention of ReaxFF, see
-this paper:
-</P>
-<P>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).
-</P>
-<P>See the doc page for the pair_style reax/c command for details
-of how to use it in LAMMPS.
-</P>
-<P>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.
-</P>
-<HR>
-
-<H4>USER-SPH package 
-</H4>
-<P>This package implements smoothed particle hydrodynamics (SPH) in
-LAMMPS.  Currently, the package has the following features:
-</P>
-<P>* 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
-</P>
-<P>See the file doc/USER/sph/SPH_LAMMPS_userguide.pdf to get started.
-</P>
-<P>There are example scripts for using this package in examples/USER/sph.
-</P>
-<P>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.
-</P>
-</HTML>
--- a/doc/Section_packages.txt
+++ b/doc/Section_packages.txt
@ -1,575 +0,0 @@
-"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 "Section_start 3"_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, -, "Section_howto 6.14"_Section_howto.html#howto_14, ellipse, -
-BODY, body-style particles, -, "body"_body.html, body, -
-CLASS2, class 2 force fields, -, "pair_style lj/class2"_pair_class2.html, -, -
-COLLOID, colloidal particles, -, "atom_style colloid"_atom_style.html, colloid, -
-CORESHELL, adiabatic core/shell model, Hendrik Heenen (Technical U of Munich), "Section_howto 6.25"_Section_howto.html#howto_25, coreshell, -
-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 styles, Mike Brown (ORNL), "Section accelerate"_accelerate_gpu.html, gpu, lib/gpu
-GRANULAR, granular systems, -, "Section_howto 6.6"_Section_howto.html#howto_6, pour, -
-KIM, openKIM potentials, Smirichinski & Elliot & Tadmor (3), "pair_style kim"_pair_kim.html, kim, KIM
-KOKKOS, Kokkos-enabled styles, Trott & Edwards (4), "Section_accelerate"_accelerate_kokkos.html, kokkos, lib/kokkos
-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, -, "Section_howto 6.3"_Section_howto.html#howto_3, peptide, -
-OPT, optimized pair styles, Fischer & Richie & Natoli (2), "Section accelerate"_accelerate_opt.html, -, -
-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
-PYTHON, embed Python code in an input script, -, "python"_python.html, python, lib/python
-REAX, ReaxFF potential, Aidan Thompson (Sandia), "pair_style reax"_pair_reax.html, reax,  lib/reax
-REPLICA, multi-replica methods, -, "Section_howto 6.5"_Section_howto.html#howto_5, tad, -
-RIGID, rigid bodies, -, "fix rigid"_fix_rigid.html, rigid, -
-SHOCK, shock loading methods, -, "fix msst"_fix_msst.html, -, -
-SNAP, quantum-fit potential, Aidan Thompson (Sandia), "pair snap"_pair_snap.html, snap, -
-SRD, stochastic rotation dynamics, -, "fix srd"_fix_srd.html, srd, -
-VORONOI, Voronoi tesselations, Daniel Schwen (LANL), "compute voronoi/atom"_compute_voronoi_atom.html, -, Voro++
-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).
-
-(3) The KIM package was created by Valeriu Smirichinski, Ryan Elliott,
-and Ellad Tadmor (U Minn).
-
-(4) The KOKKOS package was created primarily by Christian Trott
-(Sandia).  It uses the Kokkos library which was developed by Carter
-Edwards, Christian, and collaborators at 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.
-
-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.  If it is listed as
-lib/package, then the code for the library is under the lib directory
-of the LAMMPS distribution.  See the lib/package/README file for info
-on how to build the library.  If it is not listed as lib/package, then
-it is a third-party library not included in the LAMMPS distribution.
-See the src/package/README or src/package/Makefile.lammps file for
-info on where to download the library.  "Section
-start"_Section_start.html#start_3_3 of the manual also gives details
-on how to build LAMMPS with both kinds of auxiliary 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-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-COLVARS, collective variables, Fiorin & Henin & Kohlmeyer (3), "fix colvars"_fix_colvars.html, USER/colvars, "colvars"_colvars, lib/colvars
-USER-CUDA, NVIDIA GPU styles, Christian Trott (U Tech Ilmenau), "Section accelerate"_accelerate_cuda.html, 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-FEP, free energy perturbation, Agilio Padua (U Blaise Pascal Clermont-Ferrand), "compute fep"_compute_fep.html, USER/fep, -, -
-USER-INTEL, Vectorized CPU and Intel(R) coprocessor styles, W. Michael Brown (Intel), "Section accelerate"_accelerate_intel.html, examples/intel, -, -
-USER-LB, Lattice Boltzmann fluid, Colin Denniston (U Western Ontario), "fix lb/fluid"_fix_lb_fluid.html, USER/lb, -, -
-USER-MISC, single-file contributions, USER-MISC/README, USER-MISC/README, -, -, -
-USER-MOLFILE, "VMD"_VMD molfile plug-ins, Axel Kohlmeyer (Temple U), "dump molfile"_dump_molfile.html, -, -, VMD-MOLFILE
-USER-OMP, OpenMP threaded styles, Axel Kohlmeyer (Temple U), "Section accelerate"_accelerate_omp.html, -, -, -
-USER-PHONON, phonon dynamical matrix, Ling-Ti Kong (Shanghai Jiao Tong U), "fix phonon"_fix_phonon.html, USER/phonon, -, -
-USER-QMMM, QM/MM coupling, Axel Kohlmeyer (Temple U), "fix qmmm"_fix_qmmm.html, USER/qmmm, -, lib/qmmm
-USER-QUIP, QM/MM coupling, Albert Bartok-Partay (U Cambridge), "fix quip"_fix_quip.html, USER/quip, -, lib/quip
-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), "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)
-:link(VMD,http://www.ks.uiuc.edu/Research/vmd)
-
-The "Authors" column lists a name(s) if a specific person is
-responible for creating and maintaining the package.
-
-If the Library is not listed as lib/package, then it is a third-party
-library not included in the LAMMPS distribution.  See the
-src/package/Makefile.lammps file for info on where to download the
-library from.
-
-(2) The ATC package was created by Reese Jones, Jeremy Templeton, and
-Jon Zimmerman (Sandia).
-
-(3) The COLVARS package was created by Axel Kohlmeyer (Temple U) using
-the colvars module library written by Giacomo Fiorin (Temple U) and
-Jerome Henin (LISM, Marseille, France).
-
-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.  If it is listed as
-lib/package, then the code for the library is under the lib directory
-of the LAMMPS distribution.  See the lib/package/README file for info
-on how to build the library.  If it is not listed as lib/package, then
-it is a third-party library not included in the LAMMPS distribution.
-See the src/package/Makefile.lammps file for info on where to download
-the library.  "Section start"_Section_start.html#start_3_3 of the
-manual also gives details on how to build LAMMPS with both kinds of
-auxiliary libraries.
-
-More details on each package, from the USER-*/README file is given
-below.
-
-: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-COLVARS package :h4
-
-This package implements the "fix colvars" command which can be
-used in a LAMMPS input script.
-
-This fix allows to use "collective variables" to implement
-Adaptive Biasing Force, Metadynamics, Steered MD, Umbrella
-Sampling and Restraints. This code consists of two parts:
-
-A portable collective variable module library written and maintained
-by Giacomo Fiorin (ICMS, Temple University, Philadelphia, PA, USA) and
-Jerome Henin (LISM, CNRS, Marseille, France). This code is located in
-the directory lib/colvars and needs to be compiled first.  The colvars
-fix and an interface layer, exchanges information between LAMMPS and
-the collective variable module. :ul
-
-See the doc page of "fix colvars"_fix_colvars.html for more details.
-
-There are example scripts for using this package in
-examples/USER/colvars
-
-This is a very new interface that does not yet support all
-features in the module and will see future optimizations
-and improvements. The colvars module library is also available
-in NAMD has been thoroughly used and tested there. Bugs and
-problems are likely due to the interface layers code.
-Thus the current version of this package should be considered
-beta quality.
-
-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_7
-
-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-FEP package :h4
-
-This package provides methods for performing free energy perturbation
-simulations with soft-core pair potentials in LAMMPS.
-
-See these doc pages and their related commands to get started:
-
-"fix adapt/fep"_fix_adapt_fep.html
-"compute fep"_compute_fep.html
-"soft pair styles"_pair_lj_soft.html :ul
-
-The person who created this package is Agilio Padua at Universite
-Blaise Pascal Clermont-Ferrand (agilio.padua at univ-bpclermont.fr)
-Contact him directly if you have questions.
-
-:line
-
-USER-INTEL package :h4
-
-This package provides options for performing neighbor list and
-non-bonded force calculations in single, mixed, or double precision
-and also a capability for accelerating calculations with an
-Intel(R) Xeon Phi(TM) coprocessor.
- 
-See this section of the manual to get started:
-
-"Section_accelerate"_Section_accelerate.html#acc_9
-
-The person who created this package is W. Michael Brown at Intel
-(michael.w.brown at intel.com).  Contact him directly if you have questions.
-
-:line
-
-USER-LB package :h4
-
-This package contains a LAMMPS implementation of a background
-Lattice-Boltzmann fluid, which can be used to model MD particles
-influenced by hydrodynamic forces.
-
-See this doc page and its related commands to get started:
-
-"fix lb/fluid"_fix_lb_fluid.html
-
-The people who created this package are Frances Mackay (fmackay at
-uwo.ca) and Colin (cdennist at uwo.ca) Denniston, University of
-Western Ontario.  Contact them directly if you have questions.
-
-: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-MOLFILE package :h4
-
-This package contains a dump molfile command which uses molfile
-plugins that are bundled with the
-"VMD"_http://www.ks.uiuc.edu/Research/vmd molecular visualization and
-analysis program, to enable LAMMPS to dump its information in formats
-compatible with various molecular simulation tools.
-
-The package only provides the interface code, not the plugins.  These
-can be obtained from a VMD installation which has to match the
-platform that you are using to compile LAMMPS for. By adding plugins
-to VMD, support for new file formats can be added to LAMMPS (or VMD or
-other programs that use them) without having to recompile the
-application itself.
-
-See this doc page to get started:
-
-"dump molfile"_dump_molfile.html#acc_5
-
-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-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_5
-
-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-PHONON package :h4
-
-This package contains a fix phonon command that calculates dynamical
-matrices, which can then be used to compute phonon dispersion
-relations, directly from molecular dynamics simulations.
-
-See this doc page to get started:
-
-"fix phonon"_fix_phonon.html
-
-The person who created this package is Ling-Ti Kong (konglt at
-sjtu.edu.cn) at Shanghai Jiao Tong University.  Contact him directly
-if you have questions.
-
-:line
-
-USER-QMMM package :h4
-
-This package provides a fix qmmm command which allows LAMMPS to be
-used in a QM/MM simulation, currently only in combination with pw.x
-code from the "Quantum ESPRESSO"_espresso package.
-
-:link(espresso,http://www.quantum-espresso.org)
-
-The current implementation only supports an ONIOM style mechanical
-coupling to the Quantum ESPRESSO plane wave DFT package.
-Electrostatic coupling is in preparation and the interface has been
-written in a manner that coupling to other QM codes should be possible
-without changes to LAMMPS itself.
-
-See this doc page to get started:
-
-"fix qmmm"_fix_qmmm.html
-
-as well as the lib/qmmm/README file.
-
-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.
--- a/doc/Section_perf.html
+++ b/doc/Section_perf.html
@ -1,84 +0,0 @@
-<HTML>
-<CENTER><A HREF = "Section_example.html">Previous Section</A> - <A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> - <A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A> - <A HREF = "Section_tools.html">Next Section</A> 
-</CENTER>
-
-
-
-
-
-
-<HR>
-
-<H3>8. Performance & scalability 
-</H3>
-<P>LAMMPS performance on several prototypical benchmarks and machines is
-discussed on the Benchmarks page of the <A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> where
-CPU timings and parallel efficiencies are listed.  Here, the
-benchmarks are described briefly and some useful rules of thumb about
-their performance are highlighted.
-</P>
-<P>These are the 5 benchmark problems:
-</P>
-<OL><LI>LJ = atomic fluid, Lennard-Jones potential with 2.5 sigma cutoff (55
-neighbors per atom), NVE integration 
-
-<LI>Chain = bead-spring polymer melt of 100-mer chains, FENE bonds and LJ
-pairwise interactions with a 2^(1/6) sigma cutoff (5 neighbors per
-atom), NVE integration 
-
-<LI>EAM = metallic solid, Cu EAM potential with 4.95 Angstrom cutoff (45
-neighbors per atom), NVE integration 
-
-<LI>Chute = granular chute flow, frictional history potential with 1.1
-sigma cutoff (7 neighbors per atom), NVE integration 
-
-<LI>Rhodo = rhodopsin protein in solvated lipid bilayer, CHARMM force
-field with a 10 Angstrom LJ cutoff (440 neighbors per atom),
-particle-particle particle-mesh (PPPM) for long-range Coulombics, NPT
-integration 
-</OL>
-<P>The input files for running the benchmarks are included in the LAMMPS
-distribution, as are sample output files.  Each of the 5 problems has
-32,000 atoms and runs for 100 timesteps.  Each can be run as a serial
-benchmarks (on one processor) or in parallel.  In parallel, each
-benchmark can be run as a fixed-size or scaled-size problem.  For
-fixed-size benchmarking, the same 32K atom problem is run on various
-numbers of processors.  For scaled-size benchmarking, the model size
-is increased with the number of processors.  E.g. on 8 processors, a
-256K-atom problem is run; on 1024 processors, a 32-million atom
-problem is run, etc.
-</P>
-<P>A useful metric from the benchmarks is the CPU cost per atom per
-timestep.  Since LAMMPS performance scales roughly linearly with
-problem size and timesteps, the run time of any problem using the same
-model (atom style, force field, cutoff, etc) can then be estimated.
-For example, on a 1.7 GHz Pentium desktop machine (Intel icc compiler
-under Red Hat Linux), the CPU run-time in seconds/atom/timestep for
-the 5 problems is
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR ALIGN="center"><TD  ALIGN ="right">Problem:</TD><TD > LJ</TD><TD > Chain</TD><TD > EAM</TD><TD > Chute</TD><TD > Rhodopsin</TD></TR>
-<TR ALIGN="center"><TD  ALIGN ="right">CPU/atom/step:</TD><TD > 4.55E-6</TD><TD > 2.18E-6</TD><TD > 9.38E-6</TD><TD > 2.18E-6</TD><TD > 1.11E-4</TD></TR>
-<TR ALIGN="center"><TD  ALIGN ="right">Ratio to LJ:</TD><TD > 1.0</TD><TD > 0.48</TD><TD > 2.06</TD><TD > 0.48</TD><TD > 24.5 
-</TD></TR></TABLE></DIV>
-
-<P>The ratios mean that if the atomic LJ system has a normalized cost of
-1.0, the bead-spring chains and granular systems run 2x faster, while
-the EAM metal and solvated protein models run 2x and 25x slower
-respectively.  The bulk of these cost differences is due to the
-expense of computing a particular pairwise force field for a given
-number of neighbors per atom.
-</P>
-<P>Performance on a parallel machine can also be predicted from the
-one-processor timings if the parallel efficiency can be estimated.
-The communication bandwidth and latency of a particular parallel
-machine affects the efficiency.  On most machines LAMMPS will give
-fixed-size parallel efficiencies on these benchmarks above 50% so long
-as the atoms/processor count is a few 100 or greater - i.e. on 64 to
-128 processors.  Likewise, scaled-size parallel efficiencies will
-typically be 80% or greater up to very large processor counts.  The
-benchmark data on the <A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> gives specific examples on
-some different machines, including a run of 3/4 of a billion LJ atoms
-on 1500 processors that ran at 85% parallel efficiency.
-</P>
-</HTML>
--- a/doc/Section_perf.txt
+++ b/doc/Section_perf.txt
@ -1,77 +0,0 @@
-"Previous Section"_Section_example.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_tools.html :c
-
-:link(lws,http://lammps.sandia.gov)
-:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
-
-:line
-
-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
-CPU timings and parallel efficiencies are listed.  Here, the
-benchmarks are described briefly and some useful rules of thumb about
-their performance are highlighted.
-
-These are the 5 benchmark problems:
-
-LJ = atomic fluid, Lennard-Jones potential with 2.5 sigma cutoff (55
-neighbors per atom), NVE integration :olb,l
-
-Chain = bead-spring polymer melt of 100-mer chains, FENE bonds and LJ
-pairwise interactions with a 2^(1/6) sigma cutoff (5 neighbors per
-atom), NVE integration :l
-
-EAM = metallic solid, Cu EAM potential with 4.95 Angstrom cutoff (45
-neighbors per atom), NVE integration :l
-
-Chute = granular chute flow, frictional history potential with 1.1
-sigma cutoff (7 neighbors per atom), NVE integration :l
-
-Rhodo = rhodopsin protein in solvated lipid bilayer, CHARMM force
-field with a 10 Angstrom LJ cutoff (440 neighbors per atom),
-particle-particle particle-mesh (PPPM) for long-range Coulombics, NPT
-integration :ole,l
-
-The input files for running the benchmarks are included in the LAMMPS
-distribution, as are sample output files.  Each of the 5 problems has
-32,000 atoms and runs for 100 timesteps.  Each can be run as a serial
-benchmarks (on one processor) or in parallel.  In parallel, each
-benchmark can be run as a fixed-size or scaled-size problem.  For
-fixed-size benchmarking, the same 32K atom problem is run on various
-numbers of processors.  For scaled-size benchmarking, the model size
-is increased with the number of processors.  E.g. on 8 processors, a
-256K-atom problem is run; on 1024 processors, a 32-million atom
-problem is run, etc.
-
-A useful metric from the benchmarks is the CPU cost per atom per
-timestep.  Since LAMMPS performance scales roughly linearly with
-problem size and timesteps, the run time of any problem using the same
-model (atom style, force field, cutoff, etc) can then be estimated.
-For example, on a 1.7 GHz Pentium desktop machine (Intel icc compiler
-under Red Hat Linux), the CPU run-time in seconds/atom/timestep for
-the 5 problems is
-
-Problem:, LJ, Chain, EAM, Chute, Rhodopsin
-CPU/atom/step:, 4.55E-6, 2.18E-6, 9.38E-6, 2.18E-6, 1.11E-4
-Ratio to LJ:, 1.0, 0.48, 2.06, 0.48, 24.5 :tb(ea=c,ca1=r)
-
-The ratios mean that if the atomic LJ system has a normalized cost of
-1.0, the bead-spring chains and granular systems run 2x faster, while
-the EAM metal and solvated protein models run 2x and 25x slower
-respectively.  The bulk of these cost differences is due to the
-expense of computing a particular pairwise force field for a given
-number of neighbors per atom.
-
-Performance on a parallel machine can also be predicted from the
-one-processor timings if the parallel efficiency can be estimated.
-The communication bandwidth and latency of a particular parallel
-machine affects the efficiency.  On most machines LAMMPS will give
-fixed-size parallel efficiencies on these benchmarks above 50% so long
-as the atoms/processor count is a few 100 or greater - i.e. on 64 to
-128 processors.  Likewise, scaled-size parallel efficiencies will
-typically be 80% or greater up to very large processor counts.  The
-benchmark data on the "LAMMPS WWW Site"_lws gives specific examples on
-some different machines, including a run of 3/4 of a billion LJ atoms
-on 1500 processors that ran at 85% parallel efficiency.
--- a/doc/Section_python.html
+++ b/doc/Section_python.html
@ -1,792 +0,0 @@
-<HTML>
-<CENTER><A HREF = "Section_modify.html">Previous Section</A> - <A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> - <A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A> - <A HREF = "Section_errors.html">Next Section</A> 
-</CENTER>
-
-
-
-
-
-
-<HR>
-
-<H3>11. Python interface to LAMMPS 
-</H3>
-<P>LAMMPS can work together with Python in two ways.  First, Python can
-wrap LAMMPS through the <A HREF = "Section_howto.html#howto_19">LAMMPS library
-interface</A>, so that a Python script can
-create one or more instances of LAMMPS and launch one or more
-simulations.  In Python lingo, this is "extending" Python with LAMMPS.
-</P>
-<P>Second, LAMMPS can use the Python interpreter, so that a LAMMPS input
-script can invoke Python code, and pass information back-and-forth
-between the input script and Python functions you write.  The Python
-code can also callback to LAMMPS to query or change its attributes.
-In Python lingo, this is "embedding" Python in LAMMPS.
-</P>
-<P>This section describes how to do both.
-</P>
-<UL><LI>11.1 <A HREF = "#py_1">Overview of running LAMMPS from Python</A>
-<LI>11.2 <A HREF = "#py_2">Overview of using Python from a LAMMPS script</A> 
-<LI>11.3 <A HREF = "#py_3">Building LAMMPS as a shared library</A>
-<LI>11.4 <A HREF = "#py_4">Installing the Python wrapper into Python</A>
-<LI>11.5 <A HREF = "#py_5">Extending Python with MPI to run in parallel</A>
-<LI>11.6 <A HREF = "#py_6">Testing the Python-LAMMPS interface</A>
-<LI>11.7 <A HREF = "#py_7">Using LAMMPS from Python</A>
-<LI>11.8 <A HREF = "#py_8">Example Python scripts that use LAMMPS</A> 
-</UL>
-<P>If you are not familiar with it, <A HREF = "http://www.python.org">Python</A> is a
-powerful scripting and programming language which can essentially do
-anything that faster, lower-level languages like C or C++ can do, but
-typically with much fewer lines of code.  When used in embedded mode,
-Python can perform operations that the simplistic LAMMPS input script
-syntax cannot.  Python can be also be used as a "glue" language to
-drive a program through its library interface, or to hook multiple
-pieces of software together, such as a simulation package plus a
-visualization package, or to run a coupled multiscale or multiphysics
-model.
-</P>
-<P>See <A HREF = "Section_howto.html#howto_10">Section_howto 10</A> of the manual and
-the couple directory of the distribution for more ideas about coupling
-LAMMPS to other codes.  See <A HREF = "Section_howto.html#howto_19">Section_howto
-19</A> for a description of the LAMMPS
-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 either when calling LAMMPS from Python or
-when calling Python from a LAMMPS input script and then calling back
-to LAMMPS from Python code.  The library interface is designed to be
-easy to add functions to.  Thus the Python interface to LAMMPS is also
-easy to extend as well.
-</P>
-<P>If you create interesting Python scripts that run LAMMPS or
-interesting Python functions that can be called from a LAMMPS input
-script, that you think would be useful to other users, please <A HREF = "http://lammps.sandia.gov/authors.html">email
-them to the developers</A>.  We can
-include them in the LAMMPS distribution.
-</P>
-<HR>
-
-<HR>
-
-<A NAME = "py_1"></A><H4>11.1 Overview of running LAMMPS from Python 
-</H4>
-<P>The LAMMPS distribution includes a python directory with all you need
-to run LAMMPS from Python.  The python/lammps.py file wraps the LAMMPS
-library interface, with one wrapper function per LAMMPS library
-function.  This file makes it is possible to do the following either
-from a Python script, or interactively from a Python prompt: create
-one or more instances of LAMMPS, invoke LAMMPS commands or give it an
-input script, run LAMMPS incrementally, extract LAMMPS results, an
-modify internal LAMMPS variables.  From a Python script you can do
-this in serial or parallel.  Running Python interactively in parallel
-does not generally work, unless you have a version of Python that
-extends standard Python to enable multiple instances of Python to read
-what you type.
-</P>
-<P>To do all of this, you must first build LAMMPS as a shared library,
-then insure that your Python can find the python/lammps.py file and
-the shared library.  These steps are explained in subsequent sections
-11.3 and 11.4.  Sections 11.5 and 11.6 discuss using MPI from a
-parallel Python program and how to test that you are ready to use
-LAMMPS from Python.  Section 11.7 lists all the functions in the
-current LAMMPS library interface and how to call them from Python.
-</P>
-<P>Section 11.8 gives some examples of coupling LAMMPS to other tools via
-Python.  For example, LAMMPS can easily be coupled to a GUI or other
-visualization tools that display graphs or animations in real time as
-LAMMPS runs.  Examples of such scripts are inlcluded in the python
-directory.
-</P>
-<P>Two advantages of using Python to run LAMMPS are how concise the
-language is, and that it can be run interactively, enabling rapid
-development and debugging of programs.  If you use it to mostly invoke
-costly operations within LAMMPS, such as running a simulation for a
-reasonable number of timesteps, then the overhead cost of invoking
-LAMMPS thru Python will be negligible.
-</P>
-<P>The Python wrapper for LAMMPS uses the amazing and magical (to me)
-"ctypes" package in Python, which auto-generates the interface code
-needed between Python and a set of C interface routines for a library.
-Ctypes is part of standard Python for versions 2.5 and later.  You can
-check which version of Python you have installed, by simply typing
-"python" at a shell prompt.
-</P>
-<HR>
-
-<A NAME = "py_2"></A><H4>11.2 Overview of using Python from a LAMMPS script 
-</H4>
-<P>IMPORTANT NOTE: It is not currently possible to use the
-<A HREF = "python.html">python</A> command described in this section with Python 3,
-only with Python 2.  The C API changed from Python 2 to 3 and the
-LAMMPS code is not compatible with both.
-</P>
-<P>LAMMPS has a <A HREF = "python.html">python</A> command which can be used in an
-input script to define and execute a Python function that you write
-the code for.  The Python function can also be assigned to a LAMMPS
-python-style variable via the <A HREF = "variable.html">variable</A> command.  Each
-time the variable is evaluated, either in the LAMMPS input script
-itself, or by another LAMMPS command that uses the variable, this will
-trigger the Python function to be invoked.
-</P>
-<P>The Python code for the function can be included directly in the input
-script or in an auxiliary file.  The function can have arguments which
-are mapped to LAMMPS variables (also defined in the input script) and
-it can return a value to a LAMMPS variable.  This is thus a mechanism
-for your input script to pass information to a piece of Python code,
-ask Python to execute the code, and return information to your input
-script.
-</P>
-<P>Note that a Python function can be arbitrarily complex.  It can import
-other Python modules, instantiate Python classes, call other Python
-functions, etc.  The Python code that you provide can contain more
-code than the single function.  It can contain other functions or
-Python classes, as well as global variables or other mechanisms for
-storing state between calls from LAMMPS to the function.
-</P>
-<P>The Python function you provide can consist of "pure" Python code that
-only performs operations provided by standard Python.  However, the
-Python function can also "call back" to LAMMPS through its
-Python-wrapped library interface, in the manner described in the
-previous section 11.1.  This means it can issue LAMMPS input script
-commands or query and set internal LAMMPS state.  As an example, this
-can be useful in an input script to create a more complex loop with
-branching logic, than can be created using the simple looping and
-brancing logic enabled by the <A HREF = "next_html">next</A> and <A HREF = "if.html">if</A>
-commands.
-</P>
-<P>See the <A HREF = "python.html">python</A> doc page and the <A HREF = "variable.html">variable</A>
-doc page for its python-style variables for more info, including
-examples of Python code you can write for both pure Python operations
-and callbacks to LAMMPS.
-</P>
-<P>To run pure Python code from LAMMPS, you only need to build LAMMPS
-with the PYTHON package installed:
-</P>
-<P>make yes-python
-make machine
-</P>
-<P>Note that this will link LAMMPS with the Python library on your
-system, which typically requires several auxiliary system libraries to
-also be linked.  The list of these libraries and the paths to find
-them are specified in the lib/python/Makefile.lammps file.  You need
-to insure that file contains the correct information for your version
-of Python and your machine to successfully build LAMMPS.  See the
-lib/python/README file for more info.
-</P>
-<P>If you want to write Python code with callbacks to LAMMPS, then you
-must also follow the steps overviewed in the preceeding section (11.1)
-for running LAMMPS from Python.  I.e. you must build LAMMPS as a
-shared library and insure that Python can find the python/lammps.py
-file and the shared library.
-</P>
-<HR>
-
-<A NAME = "py_3"></A><H4>11.3 Building LAMMPS as a shared library 
-</H4>
-<P>Instructions on how to build LAMMPS as a shared library are given in
-<A HREF = "Section_start.html#start_5">Section_start 5</A>.  A shared library is one
-that is dynamically loadable, which is what Python requires to wrap
-LAMMPS.  On Linux this is a library file that ends in ".so", not ".a".
-</P>
-<P>>From the src directory, type
-</P>
-<PRE>make foo mode=shlib 
-</PRE>
-<P>where foo is the machine target name, such as linux or g++ or serial.
-This should create the file liblammps_foo.so in the src directory, as
-well as a soft link liblammps.so, which is what the Python wrapper will
-load by default.  Note that if you are building multiple machine
-versions of the shared library, the soft link is always set to the
-most recently built version.
-</P>
-<P>If this fails, see <A HREF = "Section_start.html#start_5">Section_start 5</A> for
-more details, especially if your LAMMPS build uses auxiliary libraries
-like MPI or FFTW which may not be built as shared libraries on your
-system.
-</P>
-<HR>
-
-<A NAME = "py_4"></A><H4>11.4 Installing the Python wrapper into Python 
-</H4>
-<P>For Python to invoke LAMMPS, there are 2 files it needs to know about:
-</P>
-<UL><LI>python/lammps.py
-<LI>src/liblammps.so 
-</UL>
-<P>Lammps.py is the Python wrapper on the LAMMPS library interface.
-Liblammps.so is the shared LAMMPS library that Python loads, as
-described above.
-</P>
-<P>You can insure Python can find these files in one of two ways:
-</P>
-<UL><LI>set two environment variables
-<LI>run the python/install.py script 
-</UL>
-<P>If you set the paths to these files as environment variables, you only
-have to do it once.  For the csh or tcsh shells, add something like
-this to your ~/.cshrc file, one line for each of the two files:
-</P>
-<PRE>setenv PYTHONPATH $<I>PYTHONPATH</I>:/home/sjplimp/lammps/python
-setenv LD_LIBRARY_PATH $<I>LD_LIBRARY_PATH</I>:/home/sjplimp/lammps/src 
-</PRE>
-<P>If you use the python/install.py script, you need to invoke it every
-time you rebuild LAMMPS (as a shared library) or make changes to the
-python/lammps.py file.
-</P>
-<P>You can invoke install.py from the python directory as
-</P>
-<PRE>% python install.py [libdir] [pydir] 
-</PRE>
-<P>The optional libdir is where to copy the LAMMPS shared library to; the
-default is /usr/local/lib.  The optional pydir is where to copy the
-lammps.py file to; the default is the site-packages directory of the
-version of Python that is running the install script.
-</P>
-<P>Note that libdir must be a location that is in your default
-LD_LIBRARY_PATH, like /usr/local/lib or /usr/lib.  And pydir must be a
-location that Python looks in by default for imported modules, like
-its site-packages dir.  If you want to copy these files to
-non-standard locations, such as within your own user space, you will
-need to set your PYTHONPATH and LD_LIBRARY_PATH environment variables
-accordingly, as above.
-</P>
-<P>If the install.py script does not allow you to copy files into system
-directories, prefix the python command with "sudo".  If you do this,
-make sure that the Python that root runs is the same as the Python you
-run.  E.g. you may need to do something like
-</P>
-<PRE>% sudo /usr/local/bin/python install.py [libdir] [pydir] 
-</PRE>
-<P>You can also invoke install.py from the make command in the src
-directory as
-</P>
-<PRE>% make install-python 
-</PRE>
-<P>In this mode you cannot append optional arguments.  Again, you may
-need to prefix this with "sudo".  In this mode you cannot control
-which Python is invoked by root.
-</P>
-<P>Note that if you want Python to be able to load different versions of
-the LAMMPS shared library (see <A HREF = "#py_5">this section</A> below), you will
-need to manually copy files like liblammps_g++.so into the appropriate
-system directory.  This is not needed if you set the LD_LIBRARY_PATH
-environment variable as described above.
-</P>
-<HR>
-
-<A NAME = "py_5"></A><H4>11.5 Extending Python with MPI to run in parallel 
-</H4>
-<P>If you wish to run LAMMPS in parallel from Python, you need to extend
-your Python with an interface to MPI.  This also allows you to
-make MPI calls directly from Python in your script, if you desire.
-</P>
-<P>There are several Python packages available that purport to wrap MPI
-as a library and allow MPI functions to be called from Python.
-</P>
-<P>These include
-</P>
-<UL><LI><A HREF = "http://pympi.sourceforge.net/">pyMPI</A>
-<LI><A HREF = "http://code.google.com/p/maroonmpi/">maroonmpi</A>
-<LI><A HREF = "http://code.google.com/p/mpi4py/">mpi4py</A>
-<LI><A HREF = "http://nbcr.sdsc.edu/forum/viewtopic.php?t=89&sid=c997fefc3933bd66204875b436940f16">myMPI</A>
-<LI><A HREF = "http://code.google.com/p/pypar">Pypar</A> 
-</UL>
-<P>All of these except pyMPI work by wrapping the MPI library and
-exposing (some portion of) its interface to your Python script.  This
-means Python cannot be used interactively in parallel, since they do
-not address the issue of interactive input to multiple instances of
-Python running on different processors.  The one exception is pyMPI,
-which alters the Python interpreter to address this issue, and (I
-believe) creates a new alternate executable (in place of "python"
-itself) as a result.
-</P>
-<P>In principle any of these Python/MPI packages should work to invoke
-LAMMPS in parallel and to make MPI calls themselves from a Python
-script which is itself running in parallel.  However, when I
-downloaded and looked at a few of them, their documentation was
-incomplete and I had trouble with their installation.  It's not clear
-if some of the packages are still being actively developed and
-supported.
-</P>
-<P>The one I recommend, since I have successfully used it with LAMMPS, is
-Pypar.  Pypar requires the ubiquitous <A HREF = "http://numpy.scipy.org">Numpy
-package</A> be installed in your Python.  After
-launching python, type
-</P>
-<PRE>import numpy 
-</PRE>
-<P>to see if it is installed.  If not, here is how to install it (version
-1.3.0b1 as of April 2009).  Unpack the numpy tarball and from its
-top-level directory, type
-</P>
-<PRE>python setup.py build
-sudo python setup.py install 
-</PRE>
-<P>The "sudo" is only needed if required to copy Numpy files into your
-Python distribution's site-packages directory.
-</P>
-<P>To install Pypar (version pypar-2.1.4_94 as of Aug 2012), unpack it
-and from its "source" directory, type
-</P>
-<PRE>python setup.py build
-sudo python setup.py install 
-</PRE>
-<P>Again, the "sudo" is only needed if required to copy Pypar files into
-your Python distribution's site-packages directory.
-</P>
-<P>If you have successully installed Pypar, you should be able to run
-Python and type
-</P>
-<PRE>import pypar 
-</PRE>
-<P>without error.  You should also be able to run python in parallel
-on a simple test script
-</P>
-<PRE>% mpirun -np 4 python test.py 
-</PRE>
-<P>where test.py contains the lines
-</P>
-<PRE>import pypar
-print "Proc %d out of %d procs" % (pypar.rank(),pypar.size()) 
-</PRE>
-<P>and see one line of output for each processor you run on.
-</P>
-<P>IMPORTANT NOTE: To use Pypar and LAMMPS in parallel from Python, you
-must insure both are using the same version of MPI.  If you only have
-one MPI installed on your system, this is not an issue, but it can be
-if you have multiple MPIs.  Your LAMMPS build is explicit about which
-MPI it is using, since you specify the details in your lo-level
-src/MAKE/Makefile.foo file.  Pypar uses the "mpicc" command to find
-information about the MPI it uses to build against.  And it tries to
-load "libmpi.so" from the LD_LIBRARY_PATH.  This may or may not find
-the MPI library that LAMMPS is using.  If you have problems running
-both Pypar and LAMMPS together, this is an issue you may need to
-address, e.g. by moving other MPI installations so that Pypar finds
-the right one.
-</P>
-<HR>
-
-<A NAME = "py_6"></A><H4>11.6 Testing the Python-LAMMPS interface 
-</H4>
-<P>To test if LAMMPS is callable from Python, launch Python interactively
-and type:
-</P>
-<PRE>>>> from lammps import lammps
->>> lmp = lammps() 
-</PRE>
-<P>If you get no errors, you're ready to use LAMMPS from Python.  If the
-2nd command fails, the most common error to see is
-</P>
-<PRE>OSError: Could not load LAMMPS dynamic library 
-</PRE>
-<P>which means Python was unable to load the LAMMPS shared library.  This
-typically occurs if the system can't find the LAMMPS shared library or
-one of the auxiliary shared libraries it depends on, or if something
-about the library is incompatible with your Python.  The error message
-should give you an indication of what went wrong.
-</P>
-<P>You can also test the load directly in Python as follows, without
-first importing from the lammps.py file:
-</P>
-<PRE>>>> from ctypes import CDLL
->>> CDLL("liblammps.so") 
-</PRE>
-<P>If an error occurs, carefully go thru the steps in <A HREF = "Section_start.html#start_5">Section_start
-5</A> and above about building a shared
-library and about insuring Python can find the necessary two files
-it needs.
-</P>
-<H5><B>Test LAMMPS and Python in serial:</B> 
-</H5>
-<P>To run a LAMMPS test in serial, type these lines into Python
-interactively from the bench directory:
-</P>
-<PRE>>>> from lammps import lammps
->>> lmp = lammps()
->>> lmp.file("in.lj") 
-</PRE>
-<P>Or put the same lines in the file test.py and run it as
-</P>
-<PRE>% python test.py 
-</PRE>
-<P>Either way, you should see the results of running the in.lj benchmark
-on a single processor appear on the screen, the same as if you had
-typed something like:
-</P>
-<PRE>lmp_g++ < in.lj 
-</PRE>
-<H5><B>Test LAMMPS and Python in parallel:</B> 
-</H5>
-<P>To run LAMMPS in parallel, assuming you have installed the
-<A HREF = "http://datamining.anu.edu.au/~ole/pypar">Pypar</A> package as discussed
-above, create a test.py file containing these lines:
-</P>
-<PRE>import pypar
-from lammps import lammps
-lmp = lammps()
-lmp.file("in.lj")
-print "Proc %d out of %d procs has" % (pypar.rank(),pypar.size()),lmp
-pypar.finalize() 
-</PRE>
-<P>You can then run it in parallel as:
-</P>
-<PRE>% mpirun -np 4 python test.py 
-</PRE>
-<P>and you should see the same output as if you had typed
-</P>
-<PRE>% mpirun -np 4 lmp_g++ < in.lj 
-</PRE>
-<P>Note that if you leave out the 3 lines from test.py that specify Pypar
-commands you will instantiate and run LAMMPS independently on each of
-the P processors specified in the mpirun command.  In this case you
-should get 4 sets of output, each showing that a LAMMPS run was made
-on a single processor, instead of one set of output showing that
-LAMMPS ran on 4 processors.  If the 1-processor outputs occur, it
-means that Pypar is not working correctly.
-</P>
-<P>Also note that once you import the PyPar module, Pypar initializes MPI
-for you, and you can use MPI calls directly in your Python script, as
-described in the Pypar documentation.  The last line of your Python
-script should be pypar.finalize(), to insure MPI is shut down
-correctly.
-</P>
-<H5><B>Running Python scripts:</B> 
-</H5>
-<P>Note that any Python script (not just for LAMMPS) can be invoked in
-one of several ways:
-</P>
-<PRE>% python foo.script
-% python -i foo.script
-% foo.script 
-</PRE>
-<P>The last command requires that the first line of the script be
-something like this:
-</P>
-<PRE>#!/usr/local/bin/python 
-#!/usr/local/bin/python -i 
-</PRE>
-<P>where the path points to where you have Python installed, and that you
-have made the script file executable:
-</P>
-<PRE>% chmod +x foo.script 
-</PRE>
-<P>Without the "-i" flag, Python will exit when the script finishes.
-With the "-i" flag, you will be left in the Python interpreter when
-the script finishes, so you can type subsequent commands.  As
-mentioned above, you can only run Python interactively when running
-Python on a single processor, not in parallel.
-</P>
-<HR>
-
-<HR>
-
-<A NAME = "py_7"></A><H4>11.7 Using LAMMPS from Python 
-</H4>
-<P>As described above, the Python interface to LAMMPS consists of a
-Python "lammps" module, the source code for which is in
-python/lammps.py, which creates a "lammps" object, with a set of
-methods that can be invoked on that object.  The sample Python code
-below assumes you have first imported the "lammps" module in your
-Python script, as follows:
-</P>
-<PRE>from lammps import lammps 
-</PRE>
-<P>These are the methods defined by the lammps module.  If you look at
-the files src/library.cpp and src/library.h you will see that they
-correspond one-to-one with calls you can make to the LAMMPS library
-from a C++ or C or Fortran program.
-</P>
-<PRE>lmp = lammps()           # create a LAMMPS object using the default liblammps.so library
-lmp = lammps(ptr=lmpptr) # ditto, but use lmpptr as previously created LAMMPS object
-lmp = lammps("g++")      # create a LAMMPS object using the liblammps_g++.so library
-lmp = lammps("",list)    # ditto, with command-line args, e.g. list = ["-echo","screen"]
-lmp = lammps("g++",list) 
-</PRE>
-<PRE>lmp.close()              # destroy a LAMMPS object 
-</PRE>
-<PRE>lmp.file(file)           # run an entire input script, file = "in.lj"
-lmp.command(cmd)         # invoke a single LAMMPS command, cmd = "run 100" 
-</PRE>
-<PRE>xlo = lmp.extract_global(name,type)  # extract a global quantity
-                                     # name = "boxxlo", "nlocal", etc
-				     # type = 0 = int
-				     #        1 = double 
-</PRE>
-<PRE>coords = lmp.extract_atom(name,type)      # extract a per-atom quantity
-                                          # name = "x", "type", etc
-				          # type = 0 = vector of ints
-				          #        1 = array of ints
-				          #        2 = vector of doubles
-				          #        3 = array of doubles 
-</PRE>
-<PRE>eng = lmp.extract_compute(id,style,type)  # extract value(s) from a compute
-v3 = lmp.extract_fix(id,style,type,i,j)   # extract value(s) from a fix
-                                          # id = ID of compute or fix
-					  # style = 0 = global data
-					  #	    1 = per-atom data
-					  #         2 = local data
-					  # type = 0 = scalar
-					  #	   1 = vector
-					  #        2 = array
-					  # i,j = indices of value in global vector or array 
-</PRE>
-<PRE>var = lmp.extract_variable(name,group,flag)  # extract value(s) from a variable
-	                                     # name = name of variable
-					     # group = group ID (ignored for equal-style variables)
-					     # flag = 0 = equal-style variable
-					     #        1 = atom-style variable 
-</PRE>
-<PRE>flag = lmp.set_variable(name,value)       # set existing named string-style variable to value, flag = 0 if successful
-natoms = lmp.get_natoms()                 # total # of atoms as int
-data = lmp.gather_atoms(name,type,count)  # return atom attribute of all atoms gathered into data, ordered by atom ID
-                                          # name = "x", "charge", "type", etc
-                                          # count = # of per-atom values, 1 or 3, etc
-lmp.scatter_atoms(name,type,count,data)   # scatter atom attribute of all atoms from data, ordered by atom ID
-                                          # name = "x", "charge", "type", etc
-                                          # count = # of per-atom values, 1 or 3, etc 
-</PRE>
-<HR>
-
-<P>IMPORTANT NOTE: Currently, the creation of a LAMMPS object from within
-lammps.py does not take an MPI communicator as an argument.  There
-should be a way to do this, so that the LAMMPS instance runs on a
-subset of processors if desired, but I don't know how to do it from
-Pypar.  So for now, it runs with MPI_COMM_WORLD, which is all the
-processors.  If someone figures out how to do this with one or more of
-the Python wrappers for MPI, like Pypar, please let us know and we
-will amend these doc pages.
-</P>
-<P>The lines
-</P>
-<PRE>from lammps import lammps
-lmp = lammps() 
-</PRE>
-<P>create an instance of LAMMPS, wrapped in a Python class by the lammps
-Python module, and return an instance of the Python class as lmp.  It
-is used to make all subequent calls to the LAMMPS library.
-</P>
-<P>Additional arguments can be used to tell Python the name of the shared
-library to load or to pass arguments to the LAMMPS instance, the same
-as if LAMMPS were launched from a command-line prompt.
-</P>
-<P>If the ptr argument is set like this:
-</P>
-<PRE>lmp = lammps(ptr=lmpptr) 
-</PRE>
-<P>then lmpptr must be an argument passed to Python via the LAMMPS
-<A HREF = "python.html">python</A> command, when it is used to define a Python
-function that is invoked by the LAMMPS input script.  This mode of
-using Python with LAMMPS is described above in 11.2.  The variable
-lmpptr refers to the instance of LAMMPS that called the embedded
-Python interpreter.  Using it as an argument to lammps() allows the
-returned Python class instance "lmp" to make calls to that instance of
-LAMMPS.  See the <A HREF = "python.html">python</A> command doc page for examples
-using this syntax.
-</P>
-<P>Note that you can create multiple LAMMPS objects in your Python
-script, and coordinate and run multiple simulations, e.g.
-</P>
-<PRE>from lammps import lammps
-lmp1 = lammps()
-lmp2 = lammps()
-lmp1.file("in.file1")
-lmp2.file("in.file2") 
-</PRE>
-<P>The file() and command() methods allow an input script or single
-commands to be invoked.
-</P>
-<P>The extract_global(), extract_atom(), extract_compute(),
-extract_fix(), and extract_variable() methods return values or
-pointers to data structures internal to LAMMPS.
-</P>
-<P>For extract_global() see the src/library.cpp file for the list of
-valid names.  New names could easily be added.  A double or integer is
-returned.  You need to specify the appropriate data type via the type
-argument.
-</P>
-<P>For extract_atom(), a pointer to internal LAMMPS atom-based data is
-returned, which you can use via normal Python subscripting.  See the
-extract() method in the src/atom.cpp file for a list of valid names.
-Again, new names could easily be added.  A pointer to a vector of
-doubles or integers, or a pointer to an array of doubles (double **)
-or integers (int **) is returned.  You need to specify the appropriate
-data type via the type argument.
-</P>
-<P>For extract_compute() and extract_fix(), the global, per-atom, or
-local data calulated by the compute or fix can be accessed.  What is
-returned depends on whether the compute or fix calculates a scalar or
-vector or array.  For a scalar, a single double value is returned.  If
-the compute or fix calculates a vector or array, a pointer to the
-internal LAMMPS data is returned, which you can use via normal Python
-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 <A HREF = "Section_howto.html#howto_15">Section_howto 15</A> 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
-<A HREF = "compute.html">computes</A> and <A HREF = "fix.html">fixes</A> for a description of what
-they calculate and store.
-</P>
-<P>For extract_variable(), an <A HREF = "variable.html">equal-style or atom-style
-variable</A> is evaluated and its result returned.
-</P>
-<P>For equal-style variables a single double value is returned and the
-group argument is ignored.  For atom-style variables, a vector of
-doubles is returned, one value per atom, which you can use via normal
-Python subscripting. The values will be zero for atoms not in the
-specified group.
-</P>
-<P>The get_natoms() method returns the total number of atoms in the
-simulation, as an int.
-</P>
-<P>The gather_atoms() method returns a ctypes vector of ints or doubles
-as specified by type, of length count*natoms, for the property of all
-the atoms in the simulation specified by name, ordered by count and
-then by atom ID.  The vector can be used via normal Python
-subscripting.  If atom IDs are not consecutively ordered within
-LAMMPS, a None is returned as indication of an error.
-</P>
-<P>Note that the data structure gather_atoms("x") returns is different
-from the data structure returned by extract_atom("x") in four ways.
-(1) Gather_atoms() returns a vector which you index as x[i];
-extract_atom() returns an array which you index as x[i][j].  (2)
-Gather_atoms() orders the atoms by atom ID while extract_atom() does
-not.  (3) Gathert_atoms() returns a list of all atoms in the
-simulation; extract_atoms() returns just the atoms local to each
-processor.  (4) Finally, the gather_atoms() data structure is a copy
-of the atom coords stored internally in LAMMPS, whereas extract_atom()
-returns an array that effectively points directly to the internal
-data.  This means you can change values inside LAMMPS from Python by
-assigning a new values to the extract_atom() array.  To do this with
-the gather_atoms() vector, you need to change values in the vector,
-then invoke the scatter_atoms() method.
-</P>
-<P>The scatter_atoms() method takes a vector of ints or doubles as
-specified by type, of length count*natoms, for the property of all the
-atoms in the simulation specified by name, ordered by bount and then
-by atom ID.  It uses the vector of data to overwrite the corresponding
-properties for each atom inside LAMMPS.  This requires LAMMPS to have
-its "map" option enabled; see the <A HREF = "atom_modify.html">atom_modify</A>
-command for details.  If it is not, or if atom IDs are not
-consecutively ordered, no coordinates are reset.
-</P>
-<P>The array of coordinates passed to scatter_atoms() must be a ctypes
-vector of ints or doubles, allocated and initialized something like
-this:
-</P>
-<PRE>from ctypes import *
-natoms = lmp.get_natoms()
-n3 = 3*natoms
-x = (n3*c_double)()
-x[0] = x coord of atom with ID 1
-x[1] = y coord of atom with ID 1
-x[2] = z coord of atom with ID 1
-x[3] = x coord of atom with ID 2
-...
-x[n3-1] = z coord of atom with ID natoms
-lmp.scatter_coords("x",1,3,x) 
-</PRE>
-<P>Alternatively, you can just change values in the vector returned by
-gather_atoms("x",1,3), since it is a ctypes vector of doubles.
-</P>
-<HR>
-
-<P>As noted above, these Python class methods correspond one-to-one with
-the functions in the LAMMPS library interface in src/library.cpp and
-library.h.  This means you can extend the Python wrapper via the
-following steps:
-</P>
-<UL><LI>Add a new interface function to src/library.cpp and
-src/library.h. 
-
-<LI>Rebuild LAMMPS as a shared library. 
-
-<LI>Add a wrapper method to python/lammps.py for this interface
-function. 
-
-<LI>You should now be able to invoke the new interface function from a
-Python script.  Isn't ctypes amazing? 
-</UL>
-<HR>
-
-<HR>
-
-<A NAME = "py_8"></A><H4>11.8 Example Python scripts that use LAMMPS 
-</H4>
-<P>These are the Python scripts included as demos in the python/examples
-directory of the LAMMPS distribution, to illustrate the kinds of
-things that are possible when Python wraps LAMMPS.  If you create your
-own scripts, send them to us and we can include them in the LAMMPS
-distribution.
-</P>
-<DIV ALIGN=center><TABLE  BORDER=1 >
-<TR><TD >trivial.py</TD><TD > read/run a LAMMPS input script thru Python</TD></TR>
-<TR><TD >demo.py</TD><TD > invoke various LAMMPS library interface routines</TD></TR>
-<TR><TD >simple.py</TD><TD > mimic operation of couple/simple/simple.cpp in Python</TD></TR>
-<TR><TD >gui.py</TD><TD > GUI go/stop/temperature-slider to control LAMMPS</TD></TR>
-<TR><TD >plot.py</TD><TD > real-time temeperature plot with GnuPlot via Pizza.py</TD></TR>
-<TR><TD >viz_tool.py</TD><TD > real-time viz via some viz package</TD></TR>
-<TR><TD >vizplotgui_tool.py</TD><TD > combination of viz_tool.py and plot.py and gui.py 
-</TD></TR></TABLE></DIV>
-
-<HR>
-
-<P>For the viz_tool.py and vizplotgui_tool.py commands, replace "tool"
-with "gl" or "atomeye" or "pymol" or "vmd", depending on what
-visualization package you have installed. 
-</P>
-<P>Note that for GL, you need to be able to run the Pizza.py GL tool,
-which is included in the pizza sub-directory.  See the <A HREF = "http://www.sandia.gov/~sjplimp/pizza.html">Pizza.py doc
-pages</A> for more info:
-</P>
-
-
-<P>Note that for AtomEye, you need version 3, and there is a line in the
-scripts that specifies the path and name of the executable.  See the
-AtomEye WWW pages <A HREF = "http://mt.seas.upenn.edu/Archive/Graphics/A">here</A> or <A HREF = "http://mt.seas.upenn.edu/Archive/Graphics/A3/A3.html">here</A> for more details:
-</P>
-<PRE>http://mt.seas.upenn.edu/Archive/Graphics/A
-http://mt.seas.upenn.edu/Archive/Graphics/A3/A3.html 
-</PRE>
-
-
-
-
-<P>The latter link is to AtomEye 3 which has the scriping
-capability needed by these Python scripts.
-</P>
-<P>Note that for PyMol, you need to have built and installed the
-open-source version of PyMol in your Python, so that you can import it
-from a Python script.  See the PyMol WWW pages <A HREF = "http://www.pymol.org">here</A> or
-<A HREF = "http://sourceforge.net/scm/?type=svn&group_id=4546">here</A> for more details:
-</P>
-<PRE>http://www.pymol.org
-http://sourceforge.net/scm/?type=svn&group_id=4546 
-</PRE>
-
-
-
-
-<P>The latter link is to the open-source version.
-</P>
-<P>Note that for VMD, you need a fairly current version (1.8.7 works for
-me) and there are some lines in the pizza/vmd.py script for 4 PIZZA
-variables that have to match the VMD installation on your system.
-</P>
-<HR>
-
-<P>See the python/README file for instructions on how to run them and the
-source code for individual scripts for comments about what they do.
-</P>
-<P>Here are screenshots of the vizplotgui_tool.py script in action for
-different visualization package options.  Click to see larger images:
-</P>
-<A HREF = "JPG/screenshot_gl.jpg"><IMG SRC = "JPG/screenshot_gl_small.jpg"></A>
-
-<A HREF = "JPG/screenshot_atomeye.jpg"><IMG SRC = "JPG/screenshot_atomeye_small.jpg"></A>
-
-<A HREF = "JPG/screenshot_pymol.jpg"><IMG SRC = "JPG/screenshot_pymol_small.jpg"></A>
-
-<A HREF = "JPG/screenshot_vmd.jpg"><IMG SRC = "JPG/screenshot_vmd_small.jpg"></A>
-
-</HTML>
--- a/doc/Section_python.txt
+++ b/doc/Section_python.txt
@ -1,777 +0,0 @@
-"Previous Section"_Section_modify.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_errors.html :c
-
-:link(lws,http://lammps.sandia.gov)
-:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
-
-:line
-
-11. Python interface to LAMMPS :h3
-
-LAMMPS can work together with Python in two ways.  First, Python can
-wrap LAMMPS through the "LAMMPS library
-interface"_Section_howto.html#howto_19, so that a Python script can
-create one or more instances of LAMMPS and launch one or more
-simulations.  In Python lingo, this is "extending" Python with LAMMPS.
-
-Second, LAMMPS can use the Python interpreter, so that a LAMMPS input
-script can invoke Python code, and pass information back-and-forth
-between the input script and Python functions you write.  The Python
-code can also callback to LAMMPS to query or change its attributes.
-In Python lingo, this is "embedding" Python in LAMMPS.
-
-This section describes how to do both.
-
-11.1 "Overview of running LAMMPS from Python"_#py_1
-11.2 "Overview of using Python from a LAMMPS script"_#py_2 
-11.3 "Building LAMMPS as a shared library"_#py_3
-11.4 "Installing the Python wrapper into Python"_#py_4
-11.5 "Extending Python with MPI to run in parallel"_#py_5
-11.6 "Testing the Python-LAMMPS interface"_#py_6
-11.7 "Using LAMMPS from Python"_#py_7
-11.8 "Example Python scripts that use LAMMPS"_#py_8 :ul
-
-If you are not familiar with it, "Python"_http://www.python.org is a
-powerful scripting and programming language which can essentially do
-anything that faster, lower-level languages like C or C++ can do, but
-typically with much fewer lines of code.  When used in embedded mode,
-Python can perform operations that the simplistic LAMMPS input script
-syntax cannot.  Python can be also be used as a "glue" language to
-drive a program through its library interface, or to hook multiple
-pieces of software together, such as a simulation package plus a
-visualization package, or to run a coupled multiscale or multiphysics
-model.
-
-See "Section_howto 10"_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 "Section_howto
-19"_Section_howto.html#howto_19 for a description of the LAMMPS
-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 either when calling LAMMPS from Python or
-when calling Python from a LAMMPS input script and then calling back
-to LAMMPS from Python code.  The library interface is designed to be
-easy to add functions to.  Thus the Python interface to LAMMPS is also
-easy to extend as well.
-
-If you create interesting Python scripts that run LAMMPS or
-interesting Python functions that can be called from a LAMMPS input
-script, that you think would be useful to other users, please "email
-them to the developers"_http://lammps.sandia.gov/authors.html.  We can
-include them in the LAMMPS distribution.
-
-:line
-:line
-
-11.1 Overview of running LAMMPS from Python :link(py_1),h4
-
-The LAMMPS distribution includes a python directory with all you need
-to run LAMMPS from Python.  The python/lammps.py file wraps the LAMMPS
-library interface, with one wrapper function per LAMMPS library
-function.  This file makes it is possible to do the following either
-from a Python script, or interactively from a Python prompt: create
-one or more instances of LAMMPS, invoke LAMMPS commands or give it an
-input script, run LAMMPS incrementally, extract LAMMPS results, an
-modify internal LAMMPS variables.  From a Python script you can do
-this in serial or parallel.  Running Python interactively in parallel
-does not generally work, unless you have a version of Python that
-extends standard Python to enable multiple instances of Python to read
-what you type.
-
-To do all of this, you must first build LAMMPS as a shared library,
-then insure that your Python can find the python/lammps.py file and
-the shared library.  These steps are explained in subsequent sections
-11.3 and 11.4.  Sections 11.5 and 11.6 discuss using MPI from a
-parallel Python program and how to test that you are ready to use
-LAMMPS from Python.  Section 11.7 lists all the functions in the
-current LAMMPS library interface and how to call them from Python.
-
-Section 11.8 gives some examples of coupling LAMMPS to other tools via
-Python.  For example, LAMMPS can easily be coupled to a GUI or other
-visualization tools that display graphs or animations in real time as
-LAMMPS runs.  Examples of such scripts are inlcluded in the python
-directory.
-
-Two advantages of using Python to run LAMMPS are how concise the
-language is, and that it can be run interactively, enabling rapid
-development and debugging of programs.  If you use it to mostly invoke
-costly operations within LAMMPS, such as running a simulation for a
-reasonable number of timesteps, then the overhead cost of invoking
-LAMMPS thru Python will be negligible.
-
-The Python wrapper for LAMMPS uses the amazing and magical (to me)
-"ctypes" package in Python, which auto-generates the interface code
-needed between Python and a set of C interface routines for a library.
-Ctypes is part of standard Python for versions 2.5 and later.  You can
-check which version of Python you have installed, by simply typing
-"python" at a shell prompt.
-
-:line
-
-11.2 Overview of using Python from a LAMMPS script :link(py_2),h4
-
-IMPORTANT NOTE: It is not currently possible to use the
-"python"_python.html command described in this section with Python 3,
-only with Python 2.  The C API changed from Python 2 to 3 and the
-LAMMPS code is not compatible with both.
-
-LAMMPS has a "python"_python.html command which can be used in an
-input script to define and execute a Python function that you write
-the code for.  The Python function can also be assigned to a LAMMPS
-python-style variable via the "variable"_variable.html command.  Each
-time the variable is evaluated, either in the LAMMPS input script
-itself, or by another LAMMPS command that uses the variable, this will
-trigger the Python function to be invoked.
-
-The Python code for the function can be included directly in the input
-script or in an auxiliary file.  The function can have arguments which
-are mapped to LAMMPS variables (also defined in the input script) and
-it can return a value to a LAMMPS variable.  This is thus a mechanism
-for your input script to pass information to a piece of Python code,
-ask Python to execute the code, and return information to your input
-script.
-
-Note that a Python function can be arbitrarily complex.  It can import
-other Python modules, instantiate Python classes, call other Python
-functions, etc.  The Python code that you provide can contain more
-code than the single function.  It can contain other functions or
-Python classes, as well as global variables or other mechanisms for
-storing state between calls from LAMMPS to the function.
-
-The Python function you provide can consist of "pure" Python code that
-only performs operations provided by standard Python.  However, the
-Python function can also "call back" to LAMMPS through its
-Python-wrapped library interface, in the manner described in the
-previous section 11.1.  This means it can issue LAMMPS input script
-commands or query and set internal LAMMPS state.  As an example, this
-can be useful in an input script to create a more complex loop with
-branching logic, than can be created using the simple looping and
-brancing logic enabled by the "next"_next_html and "if"_if.html
-commands.
-
-See the "python"_python.html doc page and the "variable"_variable.html
-doc page for its python-style variables for more info, including
-examples of Python code you can write for both pure Python operations
-and callbacks to LAMMPS.
-
-To run pure Python code from LAMMPS, you only need to build LAMMPS
-with the PYTHON package installed:
-
-make yes-python
-make machine
-
-Note that this will link LAMMPS with the Python library on your
-system, which typically requires several auxiliary system libraries to
-also be linked.  The list of these libraries and the paths to find
-them are specified in the lib/python/Makefile.lammps file.  You need
-to insure that file contains the correct information for your version
-of Python and your machine to successfully build LAMMPS.  See the
-lib/python/README file for more info.
-
-If you want to write Python code with callbacks to LAMMPS, then you
-must also follow the steps overviewed in the preceeding section (11.1)
-for running LAMMPS from Python.  I.e. you must build LAMMPS as a
-shared library and insure that Python can find the python/lammps.py
-file and the shared library.
-
-:line
-
-11.3 Building LAMMPS as a shared library :link(py_3),h4
-
-Instructions on how to build LAMMPS as a shared library are given in
-"Section_start 5"_Section_start.html#start_5.  A shared library is one
-that is dynamically loadable, which is what Python requires to wrap
-LAMMPS.  On Linux this is a library file that ends in ".so", not ".a".
-
->From the src directory, type
-
-make foo mode=shlib :pre
-
-where foo is the machine target name, such as linux or g++ or serial.
-This should create the file liblammps_foo.so in the src directory, as
-well as a soft link liblammps.so, which is what the Python wrapper will
-load by default.  Note that if you are building multiple machine
-versions of the shared library, the soft link is always set to the
-most recently built version.
-
-If this fails, see "Section_start 5"_Section_start.html#start_5 for
-more details, especially if your LAMMPS build uses auxiliary libraries
-like MPI or FFTW which may not be built as shared libraries on your
-system.
-
-:line
-
-11.4 Installing the Python wrapper into Python :link(py_4),h4
-
-For Python to invoke LAMMPS, there are 2 files it needs to know about:
-
-python/lammps.py
-src/liblammps.so :ul
-
-Lammps.py is the Python wrapper on the LAMMPS library interface.
-Liblammps.so is the shared LAMMPS library that Python loads, as
-described above.
-
-You can insure Python can find these files in one of two ways:
-
-set two environment variables
-run the python/install.py script :ul
-
-If you set the paths to these files as environment variables, you only
-have to do it once.  For the csh or tcsh shells, add something like
-this to your ~/.cshrc file, one line for each of the two files:
-
-setenv PYTHONPATH ${PYTHONPATH}:/home/sjplimp/lammps/python
-setenv LD_LIBRARY_PATH ${LD_LIBRARY_PATH}:/home/sjplimp/lammps/src :pre
-
-If you use the python/install.py script, you need to invoke it every
-time you rebuild LAMMPS (as a shared library) or make changes to the
-python/lammps.py file.
-
-You can invoke install.py from the python directory as
-
-% python install.py \[libdir\] \[pydir\] :pre
-
-The optional libdir is where to copy the LAMMPS shared library to; the
-default is /usr/local/lib.  The optional pydir is where to copy the
-lammps.py file to; the default is the site-packages directory of the
-version of Python that is running the install script.
-
-Note that libdir must be a location that is in your default
-LD_LIBRARY_PATH, like /usr/local/lib or /usr/lib.  And pydir must be a
-location that Python looks in by default for imported modules, like
-its site-packages dir.  If you want to copy these files to
-non-standard locations, such as within your own user space, you will
-need to set your PYTHONPATH and LD_LIBRARY_PATH environment variables
-accordingly, as above.
-
-If the install.py script does not allow you to copy files into system
-directories, prefix the python command with "sudo".  If you do this,
-make sure that the Python that root runs is the same as the Python you
-run.  E.g. you may need to do something like
-
-% sudo /usr/local/bin/python install.py \[libdir\] \[pydir\] :pre
-
-You can also invoke install.py from the make command in the src
-directory as
-
-% make install-python :pre
-
-In this mode you cannot append optional arguments.  Again, you may
-need to prefix this with "sudo".  In this mode you cannot control
-which Python is invoked by root.
-
-Note that if you want Python to be able to load different versions of
-the LAMMPS shared library (see "this section"_#py_5 below), you will
-need to manually copy files like liblammps_g++.so into the appropriate
-system directory.  This is not needed if you set the LD_LIBRARY_PATH
-environment variable as described above.
-
-:line
-
-11.5 Extending Python with MPI to run in parallel :link(py_5),h4
-
-If you wish to run LAMMPS in parallel from Python, you need to extend
-your Python with an interface to MPI.  This also allows you to
-make MPI calls directly from Python in your script, if you desire.
-
-There are several Python packages available that purport to wrap MPI
-as a library and allow MPI functions to be called from Python.
-
-These include
-
-"pyMPI"_http://pympi.sourceforge.net/
-"maroonmpi"_http://code.google.com/p/maroonmpi/
-"mpi4py"_http://code.google.com/p/mpi4py/
-"myMPI"_http://nbcr.sdsc.edu/forum/viewtopic.php?t=89&sid=c997fefc3933bd66204875b436940f16
-"Pypar"_http://code.google.com/p/pypar :ul
-
-All of these except pyMPI work by wrapping the MPI library and
-exposing (some portion of) its interface to your Python script.  This
-means Python cannot be used interactively in parallel, since they do
-not address the issue of interactive input to multiple instances of
-Python running on different processors.  The one exception is pyMPI,
-which alters the Python interpreter to address this issue, and (I
-believe) creates a new alternate executable (in place of "python"
-itself) as a result.
-
-In principle any of these Python/MPI packages should work to invoke
-LAMMPS in parallel and to make MPI calls themselves from a Python
-script which is itself running in parallel.  However, when I
-downloaded and looked at a few of them, their documentation was
-incomplete and I had trouble with their installation.  It's not clear
-if some of the packages are still being actively developed and
-supported.
-
-The one I recommend, since I have successfully used it with LAMMPS, is
-Pypar.  Pypar requires the ubiquitous "Numpy
-package"_http://numpy.scipy.org be installed in your Python.  After
-launching python, type
-
-import numpy :pre
-
-to see if it is installed.  If not, here is how to install it (version
-1.3.0b1 as of April 2009).  Unpack the numpy tarball and from its
-top-level directory, type
-
-python setup.py build
-sudo python setup.py install :pre
-
-The "sudo" is only needed if required to copy Numpy files into your
-Python distribution's site-packages directory.
-
-To install Pypar (version pypar-2.1.4_94 as of Aug 2012), unpack it
-and from its "source" directory, type
-
-python setup.py build
-sudo python setup.py install :pre
-
-Again, the "sudo" is only needed if required to copy Pypar files into
-your Python distribution's site-packages directory.
-
-If you have successully installed Pypar, you should be able to run
-Python and type
-
-import pypar :pre
-
-without error.  You should also be able to run python in parallel
-on a simple test script
-
-% mpirun -np 4 python test.py :pre
-
-where test.py contains the lines
-
-import pypar
-print "Proc %d out of %d procs" % (pypar.rank(),pypar.size()) :pre
-
-and see one line of output for each processor you run on.
-
-IMPORTANT NOTE: To use Pypar and LAMMPS in parallel from Python, you
-must insure both are using the same version of MPI.  If you only have
-one MPI installed on your system, this is not an issue, but it can be
-if you have multiple MPIs.  Your LAMMPS build is explicit about which
-MPI it is using, since you specify the details in your lo-level
-src/MAKE/Makefile.foo file.  Pypar uses the "mpicc" command to find
-information about the MPI it uses to build against.  And it tries to
-load "libmpi.so" from the LD_LIBRARY_PATH.  This may or may not find
-the MPI library that LAMMPS is using.  If you have problems running
-both Pypar and LAMMPS together, this is an issue you may need to
-address, e.g. by moving other MPI installations so that Pypar finds
-the right one.
-
-:line
-
-11.6 Testing the Python-LAMMPS interface :link(py_6),h4
-
-To test if LAMMPS is callable from Python, launch Python interactively
-and type:
-
->>> from lammps import lammps
->>> lmp = lammps() :pre
-
-If you get no errors, you're ready to use LAMMPS from Python.  If the
-2nd command fails, the most common error to see is
-
-OSError: Could not load LAMMPS dynamic library :pre
-
-which means Python was unable to load the LAMMPS shared library.  This
-typically occurs if the system can't find the LAMMPS shared library or
-one of the auxiliary shared libraries it depends on, or if something
-about the library is incompatible with your Python.  The error message
-should give you an indication of what went wrong.
-
-You can also test the load directly in Python as follows, without
-first importing from the lammps.py file:
-
->>> from ctypes import CDLL
->>> CDLL("liblammps.so") :pre
-
-If an error occurs, carefully go thru the steps in "Section_start
-5"_Section_start.html#start_5 and above about building a shared
-library and about insuring Python can find the necessary two files
-it needs.
-
-[Test LAMMPS and Python in serial:] :h5
-
-To run a LAMMPS test in serial, type these lines into Python
-interactively from the bench directory:
-
->>> from lammps import lammps
->>> lmp = lammps()
->>> lmp.file("in.lj") :pre
-
-Or put the same lines in the file test.py and run it as
-
-% python test.py :pre
-
-Either way, you should see the results of running the in.lj benchmark
-on a single processor appear on the screen, the same as if you had
-typed something like:
-
-lmp_g++ < in.lj :pre
-
-[Test LAMMPS and Python in parallel:] :h5
-
-To run LAMMPS in parallel, assuming you have installed the
-"Pypar"_http://datamining.anu.edu.au/~ole/pypar package as discussed
-above, create a test.py file containing these lines:
-
-import pypar
-from lammps import lammps
-lmp = lammps()
-lmp.file("in.lj")
-print "Proc %d out of %d procs has" % (pypar.rank(),pypar.size()),lmp
-pypar.finalize() :pre
-
-You can then run it in parallel as:
-
-% mpirun -np 4 python test.py :pre
-
-and you should see the same output as if you had typed
-
-% mpirun -np 4 lmp_g++ < in.lj :pre
-
-Note that if you leave out the 3 lines from test.py that specify Pypar
-commands you will instantiate and run LAMMPS independently on each of
-the P processors specified in the mpirun command.  In this case you
-should get 4 sets of output, each showing that a LAMMPS run was made
-on a single processor, instead of one set of output showing that
-LAMMPS ran on 4 processors.  If the 1-processor outputs occur, it
-means that Pypar is not working correctly.
-
-Also note that once you import the PyPar module, Pypar initializes MPI
-for you, and you can use MPI calls directly in your Python script, as
-described in the Pypar documentation.  The last line of your Python
-script should be pypar.finalize(), to insure MPI is shut down
-correctly.
-
-[Running Python scripts:] :h5
-
-Note that any Python script (not just for LAMMPS) can be invoked in
-one of several ways:
-
-% python foo.script
-% python -i foo.script
-% foo.script :pre
-
-The last command requires that the first line of the script be
-something like this:
-
-#!/usr/local/bin/python 
-#!/usr/local/bin/python -i :pre
-
-where the path points to where you have Python installed, and that you
-have made the script file executable:
-
-% chmod +x foo.script :pre
-
-Without the "-i" flag, Python will exit when the script finishes.
-With the "-i" flag, you will be left in the Python interpreter when
-the script finishes, so you can type subsequent commands.  As
-mentioned above, you can only run Python interactively when running
-Python on a single processor, not in parallel.
-
-:line
-:line
-
-11.7 Using LAMMPS from Python :link(py_7),h4
-
-As described above, the Python interface to LAMMPS consists of a
-Python "lammps" module, the source code for which is in
-python/lammps.py, which creates a "lammps" object, with a set of
-methods that can be invoked on that object.  The sample Python code
-below assumes you have first imported the "lammps" module in your
-Python script, as follows:
-
-from lammps import lammps :pre
-
-These are the methods defined by the lammps module.  If you look at
-the files src/library.cpp and src/library.h you will see that they
-correspond one-to-one with calls you can make to the LAMMPS library
-from a C++ or C or Fortran program.
-
-lmp = lammps()           # create a LAMMPS object using the default liblammps.so library
-lmp = lammps(ptr=lmpptr) # ditto, but use lmpptr as previously created LAMMPS object
-lmp = lammps("g++")      # create a LAMMPS object using the liblammps_g++.so library
-lmp = lammps("",list)    # ditto, with command-line args, e.g. list = \["-echo","screen"\]
-lmp = lammps("g++",list) :pre
-
-lmp.close()              # destroy a LAMMPS object :pre
-
-lmp.file(file)           # run an entire input script, file = "in.lj"
-lmp.command(cmd)         # invoke a single LAMMPS command, cmd = "run 100" :pre
-
-xlo = lmp.extract_global(name,type)  # extract a global quantity
-                                     # name = "boxxlo", "nlocal", etc
-				     # type = 0 = int
-				     #        1 = double :pre
-
-coords = lmp.extract_atom(name,type)      # extract a per-atom quantity
-                                          # name = "x", "type", etc
-				          # type = 0 = vector of ints
-				          #        1 = array of ints
-				          #        2 = vector of doubles
-				          #        3 = array of doubles :pre
-
-eng = lmp.extract_compute(id,style,type)  # extract value(s) from a compute
-v3 = lmp.extract_fix(id,style,type,i,j)   # extract value(s) from a fix
-                                          # id = ID of compute or fix
-					  # style = 0 = global data
-					  #	    1 = per-atom data
-					  #         2 = local data
-					  # type = 0 = scalar
-					  #	   1 = vector
-					  #        2 = array
-					  # i,j = indices of value in global vector or array :pre
-
-var = lmp.extract_variable(name,group,flag)  # extract value(s) from a variable
-	                                     # name = name of variable
-					     # group = group ID (ignored for equal-style variables)
-					     # flag = 0 = equal-style variable
-					     #        1 = atom-style variable :pre
-
-flag = lmp.set_variable(name,value)       # set existing named string-style variable to value, flag = 0 if successful
-natoms = lmp.get_natoms()                 # total # of atoms as int
-data = lmp.gather_atoms(name,type,count)  # return atom attribute of all atoms gathered into data, ordered by atom ID
-                                          # name = "x", "charge", "type", etc
-                                          # count = # of per-atom values, 1 or 3, etc
-lmp.scatter_atoms(name,type,count,data)   # scatter atom attribute of all atoms from data, ordered by atom ID
-                                          # name = "x", "charge", "type", etc
-                                          # count = # of per-atom values, 1 or 3, etc :pre
-
-:line
-
-IMPORTANT NOTE: Currently, the creation of a LAMMPS object from within
-lammps.py does not take an MPI communicator as an argument.  There
-should be a way to do this, so that the LAMMPS instance runs on a
-subset of processors if desired, but I don't know how to do it from
-Pypar.  So for now, it runs with MPI_COMM_WORLD, which is all the
-processors.  If someone figures out how to do this with one or more of
-the Python wrappers for MPI, like Pypar, please let us know and we
-will amend these doc pages.
-
-The lines
-
-from lammps import lammps
-lmp = lammps() :pre
-
-create an instance of LAMMPS, wrapped in a Python class by the lammps
-Python module, and return an instance of the Python class as lmp.  It
-is used to make all subequent calls to the LAMMPS library.
-
-Additional arguments can be used to tell Python the name of the shared
-library to load or to pass arguments to the LAMMPS instance, the same
-as if LAMMPS were launched from a command-line prompt.
-
-If the ptr argument is set like this:
-
-lmp = lammps(ptr=lmpptr) :pre
-
-then lmpptr must be an argument passed to Python via the LAMMPS
-"python"_python.html command, when it is used to define a Python
-function that is invoked by the LAMMPS input script.  This mode of
-using Python with LAMMPS is described above in 11.2.  The variable
-lmpptr refers to the instance of LAMMPS that called the embedded
-Python interpreter.  Using it as an argument to lammps() allows the
-returned Python class instance "lmp" to make calls to that instance of
-LAMMPS.  See the "python"_python.html command doc page for examples
-using this syntax.
-
-Note that you can create multiple LAMMPS objects in your Python
-script, and coordinate and run multiple simulations, e.g.
-
-from lammps import lammps
-lmp1 = lammps()
-lmp2 = lammps()
-lmp1.file("in.file1")
-lmp2.file("in.file2") :pre
-
-The file() and command() methods allow an input script or single
-commands to be invoked.
-
-The extract_global(), extract_atom(), extract_compute(),
-extract_fix(), and extract_variable() methods return values or
-pointers to data structures internal to LAMMPS.
-
-For extract_global() see the src/library.cpp file for the list of
-valid names.  New names could easily be added.  A double or integer is
-returned.  You need to specify the appropriate data type via the type
-argument.
-
-For extract_atom(), a pointer to internal LAMMPS atom-based data is
-returned, which you can use via normal Python subscripting.  See the
-extract() method in the src/atom.cpp file for a list of valid names.
-Again, new names could easily be added.  A pointer to a vector of
-doubles or integers, or a pointer to an array of doubles (double **)
-or integers (int **) is returned.  You need to specify the appropriate
-data type via the type argument.
-
-For extract_compute() and extract_fix(), the global, per-atom, or
-local data calulated by the compute or fix can be accessed.  What is
-returned depends on whether the compute or fix calculates a scalar or
-vector or array.  For a scalar, a single double value is returned.  If
-the compute or fix calculates a vector or array, a pointer to the
-internal LAMMPS data is returned, which you can use via normal Python
-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 "Section_howto 15"_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
-they calculate and store.
-
-For extract_variable(), an "equal-style or atom-style
-variable"_variable.html is evaluated and its result returned.
-
-For equal-style variables a single double value is returned and the
-group argument is ignored.  For atom-style variables, a vector of
-doubles is returned, one value per atom, which you can use via normal
-Python subscripting. The values will be zero for atoms not in the
-specified group.
-
-The get_natoms() method returns the total number of atoms in the
-simulation, as an int.
-
-The gather_atoms() method returns a ctypes vector of ints or doubles
-as specified by type, of length count*natoms, for the property of all
-the atoms in the simulation specified by name, ordered by count and
-then by atom ID.  The vector can be used via normal Python
-subscripting.  If atom IDs are not consecutively ordered within
-LAMMPS, a None is returned as indication of an error.
-
-Note that the data structure gather_atoms("x") returns is different
-from the data structure returned by extract_atom("x") in four ways.
-(1) Gather_atoms() returns a vector which you index as x\[i\];
-extract_atom() returns an array which you index as x\[i\]\[j\].  (2)
-Gather_atoms() orders the atoms by atom ID while extract_atom() does
-not.  (3) Gathert_atoms() returns a list of all atoms in the
-simulation; extract_atoms() returns just the atoms local to each
-processor.  (4) Finally, the gather_atoms() data structure is a copy
-of the atom coords stored internally in LAMMPS, whereas extract_atom()
-returns an array that effectively points directly to the internal
-data.  This means you can change values inside LAMMPS from Python by
-assigning a new values to the extract_atom() array.  To do this with
-the gather_atoms() vector, you need to change values in the vector,
-then invoke the scatter_atoms() method.
-
-The scatter_atoms() method takes a vector of ints or doubles as
-specified by type, of length count*natoms, for the property of all the
-atoms in the simulation specified by name, ordered by bount and then
-by atom ID.  It uses the vector of data to overwrite the corresponding
-properties for each atom inside LAMMPS.  This requires LAMMPS to have
-its "map" option enabled; see the "atom_modify"_atom_modify.html
-command for details.  If it is not, or if atom IDs are not
-consecutively ordered, no coordinates are reset.
-
-The array of coordinates passed to scatter_atoms() must be a ctypes
-vector of ints or doubles, allocated and initialized something like
-this:
-
-from ctypes import *
-natoms = lmp.get_natoms()
-n3 = 3*natoms
-x = (n3*c_double)()
-x\[0\] = x coord of atom with ID 1
-x\[1\] = y coord of atom with ID 1
-x\[2\] = z coord of atom with ID 1
-x\[3\] = x coord of atom with ID 2
-...
-x\[n3-1\] = z coord of atom with ID natoms
-lmp.scatter_coords("x",1,3,x) :pre
-
-Alternatively, you can just change values in the vector returned by
-gather_atoms("x",1,3), since it is a ctypes vector of doubles.
-
-:line 
-
-As noted above, these Python class methods correspond one-to-one with
-the functions in the LAMMPS library interface in src/library.cpp and
-library.h.  This means you can extend the Python wrapper via the
-following steps:
-
-Add a new interface function to src/library.cpp and
-src/library.h. :ulb,l
-
-Rebuild LAMMPS as a shared library. :l
-
-Add a wrapper method to python/lammps.py for this interface
-function. :l
-
-You should now be able to invoke the new interface function from a
-Python script.  Isn't ctypes amazing? :l,ule
-
-:line
-:line
-
-11.8 Example Python scripts that use LAMMPS :link(py_8),h4
-
-These are the Python scripts included as demos in the python/examples
-directory of the LAMMPS distribution, to illustrate the kinds of
-things that are possible when Python wraps LAMMPS.  If you create your
-own scripts, send them to us and we can include them in the LAMMPS
-distribution.
-
-trivial.py, read/run a LAMMPS input script thru Python,
-demo.py, invoke various LAMMPS library interface routines,
-simple.py, mimic operation of couple/simple/simple.cpp in Python,
-gui.py, GUI go/stop/temperature-slider to control LAMMPS,
-plot.py, real-time temeperature plot with GnuPlot via Pizza.py,
-viz_tool.py, real-time viz via some viz package,
-vizplotgui_tool.py, combination of viz_tool.py and plot.py and gui.py :tb(c=2)
-
-:line
-
-For the viz_tool.py and vizplotgui_tool.py commands, replace "tool"
-with "gl" or "atomeye" or "pymol" or "vmd", depending on what
-visualization package you have installed. 
-
-Note that for GL, you need to be able to run the Pizza.py GL tool,
-which is included in the pizza sub-directory.  See the "Pizza.py doc
-pages"_pizza for more info:
-
-:link(pizza,http://www.sandia.gov/~sjplimp/pizza.html)
-
-Note that for AtomEye, you need version 3, and there is a line in the
-scripts that specifies the path and name of the executable.  See the
-AtomEye WWW pages "here"_atomeye or "here"_atomeye3 for more details:
-
-http://mt.seas.upenn.edu/Archive/Graphics/A
-http://mt.seas.upenn.edu/Archive/Graphics/A3/A3.html :pre
-
-:link(atomeye,http://mt.seas.upenn.edu/Archive/Graphics/A)
-:link(atomeye3,http://mt.seas.upenn.edu/Archive/Graphics/A3/A3.html)
-
-The latter link is to AtomEye 3 which has the scriping
-capability needed by these Python scripts.
-
-Note that for PyMol, you need to have built and installed the
-open-source version of PyMol in your Python, so that you can import it
-from a Python script.  See the PyMol WWW pages "here"_pymol or
-"here"_pymolopen for more details:
-
-http://www.pymol.org
-http://sourceforge.net/scm/?type=svn&group_id=4546 :pre
-
-:link(pymol,http://www.pymol.org)
-:link(pymolopen,http://sourceforge.net/scm/?type=svn&group_id=4546)
-
-The latter link is to the open-source version.
-
-Note that for VMD, you need a fairly current version (1.8.7 works for
-me) and there are some lines in the pizza/vmd.py script for 4 PIZZA
-variables that have to match the VMD installation on your system.
-
-:line
-
-See the python/README file for instructions on how to run them and the
-source code for individual scripts for comments about what they do.
-
-Here are screenshots of the vizplotgui_tool.py script in action for
-different visualization package options.  Click to see larger images:
-
-:image(JPG/screenshot_gl_small.jpg,JPG/screenshot_gl.jpg)
-:image(JPG/screenshot_atomeye_small.jpg,JPG/screenshot_atomeye.jpg)
-:image(JPG/screenshot_pymol_small.jpg,JPG/screenshot_pymol.jpg)
-:image(JPG/screenshot_vmd_small.jpg,JPG/screenshot_vmd.jpg)
--- a/doc/Section_start.html
+++ b/doc/Section_start.html
--- a/doc/Section_start.txt
+++ b/doc/Section_start.txt
--- a/doc/Section_tools.html
+++ b/doc/Section_tools.html
@ -1,572 +0,0 @@
-<HTML>
-<CENTER><A HREF = "Section_perf.html">Previous Section</A> - <A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> - <A HREF = "Manual.html">LAMMPS
-Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A> - <A HREF = "Section_modify.html">Next
-Section</A> 
-</CENTER>
-
-
-
-
-
-
-<HR>
-
-<H3>9. Additional tools 
-</H3>
-<P>LAMMPS is designed to be a computational kernel for performing
-molecular dynamics computations.  Additional pre- and post-processing
-steps are often necessary to setup and analyze a simulation.  A few
-additional tools are provided with the LAMMPS distribution and are
-described in this section.
-</P>
-<P>Our group has also written and released a separate toolkit called
-<A HREF = "http://www.sandia.gov/~sjplimp/pizza.html">Pizza.py</A> which provides tools for doing setup, analysis,
-plotting, and visualization for LAMMPS simulations.  Pizza.py is
-written in <A HREF = "http://www.python.org">Python</A> and is available for download from <A HREF = "http://www.sandia.gov/~sjplimp/pizza.html">the
-Pizza.py WWW site</A>.
-</P>
-
-
-
-
-<P>Note that many users write their own setup or analysis tools or use
-other existing codes and convert their output to a LAMMPS input format
-or vice versa.  The tools listed here are included in the LAMMPS
-distribution as examples of auxiliary tools.  Some of them are not
-actively supported by Sandia, as they were contributed by LAMMPS
-users.  If you have problems using them, we can direct you to the
-authors.
-</P>
-<P>The source code for each of these codes is in the tools sub-directory
-of the LAMMPS distribution.  There is a Makefile (which you may need
-to edit for your platform) which will build several of the tools which
-reside in that directory.  Some of them are larger packages in their
-own sub-directories with their own Makefiles.
-</P>
-<UL><LI><A HREF = "#amber">amber2lmp</A>
-<LI><A HREF = "#binary">binary2txt</A>
-<LI><A HREF = "#charmm">ch2lmp</A>
-<LI><A HREF = "#chain">chain</A>
-<LI><A HREF = "#colvars">colvars</A>
-<LI><A HREF = "#create">createatoms</A>
-<LI><A HREF = "#data">data2xmovie</A>
-<LI><A HREF = "#eamdb">eam database</A>
-<LI><A HREF = "#eamgn">eam generate</A>
-<LI><A HREF = "#eff">eff</A>
-<LI><A HREF = "#emacs">emacs</A>
-<LI><A HREF = "#fep">fep</A>
-<LI><A HREF = "#ipi">i-pi</A>
-<LI><A HREF = "#ipp">ipp</A>
-<LI><A HREF = "#kate">kate</A>
-<LI><A HREF = "#arc">lmp2arc</A>
-<LI><A HREF = "#cfg">lmp2cfg</A>
-<LI><A HREF = "#vmd">lmp2vmd</A>
-<LI><A HREF = "#matlab">matlab</A>
-<LI><A HREF = "#micelle">micelle2d</A>
-<LI><A HREF = "#moltemplate">moltemplate</A>
-<LI><A HREF = "#msi">msi2lmp</A>
-<LI><A HREF = "#phonon">phonon</A>
-<LI><A HREF = "#polybond">polymer bonding</A>
-<LI><A HREF = "#pymol">pymol_asphere</A>
-<LI><A HREF = "#pythontools">python</A>
-<LI><A HREF = "#reax">reax</A>
-<LI><A HREF = "#restart">restart2data</A>
-<LI><A HREF = "#vim">vim</A>
-<LI><A HREF = "#xmgrace">xmgrace</A>
-<LI><A HREF = "#xmovie">xmovie</A> 
-</UL>
-<HR>
-
-<H4><A NAME = "amber"></A>amber2lmp tool 
-</H4>
-<P>The amber2lmp sub-directory contains two Python scripts for converting
-files back-and-forth between the AMBER MD code and LAMMPS.  See the
-README file in amber2lmp for more information.
-</P>
-<P>These tools were written by Keir Novik while he was at Queen Mary
-University of London.  Keir is no longer there and cannot support
-these tools which are out-of-date with respect to the current LAMMPS
-version (and maybe with respect to AMBER as well).  Since we don't use
-these tools at Sandia, you'll need to experiment with them and make
-necessary modifications yourself.
-</P>
-<HR>
-
-<H4><A NAME = "binary"></A>binary2txt tool 
-</H4>
-<P>The file binary2txt.cpp converts one or more binary LAMMPS dump file
-into ASCII text files.  The syntax for running the tool is
-</P>
-<PRE>binary2txt file1 file2 ... 
-</PRE>
-<P>which creates file1.txt, file2.txt, etc.  This tool must be compiled
-on a platform that can read the binary file created by a LAMMPS run,
-since binary files are not compatible across all platforms.
-</P>
-<HR>
-
-<H4><A NAME = "charmm"></A>ch2lmp tool 
-</H4>
-<P>The ch2lmp sub-directory contains tools for converting files
-back-and-forth between the CHARMM MD code and LAMMPS. 
-</P>
-<P>They are intended to make it easy to use CHARMM as a builder and as a
-post-processor for LAMMPS. Using charmm2lammps.pl, you can convert an
-ensemble built in CHARMM into its LAMMPS equivalent.  Using
-lammps2pdb.pl you can convert LAMMPS atom dumps into pdb files.
-</P>
-<P>See the README file in the ch2lmp sub-directory for more information.
-</P>
-<P>These tools were created by Pieter in't Veld (pjintve at sandia.gov)
-and Paul Crozier (pscrozi at sandia.gov) at Sandia.
-</P>
-<HR>
-
-<H4><A NAME = "chain"></A>chain tool 
-</H4>
-<P>The file chain.f creates a LAMMPS data file containing bead-spring
-polymer chains and/or monomer solvent atoms.  It uses a text file
-containing chain definition parameters as an input.  The created
-chains and solvent atoms can strongly overlap, so LAMMPS needs to run
-the system initially with a "soft" pair potential to un-overlap it.
-The syntax for running the tool is
-</P>
-<PRE>chain < def.chain > data.file 
-</PRE>
-<P>See the def.chain or def.chain.ab files in the tools directory for
-examples of definition files.  This tool was used to create the
-system for the <A HREF = "Section_perf.html">chain benchmark</A>.
-</P>
-<HR>
-
-<H4><A NAME = "colvars"></A>colvars tools 
-</H4>
-<P>The colvars directory contains a collection of tools for postprocessing
-data produced by the colvars collective variable library.
-To compile the tools, edit the makefile for your system and run "make".
-</P>
-<P>Please report problems and issues the colvars library and its tools
-at: https://github.com/colvars/colvars/issues
-</P>
-<P>abf_integrate:
-</P>
-<P>MC-based integration of multidimensional free energy gradient
-Version 20110511
-</P>
-<PRE>Syntax: ./abf_integrate < filename > [-n < nsteps >] [-t < temp >] [-m [0|1] (metadynamics)] [-h < hill_height >] [-f < variable_hill_factor >] 
-</PRE>
-<P>The LAMMPS interface to the colvars collective variable library, as
-well as these tools, were created by Axel Kohlmeyer (akohlmey at
-gmail.com) at ICTP, Italy.
-</P>
-<HR>
-
-<H4><A NAME = "create"></A>createatoms tool 
-</H4>
-<P>The tools/createatoms directory contains a Fortran program called
-createAtoms.f which can generate a variety of interesting crystal
-structures and geometries and output the resulting list of atom
-coordinates in LAMMPS or other formats.
-</P>
-<P>See the included Manual.pdf for details.
-</P>
-<P>The tool is authored by Xiaowang Zhou (Sandia), xzhou at sandia.gov.
-</P>
-<HR>
-
-<H4><A NAME = "data"></A>data2xmovie tool 
-</H4>
-<P>The file data2xmovie.c converts a LAMMPS data file into a snapshot
-suitable for visualizing with the <A HREF = "#xmovie">xmovie</A> tool, as if it had
-been output with a dump command from LAMMPS itself.  The syntax for
-running the tool is
-</P>
-<PRE>data2xmovie [options] < infile > outfile 
-</PRE>
-<P>See the top of the data2xmovie.c file for a discussion of the options.
-</P>
-<HR>
-
-<H4><A NAME = "eamdb"></A>eam database tool 
-</H4>
-<P>The tools/eam_database directory contains a Fortran program that will
-generate EAM alloy setfl potential files for any combination of 16
-elements: Cu, Ag, Au, Ni, Pd, Pt, Al, Pb, Fe, Mo, Ta, W, Mg, Co, Ti,
-Zr.  The files can then be used with the <A HREF = "pair_eam.html">pair_style
-eam/alloy</A> command.
-</P>
-<P>The tool is authored by Xiaowang Zhou (Sandia), xzhou at sandia.gov,
-and is based on his paper:
-</P>
-<P>X. W. Zhou, R. A. Johnson, and H. N. G. Wadley, Phys. Rev. B, 69,
-144113 (2004).
-</P>
-<HR>
-
-<H4><A NAME = "eamgn"></A>eam generate tool 
-</H4>
-<P>The tools/eam_generate directory contains several one-file C programs
-that convert an analytic formula into a tabulated <A HREF = "pair_eam.html">embedded atom
-method (EAM)</A> setfl potential file.  The potentials they
-produce are in the potentials directory, and can be used with the
-<A HREF = "pair_eam.html">pair_style eam/alloy</A> command.
-</P>
-<P>The source files and potentials were provided by Gerolf Ziegenhain
-(gerolf at ziegenhain.com).
-</P>
-<HR>
-
-<H4><A NAME = "eff"></A>eff tool 
-</H4>
-<P>The tools/eff directory contains various scripts for generating
-structures and post-processing output for simulations using the
-electron force field (eFF).
-</P>
-<P>These tools were provided by Andres Jaramillo-Botero at CalTech
-(ajaramil at wag.caltech.edu).
-</P>
-<HR>
-
-<H4><A NAME = "emacs"></A>emacs tool 
-</H4>
-<P>The tools/emacs directory contains a Lips add-on file for Emacs that
-enables a lammps-mode for editing of input scripts when using Emacs,
-with various highlighting options setup.
-</P>
-<P>These tools were provided by Aidan Thompson at Sandia
-(athomps at sandia.gov).
-</P>
-<HR>
-
-<H4><A NAME = "fep"></A>fep tool 
-</H4>
-<P>The tools/fep directory contains Python scripts useful for
-post-processing results from performing free-energy perturbation
-simulations using the USER-FEP package.
-</P>
-<P>The scripts were contributed by Agilio Padua (Universite Blaise
-Pascal Clermont-Ferrand), agilio.padua at univ-bpclermont.fr.
-</P>
-<P>See README file in the tools/fep directory.
-</P>
-<HR>
-
-<H4><A NAME = "ipi"></A>i-pi tool 
-</H4>
-<P>The tools/i-pi directory contains a version of the i-PI package, with
-all the LAMMPS-unrelated files removed.  It is provided so that it can
-be used with the <A HREF = "fix_ipi.html">fix ipi</A> command to perform
-path-integral molecular dynamics (PIMD).
-</P>
-<P>The i-PI package was created and is maintained by Michele Ceriotti,
-michele.ceriotti at gmail.com, to interface to a variety of molecular
-dynamics codes.
-</P>
-<P>See the tools/i-pi/manual.pdf file for an overview of i-PI, and the
-<A HREF = "fix_ipi.html">fix ipi</A> doc page for further details on running PIMD
-calculations with LAMMPS.
-</P>
-<HR>
-
-<H4><A NAME = "ipp"></A>ipp tool 
-</H4>
-<P>The tools/ipp directory contains a Perl script ipp which can be used
-to facilitate the creation of a complicated file (say, a lammps input
-script or tools/createatoms input file) using a template file.
-</P>
-<P>ipp was created and is maintained by Reese Jones (Sandia), rjones at
-sandia.gov.
-</P>
-<P>See two examples in the tools/ipp directory.  One of them is for the
-tools/createatoms tool's input file.
-</P>
-<HR>
-
-<H4><A NAME = "kate"></A>kate tool 
-</H4>
-<P>The file in the tools/kate directory is an add-on to the Kate editor
-in the KDE suite that allow syntax highlighting of LAMMPS input
-scripts.  See the README.txt file for details.
-</P>
-<P>The file was provided by Alessandro Luigi Sellerio
-(alessandro.sellerio at ieni.cnr.it).
-</P>
-<HR>
-
-<H4><A NAME = "arc"></A>lmp2arc tool 
-</H4>
-<P>The lmp2arc sub-directory contains a tool for converting LAMMPS output
-files to the format for Accelrys' Insight MD code (formerly
-MSI/Biosym and its Discover MD code).  See the README file for more
-information.
-</P>
-<P>This tool was written by John Carpenter (Cray), Michael Peachey
-(Cray), and Steve Lustig (Dupont).  John is now at the Mayo Clinic
-(jec at mayo.edu), but still fields questions about the tool.
-</P>
-<P>This tool was updated for the current LAMMPS C++ version by Jeff
-Greathouse at Sandia (jagreat at sandia.gov).
-</P>
-<HR>
-
-<H4><A NAME = "cfg"></A>lmp2cfg tool 
-</H4>
-<P>The lmp2cfg sub-directory contains a tool for converting LAMMPS output
-files into a series of *.cfg files which can be read into the
-<A HREF = "http://mt.seas.upenn.edu/Archive/Graphics/A">AtomEye</A> visualizer.  See
-the README file for more information.
-</P>
-<P>This tool was written by Ara Kooser at Sandia (askoose at sandia.gov).
-</P>
-<HR>
-
-<H4><A NAME = "vmd"></A>lmp2vmd tool 
-</H4>
-<P>The lmp2vmd sub-directory contains a README.txt file that describes
-details of scripts and plugin support within the <A HREF = "http://www.ks.uiuc.edu/Research/vmd">VMD
-package</A> for visualizing LAMMPS
-dump files.
-</P>
-<P>The VMD plugins and other supporting scripts were written by Axel
-Kohlmeyer (akohlmey at cmm.chem.upenn.edu) at U Penn.
-</P>
-<HR>
-
-<H4><A NAME = "matlab"></A>matlab tool 
-</H4>
-<P>The matlab sub-directory contains several <A HREF = "http://www.mathworks.com">MATLAB</A> scripts for
-post-processing LAMMPS output.  The scripts include readers for log
-and dump files, a reader for EAM potential files, and a converter that
-reads LAMMPS dump files and produces CFG files that can be visualized
-with the <A HREF = "http://mt.seas.upenn.edu/Archive/Graphics/A">AtomEye</A>
-visualizer.
-</P>
-<P>See the README.pdf file for more information.
-</P>
-<P>These scripts were written by Arun Subramaniyan at Purdue Univ
-(asubrama at purdue.edu).
-</P>
-
-
-<HR>
-
-<H4><A NAME = "micelle"></A>micelle2d tool 
-</H4>
-<P>The file micelle2d.f creates a LAMMPS data file containing short lipid
-chains in a monomer solution.  It uses a text file containing lipid
-definition parameters as an input.  The created molecules and solvent
-atoms can strongly overlap, so LAMMPS needs to run the system
-initially with a "soft" pair potential to un-overlap it.  The syntax
-for running the tool is
-</P>
-<PRE>micelle2d < def.micelle2d > data.file 
-</PRE>
-<P>See the def.micelle2d file in the tools directory for an example of a
-definition file.  This tool was used to create the system for the
-<A HREF = "Section_example.html">micelle example</A>.
-</P>
-<HR>
-
-<H4><A NAME = "moltemplate"></A>moltemplate tool 
-</H4>
-<P>The moltemplate sub-directory contains a Python-based tool for
-building molecular systems based on a text-file description, and
-creating LAMMPS data files that encode their molecular topology as
-lists of bonds, angles, dihedrals, etc.  See the README.TXT file for
-more information.
-</P>
-<P>This tool was written by Andrew Jewett (jewett.aij at gmail.com), who
-supports it.  It has its own WWW page at
-<A HREF = "http://moltemplate.org">http://moltemplate.org</A>.
-</P>
-<HR>
-
-<H4><A NAME = "msi"></A>msi2lmp tool 
-</H4>
-<P>The msi2lmp sub-directory contains a tool for creating LAMMPS input
-data files from Accelrys' Insight MD code (formerly MSI/Biosym and
-its Discover MD code).  See the README file for more information.
-</P>
-<P>This tool was written by John Carpenter (Cray), Michael Peachey
-(Cray), and Steve Lustig (Dupont).  John is now at the Mayo Clinic
-(jec at mayo.edu), but still fields questions about the tool.
-</P>
-<P>This tool may be out-of-date with respect to the current LAMMPS and
-Insight versions.  Since we don't use it at Sandia, you'll need to
-experiment with it yourself.
-</P>
-<HR>
-
-<H4><A NAME = "phonon"></A>phonon tool 
-</H4>
-<P>The phonon sub-directory contains a post-processing tool useful for
-analyzing the output of the <A HREF = "fix_phonon.html">fix phonon</A> command in
-the USER-PHONON package.
-</P>
-<P>See the README file for instruction on building the tool and what
-library it needs.  And see the examples/USER/phonon directory
-for example problems that can be post-processed with this tool.
-</P>
-<P>This tool was written by Ling-Ti Kong at Shanghai Jiao Tong
-University.
-</P>
-<HR>
-
-<H4><A NAME = "polybond"></A>polymer bonding tool 
-</H4>
-<P>The polybond sub-directory contains a Python-based tool useful for
-performing "programmable polymer bonding".  The Python file
-lmpsdata.py provides a "Lmpsdata" class with various methods which can
-be invoked by a user-written Python script to create data files with
-complex bonding topologies.
-</P>
-<P>See the Manual.pdf for details and example scripts.
-</P>
-<P>This tool was written by Zachary Kraus at Georgia Tech.
-</P>
-<HR>
-
-<H4><A NAME = "pymol"></A>pymol_asphere tool 
-</H4>
-<P>The pymol_asphere sub-directory contains a tool for converting a
-LAMMPS dump file that contains orientation info for ellipsoidal
-particles into an input file for the <A HREF = "http://pymol.sourceforge.net">PyMol visualization
-package</A>.
-</P>
-
-
-<P>Specifically, the tool triangulates the ellipsoids so they can be
-viewed as true ellipsoidal particles within PyMol.  See the README and
-examples directory within pymol_asphere for more information.
-</P>
-<P>This tool was written by Mike Brown at Sandia.
-</P>
-<HR>
-
-<H4><A NAME = "pythontools"></A>python tool 
-</H4>
-<P>The python sub-directory contains several Python scripts
-that perform common LAMMPS post-processing tasks, such as:
-</P>
-<UL><LI>extract thermodynamic info from a log file as columns of numbers
-<LI>plot two columns of thermodynamic info from a log file using GnuPlot
-<LI>sort the snapshots in a dump file by atom ID
-<LI>convert multiple <A HREF = "neb.html">NEB</A> dump files into one dump file for viz
-<LI>convert dump files into XYZ, CFG, or PDB format for viz by other packages 
-</UL>
-<P>These are simple scripts built on <A HREF = "http://www.sandia.gov/~sjplimp/pizza.html">Pizza.py</A> modules.  See the
-README for more info on Pizza.py and how to use these scripts.
-</P>
-<HR>
-
-<H4><A NAME = "reax"></A>reax tool 
-</H4>
-<P>The reax sub-directory contains stand-alond codes that can
-post-process the output of the <A HREF = "fix_reax_bonds.html">fix reax/bonds</A>
-command from a LAMMPS simulation using <A HREF = "pair_reax.html">ReaxFF</A>.  See
-the README.txt file for more info.
-</P>
-<P>These tools were written by Aidan Thompson at Sandia.
-</P>
-<HR>
-
-<H4><A NAME = "restart"></A>restart2data tool 
-</H4>
-<P>IMPORTANT NOTE: This tool is now obsolete and is not included in the
-current LAMMPS distribution.  This is becaues there is now a
-<A HREF = "write_data.html">write_data</A> command, which can create a data file
-from within an input script.  Running LAMMPS with the "-r"
-<A HREF = "Section_start.html#start_7">command-line switch</A> as follows:
-</P>
-<P>lmp_g++ -r restartfile datafile
-</P>
-<P>is the same as running a 2-line input script:
-</P>
-<P>read_restart restartfile
-write_data datafile
-</P>
-<P>which will produce the same data file that the restart2data tool used
-to create.  The following information is included in case you have an
-older version of LAMMPS which still includes the restart2data tool.
-</P>
-<P>The file restart2data.cpp converts a binary LAMMPS restart file into
-an ASCII data file.  The syntax for running the tool is
-</P>
-<PRE>restart2data restart-file data-file (input-file) 
-</PRE>
-<P>Input-file is optional and if specified will contain LAMMPS input
-commands for the masses and force field parameters, instead of putting
-those in the data-file.  Only a few force field styles currently
-support this option.
-</P>
-<P>This tool must be compiled on a platform that can read the binary file
-created by a LAMMPS run, since binary files are not compatible across
-all platforms.
-</P>
-<P>Note that a text data file has less precision than a binary restart
-file.  Hence, continuing a run from a converted data file will
-typically not conform as closely to a previous run as will restarting
-from a binary restart file.
-</P>
-<P>If a "%" appears in the specified restart-file, the tool expects a set
-of multiple files to exist.  See the <A HREF = "restart.html">restart</A> and
-<A HREF = "write_restart.html">write_restart</A> commands for info on how such sets
-of files are written by LAMMPS, and how the files are named.
-</P>
-<HR>
-
-<H4><A NAME = "vim"></A>vim tool 
-</H4>
-<P>The files in the tools/vim directory are add-ons to the VIM editor
-that allow easier editing of LAMMPS input scripts.  See the README.txt
-file for details.
-</P>
-<P>These files were provided by Gerolf Ziegenhain (gerolf at
-ziegenhain.com)
-</P>
-<HR>
-
-<H4><A NAME = "xmgrace"></A>xmgrace tool 
-</H4>
-<P>The files in the tools/xmgrace directory can be used to plot the
-thermodynamic data in LAMMPS log files via the xmgrace plotting
-package.  There are several tools in the directory that can be used in
-post-processing mode.  The lammpsplot.cpp file can be compiled and
-used to create plots from the current state of a running LAMMPS
-simulation.
-</P>
-<P>See the README file for details.
-</P>
-<P>These files were provided by Vikas Varshney (vv0210 at gmail.com)
-</P>
-<HR>
-
-<H4><A NAME = "xmovie"></A>xmovie tool 
-</H4>
-<P>The xmovie tool is an X-based visualization package that can read
-LAMMPS dump files and animate them.  It is in its own sub-directory
-with the tools directory.  You may need to modify its Makefile so that
-it can find the appropriate X libraries to link against.
-</P>
-<P>The syntax for running xmovie is
-</P>
-<PRE>xmovie [options] dump.file1 dump.file2 ... 
-</PRE>
-<P>If you just type "xmovie" you will see a list of options.  Note that
-by default, LAMMPS dump files are in scaled coordinates, so you
-typically need to use the -scale option with xmovie.  When xmovie runs
-it opens a visualization window and a control window.  The control
-options are straightforward to use.
-</P>
-<P>Xmovie was mostly written by Mike Uttormark (U Wisconsin) while he
-spent a summer at Sandia.  It displays 2d projections of a 3d domain.
-While simple in design, it is an amazingly fast program that can
-render large numbers of atoms very quickly.  It's a useful tool for
-debugging LAMMPS input and output and making sure your simulation is
-doing what you think it should.  The animations on the Examples page
-of the <A HREF = "http://lammps.sandia.gov">LAMMPS WWW site</A> were created with xmovie.
-</P>
-<P>I've lost contact with Mike, so I hope he's comfortable with us
-distributing his great tool!
-</P>
-</HTML>
--- a/doc/Section_tools.txt
+++ b/doc/Section_tools.txt
@ -1,566 +0,0 @@
-"Previous Section"_Section_perf.html - "LAMMPS WWW Site"_lws - "LAMMPS
-Documentation"_ld - "LAMMPS Commands"_lc - "Next
-Section"_Section_modify.html :c
-
-:link(lws,http://lammps.sandia.gov)
-:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
-
-:line
-
-9. Additional tools :h3
-
-LAMMPS is designed to be a computational kernel for performing
-molecular dynamics computations.  Additional pre- and post-processing
-steps are often necessary to setup and analyze a simulation.  A few
-additional tools are provided with the LAMMPS distribution and are
-described in this section.
-
-Our group has also written and released a separate toolkit called
-"Pizza.py"_pizza which provides tools for doing setup, analysis,
-plotting, and visualization for LAMMPS simulations.  Pizza.py is
-written in "Python"_python and is available for download from "the
-Pizza.py WWW site"_pizza.
-
-:link(pizza,http://www.sandia.gov/~sjplimp/pizza.html)
-:link(python,http://www.python.org)
-
-Note that many users write their own setup or analysis tools or use
-other existing codes and convert their output to a LAMMPS input format
-or vice versa.  The tools listed here are included in the LAMMPS
-distribution as examples of auxiliary tools.  Some of them are not
-actively supported by Sandia, as they were contributed by LAMMPS
-users.  If you have problems using them, we can direct you to the
-authors.
-
-The source code for each of these codes is in the tools sub-directory
-of the LAMMPS distribution.  There is a Makefile (which you may need
-to edit for your platform) which will build several of the tools which
-reside in that directory.  Some of them are larger packages in their
-own sub-directories with their own Makefiles.
-
-"amber2lmp"_#amber
-"binary2txt"_#binary
-"ch2lmp"_#charmm
-"chain"_#chain
-"colvars"_#colvars
-"createatoms"_#create
-"data2xmovie"_#data
-"eam database"_#eamdb
-"eam generate"_#eamgn
-"eff"_#eff
-"emacs"_#emacs
-"fep"_#fep
-"i-pi"_#ipi
-"ipp"_#ipp
-"kate"_#kate
-"lmp2arc"_#arc
-"lmp2cfg"_#cfg
-"lmp2vmd"_#vmd
-"matlab"_#matlab
-"micelle2d"_#micelle
-"moltemplate"_#moltemplate
-"msi2lmp"_#msi
-"phonon"_#phonon
-"polymer bonding"_#polybond
-"pymol_asphere"_#pymol
-"python"_#pythontools
-"reax"_#reax
-"restart2data"_#restart
-"vim"_#vim
-"xmgrace"_#xmgrace
-"xmovie"_#xmovie :ul
-
-:line
-
-amber2lmp tool :h4,link(amber)
-
-The amber2lmp sub-directory contains two Python scripts for converting
-files back-and-forth between the AMBER MD code and LAMMPS.  See the
-README file in amber2lmp for more information.
-
-These tools were written by Keir Novik while he was at Queen Mary
-University of London.  Keir is no longer there and cannot support
-these tools which are out-of-date with respect to the current LAMMPS
-version (and maybe with respect to AMBER as well).  Since we don't use
-these tools at Sandia, you'll need to experiment with them and make
-necessary modifications yourself.
-
-:line
-
-binary2txt tool :h4,link(binary)
-
-The file binary2txt.cpp converts one or more binary LAMMPS dump file
-into ASCII text files.  The syntax for running the tool is
-
-binary2txt file1 file2 ... :pre
-
-which creates file1.txt, file2.txt, etc.  This tool must be compiled
-on a platform that can read the binary file created by a LAMMPS run,
-since binary files are not compatible across all platforms.
-
-:line
-
-ch2lmp tool :h4,link(charmm)
-
-The ch2lmp sub-directory contains tools for converting files
-back-and-forth between the CHARMM MD code and LAMMPS. 
-
-They are intended to make it easy to use CHARMM as a builder and as a
-post-processor for LAMMPS. Using charmm2lammps.pl, you can convert an
-ensemble built in CHARMM into its LAMMPS equivalent.  Using
-lammps2pdb.pl you can convert LAMMPS atom dumps into pdb files.
-
-See the README file in the ch2lmp sub-directory for more information.
-
-These tools were created by Pieter in't Veld (pjintve at sandia.gov)
-and Paul Crozier (pscrozi at sandia.gov) at Sandia.
-
-:line
-
-chain tool :h4,link(chain)
-
-The file chain.f creates a LAMMPS data file containing bead-spring
-polymer chains and/or monomer solvent atoms.  It uses a text file
-containing chain definition parameters as an input.  The created
-chains and solvent atoms can strongly overlap, so LAMMPS needs to run
-the system initially with a "soft" pair potential to un-overlap it.
-The syntax for running the tool is
-
-chain < def.chain > data.file :pre
-
-See the def.chain or def.chain.ab files in the tools directory for
-examples of definition files.  This tool was used to create the
-system for the "chain benchmark"_Section_perf.html.
-
-:line
-
-colvars tools :h4,link(colvars)
-
-The colvars directory contains a collection of tools for postprocessing
-data produced by the colvars collective variable library.
-To compile the tools, edit the makefile for your system and run "make".
-
-Please report problems and issues the colvars library and its tools
-at: https://github.com/colvars/colvars/issues
-
-abf_integrate:
-
-MC-based integration of multidimensional free energy gradient
-Version 20110511
-
-Syntax: ./abf_integrate < filename > \[-n < nsteps >\] \[-t < temp >\] \[-m \[0|1\] (metadynamics)\] \[-h < hill_height >\] \[-f < variable_hill_factor >\] :pre
-
-The LAMMPS interface to the colvars collective variable library, as
-well as these tools, were created by Axel Kohlmeyer (akohlmey at
-gmail.com) at ICTP, Italy.
-
-:line
-
-createatoms tool :h4,link(create)
-
-The tools/createatoms directory contains a Fortran program called
-createAtoms.f which can generate a variety of interesting crystal
-structures and geometries and output the resulting list of atom
-coordinates in LAMMPS or other formats.
-
-See the included Manual.pdf for details.
-
-The tool is authored by Xiaowang Zhou (Sandia), xzhou at sandia.gov.
-
-:line
-
-data2xmovie tool :h4,link(data)
-
-The file data2xmovie.c converts a LAMMPS data file into a snapshot
-suitable for visualizing with the "xmovie"_#xmovie tool, as if it had
-been output with a dump command from LAMMPS itself.  The syntax for
-running the tool is
-
-data2xmovie \[options\] < infile > outfile :pre
-
-See the top of the data2xmovie.c file for a discussion of the options.
-
-:line
-
-eam database tool :h4,link(eamdb)
-
-The tools/eam_database directory contains a Fortran program that will
-generate EAM alloy setfl potential files for any combination of 16
-elements: Cu, Ag, Au, Ni, Pd, Pt, Al, Pb, Fe, Mo, Ta, W, Mg, Co, Ti,
-Zr.  The files can then be used with the "pair_style
-eam/alloy"_pair_eam.html command.
-
-The tool is authored by Xiaowang Zhou (Sandia), xzhou at sandia.gov,
-and is based on his paper:
-
-X. W. Zhou, R. A. Johnson, and H. N. G. Wadley, Phys. Rev. B, 69,
-144113 (2004).
-
-:line
-
-eam generate tool :h4,link(eamgn)
-
-The tools/eam_generate directory contains several one-file C programs
-that convert an analytic formula into a tabulated "embedded atom
-method (EAM)"_pair_eam.html setfl potential file.  The potentials they
-produce are in the potentials directory, and can be used with the
-"pair_style eam/alloy"_pair_eam.html command.
-
-The source files and potentials were provided by Gerolf Ziegenhain
-(gerolf at ziegenhain.com).
-
-:line
-
-eff tool :h4,link(eff)
-
-The tools/eff directory contains various scripts for generating
-structures and post-processing output for simulations using the
-electron force field (eFF).
-
-These tools were provided by Andres Jaramillo-Botero at CalTech
-(ajaramil at wag.caltech.edu).
-
-:line
-
-emacs tool :h4,link(emacs)
-
-The tools/emacs directory contains a Lips add-on file for Emacs that
-enables a lammps-mode for editing of input scripts when using Emacs,
-with various highlighting options setup.
-
-These tools were provided by Aidan Thompson at Sandia
-(athomps at sandia.gov).
-
-:line
-
-fep tool :h4,link(fep)
-
-The tools/fep directory contains Python scripts useful for
-post-processing results from performing free-energy perturbation
-simulations using the USER-FEP package.
-
-The scripts were contributed by Agilio Padua (Universite Blaise
-Pascal Clermont-Ferrand), agilio.padua at univ-bpclermont.fr.
-
-See README file in the tools/fep directory.
-
-:line
-
-i-pi tool :h4,link(ipi)
-
-The tools/i-pi directory contains a version of the i-PI package, with
-all the LAMMPS-unrelated files removed.  It is provided so that it can
-be used with the "fix ipi"_fix_ipi.html command to perform
-path-integral molecular dynamics (PIMD).
-
-The i-PI package was created and is maintained by Michele Ceriotti,
-michele.ceriotti at gmail.com, to interface to a variety of molecular
-dynamics codes.
-
-See the tools/i-pi/manual.pdf file for an overview of i-PI, and the
-"fix ipi"_fix_ipi.html doc page for further details on running PIMD
-calculations with LAMMPS.
-
-:line
-
-ipp tool :h4,link(ipp)
-
-The tools/ipp directory contains a Perl script ipp which can be used
-to facilitate the creation of a complicated file (say, a lammps input
-script or tools/createatoms input file) using a template file.
-
-ipp was created and is maintained by Reese Jones (Sandia), rjones at
-sandia.gov.
-
-See two examples in the tools/ipp directory.  One of them is for the
-tools/createatoms tool's input file.
-
-:line
-
-kate tool :h4,link(kate)
-
-The file in the tools/kate directory is an add-on to the Kate editor
-in the KDE suite that allow syntax highlighting of LAMMPS input
-scripts.  See the README.txt file for details.
-
-The file was provided by Alessandro Luigi Sellerio
-(alessandro.sellerio at ieni.cnr.it).
-
-:line
-
-lmp2arc tool :h4,link(arc)
-
-The lmp2arc sub-directory contains a tool for converting LAMMPS output
-files to the format for Accelrys' Insight MD code (formerly
-MSI/Biosym and its Discover MD code).  See the README file for more
-information.
-
-This tool was written by John Carpenter (Cray), Michael Peachey
-(Cray), and Steve Lustig (Dupont).  John is now at the Mayo Clinic
-(jec at mayo.edu), but still fields questions about the tool.
-
-This tool was updated for the current LAMMPS C++ version by Jeff
-Greathouse at Sandia (jagreat at sandia.gov).
-
-:line
-
-lmp2cfg tool :h4,link(cfg)
-
-The lmp2cfg sub-directory contains a tool for converting LAMMPS output
-files into a series of *.cfg files which can be read into the
-"AtomEye"_http://mt.seas.upenn.edu/Archive/Graphics/A visualizer.  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
-details of scripts and plugin support within the "VMD
-package"_http://www.ks.uiuc.edu/Research/vmd for visualizing LAMMPS
-dump files.
-
-The VMD plugins and other supporting scripts were written by Axel
-Kohlmeyer (akohlmey at cmm.chem.upenn.edu) at U Penn.
-
-:line
-
-matlab tool :h4,link(matlab)
-
-The matlab sub-directory contains several "MATLAB"_matlab scripts for
-post-processing LAMMPS output.  The scripts include readers for log
-and dump files, a reader for EAM potential files, and a converter that
-reads LAMMPS dump files and produces CFG files that can be visualized
-with the "AtomEye"_http://mt.seas.upenn.edu/Archive/Graphics/A
-visualizer.
-
-See the README.pdf file for more information.
-
-These scripts were written by Arun Subramaniyan at Purdue Univ
-(asubrama at purdue.edu).
-
-:link(matlab,http://www.mathworks.com)
-
-:line
-
-micelle2d tool :h4,link(micelle)
-
-The file micelle2d.f creates a LAMMPS data file containing short lipid
-chains in a monomer solution.  It uses a text file containing lipid
-definition parameters as an input.  The created molecules and solvent
-atoms can strongly overlap, so LAMMPS needs to run the system
-initially with a "soft" pair potential to un-overlap it.  The syntax
-for running the tool is
-
-micelle2d < def.micelle2d > data.file :pre
-
-See the def.micelle2d file in the tools directory for an example of a
-definition file.  This tool was used to create the system for the
-"micelle example"_Section_example.html.
-
-:line
-
-moltemplate tool :h4,link(moltemplate)
-
-The moltemplate sub-directory contains a Python-based tool for
-building molecular systems based on a text-file description, and
-creating LAMMPS data files that encode their molecular topology as
-lists of bonds, angles, dihedrals, etc.  See the README.TXT file for
-more information.
-
-This tool was written by Andrew Jewett (jewett.aij at gmail.com), who
-supports it.  It has its own WWW page at
-"http://moltemplate.org"_http://moltemplate.org.
-
-:line
-
-msi2lmp tool :h4,link(msi)
-
-The msi2lmp sub-directory contains a tool for creating LAMMPS input
-data files from Accelrys' Insight MD code (formerly MSI/Biosym and
-its Discover MD code).  See the README file for more information.
-
-This tool was written by John Carpenter (Cray), Michael Peachey
-(Cray), and Steve Lustig (Dupont).  John is now at the Mayo Clinic
-(jec at mayo.edu), but still fields questions about the tool.
-
-This tool may be out-of-date with respect to the current LAMMPS and
-Insight versions.  Since we don't use it at Sandia, you'll need to
-experiment with it yourself.
-
-:line
-
-phonon tool :h4,link(phonon)
-
-The phonon sub-directory contains a post-processing tool useful for
-analyzing the output of the "fix phonon"_fix_phonon.html command in
-the USER-PHONON package.
-
-See the README file for instruction on building the tool and what
-library it needs.  And see the examples/USER/phonon directory
-for example problems that can be post-processed with this tool.
-
-This tool was written by Ling-Ti Kong at Shanghai Jiao Tong
-University.
-
-:line
-
-polymer bonding tool :h4,link(polybond)
-
-The polybond sub-directory contains a Python-based tool useful for
-performing "programmable polymer bonding".  The Python file
-lmpsdata.py provides a "Lmpsdata" class with various methods which can
-be invoked by a user-written Python script to create data files with
-complex bonding topologies.
-
-See the Manual.pdf for details and example scripts.
-
-This tool was written by Zachary Kraus at Georgia Tech.
-
-:line
-
-pymol_asphere tool :h4,link(pymol)
-
-The pymol_asphere sub-directory contains a tool for converting a
-LAMMPS dump file that contains orientation info for ellipsoidal
-particles into an input file for the "PyMol visualization
-package"_pymol.
-
-:link(pymol,http://pymol.sourceforge.net)
-
-Specifically, the tool triangulates the ellipsoids so they can be
-viewed as true ellipsoidal particles within PyMol.  See the README and
-examples directory within pymol_asphere for more information.
-
-This tool was written by Mike Brown at Sandia.
-
-:line
-
-python tool :h4,link(pythontools)
-
-The python sub-directory contains several Python scripts
-that perform common LAMMPS post-processing tasks, such as:
-
-extract thermodynamic info from a log file as columns of numbers
-plot two columns of thermodynamic info from a log file using GnuPlot
-sort the snapshots in a dump file by atom ID
-convert multiple "NEB"_neb.html dump files into one dump file for viz
-convert dump files into XYZ, CFG, or PDB format for viz by other packages :ul
-
-These are simple scripts built on "Pizza.py"_pizza modules.  See the
-README for more info on Pizza.py and how to use these scripts.
-
-:line
-
-reax tool :h4,link(reax)
-
-The reax sub-directory contains stand-alond codes that can
-post-process the output of the "fix reax/bonds"_fix_reax_bonds.html
-command from a LAMMPS simulation using "ReaxFF"_pair_reax.html.  See
-the README.txt file for more info.
-
-These tools were written by Aidan Thompson at Sandia.
-
-:line
-
-restart2data tool :h4,link(restart)
-
-IMPORTANT NOTE: This tool is now obsolete and is not included in the
-current LAMMPS distribution.  This is becaues there is now a
-"write_data"_write_data.html command, which can create a data file
-from within an input script.  Running LAMMPS with the "-r"
-"command-line switch"_Section_start.html#start_7 as follows:
-
-lmp_g++ -r restartfile datafile
-
-is the same as running a 2-line input script:
-
-read_restart restartfile
-write_data datafile
-
-which will produce the same data file that the restart2data tool used
-to create.  The following information is included in case you have an
-older version of LAMMPS which still includes the restart2data tool.
-
-The file restart2data.cpp converts a binary LAMMPS restart file into
-an ASCII data file.  The syntax for running the tool is
-
-restart2data restart-file data-file (input-file) :pre
-
-Input-file is optional and if specified will contain LAMMPS input
-commands for the masses and force field parameters, instead of putting
-those in the data-file.  Only a few force field styles currently
-support this option.
-
-This tool must be compiled on a platform that can read the binary file
-created by a LAMMPS run, since binary files are not compatible across
-all platforms.
-
-Note that a text data file has less precision than a binary restart
-file.  Hence, continuing a run from a converted data file will
-typically not conform as closely to a previous run as will restarting
-from a binary restart file.
-
-If a "%" appears in the specified restart-file, the tool expects a set
-of multiple files to exist.  See the "restart"_restart.html and
-"write_restart"_write_restart.html commands for info on how such sets
-of files are written by LAMMPS, and how the files are named.
-
-:line
-
-vim tool :h4,link(vim)
-
-The files in the tools/vim directory are add-ons to the VIM editor
-that allow easier editing of LAMMPS input scripts.  See the README.txt
-file for details.
-
-These files were provided by Gerolf Ziegenhain (gerolf at
-ziegenhain.com)
-
-:line
-
-xmgrace tool :h4,link(xmgrace)
-
-The files in the tools/xmgrace directory can be used to plot the
-thermodynamic data in LAMMPS log files via the xmgrace plotting
-package.  There are several tools in the directory that can be used in
-post-processing mode.  The lammpsplot.cpp file can be compiled and
-used to create plots from the current state of a running LAMMPS
-simulation.
-
-See the README file for details.
-
-These files were provided by Vikas Varshney (vv0210 at gmail.com)
-
-:line
-
-xmovie tool :h4,link(xmovie)
-
-The xmovie tool is an X-based visualization package that can read
-LAMMPS dump files and animate them.  It is in its own sub-directory
-with the tools directory.  You may need to modify its Makefile so that
-it can find the appropriate X libraries to link against.
-
-The syntax for running xmovie is
-
-xmovie \[options\] dump.file1 dump.file2 ... :pre
-
-If you just type "xmovie" you will see a list of options.  Note that
-by default, LAMMPS dump files are in scaled coordinates, so you
-typically need to use the -scale option with xmovie.  When xmovie runs
-it opens a visualization window and a control window.  The control
-options are straightforward to use.
-
-Xmovie was mostly written by Mike Uttormark (U Wisconsin) while he
-spent a summer at Sandia.  It displays 2d projections of a 3d domain.
-While simple in design, it is an amazingly fast program that can
-render large numbers of atoms very quickly.  It's a useful tool for
-debugging LAMMPS input and output and making sure your simulation is
-doing what you think it should.  The animations on the Examples page
-of the "LAMMPS WWW site"_lws were created with xmovie.
-
-I've lost contact with Mike, so I hope he's comfortable with us
-distributing his great tool!
--- a/doc/accelerate_cuda.html
+++ b/doc/accelerate_cuda.html
@ -1,228 +0,0 @@
-<HTML>
-<CENTER><A HREF = "Section_packages.html">Previous Section</A> - <A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> -
-<A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A> 
-</CENTER>
-
-
-
-
-
-
-<HR>
-
-<P><A HREF = "Section_accelerate.html">Return to Section accelerate overview</A>
-</P>
-<H4>5.3.1 USER-CUDA package 
-</H4>
-<P>The USER-CUDA package was developed by Christian Trott (Sandia) while
-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 general
-features:
-</P>
-<UL><LI>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. 
-
-<LI>The speed-up advantage of this approach is typically better when the
-number of atoms per GPU is large 
-
-<LI>Data will stay on the GPU until a timestep where a non-USER-CUDA 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. 
-
-<LI>Neighbor lists are constructed on the GPU. 
-
-<LI>The package only supports use of a single MPI task, running on a
-single CPU (core), assigned to each GPU. 
-</UL>
-<P>Here is a quick overview of how to use the USER-CUDA package:
-</P>
-<UL><LI>build the library in lib/cuda for your GPU hardware with desired precision
-<LI>include the USER-CUDA package and build LAMMPS
-<LI>use the mpirun command to specify 1 MPI task per GPU (on each node)
-<LI>enable the USER-CUDA package via the "-c on" command-line switch
-<LI>specify the # of GPUs per node
-<LI>use USER-CUDA styles in your input script 
-</UL>
-<P>The latter two steps can be done using the "-pk cuda" and "-sf cuda"
-<A HREF = "Section_start.html#start_7">command-line switches</A> respectively.  Or
-the effect of the "-pk" or "-sf" switches can be duplicated by adding
-the <A HREF = "package.html">package cuda</A> or <A HREF = "suffix.html">suffix cuda</A> commands
-respectively to your input script.
-</P>
-<P><B>Required hardware/software:</B>
-</P>
-<P>To use this package, you need to have one or more NVIDIA GPUs and
-install the NVIDIA Cuda software on your system:
-</P>
-<P>Your NVIDIA GPU needs to support Compute Capability 1.3. This list may
-help you to find out the Compute Capability of your card:
-</P>
-<P>http://en.wikipedia.org/wiki/Comparison_of_Nvidia_graphics_processing_units
-</P>
-<P>Install the Nvidia Cuda Toolkit (version 3.2 or higher) and the
-corresponding GPU drivers.  The Nvidia Cuda SDK is not required, but
-we recommend it also be installed.  You can then make sure its sample
-projects can be compiled without problems.
-</P>
-<P><B>Building LAMMPS with the USER-CUDA package:</B>
-</P>
-<P>This requires two steps (a,b): build the USER-CUDA library, then build
-LAMMPS with the USER-CUDA package.
-</P>
-<P>You can do both these steps in one line, using the src/Make.py script,
-described in <A HREF = "Section_start.html#start_4">Section 2.4</A> of the manual.
-Type "Make.py -h" for help.  If run from the src directory, this
-command will create src/lmp_cuda using src/MAKE/Makefile.mpi as the
-starting Makefile.machine:
-</P>
-<PRE>Make.py -p cuda -cuda mode=single arch=20 -o cuda lib-cuda file mpi 
-</PRE>
-<P>Or you can follow these two (a,b) steps:
-</P>
-<P>(a) Build the USER-CUDA library
-</P>
-<P>The USER-CUDA library is in lammps/lib/cuda.  If your <I>CUDA</I> toolkit
-is not installed in the default system directoy <I>/usr/local/cuda</I> edit
-the file <I>lib/cuda/Makefile.common</I> accordingly.
-</P>
-<P>To build the library with the settings in lib/cuda/Makefile.default,
-simply type:
-</P>
-<PRE>make 
-</PRE>
-<P>To set options when the library is built, type "make OPTIONS", where
-<I>OPTIONS</I> are one or more of the following. The settings will be
-written to the <I>lib/cuda/Makefile.defaults</I> before the build.
-</P>
-<PRE><I>precision=N</I> 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
-<I>arch=M</I> to set GPU compute capability
-  M = 35 for Kepler GPUs
-  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)
-<I>prec_timer=0/1</I> to use hi-precision timers
-  0 = do not use them (default)
-  1 = use them
-  this is usually only useful for Mac machines 
-<I>dbg=0/1</I> to activate debug mode
-  0 = no debug mode (default)
-  1 = yes debug mode
-  this is only useful for developers
-<I>cufft=1</I> for use of the CUDA FFT library
-  0 = no CUFFT support (default)
-  in the future other CUDA-enabled FFT libraries might be supported 
-</PRE>
-<P>If the build is successful, it will produce the files liblammpscuda.a and
-Makefile.lammps.
-</P>
-<P>Note that if you change any of the options (like precision), you need
-to re-build the entire library.  Do a "make clean" first, followed by
-"make".
-</P>
-<P>(b) Build LAMMPS with the USER-CUDA package
-</P>
-<PRE>cd lammps/src
-make yes-user-cuda
-make machine 
-</PRE>
-<P>No additional compile/link flags are needed in Makefile.machine.
-</P>
-<P>Note that if you change the USER-CUDA library precision (discussed
-above) and rebuild the USER-CUDA library, then you also need to
-re-install the USER-CUDA package and re-build LAMMPS, so that all
-affected files are re-compiled and linked to the new USER-CUDA
-library.
-</P>
-<P><B>Run with the USER-CUDA package from the command line:</B>
-</P>
-<P>The mpirun or mpiexec command sets the total number of MPI tasks used
-by LAMMPS (one or multiple per compute node) and the number of MPI
-tasks used per node.  E.g. the mpirun command in MPICH does this via
-its -np and -ppn switches.  Ditto for OpenMPI via -np and -npernode.
-</P>
-<P>When using the USER-CUDA package, you must use exactly one MPI task
-per physical GPU.
-</P>
-<P>You must use the "-c on" <A HREF = "Section_start.html#start_7">command-line
-switch</A> to enable the USER-CUDA package.
-The "-c on" switch also issues a default <A HREF = "package.html">package cuda 1</A>
-command which sets various USER-CUDA options to default values, as
-discussed on the <A HREF = "package.html">package</A> command doc page.
-</P>
-<P>Use the "-sf cuda" <A HREF = "Section_start.html#start_7">command-line switch</A>,
-which will automatically append "cuda" to styles that support it.  Use
-the "-pk cuda Ng" <A HREF = "Section_start.html#start_7">command-line switch</A> to
-set Ng = # of GPUs per node to a different value than the default set
-by the "-c on" switch (1 GPU) or change other <A HREF = "package.html">package
-cuda</A> options.
-</P>
-<PRE>lmp_machine -c on -sf cuda -pk cuda 1 -in in.script                       # 1 MPI task uses 1 GPU
-mpirun -np 2 lmp_machine -c on -sf cuda -pk cuda 2 -in in.script          # 2 MPI tasks use 2 GPUs on a single 16-core (or whatever) node
-mpirun -np 24 -ppn 2 lmp_machine -c on -sf cuda -pk cuda 2 -in in.script  # ditto on 12 16-core nodes 
-</PRE>
-<P>The syntax for the "-pk" switch is the same as same as the "package
-cuda" command.  See the <A HREF = "package.html">package</A> command doc page for
-details, including the default values used for all its options if it
-is not specified.
-</P>
-<P>Note that the default for the <A HREF = "package.html">package cuda</A> command is
-to set the Newton flag to "off" for both pairwise and bonded
-interactions.  This typically gives fastest performance.  If the
-<A HREF = "newton.html">newton</A> command is used in the input script, it can
-override these defaults.
-</P>
-<P><B>Or run with the USER-CUDA package by editing an input script:</B>
-</P>
-<P>The discussion above for the mpirun/mpiexec command and the requirement
-of one MPI task per GPU is the same.
-</P>
-<P>You must still use the "-c on" <A HREF = "Section_start.html#start_7">command-line
-switch</A> to enable the USER-CUDA package.
-</P>
-<P>Use the <A HREF = "suffix.html">suffix cuda</A> command, or you can explicitly add a
-"cuda" suffix to individual styles in your input script, e.g.
-</P>
-<PRE>pair_style lj/cut/cuda 2.5 
-</PRE>
-<P>You only need to use the <A HREF = "package.html">package cuda</A> command if you
-wish to change any of its option defaults, including the number of
-GPUs/node (default = 1), as set by the "-c on" <A HREF = "Section_start.html#start_7">command-line
-switch</A>.
-</P>
-<P><B>Speed-ups to expect:</B>
-</P>
-<P>The performance of a GPU versus a multi-core CPU is a function of your
-hardware, which pair style is used, the number of atoms/GPU, and the
-precision used on the GPU (double, single, mixed).
-</P>
-<P>See the <A HREF = "http://lammps.sandia.gov/bench.html">Benchmark page</A> of the
-LAMMPS web site for performance of the USER-CUDA package on different
-hardware.
-</P>
-<P><B>Guidelines for best performance:</B>
-</P>
-<UL><LI>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. 
-
-<LI>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. 
-</UL>
-<P><B>Restrictions:</B>
-</P>
-<P>None.
-</P>
-</HTML>
--- a/doc/accelerate_cuda.txt
+++ b/doc/accelerate_cuda.txt
@ -1,223 +0,0 @@
-"Previous Section"_Section_packages.html - "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
-
-"Return to Section accelerate overview"_Section_accelerate.html
-
-5.3.1 USER-CUDA package :h4
-
-The USER-CUDA package was developed by Christian Trott (Sandia) while
-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 general
-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-USER-CUDA 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 are constructed on the GPU. :l
-
-The package only supports use of a single MPI task, running on a
-single CPU (core), assigned to each GPU. :l,ule
-
-Here is a quick overview of how to use the USER-CUDA package:
-
-build the library in lib/cuda for your GPU hardware with desired precision
-include the USER-CUDA package and build LAMMPS
-use the mpirun command to specify 1 MPI task per GPU (on each node)
-enable the USER-CUDA package via the "-c on" command-line switch
-specify the # of GPUs per node
-use USER-CUDA styles in your input script :ul
-
-The latter two steps can be done using the "-pk cuda" and "-sf cuda"
-"command-line switches"_Section_start.html#start_7 respectively.  Or
-the effect of the "-pk" or "-sf" switches can be duplicated by adding
-the "package cuda"_package.html or "suffix cuda"_suffix.html commands
-respectively to your input script.
-
-[Required hardware/software:]
-
-To use this package, you need to have one or more NVIDIA GPUs and
-install the 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 (version 3.2 or higher) and the
-corresponding GPU drivers.  The Nvidia Cuda SDK is not required, but
-we recommend it also be installed.  You can then make sure its sample
-projects can be compiled without problems.
-
-[Building LAMMPS with the USER-CUDA package:]
-
-This requires two steps (a,b): build the USER-CUDA library, then build
-LAMMPS with the USER-CUDA package.
-
-You can do both these steps in one line, using the src/Make.py script,
-described in "Section 2.4"_Section_start.html#start_4 of the manual.
-Type "Make.py -h" for help.  If run from the src directory, this
-command will create src/lmp_cuda using src/MAKE/Makefile.mpi as the
-starting Makefile.machine:
-
-Make.py -p cuda -cuda mode=single arch=20 -o cuda lib-cuda file mpi :pre
-
-Or you can follow these two (a,b) steps:
-
-(a) Build the USER-CUDA library
-
-The USER-CUDA library is in lammps/lib/cuda.  If your {CUDA} toolkit
-is not installed in the default system directoy {/usr/local/cuda} edit
-the file {lib/cuda/Makefile.common} accordingly.
-
-To build the library with the settings in lib/cuda/Makefile.default,
-simply type:
-
-make :pre
-
-To set options when the library is built, type "make OPTIONS", where
-{OPTIONS} are one or more of the following. The settings will be
-written to the {lib/cuda/Makefile.defaults} before the build.
-
-{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 = 35 for Kepler GPUs
-  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 them
-  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} for use of the CUDA FFT library
-  0 = no CUFFT support (default)
-  in the future other CUDA-enabled FFT libraries might be supported :pre
-
-If the build is successful, it will produce the files liblammpscuda.a and
-Makefile.lammps.
-
-Note that if you change any of the options (like precision), you need
-to re-build the entire library.  Do a "make clean" first, followed by
-"make".
-
-(b) Build LAMMPS with the USER-CUDA package
-
-cd lammps/src
-make yes-user-cuda
-make machine :pre
-
-No additional compile/link flags are needed in Makefile.machine.
-
-Note that if you change the USER-CUDA library precision (discussed
-above) and rebuild the USER-CUDA library, then you also need to
-re-install the USER-CUDA package and re-build LAMMPS, so that all
-affected files are re-compiled and linked to the new USER-CUDA
-library.
-
-[Run with the USER-CUDA package from the command line:]
-
-The mpirun or mpiexec command sets the total number of MPI tasks used
-by LAMMPS (one or multiple per compute node) and the number of MPI
-tasks used per node.  E.g. the mpirun command in MPICH does this via
-its -np and -ppn switches.  Ditto for OpenMPI via -np and -npernode.
-
-When using the USER-CUDA package, you must use exactly one MPI task
-per physical GPU.
-
-You must use the "-c on" "command-line
-switch"_Section_start.html#start_7 to enable the USER-CUDA package.
-The "-c on" switch also issues a default "package cuda 1"_package.html
-command which sets various USER-CUDA options to default values, as
-discussed on the "package"_package.html command doc page.
-
-Use the "-sf cuda" "command-line switch"_Section_start.html#start_7,
-which will automatically append "cuda" to styles that support it.  Use
-the "-pk cuda Ng" "command-line switch"_Section_start.html#start_7 to
-set Ng = # of GPUs per node to a different value than the default set
-by the "-c on" switch (1 GPU) or change other "package
-cuda"_package.html options.
-
-lmp_machine -c on -sf cuda -pk cuda 1 -in in.script                       # 1 MPI task uses 1 GPU
-mpirun -np 2 lmp_machine -c on -sf cuda -pk cuda 2 -in in.script          # 2 MPI tasks use 2 GPUs on a single 16-core (or whatever) node
-mpirun -np 24 -ppn 2 lmp_machine -c on -sf cuda -pk cuda 2 -in in.script  # ditto on 12 16-core nodes :pre
-
-The syntax for the "-pk" switch is the same as same as the "package
-cuda" command.  See the "package"_package.html command doc page for
-details, including the default values used for all its options if it
-is not specified.
-
-Note that the default for the "package cuda"_package.html command is
-to set the Newton flag to "off" for both pairwise and bonded
-interactions.  This typically gives fastest performance.  If the
-"newton"_newton.html command is used in the input script, it can
-override these defaults.
-
-[Or run with the USER-CUDA package by editing an input script:]
-
-The discussion above for the mpirun/mpiexec command and the requirement
-of one MPI task per GPU is the same.
-
-You must still use the "-c on" "command-line
-switch"_Section_start.html#start_7 to enable the USER-CUDA package.
-
-Use the "suffix cuda"_suffix.html command, or you can explicitly add a
-"cuda" suffix to individual styles in your input script, e.g.
-
-pair_style lj/cut/cuda 2.5 :pre
-
-You only need to use the "package cuda"_package.html command if you
-wish to change any of its option defaults, including the number of
-GPUs/node (default = 1), as set by the "-c on" "command-line
-switch"_Section_start.html#start_7.
-
-[Speed-ups to expect:]
-
-The performance of a GPU versus a multi-core CPU is a function of your
-hardware, which pair style is used, the number of atoms/GPU, and the
-precision used on the GPU (double, single, mixed).
-
-See the "Benchmark page"_http://lammps.sandia.gov/bench.html of the
-LAMMPS web site for performance of the USER-CUDA package on different
-hardware.
-
-[Guidelines for best performance:]
-
-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. :ulb,l
-
-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. :l,ule
-
-[Restrictions:]
-
-None.
--- a/doc/accelerate_gpu.html
+++ b/doc/accelerate_gpu.html
@ -1,257 +0,0 @@
-<HTML>
-<CENTER><A HREF = "Section_packages.html">Previous Section</A> - <A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> -
-<A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A> 
-</CENTER>
-
-
-
-
-
-
-<HR>
-
-<P><A HREF = "Section_accelerate.html">Return to Section accelerate overview</A>
-</P>
-<H4>5.3.2 GPU package 
-</H4>
-<P>The GPU package was developed by Mike Brown at ORNL and his
-collaborators, particularly Trung Nguyen (ORNL).  It provides GPU
-versions of many pair styles, including the 3-body Stillinger-Weber
-pair style, and for <A HREF = "kspace_style.html">kspace_style pppm</A> for
-long-range Coulombics.  It has the following general features:
-</P>
-<UL><LI>It is designed to exploit common GPU hardware configurations where one
-or more GPUs are coupled to many cores of one or more multi-core CPUs,
-e.g. within a node of a parallel machine. 
-
-<LI>Atom-based data (e.g. coordinates, forces) moves back-and-forth
-between the CPU(s) and GPU every timestep. 
-
-<LI>Neighbor lists can be built on the CPU or on the GPU 
-
-<LI>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. 
-
-<LI>Asynchronous force computations can be performed simultaneously on the
-CPU(s) and GPU. 
-
-<LI>It allows for GPU computations to be performed in single or double
-precision, or in mixed-mode precision, where pairwise forces are
-computed in single precision, but accumulated into double-precision
-force vectors. 
-
-<LI>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. 
-</UL>
-<P>Here is a quick overview of how to use the GPU package:
-</P>
-<UL><LI>build the library in lib/gpu for your GPU hardware wity desired precision
-<LI>include the GPU package and build LAMMPS
-<LI>use the mpirun command to set the number of MPI tasks/node which determines the number of MPI tasks/GPU
-<LI>specify the # of GPUs per node
-<LI>use GPU styles in your input script 
-</UL>
-<P>The latter two steps can be done using the "-pk gpu" and "-sf gpu"
-<A HREF = "Section_start.html#start_7">command-line switches</A> respectively.  Or
-the effect of the "-pk" or "-sf" switches can be duplicated by adding
-the <A HREF = "package.html">package gpu</A> or <A HREF = "suffix.html">suffix gpu</A> commands
-respectively to your input script.
-</P>
-<P><B>Required hardware/software:</B>
-</P>
-<P>To use this package, you currently need to have an NVIDIA GPU and
-install the NVIDIA Cuda software on your system:
-</P>
-<UL><LI>Check if you have an NVIDIA GPU: cat /proc/driver/nvidia/gpus/0/information
-<LI>Go to http://www.nvidia.com/object/cuda_get.html
-<LI>Install a driver and toolkit appropriate for your system (SDK is not necessary)
-<LI>Run lammps/lib/gpu/nvc_get_devices (after building the GPU library, see below) to list supported devices and properties 
-</UL>
-<P><B>Building LAMMPS with the GPU package:</B>
-</P>
-<P>This requires two steps (a,b): build the GPU library, then build
-LAMMPS with the GPU package.
-</P>
-<P>You can do both these steps in one line, using the src/Make.py script,
-described in <A HREF = "Section_start.html#start_4">Section 2.4</A> of the manual.
-Type "Make.py -h" for help.  If run from the src directory, this
-command will create src/lmp_gpu using src/MAKE/Makefile.mpi as the
-starting Makefile.machine:
-</P>
-<PRE>Make.py -p gpu -gpu mode=single arch=31 -o gpu lib-gpu file mpi 
-</PRE>
-<P>Or you can follow these two (a,b) steps:
-</P>
-<P>(a) Build the GPU library
-</P>
-<P>The GPU library is in lammps/lib/gpu.  Select a Makefile.machine (in
-lib/gpu) appropriate for your system.  You should pay special
-attention to 3 settings in this makefile.
-</P>
-<UL><LI>CUDA_HOME = needs to be where NVIDIA Cuda software is installed on your system
-<LI>CUDA_ARCH = needs to be appropriate to your GPUs
-<LI>CUDA_PREC = precision (double, mixed, single) you desire 
-</UL>
-<P>See lib/gpu/Makefile.linux.double for examples of the ARCH settings
-for different GPU choices, e.g. Fermi vs Kepler.  It also lists the
-possible precision settings:
-</P>
-<PRE>CUDA_PREC = -D_SINGLE_SINGLE  # single precision for all calculations
-CUDA_PREC = -D_DOUBLE_DOUBLE  # double precision for all calculations
-CUDA_PREC = -D_SINGLE_DOUBLE  # accumulation of forces, etc, in double 
-</PRE>
-<P>The last setting is the mixed mode referred to above.  Note that your
-GPU must support double precision to use either the 2nd or 3rd of
-these settings.
-</P>
-<P>To build the library, type:
-</P>
-<PRE>make -f Makefile.machine 
-</PRE>
-<P>If successful, it will produce the files libgpu.a and Makefile.lammps.
-</P>
-<P>The latter file has 3 settings that need to be appropriate for the
-paths and settings for the CUDA system software on your machine.
-Makefile.lammps is a copy of the file specified by the EXTRAMAKE
-setting in Makefile.machine.  You can change EXTRAMAKE or create your
-own Makefile.lammps.machine if needed.
-</P>
-<P>Note that to change the precision of the GPU library, you need to
-re-build the entire library.  Do a "clean" first, e.g. "make -f
-Makefile.linux clean", followed by the make command above.
-</P>
-<P>(b) Build LAMMPS with the GPU package
-</P>
-<PRE>cd lammps/src
-make yes-gpu
-make machine 
-</PRE>
-<P>No additional compile/link flags are needed in Makefile.machine.
-</P>
-<P>Note that if you change the GPU library precision (discussed above)
-and rebuild the GPU library, then you also need to re-install the GPU
-package and re-build LAMMPS, so that all affected files are
-re-compiled and linked to the new GPU library.
-</P>
-<P><B>Run with the GPU package from the command line:</B>
-</P>
-<P>The mpirun or mpiexec command sets the total number of MPI tasks used
-by LAMMPS (one or multiple per compute node) and the number of MPI
-tasks used per node.  E.g. the mpirun command in MPICH does this via
-its -np and -ppn switches.  Ditto for OpenMPI via -np and -npernode.
-</P>
-<P>When using the GPU package, you cannot assign more than one GPU to a
-single MPI task.  However multiple MPI tasks can share the same GPU,
-and in many cases it will be more efficient to run this way.  Likewise
-it may be more efficient to use less MPI tasks/node than the available
-# of CPU cores.  Assignment of multiple MPI tasks to a GPU will happen
-automatically if you create more MPI tasks/node than there are
-GPUs/mode.  E.g. with 8 MPI tasks/node and 2 GPUs, each GPU will be
-shared by 4 MPI tasks.
-</P>
-<P>Use the "-sf gpu" <A HREF = "Section_start.html#start_7">command-line switch</A>,
-which will automatically append "gpu" to styles that support it.  Use
-the "-pk gpu Ng" <A HREF = "Section_start.html#start_7">command-line switch</A> to
-set Ng = # of GPUs/node to use.
-</P>
-<PRE>lmp_machine -sf gpu -pk gpu 1 -in in.script                         # 1 MPI task uses 1 GPU
-mpirun -np 12 lmp_machine -sf gpu -pk gpu 2 -in in.script           # 12 MPI tasks share 2 GPUs on a single 16-core (or whatever) node
-mpirun -np 48 -ppn 12 lmp_machine -sf gpu -pk gpu 2 -in in.script   # ditto on 4 16-core nodes 
-</PRE>
-<P>Note that if the "-sf gpu" switch is used, it also issues a default
-<A HREF = "package.html">package gpu 1</A> command, which sets the number of
-GPUs/node to 1.
-</P>
-<P>Using the "-pk" switch explicitly allows for setting of the number of
-GPUs/node to use and additional options.  Its syntax is the same as
-same as the "package gpu" command.  See the <A HREF = "package.html">package</A>
-command doc page for details, including the default values used for
-all its options if it is not specified.
-</P>
-<P>Note that the default for the <A HREF = "package.html">package gpu</A> command is to
-set the Newton flag to "off" pairwise interactions.  It does not
-affect the setting for bonded interactions (LAMMPS default is "on").
-The "off" setting for pairwise interaction is currently required for
-GPU package pair styles.
-</P>
-<P><B>Or run with the GPU package by editing an input script:</B>
-</P>
-<P>The discussion above for the mpirun/mpiexec command, MPI tasks/node,
-and use of multiple MPI tasks/GPU is the same.
-</P>
-<P>Use the <A HREF = "suffix.html">suffix gpu</A> command, or you can explicitly add an
-"gpu" suffix to individual styles in your input script, e.g.
-</P>
-<PRE>pair_style lj/cut/gpu 2.5 
-</PRE>
-<P>You must also use the <A HREF = "package.html">package gpu</A> command to enable the
-GPU package, unless the "-sf gpu" or "-pk gpu" <A HREF = "Section_start.html#start_7">command-line
-switches</A> were used.  It specifies the
-number of GPUs/node to use, as well as other options.
-</P>
-<P><B>Speed-ups to expect:</B>
-</P>
-<P>The performance of a GPU versus a multi-core CPU is a function of your
-hardware, which pair style is used, the number of atoms/GPU, and the
-precision used on the GPU (double, single, mixed).
-</P>
-<P>See the <A HREF = "http://lammps.sandia.gov/bench.html">Benchmark page</A> of the
-LAMMPS web site for performance of the GPU package on various
-hardware, including the Titan HPC platform at ORNL.
-</P>
-<P>You should also experiment with how many MPI tasks per GPU to use to
-give the best performance for your problem and machine.  This is also
-a function of the problem size and the pair style being using.
-Likewise, you should experiment with the precision setting for the GPU
-library to see if single or mixed precision will give accurate
-results, since they will typically be faster.
-</P>
-<P><B>Guidelines for best performance:</B>
-</P>
-<UL><LI>Using multiple MPI tasks per GPU will often give the best performance,
-as allowed my most multi-core CPU/GPU configurations. 
-
-<LI>If the number of particles per MPI task is small (e.g. 100s of
-particles), it can be more efficient to run with fewer MPI tasks per
-GPU, even if you do not use all the cores on the compute node. 
-
-<LI>The <A HREF = "package.html">package gpu</A> command has several options for tuning
-performance.  Neighbor lists can be built on the GPU or CPU.  Force
-calculations can be dynamically balanced across the CPU cores and
-GPUs.  GPU-specific settings can be made which can be optimized
-for different hardware.  See the <A HREF = "package.html">packakge</A> command
-doc page for details. 
-
-<LI>As described by the <A HREF = "package.html">package gpu</A> 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 <A HREF = "bond_style.html">bond</A>,
-<A HREF = "angle_style.html">angle</A>, <A HREF = "dihedral_style.html">dihedral</A>,
-<A HREF = "improper_style.html">improper</A>, and <A HREF = "kspace_style.html">long-range</A>
-calculations will not be included in the "Pair" time. 
-
-<LI>When the <I>mode</I> 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. 
-
-<LI>The output section "GPU Time Info (average)" reports "Max Mem / Proc".
-This is the maximum memory used at one time on the GPU for data
-storage by a single MPI process. 
-</UL>
-<P><B>Restrictions:</B>
-</P>
-<P>None.
-</P>
-</HTML>
--- a/doc/accelerate_intel.html
+++ b/doc/accelerate_intel.html
@ -1,352 +0,0 @@
-<HTML>
-<CENTER><A HREF = "Section_packages.html">Previous Section</A> - <A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> -
-<A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A> 
-</CENTER>
-
-
-
-
-
-
-<HR>
-
-<P><A HREF = "Section_accelerate.html">Return to Section accelerate overview</A>
-</P>
-<H4>5.3.3 USER-INTEL package 
-</H4>
-<P>The USER-INTEL package was developed by Mike Brown at Intel
-Corporation.  It provides a capability to accelerate simulations by
-offloading neighbor list and non-bonded force calculations to Intel(R)
-Xeon Phi(TM) coprocessors (not native mode like the KOKKOS package).
-Additionally, it supports running simulations in single, mixed, or
-double precision with vectorization, even if a coprocessor is not
-present, i.e. on an Intel(R) CPU.  The same C++ code is used for both
-cases.  When offloading to a coprocessor, the routine is run twice,
-once with an offload flag.
-</P>
-<P>The USER-INTEL package can be used in tandem with the USER-OMP
-package.  This is useful when offloading pair style computations to
-coprocessors, so that other styles not supported by the USER-INTEL
-package, e.g. bond, angle, dihedral, improper, and long-range
-electrostatics, can run simultaneously in threaded mode on the CPU
-cores.  Since less MPI tasks than CPU cores will typically be invoked
-when running with coprocessors, this enables the extra CPU cores to be
-used for useful computation.
-</P>
-<P>If LAMMPS is built with both the USER-INTEL and USER-OMP packages
-intsalled, this mode of operation is made easier to use, because the
-"-suffix intel" <A HREF = "Section_start.html#start_7">command-line switch</A> or
-the <A HREF = "suffix.html">suffix intel</A> command will both set a second-choice
-suffix to "omp" so that styles from the USER-OMP package will be used
-if available, after first testing if a style from the USER-INTEL
-package is available.
-</P>
-<P>When using the USER-INTEL package, you must choose at build time
-whether you are building for CPU-only acceleration or for using the
-Xeon Phi in offload mode.
-</P>
-<P>Here is a quick overview of how to use the USER-INTEL package
-for CPU-only acceleration:
-</P>
-<UL><LI>specify these CCFLAGS in your src/MAKE/Makefile.machine: -openmp, -DLAMMPS_MEMALIGN=64, -restrict, -xHost
-<LI>specify -openmp with LINKFLAGS in your Makefile.machine
-<LI>include the USER-INTEL package and (optionally) USER-OMP package and build LAMMPS
-<LI>specify how many OpenMP threads per MPI task to use
-<LI>use USER-INTEL and (optionally) USER-OMP styles in your input script 
-</UL>
-<P>Note that many of these settings can only be used with the Intel
-compiler, as discussed below.
-</P>
-<P>Using the USER-INTEL package to offload work to the Intel(R)
-Xeon Phi(TM) coprocessor is the same except for these additional
-steps:
-</P>
-<UL><LI>add the flag -DLMP_INTEL_OFFLOAD to CCFLAGS in your Makefile.machine
-<LI>add the flag -offload to LINKFLAGS in your Makefile.machine 
-</UL>
-<P>The latter two steps in the first case and the last step in the
-coprocessor case can be done using the "-pk intel" and "-sf intel"
-<A HREF = "Section_start.html#start_7">command-line switches</A> respectively.  Or
-the effect of the "-pk" or "-sf" switches can be duplicated by adding
-the <A HREF = "package.html">package intel</A> or <A HREF = "suffix.html">suffix intel</A>
-commands respectively to your input script.
-</P>
-<P><B>Required hardware/software:</B>
-</P>
-<P>To use the offload option, you must have one or more Intel(R) Xeon
-Phi(TM) coprocessors and use an Intel(R) C++ compiler.
-</P>
-<P>Optimizations for vectorization have only been tested with the
-Intel(R) compiler.  Use of other compilers may not result in
-vectorization or give poor performance.
-</P>
-<P>Use of an Intel C++ compiler is recommended, but not required (though
-g++ will not recognize some of the settings, so they cannot be used).
-The compiler must support the OpenMP interface.
-</P>
-<P>The recommended version of the Intel(R) compiler is 14.0.1.106. 
-Versions 15.0.1.133 and later are also supported. If using Intel(R) 
-MPI, versions 15.0.2.044 and later are recommended.
-</P>
-<P><B>Building LAMMPS with the USER-INTEL package:</B>
-</P>
-<P>You can choose to build with or without support for offload to a
-Intel(R) Xeon Phi(TM) coprocessor. If you build with support for a
-coprocessor, the same binary can be used on nodes with and without
-coprocessors installed. However, if you do not have coprocessors
-on your system, building without offload support will produce a
-smaller binary.
-</P>
-<P>You can do either in one line, using the src/Make.py script, described
-in <A HREF = "Section_start.html#start_4">Section 2.4</A> of the manual.  Type
-"Make.py -h" for help.  If run from the src directory, these commands
-will create src/lmp_intel_cpu and lmp_intel_phi using
-src/MAKE/Makefile.mpi as the starting Makefile.machine:
-</P>
-<PRE>Make.py -p intel omp -intel cpu -o intel_cpu -cc icc file mpi 
-Make.py -p intel omp -intel phi -o intel_phi -cc icc file mpi 
-</PRE>
-<P>Note that this assumes that your MPI and its mpicxx wrapper
-is using the Intel compiler.  If it is not, you should
-leave off the "-cc icc" switch.
-</P>
-<P>Or you can follow these steps:
-</P>
-<PRE>cd lammps/src
-make yes-user-intel
-make yes-user-omp (if desired)
-make machine 
-</PRE>
-<P>Note that if the USER-OMP package is also installed, you can use
-styles from both packages, as described below.
-</P>
-<P>The Makefile.machine needs a "-fopenmp" flag for OpenMP support in
-both the CCFLAGS and LINKFLAGS variables.  You also need to add
-DLAMMPS_MEMALIGN=64 and -restrict to CCFLAGS.
-</P>
-<P>If you are compiling on the same architecture that will be used for
-the runs, adding the flag <I>-xHost</I> to CCFLAGS will enable
-vectorization with the Intel(R) compiler. Otherwise, you must
-provide the correct compute node architecture to the -x option
-(e.g. -xAVX).
-</P>
-<P>In order to build with support for an Intel(R) Xeon Phi(TM)
-coprocessor, the flag <I>-offload</I> should be added to the LINKFLAGS line
-and the flag -DLMP_INTEL_OFFLOAD should be added to the CCFLAGS line.
-</P>
-<P>Example makefiles Makefile.intel_cpu and Makefile.intel_phi are
-included in the src/MAKE/OPTIONS directory with settings that perform
-well with the Intel(R) compiler. The latter file has support for
-offload to coprocessors; the former does not.
-</P>
-<P><B>Notes on CPU and core affinity:</B>
-</P>
-<P>Setting core affinity is often used to pin MPI tasks and OpenMP
-threads to a core or group of cores so that memory access can be
-uniform. Unless disabled at build time, affinity for MPI tasks and 
-OpenMP threads on the host will be set by default on the host 
-when using offload to a coprocessor. In this case, it is unnecessary 
-to use other methods to control affinity (e.g. taskset, numactl,
-I_MPI_PIN_DOMAIN, etc.). This can be disabled in an input script
-with the <I>no_affinity</I> option to the <A HREF = "package.html">package intel</A> 
-command or by disabling the option at build time (by adding
-DINTEL_OFFLOAD_NOAFFINITY to the CCFLAGS line of your Makefile).
-Disabling this option is not recommended, especially when running
-on a machine with hyperthreading disabled.
-</P>
-<P><B>Running with the USER-INTEL package from the command line:</B>
-</P>
-<P>The mpirun or mpiexec command sets the total number of MPI tasks used
-by LAMMPS (one or multiple per compute node) and the number of MPI
-tasks used per node.  E.g. the mpirun command in MPICH does this via
-its -np and -ppn switches.  Ditto for OpenMPI via -np and -npernode.
-</P>
-<P>If you plan to compute (any portion of) pairwise interactions using
-USER-INTEL pair styles on the CPU, or use USER-OMP styles on the CPU,
-you need to choose how many OpenMP threads per MPI task to use.  Note
-that the product of MPI tasks * OpenMP threads/task should not exceed
-the physical number of cores (on a node), otherwise performance will
-suffer.
-</P>
-<P>If LAMMPS was built with coprocessor support for the USER-INTEL
-package, you also need to specify the number of coprocessor/node and
-the number of coprocessor threads per MPI task to use.  Note that
-coprocessor threads (which run on the coprocessor) are totally
-independent from OpenMP threads (which run on the CPU).  The default
-values for the settings that affect coprocessor threads are typically
-fine, as discussed below.
-</P>
-<P>Use the "-sf intel" <A HREF = "Section_start.html#start_7">command-line switch</A>,
-which will automatically append "intel" to styles that support it.  If
-a style does not support it, an "omp" suffix is tried next.  OpenMP
-threads per MPI task can be set via the "-pk intel Nphi omp Nt" or
-"-pk omp Nt" <A HREF = "Section_start.html#start_7">command-line switches</A>, which
-set Nt = # of OpenMP threads per MPI task to use.  The "-pk omp" form
-is only allowed if LAMMPS was also built with the USER-OMP package.
-</P>
-<P>Use the "-pk intel Nphi" <A HREF = "Section_start.html#start_7">command-line
-switch</A> to set Nphi = # of Xeon Phi(TM)
-coprocessors/node, if LAMMPS was built with coprocessor support.  All
-the available coprocessor threads on each Phi will be divided among
-MPI tasks, unless the <I>tptask</I> option of the "-pk intel" <A HREF = "Section_start.html#start_7">command-line
-switch</A> is used to limit the coprocessor
-threads per MPI task.  See the <A HREF = "package.html">package intel</A> command
-for details.
-</P>
-<PRE>CPU-only without USER-OMP (but using Intel vectorization on CPU):
-lmp_machine -sf intel -in in.script                 # 1 MPI task
-mpirun -np 32 lmp_machine -sf intel -in in.script   # 32 MPI tasks on as many nodes as needed (e.g. 2 16-core nodes) 
-</PRE>
-<PRE>CPU-only with USER-OMP (and Intel vectorization on CPU):
-lmp_machine -sf intel -pk intel 16 0 -in in.script             # 1 MPI task on a 16-core node
-mpirun -np 4 lmp_machine -sf intel -pk omp 4 -in in.script     # 4 MPI tasks each with 4 threads on a single 16-core node
-mpirun -np 32 lmp_machine -sf intel -pk omp 4 -in in.script    # ditto on 8 16-core nodes 
-</PRE>
-<PRE>CPUs + Xeon Phi(TM) coprocessors with or without USER-OMP:
-lmp_machine -sf intel -pk intel 1 omp 16 -in in.script                       # 1 MPI task, 16 OpenMP threads on CPU, 1 coprocessor, all 240 coprocessor threads
-lmp_machine -sf intel -pk intel 1 omp 16 tptask 32 -in in.script             # 1 MPI task, 16 OpenMP threads on CPU, 1 coprocessor, only 32 coprocessor threads
-mpirun -np 4 lmp_machine -sf intel -pk intel 1 omp 4 -in in.script           # 4 MPI tasks, 4 OpenMP threads/task, 1 coprocessor, 60 coprocessor threads/task
-mpirun -np 32 -ppn 4 lmp_machine -sf intel -pk intel 1 omp 4 -in in.script   # ditto on 8 16-core nodes
-mpirun -np 8 lmp_machine -sf intel -pk intel 4 omp 2 -in in.script           # 8 MPI tasks, 2 OpenMP threads/task, 4 coprocessors, 120 coprocessor threads/task 
-</PRE>
-<P>Note that if the "-sf intel" switch is used, it also invokes two
-default commands: <A HREF = "package.html">package intel 1</A>, followed by <A HREF = "package.html">package
-omp 0</A>.  These both set the number of OpenMP threads per
-MPI task via the OMP_NUM_THREADS environment variable.  The first
-command sets the number of Xeon Phi(TM) coprocessors/node to 1 (and
-the precision mode to "mixed", as one of its option defaults).  The
-latter command is not invoked if LAMMPS was not built with the
-USER-OMP package.  The Nphi = 1 value for the first command is ignored
-if LAMMPS was not built with coprocessor support.
-</P>
-<P>Using the "-pk intel" or "-pk omp" switches explicitly allows for
-direct setting of the number of OpenMP threads per MPI task, and
-additional options for either of the USER-INTEL or USER-OMP packages.
-In particular, the "-pk intel" switch sets the number of
-coprocessors/node and can limit the number of coprocessor threads per
-MPI task.  The syntax for these two switches is the same as the
-<A HREF = "package.html">package omp</A> and <A HREF = "package.html">package intel</A> commands.
-See the <A HREF = "package.html">package</A> command doc page for details, including
-the default values used for all its options if these switches are not
-specified, and how to set the number of OpenMP threads via the
-OMP_NUM_THREADS environment variable if desired.
-</P>
-<P><B>Or run with the USER-INTEL package by editing an input script:</B>
-</P>
-<P>The discussion above for the mpirun/mpiexec command, MPI tasks/node,
-OpenMP threads per MPI task, and coprocessor threads per MPI task is
-the same.
-</P>
-<P>Use the <A HREF = "suffix.html">suffix intel</A> command, or you can explicitly add an
-"intel" suffix to individual styles in your input script, e.g.
-</P>
-<PRE>pair_style lj/cut/intel 2.5 
-</PRE>
-<P>You must also use the <A HREF = "package.html">package intel</A> command, unless the
-"-sf intel" or "-pk intel" <A HREF = "Section_start.html#start_7">command-line
-switches</A> were used.  It specifies how many
-coprocessors/node to use, as well as other OpenMP threading and
-coprocessor options.  Its doc page explains how to set the number of
-OpenMP threads via an environment variable if desired.
-</P>
-<P>If LAMMPS was also built with the USER-OMP package, you must also use
-the <A HREF = "package.html">package omp</A> command to enable that package, unless
-the "-sf intel" or "-pk omp" <A HREF = "Section_start.html#start_7">command-line
-switches</A> were used.  It specifies how many
-OpenMP threads per MPI task to use, as well as other options.  Its doc
-page explains how to set the number of OpenMP threads via an
-environment variable if desired.
-</P>
-<P><B>Speed-ups to expect:</B>
-</P>
-<P>If LAMMPS was not built with coprocessor support when including the
-USER-INTEL package, then acclerated styles will run on the CPU using
-vectorization optimizations and the specified precision.  This may
-give a substantial speed-up for a pair style, particularly if mixed or
-single precision is used.
-</P>
-<P>If LAMMPS was built with coproccesor support, the pair styles will run
-on one or more Intel(R) Xeon Phi(TM) coprocessors (per node).  The
-performance of a Xeon Phi versus a multi-core CPU is a function of
-your hardware, which pair style is used, the number of
-atoms/coprocessor, and the precision used on the coprocessor (double,
-single, mixed).
-</P>
-<P>See the <A HREF = "http://lammps.sandia.gov/bench.html">Benchmark page</A> of the
-LAMMPS web site for performance of the USER-INTEL package on different
-hardware.
-</P>
-<P><B>Guidelines for best performance on an Intel(R) Xeon Phi(TM)
-coprocessor:</B>
-</P>
-<UL><LI>The default for the <A HREF = "package.html">package intel</A> command is to have
-all the MPI tasks on a given compute node use a single Xeon Phi(TM)
-coprocessor.  In general, running with a large number of MPI tasks on
-each node will perform best with offload.  Each MPI task will
-automatically get affinity to a subset of the hardware threads
-available on the coprocessor.  For example, if your card has 61 cores,
-with 60 cores available for offload and 4 hardware threads per core
-(240 total threads), running with 24 MPI tasks per node will cause
-each MPI task to use a subset of 10 threads on the coprocessor.  Fine
-tuning of the number of threads to use per MPI task or the number of
-threads to use per core can be accomplished with keyword settings of
-the <A HREF = "package.html">package intel</A> command. 
-
-<LI>If desired, only a fraction of the pair style computation can be
-offloaded to the coprocessors.  This is accomplished by using the
-<I>balance</I> keyword in the <A HREF = "package.html">package intel</A> command.  A
-balance of 0 runs all calculations on the CPU.  A balance of 1 runs
-all calculations on the coprocessor.  A balance of 0.5 runs half of
-the calculations on the coprocessor.  Setting the balance to -1 (the
-default) will enable dynamic load balancing that continously adjusts
-the fraction of offloaded work throughout the simulation.  This option
-typically produces results within 5 to 10 percent of the optimal fixed
-balance. 
-
-<LI>When using offload with CPU hyperthreading disabled, it may help
-performance to use fewer MPI tasks and OpenMP threads than available
-cores.  This is due to the fact that additional threads are generated
-internally to handle the asynchronous offload tasks. 
-
-<LI>If running short benchmark runs with dynamic load balancing, adding a
-short warm-up run (10-20 steps) will allow the load-balancer to find a
-near-optimal setting that will carry over to additional runs. 
-
-<LI>If pair computations are being offloaded to an Intel(R) Xeon Phi(TM)
-coprocessor, a diagnostic line is printed to the screen (not to the
-log file), during the setup phase of a run, indicating that offload
-mode is being used and indicating the number of coprocessor threads
-per MPI task.  Additionally, an offload timing summary is printed at
-the end of each run.  When offloading, the frequency for <A HREF = "atom_modify.html">atom
-sorting</A> is changed to 1 so that the per-atom data is
-effectively sorted at every rebuild of the neighbor lists. 
-
-<LI>For simulations with long-range electrostatics or bond, angle,
-dihedral, improper calculations, computation and data transfer to the
-coprocessor will run concurrently with computations and MPI
-communications for these calculations on the host CPU.  The USER-INTEL
-package has two modes for deciding which atoms will be handled by the
-coprocessor.  This choice is controlled with the <I>ghost</I> keyword of
-the <A HREF = "package.html">package intel</A> command.  When set to 0, ghost atoms
-(atoms at the borders between MPI tasks) are not offloaded to the
-card.  This allows for overlap of MPI communication of forces with
-computation on the coprocessor when the <A HREF = "newton.html">newton</A> setting
-is "on".  The default is dependent on the style being used, however,
-better performance may be achieved by setting this option
-explictly. 
-</UL>
-<P><B>Restrictions:</B>
-</P>
-<P>When offloading to a coprocessor, <A HREF = "pair_hybrid.html">hybrid</A> styles
-that require skip lists for neighbor builds cannot be offloaded.
-Using <A HREF = "pair_hybrid.html">hybrid/overlay</A> is allowed.  Only one intel
-accelerated style may be used with hybrid styles.
-<A HREF = "special_bonds.html">Special_bonds</A> exclusion lists are not currently
-supported with offload, however, the same effect can often be
-accomplished by setting cutoffs for excluded atom types to 0.  None of
-the pair styles in the USER-INTEL package currently support the
-"inner", "middle", "outer" options for rRESPA integration via the
-<A HREF = "run_style.html">run_style respa</A> command; only the "pair" option is
-supported.
-</P>
-</HTML>
--- a/doc/accelerate_intel.txt
+++ b/doc/accelerate_intel.txt
@ -1,347 +0,0 @@
-"Previous Section"_Section_packages.html - "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
-
-"Return to Section accelerate overview"_Section_accelerate.html
-
-5.3.3 USER-INTEL package :h4
-
-The USER-INTEL package was developed by Mike Brown at Intel
-Corporation.  It provides a capability to accelerate simulations by
-offloading neighbor list and non-bonded force calculations to Intel(R)
-Xeon Phi(TM) coprocessors (not native mode like the KOKKOS package).
-Additionally, it supports running simulations in single, mixed, or
-double precision with vectorization, even if a coprocessor is not
-present, i.e. on an Intel(R) CPU.  The same C++ code is used for both
-cases.  When offloading to a coprocessor, the routine is run twice,
-once with an offload flag.
-
-The USER-INTEL package can be used in tandem with the USER-OMP
-package.  This is useful when offloading pair style computations to
-coprocessors, so that other styles not supported by the USER-INTEL
-package, e.g. bond, angle, dihedral, improper, and long-range
-electrostatics, can run simultaneously in threaded mode on the CPU
-cores.  Since less MPI tasks than CPU cores will typically be invoked
-when running with coprocessors, this enables the extra CPU cores to be
-used for useful computation.
-
-If LAMMPS is built with both the USER-INTEL and USER-OMP packages
-intsalled, this mode of operation is made easier to use, because the
-"-suffix intel" "command-line switch"_Section_start.html#start_7 or
-the "suffix intel"_suffix.html command will both set a second-choice
-suffix to "omp" so that styles from the USER-OMP package will be used
-if available, after first testing if a style from the USER-INTEL
-package is available.
-
-When using the USER-INTEL package, you must choose at build time
-whether you are building for CPU-only acceleration or for using the
-Xeon Phi in offload mode.
-
-Here is a quick overview of how to use the USER-INTEL package
-for CPU-only acceleration:
-
-specify these CCFLAGS in your src/MAKE/Makefile.machine: -openmp, -DLAMMPS_MEMALIGN=64, -restrict, -xHost
-specify -openmp with LINKFLAGS in your Makefile.machine
-include the USER-INTEL package and (optionally) USER-OMP package and build LAMMPS
-specify how many OpenMP threads per MPI task to use
-use USER-INTEL and (optionally) USER-OMP styles in your input script :ul
-
-Note that many of these settings can only be used with the Intel
-compiler, as discussed below.
-
-Using the USER-INTEL package to offload work to the Intel(R)
-Xeon Phi(TM) coprocessor is the same except for these additional
-steps:
-
-add the flag -DLMP_INTEL_OFFLOAD to CCFLAGS in your Makefile.machine
-add the flag -offload to LINKFLAGS in your Makefile.machine :ul
-
-The latter two steps in the first case and the last step in the
-coprocessor case can be done using the "-pk intel" and "-sf intel"
-"command-line switches"_Section_start.html#start_7 respectively.  Or
-the effect of the "-pk" or "-sf" switches can be duplicated by adding
-the "package intel"_package.html or "suffix intel"_suffix.html
-commands respectively to your input script.
-
-[Required hardware/software:]
-
-To use the offload option, you must have one or more Intel(R) Xeon
-Phi(TM) coprocessors and use an Intel(R) C++ compiler.
-
-Optimizations for vectorization have only been tested with the
-Intel(R) compiler.  Use of other compilers may not result in
-vectorization or give poor performance.
-
-Use of an Intel C++ compiler is recommended, but not required (though
-g++ will not recognize some of the settings, so they cannot be used).
-The compiler must support the OpenMP interface.
-
-The recommended version of the Intel(R) compiler is 14.0.1.106. 
-Versions 15.0.1.133 and later are also supported. If using Intel(R) 
-MPI, versions 15.0.2.044 and later are recommended.
-
-[Building LAMMPS with the USER-INTEL package:]
-
-You can choose to build with or without support for offload to a
-Intel(R) Xeon Phi(TM) coprocessor. If you build with support for a
-coprocessor, the same binary can be used on nodes with and without
-coprocessors installed. However, if you do not have coprocessors
-on your system, building without offload support will produce a
-smaller binary.
-
-You can do either in one line, using the src/Make.py script, described
-in "Section 2.4"_Section_start.html#start_4 of the manual.  Type
-"Make.py -h" for help.  If run from the src directory, these commands
-will create src/lmp_intel_cpu and lmp_intel_phi using
-src/MAKE/Makefile.mpi as the starting Makefile.machine:
-
-Make.py -p intel omp -intel cpu -o intel_cpu -cc icc file mpi 
-Make.py -p intel omp -intel phi -o intel_phi -cc icc file mpi :pre
-
-Note that this assumes that your MPI and its mpicxx wrapper
-is using the Intel compiler.  If it is not, you should
-leave off the "-cc icc" switch.
-
-Or you can follow these steps:
-
-cd lammps/src
-make yes-user-intel
-make yes-user-omp (if desired)
-make machine :pre
-
-Note that if the USER-OMP package is also installed, you can use
-styles from both packages, as described below.
-
-The Makefile.machine needs a "-fopenmp" flag for OpenMP support in
-both the CCFLAGS and LINKFLAGS variables.  You also need to add
-DLAMMPS_MEMALIGN=64 and -restrict to CCFLAGS.
-
-If you are compiling on the same architecture that will be used for
-the runs, adding the flag {-xHost} to CCFLAGS will enable
-vectorization with the Intel(R) compiler. Otherwise, you must
-provide the correct compute node architecture to the -x option
-(e.g. -xAVX).
-
-In order to build with support for an Intel(R) Xeon Phi(TM)
-coprocessor, the flag {-offload} should be added to the LINKFLAGS line
-and the flag -DLMP_INTEL_OFFLOAD should be added to the CCFLAGS line.
-
-Example makefiles Makefile.intel_cpu and Makefile.intel_phi are
-included in the src/MAKE/OPTIONS directory with settings that perform
-well with the Intel(R) compiler. The latter file has support for
-offload to coprocessors; the former does not.
-
-[Notes on CPU and core affinity:]
-
-Setting core affinity is often used to pin MPI tasks and OpenMP
-threads to a core or group of cores so that memory access can be
-uniform. Unless disabled at build time, affinity for MPI tasks and 
-OpenMP threads on the host will be set by default on the host 
-when using offload to a coprocessor. In this case, it is unnecessary 
-to use other methods to control affinity (e.g. taskset, numactl,
-I_MPI_PIN_DOMAIN, etc.). This can be disabled in an input script
-with the {no_affinity} option to the "package intel"_package.html 
-command or by disabling the option at build time (by adding
-DINTEL_OFFLOAD_NOAFFINITY to the CCFLAGS line of your Makefile).
-Disabling this option is not recommended, especially when running
-on a machine with hyperthreading disabled.
-
-[Running with the USER-INTEL package from the command line:]
-
-The mpirun or mpiexec command sets the total number of MPI tasks used
-by LAMMPS (one or multiple per compute node) and the number of MPI
-tasks used per node.  E.g. the mpirun command in MPICH does this via
-its -np and -ppn switches.  Ditto for OpenMPI via -np and -npernode.
-
-If you plan to compute (any portion of) pairwise interactions using
-USER-INTEL pair styles on the CPU, or use USER-OMP styles on the CPU,
-you need to choose how many OpenMP threads per MPI task to use.  Note
-that the product of MPI tasks * OpenMP threads/task should not exceed
-the physical number of cores (on a node), otherwise performance will
-suffer.
-
-If LAMMPS was built with coprocessor support for the USER-INTEL
-package, you also need to specify the number of coprocessor/node and
-the number of coprocessor threads per MPI task to use.  Note that
-coprocessor threads (which run on the coprocessor) are totally
-independent from OpenMP threads (which run on the CPU).  The default
-values for the settings that affect coprocessor threads are typically
-fine, as discussed below.
-
-Use the "-sf intel" "command-line switch"_Section_start.html#start_7,
-which will automatically append "intel" to styles that support it.  If
-a style does not support it, an "omp" suffix is tried next.  OpenMP
-threads per MPI task can be set via the "-pk intel Nphi omp Nt" or
-"-pk omp Nt" "command-line switches"_Section_start.html#start_7, which
-set Nt = # of OpenMP threads per MPI task to use.  The "-pk omp" form
-is only allowed if LAMMPS was also built with the USER-OMP package.
-
-Use the "-pk intel Nphi" "command-line
-switch"_Section_start.html#start_7 to set Nphi = # of Xeon Phi(TM)
-coprocessors/node, if LAMMPS was built with coprocessor support.  All
-the available coprocessor threads on each Phi will be divided among
-MPI tasks, unless the {tptask} option of the "-pk intel" "command-line
-switch"_Section_start.html#start_7 is used to limit the coprocessor
-threads per MPI task.  See the "package intel"_package.html command
-for details.
-
-CPU-only without USER-OMP (but using Intel vectorization on CPU):
-lmp_machine -sf intel -in in.script                 # 1 MPI task
-mpirun -np 32 lmp_machine -sf intel -in in.script   # 32 MPI tasks on as many nodes as needed (e.g. 2 16-core nodes) :pre
-
-CPU-only with USER-OMP (and Intel vectorization on CPU):
-lmp_machine -sf intel -pk intel 16 0 -in in.script             # 1 MPI task on a 16-core node
-mpirun -np 4 lmp_machine -sf intel -pk omp 4 -in in.script     # 4 MPI tasks each with 4 threads on a single 16-core node
-mpirun -np 32 lmp_machine -sf intel -pk omp 4 -in in.script    # ditto on 8 16-core nodes :pre
-
-CPUs + Xeon Phi(TM) coprocessors with or without USER-OMP:
-lmp_machine -sf intel -pk intel 1 omp 16 -in in.script                       # 1 MPI task, 16 OpenMP threads on CPU, 1 coprocessor, all 240 coprocessor threads
-lmp_machine -sf intel -pk intel 1 omp 16 tptask 32 -in in.script             # 1 MPI task, 16 OpenMP threads on CPU, 1 coprocessor, only 32 coprocessor threads
-mpirun -np 4 lmp_machine -sf intel -pk intel 1 omp 4 -in in.script           # 4 MPI tasks, 4 OpenMP threads/task, 1 coprocessor, 60 coprocessor threads/task
-mpirun -np 32 -ppn 4 lmp_machine -sf intel -pk intel 1 omp 4 -in in.script   # ditto on 8 16-core nodes
-mpirun -np 8 lmp_machine -sf intel -pk intel 4 omp 2 -in in.script           # 8 MPI tasks, 2 OpenMP threads/task, 4 coprocessors, 120 coprocessor threads/task :pre 
-
-Note that if the "-sf intel" switch is used, it also invokes two
-default commands: "package intel 1"_package.html, followed by "package
-omp 0"_package.html.  These both set the number of OpenMP threads per
-MPI task via the OMP_NUM_THREADS environment variable.  The first
-command sets the number of Xeon Phi(TM) coprocessors/node to 1 (and
-the precision mode to "mixed", as one of its option defaults).  The
-latter command is not invoked if LAMMPS was not built with the
-USER-OMP package.  The Nphi = 1 value for the first command is ignored
-if LAMMPS was not built with coprocessor support.
-
-Using the "-pk intel" or "-pk omp" switches explicitly allows for
-direct setting of the number of OpenMP threads per MPI task, and
-additional options for either of the USER-INTEL or USER-OMP packages.
-In particular, the "-pk intel" switch sets the number of
-coprocessors/node and can limit the number of coprocessor threads per
-MPI task.  The syntax for these two switches is the same as the
-"package omp"_package.html and "package intel"_package.html commands.
-See the "package"_package.html command doc page for details, including
-the default values used for all its options if these switches are not
-specified, and how to set the number of OpenMP threads via the
-OMP_NUM_THREADS environment variable if desired.
-
-[Or run with the USER-INTEL package by editing an input script:]
-
-The discussion above for the mpirun/mpiexec command, MPI tasks/node,
-OpenMP threads per MPI task, and coprocessor threads per MPI task is
-the same.
-
-Use the "suffix intel"_suffix.html command, or you can explicitly add an
-"intel" suffix to individual styles in your input script, e.g.
-
-pair_style lj/cut/intel 2.5 :pre
-
-You must also use the "package intel"_package.html command, unless the
-"-sf intel" or "-pk intel" "command-line
-switches"_Section_start.html#start_7 were used.  It specifies how many
-coprocessors/node to use, as well as other OpenMP threading and
-coprocessor options.  Its doc page explains how to set the number of
-OpenMP threads via an environment variable if desired.
-
-If LAMMPS was also built with the USER-OMP package, you must also use
-the "package omp"_package.html command to enable that package, unless
-the "-sf intel" or "-pk omp" "command-line
-switches"_Section_start.html#start_7 were used.  It specifies how many
-OpenMP threads per MPI task to use, as well as other options.  Its doc
-page explains how to set the number of OpenMP threads via an
-environment variable if desired.
-
-[Speed-ups to expect:]
-
-If LAMMPS was not built with coprocessor support when including the
-USER-INTEL package, then acclerated styles will run on the CPU using
-vectorization optimizations and the specified precision.  This may
-give a substantial speed-up for a pair style, particularly if mixed or
-single precision is used.
-
-If LAMMPS was built with coproccesor support, the pair styles will run
-on one or more Intel(R) Xeon Phi(TM) coprocessors (per node).  The
-performance of a Xeon Phi versus a multi-core CPU is a function of
-your hardware, which pair style is used, the number of
-atoms/coprocessor, and the precision used on the coprocessor (double,
-single, mixed).
-
-See the "Benchmark page"_http://lammps.sandia.gov/bench.html of the
-LAMMPS web site for performance of the USER-INTEL package on different
-hardware.
-
-[Guidelines for best performance on an Intel(R) Xeon Phi(TM)
-coprocessor:]
-
-The default for the "package intel"_package.html command is to have
-all the MPI tasks on a given compute node use a single Xeon Phi(TM)
-coprocessor.  In general, running with a large number of MPI tasks on
-each node will perform best with offload.  Each MPI task will
-automatically get affinity to a subset of the hardware threads
-available on the coprocessor.  For example, if your card has 61 cores,
-with 60 cores available for offload and 4 hardware threads per core
-(240 total threads), running with 24 MPI tasks per node will cause
-each MPI task to use a subset of 10 threads on the coprocessor.  Fine
-tuning of the number of threads to use per MPI task or the number of
-threads to use per core can be accomplished with keyword settings of
-the "package intel"_package.html command. :ulb,l
-
-If desired, only a fraction of the pair style computation can be
-offloaded to the coprocessors.  This is accomplished by using the
-{balance} keyword in the "package intel"_package.html command.  A
-balance of 0 runs all calculations on the CPU.  A balance of 1 runs
-all calculations on the coprocessor.  A balance of 0.5 runs half of
-the calculations on the coprocessor.  Setting the balance to -1 (the
-default) will enable dynamic load balancing that continously adjusts
-the fraction of offloaded work throughout the simulation.  This option
-typically produces results within 5 to 10 percent of the optimal fixed
-balance. :l
-
-When using offload with CPU hyperthreading disabled, it may help
-performance to use fewer MPI tasks and OpenMP threads than available
-cores.  This is due to the fact that additional threads are generated
-internally to handle the asynchronous offload tasks. :l
-
-If running short benchmark runs with dynamic load balancing, adding a
-short warm-up run (10-20 steps) will allow the load-balancer to find a
-near-optimal setting that will carry over to additional runs. :l
-
-If pair computations are being offloaded to an Intel(R) Xeon Phi(TM)
-coprocessor, a diagnostic line is printed to the screen (not to the
-log file), during the setup phase of a run, indicating that offload
-mode is being used and indicating the number of coprocessor threads
-per MPI task.  Additionally, an offload timing summary is printed at
-the end of each run.  When offloading, the frequency for "atom
-sorting"_atom_modify.html is changed to 1 so that the per-atom data is
-effectively sorted at every rebuild of the neighbor lists. :l
-
-For simulations with long-range electrostatics or bond, angle,
-dihedral, improper calculations, computation and data transfer to the
-coprocessor will run concurrently with computations and MPI
-communications for these calculations on the host CPU.  The USER-INTEL
-package has two modes for deciding which atoms will be handled by the
-coprocessor.  This choice is controlled with the {ghost} keyword of
-the "package intel"_package.html command.  When set to 0, ghost atoms
-(atoms at the borders between MPI tasks) are not offloaded to the
-card.  This allows for overlap of MPI communication of forces with
-computation on the coprocessor when the "newton"_newton.html setting
-is "on".  The default is dependent on the style being used, however,
-better performance may be achieved by setting this option
-explictly. :l,ule
-
-[Restrictions:]
-
-When offloading to a coprocessor, "hybrid"_pair_hybrid.html styles
-that require skip lists for neighbor builds cannot be offloaded.
-Using "hybrid/overlay"_pair_hybrid.html is allowed.  Only one intel
-accelerated style may be used with hybrid styles.
-"Special_bonds"_special_bonds.html exclusion lists are not currently
-supported with offload, however, the same effect can often be
-accomplished by setting cutoffs for excluded atom types to 0.  None of
-the pair styles in the USER-INTEL package currently support the
-"inner", "middle", "outer" options for rRESPA integration via the
-"run_style respa"_run_style.html command; only the "pair" option is
-supported.
--- a/doc/accelerate_kokkos.html
+++ b/doc/accelerate_kokkos.html
@ -1,514 +0,0 @@
-<HTML>
-<CENTER><A HREF = "Section_packages.html">Previous Section</A> - <A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> -
-<A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A> 
-</CENTER>
-
-
-
-
-
-
-<HR>
-
-<P><A HREF = "Section_accelerate.html">Return to Section accelerate overview</A>
-</P>
-<H4>5.3.4 KOKKOS package 
-</H4>
-<P>The KOKKOS package was developed primaritly by Christian Trott
-(Sandia) with contributions of various styles by others, including
-Sikandar Mashayak (UIUC).  The underlying Kokkos library was written
-primarily by Carter Edwards, Christian Trott, and Dan Sunderland (all
-Sandia).
-</P>
-<P>The KOKKOS package contains versions of pair, fix, and atom styles
-that use data structures and macros provided by the Kokkos library,
-which is included with LAMMPS in lib/kokkos.
-</P>
-<P>The Kokkos library is part of
-<A HREF = "http://trilinos.sandia.gov/packages/kokkos">Trilinos</A> and is a
-templated C++ library that provides two key abstractions for an
-application like LAMMPS.  First, it allows a single implementation of
-an application kernel (e.g. a pair style) to run efficiently on
-different kinds of hardware, such as a GPU, Intel Phi, or many-core
-chip.
-</P>
-<P>The Kokkos library also provides data abstractions to adjust (at
-compile time) the memory layout of basic data structures like 2d and
-3d arrays and allow the transparent utilization of special hardware
-load and store operations.  Such data structures are used in LAMMPS to
-store atom coordinates or forces or neighbor lists.  The layout is
-chosen to optimize performance on different platforms.  Again this
-functionality is hidden from the developer, and does not affect how
-the kernel is coded.
-</P>
-<P>These abstractions are set at build time, when LAMMPS is compiled with
-the KOKKOS package installed.  This is done by selecting a "host" and
-"device" to build for, compatible with the compute nodes in your
-machine (one on a desktop machine or 1000s on a supercomputer).
-</P>
-<P>All Kokkos operations occur within the context of an individual MPI
-task running on a single node of the machine.  The total number of MPI
-tasks used by LAMMPS (one or multiple per compute node) is set in the
-usual manner via the mpirun or mpiexec commands, and is independent of
-Kokkos.
-</P>
-<P>Kokkos provides support for two different modes of execution per MPI
-task.  This means that computational tasks (pairwise interactions,
-neighbor list builds, time integration, etc) can be parallelized for
-one or the other of the two modes.  The first mode is called the
-"host" and is one or more threads running on one or more physical CPUs
-(within the node).  Currently, both multi-core CPUs and an Intel Phi
-processor (running in native mode, not offload mode like the
-USER-INTEL package) are supported.  The second mode is called the
-"device" and is an accelerator chip of some kind.  Currently only an
-NVIDIA GPU is supported via Cuda.  If your compute node does not have
-a GPU, then there is only one mode of execution, i.e. the host and
-device are the same.
-</P>
-<P>When using the KOKKOS package, you must choose at build time whether
-you are building for OpenMP, GPU, or for using the Xeon Phi in native
-mode.
-</P>
-<P>Here is a quick overview of how to use the KOKKOS package:
-</P>
-<UL><LI>specify variables and settings in your Makefile.machine that enable OpenMP, GPU, or Phi support
-<LI>include the KOKKOS package and build LAMMPS
-<LI>enable the KOKKOS package and its hardware options via the "-k on" command-line switch
-<LI>use KOKKOS styles in your input script 
-</UL>
-<P>The latter two steps can be done using the "-k on", "-pk kokkos" and
-"-sf kk" <A HREF = "Section_start.html#start_7">command-line switches</A>
-respectively.  Or the effect of the "-pk" or "-sf" switches can be
-duplicated by adding the <A HREF = "package.html">package kokkos</A> or <A HREF = "suffix.html">suffix
-kk</A> commands respectively to your input script.
-</P>
-<P><B>Required hardware/software:</B>
-</P>
-<P>The KOKKOS package can be used to build and run LAMMPS on the
-following kinds of hardware:
-</P>
-<UL><LI>CPU-only: one MPI task per CPU core (MPI-only, but using KOKKOS styles)
-<LI>CPU-only: one or a few MPI tasks per node with additional threading via OpenMP
-<LI>Phi: on one or more Intel Phi coprocessors (per node)
-<LI>GPU: on the GPUs of a node with additional OpenMP threading on the CPUs 
-</UL>
-<P>Note that Intel Xeon Phi coprocessors are supported in "native" mode,
-not "offload" mode like the USER-INTEL package supports.
-</P>
-<P>Only NVIDIA GPUs are currently supported.
-</P>
-<P>IMPORTANT NOTE: For good performance of the KOKKOS package on GPUs,
-you must have Kepler generation GPUs (or later).  The Kokkos library
-exploits texture cache options not supported by Telsa generation GPUs
-(or older).
-</P>
-<P>To build the KOKKOS package for GPUs, NVIDIA Cuda software must be
-installed on your system.  See the discussion above for the USER-CUDA
-and GPU packages for details of how to check and do this.
-</P>
-<P><B>Building LAMMPS with the KOKKOS package:</B>
-</P>
-<P>You must choose at build time whether to build for OpenMP, Cuda, or
-Phi.
-</P>
-<P>You can do any of these in one line, using the src/Make.py script,
-described in <A HREF = "Section_start.html#start_4">Section 2.4</A> of the manual.
-Type "Make.py -h" for help.  If run from the src directory, these
-commands will create src/lmp_kokkos_omp, lmp_kokkos_cuda, and
-lmp_kokkos_phi.  The OMP and PHI options use src/MAKE/Makefile.mpi as
-the starting Makefile.machine.  The CUDA option uses
-src/MAKE/OPTIONS/Makefile.cuda since the NVIDIA nvcc compiler is
-required.
-</P>
-<P>Make.py -p kokkos -kokkos omp -o kokkos_omp file mpi 
-Make.py -p kokkos -kokkos cuda arch=31 -o kokkos_cuda file kokkos_cuda
-Make.py -p kokkos -kokkos phi -o kokkos_phi file mpi 
-</P>
-<P>Or you can follow these steps:
-</P>
-<P>CPU-only (run all-MPI or with OpenMP threading):
-</P>
-<PRE>cd lammps/src
-make yes-kokkos
-make g++ OMP=yes 
-</PRE>
-<P>Intel Xeon Phi:
-</P>
-<PRE>cd lammps/src
-make yes-kokkos
-make g++ OMP=yes MIC=yes 
-</PRE>
-<P>CPUs and GPUs:
-</P>
-<PRE>cd lammps/src
-make yes-kokkos
-make cuda CUDA=yes 
-</PRE>
-<P>These examples set the KOKKOS-specific OMP, MIC, CUDA variables on the
-make command line which requires a GNU-compatible make command.  Try
-"gmake" if your system's standard make complains.  
-</P>
-<P>IMPORTANT NOTE: If you build using make line variables and re-build
-LAMMPS twice with different KOKKOS options and the *same* target,
-e.g. g++ in the first two examples above, then you *must* perform a
-"make clean-all" or "make clean-machine" before each build.  This is
-to force all the KOKKOS-dependent files to be re-compiled with the new
-options.
-</P>
-<P>You can also hardwire these make variables in the specified machine
-makefile, e.g. src/MAKE/Makefile.g++ in the first two examples above,
-with a line like:
-</P>
-<PRE>MIC = yes 
-</PRE>
-<P>Note that if you build LAMMPS multiple times in this manner, using
-different KOKKOS options (defined in different machine makefiles), you
-do not have to worry about doing a "clean" in between.  This is
-because the targets will be different.
-</P>
-<P>IMPORTANT NOTE: The 3rd example above for a GPU, uses a different
-machine makefile, in this case src/MAKE/Makefile.cuda, which is
-included in the LAMMPS distribution.  To build the KOKKOS package for
-a GPU, this makefile must use the NVIDA "nvcc" compiler.  And it must
-have a CCFLAGS -arch setting that is appropriate for your NVIDIA
-hardware and installed software.  Typical values for -arch are given
-in <A HREF = "Section_start.html#start_3_4">Section 2.3.4</A> of the manual, as well
-as other settings that must be included in the machine makefile, if
-you create your own.
-</P>
-<P>IMPORTANT NOTE: Currently, there are no precision options with the
-KOKKOS package.  All compilation and computation is performed in
-double precision.
-</P>
-<P>There are other allowed options when building with the KOKKOS package.
-As above, they can be set either as variables on the make command line
-or in Makefile.machine.  This is the full list of options, including
-those discussed above, Each takes a value of <I>yes</I> or <I>no</I>.  The
-default value is listed, which is set in the
-lib/kokkos/Makefile.lammps file.
-</P>
-<UL><LI>OMP, default = <I>yes</I>
-<LI>CUDA, default = <I>no</I>
-<LI>HWLOC, default = <I>no</I>
-<LI>AVX, default = <I>no</I>
-<LI>MIC, default = <I>no</I>
-<LI>LIBRT, default = <I>no</I>
-<LI>DEBUG, default = <I>no</I> 
-</UL>
-<P>OMP sets the parallelization method used for Kokkos code (within
-LAMMPS) that runs on the host.  OMP=yes means that OpenMP will be
-used.  OMP=no means that pthreads will be used.
-</P>
-<P>CUDA sets the parallelization method used for Kokkos code (within
-LAMMPS) that runs on the device.  CUDA=yes means an NVIDIA GPU running
-CUDA will be used.  CUDA=no means that the OMP=yes or OMP=no setting
-will be used for the device as well as the host.
-</P>
-<P>If CUDA=yes, then the lo-level Makefile in the src/MAKE directory must
-use "nvcc" as its compiler, via its CC setting.  For best performance
-its CCFLAGS setting should use -O3 and have an -arch setting that
-matches the compute capability of your NVIDIA hardware and software
-installation, e.g. -arch=sm_20.  Generally Fermi Generation GPUs are
-sm_20, while Kepler generation GPUs are sm_30 or sm_35 and Maxwell
-cards are sm_50.  A complete list can be found on
-<A HREF = "http://en.wikipedia.org/wiki/CUDA#Supported_GPUs">wikipedia</A>. You can
-also use the deviceQuery tool that comes with the CUDA samples.  Note
-the minimal required compute capability is 2.0, but this will give
-signicantly reduced performance compared to Kepler generation GPUs
-with compute capability 3.x.  For the LINK setting, "nvcc" should not
-be used; instead use g++ or another compiler suitable for linking C++
-applications.  Often you will want to use your MPI compiler wrapper
-for this setting (i.e. mpicxx).  Finally, the lo-level Makefile must
-also have a "Compilation rule" for creating *.o files from *.cu files.
-See src/Makefile.cuda for an example of a lo-level Makefile with all
-of these settings.
-</P>
-<P>HWLOC binds threads to hardware cores, so they do not migrate during a
-simulation.  HWLOC=yes should always be used if running with OMP=no
-for pthreads.  It is not necessary for OMP=yes for OpenMP, because
-OpenMP provides alternative methods via environment variables for
-binding threads to hardware cores.  More info on binding threads to
-cores is given in <A HREF = "Section_accelerate.html#acc_8">this section</A>.
-</P>
-<P>AVX enables Intel advanced vector extensions when compiling for an
-Intel-compatible chip.  AVX=yes should only be set if your host
-hardware supports AVX.  If it does not support it, this will cause a
-run-time crash.
-</P>
-<P>MIC enables compiler switches needed when compling for an Intel Phi
-processor.
-</P>
-<P>LIBRT enables use of a more accurate timer mechanism on most Unix
-platforms.  This library is not available on all platforms.
-</P>
-<P>DEBUG is only useful when developing a Kokkos-enabled style within
-LAMMPS.  DEBUG=yes enables printing of run-time debugging information
-that can be useful.  It also enables runtime bounds checking on Kokkos
-data structures.
-</P>
-<P><B>Run with the KOKKOS package from the command line:</B>
-</P>
-<P>The mpirun or mpiexec command sets the total number of MPI tasks used
-by LAMMPS (one or multiple per compute node) and the number of MPI
-tasks used per node.  E.g. the mpirun command in MPICH does this via
-its -np and -ppn switches.  Ditto for OpenMPI via -np and -npernode.
-</P>
-<P>When using KOKKOS built with host=OMP, you need to choose how many
-OpenMP threads per MPI task will be used (via the "-k" command-line
-switch discussed below).  Note that the product of MPI tasks * OpenMP
-threads/task should not exceed the physical number of cores (on a
-node), otherwise performance will suffer.
-</P>
-<P>When using the KOKKOS package built with device=CUDA, you must use
-exactly one MPI task per physical GPU.
-</P>
-<P>When using the KOKKOS package built with host=MIC for Intel Xeon Phi
-coprocessor support you need to insure there are one or more MPI tasks
-per coprocessor, and choose the number of coprocessor threads to use
-per MPI task (via the "-k" command-line switch discussed below).  The
-product of MPI tasks * coprocessor threads/task should not exceed the
-maximum number of threads the coproprocessor is designed to run,
-otherwise performance will suffer.  This value is 240 for current
-generation Xeon Phi(TM) chips, which is 60 physical cores * 4
-threads/core.  Note that with the KOKKOS package you do not need to
-specify how many Phi coprocessors there are per node; each
-coprocessors is simply treated as running some number of MPI tasks.
-</P>
-<P>You must use the "-k on" <A HREF = "Section_start.html#start_7">command-line
-switch</A> to enable the KOKKOS package.  It
-takes additional arguments for hardware settings appropriate to your
-system.  Those arguments are <A HREF = "Section_start.html#start_7">documented
-here</A>.  The two most commonly used
-options are:
-</P>
-<PRE>-k on t Nt g Ng 
-</PRE>
-<P>The "t Nt" option applies to host=OMP (even if device=CUDA) and
-host=MIC.  For host=OMP, it specifies how many OpenMP threads per MPI
-task to use with a node.  For host=MIC, it specifies how many Xeon Phi
-threads per MPI task to use within a node.  The default is Nt = 1.
-Note that for host=OMP this is effectively MPI-only mode which may be
-fine.  But for host=MIC you will typically end up using far less than
-all the 240 available threads, which could give very poor performance.
-</P>
-<P>The "g Ng" option applies to device=CUDA.  It specifies how many GPUs
-per compute node to use.  The default is 1, so this only needs to be
-specified is you have 2 or more GPUs per compute node.
-</P>
-<P>The "-k on" switch also issues a "package kokkos" command (with no
-additional arguments) which sets various KOKKOS options to default
-values, as discussed on the <A HREF = "package.html">package</A> command doc page.
-</P>
-<P>Use the "-sf kk" <A HREF = "Section_start.html#start_7">command-line switch</A>,
-which will automatically append "kk" to styles that support it.  Use
-the "-pk kokkos" <A HREF = "Section_start.html#start_7">command-line switch</A> if
-you wish to change any of the default <A HREF = "package.html">package kokkos</A>
-optionns set by the "-k on" <A HREF = "Section_start.html#start_7">command-line
-switch</A>.
-</P>
-<PRE>host=OMP, dual hex-core nodes (12 threads/node):
-mpirun -np 12 lmp_g++ -in in.lj                           # MPI-only mode with no Kokkos
-mpirun -np 12 lmp_g++ -k on -sf kk -in in.lj              # MPI-only mode with Kokkos
-mpirun -np 1 lmp_g++ -k on t 12 -sf kk -in in.lj          # one MPI task, 12 threads
-mpirun -np 2 lmp_g++ -k on t 6 -sf kk -in in.lj           # two MPI tasks, 6 threads/task 
-mpirun -np 32 -ppn 2 lmp_g++ -k on t 6 -sf kk -in in.lj   # ditto on 16 nodes 
-</PRE>
-<P>host=MIC, Intel Phi with 61 cores (240 threads/phi via 4x hardware threading):
-mpirun -np 1 lmp_g++ -k on t 240 -sf kk -in in.lj           # 1 MPI task on 1 Phi, 1*240 = 240
-mpirun -np 30 lmp_g++ -k on t 8 -sf kk -in in.lj            # 30 MPI tasks on 1 Phi, 30*8 = 240
-mpirun -np 12 lmp_g++ -k on t 20 -sf kk -in in.lj           # 12 MPI tasks on 1 Phi, 12*20 = 240
-mpirun -np 96 -ppn 12 lmp_g++ -k on t 20 -sf kk -in in.lj   # ditto on 8 Phis
-</P>
-<PRE>host=OMP, device=CUDA, node = dual hex-core CPUs and a single GPU:
-mpirun -np 1 lmp_cuda -k on t 6 -sf kk -in in.lj          # one MPI task, 6 threads on CPU
-mpirun -np 4 -ppn 1 lmp_cuda -k on t 6 -sf kk -in in.lj   # ditto on 4 nodes 
-</PRE>
-<PRE>host=OMP, device=CUDA, node = dual 8-core CPUs and 2 GPUs:
-mpirun -np 2 lmp_cuda -k on t 8 g 2 -sf kk -in in.lj           # two MPI tasks, 8 threads per CPU
-mpirun -np 32 -ppn 2 lmp_cuda -k on t 8 g 2 -sf kk -in in.lj   # ditto on 16 nodes 
-</PRE>
-<P>Note that the default for the <A HREF = "package.html">package kokkos</A> command is
-to use "full" neighbor lists and set the Newton flag to "off" for both
-pairwise and bonded interactions.  This typically gives fastest
-performance.  If the <A HREF = "newton.html">newton</A> command is used in the input
-script, it can override the Newton flag defaults.
-</P>
-<P>However, when running in MPI-only mode with 1 thread per MPI task, it
-will typically be faster to use "half" neighbor lists and set the
-Newton flag to "on", just as is the case for non-accelerated pair
-styles.  You can do this with the "-pk" <A HREF = "Section_start.html#start_7">command-line
-switch</A>.
-</P>
-<P><B>Or run with the KOKKOS package by editing an input script:</B>
-</P>
-<P>The discussion above for the mpirun/mpiexec command and setting
-appropriate thread and GPU values for host=OMP or host=MIC or
-device=CUDA are the same.
-</P>
-<P>You must still use the "-k on" <A HREF = "Section_start.html#start_7">command-line
-switch</A> to enable the KOKKOS package, and
-specify its additional arguments for hardware options appopriate to
-your system, as documented above.
-</P>
-<P>Use the <A HREF = "suffix.html">suffix kk</A> command, or you can explicitly add a
-"kk" suffix to individual styles in your input script, e.g.
-</P>
-<PRE>pair_style lj/cut/kk 2.5 
-</PRE>
-<P>You only need to use the <A HREF = "package.html">package kokkos</A> command if you
-wish to change any of its option defaults, as set by the "-k on"
-<A HREF = "Section_start.html#start_7">command-line switch</A>.
-</P>
-<P><B>Speed-ups to expect:</B>
-</P>
-<P>The performance of KOKKOS running in different modes is a function of
-your hardware, which KOKKOS-enable styles are used, and the problem
-size.
-</P>
-<P>Generally speaking, the following rules of thumb apply:
-</P>
-<UL><LI>When running on CPUs only, with a single thread per MPI task,
-performance of a KOKKOS style is somewhere between the standard
-(un-accelerated) styles (MPI-only mode), and those provided by the
-USER-OMP package.  However the difference between all 3 is small (less
-than 20%). 
-
-<LI>When running on CPUs only, with multiple threads per MPI task,
-performance of a KOKKOS style is a bit slower than the USER-OMP
-package. 
-
-<LI>When running on GPUs, KOKKOS is typically faster than the USER-CUDA
-and GPU packages. 
-
-<LI>When running on Intel Xeon Phi, KOKKOS is not as fast as
-the USER-INTEL package, which is optimized for that hardware. 
-</UL>
-<P>See the <A HREF = "http://lammps.sandia.gov/bench.html">Benchmark page</A> of the
-LAMMPS web site for performance of the KOKKOS package on different
-hardware.
-</P>
-<P><B>Guidelines for best performance:</B>
-</P>
-<P>Here are guidline for using the KOKKOS package on the different
-hardware configurations listed above.
-</P>
-<P>Many of the guidelines use the <A HREF = "package.html">package kokkos</A> command
-See its doc page for details and default settings.  Experimenting with
-its options can provide a speed-up for specific calculations.
-</P>
-<P><B>Running on a multi-core CPU:</B>
-</P>
-<P>If N is the number of physical cores/node, then the number of MPI
-tasks/node * number of threads/task should not exceed N, and should
-typically equal N.  Note that the default threads/task is 1, as set by
-the "t" keyword of the "-k" <A HREF = "Section_start.html#start_7">command-line
-switch</A>.  If you do not change this, no
-additional parallelism (beyond MPI) will be invoked on the host
-CPU(s).
-</P>
-<P>You can compare the performance running in different modes:
-</P>
-<UL><LI>run with 1 MPI task/node and N threads/task
-<LI>run with N MPI tasks/node and 1 thread/task
-<LI>run with settings in between these extremes 
-</UL>
-<P>Examples of mpirun commands in these modes are shown above.
-</P>
-<P>When using KOKKOS to perform multi-threading, it is important for
-performance to bind both MPI tasks to physical cores, and threads to
-physical cores, so they do not migrate during a simulation.
-</P>
-<P>If you are not certain MPI tasks are being bound (check the defaults
-for your MPI installation), binding can be forced with these flags:
-</P>
-<PRE>OpenMPI 1.8: mpirun -np 2 -bind-to socket -map-by socket ./lmp_openmpi ...
-Mvapich2 2.0: mpiexec -np 2 -bind-to socket -map-by socket ./lmp_mvapich ... 
-</PRE>
-<P>For binding threads with the KOKKOS OMP option, use thread affinity
-environment variables to force binding.  With OpenMP 3.1 (gcc 4.7 or
-later, intel 12 or later) setting the environment variable
-OMP_PROC_BIND=true should be sufficient.  For binding threads with the
-KOKKOS pthreads option, compile LAMMPS the KOKKOS HWLOC=yes option, as
-discussed in <A HREF = "Sections_start.html#start_3_4">Section 2.3.4</A> of the
-manual.
-</P>
-<P><B>Running on GPUs:</B>
-</P>
-<P>Insure the -arch setting in the machine makefile you are using,
-e.g. src/MAKE/Makefile.cuda, is correct for your GPU hardware/software
-(see <A HREF = "Section_start.html#start_3_4">this section</A> of the manual for
-details).
-</P>
-<P>The -np setting of the mpirun command should set the number of MPI
-tasks/node to be equal to the # of physical GPUs on the node. 
-</P>
-<P>Use the "-k" <A HREF = "Section_commands.html#start_7">command-line switch</A> to
-specify the number of GPUs per node, and the number of threads per MPI
-task.  As above for multi-core CPUs (and no GPU), if N is the number
-of physical cores/node, then the number of MPI tasks/node * number of
-threads/task should not exceed N.  With one GPU (and one MPI task) it
-may be faster to use less than all the available cores, by setting
-threads/task to a smaller value.  This is because using all the cores
-on a dual-socket node will incur extra cost to copy memory from the
-2nd socket to the GPU.
-</P>
-<P>Examples of mpirun commands that follow these rules are shown above.
-</P>
-<P>IMPORTANT NOTE: When using a GPU, you will achieve the best
-performance if your input script does not use any fix or compute
-styles which are not yet Kokkos-enabled.  This allows data to stay on
-the GPU for multiple timesteps, without being copied back to the host
-CPU.  Invoking a non-Kokkos fix or compute, or performing I/O for
-<A HREF = "thermo_style.html">thermo</A> or <A HREF = "dump.html">dump</A> output will cause data
-to be copied back to the CPU.
-</P>
-<P>You cannot yet assign multiple MPI tasks to the same GPU with the
-KOKKOS package.  We plan to support this in the future, similar to the
-GPU package in LAMMPS.
-</P>
-<P>You cannot yet use both the host (multi-threaded) and device (GPU)
-together to compute pairwise interactions with the KOKKOS package.  We
-hope to support this in the future, similar to the GPU package in
-LAMMPS.
-</P>
-<P><B>Running on an Intel Phi:</B>
-</P>
-<P>Kokkos only uses Intel Phi processors in their "native" mode, i.e.
-not hosted by a CPU.
-</P>
-<P>As illustrated above, build LAMMPS with OMP=yes (the default) and
-MIC=yes.  The latter insures code is correctly compiled for the Intel
-Phi.  The OMP setting means OpenMP will be used for parallelization on
-the Phi, which is currently the best option within Kokkos.  In the
-future, other options may be added.
-</P>
-<P>Current-generation Intel Phi chips have either 61 or 57 cores.  One
-core should be excluded for running the OS, leaving 60 or 56 cores.
-Each core is hyperthreaded, so there are effectively N = 240 (4*60) or
-N = 224 (4*56) cores to run on.
-</P>
-<P>The -np setting of the mpirun command sets the number of MPI
-tasks/node.  The "-k on t Nt" command-line switch sets the number of
-threads/task as Nt.  The product of these 2 values should be N, i.e.
-240 or 224.  Also, the number of threads/task should be a multiple of
-4 so that logical threads from more than one MPI task do not run on
-the same physical core.
-</P>
-<P>Examples of mpirun commands that follow these rules are shown above.
-</P>
-<P><B>Restrictions:</B>
-</P>
-<P>As noted above, if using GPUs, the number of MPI tasks per compute
-node should equal to the number of GPUs per compute node.  In the
-future Kokkos will support assigning multiple MPI tasks to a single
-GPU.
-</P>
-<P>Currently Kokkos does not support AMD GPUs due to limits in the
-available backend programming models.  Specifically, Kokkos requires
-extensive C++ support from the Kernel language.  This is expected to
-change in the future.
-</P>
-<P>Kokkos must be built with a C++11 compatible compiler.  For example,
-gcc 4.7.2 or later.
-</P>
-</HTML>
--- a/doc/accelerate_kokkos.txt
+++ b/doc/accelerate_kokkos.txt
@ -1,509 +0,0 @@
-"Previous Section"_Section_packages.html - "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
-
-"Return to Section accelerate overview"_Section_accelerate.html
-
-5.3.4 KOKKOS package :h4
-
-The KOKKOS package was developed primaritly by Christian Trott
-(Sandia) with contributions of various styles by others, including
-Sikandar Mashayak (UIUC).  The underlying Kokkos library was written
-primarily by Carter Edwards, Christian Trott, and Dan Sunderland (all
-Sandia).
-
-The KOKKOS package contains versions of pair, fix, and atom styles
-that use data structures and macros provided by the Kokkos library,
-which is included with LAMMPS in lib/kokkos.
-
-The Kokkos library is part of
-"Trilinos"_http://trilinos.sandia.gov/packages/kokkos and is a
-templated C++ library that provides two key abstractions for an
-application like LAMMPS.  First, it allows a single implementation of
-an application kernel (e.g. a pair style) to run efficiently on
-different kinds of hardware, such as a GPU, Intel Phi, or many-core
-chip.
-
-The Kokkos library also provides data abstractions to adjust (at
-compile time) the memory layout of basic data structures like 2d and
-3d arrays and allow the transparent utilization of special hardware
-load and store operations.  Such data structures are used in LAMMPS to
-store atom coordinates or forces or neighbor lists.  The layout is
-chosen to optimize performance on different platforms.  Again this
-functionality is hidden from the developer, and does not affect how
-the kernel is coded.
-
-These abstractions are set at build time, when LAMMPS is compiled with
-the KOKKOS package installed.  This is done by selecting a "host" and
-"device" to build for, compatible with the compute nodes in your
-machine (one on a desktop machine or 1000s on a supercomputer).
-
-All Kokkos operations occur within the context of an individual MPI
-task running on a single node of the machine.  The total number of MPI
-tasks used by LAMMPS (one or multiple per compute node) is set in the
-usual manner via the mpirun or mpiexec commands, and is independent of
-Kokkos.
-
-Kokkos provides support for two different modes of execution per MPI
-task.  This means that computational tasks (pairwise interactions,
-neighbor list builds, time integration, etc) can be parallelized for
-one or the other of the two modes.  The first mode is called the
-"host" and is one or more threads running on one or more physical CPUs
-(within the node).  Currently, both multi-core CPUs and an Intel Phi
-processor (running in native mode, not offload mode like the
-USER-INTEL package) are supported.  The second mode is called the
-"device" and is an accelerator chip of some kind.  Currently only an
-NVIDIA GPU is supported via Cuda.  If your compute node does not have
-a GPU, then there is only one mode of execution, i.e. the host and
-device are the same.
-
-When using the KOKKOS package, you must choose at build time whether
-you are building for OpenMP, GPU, or for using the Xeon Phi in native
-mode.
-
-Here is a quick overview of how to use the KOKKOS package:
-
-specify variables and settings in your Makefile.machine that enable OpenMP, GPU, or Phi support
-include the KOKKOS package and build LAMMPS
-enable the KOKKOS package and its hardware options via the "-k on" command-line switch
-use KOKKOS styles in your input script :ul
-
-The latter two steps can be done using the "-k on", "-pk kokkos" and
-"-sf kk" "command-line switches"_Section_start.html#start_7
-respectively.  Or the effect of the "-pk" or "-sf" switches can be
-duplicated by adding the "package kokkos"_package.html or "suffix
-kk"_suffix.html commands respectively to your input script.
-
-[Required hardware/software:]
-
-The KOKKOS package can be used to build and run LAMMPS on the
-following kinds of hardware:
-
-CPU-only: one MPI task per CPU core (MPI-only, but using KOKKOS styles)
-CPU-only: one or a few MPI tasks per node with additional threading via OpenMP
-Phi: on one or more Intel Phi coprocessors (per node)
-GPU: on the GPUs of a node with additional OpenMP threading on the CPUs :ul
-
-Note that Intel Xeon Phi coprocessors are supported in "native" mode,
-not "offload" mode like the USER-INTEL package supports.
-
-Only NVIDIA GPUs are currently supported.
-
-IMPORTANT NOTE: For good performance of the KOKKOS package on GPUs,
-you must have Kepler generation GPUs (or later).  The Kokkos library
-exploits texture cache options not supported by Telsa generation GPUs
-(or older).
-
-To build the KOKKOS package for GPUs, NVIDIA Cuda software must be
-installed on your system.  See the discussion above for the USER-CUDA
-and GPU packages for details of how to check and do this.
-
-[Building LAMMPS with the KOKKOS package:]
-
-You must choose at build time whether to build for OpenMP, Cuda, or
-Phi.
-
-You can do any of these in one line, using the src/Make.py script,
-described in "Section 2.4"_Section_start.html#start_4 of the manual.
-Type "Make.py -h" for help.  If run from the src directory, these
-commands will create src/lmp_kokkos_omp, lmp_kokkos_cuda, and
-lmp_kokkos_phi.  The OMP and PHI options use src/MAKE/Makefile.mpi as
-the starting Makefile.machine.  The CUDA option uses
-src/MAKE/OPTIONS/Makefile.cuda since the NVIDIA nvcc compiler is
-required.
-
-Make.py -p kokkos -kokkos omp -o kokkos_omp file mpi 
-Make.py -p kokkos -kokkos cuda arch=31 -o kokkos_cuda file kokkos_cuda
-Make.py -p kokkos -kokkos phi -o kokkos_phi file mpi 
-
-Or you can follow these steps:
-
-CPU-only (run all-MPI or with OpenMP threading):
-
-cd lammps/src
-make yes-kokkos
-make g++ OMP=yes :pre
-
-Intel Xeon Phi:
-
-cd lammps/src
-make yes-kokkos
-make g++ OMP=yes MIC=yes :pre
-
-CPUs and GPUs:
-
-cd lammps/src
-make yes-kokkos
-make cuda CUDA=yes :pre
-
-These examples set the KOKKOS-specific OMP, MIC, CUDA variables on the
-make command line which requires a GNU-compatible make command.  Try
-"gmake" if your system's standard make complains.  
-
-IMPORTANT NOTE: If you build using make line variables and re-build
-LAMMPS twice with different KOKKOS options and the *same* target,
-e.g. g++ in the first two examples above, then you *must* perform a
-"make clean-all" or "make clean-machine" before each build.  This is
-to force all the KOKKOS-dependent files to be re-compiled with the new
-options.
-
-You can also hardwire these make variables in the specified machine
-makefile, e.g. src/MAKE/Makefile.g++ in the first two examples above,
-with a line like:
-
-MIC = yes :pre
-
-Note that if you build LAMMPS multiple times in this manner, using
-different KOKKOS options (defined in different machine makefiles), you
-do not have to worry about doing a "clean" in between.  This is
-because the targets will be different.
-
-IMPORTANT NOTE: The 3rd example above for a GPU, uses a different
-machine makefile, in this case src/MAKE/Makefile.cuda, which is
-included in the LAMMPS distribution.  To build the KOKKOS package for
-a GPU, this makefile must use the NVIDA "nvcc" compiler.  And it must
-have a CCFLAGS -arch setting that is appropriate for your NVIDIA
-hardware and installed software.  Typical values for -arch are given
-in "Section 2.3.4"_Section_start.html#start_3_4 of the manual, as well
-as other settings that must be included in the machine makefile, if
-you create your own.
-
-IMPORTANT NOTE: Currently, there are no precision options with the
-KOKKOS package.  All compilation and computation is performed in
-double precision.
-
-There are other allowed options when building with the KOKKOS package.
-As above, they can be set either as variables on the make command line
-or in Makefile.machine.  This is the full list of options, including
-those discussed above, Each takes a value of {yes} or {no}.  The
-default value is listed, which is set in the
-lib/kokkos/Makefile.lammps file.
-
-OMP, default = {yes}
-CUDA, default = {no}
-HWLOC, default = {no}
-AVX, default = {no}
-MIC, default = {no}
-LIBRT, default = {no}
-DEBUG, default = {no} :ul
-
-OMP sets the parallelization method used for Kokkos code (within
-LAMMPS) that runs on the host.  OMP=yes means that OpenMP will be
-used.  OMP=no means that pthreads will be used.
-
-CUDA sets the parallelization method used for Kokkos code (within
-LAMMPS) that runs on the device.  CUDA=yes means an NVIDIA GPU running
-CUDA will be used.  CUDA=no means that the OMP=yes or OMP=no setting
-will be used for the device as well as the host.
-
-If CUDA=yes, then the lo-level Makefile in the src/MAKE directory must
-use "nvcc" as its compiler, via its CC setting.  For best performance
-its CCFLAGS setting should use -O3 and have an -arch setting that
-matches the compute capability of your NVIDIA hardware and software
-installation, e.g. -arch=sm_20.  Generally Fermi Generation GPUs are
-sm_20, while Kepler generation GPUs are sm_30 or sm_35 and Maxwell
-cards are sm_50.  A complete list can be found on
-"wikipedia"_http://en.wikipedia.org/wiki/CUDA#Supported_GPUs. You can
-also use the deviceQuery tool that comes with the CUDA samples.  Note
-the minimal required compute capability is 2.0, but this will give
-signicantly reduced performance compared to Kepler generation GPUs
-with compute capability 3.x.  For the LINK setting, "nvcc" should not
-be used; instead use g++ or another compiler suitable for linking C++
-applications.  Often you will want to use your MPI compiler wrapper
-for this setting (i.e. mpicxx).  Finally, the lo-level Makefile must
-also have a "Compilation rule" for creating *.o files from *.cu files.
-See src/Makefile.cuda for an example of a lo-level Makefile with all
-of these settings.
-
-HWLOC binds threads to hardware cores, so they do not migrate during a
-simulation.  HWLOC=yes should always be used if running with OMP=no
-for pthreads.  It is not necessary for OMP=yes for OpenMP, because
-OpenMP provides alternative methods via environment variables for
-binding threads to hardware cores.  More info on binding threads to
-cores is given in "this section"_Section_accelerate.html#acc_8.
-
-AVX enables Intel advanced vector extensions when compiling for an
-Intel-compatible chip.  AVX=yes should only be set if your host
-hardware supports AVX.  If it does not support it, this will cause a
-run-time crash.
-
-MIC enables compiler switches needed when compling for an Intel Phi
-processor.
-
-LIBRT enables use of a more accurate timer mechanism on most Unix
-platforms.  This library is not available on all platforms.
-
-DEBUG is only useful when developing a Kokkos-enabled style within
-LAMMPS.  DEBUG=yes enables printing of run-time debugging information
-that can be useful.  It also enables runtime bounds checking on Kokkos
-data structures.
-
-[Run with the KOKKOS package from the command line:]
-
-The mpirun or mpiexec command sets the total number of MPI tasks used
-by LAMMPS (one or multiple per compute node) and the number of MPI
-tasks used per node.  E.g. the mpirun command in MPICH does this via
-its -np and -ppn switches.  Ditto for OpenMPI via -np and -npernode.
-
-When using KOKKOS built with host=OMP, you need to choose how many
-OpenMP threads per MPI task will be used (via the "-k" command-line
-switch discussed below).  Note that the product of MPI tasks * OpenMP
-threads/task should not exceed the physical number of cores (on a
-node), otherwise performance will suffer.
-
-When using the KOKKOS package built with device=CUDA, you must use
-exactly one MPI task per physical GPU.
-
-When using the KOKKOS package built with host=MIC for Intel Xeon Phi
-coprocessor support you need to insure there are one or more MPI tasks
-per coprocessor, and choose the number of coprocessor threads to use
-per MPI task (via the "-k" command-line switch discussed below).  The
-product of MPI tasks * coprocessor threads/task should not exceed the
-maximum number of threads the coproprocessor is designed to run,
-otherwise performance will suffer.  This value is 240 for current
-generation Xeon Phi(TM) chips, which is 60 physical cores * 4
-threads/core.  Note that with the KOKKOS package you do not need to
-specify how many Phi coprocessors there are per node; each
-coprocessors is simply treated as running some number of MPI tasks.
-
-You must use the "-k on" "command-line
-switch"_Section_start.html#start_7 to enable the KOKKOS package.  It
-takes additional arguments for hardware settings appropriate to your
-system.  Those arguments are "documented
-here"_Section_start.html#start_7.  The two most commonly used
-options are:
-
-k on t Nt g Ng :pre
-
-The "t Nt" option applies to host=OMP (even if device=CUDA) and
-host=MIC.  For host=OMP, it specifies how many OpenMP threads per MPI
-task to use with a node.  For host=MIC, it specifies how many Xeon Phi
-threads per MPI task to use within a node.  The default is Nt = 1.
-Note that for host=OMP this is effectively MPI-only mode which may be
-fine.  But for host=MIC you will typically end up using far less than
-all the 240 available threads, which could give very poor performance.
-
-The "g Ng" option applies to device=CUDA.  It specifies how many GPUs
-per compute node to use.  The default is 1, so this only needs to be
-specified is you have 2 or more GPUs per compute node.
-
-The "-k on" switch also issues a "package kokkos" command (with no
-additional arguments) which sets various KOKKOS options to default
-values, as discussed on the "package"_package.html command doc page.
-
-Use the "-sf kk" "command-line switch"_Section_start.html#start_7,
-which will automatically append "kk" to styles that support it.  Use
-the "-pk kokkos" "command-line switch"_Section_start.html#start_7 if
-you wish to change any of the default "package kokkos"_package.html
-optionns set by the "-k on" "command-line
-switch"_Section_start.html#start_7.
-
-host=OMP, dual hex-core nodes (12 threads/node):
-mpirun -np 12 lmp_g++ -in in.lj                           # MPI-only mode with no Kokkos
-mpirun -np 12 lmp_g++ -k on -sf kk -in in.lj              # MPI-only mode with Kokkos
-mpirun -np 1 lmp_g++ -k on t 12 -sf kk -in in.lj          # one MPI task, 12 threads
-mpirun -np 2 lmp_g++ -k on t 6 -sf kk -in in.lj           # two MPI tasks, 6 threads/task 
-mpirun -np 32 -ppn 2 lmp_g++ -k on t 6 -sf kk -in in.lj   # ditto on 16 nodes :pre
-
-host=MIC, Intel Phi with 61 cores (240 threads/phi via 4x hardware threading):
-mpirun -np 1 lmp_g++ -k on t 240 -sf kk -in in.lj           # 1 MPI task on 1 Phi, 1*240 = 240
-mpirun -np 30 lmp_g++ -k on t 8 -sf kk -in in.lj            # 30 MPI tasks on 1 Phi, 30*8 = 240
-mpirun -np 12 lmp_g++ -k on t 20 -sf kk -in in.lj           # 12 MPI tasks on 1 Phi, 12*20 = 240
-mpirun -np 96 -ppn 12 lmp_g++ -k on t 20 -sf kk -in in.lj   # ditto on 8 Phis
-
-host=OMP, device=CUDA, node = dual hex-core CPUs and a single GPU:
-mpirun -np 1 lmp_cuda -k on t 6 -sf kk -in in.lj          # one MPI task, 6 threads on CPU
-mpirun -np 4 -ppn 1 lmp_cuda -k on t 6 -sf kk -in in.lj   # ditto on 4 nodes :pre
-
-host=OMP, device=CUDA, node = dual 8-core CPUs and 2 GPUs:
-mpirun -np 2 lmp_cuda -k on t 8 g 2 -sf kk -in in.lj           # two MPI tasks, 8 threads per CPU
-mpirun -np 32 -ppn 2 lmp_cuda -k on t 8 g 2 -sf kk -in in.lj   # ditto on 16 nodes :pre
-
-Note that the default for the "package kokkos"_package.html command is
-to use "full" neighbor lists and set the Newton flag to "off" for both
-pairwise and bonded interactions.  This typically gives fastest
-performance.  If the "newton"_newton.html command is used in the input
-script, it can override the Newton flag defaults.
-
-However, when running in MPI-only mode with 1 thread per MPI task, it
-will typically be faster to use "half" neighbor lists and set the
-Newton flag to "on", just as is the case for non-accelerated pair
-styles.  You can do this with the "-pk" "command-line
-switch"_Section_start.html#start_7.
-
-[Or run with the KOKKOS package by editing an input script:]
-
-The discussion above for the mpirun/mpiexec command and setting
-appropriate thread and GPU values for host=OMP or host=MIC or
-device=CUDA are the same.
-
-You must still use the "-k on" "command-line
-switch"_Section_start.html#start_7 to enable the KOKKOS package, and
-specify its additional arguments for hardware options appopriate to
-your system, as documented above.
-
-Use the "suffix kk"_suffix.html command, or you can explicitly add a
-"kk" suffix to individual styles in your input script, e.g.
-
-pair_style lj/cut/kk 2.5 :pre
-
-You only need to use the "package kokkos"_package.html command if you
-wish to change any of its option defaults, as set by the "-k on"
-"command-line switch"_Section_start.html#start_7.
-
-[Speed-ups to expect:]
-
-The performance of KOKKOS running in different modes is a function of
-your hardware, which KOKKOS-enable styles are used, and the problem
-size.
-
-Generally speaking, the following rules of thumb apply:
-
-When running on CPUs only, with a single thread per MPI task,
-performance of a KOKKOS style is somewhere between the standard
-(un-accelerated) styles (MPI-only mode), and those provided by the
-USER-OMP package.  However the difference between all 3 is small (less
-than 20%). :ulb,l
-
-When running on CPUs only, with multiple threads per MPI task,
-performance of a KOKKOS style is a bit slower than the USER-OMP
-package. :l
-
-When running on GPUs, KOKKOS is typically faster than the USER-CUDA
-and GPU packages. :l
-
-When running on Intel Xeon Phi, KOKKOS is not as fast as
-the USER-INTEL package, which is optimized for that hardware. :l,ule
-
-See the "Benchmark page"_http://lammps.sandia.gov/bench.html of the
-LAMMPS web site for performance of the KOKKOS package on different
-hardware.
-
-[Guidelines for best performance:]
-
-Here are guidline for using the KOKKOS package on the different
-hardware configurations listed above.
-
-Many of the guidelines use the "package kokkos"_package.html command
-See its doc page for details and default settings.  Experimenting with
-its options can provide a speed-up for specific calculations.
-
-[Running on a multi-core CPU:]
-
-If N is the number of physical cores/node, then the number of MPI
-tasks/node * number of threads/task should not exceed N, and should
-typically equal N.  Note that the default threads/task is 1, as set by
-the "t" keyword of the "-k" "command-line
-switch"_Section_start.html#start_7.  If you do not change this, no
-additional parallelism (beyond MPI) will be invoked on the host
-CPU(s).
-
-You can compare the performance running in different modes:
-  
-run with 1 MPI task/node and N threads/task
-run with N MPI tasks/node and 1 thread/task
-run with settings in between these extremes :ul
-
-Examples of mpirun commands in these modes are shown above.
-
-When using KOKKOS to perform multi-threading, it is important for
-performance to bind both MPI tasks to physical cores, and threads to
-physical cores, so they do not migrate during a simulation.
-
-If you are not certain MPI tasks are being bound (check the defaults
-for your MPI installation), binding can be forced with these flags:
-
-OpenMPI 1.8: mpirun -np 2 -bind-to socket -map-by socket ./lmp_openmpi ...
-Mvapich2 2.0: mpiexec -np 2 -bind-to socket -map-by socket ./lmp_mvapich ... :pre
-
-For binding threads with the KOKKOS OMP option, use thread affinity
-environment variables to force binding.  With OpenMP 3.1 (gcc 4.7 or
-later, intel 12 or later) setting the environment variable
-OMP_PROC_BIND=true should be sufficient.  For binding threads with the
-KOKKOS pthreads option, compile LAMMPS the KOKKOS HWLOC=yes option, as
-discussed in "Section 2.3.4"_Sections_start.html#start_3_4 of the
-manual.
-
-[Running on GPUs:]
-
-Insure the -arch setting in the machine makefile you are using,
-e.g. src/MAKE/Makefile.cuda, is correct for your GPU hardware/software
-(see "this section"_Section_start.html#start_3_4 of the manual for
-details).
-
-The -np setting of the mpirun command should set the number of MPI
-tasks/node to be equal to the # of physical GPUs on the node. 
-
-Use the "-k" "command-line switch"_Section_commands.html#start_7 to
-specify the number of GPUs per node, and the number of threads per MPI
-task.  As above for multi-core CPUs (and no GPU), if N is the number
-of physical cores/node, then the number of MPI tasks/node * number of
-threads/task should not exceed N.  With one GPU (and one MPI task) it
-may be faster to use less than all the available cores, by setting
-threads/task to a smaller value.  This is because using all the cores
-on a dual-socket node will incur extra cost to copy memory from the
-2nd socket to the GPU.
-
-Examples of mpirun commands that follow these rules are shown above.
-
-IMPORTANT NOTE: When using a GPU, you will achieve the best
-performance if your input script does not use any fix or compute
-styles which are not yet Kokkos-enabled.  This allows data to stay on
-the GPU for multiple timesteps, without being copied back to the host
-CPU.  Invoking a non-Kokkos fix or compute, or performing I/O for
-"thermo"_thermo_style.html or "dump"_dump.html output will cause data
-to be copied back to the CPU.
-
-You cannot yet assign multiple MPI tasks to the same GPU with the
-KOKKOS package.  We plan to support this in the future, similar to the
-GPU package in LAMMPS.
-
-You cannot yet use both the host (multi-threaded) and device (GPU)
-together to compute pairwise interactions with the KOKKOS package.  We
-hope to support this in the future, similar to the GPU package in
-LAMMPS.
-
-[Running on an Intel Phi:]
-
-Kokkos only uses Intel Phi processors in their "native" mode, i.e.
-not hosted by a CPU.
-
-As illustrated above, build LAMMPS with OMP=yes (the default) and
-MIC=yes.  The latter insures code is correctly compiled for the Intel
-Phi.  The OMP setting means OpenMP will be used for parallelization on
-the Phi, which is currently the best option within Kokkos.  In the
-future, other options may be added.
-
-Current-generation Intel Phi chips have either 61 or 57 cores.  One
-core should be excluded for running the OS, leaving 60 or 56 cores.
-Each core is hyperthreaded, so there are effectively N = 240 (4*60) or
-N = 224 (4*56) cores to run on.
-
-The -np setting of the mpirun command sets the number of MPI
-tasks/node.  The "-k on t Nt" command-line switch sets the number of
-threads/task as Nt.  The product of these 2 values should be N, i.e.
-240 or 224.  Also, the number of threads/task should be a multiple of
-4 so that logical threads from more than one MPI task do not run on
-the same physical core.
-
-Examples of mpirun commands that follow these rules are shown above.
-
-[Restrictions:]
-
-As noted above, if using GPUs, the number of MPI tasks per compute
-node should equal to the number of GPUs per compute node.  In the
-future Kokkos will support assigning multiple MPI tasks to a single
-GPU.
-
-Currently Kokkos does not support AMD GPUs due to limits in the
-available backend programming models.  Specifically, Kokkos requires
-extensive C++ support from the Kernel language.  This is expected to
-change in the future.
-
-Kokkos must be built with a C++11 compatible compiler.  For example,
-gcc 4.7.2 or later.
--- a/doc/accelerate_omp.html
+++ b/doc/accelerate_omp.html
@ -1,206 +0,0 @@
-<HTML>
-<CENTER><A HREF = "Section_packages.html">Previous Section</A> - <A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> -
-<A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A> 
-</CENTER>
-
-
-
-
-
-
-<HR>
-
-<P><A HREF = "Section_accelerate.html">Return to Section accelerate overview</A>
-</P>
-<H4>5.3.5 USER-OMP package 
-</H4>
-<P>The USER-OMP package was developed by Axel Kohlmeyer at Temple
-University.  It provides multi-threaded versions of most pair styles,
-nearly all bonded styles (bond, angle, dihedral, improper), several
-Kspace styles, and a few fix styles.  The package currently
-uses the OpenMP interface for multi-threading.
-</P>
-<P>Here is a quick overview of how to use the USER-OMP package:
-</P>
-<UL><LI>use the -fopenmp flag for compiling and linking in your Makefile.machine
-<LI>include the USER-OMP package and build LAMMPS
-<LI>use the mpirun command to set the number of MPI tasks/node
-<LI>specify how many threads per MPI task to use
-<LI>use USER-OMP styles in your input script 
-</UL>
-<P>The latter two steps can be done using the "-pk omp" and "-sf omp"
-<A HREF = "Section_start.html#start_7">command-line switches</A> respectively.  Or
-the effect of the "-pk" or "-sf" switches can be duplicated by adding
-the <A HREF = "package.html">package omp</A> or <A HREF = "suffix.html">suffix omp</A> commands
-respectively to your input script.
-</P>
-<P><B>Required hardware/software:</B>
-</P>
-<P>Your compiler must support the OpenMP interface.  You should have one
-or more multi-core CPUs so that multiple threads can be launched by an
-MPI task running on a CPU.
-</P>
-<P><B>Building LAMMPS with the USER-OMP package:</B>
-</P>
-<P>To do this in one line, use the src/Make.py script, described in
-<A HREF = "Section_start.html#start_4">Section 2.4</A> of the manual.  Type "Make.py
-h" for help.  If run from the src directory, this command will create
-src/lmp_omp using src/MAKE/Makefile.mpi as the starting
-Makefile.machine:
-</P>
-<PRE>Make.py -p omp -o omp file mpi 
-</PRE>
-<P>Or you can follow these steps:
-</P>
-<PRE>cd lammps/src
-make yes-user-omp
-make machine 
-</PRE>
-<P>The CCFLAGS setting in Makefile.machine needs "-fopenmp" to add OpenMP
-support.  This works for both the GNU and Intel compilers.  Without
-this flag the USER-OMP styles will still be compiled and work, but
-will not support multi-threading.  For the Intel compilers the CCFLAGS
-setting also needs to include "-restrict".
-</P>
-<P><B>Run with the USER-OMP package from the command line:</B>
-</P>
-<P>The mpirun or mpiexec command sets the total number of MPI tasks used
-by LAMMPS (one or multiple per compute node) and the number of MPI
-tasks used per node.  E.g. the mpirun command in MPICH does this via
-its -np and -ppn switches.  Ditto for OpenMPI via -np and -npernode.
-</P>
-<P>You need to choose how many threads per MPI task will be used by the
-USER-OMP package.  Note that the product of MPI tasks * threads/task
-should not exceed the physical number of cores (on a node), otherwise
-performance will suffer.
-</P>
-<P>Use the "-sf omp" <A HREF = "Section_start.html#start_7">command-line switch</A>,
-which will automatically append "omp" to styles that support it.  Use
-the "-pk omp Nt" <A HREF = "Section_start.html#start_7">command-line switch</A>, to
-set Nt = # of OpenMP threads per MPI task to use.
-</P>
-<PRE>lmp_machine -sf omp -pk omp 16 -in in.script                       # 1 MPI task on a 16-core node
-mpirun -np 4 lmp_machine -sf omp -pk omp 4 -in in.script           # 4 MPI tasks each with 4 threads on a single 16-core node
-mpirun -np 32 -ppn 4 lmp_machine -sf omp -pk omp 4 -in in.script   # ditto on 8 16-core nodes 
-</PRE>
-<P>Note that if the "-sf omp" switch is used, it also issues a default
-<A HREF = "package.html">package omp 0</A> command, which sets the number of threads
-per MPI task via the OMP_NUM_THREADS environment variable.
-</P>
-<P>Using the "-pk" switch explicitly allows for direct setting of the
-number of threads and additional options.  Its syntax is the same as
-the "package omp" command.  See the <A HREF = "package.html">package</A> command doc
-page for details, including the default values used for all its
-options if it is not specified, and how to set the number of threads
-via the OMP_NUM_THREADS environment variable if desired.
-</P>
-<P><B>Or run with the USER-OMP package by editing an input script:</B>
-</P>
-<P>The discussion above for the mpirun/mpiexec command, MPI tasks/node,
-and threads/MPI task is the same.
-</P>
-<P>Use the <A HREF = "suffix.html">suffix omp</A> command, or you can explicitly add an
-"omp" suffix to individual styles in your input script, e.g.
-</P>
-<PRE>pair_style lj/cut/omp 2.5 
-</PRE>
-<P>You must also use the <A HREF = "package.html">package omp</A> command to enable the
-USER-OMP package, unless the "-sf omp" or "-pk omp" <A HREF = "Section_start.html#start_7">command-line
-switches</A> were used.  It specifies how many
-threads per MPI task to use, as well as other options.  Its doc page
-explains how to set the number of threads via an environment variable
-if desired.
-</P>
-<P><B>Speed-ups to expect:</B>
-</P>
-<P>Depending on which styles are accelerated, you should look for a
-reduction in the "Pair time", "Bond time", "KSpace time", and "Loop
-time" values printed at the end of a run.  
-</P>
-<P>You may see a small performance advantage (5 to 20%) when running a
-USER-OMP style (in serial or parallel) with a single thread per MPI
-task, versus running standard LAMMPS with its standard
-(un-accelerated) styles (in serial or all-MPI parallelization with 1
-task/core).  This is because many of the USER-OMP styles contain
-similar optimizations to those used in the OPT package, as described
-above.
-</P>
-<P>With multiple threads/task, the optimal choice of MPI tasks/node and
-OpenMP threads/task can vary a lot and should always be tested via
-benchmark runs for a specific simulation running on a specific
-machine, paying attention to guidelines discussed in the next
-sub-section.
-</P>
-<P>A description of the multi-threading strategy used in the USER-OMP
-package and some performance examples are <A HREF = "http://sites.google.com/site/akohlmey/software/lammps-icms/lammps-icms-tms2011-talk.pdf?attredirects=0&d=1">presented
-here</A>
-</P>
-<P><B>Guidelines for best performance:</B>
-</P>
-<P>For many problems on current generation CPUs, running the USER-OMP
-package with a single thread/task is faster than running with multiple
-threads/task.  This is because the MPI parallelization in LAMMPS is
-often more efficient than multi-threading as implemented in the
-USER-OMP package.  The parallel efficiency (in a threaded sense) also
-varies for different USER-OMP styles.
-</P>
-<P>Using multiple threads/task can be more effective under the following
-circumstances:
-</P>
-<UL><LI>Individual compute nodes have a significant number of CPU cores but
-the CPU itself has limited memory bandwidth, e.g. for 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 node
-is faster.  Running in hybrid MPI+OpenMP mode will reduce the
-inter-node communication bandwidth contention in the same way, but
-offers an additional speedup by utilizing the otherwise idle CPU
-cores. 
-
-<LI>The interconnect used for MPI communication does not provide
-sufficient bandwidth for a large number of MPI tasks per node.  For
-example, this applies to running over gigabit ethernet or on Cray XT4
-or XT5 series supercomputers.  As in the aforementioned case, this
-effect worsens when using an increasing number of nodes. 
-
-<LI>The system has a spatially inhomogeneous particle density which does
-not map well to the <A HREF = "processors.html">domain decomposition scheme</A> or
-<A HREF = "balance.html">load-balancing</A> options that LAMMPS provides.  This is
-because multi-threading achives parallelism over the number of
-particles, not via their distribution in space. 
-
-<LI>A machine is being used in "capability mode", i.e. near the point
-where MPI parallelism is maxed out.  For example, this can happen when
-using the <A HREF = "kspace_style.html">PPPM solver</A> for long-range
-electrostatics on large numbers of nodes.  The scaling of the KSpace
-calculation (see the <A HREF = "kspace_style.html">kspace_style</A> command) becomes
-the performance-limiting factor.  Using multi-threading allows less
-MPI tasks to be invoked and can speed-up the long-range solver, while
-increasing overall performance by parallelizing the pairwise and
-bonded calculations via OpenMP.  Likewise additional speedup can be
-sometimes be achived by increasing the length of the Coulombic cutoff
-and thus reducing the work done by the long-range solver.  Using the
-<A HREF = "run_style.html">run_style verlet/split</A> command, which is compatible
-with the USER-OMP package, is an alternative way to reduce the number
-of MPI tasks assigned to the KSpace calculation. 
-</UL>
-<P>Additional performance tips are as follows:
-</P>
-<UL><LI>The best parallel efficiency from <I>omp</I> styles is typically achieved
-when there is at least one MPI task per physical processor,
-i.e. socket or die. 
-
-<LI>It is usually most efficient to restrict threading to a single
-socket, i.e. use one or more MPI task per socket. 
-
-<LI>Several current MPI implementation by default use a processor affinity
-setting that restricts each MPI task to a single CPU core.  Using
-multi-threading in this mode will force the threads to share that core
-and thus is likely to be counterproductive.  Instead, binding MPI
-tasks to a (multi-core) socket, should solve this issue. 
-</UL>
-<P><B>Restrictions:</B>
-</P>
-<P>None.
-</P>
-</HTML>
--- a/doc/accelerate_omp.txt
+++ b/doc/accelerate_omp.txt
@ -1,201 +0,0 @@
-"Previous Section"_Section_packages.html - "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
-
-"Return to Section accelerate overview"_Section_accelerate.html
-
-5.3.5 USER-OMP package :h4
-
-The USER-OMP package was developed by Axel Kohlmeyer at Temple
-University.  It provides multi-threaded versions of most pair styles,
-nearly all bonded styles (bond, angle, dihedral, improper), several
-Kspace styles, and a few fix styles.  The package currently
-uses the OpenMP interface for multi-threading.
-
-Here is a quick overview of how to use the USER-OMP package:
-
-use the -fopenmp flag for compiling and linking in your Makefile.machine
-include the USER-OMP package and build LAMMPS
-use the mpirun command to set the number of MPI tasks/node
-specify how many threads per MPI task to use
-use USER-OMP styles in your input script :ul
-
-The latter two steps can be done using the "-pk omp" and "-sf omp"
-"command-line switches"_Section_start.html#start_7 respectively.  Or
-the effect of the "-pk" or "-sf" switches can be duplicated by adding
-the "package omp"_package.html or "suffix omp"_suffix.html commands
-respectively to your input script.
-
-[Required hardware/software:]
-
-Your compiler must support the OpenMP interface.  You should have one
-or more multi-core CPUs so that multiple threads can be launched by an
-MPI task running on a CPU.
-
-[Building LAMMPS with the USER-OMP package:]
-
-To do this in one line, use the src/Make.py script, described in
-"Section 2.4"_Section_start.html#start_4 of the manual.  Type "Make.py
-h" for help.  If run from the src directory, this command will create
-src/lmp_omp using src/MAKE/Makefile.mpi as the starting
-Makefile.machine:
-
-Make.py -p omp -o omp file mpi :pre
-
-Or you can follow these steps:
-
-cd lammps/src
-make yes-user-omp
-make machine :pre
-
-The CCFLAGS setting in Makefile.machine needs "-fopenmp" to add OpenMP
-support.  This works for both the GNU and Intel compilers.  Without
-this flag the USER-OMP styles will still be compiled and work, but
-will not support multi-threading.  For the Intel compilers the CCFLAGS
-setting also needs to include "-restrict".
-
-[Run with the USER-OMP package from the command line:]
-
-The mpirun or mpiexec command sets the total number of MPI tasks used
-by LAMMPS (one or multiple per compute node) and the number of MPI
-tasks used per node.  E.g. the mpirun command in MPICH does this via
-its -np and -ppn switches.  Ditto for OpenMPI via -np and -npernode.
-
-You need to choose how many threads per MPI task will be used by the
-USER-OMP package.  Note that the product of MPI tasks * threads/task
-should not exceed the physical number of cores (on a node), otherwise
-performance will suffer.
-
-Use the "-sf omp" "command-line switch"_Section_start.html#start_7,
-which will automatically append "omp" to styles that support it.  Use
-the "-pk omp Nt" "command-line switch"_Section_start.html#start_7, to
-set Nt = # of OpenMP threads per MPI task to use.
-
-lmp_machine -sf omp -pk omp 16 -in in.script                       # 1 MPI task on a 16-core node
-mpirun -np 4 lmp_machine -sf omp -pk omp 4 -in in.script           # 4 MPI tasks each with 4 threads on a single 16-core node
-mpirun -np 32 -ppn 4 lmp_machine -sf omp -pk omp 4 -in in.script   # ditto on 8 16-core nodes :pre
-
-Note that if the "-sf omp" switch is used, it also issues a default
-"package omp 0"_package.html command, which sets the number of threads
-per MPI task via the OMP_NUM_THREADS environment variable.
-
-Using the "-pk" switch explicitly allows for direct setting of the
-number of threads and additional options.  Its syntax is the same as
-the "package omp" command.  See the "package"_package.html command doc
-page for details, including the default values used for all its
-options if it is not specified, and how to set the number of threads
-via the OMP_NUM_THREADS environment variable if desired.
-
-[Or run with the USER-OMP package by editing an input script:]
-
-The discussion above for the mpirun/mpiexec command, MPI tasks/node,
-and threads/MPI task is the same.
-
-Use the "suffix omp"_suffix.html command, or you can explicitly add an
-"omp" suffix to individual styles in your input script, e.g.
-
-pair_style lj/cut/omp 2.5 :pre
-
-You must also use the "package omp"_package.html command to enable the
-USER-OMP package, unless the "-sf omp" or "-pk omp" "command-line
-switches"_Section_start.html#start_7 were used.  It specifies how many
-threads per MPI task to use, as well as other options.  Its doc page
-explains how to set the number of threads via an environment variable
-if desired.
-
-[Speed-ups to expect:]
-
-Depending on which styles are accelerated, you should look for a
-reduction in the "Pair time", "Bond time", "KSpace time", and "Loop
-time" values printed at the end of a run.  
-
-You may see a small performance advantage (5 to 20%) when running a
-USER-OMP style (in serial or parallel) with a single thread per MPI
-task, versus running standard LAMMPS with its standard
-(un-accelerated) styles (in serial or all-MPI parallelization with 1
-task/core).  This is because many of the USER-OMP styles contain
-similar optimizations to those used in the OPT package, as described
-above.
-
-With multiple threads/task, the optimal choice of MPI tasks/node and
-OpenMP threads/task can vary a lot and should always be tested via
-benchmark runs for a specific simulation running on a specific
-machine, paying attention to guidelines discussed in the next
-sub-section.
-
-A description of the multi-threading strategy used in the USER-OMP
-package 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
-
-[Guidelines for best performance:]
-
-For many problems on current generation CPUs, running the USER-OMP
-package with a single thread/task is faster than running with multiple
-threads/task.  This is because the MPI parallelization in LAMMPS is
-often more efficient than multi-threading as implemented in the
-USER-OMP package.  The parallel efficiency (in a threaded sense) also
-varies for different USER-OMP styles.
-
-Using multiple threads/task can be more 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. for 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 node
-is faster.  Running in hybrid MPI+OpenMP mode will reduce the
-inter-node communication bandwidth contention in the same way, but
-offers an additional speedup by utilizing the otherwise idle CPU
-cores. :ulb,l
-
-The interconnect used for MPI communication does not provide
-sufficient bandwidth for a large number of MPI tasks per node.  For
-example, this applies to running over gigabit ethernet or on Cray XT4
-or XT5 series supercomputers.  As in the aforementioned case, this
-effect worsens when using an increasing number of nodes. :l
-
-The system has a spatially inhomogeneous particle density which does
-not map well to the "domain decomposition scheme"_processors.html or
-"load-balancing"_balance.html options that LAMMPS provides.  This is
-because multi-threading achives parallelism over the number of
-particles, not via their distribution in space. :l
-
-A machine is being used in "capability mode", i.e. near the point
-where MPI parallelism is maxed out.  For example, this can happen when
-using the "PPPM solver"_kspace_style.html for long-range
-electrostatics on large numbers of nodes.  The scaling of the KSpace
-calculation (see the "kspace_style"_kspace_style.html command) becomes
-the performance-limiting factor.  Using multi-threading allows less
-MPI tasks to be invoked and can speed-up the long-range solver, while
-increasing overall performance by parallelizing the pairwise and
-bonded calculations via OpenMP.  Likewise additional speedup can be
-sometimes be achived by increasing the length of the Coulombic cutoff
-and thus reducing the work done by the long-range solver.  Using the
-"run_style verlet/split"_run_style.html command, which is compatible
-with the USER-OMP package, is an alternative way to reduce the number
-of MPI tasks assigned to the KSpace calculation. :l,ule
-
-Additional performance tips are as follows:
-
-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. :ulb,l
-
-It is usually most efficient to restrict threading to a single
-socket, i.e. use one or more MPI task per socket. :l
-
-Several current MPI implementation by default use a processor affinity
-setting that restricts each MPI task to a single CPU core.  Using
-multi-threading in this mode will force the threads to share that core
-and thus is likely to be counterproductive.  Instead, binding MPI
-tasks to a (multi-core) socket, should solve this issue. :l,ule
-
-[Restrictions:]
-
-None.
--- a/doc/accelerate_opt.html
+++ b/doc/accelerate_opt.html
@ -1,87 +0,0 @@
-<HTML>
-<CENTER><A HREF = "Section_packages.html">Previous Section</A> - <A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> -
-<A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A> 
-</CENTER>
-
-
-
-
-
-
-<HR>
-
-<P><A HREF = "Section_accelerate.html">Return to Section accelerate overview</A>
-</P>
-<H4>5.3.6 OPT package 
-</H4>
-<P>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.
-</P>
-<P>Here is a quick overview of how to use the OPT package:
-</P>
-<UL><LI>include the OPT package and build LAMMPS
-<LI>use OPT pair styles in your input script 
-</UL>
-<P>The last step can be done using the "-sf opt" <A HREF = "Section_start.html#start_7">command-line
-switch</A>.  Or the effect of the "-sf" switch
-can be duplicated by adding a <A HREF = "suffix.html">suffix opt</A> command to your
-input script.
-</P>
-<P><B>Required hardware/software:</B>
-</P>
-<P>None.
-</P>
-<P><B>Building LAMMPS with the OPT package:</B>
-</P>
-<P>Include the package and build LAMMPS:
-</P>
-<P>To do this in one line, use the src/Make.py script, described in
-<A HREF = "Section_start.html#start_4">Section 2.4</A> of the manual.  Type "Make.py
-h" for help.  If run from the src directory, this command will create
-src/lmp_opt using src/MAKE/Makefile.mpi as the starting
-Makefile.machine:
-</P>
-<PRE>Make.py -p opt -o opt file mpi 
-</PRE>
-<P>Or you can follow these steps:
-</P>
-<PRE>cd lammps/src
-make yes-opt
-make machine 
-</PRE>
-<P>If you are using Intel compilers, then the CCFLAGS setting in
-Makefile.machine needs to include "-restrict".
-</P>
-<P><B>Run with the OPT package from the command line:</B>
-</P>
-<P>Use the "-sf opt" <A HREF = "Section_start.html#start_7">command-line switch</A>,
-which will automatically append "opt" to styles that support it.
-</P>
-<PRE>lmp_machine -sf opt -in in.script
-mpirun -np 4 lmp_machine -sf opt -in in.script 
-</PRE>
-<P><B>Or run with the OPT package by editing an input script:</B>
-</P>
-<P>Use the <A HREF = "suffix.html">suffix opt</A> command, or you can explicitly add an
-"opt" suffix to individual styles in your input script, e.g.
-</P>
-<PRE>pair_style lj/cut/opt 2.5 
-</PRE>
-<P><B>Speed-ups to expect:</B>
-</P>
-<P>You should see a reduction in the "Pair time" value printed at the end
-of a run.  On most machines for reasonable problem sizes, it will be a
-5 to 20% savings.
-</P>
-<P><B>Guidelines for best performance:</B>
-</P>
-<P>None.  Just try out an OPT pair style to see how it performs.
-</P>
-<P><B>Restrictions:</B>
-</P>
-<P>None.
-</P>
-</HTML>
--- a/doc/accelerate_opt.txt
+++ b/doc/accelerate_opt.txt
@ -1,82 +0,0 @@
-"Previous Section"_Section_packages.html - "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
-
-"Return to Section accelerate overview"_Section_accelerate.html
-
-5.3.6 OPT package :h4
-
-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.
-
-Here is a quick overview of how to use the OPT package:
-
-include the OPT package and build LAMMPS
-use OPT pair styles in your input script :ul
-
-The last step can be done using the "-sf opt" "command-line
-switch"_Section_start.html#start_7.  Or the effect of the "-sf" switch
-can be duplicated by adding a "suffix opt"_suffix.html command to your
-input script.
-
-[Required hardware/software:]
-
-None.
-
-[Building LAMMPS with the OPT package:]
-
-Include the package and build LAMMPS:
-
-To do this in one line, use the src/Make.py script, described in
-"Section 2.4"_Section_start.html#start_4 of the manual.  Type "Make.py
-h" for help.  If run from the src directory, this command will create
-src/lmp_opt using src/MAKE/Makefile.mpi as the starting
-Makefile.machine:
-
-Make.py -p opt -o opt file mpi :pre
-
-Or you can follow these steps:
-
-cd lammps/src
-make yes-opt
-make machine :pre
-
-If you are using Intel compilers, then the CCFLAGS setting in
-Makefile.machine needs to include "-restrict".
-
-[Run with the OPT package from the command line:]
-
-Use the "-sf opt" "command-line switch"_Section_start.html#start_7,
-which will automatically append "opt" to styles that support it.
-
-lmp_machine -sf opt -in in.script
-mpirun -np 4 lmp_machine -sf opt -in in.script :pre
-
-[Or run with the OPT package by editing an input script:]
-
-Use the "suffix opt"_suffix.html command, or you can explicitly add an
-"opt" suffix to individual styles in your input script, e.g.
-
-pair_style lj/cut/opt 2.5 :pre
-
-[Speed-ups to expect:]
-
-You should see a reduction in the "Pair time" value printed at the end
-of a run.  On most machines for reasonable problem sizes, it will be a
-5 to 20% savings.
-
-[Guidelines for best performance:]
-
-None.  Just try out an OPT pair style to see how it performs.
-
-[Restrictions:]
-
-None.
--- a/doc/angle_charmm.html
+++ b/doc/angle_charmm.html
@ -1,97 +0,0 @@
-<HTML>
-<CENTER><A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> - <A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A> 
-</CENTER>
-
-
-
-
-
-
-<HR>
-
-<H3>angle_style charmm command 
-</H3>
-<H3>angle_style charmm/kk command 
-</H3>
-<H3>angle_style charmm/omp command 
-</H3>
-<P><B>Syntax:</B>
-</P>
-<PRE>angle_style charmm 
-</PRE>
-<P><B>Examples:</B>
-</P>
-<PRE>angle_style charmm
-angle_coeff 1 300.0 107.0 50.0 3.0 
-</PRE>
-<P><B>Description:</B>
-</P>
-<P>The <I>charmm</I> angle style uses the potential
-</P>
-<CENTER><IMG SRC = "Eqs/angle_charmm.jpg">
-</CENTER>
-<P>with an additional Urey_Bradley term based on the distance <I>r</I> between
-the 1st and 3rd atoms in the angle.  K, theta0, Kub, and Rub are
-coefficients defined for each angle type.
-</P>
-<P>See <A HREF = "#MacKerell">(MacKerell)</A> for a description of the CHARMM force
-field.
-</P>
-<P>The following coefficients must be defined for each angle type via the
-<A HREF = "angle_coeff.html">angle_coeff</A> command as in the example above, or in
-the data file or restart files read by the <A HREF = "read_data.html">read_data</A>
-or <A HREF = "read_restart.html">read_restart</A> commands:
-</P>
-<UL><LI>K (energy/radian^2)
-<LI>theta0 (degrees)
-<LI>K_ub (energy/distance^2)
-<LI>r_ub (distance) 
-</UL>
-<P>Theta0 is specified in degrees, but LAMMPS converts it to radians
-internally; hence the units of K are in energy/radian^2.
-</P>
-<HR>
-
-<P>Styles with a <I>cuda</I>, <I>gpu</I>, <I>intel</I>, <I>kk</I>, <I>omp</I>, or <I>opt</I> 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 <A HREF = "Section_accelerate.html">Section_accelerate</A>
-of the manual.  The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
-</P>
-<P>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively.  They are only
-enabled if LAMMPS was built with those packages.  See the <A HREF = "Section_start.html#start_3">Making
-LAMMPS</A> section for more info.
-</P>
-<P>You can specify the accelerated styles explicitly in your input script
-by including their suffix, or you can use the <A HREF = "Section_start.html#start_7">-suffix command-line
-switch</A> when you invoke LAMMPS, or you can
-use the <A HREF = "suffix.html">suffix</A> command in your input script.
-</P>
-<P>See <A HREF = "Section_accelerate.html">Section_accelerate</A> of the manual for
-more instructions on how to use the accelerated styles effectively.
-</P>
-<HR>
-
-<P><B>Restrictions:</B>
-</P>
-<P>This angle style can only be used if LAMMPS was built with the
-MOLECULE package (which it is by default).  See the <A HREF = "Section_start.html#start_3">Making
-LAMMPS</A> section for more info on packages.
-</P>
-<P><B>Related commands:</B>
-</P>
-<P><A HREF = "angle_coeff.html">angle_coeff</A>
-</P>
-<P><B>Default:</B> none
-</P>
-<HR>
-
-<A NAME = "MacKerell"></A>
-
-<P><B>(MacKerell)</B> MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field,
-Fischer, Gao, Guo, Ha, et al, J Phys Chem, 102, 3586 (1998).
-</P>
-</HTML>
--- a/doc/angle_class2.html
+++ b/doc/angle_class2.html
@ -1,126 +0,0 @@
-<HTML>
-<CENTER><A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> - <A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A> 
-</CENTER>
-
-
-
-
-
-
-<HR>
-
-<H3>angle_style class2 command 
-</H3>
-<H3>angle_style class2/omp command 
-</H3>
-<P><B>Syntax:</B>
-</P>
-<PRE>angle_style class2 
-</PRE>
-<P><B>Examples:</B>
-</P>
-<PRE>angle_style class2
-angle_coeff * 75.0
-angle_coeff 1 bb 10.5872 1.0119 1.5228
-angle_coeff * ba 3.6551 24.895 1.0119 1.5228 
-</PRE>
-<P><B>Description:</B>
-</P>
-<P>The <I>class2</I> angle style uses the potential
-</P>
-<CENTER><IMG SRC = "Eqs/angle_class2.jpg">
-</CENTER>
-<P>where Ea is the angle term, Ebb is a bond-bond term, and Eba is a
-bond-angle term.  Theta0 is the equilibrium angle and r1 and r2 are
-the equilibrium bond lengths.
-</P>
-<P>See <A HREF = "#Sun">(Sun)</A> for a description of the COMPASS class2 force field.
-</P>
-<P>Coefficients for the Ea, Ebb, and Eba formulas must be defined for
-each angle type via the <A HREF = "angle_coeff.html">angle_coeff</A> command as in
-the example above, or in the data file or restart files read by the
-<A HREF = "read_data.html">read_data</A> or <A HREF = "read_restart.html">read_restart</A>
-commands.
-</P>
-<P>These are the 4 coefficients for the Ea formula:
-</P>
-<UL><LI>theta0 (degrees)
-<LI>K2 (energy/radian^2)
-<LI>K3 (energy/radian^3)
-<LI>K4 (energy/radian^4) 
-</UL>
-<P>Theta0 is specified in degrees, but LAMMPS converts it to radians
-internally; hence the units of the various K are in per-radian.
-</P>
-<P>For the Ebb formula, each line in a <A HREF = "angle_coeff.html">angle_coeff</A>
-command in the input script lists 4 coefficients, the first of which
-is "bb" to indicate they are BondBond coefficients.  In a data file,
-these coefficients should be listed under a "BondBond Coeffs" heading
-and you must leave out the "bb", i.e. only list 3 coefficients after
-the angle type.
-</P>
-<UL><LI>bb
-<LI>M (energy/distance^2)
-<LI>r1 (distance)
-<LI>r2 (distance) 
-</UL>
-<P>For the Eba formula, each line in a <A HREF = "angle_coeff.html">angle_coeff</A>
-command in the input script lists 5 coefficients, the first of which
-is "ba" to indicate they are BondAngle coefficients.  In a data file,
-these coefficients should be listed under a "BondAngle Coeffs" heading
-and you must leave out the "ba", i.e. only list 4 coefficients after
-the angle type.
-</P>
-<UL><LI>ba
-<LI>N1 (energy/distance^2)
-<LI>N2 (energy/distance^2)
-<LI>r1 (distance)
-<LI>r2 (distance) 
-</UL>
-<P>The theta0 value in the Eba formula is not specified, since it is the
-same value from the Ea formula.
-</P>
-<HR>
-
-<P>Styles with a <I>cuda</I>, <I>gpu</I>, <I>intel</I>, <I>kk</I>, <I>omp</I>, or <I>opt</I> 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 <A HREF = "Section_accelerate.html">Section_accelerate</A>
-of the manual.  The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
-</P>
-<P>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively.  They are only
-enabled if LAMMPS was built with those packages.  See the <A HREF = "Section_start.html#start_3">Making
-LAMMPS</A> section for more info.
-</P>
-<P>You can specify the accelerated styles explicitly in your input script
-by including their suffix, or you can use the <A HREF = "Section_start.html#start_7">-suffix command-line
-switch</A> when you invoke LAMMPS, or you can
-use the <A HREF = "suffix.html">suffix</A> command in your input script.
-</P>
-<P>See <A HREF = "Section_accelerate.html">Section_accelerate</A> of the manual for
-more instructions on how to use the accelerated styles effectively.
-</P>
-<HR>
-
-<P><B>Restrictions:</B>
-</P>
-<P>This angle style can only be used if LAMMPS was built with the CLASS2
-package.  See the <A HREF = "Section_start.html#start_3">Making LAMMPS</A> section
-for more info on packages.
-</P>
-<P><B>Related commands:</B>
-</P>
-<P><A HREF = "angle_coeff.html">angle_coeff</A>
-</P>
-<P><B>Default:</B> none
-</P>
-<HR>
-
-<A NAME = "Sun"></A>
-
-<P><B>(Sun)</B> Sun, J Phys Chem B 102, 7338-7364 (1998).
-</P>
-</HTML>
--- a/doc/angle_coeff.html
+++ b/doc/angle_coeff.html
@ -1,104 +0,0 @@
-<HTML>
-<CENTER><A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> - <A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A> 
-</CENTER>
-
-
-
-
-
-
-<HR>
-
-<H3>angle_coeff command 
-</H3>
-<P><B>Syntax:</B>
-</P>
-<PRE>angle_coeff N args 
-</PRE>
-<UL><LI>N = angle type (see asterisk form below)
-<LI>args = coefficients for one or more angle types 
-</UL>
-<P><B>Examples:</B>
-</P>
-<PRE>angle_coeff 1 300.0 107.0
-angle_coeff * 5.0
-angle_coeff 2*10 5.0 
-</PRE>
-<P><B>Description:</B>
-</P>
-<P>Specify the angle force field coefficients for one or more angle types.
-The number and meaning of the coefficients depends on the angle style.
-Angle coefficients can also be set in the data file read by the
-<A HREF = "read_data.html">read_data</A> command or in a restart file.
-</P>
-<P>N 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 coefficients for multiple angle types.  This takes the
-form "*" or "*n" or "n*" or "m*n".  If N = the number of angle 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).
-</P>
-<P>Note that using an angle_coeff command can override a previous setting
-for the same angle type.  For example, these commands set the coeffs
-for all angle types, then overwrite the coeffs for just angle type 2:
-</P>
-<PRE>angle_coeff * 200.0 107.0 1.2
-angle_coeff 2 50.0 107.0 
-</PRE>
-<P>A line in a data file that specifies angle coefficients uses the exact
-same format as the arguments of the angle_coeff command in an input
-script, except that wild-card asterisks should not be used since
-coefficients for all N types must be listed in the file.  For example,
-under the "Angle Coeffs" section of a data file, the line that
-corresponds to the 1st example above would be listed as
-</P>
-<PRE>1 300.0 107.0 
-</PRE>
-<P>The <A HREF = "angle_class2.html">angle_style class2</A> is an exception to this
-rule, in that an additional argument is used in the input script to
-allow specification of the cross-term coefficients.   See its
-doc page for details.
-</P>
-<HR>
-
-<P>Here is an alphabetic list of angle styles defined in LAMMPS.  Click on
-the style to display the formula it computes and coefficients
-specified by the associated <A HREF = "angle_coeff.html">angle_coeff</A> command.
-</P>
-<P>Note that 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 <A HREF = "Section_commands.html#cmd_5">this
-page</A>.
-</P>
-<UL><LI><A HREF = "angle_none.html">angle_style none</A> - turn off angle interactions
-<LI><A HREF = "angle_hybrid.html">angle_style hybrid</A> - define multiple styles of angle interactions 
-</UL>
-<UL><LI><A HREF = "angle_charmm.html">angle_style charmm</A> - CHARMM angle
-<LI><A HREF = "angle_class2.html">angle_style class2</A> - COMPASS (class 2) angle
-<LI><A HREF = "angle_cosine.html">angle_style cosine</A> - cosine angle potential
-<LI><A HREF = "angle_cosine_delta.html">angle_style cosine/delta</A> - difference of cosines angle potential
-<LI><A HREF = "angle_cosine_periodic.html">angle_style cosine/periodic</A> - DREIDING angle
-<LI><A HREF = "angle_cosine_squared.html">angle_style cosine/squared</A> - cosine squared angle potential
-<LI><A HREF = "angle_harmonic.html">angle_style harmonic</A> - harmonic angle
-<LI><A HREF = "angle_table.html">angle_style table</A> - tabulated by angle 
-</UL>
-<HR>
-
-<P><B>Restrictions:</B>
-</P>
-<P>This command must come after the simulation box is defined by a
-<A HREF = "read_data.html">read_data</A>, <A HREF = "read_restart.html">read_restart</A>, or
-<A HREF = "create_box.html">create_box</A> command.
-</P>
-<P>An angle style must be defined before any angle coefficients are
-set, either in the input script or in a data file.
-</P>
-<P><B>Related commands:</B>
-</P>
-<P><A HREF = "angle_style.html">angle_style</A>
-</P>
-<P><B>Default:</B> none
-</P>
-</HTML>
--- a/doc/angle_cosine.html
+++ b/doc/angle_cosine.html
@ -1,77 +0,0 @@
-<HTML>
-<CENTER><A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> - <A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A> 
-</CENTER>
-
-
-
-
-
-
-<HR>
-
-<H3>angle_style cosine command 
-</H3>
-<H3>angle_style cosine/omp command 
-</H3>
-<P><B>Syntax:</B>
-</P>
-<PRE>angle_style cosine 
-</PRE>
-<P><B>Examples:</B>
-</P>
-<PRE>angle_style cosine
-angle_coeff * 75.0 
-</PRE>
-<P><B>Description:</B>
-</P>
-<P>The <I>cosine</I> angle style uses the potential
-</P>
-<CENTER><IMG SRC = "Eqs/angle_cosine.jpg">
-</CENTER>
-<P>where K is defined for each angle type.
-</P>
-<P>The following coefficients must be defined for each angle type via the
-<A HREF = "angle_coeff.html">angle_coeff</A> command as in the example above, or in
-the data file or restart files read by the <A HREF = "read_data.html">read_data</A>
-or <A HREF = "read_restart.html">read_restart</A> commands:
-</P>
-<UL><LI>K (energy) 
-</UL>
-<HR>
-
-<P>Styles with a <I>cuda</I>, <I>gpu</I>, <I>intel</I>, <I>kk</I>, <I>omp</I>, or <I>opt</I> 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 <A HREF = "Section_accelerate.html">Section_accelerate</A>
-of the manual.  The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
-</P>
-<P>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
-KOKKOS, USER-OMP and OPT packages, respectively.  They are only
-enabled if LAMMPS was built with those packages.  See the <A HREF = "Section_start.html#start_3">Making
-LAMMPS</A> section for more info.
-</P>
-<P>You can specify the accelerated styles explicitly in your input script
-by including their suffix, or you can use the <A HREF = "Section_start.html#start_7">-suffix command-line
-switch</A> when you invoke LAMMPS, or you can
-use the <A HREF = "suffix.html">suffix</A> command in your input script.
-</P>
-<P>See <A HREF = "Section_accelerate.html">Section_accelerate</A> of the manual for
-more instructions on how to use the accelerated styles effectively.
-</P>
-<HR>
-
-<P><B>Restrictions:</B>
-</P>
-<P>This angle style can only be used if LAMMPS was built with the
-MOLECULE package (which it is by default).  See the <A HREF = "Section_start.html#start_3">Making
-LAMMPS</A> section for more info on packages.
-</P>
-<P><B>Related commands:</B>
-</P>
-<P><A HREF = "angle_coeff.html">angle_coeff</A>
-</P>
-<P><B>Default:</B> none
-</P>
-</HTML>
--- a/Show More
+++ b/Show More