ICODE-ADC/lammps
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'origin/master' into refactor-reading

Browse Source
This commit is contained in:
Richard Berger
2020-07-17 23:08:26 -04:00
parent c2b557233e 585ed5e1dc
commit c9dc5d90d2
1223 changed files with 865702 additions and 2037147 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
.github/CODEOWNERS vendored
View File

@ -10,6 +10,7 @@ lib/molfile/* @akohlmey
lib/qmmm/* @akohlmey
lib/vtk/* @rbberger
lib/kim/* @ellio167
lib/mesont/* @iafoss
# whole packages
src/COMPRESS/* @akohlmey
@ -25,6 +26,7 @@ src/USER-COLVARS/* @giacomofiorin
src/USER-INTEL/* @wmbrownintel
src/USER-MANIFOLD/* @Pakketeretet2
src/USER-MEAMC/* @martok
src/USER-MESONT/* @iafoss
src/USER-MOFFF/* @hheenen
src/USER-MOLFILE/* @akohlmey
src/USER-NETCDF/* @pastewka
@ -111,11 +113,14 @@ src/fix_nh.* @athomps
src/info.* @akohlmey @rbberger
src/timer.* @akohlmey
src/min* @sjplimp @stanmoore1
src/utils.* @akohlmey @rbberger
# tools
tools/msi2lmp/* @akohlmey
tools/emacs/* @HaoZeke
tools/singularity/* @akohlmey @rbberger
tools/code_standard/* @rbberger
tools/valgrind/* @akohlmey
# tests
unittest/* @akohlmey @rbberger
@ -123,6 +128,8 @@ unittest/* @akohlmey @rbberger
# cmake
cmake/* @junghans @rbberger
cmake/Modules/Packages/USER-COLVARS.cmake @junghans @rbberger @giacomofiorin
cmake/Modules/Packages/KIM.cmake @junghans @rbberger @ellio167
cmake/presets/*.cmake @junghans @rbberger @akohlmey
# python
python/* @rbberger

4
.github/CONTRIBUTING.md vendored
View File

@ -75,7 +75,9 @@ Here is a checklist of steps you need to follow to submit a single file or user
* Your new source files need to have the LAMMPS copyright, GPL notice, and your name and email address at the top, like other user-contributed LAMMPS source files. They need to create a class that is inside the LAMMPS namespace. If the file is for one of the USER packages, including USER-MISC, then we are not as picky about the coding style (see above). I.e. the files do not need to be in the same stylistic format and syntax as other LAMMPS files, though that would be nice for developers as well as users who try to read your code.
* You **must** also create or extend a documentation file for each new command or style you are adding to LAMMPS. For simplicity and convenience, the documentation of groups of closely related commands or styles may be combined into a single file. This will be one file for a single-file feature. For a package, it might be several files. These are files in the [reStructuredText](https://docutils.sourceforge.io/rst.html) markup language, that are then converted to HTML and PDF. The tools for this conversion are included in the source distribution, and the translation can be as simple as doing "make html pdf" in the doc folder. Thus the documentation source files must be in the same format and style as other `<name>.rst` files in the lammps/doc/src directory for similar commands and styles; use one or more of them as a starting point. An introduction to reStructuredText can be found at [https://docutils.sourceforge.io/docs/user/rst/quickstart.html](https://docutils.sourceforge.io/docs/user/rst/quickstart.html). The text files can include mathematical expressions and symbol in ".. math::" sections or ":math:" expressions or figures (see doc/JPG for examples), or even additional PDF files with further details (see doc/PDF for examples). The doc page should also include literature citations as appropriate; see the bottom of doc/fix_nh.rst for examples and the earlier part of the same file for how to format the cite itself. The "Restrictions" section of the doc page should indicate that your command is only available if LAMMPS is built with the appropriate USER-MISC or USER-FOO package. See other user package doc files for examples of how to do this. The prerequisite for building the HTML format files are Python 3.x and virtualenv. Please run at least `make html`, `make pdf` and `make spelling` and carefully inspect and proofread the resulting HTML format doc page as well as the output produced to the screen. Make sure that all spelling errors are fixed or the necessary false positives are added to the `doc/utils/sphinx-config/false_positives.txt` file. For new styles, those usually also need to be added to lists on the respective overview pages. This can be checked for also with `make style_check`.
* For a new package (or even a single command) you should include one or more example scripts demonstrating its use. These should run in no more than a couple minutes, even on a single processor, and not require large data files as input. See directories under examples/USER for examples of input scripts other users provided for their packages. These example inputs are also required for validating memory accesses and testing for memory leaks with valgrind
* If there is a paper of yours describing your feature (either the algorithm/science behind the feature itself, or its initial usage, or its implementation in LAMMPS), you can add the citation to the *.cpp source file. See src/USER-EFF/atom_vec_electron.cpp for an example. A LaTeX citation is stored in a variable at the top of the file and a single line of code that references the variable is added to the constructor of the class. Whenever a user invokes your feature from their input script, this will cause LAMMPS to output the citation to a log.cite file and prompt the user to examine the file. Note that you should only use this for a paper you or your group authored. E.g. adding a cite in the code for a paper by Nose and Hoover if you write a fix that implements their integrator is not the intended usage. That kind of citation should just be in the doc page you provide.
* For new utility functions or class (i.e. anything that does not depend on a LAMMPS object), new unit tests should be added to the unittest tree.
* When adding a new LAMMPS style, a .yaml file with a test configuration and reference data should be added for the styles where a suitable tester program already exists (e.g. pair styles, bond styles, etc.).
* If there is a paper of yours describing your feature (either the algorithm/science behind the feature itself, or its initial usage, or its implementation in LAMMPS), you can add the citation to the <name>.cpp source file. See src/USER-EFF/atom_vec_electron.cpp for an example. A LaTeX citation is stored in a variable at the top of the file and a single line of code that references the variable is added to the constructor of the class. Whenever a user invokes your feature from their input script, this will cause LAMMPS to output the citation to a log.cite file and prompt the user to examine the file. Note that you should only use this for a paper you or your group authored. E.g. adding a cite in the code for a paper by Nose and Hoover if you write a fix that implements their integrator is not the intended usage. That kind of citation should just be in the doc page you provide.
Finally, as a general rule-of-thumb, the more clear and self-explanatory you make your documentation and README files, and the easier you make it for people to get started, e.g. by providing example scripts, the more likely it is that users will try out your new feature.

1
.github/PULL_REQUEST_TEMPLATE.md vendored
View File

@ -34,6 +34,7 @@ By submitting this pull request, I agree, that my contribution will be included
- [ ] The added/updated documentation is integrated and tested with the documentation build system
- [ ] The feature has been verified to work with the conventional build system
- [ ] The feature has been verified to work with the CMake based build system
- [ ] Suitable tests have been added to the unittest tree.
- [ ] A package specific README file has been included or updated
- [ ] One or more example input decks are included

51
bench/FERMI/README
View File

@ -1,51 +0,0 @@
These are input scripts used to run versions of several of the
benchmarks in the top-level bench directory using the GPU accelerator
package. The results of running these scripts on two different machines
(a desktop with 2 Tesla GPUs and the ORNL Titan supercomputer) are shown
on the "GPU (Fermi)" section of the Benchmark page of the LAMMPS WWW
site: lammps.sandia.gov/bench.
Examples are shown below of how to run these scripts. This assumes
you have built 3 executables with the GPU package
installed, e.g.
lmp_linux_single
lmp_linux_mixed
lmp_linux_double
------------------------------------------------------------------------
To run on just CPUs (without using the GPU styles),
do something like the following:
mpirun -np 1 lmp_linux_double -v x 8 -v y 8 -v z 8 -v t 100 < in.lj
mpirun -np 12 lmp_linux_double -v x 16 -v y 16 -v z 16 -v t 100 < in.eam
The "xyz" settings determine the problem size. The "t" setting
determines the number of timesteps.
These mpirun commands run on a single node. To run on multiple
nodes, scale up the "-np" setting.
------------------------------------------------------------------------
To run with the GPU package, do something like the following:
mpirun -np 12 lmp_linux_single -sf gpu -v x 32 -v y 32 -v z 64 -v t 100 < in.lj
mpirun -np 8 lmp_linux_mixed -sf gpu -pk gpu 2 -v x 32 -v y 32 -v z 64 -v t 100 < in.eam
The "xyz" settings determine the problem size. The "t" setting
determines the number of timesteps. The "np" setting determines how
many MPI tasks (per node) the problem will run on. The numeric
argument to the "-pk" setting is the number of GPUs (per node); 1 GPU
is the default. Note that you can use more MPI tasks than GPUs (per
node) with the GPU package.
These mpirun commands run on a single node. To run on multiple nodes,
scale up the "-np" setting, and control the number of MPI tasks per
node via a "-ppn" setting.
------------------------------------------------------------------------
If the script has "titan" in its name, it was run on the Titan
supercomputer at ORNL.

24
bench/FERMI/in.eam
View File

@ -1,24 +0,0 @@
# bulk Cu lattice
units metal
atom_style atomic
lattice fcc 3.615
region box block 0 $x 0 $y 0 $z
create_box 1 box
create_atoms 1 box
pair_style eam
pair_coeff 1 1 Cu_u3.eam
velocity all create 1600.0 376847 loop geom
neighbor 1.0 bin
neigh_modify every 1 delay 5 check yes
fix 1 all nve
timestep 0.005
thermo 50
run $t

37
bench/FERMI/in.eam.titan
View File

@ -1,37 +0,0 @@
# bulk Cu lattice
newton off
package gpu force/neigh 0 0 1
processors * * * grid numa
variable x index 1
variable y index 1
variable z index 1
variable xx equal 20*$x
variable yy equal 20*$y
variable zz equal 20*$z
units metal
atom_style atomic
lattice fcc 3.615
region box block 0 ${xx} 0 ${yy} 0 ${zz}
create_box 1 box
create_atoms 1 box
pair_style eam/gpu
pair_coeff 1 1 Cu_u3.eam
velocity all create 1600.0 376847 loop geom
neighbor 1.0 bin
neigh_modify every 1 delay 5 check yes
fix 1 all nve
timestep 0.005
thermo 50
run 15
run 100

22
bench/FERMI/in.lj
View File

@ -1,22 +0,0 @@
# 3d Lennard-Jones melt
units lj
atom_style atomic
lattice fcc 0.8442
region box block 0 $x 0 $y 0 $z
create_box 1 box
create_atoms 1 box
mass 1 1.0
velocity all create 1.44 87287 loop geom
pair_style lj/cut 2.5
pair_coeff 1 1 1.0 1.0 2.5
neighbor 0.3 bin
neigh_modify delay 0 every 20 check no
fix 1 all nve
run $t

35
bench/FERMI/in.lj.titan
View File

@ -1,35 +0,0 @@
# 3d Lennard-Jones melt
newton off
package gpu force/neigh 0 0 1
processors * * * grid numa
variable x index 1
variable y index 1
variable z index 1
variable xx equal 20*$x
variable yy equal 20*$y
variable zz equal 20*$z
units lj
atom_style atomic
lattice fcc 0.8442
region box block 0 ${xx} 0 ${yy} 0 ${zz}
create_box 1 box
create_atoms 1 box
mass 1 1.0
velocity all create 1.44 87287 loop geom
pair_style lj/cut/gpu 2.5
pair_coeff 1 1 1.0 1.0 2.5
neighbor 0.3 bin
neigh_modify delay 0 every 20 check no
fix 1 all nve
run 15
run 100

30
bench/FERMI/in.rhodo
View File

@ -1,30 +0,0 @@
# Rhodopsin model
units real
neigh_modify delay 5 every 1
atom_style full
atom_modify map hash
bond_style harmonic
angle_style charmm
dihedral_style charmm
improper_style harmonic
pair_style lj/charmm/coul/long 8.0 10.0
pair_modify mix arithmetic
kspace_style pppm 1e-4
read_data data.rhodo
replicate $x $y $z
fix 1 all shake 0.0001 5 0 m 1.0 a 232
fix 2 all npt temp 300.0 300.0 100.0 &
z 0.0 0.0 1000.0 mtk no pchain 0 tchain 1
special_bonds charmm
thermo 50
thermo_style multi
timestep 2.0
run $t

39
bench/FERMI/in.rhodo.scaled.titan
View File

@ -1,39 +0,0 @@
# Rhodopsin model
newton off
package gpu force/neigh 0 0 1
processors * * * grid numa
variable x index 1
variable y index 1
variable z index 1
units real
neigh_modify delay 5 every 1
atom_style full
atom_modify map hash
bond_style harmonic
angle_style charmm
dihedral_style charmm
improper_style harmonic
pair_style lj/charmm/coul/long/gpu 8.0 ${cutoff}
pair_modify mix arithmetic
kspace_style pppm/gpu 1e-4
read_data data.rhodo
replicate $x $y $z
fix 1 all shake 0.0001 5 0 m 1.0 a 232
fix 2 all npt temp 300.0 300.0 100.0 &
z 0.0 0.0 1000.0 mtk no pchain 0 tchain 1
special_bonds charmm
thermo 50
# thermo_style multi
timestep 2.0
run 15
run 100

42
bench/FERMI/in.rhodo.split.titan
View File

@ -1,42 +0,0 @@
# Rhodopsin model
newton off
package gpu force/neigh 0 0 1
partition yes 1 processors * * * grid twolevel ${grid} * * * &
part 1 2 multiple
partition yes 2 processors * * * part 1 2 multiple
variable x index 1
variable y index 1
variable z index 1
units real
neigh_modify delay 5 every 1
atom_style full
atom_modify map hash
bond_style harmonic
angle_style charmm
dihedral_style charmm
improper_style harmonic
pair_style lj/charmm/coul/long/gpu 8.0 ${cutoff}
pair_modify mix arithmetic
kspace_style pppm/gpu 1e-4
read_data data.rhodo
replicate $x $y $z
fix 1 all shake 0.0001 5 0 m 1.0 a 232
fix 2 all npt temp 300.0 300.0 100.0 &
z 0.0 0.0 1000.0 mtk no pchain 0 tchain 1
special_bonds charmm
thermo 50
# thermo_style multi
timestep 2.0
run_style verlet/split
run 15
run 100

2
bench/POTENTIALS/Ni.meam
View File

@ -1,2 +0,0 @@
rc = 4.0
delr = 0.1

1
bench/POTENTIALS/Ni.meam Symbolic link
View File

@ -0,0 +1 @@
../../potentials/Ni.meam

17
bench/POTENTIALS/Si.sw
View File

@ -1,17 +0,0 @@
# Stillinger-Weber parameters for various elements and mixtures
# multiple entries can be added to this file, LAMMPS reads the ones it needs
# these entries are in LAMMPS "metal" units:
# epsilon = eV; sigma = Angstroms
# other quantities are unitless
# format of a single entry (one or more lines):
# element 1, element 2, element 3,
# epsilon, sigma, a, lambda, gamma, costheta0, A, B, p, q, tol
# Here are the original parameters in metal units, for Silicon from:
#
# Stillinger and Weber, Phys. Rev. B, v. 31, p. 5262, (1985)
#
Si Si Si 2.1683 2.0951 1.80 21.0 1.20 -0.333333333333
7.049556277 0.6022245584 4.0 0.0 0.0

1
bench/POTENTIALS/Si.sw Symbolic link
View File

@ -0,0 +1 @@
../../potentials/Si.sw

16
bench/POTENTIALS/Si.tersoff
View File

@ -1,16 +0,0 @@
# Tersoff parameters for various elements and mixtures
# multiple entries can be added to this file, LAMMPS reads the ones it needs
# these entries are in LAMMPS "metal" units:
# A,B = eV; lambda1,lambda2,lambda3 = 1/Angstroms; R,D = Angstroms
# other quantities are unitless
# This is the Si parameterization from a particular Tersoff paper:
# J. Tersoff, PRB, 37, 6991 (1988)
# See the SiCGe.tersoff file for different Si variants.
# format of a single entry (one or more lines):
# element 1, element 2, element 3,
# m, gamma, lambda3, c, d, costheta0, n, beta, lambda2, B, R, D, lambda1, A
Si Si Si 3.0 1.0 1.3258 4.8381 2.0417 0.0000 22.956
0.33675 1.3258 95.373 3.0 0.2 3.2394 3264.7

1
bench/POTENTIALS/Si.tersoff Symbolic link
View File

@ -0,0 +1 @@
../../potentials/Si.tersoff

24
bench/POTENTIALS/in.meam
View File

@ -1,24 +0,0 @@
# bulk Ni in MEAM
units metal
atom_style atomic
lattice fcc 3.52
region box block 0 20 0 20 0 20
create_box 1 box
create_atoms 1 box
pair_style meam
pair_coeff * * library.meam Ni4 Ni.meam Ni4
velocity all create 1600.0 376847 loop geom
neighbor 1.0 bin
neigh_modify delay 5 every 1
fix 1 all nve
timestep 0.005
thermo 50
run 100

22
bench/POTENTIALS/in.reax
View File

@ -1,22 +0,0 @@
# ReaxFF benchmark: simulation of PETN crystal, replicated unit cell
units real
atom_style charge
read_data data.reax
#replicate 7 8 10
replicate 7 8 5
velocity all create 300.0 9999
pair_style reax
pair_coeff * * ffield.reax 1 2 3 4
timestep 0.1
fix 2 all nve
thermo 10
thermo_style custom step temp ke pe pxx pyy pzz etotal
run 100

162
bench/POTENTIALS/library.meam
View File

@ -1,162 +0,0 @@
# meam data from vax files fcc,bcc,dia 11/4/92
# elt lat z ielement atwt
# alpha b0 b1 b2 b3 alat esub asub
# t0 t1 t2 t3 rozero ibar
'Sn5' 'dia' 4. 50 118.
5.09 5.00 16.0 04.0 5.0 6.483 3.14 1.00
1.0 2.00 5.756 -0.30 1. 0
'Sn' 'dia' 4. 50 118.
5.09 5.42 8.0 5.0 6.0 6.483 3.14 1.12
1.0 3.0 5.707 +0.30 1. 0
'Cu' 'fcc' 12. 29 63.54
5.10570729 3.634 2.20 6 2.20 3.62 3.54 1.07
1.0 3.13803254 2.49438711 2.95269237 1. 0
'Ag' 'fcc' 12. 47 107.870
5.89222008 4.456 2.20 6 2.20 4.08 2.85 1.06
1.0 5.54097609 2.45015783 1.28843988 1. 0
'Au' 'fcc' 12. 79 196.967
6.34090112 5.449 2.20 6 2.20 4.07 3.93 1.04
1.0 1.58956328 1.50776392 2.60609758 1. 0
'Ni1' 'fcc' 12. 28 58.71
4.99 2.45 2.20 6 2.20 3.52 4.45 1.10
1.0 3.57 1.60 3.70 1.0 0
'Ni2' 'fcc' 12. 28 58.71
4.99 2.45 2.20 6 2.20 3.52 4.45 1.10
1.0 3.57 1.60 3.70 1.0 3
'Ni3' 'fcc' 12. 28 58.71
4.99 2.45 1.50 6 1.50 3.52 4.45 1.10
1.0 3.57 1.60 3.70 1.0 3
'Ni4' 'fcc' 12. 28 58.71
4.99 2.45 1.50 6 1.50 3.52 4.45 1.10
1.0 3.57 1.60 3.70 1.0 0
'Ni' 'fcc' 12. 28 58.71
4.99 2.64 1.50 4.50 1.50 3.52 4.45 1.10
1.0 1.692 4.987 3.683 1.0 1
'Nix' 'fcc' 12. 28 58.71
4.99 2.64 1.50 4.50 1.50 3.52 4.45 1.10
1.0 0.00 0.000 3.683 1.0 1
'Ni' 'fcc' 12. 28 58.71
4.99 3.25 0.80 4 1.50 3.52 4.45 1.07
1.0 -4.052 13.14 3.786 1.0 1
'Pd' 'fcc' 12. 46 106.4
6.43230473 4.975 2.20 6 2.20 3.89 3.91 1.01
1.0 2.33573516 1.38343023 4.47989049 1. 0
'Pt' 'fcc' 12. 78 195.09
6.44221724 4.673 2.20 6 2.20 3.92 5.77 1.04
1.0 2.73335406 -1.3759593 3.29322278 1. 0
'Al' 'fcc' 12. 13 26.9815
4.61 2.21 2.20 6.0 2.20 4.05 3.58 1.07
1.0 -1.78 -2.21 8.01 0.6 0
'Al' 'fcc' 12. 13 26.9815
4.69 1.56 4.00 5.5 0.60 4.05 3.36 1.09
1.0 -0.251 -3.450 8.298 0.6 1
'Al' 'fcc' 12. 13 26.9815
4.69 1.58 1.00 6.0 0.60 4.05 3.36 1.09
1.0 -0.808 -2.614 8.298 0.6 1
'Pb' 'fcc' 12. 82 207.19
6.0564428 5.306 2.20 6 2.20 4.95 2.04 1.01
1.0 2.74022352 3.06323991 1.2 1. 0
'Rh' 'fcc' 12. 45 102.905
6.0045385 1.131 1.00 2 1.00 3.8 5.75 1.05
1.0 2.9900 4.60231784 4.8 1. 0
'Ir' 'fcc' 12. 77 192.2
6.52315787 1.13 1.00 2 1.00 3.84 6.93 1.05
1.0 1.50000 8.09942666 4.8 1. 0
'Li' 'bcc' 8. 3 6.939
2.97244804 1.425 1.00 1.00169907 1.00 3.509 1.65 0.87
1.0 0.26395017 0.44431129 -0.2 1. 0
'Na' 'bcc' 8. 11 22.9898
3.64280541 2.313 1.00 1.00173951 1.00 4.291 1.13 0.9
1.0 3.55398839 0.68807569 -0.2 1. 0
'K' 'bcc' 8. 19 39.102
3.90128376 2.687 1.00 1.00186667 1.00 5.344 0.94 0.92
1.0 5.09756981 0.69413264 -0.2 1. 0
'V' 'bcc' 8. 23 50.942
4.83265262 4.113 1.00 1.00095022 1.00 3.04 5.3 1
1.0 4.20161301 4.09946561 -1 1. 0
'Nb' 'bcc' 8. 41 92.906
4.79306197 4.374 1.00 1.00101441 1.00 3.301 7.47 1
1.0 3.75762849 3.82514598 -1 1. 0
'Ta' 'bcc' 8. 73 180.948
4.89528669 3.709 1.00 1.00099783 1.00 3.303 8.09 0.99
1.0 6.08617812 3.35255804 -2.9 1. 0
'Cr' 'bcc' 8. 24 51.996
5.12169218 3.224 1.00 1.00048646 1.00 2.885 4.1 0.94
1.0 -0.207535 12.2600006 -1.9 1. 0
'Mo' 'bcc' 8. 42 95.94
5.84872871 4.481 1.00 1.00065204 1.00 3.15 6.81 0.99
1.0 3.47727181 9.48582009 -2.9 1. 0
'W' 'bcc' 8. 74 183.85
5.62777409 3.978 1.00 1.00065894 1.00 3.165 8.66 0.98
1.0 3.16353338 8.24586928 -2.7 1. 0
'WL' 'bcc' 8 74 183.85
5.6831 6.54 1 1 1 3.1639 8.66 0.4
1 -0.6 0.3 -8.7 1 3
'Fe' 'bcc' 8. 26 55.847
5.07292627 2.935 1.00 1.00080073 1.00 2.866 4.29 0.89
1.0 5.13579244 4.12042448 -2.7 1. 0
'Si' 'dia' 4. 14 28.086
4.87 4.8 4.8 4.8 4.8 5.431 4.63 1.
1.0 3.30 5.105 -0.80 1. 1
'Si97' 'dia' 4. 14 28.086
4.87 4.4 5.5 5.5 5.5 5.431 4.63 1.
1.0 3.13 4.47 -1.80 2.05 0
'Si92' 'dia' 4. 14 28.086
4.87 4.4 5.5 5.5 5.5 5.431 4.63 1.
1.0 3.13 4.47 -1.80 2.35 0
'Six' 'dia' 4 14 28.086
4.87 4.4 5.5 5.5 5.5 5.431 4.63 1.0
1.0 2.05 4.47 -1.8 2.05 0
'Sixb' 'dia' 4 14 28.086
4.87 4.4 5.5 5.5 5.5 5.431 4.63 1.0
1.0 2.05 4.47 -1.8 2.5 0
'Mg' 'hcp' 12. 12 24.305
5.45 2.70 0.0 0.35 3.0 3.20 1.55 1.11
1.0 8.00 04.1 -02.0 1.0 0
'C' 'dia' 4. 6 12.0111
4.38 4.10 4.200 5.00 3.00 3.567 7.37 1.000
1.0 5.0 9.34 -1.00 2.25 1
'C' 'dia' 4. 6 12.0111
4.38 5.20 3.87 4.00 4.50 3.567 7.37 1.278
1.0 15. 2.09 -6.00 2.5 1
'C' 'dia' 4. 6 12.0111
4.38 4.50 4.00 3.50 4.80 3.567 7.37 1.00
1.0 10.5 1.54 -8.75 3.2 1
'C' 'dia' 4. 6 12.0111
4.38 3.30 2.80 1.50 3.20 3.567 7.37 1.00
1.0 10.3 1.54 -8.80 2.5 1
'C' 'dia' 4. 6 12.0111
4.38 4.60 3.45 4.00 4.20 3.567 7.37 1.061
1.0 15.0 1.74 -8.00 2.5 1
'C' 'dia' 4. 6 12.0111
4.38 4.50 4.00 3.50 4.80 3.567 7.37 1.00
1.0 10.5 1.54 -8.75 3.2 1
'h' 'dim' 1. 1 1.0079
2.96 2.70 3.5 3.4 3.4 0.74 2.235 2.27
1.0 0.19 0.00 0.00 20.00 0
'h' 'dim' 1. 1 1.0079
2.96 2.00 4.0 4.0 0.0 0.74 2.235 1.00
1.0 -0.60 -0.80 -0.0 01.0 1
'H' 'dim' 1. 1 1.0079
2.96 2.96 3.0 3.0 3.0 0.74 2.235 2.50
1.0 0.20 -0.10 0.0 0.5 0
'H' 'dim' 1. 1 1.0079
2.96 2.0 3.0 4.0 0.0 0.74 2.225 1.00
1.0 -0.5 -1.00 0.0 0.15 1
'H' 'dim' 1. 1 1.0079
2.96 2.00 2.0 2.0 2.0 0.74 2.235 1.00
1.0 -0.60 -0.80 -0.0 01.0 2
'Hni' 'dim' 1. 1 1.0079
2.96 2.96 3.0 3.0 3.0 0.74 2.235 2.50
1.0 0.2 -0.1 0.0 0.5 0
'Hni' 'dim' 1. 1 1.0079
2.96 2.96 3.0 2.0 3.0 0.74 2.235 36.4
1.0 0.2 6.0 0.0 22.8 0
'Vac' 'fcc' 12. 1 1.
0 0 0.0 0 0.0 1E+08 0 1
0 0 0 0 1. 0
'zz' 'zzz' 99. 1 1.
0 0 0.0 0 0.0 0. 0. 0.
0 0 0 0 1. 0

1
bench/POTENTIALS/library.meam Symbolic link
View File

@ -0,0 +1 @@
../../potentials/library.meam

84
bench/POTENTIALS/log.16Mar18.meam.1
View File

@ -1,84 +0,0 @@
LAMMPS (16 Mar 2018)
OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (../comm.cpp:90)
using 1 OpenMP thread(s) per MPI task
# bulk Ni in MEAM
units metal
atom_style atomic
lattice fcc 3.52
Lattice spacing in x,y,z = 3.52 3.52 3.52
region box block 0 20 0 20 0 20
create_box 1 box
Created orthogonal box = (0 0 0) to (70.4 70.4 70.4)
1 by 1 by 1 MPI processor grid
create_atoms 1 box
Created 32000 atoms
Time spent = 0.00186539 secs
pair_style meam
WARNING: The pair_style meam command is unsupported. Please use pair_style meam/c instead (../pair_meam.cpp:51)
pair_coeff * * library.meam Ni4 Ni.meam Ni4
velocity all create 1600.0 376847 loop geom
neighbor 1.0 bin
neigh_modify delay 5 every 1
fix 1 all nve
timestep 0.005
thermo 50
run 100
Neighbor list info ...
update every 1 steps, delay 5 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 5
ghost atom cutoff = 5
binsize = 2.5, bins = 29 29 29
2 neighbor lists, perpetual/occasional/extra = 2 0 0
(1) pair meam, perpetual
attributes: full, newton on
pair build: full/bin/atomonly
stencil: full/bin/3d
bin: standard
(2) pair meam, perpetual, half/full from (1)
attributes: half, newton on
pair build: halffull/newton
stencil: none
bin: none
Per MPI rank memory allocation (min/avg/max) = 55.91 | 55.91 | 55.91 Mbytes
Step Temp E_pair E_mol TotEng Press
0 1600 -142400 0 -135782.09 20259.18
50 885.10702 -139411.51 0 -135750.54 32425.433
100 895.5097 -139454.3 0 -135750.3 31804.187
Loop time of 30.6278 on 1 procs for 100 steps with 32000 atoms
Performance: 1.410 ns/day, 17.015 hours/ns, 3.265 timesteps/s
99.8% CPU use with 1 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 30.088 | 30.088 | 30.088 | 0.0 | 98.24
Neigh | 0.48914 | 0.48914 | 0.48914 | 0.0 | 1.60
Comm | 0.015916 | 0.015916 | 0.015916 | 0.0 | 0.05
Output | 0.00022554 | 0.00022554 | 0.00022554 | 0.0 | 0.00
Modify | 0.025481 | 0.025481 | 0.025481 | 0.0 | 0.08
Other | | 0.009055 | | | 0.03
Nlocal: 32000 ave 32000 max 32000 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 13576 ave 13576 max 13576 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 780360 ave 780360 max 780360 min
Histogram: 1 0 0 0 0 0 0 0 0 0
FullNghs: 1.56072e+06 ave 1.56072e+06 max 1.56072e+06 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 1560720
Ave neighs/atom = 48.7725
Neighbor list builds = 8
Dangerous builds = 0
Total wall time: 0:00:30

84
bench/POTENTIALS/log.16Mar18.meam.4
View File

@ -1,84 +0,0 @@
LAMMPS (16 Mar 2018)
OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (../comm.cpp:90)
using 1 OpenMP thread(s) per MPI task
# bulk Ni in MEAM
units metal
atom_style atomic
lattice fcc 3.52
Lattice spacing in x,y,z = 3.52 3.52 3.52
region box block 0 20 0 20 0 20
create_box 1 box
Created orthogonal box = (0 0 0) to (70.4 70.4 70.4)
1 by 2 by 2 MPI processor grid
create_atoms 1 box
Created 32000 atoms
Time spent = 0.000587463 secs
pair_style meam
WARNING: The pair_style meam command is unsupported. Please use pair_style meam/c instead (../pair_meam.cpp:51)
pair_coeff * * library.meam Ni4 Ni.meam Ni4
velocity all create 1600.0 376847 loop geom
neighbor 1.0 bin
neigh_modify delay 5 every 1
fix 1 all nve
timestep 0.005
thermo 50
run 100
Neighbor list info ...
update every 1 steps, delay 5 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 5
ghost atom cutoff = 5
binsize = 2.5, bins = 29 29 29
2 neighbor lists, perpetual/occasional/extra = 2 0 0
(1) pair meam, perpetual
attributes: full, newton on
pair build: full/bin/atomonly
stencil: full/bin/3d
bin: standard
(2) pair meam, perpetual, half/full from (1)
attributes: half, newton on
pair build: halffull/newton
stencil: none
bin: none
Per MPI rank memory allocation (min/avg/max) = 17.41 | 17.41 | 17.41 Mbytes
Step Temp E_pair E_mol TotEng Press
0 1600 -142400 0 -135782.09 20259.18
50 885.10702 -139411.51 0 -135750.54 32425.433
100 895.5097 -139454.3 0 -135750.3 31804.187
Loop time of 8.21941 on 4 procs for 100 steps with 32000 atoms
Performance: 5.256 ns/day, 4.566 hours/ns, 12.166 timesteps/s
99.2% CPU use with 4 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 8.0277 | 8.0384 | 8.0504 | 0.3 | 97.80
Neigh | 0.12555 | 0.12645 | 0.12713 | 0.2 | 1.54
Comm | 0.024279 | 0.036776 | 0.048389 | 4.5 | 0.45
Output | 9.4414e-05 | 0.00011903 | 0.00018597 | 0.0 | 0.00
Modify | 0.01252 | 0.012608 | 0.012795 | 0.1 | 0.15
Other | | 0.005028 | | | 0.06
Nlocal: 8000 ave 8045 max 7947 min
Histogram: 1 0 0 1 0 0 0 1 0 1
Nghost: 6066.75 ave 6120 max 6021 min
Histogram: 1 0 1 0 0 0 1 0 0 1
Neighs: 195090 ave 196403 max 193697 min
Histogram: 1 0 0 1 0 0 0 1 0 1
FullNghs: 390180 ave 392616 max 387490 min
Histogram: 1 0 0 1 0 0 0 1 0 1
Total # of neighbors = 1560720
Ave neighs/atom = 48.7725
Neighbor list builds = 8
Dangerous builds = 0
Total wall time: 0:00:08

86
bench/POTENTIALS/log.16Mar18.reax.1
View File

@ -1,86 +0,0 @@
LAMMPS (16 Mar 2018)
OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (../comm.cpp:90)
using 1 OpenMP thread(s) per MPI task
# ReaxFF benchmark: simulation of PETN crystal, replicated unit cell
units real
atom_style charge
read_data data.reax
orthogonal box = (0 0 0) to (9.49107 9.49107 6.99123)
1 by 1 by 1 MPI processor grid
reading atoms ...
58 atoms
#replicate 7 8 10
replicate 7 8 5
orthogonal box = (0 0 0) to (66.4375 75.9285 34.9562)
1 by 1 by 1 MPI processor grid
16240 atoms
Time spent = 0.000834942 secs
velocity all create 300.0 9999
pair_style reax
WARNING: The pair_style reax command is unsupported. Please switch to pair_style reax/c instead (../pair_reax.cpp:49)
pair_coeff * * ffield.reax 1 2 3 4
timestep 0.1
fix 2 all nve
thermo 10
thermo_style custom step temp ke pe pxx pyy pzz etotal
run 100
Neighbor list info ...
update every 1 steps, delay 10 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 12
ghost atom cutoff = 12
binsize = 6, bins = 12 13 6
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair reax, perpetual
attributes: half, newton off
pair build: half/bin/newtoff
stencil: half/bin/3d/newtoff
bin: standard
Per MPI rank memory allocation (min/avg/max) = 115.8 | 115.8 | 115.8 Mbytes
Step Temp KinEng PotEng Pxx Pyy Pzz TotEng
0 300 14521.612 -1616144.2 22296.712 -29858.677 5721.0921 -1601622.5
10 298.98728 14472.591 -1616093.9 21955.847 -24067.096 7389.148 -1601621.3
20 294.76158 14268.045 -1615890.1 19179.258 -10513.494 10789.925 -1601622
30 288.56967 13968.323 -1615591.2 13854.377 5833.02 13949.731 -1601622.9
40 282.06725 13653.571 -1615278.2 6259.9845 19406.33 14947.939 -1601624.6
50 274.84112 13303.787 -1614931.9 -2009.6832 26964.336 13346.855 -1601628.2
60 266.20153 12885.585 -1614519.7 -8441.1641 28485.532 10195.429 -1601634.1
70 259.17085 12545.262 -1614184.2 -11426.993 24941.516 6572.2953 -1601638.9
80 259.73004 12572.33 -1614216.7 -10867.598 16928.461 3033.9021 -1601644.3
90 269.2352 13032.431 -1614679 -7962.3129 4931.5317 -280.22164 -1601646.6
100 280.67181 13586.024 -1615234.3 -3606.1519 -8769.8482 -2527.5887 -1601648.3
Loop time of 358.104 on 1 procs for 100 steps with 16240 atoms
Performance: 0.002 ns/day, 9947.338 hours/ns, 0.279 timesteps/s
99.8% CPU use with 1 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 358.07 | 358.07 | 358.07 | 0.0 | 99.99
Neigh | 0 | 0 | 0 | 0.0 | 0.00
Comm | 0.01623 | 0.01623 | 0.01623 | 0.0 | 0.00
Output | 0.0013328 | 0.0013328 | 0.0013328 | 0.0 | 0.00
Modify | 0.012679 | 0.012679 | 0.012679 | 0.0 | 0.00
Other | | 0.006895 | | | 0.00
Nlocal: 16240 ave 16240 max 16240 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 32428 ave 32428 max 32428 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 6.69975e+06 ave 6.69975e+06 max 6.69975e+06 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 6699752
Ave neighs/atom = 412.546
Neighbor list builds = 0
Dangerous builds = 0
Total wall time: 0:06:02

86
bench/POTENTIALS/log.16Mar18.reax.4
View File

@ -1,86 +0,0 @@
LAMMPS (16 Mar 2018)
OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (../comm.cpp:90)
using 1 OpenMP thread(s) per MPI task
# ReaxFF benchmark: simulation of PETN crystal, replicated unit cell
units real
atom_style charge
read_data data.reax
orthogonal box = (0 0 0) to (9.49107 9.49107 6.99123)
2 by 2 by 1 MPI processor grid
reading atoms ...
58 atoms
#replicate 7 8 10
replicate 7 8 5
orthogonal box = (0 0 0) to (66.4375 75.9285 34.9562)
2 by 2 by 1 MPI processor grid
16240 atoms
Time spent = 0.000491619 secs
velocity all create 300.0 9999
pair_style reax
WARNING: The pair_style reax command is unsupported. Please switch to pair_style reax/c instead (../pair_reax.cpp:49)
pair_coeff * * ffield.reax 1 2 3 4
timestep 0.1
fix 2 all nve
thermo 10
thermo_style custom step temp ke pe pxx pyy pzz etotal
run 100
Neighbor list info ...
update every 1 steps, delay 10 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 12
ghost atom cutoff = 12
binsize = 6, bins = 12 13 6
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair reax, perpetual
attributes: half, newton off
pair build: half/bin/newtoff
stencil: half/bin/3d/newtoff
bin: standard
Per MPI rank memory allocation (min/avg/max) = 35.58 | 35.68 | 35.77 Mbytes
Step Temp KinEng PotEng Pxx Pyy Pzz TotEng
0 300 14521.612 -1616144.1 22296.712 -29858.677 5721.0922 -1601622.5
10 298.98728 14472.591 -1616093.8 21955.847 -24067.094 7389.149 -1601621.3
20 294.76158 14268.044 -1615890 19179.258 -10513.494 10789.925 -1601622
30 288.56967 13968.323 -1615591.2 13854.38 5833.0219 13949.731 -1601622.9
40 282.06725 13653.571 -1615278.2 6259.981 19406.327 14947.938 -1601624.7
50 274.84112 13303.787 -1614931.9 -2009.6844 26964.334 13346.855 -1601628.1
60 266.20153 12885.585 -1614519.8 -8441.1628 28485.533 10195.428 -1601634.2
70 259.17085 12545.262 -1614184.2 -11426.992 24941.517 6572.295 -1601639
80 259.73004 12572.33 -1614216.8 -10867.596 16928.464 3033.9024 -1601644.5
90 269.2352 13032.431 -1614679 -7962.3097 4931.5336 -280.21988 -1601646.5
100 280.67181 13586.024 -1615234.3 -3606.1482 -8769.8463 -2527.5874 -1601648.3
Loop time of 97.054 on 4 procs for 100 steps with 16240 atoms
Performance: 0.009 ns/day, 2695.944 hours/ns, 1.030 timesteps/s
99.0% CPU use with 4 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 94.83 | 95.764 | 96.883 | 9.2 | 98.67
Neigh | 0 | 0 | 0 | 0.0 | 0.00
Comm | 0.16123 | 1.2801 | 2.2132 | 79.9 | 1.32
Output | 0.00056076 | 0.00066662 | 0.00095987 | 0.0 | 0.00
Modify | 0.0048354 | 0.0049006 | 0.0049515 | 0.1 | 0.01
Other | | 0.004639 | | | 0.00
Nlocal: 4060 ave 4080 max 4040 min
Histogram: 2 0 0 0 0 0 0 0 0 2
Nghost: 14972 ave 14992 max 14952 min
Histogram: 2 0 0 0 0 0 0 0 0 2
Neighs: 1.8135e+06 ave 1.82186e+06 max 1.80514e+06 min
Histogram: 2 0 0 0 0 0 0 0 0 2
Total # of neighbors = 7253988
Ave neighs/atom = 446.674
Neighbor list builds = 0
Dangerous builds = 0
Total wall time: 0:01:38

69
bench/POTENTIALS/reax_defs.h
View File

@ -1,69 +0,0 @@
#define PORTABLECOMMENTFLAG
#ifndef PORTABLECOMMENTFLAG
// This is just a way to have portable comments
// for both C++ and FORTRAN preprocessing.
/* ///:EOH~ */
/* */
/* This file contains array dimension parameters for all the main */
/* ReaxFF data structures, some of which need to be directly accessed */
/* by Grasp C++ functions. If they are set too small, the calculation */
/* will run out of allocated memory. If they are set too big, the machine */
/* will not be able to allocate enough memory. */
/* */
/* NNEIGHMAXDEF = Max number of neighbors / NATDEF */
/* NATDEF = Max number of atoms */
/* NATTOTDEF = Max number of global atoms */
/* NSORTDEF = Max number of atom types */
/* MBONDDEF = Max number of bonds connected to one atom */
/* NAVIBDEF = for 2nd derivatives */
/* NBOTYMDEF = Max number of bond types */
/* NVATYMDEF = Max number of valency angle types */
/* NTOTYMDEF = Max number of torsion angle types */
/* NHBTYMDEF = Max number of hydrogen bond types */
/* NODMTYMDEF = Max number of off-diagonal Morse types */
/* NBOALLMAXDEF = Max number of all bonds */
/* NBOMAXDEF = Max number of bonds */
/* NHBMAXDEF = Max number of hydrogen bonds */
/* NVAMAXDEF = Max number of valency angles */
/* NOPMAXDEF = Max number of out of plane angles */
/* NTOMAXDEF = Max number of torsion angles */
/* NPAMAXDEF = Max number of general parameters in force field */
/* NMOLMAXDEF = Max number of molecules in system */
/* NMOLSETDEF = Max number of molecules in training set */
/* MRESTRADEF = Max number of restraints */
/* MTREGDEF = Max number of temperature regimes */
/* MTZONEDEF = Max number of temperature zones */
/* MVREGDEF = Max number of volume regimes */
/* MVZONEDEF = Max number of volume zones */
/* MEREGDEF = Max number of electric field regimes */
/* MEZONEDEF = Max number of electric field zones */
#endif
#define NNEIGHMAXDEF 200
#define NATDEF 50000
#define NATTOTDEF 1
#define NSORTDEF 20
#define MBONDDEF 20
#define NAVIBDEF 50
#define NBOTYMDEF 200
#define NVATYMDEF 200
#define NTOTYMDEF 200
#define NHBTYMDEF 200
#define NODMTYMDEF 20
#define NBOALLMAXDEF 180000
#define NBOMAXDEF 90000
#define NHBMAXDEF 400000
#define NVAMAXDEF 300000
#define NOPMAXDEF 00010
#define NTOMAXDEF 200000
#define NPAMAXDEF 50
#define NMOLMAXDEF 2000
#define NMOLSETDEF 1500
#define MRESTRADEF 100
#define MTREGDEF 100
#define MTZONEDEF 5
#define MVREGDEF 100
#define MVZONEDEF 6
#define MEREGDEF 100
#define MEZONEDEF 3

