forked from lijiext/lammps
import updates to the manual from the progguide branch
This commit is contained in:
parent
21e34c5c76
commit
083fe85b68
|
@ -225,7 +225,7 @@ A few example command lines are:
|
|||
|
||||
For compiling with the Clang/LLVM compilers a CMake preset is provided that
|
||||
can be loaded with `-C ../cmake/presets/clang.cmake`. Similarly,
|
||||
`-C ../cmake/presets/intel.cmake` should switch the
|
||||
`-C ../cmake/presets/intel.cmake` should switch the
|
||||
|
||||
In addition you can set ``CMAKE_TUNE_FLAGS`` to specifically add
|
||||
compiler flags to tune for optimal performance on given hosts. By
|
||||
|
|
|
@ -126,7 +126,7 @@ in the next section.
|
|||
|
||||
.. note::
|
||||
|
||||
This unit test framework is new and still under development.
|
||||
The unit test framework is new and still under development.
|
||||
The coverage is only minimal and will be expanded over time.
|
||||
Tests styles of the same kind of style (e.g. pair styles or
|
||||
bond styles) are performed with the same executable using
|
||||
|
@ -237,12 +237,12 @@ and working.
|
|||
performed with automatically rescaled epsilon to account for
|
||||
additional loss of precision from code optimizations and different
|
||||
summation orders.
|
||||
- When compiling with aggressive compiler optimization, some tests
|
||||
- When compiling with (aggressive) compiler optimization, some tests
|
||||
are likely to fail. It is recommended to inspect the individual
|
||||
tests in detail to decide whether the specific error for a specific
|
||||
tests in detail to decide, whether the specific error for a specific
|
||||
property is acceptable (it often is), or this may be an indication
|
||||
of mis-compiled code (or undesired large of precision due to
|
||||
reordering of operations).
|
||||
of mis-compiled code (or an undesired large loss of precision due
|
||||
to significant reordering of operations and thus less error cancellation).
|
||||
|
||||
Collect and visualize code coverage metrics
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
|
|
@ -1,12 +1,12 @@
|
|||
Link LAMMPS as a library to another code
|
||||
========================================
|
||||
|
||||
LAMMPS is designed as a library of C++ objects and can thus be
|
||||
LAMMPS is designed as a library of C++ objects that can be
|
||||
integrated into other applications including Python scripts.
|
||||
The files ``src/library.cpp`` and ``src/library.h`` define a
|
||||
C-style API for using LAMMPS as a library. See the :doc:`Howto
|
||||
library <Howto_library>` doc page for a description of the interface
|
||||
and how to extend it for your needs.
|
||||
library <Howto_library>` page for a description of the interface
|
||||
and how to use it for your needs.
|
||||
|
||||
The :doc:`Build basics <Build_basics>` doc page explains how to build
|
||||
LAMMPS as either a shared or static library. This results in a file
|
||||
|
@ -31,18 +31,18 @@ the suffix ``.so.0`` (or some other number).
|
|||
communicator with a subset of MPI ranks to the function creating the
|
||||
LAMMPS instance.
|
||||
|
||||
----------
|
||||
|
||||
**Link with LAMMPS as a static library**\ :
|
||||
Link with LAMMPS as a static library
|
||||
------------------------------------
|
||||
|
||||
The calling application can link to LAMMPS as a static library with
|
||||
compilation and link commands as in the examples shown below. These
|
||||
are examples for a code written in C in the file *caller.c*.
|
||||
are examples for a code written in C in the file ``caller.c``.
|
||||
The benefit of linking to a static library is, that the resulting
|
||||
executable is independent of that library since all required
|
||||
executable code from the library is copied into the calling executable.
|
||||
|
||||
*CMake build*\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
This assumes that LAMMPS has been configured without setting a
|
||||
``LAMMPS_MACHINE`` name, installed with "make install", and the
|
||||
|
@ -55,7 +55,8 @@ The commands to compile and link a coupled executable are then:
|
|||
mpicc -c -O $(pkgconf liblammps --cflags) caller.c
|
||||
mpicxx -o caller caller.o -$(pkgconf liblammps --libs)
|
||||
|
||||
*Traditional make*\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
This assumes that LAMMPS has been compiled in the folder
|
||||
``${HOME}/lammps/src`` with "make mpi". The commands to compile and link
|
||||
|
@ -83,20 +84,20 @@ LAMMPS library without any optional packages that depend on libraries
|
|||
need to include all flags, libraries, and paths for the coupled
|
||||
executable, that are also required to link the LAMMPS executable.
|
||||
|
||||
*CMake build*\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
When using CMake, additional libraries with sources in the lib folder
|
||||
are built, but not included in ``liblammps.a`` and (currently) not
|
||||
installed with "make install" and not included in the *pkgconfig*
|
||||
installed with ``make install`` and not included in the ``pkgconfig``
|
||||
configuration file. They can be found in the top level build folder,
|
||||
but you have to determine the necessary link flags manually. It is
|
||||
therefore recommended to either use the traditional make procedure to
|
||||
build and link with a static library or build and link with a shared
|
||||
library instead.
|
||||
|
||||
.. TODO: this needs to be updated to reflect that latest CMake changes after they are complete.
|
||||
|
||||
*Traditional make*\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
After you have compiled a static LAMMPS library using the conventional
|
||||
build system for example with "make mode=static serial". And you also
|
||||
|
@ -110,10 +111,10 @@ change to:
|
|||
g++ -o caller caller.o -L${HOME}/lammps/lib/poems \
|
||||
-L${HOME}/lammps/src/STUBS -L${HOME}/lammps/src -llammps_serial -lpoems -lmpi_stubs
|
||||
|
||||
Note, that you need to link with "g++" instead of "gcc", since the
|
||||
LAMMPS library is C++ code. You can display the currently applied
|
||||
settings for building LAMMPS for the "serial" machine target by using
|
||||
the command:
|
||||
Note, that you need to link with ``g++`` instead of ``gcc`` even if you have
|
||||
written your code in C, since LAMMPS itself is C++ code. You can display the
|
||||
currently applied settings for building LAMMPS for the "serial" machine target
|
||||
by using the command:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
|
@ -123,25 +124,24 @@ Which should output something like:
|
|||
|
||||
.. code-block:: bash
|
||||
|
||||
# Compiler:
|
||||
# Compiler:
|
||||
CXX=g++
|
||||
# Linker:
|
||||
# Linker:
|
||||
LD=g++
|
||||
# Compilation:
|
||||
# Compilation:
|
||||
CXXFLAGS=-g -O3 -DLAMMPS_GZIP -DLAMMPS_MEMALIGN=64 -I${HOME}/compile/lammps/lib/poems -I${HOME}/compile/lammps/src/STUBS
|
||||
# Linking:
|
||||
# Linking:
|
||||
LDFLAGS=-g -O
|
||||
# Libraries:
|
||||
# Libraries:
|
||||
LDLIBS=-L${HOME}/compile/lammps/src -llammps_serial -L${HOME}/compile/lammps/lib/poems -L${HOME}/compile/lammps/src/STUBS -lpoems -lmpi_stubs
|
||||
|
||||
From this you can gather the necessary paths and flags. With
|
||||
makefiles for other *machine* configurations you need to do the
|
||||
equivalent and replace "serial" with the corresponding *machine* name
|
||||
equivalent and replace "serial" with the corresponding "machine" name
|
||||
of the makefile.
|
||||
|
||||
----------
|
||||
|
||||
**Link with LAMMPS as a shared library**\ :
|
||||
Link with LAMMPS as a shared library
|
||||
------------------------------------
|
||||
|
||||
When linking to LAMMPS built as a shared library, the situation becomes
|
||||
much simpler, as all dependent libraries and objects are either included
|
||||
|
@ -151,7 +151,8 @@ linking the calling executable. Only the *-I* flags are needed. So the
|
|||
example case from above of the serial version static LAMMPS library with
|
||||
the POEMS package installed becomes:
|
||||
|
||||
*CMake build*\ :
|
||||
CMake build
|
||||
^^^^^^^^^^^
|
||||
|
||||
The commands with a shared LAMMPS library compiled with the CMake
|
||||
build process are the same as for the static library.
|
||||
|
@ -161,10 +162,11 @@ build process are the same as for the static library.
|
|||
mpicc -c -O $(pkgconf liblammps --cflags) caller.c
|
||||
mpicxx -o caller caller.o -$(pkgconf --libs)
|
||||
|
||||
*Traditional make*\ :
|
||||
Traditional make
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
The commands with a shared LAMMPS library compiled with the
|
||||
traditional make build using "make mode=shared serial" becomes:
|
||||
traditional make build using ``make mode=shared serial`` becomes:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
|
@ -231,29 +233,3 @@ If a required library is missing, you would get a 'not found' entry:
|
|||
libc.so.6 => /usr/lib64/libc.so.6 (0x00007fb7c7b5d000)
|
||||
/lib64/ld-linux-x86-64.so.2 (0x00007fb7c80a2000)
|
||||
|
||||
----------
|
||||
|
||||
**Calling the LAMMPS library**\ :
|
||||
|
||||
Either flavor of library (static or shared) allows one or more LAMMPS
|
||||
objects to be instantiated from the calling program. When used from a
|
||||
C++ program, most of the symbols and functions in LAMMPS are wrapped
|
||||
in a ``LAMMPS_NS`` namespace; you can safely use any of its classes and
|
||||
methods from within the calling code, as needed, and you will not incur
|
||||
conflicts with functions and variables in your code that share the name.
|
||||
This, however, does not extend to all additional libraries bundled with
|
||||
LAMMPS in the lib folder and some of the low-level code of some packages.
|
||||
|
||||
To be compatible with C, Fortran, Python programs, the library has a simple
|
||||
C-style interface, provided in ``src/library.cpp`` and ``src/library.h``.
|
||||
|
||||
See the :doc:`Python library <Python_library>` doc page for a
|
||||
description of the Python interface to LAMMPS, which wraps the C-style
|
||||
interface from a shared library through the `ctypes python module <ctypes_>`_.
|
||||
|
||||
See the sample codes in ``examples/COUPLE/simple`` for examples of C++ and
|
||||
C and Fortran codes that invoke LAMMPS through its library interface.
|
||||
Other examples in the COUPLE directory use coupling ideas discussed on
|
||||
the :doc:`Howto couple <Howto_couple>` doc page.
|
||||
|
||||
.. _ctypes: https://docs.python.org/3/library/ctypes.html
|
||||
|
|
|
@ -169,12 +169,12 @@ ARRAY mode.
|
|||
|
||||
.. _size:
|
||||
|
||||
Size of LAMMPS data types
|
||||
Size of LAMMPS integer types
|
||||
------------------------------------
|
||||
|
||||
LAMMPS has a few integer data types which can be defined as 4-byte or
|
||||
8-byte integers. The default setting of "smallbig" is almost always
|
||||
adequate.
|
||||
LAMMPS has a few integer data types which can be defined as either
|
||||
4-byte (= 32-bit) or 8-byte (= 64-bit) integers at compile time.
|
||||
The default setting of "smallbig" is almost always adequate.
|
||||
|
||||
**CMake variable**\ :
|
||||
|
||||
|
@ -420,8 +420,8 @@ Exception handling when using LAMMPS as a library
|
|||
This setting is useful when external codes drive LAMMPS as a library.
|
||||
With this option enabled, LAMMPS errors do not kill the calling code.
|
||||
Instead, the call stack is unwound and control returns to the caller,
|
||||
e.g. to Python. Of course the calling code has to be set up to
|
||||
*catch* exceptions from within LAMMPS.
|
||||
e.g. to Python. Of course, the calling code has to be set up to
|
||||
*catch* exceptions thrown from within LAMMPS.
|
||||
|
||||
**CMake variable**\ :
|
||||
|
||||
|
@ -434,3 +434,10 @@ e.g. to Python. Of course the calling code has to be set up to
|
|||
.. code-block:: make
|
||||
|
||||
LMP_INC = -DLAMMPS_EXCEPTIONS
|
||||
|
||||
.. note::
|
||||
|
||||
When LAMMPS is running in parallel, it is not always possible to
|
||||
cleanly recover from an exception since not all parallel ranks may
|
||||
throw an exception and thus other MPI ranks may get stuck waiting for
|
||||
messages from the ones with errors.
|
||||
|
|
|
@ -31,9 +31,9 @@ does something different than this sequence:
|
|||
run 100
|
||||
|
||||
In the first case, the specified timestep (0.5 fs) is used for two
|
||||
simulations of 100 timesteps each. In the 2nd case, the default
|
||||
timestep (1.0 fs) is used for the 1st 100 step simulation and a 0.5 fs
|
||||
timestep is used for the 2nd one.
|
||||
simulations of 100 timesteps each. In the second case, the default
|
||||
timestep (1.0 fs) is used for the first 100 step simulation and a 0.5 fs
|
||||
timestep is used for the second one.
|
||||
|
||||
(2) Some commands are only valid when they follow other commands. For
|
||||
example you cannot set the temperature of a group of atoms until atoms
|
||||
|
|
|
@ -78,7 +78,7 @@ OPT.
|
|||
* :doc:`coul/long/soft (o) <pair_fep_soft>`
|
||||
* :doc:`coul/msm (o) <pair_coul>`
|
||||
* :doc:`coul/slater/cut <pair_coul_slater>`
|
||||
* :doc:`coul/slater/long <pair_coul_slater>`
|
||||
* :doc:`coul/slater/long <pair_coul_slater>`
|
||||
* :doc:`coul/shield <pair_coul_shield>`
|
||||
* :doc:`coul/streitz <pair_coul>`
|
||||
* :doc:`coul/wolf (ko) <pair_coul>`
|
||||
|
|
|
@ -142,7 +142,7 @@ follows:
|
|||
minimize.
|
||||
|
||||
\item The Special class walks the bond topology of a molecular system
|
||||
to find 1st, 2nd, 3rd neighbors of each atom. It is invoked by
|
||||
to find first, second, third neighbors of each atom. It is invoked by
|
||||
several commands, like read\_data, read\_restart, and replicate.
|
||||
|
||||
\item The Atom class stores all per-atom arrays. More precisely, they
|
||||
|
|
|
@ -23,7 +23,7 @@ We use it to show how to identify the origin of a segmentation fault.
|
|||
double *special_lj = force->special_lj;
|
||||
int newton_pair = force->newton_pair;
|
||||
+ double comx = 0.0;
|
||||
|
||||
|
||||
inum = list->inum;
|
||||
ilist = list->ilist;
|
||||
@@ -134,8 +135,10 @@ void PairLJCut::compute(int eflag, int vflag)
|
||||
|
@ -31,7 +31,7 @@ We use it to show how to identify the origin of a segmentation fault.
|
|||
}
|
||||
}
|
||||
- }
|
||||
|
||||
|
||||
+ comx += atom->rmass[i]*x[i][0]; /* BUG */
|
||||
+ }
|
||||
+ printf("comx = %g\n",comx);
|
||||
|
@ -42,7 +42,7 @@ After recompiling LAMMPS and running the input you should get something like thi
|
|||
|
||||
.. code-block:
|
||||
|
||||
$ ./lmp -in in.melt
|
||||
$ ./lmp -in in.melt
|
||||
LAMMPS (19 Mar 2020)
|
||||
OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (src/comm.cpp:94)
|
||||
using 1 OpenMP thread(s) per MPI task
|
||||
|
@ -98,11 +98,11 @@ drop back to the GDB prompt.
|
|||
Unit style : lj
|
||||
Current step : 0
|
||||
Time step : 0.005
|
||||
|
||||
|
||||
Program received signal SIGSEGV, Segmentation fault.
|
||||
0x00000000006653ab in LAMMPS_NS::PairLJCut::compute (this=0x829740, eflag=1, vflag=<optimized out>) at /home/akohlmey/compile/lammps/src/pair_lj_cut.cpp:139
|
||||
139 comx += atom->rmass[i]*x[i][0]; /* BUG */
|
||||
(gdb)
|
||||
(gdb)
|
||||
|
||||
Now typing the command "where" will show the stack of functions starting from
|
||||
the current function back to "main()".
|
||||
|
@ -119,7 +119,7 @@ the current function back to "main()".
|
|||
#4 0x0000000000410ad3 in LAMMPS_NS::Input::execute_command (this=0x7d1410) at /home/akohlmey/compile/lammps/src/input.cpp:864
|
||||
#5 0x00000000004111fb in LAMMPS_NS::Input::file (this=0x7d1410) at /home/akohlmey/compile/lammps/src/input.cpp:229
|
||||
#6 0x000000000040933a in main (argc=<optimized out>, argv=<optimized out>) at /home/akohlmey/compile/lammps/src/main.cpp:65
|
||||
(gdb)
|
||||
(gdb)
|
||||
|
||||
You can also print the value of variables and see if there is anything
|
||||
unexpected. Segmentation faults, for example, commonly happen when a
|
||||
|
@ -189,12 +189,12 @@ the console are not mixed.
|
|||
|
||||
.. code-block::
|
||||
|
||||
$ valgrind ./lmp -in in.melt
|
||||
$ valgrind ./lmp -in in.melt
|
||||
==1933642== Memcheck, a memory error detector
|
||||
==1933642== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
|
||||
==1933642== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
|
||||
==1933642== Command: ./lmp -in in.melt
|
||||
==1933642==
|
||||
==1933642==
|
||||
LAMMPS (19 Mar 2020)
|
||||
OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (src/comm.cpp:94)
|
||||
using 1 OpenMP thread(s) per MPI task
|
||||
|
@ -228,7 +228,7 @@ the console are not mixed.
|
|||
==1933642== by 0x4111FA: LAMMPS_NS::Input::file() (input.cpp:229)
|
||||
==1933642== by 0x409339: main (main.cpp:65)
|
||||
==1933642== Address 0x0 is not stack'd, malloc'd or (recently) free'd
|
||||
==1933642==
|
||||
==1933642==
|
||||
|
||||
As you can see, the stack trace information is similar to that obtained
|
||||
from GDB. In addition you get a more specific hint about what cause the
|
||||
|
|
|
@ -381,7 +381,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
|
|||
are defined.
|
||||
|
||||
*Bond atom missing in box size check*
|
||||
The 2nd atoms needed to compute a particular bond is missing on this
|
||||
The second atom needed to compute a particular bond is missing on this
|
||||
processor. Typically this is because the pairwise cutoff is set too
|
||||
short or the bond has blown apart and an atom is too far away.
|
||||
|
||||
|
@ -391,7 +391,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
|
|||
the atoms are too far apart to make a valid bond.
|
||||
|
||||
*Bond atom missing in image check*
|
||||
The 2nd atom in a particular bond is missing on this processor.
|
||||
The second atom in a particular bond is missing on this processor.
|
||||
Typically this is because the pairwise cutoff is set too short or the
|
||||
bond has blown apart and an atom is too far away.
|
||||
|
||||
|
@ -401,12 +401,12 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
|
|||
are too far apart to make a valid bond.
|
||||
|
||||
*Bond atoms %d %d missing on proc %d at step %ld*
|
||||
The 2nd atom needed to compute a particular bond is missing on this
|
||||
The second atom needed to compute a particular bond is missing on this
|
||||
processor. Typically this is because the pairwise cutoff is set too
|
||||
short or the bond has blown apart and an atom is too far away.
|
||||
|
||||
*Bond atoms missing on proc %d at step %ld*
|
||||
The 2nd atom needed to compute a particular bond is missing on this
|
||||
The second atom needed to compute a particular bond is missing on this
|
||||
processor. Typically this is because the pairwise cutoff is set too
|
||||
short or the bond has blown apart and an atom is too far away.
|
||||
|
||||
|
@ -1374,7 +1374,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
|
|||
template does not qualify.
|
||||
|
||||
*Cannot use fix box/relax on a 2nd non-periodic dimension*
|
||||
When specifying an off-diagonal pressure component, the 2nd of the two
|
||||
When specifying an off-diagonal pressure component, the second of the two
|
||||
dimensions must be periodic. E.g. if the xy component is specified,
|
||||
then the y dimension must be periodic.
|
||||
|
||||
|
@ -1388,7 +1388,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
|
|||
also keyword tri or xy, this is wrong.
|
||||
|
||||
*Cannot use fix box/relax with tilt factor scaling on a 2nd non-periodic dimension*
|
||||
When specifying scaling on a tilt factor component, the 2nd of the two
|
||||
When specifying scaling on a tilt factor component, the second of the two
|
||||
dimensions must be periodic. E.g. if the xy component is specified,
|
||||
then the y dimension must be periodic.
|
||||
|
||||
|
@ -1429,7 +1429,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
|
|||
This would be changing the same box dimension twice.
|
||||
|
||||
*Cannot use fix nvt/npt/nph on a 2nd non-periodic dimension*
|
||||
When specifying an off-diagonal pressure component, the 2nd of the two
|
||||
When specifying an off-diagonal pressure component, the second of the two
|
||||
dimensions must be periodic. E.g. if the xy component is specified,
|
||||
then the y dimension must be periodic.
|
||||
|
||||
|
@ -1447,13 +1447,13 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
|
|||
Self-explanatory.
|
||||
|
||||
*Cannot use fix nvt/npt/nph with xy scaling when y is non-periodic dimension*
|
||||
The 2nd dimension in the barostatted tilt factor must be periodic.
|
||||
The second dimension in the barostatted tilt factor must be periodic.
|
||||
|
||||
*Cannot use fix nvt/npt/nph with xz scaling when z is non-periodic dimension*
|
||||
The 2nd dimension in the barostatted tilt factor must be periodic.
|
||||
The second dimension in the barostatted tilt factor must be periodic.
|
||||
|
||||
*Cannot use fix nvt/npt/nph with yz scaling when z is non-periodic dimension*
|
||||
The 2nd dimension in the barostatted tilt factor must be periodic.
|
||||
The second dimension in the barostatted tilt factor must be periodic.
|
||||
|
||||
*Cannot use fix pour rigid and not molecule*
|
||||
Self-explanatory.
|
||||
|
@ -7192,7 +7192,7 @@ keyword to allow for additional bonds to be formed
|
|||
does not exist.
|
||||
|
||||
*Replacing a fix, but new style != old style*
|
||||
A fix ID can be used a 2nd time, but only if the style matches the
|
||||
A fix ID can be used a second time, but only if the style matches the
|
||||
previous fix. In this case it is assumed you with to reset a fix's
|
||||
parameters. This error may mean you are mistakenly re-using a fix ID
|
||||
when you do not intend to.
|
||||
|
|
|
@ -43,17 +43,17 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
|
|||
Self-explanatory.
|
||||
|
||||
*Bond atom missing in box size check*
|
||||
The 2nd atoms needed to compute a particular bond is missing on this
|
||||
The second atom needed to compute a particular bond is missing on this
|
||||
processor. Typically this is because the pairwise cutoff is set too
|
||||
short or the bond has blown apart and an atom is too far away.
|
||||
|
||||
*Bond atom missing in image check*
|
||||
The 2nd atom in a particular bond is missing on this processor.
|
||||
The second atom in a particular bond is missing on this processor.
|
||||
Typically this is because the pairwise cutoff is set too short or the
|
||||
bond has blown apart and an atom is too far away.
|
||||
|
||||
*Bond atoms missing at step %ld*
|
||||
The 2nd atom needed to compute a particular bond is missing on this
|
||||
The second atom needed to compute a particular bond is missing on this
|
||||
processor. Typically this is because the pairwise cutoff is set too
|
||||
short or the bond has blown apart and an atom is too far away.
|
||||
|
||||
|
@ -486,7 +486,7 @@ This will most likely cause errors in kinetic fluctuations.
|
|||
a new style.
|
||||
|
||||
*No Kspace calculation with verlet/split*
|
||||
The 2nd partition performs a kspace calculation so the kspace_style
|
||||
The second partition performs a kspace calculation so the kspace_style
|
||||
command must be used.
|
||||
|
||||
*No automatic unit conversion to XTC file format conventions possible for units lj*
|
||||
|
|
|
@ -163,7 +163,7 @@ Here is how you can run and visualize one of the sample problems:
|
|||
|
||||
Running the simulation produces the files *dump.indent* and
|
||||
*log.lammps*\ . You can visualize the dump file of snapshots with a
|
||||
variety of 3rd-party tools highlighted on the
|
||||
variety of third-party tools highlighted on the
|
||||
`Visualization <https://lammps.sandia.gov/viz.html>`_ page of the LAMMPS
|
||||
web site.
|
||||
|
||||
|
|
|
@ -197,7 +197,7 @@ compress individual polymer chains (molecules) in a mixture, is
|
|||
explained on the :doc:`compute chunk/spread/atom <compute_chunk_spread_atom>` command doc page.
|
||||
|
||||
(7) An example for using one set of per-chunk values for molecule
|
||||
chunks, to create a 2nd set of micelle-scale chunks (clustered
|
||||
chunks, to create a second set of micelle-scale chunks (clustered
|
||||
molecules, due to hydrophobicity), is explained on the :doc:`compute chunk/reduce <compute_reduce_chunk>` command doc page.
|
||||
|
||||
(8) An example for using one set of per-chunk values (dipole moment
|
||||
|
|
|
@ -114,19 +114,19 @@ summary screen will look like this:
|
|||
-- Detecting CXX compiler ABI info - done
|
||||
-- Detecting CXX compile features
|
||||
-- Detecting CXX compile features - done
|
||||
-- Found Git: /usr/bin/git (found version "2.25.2")
|
||||
-- Found Git: /usr/bin/git (found version "2.25.2")
|
||||
-- Running check for auto-generated files from make-based build system
|
||||
-- Found MPI_CXX: /usr/lib64/mpich/lib/libmpicxx.so (found version "3.1")
|
||||
-- Found MPI: TRUE (found version "3.1")
|
||||
-- Found MPI_CXX: /usr/lib64/mpich/lib/libmpicxx.so (found version "3.1")
|
||||
-- Found MPI: TRUE (found version "3.1")
|
||||
-- Looking for C++ include omp.h
|
||||
-- Looking for C++ include omp.h - found
|
||||
-- Found OpenMP_CXX: -fopenmp (found version "4.5")
|
||||
-- Found OpenMP: TRUE (found version "4.5")
|
||||
-- Found JPEG: /usr/lib64/libjpeg.so (found version "62")
|
||||
-- Found PNG: /usr/lib64/libpng.so (found version "1.6.37")
|
||||
-- Found ZLIB: /usr/lib64/libz.so (found version "1.2.11")
|
||||
-- Found GZIP: /usr/bin/gzip
|
||||
-- Found FFMPEG: /usr/bin/ffmpeg
|
||||
-- Found OpenMP_CXX: -fopenmp (found version "4.5")
|
||||
-- Found OpenMP: TRUE (found version "4.5")
|
||||
-- Found JPEG: /usr/lib64/libjpeg.so (found version "62")
|
||||
-- Found PNG: /usr/lib64/libpng.so (found version "1.6.37")
|
||||
-- Found ZLIB: /usr/lib64/libz.so (found version "1.2.11")
|
||||
-- Found GZIP: /usr/bin/gzip
|
||||
-- Found FFMPEG: /usr/bin/ffmpeg
|
||||
-- Performing Test COMPILER_SUPPORTS-ffast-math
|
||||
-- Performing Test COMPILER_SUPPORTS-ffast-math - Success
|
||||
-- Performing Test COMPILER_SUPPORTS-march=native
|
||||
|
@ -143,7 +143,7 @@ summary screen will look like this:
|
|||
* JPEG
|
||||
* PNG
|
||||
* ZLIB
|
||||
|
||||
|
||||
-- <<< Build configuration >>>
|
||||
Build type: RelWithDebInfo
|
||||
Install path: /home/akohlmey/.local
|
||||
|
@ -157,7 +157,7 @@ summary screen will look like this:
|
|||
Options: -ffast-math;-march=native
|
||||
-- <<< Linker flags: >>>
|
||||
-- Executable name: lmp
|
||||
-- Static library flags:
|
||||
-- Static library flags:
|
||||
-- <<< MPI flags >>>
|
||||
-- MPI includes: /usr/include/mpich-x86_64
|
||||
-- MPI libraries: /usr/lib64/mpich/lib/libmpicxx.so;/usr/lib64/mpich/lib/libmpi.so;
|
||||
|
@ -291,7 +291,7 @@ Some common CMake variables
|
|||
|
||||
.. list-table::
|
||||
:header-rows: 1
|
||||
|
||||
|
||||
* - Variable
|
||||
- Description
|
||||
* - ``CMAKE_INSTALL_PREFIX``
|
||||
|
@ -313,13 +313,13 @@ Some common CMake variables
|
|||
- Fortran compiler to be used for compilation (default: system specific, ``gfortran`` on Linux)
|
||||
* - ``CXX_COMPILER_LAUNCHER``
|
||||
- tool to launch the C++ compiler, e.g. ``ccache`` or ``distcc`` for faster compilation (default: empty)
|
||||
|
||||
|
||||
Some common LAMMPS specific variables
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. list-table::
|
||||
:header-rows: 1
|
||||
|
||||
|
||||
* - Variable
|
||||
- Description
|
||||
* - ``BUILD_MPI``
|
||||
|
@ -438,7 +438,7 @@ the target name to the command. Example: ``cmake --build . --target all`` or
|
|||
* - ``clean``
|
||||
- remove all generated files
|
||||
|
||||
|
||||
|
||||
Choosing generators
|
||||
-------------------
|
||||
|
||||
|
|
|
@ -119,7 +119,7 @@ non-polarized ions (ions without an attached satellite particle). The
|
|||
groups, one for the core atoms, another for the shell atoms.
|
||||
Non-polarized ions which might also be included in the treated system
|
||||
should not be included into either of these groups, they are taken
|
||||
into account by the *group-ID* (2nd argument) of the compute. The
|
||||
into account by the *group-ID* (second argument) of the compute. The
|
||||
groups can be defined using the :doc:`group *type*\ <group>` command.
|
||||
Note that to perform thermostatting using this definition of
|
||||
temperature, the :doc:`fix modify temp <fix_modify>` command should be
|
||||
|
|
|
@ -91,4 +91,4 @@ With these modifications, the 8 simulations of each script would run
|
|||
on the 3 partitions one after the other until all were finished.
|
||||
Initially, 3 simulations would be started simultaneously, one on each
|
||||
partition. When one finished, that partition would then start
|
||||
the 4th simulation, and so forth, until all 8 were completed.
|
||||
the fourth simulation, and so forth, until all 8 were completed.
|
||||
|
|
|
@ -28,7 +28,7 @@ scripts are based on. If that script had the line
|
|||
added to it, it would produce 2 binary restart files (tmp.restart.50
|
||||
and tmp.restart.100) as it ran.
|
||||
|
||||
This script could be used to read the 1st restart file and re-run the
|
||||
This script could be used to read the first restart file and re-run the
|
||||
last 50 timesteps:
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
|
|
@ -85,7 +85,7 @@ where *V* is the volume of the box, **X** is the original vector quantity and
|
|||
**x** is the vector in the LAMMPS basis.
|
||||
|
||||
There is no requirement that a triclinic box be periodic in any
|
||||
dimension, though it typically should be in at least the 2nd dimension
|
||||
dimension, though it typically should be in at least the second dimension
|
||||
of the tilt (y in xy) if you want to enforce a shift in periodic
|
||||
boundary conditions across that boundary. Some commands that work
|
||||
with triclinic boxes, e.g. the :doc:`fix deform <fix_deform>` and :doc:`fix npt <fix_nh>` commands, require periodicity or non-shrink-wrap
|
||||
|
@ -120,7 +120,7 @@ The 9 parameters, as well as lx,ly,lz, can be output via the
|
|||
To avoid extremely tilted boxes (which would be computationally
|
||||
inefficient), LAMMPS normally requires that no tilt factor can skew
|
||||
the box more than half the distance of the parallel box length, which
|
||||
is the 1st dimension in the tilt factor (x for xz). This is required
|
||||
is the first dimension in the tilt factor (x for xz). This is required
|
||||
both when the simulation box is created, e.g. via the
|
||||
:doc:`create_box <create_box>` or :doc:`read_data <read_data>` commands,
|
||||
as well as when the box shape changes dynamically during a simulation,
|
||||
|
@ -137,7 +137,7 @@ limit during a dynamics run (e.g. via the :doc:`fix deform <fix_deform>`
|
|||
command), then the box is "flipped" to an equivalent shape with a tilt
|
||||
factor within the bounds, so the run can continue. See the :doc:`fix deform <fix_deform>` doc page for further details.
|
||||
|
||||
One exception to this rule is if the 1st dimension in the tilt
|
||||
One exception to this rule is if the first dimension in the tilt
|
||||
factor (x for xy) is non-periodic. In that case, the limits on the
|
||||
tilt factor are not enforced, since flipping the box in that dimension
|
||||
does not change the atom positions due to non-periodicity. In this
|
||||
|
|
|
@ -34,7 +34,7 @@ Here are suggestions on how to perform these tasks:
|
|||
molecular builder that will generate complex molecular models. See
|
||||
the :doc:`Tools <Tools>` doc page for details on tools packaged with
|
||||
LAMMPS. The `Pre/post processing page <http:/lammps.sandia.gov/prepost.html>`_ of the LAMMPS website
|
||||
describes a variety of 3rd party tools for this task. Furthermore,
|
||||
describes a variety of third party tools for this task. Furthermore,
|
||||
some LAMMPS internal commands allow to reconstruct, or selectively add
|
||||
topology information, as well as provide the option to insert molecule
|
||||
templates instead of atoms for building bulk molecular systems.
|
||||
|
|
|
@ -32,11 +32,12 @@ a brief description of the basic code structure of LAMMPS.
|
|||
|
||||
----------
|
||||
|
||||
Once you are familiar with LAMMPS, you may want to bookmark :doc:`this page <Commands>` since it gives quick access to a doc page for
|
||||
Once you are familiar with LAMMPS, you may want to bookmark :doc:`this page <Commands_all>` since it gives quick access to a doc page for
|
||||
every LAMMPS command.
|
||||
|
||||
.. _lws: https://lammps.sandia.gov
|
||||
|
||||
.. _user_documentation:
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:numbered: 3
|
||||
|
|
|
@ -1,60 +1,62 @@
|
|||
Building the LAMMPS manual
|
||||
**************************
|
||||
|
||||
Depending on how you obtained LAMMPS, the doc directory has up
|
||||
to 6 sub-directories, 2 Nroff files, and optionally 2 PDF files
|
||||
plus 2 e-book format files:
|
||||
Depending on how you obtained LAMMPS and whether you have built the
|
||||
manual yourself, this directory has a number of sub-directories and
|
||||
files. Here is a list with descriptions:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
src # content files for LAMMPS documentation
|
||||
html # HTML version of the LAMMPS manual (see html/Manual.html)
|
||||
utils # tools and settings for building the documentation
|
||||
docenv # virtualenv for processing the manual sources
|
||||
doctrees # temporary data from processing the manual
|
||||
mathjax # code and fonts for rendering math in html
|
||||
Manual.pdf # large PDF version of entire manual
|
||||
Developer.pdf # small PDF with info about how LAMMPS is structured
|
||||
LAMMPS.epub # Manual in ePUB e-book format
|
||||
LAMMPS.mobi # Manual in MOBI e-book format
|
||||
lammps.1 # man page for the lammps command
|
||||
msi2lmp.1 # man page for the msi2lmp command
|
||||
README # brief info about the documentation
|
||||
src # content files for LAMMPS documentation
|
||||
html # HTML version of the LAMMPS manual (see html/Manual.html)
|
||||
utils # tools and settings for building the documentation
|
||||
lammps.1 # man page for the lammps command
|
||||
msi2lmp.1 # man page for the msi2lmp command
|
||||
Manual.pdf # large PDF version of entire manual
|
||||
Developer.pdf # small PDF with info about how LAMMPS is structured
|
||||
LAMMPS.epub # Manual in ePUB e-book format
|
||||
LAMMPS.mobi # Manual in MOBI e-book format
|
||||
docenv # virtualenv folder for processing the manual sources
|
||||
doctrees # temporary data from processing the manual
|
||||
mathjax # code and fonts for rendering math in html
|
||||
doxygen # doxygen configuration and output
|
||||
.gitignore # list of files and folders to be ignored by git
|
||||
doxygen-warn.log # logfile with warnings from running doxygen
|
||||
github-development-workflow.md # notes on the LAMMPS development workflow
|
||||
include-file-conventions.md # notes on LAMMPS' include file conventions
|
||||
|
||||
If you downloaded LAMMPS as a tarball from the web site, the html folder
|
||||
and the PDF files should be included.
|
||||
If you downloaded LAMMPS as a tarball from `the LAMMPS website <lws_>`_,
|
||||
the html folder and the PDF files should be included.
|
||||
|
||||
If you downloaded LAMMPS from the public git repository, then the HTML
|
||||
and PDF files are not included. Instead you need to create them, in one
|
||||
of two ways:
|
||||
|
||||
a. You can "fetch" the current HTML and PDF files from the LAMMPS web
|
||||
site. Just type "make fetch". This should download a html_www
|
||||
site. Just type ``make fetch``. This should download a html_www
|
||||
directory and Manual_www.pdf/Developer_www.pdf files. Note that if
|
||||
new LAMMPS features have been added more recently than the date of
|
||||
your LAMMPS version, the fetched documentation will include those
|
||||
changes (but your source code will not, unless you update your local
|
||||
repository).
|
||||
|
||||
b. You can build the HTML or PDF files yourself, by typing "make html"
|
||||
or "make pdf". This requires various tools including Sphinx, git,
|
||||
and the MathJax javascript library, which the build process will attempt
|
||||
to download automatically into a virtual environment in the folder
|
||||
doc/docenv and the folder mathjax, respectively, if not already available.
|
||||
This download is required only once, unless you type "make clean-all".
|
||||
After that, viewing and processing of the documentation can be done
|
||||
without internet access. To generate the PDF version of the manual,
|
||||
the PDFLaTeX software and several LaTeX packages are required as well.
|
||||
However, those cannot be installed automatically at the moment.
|
||||
b. You can build the HTML or PDF files yourself, by typing ``make html``
|
||||
or ``make pdf``. This requires various tools and files. Some of them
|
||||
have to be installed (more on that below). For the rest the build
|
||||
process will attempt to download and install them into a python
|
||||
virtual environment and local folders. This download is required
|
||||
only once, unless you type ``make clean-all``. After that, viewing and
|
||||
processing of the documentation can be done without internet access.
|
||||
|
||||
----------
|
||||
|
||||
The generation of all documentation is managed by the Makefile in
|
||||
the doc directory.
|
||||
The generation of all documentation is managed by the Makefile in the
|
||||
doc directory. The following documentation related make commands are
|
||||
available:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
Documentation Build Options:
|
||||
|
||||
make html # generate HTML in html dir using Sphinx
|
||||
make pdf # generate 2 PDF files (Manual.pdf,Developer.pdf)
|
||||
# in doc dir via htmldoc and pdflatex
|
||||
|
@ -62,8 +64,10 @@ the doc directory.
|
|||
# as a tarball and unpack into html dir and 2 PDFs
|
||||
make epub # generate LAMMPS.epub in ePUB format using Sphinx
|
||||
make mobi # generate LAMMPS.mobi in MOBI format using ebook-convert
|
||||
|
||||
make clean # remove intermediate RST files created by HTML build
|
||||
make clean-all # remove entire build folder and any cached data
|
||||
|
||||
make anchor_check # check for duplicate anchor labels
|
||||
make style_check # check for complete and consistent style lists
|
||||
make package_check # check for complete and consistent package lists
|
||||
|
@ -74,29 +78,30 @@ the doc directory.
|
|||
Installing prerequisites for HTML build
|
||||
=======================================
|
||||
|
||||
To run the HTML documentation build toolchain, Python 3 and virtualenv
|
||||
have to be installed. Here are instructions for common setups:
|
||||
To run the HTML documentation build toolchain, python 3, git, doxygen,
|
||||
and virtualenv have to be installed locally. Here are instructions for
|
||||
common setups:
|
||||
|
||||
Ubuntu
|
||||
------
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo apt-get install python-virtualenv
|
||||
sudo apt-get install python-virtualenv git doxygen
|
||||
|
||||
Fedora (up to version 21) and Red Hat Enterprise Linux or CentOS (up to version 7.x)
|
||||
------------------------------------------------------------------------------------
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo yum install python3-virtualenv
|
||||
sudo yum install python3-virtualenv git doxygen
|
||||
|
||||
Fedora (since version 22)
|
||||
-------------------------
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo dnf install python3-virtualenv
|
||||
sudo dnf install python3-virtualenv git doxygen
|
||||
|
||||
MacOS X
|
||||
-------
|
||||
|
@ -120,22 +125,92 @@ Once Python 3 is installed, open a Terminal and type
|
|||
|
||||
This will install virtualenv from the Python Package Index.
|
||||
|
||||
----------
|
||||
Installing prerequisites for PDF build
|
||||
======================================
|
||||
|
||||
Installing prerequisites for epub build
|
||||
=======================================
|
||||
In addition to the tools needed for building the HTML format manual,
|
||||
a working LaTeX installation with support for PDFLaTeX and a selection
|
||||
of LaTeX styles/packages are required.
|
||||
|
||||
ePUB
|
||||
----
|
||||
Installing prerequisites for e-book reader builds
|
||||
=================================================
|
||||
|
||||
Same as for HTML. This uses mostly the same tools and configuration
|
||||
files as the HTML tree. In addition it uses LaTeX to convert embedded
|
||||
In addition to the tools needed for building the HTML format manual,
|
||||
a working LaTeX installation with a few add-on LaTeX packages
|
||||
as well as the ``dvipng`` tool are required to convert embedded
|
||||
math expressions transparently into embedded images.
|
||||
|
||||
For converting the generated ePUB file to a MOBI format file
|
||||
(for e-book readers, like Kindle, that cannot read ePUB), you
|
||||
also need to have the 'ebook-convert' tool from the "calibre"
|
||||
software installed. `http://calibre-ebook.com/ <http://calibre-ebook.com/>`_
|
||||
You first create the ePUB file and then convert it with 'make mobi'
|
||||
On the Kindle readers in particular, you also have support for
|
||||
PDF files, so you could download and view the PDF version as an alternative.
|
||||
For converting the generated ePUB file to a MOBI format file (for e-book
|
||||
readers, like Kindle, that cannot read ePUB), you also need to have the
|
||||
``ebook-convert`` tool from the "calibre" software
|
||||
installed. `http://calibre-ebook.com/ <http://calibre-ebook.com/>`_
|
||||
Typing ``make mobi`` will first create the ePUB file and then convert
|
||||
it. On the Kindle readers in particular, you also have support for PDF
|
||||
files, so you could download and view the PDF version as an alternative.
|
||||
|
||||
|
||||
Instructions for Developers
|
||||
===========================
|
||||
|
||||
When adding new styles or options to the LAMMPS code, corresponding
|
||||
documentation is required and either existing files in the ``src``
|
||||
folder need to be updated or new files added. These files are written
|
||||
in `reStructuredText <rst_>`_ markup for translation with the Sphinx tool.
|
||||
|
||||
Before contributing any documentation, please check that both the HTML
|
||||
and the PDF format documentation can translate without errors. Please also
|
||||
check the output to the console for any warnings or problems. There will
|
||||
be multiple tests run automatically:
|
||||
|
||||
- A test for correctness of all anchor labels and their references
|
||||
|
||||
- A test that all LAMMPS packages (= folders with sources in
|
||||
``lammps/src``) are documented and listed. A typical warning shows
|
||||
the name of the folder with the suspected new package code and the
|
||||
documentation files where they need to be listed:
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
Found 33 standard and 41 user packages
|
||||
Standard package NEWPACKAGE missing in Packages_standard.rst
|
||||
Standard package NEWPACKAGE missing in Packages_details.rst
|
||||
|
||||
- A test that only standard, printable ASCII text characters are used.
|
||||
This runs the command ``env LC_ALL=C grep -n '[^ -~]' src/*.rst`` and
|
||||
thus prints all offending lines with filename and line number
|
||||
prepended to the screen. Special characters like the Angstrom
|
||||
:math:`\mathrm{\mathring{A}}` should be typeset with embedded math
|
||||
(like this ``:math:`\mathrm{\mathring{A}}```\ ).
|
||||
|
||||
- A test whether all styles are documented and listed in their
|
||||
respective overview pages. A typical output with warnings looks like this:
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
Parsed style names w/o suffixes from C++ tree in ../src:
|
||||
Angle styles: 21 Atom styles: 24
|
||||
Body styles: 3 Bond styles: 17
|
||||
Command styles: 41 Compute styles: 143
|
||||
Dihedral styles: 16 Dump styles: 26
|
||||
Fix styles: 223 Improper styles: 13
|
||||
Integrate styles: 4 Kspace styles: 15
|
||||
Minimize styles: 9 Pair styles: 234
|
||||
Reader styles: 4 Region styles: 8
|
||||
Compute style entry newcomp is missing or incomplete in Commands_compute.rst
|
||||
Compute style entry newcomp is missing or incomplete in compute.rst
|
||||
Fix style entry newfix is missing or incomplete in Commands_fix.rst
|
||||
Fix style entry newfix is missing or incomplete in fix.rst
|
||||
Pair style entry new is missing or incomplete in Commands_pair.rst
|
||||
Pair style entry new is missing or incomplete in pair_style.rst
|
||||
Found 6 issue(s) with style lists
|
||||
|
||||
|
||||
In addition, there is the option to run a spellcheck on the entire
|
||||
manual with ``make spelling``. This requires `a library called enchant
|
||||
<https://github.com/AbiWord/enchant>`_. To avoid printing out *false
|
||||
positives* (e.g. keywords, names, abbreviations) those can be added to
|
||||
the file ``lammps/doc/utils/sphinx-config/false_positives.txt``.
|
||||
|
||||
.. _rst: https://docutils.readthedocs.io/en/sphinx-docs/user/rst/quickstart.html
|
||||
|
||||
.. _lws: https://lammps.sandia.gov
|
||||
|
|
|
@ -27,7 +27,7 @@ derived class. See fix.h for details.
|
|||
+---------------------------+--------------------------------------------------------------------------------------------+
|
||||
| setup_pre_force | called before force computation in setup (optional) |
|
||||
+---------------------------+--------------------------------------------------------------------------------------------+
|
||||
| setup | called immediately before the 1st timestep and after forces are computed (optional) |
|
||||
| setup | called immediately before the first timestep and after forces are computed (optional) |
|
||||
+---------------------------+--------------------------------------------------------------------------------------------+
|
||||
| min_setup_pre_force | like setup_pre_force, but for minimizations instead of MD runs (optional) |
|
||||
+---------------------------+--------------------------------------------------------------------------------------------+
|
||||
|
|
|
@ -10,12 +10,12 @@ Ewald.cpp is an example of computing K-space interactions.
|
|||
Here is a brief description of methods you define in your new derived
|
||||
class. See kspace.h for details.
|
||||
|
||||
+---------------+----------------------------------------------+
|
||||
| init | initialize the calculation before a run |
|
||||
+---------------+----------------------------------------------+
|
||||
| setup | computation before the 1st timestep of a run |
|
||||
+---------------+----------------------------------------------+
|
||||
| compute | every-timestep computation |
|
||||
+---------------+----------------------------------------------+
|
||||
| memory_usage | tally of memory usage |
|
||||
+---------------+----------------------------------------------+
|
||||
+---------------+------------------------------------------------+
|
||||
| init | initialize the calculation before a run |
|
||||
+---------------+------------------------------------------------+
|
||||
| setup | computation before the first timestep of a run |
|
||||
+---------------+------------------------------------------------+
|
||||
| compute | every-timestep computation |
|
||||
+---------------+------------------------------------------------+
|
||||
| memory_usage | tally of memory usage |
|
||||
+---------------+------------------------------------------------+
|
||||
|
|
|
@ -489,7 +489,7 @@ interactions. These include Ewald, particle-particle particle-mesh
|
|||
|
||||
Building with this package requires a 1d FFT library be present on
|
||||
your system for use by the PPPM solvers. This can be the KISS FFT
|
||||
library provided with LAMMPS, 3rd party libraries like FFTW, or a
|
||||
library provided with LAMMPS, third party libraries like FFTW, or a
|
||||
vendor-supplied FFT library. See the :doc:`Build settings <Build_settings>` doc page for details on how to select
|
||||
different FFT options for your LAMPMS build.
|
||||
|
||||
|
|
|
@ -254,12 +254,3 @@ following steps:
|
|||
* You should now be able to invoke the new interface function from a
|
||||
Python script.
|
||||
|
||||
----------
|
||||
|
||||
.. autoclass:: lammps.lammps
|
||||
:members:
|
||||
:no-undoc-members:
|
||||
|
||||
.. autoclass:: lammps.NeighList
|
||||
:members:
|
||||
:no-undoc-members:
|
||||
|
|
|
@ -10,7 +10,7 @@ and type:
|
|||
>>> lmp = lammps()
|
||||
|
||||
If you get no errors, you're ready to use LAMMPS from Python. If the
|
||||
2nd command fails, the most common error to see is
|
||||
second command fails, the most common error to see is
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
|
|
|
@ -324,17 +324,17 @@ physical processors is done by MPI before LAMMPS begins. It may be
|
|||
useful in some cases to alter the rank order. E.g. to insure that
|
||||
cores within each node are ranked in a desired order. Or when using
|
||||
the :doc:`run_style verlet/split <run_style>` command with 2 partitions
|
||||
to insure that a specific Kspace processor (in the 2nd partition) is
|
||||
matched up with a specific set of processors in the 1st partition.
|
||||
to insure that a specific Kspace processor (in the second partition) is
|
||||
matched up with a specific set of processors in the first partition.
|
||||
See the :doc:`Speed tips <Speed_tips>` doc page for more details.
|
||||
|
||||
If the keyword *nth* is used with a setting *N*\ , then it means every
|
||||
Nth processor will be moved to the end of the ranking. This is useful
|
||||
when using the :doc:`run_style verlet/split <run_style>` command with 2
|
||||
partitions via the -partition command-line switch. The first set of
|
||||
processors will be in the first partition, the 2nd set in the 2nd
|
||||
processors will be in the first partition, the second set in the second
|
||||
partition. The -reorder command-line switch can alter this so that
|
||||
the 1st N procs in the 1st partition and one proc in the 2nd partition
|
||||
the first N procs in the first partition and one proc in the second partition
|
||||
will be ordered consecutively, e.g. as the cores on one physical node.
|
||||
This can boost performance. For example, if you use "-reorder nth 4"
|
||||
and "-partition 9 3" and you are running on 12 processors, the
|
||||
|
|
|
@ -37,7 +37,7 @@ The *charmm* angle style uses the potential
|
|||
E = K (\theta - \theta_0)^2 + K_{ub} (r - r_{ub})^2
|
||||
|
||||
with an additional Urey_Bradley term based on the distance :math:`r` between
|
||||
the 1st and 3rd atoms in the angle. :math:`K`, :math:`\theta_0`,
|
||||
the first and third atoms in the angle. :math:`K`, :math:`\theta_0`,
|
||||
:math:`K_{ub}`, and :math:`R_{ub}` are coefficients defined for each angle
|
||||
type.
|
||||
|
||||
|
|
|
@ -31,7 +31,7 @@ Angle coefficients can also be set in the data file read by the
|
|||
:doc:`read_data <read_data>` command or in a restart file.
|
||||
|
||||
N can be specified in one of two ways. An explicit numeric value can
|
||||
be used, as in the 1st example above. Or a wild-card asterisk can be
|
||||
be used, as in the first example above. Or a wild-card asterisk can be
|
||||
used to set the coefficients for multiple angle types. This takes the
|
||||
form "\*" or "\*n" or "n\*" or "m\*n". If N = the number of angle types,
|
||||
then an asterisk with no numeric values means all types from 1 to N. A
|
||||
|
@ -53,7 +53,7 @@ same format as the arguments of the :doc:`angle_coeff <angle_coeff>` command in
|
|||
script, except that wild-card asterisks should not be used since
|
||||
coefficients for all N types must be listed in the file. For example,
|
||||
under the "Angle Coeffs" section of a data file, the line that
|
||||
corresponds to the 1st example above would be listed as
|
||||
corresponds to the first example above would be listed as
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
|
|
|
@ -75,7 +75,7 @@ parenthesized comments):
|
|||
...
|
||||
181 180.0 0.0 0.0
|
||||
|
||||
A section begins with a non-blank line whose 1st character is not a
|
||||
A section begins with a non-blank line whose first character is not a
|
||||
"#"; blank lines or lines starting with "#" can be used as comments
|
||||
between sections. The first line begins with a keyword which
|
||||
identifies the section. The line can contain additional text, but the
|
||||
|
@ -99,7 +99,7 @@ is in the tabulated file (with effectively no preliminary
|
|||
interpolation), you should set Ntable = Nfile.
|
||||
|
||||
The "FP" parameter is optional. If used, it is followed by two values
|
||||
fplo and fphi, which are the 2nd derivatives at the innermost and
|
||||
fplo and fphi, which are the second derivatives at the innermost and
|
||||
outermost angle settings. These values are needed by the spline
|
||||
construction routines. If not specified by the "FP" parameter, they
|
||||
are estimated (less accurately) by the first two and last two
|
||||
|
@ -110,9 +110,9 @@ equilibrium angle value, which is used, for example, by the :doc:`fix shake <fix
|
|||
set to 180.0.
|
||||
|
||||
Following a blank line, the next N lines list the tabulated values.
|
||||
On each line, the 1st value is the index from 1 to N, the 2nd value is
|
||||
the angle value (in degrees), the 3rd value is the energy (in energy
|
||||
units), and the 4th is -dE/d(theta) (also in energy units). The 3rd
|
||||
On each line, the first value is the index from 1 to N, the second value is
|
||||
the angle value (in degrees), the third value is the energy (in energy
|
||||
units), and the fourth is -dE/d(theta) (also in energy units). The third
|
||||
term is the energy of the 3-atom configuration for the specified
|
||||
angle. The last term is the derivative of the energy with respect to
|
||||
the angle (in degrees, not radians). Thus the units of the last term
|
||||
|
|
|
@ -15,7 +15,7 @@ Syntax
|
|||
fix_modify AtC control momentum glc_velocity
|
||||
fix_modify AtC control momentum hoover
|
||||
fix_modify AtC control momentum flux [faceset face_set_id, interpolate]
|
||||
|
||||
|
||||
* AtC fixID = ID of :doc:`fix atc <fix_atc>` instance
|
||||
* control = name of the AtC sub-command
|
||||
* physics_type = *thermal* or *momentum*
|
||||
|
@ -52,7 +52,7 @@ the finite element temperature. *flux* is a similar mode, but rather
|
|||
adds energy to the atoms based on conservation of energy.
|
||||
|
||||
*correction_max_iterations* sets the maximum number of iterations to
|
||||
compute the 2nd order in time correction term for lambda with the
|
||||
compute the second order in time correction term for lambda with the
|
||||
fractional step method. The method uses the same tolerance as the
|
||||
controller's matrix solver.
|
||||
|
||||
|
|
|
@ -56,7 +56,7 @@ adds energy to the atoms based on conservation of energy. *hoover* and
|
|||
atoms.
|
||||
|
||||
*correction_max_iterations* sets the maximum number of iterations to
|
||||
compute the 2nd order in time correction term for lambda with the
|
||||
compute the second order in time correction term for lambda with the
|
||||
fractional step method. The method uses the same tolerance as the
|
||||
controller's matrix solver.
|
||||
|
||||
|
|
|
@ -25,8 +25,8 @@ Syntax
|
|||
- temperature : temperature derived from the relative atomic kinetic energy
|
||||
- kinetic_temperature : temperature derived from the full kinetic energy
|
||||
- number_density : simple kernel estimation of number of atoms per unit volume
|
||||
- stress : Cauchy stress tensor for eulerian analysis (atom_element_map), or 1st Piola-Kirchhoff stress tensor for lagrangian analysis
|
||||
- transformed_stress : 1st Piola-Kirchhoff stress tensor for eulerian analysis (atom_element_map), or Cauchy stress tensor for lagrangian analysis
|
||||
- stress : Cauchy stress tensor for eulerian analysis (atom_element_map), or first Piola-Kirchhoff stress tensor for lagrangian analysis
|
||||
- transformed_stress : first Piola-Kirchhoff stress tensor for eulerian analysis (atom_element_map), or Cauchy stress tensor for lagrangian analysis
|
||||
- heat_flux : spatial heat flux vector for eulerian, or referential heat flux vector for lagrangian
|
||||
- potential_energy : potential energy per unit volume
|
||||
- kinetic_energy : kinetic energy per unit volume
|
||||
|
@ -37,7 +37,7 @@ Syntax
|
|||
- eshelby_stress : configurational stress (energy-momentum) tensor defined by [Eshelby]_
|
||||
- vacancy_concentration : volume fraction of vacancy content
|
||||
- type_concentration : volume fraction of a specific atom type
|
||||
|
||||
|
||||
Examples
|
||||
""""""""
|
||||
|
||||
|
|
|
@ -23,8 +23,8 @@ Syntax
|
|||
- temperature : temperature derived from the relative atomic kinetic energy
|
||||
- kinetic_temperature : temperature derived from the full kinetic energy
|
||||
- number_density : simple kernel estimation of number of atoms per unit volume
|
||||
- stress : Cauchy stress tensor for eulerian analysis (atom_element_map), or 1st Piola-Kirchhoff stress tensor for lagrangian analysis
|
||||
- transformed_stress : 1st Piola-Kirchhoff stress tensor for eulerian analysis (atom_element_map), or Cauchy stress tensor for lagrangian analysis
|
||||
- stress : Cauchy stress tensor for eulerian analysis (atom_element_map), or first Piola-Kirchhoff stress tensor for lagrangian analysis
|
||||
- transformed_stress : first Piola-Kirchhoff stress tensor for eulerian analysis (atom_element_map), or Cauchy stress tensor for lagrangian analysis
|
||||
- heat_flux : spatial heat flux vector for eulerian, or referential heat flux vector for lagrangian
|
||||
- potential_energy : potential energy per unit volume
|
||||
- kinetic_energy : kinetic energy per unit volume
|
||||
|
|
|
@ -25,7 +25,7 @@ Syntax
|
|||
- *quartic_bar* : <half_width>
|
||||
- *quartic_cylinder* : <radius>
|
||||
- *quartic_sphere* : <radius>
|
||||
|
||||
|
||||
|
||||
|
||||
Examples
|
||||
|
|
|
@ -23,8 +23,8 @@ Syntax
|
|||
- temperature : temperature derived from the relative atomic kinetic energy
|
||||
- kinetic_temperature : temperature derived from the full kinetic energy
|
||||
- number_density : simple kernel estimation of number of atoms per unit volume
|
||||
- stress : Cauchy stress tensor for eulerian analysis (atom_element_map), or 1st Piola-Kirchhoff stress tensor for lagrangian analysis
|
||||
- transformed_stress : 1st Piola-Kirchhoff stress tensor for eulerian analysis (atom_element_map), or Cauchy stress tensor for lagrangian analysis
|
||||
- stress : Cauchy stress tensor for eulerian analysis (atom_element_map), or first Piola-Kirchhoff stress tensor for lagrangian analysis
|
||||
- transformed_stress : first Piola-Kirchhoff stress tensor for eulerian analysis (atom_element_map), or Cauchy stress tensor for lagrangian analysis
|
||||
- heat_flux : spatial heat flux vector for eulerian, or referential heat flux vector for lagrangian
|
||||
- potential_energy : potential energy per unit volume
|
||||
- kinetic_energy : kinetic energy per unit volume
|
||||
|
|
|
@ -38,7 +38,7 @@ Related AtC commands
|
|||
- :doc:`fix_modify AtC add_species <atc_add_species>`
|
||||
- :doc:`fix_modify AtC add_molecule <atc_add_molecule>`
|
||||
- :doc:`fix_modify AtC remove_molecule <atc_remove_molecule>`
|
||||
|
||||
|
||||
Default
|
||||
"""""""
|
||||
|
||||
|
|
|
@ -22,7 +22,7 @@ Examples
|
|||
|
||||
fix_modify AtC set reference_potential_energy
|
||||
fix_modify AtC set reference_potential_energy -0.05
|
||||
fix_modify AtC set reference_potential_energy myPEvalues
|
||||
fix_modify AtC set reference_potential_energy myPEvalues
|
||||
|
||||
Description
|
||||
"""""""""""
|
||||
|
|
|
@ -33,11 +33,11 @@ Command to select the thermal or momentum time integration.
|
|||
Options for thermal time integration:
|
||||
|
||||
*gear*
|
||||
atomic velocity update with 2nd order Verlet, nodal temperature update
|
||||
with 3rd or 4th order Gear, thermostats based on controlling power
|
||||
atomic velocity update with second order Verlet, nodal temperature update
|
||||
with third or fourth order Gear, thermostats based on controlling power
|
||||
|
||||
*fractional_step*
|
||||
atomic velocity update with 2nd order Verlet, mixed nodal temperature
|
||||
atomic velocity update with second order Verlet, mixed nodal temperature
|
||||
update, 3/4 Gear for continuum and 2 Verlet for atomic contributions,
|
||||
thermostats based on controlling discrete energy changes
|
||||
|
||||
|
@ -46,18 +46,18 @@ Options for thermal time integration:
|
|||
Options for momentum time integration:
|
||||
|
||||
*verlet*
|
||||
atomic velocity update with 2nd order Verlet, nodal temperature update
|
||||
with 2nd order Verlet, kinetostats based on controlling force
|
||||
atomic velocity update with second order Verlet, nodal temperature update
|
||||
with second order Verlet, kinetostats based on controlling force
|
||||
|
||||
*fractional_step*
|
||||
atomic velocity update with 2nd order Verlet, mixed nodal momentum
|
||||
update, 2nd order Verlet for continuum and exact 2nd order Verlet for
|
||||
atomic velocity update with second order Verlet, mixed nodal momentum
|
||||
update, second order Verlet for continuum and exact second order Verlet for
|
||||
atomic contributions, kinetostats based on controlling discrete
|
||||
momentum changes
|
||||
|
||||
*gear*
|
||||
atomic velocity update with 2nd order Verlet, nodal temperature update
|
||||
with 3rd or 4th order Gear, kinetostats based on controlling power.
|
||||
atomic velocity update with second order Verlet, nodal temperature update
|
||||
with third or fourth order Gear, kinetostats based on controlling power.
|
||||
|
||||
---------
|
||||
|
||||
|
|
|
@ -32,7 +32,7 @@ Bond coefficients can also be set in the data file read by the
|
|||
:doc:`read_data <read_data>` command or in a restart file.
|
||||
|
||||
N can be specified in one of two ways. An explicit numeric value can
|
||||
be used, as in the 1st example above. Or a wild-card asterisk can be
|
||||
be used, as in the first example above. Or a wild-card asterisk can be
|
||||
used to set the coefficients for multiple bond types. This takes the
|
||||
form "\*" or "\*n" or "n\*" or "m\*n". If N = the number of bond types,
|
||||
then an asterisk with no numeric values means all types from 1 to N. A
|
||||
|
@ -54,7 +54,7 @@ same format as the arguments of the bond_coeff command in an input
|
|||
script, except that wild-card asterisks should not be used since
|
||||
coefficients for all N types must be listed in the file. For example,
|
||||
under the "Bond Coeffs" section of a data file, the line that
|
||||
corresponds to the 1st example above would be listed as
|
||||
corresponds to the first example above would be listed as
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
|
|
|
@ -38,8 +38,8 @@ The *fene* bond style uses the potential
|
|||
|
||||
to define a finite extensible nonlinear elastic (FENE) potential
|
||||
:ref:`(Kremer) <fene-Kremer>`, used for bead-spring polymer models. The first
|
||||
term is attractive, the 2nd Lennard-Jones term is repulsive. The
|
||||
first term extends to :math:`R_0`, the maximum extent of the bond. The 2nd
|
||||
term is attractive, the second Lennard-Jones term is repulsive. The
|
||||
first term extends to :math:`R_0`, the maximum extent of the bond. The second
|
||||
term is cutoff at :math:`2^\frac{1}{6} \sigma`, the minimum of the LJ potential.
|
||||
|
||||
The following coefficients must be defined for each bond type via the
|
||||
|
|
|
@ -32,12 +32,12 @@ The *fene/expand* bond style uses the potential
|
|||
|
||||
to define a finite extensible nonlinear elastic (FENE) potential
|
||||
:ref:`(Kremer) <feneexpand-Kremer>`, used for bead-spring polymer models. The first
|
||||
term is attractive, the 2nd Lennard-Jones term is repulsive.
|
||||
term is attractive, the second Lennard-Jones term is repulsive.
|
||||
|
||||
The *fene/expand* bond style is similar to *fene* except that an extra
|
||||
shift factor of :math:`\Delta` (positive or negative) is added to :math:`r` to
|
||||
effectively change the bead size of the bonded atoms. The first term
|
||||
now extends to :math:`R_0 + \Delta` and the 2nd term is cutoff at :math:`2^\frac{1}{6} \sigma + \Delta`.
|
||||
now extends to :math:`R_0 + \Delta` and the second term is cutoff at :math:`2^\frac{1}{6} \sigma + \Delta`.
|
||||
|
||||
The following coefficients must be defined for each bond type via the
|
||||
:doc:`bond_coeff <bond_coeff>` command as in the example above, or in
|
||||
|
|
|
@ -74,7 +74,7 @@ parenthesized comments):
|
|||
...
|
||||
101 1.00 338.0000 -1352.0000
|
||||
|
||||
A section begins with a non-blank line whose 1st character is not a
|
||||
A section begins with a non-blank line whose first character is not a
|
||||
"#"; blank lines or lines starting with "#" can be used as comments
|
||||
between sections. The first line begins with a keyword which
|
||||
identifies the section. The line can contain additional text, but the
|
||||
|
@ -109,9 +109,9 @@ equilibrium bond length, which is used, for example, by the :doc:`fix shake <fix
|
|||
length is to the distance in the table with the lowest potential energy.
|
||||
|
||||
Following a blank line, the next N lines list the tabulated values.
|
||||
On each line, the 1st value is the index from 1 to N, the 2nd value is
|
||||
the bond length r (in distance units), the 3rd value is the energy (in
|
||||
energy units), and the 4th is the force (in force units). The bond
|
||||
On each line, the first value is the index from 1 to N, the second value is
|
||||
the bond length r (in distance units), the third value is the energy (in
|
||||
energy units), and the fourth is the force (in force units). The bond
|
||||
lengths must range from a LO value to a HI value, and increase from
|
||||
one line to the next. If the actual bond length is ever smaller than
|
||||
the LO value or larger than the HI value, then the calculation is
|
||||
|
|
|
@ -76,9 +76,9 @@ atoms becomes less than 50.0. This can be useful if you start a
|
|||
simulation with an empty box or if you wish to leave room on one side
|
||||
of the box, e.g. for atoms to evaporate from a surface.
|
||||
|
||||
For triclinic (non-orthogonal) simulation boxes, if the 2nd dimension
|
||||
For triclinic (non-orthogonal) simulation boxes, if the second dimension
|
||||
of a tilt factor (e.g. y for xy) is periodic, then the periodicity is
|
||||
enforced with the tilt factor offset. If the 1st dimension is
|
||||
enforced with the tilt factor offset. If the first dimension is
|
||||
shrink-wrapped, then the shrink wrapping is applied to the tilted box
|
||||
face, to encompass the atoms. E.g. for a positive xy tilt, the xlo
|
||||
and xhi faces of the box are planes tilting in the +y direction as y
|
||||
|
|
|
@ -38,7 +38,7 @@ skewed the triclinic box is; see the :doc:`Howto triclinic <Howto_triclinic>` do
|
|||
boxes in LAMMPS.
|
||||
|
||||
LAMMPS normally requires that no tilt factor can skew the box more
|
||||
than half the distance of the parallel box length, which is the 1st
|
||||
than half the distance of the parallel box length, which is the first
|
||||
dimension in the tilt factor (x for xz). If *tilt* is set to
|
||||
*small*\ , which is the default, then an error will be
|
||||
generated if a box is created which exceeds this limit. If *tilt*
|
||||
|
|
|
@ -82,9 +82,9 @@ neighbor atom in each requested ADF.
|
|||
is what is specified with the :doc:`neighbor <neighbor>` command.
|
||||
|
||||
The *itypeN*\ ,\ *jtypeN*\ ,\ *ktypeN* settings can be specified in one of two
|
||||
ways. An explicit numeric value can be used, as in the 1st example
|
||||
ways. An explicit numeric value can be used, as in the first example
|
||||
above. Or a wild-card asterisk can be used to specify a range of atom
|
||||
types as in the 2nd example above.
|
||||
types as in the second example above.
|
||||
This takes the form "\*" or "\*n" or "n\*" or "m\*n". If N = the
|
||||
number of atom types, then an asterisk with no numeric values means
|
||||
all types from 1 to N. A leading asterisk means all types from 1 to n
|
||||
|
@ -92,12 +92,12 @@ all types from 1 to N. A leading asterisk means all types from 1 to n
|
|||
(inclusive). A middle asterisk means all types from m to n
|
||||
(inclusive).
|
||||
|
||||
If *itypeN*\ , *jtypeN*\ , and *ktypeN* are single values, as in the 1st example
|
||||
If *itypeN*\ , *jtypeN*\ , and *ktypeN* are single values, as in the first example
|
||||
above, this means that the ADF is computed where atoms of type *itypeN*
|
||||
are the central atom, and neighbor atoms of type *jtypeN* and *ktypeN*
|
||||
are forming the angle. If any of *itypeN*\ , *jtypeN*\ , or *ktypeN*
|
||||
represent a range of values via
|
||||
the wild-card asterisk, as in the 2nd example above, this means that the
|
||||
the wild-card asterisk, as in the second example above, this means that the
|
||||
ADF is computed where atoms of any of the range of types represented
|
||||
by *itypeN* are the central atom, and the angle is formed by two neighbors,
|
||||
one neighbor in the range of types represented by *jtypeN* and another neighbor
|
||||
|
|
|
@ -218,8 +218,8 @@ into ellipses.
|
|||
The created bins (and hence the chunk IDs) are numbered consecutively
|
||||
from 1 to the number of bins = *Nchunk*\ . For *bin2d* and *bin3d*\ , the
|
||||
numbering varies most rapidly in the first dimension (which could be
|
||||
x, y, or z), next rapidly in the 2nd dimension, and most slowly in the
|
||||
3rd dimension. For *bin/sphere*\ , the bin with smallest radii is chunk
|
||||
x, y, or z), next rapidly in the second dimension, and most slowly in the
|
||||
third dimension. For *bin/sphere*\ , the bin with smallest radii is chunk
|
||||
1 and the bni with largest radii is chunk Nchunk = *ncbin*\ . For
|
||||
*bin/cylinder*\ , the numbering varies most rapidly in the dimension
|
||||
along the cylinder axis and most slowly in the radial direction.
|
||||
|
@ -614,7 +614,7 @@ Note that for the *bin/sphere* style, the radii *srmin* and *srmax* are
|
|||
scaled by the lattice spacing or reduced value of the *x* dimension.
|
||||
|
||||
Note that for the *bin/cylinder* style, the radii *crmin* and *crmax*
|
||||
are scaled by the lattice spacing or reduced value of the 1st
|
||||
are scaled by the lattice spacing or reduced value of the first
|
||||
dimension perpendicular to the cylinder axis. E.g. y for an x-axis
|
||||
cylinder, x for a y-axis cylinder, and x for a z-axis cylinder.
|
||||
|
||||
|
|
|
@ -63,7 +63,7 @@ keywords are listed, a single coordination number is calculated, which
|
|||
includes atoms of all types (same as the "\*" format, see below).
|
||||
|
||||
The *typeN* keywords can be specified in one of two ways. An explicit
|
||||
numeric value can be used, as in the 2nd example above. Or a
|
||||
numeric value can be used, as in the second example above. Or a
|
||||
wild-card asterisk can be used to specify a range of atom types. This
|
||||
takes the form "\*" or "\*n" or "n\*" or "m\*n". If N = the number of
|
||||
atom types, then an asterisk with no numeric values means all types
|
||||
|
|
|
@ -36,7 +36,7 @@ all effects due to atoms passing through periodic boundaries.
|
|||
|
||||
A vector of four quantities per atom is calculated by this compute.
|
||||
The first 3 elements of the vector are the dx,dy,dz displacements.
|
||||
The 4th component is the total displacement, i.e. sqrt(dx\*dx + dy\*dy +
|
||||
The fourth component is the total displacement, i.e. sqrt(dx\*dx + dy\*dy +
|
||||
dz\*dz).
|
||||
|
||||
The displacement of an atom is from its original position at the time
|
||||
|
|
|
@ -224,7 +224,7 @@ the pair\_\*.cpp file associated with the potential.
|
|||
|
||||
Similar to the :doc:`pair_coeff <pair_coeff>` command, I and J can be
|
||||
specified in one of two ways. Explicit numeric values can be used for
|
||||
each, as in the 1st example above. I <= J is required. LAMMPS sets
|
||||
each, as in the first example above. I <= J is required. LAMMPS sets
|
||||
the coefficients for the symmetric J,I interaction to the same
|
||||
values. A wild-card asterisk can be used in place of or in conjunction
|
||||
with the I,J arguments to set the coefficients for multiple pairs of
|
||||
|
|
|
@ -64,7 +64,7 @@ If the *kspace* keyword is set to *yes*\ , which is not the default, and
|
|||
if a :doc:`kspace_style <kspace_style>` is defined, then the interaction
|
||||
energy will include a Kspace component which is the long-range
|
||||
Coulombic energy between all the atoms in the first group and all the
|
||||
atoms in the 2nd group. Likewise, the interaction force calculated by
|
||||
atoms in the second group. Likewise, the interaction force calculated by
|
||||
this compute will include the force on the compute group atoms due to
|
||||
long-range Coulombic interactions with atoms in the specified group2.
|
||||
|
||||
|
|
|
@ -38,7 +38,7 @@ parameter of mean-squared displacement, see the :doc:`compute msd/nongauss <comp
|
|||
|
||||
A vector of four quantities is calculated by this compute. The first 3
|
||||
elements of the vector are the squared dx,dy,dz displacements, summed
|
||||
and averaged over atoms in the group. The 4th element is the total
|
||||
and averaged over atoms in the group. The fourth element is the total
|
||||
squared displacement, i.e. (dx\*dx + dy\*dy + dz\*dz), summed and
|
||||
averaged over atoms in the group.
|
||||
|
||||
|
|
|
@ -36,7 +36,7 @@ they can be used to measure properties of a system.
|
|||
|
||||
Four quantities are calculated by this compute for each chunk. The
|
||||
first 3 quantities are the squared dx,dy,dz displacements of the
|
||||
center-of-mass. The 4th component is the total squared displacement,
|
||||
center-of-mass. The fourth component is the total squared displacement,
|
||||
i.e. (dx\*dx + dy\*dy + dz\*dz) of the center-of-mass. These
|
||||
calculations include all effects due to atoms passing through periodic
|
||||
boundaries.
|
||||
|
|
|
@ -39,7 +39,7 @@ element of the vector is the total squared dx,dy,dz displacements
|
|||
drsquared = (dx\*dx + dy\*dy + dz\*dz) of atoms, and the second is the
|
||||
fourth power of these displacements drfourth = (dx\*dx + dy\*dy +
|
||||
dz\*dz)\*(dx\*dx + dy\*dy + dz\*dz), summed and averaged over atoms in the
|
||||
group. The 3rd component is the nonGaussian diffusion parameter NGP =
|
||||
group. The third component is the nonGaussian diffusion parameter NGP =
|
||||
3\*drfourth/(5\*drsquared\*drsquared), i.e.
|
||||
|
||||
.. math::
|
||||
|
@ -68,7 +68,7 @@ page for an overview of LAMMPS output options.
|
|||
|
||||
The vector values are "intensive". The first vector value will be in
|
||||
distance\^2 :doc:`units <units>`, the second is in distance\^4 units, and
|
||||
the 3rd is dimensionless.
|
||||
the third is dimensionless.
|
||||
|
||||
Restrictions
|
||||
""""""""""""
|
||||
|
|
|
@ -63,7 +63,7 @@ chunkID. This means that the original chunk IDs (e.g. molecule IDs)
|
|||
will have been compressed to remove chunk IDs with no atoms assigned
|
||||
to them. Thus a compressed chunk ID of 3 may correspond to an original
|
||||
chunk ID (molecule ID in this case) of 415. The *id* attribute will
|
||||
then be 415 for the 3rd chunk.
|
||||
then be 415 for the third chunk.
|
||||
|
||||
The *coordN* attributes can only be used if a *binning* style was used
|
||||
in the :doc:`compute chunk/atom <compute_chunk_atom>` command referenced
|
||||
|
|
|
@ -97,7 +97,7 @@ listed, then a separate histogram is generated for each
|
|||
*itype*\ ,\ *jtype* pair.
|
||||
|
||||
The *itypeN* and *jtypeN* settings can be specified in one of two
|
||||
ways. An explicit numeric value can be used, as in the 4th example
|
||||
ways. An explicit numeric value can be used, as in the fourth example
|
||||
above. Or a wild-card asterisk can be used to specify a range of atom
|
||||
types. This takes the form "\*" or "\*n" or "n\*" or "m\*n". If N = the
|
||||
number of atom types, then an asterisk with no numeric values means
|
||||
|
@ -106,11 +106,11 @@ all types from 1 to N. A leading asterisk means all types from 1 to n
|
|||
(inclusive). A middle asterisk means all types from m to n
|
||||
(inclusive).
|
||||
|
||||
If both *itypeN* and *jtypeN* are single values, as in the 4th example
|
||||
If both *itypeN* and *jtypeN* are single values, as in the fourth example
|
||||
above, this means that a g(r) is computed where atoms of type *itypeN*
|
||||
are the central atom, and atoms of type *jtypeN* are the distribution
|
||||
atom. If either *itypeN* and *jtypeN* represent a range of values via
|
||||
the wild-card asterisk, as in the 5th example above, this means that a
|
||||
the wild-card asterisk, as in the fifth example above, this means that a
|
||||
g(r) is computed where atoms of any of the range of types represented
|
||||
by *itypeN* are the central atom, and atoms of any of the range of
|
||||
types represented by *jtypeN* are the distribution atom.
|
||||
|
|
|
@ -49,7 +49,7 @@ respective group IDs, which can be defined using the
|
|||
must be the same and there should be one bond defined between a pair
|
||||
of atoms in the two groups. Non-polarized ions which might also be
|
||||
included in the treated system should not be included into either of
|
||||
these groups, they are taken into account by the *group-ID* (2nd
|
||||
these groups, they are taken into account by the *group-ID* (second
|
||||
argument) of the compute.
|
||||
|
||||
The temperature is calculated by the formula KE = dim/2 N k T, where
|
||||
|
|
|
@ -76,7 +76,7 @@ with respect to *lambda*\ .
|
|||
|
||||
To perform this calculation, you provide one or more atom types as
|
||||
*atype*\ . *Atype* can be specified in one of two ways. An explicit
|
||||
numeric values can be used, as in the 1st example above. Or a
|
||||
numeric values can be used, as in the first example above. Or a
|
||||
wildcard asterisk can be used in place of or in conjunction with the
|
||||
*atype* argument to select multiple atom types. This takes the form
|
||||
"\*" or "\*n" or "n\*" or "m\*n". If N = the number of atom types, then
|
||||
|
|
|
@ -33,7 +33,7 @@ A vector of four quantities is calculated by this compute. The first 3
|
|||
elements of the vector are vx \* vx0 (and similarly for the y and z
|
||||
components), summed and averaged over atoms in the group. Vx is the
|
||||
current x-component of velocity for the atom, vx0 is the initial
|
||||
x-component of velocity for the atom. The 4th element of the vector
|
||||
x-component of velocity for the atom. The fourth element of the vector
|
||||
is the total VACF, i.e. (vx\*vx0 + vy\*vy0 + vz\*vz0), summed and
|
||||
averaged over atoms in the group.
|
||||
|
||||
|
|
|
@ -73,7 +73,7 @@ or :doc:`read_restart <read_restart>` commands:
|
|||
The weighting factor is required to correct for double counting
|
||||
pairwise non-bonded Lennard-Jones interactions in cyclic systems or
|
||||
when using the CHARMM dihedral style with non-CHARMM force fields.
|
||||
With the CHARMM dihedral style, interactions between the 1st and 4th
|
||||
With the CHARMM dihedral style, interactions between the first and fourth
|
||||
atoms in a dihedral are skipped during the normal non-bonded force
|
||||
computation and instead evaluated as part of the dihedral using
|
||||
special epsilon and sigma values specified with the
|
||||
|
@ -93,7 +93,7 @@ which applies to all 1-4 interactions in the system. For CHARMM force
|
|||
fields, the special_bonds 1-4 interaction scaling factor should be set
|
||||
to 0.0. Since the corresponding 1-4 non-bonded interactions are
|
||||
computed with the dihedral. This means that if any of the weighting
|
||||
factors defined as dihedral coefficients (4th coeff above) are
|
||||
factors defined as dihedral coefficients (fourth coeff above) are
|
||||
non-zero, then you must use a pair style with "lj/charmm" and set the
|
||||
special_bonds 1-4 scaling factor to 0.0 (which is the
|
||||
default). Otherwise 1-4 non-bonded interactions in dihedrals will be
|
||||
|
@ -115,7 +115,7 @@ 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
|
||||
defaults (1/2 and 5/6) and all the dihedral weighting factors (4th
|
||||
defaults (1/2 and 5/6) and all the dihedral weighting factors (fourth
|
||||
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
|
||||
|
|
|
@ -31,7 +31,7 @@ Dihedral coefficients can also be set in the data file read by the
|
|||
:doc:`read_data <read_data>` command or in a restart file.
|
||||
|
||||
N can be specified in one of two ways. An explicit numeric value can
|
||||
be used, as in the 1st example above. Or a wild-card asterisk can be
|
||||
be used, as in the first example above. Or a wild-card asterisk can be
|
||||
used to set the coefficients for multiple dihedral types. This takes the
|
||||
form "\*" or "\*n" or "n\*" or "m\*n". If N = the number of dihedral types,
|
||||
then an asterisk with no numeric values means all types from 1 to N. A
|
||||
|
@ -53,7 +53,7 @@ same format as the arguments of the dihedral_coeff command in an input
|
|||
script, except that wild-card asterisks should not be used since
|
||||
coefficients for all N types must be listed in the file. For example,
|
||||
under the "Dihedral Coeffs" section of a data file, the line that
|
||||
corresponds to the 1st example above would be listed as
|
||||
corresponds to the first example above would be listed as
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
|
|
|
@ -92,7 +92,7 @@ or blank lines.
|
|||
...
|
||||
30 180.0 -0.707106781187
|
||||
|
||||
A section begins with a non-blank line whose 1st character is not a
|
||||
A section begins with a non-blank line whose first character is not a
|
||||
"#"; blank lines or lines starting with "#" can be used as comments
|
||||
between sections. The first line begins with a keyword which
|
||||
identifies the section. The line can contain additional text, but the
|
||||
|
@ -102,10 +102,10 @@ any order) one or more parameters for the table. Each parameter is a
|
|||
keyword followed by one or more numeric values.
|
||||
|
||||
Following a blank line, the next N lines list the tabulated values. On
|
||||
each line, the 1st value is the index from 1 to N, the 2nd value is
|
||||
the angle value, the 3rd value is the energy (in energy units), and
|
||||
the 4th is -dE/d(phi) also in energy units). The 3rd term is the
|
||||
energy of the 4-atom configuration for the specified angle. The 4th
|
||||
each line, the first value is the index from 1 to N, the second value is
|
||||
the angle value, the third value is the energy (in energy units), and
|
||||
the fourth is -dE/d(phi) also in energy units). The third term is the
|
||||
energy of the 4-atom configuration for the specified angle. The fourth
|
||||
term (when present) is the negative derivative of the energy with
|
||||
respect to the angle (in degrees, or radians depending on whether the
|
||||
user selected DEGREES or RADIANS). Thus the units of the last term
|
||||
|
@ -147,9 +147,9 @@ choice of angle units).
|
|||
|
||||
The optional "NOF" keyword allows the user to omit the forces
|
||||
(negative energy derivatives) from the table file (normally located in
|
||||
the 4th column). In their place, forces will be calculated
|
||||
the fourth column). In their place, forces will be calculated
|
||||
automatically by differentiating the potential energy function
|
||||
indicated by the 3rd column of the table (using either linear or
|
||||
indicated by the third column of the table (using either linear or
|
||||
spline interpolation).
|
||||
|
||||
The optional "DEGREES" keyword allows the user to specify angles in
|
||||
|
@ -157,7 +157,7 @@ degrees instead of radians (default).
|
|||
|
||||
The optional "RADIANS" keyword allows the user to specify angles in
|
||||
radians instead of degrees. (Note: This changes the way the forces
|
||||
are scaled in the 4th column of the data file.)
|
||||
are scaled in the fourth column of the data file.)
|
||||
|
||||
The optional "CHECKU" keyword is followed by a filename. This allows
|
||||
the user to save all of the *Ntable* different entries in the
|
||||
|
|
|
@ -113,7 +113,7 @@ or blank lines.
|
|||
...
|
||||
30 180.0 -0.707106781187
|
||||
|
||||
A section begins with a non-blank line whose 1st character is not a
|
||||
A section begins with a non-blank line whose first character is not a
|
||||
"#"; blank lines or lines starting with "#" can be used as comments
|
||||
between sections. The first line begins with a keyword which
|
||||
identifies the section. The line can contain additional text, but the
|
||||
|
@ -123,10 +123,10 @@ any order) one or more parameters for the table. Each parameter is a
|
|||
keyword followed by one or more numeric values.
|
||||
|
||||
Following a blank line, the next N lines list the tabulated values. On
|
||||
each line, the 1st value is the index from 1 to N, the 2nd value is
|
||||
the angle value, the 3rd value is the energy (in energy units), and
|
||||
the 4th is -dE/d(phi) also in energy units). The 3rd term is the
|
||||
energy of the 4-atom configuration for the specified angle. The 4th
|
||||
each line, the first value is the index from 1 to N, the second value is
|
||||
the angle value, the third value is the energy (in energy units), and
|
||||
the fourth is -dE/d(phi) also in energy units). The third term is the
|
||||
energy of the 4-atom configuration for the specified angle. The fourth
|
||||
term (when present) is the negative derivative of the energy with
|
||||
respect to the angle (in degrees, or radians depending on whether the
|
||||
user selected DEGREES or RADIANS). Thus the units of the last term
|
||||
|
@ -168,9 +168,9 @@ choice of angle units).
|
|||
|
||||
The optional "NOF" keyword allows the user to omit the forces
|
||||
(negative energy derivatives) from the table file (normally located in
|
||||
the 4th column). In their place, forces will be calculated
|
||||
the fourth column). In their place, forces will be calculated
|
||||
automatically by differentiating the potential energy function
|
||||
indicated by the 3rd column of the table (using either linear or
|
||||
indicated by the third column of the table (using either linear or
|
||||
spline interpolation).
|
||||
|
||||
The optional "DEGREES" keyword allows the user to specify angles in
|
||||
|
@ -178,7 +178,7 @@ degrees instead of radians (default).
|
|||
|
||||
The optional "RADIANS" keyword allows the user to specify angles in
|
||||
radians instead of degrees. (Note: This changes the way the forces
|
||||
are scaled in the 4th column of the data file.)
|
||||
are scaled in the fourth column of the data file.)
|
||||
|
||||
The optional "CHECKU" keyword is followed by a filename. This allows
|
||||
the user to save all of the *Ntable* different entries in the
|
||||
|
|
|
@ -134,17 +134,23 @@ Only atoms in the specified group are rendered in the image. The
|
|||
alter what atoms are included in the image.
|
||||
The filename suffix determines whether a JPEG, PNG, or PPM file is
|
||||
created with the *image* dump style. If the suffix is ".jpg" or
|
||||
".jpeg", then a JPEG format file is created, if the suffix is ".png",
|
||||
then a PNG format is created, else a PPM (aka NETPBM) format file is
|
||||
created. The JPEG and PNG files are binary; PPM has a text mode
|
||||
header followed by binary data. JPEG images have lossy compression;
|
||||
PNG has lossless compression; and PPM files are uncompressed but can
|
||||
be compressed with gzip, if LAMMPS has been compiled with
|
||||
-DLAMMPS_GZIP and a ".gz" suffix is used.
|
||||
".jpeg", then a `JPEG format <jpeg_format_>`_ file is created, if the
|
||||
suffix is ".png", then a `PNG format <png_format_>`_ is created, else
|
||||
a `PPM (aka NETPBM) format <ppm_format_>`_ file is created.
|
||||
The JPEG and PNG files are binary; PPM has a text mode header followed
|
||||
by binary data. JPEG images have lossy compression, PNG has lossless
|
||||
compression, and PPM files are uncompressed but can be compressed with
|
||||
gzip, if LAMMPS has been compiled with -DLAMMPS_GZIP and a ".gz" suffix
|
||||
is used.
|
||||
|
||||
.. _jpeg_format: https://jpeg.org/jpeg/
|
||||
.. _png_format: https://en.wikipedia.org/wiki/Portable_Network_Graphics
|
||||
.. _ppm_format: https://en.wikipedia.org/wiki/Netpbm
|
||||
|
||||
Similarly, the format of the resulting movie is chosen with the
|
||||
*movie* dump style. This is handled by the underlying FFmpeg converter
|
||||
and thus details have to be looked up in the FFmpeg documentation.
|
||||
and thus details have to be looked up in the `FFmpeg documentation
|
||||
<http://ffmpeg.org/ffmpeg.html>`_.
|
||||
Typical examples are: .avi, .mpg, .m4v, .mp4, .mkv, .flv, .mov, .gif
|
||||
Additional settings of the movie compression like bitrate and
|
||||
framerate can be set using the :doc:`dump_modify <dump_modify>` command.
|
||||
|
|
|
@ -306,7 +306,7 @@ must enclose in quotes if it is more than one field. The *int* and
|
|||
*float* keywords take a single format argument and are applied to all
|
||||
integer or floating-point quantities output. The setting for *M
|
||||
string* also takes a single format argument which is used for the Mth
|
||||
value output in each line, e.g. the 5th column is output in high
|
||||
value output in each line, e.g. the fifth column is output in high
|
||||
precision for "format 5 %20.15g".
|
||||
|
||||
.. note::
|
||||
|
@ -419,7 +419,7 @@ be written, by processors 0,25,50,75. Each will collect information
|
|||
from itself and the next 24 processors and write it to a dump file.
|
||||
|
||||
For the *fileper* keyword, the specified value of Np means write one
|
||||
file for every Np processors. For example, if Np = 4, every 4th
|
||||
file for every Np processors. For example, if Np = 4, every fourth
|
||||
processor (0,4,8,12,etc) will collect information from itself and the
|
||||
next 3 processors and write it to a dump file.
|
||||
|
||||
|
@ -790,7 +790,7 @@ for the sequential style; otherwise the value is ignored. It
|
|||
specifies the bin size to use within the range for assigning
|
||||
consecutive colors to. For example, if the range is from -10.0 to
|
||||
10.0 and a *delta* of 1.0 is used, then 20 colors will be assigned to
|
||||
the range. The first will be from -10.0 <= color1 < -9.0, then 2nd
|
||||
the range. The first will be from -10.0 <= color1 < -9.0, then second
|
||||
from -9.0 <= color2 < -8.0, etc.
|
||||
|
||||
The *N* setting is how many entries follow. The format of the entries
|
||||
|
|
|
@ -70,7 +70,7 @@ See the :doc:`Build package <Build_package>` doc page for more info.
|
|||
Related commands
|
||||
""""""""""""""""
|
||||
|
||||
:doc:`fix phonon <fix_phonon>`, :doc:`fix numdiff <fix_numdiff>`,
|
||||
:doc:`fix phonon <fix_phonon>`, :doc:`fix numdiff <fix_numdiff>`,
|
||||
|
||||
:doc:`compute hma <compute_hma>` uses an analytic formulation of the
|
||||
Hessian provided by a pair_style's Pair::single_hessian() function,
|
||||
|
|
|
@ -229,7 +229,7 @@ specified, but are ignored.
|
|||
|
||||
Similar to the :doc:`pair_coeff command <pair_coeff>`, I and J can be
|
||||
specified in one of two ways. Explicit numeric values can be used for
|
||||
each, as in the 1st example above. I <= J is required. LAMMPS sets
|
||||
each, as in the first example above. I <= J is required. LAMMPS sets
|
||||
the coefficients for the symmetric J,I interaction to the same values.
|
||||
|
||||
A wild-card asterisk can be used in place of or in conjunction with
|
||||
|
|
|
@ -199,7 +199,7 @@ specified, but are ignored.
|
|||
|
||||
Similar to the :doc:`pair_coeff command <pair_coeff>`, I and J can be
|
||||
specified in one of two ways. Explicit numeric values can be used for
|
||||
each, as in the 1st example above. I <= J is required. LAMMPS sets
|
||||
each, as in the first example above. I <= J is required. LAMMPS sets
|
||||
the coefficients for the symmetric J,I interaction to the same values.
|
||||
|
||||
A wild-card asterisk can be used in place of or in conjunction with
|
||||
|
|
|
@ -435,7 +435,7 @@ column is only used if the *compress* keyword was set to *yes* for the
|
|||
the original chunk IDs (e.g. molecule IDs) will have been compressed
|
||||
to remove chunk IDs with no atoms assigned to them. Thus a compressed
|
||||
chunk ID of 3 may correspond to an original chunk ID or molecule ID of
|
||||
415. The OrigID column will list 415 for the 3rd chunk.
|
||||
415. The OrigID column will list 415 for the third chunk.
|
||||
|
||||
The CoordN columns only appear if a *binning* style was used in the
|
||||
:doc:`compute chunk/atom <compute_chunk_atom>` command. For *bin/1d*\ ,
|
||||
|
|
|
@ -321,7 +321,7 @@ accessed on timesteps that are multiples of *Nfreq* since that is when
|
|||
averaging is performed. The global array has # of rows = *Nrepeat*
|
||||
and # of columns = Npair+2. The first column has the time delta (in
|
||||
timesteps) between the pairs of input values used to calculate the
|
||||
correlation, as described above. The 2nd column has the number of
|
||||
correlation, as described above. The second column has the number of
|
||||
samples contributing to the correlation average, as described above.
|
||||
The remaining Npair columns are for I,J pairs of the N input values,
|
||||
as determined by the *type* keyword, as described above.
|
||||
|
|
|
@ -346,10 +346,10 @@ values:
|
|||
* 4 = max value of all input values, including ones not histogrammed
|
||||
|
||||
The global array has # of rows = Nbins and # of columns = 3. The
|
||||
first column has the bin coordinate, the 2nd column has the count of
|
||||
values in that histogram bin, and the 3rd column has the bin count
|
||||
first column has the bin coordinate, the second column has the count of
|
||||
values in that histogram bin, and the third column has the bin count
|
||||
divided by the total count (not including missing counts), so that the
|
||||
values in the 3rd column sum to 1.0.
|
||||
values in the third column sum to 1.0.
|
||||
|
||||
The vector and array values calculated by this fix are all treated as
|
||||
intensive. If this is not the case, e.g. due to histogramming
|
||||
|
|
|
@ -154,13 +154,13 @@ of type *angletype*\ , with parameters assigned by the corresponding
|
|||
.. note::
|
||||
|
||||
LAMMPS stores and maintains a data structure with a list of the
|
||||
1st, 2nd, and 3rd neighbors of each atom (within the bond topology of
|
||||
first, second, and third neighbors of each atom (within the bond topology of
|
||||
the system) for use in weighting pairwise interactions for bonded
|
||||
atoms. Note that adding a single bond always adds a new 1st neighbor
|
||||
but may also induce \*many\* new 2nd and 3rd neighbors, depending on the
|
||||
atoms. Note that adding a single bond always adds a new first neighbor
|
||||
but may also induce \*many\* new second and third neighbors, depending on the
|
||||
molecular topology of your system. The "extra special per atom"
|
||||
parameter must typically be set to allow for the new maximum total
|
||||
size (1st + 2nd + 3rd neighbors) of this per-atom list. There are 2
|
||||
size (first + second + third neighbors) of this per-atom list. There are 2
|
||||
ways to do this. See the :doc:`read_data <read_data>` or
|
||||
:doc:`create_box <create_box>` commands for details.
|
||||
|
||||
|
@ -172,12 +172,12 @@ of type *angletype*\ , with parameters assigned by the corresponding
|
|||
considered for pairwise interactions, using the weighting rules set by
|
||||
the :doc:`special_bonds <special_bonds>` command. Consider a new bond
|
||||
created between atoms I,J. If J has a bonded neighbor K, then K
|
||||
becomes a 2nd neighbor of I. Even if the *atype* keyword is not used
|
||||
becomes a second neighbor of I. Even if the *atype* keyword is not used
|
||||
to create angle I-J-K, the pairwise interaction between I and K will
|
||||
be potentially turned off or weighted by the 1-3 weighting specified
|
||||
by the :doc:`special_bonds <special_bonds>` command. This is the case
|
||||
even if the "angle yes" option was used with that command. The same
|
||||
is true for 3rd neighbors (1-4 interactions), the *dtype* keyword, and
|
||||
is true for third neighbors (1-4 interactions), the *dtype* keyword, and
|
||||
the "dihedral yes" option used with the
|
||||
:doc:`special_bonds <special_bonds>` command.
|
||||
|
||||
|
|
|
@ -371,7 +371,7 @@ the meaning of the xy,xz,yz tilt factors.
|
|||
|
||||
The *scaleyz yes* and *scalexz yes* keyword/value pairs can not be used
|
||||
for 2D simulations. *scaleyz yes*\ , *scalexz yes*\ , and *scalexy yes* options
|
||||
can only be used if the 2nd dimension in the keyword is periodic,
|
||||
can only be used if the second dimension in the keyword is periodic,
|
||||
and if the tilt factor is not coupled to the barostat via keywords
|
||||
*tri*\ , *yz*\ , *xz*\ , and *xy*\ .
|
||||
|
||||
|
|
|
@ -66,7 +66,7 @@ in the body of the data file like this with N lines:
|
|||
N 3 314 315 317 318 330
|
||||
|
||||
The first column is an index from 1 to N to enumerate the CMAP terms;
|
||||
it is ignored by LAMMPS. The 2nd column is the "type" of the
|
||||
it is ignored by LAMMPS. The second column is the "type" of the
|
||||
interaction; it is an index into the CMAP force field file. The
|
||||
remaining 5 columns are the atom IDs of the atoms in the two 4-atom
|
||||
dihedrals that overlap to create the CMAP 5-body interaction. Note
|
||||
|
|
|
@ -104,7 +104,7 @@ can be modeled using the :ref:`USER-UEF package <PKG-USER-UEF>` and its :doc:`fi
|
|||
|
||||
For the *x*\ , *y*\ , *z* parameters, the associated dimension cannot be
|
||||
shrink-wrapped. For the *xy*\ , *yz*\ , *xz* parameters, the associated
|
||||
2nd dimension cannot be shrink-wrapped. Dimensions not varied by this
|
||||
second dimension cannot be shrink-wrapped. Dimensions not varied by this
|
||||
command can be periodic or non-periodic. Dimensions corresponding to
|
||||
unspecified parameters can also be controlled by a :doc:`fix npt <fix_nh>` or :doc:`fix nph <fix_nh>` command.
|
||||
|
||||
|
@ -463,7 +463,7 @@ and the final tilt factor at the end of the simulation would be 0.0.
|
|||
During each flip event, atoms are remapped into the new box in the
|
||||
appropriate manner.
|
||||
|
||||
The one exception to this rule is if the 1st dimension in the tilt
|
||||
The one exception to this rule is if the first dimension in the tilt
|
||||
factor (x for xy) is non-periodic. In that case, the limits on the
|
||||
tilt factor are not enforced, since flipping the box in that dimension
|
||||
does not change the atom positions due to non-periodicity. In this
|
||||
|
@ -601,7 +601,7 @@ Restrictions
|
|||
You cannot apply x, y, or z deformations to a dimension that is
|
||||
shrink-wrapped via the :doc:`boundary <boundary>` command.
|
||||
|
||||
You cannot apply xy, yz, or xz deformations to a 2nd dimension (y in
|
||||
You cannot apply xy, yz, or xz deformations to a second dimension (y in
|
||||
xy) that is shrink-wrapped via the :doc:`boundary <boundary>` command.
|
||||
|
||||
Related commands
|
||||
|
|
|
@ -66,7 +66,7 @@ parenthesized comments):
|
|||
...
|
||||
500 10.0 0.500
|
||||
|
||||
A section begins with a non-blank line whose 1st character is not a
|
||||
A section begins with a non-blank line whose first character is not a
|
||||
"#"; blank lines or lines starting with "#" can be used as comments
|
||||
between sections. The first line begins with a keyword which
|
||||
identifies the section. The line can contain additional text, but the
|
||||
|
@ -86,8 +86,8 @@ to match exactly what is in the tabulated file (with effectively no
|
|||
preliminary interpolation), you should set Ntable = Nfile.
|
||||
|
||||
Following a blank line, the next N lines list the tabulated values.
|
||||
On each line, the 1st value is the index from 1 to N, the 2nd value is
|
||||
the internal temperature (in temperature units), the 3rd value is the
|
||||
On each line, the first value is the index from 1 to N, the second value is
|
||||
the internal temperature (in temperature units), the third value is the
|
||||
internal energy (in energy units).
|
||||
|
||||
Note that the internal temperature and internal energy values must
|
||||
|
|
|
@ -106,7 +106,7 @@ parenthesized comments):
|
|||
...
|
||||
500 10.0 0.500 ... 1.0000
|
||||
|
||||
A section begins with a non-blank line whose 1st character is not a
|
||||
A section begins with a non-blank line whose first character is not a
|
||||
"#"; blank lines or lines starting with "#" can be used as comments
|
||||
between sections. The first line begins with a keyword which
|
||||
identifies the section. The line can contain additional text, but the
|
||||
|
@ -121,8 +121,8 @@ What LAMMPS does is a preliminary interpolation by creating splines
|
|||
using the Nfile tabulated values as nodal points.
|
||||
|
||||
Following a blank line, the next N lines list the tabulated values.
|
||||
On each line, the 1st value is the index from 1 to N, the 2nd value is
|
||||
the internal temperature (in temperature units), the 3rd value until
|
||||
On each line, the first value is the index from 1 to N, the second value is
|
||||
the internal temperature (in temperature units), the third value until
|
||||
the *m+3* value are the internal energies of the m species (in energy units).
|
||||
|
||||
Note that all internal temperature and internal energy values must
|
||||
|
|
|
@ -109,20 +109,42 @@ etc.
|
|||
To use this fix during energy minimization, the energy corresponding
|
||||
to the added forces must also be set so as to be consistent with the
|
||||
added forces. Otherwise the minimization will not converge correctly.
|
||||
Correspondingly, the global virial needs to be updated to be use this
|
||||
fix with variable cell calculations (e.g. :doc:`fix box/relax <fix_box_relax>`
|
||||
or :doc:`fix npt <fix_nh>`).
|
||||
|
||||
This can be done from the external driver by calling this public
|
||||
method of the FixExternal class:
|
||||
This can be done from the external driver by calling these public
|
||||
methods of the FixExternal class:
|
||||
|
||||
.. code-block:: c++
|
||||
|
||||
void set_energy(double eng);
|
||||
void set_energy_global(double eng);
|
||||
void set_virial_global(double *virial);
|
||||
|
||||
where eng is the potential energy. Eng is an extensive quantity,
|
||||
where *eng* is the potential energy, and *virial* an array of the 6
|
||||
stress tensor components. Eng is an extensive quantity,
|
||||
meaning it should be the sum over per-atom energies of all affected
|
||||
atoms. It should also be provided in :doc:`energy units <units>`
|
||||
consistent with the simulation. See the details below for how to
|
||||
insure this energy setting is used appropriately in a minimization.
|
||||
|
||||
Additional public methods that the caller can use to update system
|
||||
properties are:
|
||||
|
||||
.. code-block:: c++
|
||||
|
||||
void set_energy_peratom(double *eng);
|
||||
void set_virial_peratom(double **virial);
|
||||
void set_vector_length(int n);
|
||||
void set_vector(int idx, double val);
|
||||
|
||||
These allow to set per-atom energy contributions, per-atom stress
|
||||
contributions, the length and individual values of a global vector
|
||||
of properties that the caller code may want to communicate to LAMMPS
|
||||
(e.g. for use in :doc:`fix ave/time <fix_ave_time>` or in
|
||||
:doc:`equal-style variables <variable>` or for
|
||||
:doc:`custom thermo output <thermo_style>`.
|
||||
|
||||
----------
|
||||
|
||||
**Restart, fix_modify, output, run start/stop, minimize info:**
|
||||
|
|
|
@ -432,7 +432,7 @@ equilibrium liquids can not support a shear stress and that
|
|||
equilibrium solids can not support shear stresses that exceed the
|
||||
yield stress.
|
||||
|
||||
One exception to this rule is if the 1st dimension in the tilt factor
|
||||
One exception to this rule is if the first dimension in the tilt factor
|
||||
(x for xy) is non-periodic. In that case, the limits on the tilt
|
||||
factor are not enforced, since flipping the box in that dimension does
|
||||
not change the atom positions due to non-periodicity. In this mode,
|
||||
|
@ -673,7 +673,7 @@ Restrictions
|
|||
|
||||
*X*\ , *y*\ , *z* cannot be barostatted if the associated dimension is not
|
||||
periodic. *Xy*\ , *xz*\ , and *yz* can only be barostatted if the
|
||||
simulation domain is triclinic and the 2nd dimension in the keyword
|
||||
simulation domain is triclinic and the second dimension in the keyword
|
||||
(\ *y* dimension in *xy*\ ) is periodic. *Z*\ , *xz*\ , and *yz*\ , cannot be
|
||||
barostatted for 2D simulations. The :doc:`create_box <create_box>`,
|
||||
:doc:`read data <read_data>`, and :doc:`read_restart <read_restart>`
|
||||
|
@ -687,7 +687,7 @@ is not allowed in the Nose/Hoover formulation.
|
|||
|
||||
The *scaleyz yes* and *scalexz yes* keyword/value pairs can not be used
|
||||
for 2D simulations. *scaleyz yes*\ , *scalexz yes*\ , and *scalexy yes* options
|
||||
can only be used if the 2nd dimension in the keyword is periodic,
|
||||
can only be used if the second dimension in the keyword is periodic,
|
||||
and if the tilt factor is not coupled to the barostat via keywords
|
||||
*tri*\ , *yz*\ , *xz*\ , and *xy*\ .
|
||||
|
||||
|
@ -710,7 +710,7 @@ Default
|
|||
|
||||
The keyword defaults are tchain = 3, pchain = 3, mtk = yes, tloop = 1,
|
||||
ploop = 1, nreset = 0, drag = 0.0, dilate = all, couple = none,
|
||||
flip = yes, scaleyz = scalexz = scalexy = yes if periodic in 2nd
|
||||
flip = yes, scaleyz = scalexz = scalexy = yes if periodic in second
|
||||
dimension and not coupled to barostat, otherwise no.
|
||||
|
||||
----------
|
||||
|
|
|
@ -354,7 +354,7 @@ equilibrium liquids can not support a shear stress and that
|
|||
equilibrium solids can not support shear stresses that exceed the
|
||||
yield stress.
|
||||
|
||||
One exception to this rule is if the 1st dimension in the tilt factor
|
||||
One exception to this rule is if the first dimension in the tilt factor
|
||||
(x for xy) is non-periodic. In that case, the limits on the tilt
|
||||
factor are not enforced, since flipping the box in that dimension does
|
||||
not change the atom positions due to non-periodicity. In this mode,
|
||||
|
@ -555,7 +555,7 @@ LAMMPS was built with that package. See the :doc:`Build package <Build_package>
|
|||
|
||||
*X*\ , *y*\ , *z* cannot be barostatted if the associated dimension is not
|
||||
periodic. *Xy*\ , *xz*\ , and *yz* can only be barostatted if the
|
||||
simulation domain is triclinic and the 2nd dimension in the keyword
|
||||
simulation domain is triclinic and the second dimension in the keyword
|
||||
(\ *y* dimension in *xy*\ ) is periodic. *Z*\ , *xz*\ , and *yz*\ , cannot be
|
||||
barostatted for 2D simulations. The :doc:`create_box <create_box>`,
|
||||
:doc:`read data <read_data>`, and :doc:`read_restart <read_restart>`
|
||||
|
@ -569,7 +569,7 @@ is not allowed in the Nose/Hoover formulation.
|
|||
|
||||
The *scaleyz yes* and *scalexz yes* keyword/value pairs can not be used
|
||||
for 2D simulations. *scaleyz yes*\ , *scalexz yes*\ , and *scalexy yes* options
|
||||
can only be used if the 2nd dimension in the keyword is periodic,
|
||||
can only be used if the second dimension in the keyword is periodic,
|
||||
and if the tilt factor is not coupled to the barostat via keywords
|
||||
*tri*\ , *yz*\ , *xz*\ , and *xy*\ .
|
||||
|
||||
|
@ -626,7 +626,7 @@ Default
|
|||
The keyword defaults are tchain = 3, pchain = 3, mtk = yes, tloop =
|
||||
ploop = 1, nreset = 0, drag = 0.0, dilate = all, couple = none,
|
||||
cauchystat = no,
|
||||
scaleyz = scalexz = scalexy = yes if periodic in 2nd dimension and
|
||||
scaleyz = scalexz = scalexy = yes if periodic in second dimension and
|
||||
not coupled to barostat, otherwise no.
|
||||
|
||||
----------
|
||||
|
|
|
@ -39,7 +39,7 @@ useful for treating a large biomolecule as a collection of connected,
|
|||
coarse-grained particles.
|
||||
|
||||
The coupling, associated motion constraints, and time integration is
|
||||
performed by the software package `Parallelizable Open source Efficient Multibody Software (POEMS) <poems_>`_ which computes the
|
||||
performed by the software package `Parallelizable Open source Efficient Multibody Software (POEMS)` which computes the
|
||||
constrained rigid-body motion of articulated (jointed) multibody
|
||||
systems :ref:`(Anderson) <Anderson>`. POEMS was written and is distributed
|
||||
by Prof Kurt Anderson, his graduate student Rudranarayan Mukherjee,
|
||||
|
@ -48,8 +48,6 @@ and other members of his group at Rensselaer Polytechnic Institute
|
|||
copyright information on POEMS and other details, please refer to the
|
||||
documents in the poems directory distributed with LAMMPS.
|
||||
|
||||
.. _poems: http://www.rpi.edu/~anderk5/lab
|
||||
|
||||
This fix updates the positions and velocities of the rigid atoms with
|
||||
a constant-energy time integration, so you should not update the same
|
||||
atoms via other fixes (e.g. nve, nvt, npt, temp/rescale, langevin).
|
||||
|
@ -123,7 +121,7 @@ command. This fix is not invoked during :doc:`energy minimization <minimize>`.
|
|||
Restrictions
|
||||
""""""""""""
|
||||
|
||||
This fix is part of the POEMS package. It is only enabled if LAMMPS
|
||||
This fix is part of the :ref:`POEMS <PKG-POEMS>` package. It is only enabled if LAMMPS
|
||||
was built with that package, which also requires the POEMS library be
|
||||
built and linked with LAMMPS. See the :doc:`Build package <Build_package>` doc page for more info.
|
||||
|
||||
|
|
|
@ -158,7 +158,7 @@ atom_style "spin" was declared. See the :doc:`Build package <Build_package>` do
|
|||
The *precession/spin* style can only be declared once. If more
|
||||
than one precession type (for example combining an anisotropy and a Zeeman interactions)
|
||||
has to be declared, they have to be chained in the same command
|
||||
line (as shown in the examples above).
|
||||
line (as shown in the examples above).
|
||||
|
||||
Related commands
|
||||
""""""""""""""""
|
||||
|
|
|
@ -116,7 +116,7 @@ Restrictions
|
|||
""""""""""""
|
||||
|
||||
This fix should not be used with an x,y,z setting that causes a large
|
||||
shift in the system on the 1st timestep, due to the requested COM
|
||||
shift in the system on the first timestep, due to the requested COM
|
||||
being very different from the initial COM. This could cause atoms to
|
||||
be lost, especially in parallel. Instead, use the
|
||||
:doc:`displace_atoms <displace_atoms>` command, which can be used to
|
||||
|
|
|
@ -162,7 +162,7 @@ the restraint is
|
|||
.. math::
|
||||
|
||||
E = 0 \qquad\quad\quad ,if\;r \ge r_0
|
||||
|
||||
|
||||
with the following coefficients:
|
||||
|
||||
* :math:`K` (energy/distance\^2)
|
||||
|
|
|
@ -248,7 +248,7 @@ differences may accumulate to produce divergent trajectories.
|
|||
will be built only at the very first *run* command and maintained for
|
||||
as long as the rigid fix is defined. For example, you might think you
|
||||
could displace the atoms in a body or add a large velocity to each atom
|
||||
in a body to make it move in a desired direction before a 2nd run is
|
||||
in a body to make it move in a desired direction before a second run is
|
||||
performed, using the :doc:`set <set>` or
|
||||
:doc:`displace_atoms <displace_atoms>` or :doc:`velocity <velocity>`
|
||||
commands. But these commands will not affect the internal attributes
|
||||
|
@ -727,7 +727,7 @@ In all case, the rigid bodies and non-rigid particles both contribute
|
|||
to the global pressure and the box is scaled the same by any of the
|
||||
barostatting fixes.
|
||||
|
||||
You could even use the 2nd and 3rd options for a non-hybrid simulation
|
||||
You could even use the second and third options for a non-hybrid simulation
|
||||
consisting of only rigid bodies, assuming you give :doc:`fix npt <fix_nh>` an empty group, though it's an odd thing to do. The
|
||||
barostatting fixes (:doc:`fix npt <fix_nh>` and :doc:`fix press/berensen <fix_press_berendsen>`) will monitor the pressure
|
||||
and change the box dimensions, but not time integrate any particles.
|
||||
|
|
|
@ -108,7 +108,7 @@ internal energy and extrapolated velocity are also updated.
|
|||
will be built only at the very first *run* command and maintained for
|
||||
as long as the rigid fix is defined. For example, you might think you
|
||||
could displace the particles in a body or add a large velocity to each particle
|
||||
in a body to make it move in a desired direction before a 2nd run is
|
||||
in a body to make it move in a desired direction before a second run is
|
||||
performed, using the :doc:`set <set>` or
|
||||
:doc:`displace_atoms <displace_atoms>` or :doc:`velocity <velocity>`
|
||||
commands. But these commands will not affect the internal attributes
|
||||
|
|
|
@ -18,7 +18,7 @@ Syntax
|
|||
* file = filename containing the reaction kinetic equations and Arrhenius parameters
|
||||
* localTemp = *none,lucy* = no local temperature averaging or local temperature defined through Lucy weighting function
|
||||
* matrix = *sparse, dense* format for the stoichiometric matrix
|
||||
* solver = *lammps_rk4,rkf45* = rk4 is an explicit 4th order Runge-Kutta method; rkf45 is an adaptive 4th-order Runge-Kutta-Fehlberg method
|
||||
* solver = *lammps_rk4,rkf45* = rk4 is an explicit fourth order Runge-Kutta method; rkf45 is an adaptive fourth-order Runge-Kutta-Fehlberg method
|
||||
* minSteps = # of steps for rk4 solver or minimum # of steps for rkf45 (rk4 or rkf45)
|
||||
* maxSteps = maximum number of steps for the rkf45 solver (rkf45 only)
|
||||
* relTol = relative tolerance for the rkf45 solver (rkf45 only)
|
||||
|
@ -61,9 +61,9 @@ of *m* ordinary differential equations (ODEs) that describe the change
|
|||
in concentration of a given species as a function of time are then
|
||||
constructed based on the *n* reaction rate equations.
|
||||
|
||||
The ODE systems are solved over the full DPD timestep *dt* using either a 4th
|
||||
The ODE systems are solved over the full DPD timestep *dt* using either a fourth
|
||||
order Runge-Kutta *rk4* method with a fixed step-size *h*\ , specified
|
||||
by the *lammps_rk4* keyword, or a 4th order Runge-Kutta-Fehlberg (rkf45) method
|
||||
by the *lammps_rk4* keyword, or a fourth order Runge-Kutta-Fehlberg (rkf45) method
|
||||
with an adaptive step-size for *h*\ . The number of ODE steps per DPD timestep
|
||||
for the rk4 method is optionally specified immediately after the rk4
|
||||
keyword. The ODE step-size is set as *dt/num_steps*. Smaller
|
||||
|
@ -76,7 +76,7 @@ can be specified by the user or estimated internally. It is recommended that the
|
|||
specify *h0* since this will generally reduced the number of ODE integration steps
|
||||
required. *h0* is defined as *dt / min_steps* if min_steps >= 1. If min_steps == 0,
|
||||
*h0* is estimated such that an explicit Euler method would likely produce
|
||||
an acceptable solution. This is generally overly conservative for the 4th-order
|
||||
an acceptable solution. This is generally overly conservative for the fourth-order
|
||||
method and users are advised to specify *h0* as some fraction of the DPD timestep.
|
||||
For small DPD timesteps, only one step may be necessary depending upon the tolerances.
|
||||
Note that more than min_steps ODE steps may be taken depending upon the ODE stiffness
|
||||
|
@ -172,7 +172,7 @@ parenthesized comments):
|
|||
...
|
||||
1.0 no + 1.0 co = 0.5 n2 + 1.0 co2 1.66E+06 0.0 0.69
|
||||
|
||||
A section begins with a non-blank line whose 1st character is not a
|
||||
A section begins with a non-blank line whose first character is not a
|
||||
"#"; blank lines or lines starting with "#" can be used as comments
|
||||
between sections.
|
||||
|
||||
|
|
|
@ -45,7 +45,7 @@ Description
|
|||
"""""""""""
|
||||
|
||||
Time average computed intensities from :doc:`compute saed <compute_saed>` and
|
||||
write output to a file in the 3rd generation vtk image data format for
|
||||
write output to a file in the third generation vtk image data format for
|
||||
visualization directly in parallelized visualization software packages
|
||||
like ParaView and VisIt. Note that if no time averaging is done, this
|
||||
command can be used as a convenient way to simply output diffraction
|
||||
|
@ -92,7 +92,7 @@ averaging is done; values are simply generated on timesteps
|
|||
|
||||
----------
|
||||
|
||||
The output for fix ave/time/saed is a file written with the 3rd generation
|
||||
The output for fix ave/time/saed is a file written with the third generation
|
||||
vtk image data formatting. The filename assigned by the *file* keyword is
|
||||
appended with _N.vtk where N is an index (0,1,2...) to account for multiple
|
||||
diffraction intensity outputs.
|
||||
|
@ -156,7 +156,7 @@ running or windowed average.
|
|||
|
||||
The *file* keyword allows a filename to be specified. Every *Nfreq*
|
||||
steps, the vector of saed intensity data is written to a new file using
|
||||
the 3rd generation vtk format. The base of each file is assigned by
|
||||
the third generation vtk format. The base of each file is assigned by
|
||||
the *file* keyword and this string is appended with _N.vtk where N is
|
||||
an index (0,1,2...) to account for situations with multiple diffraction
|
||||
intensity outputs.
|
||||
|
|
|
@ -126,7 +126,7 @@ displacement).
|
|||
|
||||
The force is the total force on the group of atoms by the spring. In
|
||||
the case of the *couple* style, it is the force on the fix group
|
||||
(group-ID) or the negative of the force on the 2nd group (group-ID2).
|
||||
(group-ID) or the negative of the force on the second group (group-ID2).
|
||||
The vector values calculated by this fix are "extensive".
|
||||
|
||||
No parameter of this fix can be used with the *start/stop* keywords of
|
||||
|
|
|
@ -118,7 +118,7 @@ various :doc:`output commands <Howto_output>`. The first 3 quantities
|
|||
in the vector are xyz components of the total force added to the group
|
||||
of atoms by the spring. In the case of the *couple* style, it is the
|
||||
force on the fix group (group-ID) or the negative of the force on the
|
||||
2nd group (group-ID2). The 4th quantity in the vector is the
|
||||
second group (group-ID2). The fourth quantity in the vector is the
|
||||
magnitude of the force added by the spring, as a positive value if
|
||||
(r-R0) > 0 and a negative value if (r-R0) < 0. This sign convention
|
||||
can be useful when using the spring force to compute a potential of
|
||||
|
|
|
@ -55,8 +55,8 @@ a .gz suffix). The format of the target file1 is as follows:
|
|||
|
||||
The first 3 lines may or may not be needed, depending on the format of
|
||||
the atoms to follow. If image flags are included with the atoms, the
|
||||
1st 3 lo/hi lines must appear in the file. If image flags are not
|
||||
included, the 1st 3 lines should not appear. The 3 lines contain the
|
||||
first 3 lo/hi lines must appear in the file. If image flags are not
|
||||
included, the first 3 lines should not appear. The 3 lines contain the
|
||||
simulation box dimensions for the atom coordinates, in the same format
|
||||
as in a LAMMPS data file (see the :doc:`read_data <read_data>` command).
|
||||
|
||||
|
|
|
@ -118,7 +118,7 @@ specified atom types, atom IDs, or molecule IDs into the group. These
|
|||
3 styles can use arguments specified in one of two formats.
|
||||
|
||||
The first format is a list of values (types or IDs). For example, the
|
||||
2nd command in the examples above puts all atoms of type 3 or 4 into
|
||||
second command in the examples above puts all atoms of type 3 or 4 into
|
||||
the group named *water*\ . Each entry in the list can be a
|
||||
colon-separated sequence A:B or A:B:C, as in two of the examples
|
||||
above. A "sequence" generates a sequence of values (types or IDs),
|
||||
|
@ -131,9 +131,9 @@ uses an increment of 10 and would thus would add atoms IDs
|
|||
|
||||
The second format is a *logical* followed by one or two values (type
|
||||
or ID). The 7 valid logicals are listed above. All the logicals
|
||||
except <> take a single argument. The 3rd example above adds all
|
||||
except <> take a single argument. The third example above adds all
|
||||
atoms with IDs from 1 to 150 to the group named *sub*\ . The logical <>
|
||||
means "between" and takes 2 arguments. The 4th example above adds all
|
||||
means "between" and takes 2 arguments. The fourth example above adds all
|
||||
atoms belonging to molecules with IDs from 50 to 250 (inclusive) to
|
||||
the group named polyA.
|
||||
|
||||
|
@ -192,7 +192,7 @@ this operation is useful is if the *region* style has been used
|
|||
previously to add atoms to a group that are within a geometric region.
|
||||
If molecules straddle the region boundary, then atoms outside the
|
||||
region that are part of molecules with atoms inside the region will
|
||||
not be in the group. Using the group command a 2nd time with *include
|
||||
not be in the group. Using the group command a second time with *include
|
||||
molecule* will add those atoms that are outside the region to the
|
||||
group.
|
||||
|
||||
|
@ -207,7 +207,7 @@ group.
|
|||
atoms, and P is the number of processors.
|
||||
|
||||
The *subtract* style takes a list of two or more existing group names
|
||||
as arguments. All atoms that belong to the 1st group, but not to any
|
||||
as arguments. All atoms that belong to the first group, but not to any
|
||||
of the other groups are added to the specified group.
|
||||
|
||||
The *union* style takes a list of one or more existing group names as
|
||||
|
|
|
@ -48,7 +48,7 @@ the :doc:`read_data <read_data>` command) are ordered I,J,K,L.
|
|||
the plane of J,K,L, and the bond JK lies in both planes. Similarly for
|
||||
:math:`\chi_{kjli}` and :math:`\chi_{ljik}`.
|
||||
Note that atom J appears in the common bonds (JI, JK, JL) of all 3 X
|
||||
terms. Thus J (the 2nd atom in the quadruplet) is the atom of
|
||||
terms. Thus J (the second atom in the quadruplet) is the atom of
|
||||
symmetry in the 3 :math:`\chi` angles.
|
||||
|
||||
The subscripts on the various :math:`\theta`\ s refer to different
|
||||
|
@ -56,7 +56,7 @@ combinations of 3 atoms (I,J,K,L) used to form a particular angle.
|
|||
E.g. :math:`\theta_{ijl}` is the angle formed by atoms I,J,L with J
|
||||
in the middle. :math:`\theta_1`, :math:`\theta_2`, :math:`\theta_3`
|
||||
are the equilibrium positions of those angles. Again,
|
||||
atom J (the 2nd atom in the quadruplet) is the atom of symmetry in the
|
||||
atom J (the second atom in the quadruplet) is the atom of symmetry in the
|
||||
theta angles, since it is always the center atom.
|
||||
|
||||
Since atom J is the atom of symmetry, normally the bonds J-I, J-K, J-L
|
||||
|
|
|
@ -32,7 +32,7 @@ file read by the :doc:`read_data <read_data>` command or in a restart
|
|||
file.
|
||||
|
||||
N can be specified in one of two ways. An explicit numeric value can
|
||||
be used, as in the 1st example above. Or a wild-card asterisk can be
|
||||
be used, as in the first example above. Or a wild-card asterisk can be
|
||||
used to set the coefficients for multiple improper types. This takes
|
||||
the form "\*" or "\*n" or "n\*" or "m\*n". If N = the number of improper
|
||||
types, then an asterisk with no numeric values means all types from 1
|
||||
|
@ -55,7 +55,7 @@ exact same format as the arguments of the improper_coeff command in an
|
|||
input script, except that wild-card asterisks should not be used since
|
||||
coefficients for all N types must be listed in the file. For example,
|
||||
under the "Improper Coeffs" section of a data file, the line that
|
||||
corresponds to the 1st example above would be listed as
|
||||
corresponds to the first example above would be listed as
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
|
|
|
@ -48,7 +48,7 @@ to other hybrid styles, use the style name (e.g. "harmonic")
|
|||
appropriate to that style. The AngleAngle coeffs for that improper
|
||||
type will then be ignored.
|
||||
|
||||
An improper style of *none* can be specified as the 2nd argument to
|
||||
An improper style of *none* can be specified as the second argument to
|
||||
the improper_coeff command, if you desire to turn off certain improper
|
||||
types.
|
||||
|
||||
|
|
|
@ -60,7 +60,7 @@ of SELF, e.g.
|
|||
|
||||
lmp_g++ -var fname in.script < in.script
|
||||
|
||||
The 2nd argument to the jump command is optional. If specified, it is
|
||||
The second argument to the jump command is optional. If specified, it is
|
||||
treated as a label and the new file is scanned (without executing
|
||||
commands) until the label is found, and commands are executed from
|
||||
that point forward. This can be used to loop over a portion of the
|
||||
|
|
|
@ -163,7 +163,7 @@ The *pppm/dipole/spin* style invokes a particle-particle particle-mesh solver
|
|||
for magnetic dipole-dipole interactions between magnetic spins.
|
||||
|
||||
The *pppm/tip4p* style is identical to the *pppm* style except that it
|
||||
adds a charge at the massless 4th site in each TIP4P water molecule.
|
||||
adds a charge at the massless fourth site in each TIP4P water molecule.
|
||||
It should be used with :doc:`pair styles <pair_style>` with a
|
||||
*tip4p/long* in their style name.
|
||||
|
||||
|
|
|
@ -31,7 +31,7 @@ using the "Masses" keyword. See the :doc:`units <units>` command for
|
|||
what mass units to use.
|
||||
|
||||
The I index can be specified in one of two ways. An explicit numeric
|
||||
value can be used, as in the 1st example above. Or a wild-card
|
||||
value can be used, as in the first example above. Or a wild-card
|
||||
asterisk can be used to set the mass for multiple atom types. This
|
||||
takes the form "\*" or "\*n" or "n\*" or "m\*n". If N = the number of
|
||||
atom types, then an asterisk with no numeric values means all types
|
||||
|
@ -44,7 +44,7 @@ A line in a :doc:`data file <read_data>` that follows the "Masses"
|
|||
keyword specifies mass using the same format as the arguments of the
|
||||
mass command in an input script, except that no wild-card asterisk can
|
||||
be used. For example, under the "Masses" section of a data file, the
|
||||
line that corresponds to the 1st example above would be listed as
|
||||
line that corresponds to the first example above would be listed as
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
|
|
|
@ -178,7 +178,7 @@ processing the rest of its input script after client/server
|
|||
communication terminates.
|
||||
|
||||
If both codes cooperate in this manner, a new round of client/server
|
||||
messaging can be initiated after termination by re-using a 2nd message
|
||||
messaging can be initiated after termination by re-using a second message
|
||||
command in your LAMMPS input script, followed by a new fix client or
|
||||
server command, followed by another message quit command (if LAMMPS is
|
||||
the client). As an example, this can be performed in a loop to use a
|
||||
|
|
|
@ -95,7 +95,7 @@ coordinates:
|
|||
|
||||
where the first term is the sum of all non-bonded :doc:`pairwise
|
||||
interactions <pair_style>` including :doc:`long-range Coulombic
|
||||
interactions <kspace_style>`, the 2nd through 5th terms are :doc:`bond
|
||||
interactions <kspace_style>`, the second through fifth terms are :doc:`bond
|
||||
<bond_style>`, :doc:`angle <angle_style>`, :doc:`dihedral
|
||||
<dihedral_style>`, and :doc:`improper <improper_style>` interactions
|
||||
respectively, and the last term is energy due to :doc:`fixes <fix>`
|
||||
|
|
|
@ -458,7 +458,7 @@ If flag = 0, no a,b,c values are listed on the line, just the
|
|||
If flag = 1, a,b,c are listed, where a = bondtype of the bond between
|
||||
the central atom and the first non-central atom (value b in the Shake
|
||||
Atoms section), b = bondtype of the bond between the central atom and
|
||||
the 2nd non-central atom (value c in the Shake Atoms section), and c =
|
||||
the second non-central atom (value c in the Shake Atoms section), and c =
|
||||
the angle type (1 to Nangletypes) of the angle between the 3 atoms.
|
||||
|
||||
If flag = 2, only a is listed, where a = bondtype of the bond between
|
||||
|
@ -467,13 +467,13 @@ the 2 atoms in the cluster.
|
|||
If flag = 3, a,b are listed, where a = bondtype of the bond between
|
||||
the central atom and the first non-central atom (value b in the Shake
|
||||
Atoms section), and b = bondtype of the bond between the central atom
|
||||
and the 2nd non-central atom (value c in the Shake Atoms section).
|
||||
and the second non-central atom (value c in the Shake Atoms section).
|
||||
|
||||
If flag = 4, a,b,c are listed, where a = bondtype of the bond between
|
||||
the central atom and the first non-central atom (value b in the Shake
|
||||
Atoms section), b = bondtype of the bond between the central atom and
|
||||
the 2nd non-central atom (value c in the Shake Atoms section), and c =
|
||||
bondtype of the bond between the central atom and the 3rd non-central
|
||||
the second non-central atom (value c in the Shake Atoms section), and c =
|
||||
bondtype of the bond between the central atom and the third non-central
|
||||
atom (value d in the Shake Atoms section).
|
||||
|
||||
See the :doc:`fix shake <fix_shake>` doc page for a further description
|
||||
|
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue