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

Merge pull request #1837 from akohlmey/collected-small-changes 

Collected small changes for the next patch release
This commit is contained in:
Axel Kohlmeyer 2020-01-15 15:34:00 -05:00 committed by GitHub
parent a57f6f5852 3cb26e576d
commit 1ed50bcdde
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
19 changed files with 257 additions and 14382 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
.github/CONTRIBUTING.md vendored
View File

@ -68,12 +68,12 @@ How quickly your contribution will be integrated depends largely on how much eff
Here is a checklist of steps you need to follow to submit a single file or user package for our consideration. Following these steps will save both you and us time. See existing files in packages in the source directory for examples. If you are uncertain, please ask on the lammps-users mailing list.
* All source files you provide must compile with the most current version of LAMMPS with multiple configurations. In particular you need to test compiling LAMMPS from scratch with `-DLAMMPS_BIGBIG` set in addition to the default `-DLAMMPS_SMALLBIG` setting. Your code will need to work correctly in serial and in parallel using MPI.
* For consistency with the rest of LAMMPS and especially, if you want your contribution(s) to be added to main LAMMPS code or one of its standard packages, it needs to be written in a style compatible with other LAMMPS source files. This means: 2-character indentation per level, no tabs, no lines over 80 characters. I/O is done via the C-style stdio library, style class header files should not import any system headers, STL containers should be avoided in headers, and forward declarations used where possible or needed. All added code should be placed into the LAMMPS_NS namespace or a sub-namespace; global or static variables should be avoided, as they conflict with the modular nature of LAMMPS and the C++ class structure. There MUST NOT be any "using namespace XXX;" statements in headers. In the implementation file (<name>.cpp) system includes should be placed in angular brackets (<>) and for c-library functions the C++ style header files should be included (<cstdio> instead of <stdio.h>, or <cstring> instead of <string.h>). This all is so the developers can more easily understand, integrate, and maintain your contribution and reduce conflicts with other parts of LAMMPS. This basically means that the code accesses data structures, performs its operations, and is formatted similar to other LAMMPS source files, including the use of the error class for error and warning messages.
* Source, style name, and documentation file should follow the following naming convention: style names should be lowercase and words separated by a forward slash; for a new fix style 'foo/bar', the class should be named FixFooBar, the name of the source files should be 'fix_foo_bar.h' and 'fix_foo_bar.cpp' and the corresponding documentation should be in a file 'fix_foo_bar.txt'.
* For consistency with the rest of LAMMPS and especially, if you want your contribution(s) to be added to main LAMMPS code or one of its standard packages, it needs to be written in a style compatible with other LAMMPS source files. This means: 2-character indentation per level, no tabs, no trailing whitespace, no lines over 80 characters. I/O is done via the C-style stdio library, style class header files should not import any system headers, STL containers should be avoided in headers, and forward declarations used where possible or needed. All added code should be placed into the LAMMPS_NS namespace or a sub-namespace; global or static variables should be avoided, as they conflict with the modular nature of LAMMPS and the C++ class structure. There MUST NOT be any "using namespace XXX;" statements in headers. In the implementation file (<name>.cpp) system includes should be placed in angular brackets (<>) and for c-library functions the C++ style header files should be included (<cstdio> instead of <stdio.h>, or <cstring> instead of <string.h>). This all is so the developers can more easily understand, integrate, and maintain your contribution and reduce conflicts with other parts of LAMMPS. This basically means that the code accesses data structures, performs its operations, and is formatted similar to other LAMMPS source files, including the use of the error class for error and warning messages.
* Source, style name, and documentation file should follow the following naming convention: style names should be lowercase and words separated by a forward slash; for a new fix style 'foo/bar', the class should be named FixFooBar, the name of the source files should be 'fix_foo_bar.h' and 'fix_foo_bar.cpp' and the corresponding documentation should be in a file 'fix_foo_bar.rst'.
* If you want your contribution to be added as a user-contributed feature, and it is a single file (actually a `<name>.cpp` and `<name>.h` file) it can be rapidly added to the USER-MISC directory. Include the one-line entry to add to the USER-MISC/README file in that directory, along with the 2 source files. You can do this multiple times if you wish to contribute several individual features.
* If you want your contribution to be added as a user-contribution and it is several related features, it is probably best to make it a user package directory with a name like USER-FOO. In addition to your new files, the directory should contain a README text file. The README should contain your name and contact information and a brief description of what your new package does. If your files depend on other LAMMPS style files also being installed (e.g. because your file is a derived class from the other LAMMPS class), then an Install.sh file is also needed to check for those dependencies. See other README and Install.sh files in other USER directories as examples. Send us a tarball of this USER-FOO directory.
* 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 simple text files with a specific markup language, that are then auto-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>.txt` files in the lammps/doc/src directory for similar commands and styles; use one or more of them as a starting point. A description of the markup can also be found in `lammps/doc/utils/txt2html/README.html` As appropriate, the text files can include links to equations (see doc/Eqs/*.tex for examples, we auto-create the associated JPG files), or figures (see doc/JPG for examples), or even additional PDF files with further details (see doc/PDF for examples). The doc page should also include literature citations as appropriate; see the bottom of doc/fix_nh.txt for examples and the earlier part of the same file for how to format the cite itself. The "Restrictions" section of the doc page should indicate that your command is only available if LAMMPS is built with the appropriate USER-MISC or USER-FOO package. See other user package doc files for examples of how to do this. The prerequisite for building the HTML format files are Python 3.x and virtualenv, the requirement for generating the PDF format manual is the htmldoc software. Please run at least "make html" and carefully inspect and proofread the resulting HTML format doc page before submitting 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). As appropriate, the text files can include mathematical expressions in MathJAX markup or links to equations (see doc/Eqs/*.tex for examples, we auto-create the associated JPG files), or figures (see doc/JPG for examples), or even additional PDF files with further details (see doc/PDF for examples). The doc page should also include literature citations as appropriate; see the bottom of doc/fix_nh.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` 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.

3
cmake/CMakeLists.txt
View File

@ -588,8 +588,9 @@ if(BUILD_TOOLS)
install(TARGETS binary2txt DESTINATION ${CMAKE_INSTALL_BINDIR})
# ninja-build currently does not support fortran. thus we skip building this tool
if(NOT CMAKE_GENERATOR STREQUAL "Ninja")
if(CMAKE_GENERATOR STREQUAL "Ninja")
message(STATUS "Skipping building 'chain.x' with Ninja build tool due to lack of Fortran support")
else()
enable_language(Fortran)
add_executable(chain.x ${LAMMPS_TOOLS_DIR}/chain.f)
target_link_libraries(chain.x ${CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES})

11
doc/github-development-workflow.md
View File

@ -104,14 +104,17 @@ Here are some items to check:
* every new command or style should have documentation. The names of
source files (c++ and manual) should follow the name of the style.
(example: `src/fix_nve.cpp`, `src/fix_nve.h` for `fix nve` command,
implementing the class `FixNVE`, documented in `doc/src/fix_nve.txt`)
implementing the class `FixNVE`, documented in `doc/src/fix_nve.rst`)
* all new style names should be lower case, the must be no dashes,
blanks, or underscores separating words, only forward slashes.
* new style docs should be added to the "overview" files in
`doc/src/Commands_*.txt`, `doc/src/{fixes,computes,pairs,bonds,...}.txt`
and `doc/src/lammps.book`
`doc/src/Commands_*.rst`, `doc/src/{fixes,computes,pairs,bonds,...}.rst`
* check whether manual cleanly translates with `make html` and `make pdf`
* if documentation is (still) provided as a .txt file, convert to .rst
and remove the .txt file. For files in doc/txt the conversion is automatic.
* remove all .txt files in `doc/txt` that are out of sync with their .rst counterparts in `doc/src`
* check spelling of manual with `make spelling` in doc folder
* check style tables and command lists with `make style_check`
* new source files in packages should be added to `src/.gitignore`
* removed or renamed files in packages should be added to `src/Purge.list`
* C++ source files should use C++ style include files for accessing
@ -136,7 +139,7 @@ Here are some items to check:
* Code should follow the C++-98 standard. C++-11 is only accepted
in individual special purpose packages
* indentation is 2 spaces per level
* there should be NO tabs and no trailing whitespace
* there should be NO tabs and no trailing whitespace (review the "checkstyle" test on pull requests)
* header files, especially of new styles, should not include any
other headers, except the header with the base class or cstdio.
Forward declarations should be used instead when possible.

25
doc/src/Howto_library.rst
View File

