jianmu
/
lammps
forked from lijiext/lammps
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge branch 'master' of github.com:lammps/lammps

This commit is contained in:
Michele Ceriotti 2016-11-19 23:25:51 +01:00
parent 0229556b03 4b51719e67
commit b11f376a4f
6278 changed files with 1642172 additions and 580279 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
.gitignore vendored Normal file
View File

@ -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

2
bench/Cu_u3.eam
View File

@ -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

2
bench/POTENTIALS/in.dpd
View File

@ -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

67
bench/log.15May15.chain.fixed.icc.1
View File

@ -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

67
bench/log.15May15.chain.fixed.icc.4
View File

@ -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

83
bench/log.15May15.chain.scaled.icc.4
View File

@ -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

69
bench/log.15May15.chute.fixed.icc.1
View File

@ -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

69
bench/log.15May15.chute.fixed.icc.4
View File

@ -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

79
bench/log.15May15.chute.scaled.icc.4
View File

@ -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

71
bench/log.15May15.eam.fixed.icc.1
View File

@ -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

71
bench/log.15May15.eam.fixed.icc.4
View File

@ -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

71
bench/log.15May15.eam.scaled.icc.4
View File

@ -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

68
bench/log.15May15.lj.fixed.icc.1
View File

@ -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

68
bench/log.15May15.lj.fixed.icc.4
View File

@ -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

68
bench/log.15May15.lj.scaled.icc.4
View File

@ -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

110
bench/log.15May15.rhodo.fixed.icc.1
View File

@ -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

110
bench/log.15May15.rhodo.fixed.icc.4
View File

@ -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

131
bench/log.15May15.rhodo.scaled.icc.4
View File

@ -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

78
bench/log.6Oct16.chain.fixed.icc.1 Normal file
View File

@ -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

78
bench/log.6Oct16.chain.fixed.icc.4 Normal file
View File

@ -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

94
bench/log.6Oct16.chain.scaled.icc.4 Normal file
View File

@ -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

80
bench/log.6Oct16.chute.fixed.icc.1 Normal file
View File

@ -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

80
bench/log.6Oct16.chute.fixed.icc.4 Normal file
View File

@ -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

90
bench/log.6Oct16.chute.scaled.icc.4 Normal file
View File

@ -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

83
bench/log.6Oct16.eam.fixed.icc.1 Normal file
View File

@ -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

83
bench/log.6Oct16.eam.fixed.icc.4 Normal file
View File

@ -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

83
bench/log.6Oct16.eam.scaled.icc.4 Normal file
View File

@ -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

79
bench/log.6Oct16.lj.fixed.icc.1 Normal file
View File

@ -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

79
bench/log.6Oct16.lj.fixed.icc.4 Normal file
View File

@ -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

79
bench/log.6Oct16.lj.scaled.icc.4 Normal file
View File

@ -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

122
bench/log.6Oct16.rhodo.fixed.icc.1 Normal file
View File

@ -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

122
bench/log.6Oct16.rhodo.fixed.icc.4 Normal file
View File

@ -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

143
bench/log.6Oct16.rhodo.scaled.icc.4 Normal file
View File

@ -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

5
doc/.gitignore vendored Normal file
View File

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

BIN
doc/Developer.pdf
View File

Binary file not shown.

BIN
doc/Eqs/dihedral_sign.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 19 KiB

BIN
doc/Eqs/fix_nh1.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 30 KiB

BIN
doc/Eqs/fix_ti_rs_force.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 1.7 KiB

11
doc/Eqs/fix_ti_rs_force.tex
View File

@ -1,11 +0,0 @@
\documentclass[12pt]{article}
\usepackage{amsmath}
\begin{document}
$$
F_{\text{total}} = \lambda F_{\text{int}}
$$
\end{document}

BIN
doc/Eqs/fix_ti_rs_function_1.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 2.5 KiB

9
doc/Eqs/fix_ti_rs_function_1.tex
View File

@ -1,9 +0,0 @@
\documentclass[12pt]{article}
\begin{document}
$$
\lambda(\tau) = \lambda_i + \tau \left( \lambda_f - \lambda_i \right)
$$
\end{document}

BIN
doc/Eqs/fix_ti_rs_function_2.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 3.2 KiB

9
doc/Eqs/fix_ti_rs_function_2.tex
View File

@ -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}

BIN
doc/Eqs/fix_ti_rs_function_3.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 4.7 KiB

9
doc/Eqs/fix_ti_rs_function_3.tex
View File

@ -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}

