Updating from master to 19May17

This commit is contained in:
Stan Moore 2017-05-25 11:21:10 -06:00
commit 2cf83d9fca
812 changed files with 53886 additions and 23115 deletions

View File

@ -158,7 +158,7 @@ $(VENV):
@( \
virtualenv -p $(PYTHON) $(VENV); \
. $(VENV)/bin/activate; \
pip install Sphinx; \
pip install Sphinx==1.5.6; \
pip install sphinxcontrib-images; \
deactivate;\
)

Binary file not shown.

Before

Width:  |  Height:  |  Size: 10 KiB

After

Width:  |  Height:  |  Size: 21 KiB

View File

@ -1,13 +1,14 @@
\documentclass[12pt]{article}
\usepackage{amsmath}
\begin{document}
$$
E=\sum_{ij}\phi(r_{ij})+\sum_{i}U(\rho_{i}),
E=\sum_{i<j}\phi(r_{ij})+\sum_{i}U(n_{i}),
$$
$$
\rho_{i}=\sum_{j}\rho(r_{ij})+\sum_{jk}f(r_{ij})f(r_{ik})g[\cos(\theta_{jik})]
n_{i}=\sum_{j}\rho(r_{ij})+\sum_{\substack{j<k,\\j,k\neq i}}f(r_{ij})f(r_{ik})g[\cos(\theta_{jik})]
$$
\end{document}

Binary file not shown.

After

Width:  |  Height:  |  Size: 22 KiB

View File

@ -0,0 +1,14 @@
\documentclass[12pt]{article}
\usepackage{amsmath}
\begin{document}
$$
E=\sum_{i<j}\phi_{ij}(r_{ij})+\sum_{i}U_i(n_{i}),
$$
$$
n_{i}=\sum_{j\ne i}\rho_j(r_{ij})+\sum_{\substack{j<k,\\j,k\neq i}}f_{j}(r_{ij})f_{k}(r_{ik})g_{jk}[\cos(\theta_{jik})]
$$
\end{document}

View File

@ -1,7 +1,7 @@
<!-- HTML_ONLY -->
<HEAD>
<TITLE>LAMMPS Users Manual</TITLE>
<META NAME="docnumber" CONTENT="31 Mar 2017 version">
<META NAME="docnumber" CONTENT="19 May 2017 version">
<META NAME="author" CONTENT="http://lammps.sandia.gov - Sandia National Laboratories">
<META NAME="copyright" CONTENT="Copyright (2003) Sandia Corporation. This software and manual is distributed under the GNU General Public License.">
</HEAD>
@ -21,7 +21,7 @@
<H1></H1>
LAMMPS Documentation :c,h3
31 Mar 2017 version :c,h4
19 May 2017 version :c,h4
Version info: :h4
@ -158,12 +158,11 @@ END_RST -->
2.1 "What's in the LAMMPS distribution"_start_1 :ulb,b
2.2 "Making LAMMPS"_start_2 :b
2.3 "Making LAMMPS with optional packages"_start_3 :b
2.4 "Building LAMMPS via the Make.py script"_start_4 :b
2.5 "Building LAMMPS as a library"_start_5 :b
2.6 "Running LAMMPS"_start_6 :b
2.7 "Command-line options"_start_7 :b
2.8 "Screen output"_start_8 :b
2.9 "Tips for users of previous versions"_start_9 :ule,b
2.4 "Building LAMMPS as a library"_start_4 :b
2.5 "Running LAMMPS"_start_5 :b
2.6 "Command-line options"_start_6 :b
2.7 "Screen output"_start_7 :b
2.8 "Tips for users of previous versions"_start_8 :ule,b
"Commands"_Section_commands.html :l
3.1 "LAMMPS input script"_cmd_1 :ulb,b
3.2 "Parsing rules"_cmd_2 :b

View File

@ -527,9 +527,9 @@ These are additional commands in USER packages, which can be used if
"LAMMPS is built with the appropriate
package"_Section_start.html#start_3.
"dump custom/vtk"_dump_custom_vtk.html,
"dump nc"_dump_nc.html,
"dump nc/mpiio"_dump_nc.html,
"dump netcdf"_dump_netcdf.html,
"dump netcdf/mpiio"_dump_netcdf.html,
"dump vtk"_dump_vtk.html,
"group2ndx"_group2ndx.html,
"ndx2group"_group2ndx.html,
"temper/grem"_temper_grem.html :tb(c=3,ea=c)
@ -618,6 +618,7 @@ USER-INTEL, k = KOKKOS, o = USER-OMP, t = OPT.
"press/berendsen"_fix_press_berendsen.html,
"print"_fix_print.html,
"property/atom"_fix_property_atom.html,
"python"_fix_python.html,
"qeq/comb (o)"_fix_qeq_comb.html,
"qeq/dynamic"_fix_qeq.html,
"qeq/fire"_fix_qeq.html,
@ -931,6 +932,8 @@ KOKKOS, o = USER-OMP, t = OPT.
"gran/hertz/history (o)"_pair_gran.html,
"gran/hooke (o)"_pair_gran.html,
"gran/hooke/history (o)"_pair_gran.html,
"gw"_pair_gw.html,
"gw/zbl"_pair_gw.html,
"hbond/dreiding/lj (o)"_pair_hbond_dreiding.html,
"hbond/dreiding/morse (o)"_pair_hbond_dreiding.html,
"kim"_pair_kim.html,
@ -982,6 +985,7 @@ KOKKOS, o = USER-OMP, t = OPT.
"peri/pmb (o)"_pair_peri.html,
"peri/ves"_pair_peri.html,
"polymorphic"_pair_polymorphic.html,
"python"_pair_python.html,
"reax"_pair_reax.html,
"rebo (o)"_pair_airebo.html,
"resquared (go)"_pair_resquared.html,
@ -1016,6 +1020,7 @@ package"_Section_start.html#start_3.
"dpd/fdt/energy"_pair_dpd_fdt.html,
"eam/cd (o)"_pair_eam.html,
"edip (o)"_pair_edip.html,
"edip/multi"_pair_edip.html,
"eff/cut"_pair_eff.html,
"exp6/rx"_pair_exp6_rx.html,
"gauss/cut"_pair_gauss.html,
@ -1052,7 +1057,7 @@ package"_Section_start.html#start_3.
"oxdna2/excv"_pair_oxdna2.html,
"oxdna2/stk"_pair_oxdna2.html,
"quip"_pair_quip.html,
"reax/c (k)"_pair_reax_c.html,
"reax/c (k)"_pair_reaxc.html,
"smd/hertz"_pair_smd_hertz.html,
"smd/tlsph"_pair_smd_tlsph.html,
"smd/triangulated/surface"_pair_smd_triangulated_surface.html,
@ -1155,7 +1160,7 @@ USER-OMP, t = OPT.
"zero"_dihedral_zero.html,
"hybrid"_dihedral_hybrid.html,
"charmm (ko)"_dihedral_charmm.html,
"charmmfsh"_dihedral_charmm.html,
"charmmfsw"_dihedral_charmm.html,
"class2 (ko)"_dihedral_class2.html,
"harmonic (io)"_dihedral_harmonic.html,
"helix (o)"_dihedral_helix.html,

View File

@ -11171,6 +11171,12 @@ Self-explanatory. :dd
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
{Energy tally does not account for 'zero yes'} :dt
The energy removed by using the 'zero yes' flag is not accounted

View File

@ -215,7 +215,7 @@ documentation for the formula it computes.
"special_bonds"_special_bonds.html charmm
"special_bonds"_special_bonds.html amber :ul
NOTE: For CHARMM, the newer {charmmfsw} or {charmmfsh} styles were
NOTE: For CHARMM, newer {charmmfsw} or {charmmfsh} styles were
released in March 2017. We recommend they be used instead of the
older {charmm} styles. See discussion of the differences on the "pair
charmm"_pair_charmm.html and "dihedral charmm"_dihedral_charmm.html

View File

@ -249,8 +249,12 @@ Pizza.py WWW site"_pizza. :l
Specialized features :h5
These are LAMMPS capabilities which you may not think of as typical
molecular dynamics options:
LAMMPS can be built with optional packages which implement a variety
of additional capabilities. An overview of all the packages is "given
here"_Section_packages.html.
These are some LAMMPS capabilities which you may not think of as
typical classical molecular dynamics options:
"static"_balance.html and "dynamic load-balancing"_fix_balance.html
"generalized aspherical particles"_body.html
@ -515,7 +519,7 @@ the packages they have written are somewhat unique to LAMMPS and the
code would not be as general-purpose as it is without their expertise
and efforts.
Axel Kohlmeyer (Temple U), akohlmey at gmail.com, SVN and Git repositories, indefatigable mail list responder, USER-CG-CMM and USER-OMP packages
Axel Kohlmeyer (Temple U), akohlmey at gmail.com, SVN and Git repositories, indefatigable mail list responder, USER-CGSDK and USER-OMP packages
Roy Pollock (LLNL), Ewald and PPPM solvers
Mike Brown (ORNL), brownw at ornl.gov, GPU package
Greg Wagner (Sandia), gjwagne at sandia.gov, MEAM package for MEAM potential

File diff suppressed because it is too large Load Diff

View File

@ -118,18 +118,21 @@ check which version of Python you have installed, by simply typing
11.2 Overview of using Python from a LAMMPS script :link(py_2),h4
NOTE: It is not currently possible to use the "python"_python.html
command described in this section with Python 3, only with Python 2.
The C API changed from Python 2 to 3 and the LAMMPS code is not
compatible with both.
LAMMPS has several commands which can be used to invoke Python
code directly from an input script:
LAMMPS has a "python"_python.html command which can be used in an
input script to define and execute a Python function that you write
the code for. The Python function can also be assigned to a LAMMPS
python-style variable via the "variable"_variable.html command. Each
time the variable is evaluated, either in the LAMMPS input script
itself, or by another LAMMPS command that uses the variable, this will
trigger the Python function to be invoked.
"python"_python.html
"variable python"_variable.html
"fix python"_fix_python.html
"pair_style python"_pair_python.html :ul
The "python"_python.html command which can be used to define and
execute a Python function that you write the code for. The Python
function can also be assigned to a LAMMPS python-style variable via
the "variable"_variable.html command. Each time the variable is
evaluated, either in the LAMMPS input script itself, or by another
LAMMPS command that uses the variable, this will trigger the Python
function to be invoked.
The Python code for the function can be included directly in the input
script or in an auxiliary file. The function can have arguments which
@ -162,8 +165,16 @@ doc page for its python-style variables for more info, including
examples of Python code you can write for both pure Python operations
and callbacks to LAMMPS.
To run pure Python code from LAMMPS, you only need to build LAMMPS
with the PYTHON package installed:
The "fix python"_fix_python.html command can execute
Python code at selected timesteps during a simulation run.
The "pair_style python"_pair_python command allows you to define
pairwise potentials as python code which encodes a single pairwise
interaction. This is useful for rapid-developement and debugging of a
new potential.
To use any of these commands, you only need to build LAMMPS with the
PYTHON package installed:
make yes-python
make machine :pre

View File