@ -20,6 +20,31 @@ and C and Python codes which show how a driver code can link to LAMMPS
as a library, run LAMMPS on a subset of processors, grab data from
LAMMPS, change it, and put it back into LAMMPS.
Thread-safety
-------------
LAMMPS has not initially been conceived as a thread-safe program, but
over the years changes have been applied to replace operations that
collide with creating multiple LAMMPS instances from multiple-threads
of the same process with thread-safe alternatives. This primarily
applies to the core LAMMPS code and less so on add-on packages, especially
when those packages require additional code in the *lib* folder,
interface LAMMPS to Fortran libraries, or the code uses static variables
(like the USER-COLVARS package.
Another major issue to deal with is to correctly handle MPI. Creating
a LAMMPS instance requires passing an MPI communicator, or it assumes
the MPI\_COMM\_WORLD communicator, which spans all MPI processor ranks.
When creating multiple LAMMPS object instances from different threads,
this communicator has to be different for each thread or else collisions
can happen, or it has to be guaranteed, that only one thread at a time
is active. MPI communicators, however, are not a problem, if LAMMPS is
compiled with the MPI STUBS library, which implies that there is no MPI
communication and only 1 MPI rank.
Provided APIs
-------------
The file src/library.cpp contains the following functions for creating
and destroying an instance of LAMMPS and sending it commands to
execute. See the documentation in the src/library.cpp file for

2
doc/src/python.rst
View File

@ -356,7 +356,7 @@ to the screen and log file. Note that since the LAMMPS print command
itself takes a string in quotes as its argument, the Python string
must be delimited with a different style of quotes.
The :doc:`Pytnon library <Python_library>` doc page describes the syntax
The :doc:`Python library <Python_library>` doc page describes the syntax
for how Python wraps the various functions included in the LAMMPS
library interface.

10894
doc/txt/Errors_messages.txt
View File

File diff suppressed because it is too large Load Diff

989
doc/txt/Errors_warnings.txt
View File

@ -1,989 +0,0 @@
"Higher level section"_Errors.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Warning messages :h3
This is an alphabetic list of the WARNING messages LAMMPS prints out
and the reason why. If the explanation here is not sufficient, the
documentation for the offending command may help. Warning messages
also list the source file and line number where the warning was
generated. For example, a message like this:
WARNING: Bond atom missing in box size check (domain.cpp:187) :pre
means that line #187 in the file src/domain.cpp generated the error.
Looking in the source code may help you figure out what went wrong.
Note that warning messages from "user-contributed
packages"_Packages_user.html are not listed here. If such a warning
occurs and is not self-explanatory, you'll need to look in the source
code or contact the author of the package.
Doc page with "ERROR messages"_Errors_messages.html
:line
:dlb
{Adjusting Coulombic cutoff for MSM, new cutoff = %g} :dt
The adjust/cutoff command is turned on and the Coulombic cutoff has been
adjusted to match the user-specified accuracy. :dd
{Angle atoms missing at step %ld} :dt
One or more of 3 atoms needed to compute a particular angle are
missing on this processor. Typically this is because the pairwise
cutoff is set too short or the angle has blown apart and an atom is
too far away. :dd
{Angle style in data file differs from currently defined angle style} :dt
Self-explanatory. :dd
{Angles are defined but no angle style is set} :dt
The topology contains angles, but there are no angle forces computed
since there was no angle_style command. :dd
{Atom style in data file differs from currently defined atom style} :dt
Self-explanatory. :dd
{Bond atom missing in box size check} :dt
The 2nd atoms 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. :dd
{Bond atom missing in image check} :dt
The 2nd 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. :dd
{Bond atoms missing at step %ld} :dt
The 2nd 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. :dd
{Bond style in data file differs from currently defined bond style} :dt
Self-explanatory. :dd
{Bonds are defined but no bond style is set} :dt
The topology contains bonds, but there are no bond forces computed
since there was no bond_style command. :dd
{Bond/angle/dihedral extent > half of periodic box length} :dt
This is a restriction because LAMMPS can be confused about which image
of an atom in the bonded interaction is the correct one to use.
"Extent" in this context means the maximum end-to-end length of the
bond/angle/dihedral. LAMMPS computes this by taking the maximum bond
length, multiplying by the number of bonds in the interaction (e.g. 3
for a dihedral) and adding a small amount of stretch. :dd
{Bond/react: Atom affected by reaction too close to template edge} :dt
This means an atom which changes type or connectivity during the
reaction is too close to an 'edge' atom defined in the superimpose
file. This could cause incorrect assignment of bonds, angle, etc.
Generally, this means you must include more atoms in your templates,
such that there are at least two atoms between each atom involved in
the reaction and an edge atom. :dd
{Both groups in compute group/group have a net charge; the Kspace boundary correction to energy will be non-zero} :dt
Self-explanatory. :dd
{Calling write_dump before a full system init.} :dt
The write_dump command is used before the system has been fully
initialized as part of a 'run' or 'minimize' command. Not all dump
styles and features are fully supported at this point and thus the
command may fail or produce incomplete or incorrect output. Insert
a "run 0" command, if a full system init is required. :dd
{Cannot count rigid body degrees-of-freedom before bodies are fully initialized} :dt
This means the temperature associated with the rigid bodies may be
incorrect on this timestep. :dd
{Cannot count rigid body degrees-of-freedom before bodies are initialized} :dt
This means the temperature associated with the rigid bodies may be
incorrect on this timestep. :dd
{Cannot include log terms without 1/r terms; setting flagHI to 1} :dt
Self-explanatory. :dd
{Cannot include log terms without 1/r terms; setting flagHI to 1.} :dt
Self-explanatory. :dd
{Charges are set, but coulombic solver is not used} :dt
Self-explanatory. :dd
{Charges did not converge at step %ld: %lg} :dt
Self-explanatory. :dd
{Communication cutoff is 0.0. No ghost atoms will be generated. Atoms may get lost} :dt
The communication cutoff defaults to the maximum of what is inferred from
pair and bond styles (will be zero, if none are defined) and what is specified
via "comm_modify cutoff"_comm_modify.html (defaults to 0.0). If this results
to 0.0, no ghost atoms will be generated and LAMMPS may lose atoms or use
incorrect periodic images of atoms in interaction lists. To avoid, either use
"pair style zero"_pair_zero.html with a suitable cutoff or use "comm_modify
cutoff"_comm_modify.html. :dd
{Communication cutoff is too small for SNAP micro load balancing, increased to %lf} :dt
Self-explanatory. :dd
{Compute cna/atom cutoff may be too large to find ghost atom neighbors} :dt
The neighbor cutoff used may not encompass enough ghost atoms
to perform this operation correctly. :dd
{Computing temperature of portions of rigid bodies} :dt
The group defined by the temperature compute does not encompass all
the atoms in one or more rigid bodies, so the change in
degrees-of-freedom for the atoms in those partial rigid bodies will
not be accounted for. :dd
{Create_bonds max distance > minimum neighbor cutoff} :dt
This means atom pairs for some atom types may not be in the neighbor
list and thus no bond can be created between them. :dd
{Delete_atoms cutoff > minimum neighbor cutoff} :dt
This means atom pairs for some atom types may not be in the neighbor
list and thus an atom in that pair cannot be deleted. :dd
{Dihedral atoms missing at step %ld} :dt
One or more of 4 atoms needed to compute a particular dihedral are
missing on this processor. Typically this is because the pairwise
cutoff is set too short or the dihedral has blown apart and an atom is
too far away. :dd
{Dihedral problem} :dt
Conformation of the 4 listed dihedral atoms is extreme; you may want
to check your simulation geometry. :dd
{Dihedral problem: %d %ld %d %d %d %d} :dt
Conformation of the 4 listed dihedral atoms is extreme; you may want
to check your simulation geometry. :dd
{Dihedral style in data file differs from currently defined dihedral style} :dt
Self-explanatory. :dd
{Dihedrals are defined but no dihedral style is set} :dt
The topology contains dihedrals, but there are no dihedral forces computed
since there was no dihedral_style command. :dd
{Dump dcd/xtc timestamp may be wrong with fix dt/reset} :dt
If the fix changes the timestep, the dump dcd file will not
reflect the change. :dd
{Energy due to X extra global DOFs will be included in minimizer energies} :dt
When using fixes like box/relax, the potential energy used by the minimizer
is augmented by an additional energy provided by the fix. Thus the printed
converged energy may be different from the total potential energy. :dd
{Estimated error in splitting of dispersion coeffs is %g} :dt
Error is greater than 0.0001 percent. :dd
{Ewald/disp Newton solver failed, using old method to estimate g_ewald} :dt
Self-explanatory. Choosing a different cutoff value may help. :dd
{FENE bond too long} :dt
A FENE bond has stretched dangerously far. It's interaction strength
will be truncated to attempt to prevent the bond from blowing up. :dd
{FENE bond too long: %ld %d %d %g} :dt
A FENE bond has stretched dangerously far. It's interaction strength
will be truncated to attempt to prevent the bond from blowing up. :dd
{FENE bond too long: %ld %g} :dt
A FENE bond has stretched dangerously far. It's interaction strength
will be truncated to attempt to prevent the bond from blowing up. :dd
{Fix SRD walls overlap but fix srd overlap not set} :dt
You likely want to set this in your input script. :dd
{ Fix bond/create is used multiple times or with fix bond/break - may not work as expected} :dt
When using fix bond/create multiple times or in combination with
fix bond/break, the individual fix instances do not share information
about changes they made at the same time step and thus it may result
in unexpected behavior. :dd
{Fix bond/swap will ignore defined angles} :dt
See the doc page for fix bond/swap for more info on this
restriction. :dd
{Fix deposit near setting < possible overlap separation %g} :dt
This test is performed for finite size particles with a diameter, not
for point particles. The near setting is smaller than the particle
diameter which can lead to overlaps. :dd
{Fix evaporate may delete atom with non-zero molecule ID} :dt
This is probably an error, since you should not delete only one atom
of a molecule. :dd
{Fix gcmc using full_energy option} :dt
Fix gcmc has automatically turned on the full_energy option since it
is required for systems like the one specified by the user. User input
included one or more of the following: kspace, triclinic, a hybrid
pair style, an eam pair style, or no "single" function for the pair
style. :dd
{Fix langevin gjf using random gaussians is not implemented with kokkos} :dt
This will most likely cause errors in kinetic fluctuations.
{Fix property/atom mol or charge w/out ghost communication} :dt
A model typically needs these properties defined for ghost atoms. :dd
{Fix qeq CG convergence failed (%g) after %d iterations at %ld step} :dt
Self-explanatory. :dd
{Fix qeq has non-zero lower Taper radius cutoff} :dt
Absolute value must be <= 0.01. :dd
{Fix qeq has very low Taper radius cutoff} :dt
Value should typically be >= 5.0. :dd
{Fix qeq/dynamic tolerance may be too small for damped dynamics} :dt
Self-explanatory. :dd
{Fix qeq/fire tolerance may be too small for damped fires} :dt
Self-explanatory. :dd
{Fix rattle should come after all other integration fixes} :dt
This fix is designed to work after all other integration fixes change
atom positions. Thus it should be the last integration fix specified.
If not, it will not satisfy the desired constraints as well as it
otherwise would. :dd
{Fix recenter should come after all other integration fixes} :dt
Other fixes may change the position of the center-of-mass, so
fix recenter should come last. :dd
{Fix srd SRD moves may trigger frequent reneighboring} :dt
This is because the SRD particles may move long distances. :dd
{Fix srd grid size > 1/4 of big particle diameter} :dt
This may cause accuracy problems. :dd
{Fix srd particle moved outside valid domain} :dt
This may indicate a problem with your simulation parameters. :dd
{Fix srd particles may move > big particle diameter} :dt
This may cause accuracy problems. :dd
{Fix srd viscosity < 0.0 due to low SRD density} :dt
This may cause accuracy problems. :dd
{Fixes cannot send data in Kokkos communication, switching to classic communication} :dt
This is current restriction with Kokkos. :dd
{For better accuracy use 'pair_modify table 0'} :dt
The user-specified force accuracy cannot be achieved unless the table
feature is disabled by using 'pair_modify table 0'. :dd
{Geometric mixing assumed for 1/r^6 coefficients} :dt
Self-explanatory. :dd
{Group for fix_modify temp != fix group} :dt
The fix_modify command is specifying a temperature computation that
computes a temperature on a different group of atoms than the fix
itself operates on. This is probably not what you want to do. :dd
{H matrix size has been exceeded: m_fill=%d H.m=%d\n} :dt
This is the size of the matrix. :dd
{Ignoring unknown or incorrect info command flag} :dt
Self-explanatory. An unknown argument was given to the info command.
Compare your input with the documentation. :dd
{Improper atoms missing at step %ld} :dt
One or more of 4 atoms needed to compute a particular improper are
missing on this processor. Typically this is because the pairwise
cutoff is set too short or the improper has blown apart and an atom is
too far away. :dd
{Improper problem: %d %ld %d %d %d %d} :dt
Conformation of the 4 listed improper atoms is extreme; you may want
to check your simulation geometry. :dd
{Improper style in data file differs from currently defined improper style} :dt
Self-explanatory. :dd
{Impropers are defined but no improper style is set} :dt
The topology contains impropers, but there are no improper forces computed
since there was no improper_style command. :dd
{Inconsistent image flags} :dt
The image flags for a pair on bonded atoms appear to be inconsistent.
Inconsistent means that when the coordinates of the two atoms are
unwrapped using the image flags, the two atoms are far apart.
Specifically they are further apart than half a periodic box length.
Or they are more than a box length apart in a non-periodic dimension.
This is usually due to the initial data file not having correct image
flags for the 2 atoms in a bond that straddles a periodic boundary.
They should be different by 1 in that case. This is a warning because
inconsistent image flags will not cause problems for dynamics or most
LAMMPS simulations. However they can cause problems when such atoms
are used with the fix rigid or replicate commands. Note that if you
have an infinite periodic crystal with bonds then it is impossible to
have fully consistent image flags, since some bonds will cross
periodic boundaries and connect two atoms with the same image
flag. :dd
{Increasing communication cutoff for GPU style} :dt
The pair style has increased the communication cutoff to be consistent with
the communication cutoff requirements for this pair style when run on the GPU. :dd
{KIM Model does not provide 'energy'; Potential energy will be zero} :dt
Self-explanatory. :dd
{KIM Model does not provide 'forces'; Forces will be zero} :dt
Self-explanatory. :dd
{KIM Model does not provide 'particleEnergy'; energy per atom will be zero} :dt
Self-explanatory. :dd
{KIM Model does not provide 'particleVirial'; virial per atom will be zero} :dt
Self-explanatory. :dd
{Kspace_modify slab param < 2.0 may cause unphysical behavior} :dt
The kspace_modify slab parameter should be larger to insure periodic
grids padded with empty space do not overlap. :dd
{Less insertions than requested} :dt
The fix pour command was unsuccessful at finding open space
for as many particles as it tried to insert. :dd
{Library error in lammps_gather_atoms} :dt
This library function cannot be used if atom IDs are not defined
or are not consecutively numbered. :dd
{Library error in lammps_scatter_atoms} :dt
This library function cannot be used if atom IDs are not defined or
are not consecutively numbered, or if no atom map is defined. See the
atom_modify command for details about atom maps. :dd
{Likewise 1-2 special neighbor interactions != 1.0} :dt
The topology contains bonds, but there is no bond style defined
and a 1-2 special neighbor scaling factor was not 1.0. This
means that pair style interactions may have scaled or missing
pairs in the neighbor list in expectation of interactions for
those pairs being computed from the bond style. :dd
{Likewise 1-3 special neighbor interactions != 1.0} :dt
The topology contains angles, but there is no angle style defined
and a 1-3 special neighbor scaling factor was not 1.0. This
means that pair style interactions may have scaled or missing
pairs in the neighbor list in expectation of interactions for
those pairs being computed from the angle style. :dd
{Likewise 1-4 special neighbor interactions != 1.0} :dt
The topology contains dihedrals, but there is no dihedral style defined
and a 1-4 special neighbor scaling factor was not 1.0. This
means that pair style interactions may have scaled or missing
pairs in the neighbor list in expectation of interactions for
those pairs being computed from the dihedral style. :dd
{Lost atoms via change_box: original %ld current %ld} :dt
The command options you have used caused atoms to be lost. :dd
{Lost atoms via displace_atoms: original %ld current %ld} :dt
The command options you have used caused atoms to be lost. :dd
{Lost atoms: original %ld current %ld} :dt
Lost atoms are checked for each time thermo output is done. See the
thermo_modify lost command for options. Lost atoms usually indicate
bad dynamics, e.g. atoms have been blown far out of the simulation
box, or moved further than one processor's sub-domain away before
reneighboring. :dd
{MSM mesh too small, increasing to 2 points in each direction} :dt
Self-explanatory. :dd
{Mismatch between velocity and compute groups} :dt
The temperature computation used by the velocity command will not be
on the same group of atoms that velocities are being set for. :dd
{Mixing forced for lj coefficients} :dt
Self-explanatory. :dd
{Molecule attributes do not match system attributes} :dt
An attribute is specified (e.g. diameter, charge) that is
not defined for the specified atom style. :dd
{Molecule has bond topology but no special bond settings} :dt
This means the bonded atoms will not be excluded in pair-wise
interactions. :dd
{Molecule template for create_atoms has multiple molecules} :dt
The create_atoms command will only create molecules of a single type,
i.e. the first molecule in the template. :dd
{Molecule template for fix gcmc has multiple molecules} :dt
The fix gcmc command will only create molecules of a single type,
i.e. the first molecule in the template. :dd
{Molecule template for fix shake has multiple molecules} :dt
The fix shake command will only recognize molecules of a single
type, i.e. the first molecule in the template. :dd
{More than one compute centro/atom} :dt
It is not efficient to use compute centro/atom more than once. :dd
{More than one compute cluster/atom} :dt
It is not efficient to use compute cluster/atom more than once. :dd
{More than one compute cna/atom defined} :dt
It is not efficient to use compute cna/atom more than once. :dd
{More than one compute contact/atom} :dt
It is not efficient to use compute contact/atom more than once. :dd
{More than one compute coord/atom} :dt
It is not efficient to use compute coord/atom more than once. :dd
{More than one compute damage/atom} :dt
It is not efficient to use compute ke/atom more than once. :dd
{More than one compute dilatation/atom} :dt
Self-explanatory. :dd
{More than one compute erotate/sphere/atom} :dt
It is not efficient to use compute erorate/sphere/atom more than once. :dd
{More than one compute hexorder/atom} :dt
It is not efficient to use compute hexorder/atom more than once. :dd
{More than one compute ke/atom} :dt
It is not efficient to use compute ke/atom more than once. :dd
{More than one compute orientorder/atom} :dt
It is not efficient to use compute orientorder/atom more than once. :dd
{More than one compute plasticity/atom} :dt
Self-explanatory. :dd
{More than one compute sna/atom} :dt
Self-explanatory. :dd
{More than one compute snad/atom} :dt
Self-explanatory. :dd
{More than one compute snav/atom} :dt
Self-explanatory. :dd
{More than one fix poems} :dt
It is not efficient to use fix poems more than once. :dd
{More than one fix rigid} :dt
It is not efficient to use fix rigid more than once. :dd
{Neighbor exclusions used with KSpace solver may give inconsistent Coulombic energies} :dt
This is because excluding specific pair interactions also excludes
them from long-range interactions which may not be the desired effect.
The special_bonds command handles this consistently by insuring
excluded (or weighted) 1-2, 1-3, 1-4 interactions are treated
consistently by both the short-range pair style and the long-range
solver. This is not done for exclusions of charged atom pairs via the
neigh_modify exclude command. :dd
{New thermo_style command, previous thermo_modify settings will be lost} :dt
If a thermo_style command is used after a thermo_modify command, the
settings changed by the thermo_modify command will be reset to their
default values. This is because the thermo_modify command acts on
the currently defined thermo style, and a thermo_style command creates
a new style. :dd
{No Kspace calculation with verlet/split} :dt
The 2nd partition performs a kspace calculation so the kspace_style
command must be used. :dd
{No automatic unit conversion to XTC file format conventions possible for units lj} :dt
This means no scaling will be performed. :dd
{No fixes defined, atoms won't move} :dt
If you are not using a fix like nve, nvt, npt then atom velocities and
coordinates will not be updated during timestepping. :dd
{No joints between rigid bodies, use fix rigid instead} :dt
The bodies defined by fix poems are not connected by joints. POEMS
will integrate the body motion, but it would be more efficient to use
fix rigid. :dd
{Not using real units with pair reax} :dt
This is most likely an error, unless you have created your own ReaxFF
parameter file in a different set of units. :dd
{Number of MSM mesh points changed to be a multiple of 2} :dt
MSM requires that the number of grid points in each direction be a multiple
of two and the number of grid points in one or more directions have been
adjusted to meet this requirement. :dd
{OMP_NUM_THREADS environment is not set.} :dt
This environment variable must be set appropriately to use the
USER-OMP package. :dd
{One or more atoms are time integrated more than once} :dt
This is probably an error since you typically do not want to
advance the positions or velocities of an atom more than once
per timestep. :dd
{One or more chunks do not contain all atoms in molecule} :dt
This may not be what you intended. :dd
{One or more dynamic groups may not be updated at correct point in timestep} :dt
If there are other fixes that act immediately after the initial stage
of time integration within a timestep (i.e. after atoms move), then
the command that sets up the dynamic group should appear after those
fixes. This will insure that dynamic group assignments are made
after all atoms have moved. :dd
{One or more respa levels compute no forces} :dt
This is computationally inefficient. :dd
{Pair COMB charge %.10f with force %.10f hit max barrier} :dt
Something is possibly wrong with your model. :dd
{Pair COMB charge %.10f with force %.10f hit min barrier} :dt
Something is possibly wrong with your model. :dd
{Pair brownian needs newton pair on for momentum conservation} :dt
Self-explanatory. :dd
{Pair dpd needs newton pair on for momentum conservation} :dt
Self-explanatory. :dd
{Pair dsmc: num_of_collisions > number_of_A} :dt
Collision model in DSMC is breaking down. :dd
{Pair dsmc: num_of_collisions > number_of_B} :dt
Collision model in DSMC is breaking down. :dd
{Pair style in data file differs from currently defined pair style} :dt
Self-explanatory. :dd
{Pair style restartinfo set but has no restart support} :dt
This pair style has a bug, where it does not support reading and
writing information to a restart file, but does not set the member
variable "restartinfo" to 0 as required in that case. :dd
{Particle deposition was unsuccessful} :dt
The fix deposit command was not able to insert as many atoms as
needed. The requested volume fraction may be too high, or other atoms
may be in the insertion region. :dd
{Proc sub-domain size < neighbor skin, could lead to lost atoms} :dt
The decomposition of the physical domain (likely due to load
balancing) has led to a processor's sub-domain being smaller than the
neighbor skin in one or more dimensions. Since reneighboring is
triggered by atoms moving the skin distance, this may lead to lost
atoms, if an atom moves all the way across a neighboring processor's
sub-domain before reneighboring is triggered. :dd
{Reducing PPPM order b/c stencil extends beyond nearest neighbor processor} :dt
This may lead to a larger grid than desired. See the kspace_modify overlap
command to prevent changing of the PPPM order. :dd
{Reducing PPPMDisp Coulomb order b/c stencil extends beyond neighbor processor} :dt
This may lead to a larger grid than desired. See the kspace_modify overlap
command to prevent changing of the PPPM order. :dd
{Reducing PPPMDisp dispersion order b/c stencil extends beyond neighbor processor} :dt
This may lead to a larger grid than desired. See the kspace_modify overlap
command to prevent changing of the PPPM order. :dd
{Replacing a fix, but new group != old group} :dt
The ID and style of a fix match for a fix you are changing with a fix
command, but the new group you are specifying does not match the old
group. :dd
{Replicating in a non-periodic dimension} :dt
The parameters for a replicate command will cause a non-periodic
dimension to be replicated; this may cause unwanted behavior. :dd
{Resetting reneighboring criteria during PRD} :dt
A PRD simulation requires that neigh_modify settings be delay = 0,
every = 1, check = yes. Since these settings were not in place,
LAMMPS changed them and will restore them to their original values
after the PRD simulation. :dd
{Resetting reneighboring criteria during TAD} :dt
A TAD simulation requires that neigh_modify settings be delay = 0,
every = 1, check = yes. Since these settings were not in place,
LAMMPS changed them and will restore them to their original values
after the PRD simulation. :dd
{Resetting reneighboring criteria during minimization} :dt
Minimization requires that neigh_modify settings be delay = 0, every =
1, check = yes. Since these settings were not in place, LAMMPS
changed them and will restore them to their original values after the
minimization. :dd
{Restart file used different # of processors} :dt
The restart file was written out by a LAMMPS simulation running on a
different number of processors. Due to round-off, the trajectories of
your restarted simulation may diverge a little more quickly than if
you ran on the same # of processors. :dd
{Restart file used different 3d processor grid} :dt
The restart file was written out by a LAMMPS simulation running on a
different 3d grid of processors. Due to round-off, the trajectories
of your restarted simulation may diverge a little more quickly than if
you ran on the same # of processors. :dd
{Restart file used different boundary settings, using restart file values} :dt
Your input script cannot change these restart file settings. :dd
{Restart file used different newton bond setting, using restart file value} :dt
The restart file value will override the setting in the input script. :dd
{Restart file used different newton pair setting, using input script value} :dt
The input script value will override the setting in the restart file. :dd
{Restrain problem: %d %ld %d %d %d %d} :dt
Conformation of the 4 listed dihedral atoms is extreme; you may want
to check your simulation geometry. :dd
{Running PRD with only one replica} :dt
This is allowed, but you will get no parallel speed-up. :dd
{SRD bin shifting turned on due to small lamda} :dt
This is done to try to preserve accuracy. :dd
{SRD bin size for fix srd differs from user request} :dt
Fix SRD had to adjust the bin size to fit the simulation box. See the
cubic keyword if you want this message to be an error vs warning. :dd
{SRD bins for fix srd are not cubic enough} :dt
The bin shape is not within tolerance of cubic. See the cubic
keyword if you want this message to be an error vs warning. :dd
{SRD particle %d started inside big particle %d on step %ld bounce %d} :dt
See the inside keyword if you want this message to be an error vs
warning. :dd
{SRD particle %d started inside wall %d on step %ld bounce %d} :dt
See the inside keyword if you want this message to be an error vs
warning. :dd
{Shake determinant < 0.0} :dt
The determinant of the quadratic equation being solved for a single
cluster specified by the fix shake command is numerically suspect. LAMMPS
will set it to 0.0 and continue. :dd
{Shell command '%s' failed with error '%s'} :dt
Self-explanatory. :dd
{Shell command returned with non-zero status} :dt
This may indicate the shell command did not operate as expected. :dd
{Should not allow rigid bodies to bounce off reflecting walls} :dt
LAMMPS allows this, but their dynamics are not computed correctly. :dd
{Should not use fix nve/limit with fix shake or fix rattle} :dt
This will lead to invalid constraint forces in the SHAKE/RATTLE
computation. :dd
{Simulations might be very slow because of large number of structure factors} :dt
Self-explanatory. :dd
{Slab correction not needed for MSM} :dt
Slab correction is intended to be used with Ewald or PPPM and is not needed by MSM. :dd
{System is not charge neutral, net charge = %g} :dt
The total charge on all atoms on the system is not 0.0.
For some KSpace solvers this is only a warning. :dd
{Table inner cutoff >= outer cutoff} :dt
You specified an inner cutoff for a Coulombic table that is longer
than the global cutoff. Probably not what you wanted. :dd
{Temperature for MSST is not for group all} :dt
User-assigned temperature to MSST fix does not compute temperature for
all atoms. Since MSST computes a global pressure, the kinetic energy
contribution from the temperature is assumed to also be for all atoms.
Thus the pressure used by MSST could be inaccurate. :dd
{Temperature for NPT is not for group all} :dt
User-assigned temperature to NPT fix does not compute temperature for
all atoms. Since NPT computes a global pressure, the kinetic energy
contribution from the temperature is assumed to also be for all atoms.
Thus the pressure used by NPT could be inaccurate. :dd
{Temperature for fix modify is not for group all} :dt
The temperature compute is being used with a pressure calculation
which does operate on group all, so this may be inconsistent. :dd
{Temperature for thermo pressure is not for group all} :dt
User-assigned temperature to thermo via the thermo_modify command does
not compute temperature for all atoms. Since thermo computes a global
pressure, the kinetic energy contribution from the temperature is
assumed to also be for all atoms. Thus the pressure printed by thermo
could be inaccurate. :dd
{The fix ave/spatial command has been replaced by the more flexible fix ave/chunk and compute chunk/atom commands -- fix ave/spatial will be removed in the summer of 2015} :dt
Self-explanatory. :dd
{The minimizer does not re-orient dipoles when using fix efield} :dt
This means that only the atom coordinates will be minimized,
not the orientation of the dipoles. :dd
{Too many common neighbors in CNA %d times} :dt
More than the maximum # of neighbors was found multiple times. This
was unexpected. :dd
{Too many inner timesteps in fix ttm} :dt
Self-explanatory. :dd
{Too many neighbors in CNA for %d atoms} :dt
More than the maximum # of neighbors was found multiple times. This
was unexpected. :dd
{Triclinic box skew is large} :dt
The displacement in a skewed direction is normally required to be less
than half the box length in that dimension. E.g. the xy tilt must be
between -half and +half of the x box length. You have relaxed the
constraint using the box tilt command, but the warning means that a
LAMMPS simulation may be inefficient as a result. :dd
{Use special bonds = 0,1,1 with bond style fene} :dt
Most FENE models need this setting for the special_bonds command. :dd
{Use special bonds = 0,1,1 with bond style fene/expand} :dt
Most FENE models need this setting for the special_bonds command. :dd
{Using a many-body potential with bonds/angles/dihedrals and special_bond exclusions} :dt
This is likely not what you want to do. The exclusion settings will
eliminate neighbors in the neighbor list, which the many-body potential
needs to calculated its terms correctly. :dd
{Using compute temp/deform with inconsistent fix deform remap option} :dt
Fix nvt/sllod assumes deforming atoms have a velocity profile provided
by "remap v" or "remap none" as a fix deform option. :dd
{Using compute temp/deform with no fix deform defined} :dt
This is probably an error, since it makes little sense to use
compute temp/deform in this case. :dd
{Using fix srd with box deformation but no SRD thermostat} :dt
The deformation will heat the SRD particles so this can
be dangerous. :dd
{Using kspace solver on system with no charge} :dt
Self-explanatory. :dd
{Using largest cut-off for lj/long/dipole/long long long} :dt
Self-explanatory. :dd
{Using largest cutoff for buck/long/coul/long} :dt
Self-explanatory. :dd
{Using largest cutoff for lj/long/coul/long} :dt
Self-explanatory. :dd
{Using largest cutoff for pair_style lj/long/tip4p/long} :dt
Self-explanatory. :dd
{Using package gpu without any pair style defined} :dt
Self-explanatory. :dd
{Using pair potential shift with pair_modify compute no} :dt
The shift effects will thus not be computed. :dd
{Using pair tail corrections with nonperiodic system} :dt
This is probably a bogus thing to do, since tail corrections are
computed by integrating the density of a periodic system out to
infinity. :dd
{Using pair tail corrections with pair_modify compute no} :dt
The tail corrections will thus not be computed. :dd
{pair style reax is now deprecated and will soon be retired. Users should switch to pair_style reax/c} :dt
Self-explanatory. :dd
:dle

23
doc/txt/Howto_library.txt
View File

@ -28,6 +28,29 @@ and C and Python codes which show how a driver code can link to LAMMPS
as a library, run LAMMPS on a subset of processors, grab data from
LAMMPS, change it, and put it back into LAMMPS.
Thread-safety :h4
LAMMPS has not initially been conceived as a thread-safe program, but
over the years changes have been applied to replace operations that
collide with creating multiple LAMMPS instances from multiple-threads
of the same process with thread-safe alternatives. This primarily
applies to the core LAMMPS code and less so on add-on packages, especially
when those packages require additional code in the {lib} folder,
interface LAMMPS to Fortran libraries, or the code uses static variables
(like the USER-COLVARS package.
Another major issue to deal with is to correctly handle MPI. Creating
a LAMMPS instance requires passing an MPI communicator, or it assumes
the MPI_COMM_WORLD communicator, which spans all MPI processor ranks.
When creating multiple LAMMPS object instances from different threads,
this communicator has to be different for each thread or else collisions
can happen, or it has to be guaranteed, that only one thread at a time
is active. MPI communicators, however, are not a problem, if LAMMPS is
compiled with the MPI STUBS library, which implies that there is no MPI
communication and only 1 MPI rank.
Provided APIs :h4
The file src/library.cpp contains the following functions for creating
and destroying an instance of LAMMPS and sending it commands to
execute. See the documentation in the src/library.cpp file for

474
doc/txt/fix_bond_react.txt
View File

@ -1,474 +0,0 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
fix bond/react command :h3
[Syntax:]
fix ID group-ID bond/react common_keyword values ...
react react-ID react-group-ID Nevery Rmin Rmax template-ID(pre-reacted) template-ID(post-reacted) map_file individual_keyword values ...
react react-ID react-group-ID Nevery Rmin Rmax template-ID(pre-reacted) template-ID(post-reacted) map_file individual_keyword values ...
react react-ID react-group-ID Nevery Rmin Rmax template-ID(pre-reacted) template-ID(post-reacted) map_file individual_keyword values ...
... :pre
ID, group-ID are documented in "fix"_fix.html command. Group-ID is ignored. :ulb,l
bond/react = style name of this fix command :l
the common keyword/values may be appended directly after 'bond/react' :l
this applies to all reaction specifications (below) :l
common_keyword = {stabilization} :l
{stabilization} values = {no} or {yes} {group-ID} {xmax}
{no} = no reaction site stabilization
{yes} = perform reaction site stabilization
{group-ID} = user-assigned prefix for the dynamic group of atoms not currently involved in a reaction
{xmax} = xmax value that is used by an internally-created "nve/limit"_fix_nve_limit.html integrator :pre
react = mandatory argument indicating new reaction specification :l
react-ID = user-assigned name for the reaction :l
react-group-ID = only atoms in this group are considered for the reaction :l
Nevery = attempt reaction every this many steps :l
Rmin = bonding pair atoms must be separated by more than Rmin to initiate reaction (distance units) :l
Rmax = bonding pair atoms must be separated by less than Rmax to initiate reaction (distance units) :l
template-ID(pre-reacted) = ID of a molecule template containing pre-reaction topology :l
template-ID(post-reacted) = ID of a molecule template containing post-reaction topology :l
map_file = name of file specifying corresponding atom-IDs in the pre- and post-reacted templates :l
zero or more individual keyword/value pairs may be appended to each react argument :l
individual_keyword = {prob} or {max_rxn} or {stabilize_steps} or {update_edges} :l
{prob} values = fraction seed
fraction = initiate reaction with this probability if otherwise eligible
seed = random number seed (positive integer)
{max_rxn} value = N
N = maximum number of reactions allowed to occur
{stabilize_steps} value = timesteps
timesteps = number of timesteps to apply the internally-created "nve/limit"_fix_nve_limit.html fix to reacting atoms
{update_edges} value = {none} or {charges} or {custom}
none = do not update topology near the edges of reaction templates
charges = update atomic charges of all atoms in reaction templates
custom = force the update of user-specified atomic charges :pre
:ule
[Examples:]
For unabridged example scripts and files, see examples/USER/misc/bond_react.
molecule mol1 pre_reacted_topology.txt
molecule mol2 post_reacted_topology.txt
fix 5 all bond/react react myrxn1 all 1 0 3.25 mol1 mol2 map_file.txt :pre
molecule mol1 pre_reacted_rxn1.txt
molecule mol2 post_reacted_rxn1.txt
molecule mol3 pre_reacted_rxn2.txt
molecule mol4 post_reacted_rxn2.txt
fix 5 all bond/react stabilization yes nvt_grp .03 &
react myrxn1 all 1 0 3.25 mol1 mol2 map_file_rxn1.txt prob 0.50 12345 &
react myrxn2 all 1 0 2.75 mol3 mol4 map_file_rxn2.txt prob 0.25 12345
fix 6 nvt_grp_REACT nvt temp 300 300 100 # set thermostat after bond/react :pre
[Description:]
Initiate complex covalent bonding (topology) changes. These topology
changes will be referred to as 'reactions' throughout this
documentation. Topology changes are defined in pre- and post-reaction
molecule templates and can include creation and deletion of bonds,
angles, dihedrals, impropers, bond types, angle types, dihedral types,
atom types, or atomic charges. In addition, reaction by-products or
other molecules can be identified and deleted.
Fix bond/react does not use quantum mechanical (eg. fix qmmm) or
pairwise bond-order potential (eg. Tersoff or AIREBO) methods to
determine bonding changes a priori. Rather, it uses a distance-based
probabilistic criteria to effect predetermined topology changes in
simulations using standard force fields.
This fix was created to facilitate the dynamic creation of polymeric,
amorphous or highly cross-linked systems. A suggested workflow for
using this fix is: 1) identify a reaction to be simulated 2) build a
molecule template of the reaction site before the reaction has
occurred 3) build a molecule template of the reaction site after the
reaction has occurred 4) create a map that relates the
template-atom-IDs of each atom between pre- and post-reaction molecule
templates 5) fill a simulation box with molecules and run a simulation
with fix bond/react.
Only one 'fix bond/react' command can be used at a time. Multiple
reactions can be simultaneously applied by specifying multiple {react}
arguments to a single 'fix bond/react' command. This syntax is
necessary because the 'common keywords' are applied to all reactions.
The {stabilization} keyword enables reaction site stabilization.
Reaction site stabilization is performed by including reacting atoms
in an internally-created fix "nve/limit"_fix_nve_limit.html time
integrator for a set number of timesteps given by the
{stabilize_steps} keyword. While reacting atoms are being time
integrated by the internal nve/limit, they are prevented from being
involved in any new reactions. The {xmax} value keyword should
typically be set to the maximum distance that non-reacting atoms move
during the simulation.
Fix bond/react creates and maintains two important dynamic groups of
atoms when using the {stabilization} keyword. The first group contains
all atoms currently involved in a reaction; this group is
automatically thermostatted by an internally-created
"nve/limit"_fix_nve_limit.html integrator. The second group contains
all atoms currently not involved in a reaction. This group should be
used by a thermostat in order to time integrate the system. The name
of this group of non-reacting atoms is created by appending '_REACT'
to the group-ID argument of the {stabilization} keyword, as shown in
the second example above.
NOTE: When using reaction stabilization, you should generally not have
a separate thermostat which acts on the 'all' group.
The group-ID set using the {stabilization} keyword can be an existing
static group or a previously-unused group-ID. It cannot be specified
as 'all'. If the group-ID is previously unused, the fix bond/react
command creates a "dynamic group"_group.html that is initialized to
include all atoms. If the group-ID is that of an existing static
group, the group is used as the parent group of new,
internally-created dynamic group. In both cases, this new dynamic
group is named by appending '_REACT' to the group-ID, e.g.
nvt_grp_REACT. By specifying an existing group, you may thermostat
constant-topology parts of your system separately. The dynamic group
contains only atoms not involved in a reaction at a given timestep,
and therefore should be used by a subsequent system-wide time
integrator such as nvt, npt, or nve, as shown in the second example
above (full examples can be found at examples/USER/misc/bond_react).
The time integration command should be placed after the fix bond/react
command due to the internal dynamic grouping performed by fix
bond/react.
NOTE: If the group-ID is an existing static group, react-group-IDs
should also be specified as this static group, or a subset.
The following comments pertain to each {react} argument (in other
words, can be customized for each reaction, or reaction step):
A check for possible new reaction sites is performed every {Nevery}
timesteps.
Three physical conditions must be met for a reaction to occur. First,
a bonding atom pair must be identified within the reaction distance
cutoffs. Second, the topology surrounding the bonding atom pair must
match the topology of the pre-reaction template. Finally, any reaction
constraints listed in the map file (see below) must be satisfied. If
all of these conditions are met, the reaction site is eligible to be
modified to match the post-reaction template.
A bonding atom pair will be identified if several conditions are met.
First, a pair of atoms I,J within the specified react-group-ID of type
itype and jtype must be separated by a distance between {Rmin} and
{Rmax}. It is possible that multiple bonding atom pairs are
identified: if the bonding atoms in the pre-reacted template are 1-2
neighbors, i.e. directly bonded, the farthest bonding atom partner is
set as its bonding partner; otherwise, the closest potential partner
is chosen. Then, if both an atom I and atom J have each other as their
bonding partners, these two atoms are identified as the bonding atom
pair of the reaction site. Once this unique bonding atom pair is
identified for each reaction, there could two or more reactions that
involve a given atom on the same timestep. If this is the case, only
one such reaction is permitted to occur. This reaction is chosen
randomly from all potential reactions. This capability allows e.g. for
different reaction pathways to proceed from identical reaction sites
with user-specified probabilities.
The pre-reacted molecule template is specified by a molecule command.
This molecule template file contains a sample reaction site and its
surrounding topology. As described below, the bonding atom pairs of
the pre-reacted template are specified by atom ID in the map file. The
pre-reacted molecule template should contain as few atoms as possible
while still completely describing the topology of all atoms affected
by the reaction. For example, if the force field contains dihedrals,
the pre-reacted template should contain any atom within three bonds of
reacting atoms.
Some atoms in the pre-reacted template that are not reacting may have
missing topology with respect to the simulation. For example, the
pre-reacted template may contain an atom that, in the simulation, is
currently connected to the rest of a long polymer chain. These are
referred to as edge atoms, and are also specified in the map file. All
pre-reaction template atoms should be linked to a bonding atom, via at
least one path that does not involve edge atoms. When the pre-reaction
template contains edge atoms, not all atoms, bonds, charges, etc.
specified in the reaction templates will be updated. Specifically,
topology that involves only atoms that are 'too near' to template
edges will not be updated. The definition of 'too near the edge'
depends on which interactions are defined in the simulation. If the
simulation has defined dihedrals, atoms within two bonds of edge atoms
are considered 'too near the edge.' If the simulation defines angles,
but not dihedrals, atoms within one bond of edge atoms are considered
'too near the edge.' If just bonds are defined, only edge atoms are
considered 'too near the edge.'
NOTE: Small molecules, i.e. ones that have all their atoms contained
within the reaction templates, never have edge atoms.
Note that some care must be taken when a building a molecule template
for a given simulation. All atom types in the pre-reacted template
must be the same as those of a potential reaction site in the
simulation. A detailed discussion of matching molecule template atom
types with the simulation is provided on the "molecule"_molecule.html
command page.
The post-reacted molecule template contains a sample of the reaction
site and its surrounding topology after the reaction has occurred. It
must contain the same number of atoms as the pre-reacted template. A
one-to-one correspondence between the atom IDs in the pre- and
post-reacted templates is specified in the map file as described
below. Note that during a reaction, an atom, bond, etc. type may
change to one that was previously not present in the simulation. These
new types must also be defined during the setup of a given simulation.
A discussion of correctly handling this is also provided on the
"molecule"_molecule.html command page.
NOTE: When a reaction occurs, it is possible that the resulting
topology/atom (e.g. special bonds, dihedrals, etc.) exceeds that of
the existing system and reaction templates. As when inserting
molecules, enough space for this increased topology/atom must be
reserved by using the relevant "extra" keywords to the
"read_data"_read_data.html or "create_box"_create_box.html commands.
The map file is a text document with the following format:
A map file has a header and a body. The header of map file the
contains one mandatory keyword and four optional keywords. The
mandatory keyword is 'equivalences':
N {equivalences} = # of atoms N in the reaction molecule templates :pre
The optional keywords are 'edgeIDs', 'deleteIDs', 'customIDs' and
'constraints':
N {edgeIDs} = # of edge atoms N in the pre-reacted molecule template
N {deleteIDs} = # of atoms N that are specified for deletion
N {customIDs} = # of atoms N that are specified for a custom update
N {constraints} = # of specified reaction constraints N :pre
The body of the map file contains two mandatory sections and four
optional sections. The first mandatory section begins with the keyword
'BondingIDs' and lists the atom IDs of the bonding atom pair in the
pre-reacted molecule template. The second mandatory section begins
with the keyword 'Equivalences' and lists a one-to-one correspondence
between atom IDs of the pre- and post-reacted templates. The first
column is an atom ID of the pre-reacted molecule template, and the
second column is the corresponding atom ID of the post-reacted
molecule template. The first optional section begins with the keyword
'EdgeIDs' and lists the atom IDs of edge atoms in the pre-reacted
molecule template. The second optional section begins with the keyword
'DeleteIDs' and lists the atom IDs of pre-reaction template atoms to
delete. The third optional section begins with the keyword 'Custom
Edges' and allows for forcing the update of a specific atom's atomic
charge. The first column is the ID of an atom near the edge of the
pre-reacted molecule template, and the value of the second column is
either 'none' or 'charges.' Further details are provided in the
discussion of the 'update_edges' keyword. The fourth optional section
begins with the keyword 'Constraints' and lists additional criteria
that must be satisfied in order for the reaction to occur. Currently,
there are three types of constraints available, as discussed below.
A sample map file is given below:
:line
# this is a map file :pre
7 equivalences
2 edgeIDs :pre
BondingIDs :pre
3
5 :pre
EdgeIDs :pre
1
7 :pre
Equivalences :pre
1 1
2 2
3 3
4 4
5 5
6 6
7 7 :pre
:line
Any number of additional constraints may be specified in the
Constraints section of the map file. The constraint of type 'distance'
has syntax as follows:
distance {ID1} {ID2} {rmin} {rmax} :pre
where 'distance' is the required keyword, {ID1} and {ID2} are
pre-reaction atom IDs, and these two atoms must be separated by a
distance between {rmin} and {rmax} for the reaction to occur.
The constraint of type 'angle' has the following syntax:
angle {ID1} {ID2} {ID3} {amin} {amax} :pre
where 'angle' is the required keyword, {ID1}, {ID2} and {ID3} are
pre-reaction atom IDs, and these three atoms must form an angle
between {amin} and {amax} for the reaction to occur (where {ID2} is
the central atom). Angles must be specified in degrees. This
constraint can be used to enforce a certain orientation between
reacting molecules.
The constraint of type 'arrhenius' imposes an additional reaction
probability according to the temperature-dependent Arrhenius equation:
:c,image(Eqs/fix_bond_react.jpg)
The Arrhenius constraint has the following syntax:
arrhenius {A} {n} {E_a} {seed} :pre
where 'arrhenius' is the required keyword, {A} is the pre-exponential
factor, {n} is the exponent of the temperature dependence, {E_a} is
the activation energy ("units"_units.html of energy), and {seed} is a
random number seed. The temperature is defined as the instantaneous
temperature averaged over all atoms in the reaction site, and is
calculated in the same manner as for example
"compute_temp_chunk"_compute_temp_chunk.html. Currently, there are no
options for additional temperature averaging or velocity-biased
temperature calculations. A uniform random number between 0 and 1 is
generated using {seed}; if this number is less than the result of the
Arrhenius equation above, the reaction is permitted to occur.
Once a reaction site has been successfully identified, data structures
within LAMMPS that store bond topology are updated to reflect the
post-reacted molecule template. All force fields with fixed bonds,
angles, dihedrals or impropers are supported.
A few capabilities to note: 1) You may specify as many {react}
arguments as desired. For example, you could break down a complicated
reaction mechanism into several reaction steps, each defined by its
own {react} argument. 2) While typically a bond is formed or removed
between the bonding atom pairs specified in the pre-reacted molecule
template, this is not required. 3) By reversing the order of the pre-
and post- reacted molecule templates in another {react} argument, you
can allow for the possibility of one or more reverse reactions.
The optional keywords deal with the probability of a given reaction
occurring as well as the stable equilibration of each reaction site as
it occurs:
The {prob} keyword can affect whether or not an eligible reaction
actually occurs. The fraction setting must be a value between 0.0 and
1.0. A uniform random number between 0.0 and 1.0 is generated and the
eligible reaction only occurs if the random number is less than the
fraction. Up to N reactions are permitted to occur, as optionally
specified by the {max_rxn} keyword.
The {stabilize_steps} keyword allows for the specification of how many
timesteps a reaction site is stabilized before being returned to the
overall system thermostat. In order to produce the most physical
behavior, this 'reaction site equilibration time' should be tuned to
be as small as possible while retaining stability for a given system
or reaction step. After a limited number of case studies, this number
has been set to a default of 60 timesteps. Ideally, it should be
individually tuned for each fix reaction step. Note that in some
situations, decreasing rather than increasing this parameter will
result in an increase in stability.
The {update_edges} keyword can increase the number of atoms whose
atomic charges are updated, when the pre-reaction template contains
edge atoms. When the value is set to 'charges,' all atoms' atomic
charges are updated to those specified by the post-reaction template,
including atoms near the edge of reaction templates. When the value is
set to 'custom,' an additional section must be included in the map
file that specifies whether or not to update charges, on a per-atom
basis. The format of this section is detailed above. Listing a
pre-reaction atom ID with a value of 'charges' will force the update
of the atom's charge, even if it is near a template edge. Atoms not
near a template edge are unaffected by this setting.
A few other considerations:
Many reactions result in one or more atoms that are considered
unwanted by-products. Therefore, bond/react provides the option to
delete a user-specified set of atoms. These pre-reaction atoms are
identified in the map file. A deleted atom must still be included in
the post-reaction molecule template, in which it cannot be bonded to
an atom that is not deleted. In addition to deleting unwanted reaction
by-products, this feature can be used to remove specific topologies,
such as small rings, that may be otherwise indistinguishable.
Optionally, you can enforce additional behaviors on reacting atoms.
For example, it may be beneficial to force reacting atoms to remain at
a certain temperature. For this, you can use the internally-created
dynamic group named "bond_react_MASTER_group", which consists of all
atoms currently involved in a reaction. For example, adding the
following command would add an additional thermostat to the group of
all currently-reacting atoms:
fix 1 bond_react_MASTER_group temp/rescale 1 300 300 10 1 :pre
NOTE: This command must be added after the fix bond/react command, and
will apply to all reactions.
Computationally, each timestep this fix operates, it loops over
neighbor lists (for bond-forming reactions) and computes distances
between pairs of atoms in the list. It also communicates between
neighboring processors to coordinate which bonds are created and/or
removed. All of these operations increase the cost of a timestep. Thus
you should be cautious about invoking this fix too frequently.
You can dump out snapshots of the current bond topology via the dump
local command.
:line
[Restart, fix_modify, output, run start/stop, minimize info:]
Cumulative reaction counts for each reaction are written to "binary
restart files"_restart.html. These values are associated with the
reaction name (react-ID). Additionally, internally-created per-atom
properties are stored to allow for smooth restarts. None of the
"fix_modify"_fix_modify.html options are relevant to this fix.
This fix computes one statistic for each {react} argument that it
stores in a global vector, of length 'number of react arguments', that
can be accessed by various "output commands"_Howto_output.html. The
vector values calculated by this fix are "intensive".
These is 1 quantity for each react argument:
(1) cumulative # of reactions occurred :ul
No parameter of this fix can be used with the {start/stop} keywords
of the "run"_run.html command. This fix is not invoked during "energy
minimization"_minimize.html.
When fix bond/react is 'unfixed,' all internally-created groups are
deleted. Therefore, fix bond/react can only be unfixed after unfixing
all other fixes that use any group created by fix bond/react.
[Restrictions:]
This fix is part of the USER-MISC package. It is only enabled if
LAMMPS was built with that package. See the
"Build package"_Build_package.html doc page for more info.
[Related commands:]
"fix bond/create"_fix_bond_create.html,
"fix bond/break"_fix_bond_break.html,
"fix bond/swap"_fix_bond_swap.html,
"dump local"_dump.html, "special_bonds"_special_bonds.html
[Default:]
The option defaults are stabilization = no, prob = 1.0, stabilize_steps = 60,
update_edges = none
:line
:link(Gissinger)
[(Gissinger)] Gissinger, Jensen and Wise, Polymer, 128, 211 (2017).

