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

Merge branch 'master' into bond-style-special

Browse Source
This commit is contained in:
Axel Kohlmeyer
2020-08-11 13:55:24 -04:00
parent 46021a57a6 2775b93789
commit 03ca86ee84
6914 changed files with 1387021 additions and 2277352 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
doc/src/.gitignore vendored
View File

@ -1,3 +1 @@
/Eqs
/JPG
/false_positives.txt

2
doc/src/2001/README.html
View File

@ -10,7 +10,7 @@ LAMMPS</H2>
LAMMPS = Large-scale Atomic/Molecular Massively Parallel Simulator</P>
<P>
This is the documentation for the LAMMPS 2001 version, written in F90,
which has been superceded by more current versions. See the <A
which has been superseded by more current versions. See the <A
HREF="http://www.cs.sandia.gov/~sjplimp/lammps.html">LAMMPS WWW
Site</A> for more information.
<P>

2
doc/src/2001/basics.html
View File

@ -47,7 +47,7 @@ directories: </P>
<P>
The src directory contains the F90 and C source files for LAMMPS as
well as several sample Makefiles for different machines. To make LAMMPS
for a specfic machine, you simply type</P>
for a specific machine, you simply type</P>
<P>
make machine</P>
<P>

6
doc/src/2001/input_commands.html
View File

@ -1079,7 +1079,7 @@ for style aveforce, average force on the group of fixed atoms is computed,
to new total value -> has effect of applying same force to entire group
of atoms
thermostatting constraints (rescale, hoover/drag, langevin) cannot be used in
conjuction with global &quot;temp control&quot;, since they conflict and will
conjunction with global &quot;temp control&quot;, since they conflict and will
cause atom velocities to be reset twice
thermostatting constraints (rescale, hoover/drag, langevin) cannot be used
when performing a minimization
@ -1089,7 +1089,7 @@ meaning of rescale and Langevin thermostatting coefficients is same as in
&quot;temp control&quot; command
for rescale style, it can be used as a coarse temperature rescaler,
for example &quot;rescale 200.0 300.0 100 10.0 1.0&quot; will ramp the temperature
up during the simulation, resetting it to the target temperatue as needed
up during the simulation, resetting it to the target temperature as needed
for rescale style, it can be used to create an instantaneous
drag force that slowly rescales the temperature without oscillation,
for example &quot;rescale 300.0 300.0 1 0.0 0.0001&quot; will force (or keep)
@ -1952,7 +1952,7 @@ for rescale style, the amount of rescaling is contfolled by the fractional
to halfway between the current and target temperature
for rescale style, it can be used as a coarse temperature rescaler,
for example "rescale 200.0 300.0 100 10.0 1.0" will ramp the temperature
up during the simulation, resetting it to the target temperatue as needed
up during the simulation, resetting it to the target temperature as needed
for rescale style, it can be used to create an instantaneous
drag force that slowly rescales the temperature without oscillation,
for example "rescale 300.0 300.0 1 0.0 0.0001" will force (or keep)

2
doc/src/99/README.html
View File

@ -10,7 +10,7 @@ LAMMPS</H2>
LAMMPS = Large-scale Atomic/Molecular Massively Parallel Simulator</P>
<P>
This is the documentation for the LAMMPS 99 version, written in F77,
which has been superceded by more current versions. See the <A
which has been superseded by more current versions. See the <A
HREF="http://www.cs.sandia.gov/~sjplimp/lammps.html">LAMMPS WWW
Site</A> for more information.
<P>

2
doc/src/99/basics.html
View File

@ -45,7 +45,7 @@ directories: </P>
<P>
The src directory contains the F77 and C source files for LAMMPS as
well as several sample Makefiles for different machines. To make LAMMPS
for a specfic machine, you simply type</P>
for a specific machine, you simply type</P>
<P>
make machine</P>
<P>

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

4
doc/src/99/input_commands.html
View File

@ -430,7 +430,7 @@ accuracy criterion effectively determines how many k-space vectors are used
for PPPM, accuracy criterion determines mesh spacing (see &quot;particle mesh&quot;
command)
for PPPM, must be running on power-of-2 number of processors for FFTs
must use periodic boundary conditions in conjuction with Ewald and PPPM
must use periodic boundary conditions in conjunction with Ewald and PPPM
cannot use any styles other than none with nonbond style = lj/shift or
nonbond style = soft
Coulomb style = smooth should be used with nonbond style = lj/switch,
@ -772,7 +772,7 @@ for style aveforce, average force on the group of fixed atoms is computed,
to new total value -&gt; has effect of applying same force to entire group
of atoms
thermostatting constraints (rescale, langevin, nose/hoover) cannot be used in
conjuction with global &quot;temp control&quot;, since they conflict and will
conjunction with global &quot;temp control&quot;, since they conflict and will
cause atom velocities to be reset twice
if multiple Langevin constraints are specified the Marsaglia RNG will
only use the last RNG seed specified for initialization

18
doc/src/Build.rst
View File

@ -1,13 +1,14 @@
Build LAMMPS
************
LAMMPS can be built as an executable or library from source code via
either traditional makefiles (which may require manual editing)
for use with GNU make or gmake, or a build environment generated by CMake
(Unix Makefiles, Xcode, Visual Studio, KDevelop or more). As an
alternative you can download a package with pre-built executables
as described on the :doc:`Install <Install>` doc page.
LAMMPS is built as a library and an executable from source code using
either traditional makefiles for use with GNU make (which may require
manual editing), or using a build environment generated by CMake (Unix
Makefiles, Ninja, Xcode, Visual Studio, KDevelop, CodeBlocks and more).
As an alternative you can download a package with pre-built executables
or automated build trees as described on the :doc:`Install <Install>`
doc page.
.. toctree::
:maxdepth: 1
@ -21,8 +22,3 @@ as described on the :doc:`Install <Install>` doc page.
Build_extras
Build_windows
Build_development
.. _lws: http://lammps.sandia.gov
.. _ld: Manual.html
.. _lc: Commands_all.html

565
doc/src/Build_basics.rst
View File