@ -14,12 +14,11 @@ experienced users.
2.1 "What's in the LAMMPS distribution"_#start_1
2.2 "Making LAMMPS"_#start_2
2.3 "Making LAMMPS with optional packages"_#start_3
2.4 "Building LAMMPS via the Make.py script"_#start_4
2.5 "Building LAMMPS as a library"_#start_5
2.6 "Running LAMMPS"_#start_6
2.7 "Command-line options"_#start_7
2.8 "Screen output"_#start_8
2.9 "Tips for users of previous versions"_#start_9 :all(b)
2.5 "Building LAMMPS as a library"_#start_4
2.6 "Running LAMMPS"_#start_5
2.7 "Command-line options"_#start_6
2.8 "Screen output"_#start_7
2.9 "Tips for users of previous versions"_#start_8 :all(b)
:line
@ -80,7 +79,7 @@ This section has the following sub-sections:
Read this first :h5,link(start_2_1)
If you want to avoid building LAMMPS yourself, read the preceding
If you want to avoid building LAMMPS yourself, read the preceeding
section about options available for downloading and installing
executables. Details are discussed on the "download"_download page.
@ -96,7 +95,7 @@ make serial :pre
Note that on a facility supercomputer, there are often "modules"
loaded in your environment that provide the compilers and MPI you
should use. In this case, the "mpicxx" compile/link command in
Makefile.mpi should just work by accessing those modules.
Makefile.mpi should simply work by accessing those modules.
It may be the case that one of the other Makefile.machine files in the
src/MAKE sub-directories is a better match to your system (type "make"
@ -107,33 +106,35 @@ make stampede :pre
If any of these builds (with an existing Makefile.machine) works on
your system, then you're done!
If you need to install an optional package with a LAMMPS command you
want to use, and the package does not depend on an extra library, you
can simply type
make name :pre
before invoking (or re-invoking) the above steps. "Name" is the
lower-case name of the package, e.g. replica or user-misc.
If you want to do one of the following:
use optional LAMMPS features that require additional libraries
use optional packages that require additional libraries
use optional accelerator packages that require special compiler/linker settings
run on a specialized platform that has its own compilers, settings, or other libs to use :ul
use a LAMMPS command that requires an extra library (e.g. "dump image"_dump_image.html)
build with a package that requires an extra library
build with an accelerator package that requires special compiler/linker settings
run on a machine that has its own compilers, settings, or libraries :ul
then building LAMMPS is more complicated. You may need to find where
auxiliary libraries exist on your machine or install them if they
don't. You may need to build additional libraries that are part of
the LAMMPS package, before building LAMMPS. You may need to edit a
extra libraries exist on your machine or install them if they don't.
You may need to build extra libraries that are included in the LAMMPS
distribution, before building LAMMPS itself. You may need to edit a
Makefile.machine file to make it compatible with your system.
Note that there is a Make.py tool in the src directory that automates
several of these steps, but you still have to know what you are doing.
"Section 2.4"_#start_4 below describes the tool. It is a convenient
way to work with installing/un-installing various packages, the
Makefile.machine changes required by some packages, and the auxiliary
libraries some of them use.
Please read the following sections carefully. If you are not
comfortable with makefiles, or building codes on a Unix platform, or
running an MPI job on your machine, please find a local expert to help
you. Many compilation, linking, and run problems that users have are
often not really LAMMPS issues - they are peculiar to the user's
system, compilers, libraries, etc. Such questions are better answered
by a local expert.
you. Many compilation, linking, and run problems users experience are
often not LAMMPS issues - they are peculiar to the user's system,
compilers, libraries, etc. Such questions are better answered by a
local expert.
If you have a build problem that you are convinced is a LAMMPS issue
(e.g. the compiler complains about a line of LAMMPS source code), then
@ -251,7 +252,7 @@ re-compile, after typing "make clean" (which will describe different
clean options).
The LMP_INC variable is used to include options that turn on ifdefs
within the LAMMPS code. The options that are currently recognized are:
within the LAMMPS code. The options that are currently recogized are:
-DLAMMPS_GZIP
-DLAMMPS_JPEG
@ -362,7 +363,7 @@ installed on your platform. If MPI is installed on your system in the
usual place (under /usr/local), you also may not need to specify these
3 variables, assuming /usr/local is in your path. On some large
parallel machines which use "modules" for their compile/link
environments, you may simply need to include the correct module in
environements, you may simply need to include the correct module in
your build environment, before building LAMMPS. Or the parallel
machine may have a vendor-provided MPI which the compiler has no
trouble finding.
@ -430,7 +431,7 @@ use the KISS library described above.
You may also need to set the FFT_INC, FFT_PATH, and FFT_LIB variables,
so the compiler and linker can find the needed FFT header and library
files. Note that on some large parallel machines which use "modules"
for their compile/link environments, you may simply need to include
for their compile/link environements, you may simply need to include
the correct module in your build environment. Or the parallel machine
may have a vendor-provided FFT library which the compiler has no
trouble finding.
@ -450,7 +451,7 @@ you must also manually specify the correct library, namely -lsfftw or
The FFT_INC variable also allows for a -DFFT_SINGLE setting that will
use single-precision FFTs with PPPM, which can speed-up long-range
calculations, particularly in parallel or on GPUs. Fourier transform
calulations, particularly in parallel or on GPUs. Fourier transform
and related PPPM operations are somewhat insensitive to floating point
truncation errors and thus do not always need to be performed in
double precision. Using the -DFFT_SINGLE setting trades off a little
@ -508,13 +509,13 @@ You should get the executable lmp_foo when the build is complete.
Errors that can occur when making LAMMPS: h5 :link(start_2_3)
NOTE: If an error occurs when building LAMMPS, the compiler or linker
will state very explicitly what the problem is. The error message
should give you a hint as to which of the steps above has failed, and
what you need to do in order to fix it. Building a code with a
Makefile is a very logical process. The compiler and linker need to
find the appropriate files and those files need to be compatible with
LAMMPS source files. When a make fails, there is usually a very
If an error occurs when building LAMMPS, the compiler or linker will
state very explicitly what the problem is. The error message should
give you a hint as to which of the steps above has failed, and what
you need to do in order to fix it. Building a code with a Makefile is
a very logical process. The compiler and linker need to find the
appropriate files and those files need to be compatible with LAMMPS
settings and source files. When a make fails, there is usually a very
simple reason, which you or a local expert will need to fix.
Here are two non-obvious errors that can occur:
@ -557,7 +558,8 @@ Typing "make clean-all" or "make clean-machine" will delete *.o object
files created when LAMMPS is built, for either all builds or for a
particular machine.
Changing the LAMMPS size limits via -DLAMMPS_SMALLBIG or -DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL :h6
Changing the LAMMPS size limits via -DLAMMPS_SMALLBIG or
-DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL :h6
As explained above, any of these 3 settings can be specified on the
LMP_INC line in your low-level src/MAKE/Makefile.foo.
@ -653,13 +655,7 @@ This section has the following sub-sections:
2.3.1 "Package basics"_#start_3_1
2.3.2 "Including/excluding packages"_#start_3_2
2.3.3 "Packages that require extra libraries"_#start_3_3
2.3.4 "Packages that require Makefile.machine settings"_#start_3_4 :all(b)
Note that the following "Section 2.4"_#start_4 describes the Make.py
tool which can be used to install/un-install packages and build the
auxiliary libraries which some of them use. It can also auto-edit a
Makefile.machine to add settings needed by some packages.
2.3.3 "Packages that require extra libraries"_#start_3_3 :all(b)
:line
@ -670,235 +666,221 @@ are always included, plus optional packages. Packages are groups of
files that enable a specific set of features. For example, force
fields for molecular systems or granular systems are in packages.
"Section 4"_Section_packages.html in the manual has details
about all the packages, including specific instructions for building
LAMMPS with each package, which are covered in a more general manner
"Section 4"_Section_packages.html in the manual has details about all
the packages, which come in two flavors: [standard] and [user]
packages. It also has specific instructions for building LAMMPS with
any package which requires an extra library. General instructions are
below.
You can see the list of all packages by typing "make package" from
within the src directory of the LAMMPS distribution. This also lists
various make commands that can be used to manipulate packages.
within the src directory of the LAMMPS distribution. It will also
list various make commands that can be used to manage packages.
If you use a command in a LAMMPS input script that is part of a
package, you must have built LAMMPS with that package, else you will
get an error that the style is invalid or the command is unknown.
Every command's doc page specifies if it is part of a package. You can
also type
Every command's doc page specfies if it is part of a package. You can
type
lmp_machine -h :pre
to run your executable with the optional "-h command-line
switch"_#start_7 for "help", which will simply list the styles and
commands known to your executable, and immediately exit.
There are two kinds of packages in LAMMPS, standard and user packages.
More information about the contents of standard and user packages is
given in "Section 4"_Section_packages.html of the manual. The
difference between standard and user packages is as follows:
Standard packages, such as molecule or kspace, are supported by the
LAMMPS developers and are written in a syntax and style consistent
with the rest of LAMMPS. This means we will answer questions about
them, debug and fix them if necessary, and keep them compatible with
future changes to LAMMPS.
User packages, such as user-atc or user-omp, have been contributed by
users, and always begin with the user prefix. If they are a single
command (single file), they are typically in the user-misc package.
Otherwise, they are a set of files grouped together which add a
specific functionality to the code.
User packages don't necessarily meet the requirements of the standard
packages. If you have problems using a feature provided in a user
package, you may need to contact the contributor directly to get help.
Information on how to submit additions you make to LAMMPS as single
files or either a standard or user-contributed package are given in
"this section"_Section_modify.html#mod_15 of the documentation.
switch"_#start_7 for "help", which will list the styles and commands
known to your executable, and immediately exit.
:line
Including/excluding packages :h5,link(start_3_2)
To use (or not use) a package you must include it (or exclude it)
before building LAMMPS. From the src directory, this is typically as
simple as:
To use (or not use) a package you must install it (or un-install it)
before building LAMMPS. From the src directory, this is as simple as:
make yes-colloid
make mpi :pre
or
make no-manybody
make no-user-omp
make mpi :pre
NOTE: You should NOT include/exclude packages and build LAMMPS in a
NOTE: You should NOT install/un-install packages and build LAMMPS in a
single make command using multiple targets, e.g. make yes-colloid mpi.
This is because the make procedure creates a list of source files that
will be out-of-date for the build if the package configuration changes
within the same command.
Some packages have individual files that depend on other packages
being included. LAMMPS checks for this and does the right thing.
I.e. individual files are only included if their dependencies are
already included. Likewise, if a package is excluded, other files
Any package can be installed or not in a LAMMPS build, independent of
all other packages. However, some packages include files derived from
files in other packages. LAMMPS checks for this and does the right
thing. I.e. individual files are only included if their dependencies
are already included. Likewise, if a package is excluded, other files
dependent on that package are also excluded.
NOTE: The one exception is that we do not recommend building with both
the KOKKOS package installed and any of the other acceleration
packages (GPU, OPT, USER-INTEL, USER-OMP) also installed. This is
because of how Kokkos sometimes builds using a wrapper compiler which
can make it difficult to invoke all the compile/link flags correctly
for both Kokkos and non-Kokkos files.
If you will never run simulations that use the features in a
particular packages, there is no reason to include it in your build.
For some packages, this will keep you from having to build auxiliary
libraries (see below), and will also produce a smaller executable
which may run a bit faster.
For some packages, this will keep you from having to build extra
libraries, and will also produce a smaller executable which may run a
bit faster.
When you download a LAMMPS tarball, these packages are pre-installed
in the src directory: KSPACE, MANYBODY,MOLECULE, because they are so
commonly used. When you download LAMMPS source files from the SVN or
Git repositories, no packages are pre-installed.
When you download a LAMMPS tarball, three packages are pre-installed
in the src directory -- KSPACE, MANYBODY, MOLECULE -- because they are
so commonly used. When you download LAMMPS source files from the SVN
or Git repositories, no packages are pre-installed.
Packages are included or excluded by typing "make yes-name" or "make
no-name", where "name" is the name of the package in lower-case, e.g.
name = kspace for the KSPACE package or name = user-atc for the
USER-ATC package. You can also type "make yes-standard", "make
no-standard", "make yes-std", "make no-std", "make yes-user", "make
no-user", "make yes-lib", "make no-lib", "make yes-all", or "make
no-all" to include/exclude various sets of packages. Type "make
package" to see all of the package-related make options.
Packages are installed or un-installed by typing
NOTE: Inclusion/exclusion of a package works by simply moving files
back and forth between the main src directory and sub-directories with
the package name (e.g. src/KSPACE, src/USER-ATC), so that the files
are seen or not seen when LAMMPS is built. After you have included or
excluded a package, you must re-build LAMMPS.
make yes-name
make no-name :pre
Additional package-related make options exist to help manage LAMMPS
files that exist in both the src directory and in package
sub-directories. You do not normally need to use these commands
unless you are editing LAMMPS files or have downloaded a patch from
the LAMMPS WWW site.
where "name" is the name of the package in lower-case, e.g. name =
kspace for the KSPACE package or name = user-atc for the USER-ATC
package. You can also type any of these commands:
Typing "make package-update" or "make pu" will overwrite src files
with files from the package sub-directories if the package has been
included. It should be used after a patch is installed, since patches
only update the files in the package sub-directory, but not the src
files. Typing "make package-overwrite" will overwrite files in the
package sub-directories with src files.
make yes-all | install all packages
make no-all | un-install all packages
make yes-standard or make yes-std | install standard packages
make no-standard or make no-std| un-install standard packages
make yes-user | install user packages
make no-user | un-install user packages
make yes-lib | install packages that require extra libraries
make no-lib | un-install packages that require extra libraries
make yes-ext | install packages that require external libraries
make no-ext | un-install packages that require external libraries :tb(s=|)
which install/un-install various sets of packages. Typing "make
package" will list all the these commands.
NOTE: Installing or un-installing a package works by simply moving
files back and forth between the main src directory and
sub-directories with the package name (e.g. src/KSPACE, src/USER-ATC),
so that the files are included or excluded when LAMMPS is built.
After you have installed or un-installed a package, you must re-build
LAMMPS for the action to take effect.
The following make commands help manage files that exist in both the
src directory and in package sub-directories. You do not normally
need to use these commands unless you are editing LAMMPS files or have
downloaded a patch from the LAMMPS web site.
Typing "make package-status" or "make ps" will show which packages are
currently included. For those that are included, it will list any
currently installed. For those that are installed, it will list any
files that are different in the src directory and package
sub-directory. Typing "make package-diff" lists all differences
between these files. Again, type "make package" to see all of the
package-related make options.
sub-directory.
Typing "make package-update" or "make pu" will overwrite src files
with files from the package sub-directories if the package is
installed. It should be used after a patch has been applied, since
patches only update the files in the package sub-directory, but not
the src files.
Typing "make package-overwrite" will overwrite files in the package
sub-directories with src files.
Typing "make package-diff" lists all differences between these files.
Again, just type "make package" to see all of the package-related make
options.
:line
Packages that require extra libraries :h5,link(start_3_3)
A few of the standard and user packages require additional auxiliary
libraries. Many of them are provided with LAMMPS, in which case they
must be compiled first, before LAMMPS is built, if you wish to include
that package. If you get a LAMMPS build error about a missing
library, this is likely the reason. See the
"Section 4"_Section_packages.html doc page for a list of
packages that have these kinds of auxiliary libraries.
A few of the standard and user packages require extra libraries. See
"Section 4"_Section_packages.html for two tables of packages which
indicate which ones require libraries. For each such package, the
Section 4 doc page gives details on how to build the extra library,
including how to download it if necessary. The basic ideas are
summarized here.
The lib directory in the distribution has sub-directories with package
names that correspond to the needed auxiliary libs, e.g. lib/gpu.
Each sub-directory has a README file that gives more details. Code
for most of the auxiliary libraries is included in that directory.
Examples are the USER-ATC and MEAM packages.
[System libraries:]
A few of the lib sub-directories do not include code, but do include
instructions (and sometimes scripts) that automate the process of
downloading the auxiliary library and installing it so LAMMPS can link
to it. Examples are the KIM, VORONOI, USER-MOLFILE, and USER-SMD
packages.
Packages in the tables "Section 4"_Section_packages.html with a "sys"
in the last column link to system libraries that typically already
exist on your machine. E.g. the python package links to a system
Python library. If your machine does not have the required library,
you will have to download and install it on your machine, in either
the system or user space.
The lib/python directory (for the PYTHON package) contains only a
choice of Makefile.lammps.* files. This is because no auxiliary code
or libraries are needed, only the Python library and other system libs
that should already available on your system. However, the
Makefile.lammps file is needed to tell LAMMPS which libs to use and
where to find them.
[Internal libraries:]
For libraries with provided code, the sub-directory README file
(e.g. lib/atc/README) has instructions on how to build that library.
This information is also summarized in "Section
4"_Section_packages.html. Typically this is done by typing
something like:
Packages in the tables "Section 4"_Section_packages.html with an "int"
in the last column link to internal libraries whose source code is
included with LAMMPS, in the lib/name directory where name is the
package name. You must first build the library in that directory
before building LAMMPS with that package installed. E.g. the gpu
package links to a library you build in the lib/gpu dir. You can
often do the build in one step by typing "make lib-name args=..."
from the src dir, with appropriate arguments. You can leave off the
args to see a help message. See "Section 4"_Section_packages.html for
details for each package.
make -f Makefile.g++ :pre
[External libraries:]
If one of the provided Makefiles is not appropriate for your system
you will need to edit or add one. Note that all the Makefiles have a
setting for EXTRAMAKE at the top that specifies a Makefile.lammps.*
file.
Packages in the tables "Section 4"_Section_packages.html with an "ext"
in the last column link to exernal libraries whose source code is not
included with LAMMPS. You must first download and install the library
before building LAMMPS with that package installed. E.g. the voronoi
package links to the freely available "Voro++ library"_voro_home2. You
can often do the download/build in one step by typing "make lib-name
args=..." from the src dir, with appropriate arguments. You can leave
off the args to see a help message. See "Section
4"_Section_packages.html for details for each package.
If the library build is successful, it will produce 2 files in the lib
directory:
:link(voro_home2,http://math.lbl.gov/voro++)
libpackage.a
Makefile.lammps :pre
[Possible errors:]
The Makefile.lammps file will typically be a copy of one of the
Makefile.lammps.* files in the library directory.
There are various common errors which can occur when building extra
libraries or when building LAMMPS with packages that require the extra
libraries.
Note that you must insure that the settings in Makefile.lammps are
appropriate for your system. If they are not, the LAMMPS build may
fail. To fix this, you can edit or create a new Makefile.lammps.*
file for your system, and copy it to Makefile.lammps.
If you cannot build the extra library itself successfully, you may
need to edit or create an appropriate Makefile for your machine, e.g.
with appropriate compiler or system settings. Provided makefiles are
typically in the lib/name directory. E.g. see the Makefile.* files in
lib/gpu.
As explained in the lib/package/README files, the settings in
Makefile.lammps are used to specify additional system libraries and
their locations so that LAMMPS can build with the auxiliary library.
For example, if the MEAM package is used, the auxiliary library
consists of F90 code, built with a Fortran complier. To link that
library with LAMMPS (a C++ code) via whatever C++ compiler LAMMPS is
built with, typically requires additional Fortran-to-C libraries be
included in the link. Another example are the BLAS and LAPACK
libraries needed to use the USER-ATC or USER-AWPMD packages.
The LAMMPS build often uses settings in a lib/name/Makefile.lammps
file which either exists in the LAMMPS distribution or is created or
copied from a lib/name/Makefile.lammps.* file when the library is
built. If those settings are not correct for your machine you will
need to edit or create an appropriate Makefile.lammps file.
For libraries without provided code, the sub-directory README file has
information on where to download the library and how to build it,
e.g. lib/voronoi/README and lib/smd/README. The README files also
describe how you must either (a) create soft links, via the "ln"
command, in those directories to point to where you built or installed
the packages, or (b) check or edit the Makefile.lammps file in the
same directory to provide that information.
Package-specific details for these steps are given in "Section
4"_Section_packages.html an in README files in the lib/name
directories.
Some of the sub-directories, e.g. lib/voronoi, also have an install.py
script which can be used to automate the process of
downloading/building/installing the auxiliary library, and setting the
needed soft links. Type "python install.py" for further instructions.
[Compiler options needed for accelerator packages:]
As with the sub-directories containing library code, if the soft links
or settings in the lib/package/Makefile.lammps files are not correct,
the LAMMPS build will typically fail.
Several packages contain code that is optimized for specific hardware,
e.g. CPU, KNL, or GPU. These are the OPT, GPU, KOKKOS, USER-INTEL,
and USER-OMP packages. Compiling and linking the source files in
these accelerator packages for optimal performance requires specific
settings in the Makefile.machine file you use.
:line
Packages that require Makefile.machine settings :h5,link(start_3_4)
A few packages require specific settings in Makefile.machine, to
either build or use the package effectively. These are the
USER-INTEL, KOKKOS, USER-OMP, and OPT packages, used for accelerating
code performance on CPUs or other hardware, as discussed in "Section
5.3"_Section_accelerate.html#acc_3.
A summary of what Makefile.machine changes are needed for each of
these packages is given in "Section 4"_Section_packages.html.
The details are given on the doc pages that describe each of these
accelerator packages in detail:
A summary of the Makefile.machine settings needed for each of these
packages is given in "Section 4"_Section_packages.html. More info is
given on the doc pages that describe each package in detail:
5.3.1 "USER-INTEL package"_accelerate_intel.html
5.3.2 "GPU package"_accelerate_intel.html
5.3.3 "KOKKOS package"_accelerate_kokkos.html
5.3.4 "USER-OMP package"_accelerate_omp.html
5.3.5 "OPT package"_accelerate_opt.html :all(b)
You can also look at the following machine Makefiles in
src/MAKE/OPTIONS, which include the changes. Note that the USER-INTEL
and KOKKOS packages allow for settings that build LAMMPS for different
hardware. The USER-INTEL package builds for CPU and the Xeon Phi, the
KOKKOS package builds for OpenMP, GPUs (Cuda), and the Xeon Phi.
You can also use or examine the following machine Makefiles in
src/MAKE/OPTIONS, which include the settings. Note that the
USER-INTEL and KOKKOS packages can use settings that build LAMMPS for
different hardware. The USER-INTEL package can be compiled for Intel
CPUs and KNLs; the KOKKOS package builds for CPUs (OpenMP), GPUs
(Cuda), and Intel KNLs.
Makefile.intel_cpu
Makefile.intel_phi
@ -908,127 +890,9 @@ Makefile.kokkos_phi
Makefile.omp
Makefile.opt :ul
Also note that the Make.py tool, described in the next "Section
2.4"_#start_4 can automatically add the needed info to an existing
machine Makefile, using simple command-line arguments.
:line
2.4 Building LAMMPS via the Make.py tool :h4,link(start_4)
The src directory includes a Make.py script, written in Python, which
can be used to automate various steps of the build process. It is
particularly useful for working with the accelerator packages, as well
as other packages which require auxiliary libraries to be built.
The goal of the Make.py tool is to allow any complex multi-step LAMMPS
build to be performed as a single Make.py command. And you can
archive the commands, so they can be re-invoked later via the -r
(redo) switch. If you find some LAMMPS build procedure that can't be
done in a single Make.py command, let the developers know, and we'll
see if we can augment the tool.
You can run Make.py from the src directory by typing either:
Make.py -h
python Make.py -h :pre
which will give you help info about the tool. For the former to work,
you may need to edit the first line of Make.py to point to your local
Python. And you may need to insure the script is executable:
chmod +x Make.py :pre
Here are examples of build tasks you can perform with Make.py:
Install/uninstall packages: Make.py -p no-lib kokkos omp intel
Build specific auxiliary libs: Make.py -a lib-atc lib-meam
Build libs for all installed packages: Make.py -p cuda gpu -gpu mode=double arch=31 -a lib-all
Create a Makefile from scratch with compiler and MPI settings: Make.py -m none -cc g++ -mpi mpich -a file
Augment Makefile.serial with settings for installed packages: Make.py -p intel -intel cpu -m serial -a file
Add JPG and FFTW support to Makefile.mpi: Make.py -m mpi -jpg -fft fftw -a file
Build LAMMPS with a parallel make using Makefile.mpi: Make.py -j 16 -m mpi -a exe
Build LAMMPS and libs it needs using Makefile.serial with accelerator settings: Make.py -p gpu intel -intel cpu -a lib-all file serial :tb(s=:)
The bench and examples directories give Make.py commands that can be
used to build LAMMPS with the various packages and options needed to
run all the benchmark and example input scripts. See these files for
more details:
bench/README
bench/FERMI/README
bench/KEPLER/README
bench/PHI/README
examples/README
examples/accelerate/README
examples/accelerate/make.list :ul
All of the Make.py options and syntax help can be accessed by using
the "-h" switch.
E.g. typing "Make.py -h" gives
Syntax: Make.py switch args ...
switches can be listed in any order
help switch:
-h prints help and syntax for all other specified switches
switch for actions:
-a lib-all, lib-dir, clean, file, exe or machine
list one or more actions, in any order
machine is a Makefile.machine suffix, must be last if used
one-letter switches:
-d (dir), -j (jmake), -m (makefile), -o (output),
-p (packages), -r (redo), -s (settings), -v (verbose)
switches for libs:
-atc, -awpmd, -colvars, -cuda
-gpu, -meam, -poems, -qmmm, -reax
switches for build and makefile options:
-intel, -kokkos, -cc, -mpi, -fft, -jpg, -png :pre
Using the "-h" switch with other switches and actions gives additional
info on all the other specified switches or actions. The "-h" can be
anywhere in the command-line and the other switches do not need their
arguments. E.g. type "Make.py -h -d -atc -intel" will print:
-d dir
dir = LAMMPS home dir
if -d not specified, working dir must be lammps/src :pre
-atc make=suffix lammps=suffix2
all args are optional and can be in any order
make = use Makefile.suffix (def = g++)
lammps = use Makefile.lammps.suffix2 (def = EXTRAMAKE in makefile) :pre
-intel mode
mode = cpu or phi (def = cpu)
build Intel package for CPU or Xeon Phi :pre
Note that Make.py never overwrites an existing Makefile.machine.
Instead, it creates src/MAKE/MINE/Makefile.auto, which you can save or
rename if desired. Likewise it creates an executable named
src/lmp_auto, which you can rename using the -o switch if desired.
The most recently executed Make.py command is saved in
src/Make.py.last. You can use the "-r" switch (for redo) to re-invoke
the last command, or you can save a sequence of one or more Make.py
commands to a file and invoke the file of commands using "-r". You
can also label the commands in the file and invoke one or more of them
by name.
A typical use of Make.py is to start with a valid Makefile.machine for
your system, that works for a vanilla LAMMPS build, i.e. when optional
packages are not installed. You can then use Make.py to add various
settings (FFT, JPG, PNG) to the Makefile.machine as well as change its
compiler and MPI options. You can also add additional packages to the
build, as well as build the needed supporting libraries.
You can also use Make.py to create a new Makefile.machine from
scratch, using the "-m none" switch, if you also specify what compiler
and MPI options to use, via the "-cc" and "-mpi" switches.
:line
2.5 Building LAMMPS as a library :h4,link(start_5)
2.4 Building LAMMPS as a library :h4,link(start_4)
LAMMPS can be built as either a static or shared library, which can
then be called from another application or a scripting language. See
@ -1064,7 +928,7 @@ src/MAKE/Makefile.foo and perform the build in the directory
Obj_shared_foo. This is so that each file can be compiled with the
-fPIC flag which is required for inclusion in a shared library. The
build will create the file liblammps_foo.so which another application
can link to dynamically. It will also create a soft link liblammps.so,
can link to dyamically. It will also create a soft link liblammps.so,
which will point to the most recently built shared library. This is
the file the Python wrapper loads by default.
@ -1150,7 +1014,7 @@ interface and how to extend it for your needs.
:line
2.6 Running LAMMPS :h4,link(start_6)
2.5 Running LAMMPS :h4,link(start_5)
By default, LAMMPS runs by reading commands from standard input. Thus
if you run the LAMMPS executable by itself, e.g.
@ -1282,7 +1146,7 @@ more processors or setup a smaller problem.
:line
2.7 Command-line options :h4,link(start_7)
2.6 Command-line options :h4,link(start_6)
At run time, LAMMPS recognizes several optional command-line switches
which may be used in any order. Either the full word or a one-or-two
@ -1416,8 +1280,8 @@ LAMMPS is compiled with CUDA=yes.
numa Nm :pre
This option is only relevant when using pthreads with hwloc support.
In this case Nm defines the number of NUMA regions (typically sockets)
on a node which will be utilized by a single MPI rank. By default Nm
In this case Nm defines the number of NUMA regions (typicaly sockets)
on a node which will be utilizied by a single MPI rank. By default Nm
= 1. If this option is used the total number of worker-threads per
MPI rank is threads*numa. Currently it is always almost better to
assign at least one MPI rank per NUMA region, and leave numa set to
@ -1481,7 +1345,7 @@ replica runs on on one or a few processors. Note that with MPI
installed on a machine (e.g. your desktop), you can run on more
(virtual) processors than you have physical processors.
To run multiple independent simulations from one input script, using
To run multiple independent simulatoins from one input script, using
multiple partitions, see "Section 6.4"_Section_howto.html#howto_4
of the manual. World- and universe-style "variables"_variable.html
are useful in this context.
@ -1712,7 +1576,7 @@ negative numeric value. It is OK if the first value1 starts with a
:line
2.8 LAMMPS screen output :h4,link(start_8)
2.7 LAMMPS screen output :h4,link(start_7)
As LAMMPS reads an input script, it prints information to both the
screen and a log file about significant actions it takes to setup a
@ -1760,7 +1624,7 @@ The first section provides a global loop timing summary. The {loop time}
is the total wall time for the section. The {Performance} line is
provided for convenience to help predicting the number of loop
continuations required and for comparing performance with other,
similar MD codes. The {CPU use} line provides the CPU utilization per
similar MD codes. The {CPU use} line provides the CPU utilzation per
MPI task; it should be close to 100% times the number of OpenMP
threads (or 1 of no OpenMP). Lower numbers correspond to delays due
to file I/O or insufficient thread utilization.
@ -1868,7 +1732,7 @@ communication, roughly 75% in the example above.
:line
2.9 Tips for users of previous LAMMPS versions :h4,link(start_9)
2.8 Tips for users of previous LAMMPS versions :h4,link(start_8)
The current C++ began with a complete rewrite of LAMMPS 2001, which
was written in F90. Features of earlier versions of LAMMPS are listed

View File

@ -369,15 +369,18 @@ supports it. It has its own WWW page at
msi2lmp tool :h4,link(msi)
The msi2lmp sub-directory contains a tool for creating LAMMPS input
data files from BIOVIA's Materias Studio files (formerly Accelrys'
The msi2lmp sub-directory contains a tool for creating LAMMPS template
input and data files from BIOVIA's Materias Studio files (formerly Accelrys'
Insight MD code, formerly MSI/Biosym and its Discover MD code).
This tool was written by John Carpenter (Cray), Michael Peachey
(Cray), and Steve Lustig (Dupont). Several people contributed changes
to remove bugs and adapt its output to changes in LAMMPS.
See the README file for more information.
This tool has several known limitations and is no longer under active
development, so there are no changes except for the occasional bugfix.
See the README file in the tools/msi2lmp folder for more information.
:line

View File

@ -69,8 +69,9 @@ not {hardware thread}.
For Intel Xeon CPUs:
Edit src/MAKE/OPTIONS/Makefile.intel_cpu_intelmpi as necessary. :ulb,l
If using {kspace_style pppm} in the input script, add "neigh_modify binsize 3" and "kspace_modify diff ad" to the input script for better
performance. :l
If using {kspace_style pppm} in the input script, add "neigh_modify binsize cutoff" and "kspace_modify diff ad" to the input script for better
performance. Cutoff should be roughly the neighbor list cutoff. By
default the binsize is half the neighbor list cutoff. :l
"-pk intel 0 omp 2 -sf intel" added to LAMMPS command-line :l
:ule

View File

@ -415,15 +415,15 @@ For binding threads with the KOKKOS OMP option, use thread affinity
environment variables to force binding. With OpenMP 3.1 (gcc 4.7 or
later, intel 12 or later) setting the environment variable
OMP_PROC_BIND=true should be sufficient. For binding threads with the
KOKKOS pthreads option, compile LAMMPS the KOKKOS HWLOC=yes option, as
discussed in "Section 2.3.4"_Sections_start.html#start_3_4 of the
manual.
KOKKOS pthreads option, compile LAMMPS the KOKKOS HWLOC=yes option
(see "this section"_Section_packages.html#KOKKOS of the manual for
details).
[Running on GPUs:]
Insure the -arch setting in the machine makefile you are using,
e.g. src/MAKE/Makefile.cuda, is correct for your GPU hardware/software
(see "this section"_Section_start.html#start_3_4 of the manual for
e.g. src/MAKE/Makefile.cuda, is correct for your GPU hardware/software.
(see "this section"_Section_packages.html#KOKKOS of the manual for
details).
The -np setting of the mpirun command should set the number of MPI

View File

@ -46,7 +46,7 @@ from the pair_style.
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
USER-CG-CMM package. See the "Making
USER-CGSDK package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info on packages.
[Related commands:]

View File

@ -46,9 +46,7 @@ for excluded volume interaction {oxdna/excv}, stacking {oxdna/stk}, cross-stacki
and coaxial stacking interaction {oxdna/coaxstk} as well as hydrogen-bonding interaction {oxdna/hbond} (see also documentation of
"pair_style oxdna/excv"_pair_oxdna.html). For the oxDNA2 "(Snodin)"_#oxdna2 bond style the analogous pair styles and an additional Debye-Hueckel pair
style {oxdna2/dh} have to be defined.
The coefficients
in the above example have to be kept fixed and cannot be changed without reparametrizing the entire model.
The coefficients in the above example have to be kept fixed and cannot be changed without reparametrizing the entire model.
Example input and data files for DNA duplexes can be found in examples/USER/cgdna/examples/oxDNA/ and /oxDNA2/.
A simple python setup tool which creates single straight or helical DNA strands,

View File

@ -16,7 +16,6 @@ Bond Styles :h1
bond_none
bond_nonlinear
bond_oxdna
bond_oxdna2
bond_quartic
bond_table
bond_zero

View File

@ -32,12 +32,12 @@ Commands :h1
dimension
displace_atoms
dump
dump_custom_vtk
dump_h5md
dump_image
dump_modify
dump_molfile
dump_nc
dump_netcdf
dump_vtk
echo
fix
fix_modify

View File

@ -24,7 +24,7 @@ twojmax = band limit for bispectrum components (non-negative integer) :l
R_1, R_2,... = list of cutoff radii, one for each type (distance units) :l
w_1, w_2,... = list of neighbor weights, one for each type :l
zero or more keyword/value pairs may be appended :l
keyword = {diagonal} or {rmin0} or {switchflag} or {bzeroflag} :l
keyword = {diagonal} or {rmin0} or {switchflag} or {bzeroflag} or {quadraticflag}:l
{diagonal} value = {0} or {1} or {2} or {3}
{0} = all j1, j2, j <= twojmax, j2 <= j1
{1} = subset satisfying j1 == j2
@ -36,7 +36,10 @@ keyword = {diagonal} or {rmin0} or {switchflag} or {bzeroflag} :l
{1} = use switching function
{bzeroflag} value = {0} or {1}
{0} = do not subtract B0
{1} = subtract B0 :pre
{1} = subtract B0
{quadraticflag} value = {0} or {1}
{0} = do not generate quadratic terms
{1} = generate quadratic terms :pre
:ule
[Examples:]
@ -151,7 +154,7 @@ linear mapping from radial distance to polar angle {theta0} on the
The argument {twojmax} and the keyword {diagonal} define which
bispectrum components are generated. See section below on output for a
detailed explanation of the number of bispectrum components and the
ordered in which they are listed
ordered in which they are listed.
The keyword {switchflag} can be used to turn off the switching
function.
@ -162,6 +165,14 @@ the calculated bispectrum components. This optional keyword is only
available for compute {sna/atom}, as {snad/atom} and {snav/atom}
are unaffected by the removal of constant terms.
The keyword {quadraticflag} determines whether or not the
quadratic analogs to the bispectrum quantities are generated.
These are formed by taking the outer product of the vector
of bispectrum components with itself.
See section below on output for a
detailed explanation of the number of quadratic terms and the
ordered in which they are listed.
NOTE: If you have a bonded system, then the settings of
"special_bonds"_special_bonds.html command can remove pairwise
interactions between atoms in the same bond, angle, or dihedral. This
@ -180,7 +191,7 @@ command that includes all pairs in the neighbor list.
Compute {sna/atom} calculates a per-atom array, each column
corresponding to a particular bispectrum component. The total number
of columns and the identities of the bispectrum component contained in
of columns and the identity of the bispectrum component contained in
each column depend on the values of {twojmax} and {diagonal}, as
described by the following piece of python code:
@ -213,6 +224,19 @@ block contains six sub-blocks corresponding to the {xx}, {yy}, {zz},
notation. Each of these sub-blocks contains one column for each
bispectrum component, the same as for compute {sna/atom}
For example, if {K}=30 and ntypes=1, the number of columns in the per-atom
arrays generated by {sna/atom}, {snad/atom}, and {snav/atom}
are 30, 90, and 180, respectively. With {quadratic} value=1,
the numbers of columns are 930, 2790, and 5580, respectively.
If the {quadratic} keyword value is set to 1, then additional
columns are appended to each per-atom array, corresponding to
a matrix of quantities that are products of two bispectrum components. If the
number of bispectrum components is {K}, then the number of matrix elements
is {K}^2. These are output in subblocks of {K}^2 columns, using the same
ordering of columns and sub-blocks as was used for the bispectrum
components.
These values can be accessed by any command that uses per-atom values
from a compute as input. See "Section
6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
@ -231,7 +255,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.
[Default:]
The optional keyword defaults are {diagonal} = 0, {rmin0} = 0,
{switchflag} = 1, {bzeroflag} = 0.
{switchflag} = 1, {bzeroflag} = 1, {quadraticflag} = 0,
:line

View File

@ -10,25 +10,25 @@ dihedral_style charmm command :h3
dihedral_style charmm/intel command :h3
dihedral_style charmm/kk command :h3
dihedral_style charmm/omp command :h3
dihedral_style charmmfsh command :h3
dihedral_style charmmfsw command :h3
[Syntax:]
dihedral_style style :pre
style = {charmm} or {charmmfsh} :ul
style = {charmm} or {charmmfsw} :ul
[Examples:]
dihedral_style charmm
dihedral_style charmmfsh
dihedral_style charmmfsw
dihedral_coeff 1 0.2 1 180 1.0
dihedral_coeff 2 1.8 1 0 1.0
dihedral_coeff 1 3.1 2 180 0.5 :pre
[Description:]
The {charmm} and {charmmfsh} dihedral styles use the potential
The {charmm} and {charmmfsw} dihedral styles use the potential
:c,image(Eqs/dihedral_charmm.jpg)
@ -38,10 +38,12 @@ field (see comment on weighting factors below). See
"(Cornell)"_#dihedral-Cornell for a description of the AMBER force
field.
NOTE: The newer {charmmfsh} style was released in March 2017. We
NOTE: The newer {charmmfsw} style was released in March 2017. We
recommend it be used instead of the older {charmm} style when running
a simulation with the CHARMM force field and Coulomb cutoffs, via the
"pair_style lj/charmmfsw/coul/charmmfsh"_pair_charmm.html command.
a simulation with the CHARMM force field, either with long-range
Coulombics or a Coulomb cutoff, via the "pair_style
lj/charmmfsw/coul/long"_pair_charmm.html and "pair_style
lj/charmmfsw/coul/charmmfsh"_pair_charmm.html commands respectively.
Otherwise the older {charmm} style is fine to use. See the discussion
below and more details on the "pair_style charmm"_pair_charmm.html doc
page.
@ -86,17 +88,18 @@ default). Otherwise 1-4 non-bonded interactions in dihedrals will be
computed twice.
For simulations using the CHARMM force field with a Coulomb cutoff,
the difference between the {charmm} and {charmmfsh} styles is in the
the difference between the {charmm} and {charmmfsw} styles is in the
computation of the 1-4 non-bond interactions, though only if the
distance between the two atoms is within the switching region of the
pairwise potential defined by the corresponding CHARMM pair style,
i.e. within the outer cutoff specified for the pair style. The
{charmmfsh} style should only be used when using the "pair_style
lj/charmmfsw/coul/charmmfsh"_pair_charmm.html to make the Coulombic
pairwise calculations consistent. Use the {charmm} style with
long-range Coulombics or the older "pair_style
lj/charmm/coul/charmm"_pair_charmm.html command. See the discussion
on the "CHARMM pair_style"_pair_charmm.html doc page for details.
{charmmfsw} style should only be used when using the corresponding
"pair_style lj/charmmfsw/coul/charmmfsw"_pair_charmm.html or
"pair_style lj/charmmfsw/coul/long"_pair_charmm.html commands. Use
the {charmm} style with the older "pair_style"_pair_charmm.html
commands that have just "charmm" in their style name. See the
discussion on the "CHARMM pair_style"_pair_charmm.html doc page for
details.
Note that for AMBER force fields, which use pair styles with "lj/cut",
the special_bonds 1-4 scaling factor should be set to the AMBER
@ -104,7 +107,7 @@ defaults (1/2 and 5/6) and all the dihedral weighting factors (4th
coeff above) must be set to 0.0. In this case, you can use any pair
style you wish, since the dihedral does not need any Lennard-Jones
parameter information and will not compute any 1-4 non-bonded
interactions. Likewise the {charmm} or {charmmfsh} styles are
interactions. Likewise the {charmm} or {charmmfsw} styles are
identical in this case since no 1-4 non-bonded interactions are
computed.

View File

@ -14,10 +14,10 @@ dihedral_style spherical :pre
[Examples:]
dihedral_coeff 1 1 286.1 1 124 1 1 90.0 0 1 90.0 0
dihedral_coeff 1 3 286.1 1 114 1 1 90 0 1 90.0 0 &
17.3 0 0.0 0 1 158 1 0 0.0 0 &
15.1 0 0.0 0 0 0.0 0 1 167.3 1 :pre
dihedral_coeff 1 1 286.1 1 124 1 1 90.0 0 1 90.0 0
dihedral_coeff 1 3 69.3 1 93.9 1 1 90 0 1 90 0 &
49.1 0 0.00 0 1 74.4 1 0 0.00 0 &
25.2 0 0.00 0 0 0.00 0 1 48.1 1
[Description:]
@ -35,13 +35,14 @@ the dihedral interaction even if it requires adding additional terms to
the expansion (as was done in the second example). A careful choice of
parameters can prevent singularities that occur with traditional
force-fields whenever theta1 or theta2 approach 0 or 180 degrees.
The last example above corresponds to an interaction with a single energy
minima located at phi=114, theta1=158, theta2=167.3 degrees, and it remains
minima located near phi=93.9, theta1=74.4, theta2=48.1 degrees, and it remains
numerically stable at all angles (phi, theta1, theta2). In this example,
the coefficients 17.3, and 15.1 can be physically interpreted as the
the coefficients 49.1, and 25.2 can be physically interpreted as the
harmonic spring constants for theta1 and theta2 around their minima.
The coefficient 286.1 is the harmonic spring constant for phi after
division by sin(158)*sin(167.3) (the minima positions for theta1 and theta2).
The coefficient 69.3 is the harmonic spring constant for phi after
division by sin(74.4)*sin(48.1) (the minima positions for theta1 and theta2).
The following coefficients must be defined for each dihedral type via the
"dihedral_coeff"_dihedral_coeff.html command as in the example above, or in

View File

@ -7,12 +7,12 @@
:line
dump command :h3
"dump custom/vtk"_dump_custom_vtk.html command :h3
"dump vtk"_dump_vtk.html command :h3
"dump h5md"_dump_h5md.html command :h3
"dump molfile"_dump_molfile.html command :h3
"dump netcdf"_dump_netcdf.html command :h3
"dump image"_dump_image.html command :h3
"dump movie"_dump_image.html command :h3
"dump molfile"_dump_molfile.html command :h3
"dump nc"_dump_nc.html command :h3
[Syntax:]
@ -20,7 +20,7 @@ dump ID group-ID style N file args :pre
ID = user-assigned name for the dump :ulb,l
group-ID = ID of the group of atoms to be dumped :l
style = {atom} or {atom/gz} or {atom/mpiio} or {cfg} or {cfg/gz} or {cfg/mpiio} or {dcd} or {xtc} or {xyz} or {xyz/gz} or {xyz/mpiio} or {h5md} or {image} or {movie} or {molfile} or {local} or {custom} or {custom/gz} or {custom/mpiio} :l
style = {atom} or {atom/gz} or {atom/mpiio} or {cfg} or {cfg/gz} or {cfg/mpiio} or {custom} or {custom/gz} or {custom/mpiio} or {dcd} or {h5md} or {image} or or {local} or {molfile} or {movie} or {netcdf} or {netcdf/mpiio} or {vtk} or {xtc} or {xyz} or {xyz/gz} or {xyz/mpiio} :l
N = dump every this many timesteps :l
file = name of file to write dump info to :l
args = list of arguments for a particular style :l
@ -30,33 +30,22 @@ args = list of arguments for a particular style :l
{cfg} args = same as {custom} args, see below
{cfg/gz} args = same as {custom} args, see below
{cfg/mpiio} args = same as {custom} args, see below
{custom}, {custom/gz}, {custom/mpiio} args = see below
{dcd} args = none
{h5md} args = discussed on "dump h5md"_dump_h5md.html doc page
{image} args = discussed on "dump image"_dump_image.html doc page
{local} args = see below
{molfile} args = discussed on "dump molfile"_dump_molfile.html doc page
{movie} args = discussed on "dump image"_dump_image.html doc page
{netcdf} args = discussed on "dump netcdf"_dump_netcdf.html doc page
{netcdf/mpiio} args = discussed on "dump netcdf"_dump_netcdf.html doc page
{vtk} args = same as {custom} args, see below, also "dump vtk"_dump_vtk.html doc page
{xtc} args = none
{xyz} args = none :pre
{xyz/gz} args = none :pre
{xyz} args = none
{xyz/gz} args = none
{xyz/mpiio} args = none :pre
{custom/vtk} args = similar to custom args below, discussed on "dump custom/vtk"_dump_custom_vtk.html doc page :pre
{h5md} args = discussed on "dump h5md"_dump_h5md.html doc page :pre
{image} args = discussed on "dump image"_dump_image.html doc page :pre
{movie} args = discussed on "dump image"_dump_image.html doc page :pre
{molfile} args = discussed on "dump molfile"_dump_molfile.html doc page
{nc} args = discussed on "dump nc"_dump_nc.html doc page :pre
{local} args = list of local attributes
possible attributes = index, c_ID, c_ID\[I\], f_ID, f_ID\[I\]
index = enumeration of local values
c_ID = local vector calculated by a compute with ID
c_ID\[I\] = Ith column of local array calculated by a compute with ID, I can include wildcard (see below)
f_ID = local vector calculated by a fix with ID
f_ID\[I\] = Ith column of local array calculated by a fix with ID, I can include wildcard (see below) :pre
{custom} or {custom/gz} or {custom/mpiio} args = list of atom attributes
{custom} or {custom/gz} or {custom/mpiio} args = list of atom attributes :l
possible attributes = id, mol, proc, procp1, type, element, mass,
x, y, z, xs, ys, zs, xu, yu, zu,
xsu, ysu, zsu, ix, iy, iz,
@ -94,6 +83,15 @@ args = list of arguments for a particular style :l
v_name = per-atom vector calculated by an atom-style variable with name
d_name = per-atom floating point vector with name, managed by fix property/atom
i_name = per-atom integer vector with name, managed by fix property/atom :pre
{local} args = list of local attributes :l
possible attributes = index, c_ID, c_ID\[I\], f_ID, f_ID\[I\]
index = enumeration of local values
c_ID = local vector calculated by a compute with ID
c_ID\[I\] = Ith column of local array calculated by a compute with ID, I can include wildcard (see below)
f_ID = local vector calculated by a fix with ID
f_ID\[I\] = Ith column of local array calculated by a fix with ID, I can include wildcard (see below) :pre
:ule
[Examples:]

View File

@ -1,347 +0,0 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
dump custom/vtk command :h3
[Syntax:]
dump ID group-ID style N file args :pre
ID = user-assigned name for the dump :ulb,l
group-ID = ID of the group of atoms to be dumped :l
style = {custom/vtk} :l
N = dump every this many timesteps :l
file = name of file to write dump info to :l
args = list of arguments for a particular style :l
{custom/vtk} args = list of atom attributes
possible attributes = id, mol, proc, procp1, type, element, mass,
x, y, z, xs, ys, zs, xu, yu, zu,
xsu, ysu, zsu, ix, iy, iz,
vx, vy, vz, fx, fy, fz,
q, mux, muy, muz, mu,
radius, diameter, omegax, omegay, omegaz,
angmomx, angmomy, angmomz, tqx, tqy, tqz,
c_ID, c_ID\[N\], f_ID, f_ID\[N\], v_name :pre
id = atom ID
mol = molecule ID
proc = ID of processor that owns atom
procp1 = ID+1 of processor that owns atom
type = atom type
element = name of atom element, as defined by "dump_modify"_dump_modify.html command
mass = atom mass
x,y,z = unscaled atom coordinates
xs,ys,zs = scaled atom coordinates
xu,yu,zu = unwrapped atom coordinates
xsu,ysu,zsu = scaled unwrapped atom coordinates
ix,iy,iz = box image that the atom is in
vx,vy,vz = atom velocities
fx,fy,fz = forces on atoms
q = atom charge
mux,muy,muz = orientation of dipole moment of atom
mu = magnitude of dipole moment of atom
radius,diameter = radius,diameter of spherical particle
omegax,omegay,omegaz = angular velocity of spherical particle
angmomx,angmomy,angmomz = angular momentum of aspherical particle
tqx,tqy,tqz = torque on finite-size particles
c_ID = per-atom vector calculated by a compute with ID
c_ID\[I\] = Ith column of per-atom array calculated by a compute with ID, I can include wildcard (see below)
f_ID = per-atom vector calculated by a fix with ID
f_ID\[I\] = Ith column of per-atom array calculated by a fix with ID, I can include wildcard (see below)
v_name = per-atom vector calculated by an atom-style variable with name
d_name = per-atom floating point vector with name, managed by fix property/atom
i_name = per-atom integer vector with name, managed by fix property/atom :pre
:ule
[Examples:]
dump dmpvtk all custom/vtk 100 dump*.myforce.vtk id type vx fx
dump dmpvtp flow custom/vtk 100 dump*.%.displace.vtp id type c_myD\[1\] c_myD\[2\] c_myD\[3\] v_ke :pre
The style {custom/vtk} is similar to the "custom"_dump.html style but
uses the VTK library to write data to VTK simple legacy or XML format
depending on the filename extension specified. This can be either
{*.vtk} for the legacy format or {*.vtp} and {*.vtu}, respectively,
for the XML format; see the "VTK
homepage"_http://www.vtk.org/VTK/img/file-formats.pdf for a detailed
description of these formats. Since this naming convention conflicts
with the way binary output is usually specified (see below),
"dump_modify binary"_dump_modify.html allows to set the binary
flag for this dump style explicitly.
[Description:]
Dump a snapshot of atom quantities to one or more files every N
timesteps in a format readable by the "VTK visualization
toolkit"_http://www.vtk.org or other visualization tools that use it,
e.g. "ParaView"_http://www.paraview.org. The timesteps on which dump
output is written can also be controlled by a variable; see the
"dump_modify every"_dump_modify.html command for details.
Only information for atoms in the specified group is dumped. The
"dump_modify thresh and region"_dump_modify.html commands can also
alter what atoms are included; see details below.
As described below, special characters ("*", "%") in the filename
determine the kind of output.
IMPORTANT NOTE: Because periodic boundary conditions are enforced only
on timesteps when neighbor lists are rebuilt, the coordinates of an
atom written to a dump file may be slightly outside the simulation
box.
IMPORTANT NOTE: Unless the "dump_modify sort"_dump_modify.html
option is invoked, the lines of atom information written to dump files
will be in an indeterminate order for each snapshot. This is even
true when running on a single processor, if the "atom_modify
sort"_atom_modify.html option is on, which it is by default. In this
case atoms are re-ordered periodically during a simulation, due to
spatial sorting. It is also true when running in parallel, because
data for a single snapshot is collected from multiple processors, each
of which owns a subset of the atoms.
For the {custom/vtk} style, sorting is off by default. See the
"dump_modify"_dump_modify.html doc page for details.
:line
The dimensions of the simulation box are written to a separate file
for each snapshot (either in legacy VTK or XML format depending on
the format of the main dump file) with the suffix {_boundingBox}
appended to the given dump filename.
For an orthogonal simulation box this information is saved as a
rectilinear grid (legacy .vtk or .vtr XML format).
Triclinic simulation boxes (non-orthogonal) are saved as
hexahedrons in either legacy .vtk or .vtu XML format.
Style {custom/vtk} allows you to specify a list of atom attributes
to be written to the dump file for each atom. Possible attributes
are listed above. In contrast to the {custom} style, the attributes
are rearranged to ensure correct ordering of vector components
(except for computes and fixes - these have to be given in the right
order) and duplicate entries are removed.
You cannot specify a quantity that is not defined for a particular
simulation - such as {q} for atom style {bond}, since that atom style
doesn't assign charges. Dumps occur at the very end of a timestep,
so atom attributes will include effects due to fixes that are applied
during the timestep. An explanation of the possible dump custom/vtk attributes
is given below. Since position data is required to write VTK files "x y z"
do not have to be specified explicitly.
The VTK format uses a single snapshot of the system per file, thus
a wildcard "*" must be included in the filename, as discussed below.
Otherwise the dump files will get overwritten with the new snapshot
each time.
:line
Dumps are performed on timesteps that are a multiple of N (including
timestep 0) and on the last timestep of a minimization if the
minimization converges. Note that this means a dump will not be
performed on the initial timestep after the dump command is invoked,
if the current timestep is not a multiple of N. This behavior can be
changed via the "dump_modify first"_dump_modify.html command, which
can also be useful if the dump command is invoked after a minimization
ended on an arbitrary timestep. N can be changed between runs by
using the "dump_modify every"_dump_modify.html command.
The "dump_modify every"_dump_modify.html command
also allows a variable to be used to determine the sequence of
timesteps on which dump files are written. In this mode a dump on the
first timestep of a run will also not be written unless the
"dump_modify first"_dump_modify.html command is used.
Dump filenames can contain two wildcard characters. If a "*"
character appears in the filename, then one file per snapshot is
written and the "*" character is replaced with the timestep value.
For example, tmp.dump*.vtk becomes tmp.dump0.vtk, tmp.dump10000.vtk,
tmp.dump20000.vtk, etc. Note that the "dump_modify pad"_dump_modify.html
command can be used to insure all timestep numbers are the same length
(e.g. 00010), which can make it easier to read a series of dump files
in order with some post-processing tools.
If a "%" character appears in the filename, then each of P processors
writes a portion of the dump file, and the "%" character is replaced
with the processor ID from 0 to P-1 preceded by an underscore character.
For example, tmp.dump%.vtp becomes tmp.dump_0.vtp, tmp.dump_1.vtp, ...
tmp.dump_P-1.vtp, etc. This creates smaller files and can be a fast
mode of output on parallel machines that support parallel I/O for output.
By default, P = the number of processors meaning one file per
processor, but P can be set to a smaller value via the {nfile} or
{fileper} keywords of the "dump_modify"_dump_modify.html command.
These options can be the most efficient way of writing out dump files
when running on large numbers of processors.
For the legacy VTK format "%" is ignored and P = 1, i.e., only
processor 0 does write files.
Note that using the "*" and "%" characters together can produce a
large number of small dump files!
If {dump_modify binary} is used, the dump file (or files, if "*" or
"%" is also used) is written in binary format. A binary dump file
will be about the same size as a text version, but will typically
write out much faster.
:line
This section explains the atom attributes that can be specified as
part of the {custom/vtk} style.
The {id}, {mol}, {proc}, {procp1}, {type}, {element}, {mass}, {vx},
{vy}, {vz}, {fx}, {fy}, {fz}, {q} attributes are self-explanatory.
{Id} is the atom ID. {Mol} is the molecule ID, included in the data
file for molecular systems. {Proc} is the ID of the processor (0 to
Nprocs-1) that currently owns the atom. {Procp1} is the proc ID+1,
which can be convenient in place of a {type} attribute (1 to Ntypes)
for coloring atoms in a visualization program. {Type} is the atom
type (1 to Ntypes). {Element} is typically the chemical name of an
element, which you must assign to each type via the "dump_modify
element"_dump_modify.html command. More generally, it can be any
string you wish to associated with an atom type. {Mass} is the atom
mass. {Vx}, {vy}, {vz}, {fx}, {fy}, {fz}, and {q} are components of
atom velocity and force and atomic charge.
There are several options for outputting atom coordinates. The {x},
{y}, {z} attributes write atom coordinates "unscaled", in the
appropriate distance "units"_units.html (Angstroms, sigma, etc). Use
{xs}, {ys}, {zs} if you want the coordinates "scaled" to the box size,
so that each value is 0.0 to 1.0. If the simulation box is triclinic
(tilted), then all atom coords will still be between 0.0 and 1.0.
I.e. actual unscaled (x,y,z) = xs*A + ys*B + zs*C, where (A,B,C) are
the non-orthogonal vectors of the simulation box edges, as discussed
in "Section 6.12"_Section_howto.html#howto_12.
Use {xu}, {yu}, {zu} if you want the coordinates "unwrapped" by the
image flags for each atom. Unwrapped means that if the atom has
passed thru a periodic boundary one or more times, the value is
printed for what the coordinate would be if it had not been wrapped
back into the periodic box. Note that using {xu}, {yu}, {zu} means
that the coordinate values may be far outside the box bounds printed
with the snapshot. Using {xsu}, {ysu}, {zsu} is similar to using
{xu}, {yu}, {zu}, except that the unwrapped coordinates are scaled by
the box size. Atoms that have passed through a periodic boundary will
have the corresponding coordinate increased or decreased by 1.0.
The image flags can be printed directly using the {ix}, {iy}, {iz}
attributes. For periodic dimensions, they specify which image of the
simulation box the atom is considered to be in. An image of 0 means
it is inside the box as defined. A value of 2 means add 2 box lengths
to get the true value. A value of -1 means subtract 1 box length to
get the true value. LAMMPS updates these flags as atoms cross
periodic boundaries during the simulation.
The {mux}, {muy}, {muz} attributes are specific to dipolar systems
defined with an atom style of {dipole}. They give the orientation of
the atom's point dipole moment. The {mu} attribute gives the
magnitude of the atom's dipole moment.
The {radius} and {diameter} attributes are specific to spherical
particles that have a finite size, such as those defined with an atom
style of {sphere}.
The {omegax}, {omegay}, and {omegaz} attributes are specific to
finite-size spherical particles that have an angular velocity. Only
certain atom styles, such as {sphere} define this quantity.
The {angmomx}, {angmomy}, and {angmomz} attributes are specific to
finite-size aspherical particles that have an angular momentum. Only
the {ellipsoid} atom style defines this quantity.
The {tqx}, {tqy}, {tqz} attributes are for finite-size particles that
can sustain a rotational torque due to interactions with other
particles.
The {c_ID} and {c_ID\[I\]} attributes allow per-atom vectors or arrays
calculated by a "compute"_compute.html to be output. The ID in the
attribute should be replaced by the actual ID of the compute that has
been defined previously in the input script. See the
"compute"_compute.html command for details. There are computes for
calculating the per-atom energy, stress, centro-symmetry parameter,
and coordination number of individual atoms.
Note that computes which calculate global or local quantities, as
opposed to per-atom quantities, cannot be output in a dump custom/vtk
command. Instead, global quantities can be output by the
"thermo_style custom"_thermo_style.html command, and local quantities
can be output by the dump local command.
If {c_ID} is used as a attribute, then the per-atom vector calculated
by the compute is printed. If {c_ID\[I\]} is used, then I must be in
the range from 1-M, which will print the Ith column of the per-atom
array with M columns calculated by the compute. See the discussion
above for how I can be specified with a wildcard asterisk to
effectively specify multiple values.
The {f_ID} and {f_ID\[I\]} attributes allow vector or array per-atom
quantities calculated by a "fix"_fix.html to be output. The ID in the
attribute should be replaced by the actual ID of the fix that has been
defined previously in the input script. The "fix
ave/atom"_fix_ave_atom.html command is one that calculates per-atom
quantities. Since it can time-average per-atom quantities produced by
any "compute"_compute.html, "fix"_fix.html, or atom-style
"variable"_variable.html, this allows those time-averaged results to
be written to a dump file.
If {f_ID} is used as a attribute, then the per-atom vector calculated
by the fix is printed. If {f_ID\[I\]} is used, then I must be in the
range from 1-M, which will print the Ith column of the per-atom array
with M columns calculated by the fix. See the discussion above for
how I can be specified with a wildcard asterisk to effectively specify
multiple values.
The {v_name} attribute allows per-atom vectors calculated by a
"variable"_variable.html to be output. The name in the attribute
should be replaced by the actual name of the variable that has been
defined previously in the input script. Only an atom-style variable
can be referenced, since it is the only style that generates per-atom
values. Variables of style {atom} can reference individual atom
attributes, per-atom atom attributes, thermodynamic keywords, or
invoke other computes, fixes, or variables when they are evaluated, so
this is a very general means of creating quantities to output to a
dump file.
The {d_name} and {i_name} attributes allow to output custom per atom
floating point or integer properties that are managed by
"fix property/atom"_fix_property_atom.html.
See "Section 10"_Section_modify.html of the manual for information
on how to add new compute and fix styles to LAMMPS to calculate
per-atom quantities which could then be output into dump files.
:line
[Restrictions:]
The {custom/vtk} style does not support writing of gzipped dump files.
The {custom/vtk} dump style is part of the USER-VTK package. It is
only enabled if LAMMPS was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
To use this dump style, you also must link to the VTK library. See
the info in lib/vtk/README and insure the Makefile.lammps file in that
directory is appropriate for your machine.
The {custom/vtk} dump style neither supports buffering nor custom
format strings.
[Related commands:]
"dump"_dump.html, "dump image"_dump_image.html,
"dump_modify"_dump_modify.html, "undump"_undump.html
[Default:]
By default, files are written in ASCII format. If the file extension
is not one of .vtk, .vtp or .vtu, the legacy VTK file format is used.

View File

@ -17,9 +17,7 @@ group-ID = ID of the group of atoms to be imaged :l
h5md = style of dump command (other styles {atom} or {cfg} or {dcd} or {xtc} or {xyz} or {local} or {custom} are discussed on the "dump"_dump.html doc page) :l
N = dump every this many timesteps :l
file.h5 = name of file to write to :l
args = list of data elements to dump, with their dump "subintervals".
At least one element must be given and image may only be present if
position is specified first. :l
args = list of data elements to dump, with their dump "subintervals"
position options
image
velocity options
@ -29,15 +27,17 @@ position is specified first. :l
box value = {yes} or {no}
create_group value = {yes} or {no}
author value = quoted string :pre
:ule
For the elements {position}, {velocity}, {force} and {species}, one
may specify a sub-interval to write the data only every N_element
Note that at least one element must be specified and image may only be
present if position is specified first.
For the elements {position}, {velocity}, {force} and {species}, a
sub-interval may be specified to write the data only every N_element
iterations of the dump (i.e. every N*N_element time steps). This is
specified by the option
specified by this option directly following the element declaration:
every N_element :pre
that follows directly the element declaration.
every N_element :pre
:ule

View File

@ -1,66 +0,0 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
dump nc command :h3
dump nc/mpiio command :h3
[Syntax:]
dump ID group-ID nc N file.nc args
dump ID group-ID nc/mpiio N file.nc args :pre
ID = user-assigned name for the dump :ulb,l
group-ID = ID of the group of atoms to be imaged :l
{nc} or {nc/mpiio} = style of dump command (other styles {atom} or {cfg} or {dcd} or {xtc} or {xyz} or {local} or {custom} are discussed on the "dump"_dump.html doc page) :l
N = dump every this many timesteps :l
file.nc = name of file to write to :l
args = list of per atom data elements to dump, same as for the 'custom' dump style. :l,ule
[Examples:]
dump 1 all nc 100 traj.nc type x y z vx vy vz
dump_modify 1 append yes at -1 global c_thermo_pe c_thermo_temp c_thermo_press :pre
dump 1 all nc/mpiio 1000 traj.nc id type x y z :pre
[Description:]
Dump a snapshot of atom coordinates every N timesteps in Amber-style
NetCDF file format. NetCDF files are binary, portable and
self-describing. This dump style will write only one file on the root
node. The dump style {nc} uses the "standard NetCDF
library"_netcdf-home all data is collected on one processor and then
written to the dump file. Dump style {nc/mpiio} used the "parallel
NetCDF library"_pnetcdf-home and MPI-IO; it has better performance on
a larger number of processors. Note that 'nc' outputs all atoms sorted
by atom tag while 'nc/mpiio' outputs in order of the MPI rank.
In addition to per-atom data, also global (i.e. not per atom, but per
frame) quantities can be included in the dump file. This can be
variables, output from computes or fixes data prefixed with v_, c_ and
f_, respectively. These properties are included via
"dump_modify"_dump_modify.html {global}.
:link(netcdf-home,http://www.unidata.ucar.edu/software/netcdf/)
:link(pnetcdf-home,http://trac.mcs.anl.gov/projects/parallel-netcdf/)
:line
[Restrictions:]
The {nc} and {nc/mpiio} dump styles are part of the USER-NC-DUMP
package. It is only enabled if LAMMPS was built with that
package. See the "Making LAMMPS"_Section_start.html#start_3 section
for more info.
:line
[Related commands:]
"dump"_dump.html, "dump_modify"_dump_modify.html, "undump"_undump.html

82
doc/src/dump_netcdf.txt Normal file
View File

@ -0,0 +1,82 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
dump netcdf command :h3
dump netcdf/mpiio command :h3
[Syntax:]
dump ID group-ID netcdf N file args
dump ID group-ID netcdf/mpiio N file args :pre
ID = user-assigned name for the dump :ulb,l
group-ID = ID of the group of atoms to be imaged :l
{netcdf} or {netcdf/mpiio} = style of dump command (other styles {atom} or {cfg} or {dcd} or {xtc} or {xyz} or {local} or {custom} are discussed on the "dump"_dump.html doc page) :l
N = dump every this many timesteps :l
file = name of file to write dump info to :l
args = list of atom attributes, same as for "dump_style custom"_dump.html :l,ule
[Examples:]
dump 1 all netcdf 100 traj.nc type x y z vx vy vz
dump_modify 1 append yes at -1 global c_thermo_pe c_thermo_temp c_thermo_press
dump 1 all netcdf/mpiio 1000 traj.nc id type x y z :pre
[Description:]
Dump a snapshot of atom coordinates every N timesteps in Amber-style
NetCDF file format. NetCDF files are binary, portable and
self-describing. This dump style will write only one file on the root
node. The dump style {netcdf} uses the "standard NetCDF
library"_netcdf-home. All data is collected on one processor and then
written to the dump file. Dump style {netcdf/mpiio} uses the
"parallel NetCDF library"_pnetcdf-home and MPI-IO to write to the dump
file in parallel; it has better performance on a larger number of
processors. Note that style {netcdf} outputs all atoms sorted by atom
tag while style {netcdf/mpiio} outputs atoms in order of their MPI
rank.
NetCDF files can be directly visualized via the following tools:
Ovito (http://www.ovito.org/). Ovito supports the AMBER convention and
all of the above extensions. :ule,b
VMD (http://www.ks.uiuc.edu/Research/vmd/). :l
AtomEye (http://www.libatoms.org/). The libAtoms version of AtomEye
contains a NetCDF reader that is not present in the standard
distribution of AtomEye. :l,ule
In addition to per-atom data, global data can be included in the dump
file, which are the kinds of values output by the
"thermo_style"_thermo_style.html command . See "Section howto
6.15"_Section_howto.html#howto_15 for an explanation of per-atom
versus global data. The global output written into the dump file can
be from computes, fixes, or variables, by prefixing the compute/fix ID
or variable name with "c_" or "f_" or "v_" respectively, as in the
example above. These global values are specified via the "dump_modify
global"_dump_modify.html command.
:link(netcdf-home,http://www.unidata.ucar.edu/software/netcdf/)
:link(pnetcdf-home,http://trac.mcs.anl.gov/projects/parallel-netcdf/)
:line
[Restrictions:]
The {netcdf} and {netcdf/mpiio} dump styles are part of the
USER-NETCDF package. They are only enabled if LAMMPS was built with
that package. See the "Making LAMMPS"_Section_start.html#start_3
section for more info.
:line
[Related commands:]
"dump"_dump.html, "dump_modify"_dump_modify.html, "undump"_undump.html

179
doc/src/dump_vtk.txt Normal file
View File

@ -0,0 +1,179 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
dump vtk command :h3
[Syntax:]
dump ID group-ID vtk N file args :pre
ID = user-assigned name for the dump
group-ID = ID of the group of atoms to be dumped
vtk = style of dump command (other styles {atom} or {cfg} or {dcd} or {xtc} or {xyz} or {local} or {custom} are discussed on the "dump"_dump.html doc page)
N = dump every this many timesteps
file = name of file to write dump info to
args = same as arguments for "dump_style custom"_dump.html :ul
[Examples:]
dump dmpvtk all vtk 100 dump*.myforce.vtk id type vx fx
dump dmpvtp flow vtk 100 dump*.%.displace.vtp id type c_myD\[1\] c_myD\[2\] c_myD\[3\] v_ke :pre
[Description:]
Dump a snapshot of atom quantities to one or more files every N
timesteps in a format readable by the "VTK visualization
toolkit"_http://www.vtk.org or other visualization tools that use it,
e.g. "ParaView"_http://www.paraview.org. The timesteps on which dump
output is written can also be controlled by a variable; see the
"dump_modify every"_dump_modify.html command for details.
This dump style is similar to "dump_style custom"_dump.html but uses
the VTK library to write data to VTK simple legacy or XML format
depending on the filename extension specified for the dump file. This
can be either {*.vtk} for the legacy format or {*.vtp} and {*.vtu},
respectively, for XML format; see the "VTK
homepage"_http://www.vtk.org/VTK/img/file-formats.pdf for a detailed
description of these formats. Since this naming convention conflicts
with the way binary output is usually specified (see below), the
"dump_modify binary"_dump_modify.html command allows setting of a
binary option for this dump style explicitly.
Only information for atoms in the specified group is dumped. The
"dump_modify thresh and region"_dump_modify.html commands can also
alter what atoms are included; see details below.
As described below, special characters ("*", "%") in the filename
determine the kind of output.
IMPORTANT NOTE: Because periodic boundary conditions are enforced only
on timesteps when neighbor lists are rebuilt, the coordinates of an
atom written to a dump file may be slightly outside the simulation
box.
IMPORTANT NOTE: Unless the "dump_modify sort"_dump_modify.html option
is invoked, the lines of atom information written to dump files will
be in an indeterminate order for each snapshot. This is even true
when running on a single processor, if the "atom_modify
sort"_atom_modify.html option is on, which it is by default. In this
case atoms are re-ordered periodically during a simulation, due to
spatial sorting. It is also true when running in parallel, because
data for a single snapshot is collected from multiple processors, each
of which owns a subset of the atoms.
For the {vtk} style, sorting is off by default. See the
"dump_modify"_dump_modify.html doc page for details.
:line
The dimensions of the simulation box are written to a separate file
for each snapshot (either in legacy VTK or XML format depending on the
format of the main dump file) with the suffix {_boundingBox} appended
to the given dump filename.
For an orthogonal simulation box this information is saved as a
rectilinear grid (legacy .vtk or .vtr XML format).
Triclinic simulation boxes (non-orthogonal) are saved as
hexahedrons in either legacy .vtk or .vtu XML format.
Style {vtk} allows you to specify a list of atom attributes to be
written to the dump file for each atom. The list of possible attributes
is the same as for the "dump_style custom"_dump.html command; see
its doc page for a listing and an explanation of each attribute.
NOTE: Since position data is required to write VTK files the atom
attributes "x y z" do not have to be specified explicitly; they will
be included in the dump file regardless. Also, in contrast to the
{custom} style, the specified {vtk} attributes are rearranged to
ensure correct ordering of vector components (except for computes and
fixes - these have to be given in the right order) and duplicate
entries are removed.
The VTK format uses a single snapshot of the system per file, thus
a wildcard "*" must be included in the filename, as discussed below.
Otherwise the dump files will get overwritten with the new snapshot
each time.
:line
Dumps are performed on timesteps that are a multiple of N (including
timestep 0) and on the last timestep of a minimization if the
minimization converges. Note that this means a dump will not be
performed on the initial timestep after the dump command is invoked,
if the current timestep is not a multiple of N. This behavior can be
changed via the "dump_modify first"_dump_modify.html command, which
can also be useful if the dump command is invoked after a minimization
ended on an arbitrary timestep. N can be changed between runs by
using the "dump_modify every"_dump_modify.html command.
The "dump_modify every"_dump_modify.html command
also allows a variable to be used to determine the sequence of
timesteps on which dump files are written. In this mode a dump on the
first timestep of a run will also not be written unless the
"dump_modify first"_dump_modify.html command is used.
Dump filenames can contain two wildcard characters. If a "*"
character appears in the filename, then one file per snapshot is
written and the "*" character is replaced with the timestep value.
For example, tmp.dump*.vtk becomes tmp.dump0.vtk, tmp.dump10000.vtk,
tmp.dump20000.vtk, etc. Note that the "dump_modify pad"_dump_modify.html
command can be used to insure all timestep numbers are the same length
(e.g. 00010), which can make it easier to read a series of dump files
in order with some post-processing tools.
If a "%" character appears in the filename, then each of P processors
writes a portion of the dump file, and the "%" character is replaced
with the processor ID from 0 to P-1 preceded by an underscore character.
For example, tmp.dump%.vtp becomes tmp.dump_0.vtp, tmp.dump_1.vtp, ...
tmp.dump_P-1.vtp, etc. This creates smaller files and can be a fast
mode of output on parallel machines that support parallel I/O for output.
By default, P = the number of processors meaning one file per
processor, but P can be set to a smaller value via the {nfile} or
{fileper} keywords of the "dump_modify"_dump_modify.html command.
These options can be the most efficient way of writing out dump files
when running on large numbers of processors.
For the legacy VTK format "%" is ignored and P = 1, i.e., only
processor 0 does write files.
Note that using the "*" and "%" characters together can produce a
large number of small dump files!
If {dump_modify binary} is used, the dump file (or files, if "*" or
"%" is also used) is written in binary format. A binary dump file
will be about the same size as a text version, but will typically
write out much faster.
:line
[Restrictions:]
The {vtk} style does not support writing of gzipped dump files.
The {vtk} dump style is part of the USER-VTK package. It is
only enabled if LAMMPS was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
To use this dump style, you also must link to the VTK library. See
the info in lib/vtk/README and insure the Makefile.lammps file in that
directory is appropriate for your machine.
The {vtk} dump style supports neither buffering or custom format
strings.
[Related commands:]
"dump"_dump.html, "dump image"_dump_image.html,
"dump_modify"_dump_modify.html, "undump"_undump.html
[Default:]
By default, files are written in ASCII format. If the file extension
is not one of .vtk, .vtp or .vtu, the legacy VTK file format is used.

View File

@ -22,6 +22,11 @@ attribute = {pair} or {kspace} or {atom} :l
pparam = parameter to adapt over time
I,J = type pair(s) to set parameter for
v_name = variable with name that calculates value of pparam
{bond} args = bstyle bparam I v_name
bstyle = bond style name, e.g. harmonic
bparam = parameter to adapt over time
I = type bond to set parameter for
v_name = variable with name that calculates value of bparam
{kspace} arg = v_name
v_name = variable with name that calculates scale factor on K-space terms
{atom} args = aparam v_name
@ -42,7 +47,10 @@ keyword = {scale} or {reset} :l
fix 1 all adapt 1 pair soft a 1 1 v_prefactor
fix 1 all adapt 1 pair soft a 2* 3 v_prefactor
fix 1 all adapt 1 pair lj/cut epsilon * * v_scale1 coul/cut scale 3 3 v_scale2 scale yes reset yes
fix 1 all adapt 10 atom diameter v_size :pre
fix 1 all adapt 10 atom diameter v_size
variable ramp_up equal "ramp(0.01,0.5)"
fix stretch all adapt 1 bond harmonic r0 1 v_ramp_up :pre
[Description:]
@ -192,6 +200,19 @@ fix 1 all adapt 1 pair soft a * * v_prefactor :pre
:line
The {bond} keyword uses the specified variable to change the value of
a bond coefficient over time, very similar to how the {pair} keyword
operates. The only difference is that now a bond coefficient for a
given bond type is adapted.
Currently {bond} does not support bond_style hybrid nor bond_style
hybrid/overlay as bond styles. The only bonds that currently are
working with fix_adapt are
"harmonic"_bond_harmonic.html: k,r0: type bonds :tb(c=3,s=:)
:line
The {kspace} keyword used the specified variable as a scale factor on
the energy, forces, virial calculated by whatever K-Space solver is
defined by the "kspace_style"_kspace_style.html command. If the

View File

@ -245,8 +245,8 @@ appear the system is converging to your specified pressure. The
solution for this is to either (a) zero the velocities of all atoms
before performing the minimization, or (b) make sure you are
monitoring the pressure without its kinetic component. The latter can
be done by outputting the pressure from the fix this command creates
(see below) or a pressure fix you define yourself.
be done by outputting the pressure from the pressure compute this
command creates (see below) or a pressure compute you define yourself.
NOTE: Because pressure is often a very sensitive function of volume,
it can be difficult for the minimizer to equilibrate the system the
@ -308,7 +308,7 @@ thermo_modify command (or in two separate commands), then the order in
which the keywords are specified is important. Note that a "pressure
compute"_compute_pressure.html defines its own temperature compute as
an argument when it is specified. The {temp} keyword will override
this (for the pressure compute being used by fix npt), but only if the
this (for the pressure compute being used by fix box/relax), but only if the
{temp} keyword comes after the {press} keyword. If the {temp} keyword
comes before the {press} keyword, then the new pressure compute
specified by the {press} keyword will be unaffected by the {temp}
@ -316,18 +316,16 @@ setting.
This fix computes a global scalar which can be accessed by various
"output commands"_Section_howto.html#howto_15. The scalar is the
pressure-volume energy, plus the strain energy, if it exists.
This fix computes a global scalar which can be accessed by various
"output commands"_Section_howto.html#howto_15. The scalar is given
by the energy expression shown above. The energy values reported
at the end of a minimization run under "Minimization stats" include
this energy, and so differ from what LAMMPS normally reports as
potential energy. This fix does not support the
"fix_modify"_fix_modify.html {energy} option,
because that would result in double-counting of the fix energy in the
minimization energy. Instead, the fix energy can be explicitly
added to the potential energy using one of these two variants:
pressure-volume energy, plus the strain energy, if it exists,
as described above.
The energy values reported at the
end of a minimization run under "Minimization stats" include this
energy, and so differ from what LAMMPS normally reports as potential
energy. This fix does not support the "fix_modify"_fix_modify.html
{energy} option, because that would result in double-counting of the
fix energy in the minimization energy. Instead, the fix energy can be
explicitly added to the potential energy using one of these two
variants:
variable emin equal pe+f_1 :pre

View File

@ -87,8 +87,11 @@ the note below about how to include the CMAP energy when performing an
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart
files"_restart.html.
This fix writes the list of CMAP crossterms to "binary restart
files"_restart.html. See the "read_restart"_read_restart.html command
for info on how to re-specify a fix in an input script that reads a
restart file, so that the operation of the fix continues in an
uninterrupted fashion.
The "fix_modify"_fix_modify.html {energy} option is supported by this
fix to add the potential "energy" of the CMAP interactions system's

View File

@ -317,7 +317,7 @@ solution is to start a new simulation after the equilibrium density
has been reached.
With some pair_styles, such as "Buckingham"_pair_buck.html,
"Born-Mayer-Huggins"_pair_born.html and "ReaxFF"_pair_reax_c.html, two
"Born-Mayer-Huggins"_pair_born.html and "ReaxFF"_pair_reaxc.html, two
atoms placed close to each other may have an arbitrary large, negative
potential energy due to the functional form of the potential. While
these unphysical configurations are inaccessible to typical dynamical

View File

@ -67,9 +67,10 @@ target value as the {Tstart} and {Tstop} arguments, so that the diffusion
matrix that gives canonical sampling for a given A is computed automatically.
However, the GLE framework also allow for non-equilibrium sampling, that
can be used for instance to model inexpensively zero-point energy
effects "(Ceriotti2)"_#Ceriotti2. This is achieved specifying the
{noneq} keyword followed by the name of the file that contains the
static covariance matrix for the non-equilibrium dynamics.
effects "(Ceriotti2)"_#Ceriotti2. This is achieved specifying the {noneq}
keyword followed by the name of the file that contains the static covariance
matrix for the non-equilibrium dynamics. Please note, that the covariance
matrix is expected to be given in [temperature units].
Since integrating GLE dynamics can be costly when used together with
simple potentials, one can use the {every} optional keyword to
@ -148,7 +149,7 @@ dpd/tstat"_pair_dpd.html, "fix gld"_fix_gld.html
1170-80 (2010)
:link(GLE4MD)
[(GLE4MD)] "http://epfl-cosmo.github.io/gle4md/"_http://epfl-cosmo.github.io/gle4md/
[(GLE4MD)] "http://gle4md.org/"_http://gle4md.org/
:link(Ceriotti2)
[(Ceriotti2)] Ceriotti, Bussi and Parrinello, Phys Rev Lett 103,

76
doc/src/fix_python.txt Normal file
View File

@ -0,0 +1,76 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix python command :h3
[Syntax:]
fix ID group-ID python N callback function_name :pre
ID, group-ID are ignored by this fix :ulb,l
python = style name of this fix command :l
N = execute every N steps :l
callback = {post_force} or {end_of_step} :l
{post_force} = callback after force computations on atoms every N time steps
{end_of_step} = callback after every N time steps :pre
:ule
[Examples:]
python post_force_callback here """
from lammps import lammps :pre
def post_force_callback(lammps_ptr, vflag):
lmp = lammps(ptr=lammps_ptr)
# access LAMMPS state using Python interface
""" :pre
python end_of_step_callback here """
def end_of_step_callback(lammps_ptr):
lmp = lammps(ptr=lammps_ptr)
# access LAMMPS state using Python interface
""" :pre
fix pf all python 50 post_force post_force_callback
fix eos all python 50 end_of_step end_of_step_callback :pre
[Description:]
This fix allows you to call a Python function during a simulation run.
The callback is either executed after forces have been applied to atoms
or at the end of every N time steps.
Callback functions must be declared in the global scope of the
active Python interpreter. This can either be done by defining it
inline using the python command or by importing functions from other
Python modules. If LAMMPS is driven using the library interface from
Python, functions defined in the driving Python interpreter can also
be executed.
Each callback is given a pointer object as first argument. This can be
used to initialize an instance of the lammps Python interface, which
gives access to the LAMMPS state from Python.
IMPORTANT NOTE: While you can access the state of LAMMPS via library functions
from these callbacks, trying to execute input script commands will in the best
case not work or in the worst case result in undefined behavior.
[Restrictions:]
This fix is part of the PYTHON package. It is only enabled if
LAMMPS was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section 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.
[Related commands:]
"python command"_python.html

View File

@ -74,7 +74,7 @@ NOTE: The "fix qeq/comb"_fix_qeq_comb.html command must still be used
to perform charge equilibration with the "COMB
potential"_pair_comb.html. The "fix qeq/reax"_fix_qeq_reax.html
command can be used to perform charge equilibration with the "ReaxFF
force field"_pair_reax_c.html, although fix qeq/shielded yields the
force field"_pair_reaxc.html, although fix qeq/shielded yields the
same results as fix qeq/reax if {Nevery}, {cutoff}, and {tolerance}
are the same. Eventually the fix qeq/reax command will be deprecated.
@ -116,7 +116,7 @@ the shielded Coulomb is given by equation (13) of the "ReaxFF force
field"_#vanDuin paper. The shielding accounts for charge overlap
between charged particles at small separation. This style is the same
as "fix qeq/reax"_fix_qeq_reax.html, and can be used with "pair_style
reax/c"_pair_reax_c.html. Only the {chi}, {eta}, and {gamma}
reax/c"_pair_reaxc.html. Only the {chi}, {eta}, and {gamma}
parameters from the {qfile} file are used. This style solves partial
charges on atoms via the matrix inversion method. A tolerance of
1.0e-6 is usually a good number.

View File

@ -30,7 +30,7 @@ fix 1 all qeq/reax 1 0.0 10.0 1.0e-6 param.qeq :pre
Perform the charge equilibration (QEq) method as described in "(Rappe
and Goddard)"_#Rappe2 and formulated in "(Nakano)"_#Nakano2. It is
typically used in conjunction with the ReaxFF force field model as
implemented in the "pair_style reax/c"_pair_reax_c.html command, but
implemented in the "pair_style reax/c"_pair_reaxc.html command, but
it can be used with any potential in LAMMPS, so long as it defines and
uses charges on each atom. The "fix qeq/comb"_fix_qeq_comb.html
command should be used to perform charge equilibration with the "COMB
@ -42,7 +42,7 @@ The QEq method minimizes the electrostatic energy of the system by
adjusting the partial charge on individual atoms based on interactions
with their neighbors. It requires some parameters for each atom type.
If the {params} setting above is the word "reax/c", then these are
extracted from the "pair_style reax/c"_pair_reax_c.html command and
extracted from the "pair_style reax/c"_pair_reaxc.html command and
the ReaxFF force field file it reads in. If a file name is specified
for {params}, then the parameters are taken from the specified file
and the file must contain one line for each atom type. The latter
@ -106,7 +106,7 @@ be used for periodic cell dimensions less than 10 angstroms.
[Related commands:]
"pair_style reax/c"_pair_reax_c.html
"pair_style reax/c"_pair_reaxc.html
[Default:] none

View File

@ -28,13 +28,30 @@ fix 1 all reax/c/bonds 100 bonds.reaxc :pre
Write out the bond information computed by the ReaxFF potential
specified by "pair_style reax"_pair_reax.html or "pair_style
reax/c"_pair_reax_c.html in the exact same format as the original
reax/c"_pair_reaxc.html in the exact same format as the original
stand-alone ReaxFF code of Adri van Duin. The bond information is
written to {filename} on timesteps that are multiples of {Nevery},
including timestep 0. For time-averaged chemical species analysis,
please see the "fix reaxc/c/species"_fix_reaxc_species.html command.
The format of the output file should be self-explanatory.
The format of the output file should be reasonably self-explanatory.
The meaning of the column header abbreviations is as follows:
id = atom id
type = atom type
nb = number of bonds
id_1 = atom id of first bond
id_nb = atom id of Nth bond
mol = molecule id
bo_1 = bond order of first bond
bo_nb = bond order of Nth bond
abo = atom bond order (sum of all bonds)
nlp = number of lone pairs
q = atomic charge :ul
If the filename ends with ".gz", the output file is written in gzipped
format. A gzipped dump file will be about 3x smaller than the text
version, but will also take longer to write.
:line
@ -80,14 +97,17 @@ reax"_pair_reax.html be invoked. This fix is part of the REAX
package. It is only enabled if LAMMPS was built with that package,
which also requires the REAX library be built and linked with LAMMPS.
The fix reax/c/bonds command requires that the "pair_style
reax/c"_pair_reax_c.html be invoked. This fix is part of the
reax/c"_pair_reaxc.html be invoked. This fix is part of the
USER-REAXC package. It is only enabled if LAMMPS was built with that
package. See the "Making LAMMPS"_Section_start.html#start_3 section
for more info.
To write gzipped bond files, you must compile LAMMPS with the
-DLAMMPS_GZIP option.
[Related commands:]
"pair_style reax"_pair_reax.html, "pair_style
reax/c"_pair_reax_c.html, "fix reax/c/species"_fix_reaxc_species.html
reax/c"_pair_reaxc.html, "fix reax/c/species"_fix_reaxc_species.html
[Default:] none

View File

@ -41,7 +41,7 @@ fix 1 all reax/c/species 1 100 100 species.out element Au O H position 1000 AuOH
[Description:]
Write out the chemical species information computed by the ReaxFF
potential specified by "pair_style reax/c"_pair_reax_c.html.
potential specified by "pair_style reax/c"_pair_reaxc.html.
Bond-order values (either averaged or instantaneous, depending on
value of {Nrepeat}) are used to determine chemical bonds. Every
{Nfreq} timesteps, chemical species information is written to
@ -52,6 +52,10 @@ number of molecules of each species. In this context, "species" means
a unique molecule. The chemical formula of each species is given in
the first line.
If the filename ends with ".gz", the output file is written in gzipped
format. A gzipped dump file will be about 3x smaller than the text version,
but will also take longer to write.
Optional keyword {cutoff} can be assigned to change the minimum
bond-order values used in identifying chemical bonds between pairs of
atoms. Bond-order cutoffs should be carefully chosen, as bond-order
@ -65,7 +69,7 @@ symbol printed for each LAMMPS atom type. The number of symbols must
match the number of LAMMPS atom types and each symbol must consist of
1 or 2 alphanumeric characters. Normally, these symbols should be
chosen to match the chemical identity of each LAMMPS atom type, as
specified using the "reax/c pair_coeff"_pair_reax_c.html command and
specified using the "reax/c pair_coeff"_pair_reaxc.html command and
the ReaxFF force field file.
The optional keyword {position} writes center-of-mass positions of
@ -158,19 +162,22 @@ more instructions on how to use the accelerated styles effectively.
[Restrictions:]
The fix species currently only works with
"pair_style reax/c"_pair_reax_c.html and it requires that the "pair_style
reax/c"_pair_reax_c.html be invoked. This fix is part of the
"pair_style reax/c"_pair_reaxc.html and it requires that the "pair_style
reax/c"_pair_reaxc.html be invoked. This fix is part of the
USER-REAXC package. It is only enabled if LAMMPS was built with that
package. See the "Making LAMMPS"_Section_start.html#start_3 section
for more info.
To write gzipped species files, you must compile LAMMPS with the
-DLAMMPS_GZIP option.
It should be possible to extend it to other reactive pair_styles (such as
"rebo"_pair_airebo.html, "airebo"_pair_airebo.html,
"comb"_pair_comb.html, and "bop"_pair_bop.html), but this has not yet been done.
[Related commands:]
"pair_style reax/c"_pair_reax_c.html, "fix
"pair_style reax/c"_pair_reaxc.html, "fix
reax/bonds"_fix_reax_bonds.html
[Default:]

View File

@ -111,6 +111,7 @@ Fixes :h1
fix_press_berendsen
fix_print
fix_property_atom
fix_python
fix_qbmsst
fix_qeq
fix_qeq_comb

View File

@ -45,12 +45,9 @@ above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands:
K (energy/radian^2)
K (energy)
X0 (degrees) :ul
X0 is specified in degrees, but LAMMPS converts it to radians
internally; hence the units of K are in energy/radian^2.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are

View File

@ -49,12 +49,9 @@ above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands:
K (energy/radian^2)
K (energy)
theta0 (degrees) :ul
theta0 is specified in degrees, but LAMMPS converts it to radians
internally; hence the units of K are in energy/radian^2.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are

View File

@ -290,9 +290,10 @@ to be specified using the {gewald/disp}, {mesh/disp},
{force/disp/real} or {force/disp/kspace} keywords, or
the code will stop with an error message. When this option is set to
{yes}, the error message will not appear and the simulation will start.
For a typical application, using the automatic parameter generation will provide
simulations that are either inaccurate or slow. Using this option is thus not
recommended. For guidelines on how to obtain good parameters, see the "How-To"_Section_howto.html#howto_23 discussion.
For a typical application, using the automatic parameter generation
will provide simulations that are either inaccurate or slow. Using this
option is thus not recommended. For guidelines on how to obtain good
parameters, see the "How-To"_Section_howto.html#howto_24 discussion.
[Restrictions:] none

View File

@ -55,12 +55,12 @@ dihedral_style.html
dimension.html
displace_atoms.html
dump.html
dump_custom_vtk.html
dump_h5md.html
dump_image.html
dump_modify.html
dump_molfile.html
dump_nc.html
dump_netcdf.html
dump_vtk.html
echo.html
fix.html
fix_modify.html
@ -237,6 +237,7 @@ fix_pour.html
fix_press_berendsen.html
fix_print.html
fix_property_atom.html
fix_python.html
fix_qbmsst.html
fix_qeq.html
fix_qeq_comb.html
@ -432,6 +433,7 @@ pair_gauss.html
pair_gayberne.html
pair_gran.html
pair_gromacs.html
pair_gw.html
pair_hbond_dreiding.html
pair_hybrid.html
pair_kim.html
@ -467,9 +469,10 @@ pair_oxdna.html
pair_oxdna2.html
pair_peri.html
pair_polymorphic.html
pair_python.html
pair_quip.html
pair_reax.html
pair_reax_c.html
pair_reaxc.html
pair_resquared.html
pair_sdk.html
pair_smd_hertz.html

View File

@ -75,7 +75,7 @@ Lennard-Jones 12/6) given by
:c,image(Eqs/pair_buck.jpg)
where rho is an ionic-pair dependent length parameter, and Rc is the
cutoff on both terms.
cutoff on both terms.
The styles with {coul/cut} or {coul/long} or {coul/msm} add a
Coulombic term as described for the "lj/cut"_pair_lj.html pair styles.
@ -120,6 +120,9 @@ cutoff (distance units)
cutoff2 (distance units) :ul
The second coefficient, rho, must be greater than zero.
The coefficients A, rho, and C can be written as analytical expressions
of epsilon and sigma, in analogy to the Lennard-Jones potential
"(Khrapak)"_#Khrapak.
The latter 2 coefficients are optional. If not specified, the global
A,C and Coulombic cutoffs are used. If only one cutoff is specified,
@ -127,7 +130,6 @@ it is used as the cutoff for both A,C and Coulombic interactions for
this type pair. If both coefficients are specified, they are used as
the A,C and Coulombic cutoffs for this type pair. You cannot specify
2 cutoffs for style {buck}, since it has no Coulombic terms.
For {buck/coul/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
@ -194,3 +196,6 @@ only enabled if LAMMPS was built with that package. See the
"pair_coeff"_pair_coeff.html, "pair_style born"_pair_born.html
[Default:] none
:link(Khrapak)
[(Khrapak)] Khrapak, Chaudhuri, and Morfill, J Chem Phys, 134, 054120 (2011).

View File

@ -99,9 +99,10 @@ artifacts.
NOTE: The newer {charmmfsw} or {charmmfsh} styles were released in
March 2017. We recommend they be used instead of the older {charmm}
styles. Eventually code from the new styles will propagate into the
related pair styles (e.g. implicit, accelerator, free energy
variants).
styles. This includes the newer "dihedral_style
charmmfsw"_dihedral_charmm.html command. Eventually code from the new
styles will propagate into the related pair styles (e.g. implicit,
accelerator, free energy variants).
The general CHARMM formulas are as follows

View File

@ -7,11 +7,13 @@
:line
pair_style edip command :h3
pair_style edip/multi command :h3
[Syntax:]
pair_style edip :pre
pair_style edip/omp :pre
pair_style style :pre
style = {edip} or {edip/multi} :ul
[Examples:]
@ -20,11 +22,14 @@ pair_coeff * * Si.edip Si
[Description:]
The {edip} style computes a 3-body "EDIP"_#EDIP potential which is
popular for modeling silicon materials where it can have advantages
over other models such as the "Stillinger-Weber"_pair_sw.html or
"Tersoff"_pair_tersoff.html potentials. In EDIP, the energy E of a
system of atoms is
The {edip} and {edip/multi} styles compute a 3-body "EDIP"_#EDIP
potential which is popular for modeling silicon materials where
it can have advantages over other models such as the
"Stillinger-Weber"_pair_sw.html or "Tersoff"_pair_tersoff.html
potentials. The {edip} style has been programmed for single element
potentials, while {edip/multi} supports multi-element EDIP runs.
In EDIP, the energy E of a system of atoms is
:c,image(Eqs/pair_edip.jpg)
@ -142,7 +147,7 @@ This pair style can only be used via the {pair} keyword of the
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
This pair style can only be used if LAMMPS was built with the
USER-MISC package. See the "Making LAMMPS"_Section_start.html#start_3
section for more info on packages.
@ -151,7 +156,7 @@ for pair interactions.
The EDIP potential files provided with LAMMPS (see the potentials directory)
are parameterized for metal "units"_units.html.
You can use the SW potential with any LAMMPS units, but you would need
You can use the EDIP potential with any LAMMPS units, but you would need
to create your own EDIP potential file with coefficients listed in the
appropriate units if your simulation doesn't use "metal" units.
@ -164,4 +169,4 @@ appropriate units if your simulation doesn't use "metal" units.
:line
:link(EDIP)
[(EDIP)] J. F. Justo et al., Phys. Rev. B 58, 2539 (1998).
[(EDIP)] J F Justo et al, Phys Rev B 58, 2539 (1998).

View File

@ -128,7 +128,7 @@ The B parameter is converted to a distance (sigma), before mixing
afterwards (using B=sigma^2).
Negative A values are converted to positive A values (using abs(A))
before mixing, and converted back after mixing
(by multiplying by sign(Ai)*sign(Aj)).
(by multiplying by min(sign(Ai),sign(Aj))).
This way, if either particle is repulsive (if Ai<0 or Aj<0),
then the default interaction between both particles will be repulsive.

120
doc/src/pair_gw.txt Normal file
View File

@ -0,0 +1,120 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style gw command :h3
pair_style gw/zbl command :h3
[Syntax:]
pair_style style :pre
style = {gw} or {gw/zbl} :ul
[Examples:]
pair_style gw
pair_coeff * * SiC.gw Si C C
pair_style gw/zbl
pair_coeff * * SiC.gw.zbl C Si :pre
[Description:]
The {gw} style computes a 3-body "Gao-Weber"_#Gao potential;
similarly {gw/zbl} combines this potential with a modified
repulsive ZBL core function in a similar fashion as implemented
in the "tersoff/zbl"_pair_tersoff_zbl.html pair style.
Unfortunately the author of this contributed code has not been
able to submit a suitable documentation explaining the details
of the potentials. The LAMMPS developers thus have finally decided
to release the code anyway with only the technical explanations.
For details of the model and the parameters, please refer to the
linked publication.
Only a single pair_coeff command is used with the {gw} and {gw/zbl}
styles which specifies a Gao-Weber potential file with parameters
for all needed elements. These are mapped to LAMMPS atom types by
specifying N additional arguments after the filename in the pair_coeff
command, where N is the number of LAMMPS atom types:
filename
N element names = mapping of GW elements to atom types :ul
See the "pair_coeff"_pair_coeff.html doc page for alternate ways
to specify the path for the potential file.
As an example, imagine a file SiC.gw has Gao-Weber values for Si and C.
If your LAMMPS simulation has 4 atoms types and you want the first 3 to
be Si, and the 4th to be C, you would use the following pair_coeff command:
pair_coeff * * SiC.gw Si Si Si C :pre
The first 2 arguments must be * * so as to span all LAMMPS atom types.
The first three Si arguments map LAMMPS atom types 1,2,3 to the Si
element in the GW file. The final C argument maps LAMMPS atom type 4
to the C element in the GW file. If a mapping value is specified as
NULL, the mapping is not performed. This can be used when a {gw}
potential is used as part of the {hybrid} pair style. The NULL values
are placeholders for atom types that will be used with other
potentials.
Gao-Weber files in the {potentials} directory of the LAMMPS
distribution have a ".gw" suffix. Gao-Weber with ZBL files
have a ".gz.zbl" suffix. The structure of the potential files
is similar to other many-body potentials supported by LAMMPS.
You have to refer to the comments in the files and the literature
to learn more details.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, where types I and J correspond to
two different element types, mixing is performed by LAMMPS as
described above from values in the potential file.
This pair style does not support the "pair_modify"_pair_modify.html
shift, table, and tail options.
This pair style does not write its information to "binary restart
files"_restart.html, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.
This pair style can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. It does not support the
{inner}, {middle}, {outer} keywords.
:line
[Restrictions:]
This pair style is part of the USER-MISC package. It is only enabled
if LAMMPS was built with that package. See
the "Making LAMMPS"_Section_start.html#start_3 section for more info.
This pair style requires the "newton"_newton.html setting to be "on"
for pair interactions.
The Gao-Weber potential files provided with LAMMPS (see the
potentials directory) are parameterized for metal "units"_units.html.
You can use the GW potential with any LAMMPS units, but you would need
to create your own GW potential file with coefficients listed in the
appropriate units if your simulation doesn't use "metal" units.
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
:line
:link(Gao)
[(Gao)] Gao and Weber, Nuclear Instruments and Methods in Physics Research B 191 (2012) 504.

View File

@ -73,7 +73,7 @@ pair_coeff command to assign parameters for the different type pairs.
NOTE: There are two exceptions to this option to list an individual
pair style multiple times. The first is for pair styles implemented
as Fortran libraries: "pair_style meam"_pair_meam.html and "pair_style
reax"_pair_reax.html ("pair_style reax/c"_pair_reax_c.html is OK).
reax"_pair_reax.html ("pair_style reax/c"_pair_reaxc.html is OK).
This is because unlike a C++ class, they can not be instantiated
multiple times, due to the manner in which they were coded in Fortran.
The second is for GPU-enabled pair styles in the GPU package. This is
@ -225,6 +225,12 @@ special_bonds lj/coul 1e-20 1e-20 0.5
pair_hybrid tersoff lj/cut/coul/long 12.0
pair_modify pair tersoff special lj/coul 1.0 1.0 1.0 :pre
For use with the various "compute */tally"_compute_tally.html
computes, the "pair_modify compute/tally"_pair_modify.html
command can be used to selectively turn off processing of
the compute tally styles, for example, if those pair styles
(e.g. manybody styles) do not support this feature.
See the "pair_modify"_pair_modify.html doc page for details on
the specific syntax, requirements and restrictions.

View File

@ -23,7 +23,8 @@ pair_coeff * * Ti.meam.spline Ti Ti Ti :pre
The {meam/spline} style computes pairwise interactions for metals
using a variant of modified embedded-atom method (MEAM) potentials
"(Lenosky)"_#Lenosky1. The total energy E is given by
"(Lenosky)"_#Lenosky1. For a single species ("old-style") MEAM,
the total energy E is given by
:c,image(Eqs/pair_meam_spline.jpg)
@ -31,6 +32,20 @@ where rho_i is the density at atom I, theta_jik is the angle between
atoms J, I, and K centered on atom I. The five functions Phi, U, rho,
f, and g are represented by cubic splines.
The {meam/spline} style also supports a new style multicomponent
modified embedded-atom method (MEAM) potential "(Zhang)"_#Zhang4, where
the total energy E is given by
:c,image(Eqs/pair_meam_spline_multicomponent.jpg)
where the five functions Phi, U, rho, f, and g depend on the chemistry
of the atoms in the interaction. In particular, if there are N different
chemistries, there are N different U, rho, and f functions, while there
are N(N+1)/2 different Phi and g functions. The new style multicomponent
MEAM potential files are indicated by the second line in the file starts
with "meam/spline" followed by the number of elements and the name of each
element.
The cutoffs and the coefficients for these spline functions are listed
in a parameter file which is specified by the
"pair_coeff"_pair_coeff.html command. Parameter files for different
@ -59,7 +74,7 @@ N element names = mapping of spline-based MEAM elements to atom types :ul
See the "pair_coeff"_pair_coeff.html doc page for alternate ways
to specify the path for the potential file.
As an example, imagine the Ti.meam.spline file has values for Ti. If
As an example, imagine the Ti.meam.spline file has values for Ti (old style). If
your LAMMPS simulation has 3 atoms types and they are all to be
treated with this potentials, you would use the following pair_coeff
command:
@ -72,10 +87,19 @@ in the potential file. If a mapping value is specified as NULL, the
mapping is not performed. This can be used when a {meam/spline}
potential is used as part of the {hybrid} pair style. The NULL values
are placeholders for atom types that will be used with other
potentials.
potentials. The old-style potential maps any non-NULL species named
on the command line to that single type.
NOTE: The {meam/spline} style currently supports only single-element
MEAM potentials. It may be extended for alloy systems in the future.
An example with a two component spline (new style) is TiO.meam.spline, where
the command
pair_coeff * * TiO.meam.spline Ti O :pre
will map the 1st atom type to Ti and the second atom type to O. Note
in this case that the species names need to match exactly with the
names of the elements in the TiO.meam.spline file; otherwise an
error will be raised. This behavior is different than the old style
MEAM files.
:line
@ -104,9 +128,6 @@ more instructions on how to use the accelerated styles effectively.
[Mixing, shift, table, tail correction, restart, rRESPA info]:
The current version of this pair style does not support multiple
element types or mixing. It has been designed for pure elements only.
This pair style does not support the "pair_modify"_pair_modify.html
shift, table, and tail options.
@ -142,3 +163,6 @@ for more info.
[(Lenosky)] Lenosky, Sadigh, Alonso, Bulatov, de la Rubia, Kim, Voter,
Kress, Modelling Simulation Materials Science Engineering, 8, 825
(2000).
:link(Zhang4)
[(Zhang)] Zhang and Trinkle, Computational Materials Science, 124, 204-210 (2016).

View File

@ -15,11 +15,13 @@ pair_modify keyword values ... :pre
one or more keyword/value pairs may be listed :ulb,l
keyword = {pair} or {shift} or {mix} or {table} or {table/disp} or {tabinner} or {tabinner/disp} or {tail} or {compute} :l
{pair} values = sub-style N {special} which wt1 wt2 wt3
or sub-style N {compute/tally} flag
sub-style = sub-style of "pair hybrid"_pair_hybrid.html
N = which instance of sub-style (only if sub-style is used multiple times)
{special} which wt1 wt2 wt3 = override {special_bonds} settings (optional)
which = {lj/coul} or {lj} or {coul}
w1,w2,w3 = 1-2, 1-3, and 1-4 weights from 0.0 to 1.0 inclusive
{special} which wt1 wt2 wt3 = override {special_bonds} settings (optional)
which = {lj/coul} or {lj} or {coul}
w1,w2,w3 = 1-2, 1-3, and 1-4 weights from 0.0 to 1.0 inclusive
{compute/tally} flag = {yes} or {no}
{mix} value = {geometric} or {arithmetic} or {sixthpower}
{shift} value = {yes} or {no}
{table} value = N
@ -40,6 +42,7 @@ pair_modify shift yes mix geometric
pair_modify tail yes
pair_modify table 12
pair_modify pair lj/cut compute no
pair_modify pair tersoff compute/tally no
pair_modify pair lj/cut/coul/long 1 special lj/coul 0.0 0.0 0.0 :pre
[Description:]
@ -60,9 +63,12 @@ keywords will be applied to. Note that if the {pair} keyword is not
used, and the pair style is {hybrid} or {hybrid/overlay}, then all the
specified keywords will be applied to all sub-styles.
The {special} keyword can only be used in conjunction with the {pair}
keyword and must directly follow it. It allows to override the
The {special} and {compute/tally} keywords can [only] be used in
conjunction with the {pair} keyword and must directly follow it.
{special} allows to override the
"special_bonds"_special_bonds.html settings for the specified sub-style.
{compute/tally} allows to disable or enable registering
"compute */tally"_compute_tally.html computes for a given sub-style.
More details are given below.
The {mix} keyword affects pair coefficients for interactions between
@ -231,6 +237,14 @@ setting. Substituting 1.0e-10 for 0.0 and 0.9999999999 for 1.0 is
usually a sufficient workaround in this case without causing a
significant error.
The {compute/tally} keyword takes exactly 1 argument ({no} or {yes}),
and allows to selectively disable or enable processing of the various
"compute */tally"_compute_tally.html styles for a given
"pair hybrid or hybrid/overlay"_pair_hybrid.html sub-style.
NOTE: Any "pair_modify pair compute/tally" command must be issued
[before] the corresponding compute style is defined.
:line
[Restrictions:] none
@ -240,8 +254,9 @@ conflicting options. You cannot use {tail} yes with 2d simulations.
[Related commands:]
"pair_style"_pair_style.html, "pair_coeff"_pair_coeff.html,
"thermo_style"_thermo_style.html
"pair_style"_pair_style.html, "pair_style hybrid"_pair_hybrid.html,
pair_coeff"_pair_coeff.html, "thermo_style"_thermo_style.html,
"compute */tally"_compute_tally.html
[Default:]

216
doc/src/pair_python.txt Normal file
View File

@ -0,0 +1,216 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style python command :h3
[Syntax:]
pair_style python cutoff :pre
cutoff = global cutoff for interactions in python potential classes
[Examples:]
pair_style python 2.5
pair_coeff * * py_pot.LJCutMelt lj :pre
pair_style hybrid/overlay coul/long 12.0 python 12.0
pair_coeff * * coul/long
pair_coeff * * python py_pot.LJCutSPCE OW NULL :pre
[Description:]
The {python} pair style provides a way to define pairwise additive
potential functions as python script code that is loaded into LAMMPS
from a python file which must contain specific python class definitions.
This allows to rapidly evaluate different potential functions without
having to modify and recompile LAMMPS. Due to python being an
interpreted language, however, the performance of this pair style is
going to be significantly slower (often between 20x and 100x) than
corresponding compiled code. This penalty can be significantly reduced
through generating tabulations from the python code through the
"pair_write"_pair_write.html command, which is supported by this style.
Only a single pair_coeff command is used with the {python} pair style
which specifies a python class inside a python module or file that
LAMMPS will look up in the current directory, the folder pointed to by
the LAMMPS_POTENTIALS environment variable or somewhere in your python
path. A single python module can hold multiple python pair class
definitions. The class definitions itself have to follow specific
rules that are explained below.
Atom types in the python class are specified through symbolic
constants, typically strings. These are mapped to LAMMPS atom types by
specifying N additional arguments after the class name in the
pair_coeff command, where N must be the number of currently defined
atom types:
As an example, imagine a file {py_pot.py} has a python potential class
names {LJCutMelt} with parameters and potential functions for a two
Lennard-Jones atom types labeled as 'LJ1' and 'LJ2'. In your LAMMPS
input and you would have defined 3 atom types, out of which the first
two are supposed to be using the 'LJ1' parameters and the third the
'LJ2' parameters, then you would use the following pair_coeff command:
pair_coeff * * py_pot.LJCutMelt LJ1 LJ1 LJ2 :pre
The first two arguments [must] be * * so as to span all LAMMPS atom
types. The first two LJ1 arguments map LAMMPS atom types 1 and 2 to
the LJ1 atom type in the LJCutMelt class of the py_pot.py file. The
final LJ2 argument maps LAMMPS atom type 3 to the LJ2 atom type the
python file. If a mapping value is specified as NULL, the mapping is
not performed, any pair interaction with this atom type will be
skipped. This can be used when a {python} potential is used as part of
the {hybrid} or {hybrid/overlay} pair style. The NULL values are then
placeholders for atom types that will be used with other potentials.
:line
The python potential file has to start with the following code:
from __future__ import print_function
class LAMMPSPairPotential(object):
def __init__(self):
self.pmap=dict()
self.units='lj'
def map_coeff(self,name,ltype):
self.pmap\[ltype\]=name
def check_units(self,units):
if (units != self.units):
raise Exception("Conflicting units: %s vs. %s" % (self.units,units))
:pre
Any classes with definitions of specific potentials have to be derived
from this class and should be initialize in a similar fashion to the
example given below.
NOTE: The class constructor has to set up a data structure containing
the potential parameters supported by this class. It should also
define a variable {self.units} containing a string matching one of the
options of LAMMPS' "units"_units.html command, which is used to
verify, that the potential definition in the python class and in the
LAMMPS input match.
Here is an example for a single type Lennard-Jones potential class
{LJCutMelt} in reducted units, which defines an atom type {lj} for
which the parameters epsilon and sigma are both 1.0:
class LJCutMelt(LAMMPSPairPotential):
def __init__(self):
super(LJCutMelt,self).__init__()
# set coeffs: 48*eps*sig**12, 24*eps*sig**6,
# 4*eps*sig**12, 4*eps*sig**6
self.units = 'lj'
self.coeff = \{'lj' : \{'lj' : (48.0,24.0,4.0,4.0)\}\}
:pre
The class also has to provide two methods for the computation of the
potential energy and forces, which have be named {compute_force},
and {compute_energy}, which both take 3 numerical arguments:
rsq = the square of the distance between a pair of atoms (float) :l
itype = the (numerical) type of the first atom :l
jtype = the (numerical) type of the second atom :ul
This functions need to compute the force and the energy, respectively,
and use the result as return value. The functions need to use the
{pmap} dictionary to convert the LAMMPS atom type number to the symbolic
value of the internal potential parameter data structure. Following
the {LJCutMelt} example, here are the two functions:
def compute_force(self,rsq,itype,jtype):
coeff = self.coeff\[self.pmap\[itype\]\]\[self.pmap\[jtype\]\]
r2inv = 1.0/rsq
r6inv = r2inv*r2inv*r2inv
lj1 = coeff\[0\]
lj2 = coeff\[1\]
return (r6inv * (lj1*r6inv - lj2))*r2inv :pre
def compute_energy(self,rsq,itype,jtype):
coeff = self.coeff\[self.pmap\[itype\]\]\[self.pmap\[jtype\]\]
r2inv = 1.0/rsq
r6inv = r2inv*r2inv*r2inv
lj3 = coeff\[2\]
lj4 = coeff\[3\]
return (r6inv * (lj3*r6inv - lj4)) :pre
NOTE: for consistency with the C++ pair styles in LAMMPS, the
{compute_force} function follows the conventions of the Pair::single()
methods and does not return the full force, but the force scaled by
the distance between the two atoms, so this value only needs to be
multiplied by delta x, delta y, and delta z to conveniently obtain the
three components of the force vector between these two atoms.
:line
NOTE: The evaluation of scripted python code will slow down the
computation pair-wise interactions quite significantly. However, this
can be largely worked around through using the python pair style not
for the actual simulation, but to generate tabulated potentials on the
fly using the "pair_write"_pair_write.html command. Please see below
for an example LAMMPS input of how to build a table file:
pair_style python 2.5
pair_coeff * * py_pot.LJCutMelt lj
shell rm -f melt.table
pair_write 1 1 2000 rsq 0.01 2.5 lj1_lj2.table lj :pre
Note that it is strongly recommended to try to [delete] the potential
table file before generating it. Since the {pair_write} command will
always append to a table file, which pair style table will use the
first match. Thus when changing the potential function in the python
class, the table pair style will still read the old variant.
After switching the pair style to {table}, the potential tables need
to be assigned to the LAMMPS atom types like this:
pair_style table linear 2000
pair_coeff 1 1 melt.table lj :pre
This can also be done for more complex systems. Please see the
{examples/python} folders for a few more examples.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
Mixing of potential parameters has to be handled inside the provided
python module. The python pair style simply assumes that force and
energy computation can be correctly performed for all pairs of atom
types as they are mapped to the atom type labels inside the python
potential class.
This pair style does not support the "pair_modify"_pair_modify.html
shift, table, and tail options.
This pair style does not write its information to "binary restart
files"_restart.html, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.
This pair style can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. It does not support the
{inner}, {middle}, {outer} keywords.
:line
[Restrictions:]
This pair style is part of the PYTHON package. It is only enabled if
LAMMPS was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
[Related commands:]
"pair_coeff"_pair_coeff.html, "pair_write"_pair_write.html,
"pair style table"_pair_table.html
[Default:] none

View File

@ -36,7 +36,7 @@ supplemental information of the following paper:
the most up-to-date version of ReaxFF as of summer 2010.
WARNING: pair style reax is now deprecated and will soon be retired. Users
should switch to "pair_style reax/c"_pair_reax_c.html. The {reax} style
should switch to "pair_style reax/c"_pair_reaxc.html. The {reax} style
differs from the {reax/c} style in the lo-level implementation details.
The {reax} style is a
Fortran library, linked to LAMMPS. The {reax/c} style was initially
@ -82,7 +82,7 @@ be specified.
Two examples using {pair_style reax} are provided in the examples/reax
sub-directory, along with corresponding examples for
"pair_style reax/c"_pair_reax_c.html. Note that while the energy and force
"pair_style reax/c"_pair_reaxc.html. Note that while the energy and force
calculated by both of these pair styles match very closely, the
contributions due to the valence angles differ slightly due to
the fact that with {pair_style reax/c} the default value of {thb_cutoff_sq}
@ -201,7 +201,7 @@ appropriate units if your simulation doesn't use "real" units.
[Related commands:]
"pair_coeff"_pair_coeff.html, "pair_style reax/c"_pair_reax_c.html,
"pair_coeff"_pair_coeff.html, "pair_style reax/c"_pair_reaxc.html,
"fix_reax_bonds"_fix_reax_bonds.html
[Default:]

View File

@ -17,6 +17,7 @@ cfile = NULL or name of a control file :ulb,l
zero or more keyword/value pairs may be appended :l
keyword = {checkqeq} or {lgvdw} or {safezone} or {mincap}
{checkqeq} value = {yes} or {no} = whether or not to require qeq/reax fix
{enobonds} value = {yes} or {no} = whether or not to tally energy of atoms with no bonds
{lgvdw} value = {yes} or {no} = whether or not to use a low gradient vdW correction
{safezone} = factor used for array allocation
{mincap} = minimum size for array allocation :pre
@ -127,6 +128,13 @@ recommended value for parameter {thb} is 0.01, which can be set in the
control file. Note: Force field files are different for the original
or lg corrected pair styles, using wrong ffield file generates an error message.
Using the optional keyword {enobonds} with the value {yes}, the energy
of atoms with no bonds (i.e. isolated atoms) is included in the total
potential energy and the per-atom energy of that atom. If the value
{no} is specified then the energy of atoms with no bonds is set to zero.
The latter behavior is usual not desired, as it causes discontinuities
in the potential energy when the bonding of an atom drops to zero.
Optional keywords {safezone} and {mincap} are used for allocating
reax/c arrays. Increasing these values can avoid memory problems, such
as segmentation faults and bondchk failed errors, that could occur under
@ -331,7 +339,7 @@ reax"_pair_reax.html
[Default:]
The keyword defaults are checkqeq = yes, lgvdw = no, safezone = 1.2,
The keyword defaults are checkqeq = yes, enobonds = yes, lgvdw = no, safezone = 1.2,
mincap = 50.
:line

View File

@ -134,7 +134,7 @@ respa"_run_style.html command.
[Restrictions:]
All of the lj/sdk pair styles are part of the USER-CG-CMM package.
All of the lj/sdk pair styles are part of the USER-CGSDK package.
The {lj/sdk/coul/long} style also requires the KSPACE package to be
built (which is enabled by default). They are only enabled if LAMMPS
was built with that package. See the "Making

View File

@ -150,6 +150,8 @@ hybrid"_pair_hybrid.html.
This pair style requires the "newton"_newton.html command to be {on}
for non-bonded interactions.
This pair style is not compatible with "rigid body integrators"_fix_rigid.html
[Related commands:]
"pair_style hybrid"_pair_hybrid.html, "pair_coeff"_pair_coeff.html,

View File

@ -18,7 +18,7 @@ pair_style tersoff/table/omp command :h3
pair_style style :pre
style = {tersoff} or {tersoff/table} or {tersoff/gpu} or {tersoff/omp} or {tersoff/table/omp}
style = {tersoff} or {tersoff/table} or {tersoff/gpu} or {tersoff/omp} or {tersoff/table/omp} :ul
[Examples:]

View File

@ -35,7 +35,7 @@ cutoff.
In contrast to "pair_style yukawa"_pair_yukawa.html, this functional
form arises from the Coulombic interaction between two colloid
particles, screened due to the presence of an electrolyte, see the
book by "Safran"_#Safran for a derivation in the context of DVLO
book by "Safran"_#Safran for a derivation in the context of DLVO
theory. "Pair_style yukawa"_pair_yukawa.html is a screened Coulombic
potential between two point-charges and uses no such approximation.

View File

@ -36,6 +36,7 @@ Pair Styles :h1
pair_gayberne
pair_gran
pair_gromacs
pair_gw
pair_hbond_dreiding
pair_hybrid
pair_kim
@ -71,9 +72,10 @@ Pair Styles :h1
pair_oxdna2
pair_peri
pair_polymorphic
pair_python
pair_quip
pair_reax
pair_reax_c
pair_reaxc
pair_resquared
pair_sdk
pair_smd_hertz

View File

@ -14,7 +14,7 @@ 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}
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
@ -36,7 +36,12 @@ keyword = {invoke} or {input} or {return} or {format} or {length} or {file} or {
{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 :pre
{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:]
@ -50,7 +55,7 @@ def factorial(n):
return n * factorial(n-1)
""" :pre
python loop input 1 SELF return v_value format -f here """
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
@ -59,7 +64,7 @@ def loop(lmpptr,N,cut0):
for i in range(N):
cut = cut0 + i*0.1
lmp.set_variable("cut",cut) # set a variable in LAMMPS
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")
@ -67,12 +72,8 @@ def loop(lmpptr,N,cut0):
[Description:]
NOTE: It is not currently possible to use the "python"_python.html
command described in this section with Python 3, only with Python 2.
The C API changed from Python 2 to 3 and the LAMMPS code is not
compatible with both.
Define a Python function or execute a previously defined function.
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
@ -107,7 +108,8 @@ command.
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.
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
@ -116,6 +118,13 @@ 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,
@ -310,7 +319,7 @@ 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 thrid line
"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
@ -396,6 +405,9 @@ 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"_fix_python.html.
:line
If you run Python code directly on your workstation, either
@ -477,19 +489,10 @@ python"_Section_python.html. 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.
As described above, you can use the python command to invoke a Python
function which calls back to LAMMPS through its Python-wrapped library
interface. However you cannot do the opposite. I.e. you cannot call
LAMMPS from Python and invoke the python command to "callback" to
Python and execute a Python function. LAMMPS will generate an error
if you try to do that. Note that we think there actually should be a
way to do that, but haven't yet been able to figure out how to do it
successfully.
different source files, problems may occur.
[Related commands:]
"shell"_shell.html, "variable"_variable.html
"shell"_shell.html, "variable"_variable.html, "fix python"_fix_python.html
[Default:] none

View File

@ -15,7 +15,7 @@ rerun file1 file2 ... keyword args ... :pre
file1,file2,... = dump file(s) to read :ulb,l
one or more keywords may be appended, keyword {dump} must appear and be last :l
keyword = {first} or {last} or {every} or {skip} or {start} or {stop} or {dump}
{first} args = Nfirts
{first} args = Nfirst
Nfirst = dump timestep to start on
{last} args = Nlast
Nlast = dumptimestep to stop on

View File

@ -55,7 +55,7 @@ using the generated {auto} Makefile.
cd $LAMMPS_DIR/src :pre
# generate custom Makefile
python2 Make.py -jpg -png -s ffmpeg exceptions -m mpi -a file :pre
python Make.py -jpg -png -s ffmpeg exceptions -m mpi -a file :pre
# add packages if necessary
make yes-MOLECULE :pre

View File

@ -61,7 +61,7 @@ keyword/value parameters. Not all options are used by each style.
Each option has a default as listed below.
The {create} style generates an ensemble of velocities using a random
number generator with the specified seed as the specified temperature.
number generator with the specified seed at the specified temperature.
The {set} style sets the velocities of all atoms in the group to the
specified values. If any component is specified as NULL, then it is

View File

@ -62,6 +62,7 @@ pair_coeff 3 3 1.0 1.5
pair_coeff 1 4 0.0 1.0 0.5
pair_coeff 2 4 0.0 1.0 1.0
pair_coeff 3 4 0.0 1.0 0.75
pair_coeff 4 4 0.0 1.0 0.0
delete_atoms overlap 1.0 small big

View File

@ -62,6 +62,7 @@ pair_coeff 3 3 1.0 1.5
pair_coeff 1 4 0.0 1.0 0.5
pair_coeff 2 4 0.0 1.0 1.0
pair_coeff 3 4 0.0 1.0 0.75
pair_coeff 4 4 0.0 1.0 0.0
delete_atoms overlap 1.0 small big

View File

@ -1,4 +1,4 @@
LAMMPS USER-CMM-CG example problems
LAMMPS USER-CGSDK example problems
Each of these sub-directories contains a sample problem for the SDK
coarse grained MD potentials that you can run with LAMMPS.

View File

@ -0,0 +1,26 @@
# DATE: 2011-09-15 CONTRIBUTOR: Unknown CITATION: Justo, Bazant, Kaxiras, Bulatov and Yip, Phys Rev B, 58, 2539 (1998)
# EDIP 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
# format of a single entry (one or more lines)
#
# element 1, element 2, element 3,
# A B cutoffA cutoffC alpha beta eta
# gamma lambda mu rho sigma Q0
# u1 u2 u3 u4
#
# units for each parameters:
# A , lambda are in eV
# B, cutoffA, cutoffC, gamma, sigma are in Angstrom
# alpha, beta, eta, mu, rho, Q0, u1-u4 are pure numbers
# Here are the original parameters in metal units, for Silicon from:
# J. F. Justo, M. Z. Bazant, E. Kaxiras, V. V. Bulatov, S. Yip
# Phys. Rev. B 58, 2539 (1998)
#
Si Si Si 7.9821730 1.5075463 3.1213820 2.5609104 3.1083847 0.0070975 0.2523244
1.1247945 1.4533108 0.6966326 1.2085196 0.5774108 312.1341346
-0.165799 32.557 0.286198 0.66

View File

@ -0,0 +1,38 @@
# DATE: 2017-05-16 CONTRIBUTOR: Laurent Pizzagalli CITATION: G. Lucas, M. Bertolus, and L. Pizzagalli, J. Phys. : Condens. Matter 22, 035802 (2010)
# element 1, element 2, element 3,
# A B cutoffA cutoffC alpha beta eta
# gamma lambda mu rho sigma Q0
# u1 u2 u3 u4
#
Si Si Si 5.488043 1.446435 2.941586 2.540193 3.066580 0.008593 0.589390
1.135256 2.417497 0.629131 1.343679 0.298443 208.924548
-0.165799 32.557 0.286198 0.66
C C C 10.222599 0.959814 2.212263 1.741598 1.962090 0.025661 0.275605
1.084183 3.633621 0.594236 2.827634 0.536561 289.305617
-0.165799 32.557 0.286198 0.66
C Si Si 7.535967 1.177019 2.534972 1.973974 2.507738 0.015347 0.432497
1.191567 3.025559 0.611684 2.061835 0.423863 249.115082
-0.165799 32.557000 0.286198 0.660000
Si C C 7.535967 1.177019 2.534972 1.973974 2.507738 0.015347 0.432497
1.191567 3.025559 0.611684 2.061835 0.423863 249.115082
-0.165799 32.557000 0.286198 0.660000
Si Si C 5.488043 1.446435 2.941586 2.540193 3.066580 0.008593 0.510944
1.135256 2.721528 0.620407 1.343679 0.298443 229.019815
-0.165799 32.557000 0.286198 0.660000
Si C Si 7.535967 1.177019 2.534972 1.973974 2.507738 0.015347 0.510944
1.191567 2.721528 0.620407 2.061835 0.423863 229.019815
-0.165799 32.557000 0.286198 0.660000
C C Si 10.222599 0.959814 2.212263 1.741598 1.962090 0.025661 0.354051
1.084183 3.329590 0.602960 2.827634 0.536561 269.210350
-0.165799 32.557000 0.286198 0.660000
C Si C 7.535967 1.177019 2.534972 1.973974 2.507738 0.015347 0.354051
1.191567 3.329590 0.602960 2.061835 0.423863 269.210350
-0.165799 32.557000 0.286198 0.660000

View File

@ -0,0 +1,138 @@
Position data for Silicon-Carbon system
128 atoms
2 atom types
-6.00 5.97232152 xlo xhi
-6.00 5.97232152 ylo yhi
-6.00 5.97232152 zlo zhi
Atoms
1 2 -2.9378454 -4.4592615 -4.8109196
2 2 5.6222143 -2.7335026 -1.7157569
3 2 -2.6614623 -5.5431059 1.6353686
4 2 -5.4326838 -4.6174577 5.9452279
5 2 5.8679239 -0.1120535 -3.5839373
6 2 -3.7174621 -0.6623311 -0.3714789
7 2 -5.0724728 -2.5671623 4.4103461
8 2 -3.3951436 0.9341126 4.9310702
9 2 -5.4347593 1.9523767 -5.6180938
10 2 -4.5884719 2.2904528 -1.0597739
11 2 -5.9058662 0.6212406 2.0127574
12 2 -4.7680660 0.1965740 4.3267764
13 2 -5.4228882 5.2569673 -4.5162920
14 2 -5.2683965 -5.9193658 -2.8648668
15 2 -2.8610884 1.0484664 2.0299077
16 2 -4.0711084 5.3133026 3.8009514
17 2 -0.1947147 -4.1677696 -5.6950931
18 2 -2.9892710 -3.1647368 -1.6173910
19 2 -0.9129311 -4.3819066 -0.1601859
20 2 -2.4513693 -5.2466501 4.8882912
21 2 -2.8879952 -0.1633446 -3.3401150
22 1 -4.6738762 -1.3807254 -2.2946777
23 2 -0.6973948 -1.4885343 0.6005156
24 1 -2.7392164 -2.4774843 0.2387186
25 2 -2.6551254 -2.7229952 2.6350264
26 1 -3.4644263 -4.6028144 3.3817786
27 2 0.7227614 -2.0709446 2.9214737
28 1 -2.1000577 -3.2131296 5.7273437
29 2 -3.1057649 2.3204819 -2.2725622
30 1 -2.2298751 0.7168389 -1.3107201
31 2 -1.8698261 1.4006751 0.7265108
32 1 -4.1103409 -0.7093340 1.9341753
33 2 -0.3505581 3.2707182 -0.2880656
34 1 -3.4045407 -1.4383961 4.3903527
35 2 -3.0940529 1.4132478 -5.3635505
36 1 -4.4560663 1.2072875 -3.7310176
37 2 -2.6061002 4.6373499 -4.6903941
38 1 -3.3477444 4.6768137 -2.6284678
39 2 0.8121697 4.8602418 -4.6710946
40 1 -2.5756922 3.3740738 -0.2136350
41 2 -0.3867976 5.8745611 -2.1119905
42 1 -1.6766249 1.3374292 3.8741477
43 2 -0.8770613 3.3735941 4.3846975
44 1 -1.8609254 3.3158245 -5.9786556
45 1 -5.2732321 -4.6073253 -0.9581754
46 1 -2.7888697 -5.6910152 -0.7922023
47 1 -2.4717165 4.5801880 2.5083210
48 1 -3.8819950 5.8456589 -5.7563384
49 2 2.2314782 -2.7729214 -5.2356862
50 2 0.2981976 -3.1385279 -3.1608167
51 2 2.8810785 -3.4658695 -0.5823196
52 2 0.2509625 -5.7595229 2.7389761
53 2 -0.2934120 -0.8029431 -3.3698507
54 1 -1.0075690 -2.0481922 -1.9419298
55 2 2.0729069 1.4922441 -2.3898096
56 1 1.1110944 -3.2004208 0.9491078
57 2 1.6774298 -0.7901860 2.5158773
58 1 -0.8342297 -4.3342518 2.0971458
59 2 3.2747406 -1.3107897 4.7884706
60 1 1.7126246 -3.3691471 4.5581012
61 2 0.4770605 1.7769008 -5.3339915
62 1 0.2944391 0.5892781 -2.2030106
63 2 2.2039275 3.1557557 -2.0276796
64 1 -0.0404494 0.4767818 1.0396418
65 2 1.1395867 2.3763443 2.3481007
66 1 -0.9738374 -1.6325161 3.7538567
67 2 -0.3291998 0.2996990 5.2770809
68 1 -1.6185604 -0.3964274 -5.1771220
69 2 2.5999949 -5.1977715 5.8230717
70 1 -1.6270675 2.3210900 -3.6299941
71 2 3.6532700 4.9282597 -5.4319276
72 1 0.0788934 4.0241037 -2.5011530
73 2 2.8556507 2.6168653 2.1125546
74 1 0.9738989 2.6255364 4.3412121
75 2 3.7452938 3.4521356 4.5946426
76 1 2.0805182 4.7039015 5.3280260
77 1 -1.0324174 -5.8155041 -4.3265820
78 1 0.7622442 -4.3631629 -1.3156572
79 1 0.3263684 3.9937357 1.6172321
80 1 -0.4350105 -5.7997058 4.5959134
81 2 3.9161132 -4.6052788 -3.3191717
82 2 1.9240657 5.7345079 -1.9754251
83 2 -5.9794488 -4.2369359 1.8646522
84 2 4.3339975 -4.4845227 5.3737440
85 2 2.2755456 -0.6327737 -5.7931837
86 1 1.8728190 -1.5504906 -3.4560010
87 2 3.4558100 -1.1054068 -1.8333071
88 1 4.3788172 -1.9466494 -0.3284637
89 2 2.5999235 -3.7548996 2.5740569
90 1 3.9983910 -4.4856603 1.1968663
91 2 -5.7295580 -2.1475672 -5.9963645
92 1 4.2664051 -2.6988975 -5.8005478
93 2 4.5254685 2.2906832 -3.4765798
94 1 2.3603088 1.3416442 -4.4173836
95 2 4.7767057 1.4061217 -0.7524620
96 1 1.8072666 -0.7835973 -0.4581995
97 2 4.4745018 0.3736224 2.1068274
98 1 3.6081170 -1.7315713 2.4019053
99 2 4.6281423 -0.2865409 4.4756524
100 1 1.7975239 0.2893530 4.2330830
101 2 5.8341452 4.4986472 -5.9664541
102 1 3.2401308 4.1655227 -3.5070029
103 2 4.8720339 4.8709982 -2.3364366
104 1 3.5526476 1.2262752 0.6926826
105 2 -5.8173342 4.5420479 1.5578881
106 1 3.9683224 1.5441137 3.8284375
107 2 -5.5349308 1.9067049 3.7504113
108 1 4.4728615 2.6415574 -5.5952809
109 1 1.7000950 -4.8115440 -4.1953920
110 1 1.7221527 4.1878404 -0.3712681
111 1 3.9218156 4.5935583 1.3263407
112 1 3.1310195 -5.8922481 3.6001155
113 1 4.7558719 -2.2877771 -3.4742052
114 1 -5.5050300 -2.7027381 0.8748867
115 1 5.8418594 -4.6064370 3.8714113
116 1 -4.7516868 -3.1691984 -4.4099768
117 1 3.9404971 0.7188702 -2.2898786
118 1 -5.6869740 0.2042380 -0.1916738
119 1 5.8949589 -1.2422560 3.1201292
120 1 5.9675804 -0.0712572 5.8964022
121 1 -5.6208517 3.3600036 -2.9493510
122 1 5.2065263 3.4517912 -0.3800894
123 1 -4.6994522 2.5489583 1.8297431
124 1 -4.0758407 3.0726196 5.0647973
125 1 4.1587591 -5.0896820 -1.1443498
126 1 -4.6963753 -5.7429833 1.1357818
127 1 5.5994192 4.6887008 3.5948264
128 1 5.0988369 -5.3774409 -4.9051267

View File

@ -0,0 +1,72 @@
units metal
atom_style atomic
atom_modify map array
boundary p p p
atom_modify sort 0 0.0
# temperature
variable t equal 1800.0
# coordination number cutoff
variable r equal 2.835
# minimization parameters
variable etol equal 1.0e-5
variable ftol equal 1.0e-5
variable maxiter equal 100
variable maxeval equal 100
variable dmax equal 1.0e-1
# diamond unit cell
variable a equal 5.431
lattice custom $a &
a1 1.0 0.0 0.0 &
a2 0.0 1.0 0.0 &
a3 0.0 0.0 1.0 &
basis 0.0 0.0 0.0 &
basis 0.0 0.5 0.5 &
basis 0.5 0.0 0.5 &
basis 0.5 0.5 0.0 &
basis 0.25 0.25 0.25 &
basis 0.25 0.75 0.75 &
basis 0.75 0.25 0.75 &
basis 0.75 0.75 0.25
region myreg block 0 4 &
0 4 &
0 4
create_box 1 myreg
create_atoms 1 region myreg
mass 1 28.06
group Si type 1
velocity all create $t 5287287 mom yes rot yes dist gaussian
# make a vacancy
group del id 300
delete_atoms group del
pair_style edip
pair_coeff * * Si.edip Si
thermo 10
fix 1 all nvt temp $t $t 0.1
timestep 1.0e-3
neighbor 1.0 bin
neigh_modify every 1 delay 10 check yes
# equilibrate
run 500

View File

@ -0,0 +1,72 @@
units metal
atom_style atomic
atom_modify map array
boundary p p p
atom_modify sort 0 0.0
# temperature
variable t equal 1800.0
# coordination number cutoff
variable r equal 2.835
# minimization parameters
variable etol equal 1.0e-5
variable ftol equal 1.0e-5
variable maxiter equal 100
variable maxeval equal 100
variable dmax equal 1.0e-1
# diamond unit cell
variable a equal 5.431
lattice custom $a &
a1 1.0 0.0 0.0 &
a2 0.0 1.0 0.0 &
a3 0.0 0.0 1.0 &
basis 0.0 0.0 0.0 &
basis 0.0 0.5 0.5 &
basis 0.5 0.0 0.5 &
basis 0.5 0.5 0.0 &
basis 0.25 0.25 0.25 &
basis 0.25 0.75 0.75 &
basis 0.75 0.25 0.75 &
basis 0.75 0.75 0.25
region myreg block 0 4 &
0 4 &
0 4
create_box 1 myreg
create_atoms 1 region myreg
mass 1 28.06
group Si type 1
velocity all create $t 5287287 mom yes rot yes dist gaussian
# make a vacancy
group del id 300
delete_atoms group del
pair_style edip/multi
pair_coeff * * Si.edip Si
thermo 10
fix 1 all nvt temp $t $t 0.1
timestep 1.0e-3
neighbor 1.0 bin
neigh_modify every 1 delay 10 check yes
# equilibrate
run 500

View File

@ -0,0 +1,33 @@
# Test of MEAM potential for SiC system
units metal
boundary p p p
atom_style atomic
read_data data.SiC
pair_style edip/multi
pair_coeff * * SiC.edip Si C
mass 1 28.085
mass 2 12.001
neighbor 1.0 bin
neigh_modify delay 1
fix 1 all nve
thermo 10
timestep 0.001
#dump 1 all atom 50 dump.meam
#dump 2 all image 10 image.*.jpg element element &
# axes yes 0.8 0.02 view 60 -30
#dump_modify 2 pad 3 element Si C
#dump 3 all movie 10 movie.mpg element element &
# axes yes 0.8 0.02 view 60 -30
#dump_modify 3 pad 3 element Si C
run 100

View File

@ -0,0 +1,167 @@
LAMMPS (4 May 2017)
using 1 OpenMP thread(s) per MPI task
units metal
atom_style atomic
atom_modify map array
boundary p p p
atom_modify sort 0 0.0
# temperature
variable t equal 1800.0
# coordination number cutoff
variable r equal 2.835
# minimization parameters
variable etol equal 1.0e-5
variable ftol equal 1.0e-5
variable maxiter equal 100
variable maxeval equal 100
variable dmax equal 1.0e-1
# diamond unit cell
variable a equal 5.431
lattice custom $a a1 1.0 0.0 0.0 a2 0.0 1.0 0.0 a3 0.0 0.0 1.0 basis 0.0 0.0 0.0 basis 0.0 0.5 0.5 basis 0.5 0.0 0.5 basis 0.5 0.5 0.0 basis 0.25 0.25 0.25 basis 0.25 0.75 0.75 basis 0.75 0.25 0.75 basis 0.75 0.75 0.25
lattice custom 5.431 a1 1.0 0.0 0.0 a2 0.0 1.0 0.0 a3 0.0 0.0 1.0 basis 0.0 0.0 0.0 basis 0.0 0.5 0.5 basis 0.5 0.0 0.5 basis 0.5 0.5 0.0 basis 0.25 0.25 0.25 basis 0.25 0.75 0.75 basis 0.75 0.25 0.75 basis 0.75 0.75 0.25
Lattice spacing in x,y,z = 5.431 5.431 5.431
region myreg block 0 4 0 4 0 4
create_box 1 myreg
Created orthogonal box = (0 0 0) to (21.724 21.724 21.724)
1 by 1 by 1 MPI processor grid
create_atoms 1 region myreg
Created 512 atoms
mass 1 28.06
group Si type 1
512 atoms in group Si
velocity all create $t 5287287 mom yes rot yes dist gaussian
velocity all create 1800 5287287 mom yes rot yes dist gaussian
# make a vacancy
group del id 300
1 atoms in group del
delete_atoms group del
Deleted 1 atoms, new total = 511
pair_style edip/multi
pair_coeff * * Si.edip Si
Reading potential file Si.edip with DATE: 2011-09-15
thermo 10
fix 1 all nvt temp $t $t 0.1
fix 1 all nvt temp 1800 $t 0.1
fix 1 all nvt temp 1800 1800 0.1
timestep 1.0e-3
neighbor 1.0 bin
neigh_modify every 1 delay 10 check yes
# equilibrate
run 500
Neighbor list info ...
update every 1 steps, delay 10 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 4.12138
ghost atom cutoff = 4.12138
binsize = 2.06069, bins = 11 11 11
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair edip/multi, perpetual
attributes: full, newton on
pair build: full/bin/atomonly
stencil: full/bin/3d
bin: standard
Per MPI rank memory allocation (min/avg/max) = 2.979 | 2.979 | 2.979 Mbytes
Step Temp E_pair E_mol TotEng Press
0 1802.5039 -2372.6618 0 -2253.8359 12261.807
10 952.62744 -2316.428 0 -2253.6283 723.08194
20 549.13801 -2289.442 0 -2253.2413 -2444.5204
30 1047.0106 -2321.1523 0 -2252.1305 9013.201
40 663.46141 -2294.2083 0 -2250.4711 2942.5348
50 504.74535 -2282.849 0 -2249.5748 -461.44909
60 1019.2173 -2315.5639 0 -2248.3744 7706.4286
70 844.51195 -2302.5251 0 -2246.8526 3116.8302
80 814.90407 -2299.3372 0 -2245.6166 794.77455
90 1269.5636 -2327.4775 0 -2243.7845 7729.3968
100 977.61563 -2306.1118 0 -2241.6647 2969.9939
110 843.08539 -2295.6547 0 -2240.0763 1393.4039
120 1161.6968 -2314.6587 0 -2238.0766 7398.3492
130 918.19451 -2296.4321 0 -2235.9022 2537.3997
140 881.42548 -2292.2768 0 -2234.1709 1550.3339
150 1231.1005 -2313.1054 0 -2231.9479 8112.7566
160 967.01862 -2293.332 0 -2229.5836 3422.9627
170 833.51248 -2282.7489 0 -2227.8015 43.991459
180 1240.8488 -2307.3633 0 -2225.5632 6557.8651
190 1126.4621 -2297.1922 0 -2222.9328 4289.0067
200 947.59571 -2283.29 0 -2220.822 586.2811
210 1228.153 -2299.4702 0 -2218.5071 5315.0425
220 1215.4104 -2295.9408 0 -2215.8176 4870.3417
230 1112.436 -2286.7552 0 -2213.4204 2527.1879
240 1300.081 -2296.6013 0 -2210.8965 5738.3708
250 1192.5738 -2286.8463 0 -2208.2286 4076.49
260 1004.7055 -2272.1753 0 -2205.9424 359.37589
270 1241.2018 -2285.3632 0 -2203.5399 4160.5763
280 1360.1974 -2290.325 0 -2200.6572 5802.3902
290 1151.9365 -2273.9467 0 -2198.008 1418.8887
300 1174.3518 -2273.0089 0 -2195.5925 1998.229
310 1329.2727 -2280.5049 0 -2192.8757 4721.7297
320 1284.4414 -2274.7519 0 -2190.0781 2985.4674
330 1328.3761 -2274.9545 0 -2187.3844 4543.2109
340 1446.3847 -2279.8693 0 -2184.5198 6254.4059
350 1366.2165 -2271.7475 0 -2181.6828 3637.8335
360 1358.9609 -2268.5982 0 -2179.0118 3049.5798
370 1552.208 -2278.4802 0 -2176.1545 6334.0058
380 1562.5295 -2276.1793 0 -2173.1732 5787.5547
390 1415.5498 -2263.7824 0 -2170.4655 3438.5766
400 1323.1568 -2255.1641 0 -2167.938 2427.2294
410 1260.7186 -2248.5373 0 -2165.4273 1208.6299
420 1282.1118 -2247.3718 0 -2162.8516 462.65374
430 1451.944 -2255.7551 0 -2160.0391 2037.8025
440 1568.9415 -2260.417 0 -2156.9882 3531.1602
450 1565.8262 -2257.2396 0 -2154.0162 2586.7886
460 1677.7143 -2261.7214 0 -2151.122 4112.9756
470 1762.9071 -2264.4244 0 -2148.2089 5053.2139
480 1704.5898 -2257.8678 0 -2145.4967 4077.4626
490 1731.2619 -2257.1048 0 -2142.9753 4710.5263
500 1723.9777 -2254.161 0 -2140.5118 4760.7295
Loop time of 0.679564 on 1 procs for 500 steps with 511 atoms
Performance: 63.570 ns/day, 0.378 hours/ns, 735.765 timesteps/s
99.7% CPU use with 1 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 0.65181 | 0.65181 | 0.65181 | 0.0 | 95.92
Neigh | 0.013857 | 0.013857 | 0.013857 | 0.0 | 2.04
Comm | 0.0033884 | 0.0033884 | 0.0033884 | 0.0 | 0.50
Output | 0.00070739 | 0.00070739 | 0.00070739 | 0.0 | 0.10
Modify | 0.0083694 | 0.0083694 | 0.0083694 | 0.0 | 1.23
Other | | 0.001432 | | | 0.21
Nlocal: 511 ave 511 max 511 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 845 ave 845 max 845 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 0 ave 0 max 0 min
Histogram: 1 0 0 0 0 0 0 0 0 0
FullNghs: 7902 ave 7902 max 7902 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 7902
Ave neighs/atom = 15.4638
Neighbor list builds = 19
Dangerous builds = 0
Total wall time: 0:00:00

View File

@ -0,0 +1,167 @@
LAMMPS (4 May 2017)
using 1 OpenMP thread(s) per MPI task
units metal
atom_style atomic
atom_modify map array
boundary p p p
atom_modify sort 0 0.0
# temperature
variable t equal 1800.0
# coordination number cutoff
variable r equal 2.835
# minimization parameters
variable etol equal 1.0e-5
variable ftol equal 1.0e-5
variable maxiter equal 100
variable maxeval equal 100
variable dmax equal 1.0e-1
# diamond unit cell
variable a equal 5.431
lattice custom $a a1 1.0 0.0 0.0 a2 0.0 1.0 0.0 a3 0.0 0.0 1.0 basis 0.0 0.0 0.0 basis 0.0 0.5 0.5 basis 0.5 0.0 0.5 basis 0.5 0.5 0.0 basis 0.25 0.25 0.25 basis 0.25 0.75 0.75 basis 0.75 0.25 0.75 basis 0.75 0.75 0.25
lattice custom 5.431 a1 1.0 0.0 0.0 a2 0.0 1.0 0.0 a3 0.0 0.0 1.0 basis 0.0 0.0 0.0 basis 0.0 0.5 0.5 basis 0.5 0.0 0.5 basis 0.5 0.5 0.0 basis 0.25 0.25 0.25 basis 0.25 0.75 0.75 basis 0.75 0.25 0.75 basis 0.75 0.75 0.25
Lattice spacing in x,y,z = 5.431 5.431 5.431
region myreg block 0 4 0 4 0 4
create_box 1 myreg
Created orthogonal box = (0 0 0) to (21.724 21.724 21.724)
1 by 2 by 2 MPI processor grid
create_atoms 1 region myreg
Created 512 atoms
mass 1 28.06
group Si type 1
512 atoms in group Si
velocity all create $t 5287287 mom yes rot yes dist gaussian
velocity all create 1800 5287287 mom yes rot yes dist gaussian
# make a vacancy
group del id 300
1 atoms in group del
delete_atoms group del
Deleted 1 atoms, new total = 511
pair_style edip/multi
pair_coeff * * Si.edip Si
Reading potential file Si.edip with DATE: 2011-09-15
thermo 10
fix 1 all nvt temp $t $t 0.1
fix 1 all nvt temp 1800 $t 0.1
fix 1 all nvt temp 1800 1800 0.1
timestep 1.0e-3
neighbor 1.0 bin
neigh_modify every 1 delay 10 check yes
# equilibrate
run 500
Neighbor list info ...
update every 1 steps, delay 10 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 4.12138
ghost atom cutoff = 4.12138
binsize = 2.06069, bins = 11 11 11
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair edip/multi, perpetual
attributes: full, newton on
pair build: full/bin/atomonly
stencil: full/bin/3d
bin: standard
Per MPI rank memory allocation (min/avg/max) = 2.955 | 2.955 | 2.955 Mbytes
Step Temp E_pair E_mol TotEng Press
0 1802.3816 -2372.6618 0 -2253.844 12260.967
10 938.75954 -2315.5185 0 -2253.6329 558.21646
20 534.27233 -2288.4721 0 -2253.2514 -2710.768
30 1043.7796 -2320.9485 0 -2252.1398 8679.4381
40 658.0916 -2293.8597 0 -2250.4765 2165.3742
50 517.93009 -2283.7238 0 -2249.5805 -1124.9373
60 1063.3594 -2318.4409 0 -2248.3414 7277.8526
70 868.14006 -2304.0134 0 -2246.7832 2050.2848
80 826.37805 -2300.0187 0 -2245.5416 91.099408
90 1289.6772 -2328.7151 0 -2243.6961 8180.7423
100 976.36208 -2305.9371 0 -2241.5727 3614.0499
110 810.81713 -2293.4705 0 -2240.0193 1359.368
120 1165.707 -2314.9026 0 -2238.056 7336.45
130 929.81245 -2297.139 0 -2235.8432 2793.8451
140 804.47874 -2287.2074 0 -2234.174 704.92455
150 1182.4141 -2310.0266 0 -2232.0787 7822.2337
160 979.92391 -2294.2969 0 -2229.6977 3206.7458
170 830.14748 -2282.6079 0 -2227.8824 -296.87377
180 1271.1133 -2309.4274 0 -2225.6322 7199.614
190 1209.6006 -2302.6407 0 -2222.9006 5528.3784
200 954.67693 -2283.6621 0 -2220.7273 47.02795
210 1260.814 -2301.5582 0 -2218.442 4829.788
220 1274.9954 -2299.7285 0 -2215.6774 5518.0597
230 1048.0074 -2282.398 0 -2213.3106 1754.4144
240 1261.7072 -2294.1108 0 -2210.9356 5233.2712
250 1272.6178 -2292.0793 0 -2208.1849 4795.9325
260 989.14205 -2271.0278 0 -2205.8209 -820.1828
270 1212.0445 -2283.4212 0 -2203.52 3395.8634
280 1391.9572 -2292.3809 0 -2200.6194 6666.2451
290 1093.1204 -2270.0421 0 -2197.9807 206.94523
300 1159.4831 -2272.102 0 -2195.6657 778.53806
310 1407.3528 -2285.6228 0 -2192.8463 5223.048
320 1236.7163 -2271.5389 0 -2190.0113 1865.3943
330 1258.8275 -2270.4611 0 -2187.4758 2333.3209
340 1507.9519 -2283.9906 0 -2184.5824 6775.5456
350 1366.5116 -2271.7287 0 -2181.6446 3432.115
360 1305.2829 -2265.1092 0 -2179.0614 1498.4073
370 1581.4335 -2280.4645 0 -2176.2122 6518.5597
380 1589.5319 -2277.9428 0 -2173.1567 6334.6506
390 1402.6781 -2262.9323 0 -2170.464 3278.3038
400 1374.9587 -2258.5717 0 -2167.9307 3608.7284
410 1295.7416 -2250.7752 0 -2165.3565 1877.5222
420 1278.6727 -2247.1099 0 -2162.8164 1599.4181
430 1508.1328 -2259.4245 0 -2160.0044 4300.2224
440 1624.2957 -2263.9806 0 -2156.9026 4432.625
450 1597.3356 -2259.263 0 -2153.9624 3370.3816
460 1772.0922 -2267.9106 0 -2151.0895 5788.3214
470 1806.4047 -2267.304 0 -2148.221 5950.1166
480 1593.0406 -2250.7469 0 -2145.7294 2518.0576
490 1660.9767 -2252.894 0 -2143.398 4282.1643
500 1714.283 -2253.9295 0 -2140.9194 5740.0247
Loop time of 0.205398 on 4 procs for 500 steps with 511 atoms
Performance: 210.324 ns/day, 0.114 hours/ns, 2434.304 timesteps/s
99.0% CPU use with 4 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 0.16285 | 0.1688 | 0.17446 | 1.1 | 82.18
Neigh | 0.0035172 | 0.0036234 | 0.0038214 | 0.2 | 1.76
Comm | 0.018727 | 0.024851 | 0.030996 | 2.9 | 12.10
Output | 0.0013061 | 0.0014012 | 0.0015635 | 0.3 | 0.68
Modify | 0.0046582 | 0.0048603 | 0.0050988 | 0.2 | 2.37
Other | | 0.001861 | | | 0.91
Nlocal: 127.75 ave 131 max 124 min
Histogram: 1 0 1 0 0 0 0 0 1 1
Nghost: 433.75 ave 441 max 426 min
Histogram: 1 0 1 0 0 0 0 0 1 1
Neighs: 0 ave 0 max 0 min
Histogram: 4 0 0 0 0 0 0 0 0 0
FullNghs: 1979.5 ave 2040 max 1895 min
Histogram: 1 0 0 0 1 0 0 0 0 2
Total # of neighbors = 7918
Ave neighs/atom = 15.4951
Neighbor list builds = 19
Dangerous builds = 0
Total wall time: 0:00:00

View File

@ -0,0 +1,167 @@
LAMMPS (4 May 2017)
using 1 OpenMP thread(s) per MPI task
units metal
atom_style atomic
atom_modify map array
boundary p p p
atom_modify sort 0 0.0
# temperature
variable t equal 1800.0
# coordination number cutoff
variable r equal 2.835
# minimization parameters
variable etol equal 1.0e-5
variable ftol equal 1.0e-5
variable maxiter equal 100
variable maxeval equal 100
variable dmax equal 1.0e-1
# diamond unit cell
variable a equal 5.431
lattice custom $a a1 1.0 0.0 0.0 a2 0.0 1.0 0.0 a3 0.0 0.0 1.0 basis 0.0 0.0 0.0 basis 0.0 0.5 0.5 basis 0.5 0.0 0.5 basis 0.5 0.5 0.0 basis 0.25 0.25 0.25 basis 0.25 0.75 0.75 basis 0.75 0.25 0.75 basis 0.75 0.75 0.25
lattice custom 5.431 a1 1.0 0.0 0.0 a2 0.0 1.0 0.0 a3 0.0 0.0 1.0 basis 0.0 0.0 0.0 basis 0.0 0.5 0.5 basis 0.5 0.0 0.5 basis 0.5 0.5 0.0 basis 0.25 0.25 0.25 basis 0.25 0.75 0.75 basis 0.75 0.25 0.75 basis 0.75 0.75 0.25
Lattice spacing in x,y,z = 5.431 5.431 5.431
region myreg block 0 4 0 4 0 4
create_box 1 myreg
Created orthogonal box = (0 0 0) to (21.724 21.724 21.724)
1 by 1 by 1 MPI processor grid
create_atoms 1 region myreg
Created 512 atoms
mass 1 28.06
group Si type 1
512 atoms in group Si
velocity all create $t 5287287 mom yes rot yes dist gaussian
velocity all create 1800 5287287 mom yes rot yes dist gaussian
# make a vacancy
group del id 300
1 atoms in group del
delete_atoms group del
Deleted 1 atoms, new total = 511
pair_style edip
pair_coeff * * Si.edip Si
Reading potential file Si.edip with DATE: 2011-09-15
thermo 10
fix 1 all nvt temp $t $t 0.1
fix 1 all nvt temp 1800 $t 0.1
fix 1 all nvt temp 1800 1800 0.1
timestep 1.0e-3
neighbor 1.0 bin
neigh_modify every 1 delay 10 check yes
# equilibrate
run 500
Neighbor list info ...
update every 1 steps, delay 10 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 4.12138
ghost atom cutoff = 4.12138
binsize = 2.06069, bins = 11 11 11
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair edip, perpetual
attributes: full, newton on
pair build: full/bin/atomonly
stencil: full/bin/3d
bin: standard
Per MPI rank memory allocation (min/avg/max) = 2.979 | 2.979 | 2.979 Mbytes
Step Temp E_pair E_mol TotEng Press
0 1802.5039 -2372.6618 0 -2253.8359 12261.807
10 952.62744 -2316.428 0 -2253.6283 723.08283
20 549.138 -2289.442 0 -2253.2413 -2444.5194
30 1047.0106 -2321.1522 0 -2252.1305 9013.2015
40 663.46143 -2294.2083 0 -2250.4711 2942.5358
50 504.74533 -2282.849 0 -2249.5748 -461.44817
60 1019.2173 -2315.5639 0 -2248.3744 7706.429
70 844.51197 -2302.5251 0 -2246.8526 3116.8313
80 814.90406 -2299.3372 0 -2245.6165 794.77536
90 1269.5635 -2327.4775 0 -2243.7845 7729.3971
100 977.61566 -2306.1118 0 -2241.6647 2969.9952
110 843.08538 -2295.6547 0 -2240.0763 1393.4046
120 1161.6968 -2314.6587 0 -2238.0766 7398.3495
130 918.19453 -2296.4321 0 -2235.9022 2537.4011
140 881.42546 -2292.2768 0 -2234.1709 1550.3345
150 1231.1005 -2313.1054 0 -2231.9479 8112.7568
160 967.01865 -2293.332 0 -2229.5836 3422.964
170 833.51246 -2282.7489 0 -2227.8015 43.99251
180 1240.8487 -2307.3633 0 -2225.5632 6557.8652
190 1126.4621 -2297.1922 0 -2222.9328 4289.0083
200 947.5957 -2283.29 0 -2220.8219 586.28203
210 1228.153 -2299.4702 0 -2218.5071 5315.0427
220 1215.4104 -2295.9407 0 -2215.8176 4870.343
230 1112.436 -2286.7552 0 -2213.4204 2527.1887
240 1300.081 -2296.6013 0 -2210.8965 5738.3711
250 1192.5739 -2286.8463 0 -2208.2286 4076.4913
260 1004.7055 -2272.1753 0 -2205.9424 359.3769
270 1241.2018 -2285.3632 0 -2203.5399 4160.5764
280 1360.1974 -2290.325 0 -2200.6572 5802.3912
290 1151.9366 -2273.9467 0 -2198.008 1418.8905
300 1174.3518 -2273.0089 0 -2195.5925 1998.2297
310 1329.2726 -2280.5049 0 -2192.8757 4721.7304
320 1284.4414 -2274.7519 0 -2190.0781 2985.4687
330 1328.3761 -2274.9545 0 -2187.3844 4543.2115
340 1446.3847 -2279.8693 0 -2184.5198 6254.4071
350 1366.2165 -2271.7475 0 -2181.6828 3637.8351
360 1358.9609 -2268.5982 0 -2179.0118 3049.5811
370 1552.2079 -2278.4802 0 -2176.1545 6334.0061
380 1562.5295 -2276.1793 0 -2173.1731 5787.5565
390 1415.5498 -2263.7823 0 -2170.4655 3438.5782
400 1323.1568 -2255.1641 0 -2167.938 2427.2311
410 1260.7186 -2248.5373 0 -2165.4273 1208.6316
420 1282.1118 -2247.3718 0 -2162.8516 462.65508
430 1451.9439 -2255.7551 0 -2160.0391 2037.8027
440 1568.9415 -2260.417 0 -2156.9882 3531.1613
450 1565.8261 -2257.2396 0 -2154.0161 2586.7896
460 1677.7143 -2261.7214 0 -2151.122 4112.976
470 1762.9071 -2264.4244 0 -2148.2089 5053.2148
480 1704.5898 -2257.8678 0 -2145.4966 4077.4649
490 1731.2619 -2257.1048 0 -2142.9753 4710.5276
500 1723.9777 -2254.161 0 -2140.5118 4760.7316
Loop time of 0.312472 on 1 procs for 500 steps with 511 atoms
Performance: 138.252 ns/day, 0.174 hours/ns, 1600.143 timesteps/s
99.6% CPU use with 1 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 0.28525 | 0.28525 | 0.28525 | 0.0 | 91.29
Neigh | 0.013753 | 0.013753 | 0.013753 | 0.0 | 4.40
Comm | 0.0033333 | 0.0033333 | 0.0033333 | 0.0 | 1.07
Output | 0.00071096 | 0.00071096 | 0.00071096 | 0.0 | 0.23
Modify | 0.008044 | 0.008044 | 0.008044 | 0.0 | 2.57
Other | | 0.001385 | | | 0.44
Nlocal: 511 ave 511 max 511 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 845 ave 845 max 845 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 0 ave 0 max 0 min
Histogram: 1 0 0 0 0 0 0 0 0 0
FullNghs: 7902 ave 7902 max 7902 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 7902
Ave neighs/atom = 15.4638
Neighbor list builds = 19
Dangerous builds = 0
Total wall time: 0:00:00

View File

@ -0,0 +1,167 @@
LAMMPS (4 May 2017)
using 1 OpenMP thread(s) per MPI task
units metal
atom_style atomic
atom_modify map array
boundary p p p
atom_modify sort 0 0.0
# temperature
variable t equal 1800.0
# coordination number cutoff
variable r equal 2.835
# minimization parameters
variable etol equal 1.0e-5
variable ftol equal 1.0e-5
variable maxiter equal 100
variable maxeval equal 100
variable dmax equal 1.0e-1
# diamond unit cell
variable a equal 5.431
lattice custom $a a1 1.0 0.0 0.0 a2 0.0 1.0 0.0 a3 0.0 0.0 1.0 basis 0.0 0.0 0.0 basis 0.0 0.5 0.5 basis 0.5 0.0 0.5 basis 0.5 0.5 0.0 basis 0.25 0.25 0.25 basis 0.25 0.75 0.75 basis 0.75 0.25 0.75 basis 0.75 0.75 0.25
lattice custom 5.431 a1 1.0 0.0 0.0 a2 0.0 1.0 0.0 a3 0.0 0.0 1.0 basis 0.0 0.0 0.0 basis 0.0 0.5 0.5 basis 0.5 0.0 0.5 basis 0.5 0.5 0.0 basis 0.25 0.25 0.25 basis 0.25 0.75 0.75 basis 0.75 0.25 0.75 basis 0.75 0.75 0.25
Lattice spacing in x,y,z = 5.431 5.431 5.431
region myreg block 0 4 0 4 0 4
create_box 1 myreg
Created orthogonal box = (0 0 0) to (21.724 21.724 21.724)
1 by 2 by 2 MPI processor grid
create_atoms 1 region myreg
Created 512 atoms
mass 1 28.06
group Si type 1
512 atoms in group Si
velocity all create $t 5287287 mom yes rot yes dist gaussian
velocity all create 1800 5287287 mom yes rot yes dist gaussian
# make a vacancy
group del id 300
1 atoms in group del
delete_atoms group del
Deleted 1 atoms, new total = 511
pair_style edip
pair_coeff * * Si.edip Si
Reading potential file Si.edip with DATE: 2011-09-15
thermo 10
fix 1 all nvt temp $t $t 0.1
fix 1 all nvt temp 1800 $t 0.1
fix 1 all nvt temp 1800 1800 0.1
timestep 1.0e-3
neighbor 1.0 bin
neigh_modify every 1 delay 10 check yes
# equilibrate
run 500
Neighbor list info ...
update every 1 steps, delay 10 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 4.12138
ghost atom cutoff = 4.12138
binsize = 2.06069, bins = 11 11 11
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair edip, perpetual
attributes: full, newton on
pair build: full/bin/atomonly
stencil: full/bin/3d
bin: standard
Per MPI rank memory allocation (min/avg/max) = 2.955 | 2.955 | 2.955 Mbytes
Step Temp E_pair E_mol TotEng Press
0 1802.3816 -2372.6618 0 -2253.8439 12260.967
10 938.75954 -2315.5185 0 -2253.6329 558.21736
20 534.27232 -2288.4721 0 -2253.2514 -2710.767
30 1043.7796 -2320.9485 0 -2252.1398 8679.4385
40 658.09162 -2293.8597 0 -2250.4765 2165.3752
50 517.93008 -2283.7238 0 -2249.5805 -1124.9362
60 1063.3594 -2318.4409 0 -2248.3414 7277.853
70 868.14007 -2304.0133 0 -2246.7832 2050.2859
80 826.37803 -2300.0187 0 -2245.5416 91.100098
90 1289.6772 -2328.7151 0 -2243.6961 8180.7427
100 976.36211 -2305.9371 0 -2241.5727 3614.0511
110 810.81711 -2293.4705 0 -2240.0193 1359.3687
120 1165.707 -2314.9026 0 -2238.056 7336.4505
130 929.81248 -2297.139 0 -2235.8432 2793.8463
140 804.47872 -2287.2074 0 -2234.174 704.92524
150 1182.414 -2310.0266 0 -2232.0787 7822.2339
160 979.92395 -2294.2969 0 -2229.6977 3206.7474
170 830.14746 -2282.6079 0 -2227.8824 -296.87288
180 1271.1133 -2309.4274 0 -2225.6322 7199.614
190 1209.6006 -2302.6407 0 -2222.9006 5528.3799
200 954.67692 -2283.6621 0 -2220.7272 47.02925
210 1260.814 -2301.5582 0 -2218.442 4829.7879
220 1274.9954 -2299.7285 0 -2215.6774 5518.0611
230 1048.0074 -2282.398 0 -2213.3106 1754.4157
240 1261.7071 -2294.1107 0 -2210.9356 5233.2714
250 1272.6179 -2292.0793 0 -2208.1849 4795.934
260 989.14207 -2271.0278 0 -2205.8209 -820.18098
270 1212.0444 -2283.4212 0 -2203.52 3395.8631
280 1391.9572 -2292.3809 0 -2200.6194 6666.2464
290 1093.1205 -2270.0421 0 -2197.9807 206.94752
300 1159.483 -2272.102 0 -2195.6657 778.53823
310 1407.3528 -2285.6227 0 -2192.8463 5223.0487
320 1236.7164 -2271.5389 0 -2190.0112 1865.3963
330 1258.8275 -2270.4611 0 -2187.4758 2333.321
340 1507.9519 -2283.9906 0 -2184.5824 6775.546
350 1366.5116 -2271.7287 0 -2181.6446 3432.1175
360 1305.2828 -2265.1091 0 -2179.0614 1498.4079
370 1581.4334 -2280.4645 0 -2176.2122 6518.5598
380 1589.5319 -2277.9428 0 -2173.1566 6334.6527
390 1402.6782 -2262.9323 0 -2170.464 3278.3048
400 1374.9587 -2258.5717 0 -2167.9307 3608.7293
410 1295.7416 -2250.7752 0 -2165.3565 1877.5245
420 1278.6727 -2247.1099 0 -2162.8164 1599.4189
430 1508.1328 -2259.4245 0 -2160.0044 4300.2235
440 1624.2957 -2263.9806 0 -2156.9026 4432.6267
450 1597.3356 -2259.263 0 -2153.9623 3370.3829
460 1772.0921 -2267.9105 0 -2151.0895 5788.3219
470 1806.4047 -2267.304 0 -2148.221 5950.1188
480 1593.0406 -2250.7469 0 -2145.7294 2518.0601
490 1660.9766 -2252.894 0 -2143.398 4282.1654
500 1714.2831 -2253.9295 0 -2140.9194 5740.0268
Loop time of 0.109584 on 4 procs for 500 steps with 511 atoms
Performance: 394.220 ns/day, 0.061 hours/ns, 4562.726 timesteps/s
99.0% CPU use with 4 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 0.074678 | 0.077817 | 0.084705 | 1.4 | 71.01
Neigh | 0.0036662 | 0.0037943 | 0.0039661 | 0.2 | 3.46
Comm | 0.013665 | 0.020312 | 0.023178 | 2.7 | 18.54
Output | 0.0010247 | 0.0010931 | 0.0012922 | 0.3 | 1.00
Modify | 0.0043213 | 0.0047521 | 0.0051889 | 0.6 | 4.34
Other | | 0.001814 | | | 1.66
Nlocal: 127.75 ave 131 max 124 min
Histogram: 1 0 1 0 0 0 0 0 1 1
Nghost: 433.75 ave 441 max 426 min
Histogram: 1 0 1 0 0 0 0 0 1 1
Neighs: 0 ave 0 max 0 min
Histogram: 4 0 0 0 0 0 0 0 0 0
FullNghs: 1979.5 ave 2040 max 1895 min
Histogram: 1 0 0 0 1 0 0 0 0 2
Total # of neighbors = 7918
Ave neighs/atom = 15.4951
Neighbor list builds = 19
Dangerous builds = 0
Total wall time: 0:00:00

View File

@ -0,0 +1,92 @@
LAMMPS (4 May 2017)
using 1 OpenMP thread(s) per MPI task
# Test of MEAM potential for SiC system
units metal
boundary p p p
atom_style atomic
read_data data.SiC
orthogonal box = (-6 -6 -6) to (5.97232 5.97232 5.97232)
1 by 1 by 1 MPI processor grid
reading atoms ...
128 atoms
pair_style edip/multi
pair_coeff * * SiC.edip Si C
Reading potential file SiC.edip with DATE: 2017-05-16
mass 1 28.085
mass 2 12.001
neighbor 1.0 bin
neigh_modify delay 1
fix 1 all nve
thermo 10
timestep 0.001
#dump 1 all atom 50 dump.meam
#dump 2 all image 10 image.*.jpg element element # axes yes 0.8 0.02 view 60 -30
#dump_modify 2 pad 3 element Si C
#dump 3 all movie 10 movie.mpg element element # axes yes 0.8 0.02 view 60 -30
#dump_modify 3 pad 3 element Si C
run 100
Neighbor list info ...
update every 1 steps, delay 1 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 3.94159
ghost atom cutoff = 3.94159
binsize = 1.97079, bins = 7 7 7
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair edip/multi, perpetual
attributes: full, newton on
pair build: full/bin/atomonly
stencil: full/bin/3d
bin: standard
Per MPI rank memory allocation (min/avg/max) = 2.692 | 2.692 | 2.692 Mbytes
Step Temp E_pair E_mol TotEng Press
0 0 -563.61621 0 -563.61621 -726147.34
10 4224.3601 -633.24829 0 -563.90103 -312355.55
20 4528.5661 -638.15183 0 -563.81071 -20091.291
30 4817.3654 -642.92111 0 -563.83905 106625.5
40 4619.4324 -639.6884 0 -563.85562 107180.42
50 4783.0025 -642.26961 0 -563.75166 75134.335
60 4525.145 -638.06177 0 -563.77681 71591.713
70 4685.2578 -640.72377 0 -563.8104 63956.042
80 4621.8393 -639.75912 0 -563.88682 18177.383
90 4834.7702 -643.34582 0 -563.97805 15282.823
100 4424.0589 -636.60208 0 -563.97656 47963.501
Loop time of 0.0552888 on 1 procs for 100 steps with 128 atoms
Performance: 156.270 ns/day, 0.154 hours/ns, 1808.685 timesteps/s
99.5% CPU use with 1 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 0.051872 | 0.051872 | 0.051872 | 0.0 | 93.82
Neigh | 0.0023525 | 0.0023525 | 0.0023525 | 0.0 | 4.25
Comm | 0.0004518 | 0.0004518 | 0.0004518 | 0.0 | 0.82
Output | 0.00014806 | 0.00014806 | 0.00014806 | 0.0 | 0.27
Modify | 0.00024796 | 0.00024796 | 0.00024796 | 0.0 | 0.45
Other | | 0.0002165 | | | 0.39
Nlocal: 128 ave 128 max 128 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 473 ave 473 max 473 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 0 ave 0 max 0 min
Histogram: 1 0 0 0 0 0 0 0 0 0
FullNghs: 2376 ave 2376 max 2376 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 2376
Ave neighs/atom = 18.5625
Neighbor list builds = 11
Dangerous builds = 0
Total wall time: 0:00:00

View File

@ -0,0 +1,92 @@
LAMMPS (4 May 2017)
using 1 OpenMP thread(s) per MPI task
# Test of MEAM potential for SiC system
units metal
boundary p p p
atom_style atomic
read_data data.SiC
orthogonal box = (-6 -6 -6) to (5.97232 5.97232 5.97232)
1 by 2 by 2 MPI processor grid
reading atoms ...
128 atoms
pair_style edip/multi
pair_coeff * * SiC.edip Si C
Reading potential file SiC.edip with DATE: 2017-05-16
mass 1 28.085
mass 2 12.001
neighbor 1.0 bin
neigh_modify delay 1
fix 1 all nve
thermo 10
timestep 0.001
#dump 1 all atom 50 dump.meam
#dump 2 all image 10 image.*.jpg element element # axes yes 0.8 0.02 view 60 -30
#dump_modify 2 pad 3 element Si C
#dump 3 all movie 10 movie.mpg element element # axes yes 0.8 0.02 view 60 -30
#dump_modify 3 pad 3 element Si C
run 100
Neighbor list info ...
update every 1 steps, delay 1 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 3.94159
ghost atom cutoff = 3.94159
binsize = 1.97079, bins = 7 7 7
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair edip/multi, perpetual
attributes: full, newton on
pair build: full/bin/atomonly
stencil: full/bin/3d
bin: standard
Per MPI rank memory allocation (min/avg/max) = 2.686 | 2.686 | 2.686 Mbytes
Step Temp E_pair E_mol TotEng Press
0 0 -563.61621 0 -563.61621 -726147.34
10 4224.3601 -633.24829 0 -563.90103 -312355.55
20 4528.5661 -638.15183 0 -563.81071 -20091.291
30 4817.3654 -642.92111 0 -563.83905 106625.5
40 4619.4324 -639.6884 0 -563.85562 107180.42
50 4783.0025 -642.26961 0 -563.75166 75134.335
60 4525.145 -638.06177 0 -563.77681 71591.713
70 4685.2578 -640.72377 0 -563.8104 63956.042
80 4621.8393 -639.75912 0 -563.88682 18177.383
90 4834.7702 -643.34582 0 -563.97805 15282.823
100 4424.0589 -636.60208 0 -563.97656 47963.501
Loop time of 0.020755 on 4 procs for 100 steps with 128 atoms
Performance: 416.285 ns/day, 0.058 hours/ns, 4818.118 timesteps/s
99.2% CPU use with 4 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 0.011816 | 0.013825 | 0.016871 | 1.6 | 66.61
Neigh | 0.00061321 | 0.00066817 | 0.00074816 | 0.0 | 3.22
Comm | 0.0023363 | 0.0054012 | 0.0075014 | 2.7 | 26.02
Output | 0.00020909 | 0.00022268 | 0.00025558 | 0.0 | 1.07
Modify | 8.3208e-05 | 9.346e-05 | 0.00010395 | 0.0 | 0.45
Other | | 0.0005446 | | | 2.62
Nlocal: 32 ave 36 max 25 min
Histogram: 1 0 0 0 0 0 0 1 1 1
Nghost: 262.75 ave 273 max 255 min
Histogram: 2 0 0 0 0 0 0 1 0 1
Neighs: 0 ave 0 max 0 min
Histogram: 4 0 0 0 0 0 0 0 0 0
FullNghs: 594 ave 687 max 453 min
Histogram: 1 0 0 0 0 0 1 1 0 1
Total # of neighbors = 2376
Ave neighs/atom = 18.5625
Neighbor list builds = 11
Dangerous builds = 0
Total wall time: 0:00:00

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