183
doc/txt/fix_wall_reflect.txt
View File

@ -1,183 +0,0 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
fix wall/reflect command :h3
fix wall/reflect/kk command :h3
[Syntax:]
fix ID group-ID wall/reflect face arg ... keyword value ... :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
wall/reflect = style name of this fix command :l
one or more face/arg pairs may be appended :l
face = {xlo} or {xhi} or {ylo} or {yhi} or {zlo} or {zhi} :l
{xlo},{ylo},{zlo} arg = EDGE or constant or variable
EDGE = current lo edge of simulation box
constant = number like 0.0 or -30.0 (distance units)
variable = "equal-style variable"_variable.html like v_x or v_wiggle
{xhi},{yhi},{zhi} arg = EDGE or constant or variable
EDGE = current hi edge of simulation box
constant = number like 50.0 or 100.3 (distance units)
variable = "equal-style variable"_variable.html like v_x or v_wiggle :pre
zero or more keyword/value pairs may be appended :l
keyword = {units} :l
{units} value = {lattice} or {box}
{lattice} = the wall position is defined in lattice units
{box} = the wall position is defined in simulation box units :pre
:ule
[Examples:]
fix xwalls all wall/reflect xlo EDGE xhi EDGE
fix walls all wall/reflect xlo 0.0 ylo 10.0 units box
fix top all wall/reflect zhi v_pressdown :pre
[Description:]
Bound the simulation with one or more walls which reflect particles
in the specified group when they attempt to move through them.
Reflection means that if an atom moves outside the wall on a timestep
by a distance delta (e.g. due to "fix nve"_fix_nve.html), then it is
put back inside the face by the same delta, and the sign of the
corresponding component of its velocity is flipped.
When used in conjunction with "fix nve"_fix_nve.html and "run_style
verlet"_run_style.html, the resultant time-integration algorithm is
equivalent to the primitive splitting algorithm (PSA) described by
"Bond"_#Bond1. Because each reflection event divides
the corresponding timestep asymmetrically, energy conservation is only
satisfied to O(dt), rather than to O(dt^2) as it would be for
velocity-Verlet integration without reflective walls.
Up to 6 walls or faces can be specified in a single command: {xlo},
{xhi}, {ylo}, {yhi}, {zlo}, {zhi}. A {lo} face reflects particles
that move to a coordinate less than the wall position, back in the
{hi} direction. A {hi} face reflects particles that move to a
coordinate higher than the wall position, back in the {lo} direction.
The position of each wall can be specified in one of 3 ways: as the
EDGE of the simulation box, as a constant value, or as a variable. If
EDGE is used, then the corresponding boundary of the current
simulation box is used. If a numeric constant is specified then the
wall is placed at that position in the appropriate dimension (x, y, or
z). In both the EDGE and constant cases, the wall will never move.
If the wall position is a variable, it should be specified as v_name,
where name is an "equal-style variable"_variable.html name. In this
case the variable is evaluated each timestep and the result becomes
the current position of the reflecting wall. Equal-style variables
can specify formulas with various mathematical functions, and include
"thermo_style"_thermo_style.html command keywords for the simulation
box parameters and timestep and elapsed time. Thus it is easy to
specify a time-dependent wall position.
The {units} keyword determines the meaning of the distance units used
to define a wall position, but only when a numeric constant or
variable is used. It is not relevant when EDGE is used to specify a
face position. In the variable case, the variable is assumed to
produce a value compatible with the {units} setting you specify.
A {box} value selects standard distance units as defined by the
"units"_units.html command, e.g. Angstroms for units = real or metal.
A {lattice} value means the distance units are in lattice spacings.
The "lattice"_lattice.html command must have been previously used to
define the lattice spacings.
:line
Here are examples of variable definitions that move the wall position
in a time-dependent fashion using equal-style
"variables"_variable.html.
variable ramp equal ramp(0,10)
fix 1 all wall/reflect xlo v_ramp :pre
variable linear equal vdisplace(0,20)
fix 1 all wall/reflect xlo v_linear :pre
variable wiggle equal swiggle(0.0,5.0,3.0)
fix 1 all wall/reflect xlo v_wiggle :pre
variable wiggle equal cwiggle(0.0,5.0,3.0)
fix 1 all wall/reflect xlo v_wiggle :pre
The ramp(lo,hi) function adjusts the wall position linearly from lo to
hi over the course of a run. The vdisplace(c0,velocity) function does
something similar using the equation position = c0 + velocity*delta,
where delta is the elapsed time.
The swiggle(c0,A,period) function causes the wall position to
oscillate sinusoidally according to this equation, where omega = 2 PI
/ period:
position = c0 + A sin(omega*delta) :pre
The cwiggle(c0,A,period) function causes the wall position to
oscillate sinusoidally according to this equation, which will have an
initial wall velocity of 0.0, and thus may impose a gentler
perturbation on the particles:
position = c0 + A (1 - cos(omega*delta)) :pre
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Build
package"_Build_package.html 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 "-suffix command-line
switch"_Run_options.html when you invoke LAMMPS, or you can use the
"suffix"_suffix.html command in your input script.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various "output commands"_Howto_output.html.
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command. This fix is not invoked during "energy
minimization"_minimize.html.
[Restrictions:]
Any dimension (xyz) that has a reflecting wall must be non-periodic.
A reflecting wall should not be used with rigid bodies such as those
defined by a "fix rigid" command. This is because the wall/reflect
displaces atoms directly rather than exerts a force on them. For
rigid bodies, use a soft wall instead, such as "fix
wall/lj93"_fix_wall.html. LAMMPS will flag the use of a rigid
fix with fix wall/reflect with a warning, but will not generate an
error.
[Related commands:]
"fix wall/lj93"_fix_wall.html, "fix oneway"_fix_oneway.html
[Default:] none
:line
:link(Bond1)
[(Bond)] Bond and Leimkuhler, SIAM J Sci Comput, 30, p 134 (2007).

