forked from lijiext/lammps
remove .txt doc sources
This commit is contained in:
parent
72d8bea459
commit
daa5efe1fd
|
@ -1,51 +0,0 @@
|
|||
"Previous Section"_Install.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Run_head.html :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Build LAMMPS :h2
|
||||
|
||||
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 "Install"_Install.html doc page.
|
||||
|
||||
<!-- RST
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
Build_cmake
|
||||
Build_make
|
||||
Build_link
|
||||
Build_basics
|
||||
Build_settings
|
||||
Build_package
|
||||
Build_extras
|
||||
Build_windows
|
||||
Build_development
|
||||
|
||||
END_RST -->
|
||||
|
||||
<!-- HTML_ONLY -->
|
||||
|
||||
"Build LAMMPS with CMake"_Build_cmake.html
|
||||
"Build LAMMPS with make"_Build_make.html
|
||||
"Link LAMMPS as a library to another code"_Build_link.html
|
||||
"Basic build options"_Build_basics.html
|
||||
"Optional build settings"_Build_settings.html
|
||||
"Include packages in build"_Build_package.html
|
||||
"Packages with extra build options"_Build_extras.html
|
||||
"Notes for building LAMMPS on Windows"_Build_windows.html
|
||||
"Development build options (CMake only)"_Build_development.html :all(b)
|
||||
|
||||
If you have problems building LAMMPS, it is often due to software
|
||||
issues on your local machine. If you can, find a local expert to
|
||||
help. If you're still stuck, send an email to the "LAMMPS mail
|
||||
list"_http://lammps.sandia.gov/mail.html.
|
|
@ -1,359 +0,0 @@
|
|||
"Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Basic build options :h3
|
||||
|
||||
The following topics are covered on this page, for building both with
|
||||
CMake and make:
|
||||
|
||||
"Serial vs parallel build"_#serial
|
||||
"Choice of compiler and compile/link options"_#compile
|
||||
"Build LAMMPS as an executable or a library"_#exe
|
||||
"Build the LAMMPS documentation"_#doc
|
||||
"Install LAMMPS after a build"_#install :ul
|
||||
|
||||
:line
|
||||
|
||||
Serial vs parallel build :h4,link(serial)
|
||||
|
||||
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).
|
||||
|
||||
[CMake variables]:
|
||||
|
||||
-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 LAMMPS_MACHINE=name # name = mpi, serial, mybox, titan, laptop, etc
|
||||
# no default value :pre
|
||||
|
||||
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.
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
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 :pre # uses Makefile.mybox to produce lmp_mybox :pre
|
||||
|
||||
Serial build (see src/MAKE/Makefile.serial):
|
||||
|
||||
MPI_INC = -I../STUBS
|
||||
MPI_PATH = -L../STUBS
|
||||
MPI_LIB = -lmpi_stubs :pre
|
||||
|
||||
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).
|
||||
|
||||
For a serial build, you need to specify the 3 variables, as shown
|
||||
above.
|
||||
|
||||
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 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.
|
||||
|
||||
[CMake and make info]:
|
||||
|
||||
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 "Speed omp"_Speed_omp.html 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.
|
||||
|
||||
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 "Packages details"_Packages_details.html 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
|
||||
variable before you launch LAMMPS.
|
||||
|
||||
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,
|
||||
please refer to its documentation.
|
||||
|
||||
[OpenMP Compiler compatibility info]: :link(default-none-issues)
|
||||
|
||||
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.
|
||||
|
||||
:line
|
||||
|
||||
Choice of compiler and compile/link options :h4,link(compile)
|
||||
|
||||
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.
|
||||
|
||||
:link(intel,https://software.intel.com/en-us/intel-compilers)
|
||||
|
||||
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.
|
||||
|
||||
[CMake variables]:
|
||||
|
||||
-D CMAKE_CXX_COMPILER=name # name of C++ compiler
|
||||
-D CMAKE_C_COMPILER=name # name of C compiler
|
||||
-D CMAKE_Fortran_COMPILER=name # name of Fortran compiler :pre
|
||||
|
||||
-D CMAKE_CXX_FLAGS=string # flags to use with C++ compiler
|
||||
-D CMAKE_C_FLAGS=string # flags to use with C compiler
|
||||
-D CMAKE_Fortran_FLAGS=string # flags to use with Fortran compiler :pre
|
||||
|
||||
By default CMake will use a compiler it finds and it will add
|
||||
optimization flags appropriate to that compiler and any "accelerator
|
||||
packages"_Speed_packages.html you have included in the build.
|
||||
|
||||
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:
|
||||
|
||||
Building with GNU Compilers:
|
||||
cmake ../cmake -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DCMAKE_Fortran_COMPILER=gfortran
|
||||
Building with Intel Compilers:
|
||||
cmake ../cmake -DCMAKE_C_COMPILER=icc -DCMAKE_CXX_COMPILER=icpc -DCMAKE_Fortran_COMPILER=ifort
|
||||
Building with LLVM/Clang Compilers:
|
||||
cmake ../cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_Fortran_COMPILER=flang :pre
|
||||
|
||||
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.
|
||||
|
||||
[Makefile.machine settings]:
|
||||
|
||||
Parallel build (see src/MAKE/Makefile.mpi):
|
||||
|
||||
CC = mpicxx
|
||||
CCFLAGS = -g -O3
|
||||
LINK = mpicxx
|
||||
LINKFLAGS = -g -O :pre
|
||||
|
||||
Serial build (see src/MAKE/Makefile.serial):
|
||||
|
||||
CC = g++
|
||||
CCFLAGS = -g -O3
|
||||
LINK = g++
|
||||
LINKFLAGS = -g -O :pre
|
||||
|
||||
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 "accelerator
|
||||
packages"_Speed_packages.html 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 "Speed packages"_Speed_packages.html 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:
|
||||
|
||||
Makefile.opt # OPT package
|
||||
Makefile.omp # USER-OMP package
|
||||
Makefile.intel_cpu # USER-INTEL package for CPUs
|
||||
Makefile.intel_coprocessor # USER-INTEL package for KNLs
|
||||
Makefile.gpu # GPU package
|
||||
Makefile.kokkos_cuda_mpi # KOKKOS package for GPUs
|
||||
Makefile.kokkos_omp # KOKKOS package for CPUs (OpenMP)
|
||||
Makefile.kokkos_phi # KOKKOS package for KNLs (OpenMP) :pre
|
||||
|
||||
:line
|
||||
|
||||
Build LAMMPS as an executable or a library :h4,link(exe)
|
||||
|
||||
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 "Howto couple"_Howto_couple.html doc
|
||||
page for more info on coupling LAMMPS to other codes. See the
|
||||
"Python"_Python_head.html doc page for more info on wrapping and
|
||||
running LAMMPS from Python via its library interface.
|
||||
|
||||
[CMake variables]:
|
||||
|
||||
-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
|
||||
# no default value :pre
|
||||
|
||||
|
||||
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.
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
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 :pre
|
||||
|
||||
The two library builds also create generic soft links, named
|
||||
liblammps.a and liblammps.so, which point to the liblammps_machine
|
||||
files.
|
||||
|
||||
[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.
|
||||
|
||||
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:
|
||||
|
||||
:link(mpich,http://www-unix.mcs.anl.gov/mpi)
|
||||
|
||||
./configure --enable-shared
|
||||
make
|
||||
make install :pre
|
||||
|
||||
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.
|
||||
|
||||
:line
|
||||
|
||||
Build the LAMMPS documentation :h4,link(doc)
|
||||
|
||||
[CMake variable]:
|
||||
|
||||
-D BUILD_DOC=value # yes or no (default) :pre
|
||||
|
||||
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.
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
cd lammps/doc
|
||||
make html # html doc pages
|
||||
make pdf # single Manual.pdf file :pre
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
:line
|
||||
|
||||
Build LAMMPS tools :h4,link(tools)
|
||||
|
||||
Some tools described in "Auxiliary tools"_Tools.html can be built directly
|
||||
using CMake or Make.
|
||||
|
||||
[CMake variable]:
|
||||
|
||||
-D BUILD_TOOLS=value # yes or no (default) :pre
|
||||
|
||||
The generated binaries will also become part of the LAMMPS installation (see below)
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
cd lammps/tools
|
||||
make all # build all binaries of tools
|
||||
make binary2txt # build only binary2txt tool
|
||||
make chain # build only chain tool
|
||||
make micelle2d # build only micelle2d tool
|
||||
make thermo_extract # build only thermo_extract tool
|
||||
:pre
|
||||
|
||||
:line
|
||||
|
||||
|
||||
Install LAMMPS after a build :h4,link(install)
|
||||
|
||||
After building LAMMPS, you may wish to copy the LAMMPS executable of
|
||||
library, along with other LAMMPS files (library header, doc files) to
|
||||
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 -D CMAKE_INSTALL_PREFIX=path \[options ...\] ../cmake
|
||||
make # perform make after CMake command
|
||||
make install # perform the installation into prefix :pre
|
||||
|
||||
[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
|
||||
copy the desired LAMMPS files to the appropriate system directories.
|
|
@ -1,212 +0,0 @@
|
|||
"Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Build LAMMPS with CMake :h3
|
||||
|
||||
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 "Build"_Build.html doc 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.
|
||||
|
||||
:line
|
||||
|
||||
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:
|
||||
|
||||
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 :pre
|
||||
|
||||
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".
|
||||
|
||||
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 compilation, you may optionally install the LAMMPS executable into
|
||||
your system with:
|
||||
|
||||
make install # optional, copy LAMMPS executable & library elsewhere :pre
|
||||
|
||||
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
|
||||
|
||||
:line
|
||||
|
||||
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 "Build"_Build.html 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 "perform a conventional LAMMPS
|
||||
build"_Build_make.html. 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.
|
||||
|
||||
:line
|
||||
|
||||
[Command-line version of CMake]:
|
||||
|
||||
cmake \[options ...\] /path/to/lammps/cmake # build from any dir
|
||||
cmake \[options ...\] ../cmake # build from lammps/build :pre
|
||||
|
||||
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:
|
||||
|
||||
-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 :pre
|
||||
|
||||
All the LAMMPS-specific -D variables that a LAMMPS build supports are
|
||||
described on the pages linked to from the "Build"_Build.html 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.
|
||||
|
||||
:line
|
||||
|
||||
[Curses version (terminal-style menu) of CMake]:
|
||||
|
||||
ccmake ../cmake :pre
|
||||
|
||||
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.
|
||||
|
||||
:line
|
||||
|
||||
[GUI version of CMake]:
|
||||
|
||||
cmake-gui ../cmake :pre
|
||||
|
||||
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.
|
||||
|
||||
:line
|
||||
|
||||
[Installing CMake]
|
||||
|
||||
Check if your machine already has CMake installed:
|
||||
|
||||
which cmake # do you have it?
|
||||
which cmake3 # version 3 may have this name
|
||||
cmake --version # what specific version you have :pre
|
||||
|
||||
On clusters or supercomputers which use environment modules to manage
|
||||
software packages, do this:
|
||||
|
||||
module list # is a cmake module already loaded?
|
||||
module avail # is a cmake module available?
|
||||
module load cmake3 # load cmake module with appropriate name :pre
|
||||
|
||||
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/.
|
|
@ -1,86 +0,0 @@
|
|||
"Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Development build options (CMake only) :h3
|
||||
|
||||
The CMake build of LAMMPS has a few extra options which are useful during
|
||||
development, testing or debugging.
|
||||
|
||||
:line
|
||||
|
||||
Verify compilation flags :h4,link(compilation)
|
||||
|
||||
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.
|
||||
|
||||
-D CMAKE_VERBOSE_MAKEFILE=value # value = no (default) or yes :pre
|
||||
|
||||
Another way of doing this without reconfiguration is calling make with variable VERBOSE set to 1:
|
||||
|
||||
make VERBOSE=1 :pre
|
||||
|
||||
:line
|
||||
|
||||
Address, Undefined Behavior, and Thread Sanitizer Support :h4,link(sanitizer)
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
-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
|
||||
:pre
|
||||
|
||||
:line
|
||||
|
||||
Code Coverage and Testing :h4,link(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.
|
||||
|
||||
NOTE: this is incomplete and only represents a small subset of tests that we run
|
||||
|
||||
-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
|
||||
:pre
|
||||
|
||||
If you enable testing in the CMake build it will create an additional target called "test". You can run them with:
|
||||
|
||||
make test
|
||||
:pre
|
||||
|
||||
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.
|
||||
|
||||
You can also collect code coverage metrics while running the tests by enabling
|
||||
coverage support during building.
|
||||
|
||||
-D ENABLE_COVERAGE=value # enable coverage measurements, value = no (default) or yes :pre
|
||||
|
||||
This will also add the following targets to generate coverage reports after running the LAMMPS executable:
|
||||
|
||||
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
|
||||
:pre
|
||||
|
||||
These reports require GCOVR to be installed. The easiest way to do this to install it via pip:
|
||||
|
||||
pip install git+https://github.com/gcovr/gcovr.git :pre
|
||||
:pre
|
File diff suppressed because it is too large
Load Diff
|
@ -1,85 +0,0 @@
|
|||
"Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Link LAMMPS as a library to another code :h3
|
||||
|
||||
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 "Howto
|
||||
library"_Howto_library.html doc page for a description of the
|
||||
interface and how to extend it for your needs.
|
||||
|
||||
The "Build basics"_Build_basics.html doc page explains how to build
|
||||
LAMMPS as either a shared or static library. This results in one of
|
||||
these 2 files:
|
||||
|
||||
liblammps.so # shared library
|
||||
liblammps.a # static library
|
||||
|
||||
:line
|
||||
|
||||
[Link with LAMMPS as a static library]:
|
||||
|
||||
The calling application can link to LAMMPS as a static library with a
|
||||
link command like this:
|
||||
|
||||
g++ caller.o -L/home/sjplimp/lammps/src -llammps -o caller
|
||||
|
||||
The -L argument is the path to where the liblammps.a file is. The
|
||||
-llammps argument is shorthand for the file liblammps.a.
|
||||
|
||||
:line
|
||||
|
||||
[Link with LAMMPS as a shared library]:
|
||||
|
||||
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:
|
||||
|
||||
(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
|
||||
|
||||
printenv LD_LIBRARY_PATH :pre
|
||||
|
||||
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.
|
||||
|
||||
For the csh or tcsh shells, you would add something like this to your
|
||||
~/.cshrc file:
|
||||
|
||||
setenv LD_LIBRARY_PATH $\{LD_LIBRARY_PATH\}:/home/sjplimp/lammps/src :pre
|
||||
|
||||
:line
|
||||
|
||||
[Calling the LAMMPS library]:
|
||||
|
||||
Either flavor of library (static or shared) allows one or more LAMMPS
|
||||
objects to be instantiated from the calling program.
|
||||
|
||||
When used from a C++ program, 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.
|
||||
|
||||
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.
|
||||
|
||||
See the "Python library"_Python_library.html doc page for a
|
||||
description of the Python interface to LAMMPS, which wraps the C-style
|
||||
interface.
|
||||
|
||||
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 "Howto couple"_Howto_couple.html doc page.
|
||||
|
||||
|
|
@ -1,85 +0,0 @@
|
|||
"Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Build LAMMPS with make :h3
|
||||
|
||||
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.
|
||||
|
||||
To include LAMMPS packages (i.e. optional commands and styles) you
|
||||
must install them first, as discussed on the "Build
|
||||
package"_Build_package.html doc page. If the packages require
|
||||
provided or external libraries, you must build those libraries before
|
||||
building LAMMPS. Building "LAMMPS with CMake"_Build_cmake.html can
|
||||
automate all of this for many types of machines, especially
|
||||
workstations, desktops and laptops, so we suggest you try it first.
|
||||
|
||||
These commands perform a default LAMMPS build, producing the LAMMPS
|
||||
executable lmp_serial or lmp_mpi in lammps/src:
|
||||
|
||||
cd lammps/src
|
||||
make serial # build a serial LAMMPS executable
|
||||
make mpi # build a parallel LAMMPS executable with MPI
|
||||
make # see a variety of make options :pre
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
:line
|
||||
|
||||
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:
|
||||
|
||||
OPTIONS # Makefiles which enable specific options
|
||||
MACHINES # Makefiles for specific machines
|
||||
MINE # customized Makefiles you create (you may need to create this folder) :pre
|
||||
|
||||
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.
|
||||
|
||||
Makefiles you may wish to try include these (some require a package
|
||||
first be installed). Many of these include specific compiler flags
|
||||
for optimized performance. Please note, however, that some of these
|
||||
customized machine Makefile are contributed by users. Since both
|
||||
compilers, OS configurations, and LAMMPS itself keep changing, their
|
||||
settings may become outdated:
|
||||
|
||||
make mac # build serial LAMMPS on a Mac
|
||||
make mac_mpi # build parallel LAMMPS on a Mac
|
||||
make intel_cpu # build with the USER-INTEL package optimized for CPUs
|
||||
make knl # build with the USER-INTEL package optimized for KNLs
|
||||
make opt # build with the OPT package optimized for CPUs
|
||||
make omp # build with the USER-OMP package optimized for OpenMP
|
||||
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 :pre
|
|
@ -1,240 +0,0 @@
|
|||
"Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Include packages in build :h3
|
||||
|
||||
In LAMMPS, a package is a group of files that enable a specific set of
|
||||
features. For example, force fields for molecular systems or
|
||||
rigid-body constraints are in packages. In the src directory, each
|
||||
package is a sub-directory with the package name in capital letters.
|
||||
|
||||
An overview of packages is given on the "Packages"_Packages.html doc
|
||||
page. Brief overviews of each package are on the "Packages
|
||||
details"_Packages_details.html doc page.
|
||||
|
||||
When building LAMMPS, you can choose to include or exclude each
|
||||
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
|
||||
"-h command-line switch"_Run_options.html will print all the included
|
||||
packages and commands for 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
|
||||
without any packages installed. A few packages may require additional
|
||||
steps, as explained on the "Build extras"_Build_extras.html doc page.
|
||||
|
||||
These links take you to the extra instructions for those select
|
||||
packages:
|
||||
|
||||
"COMPRESS"_Build_extras.html#compress,
|
||||
"GPU"_Build_extras.html#gpu,
|
||||
"KIM"_Build_extras.html#kim,
|
||||
"KOKKOS"_Build_extras.html#kokkos,
|
||||
"LATTE"_Build_extras.html#latte,
|
||||
"MESSAGE"_Build_extras.html#message,
|
||||
"MSCG"_Build_extras.html#mscg,
|
||||
"OPT"_Build_extras.html#opt,
|
||||
"POEMS"_Build_extras.html#poems,
|
||||
"PYTHON"_Build_extras.html#python,
|
||||
"VORONOI"_Build_extras.html#voronoi,
|
||||
"USER-ADIOS"_Build_extras.html#user-adios,
|
||||
"USER-ATC"_Build_extras.html#user-atc,
|
||||
"USER-AWPMD"_Build_extras.html#user-awpmd,
|
||||
"USER-COLVARS"_Build_extras.html#user-colvars,
|
||||
"USER-H5MD"_Build_extras.html#user-h5md,
|
||||
"USER-INTEL"_Build_extras.html#user-intel,
|
||||
"USER-MOLFILE"_Build_extras.html#user-molfile,
|
||||
"USER-NETCDF"_Build_extras.html#user-netcdf,
|
||||
"USER-PLUMED"_Build_extras.html#user-plumed,
|
||||
"USER-OMP"_Build_extras.html#user-omp,
|
||||
"USER-QMMM"_Build_extras.html#user-qmmm,
|
||||
"USER-QUIP"_Build_extras.html#user-quip,
|
||||
"USER-SCAFACOS"_Build_extras.html#user-scafacos,
|
||||
"USER-SMD"_Build_extras.html#user-smd,
|
||||
"USER-VTK"_Build_extras.html#user-vtk :tb(c=6,ea=c,a=l)
|
||||
|
||||
The mechanism for including packages is simple but different for CMake
|
||||
versus make.
|
||||
|
||||
[CMake variables]:
|
||||
|
||||
-D PKG_NAME=value # yes or no (default) :pre
|
||||
|
||||
Examples:
|
||||
|
||||
-D PKG_MANYBODY=yes
|
||||
-D PKG_USER-INTEL=yes :pre
|
||||
|
||||
All standard and user packages are included the same way. Note that
|
||||
USER packages have a hyphen between USER and the rest of the package
|
||||
name, not an underscore.
|
||||
|
||||
See the shortcut section below for how to install many packages at
|
||||
once with CMake.
|
||||
|
||||
NOTE: If you toggle back and forth between building with CMake vs
|
||||
make, no packages in the src directory can be installed when you
|
||||
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]:
|
||||
|
||||
cd lammps/src
|
||||
make ps # check which packages are currently installed
|
||||
make yes-name # install a package with name
|
||||
make no-name # un-install a package with name
|
||||
make mpi # build LAMMPS with whatever packages are now installed :pre
|
||||
|
||||
Examples:
|
||||
|
||||
make no-rigid
|
||||
make yes-user-intel :pre
|
||||
|
||||
All standard and user packages are included the same way.
|
||||
|
||||
See the shortcut section below for how to install many packages at
|
||||
once with make.
|
||||
|
||||
NOTE: You must always re-build LAMMPS (via make) after installing or
|
||||
un-installing a package, for the action to take effect.
|
||||
|
||||
NOTE: You cannot install or un-install packages and build LAMMPS in a
|
||||
single make command with multiple targets, e.g. make yes-colloid mpi.
|
||||
This is because the make procedure creates a list of source files that
|
||||
will be out-of-date for the build if the package configuration changes
|
||||
within the same command. You can include or exclude multiple packages
|
||||
in a single make command, e.g. make yes-colloid no-manybody.
|
||||
|
||||
[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
|
||||
from files in other packages. LAMMPS checks for this and does the
|
||||
right thing. Individual files are only included if their dependencies
|
||||
are already included. Likewise, if a package is excluded, other files
|
||||
dependent on that package are also excluded.
|
||||
|
||||
When you download a LAMMPS tarball or download LAMMPS source files
|
||||
from the Git or SVN repositories, no packages are pre-installed in the
|
||||
src directory.
|
||||
|
||||
NOTE: Prior to Aug 2018, if you downloaded a tarball, 3 packages
|
||||
(KSPACE, MANYBODY, MOLECULE) were pre-installed in the src directory.
|
||||
That is no longer the case, so that CMake will build as-is without the
|
||||
need to un-install those packages.
|
||||
|
||||
:line
|
||||
|
||||
[CMake shortcuts 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.
|
||||
|
||||
LAMMPS includes several of these files to define configuration
|
||||
"presets", similar to the options that exist for the Make based
|
||||
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 :tb(c=2,s=|,a=l)
|
||||
|
||||
NOTE: Running cmake this way manipulates the variable 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:]
|
||||
|
||||
# build LAMMPS with most commonly used packages, but then remove
|
||||
# those requiring additional library or tools, but still enable
|
||||
# GPU package and configure it for using CUDA. You can run.
|
||||
mkdir build
|
||||
cd build
|
||||
cmake -C ../cmake/presets/most.cmake -C ../cmake/presets/nolib.cmake -D PKG_GPU=on -D GPU_API=cuda ../cmake :pre
|
||||
|
||||
# to add another package, say BODY to the previous configuration you can run:
|
||||
cmake -D PKG_BODY=on . :pre
|
||||
|
||||
# to reset the package selection from above to the default of no packages
|
||||
# but leaving all other settings untouched. You can run:
|
||||
cmake -C ../cmake/presets/no_all.cmake . :pre
|
||||
:line
|
||||
|
||||
[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.
|
||||
|
||||
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 :tb(s=|,a=l)
|
||||
|
||||
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.
|
||||
|
||||
The following make commands help manage files that exist in both the
|
||||
src directory and in package sub-directories. You do not normally
|
||||
need to use these commands unless you are editing LAMMPS files or are
|
||||
"installing a patch"_Install_patch.html downloaded from the LAMMPS web
|
||||
site.
|
||||
|
||||
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
|
||||
currently installed, without listing the status of packages that are
|
||||
not installed.
|
||||
|
||||
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 "patch has been applied"_Install_patch.html,
|
||||
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
|
||||
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.
|
|
@ -1,372 +0,0 @@
|
|||
"Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Optional build settings :h3
|
||||
|
||||
LAMMPS can be built with several optional settings. Each sub-section
|
||||
explain how to do this for building both with CMake and make.
|
||||
|
||||
"C++11 standard compliance test"_#cxx11 when building all of LAMMPS
|
||||
"FFT library"_#fft for use with the "kspace_style pppm"_kspace_style.html command
|
||||
"Size of LAMMPS data types"_#size
|
||||
"Read or write compressed files"_#gzip
|
||||
"Output of JPG and PNG files"_#graphics via the "dump image"_dump_image.html command
|
||||
"Output of movie files"_#graphics via the "dump_movie"_dump_image.html command
|
||||
"Memory allocation alignment"_#align
|
||||
"Workaround for long long integers"_#longlong
|
||||
"Error handling exceptions"_#exceptions when using LAMMPS as a library :all(b)
|
||||
|
||||
:line
|
||||
|
||||
C++11 standard compliance test :h4,link(cxx11)
|
||||
|
||||
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.
|
||||
|
||||
[CMake variable]:
|
||||
|
||||
-D DISABLE_CXX11_REQUIREMENT=yes :pre
|
||||
|
||||
You can set additional C++ compiler flags (beyond those selected by CMake)
|
||||
through the CMAKE_CXX_FLAGS variable. Example for CentOS 7:
|
||||
|
||||
-D CMAKE_CXX_FLAGS="-O3 -g -fopenmp -DNDEBUG -std=c++11" :pre
|
||||
|
||||
[Makefile.machine setting]:
|
||||
|
||||
LMP_INC = -DLAMMPS_CXX98 :pre
|
||||
|
||||
:line
|
||||
|
||||
FFT library :h4,link(fft)
|
||||
|
||||
When the KSPACE package is included in a LAMMPS build, the
|
||||
"kspace_style pppm"_kspace_style.html command performs 3d FFTs which
|
||||
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]:
|
||||
|
||||
-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
|
||||
-D FFT_PACK=value # array (default) or pointer or memcpy :pre
|
||||
|
||||
NOTE: The values for the FFT variable must be in upper-case. This is
|
||||
an exception to the rule that all CMake variables can be specified
|
||||
with lower-case values.
|
||||
|
||||
Usually these settings are all that is needed. If CMake cannot find
|
||||
the FFT library, you can set these variables:
|
||||
|
||||
-D FFTW3_INCLUDE_DIRS=path # path to FFTW3 include files
|
||||
-D FFTW3_LIBRARIES=path # path to FFTW3 libraries
|
||||
-D MKL_INCLUDE_DIRS=path # ditto for Intel MKL library
|
||||
-D MKL_LIBRARIES=path :pre
|
||||
|
||||
[Makefile.machine settings]:
|
||||
|
||||
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_PACK_ARRAY # or -DFFT_PACK_POINTER or -DFFT_PACK_MEMCPY :pre
|
||||
# default is FFT_PACK_ARRAY if not specified
|
||||
|
||||
FFT_INC = -I/usr/local/include
|
||||
FFT_PATH = -L/usr/local/lib
|
||||
FFT_LIB = -lfftw3 # FFTW3 double precision
|
||||
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 :pre
|
||||
|
||||
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.
|
||||
|
||||
[CMake and make info]:
|
||||
|
||||
The "KISS FFT library"_http://kissfft.sf.net is included in the LAMMPS
|
||||
distribution. It is portable across all platforms. Depending on the
|
||||
size of the FFTs and the number of processors used, the other
|
||||
libraries listed here can be faster.
|
||||
|
||||
However, note that long-range Coulombics are only a portion of the
|
||||
per-timestep CPU cost, FFTs are only a portion of long-range
|
||||
Coulombics, and 1d FFTs are only a portion of the FFT cost (parallel
|
||||
communication can be costly). A breakdown of these timings is printed
|
||||
to the screen at the end of a run using the "kspace_style
|
||||
pppm"_kspace_style.html command. The "Run output"_Run_output.html
|
||||
doc page gives more details.
|
||||
|
||||
FFTW is a fast, portable FFT library that should also work on any
|
||||
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
|
||||
(e.g. invoke it via sudo), unless you specify a local directory with
|
||||
the "--prefix" option of configure. Type "./configure --help" to see
|
||||
various options.
|
||||
|
||||
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).
|
||||
|
||||
Performing 3d FFTs in parallel can be time consuming due to data
|
||||
access and required communication. This cost can be reduced by
|
||||
performing single-precision FFTs instead of double precision. Single
|
||||
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
|
||||
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
|
||||
library a second time with support for single-precision.
|
||||
|
||||
For FFTW3, do the following, which should produce the additional
|
||||
library libfftw3f.a
|
||||
|
||||
make clean
|
||||
./configure --enable-single; make; make install :pre
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
:line
|
||||
|
||||
Size of LAMMPS data types :h4,link(size)
|
||||
|
||||
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.
|
||||
|
||||
[CMake variable]:
|
||||
|
||||
-D LAMMPS_SIZES=value # smallbig (default) or bigbig or smallsmall :pre
|
||||
|
||||
[Makefile.machine setting]:
|
||||
|
||||
LMP_INC = -DLAMMPS_SMALLBIG # or -DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL :pre
|
||||
# default is LAMMPS_SMALLBIG if not specified
|
||||
[CMake and make info]:
|
||||
|
||||
The default "smallbig" setting allows for simulations with:
|
||||
|
||||
total atom count = 2^63 atoms (about 9e18)
|
||||
total timesteps = 2^63 (about 9e18)
|
||||
atom IDs = 2^31 (about 2 billion)
|
||||
image flags = roll over at 512 :ul
|
||||
|
||||
The "bigbig" setting increases the latter two limits. It allows for:
|
||||
|
||||
total atom count = 2^63 atoms (about 9e18)
|
||||
total timesteps = 2^63 (about 9e18)
|
||||
atom IDs = 2^63 (about 9e18)
|
||||
image flags = roll over at about 1 million (2^20) :ul
|
||||
|
||||
The "smallsmall" setting is only needed if your machine does not
|
||||
support 8-byte integers. It allows for:
|
||||
|
||||
total atom count = 2^31 atoms (about 2 billion)
|
||||
total timesteps = 2^31 (about 2 billion)
|
||||
atom IDs = 2^31 (about 2 billion)
|
||||
image flags = roll over at 512 (2^9) :ul
|
||||
|
||||
Atom IDs are not required for atomic systems which do not store bond
|
||||
topology information, though IDs are enabled by default. The
|
||||
"atom_modify id no"_atom_modify.html command will turn them off. Atom
|
||||
IDs are required for molecular systems with bond topology (bonds,
|
||||
angles, dihedrals, etc). Thus if you model a molecular system with
|
||||
more than 2 billion atoms, you need the "bigbig" setting.
|
||||
|
||||
Image flags store 3 values per atom which count the number of times an
|
||||
atom has moved through the periodic box in each dimension. See the
|
||||
"dump"_dump.html doc page for a discussion. If an atom moves through
|
||||
the periodic box more than this limit, the value will "roll over",
|
||||
e.g. from 511 to -512, which can cause diagnostics like the
|
||||
mean-squared displacement, as calculated by the "compute
|
||||
msd"_compute_msd.html command, to be faulty.
|
||||
|
||||
Note that the USER-ATC package and the USER-INTEL package are currently
|
||||
not compatible with the "bigbig" setting. Also, there are limitations
|
||||
when using the library interface. Some functions with known issues
|
||||
have been replaced by dummy calls printing a corresponding error rather
|
||||
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.
|
||||
|
||||
:line
|
||||
|
||||
Output of JPG, PNG, and movie files :h4,link(graphics)
|
||||
|
||||
The "dump image"_dump_image.html command has options to output JPEG or
|
||||
PNG image files. Likewise the "dump movie"_dump_image.html command
|
||||
outputs movie files in MPEG format. Using these options requires the
|
||||
following settings:
|
||||
|
||||
[CMake variables]:
|
||||
|
||||
-D WITH_JPEG=value # yes or 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
|
||||
-D WITH_FFMPEG=value # yes or no
|
||||
# default = yes if CMake can find ffmpeg, else no :pre
|
||||
|
||||
Usually these settings are all that is needed. If CMake cannot find
|
||||
the graphics header, library, executable files, you can set these
|
||||
variables:
|
||||
|
||||
-D JPEG_INCLUDE_DIR=path # path to jpeglib.h header file
|
||||
-D JPEG_LIBRARIES=path # path to libjpeg.a (.so) file
|
||||
-D PNG_INCLUDE_DIR=path # path to png.h header file
|
||||
-D PNG_LIBRARIES=path # path to libpng.a (.so) file
|
||||
-D ZLIB_INCLUDE_DIR=path # path to zlib.h header file
|
||||
-D ZLIB_LIBRARIES=path # path to libz.a (.so) file
|
||||
-D FFMPEG_EXECUTABLE=path # path to ffmpeg executable :pre
|
||||
|
||||
[Makefile.machine settings]:
|
||||
|
||||
LMP_INC = -DLAMMPS_JPEG
|
||||
LMP_INC = -DLAMMPS_PNG
|
||||
LMP_INC = -DLAMMPS_FFMPEG :pre
|
||||
|
||||
JPG_INC = -I/usr/local/include # path to jpeglib.h, png.h, zlib.h header files if make cannot find them
|
||||
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 :pre
|
||||
|
||||
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.
|
||||
|
||||
[CMake and make info]:
|
||||
|
||||
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
|
||||
communication library and lead to simulations using ffmpeg to hang or
|
||||
crash.
|
||||
|
||||
:line
|
||||
|
||||
Read or write compressed files :h4,link(gzip)
|
||||
|
||||
If this option is enabled, large files can be read or written with
|
||||
gzip compression by several LAMMPS commands, including
|
||||
"read_data"_read_data.html, "rerun"_rerun.html, and "dump"_dump.html.
|
||||
|
||||
[CMake variables]:
|
||||
|
||||
-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 :pre
|
||||
|
||||
[Makefile.machine setting]:
|
||||
|
||||
LMP_INC = -DLAMMPS_GZIP :pre
|
||||
|
||||
[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
|
||||
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
|
||||
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 "COMPRESS package"_Packages_details.html#PKG-COMPRESS enables.
|
||||
|
||||
:line
|
||||
|
||||
Memory allocation alignment :h4,link(align)
|
||||
|
||||
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.
|
||||
On most current systems, the malloc() implementation returns
|
||||
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]:
|
||||
|
||||
-D LAMMPS_MEMALIGN=value # 0, 8, 16, 32, 64 (default) :pre
|
||||
|
||||
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]:
|
||||
|
||||
LMP_INC = -DLAMMPS_MEMALIGN=value # 8, 16, 32, 64 :pre
|
||||
|
||||
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.
|
||||
|
||||
:line
|
||||
|
||||
Workaround for long long integers :h4,link(longlong)
|
||||
|
||||
If your system or MPI version does not recognize "long long" data
|
||||
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]:
|
||||
|
||||
-D LAMMPS_LONGLONG_TO_LONG=value # yes or no (default) :pre
|
||||
|
||||
[Makefile.machine setting]:
|
||||
|
||||
LMP_INC = -DLAMMPS_LONGLONG_TO_LONG :pre
|
||||
|
||||
:line
|
||||
|
||||
Exception handling when using LAMMPS as a library :h4,link(exceptions)
|
||||
|
||||
This setting is useful when external codes drive LAMMPS as a library.
|
||||
With this option enabled LAMMPS errors do not kill the caller.
|
||||
Instead, the call stack is unwound and control returns to the caller,
|
||||
e.g. to Python.
|
||||
|
||||
[CMake variable]:
|
||||
|
||||
-D LAMMPS_EXCEPTIONS=value # yes or no (default) :pre
|
||||
|
||||
[Makefile.machine setting]:
|
||||
|
||||
LMP_INC = -DLAMMPS_EXCEPTIONS :pre
|
|
@ -1,102 +0,0 @@
|
|||
"Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Notes for building LAMMPS on Windows :h3
|
||||
|
||||
"General remarks"_#generic
|
||||
"Running Linux on Windows"_#linux
|
||||
"Using GNU GCC ported to Windows"_#gnu
|
||||
"Using a cross-compiler"_#cross :ul
|
||||
|
||||
:line
|
||||
|
||||
General remarks :h4,link(generic)
|
||||
|
||||
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.
|
||||
The LAMMPS developers strongly rely on LAMMPS users giving feedback and
|
||||
providing assistance in resolving portability issues. This particularly
|
||||
true for compiling LAMMPS on Windows, since this platform has significant
|
||||
differences with some low-level functionality.
|
||||
|
||||
|
||||
Running Linux on Windows :h4,link(linux)
|
||||
|
||||
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
|
||||
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 "this tutorial"_Howto_bash.html
|
||||
|
||||
|
||||
Using GNU GCC ported to Windows :h4,link(gnu)
|
||||
|
||||
One option for compiling LAMMPS on Windows natively, that has been known
|
||||
to work in the past is to install a bash shell, unix shell utilities,
|
||||
perl, GNU make, and a GNU compiler ported to Windows. The Cygwin package
|
||||
provides a unix/linux interface to low-level Windows functions, so LAMMPS
|
||||
can be compiled on Windows. The necessary (minor) modifications to LAMMPS
|
||||
are included, but may not always up-to-date for recently added functionality
|
||||
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
|
||||
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
|
||||
this up automatically, but is untested.
|
||||
|
||||
In case of problems, you are recommended to contact somebody with
|
||||
experience in using cygwin. If you do come across portability problems
|
||||
requiring changes to the LAMMPS source code, or figure out corrections
|
||||
yourself, please report them on the lammps-users mailing list, or file
|
||||
them as an issue or pull request on the LAMMPS GitHub project.
|
||||
|
||||
|
||||
Using a cross-compiler :h4,link(cross)
|
||||
|
||||
If you need to provide custom LAMMPS binaries for Windows, but do not
|
||||
need to do the compilation on Windows, please consider using a Linux
|
||||
to Windows cross-compiler. This is how currently the Windows binary
|
||||
packages are created by the LAMMPS developers. Because of that, this is
|
||||
probably the currently best tested and supported way to build LAMMPS
|
||||
executables for Windows. There are makefiles provided for the
|
||||
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.
|
||||
|
||||
Please keep in mind, though, that this only applies to compiling LAMMPS.
|
||||
Whether the resulting binaries do work correctly is no 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
|
||||
this is subject to time constraints and focus on HPC platforms.
|
||||
|
||||
|
||||
Native Visual C++ support :h4,link(native)
|
||||
|
||||
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.
|
|
@ -1,38 +0,0 @@
|
|||
"Previous Section"_Python_head.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
|
||||
Section"_Manual.html :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Errors :h2
|
||||
|
||||
These doc pages describe the errors you can encounter when using
|
||||
LAMMPS. The common problems include conceptual issues. The messages
|
||||
and warnings doc pages give complete lists of all the messages the
|
||||
code may generate (except those generated by USER packages), with
|
||||
additional details for many of them.
|
||||
|
||||
<!-- RST
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
Errors_common
|
||||
Errors_bugs
|
||||
Errors_messages
|
||||
Errors_warnings
|
||||
|
||||
END_RST -->
|
||||
|
||||
<!-- HTML_ONLY -->
|
||||
|
||||
"Common problems"_Errors_common.html
|
||||
"Reporting bugs"_Errors_bugs.html
|
||||
"Error messages"_Errors_messages.html
|
||||
"Warning messages"_Errors_warnings.html :all(b)
|
||||
|
||||
<!-- END_HTML_ONLY -->
|
|
@ -1,35 +0,0 @@
|
|||
"Higher level section"_Errors.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Reporting bugs :h3
|
||||
|
||||
If you are confident that you have found a bug in LAMMPS, follow these
|
||||
steps.
|
||||
|
||||
Check the "New features and bug
|
||||
fixes"_http://lammps.sandia.gov/bug.html section of the "LAMMPS WWW
|
||||
site"_lws to see if the bug has already been reported or fixed or the
|
||||
"Unfixed bug"_http://lammps.sandia.gov/unbug.html to see if a fix is
|
||||
pending.
|
||||
|
||||
Check the "mailing list"_http://lammps.sandia.gov/mail.html to see if
|
||||
it has been discussed before.
|
||||
|
||||
If not, send an email to the mailing list describing the problem with
|
||||
any ideas you have as to what is causing it or where in the code the
|
||||
problem might be. The developers will ask for more info if needed,
|
||||
such as an input script or data files.
|
||||
|
||||
The most useful thing you can do to help us fix the bug is to isolate
|
||||
the problem. Run it on the smallest number of atoms and fewest number
|
||||
of processors and with the simplest input script that reproduces the
|
||||
bug and try to identify what command or combination of commands is
|
||||
causing the problem.
|
||||
|
||||
NOTE: this page needs to have GitHub issues info added
|
|
@ -1,126 +0,0 @@
|
|||
"Higher level section"_Errors.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Common problems :h3
|
||||
|
||||
If two LAMMPS runs do not produce the exact same answer on different
|
||||
machines or different numbers of processors, this is typically not a
|
||||
bug. In theory you should get identical answers on any number of
|
||||
processors and on any machine. In practice, numerical round-off can
|
||||
cause slight differences and eventual divergence of molecular dynamics
|
||||
phase space trajectories within a few 100s or few 1000s of timesteps.
|
||||
However, the statistical properties of the two runs (e.g. average
|
||||
energy or temperature) should still be the same.
|
||||
|
||||
If the "velocity"_velocity.html command is used to set initial atom
|
||||
velocities, a particular atom can be assigned a different velocity
|
||||
when the problem is run on a different number of processors or on
|
||||
different machines. If this happens, the phase space trajectories of
|
||||
the two simulations will rapidly diverge. See the discussion of the
|
||||
{loop} option in the "velocity"_velocity.html command for details and
|
||||
options that avoid this issue.
|
||||
|
||||
Similarly, the "create_atoms"_create_atoms.html command generates a
|
||||
lattice of atoms. For the same physical system, the ordering and
|
||||
numbering of atoms by atom ID may be different depending on the number
|
||||
of processors.
|
||||
|
||||
Some commands use random number generators which may be setup to
|
||||
produce different random number streams on each processor and hence
|
||||
will produce different effects when run on different numbers of
|
||||
processors. A commonly-used example is the "fix
|
||||
langevin"_fix_langevin.html command for thermostatting.
|
||||
|
||||
A LAMMPS simulation typically has two stages, setup and run. Most
|
||||
LAMMPS errors are detected at setup time; others like a bond
|
||||
stretching too far may not occur until the middle of a run.
|
||||
|
||||
LAMMPS tries to flag errors and print informative error messages so
|
||||
you can fix the problem. For most errors it will also print the last
|
||||
input script command that it was processing. Of course, LAMMPS cannot
|
||||
figure out your physics or numerical mistakes, like choosing too big a
|
||||
timestep, specifying erroneous force field coefficients, or putting 2
|
||||
atoms on top of each other! If you run into errors that LAMMPS
|
||||
doesn't catch that you think it should flag, please send an email to
|
||||
the "developers"_http://lammps.sandia.gov/authors.html.
|
||||
|
||||
If you get an error message about an invalid command in your input
|
||||
script, you can determine what command is causing the problem by
|
||||
looking in the log.lammps file or using the "echo command"_echo.html
|
||||
to see it on the screen. If you get an error like "Invalid ...
|
||||
style", with ... being fix, compute, pair, etc, it means that you
|
||||
mistyped the style name or that the command is part of an optional
|
||||
package which was not compiled into your executable. The list of
|
||||
available styles in your executable can be listed by using "the -h
|
||||
command-line swith"_Run_options.html. The installation and
|
||||
compilation of optional packages is explained on the "Build
|
||||
packages"_Build_package.html doc page.
|
||||
|
||||
For a given command, LAMMPS expects certain arguments in a specified
|
||||
order. If you mess this up, LAMMPS will often flag the error, but it
|
||||
may also simply read a bogus argument and assign a value that is
|
||||
valid, but not what you wanted. E.g. trying to read the string "abc"
|
||||
as an integer value of 0. Careful reading of the associated doc page
|
||||
for the command should allow you to fix these problems. In most cases,
|
||||
where LAMMPS expects to read a number, either integer or floating point,
|
||||
it performs a stringent test on whether the provided input actually
|
||||
is an integer or floating-point number, respectively, and reject the
|
||||
input with an error message (for instance, when an integer is required,
|
||||
but a floating-point number 1.0 is provided):
|
||||
|
||||
ERROR: Expected integer parameter instead of '1.0' in input script or data file :pre
|
||||
|
||||
Some commands allow for using variable references in place of numeric
|
||||
constants so that the value can be evaluated and may change over the
|
||||
course of a run. This is typically done with the syntax {v_name} for a
|
||||
parameter, where name is the name of the variable. On the other hand,
|
||||
immediate variable expansion with the syntax ${name} is performed while
|
||||
reading the input and before parsing commands,
|
||||
|
||||
NOTE: Using a variable reference (i.e. {v_name}) is only allowed if
|
||||
the documentation of the corresponding command explicitly says it is.
|
||||
Otherwise, you will receive an error message of this kind:
|
||||
|
||||
ERROR: Expected floating point parameter instead of 'v_name' in input script or data file :pre
|
||||
|
||||
Generally, LAMMPS will print a message to the screen and logfile and
|
||||
exit gracefully when it encounters a fatal error. Sometimes it will
|
||||
print a WARNING to the screen and logfile and continue on; you can
|
||||
decide if the WARNING is important or not. A WARNING message that is
|
||||
generated in the middle of a run is only printed to the screen, not to
|
||||
the logfile, to avoid cluttering up thermodynamic output. If LAMMPS
|
||||
crashes or hangs without spitting out an error message first then it
|
||||
could be a bug (see "this section"_Errors_bugs.html) or one of the following
|
||||
cases:
|
||||
|
||||
LAMMPS runs in the available memory a processor allows to be
|
||||
allocated. Most reasonable MD runs are compute limited, not memory
|
||||
limited, so this shouldn't be a bottleneck on most platforms. Almost
|
||||
all large memory allocations in the code are done via C-style malloc's
|
||||
which will generate an error message if you run out of memory.
|
||||
Smaller chunks of memory are allocated via C++ "new" statements. If
|
||||
you are unlucky you could run out of memory just when one of these
|
||||
small requests is made, in which case the code will crash or hang (in
|
||||
parallel), since LAMMPS doesn't trap on those errors.
|
||||
|
||||
Illegal arithmetic can cause LAMMPS to run slow or crash. This is
|
||||
typically due to invalid physics and numerics that your simulation is
|
||||
computing. If you see wild thermodynamic values or NaN values in your
|
||||
LAMMPS output, something is wrong with your simulation. If you
|
||||
suspect this is happening, it is a good idea to print out
|
||||
thermodynamic info frequently (e.g. every timestep) via the
|
||||
"thermo"_thermo.html so you can monitor what is happening.
|
||||
Visualizing the atom movement is also a good idea to insure your model
|
||||
is behaving as you expect.
|
||||
|
||||
In parallel, one way LAMMPS can hang is due to how different MPI
|
||||
implementations handle buffering of messages. If the code hangs
|
||||
without an error message, it may be that you need to specify an MPI
|
||||
setting or two (usually via an environment variable) to enable
|
||||
buffering or boost the sizes of messages that can be buffered.
|
|
@ -1,159 +0,0 @@
|
|||
"Previous Section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc - "Next
|
||||
Section"_Tools.html :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Example scripts :h3
|
||||
|
||||
The LAMMPS distribution includes an examples sub-directory with many
|
||||
sample problems. Many are 2d models that run quickly and are
|
||||
straightforward to visualize, requiring at most a couple of minutes to
|
||||
run on a desktop machine. Each problem has an input script (in.*) and
|
||||
produces a log file (log.*) when it runs. Some use a data file
|
||||
(data.*) of initial coordinates as additional input. A few sample log
|
||||
file run on different machines and different numbers of processors are
|
||||
included in the directories to compare your answers to. E.g. a log
|
||||
file like log.date.crack.foo.P means the "crack" example was run on P
|
||||
processors of machine "foo" on that date (i.e. with that version of
|
||||
LAMMPS).
|
||||
|
||||
Many of the input files have commented-out lines for creating dump
|
||||
files and image files.
|
||||
|
||||
If you uncomment the "dump"_dump.html command in the input script, a
|
||||
text dump file will be produced, which can be animated by various
|
||||
"visualization programs"_http://lammps.sandia.gov/viz.html.
|
||||
|
||||
If you uncomment the "dump image"_dump.html command in the input
|
||||
script, and assuming you have built LAMMPS with a JPG library, JPG
|
||||
snapshot images will be produced when the simulation runs. They can
|
||||
be quickly post-processed into a movie using commands described on the
|
||||
"dump image"_dump_image.html doc page.
|
||||
|
||||
Animations of many of the examples can be viewed on the Movies section
|
||||
of the "LAMMPS web site"_lws.
|
||||
|
||||
There are two kinds of sub-directories in the examples dir. Lowercase
|
||||
dirs contain one or a few simple, quick-to-run problems. Uppercase
|
||||
dirs contain up to several complex scripts that illustrate a
|
||||
particular kind of simulation method or model. Some of these run for
|
||||
longer times, e.g. to measure a particular quantity.
|
||||
|
||||
Lists of both kinds of directories are given below.
|
||||
|
||||
:line
|
||||
|
||||
Lowercase directories :h4
|
||||
|
||||
accelerate: run with various acceleration options (OpenMP, GPU, Phi)
|
||||
airebo: polyethylene with AIREBO potential
|
||||
atm: Axilrod-Teller-Muto potential example
|
||||
balance: dynamic load balancing, 2d system
|
||||
body: body particles, 2d system
|
||||
cmap: CMAP 5-body contributions to CHARMM force field
|
||||
colloid: big colloid particles in a small particle solvent, 2d system
|
||||
comb: models using the COMB potential
|
||||
controller: use of fix controller as a thermostat
|
||||
coreshell: core/shell model using CORESHELL package
|
||||
crack: crack propagation in a 2d solid
|
||||
deposit: deposit atoms and molecules on a surface
|
||||
dipole: point dipolar particles, 2d system
|
||||
dreiding: methanol via Dreiding FF
|
||||
eim: NaCl using the EIM potential
|
||||
ellipse: ellipsoidal particles in spherical solvent, 2d system
|
||||
flow: Couette and Poiseuille flow in a 2d channel
|
||||
friction: frictional contact of spherical asperities between 2d surfaces
|
||||
gcmc: Grand Canonical Monte Carlo (GCMC) via the fix gcmc command
|
||||
granregion: use of fix wall/region/gran as boundary on granular particles
|
||||
hugoniostat: Hugoniostat shock dynamics
|
||||
hyper: global and local hyperdynamics of diffusion on Pt surface
|
||||
indent: spherical indenter into a 2d solid
|
||||
kim: use of potentials from the "OpenKIM Repository"_openkim
|
||||
latte: examples for using fix latte for DFTB via the LATTE library
|
||||
meam: MEAM test for SiC and shear (same as shear examples)
|
||||
melt: rapid melt of 3d LJ system
|
||||
message: demos for LAMMPS client/server coupling with the MESSAGE package
|
||||
micelle: self-assembly of small lipid-like molecules into 2d bilayers
|
||||
min: energy minimization of 2d LJ melt
|
||||
mscg: parameterize a multi-scale coarse-graining (MSCG) model
|
||||
msst: MSST shock dynamics
|
||||
nb3b: use of non-bonded 3-body harmonic pair style
|
||||
neb: nudged elastic band (NEB) calculation for barrier finding
|
||||
nemd: non-equilibrium MD of 2d sheared system
|
||||
obstacle: flow around two voids in a 2d channel
|
||||
peptide: dynamics of a small solvated peptide chain (5-mer)
|
||||
peri: Peridynamic model of cylinder impacted by indenter
|
||||
pour: pouring of granular particles into a 3d box, then chute flow
|
||||
prd: parallel replica dynamics of vacancy diffusion in bulk Si
|
||||
python: using embedded Python in a LAMMPS input script
|
||||
qeq: use of the QEQ package for charge equilibration
|
||||
rdf-adf: computing radial and angle distribution functions for water
|
||||
reax: RDX and TATB models using the ReaxFF
|
||||
rerun: use of rerun and read_dump commands
|
||||
rigid: rigid bodies modeled as independent or coupled
|
||||
shear: sideways shear applied to 2d solid, with and without a void
|
||||
snap: NVE dynamics for BCC tantalum crystal using SNAP potential
|
||||
srd: stochastic rotation dynamics (SRD) particles as solvent
|
||||
streitz: use of Streitz/Mintmire potential with charge equilibration
|
||||
tad: temperature-accelerated dynamics of vacancy diffusion in bulk Si
|
||||
threebody: regression test input for a variety of manybody potentials
|
||||
vashishta: use of the Vashishta potential
|
||||
voronoi: Voronoi tesselation via compute voronoi/atom command :tb(s=:)
|
||||
|
||||
Here is how you can run and visualize one of the sample problems:
|
||||
|
||||
cd indent
|
||||
cp ../../src/lmp_linux . # copy LAMMPS executable to this dir
|
||||
lmp_linux -in in.indent # run the problem :pre
|
||||
|
||||
Running the simulation produces the files {dump.indent} and
|
||||
{log.lammps}. You can visualize the dump file of snapshots with a
|
||||
variety of 3rd-party tools highlighted on the
|
||||
"Visualization"_http://lammps.sandia.gov/viz.html page of the LAMMPS
|
||||
web site.
|
||||
|
||||
If you uncomment the "dump image"_dump_image.html line(s) in the input
|
||||
script a series of JPG images will be produced by the run (assuming
|
||||
you built LAMMPS with JPG support; see the
|
||||
"Build_settings"_Build_settings.html doc page for details). These can
|
||||
be viewed individually or turned into a movie or animated by tools
|
||||
like ImageMagick or QuickTime or various Windows-based tools. See the
|
||||
"dump image"_dump_image.html doc page for more details. E.g. this
|
||||
Imagemagick command would create a GIF file suitable for viewing in a
|
||||
browser.
|
||||
|
||||
% convert -loop 1 *.jpg foo.gif :pre
|
||||
|
||||
:line
|
||||
|
||||
Uppercase directories :h4
|
||||
|
||||
ASPHERE: various aspherical particle models, using ellipsoids, rigid bodies, line/triangle particles, etc
|
||||
COUPLE: examples of how to use LAMMPS as a library
|
||||
DIFFUSE: compute diffusion coefficients via several methods
|
||||
ELASTIC: compute elastic constants at zero temperature
|
||||
ELASTIC_T: compute elastic constants at finite temperature
|
||||
HEAT: compute thermal conductivity for LJ and water via fix ehex
|
||||
KAPPA: compute thermal conductivity via several methods
|
||||
MC: using LAMMPS in a Monte Carlo mode to relax the energy of a system
|
||||
SPIN: examples for features of the SPIN package
|
||||
UNITS: examples that run the same simulation in lj, real, metal units
|
||||
USER: examples for USER packages and USER-contributed commands
|
||||
VISCOSITY: compute viscosity via several methods :tb(s=:)
|
||||
|
||||
Nearly all of these directories have README files which give more
|
||||
details on how to understand and use their contents.
|
||||
|
||||
The USER directory has a large number of sub-directories which
|
||||
correspond by name to a USER package. They contain scripts that
|
||||
illustrate how to use the command(s) provided in that package. Many
|
||||
of the sub-directories have their own README files which give further
|
||||
instructions. See the "Packages_details"_Packages_details.html doc
|
||||
page for more info on specific USER packages.
|
||||
|
||||
:link(openkim,https://openkim.org)
|
|
@ -1,191 +0,0 @@
|
|||
"Previous Section"_Performance.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
|
||||
Section"_Examples.html :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
Howto discussions :h2
|
||||
|
||||
These doc pages describe how to perform various tasks with LAMMPS,
|
||||
both for users and developers. The
|
||||
"glossary"_http://lammps.sandia.gov website page also lists MD
|
||||
terminology with links to corresponding LAMMPS manual pages. The
|
||||
example input scripts included in the examples dir of the LAMMPS
|
||||
distribution and highlighted on the "Examples"_Examples.html doc page
|
||||
also show how to setup and run various kinds of simulations.
|
||||
|
||||
Tutorials howto :h3
|
||||
|
||||
<!-- RST
|
||||
|
||||
.. toctree::
|
||||
:name: tutorials
|
||||
:maxdepth: 1
|
||||
|
||||
Howto_github
|
||||
Howto_pylammps
|
||||
Howto_bash
|
||||
|
||||
END_RST -->
|
||||
|
||||
<!-- HTML_ONLY -->
|
||||
|
||||
"Using GitHub with LAMMPS"_Howto_github.html
|
||||
"PyLAMMPS interface to LAMMPS"_Howto_pylammps.html
|
||||
"Using LAMMPS with bash on Windows"_Howto_bash.html :all(b)
|
||||
|
||||
<!-- END_HTML_ONLY -->
|
||||
|
||||
General howto :h3
|
||||
|
||||
<!-- RST
|
||||
|
||||
.. toctree::
|
||||
:name: general_howto
|
||||
:maxdepth: 1
|
||||
|
||||
Howto_restart
|
||||
Howto_viz
|
||||
Howto_multiple
|
||||
Howto_replica
|
||||
Howto_library
|
||||
Howto_couple
|
||||
Howto_client_server
|
||||
|
||||
END_RST -->
|
||||
|
||||
<!-- HTML_ONLY -->
|
||||
|
||||
"Restart a simulation"_Howto_restart.html
|
||||
"Visualize LAMMPS snapshots"_Howto_viz.html
|
||||
"Run multiple simulations from one input script"_Howto_multiple.html
|
||||
"Multi-replica simulations"_Howto_replica.html
|
||||
"Library interface to LAMMPS"_Howto_library.html
|
||||
"Couple LAMMPS to other codes"_Howto_couple.html
|
||||
"Using LAMMPS in client/server mode"_Howto_client_server.html :all(b)
|
||||
|
||||
<!-- END_HTML_ONLY -->
|
||||
|
||||
Settings howto :h3
|
||||
|
||||
<!-- RST
|
||||
|
||||
.. toctree::
|
||||
:name: settings
|
||||
:maxdepth: 1
|
||||
|
||||
Howto_2d
|
||||
Howto_triclinic
|
||||
Howto_thermostat
|
||||
Howto_barostat
|
||||
Howto_walls
|
||||
Howto_nemd
|
||||
Howto_dispersion
|
||||
|
||||
END_RST -->
|
||||
|
||||
<!-- HTML_ONLY -->
|
||||
|
||||
"2d simulations"_Howto_2d.html
|
||||
"Triclinic (non-orthogonal) simulation boxes"_Howto_triclinic.html
|
||||
"Thermostats"_Howto_thermostat.html
|
||||
"Barostats"_Howto_barostat.html
|
||||
"Walls"_Howto_walls.html
|
||||
"NEMD simulations"_Howto_nemd.html
|
||||
"Long-range dispersion settings"_Howto_dispersion.html :all(b)
|
||||
|
||||
<!-- END_HTML_ONLY -->
|
||||
|
||||
|
||||
Analysis howto :h3
|
||||
|
||||
<!-- RST
|
||||
|
||||
.. toctree::
|
||||
:name: analysis
|
||||
:maxdepth: 1
|
||||
|
||||
Howto_output
|
||||
Howto_chunk
|
||||
Howto_temperature
|
||||
Howto_elastic
|
||||
Howto_kappa
|
||||
Howto_viscosity
|
||||
Howto_diffusion
|
||||
|
||||
END_RST -->
|
||||
|
||||
<!-- HTML_ONLY -->
|
||||
|
||||
"Output from LAMMPS (thermo, dumps, computes, fixes, variables)"_Howto_output.html
|
||||
"Use chunks to calculate system properties"_Howto_chunk.html :all(b)
|
||||
"Calculate temperature"_Howto_temperature.html
|
||||
"Calculate elastic constants"_Howto_elastic.html
|
||||
"Calculate thermal conductivity"_Howto_kappa.html
|
||||
"Calculate viscosity"_Howto_viscosity.html
|
||||
"Calculate a diffusion coefficient"_Howto_diffusion.html :all(b)
|
||||
|
||||
<!-- END_HTML_ONLY -->
|
||||
|
||||
Force fields howto :h3
|
||||
|
||||
<!-- RST
|
||||
|
||||
.. toctree::
|
||||
:name: force
|
||||
:maxdepth: 1
|
||||
|
||||
Howto_bioFF
|
||||
Howto_tip3p
|
||||
Howto_tip4p
|
||||
Howto_spc
|
||||
|
||||
END_RST -->
|
||||
|
||||
<!-- HTML_ONLY -->
|
||||
|
||||
"CHARMM, AMBER, COMPASS, and DREIDING force fields"_Howto_bioFF.html
|
||||
"TIP3P water model"_Howto_tip3p.html
|
||||
"TIP4P water model"_Howto_tip4p.html
|
||||
"SPC water model"_Howto_spc.html :all(b)
|
||||
|
||||
<!-- END_HTML_ONLY -->
|
||||
|
||||
Packages howto :h3
|
||||
|
||||
<!-- RST
|
||||
|
||||
.. toctree::
|
||||
:name: packages
|
||||
:maxdepth: 1
|
||||
|
||||
Howto_spherical
|
||||
Howto_granular
|
||||
Howto_body
|
||||
Howto_polarizable
|
||||
Howto_coreshell
|
||||
Howto_drude
|
||||
Howto_drude2
|
||||
Howto_manifold
|
||||
Howto_spins
|
||||
|
||||
END_RST -->
|
||||
|
||||
|
||||
<!-- HTML_ONLY -->
|
||||
|
||||
"Finite-size spherical and aspherical particles"_Howto_spherical.html
|
||||
"Granular models"_Howto_granular.html
|
||||
"Body style particles"_Howto_body.html
|
||||
"Polarizable models"_Howto_polarizable.html
|
||||
"Adiabatic core/shell model"_Howto_coreshell.html
|
||||
"Drude induced dipoles"_Howto_drude.html
|
||||
"Drude induced dipoles (extended)"_Howto_drude2.html
|
||||
"Manifolds (surfaces)"_Howto_manifold.html
|
||||
"Magnetic spins"_Howto_spins.html :all(b)
|
||||
|
||||
<!-- END_HTML_ONLY -->
|
|
@ -1,48 +0,0 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
2d simulations :h3
|
||||
|
||||
Use the "dimension"_dimension.html command to specify a 2d simulation.
|
||||
|
||||
Make the simulation box periodic in z via the "boundary"_boundary.html
|
||||
command. This is the default.
|
||||
|
||||
If using the "create box"_create_box.html command to define a
|
||||
simulation box, set the z dimensions narrow, but finite, so that the
|
||||
create_atoms command will tile the 3d simulation box with a single z
|
||||
plane of atoms - e.g.
|
||||
|
||||
"create box"_create_box.html 1 -10 10 -10 10 -0.25 0.25 :pre
|
||||
|
||||
If using the "read data"_read_data.html command to read in a file of
|
||||
atom coordinates, set the "zlo zhi" values to be finite but narrow,
|
||||
similar to the create_box command settings just described. For each
|
||||
atom in the file, assign a z coordinate so it falls inside the
|
||||
z-boundaries of the box - e.g. 0.0.
|
||||
|
||||
Use the "fix enforce2d"_fix_enforce2d.html command as the last
|
||||
defined fix to insure that the z-components of velocities and forces
|
||||
are zeroed out every timestep. The reason to make it the last fix is
|
||||
so that any forces induced by other fixes will be zeroed out.
|
||||
|
||||
Many of the example input scripts included in the LAMMPS distribution
|
||||
are for 2d models.
|
||||
|
||||
NOTE: Some models in LAMMPS treat particles as finite-size spheres, as
|
||||
opposed to point particles. See the "atom_style
|
||||
sphere"_atom_style.html and "fix nve/sphere"_fix_nve_sphere.html
|
||||
commands for details. By default, for 2d simulations, such particles
|
||||
will still be modeled as 3d spheres, not 2d discs (circles), meaning
|
||||
their moment of inertia will be that of a sphere. If you wish to
|
||||
model them as 2d discs, see the "set density/disc"_set.html command
|
||||
and the {disc} option for the "fix nve/sphere"_fix_nve_sphere.html,
|
||||
"fix nvt/sphere"_fix_nvt_sphere.html, "fix
|
||||
nph/sphere"_fix_nph_sphere.html, "fix npt/sphere"_fix_npt_sphere.html
|
||||
commands.
|
|
@ -1,75 +0,0 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Barostats :h3
|
||||
|
||||
Barostatting means controlling the pressure in an MD simulation.
|
||||
"Thermostatting"_Howto_thermostat.html means controlling the
|
||||
temperature of the particles. Since the pressure includes a kinetic
|
||||
component due to particle velocities, both these operations require
|
||||
calculation of the temperature. Typically a target temperature (T)
|
||||
and/or pressure (P) is specified by the user, and the thermostat or
|
||||
barostat attempts to equilibrate the system to the requested T and/or
|
||||
P.
|
||||
|
||||
Barostatting in LAMMPS is performed by "fixes"_fix.html. Two
|
||||
barostatting methods are currently available: Nose-Hoover (npt and
|
||||
nph) and Berendsen:
|
||||
|
||||
"fix npt"_fix_nh.html
|
||||
"fix npt/sphere"_fix_npt_sphere.html
|
||||
"fix npt/asphere"_fix_npt_asphere.html
|
||||
"fix nph"_fix_nh.html
|
||||
"fix press/berendsen"_fix_press_berendsen.html :ul
|
||||
|
||||
The "fix npt"_fix_nh.html commands include a Nose-Hoover thermostat
|
||||
and barostat. "Fix nph"_fix_nh.html is just a Nose/Hoover barostat;
|
||||
it does no thermostatting. Both "fix nph"_fix_nh.html and "fix
|
||||
press/berendsen"_fix_press_berendsen.html can be used in conjunction
|
||||
with any of the thermostatting fixes.
|
||||
|
||||
As with the "thermostats"_Howto_thermostat.html, "fix npt"_fix_nh.html
|
||||
and "fix nph"_fix_nh.html only use translational motion of the
|
||||
particles in computing T and P and performing thermo/barostatting.
|
||||
"Fix npt/sphere"_fix_npt_sphere.html and "fix
|
||||
npt/asphere"_fix_npt_asphere.html thermo/barostat using not only
|
||||
translation velocities but also rotational velocities for spherical
|
||||
and aspherical particles.
|
||||
|
||||
All of the barostatting fixes use the "compute
|
||||
pressure"_compute_pressure.html compute to calculate a current
|
||||
pressure. By default, this compute is created with a simple "compute
|
||||
temp"_compute_temp.html (see the last argument of the "compute
|
||||
pressure"_compute_pressure.html command), which is used to calculated
|
||||
the kinetic component of the pressure. The barostatting fixes can
|
||||
also use temperature computes that remove bias for the purpose of
|
||||
computing the kinetic component which contributes to the current
|
||||
pressure. See the doc pages for the individual fixes and for the
|
||||
"fix_modify"_fix_modify.html command for instructions on how to assign
|
||||
a temperature or pressure compute to a barostatting fix.
|
||||
|
||||
NOTE: As with the thermostats, the Nose/Hoover methods ("fix
|
||||
npt"_fix_nh.html and "fix nph"_fix_nh.html) perform time integration.
|
||||
"Fix press/berendsen"_fix_press_berendsen.html does NOT, so it should
|
||||
be used with one of the constant NVE fixes or with one of the NVT
|
||||
fixes.
|
||||
|
||||
Thermodynamic output, which can be setup via the
|
||||
"thermo_style"_thermo_style.html command, often includes pressure
|
||||
values. As explained on the doc page for the
|
||||
"thermo_style"_thermo_style.html command, the default pressure is
|
||||
setup by the thermo command itself. It is NOT the pressure associated
|
||||
with any barostatting fix you have defined or with any compute you
|
||||
have defined that calculates a pressure. The doc pages for the
|
||||
barostatting fixes explain the ID of the pressure compute they create.
|
||||
Thus if you want to view these pressures, you need to specify them
|
||||
explicitly via the "thermo_style custom"_thermo_style.html command.
|
||||
Or you can use the "thermo_modify"_thermo_modify.html command to
|
||||
re-define what pressure compute is used for default thermodynamic
|
||||
output.
|
|
@ -1,136 +0,0 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
CHARMM, AMBER, COMPASS, and DREIDING force fields :h3
|
||||
|
||||
A force field has 2 parts: the formulas that define it and the
|
||||
coefficients used for a particular system. Here we only discuss
|
||||
formulas implemented in LAMMPS that correspond to formulas commonly
|
||||
used in the CHARMM, AMBER, COMPASS, and DREIDING force fields. Setting
|
||||
coefficients is done either from special sections in an input data file
|
||||
via the "read_data"_read_data.html command or in the input script with
|
||||
commands like "pair_coeff"_pair_coeff.html or
|
||||
"bond_coeff"_bond_coeff.html and so on. See the "Tools"_Tools.html doc
|
||||
page for additional tools that can use CHARMM, AMBER, or Materials
|
||||
Studio generated files to assign force field coefficients and convert
|
||||
their output into LAMMPS input.
|
||||
|
||||
See "(MacKerell)"_#howto-MacKerell for a description of the CHARMM force
|
||||
field. See "(Cornell)"_#howto-Cornell for a description of the AMBER
|
||||
force field. See "(Sun)"_#howto-Sun for a description of the COMPASS
|
||||
force field.
|
||||
|
||||
:link(charmm,http://www.scripps.edu/brooks)
|
||||
:link(amber,http://amber.scripps.edu)
|
||||
|
||||
The interaction styles listed below compute force field formulas that
|
||||
are consistent with common options in CHARMM or AMBER. See each
|
||||
command's documentation for the formula it computes.
|
||||
|
||||
"bond_style"_bond_harmonic.html harmonic
|
||||
"angle_style"_angle_charmm.html charmm
|
||||
"dihedral_style"_dihedral_charmm.html charmmfsh
|
||||
"dihedral_style"_dihedral_charmm.html charmm
|
||||
"pair_style"_pair_charmm.html lj/charmmfsw/coul/charmmfsh
|
||||
"pair_style"_pair_charmm.html lj/charmmfsw/coul/long
|
||||
"pair_style"_pair_charmm.html lj/charmm/coul/charmm
|
||||
"pair_style"_pair_charmm.html lj/charmm/coul/charmm/implicit
|
||||
"pair_style"_pair_charmm.html lj/charmm/coul/long :ul
|
||||
|
||||
"special_bonds"_special_bonds.html charmm
|
||||
"special_bonds"_special_bonds.html amber :ul
|
||||
|
||||
NOTE: For CHARMM, newer {charmmfsw} or {charmmfsh} styles were released
|
||||
in March 2017. We recommend they be used instead of the older {charmm}
|
||||
styles. See discussion of the differences on the "pair
|
||||
charmm"_pair_charmm.html and "dihedral charmm"_dihedral_charmm.html doc
|
||||
pages.
|
||||
|
||||
COMPASS is a general force field for atomistic simulation of common
|
||||
organic molecules, inorganic small molecules, and polymers which was
|
||||
developed using ab initio and empirical parameterization techniques.
|
||||
See the "Tools"_Tools.html doc page for the msi2lmp tool for creating
|
||||
LAMMPS template input and data files from BIOVIA's Materials Studio
|
||||
files. Please note that the msi2lmp tool is very old and largely
|
||||
unmaintained, so it does not support all features of Materials Studio
|
||||
provided force field files, especially additions during the last decade.
|
||||
You should watch the output carefully and compare results, where
|
||||
possible. See "(Sun)"_#howto-Sun for a description of the COMPASS force
|
||||
field.
|
||||
|
||||
These interaction styles listed below compute force field formulas that
|
||||
are consistent with the COMPASS force field. See each command's
|
||||
documentation for the formula it computes.
|
||||
|
||||
"bond_style"_bond_class2.html class2
|
||||
"angle_style"_angle_class2.html class2
|
||||
"dihedral_style"_dihedral_class2.html class2
|
||||
"improper_style"_improper_class2.html class2 :ul
|
||||
|
||||
"pair_style"_pair_class2.html lj/class2
|
||||
"pair_style"_pair_class2.html lj/class2/coul/cut
|
||||
"pair_style"_pair_class2.html lj/class2/coul/long :ul
|
||||
|
||||
"special_bonds"_special_bonds.html lj/coul 0 0 1 :ul
|
||||
|
||||
DREIDING is a generic force field developed by the "Goddard
|
||||
group"_http://www.wag.caltech.edu at Caltech and is useful for
|
||||
predicting structures and dynamics of organic, biological and main-group
|
||||
inorganic molecules. The philosophy in DREIDING is to use general force
|
||||
constants and geometry parameters based on simple hybridization
|
||||
considerations, rather than individual force constants and geometric
|
||||
parameters that depend on the particular combinations of atoms involved
|
||||
in the bond, angle, or torsion terms. DREIDING has an "explicit hydrogen
|
||||
bond term"_pair_hbond_dreiding.html to describe interactions involving a
|
||||
hydrogen atom on very electronegative atoms (N, O, F).
|
||||
|
||||
See "(Mayo)"_#howto-Mayo for a description of the DREIDING force field
|
||||
|
||||
The interaction styles listed below compute force field formulas that
|
||||
are consistent with the DREIDING force field. See each command's
|
||||
documentation for the formula it computes.
|
||||
|
||||
"bond_style"_bond_harmonic.html harmonic
|
||||
"bond_style"_bond_morse.html morse :ul
|
||||
|
||||
"angle_style"_angle_harmonic.html harmonic
|
||||
"angle_style"_angle_cosine.html cosine
|
||||
"angle_style"_angle_cosine_periodic.html cosine/periodic :ul
|
||||
|
||||
"dihedral_style"_dihedral_charmm.html charmm
|
||||
"improper_style"_improper_umbrella.html umbrella :ul
|
||||
|
||||
"pair_style"_pair_buck.html buck
|
||||
"pair_style"_pair_buck.html buck/coul/cut
|
||||
"pair_style"_pair_buck.html buck/coul/long
|
||||
"pair_style"_pair_lj.html lj/cut
|
||||
"pair_style"_pair_lj.html lj/cut/coul/cut
|
||||
"pair_style"_pair_lj.html lj/cut/coul/long :ul
|
||||
|
||||
"pair_style"_pair_hbond_dreiding.html hbond/dreiding/lj
|
||||
"pair_style"_pair_hbond_dreiding.html hbond/dreiding/morse :ul
|
||||
|
||||
"special_bonds"_special_bonds.html dreiding :ul
|
||||
|
||||
:line
|
||||
|
||||
:link(howto-MacKerell)
|
||||
[(MacKerell)] MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field,
|
||||
Fischer, Gao, Guo, Ha, et al, J Phys Chem, 102, 3586 (1998).
|
||||
|
||||
:link(howto-Cornell)
|
||||
[(Cornell)] Cornell, Cieplak, Bayly, Gould, Merz, Ferguson,
|
||||
Spellmeyer, Fox, Caldwell, Kollman, JACS 117, 5179-5197 (1995).
|
||||
|
||||
:link(howto-Sun)
|
||||
[(Sun)] Sun, J. Phys. Chem. B, 102, 7338-7364 (1998).
|
||||
|
||||
:link(howto-Mayo)
|
||||
[(Mayo)] Mayo, Olfason, Goddard III, J Phys Chem, 94, 8897-8909
|
||||
(1990).
|
|
@ -1,456 +0,0 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Body particles :h3
|
||||
|
||||
[Overview:]
|
||||
|
||||
In LAMMPS, body particles are generalized finite-size particles.
|
||||
Individual body particles can represent complex entities, such as
|
||||
surface meshes of discrete points, collections of sub-particles,
|
||||
deformable objects, etc. Note that other kinds of finite-size
|
||||
spherical and aspherical particles are also supported by LAMMPS, such
|
||||
as spheres, ellipsoids, line segments, and triangles, but they are
|
||||
simpler entities that body particles. See the "Howto
|
||||
spherical"_Howto_spherical.html doc page for a general overview of all
|
||||
these particle types.
|
||||
|
||||
Body particles are used via the "atom_style body"_atom_style.html
|
||||
command. It takes a body style as an argument. The current body
|
||||
styles supported by LAMMPS are as follows. The name in the first
|
||||
column is used as the {bstyle} argument for the "atom_style
|
||||
body"_atom_style.html command.
|
||||
|
||||
{nparticle} : rigid body with N sub-particles
|
||||
{rounded/polygon} : 2d polygons with N vertices
|
||||
{rounded/polyhedron} : 3d polyhedra with N vertices, E edges and F faces :tb(s=:)
|
||||
|
||||
The body style determines what attributes are stored for each body and
|
||||
thus how they can be used to compute pairwise body/body or
|
||||
bond/non-body (point particle) interactions. More details of each
|
||||
style are described below.
|
||||
|
||||
More styles may be added in the future. See the "Modify
|
||||
body"_Modify_body.html doc page for details on how to add a new body
|
||||
style to the code.
|
||||
|
||||
:line
|
||||
|
||||
[When to use body particles:]
|
||||
|
||||
You should not use body particles to model a rigid body made of
|
||||
simpler particles (e.g. point, sphere, ellipsoid, line segment,
|
||||
triangular particles), if the interaction between pairs of rigid
|
||||
bodies is just the summation of pairwise interactions between the
|
||||
simpler particles. LAMMPS already supports this kind of model via the
|
||||
"fix rigid"_fix_rigid.html command. Any of the numerous pair styles
|
||||
that compute interactions between simpler particles can be used. The
|
||||
"fix rigid"_fix_rigid.html command time integrates the motion of the
|
||||
rigid bodies. All of the standard LAMMPS commands for thermostatting,
|
||||
adding constraints, performing output, etc will operate as expected on
|
||||
the simple particles.
|
||||
|
||||
By contrast, when body particles are used, LAMMPS treats an entire
|
||||
body as a single particle for purposes of computing pairwise
|
||||
interactions, building neighbor lists, migrating particles between
|
||||
processors, output of particles to a dump file, etc. This means that
|
||||
interactions between pairs of bodies or between a body and non-body
|
||||
(point) particle need to be encoded in an appropriate pair style. If
|
||||
such a pair style were to mimic the "fix rigid"_fix_rigid.html model,
|
||||
it would need to loop over the entire collection of interactions
|
||||
between pairs of simple particles within the two bodies, each time a
|
||||
single body/body interaction was computed.
|
||||
|
||||
Thus it only makes sense to use body particles and develop such a pair
|
||||
style, when particle/particle interactions are more complex than what
|
||||
the "fix rigid"_fix_rigid.html command can already calculate. For
|
||||
example, consider particles with one or more of the following
|
||||
attributes:
|
||||
|
||||
represented by a surface mesh
|
||||
represented by a collection of geometric entities (e.g. planes + spheres)
|
||||
deformable
|
||||
internal stress that induces fragmentation :ul
|
||||
|
||||
For these models, the interaction between pairs of particles is likely
|
||||
to be more complex than the summation of simple pairwise interactions.
|
||||
An example is contact or frictional forces between particles with
|
||||
planar surfaces that inter-penetrate. Likewise, the body particle may
|
||||
store internal state, such as a stress tensor used to compute a
|
||||
fracture criterion.
|
||||
|
||||
These are additional LAMMPS commands that can be used with body
|
||||
particles of different styles
|
||||
|
||||
"fix nve/body"_fix_nve_body.html : integrate motion of a body particle in NVE ensemble
|
||||
"fix nvt/body"_fix_nvt_body.html : ditto for NVT ensemble
|
||||
"fix npt/body"_fix_npt_body.html : ditto for NPT ensemble
|
||||
"fix nph/body"_fix_nph_body.html : ditto for NPH ensemble
|
||||
"compute body/local"_compute_body_local.html : store sub-particle attributes of a body particle
|
||||
"compute temp/body"_compute_temp_body.html : compute temperature of body particles
|
||||
"dump local"_dump.html : output sub-particle attributes of a body particle
|
||||
"dump image"_dump_image.html : output body particle attributes as an image :tb(s=:)
|
||||
|
||||
The pair styles defined for use with specific body styles are listed
|
||||
in the sections below.
|
||||
|
||||
:line
|
||||
|
||||
[Specifics of body style nparticle:]
|
||||
|
||||
The {nparticle} body style represents body particles as a rigid body
|
||||
with a variable number N of sub-particles. It is provided as a
|
||||
vanilla, prototypical example of a body particle, although as
|
||||
mentioned above, the "fix rigid"_fix_rigid.html command already
|
||||
duplicates its functionality.
|
||||
|
||||
The atom_style body command for this body style takes two additional
|
||||
arguments:
|
||||
|
||||
atom_style body nparticle Nmin Nmax
|
||||
Nmin = minimum # of sub-particles in any body in the system
|
||||
Nmax = maximum # of sub-particles in any body in the system :pre
|
||||
|
||||
The Nmin and Nmax arguments are used to bound the size of data
|
||||
structures used internally by each particle.
|
||||
|
||||
When the "read_data"_read_data.html command reads a data file for this
|
||||
body style, the following information must be provided for each entry
|
||||
in the {Bodies} section of the data file:
|
||||
|
||||
atom-ID 1 M
|
||||
N
|
||||
ixx iyy izz ixy ixz iyz
|
||||
x1 y1 z1
|
||||
...
|
||||
xN yN zN :pre
|
||||
|
||||
where M = 6 + 3*N, and N is the number of sub-particles in the body
|
||||
particle.
|
||||
|
||||
The integer line has a single value N. The floating point line(s)
|
||||
list 6 moments of inertia followed by the coordinates of the N
|
||||
sub-particles (x1 to zN) as 3N values. These values can be listed on
|
||||
as many lines as you wish; see the "read_data"_read_data.html command
|
||||
for more details.
|
||||
|
||||
The 6 moments of inertia (ixx,iyy,izz,ixy,ixz,iyz) should be the
|
||||
values consistent with the current orientation of the rigid body
|
||||
around its center of mass. The values are with respect to the
|
||||
simulation box XYZ axes, not with respect to the principal axes of the
|
||||
rigid body itself. LAMMPS performs the latter calculation internally.
|
||||
The coordinates of each sub-particle are specified as its x,y,z
|
||||
displacement from the center-of-mass of the body particle. The
|
||||
center-of-mass position of the particle is specified by the x,y,z
|
||||
values in the {Atoms} section of the data file, as is the total mass
|
||||
of the body particle.
|
||||
|
||||
The "pair_style body/nparticle"_pair_body_nparticle.html command can be used
|
||||
with this body style to compute body/body and body/non-body interactions.
|
||||
|
||||
For output purposes via the "compute
|
||||
body/local"_compute_body_local.html and "dump local"_dump.html
|
||||
commands, this body style produces one datum for each of the N
|
||||
sub-particles in a body particle. The datum has 3 values:
|
||||
|
||||
1 = x position of sub-particle
|
||||
2 = y position of sub-particle
|
||||
3 = z position of sub-particle :pre
|
||||
|
||||
These values are the current position of the sub-particle within the
|
||||
simulation domain, not a displacement from the center-of-mass (COM) of
|
||||
the body particle itself. These values are calculated using the
|
||||
current COM and orientation of the body particle.
|
||||
|
||||
For images created by the "dump image"_dump_image.html command, if the
|
||||
{body} keyword is set, then each body particle is drawn as a
|
||||
collection of spheres, one for each sub-particle. The size of each
|
||||
sphere is determined by the {bflag1} parameter for the {body} keyword.
|
||||
The {bflag2} argument is ignored.
|
||||
|
||||
:line
|
||||
|
||||
[Specifics of body style rounded/polygon:]
|
||||
|
||||
The {rounded/polygon} body style represents body particles as a 2d
|
||||
polygon with a variable number of N vertices. This style can only be
|
||||
used for 2d models; see the "boundary"_boundary.html command. See the
|
||||
"pair_style body/rounded/polygon" doc page for a diagram of two
|
||||
squares with rounded circles at the vertices. Special cases for N = 1
|
||||
(circle) and N = 2 (rod with rounded ends) can also be specified.
|
||||
|
||||
One use of this body style is for 2d discrete element models, as
|
||||
described in "Fraige"_#body-Fraige.
|
||||
|
||||
Similar to body style {nparticle}, the atom_style body command for
|
||||
this body style takes two additional arguments:
|
||||
|
||||
atom_style body rounded/polygon Nmin Nmax
|
||||
Nmin = minimum # of vertices in any body in the system
|
||||
Nmax = maximum # of vertices in any body in the system :pre
|
||||
|
||||
The Nmin and Nmax arguments are used to bound the size of data
|
||||
structures used internally by each particle.
|
||||
|
||||
When the "read_data"_read_data.html command reads a data file for this
|
||||
body style, the following information must be provided for each entry
|
||||
in the {Bodies} section of the data file:
|
||||
|
||||
atom-ID 1 M
|
||||
N
|
||||
ixx iyy izz ixy ixz iyz
|
||||
x1 y1 z1
|
||||
...
|
||||
xN yN zN
|
||||
i j j k k ...
|
||||
diameter :pre
|
||||
|
||||
where M = 6 + 3*N + 2*N + 1, and N is the number of vertices in the
|
||||
body particle.
|
||||
|
||||
The integer line has a single value N. The floating point line(s)
|
||||
list 6 moments of inertia followed by the coordinates of the N
|
||||
vertices (x1 to zN) as 3N values (with z = 0.0 for each), followed by
|
||||
2N vertex indices corresponding to the end points of the N edges,
|
||||
followed by a single diameter value = the rounded diameter of the
|
||||
circle that surrounds each vertex. The diameter value can be different
|
||||
for each body particle. These floating-point values can be listed on
|
||||
as many lines as you wish; see the "read_data"_read_data.html command
|
||||
for more details.
|
||||
|
||||
The 6 moments of inertia (ixx,iyy,izz,ixy,ixz,iyz) should be the
|
||||
values consistent with the current orientation of the rigid body
|
||||
around its center of mass. The values are with respect to the
|
||||
simulation box XYZ axes, not with respect to the principal axes of the
|
||||
rigid body itself. LAMMPS performs the latter calculation internally.
|
||||
The coordinates of each vertex are specified as its x,y,z displacement
|
||||
from the center-of-mass of the body particle. The center-of-mass
|
||||
position of the particle is specified by the x,y,z values in the
|
||||
{Atoms} section of the data file.
|
||||
|
||||
For example, the following information would specify a square particle
|
||||
whose edge length is sqrt(2) and rounded diameter is 1.0. The
|
||||
orientation of the square is aligned with the xy coordinate axes which
|
||||
is consistent with the 6 moments of inertia: ixx iyy izz ixy ixz iyz =
|
||||
1 1 4 0 0 0. Note that only Izz matters in 2D simulations.
|
||||
|
||||
3 1 27
|
||||
4
|
||||
1 1 4 0 0 0
|
||||
-0.7071 -0.7071 0
|
||||
-0.7071 0.7071 0
|
||||
0.7071 0.7071 0
|
||||
0.7071 -0.7071 0
|
||||
0 1
|
||||
1 2
|
||||
2 3
|
||||
3 0
|
||||
1.0 :pre
|
||||
|
||||
A rod in 2D, whose length is 4.0, mass 1.0, rounded at two ends
|
||||
by circles of diameter 0.5, is specified as follows:
|
||||
|
||||
1 1 13
|
||||
2
|
||||
1 1 1.33333 0 0 0
|
||||
-2 0 0
|
||||
2 0 0
|
||||
0.5 :pre
|
||||
|
||||
A disk, whose diameter is 3.0, mass 1.0, is specified as follows:
|
||||
|
||||
1 1 10
|
||||
1
|
||||
1 1 4.5 0 0 0
|
||||
0 0 0
|
||||
3.0 :pre
|
||||
|
||||
The "pair_style body/rounded/polygon"_pair_body_rounded_polygon.html
|
||||
command can be used with this body style to compute body/body
|
||||
interactions. The "fix wall/body/polygon"_fix_wall_body_polygon.html
|
||||
command can be used with this body style to compute the interaction of
|
||||
body particles with a wall.
|
||||
|
||||
:line
|
||||
|
||||
[Specifics of body style rounded/polyhedron:]
|
||||
|
||||
The {rounded/polyhedron} body style represents body particles as a 3d
|
||||
polyhedron with a variable number of N vertices, E edges and F faces.
|
||||
This style can only be used for 3d models; see the
|
||||
"boundary"_boundary.html command. See the "pair_style
|
||||
body/rounded/polygon" doc page for a diagram of a two 2d squares with
|
||||
rounded circles at the vertices. A 3d cube with rounded spheres at
|
||||
the 8 vertices and 12 rounded edges would be similar. Special cases
|
||||
for N = 1 (sphere) and N = 2 (rod with rounded ends) can also be
|
||||
specified.
|
||||
|
||||
This body style is for 3d discrete element models, as described in
|
||||
"Wang"_#body-Wang.
|
||||
|
||||
Similar to body style {rounded/polygon}, the atom_style body command
|
||||
for this body style takes two additional arguments:
|
||||
|
||||
atom_style body rounded/polyhedron Nmin Nmax
|
||||
Nmin = minimum # of vertices in any body in the system
|
||||
Nmax = maximum # of vertices in any body in the system :pre
|
||||
|
||||
The Nmin and Nmax arguments are used to bound the size of data
|
||||
structures used internally by each particle.
|
||||
|
||||
When the "read_data"_read_data.html command reads a data file for this
|
||||
body style, the following information must be provided for each entry
|
||||
in the {Bodies} section of the data file:
|
||||
|
||||
atom-ID 3 M
|
||||
N E F
|
||||
ixx iyy izz ixy ixz iyz
|
||||
x1 y1 z1
|
||||
...
|
||||
xN yN zN
|
||||
0 1
|
||||
1 2
|
||||
2 3
|
||||
...
|
||||
0 1 2 -1
|
||||
0 2 3 -1
|
||||
...
|
||||
1 2 3 4
|
||||
diameter :pre
|
||||
|
||||
where M = 6 + 3*N + 2*E + 4*F + 1, and N is the number of vertices in
|
||||
the body particle, E = number of edges, F = number of faces.
|
||||
|
||||
The integer line has three values: number of vertices (N), number of
|
||||
edges (E) and number of faces (F). The floating point line(s) list 6
|
||||
moments of inertia followed by the coordinates of the N vertices (x1
|
||||
to zN) as 3N values, followed by 2N vertex indices corresponding to
|
||||
the end points of the E edges, then 4*F vertex indices defining F
|
||||
faces. The last value is the diameter value = the rounded diameter of
|
||||
the sphere that surrounds each vertex. The diameter value can be
|
||||
different for each body particle. These floating-point values can be
|
||||
listed on as many lines as you wish; see the
|
||||
"read_data"_read_data.html command for more details. Because the
|
||||
maximum number of vertices per face is hard-coded to be 4
|
||||
(i.e. quadrilaterals), faces with more than 4 vertices need to be
|
||||
split into triangles or quadrilaterals. For triangular faces, the
|
||||
last vertex index should be set to -1.
|
||||
|
||||
The ordering of the 4 vertices within a face should follow
|
||||
the right-hand rule so that the normal vector of the face points
|
||||
outwards from the center of mass.
|
||||
|
||||
The 6 moments of inertia (ixx,iyy,izz,ixy,ixz,iyz) should be the
|
||||
values consistent with the current orientation of the rigid body
|
||||
around its center of mass. The values are with respect to the
|
||||
simulation box XYZ axes, not with respect to the principal axes of the
|
||||
rigid body itself. LAMMPS performs the latter calculation internally.
|
||||
The coordinates of each vertex are specified as its x,y,z displacement
|
||||
from the center-of-mass of the body particle. The center-of-mass
|
||||
position of the particle is specified by the x,y,z values in the
|
||||
{Atoms} section of the data file.
|
||||
|
||||
For example, the following information would specify a cubic particle
|
||||
whose edge length is 2.0 and rounded diameter is 0.5.
|
||||
The orientation of the cube is aligned with the xyz coordinate axes
|
||||
which is consistent with the 6 moments of inertia: ixx iyy izz ixy ixz
|
||||
iyz = 0.667 0.667 0.667 0 0 0.
|
||||
|
||||
1 3 79
|
||||
8 12 6
|
||||
0.667 0.667 0.667 0 0 0
|
||||
1 1 1
|
||||
1 -1 1
|
||||
-1 -1 1
|
||||
-1 1 1
|
||||
1 1 -1
|
||||
1 -1 -1
|
||||
-1 -1 -1
|
||||
-1 1 -1
|
||||
0 1
|
||||
1 2
|
||||
2 3
|
||||
3 0
|
||||
4 5
|
||||
5 6
|
||||
6 7
|
||||
7 4
|
||||
0 4
|
||||
1 5
|
||||
2 6
|
||||
3 7
|
||||
0 1 2 3
|
||||
4 5 6 7
|
||||
0 1 5 4
|
||||
1 2 6 5
|
||||
2 3 7 6
|
||||
3 0 4 7
|
||||
0.5 :pre
|
||||
|
||||
A rod in 3D, whose length is 4.0, mass 1.0 and rounded at two ends
|
||||
by circles of diameter 0.5, is specified as follows:
|
||||
|
||||
1 1 13
|
||||
2
|
||||
0 1.33333 1.33333 0 0 0
|
||||
-2 0 0
|
||||
2 0 0
|
||||
0.5 :pre
|
||||
|
||||
A sphere whose diameter is 3.0 and mass 1.0, is specified as follows:
|
||||
|
||||
1 1 10
|
||||
1
|
||||
0.9 0.9 0.9 0 0 0
|
||||
0 0 0
|
||||
3.0 :pre
|
||||
|
||||
The "pair_style
|
||||
body/rounded/polhedron"_pair_body_rounded_polyhedron.html command can
|
||||
be used with this body style to compute body/body interactions. The
|
||||
"fix wall/body/polyhedron"_fix_wall_body_polygon.html command can be
|
||||
used with this body style to compute the interaction of body particles
|
||||
with a wall.
|
||||
|
||||
:line
|
||||
|
||||
For output purposes via the "compute
|
||||
body/local"_compute_body_local.html and "dump local"_dump.html
|
||||
commands, this body style produces one datum for each of the N
|
||||
sub-particles in a body particle. The datum has 3 values:
|
||||
|
||||
1 = x position of vertex
|
||||
2 = y position of vertex
|
||||
3 = z position of vertex :pre
|
||||
|
||||
These values are the current position of the vertex within the
|
||||
simulation domain, not a displacement from the center-of-mass (COM) of
|
||||
the body particle itself. These values are calculated using the
|
||||
current COM and orientation of the body particle.
|
||||
|
||||
For images created by the "dump image"_dump_image.html command, if the
|
||||
{body} keyword is set, then each body particle is drawn as a polygon
|
||||
consisting of N line segments. Note that the line segments are drawn
|
||||
between the N vertices, which does not correspond exactly to the
|
||||
physical extent of the body (because the "pair_style
|
||||
rounded/polygon"_pair_body_rounded_polygon.html defines finite-size
|
||||
spheres at those point and the line segments between the spheres are
|
||||
tangent to the spheres). The drawn diameter of each line segment is
|
||||
determined by the {bflag1} parameter for the {body} keyword. The
|
||||
{bflag2} argument is ignored.
|
||||
|
||||
:line
|
||||
|
||||
:link(body-Fraige)
|
||||
[(Fraige)] F. Y. Fraige, P. A. Langston, A. J. Matchett, J. Dodds,
|
||||
Particuology, 6, 455 (2008).
|
||||
|
||||
:link(body-Wang)
|
||||
[(Wang)] J. Wang, H. S. Yu, P. A. Langston, F. Y. Fraige, Granular
|
||||
Matter, 13, 1 (2011).
|
|
@ -1,205 +0,0 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Use chunks to calculate system properties :h3
|
||||
|
||||
In LAMMS, "chunks" are collections of atoms, as defined by the
|
||||
"compute chunk/atom"_compute_chunk_atom.html command, which assigns
|
||||
each atom to a chunk ID (or to no chunk at all). The number of chunks
|
||||
and the assignment of chunk IDs to atoms can be static or change over
|
||||
time. Examples of "chunks" are molecules or spatial bins or atoms
|
||||
with similar values (e.g. coordination number or potential energy).
|
||||
|
||||
The per-atom chunk IDs can be used as input to two other kinds of
|
||||
commands, to calculate various properties of a system:
|
||||
|
||||
"fix ave/chunk"_fix_ave_chunk.html
|
||||
any of the "compute */chunk"_compute.html commands :ul
|
||||
|
||||
Here a brief overview for each of the 4 kinds of chunk-related commands
|
||||
is provided. Then some examples are given of how to compute different
|
||||
properties with chunk commands.
|
||||
|
||||
Compute chunk/atom command: :h4
|
||||
|
||||
This compute can assign atoms to chunks of various styles. Only atoms
|
||||
in the specified group and optional specified region are assigned to a
|
||||
chunk. Here are some possible chunk definitions:
|
||||
|
||||
atoms in same molecule | chunk ID = molecule ID |
|
||||
atoms of same atom type | chunk ID = atom type |
|
||||
all atoms with same atom property (charge, radius, etc) | chunk ID = output of compute property/atom |
|
||||
atoms in same cluster | chunk ID = output of "compute cluster/atom"_compute_cluster_atom.html command |
|
||||
atoms in same spatial bin | chunk ID = bin ID |
|
||||
atoms in same rigid body | chunk ID = molecule ID used to define rigid bodies |
|
||||
atoms with similar potential energy | chunk ID = output of "compute pe/atom"_compute_pe_atom.html |
|
||||
atoms with same local defect structure | chunk ID = output of "compute centro/atom"_compute_centro_atom.html or "compute coord/atom"_compute_coord_atom.html command :tb(s=|,c=2)
|
||||
|
||||
Note that chunk IDs are integer values, so for atom properties or
|
||||
computes that produce a floating point value, they will be truncated
|
||||
to an integer. You could also use the compute in a variable that
|
||||
scales the floating point value to spread it across multiple integers.
|
||||
|
||||
Spatial bins can be of various kinds, e.g. 1d bins = slabs, 2d bins =
|
||||
pencils, 3d bins = boxes, spherical bins, cylindrical bins.
|
||||
|
||||
This compute also calculates the number of chunks {Nchunk}, which is
|
||||
used by other commands to tally per-chunk data. {Nchunk} can be a
|
||||
static value or change over time (e.g. the number of clusters). The
|
||||
chunk ID for an individual atom can also be static (e.g. a molecule
|
||||
ID), or dynamic (e.g. what spatial bin an atom is in as it moves).
|
||||
|
||||
Note that this compute allows the per-atom output of other
|
||||
"computes"_compute.html, "fixes"_fix.html, and
|
||||
"variables"_variable.html to be used to define chunk IDs for each
|
||||
atom. This means you can write your own compute or fix to output a
|
||||
per-atom quantity to use as chunk ID. See the "Modify"_Modify.html
|
||||
doc pages for info on how to do this. You can also define a "per-atom
|
||||
variable"_variable.html in the input script that uses a formula to
|
||||
generate a chunk ID for each atom.
|
||||
|
||||
Fix ave/chunk command: :h4
|
||||
|
||||
This fix takes the ID of a "compute
|
||||
chunk/atom"_compute_chunk_atom.html command as input. For each chunk,
|
||||
it then sums one or more specified per-atom values over the atoms in
|
||||
each chunk. The per-atom values can be any atom property, such as
|
||||
velocity, force, charge, potential energy, kinetic energy, stress,
|
||||
etc. Additional keywords are defined for per-chunk properties like
|
||||
density and temperature. More generally any per-atom value generated
|
||||
by other "computes"_compute.html, "fixes"_fix.html, and "per-atom
|
||||
variables"_variable.html, can be summed over atoms in each chunk.
|
||||
|
||||
Similar to other averaging fixes, this fix allows the summed per-chunk
|
||||
values to be time-averaged in various ways, and output to a file. The
|
||||
fix produces a global array as output with one row of values per
|
||||
chunk.
|
||||
|
||||
Compute */chunk commands: :h4
|
||||
|
||||
The following computes operate on chunks of atoms to produce per-chunk
|
||||
values. Any compute whose style name ends in "/chunk" is in this
|
||||
category:
|
||||
|
||||
"compute com/chunk"_compute_com_chunk.html
|
||||
"compute gyration/chunk"_compute_gyration_chunk.html
|
||||
"compute inertia/chunk"_compute_inertia_chunk.html
|
||||
"compute msd/chunk"_compute_msd_chunk.html
|
||||
"compute property/chunk"_compute_property_chunk.html
|
||||
"compute temp/chunk"_compute_temp_chunk.html
|
||||
"compute torque/chunk"_compute_vcm_chunk.html
|
||||
"compute vcm/chunk"_compute_vcm_chunk.html :ul
|
||||
|
||||
They each take the ID of a "compute
|
||||
chunk/atom"_compute_chunk_atom.html command as input. As their names
|
||||
indicate, they calculate the center-of-mass, radius of gyration,
|
||||
moments of inertia, mean-squared displacement, temperature, torque,
|
||||
and velocity of center-of-mass for each chunk of atoms. The "compute
|
||||
property/chunk"_compute_property_chunk.html command can tally the
|
||||
count of atoms in each chunk and extract other per-chunk properties.
|
||||
|
||||
The reason these various calculations are not part of the "fix
|
||||
ave/chunk command"_fix_ave_chunk.html, is that each requires a more
|
||||
complicated operation than simply summing and averaging over per-atom
|
||||
values in each chunk. For example, many of them require calculation
|
||||
of a center of mass, which requires summing mass*position over the
|
||||
atoms and then dividing by summed mass.
|
||||
|
||||
All of these computes produce a global vector or global array as
|
||||
output, wih one or more values per chunk. The output can be used in
|
||||
various ways:
|
||||
|
||||
As input to the "fix ave/time"_fix_ave_time.html command, which can
|
||||
write the values to a file and optionally time average them. :ulb,l
|
||||
|
||||
As input to the "fix ave/histo"_fix_ave_histo.html command to
|
||||
histogram values across chunks. E.g. a histogram of cluster sizes or
|
||||
molecule diffusion rates. :l
|
||||
|
||||
As input to special functions of "equal-style
|
||||
variables"_variable.html, like sum() and max() and ave(). E.g. to
|
||||
find the largest cluster or fastest diffusing molecule or average
|
||||
radius-of-gyration of a set of molecules (chunks). :l,ule
|
||||
|
||||
Other chunk commands: :h4
|
||||
|
||||
"compute chunk/spread/atom"_compute_chunk_spread_atom.html
|
||||
"compute reduce/chunk"_compute_reduce_chunk.html :ul
|
||||
|
||||
The "compute chunk/spread/atom"_compute_chunk_spread_atom.html command
|
||||
spreads per-chunk values to each atom in the chunk, producing per-atom
|
||||
values as its output. This can be useful for outputting per-chunk
|
||||
values to a per-atom "dump file"_dump.html. Or for using an atom's
|
||||
associated chunk value in an "atom-style variable"_variable.html. Or
|
||||
as input to the "fix ave/chunk"_fix_ave_chunk.html command to
|
||||
spatially average per-chunk values calculated by a per-chunk compute.
|
||||
|
||||
The "compute reduce/chunk"_compute_reduce_chunk.html command reduces a
|
||||
peratom value across the atoms in each chunk to produce a value per
|
||||
chunk. When used with the "compute
|
||||
chunk/spread/atom"_compute_chunk_spread_atom.html command it can
|
||||
create peratom values that induce a new set of chunks with a second
|
||||
"compute chunk/atom"_compute_chunk_atom.html command.
|
||||
|
||||
Example calculations with chunks :h4
|
||||
|
||||
Here are examples using chunk commands to calculate various
|
||||
properties:
|
||||
|
||||
(1) Average velocity in each of 1000 2d spatial bins:
|
||||
|
||||
compute cc1 all chunk/atom bin/2d x 0.0 0.1 y lower 0.01 units reduced
|
||||
fix 1 all ave/chunk 100 10 1000 cc1 vx vy file tmp.out :pre
|
||||
|
||||
(2) Temperature in each spatial bin, after subtracting a flow
|
||||
velocity:
|
||||
|
||||
compute cc1 all chunk/atom bin/2d x 0.0 0.1 y lower 0.1 units reduced
|
||||
compute vbias all temp/profile 1 0 0 y 10
|
||||
fix 1 all ave/chunk 100 10 1000 cc1 temp bias vbias file tmp.out :pre
|
||||
|
||||
(3) Center of mass of each molecule:
|
||||
|
||||
compute cc1 all chunk/atom molecule
|
||||
compute myChunk all com/chunk cc1
|
||||
fix 1 all ave/time 100 1 100 c_myChunk\[*\] file tmp.out mode vector :pre
|
||||
|
||||
(4) Total force on each molecule and ave/max across all molecules:
|
||||
|
||||
compute cc1 all chunk/atom molecule
|
||||
fix 1 all ave/chunk 1000 1 1000 cc1 fx fy fz file tmp.out
|
||||
variable xave equal ave(f_1\[2\])
|
||||
variable xmax equal max(f_1\[2\])
|
||||
thermo 1000
|
||||
thermo_style custom step temp v_xave v_xmax :pre
|
||||
|
||||
(5) Histogram of cluster sizes:
|
||||
|
||||
compute cluster all cluster/atom 1.0
|
||||
compute cc1 all chunk/atom c_cluster compress yes
|
||||
compute size all property/chunk cc1 count
|
||||
fix 1 all ave/histo 100 1 100 0 20 20 c_size mode vector ave running beyond ignore file tmp.histo :pre
|
||||
|
||||
(6) An example for using a per-chunk value to apply per-atom forces to
|
||||
compress individual polymer chains (molecules) in a mixture, is
|
||||
explained on the "compute
|
||||
chunk/spread/atom"_compute_chunk_spread_atom.html command doc page.
|
||||
|
||||
(7) An example for using one set of per-chunk values for molecule
|
||||
chunks, to create a 2nd set of micelle-scale chunks (clustered
|
||||
molecules, due to hydrophobicity), is explained on the "compute
|
||||
chunk/reduce"_compute_reduce_chunk.html command doc page.
|
||||
|
||||
(8) An example for using one set of per-chunk values (dipole moment
|
||||
vectors) for molecule chunks, spreading the values to each atom in
|
||||
each chunk, then defining a second set of chunks as spatial bins, and
|
||||
using the "fix ave/chunk"_fix_ave_chunk.html command to calculate an
|
||||
average dipole moment vector for each bin. This example is explained
|
||||
on the "compute chunk/spread/atom"_compute_chunk_spread_atom.html
|
||||
command doc page.
|
|
@ -1,253 +0,0 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Adiabatic core/shell model :h3
|
||||
|
||||
The adiabatic core-shell model by "Mitchell and
|
||||
Fincham"_#MitchellFincham is a simple method for adding polarizability
|
||||
to a system. In order to mimic the electron shell of an ion, a
|
||||
satellite particle is attached to it. This way the ions are split into
|
||||
a core and a shell where the latter is meant to react to the
|
||||
electrostatic environment inducing polarizability. See the "Howto
|
||||
polarizable"_Howto_polarizable.html doc page for a discussion of all
|
||||
the polarizable models available in LAMMPS.
|
||||
|
||||
Technically, shells are attached to the cores by a spring force f =
|
||||
k*r where k is a parameterized spring constant and r is the distance
|
||||
between the core and the shell. The charges of the core and the shell
|
||||
add up to the ion charge, thus q(ion) = q(core) + q(shell). This
|
||||
setup introduces the ion polarizability (alpha) given by
|
||||
alpha = q(shell)^2 / k. In a
|
||||
similar fashion the mass of the ion is distributed on the core and the
|
||||
shell with the core having the larger mass.
|
||||
|
||||
To run this model in LAMMPS, "atom_style"_atom_style.html {full} can
|
||||
be used since atom charge and bonds are needed. Each kind of
|
||||
core/shell pair requires two atom types and a bond type. The core and
|
||||
shell of a core/shell pair should be bonded to each other with a
|
||||
harmonic bond that provides the spring force. For example, a data file
|
||||
for NaCl, as found in examples/coreshell, has this format:
|
||||
|
||||
432 atoms # core and shell atoms
|
||||
216 bonds # number of core/shell springs :pre
|
||||
|
||||
4 atom types # 2 cores and 2 shells for Na and Cl
|
||||
2 bond types :pre
|
||||
|
||||
0.0 24.09597 xlo xhi
|
||||
0.0 24.09597 ylo yhi
|
||||
0.0 24.09597 zlo zhi :pre
|
||||
|
||||
Masses # core/shell mass ratio = 0.1 :pre
|
||||
|
||||
1 20.690784 # Na core
|
||||
2 31.90500 # Cl core
|
||||
3 2.298976 # Na shell
|
||||
4 3.54500 # Cl shell :pre
|
||||
|
||||
Atoms :pre
|
||||
|
||||
1 1 2 1.5005 0.00000000 0.00000000 0.00000000 # core of core/shell pair 1
|
||||
2 1 4 -2.5005 0.00000000 0.00000000 0.00000000 # shell of core/shell pair 1
|
||||
3 2 1 1.5056 4.01599500 4.01599500 4.01599500 # core of core/shell pair 2
|
||||
4 2 3 -0.5056 4.01599500 4.01599500 4.01599500 # shell of core/shell pair 2
|
||||
(...) :pre
|
||||
|
||||
Bonds # Bond topology for spring forces :pre
|
||||
|
||||
1 2 1 2 # spring for core/shell pair 1
|
||||
2 2 3 4 # spring for core/shell pair 2
|
||||
(...) :pre
|
||||
|
||||
Non-Coulombic (e.g. Lennard-Jones) pairwise interactions are only
|
||||
defined between the shells. Coulombic interactions are defined
|
||||
between all cores and shells. If desired, additional bonds can be
|
||||
specified between cores.
|
||||
|
||||
The "special_bonds"_special_bonds.html command should be used to
|
||||
turn-off the Coulombic interaction within core/shell pairs, since that
|
||||
interaction is set by the bond spring. This is done using the
|
||||
"special_bonds"_special_bonds.html command with a 1-2 weight = 0.0,
|
||||
which is the default value. It needs to be considered whether one has
|
||||
to adjust the "special_bonds"_special_bonds.html weighting according
|
||||
to the molecular topology since the interactions of the shells are
|
||||
bypassed over an extra bond.
|
||||
|
||||
Note that this core/shell implementation does not require all ions to
|
||||
be polarized. One can mix core/shell pairs and ions without a
|
||||
satellite particle if desired.
|
||||
|
||||
Since the core/shell model permits distances of r = 0.0 between the
|
||||
core and shell, a pair style with a "cs" suffix needs to be used to
|
||||
implement a valid long-range Coulombic correction. Several such pair
|
||||
styles are provided in the CORESHELL package. See "this doc
|
||||
page"_pair_cs.html for details. All of the core/shell enabled pair
|
||||
styles require the use of a long-range Coulombic solver, as specified
|
||||
by the "kspace_style"_kspace_style.html command. Either the PPPM or
|
||||
Ewald solvers can be used.
|
||||
|
||||
For the NaCL example problem, these pair style and bond style settings
|
||||
are used:
|
||||
|
||||
pair_style born/coul/long/cs 20.0 20.0
|
||||
pair_coeff * * 0.0 1.000 0.00 0.00 0.00
|
||||
pair_coeff 3 3 487.0 0.23768 0.00 1.05 0.50 #Na-Na
|
||||
pair_coeff 3 4 145134.0 0.23768 0.00 6.99 8.70 #Na-Cl
|
||||
pair_coeff 4 4 405774.0 0.23768 0.00 72.40 145.40 #Cl-Cl :pre
|
||||
|
||||
bond_style harmonic
|
||||
bond_coeff 1 63.014 0.0
|
||||
bond_coeff 2 25.724 0.0 :pre
|
||||
|
||||
When running dynamics with the adiabatic core/shell model, the
|
||||
following issues should be considered. The relative motion of
|
||||
the core and shell particles corresponds to the polarization,
|
||||
hereby an instantaneous relaxation of the shells is approximated
|
||||
and a fast core/shell spring frequency ensures a nearly constant
|
||||
internal kinetic energy during the simulation.
|
||||
Thermostats can alter this polarization behavior, by scaling the
|
||||
internal kinetic energy, meaning the shell will not react freely to
|
||||
its electrostatic environment.
|
||||
Therefore it is typically desirable to decouple the relative motion of
|
||||
the core/shell pair, which is an imaginary degree of freedom, from the
|
||||
real physical system. To do that, the "compute
|
||||
temp/cs"_compute_temp_cs.html command can be used, in conjunction with
|
||||
any of the thermostat fixes, such as "fix nvt"_fix_nh.html or "fix
|
||||
langevin"_fix_langevin.html. This compute uses the center-of-mass velocity
|
||||
of the core/shell pairs to calculate a temperature, and insures that
|
||||
velocity is what is rescaled for thermostatting purposes. This
|
||||
compute also works for a system with both core/shell pairs and
|
||||
non-polarized ions (ions without an attached satellite particle). The
|
||||
"compute temp/cs"_compute_temp_cs.html command requires input of two
|
||||
groups, one for the core atoms, another for the shell atoms.
|
||||
Non-polarized ions which might also be included in the treated system
|
||||
should not be included into either of these groups, they are taken
|
||||
into account by the {group-ID} (2nd argument) of the compute. The
|
||||
groups can be defined using the "group {type}"_group.html command.
|
||||
Note that to perform thermostatting using this definition of
|
||||
temperature, the "fix modify temp"_fix_modify.html command should be
|
||||
used to assign the compute to the thermostat fix. Likewise the
|
||||
"thermo_modify temp"_thermo_modify.html command can be used to make
|
||||
this temperature be output for the overall system.
|
||||
|
||||
For the NaCl example, this can be done as follows:
|
||||
|
||||
group cores type 1 2
|
||||
group shells type 3 4
|
||||
compute CSequ all temp/cs cores shells
|
||||
fix thermoberendsen all temp/berendsen 1427 1427 0.4 # thermostat for the true physical system
|
||||
fix thermostatequ all nve # integrator as needed for the berendsen thermostat
|
||||
fix_modify thermoberendsen temp CSequ
|
||||
thermo_modify temp CSequ # output of center-of-mass derived temperature :pre
|
||||
|
||||
The pressure for the core/shell system is computed via the regular
|
||||
LAMMPS convention by "treating the cores and shells as individual
|
||||
particles"_#MitchellFincham2. For the thermo output of the pressure
|
||||
as well as for the application of a barostat, it is necessary to
|
||||
use an additional "pressure"_compute_pressure.html compute based on
|
||||
the default "temperature"_compute_temp.html and specifying it as a
|
||||
second argument in "fix modify"_fix_modify.html and
|
||||
"thermo_modify"_thermo_modify.html resulting in:
|
||||
|
||||
(...)
|
||||
compute CSequ all temp/cs cores shells
|
||||
compute thermo_press_lmp all pressure thermo_temp # pressure for individual particles
|
||||
thermo_modify temp CSequ press thermo_press_lmp # modify thermo to regular pressure
|
||||
fix press_bar all npt temp 300 300 0.04 iso 0 0 0.4
|
||||
fix_modify press_bar temp CSequ press thermo_press_lmp # pressure modification for correct kinetic scalar :pre
|
||||
|
||||
If "compute temp/cs"_compute_temp_cs.html is used, the decoupled
|
||||
relative motion of the core and the shell should in theory be
|
||||
stable. However numerical fluctuation can introduce a small
|
||||
momentum to the system, which is noticeable over long trajectories.
|
||||
Therefore it is recommendable to use the "fix
|
||||
momentum"_fix_momentum.html command in combination with "compute
|
||||
temp/cs"_compute_temp_cs.html when equilibrating the system to
|
||||
prevent any drift.
|
||||
|
||||
When initializing the velocities of a system with core/shell pairs, it
|
||||
is also desirable to not introduce energy into the relative motion of
|
||||
the core/shell particles, but only assign a center-of-mass velocity to
|
||||
the pairs. This can be done by using the {bias} keyword of the
|
||||
"velocity create"_velocity.html command and assigning the "compute
|
||||
temp/cs"_compute_temp_cs.html command to the {temp} keyword of the
|
||||
"velocity"_velocity.html command, e.g.
|
||||
|
||||
velocity all create 1427 134 bias yes temp CSequ
|
||||
velocity all scale 1427 temp CSequ :pre
|
||||
|
||||
To maintain the correct polarizability of the core/shell pairs, the
|
||||
kinetic energy of the internal motion shall remain nearly constant.
|
||||
Therefore the choice of spring force and mass ratio need to ensure
|
||||
much faster relative motion of the 2 atoms within the core/shell pair
|
||||
than their center-of-mass velocity. This allows the shells to
|
||||
effectively react instantaneously to the electrostatic environment and
|
||||
limits energy transfer to or from the core/shell oscillators.
|
||||
This fast movement also dictates the timestep that can be used.
|
||||
|
||||
The primary literature of the adiabatic core/shell model suggests that
|
||||
the fast relative motion of the core/shell pairs only allows negligible
|
||||
energy transfer to the environment.
|
||||
The mentioned energy transfer will typically lead to a small drift
|
||||
in total energy over time. This internal energy can be monitored
|
||||
using the "compute chunk/atom"_compute_chunk_atom.html and "compute
|
||||
temp/chunk"_compute_temp_chunk.html commands. The internal kinetic
|
||||
energies of each core/shell pair can then be summed using the sum()
|
||||
special function of the "variable"_variable.html command. Or they can
|
||||
be time/averaged and output using the "fix ave/time"_fix_ave_time.html
|
||||
command. To use these commands, each core/shell pair must be defined
|
||||
as a "chunk". If each core/shell pair is defined as its own molecule,
|
||||
the molecule ID can be used to define the chunks. If cores are bonded
|
||||
to each other to form larger molecules, the chunks can be identified
|
||||
by the "fix property/atom"_fix_property_atom.html via assigning a
|
||||
core/shell ID to each atom using a special field in the data file read
|
||||
by the "read_data"_read_data.html command. This field can then be
|
||||
accessed by the "compute property/atom"_compute_property_atom.html
|
||||
command, to use as input to the "compute
|
||||
chunk/atom"_compute_chunk_atom.html command to define the core/shell
|
||||
pairs as chunks.
|
||||
|
||||
For example if core/shell pairs are the only molecules:
|
||||
|
||||
read_data NaCl_CS_x0.1_prop.data
|
||||
compute prop all property/atom molecule
|
||||
compute cs_chunk all chunk/atom c_prop
|
||||
compute cstherm all temp/chunk cs_chunk temp internal com yes cdof 3.0 # note the chosen degrees of freedom for the core/shell pairs
|
||||
fix ave_chunk all ave/time 10 1 10 c_cstherm file chunk.dump mode vector :pre
|
||||
|
||||
For example if core/shell pairs and other molecules are present:
|
||||
|
||||
fix csinfo all property/atom i_CSID # property/atom command
|
||||
read_data NaCl_CS_x0.1_prop.data fix csinfo NULL CS-Info # atom property added in the data-file
|
||||
compute prop all property/atom i_CSID
|
||||
(...) :pre
|
||||
|
||||
The additional section in the date file would be formatted like this:
|
||||
|
||||
CS-Info # header of additional section :pre
|
||||
|
||||
1 1 # column 1 = atom ID, column 2 = core/shell ID
|
||||
2 1
|
||||
3 2
|
||||
4 2
|
||||
5 3
|
||||
6 3
|
||||
7 4
|
||||
8 4
|
||||
(...) :pre
|
||||
|
||||
:line
|
||||
|
||||
:link(MitchellFincham)
|
||||
[(Mitchell and Fincham)] Mitchell, Fincham, J Phys Condensed Matter,
|
||||
5, 1031-1038 (1993).
|
||||
|
||||
:link(MitchellFincham2)
|
||||
[(Fincham)] Fincham, Mackrodt and Mitchell, J Phys Condensed Matter,
|
||||
6, 393-404 (1994).
|
|
@ -1,116 +0,0 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Coupling LAMMPS to other codes :h3
|
||||
|
||||
LAMMPS is designed to allow it to be coupled to other codes. For
|
||||
example, a quantum mechanics code might compute forces on a subset of
|
||||
atoms and pass those forces to LAMMPS. Or a continuum finite element
|
||||
(FE) simulation might use atom positions as boundary conditions on FE
|
||||
nodal points, compute a FE solution, and return interpolated forces on
|
||||
MD atoms.
|
||||
|
||||
LAMMPS can be coupled to other codes in at least 4 ways. Each has
|
||||
advantages and disadvantages, which you'll have to think about in the
|
||||
context of your application.
|
||||
|
||||
:line
|
||||
|
||||
(1) Define a new "fix"_fix.html command that calls the other code. In
|
||||
this scenario, LAMMPS is the driver code. During its timestepping,
|
||||
the fix is invoked, and can make library calls to the other code,
|
||||
which has been linked to LAMMPS as a library. This is the way the
|
||||
"POEMS"_poems package that performs constrained rigid-body motion on
|
||||
groups of atoms is hooked to LAMMPS. See the "fix
|
||||
poems"_fix_poems.html command for more details. See the
|
||||
"Modify"_Modify.html doc pages for info on how to add a new fix to
|
||||
LAMMPS.
|
||||
|
||||
:link(poems,http://www.rpi.edu/~anderk5/lab)
|
||||
|
||||
:line
|
||||
|
||||
(2) Define a new LAMMPS command that calls the other code. This is
|
||||
conceptually similar to method (1), but in this case LAMMPS and the
|
||||
other code are on a more equal footing. Note that now the other code
|
||||
is not called during the timestepping of a LAMMPS run, but between
|
||||
runs. The LAMMPS input script can be used to alternate LAMMPS runs
|
||||
with calls to the other code, invoked via the new command. The
|
||||
"run"_run.html command facilitates this with its {every} option, which
|
||||
makes it easy to run a few steps, invoke the command, run a few steps,
|
||||
invoke the command, etc.
|
||||
|
||||
In this scenario, the other code can be called as a library, as in
|
||||
(1), or it could be a stand-alone code, invoked by a system() call
|
||||
made by the command (assuming your parallel machine allows one or more
|
||||
processors to start up another program). In the latter case the
|
||||
stand-alone code could communicate with LAMMPS through files that the
|
||||
command writes and reads.
|
||||
|
||||
See the "Modify command"_Modify_command.html doc page for info on how
|
||||
to add a new command to LAMMPS.
|
||||
|
||||
:line
|
||||
|
||||
(3) Use LAMMPS as a library called by another code. In this case the
|
||||
other code is the driver and calls LAMMPS as needed. Or a wrapper
|
||||
code could link and call both LAMMPS and another code as libraries.
|
||||
Again, the "run"_run.html command has options that allow it to be
|
||||
invoked with minimal overhead (no setup or clean-up) if you wish to do
|
||||
multiple short runs, driven by another program.
|
||||
|
||||
Examples of driver codes that call LAMMPS as a library are included in
|
||||
the examples/COUPLE directory of the LAMMPS distribution; see
|
||||
examples/COUPLE/README for more details:
|
||||
|
||||
simple: simple driver programs in C++ and C which invoke LAMMPS as a
|
||||
library :ulb,l
|
||||
|
||||
lammps_quest: coupling of LAMMPS and "Quest"_quest, to run classical
|
||||
MD with quantum forces calculated by a density functional code :l
|
||||
|
||||
lammps_spparks: coupling of LAMMPS and "SPPARKS"_spparks, to couple
|
||||
a kinetic Monte Carlo model for grain growth using MD to calculate
|
||||
strain induced across grain boundaries :l
|
||||
:ule
|
||||
|
||||
:link(quest,http://dft.sandia.gov/Quest)
|
||||
:link(spparks,http://www.sandia.gov/~sjplimp/spparks.html)
|
||||
|
||||
The "Build basics"_Build_basics.html doc page describes how to build
|
||||
LAMMPS as a library. Once this is done, you can interface with LAMMPS
|
||||
either via C++, C, Fortran, or Python (or any other language that
|
||||
supports a vanilla C-like interface). For example, from C++ you could
|
||||
create one (or more) "instances" of LAMMPS, pass it an input script to
|
||||
process, or execute individual commands, all by invoking the correct
|
||||
class methods in LAMMPS. From C or Fortran you can make function
|
||||
calls to do the same things. See the "Python"_Python_head.html doc
|
||||
pages for a description of the Python wrapper provided with LAMMPS
|
||||
that operates through the LAMMPS library interface.
|
||||
|
||||
The files src/library.cpp and library.h contain the C-style interface
|
||||
to LAMMPS. See the "Howto library"_Howto_library.html doc page for a
|
||||
description of the interface and how to extend it for your needs.
|
||||
|
||||
Note that the lammps_open() function that creates an instance of
|
||||
LAMMPS takes an MPI communicator as an argument. This means that
|
||||
instance of LAMMPS will run on the set of processors in the
|
||||
communicator. Thus the calling code can run LAMMPS on all or a subset
|
||||
of processors. For example, a wrapper script might decide to
|
||||
alternate between LAMMPS and another code, allowing them both to run
|
||||
on all the processors. Or it might allocate half the processors to
|
||||
LAMMPS and half to the other code and run both codes simultaneously
|
||||
before syncing them up periodically. Or it might instantiate multiple
|
||||
instances of LAMMPS to perform different calculations.
|
||||
|
||||
:line
|
||||
|
||||
(4) Couple LAMMPS with another code in a client/server mode. This is
|
||||
described on the "Howto client/server"_Howto_client_server.html doc
|
||||
page.
|
|
@ -1,33 +0,0 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Calculate diffusion coefficients :h3
|
||||
|
||||
The diffusion coefficient D of a material can be measured in at least
|
||||
2 ways using various options in LAMMPS. See the examples/DIFFUSE
|
||||
directory for scripts that implement the 2 methods discussed here for
|
||||
a simple Lennard-Jones fluid model.
|
||||
|
||||
The first method is to measure the mean-squared displacement (MSD) of
|
||||
the system, via the "compute msd"_compute_msd.html command. The slope
|
||||
of the MSD versus time is proportional to the diffusion coefficient.
|
||||
The instantaneous MSD values can be accumulated in a vector via the
|
||||
"fix vector"_fix_vector.html command, and a line fit to the vector to
|
||||
compute its slope via the "variable slope"_variable.html function, and
|
||||
thus extract D.
|
||||
|
||||
The second method is to measure the velocity auto-correlation function
|
||||
(VACF) of the system, via the "compute vacf"_compute_vacf.html
|
||||
command. The time-integral of the VACF is proportional to the
|
||||
diffusion coefficient. The instantaneous VACF values can be
|
||||
accumulated in a vector via the "fix vector"_fix_vector.html command,
|
||||
and time integrated via the "variable trap"_variable.html function,
|
||||
and thus extract D.
|
||||
|
||||
:line
|
|
@ -1,108 +0,0 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Long-range dispersion settings :h3
|
||||
|
||||
The PPPM method computes interactions by splitting the pair potential
|
||||
into two parts, one of which is computed in a normal pairwise fashion,
|
||||
the so-called real-space part, and one of which is computed using the
|
||||
Fourier transform, the so called reciprocal-space or kspace part. For
|
||||
both parts, the potential is not computed exactly but is approximated.
|
||||
Thus, there is an error in both parts of the computation, the
|
||||
real-space and the kspace error. The just mentioned facts are true
|
||||
both for the PPPM for Coulomb as well as dispersion interactions. The
|
||||
deciding difference - and also the reason why the parameters for
|
||||
pppm/disp have to be selected with more care - is the impact of the
|
||||
errors on the results: The kspace error of the PPPM for Coulomb and
|
||||
dispersion interaction and the real-space error of the PPPM for
|
||||
Coulomb interaction have the character of noise. In contrast, the
|
||||
real-space error of the PPPM for dispersion has a clear physical
|
||||
interpretation: the underprediction of cohesion. As a consequence, the
|
||||
real-space error has a much stronger effect than the kspace error on
|
||||
simulation results for pppm/disp. Parameters must thus be chosen in a
|
||||
way that this error is much smaller than the kspace error.
|
||||
|
||||
When using pppm/disp and not making any specifications on the PPPM
|
||||
parameters via the kspace modify command, parameters will be tuned
|
||||
such that the real-space error and the kspace error are equal. This
|
||||
will result in simulations that are either inaccurate or slow, both of
|
||||
which is not desirable. For selecting parameters for the pppm/disp
|
||||
that provide fast and accurate simulations, there are two approaches,
|
||||
which both have their up- and downsides.
|
||||
|
||||
The first approach is to set desired real-space an kspace accuracies
|
||||
via the {kspace_modify force/disp/real} and {kspace_modify
|
||||
force/disp/kspace} commands. Note that the accuracies have to be
|
||||
specified in force units and are thus dependent on the chosen unit
|
||||
settings. For real units, 0.0001 and 0.002 seem to provide reasonable
|
||||
accurate and efficient computations for the real-space and kspace
|
||||
accuracies. 0.002 and 0.05 work well for most systems using lj
|
||||
units. PPPM parameters will be generated based on the desired
|
||||
accuracies. The upside of this approach is that it usually provides a
|
||||
good set of parameters and will work for both the {kspace_modify diff
|
||||
ad} and {kspace_modify diff ik} options. The downside of the method
|
||||
is that setting the PPPM parameters will take some time during the
|
||||
initialization of the simulation.
|
||||
|
||||
The second approach is to set the parameters for the pppm/disp
|
||||
explicitly using the {kspace_modify mesh/disp}, {kspace_modify
|
||||
order/disp}, and {kspace_modify gewald/disp} commands. This approach
|
||||
requires a more experienced user who understands well the impact of
|
||||
the choice of parameters on the simulation accuracy and
|
||||
performance. This approach provides a fast initialization of the
|
||||
simulation. However, it is sensitive to errors: A combination of
|
||||
parameters that will perform well for one system might result in
|
||||
far-from-optimal conditions for other simulations. For example,
|
||||
parameters that provide accurate and fast computations for
|
||||
all-atomistic force fields can provide insufficient accuracy or
|
||||
united-atomistic force fields (which is related to that the latter
|
||||
typically have larger dispersion coefficients).
|
||||
|
||||
To avoid inaccurate or inefficient simulations, the pppm/disp stops
|
||||
simulations with an error message if no action is taken to control the
|
||||
PPPM parameters. If the automatic parameter generation is desired and
|
||||
real-space and kspace accuracies are desired to be equal, this error
|
||||
message can be suppressed using the {kspace_modify disp/auto yes}
|
||||
command.
|
||||
|
||||
A reasonable approach that combines the upsides of both methods is to
|
||||
make the first run using the {kspace_modify force/disp/real} and
|
||||
{kspace_modify force/disp/kspace} commands, write down the PPPM
|
||||
parameters from the output, and specify these parameters using the
|
||||
second approach in subsequent runs (which have the same composition,
|
||||
force field, and approximately the same volume).
|
||||
|
||||
Concerning the performance of the pppm/disp there are two more things
|
||||
to consider. The first is that when using the pppm/disp, the cutoff
|
||||
parameter does no longer affect the accuracy of the simulation
|
||||
(subject to that gewald/disp is adjusted when changing the cutoff).
|
||||
The performance can thus be increased by examining different values
|
||||
for the cutoff parameter. A lower bound for the cutoff is only set by
|
||||
the truncation error of the repulsive term of pair potentials.
|
||||
|
||||
The second is that the mixing rule of the pair style has an impact on
|
||||
the computation time when using the pppm/disp. Fastest computations
|
||||
are achieved when using the geometric mixing rule. Using the
|
||||
arithmetic mixing rule substantially increases the computational cost.
|
||||
The computational overhead can be reduced using the {kspace_modify
|
||||
mix/disp geom} and {kspace_modify splittol} commands. The first
|
||||
command simply enforces geometric mixing of the dispersion
|
||||
coefficients in kspace computations. This introduces some error in
|
||||
the computations but will also significantly speed-up the
|
||||
simulations. The second keyword sets the accuracy with which the
|
||||
dispersion coefficients are approximated using a matrix factorization
|
||||
approach. This may result in better accuracy then using the first
|
||||
command, but will usually also not provide an equally good increase of
|
||||
efficiency.
|
||||
|
||||
Finally, pppm/disp can also be used when no mixing rules apply.
|
||||
This can be achieved using the {kspace_modify mix/disp none} command.
|
||||
Note that the code does not check automatically whether any mixing
|
||||
rule is fulfilled. If mixing rules do not apply, the user will have
|
||||
to specify this command explicitly.
|
|
@ -1,77 +0,0 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Drude induced dipoles :h3
|
||||
|
||||
The thermalized Drude model represents induced dipoles by a pair of
|
||||
charges (the core atom and the Drude particle) connected by a harmonic
|
||||
spring. See the "Howto polarizable"_Howto_polarizable.html doc page
|
||||
for a discussion of all the polarizable models available in LAMMPS.
|
||||
|
||||
The Drude model has a number of features aimed at its use in
|
||||
molecular systems ("Lamoureux and Roux"_#howto-Lamoureux):
|
||||
|
||||
Thermostatting of the additional degrees of freedom associated with the
|
||||
induced dipoles at very low temperature, in terms of the reduced
|
||||
coordinates of the Drude particles with respect to their cores. This
|
||||
makes the trajectory close to that of relaxed induced dipoles. :ulb,l
|
||||
|
||||
Consistent definition of 1-2 to 1-4 neighbors. A core-Drude particle
|
||||
pair represents a single (polarizable) atom, so the special screening
|
||||
factors in a covalent structure should be the same for the core and
|
||||
the Drude particle. Drude particles have to inherit the 1-2, 1-3, 1-4
|
||||
special neighbor relations from their respective cores. :l
|
||||
|
||||
Stabilization of the interactions between induced dipoles. Drude
|
||||
dipoles on covalently bonded atoms interact too strongly due to the
|
||||
short distances, so an atom may capture the Drude particle of a
|
||||
neighbor, or the induced dipoles within the same molecule may align
|
||||
too much. To avoid this, damping at short range can be done by Thole
|
||||
functions (for which there are physical grounds). This Thole damping
|
||||
is applied to the point charges composing the induced dipole (the
|
||||
charge of the Drude particle and the opposite charge on the core, not
|
||||
to the total charge of the core atom). :l,ule
|
||||
|
||||
A detailed tutorial covering the usage of Drude induced dipoles in
|
||||
LAMMPS is on the "Howto drude2e"_Howto_drude2.html doc page.
|
||||
|
||||
As with the core-shell model, the cores and Drude particles should
|
||||
appear in the data file as standard atoms. The same holds for the
|
||||
springs between them, which are described by standard harmonic bonds.
|
||||
The nature of the atoms (core, Drude particle or non-polarizable) is
|
||||
specified via the "fix drude"_fix_drude.html command. The special
|
||||
list of neighbors is automatically refactored to account for the
|
||||
equivalence of core and Drude particles as regards special 1-2 to 1-4
|
||||
screening. It may be necessary to use the {extra/special/per/atom}
|
||||
keyword of the "read_data"_read_data.html command. If using "fix
|
||||
shake"_fix_shake.html, make sure no Drude particle is in this fix
|
||||
group.
|
||||
|
||||
There are two ways to thermostat the Drude particles at a low
|
||||
temperature: use either "fix langevin/drude"_fix_langevin_drude.html
|
||||
for a Langevin thermostat, or "fix
|
||||
drude/transform/*"_fix_drude_transform.html for a Nose-Hoover
|
||||
thermostat. The former requires use of the command "comm_modify vel
|
||||
yes"_comm_modify.html. The latter requires two separate integration
|
||||
fixes like {nvt} or {npt}. The correct temperatures of the reduced
|
||||
degrees of freedom can be calculated using the "compute
|
||||
temp/drude"_compute_temp_drude.html. This requires also to use the
|
||||
command {comm_modify vel yes}.
|
||||
|
||||
Short-range damping of the induced dipole interactions can be achieved
|
||||
using Thole functions through the "pair style
|
||||
thole"_pair_thole.html in "pair_style hybrid/overlay"_pair_hybrid.html
|
||||
with a Coulomb pair style. It may be useful to use {coul/long/cs} or
|
||||
similar from the CORESHELL package if the core and Drude particle come
|
||||
too close, which can cause numerical issues.
|
||||
|
||||
:line
|
||||
|
||||
:link(howto-Lamoureux)
|
||||
[(Lamoureux and Roux)] G. Lamoureux, B. Roux, J. Chem. Phys 119, 3025 (2003)
|
|
@ -1,472 +0,0 @@
|
|||
<script type="text/javascript"
|
||||
src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML">
|
||||
</script>
|
||||
<script type="text/x-mathjax-config">
|
||||
MathJax.Hub.Config({ TeX: { equationNumbers: {autoNumber: "AMS"} } });
|
||||
</script>
|
||||
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Tutorial for Thermalized Drude oscillators in LAMMPS :h3
|
||||
|
||||
This tutorial explains how to use Drude oscillators in LAMMPS to
|
||||
simulate polarizable systems using the USER-DRUDE package. As an
|
||||
illustration, the input files for a simulation of 250 phenol molecules
|
||||
are documented. First of all, LAMMPS has to be compiled with the
|
||||
USER-DRUDE package activated. Then, the data file and input scripts
|
||||
have to be modified to include the Drude dipoles and how to handle
|
||||
them.
|
||||
|
||||
:line
|
||||
|
||||
[Overview of Drude induced dipoles]
|
||||
|
||||
Polarizable atoms acquire an induced electric dipole moment under the
|
||||
action of an external electric field, for example the electric field
|
||||
created by the surrounding particles. Drude oscillators represent
|
||||
these dipoles by two fixed charges: the core (DC) and the Drude
|
||||
particle (DP) bound by a harmonic potential. The Drude particle can be
|
||||
thought of as the electron cloud whose center can be displaced from
|
||||
the position of the corresponding nucleus.
|
||||
|
||||
The sum of the masses of a core-Drude pair should be the mass of the
|
||||
initial (unsplit) atom, \(m_C + m_D = m\). The sum of their charges
|
||||
should be the charge of the initial (unsplit) atom, \(q_C + q_D = q\).
|
||||
A harmonic potential between the core and Drude partners should be
|
||||
present, with force constant \(k_D\) and an equilibrium distance of
|
||||
zero. The (half-)stiffness of the "harmonic bond"_bond_harmonic.html
|
||||
\(K_D = k_D/2\) and the Drude charge \(q_D\) are related to the atom
|
||||
polarizability \(\alpha\) by
|
||||
|
||||
\begin\{equation\} K_D = \frac 1 2\, \frac \{q_D^2\} \alpha
|
||||
\end\{equation\}
|
||||
|
||||
Ideally, the mass of the Drude particle should be small, and the
|
||||
stiffness of the harmonic bond should be large, so that the Drude
|
||||
particle remains close ot the core. The values of Drude mass, Drude
|
||||
charge, and force constant can be chosen following different
|
||||
strategies, as in the following examples of polarizable force
|
||||
fields:
|
||||
|
||||
"Lamoureux and Roux"_#Lamoureux2 suggest adopting a global half-stiffness, \
|
||||
\(K_D\) = 500 kcal/(mol Ang \(\{\}^2\)) - which corresponds to a force \
|
||||
constant \(k_D\) = 4184 kJ/(mol Ang \(\{\}^2\)) - for all types of \
|
||||
core-Drude bond, a global mass \(m_D\) = 0.4 g/mol (or u) for all types \
|
||||
of Drude particles, and to calculate the Drude charges for individual \
|
||||
atom types from the atom polarizabilities using equation (1). This \
|
||||
choice is followed in the polarizable CHARMM force field. :ulb,l
|
||||
Alternately "Schroeder and Steinhauser"_#Schroeder suggest adopting a global \
|
||||
charge \(q_D\) = -1.0e and a global mass \(m_D\) = 0.1 g/mol (or u) \
|
||||
for all Drude particles, and to calculate the force constant for each \
|
||||
type of core-Drude bond from equation (1). The timesteps used by these \
|
||||
authors are between 0.5 and 2 fs, with the degrees of freedom of the \
|
||||
Drude oscillators kept cold at 1 K. :l
|
||||
In both these force fields hydrogen atoms are treated as non-polarizable. :l
|
||||
:ule
|
||||
|
||||
|
||||
The motion of of the Drude particles can be calculated by minimizing
|
||||
the energy of the induced dipoles at each timestep, by an iterative,
|
||||
self-consistent procedure. The Drude particles can be massless and
|
||||
therefore do not contribute to the kinetic energy. However, the
|
||||
relaxed method is computational slow. An extended-lagrangian method
|
||||
can be used to calculate the positions of the Drude particles, but
|
||||
this requires them to have mass. It is important in this case to
|
||||
decouple the degrees of freedom associated with the Drude oscillators
|
||||
from those of the normal atoms. Thermalizing the Drude dipoles at
|
||||
temperatures comparable to the rest of the simulation leads to several
|
||||
problems (kinetic energy transfer, very short timestep, etc.), which
|
||||
can be remedied by the "cold Drude" technique ("Lamoureux and
|
||||
Roux"_#Lamoureux2).
|
||||
|
||||
Two closely related models are used to represent polarization through
|
||||
"charges on a spring": the core-shell model and the Drude
|
||||
model. Although the basic idea is the same, the core-shell model is
|
||||
normally used for ionic/crystalline materials, whereas the Drude model
|
||||
is normally used for molecular systems and fluid states. In ionic
|
||||
crystals the symmetry around each ion and the distance between them
|
||||
are such that the core-shell model is sufficiently stable. But to be
|
||||
applicable to molecular/covalent systems the Drude model includes two
|
||||
important features:
|
||||
|
||||
The possibility to thermostat the additional degrees of freedom \
|
||||
associated with the induced dipoles at very low temperature, in terms \
|
||||
of the reduced coordinates of the Drude particles with respect to \
|
||||
their cores. This makes the trajectory close to that of relaxed \
|
||||
induced dipoles. :olb,l
|
||||
The Drude dipoles on covalently bonded atoms interact too strongly \
|
||||
due to the short distances, so an atom may capture the Drude particle \
|
||||
(shell) of a neighbor, or the induced dipoles within the same molecule \
|
||||
may align too much. To avoid this, damping at short of the \
|
||||
interactions between the point charges composing the induced dipole \
|
||||
can be done by "Thole"_#Thole2 functions. :l
|
||||
:ole
|
||||
|
||||
|
||||
:line
|
||||
|
||||
[Preparation of the data file]
|
||||
|
||||
The data file is similar to a standard LAMMPS data file for
|
||||
{atom_style full}. The DPs and the {harmonic bonds} connecting them
|
||||
to their DC should appear in the data file as normal atoms and bonds.
|
||||
|
||||
You can use the {polarizer} tool (Python script distributed with the
|
||||
USER-DRUDE package) to convert a non-polarizable data file (here
|
||||
{data.102494.lmp}) to a polarizable data file ({data-p.lmp})
|
||||
|
||||
polarizer -q -f phenol.dff data.102494.lmp data-p.lmp :pre
|
||||
|
||||
This will automatically insert the new atoms and bonds.
|
||||
The masses and charges of DCs and DPs are computed
|
||||
from {phenol.dff}, as well as the DC-DP bond constants. The file
|
||||
{phenol.dff} contains the polarizabilities of the atom types
|
||||
and the mass of the Drude particles, for instance:
|
||||
|
||||
# units: kJ/mol, A, deg
|
||||
# kforce is in the form k/2 r_D^2
|
||||
# type m_D/u q_D/e k_D alpha/A3 thole
|
||||
OH 0.4 -1.0 4184.0 0.63 0.67
|
||||
CA 0.4 -1.0 4184.0 1.36 2.51
|
||||
CAI 0.4 -1.0 4184.0 1.09 2.51 :pre
|
||||
|
||||
The hydrogen atoms are absent from this file, so they will be treated
|
||||
as non-polarizable atoms. In the non-polarizable data file
|
||||
{data.102494.lmp}, atom names corresponding to the atom type numbers
|
||||
have to be specified as comments at the end of lines of the {Masses}
|
||||
section. You probably need to edit it to add these names. It should
|
||||
look like
|
||||
|
||||
Masses :pre
|
||||
|
||||
1 12.011 # CAI
|
||||
2 12.011 # CA
|
||||
3 15.999 # OH
|
||||
4 1.008 # HA
|
||||
5 1.008 # HO :pre
|
||||
|
||||
|
||||
:line
|
||||
|
||||
[Basic input file]
|
||||
|
||||
The atom style should be set to (or derive from) {full}, so that you
|
||||
can define atomic charges and molecular bonds, angles, dihedrals...
|
||||
|
||||
The {polarizer} tool also outputs certain lines related to the input
|
||||
script (the use of these lines will be explained below). In order for
|
||||
LAMMPS to recognize that you are using Drude oscillators, you should
|
||||
use the fix {drude}. The command is
|
||||
|
||||
fix DRUDE all drude C C C N N D D D :pre
|
||||
|
||||
The N, C, D following the {drude} keyword have the following meaning:
|
||||
There is one tag for each atom type. This tag is C for DCs, D for DPs
|
||||
and N for non-polarizable atoms. Here the atom types 1 to 3 (C and O
|
||||
atoms) are DC, atom types 4 and 5 (H atoms) are non-polarizable and
|
||||
the atom types 6 to 8 are the newly created DPs.
|
||||
|
||||
By recognizing the fix {drude}, LAMMPS will find and store matching
|
||||
DC-DP pairs and will treat DP as equivalent to their DC in the
|
||||
{special bonds} relations. It may be necessary to extend the space
|
||||
for storing such special relations. In this case extra space should
|
||||
be reserved by using the {extra/special/per/atom} keyword of either
|
||||
the "read_data"_read_data.html or "create_box"_create_box.html
|
||||
command. With our phenol, there is 1 more special neighbor for which
|
||||
space is required. Otherwise LAMMPS crashes and gives the required
|
||||
value.
|
||||
|
||||
read_data data-p.lmp extra/special/per/atom 1 :pre
|
||||
|
||||
Let us assume we want to run a simple NVT simulation at 300 K. Note
|
||||
that Drude oscillators need to be thermalized at a low temperature in
|
||||
order to approximate a self-consistent field (SCF), therefore it is not
|
||||
possible to simulate an NVE ensemble with this package. Since dipoles
|
||||
are approximated by a charged DC-DP pair, the {pair_style} must
|
||||
include Coulomb interactions, for instance {lj/cut/coul/long} with
|
||||
{kspace_style pppm}. For example, with a cutoff of 10. and a precision
|
||||
1.e-4:
|
||||
|
||||
pair_style lj/cut/coul/long 10.0
|
||||
kspace_style pppm 1.0e-4 :pre
|
||||
|
||||
As compared to the non-polarizable input file, {pair_coeff} lines need
|
||||
to be added for the DPs. Since the DPs have no Lennard-Jones
|
||||
interactions, their {epsilon} is 0. so the only {pair_coeff} line
|
||||
that needs to be added is
|
||||
|
||||
pair_coeff * 6* 0.0 0.0 # All-DPs :pre
|
||||
|
||||
Now for the thermalization, the simplest choice is to use the "fix
|
||||
langevin/drude"_fix_langevin_drude.html.
|
||||
|
||||
fix LANG all langevin/drude 300. 100 12435 1. 20 13977 :pre
|
||||
|
||||
This applies a Langevin thermostat at temperature 300. to the centers
|
||||
of mass of the DC-DP pairs, with relaxation time 100 and with random
|
||||
seed 12345. This fix applies also a Langevin thermostat at temperature
|
||||
1. to the relative motion of the DPs around their DCs, with relaxation
|
||||
time 20 and random seed 13977. Only the DCs and non-polarizable
|
||||
atoms need to be in this fix's group. LAMMPS will thermostat the DPs
|
||||
together with their DC. For this, ghost atoms need to know their
|
||||
velocities. Thus you need to add the following command:
|
||||
|
||||
comm_modify vel yes :pre
|
||||
|
||||
In order to avoid that the center of mass of the whole system
|
||||
drifts due to the random forces of the Langevin thermostat on DCs, you
|
||||
can add the {zero yes} option at the end of the fix line.
|
||||
|
||||
If the fix {shake} is used to constrain the C-H bonds, it should be
|
||||
invoked after the fix {langevin/drude} for more accuracy.
|
||||
|
||||
fix SHAKE ATOMS shake 0.0001 20 0 t 4 5 :pre
|
||||
|
||||
NOTE: The group of the fix {shake} must not include the DPs. If the
|
||||
group {ATOMS} is defined by non-DPs atom types, you could use
|
||||
|
||||
Since the fix {langevin/drude} does not perform time integration (just
|
||||
modification of forces but no position/velocity updates), the fix
|
||||
{nve} should be used in conjunction.
|
||||
|
||||
fix NVE all nve :pre
|
||||
|
||||
Finally, do not forget to update the atom type elements if you use
|
||||
them in a {dump_modify ... element ...} command, by adding the element
|
||||
type of the DPs. Here for instance
|
||||
|
||||
dump DUMP all custom 10 dump.lammpstrj id mol type element x y z ix iy iz
|
||||
dump_modify DUMP element C C O H H D D D :pre
|
||||
|
||||
The input file should now be ready for use!
|
||||
|
||||
You will notice that the global temperature {thermo_temp} computed by
|
||||
LAMMPS is not 300. K as wanted. This is because LAMMPS treats DPs as
|
||||
standard atoms in his default compute. If you want to output the
|
||||
temperatures of the DC-DP pair centers of mass and of the DPs relative
|
||||
to their DCs, you should use the "compute
|
||||
temp_drude"_compute_temp_drude.html
|
||||
|
||||
compute TDRUDE all temp/drude :pre
|
||||
|
||||
And then output the correct temperatures of the Drude oscillators
|
||||
using {thermo_style custom} with respectively {c_TDRUDE\[1\]} and
|
||||
{c_TDRUDE\[2\]}. These should be close to 300.0 and 1.0 on average.
|
||||
|
||||
thermo_style custom step temp c_TDRUDE\[1\] c_TDRUDE\[2\] :pre
|
||||
|
||||
|
||||
:line
|
||||
|
||||
[Thole screening]
|
||||
|
||||
Dipolar interactions represented by point charges on springs may not
|
||||
be stable, for example if the atomic polarizability is too high for
|
||||
instance, a DP can escape from its DC and be captured by another DC,
|
||||
which makes the force and energy diverge and the simulation
|
||||
crash. Even without reaching this extreme case, the correlation
|
||||
between nearby dipoles on the same molecule may be exaggerated. Often,
|
||||
special bond relations prevent bonded neighboring atoms to see the
|
||||
charge of each other's DP, so that the problem does not always appear.
|
||||
It is possible to use screened dipole-dipole interactions by using the
|
||||
"{pair_style thole}"_pair_thole.html. This is implemented as a
|
||||
correction to the Coulomb pair_styles, which dampens at short distance
|
||||
the interactions between the charges representing the induced dipoles.
|
||||
It is to be used as {hybrid/overlay} with any standard {coul} pair
|
||||
style. In our example, we would use
|
||||
|
||||
pair_style hybrid/overlay lj/cut/coul/long 10.0 thole 2.6 10.0 :pre
|
||||
|
||||
This tells LAMMPS that we are using two pair_styles. The first one is
|
||||
as above ({lj/cut/coul/long 10.0}). The second one is a {thole}
|
||||
pair_style with default screening factor 2.6 ("Noskov"_#Noskov2) and
|
||||
cutoff 10.0.
|
||||
|
||||
Since {hybrid/overlay} does not support mixing rules, the interaction
|
||||
coefficients of all the pairs of atom types with i < j should be
|
||||
explicitly defined. The output of the {polarizer} script can be used
|
||||
to complete the {pair_coeff} section of the input file. In our
|
||||
example, this will look like:
|
||||
|
||||
pair_coeff 1 1 lj/cut/coul/long 0.0700 3.550
|
||||
pair_coeff 1 2 lj/cut/coul/long 0.0700 3.550
|
||||
pair_coeff 1 3 lj/cut/coul/long 0.1091 3.310
|
||||
pair_coeff 1 4 lj/cut/coul/long 0.0458 2.985
|
||||
pair_coeff 2 2 lj/cut/coul/long 0.0700 3.550
|
||||
pair_coeff 2 3 lj/cut/coul/long 0.1091 3.310
|
||||
pair_coeff 2 4 lj/cut/coul/long 0.0458 2.985
|
||||
pair_coeff 3 3 lj/cut/coul/long 0.1700 3.070
|
||||
pair_coeff 3 4 lj/cut/coul/long 0.0714 2.745
|
||||
pair_coeff 4 4 lj/cut/coul/long 0.0300 2.420
|
||||
pair_coeff * 5 lj/cut/coul/long 0.0000 0.000
|
||||
pair_coeff * 6* lj/cut/coul/long 0.0000 0.000
|
||||
pair_coeff 1 1 thole 1.090 2.510
|
||||
pair_coeff 1 2 thole 1.218 2.510
|
||||
pair_coeff 1 3 thole 0.829 1.590
|
||||
pair_coeff 1 6 thole 1.090 2.510
|
||||
pair_coeff 1 7 thole 1.218 2.510
|
||||
pair_coeff 1 8 thole 0.829 1.590
|
||||
pair_coeff 2 2 thole 1.360 2.510
|
||||
pair_coeff 2 3 thole 0.926 1.590
|
||||
pair_coeff 2 6 thole 1.218 2.510
|
||||
pair_coeff 2 7 thole 1.360 2.510
|
||||
pair_coeff 2 8 thole 0.926 1.590
|
||||
pair_coeff 3 3 thole 0.630 0.670
|
||||
pair_coeff 3 6 thole 0.829 1.590
|
||||
pair_coeff 3 7 thole 0.926 1.590
|
||||
pair_coeff 3 8 thole 0.630 0.670
|
||||
pair_coeff 6 6 thole 1.090 2.510
|
||||
pair_coeff 6 7 thole 1.218 2.510
|
||||
pair_coeff 6 8 thole 0.829 1.590
|
||||
pair_coeff 7 7 thole 1.360 2.510
|
||||
pair_coeff 7 8 thole 0.926 1.590
|
||||
pair_coeff 8 8 thole 0.630 0.670 :pre
|
||||
|
||||
For the {thole} pair style the coefficients are
|
||||
|
||||
the atom polarizability in units of cubic length :olb,l
|
||||
the screening factor of the Thole function (optional, default value
|
||||
specified by the pair_style command) :l
|
||||
the cutoff (optional, default value defined by the pair_style command) :l
|
||||
:ole
|
||||
|
||||
The special neighbors have charge-charge and charge-dipole
|
||||
interactions screened by the {coul} factors of the {special_bonds}
|
||||
command (0.0, 0.0, and 0.5 in the example above). Without using the
|
||||
pair_style {thole}, dipole-dipole interactions are screened by the
|
||||
same factor. By using the pair_style {thole}, dipole-dipole
|
||||
interactions are screened by Thole's function, whatever their special
|
||||
relationship (except within each DC-DP pair of course). Consider for
|
||||
example 1-2 neighbors: using the pair_style {thole}, their dipoles
|
||||
will see each other (despite the {coul} factor being 0.) and the
|
||||
interactions between these dipoles will be damped by Thole's function.
|
||||
|
||||
|
||||
:line
|
||||
|
||||
[Thermostats and barostats]
|
||||
|
||||
Using a Nose-Hoover barostat with the {langevin/drude} thermostat is
|
||||
straightforward using fix {nph} instead of {nve}. For example:
|
||||
|
||||
fix NPH all nph iso 1. 1. 500 :pre
|
||||
|
||||
It is also possible to use a Nose-Hoover instead of a Langevin
|
||||
thermostat. This requires to use "{fix
|
||||
drude/transform}"_fix_drude_transform.html just before and after the
|
||||
time integration fixes. The {fix drude/transform/direct} converts the
|
||||
atomic masses, positions, velocities and forces into a reduced
|
||||
representation, where the DCs transform into the centers of mass of
|
||||
the DC-DP pairs and the DPs transform into their relative position
|
||||
with respect to their DC. The {fix drude/transform/inverse} performs
|
||||
the reverse transformation. For a NVT simulation, with the DCs and
|
||||
atoms at 300 K and the DPs at 1 K relative to their DC one would use
|
||||
|
||||
fix DIRECT all drude/transform/direct
|
||||
fix NVT1 ATOMS nvt temp 300. 300. 100
|
||||
fix NVT2 DRUDES nvt temp 1. 1. 20
|
||||
fix INVERSE all drude/transform/inverse :pre
|
||||
|
||||
For our phenol example, the groups would be defined as
|
||||
|
||||
group ATOMS type 1 2 3 4 5 # DCs and non-polarizable atoms
|
||||
group CORES type 1 2 3 # DCs
|
||||
group DRUDES type 6 7 8 # DPs :pre
|
||||
|
||||
Note that with the fixes {drude/transform}, it is not required to
|
||||
specify {comm_modify vel yes} because the fixes do it anyway (several
|
||||
times and for the forces also). To avoid the flying ice cube artifact
|
||||
"(Lamoureux)"_#Lamoureux2, where the atoms progressively freeze and the
|
||||
center of mass of the whole system drifts faster and faster, the {fix
|
||||
momentum} can be used. For instance:
|
||||
|
||||
fix MOMENTUM all momentum 100 linear 1 1 1 :pre
|
||||
|
||||
It is a bit more tricky to run a NPT simulation with Nose-Hoover
|
||||
barostat and thermostat. First, the volume should be integrated only
|
||||
once. So the fix for DCs and atoms should be {npt} while the fix for
|
||||
DPs should be {nvt} (or vice versa). Second, the {fix npt} computes a
|
||||
global pressure and thus a global temperature whatever the fix group.
|
||||
We do want the pressure to correspond to the whole system, but we want
|
||||
the temperature to correspond to the fix group only. We must then use
|
||||
the {fix_modify} command for this. In the end, the block of
|
||||
instructions for thermostatting and barostatting will look like
|
||||
|
||||
compute TATOMS ATOMS temp
|
||||
fix DIRECT all drude/transform/direct
|
||||
fix NPT ATOMS npt temp 300. 300. 100 iso 1. 1. 500
|
||||
fix_modify NPT temp TATOMS press thermo_press
|
||||
fix NVT DRUDES nvt temp 1. 1. 20
|
||||
fix INVERSE all drude/transform/inverse :pre
|
||||
|
||||
|
||||
:line
|
||||
|
||||
[Rigid bodies]
|
||||
|
||||
You may want to simulate molecules as rigid bodies (but polarizable).
|
||||
Common cases are water models such as "SWM4-NDP"_#SWM4-NDP, which is a
|
||||
kind of polarizable TIP4P water. The rigid bodies and the DPs should
|
||||
be integrated separately, even with the Langevin thermostat. Let us
|
||||
review the different thermostats and ensemble combinations.
|
||||
|
||||
NVT ensemble using Langevin thermostat:
|
||||
|
||||
comm_modify vel yes
|
||||
fix LANG all langevin/drude 300. 100 12435 1. 20 13977
|
||||
fix RIGID ATOMS rigid/nve/small molecule
|
||||
fix NVE DRUDES nve :pre
|
||||
|
||||
NVT ensemble using Nose-Hoover thermostat:
|
||||
|
||||
fix DIRECT all drude/transform/direct
|
||||
fix RIGID ATOMS rigid/nvt/small molecule temp 300. 300. 100
|
||||
fix NVT DRUDES nvt temp 1. 1. 20
|
||||
fix INVERSE all drude/transform/inverse :pre
|
||||
|
||||
NPT ensemble with Langevin thermostat:
|
||||
|
||||
comm_modify vel yes
|
||||
fix LANG all langevin/drude 300. 100 12435 1. 20 13977
|
||||
fix RIGID ATOMS rigid/nph/small molecule iso 1. 1. 500
|
||||
fix NVE DRUDES nve :pre
|
||||
|
||||
NPT ensemble using Nose-Hoover thermostat:
|
||||
|
||||
compute TATOM ATOMS temp
|
||||
fix DIRECT all drude/transform/direct
|
||||
fix RIGID ATOMS rigid/npt/small molecule temp 300. 300. 100 iso 1. 1. 500
|
||||
fix_modify RIGID temp TATOM press thermo_press
|
||||
fix NVT DRUDES nvt temp 1. 1. 20
|
||||
fix INVERSE all drude/transform/inverse :pre
|
||||
|
||||
|
||||
:line
|
||||
|
||||
:link(Lamoureux2)
|
||||
[(Lamoureux)] Lamoureux and Roux, J Chem Phys, 119, 3025-3039 (2003)
|
||||
|
||||
:link(Schroeder)
|
||||
[(Schroeder)] Schroeder and Steinhauser, J Chem Phys, 133,
|
||||
154511 (2010).
|
||||
|
||||
:link(Jiang2)
|
||||
[(Jiang)] Jiang, Hardy, Phillips, MacKerell, Schulten, and Roux,
|
||||
J Phys Chem Lett, 2, 87-92 (2011).
|
||||
|
||||
:link(Thole2)
|
||||
[(Thole)] Chem Phys, 59, 341 (1981).
|
||||
|
||||
:link(Noskov2)
|
||||
[(Noskov)] Noskov, Lamoureux and Roux, J Phys Chem B, 109, 6705 (2005).
|
||||
|
||||
:link(SWM4-NDP)
|
||||
[(SWM4-NDP)] Lamoureux, Harder, Vorobyov, Roux, MacKerell, Chem Phys
|
||||
Let, 418, 245-249 (2006)
|
||||
|
|
@ -1,47 +0,0 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Calculate elastic constants :h3
|
||||
|
||||
Elastic constants characterize the stiffness of a material. The formal
|
||||
definition is provided by the linear relation that holds between the
|
||||
stress and strain tensors in the limit of infinitesimal deformation.
|
||||
In tensor notation, this is expressed as s_ij = C_ijkl * e_kl, where
|
||||
the repeated indices imply summation. s_ij are the elements of the
|
||||
symmetric stress tensor. e_kl are the elements of the symmetric strain
|
||||
tensor. C_ijkl are the elements of the fourth rank tensor of elastic
|
||||
constants. In three dimensions, this tensor has 3^4=81 elements. Using
|
||||
Voigt notation, the tensor can be written as a 6x6 matrix, where C_ij
|
||||
is now the derivative of s_i w.r.t. e_j. Because s_i is itself a
|
||||
derivative w.r.t. e_i, it follows that C_ij is also symmetric, with at
|
||||
most 7*6/2 = 21 distinct elements.
|
||||
|
||||
At zero temperature, it is easy to estimate these derivatives by
|
||||
deforming the simulation box in one of the six directions using the
|
||||
"change_box"_change_box.html command and measuring the change in the
|
||||
stress tensor. A general-purpose script that does this is given in the
|
||||
examples/elastic directory described on the "Examples"_Examples.html
|
||||
doc page.
|
||||
|
||||
Calculating elastic constants at finite temperature is more
|
||||
challenging, because it is necessary to run a simulation that performs
|
||||
time averages of differential properties. One way to do this is to
|
||||
measure the change in average stress tensor in an NVT simulations when
|
||||
the cell volume undergoes a finite deformation. In order to balance
|
||||
the systematic and statistical errors in this method, the magnitude of
|
||||
the deformation must be chosen judiciously, and care must be taken to
|
||||
fully equilibrate the deformed cell before sampling the stress
|
||||
tensor. Another approach is to sample the triclinic cell fluctuations
|
||||
that occur in an NPT simulation. This method can also be slow to
|
||||
converge and requires careful post-processing "(Shinoda)"_#Shinoda1
|
||||
|
||||
:line
|
||||
|
||||
:link(Shinoda1)
|
||||
[(Shinoda)] Shinoda, Shiga, and Mikami, Phys Rev B, 69, 134103 (2004).
|
|
@ -1,419 +0,0 @@
|
|||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
LAMMPS GitHub tutorial :h3
|
||||
[written by Stefan Paquay]
|
||||
|
||||
:line
|
||||
|
||||
This document describes the process of how to use GitHub to integrate
|
||||
changes or additions you have made to LAMMPS into the official LAMMPS
|
||||
distribution. It uses the process of updating this very tutorial as
|
||||
an example to describe the individual steps and options. You need to
|
||||
be familiar with git and you may want to have a look at the
|
||||
"Git book"_http://git-scm.com/book/ to reacquaint yourself with some
|
||||
of the more advanced git features used below.
|
||||
|
||||
As of fall 2016, submitting contributions to LAMMPS via pull requests
|
||||
on GitHub is the preferred option for integrating contributed features
|
||||
or improvements to LAMMPS, as it significantly reduces the amount of
|
||||
work required by the LAMMPS developers. Consequently, creating a pull
|
||||
request will increase your chances to have your contribution included
|
||||
and will reduce the time until the integration is complete. For more
|
||||
information on the requirements to have your code included into LAMMPS
|
||||
please see the "Modify contribute"_Modify_contribute.html doc page.
|
||||
|
||||
:line
|
||||
|
||||
[Making an account]
|
||||
|
||||
First of all, you need a GitHub account. This is fairly simple, just
|
||||
go to "GitHub"_https://github.com and create an account by clicking
|
||||
the "Sign up for GitHub" button. Once your account is created, you
|
||||
can sign in by clicking the button in the top left and filling in your
|
||||
username or e-mail address and password.
|
||||
|
||||
:line
|
||||
|
||||
[Forking the repository]
|
||||
|
||||
To get changes into LAMMPS, you need to first fork the `lammps/lammps`
|
||||
repository on GitHub. At the time of writing, {master} is the preferred
|
||||
target branch. Thus go to "LAMMPS on GitHub"_https://github.com/lammps/lammps
|
||||
and make sure branch is set to "master", as shown in the figure below.
|
||||
|
||||
:c,image(JPG/tutorial_branch.png)
|
||||
|
||||
If it is not, use the button to change it to {master}. Once it is, use the
|
||||
fork button to create a fork.
|
||||
|
||||
:c,image(JPG/tutorial_fork.png)
|
||||
|
||||
|
||||
This will create a fork (which is essentially a copy, but uses less
|
||||
resources) of the LAMMPS repository under your own GitHub account. You
|
||||
can make changes in this fork and later file {pull requests} to allow
|
||||
the upstream repository to merge changes from your own fork into the one
|
||||
we just forked from (or others that were forked from the same repository).
|
||||
At the same time, you can set things up, so you can include changes from
|
||||
upstream into your repository and thus keep it in sync with the ongoing
|
||||
LAMMPS development.
|
||||
|
||||
:line
|
||||
|
||||
[Adding changes to your own fork]
|
||||
|
||||
Additions to the upstream version of LAMMPS are handled using {feature
|
||||
branches}. For every new feature, a so-called feature branch is
|
||||
created, which contains only those modification relevant to one specific
|
||||
feature. For example, adding a single fix would consist of creating a
|
||||
branch with only the fix header and source file and nothing else. It is
|
||||
explained in more detail here: "feature branch
|
||||
workflow"_https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow.
|
||||
|
||||
[Feature branches]
|
||||
|
||||
First of all, create a clone of your version on github on your local
|
||||
machine via HTTPS:
|
||||
|
||||
$ git clone https://github.com/<your user name>/lammps.git <some name> :pre
|
||||
|
||||
or, if you have set up your GitHub account for using SSH keys, via SSH:
|
||||
|
||||
$ git clone git@github.com:<your user name>/lammps.git :pre
|
||||
|
||||
You can find the proper URL by clicking the "Clone or download"-button:
|
||||
|
||||
:c,image(JPG/tutorial_https_block.png)
|
||||
|
||||
The above command copies ("clones") the git repository to your local
|
||||
machine to a directory with the name you chose. If none is given, it will
|
||||
default to "lammps". Typical names are "mylammps" or something similar.
|
||||
|
||||
You can use this local clone to make changes and
|
||||
test them without interfering with the repository on GitHub.
|
||||
|
||||
To pull changes from upstream into this copy, you can go to the directory
|
||||
and use git pull:
|
||||
|
||||
$ cd mylammps
|
||||
$ git checkout master
|
||||
$ git pull https://github.com/lammps/lammps :pre
|
||||
|
||||
You can also add this URL as a remote:
|
||||
|
||||
$ git remote add lammps_upstream https://www.github.com/lammps/lammps :pre
|
||||
|
||||
At this point, you typically make a feature branch from the updated master
|
||||
branch for the feature you want to work on. This tutorial contains the
|
||||
workflow that updated this tutorial, and hence we will call the branch
|
||||
"github-tutorial-update":
|
||||
|
||||
$ git checkout -b github-tutorial-update master :pre
|
||||
|
||||
Now that we have changed branches, we can make our changes to our local
|
||||
repository. Just remember that if you want to start working on another,
|
||||
unrelated feature, you should switch branches!
|
||||
|
||||
[After changes are made]
|
||||
|
||||
After everything is done, add the files to the branch and commit them:
|
||||
|
||||
$ git add doc/src/Howto_github.txt
|
||||
$ git add doc/src/JPG/tutorial*.png :pre
|
||||
|
||||
IMPORTANT NOTE: Do not use {git commit -a} (or {git add -A}). The -a
|
||||
flag (or -A flag) will automatically include _all_ modified or new files
|
||||
and that is rarely the behavior you want. It can easily lead to
|
||||
accidentally adding unrelated and unwanted changes into the repository.
|
||||
Instead it is preferable to explicitly use {git add}, {git rm}, {git mv}
|
||||
for adding, removing, renaming individual files, respectively, and then
|
||||
{git commit} to finalize the commit. Carefully check all pending
|
||||
changes with {git status} before committing them. If you find doing
|
||||
this on the command line too tedious, consider using a GUI, for example
|
||||
the one included in git distributions written in Tk, i.e. use {git gui}
|
||||
(on some Linux distributions it may be required to install an additional
|
||||
package to use it).
|
||||
|
||||
After adding all files, the change set can be committed with some
|
||||
useful message that explains the change.
|
||||
|
||||
$ git commit -m 'Finally updated the github tutorial' :pre
|
||||
|
||||
After the commit, the changes can be pushed to the same branch on GitHub:
|
||||
|
||||
$ git push :pre
|
||||
|
||||
Git will ask you for your user name and password on GitHub if you have
|
||||
not configured anything. If your local branch is not present on GitHub yet,
|
||||
it will ask you to add it by running
|
||||
|
||||
$ git push --set-upstream origin github-tutorial-update :pre
|
||||
|
||||
If you correctly type your user name and
|
||||
password, the feature branch should be added to your fork on GitHub.
|
||||
|
||||
If you want to make really sure you push to the right repository
|
||||
(which is good practice), you can provide it explicitly:
|
||||
|
||||
$ git push origin :pre
|
||||
|
||||
or using an explicit URL:
|
||||
|
||||
$ git push git@github.com:Pakketeretet2/lammps.git :pre
|
||||
|
||||
:line
|
||||
|
||||
[Filing a pull request]
|
||||
|
||||
Up to this point in the tutorial, all changes were to {your} clones of
|
||||
LAMMPS. Eventually, however, you want this feature to be included into
|
||||
the official LAMMPS version. To do this, you will want to file a pull
|
||||
request by clicking on the "New pull request" button:
|
||||
|
||||
:c,image(JPG/tutorial_new_pull_request.png)
|
||||
|
||||
Make sure that the current branch is set to the correct one, which, in
|
||||
this case, is "github-tutorial-update". If done correctly, the only
|
||||
changes you will see are those that were made on this branch.
|
||||
|
||||
This will open up a new window that lists changes made to the
|
||||
repository. If you are just adding new files, there is not much to do,
|
||||
but I suppose merge conflicts are to be resolved here if there are
|
||||
changes in existing files. If all changes can automatically be merged,
|
||||
green text at the top will say so and you can click the "Create pull
|
||||
request" button, see image.
|
||||
|
||||
:c,image(JPG/tutorial_create_new_pull_request1.png)
|
||||
|
||||
Before creating the pull request, make sure the short title is accurate
|
||||
and add a comment with details about your pull request. Here you write
|
||||
what your modifications do and why they should be incorporated upstream.
|
||||
|
||||
Note the checkbox that says "Allow edits from maintainers".
|
||||
This is checked by default checkbox (although in my version of Firefox, only the checkmark is visible):
|
||||
|
||||
:c,image(JPG/tutorial_edits_maintainers.png)
|
||||
|
||||
If it is checked, maintainers can immediately add their own edits to the
|
||||
pull request. This helps the inclusion of your branch significantly, as
|
||||
simple/trivial changes can be added directly to your pull request branch
|
||||
by the LAMMPS maintainers. The alternative would be that they make
|
||||
changes on their own version of the branch and file a reverse pull
|
||||
request to you. Just leave this box checked unless you have a very good
|
||||
reason not to.
|
||||
|
||||
Now just write some nice comments and click on "Create pull request".
|
||||
|
||||
:c,image(JPG/tutorial_create_new_pull_request2.png)
|
||||
|
||||
:line
|
||||
|
||||
[After filing a pull request]
|
||||
|
||||
NOTE: When you submit a pull request (or ask for a pull request) for the
|
||||
first time, you will receive an invitation to become a LAMMPS project
|
||||
collaborator. Please accept this invite as being a collaborator will
|
||||
simplify certain administrative tasks and will probably speed up the
|
||||
merging of your feature, too.
|
||||
|
||||
You will notice that after filing the pull request, some checks are
|
||||
performed automatically:
|
||||
|
||||
:c,image(JPG/tutorial_automated_checks.png)
|
||||
|
||||
If all is fine, you will see this:
|
||||
|
||||
:c,image(JPG/tutorial_automated_checks_passed.png)
|
||||
|
||||
If any of the checks are failing, your pull request will not be
|
||||
processed, as your changes may break compilation for certain
|
||||
configurations or may not merge cleanly. It is your responsibility
|
||||
to remove the reason(s) for the failed test(s). If you need help
|
||||
with this, please contact the LAMMPS developers by adding a comment
|
||||
explaining your problems with resolving the failed tests.
|
||||
|
||||
A few further interesting things (can) happen to pull requests before
|
||||
they are included.
|
||||
|
||||
[Additional changes]
|
||||
|
||||
First of all, any additional changes you push into your branch in your
|
||||
repository will automatically become part of the pull request:
|
||||
|
||||
:c,image(JPG/tutorial_additional_changes.png)
|
||||
|
||||
This means you can add changes that should be part of the feature after
|
||||
filing the pull request, which is useful in case you have forgotten
|
||||
them, or if a developer has requested that something needs to be changed
|
||||
before the feature can be accepted into the official LAMMPS version.
|
||||
After each push, the automated checks are run again.
|
||||
|
||||
[Labels]
|
||||
|
||||
LAMMPS developers may add labels to your pull request to assign it to
|
||||
categories (mostly for bookkeeping purposes), but a few of them are
|
||||
important: needs_work, work_in_progress, test-for-regression, and
|
||||
full-regression-test. The first two indicate, that your pull request
|
||||
is not considered to be complete. With "needs_work" the burden is on
|
||||
exclusively on you; while "work_in_progress" can also mean, that a
|
||||
LAMMPS developer may want to add changes. Please watch the comments
|
||||
to the pull requests. The two "test" labels are used to trigger
|
||||
extended tests before the code is merged. This is sometimes done by
|
||||
LAMMPS developers, if they suspect that there may be some subtle
|
||||
side effects from your changes. It is not done by default, because
|
||||
those tests are very time consuming.
|
||||
|
||||
[Reviews]
|
||||
|
||||
As of Summer 2018, a pull request needs at least 1 approving review
|
||||
from a LAMMPS developer with write access to the repository.
|
||||
In case your changes touch code that certain developers are associated
|
||||
with, they are auto-requested by the GitHub software. Those associations
|
||||
are set in the file
|
||||
".github/CODEOWNERS"_https://github.com/lammps/lammps/blob/master/.github/CODEOWNERS
|
||||
Thus if you want to be automatically notified to review when anybody
|
||||
changes files or packages, that you have contributed to LAMMPS, you can
|
||||
add suitable patterns to that file, or a LAMMPS developer may add you.
|
||||
|
||||
Otherwise, you can also manually request reviews from specific developers,
|
||||
or LAMMPS developers - in their assessment of your pull request - may
|
||||
determine who else should be reviewing your contribution and add that person.
|
||||
Through reviews, LAMMPS developers also may request specific changes from you.
|
||||
If those are not addressed, your pull requests cannot be merged.
|
||||
|
||||
[Assignees]
|
||||
|
||||
There is an assignee property for pull requests. If the request has not
|
||||
been reviewed by any developer yet, it is not assigned to anyone. After
|
||||
revision, a developer can choose to assign it to either a) you, b) a
|
||||
LAMMPS developer (including him/herself) or c) Axel Kohlmeyer (akohlmey).
|
||||
|
||||
Case a) happens if changes are required on your part :ulb,l
|
||||
Case b) means that at the moment, it is being tested and reviewed by a
|
||||
LAMMPS developer with the expectation that some changes would be required.
|
||||
After the review, the developer can choose to implement changes directly
|
||||
or suggest them to you. :l
|
||||
Case c) means that the pull request has been assigned to the developer
|
||||
overseeing the merging of pull requests into the master branch. :ule,l
|
||||
|
||||
In this case, Axel assigned the tutorial to Steve:
|
||||
|
||||
:c,image(JPG/tutorial_steve_assignee.png)
|
||||
|
||||
[Edits from LAMMPS maintainers]
|
||||
|
||||
If you allowed edits from maintainers (the default), any LAMMPS
|
||||
maintainer can add changes to your pull request. In this case, both
|
||||
Axel and Richard made changes to the tutorial:
|
||||
|
||||
:c,image(JPG/tutorial_changes_others.png)
|
||||
|
||||
[Reverse pull requests]
|
||||
|
||||
Sometimes, however, you might not feel comfortable having other people
|
||||
push changes into your own branch, or maybe the maintainers are not sure
|
||||
their idea was the right one. In such a case, they can make changes,
|
||||
reassign you as the assignee, and file a "reverse pull request", i.e.
|
||||
file a pull request in your GitHub repository to include changes in the
|
||||
branch, that you have submitted as a pull request yourself. In that
|
||||
case, you can choose to merge their changes back into your branch,
|
||||
possibly make additional changes or corrections and proceed from there.
|
||||
It looks something like this:
|
||||
|
||||
:c,image(JPG/tutorial_reverse_pull_request.png)
|
||||
|
||||
For some reason, the highlighted button didn't work in my case, but I
|
||||
can go to my own repository and merge the pull request from there:
|
||||
|
||||
:c,image(JPG/tutorial_reverse_pull_request2.png)
|
||||
|
||||
Be sure to check the changes to see if you agree with them by clicking
|
||||
on the tab button:
|
||||
|
||||
:c,image(JPG/tutorial_reverse_pull_request3.png)
|
||||
|
||||
In this case, most of it is changes in the markup and a short rewrite of
|
||||
Axel's explanation of the "git gui" and "git add" commands.
|
||||
|
||||
:c,image(JPG/tutorial_reverse_pull_request4.png)
|
||||
|
||||
Because the changes are OK with us, we are going to merge by clicking on
|
||||
"Merge pull request". After a merge it looks like this:
|
||||
|
||||
:c,image(JPG/tutorial_reverse_pull_request5.png)
|
||||
|
||||
Now, since in the meantime our local text for the tutorial also changed,
|
||||
we need to pull Axel's change back into our branch, and merge them:
|
||||
|
||||
$ git add Howto_github.txt
|
||||
$ git add JPG/tutorial_reverse_pull_request*.png
|
||||
$ git commit -m "Updated text and images on reverse pull requests"
|
||||
$ git pull :pre
|
||||
|
||||
In this case, the merge was painless because git could auto-merge:
|
||||
|
||||
:c,image(JPG/tutorial_reverse_pull_request6.png)
|
||||
|
||||
With Axel's changes merged in and some final text updates, our feature
|
||||
branch is now perfect as far as we are concerned, so we are going to
|
||||
commit and push again:
|
||||
|
||||
$ git add Howto_github.txt
|
||||
$ git add JPG/tutorial_reverse_pull_request6.png
|
||||
$ git commit -m "Merged Axel's suggestions and updated text"
|
||||
$ git push git@github.com:Pakketeretet2/lammps :pre
|
||||
|
||||
This merge also shows up on the lammps GitHub page:
|
||||
|
||||
:c,image(JPG/tutorial_reverse_pull_request7.png)
|
||||
|
||||
:line
|
||||
|
||||
[After a merge]
|
||||
|
||||
When everything is fine, the feature branch is merged into the master branch:
|
||||
|
||||
:c,image(JPG/tutorial_merged.png)
|
||||
|
||||
Now one question remains: What to do with the feature branch that got
|
||||
merged into upstream?
|
||||
|
||||
It is in principle safe to delete them from your own fork. This helps
|
||||
keep it a bit more tidy. Note that you first have to switch to another
|
||||
branch!
|
||||
|
||||
$ git checkout master
|
||||
$ git pull master
|
||||
$ git branch -d github-tutorial-update :pre
|
||||
|
||||
If you do not pull first, it is not really a problem but git will warn
|
||||
you at the next statement that you are deleting a local branch that
|
||||
was not yet fully merged into HEAD. This is because git does not yet
|
||||
know your branch just got merged into LAMMPS upstream. If you
|
||||
first delete and then pull, everything should still be fine.
|
||||
|
||||
Finally, if you delete the branch locally, you might want to push this
|
||||
to your remote(s) as well:
|
||||
|
||||
$ git push origin :github-tutorial-update :pre
|
||||
|
||||
[Recent changes in the workflow]
|
||||
|
||||
Some changes to the workflow are not captured in this tutorial. For
|
||||
example, in addition to the master branch, to which all new features
|
||||
should be submitted, there is now also an "unstable" and a "stable"
|
||||
branch; these have the same content as "master", but are only updated
|
||||
after a patch release or stable release was made.
|
||||
Furthermore, the naming of the patches now follow the pattern
|
||||
"patch_<Day><Month><Year>" to simplify comparisons between releases.
|
||||
Finally, all patches and submissions are subject to automatic testing
|
||||
and code checks to make sure they at the very least compile.
|
||||
|
||||
A discussion of the LAMMPS developer GitHub workflow can be found in the file
|
||||
"doc/github-development-workflow.md"_https://github.com/lammps/lammps/blob/master/doc/github-development-workflow.md
|
|
@ -1,57 +0,0 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Granular models :h3
|
||||
|
||||
Granular system are composed of spherical particles with a diameter,
|
||||
as opposed to point particles. This means they have an angular
|
||||
velocity and torque can be imparted to them to cause them to rotate.
|
||||
|
||||
To run a simulation of a granular model, you will want to use
|
||||
the following commands:
|
||||
|
||||
"atom_style sphere"_atom_style.html
|
||||
"fix nve/sphere"_fix_nve_sphere.html
|
||||
"fix gravity"_fix_gravity.html :ul
|
||||
|
||||
This compute
|
||||
|
||||
"compute erotate/sphere"_compute_erotate_sphere.html :ul
|
||||
|
||||
calculates rotational kinetic energy which can be "output with
|
||||
thermodynamic info"_Howto_output.html.
|
||||
|
||||
Use one of these 3 pair potentials, which compute forces and torques
|
||||
between interacting pairs of particles:
|
||||
|
||||
"pair_style"_pair_style.html gran/history
|
||||
"pair_style"_pair_style.html gran/no_history
|
||||
"pair_style"_pair_style.html gran/hertzian :ul
|
||||
|
||||
These commands implement fix options specific to granular systems:
|
||||
|
||||
"fix freeze"_fix_freeze.html
|
||||
"fix pour"_fix_pour.html
|
||||
"fix viscous"_fix_viscous.html
|
||||
"fix wall/gran"_fix_wall_gran.html :ul
|
||||
|
||||
The fix style {freeze} zeroes both the force and torque of frozen
|
||||
atoms, and should be used for granular system instead of the fix style
|
||||
{setforce}.
|
||||
|
||||
For computational efficiency, you can eliminate needless pairwise
|
||||
computations between frozen atoms by using this command:
|
||||
|
||||
"neigh_modify"_neigh_modify.html exclude :ul
|
||||
|
||||
NOTE: By default, for 2d systems, granular particles are still modeled
|
||||
as 3d spheres, not 2d discs (circles), meaning their moment of inertia
|
||||
will be the same as in 3d. If you wish to model granular particles in
|
||||
2d as 2d discs, see the note on this topic on the "Howto 2d"_Howto_2d.html
|
||||
doc page, where 2d simulations are discussed.
|
|
@ -1,90 +0,0 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Calculate thermal conductivity :h3
|
||||
|
||||
The thermal conductivity kappa of a material can be measured in at
|
||||
least 4 ways using various options in LAMMPS. See the examples/KAPPA
|
||||
directory for scripts that implement the 4 methods discussed here for
|
||||
a simple Lennard-Jones fluid model. Also, see the "Howto
|
||||
viscosity"_Howto_viscosity.html doc page for an analogous discussion
|
||||
for viscosity.
|
||||
|
||||
The thermal conductivity tensor kappa is a measure of the propensity
|
||||
of a material to transmit heat energy in a diffusive manner as given
|
||||
by Fourier's law
|
||||
|
||||
J = -kappa grad(T)
|
||||
|
||||
where J is the heat flux in units of energy per area per time and
|
||||
grad(T) is the spatial gradient of temperature. The thermal
|
||||
conductivity thus has units of energy per distance per time per degree
|
||||
K and is often approximated as an isotropic quantity, i.e. as a
|
||||
scalar.
|
||||
|
||||
The first method is to setup two thermostatted regions at opposite
|
||||
ends of a simulation box, or one in the middle and one at the end of a
|
||||
periodic box. By holding the two regions at different temperatures
|
||||
with a "thermostatting fix"_Howto_thermostat.html, the energy added to
|
||||
the hot region should equal the energy subtracted from the cold region
|
||||
and be proportional to the heat flux moving between the regions. See
|
||||
the papers by "Ikeshoji and Hafskjold"_#howto-Ikeshoji and
|
||||
"Wirnsberger et al"_#howto-Wirnsberger for details of this idea. Note
|
||||
that thermostatting fixes such as "fix nvt"_fix_nh.html, "fix
|
||||
langevin"_fix_langevin.html, and "fix
|
||||
temp/rescale"_fix_temp_rescale.html store the cumulative energy they
|
||||
add/subtract.
|
||||
|
||||
Alternatively, as a second method, the "fix heat"_fix_heat.html or
|
||||
"fix ehex"_fix_ehex.html commands can be used in place of thermostats
|
||||
on each of two regions to add/subtract specified amounts of energy to
|
||||
both regions. In both cases, the resulting temperatures of the two
|
||||
regions can be monitored with the "compute temp/region" command and
|
||||
the temperature profile of the intermediate region can be monitored
|
||||
with the "fix ave/chunk"_fix_ave_chunk.html and "compute
|
||||
ke/atom"_compute_ke_atom.html commands.
|
||||
|
||||
The third method is to perform a reverse non-equilibrium MD simulation
|
||||
using the "fix thermal/conductivity"_fix_thermal_conductivity.html
|
||||
command which implements the rNEMD algorithm of Muller-Plathe.
|
||||
Kinetic energy is swapped between atoms in two different layers of the
|
||||
simulation box. This induces a temperature gradient between the two
|
||||
layers which can be monitored with the "fix
|
||||
ave/chunk"_fix_ave_chunk.html and "compute
|
||||
ke/atom"_compute_ke_atom.html commands. The fix tallies the
|
||||
cumulative energy transfer that it performs. See the "fix
|
||||
thermal/conductivity"_fix_thermal_conductivity.html command for
|
||||
details.
|
||||
|
||||
The fourth method is based on the Green-Kubo (GK) formula which
|
||||
relates the ensemble average of the auto-correlation of the heat flux
|
||||
to kappa. The heat flux can be calculated from the fluctuations of
|
||||
per-atom potential and kinetic energies and per-atom stress tensor in
|
||||
a steady-state equilibrated simulation. This is in contrast to the
|
||||
two preceding non-equilibrium methods, where energy flows continuously
|
||||
between hot and cold regions of the simulation box.
|
||||
|
||||
The "compute heat/flux"_compute_heat_flux.html command can calculate
|
||||
the needed heat flux and describes how to implement the Green_Kubo
|
||||
formalism using additional LAMMPS commands, such as the "fix
|
||||
ave/correlate"_fix_ave_correlate.html command to calculate the needed
|
||||
auto-correlation. See the doc page for the "compute
|
||||
heat/flux"_compute_heat_flux.html command for an example input script
|
||||
that calculates the thermal conductivity of solid Ar via the GK
|
||||
formalism.
|
||||
|
||||
:line
|
||||
|
||||
:link(howto-Ikeshoji)
|
||||
[(Ikeshoji)] Ikeshoji and Hafskjold, Molecular Physics, 81, 251-261
|
||||
(1994).
|
||||
|
||||
:link(howto-Wirnsberger)
|
||||
[(Wirnsberger)] Wirnsberger, Frenkel, and Dellago, J Chem Phys, 143, 124104
|
||||
(2015).
|
|
@ -1,235 +0,0 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Library interface to LAMMPS :h3
|
||||
|
||||
As described on the "Build basics"_Build_basics.html doc page, LAMMPS
|
||||
can be built as a library, so that it can be called by another code,
|
||||
used in a "coupled manner"_Howto_couple.html with other codes, or
|
||||
driven through a "Python interface"_Python_head.html.
|
||||
|
||||
All of these methodologies use a C-style interface to LAMMPS that is
|
||||
provided in the files src/library.cpp and src/library.h. The
|
||||
functions therein have a C-style argument list, but contain C++ code
|
||||
you could write yourself in a C++ application that was invoking LAMMPS
|
||||
directly. The C++ code in the functions illustrates how to invoke
|
||||
internal LAMMPS operations. Note that LAMMPS classes are defined
|
||||
within a LAMMPS namespace (LAMMPS_NS) if you use them from another C++
|
||||
application.
|
||||
|
||||
The examples/COUPLE and python/examples directories have example C++
|
||||
and C and Python codes which show how a driver code can link to LAMMPS
|
||||
as a library, run LAMMPS on a subset of processors, grab data from
|
||||
LAMMPS, change it, and put it back into LAMMPS.
|
||||
|
||||
Thread-safety :h4
|
||||
|
||||
LAMMPS has not initially been conceived as a thread-safe program, but
|
||||
over the years changes have been applied to replace operations that
|
||||
collide with creating multiple LAMMPS instances from multiple-threads
|
||||
of the same process with thread-safe alternatives. This primarily
|
||||
applies to the core LAMMPS code and less so on add-on packages, especially
|
||||
when those packages require additional code in the {lib} folder,
|
||||
interface LAMMPS to Fortran libraries, or the code uses static variables
|
||||
(like the USER-COLVARS package.
|
||||
|
||||
Another major issue to deal with is to correctly handle MPI. Creating
|
||||
a LAMMPS instance requires passing an MPI communicator, or it assumes
|
||||
the MPI_COMM_WORLD communicator, which spans all MPI processor ranks.
|
||||
When creating multiple LAMMPS object instances from different threads,
|
||||
this communicator has to be different for each thread or else collisions
|
||||
can happen, or it has to be guaranteed, that only one thread at a time
|
||||
is active. MPI communicators, however, are not a problem, if LAMMPS is
|
||||
compiled with the MPI STUBS library, which implies that there is no MPI
|
||||
communication and only 1 MPI rank.
|
||||
|
||||
Provided APIs :h4
|
||||
|
||||
The file src/library.cpp contains the following functions for creating
|
||||
and destroying an instance of LAMMPS and sending it commands to
|
||||
execute. See the documentation in the src/library.cpp file for
|
||||
details.
|
||||
|
||||
NOTE: You can write code for additional functions as needed to define
|
||||
how your code talks to LAMMPS and add them to src/library.cpp and
|
||||
src/library.h, as well as to the "Python interface"_Python_head.html.
|
||||
The added functions can access or change any internal LAMMPS data you
|
||||
wish.
|
||||
|
||||
void lammps_open(int, char **, MPI_Comm, void **)
|
||||
void lammps_open_no_mpi(int, char **, void **)
|
||||
void lammps_close(void *)
|
||||
int lammps_version(void *)
|
||||
void lammps_file(void *, char *)
|
||||
char *lammps_command(void *, char *)
|
||||
void lammps_commands_list(void *, int, char **)
|
||||
void lammps_commands_string(void *, char *)
|
||||
void lammps_free(void *) :pre
|
||||
|
||||
The lammps_open() function is used to initialize LAMMPS, passing in a
|
||||
list of strings as if they were "command-line
|
||||
arguments"_Run_options.html when LAMMPS is run in stand-alone mode
|
||||
from the command line, and a MPI communicator for LAMMPS to run under.
|
||||
It returns a ptr to the LAMMPS object that is created, and which is
|
||||
used in subsequent library calls. The lammps_open() function can be
|
||||
called multiple times, to create multiple instances of LAMMPS.
|
||||
|
||||
LAMMPS will run on the set of processors in the communicator. This
|
||||
means the calling code can run LAMMPS on all or a subset of
|
||||
processors. For example, a wrapper script might decide to alternate
|
||||
between LAMMPS and another code, allowing them both to run on all the
|
||||
processors. Or it might allocate half the processors to LAMMPS and
|
||||
half to the other code and run both codes simultaneously before
|
||||
syncing them up periodically. Or it might instantiate multiple
|
||||
instances of LAMMPS to perform different calculations.
|
||||
|
||||
The lammps_open_no_mpi() function is similar except that no MPI
|
||||
communicator is passed from the caller. Instead, MPI_COMM_WORLD is
|
||||
used to instantiate LAMMPS, and MPI is initialized if necessary.
|
||||
|
||||
The lammps_close() function is used to shut down an instance of LAMMPS
|
||||
and free all its memory.
|
||||
|
||||
The lammps_version() function can be used to determined the specific
|
||||
version of the underlying LAMMPS code. This is particularly useful
|
||||
when loading LAMMPS as a shared library via dlopen(). The code using
|
||||
the library interface can than use this information to adapt to
|
||||
changes to the LAMMPS command syntax between versions. The returned
|
||||
LAMMPS version code is an integer (e.g. 2 Sep 2015 results in
|
||||
20150902) that grows with every new LAMMPS version.
|
||||
|
||||
The lammps_file(), lammps_command(), lammps_commands_list(), and
|
||||
lammps_commands_string() functions are used to pass one or more
|
||||
commands to LAMMPS to execute, the same as if they were coming from an
|
||||
input script.
|
||||
|
||||
Via these functions, the calling code can read or generate a series of
|
||||
LAMMPS commands one or multiple at a time and pass it through the library
|
||||
interface to setup a problem and then run it in stages. The caller
|
||||
can interleave the command function calls with operations it performs,
|
||||
calls to extract information from or set information within LAMMPS, or
|
||||
calls to another code's library.
|
||||
|
||||
The lammps_file() function passes the filename of an input script.
|
||||
The lammps_command() function passes a single command as a string.
|
||||
The lammps_commands_list() function passes multiple commands in a
|
||||
char** list. In both lammps_command() and lammps_commands_list(),
|
||||
individual commands may or may not have a trailing newline. The
|
||||
lammps_commands_string() function passes multiple commands
|
||||
concatenated into one long string, separated by newline characters.
|
||||
In both lammps_commands_list() and lammps_commands_string(), a single
|
||||
command can be spread across multiple lines, if the last printable
|
||||
character of all but the last line is "&", the same as if the lines
|
||||
appeared in an input script.
|
||||
|
||||
The lammps_free() function is a clean-up function to free memory that
|
||||
the library allocated previously via other function calls. See
|
||||
comments in src/library.cpp file for which other functions need this
|
||||
clean-up.
|
||||
|
||||
The file src/library.cpp also contains these functions for extracting
|
||||
information from LAMMPS and setting value within LAMMPS. Again, see
|
||||
the documentation in the src/library.cpp file for details, including
|
||||
which quantities can be queried by name:
|
||||
|
||||
int lammps_extract_setting(void *, char *)
|
||||
void *lammps_extract_global(void *, char *)
|
||||
void lammps_extract_box(void *, double *, double *,
|
||||
double *, double *, double *, int *, int *)
|
||||
void *lammps_extract_atom(void *, char *)
|
||||
void *lammps_extract_compute(void *, char *, int, int)
|
||||
void *lammps_extract_fix(void *, char *, int, int, int, int)
|
||||
void *lammps_extract_variable(void *, char *, char *) :pre
|
||||
|
||||
The extract_setting() function returns info on the size
|
||||
of data types (e.g. 32-bit or 64-bit atom IDs) used
|
||||
by the LAMMPS executable (a compile-time choice).
|
||||
|
||||
The other extract functions return a pointer to various global or
|
||||
per-atom quantities stored in LAMMPS or to values calculated by a
|
||||
compute, fix, or variable. The pointer returned by the
|
||||
extract_global() function can be used as a permanent reference to a
|
||||
value which may change. For the extract_atom() method, see the
|
||||
extract() method in the src/atom.cpp file for a list of valid per-atom
|
||||
properties. New names could easily be added if the property you want
|
||||
is not listed. For the other extract functions, the underlying
|
||||
storage may be reallocated as LAMMPS runs, so you need to re-call the
|
||||
function to assure a current pointer or returned value(s).
|
||||
|
||||
double lammps_get_thermo(void *, char *)
|
||||
int lammps_get_natoms(void *) :pre
|
||||
|
||||
int lammps_set_variable(void *, char *, char *)
|
||||
void lammps_reset_box(void *, double *, double *, double, double, double) :pre
|
||||
|
||||
The lammps_get_thermo() function returns the current value of a thermo
|
||||
keyword as a double precision value.
|
||||
|
||||
The lammps_get_natoms() function returns the total number of atoms in
|
||||
the system and can be used by the caller to allocate memory for the
|
||||
lammps_gather_atoms() and lammps_scatter_atoms() functions.
|
||||
|
||||
The lammps_set_variable() function can set an existing string-style
|
||||
variable to a new string value, so that subsequent LAMMPS commands can
|
||||
access the variable.
|
||||
|
||||
The lammps_reset_box() function resets the size and shape of the
|
||||
simulation box, e.g. as part of restoring a previously extracted and
|
||||
saved state of a simulation.
|
||||
|
||||
void lammps_gather_atoms(void *, char *, int, int, void *)
|
||||
void lammps_gather_atoms_concat(void *, char *, int, int, void *)
|
||||
void lammps_gather_atoms_subset(void *, char *, int, int, int, int *, void *)
|
||||
void lammps_scatter_atoms(void *, char *, int, int, void *)
|
||||
void lammps_scatter_atoms_subset(void *, char *, int, int, int, int *, void *) :pre
|
||||
|
||||
The gather functions collect peratom info of the requested type (atom
|
||||
coords, atom types, forces, etc) from all processors, and returns the
|
||||
same vector of values to each calling processor. The scatter
|
||||
functions do the inverse. They distribute a vector of peratom values,
|
||||
passed by all calling processors, to individual atoms, which may be
|
||||
owned by different processors.
|
||||
|
||||
IMPORTANT NOTE: These functions are not compatible with the
|
||||
-DLAMMPS_BIGBIG setting when compiling LAMMPS. Dummy functions
|
||||
that result in an error message and abort will be substituted
|
||||
instead of resulting in random crashes and memory corruption.
|
||||
|
||||
The lammps_gather_atoms() function does this for all N atoms in the
|
||||
system, ordered by atom ID, from 1 to N. The
|
||||
lammps_gather_atoms_concat() function does it for all N atoms, but
|
||||
simply concatenates the subset of atoms owned by each processor. The
|
||||
resulting vector is not ordered by atom ID. Atom IDs can be requested
|
||||
by the same function if the caller needs to know the ordering. The
|
||||
lammps_gather_subset() function allows the caller to request values
|
||||
for only a subset of atoms (identified by ID).
|
||||
For all 3 gather function, per-atom image flags can be retrieved in 2 ways.
|
||||
If the count is specified as 1, they are returned
|
||||
in a packed format with all three image flags stored in a single integer.
|
||||
If the count is specified as 3, the values are unpacked into xyz flags
|
||||
by the library before returning them.
|
||||
|
||||
The lammps_scatter_atoms() function takes a list of values for all N
|
||||
atoms in the system, ordered by atom ID, from 1 to N, and assigns
|
||||
those values to each atom in the system. The
|
||||
lammps_scatter_atoms_subset() function takes a subset of IDs as an
|
||||
argument and only scatters those values to the owning atoms.
|
||||
|
||||
void lammps_create_atoms(void *, int, tagint *, int *, double *, double *,
|
||||
imageint *, int) :pre
|
||||
|
||||
The lammps_create_atoms() function takes a list of N atoms as input
|
||||
with atom types and coords (required), an optionally atom IDs and
|
||||
velocities and image flags. It uses the coords of each atom to assign
|
||||
it as a new atom to the processor that owns it. This function is
|
||||
useful to add atoms to a simulation or (in tandem with
|
||||
lammps_reset_box()) to restore a previously extracted and saved state
|
||||
of a simulation. Additional properties for the new atoms can then be
|
||||
assigned via the lammps_scatter_atoms() or lammps_extract_atom()
|
||||
functions.
|
|
@ -1,41 +0,0 @@
|
|||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Manifolds (surfaces) :h3
|
||||
|
||||
[Overview:]
|
||||
|
||||
This doc page is not about a LAMMPS input script command, but about
|
||||
manifolds, which are generalized surfaces, as defined and used by the
|
||||
USER-MANIFOLD package, to track particle motion on the manifolds. See
|
||||
the src/USER-MANIFOLD/README file for more details about the package
|
||||
and its commands.
|
||||
|
||||
Below is a list of currently supported manifolds by the USER-MANIFOLD
|
||||
package, their parameters and a short description of them. The
|
||||
parameters listed here are in the same order as they should be passed
|
||||
to the relevant fixes.
|
||||
|
||||
{manifold} @ {parameters} @ {equation} @ {description}
|
||||
cylinder @ R @ x^2 + y^2 - R^2 = 0 @ Cylinder along z-axis, axis going through (0,0,0)
|
||||
cylinder_dent @ R l a @ x^2 + y^2 - r(z)^2 = 0, r(x) = R if | z | > l, r(z) = R - a*(1 + cos(z/l))/2 otherwise @ A cylinder with a dent around z = 0
|
||||
dumbbell @ a A B c @ -( x^2 + y^2 ) + (a^2 - z^2/c^2) * ( 1 + (A*sin(B*z^2))^4) = 0 @ A dumbbell
|
||||
ellipsoid @ a b c @ (x/a)^2 + (y/b)^2 + (z/c)^2 = 0 @ An ellipsoid
|
||||
gaussian_bump @ A l rc1 rc2 @ if( x < rc1) -z + A * exp( -x^2 / (2 l^2) ); else if( x < rc2 ) -z + a + b*x + c*x^2 + d*x^3; else z @ A Gaussian bump at x = y = 0, smoothly tapered to a flat plane z = 0.
|
||||
plane @ a b c x0 y0 z0 @ a*(x-x0) + b*(y-y0) + c*(z-z0) = 0 @ A plane with normal (a,b,c) going through point (x0,y0,z0)
|
||||
plane_wiggle @ a w @ z - a*sin(w*x) = 0 @ A plane with a sinusoidal modulation on z along x.
|
||||
sphere @ R @ x^2 + y^2 + z^2 - R^2 = 0 @ A sphere of radius R
|
||||
supersphere @ R q @ | x |^q + | y |^q + | z |^q - R^q = 0 @ A supersphere of hyperradius R
|
||||
spine @ a, A, B, B2, c @ -(x^2 + y^2) + (a^2 - z^2/f(z)^2)*(1 + (A*sin(g(z)*z^2))^4), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise @ An approximation to a dendritic spine
|
||||
spine_two @ a, A, B, B2, c @ -(x^2 + y^2) + (a^2 - z^2/f(z)^2)*(1 + (A*sin(g(z)*z^2))^2), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise @ Another approximation to a dendritic spine
|
||||
thylakoid @ wB LB lB @ Various, see "(Paquay)"_#Paquay1 @ A model grana thylakoid consisting of two block-like compartments connected by a bridge of width wB, length LB and taper length lB
|
||||
torus @ R r @ (R - sqrt( x^2 + y^2 ) )^2 + z^2 - r^2 @ A torus with large radius R and small radius r, centered on (0,0,0) :tb(s=@)
|
||||
|
||||
:link(Paquay1)
|
||||
[(Paquay)] Paquay and Kusters, Biophys. J., 110, 6, (2016).
|
||||
preprint available at "arXiv:1411.3019"_http://arxiv.org/abs/1411.3019/.
|
|
@ -1,94 +0,0 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Run multiple simulations from one input script :h3
|
||||
|
||||
This can be done in several ways. See the documentation for
|
||||
individual commands for more details on how these examples work.
|
||||
|
||||
If "multiple simulations" means continue a previous simulation for
|
||||
more timesteps, then you simply use the "run"_run.html command
|
||||
multiple times. For example, this script
|
||||
|
||||
units lj
|
||||
atom_style atomic
|
||||
read_data data.lj
|
||||
run 10000
|
||||
run 10000
|
||||
run 10000
|
||||
run 10000
|
||||
run 10000 :pre
|
||||
|
||||
would run 5 successive simulations of the same system for a total of
|
||||
50,000 timesteps.
|
||||
|
||||
If you wish to run totally different simulations, one after the other,
|
||||
the "clear"_clear.html command can be used in between them to
|
||||
re-initialize LAMMPS. For example, this script
|
||||
|
||||
units lj
|
||||
atom_style atomic
|
||||
read_data data.lj
|
||||
run 10000
|
||||
clear
|
||||
units lj
|
||||
atom_style atomic
|
||||
read_data data.lj.new
|
||||
run 10000 :pre
|
||||
|
||||
would run 2 independent simulations, one after the other.
|
||||
|
||||
For large numbers of independent simulations, you can use
|
||||
"variables"_variable.html and the "next"_next.html and
|
||||
"jump"_jump.html commands to loop over the same input script
|
||||
multiple times with different settings. For example, this
|
||||
script, named in.polymer
|
||||
|
||||
variable d index run1 run2 run3 run4 run5 run6 run7 run8
|
||||
shell cd $d
|
||||
read_data data.polymer
|
||||
run 10000
|
||||
shell cd ..
|
||||
clear
|
||||
next d
|
||||
jump in.polymer :pre
|
||||
|
||||
would run 8 simulations in different directories, using a data.polymer
|
||||
file in each directory. The same concept could be used to run the
|
||||
same system at 8 different temperatures, using a temperature variable
|
||||
and storing the output in different log and dump files, for example
|
||||
|
||||
variable a loop 8
|
||||
variable t index 0.8 0.85 0.9 0.95 1.0 1.05 1.1 1.15
|
||||
log log.$a
|
||||
read data.polymer
|
||||
velocity all create $t 352839
|
||||
fix 1 all nvt $t $t 100.0
|
||||
dump 1 all atom 1000 dump.$a
|
||||
run 100000
|
||||
clear
|
||||
next t
|
||||
next a
|
||||
jump in.polymer :pre
|
||||
|
||||
All of the above examples work whether you are running on 1 or
|
||||
multiple processors, but assumed you are running LAMMPS on a single
|
||||
partition of processors. LAMMPS can be run on multiple partitions via
|
||||
the "-partition command-line switch"_Run_options.html.
|
||||
|
||||
In the last 2 examples, if LAMMPS were run on 3 partitions, the same
|
||||
scripts could be used if the "index" and "loop" variables were
|
||||
replaced with {universe}-style variables, as described in the
|
||||
"variable"_variable.html command. Also, the "next t" and "next a"
|
||||
commands would need to be replaced with a single "next a t" command.
|
||||
With these modifications, the 8 simulations of each script would run
|
||||
on the 3 partitions one after the other until all were finished.
|
||||
Initially, 3 simulations would be started simultaneously, one on each
|
||||
partition. When one finished, that partition would then start
|
||||
the 4th simulation, and so forth, until all 8 were completed.
|
|
@ -1,59 +0,0 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
NEMD simulations :h3
|
||||
|
||||
Non-equilibrium molecular dynamics or NEMD simulations are typically
|
||||
used to measure a fluid's rheological properties such as viscosity.
|
||||
In LAMMPS, such simulations can be performed by first setting up a
|
||||
non-orthogonal simulation box (see the preceding Howto section).
|
||||
|
||||
A shear strain can be applied to the simulation box at a desired
|
||||
strain rate by using the "fix deform"_fix_deform.html command. The
|
||||
"fix nvt/sllod"_fix_nvt_sllod.html command can be used to thermostat
|
||||
the sheared fluid and integrate the SLLOD equations of motion for the
|
||||
system. Fix nvt/sllod uses "compute
|
||||
temp/deform"_compute_temp_deform.html to compute a thermal temperature
|
||||
by subtracting out the streaming velocity of the shearing atoms. The
|
||||
velocity profile or other properties of the fluid can be monitored via
|
||||
the "fix ave/chunk"_fix_ave_chunk.html command.
|
||||
|
||||
NOTE: A recent (2017) book by "(Daivis and Todd)"_#Daivis-nemd
|
||||
discusses use of the SLLOD method and non-equilibrium MD (NEMD)
|
||||
thermostatting generally, for both simple and complex fluids,
|
||||
e.g. molecular systems. The latter can be tricky to do correctly.
|
||||
|
||||
As discussed in the previous section on non-orthogonal simulation
|
||||
boxes, the amount of tilt or skew that can be applied is limited by
|
||||
LAMMPS for computational efficiency to be 1/2 of the parallel box
|
||||
length. However, "fix deform"_fix_deform.html can continuously strain
|
||||
a box by an arbitrary amount. As discussed in the "fix
|
||||
deform"_fix_deform.html command, when the tilt value reaches a limit,
|
||||
the box is flipped to the opposite limit which is an equivalent tiling
|
||||
of periodic space. The strain rate can then continue to change as
|
||||
before. In a long NEMD simulation these box re-shaping events may
|
||||
occur many times.
|
||||
|
||||
In a NEMD simulation, the "remap" option of "fix
|
||||
deform"_fix_deform.html should be set to "remap v", since that is what
|
||||
"fix nvt/sllod"_fix_nvt_sllod.html assumes to generate a velocity
|
||||
profile consistent with the applied shear strain rate.
|
||||
|
||||
An alternative method for calculating viscosities is provided via the
|
||||
"fix viscosity"_fix_viscosity.html command.
|
||||
|
||||
NEMD simulations can also be used to measure transport properties of a fluid
|
||||
through a pore or channel. Simulations of steady-state flow can be performed
|
||||
using the "fix flow/gauss"_fix_flow_gauss.html command.
|
||||
|
||||
:line
|
||||
|
||||
:link(Daivis-nemd)
|
||||
[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dynamics (book),
|
||||
Cambridge University Press, https://doi.org/10.1017/9781139017848, (2017).
|
|
@ -1,307 +0,0 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Output from LAMMPS (thermo, dumps, computes, fixes, variables) :h3
|
||||
|
||||
There are four basic kinds of LAMMPS output:
|
||||
|
||||
"Thermodynamic output"_thermo_style.html, which is a list
|
||||
of quantities printed every few timesteps to the screen and logfile. :ulb,l
|
||||
|
||||
"Dump files"_dump.html, which contain snapshots of atoms and various
|
||||
per-atom values and are written at a specified frequency. :l
|
||||
|
||||
Certain fixes can output user-specified quantities to files: "fix
|
||||
ave/time"_fix_ave_time.html for time averaging, "fix
|
||||
ave/chunk"_fix_ave_chunk.html for spatial or other averaging, and "fix
|
||||
print"_fix_print.html for single-line output of
|
||||
"variables"_variable.html. Fix print can also output to the
|
||||
screen. :l
|
||||
|
||||
"Restart files"_restart.html. :l
|
||||
:ule
|
||||
|
||||
A simulation prints one set of thermodynamic output and (optionally)
|
||||
restart files. It can generate any number of dump files and fix
|
||||
output files, depending on what "dump"_dump.html and "fix"_fix.html
|
||||
commands you specify.
|
||||
|
||||
As discussed below, LAMMPS gives you a variety of ways to determine
|
||||
what quantities are computed and printed when the thermodynamics,
|
||||
dump, or fix commands listed above perform output. Throughout this
|
||||
discussion, note that users can also "add their own computes and fixes
|
||||
to LAMMPS"_Modify.html which can then generate values that can then be
|
||||
output with these commands.
|
||||
|
||||
The following sub-sections discuss different LAMMPS command related
|
||||
to output and the kind of data they operate on and produce:
|
||||
|
||||
"Global/per-atom/local data"_#global
|
||||
"Scalar/vector/array data"_#scalar
|
||||
"Thermodynamic output"_#thermo
|
||||
"Dump file output"_#dump
|
||||
"Fixes that write output files"_#fixoutput
|
||||
"Computes that process output quantities"_#computeoutput
|
||||
"Fixes that process output quantities"_#fixprocoutput
|
||||
"Computes that generate values to output"_#compute
|
||||
"Fixes that generate values to output"_#fix
|
||||
"Variables that generate values to output"_#variable
|
||||
"Summary table of output options and data flow between commands"_#table :ul
|
||||
|
||||
Global/per-atom/local data :h4,link(global)
|
||||
|
||||
Various output-related commands work with three different styles of
|
||||
data: global, per-atom, or local. A global datum is one or more
|
||||
system-wide values, e.g. the temperature of the system. A per-atom
|
||||
datum is one or more values per atom, e.g. the kinetic energy of each
|
||||
atom. Local datums are calculated by each processor based on the
|
||||
atoms it owns, but there may be zero or more per atom, e.g. a list of
|
||||
bond distances.
|
||||
|
||||
Scalar/vector/array data :h4,link(scalar)
|
||||
|
||||
Global, per-atom, and local datums can each come in three kinds: a
|
||||
single scalar value, a vector of values, or a 2d array of values. The
|
||||
doc page for a "compute" or "fix" or "variable" that generates data
|
||||
will specify both the style and kind of data it produces, e.g. a
|
||||
per-atom vector.
|
||||
|
||||
When a quantity is accessed, as in many of the output commands
|
||||
discussed below, it can be referenced via the following bracket
|
||||
notation, where ID in this case is the ID of a compute. The leading
|
||||
"c_" would be replaced by "f_" for a fix, or "v_" for a variable:
|
||||
|
||||
c_ID | entire scalar, vector, or array
|
||||
c_ID\[I\] | one element of vector, one column of array
|
||||
c_ID\[I\]\[J\] | one element of array :tb(s=|)
|
||||
|
||||
In other words, using one bracket reduces the dimension of the data
|
||||
once (vector -> scalar, array -> vector). Using two brackets reduces
|
||||
the dimension twice (array -> scalar). Thus a command that uses
|
||||
scalar values as input can typically also process elements of a vector
|
||||
or array.
|
||||
|
||||
Thermodynamic output :h4,link(thermo)
|
||||
|
||||
The frequency and format of thermodynamic output is set by the
|
||||
"thermo"_thermo.html, "thermo_style"_thermo_style.html, and
|
||||
"thermo_modify"_thermo_modify.html commands. The
|
||||
"thermo_style"_thermo_style.html command also specifies what values
|
||||
are calculated and written out. Pre-defined keywords can be specified
|
||||
(e.g. press, etotal, etc). Three additional kinds of keywords can
|
||||
also be specified (c_ID, f_ID, v_name), where a "compute"_compute.html
|
||||
or "fix"_fix.html or "variable"_variable.html provides the value to be
|
||||
output. In each case, the compute, fix, or variable must generate
|
||||
global values for input to the "thermo_style custom"_dump.html
|
||||
command.
|
||||
|
||||
Note that thermodynamic output values can be "extensive" or
|
||||
"intensive". The former scale with the number of atoms in the system
|
||||
(e.g. total energy), the latter do not (e.g. temperature). The
|
||||
setting for "thermo_modify norm"_thermo_modify.html determines whether
|
||||
extensive quantities are normalized or not. Computes and fixes
|
||||
produce either extensive or intensive values; see their individual doc
|
||||
pages for details. "Equal-style variables"_variable.html produce only
|
||||
intensive values; you can include a division by "natoms" in the
|
||||
formula if desired, to make an extensive calculation produce an
|
||||
intensive result.
|
||||
|
||||
Dump file output :h4,link(dump)
|
||||
|
||||
Dump file output is specified by the "dump"_dump.html and
|
||||
"dump_modify"_dump_modify.html commands. There are several
|
||||
pre-defined formats (dump atom, dump xtc, etc).
|
||||
|
||||
There is also a "dump custom"_dump.html format where the user
|
||||
specifies what values are output with each atom. Pre-defined atom
|
||||
attributes can be specified (id, x, fx, etc). Three additional kinds
|
||||
of keywords can also be specified (c_ID, f_ID, v_name), where a
|
||||
"compute"_compute.html or "fix"_fix.html or "variable"_variable.html
|
||||
provides the values to be output. In each case, the compute, fix, or
|
||||
variable must generate per-atom values for input to the "dump
|
||||
custom"_dump.html command.
|
||||
|
||||
There is also a "dump local"_dump.html format where the user specifies
|
||||
what local values to output. A pre-defined index keyword can be
|
||||
specified to enumerate the local values. Two additional kinds of
|
||||
keywords can also be specified (c_ID, f_ID), where a
|
||||
"compute"_compute.html or "fix"_fix.html or "variable"_variable.html
|
||||
provides the values to be output. In each case, the compute or fix
|
||||
must generate local values for input to the "dump local"_dump.html
|
||||
command.
|
||||
|
||||
Fixes that write output files :h4,link(fixoutput)
|
||||
|
||||
Several fixes take various quantities as input and can write output
|
||||
files: "fix ave/time"_fix_ave_time.html, "fix
|
||||
ave/chunk"_fix_ave_chunk.html, "fix ave/histo"_fix_ave_histo.html,
|
||||
"fix ave/correlate"_fix_ave_correlate.html, and "fix
|
||||
print"_fix_print.html.
|
||||
|
||||
The "fix ave/time"_fix_ave_time.html command enables direct output to
|
||||
a file and/or time-averaging of global scalars or vectors. The user
|
||||
specifies one or more quantities as input. These can be global
|
||||
"compute"_compute.html values, global "fix"_fix.html values, or
|
||||
"variables"_variable.html of any style except the atom style which
|
||||
produces per-atom values. Since a variable can refer to keywords used
|
||||
by the "thermo_style custom"_thermo_style.html command (like temp or
|
||||
press) and individual per-atom values, a wide variety of quantities
|
||||
can be time averaged and/or output in this way. If the inputs are one
|
||||
or more scalar values, then the fix generate a global scalar or vector
|
||||
of output. If the inputs are one or more vector values, then the fix
|
||||
generates a global vector or array of output. The time-averaged
|
||||
output of this fix can also be used as input to other output commands.
|
||||
|
||||
The "fix ave/chunk"_fix_ave_chunk.html command enables direct output
|
||||
to a file of chunk-averaged per-atom quantities like those output in
|
||||
dump files. Chunks can represent spatial bins or other collections of
|
||||
atoms, e.g. individual molecules. The per-atom quantities can be atom
|
||||
density (mass or number) or atom attributes such as position,
|
||||
velocity, force. They can also be per-atom quantities calculated by a
|
||||
"compute"_compute.html, by a "fix"_fix.html, or by an atom-style
|
||||
"variable"_variable.html. The chunk-averaged output of this fix can
|
||||
also be used as input to other output commands.
|
||||
|
||||
The "fix ave/histo"_fix_ave_histo.html command enables direct output
|
||||
to a file of histogrammed quantities, which can be global or per-atom
|
||||
or local quantities. The histogram output of this fix can also be
|
||||
used as input to other output commands.
|
||||
|
||||
The "fix ave/correlate"_fix_ave_correlate.html command enables direct
|
||||
output to a file of time-correlated quantities, which can be global
|
||||
values. The correlation matrix output of this fix can also be used as
|
||||
input to other output commands.
|
||||
|
||||
The "fix print"_fix_print.html command can generate a line of output
|
||||
written to the screen and log file or to a separate file, periodically
|
||||
during a running simulation. The line can contain one or more
|
||||
"variable"_variable.html values for any style variable except the
|
||||
vector or atom styles). As explained above, variables themselves can
|
||||
contain references to global values generated by "thermodynamic
|
||||
keywords"_thermo_style.html, "computes"_compute.html,
|
||||
"fixes"_fix.html, or other "variables"_variable.html, or to per-atom
|
||||
values for a specific atom. Thus the "fix print"_fix_print.html
|
||||
command is a means to output a wide variety of quantities separate
|
||||
from normal thermodynamic or dump file output.
|
||||
|
||||
Computes that process output quantities :h4,link(computeoutput)
|
||||
|
||||
The "compute reduce"_compute_reduce.html and "compute
|
||||
reduce/region"_compute_reduce.html commands take one or more per-atom
|
||||
or local vector quantities as inputs and "reduce" them (sum, min, max,
|
||||
ave) to scalar quantities. These are produced as output values which
|
||||
can be used as input to other output commands.
|
||||
|
||||
The "compute slice"_compute_slice.html command take one or more global
|
||||
vector or array quantities as inputs and extracts a subset of their
|
||||
values to create a new vector or array. These are produced as output
|
||||
values which can be used as input to other output commands.
|
||||
|
||||
The "compute property/atom"_compute_property_atom.html command takes a
|
||||
list of one or more pre-defined atom attributes (id, x, fx, etc) and
|
||||
stores the values in a per-atom vector or array. These are produced
|
||||
as output values which can be used as input to other output commands.
|
||||
The list of atom attributes is the same as for the "dump
|
||||
custom"_dump.html command.
|
||||
|
||||
The "compute property/local"_compute_property_local.html command takes
|
||||
a list of one or more pre-defined local attributes (bond info, angle
|
||||
info, etc) and stores the values in a local vector or array. These
|
||||
are produced as output values which can be used as input to other
|
||||
output commands.
|
||||
|
||||
Fixes that process output quantities :h4,link(fixprocoutput)
|
||||
|
||||
The "fix vector"_fix_vector.html command can create global vectors as
|
||||
output from global scalars as input, accumulating them one element at
|
||||
a time.
|
||||
|
||||
The "fix ave/atom"_fix_ave_atom.html command performs time-averaging
|
||||
of per-atom vectors. The per-atom quantities can be atom attributes
|
||||
such as position, velocity, force. They can also be per-atom
|
||||
quantities calculated by a "compute"_compute.html, by a
|
||||
"fix"_fix.html, or by an atom-style "variable"_variable.html. The
|
||||
time-averaged per-atom output of this fix can be used as input to
|
||||
other output commands.
|
||||
|
||||
The "fix store/state"_fix_store_state.html command can archive one or
|
||||
more per-atom attributes at a particular time, so that the old values
|
||||
can be used in a future calculation or output. The list of atom
|
||||
attributes is the same as for the "dump custom"_dump.html command,
|
||||
including per-atom quantities calculated by a "compute"_compute.html,
|
||||
by a "fix"_fix.html, or by an atom-style "variable"_variable.html.
|
||||
The output of this fix can be used as input to other output commands.
|
||||
|
||||
Computes that generate values to output :h4,link(compute)
|
||||
|
||||
Every "compute"_compute.html in LAMMPS produces either global or
|
||||
per-atom or local values. The values can be scalars or vectors or
|
||||
arrays of data. These values can be output using the other commands
|
||||
described in this section. The doc page for each compute command
|
||||
describes what it produces. Computes that produce per-atom or local
|
||||
values have the word "atom" or "local" in their style name. Computes
|
||||
without the word "atom" or "local" produce global values.
|
||||
|
||||
Fixes that generate values to output :h4,link(fix)
|
||||
|
||||
Some "fixes"_fix.html in LAMMPS produces either global or per-atom or
|
||||
local values which can be accessed by other commands. The values can
|
||||
be scalars or vectors or arrays of data. These values can be output
|
||||
using the other commands described in this section. The doc page for
|
||||
each fix command tells whether it produces any output quantities and
|
||||
describes them.
|
||||
|
||||
Variables that generate values to output :h4,link(variable)
|
||||
|
||||
"Variables"_variable.html defined in an input script can store one or
|
||||
more strings. But equal-style, vector-style, and atom-style or
|
||||
atomfile-style variables generate a global scalar value, global vector
|
||||
or values, or a per-atom vector, respectively, when accessed. The
|
||||
formulas used to define these variables can contain references to the
|
||||
thermodynamic keywords and to global and per-atom data generated by
|
||||
computes, fixes, and other variables. The values generated by
|
||||
variables can be used as input to and thus output by the other
|
||||
commands described in this section.
|
||||
|
||||
Summary table of output options and data flow between commands :h4,link(table)
|
||||
|
||||
This table summarizes the various commands that can be used for
|
||||
generating output from LAMMPS. Each command produces output data of
|
||||
some kind and/or writes data to a file. Most of the commands can take
|
||||
data from other commands as input. Thus you can link many of these
|
||||
commands together in pipeline form, where data produced by one command
|
||||
is used as input to another command and eventually written to the
|
||||
screen or to a file. Note that to hook two commands together the
|
||||
output and input data types must match, e.g. global/per-atom/local
|
||||
data and scalar/vector/array data.
|
||||
|
||||
Also note that, as described above, when a command takes a scalar as
|
||||
input, that could be an element of a vector or array. Likewise a
|
||||
vector input could be a column of an array.
|
||||
|
||||
Command: Input: Output:
|
||||
"thermo_style custom"_thermo_style.html: global scalars: screen, log file:
|
||||
"dump custom"_dump.html: per-atom vectors: dump file:
|
||||
"dump local"_dump.html: local vectors: dump file:
|
||||
"fix print"_fix_print.html: global scalar from variable: screen, file:
|
||||
"print"_print.html: global scalar from variable: screen:
|
||||
"computes"_compute.html: N/A: global/per-atom/local scalar/vector/array:
|
||||
"fixes"_fix.html: N/A: global/per-atom/local scalar/vector/array:
|
||||
"variables"_variable.html: global scalars and vectors, per-atom vectors: global scalar and vector, per-atom vector:
|
||||
"compute reduce"_compute_reduce.html: per-atom/local vectors: global scalar/vector:
|
||||
"compute slice"_compute_slice.html: global vectors/arrays: global vector/array:
|
||||
"compute property/atom"_compute_property_atom.html: per-atom vectors: per-atom vector/array:
|
||||
"compute property/local"_compute_property_local.html: local vectors: local vector/array:
|
||||
"fix vector"_fix_vector.html: global scalars: global vector:
|
||||
"fix ave/atom"_fix_ave_atom.html: per-atom vectors: per-atom vector/array:
|
||||
"fix ave/time"_fix_ave_time.html: global scalars/vectors: global scalar/vector/array, file:
|
||||
"fix ave/chunk"_fix_ave_chunk.html: per-atom vectors: global array, file:
|
||||
"fix ave/histo"_fix_ave_histo.html: global/per-atom/local scalars and vectors: global array, file:
|
||||
"fix ave/correlate"_fix_ave_correlate.html: global scalars: global array, file:
|
||||
"fix store/state"_fix_store_state.html: per-atom vectors: per-atom vector/array :tb(c=3,s=:)
|
|
@ -1,81 +0,0 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Polarizable models :h3
|
||||
|
||||
In polarizable force fields the charge distributions in molecules and
|
||||
materials respond to their electrostatic environments. Polarizable
|
||||
systems can be simulated in LAMMPS using three methods:
|
||||
|
||||
the fluctuating charge method, implemented in the "QEQ"_fix_qeq.html
|
||||
package, :ulb,l
|
||||
the adiabatic core-shell method, implemented in the
|
||||
"CORESHELL"_Howto_coreshell.html package, :l
|
||||
the thermalized Drude dipole method, implemented in the
|
||||
"USER-DRUDE"_Howto_drude.html package. :l,ule
|
||||
|
||||
The fluctuating charge method calculates instantaneous charges on
|
||||
interacting atoms based on the electronegativity equalization
|
||||
principle. It is implemented in the "fix qeq"_fix_qeq.html which is
|
||||
available in several variants. It is a relatively efficient technique
|
||||
since no additional particles are introduced. This method allows for
|
||||
charge transfer between molecules or atom groups. However, because the
|
||||
charges are located at the interaction sites, off-plane components of
|
||||
polarization cannot be represented in planar molecules or atom groups.
|
||||
|
||||
The two other methods share the same basic idea: polarizable atoms are
|
||||
split into one core atom and one satellite particle (called shell or
|
||||
Drude particle) attached to it by a harmonic spring. Both atoms bear
|
||||
a charge and they represent collectively an induced electric dipole.
|
||||
These techniques are computationally more expensive than the QEq
|
||||
method because of additional particles and bonds. These two
|
||||
charge-on-spring methods differ in certain features, with the
|
||||
core-shell model being normally used for ionic/crystalline materials,
|
||||
whereas the so-called Drude model is normally used for molecular
|
||||
systems and fluid states.
|
||||
|
||||
The core-shell model is applicable to crystalline materials where the
|
||||
high symmetry around each site leads to stable trajectories of the
|
||||
core-shell pairs. However, bonded atoms in molecules can be so close
|
||||
that a core would interact too strongly or even capture the Drude
|
||||
particle of a neighbor. The Drude dipole model is relatively more
|
||||
complex in order to remedy this and other issues. Specifically, the
|
||||
Drude model includes specific thermostatting of the core-Drude pairs
|
||||
and short-range damping of the induced dipoles.
|
||||
|
||||
The three polarization methods can be implemented through a
|
||||
self-consistent calculation of charges or induced dipoles at each
|
||||
timestep. In the fluctuating charge scheme this is done by the matrix
|
||||
inversion method in "fix qeq/point"_fix_qeq.html, but for core-shell
|
||||
or Drude-dipoles the relaxed-dipoles technique would require an slow
|
||||
iterative procedure. These self-consistent solutions yield accurate
|
||||
trajectories since the additional degrees of freedom representing
|
||||
polarization are massless. An alternative is to attribute a mass to
|
||||
the additional degrees of freedom and perform time integration using
|
||||
an extended Lagrangian technique. For the fluctuating charge scheme
|
||||
this is done by "fix qeq/dynamic"_fix_qeq.html, and for the
|
||||
charge-on-spring models by the methods outlined in the next two
|
||||
sections. The assignment of masses to the additional degrees of
|
||||
freedom can lead to unphysical trajectories if care is not exerted in
|
||||
choosing the parameters of the polarizable models and the simulation
|
||||
conditions.
|
||||
|
||||
In the core-shell model the vibration of the shells is kept faster
|
||||
than the ionic vibrations to mimic the fast response of the
|
||||
polarizable electrons. But in molecular systems thermalizing the
|
||||
core-Drude pairs at temperatures comparable to the rest of the
|
||||
simulation leads to several problems (kinetic energy transfer, too
|
||||
short a timestep, etc.) In order to avoid these problems the relative
|
||||
motion of the Drude particles with respect to their cores is kept
|
||||
"cold" so the vibration of the core-Drude pairs is very slow,
|
||||
approaching the self-consistent regime. In both models the
|
||||
temperature is regulated using the velocities of the center of mass of
|
||||
core+shell (or Drude) pairs, but in the Drude model the actual
|
||||
relative core-Drude particle motion is thermostatted separately as
|
||||
well.
|
|
@ -1,61 +0,0 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Multi-replica simulations :h3
|
||||
|
||||
Several commands in LAMMPS run multi-replica simulations, meaning
|
||||
that multiple instances (replicas) of your simulation are run
|
||||
simultaneously, with small amounts of data exchanged between replicas
|
||||
periodically.
|
||||
|
||||
These are the relevant commands:
|
||||
|
||||
"neb"_neb.html for nudged elastic band calculations
|
||||
"neb_spin"_neb_spin.html for magnetic nudged elastic band calculations
|
||||
"prd"_prd.html for parallel replica dynamics
|
||||
"tad"_tad.html for temperature accelerated dynamics
|
||||
"temper"_temper.html for parallel tempering
|
||||
"fix pimd"_fix_pimd.html for path-integral molecular dynamics (PIMD) :ul
|
||||
|
||||
NEB is a method for finding transition states and barrier energies.
|
||||
PRD and TAD are methods for performing accelerated dynamics to find
|
||||
and perform infrequent events. Parallel tempering or replica exchange
|
||||
runs different replicas at a series of temperature to facilitate
|
||||
rare-event sampling.
|
||||
|
||||
These commands can only be used if LAMMPS was built with the REPLICA
|
||||
package. See the "Build package"_Build_package.html doc page for more
|
||||
info.
|
||||
|
||||
PIMD runs different replicas whose individual particles are coupled
|
||||
together by springs to model a system or ring-polymers.
|
||||
|
||||
This commands can only be used if LAMMPS was built with the USER-MISC
|
||||
package. See the "Build package"_Build_package.html doc page for more
|
||||
info.
|
||||
|
||||
In all these cases, you must run with one or more processors per
|
||||
replica. The processors assigned to each replica are determined at
|
||||
run-time by using the "-partition command-line
|
||||
switch"_Run_options.html to launch LAMMPS on multiple partitions,
|
||||
which in this context are the same as replicas. E.g. these commands:
|
||||
|
||||
mpirun -np 16 lmp_linux -partition 8x2 -in in.temper
|
||||
mpirun -np 8 lmp_linux -partition 8x1 -in in.neb :pre
|
||||
|
||||
would each run 8 replicas, on either 16 or 8 processors. Note the use
|
||||
of the "-in command-line switch"_Run_options.html to specify the input
|
||||
script which is required when running in multi-replica mode.
|
||||
|
||||
Also note that with MPI installed on a machine (e.g. your desktop),
|
||||
you can run on more (virtual) processors than you have physical
|
||||
processors. Thus the above commands could be run on a
|
||||
single-processor (or few-processor) desktop so that you can run
|
||||
a multi-replica simulation on more replicas than you have
|
||||
physical processors.
|
|
@ -1,97 +0,0 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Restart a simulation :h3
|
||||
|
||||
There are 3 ways to continue a long LAMMPS simulation. Multiple
|
||||
"run"_run.html commands can be used in the same input script. Each
|
||||
run will continue from where the previous run left off. Or binary
|
||||
restart files can be saved to disk using the "restart"_restart.html
|
||||
command. At a later time, these binary files can be read via a
|
||||
"read_restart"_read_restart.html command in a new script. Or they can
|
||||
be converted to text data files using the "-r command-line
|
||||
switch"_Run_options.html and read by a "read_data"_read_data.html
|
||||
command in a new script.
|
||||
|
||||
Here we give examples of 2 scripts that read either a binary restart
|
||||
file or a converted data file and then issue a new run command to
|
||||
continue where the previous run left off. They illustrate what
|
||||
settings must be made in the new script. Details are discussed in the
|
||||
documentation for the "read_restart"_read_restart.html and
|
||||
"read_data"_read_data.html commands.
|
||||
|
||||
Look at the {in.chain} input script provided in the {bench} directory
|
||||
of the LAMMPS distribution to see the original script that these 2
|
||||
scripts are based on. If that script had the line
|
||||
|
||||
restart 50 tmp.restart :pre
|
||||
|
||||
added to it, it would produce 2 binary restart files (tmp.restart.50
|
||||
and tmp.restart.100) as it ran.
|
||||
|
||||
This script could be used to read the 1st restart file and re-run the
|
||||
last 50 timesteps:
|
||||
|
||||
read_restart tmp.restart.50 :pre
|
||||
|
||||
neighbor 0.4 bin
|
||||
neigh_modify every 1 delay 1 :pre
|
||||
|
||||
fix 1 all nve
|
||||
fix 2 all langevin 1.0 1.0 10.0 904297 :pre
|
||||
|
||||
timestep 0.012 :pre
|
||||
|
||||
run 50 :pre
|
||||
|
||||
Note that the following commands do not need to be repeated because
|
||||
their settings are included in the restart file: {units, atom_style,
|
||||
special_bonds, pair_style, bond_style}. However these commands do
|
||||
need to be used, since their settings are not in the restart file:
|
||||
{neighbor, fix, timestep}.
|
||||
|
||||
If you actually use this script to perform a restarted run, you will
|
||||
notice that the thermodynamic data match at step 50 (if you also put a
|
||||
"thermo 50" command in the original script), but do not match at step
|
||||
100. This is because the "fix langevin"_fix_langevin.html command
|
||||
uses random numbers in a way that does not allow for perfect restarts.
|
||||
|
||||
As an alternate approach, the restart file could be converted to a data
|
||||
file as follows:
|
||||
|
||||
lmp_g++ -r tmp.restart.50 tmp.restart.data :pre
|
||||
|
||||
Then, this script could be used to re-run the last 50 steps:
|
||||
|
||||
units lj
|
||||
atom_style bond
|
||||
pair_style lj/cut 1.12
|
||||
pair_modify shift yes
|
||||
bond_style fene
|
||||
special_bonds 0.0 1.0 1.0 :pre
|
||||
|
||||
read_data tmp.restart.data :pre
|
||||
|
||||
neighbor 0.4 bin
|
||||
neigh_modify every 1 delay 1 :pre
|
||||
|
||||
fix 1 all nve
|
||||
fix 2 all langevin 1.0 1.0 10.0 904297 :pre
|
||||
|
||||
timestep 0.012 :pre
|
||||
|
||||
reset_timestep 50
|
||||
run 50 :pre
|
||||
|
||||
Note that nearly all the settings specified in the original {in.chain}
|
||||
script must be repeated, except the {pair_coeff} and {bond_coeff}
|
||||
commands since the new data file lists the force field coefficients.
|
||||
Also, the "reset_timestep"_reset_timestep.html command is used to tell
|
||||
LAMMPS the current timestep. This value is stored in restart files,
|
||||
but not in data files.
|
|
@ -1,54 +0,0 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
SPC water model :h3
|
||||
|
||||
The SPC water model specifies a 3-site rigid water molecule with
|
||||
charges and Lennard-Jones parameters assigned to each of the 3 atoms.
|
||||
In LAMMPS the "fix shake"_fix_shake.html command can be used to hold
|
||||
the two O-H bonds and the H-O-H angle rigid. A bond style of
|
||||
{harmonic} and an angle style of {harmonic} or {charmm} should also be
|
||||
used.
|
||||
|
||||
These are the additional parameters (in real units) to set for O and H
|
||||
atoms and the water molecule to run a rigid SPC model.
|
||||
|
||||
O mass = 15.9994
|
||||
H mass = 1.008
|
||||
O charge = -0.820
|
||||
H charge = 0.410
|
||||
LJ epsilon of OO = 0.1553
|
||||
LJ sigma of OO = 3.166
|
||||
LJ epsilon, sigma of OH, HH = 0.0
|
||||
r0 of OH bond = 1.0
|
||||
theta of HOH angle = 109.47 :all(b),p
|
||||
|
||||
Note that as originally proposed, the SPC model was run with a 9
|
||||
Angstrom cutoff for both LJ and Coulombic terms. It can also be used
|
||||
with long-range Coulombics (Ewald or PPPM in LAMMPS), without changing
|
||||
any of the parameters above, though it becomes a different model in
|
||||
that mode of usage.
|
||||
|
||||
The SPC/E (extended) water model is the same, except
|
||||
the partial charge assignments change:
|
||||
|
||||
O charge = -0.8476
|
||||
H charge = 0.4238 :all(b),p
|
||||
|
||||
See the "(Berendsen)"_#howto-Berendsen reference for more details on both
|
||||
the SPC and SPC/E models.
|
||||
|
||||
Wikipedia also has a nice article on "water
|
||||
models"_http://en.wikipedia.org/wiki/Water_model.
|
||||
|
||||
:line
|
||||
|
||||
:link(howto-Berendsen)
|
||||
[(Berendsen)] Berendsen, Grigera, Straatsma, J Phys Chem, 91,
|
||||
6269-6271 (1987).
|
|
@ -1,243 +0,0 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Finite-size spherical and aspherical particles :h3
|
||||
|
||||
Typical MD models treat atoms or particles as point masses. Sometimes
|
||||
it is desirable to have a model with finite-size particles such as
|
||||
spheroids or ellipsoids or generalized aspherical bodies. The
|
||||
difference is that such particles have a moment of inertia, rotational
|
||||
energy, and angular momentum. Rotation is induced by torque coming
|
||||
from interactions with other particles.
|
||||
|
||||
LAMMPS has several options for running simulations with these kinds of
|
||||
particles. The following aspects are discussed in turn:
|
||||
|
||||
atom styles
|
||||
pair potentials
|
||||
time integration
|
||||
computes, thermodynamics, and dump output
|
||||
rigid bodies composed of finite-size particles :ul
|
||||
|
||||
Example input scripts for these kinds of models are in the body,
|
||||
colloid, dipole, ellipse, line, peri, pour, and tri directories of the
|
||||
"examples directory"_Examples.html in the LAMMPS distribution.
|
||||
|
||||
Atom styles :h4
|
||||
|
||||
There are several "atom styles"_atom_style.html that allow for
|
||||
definition of finite-size particles: sphere, dipole, ellipsoid, line,
|
||||
tri, peri, and body.
|
||||
|
||||
The sphere style defines particles that are spheroids and each
|
||||
particle can have a unique diameter and mass (or density). These
|
||||
particles store an angular velocity (omega) and can be acted upon by
|
||||
torque. The "set" command can be used to modify the diameter and mass
|
||||
of individual particles, after then are created.
|
||||
|
||||
The dipole style does not actually define finite-size particles, but
|
||||
is often used in conjunction with spherical particles, via a command
|
||||
like
|
||||
|
||||
atom_style hybrid sphere dipole :pre
|
||||
|
||||
This is because when dipoles interact with each other, they induce
|
||||
torques, and a particle must be finite-size (i.e. have a moment of
|
||||
inertia) in order to respond and rotate. See the "atom_style
|
||||
dipole"_atom_style.html command for details. The "set" command can be
|
||||
used to modify the orientation and length of the dipole moment of
|
||||
individual particles, after then are created.
|
||||
|
||||
The ellipsoid style defines particles that are ellipsoids and thus can
|
||||
be aspherical. Each particle has a shape, specified by 3 diameters,
|
||||
and mass (or density). These particles store an angular momentum and
|
||||
their orientation (quaternion), and can be acted upon by torque. They
|
||||
do not store an angular velocity (omega), which can be in a different
|
||||
direction than angular momentum, rather they compute it as needed.
|
||||
The "set" command can be used to modify the diameter, orientation, and
|
||||
mass of individual particles, after then are created. It also has a
|
||||
brief explanation of what quaternions are.
|
||||
|
||||
The line style defines line segment particles with two end points and
|
||||
a mass (or density). They can be used in 2d simulations, and they can
|
||||
be joined together to form rigid bodies which represent arbitrary
|
||||
polygons.
|
||||
|
||||
The tri style defines triangular particles with three corner points
|
||||
and a mass (or density). They can be used in 3d simulations, and they
|
||||
can be joined together to form rigid bodies which represent arbitrary
|
||||
particles with a triangulated surface.
|
||||
|
||||
The peri style is used with "Peridynamic models"_pair_peri.html and
|
||||
defines particles as having a volume, that is used internally in the
|
||||
"pair_style peri"_pair_peri.html potentials.
|
||||
|
||||
The body style allows for definition of particles which can represent
|
||||
complex entities, such as surface meshes of discrete points,
|
||||
collections of sub-particles, deformable objects, etc. The body style
|
||||
is discussed in more detail on the "Howto body"_Howto_body.html doc
|
||||
page.
|
||||
|
||||
Note that if one of these atom styles is used (or multiple styles via
|
||||
the "atom_style hybrid"_atom_style.html command), not all particles in
|
||||
the system are required to be finite-size or aspherical.
|
||||
|
||||
For example, in the ellipsoid style, if the 3 shape parameters are set
|
||||
to the same value, the particle will be a sphere rather than an
|
||||
ellipsoid. If the 3 shape parameters are all set to 0.0 or if the
|
||||
diameter is set to 0.0, it will be a point particle. In the line or
|
||||
tri style, if the lineflag or triflag is specified as 0, then it
|
||||
will be a point particle.
|
||||
|
||||
Some of the pair styles used to compute pairwise interactions between
|
||||
finite-size particles also compute the correct interaction with point
|
||||
particles as well, e.g. the interaction between a point particle and a
|
||||
finite-size particle or between two point particles. If necessary,
|
||||
"pair_style hybrid"_pair_hybrid.html can be used to insure the correct
|
||||
interactions are computed for the appropriate style of interactions.
|
||||
Likewise, using groups to partition particles (ellipsoids versus
|
||||
spheres versus point particles) will allow you to use the appropriate
|
||||
time integrators and temperature computations for each class of
|
||||
particles. See the doc pages for various commands for details.
|
||||
|
||||
Also note that for "2d simulations"_dimension.html, atom styles sphere
|
||||
and ellipsoid still use 3d particles, rather than as circular disks or
|
||||
ellipses. This means they have the same moment of inertia as the 3d
|
||||
object. When temperature is computed, the correct degrees of freedom
|
||||
are used for rotation in a 2d versus 3d system.
|
||||
|
||||
Pair potentials :h4
|
||||
|
||||
When a system with finite-size particles is defined, the particles
|
||||
will only rotate and experience torque if the force field computes
|
||||
such interactions. These are the various "pair
|
||||
styles"_pair_style.html that generate torque:
|
||||
|
||||
"pair_style gran/history"_pair_gran.html
|
||||
"pair_style gran/hertzian"_pair_gran.html
|
||||
"pair_style gran/no_history"_pair_gran.html
|
||||
"pair_style dipole/cut"_pair_dipole.html
|
||||
"pair_style gayberne"_pair_gayberne.html
|
||||
"pair_style resquared"_pair_resquared.html
|
||||
"pair_style brownian"_pair_brownian.html
|
||||
"pair_style lubricate"_pair_lubricate.html
|
||||
"pair_style line/lj"_pair_line_lj.html
|
||||
"pair_style tri/lj"_pair_tri_lj.html
|
||||
"pair_style body/nparticle"_pair_body_nparticle.html :ul
|
||||
|
||||
The granular pair styles are used with spherical particles. The
|
||||
dipole pair style is used with the dipole atom style, which could be
|
||||
applied to spherical or ellipsoidal particles. The GayBerne and
|
||||
REsquared potentials require ellipsoidal particles, though they will
|
||||
also work if the 3 shape parameters are the same (a sphere). The
|
||||
Brownian and lubrication potentials are used with spherical particles.
|
||||
The line, tri, and body potentials are used with line segment,
|
||||
triangular, and body particles respectively.
|
||||
|
||||
Time integration :h4
|
||||
|
||||
There are several fixes that perform time integration on finite-size
|
||||
spherical particles, meaning the integrators update the rotational
|
||||
orientation and angular velocity or angular momentum of the particles:
|
||||
|
||||
"fix nve/sphere"_fix_nve_sphere.html
|
||||
"fix nvt/sphere"_fix_nvt_sphere.html
|
||||
"fix npt/sphere"_fix_npt_sphere.html :ul
|
||||
|
||||
Likewise, there are 3 fixes that perform time integration on
|
||||
ellipsoidal particles:
|
||||
|
||||
"fix nve/asphere"_fix_nve_asphere.html
|
||||
"fix nvt/asphere"_fix_nvt_asphere.html
|
||||
"fix npt/asphere"_fix_npt_asphere.html :ul
|
||||
|
||||
The advantage of these fixes is that those which thermostat the
|
||||
particles include the rotational degrees of freedom in the temperature
|
||||
calculation and thermostatting. The "fix langevin"_fix_langevin.html
|
||||
command can also be used with its {omgea} or {angmom} options to
|
||||
thermostat the rotational degrees of freedom for spherical or
|
||||
ellipsoidal particles. Other thermostatting fixes only operate on the
|
||||
translational kinetic energy of finite-size particles.
|
||||
|
||||
These fixes perform constant NVE time integration on line segment,
|
||||
triangular, and body particles:
|
||||
|
||||
"fix nve/line"_fix_nve_line.html
|
||||
"fix nve/tri"_fix_nve_tri.html
|
||||
"fix nve/body"_fix_nve_body.html :ul
|
||||
|
||||
Note that for mixtures of point and finite-size particles, these
|
||||
integration fixes can only be used with "groups"_group.html which
|
||||
contain finite-size particles.
|
||||
|
||||
Computes, thermodynamics, and dump output :h4
|
||||
|
||||
There are several computes that calculate the temperature or
|
||||
rotational energy of spherical or ellipsoidal particles:
|
||||
|
||||
"compute temp/sphere"_compute_temp_sphere.html
|
||||
"compute temp/asphere"_compute_temp_asphere.html
|
||||
"compute erotate/sphere"_compute_erotate_sphere.html
|
||||
"compute erotate/asphere"_compute_erotate_asphere.html :ul
|
||||
|
||||
These include rotational degrees of freedom in their computation. If
|
||||
you wish the thermodynamic output of temperature or pressure to use
|
||||
one of these computes (e.g. for a system entirely composed of
|
||||
finite-size particles), then the compute can be defined and the
|
||||
"thermo_modify"_thermo_modify.html command used. Note that by default
|
||||
thermodynamic quantities will be calculated with a temperature that
|
||||
only includes translational degrees of freedom. See the
|
||||
"thermo_style"_thermo_style.html command for details.
|
||||
|
||||
These commands can be used to output various attributes of finite-size
|
||||
particles:
|
||||
|
||||
"dump custom"_dump.html
|
||||
"compute property/atom"_compute_property_atom.html
|
||||
"dump local"_dump.html
|
||||
"compute body/local"_compute_body_local.html :ul
|
||||
|
||||
Attributes include the dipole moment, the angular velocity, the
|
||||
angular momentum, the quaternion, the torque, the end-point and
|
||||
corner-point coordinates (for line and tri particles), and
|
||||
sub-particle attributes of body particles.
|
||||
|
||||
Rigid bodies composed of finite-size particles :h4
|
||||
|
||||
The "fix rigid"_fix_rigid.html command treats a collection of
|
||||
particles as a rigid body, computes its inertia tensor, sums the total
|
||||
force and torque on the rigid body each timestep due to forces on its
|
||||
constituent particles, and integrates the motion of the rigid body.
|
||||
|
||||
If any of the constituent particles of a rigid body are finite-size
|
||||
particles (spheres or ellipsoids or line segments or triangles), then
|
||||
their contribution to the inertia tensor of the body is different than
|
||||
if they were point particles. This means the rotational dynamics of
|
||||
the rigid body will be different. Thus a model of a dimer is
|
||||
different if the dimer consists of two point masses versus two
|
||||
spheroids, even if the two particles have the same mass. Finite-size
|
||||
particles that experience torque due to their interaction with other
|
||||
particles will also impart that torque to a rigid body they are part
|
||||
of.
|
||||
|
||||
See the "fix rigid" command for example of complex rigid-body models
|
||||
it is possible to define in LAMMPS.
|
||||
|
||||
Note that the "fix shake"_fix_shake.html command can also be used to
|
||||
treat 2, 3, or 4 particles as a rigid body, but it always assumes the
|
||||
particles are point masses.
|
||||
|
||||
Also note that body particles cannot be modeled with the "fix
|
||||
rigid"_fix_rigid.html command. Body particles are treated by LAMMPS
|
||||
as single particles, though they can store internal state, such as a
|
||||
list of sub-particles. Individual body particles are typically treated
|
||||
as rigid bodies, and their motion integrated with a command like "fix
|
||||
nve/body"_fix_nve_body.html. Interactions between pairs of body
|
||||
particles are computed via a command like "pair_style
|
||||
body/nparticle"_pair_body_nparticle.html.
|
|
@ -1,74 +0,0 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Magnetic spins :h3
|
||||
|
||||
The magnetic spin simulations are enabled by the SPIN package, whose
|
||||
implementation is detailed in "Tranchida"_#Tranchida.
|
||||
|
||||
The model represents the simulation of atomic magnetic spins coupled
|
||||
to lattice vibrations. The dynamics of those magnetic spins can be used
|
||||
to simulate a broad range a phenomena related to magneto-elasticity, or
|
||||
or to study the influence of defects on the magnetic properties of
|
||||
materials.
|
||||
|
||||
The magnetic spins are interacting with each others and with the
|
||||
lattice via pair interactions. Typically, the magnetic exchange
|
||||
interaction can be defined using the
|
||||
"pair/spin/exchange"_pair_spin_exchange.html command. This exchange
|
||||
applies a magnetic torque to a given spin, considering the orientation
|
||||
of its neighboring spins and their relative distances.
|
||||
It also applies a force on the atoms as a function of the spin
|
||||
orientations and their associated inter-atomic distances.
|
||||
|
||||
The command "fix precession/spin"_fix_precession_spin.html allows to
|
||||
apply a constant magnetic torque on all the spins in the system. This
|
||||
torque can be an external magnetic field (Zeeman interaction), or an
|
||||
uniaxial magnetic anisotropy.
|
||||
|
||||
A Langevin thermostat can be applied to those magnetic spins using
|
||||
"fix langevin/spin"_fix_langevin_spin.html. Typically, this thermostat
|
||||
can be coupled to another Langevin thermostat applied to the atoms
|
||||
using "fix langevin"_fix_langevin.html in order to simulate
|
||||
thermostatted spin-lattice systems.
|
||||
|
||||
The magnetic Gilbert damping can also be applied using "fix
|
||||
langevin/spin"_fix_langevin_spin.html. It allows to either dissipate
|
||||
the thermal energy of the Langevin thermostat, or to perform a
|
||||
relaxation of the magnetic configuration toward an equilibrium state.
|
||||
|
||||
The command "fix setforce/spin"_fix_setforce.html allows to set the
|
||||
components of the magnetic precession vectors (while erasing and
|
||||
replacing the previously computed magnetic precession vectors on
|
||||
the atom).
|
||||
This command can be used to freeze the magnetic moment of certain
|
||||
atoms in the simulation by zeroing their precession vector.
|
||||
|
||||
The command "fix nve/spin"_fix_nve_spin.html can be used to
|
||||
perform a symplectic integration of the combined dynamics of spins
|
||||
and atomic motions.
|
||||
|
||||
The minimization style "min/spin"_min_spin.html can be applied
|
||||
to the spins to perform a minimization of the spin configuration.
|
||||
|
||||
|
||||
All the computed magnetic properties can be output by two main
|
||||
commands. The first one is "compute spin"_compute_spin.html, that
|
||||
enables to evaluate magnetic averaged quantities, such as the total
|
||||
magnetization of the system along x, y, or z, the spin temperature, or
|
||||
the magnetic energy. The second command is "compute
|
||||
property/atom"_compute_property_atom.html. It enables to output all the
|
||||
per atom magnetic quantities. Typically, the orientation of a given
|
||||
magnetic spin, or the magnetic force acting on this spin.
|
||||
|
||||
:line
|
||||
|
||||
:link(Tranchida)
|
||||
[(Tranchida)] Tranchida, Plimpton, Thibaudeau and Thompson,
|
||||
Journal of Computational Physics, 372, 406-425, (2018).
|
|
@ -1,43 +0,0 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Calculate temperature :h3
|
||||
|
||||
Temperature is computed as kinetic energy divided by some number of
|
||||
degrees of freedom (and the Boltzmann constant). Since kinetic energy
|
||||
is a function of particle velocity, there is often a need to
|
||||
distinguish between a particle's advection velocity (due to some
|
||||
aggregate motion of particles) and its thermal velocity. The sum of
|
||||
the two is the particle's total velocity, but the latter is often what
|
||||
is wanted to compute a temperature.
|
||||
|
||||
LAMMPS has several options for computing temperatures, any of which
|
||||
can be used in "thermostatting"_Howto_thermostat.html and
|
||||
"barostatting"_Howto_barostat.html. These "compute
|
||||
commands"_compute.html calculate temperature:
|
||||
|
||||
"compute temp"_compute_temp.html
|
||||
"compute temp/sphere"_compute_temp_sphere.html
|
||||
"compute temp/asphere"_compute_temp_asphere.html
|
||||
"compute temp/com"_compute_temp_com.html
|
||||
"compute temp/deform"_compute_temp_deform.html
|
||||
"compute temp/partial"_compute_temp_partial.html
|
||||
"compute temp/profile"_compute_temp_profile.html
|
||||
"compute temp/ramp"_compute_temp_ramp.html
|
||||
"compute temp/region"_compute_temp_region.html :ul
|
||||
|
||||
All but the first 3 calculate velocity biases directly (e.g. advection
|
||||
velocities) that are removed when computing the thermal temperature.
|
||||
"Compute temp/sphere"_compute_temp_sphere.html and "compute
|
||||
temp/asphere"_compute_temp_asphere.html compute kinetic energy for
|
||||
finite-size particles that includes rotational degrees of freedom.
|
||||
They both allow for velocity biases indirectly, via an optional extra
|
||||
argument which is another temperature compute that subtracts a
|
||||
velocity bias. This allows the translational velocity of spherical or
|
||||
aspherical particles to be adjusted in prescribed ways.
|
|
@ -1,100 +0,0 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Thermostats :h3
|
||||
|
||||
Thermostatting means controlling the temperature of particles in an MD
|
||||
simulation. "Barostatting"_Howto_barostat.html means controlling the
|
||||
pressure. Since the pressure includes a kinetic component due to
|
||||
particle velocities, both these operations require calculation of the
|
||||
temperature. Typically a target temperature (T) and/or pressure (P)
|
||||
is specified by the user, and the thermostat or barostat attempts to
|
||||
equilibrate the system to the requested T and/or P.
|
||||
|
||||
Thermostatting in LAMMPS is performed by "fixes"_fix.html, or in one
|
||||
case by a pair style. Several thermostatting fixes are available:
|
||||
Nose-Hoover (nvt), Berendsen, CSVR, Langevin, and direct rescaling
|
||||
(temp/rescale). Dissipative particle dynamics (DPD) thermostatting
|
||||
can be invoked via the {dpd/tstat} pair style:
|
||||
|
||||
"fix nvt"_fix_nh.html
|
||||
"fix nvt/sphere"_fix_nvt_sphere.html
|
||||
"fix nvt/asphere"_fix_nvt_asphere.html
|
||||
"fix nvt/sllod"_fix_nvt_sllod.html
|
||||
"fix temp/berendsen"_fix_temp_berendsen.html
|
||||
"fix temp/csvr"_fix_temp_csvr.html
|
||||
"fix langevin"_fix_langevin.html
|
||||
"fix temp/rescale"_fix_temp_rescale.html
|
||||
"pair_style dpd/tstat"_pair_dpd.html :ul
|
||||
|
||||
"Fix nvt"_fix_nh.html only thermostats the translational velocity of
|
||||
particles. "Fix nvt/sllod"_fix_nvt_sllod.html also does this, except
|
||||
that it subtracts out a velocity bias due to a deforming box and
|
||||
integrates the SLLOD equations of motion. See the "Howto
|
||||
nemd"_Howto_nemd.html doc page for further details. "Fix
|
||||
nvt/sphere"_fix_nvt_sphere.html and "fix
|
||||
nvt/asphere"_fix_nvt_asphere.html thermostat not only translation
|
||||
velocities but also rotational velocities for spherical and aspherical
|
||||
particles.
|
||||
|
||||
NOTE: A recent (2017) book by "(Daivis and Todd)"_#Daivis-thermostat
|
||||
discusses use of the SLLOD method and non-equilibrium MD (NEMD)
|
||||
thermostatting generally, for both simple and complex fluids,
|
||||
e.g. molecular systems. The latter can be tricky to do correctly.
|
||||
|
||||
DPD thermostatting alters pairwise interactions in a manner analogous
|
||||
to the per-particle thermostatting of "fix
|
||||
langevin"_fix_langevin.html.
|
||||
|
||||
Any of the thermostatting fixes can use "temperature
|
||||
computes"_Howto_thermostat.html that remove bias which has two
|
||||
effects. First, the current calculated temperature, which is compared
|
||||
to the requested target temperature, is calculated with the velocity
|
||||
bias removed. Second, the thermostat adjusts only the thermal
|
||||
temperature component of the particle's velocities, which are the
|
||||
velocities with the bias removed. The removed bias is then added back
|
||||
to the adjusted velocities. See the doc pages for the individual
|
||||
fixes and for the "fix_modify"_fix_modify.html command for
|
||||
instructions on how to assign a temperature compute to a
|
||||
thermostatting fix. For example, you can apply a thermostat to only
|
||||
the x and z components of velocity by using it in conjunction with
|
||||
"compute temp/partial"_compute_temp_partial.html. Of you could
|
||||
thermostat only the thermal temperature of a streaming flow of
|
||||
particles without affecting the streaming velocity, by using "compute
|
||||
temp/profile"_compute_temp_profile.html.
|
||||
|
||||
NOTE: Only the nvt fixes perform time integration, meaning they update
|
||||
the velocities and positions of particles due to forces and velocities
|
||||
respectively. The other thermostat fixes only adjust velocities; they
|
||||
do NOT perform time integration updates. Thus they should be used in
|
||||
conjunction with a constant NVE integration fix such as these:
|
||||
|
||||
"fix nve"_fix_nve.html
|
||||
"fix nve/sphere"_fix_nve_sphere.html
|
||||
"fix nve/asphere"_fix_nve_asphere.html :ul
|
||||
|
||||
Thermodynamic output, which can be setup via the
|
||||
"thermo_style"_thermo_style.html command, often includes temperature
|
||||
values. As explained on the doc page for the
|
||||
"thermo_style"_thermo_style.html command, the default temperature is
|
||||
setup by the thermo command itself. It is NOT the temperature
|
||||
associated with any thermostatting fix you have defined or with any
|
||||
compute you have defined that calculates a temperature. The doc pages
|
||||
for the thermostatting fixes explain the ID of the temperature compute
|
||||
they create. Thus if you want to view these temperatures, you need to
|
||||
specify them explicitly via the "thermo_style
|
||||
custom"_thermo_style.html command. Or you can use the
|
||||
"thermo_modify"_thermo_modify.html command to re-define what
|
||||
temperature compute is used for default thermodynamic output.
|
||||
|
||||
:line
|
||||
|
||||
:link(Daivis-thermostat)
|
||||
[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dynamics (book),
|
||||
Cambridge University Press, https://doi.org/10.1017/9781139017848, (2017).
|
|
@ -1,73 +0,0 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
TIP3P water model :h3
|
||||
|
||||
The TIP3P water model as implemented in CHARMM
|
||||
"(MacKerell)"_#howto-tip3p specifies a 3-site rigid water molecule with
|
||||
charges and Lennard-Jones parameters assigned to each of the 3 atoms.
|
||||
In LAMMPS the "fix shake"_fix_shake.html command can be used to hold
|
||||
the two O-H bonds and the H-O-H angle rigid. A bond style of
|
||||
{harmonic} and an angle style of {harmonic} or {charmm} should also be
|
||||
used.
|
||||
|
||||
These are the additional parameters (in real units) to set for O and H
|
||||
atoms and the water molecule to run a rigid TIP3P-CHARMM model with a
|
||||
cutoff. The K values can be used if a flexible TIP3P model (without
|
||||
fix shake) is desired. If the LJ epsilon and sigma for HH and OH are
|
||||
set to 0.0, it corresponds to the original 1983 TIP3P model
|
||||
"(Jorgensen)"_#Jorgensen1.
|
||||
|
||||
O mass = 15.9994
|
||||
H mass = 1.008
|
||||
O charge = -0.834
|
||||
H charge = 0.417
|
||||
LJ epsilon of OO = 0.1521
|
||||
LJ sigma of OO = 3.1507
|
||||
LJ epsilon of HH = 0.0460
|
||||
LJ sigma of HH = 0.4000
|
||||
LJ epsilon of OH = 0.0836
|
||||
LJ sigma of OH = 1.7753
|
||||
K of OH bond = 450
|
||||
r0 of OH bond = 0.9572
|
||||
K of HOH angle = 55
|
||||
theta of HOH angle = 104.52 :all(b),p
|
||||
|
||||
These are the parameters to use for TIP3P with a long-range Coulombic
|
||||
solver (e.g. Ewald or PPPM in LAMMPS), see "(Price)"_#Price1 for
|
||||
details:
|
||||
|
||||
O mass = 15.9994
|
||||
H mass = 1.008
|
||||
O charge = -0.830
|
||||
H charge = 0.415
|
||||
LJ epsilon of OO = 0.102
|
||||
LJ sigma of OO = 3.188
|
||||
LJ epsilon, sigma of OH, HH = 0.0
|
||||
K of OH bond = 450
|
||||
r0 of OH bond = 0.9572
|
||||
K of HOH angle = 55
|
||||
theta of HOH angle = 104.52 :all(b),p
|
||||
|
||||
Wikipedia also has a nice article on "water
|
||||
models"_http://en.wikipedia.org/wiki/Water_model.
|
||||
|
||||
:line
|
||||
|
||||
:link(howto-tip3p)
|
||||
[(MacKerell)] MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field,
|
||||
Fischer, Gao, Guo, Ha, et al, J Phys Chem, 102, 3586 (1998).
|
||||
|
||||
:link(Jorgensen1)
|
||||
[(Jorgensen)] Jorgensen, Chandrasekhar, Madura, Impey, Klein, J Chem
|
||||
Phys, 79, 926 (1983).
|
||||
|
||||
:link(Price1)
|
||||
[(Price)] Price and Brooks, J Chem Phys, 121, 10096 (2004).
|
||||
|
|
@ -1,112 +0,0 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
TIP4P water model :h3
|
||||
|
||||
The four-point TIP4P rigid water model extends the traditional
|
||||
three-point TIP3P model by adding an additional site, usually
|
||||
massless, where the charge associated with the oxygen atom is placed.
|
||||
This site M is located at a fixed distance away from the oxygen along
|
||||
the bisector of the HOH bond angle. A bond style of {harmonic} and an
|
||||
angle style of {harmonic} or {charmm} should also be used.
|
||||
|
||||
A TIP4P model is run with LAMMPS using either this command
|
||||
for a cutoff model:
|
||||
|
||||
"pair_style lj/cut/tip4p/cut"_pair_lj.html
|
||||
|
||||
or these two commands for a long-range model:
|
||||
|
||||
"pair_style lj/cut/tip4p/long"_pair_lj.html
|
||||
"kspace_style pppm/tip4p"_kspace_style.html :ul
|
||||
|
||||
For both models, the bond lengths and bond angles should be held fixed
|
||||
using the "fix shake"_fix_shake.html command.
|
||||
|
||||
These are the additional parameters (in real units) to set for O and H
|
||||
atoms and the water molecule to run a rigid TIP4P model with a cutoff
|
||||
"(Jorgensen)"_#Jorgensen5. Note that the OM distance is specified in
|
||||
the "pair_style"_pair_style.html command, not as part of the pair
|
||||
coefficients.
|
||||
|
||||
O mass = 15.9994
|
||||
H mass = 1.008
|
||||
O charge = -1.040
|
||||
H charge = 0.520
|
||||
r0 of OH bond = 0.9572
|
||||
theta of HOH angle = 104.52
|
||||
OM distance = 0.15
|
||||
LJ epsilon of O-O = 0.1550
|
||||
LJ sigma of O-O = 3.1536
|
||||
LJ epsilon, sigma of OH, HH = 0.0
|
||||
Coulombic cutoff = 8.5 :all(b),p
|
||||
|
||||
For the TIP4/Ice model (J Chem Phys, 122, 234511 (2005);
|
||||
http://dx.doi.org/10.1063/1.1931662) these values can be used:
|
||||
|
||||
O mass = 15.9994
|
||||
H mass = 1.008
|
||||
O charge = -1.1794
|
||||
H charge = 0.5897
|
||||
r0 of OH bond = 0.9572
|
||||
theta of HOH angle = 104.52
|
||||
OM distance = 0.1577
|
||||
LJ epsilon of O-O = 0.21084
|
||||
LJ sigma of O-O = 3.1668
|
||||
LJ epsilon, sigma of OH, HH = 0.0
|
||||
Coulombic cutoff = 8.5 :all(b),p
|
||||
|
||||
For the TIP4P/2005 model (J Chem Phys, 123, 234505 (2005);
|
||||
http://dx.doi.org/10.1063/1.2121687), these values can be used:
|
||||
|
||||
O mass = 15.9994
|
||||
H mass = 1.008
|
||||
O charge = -1.1128
|
||||
H charge = 0.5564
|
||||
r0 of OH bond = 0.9572
|
||||
theta of HOH angle = 104.52
|
||||
OM distance = 0.1546
|
||||
LJ epsilon of O-O = 0.1852
|
||||
LJ sigma of O-O = 3.1589
|
||||
LJ epsilon, sigma of OH, HH = 0.0
|
||||
Coulombic cutoff = 8.5 :all(b),p
|
||||
|
||||
These are the parameters to use for TIP4P with a long-range Coulombic
|
||||
solver (e.g. Ewald or PPPM in LAMMPS):
|
||||
|
||||
O mass = 15.9994
|
||||
H mass = 1.008
|
||||
O charge = -1.0484
|
||||
H charge = 0.5242
|
||||
r0 of OH bond = 0.9572
|
||||
theta of HOH angle = 104.52
|
||||
OM distance = 0.1250
|
||||
LJ epsilon of O-O = 0.16275
|
||||
LJ sigma of O-O = 3.16435
|
||||
LJ epsilon, sigma of OH, HH = 0.0 :all(b),p
|
||||
|
||||
Note that the when using the TIP4P pair style, the neighbor list
|
||||
cutoff for Coulomb interactions is effectively extended by a distance
|
||||
2 * (OM distance), to account for the offset distance of the
|
||||
fictitious charges on O atoms in water molecules. Thus it is
|
||||
typically best in an efficiency sense to use a LJ cutoff >= Coulomb
|
||||
cutoff + 2*(OM distance), to shrink the size of the neighbor list.
|
||||
This leads to slightly larger cost for the long-range calculation, so
|
||||
you can test the trade-off for your model. The OM distance and the LJ
|
||||
and Coulombic cutoffs are set in the "pair_style
|
||||
lj/cut/tip4p/long"_pair_lj.html command.
|
||||
|
||||
Wikipedia also has a nice article on "water
|
||||
models"_http://en.wikipedia.org/wiki/Water_model.
|
||||
|
||||
:line
|
||||
|
||||
:link(Jorgensen5)
|
||||
[(Jorgensen)] Jorgensen, Chandrasekhar, Madura, Impey, Klein, J Chem
|
||||
Phys, 79, 926 (1983).
|
|
@ -1,213 +0,0 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
Triclinic (non-orthogonal) simulation boxes :h3
|
||||
|
||||
By default, LAMMPS uses an orthogonal simulation box to encompass the
|
||||
particles. The "boundary"_boundary.html command sets the boundary
|
||||
conditions of the box (periodic, non-periodic, etc). The orthogonal
|
||||
box has its "origin" at (xlo,ylo,zlo) and is defined by 3 edge vectors
|
||||
starting from the origin given by [a] = (xhi-xlo,0,0); [b] =
|
||||
(0,yhi-ylo,0); [c] = (0,0,zhi-zlo). The 6 parameters
|
||||
(xlo,xhi,ylo,yhi,zlo,zhi) are defined at the time the simulation box
|
||||
is created, e.g. by the "create_box"_create_box.html or
|
||||
"read_data"_read_data.html or "read_restart"_read_restart.html
|
||||
commands. Additionally, LAMMPS defines box size parameters lx,ly,lz
|
||||
where lx = xhi-xlo, and similarly in the y and z dimensions. The 6
|
||||
parameters, as well as lx,ly,lz, can be output via the "thermo_style
|
||||
custom"_thermo_style.html command.
|
||||
|
||||
LAMMPS also allows simulations to be performed in triclinic
|
||||
(non-orthogonal) simulation boxes shaped as a parallelepiped with
|
||||
triclinic symmetry. The parallelepiped has its "origin" at
|
||||
(xlo,ylo,zlo) and is defined by 3 edge vectors starting from the
|
||||
origin given by [a] = (xhi-xlo,0,0); [b] = (xy,yhi-ylo,0); [c] =
|
||||
(xz,yz,zhi-zlo). {xy,xz,yz} can be 0.0 or positive or negative values
|
||||
and are called "tilt factors" because they are the amount of
|
||||
displacement applied to faces of an originally orthogonal box to
|
||||
transform it into the parallelepiped. In LAMMPS the triclinic
|
||||
simulation box edge vectors [a], [b], and [c] cannot be arbitrary
|
||||
vectors. As indicated, [a] must lie on the positive x axis. [b] must
|
||||
lie in the xy plane, with strictly positive y component. [c] may have
|
||||
any orientation with strictly positive z component. The requirement
|
||||
that [a], [b], and [c] have strictly positive x, y, and z components,
|
||||
respectively, ensures that [a], [b], and [c] form a complete
|
||||
right-handed basis. These restrictions impose no loss of generality,
|
||||
since it is possible to rotate/invert any set of 3 crystal basis
|
||||
vectors so that they conform to the restrictions.
|
||||
|
||||
For example, assume that the 3 vectors [A],[B],[C] are the edge
|
||||
vectors of a general parallelepiped, where there is no restriction on
|
||||
[A],[B],[C] other than they form a complete right-handed basis i.e.
|
||||
[A] x [B] . [C] > 0. The equivalent LAMMPS [a],[b],[c] are a linear
|
||||
rotation of [A], [B], and [C] and can be computed as follows:
|
||||
|
||||
:c,image(Eqs/transform.jpg)
|
||||
|
||||
where A = | [A] | indicates the scalar length of [A]. The hat symbol (^)
|
||||
indicates the corresponding unit vector. {beta} and {gamma} are angles
|
||||
between the vectors described below. Note that by construction,
|
||||
[a], [b], and [c] have strictly positive x, y, and z components, respectively.
|
||||
If it should happen that
|
||||
[A], [B], and [C] form a left-handed basis, then the above equations
|
||||
are not valid for [c]. In this case, it is necessary
|
||||
to first apply an inversion. This can be achieved
|
||||
by interchanging two basis vectors or by changing the sign of one of them.
|
||||
|
||||
For consistency, the same rotation/inversion applied to the basis vectors
|
||||
must also be applied to atom positions, velocities,
|
||||
and any other vector quantities.
|
||||
This can be conveniently achieved by first converting to
|
||||
fractional coordinates in the
|
||||
old basis and then converting to distance coordinates in the new basis.
|
||||
The transformation is given by the following equation:
|
||||
|
||||
:c,image(Eqs/rotate.jpg)
|
||||
|
||||
where {V} is the volume of the box, [X] is the original vector quantity and
|
||||
[x] is the vector in the LAMMPS basis.
|
||||
|
||||
There is no requirement that a triclinic box be periodic in any
|
||||
dimension, though it typically should be in at least the 2nd dimension
|
||||
of the tilt (y in xy) if you want to enforce a shift in periodic
|
||||
boundary conditions across that boundary. Some commands that work
|
||||
with triclinic boxes, e.g. the "fix deform"_fix_deform.html and "fix
|
||||
npt"_fix_nh.html commands, require periodicity or non-shrink-wrap
|
||||
boundary conditions in specific dimensions. See the command doc pages
|
||||
for details.
|
||||
|
||||
The 9 parameters (xlo,xhi,ylo,yhi,zlo,zhi,xy,xz,yz) are defined at the
|
||||
time the simulation box is created. This happens in one of 3 ways.
|
||||
If the "create_box"_create_box.html command is used with a region of
|
||||
style {prism}, then a triclinic box is setup. See the
|
||||
"region"_region.html command for details. If the
|
||||
"read_data"_read_data.html command is used to define the simulation
|
||||
box, and the header of the data file contains a line with the "xy xz
|
||||
yz" keyword, then a triclinic box is setup. See the
|
||||
"read_data"_read_data.html command for details. Finally, if the
|
||||
"read_restart"_read_restart.html command reads a restart file which
|
||||
was written from a simulation using a triclinic box, then a triclinic
|
||||
box will be setup for the restarted simulation.
|
||||
|
||||
Note that you can define a triclinic box with all 3 tilt factors =
|
||||
0.0, so that it is initially orthogonal. This is necessary if the box
|
||||
will become non-orthogonal, e.g. due to the "fix npt"_fix_nh.html or
|
||||
"fix deform"_fix_deform.html commands. Alternatively, you can use the
|
||||
"change_box"_change_box.html command to convert a simulation box from
|
||||
orthogonal to triclinic and vice versa.
|
||||
|
||||
As with orthogonal boxes, LAMMPS defines triclinic box size parameters
|
||||
lx,ly,lz where lx = xhi-xlo, and similarly in the y and z dimensions.
|
||||
The 9 parameters, as well as lx,ly,lz, can be output via the
|
||||
"thermo_style custom"_thermo_style.html command.
|
||||
|
||||
To avoid extremely tilted boxes (which would be computationally
|
||||
inefficient), LAMMPS normally requires that no tilt factor can skew
|
||||
the box more than half the distance of the parallel box length, which
|
||||
is the 1st dimension in the tilt factor (x for xz). This is required
|
||||
both when the simulation box is created, e.g. via the
|
||||
"create_box"_create_box.html or "read_data"_read_data.html commands,
|
||||
as well as when the box shape changes dynamically during a simulation,
|
||||
e.g. via the "fix deform"_fix_deform.html or "fix npt"_fix_nh.html
|
||||
commands.
|
||||
|
||||
For example, if xlo = 2 and xhi = 12, then the x box length is 10 and
|
||||
the xy tilt factor must be between -5 and 5. Similarly, both xz and
|
||||
yz must be between -(xhi-xlo)/2 and +(yhi-ylo)/2. Note that this is
|
||||
not a limitation, since if the maximum tilt factor is 5 (as in this
|
||||
example), then configurations with tilt = ..., -15, -5, 5, 15, 25,
|
||||
... are geometrically all equivalent. If the box tilt exceeds this
|
||||
limit during a dynamics run (e.g. via the "fix deform"_fix_deform.html
|
||||
command), then the box is "flipped" to an equivalent shape with a tilt
|
||||
factor within the bounds, so the run can continue. See the "fix
|
||||
deform"_fix_deform.html doc page for further details.
|
||||
|
||||
One exception to this rule is if the 1st dimension in the tilt
|
||||
factor (x for xy) is non-periodic. In that case, the limits on the
|
||||
tilt factor are not enforced, since flipping the box in that dimension
|
||||
does not change the atom positions due to non-periodicity. In this
|
||||
mode, if you tilt the system to extreme angles, the simulation will
|
||||
simply become inefficient, due to the highly skewed simulation box.
|
||||
|
||||
The limitation on not creating a simulation box with a tilt factor
|
||||
skewing the box more than half the distance of the parallel box length
|
||||
can be overridden via the "box"_box.html command. Setting the {tilt}
|
||||
keyword to {large} allows any tilt factors to be specified.
|
||||
|
||||
Box flips that may occur using the "fix deform"_fix_deform.html or
|
||||
"fix npt"_fix_nh.html commands can be turned off using the {flip no}
|
||||
option with either of the commands.
|
||||
|
||||
Note that if a simulation box has a large tilt factor, LAMMPS will run
|
||||
less efficiently, due to the large volume of communication needed to
|
||||
acquire ghost atoms around a processor's irregular-shaped sub-domain.
|
||||
For extreme values of tilt, LAMMPS may also lose atoms and generate an
|
||||
error.
|
||||
|
||||
Triclinic crystal structures are often defined using three lattice
|
||||
constants {a}, {b}, and {c}, and three angles {alpha}, {beta} and
|
||||
{gamma}. Note that in this nomenclature, the a, b, and c lattice
|
||||
constants are the scalar lengths of the edge vectors [a], [b], and [c]
|
||||
defined above. The relationship between these 6 quantities
|
||||
(a,b,c,alpha,beta,gamma) and the LAMMPS box sizes (lx,ly,lz) =
|
||||
(xhi-xlo,yhi-ylo,zhi-zlo) and tilt factors (xy,xz,yz) is as follows:
|
||||
|
||||
:c,image(Eqs/box.jpg)
|
||||
|
||||
The inverse relationship can be written as follows:
|
||||
|
||||
:c,image(Eqs/box_inverse.jpg)
|
||||
|
||||
The values of {a}, {b}, {c} , {alpha}, {beta} , and {gamma} can be printed
|
||||
out or accessed by computes using the
|
||||
"thermo_style custom"_thermo_style.html keywords
|
||||
{cella}, {cellb}, {cellc}, {cellalpha}, {cellbeta}, {cellgamma},
|
||||
respectively.
|
||||
|
||||
As discussed on the "dump"_dump.html command doc page, when the BOX
|
||||
BOUNDS for a snapshot is written to a dump file for a triclinic box,
|
||||
an orthogonal bounding box which encloses the triclinic simulation box
|
||||
is output, along with the 3 tilt factors (xy, xz, yz) of the triclinic
|
||||
box, formatted as follows:
|
||||
|
||||
ITEM: BOX BOUNDS xy xz yz
|
||||
xlo_bound xhi_bound xy
|
||||
ylo_bound yhi_bound xz
|
||||
zlo_bound zhi_bound yz :pre
|
||||
|
||||
This bounding box is convenient for many visualization programs and is
|
||||
calculated from the 9 triclinic box parameters
|
||||
(xlo,xhi,ylo,yhi,zlo,zhi,xy,xz,yz) as follows:
|
||||
|
||||
xlo_bound = xlo + MIN(0.0,xy,xz,xy+xz)
|
||||
xhi_bound = xhi + MAX(0.0,xy,xz,xy+xz)
|
||||
ylo_bound = ylo + MIN(0.0,yz)
|
||||
yhi_bound = yhi + MAX(0.0,yz)
|
||||
zlo_bound = zlo
|
||||
zhi_bound = zhi :pre
|
||||
|
||||
These formulas can be inverted if you need to convert the bounding box
|
||||
back into the triclinic box parameters, e.g. xlo = xlo_bound -
|
||||
MIN(0.0,xy,xz,xy+xz).
|
||||
|
||||
One use of triclinic simulation boxes is to model solid-state crystals
|
||||
with triclinic symmetry. The "lattice"_lattice.html command can be
|
||||
used with non-orthogonal basis vectors to define a lattice that will
|
||||
tile a triclinic simulation box via the
|
||||
"create_atoms"_create_atoms.html command.
|
||||
|
||||
A second use is to run Parrinello-Rahman dynamics via the "fix
|
||||
npt"_fix_nh.html command, which will adjust the xy, xz, yz tilt
|
||||
factors to compensate for off-diagonal components of the pressure
|
||||
tensor. The analog for an "energy minimization"_minimize.html is
|
||||
the "fix box/relax"_fix_box_relax.html command.
|
||||
|
||||
A third use is to shear a bulk solid to study the response of the
|
||||
material. The "fix deform"_fix_deform.html command can be used for
|
||||
this purpose. It allows dynamic control of the xy, xz, yz tilt
|
||||
factors as a simulation runs. This is discussed in the next section
|
||||
on non-equilibrium MD (NEMD) simulations.
|
|
@ -1,144 +0,0 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Calculate viscosity :h3
|
||||
|
||||
The shear viscosity eta of a fluid can be measured in at least 5 ways
|
||||
using various options in LAMMPS. See the examples/VISCOSITY directory
|
||||
for scripts that implement the 5 methods discussed here for a simple
|
||||
Lennard-Jones fluid model. Also, see the "Howto
|
||||
kappa"_Howto_kappa.html doc page for an analogous discussion for
|
||||
thermal conductivity.
|
||||
|
||||
Eta is a measure of the propensity of a fluid to transmit momentum in
|
||||
a direction perpendicular to the direction of velocity or momentum
|
||||
flow. Alternatively it is the resistance the fluid has to being
|
||||
sheared. It is given by
|
||||
|
||||
J = -eta grad(Vstream)
|
||||
|
||||
where J is the momentum flux in units of momentum per area per time.
|
||||
and grad(Vstream) is the spatial gradient of the velocity of the fluid
|
||||
moving in another direction, normal to the area through which the
|
||||
momentum flows. Viscosity thus has units of pressure-time.
|
||||
|
||||
The first method is to perform a non-equilibrium MD (NEMD) simulation
|
||||
by shearing the simulation box via the "fix deform"_fix_deform.html
|
||||
command, and using the "fix nvt/sllod"_fix_nvt_sllod.html command to
|
||||
thermostat the fluid via the SLLOD equations of motion.
|
||||
Alternatively, as a second method, one or more moving walls can be
|
||||
used to shear the fluid in between them, again with some kind of
|
||||
thermostat that modifies only the thermal (non-shearing) components of
|
||||
velocity to prevent the fluid from heating up.
|
||||
|
||||
NOTE: A recent (2017) book by "(Daivis and Todd)"_#Daivis-viscosity
|
||||
discusses use of the SLLOD method and non-equilibrium MD (NEMD)
|
||||
thermostatting generally, for both simple and complex fluids,
|
||||
e.g. molecular systems. The latter can be tricky to do correctly.
|
||||
|
||||
In both cases, the velocity profile setup in the fluid by this
|
||||
procedure can be monitored by the "fix ave/chunk"_fix_ave_chunk.html
|
||||
command, which determines grad(Vstream) in the equation above.
|
||||
E.g. the derivative in the y-direction of the Vx component of fluid
|
||||
motion or grad(Vstream) = dVx/dy. The Pxy off-diagonal component of
|
||||
the pressure or stress tensor, as calculated by the "compute
|
||||
pressure"_compute_pressure.html command, can also be monitored, which
|
||||
is the J term in the equation above. See the "Howto
|
||||
nemd"_Howto_nemd.html doc page for details on NEMD simulations.
|
||||
|
||||
The third method is to perform a reverse non-equilibrium MD simulation
|
||||
using the "fix viscosity"_fix_viscosity.html command which implements
|
||||
the rNEMD algorithm of Muller-Plathe. Momentum in one dimension is
|
||||
swapped between atoms in two different layers of the simulation box in
|
||||
a different dimension. This induces a velocity gradient which can be
|
||||
monitored with the "fix ave/chunk"_fix_ave_chunk.html command.
|
||||
The fix tallies the cumulative momentum transfer that it performs.
|
||||
See the "fix viscosity"_fix_viscosity.html command for details.
|
||||
|
||||
The fourth method is based on the Green-Kubo (GK) formula which
|
||||
relates the ensemble average of the auto-correlation of the
|
||||
stress/pressure tensor to eta. This can be done in a fully
|
||||
equilibrated simulation which is in contrast to the two preceding
|
||||
non-equilibrium methods, where momentum flows continuously through the
|
||||
simulation box.
|
||||
|
||||
Here is an example input script that calculates the viscosity of
|
||||
liquid Ar via the GK formalism:
|
||||
|
||||
# Sample LAMMPS input script for viscosity of liquid Ar :pre
|
||||
|
||||
units real
|
||||
variable T equal 86.4956
|
||||
variable V equal vol
|
||||
variable dt equal 4.0
|
||||
variable p equal 400 # correlation length
|
||||
variable s equal 5 # sample interval
|
||||
variable d equal $p*$s # dump interval :pre
|
||||
|
||||
# convert from LAMMPS real units to SI :pre
|
||||
|
||||
variable kB equal 1.3806504e-23 # \[J/K\] Boltzmann
|
||||
variable atm2Pa equal 101325.0
|
||||
variable A2m equal 1.0e-10
|
||||
variable fs2s equal 1.0e-15
|
||||
variable convert equal $\{atm2Pa\}*$\{atm2Pa\}*$\{fs2s\}*$\{A2m\}*$\{A2m\}*$\{A2m\} :pre
|
||||
|
||||
# setup problem :pre
|
||||
|
||||
dimension 3
|
||||
boundary p p p
|
||||
lattice fcc 5.376 orient x 1 0 0 orient y 0 1 0 orient z 0 0 1
|
||||
region box block 0 4 0 4 0 4
|
||||
create_box 1 box
|
||||
create_atoms 1 box
|
||||
mass 1 39.948
|
||||
pair_style lj/cut 13.0
|
||||
pair_coeff * * 0.2381 3.405
|
||||
timestep $\{dt\}
|
||||
thermo $d :pre
|
||||
|
||||
# equilibration and thermalization :pre
|
||||
|
||||
velocity all create $T 102486 mom yes rot yes dist gaussian
|
||||
fix NVT all nvt temp $T $T 10 drag 0.2
|
||||
run 8000 :pre
|
||||
|
||||
# viscosity calculation, switch to NVE if desired :pre
|
||||
|
||||
#unfix NVT
|
||||
#fix NVE all nve :pre
|
||||
|
||||
reset_timestep 0
|
||||
variable pxy equal pxy
|
||||
variable pxz equal pxz
|
||||
variable pyz equal pyz
|
||||
fix SS all ave/correlate $s $p $d &
|
||||
v_pxy v_pxz v_pyz type auto file S0St.dat ave running
|
||||
variable scale equal $\{convert\}/($\{kB\}*$T)*$V*$s*$\{dt\}
|
||||
variable v11 equal trap(f_SS\[3\])*$\{scale\}
|
||||
variable v22 equal trap(f_SS\[4\])*$\{scale\}
|
||||
variable v33 equal trap(f_SS\[5\])*$\{scale\}
|
||||
thermo_style custom step temp press v_pxy v_pxz v_pyz v_v11 v_v22 v_v33
|
||||
run 100000
|
||||
variable v equal (v_v11+v_v22+v_v33)/3.0
|
||||
variable ndens equal count(all)/vol
|
||||
print "average viscosity: $v \[Pa.s\] @ $T K, $\{ndens\} /A^3" :pre
|
||||
|
||||
The fifth method is related to the above Green-Kubo method,
|
||||
but uses the Einstein formulation, analogous to the Einstein
|
||||
mean-square-displacement formulation for self-diffusivity. The
|
||||
time-integrated momentum fluxes play the role of Cartesian
|
||||
coordinates, whose mean-square displacement increases linearly
|
||||
with time at sufficiently long times.
|
||||
|
||||
:line
|
||||
|
||||
:link(Daivis-viscosity)
|
||||
[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dynamics (book),
|
||||
Cambridge University Press, https://doi.org/10.1017/9781139017848, (2017).
|
|
@ -1,40 +0,0 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Visualize LAMMPS snapshots :h3
|
||||
|
||||
LAMMPS itself does not do visualization, but snapshots from LAMMPS
|
||||
simulations can be visualized (and analyzed) in a variety of ways.
|
||||
|
||||
Mention dump image and dump movie.
|
||||
|
||||
LAMMPS snapshots are created by the "dump"_dump.html command which can
|
||||
create files in several formats. The native LAMMPS dump format is a
|
||||
text file (see "dump atom" or "dump custom") which can be visualized
|
||||
by several popular visualization tools. The "dump
|
||||
image"_dump_image.html and "dump movie"_dump_image.html styles can
|
||||
output internally rendered images and convert a sequence of them to a
|
||||
movie during the MD run. Several programs included with LAMMPS as
|
||||
auxiliary tools can convert between LAMMPS format files and other
|
||||
formats. See the "Tools"_Tools.html doc page for details.
|
||||
|
||||
A Python-based toolkit distributed by our group can read native LAMMPS
|
||||
dump files, including custom dump files with additional columns of
|
||||
user-specified atom information, and convert them to various formats
|
||||
or pipe them into visualization software directly. See the "Pizza.py
|
||||
WWW site"_pizza for details. Specifically, Pizza.py can convert
|
||||
LAMMPS dump files into PDB, XYZ, "Ensight"_ensight, and VTK formats.
|
||||
Pizza.py can pipe LAMMPS dump files directly into the Raster3d and
|
||||
RasMol visualization programs. Pizza.py has tools that do interactive
|
||||
3d OpenGL visualization and one that creates SVG images of dump file
|
||||
snapshots.
|
||||
|
||||
:link(pizza,http://www.sandia.gov/~sjplimp/pizza.html)
|
||||
:link(ensight,http://www.ensight.com)
|
||||
:link(atomeye,http://mt.seas.upenn.edu/Archive/Graphics/A)
|
|
@ -1,81 +0,0 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Walls :h3
|
||||
|
||||
Walls in an MD simulation are typically used to bound particle motion,
|
||||
i.e. to serve as a boundary condition.
|
||||
|
||||
Walls in LAMMPS can be of rough (made of particles) or idealized
|
||||
surfaces. Ideal walls can be smooth, generating forces only in the
|
||||
normal direction, or frictional, generating forces also in the
|
||||
tangential direction.
|
||||
|
||||
Rough walls, built of particles, can be created in various ways. The
|
||||
particles themselves can be generated like any other particle, via the
|
||||
"lattice"_lattice.html and "create_atoms"_create_atoms.html commands,
|
||||
or read in via the "read_data"_read_data.html command.
|
||||
|
||||
Their motion can be constrained by many different commands, so that
|
||||
they do not move at all, move together as a group at constant velocity
|
||||
or in response to a net force acting on them, move in a prescribed
|
||||
fashion (e.g. rotate around a point), etc. Note that if a time
|
||||
integration fix like "fix nve"_fix_nve.html or "fix nvt"_fix_nh.html
|
||||
is not used with the group that contains wall particles, their
|
||||
positions and velocities will not be updated.
|
||||
|
||||
"fix aveforce"_fix_aveforce.html - set force on particles to average value, so they move together
|
||||
"fix setforce"_fix_setforce.html - set force on particles to a value, e.g. 0.0
|
||||
"fix freeze"_fix_freeze.html - freeze particles for use as granular walls
|
||||
"fix nve/noforce"_fix_nve_noforce.html - advect particles by their velocity, but without force
|
||||
"fix move"_fix_move.html - prescribe motion of particles by a linear velocity, oscillation, rotation, variable :ul
|
||||
|
||||
The "fix move"_fix_move.html command offers the most generality, since
|
||||
the motion of individual particles can be specified with
|
||||
"variable"_variable.html formula which depends on time and/or the
|
||||
particle position.
|
||||
|
||||
For rough walls, it may be useful to turn off pairwise interactions
|
||||
between wall particles via the "neigh_modify
|
||||
exclude"_neigh_modify.html command.
|
||||
|
||||
Rough walls can also be created by specifying frozen particles that do
|
||||
not move and do not interact with mobile particles, and then tethering
|
||||
other particles to the fixed particles, via a "bond"_bond_style.html.
|
||||
The bonded particles do interact with other mobile particles.
|
||||
|
||||
Idealized walls can be specified via several fix commands. "Fix
|
||||
wall/gran"_fix_wall_gran.html creates frictional walls for use with
|
||||
granular particles; all the other commands create smooth walls.
|
||||
|
||||
"fix wall/reflect"_fix_wall_reflect.html - reflective flat walls
|
||||
"fix wall/lj93"_fix_wall.html - flat walls, with Lennard-Jones 9/3 potential
|
||||
"fix wall/lj126"_fix_wall.html - flat walls, with Lennard-Jones 12/6 potential
|
||||
"fix wall/colloid"_fix_wall.html - flat walls, with "pair_style colloid"_pair_colloid.html potential
|
||||
"fix wall/harmonic"_fix_wall.html - flat walls, with repulsive harmonic spring potential
|
||||
"fix wall/morse"_fix_wall.html - flat walls, with Morse potential
|
||||
"fix wall/region"_fix_wall_region.html - use region surface as wall
|
||||
"fix wall/gran"_fix_wall_gran.html - flat or curved walls with "pair_style granular"_pair_gran.html potential :ul
|
||||
|
||||
The {lj93}, {lj126}, {colloid}, {harmonic}, and {morse} styles all
|
||||
allow the flat walls to move with a constant velocity, or oscillate in
|
||||
time. The "fix wall/region"_fix_wall_region.html command offers the
|
||||
most generality, since the region surface is treated as a wall, and
|
||||
the geometry of the region can be a simple primitive volume (e.g. a
|
||||
sphere, or cube, or plane), or a complex volume made from the union
|
||||
and intersection of primitive volumes. "Regions"_region.html can also
|
||||
specify a volume "interior" or "exterior" to the specified primitive
|
||||
shape or {union} or {intersection}. "Regions"_region.html can also be
|
||||
"dynamic" meaning they move with constant velocity, oscillate, or
|
||||
rotate.
|
||||
|
||||
The only frictional idealized walls currently in LAMMPS are flat or
|
||||
curved surfaces specified by the "fix wall/gran"_fix_wall_gran.html
|
||||
command. At some point we plan to allow regoin surfaces to be used as
|
||||
frictional walls, as well as triangulated surfaces.
|
|
@ -1,113 +0,0 @@
|
|||
"Higher level section"_Install.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Download source via Git :h3
|
||||
|
||||
All LAMMPS development is coordinated through the "LAMMPS GitHub
|
||||
site". If you clone the LAMMPS repository onto your local machine, it
|
||||
has several advantages:
|
||||
|
||||
You can stay current with changes to LAMMPS with a single git
|
||||
command. :ulb,l
|
||||
|
||||
You can create your own development branches to add code to LAMMPS. :l
|
||||
|
||||
You can submit your new features back to GitHub for inclusion in
|
||||
LAMMPS. :l,ule
|
||||
|
||||
You must have "Git"_git installed on your system to communicate with
|
||||
the public Git server for LAMMPS.
|
||||
|
||||
IMPORTANT NOTE: As of Oct 2016, the official home of public LAMMPS
|
||||
development is on GitHub. The previously advertised LAMMPS git
|
||||
repositories on git.lammps.org and bitbucket.org are now deprecated,
|
||||
may not be up-to-date, and may go away at any time.
|
||||
|
||||
:link(git,http://git-scm.com)
|
||||
|
||||
You can follow LAMMPS development on 3 different Git branches:
|
||||
|
||||
[stable] : this branch is updated with every stable release
|
||||
[unstable] : this branch is updated with every patch release
|
||||
[master] : this branch continuously follows ongoing development :ul
|
||||
|
||||
To access the Git repositories on your box, use the clone command to
|
||||
create a local copy of the LAMMPS repository with a command like:
|
||||
|
||||
git clone -b unstable https://github.com/lammps/lammps.git mylammps :pre
|
||||
|
||||
where "mylammps" is the name of the directory you wish to create on
|
||||
your machine and "unstable" is one of the 3 branches listed above.
|
||||
(Note that you actually download all 3 branches; you can switch
|
||||
between them at any time using "git checkout <branch name>".)
|
||||
|
||||
Once the command completes, your directory will contain the same files
|
||||
as if you unpacked a current LAMMPS tarball, with the exception, that
|
||||
the HTML documentation files are not included. They can be fetched
|
||||
from the LAMMPS website by typing "make fetch" in the doc directory.
|
||||
Or they can be generated from the content provided in doc/src by
|
||||
typing "make html" from the doc directory.
|
||||
|
||||
After initial cloning, as bug fixes and new features are added to
|
||||
LAMMPS, as listed on "this page"_Errors_bugs.html, you can stay
|
||||
up-to-date by typing the following Git commands from within the
|
||||
"mylammps" directory:
|
||||
|
||||
git checkout unstable # not needed if you always stay in this branch
|
||||
git checkout stable # use one of the 3 checkout commands
|
||||
git checkout master
|
||||
git pull :pre
|
||||
|
||||
Doing a "pull" will not change any files you have added to the LAMMPS
|
||||
directory structure. It will also not change any existing LAMMPS
|
||||
files you have edited, unless those files have changed in the
|
||||
repository. In that case, Git will attempt to merge the new
|
||||
repository file with your version of the file and tell you if there
|
||||
are any conflicts. See the Git documentation for details.
|
||||
|
||||
If you want to access a particular previous release version of LAMMPS,
|
||||
you can instead "checkout" any version with a published tag. See the
|
||||
output of "git tag -l" for the list of tags. The Git command to do
|
||||
this is as follows.
|
||||
|
||||
git checkout tagID :pre
|
||||
|
||||
Stable versions and what tagID to use for a particular stable version
|
||||
are discussed on "this page"_Errors_bugs.html. Note that this command
|
||||
will print some warnings, because in order to get back to the latest
|
||||
revision and to be able to update with "git pull" again, you first
|
||||
will need to first type "git checkout unstable" (or check out any
|
||||
other desired branch).
|
||||
|
||||
Once you have updated your local files with a "git pull" (or "git
|
||||
checkout"), you still need to re-build LAMMPS if any source files have
|
||||
changed. To do this, you should cd to the src directory and type:
|
||||
|
||||
make purge # remove any deprecated src files
|
||||
make package-update # sync package files with src files
|
||||
make foo # re-build for your machine (mpi, serial, etc) :pre
|
||||
|
||||
just as described on the "Install patch"_Install_patch.html doc page,
|
||||
after a patch has been installed.
|
||||
|
||||
IMPORTANT NOTE: If you wish to edit/change a src file that is from a
|
||||
package, you should edit the version of the file inside the package
|
||||
sub-directory with src, then re-install the package. The version in
|
||||
the src dir is merely a copy and will be wiped out if you type "make
|
||||
package-update".
|
||||
|
||||
IMPORTANT NOTE: The GitHub servers support both the "git://" and
|
||||
"https://" access protocols for anonymous read-only access. If you
|
||||
have a correspondingly configured GitHub account, you may also use SSH
|
||||
with "git@github.com:/lammps/lammps.git".
|
||||
|
||||
The LAMMPS GitHub project is managed by Christoph Junghans (LANL,
|
||||
junghans at lanl.gov), Axel Kohlmeyer (Temple U, akohlmey at
|
||||
gmail.com) and Richard Berger (Temple U, richard.berger at
|
||||
temple.edu).
|
|
@ -1,199 +0,0 @@
|
|||
"Higher level section"_Install.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Download an executable for Linux :h3
|
||||
|
||||
Binaries are available for different versions of Linux:
|
||||
|
||||
"Pre-built Ubuntu Linux executables"_#ubuntu
|
||||
"Pre-built Fedora Linux executables"_#fedora
|
||||
"Pre-built EPEL Linux executables (RHEL, CentOS)"_#epel
|
||||
"Pre-built OpenSuse Linux executables"_#opensuse
|
||||
"Gentoo Linux executable"_#gentoo
|
||||
"Arch Linux build-script"_#arch :all(b)
|
||||
|
||||
:line
|
||||
|
||||
Pre-built Ubuntu Linux executables :h4,link(ubuntu)
|
||||
|
||||
A pre-built LAMMPS executable suitable for running on the latest
|
||||
Ubuntu Linux versions, can be downloaded as a Debian package. This
|
||||
allows you to install LAMMPS with a single command, and stay
|
||||
up-to-date with the current version of LAMMPS by simply updating your
|
||||
operating system.
|
||||
|
||||
To install the appropriate personal-package archive (PPA), do the
|
||||
following once:
|
||||
|
||||
sudo add-apt-repository ppa:gladky-anton/lammps
|
||||
sudo apt-get update :pre
|
||||
|
||||
To install LAMMPS do the following once:
|
||||
|
||||
sudo apt-get install lammps-daily :pre
|
||||
|
||||
This downloads an executable named "lmp_daily" to your box, which
|
||||
can then be used in the usual way to run input scripts:
|
||||
|
||||
lmp_daily -in in.lj :pre
|
||||
|
||||
To update LAMMPS to the most current version, do the following:
|
||||
|
||||
sudo apt-get update :pre
|
||||
|
||||
which will also update other packages on your system.
|
||||
|
||||
To get a copy of the current documentation and examples:
|
||||
|
||||
sudo apt-get install lammps-daily-doc :pre
|
||||
|
||||
which will download the doc files in
|
||||
/usr/share/doc/lammps-daily-doc/doc and example problems in
|
||||
/usr/share/doc/lammps-doc/examples.
|
||||
|
||||
Note that you may still wish to download the tarball to get potential
|
||||
files and auxiliary tools.
|
||||
|
||||
To un-install LAMMPS, do the following:
|
||||
|
||||
sudo apt-get remove lammps-daily :pre
|
||||
|
||||
Note that the lammps-daily executable is built with the following
|
||||
sequence of make commands, as if you had done the same with the
|
||||
unpacked tarball files in the src directory:
|
||||
|
||||
make yes-all; make no-lib; make openmpi
|
||||
|
||||
Thus it builds with FFTW3 and OpenMPI.
|
||||
|
||||
Thanks to Anton Gladky (gladky.anton at gmail.com) for setting up this
|
||||
Ubuntu package capability.
|
||||
|
||||
:line
|
||||
|
||||
Pre-built Fedora Linux executables :h4,link(fedora)
|
||||
|
||||
Pre-built LAMMPS packages for stable releases are available
|
||||
in the Fedora Linux distribution as of version 28. The packages
|
||||
can be installed via the dnf package manager. There are 3 basic
|
||||
varieties (lammps = no MPI, lammps-mpich = MPICH MPI library,
|
||||
lammps-openmpi = OpenMPI MPI library) and for each support for
|
||||
linking to the C library interface (lammps-devel, lammps-mpich-devel,
|
||||
lammps-openmpi-devel), the header for compiling programs using
|
||||
the C library interface (lammps-headers), and the LAMMPS python
|
||||
module for Python 3. All packages can be installed at the same
|
||||
time and the name of the LAMMPS executable is {lmp} and {lmp_openmpi}
|
||||
or {lmp_mpich} respectively. By default, {lmp} will refer to the
|
||||
serial executable, unless one of the MPI environment modules is loaded
|
||||
("module load mpi/mpich-x86_64" or "module load mpi/openmpi-x86_64").
|
||||
Then the corresponding parallel LAMMPS executable can be used.
|
||||
The same mechanism applies when loading the LAMMPS python module.
|
||||
|
||||
To install LAMMPS with OpenMPI and run an input in.lj with 2 CPUs do:
|
||||
|
||||
dnf install lammps-openmpi
|
||||
module load mpi/openmpi-x86_64
|
||||
mpirun -np 2 lmp -in in.lj :pre
|
||||
|
||||
The "dnf install" command is needed only once. In case of a new LAMMPS
|
||||
stable release, "dnf update" will automatically update to the newer
|
||||
version as soon at the RPM files are built and uploaded to the download
|
||||
mirrors. The "module load" command is needed once per (shell) session
|
||||
or shell terminal instance, unless it is automatically loaded from the
|
||||
shell profile.
|
||||
|
||||
Please use "lmp -help" to see which compilation options, packages,
|
||||
and styles are included in the binary.
|
||||
|
||||
Thanks to Christoph Junghans (LANL) for making LAMMPS available in Fedora.
|
||||
|
||||
:line
|
||||
|
||||
Pre-built EPEL Linux executable :h4,link(epel)
|
||||
|
||||
Pre-built LAMMPS packages for stable releases are available
|
||||
in the "Extra Packages for Enterprise Linux (EPEL) repository"_https://fedoraproject.org/wiki/EPEL
|
||||
for use with Red Hat Enterprise Linux (RHEL) or CentOS version 7.x
|
||||
and compatible Linux distributions. Names of packages, executable,
|
||||
and content are the same as described above for Fedora Linux.
|
||||
But RHEL/CentOS 7.x uses the "yum" package manager instead of "dnf"
|
||||
in Fedora 28.
|
||||
|
||||
Please use "lmp -help" to see which compilation options, packages,
|
||||
and styles are included in the binary.
|
||||
|
||||
Thanks to Christoph Junghans (LANL) for making LAMMPS available in EPEL.
|
||||
|
||||
:line
|
||||
|
||||
Pre-built OpenSuse Linux executable :h4,link(opensuse)
|
||||
|
||||
A pre-built LAMMPS package for stable releases is available
|
||||
in OpenSuse as of Leap 15.0. You can install the package with:
|
||||
|
||||
zypper install lammps :pre
|
||||
|
||||
This includes support for OpenMPI. The name of the LAMMPS executable
|
||||
is {lmp}. Thus to run an input in parallel on 2 CPUs you would do:
|
||||
|
||||
mpirun -np 2 lmp -in in.lj :pre
|
||||
|
||||
Please use "lmp -help" to see which compilation options, packages,
|
||||
and styles are included in the binary.
|
||||
|
||||
Thanks to Christoph Junghans (LANL) for making LAMMPS available in OpenSuse.
|
||||
|
||||
:line
|
||||
|
||||
Gentoo Linux executable :h4,link(gentoo)
|
||||
|
||||
LAMMPS is part of Gentoo's main package tree and can be installed by
|
||||
typing:
|
||||
|
||||
% emerge --ask lammps :pre
|
||||
|
||||
Note that in Gentoo the LAMMPS source is downloaded and the package is
|
||||
built on the your machine.
|
||||
|
||||
Certain LAMMPS packages can be enable via USE flags, type
|
||||
|
||||
% equery uses lammps :pre
|
||||
|
||||
for details.
|
||||
|
||||
Thanks to Nicolas Bock and Christoph Junghans (LANL) for setting up
|
||||
this Gentoo capability.
|
||||
|
||||
:line
|
||||
|
||||
Archlinux build-script :h4,link(arch)
|
||||
|
||||
LAMMPS is available via Arch's unofficial Arch User repository (AUR).
|
||||
|
||||
There are three scripts available, named lammps, lammps-beta and lammps-git.
|
||||
They respectively package the stable, patch and git releases.
|
||||
|
||||
To install, you will need to have the git package installed. You may use
|
||||
any of the above names in-place of lammps.
|
||||
|
||||
$ git clone https://aur.archlinux.org/lammps.git :pre
|
||||
$ cd lammps :pre
|
||||
$ makepkg -s :pre
|
||||
# makepkg -i :pre
|
||||
|
||||
To update, you may repeat the above, or change into the cloned directory,
|
||||
and execute the following, after which, if there are any changes, you may
|
||||
use makepkg as above.
|
||||
|
||||
$ git pull :pre
|
||||
|
||||
Alternatively, you may use an AUR helper to install these packages.
|
||||
|
||||
Note that the AUR provides build-scripts that download the source and
|
||||
the build the package on your machine.
|
|
@ -1,68 +0,0 @@
|
|||
"Higher level section"_Install.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Applying patches :h3
|
||||
|
||||
It is easy to stay current with the most recent LAMMPS patch releases
|
||||
if you use Git or SVN to track LAMMPS development. Instructions for
|
||||
how to stay current are on the "Install git"_Install_git.html and
|
||||
"Install svn"_Install_svn.html doc pages.
|
||||
|
||||
If you prefer to download a tarball, as described on the "Install
|
||||
git"_Install_tarball.html doc page, you can stay current by
|
||||
downloading "patch files" when new patch releases are made. A link to
|
||||
a patch file is posted on the "bug and feature
|
||||
page"_http://lammps.sandia.gov/bug.html of the LAMMPS website, along
|
||||
with a list of changed files and details about what is in the new patch
|
||||
release. This page explains how to apply the patch file to your local
|
||||
LAMMPS directory.
|
||||
|
||||
NOTE: You should not apply patch files to a local Git or SVN repo of
|
||||
LAMMPS, only to an unpacked tarball. Use Git and SVN commands to
|
||||
update repo versions of LAMMPS.
|
||||
|
||||
Here are the steps to apply a patch file. Note that if your version
|
||||
of LAMMPS is several patch releases behind, you need to apply all the
|
||||
intervening patch files in succession to bring your version of LAMMPS
|
||||
up to date.
|
||||
|
||||
Download the patch file. You may have to shift-click in your browser
|
||||
to download the file instead of display it. Patch files have names
|
||||
like patch.12Dec16. :ulb,l
|
||||
|
||||
Put the patch file in your top-level LAMMPS directory, where the
|
||||
LICENSE and README files are. :l
|
||||
|
||||
Apply the patch by typing the following command from your top-level
|
||||
LAMMPS directory, where the redirected file is the name of the patch
|
||||
file. :l
|
||||
|
||||
patch -bp1 < patch.12Dec16 :pre
|
||||
|
||||
A list of updated files print out to the screen. The -b switch
|
||||
creates backup files of your originals (e.g. src/force.cpp.orig), so
|
||||
you can manually undo the patch if something goes wrong. :l
|
||||
|
||||
Type the following from the src directory, to enforce consistency
|
||||
between the src and package directories. This is OK to do even if you
|
||||
don't use one or more packages. If you are applying several patches
|
||||
successively, you only need to type this once at the end. The purge
|
||||
command removes deprecated src files if any were removed by the patch
|
||||
from package sub-directories. :l
|
||||
|
||||
make purge
|
||||
make package-update :pre
|
||||
|
||||
Re-build LAMMPS via the "make" command. :l,ule
|
||||
|
||||
IMPORTANT NOTE: If you wish to edit/change a src file that is from a
|
||||
package, you should edit the version of the file inside the package
|
||||
sub-dir of src, then re-install the package. The version in the src
|
||||
dir is merely a copy and will be wiped out if you type "make
|
||||
package-update".
|
|
@ -1,88 +0,0 @@
|
|||
"Higher level section"_Install.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Download source via SVN :h3
|
||||
|
||||
IMPORTANT NOTE: As of Oct 2016, SVN support is now implemented via a
|
||||
git-to-subversion interface service on GitHub and no longer through a
|
||||
mirror of the internal SVN repository at Sandia.
|
||||
|
||||
You must have the "Subversion (SVN) client software"_svn installed on
|
||||
your system to communicate with the Git server in this mode.
|
||||
|
||||
:link(svn,http://subversion.apache.org)
|
||||
|
||||
You can follow LAMMPS development on 3 different SVN branches:
|
||||
|
||||
[stable] : this branch is updated with every stable release
|
||||
[unstable] : this branch is updated with every patch release
|
||||
[master] : this branch continuously follows ongoing development :ul
|
||||
|
||||
The corresponding command lines to do an initial checkout are as
|
||||
follows. (Note that unlike Git, you must perform a separate checkout
|
||||
into a unique directory for each of the 3 branches.)
|
||||
|
||||
svn checkout https://github.com/lammps/lammps.git/branches/unstable mylammps
|
||||
svn checkout https://github.com/lammps/lammps.git/branches/stable mylammps
|
||||
svn checkout https://github.com/lammps/lammps.git/trunk mylammps :pre
|
||||
|
||||
where "mylammps" is the name of the directory you wish to create on
|
||||
your machine.
|
||||
|
||||
Once the command completes, your directory will contain the same files
|
||||
as if you unpacked a current LAMMPS tarball, with the exception, that
|
||||
the HTML documentation files are not included. They can be fetched
|
||||
from the LAMMPS website by typing "make fetch" in the doc directory.
|
||||
Or they can be generated from the content provided in doc/src by
|
||||
typing "make html" from the doc directory.
|
||||
|
||||
After initial checkout, as bug fixes and new features are added to
|
||||
LAMMPS, as listed on "this page"_Errors_bugs.html, you can stay
|
||||
up-to-date by typing the following SVN commands from within the
|
||||
"mylammps" directory:
|
||||
|
||||
svn update :pre
|
||||
|
||||
You can also check if there are any updates by typing:
|
||||
|
||||
svn -qu status :pre
|
||||
|
||||
Doing an "update" will not change any files you have added to the
|
||||
LAMMPS directory structure. It will also not change any existing
|
||||
LAMMPS files you have edited, unless those files have changed in the
|
||||
repository. In that case, SVN will attempt to merge the new
|
||||
repository file with your version of the file and tell you if there
|
||||
are any conflicts. See the SVN documentation for details.
|
||||
|
||||
Please refer to the "subversion client support help pages on
|
||||
GitHub"_https://help.github.com/articles/support-for-subversion-clients
|
||||
if you want to use advanced features like accessing particular
|
||||
previous release versions via tags.
|
||||
|
||||
Once you have updated your local files with an "svn update" (or "svn
|
||||
co"), you still need to re-build LAMMPS if any source files have
|
||||
changed. To do this, you should cd to the src directory and type:
|
||||
|
||||
make purge # remove any deprecated src files
|
||||
make package-update # sync package files with src files
|
||||
make foo # re-build for your machine (mpi, serial, etc) :pre
|
||||
|
||||
just as described on the "Install patch"_Install_patch.html doc page,
|
||||
after a patch has been installed.
|
||||
|
||||
IMPORTANT NOTE: If you wish to edit/change a src file that is from a
|
||||
package, you should edit the version of the file inside the package
|
||||
sub-directory with src, then re-install the package. The version in
|
||||
the src dir is merely a copy and will be wiped out if you type "make
|
||||
package-update".
|
||||
|
||||
The LAMMPS GitHub project is managed by Christoph Junghans (LANL,
|
||||
junghans at lanl.gov), Axel Kohlmeyer (Temple U, akohlmey at
|
||||
gmail.com) and Richard Berger (Temple U, richard.berger at
|
||||
temple.edu).
|
|
@ -1,68 +0,0 @@
|
|||
"Higher level section"_Install.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Download source and documentation as a tarball :h3
|
||||
|
||||
You can download a current LAMMPS tarball from the "download page"_download
|
||||
of the "LAMMPS website"_lws.
|
||||
|
||||
:link(download,http://lammps.sandia.gov/download.html)
|
||||
:link(bug,http://lammps.sandia.gov/bug.html)
|
||||
:link(older,http://lammps.sandia.gov/tars)
|
||||
|
||||
You have two choices of tarballs, either the most recent stable
|
||||
release or the most current patch release. Stable releases occur a
|
||||
few times per year, and undergo more testing before release. Patch
|
||||
releases occur a couple times per month. The new contents in all
|
||||
releases are listed on the "bug and feature page"_bug of the website.
|
||||
|
||||
Both tarballs include LAMMPS documentation (HTML and PDF files)
|
||||
corresponding to that version. The download page also has an option
|
||||
to download the current-version LAMMPS documentation by itself.
|
||||
|
||||
Older versions of LAMMPS can also be downloaded from "this
|
||||
page"_older.
|
||||
|
||||
Once you have a tarball, unzip and untar it with the following
|
||||
command:
|
||||
|
||||
tar -xzvf lammps*.tar.gz :pre
|
||||
|
||||
This will create a LAMMPS directory with the version date
|
||||
in its name, e.g. lammps-23Jun18.
|
||||
|
||||
:line
|
||||
|
||||
You can also download a zip file via the "Clone or download" button on
|
||||
the "LAMMPS GitHub site"_git. The file name will be lammps-master.zip
|
||||
which can be unzipped with the following command, to create
|
||||
a lammps-master dir:
|
||||
|
||||
unzip lammps*.zip :pre
|
||||
|
||||
This version is the most up-to-date LAMMPS development version. It
|
||||
will have the date of the most recent patch release (see the file
|
||||
src/version.h). But it will also include any new bug-fixes or
|
||||
features added since the last patch release. They will be included in
|
||||
the next patch release tarball.
|
||||
|
||||
:link(git,https://github.com/lammps/lammps)
|
||||
|
||||
:line
|
||||
|
||||
If you download a current LAMMPS tarball, one way to stay current as
|
||||
new patch tarballs are released, is to download a patch file which you
|
||||
can apply to your local directory to update it for each new patch
|
||||
release. (Or of course you could just download the newest tarball
|
||||
periodically.)
|
||||
|
||||
The patch files are posted on the "bug and feature page"_bug of the
|
||||
website, along with a list of changed files and details about what is
|
||||
in the new patch release. Instructions for applying a patch file are
|
||||
on the "Install patch"_Install_patch.html doc page.
|
|
@ -1,52 +0,0 @@
|
|||
"Higher level section"_Install.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Download an executable for Windows :h3
|
||||
|
||||
Pre-compiled Windows installers which install LAMMPS executables on a
|
||||
Windows system can be downloaded from this site:
|
||||
|
||||
"http://packages.lammps.org/windows.html"_http://packages.lammps.org/windows.html
|
||||
|
||||
Note that each installer package has a date in its name, which
|
||||
corresponds to the LAMMPS version of the same date. Installers for
|
||||
current and older versions of LAMMPS are available. 32-bit and 64-bit
|
||||
installers are available, and each installer contains both a serial
|
||||
and parallel executable. The installer site also explains how to
|
||||
install the Windows MPI package (MPICH2 from Argonne National Labs),
|
||||
needed to run in parallel.
|
||||
|
||||
The LAMMPS binaries contain all optional packages included in the
|
||||
source distribution except: KIM, KOKKOS, USER-INTEL, and USER-QMMM.
|
||||
The serial version also does not include the MPIIO and
|
||||
USER-LB packages. GPU support is provided for OpenCL.
|
||||
|
||||
The installer site also has instructions on how to run LAMMPS under
|
||||
Windows, once it is installed, in both serial and parallel.
|
||||
|
||||
When you download the installer package, you run it on your Windows
|
||||
machine. It will then prompt you with a dialog, where you can choose
|
||||
the installation directory, unpack and copy several executables,
|
||||
potential files, documentation pdfs, selected example files, etc. It
|
||||
will then update a few system settings (e.g. PATH, LAMMPS_POTENTIALS)
|
||||
and add an entry into the Start Menu (with references to the
|
||||
documentation, LAMMPS homepage and more). From that menu, there is
|
||||
also a link to an uninstaller that removes the files and undoes the
|
||||
environment manipulations.
|
||||
|
||||
Note that to update to a newer version of LAMMPS, you should typically
|
||||
uninstall the version you currently have, download a new installer,
|
||||
and go through the install procedure described above. I.e. the same
|
||||
procedure for installing/updating most Windows programs. You can
|
||||
install multiple versions of LAMMPS (in different directories), but
|
||||
only the executable for the last-installed package will be found
|
||||
automatically, so this should only be done for debugging purposes.
|
||||
|
||||
Thanks to Axel Kohlmeyer (Temple U, akohlmey at gmail.com) for setting
|
||||
up this Windows capability.
|
|
@ -1,39 +0,0 @@
|
|||
"Previous Section"_Manual.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
|
||||
Section"_Install.html :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
Introduction :h2
|
||||
|
||||
These pages provide a brief introduction to LAMMPS.
|
||||
|
||||
<!-- RST
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
Intro_overview
|
||||
Manual_version
|
||||
Intro_features
|
||||
Intro_nonfeatures
|
||||
Intro_opensource
|
||||
Intro_authors
|
||||
Intro_website
|
||||
|
||||
END_RST -->
|
||||
|
||||
<!-- HTML_ONLY -->
|
||||
|
||||
"Overview of LAMMPS"_Intro_overview.html
|
||||
"LAMMPS features"_Intro_features.html
|
||||
"LAMMPS non-features"_Intro_nonfeatures.html
|
||||
"LAMMPS open-source license"_Intro_license.html
|
||||
"LAMMPS authors"_Intro_authors.html
|
||||
"Additional website links"_Intro_website.html :all(b)
|
||||
|
||||
<!-- END_HTML_ONLY -->
|
|
@ -1,66 +0,0 @@
|
|||
"Higher level section"_Intro.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Authors of LAMMPS :h3
|
||||
|
||||
The primary LAMMPS developers are at Sandia National Labs and Temple
|
||||
University:
|
||||
|
||||
"Steve Plimpton"_sjp, sjplimp at sandia.gov
|
||||
Aidan Thompson, athomps at sandia.gov
|
||||
Stan Moore, stamoor at sandia.gov
|
||||
Axel Kohlmeyer, akohlmey at gmail.com
|
||||
Richard Berger, richard.berger at temple.edu :ul
|
||||
|
||||
:link(sjp,http://www.cs.sandia.gov/~sjplimp)
|
||||
|
||||
Past developers include Paul Crozier and Mark Stevens, both at Sandia,
|
||||
and Ray Shan, now at Materials Design.
|
||||
|
||||
:line
|
||||
|
||||
The "Authors page"_http://lammps.sandia.gov/authors.html of the
|
||||
"LAMMPS website"_lws has a comprehensive list of all the individuals
|
||||
who have contributed code for a new feature or command or tool to
|
||||
LAMMPS.
|
||||
|
||||
:line
|
||||
|
||||
The following folks deserve special recognition. Many of the packages
|
||||
they have written are unique for an MD code and LAMMPS would not be as
|
||||
general-purpose as it is without their expertise and efforts.
|
||||
|
||||
Metin Aktulga (MSU), USER-REAXC package for C version of ReaxFF
|
||||
Mike Brown (Intel), GPU and USER-INTEL packages
|
||||
Colin Denniston (U Western Ontario), USER-LB package
|
||||
Georg Ganzenmuller (EMI), USER-SMD and USER-SPH packages
|
||||
Andres Jaramillo-Botero (Caltech), USER-EFF package for electron force field
|
||||
Reese Jones (Sandia) and colleagues, USER-ATC package for atom/continuum coupling
|
||||
Christoph Kloss (DCS Computing), LIGGGHTS code for granular materials, built on top of LAMMPS
|
||||
Rudra Mukherjee (JPL), POEMS package for articulated rigid body motion
|
||||
Trung Ngyuen (Northwestern U), GPU and RIGID and BODY packages
|
||||
Mike Parks (Sandia), PERI package for Peridynamics
|
||||
Roy Pollock (LLNL), Ewald and PPPM solvers
|
||||
Christian Trott (Sandia), USER-CUDA and KOKKOS packages
|
||||
Ilya Valuev (JIHT), USER-AWPMD package for wave packet MD
|
||||
Greg Wagner (Northwestern U), MEAM package for MEAM potential :ul
|
||||
|
||||
:line
|
||||
|
||||
As discussed on the "History
|
||||
page"_http://lammps.sandia.gov/history.html of the website, LAMMPS
|
||||
originated as a cooperative project between DOE labs and industrial
|
||||
partners. Folks involved in the design and testing of the original
|
||||
version of LAMMPS were the following:
|
||||
|
||||
John Carpenter (Mayo Clinic, formerly at Cray Research)
|
||||
Terry Stouch (Lexicon Pharmaceuticals, formerly at Bristol Myers Squibb)
|
||||
Steve Lustig (Dupont)
|
||||
Jim Belak and Roy Pollock (LLNL) :ul
|
||||
|
|
@ -1,202 +0,0 @@
|
|||
"Higher level section"_Intro.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
LAMMPS features :h3
|
||||
|
||||
LAMMPS is a classical molecular dynamics (MD) code with these general
|
||||
classes of functionality:
|
||||
|
||||
"General features"_#general
|
||||
"Particle and model types"_#particle
|
||||
"Interatomic potentials (force fields)"_#ff
|
||||
"Atom creation"_#create
|
||||
"Ensembles, constraints, and boundary conditions"_#ensemble
|
||||
"Integrators"_#integrate
|
||||
"Diagnostics"_#diag
|
||||
"Output"_#output
|
||||
"Multi-replica models"_#replica1
|
||||
"Pre- and post-processing"_#prepost
|
||||
"Specialized features (beyond MD itself)"_#special :ul
|
||||
|
||||
:line
|
||||
|
||||
General features :h4,link(general)
|
||||
|
||||
runs on a single processor or in parallel
|
||||
distributed-memory message-passing parallelism (MPI)
|
||||
spatial-decomposition of simulation domain for parallelism
|
||||
open-source distribution
|
||||
highly portable C++
|
||||
optional libraries used: MPI and single-processor FFT
|
||||
GPU (CUDA and OpenCL), Intel Xeon Phi, and OpenMP support for many code features
|
||||
easy to extend with new features and functionality
|
||||
runs from an input script
|
||||
syntax for defining and using variables and formulas
|
||||
syntax for looping over runs and breaking out of loops
|
||||
run one or multiple simulations simultaneously (in parallel) from one script
|
||||
build as library, invoke LAMMPS through library interface or provided Python wrapper
|
||||
couple with other codes: LAMMPS calls other code, other code calls LAMMPS, umbrella code calls both :ul
|
||||
|
||||
Particle and model types :h4,link(particle)
|
||||
("atom style"_atom_style.html command)
|
||||
|
||||
atoms
|
||||
coarse-grained particles (e.g. bead-spring polymers)
|
||||
united-atom polymers or organic molecules
|
||||
all-atom polymers, organic molecules, proteins, DNA
|
||||
metals
|
||||
granular materials
|
||||
coarse-grained mesoscale models
|
||||
finite-size spherical and ellipsoidal particles
|
||||
finite-size line segment (2d) and triangle (3d) particles
|
||||
point dipole particles
|
||||
rigid collections of particles
|
||||
hybrid combinations of these :ul
|
||||
|
||||
Interatomic potentials (force fields) :h4,link(ff)
|
||||
("pair style"_pair_style.html, "bond style"_bond_style.html,
|
||||
"angle style"_angle_style.html, "dihedral style"_dihedral_style.html,
|
||||
"improper style"_improper_style.html, "kspace style"_kspace_style.html
|
||||
commands)
|
||||
|
||||
pairwise potentials: Lennard-Jones, Buckingham, Morse, Born-Mayer-Huggins, \
|
||||
Yukawa, soft, class 2 (COMPASS), hydrogen bond, tabulated
|
||||
charged pairwise potentials: Coulombic, point-dipole
|
||||
many-body potentials: EAM, Finnis/Sinclair EAM, modified EAM (MEAM), \
|
||||
embedded ion method (EIM), EDIP, ADP, Stillinger-Weber, Tersoff, \
|
||||
REBO, AIREBO, ReaxFF, COMB, SNAP, Streitz-Mintmire, 3-body polymorphic
|
||||
long-range interactions for charge, point-dipoles, and LJ dispersion: \
|
||||
Ewald, Wolf, PPPM (similar to particle-mesh Ewald)
|
||||
polarization models: "QEq"_fix_qeq.html, \
|
||||
"core/shell model"_Howto_coreshell.html, \
|
||||
"Drude dipole model"_Howto_drude.html
|
||||
charge equilibration (QEq via dynamic, point, shielded, Slater methods)
|
||||
coarse-grained potentials: DPD, GayBerne, REsquared, colloidal, DLVO
|
||||
mesoscopic potentials: granular, Peridynamics, SPH
|
||||
electron force field (eFF, AWPMD)
|
||||
bond potentials: harmonic, FENE, Morse, nonlinear, class 2, \
|
||||
quartic (breakable)
|
||||
angle potentials: harmonic, CHARMM, cosine, cosine/squared, cosine/periodic, \
|
||||
class 2 (COMPASS)
|
||||
dihedral potentials: harmonic, CHARMM, multi-harmonic, helix, \
|
||||
class 2 (COMPASS), OPLS
|
||||
improper potentials: harmonic, cvff, umbrella, class 2 (COMPASS)
|
||||
polymer potentials: all-atom, united-atom, bead-spring, breakable
|
||||
water potentials: TIP3P, TIP4P, SPC
|
||||
implicit solvent potentials: hydrodynamic lubrication, Debye
|
||||
force-field compatibility with common CHARMM, AMBER, DREIDING, \
|
||||
OPLS, GROMACS, COMPASS options
|
||||
access to the "OpenKIM Repository"_http://openkim.org of potentials via \
|
||||
"kim_init, kim_interactions, and kim_query"_kim_commands.html commands
|
||||
hybrid potentials: multiple pair, bond, angle, dihedral, improper \
|
||||
potentials can be used in one simulation
|
||||
overlaid potentials: superposition of multiple pair potentials :ul
|
||||
|
||||
Atom creation :h4,link(create)
|
||||
("read_data"_read_data.html, "lattice"_lattice.html,
|
||||
"create_atoms"_create_atoms.html, "delete_atoms"_delete_atoms.html,
|
||||
"displace_atoms"_displace_atoms.html, "replicate"_replicate.html commands)
|
||||
|
||||
read in atom coords from files
|
||||
create atoms on one or more lattices (e.g. grain boundaries)
|
||||
delete geometric or logical groups of atoms (e.g. voids)
|
||||
replicate existing atoms multiple times
|
||||
displace atoms :ul
|
||||
|
||||
Ensembles, constraints, and boundary conditions :h4,link(ensemble)
|
||||
("fix"_fix.html command)
|
||||
|
||||
2d or 3d systems
|
||||
orthogonal or non-orthogonal (triclinic symmetry) simulation domains
|
||||
constant NVE, NVT, NPT, NPH, Parrinello/Rahman integrators
|
||||
thermostatting options for groups and geometric regions of atoms
|
||||
pressure control via Nose/Hoover or Berendsen barostatting in 1 to 3 dimensions
|
||||
simulation box deformation (tensile and shear)
|
||||
harmonic (umbrella) constraint forces
|
||||
rigid body constraints
|
||||
SHAKE bond and angle constraints
|
||||
Monte Carlo bond breaking, formation, swapping
|
||||
atom/molecule insertion and deletion
|
||||
walls of various kinds
|
||||
non-equilibrium molecular dynamics (NEMD)
|
||||
variety of additional boundary conditions and constraints :ul
|
||||
|
||||
Integrators :h4,link(integrate)
|
||||
("run"_run.html, "run_style"_run_style.html, "minimize"_minimize.html commands)
|
||||
|
||||
velocity-Verlet integrator
|
||||
Brownian dynamics
|
||||
rigid body integration
|
||||
energy minimization via conjugate gradient or steepest descent relaxation
|
||||
rRESPA hierarchical timestepping
|
||||
rerun command for post-processing of dump files :ul
|
||||
|
||||
Diagnostics :h4,link(diag)
|
||||
|
||||
see various flavors of the "fix"_fix.html and "compute"_compute.html commands :ul
|
||||
|
||||
Output :h4,link(output)
|
||||
("dump"_dump.html, "restart"_restart.html commands)
|
||||
|
||||
log file of thermodynamic info
|
||||
text dump files of atom coords, velocities, other per-atom quantities
|
||||
binary restart files
|
||||
parallel I/O of dump and restart files
|
||||
per-atom quantities (energy, stress, centro-symmetry parameter, CNA, etc)
|
||||
user-defined system-wide (log file) or per-atom (dump file) calculations
|
||||
spatial and time averaging of per-atom quantities
|
||||
time averaging of system-wide quantities
|
||||
atom snapshots in native, XYZ, XTC, DCD, CFG formats :ul
|
||||
|
||||
Multi-replica models :h4,link(replica1)
|
||||
|
||||
"nudged elastic band"_neb.html
|
||||
"parallel replica dynamics"_prd.html
|
||||
"temperature accelerated dynamics"_tad.html
|
||||
"parallel tempering"_temper.html :ul
|
||||
|
||||
Pre- and post-processing :h4,link(prepost)
|
||||
|
||||
A handful of pre- and post-processing tools are packaged with LAMMPS,
|
||||
some of which can convert input and output files to/from formats used
|
||||
by other codes; see the "Toos"_Tools.html doc page. :ulb,l
|
||||
|
||||
Our group has also written and released a separate toolkit called
|
||||
"Pizza.py"_pizza which provides tools for doing setup, analysis,
|
||||
plotting, and visualization for LAMMPS simulations. Pizza.py is
|
||||
written in "Python"_python and is available for download from "the
|
||||
Pizza.py WWW site"_pizza. :l,ule
|
||||
|
||||
:link(pizza,http://www.sandia.gov/~sjplimp/pizza.html)
|
||||
:link(python,http://www.python.org)
|
||||
|
||||
Specialized features :h4,link(special)
|
||||
|
||||
LAMMPS can be built with optional packages which implement a variety
|
||||
of additional capabilities. See the "Packages"_Packages.html doc
|
||||
page for details.
|
||||
|
||||
These are LAMMPS capabilities which you may not think of as typical
|
||||
classical MD options:
|
||||
|
||||
"static"_balance.html and "dynamic load-balancing"_fix_balance.html
|
||||
"generalized aspherical particles"_Howto_body.html
|
||||
"stochastic rotation dynamics (SRD)"_fix_srd.html
|
||||
"real-time visualization and interactive MD"_fix_imd.html
|
||||
calculate "virtual diffraction patterns"_compute_xrd.html
|
||||
"atom-to-continuum coupling"_fix_atc.html with finite elements
|
||||
coupled rigid body integration via the "POEMS"_fix_poems.html library
|
||||
"QM/MM coupling"_fix_qmmm.html
|
||||
Monte Carlo via "GCMC"_fix_gcmc.html and "tfMC"_fix_tfmc.html and "atom swapping"_fix_atom_swap.html
|
||||
"path-integral molecular dynamics (PIMD)"_fix_ipi.html and "this as well"_fix_pimd.html
|
||||
"Direct Simulation Monte Carlo"_pair_dsmc.html for low-density fluids
|
||||
"Peridynamics mesoscale modeling"_pair_peri.html
|
||||
"Lattice Boltzmann fluid"_fix_lb_fluid.html
|
||||
"targeted"_fix_tmd.html and "steered"_fix_smd.html molecular dynamics
|
||||
"two-temperature electron model"_fix_ttm.html :ul
|
|
@ -1,100 +0,0 @@
|
|||
"Higher level section"_Intro.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
LAMMPS non-features :h3
|
||||
|
||||
LAMMPS is designed to be a fast, parallel engine for molecular
|
||||
dynamics (MD) simulations. It provides only a modest amount of
|
||||
functionality for setting up simulations and analyzing their output.
|
||||
|
||||
Specifically, LAMMPS was not conceived and designed for:
|
||||
|
||||
being run through a GUI
|
||||
building molecular systems, or building molecular topologies
|
||||
assign force-field coefficients automagically
|
||||
perform sophisticated analysis of your MD simulation
|
||||
visualize your MD simulation interactively
|
||||
plot your output data :ul
|
||||
|
||||
Although over the years these limitations have been somewhat
|
||||
reduced through features added to LAMMPS or external tools
|
||||
that either closely interface with LAMMPS or extend LAMMPS.
|
||||
|
||||
Here are suggestions on how to perform these tasks:
|
||||
|
||||
[GUI:] LAMMPS can be built as a library and a Python wrapper that wraps
|
||||
the library interface is provided. Thus, GUI interfaces can be
|
||||
written in Python (or C or C++ if desired) that run LAMMPS and
|
||||
visualize or plot its output. Examples of this are provided in the
|
||||
python directory and described on the "Python"_Python_head.html doc
|
||||
page. Also, there are several external wrappers or GUI front ends. :ulb,l
|
||||
|
||||
[Builder:] Several pre-processing tools are packaged with LAMMPS. Some
|
||||
of them convert input files in formats produced by other MD codes such
|
||||
as CHARMM, AMBER, or Insight into LAMMPS input formats. Some of them
|
||||
are simple programs that will build simple molecular systems, such as
|
||||
linear bead-spring polymer chains. The moltemplate program is a true
|
||||
molecular builder that will generate complex molecular models. See
|
||||
the "Tools"_Tools.html doc page for details on tools packaged with
|
||||
LAMMPS. The "Pre/post processing
|
||||
page"_http:/lammps.sandia.gov/prepost.html of the LAMMPS website
|
||||
describes a variety of 3rd party tools for this task. Furthermore,
|
||||
some LAMMPS internal commands allow to reconstruct, or selectively add
|
||||
topology information, as well as provide the option to insert molecule
|
||||
templates instead of atoms for building bulk molecular systems. :l
|
||||
|
||||
[Force-field assignment:] The conversion tools described in the previous
|
||||
bullet for CHARMM, AMBER, and Insight will also assign force field
|
||||
coefficients in the LAMMPS format, assuming you provide CHARMM, AMBER,
|
||||
or BIOVIA (formerly Accelrys) force field files. The tools
|
||||
"ParmEd"_https://parmed.github.io/ParmEd/html/index.html and
|
||||
"InterMol"_https://github.com/shirtsgroup/InterMol are particularly
|
||||
powerful and flexible in converting force field and topology data
|
||||
between various MD simulation programs. :l
|
||||
|
||||
[Simulation analysis:] If you want to perform analysis on-the-fly as
|
||||
your simulation runs, see the "compute"_compute.html and
|
||||
"fix"_fix.html doc pages, which list commands that can be used in a
|
||||
LAMMPS input script. Also see the "Modify"_Modify.html doc page for
|
||||
info on how to add your own analysis code or algorithms to LAMMPS.
|
||||
For post-processing, LAMMPS output such as "dump file
|
||||
snapshots"_dump.html can be converted into formats used by other MD or
|
||||
post-processing codes. To some degree, that conversion can be done
|
||||
directly inside of LAMMPS by interfacing to the VMD molfile plugins.
|
||||
The "rerun"_rerun.html command also allows to do some post-processing
|
||||
of existing trajectories, and through being able to read a variety
|
||||
of file formats, this can also be used for analyzing trajectories
|
||||
from other MD codes. Some post-processing tools packaged with
|
||||
LAMMPS will do these conversions. Scripts provided in the
|
||||
tools/python directory can extract and massage data in dump files to
|
||||
make it easier to import into other programs. See the
|
||||
"Tools"_Tools.html doc page for details on these various options. :l
|
||||
|
||||
[Visualization:] LAMMPS can produce NETPBM, JPG or PNG snapshot images
|
||||
on-the-fly via its "dump image"_dump_image.html command and pass
|
||||
them to an external program, "FFmpeg"_https://www.ffmpeg.org to generate
|
||||
movies from them. For high-quality, interactive visualization there are
|
||||
many excellent and free tools available. See the "Other Codes
|
||||
page"_http://lammps.sandia.gov/viz.html page of the LAMMPS website for
|
||||
visualization packages that can use LAMMPS output data. :l
|
||||
|
||||
[Plotting:] See the next bullet about Pizza.py as well as the
|
||||
"Python"_Python_head.html doc page for examples of plotting LAMMPS
|
||||
output. Scripts provided with the {python} tool in the tools
|
||||
directory will extract and massage data in log and dump files to make
|
||||
it easier to analyze and plot. See the "Tools"_Tools.html doc page
|
||||
for more discussion of the various tools. :l
|
||||
|
||||
[Pizza.py:] Our group has also written a separate toolkit called
|
||||
"Pizza.py"_http://pizza.sandia.gov which can do certain kinds of
|
||||
setup, analysis, plotting, and visualization (via OpenGL) for LAMMPS
|
||||
simulations. It thus provides some functionality for several of the
|
||||
above bullets. Pizza.py is written in "Python"_http://www.python.org
|
||||
and is available for download from "this
|
||||
page"_http://www.cs.sandia.gov/~sjplimp/download.html. :l,ule
|
|
@ -1,44 +0,0 @@
|
|||
"Higher level section"_Intro.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
LAMMPS open-source license :h3
|
||||
|
||||
LAMMPS is a freely-available open-source code, distributed under the
|
||||
terms of the "GNU Public License"_gnu, which means you can use or
|
||||
modify the code however you wish.
|
||||
|
||||
LAMMPS comes with no warranty of any kind. As each source file states
|
||||
in its header, it is a copyrighted code that is distributed free-of-
|
||||
charge, under the terms of the "GNU Public License"_gnu (GPL). This
|
||||
is often referred to as open-source distribution - see
|
||||
"www.gnu.org"_gnuorg or "www.opensource.org"_opensource. The legal
|
||||
text of the GPL is in the LICENSE file included in the LAMMPS
|
||||
distribution.
|
||||
|
||||
:link(gnu,http://www.gnu.org/copyleft/gpl.html)
|
||||
:link(gnuorg,http://www.gnu.org)
|
||||
:link(opensource,http://www.opensource.org)
|
||||
|
||||
Here is a summary of what the GPL means for LAMMPS users:
|
||||
|
||||
(1) Anyone is free to use, modify, or extend LAMMPS in any way they
|
||||
choose, including for commercial purposes.
|
||||
|
||||
(2) If you distribute a modified version of LAMMPS, it must remain
|
||||
open-source, meaning you distribute it under the terms of the GPL.
|
||||
You should clearly annotate such a code as a derivative version of
|
||||
LAMMPS.
|
||||
|
||||
(3) If you release any code that includes LAMMPS source code, then it
|
||||
must also be open-sourced, meaning you distribute it under the terms
|
||||
of the GPL.
|
||||
|
||||
(4) If you give LAMMPS files to someone else, the GPL LICENSE file and
|
||||
source file headers (including the copyright and GPL notices) should
|
||||
remain part of the code.
|
|
@ -1,58 +0,0 @@
|
|||
"Higher level section"_Intro.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Overview of LAMMPS :h3
|
||||
|
||||
LAMMPS is a classical molecular dynamics (MD) code that models
|
||||
ensembles of particles in a liquid, solid, or gaseous state. It can
|
||||
model atomic, polymeric, biological, solid-state (metals, ceramics,
|
||||
oxides), granular, coarse-grained, or macroscopic systems using a
|
||||
variety of interatomic potentials (force fields) and boundary
|
||||
conditions. It can model 2d or 3d systems with only a few particles
|
||||
up to millions or billions.
|
||||
|
||||
LAMMPS can be built and run on a laptop or desktop machine, but is
|
||||
designed for parallel computers. It will run on any parallel machine
|
||||
that supports the "MPI"_mpi message-passing library. This includes
|
||||
shared-memory boxes and distributed-memory clusters and
|
||||
supercomputers.
|
||||
|
||||
:link(mpi,http://www-unix.mcs.anl.gov/mpi)
|
||||
|
||||
LAMMPS is written in C++. Earlier versions were written in F77 and
|
||||
F90. See the "History page"_http://lammps.sandia.gov/history.html of
|
||||
the website for details. All versions can be downloaded from the
|
||||
"LAMMPS website"_lws.
|
||||
|
||||
LAMMPS is designed to be easy to modify or extend with new
|
||||
capabilities, such as new force fields, atom types, boundary
|
||||
conditions, or diagnostics. See the "Modify"_Modify.html doc page for
|
||||
more details.
|
||||
|
||||
In the most general sense, LAMMPS integrates Newton's equations of
|
||||
motion for a collection of interacting particles. A single particle
|
||||
can be an atom or molecule or electron, a coarse-grained cluster of
|
||||
atoms, or a mesoscopic or macroscopic clump of material. The
|
||||
interaction models that LAMMPS includes are mostly short-range in
|
||||
nature; some long-range models are included as well.
|
||||
|
||||
LAMMPS uses neighbor lists to keep track of nearby particles. The
|
||||
lists are optimized for systems with particles that are repulsive at
|
||||
short distances, so that the local density of particles never becomes
|
||||
too large. This is in contrast to methods used for modeling plasma
|
||||
or gravitational bodies (e.g. galaxy formation).
|
||||
|
||||
On parallel machines, LAMMPS uses spatial-decomposition techniques to
|
||||
partition the simulation domain into small sub-domains of equal
|
||||
computational cost, one of which is assigned to each processor.
|
||||
Processors communicate and store "ghost" atom information for atoms
|
||||
that border their sub-domain.
|
||||
|
||||
|
||||
|
|
@ -1,42 +0,0 @@
|
|||
"Higher level section"_Intro.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Additional website links :h3
|
||||
|
||||
The "LAMMPS website"_lws has a variety of additional info about
|
||||
LAMMPS, beyond what is in this manual. Some of the other pages in
|
||||
this Intr are included in this list.
|
||||
|
||||
"Brief intro and recently added significant features"_lws
|
||||
"List of features"_http://lammps.sandia.gov/features.html
|
||||
"List of non-features"_http://lammps.sandia.gov/non_features.html
|
||||
"Recent bug fixes and new features"_http://lammps.sandia.gov/bug.html :ul
|
||||
|
||||
"Download info"_http://lammps.sandia.gov/download.html
|
||||
"GitHub site"_https://github.com/lammps/lammps
|
||||
"SourceForge site"_https://sourceforge.net/projects/lammps
|
||||
"LAMMPS open-source license"_http://lammps.sandia.gov/open_source.html :ul
|
||||
|
||||
"Glossary of MD terms relevant to LAMMPS"_http://lammps.sandia.gov/glossary.html
|
||||
"LAMMPS highlights with images"_http://lammps.sandia.gov/pictures.html
|
||||
"LAMMPS highlights with movies"_http://lammps.sandia.gov/movies.html
|
||||
"Mail list"_http://lammps.sandia.gov/mail.html
|
||||
"Workshops"_http://lammps.sandia.gov/workshops.html
|
||||
"Tutorials"_http://lammps.sandia.gov/tutorials.html
|
||||
"Developer guide"_http://lammps.sandia.gov/Developer.pdf :ul
|
||||
|
||||
"Pre- and post-processing tools for LAMMPS"_http://lammps.sandia.gov/prepost.html
|
||||
"Other software usable with LAMMPS"_http://lammps.sandia.gov/offsite.html
|
||||
"Viz tools usable with LAMMPS"_http://lammps.sandia.gov/viz.html :ul
|
||||
|
||||
"Benchmark performance"_http://lammps.sandia.gov/bench.html
|
||||
"Publications that have cited LAMMPS"_http://lammps.sandia.gov/papers.html
|
||||
"Authors of LAMMPS"_http://lammps.sandia.gov/authors.html
|
||||
"History of LAMMPS development"_http://lammps.sandia.gov/history.html
|
||||
"Funding for LAMMPS"_http://lammps.sandia.gov/funding.html :ul
|
|
@ -1,33 +0,0 @@
|
|||
"Higher level section"_Manual.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
What does a LAMMPS version mean :h3
|
||||
|
||||
The LAMMPS "version" is the date when it was released, such as 1 May
|
||||
2014. LAMMPS is updated continuously. Whenever we fix a bug or add a
|
||||
feature, we release it in the next {patch} release, which are
|
||||
typically made every couple of weeks. Info on patch releases are on
|
||||
"this website page"_http://lammps.sandia.gov/bug.html. Every few
|
||||
months, the latest patch release is subjected to more thorough testing
|
||||
and labeled as a {stable} version.
|
||||
|
||||
Each version of LAMMPS contains all the features and bug-fixes up to
|
||||
and including its version date.
|
||||
|
||||
The version date is printed to the screen and logfile every time you
|
||||
run LAMMPS. It is also in the file src/version.h and in the LAMMPS
|
||||
directory name created when you unpack a tarball. And it is on the
|
||||
first page of the "manual"_Manual.html.
|
||||
|
||||
If you browse the HTML doc pages on the LAMMPS WWW site, they always
|
||||
describe the most current patch release of LAMMPS. :ulb,l
|
||||
|
||||
If you browse the HTML doc pages included in your tarball, they
|
||||
describe the version you have, which may be older. :l,ule
|
||||
|
|
@ -1,70 +0,0 @@
|
|||
"Previous Section"_Tools.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
|
||||
Section"_Python_head.html :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Modify & extend LAMMPS :h2
|
||||
|
||||
LAMMPS is designed in a modular fashion so as to be easy to modify and
|
||||
extend with new functionality. In fact, about 95% of its source code
|
||||
is add-on files. These doc pages give basic instructions on how to do
|
||||
this.
|
||||
|
||||
If you add a new feature to LAMMPS and think it will be of interest to
|
||||
general users, we encourage you to submit it for inclusion in LAMMPS
|
||||
as a pull request on our "GitHub
|
||||
site"_https://github.com/lammps/lammps, after reading the "Modify
|
||||
contribute"_Modify_contribute.html doc page.
|
||||
|
||||
<!-- RST
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
Modify_overview
|
||||
Modify_contribute
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
Modify_atom
|
||||
Modify_pair
|
||||
Modify_bond
|
||||
Modify_compute
|
||||
Modify_fix
|
||||
Modify_command
|
||||
Modify_dump
|
||||
Modify_kspace
|
||||
Modify_min
|
||||
Modify_region
|
||||
Modify_body
|
||||
Modify_thermo
|
||||
Modify_variable
|
||||
|
||||
END_RST -->
|
||||
|
||||
<!-- HTML_ONLY -->
|
||||
|
||||
"Overview"_Modify_overview.html
|
||||
"Submitting new features for inclusion in LAMMPS"_Modify_contribute.html :all(b)
|
||||
|
||||
"Atom styles"_Modify_atom.html
|
||||
"Pair styles"_Modify_pair.html
|
||||
"Bond, angle, dihedral, improper styles"_Modify_bond.html
|
||||
"Compute styles"_Modify_compute.html
|
||||
"Fix styles"_Modify_fix.html
|
||||
"Input script command styles"_Modify_command.html
|
||||
"Dump styles"_Modify_dump.html
|
||||
"Kspace styles"_Modify_kspace.html
|
||||
"Minimization styles"_Modify_min.html
|
||||
"Region styles"_Modify_region.html
|
||||
"Body styles"_Modify_body.html
|
||||
"Thermodynamic output options"_Modify_thermo.html
|
||||
"Variable options"_Modify_variable.html :all(b)
|
||||
|
||||
<!-- END_HTML_ONLY -->
|
|
@ -1,90 +0,0 @@
|
|||
"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Atom styles :h3
|
||||
|
||||
Classes that define an "atom style"_atom_style.html are derived from
|
||||
the AtomVec class and managed by the Atom class. The atom style
|
||||
determines what attributes are associated with an atom. A new atom
|
||||
style can be created if one of the existing atom styles does not
|
||||
define all the attributes you need to store and communicate with
|
||||
atoms.
|
||||
|
||||
Atom_vec_atomic.cpp is a simple example of an atom style.
|
||||
|
||||
Here is a brief description of methods you define in your new derived
|
||||
class. See atom_vec.h for details.
|
||||
|
||||
init: one time setup (optional)
|
||||
grow: re-allocate atom arrays to longer lengths (required)
|
||||
grow_reset: make array pointers in Atom and AtomVec classes consistent (required)
|
||||
copy: copy info for one atom to another atom's array locations (required)
|
||||
pack_comm: store an atom's info in a buffer communicated every timestep (required)
|
||||
pack_comm_vel: add velocity info to communication buffer (required)
|
||||
pack_comm_hybrid: store extra info unique to this atom style (optional)
|
||||
unpack_comm: retrieve an atom's info from the buffer (required)
|
||||
unpack_comm_vel: also retrieve velocity info (required)
|
||||
unpack_comm_hybrid: retrieve extra info unique to this atom style (optional)
|
||||
pack_reverse: store an atom's info in a buffer communicating partial forces (required)
|
||||
pack_reverse_hybrid: store extra info unique to this atom style (optional)
|
||||
unpack_reverse: retrieve an atom's info from the buffer (required)
|
||||
unpack_reverse_hybrid: retrieve extra info unique to this atom style (optional)
|
||||
pack_border: store an atom's info in a buffer communicated on neighbor re-builds (required)
|
||||
pack_border_vel: add velocity info to buffer (required)
|
||||
pack_border_hybrid: store extra info unique to this atom style (optional)
|
||||
unpack_border: retrieve an atom's info from the buffer (required)
|
||||
unpack_border_vel: also retrieve velocity info (required)
|
||||
unpack_border_hybrid: retrieve extra info unique to this atom style (optional)
|
||||
pack_exchange: store all an atom's info to migrate to another processor (required)
|
||||
unpack_exchange: retrieve an atom's info from the buffer (required)
|
||||
size_restart: number of restart quantities associated with proc's atoms (required)
|
||||
pack_restart: pack atom quantities into a buffer (required)
|
||||
unpack_restart: unpack atom quantities from a buffer (required)
|
||||
create_atom: create an individual atom of this style (required)
|
||||
data_atom: parse an atom line from the data file (required)
|
||||
data_atom_hybrid: parse additional atom info unique to this atom style (optional)
|
||||
data_vel: parse one line of velocity information from data file (optional)
|
||||
data_vel_hybrid: parse additional velocity data unique to this atom style (optional)
|
||||
memory_usage: tally memory allocated by atom arrays (required) :tb(s=:)
|
||||
|
||||
The constructor of the derived class sets values for several variables
|
||||
that you must set when defining a new atom style, which are documented
|
||||
in atom_vec.h. New atom arrays are defined in atom.cpp. Search for
|
||||
the word "customize" and you will find locations you will need to
|
||||
modify.
|
||||
|
||||
NOTE: It is possible to add some attributes, such as a molecule ID, to
|
||||
atom styles that do not have them via the "fix
|
||||
property/atom"_fix_property_atom.html command. This command also
|
||||
allows new custom attributes consisting of extra integer or
|
||||
floating-point values to be added to atoms. See the "fix
|
||||
property/atom"_fix_property_atom.html doc page for examples of cases
|
||||
where this is useful and details on how to initialize, access, and
|
||||
output the custom values.
|
||||
|
||||
New "pair styles"_pair_style.html, "fixes"_fix.html, or
|
||||
"computes"_compute.html can be added to LAMMPS, as discussed below.
|
||||
The code for these classes can use the per-atom properties defined by
|
||||
fix property/atom. The Atom class has a find_custom() method that is
|
||||
useful in this context:
|
||||
|
||||
int index = atom->find_custom(char *name, int &flag); :pre
|
||||
|
||||
The "name" of a custom attribute, as specified in the "fix
|
||||
property/atom"_fix_property_atom.html command, is checked to verify
|
||||
that it exists and its index is returned. The method also sets flag =
|
||||
0/1 depending on whether it is an integer or floating-point attribute.
|
||||
The vector of values associated with the attribute can then be
|
||||
accessed using the returned index as
|
||||
|
||||
int *ivector = atom->ivector\[index\];
|
||||
double *dvector = atom->dvector\[index\]; :pre
|
||||
|
||||
Ivector or dvector are vectors of length Nlocal = # of owned atoms,
|
||||
which store the attributes of individual atoms.
|
|
@ -1,34 +0,0 @@
|
|||
"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Body styles :h3
|
||||
|
||||
Classes that define body particles are derived from the Body class.
|
||||
Body particles can represent complex entities, such as surface meshes
|
||||
of discrete points, collections of sub-particles, deformable objects,
|
||||
etc.
|
||||
|
||||
See the "Howto body"_Howto_body.html doc page for an overview of using
|
||||
body particles and the various body styles LAMMPS supports. New
|
||||
styles can be created to add new kinds of body particles to LAMMPS.
|
||||
|
||||
Body_nparticle.cpp is an example of a body particle that is treated as
|
||||
a rigid body containing N sub-particles.
|
||||
|
||||
Here is a brief description of methods you define in your new derived
|
||||
class. See body.h for details.
|
||||
|
||||
data_body: process a line from the Bodies section of a data file
|
||||
noutrow: number of sub-particles output is generated for
|
||||
noutcol: number of values per-sub-particle output is generated for
|
||||
output: output values for the Mth sub-particle
|
||||
pack_comm_body: body attributes to communicate every timestep
|
||||
unpack_comm_body: unpacking of those attributes
|
||||
pack_border_body: body attributes to communicate when reneighboring is done
|
||||
unpack_border_body: unpacking of those attributes :tb(s=:)
|
|
@ -1,33 +0,0 @@
|
|||
"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Bond, angle, dihedral, improper styles :h3
|
||||
|
||||
Classes that compute molecular interactions are derived from the Bond,
|
||||
Angle, Dihedral, and Improper classes. New styles can be created to
|
||||
add new potentials to LAMMPS.
|
||||
|
||||
Bond_harmonic.cpp is the simplest example of a bond style. Ditto for
|
||||
the harmonic forms of the angle, dihedral, and improper style
|
||||
commands.
|
||||
|
||||
Here is a brief description of common methods you define in your
|
||||
new derived class. See bond.h, angle.h, dihedral.h, and improper.h
|
||||
for details and specific additional methods.
|
||||
|
||||
init: check if all coefficients are set, calls {init_style} (optional)
|
||||
init_style: check if style specific conditions are met (optional)
|
||||
compute: compute the molecular interactions (required)
|
||||
settings: apply global settings for all types (optional)
|
||||
coeff: set coefficients for one type (required)
|
||||
equilibrium_distance: length of bond, used by SHAKE (required, bond only)
|
||||
equilibrium_angle: opening of angle, used by SHAKE (required, angle only)
|
||||
write & read_restart: writes/reads coeffs to restart files (required)
|
||||
single: force and energy of a single bond or angle (required, bond or angle only)
|
||||
memory_usage: tally memory allocated by the style (optional) :tb(s=:)
|
|
@ -1,27 +0,0 @@
|
|||
"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Input script command style :h3
|
||||
|
||||
New commands can be added to LAMMPS input scripts by adding new
|
||||
classes that have a "command" method. For example, the create_atoms,
|
||||
read_data, velocity, and run commands are all implemented in this
|
||||
fashion. When such a command is encountered in the LAMMPS input
|
||||
script, LAMMPS simply creates a class with the corresponding name,
|
||||
invokes the "command" method of the class, and passes it the arguments
|
||||
from the input script. The command method can perform whatever
|
||||
operations it wishes on LAMMPS data structures.
|
||||
|
||||
The single method your new class must define is as follows:
|
||||
|
||||
command: operations performed by the new command :tb(s=:)
|
||||
|
||||
Of course, the new class can define other methods and variables as
|
||||
needed.
|
||||
|
|
@ -1,49 +0,0 @@
|
|||
"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Compute styles :h3
|
||||
|
||||
Classes that compute scalar and vector quantities like temperature
|
||||
and the pressure tensor, as well as classes that compute per-atom
|
||||
quantities like kinetic energy and the centro-symmetry parameter
|
||||
are derived from the Compute class. New styles can be created
|
||||
to add new calculations to LAMMPS.
|
||||
|
||||
Compute_temp.cpp is a simple example of computing a scalar
|
||||
temperature. Compute_ke_atom.cpp is a simple example of computing
|
||||
per-atom kinetic energy.
|
||||
|
||||
Here is a brief description of methods you define in your new derived
|
||||
class. See compute.h for details.
|
||||
|
||||
init: perform one time setup (required)
|
||||
init_list: neighbor list setup, if needed (optional)
|
||||
compute_scalar: compute a scalar quantity (optional)
|
||||
compute_vector: compute a vector of quantities (optional)
|
||||
compute_peratom: compute one or more quantities per atom (optional)
|
||||
compute_local: compute one or more quantities per processor (optional)
|
||||
pack_comm: pack a buffer with items to communicate (optional)
|
||||
unpack_comm: unpack the buffer (optional)
|
||||
pack_reverse: pack a buffer with items to reverse communicate (optional)
|
||||
unpack_reverse: unpack the buffer (optional)
|
||||
remove_bias: remove velocity bias from one atom (optional)
|
||||
remove_bias_all: remove velocity bias from all atoms in group (optional)
|
||||
restore_bias: restore velocity bias for one atom after remove_bias (optional)
|
||||
restore_bias_all: same as before, but for all atoms in group (optional)
|
||||
pair_tally_callback: callback function for {tally}-style computes (optional).
|
||||
memory_usage: tally memory usage (optional) :tb(s=:)
|
||||
|
||||
Tally-style computes are a special case, as their computation is done
|
||||
in two stages: the callback function is registered with the pair style
|
||||
and then called from the Pair::ev_tally() function, which is called for
|
||||
each pair after force and energy has been computed for this pair. Then
|
||||
the tallied values are retrieved with the standard compute_scalar or
|
||||
compute_vector or compute_peratom methods. The USER-TALLY package
|
||||
provides {examples}_compute_tally.html for utilizing this mechanism.
|
||||
|
|
@ -1,216 +0,0 @@
|
|||
"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Submitting new features for inclusion in LAMMPS :h3
|
||||
|
||||
We encourage users to submit new features or modifications for LAMMPS
|
||||
to "the core developers"_http://lammps.sandia.gov/authors.html so they
|
||||
can be added to the LAMMPS distribution. The preferred way to manage
|
||||
and coordinate this is as of Fall 2016 via the LAMMPS project on
|
||||
"GitHub"_https://github.com/lammps/lammps. An alternative is to
|
||||
contact the LAMMPS developers or the indicated developer of a package
|
||||
or feature directly and send in your contribution via e-mail.
|
||||
|
||||
For any larger modifications or programming project, you are
|
||||
encouraged to contact the LAMMPS developers ahead of time, in order to
|
||||
discuss implementation strategies and coding guidelines, that will
|
||||
make it easier to integrate your contribution and result in less work
|
||||
for everybody involved. You are also encouraged to search through the
|
||||
list of "open issues on
|
||||
GitHub"_https://github.com/lammps/lammps/issues and submit a new issue
|
||||
for a planned feature, so you would not duplicate the work of others
|
||||
(and possibly get scooped by them) or have your work duplicated by
|
||||
others.
|
||||
|
||||
How quickly your contribution will be integrated depends largely on
|
||||
how much effort it will cause to integrate and test it, how much it
|
||||
requires changes to the core codebase, and of how much interest it is
|
||||
to the larger LAMMPS community. Please see below for a checklist of
|
||||
typical requirements. Once you have prepared everything, see the
|
||||
"Using GitHub with LAMMPS Howto"_Howto_github.html doc page for instructions on how to
|
||||
submit your changes or new files through a GitHub pull request. If you
|
||||
prefer to submit patches or full files, you should first make certain,
|
||||
that your code works correctly with the latest patch-level version of
|
||||
LAMMPS and contains all bug fixes from it. Then create a gzipped tar
|
||||
file of all changed or added files or a corresponding patch file using
|
||||
'diff -u' or 'diff -c' and compress it with gzip. Please only use gzip
|
||||
compression, as this works well on all platforms.
|
||||
|
||||
If the new features/files are broadly useful we may add them as core
|
||||
files to LAMMPS or as part of a "standard
|
||||
package"_Packages_standard.html. Else we will add them as a
|
||||
user-contributed file or "user package"_Packages_user.html. Examples
|
||||
of user packages are in src sub-directories that start with USER. The
|
||||
USER-MISC package is simply a collection of (mostly) unrelated single
|
||||
files, which is the simplest way to have your contribution quickly
|
||||
added to the LAMMPS distribution. All the standard and user packages
|
||||
are listed and described on the "Packages
|
||||
details"_Packages_details.html doc page.
|
||||
|
||||
Note that by providing us files to release, you are agreeing to make
|
||||
them open-source, i.e. we can release them under the terms of the GPL,
|
||||
used as a license for the rest of LAMMPS. See the "Open
|
||||
source"_http://lammps.sandia.gov/open_source.html page on the LAMMPS
|
||||
website for details.
|
||||
|
||||
With user packages and files, all we are really providing (aside from
|
||||
the fame and fortune that accompanies having your name in the source
|
||||
code and on the "Authors page"_http://lammps.sandia.gov/authors.html
|
||||
of the "LAMMPS WWW site"_lws), is a means for you to distribute your
|
||||
work to the LAMMPS user community, and a mechanism for others to
|
||||
easily try out your new feature. This may help you find bugs or make
|
||||
contact with new collaborators. Note that you're also implicitly
|
||||
agreeing to support your code which means answer questions, fix bugs,
|
||||
and maintain it if LAMMPS changes in some way that breaks it (an
|
||||
unusual event).
|
||||
|
||||
NOTE: If you prefer to actively develop and support your add-on
|
||||
feature yourself, then you may wish to make it available for download
|
||||
from your own website, as a user package that LAMMPS users can add to
|
||||
their copy of LAMMPS. See the "Offsite LAMMPS packages and
|
||||
tools"_http://lammps.sandia.gov/offsite.html page of the LAMMPS web
|
||||
site for examples of groups that do this. We are happy to advertise
|
||||
your package and web site from that page. Simply email the
|
||||
"developers"_http://lammps.sandia.gov/authors.html with info about
|
||||
your package and we will post it there.
|
||||
|
||||
The previous sections of this doc page describe how to add new "style"
|
||||
files of various kinds to LAMMPS. Packages are simply collections of
|
||||
one or more new class files which are invoked as a new style within a
|
||||
LAMMPS input script. If designed correctly, these additions typically
|
||||
do not require changes to the main core of LAMMPS; they are simply
|
||||
add-on files. If you think your new feature requires non-trivial
|
||||
changes in core LAMMPS files, you'll need to "communicate with the
|
||||
developers"_http://lammps.sandia.gov/authors.html, since we may or may
|
||||
not want to make those changes. An example of a trivial change is
|
||||
making a parent-class method "virtual" when you derive a new child
|
||||
class from it.
|
||||
|
||||
Here is a checklist of steps you need to follow to submit a single file
|
||||
or user package for our consideration. Following these steps will save
|
||||
both you and us time. See existing files in packages in the src dir for
|
||||
examples. If you are uncertain, please ask.
|
||||
|
||||
All source files you provide must compile with the most current
|
||||
version of LAMMPS with multiple configurations. In particular you
|
||||
need to test compiling LAMMPS from scratch with -DLAMMPS_BIGBIG
|
||||
set in addition to the default -DLAMMPS_SMALLBIG setting. Your code
|
||||
will need to work correctly in serial and in parallel using MPI. :ulb,l
|
||||
|
||||
For consistency with the rest of LAMMPS and especially, if you want
|
||||
your contribution(s) to be added to main LAMMPS code or one of its
|
||||
standard packages, it needs to be written in a style compatible with
|
||||
other LAMMPS source files. This means: 2-character indentation per
|
||||
level, [no tabs], no lines over 80 characters. I/O is done via
|
||||
the C-style stdio library (mixing of stdio and iostreams is generally
|
||||
discouraged), class header files should not import any system headers
|
||||
outside of <cstdio>, STL containers should be avoided in headers,
|
||||
system header from the C library should use the C++-style names
|
||||
(<cstdlib>, <cstdio>, or <cstring>) instead of the C-style names
|
||||
<stdlib.h>, <stdio.h>, or <string.h>), and forward declarations
|
||||
used where possible or needed to avoid including headers.
|
||||
All added code should be placed into the LAMMPS_NS namespace or a
|
||||
sub-namespace; global or static variables should be avoided, as they
|
||||
conflict with the modular nature of LAMMPS and the C++ class structure.
|
||||
Header files must [not] import namespaces with {using}.
|
||||
This all is so the developers can more easily understand, integrate,
|
||||
and maintain your contribution and reduce conflicts with other parts
|
||||
of LAMMPS. This basically means that the code accesses data
|
||||
structures, performs its operations, and is formatted similar to other
|
||||
LAMMPS source files, including the use of the error class for error
|
||||
and warning messages. :l
|
||||
|
||||
If you want your contribution to be added as a user-contributed
|
||||
feature, and it's a single file (actually a *.cpp and *.h file) it can
|
||||
rapidly be added to the USER-MISC directory. Send us the one-line
|
||||
entry to add to the USER-MISC/README file in that dir, along with the
|
||||
2 source files. You can do this multiple times if you wish to
|
||||
contribute several individual features. :l
|
||||
|
||||
If you want your contribution to be added as a user-contribution and
|
||||
it is several related features, it is probably best to make it a user
|
||||
package directory with a name like USER-FOO. In addition to your new
|
||||
files, the directory should contain a README text file. The README
|
||||
should contain your name and contact information and a brief
|
||||
description of what your new package does. If your files depend on
|
||||
other LAMMPS style files also being installed (e.g. because your file
|
||||
is a derived class from the other LAMMPS class), then an Install.sh
|
||||
file is also needed to check for those dependencies. See other README
|
||||
and Install.sh files in other USER directories as examples. Send us a
|
||||
tarball of this USER-FOO directory. :l
|
||||
|
||||
Your new source files need to have the LAMMPS copyright, GPL notice,
|
||||
and your name and email address at the top, like other
|
||||
user-contributed LAMMPS source files. They need to create a class
|
||||
that is inside the LAMMPS namespace. If the file is for one of the
|
||||
|
||||
USER packages, including USER-MISC, then we are not as picky about the
|
||||
coding style (see above). I.e. the files do not need to be in the
|
||||
same stylistic format and syntax as other LAMMPS files, though that
|
||||
would be nice for developers as well as users who try to read your
|
||||
code. :l
|
||||
|
||||
You [must] also create a [documentation] file for each new command or
|
||||
style you are adding to LAMMPS. For simplicity and convenience, the
|
||||
documentation of groups of closely related commands or styles may be
|
||||
combined into a single file. This will be one file for a single-file
|
||||
feature. For a package, it might be several files. These are simple
|
||||
text files with a specific markup language, that are then auto-converted
|
||||
to HTML and PDF. The tools for this conversion are included in the
|
||||
source distribution, and the translation can be as simple as doing
|
||||
"make html pdf" in the doc folder.
|
||||
Thus the documentation source files must be in the same format and
|
||||
style as other *.txt files in the lammps/doc/src directory for similar
|
||||
commands and styles; use one or more of them as a starting point.
|
||||
A description of the markup can also be found in
|
||||
lammps/doc/utils/txt2html/README.html
|
||||
As appropriate, the text files can include links to equations
|
||||
(see doc/Eqs/*.tex for examples, we auto-create the associated JPG
|
||||
files), or figures (see doc/JPG for examples), or even additional PDF
|
||||
files with further details (see doc/PDF for examples). The doc page
|
||||
should also include literature citations as appropriate; see the
|
||||
bottom of doc/fix_nh.txt for examples and the earlier part of the same
|
||||
file for how to format the cite itself. The "Restrictions" section of
|
||||
the doc page should indicate that your command is only available if
|
||||
LAMMPS is built with the appropriate USER-MISC or USER-FOO package.
|
||||
See other user package doc files for examples of how to do this. The
|
||||
prerequisite for building the HTML format files are Python 3.x and
|
||||
virtualenv, the requirement for generating the PDF format manual
|
||||
is the "htmldoc"_http://www.htmldoc.org/ software. Please run at least
|
||||
"make html" and carefully inspect and proofread the resulting HTML format
|
||||
doc page before submitting your code. :l
|
||||
|
||||
For a new package (or even a single command) you should include one or
|
||||
more example scripts demonstrating its use. These should run in no
|
||||
more than a couple minutes, even on a single processor, and not require
|
||||
large data files as input. See directories under examples/USER for
|
||||
examples of input scripts other users provided for their packages.
|
||||
These example inputs are also required for validating memory accesses
|
||||
and testing for memory leaks with valgrind :l
|
||||
|
||||
If there is a paper of yours describing your feature (either the
|
||||
algorithm/science behind the feature itself, or its initial usage, or
|
||||
its implementation in LAMMPS), you can add the citation to the *.cpp
|
||||
source file. See src/USER-EFF/atom_vec_electron.cpp for an example.
|
||||
A LaTeX citation is stored in a variable at the top of the file and a
|
||||
single line of code that references the variable is added to the
|
||||
constructor of the class. Whenever a user invokes your feature from
|
||||
their input script, this will cause LAMMPS to output the citation to a
|
||||
log.cite file and prompt the user to examine the file. Note that you
|
||||
should only use this for a paper you or your group authored.
|
||||
E.g. adding a cite in the code for a paper by Nose and Hoover if you
|
||||
write a fix that implements their integrator is not the intended
|
||||
usage. That kind of citation should just be in the doc page you
|
||||
provide. :l
|
||||
:ule
|
||||
|
||||
Finally, as a general rule-of-thumb, the more clear and
|
||||
self-explanatory you make your documentation and README files, and the
|
||||
easier you make it for people to get started, e.g. by providing example
|
||||
scripts, the more likely it is that users will try out your new feature.
|
|
@ -1,35 +0,0 @@
|
|||
"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Dump styles :h3
|
||||
|
||||
Classes that dump per-atom info to files are derived from the Dump
|
||||
class. To dump new quantities or in a new format, a new derived dump
|
||||
class can be added, but it is typically simpler to modify the
|
||||
DumpCustom class contained in the dump_custom.cpp file.
|
||||
|
||||
Dump_atom.cpp is a simple example of a derived dump class.
|
||||
|
||||
Here is a brief description of methods you define in your new derived
|
||||
class. See dump.h for details.
|
||||
|
||||
write_header: write the header section of a snapshot of atoms
|
||||
count: count the number of lines a processor will output
|
||||
pack: pack a proc's output data into a buffer
|
||||
write_data: write a proc's data to a file :tb(s=:)
|
||||
|
||||
See the "dump"_dump.html command and its {custom} style for a list of
|
||||
keywords for atom information that can already be dumped by
|
||||
DumpCustom. It includes options to dump per-atom info from Compute
|
||||
classes, so adding a new derived Compute class is one way to calculate
|
||||
new quantities to dump.
|
||||
|
||||
Note that new keywords for atom properties are not typically
|
||||
added to the "dump custom"_dump.html command. Instead they are added
|
||||
to the "compute property/atom"_compute_property_atom.html command.
|
|
@ -1,107 +0,0 @@
|
|||
"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Fix styles :h3
|
||||
|
||||
In LAMMPS, a "fix" is any operation that is computed during
|
||||
timestepping that alters some property of the system. Essentially
|
||||
everything that happens during a simulation besides force computation,
|
||||
neighbor list construction, and output, is a "fix". This includes
|
||||
time integration (update of coordinates and velocities), force
|
||||
constraints or boundary conditions (SHAKE or walls), and diagnostics
|
||||
(compute a diffusion coefficient). New styles can be created to add
|
||||
new options to LAMMPS.
|
||||
|
||||
Fix_setforce.cpp is a simple example of setting forces on atoms to
|
||||
prescribed values. There are dozens of fix options already in LAMMPS;
|
||||
choose one as a template that is similar to what you want to
|
||||
implement.
|
||||
|
||||
Here is a brief description of methods you can define in your new
|
||||
derived class. See fix.h for details.
|
||||
|
||||
setmask: determines when the fix is called during the timestep (required)
|
||||
init: initialization before a run (optional)
|
||||
setup_pre_exchange: called before atom exchange in setup (optional)
|
||||
setup_pre_force: called before force computation in setup (optional)
|
||||
setup: called immediately before the 1st timestep and after forces are computed (optional)
|
||||
min_setup_pre_force: like setup_pre_force, but for minimizations instead of MD runs (optional)
|
||||
min_setup: like setup, but for minimizations instead of MD runs (optional)
|
||||
initial_integrate: called at very beginning of each timestep (optional)
|
||||
pre_exchange: called before atom exchange on re-neighboring steps (optional)
|
||||
pre_neighbor: called before neighbor list build (optional)
|
||||
pre_force: called before pair & molecular forces are computed (optional)
|
||||
post_force: called after pair & molecular forces are computed and communicated (optional)
|
||||
final_integrate: called at end of each timestep (optional)
|
||||
end_of_step: called at very end of timestep (optional)
|
||||
write_restart: dumps fix info to restart file (optional)
|
||||
restart: uses info from restart file to re-initialize the fix (optional)
|
||||
grow_arrays: allocate memory for atom-based arrays used by fix (optional)
|
||||
copy_arrays: copy atom info when an atom migrates to a new processor (optional)
|
||||
pack_exchange: store atom's data in a buffer (optional)
|
||||
unpack_exchange: retrieve atom's data from a buffer (optional)
|
||||
pack_restart: store atom's data for writing to restart file (optional)
|
||||
unpack_restart: retrieve atom's data from a restart file buffer (optional)
|
||||
size_restart: size of atom's data (optional)
|
||||
maxsize_restart: max size of atom's data (optional)
|
||||
setup_pre_force_respa: same as setup_pre_force, but for rRESPA (optional)
|
||||
initial_integrate_respa: same as initial_integrate, but for rRESPA (optional)
|
||||
post_integrate_respa: called after the first half integration step is done in rRESPA (optional)
|
||||
pre_force_respa: same as pre_force, but for rRESPA (optional)
|
||||
post_force_respa: same as post_force, but for rRESPA (optional)
|
||||
final_integrate_respa: same as final_integrate, but for rRESPA (optional)
|
||||
min_pre_force: called after pair & molecular forces are computed in minimizer (optional)
|
||||
min_post_force: called after pair & molecular forces are computed and communicated in minimizer (optional)
|
||||
min_store: store extra data for linesearch based minimization on a LIFO stack (optional)
|
||||
min_pushstore: push the minimization LIFO stack one element down (optional)
|
||||
min_popstore: pop the minimization LIFO stack one element up (optional)
|
||||
min_clearstore: clear minimization LIFO stack (optional)
|
||||
min_step: reset or move forward on line search minimization (optional)
|
||||
min_dof: report number of degrees of freedom {added} by this fix in minimization (optional)
|
||||
max_alpha: report maximum allowed step size during linesearch minimization (optional)
|
||||
pack_comm: pack a buffer to communicate a per-atom quantity (optional)
|
||||
unpack_comm: unpack a buffer to communicate a per-atom quantity (optional)
|
||||
pack_reverse_comm: pack a buffer to reverse communicate a per-atom quantity (optional)
|
||||
unpack_reverse_comm: unpack a buffer to reverse communicate a per-atom quantity (optional)
|
||||
dof: report number of degrees of freedom {removed} by this fix during MD (optional)
|
||||
compute_scalar: return a global scalar property that the fix computes (optional)
|
||||
compute_vector: return a component of a vector property that the fix computes (optional)
|
||||
compute_array: return a component of an array property that the fix computes (optional)
|
||||
deform: called when the box size is changed (optional)
|
||||
reset_target: called when a change of the target temperature is requested during a run (optional)
|
||||
reset_dt: is called when a change of the time step is requested during a run (optional)
|
||||
modify_param: called when a fix_modify request is executed (optional)
|
||||
memory_usage: report memory used by fix (optional)
|
||||
thermo: compute quantities for thermodynamic output (optional) :tb(s=:)
|
||||
|
||||
Typically, only a small fraction of these methods are defined for a
|
||||
particular fix. Setmask is mandatory, as it determines when the fix
|
||||
will be invoked during the timestep. Fixes that perform time
|
||||
integration ({nve}, {nvt}, {npt}) implement initial_integrate() and
|
||||
final_integrate() to perform velocity Verlet updates. Fixes that
|
||||
constrain forces implement post_force().
|
||||
|
||||
Fixes that perform diagnostics typically implement end_of_step(). For
|
||||
an end_of_step fix, one of your fix arguments must be the variable
|
||||
"nevery" which is used to determine when to call the fix and you must
|
||||
set this variable in the constructor of your fix. By convention, this
|
||||
is the first argument the fix defines (after the ID, group-ID, style).
|
||||
|
||||
If the fix needs to store information for each atom that persists from
|
||||
timestep to timestep, it can manage that memory and migrate the info
|
||||
with the atoms as they move from processors to processor by
|
||||
implementing the grow_arrays, copy_arrays, pack_exchange, and
|
||||
unpack_exchange methods. Similarly, the pack_restart and
|
||||
unpack_restart methods can be implemented to store information about
|
||||
the fix in restart files. If you wish an integrator or force
|
||||
constraint fix to work with rRESPA (see the "run_style"_run_style.html
|
||||
command), the initial_integrate, post_force_integrate, and
|
||||
final_integrate_respa methods can be implemented. The thermo method
|
||||
enables a fix to contribute values to thermodynamic output, as printed
|
||||
quantities and/or to be summed to the potential energy of the system.
|
|
@ -1,25 +0,0 @@
|
|||
"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Kspace styles :h3
|
||||
|
||||
Classes that compute long-range Coulombic interactions via K-space
|
||||
representations (Ewald, PPPM) are derived from the KSpace class. New
|
||||
styles can be created to add new K-space options to LAMMPS.
|
||||
|
||||
Ewald.cpp is an example of computing K-space interactions.
|
||||
|
||||
Here is a brief description of methods you define in your new derived
|
||||
class. See kspace.h for details.
|
||||
|
||||
init: initialize the calculation before a run
|
||||
setup: computation before the 1st timestep of a run
|
||||
compute: every-timestep computation
|
||||
memory_usage: tally of memory usage :tb(s=:)
|
||||
|
|
@ -1,23 +0,0 @@
|
|||
"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Minimization styles :h3
|
||||
|
||||
Classes that perform energy minimization derived from the Min class.
|
||||
New styles can be created to add new minimization algorithms to
|
||||
LAMMPS.
|
||||
|
||||
Min_cg.cpp is an example of conjugate gradient minimization.
|
||||
|
||||
Here is a brief description of methods you define in your new derived
|
||||
class. See min.h for details.
|
||||
|
||||
init: initialize the minimization before a run
|
||||
run: perform the minimization
|
||||
memory_usage: tally of memory usage :tb(s=:)
|
|
@ -1,101 +0,0 @@
|
|||
"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Overview :h3
|
||||
|
||||
The best way to add a new feature to LAMMPS is to find a similar
|
||||
feature and look at the corresponding source and header files to figure
|
||||
out what it does. You will need some knowledge of C++ to be able to
|
||||
understand the hi-level structure of LAMMPS and its class
|
||||
organization, but functions (class methods) that do actual
|
||||
computations are written in vanilla C-style code and operate on simple
|
||||
C-style data structures (vectors and arrays).
|
||||
|
||||
Most of the new features described on the "Modify"_Modify.html doc
|
||||
page require you to write a new C++ derived class (except for
|
||||
exceptions described below, where you can make small edits to existing
|
||||
files). Creating a new class requires 2 files, a source code file
|
||||
(*.cpp) and a header file (*.h). The derived class must provide
|
||||
certain methods to work as a new option. Depending on how different
|
||||
your new feature is compared to existing features, you can either
|
||||
derive from the base class itself, or from a derived class that
|
||||
already exists. Enabling LAMMPS to invoke the new class is as simple
|
||||
as putting the two source files in the src dir and re-building LAMMPS.
|
||||
|
||||
The advantage of C++ and its object-orientation is that all the code
|
||||
and variables needed to define the new feature are in the 2 files you
|
||||
write, and thus shouldn't make the rest of LAMMPS more complex or
|
||||
cause side-effect bugs.
|
||||
|
||||
Here is a concrete example. Suppose you write 2 files pair_foo.cpp
|
||||
and pair_foo.h that define a new class PairFoo that computes pairwise
|
||||
potentials described in the classic 1997 "paper"_#Foo by Foo, et al.
|
||||
If you wish to invoke those potentials in a LAMMPS input script with a
|
||||
command like
|
||||
|
||||
pair_style foo 0.1 3.5 :pre
|
||||
|
||||
then your pair_foo.h file should be structured as follows:
|
||||
|
||||
#ifdef PAIR_CLASS
|
||||
PairStyle(foo,PairFoo)
|
||||
#else
|
||||
...
|
||||
(class definition for PairFoo)
|
||||
...
|
||||
#endif :pre
|
||||
|
||||
where "foo" is the style keyword in the pair_style command, and
|
||||
PairFoo is the class name defined in your pair_foo.cpp and pair_foo.h
|
||||
files.
|
||||
|
||||
When you re-build LAMMPS, your new pairwise potential becomes part of
|
||||
the executable and can be invoked with a pair_style command like the
|
||||
example above. Arguments like 0.1 and 3.5 can be defined and
|
||||
processed by your new class.
|
||||
|
||||
As illustrated by this pairwise example, many kinds of options are
|
||||
referred to in the LAMMPS documentation as the "style" of a particular
|
||||
command.
|
||||
|
||||
The "Modify page"_Modify.html lists all the common styles in LAMMPS,
|
||||
and discusses the header file for the base class that these styles are
|
||||
derived from. Public variables in that file are ones used and set by
|
||||
the derived classes which are also used by the base class. Sometimes
|
||||
they are also used by the rest of LAMMPS. Virtual functions in the
|
||||
base class header file which are set = 0 are ones you must define in
|
||||
your new derived class to give it the functionality LAMMPS expects.
|
||||
Virtual functions that are not set to 0 are functions you can
|
||||
optionally define.
|
||||
|
||||
Additionally, new output options can be added directly to the
|
||||
thermo.cpp, dump_custom.cpp, and variable.cpp files. These are also
|
||||
listed on the "Modify page"_Modify.html.
|
||||
|
||||
Here are additional guidelines for modifying LAMMPS and adding new
|
||||
functionality:
|
||||
|
||||
Think about whether what you want to do would be better as a pre- or
|
||||
post-processing step. Many computations are more easily and more
|
||||
quickly done that way. :ulb,l
|
||||
|
||||
Don't do anything within the timestepping of a run that isn't
|
||||
parallel. E.g. don't accumulate a bunch of data on a single processor
|
||||
and analyze it. You run the risk of seriously degrading the parallel
|
||||
efficiency. :l
|
||||
|
||||
If your new feature reads arguments or writes output, make sure you
|
||||
follow the unit conventions discussed by the "units"_units.html
|
||||
command. :l
|
||||
:ule
|
||||
|
||||
:line
|
||||
|
||||
:link(Foo)
|
||||
[(Foo)] Foo, Morefoo, and Maxfoo, J of Classic Potentials, 75, 345 (1997).
|
|
@ -1,33 +0,0 @@
|
|||
"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Pair styles :h3
|
||||
|
||||
Classes that compute pairwise interactions are derived from the Pair
|
||||
class. In LAMMPS, pairwise calculation include many-body potentials
|
||||
such as EAM or Tersoff where particles interact without a static bond
|
||||
topology. New styles can be created to add new pair potentials to
|
||||
LAMMPS.
|
||||
|
||||
Pair_lj_cut.cpp is a simple example of a Pair class, though it
|
||||
includes some optional methods to enable its use with rRESPA.
|
||||
|
||||
Here is a brief description of the class methods in pair.h:
|
||||
|
||||
compute: workhorse routine that computes pairwise interactions
|
||||
settings: reads the input script line with arguments you define
|
||||
coeff: set coefficients for one i,j type pair
|
||||
init_one: perform initialization for one i,j type pair
|
||||
init_style: initialization specific to this pair style
|
||||
write & read_restart: write/read i,j pair coeffs to restart files
|
||||
write & read_restart_settings: write/read global settings to restart files
|
||||
single: force and energy of a single pairwise interaction between 2 atoms
|
||||
compute_inner/middle/outer: versions of compute used by rRESPA :tb(s=:)
|
||||
|
||||
The inner/middle/outer routines are optional.
|
|
@ -1,25 +0,0 @@
|
|||
"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Region styles :h3
|
||||
|
||||
Classes that define geometric regions are derived from the Region
|
||||
class. Regions are used elsewhere in LAMMPS to group atoms, delete
|
||||
atoms to create a void, insert atoms in a specified region, etc. New
|
||||
styles can be created to add new region shapes to LAMMPS.
|
||||
|
||||
Region_sphere.cpp is an example of a spherical region.
|
||||
|
||||
Here is a brief description of methods you define in your new derived
|
||||
class. See region.h for details.
|
||||
|
||||
inside: determine whether a point is in the region
|
||||
surface_interior: determine if a point is within a cutoff distance inside of surface
|
||||
surface_exterior: determine if a point is within a cutoff distance outside of surface
|
||||
shape_update : change region shape if set by time-dependent variable :tb(s=:)
|
|
@ -1,35 +0,0 @@
|
|||
"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Thermodynamic output options :h3
|
||||
|
||||
There is one class that computes and prints thermodynamic information
|
||||
to the screen and log file; see the file thermo.cpp.
|
||||
|
||||
There are two styles defined in thermo.cpp: "one" and "multi". There
|
||||
is also a flexible "custom" style which allows the user to explicitly
|
||||
list keywords for quantities to print when thermodynamic info is
|
||||
output. See the "thermo_style"_thermo_style.html command for a list
|
||||
of defined quantities.
|
||||
|
||||
The thermo styles (one, multi, etc) are simply lists of keywords.
|
||||
Adding a new style thus only requires defining a new list of keywords.
|
||||
Search for the word "customize" with references to "thermo style" in
|
||||
thermo.cpp to see the two locations where code will need to be added.
|
||||
|
||||
New keywords can also be added to thermo.cpp to compute new quantities
|
||||
for output. Search for the word "customize" with references to
|
||||
"keyword" in thermo.cpp to see the several locations where code will
|
||||
need to be added.
|
||||
|
||||
Note that the "thermo_style custom"_thermo.html command already allows
|
||||
for thermo output of quantities calculated by "fixes"_fix.html,
|
||||
"computes"_compute.html, and "variables"_variable.html. Thus, it may
|
||||
be simpler to compute what you wish via one of those constructs, than
|
||||
by adding a new keyword to the thermo command.
|
|
@ -1,46 +0,0 @@
|
|||
"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Variable options :h3
|
||||
|
||||
There is one class that computes and stores "variable"_variable.html
|
||||
information in LAMMPS; see the file variable.cpp. The value
|
||||
associated with a variable can be periodically printed to the screen
|
||||
via the "print"_print.html, "fix print"_fix_print.html, or
|
||||
"thermo_style custom"_thermo_style.html commands. Variables of style
|
||||
"equal" can compute complex equations that involve the following types
|
||||
of arguments:
|
||||
|
||||
thermo keywords = ke, vol, atoms, ...
|
||||
other variables = v_a, v_myvar, ...
|
||||
math functions = div(x,y), mult(x,y), add(x,y), ...
|
||||
group functions = mass(group), xcm(group,x), ...
|
||||
atom values = x\[123\], y\[3\], vx\[34\], ...
|
||||
compute values = c_mytemp\[0\], c_thermo_press\[3\], ... :pre
|
||||
|
||||
Adding keywords for the "thermo_style custom"_thermo_style.html
|
||||
command (which can then be accessed by variables) is discussed on the
|
||||
"Modify thermo"_Modify_thermo.html doc page.
|
||||
|
||||
Adding a new math function of one or two arguments can be done by
|
||||
editing one section of the Variable::evaluate() method. Search for
|
||||
the word "customize" to find the appropriate location.
|
||||
|
||||
Adding a new group function can be done by editing one section of the
|
||||
Variable::evaluate() method. Search for the word "customize" to find
|
||||
the appropriate location. You may need to add a new method to the
|
||||
Group class as well (see the group.cpp file).
|
||||
|
||||
Accessing a new atom-based vector can be done by editing one section
|
||||
of the Variable::evaluate() method. Search for the word "customize"
|
||||
to find the appropriate location.
|
||||
|
||||
Adding new "compute styles"_compute.html (whose calculated values can
|
||||
then be accessed by variables) is discussed on the "Modify
|
||||
compute"_Modify_compute.html doc page.
|
|
@ -1,40 +0,0 @@
|
|||
"Previous Section"_Commands.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
|
||||
Section"_Speed.html :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Optional packages :h2
|
||||
|
||||
This section gives an overview of the optional packages that extend
|
||||
LAMMPS functionality. Packages are groups of files that enable a
|
||||
specific set of features. For example, force fields for molecular
|
||||
systems or rigid-body constraints are in packages. You can see the
|
||||
list of all packages and "make" commands to manage them by typing
|
||||
"make package" from within the src directory of the LAMMPS
|
||||
distribution. The "Build package"_Build_package.html doc page gives
|
||||
general info on how to install and un-install packages as part of the
|
||||
LAMMPS build process.
|
||||
|
||||
<!-- RST
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
Packages_standard
|
||||
Packages_user
|
||||
Packages_details
|
||||
|
||||
END_RST -->
|
||||
|
||||
<!-- HTML_ONLY -->
|
||||
|
||||
"Standard packages"_Packages_standard.html
|
||||
"User packages"_Packages_user.html
|
||||
"Details on each package"_Packages_details.html :ul
|
||||
|
||||
<!-- END_HTML_ONLY -->
|
|
@ -1,65 +0,0 @@
|
|||
"Higher level section"_Packages.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Standard packages :h3
|
||||
|
||||
This is the list of standard packages in LAMMPS. The link for each
|
||||
package name gives more details.
|
||||
|
||||
Standard packages are supported by the LAMMPS developers and are
|
||||
written in a syntax and style consistent with the rest of LAMMPS.
|
||||
This means the developers will answer questions about them, debug and
|
||||
fix them if necessary, and keep them compatible with future changes to
|
||||
LAMMPS.
|
||||
|
||||
The "Example" column is a sub-directory in the examples directory of
|
||||
the distribution which has an input script that uses the package.
|
||||
E.g. "peptide" refers to the examples/peptide directory; USER/atc
|
||||
refers to the examples/USER/atc directory. The "Library" column
|
||||
indicates whether an extra library is needed to build and use the
|
||||
package:
|
||||
|
||||
no = no library
|
||||
sys = system library: you likely have it on your machine
|
||||
int = internal library: provided with LAMMPS, but you may need to build it
|
||||
ext = external library: you will need to download and install it on your machine :ul
|
||||
|
||||
Package, Description, Doc page, Example, Library
|
||||
"ASPHERE"_Packages_details.html#PKG-ASPHERE, aspherical particle models, "Howto spherical"_Howto_spherical.html, ellipse, no
|
||||
"BODY"_Packages_details.html#PKG-BODY, body-style particles, "Howto body"_Howto_body.html, body, no
|
||||
"CLASS2"_Packages_details.html#PKG-CLASS2, class 2 force fields, "pair_style lj/class2"_pair_class2.html, n/a, no
|
||||
"COLLOID"_Packages_details.html#PKG-COLLOID, colloidal particles, "atom_style colloid"_atom_style.html, colloid, no
|
||||
"COMPRESS"_Packages_details.html#PKG-COMPRESS, I/O compression, "dump */gz"_dump.html, n/a, sys
|
||||
"CORESHELL"_Packages_details.html#PKG-CORESHELL, adiabatic core/shell model, "Howto coreshell"_Howto_coreshell.html, coreshell, no
|
||||
"DIPOLE"_Packages_details.html#PKG-DIPOLE, point dipole particles, "pair_style dipole/cut"_pair_dipole.html, dipole, no
|
||||
"GPU"_Packages_details.html#PKG-GPU, GPU-enabled styles, "Section gpu"_Speed_gpu.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, int
|
||||
"GRANULAR"_Packages_details.html#PKG-GRANULAR, granular systems, "Howto granular"_Howto_granular.html, pour, no
|
||||
"KIM"_Packages_details.html#PKG-KIM, OpenKIM wrapper, "pair_style kim"_pair_kim.html, kim, ext
|
||||
"KOKKOS"_Packages_details.html#PKG-KOKKOS, Kokkos-enabled styles, "Speed kokkos"_Speed_kokkos.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, no
|
||||
"KSPACE"_Packages_details.html#PKG-KSPACE, long-range Coulombic solvers, "kspace_style"_kspace_style.html, peptide, no
|
||||
"LATTE"_Packages_details.html#PKG-LATTE, quantum DFTB forces via LATTE, "fix latte"_fix_latte.html, latte, ext
|
||||
"MANYBODY"_Packages_details.html#PKG-MANYBODY, many-body potentials, "pair_style tersoff"_pair_tersoff.html, shear, no
|
||||
"MC"_Packages_details.html#PKG-MC, Monte Carlo options, "fix gcmc"_fix_gcmc.html, n/a, no
|
||||
"MESSAGE"_Packages_details.html#PKG-MESSAGE, client/server messaging, "message"_message.html, message, int
|
||||
"MISC"_Packages_details.html#PKG-MISC, miscellaneous single-file commands, n/a, no, no
|
||||
"MOLECULE"_Packages_details.html#PKG-MOLECULE, molecular system force fields, "Howto bioFF"_Howto_bioFF.html, peptide, no
|
||||
"MPIIO"_Packages_details.html#PKG-MPIIO, MPI parallel I/O dump and restart, "dump"_dump.html, n/a, no
|
||||
"MSCG"_Packages_details.html#PKG-MSCG, multi-scale coarse-graining wrapper, "fix mscg"_fix_mscg.html, mscg, ext
|
||||
"OPT"_Packages_details.html#PKG-OPT, optimized pair styles, "Speed opt"_Speed_opt.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, no
|
||||
"PERI"_Packages_details.html#PKG-PERI, Peridynamics models, "pair_style peri"_pair_peri.html, peri, no
|
||||
"POEMS"_Packages_details.html#PKG-POEMS, coupled rigid body motion, "fix poems"_fix_poems.html, rigid, int
|
||||
"PYTHON"_Packages_details.html#PKG-PYTHON, embed Python code in an input script, "python"_python.html, python, sys
|
||||
"QEQ"_Packages_details.html#PKG-QEQ, QEq charge equilibration, "fix qeq"_fix_qeq.html, qeq, no
|
||||
"REPLICA"_Packages_details.html#PKG-REPLICA2, multi-replica methods, "Howto replica"_Howto_replica.html, tad, no
|
||||
"RIGID"_Packages_details.html#PKG-RIGID, rigid bodies and constraints, "fix rigid"_fix_rigid.html, rigid, no
|
||||
"SHOCK"_Packages_details.html#PKG-SHOCK, shock loading methods, "fix msst"_fix_msst.html, n/a, no
|
||||
"SNAP"_Packages_details.html#PKG-SNAP, quantum-fitted potential, "pair_style snap"_pair_snap.html, snap, no
|
||||
"SPIN"_Packages_details.html#PKG-SPIN, magnetic atomic spin dynamics, "Howto spins"_Howto_spins.html, SPIN, no
|
||||
"SRD"_Packages_details.html#PKG-SRD, stochastic rotation dynamics, "fix srd"_fix_srd.html, srd, no
|
||||
"VORONOI"_Packages_details.html#PKG-VORONOI, Voronoi tesselation, "compute voronoi/atom"_compute_voronoi_atom.html, n/a, ext :tb(ea=c,ca1=l)
|
|
@ -1,83 +0,0 @@
|
|||
"Higher level section"_Packages.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
User packages :h3
|
||||
|
||||
This is a list of user packages in LAMMPS. The link for each package
|
||||
name gives more details.
|
||||
|
||||
User packages have been contributed by users, and begin with the
|
||||
"user" prefix. If a contribution is a single command (single file),
|
||||
it is typically in the user-misc package. User packages don't
|
||||
necessarily meet the requirements of the "standard
|
||||
packages"_Packages_standard.html. This means the developers will try
|
||||
to keep things working and usually can answer technical questions
|
||||
about compiling the package. If you have problems using a specific
|
||||
feature provided in a user package, you may need to contact the
|
||||
contributor directly to get help. Information on how to submit
|
||||
additions you make to LAMMPS as single files or as a standard or user
|
||||
package is explained on the "Modify contribute"_Modify_contribute.html
|
||||
doc page.
|
||||
|
||||
The "Example" column is a sub-directory in the examples directory of
|
||||
the distribution which has an input script that uses the package.
|
||||
E.g. "peptide" refers to the examples/peptide directory; USER/atc
|
||||
refers to the examples/USER/atc directory. The "Library" column
|
||||
indicates whether an extra library is needed to build and use the
|
||||
package:
|
||||
|
||||
no = no library
|
||||
sys = system library: you likely have it on your machine
|
||||
int = internal library: provided with LAMMPS, but you may need to build it
|
||||
ext = external library: you will need to download and install it on your machine :ul
|
||||
|
||||
Package, Description, Doc page, Example, Library
|
||||
"USER-ADIOS"_Packages_details.html#PKG-USER-ADIOS, dump output via ADIOS, "dump adios"_dump_adios.html, USER/adios, ext
|
||||
"USER-ATC"_Packages_details.html#PKG-USER-ATC, Atom-to-Continuum coupling, "fix atc"_fix_atc.html, USER/atc, int
|
||||
"USER-AWPMD"_Packages_details.html#PKG-USER-AWPMD, wave packet MD, "pair_style awpmd/cut"_pair_awpmd.html, USER/awpmd, int
|
||||
"USER-BOCS"_Packages_details.html#PKG-USER-BOCS, BOCS bottom up coarse graining, "fix bocs"_fix_bocs.html, USER/bocs, no
|
||||
"USER-CGDNA"_Packages_details.html#PKG-USER-CGDNA, coarse-grained DNA force fields, src/USER-CGDNA/README, USER/cgdna, no
|
||||
"USER-CGSDK"_Packages_details.html#PKG-USER-CGSDK, SDK coarse-graining model, "pair_style lj/sdk"_pair_sdk.html, USER/cgsdk, no
|
||||
"USER-COLVARS"_Packages_details.html#PKG-USER-COLVARS, collective variables library, "fix colvars"_fix_colvars.html, USER/colvars, int
|
||||
"USER-DIFFRACTION"_Packages_details.html#PKG-USER-DIFFRACTION, virtual x-ray and electron diffraction,"compute xrd"_compute_xrd.html, USER/diffraction, no
|
||||
"USER-DPD"_Packages_details.html#PKG-USER-DPD, reactive dissipative particle dynamics, src/USER-DPD/README, USER/dpd, no
|
||||
"USER-DRUDE"_Packages_details.html#PKG-USER-DRUDE, Drude oscillators, "Howto drude"_Howto_drude.html, USER/drude, no
|
||||
"USER-EFF"_Packages_details.html#PKG-USER-EFF, electron force field,"pair_style eff/cut"_pair_eff.html, USER/eff, no
|
||||
"USER-FEP"_Packages_details.html#PKG-USER-FEP, free energy perturbation,"compute fep"_compute_fep.html, USER/fep, no
|
||||
"USER-H5MD"_Packages_details.html#PKG-USER-H5MD, dump output via HDF5,"dump h5md"_dump_h5md.html, n/a, ext
|
||||
"USER-INTEL"_Packages_details.html#PKG-USER-INTEL, optimized Intel CPU and KNL styles,"Speed intel"_Speed_intel.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, no
|
||||
"USER-LB"_Packages_details.html#PKG-USER-LB, Lattice Boltzmann fluid,"fix lb/fluid"_fix_lb_fluid.html, USER/lb, no
|
||||
"USER-MANIFOLD"_Packages_details.html#PKG-USER-MANIFOLD, motion on 2d surfaces,"fix manifoldforce"_fix_manifoldforce.html, USER/manifold, no
|
||||
"USER-MEAMC"_Packages_details.html#PKG-USER-MEAMC, modified EAM potential (C++), "pair_style meam/c"_pair_meamc.html, meamc, no
|
||||
"USER-MESO"_Packages_details.html#PKG-USER-MESO, mesoscale DPD models, "pair_style edpd"_pair_meso.html, USER/meso, no
|
||||
"USER-MGPT"_Packages_details.html#PKG-USER-MGPT, fast MGPT multi-ion potentials, "pair_style mgpt"_pair_mgpt.html, USER/mgpt, no
|
||||
"USER-MISC"_Packages_details.html#PKG-USER-MISC, single-file contributions, USER-MISC/README, USER/misc, no
|
||||
"USER-MOFFF"_Packages_details.html#PKG-USER-MOFFF, styles for "MOF-FF"_MOFplus force field, "pair_style buck6d/coul/gauss"_pair_buck6d_coul_gauss.html, USER/mofff, no
|
||||
"USER-MOLFILE"_Packages_details.html#PKG-USER-MOLFILE, "VMD"_https://www.ks.uiuc.edu/Research/vmd/ molfile plug-ins,"dump molfile"_dump_molfile.html, n/a, ext
|
||||
"USER-NETCDF"_Packages_details.html#PKG-USER-NETCDF, dump output via NetCDF,"dump netcdf"_dump_netcdf.html, n/a, ext
|
||||
"USER-OMP"_Packages_details.html#PKG-USER-OMP, OpenMP-enabled styles,"Speed omp"_Speed_omp.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, no
|
||||
"USER-PHONON"_Packages_details.html#PKG-USER-PHONON, phonon dynamical matrix,"fix phonon"_fix_phonon.html, USER/phonon, no
|
||||
"USER-PLUMED"_Packages_details.html#PKG-USER-PLUMED, "PLUMED"_#PLUMED free energy library,"fix plumed"_fix_plumed.html, USER/plumed, ext
|
||||
"USER-PTM"_Packages_details.html#PKG-USER-PTM, Polyhedral Template Matching,"compute ptm/atom"_compute_ptm_atom.html, n/a, no
|
||||
"USER-QMMM"_Packages_details.html#PKG-USER-QMMM, QM/MM coupling,"fix qmmm"_fix_qmmm.html, USER/qmmm, ext
|
||||
"USER-QTB"_Packages_details.html#PKG-USER-QTB, quantum nuclear effects,"fix qtb"_fix_qtb.html "fix qbmsst"_fix_qbmsst.html, qtb, no
|
||||
"USER-QUIP"_Packages_details.html#PKG-USER-QUIP, QUIP/libatoms interface,"pair_style quip"_pair_quip.html, USER/quip, ext
|
||||
"USER-REAXC"_Packages_details.html#PKG-USER-REAXC, ReaxFF potential (C/C++) ,"pair_style reaxc"_pair_reaxc.html, reax, no
|
||||
"USER-SCAFACOS"_Packages_details.html#PKG-USER-SCAFACOS, wrapper on ScaFaCoS solver,"kspace_style scafacos"_kspace_style.html, USER/scafacos, ext
|
||||
"USER-SDPD"_Packages_details.html#PKG-USER-SDPD, smoothed dissipative particle dynamics,"pair_style sdpd/taitwater/isothermal"_pair_sdpd_taitwater_isothermal.html, USER/sdpd, no
|
||||
"USER-SMD"_Packages_details.html#PKG-USER-SMD, smoothed Mach dynamics,"SMD User Guide"_PDF/SMD_LAMMPS_userguide.pdf, USER/smd, ext
|
||||
"USER-SMTBQ"_Packages_details.html#PKG-USER-SMTBQ, second moment tight binding QEq potential,"pair_style smtbq"_pair_smtbq.html, USER/smtbq, no
|
||||
"USER-SPH"_Packages_details.html#PKG-USER-SPH, smoothed particle hydrodynamics,"SPH User Guide"_PDF/SPH_LAMMPS_userguide.pdf, USER/sph, no
|
||||
"USER-TALLY"_Packages_details.html#PKG-USER-TALLY, pairwise tally computes,"compute XXX/tally"_compute_tally.html, USER/tally, no
|
||||
"USER-UEF"_Packages_details.html#PKG-USER-UEF, extensional flow,"fix nvt/uef"_fix_nh_uef.html, USER/uef, no
|
||||
"USER-VTK"_Packages_details.html#PKG-USER-VTK, dump output via VTK, "compute vtk"_dump_vtk.html, n/a, ext
|
||||
"USER-YAFF"_Packages_details.html#PKG-USER-YAFF, additional styles implemented in YAFF, "angle_style cross"_angle_cross.html, USER/yaff, no :tb(ea=c,ca1=l)
|
||||
|
||||
:link(MOFplus,https://www.mofplus.org/content/show/MOF-FF)
|
||||
:link(PLUMED,http://www.plumed.org)
|
|
@ -1,85 +0,0 @@
|
|||
"Higher level section"_Python_head.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Call Python from a LAMMPS input script :h3
|
||||
|
||||
LAMMPS has several commands which can be used to invoke Python
|
||||
code directly from an input script:
|
||||
|
||||
"python"_python.html
|
||||
"variable python"_variable.html
|
||||
"fix python/invoke"_fix_python_invoke.html
|
||||
"pair_style python"_pair_python.html :ul
|
||||
|
||||
The "python"_python.html command which can be used to define and
|
||||
execute a Python function that you write the code for. The Python
|
||||
function can also be assigned to a LAMMPS python-style variable via
|
||||
the "variable"_variable.html command. Each time the variable is
|
||||
evaluated, either in the LAMMPS input script itself, or by another
|
||||
LAMMPS command that uses the variable, this will trigger the Python
|
||||
function to be invoked.
|
||||
|
||||
The Python code for the function can be included directly in the input
|
||||
script or in an auxiliary file. The function can have arguments which
|
||||
are mapped to LAMMPS variables (also defined in the input script) and
|
||||
it can return a value to a LAMMPS variable. This is thus a mechanism
|
||||
for your input script to pass information to a piece of Python code,
|
||||
ask Python to execute the code, and return information to your input
|
||||
script.
|
||||
|
||||
Note that a Python function can be arbitrarily complex. It can import
|
||||
other Python modules, instantiate Python classes, call other Python
|
||||
functions, etc. The Python code that you provide can contain more
|
||||
code than the single function. It can contain other functions or
|
||||
Python classes, as well as global variables or other mechanisms for
|
||||
storing state between calls from LAMMPS to the function.
|
||||
|
||||
The Python function you provide can consist of "pure" Python code that
|
||||
only performs operations provided by standard Python. However, the
|
||||
Python function can also "call back" to LAMMPS through its
|
||||
Python-wrapped library interface, in the manner described in the
|
||||
"Python run"_Python_run.html doc page. This means it can issue LAMMPS
|
||||
input script commands or query and set internal LAMMPS state. As an
|
||||
example, this can be useful in an input script to create a more
|
||||
complex loop with branching logic, than can be created using the
|
||||
simple looping and branching logic enabled by the "next"_next.html and
|
||||
"if"_if.html commands.
|
||||
|
||||
See the "python"_python.html doc page and the "variable"_variable.html
|
||||
doc page for its python-style variables for more info, including
|
||||
examples of Python code you can write for both pure Python operations
|
||||
and callbacks to LAMMPS.
|
||||
|
||||
The "fix python/invoke"_fix_python_invoke.html command can execute
|
||||
Python code at selected timesteps during a simulation run.
|
||||
|
||||
The "pair_style python"_pair_python.html command allows you to define
|
||||
pairwise potentials as python code which encodes a single pairwise
|
||||
interaction. This is useful for rapid development and debugging of a
|
||||
new potential.
|
||||
|
||||
To use any of these commands, you only need to build LAMMPS with the
|
||||
PYTHON package installed:
|
||||
|
||||
make yes-python
|
||||
make machine :pre
|
||||
|
||||
Note that this will link LAMMPS with the Python library on your
|
||||
system, which typically requires several auxiliary system libraries to
|
||||
also be linked. The list of these libraries and the paths to find
|
||||
them are specified in the lib/python/Makefile.lammps file. You need
|
||||
to insure that file contains the correct information for your version
|
||||
of Python and your machine to successfully build LAMMPS. See the
|
||||
lib/python/README file for more info.
|
||||
|
||||
If you want to write Python code with callbacks to LAMMPS, then you
|
||||
must also follow the steps summarized in the "Python
|
||||
run"_Python_run.html doc page. I.e. you must build LAMMPS as a shared
|
||||
library and insure that Python can find the python/lammps.py file and
|
||||
the shared library.
|
|
@ -1,81 +0,0 @@
|
|||
"Higher level section"_Python_head.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Example Python scripts that use LAMMPS :h3
|
||||
|
||||
These are the Python scripts included as demos in the python/examples
|
||||
directory of the LAMMPS distribution, to illustrate the kinds of
|
||||
things that are possible when Python wraps LAMMPS. If you create your
|
||||
own scripts, send them to us and we can include them in the LAMMPS
|
||||
distribution.
|
||||
|
||||
trivial.py, read/run a LAMMPS input script through Python,
|
||||
demo.py, invoke various LAMMPS library interface routines,
|
||||
simple.py, run in parallel, similar to examples/COUPLE/simple/simple.cpp,
|
||||
split.py, same as simple.py but running in parallel on a subset of procs,
|
||||
gui.py, GUI go/stop/temperature-slider to control LAMMPS,
|
||||
plot.py, real-time temperature plot with GnuPlot via Pizza.py,
|
||||
viz_tool.py, real-time viz via some viz package,
|
||||
vizplotgui_tool.py, combination of viz_tool.py and plot.py and gui.py :tb(c=2)
|
||||
|
||||
:line
|
||||
|
||||
For the viz_tool.py and vizplotgui_tool.py commands, replace "tool"
|
||||
with "gl" or "atomeye" or "pymol" or "vmd", depending on what
|
||||
visualization package you have installed.
|
||||
|
||||
Note that for GL, you need to be able to run the Pizza.py GL tool,
|
||||
which is included in the pizza sub-directory. See the "Pizza.py doc
|
||||
pages"_pizza for more info:
|
||||
|
||||
:link(pizza,http://www.sandia.gov/~sjplimp/pizza.html)
|
||||
|
||||
Note that for AtomEye, you need version 3, and there is a line in the
|
||||
scripts that specifies the path and name of the executable. See the
|
||||
AtomEye WWW pages "here"_atomeye or "here"_atomeye3 for more details:
|
||||
|
||||
http://mt.seas.upenn.edu/Archive/Graphics/A
|
||||
http://mt.seas.upenn.edu/Archive/Graphics/A3/A3.html :pre
|
||||
|
||||
:link(atomeye,http://mt.seas.upenn.edu/Archive/Graphics/A)
|
||||
:link(atomeye3,http://mt.seas.upenn.edu/Archive/Graphics/A3/A3.html)
|
||||
|
||||
The latter link is to AtomEye 3 which has the scripting
|
||||
capability needed by these Python scripts.
|
||||
|
||||
Note that for PyMol, you need to have built and installed the
|
||||
open-source version of PyMol in your Python, so that you can import it
|
||||
from a Python script. See the PyMol WWW pages "here"_pymolhome or
|
||||
"here"_pymolopen for more details:
|
||||
|
||||
http://www.pymol.org
|
||||
http://sourceforge.net/scm/?type=svn&group_id=4546 :pre
|
||||
|
||||
:link(pymolhome,http://www.pymol.org)
|
||||
:link(pymolopen,http://sourceforge.net/scm/?type=svn&group_id=4546)
|
||||
|
||||
The latter link is to the open-source version.
|
||||
|
||||
Note that for VMD, you need a fairly current version (1.8.7 works for
|
||||
me) and there are some lines in the pizza/vmd.py script for 4 PIZZA
|
||||
variables that have to match the VMD installation on your system.
|
||||
|
||||
:line
|
||||
|
||||
See the python/README file for instructions on how to run them and the
|
||||
source code for individual scripts for comments about what they do.
|
||||
|
||||
Here are screenshots of the vizplotgui_tool.py script in action for
|
||||
different visualization package options. Click to see larger images:
|
||||
|
||||
:image(JPG/screenshot_gl_small.jpg,JPG/screenshot_gl.jpg)
|
||||
:image(JPG/screenshot_atomeye_small.jpg,JPG/screenshot_atomeye.jpg)
|
||||
:image(JPG/screenshot_pymol_small.jpg,JPG/screenshot_pymol.jpg)
|
||||
:image(JPG/screenshot_vmd_small.jpg,JPG/screenshot_vmd.jpg)
|
||||
|
|
@ -1,72 +0,0 @@
|
|||
"Previous Section"_Modify.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
|
||||
Section"_Errors.html :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Use Python with LAMMPS :h2
|
||||
|
||||
These doc pages describe various ways that LAMMPS and Python can be
|
||||
used together.
|
||||
|
||||
<!-- RST
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
Python_overview
|
||||
Python_run
|
||||
Python_shlib
|
||||
Python_install
|
||||
Python_mpi
|
||||
Python_test
|
||||
Python_library
|
||||
Python_pylammps
|
||||
Python_examples
|
||||
Python_call
|
||||
|
||||
END_RST -->
|
||||
|
||||
<!-- HTML_ONLY -->
|
||||
|
||||
"Overview of Python and LAMMPS"_Python_overview.html
|
||||
"Run LAMMPS from Python"_Python_run.html
|
||||
"Build LAMMPS as a shared library"_Python_shlib.html
|
||||
"Install LAMMPS in Python"_Python_install.html
|
||||
"Extend Python to run in parallel"_Python_mpi.html
|
||||
"Test the Python/LAMMPS interface"_Python_test.html
|
||||
"Python library interface"_Python_library.html
|
||||
"PyLammps interface"_Python_pylammps.html
|
||||
"Example Python scripts that use LAMMPS"_Python_examples.html
|
||||
"Call Python from a LAMMPS input script"_Python_call.html :all(b)
|
||||
|
||||
<!-- END_HTML_ONLY -->
|
||||
|
||||
If you're not familiar with "Python"_http://www.python.org, it's a
|
||||
powerful scripting and programming language which can do most
|
||||
everything that lower-level languages like C or C++ can do in fewer
|
||||
lines of code. The only drawback is slower execution speed. Python
|
||||
is also easy to use as a "glue" language to drive a program through
|
||||
its library interface, or to hook multiple pieces of software
|
||||
together, such as a simulation code plus a visualization tool, or to
|
||||
run a coupled multiscale or multiphysics model.
|
||||
|
||||
See the "Howto_couple"_Howto_couple.html doc page for more ideas about
|
||||
coupling LAMMPS to other codes. See the "Howto
|
||||
library"_Howto_library.html doc page for a description of the LAMMPS
|
||||
library interface provided in src/library.h and src/library.h. That
|
||||
interface is exposed to Python either when calling LAMMPS from Python
|
||||
or when calling Python from a LAMMPS input script and then calling
|
||||
back to LAMMPS from Python code. The library interface is designed to
|
||||
be easy to add functionality to. Thus the Python interface to LAMMPS
|
||||
is also easy to extend as well.
|
||||
|
||||
If you create interesting Python scripts that run LAMMPS or
|
||||
interesting Python functions that can be called from a LAMMPS input
|
||||
script, that you think would be generally useful, please post them as
|
||||
a pull request to our "GitHub site"_https://github.com/lammps/lammps,
|
||||
and they can be added to the LAMMPS distribution or webpage.
|
|
@ -1,67 +0,0 @@
|
|||
"Higher level section"_Python_head.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Installing LAMMPS in Python :h3
|
||||
|
||||
For Python to invoke LAMMPS, there are 2 files it needs to know about:
|
||||
|
||||
python/lammps.py
|
||||
liblammps.so or liblammps.dylib :ul
|
||||
|
||||
The python source code in lammps.py is the Python wrapper on the
|
||||
LAMMPS library interface. The liblammps.so or liblammps.dylib file
|
||||
is the shared LAMMPS library that Python loads dynamically.
|
||||
|
||||
You can achieve that Python can find these files in one of two ways:
|
||||
|
||||
set two environment variables pointing to the location in the source tree
|
||||
run "make install-python" or run the python/install.py script explicitly :ul
|
||||
|
||||
When calling "make install-python" LAMMPS will try to install the
|
||||
python module and the shared library into the python site-packages folders;
|
||||
either the system-wide ones, or the local users ones (in case of insufficient
|
||||
permissions for the global install). Python will then find the module
|
||||
and shared library file automatically. The exact location of these folders
|
||||
depends on your python version and your operating system.
|
||||
|
||||
If you set the paths to these files as environment variables, you only
|
||||
have to do it once. For the csh or tcsh shells, add something like
|
||||
this to your ~/.cshrc file, one line for each of the two files:
|
||||
|
||||
setenv PYTHONPATH $\{PYTHONPATH\}:/home/sjplimp/lammps/python
|
||||
setenv LD_LIBRARY_PATH $\{LD_LIBRARY_PATH\}:/home/sjplimp/lammps/src :pre
|
||||
|
||||
On MacOSX you may also need to set DYLD_LIBRARY_PATH accordingly.
|
||||
For Bourne/Korn shells accordingly into the corresponding files using
|
||||
the "export" shell builtin.
|
||||
|
||||
If you use "make install-python" or the python/install.py script, you need
|
||||
to invoke it every time you rebuild LAMMPS (as a shared library) or
|
||||
make changes to the python/lammps.py file, so that the site-packages
|
||||
files are updated with the new version.
|
||||
|
||||
If the default settings of "make install-python" are not what you want,
|
||||
you can invoke install.py from the python directory manually as
|
||||
|
||||
% python install.py -m \<python module\> -l <shared library> -v <version.h file> \[-d \<pydir\>\] :pre
|
||||
|
||||
The -m flag points to the lammps.py python module file to be installed,
|
||||
the -l flag points to the LAMMPS shared library file to be installed,
|
||||
the -v flag points to the version.h file in the LAMMPS source
|
||||
and the optional -d flag to a custom (legacy) installation folder :ul
|
||||
|
||||
If you use a legacy installation folder, you will need to set your
|
||||
PYTHONPATH and LD_LIBRARY_PATH (and/or DYLD_LIBRARY_PATH) environment
|
||||
variables accordingly, as described above.
|
||||
|
||||
Note that if you want Python to be able to load different versions of
|
||||
the LAMMPS shared library (see "this section"_Python_shlib.html), you will
|
||||
need to manually copy files like liblammps_g++.so into the appropriate
|
||||
system directory. This is not needed if you set the LD_LIBRARY_PATH
|
||||
environment variable as described above.
|
|
@ -1,67 +0,0 @@
|
|||
"Higher level section"_Python_head.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Extending Python to run in parallel :h3
|
||||
|
||||
If you wish to run LAMMPS in parallel from Python, you need to extend
|
||||
your Python with an interface to MPI. This also allows you to
|
||||
make MPI calls directly from Python in your script, if you desire.
|
||||
|
||||
We recommend use of mpi4py:
|
||||
|
||||
"PyPar"_https://github.com/daleroberts/pypar :ul
|
||||
|
||||
As of version 2.0.0 it allows passing a custom MPI communicator to
|
||||
the LAMMPS constructor, which means one can easily run one or more
|
||||
LAMMPS instances on subsets of the total MPI ranks.
|
||||
|
||||
To install mpi4py (version mpi4py-2.0.0 as of Oct 2015), unpack it
|
||||
and from its main directory, type
|
||||
|
||||
python setup.py build
|
||||
sudo python setup.py install :pre
|
||||
|
||||
Again, the "sudo" is only needed if required to copy mpi4py files into
|
||||
your Python distribution's site-packages directory. To install with
|
||||
user privilege into the user local directory type
|
||||
|
||||
python setup.py install --user :pre
|
||||
|
||||
If you have successfully installed mpi4py, you should be able to run
|
||||
Python and type
|
||||
|
||||
from mpi4py import MPI :pre
|
||||
|
||||
without error. You should also be able to run python in parallel
|
||||
on a simple test script
|
||||
|
||||
% mpirun -np 4 python test.py :pre
|
||||
|
||||
where test.py contains the lines
|
||||
|
||||
from mpi4py import MPI
|
||||
comm = MPI.COMM_WORLD
|
||||
print "Proc %d out of %d procs" % (comm.Get_rank(),comm.Get_size()) :pre
|
||||
|
||||
and see one line of output for each processor you run on.
|
||||
|
||||
NOTE: To use mpi4py and LAMMPS in parallel from Python, you must
|
||||
insure both are using the same version of MPI. If you only have one
|
||||
MPI installed on your system, this is not an issue, but it can be if
|
||||
you have multiple MPIs. Your LAMMPS build is explicit about which MPI
|
||||
it is using, since you specify the details in your lo-level
|
||||
src/MAKE/Makefile.foo file. Mpi4py uses the "mpicc" command to find
|
||||
information about the MPI it uses to build against. And it tries to
|
||||
load "libmpi.so" from the LD_LIBRARY_PATH. This may or may not find
|
||||
the MPI library that LAMMPS is using. If you have problems running
|
||||
both mpi4py and LAMMPS together, this is an issue you may need to
|
||||
address, e.g. by moving other MPI installations so that mpi4py finds
|
||||
the right one.
|
||||
|
||||
|
|
@ -1,36 +0,0 @@
|
|||
"Previous Section"_Examples.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
|
||||
Section"_Tools.html :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
Overview of Python and LAMMPS :h3
|
||||
|
||||
LAMMPS can work together with Python in three ways. First, Python can
|
||||
wrap LAMMPS through the its "library interface"_Howto_library.html, so
|
||||
that a Python script can create one or more instances of LAMMPS and
|
||||
launch one or more simulations. In Python lingo, this is called
|
||||
"extending" Python with a LAMMPS module.
|
||||
|
||||
Second, a lower-level Python interface can be used indirectly through
|
||||
the provided PyLammps and IPyLammps wrapper classes, written in Python.
|
||||
These wrappers try to simplify the usage of LAMMPS in Python by
|
||||
providing an object-based interface to common LAMMPS functionality.
|
||||
They also reduces the amount of code necessary to parameterize LAMMPS
|
||||
scripts through Python and make variables and computes directly
|
||||
accessible.
|
||||
|
||||
Third, LAMMPS can use the Python interpreter, so that a LAMMPS
|
||||
input script or styles can invoke Python code directly, and pass
|
||||
information back-and-forth between the input script and Python
|
||||
functions you write. This Python code can also callback to LAMMPS
|
||||
to query or change its attributes through the LAMMPS Python module
|
||||
mentioned above. In Python lingo, this is "embedding" Python in
|
||||
LAMMPS. When used in this mode, Python can perform script operations
|
||||
that the simple LAMMPS input script syntax can not.
|
||||
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
"Higher level section"_Python_head.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
PyLammps interface :h3
|
||||
|
||||
PyLammps is a Python wrapper class which can be created on its own or
|
||||
use an existing lammps Python object. It has its own "Howto
|
||||
pylammps"_Howto_pylammps.html doc page.
|
|
@ -1,40 +0,0 @@
|
|||
"Higher level section"_Python_head.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Run LAMMPS from Python :h3
|
||||
|
||||
The LAMMPS distribution includes a python directory with all you need
|
||||
to run LAMMPS from Python. The python/lammps.py file wraps the LAMMPS
|
||||
library interface, with one wrapper function per LAMMPS library
|
||||
function. This file makes it is possible to do the following either
|
||||
from a Python script, or interactively from a Python prompt: create
|
||||
one or more instances of LAMMPS, invoke LAMMPS commands or give it an
|
||||
input script, run LAMMPS incrementally, extract LAMMPS results, an
|
||||
modify internal LAMMPS variables. From a Python script you can do
|
||||
this in serial or parallel. Running Python interactively in parallel
|
||||
does not generally work, unless you have a version of Python that
|
||||
extends Python to enable multiple instances of Python to read what you
|
||||
type.
|
||||
|
||||
To do all of this, you must first build LAMMPS as a shared library,
|
||||
then insure that your Python can find the python/lammps.py file and
|
||||
the shared library.
|
||||
|
||||
Two advantages of using Python to run LAMMPS are how concise the
|
||||
language is, and that it can be run interactively, enabling rapid
|
||||
development and debugging. If you use it to mostly invoke costly
|
||||
operations within LAMMPS, such as running a simulation for a
|
||||
reasonable number of timesteps, then the overhead cost of invoking
|
||||
LAMMPS through Python will be negligible.
|
||||
|
||||
The Python wrapper for LAMMPS uses the "ctypes" package in Python,
|
||||
which auto-generates the interface code needed between Python and a
|
||||
set of C-style library functions. Ctypes is part of standard Python
|
||||
for versions 2.5 and later. You can check which version of Python you
|
||||
have by simply typing "python" at a shell prompt.
|
|
@ -1,73 +0,0 @@
|
|||
"Higher level section"_Python_head.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Build LAMMPS as a shared library :h3
|
||||
|
||||
Build LAMMPS as a shared library using make :h4
|
||||
|
||||
Instructions on how to build LAMMPS as a shared library are given on
|
||||
the "Build_basics"_Build_basics.html doc page. A shared library is
|
||||
one that is dynamically loadable, which is what Python requires to
|
||||
wrap LAMMPS. On Linux this is a library file that ends in ".so", not
|
||||
".a".
|
||||
|
||||
From the src directory, type
|
||||
|
||||
make foo mode=shlib :pre
|
||||
|
||||
where foo is the machine target name, such as mpi or serial.
|
||||
This should create the file liblammps_foo.so in the src directory, as
|
||||
well as a soft link liblammps.so, which is what the Python wrapper will
|
||||
load by default. Note that if you are building multiple machine
|
||||
versions of the shared library, the soft link is always set to the
|
||||
most recently built version.
|
||||
|
||||
NOTE: If you are building LAMMPS with an MPI or FFT library or other
|
||||
auxiliary libraries (used by various packages), then all of these
|
||||
extra libraries must also be shared libraries. If the LAMMPS
|
||||
shared-library build fails with an error complaining about this, see
|
||||
the "Build_basics"_Build_basics.html doc page.
|
||||
|
||||
Build LAMMPS as a shared library using CMake :h4
|
||||
|
||||
When using CMake the following two options are necessary to generate the LAMMPS
|
||||
shared library:
|
||||
|
||||
-D BUILD_LIB=on # enable building LAMMPS as a library
|
||||
-D BUILD_SHARED_LIBS=on # enable building of LAMMPS shared library (both options are needed!) :pre
|
||||
|
||||
What this does is create a liblammps.so which contains the majority of LAMMPS
|
||||
code. The generated lmp binary also dynamically links to this library. This
|
||||
means that either this liblammps.so file has to be in the same directory, a system
|
||||
library path (e.g. /usr/lib64/) or in the LD_LIBRARY_PATH.
|
||||
|
||||
If you want to use the shared library with Python the recommended way is to create a virtualenv and use it as
|
||||
CMAKE_INSTALL_PREFIX.
|
||||
|
||||
# create virtualenv
|
||||
virtualenv --python=$(which python3) myenv3
|
||||
source myenv3/bin/activate :pre
|
||||
|
||||
# build library
|
||||
mkdir build
|
||||
cd build
|
||||
cmake -D PKG_PYTHON=on -D BUILD_LIB=on -D BUILD_SHARED_LIBS=on -D CMAKE_INSTALL_PREFIX=$VIRTUAL_ENV ../cmake
|
||||
make -j 4 :pre
|
||||
|
||||
# install into prefix
|
||||
make install :pre
|
||||
|
||||
This will also install the Python module into your virtualenv. Since virtualenv
|
||||
doesn't change your LD_LIBRARY_PATH, you still need to add its lib64 folder to
|
||||
it, which contains the installed liblammps.so.
|
||||
|
||||
export LD_LIBRARY_PATH=$VIRTUAL_ENV/lib64:$LD_LIBRARY_PATH :pre
|
||||
|
||||
Starting Python outside (!) of your build directory, but with the virtualenv
|
||||
enabled and with the LD_LIBRARY_PATH set gives you access to LAMMPS via Python.
|
|
@ -1,131 +0,0 @@
|
|||
"Higher level section"_Python_head.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Test the Python/LAMMPS interface :h3
|
||||
|
||||
To test if LAMMPS is callable from Python, launch Python interactively
|
||||
and type:
|
||||
|
||||
>>> from lammps import lammps
|
||||
>>> lmp = lammps() :pre
|
||||
|
||||
If you get no errors, you're ready to use LAMMPS from Python. If the
|
||||
2nd command fails, the most common error to see is
|
||||
|
||||
OSError: Could not load LAMMPS dynamic library :pre
|
||||
|
||||
which means Python was unable to load the LAMMPS shared library. This
|
||||
typically occurs if the system can't find the LAMMPS shared library or
|
||||
one of the auxiliary shared libraries it depends on, or if something
|
||||
about the library is incompatible with your Python. The error message
|
||||
should give you an indication of what went wrong.
|
||||
|
||||
You can also test the load directly in Python as follows, without
|
||||
first importing from the lammps.py file:
|
||||
|
||||
>>> from ctypes import CDLL
|
||||
>>> CDLL("liblammps.so") :pre
|
||||
|
||||
If an error occurs, carefully go through the steps on the
|
||||
"Build_basics"_Build_basics.html doc page about building a shared
|
||||
library and the "Python_install"_Python_install.html doc page about
|
||||
insuring Python can find the necessary two files it needs.
|
||||
|
||||
[Test LAMMPS and Python in serial:] :h4
|
||||
|
||||
To run a LAMMPS test in serial, type these lines into Python
|
||||
interactively from the bench directory:
|
||||
|
||||
>>> from lammps import lammps
|
||||
>>> lmp = lammps()
|
||||
>>> lmp.file("in.lj") :pre
|
||||
|
||||
Or put the same lines in the file test.py and run it as
|
||||
|
||||
% python test.py :pre
|
||||
|
||||
Either way, you should see the results of running the in.lj benchmark
|
||||
on a single processor appear on the screen, the same as if you had
|
||||
typed something like:
|
||||
|
||||
lmp_g++ -in in.lj :pre
|
||||
|
||||
[Test LAMMPS and Python in parallel:] :h4
|
||||
|
||||
To run LAMMPS in parallel, assuming you have installed the
|
||||
"PyPar"_https://github.com/daleroberts/pypar package as discussed
|
||||
above, create a test.py file containing these lines:
|
||||
|
||||
import pypar
|
||||
from lammps import lammps
|
||||
lmp = lammps()
|
||||
lmp.file("in.lj")
|
||||
print "Proc %d out of %d procs has" % (pypar.rank(),pypar.size()),lmp
|
||||
pypar.finalize() :pre
|
||||
|
||||
To run LAMMPS in parallel, assuming you have installed the
|
||||
"mpi4py"_https://bitbucket.org/mpi4py/mpi4py package as discussed
|
||||
above, create a test.py file containing these lines:
|
||||
|
||||
from mpi4py import MPI
|
||||
from lammps import lammps
|
||||
lmp = lammps()
|
||||
lmp.file("in.lj")
|
||||
me = MPI.COMM_WORLD.Get_rank()
|
||||
nprocs = MPI.COMM_WORLD.Get_size()
|
||||
print "Proc %d out of %d procs has" % (me,nprocs),lmp
|
||||
MPI.Finalize() :pre
|
||||
|
||||
You can either script in parallel as:
|
||||
|
||||
% mpirun -np 4 python test.py :pre
|
||||
|
||||
and you should see the same output as if you had typed
|
||||
|
||||
% mpirun -np 4 lmp_g++ -in in.lj :pre
|
||||
|
||||
Note that if you leave out the 3 lines from test.py that specify PyPar
|
||||
commands you will instantiate and run LAMMPS independently on each of
|
||||
the P processors specified in the mpirun command. In this case you
|
||||
should get 4 sets of output, each showing that a LAMMPS run was made
|
||||
on a single processor, instead of one set of output showing that
|
||||
LAMMPS ran on 4 processors. If the 1-processor outputs occur, it
|
||||
means that PyPar is not working correctly.
|
||||
|
||||
Also note that once you import the PyPar module, PyPar initializes MPI
|
||||
for you, and you can use MPI calls directly in your Python script, as
|
||||
described in the PyPar documentation. The last line of your Python
|
||||
script should be pypar.finalize(), to insure MPI is shut down
|
||||
correctly.
|
||||
|
||||
[Running Python scripts:] :h4
|
||||
|
||||
Note that any Python script (not just for LAMMPS) can be invoked in
|
||||
one of several ways:
|
||||
|
||||
% python foo.script
|
||||
% python -i foo.script
|
||||
% foo.script :pre
|
||||
|
||||
The last command requires that the first line of the script be
|
||||
something like this:
|
||||
|
||||
#!/usr/local/bin/python
|
||||
#!/usr/local/bin/python -i :pre
|
||||
|
||||
where the path points to where you have Python installed, and that you
|
||||
have made the script file executable:
|
||||
|
||||
% chmod +x foo.script :pre
|
||||
|
||||
Without the "-i" flag, Python will exit when the script finishes.
|
||||
With the "-i" flag, you will be left in the Python interpreter when
|
||||
the script finishes, so you can type subsequent commands. As
|
||||
mentioned above, you can only run Python interactively when running
|
||||
Python on a single processor, not in parallel.
|
|
@ -1,89 +0,0 @@
|
|||
"Higher level section"_Run_head.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Basics of running LAMMPS :h3
|
||||
|
||||
LAMMPS is run from the command line, reading commands from a
|
||||
file via the -in command line flag, or from standard input.
|
||||
Using the "-in in.file" variant is recommended:
|
||||
|
||||
lmp_serial < in.file
|
||||
lmp_serial -in in.file
|
||||
/path/to/lammps/src/lmp_serial < in.file
|
||||
mpirun -np 4 lmp_mpi -in in.file
|
||||
mpirun -np 8 /path/to//lammps/src/lmp_mpi -in in.file
|
||||
mpirun -np 6 /usr/local/bin/lmp -in in.file :pre
|
||||
|
||||
You normally run the LAMMPS command in the directory where your
|
||||
input script is located. That is also where output files are
|
||||
produced by default, unless you provide specific other paths in
|
||||
your input script or on the command line. As in some of the
|
||||
examples above, the LAMMPS executable itself can be placed elsewhere.
|
||||
|
||||
NOTE: The redirection operator "<" will not always work when running
|
||||
in parallel with mpirun; for those systems the -in form is required.
|
||||
|
||||
As LAMMPS runs it prints info to the screen and a logfile named
|
||||
log.lammps. More info about output is given on the "Run
|
||||
output"_Run_output.html doc page.
|
||||
|
||||
If LAMMPS encounters errors in the input script or while running a
|
||||
simulation it will print an ERROR message and stop or a WARNING
|
||||
message and continue. See the "Errors"_Errors.html doc page for a
|
||||
discussion of the various kinds of errors LAMMPS can or can't detect,
|
||||
a list of all ERROR and WARNING messages, and what to do about them.
|
||||
|
||||
:line
|
||||
|
||||
LAMMPS can run the same problem on any number of processors, including
|
||||
a single processor. In theory you should get identical answers on any
|
||||
number of processors and on any machine. In practice, numerical
|
||||
round-off can cause slight differences and eventual divergence of
|
||||
molecular dynamics phase space trajectories. See the "Errors
|
||||
common"_Errors_common.html doc page for discussion of this.
|
||||
|
||||
LAMMPS can run as large a problem as will fit in the physical memory
|
||||
of one or more processors. If you run out of memory, you must run on
|
||||
more processors or define a smaller problem.
|
||||
|
||||
If you run LAMMPS in parallel via mpirun, you should be aware of the
|
||||
"processors"_processors.html command which controls how MPI tasks are
|
||||
mapped to the simulation box, as well as mpirun options that control
|
||||
how MPI tasks are assigned to physical cores of the node(s) of the
|
||||
machine you are running on. These settings can improve performance,
|
||||
though the defaults are often adequate.
|
||||
|
||||
For example, it is often important to bind MPI tasks (processes) to
|
||||
physical cores (processor affinity), so that the operating system does
|
||||
not migrate them during a simulation. If this is not the default
|
||||
behavior on your machine, the mpirun option "--bind-to core" (OpenMPI)
|
||||
or "-bind-to core" (MPICH) can be used.
|
||||
|
||||
If the LAMMPS command(s) you are using support multi-threading, you
|
||||
can set the number of threads per MPI task via the environment
|
||||
variable OMP_NUM_THREADS, before you launch LAMMPS:
|
||||
|
||||
export OMP_NUM_THREADS=2 # bash
|
||||
setenv OMP_NUM_THREADS 2 # csh or tcsh :pre
|
||||
|
||||
This can also be done via the "package"_package.html command or via
|
||||
the "-pk command-line switch"_Run_options.html which invokes the
|
||||
package command. See the "package"_package.html command or
|
||||
"Speed"_Speed.html doc pages for more details about which accelerator
|
||||
packages and which commands support multi-threading.
|
||||
|
||||
:line
|
||||
|
||||
You can experiment with running LAMMPS using any of the input scripts
|
||||
provided in the examples or bench directory. Input scripts are named
|
||||
in.* and sample outputs are named log.*.P where P is the number of
|
||||
processors it was run on.
|
||||
|
||||
Some of the examples or benchmarks require LAMMPS to be built with
|
||||
optional packages.
|
|
@ -1,38 +0,0 @@
|
|||
"Previous Section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc - "Next
|
||||
Section"_Commands.html :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Run LAMMPS :h2
|
||||
|
||||
These pages explain how to run LAMMPS once you have "installed an
|
||||
executable"_Install.html or "downloaded the source code"_Install.html
|
||||
and "built an executable"_Build.html. The "Commands"_Commands.html
|
||||
doc page describes how input scripts are structured and the commands
|
||||
they can contain.
|
||||
|
||||
<!-- RST
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
Run_basics
|
||||
Run_options
|
||||
Run_output
|
||||
Run_windows
|
||||
|
||||
END_RST -->
|
||||
|
||||
<!-- HTML_ONLY -->
|
||||
|
||||
"Basics of running LAMMPS"_Run_basics.html
|
||||
"Command-line options"_Run_options.html
|
||||
"Screen and logfile output"_Run_output.html
|
||||
"Running LAMMPS on Windows"_Run_windows.html :all(b)
|
||||
|
||||
<!-- END_HTML_ONLY -->
|
|
@ -1,542 +0,0 @@
|
|||
"Higher level section"_Run_head.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Command-line options :h3
|
||||
|
||||
At run time, LAMMPS recognizes several optional command-line switches
|
||||
which may be used in any order. Either the full word or a one-or-two
|
||||
letter abbreviation can be used:
|
||||
|
||||
"-e or -echo"_#echo
|
||||
"-h or -help"_#help
|
||||
"-i or -in"_#file
|
||||
"-k or -kokkos"_#run-kokkos
|
||||
"-l or -log"_#log
|
||||
"-m or -mpicolor"_#mpicolor
|
||||
"-nc or -nocite"_#nocite
|
||||
"-pk or -package"_#package
|
||||
"-p or -partition"_#partition
|
||||
"-pl or -plog"_#plog
|
||||
"-ps or -pscreen"_#pscreen
|
||||
"-ro or -reorder"_#reorder
|
||||
"-r2data or -restart2data"_#restart2data
|
||||
"-r2dump or -restart2dump"_#restart2dump
|
||||
"-sc or -screen"_#screen
|
||||
"-sf or -suffix"_#suffix
|
||||
"-v or -var"_#var :ul
|
||||
|
||||
For example, the lmp_mpi executable might be launched as follows:
|
||||
|
||||
mpirun -np 16 lmp_mpi -v f tmp.out -l my.log -sc none -i in.alloy
|
||||
mpirun -np 16 lmp_mpi -var f tmp.out -log my.log -screen none -in in.alloy :pre
|
||||
|
||||
:line
|
||||
|
||||
[-echo style] :link(echo)
|
||||
|
||||
Set the style of command echoing. The style can be {none} or {screen}
|
||||
or {log} or {both}. Depending on the style, each command read from
|
||||
the input script will be echoed to the screen and/or logfile. This
|
||||
can be useful to figure out which line of your script is causing an
|
||||
input error. The default value is {log}. The echo style can also be
|
||||
set by using the "echo"_echo.html command in the input script itself.
|
||||
|
||||
:line
|
||||
|
||||
[-help] :link(help)
|
||||
|
||||
Print a brief help summary and a list of options compiled into this
|
||||
executable for each LAMMPS style (atom_style, fix, compute,
|
||||
pair_style, bond_style, etc). This can tell you if the command you
|
||||
want to use was included via the appropriate package at compile time.
|
||||
LAMMPS will print the info and immediately exit if this switch is
|
||||
used.
|
||||
|
||||
:line
|
||||
|
||||
[-in file] :link(file)
|
||||
|
||||
Specify a file to use as an input script. This is an optional switch
|
||||
when running LAMMPS in one-partition mode. If it is not specified,
|
||||
LAMMPS reads its script from standard input, typically from a script
|
||||
via I/O redirection; e.g. lmp_linux < in.run. I/O redirection should
|
||||
also work in parallel, but if it does not (in the unlikely case that
|
||||
an MPI implementation does not support it), then use the -in flag.
|
||||
Note that this is a required switch when running LAMMPS in
|
||||
multi-partition mode, since multiple processors cannot all read from
|
||||
stdin.
|
||||
|
||||
:line
|
||||
|
||||
[-kokkos on/off keyword/value ...] :link(run-kokkos)
|
||||
|
||||
Explicitly enable or disable KOKKOS support, as provided by the KOKKOS
|
||||
package. Even if LAMMPS is built with this package, as described
|
||||
in "Speed kokkos"_Speed_kokkos.html, this switch must be set to enable
|
||||
running with KOKKOS-enabled styles the package provides. If the
|
||||
switch is not set (the default), LAMMPS will operate as if the KOKKOS
|
||||
package were not installed; i.e. you can run standard LAMMPS or with
|
||||
the GPU or USER-OMP packages, for testing or benchmarking purposes.
|
||||
|
||||
Additional optional keyword/value pairs can be specified which
|
||||
determine how Kokkos will use the underlying hardware on your
|
||||
platform. These settings apply to each MPI task you launch via the
|
||||
"mpirun" or "mpiexec" command. You may choose to run one or more MPI
|
||||
tasks per physical node. Note that if you are running on a desktop
|
||||
machine, you typically have one physical node. On a cluster or
|
||||
supercomputer there may be dozens or 1000s of physical nodes.
|
||||
|
||||
Either the full word or an abbreviation can be used for the keywords.
|
||||
Note that the keywords do not use a leading minus sign. I.e. the
|
||||
keyword is "t", not "-t". Also note that each of the keywords has a
|
||||
default setting. Examples of when to use these options and what
|
||||
settings to use on different platforms is given on the "Speed
|
||||
kokkos"_Speed_kokkos.html doc page.
|
||||
|
||||
d or device
|
||||
g or gpus
|
||||
t or threads
|
||||
n or numa :ul
|
||||
|
||||
device Nd :pre
|
||||
|
||||
This option is only relevant if you built LAMMPS with CUDA=yes, you
|
||||
have more than one GPU per node, and if you are running with only one
|
||||
MPI task per node. The Nd setting is the ID of the GPU on the node to
|
||||
run on. By default Nd = 0. If you have multiple GPUs per node, they
|
||||
have consecutive IDs numbered as 0,1,2,etc. This setting allows you
|
||||
to launch multiple independent jobs on the node, each with a single
|
||||
MPI task per node, and assign each job to run on a different GPU.
|
||||
|
||||
gpus Ng Ns :pre
|
||||
|
||||
This option is only relevant if you built LAMMPS with CUDA=yes, you
|
||||
have more than one GPU per node, and you are running with multiple MPI
|
||||
tasks per node (up to one per GPU). The Ng setting is how many GPUs
|
||||
you will use. The Ns setting is optional. If set, it is the ID of a
|
||||
GPU to skip when assigning MPI tasks to GPUs. This may be useful if
|
||||
your desktop system reserves one GPU to drive the screen and the rest
|
||||
are intended for computational work like running LAMMPS. By default
|
||||
Ng = 1 and Ns is not set.
|
||||
|
||||
Depending on which flavor of MPI you are running, LAMMPS will look for
|
||||
one of these 4 environment variables
|
||||
|
||||
SLURM_LOCALID (various MPI variants compiled with SLURM support)
|
||||
MPT_LRANK (HPE MPI)
|
||||
MV2_COMM_WORLD_LOCAL_RANK (Mvapich)
|
||||
OMPI_COMM_WORLD_LOCAL_RANK (OpenMPI) :pre
|
||||
|
||||
which are initialized by the "srun", "mpirun" or "mpiexec" commands.
|
||||
The environment variable setting for each MPI rank is used to assign a
|
||||
unique GPU ID to the MPI task.
|
||||
|
||||
threads Nt :pre
|
||||
|
||||
This option assigns Nt number of threads to each MPI task for
|
||||
performing work when Kokkos is executing in OpenMP or pthreads mode.
|
||||
The default is Nt = 1, which essentially runs in MPI-only mode. If
|
||||
there are Np MPI tasks per physical node, you generally want Np*Nt =
|
||||
the number of physical cores per node, to use your available hardware
|
||||
optimally. This also sets the number of threads used by the host when
|
||||
LAMMPS is compiled with CUDA=yes.
|
||||
|
||||
numa Nm :pre
|
||||
|
||||
This option is only relevant when using pthreads with hwloc support.
|
||||
In this case Nm defines the number of NUMA regions (typically sockets)
|
||||
on a node which will be utilized by a single MPI rank. By default Nm
|
||||
= 1. If this option is used the total number of worker-threads per
|
||||
MPI rank is threads*numa. Currently it is always almost better to
|
||||
assign at least one MPI rank per NUMA region, and leave numa set to
|
||||
its default value of 1. This is because letting a single process span
|
||||
multiple NUMA regions induces a significant amount of cross NUMA data
|
||||
traffic which is slow.
|
||||
|
||||
:line
|
||||
|
||||
[-log file] :link(log)
|
||||
|
||||
Specify a log file for LAMMPS to write status information to. In
|
||||
one-partition mode, if the switch is not used, LAMMPS writes to the
|
||||
file log.lammps. If this switch is used, LAMMPS writes to the
|
||||
specified file. In multi-partition mode, if the switch is not used, a
|
||||
log.lammps file is created with hi-level status information. Each
|
||||
partition also writes to a log.lammps.N file where N is the partition
|
||||
ID. If the switch is specified in multi-partition mode, the hi-level
|
||||
logfile is named "file" and each partition also logs information to a
|
||||
file.N. For both one-partition and multi-partition mode, if the
|
||||
specified file is "none", then no log files are created. Using a
|
||||
"log"_log.html command in the input script will override this setting.
|
||||
Option -plog will override the name of the partition log files file.N.
|
||||
|
||||
:line
|
||||
|
||||
[-mpicolor] color :link(mpicolor)
|
||||
|
||||
If used, this must be the first command-line argument after the LAMMPS
|
||||
executable name. It is only used when LAMMPS is launched by an mpirun
|
||||
command which also launches another executable(s) at the same time.
|
||||
(The other executable could be LAMMPS as well.) The color is an
|
||||
integer value which should be different for each executable (another
|
||||
application may set this value in a different way). LAMMPS and the
|
||||
other executable(s) perform an MPI_Comm_split() with their own colors
|
||||
to shrink the MPI_COMM_WORLD communication to be the subset of
|
||||
processors they are actually running on.
|
||||
|
||||
Currently, this is only used in LAMMPS to perform client/server
|
||||
messaging with another application. LAMMPS can act as either a client
|
||||
or server (or both). More details are given on the "Howto
|
||||
client/server"_Howto_client_server.html doc page.
|
||||
|
||||
Specifically, this refers to the "mpi/one" mode of messaging provided
|
||||
by the "message"_message.html command and the CSlib library LAMMPS
|
||||
links with from the lib/message directory. See the
|
||||
"message"_message.html command for more details.
|
||||
|
||||
:line
|
||||
|
||||
[-nocite] :link(nocite)
|
||||
|
||||
Disable writing the log.cite file which is normally written to list
|
||||
references for specific cite-able features used during a LAMMPS run.
|
||||
See the "citation page"_http://lammps.sandia.gov/cite.html for more
|
||||
details.
|
||||
|
||||
:line
|
||||
|
||||
[-package style args ....] :link(package)
|
||||
|
||||
Invoke the "package"_package.html command with style and args. The
|
||||
syntax is the same as if the command appeared at the top of the input
|
||||
script. For example "-package gpu 2" or "-pk gpu 2" is the same as
|
||||
"package gpu 2"_package.html in the input script. The possible styles
|
||||
and args are documented on the "package"_package.html doc page. This
|
||||
switch can be used multiple times, e.g. to set options for the
|
||||
USER-INTEL and USER-OMP packages which can be used together.
|
||||
|
||||
Along with the "-suffix" command-line switch, this is a convenient
|
||||
mechanism for invoking accelerator packages and their options without
|
||||
having to edit an input script.
|
||||
|
||||
:line
|
||||
|
||||
[-partition 8x2 4 5 ...] :link(partition)
|
||||
|
||||
Invoke LAMMPS in multi-partition mode. When LAMMPS is run on P
|
||||
processors and this switch is not used, LAMMPS runs in one partition,
|
||||
i.e. all P processors run a single simulation. If this switch is
|
||||
used, the P processors are split into separate partitions and each
|
||||
partition runs its own simulation. The arguments to the switch
|
||||
specify the number of processors in each partition. Arguments of the
|
||||
form MxN mean M partitions, each with N processors. Arguments of the
|
||||
form N mean a single partition with N processors. The sum of
|
||||
processors in all partitions must equal P. Thus the command
|
||||
"-partition 8x2 4 5" has 10 partitions and runs on a total of 25
|
||||
processors.
|
||||
|
||||
Running with multiple partitions can be useful for running
|
||||
"multi-replica simulations"_Howto_replica.html, where each replica
|
||||
runs on one or a few processors. Note that with MPI installed on a
|
||||
machine (e.g. your desktop), you can run on more (virtual) processors
|
||||
than you have physical processors.
|
||||
|
||||
To run multiple independent simulations from one input script, using
|
||||
multiple partitions, see the "Howto multiple"_Howto_multiple.html doc
|
||||
page. World- and universe-style "variables"_variable.html are useful
|
||||
in this context.
|
||||
|
||||
:line
|
||||
|
||||
[-plog file] :link(plog)
|
||||
|
||||
Specify the base name for the partition log files, so partition N
|
||||
writes log information to file.N. If file is none, then no partition
|
||||
log files are created. This overrides the filename specified in the
|
||||
-log command-line option. This option is useful when working with
|
||||
large numbers of partitions, allowing the partition log files to be
|
||||
suppressed (-plog none) or placed in a sub-directory (-plog
|
||||
replica_files/log.lammps) If this option is not used the log file for
|
||||
partition N is log.lammps.N or whatever is specified by the -log
|
||||
command-line option.
|
||||
|
||||
:line
|
||||
|
||||
[-pscreen file] :link(pscreen)
|
||||
|
||||
Specify the base name for the partition screen file, so partition N
|
||||
writes screen information to file.N. If file is none, then no
|
||||
partition screen files are created. This overrides the filename
|
||||
specified in the -screen command-line option. This option is useful
|
||||
when working with large numbers of partitions, allowing the partition
|
||||
screen files to be suppressed (-pscreen none) or placed in a
|
||||
sub-directory (-pscreen replica_files/screen). If this option is not
|
||||
used the screen file for partition N is screen.N or whatever is
|
||||
specified by the -screen command-line option.
|
||||
|
||||
:line
|
||||
|
||||
[-reorder] :link(reorder)
|
||||
|
||||
This option has 2 forms:
|
||||
|
||||
-reorder nth N
|
||||
-reorder custom filename :pre
|
||||
|
||||
Reorder the processors in the MPI communicator used to instantiate
|
||||
LAMMPS, in one of several ways. The original MPI communicator ranks
|
||||
all P processors from 0 to P-1. The mapping of these ranks to
|
||||
physical processors is done by MPI before LAMMPS begins. It may be
|
||||
useful in some cases to alter the rank order. E.g. to insure that
|
||||
cores within each node are ranked in a desired order. Or when using
|
||||
the "run_style verlet/split"_run_style.html command with 2 partitions
|
||||
to insure that a specific Kspace processor (in the 2nd partition) is
|
||||
matched up with a specific set of processors in the 1st partition.
|
||||
See the "Speed tips"_Speed_tips.html doc page for more details.
|
||||
|
||||
If the keyword {nth} is used with a setting {N}, then it means every
|
||||
Nth processor will be moved to the end of the ranking. This is useful
|
||||
when using the "run_style verlet/split"_run_style.html command with 2
|
||||
partitions via the -partition command-line switch. The first set of
|
||||
processors will be in the first partition, the 2nd set in the 2nd
|
||||
partition. The -reorder command-line switch can alter this so that
|
||||
the 1st N procs in the 1st partition and one proc in the 2nd partition
|
||||
will be ordered consecutively, e.g. as the cores on one physical node.
|
||||
This can boost performance. For example, if you use "-reorder nth 4"
|
||||
and "-partition 9 3" and you are running on 12 processors, the
|
||||
processors will be reordered from
|
||||
|
||||
0 1 2 3 4 5 6 7 8 9 10 11 :pre
|
||||
|
||||
to
|
||||
|
||||
0 1 2 4 5 6 8 9 10 3 7 11 :pre
|
||||
|
||||
so that the processors in each partition will be
|
||||
|
||||
0 1 2 4 5 6 8 9 10
|
||||
3 7 11 :pre
|
||||
|
||||
See the "processors" command for how to insure processors from each
|
||||
partition could then be grouped optimally for quad-core nodes.
|
||||
|
||||
If the keyword is {custom}, then a file that specifies a permutation
|
||||
of the processor ranks is also specified. The format of the reorder
|
||||
file is as follows. Any number of initial blank or comment lines
|
||||
(starting with a "#" character) can be present. These should be
|
||||
followed by P lines of the form:
|
||||
|
||||
I J :pre
|
||||
|
||||
where P is the number of processors LAMMPS was launched with. Note
|
||||
that if running in multi-partition mode (see the -partition switch
|
||||
above) P is the total number of processors in all partitions. The I
|
||||
and J values describe a permutation of the P processors. Every I and
|
||||
J should be values from 0 to P-1 inclusive. In the set of P I values,
|
||||
every proc ID should appear exactly once. Ditto for the set of P J
|
||||
values. A single I,J pairing means that the physical processor with
|
||||
rank I in the original MPI communicator will have rank J in the
|
||||
reordered communicator.
|
||||
|
||||
Note that rank ordering can also be specified by many MPI
|
||||
implementations, either by environment variables that specify how to
|
||||
order physical processors, or by config files that specify what
|
||||
physical processors to assign to each MPI rank. The -reorder switch
|
||||
simply gives you a portable way to do this without relying on MPI
|
||||
itself. See the "processors out"_processors.html command for how
|
||||
to output info on the final assignment of physical processors to
|
||||
the LAMMPS simulation domain.
|
||||
|
||||
:line
|
||||
|
||||
[-restart2data restartfile \[remap\] datafile keyword value ...]
|
||||
:link(restart2data)
|
||||
|
||||
Convert the restart file into a data file and immediately exit. This
|
||||
is the same operation as if the following 2-line input script were
|
||||
run:
|
||||
|
||||
read_restart restartfile \[remap\]
|
||||
write_data datafile keyword value ... :pre
|
||||
|
||||
The specified restartfile and/or datafile name may contain the wild-card
|
||||
character "*". The restartfile name may also contain the wild-card
|
||||
character "%". The meaning of these characters is explained on the
|
||||
"read_restart"_read_restart.html and "write_data"_write_data.html doc
|
||||
pages. The use of "%" means that a parallel restart file can be read.
|
||||
Note that a filename such as file.* may need to be enclosed in quotes or
|
||||
the "*" character prefixed with a backslash ("\") to avoid shell
|
||||
expansion of the "*" character.
|
||||
|
||||
Following restartfile argument, the optional word "remap" may be used.
|
||||
This has the same effect like adding it to a
|
||||
"read_restart"_read_restart.html command, and operates as explained on
|
||||
its doc page. This is useful if reading the restart file triggers an
|
||||
error that atoms have been lost. In that case, use of the remap flag
|
||||
should allow the data file to still be produced.
|
||||
|
||||
The syntax following restartfile (or remap), namely
|
||||
|
||||
datafile keyword value ... :pre
|
||||
|
||||
is identical to the arguments of the "write_data"_write_data.html
|
||||
command. See its doc page for details. This includes its
|
||||
optional keyword/value settings.
|
||||
|
||||
:line
|
||||
|
||||
[-restart2dump restartfile \[remap\] group-ID dumpstyle dumpfile arg1 arg2 ...] :link(restart2dump)
|
||||
|
||||
Convert the restart file into a dump file and immediately exit. This
|
||||
is the same operation as if the following 2-line input script were
|
||||
run:
|
||||
|
||||
read_restart restartfile \[remap\]
|
||||
write_dump group-ID dumpstyle dumpfile arg1 arg2 ... :pre
|
||||
|
||||
Note that the specified restartfile and dumpfile names may contain
|
||||
wild-card characters ("*","%") as explained on the
|
||||
"read_restart"_read_restart.html and "write_dump"_write_dump.html doc
|
||||
pages. The use of "%" means that a parallel restart file and/or
|
||||
parallel dump file can be read and/or written. Note that a filename
|
||||
such as file.* may need to be enclosed in quotes or the "*" character
|
||||
prefixed with a backslash ("\") to avoid shell expansion of the "*"
|
||||
character.
|
||||
|
||||
Note that following the restartfile argument, the optional word "remap"
|
||||
can be used. This has the effect as adding it to the
|
||||
"read_restart"_read_restart.html command, as explained on its doc page.
|
||||
This is useful if reading the restart file triggers an error that atoms
|
||||
have been lost. In that case, use of the remap flag should allow the
|
||||
dump file to still be produced.
|
||||
|
||||
The syntax following restartfile (or remap), namely
|
||||
|
||||
group-ID dumpstyle dumpfile arg1 arg2 ... :pre
|
||||
|
||||
is identical to the arguments of the "write_dump"_write_dump.html
|
||||
command. See its doc page for details. This includes what per-atom
|
||||
fields are written to the dump file and optional dump_modify settings,
|
||||
including ones that affect how parallel dump files are written, e.g.
|
||||
the {nfile} and {fileper} keywords. See the
|
||||
"dump_modify"_dump_modify.html doc page for details.
|
||||
|
||||
:line
|
||||
|
||||
[-screen file] :link(screen)
|
||||
|
||||
Specify a file for LAMMPS to write its screen information to. In
|
||||
one-partition mode, if the switch is not used, LAMMPS writes to the
|
||||
screen. If this switch is used, LAMMPS writes to the specified file
|
||||
instead and you will see no screen output. In multi-partition mode,
|
||||
if the switch is not used, hi-level status information is written to
|
||||
the screen. Each partition also writes to a screen.N file where N is
|
||||
the partition ID. If the switch is specified in multi-partition mode,
|
||||
the hi-level screen dump is named "file" and each partition also
|
||||
writes screen information to a file.N. For both one-partition and
|
||||
multi-partition mode, if the specified file is "none", then no screen
|
||||
output is performed. Option -pscreen will override the name of the
|
||||
partition screen files file.N.
|
||||
|
||||
:line
|
||||
|
||||
[-suffix style args] :link(suffix)
|
||||
|
||||
Use variants of various styles if they exist. The specified style can
|
||||
be {gpu}, {intel}, {kk}, {omp}, {opt}, or {hybrid}. These
|
||||
refer to optional packages that LAMMPS can be built with, as described
|
||||
in "Accelerate performance"_Speed.html. The "gpu" style corresponds to the
|
||||
GPU package, the "intel" style to the USER-INTEL package, the "kk"
|
||||
style to the KOKKOS package, the "opt" style to the OPT package, and
|
||||
the "omp" style to the USER-OMP package. The hybrid style is the only
|
||||
style that accepts arguments. It allows for two packages to be
|
||||
specified. The first package specified is the default and will be used
|
||||
if it is available. If no style is available for the first package,
|
||||
the style for the second package will be used if available. For
|
||||
example, "-suffix hybrid intel omp" will use styles from the
|
||||
USER-INTEL package if they are installed and available, but styles for
|
||||
the USER-OMP package otherwise.
|
||||
|
||||
Along with the "-package" command-line switch, this is a convenient
|
||||
mechanism for invoking accelerator packages and their options without
|
||||
having to edit an input script.
|
||||
|
||||
As an example, all of the packages provide a "pair_style
|
||||
lj/cut"_pair_lj.html variant, with style names lj/cut/gpu,
|
||||
lj/cut/intel, lj/cut/kk, lj/cut/omp, and lj/cut/opt. A variant style
|
||||
can be specified explicitly in your input script, e.g. pair_style
|
||||
lj/cut/gpu. If the -suffix switch is used the specified suffix
|
||||
(gpu,intel,kk,omp,opt) is automatically appended whenever your input
|
||||
script command creates a new "atom"_atom_style.html,
|
||||
"pair"_pair_style.html, "fix"_fix.html, "compute"_compute.html, or
|
||||
"run"_run_style.html style. If the variant version does not exist,
|
||||
the standard version is created.
|
||||
|
||||
For the GPU package, using this command-line switch also invokes the
|
||||
default GPU settings, as if the command "package gpu 1" were used at
|
||||
the top of your input script. These settings can be changed by using
|
||||
the "-package gpu" command-line switch or the "package
|
||||
gpu"_package.html command in your script.
|
||||
|
||||
For the USER-INTEL package, using this command-line switch also
|
||||
invokes the default USER-INTEL settings, as if the command "package
|
||||
intel 1" were used at the top of your input script. These settings
|
||||
can be changed by using the "-package intel" command-line switch or
|
||||
the "package intel"_package.html command in your script. If the
|
||||
USER-OMP package is also installed, the hybrid style with "intel omp"
|
||||
arguments can be used to make the omp suffix a second choice, if a
|
||||
requested style is not available in the USER-INTEL package. It will
|
||||
also invoke the default USER-OMP settings, as if the command "package
|
||||
omp 0" were used at the top of your input script. These settings can
|
||||
be changed by using the "-package omp" command-line switch or the
|
||||
"package omp"_package.html command in your script.
|
||||
|
||||
For the KOKKOS package, using this command-line switch also invokes
|
||||
the default KOKKOS settings, as if the command "package kokkos" were
|
||||
used at the top of your input script. These settings can be changed
|
||||
by using the "-package kokkos" command-line switch or the "package
|
||||
kokkos"_package.html command in your script.
|
||||
|
||||
For the OMP package, using this command-line switch also invokes the
|
||||
default OMP settings, as if the command "package omp 0" were used at
|
||||
the top of your input script. These settings can be changed by using
|
||||
the "-package omp" command-line switch or the "package
|
||||
omp"_package.html command in your script.
|
||||
|
||||
The "suffix"_suffix.html command can also be used within an input
|
||||
script to set a suffix, or to turn off or back on any suffix setting
|
||||
made via the command line.
|
||||
|
||||
:line
|
||||
|
||||
[-var name value1 value2 ...] :link(var)
|
||||
|
||||
Specify a variable that will be defined for substitution purposes when
|
||||
the input script is read. This switch can be used multiple times to
|
||||
define multiple variables. "Name" is the variable name which can be a
|
||||
single character (referenced as $x in the input script) or a full
|
||||
string (referenced as $\{abc\}). An "index-style
|
||||
variable"_variable.html will be created and populated with the
|
||||
subsequent values, e.g. a set of filenames. Using this command-line
|
||||
option is equivalent to putting the line "variable name index value1
|
||||
value2 ..." at the beginning of the input script. Defining an index
|
||||
variable as a command-line argument overrides any setting for the same
|
||||
index variable in the input script, since index variables cannot be
|
||||
re-defined.
|
||||
|
||||
See the "variable"_variable.html command for more info on defining
|
||||
index and other kinds of variables and the "Commands
|
||||
parse"_Commands_parse.html page for more info on using variables in
|
||||
input scripts.
|
||||
|
||||
NOTE: Currently, the command-line parser looks for arguments that
|
||||
start with "-" to indicate new switches. Thus you cannot specify
|
||||
multiple variable values if any of them start with a "-", e.g. a
|
||||
negative numeric value. It is OK if the first value1 starts with a
|
||||
"-", since it is automatically skipped.
|
|
@ -1,176 +0,0 @@
|
|||
"Higher level section"_Run_head.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Screen and logfile output :h3
|
||||
|
||||
As LAMMPS reads an input script, it prints information to both the
|
||||
screen and a log file about significant actions it takes to setup a
|
||||
simulation. When the simulation is ready to begin, LAMMPS performs
|
||||
various initializations, and prints info about the run it is about to
|
||||
perform, including the amount of memory (in MBytes per processor) that
|
||||
the simulation requires. It also prints details of the initial
|
||||
thermodynamic state of the system. During the run itself,
|
||||
thermodynamic information is printed periodically, every few
|
||||
timesteps. When the run concludes, LAMMPS prints the final
|
||||
thermodynamic state and a total run time for the simulation. It also
|
||||
appends statistics about the CPU time and storage requirements for the
|
||||
simulation. An example set of statistics is shown here:
|
||||
|
||||
Loop time of 2.81192 on 4 procs for 300 steps with 2004 atoms :pre
|
||||
|
||||
Performance: 18.436 ns/day 1.302 hours/ns 106.689 timesteps/s
|
||||
97.0% CPU use with 4 MPI tasks x no OpenMP threads :pre
|
||||
|
||||
MPI task timings breakdown:
|
||||
Section | min time | avg time | max time |%varavg| %total
|
||||
---------------------------------------------------------------
|
||||
Pair | 1.9808 | 2.0134 | 2.0318 | 1.4 | 71.60
|
||||
Bond | 0.0021894 | 0.0060319 | 0.010058 | 4.7 | 0.21
|
||||
Kspace | 0.3207 | 0.3366 | 0.36616 | 3.1 | 11.97
|
||||
Neigh | 0.28411 | 0.28464 | 0.28516 | 0.1 | 10.12
|
||||
Comm | 0.075732 | 0.077018 | 0.07883 | 0.4 | 2.74
|
||||
Output | 0.00030518 | 0.00042665 | 0.00078821 | 1.0 | 0.02
|
||||
Modify | 0.086606 | 0.086631 | 0.086668 | 0.0 | 3.08
|
||||
Other | | 0.007178 | | | 0.26 :pre
|
||||
|
||||
Nlocal: 501 ave 508 max 490 min
|
||||
Histogram: 1 0 0 0 0 0 1 1 0 1
|
||||
Nghost: 6586.25 ave 6628 max 6548 min
|
||||
Histogram: 1 0 1 0 0 0 1 0 0 1
|
||||
Neighs: 177007 ave 180562 max 170212 min
|
||||
Histogram: 1 0 0 0 0 0 0 1 1 1 :pre
|
||||
|
||||
Total # of neighbors = 708028
|
||||
Ave neighs/atom = 353.307
|
||||
Ave special neighs/atom = 2.34032
|
||||
Neighbor list builds = 26
|
||||
Dangerous builds = 0 :pre
|
||||
|
||||
:line
|
||||
|
||||
The first section provides a global loop timing summary. The {loop
|
||||
time} is the total wall-clock time for the simulation to run. The
|
||||
{Performance} line is provided for convenience to help predict how
|
||||
long it will take to run a desired physical simulation. The {CPU use}
|
||||
line provides the CPU utilization per MPI task; it should be close to
|
||||
100% times the number of OpenMP threads (or 1 of not using OpenMP).
|
||||
Lower numbers correspond to delays due to file I/O or insufficient
|
||||
thread utilization.
|
||||
|
||||
:line
|
||||
|
||||
The {MPI task} section gives the breakdown of the CPU run time (in
|
||||
seconds) into major categories:
|
||||
|
||||
{Pair} = non-bonded force computations
|
||||
{Bond} = bonded interactions: bonds, angles, dihedrals, impropers
|
||||
{Kspace} = long-range interactions: Ewald, PPPM, MSM
|
||||
{Neigh} = neighbor list construction
|
||||
{Comm} = inter-processor communication of atoms and their properties
|
||||
{Output} = output of thermodynamic info and dump files
|
||||
{Modify} = fixes and computes invoked by fixes
|
||||
{Other} = all the remaining time :ul
|
||||
|
||||
For each category, there is a breakdown of the least, average and most
|
||||
amount of wall time any processor spent on this category of
|
||||
computation. The "%varavg" is the percentage by which the max or min
|
||||
varies from the average. This is an indication of load imbalance. A
|
||||
percentage close to 0 is perfect load balance. A large percentage is
|
||||
imbalance. The final "%total" column is the percentage of the total
|
||||
loop time is spent in this category.
|
||||
|
||||
When using the "timer full"_timer.html setting, an additional column
|
||||
is added that also prints the CPU utilization in percent. In addition,
|
||||
when using {timer full} and the "package omp"_package.html command are
|
||||
active, a similar timing summary of time spent in threaded regions to
|
||||
monitor thread utilization and load balance is provided. A new {Thread
|
||||
timings} section is also added, which lists the time spent in reducing
|
||||
the per-thread data elements to the storage for non-threaded
|
||||
computation. These thread timings are measured for the first MPI rank
|
||||
only and thus, because the breakdown for MPI tasks can change from
|
||||
MPI rank to MPI rank, this breakdown can be very different for
|
||||
individual ranks. Here is an example output for this section:
|
||||
|
||||
Thread timings breakdown (MPI rank 0):
|
||||
Total threaded time 0.6846 / 90.6%
|
||||
Section | min time | avg time | max time |%varavg| %total
|
||||
---------------------------------------------------------------
|
||||
Pair | 0.5127 | 0.5147 | 0.5167 | 0.3 | 75.18
|
||||
Bond | 0.0043139 | 0.0046779 | 0.0050418 | 0.5 | 0.68
|
||||
Kspace | 0.070572 | 0.074541 | 0.07851 | 1.5 | 10.89
|
||||
Neigh | 0.084778 | 0.086969 | 0.089161 | 0.7 | 12.70
|
||||
Reduce | 0.0036485 | 0.003737 | 0.0038254 | 0.1 | 0.55 :pre
|
||||
|
||||
:line
|
||||
|
||||
The third section above lists the number of owned atoms (Nlocal),
|
||||
ghost atoms (Nghost), and pair-wise neighbors stored per processor.
|
||||
The max and min values give the spread of these values across
|
||||
processors with a 10-bin histogram showing the distribution. The total
|
||||
number of histogram counts is equal to the number of processors.
|
||||
|
||||
:line
|
||||
|
||||
The last section gives aggregate statistics (across all processors)
|
||||
for pair-wise neighbors and special neighbors that LAMMPS keeps track
|
||||
of (see the "special_bonds"_special_bonds.html command). The number
|
||||
of times neighbor lists were rebuilt is tallied, as is the number of
|
||||
potentially {dangerous} rebuilds. If atom movement triggered neighbor
|
||||
list rebuilding (see the "neigh_modify"_neigh_modify.html command),
|
||||
then dangerous reneighborings are those that were triggered on the
|
||||
first timestep atom movement was checked for. If this count is
|
||||
non-zero you may wish to reduce the delay factor to insure no force
|
||||
interactions are missed by atoms moving beyond the neighbor skin
|
||||
distance before a rebuild takes place.
|
||||
|
||||
:line
|
||||
|
||||
If an energy minimization was performed via the
|
||||
"minimize"_minimize.html command, additional information is printed,
|
||||
e.g.
|
||||
|
||||
Minimization stats:
|
||||
Stopping criterion = linesearch alpha is zero
|
||||
Energy initial, next-to-last, final =
|
||||
-6372.3765206 -8328.46998942 -8328.46998942
|
||||
Force two-norm initial, final = 1059.36 5.36874
|
||||
Force max component initial, final = 58.6026 1.46872
|
||||
Final line search alpha, max atom move = 2.7842e-10 4.0892e-10
|
||||
Iterations, force evaluations = 701 1516 :pre
|
||||
|
||||
The first line prints the criterion that determined minimization was
|
||||
converged. The next line lists the initial and final energy, as well
|
||||
as the energy on the next-to-last iteration. The next 2 lines give a
|
||||
measure of the gradient of the energy (force on all atoms). The
|
||||
2-norm is the "length" of this 3N-component force vector; the largest
|
||||
component (x, y, or z) of force (infinity-norm) is also given. Then
|
||||
information is provided about the line search and statistics on how
|
||||
many iterations and force-evaluations the minimizer required.
|
||||
Multiple force evaluations are typically done at each iteration to
|
||||
perform a 1d line minimization in the search direction. See the
|
||||
"minimize"_minimize.html doc page for more details.
|
||||
|
||||
:line
|
||||
|
||||
If a "kspace_style"_kspace_style.html long-range Coulombics solver
|
||||
that performs FFTs was used during the run (PPPM, Ewald), then
|
||||
additional information is printed, e.g.
|
||||
|
||||
FFT time (% of Kspce) = 0.200313 (8.34477)
|
||||
FFT Gflps 3d 1d-only = 2.31074 9.19989 :pre
|
||||
|
||||
The first line is the time spent doing 3d FFTs (several per timestep)
|
||||
and the fraction it represents of the total KSpace time (listed
|
||||
above). Each 3d FFT requires computation (3 sets of 1d FFTs) and
|
||||
communication (transposes). The total flops performed is 5Nlog_2(N),
|
||||
where N is the number of points in the 3d grid. The FFTs are timed
|
||||
with and without the communication and a Gflop rate is computed. The
|
||||
3d rate is with communication; the 1d rate is without (just the 1d
|
||||
FFTs). Thus you can estimate what fraction of your FFT time was spent
|
||||
in communication, roughly 75% in the example above.
|
|
@ -1,73 +0,0 @@
|
|||
"Higher level section"_Run_head.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Running LAMMPS on Windows :h3
|
||||
|
||||
To run a serial (non-MPI) executable, follow these steps:
|
||||
|
||||
Get a command prompt by going to Start->Run... ,
|
||||
then typing "cmd". :ulb,l
|
||||
|
||||
Move to the directory where you have your input script,
|
||||
(e.g. by typing: cd "Documents"). :l
|
||||
|
||||
At the command prompt, type "lmp_serial -in in.file", where
|
||||
in.file is the name of your LAMMPS input script. :l,ule
|
||||
|
||||
Note that the serial executable includes support for multi-threading
|
||||
parallelization from the styles in the USER-OMP packages. To run with
|
||||
4 threads, you can type this:
|
||||
|
||||
lmp_serial -in in.lj -pk omp 4 -sf omp :pre
|
||||
|
||||
:line
|
||||
|
||||
For the MPI executable, which allows you to run LAMMPS under Windows
|
||||
in parallel, follow these steps.
|
||||
|
||||
Download and install a compatible MPI library binary package:
|
||||
|
||||
for 32-bit Windows: "mpich2-1.4.1p1-win-ia32.msi"_http://download.lammps.org/thirdparty/mpich2-1.4.1p1-win-ia32.msi
|
||||
for 64-bit Windows: "mpich2-1.4.1p1-win-x86-64.msi"_http://download.lammps.org/thirdparty/mpich2-1.4.1p1-win-x86-64.msi :ul
|
||||
|
||||
The LAMMPS Windows installer packages will automatically adjust your
|
||||
path for the default location of this MPI package. After the
|
||||
installation of the MPICH2 software, it needs to be integrated into
|
||||
the system. For this you need to start a Command Prompt in
|
||||
{Administrator Mode} (right click on the icon and select it). Change
|
||||
into the MPICH2 installation directory, then into the sub-directory
|
||||
[bin] and execute [smpd.exe -install]. Exit the command window.
|
||||
|
||||
Get a new, regular command prompt by going to Start->Run... ,
|
||||
then typing "cmd". :ulb,l
|
||||
|
||||
Move to the directory where you have your input file
|
||||
(e.g. by typing: cd "Documents"). :l,ule
|
||||
|
||||
Then type something like this:
|
||||
|
||||
mpiexec -localonly 4 lmp_mpi -in in.file
|
||||
mpiexec -np 4 lmp_mpi -in in.file :pre
|
||||
|
||||
where in.file is the name of your LAMMPS input script. For the latter
|
||||
case, you may be prompted to enter your password.
|
||||
|
||||
In this mode, output may not immediately show up on the screen, so if
|
||||
your input script takes a long time to execute, you may need to be
|
||||
patient before the output shows up.
|
||||
|
||||
The parallel executable can also run on a single processor by typing
|
||||
something like this:
|
||||
|
||||
lmp_mpi -in in.lj :pre
|
||||
|
||||
Note that the parallel executable also includes OpenMP
|
||||
multi-threading, which can be combined with MPI using something like:
|
||||
|
||||
mpiexec -localonly 2 lmp_mpi -in in.lj -pk omp 2 -sf omp :pre
|
|
@ -1,57 +0,0 @@
|
|||
"Previous Section"_Package.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
|
||||
Section"_Howto.html :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Accelerate performance :h2
|
||||
|
||||
This section describes various methods for improving LAMMPS
|
||||
performance for different classes of problems running on different
|
||||
kinds of machines.
|
||||
|
||||
There are two thrusts to the discussion that follows. The first is
|
||||
using code options that implement alternate algorithms that can
|
||||
speed-up a simulation. The second is to use one of the several
|
||||
accelerator packages provided with LAMMPS that contain code optimized
|
||||
for certain kinds of hardware, including multi-core CPUs, GPUs, and
|
||||
Intel Xeon Phi co-processors.
|
||||
|
||||
The "Benchmark page"_http://lammps.sandia.gov/bench.html of the LAMMPS
|
||||
web site gives performance results for the various accelerator
|
||||
packages discussed on the "Speed packages"_Speed_packages.html doc
|
||||
page, for several of the standard LAMMPS benchmark problems, as a
|
||||
function of problem size and number of compute nodes, on different
|
||||
hardware platforms.
|
||||
|
||||
<!-- RST
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
Speed_bench
|
||||
Speed_measure
|
||||
Speed_tips
|
||||
Speed_packages
|
||||
Speed_compare
|
||||
|
||||
END_RST -->
|
||||
|
||||
<!-- HTML_ONLY -->
|
||||
|
||||
"Benchmarks"_Speed_bench.html
|
||||
"Measuring performance"_Speed_measure.html
|
||||
"General tips"_Speed_tips.html
|
||||
"Accelerator packages"_Speed_packages.html
|
||||
"GPU package"_Speed_gpu.html
|
||||
"USER-INTEL package"_Speed_intel.html
|
||||
"KOKKOS package"_Speed_kokkos.html
|
||||
"USER-OMP package"_Speed_omp.html
|
||||
"OPT package"_Speed_opt.html
|
||||
"Comparison of accelerator packages"_Speed_compare.html :all(b)
|
||||
|
||||
<!-- END_HTML_ONLY -->
|
|
@ -1,88 +0,0 @@
|
|||
"Higher level section"_Speed.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Benchmarks :h3
|
||||
|
||||
Current LAMMPS performance is discussed on the "Benchmarks
|
||||
page"_http://lammps.sandia.gov/bench.html of the "LAMMPS website"_lws
|
||||
where timings and parallel efficiency are listed. The page has
|
||||
several sections, which are briefly described below:
|
||||
|
||||
CPU performance on 5 standard problems, strong and weak scaling
|
||||
GPU and Xeon Phi performance on same and related problems
|
||||
Comparison of cost of interatomic potentials
|
||||
Performance of huge, billion-atom problems :ul
|
||||
|
||||
The 5 standard problems are as follow:
|
||||
|
||||
LJ = atomic fluid, Lennard-Jones potential with 2.5 sigma cutoff (55
|
||||
neighbors per atom), NVE integration :olb,l
|
||||
|
||||
Chain = bead-spring polymer melt of 100-mer chains, FENE bonds and LJ
|
||||
pairwise interactions with a 2^(1/6) sigma cutoff (5 neighbors per
|
||||
atom), NVE integration :l
|
||||
|
||||
EAM = metallic solid, Cu EAM potential with 4.95 Angstrom cutoff (45
|
||||
neighbors per atom), NVE integration :l
|
||||
|
||||
Chute = granular chute flow, frictional history potential with 1.1
|
||||
sigma cutoff (7 neighbors per atom), NVE integration :l
|
||||
|
||||
Rhodo = rhodopsin protein in solvated lipid bilayer, CHARMM force
|
||||
field with a 10 Angstrom LJ cutoff (440 neighbors per atom),
|
||||
particle-particle particle-mesh (PPPM) for long-range Coulombics, NPT
|
||||
integration :l
|
||||
:ole
|
||||
|
||||
Input files for these 5 problems are provided in the bench directory
|
||||
of the LAMMPS distribution. Each has 32,000 atoms and runs for 100
|
||||
timesteps. The size of the problem (number of atoms) can be varied
|
||||
using command-line switches as described in the bench/README file.
|
||||
This is an easy way to test performance and either strong or weak
|
||||
scalability on your machine.
|
||||
|
||||
The bench directory includes a few log.* files that show performance
|
||||
of these 5 problems on 1 or 4 cores of Linux desktop. The bench/FERMI
|
||||
and bench/KEPLER dirs have input files and scripts and instructions
|
||||
for running the same (or similar) problems using OpenMP or GPU or Xeon
|
||||
Phi acceleration options. See the README files in those dirs and the
|
||||
"Speed packages"_Speed_packages.html doc pages for instructions on how
|
||||
to build LAMMPS and run on that kind of hardware.
|
||||
|
||||
The bench/POTENTIALS directory has input files which correspond to the
|
||||
table of results on the
|
||||
"Potentials"_http://lammps.sandia.gov/bench.html#potentials section of
|
||||
the Benchmarks web page. So you can also run those test problems on
|
||||
your machine.
|
||||
|
||||
The "billion-atom"_http://lammps.sandia.gov/bench.html#billion section
|
||||
of the Benchmarks web page has performance data for very large
|
||||
benchmark runs of simple Lennard-Jones (LJ) models, which use the
|
||||
bench/in.lj input script.
|
||||
|
||||
:line
|
||||
|
||||
For all the benchmarks, a useful metric is the CPU cost per atom per
|
||||
timestep. Since performance scales roughly linearly with problem size
|
||||
and timesteps for all LAMMPS models (i.e. interatomic or coarse-grained
|
||||
potentials), the run time of any problem using the same model (atom
|
||||
style, force field, cutoff, etc) can then be estimated.
|
||||
|
||||
Performance on a parallel machine can also be predicted from one-core
|
||||
or one-node timings if the parallel efficiency can be estimated. The
|
||||
communication bandwidth and latency of a particular parallel machine
|
||||
affects the efficiency. On most machines LAMMPS will give a parallel
|
||||
efficiency on these benchmarks above 50% so long as the number of
|
||||
atoms/core is a few 100 or greater, and closer to 100% for large
|
||||
numbers of atoms/core. This is for all-MPI mode with one MPI task per
|
||||
core. For nodes with accelerator options or hardware (OpenMP, GPU,
|
||||
Phi), you should first measure single node performance. Then you can
|
||||
estimate parallel performance for multi-node runs using the same logic
|
||||
as for all-MPI mode, except that now you will typically need many more
|
||||
atoms/node to achieve good scalability.
|
|
@ -1,116 +0,0 @@
|
|||
"Higher level section"_Speed.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
Comparison of various accelerator packages :h3
|
||||
|
||||
The next section compares and contrasts the various accelerator
|
||||
options, since there are multiple ways to perform OpenMP threading,
|
||||
run on GPUs, optimize for vector units on CPUs and run on Intel
|
||||
Xeon Phi (co-)processors.
|
||||
|
||||
All of these packages can accelerate a LAMMPS calculation taking
|
||||
advantage of hardware features, but they do it in different ways
|
||||
and acceleration is not always guaranteed.
|
||||
|
||||
As a consequence, for a particular simulation on specific hardware,
|
||||
one package may be faster than the other. We give some guidelines
|
||||
below, but the best way to determine which package is faster for your
|
||||
input script is to try multiple of them on your machine and experiment
|
||||
with available performance tuning settings. See the benchmarking
|
||||
section below for examples where this has been done.
|
||||
|
||||
[Guidelines for using each package optimally:]
|
||||
|
||||
Both, the GPU and the KOKKOS package allows you to assign multiple
|
||||
MPI ranks (= CPU cores) to the same GPU. For the GPU package, this
|
||||
can lead to a speedup through better utilization of the GPU (by
|
||||
overlapping computation and data transfer) and more efficient
|
||||
computation of the non-GPU accelerated parts of LAMMPS through MPI
|
||||
parallelization, as all system data is maintained and updated on
|
||||
the host. For KOKKOS, there is less to no benefit from this, due
|
||||
to its different memory management model, which tries to retain
|
||||
data on the GPU.
|
||||
:ulb,l
|
||||
|
||||
The GPU package moves per-atom data (coordinates, forces, and
|
||||
(optionally) neighbor list data, if not computed on the GPU) between
|
||||
the CPU and GPU at every timestep. The KOKKOS/CUDA package only does
|
||||
this on timesteps when a CPU calculation is required (e.g. to invoke
|
||||
a fix or compute that is non-GPU-ized). Hence, if you can formulate
|
||||
your input script to only use GPU-ized fixes and computes, and avoid
|
||||
doing I/O too often (thermo output, dump file snapshots, restart files),
|
||||
then the data transfer cost of the KOKKOS/CUDA package can be very low,
|
||||
causing it to run faster than the GPU package. :l
|
||||
|
||||
The GPU package is often faster than the KOKKOS/CUDA package, when the
|
||||
number of atoms per GPU is on the smaller side. The crossover point,
|
||||
in terms of atoms/GPU at which the KOKKOS/CUDA package becomes faster
|
||||
depends strongly on the pair style. For example, for a simple Lennard Jones
|
||||
system the crossover (in single precision) is often about 50K-100K
|
||||
atoms per GPU. When performing double precision calculations the
|
||||
crossover point can be significantly smaller. :l
|
||||
|
||||
Both KOKKOS and GPU package compute bonded interactions (bonds, angles,
|
||||
etc) on the CPU. If the GPU package is running with several MPI processes
|
||||
assigned to one GPU, the cost of computing the bonded interactions is
|
||||
spread across more CPUs and hence the GPU package can run faster in these
|
||||
cases. :l
|
||||
|
||||
When using LAMMPS with multiple MPI ranks assigned to the same GPU, its
|
||||
performance depends to some extent on the available bandwidth between
|
||||
the CPUs and the GPU. This can differ significantly based on the
|
||||
available bus technology, capability of the host CPU and mainboard,
|
||||
the wiring of the buses and whether switches are used to increase the
|
||||
number of available bus slots, or if GPUs are housed in an external
|
||||
enclosure. This can become quite complex. :l
|
||||
|
||||
To achieve significant acceleration through GPUs, both KOKKOS and GPU
|
||||
package require capable GPUs with fast on-device memory and efficient
|
||||
data transfer rates. This requests capable upper mid-level to high-end
|
||||
(desktop) GPUs. Using lower performance GPUs (e.g. on laptops) may
|
||||
result in a slowdown instead. :l
|
||||
|
||||
For the GPU package, specifically when running in parallel with MPI,
|
||||
if it often more efficient to exclude the PPPM kspace style from GPU
|
||||
acceleration and instead run it - concurrently with a GPU accelerated
|
||||
pair style - on the CPU. This can often be easily achieved with placing
|
||||
a {suffix off} command before and a {suffix on} command after the
|
||||
{kspace_style pppm} command. :l
|
||||
|
||||
The KOKKOS/OpenMP and USER-OMP package have different thread management
|
||||
strategies, which should result in USER-OMP being more efficient for a
|
||||
small number of threads with increasing overhead as the number of threads
|
||||
per MPI rank grows. The KOKKOS/OpenMP kernels have less overhead in that
|
||||
case, but have lower performance with few threads. :l
|
||||
|
||||
The USER-INTEL package contains many options and settings for achieving
|
||||
additional performance on Intel hardware (CPU and accelerator cards), but
|
||||
to unlock this potential, an Intel compiler is required. The package code
|
||||
will compile with GNU gcc, but it will not be as efficient. :l
|
||||
:ule
|
||||
|
||||
[Differences between the GPU and KOKKOS packages:]
|
||||
|
||||
The GPU package accelerates only pair force, neighbor list, and (parts
|
||||
of) PPPM calculations. The KOKKOS package attempts to run most of the
|
||||
calculation on the GPU, but can transparently support non-accelerated
|
||||
code (with a performance penalty due to having data transfers between
|
||||
host and GPU). :ulb,l
|
||||
|
||||
The GPU package requires neighbor lists to be built on the CPU when using
|
||||
exclusion lists, or a triclinic simulation box. :l
|
||||
|
||||
The GPU package can be compiled for CUDA or OpenCL and thus supports
|
||||
both, Nvidia and AMD GPUs well. On Nvidia hardware, using CUDA is typically
|
||||
resulting in equal or better performance over OpenCL. :l
|
||||
|
||||
OpenCL in the GPU package does theoretically also support Intel CPUs or
|
||||
Intel Xeon Phi, but the native support for those in KOKKOS (or USER-INTEL)
|
||||
is superior. :l
|
||||
:ule
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue