Merge branch 'master' into lammps-icms

Resolved Conflicts:
	doc/Eqs/pair_coul_diel.jpg
	doc/Section_commands.html
	doc/Section_commands.txt
	doc/pair_coul_diel.html
	doc/pair_coul_diel.txt
	doc/processors.html
	doc/processors.txt
	examples/USER/imd/bucky_cnt_imd.vmd
	examples/USER/imd/in.bucky-plus-cnt
	examples/USER/imd/in.deca-ala-solv_imd
	examples/USER/imd/in.deca-ala_imd
	lib/gpu/Makefile.fermi
	lib/gpu/Makefile.lincoln
	lib/gpu/Makefile.longhorn
	lib/gpu/Makefile.serial
	lib/gpu/geryon/VERSION.txt
	lib/gpu/pair_gpu_device.cpp
	src/ASPHERE/atom_vec_ellipsoid.cpp
	src/CLASS2/Install.sh
	src/COLLOID/atom_vec_colloid.cpp
	src/DIPOLE/atom_vec_dipole.cpp
	src/GPU/fix_gpu.cpp
	src/GRANULAR/atom_vec_granular.cpp
	src/GRANULAR/fix_pour.h
	src/KSPACE/Install.sh
	src/KSPACE/fft3d.cpp
	src/KSPACE/fft3d.h
	src/KSPACE/kissfft.h
	src/KSPACE/pppm.cpp
	src/KSPACE/pppm.h
	src/KSPACE/pppm_tip4p.cpp
	src/MAKE/Makefile.openmpi
	src/MAKE/Makefile.serial
	src/MANYBODY/pair_airebo.cpp
	src/MANYBODY/pair_comb.cpp
	src/MANYBODY/pair_eam.cpp
	src/MANYBODY/pair_eim.cpp
	src/MANYBODY/pair_sw.cpp
	src/MANYBODY/pair_tersoff.cpp
	src/MANYBODY/pair_tersoff_zbl.cpp
	src/MOLECULE/atom_vec_angle.cpp
	src/MOLECULE/atom_vec_bond.cpp
	src/MOLECULE/atom_vec_full.cpp
	src/MOLECULE/atom_vec_molecular.cpp
	src/Makefile
	src/Makefile.lib
	src/PERI/atom_vec_peri.cpp
	src/USER-CG-CMM/Install.sh
	src/USER-IMD/README
	src/USER-IMD/fix_imd.cpp
	src/USER-IMD/fix_imd.h
	src/USER-SMD/Install.sh
	src/atom_vec_atomic.cpp
	src/atom_vec_charge.cpp
	src/comm.cpp
	src/finish.cpp
	src/fix_box_relax.cpp
	src/fix_deposit.cpp
	src/fix_spring_self.cpp
	src/fix_store_state.cpp
	src/fix_wall.cpp
	src/fix_wall_reflect.cpp
	src/input.cpp
	src/input.h
	src/memory.cpp
	src/memory.h
	src/pair_lj_cut.cpp
	tools/restart2data.cpp
This commit is contained in:
Axel Kohlmeyer
2011-12-31 19:07:46 -05:00
2579 changed files with 905870 additions and 99854 deletions

1
README
View File

@ -39,3 +39,4 @@ Point your browser at any of these files to get started:
doc/Manual.html the LAMMPS manual
doc/Section_intro.html hi-level introduction to LAMMPS
doc/Section_start.html how to build and use LAMMPS
doc/Developer.pdf LAMMPS developer guide

View File

@ -2,7 +2,7 @@
# chute flow of 32000 atoms with frozen base at 26 degrees
units lj
atom_style granular
atom_style sphere
boundary p p fs
newton off
communicate single vel yes

View File

@ -5,7 +5,7 @@ variable x index 1
variable y index 1
units lj
atom_style granular
atom_style sphere
boundary p p fs
newton off
communicate single vel yes

View File

@ -1,4 +1,4 @@
LAMMPS (10 Sep 2010)
LAMMPS (27 Mar 2011)
# FENE beadspring benchmark
units lj
@ -32,18 +32,18 @@ thermo 100
timestep 0.012
run 100
Memory usage per processor = 8.37288 Mbytes
Memory usage per processor = 11.3536 Mbytes
Step Temp E_pair E_mol TotEng Press
0 0.97029772 0.44484087 20.494523 22.394765 4.6721833
100 0.9729966 0.4361122 20.507698 22.40326 4.6548819
Loop time of 1.88908 on 1 procs for 100 steps with 32000 atoms
Loop time of 1.87328 on 1 procs for 100 steps with 32000 atoms
Pair time (%) = 0.444468 (23.5283)
Bond time (%) = 0.293589 (15.5413)
Neigh time (%) = 0.685171 (36.27)
Comm time (%) = 0.0576162 (3.04996)
Outpt time (%) = 0.000181913 (0.00962972)
Other time (%) = 0.408057 (21.6008)
Pair time (%) = 0.438668 (23.4171)
Bond time (%) = 0.289005 (15.4277)
Neigh time (%) = 0.679554 (36.2761)
Comm time (%) = 0.0552287 (2.94823)
Outpt time (%) = 0.00018096 (0.00966003)
Other time (%) = 0.410646 (21.9212)
Nlocal: 32000 ave 32000 max 32000 min
Histogram: 1 0 0 0 0 0 0 0 0 0

View File

@ -1,4 +1,4 @@
LAMMPS (10 Sep 2010)
LAMMPS (27 Mar 2011)
# FENE beadspring benchmark
units lj
@ -32,18 +32,18 @@ thermo 100
timestep 0.012
run 100
Memory usage per processor = 3.56846 Mbytes
Memory usage per processor = 4.80505 Mbytes
Step Temp E_pair E_mol TotEng Press
0 0.97029772 0.44484087 20.494523 22.394765 4.6721833
100 0.97145835 0.43803883 20.502691 22.397872 4.626988
Loop time of 0.437537 on 4 procs for 100 steps with 32000 atoms
Loop time of 0.436674 on 4 procs for 100 steps with 32000 atoms
Pair time (%) = 0.0835259 (19.09)
Bond time (%) = 0.0587637 (13.4306)
Neigh time (%) = 0.158699 (36.2711)
Comm time (%) = 0.0484382 (11.0707)
Outpt time (%) = 0.000112474 (0.0257062)
Other time (%) = 0.0879969 (20.1119)
Pair time (%) = 0.0835696 (19.1378)
Bond time (%) = 0.0588097 (13.4677)
Neigh time (%) = 0.157872 (36.1532)
Comm time (%) = 0.047663 (10.915)
Outpt time (%) = 9.69768e-05 (0.0222081)
Other time (%) = 0.0886627 (20.3041)
Nlocal: 8000 ave 8030 max 7974 min
Histogram: 1 0 0 1 0 1 0 0 0 1

View File

@ -1,4 +1,4 @@
LAMMPS (10 Sep 2010)
LAMMPS (27 Mar 2011)
# FENE beadspring benchmark
variable x index 1
@ -48,18 +48,18 @@ thermo 100
timestep 0.012
run 100
Memory usage per processor = 10.0339 Mbytes
Memory usage per processor = 13.3552 Mbytes
Step Temp E_pair E_mol TotEng Press
0 0.97027498 0.44484087 20.494523 22.394765 4.6721833
100 0.97682955 0.44239968 20.500229 22.407862 4.6527025
Loop time of 2.44443 on 4 procs for 100 steps with 128000 atoms
Loop time of 2.4188 on 4 procs for 100 steps with 128000 atoms
Pair time (%) = 0.512437 (20.9635)
Bond time (%) = 0.34535 (14.128)
Neigh time (%) = 0.750835 (30.7162)
Comm time (%) = 0.225137 (9.2102)
Outpt time (%) = 0.000238776 (0.00976818)
Other time (%) = 0.61043 (24.9723)
Pair time (%) = 0.507936 (20.9995)
Bond time (%) = 0.340843 (14.0914)
Neigh time (%) = 0.735922 (30.425)
Comm time (%) = 0.228828 (9.46038)
Outpt time (%) = 0.000289202 (0.0119564)
Other time (%) = 0.604987 (25.0118)
Nlocal: 32000 ave 32015 max 31983 min
Histogram: 1 0 1 0 0 0 0 0 1 1

View File

@ -1,4 +1,4 @@
LAMMPS (10 Sep 2010)
LAMMPS (27 Mar 2011)
# LAMMPS benchmark of granular flow
# chute flow of 32000 atoms with frozen base at 26 degrees
@ -38,17 +38,17 @@ thermo_modify norm no
thermo 100
run 100
Memory usage per processor = 33.1524 Mbytes
Memory usage per processor = 35.2505 Mbytes
Step Atoms KinEng 1 Volume
0 32000 784139.13 1601.1263 29830.88
100 32000 784289.99 1571.0137 29831.804
Loop time of 1.60559 on 1 procs for 100 steps with 32000 atoms
Loop time of 1.58777 on 1 procs for 100 steps with 32000 atoms
Pair time (%) = 0.895255 (55.7587)
Neigh time (%) = 0.0694721 (4.32689)
Comm time (%) = 0.0682392 (4.25011)
Outpt time (%) = 0.000529051 (0.0329506)
Other time (%) = 0.572093 (35.6314)
Pair time (%) = 0.887784 (55.9139)
Neigh time (%) = 0.070847 (4.46205)
Comm time (%) = 0.0669501 (4.21661)
Outpt time (%) = 0.000550032 (0.0346418)
Other time (%) = 0.561639 (35.3728)
Nlocal: 32000 ave 32000 max 32000 min
Histogram: 1 0 0 0 0 0 0 0 0 0

View File

@ -1,4 +1,4 @@
LAMMPS (10 Sep 2010)
LAMMPS (27 Mar 2011)
# LAMMPS benchmark of granular flow
# chute flow of 32000 atoms with frozen base at 26 degrees
@ -38,17 +38,17 @@ thermo_modify norm no
thermo 100
run 100
Memory usage per processor = 14.5608 Mbytes
Memory usage per processor = 15.4199 Mbytes
Step Atoms KinEng 1 Volume
0 32000 784139.13 1601.1263 29830.88
100 32000 784289.99 1571.0137 29831.804
Loop time of 0.277719 on 4 procs for 100 steps with 32000 atoms
Loop time of 0.270323 on 4 procs for 100 steps with 32000 atoms
Pair time (%) = 0.137333 (49.4503)
Neigh time (%) = 0.0172272 (6.20312)
Comm time (%) = 0.0410517 (14.7818)
Outpt time (%) = 0.000243425 (0.0876517)
Other time (%) = 0.0818638 (29.4772)
Pair time (%) = 0.135713 (50.2038)
Neigh time (%) = 0.0173983 (6.43611)
Comm time (%) = 0.0378563 (14.0041)
Outpt time (%) = 0.000246227 (0.091086)
Other time (%) = 0.0791097 (29.2649)
Nlocal: 8000 ave 8010 max 7990 min
Histogram: 2 0 0 0 0 0 0 0 0 2

View File

@ -1,4 +1,4 @@
LAMMPS (10 Sep 2010)
LAMMPS (27 Mar 2011)
# LAMMPS benchmark of granular flow
# chute flow of 32000 atoms with frozen base at 26 degrees
@ -48,17 +48,17 @@ thermo_modify norm no
thermo 100
run 100
Memory usage per processor = 35.1222 Mbytes
Memory usage per processor = 37.3912 Mbytes
Step Atoms KinEng 1 Volume
0 128000 3136556.5 6404.5051 119323.52
100 128000 3137160 6284.0549 119327.22
Loop time of 2.81255 on 4 procs for 100 steps with 128000 atoms
Loop time of 2.79202 on 4 procs for 100 steps with 128000 atoms
Pair time (%) = 1.14575 (40.7373)
Neigh time (%) = 0.070235 (2.4972)
Comm time (%) = 0.247361 (8.79492)
Outpt time (%) = 0.00147456 (0.0524279)
Other time (%) = 1.34772 (47.9182)
Pair time (%) = 1.13366 (40.6034)
Neigh time (%) = 0.0699974 (2.50705)
Comm time (%) = 0.24415 (8.74457)
Outpt time (%) = 0.00162953 (0.0583639)
Other time (%) = 1.34259 (48.0866)
Nlocal: 32000 ave 32000 max 32000 min
Histogram: 4 0 0 0 0 0 0 0 0 0

View File

@ -1,4 +1,4 @@
LAMMPS (10 Sep 2010)
LAMMPS (27 Mar 2011)
# bulk Cu lattice
variable x index 1
@ -41,18 +41,18 @@ timestep 0.005
thermo 50
run 100
Memory usage per processor = 13.3815 Mbytes
Memory usage per processor = 15.3728 Mbytes
Step Temp E_pair E_mol TotEng Press
0 1600 -113280 0 -106662.09 18703.573
50 781.69049 -109873.35 0 -106640.13 52273.088
100 801.832 -109957.3 0 -106640.77 51322.821
Loop time of 11.4134 on 1 procs for 100 steps with 32000 atoms
Loop time of 11.4086 on 1 procs for 100 steps with 32000 atoms
Pair time (%) = 10.2719 (89.9988)
Neigh time (%) = 0.870639 (7.62822)
Comm time (%) = 0.071027 (0.622312)
Outpt time (%) = 0.000430107 (0.00376844)
Other time (%) = 0.19938 (1.74689)
Pair time (%) = 10.2465 (89.814)
Neigh time (%) = 0.893404 (7.83096)
Comm time (%) = 0.0694258 (0.608539)
Outpt time (%) = 0.000409126 (0.00358612)
Other time (%) = 0.198848 (1.74296)
Nlocal: 32000 ave 32000 max 32000 min
Histogram: 1 0 0 0 0 0 0 0 0 0

View File

@ -1,4 +1,4 @@
LAMMPS (10 Sep 2010)
LAMMPS (27 Mar 2011)
# bulk Cu lattice
variable x index 1
@ -41,18 +41,18 @@ timestep 0.005
thermo 50
run 100
Memory usage per processor = 4.30641 Mbytes
Memory usage per processor = 4.92442 Mbytes
Step Temp E_pair E_mol TotEng Press
0 1600 -113280 0 -106662.09 18703.573
50 781.69049 -109873.35 0 -106640.13 52273.088
100 801.832 -109957.3 0 -106640.77 51322.821
Loop time of 2.83686 on 4 procs for 100 steps with 32000 atoms
Loop time of 2.84421 on 4 procs for 100 steps with 32000 atoms
Pair time (%) = 2.47209 (87.1416)
Neigh time (%) = 0.216486 (7.63117)
Comm time (%) = 0.102601 (3.61672)
Outpt time (%) = 0.000239313 (0.00843582)
Other time (%) = 0.0454471 (1.60202)
Pair time (%) = 2.47554 (87.0379)
Neigh time (%) = 0.216563 (7.61418)
Comm time (%) = 0.104262 (3.66577)
Outpt time (%) = 0.000251591 (0.00884573)
Other time (%) = 0.0475937 (1.67335)
Nlocal: 8000 ave 8008 max 7993 min
Histogram: 2 0 0 0 0 0 0 0 1 1

View File

@ -1,4 +1,4 @@
LAMMPS (10 Sep 2010)
LAMMPS (27 Mar 2011)
# bulk Cu lattice
variable x index 1
@ -41,18 +41,18 @@ timestep 0.005
thermo 50
run 100
Memory usage per processor = 13.2978 Mbytes
Memory usage per processor = 15.2892 Mbytes
Step Temp E_pair E_mol TotEng Press
0 1600 -453120 0 -426647.73 18704.012
50 779.50001 -439457.02 0 -426560.06 52355.276
100 797.97828 -439764.76 0 -426562.07 51474.74
Loop time of 12.1219 on 4 procs for 100 steps with 128000 atoms
Loop time of 12.0882 on 4 procs for 100 steps with 128000 atoms
Pair time (%) = 10.388 (85.696)
Neigh time (%) = 0.970104 (8.00291)
Comm time (%) = 0.309309 (2.55166)
Outpt time (%) = 0.00056392 (0.00465208)
Other time (%) = 0.453939 (3.74479)
Pair time (%) = 10.3589 (85.6942)
Neigh time (%) = 0.963713 (7.97234)
Comm time (%) = 0.316817 (2.62088)
Outpt time (%) = 0.000717819 (0.00593818)
Other time (%) = 0.448062 (3.70661)
Nlocal: 32000 ave 32092 max 31914 min
Histogram: 1 0 0 1 0 1 0 0 0 1

View File

@ -1,4 +1,4 @@
LAMMPS (10 Sep 2010)
LAMMPS (27 Mar 2011)
# 3d Lennard-Jones melt
variable x index 1
@ -39,17 +39,17 @@ neigh_modify delay 0 every 20 check no
fix 1 all nve
run 100
Memory usage per processor = 11.5405 Mbytes
Memory usage per processor = 13.2267 Mbytes
Step Temp E_pair E_mol TotEng Press
0 1.44 -6.7733681 0 -4.6134356 -5.0197073
100 0.7574531 -5.7585055 0 -4.6223613 0.20726105
Loop time of 4.23911 on 1 procs for 100 steps with 32000 atoms
Loop time of 4.24155 on 1 procs for 100 steps with 32000 atoms
Pair time (%) = 3.65005 (86.1043)
Neigh time (%) = 0.358313 (8.45255)
Comm time (%) = 0.0616844 (1.45513)
Outpt time (%) = 0.000219822 (0.00518557)
Other time (%) = 0.168838 (3.98286)
Pair time (%) = 3.6555 (86.1832)
Neigh time (%) = 0.359136 (8.4671)
Comm time (%) = 0.0590658 (1.39255)
Outpt time (%) = 0.000212193 (0.00500272)
Other time (%) = 0.167634 (3.95218)
Nlocal: 32000 ave 32000 max 32000 min
Histogram: 1 0 0 0 0 0 0 0 0 0

View File

@ -1,4 +1,4 @@
LAMMPS (10 Sep 2010)
LAMMPS (27 Mar 2011)
# 3d Lennard-Jones melt
variable x index 1
@ -39,17 +39,17 @@ neigh_modify delay 0 every 20 check no
fix 1 all nve
run 100
Memory usage per processor = 3.77112 Mbytes
Memory usage per processor = 4.31284 Mbytes
Step Temp E_pair E_mol TotEng Press
0 1.44 -6.7733681 0 -4.6134356 -5.0197073
100 0.7574531 -5.7585055 0 -4.6223613 0.20726105
Loop time of 1.08693 on 4 procs for 100 steps with 32000 atoms
Loop time of 1.08102 on 4 procs for 100 steps with 32000 atoms
Pair time (%) = 0.862853 (79.3841)
Neigh time (%) = 0.0901618 (8.29506)
Comm time (%) = 0.104805 (9.64223)
Outpt time (%) = 0.00012809 (0.0117846)
Other time (%) = 0.0289862 (2.66678)
Pair time (%) = 0.86205 (79.7443)
Neigh time (%) = 0.0897413 (8.30156)
Comm time (%) = 0.0998399 (9.23573)
Outpt time (%) = 0.000194311 (0.0179748)
Other time (%) = 0.0291918 (2.7004)
Nlocal: 8000 ave 8037 max 7964 min
Histogram: 2 0 0 0 0 0 0 0 1 1

View File

@ -1,4 +1,4 @@
LAMMPS (10 Sep 2010)
LAMMPS (27 Mar 2011)
# 3d Lennard-Jones melt
variable x index 1
@ -39,17 +39,17 @@ neigh_modify delay 0 every 20 check no
fix 1 all nve
run 100
Memory usage per processor = 11.4634 Mbytes
Memory usage per processor = 13.1495 Mbytes
Step Temp E_pair E_mol TotEng Press
0 1.44 -6.7733681 0 -4.6133849 -5.0196788
100 0.75841891 -5.759957 0 -4.6223375 0.20008866
Loop time of 4.71979 on 4 procs for 100 steps with 128000 atoms
Loop time of 4.71885 on 4 procs for 100 steps with 128000 atoms
Pair time (%) = 3.69683 (78.3262)
Neigh time (%) = 0.352295 (7.46421)
Comm time (%) = 0.27812 (5.89264)
Outpt time (%) = 0.000311732 (0.00660479)
Other time (%) = 0.392233 (8.31039)
Pair time (%) = 3.70177 (78.4464)
Neigh time (%) = 0.350671 (7.43129)
Comm time (%) = 0.278878 (5.90987)
Outpt time (%) = 0.000279307 (0.00591897)
Other time (%) = 0.387254 (8.20654)
Nlocal: 32000 ave 32060 max 31939 min
Histogram: 1 0 1 0 0 0 0 1 0 1

View File

@ -1,4 +1,4 @@
LAMMPS (10 Sep 2010)
LAMMPS (27 Mar 2011)
# Rhodopsin model
units real
@ -51,37 +51,37 @@ PPPM initialization ...
stencil order = 5
RMS precision = 7.57143e-05
brick FFT buffer size/proc = 41070 25600 12321
Memory usage per processor = 124.369 Mbytes
Memory usage per processor = 138.965 Mbytes
---------------- Step 0 ----- CPU = 0.0000 (sec) ----------------
TotEng = -25356.2055 KinEng = 21444.8313 Temp = 299.0397
PotEng = -46801.0368 E_bond = 2537.9940 E_angle = 10921.3742
E_dihed = 5211.7865 E_impro = 213.5116 E_vdwl = -2307.8634
E_coul = 207021.6603 E_long = -270399.5000 Press = -142.6030
Volume = 307995.0335
---------------- Step 50 ----- CPU = 31.7800 (sec) ----------------
---------------- Step 50 ----- CPU = 32.2123 (sec) ----------------
TotEng = -25330.0783 KinEng = 21501.0023 Temp = 299.8230
PotEng = -46831.0806 E_bond = 2471.7004 E_angle = 10836.4977
E_dihed = 5239.6299 E_impro = 227.1218 E_vdwl = -1993.2753
E_coul = 206793.4044 E_long = -270406.1594 Press = 237.6744
Volume = 308031.5641
---------------- Step 100 ----- CPU = 64.5301 (sec) ----------------
---------------- Step 100 ----- CPU = 65.3867 (sec) ----------------
TotEng = -25290.7642 KinEng = 21592.0080 Temp = 301.0920
PotEng = -46882.7722 E_bond = 2567.9806 E_angle = 10781.9408
E_dihed = 5198.7431 E_impro = 216.7832 E_vdwl = -1902.4804
E_coul = 206654.9995 E_long = -270400.7389 Press = 6.9875
Volume = 308133.9900
Loop time of 64.5302 on 1 procs for 100 steps with 32000 atoms
Loop time of 65.3868 on 1 procs for 100 steps with 32000 atoms
Pair time (%) = 46.3691 (71.8564)
Bond time (%) = 2.88541 (4.4714)
Kspce time (%) = 6.09222 (9.44088)
Neigh time (%) = 6.59142 (10.2145)
Comm time (%) = 0.18323 (0.283944)
Outpt time (%) = 0.000371933 (0.000576371)
Other time (%) = 2.40847 (3.73231)
Pair time (%) = 46.2231 (70.6918)
Bond time (%) = 2.88711 (4.41543)
Kspce time (%) = 7.06667 (10.8075)
Neigh time (%) = 6.61535 (10.1173)
Comm time (%) = 0.185745 (0.28407)
Outpt time (%) = 0.000392199 (0.000599813)
Other time (%) = 2.4084 (3.68331)
FFT time (% of Kspce) = 0.434537 (7.13265)
FFT Gflps 3d (1d only) = 1.19598 1.70446
FFT time (% of Kspce) = 0.430403 (6.0906)
FFT Gflps 3d (1d only) = 1.20747 1.74267
Nlocal: 32000 ave 32000 max 32000 min
Histogram: 1 0 0 0 0 0 0 0 0 0

View File

@ -1,4 +1,4 @@
LAMMPS (10 Sep 2010)
LAMMPS (27 Mar 2011)
# Rhodopsin model
units real
@ -51,37 +51,37 @@ PPPM initialization ...
stencil order = 5
RMS precision = 7.57143e-05
brick FFT buffer size/proc = 13230 6400 5670
Memory usage per processor = 47.7552 Mbytes
Memory usage per processor = 54.4744 Mbytes
---------------- Step 0 ----- CPU = 0.0000 (sec) ----------------
TotEng = -25356.2055 KinEng = 21444.8313 Temp = 299.0397
PotEng = -46801.0368 E_bond = 2537.9940 E_angle = 10921.3742
E_dihed = 5211.7865 E_impro = 213.5116 E_vdwl = -2307.8634
E_coul = 207021.6603 E_long = -270399.5000 Press = -142.6030
Volume = 307995.0335
---------------- Step 50 ----- CPU = 8.2303 (sec) ----------------
---------------- Step 50 ----- CPU = 8.2683 (sec) ----------------
TotEng = -25330.0783 KinEng = 21501.0023 Temp = 299.8230
PotEng = -46831.0806 E_bond = 2471.7004 E_angle = 10836.4977
E_dihed = 5239.6299 E_impro = 227.1218 E_vdwl = -1993.2753
E_coul = 206793.4044 E_long = -270406.1594 Press = 237.6744
Volume = 308031.5641
---------------- Step 100 ----- CPU = 16.7709 (sec) ----------------
---------------- Step 100 ----- CPU = 16.8728 (sec) ----------------
TotEng = -25290.7642 KinEng = 21592.0080 Temp = 301.0920
PotEng = -46882.7722 E_bond = 2567.9806 E_angle = 10781.9408
E_dihed = 5198.7431 E_impro = 216.7832 E_vdwl = -1902.4804
E_coul = 206654.9995 E_long = -270400.7389 Press = 6.9875
Volume = 308133.9900
Loop time of 16.771 on 4 procs for 100 steps with 32000 atoms
Loop time of 16.8729 on 4 procs for 100 steps with 32000 atoms
Pair time (%) = 11.2592 (67.1347)
Bond time (%) = 0.685832 (4.08939)
Kspce time (%) = 2.03664 (12.1438)
Neigh time (%) = 1.60447 (9.56693)
Comm time (%) = 0.334371 (1.99374)
Outpt time (%) = 0.00025332 (0.00151046)
Other time (%) = 0.850284 (5.06997)
Pair time (%) = 11.2248 (66.5258)
Bond time (%) = 0.687313 (4.07347)
Kspce time (%) = 2.07329 (12.2877)
Neigh time (%) = 1.59928 (9.47838)
Comm time (%) = 0.410708 (2.43412)
Outpt time (%) = 0.000243425 (0.0014427)
Other time (%) = 0.877245 (5.19914)
FFT time (% of Kspce) = 0.194679 (9.55886)
FFT Gflps 3d (1d only) = 2.6695 6.75898
FFT time (% of Kspce) = 0.223284 (10.7696)
FFT Gflps 3d (1d only) = 2.32752 6.8543
Nlocal: 8000 ave 8143 max 7933 min
Histogram: 1 2 0 0 0 0 0 0 0 1

View File