793
doc/txt/pair_granular.txt
View File

@ -1,793 +0,0 @@
<script type="text/javascript"
src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML">
</script>
<script type="text/x-mathjax-config">
MathJax.Hub.Config({ TeX: { equationNumbers: {autoNumber: "AMS"} } });
</script>
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
pair_style granular command :h3
[Syntax:]
pair_style granular cutoff :pre
cutoff = global cutoff (optional). See discussion below. :ul
[Examples:]
pair_style granular
pair_coeff * * hooke 1000.0 50.0 tangential linear_nohistory 1.0 0.4 damping mass_velocity :pre
pair_style granular
pair_coeff * * hooke 1000.0 50.0 tangential linear_history 500.0 1.0 0.4 damping mass_velocity :pre
pair_style granular
pair_coeff * * hertz 1000.0 50.0 tangential mindlin 1000.0 1.0 0.4 :pre
pair_style granular
pair_coeff * * hertz/material 1e8 0.3 0.3 tangential mindlin_rescale NULL 1.0 0.4 damping tsuji :pre
pair_style granular
pair_coeff 1 * jkr 1000.0 500.0 0.3 10 tangential mindlin 800.0 1.0 0.5 rolling sds 500.0 200.0 0.5 twisting marshall
pair_coeff 2 2 hertz 200.0 100.0 tangential linear_history 300.0 1.0 0.1 rolling sds 200.0 100.0 0.1 twisting marshall :pre
pair_style granular
pair_coeff 1 1 dmt 1000.0 50.0 0.3 0.0 tangential mindlin NULL 0.5 0.5 rolling sds 500.0 200.0 0.5 twisting marshall
pair_coeff 2 2 dmt 1000.0 50.0 0.3 10.0 tangential mindlin NULL 0.5 0.1 rolling sds 500.0 200.0 0.1 twisting marshall :pre
[Description:]
The {granular} styles support a variety of options for the normal,
tangential, rolling and twisting forces resulting from contact between
two granular particles. This expands on the options offered by the
"pair gran/*"_pair_gran.html pair styles. The total computed forces
and torques are the sum of various models selected for the normal,
tangential, rolling and twisting modes of motion.
All model choices and parameters are entered in the
"pair_coeff"_pair_coeff.html command, as described below. Unlike
e.g. "pair gran/hooke"_pair_gran.html, coefficient values are not
global, but can be set to different values for different combinations
of particle types, as determined by the "pair_coeff"_pair_coeff.html
command. If the contact model choice is the same for two particle
types, the mixing for the cross-coefficients can be carried out
automatically. This is shown in the last example, where model
choices are the same for type 1 - type 1 as for type 2 - type2
interactions, but coefficients are different. In this case, the
mixed coefficients for type 1 - type 2 interactions can be determined from
mixing rules discussed below. For additional flexibility,
coefficients as well as model forms can vary between particle types,
as shown in the fourth example: type 1 - type 1 interactions are based
on a Johnson-Kendall-Roberts normal contact model and 2-2 interactions
are based on a DMT cohesive model (see below). In that example, 1-1
and 2-2 interactions have different model forms, in which case mixing of
coefficients cannot be determined, so 1-2 interactions must be
explicitly defined via the {pair_coeff 1 *} command, otherwise an
error would result.
:line
The first required keyword for the {pair_coeff} command is the normal
contact model. Currently supported options for normal contact models
and their required arguments are:
{hooke} : \(k_n\), \(\eta_\{n0\}\) (or \(e\))
{hertz} : \(k_n\), \(\eta_\{n0\}\) (or \(e\))
{hertz/material} : E, \(\eta_\{n0\}\) (or \(e\)), \(\nu\)
{dmt} : E, \(\eta_\{n0\}\) (or \(e\)), \(\nu\), \(\gamma\)
{jkr} : E, \(\eta_\{n0\}\) (or \(e\)), \(\nu\), \(\gamma\) :ol
Here, \(k_n\) is spring stiffness (with units that depend on model
choice, see below); \(\eta_\{n0\}\) is a damping prefactor (or, in its
place a coefficient of restitution \(e\), depending on the choice of
damping mode, see below); E is Young's modulus in units of
{force}/{length}^2, i.e. {pressure}; \(\nu\) is Poisson's ratio and
\(\gamma\) is a surface energy density, in units of
{energy}/{length}^2.
For the {hooke} model, the normal, elastic component of force acting
on particle {i} due to contact with particle {j} is given by:
\begin\{equation\}
\mathbf\{F\}_\{ne, Hooke\} = k_N \delta_\{ij\} \mathbf\{n\}
\end\{equation\}
Where \(\delta_\{ij\} = R_i + R_j - \|\mathbf\{r\}_\{ij\}\|\) is the particle
overlap, \(R_i, R_j\) are the particle radii, \(\mathbf\{r\}_\{ij\} =
\mathbf\{r\}_i - \mathbf\{r\}_j\) is the vector separating the two
particle centers (note the i-j ordering so that \(F_\{ne\}\) is
positive for repulsion), and \(\mathbf\{n\} =
\frac\{\mathbf\{r\}_\{ij\}\}\{\|\mathbf\{r\}_\{ij\}\|\}\). Therefore,
for {hooke}, the units of the spring constant \(k_n\) are
{force}/{distance}, or equivalently {mass}/{time^2}.
For the {hertz} model, the normal component of force is given by:
\begin\{equation\}
\mathbf\{F\}_\{ne, Hertz\} = k_N R_\{eff\}^\{1/2\}\delta_\{ij\}^\{3/2\} \mathbf\{n\}
\end\{equation\}
Here, \(R_\{eff\} = \frac\{R_i R_j\}\{R_i + R_j\}\) is the effective
radius, denoted for simplicity as {R} from here on. For {hertz}, the
units of the spring constant \(k_n\) are {force}/{length}^2, or
equivalently {pressure}.
For the {hertz/material} model, the force is given by:
\begin\{equation\}
\mathbf\{F\}_\{ne, Hertz/material\} = \frac\{4\}\{3\} E_\{eff\} R_\{eff\}^\{1/2\}\delta_\{ij\}^\{3/2\} \mathbf\{n\}
\end\{equation\}
Here, \(E_\{eff\} = E = \left(\frac\{1-\nu_i^2\}\{E_i\} +
\frac\{1-\nu_j^2\}\{E_j\}\right)^\{-1\}\) is the effective Young's
modulus, with \(\nu_i, \nu_j \) the Poisson ratios of the particles of
types {i} and {j}. Note that if the elastic modulus and the shear
modulus of the two particles are the same, the {hertz/material} model
is equivalent to the {hertz} model with \(k_N = 4/3 E_\{eff\}\)
The {dmt} model corresponds to the
"(Derjaguin-Muller-Toporov)"_#DMT1975 cohesive model, where the force
is simply Hertz with an additional attractive cohesion term:
\begin\{equation\}
\mathbf\{F\}_\{ne, dmt\} = \left(\frac\{4\}\{3\} E R^\{1/2\}\delta_\{ij\}^\{3/2\} - 4\pi\gamma R\right)\mathbf\{n\}
\end\{equation\}
The {jkr} model is the "(Johnson-Kendall-Roberts)"_#JKR1971 model,
where the force is computed as:
\begin\{equation\}
\label\{eq:force_jkr\}
\mathbf\{F\}_\{ne, jkr\} = \left(\frac\{4Ea^3\}\{3R\} - 2\pi a^2\sqrt\{\frac\{4\gamma E\}\{\pi a\}\}\right)\mathbf\{n\}
\end\{equation\}
Here, {a} is the radius of the contact zone, related to the overlap
\(\delta\) according to:
\begin\{equation\}
\delta = a^2/R - 2\sqrt\{\pi \gamma a/E\}
\end\{equation\}
LAMMPS internally inverts the equation above to solve for {a} in terms
of \(\delta\), then solves for the force in the previous
equation. Additionally, note that the JKR model allows for a tensile
force beyond contact (i.e. for \(\delta < 0\)), up to a maximum of
\(3\pi\gamma R\) (also known as the 'pull-off' force). Note that this
is a hysteretic effect, where particles that are not contacting
initially will not experience force until they come into contact
\(\delta \geq 0\); as they move apart and (\(\delta < 0\)), they
experience a tensile force up to \(3\pi\gamma R\), at which point they
lose contact.
:line
In addition, the normal force is augmented by a damping term of the
following general form:
\begin\{equation\}
\mathbf\{F\}_\{n,damp\} = -\eta_n \mathbf\{v\}_\{n,rel\}
\end\{equation\}
Here, \(\mathbf\{v\}_\{n,rel\} = (\mathbf\{v\}_j - \mathbf\{v\}_i)
\cdot \mathbf\{n\} \mathbf\{n\}\) is the component of relative velocity along
\(\mathbf\{n\}\).
The optional {damping} keyword to the {pair_coeff} command followed by
a keyword determines the model form of the damping factor \(\eta_n\),
and the interpretation of the \(\eta_\{n0\}\) or \(e\) coefficients
specified as part of the normal contact model settings. The {damping}
keyword and corresponding model form selection may be appended
anywhere in the {pair coeff} command. Note that the choice of damping
model affects both the normal and tangential damping (and depending on
other settings, potentially also the twisting damping). The options
for the damping model currently supported are:
{velocity}
{mass_velocity}
{viscoelastic}
{tsuji} :ol
If the {damping} keyword is not specified, the {viscoelastic} model is
used by default.
For {damping velocity}, the normal damping is simply equal to the
user-specified damping coefficient in the {normal} model:
\begin\{equation\}
\eta_n = \eta_\{n0\}
\end\{equation\}
Here, \(\eta_\{n0\}\) is the damping coefficient specified for the normal
contact model, in units of {mass}/{time}.
For {damping mass_velocity}, the normal damping is given by:
\begin\{equation\}
\eta_n = \eta_\{n0\} m_\{eff\}
\end\{equation\}
Here, \(\eta_\{n0\}\) is the damping coefficient specified for the normal
contact model, in units of {mass}/{time} and
\(m_\{eff\} = m_i m_j/(m_i + m_j)\) is the effective mass.
Use {damping mass_velocity} to reproduce the damping behavior of
{pair gran/hooke/*}.
The {damping viscoelastic} model is based on the viscoelastic
treatment of "(Brilliantov et al)"_#Brill1996, where the normal
damping is given by:
\begin\{equation\}
\eta_n = \eta_\{n0\}\ a m_\{eff\}
\end\{equation\}
Here, {a} is the contact radius, given by \(a =\sqrt\{R\delta\}\)
for all models except {jkr}, for which it is given implicitly according
to \(\delta = a^2/R - 2\sqrt\{\pi \gamma a/E\}\). For {damping viscoelastic},
\(\eta_\{n0\}\) is in units of 1/({time}*{distance}).
The {tsuji} model is based on the work of "(Tsuji et
al)"_#Tsuji1992. Here, the damping coefficient specified as part of
the normal model is interpreted as a restitution coefficient
\(e\). The damping constant \(\eta_n\) is given by:
\begin\{equation\}
\eta_n = \alpha (m_\{eff\}k_n)^\{1/2\}
\end\{equation\}
For normal contact models based on material parameters, \(k_n =
4/3Ea\). The parameter \(\alpha\) is related to the restitution
coefficient {e} according to:
\begin\{equation\}
\alpha = 1.2728-4.2783e+11.087e^2-22.348e^3+27.467e^4-18.022e^5+4.8218e^6
\end\{equation\}
The dimensionless coefficient of restitution \(e\) specified as part
of the normal contact model parameters should be between 0 and 1, but
no error check is performed on this.
The total normal force is computed as the sum of the elastic and
damping components:
\begin\{equation\}
\mathbf\{F\}_n = \mathbf\{F\}_\{ne\} + \mathbf\{F\}_\{n,damp\}
\end\{equation\}
:line
The {pair_coeff} command also requires specification of the tangential
contact model. The required keyword {tangential} is expected, followed
by the model choice and associated parameters. Currently supported
tangential model choices and their expected parameters are as follows:
{linear_nohistory} : \(x_\{\gamma,t\}\), \(\mu_s\)
{linear_history} : \(k_t\), \(x_\{\gamma,t\}\), \(\mu_s\)
{mindlin} : \(k_t\) or NULL, \(x_\{\gamma,t\}\), \(\mu_s\)
{mindlin_rescale} : \(k_t\) or NULL, \(x_\{\gamma,t\}\), \(\mu_s\) :ol
Here, \(x_\{\gamma,t\}\) is a dimensionless multiplier for the normal
damping \(\eta_n\) that determines the magnitude of the tangential
damping, \(\mu_t\) is the tangential (or sliding) friction
coefficient, and \(k_t\) is the tangential stiffness coefficient.
For {tangential linear_nohistory}, a simple velocity-dependent Coulomb
friction criterion is used, which mimics the behavior of the {pair
gran/hooke} style. The tangential force (\mathbf\{F\}_t\) is given by:
\begin\{equation\}
\mathbf\{F\}_t = -min(\mu_t F_\{n0\}, \|\mathbf\{F\}_\mathrm\{t,damp\}\|) \mathbf\{t\}
\end\{equation\}
The tangential damping force \(\mathbf\{F\}_\mathrm\{t,damp\}\) is given by:
\begin\{equation\}
\mathbf\{F\}_\mathrm\{t,damp\} = -\eta_t \mathbf\{v\}_\{t,rel\}
\end\{equation\}
The tangential damping prefactor \(\eta_t\) is calculated by scaling
the normal damping \(\eta_n\) (see above):
\begin\{equation\}
\eta_t = -x_\{\gamma,t\} \eta_n
\end\{equation\}
The normal damping prefactor \(\eta_n\) is determined by the choice
of the {damping} keyword, as discussed above. Thus, the {damping}
keyword also affects the tangential damping. The parameter
\(x_\{\gamma,t\}\) is a scaling coefficient. Several works in the
literature use \(x_\{\gamma,t\} = 1\) ("Marshall"_#Marshall2009,
"Tsuji et al"_#Tsuji1992, "Silbert et al"_#Silbert2001). The relative
tangential velocity at the point of contact is given by
\(\mathbf\{v\}_\{t, rel\} = \mathbf\{v\}_\{t\} - (R_i\Omega_i +
R_j\Omega_j) \times \mathbf\{n\}\), where \(\mathbf\{v\}_\{t\} =
\mathbf\{v\}_r - \mathbf\{v\}_r\cdot\mathbf\{n\}\{n\}\),
\(\mathbf\{v\}_r = \mathbf\{v\}_j - \mathbf\{v\}_i\).
The direction of the applied force is \(\mathbf\{t\} =
\mathbf\{v_\{t,rel\}\}/\|\mathbf\{v_\{t,rel\}\}\|\) .
The normal force value \(F_\{n0\}\) used to compute the critical force
depends on the form of the contact model. For non-cohesive models
({hertz}, {hertz/material}, {hooke}), it is given by the magnitude of
the normal force:
\begin\{equation\}
F_\{n0\} = \|\mathbf\{F\}_n\|
\end\{equation\}
For cohesive models such as {jkr} and {dmt}, the critical force is
adjusted so that the critical tangential force approaches \(\mu_t
F_\{pulloff\}\), see "Marshall"_#Marshall2009, equation 43, and
"Thornton"_#Thornton1991. For both models, \(F_\{n0\}\) takes the
form:
\begin\{equation\}
F_\{n0\} = \|\mathbf\{F\}_ne + 2 F_\{pulloff\}\|
\end\{equation\}
Where \(F_\{pulloff\} = 3\pi \gamma R \) for {jkr}, and
\(F_\{pulloff\} = 4\pi \gamma R \) for {dmt}.
The remaining tangential options all use accumulated tangential
displacement (i.e. contact history). This is discussed below in the
context of the {linear_history} option, but the same treatment of the
accumulated displacement applies to the other options as well.
For {tangential linear_history}, the tangential force is given by:
\begin\{equation\}
\mathbf\{F\}_t = -min(\mu_t F_\{n0\}, \|-k_t\mathbf\{\xi\} + \mathbf\{F\}_\mathrm\{t,damp\}\|) \mathbf\{t\}
\end\{equation\}
Here, \(\mathbf\{\xi\}\) is the tangential displacement accumulated
during the entire duration of the contact:
\begin\{equation\}
\mathbf\{\xi\} = \int_\{t0\}^t \mathbf\{v\}_\{t,rel\}(\tau) \mathrm\{d\}\tau
\end\{equation\}
This accumulated tangential displacement must be adjusted to account
for changes in the frame of reference of the contacting pair of
particles during contact. This occurs due to the overall motion of the
contacting particles in a rigid-body-like fashion during the duration
of the contact. There are two modes of motion that are relevant: the
'tumbling' rotation of the contacting pair, which changes the
orientation of the plane in which tangential displacement occurs; and
'spinning' rotation of the contacting pair about the vector connecting
their centers of mass (\(\mathbf\{n\}\)). Corrections due to the
former mode of motion are made by rotating the accumulated
displacement into the plane that is tangential to the contact vector
at each step, or equivalently removing any component of the tangential
displacement that lies along \(\mathbf\{n\}\), and rescaling to
preserve the magnitude. This follows the discussion in
"Luding"_#Luding2008, see equation 17 and relevant discussion in that
work:
\begin\{equation\}
\mathbf\{\xi\} = \left(\mathbf\{\xi'\} - (\mathbf\{n\} \cdot \mathbf\{\xi'\})\mathbf\{n\}\right) \frac\{\|\mathbf\{\xi'\}\|\}\{\|\mathbf\{\xi'\}\| - \mathbf\{n\}\cdot\mathbf\{\xi'\}\}
\label\{eq:rotate_displacements\}
\end\{equation\}
Here, \(\mathbf\{\xi'\}\) is the accumulated displacement prior to the
current time step and \(\mathbf\{\xi\}\) is the corrected
displacement. Corrections to the displacement due to the second mode
of motion described above (rotations about \(\mathbf\{n\}\)) are not
currently implemented, but are expected to be minor for most
simulations.
Furthermore, when the tangential force exceeds the critical force, the
tangential displacement is re-scaled to match the value for the
critical force (see "Luding"_#Luding2008, equation 20 and related
discussion):
\begin\{equation\}
\mathbf\{\xi\} = -\frac\{1\}\{k_t\}\left(\mu_t F_\{n0\}\mathbf\{t\} + \mathbf\{F\}_\{t,damp\}\right)
\end\{equation\}
The tangential force is added to the total normal force (elastic plus
damping) to produce the total force on the particle. The tangential
force also acts at the contact point (defined as the center of the
overlap region) to induce a torque on each particle according to:
\begin\{equation\}
\mathbf\{\tau\}_i = -(R_i - 0.5 \delta) \mathbf\{n\} \times \mathbf\{F\}_t
\end\{equation\}
\begin\{equation\}
\mathbf\{\tau\}_j = -(R_j - 0.5 \delta) \mathbf\{n\} \times \mathbf\{F\}_t
\end\{equation\}
For {tangential mindlin}, the "Mindlin"_#Mindlin1949 no-slip solution is used, which differs from the {linear_history}
option by an additional factor of {a}, the radius of the contact region. The tangential force is given by:
\begin\{equation\}
\mathbf\{F\}_t = -min(\mu_t F_\{n0\}, \|-k_t a \mathbf\{\xi\} + \mathbf\{F\}_\mathrm\{t,damp\}\|) \mathbf\{t\}
\end\{equation\}
Here, {a} is the radius of the contact region, given by \(a =\sqrt\{R\delta\}\)
for all normal contact models, except for {jkr}, where it is given
implicitly by \(\delta = a^2/R - 2\sqrt\{\pi \gamma a/E\}\), see
discussion above. To match the Mindlin solution, one should set \(k_t
= 8G\), where \(G\) is the shear modulus, related to Young's modulus
\(E\) by \(G = E/(2(1+\nu))\), where \(\nu\) is Poisson's ratio. This
can also be achieved by specifying {NULL} for \(k_t\), in which case a
normal contact model that specifies material parameters \(E\) and
\(\nu\) is required (e.g. {hertz/material}, {dmt} or {jkr}). In this
case, mixing of the shear modulus for different particle types {i} and
{j} is done according to:
\begin\{equation\}
1/G = 2(2-\nu_i)(1+\nu_i)/E_i + 2(2-\nu_j)(1+\nu_j)/E_j
\end\{equation\}
The {mindlin_rescale} option uses the same form as {mindlin}, but the
magnitude of the tangential displacement is re-scaled as the contact
unloads, i.e. if \(a < a_\{t_\{n-1\}\}\):
\begin\{equation\}
\mathbf\{\xi\} = \mathbf\{\xi_\{t_\{n-1\}\}\} \frac\{a\}\{a_\{t_\{n-1\}\}\}
\end\{equation\}
Here, \(t_\{n-1\}\) indicates the value at the previous time
step. This rescaling accounts for the fact that a decrease in the
contact area upon unloading leads to the contact being unable to
support the previous tangential loading, and spurious energy is
created without the rescaling above ("Walton"_#WaltonPC ). See also
discussion in "Thornton et al, 2013"_#Thornton2013 , particularly
equation 18(b) of that work and associated discussion.
:line
The optional {rolling} keyword enables rolling friction, which resists
pure rolling motion of particles. The options currently supported are:
{none}
{sds} : \(k_\{roll\}\), \(\gamma_\{roll\}\), \(\mu_\{roll\}\) :ol
If the {rolling} keyword is not specified, the model defaults to {none}.
For {rolling sds}, rolling friction is computed via a
spring-dashpot-slider, using a 'pseudo-force' formulation, as detailed
by "Luding"_#Luding2008. Unlike the formulation in
"Marshall"_#Marshall2009, this allows for the required adjustment of
rolling displacement due to changes in the frame of reference of the
contacting pair. The rolling pseudo-force is computed analogously to
the tangential force:
\begin\{equation\}
\mathbf\{F\}_\{roll,0\} = k_\{roll\} \mathbf\{\xi\}_\{roll\} - \gamma_\{roll\} \mathbf\{v\}_\{roll\}
\end\{equation\}
Here, \(\mathbf\{v\}_\{roll\} = -R(\mathbf\{\Omega\}_i -
\mathbf\{\Omega\}_j) \times \mathbf\{n\}\) is the relative rolling
velocity, as given in "Wang et al"_#Wang2015 and
"Luding"_#Luding2008. This differs from the expressions given by "Kuhn
and Bagi"_#Kuhn2004 and used in "Marshall"_#Marshall2009; see "Wang et
al"_#Wang2015 for details. The rolling displacement is given by:
\begin\{equation\}
\mathbf\{\xi\}_\{roll\} = \int_\{t_0\}^t \mathbf\{v\}_\{roll\} (\tau) \mathrm\{d\} \tau
\end\{equation\}
A Coulomb friction criterion truncates the rolling pseudo-force if it
exceeds a critical value:
\begin\{equation\}
\mathbf\{F\}_\{roll\} = min(\mu_\{roll\} F_\{n,0\}, \|\mathbf\{F\}_\{roll,0\}\|)\mathbf\{k\}
\end\{equation\}
Here, \(\mathbf\{k\} =
\mathbf\{v\}_\{roll\}/\|\mathbf\{v\}_\{roll\}\|\) is the direction of
the pseudo-force. As with tangential displacement, the rolling
displacement is rescaled when the critical force is exceeded, so that
the spring length corresponds the critical force. Additionally, the
displacement is adjusted to account for rotations of the frame of
reference of the two contacting particles in a manner analogous to the
tangential displacement.
The rolling pseudo-force does not contribute to the total force on
either particle (hence 'pseudo'), but acts only to induce an equal and
opposite torque on each particle, according to:
\begin\{equation\}
\tau_\{roll,i\} = R_\{eff\} \mathbf\{n\} \times \mathbf\{F\}_\{roll\}
\end\{equation\}
\begin\{equation\}
\tau_\{roll,j\} = -\tau_\{roll,i\}
\end\{equation\}
:line
The optional {twisting} keyword enables twisting friction, which
resists rotation of two contacting particles about the vector
\(\mathbf\{n\}\) that connects their centers. The options currently
supported are:
{none}
{sds} : \(k_\{twist\}\), \(\gamma_\{twist\}\), \(\mu_\{twist\}\)
{marshall} :ol
If the {twisting} keyword is not specified, the model defaults to {none}.
For both {twisting sds} and {twisting marshall}, a history-dependent
spring-dashpot-slider is used to compute the twisting torque. Because
twisting displacement is a scalar, there is no need to adjust for
changes in the frame of reference due to rotations of the particle
pair. The formulation in "Marshall"_#Marshall2009 therefore provides
the most straightforward treatment:
\begin\{equation\}
\tau_\{twist,0\} = -k_\{twist\}\xi_\{twist\} - \gamma_\{twist\}\Omega_\{twist\}
\end\{equation\}
Here \(\xi_\{twist\} = \int_\{t_0\}^t \Omega_\{twist\} (\tau)
\mathrm\{d\}\tau\) is the twisting angular displacement, and
\(\Omega_\{twist\} = (\mathbf\{\Omega\}_i - \mathbf\{\Omega\}_j) \cdot
\mathbf\{n\}\) is the relative twisting angular velocity. The torque
is then truncated according to:
\begin\{equation\}
\tau_\{twist\} = min(\mu_\{twist\} F_\{n,0\}, \tau_\{twist,0\})
\end\{equation\}
Similar to the sliding and rolling displacement, the angular
displacement is rescaled so that it corresponds to the critical value
if the twisting torque exceeds this critical value:
\begin\{equation\}
\xi_\{twist\} = \frac\{1\}\{k_\{twist\}\} (\mu_\{twist\} F_\{n,0\}sgn(\Omega_\{twist\}) - \gamma_\{twist\}\Omega_\{twist\})
\end\{equation\}
For {twisting sds}, the coefficients \(k_\{twist\}, \gamma_\{twist\}\)
and \(\mu_\{twist\}\) are simply the user input parameters that follow
the {twisting sds} keywords in the {pair_coeff} command.
For {twisting_marshall}, the coefficients are expressed in terms of
sliding friction coefficients, as discussed in
"Marshall"_#Marshall2009 (see equations 32 and 33 of that work):
\begin\{equation\}
k_\{twist\} = 0.5k_ta^2
\end\{equation\}
\begin\{equation\}
\eta_\{twist\} = 0.5\eta_ta^2
\end\{equation\}
\begin\{equation\}
\mu_\{twist\} = \frac\{2\}\{3\}a\mu_t
\end\{equation\}
Finally, the twisting torque on each particle is given by:
\begin\{equation\}
\mathbf\{\tau\}_\{twist,i\} = \tau_\{twist\}\mathbf\{n\}
\end\{equation\}
\begin\{equation\}
\mathbf\{\tau\}_\{twist,j\} = -\mathbf\{\tau\}_\{twist,i\}
\end\{equation\}
:line
The {granular} pair style can reproduce the behavior of the
{pair gran/*} styles with the appropriate settings (some very
minor differences can be expected due to corrections in
displacement history frame-of-reference, and the application
of the torque at the center of the contact rather than
at each particle). The first example above
is equivalent to {pair gran/hooke 1000.0 NULL 50.0 50.0 0.4 1}.
The second example is equivalent to
{pair gran/hooke/history 1000.0 500.0 50.0 50.0 0.4 1}.
The third example is equivalent to
{pair gran/hertz/history 1000.0 500.0 50.0 50.0 0.4 1}.
:line
LAMMPS automatically sets pairwise cutoff values for {pair_style
granular} based on particle radii (and in the case of {jkr} pull-off
distances). In the vast majority of situations, this is adequate.
However, a cutoff value can optionally be appended to the {pair_style
granular} command to specify a global cutoff (i.e. a cutoff for all
atom types). Additionally, the optional {cutoff} keyword can be passed
to the {pair_coeff} command, followed by a cutoff value. This will
set a pairwise cutoff for the atom types in the {pair_coeff} command.
These options may be useful in some rare cases where the automatic
cutoff determination is not sufficient, e.g. if particle diameters
are being modified via the {fix adapt} command. In that case, the
global cutoff specified as part of the {pair_style granular} command
is applied to all atom types, unless it is overridden for a given atom
type combination by the {cutoff} value specified in the {pair coeff}
command. If {cutoff} is only specified in the {pair coeff} command
and no global cutoff is appended to the {pair_style granular} command,
then LAMMPS will use that cutoff for the specified atom type
combination, and automatically set pairwise cutoffs for the remaining
atom types.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Build
package"_Build_package.html 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 "-suffix command-line
switch"_Run_options.html when you invoke LAMMPS, or you can use the
"suffix"_suffix.html command in your input script.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
The "pair_modify"_pair_modify.html mix, shift, table, and tail options
are not relevant for granular pair styles.
Mixing of coefficients is carried out using geometric averaging for
most quantities, e.g. if friction coefficient for type 1-type 1
interactions is set to \(\mu_1\), and friction coefficient for type
2-type 2 interactions is set to \(\mu_2\), the friction coefficient
for type1-type2 interactions is computed as \(\sqrt\{\mu_1\mu_2\}\)
(unless explicitly specified to a different value by a {pair_coeff 1 2
...} command). The exception to this is elastic modulus, only
applicable to {hertz/material}, {dmt} and {jkr} normal contact
models. In that case, the effective elastic modulus is computed as:
\begin\{equation\}
E_\{eff,ij\} = \left(\frac\{1-\nu_i^2\}\{E_i\} + \frac\{1-\nu_j^2\}\{E_j\}\right)^\{-1\}
\end\{equation\}
If the {i-j} coefficients \(E_\{ij\}\) and \(\nu_\{ij\}\) are
explicitly specified, the effective modulus is computed as:
\begin\{equation\}
E_\{eff,ij\} = \left(\frac\{1-\nu_\{ij\}^2\}\{E_\{ij\}\} + \frac\{1-\nu_\{ij\}^2\}\{E_\{ij\}\}\right)^\{-1\}
\end\{equation\}
or
\begin\{equation\}
E_\{eff,ij\} = \frac\{E_\{ij\}\}\{2(1-\nu_\{ij\})\}
\end\{equation\}
These pair styles write their information to "binary restart
files"_restart.html, so a pair_style command does not need to be
specified in an input script that reads a restart file.
These pair styles can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. They do not support the
{inner}, {middle}, {outer} keywords.
The single() function of these pair styles returns 0.0 for the energy
of a pairwise interaction, since energy is not conserved in these
dissipative potentials. It also returns only the normal component of
the pairwise interaction force. However, the single() function also
calculates 12 extra pairwise quantities. The first 3 are the
components of the tangential force between particles I and J, acting
on particle I. The 4th is the magnitude of this tangential force.
The next 3 (5-7) are the components of the rolling torque acting on
particle I. The next entry (8) is the magnitude of the rolling torque.
The next entry (9) is the magnitude of the twisting torque acting
about the vector connecting the two particle centers.
The last 3 (10-12) are the components of the vector connecting
the centers of the two particles (x_I - x_J).
These extra quantities can be accessed by the "compute
pair/local"_compute_pair_local.html command, as {p1}, {p2}, ...,
{p12}.
:line
[Restrictions:]
All the granular pair styles are part of the GRANULAR package. It is
only enabled if LAMMPS was built with that package. See the "Build
package"_Build_package.html doc page for more info.
These pair styles require that atoms store torque and angular velocity
(omega) as defined by the "atom_style"_atom_style.html. They also
require a per-particle radius is stored. The {sphere} atom style does
all of this.
This pair style requires you to use the "comm_modify vel
yes"_comm_modify.html command so that velocities are stored by ghost
atoms.
These pair styles will not restart exactly when using the
"read_restart"_read_restart.html command, though they should provide
statistically similar results. This is because the forces they
compute depend on atom velocities. See the
"read_restart"_read_restart.html command for more details.
[Related commands:]
"pair_coeff"_pair_coeff.html
"pair gran/*"_pair_gran.html
[Default:]
For the {pair_coeff} settings: {damping viscoelastic}, {rolling none},
{twisting none}.
[References:]
:link(Brill1996)
[(Brilliantov et al, 1996)] Brilliantov, N. V., Spahn, F., Hertzsch,
J. M., & Poschel, T. (1996). Model for collisions in granular
gases. Physical review E, 53(5), 5382.
:link(Tsuji1992)
[(Tsuji et al, 1992)] Tsuji, Y., Tanaka, T., & Ishida,
T. (1992). Lagrangian numerical simulation of plug flow of
cohesionless particles in a horizontal pipe. Powder technology, 71(3),
239-250.
:link(JKR1971)
[(Johnson et al, 1971)] Johnson, K. L., Kendall, K., & Roberts,
A. D. (1971). Surface energy and the contact of elastic
solids. Proc. R. Soc. Lond. A, 324(1558), 301-313.
:link(DMT1975)
[Derjaguin et al, 1975)] Derjaguin, B. V., Muller, V. M., & Toporov,
Y. P. (1975). Effect of contact deformations on the adhesion of
particles. Journal of Colloid and interface science, 53(2), 314-326.
:link(Luding2008)
[(Luding, 2008)] Luding, S. (2008). Cohesive, frictional powders:
contact models for tension. Granular matter, 10(4), 235.
:link(Marshall2009)
[(Marshall, 2009)] Marshall, J. S. (2009). Discrete-element modeling
of particulate aerosol flows. Journal of Computational Physics,
228(5), 1541-1561.
:link(Silbert2001)
[(Silbert, 2001)] Silbert, L. E., Ertas, D., Grest, G. S., Halsey,
T. C., Levine, D., & Plimpton, S. J. (2001). Granular flow down an
inclined plane: Bagnold scaling and rheology. Physical Review E,
64(5), 051302.
:link(Kuhn2004)
[(Kuhn and Bagi, 2005)] Kuhn, M. R., & Bagi, K. (2004). Contact
rolling and deformation in granular media. International journal of
solids and structures, 41(21), 5793-5820.
:link(Wang2015)
[(Wang et al, 2015)] Wang, Y., Alonso-Marroquin, F., & Guo,
W. W. (2015). Rolling and sliding in 3-D discrete element
models. Particuology, 23, 49-55.
:link(Thornton1991)
[(Thornton, 1991)] Thornton, C. (1991). Interparticle sliding in the
presence of adhesion. J. Phys. D: Appl. Phys. 24 1942
:link(Mindlin1949)
[(Mindlin, 1949)] Mindlin, R. D. (1949). Compliance of elastic bodies
in contact. J. Appl. Mech., ASME 16, 259-268.
:link(Thornton2013)
[(Thornton et al, 2013)] Thornton, C., Cummins, S. J., & Cleary,
P. W. (2013). An investigation of the comparative behaviour of
alternative contact force models during inelastic collisions. Powder
Technology, 233, 30-46.
:link(WaltonPC)
[(Otis R. Walton)] Walton, O.R., Personal Communication

348
doc/txt/pair_lj.txt
View File

@ -1,348 +0,0 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
pair_style lj/cut command :h3
pair_style lj/cut/gpu command :h3
pair_style lj/cut/intel command :h3
pair_style lj/cut/kk command :h3
pair_style lj/cut/opt command :h3
pair_style lj/cut/omp command :h3
pair_style lj/cut/coul/cut command :h3
pair_style lj/cut/coul/cut/gpu command :h3
pair_style lj/cut/coul/cut/kk command :h3
pair_style lj/cut/coul/cut/omp command :h3
pair_style lj/cut/coul/debye command :h3
pair_style lj/cut/coul/debye/gpu command :h3
pair_style lj/cut/coul/debye/kk command :h3
pair_style lj/cut/coul/debye/omp command :h3
pair_style lj/cut/coul/dsf command :h3
pair_style lj/cut/coul/dsf/gpu command :h3
pair_style lj/cut/coul/dsf/kk command :h3
pair_style lj/cut/coul/dsf/omp command :h3
pair_style lj/cut/coul/long command :h3
pair_style lj/cut/coul/long/gpu command :h3
pair_style lj/cut/coul/long/kk command :h3
pair_style lj/cut/coul/long/intel command :h3
pair_style lj/cut/coul/long/opt command :h3
pair_style lj/cut/coul/long/omp command :h3
pair_style lj/cut/coul/msm command :h3
pair_style lj/cut/coul/msm/gpu command :h3
pair_style lj/cut/coul/msm/omp command :h3
pair_style lj/cut/coul/wolf command :h3
pair_style lj/cut/coul/wolf/omp command :h3
pair_style lj/cut/tip4p/cut command :h3
pair_style lj/cut/tip4p/cut/omp command :h3
pair_style lj/cut/tip4p/long command :h3
pair_style lj/cut/tip4p/long/omp command :h3
pair_style lj/cut/tip4p/long/opt command :h3
[Syntax:]
pair_style style args :pre
style = {lj/cut} or {lj/cut/coul/cut} or {lj/cut/coul/debye} or {lj/cut/coul/dsf} or {lj/cut/coul/long} {lj/cut/coul/msm} or {lj/cut/tip4p/long}
args = list of arguments for a particular style :ul
{lj/cut} args = cutoff
cutoff = global cutoff for Lennard Jones interactions (distance units)
{lj/cut/coul/cut} args = cutoff (cutoff2)
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
{lj/cut/coul/debye} args = kappa cutoff (cutoff2)
kappa = inverse of the Debye length (inverse distance units)
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
{lj/cut/coul/dsf} args = alpha cutoff (cutoff2)
alpha = damping parameter (inverse distance units)
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (distance units)
{lj/cut/coul/long} args = cutoff (cutoff2)
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
{lj/cut/coul/msm} args = cutoff (cutoff2)
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
{lj/cut/coul/wolf} args = alpha cutoff (cutoff2)
alpha = damping parameter (inverse distance units)
cutoff = global cutoff for LJ (and Coulombic if only 2 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
{lj/cut/tip4p/cut} args = otype htype btype atype qdist cutoff (cutoff2)
otype,htype = atom types for TIP4P O and H
btype,atype = bond and angle types for TIP4P waters
qdist = distance from O atom to massless charge (distance units)
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
{lj/cut/tip4p/long} args = otype htype btype atype qdist cutoff (cutoff2)
otype,htype = atom types for TIP4P O and H
btype,atype = bond and angle types for TIP4P waters
qdist = distance from O atom to massless charge (distance units)
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units) :pre
[Examples:]
pair_style lj/cut 2.5
pair_coeff * * 1 1
pair_coeff 1 1 1 1.1 2.8 :pre
pair_style lj/cut/coul/cut 10.0
pair_style lj/cut/coul/cut 10.0 8.0
pair_coeff * * 100.0 3.0
pair_coeff 1 1 100.0 3.5 9.0
pair_coeff 1 1 100.0 3.5 9.0 9.0 :pre
pair_style lj/cut/coul/debye 1.5 3.0
pair_style lj/cut/coul/debye 1.5 2.5 5.0
pair_coeff * * 1.0 1.0
pair_coeff 1 1 1.0 1.5 2.5
pair_coeff 1 1 1.0 1.5 2.5 5.0 :pre
pair_style lj/cut/coul/dsf 0.05 2.5 10.0
pair_coeff * * 1.0 1.0
pair_coeff 1 1 1.0 1.0 2.5 :pre
pair_style lj/cut/coul/long 10.0
pair_style lj/cut/coul/long 10.0 8.0
pair_coeff * * 100.0 3.0
pair_coeff 1 1 100.0 3.5 9.0 :pre
pair_style lj/cut/coul/msm 10.0
pair_style lj/cut/coul/msm 10.0 8.0
pair_coeff * * 100.0 3.0
pair_coeff 1 1 100.0 3.5 9.0 :pre
pair_style lj/cut/tip4p/cut 1 2 7 8 0.15 12.0
pair_style lj/cut/tip4p/cut 1 2 7 8 0.15 12.0 10.0
pair_coeff * * 100.0 3.0
pair_coeff 1 1 100.0 3.5 9.0 :pre
pair_style lj/cut/coul/wolf 0.2 5. 10.0
pair_coeff * * 1.0 1.0
pair_coeff 1 1 1.0 1.0 2.5 :pre
pair_style lj/cut/tip4p/long 1 2 7 8 0.15 12.0
pair_style lj/cut/tip4p/long 1 2 7 8 0.15 12.0 10.0
pair_coeff * * 100.0 3.0
pair_coeff 1 1 100.0 3.5 9.0 :pre
[Description:]
The {lj/cut} styles compute the standard 12/6 Lennard-Jones potential,
given by
:c,image(Eqs/pair_lj.jpg)
Rc is the cutoff.
Style {lj/cut/coul/cut} adds a Coulombic pairwise interaction given by
:c,image(Eqs/pair_coulomb.jpg)
where C is an energy-conversion constant, Qi and Qj are the charges on
the 2 atoms, and epsilon is the dielectric constant which can be set
by the "dielectric"_dielectric.html command. If one cutoff is
specified in the pair_style command, it is used for both the LJ and
Coulombic terms. If two cutoffs are specified, they are used as
cutoffs for the LJ and Coulombic terms respectively.
Style {lj/cut/coul/debye} adds an additional exp() damping factor
to the Coulombic term, given by
:c,image(Eqs/pair_debye.jpg)
where kappa is the inverse of the Debye length. This potential is
another way to mimic the screening effect of a polar solvent.
Style {lj/cut/coul/dsf} computes the Coulombic term via the damped
shifted force model described in "Fennell"_#Fennell2, given by:
:c,image(Eqs/pair_coul_dsf.jpg)
where {alpha} is the damping parameter and erfc() is the complementary
error-function. This potential is essentially a short-range,
spherically-truncated, charge-neutralized, shifted, pairwise {1/r}
summation. The potential is based on Wolf summation, proposed as an
alternative to Ewald summation for condensed phase systems where
charge screening causes electrostatic interactions to become
effectively short-ranged. In order for the electrostatic sum to be
absolutely convergent, charge neutralization within the cutoff radius
is enforced by shifting the potential through placement of image
charges on the cutoff sphere. Convergence can often be improved by
setting {alpha} to a small non-zero value.
Styles {lj/cut/coul/long} and {lj/cut/coul/msm} compute the same
Coulombic interactions as style {lj/cut/coul/cut} except that an
additional damping factor is applied to the Coulombic term so it can
be used in conjunction with the "kspace_style"_kspace_style.html
command and its {ewald} or {pppm} option. The Coulombic cutoff
specified for this style means that pairwise interactions within this
distance are computed directly; interactions outside that distance are
computed in reciprocal space.
Style {coul/wolf} adds a Coulombic pairwise interaction via the Wolf
summation method, described in "Wolf"_#Wolf1, given by:
:c,image(Eqs/pair_coul_wolf.jpg)
where {alpha} is the damping parameter, and erfc() is the
complementary error-function terms. This potential
is essentially a short-range, spherically-truncated,
charge-neutralized, shifted, pairwise {1/r} summation. With a
manipulation of adding and subtracting a self term (for i = j) to the
first and second term on the right-hand-side, respectively, and a
small enough {alpha} damping parameter, the second term shrinks and
the potential becomes a rapidly-converging real-space summation. With
a long enough cutoff and small enough alpha parameter, the energy and
forces calculated by the Wolf summation method approach those of the
Ewald sum. So it is a means of getting effective long-range
interactions with a short-range potential.
Styles {lj/cut/tip4p/cut} and {lj/cut/tip4p/long} implement the TIP4P
water model of "(Jorgensen)"_#Jorgensen2, which introduces a massless
site located a short distance away from the oxygen atom along the
bisector of the HOH angle. The atomic types of the oxygen and
hydrogen atoms, the bond and angle types for OH and HOH interactions,
and the distance to the massless charge site are specified as
pair_style arguments. Style {lj/cut/tip4p/cut} uses a cutoff for
Coulomb interactions; style {lj/cut/tip4p/long} is for use with a
long-range Coulombic solver (Ewald or PPPM).
NOTE: For each TIP4P water molecule in your system, the atom IDs for
the O and 2 H atoms must be consecutive, with the O atom first. This
is to enable LAMMPS to "find" the 2 H atoms associated with each O
atom. For example, if the atom ID of an O atom in a TIP4P water
molecule is 500, then its 2 H atoms must have IDs 501 and 502.
See the "Howto tip4p"_Howto_tip4p.html doc page for more information
on how to use the TIP4P pair styles and lists of parameters to set.
Note that the neighbor list cutoff for Coulomb interactions is
effectively extended by a distance 2*qdist when using the TIP4P pair
style, to account for the offset distance of the fictitious charges on
O atoms in water molecules. Thus it is typically best in an
efficiency sense to use a LJ cutoff >= Coulombic cutoff + 2*qdist, 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.
For all of the {lj/cut} pair styles, the following coefficients must
be defined for each pair of atoms types via the
"pair_coeff"_pair_coeff.html command as in the examples above, or in
the data file or restart files read by the "read_data"_read_data.html
or "read_restart"_read_restart.html commands, or by mixing as
described below:
epsilon (energy units)
sigma (distance units)
cutoff1 (distance units)
cutoff2 (distance units) :ul
Note that sigma is defined in the LJ formula as the zero-crossing
distance for the potential, not as the energy minimum at 2^(1/6)
sigma.
The latter 2 coefficients are optional. If not specified, the global
LJ and Coulombic cutoffs specified in the pair_style command are used.
If only one cutoff is specified, it is used as the cutoff for both LJ
and Coulombic interactions for this type pair. If both coefficients
are specified, they are used as the LJ and Coulombic cutoffs for this
type pair. You cannot specify 2 cutoffs for style {lj/cut}, since it
has no Coulombic terms.
For {lj/cut/coul/long} and {lj/cut/coul/msm} and {lj/cut/tip4p/cut}
and {lj/cut/tip4p/long} only the LJ cutoff can be specified since a
Coulombic cutoff cannot be specified for an individual I,J type pair.
All type pairs use the same global Coulombic cutoff specified in the
pair_style command.
:line
A version of these styles with a soft core, {lj/cut/soft}, suitable for use in
free energy calculations, is part of the USER-FEP package and is documented with
the "pair_fep_soft"_pair_fep_soft.html styles. The version with soft core is
only available if LAMMPS was built with that package. See the "Build
package"_Build_package.html doc page for more info.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Build
package"_Build_package.html 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 "-suffix command-line
switch"_Run_options.html when you invoke LAMMPS, or you can use the
"suffix"_suffix.html command in your input script.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance for all of the lj/cut pair styles can be mixed.
The default mix value is {geometric}. See the "pair_modify" command
for details.
All of the {lj/cut} pair styles support the
"pair_modify"_pair_modify.html shift option for the energy of the
Lennard-Jones portion of the pair interaction.
The {lj/cut/coul/long} and {lj/cut/tip4p/long} pair styles support the
"pair_modify"_pair_modify.html table option since they can tabulate
the short-range portion of the long-range Coulombic interaction.
All of the {lj/cut} pair styles support the
"pair_modify"_pair_modify.html tail option for adding a long-range
tail correction to the energy and pressure for the Lennard-Jones
portion of the pair interaction.
All of the {lj/cut} pair styles write their information to "binary
restart files"_restart.html, so pair_style and pair_coeff commands do
not need to be specified in an input script that reads a restart file.
The {lj/cut} and {lj/cut/coul/long} pair styles support the use of the
{inner}, {middle}, and {outer} keywords of the "run_style
respa"_run_style.html command, meaning the pairwise forces can be
partitioned by distance at different levels of the rRESPA hierarchy.
The other styles only support the {pair} keyword of run_style respa.
See the "run_style"_run_style.html command for details.
:line
[Restrictions:]
The {lj/cut/coul/long} and {lj/cut/tip4p/long} styles are part of the
KSPACE package. The {lj/cut/tip4p/cut} style is part of the MOLECULE
package. These styles are only enabled if LAMMPS was built with those
packages. See the "Build package"_Build_package.html doc page for
more info.
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
:line
:link(Jorgensen2)
[(Jorgensen)] Jorgensen, Chandrasekhar, Madura, Impey, Klein, J Chem
Phys, 79, 926 (1983).
:link(Fennell2)
[(Fennell)] C. J. Fennell, J. D. Gezelter, J Chem Phys, 124,
234104 (2006).

498
doc/txt/python.txt
View File

@ -1,498 +0,0 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
python command :h3
[Syntax:]
python func keyword args ... :pre
func = name of Python function :ulb,l
one or more keyword/args pairs must be appended :l
keyword = {invoke} or {input} or {return} or {format} or {length} or {file} or {here} or {exists} or {source}
{invoke} arg = none = invoke the previously defined Python function
{input} args = N i1 i2 ... iN
N = # of inputs to function
i1,...,iN = value, SELF, or LAMMPS variable name
value = integer number, floating point number, or string
SELF = reference to LAMMPS itself which can be accessed by Python function
variable = v_name, where name = name of LAMMPS variable, e.g. v_abc
{return} arg = varReturn
varReturn = v_name = LAMMPS variable name which return value of function will be assigned to
{format} arg = fstring with M characters
M = N if no return value, where N = # of inputs
M = N+1 if there is a return value
fstring = each character (i,f,s,p) corresponds in order to an input or return value
'i' = integer, 'f' = floating point, 's' = string, 'p' = SELF
{length} arg = Nlen
Nlen = max length of string returned from Python function
{file} arg = filename
filename = file of Python code, which defines func
{here} arg = inline
inline = one or more lines of Python code which defines func
must be a single argument, typically enclosed between triple quotes
{exists} arg = none = Python code has been loaded by previous python command
{source} arg = {filename} or {inline}
filename = file of Python code which will be executed immediately
inline = one or more lines of Python code which will be executed immediately
must be a single argument, typically enclosed between triple quotes
:pre
:ule
[Examples:]
python pForce input 2 v_x 20.0 return v_f format fff file force.py
python pForce invoke :pre
python factorial input 1 myN return v_fac format ii here """
def factorial(n):
if n == 1: return n
return n * factorial(n-1)
""" :pre
python loop input 1 SELF return v_value format pf here """
def loop(lmpptr,N,cut0):
from lammps import lammps
lmp = lammps(ptr=lmpptr) :pre
# loop N times, increasing cutoff each time :pre
for i in range(N):
cut = cut0 + i*0.1
lmp.set_variable("cut",cut) # set a variable in LAMMPS
lmp.command("pair_style lj/cut $\{cut\}") # LAMMPS commands
lmp.command("pair_coeff * * 1.0 1.0")
lmp.command("run 100")
""" :pre
[Description:]
Define a Python function or execute a previously defined function or
execute some arbitrary python code.
Arguments, including LAMMPS variables, can be passed to the function
from the LAMMPS input script and a value returned by the Python
function to a LAMMPS variable. The Python code for the function can
be included directly in the input script or in a separate Python file.
The function can be standard Python code or it can make "callbacks" to
LAMMPS through its library interface to query or set internal values
within LAMMPS. This is a powerful mechanism for performing complex
operations in a LAMMPS input script that are not possible with the
simple input script and variable syntax which LAMMPS defines. Thus
your input script can operate more like a true programming language.
Use of this command requires building LAMMPS with the PYTHON package
which links to the Python library so that the Python interpreter is
embedded in LAMMPS. More details about this process are given below.
There are two ways to invoke a Python function once it has been
defined. One is using the {invoke} keyword. The other is to assign
the function to a "python-style variable"_variable.html defined in
your input script. Whenever the variable is evaluated, it will
execute the Python function to assign a value to the variable. Note
that variables can be evaluated in many different ways within LAMMPS.
They can be substituted for directly in an input script. Or they can
be passed to various commands as arguments, so that the variable is
evaluated during a simulation run.
A broader overview of how Python can be used with LAMMPS is given on
the "Python"_Python_head.html doc page. There is an examples/python
directory which illustrates use of the python command.
:line
The {func} setting specifies the name of the Python function. The
code for the function is defined using the {file} or {here} keywords
as explained below. In case of the {source} keyword, the name of
the function is ignored.
If the {invoke} keyword is used, no other keywords can be used, and a
previous python command must have defined the Python function
referenced by this command. This invokes the Python function with the
previously defined arguments and return value processed as explained
below. You can invoke the function as many times as you wish in your
input script.
If the {source} keyword is used, no other keywords can be used.
The argument can be a filename or a string with python commands,
either on a single line enclosed in quotes, or as multiple lines
enclosed in triple quotes. These python commands will be passed
to the python interpreter and executed immediately without registering
a python function for future execution.
The {input} keyword defines how many arguments {N} the Python function
expects. If it takes no arguments, then the {input} keyword should
not be used. Each argument can be specified directly as a value,
e.g. 6 or 3.14159 or abc (a string of characters). The type of each
argument is specified by the {format} keyword as explained below, so
that Python will know how to interpret the value. If the word SELF is
used for an argument it has a special meaning. A pointer is passed to
the Python function which it converts into a reference to LAMMPS
itself. This enables the function to call back to LAMMPS through its
library interface as explained below. This allows the Python function
to query or set values internal to LAMMPS which can affect the
subsequent execution of the input script. A LAMMPS variable can also
be used as an argument, specified as v_name, where "name" is the name
of the variable. Any style of LAMMPS variable can be used, as defined
by the "variable"_variable.html command. Each time the Python
function is invoked, the LAMMPS variable is evaluated and its value is
passed to the Python function.
The {return} keyword is only needed if the Python function returns a
value. The specified {varReturn} must be of the form v_name, where
"name" is the name of a python-style LAMMPS variable, defined by the
"variable"_variable.html command. The Python function can return a
numeric or string value, as specified by the {format} keyword.
As explained on the "variable"_variable.html doc page, the definition
of a python-style variable associates a Python function name with the
variable. This must match the {func} setting for this command. For
example these two commands would be self-consistent:
variable foo python myMultiply
python myMultiply return v_foo format f file funcs.py :pre
The two commands can appear in either order in the input script so
long as both are specified before the Python function is invoked for
the first time.
The {format} keyword must be used if the {input} or {return} keyword
is used. It defines an {fstring} with M characters, where M = sum of
number of inputs and outputs. The order of characters corresponds to
the N inputs, followed by the return value (if it exists). Each
character must be one of the following: "i" for integer, "f" for
floating point, "s" for string, or "p" for SELF. Each character
defines the type of the corresponding input or output value of the
Python function and affects the type conversion that is performed
internally as data is passed back and forth between LAMMPS and Python.
Note that it is permissible to use a "python-style
variable"_variable.html in a LAMMPS command that allows for an
equal-style variable as an argument, but only if the output of the
Python function is flagged as a numeric value ("i" or "f") via the
{format} keyword.
If the {return} keyword is used and the {format} keyword specifies the
output as a string, then the default maximum length of that string is
63 characters (64-1 for the string terminator). If you want to return
a longer string, the {length} keyword can be specified with its {Nlen}
value set to a larger number (the code allocates space for Nlen+1 to
include the string terminator). If the Python function generates a
string longer than the default 63 or the specified {Nlen}, it will be
truncated.
:line
Either the {file}, {here}, or {exists} keyword must be used, but only
one of them. These keywords specify what Python code to load into the
Python interpreter. The {file} keyword gives the name of a file,
which should end with a ".py" suffix, which contains Python code. The
code will be immediately loaded into and run in the "main" module of
the Python interpreter. Note that Python code which contains a
function definition does not "execute" the function when it is run; it
simply defines the function so that it can be invoked later.
The {here} keyword does the same thing, except that the Python code
follows as a single argument to the {here} keyword. This can be done
using triple quotes as delimiters, as in the examples above. This
allows Python code to be listed verbatim in your input script, with
proper indentation, blank lines, and comments, as desired. See the
"Commands parse"_Commands_parse.html doc page, for an explanation of
how triple quotes can be used as part of input script syntax.
The {exists} keyword takes no argument. It means that Python code
containing the required Python function defined by the {func} setting,
is assumed to have been previously loaded by another python command.
Note that the Python code that is loaded and run must contain a
function with the specified {func} name. To operate properly when
later invoked, the function code must match the {input} and
{return} and {format} keywords specified by the python command.
Otherwise Python will generate an error.
:line
This section describes how Python code can be written to work with
LAMMPS.
Whether you load Python code from a file or directly from your input
script, via the {file} and {here} keywords, the code can be identical.
It must be indented properly as Python requires. It can contain
comments or blank lines. If the code is in your input script, it
cannot however contain triple-quoted Python strings, since that will
conflict with the triple-quote parsing that the LAMMPS input script
performs.
All the Python code you specify via one or more python commands is
loaded into the Python "main" module, i.e. __main__. The code can
define global variables or statements that are outside of function
definitions. It can contain multiple functions, only one of which
matches the {func} setting in the python command. This means you can
use the {file} keyword once to load several functions, and the
{exists} keyword thereafter in subsequent python commands to access
the other functions previously loaded.
A Python function you define (or more generally, the code you load)
can import other Python modules or classes, it can make calls to other
system functions or functions you define, and it can access or modify
global variables (in the "main" module) which will persist between
successive function calls. The latter can be useful, for example, to
prevent a function from being invoke multiple times per timestep by
different commands in a LAMMPS input script that access the returned
python-style variable associated with the function. For example,
consider this function loaded with two global variables defined
outside the function:
nsteplast = -1
nvaluelast = 0 :pre
def expensive(nstep):
global nsteplast,nvaluelast
if nstep == nsteplast: return nvaluelast
nsteplast = nstep
# perform complicated calculation
nvalue = ...
nvaluelast = nvalue
return nvalue :pre
Nsteplast stores the previous timestep the function was invoked
(passed as an argument to the function). Nvaluelast stores the return
value computed on the last function invocation. If the function is
invoked again on the same timestep, the previous value is simply
returned, without re-computing it. The "global" statement inside the
Python function allows it to overwrite the global variables.
Note that if you load Python code multiple times (via multiple python
commands), you can overwrite previously loaded variables and functions
if you are not careful. E.g. if the code above were loaded twice, the
global variables would be re-initialized, which might not be what you
want. Likewise, if a function with the same name exists in two chunks
of Python code you load, the function loaded second will override the
function loaded first.
It's important to realize that if you are running LAMMPS in parallel,
each MPI task will load the Python interpreter and execute a local
copy of the Python function(s) you define. There is no connection
between the Python interpreters running on different processors.
This implies three important things.
First, if you put a print statement in your Python function, you will
see P copies of the output, when running on P processors. If the
prints occur at (nearly) the same time, the P copies of the output may
be mixed together. Welcome to the world of parallel programming and
debugging.
Second, if your Python code loads modules that are not pre-loaded by
the Python library, then it will load the module from disk. This may
be a bottleneck if 1000s of processors try to load a module at the
same time. On some large supercomputers, loading of modules from disk
by Python may be disabled. In this case you would need to pre-build a
Python library that has the required modules pre-loaded and link
LAMMPS with that library.
Third, if your Python code calls back to LAMMPS (discussed in the
next section) and causes LAMMPS to perform an MPI operation requires
global communication (e.g. via MPI_Allreduce), such as computing the
global temperature of the system, then you must insure all your Python
functions (running independently on different processors) call back to
LAMMPS. Otherwise the code may hang.
:line
Your Python function can "call back" to LAMMPS through its
library interface, if you use the SELF input to pass Python
a pointer to LAMMPS. The mechanism for doing this in your
Python function is as follows:
def foo(lmpptr,...):
from lammps import lammps
lmp = lammps(ptr=lmpptr)
lmp.command('print "Hello from inside Python"')
... :pre
The function definition must include a variable (lmpptr in this case)
which corresponds to SELF in the python command. The first line of
the function imports the Python module lammps.py in the python dir of
the distribution. The second line creates a Python object "lmp" which
wraps the instance of LAMMPS that called the function. The
"ptr=lmpptr" argument is what makes that happen. The third line
invokes the command() function in the LAMMPS library interface. It
takes a single string argument which is a LAMMPS input script command
for LAMMPS to execute, the same as if it appeared in your input
script. In this case, LAMMPS should output
Hello from inside Python :pre
to the screen and log file. Note that since the LAMMPS print command
itself takes a string in quotes as its argument, the Python string
must be delimited with a different style of quotes.
The "Pytnon library"_Python_library.html doc page describes the syntax
for how Python wraps the various functions included in the LAMMPS
library interface.
A more interesting example is in the examples/python/in.python script
which loads and runs the following function from examples/python/funcs.py:
def loop(N,cut0,thresh,lmpptr):
print "LOOP ARGS",N,cut0,thresh,lmpptr
from lammps import lammps
lmp = lammps(ptr=lmpptr)
natoms = lmp.get_natoms() :pre
for i in range(N):
cut = cut0 + i*0.1 :pre
lmp.set_variable("cut",cut) # set a variable in LAMMPS
lmp.command("pair_style lj/cut $\{cut\}") # LAMMPS command
#lmp.command("pair_style lj/cut %d" % cut) # LAMMPS command option :pre
lmp.command("pair_coeff * * 1.0 1.0") # ditto
lmp.command("run 10") # ditto
pe = lmp.extract_compute("thermo_pe",0,0) # extract total PE from LAMMPS
print "PE",pe/natoms,thresh
if pe/natoms < thresh: return :pre
with these input script commands:
python loop input 4 10 1.0 -4.0 SELF format iffp file funcs.py
python loop invoke :pre
This has the effect of looping over a series of 10 short runs (10
timesteps each) where the pair style cutoff is increased from a value
of 1.0 in distance units, in increments of 0.1. The looping stops
when the per-atom potential energy falls below a threshold of -4.0 in
energy units. More generally, Python can be used to implement a loop
with complex logic, much more so than can be created using the LAMMPS
"jump"_jump.html and "if"_if.html commands.
Several LAMMPS library functions are called from the loop function.
Get_natoms() returns the number of atoms in the simulation, so that it
can be used to normalize the potential energy that is returned by
extract_compute() for the "thermo_pe" compute that is defined by
default for LAMMPS thermodynamic output. Set_variable() sets the
value of a string variable defined in LAMMPS. This library function
is a useful way for a Python function to return multiple values to
LAMMPS, more than the single value that can be passed back via a
return statement. This cutoff value in the "cut" variable is then
substituted (by LAMMPS) in the pair_style command that is executed
next. Alternatively, the "LAMMPS command option" line could be used
in place of the 2 preceding lines, to have Python insert the value
into the LAMMPS command string.
NOTE: When using the callback mechanism just described, recognize that
there are some operations you should not attempt because LAMMPS cannot
execute them correctly. If the Python function is invoked between
runs in the LAMMPS input script, then it should be OK to invoke any
LAMMPS input script command via the library interface command() or
file() functions, so long as the command would work if it were
executed in the LAMMPS input script directly at the same point.
However, a Python function can also be invoked during a run, whenever
an associated LAMMPS variable it is assigned to is evaluated. If the
variable is an input argument to another LAMMPS command (e.g. "fix
setforce"_fix_setforce.html), then the Python function will be invoked
inside the class for that command, in one of its methods that is
invoked in the middle of a timestep. You cannot execute arbitrary
input script commands from the Python function (again, via the
command() or file() functions) at that point in the run and expect it
to work. Other library functions such as those that invoke computes
or other variables may have hidden side effects as well. In these
cases, LAMMPS has no simple way to check that something illogical is
being attempted.
The same applies to Python functions called during a simulation run at
each time step using "fix python/invoke"_fix_python_invoke.html.
:line
If you run Python code directly on your workstation, either
interactively or by using Python to launch a Python script stored in a
file, and your code has an error, you will typically see informative
error messages. That is not the case when you run Python code from
LAMMPS using an embedded Python interpreter. The code will typically
fail silently. LAMMPS will catch some errors but cannot tell you
where in the Python code the problem occurred. For example, if the
Python code cannot be loaded and run because it has syntax or other
logic errors, you may get an error from Python pointing to the
offending line, or you may get one of these generic errors from
LAMMPS:
Could not process Python file
Could not process Python string :pre
When the Python function is invoked, if it does not return properly,
you will typically get this generic error from LAMMPS:
Python function evaluation failed :pre
Here are three suggestions for debugging your Python code while
running it under LAMMPS.
First, don't run it under LAMMPS, at least to start with! Debug it
using plain Python. Load and invoke your function, pass it arguments,
check return values, etc.
Second, add Python print statements to the function to check how far
it gets and intermediate values it calculates. See the discussion
above about printing from Python when running in parallel.
Third, use Python exception handling. For example, say this statement
in your Python function is failing, because you have not initialized the
variable foo:
foo += 1 :pre
If you put one (or more) statements inside a "try" statement,
like this:
import exceptions
print "Inside simple function"
try:
foo += 1 # one or more statements here
except Exception, e:
print "FOO error:",e :pre
then you will get this message printed to the screen:
FOO error: local variable 'foo' referenced before assignment :pre
If there is no error in the try statements, then nothing is printed.
Either way the function continues on (unless you put a return or
sys.exit() in the except clause).
:line
[Restrictions:]
This command is part of the PYTHON package. It is only enabled if
LAMMPS was built with that package. See the "Build
package"_Build_package.html doc page for more info.
Building LAMMPS with the PYTHON package will link LAMMPS with the
Python library on your system. Settings to enable this are in the
lib/python/Makefile.lammps file. See the lib/python/README file for
information on those settings.
If you use Python code which calls back to LAMMPS, via the SELF input
argument explained above, there is an extra step required when
building LAMMPS. LAMMPS must also be built as a shared library and
your Python function must be able to load the Python module in
python/lammps.py that wraps the LAMMPS library interface. These are
the same steps required to use Python by itself to wrap LAMMPS.
Details on these steps are explained on the "Python"_Python_head.html
doc page. Note that it is important that the stand-alone LAMMPS
executable and the LAMMPS shared library be consistent (built from the
same source code files) in order for this to work. If the two have
been built at different times using different source files, problems
may occur.
[Related commands:]
"shell"_shell.html, "variable"_variable.html, "fix
python/invoke"_fix_python_invoke.html
[Default:] none

20
potentials/Si.tersoff.modc
View File

@ -1,10 +1,10 @@
# DATE: 2016-11-09 CONTRIBUTOR: Ganga P Purja Pun (George Mason University, Fairfax) CITATION: Unknown
#
# Format:
# element1 element2 element3
# beta alpha h eta
# beta_ters lam2 B R D lam1 A
# n c1 c2 c3 c4 c5 C
Si Si Si 3.00000000 1.80536502 -0.38136087 2.16152496
1 1.39343356 117.78072440 2.87478837 0.33090566 3.18011795 3198.51383127
1.98633876 0.20123243 614230.04310619 996439.09714140 3.33560562 25.20963770 -0.00592042
# DATE: 2016-11-09 CONTRIBUTOR: Ganga P Purja Pun (George Mason University, Fairfax) CITATION: Unknown
#
# Format:
# element1 element2 element3
# beta alpha h eta
# beta_ters lam2 B R D lam1 A
# n c1 c2 c3 c4 c5 C
Si Si Si 3.00000000 1.80536502 -0.38136087 2.16152496
1 1.39343356 117.78072440 2.87478837 0.33090566 3.18011795 3198.51383127
1.98633876 0.20123243 614230.04310619 996439.09714140 3.33560562 25.20963770 -0.00592042

96
potentials/SiC_Erhart-Albe.tersoff
View File

@ -1,48 +1,48 @@
# DATE: 2009-05-05 CONTRIBUTOR: Felix Ulomek, ulomek@imm.rwth-aachen.de CITATION: Erhart and Albe, Phys Rev B, 71, 035211 (2005)
# Si and C mixture, parameterized for Tersoff potential
# this file is from ulomek(at)imm.rwth-aachen.de
# values are from Erhart/Albe - Phys Rev B, 71, 035211 (2005)
# m=n=beta=1
# R,D,gamma,c,d ->same
# lambda1=beta*sqrt(2*S)
# lambda2=beta*sqrt(2/S)
# lambda3=2*mu=0
# costheta0=-h
# A=D0/(S-1)*exp(lambda1*r0)
# B=S*D0/(S-1)*exp(lambda2*r0)
# 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
# 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
C C C 1 0.11233 0 181.91 6.28433 -0.5556 1
1 1.93090093 175.426651 2 0.15 4.18426232 2019.8449
Si Si Si 1 0.114354 0 2.00494 0.81472 -0.259 1
1 1.53810493 219.521624 2.82 0.14 2.83318929 2145.7128
Si Si C 1 0.011877 0 273987 180.314 -0.68 0
0 0 0 2.4 0.2 0 0
Si C C 1 0.011877 0 273987 180.314 -0.68 1
1 1.76807421 225.189481 2.4 0.2 3.26563307 1779.36144
C Si Si 1 0.011877 0 273987 180.314 -0.68 1
1 1.76807421 225.189481 2.4 0.2 3.26563307 1779.36144
C Si C 1 0.11233 0 181.910 6.28433 -0.5556 0
0 0 0 2 0.15 0 0
C C Si 1 0.011877 0 273987 180.314 -0.68 0
0 0 0 2.4 0.2 0 0
Si C Si 1 0.114354 0 2.00494 0.81472 -0.259 0
0 0 0 2.82 0.14 0 0
# DATE: 2009-05-05 CONTRIBUTOR: Felix Ulomek, ulomek@imm.rwth-aachen.de CITATION: Erhart and Albe, Phys Rev B, 71, 035211 (2005)
# Si and C mixture, parameterized for Tersoff potential
# this file is from ulomek(at)imm.rwth-aachen.de
# values are from Erhart/Albe - Phys Rev B, 71, 035211 (2005)
# m=n=beta=1
# R,D,gamma,c,d ->same
# lambda1=beta*sqrt(2*S)
# lambda2=beta*sqrt(2/S)
# lambda3=2*mu=0
# costheta0=-h
# A=D0/(S-1)*exp(lambda1*r0)
# B=S*D0/(S-1)*exp(lambda2*r0)
# 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
# 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
C C C 1 0.11233 0 181.91 6.28433 -0.5556 1
1 1.93090093 175.426651 2 0.15 4.18426232 2019.8449
Si Si Si 1 0.114354 0 2.00494 0.81472 -0.259 1
1 1.53810493 219.521624 2.82 0.14 2.83318929 2145.7128
Si Si C 1 0.011877 0 273987 180.314 -0.68 0
0 0 0 2.4 0.2 0 0
Si C C 1 0.011877 0 273987 180.314 -0.68 1
1 1.76807421 225.189481 2.4 0.2 3.26563307 1779.36144
C Si Si 1 0.011877 0 273987 180.314 -0.68 1
1 1.76807421 225.189481 2.4 0.2 3.26563307 1779.36144
C Si C 1 0.11233 0 181.910 6.28433 -0.5556 0
0 0 0 2 0.15 0 0
C C Si 1 0.011877 0 273987 180.314 -0.68 0
0 0 0 2.4 0.2 0 0
Si C Si 1 0.114354 0 2.00494 0.81472 -0.259 0
0 0 0 2.82 0.14 0 0

260
potentials/TiO.meam.spline
View File

@ -1,130 +1,130 @@
# Ti-O cubic spline potential where O is in the dilute limit. DATE: 2016-06-05 CONTRIBUTOR: Pinchao Zhang, Dallas R. Trinkle
meam/spline 2 Ti O
spline3eq
13
-20 0
1.742692837 3.744277175966 99.4865081627958
2.05580176725 0.910839730906 10.8702523265355
2.3689106975 0.388045896634 -1.55322418749562
2.68201962775 -0.018840906533 2.43630041329215
2.995128558 -0.248098929639 2.67912713976835
3.30823748825 -0.264489550297 -0.125056384603077
3.6213464185 -0.227196189283 1.10662555360438
3.93445534875 -0.129293090176 -0.592053676745914
4.247564279 -0.059685366933 -0.470123414607672
4.56067320925 -0.031100025561 -0.0380739973059663
4.8737821395 -0.013847363202 -0.0711547960695406
5.18689106975 -0.003203412728 -0.081768292420175
5.5 0 -0.0571422964883619
spline3eq
5
0.155001355787331 0
1.9 0.533321679606674 0
2.8 0.456402081843862 -1.60311717015859
3.7 -0.324281383502201 1.19940299483249
4.6 -0.474029826906675 1.47909794595154
5.5 0 -2.49521499855605
spline3eq
13
0 0
1.742692837 0 0
2.05580176725 0 0
2.3689106975 0 0
2.68201962775 0 0
2.995128558 0 0
3.30823748825 0 0
3.6213464185 0 0
3.93445534875 0 0
4.247564279 0 0
4.56067320925 0 0
4.8737821395 0 0
5.18689106975 0 0
5.5 0 0
spline3eq
11
-1 0
2.055801767 1.7475279661 -525.869786904802
2.2912215903 -5.8677963945 252.796316927755
2.5266414136 -8.3376288737 71.7318388721015
2.7620612369 -5.8398712842 -1.93587742753693
2.9974810602 -3.1140648231 -39.2999192667503
3.2329008835 -1.7257245065 14.3424136002004
3.4683207068 -0.4428977017 -29.4925534559498
3.7037405301 -0.1466643003 -3.18010534572236
3.9391603534 -0.2095507945 3.33490838803603
4.1745801767 -0.1442384563 3.71918691359508
4.41 0 -9.66717019857564
spline3eq
5
-61.9827585211652 0
1.9 11.2293641315584 0
2.8 -27.9976343076148 122.648031332411
3.7 -8.32979773113248 -54.3340881766381
4.6 -1.00863195297399 3.23150064581724
5.5 0 -5.3514242228123
spline3eq
4
0.00776934946045395 0.105197706160344
-55.14233165 -0.29745568008 0.00152870603877451
-44.7409899033333 -0.15449458722 0.00038933722543571
-34.3396481566667 0.05098657168 0.00038124926922248
-23.93830641 0.57342694704 0.0156639264890892
spline3eq
5
-0.00676745157022662 -0.0159520381982146
-23.9928 0.297607384684645 0
-15.9241175 0.216691597077105 -0.0024248755353942
-7.855435 0.0637598673719069 0.00306245895013358
0.213247499999998 -0.00183450621970427 -0.00177588407633909
8.28193 -0.111277018874367 0
spline3eq
10
2.77327511656661 0
2.055801767 -0.1485215264 72.2010867146919
2.31737934844444 1.6845304918 -47.2744689053404
2.57895692988889 2.0113365977 -15.1859578405326
2.84053451133333 1.1444092747 3.33978204841873
3.10211209277778 0.2861606803 2.587867603808
3.36368967422222 -0.3459281126 6.14070694084556
3.62526725566667 -0.6257480601 3.7397696717154
3.88684483711111 -0.6119510826 4.64749084871402
4.14842241855556 -0.3112059651 2.83275746415936
4.41 0 -15.0612086827734
spline3eq
5
12.3315547862781 0
1.9 2.62105440156724 0
2.8 10.2850803058354 -25.439802988016
3.7 3.23933763743897 -7.20203673434025
4.6 -5.79049355858613 39.5509978688682
5.5 0 -41.221771373642
spline3eq
8
8.33642274810572 -60.4024574736564
-1 0.07651409193 -110.652321293778
-0.724509054371429 0.14155824541 44.8853405500508
-0.449018108742857 0.75788697341 -25.3065115342002
-0.173527163114286 0.63011570378 -2.48510144915082
0.101963782514286 0.09049597305 2.68769386908235
0.377454728142857 -0.35741586657 -1.01558570129633
0.652945673771428 -0.65293217647 13.4224786001212
0.9284366194 -6.00912190653 -452.752542694929
spline3eq
5
0.137191606537625 -1.55094230968985
-1 0.0513843442016519 0
-0.5 0.0179024412245673 -2.44986494990154
0 -0.260650876879273 3.91774583656401
0.5 -0.190163791764901 -4.84414871911743
1 -0.763795416646599 0
spline3eq
8
0 0
-1 0 0
-0.724509054371429 0 0
-0.449018108742857 0 0
-0.173527163114286 0 0
0.101963782514286 0 0
0.377454728142857 0 0
0.652945673771428 0 0
0.9284366194 0 0
# Ti-O cubic spline potential where O is in the dilute limit. DATE: 2016-06-05 CONTRIBUTOR: Pinchao Zhang, Dallas R. Trinkle
meam/spline 2 Ti O
spline3eq
13
-20 0
1.742692837 3.744277175966 99.4865081627958
2.05580176725 0.910839730906 10.8702523265355
2.3689106975 0.388045896634 -1.55322418749562
2.68201962775 -0.018840906533 2.43630041329215
2.995128558 -0.248098929639 2.67912713976835
3.30823748825 -0.264489550297 -0.125056384603077
3.6213464185 -0.227196189283 1.10662555360438
3.93445534875 -0.129293090176 -0.592053676745914
4.247564279 -0.059685366933 -0.470123414607672
4.56067320925 -0.031100025561 -0.0380739973059663
4.8737821395 -0.013847363202 -0.0711547960695406
5.18689106975 -0.003203412728 -0.081768292420175
5.5 0 -0.0571422964883619
spline3eq
5
0.155001355787331 0
1.9 0.533321679606674 0
2.8 0.456402081843862 -1.60311717015859
3.7 -0.324281383502201 1.19940299483249
4.6 -0.474029826906675 1.47909794595154
5.5 0 -2.49521499855605
spline3eq
13
0 0
1.742692837 0 0
2.05580176725 0 0
2.3689106975 0 0
2.68201962775 0 0
2.995128558 0 0
3.30823748825 0 0
3.6213464185 0 0
3.93445534875 0 0
4.247564279 0 0
4.56067320925 0 0
4.8737821395 0 0
5.18689106975 0 0
5.5 0 0
spline3eq
11
-1 0
2.055801767 1.7475279661 -525.869786904802
2.2912215903 -5.8677963945 252.796316927755
2.5266414136 -8.3376288737 71.7318388721015
2.7620612369 -5.8398712842 -1.93587742753693
2.9974810602 -3.1140648231 -39.2999192667503
3.2329008835 -1.7257245065 14.3424136002004
3.4683207068 -0.4428977017 -29.4925534559498
3.7037405301 -0.1466643003 -3.18010534572236
3.9391603534 -0.2095507945 3.33490838803603
4.1745801767 -0.1442384563 3.71918691359508
4.41 0 -9.66717019857564
spline3eq
5
-61.9827585211652 0
1.9 11.2293641315584 0
2.8 -27.9976343076148 122.648031332411
3.7 -8.32979773113248 -54.3340881766381
4.6 -1.00863195297399 3.23150064581724
5.5 0 -5.3514242228123
spline3eq
4
0.00776934946045395 0.105197706160344
-55.14233165 -0.29745568008 0.00152870603877451
-44.7409899033333 -0.15449458722 0.00038933722543571
-34.3396481566667 0.05098657168 0.00038124926922248
-23.93830641 0.57342694704 0.0156639264890892
spline3eq
5
-0.00676745157022662 -0.0159520381982146
-23.9928 0.297607384684645 0
-15.9241175 0.216691597077105 -0.0024248755353942
-7.855435 0.0637598673719069 0.00306245895013358
0.213247499999998 -0.00183450621970427 -0.00177588407633909
8.28193 -0.111277018874367 0
spline3eq
10
2.77327511656661 0
2.055801767 -0.1485215264 72.2010867146919
2.31737934844444 1.6845304918 -47.2744689053404
2.57895692988889 2.0113365977 -15.1859578405326
2.84053451133333 1.1444092747 3.33978204841873
3.10211209277778 0.2861606803 2.587867603808
3.36368967422222 -0.3459281126 6.14070694084556
3.62526725566667 -0.6257480601 3.7397696717154
3.88684483711111 -0.6119510826 4.64749084871402
4.14842241855556 -0.3112059651 2.83275746415936
4.41 0 -15.0612086827734
spline3eq
5
12.3315547862781 0
1.9 2.62105440156724 0
2.8 10.2850803058354 -25.439802988016
3.7 3.23933763743897 -7.20203673434025
4.6 -5.79049355858613 39.5509978688682
5.5 0 -41.221771373642
spline3eq
8
8.33642274810572 -60.4024574736564
-1 0.07651409193 -110.652321293778
-0.724509054371429 0.14155824541 44.8853405500508
-0.449018108742857 0.75788697341 -25.3065115342002
-0.173527163114286 0.63011570378 -2.48510144915082
0.101963782514286 0.09049597305 2.68769386908235
0.377454728142857 -0.35741586657 -1.01558570129633
0.652945673771428 -0.65293217647 13.4224786001212
0.9284366194 -6.00912190653 -452.752542694929
spline3eq
5
0.137191606537625 -1.55094230968985
-1 0.0513843442016519 0
-0.5 0.0179024412245673 -2.44986494990154
0 -0.260650876879273 3.91774583656401
0.5 -0.190163791764901 -4.84414871911743
1 -0.763795416646599 0
spline3eq
8
0 0
-1 0 0
-0.724509054371429 0 0
-0.449018108742857 0 0
-0.173527163114286 0 0
0.101963782514286 0 0
0.377454728142857 0 0
0.652945673771428 0 0
0.9284366194 0 0

6
src/USER-MEAMC/meam_funcs.cpp
View File

@ -382,9 +382,9 @@ MEAM::get_Zij2(const lattice_t latt, const double cmin, const double cmax,
// Compute screening for each first neighbor
if (latt==DIA3){ // special case for 3NN diamond structure
C = 1.0;
C = 1.0;
} else {
C = 4.0 / (a * a) - 1.0;
C = 4.0 / (a * a) - 1.0;
}
x = (C - cmin) / (cmax - cmin);
sijk = fcut(x);
@ -415,4 +415,4 @@ MEAM::get_Zij2_b2nn(const lattice_t latt, const double cmin, const double cmax,
sijk = fcut(x);
S = MathSpecial::powint(sijk, numscr);
return Zij2;
}
}

6
src/USER-MEAMC/meam_setup_done.cpp
View File

@ -103,7 +103,7 @@ MEAM::alloyparams(void)
this->alpha_meam[i][j] = this->alpha_meam[j][i];
this->lattce_meam[i][j] = this->lattce_meam[j][i];
this->nn2_meam[i][j] = this->nn2_meam[j][i];
// theta for lin,tri,zig references
// theta for lin,tri,zig references
this->stheta_meam[i][j] = this->stheta_meam[j][i];
this->ctheta_meam[i][j] = this->ctheta_meam[j][i];
// If i<j and term is unset, use default values (e.g. mean of i-i and
@ -747,9 +747,9 @@ MEAM::get_densref(double r, int a, int b, double* rho01, double* rho11, double*
break;
case CH4:
*rho01 = 4.0 * rhoa02; //in assumption that 'a' represent carbon
*rho02 = rhoa01; //in assumption that 'b' represent hydrogen
*rho02 = rhoa01; //in assumption that 'b' represent hydrogen
get_shpfcn(DIM, 0, 0, s); //H
get_shpfcn(DIM, 0, 0, s); //H
*rho12 = s[0] * rhoa11 * rhoa11;
*rho22 = s[1] * rhoa21 * rhoa21;
*rho32 = s[2] * rhoa31 * rhoa31;

2
src/comm.cpp
View File

@ -982,6 +982,7 @@ rendezvous_all2all(int n, char *inbuf, int insize, int inorder, int *procs,
memory->create(procs_a2a,nprocs,"rendezvous:procs");
inbuf_a2a = (char *) memory->smalloc((bigint) n*insize,
"rendezvous:inbuf");
memset(inbuf_a2a,0,(bigint)n*insize*sizeof(char));
memory->create(offsets,nprocs,"rendezvous:offsets");
for (int i = 0; i < nprocs; i++) procs_a2a[i] = 0;
@ -1045,6 +1046,7 @@ rendezvous_all2all(int n, char *inbuf, int insize, int inorder, int *procs,
char *inbuf_rvous = (char *) memory->smalloc((bigint) nrvous*insize,
"rendezvous:inbuf");
memset(inbuf_rvous,0,(bigint) nrvous*insize*sizeof(char));
MPI_Alltoallv(inbuf_a2a,sendcount,sdispls,MPI_CHAR,
inbuf_rvous,recvcount,rdispls,MPI_CHAR,world);