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