107
cmake/CMakeLists.txt
View File

@ -32,6 +32,12 @@ endif()
# Cmake modules/macros are in a subdirectory to keep this file cleaner
set(CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/Modules)
# make sure LIBRARY_PATH is set if environment variable is set
if (DEFINED ENV{LIBRARY_PATH})
list(APPEND CMAKE_LIBRARY_PATH "$ENV{LIBRARY_PATH}")
message(STATUS "Appending $ENV{LIBRARY_PATH} to CMAKE_LIBRARY_PATH: ${CMAKE_LIBRARY_PATH}")
endif()
include(LAMMPSUtils)
get_lammps_version(${LAMMPS_SOURCE_DIR}/version.h PROJECT_VERSION)
@ -51,7 +57,6 @@ check_for_autogen_files(${LAMMPS_SOURCE_DIR})
# compiler tests
# these need ot be done early (before further tests).
#####################################################################
include(CheckCCompilerFlag)
include(CheckIncludeFileCXX)
# set required compiler flags and compiler/CPU arch specific optimizations
@ -64,28 +69,11 @@ if(${CMAKE_CXX_COMPILER_ID} STREQUAL "Intel")
endif()
endif()
if(${CMAKE_CXX_COMPILER_ID} STREQUAL "GNU")
set(CMAKE_TUNE_DEFAULT "-march=native")
endif()
if(${CMAKE_CXX_COMPILER_ID} STREQUAL "Clang")
set(CMAKE_TUNE_DEFAULT "-march=native")
endif()
# we require C++11 without extensions
set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)
# GNU compiler specific features for testing
if (${CMAKE_CXX_COMPILER_ID} STREQUAL "GNU")
option(ENABLE_COVERAGE "Enable collecting code coverage data" OFF)
mark_as_advanced(ENABLE_COVERAGE)
if(ENABLE_COVERAGE)
set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} --coverage")
endif()
endif()
########################################################################
# User input options #
########################################################################
@ -116,11 +104,11 @@ install(TARGETS lmp EXPORT LAMMPS_Targets DESTINATION ${CMAKE_INSTALL_BINDIR})
option(CMAKE_VERBOSE_MAKEFILE "Generate verbose Makefiles" OFF)
set(STANDARD_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS DIPOLE
GRANULAR KSPACE LATTE MANYBODY MC MESSAGE MISC MOLECULE PERI POEMS QEQ
REPLICA RIGID SHOCK SPIN SNAP SRD KIM PYTHON MSCG MPIIO VORONOI
GRANULAR KSPACE LATTE MANYBODY MC MESSAGE MISC MLIAP MOLECULE PERI POEMS
QEQ REPLICA RIGID SHOCK SPIN SNAP SRD KIM PYTHON MSCG MPIIO VORONOI
USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-MESODPD USER-CGSDK USER-COLVARS
USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP USER-H5MD USER-LB
USER-MANIFOLD USER-MEAMC USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
USER-MANIFOLD USER-MEAMC USER-MESONT USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
USER-NETCDF USER-PHONON USER-PLUMED USER-PTM USER-QTB USER-REACTION
USER-REAXC USER-SCAFACOS USER-SDPD USER-SMD USER-SMTBQ USER-SPH USER-TALLY
USER-UEF USER-VTK USER-QUIP USER-QMMM USER-YAFF USER-ADIOS)
@ -197,13 +185,14 @@ if(NOT ${LAMMPS_MEMALIGN} STREQUAL "0")
target_compile_definitions(lammps PRIVATE -DLAMMPS_MEMALIGN=${LAMMPS_MEMALIGN})
endif()
option(LAMMPS_EXCEPTIONS "enable the use of C++ exceptions for error messages (useful for library interface)" OFF)
option(LAMMPS_EXCEPTIONS "enable the use of C++ exceptions for error messages (useful for library interface)" ${ENABLE_TESTING})
if(LAMMPS_EXCEPTIONS)
target_compile_definitions(lammps PUBLIC -DLAMMPS_EXCEPTIONS)
endif()
# "hard" dependencies between packages resulting
# in an error instead of skipping over files
pkg_depends(MLIAP SNAP)
pkg_depends(MPIIO MPI)
pkg_depends(USER-ATC MANYBODY)
pkg_depends(USER-LB MPI)
@ -242,6 +231,48 @@ if(BUILD_OMP)
target_link_libraries(lammps PRIVATE OpenMP::OpenMP_CXX)
endif()
# Compiler specific features for testing
if(${CMAKE_CXX_COMPILER_ID} STREQUAL "GNU")
option(ENABLE_COVERAGE "Enable collecting code coverage data" OFF)
mark_as_advanced(ENABLE_COVERAGE)
if(ENABLE_COVERAGE)
if(CMAKE_VERSION VERSION_LESS 3.13)
if(CMAKE_CXX_FLAGS)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} --coverage")
else()
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_${CMAKE_BUILD_TYPE}_FLAGS} --coverage")
endif()
else()
target_compile_options(lammps PUBLIC --coverage)
target_link_options(lammps PUBLIC --coverage)
endif()
endif()
endif()
set(ENABLE_SANITIZER "none" CACHE STRING "Select a code sanitizer option (none (default), address, leak, thread, undefined)")
mark_as_advanced(ENABLE_SANITIZER)
set(ENABLE_SANITIZER_VALUES none address leak thread undefined)
set_property(CACHE ENABLE_SANITIZER PROPERTY STRINGS ${ENABLE_SANITIZER_VALUES})
validate_option(ENABLE_SANITIZER ENABLE_SANITIZER_VALUES)
string(TOLOWER ${ENABLE_SANITIZER} ENABLE_SANITIZER)
if(NOT ENABLE_SANITIZER STREQUAL "none")
if((${CMAKE_CXX_COMPILER_ID} STREQUAL "GNU") OR (${CMAKE_CXX_COMPILER_ID} STREQUAL "Clang"))
if(CMAKE_VERSION VERSION_LESS 3.13)
if(CMAKE_CXX_FLAGS)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=${ENABLE_SANITIZER}")
else()
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_${CMAKE_BUILD_TYPE}_FLAGS} -fsanitize=${ENABLE_SANITIZER}")
endif()
else()
target_compile_options(lammps PUBLIC -fsanitize=${ENABLE_SANITIZER})
target_link_options(lammps PUBLIC -fsanitize=${ENABLE_SANITIZER})
endif()
else()
message(WARNING "ENABLE_SANITIZER option not supported by ${CMAKE_CXX_COMPILER_ID} compilers. Ignoring.")
set(ENABLE_SANITIZER "none")
endif()
endif()
if(PKG_MSCG OR PKG_USER-ATC OR PKG_USER-AWPMD OR PKG_USER-QUIP OR PKG_LATTE)
enable_language(C)
find_package(LAPACK)
@ -327,17 +358,10 @@ foreach(PKG_WITH_INCL KSPACE PYTHON VORONOI USER-COLVARS USER-MOLFILE USER-NETCD
endif()
endforeach()
set(CMAKE_TUNE_FLAGS "${CMAKE_TUNE_DEFAULT}" CACHE STRING "Compiler specific optimization or instrumentation")
set(CMAKE_TUNE_FLAGS "${CMAKE_TUNE_DEFAULT}" CACHE STRING "Compiler and machine specific optimization flags (compilation only)")
separate_arguments(CMAKE_TUNE_FLAGS)
include(CheckCXXCompilerFlag)
foreach(_FLAG ${CMAKE_TUNE_FLAGS})
string(REGEX REPLACE "[=\"]" "" _FLAGX ${_FLAG})
check_cxx_compiler_flag("${_FLAG}" COMPILER_SUPPORTS${_FLAGX})
if(COMPILER_SUPPORTS${_FLAGX})
target_compile_options(lammps PRIVATE ${_FLAG})
else()
message(WARNING "${_FLAG} found in CMAKE_TUNE_FLAGS, but not supported by the compiler, skipping")
endif()
endforeach()
########################################################################
# Basic system tests (standard libraries, headers, functions, types) #
@ -359,6 +383,15 @@ target_link_libraries(lammps PRIVATE ${MATH_LIBRARIES})
include(StyleHeaderUtils)
RegisterStyles(${LAMMPS_SOURCE_DIR})
########################################################
# Fetch missing external files and archives for packages
########################################################
foreach(PKG ${STANDARD_PACKAGES} ${SUFFIX_PACKAGES})
if(PKG_${PKG})
FetchPotentials(${LAMMPS_SOURCE_DIR}/${PKG} ${LAMMPS_POTENTIALS_DIR})
endif()
endforeach()
##############################################
# add sources of enabled packages
############################################
@ -405,13 +438,19 @@ endforeach()
##############################################
# add lib sources of (simple) enabled packages
############################################
foreach(SIMPLE_LIB POEMS USER-ATC USER-AWPMD USER-H5MD)
foreach(SIMPLE_LIB POEMS USER-ATC USER-AWPMD USER-H5MD USER-MESONT)
if(PKG_${SIMPLE_LIB})
string(REGEX REPLACE "^USER-" "" PKG_LIB "${SIMPLE_LIB}")
string(TOLOWER "${PKG_LIB}" PKG_LIB)
if(PKG_LIB STREQUAL mesont)
enable_language(Fortran)
file(GLOB_RECURSE ${PKG_LIB}_SOURCES
${LAMMPS_LIB_SOURCE_DIR}/${PKG_LIB}/[^.]*.f90)
else()
file(GLOB_RECURSE ${PKG_LIB}_SOURCES
${LAMMPS_LIB_SOURCE_DIR}/${PKG_LIB}/[^.]*.c
${LAMMPS_LIB_SOURCE_DIR}/${PKG_LIB}/[^.]*.cpp)
endif()
add_library(${PKG_LIB} STATIC ${${PKG_LIB}_SOURCES})
set_target_properties(${PKG_LIB} PROPERTIES OUTPUT_NAME lammps_${PKG_LIB}${LAMMPS_MACHINE})
target_link_libraries(lammps PRIVATE ${PKG_LIB})
@ -610,6 +649,8 @@ install(
###############################################################################
if(BUILD_SHARED_LIBS)
if(CMAKE_VERSION VERSION_LESS 3.12)
# adjust so we find Python 3 versions before Python 2 on old systems with old CMake
set(Python_ADDITIONAL_VERSIONS 3.8 3.7 3.6 3.5)
find_package(PythonInterp) # Deprecated since version 3.12
if(PYTHONINTERP_FOUND)
set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
@ -661,6 +702,7 @@ endif()
include(Testing)
include(CodeCoverage)
include(CodingStandard)
###############################################################################
# Print package summary
@ -765,3 +807,6 @@ if(PKG_KSPACE)
endif()
endif()
endif()
if(BUILD_DOC)
message(STATUS "<<< Building HTML Manual >>>")
endif()

34
cmake/Modules/CodingStandard.cmake Normal file
View File

@ -0,0 +1,34 @@
if(CMAKE_VERSION VERSION_LESS 3.12)
find_package(PythonInterp 3.5 QUIET) # Deprecated since version 3.12
if(PYTHONINTERP_FOUND)
set(Python3_EXECUTABLE ${PYTHON_EXECUTABLE})
set(Python3_VERSION ${PYTHON_VERSION_STRING})
endif()
else()
find_package(Python3 COMPONENTS Interpreter QUIET)
endif()
if (Python3_EXECUTABLE)
if(Python3_VERSION VERSION_GREATER_EQUAL 3.5)
add_custom_target(
check-whitespace
${Python3_EXECUTABLE} ${LAMMPS_TOOLS_DIR}/coding_standard/whitespace.py .
WORKING_DIRECTORY ${LAMMPS_DIR}
COMMENT "Check for whitespace errors")
add_custom_target(
check-permissions
${Python3_EXECUTABLE} ${LAMMPS_TOOLS_DIR}/coding_standard/permissions.py .
WORKING_DIRECTORY ${LAMMPS_DIR}
COMMENT "Check for permission errors")
add_custom_target(
fix-whitespace
${Python3_EXECUTABLE} ${LAMMPS_TOOLS_DIR}/coding_standard/whitespace.py -f .
WORKING_DIRECTORY ${LAMMPS_DIR}
COMMENT "Fix whitespace errors")
add_custom_target(
fix-permissions
${Python3_EXECUTABLE} ${LAMMPS_TOOLS_DIR}/coding_standard/permissions.py -f .
WORKING_DIRECTORY ${LAMMPS_DIR}
COMMENT "Fix permission errors")
endif()
endif()

31
cmake/Modules/Documentation.cmake
View File

@ -2,10 +2,19 @@
# Build documentation
###############################################################################
option(BUILD_DOC "Build LAMMPS HTML documentation" OFF)
if(BUILD_DOC)
find_package(PythonInterp 3 REQUIRED)
set(VIRTUALENV ${PYTHON_EXECUTABLE} -m virtualenv)
if(BUILD_DOC)
# Sphinx 3.x requires at least Python 3.5
if(CMAKE_VERSION VERSION_LESS 3.12)
find_package(PythonInterp 3.5 REQUIRED)
set(VIRTUALENV ${PYTHON_EXECUTABLE} -m virtualenv -p ${PYTHON_EXECUTABLE})
else()
find_package(Python3 REQUIRED COMPONENTS Interpreter)
if(Python3_VERSION VERSION_LESS 3.5)
message(FATAL_ERROR "Python 3.5 and up is required to build the HTML documentation")
endif()
set(VIRTUALENV ${Python3_EXECUTABLE} -m virtualenv -p ${Python3_EXECUTABLE})
endif()
file(GLOB DOC_SOURCES ${LAMMPS_DOC_DIR}/src/[^.]*.rst)
@ -25,11 +34,10 @@ if(BUILD_DOC)
)
# download mathjax distribution and unpack to folder "mathjax"
if(NOT EXISTS ${CMAKE_CURRENT_BINARY_DIR}/mathjax/es5)
file(DOWNLOAD "https://github.com/mathjax/MathJax/archive/3.0.5.tar.gz"
"${CMAKE_CURRENT_BINARY_DIR}/mathjax.tar.gz"
EXPECTED_MD5 5d9d3799cce77a1a95eee6be04eb68e7)
if(NOT EXISTS ${CMAKE_CURRENT_BINARY_DIR}/mathjax)
execute_process(COMMAND ${CMAKE_COMMAND} -E tar xzf mathjax.tar.gz WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR})
file(GLOB MATHJAX_VERSION_DIR ${CMAKE_CURRENT_BINARY_DIR}/MathJax-*)
execute_process(COMMAND ${CMAKE_COMMAND} -E rename ${MATHJAX_VERSION_DIR} ${CMAKE_CURRENT_BINARY_DIR}/mathjax)
@ -37,11 +45,18 @@ if(BUILD_DOC)
file(MAKE_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/html/_static/mathjax)
file(COPY ${CMAKE_CURRENT_BINARY_DIR}/mathjax/es5 DESTINATION ${CMAKE_CURRENT_BINARY_DIR}/html/_static/mathjax/)
# for increased browser compatibility
if(NOT EXISTS ${CMAKE_CURRENT_BINARY_DIR}/html/_static/polyfill.js)
file(DOWNLOAD "https://polyfill.io/v3/polyfill.min.js?features=es6"
"${CMAKE_CURRENT_BINARY_DIR}/html/_static/polyfill.js")
endif()
# note, this may run in parallel with other tasks, so we must not use multiple processes here
add_custom_command(
OUTPUT html
DEPENDS ${DOC_SOURCES} docenv requirements.txt
COMMAND ${DOCENV_BINARY_DIR}/sphinx-build -b html -c ${LAMMPS_DOC_DIR}/utils/sphinx-config -d ${CMAKE_BINARY_DIR}/doctrees ${LAMMPS_DOC_DIR}/src html
COMMAND ${CMAKE_COMMAND} -E create_symlink Manual.html ${CMAKE_CURRENT_BINARY_DIR}/html/index.html
)
# copy selected image files to html output tree
@ -56,17 +71,17 @@ if(BUILD_DOC)
set(HTML_IMAGE_TARGETS "")
foreach(_IMG ${HTML_EXTRA_IMAGES})
string(PREPEND _IMG JPG/)
list(APPEND HTML_IMAGE_TARGETS "html/${_IMG}")
list(APPEND HTML_IMAGE_TARGETS "${CMAKE_CURRENT_BINARY_DIR}/html/${_IMG}")
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/html/${_IMG}
DEPENDS ${LAMMPS_DOC_DIR}/src/${_IMG} html/JPG
DEPENDS ${LAMMPS_DOC_DIR}/src/${_IMG} ${CMAKE_CURRENT_BINARY_DIR}/html/JPG
COMMAND ${CMAKE_COMMAND} -E copy ${LAMMPS_DOC_DIR}/src/${_IMG} ${CMAKE_BINARY_DIR}/html/${_IMG}
)
endforeach()
add_custom_target(
doc ALL
DEPENDS html html/_static/mathjax/es5 ${HTML_IMAGE_TARGETS}
DEPENDS html ${CMAKE_CURRENT_BINARY_DIR}/html/_static/mathjax/es5 ${HTML_IMAGE_TARGETS}
SOURCES ${LAMMPS_DOC_DIR}/utils/requirements.txt ${DOC_SOURCES}
)