@ -6,159 +6,206 @@ CMake and make:
* :ref:`Serial vs parallel build <serial>`
* :ref:`Choice of compiler and compile/link options <compile>`
* :ref:`Build LAMMPS as an executable or a library <exe>`
* :ref:`Build the LAMMPS executable and library <exe>`
* :ref:`Including and removing debug support <debug>`
* :ref:`Build the LAMMPS documentation <doc>`
* :ref:`Install LAMMPS after a build <install>`
----------
.. _serial:
Serial vs parallel build
-------------------------------------
------------------------
LAMMPS can be built to run in parallel using the ubiquitous `MPI (message-passing interface) <https://en.wikipedia.org/wiki/Message_Passing_Interface>`_
library. Or it can built to run on a single processor (serial)
without MPI. It can also be built with support for OpenMP threading
(see more discussion below).
LAMMPS is written to use the ubiquitous `MPI (Message Passing Interface)
<https://en.wikipedia.org/wiki/Message_Passing_Interface>`_ library API
for distributed memory parallel computation. You need to have such a
library installed for building and running LAMMPS in parallel using a
domain decomposition parallelization. It is compatible with the MPI
standard version 2.x and later. LAMMPS can also be built into a
"serial" executable for use with a single processor using the bundled
MPI STUBS library.
**CMake variables**\ :
Independent of the distributed memory MPI parallelization, parts of
LAMMPS are also written with support for shared memory parallelization
using the `OpenMP <https://en.wikipedia.org/wiki/OpenMP>`_ threading
standard. A more detailed discussion of that is below.
**CMake build**\ :
.. parsed-literal::
.. code-block:: bash
-D BUILD_MPI=value # yes or no, default is yes if CMake finds MPI, else no
-D BUILD_OMP=value # yes or no (default)
-D BUILD_OMP=value # yes or no, default is yes if a compatible compiler is detected
-D LAMMPS_MACHINE=name # name = mpi, serial, mybox, titan, laptop, etc
# no default value
The executable created by CMake (after running make) is lmp\_name. If
the LAMMPS\_MACHINE variable is not specified, the executable is just
lmp. Using BUILD\_MPI=no will produce a serial executable.
The executable created by CMake (after running make) is named ``lmp`` unless
the ``LAMMPS_MACHINE`` option is set. When setting ``LAMMPS_MACHINE=name``
the executable will be called ``lmp_name``. Using ``BUILD_MPI=no`` will
enforce building a serial executable using the MPI STUBS library.
**Traditional make**\ :
The build with traditional makefiles has to be done inside the source folder ``src``.
.. parsed-literal::
.. code-block:: bash
cd lammps/src
make mpi # parallel build, produces lmp_mpi using Makefile.mpi
make serial # serial build, produces lmp_serial using Makefile/serial
make mybox # uses Makefile.mybox to produce lmp_mybox
make mybox # uses Makefile.mybox to produce lmp_mybox
Serial build (see src/MAKE/Makefile.serial):
Any ``make machine`` command will look up the make settings from a file
``Makefile.machine`` in the folder ``src/MAKE`` or one of its
sub-directories ``MINE``, ``MACHINES``, or ``OPTIONS``, create a folder
``Obj_machine`` with all objects and generated files and an executable
called ``lmp_machine``\ . The standard parallel build with ``make mpi``
assumes a standard MPI installation with MPI compiler wrappers where all
necessary compiler and linker flags to get access and link with the
suitable MPI headers and libraries are set by the wrapper programs. For
other cases or the serial build, you have to adjust the make file
variables ``MPI_INC``, ``MPI_PATH``, ``MPI_LIB`` as well as ``CC`` and
``LINK``\ . To enable OpenMP threading usually a compiler specific flag
needs to be added to the compile and link commands. For the GNU
compilers, this is ``-fopenmp``\ , which can be added to the ``CC`` and
``LINK`` makefile variables.
For the serial build the following make variables are set (see src/MAKE/Makefile.serial):
.. parsed-literal::
.. code-block:: make
CC = g++
LINK = g++
MPI_INC = -I../STUBS
MPI_PATH = -L../STUBS
MPI_LIB = -lmpi_stubs
For a parallel build, if MPI is installed on your system in the usual
place (e.g. under /usr/local), you do not need to specify the 3
variables MPI\_INC, MPI\_PATH, MPI\_LIB. The MPI wrapper on the compiler
(e.g. mpicxx, mpiCC) knows where to find the needed include and
library files. Failing this, these 3 variables can be used to specify
where the mpi.h file (MPI\_INC), and the MPI library files (MPI\_PATH)
are found, and the name of the library files (MPI\_LIB).
You also need to build the STUBS library for your platform before making
LAMMPS itself. A ``make serial`` build does this for you automatically,
otherwise, type ``make mpi-stubs`` from the src directory, or ``make``
from the ``src/STUBS`` dir. If the build fails, you may need to edit
the ``STUBS/Makefile`` for your platform. The stubs library does not
provide MPI/IO functions required by some LAMMPS packages,
e.g. ``MPIIO`` or ``USER-LB``, and thus is not compatible with those
packages.
For a serial build, you need to specify the 3 variables, as shown
above.
.. note::
For a serial LAMMPS build, use the dummy MPI library provided in
src/STUBS. You also need to build the STUBS library for your platform
before making LAMMPS itself. A "make serial" build does this for.
Otherwise, type "make mpi-stubs" from the src directory, or "make"
from the src/STUBS dir. If the build fails, you will need to edit the
STUBS/Makefile for your platform.
The file ``src/STUBS/mpi.c`` provides a CPU timer function called
``MPI_Wtime()`` that calls ``gettimeofday()``. If your operating system
does not support ``gettimeofday()``, you will need to insert code to
call another timer. Note that the ANSI-standard function ``clock()``
rolls over after an hour or so, and is therefore insufficient for
timing long LAMMPS simulations.
The file STUBS/mpi.c provides a CPU timer function called MPI\_Wtime()
that calls gettimeofday() . If your system doesn't support
gettimeofday() , you'll need to insert code to call another timer.
Note that the ANSI-standard function clock() rolls over after an hour
or so, and is therefore insufficient for timing long LAMMPS
simulations.
**MPI and OpenMP support info**\ :
**CMake and make info**\ :
If you are installing MPI yourself to build a parallel LAMMPS
executable, we recommend either MPICH or OpenMPI which are regularly
used and tested with LAMMPS by the LAMMPS developers. MPICH can be
downloaded from the `MPICH home page <https://www.mpich.org>`_ and
OpenMPI can be downloaded correspondingly from the `OpenMPI home page
<https://www.open-mpi.org>`_. Other MPI packages should also work. No
specific vendor provided and standard compliant MPI library is currently
known to be incompatible with LAMMPS. If you are running on a large
parallel machine, your system admins or the vendor should have already
installed a version of MPI, which is likely to be faster than a
self-installed MPICH or OpenMPI, so you should study the provided
documentation to find out how to build and link with it.
If you are installing MPI yourself, we recommend MPICH2 from Argonne
National Laboratory or OpenMPI. MPICH can be downloaded from the
`Argonne MPI site <http://www.mcs.anl.gov/research/projects/mpich2/>`_.
OpenMPI can be downloaded from the `OpenMPI site <http://www.open-mpi.org>`_. Other MPI packages should also work.
If you are running on a large parallel machine, your system admins or
the vendor should have already installed a version of MPI, which is
likely to be faster than a self-installed MPICH or OpenMPI, so find
out how to build and link with it.
The majority of OpenMP (threading) support in LAMMPS is provided by the
``USER-OMP`` package; see the :doc:`Speed omp <Speed_omp>` doc page for
details. The ``USER-INTEL`` package also includes OpenMP threading (it
is compatible with ``USER-OMP`` and will usually fall back on styles
from that package, if a ``USER-INTEL`` does not exist) and adds
vectorization support when compiled with compatible compilers, in
particular the Intel compilers on top of OpenMP. Also, the ``KOKKOS``
package can be compiled to include OpenMP threading.
The majority of OpenMP (threading) support in LAMMPS is provided by
the USER-OMP package; see the :doc:`Speed omp <Speed_omp>` doc page for
details. The USER-INTEL package also provides OpenMP support (it is
compatible with USER-OMP) and adds vectorization support when compiled
with the Intel compilers on top of that. Also, the KOKKOS package can
be compiled for using OpenMP threading.
In addition, there are a few commands in LAMMPS that have native OpenMP
support included as well. These are commands in the ``MPIIO``,
``SNAP``, ``USER-DIFFRACTION``, and ``USER-DPD`` packages. In addition
some packages support OpenMP threading indirectly through the libraries
they interface to: e.g. ``LATTE``, ``KSPACE``, and ``USER-COLVARS``.
See the :doc:`Packages details <Packages_details>` doc page for more
info on these packages and the doc pages for their respective commands
for OpenMP threading info.
However, there are a few commands in LAMMPS that have native OpenMP
support. These are commands in the MPIIO, SNAP, USER-DIFFRACTION, and
USER-DPD packages. In addition some packages support OpenMP threading
indirectly through the libraries they interface to: e.g. LATTE and
USER-COLVARS. See the :doc:`Packages details <Packages_details>` doc
page for more info on these packages and the doc pages for their
respective commands for OpenMP threading info.
For CMake, if you use BUILD\_OMP=yes, you can use these packages and
turn on their native OpenMP support and turn on their native OpenMP
support at run time, by setting the OMP\_NUM\_THREADS environment
For CMake, if you use ``BUILD_OMP=yes``, you can use these packages
and turn on their native OpenMP support and turn on their native OpenMP
support at run time, by setting the ``OMP_NUM_THREADS`` environment
variable before you launch LAMMPS.
For building via conventional make, the CCFLAGS and LINKFLAGS
For building via conventional make, the ``CCFLAGS`` and ``LINKFLAGS``
variables in Makefile.machine need to include the compiler flag that
enables OpenMP. For GNU compilers it is -fopenmp. For (recent) Intel
compilers it is -qopenmp. If you are using a different compiler,
enables OpenMP. For GNU compilers it is ``-fopenmp``\ . For (recent) Intel
compilers it is ``-qopenmp``\ . If you are using a different compiler,
please refer to its documentation.
.. _default-none-issues:
**OpenMP Compiler compatibility info**\ :
Some compilers do not fully support the 'default(none)' directive
and others (e.g. GCC version 9 and beyond) may implement OpenMP 4.0
semantics, which are incompatible with the OpenMP 3.1 directives used
in LAMMPS (for maximal compatibility with compiler versions in use).
In those case, all 'default(none)' directives (which aid in detecting
incorrect and unwanted sharing) can be replaced with 'default(shared)'
while dropping all 'shared()' directives. The script
'src/USER-OMP/hack\_openmp\_for\_pgi\_gcc9.sh' can be used to automate
this conversion.
**OpenMP Compiler compatibility info**\ :
Some compilers do not fully support the ``default(none)`` directive
and others (e.g. GCC version 9 and beyond, Clang version 10 and later)
may implement strict OpenMP 4.0 and later semantics, which are incompatible
with the OpenMP 3.1 semantics used in LAMMPS for maximal compatibility
with compiler versions in use. If compilation with OpenMP enabled fails
because of your compiler requiring strict OpenMP 4.0 semantic, you can
change the behavior by adding ``-D LAMMPS_OMP_COMPAT=4`` to the ``LMP_INC``
variable in your makefile, or add it to the command line while configuring
with CMake. CMake will detect the suitable setting for the GNU, Clang,
and Intel compilers.
----------
.. _compile:
Choice of compiler and compile/link options
---------------------------------------------------------
The choice of compiler and compiler flags can be important for
performance. Vendor compilers can produce faster code than
open-source compilers like GNU. On boxes with Intel CPUs, we suggest
trying the `Intel C++ compiler <intel_>`_.
The choice of compiler and compiler flags can be important for maximum
performance. Vendor provided compilers for a specific hardware can
produce faster code than open-source compilers like the GNU compilers.
On the most common x86 hardware most popular C++ compilers are quite
similar in performance of C/C++ code at high optimization levels. When
using the ``USER-INTEL`` package, there is a distinct advantage in using
the `Intel C++ compiler <intel_>`_ due to much improved vectorization
through SSE and AVX instructions on compatible hardware as the source
code includes changes and Intel compiler specific directives to enable
high degrees of vectorization. This may change over time as equivalent
vectorization directives are included into OpenMP standard revisions and
other compilers adopt them.
.. _intel: https://software.intel.com/en-us/intel-compilers
On parallel clusters or supercomputers which use "environment modules"
for their compile/link environments, you can often access different
compilers by simply loading the appropriate module before building
LAMMPS.
**CMake build**\ :
On parallel clusters or supercomputers which use "modules" for their
compile/link environments, you can often access different compilers by
simply loading the appropriate module before building LAMMPS.
By default CMake will use a compiler it finds according to internal
preferences and it will add optimization flags appropriate to that
compiler and any :doc:`accelerator packages <Speed_packages>` you have
included in the build.
**CMake variables**\ :
You can tell CMake to look for a specific compiler with setting CMake
variables (listed below) during configuration. For a few common
choices, there are also presets in the ``cmake/presets`` folder. For
convenience, there is a ``CMAKE_TUNE_FLAGS`` variable that can be set to
apply global compiler options (applied to compilation only), to be used
for adding compiler or host specific optimization flags in addition to
the "flags" variables listed below. You may also specify the
corresponding ``CMAKE_*_FLAGS`` variables individually, if you want to
experiment with alternate optimization flags. You should specify all 3
compilers, so that the (few) LAMMPS source files written in C or Fortran
are built with a compiler consistent with the one used for the C++
files:
.. parsed-literal::
.. code-block:: bash
-D CMAKE_CXX_COMPILER=name # name of C++ compiler
-D CMAKE_C_COMPILER=name # name of C compiler
@ -168,77 +215,92 @@ simply loading the appropriate module before building LAMMPS.
-D CMAKE_C_FLAGS=string # flags to use with C compiler
-D CMAKE_Fortran_FLAGS=string # flags to use with Fortran compiler
By default CMake will use a compiler it finds and it will add
optimization flags appropriate to that compiler and any :doc:`accelerator packages <Speed_packages>` you have included in the build.
A few example command lines are:
You can tell CMake to look for a specific compiler with these variable
settings. Likewise you can specify the FLAGS variables if you want to
experiment with alternate optimization flags. You should specify all
3 compilers, so that the small number of LAMMPS source files written
in C or Fortran are built with a compiler consistent with the one used
for all the C++ files:
.. code-block:: bash
.. parsed-literal::
Building with GNU Compilers:
# Building with GNU Compilers:
cmake ../cmake -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DCMAKE_Fortran_COMPILER=gfortran
Building with Intel Compilers:
# Building with Intel Compilers:
cmake ../cmake -DCMAKE_C_COMPILER=icc -DCMAKE_CXX_COMPILER=icpc -DCMAKE_Fortran_COMPILER=ifort
Building with LLVM/Clang Compilers:
# Building with LLVM/Clang Compilers:
cmake ../cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_Fortran_COMPILER=flang
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
In addition you can set ``CMAKE_TUNE_FLAGS`` to specifically add
compiler flags to tune for optimal performance on given hosts. By
default this variable is empty.
.. note::
When the cmake command completes, it prints info to the screen
as to which compilers it is using, and what flags will be used in the
compilation. Note that if the top-level compiler is mpicxx, it is
simply a wrapper on a real compiler. The underlying compiler info is
what will be listed in the CMake output. You should check to insure
you are using the compiler and optimization flags are the ones you
want.
When the cmake command completes, it prints a summary to the screen
which compilers it is using and what flags and settings will be used
for the compilation. Note that if the top-level compiler is mpicxx,
it is simply a wrapper on a real compiler. The underlying compiler
info is what CMake will try to determine and report. You should check
to confirm you are using the compiler and optimization flags you want.
**Makefile.machine settings**\ :
**Makefile.machine settings for traditional make**\ :
Parallel build (see src/MAKE/Makefile.mpi):
The "compiler/linker settings" section of a Makefile.machine lists
compiler and linker settings for your C++ compiler, including
optimization flags. For a parallel build it is recommended to use
``mpicxx`` or ``mpiCC``, since these compiler wrappers will include a
variety of settings appropriate for your MPI installation and thus
avoiding the guesswork of finding the right flags.
Parallel build (see ``src/MAKE/Makefile.mpi``):
.. parsed-literal::
.. code-block:: bash
CC = mpicxx
CCFLAGS = -g -O3
LINK = mpicxx
LINKFLAGS = -g -O
Serial build (see src/MAKE/Makefile.serial):
Serial build with GNU gcc (see ``src/MAKE/Makefile.serial``):
.. parsed-literal::
.. code-block:: make
CC = g++
CCFLAGS = -g -O3
LINK = g++
LINKFLAGS = -g -O
The "compiler/linker settings" section of a Makefile.machine lists
compiler and linker settings for your C++ compiler, including
optimization flags. You should always use mpicxx or mpiCC for
a parallel build, since these compiler wrappers will include
a variety of settings appropriate for your MPI installation.
.. note::
If you build LAMMPS with any :doc:`accelerator packages <Speed_packages>` included, they have specific
optimization flags that are either required or recommended for optimal
performance. You need to include these in the CCFLAGS and LINKFLAGS
settings above. For details, see the individual package doc pages
listed on the :doc:`Speed packages <Speed_packages>` doc page. Or
examine these files in the src/MAKE/OPTIONS directory. They
correspond to each of the 5 accelerator packages and their hardware
variants:
If compilation stops with a message like the following:
.. code-block::
.. parsed-literal::
g++ -g -O3 -DLAMMPS_GZIP -DLAMMPS_MEMALIGN=64 -I../STUBS -c ../main.cpp
In file included from ../pointers.h:24:0,
from ../input.h:17,
from ../main.cpp:16:
../lmptype.h:34:2: error: #error LAMMPS requires a C++11 (or later) compliant compiler. Enable C++11 compatibility or upgrade the compiler.
then you have either an unsupported (old) compiler or you have to
turn on C++11 mode. The latter applies to GCC 4.8.x shipped with
RHEL 7.x and CentOS 7.x. For those compilers, you need to add the
``-std=c++11`` flag. Otherwise, you would have to install a newer
compiler that supports C++11; either as a binary package or through
compiling from source.
If you build LAMMPS with any :doc:`accelerator packages
<Speed_packages>` included, there may be specific optimization flags
that are either required or recommended to enable required features and
to achieve optimal performance. You need to include these in the
CCFLAGS and LINKFLAGS settings above. For details, see the individual
package doc pages listed on the :doc:`Speed packages <Speed_packages>`
doc page. Or examine these files in the src/MAKE/OPTIONS directory.
They correspond to each of the 5 accelerator packages and their hardware
variants:
.. code-block:: bash
Makefile.opt # OPT package
Makefile.omp # USER-OMP package
@ -249,129 +311,201 @@ a variety of settings appropriate for your MPI installation.
Makefile.kokkos_omp # KOKKOS package for CPUs (OpenMP)
Makefile.kokkos_phi # KOKKOS package for KNLs (OpenMP)
----------
.. _exe:
Build LAMMPS as an executable or a library
----------------------------------------------------
Build the LAMMPS executable and library
---------------------------------------
LAMMPS can be built as either an executable or as a static or shared
library. The LAMMPS library can be called from another application or
a scripting language. See the :doc:`Howto couple <Howto_couple>` doc
LAMMPS is always built as a library of C++ classes plus an executable.
The executable is a simple ``main()`` function that sets up MPI and then
creates a LAMMPS class instance from the LAMMPS library, which
will then process commands provided via a file or from the console
input. The LAMMPS library can also be called from another application
or a scripting language. See the :doc:`Howto couple <Howto_couple>` doc
page for more info on coupling LAMMPS to other codes. See the
:doc:`Python <Python_head>` doc page for more info on wrapping and
running LAMMPS from Python via its library interface.
**CMake variables**\ :
**CMake build**\ :
For CMake builds, you can select through setting CMake variables between
building a shared or a static LAMMPS library and what kind of suffix is
added to them (in case you want to concurrently install multiple variants
of binaries with different settings). If none are set, defaults are applied.
.. parsed-literal::
.. code-block:: bash
-D BUILD_EXE=value # yes (default) or no
-D BUILD_LIB=value # yes or no (default)
-D BUILD_SHARED_LIBS=value # yes or no (default)
-D LAMMPS_LIB_SUFFIX=name # name = mpi, serial, mybox, titan, laptop, etc
-D LAMMPS_MACHINE=name # name = mpi, serial, mybox, titan, laptop, etc
# no default value
Setting BUILD\_EXE=no will not produce an executable. Setting
BUILD\_LIB=yes will produce a static library named liblammps.a.
Setting both BUILD\_LIB=yes and BUILD\_SHARED\_LIBS=yes will produce a
shared library named liblammps.so. If LAMMPS\_LIB\_SUFFIX is set the generated
libraries will be named liblammps\_name.a or liblammps\_name.so instead.
The compilation will always produce a LAMMPS library and an executable
linked to it. By default this will be a static library named
``liblammps.a`` and an executable named ``lmp`` Setting
``BUILD_SHARED_LIBS=yes`` will instead produce a shared library called
``liblammps.so`` (or ``liblammps.dylib`` or ``liblammps.dll`` depending
on the platform) If ``LAMMPS_MACHINE=name`` is set in addition, the name
of the generated libraries will be changed to either
``liblammps_name.a`` or ``liblammps_name.so``\ , respectively and the
executable will be called ``lmp_name``.
**Traditional make**\ :
With the traditional makefile based build process, the choice of
the generated executable or library depends on the "mode" setting.
Several options are available and ``mode=static`` is the default.
.. parsed-literal::
.. code-block:: bash
cd lammps/src
make machine # build LAMMPS executable lmp_machine
make mode=lib machine # build LAMMPS static lib liblammps_machine.a
make mode=shlib machine # build LAMMPS shared lib liblammps_machine.so
make mode=static machine # same as "make machine"
make mode=shared machine # build LAMMPS shared lib liblammps_machine.so instead
The two library builds also create generic soft links, named
liblammps.a and liblammps.so, which point to the liblammps\_machine
files.
The "static" build will generate a static library called
``liblammps_machine.a`` and an executable named ``lmp_machine``\ , while
the "shared" build will generate a shared library
``liblammps_machine.so`` instead and ``lmp_machine`` will be linked to
it. The build step will also create generic soft links, named
``liblammps.a`` and ``liblammps.so``\ , which point to the specific
``liblammps_machine.a/so`` files.
**CMake and make info**\ :
CMake and make info
^^^^^^^^^^^^^^^^^^^
Note that for a shared library to be usable by a calling program, all
the auxiliary libraries it depends on must also exist as shared
libraries. This will be the case for libraries included with LAMMPS,
such as the dummy MPI library in src/STUBS or any package libraries in
the lib/packages directory, since they are always built as shared
libraries using the -fPIC switch. However, if a library like MPI or
FFTW does not exist as a shared library, the shared library build will
generate an error. This means you will need to install a shared
library version of the auxiliary library. The build instructions for
the library should tell you how to do this.
Note that for creating a shared library, all the libraries it depends on
must be compiled to be compatible with shared libraries. This should be
the case for libraries included with LAMMPS, such as the dummy MPI
library in ``src/STUBS`` or any package libraries in the ``lib``
directory, since they are always built in a shared library compatible
way using the ``-fPIC`` compiler switch. However, if an auxiliary
library (like MPI or FFTW) does not exist as a compatible format, the
shared library linking step may generate an error. This means you will
need to install a compatible version of the auxiliary library. The
build instructions for that library should tell you how to do this.
As an example, here is how to build and install the `MPICH library <mpich_>`_, a popular open-source version of MPI, distributed by
Argonne National Lab, as a shared library in the default
/usr/local/lib location:
As an example, here is how to build and install the `MPICH library
<mpich_>`_, a popular open-source version of MPI, as a shared library
in the default /usr/local/lib location:
.. _mpich: http://www-unix.mcs.anl.gov/mpi
.. _mpich: https://www.mpich.org
.. parsed-literal::
.. code-block:: bash
./configure --enable-shared
make
make install
You may need to use "sudo make install" in place of the last line if
you do not have write privileges for /usr/local/lib. The end result
should be the file /usr/local/lib/libmpich.so.
You may need to use ``sudo make install`` in place of the last line if
you do not have write privileges for ``/usr/local/lib`` or use the
``--prefix`` configuration option to select an installation folder,
where you do have write access. The end result should be the file
``/usr/local/lib/libmpich.so``. On many Linux installations the folder
``${HOME}/.local`` is an alternative to using ``/usr/local`` and does
not require superuser or sudo access. In that case the configuration
step becomes:
.. code-block:: bash
./configure --enable-shared --prefix=${HOME}/.local
Avoiding to use "sudo" for custom software installation (i.e. from source
and not through a package manager tool provided by the OS) is generally
recommended to ensure the integrity of the system software installation.
----------
.. _debug:
Excluding or removing debug support
-----------------------------------
By default the compilation settings will include the *-g* flag which
instructs the compiler to include debug information (e.g. which line of
source code a particular instruction correspond to). This can be
extremely useful in case LAMMPS crashes and can help to provide crucial
information in :doc:`tracking down the origin of a crash <Errors_debug>`
and help the LAMMPS developers fix bugs in the source code. However,
this increases the storage requirements for object files, libraries, and
the executable 3-5 fold.
If this is a concern, you can change the compilation settings or remove
the debug information from the LAMMPS executable:
- **Traditional make**: edit your ``Makefile.<machine>`` to remove the
*-g* flag from the ``CCFLAGS`` and ``LINKFLAGS`` definitions
- **CMake**: use ``-D CMAKE_BUILD_TYPE=Release`` or explicitly reset
the applicable compiler flags (best done using the text mode or
graphical user interface).
- **Remove debug info**: If you are only concerned about the executable
being too large, you can use the ``strip`` tool (e.g. ``strip
lmp_serial``) to remove the debug information from the executable file.
Do not strip libraries or object files, as that will render them unusable.
----------
.. _doc:
Build the LAMMPS documentation
----------------------------------------
**CMake variable**\ :
The LAMMPS manual is written in `reStructuredText <rst_>`_ format which
can be translated to different output format using the `Sphinx <sphinx_>`_
document generator tool. Currently the translation to HTML and PDF (via
LaTeX) are supported. For that to work a Python 3 interpreter and
internet access is required. For the documentation build a python
based virtual environment is set up in the folder doc/docenv and various
python packages are installed into that virtual environment via the pip
tool. The actual translation is then done via make commands.
.. _rst: https://docutils.readthedocs.io/en/sphinx-docs/user/rst/quickstart.html
.. _sphinx: https://sphinx-doc.org
.. parsed-literal::
Documentation make option
^^^^^^^^^^^^^^^^^^^^^^^^^
-D BUILD_DOC=value # yes or no (default)
The following make commands can be issued in the doc folder of the
LAMMPS source distribution.
This will create the HTML doc pages within the CMake build directory.
The reason to do this is if you want to "install" LAMMPS on a system
after the CMake build via "make install", and include the doc pages in
the install.
.. code-block:: bash
**Traditional make**\ :
make html # create HTML doc pages in html directory
make pdf # create Developer.pdf and Manual.pdf in this directory
make fetch # fetch HTML and PDF files from LAMMPS web site
make clean # remove all intermediate files
make clean-all # reset the entire doc build environment
make anchor_check # scan for duplicate anchor labels
make style_check # check for complete and consistent style lists
make package_check # check for complete and consistent package lists
make spelling # spell-check the manual
.. parsed-literal::
cd lammps/doc
make html # html doc pages
make pdf # single Manual.pdf file
This will create a lammps/doc/html dir with the HTML doc pages so that
you can browse them locally on your system. Type "make" from the
lammps/doc dir to see other options.
Thus "make html" will create a "doc/html" directory with the HTML format
manual pages so that you can browse them with a web browser locally on
your system.
.. note::
You can also download a tarball of the documentation for the
current LAMMPS version (HTML and PDF files), from the website
`download page <http://lammps.sandia.gov/download.html>`_.
`download page <https://lammps.sandia.gov/download.html>`_.
CMake build option
^^^^^^^^^^^^^^^^^^
It is also possible to create the HTML version of the manual within
the :doc:`CMake build directory <Build_cmake>`. The reason for this
option is to include the installation of the HTML manual pages into
the "install" step when installing LAMMPS after the CMake build via
``make install``. The documentation build is included in the default
build target, but can also be requested independently with ``make doc``.
.. code-block:: bash
-D BUILD_DOC=value # yes or no (default)
----------
.. _tools:
Build LAMMPS tools
@ -380,19 +514,20 @@ Build LAMMPS tools
Some tools described in :doc:`Auxiliary tools <Tools>` can be built directly
using CMake or Make.
**CMake variable**\ :
CMake build
^^^^^^^^^^^
.. parsed-literal::
.. code-block:: bash
-D BUILD_TOOLS=value # yes or no (default)
The generated binaries will also become part of the LAMMPS installation (see below)
The generated binaries will also become part of the LAMMPS installation
(see below).
**Traditional make**\ :
Traditional make
^^^^^^^^^^^^^^^^
.. parsed-literal::
.. code-block:: bash
cd lammps/tools
make all # build all binaries of tools
@ -401,10 +536,8 @@ The generated binaries will also become part of the LAMMPS installation (see bel
make micelle2d # build only micelle2d tool
make thermo_extract # build only thermo_extract tool
----------
.. _install:
Install LAMMPS after a build
@ -416,22 +549,18 @@ a globally visible place on your system, for others to access. Note
that you may need super-user privileges (e.g. sudo) if the directory
you want to copy files to is protected.
**CMake variable**\ :
CMake build
^^^^^^^^^^^
.. parsed-literal::
.. code-block:: bash
cmake -D CMAKE_INSTALL_PREFIX=path [options ...] ../cmake
make # perform make after CMake command
make install # perform the installation into prefix
**Traditional make**\ :
Traditional make
^^^^^^^^^^^^^^^^
There is no "install" option in the src/Makefile for LAMMPS. If you
wish to do this you will need to first build LAMMPS, then manually
There is no "install" option in the ``src/Makefile`` for LAMMPS. If
you wish to do this you will need to first build LAMMPS, then manually
copy the desired LAMMPS files to the appropriate system directories.
.. _lws: http://lammps.sandia.gov
.. _ld: Manual.html
.. _lc: Commands_all.html

353
doc/src/Build_cmake.rst
View File

@ -1,222 +1,162 @@
Build LAMMPS with CMake
=======================
This page is a short summary of how to use CMake to build LAMMPS.
Details on CMake variables that enable specific LAMMPS build options
are given on the pages linked to from the :doc:`Build <Build>` doc page.
This page describes how to use `CMake <https://cmake.org>`_ in general
to build LAMMPS. Details for specific compile time settings and options
to enable and configure add-on packages are discussed with those
packages. Links to those pages on the :doc:`Build overview <Build>`
page.
Richard Berger (Temple U) has also written a `more comprehensive guide <https://github.com/lammps/lammps/blob/master/cmake/README.md>`_
for how to use CMake to build LAMMPS. If you are new to CMake it is a
good place to start.
The following text assumes some familiarity with CMake and focuses on
using the command line tool ``cmake`` and what settings are supported
for building LAMMPS. A more detailed tutorial on how to use ``cmake``
itself, the text mode or graphical user interface, change the generated
output files for different build tools and development environments is
on a :doc:`separate page <Howto_cmake>`.
.. note::
LAMMPS currently requires that CMake version 3.10 or later is available;
version 3.12 or later is preferred.
.. warning::
You must not mix the :doc:`traditional make based <Build_make>`
LAMMPS build procedure with using CMake. Thus no packages may be
installed or a build been previously attempted in the LAMMPS source
directory by using ``make <machine>``. CMake will detect if this is
the case and generate an error. To remove conflicting files from the
``src`` you can use the command ``make no-all purge`` which will
un-install all packages and delete all auto-generated files.
----------
Advantages of using CMake
^^^^^^^^^^^^^^^^^^^^^^^^^
CMake is an alternative to compiling LAMMPS in the traditional way
through :doc:`(manually customized) makefiles <Build_make>` and a recent
addition to LAMMPS thanks to the efforts of Christoph Junghans (LANL)
and Richard Berger (Temple U). Using CMake has multiple advantages that
are specifically helpful for people with limited experience in compiling
software or for people that want to modify or extend LAMMPS.
- CMake can detect available hardware, tools, features, and libraries
and adapt the LAMMPS default build configuration accordingly.
- CMake can generate files for different build tools and integrated
development environments (IDE).
- CMake supports customization of settings with a text mode or graphical
user interface. No knowledge of file formats or and complex command
line syntax required.
- All enabled components are compiled in a single build operation.
- Automated dependency tracking for all files and configuration options.
- Support for true out-of-source compilation. Multiple configurations
and settings with different choices of LAMMPS packages, settings, or
compilers can be configured and built concurrently from the same
source tree.
- Simplified packaging of LAMMPS for Linux distributions, environment
modules, or automated build tools like `Homebrew <https://brew.sh/>`_.
- Integration of automated regression testing (the LAMMPS side for that
is still under development).
.. _cmake_build:
Getting started
^^^^^^^^^^^^^^^
Building LAMMPS with CMake is a two-step process. First you use CMake
to create a build environment in a new directory. On Linux systems,
this will be based on makefiles for use with make. Then you use the
make command to build LAMMPS, which uses the created
Makefile(s). Example:
to generate a build environment in a new directory. For that purpose
you can use either the command-line utility ``cmake`` (or ``cmake3``),
the text-mode UI utility ``ccmake`` (or ``ccmake3``) or the graphical
utility ``cmake-gui``, or use them interchangeably. The second step is
then the compilation and linking of all objects, libraries, and
executables. Here is a minimal example using the command line version of
CMake to build LAMMPS with no add-on packages enabled and no
customization:
.. code-block:: bash
.. parsed-literal::
cd lammps # change to the LAMMPS distribution directory
mkdir build; cd build # create and use a build directory
cmake ../cmake # configuration reading CMake scripts from ../cmake
cmake --build . # compilation (or type "make")
cd lammps # change to the LAMMPS distribution directory
mkdir build; cd build # create a new directory (folder) for build
cmake [options ...] ../cmake # configuration with (command-line) cmake
make # compilation
This will create and change into a folder called ``build``, then run the
configuration step to generate build files for the default build command
and then launch that build command to compile LAMMPS. During the
configuration step CMake will try to detect whether support for MPI,
OpenMP, FFTW, gzip, JPEG, PNG, and ffmpeg are available and enable the
corresponding configuration settings. The progress of this
configuration can be followed on the screen and a summary of selected
options and settings will be printed at the end. The ``cmake --build
.`` command will launch the compilation, which, if successful, will
ultimately produce a library ``liblammps.a`` and the LAMMPS executable
``lmp`` inside the ``build`` folder.
The cmake command will detect available features, enable selected
packages and options, and will generate the build environment. By default
this build environment will be created for "Unix Makefiles" on most
platforms and particularly on Linux. However, alternate build tools
(e.g. Ninja) and support files for Integrated Development Environments
(IDE) like Eclipse, CodeBlocks, or Kate can be generated, too. This is
selected via the "-G" command line flag. For the rest of the documentation
we will assume that the build environment is generated for makefiles
and thus the make command will be used to compile and link LAMMPS as
indicated above, producing (by default) an executable called "lmp" and
a library called "liblammps.a" in the "build" folder. When generating
a build environment for the "Ninja" build tool, the build command would
be "ninja" instead of "make".
Compilation can take a long time, since LAMMPS is a large project with
many features. If your machine has multiple CPU cores (most do these
days), you can speed this up by compiling sources in parallel with
``make -j N`` (with N being the maximum number of concurrently executed
tasks). Also installation of the `ccache <https://ccache.dev/>`_ (=
Compiler Cache) software may speed up repeated compilation even more,
e.g. during code development.
If your machine has multiple CPU cores (most do these days), using a
command like "make -jN" (with N being the number of available local
CPU cores) can be much faster. If you plan to do development on
LAMMPS or need to re-compile LAMMPS repeatedly, installation of the
ccache (= Compiler Cache) software may speed up repeated compilation
even more.
After the initial build, whenever you edit LAMMPS source files, enable
or disable packages, change compiler flags or build options, you must
re-compile and relink the LAMMPS executable with ``cmake --build .`` (or
``make``). If the compilation fails for some reason, try running
``cmake .`` and then compile again. The included dependency tracking
should make certain that only the necessary subset of files are
re-compiled. You can also delete compiled objects, libraries and
executables with ``cmake --build . --target clean`` (or ``make clean``).
After compilation, you may optionally install the LAMMPS executable into
your system with:
.. code-block:: bash
.. parsed-literal::
make install # optional, copy compiled files into installation location
make install # optional, copy LAMMPS executable & library elsewhere
This will install the LAMMPS executable and library, some tools (if
configured) and additional files like LAMMPS API headers, manpages,
potential and force field files. The location of the installation tree
defaults to ``${HOME}/.local``.
This will install the lammps executable and library (if requested), some
tools (if configured) and additional files like library API headers,
manpages, potential and force field files. The location of the installation
tree is set by the CMake variable "CMAKE\_INSTALL\_PREFIX" which defaults
to ${HOME}/.local
.. _cmake_options:
Configuration and build options
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The CMake commands have one mandatory argument: a folder containing a
file called ``CMakeLists.txt`` (for LAMMPS it is located in the
``cmake`` folder) or a build folder containing a file called
``CMakeCache.txt``, which is generated at the end of the CMake
configuration step. The cache file contains all current CMake settings.
To modify settings, enable or disable features, you need to set *variables*
with either the *-D* command line flag (``-D VARIABLE1_NAME=value``) or
change them in the text mode of graphical user interface. The *-D* flag
can be used several times in one command.
For your convenience we provide :ref:`CMake presets <cmake_presets>`
that combine multiple settings to enable optional LAMMPS packages or use
a different compiler tool chain. Those are loaded with the *-C* flag
(``-C ../cmake/presets/minimal.cmake``). This step would only be needed
once, as the settings from the preset files are stored in the
``CMakeCache.txt`` file. It is also possible to customize the build
by adding one or more *-D* flags to the CMake command line.
Generating files for alternate build tools (e.g. Ninja) and project files
for IDEs like Eclipse, CodeBlocks, or Kate can be selected using the *-G*
command line flag. A list of available generator settings for your
specific CMake version is given when running ``cmake --help``.
----------
There are 3 variants of CMake: a command-line version (cmake), a text mode
UI version (ccmake), and a graphical GUI version (cmake-GUI). You can use
any of them interchangeably to configure and create the LAMMPS build
environment. On Linux all the versions produce a Makefile as their
output. See more details on each below.
You can specify a variety of options with any of the 3 versions, which
affect how the build is performed and what is included in the LAMMPS
executable. Links to pages explaining all the options are listed on
the :doc:`Build <Build>` doc page.
You must perform the CMake build system generation and compilation in
a new directory you create. It can be anywhere on your local machine.
In these Build pages we assume that you are building in a directory
called "lammps/build". You can perform separate builds independently
with different options, so long as you perform each of them in a
separate directory you create. All the auxiliary files created by one
build process (executable, object files, log files, etc) are stored in
this directory or sub-directories within it that CMake creates.
.. note::
To perform a CMake build, no packages can be installed or a
build been previously attempted in the LAMMPS src directory by using
"make" commands to :doc:`perform a conventional LAMMPS build <Build_make>`. CMake detects if this is the case and
generates an error, telling you to type "make no-all purge" in the src
directory to un-install all packages. The purge removes all the \*.h
files auto-generated by make.
You must have CMake version 2.8 or later on your system to build
LAMMPS. A handful of LAMMPS packages (KOKKOS, LATTE, MSCG) require a
later version. CMake will print a message telling you if a later
version is required. Installation instructions for CMake are below.
After the initial build, if you edit LAMMPS source files, or add your
own new files to the source directory, you can just re-type make from
your build directory and it will re-compile only the files that have
changed. If you want to change CMake options you can run cmake (or
ccmake or cmake-gui) again from the same build directory and alter
various options; see details below. Or you can remove the entire build
folder, recreate the directory and start over.
----------
**Command-line version of CMake**\ :
.. parsed-literal::
cmake [options ...] /path/to/lammps/cmake # build from any dir
cmake [options ...] ../cmake # build from lammps/build
The cmake command takes one required argument, which is the LAMMPS
cmake directory which contains the CMakeLists.txt file.
The argument can be preceeded or followed by various CMake
command-line options. Several useful ones are:
.. parsed-literal::
-D CMAKE_INSTALL_PREFIX=path # where to install LAMMPS executable/lib if desired
-D CMAKE_BUILD_TYPE=type # type = RelWithDebInfo (default), Release, MinSizeRel, or Debug
-G output # style of output CMake generates
-DVARIABLE=value # setting for a LAMMPS feature to enable
-D VARIABLE=value # ditto, but cannot come after CMakeLists.txt dir
-C path/to/preset/file # load some CMake settings before configuring
All the LAMMPS-specific -D variables that a LAMMPS build supports are
described on the pages linked to from the :doc:`Build <Build>` doc page.
All of these variable names are upper-case and their values are
lower-case, e.g. -D LAMMPS\_SIZES=smallbig. For boolean values, any of
these forms can be used: yes/no, on/off, 1/0.
On Unix/Linux machines, CMake generates a Makefile by default to
perform the LAMMPS build. Alternate forms of build info can be
generated via the -G switch, e.g. Visual Studio on a Windows machine,
Xcode on MacOS, or KDevelop on Linux. Type "cmake --help" to see the
"Generator" styles of output your system supports.
.. note::
When CMake runs, it prints configuration info to the screen.
You should review this to verify all the features you requested were
enabled, including packages. You can also see what compilers and
compile options will be used for the build. Any errors in CMake
variable syntax will also be flagged, e.g. mis-typed variable names or
variable values.
CMake creates a CMakeCache.txt file when it runs. This stores all the
settings, so that when running CMake again you can use the current
folder '.' instead of the path to the LAMMPS cmake folder as the
required argument to the CMake command. Either way the existing
settings will be inherited unless the CMakeCache.txt file is removed.
If you later want to change a setting you can rerun cmake in the build
directory with different setting. Please note that some automatically
detected variables will not change their value when you rerun cmake.
In these cases it is usually better to first remove all the
files/directories in the build directory, or start with a fresh build
directory.
----------
**Curses version (terminal-style menu) of CMake**\ :
.. parsed-literal::
ccmake ../cmake
You initiate the configuration and build environment generation steps
separately. For the first you have to type **c**\ , for the second you
have to type **g**\ . You may need to type **c** multiple times, and may be
required to edit some of the entries of CMake configuration variables
in between. Please see the `ccmake manual <https://cmake.org/cmake/help/latest/manual/ccmake.1.html>`_ for
more information.
----------
**GUI version of CMake**\ :
.. parsed-literal::
cmake-gui ../cmake
You initiate the configuration and build environment generation steps
separately. For the first you have to click on the **Configure** button,
for the second you have to click on the **Generate** button. You may
need to click on **Configure** multiple times, and may be required to
edit some of the entries of CMake configuration variables in between.
Please see the `cmake-gui manual <https://cmake.org/cmake/help/latest/manual/cmake-gui.1.html>`_
for more information.
----------
**Installing CMake**
Installing CMake
^^^^^^^^^^^^^^^^
Check if your machine already has CMake installed:
.. parsed-literal::
.. code-block:: bash
which cmake # do you have it?
which cmake3 # version 3 may have this name
@ -225,21 +165,16 @@ Check if your machine already has CMake installed:
On clusters or supercomputers which use environment modules to manage
software packages, do this:
.. code-block:: bash
.. parsed-literal::
module list # is a module for cmake already loaded?
module avail # is a module for cmake available?
module load cmake # load cmake module with appropriate name
module list # is a cmake module already loaded?
module avail # is a cmake module available?
module load cmake3 # load cmake module with appropriate name
Most Linux distributions offer pre-compiled cmake packages through
their package management system. If you do not have CMake or a new
enough version, you can download the latest version at
`https://cmake.org/download/ <https://cmake.org/download/>`_.
Instructions on how to install it on various platforms can be found
`on this page <https://cmake.org/install/>`_.
.. _lws: http://lammps.sandia.gov
.. _ld: Manual.html
.. _lc: Commands_all.html
Most Linux distributions offer pre-compiled cmake packages through their
package management system. If you do not have CMake or a recent enough
version (Note: for CentOS 7.x you need to enable the EPEL repository),
you can download the latest version from `https://cmake.org/download/
<https://cmake.org/download/>`_. Instructions on how to install it on
various platforms can be found `on this page
<https://cmake.org/install/>`_.

362
doc/src/Build_development.rst
View File

@ -1,120 +1,370 @@
Development build options (CMake only)
======================================
The CMake build of LAMMPS has a few extra options which are useful during
development, testing or debugging.
The CMake build procedure of LAMMPS offers a few extra options which are
useful during development, testing or debugging.
----------
.. _compilation:
Verify compilation flags
------------------------------------------
Monitor compilation flags
-------------------------
Sometimes it is necessary to verify the complete sequence of compilation flags
generated by the CMake build. To enable a more verbose output during
compilation you can use the following option.
.. parsed-literal::
.. code-block:: bash
-D CMAKE_VERBOSE_MAKEFILE=value # value = no (default) or yes
Another way of doing this without reconfiguration is calling make with variable VERBOSE set to 1:
Another way of doing this without reconfiguration is calling make with
variable VERBOSE set to 1:
.. parsed-literal::
.. code-block:: bash
make VERBOSE=1
----------
.. _sanitizer:
Address, Undefined Behavior, and Thread Sanitizer Support
-------------------------------------------------------------------------
---------------------------------------------------------
Compilers such as GCC and Clang support generating binaries which use different
sanitizers to detect problems in code during run-time. They can detect `memory leaks <https://clang.llvm.org/docs/AddressSanitizer.html>`_,
code that runs into `undefined behavior <https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html>`_ of the
language and `data races <https://clang.llvm.org/docs/ThreadSanitizer.html>`_ in threaded code.
Compilers such as GCC and Clang support generating instrumented binaries
which use different sanitizer libraries to detect problems in the code
during run-time. They can detect issues like:
The following settings allow you enable these features if your compiler supports
it. Please note that they come with a performance hit. However, they are
usually faster than using tools like Valgrind.
- `memory leaks <https://clang.llvm.org/docs/AddressSanitizer.html>`_
- `undefined behavior <https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html>`_
- `data races <https://clang.llvm.org/docs/ThreadSanitizer.html>`_
Please note that this kind of instrumentation usually comes with a
performance hit (but much less than using tools like `Valgrind
<https://valgrind.org>`_ with a more low level approach). The to enable
these features additional compiler flags need to be added to the
compilation and linking stages. This is done through setting the
``ENABLE_SANITIZER`` variable during configuration. Examples:
.. parsed-literal::
-D ENABLE_SANITIZE_ADDRESS=value # enable Address Sanitizer, value = no (default) or yes
-D ENABLE_SANITIZE_UNDEFINED=value # enable Undefined Behaviour Sanitizer, value = no (default) or yes
-D ENABLE_SANITIZE_THREAD=value # enable Thread Sanitizer, value = no (default) or yes
.. code-block:: bash
-D ENABLE_SANITIZER=none # no sanitizer active (default)
-D ENABLE_SANITIZER=address # enable address sanitizer / memory leak checker
-D ENABLE_SANITIZER=leak # enable memory leak checker (only)
-D ENABLE_SANITIZER=undefined # enable undefined behavior sanitizer
-D ENABLE_SANITIZER=thread # enable thread sanitizer
----------
.. _testing:
Code Coverage and Testing
---------------------------------------
Code Coverage and Unit Testing
------------------------------
We do extensive regression testing of the LAMMPS code base on a continuous
basis. Some of the logic to do this has been added to the CMake build so
developers can run the tests directly on their workstation.
The LAMMPS code is subject to multiple levels of automated testing
during development: integration testing (i.e. whether the code compiles
on various platforms and with a variety of settings), unit testing
(i.e. whether certain individual parts of the code produce the expected
results for given inputs), run testing (whether selected complete input
decks run without crashing for multiple configurations), and regression
testing (i.e. whether selected input examples reproduce the same
results over a given number of steps and operations within a given
error margin). The status of this automated testing can be viewed on
`https://ci.lammps.org <https://ci.lammps.org>`_.
The unit testing facility is integrated into the CMake build process
of the LAMMPS source code distribution itself. It can be enabled by
setting ``-D ENABLE_TESTING=on`` during the CMake configuration step.
It requires the `YAML <http://pyyaml.org/>`_ library and development
headers to compile and will download and compile a recent version of the
`Googletest <https://github.com/google/googletest/>`_ C++ test framework
for implementing the tests.
After compilation is complete, the unit testing is started in the build
folder using the ``ctest`` command, which is part of the CMake software.
The output of this command will be looking something like this::
[...]$ ctest
Test project /home/akohlmey/compile/lammps/build-testing
Start 1: MolPairStyle:hybrid-overlay
1/109 Test #1: MolPairStyle:hybrid-overlay ......... Passed 0.02 sec
Start 2: MolPairStyle:hybrid
2/109 Test #2: MolPairStyle:hybrid ................. Passed 0.01 sec
Start 3: MolPairStyle:lj_class2
[...]
Start 107: PotentialFileReader
107/109 Test #107: PotentialFileReader ................ Passed 0.04 sec
Start 108: EIMPotentialFileReader
108/109 Test #108: EIMPotentialFileReader ............. Passed 0.03 sec
Start 109: TestSimpleCommands
109/109 Test #109: TestSimpleCommands ................. Passed 0.02 sec
100% tests passed, 0 tests failed out of 26
Total Test time (real) = 25.57 sec
The ``ctest`` command has many options, the most important ones are:
.. list-table::
* - Option
- Function
* - -V
- verbose output: display output of individual test runs
* - -j <num>
- parallel run: run <num> tests in parallel
* - -R <regex>
- run subset of tests matching the regular expression <regex>
* - -E <regex>
- exclude subset of tests matching the regular expression <regex>
* - -N
- dry-run: display list of tests without running them
* - -T memcheck
- run tests with valgrind memory checker (if available)
In its full implementation, the unit test framework will consist of multiple
kinds of tests implemented in different programming languages (C++, C, Python,
Fortran) and testing different aspects of the LAMMPS software and its features.
At the moment only tests for "force styles" are implemented. More on those
in the next section.
.. note::
this is incomplete and only represents a small subset of tests that we run
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
different input files in YAML format. So to add a test for
another pair style can be done by copying the YAML file and
editing the style settings and then running the individual test
program with a flag to update the computed reference data.
Detailed documentation about how to add new test program and
the contents of the YAML files for existing test programs
will be provided in time as well.
Unit tests for force styles
^^^^^^^^^^^^^^^^^^^^^^^^^^^
A large part of LAMMPS are different "styles" for computing non-bonded
and bonded interactions selected through the :doc:`pair_style`,
:doc:`bond_style`, :doc:`angle_style`, :doc:`dihedral_style`,
:doc:`improper_style`, and :doc:`kspace_style`. Since these all share
common interfaces, it is possible to write generic test programs that
will call those common interfaces for small test systems with less than
100 atoms and compare the results with pre-recorded reference results.
A test run is then a a collection multiple individual test runs each
with many comparisons to reference results based on template input
files, individual command settings, relative error margins, and
reference data stored in a YAML format file with ``.yaml``
suffix. Currently the programs ``pair_style``, ``bond_style``, and
``angle_style`` are implemented. They will compare forces, energies and
(global) stress for all atoms after a ``run 0`` calculation and after a
few steps of MD with :doc:`fix nve <fix_nve>`, each in multiple variants
with different settings and also for multiple accelerated styles. If a
prerequisite style or package is missing, the individual tests are
skipped. All tests will be executed on a single MPI process, so using
the CMake option ``-D BUILD_MPI=off`` can significantly speed up testing,
since this will skip the MPI initialization for each test run.
Below is an example command and output:
.. parsed-literal::
-D ENABLE_TESTING=value # enable simple run tests of LAMMPS, value = no (default) or yes
-D LAMMPS_TESTING_SOURCE_DIR=path # path to lammps-testing repository (option if in custom location)
-D LAMMPS_TESTING_GIT_TAG=value # version of lammps-testing repository that should be used, value = master (default) or custom git commit or tag
[tests]$ pair_style mol-pair-lj_cut.yaml
[==========] Running 6 tests from 1 test suite.
[----------] Global test environment set-up.
[----------] 6 tests from PairStyle
[ RUN ] PairStyle.plain
[ OK ] PairStyle.plain (24 ms)
[ RUN ] PairStyle.omp
[ OK ] PairStyle.omp (18 ms)
[ RUN ] PairStyle.intel
[ OK ] PairStyle.intel (6 ms)
[ RUN ] PairStyle.opt
[ SKIPPED ] PairStyle.opt (0 ms)
[ RUN ] PairStyle.single
[ OK ] PairStyle.single (7 ms)
[ RUN ] PairStyle.extract
[ OK ] PairStyle.extract (6 ms)
[----------] 6 tests from PairStyle (62 ms total)
If you enable testing in the CMake build it will create an additional target called "test". You can run them with:
[----------] Global test environment tear-down
[==========] 6 tests from 1 test suite ran. (63 ms total)
[ PASSED ] 5 tests.
[ SKIPPED ] 1 test, listed below:
[ SKIPPED ] PairStyle.opt
In this particular case, 5 out of 6 sets of tests were conducted, the
tests for the ``lj/cut/opt`` pair style was skipped, since the tests
executable did not include it. To learn what individual tests are performed,
you (currently) need to read the source code. You can use code coverage
recording (see next section) to confirm how well the tests cover the code
paths in the individual source files.
.. parsed-literal::
The force style test programs have a common set of options:
make test
.. list-table::
The test cases used come from the lammps-testing repository. They are
derivatives of the examples folder with some modifications to make the run
faster.
* - Option
- Function
* - -g <newfile>
- regenerate reference data in new YAML file
* - -u
- update reference data in the original YAML file
* - -s
- print error statistics for each group of comparisons
* - -v
- verbose output: also print the executed LAMMPS commands
You can also collect code coverage metrics while running the tests by enabling
coverage support during building.
The ``ctest`` tool has no mechanism to directly pass flags to the individual
test programs, but a workaround has been implemented where these flags can be
set in an environment variable ``TEST_ARGS``. Example:
.. code-block:: bash
.. parsed-literal::
env TEST_ARGS=-s ctest -V -R BondStyle
-D ENABLE_COVERAGE=value # enable coverage measurements, value = no (default) or yes
To add a test for a style that is not yet covered, it is usually best
to copy a YAML file for a similar style to a new file, edit the details
of the style (how to call it, how to set its coefficients) and then
run test command with either the *-g* and the replace the initial
test file with the regenerated one or the *-u* option. The *-u* option
will destroy the original file, if the generation run does not complete,
so using *-g* is recommended unless the YAML file is fully tested
and working.
This will also add the following targets to generate coverage reports after running the LAMMPS executable:
.. admonition:: Recommendations and notes for YAML files
:class: note
- The reference results should be recorded without any code
optimization or related compiler flags enabled.
- The ``epsilon`` parameter defines the relative precision with which
the reference results must be met. The test geometries often have
high and low energy parts and thus a significant impact from
floating-point math truncation errors is to be expected. Some
functional forms and potentials are more noisy than others, so this
parameter needs to be adjusted. Typically a value around 1.0e-13
can be used, but it may need to be as large as 1.0e-8 in some
cases.
- The tests for pair styles from OPT, USER-OMP and USER-INTEL are
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
are likely to fail. It is recommended to inspect the individual
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 an undesired large loss of precision due
to significant reordering of operations and thus less error cancellation).
.. parsed-literal::
Use custom linker for faster link times when ENABLE_TESTING is active
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
make test # run tests first!
make gen_coverage_html # generate coverage report in HTML format
make gen_coverage_xml # generate coverage report in XML format
When compiling LAMMPS with enabled tests, most test executables will
need to be linked against the LAMMPS library. Since this can be a
large with many C++ objects when many packages are enabled, link times
can become very long on machines that use the GNU BFD linker (e.g.
Linux systems). Alternatives like the ``lld`` linker of the LLVM project
or the ``gold`` linker available with GNU binutils can speed up this step
substantially. CMake will by default test if any of the two can be
enabled and use it when ``ENABLE_TESTING`` is active. It can also be
selected manually through the ``CMAKE_CUSTOM_LINKER`` CMake variable.
Allowed values are ``lld``, ``gold``, ``bfd``, or ``default``. The
``default`` option will use the system default linker otherwise, the
linker is chosen explicitly. This option is only available for the
GNU or Clang C++ compiler.
These reports require GCOVR to be installed. The easiest way to do this to install it via pip:
Tests for other components and utility functions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Additional tests that validate utility functions or specific components
of LAMMPS are implemented as standalone executable which may, or may not
require creating a suitable LAMMPS instance. These tests are more specific
and do not require YAML format input files. To add a test, either an
existing source file needs to be extended or a new file added, which in turn
requires additions to the ``CMakeLists.txt`` file in the source folder.
.. parsed-literal::
Collect and visualize code coverage metrics
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You can also collect code coverage metrics while running LAMMPS or the
tests by enabling code coverage support during the CMake configuration:
.. code-block:: bash
-D ENABLE_COVERAGE=on # enable coverage measurements (off by default)
This will instrument all object files to write information about which
lines of code were accessed during execution in files next to the
corresponding object files. These can be post-processed to visually
show the degree of coverage and which code paths are accessed and which
are not taken. When working on unit tests (see above), this can be
extremely helpful to determine which parts of the code are not executed
and thus what kind of tests are still missing. The coverage data is
cumulative, i.e. new data is added with each new run.
Enabling code coverage will also add the following build targets to
generate coverage reports after running the LAMMPS executable or the
unit tests:
.. code-block:: bash
make gen_coverage_html # generate coverage report in HTML format
make gen_coverage_xml # generate coverage report in XML format
make clean_coverage_html # delete folder with HTML format coverage report
make reset_coverage # delete all collected coverage data and HTML output
These reports require `GCOVR <https://gcovr.com/>`_ to be installed. The easiest way
to do this to install it via pip:
.. code-block:: bash
pip install git+https://github.com/gcovr/gcovr.git
After post-processing with ``gen_coverage_html`` the results are in
a folder ``coverage_html`` and can be viewed with a web browser.
The images below illustrate how the data is presented.
.. list-table::
.. _lws: http://lammps.sandia.gov
.. _ld: Manual.html
.. _lc: Commands_all.html
* - .. figure:: JPG/coverage-overview-top.png
:target: JPG/coverage-overview-top.png
Top of the overview page
- .. figure:: JPG/coverage-overview-manybody.png
:target: JPG/coverage-overview-manybody.png
Styles with good coverage
- .. figure:: JPG/coverage-file-top.png
:target: JPG/coverage-file-top.png
Top of individual source page
- .. figure:: JPG/coverage-file-branches.png
:target: JPG/coverage-file-branches.png
Source page with branches
Coding style utilities
----------------------
To aid with enforcing some of the coding style conventions in LAMMPS
some additional build targets have been added. These require Python 3.5
or later and will only work on Unix-like operating and file systems.
The following options are available.
.. code-block:: bash
make check-whitespace # generate coverage report in HTML format
make fix-whitespace # generate coverage report in XML format
make check-permissions # delete folder with HTML format coverage report
make fix-permissions # delete all collected coverage data and HTML output
For the code in the ``unittest`` tree we are using the `clang-format`
tool (Clang version 8.0 or later is required). If available, the source
code files in the ``unittest`` tree can be updated to conform to the
formatting settings using ``make format-tests``.