BIN
doc/Eqs/fix_ti_spring_force.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 3.5 KiB

11
doc/Eqs/fix_ti_spring_force.tex
View File

@ -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}

BIN
doc/Eqs/fix_ti_spring_function_1.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 1.0 KiB

BIN
doc/Eqs/fix_ti_spring_function_2.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 5.6 KiB

13
doc/Eqs/improper_umbrella.tex
View File

@ -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}

BIN
doc/Eqs/pressure.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 4.0 KiB

9
doc/Eqs/pressure.tex
View File

@ -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}

BIN
doc/Eqs/pressure_tensor.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 4.9 KiB

145
doc/Makefile Normal file
View File

@ -0,0 +1,145 @@
# 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
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
# ------------------------------------------
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"
# ------------------------------------------
clean-all:
rm -rf $(BUILDDIR)/* utils/txt2html/txt2html.exe
clean:
rm -rf $(RSTDIR)
html: $(OBJECTS)
@(\
. $(VENV)/bin/activate ;\
cp -r src/* $(RSTDIR)/ ;\
sphinx-build -j 8 -b html -c utils/sphinx-config -d $(BUILDDIR)/doctrees $(RSTDIR) html ;\
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."
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
# ------------------------------------------
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; \
pip install sphinxcontrib-images; \
deactivate;\
)
$(TXT2RST): $(VENV)
@( \
. $(VENV)/bin/activate; \
(cd utils/converters;\
python setup.py develop);\
deactivate;\
)

428
doc/Manual.html
View File

@ -1,428 +0,0 @@
<HTML>
<HEAD>
<TITLE>LAMMPS Users Manual</TITLE>
<META NAME="docnumber" CONTENT="2 Jul 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>2 Jul 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>
6.25 <A HREF = "howto_25">Adiabatic core/shell model</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>

BIN
doc/Manual.pdf
View File

Binary file not shown.

BIN
doc/PDF/colvars-refman-lammps.pdf
View File

Binary file not shown.

115
doc/README Normal file
View File

@ -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

89
doc/Scripts/correlate.py
View File

@ -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

401
doc/Section_accelerate.html
View File

@ -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>

397
doc/Section_accelerate.txt
View File

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

656
doc/Section_commands.html
View File

@ -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>

1024
doc/Section_commands.txt
View File

File diff suppressed because it is too large Load Diff

11168
doc/Section_errors.html
View File

File diff suppressed because it is too large Load Diff

126
doc/Section_example.html
View File

@ -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>

119
doc/Section_example.txt
View File

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

129
doc/Section_history.html
View File

@ -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>

2653
doc/Section_howto.html
View File

File diff suppressed because it is too large Load Diff

550
doc/Section_intro.html
View File

@ -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>

789
doc/Section_modify.html
View File

@ -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>

590
doc/Section_packages.html
View File

@ -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>

575
doc/Section_packages.txt
View File

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

84
doc/Section_perf.html
View File

@ -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>

77
doc/Section_perf.txt
View File

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

792
doc/Section_python.html
View File

@ -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>

1864
doc/Section_start.html
View File

File diff suppressed because it is too large Load Diff

572
doc/Section_tools.html
View File

@ -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>

228
doc/accelerate_cuda.html
View File

@ -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>

223
doc/accelerate_cuda.txt
View File

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

257
doc/accelerate_gpu.html
View File

@ -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>

352
doc/accelerate_intel.html
View File

@ -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>

347
doc/accelerate_intel.txt
View File

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

514
doc/accelerate_kokkos.html
View File

@ -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>

509
doc/accelerate_kokkos.txt
View File

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

206
doc/accelerate_omp.html
View File

@ -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>

201
doc/accelerate_omp.txt
View File

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

87
doc/accelerate_opt.html
View File

@ -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>

82
doc/accelerate_opt.txt
View File

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

97
doc/angle_charmm.html
View File

@ -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>

126
doc/angle_class2.html
View File

@ -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>

104
doc/angle_coeff.html
View File

@ -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>

77
doc/angle_cosine.html
View File

@ -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>

83
doc/angle_cosine_delta.html
View File

@ -1,83 +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/delta command
</H3>
<H3>angle_style cosine/delta/omp command
</H3>
<P><B>Syntax:</B>
</P>
<PRE>angle_style cosine/delta
</PRE>
<P><B>Examples:</B>
</P>
<PRE>angle_style cosine/delta
angle_coeff 2*4 75.0 100.0
</PRE>
<P><B>Description:</B>
</P>
<P>The <I>cosine/delta</I> angle style uses the potential
</P>
<CENTER><IMG SRC = "Eqs/angle_cosine_delta.jpg">
</CENTER>
<P>where theta0 is the equilibrium value of the angle, and K is a
prefactor. Note that the usual 1/2 factor is included in K.
</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)
<LI>theta0 (degrees)
</UL>
<P>Theta0 is specified in degrees, but LAMMPS converts it to radians
internally.
</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>, <A HREF = "angle_cosine_squared.html">angle_style
cosine/squared</A>
</P>
<P><B>Default:</B> none
</P>
</HTML>

97
doc/angle_cosine_periodic.html
View File

@ -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 cosine/periodic command
</H3>
<H3>angle_style cosine/periodic/omp command
</H3>
<P><B>Syntax:</B>
</P>
<PRE>angle_style cosine/periodic
</PRE>
<P><B>Examples:</B>
</P>
<PRE>angle_style cosine/periodic
angle_coeff * 75.0 1 6
</PRE>
<P><B>Description:</B>
</P>
<P>The <I>cosine/periodic</I> angle style uses the following potential, which
is commonly used in the <A HREF = "Section_howto.html#howto_4">DREIDING</A> force
field, particularly for organometallic systems where <I>n</I> = 4 might be
used for an octahedral complex and <I>n</I> = 3 might be used for a
trigonal center:
</P>
<CENTER><IMG SRC = "Eqs/angle_cosine_periodic.jpg">
</CENTER>
<P>where C, B and n are coefficients defined for each angle type.
</P>
<P>See <A HREF = "#Mayo">(Mayo)</A> for a description of the DREIDING 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>C (energy)
<LI>B = 1 or -1
<LI>n = 1, 2, 3, 4, 5 or 6 for periodicity
</UL>
<P>Note that the prefactor C is specified and not the overall force
constant K = C / n^2. When B = 1, it leads to a minimum for the
linear geometry. When B = -1, it leads to a maximum for the linear
geometry.
</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 = "Mayo"></A>
<P><B>(Mayo)</B> Mayo, Olfason, Goddard III, J Phys Chem, 94, 8897-8909
(1990).
</P>
</HTML>

81
doc/angle_cosine_shift.html
View File

@ -1,81 +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/shift command
</H3>
<H3>angle_style cosine/shift/omp command
</H3>
<P><B>Syntax:</B>
</P>
<PRE>angle_style cosine/shift
</PRE>
<P><B>Examples:</B>
</P>
<PRE>angle_style cosine/shift
angle_coeff * 10.0 45.0
</PRE>
<P><B>Description:</B>
</P>
<P>The <I>cosine/shift</I> angle style uses the potential
</P>
<CENTER><IMG SRC = "Eqs/angle_cosine_shift.jpg">
</CENTER>
<P>where theta0 is the equilibrium angle. The potential is bounded
between -Umin and zero. In the neighborhood of the minimum E=- Umin +
Umin/4(theta-theta0)^2 hence the spring constant is umin/2.
</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>umin (energy)
<LI>theta (angle)
</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
USER-MISC 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>,
<A HREF = "angle_cosineshiftexp.html">angle_cosineshiftexp</A>
</P>
<P><B>Default:</B> none
</P>
</HTML>

94
doc/angle_cosine_shift_exp.html
View File

@ -1,94 +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/shift/exp command
</H3>
<H3>angle_style cosine/shift/exp/omp command
</H3>
<P><B>Syntax:</B>
</P>
<PRE>angle_style cosine/shift/exp
</PRE>
<P><B>Examples:</B>
</P>
<PRE>angle_style cosine/shift/exp
angle_coeff * 10.0 45.0 2.0
</PRE>
<P><B>Description:</B>
</P>
<P>The <I>cosine/shift/exp</I> angle style uses the potential
</P>
<CENTER><IMG SRC = "Eqs/angle_cosine_shift_exp.jpg">
</CENTER>
<P>where Umin, theta, and a are defined for each angle type.
</P>
<P>The potential is bounded between [-Umin:0] and the minimum is
located at the angle theta0. The a parameter can be both positive or
negative and is used to control the spring constant at the
equilibrium.
</P>
<P>The spring constant is given by k = A exp(A) Umin / [2 (Exp(a)-1)].
For a > 3, k/Umin = a/2 to better than 5% relative error. For negative
values of the a parameter, the spring constant is essentially zero,
and anharmonic terms takes over. The potential is furthermore well
behaved in the limit a -> 0, where it has been implemented to linear
order in a for a < 0.001. In this limit the potential reduces to the
cosineshifted potential.
</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>umin (energy)
<LI>theta (angle)
<LI>A (real number)
</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
USER-MISC 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>,
<A HREF = "angle_cosineshift.html">angle_cosineshift</A>,
<A HREF = "dihedral_cosineshift.html">dihedral_cosineshift</A>
</P>
<P><B>Default:</B> none
</P>
</HTML>

82
doc/angle_cosine_squared.html
View File

@ -1,82 +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/squared command
</H3>
<H3>angle_style cosine/squared/omp command
</H3>
<P><B>Syntax:</B>
</P>
<PRE>angle_style cosine/squared
</PRE>
<P><B>Examples:</B>
</P>
<PRE>angle_style cosine/squared
angle_coeff 2*4 75.0 100.0
</PRE>
<P><B>Description:</B>
</P>
<P>The <I>cosine/squared</I> angle style uses the potential
</P>
<CENTER><IMG SRC = "Eqs/angle_cosine_squared.jpg">
</CENTER>
<P>where theta0 is the equilibrium value of the angle, and K is a
prefactor. Note that the usual 1/2 factor is included in K.
</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)
<LI>theta0 (degrees)
</UL>
<P>Theta0 is specified in degrees, but LAMMPS converts it to radians
internally.
</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>
</HTML>

130
doc/angle_dipole.html
View File

@ -1,130 +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 dipole command
</H3>
<H3>angle_style dipole/omp command
</H3>
<P><B>Syntax:</B>
</P>
<PRE>angle_style dipole
</PRE>
<P><B>Examples:</B>
</P>
<PRE>angle_style dipole
angle_coeff 6 2.1 180.0
</PRE>
<P><B>Description:</B>
</P>
<P>The <I>dipole</I> angle style is used to control the orientation of a dipolar
atom within a molecule <A HREF = "#Orsi">(Orsi)</A>. Specifically, the <I>dipole</I> angle
style restrains the orientation of a point dipole mu_j (embedded in atom
'j') with respect to a reference (bond) vector r_ij = r_i - r_j, where 'i'
is another atom of the same molecule (typically, 'i' and 'j' are also
covalently bonded).
</P>
<P>It is convenient to define an angle gamma between the 'free' vector mu_j
and the reference (bond) vector r_ij:
</P>
<CENTER><IMG SRC = "Eqs/angle_dipole_gamma.jpg">
</CENTER>
<P>The <I>dipole</I> angle style uses the potential:
</P>
<CENTER><IMG SRC = "Eqs/angle_dipole_potential.jpg">
</CENTER>
<P>where K is a rigidity constant and gamma0 is an equilibrium (reference)
angle.
</P>
<P>The torque on the dipole can be obtained by differentiating the
potential using the 'chain rule' as in appendix C.3 of
<A HREF = "#Allen">(Allen)</A>:
</P>
<CENTER><IMG SRC = "Eqs/angle_dipole_torque.jpg">
</CENTER>
<P>Example: if gamma0 is set to 0 degrees, the torque generated by
the potential will tend to align the dipole along the reference
direction defined by the (bond) vector r_ij (in other words, mu_j is
restrained to point towards atom 'i').
</P>
<P>Note that the angle dipole potential does not give rise to any force,
because it does not depend on the distance between i and j (it only
depends on the angle between mu_j and r_ij).
</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)
<LI>gamma0 (degrees)
</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_6">-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>
<P><B>Restrictions:</B>
</P>
<P>This angle style can only be used if LAMMPS was built with the
USER-MISC package. See the <A HREF = "Section_start.html#2_3">Making LAMMPS</A>
section for more info on packages.
</P>
<P>IMPORTANT NOTE: In the "Angles" section of the data file, the atom ID
'j' corresponding to the dipole to restrain must come before the atom
ID of the reference atom 'i'. A third atom ID 'k' must also be
provided, although 'k' is just a 'dummy' atom which can be any atom;
it may be useful to choose a convention (e.g., 'k'='i') and adhere to
it. For example, if ID=1 for the dipolar atom to restrain, and ID=2
for the reference atom, the corresponding line in the "Angles" section
of the data file would read: X X 1 2 2
</P>
<P>The "newton" command for intramolecular interactions must be "on"
(which is the default).
</P>
<P>This angle style should not be used with SHAKE.
</P>
<P><B>Related commands:</B>
</P>
<P><A HREF = "angle_coeff.html">angle_coeff</A>, <A HREF = "angle_hybrid.html">angle_hybrid</A>
</P>
<P><B>Default:</B> none
</P>
<HR>
<A NAME = "Orsi"></A>
<P><B>(Orsi)</B> Orsi & Essex, The ELBA force field for coarse-grain modeling of
lipid membranes, PloS ONE 6(12): e28637, 2011.
</P>
<A NAME = "Allen"></A>
<P><B>(Allen)</B> Allen & Tildesley, Computer Simulation of Liquids,
Clarendon Press, Oxford, 1987.
</P>
</HTML>

122
doc/angle_dipole.txt
View File

@ -1,122 +0,0 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
angle_style dipole command :h3
angle_style dipole/omp command :h3
[Syntax:]
angle_style dipole :pre
[Examples:]
angle_style dipole
angle_coeff 6 2.1 180.0 :pre
[Description:]
The {dipole} angle style is used to control the orientation of a dipolar
atom within a molecule "(Orsi)"_#Orsi. Specifically, the {dipole} angle
style restrains the orientation of a point dipole mu_j (embedded in atom
'j') with respect to a reference (bond) vector r_ij = r_i - r_j, where 'i'
is another atom of the same molecule (typically, 'i' and 'j' are also
covalently bonded).
It is convenient to define an angle gamma between the 'free' vector mu_j
and the reference (bond) vector r_ij:
:c,image(Eqs/angle_dipole_gamma.jpg)
The {dipole} angle style uses the potential:
:c,image(Eqs/angle_dipole_potential.jpg)
where K is a rigidity constant and gamma0 is an equilibrium (reference)
angle.
The torque on the dipole can be obtained by differentiating the
potential using the 'chain rule' as in appendix C.3 of
"(Allen)"_#Allen:
:c,image(Eqs/angle_dipole_torque.jpg)
Example: if gamma0 is set to 0 degrees, the torque generated by
the potential will tend to align the dipole along the reference
direction defined by the (bond) vector r_ij (in other words, mu_j is
restrained to point towards atom 'i').
Note that the angle dipole potential does not give rise to any force,
because it does not depend on the distance between i and j (it only
depends on the angle between mu_j and r_ij).
The following coefficients must be defined for each angle type via the
"angle_coeff"_angle_coeff.html command as in the example above, or in
the data file or restart files read by the "read_data"_read_data.html
or "read_restart"_read_restart.html commands:
K (energy)
gamma0 (degrees) :ul
:line
Styles with a {cuda}, {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section_accelerate"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
KOKKOS, USER-OMP and OPT packages, respectively. They are only
enabled if LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section_accelerate"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
USER-MISC package. See the "Making LAMMPS"_Section_start.html#2_3
section for more info on packages.
IMPORTANT NOTE: In the "Angles" section of the data file, the atom ID
'j' corresponding to the dipole to restrain must come before the atom
ID of the reference atom 'i'. A third atom ID 'k' must also be
provided, although 'k' is just a 'dummy' atom which can be any atom;
it may be useful to choose a convention (e.g., 'k'='i') and adhere to
it. For example, if ID=1 for the dipolar atom to restrain, and ID=2
for the reference atom, the corresponding line in the "Angles" section
of the data file would read: X X 1 2 2
The "newton" command for intramolecular interactions must be "on"
(which is the default).
This angle style should not be used with SHAKE.
[Related commands:]
"angle_coeff"_angle_coeff.html, "angle_hybrid"_angle_hybrid.html
[Default:] none
:line
:link(Orsi)
[(Orsi)] Orsi & Essex, The ELBA force field for coarse-grain modeling of
lipid membranes, PloS ONE 6(12): e28637, 2011.
:link(Allen)
[(Allen)] Allen & Tildesley, Computer Simulation of Liquids,
Clarendon Press, Oxford, 1987.

78
doc/angle_fourier.html
View File

@ -1,78 +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 fourier command
</H3>
<H3>angle_style fourier/omp command
</H3>
<P><B>Syntax:</B>
</P>
<PRE>angle_style fourier
</PRE>
<P><B>Examples:</B>
</P>
<P>angle_style fourier
angle_coeff 75.0 1.0 1.0 1.0
</P>
<P><B>Description:</B>
</P>
<P>The <I>fourier</I> angle style uses the potential
</P>
<CENTER><IMG SRC = "Eqs/angle_fourier.jpg">
</CENTER>
<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)
<LI>C0 (real)
<LI>C1 (real)
<LI>C2 (real)
</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
USER_MISC 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>
</HTML>

Some files were not shown because too many files have changed in this diff Show More