46
cmake/Modules/FindClangFormat.cmake Normal file
View File

@ -0,0 +1,46 @@
# Find clang-format
find_program(ClangFormat_EXECUTABLE NAMES clang-format
clang-format-10.0
clang-format-9.0
clang-format-8.0
clang-format-7.0
clang-format-6.0
DOC "clang-format executable")
mark_as_advanced(ClangFormat_EXECUTABLE)
if(ClangFormat_EXECUTABLE)
# find version
execute_process(COMMAND ${ClangFormat_EXECUTABLE} --version
OUTPUT_VARIABLE clang_format_version
ERROR_QUIET OUTPUT_STRIP_TRAILING_WHITESPACE)
if(clang_format_version MATCHES "^clang-format version .*")
# Arch Linux
# clang-format version 10.0.0
# Ubuntu 18.04 LTS Output
# clang-format version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
string(REGEX REPLACE "clang-format version ([0-9.]+).*"
"\\1"
ClangFormat_VERSION
"${clang_format_version}")
elseif(clang_format_version MATCHES ".*LLVM version .*")
# CentOS 7 Output
# LLVM (http://llvm.org/):
# LLVM version 3.4.2
# Optimized build.
# Built Nov 1 2018 (15:06:24).
# Default target: x86_64-redhat-linux-gnu
# Host CPU: x86-64
string(REGEX REPLACE ".*LLVM version ([0-9.]+).*"
"\\1"
ClangFormat_VERSION
"${clang_format_version}")
else()
set(ClangFormat_VERSION "0.0")
endif()
endif()
include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(ClangFormat REQUIRED_VARS ClangFormat_EXECUTABLE VERSION_VAR ClangFormat_VERSION)

23
cmake/Modules/LAMMPSUtils.cmake
View File

@ -85,3 +85,26 @@ function(GenerateBinaryHeader varname outfile files)
file(APPEND ${outfile} "const unsigned int ${varname}_size = sizeof(${varname});\n")
endforeach()
endfunction(GenerateBinaryHeader)
# fetch missing potential files
function(FetchPotentials pkgfolder potfolder)
if (EXISTS "${pkgfolder}/potentials.txt")
set(LAMMPS_POTENTIALS_URL "https://download.lammps.org/potentials")
file(STRINGS "${pkgfolder}/potentials.txt" linelist REGEX "^[^#].")
foreach(line ${linelist})
string(FIND ${line} " " blank)
math(EXPR plusone "${blank}+1")
string(SUBSTRING ${line} 0 ${blank} pot)
string(SUBSTRING ${line} ${plusone} -1 sum)
if(EXISTS ${LAMMPS_POTENTIALS_DIR}/${pot})
file(MD5 "${LAMMPS_POTENTIALS_DIR}/${pot}" oldsum)
endif()
if(NOT sum STREQUAL oldsum)
message(STATUS "Checking external potential ${pot} from ${LAMMPS_POTENTIALS_URL}")
file(DOWNLOAD "${LAMMPS_POTENTIALS_URL}/${pot}.${sum}" "${CMAKE_BINARY_DIR}/${pot}"
EXPECTED_HASH MD5=${sum} SHOW_PROGRESS)
file(COPY "${CMAKE_BINARY_DIR}/${pot}" DESTINATION ${LAMMPS_POTENTIALS_DIR})
endif()
endforeach()
endif()
endfunction(FetchPotentials)

74
cmake/Modules/Packages/GPU.cmake
View File