1512
doc/src/Build_extras.rst
View File

File diff suppressed because it is too large Load Diff

248
doc/src/Build_link.rst
View File

@ -1,91 +1,235 @@
Link LAMMPS as a library to another code
========================================
LAMMPS can be used as a library by another application, including
Python scripts. The files src/library.cpp and library.h define the
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.
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>` 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 one of
these 2 files:
LAMMPS as either a shared or static library. This results in a file
in the compilation folder called ``liblammps.a`` or ``liblammps_<name>.a``
in case of building a static library. In case of a shared library
the name is the same only that the suffix is going to be either ``.so``
or ``.dylib`` or ``.dll`` instead of ``.a`` depending on the OS.
In some cases the ``.so`` file may be a symbolic link to a file with
the suffix ``.so.0`` (or some other number).
liblammps.so # shared library
liblammps.a # static library
.. note::
Care should be taken to use the same MPI library for the calling code
and the LAMMPS library. The ``library.h`` file includes ``mpi.h``
and uses definitions from it so those need to be available and
consistent. When LAMMPS is compiled with the included STUBS MPI
library, then its ``mpi.h`` file needs to be included. While it is
technically possible to use a full MPI library in the calling code
and link to a serial LAMMPS library compiled with MPI STUBS, it is
recommended to use the *same* MPI library for both, and then use
``MPI_Comm_split()`` in the calling code to pass a suitable
communicator with a subset of MPI ranks to the function creating the
LAMMPS instance.
----------
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``.
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.
**Link with LAMMPS as a static library**\ :
CMake build
^^^^^^^^^^^
The calling application can link to LAMMPS as a static library with a
link command like this:
This assumes that LAMMPS has been configured without setting a
``LAMMPS_MACHINE`` name, installed with "make install", and the
``PKG_CONFIG_PATH`` environment variable has been updated to include the
``liblammps.pc`` file installed into the configured destination folder.
The commands to compile and link a coupled executable are then:
g++ caller.o -L/home/sjplimp/lammps/src -llammps -o caller
.. code-block:: bash
The -L argument is the path to where the liblammps.a file is. The
-llammps argument is shorthand for the file liblammps.a.
mpicc -c -O $(pkgconf liblammps --cflags) caller.c
mpicxx -o caller caller.o -$(pkgconf liblammps --libs)
Traditional make
^^^^^^^^^^^^^^^^
----------
This assumes that LAMMPS has been compiled in the folder
``${HOME}/lammps/src`` with "make mpi". The commands to compile and link
a coupled executable are then:
.. code-block:: bash
**Link with LAMMPS as a shared library**\ :
mpicc -c -O -I${HOME}/lammps/src caller.c
mpicxx -o caller caller.o -L${HOME}/lammps/src -llammps_mpi
If you wish to link to liblammps.so, the operating system finds shared
libraries to load at run-time using the environment variable
LD\_LIBRARY\_PATH. To enable this you can do one of two things:
The *-I* argument is the path to the location of the ``library.h``
header file containing the interface to the LAMMPS C-style library
interface. The *-L* argument is the path to where the ``liblammps_mpi.a``
file is located. The *-llammps_mpi* argument is shorthand for telling the
compiler to link the file ``liblammps_mpi.a``. If LAMMPS has been
built as a shared library, then the linker will use ``liblammps_mpi.so``
instead. If both files are available, the linker will usually prefer
the shared library. In case of a shared library, you may need to update
the ``LD_LIBRARY_PATH`` environment variable or running the ``caller``
executable will fail since it cannot find the shared library at runtime.
(1) Copy the liblammps.so file to a location the system can find it,
such as /usr/local/lib. I.e. a directory already listed in your
LD\_LIBRARY\_PATH variable. You can type
However, it is only as simple as shown above for the case of a plain
LAMMPS library without any optional packages that depend on libraries
(bundled or external) or when using a shared library. Otherwise, you
need to include all flags, libraries, and paths for the coupled
executable, that are also required to link the LAMMPS executable.
CMake build
^^^^^^^^^^^
.. parsed-literal::
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``
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.
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
have installed the ``POEMS`` package after building its bundled library
in ``lib/poems``. Then the commands to build and link the coupled executable
change to:
.. code-block:: bash
gcc -c -O -I${HOME}/lammps/src/STUBS -I${HOME}/lammps/src -caller.c
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`` 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
make mode=print serial
Which should output something like:
.. code-block:: bash
# Compiler:
CXX=g++
# Linker:
LD=g++
# Compilation:
CXXFLAGS=-g -O3 -DLAMMPS_GZIP -DLAMMPS_MEMALIGN=64 -I${HOME}/compile/lammps/lib/poems -I${HOME}/compile/lammps/src/STUBS
# Linking:
LDFLAGS=-g -O
# 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
of the makefile.
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
in the shared library or registered as a dependent library in the shared
library file. Thus those libraries need not to be specified when
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
^^^^^^^^^^^
The commands with a shared LAMMPS library compiled with the CMake
build process are the same as for the static library.
.. code-block:: bash
mpicc -c -O $(pkgconf liblammps --cflags) caller.c
mpicxx -o caller caller.o -$(pkgconf --libs)
Traditional make
^^^^^^^^^^^^^^^^
The commands with a shared LAMMPS library compiled with the
traditional make build using ``make mode=shared serial`` becomes:
.. code-block:: bash
gcc -c -O -I${HOME}/lammps/src/STUBS -I${HOME}/lammps/src -caller.c
g++ -o caller caller.o -L${HOME}/lammps/src -llammps_serial
*Locating liblammps.so at runtime*\ :
However, now the ``liblammps.so`` file is required at runtime and needs
to be in a folder, where the shared linker program of the operating
system can find it. This would be either a folder like ``/usr/local/lib64``
or ``${HOME}/.local/lib64`` or a folder pointed to by the ``LD_LIBRARY_PATH``
environment variable. You can type
.. code-block:: bash
printenv LD_LIBRARY_PATH
to see what directories are in that list.
(2) Add the LAMMPS src directory (or the directory you perform CMake
build in) to your LD\_LIBRARY\_PATH, so that the current version of the
shared library is always available to programs that use it.
Or you can add the LAMMPS src directory (or the directory you performed
a CMake style build in) to your ``LD_LIBRARY_PATH``, so that the current
version of the shared library is always available to programs that use it.
For the csh or tcsh shells, you would add something like this to your
~/.cshrc file:
For the Bourne or Korn shells (/bin/sh, /bin/ksh, /bin/bash etc.), you
would add something like this to your ``${HOME}/.profile`` file:
.. code-block:: bash
.. parsed-literal::
LD_LIBRARY_PATH ${LD_LIBRARY_PATH-/usr/lib64}:${HOME}/lammps/src
export LD_LIBRARY_PATH
setenv LD_LIBRARY_PATH ${LD_LIBRARY_PATH}:/home/sjplimp/lammps/src
For the csh or tcsh shells, you would equivalently add something like this
to your ``${HOME}/.cshrc`` file:
.. code-block:: csh
----------
setenv LD_LIBRARY_PATH ${LD_LIBRARY_PATH}:${HOME}/lammps/src
You can verify whether all required shared libraries are found with the
``ldd`` tool. Example:
**Calling the LAMMPS library**\ :
.. code-block:: bash
Either flavor of library (static or shared) allows one or more LAMMPS
objects to be instantiated from the calling program.
$ LD_LIBRARY_PATH=/home/user/lammps/src ldd caller
linux-vdso.so.1 (0x00007ffe729e0000)
liblammps.so => /home/user/lammps/src/liblammps.so (0x00007fc91bb9e000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fc91b984000)
libm.so.6 => /lib64/libm.so.6 (0x00007fc91b83e000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fc91b824000)
libc.so.6 => /lib64/libc.so.6 (0x00007fc91b65b000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc91c094000)
When used from a C++ program, all of LAMMPS is wrapped in a LAMMPS\_NS
namespace; you can safely use any of its classes and methods from
within the calling code, as needed.
If a required library is missing, you would get a 'not found' entry:
When used from a C or Fortran program, the library has a simple
C-style interface, provided in src/library.cpp and src/library.h.
.. code-block:: bash
See the :doc:`Python library <Python_library>` doc page for a
description of the Python interface to LAMMPS, which wraps the C-style
interface.
$ ldd caller
linux-vdso.so.1 (0x00007ffd672fe000)
liblammps.so => not found
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fb7c7e86000)
libm.so.6 => /usr/lib64/libm.so.6 (0x00007fb7c7d40000)
libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007fb7c7d26000)
libc.so.6 => /usr/lib64/libc.so.6 (0x00007fb7c7b5d000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb7c80a2000)
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.
.. _lws: http://lammps.sandia.gov
.. _ld: Manual.html
.. _lc: Commands_all.html

130
doc/src/Build_make.rst
View File

@ -2,71 +2,109 @@ Build LAMMPS with make
======================
Building LAMMPS with traditional makefiles requires that you have a
Makefile."machine" file appropriate for your system in the src/MAKE,
src/MAKE/MACHINES, src/MAKE/OPTIONS, or src/MAKE/MINE directory (see
below). It can include various options for customizing your LAMMPS
build with a number of global compilation options and features.
``Makefile.<machine>`` file appropriate for your system in either the
``src/MAKE``, ``src/MAKE/MACHINES``, ``src/MAKE/OPTIONS``, or
``src/MAKE/MINE`` directory (see below). It can include various options
for customizing your LAMMPS build with a number of global compilation
options and features.
To include LAMMPS packages (i.e. optional commands and styles) you
must install them first, as discussed on the :doc:`Build package <Build_package>` doc page. If the packages require
provided or external libraries, you must build those libraries before
building LAMMPS. Building :doc:`LAMMPS with CMake <Build_cmake>` can
automate all of this for many types of machines, especially
workstations, desktops and laptops, so we suggest you try it first.
Requirements
^^^^^^^^^^^^
These commands perform a default LAMMPS build, producing the LAMMPS
executable lmp\_serial or lmp\_mpi in lammps/src:
Those makefiles are written for and tested with GNU make and may not
be compatible with other make programs. In most cases, if the "make"
program is not GNU make, then there will be a GNU make program
available under the name "gmake". If GNU make or a compatible make is
not available, you may have to first install it or switch to building
with :doc:`CMake <Build_cmake>`. The makefiles of the traditional
make based build process and the scripts they are calling expect a few
additional tools to be available and functioning.
* a working C/C++ compiler toolchain supporting the C++11 standard; on
Linux these are often the GNU compilers. Some older compilers
require adding flags like ``-std=c++11`` to enable the C++11 mode.
* a Bourne shell compatible "Unix" shell program (often this is ``bash``)
* a few shell utilities: ``ls``, ``mv``, ``ln``, ``rm``, ``grep``, ``sed``, ``tr``, ``cat``, ``touch``, ``diff``, ``dirname``
* python (optional, required for ``make lib-<pkg>`` in the src folder).
python scripts are currently tested with python 2.7 and 3.6. The procedure
for :doc:`building the documentation <Manual_build>` requires python 3.
.. parsed-literal::
Getting started
^^^^^^^^^^^^^^^
cd lammps/src
make serial # build a serial LAMMPS executable
To include LAMMPS packages (i.e. optional commands and styles) you must
enable (or "install") them first, as discussed on the :doc:`Build
package <Build_package>` doc page. If a packages requires (provided or
external) libraries, you must configure and build those libraries
**before** building LAMMPS itself and especially **before** enabling
such a package with ``make yes-<package>``. Building :doc:`LAMMPS with
CMake <Build_cmake>` can automate much of this for many types of
machines, especially workstations, desktops, and laptops, so we suggest
you try it first when building LAMMPS in those cases.
The commands below perform a default LAMMPS build, producing the LAMMPS
executable ``lmp_serial`` and ``lmp_mpi`` in ``lammps/src``:
.. code-block:: bash
cd lammps/src # change to main LAMMPS source folder
make serial # build a serial LAMMPS executable using GNU g++
make mpi # build a parallel LAMMPS executable with MPI
make # see a variety of make options
This initial compilation can take a long time, since LAMMPS is a large
project with many features. If your machine has multiple CPU cores
(most do these days), using a command like "make -jN mpi" (with N =
the number of available CPU cores) can be much faster. If you plan to
do development on LAMMPS or need to re-compile LAMMPS repeatedly, the
installation of the ccache (= Compiler Cache) software may speed up
compilation even more.
Compilation can take a long time, since LAMMPS is a large project with
many features. If your machine has multiple CPU cores (most do these
days), you can speed this up by compiling sources in parallel with
``make -j N`` (with N being the maximum number of concurrently executed
tasks). Also installation of the `ccache <https://ccache.dev/>`_ (=
Compiler Cache) software may speed up repeated compilation even more,
e.g. during code development.
After the initial build, whenever you edit LAMMPS source files, or add
or remove new files to the source directory (e.g. by installing or
uninstalling packages), you must re-compile and relink the LAMMPS
executable with the same "make" command. This makefiles dependencies
should insure that only the subset of files that need to be are
re-compiled.
executable with the same ``make <machine>`` command. The makefile's
dependency tracking should insure that only the necessary subset of
files are re-compiled. If you change settings in the makefile, you have
to recompile *everything*. To delete all objects you can use ``make
clean-<machine>``.
.. note::
When you build LAMMPS for the first time, a long list of \*.d
files will be printed out rapidly. This is not an error; it is the
Makefile doing its normal creation of dependencies.
Before the actual compilation starts, LAMMPS will perform several
steps to collect information from the configuration and setup that
is then embedded into the executable. When you build LAMMPS for
the first time, it will also compile a tool to quickly assemble
a list of dependencies, that are required for the make program to
correctly detect which parts need to be recompiled after changes
were made to the sources.
Customized builds and alternate makefiles
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
----------
The ``src/MAKE`` directory tree contains the ``Makefile.<machine>``
files included in the LAMMPS distribution. Typing ``make example`` uses
``Makefile.example`` from one of those folders, if available. Thus the
``make serial`` and ``make mpi`` lines above use
``src/MAKE/Makefile.serial`` and ``src/MAKE/Makefile.mpi``,
respectively. Other makefiles are in these directories:
The lammps/src/MAKE tree contains all the Makefile.machine files
included in the LAMMPS distribution. Typing "make machine" uses
Makefile.machine. Thus the "make serial" or "make mpi" lines above
use Makefile.serial and Makefile.mpi. Others are in these dirs:
.. parsed-literal::
.. code-block:: bash
OPTIONS # Makefiles which enable specific options
MACHINES # Makefiles for specific machines
MINE # customized Makefiles you create (you may need to create this folder)
Typing "make" lists all the available Makefile.machine files. A file
with the same name can appear in multiple folders (not a good idea).
The order the dirs are searched is as follows: src/MAKE/MINE,
src/MAKE, src/MAKE/OPTIONS, src/MAKE/MACHINES. This gives preference
to a customized file you put in src/MAKE/MINE.
Simply typing ``make`` lists all the available ``Makefile.<machine>``
files with a single line description toward the end of the output. A
file with the same name can appear in multiple folders (not a good
idea). The order the directories are searched is as follows:
``src/MAKE/MINE``, ``src/MAKE``, ``src/MAKE/OPTIONS``,
``src/MAKE/MACHINES``. This gives preference to a customized file you
put in ``src/MAKE/MINE``. If you create your own custom makefile under
a new name, please edit the first line with the description and machine
name, so you will not confuse yourself, when looking at the machine
summary.
Makefiles you may wish to try include these (some require a package
first be installed). Many of these include specific compiler flags
@ -75,8 +113,7 @@ customized machine Makefile are contributed by users. Since both
compilers, OS configurations, and LAMMPS itself keep changing, their
settings may become outdated:
.. parsed-literal::
.. code-block:: bash
make mac # build serial LAMMPS on a Mac
make mac_mpi # build parallel LAMMPS on a Mac
@ -87,8 +124,3 @@ settings may become outdated:
make kokkos_omp # build with the KOKKOS package for OpenMP
make kokkos_cuda_mpi # build with the KOKKOS package for GPUs
make kokkos_phi # build with the KOKKOS package for KNLs
.. _lws: http://lammps.sandia.gov
.. _ld: Manual.html
.. _lc: Commands_all.html