@ -1,4 +1,4 @@
LAMMPS (10 Sep 2010)
LAMMPS (27 Mar 2011)
# Rhodopsin model
variable x index 1
@ -72,37 +72,37 @@ PPPM initialization ...
stencil order = 5
RMS precision = 7.66425e-05
brick FFT buffer size/proc = 41615 25920 12915
Memory usage per processor = 130.497 Mbytes
Memory usage per processor = 146.135 Mbytes
---------------- Step 0 ----- CPU = 0.0000 (sec) ----------------
TotEng = -101425.4825 KinEng = 85779.3251 Temp = 299.0304
PotEng = -187204.8077 E_bond = 10151.9760 E_angle = 43685.4968
E_dihed = 20847.1460 E_impro = 854.0463 E_vdwl = -9231.4537
E_coul = 827025.3556 E_long = -1080537.3748 Press = -142.3084
Volume = 1231980.1340
---------------- Step 50 ----- CPU = 32.9583 (sec) ----------------
---------------- Step 50 ----- CPU = 32.8194 (sec) ----------------
TotEng = -101320.2611 KinEng = 86003.4849 Temp = 299.8118
PotEng = -187323.7460 E_bond = 9887.1072 E_angle = 43346.7920
E_dihed = 20958.7034 E_impro = 908.4715 E_vdwl = -7973.4456
E_coul = 826113.1533 E_long = -1080564.5278 Press = 238.0165
Volume = 1232126.1854
---------------- Step 100 ----- CPU = 67.2708 (sec) ----------------
---------------- Step 100 ----- CPU = 66.9547 (sec) ----------------
TotEng = -101158.1519 KinEng = 86355.6231 Temp = 301.0394
PotEng = -187513.7749 E_bond = 10272.0700 E_angle = 43128.6453
E_dihed = 20793.9768 E_impro = 867.0826 E_vdwl = -7586.7196
E_coul = 825555.5006 E_long = -1080544.3306 Press = 15.2192
Volume = 1232535.8453
Loop time of 67.2712 on 4 procs for 100 steps with 128000 atoms
Loop time of 66.9548 on 4 procs for 100 steps with 128000 atoms
Pair time (%) = 45.8103 (68.0979)
Bond time (%) = 2.8855 (4.28936)
Kspce time (%) = 7.55695 (11.2335)
Neigh time (%) = 6.5594 (9.75068)
Comm time (%) = 0.880104 (1.30829)
Outpt time (%) = 0.000582039 (0.000865213)
Other time (%) = 3.57839 (5.31935)
Pair time (%) = 45.779 (68.373)
Bond time (%) = 2.87439 (4.29303)
Kspce time (%) = 7.5089 (11.2149)
Neigh time (%) = 6.52016 (9.73816)
Comm time (%) = 0.765243 (1.14293)
Outpt time (%) = 0.000411808 (0.000615055)
Other time (%) = 3.50669 (5.2374)
FFT time (% of Kspce) = 1.19838 (15.858)
FFT Gflps 3d (1d only) = 1.99837 6.14282
FFT time (% of Kspce) = 1.17001 (15.5816)
FFT Gflps 3d (1d only) = 2.04683 6.15771
Nlocal: 32000 ave 32000 max 32000 min
Histogram: 4 0 0 0 0 0 0 0 0 0

BIN
doc/Developer.pdf Normal file

Binary file not shown.

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.4 KiB

View File

@ -0,0 +1,9 @@
\documentstyle[12pt]{article}
\begin{document}
$$
E=-\frac{Umin}{2} \left[ 1+Cos(\theta-\theta_0) \right]
$$
\end{document}

Binary file not shown.

After

Width:  |  Height:  |  Size: 4.6 KiB

View File

@ -0,0 +1,13 @@
\documentstyle[12pt]{article}
\begin{document}
$$
E=-U_{min}
\frac{e^{-a U(\theta,\theta_0)}-1}{e^a-1}
\quad\mbox{with}\quad
U(\theta,\theta_0)
=-0.5 \left(1+\cos(\theta-\theta_0) \right)
$$
\end{document}

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.0 KiB

View File

@ -0,0 +1,9 @@
\documentclass[12pt]{article}
\begin{document}
$$
E = \frac{Umin}{(r_0-r_c)^2} \left[ (r-r_0)^2-(r_c-r_0)^2 \right]
$$
\end{document}

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.9 KiB

View File

@ -0,0 +1,9 @@
\documentclass[12pt]{article}
\begin{document}
$$
E = \frac{Umin}{(r_0-r_c)^2} \left[ (r-r_0)^2-(r_c-r_0)^2 \right]
$$
\end{document}

Binary file not shown.

Before

Width:  |  Height:  |  Size: 6.1 KiB

After

Width:  |  Height:  |  Size: 17 KiB

BIN
doc/Eqs/box_inverse.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 16 KiB

14
doc/Eqs/box_inverse.tex Normal file
View File

@ -0,0 +1,14 @@
\documentclass[12pt]{article}
\begin{document}
\begin{eqnarray*}
{\rm lx} &=& a \\
{\rm xy} &=& b \cos{\gamma} \\
{\rm xz} &=& c \cos{\beta}\\
{\rm ly}^2 &=& b^2 - {\rm xy}^2 \\
{\rm yz} &=& \frac{b*c \cos{\alpha} - {\rm xy}*{\rm xz}}{\rm ly} \\
{\rm lz}^2 &=& c^2 - {\rm xz}^2 - {\rm yz}^2 \\
\end{eqnarray*}
\end{document}

Binary file not shown.

After

Width:  |  Height:  |  Size: 4.7 KiB

View File

@ -0,0 +1,13 @@
\documentstyle[12pt]{article}
\begin{document}
$$
E=-U_{min}
\frac{e^{-a U(\theta,\theta_0)}-1}{e^a-1}
\quad\mbox{with}\quad
U(\theta,\theta_0)
=-0.5 \left(1+\cos(\theta-\theta_0) \right)
$$
\end{document}

BIN
doc/Eqs/fix_nphug.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 12 KiB

9
doc/Eqs/fix_nphug.tex Normal file
View File

@ -0,0 +1,9 @@
\documentstyle[12pt]{article}
\begin{document}
$$
T_t - T = \frac{\left(\frac{1}{2}\left(P + P_0\right)\left(V_0 - V\right) + E_0 - E\right)}{N_{dof} k_B } = Delta
$$
\end{document}

BIN
doc/Eqs/fld.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.1 KiB

9
doc/Eqs/fld.tex Normal file
View File

@ -0,0 +1,9 @@
\documentstyle[12pt]{article}
\begin{document}
$$
F^{H} = -R_{FU}(U-U^{\infty}) + R_{FE}E^{\infty}
$$
\end{document}

BIN
doc/Eqs/fld2.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.1 KiB

9
doc/Eqs/fld2.tex Normal file
View File

@ -0,0 +1,9 @@
\documentstyle[12pt]{article}
\begin{document}
$$
-R_{FU}(U-U^{\infty}) = -R_{FE}E^{\infty} - F^{rest}
$$
\end{document}

BIN
doc/Eqs/pair_adp.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 11 KiB

26
doc/Eqs/pair_adp.tex Normal file
View File

@ -0,0 +1,26 @@
\documentclass[12pt]{article}
\begin{document}
\begin{eqnarray*}
E_{i} & = & F_{\alpha} \left( \sum_{j \ne i} \rho(r_{ij}) \right) +
\frac{1}{2} \sum_{j \ne i} \phi_{\alpha \beta} (r_{ij}) +
\frac{1}{2} \sum_{i,s} \left( \mu_{i}^{s} \right)^2 +
\sum_{i,s,t} \left( \lambda_{i}^{st} \right)^2 - \frac{1}{6} \nu_{i} \\
\mu_{i}^{s} & = & \sum_{i \ne j} u(r_{ij}) r_{ij}^{s} \\
\lambda_{i}^{st} & = & \sum_{i \ne j} w(r_{ij}) r_{ij}^{s} r_{ij}^{t} \\
\nu_{i} & = & \sum_{s} \lambda_{i}^{ss}
\end{eqnarray*}
\begin{eqnarray*}
E_i & = & F_\alpha \left( \sum_{j\neq i} \rho_\beta (r_{ij}) \right) + \frac{1}{2} \sum_{j\neq i}\phi_{\alpha\beta}(r_{ij})+ \frac{1}{2} \sum_s (\mu_i^s)^2 + \frac{1}{2} \sum_{s,t} (\lambda_i^{st})^2 - \frac{1}{6} \nu_i^2 \\
%
\mu_i^s & = & \sum_{j\neq i}u_{\alpha\beta}(r_{ij})r_{ij}^s\\
%
\lambda_i^{st} & = & \sum_{j\neq i}w_{\alpha\beta}(r_{ij})r_{ij}^sr_{ij}^t\\
%
\nu_i & = & \sum_s\lambda_i^{ss}
\end{eqnarray*}
\end{document}

BIN
doc/Eqs/pair_dipole_sf.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 55 KiB

View File

@ -0,0 +1,51 @@
\documentclass[12pt]{article}
\begin{document}
\begin{eqnarray*}
E_{LJ} & = & 4\epsilon \left\{ \left[ \left( \frac{\sigma}{r} \right)^{\!12} -
\left( \frac{\sigma}{r} \right)^{\!6} \right] +
\left[ 6\left( \frac{\sigma}{r_c} \right)^{\!12} -
3\left(\frac{\sigma}{r_c}\right)^{\!6}\right]\left(\frac{r}{r_c}\right)^{\!2}
- 7\left( \frac{\sigma}{r_c} \right)^{\!12} +
4\left( \frac{\sigma}{r_c} \right)^{\!6}\right\} \\
E_{qq} & = & \frac{q_i q_j}{r}\left(1-\frac{r}{r_c}\right)^{\!2} \\
E_{pq} & = & E_{ji} = -\frac{q}{r^3} \left[ 1 -
3\left(\frac{r}{r_c}\right)^{\!2} +
2\left(\frac{r}{r_c}\right)^{\!3}\right] (\vec{p}\bullet\vec{r}) \\
E_{qp} & = & E_{ij} = \frac{q}{r^3} \left[ 1 -
3\left(\frac{r}{r_c}\right)^{\!2} +
2\left(\frac{r}{r_c}\right)^{\!3}\right] (\vec{p}\bullet\vec{r}) \\
E_{pp} & = & \left[1-4\left(\frac{r}{r_c}\right)^{\!3} +
3\left(\frac{r}{r_c}\right)^{\!4}\right]\left[\frac{1}{r^3}
(\vec{p_i} \bullet \vec{p_j}) - \frac{3}{r^5}
(\vec{p_i} \bullet \vec{r}) (\vec{p_j} \bullet \vec{r})\right] \\
\end{eqnarray*}
\begin{eqnarray*}
F_{LJ} & = & \left\{\left[48\epsilon \left(\frac{\sigma}{r}\right)^{\!12} -
24\epsilon \left(\frac{\sigma}{r}\right)^{\!6} \right]\frac{1}{r^2} -
\left[48\epsilon \left(\frac{\sigma}{r_c}\right)^{\!12} - 24\epsilon
\left(\frac{\sigma}{r_c}\right)^{\!6} \right]\frac{1}{r_c^2}\right\}\vec{r}\\
F_{qq} & = & \frac{q_i q_j}{r}\left(\frac{1}{r^2} -
\frac{1}{r_c^2}\right)\vec{r} \\
F_{pq} &=& F_{ij } = -\frac{3q}{r^5} \left[ 1 -
\left(\frac{r}{r_c}\right)^{\!2}\right](\vec{p}\bullet\vec{r})\vec{r} +
\frac{q}{r^3}\left[1-3\left(\frac{r}{r_c}\right)^{\!2} +
2\left(\frac{r}{r_c}\right)^{\!3}\right] \vec{p} \\
F_{qp} &=& F_{ij} = \frac{3q}{r^5} \left[ 1 -
\left(\frac{r}{r_c}\right)^{\!2}\right] (\vec{p}\bullet\vec{r})\vec{r} -
\frac{q}{r^3}\left[1-3\left(\frac{r}{r_c}\right)^{\!2} +
2\left(\frac{r}{r_c}\right)^{\!3}\right] \vec{p} \\
F_{pp} & = &\frac{3}{r^5}\Bigg\{\left[1-\left(\frac{r}{r_c}\right)^{\!4}\right]
\left[(\vec{p_i}\bullet\vec{p_j}) - \frac{3}{r^2} (\vec{p_i}\bullet\vec{r})
(\vec{p_j} \bullet \vec{r})\right] \vec{r} + \\
& & \left[1 -
4\left(\frac{r}{r_c}\right)^{\!3}+3\left(\frac{r}{r_c}\right)^{\!4}\right]
\left[ (\vec{p_j} \bullet \vec{r}) \vec{p_i} + (\vec{p_i} \bullet \vec{r})
\vec{p_j} -\frac{2}{r^2} (\vec{p_i} \bullet \vec{r})
(\vec{p_j} \bullet \vec{r})\vec{r}\right] \Bigg\} \\
\end{eqnarray*}
\end{document}

BIN
doc/Eqs/pair_dipole_sf2.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 24 KiB

View File

@ -0,0 +1,24 @@
\documentclass[12pt]{article}
\begin{document}
\begin{eqnarray*}
T_{pq} = T_{ij} & = & \frac{q_j}{r^3} \left[ 1 -
3\left(\frac{r}{r_c}\right)^{\!2} +
2\left(\frac{r}{r_c}\right)^{\!3}\right] (\vec{p_i}\times\vec{r}) \\
T_{qp} = T_{ji} & = & - \frac{q_i}{r^3} \left[ 1 -
3\left(\frac{r}{r_c}\right)^{\!2} +
2\left(\frac{r}{r_c}\right)^{\!3} \right] (\vec{p_j}\times\vec{r}) \\
T_{pp} = T_{ij} & = & -\frac{1}{r^3}\left[1-4\left(\frac{r}{r_c}\right)^{\!3} +
e3\left(\frac{r}{r_c}\right)^{\!4}\right] (\vec{p_i} \times \vec{p_j}) + \\
& & \frac{3}{r^5}\left[1-4\left(\frac{r}{r_c}\right)^{\!3} +
3\left(\frac{r}{r_c}\right)^{\!4}\right] (\vec{p_j}\bullet\vec{r})
(\vec{p_i} \times \vec{r}) \\
T_{pp} = T_{ji} & = & -\frac{1}{r^3}\left[1-4\left(\frac{r}{r_c}\right)^{\!3} +
3\left(\frac{r}{r_c}\right)^{\!4}\right](\vec{p_j} \times \vec{p_i}) + \\
& & \frac{3}{r^5}\left[1-4\left(\frac{r}{r_c}\right)^{\!3} +
3\left(\frac{r}{r_c}\right)^{\!4}\right] (\vec{p_i} \bullet \vec{r})
(\vec{p_j} \times \vec{r}) \\
\end{eqnarray*}
\end{document}

Binary file not shown.

Before

Width:  |  Height:  |  Size: 3.6 KiB

After

Width:  |  Height:  |  Size: 3.7 KiB

View File

@ -3,8 +3,8 @@
\begin{document}
$$
E_i = F_\alpha \left(\sum_{j \neq i}\ \rho_\alpha (r_{ij})\right) +
E_i = F_\alpha \left(\sum_{j \neq i}\ \rho_\beta (r_{ij})\right) +
\frac{1}{2} \sum_{j \neq i} \phi_{\alpha\beta} (r_{ij})
$$
\end{document}
\end{document}

BIN
doc/Eqs/pair_edip.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 24 KiB

22
doc/Eqs/pair_edip.tex Normal file
View File

@ -0,0 +1,22 @@
\documentclass[12pt]{article}
\usepackage{amssymb,amsmath}
\begin{document}
\begin{eqnarray*}
E & = & \sum_{j \ne i} \phi_{2}(R_{ij}, Z_{i}) + \sum_{j \ne i} \sum_{k \ne i,k > j} \phi_{3}(R_{ij}, R_{ik}, Z_{i}) \\
\phi_{2}(r, Z) & = & A\left[\left(\frac{B}{r}\right)^{\rho} - e^{-\beta Z^2}\right]exp{\left(\frac{\sigma}{r-a}\right)} \\
\phi_{3}(R_{ij}, R_{ik}, Z_i) & = & exp{\left(\frac{\gamma}{R_{ij}-a}\right)}exp{\left(\frac{\gamma}{R_{ik}-a}\right)}h(cos\theta_{ijk},Z_i) \\
Z_i & = & \sum_{m \ne i} f(R_{im}) \qquad
f(r) = \begin{cases}
1 & \quad r<c \\
\exp\left(\frac{\alpha}{1-x^{-3}}\right) & \quad c<r<a \\
0 & \quad r>a
\end{cases} \\
h(l,Z) & = & \lambda [(1-e^{-Q(Z)(l+\tau(Z))^2}) + \eta Q(Z)(l+\tau(Z))^2 ] \\
Q(Z) & = & Q_0 e^{-\mu Z} \qquad \tau(Z) = u_1 + u_2 (u_3 e^{-u_4 Z} - e^{-2u_4 Z})
\end{eqnarray*}
\end{document}

BIN
doc/Eqs/pair_gauss_cut.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.7 KiB

View File

@ -0,0 +1,8 @@
\documentclass[12pt]{article}
\pagestyle{empty}
\begin{document}
\begin{eqnarray*}
E = & \frac{H}{\sigma_h\sqrt{2\pi}} \exp\left[-\frac{(r-r_{mh})^2}{2\sigma_h^2}\right]
\end{eqnarray*}
\end{document}

Binary file not shown.

Before

Width:  |  Height:  |  Size: 9.0 KiB

After

Width:  |  Height:  |  Size: 22 KiB

View File

@ -7,8 +7,8 @@ E_{LJ} & = & 4 \epsilon \left[ \left(\frac{\sigma}{r}\right)^{12} -
\left(\frac{\sigma}{r}\right)^6 \right] + S_{LJ}(r)
\qquad r < r_c \\
E_C & = & \frac{C q_i q_j}{\epsilon r} + S_C(r) \qquad r < r_c \\
S(r) & = & 0 \qquad r < r_1 \\
S(r) & = & A (r - r_1)^2 + B (r - r_1)^3 \qquad r_1 < r < r_c
S(r) & = & C \qquad r < r_1 \\
S(r) & = & \frac{A}{3} (r - r_1)^3 + \frac{B}{4} (r - r_1)^4 + C \qquad r_1 < r < r_c
\end{eqnarray*}
\end{document}

Binary file not shown.

Before

Width:  |  Height:  |  Size: 12 KiB

After

Width:  |  Height:  |  Size: 18 KiB

View File

@ -1,16 +1,18 @@
\documentstyle[12pt]{article}
\begin{document}
$$
E^{hb}_{LJ}(r)=AR^{-12}-BR^{-10}cos^n\theta=4\epsilon\left\lbrace 5\left[ \frac{\sigma}{r}\right]^{12}-6\left[ \frac{\sigma}{r}\right]^{10} \right\rbrace cos^n\theta
$$
$$
E^{hb}_{MORSE}(r)=D_0\left\lbrace \chi^2 - 2\chi\right\rbrace cos^n\theta=D_{0}\left\lbrace e^{- 2 \alpha (r - r_0)} - 2 e^{- \alpha (r - r_0)} \right\rbrace cos^n\theta
$$
$$
where \qquad r < r_c, \qquad cos^2\left( \theta\right) > cos^2\left( \theta_c\right)
$$
\begin{eqnarray*}
E & = & \left[LJ(r) | Morse(r) \right] \qquad \qquad \qquad r < r_{\rm in} \\
& = & S(r) * \left[LJ(r) | Morse(r) \right] \qquad \qquad r_{\rm in} < r < r_{\rm out} \\
& = & 0 \qquad \qquad \qquad \qquad \qquad \qquad \qquad r > r_{\rm out} \\
LJ(r) & = & AR^{-12}-BR^{-10}cos^n\theta=
\epsilon\left\lbrace 5\left[ \frac{\sigma}{r}\right]^{12}-
6\left[ \frac{\sigma}{r}\right]^{10} \right\rbrace cos^n\theta\\
Morse(r) & = & D_0\left\lbrace \chi^2 - 2\chi\right\rbrace cos^n\theta=
D_{0}\left\lbrace e^{- 2 \alpha (r - r_0)} - 2 e^{- \alpha (r - r_0)}
\right\rbrace cos^n\theta \\
S(r) & = & \frac{ \left[r_{\rm out}^2 - r^2\right]^2
\left[r_{\rm out}^2 + 2r^2 - 3{r_{\rm in}^2}\right]}
{ \left[r_{\rm out}^2 - {r_{\rm in}}^2\right]^3 }
\end{eqnarray*}
\end{document}

BIN
doc/Eqs/pair_lj_cubic.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 5.3 KiB

12
doc/Eqs/pair_lj_cubic.tex Normal file
View File

@ -0,0 +1,12 @@
\documentstyle[12pt]{article}
\begin{document}
\begin{eqnarray*}
E &=& u_{LJ}(r) \qquad r \leq r_s \\
&=& u_{LJ}(r_s) + (r-r_s) u'_{LJ}(r_s) - \frac{1}{6} A_3 (r-r_s)^3 \qquad r_s < r \leq r_c \\
&=& 0 \qquad r > r_c
\end{eqnarray*}
\end{document}

BIN
doc/Eqs/pair_lj_sf.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 9.4 KiB

11
doc/Eqs/pair_lj_sf.tex Normal file
View File

@ -0,0 +1,11 @@
\documentclass[12pt]{article}
\begin{document}
\begin{eqnarray*}
F & = & F_{\mathrm{LJ}}(r) - F_{\mathrm{LJ}}(r_{\mathrm{c}}) \qquad r < r_{\mathrm{c}} \\
E & = & E_{\mathrm{LJ}}(r) - E_{\mathrm{LJ}}(r_{\mathrm{c}}) + (r - r_{\mathrm{c}}) F_{\mathrm{LJ}}(r_{\mathrm{c}}) \qquad r < r_{\mathrm{c}} \\
\mathrm{with} \qquad E_{\mathrm{LJ}}(r) & = & 4 \epsilon \left[ \left(\frac{\sigma}{r}\right)^{12} - \left(\frac{\sigma}{r}\right)^6 \right] \qquad \mathrm{and} \qquad F_{\mathrm{LJ}}(r) = - E^\prime_{\mathrm{LJ}}(r)
\end{eqnarray*}
\end{document}

BIN
doc/Eqs/pair_sph_ideal.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 911 B

View File

@ -0,0 +1,9 @@
\documentclass[12pt]{article}
\begin{document}
$$
p = (\gamma - 1) \rho e
$$
\end{document}

BIN
doc/Eqs/pair_sph_tait.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.4 KiB

View File

@ -0,0 +1,9 @@
\documentclass[12pt]{article}
\begin{document}
$$
p = B [(\frac{\rho}{\rho_0})^{\gamma} - 1]
$$
\end{document}

BIN
doc/JPG/dump1.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 594 KiB

BIN
doc/JPG/dump1_small.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 16 KiB

BIN
doc/JPG/dump2.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 168 KiB

BIN
doc/JPG/dump2_small.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 6.4 KiB

View File

@ -40,8 +40,12 @@ describe the most current version of LAMMPS.
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
about once per month. This is because it is large, and we don't want
it to be part of very 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.
@ -78,91 +82,107 @@ it gives quick access to documentation for all LAMMPS commands.
</P>
<OL><LI><A HREF = "Section_intro.html">Introduction</A>
<UL> 1.1 <A HREF = "Section_intro.html#1_1">What is LAMMPS</A>
<UL> 1.1 <A HREF = "Section_intro.html#intro_1">What is LAMMPS</A>
<BR>
1.2 <A HREF = "Section_intro.html#1_2">LAMMPS features</A>
1.2 <A HREF = "Section_intro.html#intro_2">LAMMPS features</A>
<BR>
1.3 <A HREF = "Section_intro.html#1_3">LAMMPS non-features</A>
1.3 <A HREF = "Section_intro.html#intro_3">LAMMPS non-features</A>
<BR>
1.4 <A HREF = "Section_intro.html#1_4">Open source distribution</A>
1.4 <A HREF = "Section_intro.html#intro_4">Open source distribution</A>
<BR>
1.5 <A HREF = "Section_intro.html#1_5">Acknowledgments and citations</A>
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#2_1">What's in the LAMMPS distribution</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#2_2">Making LAMMPS</A>
2.2 <A HREF = "Section_start.html#start_2">Making LAMMPS</A>
<BR>
2.3 <A HREF = "Section_start.html#2_3">Making LAMMPS with optional packages</A>
2.3 <A HREF = "Section_start.html#start_3">Making LAMMPS with optional packages</A>
<BR>
2.4 <A HREF = "Section_start.html#2_4">Building LAMMPS as a library</A>
2.4 <A HREF = "Section_start.html#start_4">Building LAMMPS as a library</A>
<BR>
2.5 <A HREF = "Section_start.html#2_5">Running LAMMPS</A>
2.5 <A HREF = "Section_start.html#start_5">Running LAMMPS</A>
<BR>
2.6 <A HREF = "Section_start.html#2_6">Command-line options</A>
2.6 <A HREF = "Section_start.html#start_6">Command-line options</A>
<BR>
2.7 <A HREF = "Section_start.html#2_7">Screen output</A>
2.7 <A HREF = "Section_start.html#start_7">Screen output</A>
<BR>
2.8 <A HREF = "Section_start.html#2_8">Running on GPUs</A>
<BR>
2.9 <A HREF = "Section_start.html#2_9">Tips for users of previous versions</A>
2.8 <A HREF = "2_8">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#3_1">LAMMPS input script</A>
<UL> 3.1 <A HREF = "Section_commands.html#cmd_1">LAMMPS input script</A>
<BR>
3.2 <A HREF = "Section_commands.html#3_2">Parsing rules</A>
3.2 <A HREF = "Section_commands.html#cmd_2">Parsing rules</A>
<BR>
3.3 <A HREF = "Section_commands.html#3_3">Input script structure</A>
3.3 <A HREF = "Section_commands.html#cmd_3">Input script structure</A>
<BR>
3.4 <A HREF = "Section_commands.html#3_4">Commands listed by category</A>
3.4 <A HREF = "Section_commands.html#cmd_4">Commands listed by category</A>
<BR>
3.5 <A HREF = "Section_commands.html#3_5">Commands listed alphabetically</A>
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">OPT package</A>
<BR>
5.2 <A HREF = "Section_accelerate.html#acc_2">USER-OMP package</A>
<BR>
5.3 <A HREF = "Section_accelerate.html#acc_3">GPU package</A>
<BR>
5.4 <A HREF = "Section_accelerate.html#acc_4">USER-CUDA package</A>
<BR>
5.5 <A HREF = "Section_accelerate.html#acc_5">Comparison of GPU and USER-CUDA packages</A>
<BR></UL>
<LI><A HREF = "Section_howto.html">How-to discussions</A>
<UL> 4.1 <A HREF = "Section_howto.html#4_1">Restarting a simulation</A>
<UL> 6.1 <A HREF = "Section_howto.html#howto_1">Restarting a simulation</A>
<BR>
4.2 <A HREF = "Section_howto.html#4_2">2d simulations</A>
6.2 <A HREF = "Section_howto.html#howto_2">2d simulations</A>
<BR>
4.3 <A HREF = "Section_howto.html#4_3">CHARMM and AMBER force fields</A>
6.3 <A HREF = "Section_howto.html#howto_3">CHARMM and AMBER force fields</A>
<BR>
4.4 <A HREF = "Section_howto.html#4_4">Running multiple simulations from one input script</A>
6.4 <A HREF = "Section_howto.html#howto_4">Running multiple simulations from one input script</A>
<BR>
4.5 <A HREF = "Section_howto.html#4_5">Multi-replica simulations</A>
6.5 <A HREF = "Section_howto.html#howto_5">Multi-replica simulations</A>
<BR>
4.6 <A HREF = "Section_howto.html#4_6">Granular models</A>
6.6 <A HREF = "Section_howto.html#howto_6">Granular models</A>
<BR>
4.7 <A HREF = "Section_howto.html#4_7">TIP3P water model</A>
6.7 <A HREF = "Section_howto.html#howto_7">TIP3P water model</A>
<BR>
4.8 <A HREF = "Section_howto.html#4_8">TIP4P water model</A>
6.8 <A HREF = "Section_howto.html#howto_8">TIP4P water model</A>
<BR>
4.9 <A HREF = "Section_howto.html#4_9">SPC water model</A>
6.9 <A HREF = "Section_howto.html#howto_9">SPC water model</A>
<BR>
4.10 <A HREF = "Section_howto.html#4_10">Coupling LAMMPS to other codes</A>
6.10 <A HREF = "Section_howto.html#howto_10">Coupling LAMMPS to other codes</A>
<BR>
4.11 <A HREF = "Section_howto.html#4_11">Visualizing LAMMPS snapshots</A>
6.11 <A HREF = "Section_howto.html#howto_11">Visualizing LAMMPS snapshots</A>
<BR>
4.12 <A HREF = "Section_howto.html#4_12">Triclinic (non-orthogonal) simulation boxes</A>
6.12 <A HREF = "Section_howto.html#howto_12">Triclinic (non-orthogonal) simulation boxes</A>
<BR>
4.13 <A HREF = "Section_howto.html#4_13">NEMD simulations</A>
6.13 <A HREF = "Section_howto.html#howto_13">NEMD simulations</A>
<BR>
4.14 <A HREF = "Section_howto.html#4_14">Extended spherical and aspherical particles</A>
6.14 <A HREF = "Section_howto.html#howto_14">Extended spherical and aspherical particles</A>
<BR>
4.15 <A HREF = "Section_howto.html#4_15">Output from LAMMPS (thermo, dumps, computes, fixes, variables)</A>
6.15 <A HREF = "Section_howto.html#howto_15">Output from LAMMPS (thermo, dumps, computes, fixes, variables)</A>
<BR>
4.16 <A HREF = "Section_howto.html#4_16">Thermostatting, barostatting, and compute temperature</A>
6.16 <A HREF = "Section_howto.html#howto_16">Thermostatting, barostatting, and compute temperature</A>
<BR>
4.17 <A HREF = "Section_howto.html#4_17">Walls</A>
6.17 <A HREF = "Section_howto.html#howto_17">Walls</A>
<BR>
4.18 <A HREF = "Section_howto.html#4_18">Elastic constants</A>
6.18 <A HREF = "Section_howto.html#howto_18">Elastic constants</A>
<BR>
4.19 <A HREF = "Section_howto.html#4_19">Library interface to LAMMPS</A>
6.19 <A HREF = "Section_howto.html#howto_19">Library interface to LAMMPS</A>
<BR>
4.20 <A HREF = "Section_howto.html#4_20">Calculating thermal conductivity</A>
6.20 <A HREF = "Section_howto.html#howto_20">Calculating thermal conductivity</A>
<BR>
4.21 <A HREF = "Section_howto.html#4_21">Calculating viscosity</A>
6.21 <A HREF = "Section_howto.html#howto_21">Calculating viscosity</A>
<BR></UL>
<LI><A HREF = "Section_example.html">Example problems</A>
@ -170,37 +190,65 @@ it gives quick access to documentation for all LAMMPS commands.
<LI><A HREF = "Section_tools.html">Additional tools</A>
<LI><A HREF = "Section_modify.html">Modifying & Extending LAMMPS</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">Thermodynamic output options</A>
<BR>
10.13 <A HREF = "Section_modify.html#mod_13">Variable options</A>
<BR>
10.14 <A HREF = "Section_modify.html#mod_14">Submitting new features for inclusion in LAMMPS</A>
<BR></UL>
<LI><A HREF = "Section_python.html">Python interface</A>
<UL> 9.1 <A HREF = "Section_python.html#9_1">Extending Python with a serial version of LAMMPS</A>
<UL> 11.1 <A HREF = "Section_python.html#py_1">Extending Python with a serial version of LAMMPS</A>
<BR>
9.2 <A HREF = "Section_python.html#9_2">Creating a shared MPI library</A>
11.2 <A HREF = "Section_python.html#py_2">Creating a shared MPI library</A>
<BR>
9.3 <A HREF = "Section_python.html#9_3">Extending Python with a parallel version of LAMMPS</A>
11.3 <A HREF = "Section_python.html#py_3">Extending Python with a parallel version of LAMMPS</A>
<BR>
9.4 <A HREF = "Section_python.html#9_4">Extending Python with MPI</A>
11.4 <A HREF = "Section_python.html#py_4">Extending Python with MPI</A>
<BR>
9.5 <A HREF = "Section_python.html#9_5">Testing the Python-LAMMPS interface</A>
11.5 <A HREF = "Section_python.html#py_5">Testing the Python-LAMMPS interface</A>
<BR>
9.6 <A HREF = "Section_python.html#9_6">Using LAMMPS from Python</A>
11.6 <A HREF = "Section_python.html#py_6">Using LAMMPS from Python</A>
<BR>
9.7 <A HREF = "Section_python.html#9_7">Example Python scripts that use LAMMPS</A>
11.7 <A HREF = "Section_python.html#py_7">Example Python scripts that use LAMMPS</A>
<BR></UL>
<LI><A HREF = "Section_errors.html">Errors</A>
<UL> 10.1 <A HREF = "Section_errors.html#10_1">Common problems</A>
<UL> 12.1 <A HREF = "Section_errors.html#err_1">Common problems</A>
<BR>
10.2 <A HREF = "Section_errors.html#10_2">Reporting bugs</A>
12.2 <A HREF = "Section_errors.html#err_2">Reporting bugs</A>
<BR>
10.3 <A HREF = "Section_errors.html#10_3">Error & warning messages</A>
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> 11.1 <A HREF = "Section_history.html#11_1">Coming attractions</A>
<UL> 13.1 <A HREF = "Section_history.html#hist_1">Coming attractions</A>
<BR>
11.2 <A HREF = "Section_history.html#11_2">Past versions</A>
13.2 <A HREF = "Section_history.html#hist_2">Past versions</A>
<BR></UL>
</OL>
@ -287,6 +335,46 @@ it gives quick access to documentation for all LAMMPS commands.