@ -40,6 +40,17 @@ if(GPU_API STREQUAL "CUDA")
set(GPU_ARCH "sm_50" CACHE STRING "LAMMPS GPU CUDA SM primary architecture (e.g. sm_60)")
# ensure that no *cubin.h files exist from a compile in the lib/gpu folder
file(GLOB GPU_LIB_OLD_CUBIN_HEADERS ${LAMMPS_LIB_SOURCE_DIR}/gpu/*_cubin.h)
if (GPU_LIB_OLD_CUBIN_HEADERS)
message(FATAL_ERROR "########################################################################\n"
"Found file(s) generated by the make-based build system in lib/gpu\n"
"Please run\n"
" make -C ${LAMMPS_LIB_SOURCE_DIR}/gpu -f Makefile.serial clean\n"
"to remove\n"
"########################################################################")
endif()
file(GLOB GPU_LIB_CU ${LAMMPS_LIB_SOURCE_DIR}/gpu/[^.]*.cu ${CMAKE_CURRENT_SOURCE_DIR}/gpu/[^.]*.cu)
list(REMOVE_ITEM GPU_LIB_CU ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_pppm.cu)
@ -55,31 +66,42 @@ if(GPU_API STREQUAL "CUDA")
# --arch translates directly instead of JIT, so this should be for the preferred or most common architecture
set(GPU_CUDA_GENCODE "-arch=${GPU_ARCH}")
# Fermi (GPU Arch 2.x) is supported by CUDA 3.2 to CUDA 8.0
if((CUDA_VERSION VERSION_GREATER "3.1") AND (CUDA_VERSION VERSION_LESS "9.0"))
if((CUDA_VERSION VERSION_GREATER_EQUAL "3.2") AND (CUDA_VERSION VERSION_LESS "9.0"))
string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_20,code=[sm_20,compute_20] ")
endif()
# Kepler (GPU Arch 3.x) is supported by CUDA 5 and later
if(CUDA_VERSION VERSION_GREATER "4.9")
# Kepler (GPU Arch 3.0) is supported by CUDA 5 to CUDA 10.2
if((CUDA_VERSION VERSION_GREATER_EQUAL "5.0") AND (CUDA_VERSION VERSION_LESS "11.0"))
string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_30,code=[sm_30,compute_30] ")
endif()
# Kepler (GPU Arch 3.5) is supported by CUDA 5 to CUDA 11
if((CUDA_VERSION VERSION_GREATER_EQUAL "5.0") AND (CUDA_VERSION VERSION_LESS "12.0"))
string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_30,code=[sm_30,compute_30] -gencode arch=compute_35,code=[sm_35,compute_35]")
endif()
# Maxwell (GPU Arch 5.x) is supported by CUDA 6 and later
if(CUDA_VERSION VERSION_GREATER "5.9")
if(CUDA_VERSION VERSION_GREATER_EQUAL "6.0")
string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_50,code=[sm_50,compute_50] -gencode arch=compute_52,code=[sm_52,compute_52]")
endif()
# Pascal (GPU Arch 6.x) is supported by CUDA 8 and later
if(CUDA_VERSION VERSION_GREATER "7.9")
if(CUDA_VERSION VERSION_GREATER_EQUAL "8.0")
string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_60,code=[sm_60,compute_60] -gencode arch=compute_61,code=[sm_61,compute_61]")
endif()
# Volta (GPU Arch 7.0) is supported by CUDA 9 and later
if(CUDA_VERSION VERSION_GREATER "8.9")
if(CUDA_VERSION VERSION_GREATER_EQUAL "9.0")
string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_70,code=[sm_70,compute_70]")
endif()
# Turing (GPU Arch 7.5) is supported by CUDA 10 and later
if(CUDA_VERSION VERSION_GREATER "9.9")
if(CUDA_VERSION VERSION_GREATER_EQUAL "10.0")
string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_75,code=[sm_75,compute_75]")
endif()
# Ampere (GPU Arch 8.0) is supported by CUDA 11 and later
if(CUDA_VERSION VERSION_GREATER_EQUAL "11.0")
string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_80,code=[sm_80,compute_80]")
endif()
if(CUDA_VERSION VERSION_GREATER_EQUAL "12.0")
message(WARNING "Unsupported CUDA version. Use at your own risk.")
endif()
cuda_compile_fatbin(GPU_GEN_OBJS ${GPU_LIB_CU} OPTIONS
cuda_compile_fatbin(GPU_GEN_OBJS ${GPU_LIB_CU} OPTIONS ${CUDA_REQUEST_PIC}
-DUNIX -O3 --use_fast_math -Wno-deprecated-gpu-targets -DNV_KERNEL -DUCL_CUDADR ${GPU_CUDA_GENCODE} -D_${GPU_PREC_SETTING})
cuda_compile(GPU_OBJS ${GPU_LIB_CUDPP_CU} OPTIONS ${CUDA_REQUEST_PIC}
@ -115,7 +137,7 @@ if(GPU_API STREQUAL "CUDA")
elseif(GPU_API STREQUAL "OPENCL")
if(${CMAKE_SYSTEM_NAME} STREQUAL "Windows")
# download and unpack support binaries for compilation of windows binaries.
set(LAMMPS_THIRDPARTY_URL "http://download.lammps.org/thirdparty")
set(LAMMPS_THIRDPARTY_URL "https://download.lammps.org/thirdparty")
file(DOWNLOAD "${LAMMPS_THIRDPARTY_URL}/opencl-win-devel.tar.gz" "${CMAKE_CURRENT_BINARY_DIR}/opencl-win-devel.tar.gz"
EXPECTED_MD5 2c00364888d5671195598b44c2e0d44d)
execute_process(COMMAND ${CMAKE_COMMAND} -E tar xzf opencl-win-devel.tar.gz WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR})
@ -217,29 +239,40 @@ elseif(GPU_API STREQUAL "HIP")
# --arch translates directly instead of JIT, so this should be for the preferred or most common architecture
set(HIP_CUDA_GENCODE "-arch=${HIP_ARCH}")
# Fermi (GPU Arch 2.x) is supported by CUDA 3.2 to CUDA 8.0
if((CUDA_VERSION VERSION_GREATER "3.1") AND (CUDA_VERSION VERSION_LESS "9.0"))
if((CUDA_VERSION VERSION_GREATER_EQUAL "3.2") AND (CUDA_VERSION VERSION_LESS "9.0"))
string(APPEND HIP_CUDA_GENCODE " -gencode arch=compute_20,code=[sm_20,compute_20]")
endif()
# Kepler (GPU Arch 3.x) is supported by CUDA 5 and later
if(CUDA_VERSION VERSION_GREATER "4.9")
string(APPEND HIP_CUDA_GENCODE "-gencode arch=compute_30,code=[sm_30,compute_30] -gencode arch=compute_35,code=[sm_35,compute_35] ")
# Kepler (GPU Arch 3.0) is supported by CUDA 5 to CUDA 10.2
if((CUDA_VERSION VERSION_GREATER_EQUAL "5.0") AND (CUDA_VERSION VERSION_LESS "11.0"))
string(APPEND HIP_CUDA_GENCODE " -gencode arch=compute_30,code=[sm_30,compute_30]")
endif()
# Kepler (GPU Arch 3.5) is supported by CUDA 5 to CUDA 11.0
if((CUDA_VERSION VERSION_GREATER_EQUAL "5.0") AND (CUDA_VERSION VERSION_LESS "12.0"))
string(APPEND HIP_CUDA_GENCODE " -gencode arch=compute_35,code=[sm_35,compute_35]")
endif()
# Maxwell (GPU Arch 5.x) is supported by CUDA 6 and later
if(CUDA_VERSION VERSION_GREATER "5.9")
if(CUDA_VERSION VERSION_GREATER_EQUAL "6.0")
string(APPEND HIP_CUDA_GENCODE " -gencode arch=compute_50,code=[sm_50,compute_50] -gencode arch=compute_52,code=[sm_52,compute_52]")
endif()
# Pascal (GPU Arch 6.x) is supported by CUDA 8 and later
if(CUDA_VERSION VERSION_GREATER "7.9")
if(CUDA_VERSION VERSION_GREATER_EQUAL "8.0")
string(APPEND HIP_CUDA_GENCODE " -gencode arch=compute_60,code=[sm_60,compute_60] -gencode arch=compute_61,code=[sm_61,compute_61]")
endif()
# Volta (GPU Arch 7.0) is supported by CUDA 9 and later
if(CUDA_VERSION VERSION_GREATER "8.9")
if(CUDA_VERSION VERSION_GREATER_EQUAL "9.0")
string(APPEND HIP_CUDA_GENCODE " -gencode arch=compute_70,code=[sm_70,compute_70]")
endif()
# Turing (GPU Arch 7.5) is supported by CUDA 10 and later
if(CUDA_VERSION VERSION_GREATER "9.9")
if(CUDA_VERSION VERSION_GREATER_EQUAL "10.0")
string(APPEND HIP_CUDA_GENCODE " -gencode arch=compute_75,code=[sm_75,compute_75]")
endif()
# Ampere (GPU Arch 8.0) is supported by CUDA 11 and later
if(CUDA_VERSION VERSION_GREATER_EQUAL "11.0")
string(APPEND HIP_CUDA_GENCODE " -gencode arch=compute_80,code=[sm_80,compute_80]")
endif()
if(CUDA_VERSION VERSION_GREATER_EQUAL "12.0")
message(WARNING "Unsupported CUDA version. Use at your own risk.")
endif()
endif()
file(GLOB GPU_LIB_CU ${LAMMPS_LIB_SOURCE_DIR}/gpu/[^.]*.cu ${CMAKE_CURRENT_SOURCE_DIR}/gpu/[^.]*.cu)
@ -257,10 +290,17 @@ elseif(GPU_API STREQUAL "HIP")
if(HIP_PLATFORM STREQUAL "hcc")
configure_file(${CU_FILE} ${CU_CPP_FILE} COPYONLY)
if(HIP_COMPILER STREQUAL "clang")
add_custom_command(OUTPUT ${CUBIN_FILE}
VERBATIM COMMAND ${HIP_HIPCC_EXECUTABLE} --genco --offload-arch=${HIP_ARCH} -O3 -ffast-math -DUSE_HIP -D_${GPU_PREC_SETTING} -I${LAMMPS_LIB_SOURCE_DIR}/gpu -o ${CUBIN_FILE} ${CU_CPP_FILE}
DEPENDS ${CU_CPP_FILE}
COMMENT "Generating ${CU_NAME}.cubin")
else()
add_custom_command(OUTPUT ${CUBIN_FILE}
VERBATIM COMMAND ${HIP_HIPCC_EXECUTABLE} --genco -t="${HIP_ARCH}" -f=\"-O3 -ffast-math -DUSE_HIP -D_${GPU_PREC_SETTING} -I${LAMMPS_LIB_SOURCE_DIR}/gpu\" -o ${CUBIN_FILE} ${CU_CPP_FILE}
DEPENDS ${CU_CPP_FILE}
COMMENT "Generating ${CU_NAME}.cubin")
endif()
elseif(HIP_PLATFORM STREQUAL "nvcc")
add_custom_command(OUTPUT ${CUBIN_FILE}
VERBATIM COMMAND ${HIP_HIPCC_EXECUTABLE} --fatbin --use_fast_math -DUSE_HIP -D_${GPU_PREC_SETTING} ${HIP_CUDA_GENCODE} -I${LAMMPS_LIB_SOURCE_DIR}/gpu -o ${CUBIN_FILE} ${CU_FILE}

6
cmake/Modules/Packages/USER-SCAFACOS.cmake
View File

@ -14,10 +14,16 @@ endif()
option(DOWNLOAD_SCAFACOS "Download ScaFaCoS library instead of using an already installed one" ${DOWNLOAD_SCAFACOS_DEFAULT})
if(DOWNLOAD_SCAFACOS)
message(STATUS "ScaFaCoS download requested - we will build our own")
# version 1.0.1 needs a patch to compile and linke cleanly with GCC 10 and later.
file(DOWNLOAD https://download.lammps.org/thirdparty/scafacos-1.0.1-fix.diff ${CMAKE_CURRENT_BINARY_DIR}/scafacos-1.0.1.fix.diff
EXPECTED_HASH MD5=4baa1333bb28fcce102d505e1992d032)
include(ExternalProject)
ExternalProject_Add(scafacos_build
URL https://github.com/scafacos/scafacos/releases/download/v1.0.1/scafacos-1.0.1.tar.gz
URL_MD5 bd46d74e3296bd8a444d731bb10c1738
PATCH_COMMAND patch -p1 < ${CMAKE_CURRENT_BINARY_DIR}/scafacos-1.0.1.fix.diff
CONFIGURE_COMMAND <SOURCE_DIR>/configure --prefix=<INSTALL_DIR> --disable-doc
--enable-fcs-solvers=fmm,p2nfft,direct,ewald,p3m
--with-internal-fftw --with-internal-pfft

2
cmake/Modules/Packages/USER-SMD.cmake
View File

@ -9,7 +9,7 @@ if(DOWNLOAD_EIGEN3)
message(STATUS "Eigen3 download requested - we will build our own")
include(ExternalProject)
ExternalProject_Add(Eigen3_build
URL http://bitbucket.org/eigen/eigen/get/3.3.7.tar.gz
URL https://bitbucket.org/eigen/eigen/get/3.3.7.tar.gz
URL_MD5 f2a417d083fe8ca4b8ed2bc613d20f07
CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
)

15
cmake/Modules/Testing.cmake
View File

@ -3,6 +3,21 @@
###############################################################################
option(ENABLE_TESTING "Enable testing" OFF)
if(ENABLE_TESTING)
find_program(VALGRIND_BINARY NAMES valgrind)
# generate custom suppression file
file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/lammps.supp "\n")
file(GLOB VALGRIND_SUPPRESSION_FILES ${LAMMPS_TOOLS_DIR}/valgrind/[^.]*.supp)
foreach(SUPP ${VALGRIND_SUPPRESSION_FILES})
file(READ ${SUPP} SUPPRESSIONS)
file(APPEND ${CMAKE_CURRENT_BINARY_DIR}/lammps.supp "${SUPPRESSIONS}")
endforeach()
set(VALGRIND_DEFAULT_OPTIONS "--leak-check=full --show-leak-kinds=all --track-origins=yes --suppressions=${CMAKE_BINARY_DIR}/lammps.supp")
set(MEMORYCHECK_COMMAND "${VALGRIND_BINARY}" CACHE FILEPATH "Memory Check Command")
set(MEMORYCHECK_COMMAND_OPTIONS "${VALGRIND_DEFAULT_OPTIONS}" CACHE STRING "Memory Check Command Options")
include(CTest)
enable_testing()
get_filename_component(LAMMPS_UNITTEST_DIR ${LAMMPS_SOURCE_DIR}/../unittest ABSOLUTE)
get_filename_component(LAMMPS_UNITTEST_BIN ${CMAKE_BINARY_DIR}/unittest ABSOLUTE)

2
cmake/presets/all_off.cmake
View File

@ -8,7 +8,7 @@ set(ALL_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
USER-ADIOS USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK
USER-COLVARS USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP
USER-H5MD USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESODPD
USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE USER-NETCDF USER-OMP
USER-MESONT USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE USER-NETCDF USER-OMP
USER-PHONON USER-PLUMED USER-PTM USER-QMMM USER-QTB USER-QUIP
USER-REACTION USER-REAXC USER-SCAFACOS USER-SDPD USER-SMD USER-SMTBQ
USER-SPH USER-TALLY USER-UEF USER-VTK USER-YAFF)

2
cmake/presets/all_on.cmake
View File

@ -10,7 +10,7 @@ set(ALL_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
USER-ADIOS USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK
USER-COLVARS USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP
USER-H5MD USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESODPD
USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE USER-NETCDF USER-OMP
USER-MESONT USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE USER-NETCDF USER-OMP
USER-PHONON USER-PLUMED USER-PTM USER-QMMM USER-QTB USER-QUIP
USER-REACTION USER-REAXC USER-SCAFACOS USER-SDPD USER-SMD USER-SMTBQ
USER-SPH USER-TALLY USER-UEF USER-VTK USER-YAFF)

17
cmake/presets/download.cmake Normal file
View File

@ -0,0 +1,17 @@
# preset that turns on packages with automatic downloads of sources of potentials
# compilation of libraries like Plumed or ScaFaCoS can take a considerable amount of time.
set(ALL_PACKAGES KIM LATTE MSCG VORONOI USER-PLUMED USER-SCAFACOS USER-SMD USER-MESONT)
foreach(PKG ${ALL_PACKAGES})
set(PKG_${PKG} ON CACHE BOOL "" FORCE)
endforeach()
set(DOWNLOAD_KIM ON CACHE BOOL "" FORCE)
set(DOWNLOAD_LATTE ON CACHE BOOL "" FORCE)
set(DOWNLOAD_MSCG ON CACHE BOOL "" FORCE)
set(DOWNLOAD_VORO ON CACHE BOOL "" FORCE)
set(DOWNLOAD_EIGEN3 ON CACHE BOOL "" FORCE)
set(DOWNLOAD_PLUMED ON CACHE BOOL "" FORCE)
set(DOWNLOAD_SCAFACOS ON CACHE BOOL "" FORCE)

6
cmake/presets/mingw-cross.cmake
View File

@ -1,10 +1,10 @@
set(WIN_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
GRANULAR KSPACE LATTE MANYBODY MC MISC MOLECULE OPT PERI
POEMS QEQ REPLICA RIGID SHOCK SNAP SPIN SRD VORONOI
GRANULAR KSPACE LATTE MANYBODY MC MISC MLIAP MOLECULE OPT
PERI POEMS QEQ REPLICA RIGID SHOCK SNAP SPIN SRD VORONOI
USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK
USER-COLVARS USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF
USER-FEP USER-INTEL USER-MANIFOLD USER-MEAMC USER-MESODPD
USER-MISC USER-MGPT USER-MOFFF USER-MOLFILE USER-OMP
USER-MESONT USER-MISC USER-MGPT USER-MOFFF USER-MOLFILE USER-OMP
USER-PHONON USER-PTM USER-QTB USER-REACTION USER-REAXC
USER-SDPD USER-SMD USER-SMTBQ USER-SPH USER-TALLY USER-UEF
USER-YAFF)

4
cmake/presets/most.cmake
View File

@ -2,8 +2,8 @@
# external libraries. Compared to all_on.cmake some more unusual packages
# are removed. The resulting binary should be able to run most inputs.
set(ALL_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL
DIPOLE GRANULAR KSPACE MANYBODY MC MISC MOLECULE OPT PERI
set(ALL_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE
GRANULAR KSPACE MANYBODY MC MISC MLIAP MOLECULE OPT PERI
POEMS PYTHON QEQ REPLICA RIGID SHOCK SNAP SPIN SRD VORONOI
USER-BOCS USER-CGDNA USER-CGSDK USER-COLVARS USER-DIFFRACTION
USER-DPD USER-DRUDE USER-EFF USER-FEP USER-MEAMC USER-MESODPD

2
cmake/presets/nolib.cmake
View File

@ -3,7 +3,7 @@
set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MPIIO MSCG PYTHON
VORONOI USER-ADIOS USER-ATC USER-AWPMD USER-H5MD USER-LB
USER-MOLFILE USER-NETCDF USER-PLUMED USER-QMMM USER-QUIP
USER-MOLFILE USER-MESONT USER-NETCDF USER-PLUMED USER-QMMM USER-QUIP
USER-SCAFACOS USER-SMD USER-VTK)
foreach(PKG ${PACKAGES_WITH_LIB})

2
doc/lammps.1
View File

@ -1,4 +1,4 @@
.TH LAMMPS "2 June 2020" "2020-06-02"
.TH LAMMPS "30 June 2020" "2020-06-30"
.SH NAME
.B LAMMPS
\- Molecular Dynamics Simulator.

0
doc/src/99/crib.html Executable file → Normal file
View File

46
doc/src/Build_basics.rst
View File

@ -193,14 +193,17 @@ compiler and any :doc:`accelerator packages <Speed_packages>` you have
included in the build.
You can tell CMake to look for a specific compiler with setting CMake
variable during configuration. For a few common choices, there are also
presets in the ``cmake/presets`` folder. For convenience, there is a
``CMAKE_TUNE_FLAGS`` variable that can be set to apply global compiler
options. More on that below, but you can also specify the corresponding
``CMAKE_*_FLAGS`` variables individually if you want to experiment with
alternate optimization flags. You should specify all 3 compilers, so
that the (few) LAMMPS source files written in C or Fortran are built
with a compiler consistent with the one used for the C++ files:
variables (listed below) during configuration. For a few common
choices, there are also presets in the ``cmake/presets`` folder. For
convenience, there is a ``CMAKE_TUNE_FLAGS`` variable that can be set to
apply global compiler options (applied to compilation only), to be used
for adding compiler or host specific optimization flags in addition to
the "flags" variables listed below. You may also specify the
corresponding ``CMAKE_*_FLAGS`` variables individually, if you want to
experiment with alternate optimization flags. You should specify all 3
compilers, so that the (few) LAMMPS source files written in C or Fortran
are built with a compiler consistent with the one used for the C++
files:
.. code-block:: bash
@ -229,11 +232,7 @@ can be loaded with `-C ../cmake/presets/clang.cmake`. Similarly,
In addition you can set ``CMAKE_TUNE_FLAGS`` to specifically add
compiler flags to tune for optimal performance on given hosts. By
default these are initialized to some compiler specific flags, to
optimize the LAMMPS executable with optimizations and instructions
available on the host where LAMMPS is compiled. For example, for Intel
compilers this would be ``-xHost`` and for GNU compilers this would be
``-march=native``. To turn these flags off, do ``-D CMAKE_TUNE_FLAGS=``.
default this variable is empty.
.. note::
@ -372,7 +371,8 @@ it. The build step will also create generic soft links, named
``liblammps.a`` and ``liblammps.so``\ , which point to the specific
``liblammps_machine.a/so`` files.
**CMake and make info**\ :
CMake and make info
^^^^^^^^^^^^^^^^^^^
Note that for creating a shared library, all the libraries it depends on
must be compiled to be compatible with shared libraries. This should be
@ -462,7 +462,8 @@ tool. The actual translation is then done via make commands.
.. _rst: https://docutils.readthedocs.io/en/sphinx-docs/user/rst/quickstart.html
.. _sphinx: https://sphinx-doc.org
**Documentation make option**\ :
Documentation make option
^^^^^^^^^^^^^^^^^^^^^^^^^
The following make commands can be issued in the doc folder of the
LAMMPS source distribution.
@ -489,7 +490,8 @@ your system.
current LAMMPS version (HTML and PDF files), from the website
`download page <https://lammps.sandia.gov/download.html>`_.
**CMake build option**\ :
CMake build option
^^^^^^^^^^^^^^^^^^
It is also possible to create the HTML version of the manual within
the :doc:`CMake build directory <Build_cmake>`. The reason for this
@ -512,7 +514,8 @@ Build LAMMPS tools
Some tools described in :doc:`Auxiliary tools <Tools>` can be built directly
using CMake or Make.
**CMake build3**\ :
CMake build
^^^^^^^^^^^
.. code-block:: bash
@ -521,7 +524,8 @@ using CMake or Make.
The generated binaries will also become part of the LAMMPS installation
(see below).
**Traditional make**\ :
Traditional make
^^^^^^^^^^^^^^^^
.. code-block:: bash
@ -545,7 +549,8 @@ a globally visible place on your system, for others to access. Note
that you may need super-user privileges (e.g. sudo) if the directory
you want to copy files to is protected.
**CMake build**\ :
CMake build
^^^^^^^^^^^
.. code-block:: bash
@ -553,7 +558,8 @@ you want to copy files to is protected.
make # perform make after CMake command
make install # perform the installation into prefix
**Traditional make**\ :
Traditional make
^^^^^^^^^^^^^^^^
There is no "install" option in the ``src/Makefile`` for LAMMPS. If
you wish to do this you will need to first build LAMMPS, then manually

99
doc/src/Build_development.rst
View File

@ -8,8 +8,8 @@ useful during development, testing or debugging.
.. _compilation:
Verify compilation flags
------------------------
Monitor compilation flags
-------------------------
Sometimes it is necessary to verify the complete sequence of compilation flags
generated by the CMake build. To enable a more verbose output during
@ -19,7 +19,8 @@ compilation you can use the following option.
-D CMAKE_VERBOSE_MAKEFILE=value # value = no (default) or yes
Another way of doing this without reconfiguration is calling make with variable VERBOSE set to 1:
Another way of doing this without reconfiguration is calling make with
variable VERBOSE set to 1:
.. code-block:: bash
@ -33,25 +34,27 @@ Address, Undefined Behavior, and Thread Sanitizer Support
---------------------------------------------------------
Compilers such as GCC and Clang support generating instrumented binaries
which use different sanitizer libraries to detect problems in code
which use different sanitizer libraries to detect problems in the code
during run-time. They can detect issues like:
- `memory leaks <https://clang.llvm.org/docs/AddressSanitizer.html>`_
- `undefined behavior <https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html>`_
- `data races <https://clang.llvm.org/docs/ThreadSanitizer.html>`_
Please note that this kind of instrumentation usually comes with a small
performance hit (much less than using tools like `Valgrind
<https://valgrind.org>`_). The to enable these features additional
compiler flags need to be added to the compilation and linking stages.
This is most easily done through setting the ``CMAKE_TUNE_FLAGS``
variable during configuration. Examples:
Please note that this kind of instrumentation usually comes with a
performance hit (but much less than using tools like `Valgrind
<https://valgrind.org>`_ with a more low level approach). The to enable
these features additional compiler flags need to be added to the
compilation and linking stages. This is done through setting the
``ENABLE_SANITIZER`` variable during configuration. Examples:
.. code-block:: bash
-D CMAKE_TUNE_FLAGS=-fsanitize=address # enable address sanitizer / memory leak checker
-D CMAKE_TUNE_FLAGS=-fsanitize=undefined # enable undefined behavior sanitizer
-D CMAKE_TUNE_FLAGS=-fsanitize=thread # enable thread sanitizer
-D ENABLE_SANITIZER=none # no sanitizer active (default)
-D ENABLE_SANITIZER=address # enable address sanitizer / memory leak checker
-D ENABLE_SANITIZER=leak # enable memory leak checker (only)
-D ENABLE_SANITIZER=undefined # enable undefined behavior sanitizer
-D ENABLE_SANITIZER=thread # enable thread sanitizer
----------
@ -86,19 +89,21 @@ The output of this command will be looking something like this::
[...]$ ctest
Test project /home/akohlmey/compile/lammps/build-testing
Start 1: MolPairStyle:hybrid-overlay
1/26 Test #1: MolPairStyle:hybrid-overlay ......... Passed 0.02 sec
1/109 Test #1: MolPairStyle:hybrid-overlay ......... Passed 0.02 sec
Start 2: MolPairStyle:hybrid
2/26 Test #2: MolPairStyle:hybrid ................. Passed 0.01 sec
2/109 Test #2: MolPairStyle:hybrid ................. Passed 0.01 sec
Start 3: MolPairStyle:lj_class2
[...]
Start 25: AngleStyle:harmonic
25/26 Test #25: AngleStyle:harmonic ................. Passed 0.01 sec
Start 26: AngleStyle:zero
26/26 Test #26: AngleStyle:zero ..................... Passed 0.01 sec
Start 107: PotentialFileReader
107/109 Test #107: PotentialFileReader ................ Passed 0.04 sec
Start 108: EIMPotentialFileReader
108/109 Test #108: EIMPotentialFileReader ............. Passed 0.03 sec
Start 109: TestSimpleCommands
109/109 Test #109: TestSimpleCommands ................. Passed 0.02 sec
100% tests passed, 0 tests failed out of 26
Total Test time (real) = 0.27 sec
Total Test time (real) = 25.57 sec
The ``ctest`` command has many options, the most important ones are:
@ -117,6 +122,8 @@ The ``ctest`` command has many options, the most important ones are:
- exclude subset of tests matching the regular expression <regex>
* - -N
- dry-run: display list of tests without running them
* - -T memcheck
- run tests with valgrind memory checker (if available)
In its full implementation, the unit test framework will consist of multiple
kinds of tests implemented in different programming languages (C++, C, Python,
@ -126,7 +133,7 @@ in the next section.
.. note::
This unit test framework is new and still under development.
The unit test framework is new and still under development.
The coverage is only minimal and will be expanded over time.
Tests styles of the same kind of style (e.g. pair styles or
bond styles) are performed with the same executable using
@ -193,8 +200,8 @@ In this particular case, 5 out of 6 sets of tests were conducted, the
tests for the ``lj/cut/opt`` pair style was skipped, since the tests
executable did not include it. To learn what individual tests are performed,
you (currently) need to read the source code. You can use code coverage
recording (see next section) to confirm how well the tests cover the individual
source files.
recording (see next section) to confirm how well the tests cover the code
paths in the individual source files.
The force style test programs have a common set of options:
@ -211,6 +218,14 @@ The force style test programs have a common set of options:
* - -v
- verbose output: also print the executed LAMMPS commands
The ``ctest`` tool has no mechanism to directly pass flags to the individual
test programs, but a workaround has been implemented where these flags can be
set in an environment variable ``TEST_ARGS``. Example:
.. code-block:: bash
env TEST_ARGS=-s ctest -V -R BondStyle
To add a test for a style that is not yet covered, it is usually best
to copy a YAML file for a similar style to a new file, edit the details
of the style (how to call it, how to set its coefficients) and then
@ -237,12 +252,22 @@ and working.
performed with automatically rescaled epsilon to account for
additional loss of precision from code optimizations and different
summation orders.
- When compiling with aggressive compiler optimization, some tests
- When compiling with (aggressive) compiler optimization, some tests
are likely to fail. It is recommended to inspect the individual
tests in detail to decide whether the specific error for a specific
tests in detail to decide, whether the specific error for a specific
property is acceptable (it often is), or this may be an indication
of mis-compiled code (or undesired large of precision due to
reordering of operations).
of mis-compiled code (or an undesired large loss of precision due
to significant reordering of operations and thus less error cancellation).
Tests for other components and utility functions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Additional tests that validate utility functions or specific components
of LAMMPS are implemented as standalone executable which may, or may not
require creating a suitable LAMMPS instance. These tests are more specific
and do not require YAML format input files. To add a test, either an
existing source file needs to be extended or a new file added, which in turn
requires additions to the ``CMakeLists.txt`` file in the source folder.
Collect and visualize code coverage metrics
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -306,3 +331,23 @@ The images below illustrate how the data is presented.
:target: JPG/coverage-file-branches.png
Source page with branches
Coding style utilities
----------------------
To aid with enforcing some of the coding style conventions in LAMMPS
some additional build targets have been added. These require Python 3.5
or later and will only work on Unix-like operating and file systems.
The following options are available.
.. code-block:: bash
make check-whitespace # generate coverage report in HTML format
make fix-whitespace # generate coverage report in XML format
make check-permissions # delete folder with HTML format coverage report
make fix-permissions # delete all collected coverage data and HTML output
For the code in the ``unittest`` tree we are using the `clang-format`
tool (Clang version 8.0 or later is required). If available, the source
code files in the ``unittest`` tree can be updated to conform to the
formatting settings using ``make format-tests``.

558
doc/src/Build_extras.rst
View File

File diff suppressed because it is too large Load Diff

78
doc/src/Build_link.rst
View File

@ -1,12 +1,12 @@
Link LAMMPS as a library to another code
========================================
LAMMPS is designed as a library of C++ objects and can thus be
LAMMPS is designed as a library of C++ objects that can be
integrated into other applications including Python scripts.
The files ``src/library.cpp`` and ``src/library.h`` define a
C-style API for using LAMMPS as a library. See the :doc:`Howto
library <Howto_library>` doc page for a description of the interface
and how to extend it for your needs.
library <Howto_library>` page for a description of the interface
and how to use it for your needs.
The :doc:`Build basics <Build_basics>` doc page explains how to build
LAMMPS as either a shared or static library. This results in a file
@ -31,18 +31,18 @@ the suffix ``.so.0`` (or some other number).
communicator with a subset of MPI ranks to the function creating the
LAMMPS instance.
----------
**Link with LAMMPS as a static library**\ :
Link with LAMMPS as a static library
------------------------------------
The calling application can link to LAMMPS as a static library with
compilation and link commands as in the examples shown below. These
are examples for a code written in C in the file *caller.c*.
are examples for a code written in C in the file ``caller.c``.
The benefit of linking to a static library is, that the resulting
executable is independent of that library since all required
executable code from the library is copied into the calling executable.
*CMake build*\ :
CMake build
^^^^^^^^^^^
This assumes that LAMMPS has been configured without setting a
``LAMMPS_MACHINE`` name, installed with "make install", and the
@ -55,7 +55,8 @@ The commands to compile and link a coupled executable are then:
mpicc -c -O $(pkgconf liblammps --cflags) caller.c
mpicxx -o caller caller.o -$(pkgconf liblammps --libs)
*Traditional make*\ :
Traditional make
^^^^^^^^^^^^^^^^
This assumes that LAMMPS has been compiled in the folder
``${HOME}/lammps/src`` with "make mpi". The commands to compile and link
@ -83,20 +84,20 @@ LAMMPS library without any optional packages that depend on libraries
need to include all flags, libraries, and paths for the coupled
executable, that are also required to link the LAMMPS executable.
*CMake build*\ :
CMake build
^^^^^^^^^^^
When using CMake, additional libraries with sources in the lib folder
are built, but not included in ``liblammps.a`` and (currently) not
installed with "make install" and not included in the *pkgconfig*
installed with ``make install`` and not included in the ``pkgconfig``
configuration file. They can be found in the top level build folder,
but you have to determine the necessary link flags manually. It is
therefore recommended to either use the traditional make procedure to
build and link with a static library or build and link with a shared
library instead.
.. TODO: this needs to be updated to reflect that latest CMake changes after they are complete.
*Traditional make*\ :
Traditional make
^^^^^^^^^^^^^^^^
After you have compiled a static LAMMPS library using the conventional
build system for example with "make mode=static serial". And you also
@ -110,10 +111,10 @@ change to:
g++ -o caller caller.o -L${HOME}/lammps/lib/poems \
-L${HOME}/lammps/src/STUBS -L${HOME}/lammps/src -llammps_serial -lpoems -lmpi_stubs
Note, that you need to link with "g++" instead of "gcc", since the
LAMMPS library is C++ code. You can display the currently applied
settings for building LAMMPS for the "serial" machine target by using
the command:
Note, that you need to link with ``g++`` instead of ``gcc`` even if you have
written your code in C, since LAMMPS itself is C++ code. You can display the
currently applied settings for building LAMMPS for the "serial" machine target
by using the command:
.. code-block:: bash
@ -136,12 +137,11 @@ Which should output something like:
From this you can gather the necessary paths and flags. With
makefiles for other *machine* configurations you need to do the
equivalent and replace "serial" with the corresponding *machine* name
equivalent and replace "serial" with the corresponding "machine" name
of the makefile.
----------
**Link with LAMMPS as a shared library**\ :
Link with LAMMPS as a shared library
------------------------------------
When linking to LAMMPS built as a shared library, the situation becomes
much simpler, as all dependent libraries and objects are either included
@ -151,7 +151,8 @@ linking the calling executable. Only the *-I* flags are needed. So the
example case from above of the serial version static LAMMPS library with
the POEMS package installed becomes:
*CMake build*\ :
CMake build
^^^^^^^^^^^
The commands with a shared LAMMPS library compiled with the CMake
build process are the same as for the static library.
@ -161,10 +162,11 @@ build process are the same as for the static library.
mpicc -c -O $(pkgconf liblammps --cflags) caller.c
mpicxx -o caller caller.o -$(pkgconf --libs)
*Traditional make*\ :
Traditional make
^^^^^^^^^^^^^^^^
The commands with a shared LAMMPS library compiled with the
traditional make build using "make mode=shared serial" becomes:
traditional make build using ``make mode=shared serial`` becomes:
.. code-block:: bash
@ -231,29 +233,3 @@ If a required library is missing, you would get a 'not found' entry:
libc.so.6 => /usr/lib64/libc.so.6 (0x00007fb7c7b5d000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb7c80a2000)
----------
**Calling the LAMMPS library**\ :
Either flavor of library (static or shared) allows one or more LAMMPS
objects to be instantiated from the calling program. When used from a
C++ program, most of the symbols and functions in LAMMPS are wrapped
in a ``LAMMPS_NS`` namespace; you can safely use any of its classes and
methods from within the calling code, as needed, and you will not incur
conflicts with functions and variables in your code that share the name.
This, however, does not extend to all additional libraries bundled with
LAMMPS in the lib folder and some of the low-level code of some packages.
To be compatible with C, Fortran, Python programs, the library has a simple
C-style interface, provided in ``src/library.cpp`` and ``src/library.h``.
See the :doc:`Python library <Python_library>` doc page for a
description of the Python interface to LAMMPS, which wraps the C-style
interface from a shared library through the `ctypes python module <ctypes_>`_.
See the sample codes in ``examples/COUPLE/simple`` for examples of C++ and
C and Fortran codes that invoke LAMMPS through its library interface.
Other examples in the COUPLE directory use coupling ideas discussed on
the :doc:`Howto couple <Howto_couple>` doc page.
.. _ctypes: https://docs.python.org/3/library/ctypes.html

15
doc/src/Build_package.rst
View File

@ -45,7 +45,8 @@ packages:
The mechanism for including packages is simple but different for CMake
versus make.
**CMake build**\ :
CMake build
^^^^^^^^^^^
.. code-block:: csh
@ -72,7 +73,8 @@ once with CMake.
invoke cmake. CMake will give an error if that is not the case,
indicating how you can un-install all packages in the src dir.
**Traditional make**\ :
Traditional make
^^^^^^^^^^^^^^^^
.. code-block:: bash
@ -108,7 +110,8 @@ once with make.
within the same command. You can include or exclude multiple packages
in a single make command, e.g. make yes-colloid no-manybody.
**CMake and make info**\ :
CMake and make info
^^^^^^^^^^^^^^^^^^^
Any package can be included or excluded in a LAMMPS build, independent
of all other packages. However, some packages include files derived
@ -132,7 +135,7 @@ src directory.
.. _cmake_presets:
**CMake shortcuts for installing many packages**\ :
CMake presets for installing many packages
Instead of specifying all the CMake options via the command-line,
CMake allows initializing its settings cache using script files.
@ -150,6 +153,7 @@ one of them as a starting point and customize it to your needs.
cmake -C ../cmake/presets/minimal.cmake [OPTIONS] ../cmake # enable just a few core packages
cmake -C ../cmake/presets/most.cmake [OPTIONS] ../cmake # enable most packages
cmake -C ../cmake/presets/download.cmake [OPTIONS] ../cmake # enable packages which download sources or potential files
cmake -C ../cmake/presets/nolib.cmake [OPTIONS] ../cmake # disable packages that do require extra libraries or tools
cmake -C ../cmake/presets/clang.cmake [OPTIONS] ../cmake # change settings to use the Clang compilers by default
cmake -C ../cmake/presets/intel.cmake [OPTIONS] ../cmake # change settings to use the Intel compilers by default
@ -184,7 +188,8 @@ one of them as a starting point and customize it to your needs.
----------
**Make shortcuts for installing many packages**\ :
Make shortcuts for installing many packages
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The following commands are useful for managing package source files
and their installation when building LAMMPS via traditional make.

82
doc/src/Build_settings.rst
View File

@ -44,7 +44,8 @@ require use of an FFT library to compute 1d FFTs. The KISS FFT
library is included with LAMMPS but other libraries can be faster.
LAMMPS can use them if they are available on your system.
**CMake variables**\ :
CMake build
^^^^^^^^^^^
.. code-block:: bash
@ -74,7 +75,12 @@ to assist:
-D FFT_MKL_THREADS=on # enable using threaded FFTs with MKL libraries
-D MKL_LIBRARIES=path
**Makefile.machine settings**\ :
Traditional make
^^^^^^^^^^^^^^^^
To change the FFT library to be used and its options, you have to edit
your machine Makefile. Below are examples how the makefile variables
could be changed.
.. code-block:: make
@ -104,7 +110,8 @@ As with CMake, you do not need to set paths in ``FFT_INC`` or ``FFT_PATH``, if
the compiler can find the FFT header and library files in its default search path.
You must specify ``FFT_LIB`` with the appropriate FFT libraries to include in the link.
**CMake and make info**\ :
CMake build
^^^^^^^^^^^
The `KISS FFT library <http://kissfft.sf.net>`_ is included in the LAMMPS
distribution. It is portable across all platforms. Depending on the size
@ -127,7 +134,7 @@ download it from `www.fftw.org <http://www.fftw.org>`_. LAMMPS requires
version 3.X; the legacy version 2.1.X is no longer supported.
Building FFTW for your box should be as simple as ``./configure; make;
make install``\ . The install command typically requires root privileges
make install``. The install command typically requires root privileges
(e.g. invoke it via sudo), unless you specify a local directory with
the "--prefix" option of configure. Type ``./configure --help`` to see
various options.
@ -169,20 +176,25 @@ ARRAY mode.
.. _size:
Size of LAMMPS data types
Size of LAMMPS integer types
------------------------------------
LAMMPS has a few integer data types which can be defined as 4-byte or
8-byte integers. The default setting of "smallbig" is almost always
adequate.
LAMMPS has a few integer data types which can be defined as either
4-byte (= 32-bit) or 8-byte (= 64-bit) integers at compile time.
The default setting of "smallbig" is almost always adequate.
**CMake variable**\ :
CMake build
^^^^^^^^^^^
.. code-block:: bash
-D LAMMPS_SIZES=value # smallbig (default) or bigbig or smallsmall
**Makefile.machine setting**\ :
Traditional build
^^^^^^^^^^^^^^^^^
If you want a setting different from the default, you need to edit your
machine Makefile.
.. code-block:: make
@ -190,7 +202,8 @@ adequate.
The default setting is ``-DLAMMPS_SMALLBIG`` if nothing is specified
**CMake and make info**\ :
CMake and make info
^^^^^^^^^^^^^^^^^^^
The default "smallbig" setting allows for simulations with:
@ -251,7 +264,8 @@ PNG image files. Likewise the :doc:`dump movie <dump_image>` command
outputs movie files in MPEG format. Using these options requires the
following settings:
**CMake variables**\ :
CMake build
^^^^^^^^^^^
.. code-block:: bash
@ -276,7 +290,8 @@ variables:
-D ZLIB_LIBRARIES=path # path to libz.a (.so) file
-D FFMPEG_EXECUTABLE=path # path to ffmpeg executable
**Makefile.machine settings**\ :
Traditional make
^^^^^^^^^^^^^^^^
.. code-block:: make
@ -295,7 +310,8 @@ with a list of graphics libraries to include in the link. You must
insure ffmpeg is in a directory where LAMMPS can find it at runtime,
that is a directory in your PATH environment variable.
**CMake and make info**\ :
CMake and make info
^^^^^^^^^^^^^^^^^^^
Using ``ffmpeg`` to output movie files requires that your machine
supports the "popen" function in the standard runtime library.
@ -318,7 +334,8 @@ If this option is enabled, large files can be read or written with
gzip compression by several LAMMPS commands, including
:doc:`read_data <read_data>`, :doc:`rerun <rerun>`, and :doc:`dump <dump>`.
**CMake variables**\ :
CMake build
^^^^^^^^^^^
.. code-block:: bash
@ -326,13 +343,15 @@ gzip compression by several LAMMPS commands, including
# default is yes if CMake can find gzip, else no
-D GZIP_EXECUTABLE=path # path to gzip executable if CMake cannot find it
**Makefile.machine setting**\ :
Traditional make
^^^^^^^^^^^^^^^^
.. code-block:: make
LMP_INC = -DLAMMPS_GZIP
**CMake and make info**\ :
CMake and make info
^^^^^^^^^^^^^^^^^^^
This option requires that your machine supports the "popen()" function
in the standard runtime library and that a gzip executable can be
@ -363,7 +382,8 @@ pointers that are aligned to 16-byte boundaries. Using SSE vector
instructions efficiently, however, requires memory blocks being
aligned on 64-byte boundaries.
**CMake variable**\ :
CMake build
^^^^^^^^^^^
.. code-block:: bash
@ -374,7 +394,8 @@ and revert to using the malloc() C-library function instead. When
compiling LAMMPS for Windows systems, malloc() will always be used
and this setting ignored.
**Makefile.machine setting**\ :
Traditional make
^^^^^^^^^^^^^^^^
.. code-block:: make
@ -398,13 +419,15 @@ types, the following setting will be needed. It converts "long long"
to a "long" data type, which should be the desired 8-byte integer on
those systems:
**CMake variable**\ :
CMake build
^^^^^^^^^^^
.. code-block:: bash
-D LAMMPS_LONGLONG_TO_LONG=value # yes or no (default)
**Makefile.machine setting**\ :
Traditional make
^^^^^^^^^^^^^^^^
.. code-block:: make
@ -420,17 +443,26 @@ Exception handling when using LAMMPS as a library
This setting is useful when external codes drive LAMMPS as a library.
With this option enabled, LAMMPS errors do not kill the calling code.
Instead, the call stack is unwound and control returns to the caller,
e.g. to Python. Of course the calling code has to be set up to
*catch* exceptions from within LAMMPS.
e.g. to Python. Of course, the calling code has to be set up to
*catch* exceptions thrown from within LAMMPS.
**CMake variable**\ :
CMake build
^^^^^^^^^^^
.. code-block:: bash
-D LAMMPS_EXCEPTIONS=value # yes or no (default)
**Makefile.machine setting**\ :
Traditional make
^^^^^^^^^^^^^^^^
.. code-block:: make
LMP_INC = -DLAMMPS_EXCEPTIONS
.. note::
When LAMMPS is running in parallel, it is not always possible to
cleanly recover from an exception since not all parallel ranks may
throw an exception and thus other MPI ranks may get stuck waiting for
messages from the ones with errors.

10
doc/src/Commands_all.rst
View File

@ -46,13 +46,6 @@ An alphabetic list of all general LAMMPS commands.
* :doc:`dimension <dimension>`
* :doc:`displace_atoms <displace_atoms>`
* :doc:`dump <dump>`
* :doc:`dump atom/adios <dump_adios>`
* :doc:`dump custom/adios <dump_adios>`
* :doc:`dump image <dump_image>`
* :doc:`dump movie <dump_image>`
* :doc:`dump netcdf <dump_netcdf>`
* :doc:`dump netcdf/mpiio <dump_netcdf>`
* :doc:`dump vtk <dump_vtk>`
* :doc:`dump_modify <dump_modify>`
* :doc:`dynamical_matrix <dynamical_matrix>`
* :doc:`echo <echo>`
@ -108,7 +101,8 @@ An alphabetic list of all general LAMMPS commands.
* :doc:`region <region>`
* :doc:`replicate <replicate>`
* :doc:`rerun <rerun>`
* :doc:`reset_ids <reset_ids>`
* :doc:`reset_atom_ids <reset_atom_ids>`
* :doc:`reset_mol_ids <reset_mol_ids>`
* :doc:`reset_timestep <reset_timestep>`
* :doc:`restart <restart>`
* :doc:`run <run>`

3
doc/src/Commands_compute.rst
View File

@ -79,6 +79,8 @@ KOKKOS, o = USER-OMP, t = OPT.
* :doc:`ke/atom/eff <compute_ke_atom_eff>`
* :doc:`ke/eff <compute_ke_eff>`
* :doc:`ke/rigid <compute_ke_rigid>`
* :doc:`mesont <compute_mesont>`
* :doc:`mliap <compute_mliap>`
* :doc:`momentum <compute_momentum>`
* :doc:`msd <compute_msd>`
* :doc:`msd/chunk <compute_msd_chunk>`
@ -121,6 +123,7 @@ KOKKOS, o = USER-OMP, t = OPT.
* :doc:`smd/tlsph/strain/rate <compute_smd_tlsph_strain_rate>`
* :doc:`smd/tlsph/stress <compute_smd_tlsph_stress>`
* :doc:`smd/triangle/vertices <compute_smd_triangle_vertices>`
* :doc:`smd/ulsph/effm <compute_smd_ulsph_effm>`
* :doc:`smd/ulsph/num/neighs <compute_smd_ulsph_num_neighs>`
* :doc:`smd/ulsph/strain <compute_smd_ulsph_strain>`
* :doc:`smd/ulsph/strain/rate <compute_smd_ulsph_strain_rate>`

2
doc/src/Commands_fix.rst
View File

@ -42,6 +42,7 @@ OPT.
* :doc:`bocs <fix_bocs>`
* :doc:`bond/break <fix_bond_break>`
* :doc:`bond/create <fix_bond_create>`
* :doc:`bond/create/angle <fix_bond_create>`
* :doc:`bond/react <fix_bond_react>`
* :doc:`bond/swap <fix_bond_swap>`
* :doc:`box/relax <fix_box_relax>`
@ -147,6 +148,7 @@ OPT.
* :doc:`oneway <fix_oneway>`
* :doc:`orient/bcc <fix_orient>`
* :doc:`orient/fcc <fix_orient>`
* :doc:`orient/eco <fix_orient_eco>`
* :doc:`phonon <fix_phonon>`
* :doc:`pimd <fix_pimd>`
* :doc:`planeforce <fix_planeforce>`

6
doc/src/Commands_input.rst
View File

@ -31,9 +31,9 @@ does something different than this sequence:
run 100
In the first case, the specified timestep (0.5 fs) is used for two
simulations of 100 timesteps each. In the 2nd case, the default
timestep (1.0 fs) is used for the 1st 100 step simulation and a 0.5 fs
timestep is used for the 2nd one.
simulations of 100 timesteps each. In the second case, the default
timestep (1.0 fs) is used for the first 100 step simulation and a 0.5 fs
timestep is used for the second one.
(2) Some commands are only valid when they follow other commands. For
example you cannot set the temperature of a group of atoms until atoms

19
doc/src/Commands_pair.rst
View File

@ -136,22 +136,22 @@ OPT.
* :doc:`lj/class2/soft <pair_fep_soft>`
* :doc:`lj/cubic (go) <pair_lj_cubic>`
* :doc:`lj/cut (gikot) <pair_lj>`
* :doc:`lj/cut/coul/cut (gko) <pair_lj>`
* :doc:`lj/cut/coul/cut (gko) <pair_lj_cut_coul>`
* :doc:`lj/cut/coul/cut/soft (o) <pair_fep_soft>`
* :doc:`lj/cut/coul/debye (gko) <pair_lj>`
* :doc:`lj/cut/coul/dsf (gko) <pair_lj>`
* :doc:`lj/cut/coul/long (gikot) <pair_lj>`
* :doc:`lj/cut/coul/debye (gko) <pair_lj_cut_coul>`
* :doc:`lj/cut/coul/dsf (gko) <pair_lj_cut_coul>`
* :doc:`lj/cut/coul/long (gikot) <pair_lj_cut_coul>`
* :doc:`lj/cut/coul/long/cs <pair_cs>`
* :doc:`lj/cut/coul/long/soft (o) <pair_fep_soft>`
* :doc:`lj/cut/coul/msm (go) <pair_lj>`
* :doc:`lj/cut/coul/wolf (o) <pair_lj>`
* :doc:`lj/cut/coul/msm (go) <pair_lj_cut_coul>`
* :doc:`lj/cut/coul/wolf (o) <pair_lj_cut_coul>`
* :doc:`lj/cut/dipole/cut (go) <pair_dipole>`
* :doc:`lj/cut/dipole/long (g) <pair_dipole>`
* :doc:`lj/cut/dipole/sf (go) <pair_dipole>`
* :doc:`lj/cut/soft (o) <pair_fep_soft>`
* :doc:`lj/cut/thole/long (o) <pair_thole>`
* :doc:`lj/cut/tip4p/cut (o) <pair_lj>`
* :doc:`lj/cut/tip4p/long (got) <pair_lj>`
* :doc:`lj/cut/tip4p/cut (o) <pair_lj_cut_tip4p>`
* :doc:`lj/cut/tip4p/long (got) <pair_lj_cut_tip4p>`
* :doc:`lj/cut/tip4p/long/soft (o) <pair_fep_soft>`
* :doc:`lj/expand (gko) <pair_lj_expand>`
* :doc:`lj/expand/coul/long (g) <pair_lj_expand>`
@ -180,8 +180,10 @@ OPT.
* :doc:`meam/spline (o) <pair_meam_spline>`
* :doc:`meam/sw/spline <pair_meam_sw_spline>`
* :doc:`mesocnt <pair_mesocnt>`
* :doc:`mesont/tpm <pair_mesont_tpm>`
* :doc:`mgpt <pair_mgpt>`
* :doc:`mie/cut (g) <pair_mie>`
* :doc:`mliap <pair_mliap>`
* :doc:`mm3/switch3/coulgauss/long <pair_mm3_switch3_coulgauss_long>`
* :doc:`momb <pair_momb>`
* :doc:`morse (gkot) <pair_morse>`
@ -227,7 +229,6 @@ OPT.
* :doc:`smd/ulsph <pair_smd_ulsph>`
* :doc:`smtbq <pair_smtbq>`
* :doc:`snap (k) <pair_snap>`
* :doc:`snap (k) <pair_snap>`
* :doc:`soft (go) <pair_soft>`
* :doc:`sph/heatconduction <pair_sph_heatconduction>`
* :doc:`sph/idealgas <pair_sph_idealgas>`

2
doc/src/Developer/developer.tex
View File

@ -142,7 +142,7 @@ follows:
minimize.
\item The Special class walks the bond topology of a molecular system
to find 1st, 2nd, 3rd neighbors of each atom. It is invoked by
to find first, second, third neighbors of each atom. It is invoked by
several commands, like read\_data, read\_restart, and replicate.
\item The Atom class stores all per-atom arrays. More precisely, they

22
doc/src/Errors_messages.rst
View File

@ -381,7 +381,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
are defined.
*Bond atom missing in box size check*
The 2nd atoms needed to compute a particular bond is missing on this
The second atom needed to compute a particular bond is missing on this
processor. Typically this is because the pairwise cutoff is set too
short or the bond has blown apart and an atom is too far away.
@ -391,7 +391,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
the atoms are too far apart to make a valid bond.
*Bond atom missing in image check*
The 2nd atom in a particular bond is missing on this processor.
The second atom in a particular bond is missing on this processor.
Typically this is because the pairwise cutoff is set too short or the
bond has blown apart and an atom is too far away.
@ -401,12 +401,12 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
are too far apart to make a valid bond.
*Bond atoms %d %d missing on proc %d at step %ld*
The 2nd atom needed to compute a particular bond is missing on this
The second atom needed to compute a particular bond is missing on this
processor. Typically this is because the pairwise cutoff is set too
short or the bond has blown apart and an atom is too far away.
*Bond atoms missing on proc %d at step %ld*
The 2nd atom needed to compute a particular bond is missing on this
The second atom needed to compute a particular bond is missing on this
processor. Typically this is because the pairwise cutoff is set too
short or the bond has blown apart and an atom is too far away.
@ -1374,7 +1374,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
template does not qualify.
*Cannot use fix box/relax on a 2nd non-periodic dimension*
When specifying an off-diagonal pressure component, the 2nd of the two
When specifying an off-diagonal pressure component, the second of the two
dimensions must be periodic. E.g. if the xy component is specified,
then the y dimension must be periodic.
@ -1388,7 +1388,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
also keyword tri or xy, this is wrong.
*Cannot use fix box/relax with tilt factor scaling on a 2nd non-periodic dimension*
When specifying scaling on a tilt factor component, the 2nd of the two
When specifying scaling on a tilt factor component, the second of the two
dimensions must be periodic. E.g. if the xy component is specified,
then the y dimension must be periodic.
@ -1429,7 +1429,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
This would be changing the same box dimension twice.
*Cannot use fix nvt/npt/nph on a 2nd non-periodic dimension*
When specifying an off-diagonal pressure component, the 2nd of the two
When specifying an off-diagonal pressure component, the second of the two
dimensions must be periodic. E.g. if the xy component is specified,
then the y dimension must be periodic.
@ -1447,13 +1447,13 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
Self-explanatory.
*Cannot use fix nvt/npt/nph with xy scaling when y is non-periodic dimension*
The 2nd dimension in the barostatted tilt factor must be periodic.
The second dimension in the barostatted tilt factor must be periodic.
*Cannot use fix nvt/npt/nph with xz scaling when z is non-periodic dimension*
The 2nd dimension in the barostatted tilt factor must be periodic.
The second dimension in the barostatted tilt factor must be periodic.
*Cannot use fix nvt/npt/nph with yz scaling when z is non-periodic dimension*
The 2nd dimension in the barostatted tilt factor must be periodic.
The second dimension in the barostatted tilt factor must be periodic.
*Cannot use fix pour rigid and not molecule*
Self-explanatory.
@ -7192,7 +7192,7 @@ keyword to allow for additional bonds to be formed
does not exist.
*Replacing a fix, but new style != old style*
A fix ID can be used a 2nd time, but only if the style matches the
A fix ID can be used a second time, but only if the style matches the
previous fix. In this case it is assumed you with to reset a fix's
parameters. This error may mean you are mistakenly re-using a fix ID
when you do not intend to.

8
doc/src/Errors_warnings.rst
View File

@ -43,17 +43,17 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
Self-explanatory.
*Bond atom missing in box size check*
The 2nd atoms needed to compute a particular bond is missing on this
The second atom needed to compute a particular bond is missing on this
processor. Typically this is because the pairwise cutoff is set too
short or the bond has blown apart and an atom is too far away.
*Bond atom missing in image check*
The 2nd atom in a particular bond is missing on this processor.
The second atom in a particular bond is missing on this processor.
Typically this is because the pairwise cutoff is set too short or the
bond has blown apart and an atom is too far away.
*Bond atoms missing at step %ld*
The 2nd atom needed to compute a particular bond is missing on this
The second atom needed to compute a particular bond is missing on this
processor. Typically this is because the pairwise cutoff is set too
short or the bond has blown apart and an atom is too far away.
@ -486,7 +486,7 @@ This will most likely cause errors in kinetic fluctuations.
a new style.
*No Kspace calculation with verlet/split*
The 2nd partition performs a kspace calculation so the kspace_style
The second partition performs a kspace calculation so the kspace_style
command must be used.
*No automatic unit conversion to XTC file format conventions possible for units lj*

2
doc/src/Examples.rst
View File

@ -163,7 +163,7 @@ Here is how you can run and visualize one of the sample problems:
Running the simulation produces the files *dump.indent* and
*log.lammps*\ . You can visualize the dump file of snapshots with a
variety of 3rd-party tools highlighted on the
variety of third-party tools highlighted on the
`Visualization <https://lammps.sandia.gov/viz.html>`_ page of the LAMMPS
web site.

4
doc/src/Howto_bioFF.rst
View File

@ -102,8 +102,8 @@ documentation for the formula it computes.
* :doc:`pair_style <pair_buck>` buck/coul/cut
* :doc:`pair_style <pair_buck>` buck/coul/long
* :doc:`pair_style <pair_lj>` lj/cut
* :doc:`pair_style <pair_lj>` lj/cut/coul/cut
* :doc:`pair_style <pair_lj>` lj/cut/coul/long
* :doc:`pair_style <pair_lj_cut_coul>` lj/cut/coul/cut
* :doc:`pair_style <pair_lj_cut_coul>` lj/cut/coul/long
* :doc:`pair_style <pair_hbond_dreiding>` hbond/dreiding/lj
* :doc:`pair_style <pair_hbond_dreiding>` hbond/dreiding/morse

171
doc/src/Howto_body.rst
View File

@ -9,13 +9,15 @@ surface meshes of discrete points, collections of sub-particles,
deformable objects, etc. Note that other kinds of finite-size
spherical and aspherical particles are also supported by LAMMPS, such
as spheres, ellipsoids, line segments, and triangles, but they are
simpler entities that body particles. See the :doc:`Howto spherical <Howto_spherical>` doc page for a general overview of all
these particle types.
simpler entities than body particles. See the :doc:`Howto spherical
<Howto_spherical>` doc page for a general overview of all these
particle types.
Body particles are used via the :doc:`atom_style body <atom_style>`
command. It takes a body style as an argument. The current body
styles supported by LAMMPS are as follows. The name in the first
column is used as the *bstyle* argument for the :doc:`atom_style body <atom_style>` command.
column is used as the *bstyle* argument for the :doc:`atom_style body
<atom_style>` command.
+----------------------+---------------------------------------------------+
| *nparticle* | rigid body with N sub-particles |
@ -30,8 +32,9 @@ thus how they can be used to compute pairwise body/body or
bond/non-body (point particle) interactions. More details of each
style are described below.
More styles may be added in the future. See the :doc:`Modify body <Modify_body>` doc page for details on how to add a new body
style to the code.
More styles may be added in the future. See the :doc:`Modify body
<Modify_body>` doc page for details on how to add a new body style to
the code.
----------
@ -55,10 +58,10 @@ interactions, building neighbor lists, migrating particles between
processors, output of particles to a dump file, etc. This means that
interactions between pairs of bodies or between a body and non-body
(point) particle need to be encoded in an appropriate pair style. If
such a pair style were to mimic the :doc:`fix rigid <fix_rigid>` model,
it would need to loop over the entire collection of interactions
between pairs of simple particles within the two bodies, each time a
single body/body interaction was computed.
such a pair style were to mimic the :doc:`fix rigid <fix_rigid>`
model, it would need to loop over the entire collection of
interactions between pairs of simple particles within the two bodies,
each time a single body/body interaction was computed.
Thus it only makes sense to use body particles and develop such a pair
style, when particle/particle interactions are more complex than what
@ -160,27 +163,6 @@ of the body particle.
The :doc:`pair_style body/nparticle <pair_body_nparticle>` command can be used
with this body style to compute body/body and body/non-body interactions.
For output purposes via the :doc:`compute body/local <compute_body_local>` and :doc:`dump local <dump>`
commands, this body style produces one datum for each of the N
sub-particles in a body particle. The datum has 3 values:
.. parsed-literal::
1 = x position of sub-particle
2 = y position of sub-particle
3 = z position of sub-particle
These values are the current position of the sub-particle within the
simulation domain, not a displacement from the center-of-mass (COM) of
the body particle itself. These values are calculated using the
current COM and orientation of the body particle.
For images created by the :doc:`dump image <dump_image>` command, if the
*body* keyword is set, then each body particle is drawn as a
collection of spheres, one for each sub-particle. The size of each
sphere is determined by the *bflag1* parameter for the *body* keyword.
The *bflag2* argument is ignored.
----------
**Specifics of body style rounded/polygon:**
@ -208,7 +190,7 @@ The Nmin and Nmax arguments are used to bound the size of data
structures used internally by each particle.
When the :doc:`read_data <read_data>` command reads a data file for this
body style, the following information must be provided for each entry
body style, the following information must be provided for each body
in the *Bodies* section of the data file:
.. parsed-literal::
@ -219,21 +201,25 @@ in the *Bodies* section of the data file:
x1 y1 z1
...
xN yN zN
i j j k k ...
diameter
where M = 6 + 3\*N + 2\*N + 1, and N is the number of vertices in the
body particle.
where M = 6 + 3\*N + 1, and N is the number of vertices in the body
particle.
The integer line has a single value N. The floating point line(s)
list 6 moments of inertia followed by the coordinates of the N
list 6 moments of inertia, followed by the coordinates of the N
vertices (x1 to zN) as 3N values (with z = 0.0 for each), followed by
2N vertex indices corresponding to the end points of the N edges,
followed by a single diameter value = the rounded diameter of the
circle that surrounds each vertex. The diameter value can be different
for each body particle. These floating-point values can be listed on
as many lines as you wish; see the :doc:`read_data <read_data>` command
for more details.
a diameter value = the rounded diameter of the circle that surrounds
each vertex. The diameter value can be different for each body
particle. These floating-point values can be listed on as many lines
as you wish; see the :doc:`read_data <read_data>` command for more
details.
.. note::
It is important that the vertices for each polygonal body particle be
listed in order around its perimeter, so that edges can be inferred.
LAMMPS does not check that this is the case.
The 6 moments of inertia (ixx,iyy,izz,ixy,ixz,iyz) should be the
values consistent with the current orientation of the rigid body
@ -260,10 +246,6 @@ is consistent with the 6 moments of inertia: ixx iyy izz ixy ixz iyz =
-0.7071 0.7071 0
0.7071 0.7071 0
0.7071 -0.7071 0
0 1
1 2
2 3
3 0
1.0
A rod in 2D, whose length is 4.0, mass 1.0, rounded at two ends
@ -345,8 +327,10 @@ in the *Bodies* section of the data file:
1 2 3 4
diameter
where M = 6 + 3\*N + 2\*E + 4\*F + 1, and N is the number of vertices in
the body particle, E = number of edges, F = number of faces.
where M = 6 + 3\*N + 2\*E + 4\*F + 1, and N is the number of vertices
in the body particle, E = number of edges, F = number of faces. For N
= 1 or 2, the format is simpler. E and F are ignored and no edges or
faces are listed, so that M = 6 + 3\*N + 1.
The integer line has three values: number of vertices (N), number of
edges (E) and number of faces (F). The floating point line(s) list 6
@ -356,16 +340,26 @@ the end points of the E edges, then 4\*F vertex indices defining F
faces. The last value is the diameter value = the rounded diameter of
the sphere that surrounds each vertex. The diameter value can be
different for each body particle. These floating-point values can be
listed on as many lines as you wish; see the
:doc:`read_data <read_data>` command for more details. Because the
maximum number of vertices per face is hard-coded to be 4
(i.e. quadrilaterals), faces with more than 4 vertices need to be
split into triangles or quadrilaterals. For triangular faces, the
last vertex index should be set to -1.
listed on as many lines as you wish; see the :doc:`read_data
<read_data>` command for more details.
The ordering of the 4 vertices within a face should follow
the right-hand rule so that the normal vector of the face points
outwards from the center of mass.
Note that vertices are numbered from 0 to N-1 inclusive. The order of
the 2 vertices in each edge does not matter. Faces can be triangles
or quadrilaterals. In both cases 4 vertices must be specified. For a
triangle the 4th vertex is -1. The 4 vertices within each triangle or
quadrilateral face should be ordered by the right-hand rule so that
the normal vector of the face points outwards from the center of mass.
For polyhedron with faces with more than 4 vertices, you should split
the complex face into multiple simple faces, each of which is a
triangle or quadrilateral.
.. note::
If a face is a quadrilateral then its 4 vertices must be co-planar.
LAMMPS does not check that this is the case. If you have a quad-face
of a polyhedron that is not planar (e.g. a cube whose vertices have
been randomly displaced), then you should represent the single quad
face as two triangle faces instead.
The 6 moments of inertia (ixx,iyy,izz,ixy,ixz,iyz) should be the
values consistent with the current orientation of the rigid body
@ -421,8 +415,8 @@ by circles of diameter 0.5, is specified as follows:
.. parsed-literal::
1 1 13
2
1 3 13
2 1 1
0 1.33333 1.33333 0 0 0
-2 0 0
2 0 0
@ -432,27 +426,34 @@ A sphere whose diameter is 3.0 and mass 1.0, is specified as follows:
.. parsed-literal::
1 1 10
1
1 3 10
1 1 1
0.9 0.9 0.9 0 0 0
0 0 0
3.0
The :doc:`pair_style body/rounded/polhedron <pair_body_rounded_polyhedron>` command can
be used with this body style to compute body/body interactions. The
:doc:`fix wall/body/polyhedron <fix_wall_body_polygon>` command can be
used with this body style to compute the interaction of body particles
with a wall.
The number of edges and faces for a rod or sphere must be listed,
but is ignored.
The :doc:`pair_style body/rounded/polhedron
<pair_body_rounded_polyhedron>` command can be used with this body
style to compute body/body interactions. The :doc:`fix
wall/body/polyhedron <fix_wall_body_polygon>` command can be used with
this body style to compute the interaction of body particles with a
wall.
----------
For output purposes via the :doc:`compute body/local <compute_body_local>` and :doc:`dump local <dump>`
commands, this body style produces one datum for each of the N
sub-particles in a body particle. The datum has 3 values:
**Output specifics for all body styles:**
For the :doc:`compute body/local <compute_body_local>` and :doc:`dump
local <dump>` commands, all 3 of the body styles described on his page
produces one datum for each of the N vertices (of sub-particles) in a
body particle. The datum has 3 values:
.. parsed-literal::
1 = x position of vertex
1 = x position of vertex (or sub-particle)
2 = y position of vertex
3 = z position of vertex
@ -461,15 +462,29 @@ simulation domain, not a displacement from the center-of-mass (COM) of
the body particle itself. These values are calculated using the
current COM and orientation of the body particle.
For images created by the :doc:`dump image <dump_image>` command, if the
*body* keyword is set, then each body particle is drawn as a polygon
consisting of N line segments. Note that the line segments are drawn
between the N vertices, which does not correspond exactly to the
physical extent of the body (because the :doc:`pair_style rounded/polygon <pair_body_rounded_polygon>` defines finite-size
spheres at those point and the line segments between the spheres are
tangent to the spheres). The drawn diameter of each line segment is
determined by the *bflag1* parameter for the *body* keyword. The
*bflag2* argument is ignored.
The :doc:`dump image <dump_image>` command and its *body* keyword can
be used to render body particles.
For the *nparticle* body style, each body is drawn as a
collection of spheres, one for each sub-particle. The size of each
sphere is determined by the *bflag1* parameter for the *body* keyword.
The *bflag2* argument is ignored.
For the *rounded/polygon* body style, each body is drawn as a polygon
with N line segments. For the *rounded/polyhedron* body style, each
face of each body is drawn as a polygon with N line segments. The
drawn diameter of each line segment is determined by the *bflag1*
parameter for the *body* keyword. The *bflag2* argument is ignored.
Note that for both the *rounded/polygon* and *rounded/polyhedron*
styles, line segments are drawn between the pairs of vertices.
Depending on the diameters of the line segments this may be slightly
different than the physical extent of the body as calculated by the
:doc:`pair_style rounded/polygon <pair_body_rounded_polygon>` or
:doc:`pair_style rounded/polyhedron <pair_body_rounded_polyhedron>`
commands. Conceptually, the pair styles define the surface of a 2d or
3d body by lines or planes that are tangent to the finite-size spheres
of specified diameter which are placed on each vertex position.
----------

2
doc/src/Howto_chunk.rst
View File

@ -197,7 +197,7 @@ compress individual polymer chains (molecules) in a mixture, is
explained on the :doc:`compute chunk/spread/atom <compute_chunk_spread_atom>` command doc page.
(7) An example for using one set of per-chunk values for molecule
chunks, to create a 2nd set of micelle-scale chunks (clustered
chunks, to create a second set of micelle-scale chunks (clustered
molecules, due to hydrophobicity), is explained on the :doc:`compute chunk/reduce <compute_reduce_chunk>` command doc page.
(8) An example for using one set of per-chunk values (dipole moment

2
doc/src/Howto_cmake.rst
View File

@ -331,7 +331,7 @@ Some common LAMMPS specific variables
* - ``BUILD_DOC``
- include building the HTML format documentation for packaging/installing (default: ``off``)
* - ``CMAKE_TUNE_FLAGS``
- common compiler flags, for optimization or instrumentation (default: compiler specific)
- common compiler flags, for optimization or instrumentation (default:)
* - ``LAMMPS_MACHINE``
- when set to ``name`` the LAMMPS executable and library will be called ``lmp_name`` and ``liblammps_name.a``
* - ``LAMMPS_EXCEPTIONS``

2
doc/src/Howto_coreshell.rst
View File

@ -119,7 +119,7 @@ non-polarized ions (ions without an attached satellite particle). The
groups, one for the core atoms, another for the shell atoms.
Non-polarized ions which might also be included in the treated system
should not be included into either of these groups, they are taken
into account by the *group-ID* (2nd argument) of the compute. The
into account by the *group-ID* (second argument) of the compute. The
groups can be defined using the :doc:`group *type*\ <group>` command.
Note that to perform thermostatting using this definition of
temperature, the :doc:`fix modify temp <fix_modify>` command should be

2
doc/src/Howto_multiple.rst
View File

@ -91,4 +91,4 @@ With these modifications, the 8 simulations of each script would run
on the 3 partitions one after the other until all were finished.
Initially, 3 simulations would be started simultaneously, one on each
partition. When one finished, that partition would then start
the 4th simulation, and so forth, until all 8 were completed.
the fourth simulation, and so forth, until all 8 were completed.

51
doc/src/Howto_output.rst
View File

@ -3,13 +3,15 @@ Output from LAMMPS (thermo, dumps, computes, fixes, variables)
There are four basic kinds of LAMMPS output:
* :doc:`Thermodynamic output <thermo_style>`, which is a list
of quantities printed every few timesteps to the screen and logfile.
* :doc:`Thermodynamic output <thermo_style>`, which is a list of
quantities printed every few timesteps to the screen and logfile.
* :doc:`Dump files <dump>`, which contain snapshots of atoms and various
per-atom values and are written at a specified frequency.
* Certain fixes can output user-specified quantities to files: :doc:`fix ave/time <fix_ave_time>` for time averaging, :doc:`fix ave/chunk <fix_ave_chunk>` for spatial or other averaging, and :doc:`fix print <fix_print>` for single-line output of
:doc:`variables <variable>`. Fix print can also output to the
screen.
* Certain fixes can output user-specified quantities to files:
:doc:`fix ave/time <fix_ave_time>` for time averaging,
:doc:`fix ave/chunk <fix_ave_chunk>` for spatial or other averaging, and
:doc:`fix print <fix_print>` for single-line output of
:doc:`variables <variable>`. Fix print can also output to the screen.
* :doc:`Restart files <restart>`.
A simulation prints one set of thermodynamic output and (optionally)
@ -41,7 +43,7 @@ to output and the kind of data they operate on and produce:
.. _global:
Global/per-atom/local data
---------------------------------------
--------------------------
Various output-related commands work with three different styles of
data: global, per-atom, or local. A global datum is one or more
@ -54,7 +56,7 @@ bond distances.
.. _scalar:
Scalar/vector/array data
-------------------------------------
------------------------
Global, per-atom, and local datums can each come in three kinds: a
single scalar value, a vector of values, or a 2d array of values. The
@ -81,10 +83,27 @@ the dimension twice (array -> scalar). Thus a command that uses
scalar values as input can typically also process elements of a vector
or array.
.. _disambiguation:
Disambiguation
--------------
Some computes and fixes produce data in multiple styles, e.g. a global
scalar and a per-atom vector. Usually the context in which the input
script references the data determines which style is meant. Example: if
a compute provides both a global scalar and a per-atom vector, the
former will be accessed by using ``c_ID`` in an equal-style variable,
while the latter will be accessed by using ``c_ID`` in an atom-style
variable. Note that atom-style variable formulas can also access global
scalars, but in this case it is not possible to do directly because of
the ambiguity. Instead, an equal-style variable can be defined which
accesses the global scalar, and that variable used in the atom-style
variable formula in place of ``c_ID``.
.. _thermo:
Thermodynamic output
---------------------------------
--------------------
The frequency and format of thermodynamic output is set by the
:doc:`thermo <thermo>`, :doc:`thermo_style <thermo_style>`, and
@ -112,7 +131,7 @@ intensive result.
.. _dump:
Dump file output
---------------------------
----------------
Dump file output is specified by the :doc:`dump <dump>` and
:doc:`dump_modify <dump_modify>` commands. There are several
@ -138,7 +157,7 @@ command.
.. _fixoutput:
Fixes that write output files
---------------------------------------------
-----------------------------
Several fixes take various quantities as input and can write output
files: :doc:`fix ave/time <fix_ave_time>`, :doc:`fix ave/chunk <fix_ave_chunk>`, :doc:`fix ave/histo <fix_ave_histo>`,
@ -192,7 +211,7 @@ from normal thermodynamic or dump file output.
.. _computeoutput:
Computes that process output quantities
-----------------------------------------------------------
---------------------------------------
The :doc:`compute reduce <compute_reduce>` and :doc:`compute reduce/region <compute_reduce>` commands take one or more per-atom
or local vector quantities as inputs and "reduce" them (sum, min, max,
@ -219,7 +238,7 @@ output commands.
.. _fixprocoutput:
Fixes that process output quantities
--------------------------------------------------------
------------------------------------
The :doc:`fix vector <fix_vector>` command can create global vectors as
output from global scalars as input, accumulating them one element at
@ -244,7 +263,7 @@ The output of this fix can be used as input to other output commands.
.. _compute:
Computes that generate values to output
-----------------------------------------------------
---------------------------------------
Every :doc:`compute <compute>` in LAMMPS produces either global or
per-atom or local values. The values can be scalars or vectors or
@ -257,7 +276,7 @@ without the word "atom" or "local" produce global values.
.. _fix:
Fixes that generate values to output
----------------------------------------------
------------------------------------
Some :doc:`fixes <fix>` in LAMMPS produces either global or per-atom or
local values which can be accessed by other commands. The values can
@ -269,7 +288,7 @@ describes them.
.. _variable:
Variables that generate values to output
-------------------------------------------------------
----------------------------------------
:doc:`Variables <variable>` defined in an input script can store one or
more strings. But equal-style, vector-style, and atom-style or
@ -284,7 +303,7 @@ commands described in this section.
.. _table:
Summary table of output options and data flow between commands
--------------------------------------------------------------------------
--------------------------------------------------------------
This table summarizes the various commands that can be used for
generating output from LAMMPS. Each command produces output data of

2
doc/src/Howto_restart.rst
View File

@ -28,7 +28,7 @@ scripts are based on. If that script had the line
added to it, it would produce 2 binary restart files (tmp.restart.50
and tmp.restart.100) as it ran.
This script could be used to read the 1st restart file and re-run the
This script could be used to read the first restart file and re-run the
last 50 timesteps:
.. code-block:: LAMMPS

6
doc/src/Howto_tip4p.rst
View File

@ -11,11 +11,11 @@ angle style of *harmonic* or *charmm* should also be used.
A TIP4P model is run with LAMMPS using either this command
for a cutoff model:
* :doc:`pair_style lj/cut/tip4p/cut <pair_lj>`
* :doc:`pair_style lj/cut/tip4p/cut <pair_lj_cut_tip4p>`
or these two commands for a long-range model:
* :doc:`pair_style lj/cut/tip4p/long <pair_lj>`
* :doc:`pair_style lj/cut/tip4p/long <pair_lj_cut_tip4p>`
* :doc:`kspace_style pppm/tip4p <kspace_style>`
For both models, the bond lengths and bond angles should be held fixed
@ -95,7 +95,7 @@ typically best in an efficiency sense to use a LJ cutoff >= Coulomb
cutoff + 2\*(OM distance), to shrink the size of the neighbor list.
This leads to slightly larger cost for the long-range calculation, so
you can test the trade-off for your model. The OM distance and the LJ
and Coulombic cutoffs are set in the :doc:`pair_style lj/cut/tip4p/long <pair_lj>` command.
and Coulombic cutoffs are set in the :doc:`pair_style lj/cut/tip4p/long <pair_lj_cut_tip4p>` command.
Wikipedia also has a nice article on `water models <http://en.wikipedia.org/wiki/Water_model>`_.

6
doc/src/Howto_triclinic.rst
View File

@ -85,7 +85,7 @@ where *V* is the volume of the box, **X** is the original vector quantity and
**x** is the vector in the LAMMPS basis.
There is no requirement that a triclinic box be periodic in any
dimension, though it typically should be in at least the 2nd dimension
dimension, though it typically should be in at least the second dimension
of the tilt (y in xy) if you want to enforce a shift in periodic
boundary conditions across that boundary. Some commands that work
with triclinic boxes, e.g. the :doc:`fix deform <fix_deform>` and :doc:`fix npt <fix_nh>` commands, require periodicity or non-shrink-wrap
@ -120,7 +120,7 @@ The 9 parameters, as well as lx,ly,lz, can be output via the
To avoid extremely tilted boxes (which would be computationally
inefficient), LAMMPS normally requires that no tilt factor can skew
the box more than half the distance of the parallel box length, which
is the 1st dimension in the tilt factor (x for xz). This is required
is the first dimension in the tilt factor (x for xz). This is required
both when the simulation box is created, e.g. via the
:doc:`create_box <create_box>` or :doc:`read_data <read_data>` commands,
as well as when the box shape changes dynamically during a simulation,
@ -137,7 +137,7 @@ limit during a dynamics run (e.g. via the :doc:`fix deform <fix_deform>`
command), then the box is "flipped" to an equivalent shape with a tilt
factor within the bounds, so the run can continue. See the :doc:`fix deform <fix_deform>` doc page for further details.
One exception to this rule is if the 1st dimension in the tilt
One exception to this rule is if the first dimension in the tilt
factor (x for xy) is non-periodic. In that case, the limits on the
tilt factor are not enforced, since flipping the box in that dimension
does not change the atom positions due to non-periodicity. In this

32
doc/src/Install_linux.rst
View File

@ -21,8 +21,14 @@ Pre-built Ubuntu Linux executables
A pre-built LAMMPS executable suitable for running on the latest
Ubuntu Linux versions, can be downloaded as a Debian package. This
allows you to install LAMMPS with a single command, and stay
up-to-date with the current version of LAMMPS by simply updating your
operating system.
up-to-date with the current stable version of LAMMPS by simply updating
your operating system. Please note, that the repository below offers
two LAMMPS packages, ``lammps-daily`` and ``lammps-stable``. The
LAMMPS developers recommend to use the ``lammps-stable`` package for
any production simulations. The ``lammps-daily`` package is built
from the LAMMPS development sources, and those versions may have known
issues and bugs when new features are added and the software has not
undergone full release testing.
To install the appropriate personal-package archives (PPAs), do the
following once:
@ -37,16 +43,16 @@ To install LAMMPS do the following once:
.. code-block:: bash
$ sudo apt-get install lammps-daily
$ sudo apt-get install lammps-stable
This downloads an executable named ``lmp_daily`` to your box, which
This downloads an executable named ``lmp_stable`` to your box, which
can then be used in the usual way to run input scripts:
.. code-block:: bash
$ lmp_daily -in in.lj
$ lmp_stable -in in.lj
To update LAMMPS to the most current version, do the following:
To update LAMMPS to the most current stable version, do the following:
.. code-block:: bash
@ -58,25 +64,25 @@ To get a copy of the current documentation and examples:
.. code-block:: bash
$ sudo apt-get install lammps-daily-doc
$ sudo apt-get install lammps-stable-doc
which will download the doc files in
``/usr/share/doc/lammps-daily-doc/doc`` and example problems in
``/usr/share/doc/lammps-stable-doc/doc`` and example problems in
``/usr/share/doc/lammps-doc/examples``.
To get a copy of the current potentials files:
.. code-block:: bash
$ sudo apt-get install lammps-daily-data
$ sudo apt-get install lammps-stable-data
which will download the potentials files to
``/usr/share/lammps-daily/potentials``. The ``lmp_daily`` binary is
``/usr/share/lammps-stable/potentials``. The ``lmp_stable`` binary is
hard-coded to look for potential files in this directory (it does not
use the `LAMMPS_POTENTIALS` environment variable, as described
in :doc:`pair_coeff <pair_coeff>` command).
The ``lmp_daily`` binary is built with the :ref:`KIM package <kim>` which
The ``lmp_stable`` binary is built with the :ref:`KIM package <kim>` which
results in the above command also installing the `kim-api` binaries when LAMMPS
is installed. In order to use potentials from `openkim.org <openkim_>`_, you
can install the `openkim-models` package
@ -89,9 +95,9 @@ To un-install LAMMPS, do the following:
.. code-block:: bash
$ sudo apt-get remove lammps-daily
$ sudo apt-get remove lammps-stable
Please use ``lmp_daily -help`` to see which compilation options, packages,
Please use ``lmp_stable -help`` to see which compilation options, packages,
and styles are included in the binary.
Thanks to Anton Gladky (gladky.anton at gmail.com) for setting up this

2
doc/src/Intro_nonfeatures.rst
View File

@ -34,7 +34,7 @@ Here are suggestions on how to perform these tasks:
molecular builder that will generate complex molecular models. See
the :doc:`Tools <Tools>` doc page for details on tools packaged with
LAMMPS. The `Pre/post processing page <http:/lammps.sandia.gov/prepost.html>`_ of the LAMMPS website
describes a variety of 3rd party tools for this task. Furthermore,
describes a variety of third party tools for this task. Furthermore,
some LAMMPS internal commands allow to reconstruct, or selectively add
topology information, as well as provide the option to insert molecule
templates instead of atoms for building bulk molecular systems.

3
doc/src/Manual.rst
View File

@ -32,11 +32,12 @@ a brief description of the basic code structure of LAMMPS.
----------
Once you are familiar with LAMMPS, you may want to bookmark :doc:`this page <Commands>` since it gives quick access to a doc page for
Once you are familiar with LAMMPS, you may want to bookmark :doc:`this page <Commands_all>` since it gives quick access to a doc page for
every LAMMPS command.
.. _lws: https://lammps.sandia.gov
.. _user_documentation:
.. toctree::
:maxdepth: 2
:numbered: 3

163
doc/src/Manual_build.rst
View File

@ -1,60 +1,62 @@
Building the LAMMPS manual
**************************
Depending on how you obtained LAMMPS, the doc directory has up
to 6 sub-directories, 2 Nroff files, and optionally 2 PDF files
plus 2 e-book format files:
Depending on how you obtained LAMMPS and whether you have built the
manual yourself, this directory has a number of sub-directories and
files. Here is a list with descriptions:
.. code-block:: bash
README # brief info about the documentation
src # content files for LAMMPS documentation
html # HTML version of the LAMMPS manual (see html/Manual.html)
utils # tools and settings for building the documentation
docenv # virtualenv for processing the manual sources
doctrees # temporary data from processing the manual
mathjax # code and fonts for rendering math in html
lammps.1 # man page for the lammps command
msi2lmp.1 # man page for the msi2lmp command
Manual.pdf # large PDF version of entire manual
Developer.pdf # small PDF with info about how LAMMPS is structured
LAMMPS.epub # Manual in ePUB e-book format
LAMMPS.mobi # Manual in MOBI e-book format
lammps.1 # man page for the lammps command
msi2lmp.1 # man page for the msi2lmp command
docenv # virtualenv folder for processing the manual sources
doctrees # temporary data from processing the manual
mathjax # code and fonts for rendering math in html
doxygen # doxygen configuration and output
.gitignore # list of files and folders to be ignored by git
doxygen-warn.log # logfile with warnings from running doxygen
github-development-workflow.md # notes on the LAMMPS development workflow
include-file-conventions.md # notes on LAMMPS' include file conventions
If you downloaded LAMMPS as a tarball from the web site, the html folder
and the PDF files should be included.
If you downloaded LAMMPS as a tarball from `the LAMMPS website <lws_>`_,
the html folder and the PDF files should be included.
If you downloaded LAMMPS from the public git repository, then the HTML
and PDF files are not included. Instead you need to create them, in one
of two ways:
a. You can "fetch" the current HTML and PDF files from the LAMMPS web
site. Just type "make fetch". This should download a html_www
site. Just type ``make fetch``. This should download a html_www
directory and Manual_www.pdf/Developer_www.pdf files. Note that if
new LAMMPS features have been added more recently than the date of
your LAMMPS version, the fetched documentation will include those
changes (but your source code will not, unless you update your local
repository).
b. You can build the HTML or PDF files yourself, by typing "make html"
or "make pdf". This requires various tools including Sphinx, git,
and the MathJax javascript library, which the build process will attempt
to download automatically into a virtual environment in the folder
doc/docenv and the folder mathjax, respectively, if not already available.
This download is required only once, unless you type "make clean-all".
After that, viewing and processing of the documentation can be done
without internet access. To generate the PDF version of the manual,
the PDFLaTeX software and several LaTeX packages are required as well.
However, those cannot be installed automatically at the moment.
b. You can build the HTML or PDF files yourself, by typing ``make html``
or ``make pdf``. This requires various tools and files. Some of them
have to be installed (more on that below). For the rest the build
process will attempt to download and install them into a python
virtual environment and local folders. This download is required
only once, unless you type ``make clean-all``. After that, viewing and
processing of the documentation can be done without internet access.
----------
The generation of all documentation is managed by the Makefile in
the doc directory.
The generation of all documentation is managed by the Makefile in the
doc directory. The following documentation related make commands are
available:
.. code-block:: bash
Documentation Build Options:
make html # generate HTML in html dir using Sphinx
make pdf # generate 2 PDF files (Manual.pdf,Developer.pdf)
# in doc dir via htmldoc and pdflatex
@ -62,8 +64,10 @@ the doc directory.
# as a tarball and unpack into html dir and 2 PDFs
make epub # generate LAMMPS.epub in ePUB format using Sphinx
make mobi # generate LAMMPS.mobi in MOBI format using ebook-convert
make clean # remove intermediate RST files created by HTML build
make clean-all # remove entire build folder and any cached data
make anchor_check # check for duplicate anchor labels
make style_check # check for complete and consistent style lists
make package_check # check for complete and consistent package lists
@ -74,29 +78,30 @@ the doc directory.
Installing prerequisites for HTML build
=======================================
To run the HTML documentation build toolchain, Python 3 and virtualenv
have to be installed. Here are instructions for common setups:
To run the HTML documentation build toolchain, python 3, git, doxygen,
and virtualenv have to be installed locally. Here are instructions for
common setups:
Ubuntu
------
.. code-block:: bash
sudo apt-get install python-virtualenv
sudo apt-get install python-virtualenv git doxygen
Fedora (up to version 21) and Red Hat Enterprise Linux or CentOS (up to version 7.x)
------------------------------------------------------------------------------------
.. code-block:: bash
sudo yum install python3-virtualenv
sudo yum install python3-virtualenv git doxygen
Fedora (since version 22)
-------------------------
.. code-block:: bash
sudo dnf install python3-virtualenv
sudo dnf install python3-virtualenv git doxygen
MacOS X
-------
@ -120,22 +125,92 @@ Once Python 3 is installed, open a Terminal and type
This will install virtualenv from the Python Package Index.
----------
Installing prerequisites for PDF build
======================================
Installing prerequisites for epub build
=======================================
In addition to the tools needed for building the HTML format manual,
a working LaTeX installation with support for PDFLaTeX and a selection
of LaTeX styles/packages are required.
ePUB
----
Installing prerequisites for e-book reader builds
=================================================
Same as for HTML. This uses mostly the same tools and configuration
files as the HTML tree. In addition it uses LaTeX to convert embedded
In addition to the tools needed for building the HTML format manual,
a working LaTeX installation with a few add-on LaTeX packages
as well as the ``dvipng`` tool are required to convert embedded
math expressions transparently into embedded images.
For converting the generated ePUB file to a MOBI format file
(for e-book readers, like Kindle, that cannot read ePUB), you
also need to have the 'ebook-convert' tool from the "calibre"
software installed. `http://calibre-ebook.com/ <http://calibre-ebook.com/>`_
You first create the ePUB file and then convert it with 'make mobi'
On the Kindle readers in particular, you also have support for
PDF files, so you could download and view the PDF version as an alternative.
For converting the generated ePUB file to a MOBI format file (for e-book
readers, like Kindle, that cannot read ePUB), you also need to have the
``ebook-convert`` tool from the "calibre" software
installed. `http://calibre-ebook.com/ <http://calibre-ebook.com/>`_
Typing ``make mobi`` will first create the ePUB file and then convert
it. On the Kindle readers in particular, you also have support for PDF
files, so you could download and view the PDF version as an alternative.
Instructions for Developers
===========================
When adding new styles or options to the LAMMPS code, corresponding
documentation is required and either existing files in the ``src``
folder need to be updated or new files added. These files are written
in `reStructuredText <rst_>`_ markup for translation with the Sphinx tool.
Before contributing any documentation, please check that both the HTML
and the PDF format documentation can translate without errors. Please also
check the output to the console for any warnings or problems. There will
be multiple tests run automatically:
- A test for correctness of all anchor labels and their references
- A test that all LAMMPS packages (= folders with sources in
``lammps/src``) are documented and listed. A typical warning shows
the name of the folder with the suspected new package code and the
documentation files where they need to be listed:
.. parsed-literal::
Found 33 standard and 41 user packages
Standard package NEWPACKAGE missing in Packages_standard.rst
Standard package NEWPACKAGE missing in Packages_details.rst
- A test that only standard, printable ASCII text characters are used.
This runs the command ``env LC_ALL=C grep -n '[^ -~]' src/*.rst`` and
thus prints all offending lines with filename and line number
prepended to the screen. Special characters like the Angstrom
:math:`\mathrm{\mathring{A}}` should be typeset with embedded math
(like this ``:math:`\mathrm{\mathring{A}}```\ ).
- A test whether all styles are documented and listed in their
respective overview pages. A typical output with warnings looks like this:
.. parsed-literal::
Parsed style names w/o suffixes from C++ tree in ../src:
Angle styles: 21 Atom styles: 24
Body styles: 3 Bond styles: 17
Command styles: 41 Compute styles: 143
Dihedral styles: 16 Dump styles: 26
Fix styles: 223 Improper styles: 13
Integrate styles: 4 Kspace styles: 15
Minimize styles: 9 Pair styles: 234
Reader styles: 4 Region styles: 8
Compute style entry newcomp is missing or incomplete in Commands_compute.rst
Compute style entry newcomp is missing or incomplete in compute.rst
Fix style entry newfix is missing or incomplete in Commands_fix.rst
Fix style entry newfix is missing or incomplete in fix.rst
Pair style entry new is missing or incomplete in Commands_pair.rst
Pair style entry new is missing or incomplete in pair_style.rst
Found 6 issue(s) with style lists
In addition, there is the option to run a spellcheck on the entire
manual with ``make spelling``. This requires `a library called enchant
<https://github.com/AbiWord/enchant>`_. To avoid printing out *false
positives* (e.g. keywords, names, abbreviations) those can be added to
the file ``lammps/doc/utils/sphinx-config/false_positives.txt``.
.. _rst: https://docutils.readthedocs.io/en/sphinx-docs/user/rst/quickstart.html
.. _lws: https://lammps.sandia.gov

72
doc/src/Modify_contribute.rst
View File

@ -1,37 +1,51 @@
Submitting new features for inclusion in LAMMPS
===============================================
We encourage users to submit new features or modifications for LAMMPS
to `the core developers <https://lammps.sandia.gov/authors.html>`_ so they
can be added to the LAMMPS distribution. The preferred way to manage
and coordinate this is as of Fall 2016 via the LAMMPS project on
`GitHub <https://github.com/lammps/lammps>`_. An alternative is to
contact the LAMMPS developers or the indicated developer of a package
or feature directly and send in your contribution via e-mail.
We encourage users to submit new features or modifications for LAMMPS to
`the core developers <https://lammps.sandia.gov/authors.html>`_ so they
can be added to the LAMMPS distribution. The preferred way to manage and
coordinate this is via the LAMMPS project on `GitHub
<https://github.com/lammps/lammps>`_. Please see the :doc:`GitHub
Tutorial <Howto_github>` for a demonstration on how to do that. An
alternative is to contact the LAMMPS developers or the indicated
developer of a package or feature directly and send in your contribution
via e-mail, but that can add a significant delay on getting your
contribution included, depending on how busy the developer is you
contact, how complex a task it would be to integrate that code, and how
many - if any - changes are required before the code can be included.
For any larger modifications or programming project, you are
encouraged to contact the LAMMPS developers ahead of time, in order to
discuss implementation strategies and coding guidelines, that will
make it easier to integrate your contribution and result in less work
for everybody involved. You are also encouraged to search through the
list of `open issues on GitHub <https://github.com/lammps/lammps/issues>`_ and submit a new issue
for a planned feature, so you would not duplicate the work of others
(and possibly get scooped by them) or have your work duplicated by
others.
For any larger modifications or programming project, you are encouraged
to contact the LAMMPS developers ahead of time, in order to discuss
implementation strategies and coding guidelines, that will make it
easier to integrate your contribution and result in less work for
everybody involved. You are also encouraged to search through the list
of `open issues on GitHub <https://github.com/lammps/lammps/issues>`_
and submit a new issue for a planned feature, so you would not duplicate
the work of others (and possibly get scooped by them) or have your work
duplicated by others.
How quickly your contribution will be integrated depends largely on
how much effort it will cause to integrate and test it, how much it
requires changes to the core codebase, and of how much interest it is
to the larger LAMMPS community. Please see below for a checklist of
typical requirements. Once you have prepared everything, see the
:doc:`Using GitHub with LAMMPS Howto <Howto_github>` doc page for instructions on how to
submit your changes or new files through a GitHub pull request. If you
prefer to submit patches or full files, you should first make certain,
that your code works correctly with the latest patch-level version of
LAMMPS and contains all bug fixes from it. Then create a gzipped tar
file of all changed or added files or a corresponding patch file using
'diff -u' or 'diff -c' and compress it with gzip. Please only use gzip
compression, as this works well on all platforms.
For informal communication with (some of) the LAMMPS developers you may
ask to join the `LAMMPS developers on Slack <https://lammps.slack.com>`_.
This slack work space is by invitation only. Thus for access, please
send an e-mail to ``slack@lammps.org`` explaining what part of LAMMPS
you are working on. Only discussions related to LAMMPS development are
tolerated, so this is **NOT** for people that look for help with compiling,
installing, or using LAMMPS. Please contact the `lammps-users mailing
list <https://lammps.sandia.gov>`_ for those purposes instead.
How quickly your contribution will be integrated depends largely on how
much effort it will cause to integrate and test it, how much it requires
changes to the core codebase, and of how much interest it is to the
larger LAMMPS community. Please see below for a checklist of typical
requirements. Once you have prepared everything, see the :doc:`Using
GitHub with LAMMPS Howto <Howto_github>` doc page for instructions on
how to submit your changes or new files through a GitHub pull
request. If you prefer to submit patches or full files, you should first
make certain, that your code works correctly with the latest patch-level
version of LAMMPS and contains all bug fixes from it. Then create a
gzipped tar file of all changed or added files or a corresponding patch
file using 'diff -u' or 'diff -c' and compress it with gzip. Please only
use gzip compression, as this works well on all platforms.
If the new features/files are broadly useful we may add them as core
files to LAMMPS or as part of a :doc:`standard package <Packages_standard>`. Else we will add them as a

2
doc/src/Modify_fix.rst
View File

@ -27,7 +27,7 @@ derived class. See fix.h for details.
+---------------------------+--------------------------------------------------------------------------------------------+
| setup_pre_force | called before force computation in setup (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| setup | called immediately before the 1st timestep and after forces are computed (optional) |
| setup | called immediately before the first timestep and after forces are computed (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+
| min_setup_pre_force | like setup_pre_force, but for minimizations instead of MD runs (optional) |
+---------------------------+--------------------------------------------------------------------------------------------+

12
doc/src/Modify_kspace.rst
View File

@ -10,12 +10,12 @@ Ewald.cpp is an example of computing K-space interactions.
Here is a brief description of methods you define in your new derived
class. See kspace.h for details.
+---------------+----------------------------------------------+
+---------------+------------------------------------------------+
| init | initialize the calculation before a run |
+---------------+----------------------------------------------+
| setup | computation before the 1st timestep of a run |
+---------------+----------------------------------------------+
+---------------+------------------------------------------------+
| setup | computation before the first timestep of a run |
+---------------+------------------------------------------------+
| compute | every-timestep computation |
+---------------+----------------------------------------------+
+---------------+------------------------------------------------+
| memory_usage | tally of memory usage |
+---------------+----------------------------------------------+
+---------------+------------------------------------------------+

80
doc/src/Packages_details.rst
View File

@ -44,6 +44,7 @@ page gives those details.
* :ref:`MC <PKG-MC>`
* :ref:`MESSAGE <PKG-MESSAGE>`
* :ref:`MISC <PKG-MISC>`
* :ref:`MLIAP <PKG-MLIAP>`
* :ref:`MOLECULE <PKG-MOLECULE>`
* :ref:`MPIIO <PKG-MPIIO>`
* :ref:`MSCG <PKG-MSCG>`
@ -81,6 +82,7 @@ page gives those details.
* :ref:`USER-MANIFOLD <PKG-USER-MANIFOLD>`
* :ref:`USER-MEAMC <PKG-USER-MEAMC>`
* :ref:`USER-MESODPD <PKG-USER-MESODPD>`
* :ref:`USER-MESONT <PKG-USER-MESONT>`
* :ref:`USER-MGPT <PKG-USER-MGPT>`
* :ref:`USER-MISC <PKG-USER-MISC>`
* :ref:`USER-MOFFF <PKG-USER-MOFFF>`
@ -304,7 +306,8 @@ gpu" or "-suffix gpu" :doc:`command-line switches <Run_options>`. See
also the :ref:`KOKKOS <PKG-KOKKOS>` package, which has GPU-enabled styles.
**Authors:** Mike Brown (Intel) while at Sandia and ORNL and Trung Nguyen
(Northwestern U) while at ORNL.
(Northwestern U) while at ORNL and later. AMD HIP support by Evgeny
Kuznetsov, Vladimir Stegailov, and Vsevolod Nikolskiy (HSE University).
**Install:**
@ -489,7 +492,7 @@ interactions. These include Ewald, particle-particle particle-mesh
Building with this package requires a 1d FFT library be present on
your system for use by the PPPM solvers. This can be the KISS FFT
library provided with LAMMPS, 3rd party libraries like FFTW, or a
library provided with LAMMPS, third party libraries like FFTW, or a
vendor-supplied FFT library. See the :doc:`Build settings <Build_settings>` doc page for details on how to select
different FFT options for your LAMPMS build.
@ -651,6 +654,29 @@ listing, "ls src/MISC", to see the list of commands.
----------
.. _PKG-MLIAP:
MLIAP package
-------------
**Contents:**
A general interface for machine-learning interatomic potentials.
**Install:**
To use this package, also the :ref:`SNAP package<PKG-SNAP>` needs to be installed.
**Author:** Aidan Thompson (Sandia).
**Supporting info:**
* src/MLIAP: filenames -> commands
* :doc:`pair_style mliap <pair_mliap>`
* examples/mliap
----------
.. _PKG-MOLECULE:
MOLECULE package
@ -1712,6 +1738,56 @@ algorithm.
* examples/USER/mesodpd
* https://lammps.sandia.gov/movies.html#mesodpd
* examples/USER/meso
* http://lammps.sandia.gov/movies.html#mesodpd
----------
.. _PKG-USER-MESONT:
USER-MESONT package
-------------------
**Contents:**
USER-MESONT is a LAMMPS package for simulation of nanomechanics of
nanotubes (NTs). The model is based on a coarse-grained representation
of NTs as "flexible cylinders" consisting of a variable number of
segments. Internal interactions within a NT and the van der Waals
interaction between the tubes are described by a mesoscopic force field
designed and parameterized based on the results of atomic-level
molecular dynamics simulations. The description of the force field is
provided in the papers listed below. This package contains two
independent implementations of this model: :doc:`pair_style mesocnt
<pair_mesocnt>` is a (minimal) C++ implementation, and :doc:`pair_style
mesont/tpm <pair_mesont_tpm>` is a more general and feature rich
implementation based on a Fortran library in the ``lib/mesont`` folder.
**Download of potential files:**
The potential files for these pair styles are *very* large and thus
are not included in the regular downloaded packages of LAMMPS or the
git repositories. Instead, they will be automatically downloaded
from a web server when the package is installed for the first time.
**Authors of the *mesont* styles:**
Maxim V. Shugaev (University of Virginia), Alexey N. Volkov (University of Alabama), Leonid V. Zhigilei (University of Virginia)
**Author of the *mesocnt* pair style:**
Philipp Kloza (U Cambridge)
**Supporting info:**
* src/USER-MESONT: filenames -> commands
* src/USER-MESONT/README
* :doc:`atom_style mesont <atom_style>`
* :doc:`pair_style mesont/tpm <pair_mesont_tpm>`
* :doc:`compute mesont <compute_mesont>`
* :doc:`pair_style mesocnt <pair_mesocnt>`
* examples/USER/mesont
* tools/mesont
----------
.. _PKG-USER-MOFFF:

2
doc/src/Packages_standard.rst
View File

@ -59,6 +59,8 @@ package:
+----------------------------------+--------------------------------------+----------------------------------------------------+------------------------------------------------------+---------+
| :ref:`MISC <PKG-MISC>` | miscellaneous single-file commands | n/a | no | no |
+----------------------------------+--------------------------------------+----------------------------------------------------+------------------------------------------------------+---------+
| :ref:`MLIAP <PKG-MLIAP>` | multiple machine learning potentials | :doc:`pair_style mliap <pair_mliap>` | mliap | no |
+----------------------------------+--------------------------------------+----------------------------------------------------+------------------------------------------------------+---------+
| :ref:`MOLECULE <PKG-MOLECULE>` | molecular system force fields | :doc:`Howto bioFF <Howto_bioFF>` | peptide | no |
+----------------------------------+--------------------------------------+----------------------------------------------------+------------------------------------------------------+---------+
| :ref:`MPIIO <PKG-MPIIO>` | MPI parallel I/O dump and restart | :doc:`dump <dump>` | n/a | no |

2
doc/src/Packages_user.rst
View File

@ -67,6 +67,8 @@ package:
+------------------------------------------------+-----------------------------------------------------------------+-------------------------------------------------------------------------------+------------------------------------------------------+---------+
| :ref:`USER-MESODPD <PKG-USER-MESODPD>` | mesoscale DPD models | :doc:`pair_style edpd <pair_mesodpd>` | USER/mesodpd | no |
+------------------------------------------------+-----------------------------------------------------------------+-------------------------------------------------------------------------------+------------------------------------------------------+---------+
| :ref:`USER-MESONT <PKG-USER-MESONT>` | mesoscopic tubular potential model for nanotubes | pair style :doc:`mesont/tpm <pair_mesont_tpm>`, :doc:`mesocnt <pair_mesocnt>` | USER/mesont | int |
+------------------------------------------------+-----------------------------------------------------------------+-------------------------------------------------------------------------------+------------------------------------------------------+---------+
| :ref:`USER-MGPT <PKG-USER-MGPT>` | fast MGPT multi-ion potentials | :doc:`pair_style mgpt <pair_mgpt>` | USER/mgpt | no |
+------------------------------------------------+-----------------------------------------------------------------+-------------------------------------------------------------------------------+------------------------------------------------------+---------+
| :ref:`USER-MISC <PKG-USER-MISC>` | single-file contributions | USER-MISC/README | USER/misc | no |

9
doc/src/Python_library.rst
View File

@ -254,12 +254,3 @@ following steps:
* You should now be able to invoke the new interface function from a
Python script.
----------
.. autoclass:: lammps.lammps
:members:
:no-undoc-members:
.. autoclass:: lammps.NeighList
:members:
:no-undoc-members:

2
doc/src/Python_test.rst
View File

@ -10,7 +10,7 @@ and type:
>>> lmp = lammps()
If you get no errors, you're ready to use LAMMPS from Python. If the
2nd command fails, the most common error to see is
second command fails, the most common error to see is
.. parsed-literal::

8
doc/src/Run_options.rst
View File

@ -324,17 +324,17 @@ physical processors is done by MPI before LAMMPS begins. It may be
useful in some cases to alter the rank order. E.g. to insure that
cores within each node are ranked in a desired order. Or when using
the :doc:`run_style verlet/split <run_style>` command with 2 partitions
to insure that a specific Kspace processor (in the 2nd partition) is
matched up with a specific set of processors in the 1st partition.
to insure that a specific Kspace processor (in the second partition) is
matched up with a specific set of processors in the first partition.
See the :doc:`Speed tips <Speed_tips>` doc page for more details.
If the keyword *nth* is used with a setting *N*\ , then it means every
Nth processor will be moved to the end of the ranking. This is useful
when using the :doc:`run_style verlet/split <run_style>` command with 2
partitions via the -partition command-line switch. The first set of
processors will be in the first partition, the 2nd set in the 2nd
processors will be in the first partition, the second set in the second
partition. The -reorder command-line switch can alter this so that
the 1st N procs in the 1st partition and one proc in the 2nd partition
the first N procs in the first partition and one proc in the second partition
will be ordered consecutively, e.g. as the cores on one physical node.
This can boost performance. For example, if you use "-reorder nth 4"
and "-partition 9 3" and you are running on 12 processors, the

6
doc/src/Speed_gpu.rst
View File

@ -50,6 +50,10 @@ but this can be overridden using the device option of the :doc:`package <package
command. run lammps/lib/gpu/ocl_get_devices to get a list of available
platforms and devices with a suitable ICD available.
To compute and use this package in HIP mode, you have to have the AMD ROCm
software installed. Versions of ROCm older than 3.5 are currently deprecated
by AMD.
**Building LAMMPS with the GPU package:**
See the :ref:`Build extras <gpu>` doc page for
@ -88,7 +92,7 @@ GPUs/node to 1.
Using the "-pk" switch explicitly allows for setting of the number of
GPUs/node to use and additional options. Its syntax is the same as
same as the "package gpu" command. See the :doc:`package <package>`
the "package gpu" command. See the :doc:`package <package>`
command doc page for details, including the default values used for
all its options if it is not specified.

6
doc/src/Speed_intel.rst
View File

@ -138,10 +138,10 @@ For Intel Xeon Phi co-processors (Offload):
**Required hardware/software:**
When using Intel compilers version 16.0 or later is required.
In order to use offload to co-processors, an Intel Xeon Phi
co-processor and an Intel compiler are required. For this, the
recommended version of the Intel compiler is 14.0.1.106 or
versions 15.0.2.044 and higher.
co-processor and an Intel compiler are required.
Although any compiler can be used with the USER-INTEL package,
currently, vectorization directives are disabled by default when

9
doc/src/angle_charmm.rst
View File

@ -37,7 +37,7 @@ The *charmm* angle style uses the potential
E = K (\theta - \theta_0)^2 + K_{ub} (r - r_{ub})^2
with an additional Urey_Bradley term based on the distance :math:`r` between
the 1st and 3rd atoms in the angle. :math:`K`, :math:`\theta_0`,
the first and third atoms in the angle. :math:`K`, :math:`\theta_0`,
:math:`K_{ub}`, and :math:`R_{ub}` are coefficients defined for each angle
type.
@ -49,13 +49,14 @@ The following coefficients must be defined for each angle type via the
the data file or restart files read by the :doc:`read_data <read_data>`
or :doc:`read_restart <read_restart>` commands:
* :math:`K` (energy/radian\^2)
* :math:`K` (energy)
* :math:`\theta_0` (degrees)
* :math:`K_{ub}` (energy/distance\^2)
* :math:`r_{ub}` (distance)
:math:`\theta_0` is specified in degrees, but LAMMPS converts it to radians
internally; hence the units of :math:`K` are in energy/radian\^2.
:math:`\theta_0` is specified in degrees, but LAMMPS converts it to
radians internally; hence :math:`K` is effectively energy per
radian\^2.
----------

42
doc/src/angle_class2.rst
View File

@ -41,27 +41,29 @@ The *class2* angle style uses the potential
E_{bb} & = M (r_{ij} - r_1) (r_{jk} - r_2) \\
E_{ba} & = N_1 (r_{ij} - r_1) (\theta - \theta_0) + N_2(r_{jk} - r_2)(\theta - \theta_0)
where :math:`E_a` is the angle term, :math:`E_{bb}` is a bond-bond term, and :math:`E_{ba}` is a
bond-angle term. :math:`\theta_0` is the equilibrium angle and :math:`r_1` and :math:`r_2` are
the equilibrium bond lengths.
where :math:`E_a` is the angle term, :math:`E_{bb}` is a bond-bond
term, and :math:`E_{ba}` is a bond-angle term. :math:`\theta_0` is
the equilibrium angle and :math:`r_1` and :math:`r_2` are the
equilibrium bond lengths.
See :ref:`(Sun) <angle-Sun>` for a description of the COMPASS class2 force field.
Coefficients for the :math:`E_a`, :math:`E_{bb}`, and :math:`E_{ba}` formulas must be defined for
each angle type via the :doc:`angle_coeff <angle_coeff>` command as in
the example above, or in the data file or restart files read by the
:doc:`read_data <read_data>` or :doc:`read_restart <read_restart>`
commands.
Coefficients for the :math:`E_a`, :math:`E_{bb}`, and :math:`E_{ba}`
formulas must be defined for each angle type via the :doc:`angle_coeff
<angle_coeff>` command as in the example above, or in the data file or
restart files read by the :doc:`read_data <read_data>` or
:doc:`read_restart <read_restart>` commands.
These are the 4 coefficients for the :math:`E_a` formula:
* :math:`\theta_0` (degrees)
* :math:`K_2` (energy/radian\^2)
* :math:`K_3` (energy/radian\^3)
* :math:`K_4` (energy/radian\^4)
* :math:`K_2` (energy)
* :math:`K_3` (energy)
* :math:`K_4` (energy)
:math:`\theta_0` is specified in degrees, but LAMMPS converts it to radians
internally; hence the units of the various :math:`K` are in per-radian.
:math:`\theta_0` is specified in degrees, but LAMMPS converts it to
radians internally; hence the various :math:`K` are effectively energy
per radian\^2 or radian\^3 or radian\^4.
For the :math:`E_{bb}` formula, each line in a :doc:`angle_coeff <angle_coeff>`
command in the input script lists 4 coefficients, the first of which
@ -122,11 +124,15 @@ The *class2/p6* angle style uses the *class2* potential expanded to sixth order:
In this expanded term 6 coefficients for the :math:`E_a` formula need to be set:
* :math:`\theta_0` (degrees)
* :math:`K_2` (energy/radian\^2)
* :math:`K_3` (energy/radian\^3)
* :math:`K_4` (energy/radian\^4)
* :math:`K_5` (energy/radian\^5)
* :math:`K_6` (energy/radian\^6)
* :math:`K_2` (energy)
* :math:`K_3` (energy)
* :math:`K_4` (energy)
* :math:`K_5` (energy)
* :math:`K_6` (energy)
:math:`\theta_0` is specified in degrees, but LAMMPS converts it to
radians internally; hence the various :math:`K` are effectively energy
per radian\^2 or radian\^3 or radian\^4 or radian\^5 or radian\^6.
The bond-bond and bond-angle terms remain unchanged.

4
doc/src/angle_coeff.rst
View File

@ -31,7 +31,7 @@ Angle coefficients can also be set in the data file read by the
:doc:`read_data <read_data>` command or in a restart file.
N can be specified in one of two ways. An explicit numeric value can
be used, as in the 1st example above. Or a wild-card asterisk can be
be used, as in the first example above. Or a wild-card asterisk can be
used to set the coefficients for multiple angle types. This takes the
form "\*" or "\*n" or "n\*" or "m\*n". If N = the number of angle types,
then an asterisk with no numeric values means all types from 1 to N. A
@ -53,7 +53,7 @@ same format as the arguments of the :doc:`angle_coeff <angle_coeff>` command in
script, except that wild-card asterisks should not be used since
coefficients for all N types must be listed in the file. For example,
under the "Angle Coeffs" section of a data file, the line that
corresponds to the 1st example above would be listed as
corresponds to the first example above would be listed as
.. parsed-literal::

9
doc/src/angle_cross.rst
View File

@ -40,14 +40,15 @@ the data file or restart files read by the :doc:`read_data <read_data>`
or :doc:`read_restart <read_restart>` commands:
* :math:`K_{SS}` (energy/distance\^2)
* :math:`K_{BS0}` (energy/distance/rad)
* :math:`K_{BS1}` (energy/distance/rad)
* :math:`K_{BS0}` (energy/distance)
* :math:`K_{BS1}` (energy/distance)
* :math:`r_{12,0}` (distance)
* :math:`r_{32,0}` (distance)
* :math:`\theta_0` (degrees)
:math:`\theta_0` is specified in degrees, but LAMMPS converts it to radians
internally; hence the units of :math:`K_{BS0}` and :math:`K_{BS1}` are in energy/distance/radian.
:math:`\theta_0` is specified in degrees, but LAMMPS converts it to
radians internally; hence the :math:`K_{BS0}` and :math:`K_{BS1}` are
effectively energy/distance per radian.
Restrictions
""""""""""""

15
doc/src/angle_harmonic.rst
View File

@ -44,11 +44,12 @@ The following coefficients must be defined for each angle type via the
the data file or restart files read by the :doc:`read_data <read_data>`
or :doc:`read_restart <read_restart>` commands:
* :math:`K` (energy/radian\^2)
* :math:`K` (energy)
* :math:`\theta_0` (degrees)
:math:`\theta_0` is specified in degrees, but LAMMPS converts it to radians
internally; hence the units of :math:`K` are in energy/radian\^2.
:math:`\theta_0` is specified in degrees, but LAMMPS converts it to
radians internally; hence :math:`K` is effectively energy per
radian\^2.
----------
@ -61,11 +62,13 @@ produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the :doc:`Build package <Build_package>` doc page for more info.
LAMMPS was built with those packages. See the :doc:`Build package
<Build_package>` doc page for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the :doc:`-suffix command-line switch <Run_options>` when you invoke LAMMPS, or you can use the
:doc:`suffix <suffix>` command in your input script.
by including their suffix, or you can use the :doc:`-suffix
command-line switch <Run_options>` when you invoke LAMMPS, or you can
use the :doc:`suffix <suffix>` command in your input script.
See the :doc:`Speed packages <Speed_packages>` doc page for more
instructions on how to use the accelerated styles effectively.

14
doc/src/angle_mm3.rst
View File

@ -28,20 +28,22 @@ as defined in :ref:`(Allinger) <mm3-allinger1989>`
E = K (\theta - \theta_0)^2 \left[ 1 - 0.014(\theta - \theta_0) + 5.6(10)^{-5} (\theta - \theta_0)^2 - 7.0(10)^{-7} (\theta - \theta_0)^3 + 9(10)^{-10} (\theta - \theta_0)^4 \right]
where :math:`\theta_0` is the equilibrium value of the angle, and :math:`K` is a
prefactor. The anharmonic prefactors have units :math:`\deg^{-n}`, for example
:math:`-0.014 \deg^{-1}`, :math:`5.6 \cdot 10^{-5} \deg^{-2}`, ...
where :math:`\theta_0` is the equilibrium value of the angle, and
:math:`K` is a prefactor. The anharmonic prefactors have units
:math:`\deg^{-n}`, for example :math:`-0.014 \deg^{-1}`, :math:`5.6
\cdot 10^{-5} \deg^{-2}`, ...
The following coefficients must be defined for each angle type via the
:doc:`angle_coeff <angle_coeff>` command as in the example above, or in
the data file or restart files read by the :doc:`read_data <read_data>`
or :doc:`read_restart <read_restart>` commands:
* :math:`K` (energy/radian\^2)
* :math:`K` (energy)
* :math:`\theta_0` (degrees)
:math:`\theta_0` is specified in degrees, but LAMMPS converts it to radians
internally; hence the units of :math:`K` are in energy/radian\^2.
:math:`\theta_0` is specified in degrees, but LAMMPS converts it to
radians internally; hence :math:`K` is effectively energy per
radian\^2.
Restrictions
""""""""""""

11
doc/src/angle_quartic.rst
View File

@ -39,12 +39,13 @@ the data file or restart files read by the :doc:`read_data <read_data>`
or :doc:`read_restart <read_restart>` commands:
* :math:`\theta_0` (degrees)
* :math:`K_2` (energy/radian\^2)
* :math:`K_3` (energy/radian\^3)
* :math:`K_4` (energy/radian\^4)
* :math:`K_2` (energy)
* :math:`K_3` (energy)
* :math:`K_4` (energy)
:math:`\theta_0` is specified in degrees, but LAMMPS converts it to radians
internally; hence the units of :math:`K` are in energy/radian\^2.
:math:`\theta_0` is specified in degrees, but LAMMPS converts it to
radians internally; hence the various :math:`K` are effectively energy
per radian\^2 or radian\^3 or radian\^4.
----------

15
doc/src/angle_sdk.rst
View File

@ -44,13 +44,15 @@ is included in :math:`K`.
The following coefficients must be defined for each angle type via the
:doc:`angle_coeff <angle_coeff>` command as in the example above:
* :math:`K` (energy/radian\^2)
* :math:`K` (energy)
* :math:`\theta_0` (degrees)
:math:`\theta_0` is specified in degrees, but LAMMPS converts it to radians
internally; hence the units of :math:`K` are in energy/radian\^2.
The also required *lj/sdk* parameters will be extracted automatically
from the pair_style.
:math:`\theta_0` is specified in degrees, but LAMMPS converts it to
radians internally; hence :math:`K` is effectively energy per
radian\^2.
The required *lj/sdk* parameters are extracted automatically from the
pair_style.
----------
@ -63,7 +65,8 @@ produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the :doc:`Build package <Build_package>` doc page for more info.
LAMMPS was built with those packages. See the :doc:`Build package
<Build_package>` doc page for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the :doc:`-suffix command-line switch <Run_options>` when you invoke LAMMPS, or you can use the

10
doc/src/angle_table.rst
View File

@ -75,7 +75,7 @@ parenthesized comments):
...
181 180.0 0.0 0.0
A section begins with a non-blank line whose 1st character is not a
A section begins with a non-blank line whose first character is not a
"#"; blank lines or lines starting with "#" can be used as comments
between sections. The first line begins with a keyword which
identifies the section. The line can contain additional text, but the
@ -99,7 +99,7 @@ is in the tabulated file (with effectively no preliminary
interpolation), you should set Ntable = Nfile.
The "FP" parameter is optional. If used, it is followed by two values
fplo and fphi, which are the 2nd derivatives at the innermost and
fplo and fphi, which are the second derivatives at the innermost and
outermost angle settings. These values are needed by the spline
construction routines. If not specified by the "FP" parameter, they
are estimated (less accurately) by the first two and last two
@ -110,9 +110,9 @@ equilibrium angle value, which is used, for example, by the :doc:`fix shake <fix
set to 180.0.
Following a blank line, the next N lines list the tabulated values.
On each line, the 1st value is the index from 1 to N, the 2nd value is
the angle value (in degrees), the 3rd value is the energy (in energy
units), and the 4th is -dE/d(theta) (also in energy units). The 3rd
On each line, the first value is the index from 1 to N, the second value is
the angle value (in degrees), the third value is the energy (in energy
units), and the fourth is -dE/d(theta) (also in energy units). The third
term is the energy of the 3-atom configuration for the specified
angle. The last term is the derivative of the energy with respect to
the angle (in degrees, not radians). Thus the units of the last term

2
doc/src/atc_control_momentum.rst
View File

@ -52,7 +52,7 @@ the finite element temperature. *flux* is a similar mode, but rather
adds energy to the atoms based on conservation of energy.
*correction_max_iterations* sets the maximum number of iterations to
compute the 2nd order in time correction term for lambda with the
compute the second order in time correction term for lambda with the
fractional step method. The method uses the same tolerance as the
controller's matrix solver.

2
doc/src/atc_control_thermal.rst
View File

@ -56,7 +56,7 @@ adds energy to the atoms based on conservation of energy. *hoover* and
atoms.
*correction_max_iterations* sets the maximum number of iterations to
compute the 2nd order in time correction term for lambda with the
compute the second order in time correction term for lambda with the
fractional step method. The method uses the same tolerance as the
controller's matrix solver.

4
doc/src/atc_hardy_fields.rst
View File

@ -25,8 +25,8 @@ Syntax
- temperature : temperature derived from the relative atomic kinetic energy
- kinetic_temperature : temperature derived from the full kinetic energy
- number_density : simple kernel estimation of number of atoms per unit volume
- stress : Cauchy stress tensor for eulerian analysis (atom_element_map), or 1st Piola-Kirchhoff stress tensor for lagrangian analysis
- transformed_stress : 1st Piola-Kirchhoff stress tensor for eulerian analysis (atom_element_map), or Cauchy stress tensor for lagrangian analysis
- stress : Cauchy stress tensor for eulerian analysis (atom_element_map), or first Piola-Kirchhoff stress tensor for lagrangian analysis
- transformed_stress : first Piola-Kirchhoff stress tensor for eulerian analysis (atom_element_map), or Cauchy stress tensor for lagrangian analysis
- heat_flux : spatial heat flux vector for eulerian, or referential heat flux vector for lagrangian
- potential_energy : potential energy per unit volume
- kinetic_energy : kinetic energy per unit volume

4
doc/src/atc_hardy_gradients.rst
View File

@ -23,8 +23,8 @@ Syntax
- temperature : temperature derived from the relative atomic kinetic energy
- kinetic_temperature : temperature derived from the full kinetic energy
- number_density : simple kernel estimation of number of atoms per unit volume
- stress : Cauchy stress tensor for eulerian analysis (atom_element_map), or 1st Piola-Kirchhoff stress tensor for lagrangian analysis
- transformed_stress : 1st Piola-Kirchhoff stress tensor for eulerian analysis (atom_element_map), or Cauchy stress tensor for lagrangian analysis
- stress : Cauchy stress tensor for eulerian analysis (atom_element_map), or first Piola-Kirchhoff stress tensor for lagrangian analysis
- transformed_stress : first Piola-Kirchhoff stress tensor for eulerian analysis (atom_element_map), or Cauchy stress tensor for lagrangian analysis
- heat_flux : spatial heat flux vector for eulerian, or referential heat flux vector for lagrangian
- potential_energy : potential energy per unit volume
- kinetic_energy : kinetic energy per unit volume

4
doc/src/atc_hardy_rates.rst
View File

@ -23,8 +23,8 @@ Syntax
- temperature : temperature derived from the relative atomic kinetic energy
- kinetic_temperature : temperature derived from the full kinetic energy
- number_density : simple kernel estimation of number of atoms per unit volume
- stress : Cauchy stress tensor for eulerian analysis (atom_element_map), or 1st Piola-Kirchhoff stress tensor for lagrangian analysis
- transformed_stress : 1st Piola-Kirchhoff stress tensor for eulerian analysis (atom_element_map), or Cauchy stress tensor for lagrangian analysis
- stress : Cauchy stress tensor for eulerian analysis (atom_element_map), or first Piola-Kirchhoff stress tensor for lagrangian analysis
- transformed_stress : first Piola-Kirchhoff stress tensor for eulerian analysis (atom_element_map), or Cauchy stress tensor for lagrangian analysis
- heat_flux : spatial heat flux vector for eulerian, or referential heat flux vector for lagrangian
- potential_energy : potential energy per unit volume
- kinetic_energy : kinetic energy per unit volume

18
doc/src/atc_time_integration.rst
View File

@ -33,11 +33,11 @@ Command to select the thermal or momentum time integration.
Options for thermal time integration:
*gear*
atomic velocity update with 2nd order Verlet, nodal temperature update
with 3rd or 4th order Gear, thermostats based on controlling power
atomic velocity update with second order Verlet, nodal temperature update
with third or fourth order Gear, thermostats based on controlling power
*fractional_step*
atomic velocity update with 2nd order Verlet, mixed nodal temperature
atomic velocity update with second order Verlet, mixed nodal temperature
update, 3/4 Gear for continuum and 2 Verlet for atomic contributions,
thermostats based on controlling discrete energy changes
@ -46,18 +46,18 @@ Options for thermal time integration:
Options for momentum time integration:
*verlet*
atomic velocity update with 2nd order Verlet, nodal temperature update
with 2nd order Verlet, kinetostats based on controlling force
atomic velocity update with second order Verlet, nodal temperature update
with second order Verlet, kinetostats based on controlling force
*fractional_step*
atomic velocity update with 2nd order Verlet, mixed nodal momentum
update, 2nd order Verlet for continuum and exact 2nd order Verlet for
atomic velocity update with second order Verlet, mixed nodal momentum
update, second order Verlet for continuum and exact second order Verlet for
atomic contributions, kinetostats based on controlling discrete
momentum changes
*gear*
atomic velocity update with 2nd order Verlet, nodal temperature update
with 3rd or 4th order Gear, kinetostats based on controlling power.
atomic velocity update with second order Verlet, nodal temperature update
with third or fourth order Gear, kinetostats based on controlling power.
---------

4
doc/src/atom_style.rst
View File

@ -103,6 +103,8 @@ quantities.
+--------------+-----------------------------------------------------+--------------------------------------+
| *mdpd* | density | mDPD particles |
+--------------+-----------------------------------------------------+--------------------------------------+
| *mesont* | mass, radius, length, buckling, connections, tube id| mesoscopic nanotubes |
+--------------+-----------------------------------------------------+--------------------------------------+
| *molecular* | bonds, angles, dihedrals, impropers | uncharged molecules |
+--------------+-----------------------------------------------------+--------------------------------------+
| *peri* | mass, volume | mesoscopic Peridynamic models |
@ -347,6 +349,8 @@ dynamics (tDPD), respectively.
The *sph* style is part of the USER-SPH package for smoothed particle
hydrodynamics (SPH). See `this PDF guide <USER/sph/SPH_LAMMPS_userguide.pdf>`_ to using SPH in LAMMPS.
The *mesont* style is part of the USER-MESONT package.
The *spin* style is part of the SPIN package.
The *wavepacket* style is part of the USER-AWPMD package for the

4
doc/src/bond_coeff.rst
View File

@ -32,7 +32,7 @@ Bond coefficients can also be set in the data file read by the
:doc:`read_data <read_data>` command or in a restart file.
N can be specified in one of two ways. An explicit numeric value can
be used, as in the 1st example above. Or a wild-card asterisk can be
be used, as in the first example above. Or a wild-card asterisk can be
used to set the coefficients for multiple bond types. This takes the
form "\*" or "\*n" or "n\*" or "m\*n". If N = the number of bond types,
then an asterisk with no numeric values means all types from 1 to N. A
@ -54,7 +54,7 @@ same format as the arguments of the bond_coeff command in an input
script, except that wild-card asterisks should not be used since
coefficients for all N types must be listed in the file. For example,
under the "Bond Coeffs" section of a data file, the line that
corresponds to the 1st example above would be listed as
corresponds to the first example above would be listed as
.. parsed-literal::

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