147
doc/src/Build_package.rst
View File

@ -14,10 +14,13 @@ package. In general there is no need to include a package if you
never plan to use its features.
If you get a run-time error that a LAMMPS command or style is
"Unknown", it is often because the command is contained in a package,
and your build did not include that package. Running LAMMPS with the
:doc:`-h command-line switch <Run_options>` will print all the included
packages and commands for that executable.
"unknown", it is often because the command is contained in a package,
and your build did not include that package. If the command or style
*is* available in a package included in the LAMMPS distribution,
the error message will indicate which package would be needed.
Running LAMMPS with the :doc:`-h command-line switch <Run_options>`
will print *all* optional commands and packages that were enabled
when building that executable.
For the majority of packages, if you follow the single step below to
include it, you can then build LAMMPS exactly the same as you would
@ -42,17 +45,16 @@ packages:
The mechanism for including packages is simple but different for CMake
versus make.
**CMake variables**\ :
CMake build
^^^^^^^^^^^
.. parsed-literal::
.. code-block:: csh
-D PKG_NAME=value # yes or no (default)
Examples:
.. parsed-literal::
.. code-block:: csh
-D PKG_MANYBODY=yes
-D PKG_USER-INTEL=yes
@ -71,10 +73,10 @@ once with CMake.
invoke cmake. CMake will give an error if that is not the case,
indicating how you can un-install all packages in the src dir.
**Traditional make**\ :
Traditional make
^^^^^^^^^^^^^^^^
.. parsed-literal::
.. code-block:: bash
cd lammps/src
make ps # check which packages are currently installed
@ -84,8 +86,7 @@ once with CMake.
Examples:
.. parsed-literal::
.. code-block:: bash
make no-rigid
make yes-user-intel
@ -109,7 +110,8 @@ once with make.
within the same command. You can include or exclude multiple packages
in a single make command, e.g. make yes-colloid no-manybody.
**CMake and make info**\ :
CMake and make info
^^^^^^^^^^^^^^^^^^^
Any package can be included or excluded in a LAMMPS build, independent
of all other packages. However, some packages include files derived
@ -119,7 +121,7 @@ are already included. Likewise, if a package is excluded, other files
dependent on that package are also excluded.
When you download a LAMMPS tarball or download LAMMPS source files
from the Git or SVN repositories, no packages are pre-installed in the
from the git repository, no packages are pre-installed in the
src directory.
.. note::
@ -129,16 +131,17 @@ src directory.
That is no longer the case, so that CMake will build as-is without the
need to un-install those packages.
----------
.. _cmake_presets:
**CMake shortcuts for installing many packages**\ :
CMake presets for installing many packages
Instead of specifying all the CMake options via the command-line,
CMake allows initializing the variable cache using script files. These
are regular CMake files which can manipulate and set variables, and
can also contain control flow constructs.
CMake allows initializing its settings cache using script files.
These are regular CMake files which can manipulate and set CMake
variables (which represent selected options), and can also contain
control flow constructs for more complex operations.
LAMMPS includes several of these files to define configuration
"presets", similar to the options that exist for the Make based
@ -146,33 +149,28 @@ system. Using these files you can enable/disable portions of the
available packages in LAMMPS. If you need a custom preset you can take
one of them as a starting point and customize it to your needs.
+-------------------------------------------------------------+-----------------------------------------------------------+
| cmake -C ../cmake/presets/all\_on.cmake [OPTIONS] ../cmake | enable all packages |
+-------------------------------------------------------------+-----------------------------------------------------------+
| cmake -C ../cmake/presets/all\_off.cmake [OPTIONS] ../cmake | disable all packages |
+-------------------------------------------------------------+-----------------------------------------------------------+
| cmake -C ../cmake/presets/minimal.cmake [OPTIONS] ../cmake | enable just a few core packages |
+-------------------------------------------------------------+-----------------------------------------------------------+
| cmake -C ../cmake/presets/most.cmake [OPTIONS] ../cmake | enable most common packages |
+-------------------------------------------------------------+-----------------------------------------------------------+
| cmake -C ../cmake/presets/nolib.cmake [OPTIONS] ../cmake | disable packages that do require extra libraries or tools |
+-------------------------------------------------------------+-----------------------------------------------------------+
| cmake -C ../cmake/presets/clang.cmake [OPTIONS] ../cmake | change settings to use the Clang compilers by default |
+-------------------------------------------------------------+-----------------------------------------------------------+
| cmake -C ../cmake/presets/mingw.cmake [OPTIONS] ../cmake | enable all packages compatible with MinGW compilers |
+-------------------------------------------------------------+-----------------------------------------------------------+
.. code-block:: bash
cmake -C ../cmake/presets/minimal.cmake [OPTIONS] ../cmake # enable just a few core packages
cmake -C ../cmake/presets/most.cmake [OPTIONS] ../cmake # enable most packages
cmake -C ../cmake/presets/download.cmake [OPTIONS] ../cmake # enable packages which download sources or potential files
cmake -C ../cmake/presets/nolib.cmake [OPTIONS] ../cmake # disable packages that do require extra libraries or tools
cmake -C ../cmake/presets/clang.cmake [OPTIONS] ../cmake # change settings to use the Clang compilers by default
cmake -C ../cmake/presets/intel.cmake [OPTIONS] ../cmake # change settings to use the Intel compilers by default
cmake -C ../cmake/presets/all_on.cmake [OPTIONS] ../cmake # enable all packages
cmake -C ../cmake/presets/all_off.cmake [OPTIONS] ../cmake # disable all packages
mingw64-cmake -C ../cmake/presets/mingw-cross.cmake [OPTIONS] ../cmake # compile with MinGW cross compilers
.. note::
Running cmake this way manipulates the variable cache in your
Running cmake this way manipulates the CMake settings cache in your
current build directory. You can combine multiple presets and options
in a single cmake run, or change settings incrementally by running
cmake with new flags.
**Example:**
.. parsed-literal::
.. code-block:: bash
# build LAMMPS with most commonly used packages, but then remove
# those requiring additional library or tools, but still enable
@ -188,49 +186,41 @@ one of them as a starting point and customize it to your needs.
# but leaving all other settings untouched. You can run:
cmake -C ../cmake/presets/no_all.cmake .
----------
**Make shortcuts for installing many packages**\ :
Make shortcuts for installing many packages
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The following commands are useful for managing package source files
and their installation when building LAMMPS via traditional make.
Just type "make" in lammps/src to see a one-line summary.
Just type ``make`` in lammps/src to see a one-line summary.
These commands install/un-install sets of packages:
+-----------------------------------+-----------------------------------------------------+
| make yes-all | install all packages |
+-----------------------------------+-----------------------------------------------------+
| make no-all | un-install all packages |
+-----------------------------------+-----------------------------------------------------+
| make yes-standard or make yes-std | install standard packages |
+-----------------------------------+-----------------------------------------------------+
| make no-standard or make no-std | un-install standard packages |
+-----------------------------------+-----------------------------------------------------+
| make yes-user | install user packages |
+-----------------------------------+-----------------------------------------------------+
| make no-user | un-install user packages |
+-----------------------------------+-----------------------------------------------------+
| make yes-lib | install packages that require extra libraries |
+-----------------------------------+-----------------------------------------------------+
| make no-lib | un-install packages that require extra libraries |
+-----------------------------------+-----------------------------------------------------+
| make yes-ext | install packages that require external libraries |
+-----------------------------------+-----------------------------------------------------+
| make no-ext | un-install packages that require external libraries |
+-----------------------------------+-----------------------------------------------------+
.. code-block:: bash
which install/un-install various sets of packages. Typing "make
package" will list all the these commands.
make yes-all # install all packages
make no-all # uninstall all packages
make yes-standard or make yes-std # install standard packages
make no-standard or make no-std # uninstall standard packages
make yes-user # install user packages
make no-user # uninstall user packages
make yes-lib # install packages that require extra libraries
make no-lib # uninstall packages that require extra libraries
make yes-ext # install packages that require external libraries
make no-ext # uninstall packages that require external libraries
which install/un-install various sets of packages. Typing ``make
package`` will list all the these commands.
.. note::
Installing or un-installing a package works by simply copying
files back and forth between the main src directory and
sub-directories with the package name (e.g. src/KSPACE, src/USER-ATC),
so that the files are included or excluded when LAMMPS is built.
Installing or un-installing a package for the make based build process
works by simply copying files back and forth between the main source
directory src and the sub-directories with the package name (e.g.
src/KSPACE, src/USER-ATC), so that the files are included or excluded
when LAMMPS is built. Only source files in the src folder will be
compiled.
The following make commands help manage files that exist in both the
src directory and in package sub-directories. You do not normally
@ -238,28 +228,23 @@ need to use these commands unless you are editing LAMMPS files or are
:doc:`installing a patch <Install_patch>` downloaded from the LAMMPS web
site.
Type "make package-status" or "make ps" to show which packages are
Type ``make package-status`` or ``make ps`` to show which packages are
currently installed. For those that are installed, it will list any
files that are different in the src directory and package
sub-directory.
Type "make package-installed" or "make pi" to show which packages are
Type ``make package-installed`` or ``make pi`` to show which packages are
currently installed, without listing the status of packages that are
not installed.
Type "make package-update" or "make pu" to overwrite src files with
Type ``make package-update`` or ``make pu`` to overwrite src files with
files from the package sub-directories if the package is installed.
It should be used after a :doc:`patch has been applied <Install_patch>`,
since patches only update the files in the package sub-directory, but
not the src files.
Type "make package-overwrite" to overwrite files in the package
Type ``make package-overwrite`` to overwrite files in the package
sub-directories with src files.
Type "make package-diff" to list all differences between pairs of
files in both the src dir and a package dir.
.. _lws: http://lammps.sandia.gov
.. _ld: Manual.html
.. _lc: Commands_all.html
Type ``make package-diff`` to list all differences between pairs of
files in both the source directory and the package directory.

275
doc/src/Build_settings.rst
View File

@ -4,68 +4,35 @@ Optional build settings
LAMMPS can be built with several optional settings. Each sub-section
explain how to do this for building both with CMake and make.
| :ref:`C++11 standard compliance test <cxx11>` when building all of LAMMPS
| :ref:`FFT library <fft>` for use with the :doc:`kspace_style pppm <kspace_style>` command
| :ref:`Size of LAMMPS data types <size>`
| :ref:`Read or write compressed files <gzip>`
| :ref:`Output of JPG and PNG files <graphics>` via the :doc:`dump image <dump_image>` command
| :ref:`Output of movie files <graphics>` via the :doc:`dump_movie <dump_image>` command
| :ref:`Memory allocation alignment <align>`
| :ref:`Workaround for long long integers <longlong>`
| :ref:`Error handling exceptions <exceptions>` when using LAMMPS as a library
|
* :ref:`C++11 standard compliance <cxx11>` when building all of LAMMPS
* :ref:`FFT library <fft>` for use with the :doc:`kspace_style pppm <kspace_style>` command
* :ref:`Size of LAMMPS data types <size>`
* :ref:`Read or write compressed files <gzip>`
* :ref:`Output of JPG and PNG files <graphics>` via the :doc:`dump image <dump_image>` command
* :ref:`Output of movie files <graphics>` via the :doc:`dump_movie <dump_image>` command
* :ref:`Memory allocation alignment <align>`
* :ref:`Workaround for long long integers <longlong>`
* :ref:`Error handling exceptions <exceptions>` when using LAMMPS as a library
----------
.. _cxx11:
C++11 standard compliance test
C++11 standard compliance
------------------------------------------
The LAMMPS developers plan to transition to make the C++11 standard the
minimum requirement for compiling LAMMPS. Currently this only applies to
some packages like KOKKOS while the rest aims to be compatible with the C++98
standard. Most currently used compilers are compatible with C++11; some need
to set extra flags to switch. To determine the impact of requiring C++11,
we have added a simple compliance test to the source code, that will cause
the compilation to abort, if C++11 compliance is not available or enabled.
To bypass this check, you need to change a setting in the makefile or
when calling CMake.
A C++11 standard compatible compiler is a requirement for compiling LAMMPS.
LAMMPS version 3 March 2020 is the last version compatible with the previous
C++98 standard for the core code and most packages. Most currently used
C++ compilers are compatible with C++11, but some older ones may need extra
flags to enable C++11 compliance. Example for GNU c++ 4.8.x:
**CMake variable**\ :
.. parsed-literal::
-D DISABLE_CXX11_REQUIREMENT=yes
You can set additional C++ compiler flags (beyond those selected by CMake)
through the CMAKE\_CXX\_FLAGS variable. Example for CentOS 7:
.. parsed-literal::
-D CMAKE_CXX_FLAGS="-O3 -g -fopenmp -DNDEBUG -std=c++11"
**Makefile.machine setting**\ to bypass the C++11 test and compile in C++98 mode:
.. parsed-literal::
LMP_INC = -DLAMMPS_CXX98
**Makefile.machine setting**\ to enable the C++11 with older (but not too old) GNU c++ (e.g. on CentOS 7):
.. parsed-literal::
.. code-block:: make
CCFLAGS = -g -O3 -std=c++11
----------
.. _fft:
FFT library
@ -77,10 +44,10 @@ require use of an FFT library to compute 1d FFTs. The KISS FFT
library is included with LAMMPS but other libraries can be faster.
LAMMPS can use them if they are available on your system.
**CMake variables**\ :
CMake build
^^^^^^^^^^^
.. parsed-literal::
.. code-block:: bash
-D FFT=value # FFTW3 or MKL or KISS, default is FFTW3 if found, else KISS
-D FFT_SINGLE=value # yes or no (default), no = double precision
@ -99,44 +66,52 @@ OpenMP threads are enabled and a packages like KOKKOS or USER-OMP is
used. If CMake cannot detect the FFT library, you can set these variables
to assist:
.. parsed-literal::
.. code-block:: bash
-D FFTW3_INCLUDE_DIRS=path # path to FFTW3 include files
-D FFTW3_LIBRARIES=path # path to FFTW3 libraries
-D FFT_FFTW_THREADS=on # enable using threaded FFTW3 libraries
-D MKL_INCLUDE_DIRS=path # ditto for Intel MKL library
-D FFT_MKL_THREADS=on # enable using threaded FFTs with MKL libraries
-D MKL_LIBRARIES=path
**Makefile.machine settings**\ :
Traditional make
^^^^^^^^^^^^^^^^
To change the FFT library to be used and its options, you have to edit
your machine Makefile. Below are examples how the makefile variables
could be changed.
.. parsed-literal::
.. code-block:: make
FFT_INC = -DFFT_FFTW3 # -DFFT_FFTW3, -DFFT_FFTW (same as -DFFT_FFTW3), -DFFT_MKL, or -DFFT_KISS
# default is KISS if not specified
FFT_INC = -DFFT_SINGLE # do not specify for double precision
FFT_INC = -DFFT_FFTW_THREADS # enable using threaded FFTW3 libraries
FFT_INC = -DFFT_MKL_THREADS # enable using threaded FFTs with MKL libraries
FFT_INC = -DFFT_PACK_ARRAY # or -DFFT_PACK_POINTER or -DFFT_PACK_MEMCPY
# default is FFT\_PACK\_ARRAY if not specified
# default is FFT_PACK_ARRAY if not specified
.. parsed-literal::
.. code-block:: make
FFT_INC = -I/usr/local/include
FFT_PATH = -L/usr/local/lib
FFT_LIB = -lfftw3 # FFTW3 double precision
FFT_LIB = -lfftw3 -lfftw3_omp # FFTW3 double precision with threads (needs -DFFT_FFTW_THREADS)
FFT_LIB = -lfftw3 -lfftw3f # FFTW3 single precision
FFT_LIB = -lmkl_intel_lp64 -lmkl_sequential -lmkl_core # MKL with Intel compiler
FFT_LIB = -lmkl_gf_lp64 -lmkl_sequential -lmkl_core # MKL with GNU compier
FFT_LIB = -lmkl_intel_lp64 -lmkl_sequential -lmkl_core # MKL with Intel compiler, serial interface
FFT_LIB = -lmkl_gf_lp64 -lmkl_sequential -lmkl_core # MKL with GNU compiler, serial interface
FFT_LIB = -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core # MKL with Intel compiler, threaded interface
FFT_LIB = -lmkl_gf_lp64 -lmkl_gnu_thread -lmkl_core # MKL with GNU compiler, threaded interface
FFT_LIB = -lmkl_rt # MKL with automatic runtime selection of interface libs
As with CMake, you do not need to set paths in FFT\_INC or FFT\_PATH, if
make can find the FFT header and library files. You must specify
FFT\_LIB with the appropriate FFT libraries to include in the link.
As with CMake, you do not need to set paths in ``FFT_INC`` or ``FFT_PATH``, if
the compiler can find the FFT header and library files in its default search path.
You must specify ``FFT_LIB`` with the appropriate FFT libraries to include in the link.
**CMake and make info**\ :
CMake build
^^^^^^^^^^^
The `KISS FFT library <http://kissfft.sf.net>`_ is included in the LAMMPS
distribution. It is portable across all platforms. Depending on the size
@ -158,14 +133,15 @@ platform and can be faster than the KISS FFT library. You can
download it from `www.fftw.org <http://www.fftw.org>`_. LAMMPS requires
version 3.X; the legacy version 2.1.X is no longer supported.
Building FFTW for your box should be as simple as ./configure; make;
make install. The install command typically requires root privileges
Building FFTW for your box should be as simple as ``./configure; make;
make install``. The install command typically requires root privileges
(e.g. invoke it via sudo), unless you specify a local directory with
the "--prefix" option of configure. Type "./configure --help" to see
the "--prefix" option of configure. Type ``./configure --help`` to see
various options.
The Intel MKL math library is part of the Intel compiler suite. It
can be used with the Intel or GNU compiler (see FFT\_LIB setting above).
can be used with the Intel or GNU compiler (see the ``FFT_LIB`` setting
above).
Performing 3d FFTs in parallel can be time consuming due to data
access and required communication. This cost can be reduced by
@ -174,58 +150,60 @@ precision means the real and imaginary parts of a complex datum are
4-byte floats. Double precision means they are 8-byte doubles. Note
that Fourier transform and related PPPM operations are somewhat less
sensitive to floating point truncation errors and thus the resulting
error is less than the difference in precision. Using the -DFFT\_SINGLE
error is less than the difference in precision. Using the ``-DFFT_SINGLE``
setting trades off a little accuracy for reduced memory use and
parallel communication costs for transposing 3d FFT data.
When using -DFFT\_SINGLE with FFTW3 you may need to build the FFTW
When using ``-DFFT_SINGLE`` with FFTW3 you may need to build the FFTW
library a second time with support for single-precision.
For FFTW3, do the following, which should produce the additional
library libfftw3f.a or libfftw3f.so.
library ``libfftw3f.a`` or ``libfftw3f.so``\ .
.. parsed-literal::
.. code-block:: bash
make clean
./configure --enable-single; make; make install
Performing 3d FFTs requires communication to transpose the 3d FFT
grid. The data packing/unpacking for this can be done in one of 3
modes (ARRAY, POINTER, MEMCPY) as set by the FFT\_PACK syntax above.
modes (ARRAY, POINTER, MEMCPY) as set by the FFT_PACK syntax above.
Depending on the machine, the size of the FFT grid, the number of
processors used, one option may be slightly faster. The default is
ARRAY mode.
----------
.. _size:
Size of LAMMPS data types
Size of LAMMPS integer types
------------------------------------
LAMMPS has a few integer data types which can be defined as 4-byte or
8-byte integers. The default setting of "smallbig" is almost always
adequate.
LAMMPS has a few integer data types which can be defined as either
4-byte (= 32-bit) or 8-byte (= 64-bit) integers at compile time.
The default setting of "smallbig" is almost always adequate.
**CMake variable**\ :
CMake build
^^^^^^^^^^^
.. parsed-literal::
.. code-block:: bash
-D LAMMPS_SIZES=value # smallbig (default) or bigbig or smallsmall
**Makefile.machine setting**\ :
Traditional build
^^^^^^^^^^^^^^^^^
If you want a setting different from the default, you need to edit your
machine Makefile.
.. parsed-literal::
.. code-block:: make
LMP_INC = -DLAMMPS_SMALLBIG # or -DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL
# default is LAMMPS\_SMALLBIG if not specified
**CMake and make info**\ :
The default setting is ``-DLAMMPS_SMALLBIG`` if nothing is specified
CMake and make info
^^^^^^^^^^^^^^^^^^^
The default "smallbig" setting allows for simulations with:
@ -272,12 +250,10 @@ than crashing randomly or corrupting data.
Also note that the GPU package requires its lib/gpu library to be
compiled with the same size setting, or the link will fail. A CMake
build does this automatically. When building with make, the setting
in whichever lib/gpu/Makefile is used must be the same as above.
in whichever ``lib/gpu/Makefile`` is used must be the same as above.
----------
.. _graphics:
Output of JPG, PNG, and movie files
@ -288,24 +264,23 @@ PNG image files. Likewise the :doc:`dump movie <dump_image>` command
outputs movie files in MPEG format. Using these options requires the
following settings:
**CMake variables**\ :
CMake build
^^^^^^^^^^^
.. parsed-literal::
.. code-block:: bash
-D WITH_JPEG=value # yes or no
# default = yes if CMake finds JPEG files, else no
# default = yes if CMake finds JPEG files, else no
-D WITH_PNG=value # yes or no
# default = yes if CMake finds PNG and ZLIB files, else no
# default = yes if CMake finds PNG and ZLIB files, else no
-D WITH_FFMPEG=value # yes or no
# default = yes if CMake can find ffmpeg, else no
# default = yes if CMake can find ffmpeg, else no
Usually these settings are all that is needed. If CMake cannot find
the graphics header, library, executable files, you can set these
variables:
.. parsed-literal::
.. code-block:: bash
-D JPEG_INCLUDE_DIR=path # path to jpeglib.h header file
-D JPEG_LIBRARIES=path # path to libjpeg.a (.so) file
@ -315,10 +290,10 @@ variables:
-D ZLIB_LIBRARIES=path # path to libz.a (.so) file
-D FFMPEG_EXECUTABLE=path # path to ffmpeg executable
**Makefile.machine settings**\ :
Traditional make
^^^^^^^^^^^^^^^^
.. parsed-literal::
.. code-block:: make
LMP_INC = -DLAMMPS_JPEG
LMP_INC = -DLAMMPS_PNG
@ -328,28 +303,28 @@ variables:
JPG_PATH = -L/usr/lib # paths to libjpeg.a, libpng.a, libz.a (.so) files if make cannot find them
JPG_LIB = -ljpeg -lpng -lz # library names
As with CMake, you do not need to set JPG\_INC or JPG\_PATH, if make can
find the graphics header and library files. You must specify JPG\_LIB
As with CMake, you do not need to set ``JPG_INC`` or ``JPG_PATH``,
if make can find the graphics header and library files. You must
specify ``JPG_LIB``
with a list of graphics libraries to include in the link. You must
insure ffmpeg is in a directory where LAMMPS can find it at runtime,
i.e. a dir in your PATH environment variable.
that is a directory in your PATH environment variable.
**CMake and make info**\ :
CMake and make info
^^^^^^^^^^^^^^^^^^^
Using ffmpeg to output movie files requires that your machine
Using ``ffmpeg`` to output movie files requires that your machine
supports the "popen" function in the standard runtime library.
.. note::
On some clusters with high-speed networks, using the fork()
library calls (required by popen()) can interfere with the fast
library call (required by popen()) can interfere with the fast
communication library and lead to simulations using ffmpeg to hang or
crash.
----------
.. _gzip:
Read or write compressed files
@ -359,23 +334,24 @@ If this option is enabled, large files can be read or written with
gzip compression by several LAMMPS commands, including
:doc:`read_data <read_data>`, :doc:`rerun <rerun>`, and :doc:`dump <dump>`.
**CMake variables**\ :
CMake build
^^^^^^^^^^^
.. parsed-literal::
.. code-block:: bash
-D WITH_GZIP=value # yes or no
# default is yes if CMake can find gzip, else no
-D GZIP_EXECUTABLE=path # path to gzip executable if CMake cannot find it
**Makefile.machine setting**\ :
Traditional make
^^^^^^^^^^^^^^^^
.. parsed-literal::
.. code-block:: make
LMP_INC = -DLAMMPS_GZIP
**CMake and make info**\ :
CMake and make info
^^^^^^^^^^^^^^^^^^^
This option requires that your machine supports the "popen()" function
in the standard runtime library and that a gzip executable can be
@ -384,22 +360,20 @@ found by LAMMPS during a run.
.. note::
On some clusters with high-speed networks, using the fork()
library calls (required by popen()) can interfere with the fast
library call (required by popen()) can interfere with the fast
communication library and lead to simulations using compressed output
or input to hang or crash. For selected operations, compressed file
I/O is also available using a compression library instead, which is
what the :ref:`COMPRESS package <PKG-COMPRESS>` enables.
----------
.. _align:
Memory allocation alignment
---------------------------------------
This setting enables the use of the posix\_memalign() call instead of
This setting enables the use of the posix_memalign() call instead of
malloc() when LAMMPS allocates large chunks or memory. This can make
vector instructions on CPUs more efficient, if dynamically allocated
memory is aligned on larger-than-default byte boundaries.
@ -408,35 +382,33 @@ pointers that are aligned to 16-byte boundaries. Using SSE vector
instructions efficiently, however, requires memory blocks being
aligned on 64-byte boundaries.
**CMake variable**\ :
CMake build
^^^^^^^^^^^
.. parsed-literal::
.. code-block:: bash
-D LAMMPS_MEMALIGN=value # 0, 8, 16, 32, 64 (default)
Use a LAMMPS\_MEMALIGN value of 0 to disable using posix\_memalign()
Use a ``LAMMPS_MEMALIGN`` value of 0 to disable using posix_memalign()
and revert to using the malloc() C-library function instead. When
compiling LAMMPS for Windows systems, malloc() will always be used
and this setting ignored.
**Makefile.machine setting**\ :
Traditional make
^^^^^^^^^^^^^^^^
.. parsed-literal::
.. code-block:: make
LMP_INC = -DLAMMPS_MEMALIGN=value # 8, 16, 32, 64
Do not set -DLAMMPS\_MEMALIGN, if you want to have memory allocated
with the malloc() function call instead. -DLAMMPS\_MEMALIGN **cannot**
Do not set ``-DLAMMPS_MEMALIGN``, if you want to have memory allocated
with the malloc() function call instead. ``-DLAMMPS_MEMALIGN`` **cannot**
be used on Windows, as it does use different function calls for
allocating aligned memory, that are not compatible with how LAMMPS
manages its dynamical memory.
----------
.. _longlong:
Workaround for long long integers
@ -447,49 +419,50 @@ types, the following setting will be needed. It converts "long long"
to a "long" data type, which should be the desired 8-byte integer on
those systems:
**CMake variable**\ :
CMake build
^^^^^^^^^^^
.. parsed-literal::
.. code-block:: bash
-D LAMMPS_LONGLONG_TO_LONG=value # yes or no (default)
**Makefile.machine setting**\ :
Traditional make
^^^^^^^^^^^^^^^^
.. parsed-literal::
.. code-block:: make
LMP_INC = -DLAMMPS_LONGLONG_TO_LONG
----------
.. _exceptions:
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 caller.
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.
e.g. to Python. Of course, the calling code has to be set up to
*catch* exceptions thrown from within LAMMPS.
**CMake variable**\ :
CMake build
^^^^^^^^^^^
.. parsed-literal::
.. code-block:: bash
-D LAMMPS_EXCEPTIONS=value # yes or no (default)
**Makefile.machine setting**\ :
Traditional make
^^^^^^^^^^^^^^^^
.. parsed-literal::
.. code-block:: make
LMP_INC = -DLAMMPS_EXCEPTIONS
.. note::
.. _lws: http://lammps.sandia.gov
.. _ld: Manual.html
.. _lc: Commands_all.html
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.

51
doc/src/Build_windows.rst
View File

@ -6,10 +6,8 @@ Notes for building LAMMPS on Windows
* :ref:`Using GNU GCC ported to Windows <gnu>`
* :ref:`Using a cross-compiler <cross>`
----------
.. _generic:
General remarks
@ -17,9 +15,9 @@ General remarks
LAMMPS is developed and tested primarily on Linux machines. The vast
majority of HPC clusters and supercomputers today runs on Linux as well.
Thus portability to other platforms is desired, but not always achieved.
While portability to other platforms is desired, it is not always achieved.
The LAMMPS developers strongly rely on LAMMPS users giving feedback and
providing assistance in resolving portability issues. This particularly
providing assistance in resolving portability issues. This is particularly
true for compiling LAMMPS on Windows, since this platform has significant
differences with some low-level functionality.
@ -31,18 +29,20 @@ Running Linux on Windows
So before trying to build LAMMPS on Windows, please consider if using
the pre-compiled Windows binary packages are sufficient for your needs
(as an aside, those packages themselves are build on a Linux machine
using cross-compilers). If it is necessary for your to compile LAMMPS
using cross-compilers). If it is necessary for you to compile LAMMPS
on a Windows machine (e.g. because it is your main desktop), please also
consider using a virtual machine software and run a Linux virtual machine,
or - if have a recently updated Windows 10 installation - consider using
the Windows subsystem for Linux, which allows to run a bash shell from
Ubuntu and from there on, you can pretty much use that shell like you
are running on an Ubuntu Linux machine (e.g. installing software via
apt-get). For more details on that, please see :doc:`this tutorial <Howto_bash>`
consider using a virtual machine software and compile and run LAMMPS in
a Linux virtual machine, or - if you have a recently updated Windows 10
installation - consider using the Windows subsystem for Linux. This
optional Windows feature allows you to run the bash shell from Ubuntu
from within Windows and from there on, you can pretty much use that
shell like you are running on an Ubuntu Linux machine (e.g. installing
software via apt-get and more). For more details on that, please
see :doc:`this tutorial <Howto_wsl>`
.. _gnu:
Using GNU GCC ported to Windows
Using a GNU GCC ported to Windows
-----------------------------------------
One option for compiling LAMMPS on Windows natively, that has been known
@ -55,8 +55,8 @@ and the corresponding new code. A machine makefile for using cygwin for
the old build system is provided. Using CMake for this mode of compilation
is untested and not likely to work.
When compiling for Windows do **not** set the -DLAMMPS\_MEMALIGN define
in the LMP\_INC makefile variable and add -lwsock32 -lpsapi to the linker
When compiling for Windows do **not** set the -DLAMMPS_MEMALIGN define
in the LMP_INC makefile variable and add -lwsock32 -lpsapi to the linker
flags in LIB makefile variable. Try adding -static-libgcc or -static or
both to the linker flags when your resulting LAMMPS Windows executable
complains about missing .dll files. The CMake configuration should set
@ -83,13 +83,19 @@ traditional build system, but CMake has also been successfully tested
using the mingw32-cmake and mingw64-cmake wrappers that are bundled
with the cross-compiler environment on Fedora machines. A CMake preset
selecting all packages compatible with this cross-compilation build
is provided. You likely need to disable the GPU package unless you
download and install the contents of the pre-compiled `OpenCL ICD loader library <https://download.lammps.org/thirdparty/opencl-win-devel.tar.gz>`_
into your MinGW64 cross-compiler environment. The cross-compilation
currently will only produce non-MPI serial binaries.
is provided. The GPU package can only be compiled with OpenCL support
and you need to download and install the pre-compiled
`OpenCL ICD loader library <https://download.lammps.org/thirdparty/opencl-win-devel.tar.gz>`_
into your MinGW64 cross-compiler environment. With CMake this will be
done transparently. To compile with MPI support, a pre-compiled
library and the corresponding header files are required. There is
`one package for 32-bit Windows <https://download.lammps.org/thirdparty/mpich2-win32-devel.tar.gz>`_
and `a second package for 64-bit Windows <https://download.lammps.org/thirdparty/mpich2-win64-devel.tar.gz>`_.
When building with CMake, the matching package will be downloaded
automatically, but MPI support has to be explicitly enabled with ``-DBUILD_MPI=on``.
Please keep in mind, though, that this only applies to compiling LAMMPS.
Whether the resulting binaries do work correctly is no tested by the
Please keep in mind, though, that this only applies to **compiling** LAMMPS.
Whether the resulting binaries do work correctly is not tested by the
LAMMPS developers. We instead rely on the feedback of the users
of these pre-compiled LAMMPS packages for Windows. We will try to resolve
issues to the best of our abilities if we become aware of them. However
@ -104,8 +110,3 @@ Support for the Visual C++ compilers is currently not available. The
CMake build system is capable of creating suitable a Visual Studio
style build environment, but the LAMMPS code itself is not fully ported
to support Visual C++. Volunteers to take on this task are welcome.
.. _lws: http://lammps.sandia.gov
.. _ld: Manual.html
.. _lc: Commands_all.html

1
doc/src/Commands.rst
View File

@ -4,7 +4,6 @@ Commands
These pages describe how a LAMMPS input script is formatted and the
commands in it are used to define a LAMMPS simulation.
.. toctree::
:maxdepth: 1

15
doc/src/Commands_all.rst
View File

@ -17,7 +17,7 @@ General commands
An alphabetic list of all general LAMMPS commands.
.. table_from_list::
:columns: 6
:columns: 5
* :doc:`angle_coeff <angle_coeff>`
* :doc:`angle_style <angle_style>`
@ -46,13 +46,6 @@ An alphabetic list of all general LAMMPS commands.
* :doc:`dimension <dimension>`
* :doc:`displace_atoms <displace_atoms>`
* :doc:`dump <dump>`
* :doc:`dump atom/adios <dump_adios>`
* :doc:`dump custom/adios <dump_adios>`
* :doc:`dump image <dump_image>`
* :doc:`dump movie <dump_image>`
* :doc:`dump netcdf <dump_netcdf>`
* :doc:`dump netcdf/mpiio <dump_netcdf>`
* :doc:`dump vtk <dump_vtk>`
* :doc:`dump_modify <dump_modify>`
* :doc:`dynamical_matrix <dynamical_matrix>`
* :doc:`echo <echo>`
@ -70,6 +63,7 @@ An alphabetic list of all general LAMMPS commands.
* :doc:`kim_init <kim_commands>`
* :doc:`kim_interactions <kim_commands>`
* :doc:`kim_param <kim_commands>`
* :doc:`kim_property <kim_commands>`
* :doc:`kim_query <kim_commands>`
* :doc:`kspace_modify <kspace_modify>`
* :doc:`kspace_style <kspace_style>`
@ -93,6 +87,7 @@ An alphabetic list of all general LAMMPS commands.
* :doc:`package <package>`
* :doc:`pair_coeff <pair_coeff>`
* :doc:`pair_modify <pair_modify>`
* :doc:`pair_style <pair_style>`
* :doc:`pair_write <pair_write>`
* :doc:`partition <partition>`
* :doc:`prd <prd>`
@ -106,7 +101,8 @@ An alphabetic list of all general LAMMPS commands.
* :doc:`region <region>`
* :doc:`replicate <replicate>`
* :doc:`rerun <rerun>`
* :doc:`reset_ids <reset_ids>`
* :doc:`reset_atom_ids <reset_atom_ids>`
* :doc:`reset_mol_ids <reset_mol_ids>`
* :doc:`reset_timestep <reset_timestep>`
* :doc:`restart <restart>`
* :doc:`run <run>`
@ -136,4 +132,3 @@ An alphabetic list of all general LAMMPS commands.
* :doc:`write_data <write_data>`
* :doc:`write_dump <write_dump>`
* :doc:`write_restart <write_restart>`

1
doc/src/Commands_bond.rst
View File

@ -100,7 +100,6 @@ have accelerated versions. This is indicated by additional letters in
parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
OPT.
.. table_from_list::
:columns: 4

233
doc/src/Commands_category.rst
View File

@ -7,126 +7,163 @@ alphabetically. Style options for entries like fix, compute, pair etc.
have their own pages where they are listed alphabetically.
Initialization:
------------------------------
* :doc:`newton <newton>`,
* :doc:`package <package>`,
* :doc:`processors <processors>`,
* :doc:`suffix <suffix>`,
* :doc:`units <units>`
.. table_from_list::
:columns: 5
* :doc:`newton <newton>`
* :doc:`package <package>`
* :doc:`processors <processors>`
* :doc:`suffix <suffix>`
* :doc:`units <units>`
Setup simulation box:
------------------------------
* :doc:`boundary <boundary>`,
* :doc:`box <box>`,
* :doc:`change_box <change_box>`,
* :doc:`create_box <create_box>`,
* :doc:`dimension <dimension>`,
* :doc:`lattice <lattice>`,
* :doc:`region <region>`
.. table_from_list::
:columns: 4
* :doc:`boundary <boundary>`
* :doc:`box <box>`
* :doc:`change_box <change_box>`
* :doc:`create_box <create_box>`
* :doc:`dimension <dimension>`
* :doc:`lattice <lattice>`
* :doc:`region <region>`
Setup atoms:
------------------------------
* :doc:`atom_modify <atom_modify>`,
* :doc:`atom_style <atom_style>`,
* :doc:`balance <balance>`,
* :doc:`create_atoms <create_atoms>`,
* :doc:`create_bonds <create_bonds>`,
* :doc:`delete_atoms <delete_atoms>`,
* :doc:`delete_bonds <delete_bonds>`,
* :doc:`displace_atoms <displace_atoms>`,
* :doc:`group <group>`,
* :doc:`mass <mass>`,
* :doc:`molecule <molecule>`,
* :doc:`read_data <read_data>`,
* :doc:`read_dump <read_dump>`,
* :doc:`read_restart <read_restart>`,
* :doc:`replicate <replicate>`,
* :doc:`set <set>`,
* :doc:`velocity <velocity>`
.. table_from_list::
:columns: 4
* :doc:`atom_modify <atom_modify>`
* :doc:`atom_style <atom_style>`
* :doc:`balance <balance>`
* :doc:`create_atoms <create_atoms>`
* :doc:`create_bonds <create_bonds>`
* :doc:`delete_atoms <delete_atoms>`
* :doc:`delete_bonds <delete_bonds>`
* :doc:`displace_atoms <displace_atoms>`
* :doc:`group <group>`
* :doc:`mass <mass>`
* :doc:`molecule <molecule>`
* :doc:`read_data <read_data>`
* :doc:`read_dump <read_dump>`
* :doc:`read_restart <read_restart>`
* :doc:`replicate <replicate>`
* :doc:`set <set>`
* :doc:`velocity <velocity>`
Force fields:
------------------------------
* :doc:`angle_coeff <angle_coeff>`,
* :doc:`angle_style <angle_style>`,
* :doc:`bond_coeff <bond_coeff>`,
* :doc:`bond_style <bond_style>`,
* :doc:`bond_write <bond_write>`,
* :doc:`dielectric <dielectric>`,
* :doc:`dihedral_coeff <dihedral_coeff>`,
* :doc:`dihedral_style <dihedral_style>`,
* :doc:`improper_coeff <improper_coeff>`,
* :doc:`improper_style <improper_style>`,
* :doc:`kspace_modify <kspace_modify>`,
* :doc:`kspace_style <kspace_style>`,
* :doc:`pair_coeff <pair_coeff>`,
* :doc:`pair_modify <pair_modify>`,
* :doc:`pair_style <pair_style>`,
* :doc:`pair_write <pair_write>`,
* :doc:`special_bonds <special_bonds>`
.. table_from_list::
:columns: 4
* :doc:`angle_coeff <angle_coeff>`
* :doc:`angle_style <angle_style>`
* :doc:`bond_coeff <bond_coeff>`
* :doc:`bond_style <bond_style>`
* :doc:`bond_write <bond_write>`
* :doc:`dielectric <dielectric>`
* :doc:`dihedral_coeff <dihedral_coeff>`
* :doc:`dihedral_style <dihedral_style>`
* :doc:`improper_coeff <improper_coeff>`
* :doc:`improper_style <improper_style>`
* :doc:`kspace_modify <kspace_modify>`
* :doc:`kspace_style <kspace_style>`
* :doc:`pair_coeff <pair_coeff>`
* :doc:`pair_modify <pair_modify>`
* :doc:`pair_style <pair_style>`
* :doc:`pair_write <pair_write>`
* :doc:`special_bonds <special_bonds>`
Settings:
------------------------------
* :doc:`comm_modify <comm_modify>`,
* :doc:`comm_style <comm_style>`,
* :doc:`info <info>`,
* :doc:`min_modify <min_modify>`,
* :doc:`min_style <min_style>`,
* :doc:`neigh_modify <neigh_modify>`,
* :doc:`neighbor <neighbor>`,
* :doc:`partition <partition>`,
* :doc:`reset_timestep <reset_timestep>`,
* :doc:`run_style <run_style>`,
* :doc:`timer <timer>`,
* :doc:`timestep <timestep>`
.. table_from_list::
:columns: 4
* :doc:`comm_modify <comm_modify>`
* :doc:`comm_style <comm_style>`
* :doc:`info <info>`
* :doc:`min_modify <min_modify>`
* :doc:`min_style <min_style>`
* :doc:`neigh_modify <neigh_modify>`
* :doc:`neighbor <neighbor>`
* :doc:`partition <partition>`
* :doc:`reset_timestep <reset_timestep>`
* :doc:`run_style <run_style>`
* :doc:`timer <timer>`
* :doc:`timestep <timestep>`
Operations within timestepping (fixes) and diagnostics (computes):
------------------------------------------------------------------------------------------
* :doc:`compute <compute>`,
* :doc:`compute_modify <compute_modify>`,
* :doc:`fix <fix>`,
* :doc:`fix_modify <fix_modify>`,
* :doc:`uncompute <uncompute>`,
* :doc:`unfix <unfix>`
.. table_from_list::
:columns: 4
* :doc:`compute <compute>`
* :doc:`compute_modify <compute_modify>`
* :doc:`fix <fix>`
* :doc:`fix_modify <fix_modify>`
* :doc:`uncompute <uncompute>`
* :doc:`unfix <unfix>`
Output:
------------------------------
* :doc:`dump image <dump_image>`,
* :doc:`dump movie <dump_image>`,
* :doc:`dump <dump>`,
* :doc:`dump_modify <dump_modify>`,
* :doc:`restart <restart>`,
* :doc:`thermo <thermo>`,
* :doc:`thermo_modify <thermo_modify>`,
* :doc:`thermo_style <thermo_style>`,
* :doc:`undump <undump>`,
* :doc:`write_coeff <write_coeff>`,
* :doc:`write_data <write_data>`,
* :doc:`write_dump <write_dump>`,
* :doc:`write_restart <write_restart>`
.. table_from_list::
:columns: 4
* :doc:`dump image <dump_image>`
* :doc:`dump movie <dump_image>`
* :doc:`dump <dump>`
* :doc:`dump_modify <dump_modify>`
* :doc:`restart <restart>`
* :doc:`thermo <thermo>`
* :doc:`thermo_modify <thermo_modify>`
* :doc:`thermo_style <thermo_style>`
* :doc:`undump <undump>`
* :doc:`write_coeff <write_coeff>`
* :doc:`write_data <write_data>`
* :doc:`write_dump <write_dump>`
* :doc:`write_restart <write_restart>`
Actions:
------------------------------
* :doc:`minimize <minimize>`,
* :doc:`neb <neb>`,
* :doc:`neb_spin <neb_spin>`,
* :doc:`prd <prd>`,
* :doc:`rerun <rerun>`,
* :doc:`run <run>`,
* :doc:`tad <tad>`,
* :doc:`temper <temper>`
.. table_from_list::
:columns: 6
* :doc:`minimize <minimize>`
* :doc:`neb <neb>`
* :doc:`neb_spin <neb_spin>`
* :doc:`prd <prd>`
* :doc:`rerun <rerun>`
* :doc:`run <run>`
* :doc:`tad <tad>`
* :doc:`temper <temper>`
Input script control:
------------------------------
* :doc:`clear <clear>`,
* :doc:`echo <echo>`,
* :doc:`if <if>`,
* :doc:`include <include>`,
* :doc:`jump <jump>`,
* :doc:`label <label>`,
* :doc:`log <log>`,
* :doc:`next <next>`,
* :doc:`print <print>`,
* :doc:`python <python>`,
* :doc:`quit <quit>`,
* :doc:`shell <shell>`,
* :doc:`variable <variable>`
.. table_from_list::
:columns: 7
* :doc:`clear <clear>`
* :doc:`echo <echo>`
* :doc:`if <if>`
* :doc:`include <include>`
* :doc:`info <info>`
* :doc:`jump <jump>`
* :doc:`label <label>`
* :doc:`log <log>`
* :doc:`next <next>`
* :doc:`print <print>`
* :doc:`python <python>`
* :doc:`quit <quit>`
* :doc:`shell <shell>`
* :doc:`variable <variable>`

17
doc/src/Commands_compute.rst
View File

@ -20,7 +20,7 @@ additional letters in parenthesis: g = GPU, i = USER-INTEL, k =
KOKKOS, o = USER-OMP, t = OPT.
.. table_from_list::
:columns: 6
:columns: 5
* :doc:`ackland/atom <compute_ackland_atom>`
* :doc:`adf <compute_adf>`
@ -42,7 +42,7 @@ KOKKOS, o = USER-OMP, t = OPT.
* :doc:`com <compute_com>`
* :doc:`com/chunk <compute_com_chunk>`
* :doc:`contact/atom <compute_contact_atom>`
* :doc:`coord/atom <compute_coord_atom>`
* :doc:`coord/atom (k) <compute_coord_atom>`
* :doc:`damage/atom <compute_damage_atom>`
* :doc:`dihedral <compute_dihedral>`
* :doc:`dihedral/local <compute_dihedral_local>`
@ -79,15 +79,14 @@ KOKKOS, o = USER-OMP, t = OPT.
* :doc:`ke/atom/eff <compute_ke_atom_eff>`
* :doc:`ke/eff <compute_ke_eff>`
* :doc:`ke/rigid <compute_ke_rigid>`
* :doc:`meso/e/atom <compute_meso_e_atom>`
* :doc:`meso/rho/atom <compute_meso_rho_atom>`
* :doc:`meso/t/atom <compute_meso_t_atom>`
* :doc:`mesont <compute_mesont>`
* :doc:`mliap <compute_mliap>`
* :doc:`momentum <compute_momentum>`
* :doc:`msd <compute_msd>`
* :doc:`msd/chunk <compute_msd_chunk>`
* :doc:`msd/nongauss <compute_msd_nongauss>`
* :doc:`omega/chunk <compute_omega_chunk>`
* :doc:`orientorder/atom <compute_orientorder_atom>`
* :doc:`orientorder/atom (k) <compute_orientorder_atom>`
* :doc:`pair <compute_pair>`
* :doc:`pair/local <compute_pair_local>`
* :doc:`pe <compute_pe>`
@ -124,6 +123,7 @@ KOKKOS, o = USER-OMP, t = OPT.
* :doc:`smd/tlsph/strain/rate <compute_smd_tlsph_strain_rate>`
* :doc:`smd/tlsph/stress <compute_smd_tlsph_stress>`
* :doc:`smd/triangle/vertices <compute_smd_triangle_vertices>`
* :doc:`smd/ulsph/effm <compute_smd_ulsph_effm>`
* :doc:`smd/ulsph/num/neighs <compute_smd_ulsph_num_neighs>`
* :doc:`smd/ulsph/strain <compute_smd_ulsph_strain>`
* :doc:`smd/ulsph/strain/rate <compute_smd_ulsph_strain_rate>`
@ -133,6 +133,9 @@ KOKKOS, o = USER-OMP, t = OPT.
* :doc:`sna/atom <compute_sna_atom>`
* :doc:`snad/atom <compute_sna_atom>`
* :doc:`snav/atom <compute_sna_atom>`
* :doc:`sph/e/atom <compute_sph_e_atom>`
* :doc:`sph/rho/atom <compute_sph_rho_atom>`
* :doc:`sph/t/atom <compute_sph_t_atom>`
* :doc:`spin <compute_spin>`
* :doc:`stress/atom <compute_stress_atom>`
* :doc:`stress/mop <compute_stress_mop>`
@ -161,6 +164,6 @@ KOKKOS, o = USER-OMP, t = OPT.
* :doc:`torque/chunk <compute_torque_chunk>`
* :doc:`vacf <compute_vacf>`
* :doc:`vcm/chunk <compute_vcm_chunk>`
* :doc:`viscosity/cos <compute_viscosity_cos>`
* :doc:`voronoi/atom <compute_voronoi_atom>`
* :doc:`xrd <compute_xrd>`

11
doc/src/Commands_fix.rst
View File

@ -20,8 +20,9 @@ parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
OPT.
.. table_from_list::
:columns: 6
:columns: 5
* :doc:`accelerate/cos <fix_accelerate_cos>`
* :doc:`adapt <fix_adapt>`
* :doc:`adapt/fep <fix_adapt_fep>`
* :doc:`addforce <fix_addforce>`
@ -41,6 +42,7 @@ OPT.
* :doc:`bocs <fix_bocs>`
* :doc:`bond/break <fix_bond_break>`
* :doc:`bond/create <fix_bond_create>`
* :doc:`bond/create/angle <fix_bond_create>`
* :doc:`bond/react <fix_bond_react>`
* :doc:`bond/swap <fix_bond_swap>`
* :doc:`box/relax <fix_box_relax>`
@ -94,9 +96,7 @@ OPT.
* :doc:`lb/viscous <fix_lb_viscous>`
* :doc:`lineforce <fix_lineforce>`
* :doc:`manifoldforce <fix_manifoldforce>`
* :doc:`meso <fix_meso>`
* :doc:`meso/move <fix_meso_move>`
* :doc:`meso/stationary <fix_meso_stationary>`
* :doc:`momentum (k) <fix_momentum>`
* :doc:`move <fix_move>`
* :doc:`mscg <fix_mscg>`
@ -119,6 +119,7 @@ OPT.
* :doc:`npt/eff <fix_nh_eff>`
* :doc:`npt/sphere (o) <fix_npt_sphere>`
* :doc:`npt/uef <fix_nh_uef>`
* :doc:`numdiff <fix_numdiff>`
* :doc:`nve (iko) <fix_nve>`
* :doc:`nve/asphere (i) <fix_nve_asphere>`
* :doc:`nve/asphere/noforce <fix_nve_asphere_noforce>`
@ -147,6 +148,7 @@ OPT.
* :doc:`oneway <fix_oneway>`
* :doc:`orient/bcc <fix_orient>`
* :doc:`orient/fcc <fix_orient>`
* :doc:`orient/eco <fix_orient_eco>`
* :doc:`phonon <fix_phonon>`
* :doc:`pimd <fix_pimd>`
* :doc:`planeforce <fix_planeforce>`
@ -200,6 +202,8 @@ OPT.
* :doc:`smd/move_tri_surf <fix_smd_move_triangulated_surface>`
* :doc:`smd/setvel <fix_smd_setvel>`
* :doc:`smd/wall_surface <fix_smd_wall_surface>`
* :doc:`sph <fix_sph>`
* :doc:`sph/stationary <fix_sph_stationary>`
* :doc:`spring <fix_spring>`
* :doc:`spring/chunk <fix_spring_chunk>`
* :doc:`spring/rg <fix_spring_rg>`
@ -240,3 +244,4 @@ OPT.
* :doc:`wall/region <fix_wall_region>`
* :doc:`wall/region/ees <fix_wall_ees>`
* :doc:`wall/srd <fix_wall_srd>`
* :doc:`widom <fix_widom>`

10
doc/src/Commands_input.rst
View File

@ -16,7 +16,6 @@ simulation with all the settings. Rather, the input script is read
one line at a time and each command takes effect when it is read.
Thus this sequence of commands:
.. code-block:: LAMMPS
timestep 0.5
@ -25,7 +24,6 @@ Thus this sequence of commands:
does something different than this sequence:
.. code-block:: LAMMPS
run 100
@ -33,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
@ -48,7 +46,7 @@ is to have the desired effect. For example, the
:doc:`read_data <read_data>` command initializes the system by setting
up the simulation box and assigning atoms to processors. If default
values are not desired, the :doc:`processors <processors>` and
:doc:`boundary <boundary>` commands need to be used before read\_data to
:doc:`boundary <boundary>` commands need to be used before read_data to
tell LAMMPS how to map processors to the simulation box.
Many input script errors are detected by LAMMPS and an ERROR or

40
doc/src/Commands_pair.rst
View File