Binary file not shown.

View File

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

654
doc/Section_accelerate.html Normal file
View File

@ -0,0 +1,654 @@
<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>
5.1 <A HREF = "#acc_1">OPT package</A><BR>
5.2 <A HREF = "#acc_2">USER-OMP package</A><BR>
5.3 <A HREF = "#acc_3">GPU package</A><BR>
5.4 <A HREF = "#acc_4">USER-CUDA package</A><BR>
5.5 <A HREF = "#acc_5">Comparison of GPU and USER-CUDA packages</A> <BR>
<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, if you have the appropriate
hardware on your system.
</P>
<P>The accelerated styles have the same name as the standard styles,
except that a suffix is appended. Otherwise, the syntax for the
command is identical, their functionality is the same, and the
numerical results it produces should also be identical, except for
precision and round-off issues.
</P>
<P>For example, all of these variants of the basic Lennard-Jones pair
style exist in LAMMPS:
</P>
<UL><LI><A HREF = "pair_lj.html">pair_style lj/cut</A>
<LI><A HREF = "pair_lj.html">pair_style lj/cut/opt</A>
<LI><A HREF = "pair_lj.html">pair_style lj/cut/omp</A>
<LI><A HREF = "pair_lj.html">pair_style lj/cut/gpu</A>
<LI><A HREF = "pair_lj.html">pair_style lj/cut/cuda</A>
</UL>
<P>Assuming you have built LAMMPS with the appropriate package, these
styles can be invoked by specifying them explicitly in your input
script. Or you can use the <A HREF = "Section_start.html#start_6">-suffix command-line
switch</A> to invoke the accelerated versions
automatically, without changing your input script. The
<A HREF = "suffix.html">suffix</A> command allows you to set a suffix explicitly and
to turn off/on the comand-line switch setting, both from within your
input script.
</P>
<P>Styles with an "opt" suffix are part of the OPT package and typically
speed-up the pairwise calculations of your simulation by 5-25%.
</P>
<P>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.
</P>
<P>Styles with a "gpu" or "cuda" suffix are part of the GPU or USER-CUDA
packages, and can be run on NVIDIA GPUs associated with your CPUs.
The speed-up due to GPU usage depends on a variety of factors, as
discussed below.
</P>
<P>To see what styles are currently available in each of the accelerated
packages, see <A HREF = "Section_commands.html#cmd_5">this section</A> of the
manual. A list of accelerated styles is included in the pair, fix,
compute, and kspace sections.
</P>
<P>The following sections explain:
</P>
<UL><LI>what hardware and software the accelerated styles require
<LI>how to build LAMMPS with the accelerated packages in place
<LI>what changes (if any) are needed in your input scripts
<LI>guidelines for best performance
<LI>speed-ups you can expect
</UL>
<P>The final section compares and contrasts the GPU and USER-CUDA
packages, since they are both designed to use NVIDIA GPU hardware.
</P>
<HR>
<HR>
<H4><A NAME = "acc_1"></A>5.1 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>The procedure for building LAMMPS with the OPT package is simple. It
is the same as for any other package which has no additional library
dependencies:
</P>
<PRE>make yes-opt
make machine
</PRE>
<P>If your input script uses one of the OPT pair styles,
you can run it as follows:
</P>
<PRE>lmp_machine -sf opt < in.script
mpirun -np 4 lmp_machine -sf opt < in.script
</PRE>
<P>You should see a reduction in the "Pair time" printed out at the end
of the run. On most machines and problems, this will typically be a 5
to 20% savings.
</P>
<HR>
<HR>
<H4><A NAME = "acc_2"></A>5.2 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, all dihedral
styles and a few fixes in LAMMPS. The package currently uses the OpenMP
interface which requires using a specific compiler flag in the makefile
to enable multiple threads; without this flag the corresponding pair
styles will still be compiled and work, but do not support multi-threading.
</P>
<P><B>Building LAMMPS with the USER-OMP package:</B>
</P>
<P>The procedure for building LAMMPS with the USER-OMP package is simple.
You have to edit your machine specific makefile to add the flag to
enable OpenMP support to the CCFLAGS and LINKFLAGS variables. For the
GNU compilers for example this flag is called <I>-fopenmp</I>. Check your
compiler documentation to find out which flag you need to add.
The rest of the compilation is the same as for any other package which
has no additional library dependencies:
</P>
<PRE>make yes-user-omp
make machine
</PRE>
<P>Please note that this will only install accelerated versions
of styles that are already installed, so you want to install
this package as the last package, or else you may be missing
some accelerated styles. If you plan to uninstall some package,
you should first uninstall the USER-OMP package then the other
package and then re-install USER-OMP, to make sure that there
are no orphaned <I>omp</I> style files present, which would lead to
compilation errors.
</P>
<P>If your input script uses one of regular styles that are also
exist as an OpenMP version in the USER-OMP package you can run
it as follows:
</P>
<PRE>env OMP_NUM_THREADS=4 lmp_serial -sf omp -in in.script
env OMP_NUM_THREADS=2 mpirun -np 2 lmp_machine -sf omp -in in.script
mpirun -x OMP_NUM_THREADS=2 -np 2 lmp_machine -sf omp -in in.script
</PRE>
<P>The value of the environment variable OMP_NUM_THREADS determines how
many threads per MPI task are launched. All three examples above use
a total of 4 CPU cores. For different MPI implementations the method
to pass the OMP_NUM_THREADS environment variable to all processes is
different. Two different variants, one for MPICH and OpenMPI, respectively
are shown above. Please check the documentation of your MPI installation
for additional details. Alternatively, the value provided by OMP_NUM_THREADS
can be overridded with the <A HREF = "package.html">package omp</A> command.
Depending on which styles are accelerated in your input, you should
see a reduction in the "Pair time" and/or "Bond time" and "Loop time"
printed out at the end of the run. The optimal ratio of MPI to OpenMP
can vary a lot and should always be confirmed through some benchmark
runs for the current system and on the current machine.
</P>
<P><B>Restrictions:</B>
</P>
<P>None of the pair styles in the USER-OMP package support the "inner",
"middle", "outer" options for r-RESPA integration, only the "pair"
option is supported.
</P>
<P><B>Parallel efficiency and performance tips:</B>
</P>
<P>In most simple cases the MPI parallelization in LAMMPS is more
efficient than multi-threading implemented in the USER-OMP package.
Also the parallel efficiency varies between individual styles.
On the other hand, in many cases you still want to use the <I>omp</I> version
- even when compiling or running without OpenMP support - since they
all contain optimizations similar to those in the OPT package, which
can result in serial speedup.
</P>
<P>Using multi-threading is most 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. Intel Xeon 53xx
(Clovertown) and 54xx (Harpertown) quad core processors. Running
one MPI task per CPU core will result in significant performance
degradation, so that running with 4 or even only 2 MPI tasks per
nodes is faster. Running in hybrid MPI+OpenMP mode will reduce the
inter-node communication bandwidth contention in the same way,
but offers and additional speedup from utilizing the otherwise
idle CPU cores.
<LI>The interconnect used for MPI communication is not able to provide
sufficient bandwidth for a large number of MPI tasks per node.
This applies for example to running over gigabit ethernet or
on Cray XT4 or XT5 series supercomputers. Same as in the aforementioned
case this effect worsens with using an increasing number of nodes.
<LI>The input is a system that has an inhomogeneous particle density
which cannot be mapped well to the domain decomposition scheme
that LAMMPS employs. While this can be to some degree alleviated
through using the <A HREF = "processors.html">processors</A> keyword, multi-threading
provides a parallelism that parallelizes over the number of particles
not their distribution in space.
<LI>Finally, multi-threaded styles can improve performance when running
LAMMPS in "capability mode", i.e. near the point where the MPI
parallelism scales out. This can happen in particular when using
as kspace style for long-range electrostatics. Here the scaling
of the kspace style is the performance limiting factor and using
multi-threaded styles allows to operate the kspace style at the
limit of scaling and then increase performance parallelizing
the real space calculations with hybrid MPI+OpenMP. Sometimes
additional speedup can be achived by increasing the real-space
coulomb cutoff and thus reducing the work in the kspace part.
</UL>
<P>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.
</P>
<P>Using threads on hyper-threading enabled cores is usually
counterproductive, as the cost in additional memory bandwidth
requirements is not offset by the gain in CPU utilization
through hyper-threading.
</P>
<P>A description of the multi-threading strategy 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>
<HR>
<HR>
<H4><A NAME = "acc_3"></A>5.3 GPU package
</H4>
<P>The GPU package was developed by Mike Brown at ORNL. It provides GPU
versions of several pair styles and for long-range Coulombics via the
PPPM command. It has the following features:
</P>
<UL><LI>The package is designed to exploit common GPU hardware configurations
where one or more GPUs are coupled with many cores of a multi-core
CPUs, e.g. within a node of a parallel machine.
<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 constructed 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>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><B>Hardware and software requirements:</B>
</P>
<P>To use this package, you currently need to have specific NVIDIA
hardware and install specific NVIDIA CUDA software on your system:
</P>
<UL><LI>Check if you have an NVIDIA card: cat /proc/driver/nvidia/cards/0
<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>Follow the instructions in lammps/lib/gpu/README to build the library (see below)
<LI>Run lammps/lib/gpu/nvc_get_devices to list supported devices and properties
</UL>
<P><B>Building LAMMPS with the GPU package:</B>
</P>
<P>As with other packages that include a separately compiled library, you
need to first build the GPU library, before building LAMMPS itself.
General instructions for doing this are in <A HREF = "doc/Section_start.html#start_3">this
section</A> of the manual. For this
package, do the following, using a Makefile in lib/gpu appropriate for
your system:
</P>
<PRE>cd lammps/lib/gpu
make -f Makefile.linux
(see further instructions in lammps/lib/gpu/README)
</PRE>
<P>If you are successful, you will produce the file lib/libgpu.a.
</P>
<P>Now you are ready to build LAMMPS with the GPU package installed:
</P>
<PRE>cd lammps/src
make yes-gpu
make machine
</PRE>
<P>Note that the lo-level Makefile (e.g. src/MAKE/Makefile.linux) has
these settings: gpu_SYSINC, gpu_SYSLIB, gpu_SYSPATH. These need to be
set appropriately to include the paths and settings for the CUDA
system software on your machine. See src/MAKE/Makefile.g++ for an
example.
</P>
<P><B>GPU configuration</B>
</P>
<P>When using GPUs, you are restricted to one physical GPU per LAMMPS
process, which is an MPI process running on a single core or
processor. Multiple MPI processes (CPU cores) can share a single GPU,
and in many cases it will be more efficient to run this way.
</P>
<P><B>Input script requirements:</B>
</P>
<P>Additional input script requirements to run pair or PPPM styles with a
<I>gpu</I> suffix are as follows:
</P>
<UL><LI>To invoke specific styles from the GPU package, you can either append
"gpu" to the style name (e.g. pair_style lj/cut/gpu), or use the
<A HREF = "Section_start.html#start_6">-suffix command-line switch</A>, or use the
<A HREF = "suffix.html">suffix</A> command.
<LI>The <A HREF = "newton.html">newton pair</A> setting must be <I>off</I>.
<LI>The <A HREF = "package.html">package gpu</A> command must be used near the beginning
of your script to control the GPU selection and initialization
settings. It also has an option to enable asynchronous splitting of
force computations between the CPUs and GPUs.
</UL>
<P>As an example, if you have two GPUs per node and 8 CPU cores per node,
and would like to run on 4 nodes (32 cores) with dynamic balancing of
force calculation across CPU and GPU cores, you could specify
</P>
<PRE>package gpu force/neigh 0 1 -1
</PRE>
<P>In this case, all CPU cores and GPU devices on the nodes would be
utilized. Each GPU device would be shared by 4 CPU cores. The CPU
cores would perform force calculations for some fraction of the
particles at the same time the GPUs performed force calculation for
the other particles.
</P>
<P><B>Timing output:</B>
</P>
<P>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.
</P>
<P>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.
</P>
<P><B>Performance tips:</B>
</P>
<P>Generally speaking, for best performance, you should use multiple CPUs
per GPU, as provided my most multi-core CPU/GPU configurations.
</P>
<P>Because of the large number of cores within each GPU device, it may be
more efficient to run on fewer processes per GPU when the number of
particles per MPI process is small (100's of particles); this can be
necessary to keep the GPU cores busy.
</P>
<P>See the lammps/lib/gpu/README file for instructions on how to build
the GPU library for single, mixed, or double precision. The latter
requires that your GPU card support double precision.
</P>
<HR>
<HR>
<H4><A NAME = "acc_4"></A>5.4 USER-CUDA package
</H4>
<P>The USER-CUDA package was developed by Christian Trott at U Technology
Ilmenau in Germany. It provides NVIDIA GPU versions of many pair
styles, many fixes, a few computes, and for long-range Coulombics via
the PPPM command. It has the following features:
</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-GPU-ized fix or
compute is invoked. Whenever a non-GPU operation occurs (fix,
compute, output), data automatically moves back to the CPU as needed.
This may incur a performance penalty, but should otherwise work
transparently.
<LI>Neighbor lists for GPU-ized pair styles are constructed on the
GPU.
<LI>The package only supports use of a single CPU (core) with each
GPU.
</UL>
<P><B>Hardware and software requirements:</B>
</P>
<P>To use this package, you need to have specific NVIDIA hardware and
install specific 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 in version 3.2 or higher and the
corresponding GPU drivers. The Nvidia Cuda SDK is not required for
LAMMPSCUDA but we recommend it be installed. You can then make sure
that its sample projects can be compiled without problems.
</P>
<P><B>Building LAMMPS with the USER-CUDA package:</B>
</P>
<P>As with other packages that include a separately compiled library, you
need to first build the USER-CUDA library, before building LAMMPS
itself. General instructions for doing this are in <A HREF = "doc/Section_start.html#start_3">this
section</A> of the manual. For this
package, do the following, using settings in the lib/cuda Makefiles
appropriate for your system:
</P>
<UL><LI>Go to the lammps/lib/cuda directory
<LI>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.
<LI>Type "make OPTIONS", where <I>OPTIONS</I> are one or more of the following
options. The settings will be written to the
<I>lib/cuda/Makefile.defaults</I> and used in the next step.
<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 = 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 these timers
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> to determine usage of CUDA FFT library
0 = no CUFFT support (default)
in the future other CUDA-enabled FFT libraries might be supported
</PRE>
<LI>Type "make" to build the library. If you are successful, you will
produce the file lib/libcuda.a.
</UL>
<P>Now you are ready to build LAMMPS with the USER-CUDA package installed:
</P>
<PRE>cd lammps/src
make yes-user-cuda
make machine
</PRE>
<P>Note that the LAMMPS build references the lib/cuda/Makefile.common
file to extract setting specific CUDA settings. So it is important
that you have first built the cuda library (in lib/cuda) using
settings appropriate to your system.
</P>
<P><B>Input script requirements:</B>
</P>
<P>Additional input script requirements to run styles with a <I>cuda</I>
suffix are as follows:
</P>
<UL><LI>To invoke specific styles from the USER-CUDA package, you can either
append "cuda" to the style name (e.g. pair_style lj/cut/cuda), or use
the <A HREF = "Section_start.html#start_6">-suffix command-line switch</A>, or use
the <A HREF = "suffix.html">suffix</A> command. One exception is that the
<A HREF = "kspace_style.html">kspace_style pppm/cuda</A> command has to be requested
explicitly.
<LI>To use the USER-CUDA package with its default settings, no additional
command is needed in your input script. This is because when LAMMPS
starts up, it detects if it has been built with the USER-CUDA package.
See the <A HREF = "Section_start.html#start_6">-cuda command-line switch</A> for
more details.
<LI>To change settings for the USER-CUDA package at run-time, the <A HREF = "package.html">package
cuda</A> command can be used near the beginning of your
input script. See the <A HREF = "package.html">package</A> command doc page for
details.
</UL>
<P><B>Performance tips:</B>
</P>
<P>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.
</P>
<P>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.
</P>
<HR>
<HR>
<H4><A NAME = "acc_5"></A>5.5 Comparison of GPU and USER-CUDA packages
</H4>
<P>Both the GPU and USER-CUDA 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 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>
<HR>
<P><B>Benchmark data:</B>
</P>
<P>NOTE: We plan to add some benchmark results and plots here for the
examples described in the previous section.
</P>
<P>Simulations:
</P>
<P>1. Lennard Jones
</P>
<UL><LI>256,000 atoms
<LI>2.5 A cutoff
<LI>0.844 density
</UL>
<P>2. Lennard Jones
</P>
<UL><LI>256,000 atoms
<LI>5.0 A cutoff
<LI>0.844 density
</UL>
<P>3. Rhodopsin model
</P>
<UL><LI>256,000 atoms
<LI>10A cutoff
<LI>Coulomb via PPPM
</UL>
<P>4. Lihtium-Phosphate
</P>
<UL><LI>295650 atoms
<LI>15A cutoff
<LI>Coulomb via PPPM
</UL>
<P>Hardware:
</P>
<P>Workstation:
</P>
<UL><LI>2x GTX470
<LI>i7 950@3GHz
<LI>24Gb DDR3 @ 1066Mhz
<LI>CentOS 5.5
<LI>CUDA 3.2
<LI>Driver 260.19.12
</UL>
<P>eStella:
</P>
<UL><LI>6 Nodes
<LI>2xC2050
<LI>2xQDR Infiniband interconnect(aggregate bandwidth 80GBps)
<LI>Intel X5650 HexCore @ 2.67GHz
<LI>SL 5.5
<LI>CUDA 3.2
<LI>Driver 260.19.26
</UL>
<P>Keeneland:
</P>
<UL><LI>HP SL-390 (Ariston) cluster
<LI>120 nodes
<LI>2x Intel Westmere hex-core CPUs
<LI>3xC2070s
<LI>QDR InfiniBand interconnect
</UL>
</HTML>

644
doc/Section_accelerate.txt Normal file
View File

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

View File

@ -1,5 +1,5 @@
<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_howto.html">Next Section</A>
<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>
@ -11,18 +11,20 @@
<H3>3. Commands
</H3>
<P>This section describes how a LAMMPS input script is formatted and what
commands are used to define a LAMMPS simulation.
<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 = "#3_1">LAMMPS input script</A><BR>
3.2 <A HREF = "#3_2">Parsing rules</A><BR>
3.3 <A HREF = "#3_3">Input script structure</A><BR>
3.4 <A HREF = "#3_4">Commands listed by category</A><BR>
3.5 <A HREF = "#3_5">Commands listed alphabetically</A> <BR>
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>
<A NAME = "3_1"></A><H4>3.1 LAMMPS input script
<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
@ -76,7 +78,7 @@ command lists restrictions on how the command can be used.
</P>
<HR>
<A NAME = "3_2"></A><H4>3.2 Parsing rules
<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
@ -135,7 +137,7 @@ allowed, but that should be sufficient for most use cases.
</P>
<HR>
<H4><A NAME = "3_3"></A>3.3 Input script structure
<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
@ -225,11 +227,11 @@ the <A HREF = "minimize.html">minimize</A> command. A parallel tempering
</P>
<HR>
<A NAME = "3_4"></A><H4>3.4 Commands listed by category
<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 = "#3_5">next section</A> lists the same commands alphabetically. Note that
some style options for some commands are part of specific LAMMPS
<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
@ -264,12 +266,11 @@ in the command's documentation.
</P>
<P>Settings:
</P>
<P><A HREF = "communicate.html">communicate</A>, <A HREF = "dipole.html">dipole</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 = "shape.html">shape</A>,
<A HREF = "timestep.html">timestep</A>, <A HREF = "velocity.html">velocity</A>
<P><A HREF = "communicate.html">communicate</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>
@ -282,10 +283,11 @@ in the command's documentation.
</P>
<P>Output:
</P>
<P><A HREF = "dump.html">dump</A>, <A HREF = "dump_modify.html">dump_modify</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_restart.html">write_restart</A>
<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 = "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_restart.html">write_restart</A>
</P>
<P>Actions:
</P>
@ -303,12 +305,12 @@ in the command's documentation.
</P>
<HR>
<H4><A NAME = "3_5"></A><A NAME = "comm"></A>3.5 Individual commands
<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 = "#3_4">previous
section</A> lists the same commands, grouped by category. Note that
some style options for some commands are part of specific LAMMPS
listing below of styles within certain commands. The <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
@ -318,17 +320,17 @@ in the command's documentation.
<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 = "bond_coeff.html">bond_coeff</A></TD><TD ><A HREF = "bond_style.html">bond_style</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "boundary.html">boundary</A></TD><TD ><A HREF = "change_box.html">change_box</A></TD><TD ><A HREF = "clear.html">clear</A></TD><TD ><A HREF = "communicate.html">communicate</A></TD><TD ><A HREF = "compute.html">compute</A></TD><TD ><A HREF = "compute_modify.html">compute_modify</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "create_atoms.html">create_atoms</A></TD><TD ><A HREF = "create_box.html">create_box</A></TD><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></TR>
<TR ALIGN="center"><TD ><A HREF = "dihedral_style.html">dihedral_style</A></TD><TD ><A HREF = "dimension.html">dimension</A></TD><TD ><A HREF = "dipole.html">dipole</A></TD><TD ><A HREF = "displace_atoms.html">displace_atoms</A></TD><TD ><A HREF = "displace_box.html">displace_box</A></TD><TD ><A HREF = "dump.html">dump</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "dihedral_style.html">dihedral_style</A></TD><TD ><A HREF = "dimension.html">dimension</A></TD><TD ><A HREF = "displace_atoms.html">displace_atoms</A></TD><TD ><A HREF = "displace_box.html">displace_box</A></TD><TD ><A HREF = "dump.html">dump</A></TD><TD ><A HREF = "dump_image.html">dump image</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "dump_modify.html">dump_modify</A></TD><TD ><A HREF = "echo.html">echo</A></TD><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></TR>
<TR ALIGN="center"><TD ><A HREF = "improper_coeff.html">improper_coeff</A></TD><TD ><A HREF = "improper_style.html">improper_style</A></TD><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></TR>
<TR ALIGN="center"><TD ><A HREF = "label.html">label</A></TD><TD ><A HREF = "lattice.html">lattice</A></TD><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></TR>
<TR ALIGN="center"><TD ><A HREF = "min_style.html">min_style</A></TD><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></TR>
<TR ALIGN="center"><TD ><A HREF = "nthreads.html">nthreads</A></TD><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 = "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 = "read_data.html">read_data</A></TD><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></TR>
<TR ALIGN="center"><TD ><A HREF = "reset_timestep.html">reset_timestep</A></TD><TD ><A HREF = "restart.html">restart</A></TD><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 = "shape.html">shape</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "shell.html">shell</A></TD><TD ><A HREF = "special_bonds.html">special_bonds</A></TD><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></TR>
<TR ALIGN="center"><TD ><A HREF = "thermo_style.html">thermo_style</A></TD><TD ><A HREF = "timestep.html">timestep</A></TD><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></TR>
<TR ALIGN="center"><TD ><A HREF = "variable.html">variable</A></TD><TD ><A HREF = "velocity.html">velocity</A></TD><TD ><A HREF = "write_restart.html">write_restart</A>
<TR ALIGN="center"><TD ><A HREF = "package.html">package</A></TD><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></TR>
<TR ALIGN="center"><TD ><A HREF = "prd.html">prd</A></TD><TD ><A HREF = "print.html">print</A></TD><TD ><A HREF = "processors.html">processors</A></TD><TD ><A HREF = "read_data.html">read_data</A></TD><TD ><A HREF = "read_restart.html">read_restart</A></TD><TD ><A HREF = "region.html">region</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "replicate.html">replicate</A></TD><TD ><A HREF = "reset_timestep.html">reset_timestep</A></TD><TD ><A HREF = "restart.html">restart</A></TD><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></TR>
<TR ALIGN="center"><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><TD ><A HREF = "tad.html">tad</A></TD><TD ><A HREF = "temper.html">temper</A></TD><TD ><A HREF = "thermo.html">thermo</A></TD></TR>
<TR ALIGN="center"><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><TD ><A HREF = "uncompute.html">uncompute</A></TD><TD ><A HREF = "undump.html">undump</A></TD><TD ><A HREF = "unfix.html">unfix</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "units.html">units</A></TD><TD ><A HREF = "variable.html">variable</A></TD><TD ><A HREF = "velocity.html">velocity</A></TD><TD ><A HREF = "write_restart.html">write_restart</A>
</TD></TR></TABLE></DIV>
<HR>
@ -341,22 +343,35 @@ of each style or click on the style itself for a full description:
<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</A></TD><TD ><A HREF = "fix_aveforce.html">aveforce</A></TD><TD ><A HREF = "fix_ave_atom.html">ave/atom</A></TD><TD ><A HREF = "fix_ave_correlate.html">ave/correlate</A></TD><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></TR>
<TR ALIGN="center"><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><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></TR>
<TR ALIGN="center"><TD ><A HREF = "fix_efield.html">efield</A></TD><TD ><A HREF = "fix_enforce2d.html">enforce2d</A></TD><TD ><A HREF = "fix_evaporate.html">evaporate</A></TD><TD ><A HREF = "fix_external.html">external</A></TD><TD ><A HREF = "fix_freeze.html">freeze</A></TD><TD ><A HREF = "fix_gravity.html">gravity</A></TD><TD ><A HREF = "fix_heat.html">heat</A></TD><TD ><A HREF = "fix_indent.html">indent</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "fix_langevin.html">langevin</A></TD><TD ><A HREF = "fix_lineforce.html">lineforce</A></TD><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</A></TD><TD ><A HREF = "fix_nph_asphere.html">nph/asphere</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "fix_nph_sphere.html">nph/sphere</A></TD><TD ><A HREF = "fix_nh.html">npt</A></TD><TD ><A HREF = "fix_npt_asphere.html">npt/asphere</A></TD><TD ><A HREF = "fix_npt_sphere.html">npt/sphere</A></TD><TD ><A HREF = "fix_nve.html">nve</A></TD><TD ><A HREF = "fix_nve_asphere.html">nve/asphere</A></TD><TD ><A HREF = "fix_nve_limit.html">nve/limit</A></TD><TD ><A HREF = "fix_nve_noforce.html">nve/noforce</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "fix_nve_sphere.html">nve/sphere</A></TD><TD ><A HREF = "fix_nh.html">nvt</A></TD><TD ><A HREF = "fix_nvt_asphere.html">nvt/asphere</A></TD><TD ><A HREF = "fix_nvt_sllod.html">nvt/sllod</A></TD><TD ><A HREF = "fix_nvt_sphere.html">nvt/sphere</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></TR>
<TR ALIGN="center"><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_qeq_comb.html">qeq/comb</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_rigid.html">rigid</A></TD><TD ><A HREF = "fix_rigid.html">rigid/nve</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "fix_rigid.html">rigid/nvt</A></TD><TD ><A HREF = "fix_setforce.html">setforce</A></TD><TD ><A HREF = "fix_shake.html">shake</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><TD ><A HREF = "fix_store_force.html">store/force</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "fix_store_state.html">store/state</A></TD><TD ><A HREF = "fix_temp_berendsen.html">temp/berendsen</A></TD><TD ><A HREF = "fix_temp_rescale.html">temp/rescale</A></TD><TD ><A HREF = "fix_thermal_conductivity.html">thermal/conductivity</A></TD><TD ><A HREF = "fix_tmd.html">tmd</A></TD><TD ><A HREF = "fix_ttm.html">ttm</A></TD><TD ><A HREF = "fix_viscosity.html">viscosity</A></TD><TD ><A HREF = "fix_viscous.html">viscous</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "fix_wall.html">wall/colloid</A></TD><TD ><A HREF = "fix_wall_gran.html">wall/gran</A></TD><TD ><A HREF = "fix_wall.html">wall/harmonic</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_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>
<TR ALIGN="center"><TD ><A HREF = "fix_efield.html">efield</A></TD><TD ><A HREF = "fix_enforce2d.html">enforce2d</A></TD><TD ><A HREF = "fix_evaporate.html">evaporate</A></TD><TD ><A HREF = "fix_external.html">external</A></TD><TD ><A HREF = "fix_freeze.html">freeze</A></TD><TD ><A HREF = "fix_gcmc.html">gcmc</A></TD><TD ><A HREF = "fix_gravity.html">gravity</A></TD><TD ><A HREF = "fix_heat.html">heat</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "fix_indent.html">indent</A></TD><TD ><A HREF = "fix_langevin.html">langevin</A></TD><TD ><A HREF = "fix_lineforce.html">lineforce</A></TD><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</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "fix_nphug.html">nphug</A></TD><TD ><A HREF = "fix_nph_asphere.html">nph/asphere</A></TD><TD ><A HREF = "fix_nph_sphere.html">nph/sphere</A></TD><TD ><A HREF = "fix_nh.html">npt</A></TD><TD ><A HREF = "fix_npt_asphere.html">npt/asphere</A></TD><TD ><A HREF = "fix_npt_sphere.html">npt/sphere</A></TD><TD ><A HREF = "fix_nve.html">nve</A></TD><TD ><A HREF = "fix_nve_asphere.html">nve/asphere</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "fix_nve_asphere_noforce.html">nve/asphere/noforce</A></TD><TD ><A HREF = "fix_nve_limit.html">nve/limit</A></TD><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</A></TD><TD ><A HREF = "fix_nve_tri.html">nve/tri</A></TD><TD ><A HREF = "fix_nh.html">nvt</A></TD><TD ><A HREF = "fix_nvt_asphere.html">nvt/asphere</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "fix_nvt_sllod.html">nvt/sllod</A></TD><TD ><A HREF = "fix_nvt_sphere.html">nvt/sphere</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></TR>
<TR ALIGN="center"><TD ><A HREF = "fix_qeq_comb.html">qeq/comb</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><TD ><A HREF = "fix_rigid.html">rigid</A></TD><TD ><A HREF = "fix_rigid.html">rigid/nve</A></TD><TD ><A HREF = "fix_rigid.html">rigid/nvt</A></TD><TD ><A HREF = "fix_setforce.html">setforce</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "fix_shake.html">shake</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><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</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "fix_temp_rescale.html">temp/rescale</A></TD><TD ><A HREF = "fix_thermal_conductivity.html">thermal/conductivity</A></TD><TD ><A HREF = "fix_tmd.html">tmd</A></TD><TD ><A HREF = "fix_ttm.html">ttm</A></TD><TD ><A HREF = "fix_viscosity.html">viscosity</A></TD><TD ><A HREF = "fix_viscous.html">viscous</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/lj126</A></TD><TD ><A HREF = "fix_wall.html">wall/lj93</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 fix styles contributed by users, which can be used if
<A HREF = "Section_start.html#2_3">LAMMPS is built with the appropriate package</A>.
<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_atc.html">atc</A></TD><TD ><A HREF = "fix_imd.html">imd</A></TD><TD ><A HREF = "fix_langevin_eff.html">langevin/eff</A></TD><TD ><A HREF = "fix_nh_eff.html">nph/eff</A></TD><TD ><A HREF = "fix_nh_eff.html">npt/eff</A></TD><TD ><A HREF = "fix_nve_eff.html">nve/eff</A></TD></TR>
<TR ALIGN="center"><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_qeq_reax.html">qeq/reax</A></TD><TD ><A HREF = "fix_smd.html">smd</A></TD><TD ><A HREF = "fix_temp_rescale_eff.html">temp/rescale/eff</A>
<TR ALIGN="center"><TD ><A HREF = "fix_addtorque.html">addtorque</A></TD><TD ><A HREF = "fix_atc.html">atc</A></TD><TD ><A HREF = "fix_imd.html">imd</A></TD><TD ><A HREF = "fix_langevin_eff.html">langevin/eff</A></TD><TD ><A HREF = "fix_meso.html">meso</A></TD><TD ><A HREF = "fix_meso_stationary.html">meso/stationary</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "fix_nh_eff.html">nph/eff</A></TD><TD ><A HREF = "fix_nh_eff.html">npt/eff</A></TD><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_qeq_reax.html">qeq/reax</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "fix_smd.html">smd</A></TD><TD ><A HREF = "fix_temp_rescale_eff.html">temp/rescale/eff</A>
</TD></TR></TABLE></DIV>
<P>These are accelerated fix styles, which can be used if LAMMPS is
built with the <A HREF = "Section_accelerate.html">appropriate accelerated
package</A>.
</P>
<DIV ALIGN=center><TABLE BORDER=1 >
<TR ALIGN="center"><TD ><A HREF = "fix_freeze.html">freeze/cuda</A></TD><TD ><A HREF = "fix_addforce.html">addforce/cuda</A></TD><TD ><A HREF = "fix_aveforce.html">aveforce/cuda</A></TD><TD ><A HREF = "fix_enforce2d.html">enforce2d/cuda</A></TD><TD ><A HREF = "fix_gravity.html">gravity/cuda</A></TD><TD ><A HREF = "fix_gravity.html">gravity/omp</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "fix_nh.html">npt/cuda</A></TD><TD ><A HREF = "fix_nh.html">nve/cuda</A></TD><TD ><A HREF = "fix_nve_sphere.html">nve/sphere/omp</A></TD><TD ><A HREF = "fix_nh.html">nvt/cuda</A></TD><TD ><A HREF = "fix_qeq_comb.html">qeq/comb/omp</A></TD><TD ><A HREF = "fix_setforce.html">setforce/cuda</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "fix_shake.html">shake/cuda</A></TD><TD ><A HREF = "fix_temp_berendsen.html">temp/berendsen/cuda</A></TD><TD ><A HREF = "fix_temp_rescale.html">temp/rescale/cuda</A></TD><TD ><A HREF = "fix_temp_rescale.html">temp/rescale/limit/cuda</A></TD><TD ><A HREF = "fix_viscous.html">viscous/cuda</A>
</TD></TR></TABLE></DIV>
<HR>
@ -372,16 +387,26 @@ each style or click on the style itself for a full description:
<TR ALIGN="center"><TD ><A HREF = "compute_erotate_asphere.html">erotate/asphere</A></TD><TD ><A HREF = "compute_erotate_sphere.html">erotate/sphere</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_molecule.html">gyration/molecule</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_ke.html">ke</A></TD><TD ><A HREF = "compute_ke_atom.html">ke/atom</A></TD><TD ><A HREF = "compute_msd.html">msd</A></TD><TD ><A HREF = "compute_msd_molecule.html">msd/molecule</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "compute_pair.html">pair</A></TD><TD ><A HREF = "compute_pair_local.html">pair/local</A></TD><TD ><A HREF = "compute_pe.html">pe</A></TD><TD ><A HREF = "compute_pe_atom.html">pe/atom</A></TD><TD ><A HREF = "compute_pressure.html">pressure</A></TD><TD ><A HREF = "compute_property_atom.html">property/atom</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "compute_property_local.html">property/local</A></TD><TD ><A HREF = "compute_property_molecule.html">property/molecule</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_stress_atom.html">stress/atom</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "compute_temp.html">temp</A></TD><TD ><A HREF = "compute_temp_asphere.html">temp/asphere</A></TD><TD ><A HREF = "compute_temp_com.html">temp/com</A></TD><TD ><A HREF = "compute_temp_deform.html">temp/deform</A></TD><TD ><A HREF = "compute_temp_partial.html">temp/partial</A></TD><TD ><A HREF = "compute_temp_profile.html">temp/profile</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "compute_temp_ramp.html">temp/ramp</A></TD><TD ><A HREF = "compute_temp_region.html">temp/region</A></TD><TD ><A HREF = "compute_temp_sphere.html">temp/sphere</A></TD><TD ><A HREF = "compute_ti.html">ti</A>
<TR ALIGN="center"><TD ><A HREF = "compute_property_local.html">property/local</A></TD><TD ><A HREF = "compute_property_molecule.html">property/molecule</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></TR>
<TR ALIGN="center"><TD ><A HREF = "compute_stress_atom.html">stress/atom</A></TD><TD ><A HREF = "compute_temp.html">temp</A></TD><TD ><A HREF = "compute_temp_asphere.html">temp/asphere</A></TD><TD ><A HREF = "compute_temp_com.html">temp/com</A></TD><TD ><A HREF = "compute_temp_deform.html">temp/deform</A></TD><TD ><A HREF = "compute_temp_partial.html">temp/partial</A></TD></TR>
<TR ALIGN="center"><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><TD ><A HREF = "compute_temp_sphere.html">temp/sphere</A></TD><TD ><A HREF = "compute_ti.html">ti</A>
</TD></TR></TABLE></DIV>
<P>These are compute styles contributed by users, which can be used if
<A HREF = "Section_start.html#2_3">LAMMPS is built with the appropriate package</A>.
<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_ke_eff.html">ke/eff</A></TD><TD ><A HREF = "compute_ke_atom_eff.html">ke/atom/eff</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>
<TR ALIGN="center"><TD ><A HREF = "compute_ackland_atom.html">ackland/atom</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><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></TR>
<TR ALIGN="center"><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>
<P>These are accelerated compute styles, which can be used if LAMMPS is
built with the <A HREF = "Section_accelerate.html">appropriate accelerated
package</A>.
</P>
<DIV ALIGN=center><TABLE BORDER=1 >
<TR ALIGN="center"><TD ><A HREF = "compute_pe.html">pe/cuda</A></TD><TD ><A HREF = "compute_pressure.html">pressure/cuda</A></TD><TD ><A HREF = "compute_temp.html">temp/cuda</A></TD><TD ><A HREF = "compute_temp_partial.html">temp/partial/cuda</A>
</TD></TR></TABLE></DIV>
<HR>
@ -392,33 +417,72 @@ each style or click on the style itself for a full description:
potentials. Click on the style itself for a full description:
</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_airebo.html">airebo</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_born.html">born</A></TD><TD ><A HREF = "pair_born.html">born/coul/long</A></TD><TD ><A HREF = "pair_buck.html">buck</A></TD><TD ><A HREF = "pair_buck.html">buck/coul/cut</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_buck.html">buck/coul/long</A></TD><TD ><A HREF = "pair_colloid.html">colloid</A></TD><TD ><A HREF = "pair_comb.html">comb</A></TD><TD ><A HREF = "pair_coul.html">coul/cut</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_coul.html">coul/debye</A></TD><TD ><A HREF = "pair_coul.html">coul/long</A></TD><TD ><A HREF = "pair_dipole.html">dipole/cut</A></TD><TD ><A HREF = "pair_dpd.html">dpd</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_dpd.html">dpd/tstat</A></TD><TD ><A HREF = "pair_dsmc.html">dsmc</A></TD><TD ><A HREF = "pair_eam.html">eam</A></TD><TD ><A HREF = "pair_eam.html">eam/opt</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_eam.html">eam/alloy</A></TD><TD ><A HREF = "pair_eam.html">eam/alloy/opt</A></TD><TD ><A HREF = "pair_eam.html">eam/fs</A></TD><TD ><A HREF = "pair_eam.html">eam/fs/opt</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_eim.html">eim</A></TD><TD ><A HREF = "pair_gauss.html">gauss</A></TD><TD ><A HREF = "pair_gayberne.html">gayberne</A></TD><TD ><A HREF = "pair_gayberne.html">gayberne/gpu</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_gran.html">gran/hertz/history</A></TD><TD ><A HREF = "pair_gran.html">gran/hooke</A></TD><TD ><A HREF = "pair_gran.html">gran/hooke/history</A></TD><TD ><A HREF = "pair_hbond_dreiding.html">hbond/dreiding/lj</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_hbond_dreiding.html">hbond/dreiding/morse</A></TD><TD ><A HREF = "pair_charmm.html">lj/charmm/coul/charmm</A></TD><TD ><A HREF = "pair_charmm.html">lj/charmm/coul/charmm/implicit</A></TD><TD ><A HREF = "pair_charmm.html">lj/charmm/coul/long</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_charmm.html">lj/charmm/coul/long/gpu</A></TD><TD ><A HREF = "pair_charmm.html">lj/charmm/coul/long/opt</A></TD><TD ><A HREF = "pair_class2.html">lj/class2</A></TD><TD ><A HREF = "pair_class2.html">lj/class2/coul/cut</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_class2.html">lj/class2/coul/long</A></TD><TD ><A HREF = "pair_lj.html">lj/cut</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/gpu</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/opt</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_lj.html">lj/cut/coul/cut</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/coul/cut/gpu</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/coul/debye</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/coul/long</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_lj.html">lj/cut/coul/long/gpu</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/coul/long/tip4p</A></TD><TD ><A HREF = "pair_lj_expand.html">lj/expand</A></TD><TD ><A HREF = "pair_gromacs.html">lj/gromacs</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_gromacs.html">lj/gromacs/coul/gromacs</A></TD><TD ><A HREF = "pair_lj_smooth.html">lj/smooth</A></TD><TD ><A HREF = "pair_lj96_cut.html">lj96/cut</A></TD><TD ><A HREF = "pair_lj96_cut.html">lj96/cut/gpu</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_lubricate.html">lubricate</A></TD><TD ><A HREF = "pair_meam.html">meam</A></TD><TD ><A HREF = "pair_morse.html">morse</A></TD><TD ><A HREF = "pair_morse.html">morse/opt</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_peri.html">peri/lps</A></TD><TD ><A HREF = "pair_peri.html">peri/pmb</A></TD><TD ><A HREF = "pair_reax.html">reax</A></TD><TD ><A HREF = "pair_resquared.html">resquared</A></TD></TR>
<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</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_airebo.html">airebo</A></TD><TD ><A HREF = "pair_born.html">born</A></TD><TD ><A HREF = "pair_born.html">born/coul/long</A></TD><TD ><A HREF = "pair_brownian.html">brownian</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_brownian.html">brownian/poly</A></TD><TD ><A HREF = "pair_buck.html">buck</A></TD><TD ><A HREF = "pair_buck.html">buck/coul/cut</A></TD><TD ><A HREF = "pair_buck.html">buck/coul/long</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_colloid.html">colloid</A></TD><TD ><A HREF = "pair_comb.html">comb</A></TD><TD ><A HREF = "pair_coul.html">coul/cut</A></TD><TD ><A HREF = "pair_coul.html">coul/debye</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_coul.html">coul/long</A></TD><TD ><A HREF = "pair_dipole.html">dipole/cut</A></TD><TD ><A HREF = "pair_dpd.html">dpd</A></TD><TD ><A HREF = "pair_dpd.html">dpd/tstat</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_dsmc.html">dsmc</A></TD><TD ><A HREF = "pair_eam.html">eam</A></TD><TD ><A HREF = "pair_eam.html">eam/alloy</A></TD><TD ><A HREF = "pair_eam.html">eam/fs</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_eim.html">eim</A></TD><TD ><A HREF = "pair_gauss.html">gauss</A></TD><TD ><A HREF = "pair_gayberne.html">gayberne</A></TD><TD ><A HREF = "pair_gran.html">gran/hertz/history</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_gran.html">gran/hooke</A></TD><TD ><A HREF = "pair_gran.html">gran/hooke/history</A></TD><TD ><A HREF = "pair_hbond_dreiding.html">hbond/dreiding/lj</A></TD><TD ><A HREF = "pair_hbond_dreiding.html">hbond/dreiding/morse</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_line_lj.html">line/lj</A></TD><TD ><A HREF = "pair_charmm.html">lj/charmm/coul/charmm</A></TD><TD ><A HREF = "pair_charmm.html">lj/charmm/coul/charmm/implicit</A></TD><TD ><A HREF = "pair_charmm.html">lj/charmm/coul/long</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_class2.html">lj/class2</A></TD><TD ><A HREF = "pair_class2.html">lj/class2/coul/cut</A></TD><TD ><A HREF = "pair_class2.html">lj/class2/coul/long</A></TD><TD ><A HREF = "pair_lj.html">lj/cut</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_lj.html">lj/cut/coul/cut</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/coul/debye</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/coul/long</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/coul/long/tip4p</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_lj_expand.html">lj/expand</A></TD><TD ><A HREF = "pair_gromacs.html">lj/gromacs</A></TD><TD ><A HREF = "pair_gromacs.html">lj/gromacs/coul/gromacs</A></TD><TD ><A HREF = "pair_lj_smooth.html">lj/smooth</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_lj96.html">lj96/cut</A></TD><TD ><A HREF = "pair_lubricate.html">lubricate</A></TD><TD ><A HREF = "pair_lubricate.html">lubricate/poly</A></TD><TD ><A HREF = "pair_lubricateU.html">lubricateU</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_lubricateU.html">lubricateU/poly</A></TD><TD ><A HREF = "pair_meam.html">meam</A></TD><TD ><A HREF = "pair_morse.html">morse</A></TD><TD ><A HREF = "pair_peri.html">peri/lps</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_peri.html">peri/pmb</A></TD><TD ><A HREF = "pair_reax.html">reax</A></TD><TD ><A HREF = "pair_airebo.html">rebo</A></TD><TD ><A HREF = "pair_resquared.html">resquared</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_soft.html">soft</A></TD><TD ><A HREF = "pair_sw.html">sw</A></TD><TD ><A HREF = "pair_table.html">table</A></TD><TD ><A HREF = "pair_tersoff.html">tersoff</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_tersoff_zbl.html">tersoff/zbl</A></TD><TD ><A HREF = "pair_yukawa.html">yukawa</A></TD><TD ><A HREF = "pair_yukawa_colloid.html">yukawa/colloid</A>
<TR ALIGN="center"><TD ><A HREF = "pair_tersoff_zbl.html">tersoff/zbl</A></TD><TD ><A HREF = "pair_tri_lj.html">tri/lj</A></TD><TD ><A HREF = "pair_yukawa.html">yukawa</A></TD><TD ><A HREF = "pair_yukawa_colloid.html">yukawa/colloid</A>
</TD></TR></TABLE></DIV>
<P>These are pair styles contributed by users, which can be used if
<A HREF = "Section_start.html#2_3">LAMMPS is built with the appropriate package</A>.
<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_buck_coul.html">buck/coul</A></TD><TD ><A HREF = "pair_cmm.html">cg/cmm</A></TD><TD ><A HREF = "pair_cmm.html">cg/cmm/gpu</A></TD><TD ><A HREF = "pair_cmm.html">cg/cmm/coul/cut</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_cmm.html">cg/cmm/coul/long</A></TD><TD ><A HREF = "pair_coul_diel.html">coul/diel</A></TD><TD ><A HREF = "pair_cmm.html">cg/cmm/coul/long/gpu</A></TD><TD ><A HREF = "pair_eam.html">eam/cd</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_eff.html">eff/cut</A></TD><TD ><A HREF = "pair_gauss.html">gauss/cut</A></TD><TD ><A HREF = "pair_lj_coul.html">lj/coul</A></TD><TD ><A HREF = "pair_reax_c.html">reax/c</A>
<TR ALIGN="center"><TD ><A HREF = "pair_awpmd.html">awpmd/cut</A></TD><TD ><A HREF = "pair_buck_coul.html">buck/coul</A></TD><TD ><A HREF = "pair_coul_diel.html">coul/diel</A></TD><TD ><A HREF = "pair_sdk.html">lj/sdk</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_sdk.html">lj/sdk/coul/long</A></TD><TD ><A HREF = "pair_dipole.html">dipole/sf</A></TD><TD ><A HREF = "pair_eam.html">eam/cd</A></TD><TD ><A HREF = "pair_edip.html">edip</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_eff.html">eff/cut</A></TD><TD ><A HREF = "pair_gauss.html">gauss/cut</A></TD><TD ><A HREF = "pair_lj_coul.html">lj/coul</A></TD><TD ><A HREF = "pair_lj_sf.html">lj/sf</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_reax_c.html">reax/c</A></TD><TD ><A HREF = "pair_heatconduction.html">sph/heatconduction</A></TD><TD ><A HREF = "pair_idealgas.html">sph/idealgas</A></TD><TD ><A HREF = "pair_lj.html">sph/lj</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_rhosum.html">sph/rhosum</A></TD><TD ><A HREF = "pair_taitwater.html">sph/taitwater</A></TD><TD ><A HREF = "pair_taitwater_morris.html">sph/taitwater/morris</A></TD><TD ><A HREF = "pair_tersoff.html">tersoff/table</A>
</TD></TR></TABLE></DIV>
<P>These are accelerated pair styles, which can be used if LAMMPS is
built with the <A HREF = "Section_accelerate.html">appropriate accelerated
package</A>.
</P>
<DIV ALIGN=center><TABLE BORDER=1 >
<TR ALIGN="center"><TD ><A HREF = "pair_adp.html">adp/omp</A></TD><TD ><A HREF = "pair_airebo.html">airebo/omp</A></TD><TD ><A HREF = "pair_born.html">born/coul/long/cuda</A></TD><TD ><A HREF = "pair_born.html">born/coul/long/omp</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_born.html">born/omp</A></TD><TD ><A HREF = "pair_buck.html">buck/coul/cut/cuda</A></TD><TD ><A HREF = "pair_buck.html">buck/coul/cut/omp</A></TD><TD ><A HREF = "pair_buck.html">buck/coul/long/cuda</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_buck.html">buck/coul/long/omp</A></TD><TD ><A HREF = "pair_buck_coul.html">buck/coul/omp</A></TD><TD ><A HREF = "pair_buck.html">buck/cuda</A></TD><TD ><A HREF = "pair_buck.html">buck/omp</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_sdk.html">lj/sdk/gpu</A></TD><TD ><A HREF = "pair_sdk.html">lj/sdk/omp</A></TD><TD ><A HREF = "pair_sdk.html">lj/sdk/coul/long/gpu</A></TD><TD ><A HREF = "pair_sdk.html">lj/sdk/coul/long/omp</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_colloid.html">colloid/omp</A></TD><TD ><A HREF = "pair_comb.html">comb/omp</A></TD><TD ><A HREF = "pair_coul.html">coul/cut/omp</A></TD><TD ><A HREF = "pair_coul.html">coul/debye/omp</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_coul.html">coul/long/gpu</A></TD><TD ><A HREF = "pair_coul.html">coul/long/omp</A></TD><TD ><A HREF = "pair_dipole.html">dipole/cut/omp</A></TD><TD ><A HREF = "pair_dipole.html">dipole/sf/omp</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_dpd.html">dpd/omp</A></TD><TD ><A HREF = "pair_dpd.html">dpd/tstat/omp</A></TD><TD ><A HREF = "pair_eam.html">eam/alloy/cuda</A></TD><TD ><A HREF = "pair_eam.html">eam/alloy/omp</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_eam.html">eam/alloy/opt</A></TD><TD ><A HREF = "pair_eam.html">eam/cd/omp</A></TD><TD ><A HREF = "pair_eam.html">eam/cuda</A></TD><TD ><A HREF = "pair_eam.html">eam/fs/cuda</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_eam.html">eam/fs/omp</A></TD><TD ><A HREF = "pair_eam.html">eam/fs/opt</A></TD><TD ><A HREF = "pair_eam.html">eam/omp</A></TD><TD ><A HREF = "pair_eam.html">eam/opt</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_edip.html">edip/omp</A></TD><TD ><A HREF = "pair_eim.html">eim/omp</A></TD><TD ><A HREF = "pair_gauss.html">gauss/omp</A></TD><TD ><A HREF = "pair_gayberne.html">gayberne/gpu</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_gayberne.html">gayberne/omp</A></TD><TD ><A HREF = "pair_gran.html">gran/hertz/history/omp</A></TD><TD ><A HREF = "pair_gran.html">gran/hooke/cuda</A></TD><TD ><A HREF = "pair_gran.html">gran/hooke/history/omp</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_gran.html">gran/hooke/omp</A></TD><TD ><A HREF = "pair_hbond_dreiding.html">hbond/dreiding/lj/omp</A></TD><TD ><A HREF = "pair_hbond_dreiding.html">hbond/dreiding/morse/omp</A></TD><TD ><A HREF = "pair_line_lj.html">line/lj/omp</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_charmm.html">lj/charmm/coul/charmm/cuda</A></TD><TD ><A HREF = "pair_charmm.html">lj/charmm/coul/charmm/omp</A></TD><TD ><A HREF = "pair_charmm.html">lj/charmm/coul/charmm/implicit/cuda</A></TD><TD ><A HREF = "pair_charmm.html">lj/charmm/coul/charmm/implicit/omp</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_charmm.html">lj/charmm/coul/long/cuda</A></TD><TD ><A HREF = "pair_charmm.html">lj/charmm/coul/long/gpu</A></TD><TD ><A HREF = "pair_charmm.html">lj/charmm/coul/long/omp</A></TD><TD ><A HREF = "pair_charmm.html">lj/charmm/coul/long/opt</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_charmm.html">lj/charmm/coul/pppm/omp</A></TD><TD ><A HREF = "pair_class2.html">lj/class2/coul/cut/cuda</A></TD><TD ><A HREF = "pair_class2.html">lj/class2/coul/cut/omp</A></TD><TD ><A HREF = "pair_class2.html">lj/class2/coul/long/cuda</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_class2.html">lj/class2/coul/long/gpu</A></TD><TD ><A HREF = "pair_class2.html">lj/class2/coul/long/omp</A></TD><TD ><A HREF = "pair_class2.html">lj/class2/cuda</A></TD><TD ><A HREF = "pair_class2.html">lj/class2/gpu</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_class2.html">lj/class2/omp</A></TD><TD ><A HREF = "pair_lj_coul.html">lj/coul/omp</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/coul/cut/cuda</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/coul/cut/gpu</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_lj.html">lj/cut/coul/cut/omp</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/coul/debye/cuda</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/coul/debye/omp</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/coul/long/cuda</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_lj.html">lj/cut/coul/long/gpu</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/coul/long/omp</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/coul/long/opt</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/coul/long/tip4p/omp</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_lj.html">lj/cut/coul/long/tip4p/opt</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/coul/pppm/omp</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/coul/pppm/tip4p/omp</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/cuda</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_lj.html">lj/cut/experimental/cuda</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/gpu</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/omp</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/opt</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_lj_expand.html">lj/expand/cuda</A></TD><TD ><A HREF = "pair_lj_expand.html">lj/expand/gpu</A></TD><TD ><A HREF = "pair_lj_expand.html">lj/expand/omp</A></TD><TD ><A HREF = "pair_gromacs.html">lj/gromacs/coul/gromacs/cuda</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_gromacs.html">lj/gromacs/coul/gromacs/omp</A></TD><TD ><A HREF = "pair_gromacs.html">lj/gromacs/cuda</A></TD><TD ><A HREF = "pair_gromacs.html">lj/gromacs/omp</A></TD><TD ><A HREF = "pair_lj_sf.html">lj/sf/omp</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_lj_smooth.html">lj/smooth/cuda</A></TD><TD ><A HREF = "pair_lj_smooth.html">lj/smooth/omp</A></TD><TD ><A HREF = "pair_lj96.html">lj96/cut/cuda</A></TD><TD ><A HREF = "pair_lj96.html">lj96/cut/gpu</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_lj96.html">lj96/cut/omp</A></TD><TD ><A HREF = "pair_morse.html">morse/cuda</A></TD><TD ><A HREF = "pair_morse.html">morse/gpu</A></TD><TD ><A HREF = "pair_morse.html">morse/omp</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_morse.html">morse/opt</A></TD><TD ><A HREF = "pair_peri.html">peri/lps/omp</A></TD><TD ><A HREF = "pair_peri.html">peri/pmb/omp</A></TD><TD ><A HREF = "pair_airebo.html">rebo/omp</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_resquared.html">resquared/gpu</A></TD><TD ><A HREF = "pair_resquared.html">resquared/omp</A></TD><TD ><A HREF = "pair_soft.html">soft/omp</A></TD><TD ><A HREF = "pair_sw.html">sw/cuda</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_sw.html">sw/omp</A></TD><TD ><A HREF = "pair_table.html">table/omp</A></TD><TD ><A HREF = "pair_tersoff.html">tersoff/cuda</A></TD><TD ><A HREF = "pair_tersoff.html">tersoff/omp</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_tersoff.html">tersoff/table/omp</A></TD><TD ><A HREF = "pair_tersoff_zbl.html">tersoff/zbl/omp</A></TD><TD ><A HREF = "pair_tri_lj.html">tri/lj/omp</A></TD><TD ><A HREF = "pair_yukawa.html">yukawa/omp</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_yukawa_colloid.html">yukawa/colloid/omp</A>
</TD></TR></TABLE></DIV>
<HR>
@ -434,6 +498,24 @@ potentials. Click on the style itself for a full description:
<TR ALIGN="center"><TD WIDTH="100"><A HREF = "bond_quartic.html">quartic</A></TD><TD WIDTH="100"><A HREF = "bond_table.html">table</A>
</TD></TR></TABLE></DIV>
<P>These are bond styles contributed by users, 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</A></TD><TD ><A HREF = "bond_harmonic_shift_cut.html">harmonic/shift/cut</A>
</TD></TR></TABLE></DIV>
<P>These are accelerated bond styles, which can be used if LAMMPS is
built with the <A HREF = "Section_accelerate.html">appropriate accelerated
package</A>.
</P>
<DIV ALIGN=center><TABLE BORDER=1 >
<TR ALIGN="center"><TD WIDTH="100"><A HREF = "bond_class2.html">class2/omp</A></TD><TD WIDTH="100"><A HREF = "bond_fene.html">fene/omp</A></TD><TD WIDTH="100"><A HREF = "bond_fene_expand.html">fene/expand/omp</A></TD><TD WIDTH="100"><A HREF = "bond_harmonic.html">harmonic/omp</A></TD></TR>
<TR ALIGN="center"><TD WIDTH="100"><A HREF = "bond_harmonic_shift.html">harmonic/shift/omp</A></TD><TD WIDTH="100"><A HREF = "bond_harmonic_shift_cut.html">harmonic/shift/cut/omp</A></TD><TD WIDTH="100"><A HREF = "bond_morse.html">morse/omp</A></TD><TD WIDTH="100"><A HREF = "bond_nonlinear.html">nonlinear/omp</A></TD></TR>
<TR ALIGN="center"><TD WIDTH="100"><A HREF = "bond_quartic.html">quartic/omp</A></TD><TD WIDTH="100"><A HREF = "bond_table.html">table/omp</A>
</TD></TR></TABLE></DIV>
<HR>
<H4>Angle_style potentials
@ -448,10 +530,21 @@ angle potentials. Click on the style itself for a full description:
</TD></TR></TABLE></DIV>
<P>These are angle styles contributed by users, which can be used if
<A HREF = "Section_start.html#2_3">LAMMPS is built with the appropriate package</A>.
<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_cmm.html">cg/cmm</A>
<TR ALIGN="center"><TD ><A HREF = "angle_sdk.html">sdk</A></TD><TD ><A HREF = "angle_cosine_shift.html">cosine/shift</A></TD><TD ><A HREF = "angle_cosine_shift_exp.html">cosine/shift/exp</A>
</TD></TR></TABLE></DIV>
<P>These are accelerated angle styles, which can be used if LAMMPS is
built with the <A HREF = "Section_accelerate.html">appropriate accelerated
package</A>.
</P>
<DIV ALIGN=center><TABLE BORDER=1 >
<TR ALIGN="center"><TD WIDTH="100"><A HREF = "angle_charmm.html">charmm/omp</A></TD><TD WIDTH="100"><A HREF = "angle_class2.html">class2/omp</A></TD><TD WIDTH="100"><A HREF = "angle_cosine.html">cosine/omp</A></TD><TD WIDTH="100"><A HREF = "angle_cosine_delta.html">cosine/delta/omp</A></TD></TR>
<TR ALIGN="center"><TD WIDTH="100"><A HREF = "angle_cosine_periodic.html">cosine/periodic/omp</A></TD><TD WIDTH="100"><A HREF = "angle_cosine_shift.html">cosine/shift/omp</A></TD><TD WIDTH="100"><A HREF = "angle_cosine_shift_exp.html">cosine/shift/exp/omp</A></TD><TD WIDTH="100"><A HREF = "angle_cosine_squared.html">cosine/squared/omp</A></TD></TR>
<TR ALIGN="center"><TD WIDTH="100"><A HREF = "angle_harmonic.html">harmonic/omp</A></TD><TD WIDTH="100"><A HREF = "angle_table.html">table/omp</A>
</TD></TR></TABLE></DIV>
<HR>
@ -467,6 +560,23 @@ description:
<TR ALIGN="center"><TD WIDTH="100"><A HREF = "dihedral_harmonic.html">harmonic</A></TD><TD WIDTH="100"><A HREF = "dihedral_helix.html">helix</A></TD><TD WIDTH="100"><A HREF = "dihedral_multi_harmonic.html">multi/harmonic</A></TD><TD WIDTH="100"><A HREF = "dihedral_opls.html">opls</A>
</TD></TR></TABLE></DIV>
<P>These are dihedral styles contributed by users, 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</A>
</TD></TR></TABLE></DIV>
<P>These are accelerated dihedral styles, which can be used if LAMMPS is
built with the <A HREF = "Section_accelerate.html">appropriate accelerated
package</A>.
</P>
<DIV ALIGN=center><TABLE BORDER=1 >
<TR ALIGN="center"><TD WIDTH="100"><A HREF = "dihedral_charmm.html">charmm/omp</A></TD><TD WIDTH="100"><A HREF = "dihedral_class2.html">class2/omp</A></TD><TD WIDTH="100"><A HREF = "dihedral_cosine_shift_exp.html">cosine/shift/exp/omp</A></TD><TD WIDTH="100"><A HREF = "dihedral_harmonic.html">harmonic/omp</A></TD></TR>
<TR ALIGN="center"><TD WIDTH="100"><A HREF = "dihedral_helix.html">helix/omp</A></TD><TD WIDTH="100"><A HREF = "dihedral_multi_harmonic.html">multi/harmonic/omp</A></TD><TD WIDTH="100"><A HREF = "dihedral_opls.html">opls/omp</A>
</TD></TR></TABLE></DIV>
<HR>
<H4>Improper_style potentials
@ -480,6 +590,14 @@ description:
<TR ALIGN="center"><TD WIDTH="100"><A HREF = "improper_harmonic.html">harmonic</A></TD><TD WIDTH="100"><A HREF = "improper_umbrella.html">umbrella</A>
</TD></TR></TABLE></DIV>
<P>These are accelerated improper styles, which can be used if LAMMPS is
built with the <A HREF = "Section_accelerate.html">appropriate accelerated
package</A>.
</P>
<DIV ALIGN=center><TABLE BORDER=1 >
<TR ALIGN="center"><TD WIDTH="100"><A HREF = "improper_class2.html">class2/omp</A></TD><TD WIDTH="100"><A HREF = "improper_cvff.html">cvff/omp</A></TD><TD WIDTH="100"><A HREF = "improper_harmonic.html">harmonic/omp</A></TD><TD WIDTH="100"><A HREF = "improper_umbrella.html">umbrella/omp</A>
</TD></TR></TABLE></DIV>
<HR>
<H4>Kspace solvers
@ -488,14 +606,24 @@ description:
Kspace solvers. Click on the style itself for a full description:
</P>
<DIV ALIGN=center><TABLE BORDER=1 >
<TR ALIGN="center"><TD WIDTH="100"><A HREF = "kspace_style.html">ewald</A></TD><TD WIDTH="100"><A HREF = "kspace_style.html">pppm</A></TD><TD WIDTH="100"><A HREF = "kspace_style.html">pppm/tip4p</A>
<TR ALIGN="center"><TD WIDTH="100"><A HREF = "kspace_style.html">ewald</A></TD><TD WIDTH="100"><A HREF = "kspace_style.html">pppm</A></TD><TD WIDTH="100"><A HREF = "kspace_style.html">pppm/cg</A></TD><TD WIDTH="100"><A HREF = "kspace_style.html">pppm/tip4p</A>
</TD></TR></TABLE></DIV>
<P>These are Kspace solvers contributed by users, which can be used if
<A HREF = "Section_start.html#2_3">LAMMPS is built with the appropriate package</A>.
<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 WIDTH="100"><A HREF = "kspace_style.html">ewald/n</A>
</TD></TR></TABLE></DIV>
<P>These are accelerated Kspace solvers, which can be used if LAMMPS is
built with the <A HREF = "Section_accelerate.html">appropriate accelerated
package</A>.
</P>
<DIV ALIGN=center><TABLE BORDER=1 >
<TR ALIGN="center"><TD ><A HREF = "kspace_style.html">ewald/omp</A></TD><TD ><A HREF = "kspace_style.html">pppm/cuda</A></TD><TD ><A HREF = "kspace_style.html">pppm/gpu</A></TD><TD ><A HREF = "kspace_style.html">pppm/omp</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "kspace_style.html">pppm/proxy</A>
</TD></TR></TABLE></DIV>
</HTML>

View File

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

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

View File

@ -9,7 +9,7 @@
<HR>
<H3>5. Example problems
<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

View File

@ -6,7 +6,7 @@
:line
5. Example problems :h3
7. Example problems :h3
The LAMMPS distribution includes an examples sub-directory with
several sample problems. Each problem is in a sub-directory of its

View File

@ -1,5 +1,7 @@
<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><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>
@ -9,69 +11,61 @@
<HR>
<H3>11. Future and history
<H3>13. Future and history
</H3>
<P>This section lists features we are planning to add to LAMMPS, features
of previous versions of LAMMPS, and features of other parallel
molecular dynamics codes I've distributed.
<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>
11.1 <A HREF = "#11_1">Coming attractions</A><BR>
11.2 <A HREF = "#11_2">Past versions</A> <BR>
13.1 <A HREF = "#hist_1">Coming attractions</A><BR>
13.2 <A HREF = "#hist_2">Past versions</A> <BR>
<HR>
<H4><A NAME = "11_1"></A>11.1 Coming attractions
<HR>
<H4><A NAME = "hist_1"></A>13.1 Coming attractions
</H4>
<P>The current version of LAMMPS incorporates nearly all the features
from previous parallel MD codes developed at Sandia. These include
earlier versions of LAMMPS itself, Warp and ParaDyn for metals, and
GranFlow for granular materials.
<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>These are new features we'd like to eventually add to LAMMPS. Some
are being worked on; some haven't been implemented because of lack of
time or interest; others are just a lot of work! See <A HREF = "http://lammps.sandia.gov/future.html">this
page</A> on the LAMMPS WWW site for more details.
<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>
<UL><LI>Coupling to finite elements for streess-strain
<LI>New ReaxFF implementation
<LI>Nudged elastic band
<LI>Temperature accelerated dynamics
<LI>Triangulated particles
<LI>Stochastic rotation dynamics
<LI>Stokesian dynamics via fast lubrication dynamics
<LI>Long-range point-dipole solver
<LI>Per-atom energy and stress for long-range Coulombics
<LI>Long-range Coulombics via Ewald and PPPM for triclinic boxes
<LI>Metadynamics
<LI>Direct Simulation Monte Carlo - DSMC
</UL>
<HR>
<H4><A NAME = "11_2"></A>11.2 Past versions
<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). Soon after
the CRADA ended, a final F77 version of the code, LAMMPS 99, was
released. As development of LAMMPS continued at Sandia, the memory
management in the code was converted to F90; a final F90 version was
released as LAMMPS 2001.
and 3 companies (Cray, Bristol Myers Squibb, and Dupont). The goal was
to develop a large-scale parallel classical MD code; the coding effort
was led by Steve Plimpton at Sandia.
</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
in 2004. It includes many new features, including features from other
parallel molecular dynamics codes written at Sandia, namely ParaDyn,
Warp, and GranFlow. ParaDyn is a parallel implementation of the
popular serial DYNAMO code developed by Stephen Foiles and Murray Daw
for their embedded atom method (EAM) metal potentials. ParaDyn uses
atom- and force-decomposition algorithms to run in parallel. Warp is
also a parallel implementation of the EAM potentials designed for
large problems, with boundary conditions specific to shearing solids
in varying geometries. GranFlow is a granular materials code with
potentials and boundary conditions peculiar to granular systems. All
of these codes (except ParaDyn) use spatial-decomposition techniques
for their parallelism.
as an open source code in 2004. It includes many new features beyond
those in LAMMPS 99 or 2001. It also includes features from older
parallel MD codes written at Sandia, namely ParaDyn, Warp, and
GranFlow (see below).
</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

View File

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

View File

@ -1,5 +1,5 @@
<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_example.html">Next Section</A>
<CENTER><A HREF = "Section_accelerate.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_example.html">Next Section</A>
</CENTER>
@ -9,32 +9,31 @@
<HR>
<H3>4. How-to discussions
<H3>6. How-to discussions
</H3>
<P>The following sections describe how to use various options within
LAMMPS.
<P>This section describes how to perform common tasks using LAMMPS.
</P>
4.1 <A HREF = "#4_1">Restarting a simulation</A><BR>
4.2 <A HREF = "#4_2">2d simulations</A><BR>
4.3 <A HREF = "#4_3">CHARMM, AMBER, and DREIDING force fields</A><BR>
4.4 <A HREF = "#4_4">Running multiple simulations from one input script</A><BR>
4.5 <A HREF = "#4_5">Multi-replica simulations</A><BR>
4.6 <A HREF = "#4_6">Granular models</A><BR>
4.7 <A HREF = "#4_7">TIP3P water model</A><BR>
4.8 <A HREF = "#4_8">TIP4P water model</A><BR>
4.9 <A HREF = "#4_9">SPC water model</A><BR>
4.10 <A HREF = "#4_10">Coupling LAMMPS to other codes</A><BR>
4.11 <A HREF = "#4_11">Visualizing LAMMPS snapshots</A><BR>
4.12 <A HREF = "#4_12">Triclinic (non-orthogonal) simulation boxes</A><BR>
4.13 <A HREF = "#4_13">NEMD simulations</A><BR>
4.14 <A HREF = "#4_14">Extended spherical and aspherical particles</A><BR>
4.15 <A HREF = "#4_15">Output from LAMMPS (thermo, dumps, computes, fixes, variables)</A><BR>
4.16 <A HREF = "#4_16">Thermostatting, barostatting and computing temperature</A><BR>
4.17 <A HREF = "#4_17">Walls</A><BR>
4.18 <A HREF = "#4_18">Elastic constants</A><BR>
4.19 <A HREF = "#4_19">Library interface to LAMMPS</A><BR>
4.20 <A HREF = "#4_20">Calculating thermal conductivity</A><BR>
4.21 <A HREF = "#4_21">Calculating viscosity</A> <BR>
6.1 <A HREF = "#howto_1">Restarting a simulation</A><BR>
6.2 <A HREF = "#howto_2">2d simulations</A><BR>
6.3 <A HREF = "#howto_3">CHARMM, AMBER, and DREIDING force fields</A><BR>
6.4 <A HREF = "#howto_4">Running multiple simulations from one input script</A><BR>
6.5 <A HREF = "#howto_5">Multi-replica simulations</A><BR>
6.6 <A HREF = "#howto_6">Granular models</A><BR>
6.7 <A HREF = "#howto_7">TIP3P water model</A><BR>
6.8 <A HREF = "#howto_8">TIP4P water model</A><BR>
6.9 <A HREF = "#howto_9">SPC water model</A><BR>
6.10 <A HREF = "#howto_10">Coupling LAMMPS to other codes</A><BR>
6.11 <A HREF = "#howto_11">Visualizing LAMMPS snapshots</A><BR>
6.12 <A HREF = "#howto_12">Triclinic (non-orthogonal) simulation boxes</A><BR>
6.13 <A HREF = "#howto_13">NEMD simulations</A><BR>
6.14 <A HREF = "#howto_14">Extended spherical and aspherical particles</A><BR>
6.15 <A HREF = "#howto_15">Output from LAMMPS (thermo, dumps, computes, fixes, variables)</A><BR>
6.16 <A HREF = "#howto_16">Thermostatting, barostatting and computing temperature</A><BR>
6.17 <A HREF = "#howto_17">Walls</A><BR>
6.18 <A HREF = "#howto_18">Elastic constants</A><BR>
6.19 <A HREF = "#howto_19">Library interface to LAMMPS</A><BR>
6.20 <A HREF = "#howto_20">Calculating thermal conductivity</A><BR>
6.21 <A HREF = "#howto_21">Calculating viscosity</A> <BR>
<P>The example input scripts included in the LAMMPS distribution and
highlighted in <A HREF = "Section_example.html">this section</A> also show how to
@ -42,7 +41,9 @@ setup and run various kinds of simulations.
</P>
<HR>
<A NAME = "4_1"></A><H4>4.1 Restarting a simulation
<HR>
<A NAME = "howto_1"></A><H4>6.1 Restarting a simulation
</H4>
<P>There are 3 ways to continue a long LAMMPS simulation. Multiple
<A HREF = "run.html">run</A> commands can be used in the same input script. Each
@ -134,7 +135,7 @@ but not in data files.
</P>
<HR>
<A NAME = "4_2"></A><H4>4.2 2d simulations
<A NAME = "howto_2"></A><H4>6.2 2d simulations
</H4>
<P>Use the <A HREF = "dimension.html">dimension</A> command to specify a 2d simulation.
</P>
@ -169,7 +170,7 @@ the same as in 3d.
</P>
<HR>
<A NAME = "4_3"></A><H4>4.3 CHARMM, AMBER, and DREIDING force fields
<A NAME = "howto_3"></A><H4>6.3 CHARMM, AMBER, and DREIDING force fields
</H4>
<P>A force field has 2 parts: the formulas that define it and the
coefficients used for a particular system. Here we only discuss
@ -246,7 +247,7 @@ documentation for the formula it computes.
</UL>
<HR>
<A NAME = "4_4"></A><H4>4.4 Running multiple simulations from one input script
<A NAME = "howto_4"></A><H4>6.4 Running multiple simulations from one input script
</H4>
<P>This can be done in several ways. See the documentation for
individual commands for more details on how these examples work.
@ -318,7 +319,7 @@ jump in.polymer
<P>All of the above examples work whether you are running on 1 or
multiple processors, but assumed you are running LAMMPS on a single
partition of processors. LAMMPS can be run on multiple partitions via
the "-partition" command-line switch as described in <A HREF = "Section_start.html#2_6">this
the "-partition" command-line switch as described in <A HREF = "Section_start.html#start_6">this
section</A> of the manual.
</P>
<P>In the last 2 examples, if LAMMPS were run on 3 partitions, the same
@ -334,7 +335,7 @@ the 4th simulation, and so forth, until all 8 were completed.
</P>
<HR>
<A NAME = "4_5"></A><H4>4.5 Multi-replica simulations
<A NAME = "howto_5"></A><H4>6.5 Multi-replica simulations
</H4>
<P>Several commands in LAMMPS run mutli-replica simulations, meaning
that multiple instances (replicas) of your simulation are run
@ -355,12 +356,12 @@ runs different replicas at a series of temperature to facilitate
rare-event sampling.
</P>
<P>These command can only be used if LAMMPS was built with the "replica"
package. See the <A HREF = "Section_start.html#2_3">Making LAMMPS</A> section for
more info on packages.
package. See the <A HREF = "Section_start.html#start_3">Making LAMMPS</A> section
for more info on packages.
</P>
<P>In all these cases, you must run with one or more processors per
replica. The processors assigned to each replica are determined at
run-time by using the <A HREF = "Section_start.html#2_6">-partition command-line
run-time by using the <A HREF = "Section_start.html#start_6">-partition command-line
switch</A> to launch LAMMPS on multiple
partitions, which in this context are the same as replicas. E.g.
these commands:
@ -369,8 +370,8 @@ these commands:
mpirun -np 8 lmp_linux -partition 8x1 -in in.neb
</PRE>
<P>would each run 8 replicas, on either 16 or 8 processors. Note the use
of the <A HREF = "Section_start.html#2_6">-in command-line switch</A> to specify the
input script which is required when running in multi-replica mode.
of the <A HREF = "Section_start.html#start_6">-in command-line switch</A> to specify
the input script which is required when running in multi-replica mode.
</P>
<P>Also note that with MPI installed on a machine (e.g. your desktop),
you can run on more (virtual) processors than you have physical
@ -381,7 +382,7 @@ physical processors.
</P>
<HR>
<A NAME = "4_6"></A><H4>4.6 Granular models
<A NAME = "howto_6"></A><H4>6.6 Granular models
</H4>
<P>Granular system are composed of spherical particles with a diameter,
as opposed to point particles. This means they have an angular
@ -390,7 +391,7 @@ velocity and torque can be imparted to them to cause them to rotate.
<P>To run a simulation of a granular model, you will want to use
the following commands:
</P>
<UL><LI><A HREF = "atom_style.html">atom_style</A> granular
<UL><LI><A HREF = "atom_style.html">atom_style sphere</A>
<LI><A HREF = "fix_nve_sphere.html">fix nve/sphere</A>
<LI><A HREF = "fix_gravity.html">fix gravity</A>
</UL>
@ -398,7 +399,7 @@ the following commands:
</P>
<UL><LI><A HREF = "compute_erotate_sphere.html">compute erotate/sphere</A>
</UL>
<P>calculates rotational kinetic energy which can be <A HREF = "Section_howto.html#4_15">output with
<P>calculates rotational kinetic energy which can be <A HREF = "Section_howto.html#howto_15">output with
thermodynamic info</A>.
</P>
<P>Use one of these 3 pair potentials, which compute forces and torques
@ -426,7 +427,7 @@ computations between frozen atoms by using this command:
</UL>
<HR>
<A NAME = "4_7"></A><H4>4.7 TIP3P water model
<A NAME = "howto_7"></A><H4>6.7 TIP3P water model
</H4>
<P>The TIP3P water model as implemented in CHARMM
<A HREF = "#MacKerell">(MacKerell)</A> specifies a 3-site rigid water molecule with
@ -486,7 +487,7 @@ models</A>.
</P>
<HR>
<A NAME = "4_8"></A><H4>4.8 TIP4P water model
<A NAME = "howto_8"></A><H4>6.8 TIP4P water model
</H4>
<P>The four-point TIP4P rigid water model extends the traditional
three-point TIP3P model by adding an additional site, usually
@ -545,7 +546,7 @@ models</A>.
</P>
<HR>
<A NAME = "4_9"></A><H4>4.9 SPC water model
<A NAME = "howto_9"></A><H4>6.9 SPC water model
</H4>
<P>The SPC water model specifies a 3-site rigid water molecule with
charges and Lennard-Jones parameters assigned to each of the 3 atoms.
@ -590,7 +591,7 @@ models</A>.
</P>
<HR>
<A NAME = "4_10"></A><H4>4.10 Coupling LAMMPS to other codes
<A NAME = "howto_10"></A><H4>6.10 Coupling LAMMPS to other codes
</H4>
<P>LAMMPS is designed to allow it to be coupled to other codes. For
example, a quantum mechanics code might compute forces on a subset of
@ -660,10 +661,10 @@ strain induced across grain boundaries
<P><A HREF = "Section_start.html#2_4">This section</A> of the documentation describes
how to build LAMMPS as a library. Once this is done, you can
interface with LAMMPS either via C++, C, Fortran, or Python (or any
other language that supports a vanilla C-like interface). For
<P><A HREF = "Section_start.html#start_4">This section</A> of the documentation
describes how to build LAMMPS as a library. Once this is done, you
can interface with LAMMPS either via C++, C, Fortran, or Python (or
any other language that supports a vanilla C-like interface). For
example, from C++ you could create one (or more) "instances" of
LAMMPS, pass it an input script to process, or execute individual
commands, all by invoking the correct class methods in LAMMPS. From C
@ -673,7 +674,7 @@ the Python wrapper provided with LAMMPS that operates through the
LAMMPS library interface.
</P>
<P>The files src/library.cpp and library.h contain the C-style interface
to LAMMPS. See <A HREF = "Section_howto.html#4_19">this section</A> of the manual
to LAMMPS. See <A HREF = "Section_howto.html#howto_19">this section</A> of the manual
for a description of the interface and how to extend it for your
needs.
</P>
@ -690,7 +691,7 @@ instances of LAMMPS to perform different calculations.
</P>
<HR>
<A NAME = "4_11"></A><H4>4.11 Visualizing LAMMPS snapshots
<A NAME = "howto_11"></A><H4>6.11 Visualizing LAMMPS snapshots
</H4>
<P>LAMMPS itself does not do visualization, but snapshots from LAMMPS
simulations can be visualized (and analyzed) in a variety of ways.
@ -749,14 +750,14 @@ See the <A HREF = "dump.html">dump</A> command for more information on XTC files
<HR>
<A NAME = "4_12"></A><H4>4.12 Triclinic (non-orthogonal) simulation boxes
<A NAME = "howto_12"></A><H4>6.12 Triclinic (non-orthogonal) simulation boxes
</H4>
<P>By default, LAMMPS uses an orthogonal simulation box to encompass the
particles. The <A HREF = "boundary.html">boundary</A> command sets the boundary
conditions of the box (periodic, non-periodic, etc). The orthogonal
box has its "origin" at (xlo,ylo,zlo) and is defined by 3 edge vectors
starting from the origin given by A = (xhi-xlo,0,0); B =
(0,yhi-ylo,0); C = (0,0,zhi-zlo). The 6 parameters
starting from the origin given by <B>a</B> = (xhi-xlo,0,0); <B>b</B> =
(0,yhi-ylo,0); <B>c</B> = (0,0,zhi-zlo). The 6 parameters
(xlo,xhi,ylo,yhi,zlo,zhi) are defined at the time the simluation box
is created, e.g. by the <A HREF = "create_box.html">create_box</A> or
<A HREF = "read_data.html">read_data</A> or <A HREF = "read_restart.html">read_restart</A>
@ -768,14 +769,14 @@ custom</A> command.
<P>LAMMPS also allows simulations to be perfored in non-orthogonal
simulation boxes shaped as a parallelepiped with triclinic symmetry.
The parallelepiped has its "origin" at (xlo,ylo,zlo) and is defined by
3 edge vectors starting from the origin given by A = (xhi-xlo,0,0); B
= (xy,yhi-ylo,0); C = (xz,yz,zhi-zlo). <I>Xy,xz,yz</I> can be 0.0 or
3 edge vectors starting from the origin given by <B>a</B> = (xhi-xlo,0,0); <B>b</B>
= (xy,yhi-ylo,0); <B>c</B> = (xz,yz,zhi-zlo). <I>Xy,xz,yz</I> can be 0.0 or
positive or negative values and are called "tilt factors" because they
are the amount of displacement applied to faces of an originally
orthogonal box to transform it into the parallelepiped. Note that in
LAMMPS the triclinic simulation box edge vectors A,B,C cannot be
arbitrary vectors. As indicated, A must be aligned with the x axis, B
must be in the xy plane, and C is arbitrary. However, this is not a
LAMMPS the triclinic simulation box edge vectors <B>a</B>, <B>b</B>, and <B>c</B> cannot be
arbitrary vectors. As indicated, <B>a</B> must be aligned with the x axis, <B>b</B>
must be in the xy plane, and <B>c</B> is arbitrary. However, this is not a
restriction since it is possible to rotate any set of 3 crystal basis
vectors so that they meet this restriction.
</P>
@ -817,14 +818,25 @@ equivalent.
</P>
<P>Triclinic crystal structures are often defined using three lattice
constants <I>a</I>, <I>b</I>, and <I>c</I>, and three angles <I>alpha</I>, <I>beta</I> and
<I>gamma</I>. Note that in this nomenclature, the a,b,c lattice constants
are the scalar lengths of the 3 A,B,C edge vectors defined above. The
<I>gamma</I>. Note that in this nomenclature, the a, b, and c lattice constants
are the scalar lengths of the edge vectors <B>a</B>, <B>b</B>, and <B>c</B> defined
above. The
relationship between these 6 quantities (a,b,c,alpha,beta,gamma) and
the LAMMPS box sizes (lx,ly,lz) = (xhi-xlo,yhi-ylo,zhi-zlo) and tilt
factors (xy,xz,yz) is as follows:
</P>
<CENTER><IMG SRC = "Eqs/box.jpg">
</CENTER>
<P>The inverse relationship can be written as follows:
</P>
<CENTER><IMG SRC = "Eqs/box_inverse.jpg">
</CENTER>
<P>The values of <I>a</I>, <I>b</I>, <I>c</I> , <I>alpha</I>, <I>beta</I> , and <I>gamma</I> can be printed
out or accessed by computes using the
<A HREF = "thermo_style.html">thermo_style custom</A> keywords
<I>cella</I>, <I>cellb</I>, <I>cellc</I>, <I>cellalpha</I>, <I>cellbeta</I>, <I>cellgamma</I>,
respectively.
</P>
<P>As discussed on the <A HREF = "dump.html">dump</A> command doc page, when the BOX
BOUNDS for a snapshot is written to a dump file for a triclinic box,
an orthogonal bounding box which encloses the triclinic simulation box
@ -871,7 +883,7 @@ on non-equilibrium MD (NEMD) simulations.
</P>
<HR>
<A NAME = "4_13"></A><H4>4.13 NEMD simulations
<A NAME = "howto_13"></A><H4>6.13 NEMD simulations
</H4>
<P>Non-equilibrium molecular dynamics or NEMD simulations are typically
used to measure a fluid's rheological properties such as viscosity.
@ -909,13 +921,13 @@ profile consistent with the applied shear strain rate.
</P>
<HR>
<A NAME = "4_14"></A><H4>4.14 Extended spherical and aspherical particles
<A NAME = "howto_14"></A><H4>6.14 Extended spherical and aspherical particles
</H4>
<P>Typical MD models treat atoms or particles as point masses.
Sometimes, however, it is desirable to have a model with finite-size
particles such as spherioids or aspherical ellipsoids. The difference
is that such particles have a moment of inertia, rotational energy,
and angular momentum. Rotation is induced by torque from interactions
particles such as spheres or aspherical ellipsoids. The difference is
that such particles have a moment of inertia, rotational energy, and
angular momentum. Rotation is induced by torque from interactions
with other particles.
</P>
<P>LAMMPS has several options for running simulations with these kinds of
@ -929,53 +941,61 @@ particles. The following aspects are discussed in turn:
</UL>
<H5>Atom styles
</H5>
<P>There are 3 <A HREF = "atom_style.html">atom styles</A> that allow for definition of
finite-size particles: granular, dipole, ellipsoid.
<P>There are 2 <A HREF = "atom_style.html">atom styles</A> that allow for definition of
finite-size particles: sphere and ellipsoid. The peri atom style also
treats particles as having a volume, but that is internal to the
<A HREF = "pair_peri.html">pair_style peri</A> potentials. The dipole atom style is
most often used in conjunction with finite-size particles.
</P>
<P>Granular particles are spheriods and each particle can have a unique
diameter and mass (or density). These particles store an angular
velocity (omega) and can be acted upon by torque.
<P>The sphere style defines particles that are spheriods and each
particle can have a unique diameter and mass (or density). These
particles store an angular velocity (omega) and can be acted upon by
torque. The "set" command can be used to modify the diameter and mass
of individual particles, after then are created.
</P>
<P>Dipolar particles are typically spheriods with a point dipole and each
particle type has a diamater and mass, set by the <A HREF = "shape.html">shape</A>
and <A HREF = "mass.html">mass</A> commands. These particles store an angular
velocity (omega) and can be acted upon by torque. They also store an
orientation for the point dipole (mu) which has a length set by the
<A HREF = "dipole.html">dipole</A> command. The <A HREF = "set.html">set</A> command can be used
to initialize the orientation of dipole moments.
<P>The ellipsoid style defines particles that are ellipsoids and thus can
be aspherical. Each particle has a shape, specified by 3 diameters,
and mass (or density). These particles store an angular momentum and
their orientation (quaternion), and can be acted upon by torque. They
do not store an angular velocity (omega), which can be in a different
direction than angular momentum, rather they compute it as needed.
The "set" command can be used to modify the diameter, orientation, and
mass of individual particles, after then are created. It also has a
brief explanation of what quaternions are.
</P>
<P>Ellipsoid particles are aspherical. Each particle type has an
ellipsoidal shape and mass, defined by the <A HREF = "shape.html">shape</A> and
<A HREF = "mass.html">mass</A> commands. These particles store an angular momentum
and their orientation (quaternion), and can be acted upon by torque.
They do not store an angular velocity (omega), which can be in a
different direction than angular momentum, rather they compute it as
needed. Ellipsoidal particles can also store a dipole moment if an
<A HREF = "atom_style.html">atom_style hybrid ellipsoid dipole</A> is used. The
<A HREF = "set.html">set</A> command can be used to initialize the orientation of
ellipsoidal particles and has a brief explanation of quaternions.
<P>The dipole style does not define extended particles, but is often
used in conjunction with spherical particles, via a command like
</P>
<PRE>atom_style hybrid sphere dipole
</PRE>
<P>This is because when dipoles interact with each other, they induce
torques, and a particle must be extended (i.e. have a moment of
inertia) in order to respond and rotate. See the <A HREF = "atom_style.html">atom_style
dipole</A> command for details. The "set" command can be
used to modify the orientation and length of the dipole moment of
individual particles, after then are created.
</P>
<P>Note that if one of these atom styles is used (or multiple styles via
the <A HREF = "atom_style.html">atom_style hybrid</A> command), not all particles in
the system are required to be finite-size or aspherical. For example,
if the 3 shape parameters are set to the same value, the particle will
be a spheroid rather than an ellipsoid. If the 3 shape parameters are
be a sphere rather than an ellipsoid. If the 3 shape parameters are
all set to 0.0 or if the diameter is set to 0.0, it will be a point
particle. If the dipole moment is set to zero, the particle will not
have a point dipole associated with it. The pair styles used to
compute pairwise interactions will typically compute the correct
interaction in these simplified (cheaper) cases. <A HREF = "pair_hybrid.html">Pair_style
hybrid</A> can be used to insure the correct
particle. If the length of the dipole moment is set to zero, the
particle will not have a point dipole associated with it. The pair
styles used to compute pairwise interactions will typically compute
the correct interaction in these simplified (cheaper) cases.
<A HREF = "pair_hybrid.html">Pair_style hybrid</A> can be used to insure the correct
interactions are computed for the appropriate style of interactions.
Likewise, using groups to partition particles (ellipsoid versus
spheroid versus point particles) will allow you to use the appropriate
Likewise, using groups to partition particles (ellipsoids versus
spheres versus point particles) will allow you to use the appropriate
time integrators and temperature computations for each class of
particles. See the doc pages for various commands for details.
</P>
<P>Also note that for <A HREF = "dimension.html">2d simulations</A>, finite-size
spheroids and ellipsoids are still treated as 3d particles, rather
than as disks or ellipses. This means they have the same moment of
inertia for a 3d extended object. When their temperature is
spheres and ellipsoids are still treated as 3d particles, rather than
as circular disks or ellipses. This means they have the same moment
of inertia for a 3d extended object. When their temperature is
coomputed, the correct degrees of freedom are used for rotation in a
2d versus 3d system.
</P>
@ -994,15 +1014,14 @@ that generate torque:
<LI><A HREF = "pair_resquared.html">pair_style resquared</A>
<LI><A HREF = "pair_lubricate.html">pair_style lubricate</A>
</UL>
<P>The <A HREF = "pair_gran.html">granular pair styles</A> are used with <A HREF = "atom_style.html">atom_style
granular</A>. The <A HREF = "pair_dipole.html">dipole pair style</A>
is used with <A HREF = "atom_style.html">atom_style dipole</A>. The
<A HREF = "pair_gayberne.html">GayBerne</A> and <A HREF = "pair_resquared.html">REsquared</A>
potentials require particles have a <A HREF = "shape.html">shape</A> and are
designed for <A HREF = "atom_style.html">ellipsoidal particles</A>. The
<A HREF = "pair_lubricate.html">lubrication potential</A> requires that particles
have a <A HREF = "shape.html">shape</A>. It can currently only be used with
extended spherical particles.
<P>The <A HREF = "pair_gran.html">granular pair styles</A> are used with spherical
particles. The <A HREF = "pair_dipole.html">dipole pair style</A> is used with
<A HREF = "atom_style.html">atom_style dipole</A>, which could be applied to
spherical or ellipsoidal particles. The <A HREF = "pair_gayberne.html">GayBerne</A>
and <A HREF = "pair_resquared.html">REsquared</A> potentials require ellipsoidal
particles, though they will also work if the 3 shape parameters are
the same (a sphere). The <A HREF = "pair_lubricate.html">lubrication potential</A>
works with spherical particles.
</P>
<H5>Time integration
</H5>
@ -1014,8 +1033,8 @@ and angular velocity or angular momentum of the particles:
<LI><A HREF = "fix_nvt_sphere.html">fix nvt/sphere</A>
<LI><A HREF = "fix_npt_sphere.html">fix npt/sphere</A>
</UL>
<P>Likewise, there are 3 fixes that perform time integration on extended
aspherical particles:
<P>Likewise, there are 3 fixes that perform time integration on
ellipsoids as extended aspherical particles:
</P>
<UL><LI><A HREF = "fix_nve_asphere.html">fix nve/asphere</A>
<LI><A HREF = "fix_nvt_asphere.html">fix nvt/asphere</A>
@ -1035,7 +1054,7 @@ extended particles.
<H5>Computes, thermodynamics, and dump output
</H5>
<P>There are 4 computes that calculate the temperature or rotational energy
of extended spherical or aspherical particles:
of extended spherical or aspherical particles (ellipsoids):
</P>
<UL><LI><A HREF = "compute_temp_sphere.html">compute temp/sphere</A>
<LI><A HREF = "compute_temp_asphere.html">compute temp/asphere</A>
@ -1063,11 +1082,8 @@ particles as a rigid body, computes its inertia tensor, sums the total
force and torque on the rigid body each timestep due to forces on its
constituent particles, and integrates the motion of the rigid body.
</P>
<P>(NOTE: the feature described in the following paragraph has not yet
been released. It will be soon.)
</P>
<P>If any of the constituent particles of a rigid body are extended
particles (spheroids or ellipsoids), then their contribution to the
particles (spheres or ellipsoids), then their contribution to the
inertia tensor of the body is different than if they were point
particles. This means the rotational dynamics of the rigid body will
be different. Thus a model of a dimer is different if the dimer
@ -1085,7 +1101,7 @@ particles are point masses.
</P>
<HR>
<A NAME = "4_15"></A><H4>4.15 Output from LAMMPS (thermo, dumps, computes, fixes, variables)
<A NAME = "howto_15"></A><H4>6.15 Output from LAMMPS (thermo, dumps, computes, fixes, variables)
</H4>
<P>There are four basic kinds of LAMMPS output:
</P>
@ -1266,6 +1282,11 @@ or local vector quantities as inputs and "reduce" them (sum, min, max,
ave) to scalar quantities. These are produced as output values which
can be used as input to other output commands.
</P>
<P>The <A HREF = "compute_slice.html">compute slice</A> command take one or more global
vector or array quantities as inputs and extracts a subset of their
values to create a new vector or array. These are produced as output
values which can be used as input to other output commands.
</P>
<P>The <A HREF = "compute_property_atom.html">compute property/atom</A> command takes a
list of one or more pre-defined atom attributes (id, x, fx, etc) and
stores the values in a per-atom vector or array. These are produced
@ -1359,6 +1380,7 @@ vector input could be a column of an array.
<TR><TD ><A HREF = "fix.html">fixes</A></TD><TD > N/A</TD><TD > global/per-atom/local scalar/vector/array</TD><TD ></TD></TR>
<TR><TD ><A HREF = "variable.html">variables</A></TD><TD > global scalars, per-atom vectors</TD><TD > global scalar, per-atom vector</TD><TD ></TD></TR>
<TR><TD ><A HREF = "compute_reduce.html">compute reduce</A></TD><TD > per-atom/local vectors</TD><TD > global scalar/vector</TD><TD ></TD></TR>
<TR><TD ><A HREF = "compute_slice.html">compute slice</A></TD><TD > global vectors/arrays</TD><TD > global vector/array</TD><TD ></TD></TR>
<TR><TD ><A HREF = "compute_property_atom.html">compute property/atom</A></TD><TD > per-atom vectors</TD><TD > per-atom vector/array</TD><TD ></TD></TR>
<TR><TD ><A HREF = "compute_property_local.html">compute property/local</A></TD><TD > local vectors</TD><TD > local vector/array</TD><TD ></TD></TR>
<TR><TD ><A HREF = "compute_atom_molecule.html">compute atom/molecule</A></TD><TD > per-atom vectors</TD><TD > global vector/array</TD><TD ></TD></TR>
@ -1373,7 +1395,7 @@ vector input could be a column of an array.
<HR>
<A NAME = "4_16"></A><H4>4.16 Thermostatting, barostatting, and computing temperature
<A NAME = "howto_16"></A><H4>6.16 Thermostatting, barostatting, and computing temperature
</H4>
<P>Thermostatting means controlling the temperature of particles in an MD
simulation. Barostatting means controlling the pressure. Since the
@ -1434,7 +1456,7 @@ thermostatting can be invoked via the <I>dpd/tstat</I> pair style:
<P><A HREF = "fix_nh.html">Fix nvt</A> only thermostats the translational velocity of
particles. <A HREF = "fix_nvt_sllod.html">Fix nvt/sllod</A> also does this, except
that it subtracts out a velocity bias due to a deforming box and
integrates the SLLOD equations of motion. See the <A HREF = "#4_13">NEMD
integrates the SLLOD equations of motion. See the <A HREF = "#howto_13">NEMD
simulations</A> section of this page for further details. <A HREF = "fix_nvt_sphere.html">Fix
nvt/sphere</A> and <A HREF = "fix_nvt_asphere.html">fix
nvt/asphere</A> thermostat not only translation
@ -1524,7 +1546,7 @@ thermodynamic output.
</P>
<HR>
<A NAME = "4_17"></A><H4>4.17 Walls
<A NAME = "howto_17"></A><H4>6.17 Walls
</H4>
<P>Walls in an MD simulation are typically used to bound particle motion,
i.e. to serve as a boundary condition.
@ -1598,7 +1620,7 @@ frictional walls, as well as triangulated surfaces.
</P>
<HR>
<A NAME = "4_18"></A><H4>4.18 Elastic constants
<A NAME = "howto_18"></A><H4>6.18 Elastic constants
</H4>
<P>Elastic constants characterize the stiffness of a material. The formal
definition is provided by the linear relation that holds between the
@ -1634,12 +1656,12 @@ converge and requires careful post-processing <A HREF = "#Shinoda">(Shinoda)</A>
</P>
<HR>
<A NAME = "4_19"></A><H4>4.19 Library interface to LAMMPS
<A NAME = "howto_19"></A><H4>6.19 Library interface to LAMMPS
</H4>
<P>As described in <A HREF = "Section_start.html#2_4">this section</A>, LAMMPS can be
built as a library, so that it can be called by another code, used in
a <A HREF = "Section_howto.html#4_10">coupled manner</A> with other codes, or driven
through a <A HREF = "Section_python.html">Python interface</A>.
<P>As described in <A HREF = "Section_start.html#start_4">this section</A>, LAMMPS can
be built as a library, so that it can be called by another code, used
in a <A HREF = "Section_howto.html#howto_10">coupled manner</A> with other codes, or
driven through a <A HREF = "Section_python.html">Python interface</A>.
</P>
<P>All of these methodologies use a C-style interface to LAMMPS that is
provided in the files src/library.cpp and src/library.h. The
@ -1658,11 +1680,12 @@ void lammps_file(void *, char *);
char *lammps_command(void *, char *);
</PRE>
<P>The lammps_open() function is used to initialize LAMMPS, passing in a
list of strings as if they were <A HREF = "#2_6">command-line arguments</A> when
LAMMPS is run in stand-alone mode from the command line, and a MPI
communicator for LAMMPS to run under. It returns a ptr to the LAMMPS
object that is created, and which is used in subsequent library calls.
The lammps_open() function can be called multiple times, to create
list of strings as if they were <A HREF = "Section_start.html#start_6">command-line
arguments</A> when LAMMPS is run in
stand-alone mode from the command line, and a MPI communicator for
LAMMPS to run under. It returns a ptr to the LAMMPS object that is
created, and which is used in subsequent library calls. The
lammps_open() function can be called multiple times, to create
multiple instances of LAMMPS.
</P>
<P>LAMMPS will run on the set of processors in the communicator. This
@ -1714,10 +1737,10 @@ grab data from LAMMPS, change it, and put it back into LAMMPS.
</P>
<HR>
<A NAME = "4_20"></A><H4>4.20 Calculating thermal conductivity
<A NAME = "howto_20"></A><H4>6.20 Calculating thermal conductivity
</H4>
<P>The thermal conductivity kappa of a material can be measured in at
least 3 ways using various options in LAMMPS. (See <A HREF = "Section_howto.html#4_21">this
least 3 ways using various options in LAMMPS. (See <A HREF = "Section_howto.html#howto_21">this
section</A> of the manual for an analogous
discussion for viscosity). The thermal conducitivity tensor kappa is
a measure of the propensity of a material to transmit heat energy in a
@ -1734,7 +1757,7 @@ scalar.
<P>The first method is to setup two thermostatted regions at opposite
ends of a simulation box, or one in the middle and one at the end of a
periodic box. By holding the two regions at different temperatures
with a <A HREF = "Section_howto.html#4_13">thermostatting fix</A>, the energy added
with a <A HREF = "Section_howto.html#howto_13">thermostatting fix</A>, the energy added
to the hot region should equal the energy subtracted from the cold
region and be proportional to the heat flux moving between the
regions. See the paper by <A HREF = "#Ikeshoji">Ikeshoji and Hafskjold</A> for
@ -1779,10 +1802,10 @@ formalism.
</P>
<HR>
<A NAME = "4_21"></A><H4>4.21 Calculating viscosity
<A NAME = "howto_21"></A><H4>6.21 Calculating viscosity
</H4>
<P>The shear viscosity eta of a fluid can be measured in at least 3 ways
using various options in LAMMPS. (See <A HREF = "Section_howto.html#4_20">this
using various options in LAMMPS. (See <A HREF = "Section_howto.html#howto_20">this
section</A> of the manual for an analogous
discussion for thermal conductivity). Eta is a measure of the
propensity of a fluid to transmit momentum in a direction
@ -1808,7 +1831,7 @@ y-direction of the Vx component of fluid motion or grad(Vstream) =
dVx/dy. In this case, the Pxy off-diagonal component of the pressure
or stress tensor, as calculated by the <A HREF = "compute_pressure.html">compute
pressure</A> command, can also be monitored, which
is the J term in the equation above. See <A HREF = "Section_howto.html#4_13">this
is the J term in the equation above. See <A HREF = "Section_howto.html#howto_13">this
section</A> of the manual for details on NEMD
simulations.
</P>

View File

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

View File

@ -11,20 +11,22 @@
<H3>1. Introduction
</H3>
<P>These sections provide an overview of what LAMMPS can and can't do,
describe what it means for LAMMPS to be an open-source code, and
acknowledge the funding and people who have contributed to LAMMPS over
the years.
<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 = "#1_1">What is LAMMPS</A><BR>
1.2 <A HREF = "#1_2">LAMMPS features</A><BR>
1.3 <A HREF = "#1_3">LAMMPS non-features</A><BR>
1.4 <A HREF = "#1_4">Open source distribution</A><BR>
1.5 <A HREF = "#1_5">Acknowledgments and citations</A> <BR>
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>
<A NAME = "1_1"></A><H4>1.1 What is LAMMPS
<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
@ -49,7 +51,7 @@ 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 = "#1_4">this section</A> for a brief
modify the code however you wish. See <A HREF = "#intro_4">this section</A> for a brief
discussion of the open-source philosophy.
</P>
@ -67,7 +69,7 @@ downloaded from the <A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A>.
<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 = "#1_5">this section</A> for more information on LAMMPS funding and
See <A HREF = "#intro_5">this section</A> for more information on LAMMPS funding and
individuals who have contributed to LAMMPS.
</P>
@ -86,11 +88,11 @@ communicate and store "ghost" atom information for atoms that border
their sub-domain. LAMMPS is most efficient (in a parallel sense) for
systems whose particles fill a 3d rectangular box with roughly uniform
density. Papers with technical details of the algorithms used in
LAMMPS are listed in <A HREF = "#1_5">this section</A>.
LAMMPS are listed in <A HREF = "#intro_5">this section</A>.
</P>
<HR>
<A NAME = "1_2"></A><H4>1.2 LAMMPS features
<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
@ -125,7 +127,8 @@ LAMMPS.
<LI> metals
<LI> granular materials
<LI> coarse-grained mesoscale models
<LI> extended spherical and ellipsoidal particles
<LI> finite-size spherical and ellipsoidal particles
<LI> finite-size line segment (2d) and triangle (3d) particles
<LI> point dipolar particles
<LI> rigid collections of particles
<LI> hybrid combinations of these
@ -139,10 +142,10 @@ 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), Stillinger-Weber, Tersoff, AI-REBO, ReaxFF, COMB
<LI> electron force field (eFF)
<LI> manybody potentials: EAM, Finnis/Sinclair EAM, modified EAM (MEAM), embedded ion method (EIM), EDIP, ADP, Stillinger-Weber, Tersoff, REBO, AIREBO, ReaxFF, COMB
<LI> electron force field (eFF, AWPMD)
<LI> coarse-grained potentials: DPD, GayBerne, REsquared, colloidal, DLVO
<LI> mesoscopic potentials: granular, Peridynamics
<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
@ -246,6 +249,7 @@ molecular dynamics options:
<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 = "doc/fix_gcmc.html">grand canonical Monte Carlo</A> insertions/deletions
<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_tmd.html">targeted</A> and <A HREF = "fix_smd.html">steered</A> molecular dynamics
@ -253,7 +257,7 @@ molecular dynamics options:
</UL>
<HR>
<A NAME = "1_3"></A><H4>1.3 LAMMPS non-features
<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
@ -371,7 +375,7 @@ spatial-decomposition version exist.
</P>
<HR>
<A NAME = "1_4"></A><H4>1.4 Open source distribution
<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-
@ -416,7 +420,7 @@ 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#10_2">this section</A> describes
<LI>If you find a bug, <A HREF = "Section_errors.html#err_2">this section</A> describes
how to report it.
<LI>If you publish a paper using LAMMPS results, send the citation (and
@ -454,7 +458,7 @@ encouraged.
</UL>
<HR>
<H4><A NAME = "1_5"></A>1.5 Acknowledgments and citations
<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
@ -476,146 +480,58 @@ Hierarchical Modeling".
<P>The following papers describe the parallel algorithms used in LAMMPS.
<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>S. J. Plimpton, R. Pollock, M. Stevens, <B>Particle-Mesh Ewald and
rRESPA for Parallel Molecular Dynamics Simulations</B>, in Proc of the
Eighth SIAM Conference on Parallel Processing for Scientific
Computing, Minneapolis, MN (March 1997).
<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>If you use LAMMPS results in your published work, please cite the J
Comp Phys reference and include a pointer to the <A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A>
(http://lammps.sandia.gov).
<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>If you send is information about your publication, we'll be pleased to
add it to the Publications page of the <A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A>. Ditto
for a picture or movie for the Pictures or Movies pages.
<P>The core group of LAMMPS developers is at Sandia National Labs:
</P>
<P>The core group of LAMMPS developers is at Sandia National Labs. They
include <A HREF = "http://www.sandia.gov/~sjplimp">Steve Plimpton</A>, Paul Crozier, and Aidan Thompson and can
be contacted via email: sjplimp, pscrozi, athomps at sandia.gov.
<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>
<P>Here are various folks who have made significant contributions to
features in LAMMPS. The most recent contributions are at the top of
the list.
</P>
<DIV ALIGN=center><TABLE BORDER=1 >
<TR><TD >ipp Perl script tool </TD><TD > Reese Jones (Sandia)</TD></TR>
<TR><TD >eam_database and createatoms tools </TD><TD > Xiaowang Zhou (Sandia)</TD></TR>
<TR><TD >electron force field (eFF) </TD><TD > Andres Jaramillo-Botero and Julius Su (Caltech)</TD></TR>
<TR><TD >embedded ion method (EIM) potential </TD><TD > Xiaowang Zhou (Sandia)</TD></TR>
<TR><TD >COMB potential with charge equilibration </TD><TD > Tzu-Ray Shan (U Florida)</TD></TR>
<TR><TD >fix ave/correlate </TD><TD > Benoit Leblanc, Dave Rigby, Paul Saxe (Materials Design) and Reese Jones (Sandia)</TD></TR>
<TR><TD >pair_style peri/lps </TD><TD > Mike Parks (Sandia)</TD></TR>
<TR><TD >fix msst </TD><TD > Lawrence Fried (LLNL), Evan Reed (LLNL, Stanford)</TD></TR>
<TR><TD >thermo_style custom tpcpu & spcpu keywords </TD><TD > Axel Kohlmeyer (Temple U) </TD></TR>
<TR><TD >fix rigid/nve, fix rigid/nvt </TD><TD > Tony Sheh and Trung Dac Nguyen (U Michigan)</TD></TR>
<TR><TD >public SVN & Git repositories for LAMMPS </TD><TD > Axel Kohlmeyer (Temple U) and Bill Goldman (Sandia)</TD></TR>
<TR><TD >fix nvt, fix nph, fix npt, Parinello/Rahman dynamics, fix box/relax </TD><TD > Aidan Thompson (Sandia)</TD></TR>
<TR><TD >compute heat/flux </TD><TD > German Samolyuk (ORNL) and Mario Pinto (Computational Research Lab, Pune, India)</TD></TR>
<TR><TD >pair yukawa/colloid </TD><TD > Randy Schunk (Sandia)</TD></TR>
<TR><TD >fix wall/colloid </TD><TD > Jeremy Lechman (Sandia)</TD></TR>
<TR><TD >pair_style dsmc for Direct Simulation Monte Carlo (DSMC) modeling </TD><TD > Paul Crozier (Sandia)</TD></TR>
<TR><TD >fix imd for real-time viz and interactive MD </TD><TD > Axel Kohlmeyer (Temple Univ)</TD></TR>
<TR><TD >concentration-dependent EAM potential </TD><TD > Alexander Stukowski (Technical University of Darmstadt)</TD></TR>
<TR><TD >parallel replica dymamics (PRD) </TD><TD > Mike Brown (Sandia)</TD></TR>
<TR><TD >min_style hftn </TD><TD > Todd Plantenga (Sandia)</TD></TR>
<TR><TD >fix atc </TD><TD > Reese Jones, Jon Zimmerman, Jeremy Templeton (Sandia)</TD></TR>
<TR><TD >dump cfg </TD><TD > Liang Wan (Chinese Academy of Sciences)</TD></TR>
<TR><TD >fix nvt with Nose/Hoover chains </TD><TD > Andy Ballard (U Maryland)</TD></TR>
<TR><TD >pair_style lj/cut/gpu, pair_style gayberne/gpu </TD><TD > Mike Brown (Sandia)</TD></TR>
<TR><TD >pair_style lj96/cut, bond_style table, angle_style table </TD><TD > Chuanfu Luo</TD></TR>
<TR><TD >fix langevin tally </TD><TD > Carolyn Phillips (U Michigan)</TD></TR>
<TR><TD >compute heat/flux for Green-Kubo </TD><TD > Reese Jones (Sandia), Philip Howell (Siemens), Vikas Varsney (AFRL)</TD></TR>
<TR><TD >region cone </TD><TD > Pim Schravendijk</TD></TR>
<TR><TD >fix reax/bonds </TD><TD > Aidan Thompson (Sandia)</TD></TR>
<TR><TD >pair born/coul/long </TD><TD > Ahmed Ismail (Sandia)</TD></TR>
<TR><TD >fix ttm </TD><TD > Paul Crozier (Sandia) and Carolyn Phillips (U Michigan)</TD></TR>
<TR><TD >fix box/relax </TD><TD > Aidan Thompson and David Olmsted (Sandia)</TD></TR>
<TR><TD >ReaxFF potential </TD><TD > Aidan Thompson (Sandia) and Hansohl Cho (MIT)</TD></TR>
<TR><TD >compute cna/atom </TD><TD > Wan Liang (Chinese Academy of Sciences)</TD></TR>
<TR><TD >Tersoff/ZBL potential </TD><TD > Dave Farrell (Northwestern U)</TD></TR>
<TR><TD >peridynamics </TD><TD > Mike Parks (Sandia)</TD></TR>
<TR><TD >fix smd for steered MD </TD><TD > Axel Kohlmeyer (U Penn)</TD></TR>
<TR><TD >GROMACS pair potentials </TD><TD > Mark Stevens (Sandia)</TD></TR>
<TR><TD >lmp2vmd tool </TD><TD > Axel Kohlmeyer (U Penn)</TD></TR>
<TR><TD >compute group/group </TD><TD > Naveen Michaud-Agrawal (Johns Hopkins U)</TD></TR>
<TR><TD >CG-CMM user package for coarse-graining </TD><TD > Axel Kohlmeyer (U Penn)</TD></TR>
<TR><TD >cosine/delta angle potential </TD><TD > Axel Kohlmeyer (U Penn)</TD></TR>
<TR><TD >VIM editor add-ons for LAMMPS input scripts </TD><TD > Gerolf Ziegenhain</TD></TR>
<TR><TD >pair lubricate </TD><TD > Randy Schunk (Sandia)</TD></TR>
<TR><TD >compute ackland/atom </TD><TD > Gerolf Zeigenhain</TD></TR>
<TR><TD >kspace_style ewald/n, pair_style lj/coul, pair_style buck/coul </TD><TD > Pieter in 't Veld (Sandia)</TD></TR>
<TR><TD >AI-REBO bond-order potential </TD><TD > Ase Henry (MIT)</TD></TR>
<TR><TD >making LAMMPS a true "object" that can be instantiated multiple times, e.g. as a library </TD><TD > Ben FrantzDale (RPI)</TD></TR>
<TR><TD >pymol_asphere viz tool </TD><TD > Mike Brown (Sandia)</TD></TR>
<TR><TD >NEMD SLLOD integration </TD><TD > Pieter in 't Veld (Sandia)</TD></TR>
<TR><TD >tensile and shear deformations </TD><TD > Pieter in 't Veld (Sandia)</TD></TR>
<TR><TD >GayBerne potential </TD><TD > Mike Brown (Sandia)</TD></TR>
<TR><TD >ellipsoidal particles </TD><TD > Mike Brown (Sandia)</TD></TR>
<TR><TD >colloid potentials </TD><TD > Pieter in 't Veld (Sandia)</TD></TR>
<TR><TD >fix heat </TD><TD > Paul Crozier and Ed Webb (Sandia)</TD></TR>
<TR><TD >neighbor multi and communicate multi </TD><TD > Pieter in 't Veld (Sandia)</TD></TR>
<TR><TD >MATLAB post-processing scripts </TD><TD > Arun Subramaniyan (Purdue)</TD></TR>
<TR><TD >triclinic (non-orthogonal) simulation domains </TD><TD > Pieter in 't Veld (Sandia)</TD></TR>
<TR><TD >thermo_extract tool</TD><TD > Vikas Varshney (Wright Patterson AFB)</TD></TR>
<TR><TD >fix ave/time and fix ave/spatial </TD><TD > Pieter in 't Veld (Sandia)</TD></TR>
<TR><TD >MEAM potential </TD><TD > Greg Wagner (Sandia)</TD></TR>
<TR><TD >optimized pair potentials for lj/cut, charmm/long, eam, morse </TD><TD > James Fischer (High Performance Technologies), David Richie and Vincent Natoli (Stone Ridge Technologies)</TD></TR>
<TR><TD >fix wall/lj126 </TD><TD > Mark Stevens (Sandia)</TD></TR>
<TR><TD >Stillinger-Weber and Tersoff potentials </TD><TD > Aidan Thompson and Xiaowang Zhou (Sandia)</TD></TR>
<TR><TD >region prism </TD><TD > Pieter in 't Veld (Sandia)</TD></TR>
<TR><TD >LJ tail corrections for energy/pressure </TD><TD > Paul Crozier (Sandia)</TD></TR>
<TR><TD >fix momentum and recenter </TD><TD > Naveen Michaud-Agrawal (Johns Hopkins U)</TD></TR>
<TR><TD >multi-letter variable names </TD><TD > Naveen Michaud-Agrawal (Johns Hopkins U)</TD></TR>
<TR><TD >OPLS dihedral potential</TD><TD > Mark Stevens (Sandia)</TD></TR>
<TR><TD >POEMS coupled rigid body integrator</TD><TD > Rudranarayan Mukherjee (RPI)</TD></TR>
<TR><TD >faster pair hybrid potential</TD><TD > James Fischer (High Performance Technologies, Inc), Vincent Natoli and David Richie (Stone Ridge Technology)</TD></TR>
<TR><TD >breakable bond quartic potential</TD><TD > Chris Lorenz and Mark Stevens (Sandia)</TD></TR>
<TR><TD >DCD and XTC dump styles</TD><TD > Naveen Michaud-Agrawal (Johns Hopkins U)</TD></TR>
<TR><TD >grain boundary orientation fix </TD><TD > Koenraad Janssens and David Olmsted (Sandia)</TD></TR>
<TR><TD >lj/smooth pair potential </TD><TD > Craig Maloney (UCSB) </TD></TR>
<TR><TD >radius-of-gyration spring fix </TD><TD > Naveen Michaud-Agrawal (Johns Hopkins U) and Paul Crozier (Sandia)</TD></TR>
<TR><TD >self spring fix </TD><TD > Naveen Michaud-Agrawal (Johns Hopkins U)</TD></TR>
<TR><TD >EAM CoAl and AlCu potentials </TD><TD > Kwang-Reoul Lee (KIST, Korea)</TD></TR>
<TR><TD >cosine/squared angle potential </TD><TD > Naveen Michaud-Agrawal (Johns Hopkins U)</TD></TR>
<TR><TD >helix dihedral potential </TD><TD > Naveen Michaud-Agrawal (Johns Hopkins U) and Mark Stevens (Sandia)</TD></TR>
<TR><TD >Finnis/Sinclair EAM</TD><TD > Tim Lau (MIT)</TD></TR>
<TR><TD >dissipative particle dynamics (DPD) potentials</TD><TD > Kurt Smith (U Pitt) and Frank van Swol (Sandia)</TD></TR>
<TR><TD >TIP4P potential (4-site water)</TD><TD > Ahmed Ismail and Amalie Frischknecht (Sandia)</TD></TR>
<TR><TD >uniaxial strain fix</TD><TD > Carsten Svaneborg (Max Planck Institute)</TD></TR>
<TR><TD >thermodynamics enhanced by fix quantities</TD><TD > Aidan Thompson (Sandia)</TD></TR>
<TR><TD >compressed dump files</TD><TD > Erik Luijten (U Illinois)</TD></TR>
<TR><TD >cylindrical indenter fix</TD><TD > Ravi Agrawal (Northwestern U)</TD></TR>
<TR><TD >electric field fix</TD><TD > Christina Payne (Vanderbilt U)</TD></TR>
<TR><TD >AMBER <-> LAMMPS tool</TD><TD > Keir Novik (Univ College London) and Vikas Varshney (U Akron)</TD></TR>
<TR><TD >CHARMM <-> LAMMPS tool</TD><TD > Pieter in 't Veld and Paul Crozier (Sandia)</TD></TR>
<TR><TD >Morse bond potential</TD><TD > Jeff Greathouse (Sandia)</TD></TR>
<TR><TD >radial distribution functions</TD><TD > Paul Crozier & Jeff Greathouse (Sandia)</TD></TR>
<TR><TD >force tables for long-range Coulombics</TD><TD > Paul Crozier (Sandia)</TD></TR>
<TR><TD >targeted molecular dynamics (TMD)</TD><TD > Paul Crozier (Sandia) and Christian Burisch (Bochum University, Germany)</TD></TR>
<TR><TD >FFT support for SGI SCSL (Altix)</TD><TD > Jim Shepherd (Ga Tech)</TD></TR>
<TR><TD >lmp2cfg and lmp2traj tools</TD><TD > Ara Kooser, Jeff Greathouse, Andrey Kalinichev (Sandia)</TD></TR>
<TR><TD >parallel tempering</TD><TD > Mark Sears (Sandia)</TD></TR>
<TR><TD >embedded atom method (EAM) potential</TD><TD > Stephen Foiles (Sandia)</TD></TR>
<TR><TD >multi-harmonic dihedral potential</TD><TD > Mathias Puetz (Sandia)</TD></TR>
<TR><TD >granular force fields and BC</TD><TD > Leo Silbert & Gary Grest (Sandia)</TD></TR>
<TR><TD >2d Ewald/PPPM</TD><TD > Paul Crozier (Sandia)</TD></TR>
<TR><TD >CHARMM force fields</TD><TD > Paul Crozier (Sandia)</TD></TR>
<TR><TD >msi2lmp tool</TD><TD > Steve Lustig (Dupont), Mike Peachey & John Carpenter (Cray)</TD></TR>
<TR><TD >HTFN energy minimizer</TD><TD > Todd Plantenga (Sandia)</TD></TR>
<TR><TD >class 2 force fields</TD><TD > Eric Simon (Cray)</TD></TR>
<TR><TD >NVT/NPT integrators</TD><TD > Mark Stevens (Sandia)</TD></TR>
<TR><TD >rRESPA</TD><TD > Mark Stevens & Paul Crozier (Sandia)</TD></TR>
<TR><TD >Ewald and PPPM solvers</TD><TD > Roy Pollock (LLNL) </TD><TD >
</TD></TR></TABLE></DIV>
<P>Other CRADA partners involved in the design and testing of LAMMPS were
<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>Pieter in' t Veld (BASF), pieter.intveld at basf.com, USER-EWALDN package for 1/r^N long-range solvers
<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">this section</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)

View File

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

View File

@ -11,8 +11,26 @@ Section</A>
<HR>
<H3>8. Modifying & extending LAMMPS
<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">Thermodynamic output options</A><BR>
10.13 <A HREF = "#mod_13">Variable options</A><BR>
10.14 <A HREF = "#mod_14">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.
@ -22,7 +40,7 @@ with minimal instructions. If you add a new feature to LAMMPS and
think it will be of interest to general users, we encourage you to
submit it to the developers for inclusion in the released version of
LAMMPS. Information about how to do this is provided
<A HREF = "#package">below</A>.
<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
@ -75,28 +93,9 @@ the executable and can be invoked with a pair_style command like the
example above. Arguments like 0.1 and 3.5 can be defined and
processed by your new class.
</P>
<P>Here is a list of the new features that can be added in this way,
along with information about how to submit your features for inclusion
in the LAMMPS distribution.
</P>
<UL><LI><A HREF = "#atom">Atom styles</A>
<LI><A HREF = "#bond">Bond, angle, dihedral, improper potentials</A>
<LI><A HREF = "#compute">Compute styles</A>
<LI><A HREF = "#dump">Dump styles</A>
<LI><A HREF = "#dump">Dump custom output options</A>
<LI><A HREF = "#fix">Fix styles</A> which include integrators, temperature and pressure control, force constraints, boundary conditions, diagnostic output, etc
<LI><A HREF = "#command">Input script commands</A>
<LI><A HREF = "#kspace">Kspace computations</A>
<LI><A HREF = "#min">Minimization solvers</A>
<LI><A HREF = "#pair">Pairwise potentials</A>
<LI><A HREF = "#region">Region styles</A>
<LI><A HREF = "#thermo">Thermodynamic output options</A>
<LI><A HREF = "#variable">Variable options</A>
</UL>
<UL><LI><A HREF = "#package">Submitting new features to the developers to include in LAMMPS</A>
</UL>
<P>As illustrated by the pairwise example, these options are referred to
in the LAMMPS documentation as the "style" of a particular command.
<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
@ -108,15 +107,9 @@ 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 in
these sections:
thermo.cpp, dump_custom.cpp, and variable.cpp files as explained
below.
</P>
<UL><LI><A HREF = "#dump_custom">Dump custom output options</A>
<LI><A HREF = "#thermo">Thermodynamic output options</A>
<LI><A HREF = "#variable">Variable options</A>
</UL>
<HR>
<P>Here are additional guidelines for modifying LAMMPS and adding new
functionality:
</P>
@ -136,52 +129,58 @@ 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.
interested in adding it to the LAMMPS distribution. See further
details on this at the bottom of this page.
</UL>
<HR>
<HR>
<A NAME = "atom"></A><H4>Atom styles
<A NAME = "mod_1"></A><H4>10.1 Atom styles
</H4>
<P>Classes that define an atom style are derived from the Atom class.
The atom style determines what quantities are associated with an atom.
A new atom style can be created if one of the existing atom styles
does not define all the arrays you need to store and communicate with
atoms.
<P>Classes that define an atom style are derived from the AtomVec class
and managed by the Atom class. The atom style determines what
quantities are associated with an atom. A new atom style can be
created if one of the existing atom styles does not define all
the arrays you need to store and communicate with atoms.
</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.h for details.
class. See atom_vec.h for details.
</P>
<DIV ALIGN=center><TABLE BORDER=1 >
<TR><TD >grow</TD><TD > re-allocate atom arrays to longer lengths</TD></TR>
<TR><TD >copy</TD><TD > copy info for one atom to another atom's array locations</TD></TR>
<TR><TD >pack_comm</TD><TD > store an atom's info in a buffer communicated every timestep</TD></TR>
<TR><TD >pack_comm_vel</TD><TD > add velocity info to buffer</TD></TR>
<TR><TD >pack_comm_one</TD><TD > store extra info unique to this atom style</TD></TR>
<TR><TD >unpack_comm</TD><TD > retrieve an atom's info from the buffer</TD></TR>
<TR><TD >unpack_comm_vel</TD><TD > also retrieve velocity info</TD></TR>
<TR><TD >unpack_comm_one</TD><TD > retreive extra info unique to this atom style</TD></TR>
<TR><TD >pack_reverse</TD><TD > store an atom's info in a buffer communicating partial forces</TD></TR>
<TR><TD >pack_reverse_one</TD><TD > store extra info unique to this atom style</TD></TR>
<TR><TD >unpack_reverse</TD><TD > retrieve an atom's info from the buffer</TD></TR>
<TR><TD >unpack_reverse_one</TD><TD > retreive extra info unique to this atom style</TD></TR>
<TR><TD >pack_border</TD><TD > store an atom's info in a buffer communicated on neighbor re-builds</TD></TR>
<TR><TD >pack_border_vel</TD><TD > add velocity info to buffer</TD></TR>
<TR><TD >pack_border_one</TD><TD > store extra info unique to this atom style</TD></TR>
<TR><TD >unpack_border</TD><TD > retrieve an atom's info from the buffer</TD></TR>
<TR><TD >unpack_border_vel</TD><TD > also retrieve velocity info</TD></TR>
<TR><TD >unpack_border_one</TD><TD > retreive extra info unique to this atom style</TD></TR>
<TR><TD >pack_exchange</TD><TD > store all an atom's info to migrate to another processor</TD></TR>
<TR><TD >unpack_exchange</TD><TD > retrieve an atom's info from the buffer</TD></TR>
<TR><TD >size_restart</TD><TD > number of restart quantities associated with proc's atoms</TD></TR>
<TR><TD >pack_restart</TD><TD > pack atom quantities into a buffer</TD></TR>
<TR><TD >unpack_restart</TD><TD > unpack atom quantities from a buffer</TD></TR>
<TR><TD >create_atom</TD><TD > create an individual atom of this style</TD></TR>
<TR><TD >data_atom</TD><TD > parse an atom line from the data file</TD></TR>
<TR><TD >memory_usage</TD><TD > tally memory allocated by atom arrays
<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
@ -192,7 +191,7 @@ modify.
</P>
<HR>
<A NAME = "bond"></A><H4>Bond, angle, dihedral, improper potentials
<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
@ -202,21 +201,26 @@ add new potentials to LAMMPS.
the harmonic forms of the angle, dihedral, and improper style
commands.
</P>
<P>Here is a brief description of methods you define in your new derived
bond class. See bond.h, angle.h, dihedral.h, and improper.h for
details.
<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 >compute</TD><TD > compute the molecular interactions</TD></TR>
<TR><TD >coeff</TD><TD > set coefficients for one bond type</TD></TR>
<TR><TD >equilibrium_distance</TD><TD > length of bond, used by SHAKE</TD></TR>
<TR><TD >write & read_restart</TD><TD > writes/reads coeffs to restart files</TD></TR>
<TR><TD >single</TD><TD > force and energy of a single bond
<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 = "compute"></A><H4>Compute styles
<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
@ -232,21 +236,28 @@ per-atom kinetic energy.
class. See compute.h for details.
</P>
<DIV ALIGN=center><TABLE BORDER=1 >
<TR><TD >compute_scalar</TD><TD > compute a scalar quantity</TD></TR>
<TR><TD >compute_vector</TD><TD > compute a vector of quantities</TD></TR>
<TR><TD >compute_peratom</TD><TD > compute one or more quantities per atom</TD></TR>
<TR><TD >pack_comm</TD><TD > pack a buffer with items to communicate</TD></TR>
<TR><TD >unpack_comm</TD><TD > unpack the buffer</TD></TR>
<TR><TD >pack_reverse</TD><TD > pack a buffer with items to reverse communicate</TD></TR>
<TR><TD >unpack_reverse</TD><TD > unpack the buffer</TD></TR>
<TR><TD >memory_usage</TD><TD > tally memory usage
<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 = "dump"></A><H4>Dump styles
<A NAME = "mod_4"></A><H4>10.4 Dump styles
</H4>
<A NAME = "dump_custom"></A><H4>Dump custom output options
<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
@ -277,7 +288,7 @@ half-dozen or so locations where code will need to be added.
</P>
<HR>
<A NAME = "fix"></A><H4>Fix styles
<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
@ -297,34 +308,59 @@ implement.
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</TD></TR>
<TR><TD >init</TD><TD > initialization before a run</TD></TR>
<TR><TD >setup</TD><TD > called immediately before the 1st timestep</TD></TR>
<TR><TD >initial_integrate</TD><TD > called at very beginning of each timestep</TD></TR>
<TR><TD >pre_exchange</TD><TD > called before atom exchange on re-neighboring steps</TD></TR>
<TR><TD >pre_neighbor</TD><TD > called before neighbor list build</TD></TR>
<TR><TD >post_force</TD><TD > called after pair & molecular forces are computed</TD></TR>
<TR><TD >final_integrate</TD><TD > called at end of each timestep</TD></TR>
<TR><TD >end_of_step</TD><TD > called at very end of timestep</TD></TR>
<TR><TD >write_restart</TD><TD > dumps fix info to restart file</TD></TR>
<TR><TD >restart</TD><TD > uses info from restart file to re-initialize the fix</TD></TR>
<TR><TD >grow_arrays</TD><TD > allocate memory for atom-based arrays used by fix</TD></TR>
<TR><TD >copy_arrays</TD><TD > copy atom info when an atom migrates to a new processor</TD></TR>
<TR><TD >memory_usage</TD><TD > report memory used by fix</TD></TR>
<TR><TD >pack_exchange</TD><TD > store atom's data in a buffer</TD></TR>
<TR><TD >unpack_exchange</TD><TD > retrieve atom's data from a buffer</TD></TR>
<TR><TD >pack_restart</TD><TD > store atom's data for writing to restart file</TD></TR>
<TR><TD >unpack_restart</TD><TD > retrieve atom's data from a restart file buffer</TD></TR>
<TR><TD >size_restart</TD><TD > size of atom's data</TD></TR>
<TR><TD >maxsize_restart</TD><TD > max size of atom's data</TD></TR>
<TR><TD >initial_integrate_respa</TD><TD > same as initial_integrate, but for rRESPA</TD></TR>
<TR><TD >post_force_respa</TD><TD > same as post_force, but for rRESPA</TD></TR>
<TR><TD >final_integrate_respa</TD><TD > same as final_integrate, but for rRESPA</TD></TR>
<TR><TD >pack_comm</TD><TD > pack a buffer to communicate a per-atom quantity</TD></TR>
<TR><TD >unpack_comm</TD><TD > unpack a buffer to communicate a per-atom quantity</TD></TR>
<TR><TD >pack_reverse_comm</TD><TD > pack a buffer to reverse communicate a per-atom quantity</TD></TR>
<TR><TD >unpack_reverse_comm</TD><TD > unpack a buffer to reverse communicate a per-atom quantity</TD></TR>
<TR><TD >thermo</TD><TD > compute quantities for thermodynamic output
<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 after 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
@ -355,7 +391,7 @@ quantities and/or to be summed to the potential energy of the system.
</P>
<HR>
<A NAME = "command"></A><H4>Input script commands
<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,
@ -377,7 +413,7 @@ needed.
</P>
<HR>
<A NAME = "kspace"></A><H4>Kspace computations
<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
@ -397,7 +433,7 @@ class. See kspace.h for details.
<HR>
<A NAME = "min"></A><H4>Minimization solvers
<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
@ -416,7 +452,7 @@ class. See min.h for details.
<HR>
<A NAME = "pair"></A><H4>Pairwise potentials
<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
@ -445,7 +481,7 @@ includes some optional methods to enable its use with rRESPA.
</P>
<HR>
<A NAME = "region"></A><H4>Region styles
<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
@ -463,17 +499,16 @@ class. See region.h for details.
<HR>
<A NAME = "thermo"></A><H4>Thermodynamic output options
<A NAME = "mod_12"></A><H4>10.12 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 several styles defined in thermo.cpp: "one", "multi",
"granular", etc. There is also a flexible "custom" style which allows
the user to explicitly list keywords for quantities to print when
thermodynamic info is output. See the
<A HREF = "thermo_style.html">thermo_style</A> command for a list of defined
quantities.
<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.
@ -493,7 +528,7 @@ by adding a new keyword to the thermo command.
</P>
<HR>
<A NAME = "variable"></A><H4>Variable options
<A NAME = "mod_13"></A><H4>10.13 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
@ -533,25 +568,29 @@ then be accessed by variables) was discussed
</P>
<HR>
<A NAME = "package"></A><H4>Submitting new features to the developers to include in LAMMPS
<HR>
<A NAME = "mod_14"></A><H4>10.14 Submitting new features for inclusion in LAMMPS
</H4>
<P>We encourage users to submit new features that they add to LAMMPS to
<A HREF = "http://lammps.sandia.gov/authors.html">the developers</A>, especially if
you think they will be useful to other users. If they are broadly
useful we may add them as core files to LAMMPS or as part of a
<A HREF = "Section_start.html#2_3">standard package</A>. Else we will add them as a
user-contributed package. Examples of user packages are in src
sub-directories that start with USER. You can see a list of the both
standard and user packages by typing "make package" in the LAMMPS src
directory.
you think the features will be of interest to other users. If they
are broadly useful we may add them as core files to LAMMPS or as part
of a <A HREF = "Section_start.html#start_3">standard package</A>. Else we will add
them as a user-contributed package or file. Examples of user packages
are in src sub-directories that start with USER. The USER-MISC
package is simply a collection of (mostly) unrelated single files,
which is the simplest way to have your contribution quickly added to
the LAMMPS distribution. You can see a list of the both standard and
user packages by typing "make package" in the LAMMPS src directory.
</P>
<P>With user packages, all we are really providing (aside from the fame
and fortune that accompanies having your name in the source code and
on the <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
<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.
</P>
@ -560,42 +599,56 @@ features of various kinds to LAMMPS. Packages are simply collections
of one or more new class files which are invoked as a new "style"
within a LAMMPS input script. If designed correctly, these additions
do not require changes to the main core of LAMMPS; they are simply
add-on files. If you think your new feature does requires changes in
other LAMMPS files, you'll need to <A HREF = "http://lammps.sandia.gov/authors.html">communicate with the
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.
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 is what you need to do to submit a user package for our
consideration. Following these steps will save time for both you and
us. See existing package files for examples.
<P>Here is what you need to do to submit a user package or single file
for our consideration. Following these steps will save time for both
you and us. See existing package files for examples.
</P>
<P>Your user package will be a directory with a name like USER-FOO. In
<UL><LI>All source files you provide must compile with the most current
version of LAMMPS.
<LI>If your contribution is a single file (actually a *.cpp and *.h file)
it can most rapidly be added to the USER-MISC directory. Send us the
one-line entry to add to the USER-MISC/README file in that dir, along
with the 2 source files. You can do this multiple times if you wish
to contribute several individual features.
<LI>If your contribution is several related featues, it is probably best
to make it a user package directory with a name like USER-FOO. In
addition to your new files, the directory should contain a README, and
Install.csh file. Send us a tarball of this USER-FOO directory.
</P>
<P>The README text file should contain your name and contact information
and a brief description of what your new package does.
</P>
<P>The Install.csh file enables LAMMPS to include and exclude your
package.
</P>
<P>Your new source files need to have the LAMMPS copyright, GPL notice,
and your name at the top. They need to create a class that is inside
the LAMMPS namespace. Other than that, your files can do whatever is
necessary to implement the new features. They don't have to be
written in the same style and syntax as other LAMMPS files, thought
that would be nice.
</P>
<P>Finally, in addition to the USER-FOO tarball, you also need to send us
a documentation file for each new command or style you are adding to
LAMMPS. These are text files which we will convert to HTML. Use one
of the *.txt files in the doc dir as a starting point for the new file
you create, since it should look similar to the doc files for existing
commands and styles. The "Restrictions" section of the doc page
should indicate that your feature is only available if LAMMPS is built
with the "user-foo" package. See other user package files for an
example of how to do this.
</P>
Install.csh file. The README text file should contain your name and
contact information and a brief description of what your new package
does. The Install.csh file enables LAMMPS to include and exclude your
package. See other README and Install.sh files in other USER
directories as examples. Send us a tarball of this USER-FOO
directory.
<LI>Your new source files need to have the LAMMPS copyright, GPL notice,
and your name at the top, like other LAMMPS source files. They need
to create a class that is inside the LAMMPS namespace. Other than
that, your files can do whatever is necessary to implement the new
features. They don't have to be written in the same stylistic format
and syntax as other LAMMPS files, though that would be nice.
<LI>Finally, you must also send a documentation file for each new command
or style you are adding to LAMMPS. This will be one file for a
single-file feature. For a package, it might be several files. These
are simple text files which we will convert to HTML. They must be in
the same format as other *.txt files in the lammps/doc directory for
similar commands and styles. The "Restrictions" section of the doc
page should indicate that your command is only available if LAMMPS is
built with the appropriate USER-MISC or USER-FOO package. See other
user package doc files for an example of how to do this. The txt2html
tool we use to do the conversion can be downloaded from <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.
</UL>
<P>Note that the more clear and self-explanatory you make your doc and
README files, the more likely it is that users will try out your new
feature.

View File

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

422
doc/Section_packages.html Normal file
View File

@ -0,0 +1,422 @@
<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">this section</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">howto</A></TD><TD > ellipse</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 >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 potentials</TD><TD > Mike Brown (ORNL)</TD><TD > <A HREF = "Section_accelerate.html#acc_3">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">howto</A></TD><TD > pour</TD><TD > -</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">howto</A></TD><TD > peptide</TD><TD > -</TD></TR>
<TR ALIGN="center"><TD >OPT</TD><TD > optimized pair potentials</TD><TD > Fischer & Richie & Natoli (2)</TD><TD > <A HREF = "Section_accelerate.html#acc_1">howto</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 >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">howto</A></TD><TD > tad</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 >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 >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>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. These are in the lib directory of the distribution. <A HREF = "Section_start.html#start_3_3">This section</A> of the manual gives details on the 2-step build process with external 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-MISC</TD><TD > single-file contributions</TD><TD > USER-MISC/README</TD><TD > -</TD><TD > -</TD><TD > -</TD><TD > -</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-CUDA</TD><TD > NVIDIA GPU styles</TD><TD > Christian Trott (U Tech Ilmenau)</TD><TD > <A HREF = "Section_accelerate.html#acc_4">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-EWALDN</TD><TD > Ewald for 1/R^n</TD><TD > Pieter in' t Veld (BASF)</TD><TD > <A HREF = "kspace_style.html">kspace_style</A></TD><TD > -</TD><TD > -</TD><TD > -</TD></TR>
<TR ALIGN="center"><TD >USER-OMP</TD><TD > OpenMP threaded styles</TD><TD > Axel Kohlmeyer (Temple U)</TD><TD > <A HREF = "Section_accelerate.html#acc_2">accelerate</A></TD><TD > -</TD><TD > -</TD><TD > -</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">SPH_LAMMPS_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>(2) The ATC package was created by Reese Jones, Jeremy Templeton, and Jon Zimmerman (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, 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. These are in the
lib directory of the distribution. <A HREF = "Section_start.html#start_3_3">This
section</A> of the manual gives details on
the 2-step build process with external libraries.
</P>
<P>More details on each package, from the USER-blah/README file
is given below.
</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-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-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_4">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-EWALDN package
</H4>
<P>This package implements 3 commands which can be used in a LAMMPS input
script: pair_style lj/coul, pair_style buck/coul, and kspace_style
ewald/n.
</P>
<P>The "kspace_style ewald/n" command is similar to standard Ewald for
charges, but also enables the Lennard-Jones interaction, or any 1/r^N
interaction to be of infinite extent, instead of being cutoff. LAMMPS
pair potentials for long-range Coulombic interactions, such as
lj/cut/coul/long can be used with ewald/n. The two new pair_style
commands provide the modifications for the short-range LJ and
Buckingham interactions that can also be used with ewald/n.
</P>
<P>Another advantage of kspace_style ewald/n is that it can be used with
non-orthogonal (triclinic symmetry) simulation boxes, either for just
long-range Coulombic interactions, or for both Coulombic and 1/r^N LJ
or Buckingham, which is not currently possible for other kspace styles
such as PPPM and ewald.
</P>
<P>See the doc pages for these commands for details.
</P>
<P>The person who created these files is Pieter in' t Veld while at
Sandia. He is now at BASF (pieter.intveld at basf.com). Contact him
directly if you have questions.
</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_2">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-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>

408
doc/Section_packages.txt Normal file
View File

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

View File

@ -9,7 +9,7 @@
<HR>
<H3>6. Performance & scalability
<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

View File

@ -6,7 +6,7 @@
:line
6. Performance & scalability :h3
8. Performance & scalability :h3
LAMMPS performance on several prototypical benchmarks and machines is
discussed on the Benchmarks page of the "LAMMPS WWW Site"_lws where

View File

@ -9,8 +9,19 @@
<HR>
<H3>9. Python interface to LAMMPS
<H3>11. Python interface to LAMMPS
</H3>
<P>This section describes how to build and use LAMMPS via a Python
interface.
</P>
<UL><LI>11.1 <A HREF = "#py_1">Extending Python with a serial version of LAMMPS</A>
<LI>11.2 <A HREF = "#py_2">Creating a shared MPI library</A>
<LI>11.3 <A HREF = "#py_3">Extending Python with a parallel version of LAMMPS</A>
<LI>11.4 <A HREF = "#py_4">Extending Python with MPI</A>
<LI>11.5 <A HREF = "#py_5">Testing the Python-LAMMPS interface</A>
<LI>11.6 <A HREF = "#py_6">Using LAMMPS from Python</A>
<LI>11.7 <A HREF = "#py_7">Example Python scripts that use LAMMPS</A>
</UL>
<P>The LAMMPS distribution includes some Python code in its python
directory which wraps the library interface to LAMMPS. This makes it
is possible to run LAMMPS, invoke LAMMPS commands or give it an input
@ -20,16 +31,17 @@ either from a Python script or interactively from a Python prompt.
<P><A HREF = "http://www.python.org">Python</A> is a powerful scripting and programming
language which can be used to wrap software like LAMMPS and other
packages. It can be used to glue multiple pieces of software
together, e.g. to run a coupled or multiscale model. See <A HREF = "Section_howto.html#4_10">this
together, e.g. to run a coupled or multiscale model. See <A HREF = "Section_howto.html#howto_10">this
section</A> of the manual and the couple
directory of the distribution for more ideas about coupling LAMMPS to
other codes. See <A HREF = "Section_start.html#2_4">this section</A> about how to
build LAMMPS as a library, and <A HREF = "Section_howto.html#4_19">this section</A>
for a description of the library interface provided in src/library.cpp
and src/library.h and how to extend it for your needs. As described
below, that interface is what is exposed to Python. It is designed to
be easy to add functions to. This has the effect of extending the
Python inteface as well. See details below.
other codes. See <A HREF = "Section_start.html#start_4">this section</A> about how
to build LAMMPS as a library, and <A HREF = "Section_howto.html#howto_19">this
section</A> for a description of the library
interface provided in src/library.cpp and src/library.h and how to
extend it for your needs. As described below, that interface is what
is exposed to Python. It is designed to be easy to add functions to.
This has the effect of extending the Python inteface as well. See
details below.
</P>
<P>By using the Python interface LAMMPS can also be coupled with a GUI or
visualization tools that display graphs or animations in real time as
@ -88,14 +100,6 @@ setup discussion. The next to last sub-section describes the Python
syntax used to invoke LAMMPS. The last sub-section describes example
Python scripts included in the python directory.
</P>
<UL><LI><A HREF = "#9_1">Extending Python with a serial version of LAMMPS</A>
<LI><A HREF = "#9_2">Creating a shared MPI library</A>
<LI><A HREF = "#9_3">Extending Python with a parallel version of LAMMPS</A>
<LI><A HREF = "#9_4">Extending Python with MPI</A>
<LI><A HREF = "#9_5">Testing the Python-LAMMPS interface</A>
<LI><A HREF = "#9_6">Using LAMMPS from Python</A>
<LI><A HREF = "#9_7">Example Python scripts that use LAMMPS</A>
</UL>
<P>Before proceeding, there are 2 items to note.
</P>
<P>(1) The provided Python wrapper for LAMMPS uses the amazing and
@ -116,7 +120,7 @@ code, you are not building shared versions of these libraries.
</P>
<P>The discussion below describes how to create a shared MPI library. I
suggest you start by configuing LAMMPS without packages installed that
require any libraries besides MPI. See <A HREF = "Section_start.html#2_3">this
require any libraries besides MPI. See <A HREF = "Section_start.html#start_3">this
section</A> of the manual for a discussion of
LAMMPS pacakges. E.g. do not use the KSPACE, GPU, MEAM, POEMS, or
REAX packages.
@ -134,7 +138,7 @@ LAMMPS wrapper.
<HR>
<A NAME = "9_1"></A><H4>Extending Python with a serial version of LAMMPS
<A NAME = "py_1"></A><H4>11.1 Extending Python with a serial version of LAMMPS
</H4>
<P>From the python directory in the LAMMPS distribution, type
</P>
@ -164,7 +168,7 @@ this, where you should replace "foo" with your directory of choice.
</P>
<HR>
<A NAME = "9_2"></A><H4>Creating a shared MPI library
<A NAME = "py_2"></A><H4>11.2 Creating a shared MPI library
</H4>
<P>A shared library is one that is dynamically loadable, which is what
Python requires. On Linux this is a library file that ends in ".so",
@ -175,7 +179,7 @@ by Argonne National Labs. From within the mpich directory, type
</P>
<PRE>./configure --enable-sharedlib=gcc
<PRE>./configure --enable-shared
make
make install
</PRE>
@ -188,14 +192,14 @@ static and shared MPI library. This will be fine for running LAMMPS
from Python since it only uses the shared library. But if you now try
to build LAMMPS by itself as a stand-alone program (cd lammps/src;
make foo) or build other codes that expect to link against libmpich.a,
then those builds will typically fail if the linker uses libmpich.so
instead. This means you will need to remove the file
then those builds may fail if the linker uses libmpich.so instead. If
this happens, it means you will need to remove the file
/usr/local/lib/libmich.so before building LAMMPS again as a
stand-alone code.
</P>
<HR>
<A NAME = "9_3"></A><H4>Extending Python with a parallel version of LAMMPS
<A NAME = "py_3"></A><H4>11.3 Extending Python with a parallel version of LAMMPS
</H4>
<P>From the python directory, type
</P>
@ -233,7 +237,7 @@ will be put in the appropriate directory.
</P>
<HR>
<A NAME = "9_4"></A><H4>Extending Python with MPI
<A NAME = "py_4"></A><H4>11.4 Extending Python with MPI
</H4>
<P>There are several Python packages available that purport to wrap MPI
as a library and allow MPI functions to be called from Python.
@ -308,7 +312,7 @@ print "Proc %d out of %d procs" % (pypar.rank(),pypar.size())
</P>
<HR>
<A NAME = "9_5"></A><H4>Testing the Python-LAMMPS interface
<A NAME = "py_5"></A><H4>11.5 Testing the Python-LAMMPS interface
</H4>
<P>Before using LAMMPS in a Python program, one more step is needed. The
interface to LAMMPS is via the Python ctypes package, which loads the
@ -402,7 +406,7 @@ Python on a single processor, not in parallel.
<HR>
<A NAME = "9_6"></A><H4>Using LAMMPS from Python
<A NAME = "py_6"></A><H4>11.6 Using LAMMPS from Python
</H4>
<P>The Python interface to LAMMPS consists of a Python "lammps" module,
the source code for which is in python/lammps.py, which creates a
@ -498,7 +502,7 @@ subscripting. The one exception is that for a fix that calculates a
global vector or array, a single double value from the vector or array
is returned, indexed by I (vector) or I and J (array). I,J are
zero-based indices. The I,J arguments can be left out if not needed.
See <A HREF = "Section_howto.html#4_15">this section</A> of the manual for a
See <A HREF = "Section_howto.html#howto_15">this section</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
@ -578,7 +582,7 @@ following steps:
src/library.h.
<LI>Verify the new function is syntactically correct by building LAMMPS as
a library - see <A HREF = "Section_start.html#2_4">this section</A> of the
a library - see <A HREF = "Section_start.html#start_4">this section</A> of the
manual.
<LI>Add a wrapper method in the Python LAMMPS module to python/lammps.py
@ -594,7 +598,7 @@ Python script. Isn't ctypes amazing?
<HR>
<A NAME = "9_7"></A><H4>Example Python scripts that use LAMMPS
<A NAME = "py_7"></A><H4>11.7 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

View File

@ -6,7 +6,18 @@
:line
9. Python interface to LAMMPS :h3
11. Python interface to LAMMPS :h3
This section describes how to build and use LAMMPS via a Python
interface.
11.1 "Extending Python with a serial version of LAMMPS"_#py_1
11.2 "Creating a shared MPI library"_#py_2
11.3 "Extending Python with a parallel version of LAMMPS"_#py_3
11.4 "Extending Python with MPI"_#py_4
11.5 "Testing the Python-LAMMPS interface"_#py_5
11.6 "Using LAMMPS from Python"_#py_6
11.7 "Example Python scripts that use LAMMPS"_#py_7 :ul
The LAMMPS distribution includes some Python code in its python
directory which wraps the library interface to LAMMPS. This makes it
@ -18,15 +29,16 @@ either from a Python script or interactively from a Python prompt.
language which can be used to wrap software like LAMMPS and other
packages. It can be used to glue multiple pieces of software
together, e.g. to run a coupled or multiscale model. See "this
section"_Section_howto.html#4_10 of the manual and the couple
section"_Section_howto.html#howto_10 of the manual and the couple
directory of the distribution for more ideas about coupling LAMMPS to
other codes. See "this section"_Section_start.html#2_4 about how to
build LAMMPS as a library, and "this section"_Section_howto.html#4_19
for a description of the library interface provided in src/library.cpp
and src/library.h and how to extend it for your needs. As described
below, that interface is what is exposed to Python. It is designed to
be easy to add functions to. This has the effect of extending the
Python inteface as well. See details below.
other codes. See "this section"_Section_start.html#start_4 about how
to build LAMMPS as a library, and "this
section"_Section_howto.html#howto_19 for a description of the library
interface provided in src/library.cpp and src/library.h and how to
extend it for your needs. As described below, that interface is what
is exposed to Python. It is designed to be easy to add functions to.
This has the effect of extending the Python inteface as well. See
details below.
By using the Python interface LAMMPS can also be coupled with a GUI or
visualization tools that display graphs or animations in real time as
@ -85,14 +97,6 @@ setup discussion. The next to last sub-section describes the Python
syntax used to invoke LAMMPS. The last sub-section describes example
Python scripts included in the python directory.
"Extending Python with a serial version of LAMMPS"_#9_1
"Creating a shared MPI library"_#9_2
"Extending Python with a parallel version of LAMMPS"_#9_3
"Extending Python with MPI"_#9_4
"Testing the Python-LAMMPS interface"_#9_5
"Using LAMMPS from Python"_#9_6
"Example Python scripts that use LAMMPS"_#9_7 :ul
Before proceeding, there are 2 items to note.
(1) The provided Python wrapper for LAMMPS uses the amazing and
@ -114,7 +118,7 @@ code, you are not building shared versions of these libraries.
The discussion below describes how to create a shared MPI library. I
suggest you start by configuing LAMMPS without packages installed that
require any libraries besides MPI. See "this
section"_Section_start.html#2_3 of the manual for a discussion of
section"_Section_start.html#start_3 of the manual for a discussion of
LAMMPS pacakges. E.g. do not use the KSPACE, GPU, MEAM, POEMS, or
REAX packages.
@ -130,7 +134,7 @@ LAMMPS wrapper.
:line
:line
Extending Python with a serial version of LAMMPS :link(9_1),h4
11.1 Extending Python with a serial version of LAMMPS :link(py_1),h4
From the python directory in the LAMMPS distribution, type
@ -160,7 +164,7 @@ If these commands are successful, a {lammps.py} and
:line
Creating a shared MPI library :link(9_2),h4
11.2 Creating a shared MPI library :link(py_2),h4
A shared library is one that is dynamically loadable, which is what
Python requires. On Linux this is a library file that ends in ".so",
@ -171,7 +175,7 @@ by Argonne National Labs. From within the mpich directory, type
:link(mpich,http://www-unix.mcs.anl.gov/mpi)
./configure --enable-sharedlib=gcc
./configure --enable-shared
make
make install :pre
@ -184,14 +188,14 @@ static and shared MPI library. This will be fine for running LAMMPS
from Python since it only uses the shared library. But if you now try
to build LAMMPS by itself as a stand-alone program (cd lammps/src;
make foo) or build other codes that expect to link against libmpich.a,
then those builds will typically fail if the linker uses libmpich.so
instead. This means you will need to remove the file
then those builds may fail if the linker uses libmpich.so instead. If
this happens, it means you will need to remove the file
/usr/local/lib/libmich.so before building LAMMPS again as a
stand-alone code.
:line
Extending Python with a parallel version of LAMMPS :link(9_3),h4
11.3 Extending Python with a parallel version of LAMMPS :link(py_3),h4
From the python directory, type
@ -229,7 +233,7 @@ will be put in the appropriate directory.
:line
Extending Python with MPI :link(9_4),h4
11.4 Extending Python with MPI :link(py_4),h4
There are several Python packages available that purport to wrap MPI
as a library and allow MPI functions to be called from Python.
@ -304,7 +308,7 @@ and see one line of output for each processor you ran on.
:line
Testing the Python-LAMMPS interface :link(9_5),h4
11.5 Testing the Python-LAMMPS interface :link(py_5),h4
Before using LAMMPS in a Python program, one more step is needed. The
interface to LAMMPS is via the Python ctypes package, which loads the
@ -397,7 +401,7 @@ Python on a single processor, not in parallel.
:line
:line
Using LAMMPS from Python :link(9_6),h4
11.6 Using LAMMPS from Python :link(py_6),h4
The Python interface to LAMMPS consists of a Python "lammps" module,
the source code for which is in python/lammps.py, which creates a
@ -493,7 +497,7 @@ subscripting. The one exception is that for a fix that calculates a
global vector or array, a single double value from the vector or array
is returned, indexed by I (vector) or I and J (array). I,J are
zero-based indices. The I,J arguments can be left out if not needed.
See "this section"_Section_howto.html#4_15 of the manual for a
See "this section"_Section_howto.html#howto_15 of the manual for a
discussion of global, per-atom, and local data, and of scalar, vector,
and array data types. See the doc pages for individual
"computes"_compute.html and "fixes"_fix.html for a description of what
@ -573,7 +577,7 @@ Add a new interface function to src/library.cpp and
src/library.h. :ulb,l
Verify the new function is syntactically correct by building LAMMPS as
a library - see "this section"_Section_start.html#2_4 of the
a library - see "this section"_Section_start.html#start_4 of the
manual. :l
Add a wrapper method in the Python LAMMPS module to python/lammps.py
@ -588,7 +592,7 @@ Python script. Isn't ctypes amazing? :l,ule
:line
:line
Example Python scripts that use LAMMPS :link(9_7),h4
11.7 Example Python scripts that use LAMMPS :link(py_7),h4
These are the Python scripts included as demos in the python/examples
directory of the LAMMPS distribution, to illustrate the kinds of

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

View File

@ -11,7 +11,7 @@ Section</A>
<HR>
<H3>7. Additional tools
<H3>9. Additional tools
</H3>
<P>LAMMPS is designed to be a computational kernel for performing
molecular dynamics computations. Additional pre- and post-processing
@ -56,7 +56,6 @@ own sub-directories with their own Makefiles.
<LI><A HREF = "#ipp">ipp</A>
<LI><A HREF = "#arc">lmp2arc</A>
<LI><A HREF = "#cfg">lmp2cfg</A>
<LI><A HREF = "#traj">lmp2traj</A>
<LI><A HREF = "#vmd">lmp2vmd</A>
<LI><A HREF = "#matlab">matlab</A>
<LI><A HREF = "#micelle">micelle2d</A>
@ -251,18 +250,6 @@ the README file for more information.
</P>
<HR>
<H4><A NAME = "traj"></A>lmp2traj tool
</H4>
<P>The lmp2traj sub-directory contains a tool for converting LAMMPS output
files into 3 analysis files. One file can be used to create contour
maps of the atom positions over the course of the simulation. The
other two files provide density profiles and dipole moments. See the
README file for more information.
</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

View File

@ -8,7 +8,7 @@ Section"_Section_modify.html :c
:line
7. Additional tools :h3
9. Additional tools :h3
LAMMPS is designed to be a computational kernel for performing
molecular dynamics computations. Additional pre- and post-processing
@ -52,7 +52,6 @@ own sub-directories with their own Makefiles.
"ipp"_#ipp
"lmp2arc"_#arc
"lmp2cfg"_#cfg
"lmp2traj"_#traj
"lmp2vmd"_#vmd
"matlab"_#matlab
"micelle2d"_#micelle
@ -247,18 +246,6 @@ This tool was written by Ara Kooser at Sandia (askoose at sandia.gov).
:line
lmp2traj tool :h4,link(traj)
The lmp2traj sub-directory contains a tool for converting LAMMPS output
files into 3 analysis files. One file can be used to create contour
maps of the atom positions over the course of the simulation. The
other two files provide density profiles and dipole moments. See the
README file for more information.
This tool was written by Ara Kooser at Sandia (askoose at sandia.gov).
:line
lmp2vmd tool :h4,link(vmd)
The lmp2vmd sub-directory contains a README.txt file that describes

Binary file not shown.

View File

@ -11,6 +11,8 @@
<H3>angle_style charmm command
</H3>
<H3>angle_style charmm/omp command
</H3>
<P><B>Syntax:</B>
</P>
<PRE>angle_style charmm
@ -46,10 +48,34 @@ or <A HREF = "read_restart.html">read_restart</A> commands:
<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>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">this section</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-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">this section</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
"molecular" package (which it is by default). See the <A HREF = "Section_start.html#2_3">Making
MOLECULAR 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>

View File

@ -7,6 +7,7 @@
:line
angle_style charmm command :h3
angle_style charmm/omp command :h3
[Syntax:]
@ -43,11 +44,35 @@ r_ub (distance) :ul
Theta0 is specified in degrees, but LAMMPS converts it to radians
internally; hence the units of K are in energy/radian^2.
:line
Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally
the same as the corresponding style without the suffix. They have
been optimized to run faster, depending on your available hardware,
as discussed in "this section"_Section_accelerate.html of the manual.
The accelerated styles take the same arguments and should produce the
same results, except for round-off and precision issues.
These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
packages, respectively. They are only enabled if LAMMPS was built with
those packages. See the "Making LAMMPS"_Section_start.html#start_3
section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "this section"_Section_accelerate.html of the manual for more
instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
"molecular" package (which it is by default). See the "Making
LAMMPS"_Section_start.html#2_3 section for more info on packages.
MOLECULAR package (which it is by default). See the "Making
LAMMPS"_Section_start.html#start_3 section for more info on packages.
[Related commands:]

View File

@ -11,6 +11,8 @@
<H3>angle_style class2 command
</H3>
<H3>angle_style class2/omp command
</H3>
<P><B>Syntax:</B>
</P>
<PRE>angle_style class2
@ -78,11 +80,35 @@ the angle type.
<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>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">this section</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-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">this section</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#2_3">Making LAMMPS</A>
section for more info on packages.
<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>

View File

@ -7,6 +7,7 @@
:line
angle_style class2 command :h3
angle_style class2/omp command :h3
[Syntax:]
@ -75,11 +76,35 @@ r2 (distance) :ul
The theta0 value in the Eba formula is not specified, since it is the
same value from the Ea formula.
:line
Styles with a {cuda}, {gpu}, {omp}, or {opt} suffix are functionally
the same as the corresponding style without the suffix. They have
been optimized to run faster, depending on your available hardware,
as discussed in "this section"_Section_accelerate.html of the manual.
The accelerated styles take the same arguments and should produce the
same results, except for round-off and precision issues.
These accelerated styles are part of the USER-CUDA, GPU, USER-OMP and OPT
packages, respectively. They are only enabled if LAMMPS was built with
those packages. See the "Making LAMMPS"_Section_start.html#start_3
section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "this section"_Section_accelerate.html of the manual for more
instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
"class2" package. See the "Making LAMMPS"_Section_start.html#2_3
section for more info on packages.
This angle style can only be used if LAMMPS was built with the CLASS2
package. See the "Making LAMMPS"_Section_start.html#start_3 section
for more info on packages.
[Related commands:]

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