@ -26,6 +26,10 @@ OPT.
* :doc:`zero <pair_zero>`
* :doc:`hybrid (k) <pair_hybrid>`
* :doc:`hybrid/overlay (k) <pair_hybrid>`
* :doc:`kim <pair_kim>`
* :doc:`list <pair_list>`
*
*
*
*
*
@ -73,6 +77,8 @@ OPT.
* :doc:`coul/long/cs (g) <pair_cs>`
* :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/shield <pair_coul_shield>`
* :doc:`coul/streitz <pair_coul>`
* :doc:`coul/wolf (ko) <pair_coul>`
@ -86,12 +92,12 @@ OPT.
* :doc:`drip <pair_drip>`
* :doc:`eam (gikot) <pair_eam>`
* :doc:`eam/alloy (gikot) <pair_eam>`
* :doc:`eam/cd (o) <pair_eam>`
* :doc:`eam/cd/old (o) <pair_eam>`
* :doc:`eam/cd <pair_eam>`
* :doc:`eam/cd/old <pair_eam>`
* :doc:`eam/fs (gikot) <pair_eam>`
* :doc:`edip (o) <pair_edip>`
* :doc:`edip/multi <pair_edip>`
* :doc:`edpd <pair_meso>`
* :doc:`edpd <pair_mesodpd>`
* :doc:`eff/cut <pair_eff>`
* :doc:`eim (o) <pair_eim>`
* :doc:`exp6/rx (k) <pair_exp6_rx>`
@ -108,14 +114,12 @@ OPT.
* :doc:`hbond/dreiding/lj (o) <pair_hbond_dreiding>`
* :doc:`hbond/dreiding/morse (o) <pair_hbond_dreiding>`
* :doc:`ilp/graphene/hbn <pair_ilp_graphene_hbn>`
* :doc:`kim <pair_kim>`
* :doc:`kolmogorov/crespi/full <pair_kolmogorov_crespi_full>`
* :doc:`kolmogorov/crespi/z <pair_kolmogorov_crespi_z>`
* :doc:`lcbop <pair_lcbop>`
* :doc:`lebedeva/z <pair_lebedeva_z>`
* :doc:`lennard/mdf <pair_mdf>`
* :doc:`line/lj <pair_line_lj>`
* :doc:`list <pair_list>`
* :doc:`lj/charmm/coul/charmm (iko) <pair_charmm>`
* :doc:`lj/charmm/coul/charmm/implicit (ko) <pair_charmm>`
* :doc:`lj/charmm/coul/long (gikot) <pair_charmm>`
@ -127,26 +131,27 @@ OPT.
* :doc:`lj/class2/coul/cut (ko) <pair_class2>`
* :doc:`lj/class2/coul/cut/soft <pair_fep_soft>`
* :doc:`lj/class2/coul/long (gko) <pair_class2>`
* :doc:`lj/class2/coul/long/cs <pair_cs>`
* :doc:`lj/class2/coul/long/soft <pair_fep_soft>`
* :doc:`lj/class2/soft <pair_fep_soft>`
* :doc:`lj/cubic (go) <pair_lj_cubic>`
* :doc:`lj/cut (gikot) <pair_lj>`
* :doc:`lj/cut/coul/cut (gko) <pair_lj>`
* :doc:`lj/cut/coul/cut (gko) <pair_lj_cut_coul>`
* :doc:`lj/cut/coul/cut/soft (o) <pair_fep_soft>`
* :doc:`lj/cut/coul/debye (gko) <pair_lj>`
* :doc:`lj/cut/coul/dsf (gko) <pair_lj>`
* :doc:`lj/cut/coul/long (gikot) <pair_lj>`
* :doc:`lj/cut/coul/debye (gko) <pair_lj_cut_coul>`
* :doc:`lj/cut/coul/dsf (gko) <pair_lj_cut_coul>`
* :doc:`lj/cut/coul/long (gikot) <pair_lj_cut_coul>`
* :doc:`lj/cut/coul/long/cs <pair_cs>`
* :doc:`lj/cut/coul/long/soft (o) <pair_fep_soft>`
* :doc:`lj/cut/coul/msm (go) <pair_lj>`
* :doc:`lj/cut/coul/wolf (o) <pair_lj>`
* :doc:`lj/cut/coul/msm (go) <pair_lj_cut_coul>`
* :doc:`lj/cut/coul/wolf (o) <pair_lj_cut_coul>`
* :doc:`lj/cut/dipole/cut (go) <pair_dipole>`
* :doc:`lj/cut/dipole/long (g) <pair_dipole>`
* :doc:`lj/cut/dipole/sf (go) <pair_dipole>`
* :doc:`lj/cut/soft (o) <pair_fep_soft>`
* :doc:`lj/cut/thole/long (o) <pair_thole>`
* :doc:`lj/cut/tip4p/cut (o) <pair_lj>`
* :doc:`lj/cut/tip4p/long (got) <pair_lj>`
* :doc:`lj/cut/tip4p/cut (o) <pair_lj_cut_tip4p>`
* :doc:`lj/cut/tip4p/long (got) <pair_lj_cut_tip4p>`
* :doc:`lj/cut/tip4p/long/soft (o) <pair_fep_soft>`
* :doc:`lj/expand (gko) <pair_lj_expand>`
* :doc:`lj/expand/coul/long (g) <pair_lj_expand>`
@ -169,14 +174,16 @@ OPT.
* :doc:`lubricate/poly (o) <pair_lubricate>`
* :doc:`lubricateU <pair_lubricateU>`
* :doc:`lubricateU/poly <pair_lubricateU>`
* :doc:`mdpd <pair_meso>`
* :doc:`mdpd/rhosum <pair_meso>`
* :doc:`mdpd <pair_mesodpd>`
* :doc:`mdpd/rhosum <pair_mesodpd>`
* :doc:`meam/c <pair_meamc>`
* :doc:`meam/spline (o) <pair_meam_spline>`
* :doc:`meam/sw/spline <pair_meam_sw_spline>`
* :doc:`mesocnt <pair_mesocnt>`
* :doc:`mesont/tpm <pair_mesont_tpm>`
* :doc:`mgpt <pair_mgpt>`
* :doc:`mie/cut (g) <pair_mie>`
* :doc:`mliap <pair_mliap>`
* :doc:`mm3/switch3/coulgauss/long <pair_mm3_switch3_coulgauss_long>`
* :doc:`momb <pair_momb>`
* :doc:`morse (gkot) <pair_morse>`
@ -222,7 +229,6 @@ OPT.
* :doc:`smd/ulsph <pair_smd_ulsph>`
* :doc:`smtbq <pair_smtbq>`
* :doc:`snap (k) <pair_snap>`
* :doc:`snap (k) <pair_snap>`
* :doc:`soft (go) <pair_soft>`
* :doc:`sph/heatconduction <pair_sph_heatconduction>`
* :doc:`sph/idealgas <pair_sph_idealgas>`
@ -240,7 +246,7 @@ OPT.
* :doc:`sw (giko) <pair_sw>`
* :doc:`table (gko) <pair_table>`
* :doc:`table/rx (k) <pair_table_rx>`
* :doc:`tdpd <pair_meso>`
* :doc:`tdpd <pair_mesodpd>`
* :doc:`tersoff (giko) <pair_tersoff>`
* :doc:`tersoff/mod (gko) <pair_tersoff_mod>`
* :doc:`tersoff/mod/c (o) <pair_tersoff_mod>`

200
doc/src/Commands_parse.rst
View File

@ -9,134 +9,150 @@ file names or user-chosen ID strings.
Here are 6 rules for how each line in the input script is parsed by
LAMMPS:
(1) If the last printable character on the line is a "&" character,
the command is assumed to continue on the next line. The next line is
concatenated to the previous line by removing the "&" character and
line break. This allows long commands to be continued across two or
more lines. See the discussion of triple quotes in (6) for how to
continue a command across multiple line without using "&" characters.
.. _one:
(2) All characters from the first "#" character onward are treated as
comment and discarded. See an exception in (6). Note that a
comment after a trailing "&" character will prevent the command from
continuing on the next line. Also note that for multi-line commands a
single leading "#" will comment out the entire command.
1. If the last printable character on the line is a "&" character, the
command is assumed to continue on the next line. The next line is
concatenated to the previous line by removing the "&" character and
line break. This allows long commands to be continued across two or
more lines. See the discussion of triple quotes in :ref:`6 <six>`
for how to continue a command across multiple line without using "&"
characters.
.. code-block:: LAMMPS
.. _two:
# this is a comment
2. All characters from the first "#" character onward are treated as
comment and discarded. The exception to this rule is described in
:ref:`6 <six>`. Note that a comment after a trailing "&" character
will prevent the command from continuing on the next line. Also note
that for multi-line commands a single leading "#" will comment out
the entire command.
(3) The line is searched repeatedly for $ characters, which indicate
variables that are replaced with a text string. See an exception in
(6).
.. code-block:: LAMMPS
If the $ is followed by curly brackets, then the variable name is the
text inside the curly brackets. If no curly brackets follow the $,
then the variable name is the single character immediately following
the $. Thus ${myTemp} and $x refer to variable names "myTemp" and
"x".
# this is a comment
timestep 1.0 # this is also a comment
How the variable is converted to a text string depends on what style
of variable it is; see the :doc:`variable <variable>` doc page for details.
It can be a variable that stores multiple text strings, and return one
of them. The returned text string can be multiple "words" (space
separated) which will then be interpreted as multiple arguments in the
input command. The variable can also store a numeric formula which
will be evaluated and its numeric result returned as a string.
.. _three:
As a special case, if the $ is followed by parenthesis, then the text
inside the parenthesis is treated as an "immediate" variable and
evaluated as an :doc:`equal-style variable <variable>`. This is a way
to use numeric formulas in an input script without having to assign
them to variable names. For example, these 3 input script lines:
3. The line is searched repeatedly for $ characters, which indicate
variables that are replaced with a text string. The exception to
this rule is described in :ref:`6 <six>`.
If the $ is followed by text in curly brackets '{}', then the
variable name is the text inside the curly brackets. If no curly
brackets follow the $, then the variable name is the single character
immediately following the $. Thus ${myTemp} and $x refer to variables
named "myTemp" and "x", while "$xx" will be interpreted as a variable
named "x" followed by an "x" character.
.. code-block:: LAMMPS
How the variable is converted to a text string depends on what style
of variable it is; see the :doc:`variable <variable>` doc page for
details. It can be a variable that stores multiple text strings, and
return one of them. The returned text string can be multiple "words"
(space separated) which will then be interpreted as multiple
arguments in the input command. The variable can also store a
numeric formula which will be evaluated and its numeric result
returned as a string.
variable X equal (xlo+xhi)/2+sqrt(v_area)
region 1 block $X 2 INF INF EDGE EDGE
variable X delete
As a special case, if the $ is followed by parenthesis "()", then the
text inside the parenthesis is treated as an "immediate" variable and
evaluated as an :doc:`equal-style variable <variable>`. This is a
way to use numeric formulas in an input script without having to
assign them to variable names. For example, these 3 input script
lines:
can be replaced by
.. code-block:: LAMMPS
variable X equal (xlo+xhi)/2+sqrt(v_area)
region 1 block $X 2 INF INF EDGE EDGE
variable X delete
.. code-block:: LAMMPS
can be replaced by:
region 1 block $((xlo+xhi)/2+sqrt(v_area)) 2 INF INF EDGE EDGE
.. code-block:: LAMMPS
so that you do not have to define (or discard) a temporary variable X.
region 1 block $((xlo+xhi)/2+sqrt(v_area)) 2 INF INF EDGE EDGE
Additionally, the "immediate" variable expression may be followed by a
colon, followed by a C-style format string, e.g. ":%f" or ":%.10g".
The format string must be appropriate for a double-precision
floating-point value. The format string is used to output the result
of the variable expression evaluation. If a format string is not
specified a high-precision "%.20g" is used as the default.
so that you do not have to define (or discard) a temporary variable,
"X" in this case.
This can be useful for formatting print output to a desired precision:
Additionally, the "immediate" variable expression may be followed by
a colon, followed by a C-style format string, e.g. ":%f" or ":%.10g".
The format string must be appropriate for a double-precision
floating-point value. The format string is used to output the result
of the variable expression evaluation. If a format string is not
specified a high-precision "%.20g" is used as the default.
This can be useful for formatting print output to a desired precision:
.. code-block:: LAMMPS
.. code-block:: LAMMPS
print "Final energy per atom: $(pe/atoms:%10.3f) eV/atom"
print "Final energy per atom: $(pe/atoms:%10.3f) eV/atom"
Note that neither the curly-bracket or immediate form of variables can
contain nested $ characters for other variables to substitute for.
Thus you cannot do this:
Note that neither the curly-bracket or immediate form of variables
can contain nested $ characters for other variables to substitute
for. Thus you may **NOT** do this:
.. code-block:: LAMMPS
.. code-block:: LAMMPS
variable a equal 2
variable b2 equal 4
print "B2 = ${b$a}"
variable a equal 2
variable b2 equal 4
print "B2 = ${b$a}"
Nor can you specify an expression like "$($x-1.0)" for an immediate
variable, but you could use $(v_x-1.0), since the latter is valid
syntax for an :doc:`equal-style variable <variable>`.
Nor can you specify this $($x-1.0) for an immediate variable, but
you could use $(v\_x-1.0), since the latter is valid syntax for an
:doc:`equal-style variable <variable>`.
See the :doc:`variable <variable>` command for more details of how
strings are assigned to variables and evaluated, and how they can
be used in input script commands.
See the :doc:`variable <variable>` command for more details of how
strings are assigned to variables and evaluated, and how they can be
used in input script commands.
.. _four:
(4) The line is broken into "words" separated by white-space (tabs,
spaces). Note that words can thus contain letters, digits,
underscores, or punctuation characters.
4. The line is broken into "words" separated by white-space (tabs,
spaces). Note that words can thus contain letters, digits,
underscores, or punctuation characters.
(5) The first word is the command name. All successive words in the
line are arguments.
.. _five:
(6) If you want text with spaces to be treated as a single argument,
it can be enclosed in either single or double or triple quotes. A
long single argument enclosed in single or double quotes can span
multiple lines if the "&" character is used, as described above. When
the lines are concatenated together (and the "&" characters and line
breaks removed), the text will become a single line. If you want
multiple lines of an argument to retain their line breaks, the text
can be enclosed in triple quotes, in which case "&" characters are not
needed. For example:
5. The first word is the command name. All successive words in the line
are arguments.
.. _six:
.. code-block:: LAMMPS
6. If you want text with spaces to be treated as a single argument, it
can be enclosed in either single or double or triple quotes. A long
single argument enclosed in single or double quotes can span multiple
lines if the "&" character is used, as described above. When the
lines are concatenated together (and the "&" characters and line
breaks removed), the text will become a single line. If you want
multiple lines of an argument to retain their line breaks, the text
can be enclosed in triple quotes, in which case "&" characters are
not needed. For example:
print "Volume = $v"
print 'Volume = $v'
if "${steps} > 1000" then quit
variable a string "red green blue &
.. code-block:: LAMMPS
print "Volume = $v"
print 'Volume = $v'
if "${steps} > 1000" then quit
variable a string "red green blue &
purple orange cyan"
print """
System volume = $v
System temperature = $t
"""
print """
System volume = $v
System temperature = $t
"""
In each case, the single, double, or triple quotes are removed when
the single argument they enclose is stored internally.
In each case, the single, double, or triple quotes are removed when
the single argument they enclose is stored internally.
See the :doc:`dump modify format <dump_modify>`, :doc:`print <print>`,
:doc:`if <if>`, and :doc:`python <python>` commands for examples.
See the :doc:`dump modify format <dump_modify>`, :doc:`print
<print>`, :doc:`if <if>`, and :doc:`python <python>` commands for
examples.
A "#" or "$" character that is between quotes will not be treated as a
comment indicator in (2) or substituted for as a variable in (3).
A "#" or "$" character that is between quotes will not be treated as
a comment indicator in :ref:`2 <two>` or substituted for as a
variable in :ref:`3 <three>`.
.. note::

7
doc/src/Commands_removed.rst
View File

@ -48,7 +48,7 @@ The USER-CUDA package had been removed, since it had been unmaintained
for a long time and had known bugs and problems. Significant parts of
the design were transferred to the
:ref:`KOKKOS package <PKG-KOKKOS>`, which has similar
performance characteristics on Nvidia GPUs. Both, the KOKKOS
performance characteristics on NVIDIA GPUs. Both, the KOKKOS
and the :ref:`GPU package <PKG-GPU>` are maintained
and allow running LAMMPS with GPU acceleration.
@ -60,8 +60,3 @@ LAMMPS executable directly instead of having a separate tool. A
combination of the commands :doc:`read_restart <read_restart>` and
:doc:`write_data <write_data>` can be used to the same effect. For added
convenience this conversion can also be triggered by :doc:`command line flags <Run_options>`
.. _lws: http://lammps.sandia.gov
.. _ld: Manual.html
.. _lc: Commands_all.html

52
doc/src/Commands_structure.rst
View File

@ -8,17 +8,20 @@ page.
A LAMMPS input script typically has 4 parts:
1. Initialization
2. Atom definition
3. Settings
4. Run a simulation
1. :ref:`Initialization <init>`
2. :ref:`System definition <system>`
3. :ref:`Simulation settings <settings>`
4. :ref:`Run a simulation <run>`
The last 2 parts can be repeated as many times as desired. I.e. run a
simulation, change some settings, run some more, etc. Each of the 4
parts is now described in more detail. Remember that almost all
commands need only be used if a non-default value is desired.
(1) Initialization
.. _init:
Initialization
------------------------------
Set parameters that need to be defined before atoms are created or
read-in from a file.
@ -34,23 +37,33 @@ commands tell LAMMPS what kinds of force fields are being used:
:doc:`angle_style <angle_style>`, :doc:`dihedral_style <dihedral_style>`,
:doc:`improper_style <improper_style>`.
(2) Atom definition
.. _system:
There are 3 ways to define atoms in LAMMPS. Read them in from a data
or restart file via the :doc:`read_data <read_data>` or
:doc:`read_restart <read_restart>` commands. These files can contain
molecular topology information. Or create atoms on a lattice (with no
molecular topology), using these commands: :doc:`lattice <lattice>`,
:doc:`region <region>`, :doc:`create_box <create_box>`,
:doc:`create_atoms <create_atoms>`. The entire set of atoms can be
duplicated to make a larger simulation using the
:doc:`replicate <replicate>` command.
System definition
------------------------------
(3) Settings
There are 3 ways to define the simulation cell and reserve space for
force field info and fill it with atoms in LAMMPS. Read them in from
(1) a data file or (2) a restart file via the :doc:`read_data
<read_data>` or :doc:`read_restart <read_restart>` commands,
respectively. These files can also contain molecular topology
information. Or (3) create a simulation cell and fill it with atoms on
a lattice (with no molecular topology), using these commands:
:doc:`lattice <lattice>`, :doc:`region <region>`, :doc:`create_box
<create_box>`, :doc:`create_atoms <create_atoms>` or
:doc:`read_dump <read_dump>`.
The entire set of atoms can be duplicated to make a larger simulation
using the :doc:`replicate <replicate>` command.
.. _settings:
Simulation settings
------------------------------
Once atoms and molecular topology are defined, a variety of settings
can be specified: force field coefficients, simulation parameters,
output options, etc.
output options, and more.
Force field coefficients are set by these commands (they can also be
set in the read-in files): :doc:`pair_coeff <pair_coeff>`,
@ -77,7 +90,10 @@ commands.
Output options are set by the :doc:`thermo <thermo>`, :doc:`dump <dump>`,
and :doc:`restart <restart>` commands.
(4) Run a simulation
.. _run:
Run a simulation
------------------------------
A molecular dynamics simulation is run using the :doc:`run <run>`
command. Energy minimization (molecular statics) is performed using

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

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

BIN
doc/src/Eqs/angle_class2_p6.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 14 KiB

15
doc/src/Eqs/angle_class2_p6.tex
View File

@ -1,15 +0,0 @@
\documentclass[12pt]{article}
\pagestyle{empty}
\begin{document}
$$
E_{a} = K_2\left(\theta - \theta_0\right)^2 + K_3\left(\theta - \theta_0\right)^3 + K_4\left(\theta - \theta_0\right)^4 + K_5\left(\theta - \theta_0\right)^5 + K_6\left(\theta - \theta_0\right)^6
$$
\end{document}
%%% Local Variables:
%%% mode: latex
%%% TeX-master: t
%%% End:

BIN
doc/src/Eqs/box.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 11 KiB

14
doc/src/Eqs/box.tex
View File

@ -1,14 +0,0 @@
\documentclass[12pt]{article}
\begin{document}
\begin{eqnarray*}
a &=& {\rm lx} \\
b^2 &=& {\rm ly}^2 + {\rm xy}^2 \\
c^2 &=& {\rm lz}^2 + {\rm xz}^2 + {\rm yz}^2 \\
\cos{\alpha} &=& \frac{{\rm xy}*{\rm xz} + {\rm ly}*{\rm yz}}{b*c} \\
\cos{\beta} &=& \frac{\rm xz}{c} \\
\cos{\gamma} &=& \frac{\rm xy}{b} \\
\end{eqnarray*}
\end{document}

BIN
doc/src/Eqs/box_inverse.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 10 KiB

14
doc/src/Eqs/box_inverse.tex
View File

@ -1,14 +0,0 @@
\documentclass[12pt]{article}
\begin{document}
\begin{eqnarray*}
{\rm lx} &=& a \\
{\rm xy} &=& b \cos{\gamma} \\
{\rm xz} &=& c \cos{\beta}\\
{\rm ly}^2 &=& b^2 - {\rm xy}^2 \\
{\rm yz} &=& \frac{b*c \cos{\alpha} - {\rm xy}*{\rm xz}}{\rm ly} \\
{\rm lz}^2 &=& c^2 - {\rm xz}^2 - {\rm yz}^2 \\
\end{eqnarray*}
\end{document}

BIN
doc/src/Eqs/centro_symmetry.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 4.0 KiB

9
doc/src/Eqs/centro_symmetry.tex
View File

@ -1,9 +0,0 @@
\documentclass[12pt]{article}
\begin{document}
$$
CS = \sum_{i = 1}^{N/2} | \vec{R}_i + \vec{R}_{i+N/2} |^2
$$
\end{document}

BIN
doc/src/Eqs/cna_cutoff1.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 13 KiB

14
doc/src/Eqs/cna_cutoff1.tex
View File

@ -1,14 +0,0 @@
\documentclass[12pt,article]{article}
\usepackage{indentfirst}
\usepackage{amsmath}
\begin{document}
\begin{eqnarray*}
r_{c}^{fcc} & = & \frac{1}{2} \left(\frac{\sqrt{2}}{2} + 1\right) \mathrm{a} \simeq 0.8536 \:\mathrm{a} \\
r_{c}^{bcc} & = & \frac{1}{2}(\sqrt{2} + 1) \mathrm{a} \simeq 1.207 \:\mathrm{a} \\
r_{c}^{hcp} & = & \frac{1}{2}\left(1+\sqrt{\frac{4+2x^{2}}{3}}\right) \mathrm{a}
\end{eqnarray*}
\end{document}

BIN
doc/src/Eqs/cna_cutoff2.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 2.5 KiB

12
doc/src/Eqs/cna_cutoff2.tex
View File

@ -1,12 +0,0 @@
\documentclass[12pt,article]{article}
\usepackage{indentfirst}
\usepackage{amsmath}
\begin{document}
$$
Rc + Rs > 2*{\rm cutoff}
$$
\end{document}

BIN
doc/src/Eqs/cnp_cutoff.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 13 KiB

14
doc/src/Eqs/cnp_cutoff.tex
View File

@ -1,14 +0,0 @@
\documentclass[12pt,article]{article}
\usepackage{indentfirst}
\usepackage{amsmath}
\begin{document}
\begin{eqnarray*}
r_{c}^{fcc} & = & \frac{1}{2} \left(\frac{\sqrt{2}}{2} + 1\right) \mathrm{a} \simeq 0.8536 \:\mathrm{a} \\
r_{c}^{bcc} & = & \frac{1}{2}(\sqrt{2} + 1) \mathrm{a} \simeq 1.207 \:\mathrm{a} \\
r_{c}^{hcp} & = & \frac{1}{2}\left(1+\sqrt{\frac{4+2x^{2}}{3}}\right) \mathrm{a}
\end{eqnarray*}
\end{document}

BIN
doc/src/Eqs/cnp_cutoff2.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 2.5 KiB

12
doc/src/Eqs/cnp_cutoff2.tex
View File

@ -1,12 +0,0 @@
\documentclass[12pt,article]{article}
\usepackage{indentfirst}
\usepackage{amsmath}
\begin{document}
$$
Rc + Rs > 2*{\rm cutoff}
$$
\end{document}

BIN
doc/src/Eqs/cnp_eq.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 23 KiB

9
doc/src/Eqs/cnp_eq.tex
View File

@ -1,9 +0,0 @@
\documentclass[12pt]{article}
\begin{document}
$$
Q_{i} = \frac{1}{n_i}\sum_{j = 1}^{n_i} | \sum_{k = 1}^{n_{ij}} \vec{R}_{ik} + \vec{R}_{jk} |^2
$$
\end{document}

BIN
doc/src/Eqs/compute_dpd.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 21 KiB

13
doc/src/Eqs/compute_dpd.tex
View File

@ -1,13 +0,0 @@
\documentstyle[12pt]{article}
\pagestyle{empty}
\begin{document}
\begin{eqnarray*}
U^{cond} = \displaystyle\sum_{i=1}^{N} u_{i}^{cond} \\
U^{mech} = \displaystyle\sum_{i=1}^{N} u_{i}^{mech} \\
U^{chem} = \displaystyle\sum_{i=1}^{N} u_{i}^{chem} \\
U = \displaystyle\sum_{i=1}^{N} (u_{i}^{cond} + u_{i}^{mech} + u_{i}^{chem}) \\
\theta_{avg} = (\frac{1}{N}\displaystyle\sum_{i=1}^{N} \frac{1}{\theta_{i}})^{-1} \\
\end{eqnarray*}
\end{document}

BIN
doc/src/Eqs/compute_fep_bar.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 18 KiB

7
doc/src/Eqs/compute_fep_bar.tex
View File

@ -1,7 +0,0 @@
\documentstyle[12pt]{article}
\begin{document}
\[ \left< \frac{1}{1 + \exp\left[\left(U_1 - U_0 - \Delta_0^1A \right) /kT \right]} \right>_0 = \left< \frac{1}{1 + \exp\left[\left(U_0 - U_1 + \Delta_0^1A \right) /kT \right]} \right>_1 \]
\end{document}

BIN
doc/src/Eqs/compute_fep_fdti.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 15 KiB

10
doc/src/Eqs/compute_fep_fdti.tex
View File

@ -1,10 +0,0 @@
\documentstyle[12pt]{article}
\begin{document}
\[ \Delta_0^1 A = \int_{\lambda=0}^{\lambda=1} \left( \frac{\partial
A(\lambda)}{\partial\lambda} \right)_\lambda \mathrm{d}\lambda
\approx \sum_{i=0}^{n-1} w_i \frac{A(\lambda_{i} + \delta) -
A(\lambda_i)}{\delta} \]
\end{document}

BIN
doc/src/Eqs/compute_fep_fep.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 18 KiB

9
doc/src/Eqs/compute_fep_fep.tex
View File

@ -1,9 +0,0 @@
\documentstyle[12pt]{article}
\begin{document}
\[ \Delta_0^1 A = \sum_{i=0}^{n-1} \Delta_{\lambda_i}^{\lambda_{i+1}} A =
- kT \sum_{i=0}^{n-1} \ln \left< \exp \left( - \frac{U(\lambda_{i+1}) -
U(\lambda_i)}{kT} \right) \right>_{\lambda_i} \]
\end{document}

BIN
doc/src/Eqs/compute_fep_lambda.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 10 KiB

10
doc/src/Eqs/compute_fep_lambda.tex
View File

@ -1,10 +0,0 @@
\documentstyle[12pt]{article}
\begin{document}
\begin{eqnarray*}
\lambda = 0 \quad\Rightarrow\quad U = U_{\mathrm{bg}} + U_0 \\
\lambda = 1 \quad\Rightarrow\quad U = U_{\mathrm{bg}} + U_1
\end{eqnarray*}
\end{document}

BIN
doc/src/Eqs/compute_fep_ti.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 18 KiB

10
doc/src/Eqs/compute_fep_ti.tex
View File

@ -1,10 +0,0 @@
\documentstyle[12pt]{article}
\begin{document}
\[ \Delta_0^1 A = \int_{\lambda=0}^{\lambda=1} \left< \frac{\partial
U(\lambda)}{\partial\lambda} \right>_\lambda \mathrm{d}\lambda
\approx \sum_{i=0}^{n-1} w_i \left< \frac{U(\lambda_{i} + \delta) -
U(\lambda_i)}{\delta} \right>_{\lambda_i} \]
\end{document}

BIN
doc/src/Eqs/compute_fep_u.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 9.1 KiB

7
doc/src/Eqs/compute_fep_u.tex
View File

@ -1,7 +0,0 @@
\documentstyle[12pt]{article}
\begin{document}
\[ U(\lambda) = U_{\mathrm{bg}} + U_1(\lambda) + U_0(\lambda) \]
\end{document}

BIN
doc/src/Eqs/compute_fep_vol.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 15 KiB

9
doc/src/Eqs/compute_fep_vol.tex
View File

@ -1,9 +0,0 @@
\documentstyle[12pt]{article}
\begin{document}
\[ \Delta_0^1 A = - kT \sum_{i=0}^{n-1} \ln \frac{\left< V \exp \left( -
\frac{U(\lambda_{i+1}) - U(\lambda_i)}{kT} \right)
\right>_{\lambda_i}}{\left< V \right>_{\lambda_i}} \]
\end{document}

BIN
doc/src/Eqs/compute_gyration.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 3.6 KiB

9
doc/src/Eqs/compute_gyration.tex
View File

@ -1,9 +0,0 @@
\documentstyle[12pt]{article}
\begin{document}
$$
{R_g}^2 = \frac{1}{M} \sum_i m_i (r_i - r_{cm})^2
$$
\end{document}

BIN
doc/src/Eqs/compute_msd_nongauss.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 7.1 KiB

9
doc/src/Eqs/compute_msd_nongauss.tex
View File

@ -1,9 +0,0 @@
\documentstyle[12pt]{article}
\begin{document}
$$
NGP(t) = 3<(r(t)-r(0))^4>/(5<(r(t)-r(0))^2>^2) - 1
$$
\end{document}

BIN
doc/src/Eqs/compute_saed1.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 1.4 KiB

10
doc/src/Eqs/compute_saed1.tex
View File

@ -1,10 +0,0 @@
\documentstyle[12pt]{article}
\begin{document}
$$
I=\frac{F^{*}F}{N}
$$
\end{document}

BIN
doc/src/Eqs/compute_saed2.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 4.8 KiB

9
doc/src/Eqs/compute_saed2.tex
View File

@ -1,9 +0,0 @@
\documentstyle[12pt]{article}
\begin{document}
$$
F(\mathbf{k})=\sum_{j=1}^{N}f_j(\theta)exp(2\pi i \mathbf{k}\cdot \mathbf{r}_j)
$$
\end{document}

BIN
doc/src/Eqs/compute_saed3.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 6.9 KiB

10
doc/src/Eqs/compute_saed3.tex
View File

@ -1,10 +0,0 @@
\documentstyle[12pt]{article}
\begin{document}
$$
f_j\left ( \frac{sin(\theta)}{\lambda} \right )=\sum_{i}^{5}
a_i exp\left ( -b_i \frac{sin^{2}(\theta)}{\lambda^{2}} \right )
$$
\end{document}

BIN
doc/src/Eqs/compute_shape_parameters.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 6.8 KiB

13
doc/src/Eqs/compute_shape_parameters.tex
View File

@ -1,13 +0,0 @@
\documentclass[12pt]{article}
\pagestyle{empty}
\begin{document}
\begin{eqnarray*}
c = l_z - 0.5(l_y+l_x) \\
b = l_y - l_x \\
k = \frac{3}{2} \frac{l_x^2+l_y^2+l_z^2}{(l_x+l_y+l_z)^2} - \frac{1}{2}
\end{eqnarray*}
\end{document}

BIN
doc/src/Eqs/compute_sna_atom1.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 19 KiB

11
doc/src/Eqs/compute_sna_atom1.tex
View File

@ -1,11 +0,0 @@
\documentclass[24pt]{article}
\pagestyle{empty}
\begin{document}
\begin{eqnarray*}
\theta_0 = {\tt rfac0} \frac{r-r_{min0}}{R_{ii'}-r_{min0}} \pi
\end{eqnarray*}
\end{document}

BIN
doc/src/Eqs/compute_sna_atom2.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 17 KiB

11
doc/src/Eqs/compute_sna_atom2.tex
View File

@ -1,11 +0,0 @@
\documentclass[24pt]{article}
\pagestyle{empty}
\begin{document}
\begin{eqnarray*}
u^j_{m,m'} = U^j_{m,m'}(0,0,0) + \sum_{r_{ii'} < R_{ii'}}{f_c(r_{ii'}) w_{i'} U^j_{m,m'}(\theta_0,\theta,\phi)}
\end{eqnarray*}
\end{document}

BIN
doc/src/Eqs/compute_sna_atom3.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 19 KiB

16
doc/src/Eqs/compute_sna_atom3.tex
View File

@ -1,16 +0,0 @@
\documentclass[24pt]{article}
\pagestyle{empty}
\begin{document}
\newcommand{\hcoeff}[9]{H\!\!{\tiny\begin{array}{l}#1 #2 #3 \\ #4 #5 #6 \\ #7 #8 #9 \end{array}}}
\begin{equation}
B_{j_1,j_2,j} = \\
\sum_{m_1,m'_1=-j_1}^{j_1}\sum_{m_2,m'_2=-j_2}^{j_2}\sum_{m,m'=-j}^{j} (u^j_{m,m'})^*
\hcoeff{j}{m}{m'}{j_1}{\!m_1}{\!m'_1}{j_2}{m_2}{m'_2}
u^{j_1}_{m_1,m'_1} u^{j_2}_{m_2,m'_2}
\end{equation}
\end{document}

BIN
doc/src/Eqs/compute_sna_atom4.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 35 KiB

14
doc/src/Eqs/compute_sna_atom4.tex
View File

@ -1,14 +0,0 @@
\documentclass[24pt]{article}
\pagestyle{empty}
\begin{document}
\begin{eqnarray*}
\label{eqn:f_c}
f_c(r) & = & \frac{1}{2}(\cos(\pi \frac{r-r_{min0}}{R_{ii'}-r_{min0}}) + 1), r \leq R_{ii'} \\
& = & 0, r > R_{ii'}
\end{eqnarray*}
\end{document}

BIN
doc/src/Eqs/compute_sna_atom5.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 14 KiB

12
doc/src/Eqs/compute_sna_atom5.tex
View File

@ -1,12 +0,0 @@
\documentclass[24pt]{article}
\pagestyle{empty}
\begin{document}
\begin{equation}
- \sum_{i' \in I} \frac{\partial {B^{i'}_{j_1,j_2,j} }}{\partial {\bf r}_i}
\end{equation}
\end{document}

BIN
doc/src/Eqs/compute_sna_atom6.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 17 KiB

12
doc/src/Eqs/compute_sna_atom6.tex
View File

@ -1,12 +0,0 @@
\documentclass[24pt]{article}
\pagestyle{empty}
\begin{document}
\begin{eqnarray*}
- {\bf r}_i \otimes \sum_{i' \in I} \frac{\partial {B^{i'}_{j_1,j_2,j}}}{\partial {\bf r}_i}
\end{eqnarray*}
\end{document}

BIN
doc/src/Eqs/compute_xrd1.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 2.3 KiB

10
doc/src/Eqs/compute_xrd1.tex
View File

@ -1,10 +0,0 @@
\documentstyle[12pt]{article}
\begin{document}
$$
I=Lp(\theta)\frac{F^{*}F}{N}
$$
\end{document}

BIN
doc/src/Eqs/compute_xrd2.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 4.7 KiB

9
doc/src/Eqs/compute_xrd2.tex
View File

@ -1,9 +0,0 @@
\documentstyle[12pt]{article}
\begin{document}
$$
F(\mathbf{k})=\sum_{j=1}^{N}f_j(\theta)exp(2\pi i \mathbf{k}\cdot \mathbf{r}_j)
$$
\end{document}

BIN
doc/src/Eqs/compute_xrd3.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 4.6 KiB

9
doc/src/Eqs/compute_xrd3.tex
View File

@ -1,9 +0,0 @@
\documentstyle[12pt]{article}
\begin{document}
$$
Lp(\theta)=\frac{1+cos^{2}(2\theta)}{cos(\theta)sin^{2}(\theta)}
$$
\end{document}

BIN
doc/src/Eqs/compute_xrd4.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 2.2 KiB

9
doc/src/Eqs/compute_xrd4.tex
View File

@ -1,9 +0,0 @@
\documentstyle[12pt]{article}
\begin{document}
$$
\frac{sin(\theta)}{\lambda}=\frac{\left | \mathbf{k} \right |}{2}
$$
\end{document}

BIN
doc/src/Eqs/compute_xrd5.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 7.4 KiB

10
doc/src/Eqs/compute_xrd5.tex
View File

@ -1,10 +0,0 @@
\documentstyle[12pt]{article}
\begin{document}
$$
f_j\left ( \frac{sin(\theta)}{\lambda} \right )=\sum_{i}^{4}
a_i exp\left ( -b_i \frac{sin^{2}(\theta)}{\lambda^{2}} \right )+c
$$
\end{document}

BIN
doc/src/Eqs/dihedral_charmm.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 3.0 KiB

9
doc/src/Eqs/dihedral_charmm.tex
View File

@ -1,9 +0,0 @@
\documentclass[12pt]{article}
\begin{document}
$$
E = K [ 1 + \cos (n \phi - d) ]
$$
\end{document}

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